
토스 엑셀레이터 3기를 수료하면서 많은 것을 배웠다. 특히 "좋은 코드"에 대한 관점이 많이 바뀌었다. 요즘 개발을 하면서 배웠던 패턴들을 실무에 적용하고 있는데, 문득 궁금했다.
"이전과 비교해서 나는 성장했을까? 배웠던 패턴들은 잘 쓰고 있는 걸까?"
그래서 토스 프론트엔드 모의고사에 참여하기로 했다.
소요 시간: 약 1시간
체감 난이도: 쉬움
구현 자체는 어렵지 않았다. 요구사항이 선형적으로 되어 있어서 순서대로 풀어나가면 됐다. 다만 이 모의고사의 진짜 가치는 "몇 가지 고민해볼 만한 포인트를 제시한다"는 데 있었다.
1시간이 남은 상태에서 나는 고민했다.
"내가 어떤 부분을 보여주어야 할까? 또 어떤 부분에 집중해야 할까?"
결국 나는 엑셀레이터에서 배운 패턴들을 적용하는 데 집중했다.
엑셀레이터에서 가장 강조하는 것 중 하나가 "요구사항과 코드가 1:1로 매칭되어 글처럼 읽히는 코드"다. 나는 이번 모의고사에서 그걸 실천해보려 했다.
예를 들어, SavingsCalculatorPage라는 이름을 보고 들어왔을 때 예상하는 것은 "적금 계산기 페이지"일 것이다. 실제로 코드를 보면:
<>
<SavingCalculator />
<Spacing size={24} />
<Border height={16} />
<Spacing size={8} />
<SavingTap value={activeTab} onChange={setActiveTab} />
{activeTab === 'products' &&
availableSavingsProducts.map(product => (
<SavingProduct
key={product.id}
product={product}
isSelected={selectedProduct?.id === product.id}
onSelect={setSelectedProduct}
/>
))}
{activeTab === 'results' && (
// ... 결과 표시
)}
</>
위에서부터 순서대로 읽으면 계산기 → 탭 → 탭에 따라 바뀌는 컴포넌트를 볼 수 있다. 추상화 레벨이 일치하고, 관심사가 명확하게 분리되어 있어서 코드가 "읽힌다."
하지만 모든 게 완벽하진 않았다. 특히 이런 부분들이 어색하게 느껴졌다:
const conditions = useSavingsCalculatorConditions();
const canShowResult =
selectedProduct !== null &&
conditions.monthlyPayment > 0 &&
conditions.term > 0 &&
conditions.targetAmount > 0;
이 네이밍들이 정말 적절한지, 비즈니스 로직의 위치가 올바른지, 추상화가 제대로 되어 있는지 확신이 서지 않았다. 그래서 PR에 5가지 질문을 남겼다:
해당 부분은 항상 내가 아직도 코드를 짜면서 고민하는 큰 5갈래의 부분이다.
예전 같았으면 이 과제를 어떻게 풀었을까?
아마 요구사항을 보고 순서대로 쭉 구현했을 것이다. 데이터와 계산 로직이 섞여 있고, 요구사항은 단순히 "내가 풀어야 하는 체크리스트" 정도였을 것이다. 코드와 요구사항이 일치하는 것의 중요성을 생각하지 않았을 것 같다.
지금은 다르다. 코드를 짜기 전에 이상적인 인터페이스를 먼저 고민한다. 그 인터페이스대로 코드를 짜는 연습을 하고 있다. 또한 단순한 "추출"이 아닌 "추상화"를 잘하고 있는지 고민한다.
결국 코드의 이상적인 모델을 통해 경제적인 코드를 만드는 것에 집중하게 됐다.
모의고사를 푼 후, 재엽님의 라이브 해설 강의를 들을 수 있었다. 토스에서 생각하는 "좋은 코드"가 무엇인지 명확하게 볼 수 있었다.
가장 인상 깊었던 부분은 요구사항을 먼저 보고 그것과 1:1 매칭되는 이상적인 인터페이스를 먼저 고민하고 쭉 적어나가는 모습이었다. 역시 코드를 나중에 좋은 인터페이스에 맞추는 것보다는, 미리 좋은 인터페이스를 만들고 나서 그것에 맞게 개발하는 게 훨씬 낫다는 걸 다시 확인했다.
또 중간에 "AI 시대의 좋은 코드"라는 아티클도 공유해주셨는데, 추출과 추상화에 대한 고민이 정리되어 있어서 도움이 많이 됐다. 요즘 가장 고민되고 해결하고자 하는 부분이라 많은 연습이 필요할 것 같다.
아쉬웠던 점: 나도 모르게 다시 코드를 인터페이스에 맞추려고 노력하는 모습이 나왔다. 인터페이스를 먼저 놓고 구현하는 데 집중해야 하는데, 이런 습관은 지속적으로 코칭받은 부분인데도 여전히 나타나서 아쉬웠다.
잘한 점: 그래도 이전에 비해 기본적으로 이상적인 인터페이스를 먼저 생각하고 코드에 빨려 들어가지 않게 노력했던 점은 잘했다고 생각한다.
이런 과제 모의고사는 실무와 달리 요구사항이 확실하고 변경되지 않기 때문에 패턴 적용에 더 많은 생각을 하게 된다.
같은 코드를 통해서 다른 개발자들의 방식을 보는 기회는 흔치 않다. 또 이런 기회가 있다면 전력으로 풀어보고 좋은 코드에 대해서 고민할 수 있는 기회니까 꼭 참여했으면 한다.
추천하는 방식:
1. 바로 풀어본다 (미리 준비하지 말고)
2. 내가 얼마나 구현에 집중하는지, 어떤 구조를 생각하는지 관찰한다
3. 다른 사람들은 어떤 식으로 구현했는지 PR을 둘러본다
4. 토스 실무자분의 해설 강의가 진행된다면 무조껀 참여해서 같이 본다 (중요)
5. 어떤 식으로 하는 게 좋은지 스스로 생각해본다
항상 성장은 전력으로 도전한 것이 깨질때 일어나는 것 같다. 내 전력을 다하여 코드를 짜고, 어떻게 하면 더 좋았을까를 피드백받고 회고한다면 가파르게 성장할 수 있을 것 같다