입사 첫날, 맥북을 받고 개발 환경을 세팅하는데 README에 적힌 대로 했는데 안 됐다. Node 버전이 달랐다. 슬랙에서 물어보려는데 어느 채널에 물어봐야 하는지도 몰랐다. 옆자리 동료한테 조심스럽게 물어봤더니 "아 그거 README가 오래됐어요, 잠깐만요" 하고 5분 만에 해결해줬다. 그 5분이 고마우면서도, 내가 이렇게 아무것도 모르는 사람이 됐다는 게 묘하게 불편했다.

전 회사에서는 코드베이스를 거의 외우고 있었다. 어떤 컴포넌트가 어디서 쓰이는지, API 응답 구조가 어떤지, 심지어 어떤 코드가 왜 이상하게 생겼는지까지 다 알았다. 그런 사람이 갑자기 "이 프로젝트 폴더 구조가 뭔가요"부터 시작해야 하는 건 생각보다 자존심이 상하는 일이다.

첫 2주: 코드보다 사람을 먼저 파악하기#

처음에는 코드를 열심히 읽었다. 출근하면 바로 에디터를 열고 컴포넌트 트리를 따라가면서 이해하려고 했다. 근데 이틀 정도 하고 나니까 깨달은 게 있다. 코드만 봐서는 "왜 이렇게 했는지"를 알 수 없다는 거다.

예를 들어 상품 상세 페이지에서 가격 표시 로직이 이상하게 복잡했다. 할인율 계산하는 함수가 3개나 있었고, 하나는 deprecated 주석이 달려 있는데 아직 쓰이고 있었다. 코드만 보면 "이거 왜 이래?"인데, 나중에 팀원한테 물어보니까 사정이 있었다. 이전에 결제 시스템을 바꾸면서 과도기에 두 개를 같이 써야 했고, 마이그레이션이 아직 안 끝났다고. 그 맥락을 모르면 코드를 아무리 오래 봐도 이해할 수 없는 부분이었다.

그 뒤로는 코드를 읽다가 이해 안 되는 부분이 나오면 먼저 git blame을 봤다. 누가 언제 수정했는지 확인하고, 그 사람한테 직접 물어봤다. "이 부분 컨텍스트가 궁금한데 잠깐 시간 괜찮으세요?"라고. 대부분 흔쾌히 알려줬다. 오히려 "아 그거 물어봐줘서 고마워, 나도 정리해야 하는데 계속 미루고 있었어"라는 반응도 있었다.

첫 2주 동안 가장 도움이 된 건 코드 리딩이 아니라 사람들과의 대화였다. 누가 어떤 도메인을 담당하는지, 의사결정은 어떤 흐름으로 이루어지는지, 팀 내에서 암묵적으로 지켜지는 규칙 같은 것들. 문서에는 안 적혀 있지만 모두가 알고 있는 것들이 꽤 많았다.

온보딩 문서를 믿지 말라는 건 아니고#

온보딩 문서가 아예 없는 건 아니었다. 노션에 꽤 잘 정리된 페이지가 있었다. 아키텍처 다이어그램도 있고, 주요 서비스 간 의존성도 그려져 있었다. 근데 문제는 이게 6개월 전 버전이라는 거다. 그 사이에 마이크로서비스 하나가 합쳐졌고, 새로운 BFF 레이어가 추가됐다. 문서상으로는 서비스 A가 서비스 B를 직접 호출하는데, 실제로는 중간에 게이트웨이를 거치고 있었다.

그래서 나는 온보딩 과정에서 알게 된 것들을 노션에 따로 정리하기 시작했다. "실제 구조"라는 이름으로. 이게 나중에 꽤 유용했는데, 나 이후에 입사한 분이 "이거 진짜 도움됐어요"라고 말해줬을 때 뿌듯했다. 작은 기여인데 의외로 임팩트가 있었다.

첫 번째 PR#

입사 후 일주일쯤 됐을 때 첫 PR을 올렸다. 버튼 컴포넌트의 disabled 상태에서 툴팁이 안 뜨는 버그 수정이었다. 코드 변경은 8줄 정도. 팀 리드가 "온보딩 중인데 벌써 PR 올렸네"라고 했는데, 솔직히 이걸 빨리 올리고 싶었던 이유가 있다.

새 회사에서 처음 머지되는 코드가 의미가 있다고 생각했다. 아무리 작아도 "이 사람이 기여한 코드가 프로덕션에 나가 있다"는 사실이 소속감을 준다. 그리고 PR 과정을 통해 팀의 코드 리뷰 문화를 파악할 수 있다. 리뷰를 얼마나 꼼꼼하게 하는지, 어떤 부분을 중요하게 보는지, 컨벤션이 어떤지. 이걸 직접 겪어봐야 감이 온다.

리뷰에서 컨벤션 관련 코멘트를 2개 받았다. 하나는 CSS 클래스 네이밍 방식이었고, 하나는 테스트 파일 위치였다. 전 회사에서 하던 방식이 몸에 배어 있어서 무의식적으로 그렇게 쓴 거였다. 이런 것도 빨리 경험할수록 좋다.

30일 차: 흐름이 보이기 시작하다#

한 달쯤 지나니까 슬랙에서 대화 흐름을 따라갈 수 있게 됐다. 처음에는 약어랑 내부 용어 때문에 무슨 말인지 절반도 못 알아들었다. "TMS에서 FE 쪽 CDC 체크해줄 수 있어?" 같은 메시지를 보면 단어 하나하나 검색해야 했다. 그게 한 달쯤 되니까 자연스럽게 이해가 됐다.

스프린트 플래닝에서도 변화가 있었다. 처음 몇 번은 그냥 듣기만 했다. 티켓 설명을 읽어도 맥락을 모르니까 "이건 얼마나 걸릴까요?"라는 질문에 답할 수가 없었다. 한 달쯤 되니까 "이 부분은 기존 컴포넌트를 재사용하면 될 것 같은데요"라는 식으로 의견을 낼 수 있게 됐다. 처음으로 플래닝에서 말을 했을 때 팀 리드가 고개를 끄덕여준 게 기억난다.

60일 차: 실수하고 배우는 시기#

두 달 차에 사고를 하나 쳤다. 스테이징 환경이라고 생각하고 API를 호출했는데 프로덕션이었다. 다행히 읽기 전용 API라서 데이터가 변경되지는 않았지만, 모니터링 대시보드에 이상한 트래픽이 찍혀서 시니어가 물어봤다. 솔직하게 말했다. "제가 환경 변수를 확인 안 하고 호출했습니다." 시니어가 "괜찮아, 나도 입사 초기에 비슷한 거 한 적 있어. 근데 앞으로는 환경 변수 확인하는 습관 들이자" 하고 넘어갔다.

이때 배운 게 있다. 실수했을 때 숨기거나 변명하지 않는 게 신뢰를 쌓는 가장 빠른 방법이라는 거다. 특히 신입일 때는 실수 자체보다 실수를 어떻게 처리하는지를 사람들이 본다. "아 이 사람은 솔직하게 말하고 같은 실수를 반복하지 않으려는 사람이구나"라는 인상을 주는 게 중요하다.

그 이후로 나는 .env 파일에 환경 이름을 콘솔에 찍는 스크립트를 추가했다. 개발 서버 켤 때마다 "현재 환경: staging"이 보이게. 사소한 건데 이걸 팀 채널에 공유했더니 다른 분이 "오 좋은데, 저도 적용해야지"라고 해서 팀 전체 세팅에 반영됐다.

90일 차: 돌아보니#

세 달이 지나고 나서야 "여기가 내 회사다"라는 느낌이 살짝 들기 시작했다. 완전히 적응한 건 아니다. 아직도 모르는 도메인이 많고, 코드베이스에서 처음 보는 패턴을 발견하기도 한다. 근데 "모르는 게 있으면 누구한테 물어봐야 하는지"는 알게 됐다. 그게 적응의 핵심인 것 같다.

돌이켜보면 잘한 것과 아쉬운 것이 있다.

잘한 것: 질문을 많이 한 것. 처음에는 "이런 것도 모르냐"고 생각할까 봐 겁났는데, 실제로 그렇게 반응하는 사람은 없었다. 오히려 "일찍 물어봐서 좋다"는 반응이 대부분이었다. 그리고 질문할 때 "이 부분을 이렇게 이해했는데 맞나요?"라는 식으로 내 이해를 먼저 말하고 확인 받는 방식이 효과적이었다.

아쉬운 것: 처음 2주 동안 너무 코드만 읽으려고 한 것. 그 시간에 팀원들이랑 점심이라도 더 먹을 걸. 코드는 어차피 매일 보게 된다. 근데 관계를 만들 수 있는 기회는 초반에 집중되어 있다. 첫 달에 "새로 오신 분이니까" 하고 먼저 다가와주는 분위기가 있는데, 그 시기를 놓치면 나중에 관계를 만드는 게 더 어렵다.

지금 이직을 앞두고 있거나 막 새 회사에 합류한 분들에게 하나만 말하자면, 첫 90일의 목표는 "뛰어난 성과를 내는 것"이 아니라 "이 사람이랑 같이 일하고 싶다"는 인상을 주는 거다. 그리고 그 인상은 대단한 기술력이 아니라 성실함, 솔직함, 질문하는 태도에서 온다.

점심의 중요성#

사소하지만 빼놓을 수 없는 게 점심이다. 처음에는 "밥 같이 드실래요?"라는 말에 "네 감사합니다" 하고 따라갔다. 누가 어떤 사람인지도 모르는 채로. 근데 이 점심 시간이 생각보다 중요했다. 업무 시간에는 못하는 가벼운 대화를 점심에 한다. 전 회사 어디 다녔는지, 주말에 뭐 하는지, 요즘 뭐에 관심 있는지. 이런 대화를 통해서 "직장 동료"가 "아는 사람"이 된다.

한 번은 점심을 먹다가 시니어 한 분이 "나 입사했을 때 이 코드베이스 보고 충격받았어"라는 얘기를 했다. 3년 전에 급하게 만든 프로토타입이 아직도 프로덕션에 살아있다는 거였다. 그 히스토리를 아는 것만으로도 코드를 이해하는 데 도움이 됐다. 점심에서 나온 얘기가 업무에 도움이 된 셈이다.

입사 초기에 하면 좋은 작은 것들#

온보딩 중에 발견한 문서 오류를 수정하는 PR을 올렸다. README의 Node 버전이 실제와 다른 것, 환경 변수 설명이 빠진 것, 더 이상 쓰이지 않는 스크립트 안내. 이런 거 하나하나 고치면서 PR을 올리면 두 가지 효과가 있다. 팀에 기여하면서 동시에 코드 리뷰를 통해 팀의 프로세스를 배울 수 있다.

그리고 궁금한 건 바로바로 물어보되, 같은 질문을 두 번 하지 않으려고 답변을 기록했다. 노션에 "QnA 로그"라는 페이지를 만들어서, 질문과 답을 쌓아갔다. 2달쯤 되니까 이게 내 개인 위키가 됐다. 가끔 기억 안 나는 거 있으면 여기서 검색한다.

물론 이건 내 경험일 뿐이고, 회사마다, 팀마다 다를 거다. 다음에 또 이직하게 되면 그때는 또 다른 교훈이 생기겠지. 그게 좀 무섭기도 하고 기대되기도 한다.