팀에 합류한 지 한 달쯤 됐을 때, 우리 팀의 시니어가 뭘 하는 사람인지 궁금해졌다. 코드를 엄청 잘 짜는 사람인 건 알겠는데, 신기하게도 그 사람이 직접 코드를 짜는 걸 별로 본 적이 없었다.

어느 날 슬쩍 캘린더를 봤다. 오전 10시에 프로덕트 팀과 기획 논의, 11시에 다른 팀 시니어와 아키텍처 리뷰, 점심 먹고 1시에 주니어 1on1, 2시에 PR 리뷰 5개, 3시에 장애 대응 프로세스 회의, 4시에야 자기 코드를 짜기 시작. 5시 반에 퇴근. 코딩한 시간은 1시간 반.

처음에는 솔직히 "저 사람은 대체 개발을 언제 하는 거지?"라고 생각했다. 근데 시간이 지나면서, 그 사람이 회의에서 하는 일이 코드를 짜는 것보다 더 중요하다는 걸 깨달았다.

시니어의 하루#

staffeng.com에서 설명하는 시니어/스태프 엔지니어의 역할을 보면, 핵심 활동이 네 가지로 나뉜다. 기술 방향 설정, 멘토링과 스폰서십, 엔지니어링 관점을 의사결정에 주입하기, 그리고 모호한 문제 탐색하기.

우리 팀 시니어도 비슷했다. 구체적으로 뭘 하는지 관찰한 걸 정리해보면 이렇다.

PR 리뷰 (하루 1~2시간)#

시니어의 일과에서 가장 큰 비중을 차지하는 건 코드 리뷰였다. 팀원 4명의 PR을 매일 리뷰했다. 근데 단순히 "여기 세미콜론 빠졌어요" 수준이 아니었다. 코드의 설계 의도를 물었고, 확장성을 따졌고, 엣지 케이스를 짚었다.

한번은 내가 올린 PR에 이런 코멘트가 달렸다. "이 API 호출 실패 시 retry 로직이 없는데, 네트워크 불안정한 환경에서 어떻게 될지 생각해봤어?" 나는 성공 케이스만 생각하고 코드를 짰는데, 시니어는 실패 케이스를 먼저 봤다.

코드 한 줄을 짜는 것보다 다른 사람의 코드 방향을 잡아주는 게 레버리지가 크다. 시니어가 1시간 동안 PR 리뷰를 하면, 4명의 코드 품질이 올라간다. 시니어가 1시간 동안 자기 코드를 짜면, 1명분의 코드가 생긴다. 어느 쪽이 팀에 더 큰 기여인가?

기술적 의사결정 (주 3~5시간)#

새 기능을 어떤 기술 스택으로 만들지, 기존 시스템을 어떻게 마이그레이션할지, 서드파티 라이브러리를 도입할지 직접 만들지. 이런 결정을 시니어가 주도했다.

인상적이었던 건 결정 과정이었다. 그냥 "내 경험상 A가 낫다"가 아니라, 선택지를 나열하고, 각각의 트레이드오프를 문서화하고, 팀원들의 의견을 수렴한 뒤에 결정했다. 그리고 그 결정의 근거를 노션에 기록했다. "왜 B 대신 A를 선택했는지"가 6개월 뒤에도 참조 가능한 상태로.

Gergely Orosz가 엔지니어링 의사결정에 대해 쓴 글에서도 비슷한 맥락의 이야기가 나온다. 결정 자체보다 "결정의 맥락을 기록하는 것"이 더 중요하다고. 당시의 제약 조건, 고려한 대안, 결정의 근거. 이게 있으면 나중에 "왜 이렇게 했지?"라는 질문에 답할 수 있다.

멘토링 (주 2~3시간)#

시니어는 팀의 주니어 둘과 격주로 1on1을 했고, 나를 포함한 미드레벨 개발자들과도 월 1회 1on1을 했다. 1on1에서는 코딩 질문보다 커리어 고민이나 업무 방식에 대한 이야기가 많았다.

나한테는 이런 피드백을 준 적이 있다. "코드를 짜기 전에 10분만 설계를 먼저 해봐. 머릿속으로가 아니라 종이에. 그러면 코딩 시간이 절반으로 줄어." 사소한 조언 같지만, 실제로 해보니까 진짜였다. 기능을 구현하다가 중간에 "아 이 구조가 아닌데" 하고 갈아엎는 일이 확 줄었다.

staffeng.com에서는 이걸 "멘토링과 스폰서십"으로 구분한다. 멘토링은 조언을 주는 거고, 스폰서십은 팀원이 성장할 기회를 만들어주는 거다. 우리 시니어는 둘 다 했다. 주니어 한 명에게 장애 대응 당번을 맡기면서 "이번 주는 네가 리드해봐, 내가 옆에서 백업할게"라고 했다. 직접 하면 30분이면 끝날 일을 주니어한테 맡기면 2시간이 걸렸다. 근데 그 2시간이 주니어에게는 6개월치 경험이었다.

팀 간 조율 (주 2~3시간)#

프론트엔드 팀과 백엔드 팀의 API 스펙 논의, 디자인 팀과의 컴포넌트 규격 조율, 인프라 팀과의 배포 프로세스 정리. 이런 "팀 사이의 빈 공간"을 시니어가 채웠다.

staffeng.com에서 이걸 "접착제(glue) 역할"이라고 부른다. 보이지 않지만 팀이 돌아가게 만드는 필수적인 작업. 누군가가 이걸 하지 않으면 팀 간 커뮤니케이션이 어긋나고, 나중에 "왜 API 스펙이 다른 거야?" 같은 문제가 터진다.

한번은 프론트엔드에서 필요한 데이터와 백엔드에서 내려주는 데이터 구조가 맞지 않는 상황이 있었다. 주니어였던 나는 "프론트에서 변환하면 되죠"라고 생각했는데, 시니어는 백엔드 팀과 미팅을 잡았다. 결과적으로 API 응답 구조를 변경해서, 프론트에서 불필요한 데이터 변환 로직을 짤 필요가 없어졌다. 코드 10줄을 안 짜게 만든 거다.

그리고 코딩 (하루 1~2시간)#

시니어도 코드를 짠다. 근데 짜는 코드의 성격이 다르다. 새 기능의 컴포넌트를 하나하나 만드는 게 아니라, 아키텍처의 뼈대를 잡거나, 복잡한 기술적 문제를 해결하거나, 다른 사람이 참고할 수 있는 패턴 코드를 만든다.

시니어가 직접 짠 코드를 본 적이 있는데, 양은 적지만 구조가 명확했다. 주석 대신 코드 자체가 설명이 되는 방식. 나중에 누가 봐도 "아 이런 구조구나"를 알 수 있게 짜여 있었다. 이런 코드가 팀의 표준이 되고, 다른 팀원들이 비슷한 구조로 코드를 짜게 된다.

staffeng.com에서도 언급하는데, 스태프 엔지니어가 코딩에 너무 많은 시간을 쓰면 오히려 경고 신호라고 한다. "편한 영역에 시간을 쓰는 것"일 수 있다는 거다. 코드를 짜는 건 익숙하고 만족감이 크지만, 진짜 영향력 있는 일은 대부분 코드 밖에 있다.

"나는 그냥 코딩만 하고 싶다"#

2년 차쯤에 "나는 그냥 코딩만 계속 하고 싶다"고 생각한 적이 있다. 회의 없이, 리뷰 없이, 그냥 헤드폰 끼고 온종일 코드만 짜는 삶. 그게 제일 행복할 것 같았다.

지금도 그 마음을 완전히 이해한다. 코드를 짜는 건 즉각적인 보상이 있다. 기능이 동작하면 바로 눈에 보이고, PR이 머지되면 성취감이 든다. 반면에 회의에서 1시간을 보내면 아웃풋이 뭔지 모호하다.

근데 시니어를 관찰하면서 생각이 바뀌었다. 시니어가 1시간 회의를 해서 잘못된 기획 방향을 잡아주면, 팀 전체가 2주치 삽질을 안 한다. 시니어가 아키텍처를 잘 잡아주면, 6개월 뒤에 새 기능 추가가 3일 걸릴 걸 1일로 줄인다. 시니어가 주니어를 잘 멘토링하면, 1명의 생산성이 2배가 된다.

이런 것들이 코드 에디터에는 나타나지 않는다. 커밋 로그에도 없다. GitHub 잔디에도 안 찍힌다. 근데 팀의 성과에 미치는 영향은 코드를 직접 짜는 것보다 훨씬 크다.

Gergely Orosz는 시니어 엔지니어의 핵심 역할이 "개인의 아웃풋"에서 "팀의 아웃풋"으로의 전환이라고 말한다. 주니어일 때는 내가 얼마나 많은 코드를 짰는지가 평가 기준이다. 시니어가 되면 내 팀이 얼마나 잘 돌아가는지가 평가 기준이 된다.

코딩 실력은 기본값이 된다#

오해하면 안 되는 게, 시니어가 코드를 못 짜도 된다는 뜻이 아니다. 코딩 실력은 "있어야 하는 기본값"이다. 기본값이 있는 상태에서, 그 위에 뭘 쌓을 수 있느냐가 시니어와 미드레벨의 차이다.

운전에 비유하면 이해가 쉽다. 초보 운전자는 핸들 조작과 브레이크 타이밍에 집중한다. 숙련된 운전자는 그게 자동화되어 있어서, 도로 상황을 읽고, 목적지까지의 경로를 판단하고, 동승자의 안전을 챙길 여유가 생긴다. 핸들과 브레이크가 중요하지 않다는 게 아니라, 그게 기본이 된 뒤에 더 큰 그림을 볼 수 있다는 거다.

시니어의 코딩 실력은 "핸들과 브레이크"에 해당한다. 그게 안 되면 PR 리뷰도 아키텍처 결정도 할 수 없다. 근데 그것만 잘한다고 시니어가 되는 건 아니다.

불편한 진실: 소통 능력#

시니어를 관찰하면서 가장 불편했던 깨달음이 있다. 그 사람이 팀에서 가장 영향력이 큰 이유는 코딩 실력이 아니라 소통 능력이었다.

PM에게 기술적 제약을 이해시킬 때, 복잡한 개념을 비유로 설명했다. "이건 집의 기둥을 옮기는 것과 같아서, 벽지를 바꾸는 것과는 차원이 다릅니다." PM이 바로 이해했다. 기술 용어를 쓰면 "좀 더 쉽게 설명해주세요"가 되는데, 비유를 쓰면 "아 그러면 일정을 조정해야겠네요"가 된다.

코드 리뷰에서도 마찬가지였다. "이건 틀렸어요"가 아니라 "이런 접근도 있는데, 한번 비교해볼래?" 식이었다. 같은 피드백인데 받아들이는 쪽의 감정이 완전히 다르다. 전자는 방어적으로 만들고, 후자는 호기심을 유발한다.

팀 간 회의에서는 서로 다른 관점을 가진 사람들의 의견을 정리하고, 합의점을 찾아냈다. 프론트엔드와 백엔드가 서로 "이건 너네 쪽에서 해야지"라고 할 때, "이 부분은 프론트에서 처리하면 유저 경험이 좋아지고, 이 부분은 백에서 처리하면 전체 성능이 좋아지니까 이렇게 나누면 어떨까요?"라고 중재했다.

이 모든 게 "코딩 실력" 밖의 영역이다. 근데 이 능력이 없으면 시니어로서의 영향력이 절반으로 줄어든다.

그래서 나는 뭘 해야 하는가#

시니어의 하루를 관찰한 뒤, 스스로에게 물었다. "나는 저렇게 되고 싶은가?" 솔직한 답은 "반반"이었다. 코드를 짜는 시간이 줄어드는 건 아쉽지만, 팀 전체에 미치는 영향이 커지는 건 매력적이었다.

지금 의식적으로 연습하는 것들이 있다.

코드 리뷰를 꼼꼼히 한다. 예전에는 "LGTM"을 많이 달았다. 이제는 "왜 이 구조를 선택했는지" 질문을 하나씩 던진다. 리뷰를 통해 설계 사고를 연습하는 거다.

글로 설명하는 연습을 한다. 기술적 결정을 슬랙에 글로 정리해서 공유한다. "이번에 A 대신 B를 선택한 이유" 같은 글. 처음에는 어색했는데, 반복하니까 복잡한 것을 단순하게 전달하는 능력이 올라간다.

멘토링을 시도한다. 같은 팀 신입에게 "궁금한 거 있으면 편하게 물어봐"라고 먼저 말을 건넨다. 질문에 답하다 보면, 내가 알고 있는 걸 정리하게 되고, 모르고 있던 빈틈도 발견하게 된다.

"왜"를 먼저 묻는다. 기획서가 오면 "어떻게 만들지"보다 "왜 이 기능이 필요하지"를 먼저 생각한다. 가끔은 "이거 안 만들어도 해결되는 문제 아닌가?"를 발견하기도 한다.

시니어는 코드를 덜 짠다. 그리고 그게 맞다.#

staffeng.com에서 읽은 문장 중 이런 게 있었다. 시니어/스태프 엔지니어의 피드백 사이클은 길다고. 주니어의 피드백은 즉각적이다 — 코드를 짜고, 빌드하고, 동작을 확인한다. 시니어의 피드백은 몇 주, 몇 달, 심지어 몇 년이 걸린다. 오늘 내린 아키텍처 결정이 맞았는지는 6개월 뒤에야 알 수 있다.

그래서 시니어의 일상은 "아무것도 안 한 것 같은" 날이 많다. 회의하고, 리뷰하고, 문서 쓰고. 커밋은 0개. 근데 그날의 회의에서 방향을 잡아줘서 팀이 올바른 길로 가고, 리뷰에서 버그를 잡아서 장애를 예방하고, 문서를 써서 6개월 뒤 새 팀원의 온보딩 시간을 단축한다.

코드를 덜 짜는 게 덜 일하는 게 아니다. 일의 성격이 바뀌는 거다. 개인의 아웃풋에서 팀의 아웃풋으로. 직접 짜는 것에서 방향을 잡는 것으로. 하루의 성과에서 분기의 성과로.

이걸 이해하고 나면 "나는 그냥 코딩만 하고 싶다"가 다르게 들린다. 그건 "나는 편한 영역에 머무르고 싶다"일 수도 있다. 물론 개인 기여자(IC) 트랙으로 깊이 가는 선택도 존재하고, 그게 나쁜 건 아니다. 다만 그 선택도 "코딩만 하는 것"과는 다르다. 깊이 있는 IC도 결국 기술 방향을 설정하고, 다른 팀을 설득하고, 문서를 쓰고, 모호한 문제를 정의하는 일을 한다.

코드를 덜 짜되, 더 큰 영향을 만드는 것. 그게 시니어의 역할이고, 솔직히 말해서 처음에는 불편한 전환이다. 근데 그 불편함 너머에 다른 종류의 만족감이 있다는 걸, 시니어의 하루를 관찰하면서 조금씩 느끼고 있다.