[maple-helper - 12] 메이플 헬퍼 중간 회고 리팩토링의 늪과 현실적인 타협점

회고AAR리팩토링트레이드오프애드센스

최근 메이플 헬퍼 프로젝트의 초기 목표가 크게 변경되었다. 앞으로의 프로젝트 방향성을 위해 AAR(After Action Review) 방식으로 중간 회고를 진행했다.

초기 목표 (Plan)

메이플 헬퍼는 약 1년 전에 만든 개인 프로젝트다. 기능 자체는 잘 동작했지만 시간이 지나면서 다음과 같은 기술 부채들이 점점 수면 위로 드러나기 시작했다.

  • UI와 비즈니스 로직이 한 파일에 무분별하게 섞여 있었다.
  • API 요청, 데이터 가공, 렌더링의 책임이 명확히 분리되지 않았다.
  • 폴더 구조와 네이밍 규칙이 파편화되어 일관성이 떨어졌다.
  • useContext 기반 상태 관리로 인해 상태 변경 로직이 컴포넌트 곳곳에 흩어져 유지보수와 확장이 한계에 달했다.

그래서 v2 업데이트에서는 단순히 새로운 기능을 추가하는 것을 넘어, 서비스 확장에 발목을 잡는 구조적 요소를 걷어내는 것을 가장 큰 목표로 잡았다.

메이플 헬퍼 v2 핵심 리팩토링 및 개발 목표

  1. API Router를 이용한 BFF 패턴 도입
  2. 서비스 확장을 고려한 구조 개선 (폴더 구조, 네이밍 컨벤션, 역할 분리)
  3. 주간 보스 계산기 상태 관리 구조 개선 (Zustand 도입)
  4. 신규 서비스 추가 (최초의 대적자 패링 연습장, 재획 기록 기능)

현실과 결과 (Reality)

하지만 리팩토링의 범위는 예상보다 훨씬 방대했다.

API 요청 로직을 분리하고, useContext로 엮여있던 전역 상태를 Zustand로 마이그레이션한 뒤 주보 캐릭터의 데이터 구조까지 수정하는 데에만 무려 3주가 소요되었다.

게다가 서비스 수익화를 위해 구조를 뜯어보던 중, 기존의 대시보드 중심 레이아웃이 구글 애드센스 같은 광고를 배치하기에 구조적으로 매우 불리하다는 치명적인 문제도 발견했다.

결국 목표를 전면 수정해야 했다. 개발을 가장 심각하게 방해하는 코어 구조만 단계적으로 개선한 뒤, 기존 레이아웃을 '전적 검색 사이트' 형태의 레이아웃으로 완전히 엎고 그 위에 내부 콘텐츠를 쌓아가는 방향으로 계획을 변경했다.

배운 점 (Lessons Learned)

개발 실력이라는 게 참 묘하다. 개발 당시에는 꽤 잘 짰다고 자부했던 코드도 6개월, 1년 뒤에 다시 열어보면 구조적으로 엉망인 경우가 많다.

이번 회고를 통해 얻은 가장 큰 교훈은 **"모든 문제를 새 코드로 완벽하게 해결하려고 드는 것은 리팩토링이 아니라, 오히려 서비스 운영과 확장을 가로막는 병목이 된다"**는 점이다.

문제가 있는 코드라도 프로젝트 확장에 치명적인 걸림돌이 되지 않는다면, 당장 고치지 않고 과감하게 기술 부채로 남겨두고 넘어가는 타협도 개발자의 중요한 역량이라는 것을 뼈저리게 배웠다.

개선점과 다음 목표 (Next Steps)

서비스 수익화를 위해 구글 애드센스를 조사해 본 결과, 단순히 껍데기 서비스를 하나 띄우고 광고를 다는 것만으로는 승인을 받기 어렵다는 사실을 확인했다. 승인을 위해서는 충분한 콘텐츠 양과 명확한 서비스 텍스트 구조가 필수적이었다.

따라서 메이플 헬퍼의 다음 최우선 목표는 **‘구글 애드센스 승인을 받을 수 있는 서비스로 탈바꿈하는 것’**으로 설정했다.

이를 달성하기 위해 다음 액션 아이템들을 진행할 예정이다.

  • 광고 영역 확보와 유저 사용성을 동시에 고려한 전체 레이아웃 개편
  • 광고 승인에 필요한 절대적인 콘텐츠 텍스트 양 확보
  • 개발 리소스를 적게 들이면서 빠르게 배포할 수 있는 '메이플스토리 관련 읽을거리성 정보 콘텐츠' 지속 추가