제작기개요
웨이브웍스는 모바일 게임과 앱을 만드는 1인 회사이고, 지금은 5개 프로젝트를 AI 코딩 도구 Claude Code를 활용하여 동시에 개발합니다. Claude Code는 별도의 세팅이 없으면 새 대화(세션)를 열 때 이전 대화를 기억하지 못하는 문제가 있어 어디까지 했고 다음에 무엇을 할지를 문서로 넘기는 작업 방식에 대한 규칙이 필요합니다. 개발 단계를 현행화하기 위한 다양한 일정 관리 스킬과 플러그인도 있지만 저희에게 맞는다는 생각이 들지 않았습니다. 그래서 순정 상태에서 직접 규칙을 손봐 저희만의 작업 방식(ROADMAP.md와 STATE.md를 조합한 방식)으로 관리하고 있었는데, 문제는 그 문서가 세션마다 커져 읽는 토큰 비용이 늘었고, 동시에 여러 세션에서 여러 프로젝트를 진행하다 보니 한번 꼬이면 어디까지 진행했는지 찾지 못하거나 찾는 데 토큰 소모가 커지는 문제가 있었다는 점입니다. 그래서 기존 작업 체계를 전면 개편해 마크다운 문서로 관리하던 것을 JSON 형식으로 옮기고 완료와 검증을 따로 기록하도록 바꿨으며, 여러 프로젝트를 동시에 진행할 때 한눈에 볼 수 있는 대시보드도 만들어 한 화면에서 보게 했습니다. 효율은 아직 측정 전이지만 많은 부분에서 개선되었다고 체감하고 있습니다.
저희가 자체적으로 만든 대시보드로 프로젝트별 전체 진행률과 개발 단계, 진행 중인 작업을 한눈에 확인할 수 있습니다.
로드맵과 인계 문서가 커진 문제
프로젝트마다 저장소에 문서 두 개를 두었습니다. 로드맵은 할 일을 표로 적고 끝나면 체크 표시로 바꾸는 마크다운 파일이고, 인계 문서는 다음 세션이 이어서 일하도록 현재 상황과 다음 할 일을 적는 파일입니다. 세션은 작업을 마칠 때마다 두 문서를 고쳤고, 새 세션은 두 문서를 읽고 시작했습니다.
세션 수가 늘면서 인계 문서가 관리하기 어려울 만큼 커졌습니다. 상한을 12KB로 잡았지만 게임 두 개의 인계 문서는 46KB와 49KB가 되었는데, 할 일 목록과 결정 이유, 검증 결과, 변경 이력이 한 파일에 같이 쌓였기 때문입니다. 세션을 열 때마다 이 파일을 다 읽으니 시작 비용이 커졌고 어느 줄이 최신인지 찾기도 어려웠습니다.
로드맵 표도 비슷했습니다. 아기 수유·수면을 한 손으로 기록하는 앱 오 마이 베이비의 옛 로드맵은 224줄에 완료 표시 53개와 미완료 표시 44개가 있었는데, 한 칸에 1,700자가 넘게 들어간 행도 있었습니다. Play 콘솔의 사전 출시 보고서를 기다리며 확인한 시각을 21번 이어 적은 칸이어서, 작업 상태를 보려고 열었는데 기록을 읽어야 하는 문서가 된 것입니다.
더 큰 문제는 체크 표시가 말해 주지 않는 것이었습니다. 체크는 그때 끝났다는 사실만 뜻하기 때문에, 확인한 뒤 코드가 바뀌었는지와 실기기 확인을 실제로 했는지 생략하기로 했는지는 칸 안의 글을 읽어야 알 수 있었습니다. 프로젝트가 다섯 개가 되자 진행 상황을 보려면 저장소 다섯 곳의 로드맵과 인계 문서를 번갈아 열어야 했고, 문서 종류와 위치도 프로젝트마다 달라 같은 정보를 다른 자리에서 찾았습니다.
작업 목록을 JSON 파일로 옮기기
할 일 목록과 상태는 프로젝트마다 JSON 파일 세 개에 두는데, 프로젝트 정보와 작업 목록, 변경 기록입니다. 사람이 읽는 로드맵은 이 JSON에서 생성하고 첫 줄에 원본 JSON의 해시값을 적어 두기 때문에, 로드맵을 직접 고쳤거나 원본이 바뀐 뒤 다시 생성하지 않았으면 검사 명령이 잡아냅니다. 인계 문서에는 상황 설명만 남기고 작업은 ID로 가리킵니다.
작업은 다섯 층으로 나눕니다. 기획부터 운영까지 아홉 단계가 있고 단계 안에 작업 묶음(에픽), 묶음 안에 작업, 작업 아래 세부 작업과 점검 항목이 있는데, 진행률은 세 번째 층인 작업 수로만 계산합니다. 세션이 일하다가 세부 작업을 얼마든지 덧붙여도 진행률이 바뀌지 않게 하려는 선택입니다.
세션은 매번 전체 파일을 읽지 않고 요약 명령으로 현재 릴리스 진행률과 진행 중인 작업, 막힌 작업, 검사 결과를 한 번에 받습니다. 상태는 명령으로 바꾸고 바뀐 필드마다 변경 기록이 한 줄 남는데, 오 마이 베이비는 작업 176개를 옮긴 뒤 이틀 동안 변경 기록 167건이 쌓였습니다.
끝난 일의 확인이 낡았는지 알아내기
새 체계는 작업 완료와 검증을 따로 둡니다. 완료는 그 일을 했다는 상태이고 검증은 확인했으며 그 확인이 지금도 유효하다는 상태인데, 검증을 기록할 때 근거가 된 파일이나 문서 절의 해시값(sha256)을 함께 저장합니다. 해시값은 파일 내용을 짧은 값으로 줄인 것이어서 한 글자만 바뀌어도 달라지므로, 나중에 같은 파일의 해시값을 다시 계산해 다르면 완료 표시는 그대로 두고 검증이 낡았다는 표시만 따로 보여 줍니다.
확인을 생략하기로 한 경우도 기록 방식이 있습니다. 누가 언제 어떤 범위를 왜 면제했는지 적은 면제 기록을 남기고, 통과로 세지 않고 “통과(면제 N건)“로 구분해 보여 줍니다. 그래서 옛 로드맵에서 “실기기 확인 생략”이라고 칸에 적어 두던 것이 상태 값이 되어 걸러 볼 수 있습니다. 오 마이 베이비의 현재 릴리스에서 검증 기록이 있는 작업 중 유효한 통과는 5건, 면제는 61건으로, 면제가 많다는 사실이 이제 숫자로 보입니다.
작업 묶음마다 완료 조건 두기
새 프로젝트를 시작하면 단계별 에픽 틀을 깔아 줍니다. 처음 틀은 에픽 121개 중 자식 작업이 있는 것이 47개여서 화면이 빈 에픽으로 가득했고 에픽에 완료 조건도 없었기 때문에 틀을 다시 짰습니다. 공통 에픽 15개에 앱·게임·웹 유형별 에픽을 더하고, 에픽마다 무엇이 어디에 있어야 하고 누가 확인하는지를 완료 조건 점검표로 적었습니다. 빈 에픽은 접어서 진행률에서 빼고, 문의 대응이나 지표 확인처럼 출시 뒤 끝나지 않는 운영 일은 상시 에픽으로 따로 둡니다.
위 패널은 오 마이 베이비의 「기록·공유·알림·개인정보 정책」 에픽입니다. 상태가 “진행 중 (집계)“인 것은 에픽의 상태를 직접 정하지 않고 하위 작업 여섯 개에서 계산한다는 뜻입니다. 완료 조건과 하위 작업의 상태, 연결된 문서를 한 화면에서 보니, 이 에픽을 끝내려면 무엇이 남았는지 세션이 바로 알 수 있습니다.
대시보드에서 확인하는 것
대시보드는 다섯 프로젝트와 공용 패키지, 회사 웹사이트까지 일곱 저장소의 JSON을 읽는 로컬 웹 화면입니다. 숫자를 따로 계산하지 않고 요약 명령이 쓰는 같은 코드를 부르기 때문에, 카드 숫자가 명령 결과와 다르면 그 자체를 버그로 보기로 정했습니다.
프로젝트를 열면 개요 탭에서 단계별 진행률을 봅니다. 오 마이 베이비는 구현 단계보다 검증·출시 준비 단계가 더 남아 있고, 대기 작업으로 라이브러리 버전 올리기와 일본어·중국어 원어민 검수 두 건이 보입니다. 작업 탭은 단계별 트리에서 남은 것, 대기, 진행 중만 걸러 볼 수 있고 말단 작업의 상태는 화면에서 바로 바꿀 수 있는데, 바꾸면 변경 기록이 남습니다. 홈의 대기함에는 승인이나 외부 응답을 기다리는 작업이 모여 있어서, 저장소를 열지 않고도 어떤 결정이 밀려 있는지 알 수 있습니다.
아직 남은 문제
효율은 측정 전입니다. 이 체계는 만든 지 이틀이라 인계 비용과 세션 시작 시간이 얼마나 줄었는지는 아직 재지 않았습니다. 다섯 프로젝트 모두 검사 명령에서 오류는 없지만 경고는 많습니다. 3D 모형의 나사를 푸는 퍼즐 스크류 펀치 3D가 34건, 병아리를 한 줄에 하나씩 놓는 논리 퍼즐 삐약도쿠가 33건입니다. 모두 완료인데 검증 기록이 없다는 경고이고, 옛 로드맵의 체크 표시를 옮기면서 검증 근거까지 복원하지 못해서 생겼습니다. 출시한 게임 스쿨버스 지옥탈출은 카드에 46%로 나오는데, 출시 전 작업 기록을 아직 옮겨 넣지 않아 수치가 실제보다 낮습니다.
바꾸고 나서 분명히 달라진 점은 다섯 프로젝트의 진행 상황을 저장소 대신 화면 하나에서 보고, 끝난 일의 확인이 유효한지 면제인지를 숫자로 본다는 것입니다. 세션 시작이 얼마나 빨라졌는지는 몇 주 운영 기록이 쌓인 뒤에 알 수 있습니다.
