혼자서 LLM 앱 MVP 1주일에 만들기: 기능 범위 좁히는 법

1. 일주일 MVP의 기준은 ‘앱 완성’이 아니다

일주일 안에 LLM 앱을 만든다는 말은 기능이 많은 서비스를 완성한다는 뜻이 아닙니다. 사용자가 특정 입력을 넣고, 결과를 받아, 다음 행동으로 이어지는 한 가지 흐름을 실제로 경험하게 만든다는 뜻에 가깝습니다.

조코헌트에는 이미 262개의 프로덕트가 출시되어 있고, 그중 AI 도구가 42%를 차지합니다. AI 앱을 만드는 사람이 많은 만큼 “무엇을 만들까”보다 “어디까지 만들지”가 더 중요한 경쟁력이 됩니다.

핵심 행동을 한 문장으로 쓰기

먼저 다음 문장을 완성해 보세요.

사용자는 ___를 입력하고, 앱은 ___를 제공해, 사용자가 ___를 한다.

예를 들어 “문서를 올리고 요약을 받아 핵심 항목을 확인한다”처럼 씁니다. 로그인, 결제, 공유, 대시보드 같은 기능은 이 흐름을 돕는지 따져야 합니다. 핵심 행동을 직접 돕지 않는다면 일주일 MVP에서는 우선순위를 낮춥니다.

성공 신호도 하나만 고르기

첫 버전의 목표는 가입자 수가 아니라 핵심 행동의 완료 여부가 될 수 있습니다. 사용자가 결과를 다시 요청했는지, 결과를 복사했는지, 문제 해결에 활용했는지처럼 제품의 가설과 가까운 신호를 하나 정하세요. 지표를 여러 개 추적하면 그럴듯한 숫자는 늘어나지만, 무엇을 개선해야 하는지는 오히려 흐려집니다.

2. 기능 후보를 ‘모델 호출 전후’로 자르기

LLM 앱은 기능 목록으로 생각하면 금방 커집니다. 대신 모델 호출을 중심으로 입력과 출력의 경계를 그어 보세요.

입력 단계에서 덜어낼 것

처음에는 입력 형식을 하나로 제한하는 편이 안전합니다. 텍스트만 받을지, 파일까지 받을지, 이미지와 음성도 받을지 결정하세요. 여러 형식을 동시에 지원하면 파싱, 오류 처리, 안내 문구가 함께 늘어납니다.

사용자가 어떤 정보를 입력해야 좋은 결과가 나오는지도 짧은 예시로 보여주세요. 자세한 설정 화면을 만드는 대신, 기본 프롬프트와 최소한의 선택지만 제공하는 방식이 적합합니다. 프롬프트를 설계할 때는 AI에게 코드를 잘 시키는 프롬프트 작성법의 명세·제약·예시 구조를 응용할 수 있습니다.

출력 단계에서 검증할 것

출력은 화려한 UI보다 일관성이 중요합니다. 결과의 형식, 길이, 실패 시 안내를 먼저 정하세요. 같은 입력에 결과가 크게 흔들리면 사용자는 기능보다 신뢰성 문제를 먼저 느낍니다.

초기에는 스트리밍, 대화 기록, 결과 편집, 팀 공유를 모두 넣기보다 결과를 읽고 복사하는 경험부터 확인하세요. 모델 선택과 토큰 사용량은 LLM API 비용 폭탄 피하기를 참고해 예상치 못한 운영 비용을 줄일 수 있습니다.

3. 7일을 기능이 아니라 검증 단계로 나누기

일주일 일정은 “월요일 프론트엔드, 화요일 백엔드”처럼 기술별로 쪼개기보다 가설을 검증하는 순서로 배치하는 것이 좋습니다.

1~2일차: 흐름과 실패 조건 정의

핵심 입력과 기대 출력 예시를 몇 개 작성하고, 결과가 부족하거나 모델 호출이 실패했을 때 사용자가 무엇을 보게 될지 정합니다. 이때 코딩 한 줄 몰라도 시작하는 LLM 앱 만들기에서 다룬 입력·호출·출력의 기본 구조를 참고하면 설계가 단순해집니다.

3~5일차: 가장 짧은 세로 슬라이스 구현

화면 한 장, API 경로 하나, 결과 화면 하나가 연결되는 세로 슬라이스를 먼저 만드세요. 데이터베이스나 인증이 꼭 필요하지 않다면 임시 저장으로 시작해도 됩니다. 중요한 것은 각 부품을 따로 완성하는 것이 아니라 사용자가 처음부터 끝까지 한 번 통과할 수 있는지 확인하는 것입니다.

6~7일차: 실제 사용과 수정

테스트 입력을 고정해 두고 결과 품질, 오류 메시지, 대기 경험을 점검합니다. 그다음 핵심 흐름을 막는 문제만 수정하고 출시합니다. 코드 품질과 보안 검토는 AI가 짠 코드를 믿어도 될까의 체크리스트처럼 별도 목록으로 관리하면 범위가 섞이지 않습니다.

4. ‘나중에’로 보내도 되는 기능의 기준

기능을 뺄 때는 감이 아니라 질문으로 판단하세요.

지금 넣을 기능

• 핵심 결과를 만드는 데 직접 필요한가?
• 사용자가 기능의 가치를 판단하려면 꼭 필요한가?
• 실패했을 때 사용자가 다시 시도할 방법이 있는가?

셋 중 하나라도 중요하다면 최소 형태로 포함합니다. 예를 들어 인증이 필요하다면 소셜 로그인 여러 개 대신 한 가지 방식으로 시작할 수 있습니다.

다음 버전으로 미룰 기능

• 사용자가 반복해서 요청하기 전까지 가치가 불확실한 기능
• 핵심 결과와 관계없는 개인화·테마·고급 설정
• 운영 데이터가 쌓여야 설계할 수 있는 추천·자동화 기능
• “있으면 좋아 보이는” 공유·알림·관리자 화면

미루는 것은 삭제가 아닙니다. 문서나 이슈에 보관하되, 출시 후 실제 요청이 반복될 때 다시 꺼내세요.

5. 출시 후에만 알 수 있는 것

책상 앞에서는 모든 기능이 필요해 보이지만, 사용자는 예상보다 좁은 문제만 해결하려고 들어올 수 있습니다. 조코헌트에서 출시 첫 24시간 안에 업보트나 댓글을 하나라도 받은 프로덕트는 59%였습니다. 이 수치가 성공을 보장하지는 않지만, 완벽한 기능 목록을 기다리기보다 작동하는 가설을 먼저 공개할 이유는 충분합니다.

출시 직후에는 “기능을 더 만들까?”보다 다음을 관찰하세요. 사용자가 어디에서 멈추는지, 어떤 입력을 반복하는지, 결과를 어떻게 활용하는지, 그리고 어떤 기능을 직접 요청하는지입니다. 그 관찰이 다음 일주일의 범위를 정합니다.

좋은 LLM 앱 MVP는 작아서 부족한 제품이 아니라, 무엇을 검증하려는지 선명한 제품입니다. 핵심 행동 하나를 고르고 입력·출력의 경계를 정한 뒤, 일주일 안에 실제 사용 장면까지 연결해 보세요.