혹시 이런 적.. 있으신가요?

• 만든 지 오래돼 기획 문서는 사라졌는데, 서비스만 덩그러니 돌아가고 있어요.
• 외주로 받은 서비스라, 어떻게 기획되었는지 우리도 잘 몰라요.
• 리뉴얼을 하려는데 지금 시점의 서비스의 구조가 정리가 안 돼 막막해요.
• 잘 만든 서비스를 참고해서 우리 신규 기획의 레퍼런스로 삼고 싶어요.

하나라도 고개가 끄덕여졌다면, 오늘 글이 딱이에요.

코드만 있으면 — 공개된 오픈소스든, 우리가 가진 서비스든 — 매니패스트로 잘 짜인 기획 문서를 '거꾸로' 뽑아낼 수 있거든요. 이게 정말 되는지, 직접 해보면서 보여드릴 거예요.

먼저, 이 주제를 쓰게 된 계기부터 말씀드릴게요.

여느 때처럼 고객의 피드백을 확인하고 응대하던 중, 이런 요청을 보게 되었습니다.

“이미 개발된 서비스도 매니패스트로 다시 정리할 수 있나요?”

음.. 문득 저희도 궁금해졌습니다.

이미 만들어진 서비스를 매니패스트가 잘 갖춰진 기획 문서로 다시 정리해낼 수 있을까?

서비스가 있다는 것은 코드가 있다는 것이고, 코드 안에는 어떤 기능이 있는지, 어떤 데이터가 오가는지, 사용자가 어떤 화면을 거치는지가 어느 정도 구현되어 있을 겁니다.

그렇다면 Codex가 이 코드를 읽고 매니패스트 MCP를 통해 그 내용을 매니패스트에 옮겼을 때 매니패스트는 기존 서비스의 구조를 얼마나 잘 정리할 수 있을까요?

그래서 이번 사례집에서는 이 부분을 직접 실험해보기로 했습니다!

💡 역기획은 코드에 접근할 수 있을 때 가능해요. 공개된 오픈소스이거나, 내가 소유한 서비스라면 똑같이 할 수 있답니다.

이번 사례에서 사용할 프로젝트 살펴보기

이번에 역기획해볼 서비스는 액추얼 버짓(Actual Budget) 이라는 오픈소스 가계부예요.

수입과 지출을 기록하고 카테고리마다 예산을 세워 '지금 쓸 수 있는 돈'을 한눈에 관리하도록 도와주는 도구죠. 가장 큰 특징은 모든 데이터를 외부 서버가 아니라 사용자의 기기에 먼저 저장하는 '로컬 우선(local-first)' 방식이라는 점, 그리고 코드가 GitHub에 공개되어 있어 구조를 직접 들여다볼 수 있다는 점이에요.

이번 역기획은 Codex와 매니패스트 MCP로 진행할게요.

우선, 이 서비스가 어떤 기능들을 갖추고 있는지 설명해드릴게요!

핵심 기능은 크게 네 가지예요.

1. 먼저 계좌·거래 관리예요. 입출금 계좌나 신용카드 같은 여러 계좌를 만들어두고, 거래를 직접 입력하거나 은행 연동으로 자동으로 불러올 수 있어요. 불러온 거래는 카테고리·수취인(거래 상대, payee)·메모를 붙여 정리하고, 분할 거래나 계좌 간 이체도 기록할 수 있죠.

2. 이 서비스의 핵심은 예산 짜기예요. 액추얼 버짓은 가진 돈을 카테고리라는 봉투에 미리 나눠 담는 '봉투 예산(Envelope Budgeting)' 방식을 기본으로 삼는데요, 모든 돈에 역할을 부여하고 이번 달에 남은 돈을 다음 달로 이월하는 흐름이 자연스럽게 이어져요. 카테고리별 목표(goal)를 설정해 매달 예산을 채우는 수고를 덜 수도 있답니다.

3. 여기에 자동화와 리포트가 더해져요. 규칙(Rules)으로 특정 거래를 자동 분류하고, 예약 거래(Schedules)로 월세·구독료 같은 정기 지출을 미리 등록할 수 있어요. 그렇게 쌓인 데이터는 순자산·현금 흐름·지출 분석 같은 리포트로 한눈에 돌아볼 수 있죠.

이 밖에도 태그·수취인 관리·필터 검색을 갖추고 있고, 별도의 동기화 서버를 연결하면 여러 기기에서 함께 쓸 수도 있어요. 웹·데스크톱·모바일 어디서든 쓸 수 있는, 가계부에 필요한 핵심 흐름을 두루 갖춘 서비스랍니다.

자, 이 정도로 오늘 사례집에서 사용할 서비스에 대해 살펴보았습니다.

이제 Codex를 통해 해당 서비스의 코드와 구조를 분석할 거예요. 그리고 연결된 매니패스트 MCP를 활용해, 매니패스트 안에 PRD, 기능명세서, 유저플로우 형태로 정리해보겠습니다!

저희가 이번 사례에서 확인하고 싶은 것은 단순히 ’AI가 코드를 요약할 수 있는가?’가 아닙니다.

이미 개발된 서비스 안에 숨어 있는 제품의 목적, 핵심 기능, 사용자 흐름, 기능별 조건을 매니패스트가 팀이 함께 볼 수 있는 기획 문서로 얼마나 잘 정리해주는지 확인하는 것이죠.

즉, 이번 사례는 이미 만들어진 서비스를 다시 불러와 매니패스트가 어떤 기획 구조로 정리하고, 어떻게 기획 문서로 되돌리는지 확인하는 역기획 실험입니다!

Codex와 Manyfast MCP를 함께 사용했을 때 기존 서비스가 어떤 기획 문서로 정리되는지, 그리고 그 결과물이 실제로 얼마나 활용 가능한지 함께 확인해봅시다.

👉MCP 연결 방법은 이번 사례집에서 자세히 다루지 않아요. 가이드 문서를 참고해 Codex에 매니패스트 MCP를 미리 연결해주세요! [연결 가이드]

Step 1. Codex에게 서비스 구조 넣기

먼저 할 일은 역기획할 프로젝트의 코드를 Codex 손에 쥐여주는 거예요. 액추얼 버짓은 코드가 GitHub에 공개돼 있으니, 저장소를 그대로 받아와 Codex가 읽을 수 있는 자리에 두면 됩니다.

프로젝트 코드 가져오기

먼저 액추얼 버짓의 GitHub 저장소를 로컬로 내려받습니다. 터미널에 아래 한 줄이면 충분해요.

git clone <https://github.com/actualbudget/actual.git>

내려받은 폴더를 Codex가 작업할 위치로 열어두면 준비 끝이에요. Codex는 이 폴더 안의 코드를 직접 읽으면서 분석을 시작하게 됩니다.

Codex에게 분석 요청하기

이제 Codex에게 "이 코드를 읽고, 기획 문서로 되돌리기 위한 사전 분석을 해줘"라고 요청할 차례예요. 곧바로 매니패스트로 넘기기 전에, 코드 안에 무엇이 들어 있는지부터 Codex가 스스로 정리하게 하는 단계죠. 아래 프롬프트를 그대로 넣어볼게요.

이 프로젝트는 오픈소스 가계부 서비스야. 
코드 전체를 읽고, 나중에 기획 문서로 되돌리기 위한 사전 분석을 해줘. 

다음 네 가지를 정리해줘:
1. 제품의 목적과 핵심 가치 — 이 서비스가 사용자에게 무엇을 해결해 주는가 
2. 핵심 기능 — 계좌·예산·거래·자동화·리포트처럼 기능 단위로 
3. 주요 데이터 구조 — 어떤 데이터가 오가는지
4. 사용자 화면 흐름 — 사용자가 거치는 주요 화면과 동선 

추측이 아니라, 실제 코드에 구현된 내용을 근거로 정리해줘. 

Codex가 읽어낸 구조 살펴보기

잠시 기다리면 Codex가 분석 결과를 정리해 줍니다.

코드만 읽고도 이 서비스를 "로컬 우선 가계부 + 선택적 동기화 + 월간 예산 편성" 제품이라고 한 줄로 요약하고, 계좌·거래·예산·규칙·스케줄·리포트까지 핵심 기능을 빠짐없이 짚어냈죠. README의 'local-first personal finance tool' 소개 문구와 실제 코드 동작을 근거로 제시도 했네요!

우리가 앞에서 소개했던 기능들을, 사람이 알려주지 않았는데 코드만 보고 정리해낸 거예요.

이 결과물이 다음 단계에서 매니패스트로 옮길 '재료'가 됩니다.

Step 2. 매니패스트 MCP로 옮기기

여기서부터가 이번 실험의 핵심입니다!

Codex가 코드에서 읽어낸 구조를 이제 매니패스트로 넘길 차례예요. 흩어진 코드 분석이 매니패스트 안에서 PRD·기능명세서·유저플로우라는 기획 문서 형태로 다시 짜이는지 확인할 차례거든요!

매니패스트로 정리 요청하기

앞에서 Codex가 분석한 내용을 매니패스트 MCP로 옮겨 달라고 요청할 차례입니다.

그런데 그 전에 두 가지 사항을 확인 후 진행하세요!

• 매니패스트 MCP가 Codex에 연결돼 있어야 해요.
  • 서론의 연결 가이드 링크를 확인하여 MCP 연결을 완료해주세요.
• 프롬프트 입력 전, 빈 프로젝트를 먼저 만들어두세요.
  • 매니패스트 MCP는 새 프로젝트를 직접 만들지는 못하고, 이미 있는 프로젝트 안을 채워주는 역할을 해요. 그래서 매니패스트에서 빈 프로젝트를 하나 먼저 만들어두고, 그 프로젝트 제목을 Codex에게 알려주면 됩니다. 그러면 Codex가 PRD·기능명세서를 채워줄 거예요.

물론, 위 두 가지 사항이 충족되지 않아도 Codex나 Claude와 같은 에이전트들은 다음 진행을 위해 위의 조건을 알아서 안내할겁니다. 어쨌든, 위의 두 가지는 꼭 충족되어야 다음으로 진행되니 참고해주세요.

이제 프롬프트를 입력해보겠습니다!

방금 코드에서 분석한 내용을, 연결된 매니패스트 MCP를 사용해 매니패스트에 정리해줘. 


1. 내가 매니패스트에 만들어 둔 프로젝트(제목:액추얼 버짓 역기획)에 작성해줘. 

2. PRD에 제품의 목적·핵심 가치·타깃 사용자·핵심 기능을 채워줘. 

3. 기능명세서에 계좌·거래·예산·자동화(규칙/스케줄)·리포트 등을 
기능 단위로 정리해줘.



분석에서 찾은 코드 근거를 바탕으로, 실제 구현된 기능을 빠짐없이 작성해줘. 
 

PRD·기능명세서로 자동 정리

프롬프트를 넣으면 Codex가 매니패스트 MCP의 도구들을 차례로 부르면서, 빈 프로젝트 안에 PRD부터 기능명세서까지 하나씩 채워 나가요. 코드 더미였던 내용이 팀이 함께 볼 수 있는 기획 문서 형태로 옮겨지는 순간이죠. 잠시 기다리면 매니패스트 프로젝트 안에 문서가 생성된 걸 확인할 수 있어요.

일단, 일괄 승인으로 문서들을 채운 후 유저플로우 생성으로 넘어가볼게요.

유저플로우는 매니패스트에서 생성하기

PRD와 기능명세서가 채워졌으면, 유저플로우는 매니패스트 안에서 만들면 됩니다. 앞서 정리된 기획 내용을 바탕으로 매니패스트가 사용자 화면 흐름을 그려줄 거예요.

이렇게 'MCP가 채운 문서'와 '매니패스트가 그린 흐름'이 한 프로젝트 안에 모이면, 코드에서 출발한 역기획이 비로소 온전한 기획 문서 한 벌로 완성돼요.

Step 3. 작성된 기획 문서 뜯어보기

이제 가장 궁금했던 걸 확인할 차례예요. 코드에서 출발한 분석이 매니패스트 안에서 어떤 기획 문서가 됐는지, 그리고 맨 앞에서 소개한 기능들이 정말 잘 담겼는지 직접 뜯어볼게요.

처음 소개한 기능들이 다 들어왔을까?

매니패스트 안에는 요구사항 8개, 기능 32개, 스펙 39개가 만들어졌어요. 앞에서 소개한 핵심 기능과 맞춰보면 이렇게 빠짐없이 들어왔죠.

여기에 로컬 우선 데이터 관리, 화면·내비게이션, 설정·태그·권한까지 더해져서, 오히려 소개글보다 촘촘하게 정리됐어요. 매니패스트 기능명세서를 트리뷰로 살펴보고, 엑셀로 내보내 열어보니 기능 정리가 아주 잘 돼 있었어요!

이 내용, 어떻게 이렇게 구체적일까

기능이 많이 잡힌 건 알겠는데, 진짜 궁금한 건 이거예요.

‘이게 코드를 보고 정확히 쓴 걸까, 아니면 그럴듯하게 지어낸 걸까?’

그래서 한 항목을 골라 실제 코드와 대조해봤습니다. 예를 들어 태그 기능의 스펙은 이렇게 적혀 있어요.

태그는 id, tag, color, description, tombstone, hidden 필드를 가지며 tags-get/create/update/delete API와 ManageTagsPage에서 관리된다.

코드 용어가 섞여 있어 낯설어 보이지만, 풀어보면 어렵지 않아요.

• id, tag, color, description, tombstone, hidden — 태그 하나가 품는 데이터 항목이에요. 쉽게 말하면 태그의 이름(tag), 색상(color), 설명(description), 숨김 여부(hidden) 같은 것들이죠. (id는 식별자, tombstone은 동기화용 내부 표시예요.)
• tags-get / create / update / delete — 태그를 불러오고·만들고·고치고·지우는 기능 묶음이에요. 흔히 말하는 '생성·조회·수정·삭제'죠.
• ManageTagsPage — 태그를 관리하는 화면 그 자체예요.

눈여겨볼 것은 이게 두루뭉술한 설명이 아니라 코드 속 실제 이름과 화면까지 콕 집어서 적혀 있다는 점이에요.

우리가 Step 1·2에서 "코드 근거를 바탕으로 정리해줘" 라고 요청했기 때문에, Codex가 추상적으로 얼버무리지 않고 실제 구현에서 끌어온 근거로 채운 거죠. 실제로 각 항목 끝에는 "구현 근거: …/tags/app.ts" 처럼 어느 파일에서 가져왔는지 출처까지 붙어 있어요.

즉, 매니패스트에 담긴 내용은 상상이 아니라 코드 근거에 정확히 들어맞는 결과였어요. 역기획이 단순 요약이 아니라, 실제 구조를 짚어냈다는 걸 확인한 거죠.

Step 4. 한 걸음 더 — 사람이 읽는 기획서로

Codex가 정리해 준 것처럼 코드 근거에 충실한 정리는 정확하다는 게 큰 장점이에요. 하지만 이대로 ‘기획서’로 부르기엔 부족한 측면이 많습니다.

코드를 가진 개발자에겐 더없이 친절한 '지도'지만, 코드 없이 이 문서만 받은 사람에겐 조금 불친절할 수 있어요.

즉, 코드를 아는 사람에게만 또렷한 용어로 적혀 있고, 일반 사람들은 이해할 수 없는 기획서가 되는 겁니다.

그렇다고 우리가 문서를 일일이 손볼 필요는 없답니다! 이어서 코덱스에게 프롬프트를 통해 부탁해볼게요.

방금 만든 PRD와 기능명세서를 일반사람도 이해할 수 있는 기획서 톤으로 매니패스트에 다시 정리해줘. 


1. API 이름이나 컴포넌트 파일명 같은 코드 용어 대신, 
 사용자가 무엇을 할 수 있는지(행동)와 화면이 어떻게 동작하는지를 중심으로 써줘. 

2. 각 기능은 '사용자는 ~할 수 있다' 형태의 수락 기준으로 풀어줘. 

3. 동기화용 tombstone 같은 내부 구현 필드는 본문에서 빼고, 
 꼭 필요하면 '개발 참고'로 따로 덧붙여줘. 
 

코덱스는 프롬프트를 받고 다시 매니패스트로 들어가, 같은 내용을 사람이 읽기 편한 문장으로 정리해줍니다.

코드 용어로 빼곡하던 태그 기능이 이렇게 바뀌었어요.

Before — 코드 근거 톤

태그는 id, tag, color, description, tombstone, hidden 필드를 가지며 tags-get/create/update/delete API와 ManageTagsPage에서 관리된다.

After — 기획서 톤

사용자는 태그 이름, 색상, 설명을 설정해 거래를 더 세밀하게 정리할 수 있고, 필요 없는 태그를 숨기거나 삭제할 수 있다.

보너스 — 와이어프레임, 그리고 피그마까지

기획 문서가 갖춰지면, 매니패스트는 한 발 더 나아가 와이어프레임(화면 밑그림)까지 그려줘요.

PRD와 기능명세서에 정리된 화면들을 바탕으로, 각 화면이 대략 어떤 모습일지 레이아웃을 잡아줍니다. 유저플로우와 마찬가지로, 이것도 코드나 코덱스가 아니라 매니패스트 안에서 생성하면 됩니다.

이번 사례의 핵심이었던 예산 화면을 뽑아, 실제 서비스와 나란히 놓아봤어요.

물론 완전 똑같지는 않아요. 😅 매니패스트는 화면을 베끼는 게 아니라, 기능을 읽고 깔끔한 화면 구상으로 다시 그려주거든요.

그래도 월별 예산 요약, 카테고리별 진행률(식비 84%, 의료는 140% 초과까지!), 수취인 자동 분류, 자동화 규칙 현황처럼 우리가 앞에서 소개한 핵심 기능들이 화면 밑그림 위에 고스란히 자리 잡은 게 보이죠. 코드 한 덩어리였던 서비스가 ‘눈에 보이는 화면’으로까지 되돌아온 거예요.

이렇게 PRD → 기능명세서 → 유저플로우 → 와이어프레임 → 피그마까지. 이미 만들어진 서비스 하나가, 기획부터 디자인 직전까지 이어지는 문서 한 벌로 온전히 되살아났네요!

마무리하며

처음 질문이었던 "이미 만들어진 서비스도 기획서로 되돌릴 수 있을까?" 의 답은 "된다" 였어요. 그럼 한 걸음 더, 진짜 궁금한 걸 짚어볼게요. 이 역기획, 실제로 어디에 써먹을 수 있을까요?

글 첫머리에서 "이런 적 있으신가요?"로 꺼냈던 상황들 — 문서가 사라진 서비스, 외주로 받아 속 모르는 서비스, 리뉴얼 앞에서 막막한 서비스, 참고하고 싶은 잘 만든 서비스 — 기억하시나요? 이제 그 모든 경우에, 코드만 있으면 매니패스트가 PRD·기능명세서·유저플로우·와이어프레임까지 한 벌의 기획 문서로 되돌려줘요.

결국 공통점은 하나입니다.

코드는 있는데 기획이 없는 상황도 매니패스트가 다시 잘 정리된 기획 문서로 만들어줄 수 있다는 것!

새로 만드는 서비스의 기획만이 아니라, 이미 세상에 나온 서비스를 다시 정리하는 일에도 매니패스트를 쓸 수 있다는 얘기죠.

혹시 지금 떠오르는 서비스가 있다면, 그게 바로 역기획으로 정리해볼 첫 번째 후보일지도 몰라요. 🐢