5년 차가 되었을 때, 나는 코딩 실력만으로 시니어가 될 수 있다고 생각했다. 알고리즘을 잘 풀고, 새로운 프레임워크를 빨리 익히고, 버그를 빠르게 고치면 자연스럽게 시니어가 되는 줄 알았다. 하지만 현실은 달랐다.
시니어 개발자로 인정받는 순간은 어려운 기술 문제를 풀었을 때가 아니었다. 팀이 막혔을 때 방향을 제시하고, 모호한 요구사항을 구체적인 기술 계획으로 바꾸고, 주니어가 성장할 수 있는 환경을 만들었을 때였다.
코딩 실력은 시니어의 필요조건이지 충분조건이 아니다
물론 코딩을 잘해야 한다. 하지만 코딩은 시니어 역할의 30% 정도에 해당한다. 나머지 70%는 전혀 다른 능력을 요구한다. 기술적 의사결정, 커뮤니케이션, 멘토링, 프로젝트 리딩이 그것이다.
주니어 개발자의 일주일:
월: 기능 구현
화: 기능 구현
수: 버그 수정
목: 기능 구현
금: 코드 정리
시니어 개발자의 일주일:
월: 기술 설계 리뷰 + 아키텍처 문서 작성
화: 1:1 멘토링 + 코드 리뷰 + 기능 구현
수: 기술 부채 우선순위 정리 + 스프린트 플래닝
목: 크로스팀 미팅 + 장애 대응 프로세스 개선
금: RFC 작성 + 주니어 PR 리뷰 + 기술 블로그 작성시니어로 가는 길에서 키워야 할 3가지 역량
역량 1: 기술적 의사결정 능력. "MongoDB와 PostgreSQL 중 뭘 써야 하나?"라는 질문에 답하는 것이 아니라, "이 프로젝트의 데이터 특성과 팀의 경험을 고려했이 때, 왜 이 선택이 최선인지"를 설명할 수 있어야 한다. 트레이드오프를 명확히 하고, 결정의 근거를 문서화하는 습관이 중요하다.
역량 2: 기술적 커뮤니케이션. 비개발 직군에게 기술적 제약을 설명하고, 경영진에게 기술 부채의 비용을 납득시키고, 다른 팀과의 인터페이스를 설계하는 능력. 이것은 코딩과 전혀 다른 근육을 사용한다.
역량 3: 곱하기 효과. 자신의 생산성을 10% 높이는 것보다, 팀원 5명의 생산성을 각각 20%씩 높이는 것이 조직에 더 큰 가치를 준다. 좋은 문서를 작성하고, 재사용 가능한 도구를 만들고, 팀의 개발 환경을 개선하는 것이 곱하기 효과다.
경력의 다음 단계를 준비하려면
코드를 작성하는 시간의 일부를 글을 쓰는 시간으로 바꿔보라. 기술 블로그, RFC 문서, 장애 보고서, 아키텍처 결정 기록(ADR). 글을 쓰면 생각이 정리되고, 그 과정에서 의사결정의 질이 높아진다. 또한 리뷰어가 아닌 멘토가 되어 보라. 코드의 오류를 지적하는 대신, 상대방이 스스로 문제를 발견할 수 있도록 질문을 던져라.
시니어 개발자는 만들어지는 것이지, 연차가 채워져서 되는 것이 아니다. 코딩 너머의 역량을 의식적으로 키워나갈 때, 그 타이틀은 자연스럽게 따라온다.
댓글