"나는 코딩이 좋은데, 왜 매니저를 해야 해?"
개발자 커리어에서 한 번쯤은 이 갈림길을 만나게 돼요. IC(Individual Contributor, 개인 기여자) 트랙을 타고 시니어, 스태프, 프린시펄 엔지니어로 갈 것이냐, 아니면 매니저 트랙으로 전환해서 테크 리드, 엔지니어링 매니저, 디렉터로 갈 것이냐. 많은 개발자들이 "매니저 되면 코딩 못 하잖아"라는 이유로 관리직을 기피하는데요, 최근 공유된 한 글이 매니저 전환을 긍정적으로 바라보는 시각을 꽤 설득력 있게 풀어내고 있어서 이야기해보려 해요.
매니저가 된다는 건 어떤 의미인가
먼저 오해를 좀 풀 필요가 있어요. 엔지니어링 매니저는 "코딩을 그만두는 것"이 아니에요. 물론 직접 프로덕션 코드를 작성하는 시간은 줄어들지만, 대신 다른 종류의 문제를 풀게 되는 거예요.
개발자가 푸는 문제가 "이 기능을 어떻게 구현하지?"라면, 매니저가 푸는 문제는 "우리 팀이 어떻게 하면 가장 효과적으로 일할 수 있지?"예요. 이게 뭐냐면, 코드의 버그를 고치는 대신 조직의 버그를 고치는 거라고 생각하면 돼요. 커뮤니케이션 병목이 어디 있는지, 누가 번아웃 직전인지, 프로젝트 우선순위가 비즈니스 목표와 맞는지 같은 것들이죠.
시스템 디자인을 좋아하는 개발자라면 사실 매니저 역할이 잘 맞을 수 있어요. 소프트웨어 시스템을 설계하는 것과 팀 시스템을 설계하는 것은 놀라울 만큼 비슷하거든요. 의존성 관리, 병목 제거, 확장성 확보, 장애 대응 프로세스... 이런 개념들이 거의 그대로 적용돼요.
매니저 전환을 고려해야 하는 현실적인 이유들
솔직히 이야기하면, 많은 회사에서 IC 트랙의 상위 레벨은 자리가 매우 적어요. 스태프 엔지니어 이상의 포지션은 회사마다 몇 명 안 되는 경우가 많고, 프린시펄 엔지니어는 더 적죠. 반면 팀이 늘어나면 매니저 자리는 자연스럽게 생기는 구조예요. 커리어 성장의 천장이라는 관점에서 보면 매니저 트랙이 현실적으로 더 많은 기회를 제공하는 경우가 있어요.
또 하나 중요한 건 영향력의 범위예요. 아무리 뛰어난 개발자라도 혼자서 할 수 있는 일에는 한계가 있잖아요. 하루에 쓸 수 있는 코드의 양은 정해져 있으니까요. 그런데 매니저로서 5명, 10명의 개발자가 더 잘 일할 수 있는 환경을 만들어주면, 내가 직접 코딩하는 것보다 훨씬 큰 임팩트를 낼 수 있어요. 이걸 "레버리지"라고 부르는데, 자기 시간 1시간을 투자해서 팀 전체의 생산성을 올리는 거예요.
보상 측면에서도 이야기하자면, 한국 IT 업계에서 시니어 개발자와 엔지니어링 매니저의 연봉 밴드가 비슷하거나 매니저 쪽이 약간 높은 경우가 많아요. 특히 CTO나 VP of Engineering 같은 상위 관리직으로 가면 보상 차이가 더 벌어지는 게 현실이에요.
그런데 매니저가 안 맞는 사람도 있다
균형 잡힌 시각을 위해 반대편도 이야기해야겠죠. 매니저 역할이 안 맞는 경우도 분명히 있어요.
1:1 미팅에 에너지가 소진되는 사람이라면 매니저가 힘들 수 있어요. 매니저의 핵심 업무 중 하나가 팀원과의 정기적인 1:1인데, 이게 매주 여러 번 반복되거든요. 사람과의 대화에서 에너지를 얻는 게 아니라 소모되는 타입이라면 꽤 지칠 수 있어요.
또 성과가 눈에 잘 안 보인다는 점도 있어요. 코드를 짜면 결과물이 바로 보이잖아요. PR을 올리고, 배포하고, 유저가 쓰는 걸 확인하는 그 뿌듯함이 있는데. 매니저의 성과는 "팀이 잘 돌아가는 것"이라서 즉각적인 만족감이 덜해요. 오히려 잘할수록 티가 안 나는 역설적인 역할이기도 하죠.
그리고 한국 스타트업 환경에서는 "플레잉 매니저"를 요구하는 경우가 많아요. 코딩도 하면서 관리도 하라는 건데, 이게 양쪽 다 중간만 하게 되는 함정에 빠지기 쉬워요. 매니저 전환을 결심했다면 회사가 관리 업무에 집중할 수 있는 환경을 제공하는지도 확인해봐야 해요.
한국 개발자에게 주는 시사점
한국 IT 업계는 지금 빠르게 성숙하고 있어요. 10년 전만 해도 "개발 잘하는 사람이 팀장 되는" 구조였다면, 지금은 엔지니어링 매니지먼트를 하나의 전문 영역으로 인식하는 회사들이 많아졌거든요.
매니저 전환을 고민하고 있다면 몇 가지를 체크해보세요. 먼저 지금 하고 있는 비공식 리더십 활동이 있는지 봐주세요. 코드 리뷰를 많이 하고, 주니어 멘토링을 자발적으로 하고, 팀 프로세스 개선에 관심이 있다면 이미 매니저의 일을 일부 하고 있는 거예요. 이런 활동에서 에너지를 느끼는지가 중요한 지표가 돼요.
"매니저 해봤다가 안 맞으면 어쩌지"라는 걱정도 많이 하시는데, 요즘은 매니저에서 다시 IC로 돌아오는 걸 자연스럽게 받아들이는 문화가 자리잡고 있어요. 이걸 "매니저 펜들럼"이라고 하는데, 양쪽을 모두 경험해본 사람이 오히려 더 가치 있는 인재가 될 수 있어요.
한줄 정리
매니저 전환은 코딩을 포기하는 게 아니라, 문제를 푸는 스케일을 코드에서 조직으로 넓히는 선택이에요.
여러분의 5년 후 커리어 그림에 매니저 역할이 들어가 있나요? 아니면 IC 트랙에서 깊이를 파는 게 더 끌리시나요?
🔗 출처: Hacker News
TTJ 코딩클래스 정규반
월급 외 수입,
코딩으로 만들 수 있습니다
17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공
