Toss Frontend Accelerator 5기 Pre-Course 회고

토스 ACC(Frontend Accelerator) 지원 기회가 생겨 지원서를 작성하게 되었다. 단순히 이력을 나열하는 과정이 아니라, 그동안의 선택과 경험을 하나씩 복기해야 하는 질문들이 많아 작성하는 데 시간이 꽤 걸렸다. 질문에 답하다 보니 ‘아, 내가 이런 고민들을 안고 일해왔구나’ 하고 스스로를 다시 돌아보게 되었다. 지원을 마치고 다행히 본과정 전에 있는 프리코스 과정에는 합류할 수 있게 되었다. 이전 기수분들의 후기를 찾아보며 가장 궁금했던 점은, 이 과정이 단순히 기술 스택을 가르치는 교육이 아니라 코드를 짜는 사람의 사고방식을 다룬다는 점이었다. 연차가 쌓이면서 “이 정도면 잘 구현했다고 말할 수 있을까?”라는 질문에 스스로 확신 있게 답하지 못하는 순간들이 늘고 있었다. 코드는 분명 돌아가지만, 이 코드가 나중에 유지보수의 병목이 되지는 않을지, 다른 사람이 읽기 어려운 구조는 아닐지에 대한 의심이 항상 따라다녔다.

내가 생각하기에 ‘잘 구현했다’ 것은 결국 구현한 내가 느끼는 것일 뿐이고, 유지보수가 좋은 코드인지는 결국 그 상황에 도달해봐야 알 수 있다 보니, 판단 기준 자체가 늘 모호하게 느껴졌다. ACC 프리코스는 내가 막연하게 안고 있던 이런 불안과 질문들을 정면으로 마주해볼 수 있는 기회였던 것 같다. 본격적으로 무엇을 배웠는지를 정리하기에 앞서, 프리코스에서 배운 내용을 회사 코드에 직접 적용해 본 경험부터 간단하게 기록해보려 한다.

문제점: 정리는 했지만, 개선되었다고 말하기 어려웠던 코드

리팩토링을 시도했던 해당 컴포넌트는 상태 관리 방식과 로직의 흐름이 상당히 파편화되어 있었다. 급하게 개발되는 과정에서 각 시점의 요구사항을 충실히 구현하다 보니 생긴 구조였고, 나 역시 그 상황에 있었다면 비슷하게 작성했을 것 같다는 생각이 들었다.

입사 후부터 계속 리팩토링하고 싶었던 컴포넌트였지만, 막상 손을 대면 늘 벽에 부딪혔다. 컴포넌트 자체도 약 800줄 정도로 너무 길었고, 호출되는 커스텀 훅만 해도 8개가 넘었다. 문제는 그 훅들이 서로 엮여 있다는 점이었다. 한 로직을 수정했을 때 다른 기능들이 정상적으로 동작할지 확신하기 어려웠고, 전체 흐름을 알 수 없었다. 해당 컴포넌트에 어떤 기획까지 포함하고 있는지조차 파악이 되지 않았다.

이전에도 공통으로 보이는 로직을 커스텀 훅으로 묶거나 컴포넌트를 쪼개보는 시도를 했었다. 하지만 리팩토링을 마친 뒤에도 복잡한 로직을 다른 파일로 옮겨 숨겼을 뿐, 읽기 쉬워졌다는 느낌은 아니었고, 결국 코드를 다시 되돌리곤 했다.

이번에는 어떻게 접근했는가

이번 리팩토링에서는 ACC 프리코스를 통해 배운 관점을 바탕으로 접근 방식을 바꾸기로 했다.
코드를 어떻게 옮길지, 구조를 어떻게 나눌지보다 먼저, 기획의 언어를 어떻게 코드로 투명하게 드러낼 수 있을지, 코드를 읽는 사람이 시점을 이리저리 이동하지 않아도 흐름을 이해할 수 있을지를 고민했다. 이번 리팩토링의 목표는 구조를 잘 만들어 보이는 것이 아니라, 코드를 읽는 사람이 덜 생각해도 되는 상태를 만드는 것, 그리고 코드의 흐름이 자연스럽게 읽히는 상태를 만드는 것이었다.

해당 페이지는 여러 상태와 조건이 얽혀 있는 복잡한 도메인이었고, 기존 코드에는 인라인 조건들이 곳곳에 흩어져 있었다. 이런 코드를 읽을 때마다 조건을 하나씩 해독하며 이게 어떤 상황인지 머릿속에서 계산해야 했다.

그래서 이번에는 인라인 조건을 그대로 두지 않고, 기획서에 적힌 문장을 코드로 옮기듯 의미 있는 이름을 붙이기로 했다. 다만, 의미가 충분히 자명한 간단한 조건들은 굳이 변수로 분리하지 않고 인라인으로 유지했다. 

이렇게 접근하다 보니, 사실 이런 정리는 이전에도 충분히 할 수 있었겠다는 생각이 들었다. 다만 그동안의 나는 조건의 의미를 드러내기보다는, 복잡해 보이는 코드를 어떻게 분리하고 숨길지에만 집중하고 있었던 것 같다. 구조를 나누고 파일을 쪼개는 것을 리팩토링이라고 여기면서, 그 코드가 어떤 상태와 어떤 상황을 표현하고 있는지를 드러내는 데에는 상대적으로 신경을 덜 쓰고 있었다는 걸 이번 과정을 통해 처음으로 자각하게 되었다. 

이렇게 바꾸고 나니 코드는 더 이상 계산해야 할 대상이 아니라 읽히는 대상이 되었고, 조건을 이해하기 위해 기획서를 다시 보거나 코드를 위아래로 오가며 맥락을 추적해야 하는 시점 이동도 크게 줄어들었다. 그리고 상태와 흐름이 정리되자 이전에는 보이지 않던 것들이 보이기 시작했다. 여러 곳에 흩어져 있던 중복 로직들이 단순히 비슷한 코드가 아니라, 같은 목적을 가진 행위라는 점이 분명해졌다. 그래서 코드의 형태가 아니라 행위의 목적을 기준으로 로직을 추려냈고, 세션을 시작하거나 특정 상태를 종료하는 흐름들을 start, stop 같은 액션 중심의 함수로 추출했다.  이때의 기준은 중복을 모두 함수로 빼는 것이 아니라, 코드 흐름 속에서 “여기서 무엇이 시작되고, 무엇이 끝나는지”가 자연스럽게 읽히는지 여부였다. 

결과

하루 정도 리팩토링을 마치고 나서 의외였던 점은, 컴포넌트의 전체 길이가 이전과 거의 비슷했다는 것이었다. 예전 같았으면 코드 길이에 집착해서 어떻게든 훅으로 빼려고 했을 텐데, 지금은 위에서 아래로 읽기만 해도 어떤 상태를 확인하고, 어떤 조건에서 액션이 실행되며, 어떤 경우에 UI가 막히는지 흐름이 자연스럽게 보였기 때문에 코드 길이에 대한 불편함에 집착하지 않았다.

흐름이 투명해지니 그동안 숨어 있던 이슈들도 자연스럽게 드러났는데, 로딩 중에 실행되면 안 되는 액션이나 특정 상태에서 누락된 예외 처리들을 발견하고, 기획과 다르게 동작하고 있는 부분들을 발견해 수정할 수 있었다. 작게 접근해 보자고 시작했던 리팩토링이었지만, 결과적으로는 기획과 코드의 상태 정의를 다시 맞추는 꽤 큰 정리로 이어졌다.

중간중간 길이는 비슷한데 정말 좋아진 게 맞을까 하는 의구심이 들기도 했지만, 코드를 리뷰해준 동료분이 흐름이 한 번에 눈에 들어온다, 코드가 잘 이해된다는 피드백을 받으면서 다행이라는 생각을 했다.

그래서 어떤 것을 배웠나

그동안 클린 코드나 함수형 프로그래밍 같은 책들을 읽으면서도 실무에 제대로 적용하고 있다는 느낌이 들지 않았다. 지금 생각해 보면 어떤 기준을 가지고 코드를 바라봐야 하는지 몰랐기도 했고, 중요하다는 건 알겠는데 그걸 실제 코드로 어떻게 옮겨야 하는지는 잘 감이 오지 않았던 것 같다. (너무 크게, 너무 많은 것을 한 번에 이해하려고 했던 건 아닐까 싶기도 하다.)
“이건 정말 좋은 말이다”라고 생각하며 노션에 적어두긴 했지만, 막상 코드를 작성할 때는 그 문장들이 거의 떠오르지 않았다.

반면 프리코스에서는 기준을 설명으로만 듣는 게 아니라, 하나의 과제를 두고 계속 적용해보고, 설명해보고, 다시 고쳐보는 과정을 반복했다. 그러다 보니 왜 이런 기준이 필요한지, 이게 코드에서 어떤 차이를 만드는지가 자연스럽게 체감되었다. 

그렇게 프리코스를 진행하면서 계속 마주하게 된 기준들 중, 요즘 내가 가장 우선으로 두고 있는 질문들은 아래와 같다.

1. UI와 코드가 1:1로 대응되고 있는지
2. 이 코드가 무엇을 하는지를 기획의 언어로 설명할 수 있는지
3. 코드를 이해하기 위해 시점을 이리저리 이동하지 않아도 되는지

그리고 무엇보다 크게 배운 것은, 작게 실천하기와 본질부터 생각하기다. 이건 개발뿐 아니라 나의 일상에도 영향을 주었다. 프리코스 이후 운 좋게도 종택님과 인터뷰를 할 수 있었고, 그 대화를 계기로 나 스스로의 행동을 돌아보게 되었다.

돌이켜보니 나는 항상 미래를 예측하면서 행동을 주저하는 편이었다. 나중에 어떻게 될지, 이 선택이 맞을지부터 먼저 생각하다 보니 정작 지금 할 수 있는 행동을 미루고 있었다. 종택님은 이런 상황에서 하나의 방법으로, 내가 원하는 것 or 주저하는 순간을 어딘가에 적어보는 걸 추천해주셨다. 그 이후로 매일 노션에 내가 주저하고 있거나, 주저했거나, 주저할 것 같은 상황들을 적기 시작했다. 집에 돌아와 그날 적어둔 내용을 다시 보며, 왜 그 순간에 주저했는지를 혼자 정리하는 루틴을 만들었다.

노션에 적어보는 것만으로도 내가 지금 무엇을 원하는지는 이전보다 분명해졌다. 다만 그걸 실제 행동으로 옮기는 건 생각보다 쉽지 않았고, 다음 액션으로 내가 지금 하고 싶은 것과 지금 집중해야 하는 것을 최대한 작게 쪼개보기 시작했다. 생각을 작게 나누기 시작하니 행동도 자연스럽게 작은 액션 아이템으로 이어질 수 있었다.  

회의에서 주제가 벗어나는 것 같을 때도, "이건 주제에 벗어나는 것 같다"고 말하기는 거의 불가능에 가깝지만, "우리가 이 이야기를 시작한 이유가 이거였죠?"라고 질문하는 것은 가능했다. 팀원이 기획을 보며 너무 멀리까지 고민할 때도 마찬가지였다. 혼자서 "너무 벗어난 범위다"인데 라고 생각하는 데에서만 그치기보다는, "이게 기획적으로 가능한 범위인지"를 먼저 확인하고, 그렇다면 미래에 불투명하게 추가될 기획을 대비해 지금 우리가 함께 챙길 수 있는 액션이 무엇인지 찾아보는 쪽은 가능했다.

기획을 보고 먼 미래까지 걱정하는 것은 나 역시 크게 다르지 않다. 새로운 기획이 나올 때마다 멀리까지 고민하고, 다가올지 아닐지 모르는 미래를 계속 예측하면서 유지보수가 쉬운 구조를 먼저 고민하는 편인데 미래를 예측할수록 오히려 구현은 더 어려워졌고, 변경하기 쉬운 코드를 짜는 데에도 시간이 더 오래 걸렸다. 또 미래의 예측에 내 생각이 들어가다 보니 변경이 어려운 구조로 구현될 때가 많았다. 이젠 본질에 더 집중해서 지금 내가 원하는 것은 '잘 구현하는 것' 이니 미래에 대해서는 ‘언젠가 변경될 수도 있다’ 정도까지만 염두에 두고 현재 기획에 집중해서 구현해 보니, 코드가 훨씬 단순해졌고 결과적으로 변경도 더 쉬워졌다.

또 최근에 느낀 점은, 내가 작업을 쪼개는 방식이 이전과는 조금 달라졌다는 점이었다. 예전에도 커밋을 잘게 나누려고 의식적으로 노력하긴 했지만, 지금 돌이켜보면 ‘쪼개야 한다’는 기준에 맞춰 형식적으로 나누는 데 가까웠던 것 같다. 얼마 전 베이스 브랜치에 여러 브랜치에서 작업한 변경 사항들이 한꺼번에 합쳐지면서 사이드 이펙트로 이슈가 발생한 적이 있었다. 그런데 예상보다 훨씬 빠르게 원인을 좁혀갈 수 있었는데, 생각보다 커밋이 상태 하나, 흐름 하나 단위로 더 잘게 나뉘어 있었기 때문이다. 그때서야 요즘 들어 커밋이 이전보다 훨씬 더 잘게 쪼개지고 있다는 걸 체감하게 되었다.

이렇게 작게, 본질부터 생각하기 시작하니 머릿속도 조금씩 가벼워졌다. 작년 하반기부터 개인적으로 꽤 힘든 시간을 보냈는데, 답답한 마음에 여러 스터디와 사이드 프로젝트를 병행하며 스스로를 바쁘게 만들기도 했다. 덕분에 바쁜 2025년 하반기를 보내긴 했지만, 돌이켜보면 본질적인 문제를 해결했다기보다는 잠시 다른 곳에 숨겨두었던 것에 가까웠던 것 같다. 

그래서 프로젝트와 스터디들이 하나둘 정리되어 가는 시점에 2026년 1월이 되었는데도 여전히 2025년 연말을 보내는 느낌이었고, 작게 생각하고 본질에 집중하기로 마음을 정리하고 나서야 2월이 된 지금 비로소 2026년에 들어선 느낌이 든다. 요즘은 적어도 하루하루 무엇에 집중해야 할지는 이전보다 훨씬 선명해진 것 같다! 앞으로도 프리코스에서 배운 것들을 잘 실천해보고자 한다. 🙂