계기

이번에 토스에서 진행하는 Frontend Fundamental 2기에 참여하게 되었습니다. 사실 1기 때도 신청을 고민하긴 했었는데, 그 당시에는 개인적으로 이것저것 벌려놓은 일들이 많아서 도저히 시간을 낼 수가 없겠다는 판단에 결국 스킵했었습니다. 그런데 이번에는 상황이 조금 달랐습니다. 주변에서 1기를 경험했던 사람들의 이야기를 꽤 많이 들을 수 있었는데, 꽤나 좋았다는 피드백이 많았어요. 단순히 과제를 수행하는 수준이 아니라, 스스로의 기준을 다시 점검하게 되는 계기가 됐다는 이야기도 있었고요.

또 한 가지는, 요즘 느끼고 있던 약간의 경각심 때문이기도 했습니다. 최근 몇 년 사이 AI의 발전 속도가 워낙 빠르다 보니, 예전처럼 코드 한 줄 한 줄을 고민하기보다는 “이 정도면 되지 않을까?” 하고 넘어가는 순간들이 점점 많아졌던 것 같아요. 물론 생산성이 올라가는 건 좋은 일이지만, 그만큼 코드의 구조나 품질에 대한 고민이 느슨해지고 있지는 않은지 스스로 의심이 들기도 했습니다.

게다가 회사에서 프론트엔드를 혼자 맡고 있다 보니, 다른 사람들이 실제로 어떤 방식으로 구조를 설계하고, 어떤 기준으로 코드를 나누는지 접할 기회가 거의 없다는 점도 컸습니다. 결국 제 방식이 계속 고착화되고 있는 건 아닌지, 혹은 더 나은 접근 방식이 있는데도 모르고 지나가고 있는 건 아닌지 궁금해졌고, 그런 맥락에서 이번 프로그램이 좋은 비교 기준이 되어줄 수 있겠다는 기대도 있었습니다.

꽤나 신박한 미션

신청을 하고 나서 가장 먼저 했던 건, 이전 기수의 과제를 찾아보는 일이었어요. 대략적인 난이도나 방향성을 가늠해보고 싶었거든요. 1기 과제를 보니, 실제 과제 전형에서 나올 법한 작은 프로덕트의 일부를 구현하는 형태였습니다. UI와 로직이 어느 정도 주어지고, 그걸 바탕으로 기능을 완성하는 식이었어요.

그래서 자연스럽게 “2기도 비슷한 느낌이겠지?”라고 생각하고 있었는데, 막상 받아본 과제는 예상과 꽤 달랐습니다. 이미 완성되어 있지만 상당히 지저분하게 작성된 코드를 기반으로, 이를 본인의 기준에 맞게 리팩토링하고 재설계하는 문제였거든요.

처음 과제를 받았을 때는 솔직히 조금 당황했습니다. 이미 있는 코드를 ‘고쳐서 더 나은 구조로 바꾸는 것’은 생각보다 결이 다른 작업이니까요. 어디까지 손을 대야 하는지, 무엇을 기준으로 개선해야 하는지 스스로 기준을 세워야 한다는 점도 쉽지 않았고요.

그럼에도 불구하고, 오히려 그래서 더 흥미롭게 느껴졌습니다. 평소에는 잘 접하기 어려운 유형의 문제였고, 실제 실무에서는 이런 상황이 훨씬 더 많기도 하니까요. 완전히 새로 만드는 것보다, 이미 존재하는 복잡한 코드를 이해하고 재구성하는 능력이 더 중요할 때가 많다는 점에서, 꽤 현실적인 과제라는 생각도 들었습니다.

어떻게?

과제를 진행하면서 일부러 새로운 패턴이나 기법을 억지로 적용하려고 하지는 않았어요. 이 과제를 위해 특별히 무언가를 넣기보다는, 평소에 제가 자연스럽게 사용하던 방식들을 그대로 가져오는 쪽을 선택했습니다.

예를 들어 폴더 구조를 나누는 방식이나, 컴포넌트를 분리하는 기준 같은 것들이요. 기능 단위로 나눌지, 도메인 기준으로 나눌지, 혹은 재사용성을 어디까지 고려할지 같은 판단들도 평소 하던 방식 그대로 가져갔습니다.

이렇게 한 이유는 나중에 다른 사람들의 코드와 비교해볼 때, 최대한 평소의 코드를 기준으로 평가해보고 싶었기 때문입니다. 만약 평소에는 쓰지 않던 패턴을 억지로 도입했다면, 그 결과가 좋든 나쁘든 제 실제 실력이나 습관을 반영한다고 보기 어려울 것 같았거든요.

또, 이후에 진행될 피드백이나 해설 강의를 들을 때도, “내가 평소에 하던 방식”과 “다른 사람들이 선택한 방식”을 비교하는 게 훨씬 의미 있는 학습이 될 거라고 생각했습니다. 단순히 정답을 맞추는 게 아니라, 선택의 이유를 이해하는 과정이 더 중요하다고 봤기 때문이에요.

사용하는 라이브러리 역시 마찬가지였습니다. 새로운 걸 억지로 도입하기보다는, 이미 익숙하게 사용하던 것들을 그대로 유지하면서 작업했습니다. 결국 도구보다는 구조와 사고방식 자체를 점검하는 게 이번 과제의 핵심이라고 생각했거든요.

그래서 후기

개인적으로는, 과제를 제출한 후 총 2번의 피드백 과정을 거쳤습니다. 한 번은 프로그램 전체가 함께 진행한 해설 강의였고, 다른 한 번은 상호 피드백 스레드에 직접 참여해서 다른 참가자분들과 코드 리뷰를 주고받는 시간이었습니다.

해설 방송의 경우에도 인상 깊었던 포인트들이 여러 개 있었는데, 개인적으로 가장 기억에 남는 부분은 생각보다 페이지 컴포넌트에서 과도하게 분리할 필요는 없다라는 이야기였습니다.

사실 저는 그동안 페이지에서는 최대한 브라우저로 인한 외부 의존성 ex)쿼리스트링 을 처리하고 그 값들을 하위 컴포넌트측으로 보내는 편이었어요. 재사용성과 테스트 용이성, 그리고 관심사 분리 측면에서 당연히 유리하다고 믿고 있었고요. 그래서 페이지 단위에서도 가능한 한 작은 단위로 나누려고 했던 습관이 있었던 것 같습니다.

그런데 이번 해설에서는 오히려 그 반대 방향의 이야기가 나왔습니다. 페이지 컴포넌트는 그 자체로 하나의 “맥락”을 가지고 있기 때문에, 그 안에서만 쓰이는 로직이나 UI까지 굳이 바깥으로 분리할 필요는 없다는 것이었어요. 오히려 과도한 분리는 코드를 따라가야 하는 경로만 늘어나게 만들고, 읽는 사람 입장에서 맥락을 파악하기 더 어렵게 만들 수 있다는 점이 인상적이었습니다. FSD 최신 문서에서 제시한 최대한 페이지 컴포넌트에서 시작하라는 조언이 생각나는 대목이기도 했어요.

이 이야기를 들으면서, 제가 그동안 “분리”라는 행위를 거의 습관처럼 해오고 있었던 건 아닌가 하는 생각이 들었습니다. 분리를 해야 하는 이유보다는, 그냥 좋은 코드니까라는 막연한 기준으로 나누고 있었던 건 아닌지 돌아보게 되더라고요.

결국 중요한 건 얼마나 잘게 나누느냐가 아니라, 어디까지를 하나의 맥락으로 볼 것인가, 그리고 그 맥락이 깨지지 않도록 구조를 설계하는 것이라는 생각이 들었습니다.

이 포인트는 상호 코드 리뷰를 하면서도 다시 한 번 체감할 수 있었습니다. 어떤 분들은 굉장히 세밀하게 컴포넌트를 나누신 반면, 어떤 분들은 비교적 큰 단위로 유지하면서도 코드가 충분히 읽히도록 잘 구성해두셨더라고요. 그리고 후자의 경우가 오히려 전체 흐름을 이해하기는 더 수월했던 경우도 꽤 있었습니다. 그리고 단순히 프론트엔드 코드 뿐만이 아니라, AI 시대에서의 작업 방식 변화나 개인의 생각들을 나누는 좋은 시간을 가졌어요. 9시에 시작한 디스코드 회의가 생각보다 길어져서 거진, 새벽 1시즈음에 끝났을 정도로 많은 이야기들을 주고 받았던 시간이었어요. 끝나고 치킨 시켜먹으려 했는데 마치고 보니 가게가 문을 닫았더라구요...

이 경험을 통해서, 정답 같은 구조가 따로 있다기보다는, 의도가 드러나는 구조가 좋은 구조라는 쪽으로 생각이 조금 바뀌게 된 것 같습니다. 그리고 그 의도를 드러내기 위해서는, 무조건 나누는 것보다는 때로는 적절하게 묶어두는 것도 중요하다는 걸 느꼈고요.

오랜만에 꽤 밀도 있게 고민했던 시간이었던 것 같고, 덕분에 다시 한 번 기본을 돌아보는 계기가 됐습니다. 다음 기회가 있다면 또 참여해보고 싶네요.