AI 시대를 위한 바이브 기획은 어떤 모습이어야 하는가?

이 글은 ‘리오랩(매니패스트)’이 제작하고, 요즘IT가 기업 제휴 콘텐츠로 소개합니다.

지난 1편과 2편에서는 AI 시대에 우리가 왜 여전히 재작업 지옥에 사는지에 대해 이야기했습니다. 간단히 요약하자면, 1편에서는 아무리 AI 코딩 툴이 발전해도, 기획서 자체가 모호하면 쓰레기가 들어갔을 때 쓰레기가 나오는 GIGO(Garbage In, Garbage Out) 문제를 피할 수 없다는 것을 확인했습니다. 또한 2편에서는, 이 모호한 기획이 만들어낼 수 있는 문제는 단순히 개발 효율을 떨어뜨리는 것을 넘어, 프리랜서와 SI 기업의 비청구시간(Non-billable Hours)을 늘리고 수주율을 떨어뜨리는, 즉 우리의 돈 문제와 직결되어 있음을 다루었습니다.

그렇다면 이런 고질적인 문제를 해결하기 위해, AI 시대의 기획은 과연 어떤 모습이 되어야 할까요?

1, 2편에서 그토록 강조했던 기획력을 실제로 향상시키기 위해, 우리는 무엇을 해야 할까요? 오늘 3편에서는 기존의 방식이 아닌, AI 시대에 걸맞은 새로운 기획의 모습인 바이브 기획(Vibe Planning)이 어떤 모습이어야 하는지, 그 구체적인 원칙과 방법론을 제시하고자 합니다. 이를 통해 저희 매니패스트가 바라보고 있는 방향을 설명하고, 매니패스트가 어떤 기획용 AI 도구로 여러분들에게 다가갈 것인지 말씀드리고자 합니다.

1. 죽은 기획서의 3가지 한계

우리는 왜 AI라는 강력한 무기를 손에 쥐고도 여전히 재작업과 소통 비용에 시달릴까요?

문제는 우리의 기획 도구가 20년 전과 본질적으로 달라지지 않았기 때문입니다. 우리는 여전히 파워포인트(PPT), 엑셀, 워드를 사용합니다. 물론 최근에는 노션과 피그마같이 더 나은 도구들이 기획 작업에 추가되기도 했습니다. 하지만 이 발전된 도구들로 우리가 예전보다 더 잘하게 된 것은, 그저 더 깔끔하고 예쁜 그림과 도형을 그리는 능력뿐입니다.

AI가 코드를 짜주는 시대에도, 이 죽은 기획서들은 다음과 같은 3가지 명확한 한계를 가지며, 저희는 이것을 IT 프로젝트에서의 대부분의 재작업 지옥의 근본 원인이라고 판단하고 있습니다.

한계 1: 파편화(Fragmentation)

우리 IT 프로젝트의 현실을 들여다봅시다. 정보구조도(IA)는 엑셀에, 서비스 정책은 컨플루언스 (Confluence)에, 화면 플로우차트(Flowchart)는 PPT나 FigJam에, 상세 화면정의서는 노션이나 PPT에, 그리고 개발 태스크는 Jira에 흩어져 있습니다. 각각의 도구들은 정말 유용하고 강력합니다. 하지만 이 도구들이 모두 파편화되어 있다는 사실이 우리의 기획 작업에 거슬리는 장애물이 된다는 것이 문제입니다.

모든 기획의 핵심 산출물이 서로 다른 파일과 시스템에 파편화되어 흩어져 있는 것, 이것이 모든 비극의 시작입니다. 기획 핵심 산출물이 파편화되면 될수록, 우리 프로젝트의 집중력도 파편화될 수밖에 없거든요.

한계 2: 수동 동기화(Manual Synchronization)

프로젝트 도중 갑작스럽게 ‘추천인 코드’ 기능이 추가되었다고 가정해 봅시다. PM은 이제 이 하나의 변경 사항을 반영하기 위해, 엑셀로 만든 IA 문서를 열어 수정하고, PPT로 만든 플로우차트를 찾아 수정하고, 노션에 작성 중인 화면정의서를 다시 고쳐야 합니다.

만약 이 과정에서 단 하나라도 빠뜨리면 어떻게 될까요? 예를 들어, PM이 바쁜 나머지 PPT 플로우차트는 수정했지만 엑셀 IA 시트는 깜빡하고 수정하지 않았다고 해봅시다. (추후에 받게 될 온갖 질책과 한숨은 일단 모르는 척 넘어가겠습니다.)

개발자는 파편화된 문서들 간의 불일치를 해독하느라 시간을 낭비합니다. 혹은 더 나쁘게도, 잘못된 버전의 기획서를 바탕으로 개발을 진행하다가 추후에 그 사실을 알게 됩니다. 몇 번 잘못된 버전의 기획서로 개발하는 실수를 저지르고 나면, 기획자와 기획서에 대한 불신을 키우게 되겠죠. 이 불신은 결국 프로젝트 전체의 소통 비용을 기하급수적으로 증가시킵니다.

한계 3: 비구조화(Unstructured)

가장 치명적인 한계입니다. GitHub Copilot 같은 AI 코딩 툴은 PPT 장표나 엑셀 시트에 담긴 논리 구조를 이해할 수 없습니다. AI에게 이것은 그저 예쁜 그림이나 의미 없는 텍스트 덩어리일 뿐입니다.

LLM이 아무리 발전했다고 하더라도, AI는 여전히 명확하게 구조화된 데이터를 다룰 때 그 진가를 발휘합니다. 현재 우리의 기획서는 AI가 읽고 이해할 수 있는 데이터라기 보다는, 사람이 눈으로 봐야만 하는 문서에 가깝습니다. 그러니 결국 기획자가 작성한 기획서를 개발자들은 다시 기계가 읽을 수 있는 구조화된 데이터로 변환하는 과정을 거쳐야 하지요.

2. 살아있는 기획서: 바이브 기획의 5가지 원칙

저희는 이 죽은 기획서의 문제를 근본적으로 해결하고, AI가 IT 프로젝트 전체에 깊숙이 관여하는 현재 시대에 어울리는 기획을 바로 바이브 기획이 향해야 할 방향이라고 생각하고 있습니다. 또한 바이브 기획이 기획서를 문서가 아닌 살아있는 시스템으로 바라보게 만드는 접근 방식이며, 다음과 같은 5가지 원칙을 가져야 한다고 생각합니다. 이 5가지 원칙은 앞으로 저희가 계속해서 고도화시켜 나갈 방향이자 목표 그 자체입니다. 

원칙 1: 통합(Integrated)

IA, 플로우, 화면, 명세서는 처음부터 끝까지 하나의 시스템 안에서 유기적으로 관리되어야 합니다.

예를 들어, IA에서 ‘회원가입’ 화면의 이름을 ‘유저 등록’으로 바꾸는 순간, Flowchart와 화면정의서에 포함된 모든 ‘회원가입’이라는 이름이 실시간으로 ‘유저 등록’으로 바뀌어야 합니다. 이것이 바로 수동 동기화의 지옥에서 탈출하는 첫걸음입니다. 앞으로 나올 바이브 기획 도구가 우리에게 쓸모가 있으려면, 우선적으로 이 통합의 원칙을 충족해야 할 것입니다.

원칙 2: 구조화(Structured)

기획서는 단순한 문서가 아니라 데이터베이스여야 합니다. 기획서에서 ‘회원가입’은 단순한 문자여서는 안 됩니다. 개발자들과 디자이너에게, 그리고 그들이 프로젝트에 활용하는 AI 도구들에 익숙한 데이터베이스여야 합니다. 다시 말해, 기획서에서 ‘회원가입’은 [화면 ID: SCR-001], [연결 기능: F-001, F-002], [정책: P-001] 등의 명확한 속성을 가진 하나의 객체(Object)여야 합니다. 

또한 사람의 창의적이고 비정형적인 아이디어를 기획서로 옮기는 과정에서, 필연적으로 일정 부분 비정형적인 부분이 기획서에 남을 수밖에 없습니다. 분명 깔끔하게 썼다고 생각한 기획서인데, 개발자들이 기획서를 이해하지 못하고 수도 없이 질문하는 경우를 많이 보셨을 겁니다. 바로 기획서가 본질적으로 어느 정도 주관적일 수밖에 없기 때문이죠. 다른 사람도 정확히 이해하기 힘든 것이 기획서인데, 하물며 기계는 어떨까요?  

이제 기획을 글쓰기의 영역이 아닌 데이터 설계의 영역으로 가져온다면, AI의 도움으로 기획서를 완전히 정형적으로 쓸 수 있게 된다면 사람이 해독해야 하는 기획서가 아닌 기계가 이해할 수 있는 기획서를 쓰는 시대가 시작될 것입니다.

원칙 3: 기계 가독성(Machine-Readable)

기획이 객체로 구조화된다면(원칙 2), AI 툴도 드디어 기획서를 이해할 수 있게 될 것입니다. 아주 단순하게 말한다면, 우리는 AI에게 "SCR-001(회원가입) 화면에 필요한 API 엔드포인트 초안을 짜줘" 또는 "F-001(이메일 중복 확인) 기능의 테스트 케이스를 10개 만들어줘"라고 할 수 있어야 한다고 생각합니다. 

물론 실제 프로젝트에서는 이것보다 훨씬 복잡한 명령을 내리고, 수행해야 할 것입니다. 하지만 그렇게 복잡한 명령을 내리고 수행하려면, 애초에 기획 단계에서부터 기계가 이해할 수 있는 언어로 기획되어야 할 것입니다. 자연어로 코딩을 하는 AI 바이브 코딩 시대라고는 하지만, 바이브 코딩을 해보신 분들은 모두 아실 겁니다. 기계에게 프로젝트의 맥락을 이해시키기 위해 프롬프팅을 수도 없이 하다 보면, 이게 내가 직접 코딩을 하는 것보다 빠르긴 한 건가 하는 생각이 드는 순간을요.

기계가 읽을 수 있는 기획서를 만들어내는 바이브 기획의 시대가 도래한다면, AI가 그저 텍스트 뭉치를 읽고 추론하는 것이 아니라, 구조화된 데이터를 읽고 논리적인 코드를 생성할 수 있을 것입니다. 우리가 꿈꾸는 진정한 바이브 코딩은 아마도 이러한 바이브 기획과 함께 도래하지 않을까요?

원칙 4: 버전 관리(Version-Controlled)

기획서_v1_final_진짜최종.pptx 같은 파일명은 이제 정말로 그만둘 때가 온 것 같습니다.

왜 개발자들은 모두 버전 관리를 자연스럽게 받아들이고 있는데, 기획자들은 항상 final과 진짜 최종과 찐찐최종을 만들어야 할까요? 앞으로는 모든 기획서 역시 변경 이력은 Git 커밋처럼 자동으로 추적되고 관리될 필요가 있습니다. 개발자가 "어제 기획서랑 오늘 뭐가 바뀐 거죠?"라고 PM에게 물어보거나, 기획서를 두 장 열고 변화된 부분을 확인하거나, 기획자가 변경된 부분마다 파란색으로 색칠하는 시대는 이제 끝나야 합니다. 그저 시스템에 접속해 어제와 오늘의 변경분(Diff)만 확인하고 즉시 작업에 반영할 수 있어야 합니다.

원칙 5: 검증(Validated)

마지막으로, 저희는 코딩을 하기 전에 기획 단계에서 컴파일할 수 있어야 한다고 생각합니다.

기획이 하나의 시스템으로 통합되고 구조화된다면, 시스템이 기획의 논리적 오류를 자동으로 검증할 수 있을 것입니다. 예를 들어, "‘로그아웃’ 버튼에서 ‘로그인’ 화면으로 가는 플로우가 빠졌네요" 또는 "결제 플로우에 죽은 링크가 존재합니다" 같은 오류를 코딩이 시작되기 전에 시스템이 자동으로 경고해 줄 수 있어야 합니다. 저희가 생각하는 바이브 기획의 최종 단계에서는, AI를 활용하여 IT 프로젝트에 기획과 개발과 디자인 사이의 벽을 허물어 버릴 수 있을 것입니다.

3. 실전 비교: ‘추천인 코드’ 재작업 지옥 탈출기

이제 1편에서 언급했던 ‘추천인 코드’ 추가 시나리오가, 이 두 가지 다른 기획 방식 하에서 어떻게 전개되는지 구체적으로 비교해 보겠습니다. 1편을 안 보셨더라도 걱정하지 마세요. 우리에게 아주 익숙한 시나리오입니다. 처음에는 구글/네이버/카카오 로그인만 가능하면 된다고 했던 클라이언트가, 개발 도중에 갑자기 회원가입 시 추천인 코드 입력 기능도 넣어주실 수 있냐고 물어보는 상황이거든요. 

Before: 죽은 기획서 (PPT/엑셀)

1. 고객이 슬랙으로 PM에게 "회원가입 시 추천인 코드 입력 기능을 넣어주세요"라고 요청합니다.
2. PM은 알겠다고 답한 뒤, 엑셀(IA), PPT(플로우), 노션(정의서) 3개의 파일을 엽니다.
3. 3개의 문서를 각각 수정하며 수동으로 동기화 작업을 시작합니다.
4. 그러다 중간에 다른 급한 업무가 끼어들어, PPT(플로우) 수정을 빠뜨리고 맙니다.
5. PM은 팀원들에게 "추천인 코드 기능 추가됐습니다. 도저히 방어할 수 없었습니다. 죄송합니다. 노션 참고해 주세요"라고 공지합니다.
6. 개발자는 노션(정의서)만 보고 DB 스키마를 고치고 API를 개발합니다.
7. 하지만 개인적인 사정으로 PM과의 회의에서 약간 집중력이 부족했던 디자이너는, 엑셀(IA)만 보고 옛날 플로우가 반영된 디자인 시안을 전달합니다.
8. 개발이 끝난 뒤 디자인을 입히는 과정에서야 플로우가 꼬인 것을 발견하고, 대참사가 벌어집니다. 재작업이 발생합니다.

After: 바이브 기획(5가지 원칙)

1. 고객이 PM에게 동일한 요청을 합니다.
2. PM은 통합 기획 시스템에 접속합니다.
3. '추천인 코드 입력'이라는 화면 객체(Object)를 새로 만듭니다. (원칙 2: 구조화)
4. '회원가입 플로우'에 '추천인 코드 입력' 객체를 드래그하여 연결합니다.
5. 이 작업 즉시, IA와 플로우차트, 화면 목록이 자동으로 변경됩니다. (원칙 1: 통합)
6. 이때 시스템이 PM에게 경고를 보냅니다. "경고: '추천인 코드' 기능에 대한 '유효성 검증' 정책이 정의되지 않았습니다." (원칙 5: 검증)
7. PM은 경고를 확인하고, '추천인 코드 유효성 검증' 정책을 상세히 정의한 뒤 'v1.2'로 커밋합니다. (원칙 4: 버전 관리)
8. 개발자와 디자이너는 "v1.2 변경 내역" 알림을 받습니다. 두 사람 모두 '추천인 코드'가 추가된 동일한 버전의 기획서를 시스템에서 확인하고 동시에 작업을 시작합니다.
9. 재작업은 발생하지 않습니다.

4. 결론: 곧 바이브 기획이 우리에게 찾아올 겁니다

AI 시대의 기획 작업은 더 이상 ChatGPT에게 "기획서 초안 좀 써줘"라고 부탁하는 수준에 머물러서는 안 됩니다. AI를 기획에 더 적극적으로 활용해야 하는 것은 맞지만, 그것은 정확히 기획만을 위해 개발된 기획 시스템 위에서 이루어져야 합니다. AI가 우리의 기획을 더 효과적으로 돕게 하려면, AI가 이해할 수 있는 명료하고 구조화된 기획서를 만드는 것이 선행되어야 합니다. 그리고 이 구조화된 기획서를 만드는 속도는, 바이브 기획 시스템의 도움을 받을 때 훨씬 더 빨라질 것입니다.

이러한 바이브 기획의 도입은 단순히 기획자 한 명의 생산성을 높이는 것을 넘어, IT 프로젝트 전체의 생산성을 폭발적으로 향상시키는 핵심 열쇠가 될 것입니다.

<참고>

manyfast.io/blog

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.