본문 바로가기

생각정리, 주절주절/개발에 도움되는 것들

토스 Frontend Fundamentals 모의고사 후기

우연한 기회로 Fundamentals 모의고사에 참여하게 됐다. 요즘 회사 일이 바빠 망설임도 있었지만, 결과적으로는 참여하길 정말 잘했다. 빨리 3회차가 시작되길 기다릴만큼...

 

배운 것 1: UI를 먼저 보고, 구조를 새로 잡는다

가장 크게 배운 건 복잡한 기존 코드를 고치려 달려드는 대신, 구현하고자 하는 UI를 먼저 바라보고 구조를 다시 짜는 방식이었다. 회사 업무에서도 바쁘게 쳐내다 보면 조그만 쓰레기들(부채)이 쌓이고, 리팩토링을 시도해도 이미 쌓인 쓰레기를 치우는 건 생각보다 훨씬 어렵다. 오히려 더 쓰레기장이 되기도 한다. 그 답답함을 자주 느꼈는데, "UI를 보고 structure를 다시 잡는다"는 접근이 그 문제의 해법이 될 수 있다는 걸 이번에 배웠다.

 

예를 들어 다음과 같은 화면이 있다고 하자.

이런 UI가 있다고할때, 

import { useState } from 'react';

export default function ReservationStatusPage() {
  const [date, setDate] = useState(new Date());
  return <>
    <h1>회의실 예약</h1>

    <section>
      <h2>날짜 선택</h2>
      <DatePicker value={date} onChange={setDate} />
    </section>

    <section>
      <h2>예약 현황</h2>
      <ReservationTimeline />
    </section>

    <section>
      <h2>내 예약</h2>
      <MyReservations />
    </section>
  </>
}

 

UI 구조와 코드 구조를 1:1 대응시키면 코드가 자연스럽게 읽힌다. 아울러 div 대신 section을 쓰는 것이 웹 접근성에 훨씬 유리하다는 것도 이번에 제대로 짚어주셨다. 단, aria-label과 함께 써야 의미가 있다. 매번 습관적으로 div 쓰던 걸, 의식적으로 멈추게 되었다. 그리고 컴포넌트 내부에서 margin을 쓰지 않고 별도의 Spacing 컴포넌트로 분리하는 패턴이 유지보수에 훨씬 유리하다는 것도 깨닫게 되어, 이번 기회에 실무에 적용했다.

 

배운 것 2: props는 꽂을 이유가 있을 때만 꽂는다

요즘 포코피아에 빠져 있다. 게임 속에서 화력 발전소에서 전기를 멀리까지 끌어오려면 전봇대를 하나씩 이어가야 하는데, 처음부터 설계 없이 연결하다 보면 어느새 건물 한복판, 땅 한가운데 전봇대가 덕지덕지 들어차게 된다. 미관을 해치는 건 기본이고, 나중에 전봇대 하나를 없애려 하면 연결된 것들이 너무 많아 전체 전기가 꺼져버린다.

그런데 코드가 딱 이것과 같다는 걸 느꼈다.

props를 "플러그를 꽂는 것"이라고 표현한 말이 그래서 딱 와 닿았다. 지금 이 컴포넌트에 플러그를 꽂아야 하는 이유가 무엇인지 먼저 따져보면, 자연스럽게 외부 의존성이 낮은 순수한 컴포넌트로 이어진다. 반대로 이유 없이 props를 연결하다 보면 어느새 사방에 전봇대가 세워진 것처럼, 어디 하나를 건드리면 전체가 흔들리는 코드가 된다. 설계 없이 꽂고 보는 게 아니라, 꽂을 이유를 먼저 묻는 것. 그게 예측 가능한 코드의 시작임을 다시금 깨닫게 되었다. 

이건 전역 상태 라이브러리가 되는걸까ㅋㅅㅋ

 

배운 것 3: 과도한 분리도 가독성을 해친다

코드가 200줄을 넘으면 무조건 컴포넌트로 쪼갰었는데, 이번에 다시 생각하게 됐다. UI와 코드의 1:1 대응이 제대로 안 된 채 분리하면 오히려 더 복잡해진다. 마치 끝없는 FilterPanel의 유혹... 뭔가 정리된 것 같은 그 느낌. 하지만 실제로 코드를 읽는 사람 입장에서는 어떨까. 줄줄 읽히는가, 아니면 잉? 뭐지? 하며 또 들어가고, 또 들어가야 하는가. 진짜 가독성은 코드 줄 수가 아니라 흐름에서 온다는 것.

쉽게 쓰기, 최소한으로 쓰기. 이게 가장 어렵고, 그래서 가장 아름다운 영역인 것 같다.

 

그리고 토스다움

애플 제품의 포장을 뜯을 때 느끼는 그 감각을 나는 정말 좋아한다. 뜯는 부분을 잡아올릴 때, 딱 맞아 떨어지는 저항감있는 속도감, 패키징 내부에는 있어야 할 것만 있는 미니멀함. 그 감각들을 이번 토스 해설에서 느꼈다.

모든 개발자는 그 순간의 이유로 코드를 써내려간다고 생각한다. 다 나름의 결정이 있다. 차이는 그 결정이 얼마나 세련되고 유려한가에 있다. 이번 해설에선 내가 생각할 수 있는 것 이상을 생각해내는 사람들을 통해 탁월함을 느꼈다. 그 중 하나가 불필요함을 알아보려면 0에서 시작해야 한다는 것이기도 하다. 더하는 게 아니라 덜어내는 것을 기본값으로 두는 사고방식.

그런 사고방식을 배우고 싶다. 아름답다고 느껴지는 코드를 짜는 사람들과 일해보고 싶다는 생각이 이번에 더 깊어졌다. 그런데 그 사람들도 그런 사람과 일하고 싶은 것은 마찬가지겠지. 얼른 나도 그곳에 다다르고 싶다. 그래서 3회차도 빨리 시작됐으면 좋겠다.

반응형