리드를 맡겠냐는 제안을 받았을 때 첫 반응은 기쁨이 아니라 두려움이었다. 코딩 시간이 줄어들 거라는 걸 알고 있었으니까.

개발자로서 코딩은 단순히 일이 아니라 정체성의 일부다. "나는 코드를 쓰는 사람"이라는 자기 인식. 그 시간이 줄어들면 "나는 뭘 하는 사람이지?"라는 질문이 생긴다.

줄어드는 것#

리드를 맡고 나서 캘린더가 미팅으로 채워졌다. 스프린트 플래닝, 스탠드업, 1:1, 기획 리뷰, 채용 면접, 리더 회의. 하루에 코딩할 수 있는 시간이 2시간 남으면 운이 좋은 날이었다.

그 2시간마저도 집중이 어렵다. 30분 코딩하고, 슬랙 알림에 답하고, 다시 코딩하려는데 컨텍스트를 잃어버렸다. 예전에는 2시간이면 기능 하나를 끝낼 수 있었는데, 이제는 코드를 읽다가 회의 시간이 된다.

기술적 감각이 무뎌지는 게 느껴졌다. 팀원이 PR을 올리면 전에는 바로 리뷰할 수 있었는데, 이제는 코드를 파악하는 데 시간이 더 걸린다. 새로운 라이브러리나 패턴을 팀원이 먼저 알고 있다. 기술적으로 뒤처지고 있다는 불안.

"나는 뭘 기여하고 있는가"#

한동안 혼란스러웠다. 하루가 끝나면 "오늘 뭘 했지?"라는 생각이 들었다. 미팅에 들어가서 이야기하고, 슬랙에서 질문에 답하고, 일정을 조율하고. 눈에 보이는 산출물이 없다. 코드는 눈에 보인다. 기능이 동작하면 "내가 이걸 만들었다"는 성취감이 있다. 리드 업무는 그런 게 없다.

전환점은 팀원과의 1:1에서 왔다. 주니어 팀원이 "요즘 코드 리뷰 코멘트 덕분에 많이 배우고 있어요"라고 했다. 또 다른 팀원은 "기획 미팅에서 엔지니어링 관점을 말해줘서 불필요한 기능 개발을 안 하게 됐다"고 했다.

내가 직접 코드를 쓰지 않아도, 팀 전체의 코드 품질과 방향에 영향을 주고 있었다. 형태가 달라졌을 뿐, 기여는 하고 있었다.

새로운 형태의 기여#

리드의 기여는 "곱하기"에 가깝다는 걸 받아들이는 데 시간이 걸렸다.

IC가 10의 기여를 한다면, 리드는 5인 팀원 네 명의 기여를 6으로 만드는 역할이다. 본인의 직접 기여는 5에서 3으로 줄었지만, 팀 전체 기여는 20에서 27이 된다.

코드 리뷰를 통해 코드 품질을 올린다. 아키텍처 결정을 내려서 팀이 삽질하는 시간을 줄인다. 기획과의 소통에서 엔지니어링 제약을 전달해서 실현 가능한 스펙을 만든다. 팀원의 성장을 돕는다.

이게 코딩보다 재미없냐고? 솔직히, 종류가 다른 재미다. 코딩의 재미가 "문제를 풀었다"는 성취감이라면, 리드의 재미는 "팀이 잘 돌아간다"는 만족감이다. 후자가 더 느리게 오고, 덜 선명하지만, 나름의 무게가 있다.

코딩을 완전히 놓지 않는 방법#

그래도 코딩을 완전히 놓으면 안 된다. 기술적 판단력이 떨어지면 리드로서의 가치도 떨어진다.

실천하고 있는 것들:

크리티컬하지 않은 태스크를 직접 한다. 급하지 않고, 다른 사람의 작업을 블로킹하지 않는 태스크를 골라서 직접 코딩한다. 성능 개선, 기술 부채 청산, 개발 환경 개선 같은 것들.

사이드 프로젝트를 유지한다. 회사 프로젝트에서 코딩 시간이 부족하면, 개인 프로젝트에서 새로운 기술을 시도한다. 이 블로그도 그런 역할을 한다.

코드 리뷰를 깊게 한다. 승인만 하는 게 아니라, 코드를 로컬에서 직접 실행해보고 리뷰한다. 이러면 코드 감각도 유지되고, 리뷰 품질도 올라간다.

리드 역할이 모든 개발자에게 맞는 건 아니다. IC 트랙을 선택해서 기술적 깊이를 파는 것도 훌륭한 커리어다. 중요한 건 "코딩을 많이 하는 게 좋은 개발자"라는 생각에서 벗어나는 것이다. 기여의 형태는 다양하다.