작년 이맘때쯤, 나는 PR 하나를 3일 동안 붙잡고 있었다.

장바구니 페이지의 쿠폰 적용 로직을 리팩토링하는 작업이었는데, 코드를 고치다 보니 "이왕 하는 거 좀 더 깔끔하게" 하고 싶어졌다. custom hook을 분리하고, 타입을 좀 더 엄격하게 잡고, 에러 핸들링 케이스를 하나하나 다 처리하려다 보니 변경된 파일이 14개가 됐다. 그리고 코드를 다시 보니까 또 마음에 안 드는 부분이 보였다. 끝이 없었다.

3일째 되는 날 아침, 팀 리드가 스탠드업에서 물었다. "쿠폰 건 어디까지 됐어?" 나는 "거의 다 됐는데 좀 더 정리하고 있어요"라고 대답했다. 잠깐 뜸을 들이더니 이렇게 말했다.

"지금 올려. 완벽할 필요 없어. 리뷰 받으면서 고치는 거야."

"완벽한 코드"라는 환상#

그 말을 듣고 바로 PR을 올렸다. 리뷰가 왔다. 지적은 3개였다. 내가 3일 동안 고민한 구조적인 부분은 아무도 언급하지 않았다. 대신 내가 미처 생각 못 한 edge case 하나, 네이밍 하나, 불필요한 re-render 하나가 지적됐다. 30분 만에 수정하고 머지했다.

3일 동안 혼자 코드를 갈아엎고 있었던 시간이 허무했다.

돌이켜보면 1년 차 때 나는 PR을 올리는 행위 자체를 "내 실력을 보여주는 것"이라고 생각했다. 코드 리뷰에서 지적받는 건 내 실력이 부족하다는 뜻이라고. 그래서 최대한 완벽하게 만들어서 올리려고 했다. 근데 현실은 정반대였다. PR을 빨리 올리는 사람이 더 많이 배운다. 리뷰어의 시간을 아끼는 작은 PR이 14개 파일짜리 거대한 PR보다 훨씬 가치 있다. 그리고 무엇보다, 머지되지 않은 코드는 아무런 가치를 만들지 못한다.

지금은 이렇게 한다. 일단 동작하는 최소 단위로 PR을 올린다. 개선할 부분이 보이면 후속 PR로 분리한다. "이건 좀 더 다듬어서"라는 생각이 들면 그게 바로 올려야 할 타이밍이라는 신호다.

질문에도 급이 있다#

1년 차 초반에 나는 질문을 이렇게 했다.

"이 API 응답 구조가 좀 이상한데, 어떻게 처리하면 되나요?"

시니어분이 친절하게 알려줬다. 그런데 한 달쯤 지나니까 비슷한 상황에서 또 같은 질문을 하고 있는 나를 발견했다. 스스로 생각하는 근육이 안 생긴 거다.

전환점은 다른 팀 동기랑 점심 먹다가 온 대화였다. "나 요즘 질문 방식 바꿨는데 반응이 확 달라졌어"라고 했다. 방법은 간단했다. 질문하기 전에 두 가지 선택지를 먼저 만드는 것이다.

그 뒤로 나도 바꿨다. "이거 어떻게 해요?" 대신 이런 식으로 질문했다.

"이 API 응답에서 null이 올 수 있는데, A) 프론트에서 Optional chaining으로 처리하는 방법이랑 B) API 레이어에서 default value를 넣어주는 방법 중에 고민이에요. A가 나은 것 같은 게, 서버 응답 스펙이 바뀔 때마다 API 레이어를 수정할 필요가 없어서요. 근데 B가 더 안전한 건지 잘 모르겠어요."

변화가 즉각적이었다. 시니어분의 대답도 달라졌다. "A로 가되 이런 케이스는 조심해"처럼 구체적인 방향을 바로 줬다. 이전에는 내 상황을 파악하는 데 5분, 설명하는 데 10분이 걸렸던 대화가 2분 만에 끝났다.

이게 왜 효과적인지는 나중에야 이해했다. 선택지를 준비하는 과정 자체가 이미 문제를 절반은 풀고 있는 것이다. 가끔은 선택지를 정리하다가 답을 스스로 찾기도 한다. 그러면 질문 자체가 필요 없어진다. 그게 제일 좋은 경우다.

코드를 짜는 능력보다 코드를 읽는 능력#

입사하고 처음 받은 업무가 새 기능 개발이 아니었다. 6개월 전에 퇴사한 분이 만든 결제 위젯의 버그 수정이었다. 파일을 열었을 때의 그 막막함이 아직도 생각난다.

컴포넌트가 하나의 파일에 400줄이었다. 주석은 없었다. 변수명은 temp, data2, flag 같은 것들이 섞여 있었다. 상태가 어디서 바뀌는지 추적하려면 3개 파일을 왔다 갔다 해야 했다. 나는 속으로 "이걸 누가 이렇게 짰어"라고 투덜거렸다.

그런데 1주일 동안 그 코드를 계속 읽다 보니 패턴이 보이기 시작했다. 그 분 나름의 규칙이 있었다. data2는 서버에서 온 원본 데이터를 변환한 버전이었고, flag는 결제 수단 전환 시 사용하는 토글이었다. 네이밍이 구려서 그렇지, 로직 자체는 꽤 합리적이었다. 아마 빠듯한 일정에 쫓기면서 짠 코드였을 거다.

그때 배운 게 있다. 새 코드를 잘 짜는 것보다 남의 코드를 잘 읽는 게 주니어한테는 훨씬 중요한 스킬이라는 것. 현실적으로 주니어가 처음부터 설계하는 일은 거의 없다. 대부분의 시간은 기존 코드 위에 무언가를 쌓거나, 누군가가 남긴 코드를 고치는 데 쓴다. 읽기 능력이 없으면 그 위에 아무것도 올릴 수가 없다.

내가 쓰는 방법은 단순하다. 처음 보는 코드베이스를 읽을 때, 일단 진입점을 찾는다. 사용자가 버튼을 클릭하면 어떤 함수가 불리는지부터 시작해서, 데이터가 흘러가는 방향을 따라간다. 이해한 부분은 주석으로 메모를 남긴다. 나중에 그 주석은 지우더라도, 읽는 과정에서 머릿속에 지도가 그려진다.

기술 부채에 대한 오해#

"기술 부채는 나쁘다"라고 단정짓던 때가 있었다.

팀에서 레거시 코드를 리팩토링하자는 이야기가 나올 때마다, 나는 적극적으로 찬성했다. "이 코드 구조가 좋지 않으니까 바꿔야 합니다." 2년 차 초반에 한번은 PO(Product Owner)에게 리팩토링 필요성을 설명하다가 이런 답변을 들었다.

"그래서 그걸 지금 하면 유저한테 뭐가 달라지는데?"

대답을 못 했다.

그 뒤로 기술 부채를 다르게 보게 됐다. 부채에는 두 종류가 있다. 하나는 "우리 지금 이렇게 하면 나중에 문제 될 줄 알지만, 이번 스프린트에 출시하려면 이 방법밖에 없어"라는 의도적인 부채. 다른 하나는 "이렇게 하면 안 되는 줄 몰랐어"라는 무지에 의한 부채다.

의도적인 부채는 비즈니스 판단이다. 지금 출시하는 게 나중에 리팩토링하는 비용보다 가치가 크다면, 그건 합리적인 선택이다. 반대로, 무지에 의한 부채는 쌓이기만 하고 언제 터질지 모르는 시한폭탄이다. 같은 "안 좋은 코드"라도 맥락이 완전히 다르다.

지금은 리팩토링을 제안할 때 이렇게 말한다. "이 부분이 다음 분기에 결제 수단 추가할 때 병목이 될 것 같은데, 지금 구조를 바꿔두면 그때 작업 시간을 반으로 줄일 수 있을 것 같아요." 비즈니스 임팩트로 번역하는 거다. 이게 통한다.

사이드 프로젝트가 가르쳐 준 것#

회사에서는 배울 수 없는 게 하나 있다. 처음부터 끝까지 혼자 결정하는 경험이다.

회사에서는 보일러플레이트가 이미 있고, 폴더 구조가 정해져 있고, 쓰는 라이브러리가 정해져 있다. 나는 그 틀 안에서 일한다. 그래서 "왜 이 라이브러리를 쓰는지", "왜 이 구조인지"를 깊이 생각해본 적이 없었다.

작년 가을에 개인 블로그를 만들기로 했다. Next.js는 회사에서 쓰니까 익숙했다. 근데 첫 번째 선택부터 막혔다. App Router를 쓸까 Pages Router를 쓸까. 회사에서는 이미 정해진 거였으니까 고민한 적이 없었다. MDX를 어떻게 처리할지, 스타일링은 뭘 쓸지, 배포는 Vercel로 할지 Cloudflare로 할지. 전부 내가 결정해야 했다.

재미있었던 건, 그 과정에서 "정답이 없다"는 걸 체감한 거다. 기술 선택에 정답은 없고 trade-off만 있다는 말을 머리로는 알고 있었는데, 직접 고민하니까 진짜로 느껴졌다. Tailwind를 고른 이유, contentlayer 대신 next-mdx-remote를 고른 이유, 전부 나만의 근거가 생겼다. 회사에서 "왜 이거 쓰세요?"라고 물어보면 이전에는 "원래 있던 거라서요"라고 대답했을 텐데, 이제는 각 선택의 장단점을 말할 수 있게 됐다.

그리고 한 가지 더. 사이드 프로젝트는 완성해야 의미가 있다. 나도 이전에 3개쯤 중간에 접은 프로젝트가 있다. 새 기술 써보는 게 목적이면 튜토리얼이면 충분하다. 사이드 프로젝트의 진짜 가치는 "이 정도면 됐다"라고 판단하고 세상에 내놓는 경험에 있다. 그 판단이 회사에서 feature를 ship하는 감각과 직결된다.

이 글에 쓴 다섯 가지를 1년 차 때의 나한테 보여줬으면 좀 달랐을까. 아마 읽고도 제대로 이해 못 했을 것 같다. 결국 직접 부딪혀야 체감하는 것들이니까.

다만 한 가지, "PR을 빨리 올려라"는 진짜 첫날부터 알았으면 좋겠다. 그것만 알았어도 아꼈을 시간이 꽤 된다.