내 손으로 만든 Toss Frontend Fundamentals 코치

기준이 없었다

레벨2 들어가면서 코드리뷰가 달라졌다.

레벨1은 "작동하냐"였다면, 레벨2부터는 "왜 이렇게 짰어"가 따라온다.

처음엔 그 질문이 막막했다. 작동하는데 뭐가 문제야? 싶었다가, 피드백이 쌓이면서 알게 됐다.

작동하는 코드와 읽히는 코드는 다르다.

 

페이먼츠 2단계 PR 리뷰에서 리뷰어인 루트가 한 줄 남겼다.

"동작하는 것에만 집중해 코드 퀄리티가 아쉽다."

 

틀린 말이 아니었다. Wrapper 네이밍이 너무 포괄적이었고, 어떤 `InputWrapper`는 `useInputGroup`을 쓰고 어떤 건 직접 관리하고 있었다. 왜 그랬냐고 물어보면 대답 못했을 것 같다. 기준 자체가 없었다.

3단계에서는 루트가 다른 말을 했다. "추출이지 추상화가 아니다." 코드를 옮겼을 뿐, 왜 분리해야 하는지 이유가 없다는 거였다.

두 번 연속으로 같은 방향의 피드백을 받았다. 고치긴 했는데, 왜 그게 맞는 방향인지 설명하지 못했다.

기준이 없으면 리뷰를 받아서 고쳐도 다시 같은 자리로 돌아온다는 걸 그때 알게 됐다.

이유를 알고 코딩하고 싶다는 생각이 거기서 나왔다.

 

기준점 잡기

토스의 Frontend Fundamentals 문서를 처음 봤을 때 이거다 싶었다. (파라디 블로그 글 보고 첨 접했다. 파라디 땡큐)

가독성, 예측 가능성, 응집도, 결합도. 딱 네 가지 기준으로 좋은 코드를 정의한다.

이론서가 아니다. 나쁜 코드가 먼저 나오고, 왜 나쁜지, 어떻게 바꾸는지 예시 코드로 보여준다.

근데 읽고 끝나는 공부는 내 스타일이 아니다.

 

솔직히, 나는 개념이 먼저 오면 잘 안 붙는다.

코드를 보고 "이게 왜 이상하지?" 하는 순간에 배운다. 문제가 먼저 와야 집중된다.

스포츠를 할 때와 같다. 실제로 뛰어보고 해봐야 체화가 되고 이해가 됐지, 정적인 책이나 문서만 읽고 흡수된 건 별로 없었다.

그래서 학습 도구를 직접 만들기로 했다.

 

Claude Code 스킬을 활용해서 `/toss-ff-coach` 스킬을 만들었다.

페르소나는 10년차 토스 시니어 FE 개발자다. 가르치는 방식은 강의가 아니라 대화로 이끌어가는 식이다.

내가 코드를 붙여넣으면 "이 코드 어때 보여?"부터 시작한다. 내가 먼저 판단하고, 그걸 같이 해부한다.

절대 규칙이 두 가지다.

1. FF 문서에 없는 내용은 쓰지 않는다.
2. 답을 직접 알려주지 않는다.

두 번째가 핵심이었다. 깨달음은 스스로 만들도록 했다.

 

학습 모드는 네 가지다.

1. 코드 리뷰
2. 개념 학습
3. 퀴즈
4. 트레이드오프 토론

세션이 끝날 때 "오늘은 여기까지"라고 하면 자동으로 정리된다.

오늘 다룬 코드, 발견한 FF 이슈, 내가 스스로 도달한 깨달음만 추려서 세션 파일로 저장한다.

"스스로 도달한 것만"이 포인트다. 코치가 알려준 건 기록하지 않는다.

이 세션 파일은 Obsidian 세컨 브레인에도 쌓인다. 학습이 날아가지 않는 구조다.

 

도구를 내 손으로 만들었다. 이제 그 도구로 내 코드를 보는 눈을 만든다.

기준이 없어서 리뷰 때마다 흔들렸다면, 이제는 기준을 직접 체화하는 방식으로 바꿨다.

다음 글은 그 코치와 함께 들어간 첫 코드 개선 이야기다.