[tolli #3] switch로 쪼갠 화면이 협업 단위가 됐다

💡 읽기 전 필요한 지식 💡
- 컴포넌트라는 개념에 대한 가벼운 이해
- switch문이 값에 따라 분기하는 문법이라는 정도의 지식
- 여러 명이 하나의 레포에서 함께 개발한다는 상황에 대한 감

📖 읽고 나면 얻을 수 있는 것 📖
- 하나의 큰 화면을 여러 사람이 나눌 수 있게 "구조로" 설계하는 방법을 이해하게 된다
- switch 분기와 독립 컴포넌트라는 뼈대가 왜 협업과 관심사 분리에 유리한지 알게 된다
- 애자일하게 스프린트마다 역할을 나누고 리딩한 경험이 어떤 모습이었는지 엿볼 수 있다

이 글을 읽기 전에 이전 글들을 읽으면 도움이 될 것이다.

[tolli #1] 무거운 성경암송 앱이 싫다

[tolli #2] 왜 React Native + WebView 하이브리드였을까?

톨리의 핵심은 학습 플로우라고 할 수 있다.

기획 단계에서 한 구절을 외우는 과정을 0단계부터 7단계까지 나눠 둔 상태였다.

그래서 처음엔 이 흐름을 하나의 큰 화면으로도 볼 수 있었다.

하지만 조금이라도 들여다보면 각 단계는 생긴 것도, 하는 일도 서로 완전히 다른 것을 볼 수 있다.

 

정리해보자면 아래와 같다.

1. 0단계 - 그냥 읽는 화면
2. 1단계 - 단어를 탭하면 뜻이 나오는 화면
3. 2~5단계 - 일부를 가리고 선택지로 맞히는 화면
4. 6단계 - 초성만 보고 타이핑하는 화면
5. 7단계 - 녹음하는 화면

즉, 하나의 "학습"이지만 실제로는 서로 다른 성격의 독립적인 화면이 존재하는 셈이었다.

당연히 이 모든 단계들을 한 파일에 다 넣으면 아무도 손 대기 어려운 거대하고도 거대한 컴포넌트가 되지 않을까?

---

switch 뼈대 만들기

필자는 이 학습플로우를 다른 개발자가 시작하기 전에 먼저 만들기로 했는데, 세팅이 필요하다고 보았다.

그래서 내린 결정은 단계를 URL의 일부로 두고, 그 숫자에 따라 어떤 화면을 보여줄지 switch문으로 분기하는 것이었다.

동적 라우팅으로 `study/[verseId]/[step]`이란 경로를 만들고, 주소의 step 값을 읽어 그에 맞는 컴포넌트 하나를 그려주도록 하는 것이다.

 

실제 코드의 핵심을 보면 아래와 같다.

switch (currentStep) {
  case 0:
    return <ReadVerse verse={verse} verseId={verseId} />;
  case 1:
    return <TabVerse verse={verse} meanings={verse.words} verseId={verseId} />;
  case 2: case 3: case 4: case 5:
    return <MultipleChoiceView step={currentStep} verse={verse} stepMaskData={stepMaskData} verseId={verseId} />;
  case 6:
    return <ConsonantTypingView verse={verse} verseId={verseId} />;
  case 7:
    return <Record verseId={Number(verseId)} />;
  default:
    return null;
}

위 코드는 현재 단계를 나타내는 숫자(currentStep)에 따라 서로 다른 화면 컴포넌트를 리턴해주는 부분이다.

중요한 건 이 파일이 직접 하는 일이 거의 없다는 점이다.

이 파일은 "몇 번 단계면 어떤 컴포넌트를 보여준다"라는 연결만 책임지고, 각 화면이 실제로 어떻게 동작하는지는 ReadVerse, TabVerse, MultipleChoiceView와 같은 각각의 컴포넌트에 완전히 맡긴 셈이다.

 

폴더구조 또한 이에 맞게 step0, step1, step2-5, step6, step7으로 나눠 두었다.

study/
├── [verseId]/[step]/page.tsx
└── _components/
    ├── step0/ReadVerse
    ├── step1/TabVerse
    ├── step2-5/MultipleChoiceView
    ├── step6/ConsonantTypingView
    └── step7/Record

이렇게 나누고 나니 한 가지가 확실해졌다고 생각한다.

각 스텝 컴포넌트는 서로를 몰라도 된다. 즉, 관심사 분리가 명확하다는 것

예를 들면, step6를 만드는 사람은 step2가 어떻게 동작하는지 알 필요가 없고,

그저 자신의 화면만 정해진 props만 신경 쓰면 되는 구조이다.

바로 이 점이 협업의 핵심이 되지 않았을까 싶다.

---

이 swtich 뼈대가 협업에 미친 영향

이 구조를 먼저 잡아둔 이유는 위에서 말한 것과 같이 프로젝트를 혼자 하지 않았기 때문에도 있다.

다른 개발자와 함게 하나의 레포에서 작업했고,

학습 플로우를 하나의 큰 화면으로 두면 둘이 같은 파일을 동시에 고쳐 충돌이 나기도 쉬울 것이라고 판단했다.

 

그래서 switch분기와 빈 스텝의 컴포넌트의 뼈대만 먼저 만들어 두고, 그 안을 채우는 일을 나눌 수 있게 했다.

각자가 맡은 스텝의 폴더 안에서만 작업하면 서로의 코드를 건드릴 일은 거의 없어진다.

 

실제로 진행한 스프린트에서는 이렇게 나누었다.

지오는 메인화면과 step0-1, 7을 맡고, 필자는 step2부터 step6를 맡는 식이었다.

화면이 이미 컴포넌트 단위로 쪼개져 있었기 떄문에, 이렇게 스텝 단위로 일을 분배하는 것이 자연스러웠다.

먼저 구조를 잡아둔 것이 그대로 역할 분배의 단위가 되었다!

---

+ 스프린트마다 애자일하게 역할 나누기

사실 구조만 잡는다고해서 협업이 저절로 되지는 않는다고 생각한다.

 

스프린트 단위로 목표를 끊고, 그 안에서 누가 무엇을 맡을지를 명확히 나누는 일을 스스로 맡았는데,

초반 스프린트에서는

지오가 카카오 로그인과 회원가입을,

필자가 구글, 애플로그인과 파이어베이스 구축을 맡는 식으로 인증 계열을 나눠 가져갔고,

시간이 남는 사람이 스플래시나 알림 페이지 같은 곁다리 작업을 가져가도록 했다.

 

학습 플로우가 본격적으로 시작되는 스프린트에서는 앞서 말한 대로 스텝을 나누어 병렬로 진행했다.

 

맡은 기능을 구현한 뒤의 흐름도 함께 정해뒀는데, 기능을 다 만들면 코드리뷰를 거치고 리팩터링한 뒤 PR을 보내는 사이클로  돌렸다.

단순히 일만 나누는게 아니라, 어떤 상태에서 PR을 올릴지까지를 같이 정해두어야 협업이 잘 돌아간다는 걸 느꼈다.

리딩이라고 해서 거처한 게 아니라, 프로젝트의 구조를 먼저 이해한 사람이 일의 단위와 순서를 제안하는 정도의 역할이었다.

좋은 구조는 그 자체로 협업의 언어가 되지 않을까?
구조가 먼저 서 있었기 때문에 역할을 깔끔하게 나눌 수 있다.
(절대 과한 추상화부터 하자는 것은 아니다!)

---

다음 글부터는 이 앱을 만들며 실제로 부딪힌 트러블슈팅을 다룬다.
먼저 가장 오래, 가장 힘들게 파고든  AOS에서의 Apple 로그인이슈를 한 편으로 자세히 기록해보려 한다.