게임 약관 초기화
로직 리팩터링

게임 약관 동의 페이지의 초기화 로직은 오랜 기간 요구사항이 추가되며 단일 함수 416줄, 결과 처리 switch-case 200줄까지 커졌습니다.

검증과 API 호출, 비즈니스 규칙, 화면 상태 변경이 한 흐름에 섞여 있었고 대부분의 작업이 switchMap으로 작성되어 최대 6단계까지 중첩됐습니다.

• 하나의 함수가 전체 초기화 책임을 가져 변경 영향 범위를 예측하기 어려움
• 여섯 개의 값을 튜플로 전달해 파이프라인 단계별 데이터 의미가 불명확함
• 오류 코드별 처리가 한 switch-case에 모여 독립적인 수정과 테스트가 어려움

전체 실행 순서는 Orchestrator가 담당하고, 세부 로직은 검증, 데이터 로딩, 비즈니스 규칙, 화면 상태 발행의 4개의 Service로 분리했습니다.

파이프라인 전체 데이터를 Context 객체에 누적해 각 단계의 입출력을 명시했습니다. 동기 변환은 map, API 호출은 switchMap, 부수효과는 tap으로 구분해 Operator의 의도도 드러냈습니다.

200줄의 switch-case는 오류 코드별 14개 Handler로 분리했습니다. Factory가 코드에 맞는 Handler를 선택하도록 해 각 케이스가 서로의 구현에 영향을 주지 않도록 했습니다.

여러 Handler에서 반복되던 오류 메시지 생성 로직은 공통 유틸리티로 옮겨 중복도 함께 제거했습니다.

• 6단계로 중첩됐던 switchMap을 제거하고 단계별 RxJS 파이프라인으로 재구성
• 여섯 값을 전달하던 튜플을 단일 Context 객체로 바꿔 데이터 흐름을 명시화
• 신규 오류 대응 범위를 기존 switch-case 수정에서 Handler 추가와 등록으로 축소

패턴을 적용하는 것보다 각 단계와 분기가 독립적으로 이해되고 테스트될 수 있게 만드는 데 집중했습니다. 그 결과 전체 흐름은 Orchestrator에서 읽히고, 세부 변경은 해당 Service나 Handler 안에서 끝나게 됐습니다.