Manyfast로 바이브코딩 재작업 줄이기: 구현 전에 정책을 정하는 기획 워크플로

Manyfast로 바이브코딩할 때 재작업을 줄이는 핵심은 두 가지입니다. 기획을 구조화해 개발 도구가 읽을 수 있게 만들고, 구현에 들어가기 전에 권한·예외·완료 조건을 정해 두는 거예요. 누가 기능을 쓰는지, 실패하면 어떻게 처리할지, 무엇을 충족해야 완료로 볼지를 먼저 결정하면 정책이 빠져서 코드를 다시 고치는 일을 줄일 수 있습니다.

처음 살펴볼 것은 문서 분량이 아니라 아직 결정하지 않은 사항입니다. 기능과 화면이 다 정리돼 있어도 접근 권한이나 예외 동작이 비어 있으면, 그 빈자리는 개발 도구가 임의로 판단해 채우게 돼요. 이 글에서 말하는 재작업은 빠뜨린 정책 때문에 생기는 수정을 가리킵니다. 아래 순서는 Manyfast의 공식 기능을 조합한 실무 제안이에요.

PRD와 기능명세서에는 무엇을 정해 둬야 할까

PRD에는 제품 목표, 사용자 문제, 해결 방향과 성공 기준을 정리합니다. 무엇을 왜 만드는지 판단하는 기준 문서인 만큼, 이번에 구현할 범위와 제외할 범위도 같이 적어 두길 권해요. 이 경계가 흐릿하면 세부 동작을 아무리 꼼꼼히 정의해도 개발 범위가 계속 늘어날 수 있습니다.

기능명세서는 이 내용을 ‘요구사항 → 기능 → 상세 기능’으로 구체화하는 문서입니다. 요구사항에는 수용 기준을, 기능에는 사용자 역할을, 상세 기능에는 실제 동작과 정책을 씁니다. 여기에 있는 개발 준비 슬롯은 선행조건·트리거·동작·결과·예외·표시·권한 및 접근·비즈니스 규칙·데이터를 정리하는 틀이에요. 모든 칸을 채우려고 애쓰기보다는 구현 판단에 필요한 내용을 분명하게 쓰는 데 힘을 쏟는 편이 낫습니다.

‘문서 공유’ 기능을 기획한다고 해 볼게요. ‘문서를 공유할 수 있다’에서 멈추면 개발 도구가 판단할 몫이 너무 많이 남습니다. 공유 주체를 문서 소유자로 제한할지부터 정하고, 권한 없는 사용자가 링크를 열었을 때 내용을 노출하지 않고 접근 거부 안내를 보여주도록 정할 수도 있어요. 완료 조건에는 허용된 사용자의 열람 성공과 권한 없는 사용자의 접근 차단을 함께 넣어 두세요.

작성률보다 먼저 볼 것은 개발 도구가 임의로 결정해야 할 사항이 아직 남아 있는지입니다.

여기서 흔히 헷갈리는 지점이 있습니다. 슬롯을 다 채웠는데도 ‘누구나 링크로 열람’과 ‘초대된 사용자만 열람’이 함께 적혀 있다면 구현 기준은 여전히 불명확해요. 빈칸이 몇 개인지와 정책이 서로 맞는지는 따로 확인해야 합니다.

범위 확정부터 구현 검증까지, 6단계로 진행하기

기획을 넘기기 전에는 범위를 좁히고, 구현이 끝나면 같은 명세로 결과를 확인합니다. 아래 순서를 따르면 결정한 정책과 코드가 어떻게 연결되는지 추적하기 쉬워요.

1. PRD에 사용자 문제와 이번 구현 범위, 제외 범위를 명시합니다.
2. 상세 기능마다 권한·예외·완료 조건을 결정하고, 미결정 사항을 구분합니다.
3. 유저플로우와 화면을 대조해 정상 동작뿐 아니라 접근 거부와 실패 이후의 흐름도 반영됐는지 확인합니다.
4. MCP로 기획을 읽힌 뒤, 개발 도구에 구현 대상·미결정 사항·개발 순서를 먼저 설명하도록 요청합니다.
5. 구현 후 명세별로 해당 코드의 근거와 테스트 결과를 확인합니다.
6. 정책이 바뀌면 기획을 갱신하고, 개발 도구가 변경 내용을 다시 읽었는지 확인한 뒤 코드를 수정합니다.

MCP는 Manyfast의 기획 데이터를 외부 AI 개발 도구가 읽을 수 있게 이어 주는 통로입니다. MCP 연결 가이드대로 서버를 등록하고 OAuth 로그인을 마친 다음, 접근 가능한 프로젝트 목록을 요청해 보면 연결됐는지 확인할 수 있어요. 조회하거나 작업할 수 있는 범위는 프로젝트 권한과 그룹 플랜에 따라 달라지니, 쓰는 환경에서 어디까지 지원되는지도 확인해 두세요.

코드 생성과 수정은 Manyfast가 아니라 연결한 개발 도구에서 이뤄집니다.

이 여섯 단계 중에서 저는 네 번째를 특히 놓치지 말라고 말하고 싶습니다. 도구가 이해한 내용을 먼저 설명하게 하면, 기획에 없는 정책을 덧붙였거나 제외 범위를 구현 대상으로 잡은 경우를 코드를 쓰기 전에 바로잡을 수 있기 때문이에요. 다섯 번째 단계에서도 ‘구현 완료’라는 답변을 그대로 받아들이기보다, 각 완료 조건을 어떤 코드와 테스트로 충족했는지 하나씩 연결해 보세요.

기획이 바뀌었을 때, 그리고 효과는 어떻게 판단할까

MCP로 최신 기획을 조회할 수 있다는 말이 기획을 바꾸는 즉시 코드도 바뀐다는 뜻은 아닙니다. 변경한 뒤에는 개발 도구에 다시 조회해 달라고 요청하고, 읽어 온 내용과 수정 대상을 직접 확인해야 해요. PRD 검토 항목도 마찬가지예요. ‘해결’ 표시만 한다고 문서가 바뀌지는 않으므로, 수정안을 생성하고 실제로 반영됐는지까지 확인하세요.

효과를 따질 때는 기능을 지원한다는 사실과 성과 수치를 구분해서 봐야 합니다. Manyfast는 구조화된 기획과 코드를 대조해 결제 서비스 연동 누락을 찾아낸 자사 사례를 소개했어요. 다만 공급사가 공개한 단일 사례라서, 이를 모든 프로젝트의 재작업 감소율로 넓혀 해석하기는 어렵습니다.

실무에서는 비슷한 범위의 작업끼리 비교하면서, 구현 후에 새로 결정한 정책과 그 때문에 든 수정 시간을 기록해 보길 권합니다. 핵심은 처음부터 정할 수 있었던 조건이 뒤늦게 추가되는 일이 줄었는지예요. 구현 전에 정책을 정리한 효과를 판단하는 데는 문서를 얼마나 썼는지보다 이 기록이 더 직접적인 기준이 됩니다.