토스 Frontend Fundamentals 1회 모의고사 후기

토스 Frontend Fundamentals 모의고사란?

토스에서 실제 채용 단계에 쓰였던 과제 일부를 공개해 놓고, 지원자들이 어떤 식으로 풀었는지, 출제자는 어떻게 생각했는지를 같이 볼 수 있는 모의고사 이벤트다. 단순히 “문제 하나 풀었다”에서 끝나는 게 아니라, 여러 사람의 코드와 사고 과정을 비교해볼 수 있다는 점이 재미있었다.

신청하게된 계기

평소에도 토스가 Frontend Fundamentals, Debugging Fundamentals, 각종 오픈소스 등으로 개발 문화에 많이 기여한다고 생각하고 있었는데, 모의고사까지 연다는 걸 보고 그냥 지나치기 아깝다는 생각이 들었다.

솔직히 일을 하면서 좋은 코드에 대해 깊게 고민해본 시간이 생각보다 많지 않았다는 걸 최근 제대로 메타인지하게 됐다. 바쁘다는 이유로, 어차피 상위 의사결정자 자주 바뀌는 구조니까. 라며 “지금은 어쩔 수 없어”라고 자기 합리화를 꽤 오랫동안 해온 것 같다. 그 때문에 연차에 비해 좋은 코드에 대한 감각이 많이 뒤처져 있다는 느낌이 있었고, 이번 모의고사는 그걸 좀 정면으로 마주해보는 계기였다.

과제 & 해설 후기

과제는 예상대로 쉽지 않았다. 그래도 지금 내가 갖고 있는 기준과 생각을 최대한 반영해서 풀어보려고 했다. 다만 요구사항을 처음 받았을 때 전체 구조와 공유될 로직, 컴포넌트들을 머릿속에서 한 번에 그려보는 일이 여전히 어렵다. 구현 막판쯤 갔을 때 “아, 이걸 이렇게 묶었어야 했는데…” 하고 뒤늦게 깨닫는 패턴이 또 나왔다.

해설 방송은 처음부터 끝까지 봤다. 출제자분이 라이브 코딩으로 단계별 사고 과정을 보여주고, 다른 한 분과 자연스럽게 이야기 주고받는 형식이라 보는 내내 집중이 잘 됐다. 특히 후반부에 실제 모의고사 참가자들의 코드를 가져와서 리뷰하는 파트가 제일 좋았다. 실제로 내가 과거 업무를 하면서 짜왔던 코드와 비슷한 패턴이 계속 나와서, “아 저거 나도 해봤던 실수인데…” 하는 공감과 동시에, 그걸 어떻게 고쳐야 더 나은 구조가 되는지 설명을 들으니 이해가 엄청 잘됐다. 역시 공감은 학습할 때 큰 도움이 된다.

전체적으로 라이브코딩, 코드리뷰 시간에 기억에 남는 포인트 몇 가지를 정리하면 이렇다.

• 어떤 문제를 풀기 위해 세부 구현부터 파고들면 금방 “세부 구현에 잡아먹힌다”라는 표현을 해주셨다. 처음 들어보는 말인데 엄청 공감이 되는 말이였다. 그걸 피하려면 먼저 멘탈 모델을 잡고, 컴포넌트·훅 인터페이스부터 그려야 한다는 점. 이 부분은 평소에도 어느 정도 신경 쓰고 있어서, 더 의식적으로 잘해봐야겠다 라고 생각했다.

• 트렌드에 하잎돼서 무지성 따라 하기보다는, 왜 이 선택이 여기서 맞는지 스스로 설득할 수 있어야 한다는 메시지가 있었다. (FSD에 대한 이야기였던거로 기억함) 그 떄 왠진 모르겠지만 군대에서 부소대장님이 경계 시험 볼 때 “무조건적인 정답은 없고, 날 설득하면 된다”던 말이 떠올랐다. 은탄환이 있을거라고 생각하지 말것. 각 상황마다 적절한 대응 방법이 있을 뿐이다. 근본적인거에 집중하다보면 좋은 결과(구조)는 따라오기 마련이다. 라고 느꼈다

• “props drilling은 관심사 분리가 제대로 안 됐을 때 상태를 억지로 전달하다가 생기는 경우가 많다”라는 말을 해주셨는데, 이해는 되지만, 데스크톱처럼 한 화면에 정보가 빽빽한 서비스에서 어떻게 이 부분을 가져가야할지는 아직 모르겠다. 더 많이 고민해보고 다른 레퍼런스를 많이 찾아봐야겠다…

• 화면에 보이는 UI와 코드에 1대1로 매칭되는 구조가 의외로 중요하다는 얘기도 공감이 됐다. 실제 UI와 코드가 바로 매칭되면, 디버깅이나 리뷰할 때 인지 부담이 확 줄어든다. 라는걸 실제로 예시를 보여줬는데 평소에 내가 은은하게 생각했던 부분이 더 명확하게 들어왔다.

• 구현과 내부 구현을 분리해서 보는 습관이 필요하다는 걸 다시 느꼈다. useView 같은 훅을 예로 들면, 내부에서 전역 상태를 쓰든 URL 파라미터를 쓰든 그건 디테일일 뿐이고, 진짜 중요한 건 외부에서 보이는 인터페이스라는 점.

• 컴포넌트의 관심사는 결국 “비즈니스 동작 구현”이어야 한다는 말도 마음에 남았다. 옵셔널 체이닝이나 에러 체크 로직이 컴포넌트 안에 잔뜩 들어가면 금방 복잡해지는데, useSuspenseQuery 같은 걸 활용해서 그런 부분을 바깥으로 밀어내면 컴포넌트가 훨씬 단순해질 수 있다는 예시가 설득력 있었다.

해설을 듣고나니 내 코드를 한 번 싹 보고 리팩토링 해봐야겠다 라는 생각이 들었다. 다른 분들의 PR도 순회하면서 좋은 부분이 있으면 밑줄 긁으면서 머릿속에 남겨봐야지..