한 달 프로젝트가 세 달이 되는 이유, AI 개발도 기준 문서에서 갈립니다 (Manyfast 허재혁 대표님)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

한 달 프로젝트가 세 달로 늘어나는 일을 줄이려면, AI 개발에서도 합의한 범위와 변경 이유, 승인 이력을 축적하는 기준 문서가 필요하다.

📌 핵심 요점

1. 일정 지연은 합의한 범위를 기록하지 않는 데서 시작된다. 회의에서 정한 기능과 유지보수 조건을 즉시 문서로 공유하지 않으면 고객사와 수행사의 해석이 달라지고 추가 작업이 쌓인다.
2. AI 협업에는 문서의 우선순위와 결정의 맥락이 필요하다. 회의록과 기획서가 어긋나거나 변경 이유가 빠지면 에이전트마다 다르게 추측해 구현 오류로 이어질 수 있다.
3. 매니페스트는 기획서 생성에서 지속적으로 활용하는 SSOT로 방향을 넓혔다. 사람에게 익숙한 차트·와이어프레임과 AI가 읽는 JSON 데이터를 연결하며, 코드와의 불일치를 확인하는 ‘살아 있는 기획서’를 목표로 한다.
4. 변경은 사람이 승인하고 문서 사이의 차이를 확인해야 한다. 회의에서 관련 결정을 추출해 수정안을 연결하고, PM이 승인한 뒤 기능 명세와 유저 플로우의 불일치를 확인하는 흐름을 제시한다.
5. 기업 도입에는 개발과 보고를 함께 지원하는 설계가 필요하다. 온프레미스 구축, 기업 보유 모델 연결, 사내 양식에 맞춘 출력으로 조직의 제약에 대응하며 국내에서는 기업·팀 고객, 해외에서는 PLG를 추진할 계획이다.

🧩 배경과 문제 정의

• 회의에서 결정한 기능·범위·유지보수 조건을 기준 문서에 남기고 공유하지 않으면, 이해관계자의 기억과 해석이 달라져 일정과 작업량이 늘어난다.
• AI 에이전트는 파편화된 문서에서 변경 이유와 우선순위를 알기 어렵다. 최신 결정과 그 맥락이 빠지면 추측에 의존하고, 그 추측이 구현 오류로 이어질 수 있다.
• 매니페스트는 기획서를 빠르게 생성하는 도구에서, 사람과 AI가 함께 읽고 변경 이력과 합의를 축적하는 SSOT를 지향하는 도구로 방향을 넓혔다.

🕒 시간순 섹션별 상세정리

1. 기획서 생성보다 기준 문서의 지속적인 활용이 중요해졌다

• 매니페스트의 이용자는 이전 출연 당시 약 3,000명에서 약 3만 명으로 늘었고, 17개국에서 사용하는 서비스로 확장됐다. [01:24]
• 초기 제품은 여러 도구로 분산된 기획 작업을 모아 기획서를 빠르게 만들고 공유하는 데 집중했다. [02:25]

2. 파편화된 기획 자료는 AI의 추측을 늘린다

• 위키와 지식 저장 도구는 자료를 쌓기에는 적합하지만, 축적된 기획 데이터를 수정·삭제하고 조정하는 과정이 불편하다. 와이어프레임과 유저 플로우까지 여러 곳에 흩어지면 관리가 더 어려워진다. [04:25]
• 사람은 도표나 손그림도 읽을 수 있지만, 코드와 텍스트를 읽는 AI는 스키마가 맞지 않으면 내용을 착각하거나 추측할 수 있다. 문서 구조와 데이터의 일관성이 중요해지는 이유다. [05:25]

3. 합의한 범위를 기록하지 않으면 프로젝트가 길어진다

• 고객사와 수행사 사이에 기준 문서가 없고 회의 결정을 당시 공유하지 않으면, 어떤 기능까지 제공하기로 했는지를 두고 해석이 달라진다. [06:25]
• 이런 상황에서는 한 달로 예상했던 프로젝트가 두 달, 세 달로 늘어나기도 한다. 유지보수 범위까지 불명확하면 6개월 뒤에도 추가 작업을 요구받는 일이 생긴다. [06:52]

4. AI 협업에는 결정의 권위와 변경 이유가 필요하다

• 사람끼리 회의하면 의도와 맥락이 참여자에게 남지만, 각자의 컴퓨터에서 독립적으로 일하는 AI 에이전트는 이를 공유하지 못한다. 회의록과 기획서가 어긋나고 우선순위도 없으면 에이전트마다 다르게 해석할 수 있다. [07:28]
• 일관된 작업을 위해서는 어떤 문서가 우선하는지 명확한 권위가 있어야 한다. [08:12]

5. 살아 있는 기획서는 코드와의 차이를 확인할 수 있어야 한다

• 소프트웨어 기획에서 좋은 SSOT의 조건은 코드와 동기화돼 있고, 기획과 코드가 어긋났을 때 이를 알리고 확인할 수 있는 것이다. [10:42]
• 이런 조건을 갖춘 문서를 ‘살아 있는 기획서’로 정의하며, 매니페스트는 이를 구현하는 제품을 목표로 삼고 있다. [10:58]

6. 노션으로도 SSOT를 만들 수 있지만 관리 부담이 크다

• 노션도 수정할 때마다 새 버전을 만들고 이전 버전에서 바뀐 이유를 댓글로 기록하면 좋은 SSOT가 될 수 있다. 다만 이를 유지하려면 수작업이 많이 필요하다. [12:06]
• 노션의 스키마는 AI가 활용하기 좋은 구조라는 평가와 별개로, 현업 PM과 기획자가 내용을 보고 의사결정하기에 적합한 명시성을 갖췄는지는 다른 문제다. [12:33]

7. 저장된 스냅샷만으로는 기준 문서가 완성되지 않는다

• 특정 시점의 문서를 저장해 놓은 스냅샷을 SSOT로 여기는 경우가 많다. 하지만 권위 있는 기준 문서에는 변경 이력뿐 아니라 변경 의도와 맥락도 계속 축적돼야 한다. [13:34]
• 사람이 한눈에 이해하기 좋은 한 페이지를 만들고 버전을 저장하는 것만으로는, AI까지 함께 활용할 기준 문서의 조건을 충족하기 어렵다. [14:02]

8. 사람의 시각화와 AI의 구조화된 데이터를 함께 맞춘다

• 사람은 플로우 차트, 와이어프레임, 깊이별로 정리된 기능 명세처럼 시각적 구조가 있는 기획서를 이해하기 쉽다. AI가 읽기 편한 텍스트·코드 중심 표현과는 차이가 있다. [14:25]
• 두 가지 읽기 방식을 동시에 지원해야 명확한 SSOT가 된다는 것이 매니페스트의 가설이며, 제품 설계도 이 방향을 따른다. [14:51]

9. 대기업 기획팀은 AI 개발과 기존 보고 체계 사이에서 이중 작업을 한다

• 방문한 대기업 사례에서는 개발팀이 AI와 코드 기반 문서를 활용하는 반면, 기획팀은 이를 의사결정권자에게 그대로 보고하기 어려웠다. 개발에 적합한 표현과 보고에 필요한 표현 사이에 간극이 있었다. [16:31]
• 기존 컨플루언스 위키에 자료가 쌓여 있어도 AI가 읽기 어렵거나, 보안 환경 때문에 AI 연결 자체를 시도하기 어려운 제약이 있었다. [17:43]

10. 온프레미스와 기업 보유 모델을 연결하는 모듈형 구조

• 매니페스트는 대기업 한 곳에 온프레미스 구축을 진행하고 있으며, 초기부터 엔터프라이즈 환경을 고려해 모듈형으로 설계했다. [20:27]
• SaaS에서는 앤트로픽과 OpenAI 등의 모델을 선택할 수 있고, 기업이 보유한 클라우드 모델 사용 환경과 연결하도록 구성돼 있다. [20:52]

11. 기업별 디자인과 보고 양식에 맞춰 산출물을 바꾼다

• SaaS는 와이어프레임과 문서를 범용 형태로 내보내 후속 가공에 사용할 재료를 제공한다. 엔터프라이즈에서는 출력물을 기업 요구에 맞게 조정할 수 있다. [21:38]
• 와이어프레임에 전용 디자인을 일관되게 적용하거나, 사내 기안서에 맞춘 엑셀·파워포인트를 출력할 수 있다. JSON 기반 데이터에 출력 규격을 설정해 보고에 필요한 형태로 만드는 방식이다. [22:01]

12. 고객 피드백과 승인을 기준 문서의 변경 이력으로 남긴다

• 외주 개발사는 초안을 고객에게 공유하고 화면에서 코멘트를 받은 뒤, 이를 반영한 개선 기획서를 다시 승인받는 방식으로 활용할 수 있다. 승인에 따라 무엇이 바뀌었는지 내역을 남기는 것이 핵심이다. [23:01]
• 이해관계자가 해당 문서를 상위 기준으로 삼아 의사결정하기로 합의하면, 문서는 공동 판단의 근거가 된다. [23:32]

13. 버전 사이에 끼어든 기능은 외주사의 부담이 될 수 있다

• 엑셀 기획안을 주고받으며 버전을 올리다 보면, 어느 시점에 합의하지 않았다고 생각한 기능이 들어가 있는 경우가 있었다. [24:53]
• 추가 기능이나 제약 조건, 정책을 누가 어떤 결정으로 넣었는지 기록하지 않으면 합의 여부를 추적하기 어렵다. 대표의 경험에서는 이런 누락으로 외주 개발사와 에이전시가 손해를 부담하는 경우가 많았다. [25:15]

14. 고객 요청서에서 출발해 빠진 조건을 보완한다

• 제품은 요구사항 정의부터 기능 명세, 흐름 검토, 화면 설계까지 연결하며, 온보딩에서는 신규 서비스·고객 프로젝트·운영 중인 프로젝트를 구분한다. [26:14]
• 고객 프로젝트에서는 제안 요청서, 기존 자료, 회의록을 올려 합의의 기준이 될 기획서 초안을 만든다. [27:05]

15. PRD·기능 명세·유저 플로우를 연결해 개발 조건을 구체화한다

• 문서화 단계에서는 PRD와 세부 기능 명세서, 유저 플로우를 만든다. 같은 기능이라도 사용자가 이용하는 흐름에 따라 제품이 달라질 수 있어 기능 목록과 사용 흐름을 함께 다룬다. [27:57]
• 커피 주문 앱 예시의 기능 명세에는 준비·개발·완료 등의 상태와 중요도뿐 아니라, 선행 조건·트리거·동작 결과·접근 권한 같은 개발 조건이 포함된다. [28:53]

16. 예외 상황과 일정·비용 쟁점을 초기 기획에 포함한다

• 유저 플로우에는 소셜 로그인 실패와 네트워크 오류처럼 실제 개발에서 대응해야 하는 예외 상황이 필요하다. 매니페스트의 문서 구조에는 디자인 에이전시와 SI 업무에서 약 350개사를 대상으로 다듬은 경험이 반영되어 있다 [30:47]
• 고객사의 RFP로 초기 기획안을 만든 뒤에는 대면 미팅에서 논의할 쟁점을 추린다. 단순 확인 사항을 제외하고 일정과 비용에 영향을 주는 항목끼리 묶는다 [31:36]

17. 회의 결정을 기획서에 연결하고 사람이 승인한다

• 전사된 회의록이나 텍스트·문서 파일을 등록하면 해당 기획서와 연결된 회의록을 만들 수 있다 [32:22]
• 결정 추출은 회의 내용 중 기획서와 관련된 결정만 골라낸다. 점심 메뉴처럼 무관한 결정은 제외하고, 관련 기능에 수정안을 연결한다 [32:56]

18. 변경된 명세와 유저 플로우를 동기화한다

• 회의 결과로 기능 명세서를 바꾸면 기존 유저 플로우는 이전 상태로 남는다. 동기화 기능은 두 문서가 어긋난 부분을 적용 항목으로 제시하고 변경 부분을 확인할 수 있게 한다 [33:46]
• 고객 피드백을 반영한 뒤 플로우 차트를 다시 생성하면, 의도한 수정 외에도 단어나 모양이 달라질 수 있다. 부분 수정 요청만으로는 결과를 신뢰하기 어려워 변경 범위를 확인하는 기능이 중요해진다 [34:21]

19. 온보딩 후 1달러로 팀 플랜을 체험한다

• 세 가지 온보딩을 모두 성실하게 체험하면 프로모션 화면이 나타나며, 1달러로 2주 동안 크레딧과 팀 플랜의 모든 기능을 이용할 수 있다 [34:48]
• 이 체험은 구독과 별개로 설계되어 기간이 지나도 자동으로 추가 결제되지 않는다. 체험 종료 후에는 무료 스타트업 플랜으로 돌아간다 [35:44]

20. 고객 피드백을 기획에 반영하고 개발 도구로 넘긴다

• 외부 공유 시 PRD·기능 명세서·유저 플로우 중 공개할 범위를 고르고 링크 이름과 만료 기한을 설정한다. 공유 페이지는 읽기에 집중하도록 구성되며, 실시간 협업에서는 커서와 코멘트를 확인할 수 있다 [36:29]
• 관련 기능을 멘션하고 고객 코멘트를 반영해 달라고 요청하면 AI가 기획안을 수정한다. 매장 관리자만 기능에 접근하도록 하는 권한 변경 사례에서는 반영한 코멘트를 닫는 처리까지 수행한다 [37:05]

21. 합의 버전과 변경 이력을 보존하고 이슈와 대조한다

• 기획서는 주요 시점에 새 버전으로 저장할 수 있고, AI를 통한 업데이트도 자동 저장된다. 고객과 합의한 시점에는 라벨을 붙여 기준 버전을 남길 수 있다 [38:34]
• 매니페스트 팀도 출시 초기부터 자사 제품으로 기획을 관리해 왔다. 연결된 리니어 이슈와 기획 문서를 대조해 뒤처지거나 반영되지 않은 항목을 확인한다 [40:10]

22. 국내 조직 고객과 해외 제품 주도 성장에 서로 다른 전략을 적용한다

• 개인·프리랜서·예비 창업자를 위한 기능도 유지하되, 국내에서는 협업과 형상 관리의 가치를 활용할 기업·팀 고객에 집중할 계획이다. 한국 시장에서 도입 고객과 테스트베드를 확보하며 제품을 다듬으려 한다 [42:23]
• 해외에서는 PLG를 다시 시도할 계획이다. 국내에서 높은 이탈률과 PLG만으로 성장하기 어려운 한계를 경험했지만, 더 큰 시장에서는 가능성이 있을 것으로 기대한다 [42:48]

23. AI의 기획 대행보다 사람의 판단과 구체화를 돕는다

• AI 산출물이 평균에 수렴한다는 판단에 따라 신규 제품의 기획을 AI에 전부 위임해서는 안 된다는 입장이다. 기획 과정의 의사결정은 사람이 주도해야 한다 [44:10]
• 제품의 현재 방향은 기획 전체를 대신하기보다 내용을 세심하게 구체화하는 데 있다. 개발·사업화·기획 관점의 다중 페르소나 검토로 누락과 모호함을 찾아, 초보 창업자의 기획 방향을 잡는 길잡이가 될 수 있을 것으로 조심스럽게 기대한다 [45:11]

🧾 결론

• 기준 문서는 이해관계자가 무엇을 상위 기준으로 삼을지 합의하고 지속적으로 갱신할 때 공동 판단의 근거가 된다.
• 버전 저장만으로는 부족하다. 누가 언제 무엇을 바꿨는지에 더해 변경 의도와 승인 맥락을 남겨야 이후의 해석 차이를 줄일 수 있다.
• AI가 기획을 구체화하고 누락을 찾도록 활용하되, 출시 범위와 변경 사항에 대한 의사결정은 사람이 맡는 것이 인터뷰의 일관된 방향이다.

📈 투자·시사 포인트

• 제품의 지속 사용 여부를 볼 때 문서 생성 횟수와 함께 조직의 기준 문서로 활용되는지 살펴볼 필요가 있다. 기준 문서로 사용하는 팀이 상대적으로 오래 머물렀다는 관찰이 제품 전환의 근거였다.
• 기업용 기획 도구의 도입 가치는 AI 기능뿐 아니라 보안 환경, 기존 보고 양식, 승인 절차와 얼마나 연결되는지에서도 확인해야 한다. 인터뷰의 이중 문서 작업 사례가 이 수요를 보여준다.
• 국내 기업·팀 중심 전략과 해외 PLG는 서로 다른 가설이다. 이용자 약 3만 명·17개국이라는 소개와 별개로, 유료 유지율과 매출 성과는 추가 확인이 필요하다.
• 코드와 기획의 동기화는 제품이 지향하는 핵심 가치다. 실제 평가에서는 현재 제시된 문서 간 동기화와 이슈 대조가 코드 수준의 불일치 탐지까지 얼마나 이어지는지 확인해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 한 달 프로젝트가 두세 달로 늘어나는 사례는 인터뷰에서 소개한 경험이다. 기준 문서 도입으로 일정이나 비용이 얼마나 개선되는지 정량적인 비교 결과는 제시되지 않았다.
• 코드와 동기화되는 ‘살아 있는 기획서’는 제품의 목표로 설명된다. 소개된 명세·유저 플로우 동기화 및 리니어 이슈 대조만으로 코드 전체와의 자동 동기화가 구현됐다고 판단하기는 어렵다.
• 이용자 수와 사용 국가 수는 대표가 소개한 수치이며, 유료 고객 수·매출·고객군별 유지율은 확인되지 않는다. 대기업 온프레미스 구축도 진행 중인 사례로 제시됐다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 진행 중인 프로젝트에서 고객사와 수행사가 함께 따를 기준 문서를 지정하고, 기능·출시 범위·유지보수 조건을 명시한다.
• 회의 결정마다 변경 내용, 이유, 발의자, 수정 시점, 승인자를 기록하고 관련 기능 명세에 연결한다.
• AI에 작업을 넘기기 전에 문서의 우선순위와 최신 합의 버전을 지정하고, 충돌하거나 빠진 조건을 사람이 확인한다.
• 기능 명세 변경 후 유저 플로우·와이어프레임·연결된 이슈에 남은 차이를 점검하고, 의도하지 않은 변경도 함께 검토한다.

❓ 열린 질문

• 기획과 코드의 불일치를 어느 수준까지 자동으로 탐지하고, 발견한 차이는 누가 어떤 기준으로 승인할 수 있을까?
• 고객과 수행사가 기준 문서의 권위에 합의한 뒤에도 긴급 요청이나 구두 변경이 들어오면 어떻게 승인 이력에 연결할까?
• 국내 기업 고객의 협업·형상 관리 수요와 해외 PLG가 각각 지속 사용과 유료 전환으로 이어지는지는 어떤 지표로 확인할 수 있을까?