퇴사 회고

좋은 개발자가 되는 방식으로 리드를 하다, 다시 프론트엔드 IC를 선택하기까지

퇴사를 결심하며 가장 어려웠던 것은 떠날 이유를 찾는 일이 아니었다. 남아도 될 이유가 너무 많다는 것이었다.

집에서 회사까지는 30분이면 도착했다. 이전 회사를 왕복 세 시간씩 다녀본 나에게 이 거리는 얼마나 큰 행복인지 설명할 필요도 없었다. 함께 일하는 사람들은 착하고 좋은 사람들이었고, 회사에서 만난 테크 조직장님을 나는 진심으로 존경했다. 회사를 떠난 뒤에도 오랫동안 조언을 구하게 될 사람이라고 생각한다.

무엇보다 모든 것이 익숙했다. 4년 넘게 일하면서 서비스뿐 아니라 사내 시스템과 인프라, 조직이 움직이는 방식까지 많은 부분을 알게 됐다. 조용한 성격인 나도 업무에 필요한 일이라면 누구에게든 어렵지 않게 요청할 수 있었다. 회사 안에서 쌓아온 관계와 지식은 내가 일을 잘할 수 있게 해주는 든든한 인프라였다.

그런데 어느 순간부터 그 편안함이 다른 질문을 만들기 시작했다.

나는 지금도 프론트엔드 개발자로서 성장하고 있는가.

공교롭게도 이 질문이 가장 커진 시기는 리드 역할에 가장 깊이 몰입하던 때였다.

좋은 개발자가 되는 방식으로 좋은 리드가 되려 했다

나는 어릴 때부터 개발자가 되고 싶었다. 컴퓨터공학과에 진학했고, 개발자가 된 뒤에도 가장 큰 즐거움은 기술을 깊게 이해하는 일이었다.

새로운 기술을 만나면 사용법보다 내부 동작이 궁금했다. 문제가 생기면 적당히 우회하기보다 왜 발생했는지 끝까지 파고들었다. 동료가 기술적인 문제로 막혀 있을 때 해결 방법이 떠오르면 밤늦게까지 살펴본 뒤 다음 날 가져가기도 했다.

그 집요함은 개발자로서 나를 성장시킨 가장 큰 무기였다.

그래서 처음 리드를 맡았을 때도 같은 방식으로 잘할 수 있을 것이라고 생각했다. 내가 더 많이 알고, 더 꼼꼼히 리뷰하고, 어려운 문제를 더 많이 해결하면 팀에 도움이 될 것이라고 믿었다.

실제로 나는 팀원들이 올리는 PR을 거의 모두 직접 확인했다. 다섯 명 정도의 팀이니 충분히 할 수 있을 것 같았다. 하지만 리드가 되자 이전에는 없던 일이 함께 생겼다. 열흘짜리 스프린트에서 각종 회의에 참여하고 준비하는 데만 내 가용 시간 중 이틀가량이 들어갔다. 그 상태에서 모든 PR을 꼼꼼히 살피는 일은 생각보다 오래 지속할 수 있는 방식이 아니었다.

리뷰가 늦어졌고 나도 점점 지쳤다. 일부 의사결정과 리뷰는 내 답을 기다리며 멈추기도 했다. 내가 모든 일을 챙기는 모습은 당장에는 안전해 보였지만, 결과적으로 내가 팀의 병목이 되는 구조를 만들고 있었다.

내가 답을 많이 줄수록 팀이 더 빨리 움직일 것이라고 생각했다. 반드시 그렇지는 않았다. 때로는 내가 답을 줄 수 있을 때까지 일이 멈췄다.

물어볼 사람도 마땅치 않았다. 조직에는 경험 많은 개발자들이 있었지만 프론트엔드 팀을 이끌어본 사람은 없었다. 조직장님께 방향을 여쭐 수는 있어도 매일 마주치는 판단까지 들고 갈 수는 없었다. 그래서 셸리 벤호프의 《리드 개발자로 가는 길》을 사서 읽기 시작했다.

책에서 가장 오래 붙들고 있었던 문장은 좋은 리드의 성과를 정의하는 대목이었다. 기술 부채가 눈에 띄게 줄어들고 같은 문제가 재발하지 않는 것. 내가 얼마나 많은 문제를 풀었는지는 거기에 없었다.

그 기준으로 내 하루를 다시 보면, 나는 성과를 내고 있는 게 아니라 같은 문제를 매번 새로 풀고 있었다.

리드 없이 도는 구조가 먼저였다

병목이 나라는 것을 알고 나서도 한동안은 더 빨리 리뷰하는 방법을 찾았다. 그런데 그건 내 시간과 집중력의 한계에서 생긴 문제라 내가 더 열심히 하는 것으로는 풀리지 않았다.

리드의 병목을 깨려면 리드 없이 작동하는 구조가 먼저 있어야 했다.

그래서 코드리뷰 체계를 내가 만들지 않기로 했다. 기술적 시도에 열정이 있던 동료에게 TFT 리드를 맡기고, 팀에 맞는 코드리뷰 컨벤션 제정과 리뷰 자동화 도구 검토에 대한 전권을 넘겼다.

형식적으로는 그냥 담당자를 지정한 것이었다. 그래도 발족식을 열었고 발표 세션도 만들었다. 굳이 자리를 만든 이유는 이게 나에게서 내려온 일이 아니라는 걸 보여주고 싶어서였다.

리드가 “앞으로 코드리뷰 이렇게 하세요”라고 하면 통제로 느껴진다. 동료가 “우리 이렇게 리뷰 부담 줄여봐요”라고 하면 받아들이는 온도가 다르다. 팀이 생각하는 리드라는 개념 자체를 바꾸고 싶었다. 이 팀에서는 누구든 자기 영역의 리드가 될 수 있다는 것.

맡겨놓고 내가 다른 일을 하러 간 것은 아니었다. 1on1의 소재가 됐고, 지속적인 대화 주제가 됐고, 같이 고민하는 일이 됐다.

발표 세션은 일부러 무겁지 않게 했다. 실수해도 괜찮다고 자주 말했다. 처음에는 발표하는 쪽도 듣는 쪽도 익숙하지 않았는데, 팀원들이 진지하게 경청해주면서 분위기가 잡혔다. 돌아온 피드백은 재밌다는 것이었다.

TFT 리드는 팀원들의 의견을 수렴해 PR 체크리스트와 코드 스타일 가이드 문서를 정립했다. GitHub PR 템플릿을 만들어 작성자가 컨벤션에 맞게 올리도록 했고, 그 덕분에 리뷰어가 변경 내용을 파악하는 부담이 줄었다. 코드 리뷰 봇과 PR 전 AI를 이용해 셀프 리뷰를 할 수 있는 스킬도 구축했다.

승인 규칙도 이때 정리됐다. 단순 UI나 텍스트 변경, 소규모 리팩토링은 동료 리뷰 한 명의 승인으로 머지할 수 있게 했다. 비즈니스 중요도가 높은 작업이나 아키텍처 변경이나 복잡한 비즈니스 로직, 공통 모듈은 리드를 포함한 두 명의 승인을 받도록 했다.

이 규칙에서 내가 중요하게 본 것은 첫 번째 항목이었다. 내가 보지 않아도 되는 PR의 범위를 팀이 직접 정한 셈이기 때문이다.

비슷한 시기에 AI 코드리뷰 봇도 자리를 잡았다. 봇의 기반은 팀원이 사내 LLM을 연결해 만들었고, 우리는 여기에 팀의 리뷰 규칙을 반영했다. 단순히 코드에 코멘트를 남기는 데서 그치지 않고 PR의 변경 범위를 요약해 시각적으로 보여주도록 개선했다.

정확히 몇 분을 줄였는지는 측정하지 못했다. 다만 실제 리뷰에 도움이 됐다는 의견이 회고에서 나왔고, 나 역시 변경 범위를 파악하는 데 드는 시간이 줄었다고 느꼈다.

봇이 사람의 판단을 대신한 것은 아니었다. 변경 내용을 훑는 반복적인 부담을 줄였을 뿐, 코드를 머지할지 결정하고 그 결과에 책임지는 일은 여전히 사람의 몫이었다.

이 과정에서 배운 것은 컨벤션이나 도구 자체가 아니었다.

좋은 구조를 만들려면 리드가 먼저 전해야 하는 것이 있는데, 그게 실력은 아니었다. 뭐라도 해보려는 의지에 가까웠다.

구조는 리드가 설계해서 팀에 배포하는 물건이 아니다. 팀원이 참여할 때만 작동하고, 참여는 지시로 만들어지지 않는다. 그래서 컨벤션 초안보다 먼저 필요했던 것은 이 사람이 정말 바꿔보려고 한다는 신호였다.

그 신호는 말로 전해지지 않았다. 발족식을 열고, 1on1에서 계속 묻고, 실수해도 괜찮다고 반복하는 데 시간을 쓰는 것으로 전해졌다. 리드가 어디에 시간을 쓰는지를 팀은 보고 있었다.

물론 이게 통한 건 우리 팀원들이 착했기 때문이라고 생각한다. 지금 돌아봐도 감사한 일이다. 같은 방식이 모든 팀에서 통했을 거라고는 말하지 못하겠다.

AI를 말하기 전에 우리가 하는 일부터 살펴봤다

리드가 된 뒤 받은 큰 과제 중 하나는 AI를 팀의 개발 과정에 어떻게 도입할 것인가였다.

하지만 AI를 도입하자는 말을 꺼내기 전에 먼저 살펴본 것은 AI가 아니었다. 우리가 어떤 방식으로 일하고 있는지부터 들여다봤다.

우리 팀이 담당하는 서비스는 여러 금융기관의 정책과 법적 규제에 영향을 받았다. 한 스프린트에 다섯 건 이상의 긴급 수정 요청이 들어올 때도 많았다. 스프린트 보드에는 한때 60개 안팎의 티켓이 올라와 있었다.

물론 티켓 수가 그대로 업무량이나 생산성을 의미하지는 않는다. 티켓마다 난도가 다르고, 하나의 일을 어디까지 나눠 기록하는지에 따라서도 숫자는 달라진다. 그래도 60개에 가까운 티켓이 뒤섞인 보드는 우리가 어디에 시간을 쓰고 있는지조차 제대로 설명하기 어려운 상태라는 사실을 보여주고 있었다.

긴급하지만 단순한 수정이 있었다. 긴급한 동시에 사흘 이상이 필요한 작업도 있었다. 비밀번호 초기화나 계정 관리, 권한 부여처럼 개발팀이 관습적으로 처리하던 백오피스 운영 업무도 있었다. 심의필 번호나 홈페이지 공지사항처럼 주기적으로 반복되는 단순 텍스트 변경도 계속 들어왔다.

모든 일을 더 빠르게 처리하는 것이 답처럼 보였다. 하지만 일감을 하나씩 살펴볼수록 속도보다 먼저 해결해야 할 문제가 보였다.

서로 다른 종류의 일이 한 보드 안에 뒤섞여 있었다.

그래서 플래닝과 스크럼 방식을 바꾸기 시작했다. Jira 티켓에 업무의 종류와 우선순위를 나타내는 레이블을 붙였고, 계획하지 않은 운영 업무에는 별도의 레이블을 남겼다. 우리가 느린 것인지, 계획하지 않은 일이 계속 들어와 집중이 깨지는 것인지 구분해서 말할 수 있어야 했다.

세 번 정도 스프린트를 반복하자 이전에는 감각으로만 알고 있던 문제가 기록으로 보이기 시작했다.

우리 팀에는 운영 업무가 너무 많았다.

그전에도 긴급 요청이 많아 계획한 일에 집중하기 어렵다고 말할 수는 있었다. 하지만 근거가 없었다. 레이블을 붙이고 기록한 뒤에는 어떤 종류의 일에 시간이 사용되고 있는지 설명할 수 있었다.

비밀번호 초기화와 계정·권한 관리처럼 운영 조직이 맡는 것이 적절한 업무를 정리해 운영팀으로 이관했다. 반복되는 수정은 모두 같은 방식으로 처리하지 않았다. 요청 빈도가 충분히 높고 운영에서 직접 다루는 편이 효율적인 일은 백오피스화를 추진했다. 반대로 백오피스를 만드는 비용이 더 커 보이는 작업은 공통 컴포넌트로 만들어 개발팀이 짧은 시간 안에 대응할 수 있게 했다.

금융사 요청에 따라 특정 기간에만 상품 목록에 배너를 노출하는 작업이 후자의 사례였다.

이런 일을 하나씩 정리하면서 당시 집계로는 팀 전체 기준 한 스프린트에 약 4일분의 가용 시간을 다시 확보할 수 있었다. 한때 60개 안팎이던 스프린트 티켓 수도 10개에서 20개 정도로 줄었다.

그 숫자를 곧바로 생산성 향상이라고 부르고 싶지는 않다. 운영팀으로 이관된 업무가 있었고, 반복 작업을 처리하는 방식이 달라졌으며, 보드에서 관리하는 일의 범위도 이전과 같지 않았기 때문이다.

다만 한 가지 변화는 분명했다. 팀이 직접 처리하지 않아도 되는 일을 걷어내고, 반복되는 일의 비용을 낮추면서 어디에 집중해야 하는지를 이전보다 잘 구분할 수 있게 됐다.

그렇게 되찾은 시간으로 미뤄두었던 App Router 전환과 성능 개선을 다루고, 팀 스터디를 이어갈 수 있었다.

처음에는 이런 일이 개발과 멀어지는 과정처럼 느껴지기도 했다. 하지만 코드를 고쳐 문제를 해결하는 것과는 다른 방식일 뿐, 병목을 찾고 반복되는 비용을 구조적으로 줄인다는 점에서는 엔지니어링과 닮아 있었다.

나는 이 새로운 종류의 문제에도 상당한 흥미를 느꼈다.

기술을 도입하는 것보다 그 가치를 설명하는 일이 어려웠다

Claude Code 사용권 도입을 위한 전사 발표를 준비할 때는 대학생 때 해커톤을 하던 것처럼 사흘 동안 밤늦게까지 논리를 다듬었다.

“AI가 좋으니 도입하고 싶습니다”라는 말로는 설득할 수 없었다.

설명해야 했던 것은 도구의 성능이 아니라 우리가 마주한 문제였다.

서비스의 도메인과 정책 복잡도는 계속 늘고 있었다. 반면 팀 규모는 줄었고, 많은 지식이 구성원의 경험과 기억에 의존하고 있었다. 지금은 어떻게든 운영되고 있더라도 같은 방식으로 더 복잡해진 서비스를 계속 감당할 수 있는지는 다른 문제였다.

발표는 현재 상황에서 출발했다. 지금 방식의 한계가 앞으로 어떤 비즈니스 위험을 만들 수 있는지 설명하고, AI를 그 위험을 줄일 수 있는 하나의 방향으로 제시했다. 마지막으로 추가 채용과 비교했을 때의 비용과 기대 효과를 설명했다.

승인 과정에서는 추가 채용 TO 한 자리와 비교해야 하는 현실적인 비용도 있었다. 그러면서도 나는 AI 도입을 개발자 대체가 아니라 현재 팀의 역량을 확장하는 투자라고 설명했다.

그 두 문장은 완전히 편안하게 양립하지 않았다.

도입을 결정한다는 것은 좋은 면만 선택하는 일이 아니었다. 무엇을 얻기 위해 어떤 비용을 감수할지 정하는 일이기도 했다.

가장 걱정한 질문은 이것이었다.

그래서 생산성이 얼마나 좋아지는가.

도입 전후의 내부 지표를 보면 개인당 처리한 Jira 티켓 수는 30% 이상 늘었다. 하지만 이 숫자만으로 AI가 생산성을 30% 높였다고 말할 수는 없었다. 같은 기간에 운영 업무를 이관했고, 티켓 분류와 플래닝 방식도 바꿨다. 반복 작업을 처리하는 구조도 개선했고, 티켓마다 업무의 난도 역시 달랐다.

여러 변화가 동시에 일어났는데 그 결과를 하나의 도구에 돌리는 것은 정확하지 않았다.

오히려 이 경험을 통해 알게 된 것은, 새로운 도구를 도입하기 전에 우리가 어떤 일을 하고 있는지부터 설명할 수 있어야 한다는 사실이었다. 작은 오류가 수정으로 끝나 기록에 남지 않는 경우를 줄이고, 오류의 심각도와 처리 기준을 정리한 것도 같은 이유였다.

일을 잘하는 것만으로 충분하지 않았다. 그 일이 왜 필요했고, 무엇이 달라졌으며, 앞으로 어떤 위험을 줄였는지 다른 사람이 판단할 수 있는 언어로 설명해야 했다.

예전에는 이런 일을 두고 정치라고 말하는 사람들의 마음을 잘 이해하지 못했다. 하지만 적어도 내가 경험한 범위에서 조직의 신뢰를 얻는 일은 성과를 부풀리는 것과 달랐다.

보이지 않던 일을 기록하고, 다른 조직이 판단할 수 있는 언어로 설명하고, 문제가 생겼을 때 숨기지 않는 일에 가까웠다.

좋은 결과를 만드는 일과 그 결과가 신뢰받게 만드는 일은 별개의 일이었다.

질문을 많이 한다고 진실에 가까워지는 것은 아니었다

팀 문화를 만드는 과정에서도 시행착오가 많았다.

우리 팀은 애자일 방식으로 일하고 있었지만 회고는 제대로 자리 잡지 못한 상태였다. 바쁜 스프린트가 끝난 뒤 뻔한 이야기를 반복하는 회고라면 하지 않는 편이 낫다는 의견도 있었다. 나 역시 형식만 채우는 회고는 원하지 않았다.

그래서 PMI, KPT, 5 Whys처럼 여러 방식을 찾아 시도했다. 피그잼에 템플릿을 만들고, 조금이라도 편한 분위기를 만들려고 음료를 준비하기도 했다.

장애 회고 날, “왜 이 테스트 케이스를 놓쳤는가”에서 시작된 질문은 세 번째 “왜”에 이르러 “왜 배포 전 한 번 더 확인하지 않았는가”라는 추궁으로 변해 있었다. 회의실 정적이 길어졌고, 동료의 표정은 어두워졌다.

원인을 찾는다는 명목 아래 내가 던진 질문들이 상대를 방어적으로 만들고 있었다.

나는 질문을 더 하면 진실에 가까워질 것이라고 생각했다.

하지만 사람이 자신을 방어하기 시작하면 질문을 많이 한다고 더 정확한 답이 나오는 것은 아니었다. 오히려 상대가 그 자리에서 가장 안전하다고 느끼는 설명만 남을 수 있었다.

실수해도 괜찮다고 팀에 말해온 사람이 나였다.

문제는 5 Whys라는 방법론 자체가 아니었다. 그것을 사용하던 나의 태도였다. 시스템이 왜 실수를 막지 못했는지 살펴보기 전에, 누군가가 왜 그런 선택을 했는지부터 반복해서 설명하게 만들고 있었다.

그 뒤로 회고에서 가장 중요하게 생각한 것은 좋은 질문의 개수보다 솔직하게 이야기해도 안전하다고 느낄 수 있는 분위기였다. 회고가 좋은 대화로 끝나지 않도록 실제로 실행하고 확인할 수 있는 작은 액션 아이템도 남기려고 했다.

리드가 된 뒤 나는 답을 주는 것만큼 질문을 만드는 일이 중요하다고 생각하게 됐다.

동시에 질문도 잘못 사용하면 답을 찾는 도구가 아니라 상대를 몰아세우는 도구가 될 수 있다는 것을 배웠다.

어디까지 결정하고 어디서부터 기다릴 것인가

지난 1년 동안 애자일 리드로 일하며 가장 많이 고민한 것은 프론트엔드 개발자들이 어떻게 더 생산적으로 일하고, 각자의 성장 방향을 찾을 수 있게 도울 것인가였다.

생산성을 가로막는 반복 업무를 줄였다. 팀 스터디를 이어갈 수 있는 시간을 만들려고 했다. 코드리뷰의 부담을 낮추는 도구도 팀과 함께 다듬었다.

하지만 구현 속도가 빨라질수록 다른 문제가 더 중요해졌다.

왜 이 구조를 선택해야 하는가. 정책이 바뀌면 어디를 수정해야 하는가. 코드베이스 밖의 네이티브 앱과 인프라 상황은 어떤가. 테스트하기 쉬운가. 지금 빠르게 만드는 선택이 다음 변경에서 어떤 비용을 만들 것인가.

AI는 초안을 빠르게 만들고 반복 작업을 줄여줬지만, 이런 질문에 대한 책임까지 대신 져주지는 않았다.

그래서 봇을 도입했어도 사람의 리뷰를 없애지는 않았다. 봇은 변경 내용을 빠르게 파악하고 기본적인 문제를 먼저 살펴보는 도구였다. 마지막 판단과 책임은 여전히 팀의 몫이었다.

리드의 역할도 조금씩 다르게 보이기 시작했다.

모든 코드의 정답을 직접 알려주는 사람이 아니라, 팀원이 스스로 판단할 수 있도록 맥락과 기준을 공유하는 사람이 되어야 했다.

말처럼 쉽게 되지는 않았다. 내가 대신 결정하는 것이 당장은 훨씬 빠른 경우가 많았다. 일이 쌓일수록 그 유혹은 커졌다. 실제로 나는 많은 답을 직접 내렸고, 그만큼 바빠졌으며, 새로운 종류의 업무에 재미를 느끼면서도 꽤 지쳤다.

지난 1년 동안 내가 가장 많이 씨름한 문제는 AI를 얼마나 많이 사용할 것인가가 아니었다.

내가 어디까지 직접 결정하고, 어디서부터 팀원이 판단하도록 기다릴 것인가에 가까웠다.

리드로 성장할수록 다시 IC가 되고 싶어졌다

리드 역할은 생각보다 재미있었다.

코드만 보던 시선에서 벗어나 팀의 업무 흐름과 조직의 우선순위를 보게 됐다. 팀원이 어떤 조건에서 잘 일하는지도 조금씩 알게 됐다. 목표와 방향이 분명할 때 놀라운 집중력으로 계획과 문서를 만들어내는 사람이 있었고, 내가 놓친 문제를 짧은 관찰로 발견하는 사람도 있었다.

기술적인 답을 많이 알고 있는 것만큼, 팀원이 의견을 내고 스스로 결정할 수 있는 조건을 만드는 일이 중요하다는 것도 알게 됐다.

동료들이 내가 기울인 노력을 알아봐주고, 팀이 이전보다 건강해졌다고 말해줬을 때 특히 기뻤다. 혼자 좋은 리드가 되려고 애쓴 시간이 아니라 함께 좋은 팀을 만들어온 시간으로 받아들여지는 것 같았다.

그런데 프론트엔드 개발자로서 앞으로 어디로 가야 하는지는 계속 불분명했다.

《리드 개발자로 가는 길》에는 현대 소프트웨어 생태계에서 각 분야의 기술적 깊이가 깊어졌기 때문에 영역별 전문 리드가 필요하다는 대목이 있다. 백엔드 중심의 리드가 상태 관리와 렌더링 최적화, 빌드 툴체인 같은 프론트엔드의 복잡성을 모두 커버하기는 어렵다는 것이다.

이 장은 내가 왜 필요한 사람인지 설명해줬다. 동시에 내가 왜 배울 곳이 없는지도 설명하고 있었다.

조직에는 경험 많은 다른 직무의 개발자들이 있었고, AI를 통해 기술 지식을 공부하기도 쉬워졌다. 하지만 내가 정말 배우고 싶은 것은 지식만이 아니었다.

더 복잡한 프론트엔드 문제를 먼저 통과한 사람의 판단 과정, 기술적인 선택의 기준, 내가 미처 보지 못한 약점을 가까이에서 보고 싶었다.

지난 1년 동안 나는 팀원이 스스로 판단할 수 있도록 맥락과 기준을 공유하는 일에 많은 시간을 썼다. 그러면서 어느 순간 알게 됐다. 정작 나에게 그렇게 해줄 사람은 조직 안에 없었다는 것을.

그래서 지금 내가 원하는 것은 당분간 다른 팀에서 같은 리드 역할을 반복하는 일이 아니었다.

내가 기준을 제시하는 사람으로 서기보다, 더 복잡한 프론트엔드 문제를 먼저 겪어본 리드와 동료의 기준 안에서 내 판단을 다시 검증받고 싶었다. 내가 어렵게 만든 기준이 다른 사람의 리뷰 앞에서 쉽게 깨지고, 당연하다고 생각했던 선택을 다시 설명해야 하는 환경에 나를 놓아보고 싶었다.

리드에서 IC로 옮기는 일이 뒤로 가는 선택처럼 보일 수도 있다.

하지만 나에게는 책임을 줄이기 위한 이동보다 성장의 초점을 바꾸는 선택에 가깝다. 지난 1년 동안 다른 사람의 성장 조건을 고민했다면, 이제는 나도 다시 누군가의 질문을 받고, 더 어려운 문제 앞에서 오래 헤매며 기술적인 기준을 넓히고 싶다.

함께 일한 동료들의 역량이 부족해서 내린 결론은 아니다. 회사가 필요로 하는 프론트엔드의 역할과 내가 다음으로 깊게 배우고 싶은 역할 사이에 조금씩 거리가 생기고 있었다.

남아도 될 이유가 너무 많았다

그런데도 오래 망설였다.

회사가 싫어서 떠나고 싶은 것이 아니었다. 오히려 회사가 너무 편하고 좋았기 때문에 더 오래 고민했다. 지금까지 쌓아온 관계와 신뢰를 두고 낯선 곳으로 가는 선택은 합리적이지 않아 보일 때도 많았다.

그 무렵 읽은 《퀴팅》이 이 망설임에 이름을 붙여줬다.

우리가 발이 묶이는 이유로 이 책이 꼽는 것은 두 가지다. 그동안 쏟아부은 시간과 노력이 아까워서 놓지 못하는 매몰 비용의 함정, 그리고 그동안 쌓아온 정체성과 주변의 기대에 맞추려다 변화를 두려워하게 되는 타인의 시선.

첫 번째 문장에서 이 글의 첫 문단으로 되돌아갔다.

내가 남아야 할 이유로 꼽았던 것들은 대부분 이미 지불한 비용이었다. 4년 동안 쌓은 관계와 지식, 익숙한 인프라, 30분이면 닿는 거리. 전부 진짜 가치가 있는 것들이지만, 앞으로 내가 무엇을 배울 수 있는지에 대한 답은 아니었다.

두 번째 문장은 더 아팠다. 리드에서 IC로 돌아가는 일이 뒤로 가는 선택처럼 보일까 봐 오래 망설였기 때문이다. 그런데 그 시선은 내 다음 5년을 대신 책임져주지 않는다.

책에는 바우어새 이야기가 나온다. 동물은 장애물에 막히면 미련 없이 전략을 바꿔 다른 방법을 찾는다. 사람만 미련과 두려움 때문에 애매한 상태를 오래 끌고 간다는 것이다.

내가 하고 있던 것이 그 애매한 상태였다. 회사가 싫지 않았고 일도 재미있었고, 그래서 아무것도 바꾸지 않은 채로 질문만 커지고 있었다.

퇴사 절차를 마치고 나서 곧바로 다음 회사로 가지는 않기로 했다. 그동안 미뤄둔 몸 상태를 살피고, 결혼을 준비하고, 숨 가쁘게 지나온 1년이 내게 무엇을 남겼는지 천천히 확인하려고 한다.

《퀴팅》은 인생을 한자리에 고정시키는 닻을 걷고 원하는 방향으로 나아가는 돛을 달 때 다음 챕터가 시작된다고 말한다.

지금 나는 닻을 걷은 참이다. 돛은 아직 방향을 정하는 중이다.

집요함의 방향을 바꾸는 일

돌이켜보면 지난 1년은 개발자로서 나를 성장시킨 성향을 버리는 시간이 아니었다.

나는 여전히 문제를 깊게 파고드는 사람이다. 기술적으로 흥미로운 주제를 만나면 끝을 보고 싶고, 동료가 막혀 있으면 함께 답을 찾고 싶다. 그 성향은 앞으로도 쉽게 바뀌지 않을 것이다.

다만 리드가 된 뒤에는 집요함이 향해야 할 대상이 달라졌다.

내가 직접 문제를 푸는 것보다 왜 같은 문제가 반복되는지 살펴봐야 했다. 일이 많으면 더 열심히 처리하기보다 어떤 일이 팀의 집중을 빼앗는지 기록해야 했다. 모든 PR을 직접 보려 하기보다 팀이 함께 판단하기 위해 필요한 기준이 무엇인지 고민해야 했다. 장애의 원인을 끝까지 묻는 것만큼 사람들이 솔직하게 이야기할 수 있는 환경도 지켜야 했다.

지난 1년 동안 나는 좋은 개발자에서 좋은 리드로 완전히 변한 것이 아니다. 아직도 직접 답을 내리는 편이 더 편하고, 기술적인 완성도를 놓기 어려우며, 일이 많아지면 모든 것을 혼자 챙기려는 습관이 나온다.

그래도 한 가지는 이전보다 분명하게 알게 됐다.

성장은 내가 잘하는 방식을 더 강하게 만드는 일만은 아니었다. 내가 가진 강점이 언제 팀의 병목이 되는지 알아차리고, 그 힘이 향하는 방향을 바꾸는 일이기도 했다.

이제 다시 프론트엔드 IC의 역할에 집중하려는 것도 지난 1년을 되돌리는 선택은 아니다.

리드로 일하며 얻은 시야를 가지고 다시 코드 가까이로 내려가고 싶다. 하나의 기술적 선택이 팀의 업무 방식과 서비스의 운영에 어떤 영향을 주는지 함께 보면서, 더 깊은 프론트엔드 문제를 직접 통과하고 싶다.

이번에는 답을 주는 사람으로만 남기보다, 내가 내린 답이 자주 깨질 수 있는 환경으로 가고 싶다.

내가 회사를 떠나는 이유는 이곳에서 배운 것이 적어서가 아니다.

더 배우고 싶다는 마음을 더는 모른 척할 수 없었기 때문이다.