미니게임 몇 개를 연속으로 추가하고 나서, 작업 흐름이 눈에 띄게 나빠지기 시작했습니다. 가장 직접적인 신호는 토큰 소진이었습니다. 새 게임을 만들 때 AI에게 기존 게임 파일들을 참고로 넘겨줘야 하는데, 게임마다 구조가 달라 설명할 게 많아지다 보니 작업을 시작한 지 2시간도 안 돼서 컨텍스트 한도에 도달하는 일이 잦아졌습니다. 같은 날 다시 처음부터 세팅하고 이어가는 게 귀찮아서, 하루에 할 수 있는 작업량이 자연스럽게 줄어들고 있었습니다. 코드 자체도 문제였습니다. UI 구조나 상태 관리 방식이 게임마다 제각각이라, 한 게임에서 뭔가 고치면 다른 게임에도 비슷한 수정을 반복해야 했습니다. 이 상태를 그냥 두면 게임이 늘수록 더 나빠질 게 분명했습니다.
리팩터링 전에 테스트 코드부터
리팩터링을 하고 싶다는 생각은 있었는데, 막상 시작하려니 좀 무서웠습니다. 테스트 코드 없이 구조를 바꾸다가 무언가 조용히 망가질 수 있거든요. 프론트엔드 코드는 배포해서 직접 써봐야 알 수 있는 버그들이 많아서, 백엔드보다 훨씬 불안합니다. 그래서 순서를 바꿨습니다. 먼저 AI에게 현재 코드에 대한 테스트 코드를 작성해달라고 요청했습니다. 게임 데이터 구조가 올바른지, 필수 필드가 빠지지 않았는지, 다국어 번역이 모두 존재하는지 같은 항목들을 자동으로 검증할 수 있게 했습니다. 테스트가 갖춰진 상태에서 코드를 건드려야 뭔가 깨졌을 때 바로 알 수 있으니까요.
서버 개발하듯 공통을 먼저 찾아냈다
테스트 준비가 되자 본격적으로 리팩터링에 들어갔습니다. 접근 방식은 평소 백엔드 개발할 때와 비슷했습니다. 서버 코드를 짤 때 공통 로직을 서비스 레이어로 빼듯이, 여기서도 먼저 "게임들 사이에서 중복되는 게 뭔지 파악하라"고 AI에게 시켰습니다. 코드 전체를 훑어보게 하고 공통 패턴을 정리하는 작업부터 시킨 겁니다. 파악된 내용을 바탕으로 세 가지 방향으로 분리를 진행했습니다. 첫 번째는 UI 컴포넌트 통일이었습니다. 게임마다 제각각 구현돼 있던 결과 카드와 랭킹 대시보드를 공통 컴포넌트로 추출했습니다. 두 번째는 공통 기능을 훅으로 분리하는 작업이었습니다. 게임 진행 중 사운드를 처리하는 코드가 여러 게임에 흩어져 있었는데, 이를 단일 훅으로 묶었습니다. 세 번째는 파일 내 UI 로직과 비즈니스 로직 분리였습니다. 한 파일에 화면 렌더링 코드와 게임 진행 로직이 뒤섞여 있던 경우를 정리했습니다.
고치면 테스트, 고치면 테스트
작업 자체는 단순한 사이클의 반복이었습니다. AI한테 파일을 수정시키고, 전체 테스트를 돌리고, 실패하면 원인을 파악해서 다시 수정하는 패턴을 계속 반복했습니다. 힘든 점은 AI가 앞서 지시한 내용을 종종 이행하지 않는다는 거였습니다. 예를 들어 "결과 카드는 반드시 공통 컴포넌트를 써라"고 이미 말했는데, 다음 파일을 수정할 때 슬쩍 예전 방식으로 돌아가는 경우가 있었습니다. 파일이 많다 보니 AI가 앞의 지시를 잊어버리는 것인지, 아니면 그냥 내부적으로 뭔가 우선순위 처리가 달라지는 건지 알 수 없지만, 같은 말을 여러 번 반복해야 하는 상황이 꽤 있었습니다.
코드 20% 줄고 작업 시간 1시간 늘었다
결과는 기대했던 것보다 좋았습니다. 파일 하나하나의 크기가 눈에 띄게 줄었고, 전체 코드 양이 약 20% 줄어들었습니다. AI에게 파일을 참조시킬 때 불필요한 내용이 많이 빠지다 보니 토큰 소모도 줄었고, 한 세션에 작업할 수 있는 시간이 2시간에서 3시간 정도로 늘었습니다. 작은 것 같지만 체감 차이는 꽤 있었습니다. 하루에 두 번씩 세팅을 새로 해야 하던 게 한 번으로 줄어드니까요. AI 가이드는 리팩터링 전부터 운영하고 있었는데, 이번에 리팩터링된 구조 설명과 어떤 컴포넌트를 언제 써야 하는지에 대한 내용을 새로 추가한 것이 효과를 냈습니다. 이전보다 전반적으로 통일성 있는 결과물이 나오기 시작했고, 수정 요청을 보내는 빈도도 줄었습니다.
처음부터 큰 그림을 잡았으면?
리팩터링을 마치고 나서 든 생각은, 그래도 이 시점에 한 게 늦지 않았다는 것이었습니다. 물론 처음부터 공통 컴포넌트와 훅 구조를 잡고 시작했다면 이 시간을 아낄 수 있었겠죠. 하지만 솔직히 그건 만들어보기 전에는 알기 어렵습니다. 어떤 패턴이 공통으로 쓰이게 될지, 어떤 부분이 복잡해질지는 게임을 직접 몇 개 만들어봐야 보이기 시작했습니다. 처음부터 완벽한 구조를 설계하려고 했으면, 실제로는 쓸모없는 추상화를 잔뜩 만들고 시작이 늦어졌을 가능성이 큽니다.
서비스란 게 원래 그런 것 같습니다. 만들면서 부족한 점을 발견하고, 발견하면 고치고, 고치면 또 다른 게 보이고. 처음부터 완벽한 설계도를 그리고 시작하는 사람은 거의 없을 테고, 그렇게 하는 게 항상 옳은 것도 아닐 거라고 생각합니다. 이번 리팩터링이 주는 교훈이 있다면, 너무 오래 쌓아두기 전에 정리하는 시간을 가지는 게 좋다는 것 정도입니다. 기술 부채는 빨리 갚을수록 이자가 덜 붙으니까요.