BUILT & IMPROVED · 2025.11
약관 라우팅 로직
리팩터링
조건 판단, 화면 데이터 구성, 라우팅 실행이 한곳에 섞여 있던 초기화 로직을 분리했습니다. 조건을 순수 함수와 배열 기반 전략으로 재구성해 흐름을 짧고 선언적으로 만들었습니다.
- 문제
- 108줄의 조건·실행 혼재
- 판단
- 데이터와 동작의 분리
- 결과
- 26줄의 선언적 흐름
01
배경
모바일 SDK 약관 동의 페이지에는 가입 여부, 국가, 연령 인증 상태에 따라 첫 화면을 결정하는 로직이 있었습니다. 시나리오가 늘면서 초기화 함수는 108줄의 if-else 블록으로 커졌습니다.
각 분기 안에는 조건 판단뿐 아니라 화면 데이터 구성과 서비스 호출, 라우터 실행까지 함께 들어 있어 작은 변경도 전체 흐름을 다시 확인해야 했습니다.
02
문제 정의
- 조건 판단과 부수효과가 결합되어 조건만 독립적으로 테스트하기 어려움
- 새 시나리오를 추가할 때 초기화 함수 전체를 수정해야 함
- 컴포넌트의 this와 서비스·라우터 의존성이 순수 로직까지 전파됨
03
설계 판단
라우팅 조건과 목적지를 배열 기반 Strategy로 정의하고, 현재 상태를 전달하면 목적지만 반환하는 순수 함수를 만들었습니다. 목적지별 화면 데이터도 별도의 설정 객체로 분리했습니다.
BEFORE조건과 실행이 결합된 분기판단 · 데이터 구성 · 라우팅
AFTER순수한 목적지 결정판단 → 데이터 생성 → 실행
컴포넌트 메서드를 참조해야 하는 콜백과 실제 서비스·라우터 호출만 컴포넌트에 남겼습니다. 초기화 함수는 컨텍스트 생성, 목적지 결정, 데이터 생성, 콜백 주입, 실행의 다섯 단계만 조율합니다.
04
결과
- 라우팅 조건을 컴포넌트와 분리해 목적지 결정 함수를 독립적으로 테스트할 수 있게 됨
- 신규 시나리오 추가 범위를 전체 초기화 함수 수정에서 전략 항목 추가로 축소
- TypeScript Enum을 as const 객체로 바꿔 불필요한 런타임 코드를 제거
복잡한 분기에서 먼저 분리해야 할 것은 코드의 길이가 아니라 ‘판단’과 ‘실행’의 경계였습니다. 이 경계를 나누자 테스트와 시나리오 확장이 함께 단순해졌습니다.