3년 차, 개발 습관 돌아보기
5년 만에 구글에서 수석 개발자가 된 방법 - 이한결
우연히 유튜브에서 5년 만에 구글에서 수석 개발자가 된 방법 - 이한결 | 주인공들의 이야기를 보게 됐는데, 너무 좋은 내용들이 많았다. 이 글에서는 영상 내용의 일부를 정리하면서 나의 생각들을 덧붙이려 한다.
커리어를 시작하는 개발자가 가져야 하는 마인드 셋
업무를 처음 시작하는 사람들에게는 Expectation Management—즉, 업무가 언제 끝날지 관리하고 예측하는 능력—를 가장 중요한 역량으로 이야기한다. 많은 공감이 갔다.
내가 신입 개발자로 일을 시작했을 때, 이 점을 제대로 이해하지 못해 고된 경험을 했다. 초기에는 규모가 작은 작업을 맡아, 개발 시간을 늘려가면서 그럭저럭 성공했다. 그러나 그 기간에 나는 Expectation Management를 개선하지 않았다. 단순히 "시간을 많이 들이면 해결된다"는 안일한 생각을 유지한 채, 보다 큰 프로젝트를 맡게 되자 큰 시련을 겪었다.
영상에서는 파이 룰—내가 예측한 시간에 3.14를 곱한다—을 소개해 주는데, 본질적으로 Expectation Management를 향상시키는 것이 중요하다고 생각한다. 나는 이와 같은 어려움을 겪는 이들에게 문제를 가능한 작은 단위로 쪼개고, 각 단위별로 시간을 예측하는 연습을 강력 추천한다. 예를 들어, 서버 데이터를 받아와 화면을 구성하는 작업이 주어졌다면, 뷰 컴포넌트 1, 뷰 컴포넌트 2, 탭 랜딩, 특정 API 추가, UI 매핑, 메인 로직 작성, 테스트 코드 작성, 접근성, 여러 디바이스 대응 등으로 세분화하여 각각의 예상 시간을 측정해 보는 방식이다. 나는 과하다 싶을 정도로 작업을 세세하게 쪼개보고, 더 큰 단위로 묶어도 되겠다는 판단이 들 때 점차 조정해 나갔다.
또한, 이 영상에서 소개된 내용 중 신입 때 알았더라면 좋았을 부분은 "얼마나 걸릴 것 같아?"라는 질문에 바로 대답할 의무가 없다는 점이다. 즉각적인 답변 대신, "조금 조사해 보고 오늘 퇴근 전까지 답변드리겠습니다."라고 말하는 것이 더 현명하다. 이는 신입이 초반에 누릴 수 있는 면책권일 수 있지만, 이를 빨리 깨우치는 것이 중요하다.
빅테크 수석 개발자가 알려주는 일(코딩) 잘하는 방법
(1) Context Switching
개발 중 가장 힘든 순간 중 하나는 깊이 몰입해 코드를 작성하던 도중 다른 일로 호출되는 컨텍스트 스위칭이다. 중간에 끊겼다가 다시 코딩에 몰입하기 위해서는 큰 비용이 따르기 때문에, 이를 효과적으로 관리하는 것이 중요하다. 이를 위해 프로젝트의 요구사항을 세분화하고, 각 스텝을 상세하게 나눈 후 코딩을 시작하는 것이 필요하다. 이 첫 번째 단계에서는 관계자들과 충분히 논의해야 하며, 이 과정에서 많은 블로킹 모먼트가 생기게 된다. 따라서, 이러한 시간을 어떻게 관리하느냐도 중요하다.
또한, 개발 중간에 들어오는 질문이 있을 때 중요한 이슈가 아니면 무시할지 판단하는 것도 중요하다고 얘기한다. 특히 집중이 필요한 순간에는, 주요 변경 사항을 작은 체크포인트로 나눠 정리해 두는 것이 유용하기에 앞서 이야기한 개발 아웃라인을 잡는 과정이 중요하다. 이렇게 하면 코드 작성 중간에 끊기더라도 쉽게 이어나갈 수 있다.
초반 개발 아웃라인을 잡기 위해, 관계자들과 커뮤니케이션하고 블로킹된 시간들을 효율적으로 사용하는 연습을 더 적극적으로 해야겠다는 생각이 든다.
(2) 작은 PR 단위
체크포인트 설정의 결과물로 나오 것이 작은 PR이다. 코드 리뷰 시, 전체 변경 사항이 2000줄이라고 가정해 보자. 이를 100줄 단위로 자연스럽게 나누고 이 작은 덩어리만으로 안전하게 잘 넣을 수 있도록 플래닝하는 것이 중요하다. 한결님은 각 PR의 기능 변경 사항은 100줄 이하로, 단위 테스트는 많이 작성하여, PR이 쉽게 Approve되는 것에 집착하신다고 얘기한다.
이 부분은 영상을 시청하면서 특히 즐거웠던 부분이다. 나는 운 좋게 좋은 사수를 만나 강도 높은 코드리뷰와 함께 개발을 시작했고 그 과정에서 고민했던 것들이 이 영상의 내용과 일치했다. 이는 단순히 팀원들로부터 PR Approve를 쉽게 받기 위한 방법일 뿐만 아니라, 예상된 개발 시간을 지키고 자신에게 심리적 안정감을 주는 방식이기도 하다.
작은 PR로 나누는 것은 업무를 작게 나누는 것을 넘어서는 심화 과정이 필요했다. 자연스럽게 읽기 좋은 PR의 순서와 실제 개발 순서를 일치시키는 것은 꽤 어렵게 느껴졌다. 개발 도중 길을 잃고, 모든 커밋을 reset한 뒤 처음부터 다시 나누는 상황도 자주 있었다. 읽기 좋은 PR의 순서와 개발 순서를 맞추는 연습을 의도적으로 반복한 끝에, 전체 reset 없이 몇 번의 rebase로 수정할 수 있게 되었고, 반복되는 요구사항들은 머릿속에서 자연스럽게 개발 순서가 정해질 수 있었다. 빠른 Approve가 가능한 PR은 항상 나에게 가장 높은 우선순위이다.
이러한 습관은 조직 차원에서 길러져야 한다. PR을 작고 명확하게 나누는 습관은 엔지니어링 조직을 건강하게 성장시키는 데 필수적이다. 조직에서 이러한 기준을 요구하고, 본인 또한 같은 기준에 맞춰 평가받으면 조직은 더욱 건강하게 성장할 수 있다.
이직과 성장의 상관관계
한 조직에 오래 머무른 분들에게 이직을 추천한다고 얘기한다. 페이스북에 계셨던 한결님은 그 당시 "play nice" 하라는 피드백을 자주 받으셨다고 한다. 예전에 페이스북에서 스태프 역할을 수행할 때는 신규 입사자가 코드를 작성하지 않고 다이어그램을 만드는 모습을 보고 강하게 얘기하기도 했다. 하지만 회사를 옮기고 나니, 페이스북만의 문화였을 뿐, 다른 회사들은 디자인과 기획 단계에 상당한 시간을 투자한다는 것을 알게 되었다. 구글에서는 스태프 레벨에 적응하는 데 1~2개월 정도의 시간이 필요했을 정도로 문화가 달랐었다.
편안한 공간에서 벗어나 새로운 자극을 받으면 Fast Growth의 시간이 오게 된다. 리더십 구성이나 시스템은 영원하지 않기에, 어느 상황에서도 일정한 성과를 낼 수 있는 능력을 기르려면 익숙한 환경을 벗어나 보는 경험을 가져보는 것이 좋다.
최고의 테크 회사들이 시니어 개발자들에게 바라는 모습
이 부분을 보면서, 앞으로 경력이 쌓일수록 단순한 코드 머신으로 빠지지 않기 위한 노력이 꾸준히 필요함을 느꼈다. 어떠한 엔지니어 지향점을 갖든 간에 높은 레벨로 올라갈수록 다양한 역량을 요구받는다. 아래는 간략히 정리한 내용인데 자세한 내용은 영상의 6:44부터 참고하면 좋다.
개발자의 연차와 역량이 쌓이면서 회사는 더 큰 범위의 문제 해결을 기대하게 된다. 특히 시니어 개발자에게는 개별 기능의 End-to-End 책임을 넘어, 시스템 단위의 End-to-End를, 더 나아가서는 전체 기술 생태계를 아우르는 책임을 요구한다.
이와 같은 기대가 구체적으로 어떤 의미인지에 대해서는 다양한 해석이 존재하기에, Facebook 같은 기업에서는 시니어 개발자들이 선택할 수 있는 ArcheType을 정의한다. 한결님이 언급하신 ArcheType 중 Code Machine, Product Engineering Hybrid, Generalist를 정리해 보자.
(1) Code Machine
엄청난 코딩 아웃풋을 보유한 개발자들이다. 레벨이 높아짐에 따라 코딩 머신으로서 인정을 받으려면 정말로 많은 코드를 짤 수 있어야 한다. 이에 따라 해당 코드의 필요성을 명확히 하여 팀이나 코드 리뷰어들에게 설득할 수 있는 명분을 만들어야 한다. 이들은 코드로서 명분을 만드는 사람들이다.
(2) Product Engeneering Hybrid
Facebook의 모토인 Move Fast에 가장 부합하는 ArcheType이다. 제품과 엔지니어링 두 분야 모두에 통찰력을 가지고 문제를 해결하는 역할을 맡는다. 이들은 단기간에 최적의 방향을 제시하고 실행하며, 프로젝트의 가능성을 빠르게 판단한다.
(3) Generalist
서버와 클라이언트를 모두 아우르는 풀스택 기술을 보유하여 다양한 태스크를 조율한다. Generalist는 직군이 다양한 20-30명의 팀을 관리하며, 매니저와는 차별화된 역할을 수행한다. 매니저가 팀 운영을 맡는다면, Generalist는 엔지니어링과 협업의 중심을 잡아주는 역할을 한다.
또한, 팀원들의 개인 목표를 파악하는 일은 매니저뿐만 아니라 엔지니어에게도 중요한 일이다. 회사가 커짐에 따라 모든 팀 구성원이 동일한 컬처핏을 갖추기는 어렵기에, 각 구성원의 목표와 필요를 이해하고, 이에 맞는 성장을 지원하는 것이 중요하다.
연차가 쌓일수록 엔지니어링의 역할은 단순한 기술적 기여를 넘어서 소셜 엔지니어링, 즉 팀원과의 협력과 이해가 필요한 영역으로 확장된다.
