테크리드로 넘어가는 시점, 무엇으로 판단하나?
결론부터 적는다. 연차가 5년이든 8년이든 그 자체는 테크리드 전환의 근거가 안 된다. 판단 기준은 "코드가 아니라 시스템·조직·배포 흐름까지 병목을 정의할 수 있는가"이고, 그다음이 "기능 속도·기술 부채·안정성 중 무엇을 먼저 희생할지 말할 수 있는가"다. 이 두 개를 못하면 시니어 IC로 남는 게 오히려 팀에 이득인 경우가 많다.
- 테크리드는 사람 관리자가 아니라 코드베이스 장기 건강을 책임지는 senior IC 정의가 실무 가이드에서 우세하고, 코드 작성 비중은 40~60% 수준으로 제시된다출처: pandev-metrics.com
- 2026년 기준 기술 리더의 최우선 과제는 "측정 가능한 비즈니스 성과" 79%로, 코드 품질 단독 지표보다 앞선다출처: Deloitte
- 팀 규모 7명 미만이면 테크리드, 8명 이상이면 엔지니어링 매니저 구조가 더 맞는다는 실무 기준이 있다
- 기술 부채는 감정적 판단이 아니라 스프린트 용량 15~20% 상시 배분 같은 정량 규칙으로 다뤄진다
이 전환에서 가장 먼저 갈리는 건 "내가 짠 코드의 품질"이 아니라 "내가 정의한 문제의 범위"다. 주니어~중급 시니어는 버그를 고치고 기능을 낸다. 테크리드는 그 버그가 왜 반복되는지, 배포 파이프라인의 어느 지점이 병목인지, 두 팀이 같은 API를 다르게 해석해서 생긴 마찰인지를 구분해야 한다. 이 구분 능력이 없으면 아래 축들은 다 무의미해진다.
코드 작성 비중이 줄어드는 게 맞는 신호인가?
맞다, 다만 줄어드는 방향과 속도가 중요하다. 실무 자료에 따르면 테크리드의 중간 코드 작성 시간은 하루 3시간 12분이고, 엔지니어링 매니저는 18분으로 나온다출처: pandev-metrics.com. 이 차이는 "테크리드가 손을 놓는다"는 뜻이 아니라 "코드 작성 시간의 나머지가 어디로 가는가"를 보여준다. 같은 자료의 일과 분해를 보면 architecture·design에 15~25%, 크로스팀 미팅에 10~15%, 코드 리뷰에 15~25%가 배분된다.
내가 직접 이 전환기를 지나면서 느낀 건, 코드 비중이 줄어드는 걸 불안해하면 안 된다는 점이었다. 문제는 "코드 대신 뭘 채우고 있느냐"다. 크로스팀 미팅 시간이 늘었는데 그 미팅에서 내가 결정을 내리지 못하고 정보 전달만 하고 있다면, 그건 성장이 아니라 역할 혼선이다. 반대로 코드 리뷰 시간이 늘면서 그 리뷰 기준 자체를 팀 표준으로 만들고 있다면 그게 진짜 전환 신호다.
기능 속도와 기술 부채, 뭘 먼저 챙겨야 하나?
정답은 없고, 우선순위를 매번 설명할 수 있어야 한다는 게 기준이다. O'Reilly의 2026년 자료는 기술 리더의 핵심 과제를 feature velocity, technical debt, system stability의 삼중 트레이드오프로 직접 제시한다출처: O'Reilly. 셋 중 하나를 100% 만족시키면 나머지 둘이 무너진다는 전제가 깔려 있다.
실무에서 쓸 수 있는 정량 규칙 하나는 기술 부채를 스프린트 용량의 15~20%로 상시 배분하는 방식이다출처: hirestepx.com. 이때 부채를 "버그 유발", "개발 속도 저하", "확장성 저해", "보안 위험" 네 갈래로 나눠서 우선순위를 매기라는 제안도 함께 나온다. 나는 이 분류를 그대로 쓰기보다, 팀 컨텍스트에 맞춰 "이번 분기 로드맵에 영향을 주는가"를 필터로 하나 더 얹었다. 분류 자체보다 "이 부채를 지금 안 갚으면 다음 스프린트 어디서 터지는가"를 구체적으로 말할 수 있느냐가 실전에서는 더 중요했다.
주의할 점은 이 셋 중 하나를 절대적으로 우선하는 규칙은 없다는 것이다. 안정성만 밀면 기능 딜리버리가 멈추고, 속도만 밀면 부채가 쌓여 다음 분기 전체를 갉아먹는다. 테크리드의 실질 업무는 이 세 축의 균형점을 매 스프린트 다시 협상하는 일에 가깝다.
팀 규모가 커지면 역할이 어떻게 바뀌나?
바뀐다, 그것도 꽤 명확한 경계선에서. 실무 가이드에 따르면 팀 규모 7명 미만에서는 테크리드가 더 적합하고, 8명 이상에서는 엔지니어링 매니저 구조가 더 적합하다고 정리된다출처: pandev-metrics.com. 이 경계는 절대 법칙이 아니라 코드 작성·기술 의사결정과 사람 관리를 한 사람이 동시에 감당할 수 있는 물리적 한계에 가깝다.
Deloitte 조사에서는 조직의 71%가 기술 리더를 5명 이상 보유한다고 나온다출처: Deloitte. 이건 한 사람의 테크리드가 조직 전체를 커버하는 구조가 아니라, 여러 명의 테크리드가 각자 다른 팀·도메인을 맡고 서로 조정하는 구조가 이미 일반적이라는 뜻으로 읽힌다. 같은 자료는 기술 리더의 역할이 운영(run) 중심에서 조정(orchestrate) 중심으로 이동했다고 설명한다. 내가 겪은 조직에서도 팀이 6명일 때와 10명일 때 내 하루 일과는 완전히 달랐다. 6명일 때는 아키텍처 결정과 코드 리뷰가 하루 절반이었고, 10명이 넘어가자 두 개 서브팀 간 인터페이스 정의와 우선순위 조율에 더 많은 시간이 들어갔다.
장애 대응과 크로스팀 조율까지 책임지는 게 맞나?
책임 범위는 위임이 아니라 소유로 정의된다. 한 채용 가이드는 테크리드가 아키텍처 품질, delivery velocity, technical soundness를 묶어서 책임지고, deployment frequency나 incident recovery time 같은 운영 지표를 관리 대상으로 삼아야 한다고 적는다출처: hire22.ai. 같은 자료는 테크리드가 기술 결정을 아래로 위임하는 수준이 아니라 코드 리뷰 기준, 시스템 설계 선택, 장애 대응과 RCA까지 직접 책임져야 한다고 명시한다.
이 부분에서 자주 간과되는 게 협상·중재 능력이다. 엔지니어링 리더십 역량 문서는 이를 핵심 역량으로 별도 명시한다출처: Engineers Australia. 장애 회고에서 RCA를 쓰는 기술 능력과, 그 RCA를 두 팀이 서로 책임을 떠넘기지 않는 방식으로 진행하는 능력은 완전히 다른 스킬셋이다. 나는 장애 대응 자체보다 사후 회고 미팅에서 "누구 코드가 문제였나"로 흘러가는 걸 막는 데 더 많은 에너지를 썼다.
실무에서 놓치기 쉬운 함정은 무엇인가?
가장 흔한 함정은 코드 비중을 줄이면서 기술 감각까지 같이 놓치는 것이다. 코드 작성 시간이 3시간대에서 1시간대로 줄어드는 건 자연스러운 흐름이지만, 그 줄어든 시간을 크로스팀 회의로만 채우고 실제 코드베이스 변화를 못 따라가면 코드 리뷰 기준 자체가 형식적으로 변한다. 리뷰에서 "스타일만 지적하고 아키텍처 리스크는 못 짚는" 상태가 되면 테크리드로서의 핵심 책임을 못 하는 셈이다.
또 다른 함정은 기술 부채 배분 비율(15~20%)을 숫자 자체로 목표화하는 것이다. 이 수치는 참고 기준이지 정답이 아니다출처: hirestepx.com. 어떤 스프린트는 규제 준수 이슈 때문에 30%를 써야 할 수도 있고, 어떤 분기는 신규 기능이 급해서 5%로 줄여야 할 수도 있다. 이 배분을 매번 설명할 수 있느냐가 숫자를 지키는 것보다 중요하다.
마지막으로, 제품 요구사항을 엔지니어링 요구사항으로 번역하는 역할을 과소평가하는 경우가 많다출처: ssmusoke.com. 이 번역 작업은 회의록에 남지 않고 티켓에도 안 잡히지만, 이게 안 되면 제품팀과 엔지니어링 팀 사이의 마찰이 스프린트마다 반복된다.
결론적으로 언제 무엇을 준비해야 하나?
지금 시니어 IC 단계라면 다음 전환 준비는 코드 생산량이 아니라 아래 네 가지를 스스로 설명할 수 있는지로 점검하는 게 맞다.
- 최근 3개월 안에 코드가 아니라 시스템·배포 흐름·조직 구조 차원에서 병목을 정의한 적이 있는가
- 기능 속도·기술 부채·안정성 중 하나를 의도적으로 희생한 결정을 내리고 그 근거를 설명할 수 있는가
- 팀 규모가 7명을 넘어가는 상황에서 내 역할이 구현자에서 조정자로 바뀌어야 함을 인지하고 있는가
- 장애 이후 RCA를 기술적으로만이 아니라 팀 간 마찰 없이 진행할 수 있는가
이 네 가지에 구체적인 사례로 답할 수 없다면, 아직은 연차와 무관하게 테크리드 전환보다 시니어 IC로서 문제 정의 범위를 넓히는 연습이 먼저다.
핵심 정리
- 테크리드 전환의 기준은 연차가 아니라 "코드 밖 병목을 정의하는 능력"과 "트레이드오프를 설명하는 능력"이다
- 코드 작성 비중은 40~60%, 중간 3시간 12분/일 수준으로 줄어들되 완전히 사라지지 않는다출처: pandev-metrics.com
- 기능 속도·기술 부채·안정성은 항상 동시에 저울질해야 하며, 기술 부채는 스프린트 용량 15~20% 같은 정량 규칙으로 관리하는 게 실무적이다
- 팀 규모 7명 미만은 테크리드, 8명 이상은 엔지니어링 매니저 구조가 더 맞는다는 경계가 실무에서 통용된다
- 협상·중재 능력과 제품-엔지니어링 번역 역할은 티켓에 안 남지만 테크리드 핵심 역량이다