이 나이에 모의고사...?

(헌터x헌터 헌터 시험편...)

평소처럼 링크드인 눈팅을하다가 한 게시물에 멈춰섰다. Toss에서 주최하는 모의고사를 참여하면 과제를 풀 수 있는 이벤트였다.

토스 Frontend Fundamentals X 계정에서 선착순으로 디스코드 링크를 공유받아 들어갈 수 있었다.

나는 현재 4년차 실무개발자이지만 사수아래에서 개발해본 경험은 없다. 그렇기에 Frontend Fundamentals같은 공간은 나에게 방향성을 잡아주는 좋은 레퍼런스였다고 생각한다.

어떤게 좋은코드일까 고민을하는편이고, 2년전만해도 나는 나쁜습관을 가지면서 코딩을하고있었는데 지침서를 보면서 많이 고친편이다.

그중 한 사례를 예로들자면 나는 이벤트 함수에대하여 아무리 간단한 코드라도 "handle" 함수를만들어서 사용했는데 그 이유는 규칙적인 컨벤션과 함수명에는 handle을 달자는 것에 사로잡혀있었기 때문이다.

const handleBottomSheetDissmiss = () => {
  Keyboard.dissmiss();
};

이런식으로 아무리 간단한 이벤트라도 모두 "handle"화 해버렸다. 그 당시는 물어볼 사람도 없고 Claude Code, Cursor 같은게 없을뿐더러 나에게 지침서는 클론코딩강의 뿐이었다.

클론강의때문에 내가 나쁜버릇을 가진건아니고 그냥 이런 부분에대하여 토론할 사람들이 없어서, 나쁜 습관을 가지지 않았을까? 라는 의문이든다.

하지만 지침서를 참고하면서 강제적인 컨벤션보다 글처럼 읽히는 코드, 문맥에 따라 자연스러운 코드가 중요한 것을 깨달았다.

<BottomSheet onPress={Keyboard.dissmiss()}  ... >

요즘은 이런식으로 바텀시트의 onPress는 키보드를 사라지게 하는구나하고 작성하는편이다. 이정도면 처음 코드를 보는사람이 유지보수할 때 편하지 않을까 ? 라는 생각도한다.

그래서 다시 돌아가자면, 프론트엔드 지침서에서 진행하는 과제 형태의 모의고사에서 다시한번 나의 나쁜습관을 고칠 힌트를 얻기위하여 참여했다.

사실 실제로 채용을 위한 과제가 아니었기에 있는 그대로 내가 생각하는 방향성으로 코딩을 하였고 개선점을 해설로 듣기위한 목표가 컸다.

과제는 11월 3째주 주말까지였고 해설은 11월 25일 화요일에 진행되었다.

대략 70명정도가 과제에 참여했고, 평일 저녁임에도 불구하고 꽤 많은 사람들이 라이브 해설 방송에 참여했다.

해설 강의를 들으면서 초중반부는 "아 그래도 어느정도 방향성은 맞게 코딩하고있었네"였는데 후반으로 갈수록 나의 코드가 엉망인 것을 알았다.

일단 이번 모의고사 평가원의 출제 포인트는 State(상태)를 어떤방법으로? 였다.

좋은 방법이든 아니든 일단 네 가지 정도의 방법론이 떠오르는데

부모 컴포넌트에서 상태를 관리, 자식 컴포넌트에 Props로 전달
Props Drilling이 발생하여 전역 상태로 전달
영속성(브라우저의 로컬스토리지나 이와 비슷하게 새로고침해도 휘발이되지않는 요소)으로 저장
Url에 상태를 저장(query params)

방법론은 이러지만 나는 제일 첫번째로 언급한 부모에서 자식으로 전달하는 형태로 개발하는게 가장 좋다고 생각하였고 해설에서도 이런식으로 풀어주셨다.

사실 Props Drilling이라는 단어 자체가 되게 위험한 요소라고 생각한다. 신입 개발자일때는 Data Driven에 대한 개념도 없을 뿐더러

하나의 파일에 많은 코드들이 존재하는것을 꺼려하여 나름 초보자의 시선으로 컴포넌트를 분리하여 코딩을했는데, 정리되지 않은 컴포넌트와 경계가 없는 기준이 생기면서

수많은 자식들이 생기고 그로인해, Props가 아래로 뻗어나갔다고 생각한다. 정답은 없지만 나는 데이터 기반으로 컴포넌트를 분리하여 적절하게 Props를 전달하는게 좋은 방향성이라고 생각한다.

해설에서 드릴링에 관련된 짤막한 의견을 남겨주셨는데 아래와 같다.

상태가 제대로 역할에 따라 분리되지 않았을 때
하나의 컴포넌트가 많은 역할을 하고 있을 때
역할을 잘분리하면 문제 없고, 합성으로 풀어서 해결하자

이 외에도 내가 해설강의를 들으면서 앞으로 이렇게 접근해보는게 좋겠다고 생각하는 방법에 대하여 몇자 적어보려한다.

이상적인 형태를 수도코드로 표현해보기

나는 디자인 시스템같은 요소를 보면 어느정도 이렇게 짜야겠다 코드가 흐릿하게 보이는 수준이다.

사실 화면을 구성하는 부분에대하여 처리하는것은 문제없지만 뭔가 커스텀 훅을 지금 단계에서 표현해보지는 않았던 것 같다.

아래 이미지 처럼 코드에서 텍스트는 매우 중요한 구분자인것같다. 그 외에도 예시는 간단하지만 useView같은 상태를 관리하는 훅들도 미리 생각해보면 좋을 것 같다.

간단하게 생각하면 화면과 코드의 1:1매칭이지만 이러한 수준까지 구현하기에는 많은 경험이 필요한 느낌이든다.

복잡한 화면이면 위의 예시처럼 직관적으로 표현하기 힘들것이다. 여기서 개발자의 센스나 숙련도가 드러나는느낌이다.

주제가 커질수록 해당 주제에대한 관심사를 세분화하여 그룹을 잘짜야할 것 같다. 마치 지도를 구현할 때 클러스터 기능을 사용하는 것처럼

아래는 내가 자주 사용하며 평소 많은 레퍼런스를 참고하는 MJ님의 react-native-naver-map 클러스터 예시화면이다.

이렇게 확대, 축소할 때 처럼 코드역시 역할별로 잘 그룹화 시켜야겠다고 생각했다.

다음으로 중요하다 생각한건 바로

합성으로 Props Drilling 풀어내기

보통 부모 자식관계가 형성될 때, 사용하지않는 props도 전달되는 경우가있다.

이러한 부분들이 엉키고 엉켜서 흔히 말하는 Props Drilling의 문제점이라는 주제로 화두에 오르는데

나는 데이터 기준으로 역할과 책임을 가지는 컴포넌트에 한해서 Props를 계속하여 내려받는건 문제없다고 생각한다.

해설에서 해당 문제에대하여 깊게 다루진 않았지만, 합성으로 잘 풀어나가면된다는 말이 인상깊어 정리를 해보려한다.

Component A -> Component B -> Component C 라는 구조를 가지고있고 C가 A에서 값을 전달받아 사용하려면, 해당 값은 B를 거쳐오는 구조이다.

이러한 구조가 겹치고 사용하지않는 props를 받는 컴포넌트가 늘어나며 문제가 생기는 구조이다.

이를 합성으로 풀어보려면 아래와같이 풀어볼 수 있다.

아래구조는 단순하지만 합성으로 풀기위한 초석이되는 구조이다. A -> B -> C 구조는 유지되지만

B는 합성을 통해 children을 감싸는 역할만 한다.

평소 Context + 컴파운드 컴포넌트형태로 풀던 구조를 단순하게 가져갈 수 있으면 좋겠다는 생각이 들었다.

// A: 데이터를 가진 상위
function A() {
  const user = { name: "백준 프로그래머스(김동한)", tier: "Gold" };
  return (
    <B>
      <C user={user} />
    </B>
  );
}

// B: 레이아웃/스타일 책임, 데이터 모름
function B({ children }: { children: React.ReactNode }) {
  return <div className="card">{children}</div>;
}

// C: 실제로 데이터 사용하는 곳
function C({ user }: { user: { name: string, tier: string } }) {
  return (
    <p>
      {user.name} / {user.tier}
    </p>
  );
}

후기를 마치며

일단 여기까지 해설 방송에대한 나의 후기인데, 두시간 조금 안되게 진행되었지만 지루하지않았다.

생각보다 놓치고 있는게 많았고, 채용 과제에서 뭐가 중요한지 조금 힌트를 얻었다.

여담으로 FSD, Props Drilling에 대한 질문이 들어올 때 할 말은 많은데 하지 않는 상황이 조금 재밌었다.

요즘 같이 AI가 다해주는 세상에 이런 세심한 테크닉을 학습시키면 더 완벽한 코드가 나오지 않을까?

올해 토스의 과제를 두번 째 풀어보는데, 앞서 ReactNative 코어 과제에서 떨어진게 내심 아쉽다.

토스의 과제는 다른 채용과제보다 항상 재밌고, 요구사항이 명확해서 좋다. 과제자체에 대하여 고민하지않아도된다.

좋은 경험이었다.