소프트웨어 기획 전용 AI 개발기

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

1. 디자인 에이전시를 운영하며 느낀 ‘기획 병목’ 문제

안녕하세요, 팀 매니패스트입니다. 요즈음 저희 프로덕트인 매니패스트의 정식 출시 축하와 더불어, "왜 그런 소프트웨어 기획 전용 AI를 만들게 됐냐"는 질문을 자주 받습니다. 보통은 기술적인 답을 기대하시는데, 솔직히 말씀드리자면 저희의 출발점은 기술이 아니라 반복된 좌절이었습니다.

저희 팀의 전신은 UXUI 전문 디자인 에이전시입니다. 스타트업 MVP부터 대기업 사내벤처까지, 4년간 350건이 넘는 프로젝트를 수행하면서 소프트웨어가 태어나고 성장하는 과정의 거의 모든 장면을 옆에서 지켜봐 왔습니다.

저희가 주로 만났던 고객은 초기 스타트업이나 사내벤처처럼 규모가 작고 속도가 빠른 조직들이었습니다. 이런 조직들에게 기획은 대체로 후순위였습니다. 예산은 한정되어 있고, 사용할 수 있는 시간도 적습니다. 그러다 보니 "일단 만들어보고 시장 반응을 보자"는 판단이 먼저 앞섰기 때문입니다. 기획에 시간과 비용을 따로 쓰는 곳은 드물었고, 자연스럽게 UXUI 전문 디자인 에이전시인 저희의 역할도 좁아졌습니다. 고객이 이미 정해온 방향 위에서 화면을 설계하고, 개발 전달용 산출물을 만들어내는 것. 그게 저희의 사실상 업무 범위의 전부였습니다.

이렇게 기획을 간과한 채 시작된 프로젝트는 어김없이 흔들렸습니다. 중간에 방향이 바뀌거나, 일정이 끝없이 늘어나거나, 결국 누구도 책임지지 못한 채 조용히 소멸하거나. 좋은 결과를 낸 프로젝트도 물론 많았습니다. 하지만 실패한 것들을 나란히 놓고 보면, 놀라울 정도로 같은 패턴이 반복되고 있었습니다.

기획이 제대로 안 되어 있었습니다. 정확히 말하면 구조화가 부족했습니다.

아이디어는 있는데 구조화된 기획서가 없고, 구조화된 기획서가 없으니 커뮤니케이션이 깨지고, 커뮤니케이션이 깨지니 결과물이 산으로 갑니다. 방향이 잡히지 않은 개발은 아무리 빠르게 실행해도 실패에 가까워질 뿐이었습니다. 그리고 이 문제는 특정 고객사만의 문제가 아니었습니다. 규모와 산업을 가리지 않고, 거의 모든 프로젝트에서 반복되는 구조적인 문제였습니다.

그때 저희가 품은 질문이 하나 있습니다. "이렇게 치명적이고 반복적인 문제를, 왜 아무도 도구로 풀지 않았을까?"

오늘은 저희가 이 질문에서 시작해, 소프트웨어 기획 전용 AI를 직접 만들기까지의 과정을 이야기해 보려 합니다.

2. 범용 LLM을 통한 기획은 충분하지 않다

문제를 인식한 다음, 저희가 가장 먼저 한 일은 당연히 이미 존재하는 도구로 문제를 해결하려고 시도해 보는 것이었습니다. ChatGPT와 Claude는 이미 충분히 강력한 도구였고, "이걸로 기획까지 커버할 수 있지 않을까?"라는 기대는 저희만의 것이 아니었을 겁니다.

실제로 범용 LLM에 기획을 맡겨보면, 처음에는 꽤 감탄하게 됩니다. "부동산 중개인을 위한 SNS 서비스를 기획해줘"라고 입력하면, 그럴듯한 기능 목록이 쏟아져 나옵니다. 회원가입, 매물 등록, 피드, 메시지, 알림 얼핏 보면 완성된 기획서처럼 보이기도 합니다.

하지만 실무에서 이걸 그대로 쓸 수 있느냐고 물으면, 대답은 "아니요"입니다.

문제는 기획 사이의 정합성이었습니다. 기획이라는 작업의 본질은 단순히 기능을 나열하는 것이 아니라, 기능과 기능 사이의 관계를 정의하고, 그 관계가 모순 없이 작동하는지를 검증하는 일입니다. 회원가입 로직이 바뀌면 권한 체계가 달라지고, 권한 체계가 달라지면 피드에 보이는 콘텐츠의 범위도 바뀝니다. 기획에서의 하나의 변경은 연쇄적으로 다른 항목에 영향을 미칩니다.

범용 LLM은 이 연쇄 관계를 유지하지 못합니다. 대화가 길어지면 앞에서 정의한 내용을 잊어버리고, 기능 A에서 설정한 조건과 기능 B에서 설정한 조건이 서로 충돌하는 경우가 빈번하게 발생했습니다. 프롬프트를 아무리 정교하게 작성해도, 결국 사람이 전체 맥락을 머릿속에 들고 다니면서 일일이 검증해야 했습니다. AI를 쓰는 건데, 결국 사람의 부담이 줄지 않는 구조였습니다.

또 하나의 근본적인 한계가 있었습니다. 바로 출력 형태의 문제입니다.

소프트웨어 기획에는 텍스트만으로 표현할 수 없는 영역이 분명히 존재합니다. 정보구조도(IA), 플로우차트, 와이어프레임 이런 시각화된 산출물이 있어야, 개발자와 디자이너가 같은 그림을 보고 일할 수 있습니다. AI는 마크다운과 JSON 같은 텍스트 기반의 언어로 세상을 이해하지만, 최종 의사결정권자인 사람은 도표와 흐름도, 화면으로 시각화된 요소들로 판단하고 결정을 내립니다.

범용 LLM은 텍스트를 생성하는 데에는 탁월하지만, 이 텍스트를 구조화된 시각 산출물로 전환하는 것은 태생적으로 어렵습니다. 결국 AI가 뱉어낸 텍스트를 사람이 다시 Excel에 옮기고, Figma에서 흐름도를 그리고, PPT로 정리하는 과정이 반복됩니다. 도구를 줄이려고 AI를 도입했는데, 오히려 한 단계가 더 추가되는 셈이었습니다.

저희는 이 경험을 통해 확신하게 되었습니다. 프롬프트 엔지니어링만으로는 기획의 문제를 풀 수 없다는 것. 기획이라는 업무의 구조 자체를 이해하고, 그 구조에 맞게 설계된 전용 시스템이 필요하다는 것이죠.

3. 개발 여정에서 부딪힌 다양한 문제들

프로덕트를 설계하는 것과 실제로 만드는 것은 완전히 다른 일이었습니다. 저희는 무엇이 사람들이 겪고 있는 문제인지 안다고 생각했고, 어떤 프로덕트를 만들면 그 문제를 해결해줄 수 있는지도 안다고 생각했습니다. 그러나 머릿속에서는 완벽했던 그림이, 현실의 기술과 사용자 앞에서 무너지는 순간을 저희는 여러 번 경험했습니다. 그중 두 가지 이야기를 솔직하게 나눠보려 합니다.

1) 와이어프레임은 종착점이었지, 출발점이 아니었습니다

개발 초기, 저희가 가장 확신을 가지고 탑재한 기능은 와이어프레임 자동 생성이었습니다. 유저 리서치에서도, 내부 논의에서도 니즈가 가장 높았던 기능이었습니다. 기획 데이터를 입력하면, 화면 구성이 바로 시각화되는 것. 저희도 이것이 매니패스트가 도달해야 할 종착점이라고 생각했고, 지금도 그 생각은 변하지 않았습니다.

문제는 그 종착점을 준비되지 않은 상태에서 먼저 꺼내 들었다는 데 있었습니다.

실제로 기능을 출시하고 나니, 현실은 냉혹했습니다. 와이어프레임 렌더링에 시간이 너무 오래 걸렸고, 나오는 결과물도 불완전했습니다. 기획자가 빠르게 구조를 잡고 반복 수정해야 하는 흐름에서 이 지연과 불완전함은 단순한 불편이 아니었습니다. 유저 이탈율이 눈에 띄게 올라가기 시작했습니다. 가장 기대를 걸었던 기능이 오히려 프로덕트의 신뢰를 깎아 먹고 있었습니다. 결국 저희는 이 기능을 롤백하는 결정을 내려야 했습니다.

하지만 단순히 "속도가 느려서 뺐다"로 끝난 경험이 아니었습니다. 이 과정에서 두 가지 중요한 깨달음을 얻었습니다.

첫 번째는 핵심 기술을 오롯이 외부 AI에 의존하는 구조로는 안 된다는 것이었습니다. 범용 모델의 출력을 그대로 가져다 쓰는 방식으로는, 기획이라는 도메인이 요구하는 정밀도와 속도를 동시에 만족시킬 수 없었습니다. 이 경험이 자체적인 파인튜닝과 독자 기술 개발에 본격적으로 투자하게 된 계기가 되었습니다.

두 번째는 더 본질적인 인사이트였습니다. 와이어프레임이 원하는 형태로 출력되려면, 그 이전 단계의 기획 맥락이 충분히 채워져 있어야 한다는 것입니다. 요구사항이 정의되고, 기능이 구조화되고, 플로우차트가 잡혀 있을 때 그제서야 와이어프레임은 적은 공수로도 의도한 형태에 가까운 결과를 낼 수 있습니다. 맥락 없이 화면부터 그리려 했던 것이 문제의 근원이었습니다.

그래서 저희는 방향을 틀었습니다. 와이어프레임이라는 종착점을 향해 곧장 달려가는 대신, 플로우차트부터 차근차근 편집하고 구현할 수 있도록 기획의 미싱 링크를 하나씩 채워나가는 과정을 시작했습니다. 돌아가는 길처럼 보였지만, 결과적으로 이 결정이 프로덕트의 뼈대를 훨씬 단단하게 만들어주었다고 생각합니다.

2) AI에게 기획을 통째로 맡겨서는 안 됩니다

두 번째 시행착오는 저희 프로덕트의 본질에 대한 질문으로 이어진 경험이었습니다.

개발 중간 단계에서, 새로 추가할 기능의 방향을 정해야 하는 시점이 있었습니다. 저희는 일종의 실험을 해봤습니다. AI에게 처음부터 끝까지 기능을 추천받고, 그 추천을 100% 반영한 기획안을 작성해서 샘플 개발까지 진행한 것입니다. 결과물은 논리적으로 빈틈이 없었습니다. 구현 조건도 깔끔하게 정리되어 있었고, 누가 봐도 고개를 끄덕일 만한 명세서였습니다.

그런데 이상하게도, 그 기획안대로 만들어질 프로덕트에서는 아무런 매력이 느껴지지 않았습니다. 아니, 그 기획안으로 프로덕트 만들면 100% 망할 것 같았습니다.

AI가 추천하는 기능은 데이터의 평균치에 수렴합니다. 보편적인 대중이 거부감을 느끼지 않을, 실패 확률이 낮은 방향으로 정리됩니다. 하지만 프로덕트의 성공은 그 보편성을 뚫고 나오는 날카로운 개성에서 시작됩니다. 특정 타깃의 고통을 집요하게 파고드는, 논리만으로는 설명되지 않는 집착. AI의 논리만 따라가면 프로덕트는 매끈해질 수도 있지만, 프로덕트의 야성과 매력은 사라집니다.

이 경험 이후 저희는 확신하게 되었습니다. AI 기획 도구의 본질은 "AI가 기획을 대신 해주는 것"이 아니라는 것을.

AI가 방대한 데이터를 빠르게 구조화해 완성도 높은 초안을 만들어줄 수는 있습니다. 하지만 "왜 이 기능이어야 하는가", "무엇을 포기할 것인가"라는 판단은 결국 사람의 몫입니다. 그래서 저희는 AI와 사람 사이에 충분한 질의응답 과정이 들어가야 한다고 생각합니다. AI가 초안을 제시하고, 사람이 질문하고, AI가 대안을 내놓고, 사람이 최종 결정을 내리는 이 반복적인 대화의 과정 속에서만 인간다운 의사결정이 가능해집니다.

AI는 도구로 쓰되, 의사결정의 핸들은 사람이 쥐고 있어야 합니다. 저희 프로덕트는 그 핸들을 사람의 손에 돌려주기 위해 존재합니다.

4. 그래서 저희는 기획 전용 AI를 이렇게 만들었습니다

그래서 저희는 이렇게 만들었습니다. 현재 저희가 가지고 있는 저희 프로덕트의 가장 큰 그림은, "기획 전용 AI가 갖춰야 할 세 가지 축"이입니다.

첫 번째는 AI 챗봇입니다. 자연어로 아이디어를 입력하면, AI가 그것을 기획의 언어로 번역해주는 역할입니다. 여기까지는 범용 LLM과 비슷해 보일 수 있습니다. 하지만 결정적인 차이가 있습니다. 매니패스트의 AI는 단순히 텍스트를 생성하는 것이 아니라, 구조화된 기획 데이터 안에서 동작합니다. 요구사항을 정의하면 그것이 기능 명세로 연결되고, 기능 명세는 플로우차트로 이어집니다. 하나의 맥락이 끊기지 않고 전체 기획 체계 안에서 유지되는 것, 이것이 범용 LLM과의 근본적인 차이입니다.

두 번째는 시각화 에디터입니다. 앞서 말씀드렸듯이, 기획에는 텍스트만으로 표현할 수 없는 영역이 있습니다. 기획의 구조와 흐름을 직관적으로 표현하는 것. 플로우차트, 와이어프레임 같은 시각 산출물이 기획자와 개발자, 디자이너가 같은 그림을 보고 일할 수 있게 만드는 핵심입니다. 매니패스트는 AI가 생성한 기획 데이터를 별도의 도구 없이 솔루션 내부에서 바로 시각화할 수 있도록 설계했습니다.

세 번째는 문서화 에디터입니다. 기획의 최종 산출물은 결국 문서입니다. 기능명세서, 요구사항 정의서, 개발 명세서까지 실무에서 요구되는 문서의 형태는 다양하고, 그 포맷도 조직마다 다릅니다. 매니패스트는 내부 기획 데이터를 엑셀, 마크다운, 이미지 등 원하는 형식으로 원클릭 내보내기할 수 있도록 만들었습니다. 기획 데이터를 구조화하고, 편집하고, 내보내는 전 과정이 하나의 솔루션 안에서 완결되는 것. 이것이 저희가 "올인원 기획 에디터"라고 부르는 이유입니다.

이 세 가지 축을 관통하는 설계 원칙이 하나 있습니다. 바로 AI가 이해하는 텍스트 구조와 인간이 이해하는 시각 구조 사이의 간극을 메우는 것입니다.

AI는 텍스트 기반의 구조화된 데이터로 세상을 이해합니다. 반면 사람은 도표와 흐름도, 화면으로 판단하고 의사결정을 내립니다. 매니패스트는 이 간극 위에 서 있는 도구입니다. AI가 생성한 구조화 데이터를 인간이 직관적으로 이해할 수 있는 형태로 실시간 변환하고, 인간이 수정한 내용을 다시 AI가 이해할 수 있는 구조로 반영하는 양방향 흐름. 이것이 저희 프로덕트의 핵심 아키텍처입니다.

그리고 한 가지 더. 저희는 매니패스트를 닫힌 도구로 만들 생각이 없었습니다.

저희는 MCP(Model Context Protocol) 기반 설계는, 매니패스트에서 구조화된 기획 데이터를 외부 AI 도구들에게 직접 전달할 수 있게 해줍니다. 매니패스트에서 기획을 구조화하고, 그 데이터가 Figma AI 같은 디자인 도구로, 다시 Cursor 같은 개발 도구로 이어지는 흐름. 저희는 이것을 "바이브 플래닝 → 바이브 디자인 → 바이브 코딩"으로 연결되는 파이프라인이라고 부르고 있습니다. 기획이 더 이상 문서 작성에서 끝나는 것이 아니라, 소프트웨어 개발 전체의 시작점이자 연결 고리가 되는 것. 그것이 저희가 그리는 그림입니다.

5. 기획 편집기에서 시작해, 소프트웨어 개발의 새로운 표준으로

솔직하게 말씀드리면, 매니패스트는 아직 완성된 프로덕트가 아닙니다. 저희가 그리는 그림의 첫 번째 칸을 겨우 채운 단계에 가깝습니다.

지금의 매니패스트는 기획 업무의 효율화를 위한 시각화 편집기입니다. 아이디어를 입력하면 기획 데이터가 구조화되고, 그것을 편집하고, 산출물로 내보내는 과정을 하나의 솔루션 안에서 완결짓는 것. 작년 11월 소프트런칭 이후 4,000명이 넘는 글로벌 유저가 사용해주셨고, 14,000건 이상의 기획 문서가 생성되었습니다. 2회 이상 재방문하는 유저 비율이 70%라는 수치는, 이 문제가 저희만의 문제가 아니었다는 것을 확인시켜 주었습니다.

하지만 저희의 시선은 이미 다음 단계를 향하고 있습니다.

다음 단계는 AI 에이전트의 고도화입니다. 자연어 입력 기반으로 기획 전주기를 수행하는 멀티모달 생성 엔진을 만들고 있습니다. 기획서를 자동으로 검토하고, 프로덕트의 사용성을 시뮬레이션하는 기능까지 내다보고 있습니다. 그리고 그 다음에는 MCP와 API, 플러그인을 통해 다양한 도구와 환경을 유연하게 연결하는 마켓플레이스를 구축하려 합니다. 최종적으로는 팀과 조직의 기획 중심 협업을 돕는 워크스페이스, 그리고 기획부터 배포·운영까지 IT 프로젝트 전 과정을 아우르는 통합 운영체제를 지향하고 있습니다.

거창하게 들릴 수 있다는 것을 압니다. 하지만 저희가 이 로드맵을 확신하는 이유는 단순합니다. 4년간 350개의 프로젝트를 수행하면서 반복적으로 목격한 문제, AI 시대에 더 심화되고 있는 기획의 병목, 그리고 베타 기간 동안 다수의 유저들이 보내준 생생한 피드백들, 이 모든 것이 같은 방향을 가리키고 있기 때문입니다.

기획의 실패를 줄일 때, 프로젝트의 성공 확률은 높아집니다. 그리고 그 시작은 거창한 혁신이 아니라, 기획자의 빈 화면 앞에서 첫 구조를 함께 잡아주는 일에서 출발한다고 저희는 믿고 있습니다.

저희는 아직 그 표준을 만들어 가는 길 위에 있습니다. 완성되었다고 말씀드리기엔 이릅니다. 다만, 이 문제를 오래 곱씹어 온 팀이 현장의 목소리를 들으며 한 발씩 나아가고 있다는 것, 그리고 그 과정 자체를 이렇게 나눌 수 있다는 것이 저희에게는 의미 있는 일입니다.

이 글이 비슷한 고민을 안고 계신 분들께 작은 참고가 되었으면 합니다. 긴 글 읽어주셔서 감사합니다.

<참고>

manyfast.io/blog

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