회의에서 로그인을 구글 로그인으로 하기로 했다가, 다음 회의에서 카카오 로그인으로 바꿉니다. 회의에 있던 사람들은 이유를 알아요. 구글 쪽에는 보안 인증 문제가 있었고, 카카오는 국내 시장을 노린 선택이었죠. 그런데 위키에는 바뀌었다는 두 줄만 남습니다. 요즘은 그 문서를 개발자 대신 AI 에이전트가 읽고 일하기도 하죠. 이유가 빠진 기획서를 받은 AI는 그 빈칸을 무엇으로 채울까요?
Manyfast(매니패스트) 허재혁 대표님의 답은 '추측'입니다. 그래서 결정만 적힌 문서가 아니라 바뀐 이유와 맥락이 계속 쌓이는 기준 문서(SSOT)가 있어야 AI 에이전트도 일관되게 일할 수 있다고 말해요. 기준 문서의 조건부터 대기업 기획팀과 외주 개발사가 겪는 문제, 바뀐 Manyfast 화면까지 하나씩 물어봤습니다. 이번 호는 Manyfast 허재혁 대표 인터뷰예요. 글 끝에 Team 플랜을 1달러로 14일 동안 써 볼 수 있는 특별 링크가 있으니 끝까지 읽어 주세요!
Manyfast는 기획서를 빨리 만들어 주는 도구에서 팀의 기준 문서를 관리하는 도구로 바뀌었습니다
Q. 3월에 이어 두 번째로 모셨는데, 그사이 10배 넘게 성장하셨더라고요. 구독자분들께 자기소개를 부탁드립니다.
Manyfast를 운영하는 매니패스트 주식회사 허재혁입니다. 10배 성장했다고 말씀해 주셨는데, 딱 10배예요. 3월에 출연했을 때 3,000명 정도로 시작했던 것 같은데, 지금은 3만 명 정도예요. 17개국에서 쓰는 솔루션으로 넓어졌습니다.
Q. 3월에는 PRD(제품 요구 사항 문서)를 만들어 MCP(AI 도구가 외부 서비스와 데이터를 주고받는 연결 규격)로 커서나 Claude Code 같은 AI 코딩 도구에 넘기는 흐름을 보여 주셨어요. 최근 제품이 바뀐 걸로 아는데, 어떤 과정과 계기가 있었나요?
저는 피그마를 베타 때부터 써 온 얼리 유저예요. 개발에는 커서나 Claude Code가 있고 디자인에는 피그마가 있는데, 기획에는 왜 전용 도구가 없을까 싶었습니다. 누구는 피그마로, 누구는 워드나 파워포인트, 엑셀로 하는 식으로 너무 흩어져 있었거든요.
처음 생각한 기획 전용 도구는 단순했어요. 기획서를 빨리 만들어 주고 공유하는 도구였죠. 3월에는 그랬던 것 같아요. 그렇게 시장에 내놓고 빠르게 호응을 얻으며 성장했다고 생각합니다.
그런데 시간이 지나면서 알게 됐어요. 기준이 되는 기획 문서를 쓰는 조직이나 팀이 저희 제품을 가장 오래 쓴다는 걸요.
Q. 예전에는 '최종', '최최종' 문서를 던지거나, 위키에 올려 두고 "버전 1.1 됐습니다" 하고 안내하는 팀이 많았잖아요. 그렇게 일하던 팀들이 기준 문서를 하나 두고 계속 고쳐 쓰게 되는 건 어떤 필요 때문인가요?
저는 UX·UI 디자이너 출신 얼리어답터라 시장에 나온 도구를 거의 다 써 봅니다. 위키나 지식을 저장하는 도구는 쌓인 기획 데이터를 고치기가 불편해요. 쌓아 가는 도구라서, 그 안의 기획을 다듬거나 지우고 고치는 과정이 번거롭습니다.
기획 문서가 흩어져 있으면 생기는 문제가 또 있어요. 요즘은 개발자가 아니라 AI 에이전트가 일을 하잖아요. 문서의 독자가 사람이 아니라 AI가 된 거예요.
사람이 읽을 때는 읽히기만 하면 됩니다. 도표를 파워포인트로 만들었든 피그마로 만들었든 손으로 그렸든 상관없어요.
그런데 AI는 코드와 텍스트를 읽습니다. 그래서 스키마(데이터의 구조와 형식을 정한 규칙)가 맞지 않으면 착각하거나 추측해요. 스키마를 맞추고 문서를 일관되게 쌓아 두는 게 굉장히 중요하다고 느꼈습니다.
회의에서 정한 이유가 문서에 없으면 AI 에이전트는 추측으로 빈칸을 채웁니다
Q. AI가 팀과 협업하려면 핵심 기획서가 늘 최신 정본이어야 하잖아요. 에이전시 시절 그게 안 돼서 힘들었던 경험에서 출발하셨다고 들었는데, 지금 사용자들의 모습과 어떻게 이어지나요?
저는 에이전시를 운영하다 보니 외부 이해관계자와 일하는 경우를 많이 겪었어요. 기준이 되는 문서가 없으면 무조건 힘듭니다.
어떤 회의에서 무엇이 결정됐는지 남겨 두지 않고 제때 고객사에 공유하지 않으면 이런 말이 나와요. "이 기능까지 해 주기로 한 것 같은데요", "이 기능은 이렇게 하기로 했는데요."
그러면 맨먼스(Man-Month, 한 사람이 한 달 동안 하는 작업량)가 끝도 없이 늘어납니다. 한 달짜리 프로젝트가 두 달이 되고, 어쩌다 보면 세 달까지 가요. 유지 보수 범위를 명확히 해 두지 않으면 6개월 뒤에 와서 "이거 해 줘" 하는 경우도 많았습니다.
이게 에이전시만의 문제는 아니에요. 예전에는 사람 대 사람으로 일했잖아요. 개발자, 디자이너, PM, 고객사 사람들이 다 모여 회의를 하니 의도와 맥락이 각자에게 녹아 있었죠.
요즘은 비대면으로 일하고, 일을 하는 쪽이 각자의 컴퓨터 안에 AI 에이전트로 따로 있어요. 회의록이 기획서와 맞지 않고 어느 수준으로 참고할지 우선순위도 없으면, 에이전트들이 저마다 다르게 해석해 버립니다. 그래서 명확한 권위가 있는 기준이 있어야 일관된 작업을 할 수 있다고 생각해요.
예를 들어 볼게요. 기획서나 회의록에 '로그인은 구글 로그인으로 한다'고 적혀요. 그다음에 '카카오 로그인으로 바뀌었다'고 적히고요. 위키에는 이렇게만 쌓여 있는 거죠.
회의에서는 바꾼 의도와 맥락이 있었을 거예요. 구글 로그인에는 SSO(한 번 로그인으로 여러 서비스를 쓰는 방식) 보안 인증 문제가 있었고, 카카오는 국내 시장을 겨냥했다는 걸 회의에 있던 사람들은 다 압니다.
그런데 AI는 텍스트만 있고 누가 제안했는지도 모르면 추측을 하게 됩니다. 그 추측이 쌓이고 쌓여 이어지면, 결국 코드가 꼬이거나 대참사가 날 수 있다는 거죠.
좋은 기획서는 코드와 맞춰지고, 바뀐 이유가 쌓이고, 사람과 AI가 함께 읽습니다
Q. 정본이 없거나 개발이 먼저 앞서가면 꼬이는 경우가 많죠. 그렇게 하나를 단단히 잡아 주는 기준을 SSOT(Single Source of Truth, 모두가 기준으로 삼는 단 하나의 정본)라고 하는데, 원래 데이터 엔지니어링에서 온 말이잖아요. 기획에서 말하는 SSOT는 어떤 모습인가요?
기획은 범위가 넓으니 IT·소프트웨어 기획으로 좁혀서 말씀드릴게요.
제가 생각하는 좋은 SSOT의 기준은 단순해요. 코드와 동기화돼 있어야 하고, 코드와 어긋났을 때 그걸 알려 주고 확인할 수 있어야 합니다. 그래서 저희는 좋은 기획서를 살아있는 기획서라고 정의했고, 그걸 구현하는 제품을 만들려고 전 팀원이 노력하고 있어요.
Q. 전에 SSOT에는 단 하나의 기준, 언제든 변경을 파악할 수 있는 구조, 사람과 AI가 같이 읽는 문서가 필요하다고 하셨죠. 각각 무슨 뜻이고, 현장에서 빠지면 어떤 증상이 나타나나요?
가장 흔한 실수는 스냅샷(특정 시점에 찍어 둔 사본)을 가지고 SSOT라고 하는 거예요. SSOT는 권위가 있는 문서입니다. 사람들이 거기에 변경 이력과 의도, 맥락을 계속 쌓아 갈 때 좋은 SSOT가 된다고 생각해요.
그런데 보통은 스냅샷을 찍어 버전으로 저장한 다음, 사람이 딱 보고 이해할 수 있게 보기 좋은 한 페이지를 만들어 놓고 SSOT라고 해요.
알아 두셔야 할 게 있어요. AI가 잘 읽는 기획서와 사람이 잘 읽는 기획서를, 연구까지는 아니어도 많이 테스트해 봤거든요. 결국 사람이 잘 이해하는 기획서는 시각화 위주의 기획서입니다.
Q. 시각화 위주의 기획서라면, 예를 들면 어떤 건가요?
플로우 차트나 와이어프레임이 그렇고, 기능 명세도 줄글이 아니라 단계별로 오밀조밀하게 정리된 것이 사람이 보기 편한 기획서예요.
그런데 AI가 읽기 편한 기획서는 다릅니다. 1000페이지짜리 텍스트나 코드면 돼요. 그래서 사람이 이해하는 기획과 AI가 이해하는 기획 사이에 괴리가 생겨요.
두 가지를 다 잘 해낼 수 있어야 명확한 SSOT가 된다는 게 지금 저희가 가진 가설이에요. 그 가설을 밀고 있고, Manyfast도 그 방향으로 설계하고 있습니다.
그래서 Manyfast에서는 기능과 플로우 차트, 와이어프레임이 사람이 보기 편한 그래픽으로 나와요. 하지만 뒷단은 전부 JSON(프로그램끼리 데이터를 주고받는 텍스트 형식) 코드 기반으로 설계돼 있습니다. 사람이 보는 것과 일치하는 데이터를 AI가 손실 없이 읽을 수 있는 구조죠. 그게 가장 큰 차이예요.
한 대기업 서비스 기획팀은 AI로 일하는 개발팀과 보고받는 임원 사이에 끼어 있었습니다
Q. 요즘 체감하신 조직의 문제는 어떤 모습이었나요? 기획서를 공유하고 SSOT를 필요로 한다는 관점에서요.
조직이 AI에 얼마나 맞춰져 있느냐에 따라 천차만별이에요. 오늘 아침에도 한 대기업에 솔루션을 소개하고 왔는데, 그곳은 서비스 기획팀이었어요.
개발팀은 이미 AI로 자동화를 하고 에이전트도 만들고 있습니다. 그런데 서비스 기획팀은 개발팀에 일을 지시할 방법이나 도구가 없고, 개발팀이 하는 일과 기획팀이 보고하는 의사결정권자 사이에서 큰 괴리를 느껴요.
개발팀은 Claude Code나 코덱스(Codex, OpenAI의 코딩 에이전트)를 쓰면서 기획 문서든 뭐든 코드 기반으로 뚝딱뚝딱 만들어요. 그런데 기획·PM 부서는 보고를 해야 하잖아요. 코드 기반 문서를 임원에게 그대로 가져가서 보고할 수는 없습니다.
큰 조직에는 레거시(오래 쌓인 기존 자료와 시스템)도 있어요. 오늘 간 곳도 컨플루언스(사내 위키 도구)에 레거시가 빼곡했습니다. AI를 붙여도 잘 못 읽고, 애초에 붙여 볼 시도조차 못 하는 보안 환경이라고 하시더라고요.
사람이 읽고 의사결정할 문서는 갖춰져 있는데, AI가 읽고 수행할 문서는 갖춰져 있지 않은 거예요.
그 사이에 낀 기획팀은 개발팀에 줄 문서를 따로 만들고, 개발팀이 만든 걸 가공해 임원에게 보여 줄 문서도 만들어야 합니다. 그런데 개발팀 쪽에서는 "AI도 못 써서 생산성이 이렇게 떨어지는데 어떻게 할 거냐"는 압박이 들어와요.
그러니 화가 나기도 하고, 거꾸로 개발을 배워 보려다 '이게 맞나' 싶다고 해요. 개발 친화적으로 가려면 사람이 겪기에 별로인 순간이 많거든요. 1000페이지짜리 기획서를 써야 한다든지요.
Q. 저도 화면 설계서를 1000페이지씩 써서 PPT를 꾸몄던 기억이 나네요.
저도 직전에 리오랩이라는 디자인 에이전시를 할 때 그랬어요. 피그마로 UX·UI를 다 만들어 놨는데, 고객사에서 무조건 파워포인트로 만들어야 한다고 했습니다. 800페이지짜리였는데, 보안 때문에 노트북을 가져갈 수도 없어서 현장에서 2주 동안 피그마를 파워포인트로 옮겼어요.
Q. 보안 얘기도 하셨는데요. 금융권은 대부분 온프레미스(회사 서버에 직접 설치해 쓰는 방식)이고, 대기업도 보안에 엄청나게 신경 씁니다. 저희도 한 대기업과 일할 때 VDI(회사 서버 안의 가상 PC)에서 돌아가게 개발했는데, Manyfast는 이런 요구에 어떻게 대응하나요?
대기업 한 곳에는 온프레미스로 구축을 들어갔어요. 저는 국내 SI(기업 전산 시스템을 대신 만들어 주는 일) 업계와 디자인 에이전시에서 5년 동안 사람 중심의 비즈니스를 했던 사람이라, 처음부터 엔터프라이즈 솔루션으로 모듈화해서 설계해야겠다고 생각했어요.
그래서 Manyfast는 지금 SaaS(구독형 소프트웨어)로 되어 있고 챗봇에서 Anthropic이나 OpenAI 모델을 골라 쓰는데, 처음부터 그 모델을 대기업이 AWS나 Azure에서 받아 둔 전용 토큰과 연결할 수 있게 설계했어요. 로컬 모델도 가능하지만 굳이 추천하지는 않아요.
SaaS로 쓰시면 와이어프레임이나 문서를 범용 형태로 내보내 클로드로 가공해 쓸 수 있게 드려요. 엔터프라이즈 전용으로 쓰시면 출력물을 회사에 맞게 커스텀할 수 있어요. 디자인 MD 파일을 넣어 회사 디자인으로 와이어프레임을 뽑을 수도 있고, 사내 기안서 양식이 있으면 엑셀이든 파워포인트든 그 양식에 맞출 수 있습니다. JSON 기반이라 출력 규격에 하네스(AI가 정해진 틀대로 일하도록 거는 장치)를 걸어 두면 바로 보고에 쓸 수 있는 형태로 만들 수 있어요.
외주 개발사에게 기획서는 고객과 무엇을 합의했는지 남기는 기록입니다
Q. 외주 개발사나 에이전시, SI 회사의 현장은 어떤가요? 기획서를 서로 어떻게 관리하면서 쓰면 좋을까요?
클라이언트에게 Manyfast로 초안을 만들어 공유하고, 피드백 코멘트도 Manyfast 화면으로 받는 거예요. 그 코멘트로 개선 기획서를 만들어 클라이언트에게 컨펌받습니다. 그러면 승인을 거쳐 이 기획서가 이렇게 바뀌었다는 내역을 남길 수 있죠.
SSOT는 결국 기준 문서예요. 나만 쓸 거면 기준 문서가 별로 필요 없을 수도 있습니다. 하지만 문서에는 결국 합의라는 목적도 있다고 생각해요.
사람들이 문서를 보고 '이게 상위 기준이고, 이걸로 의사결정하자'고 합의하는 순간이 있잖아요. 그때부터 쌓이는 의사결정과 로그를 다 남겨 두면, 외주 개발사는 나중에 분쟁이 생겼을 때 그걸 근거로 내놓을 수 있습니다.
요즘은 회의록을 전사해 공유하고 "이대로 진행하겠습니다, 괜찮으시죠?" 하고 확인받잖아요. 그런데 회의에 다 안 담기고, 개발 영역으로 넘어가면 모호해지는 것들이 있어요. 기준 문서에는 그런 것까지 세세하게 담고, 언제 누가 고쳤는지도 남길 수 있어요.
이런 클라이언트도 많이 만났어요. 엑셀로 서비스 기획안을 주고받는데, 버전이 0.8, 0.9, 1.0으로 올라가다 1.2쯤 보면 중간에 이상한 기능들이 끼어 있어요.
합의할 때 제가 다 검수하지 못한 거죠. 기능이나 제약 조건, 정책이 추가됐는데 누가, 언제, 어떤 의사결정을 했는지 남겨 두지 않으면 대부분 외주 개발사나 SI 기업, 에이전시의 손해로 돌아옵니다. 제 피해의식일 수도 있지만, 대부분은 저희가 손해를 떠안았어요.
Manyfast에서는 고객 요청서로 기획 초안을 만들고, 회의 결정과 고객 코멘트는 사람이 승인해 반영합니다
Q. 새로 바뀐 Manyfast를 같이 보면서, 기획서를 협업의 기준으로 어떻게 쓸 수 있을지 얘기해 보면 좋겠습니다.
먼저 새로 바뀐 랜딩 페이지예요. 요구 사항 정의부터 기능 명세, 흐름 검토, 화면 설계까지 다룹니다.
가입하면 튜토리얼로 들어가요. 오늘은 외주 개발사라고 가정하고 고객 프로젝트로 온보딩을 해 볼게요.
고객에게 제안 요청서(RFP)를 받았다고 해 볼게요. 이걸 합의의 정본이 되는 SSOT 기획서로 만드는 과정이에요. 요청서나 자료, 기존 회의록을 올리면 기획안 초안이 나옵니다. 실제 개발 기획으로 가려면 빠진 정보가 많아서, 1차 출시에 꼭 들어갈 것이나 일정과 예산 중 어느 쪽이 더 빠듯한지 같은 질문에 답하게 돼요.
답하고 나면 PRD와, PRD를 더 자세히 쓴 기능 명세서, 그리고 그걸 바탕으로 한 유저 플로우(사용자가 화면을 거쳐 가는 흐름)가 나옵니다. 같은 기능을 가진 제품이라도 사용자가 어떻게 쓰느냐에 따라 전혀 다른 제품이 되거든요.
예시로 '모닝브루 모바일 주문 서비스'라는 커피 주문 앱의 기획 제안서가 나왔습니다. 기능 명세서에는 기능마다 준비 중·개발 중·완료 같은 상태와 중요도, 개발 선행 조건, 트리거, 결과값, 권한과 접근까지 붙어요.
플로우 탭에서는 화면 흐름도 볼 수 있어요. AI로 플로우 차트를 그려 보면 아시겠지만, 기능은 잘 만들어도 플로우 차트는 아직 원하는 형태로 잘 안 나오는 경우가 많아요. 그래서 저희는 플로우 차트를 열심히 깎았습니다. 기능과 매칭해서, 시작점과 페이지, 데이터, 분기점에 맞춰 생성되도록 신경 썼어요.
Q. 저도 유저 플로우를 많이 그려 봐서 공감되는 게, 소셜 로그인 실패나 네트워크 오류 같은 예외 케이스를 잘 담는 거예요. 보니까 그런 것들이 이미 꽤 대비된 상태로 나오더라고요.
맞습니다. 리오랩과 SI를 하던 시절 350개 회사 정도를 상대하며 다듬었던 문서예요. '플로우가 이렇게 나오면 현업에서 못 쓰겠는데' 하면서 많이 깎았습니다.
플로우까지 나오면 다음은 클라이언트와의 대면 미팅이에요. 미팅 전에 먼저 짚어야 할 쟁점을 뽑아 주는데, 단순 확인 사항은 빼고 서로 영향을 주는 것끼리 묶어 일정과 비용에 미치는 영향까지 정리합니다. 이 예시에서는 출시 범위와 POS(매장 계산 시스템) 연동 방식, 결제 구조, 메뉴 데이터 준비 방식이 나왔어요.
회의록을 기획서에 바로 반영하는 기능도 있습니다. 캔버스에서 바로 회의를 해서 전사 회의록을 만들거나, 받은 회의록 파일을 올리면 이 기획서와 연동된 회의록이 붙어요.
여기서 '결정 추출'을 누르면 기획서에 반영할 결정이 뽑혀 나와요. 회의에서 "오늘 점심은 김치찌개"로 정한 건 당연히 빠지고, 기획서와 관련된 결정만 남습니다. 반영하면 연결된 기능에 수정이 들어가는데, 수정안을 하나씩 확인하고 승인해서 확정해요. 이 의사결정은 사람, PM이 직접 합니다.
기능 명세서를 바꿨으니 이제 유저 플로우는 낡은 버전이에요. 살아있는 기획서에서 가장 중요한 게 이 동기화입니다. 둘을 동기화하면 어긋난 곳이 적용할 항목으로 올라오고, 적용하기를 누르면 됩니다.
바뀐 부분이 이렇게 보입니다. 좀 더 짚어 드리면, 플로우 차트를 고객사에 공유했는데 고객 피드백을 받아 기능 명세서나 PRD를 고쳤다고 해 볼게요. 그때 유저 플로우 차트를 통째로 다시 뽑으면 생뚱맞은 게 나올 때가 너무 많습니다. 부분만 고치라고 해도 믿을 수가 없어요. 다른 곳의 단어가 미세하게 어긋나 있거나 모양이 달라져 있는 경우가 대부분이거든요.
이제 외부 이해관계자와 소통하는 흐름이에요. PRD나 기능 명세서, 유저 플로우 중 보여 줄 범위와 링크 이름, 만료 기한을 정해 공유합니다. 공유 페이지에는 수정 기능이나 채팅창이 없어요. 읽기에만 집중하도록 설계했습니다.
고객이 '매장 관리자만 해당 기능에 접근하게 해 주세요' 같은 코멘트를 남겼다고 해 볼게요. 그걸 복사해 붙여 넣을 필요도 없이, @로 해당 기능을 멘션하고 "여기 달린 고객 코멘트를 기획안에 반영해 줘" 한마디만 치면 됩니다. 그러면 권한과 접근 영역이 코멘트를 반영한 내용으로 나오고, 반영한 코멘트를 닫아 두는 것까지 AI 에이전트가 해 줘요.
Manyfast로 만든 기획서는 MCP로 개발 도구에 넘기고, 바뀐 과정은 버전으로 남깁니다
Q. MCP가 잘 연동돼 있으면, 업데이트된 히스토리를 바탕으로 개발자에게 넘길 수도 있겠네요.
맞습니다. 일반 MCP는 당연히 연동되고, Claude Code와 코덱스, Monday·Jira·Linear 같은 이슈 트래커(할 일과 버그를 관리하는 도구)와는 전용으로 연동돼 있어요. 저희도 3월 출시 때부터 Manyfast의 기획을 Manyfast로 해 왔는데, 기능을 만든 다음 Claude Code에 바로 개발을 넘기거나 Linear에 "이거 이슈 만들어 줘" 하는 식으로 처리합니다.
그리고 버전이 있어요. 기획에서 가장 중요한 합의와 형상 관리(무엇이 언제 어떻게 바뀌었는지 이력을 관리하는 일)를 이 기능으로 봅니다. 시점마다 새 버전으로 저장할 수 있고, AI로 고치다가 깜빡해도 자동 저장이 돼요. 고객과 합의한 시점에는 라벨을 달아 저장할 수도 있습니다.
예를 들어 저희 기획서에서 '회의실 기능'을 멘션하고 "Linear를 참고해서 업데이트 안 된 부분이 있으면 이슈 초안을 만들어 줘"라고 할 수 있어요. 그러면 문서와 이슈를 대조해서 뒤처져 있거나 반영이 안 된 항목을 알려 줍니다.
버전 기록에는 운영팀장님이 어떤 부분을 어떻게 고쳤는지가 시점마다 남아 있어요. 문서 복사본을 만들어 버전 복원을 하면 이전 버전으로 돌아갈 수도 있습니다. Git(코드 변경 이력을 관리하는 도구) 개념 그대로, Claude Code에서 포크하듯 갈래를 내서 쓸 수 있는 거죠.
Manyfast의 다음 계획, 그리고 기획을 AI에게 다 맡기면 안 되는 이유
Q. 앞으로의 계획도 궁금합니다. 글로벌 진출도, 엔터프라이즈 쪽도 많이 나아가실 것 같은데요.
바이브 코딩(말로 지시해 AI가 코드를 짜게 하는 방식)을 하는 개인이나 프리랜서, 예비 창업자를 위한 제품도 놓지 않을 거예요. 하지만 국내에서는 엔터프라이즈와 팀 단위에 집중하려고 합니다. 협업이나 형상 관리, SSOT의 가치를 느끼려면 결국 조직에서 써야 하거든요. 저희에게 친화적인 한국 시장에서 테스트베드와 고객을 많이 만들면서 제품을 계속 깎아 갈 예정이에요.
해외 전략은 조금 다릅니다. PLG(Product-Led Growth, 영업보다 제품 자체로 사용자를 모으고 키우는 성장 방식)를 한 번 더 해 보고 싶어요. 앞서 인터뷰했을 때는 한국에서 PLG만으로는 성장할 수 없다고 말씀드렸는데, 시장이 무지 크면 되지 않을까요?
제 목표는 결국 소프트웨어 기획의 표준 도구를 만드는 거였어요. 피그마가 디자인의 표준 도구라면, 소프트웨어 기획은 지금 그 자리가 비어 있다고 봅니다. 무주공산이죠. 이 틈에 PM과 기획자들이 쓰는 도구에서 1등이 되겠다는 포부로 글로벌 시장에도 알려 볼 예정입니다.
Q. 마지막으로, 국내 스타트업이나 1인 바이브 코더에게 Manyfast가 통한다면 어떤 부분일까요? 그들을 위한 계획도 있으신가요?
기획은 AI에게 다 맡겨서는 안 된다고 생각해요. AI가 만든 산출물은 결국 평균에 수렴하기 마련이거든요. 신규 제품을 AI에게 맡기면 평균적인 산출물이 나옵니다. 그래서 적어도 기획 과정은 사람이 주도해서 의사결정해야 한다고 봐요.
저희 제품도 기획을 A부터 Z까지 다 해 주는 콘셉트는 아니에요. 3월에는 그런 제품이었을 수도 있지만, 지금은 기획을 더 세심하게 구체화해 가는 제품이라고 생각합니다.
기획서 검토 기능도 있어요. 개발, 사업화, QA(품질 점검) 관점의 여러 페르소나로 기획서를 진단해 주는 기능입니다. 예비 창업자나 IT 솔루션을 처음 만들어 보는 분은 이걸로 내 기획에서 빠진 부분이 무엇인지 알 수 있어요.
그냥 AI에게 기획을 맡기면 모호한 부분이나 빠진 부분이 잘 안 보이거든요. 그래서 기획 방향을 잡아 주는 길잡이 역할도 할 수 있지 않을까 조심스럽게 생각해 봅니다.
Manyfast Team 플랜을 1달러에 14일 동안 써 볼 수 있는 특별 링크를 준비했습니다. :)
아래 링크로 Team 플랜을 1달러에 14일 동안 체험할 수 있어요. 팀원과의 협업, 상위 AI 모델, 버전 관리, 문서 커스텀까지 모든 기능을 쓸 수 있고, 무료 크레딧의 10배를 한 번에 받습니다. 이 글에 나온 회의 결정 반영, 이슈 트래커 연동, 여러 관점의 기획서 검토도 Team 플랜에서 써 볼 수 있어요. 14일이 지나면 자동 결제 없이 무료 플랜으로 돌아가요. (Manyfast 첫 결제 고객 대상이며, 이전에 체험판이나 정식 결제 이력이 있는 계정은 이용할 수 없습니다.)
👉 1달러로 Team 플랜 14일 체험하기
조쉬가 직접 운영하는 AI 솔로프리너 클럽에 초대합니다.
이미 300명이 넘는 분들이 ASC와 함께 성장하고 있습니다.
구글 엔지니어, 토스 PM, 산부인과 전문의, 스타트업 대표까지
— 각자의 자리에서 정상에 선 사람들이 지금 AI로 새로운 도전을 시작했습니다.
그리고 ASC 14기는 단 30명만 함께합니다.
아직 늦지 않았습니다.
지금 시작하는 당신이, 1년 뒤 가장 앞서 있을 솔로프리너입니다.
의견을 남겨주세요