안녕하세요! 저번에는 객체지향적으로 생각하는 방법에 대해 다뤘다면, 오늘은 소프트스킬 관련된 책을 가져왔습니다 😊
이 또한 추천을 받았고 제가 현업에서의 경험이 없어 추구하는 협업 방식이 좋은 것인지, 다른 개발자들은 어떻게 추구하는지, 또한 취업을 하더라도 이후에는 어떻게 성장을 계속 해 나아가야하는지에 대해 도움을 받았습니다
제 자신이 더 빠르게 성장을 하고 주변 팀원들과 함께 성장의 시너지를 이끌어 내는 방법에 관한 책
읽으면서 제 상황을 돌아보고 공감할 수 있는 부분도 많았습니다
이 글을 읽으시는 분들도 읽고 조금이나마 성장에 도움이 되었으면 합니다!!
우리는 어떤 시니어 개발자가 되어야 할까요?
물론, 신입인 제가 이런 질문을 던지는 것이 다소 어색하게 느껴질 수도 있습니다.
하지만 저는 ’앞으로 어떻게 노력해야 할까?’라는 장기적인 관점에서 이 질문을 하고 싶었습니다.
자! 생각하셨죠? (각자가 생각하는 답을 마음속에 간직하고 제 글을 읽어주세요)
제가 PM을 할 때 백엔드 개발자분께서 이런 말씀을 하신 적이 있어요:
단순 API만 찍어내는 작업은 질려서 하고 싶지 않아요
어떻게 보면 학생 때부터 하던 걸 개발자가 되어서도 반복 작업만 할 수도 있는 거잖아요?
그래서 책의 저자는 이렇게 말합니다:
소프트웨어 개발에서 점차 경력 연수를 중시하는 문화가 사라질 것
1만시간 법칙의 비밀
이 글을 읽는 분들은 모두 양치를 혼자 하실 줄 알죠???
이렇게 다양한 방법으로 아마 양치하고 계실거에요
(저 기안84님 너무 좋아합니다 날것의 감성)
양치를 할 때 무슨 생각 하시나요?
저는 그 시간이 아까워서 유튜브 보면서 해요
그런 이유인가..? 4년전에 치과를 갔는데 충치가 여러개 발견되어서 돈을 투자햇어요
충치가 있다는 것 = 제가 양치를 잘 못했다는 것인데 분명 만시간 이상 투자를 했는데...
왜 아직도 고수가 아닐까요??
1. 동기가 부족합니다
"와! 나 진짜 세계에서 제일 치카치카 잘하는 사람이 될 거야!!"
이렇게 생각하신 분 있나요? 없죠!
2. 피드백을 제때 받지 못했습니다
치과를 가서 충치를 제거한 후에야 어느 부분을 잘 닦아주세요~라고 해주십니다
결국 의식하지 않고 반복적인 일을 아무 의미없는 일이 되어버립니다
우리는 이를 위해 의도적 수련을 해야합니다
이것을 깨우치고 반성했던 경험이 있어요
이전에 단순 구현을 위해 빠르게 뷰를 그리던 때가 있었는데 다시 문제를 마주할 때 똑같은 실수를 하게 되더라고요
하나의 과제를 하거나 어떤 코드 한줄에도 결국 모든 의도가 들어가야한다는 것을 의미해요
자 그러면 이제 그래서 어떻게 성장하면 될까요?
성장은 복리다!
어떻게 하면 그 성장을 up Up UP 시킬 수 있을까요?
나만의 지식 네트워크 만들기
책에서는 이미 갖고 있는 것들을 하이퍼링크로 촘촘히 연결하라고 강조해요. 옵시디언의 노드들처럼 말이에요 ✨
새로운 기술을 배울 때 흔히 하는 실수가 있어요. "오 신기술~~~! 써봐야지~" 하면서 기존 지식과 연결하지 않고 그냥 덮어쓰기하는 거예요.
하다보면 아직 머리속에 기존 것들과 페어링이 이루어지지 않고 네트워크가 잘 형성이 되지 않았기에 그저 덮어쓰기되는 경우도 발생합니다
한 예시를 swift protocol로 들자면,
덮어쓰기의 경우:
- Equatable: "아, 그냥 비교하는 프로토콜이구나"
- Hashable: "음, 해싱할 때 쓰는 프로토콜이구나"
에서 끝나지만,
촘촘히 연결하는 경우:
protocol Hashable: Equatable {
func hash(into hasher: inout Hasher)
}
연결점 발견:
- Hashable이 Equatable을 채택하는 이유는? 해시 충돌 시 실제 값 비교가 필요하기 때문!
- Dictionary, Set에서 어떻게 활용되는지
와 같이 연결하며 머리속에 기존 지식을 기반으로 더 빠르게 Hashable을 학습할 수 있는거죠
물론 내부적으로 계속 노드들만 연결하는것은 수렴할 위험이 있습니다.
그래서 주기적으로 외부 자극(학습)은 필수에요
몰입할 수 있는 상황을 만들기
미하이 칙센트미하이의 몰입 이론 그래프를 보면, 과제 수준과 개인 능력의 조합에 따라 우리가 어떤 감정을 느끼는지 잘 보여줘요.
일반적으로 능력과 과제 수준이 선형적일 때 몰입할 수 있고, 이때 가장 퍼포먼스와 학습이 잘 이루어져요!
A3: 불안(Anxiety)
여긴 제 능력은 낮은데 해야 하는 과제가 너무 어려울 때 오는 구간이에요
와..내가 이거 할 수 있나... 오늘 과제 너무 어려운데? 생각을 하며 불안감이 몰려오는 단계죠
이때 할 수 있는 방법은 2가지가 있어요
1. A3->A4:
저보다 잘하는 사람에게 도움을 요청하거나, 짝 프로그래밍을 하면서 능력을 향상시킬 수 있어요
요즘에는 AI Agent도 너무 좋기 때문에 활용할 수도 있을거 같아요
2. A3 -> A1:
혹은 과제의 수준을 낮추는 방법도 있어요. 하나의 과제가 들어오면 스스로 우선순위와 체크포인트 잘게잘게 설정하는거죠
그리고 본인이 할 수 있는 데 까지 체크포인트 한 단계씩 목표로 하며 과제 수준을 낮춰 몰입할 수 있어요
하나의 통합 테스트나 인수 테스트를 단위테스트 기준으로 몰입하는 방법도 잇죠
A2: 지루함(Bored)
반대로, 제 능력이 훨씬 뛰어난데 과제가 너무 쉬울 땐
“와… 나 너무 잘하는데? it’s too easy… no jam” 상태가 옵니다.
여기서도 2가지 방법이 있어요
1. A2 -> A4:
일부러 작업의 난이도를 높이는 거죠. 나만의 데드라인을 평소보다 더 빡세게 잡거나,
Instruments로 성능 고려한 개발을 하거나 "굳이" 해야 하는 일까지 하기가 있어요
2. A2 -> A1:
실력을 다운그레이드해봅니다.
"어? 내가 어떻게 여기까지 왔는데 왜 실력을 깎아?"😡
다행히 익숙한 환경에서 벗어나서 개발해보라는 겁니다
Xcode에 익숙해져 있다면 Cursor를, 명령형 프로그래밍이 익숙하다면 함수형 프로그래밍을,
컴파일 주기를 평소보다 더 길게 잡아두고 개발을 하는것도 방법이 될 수 있어요
혹시 더 관심이 있으시다면!!
https://www.youtube.com/watch?v=P9Sy5ODwJlc
이 영상 추천드립니다
그렇다면 현재 저의 상태는 어디일까요??
동시에 함께 생각해봐요 메타인지타임!!
전문가가 되기 위해 질문 전문가부터 되어보기
A3→A4로 가기 위해서는 고수에게 도움을 요청해야 하는데, 여기서 가장 중요한 건 좋은 질문을 던지는 것이에요.
코드 리뷰나 스크럼 회의에서 이런 질문들 많이 하죠:
- "어? 이거 왜 이렇게 했어요...?"
- "에러 처리는 어떻게 했어요?"
- "이 UI 어떻게 짰어요?"
이런 추상적인 질문을 받으면 답변자는 곤란합니다
"음? 뭘 설명하라는 거야! 뭘 모르는 거야!" 하면서 원하는 수준의 답변을 주기 어려워해요.
개선된 질문:
- "에러가 다양하게 발생할 때, 어떤 기준으로 사용자에게 보여줄지/숨길지 결정하셨나요?"
- "UI 요구사항이 자주 바뀔 수 있을 때, 어떤 기준으로 오토레이아웃을 설계하셨나요?"
질문 자체도 구체적인 사건을 답변자가 말하도록 유도하는 게 질문자의 역량이에요! 🙏🏻🙏🏻
피드백을 자주 받아라
최대한 작게 사람들에게 피드백을 받고 순환율을 더 높이는 것이 좋다
우리가 양치를 못했던 이유가 피드백을 못받아서였잖아요?
그렇기 때문에 개발에 대해서 고수가 되기 위해서는 피드백을 받아야 하는데, 그 텀을 최대한 짧게 잡는게 좋다고 합니다
그래야 잘못된 길을 나중에 가서 고치는 것보다 자주 자주 교정하는게 더 빠르게 갈 수 잇죠
챕터1에서 자라기 부분을 강조하였다면 두 번째 부분은 함께입니다. 저는 이 부분을 소프트 스킬과 관련지어 정리해봤어요
소프트 스킬을 up uP UP🚀🚀🚀
우리는 AI에게서 살아남아야 합니다 🤖🤖
암묵적이고 정답이 없는 곳으로 가야 해요!
책에서는 컴퓨터 프로그래머 VS 소프트웨어 개발자 차이를 이렇게 설명해요:
- 컴퓨터 프로그래머: 전달받은 스펙대로 개발 → 컴퓨터화 확률 48%
- 소프트웨어 개발자: 뭘 만들지 고민하고 설계 → 컴퓨터화 확률 4.2%
무슨 차이가 있길래 확률이 저렇게 차이가 날까요? 🤔🤔🤔
바로 스스로 생각하고 협상하는 능력입니다
단순히 "이 API 호출해서 화면에 보여주세요"라는 스펙을 받아서 구현하는 것과
요구사항이 오면 스스로 기능을 나누고 구현을 하는 단계는 다른 분야인 거죠!
팀워크의 비밀
책에서 정말 충격적인 실험 결과가 나와요:
"만약 팀끼리 계획이 없다는 가정하에 고수 개발자 4명을 묶어놓으면 오히려 주니어 개발자 4명이 계획없을때보다 더 효율이 떨어지는 결과가 있었습니다"
물론 제대로 협력했을 땐 당연히(?) 고수 개발자들이 훨씬 효율이 좋았어요 😅
왜 이런 일이 일어날까요?
정보 공유가 제대로 이루어지지 않아 모듈이 제대로 통합되지 않고 충돌이 일어났거든요.
고수들은 각자 자신만의 방식과 고집이 있어서 서로 맞지 않았던 거죠.
결론은 소셜 스킬이 뛰어난 사람이 가운데에서 협력을 잘하도록 돕는 사람이 필요하다는 겁니다
좋은 리더는 프로젝트를 성공으로 이끌 수도 있고, 반대로 비효율의 끝으로 달리게 할 수도 있어요.
그러면 팀을 어떻게 이끌어야할까요?🤔🤔🤔
심리적 안정감⭐️⭐️⭐️⭐️⭐️
저는 실제로 어떤 팀을 구성하면 가장 먼저 하는 것이 최대한 분위기를 풀고 모두가 서로를 의지할 수 있는 환경을 구성하기 위해 노력해왔어요.
이 책을 읽으니 제가 했던 행동들이 더더욱 가치 있는 행동임을 증명해줘서 살짝 다행이었습니다 😂
리더는 기술적으로도 뛰어난 것도 중요하지만 그것보다 더 중요한건:
학습할 수 있는 환경을 만들어주어야 합니다
팀원들 간에 서로 친해지고 의지할 수 있는 환경이 되면 어떤 문제나 고민이 있어도 언제나 먼저 얘기하는 환경이 되더라고요!
저 같은 경우는 질문 자체가 어려운 사람이에요. 그 이유가 너무 스스로 질문의 퀄리티가 너무 낮나?
하다보니 머릿속에서 필터링을 3번 정도 거치고 나오는 것 같아서요.
근데 팀의 분위기가 좋으면 질문이 좀 어설퍼도 손가락질하는 문화가 아니기 때문에 필터링의 횟수가 줄고 아이디어도 더 잘 나왔던 것 같아요! 💡
이런 환경은 설득에서도 장점으로 이루어졌어요
객관성은 상대적이다 - 설득의 기술
프로젝트를 진행하며 원하는 기술을 적용하거나 방향을 이끌어야 할 때가 있을 거예요.
아키텍처 도입을 예시로 들면:
- 개발자A: "MVVM이 최고야!"
- 개발자B: "MVC가 더 실용적이야!"
둘 다 나름의 근거가 있다고 가정해볼게요. 어떻게 설득해야 할까요?
저라면 상대방과 심리적 안정감 관계를 쌓으면서 상대방이 왜 그렇게 생각하는지 이해하는 거예요.
A개발자가 MVC를 적용하면서 고생한 경험이 많아서 MVVM을 도입했다면?
→ 걱정하는 부분을 위주로 설득하기!
"MVVM의 장점보다는 MVC에서 겪었던 문제점들을 어떻게 해결할 수 있는지" 중심으로 대화하는 거죠.
실수해도 괜차나 링딩딩딩딩🎵
실수 문화를 실수 예방에서 실수 관리 문화로 바꿔야 해요
Blame 문화의 악순환
실수를 Blame하는 문화에서는:
- 실수를 숨기려고 함
- 더 큰 삽질을 하다가 더 큰 실수로 발전
- 팀 전체의 생산성 저하
실수 관리 문화에서는:
- 실수를 빠르게 공개
- 함께 수정하는 것이 팀 생산성 측면에서 훨씬 좋음
- 실수를 통해 더 많이 배움
저 또한 모두 편한 분위기를 만들었더니 본인의 실수를 숨기지 않고 말하는 경우가 많았어요. 저조차도 그렇게 했고요!
🤔 회고
저는 코드 리뷰나 PR 리뷰할 때마다 제가 완벽하게 머리속에 정리가 되지 않는다면 아예 질문을 안하거나 말을 안하는 성격이였어요
그런데 이 내용을 정리하고 나니 오히려 그런 부분에서 마이너스 요소가 되는 거고, 차라리 틀리더라도 말을 하고 부끄러워하지 않으며 더 배우는 게 중요한 것 같아요.
또한 질문 자체가 어려운 성향이었는데, 품질을 높이기 위해 노력해야겠어요. 몇 번 컨퍼런스에서 발표를 들었는데 그때마다 시니어 개발자분들이 주니어 개발자에게 원하는 게 "질문을 좀 구체적으로 해라"였거든요.
결국 이 책은, 협업에 관심이 많고 성장에 목말라 있는 현재 상태에 너무 도움이 되는 책이였기에 제 글을 읽고 궁금해진 사람들은 주변 도서관에서 한번쯤 빌려서 읽어도 좋을 책인 거 같습니다
현실에 안주하지 않고, 지금 내가 어디에 집중하고 노력하고 있는지를 자각해보자
그리고 더 큰 성장을 위해, 팀원들과 함께 어떻게 시너지를 낼 수 있을지를 끊임없이 고민을 해보면 좋겠습니다
'도서관' 카테고리의 다른 글
객체지향의 사실과 오해 (7) | 2025.08.14 |
---|