🧩 토스 Frontend Fundamentals 모의고사 리뷰를 통해 느낀 점

안녕하세요! 프론트엔드 개발자 정소현입니다.
최근 저는 “확장성 있는 프론트엔드 구조”, “응집성과 모듈성”, “관심사 분리”, “추상화” 등
항상 언급되지만 실제 코드에 적용하려 하면 어려운 주제들에 대해 많은 고민을 하고 있었습니다.

그러던 중 토스 Frontend Fundamentals 모의고사에 참여하게 되었고,
리뷰 라이브를 들으며 제가 놓치고 있었던 중요한 부분들을 다시 돌아볼 수 있었습니다.
그 경험을 공유해보고자 합니다.

---

✨ 진행 과정

• 2시간 내 과제 구현
• PR 제출
• Github Discussions에 인사이트 공유
• 오종택님 & 한재엽님의
  라이브 코딩 + 질의응답 + PR 리뷰 + Discussions 리뷰

짧은 시간이었지만 많은 깨달음을 얻은 시간이었습니다.

---

아래는 제가 리뷰를 들으며 가장 크게 와닿았던 부분들입니다.

1. 컴포넌트 구조와 추상화 — “추출이 아니라 추상화를 하자”

🔍 리뷰 전, 내가 했던 방식

• UI 화면 구조를 옆에 두고 따라가며 컴포넌트 분리
• Header, Content 등을 각각 파일로 분리
• UI 로직과 비즈니스 로직 hook으로 분리
• 파일이 많아지자 폴더 구조 고민이 함께 증가(FSD? DDD? )

하지만 리뷰를 들으면서 이런 생각이 들었습니다.

“이 파일 하나만 보고 이 페이지가 어떤 페이지인지 파악할 수 있을까?”

컴포넌트가 과할 정도로 분리되면
오히려 한눈에 흐름을 이해하기 어렵고,
파일 스위칭이 늘어나면서 인지 부하도 커진다는 사실을 다시 느꼈습니다.

특히 UI 구조와 코드 구조를 1:1로 매핑할 수 있어야 유지보수가 쉬워진다는 점이
라이브 리뷰에서 나왔던 이야기였는데,
이 말이 정말 강하게 와닿았습니다.

💡 "폴더 구조"보다 중요한 기준

폴더가 깔끔한지는 사실 부차적 문제였습니다.
리뷰에서 듣게된 더 중요한 것은 다음 세 가지 질문이었습니다.

• 이 분리가 인지 부하를 낮추는가?
• 이 분리가 유지보수를 용이하게 하는가?
• 이 분리에 따른 트레이드오프는 무엇인가?

이 기준으로 다시 생각해보니,
과도한 분리가 오히려 복잡도를 증가시키고 있다는 걸 깨달았습니다.

그리고 리뷰에서 나온 한 문장이 오래 남았습니다.

“추출이 아니라 추상화를 해야 한다.”

참고

그동안 저는 ‘분리’에만 집중하고 있었던 것 같습니다.
정말 필요한 분리인지, 재사용 가능성이 있는지, 응집이 유리한지에 대한 판단보다
그저 분리 자체가 목적이 되어버렸다는 걸 깨달았습니다.

---

2. Suspense — “성공 케이스에 집중하는 UI 작성”

Suspense는 이미 알고 있던 좋은 기능이었지만
저는 그동안 보수적으로 사용해왔습니다.

🔸 제가 우려했던 부분

1. 로딩 흐름이 암시적으로 숨겨져 있어 디버깅이 어려움
2. 컴포넌트가 부모 Suspense Boundary에 암묵적으로 의존
3. 컴포넌트를 이동하거나 재사용할 때 “여기 Suspense 있나?”를 매번 확인해야 하는 비용

그래서 저는

if (isLoading) return <Spinner />;

처럼 명시적으로 로딩을 처리하는 방식을 선호했었습니다.

🔸 리뷰에서 들은 새로운 관점

리뷰에서 가장 크게 와닿았던 말은 다음이었습니다.
참고영상

Suspense는 단순히 로딩을 위임하는 것이 아니라
‘성공 케이스에만 집중해서 UI를 작성하겠다’라는 선언이다.

즉,

• null일 수도 있어 같은 방어적 로직 없이
• 성공한 데이터 기준으로 UI를 작성할 수 있도록 도와주는 도구이며
• 단순 로딩 처리 도구가 아니라
  코드의 관심사를 명확하게 정리해주는 구조적 장치라는 점을 깨달았습니다.

---

🔸 Boundary 의존 문제를 해결할 수 있는 패턴

리뷰에서 소개된 패턴은 다음과 같습니다.

자식 컴포넌트 내부하단에서:

Child.loading = () => <LoadingUI />;

부모 컴포넌트에서는:

<Suspense fallback={<Child.loading />} />

이 패턴을 활용하면,

• 자식 컴포넌트가 어디에서든 재사용 가능하고
• 필요한 로딩 UI까지 스스로 제공할 수 있어

Suspense Boundary에 대한 암묵적 의존성 문제도 자연스럽게 해결된다는 점이 인상적이었습니다.

---

📝 핵심 요약

구조보다 근본적인 것 — “코드는 위에서 아래로 자연스럽게 읽혀야 한다”

2시간 동안의 리뷰에서 가장 강하게 얻은 메시지는
폴더 구조나 특정 패턴보다 코드의 흐름과 읽힘이 더 중요하다는 점이었습니다.

• UI 형태와 코드 구조가 1:1로 매핑될수록 유지보수하기 쉽다.
• 책임 단위로 추상화를 하면 재사용성은 자연스럽게 따라온다.
• 이 (함수 / 파일 / 폴더) 분리가 인지부하를 낮추나?
• 이 (함수 / 파일 / 폴더) 분리가 유지보수를 용이하게 하나?"
• 이 (함수 / 파일 / 폴더) 분리의 트레이드 오프는 무엇일까?
• 추출과 추상화를 구분하자.

결국, 단순히 잘게 나누는 것보다

읽기 쉬운 코드, 유지보수하기 쉬운 코드가 훨씬 더 중요하다.

는 메시지를 다시 한 번 느끼게 되었습니다.

---

✨ 마무리

짧았던 리뷰 시간이었지만
제가 놓쳤던 문제점들과
왜 구조 설계에서 어려움을 겪고 있었는지
명확하게 이해할 수 있었던 소중한 시간이었습니다.

그래서 앞으로는 이것들을 기준으로 개발을 진행하려고 노력하고자 합니다.

• 컴포넌트가 ‘정말 알아야 할 정보’만 갖도록 설계하자.
• 코드는 위에서 아래로 자연스럽게 읽혀야 한다.
• “DDD vs FSD 중 무엇이 정답일까?”라는 고민보다 더 중요한 것은,

내 코드가 잘 읽히는가?
유지보수하기 쉬운가?
인지 부하를 줄이는가?

다음에 기회가 있다면
다른 분들도 꼭 참여해보시길 추천드립니다!
읽어주셔서 감사합니다 🙏