AI 도구로 만들고
배포하기
도구를 고르고, AI에게 작업을 지시하고, 첫 루프의 범위를 정한 뒤, 실제로 접속할 수 있는 URL로 배포하기까지 — 첫 MVP를 만드는 과정을 순서대로 설명합니다.
데모 방식의 변화
만드는 일이 쉬워지면서, 팀 간 차이는 코딩 능력보다 문제 정의와 검증 습관에서 생기게 되었습니다.
"여기를 누르면 이 화면으로 넘어갈 예정입니다"
몇 해 전 캡스톤 최종 발표장에서는, 개발을 맡을 사람이 없는 팀의 데모가 대부분 그림이었습니다. 디자인 도구로 그린 앱 화면 몇 장을 차례로 띄우고, 발표자가 화살표를 따라가며 "여기를 누르면 이 화면으로 넘어갈 예정"이라고 설명하는 방식이었습니다. 화면 속 버튼은 눌리지 않았습니다.
지금은 상황이 다릅니다. 코드를 배운 적 없는 팀도 프롬프트 몇 시간이면 실제로 동작하는 웹앱 초안을 만들 수 있습니다. 그래서 이 수업의 9주차 데모 발표에서는 그림 목업이 아니라 실제 배포된 서비스의 시연을 권장합니다.
다만 만드는 일이 쉬워졌다고 해서 팀 간 격차가 사라진 것은 아닙니다. 격차가 생기는 지점이 달라졌을 뿐입니다. 코딩 능력의 비중이 줄어든 자리에서 차이를 만드는 것은 무엇을 만들지 정확히 정의하는 능력과 만든 것을 직접 확인하는 검증 습관입니다. 이 장은 그 두 가지를 다룹니다.
"빠르게 만들어 검증한다"는 접근 자체는 새로운 것이 아닙니다. 에릭 리스가 2011년 린 스타트업에서 정리한 MVP(Minimum Viable Product)는 "최소한의 노력으로 검증된 학습을 최대화하는 제품 버전"을 뜻합니다. 달라진 것은 그 최소 버전을 만드는 비용입니다. 예전에는 MVP조차 개발자의 몇 주 작업이 필요해서, 개발자가 없는 팀은 설문이나 그림 목업으로 대신할 수밖에 없었습니다. AI 도구는 그 제약을 상당 부분 줄였습니다.
이런 작업 방식을 가리키는 "바이브 코딩(vibe coding)"이라는 표현은 2025년 초 안드레이 카파시(Andrej Karpathy)의 언급에서 널리 퍼진 것으로 알려져 있습니다 — 코드의 세부를 직접 통제하는 대신 자연어로 방향을 주고 결과를 받아들이며 진행하는 방식이라는 의미였습니다. 이 장에서는 이 말을 조금 더 엄격하게 사용합니다. 방향만 주고 결과를 검증 없이 받아들이는 것은 이 수업이 권장하는 방식이 아니며, §2의 네 가지 원칙이 그 기준선입니다.
출처 Ries, The Lean Startup, Crown Business, 2011 · "바이브 코딩" 표현의 유래는 2025년 초 카파시의 소셜미디어 게시글로 알려져 있습니다(정황 표기 · 1차 자료 링크는 생략).
도구 지형: 세 계열
도구 이름은 자주 바뀝니다. 명세를 주고 결과를 검증하는 사람의 역할은 어느 도구에서든 같습니다.
세 계열의 도구와 적합한 상황
AI 빌드 도구는 크게 세 계열로 나눌 수 있습니다. 어느 것이 더 우월한가의 문제가 아니라, 팀의 기술 수준과 이번 루프의 목표 산출물에 무엇이 맞는가의 문제입니다.
| 계열 | 예시 (작성 시점 기준) | 무엇을 해 주는가 | 한계 | 이런 팀에 |
|---|---|---|---|---|
| ① 에이전트형 코딩 도구 |
Claude Code, Cursor, GitHub Copilot |
코드베이스를 이해하고 직접 수정·확장합니다. 자유도가 가장 높고, 외부 API 연동이나 데이터베이스 등도 붙일 수 있습니다 | 코드와 터미널 개념에 대한 러닝커브가 있습니다. 결과를 검토하려면 최소한의 코드 읽기가 필요합니다 | 코드를 읽어 본 팀원이 한 명이라도 있고, 세부를 직접 제어하고 싶은 팀 |
| ② 프롬프트→앱 빌더 |
v0, Lovable, Bolt, Replit |
대화만으로 웹앱 초안이 빠르게 나오고, 대부분 호스팅(배포)까지 버튼 하나로 제공합니다 | 세부 제어와 복잡한 연동에 한계가 있습니다. 앱이 커지면 "말로 고치기"가 오히려 어려워집니다 | 전원 비개발자인 팀의 첫 루프. 며칠 안에 동작하는 URL이 필요할 때 |
| ③ 디자인·프로토 타입 도구 |
Figma | 화면 설계와 클릭 목업을 만듭니다. 만들기 전에 팀·사용자와 화면 흐름을 합의하는 데 가장 빠릅니다 | 실제로 동작하지 않습니다. 이 수업의 데모 권장 기준(배포된 서비스)을 이것만으로는 채우기 어렵습니다 | 빌드에 들어가기 전, 화면 흐름을 적은 비용으로 합의하고 싶은 모든 팀 |
도구 지형은 몇 달 단위로 바뀝니다. 위 표의 이름들은 작성 시점 기준의 예시이며, 이번 학기의 권장 도구와 지원 계정(교육용 크레딧 등)은 eclass 공지가 기준입니다. 표에서 기억할 것은 개별 이름보다, 세 계열의 구분과 자유도·진입장벽이 서로 맞바꾸는 관계라는 구조입니다.
세 계열은 배타적이지 않습니다. 실제 팀의 흔한 경로는 ③으로 화면 흐름을 짧게 합의하고, ②로 첫 배포 URL을 만들고, 빌더의 한계에 부딪히는 지점(외부 데이터 연동, 세밀한 로직)에서 ①로 옮기거나 병용하는 것입니다. 도구를 바꾸는 것이 부담스럽게 느껴질 수 있지만, 이 수업의 산출물은 코드가 아니라 검증된 학습이므로 도구를 바꿔도 잃는 것은 생각보다 적습니다.
어느 계열을 쓰든 공통 원리가 있습니다. 도구는 실행을 대신할 뿐, 무엇을 만들지 정의하는 일(명세)과 만들어진 것이 맞는지 판단하는 일(검증)은 사람의 몫으로 남습니다. 도구가 바뀔 때마다 새로 배워야 하는 것은 조작법이고, 한 번 익히면 도구가 바뀌어도 그대로 쓸 수 있는 것이 명세와 검증의 기술입니다. 다음 절에서 그 기술을 다룹니다.
어떤 도구를 어떻게 썼는지는 기록해 두어야 합니다. 최종보고서의 요구 항목에 "제품 및 서비스 개발 과정(시간, 비용, 개발 tool, 핵심 기능, 시장 테스트 계획)"이 명시되어 있습니다. 루프마다 사용 도구·소요 시간·비용을 그때그때 적어 두면 보고서 작성 때 그대로 옮길 수 있습니다.
출처 각 도구의 기능과 요금은 해당 공식 사이트 기준(작성 시점의 예시이며, 학기 중 권장 도구는 eclass 공지 기준) · MVP 개념: Ries, The Lean Startup, 2011.
바이브 코딩의 규율
명세, 작은 단위 작업, 버전 보존, 사람의 검증 — AI에게 일을 맡길 때 지킬 네 가지 원칙을 설명합니다.
AI에게 일을 맡길 때의 네 가지 원칙
AI 도구를 쓰는 빌드가 어려움을 겪는 경우, 원인은 대개 도구가 아니라 지시하는 방식에 있습니다. 다음 네 가지 원칙이 흔한 문제의 대부분을 예방합니다.
- 프롬프트가 명세입니다. 모호한 요청은 모호한 결과물로 이어집니다. "로그인 기능 만들어 줘"가 아니라, 행위자·행동·목적이 담긴 사용자 스토리 형식으로 씁니다 — "러너가 이메일로 가입하고, 크루를 검색해, 참가 신청을 보낼 수 있다." 이렇게 쓰면 만들 범위가 정해지고, 완성 여부를 판정할 기준(신청이 실제로 보내지는가)이 같은 문장 안에 생깁니다.
- 작게 만들고 자주 확인합니다. 한 번의 요청은 화면 하나, 흐름 하나 정도로 잡습니다. "앱 전체를 만들어 줘" 같은 큰 요청은 AI도 정확히 수행하기 어렵고, 나온 결과를 사람이 검증하기도 어렵습니다.
- 버전을 보존합니다. 루프마다 "동작하는 버전"을 반드시 남깁니다. git을 쓸 줄 알면 git으로, 아니면 도구가 제공하는 버전·스냅샷 기능으로 남기면 됩니다. 이전 버전으로 되돌릴 수 없으면 새로운 시도를 하기 어렵습니다 — 실패했을 때 돌아갈 지점이 없기 때문입니다.
- 검증 책임은 사람에게 있습니다. AI가 만든 화면을 눈으로 보는 데서 그치지 않고, 사용자 흐름을 처음부터 끝까지 직접 눌러 봅니다. 가입하고, 검색하고, 신청 버튼을 누르고, 그 신청이 실제로 기록되는지까지 확인합니다. 겉보기에 완성된 화면과 실제로 동작하는 화면은 다르며, AI가 만든 결과물은 전자에 그치는 경우가 적지 않습니다.
원칙 ①의 사용자 스토리 형식은 애자일 개발에서 오래 쓰여 온 관행("As a ~, I want ~, so that ~")을 한국어로 줄인 것입니다. 이 형식의 장점은 문장 구조가 테스트를 내장한다는 점입니다. "러너가 참가 신청을 보낼 수 있다"는 문장은 그대로 검증 절차가 됩니다 — 러너 계정으로 신청을 보내 보면 됩니다. 반면 "신청 기능"이라는 명사형 요청은 어디까지 만들면 완성인지, 무엇을 확인하면 되는지를 알려 주지 않습니다.
원칙 ②와 ④는 한 쌍으로 움직입니다. 확인 없이 쌓은 다섯 개의 기능보다, 매번 끝까지 확인한 두 개의 기능이 프로젝트를 더 안정적으로 전진시킵니다. AI 도구의 오류는 대개 눈에 띄는 에러 화면이 아니라 겉보기에 정상인 화면으로 나타나기 때문입니다 — 저장되지 않는 폼, 눌리지 않는 버튼, 새로고침하면 사라지는 데이터 같은 문제는 사람이 흐름 끝까지 가 보기 전에는 발견되지 않습니다.
출처 사용자 스토리 관행: Cohn, User Stories Applied, Addison-Wesley, 2004 · MVP와 검증된 학습: Ries, The Lean Startup, 2011.
배포 전에 확인할 보안 사항
실제로 자주 일어나는 사고 유형이 있습니다. 지도·AI 등의 API를 쓰기 위해 발급받은 키를 코드에 그대로 적은 채 공개 배포하고, 이후 소스 보기를 통해 키가 노출되어 외부에서 무단 사용되는 경우입니다.
- API 키·비밀번호를 코드에 하드코딩하지 않습니다. 키는 환경변수나 서버 측에 두고, 프론트엔드 코드와 공개 저장소에는 넣지 않습니다. AI에게 지시할 때도 "키는 환경변수로 분리하라"고 명세에 적어 둡니다. 이미 노출된 키는 코드에서 지우는 것으로 끝나지 않으므로, 즉시 폐기하고 재발급합니다.
- 개인정보 수집은 최소화합니다. 수집하는 순간 보호할 책임이 생깁니다. 첫 루프의 가설을 검증하는 데 전화번호·생년월일·위치 이력이 정말 필요한지 먼저 묻고, 이메일 하나로 시작할 수 있다면 이메일만 받습니다.
- AI가 만든 기본 설정을 그대로 신뢰하지 않습니다. 관리자 페이지에 인증이 걸려 있는지, 다른 사용자의 데이터가 URL만 바꾸면 보이지는 않는지 — 배포 전에 사람이 직접 확인합니다.
"학생 프로젝트인데 누가 노리겠나"라는 생각이 이런 사고의 출발점이 되기 쉽습니다. 그러나 공개된 웹의 저장소와 페이지를 자동으로 훑으며 키 패턴을 수집하는 봇이 상시 돌고 있어서, 프로젝트의 규모나 인지도와 무관하게 노출된 키는 발견됩니다. 무료 할당량이 있는 키라도 도용되면 할당량 소진으로 서비스가 멈추고, 결제 수단이 연결된 키라면 요금이 쌓입니다.
개인정보 항목은 반대 방향에서 생각할 문제입니다. 사용자가 늘어난 뒤 "그때 왜 이 정보를 받았을까"를 후회하는 경우는 있어도, 덜 받아서 문제가 되는 경우는 드뭅니다. 수집 항목이 늘수록 가입 단계의 이탈도 늘어나므로, 최소 수집은 법적·윤리적 요구인 동시에 전환율 측면에서도 유리한 선택입니다.
출처 키 노출 시 대응(폐기·재발급 원칙)은 각 API 제공사 보안 문서의 공통 권고 사항입니다 · 개인정보 최소 수집: 개인정보 보호법의 최소 수집 원칙(제3조) 참조.
AI 도구 사용과 평가에 대한 오해
"AI 도구로 만들면 우리가 만든 것이 아니어서 평가에 불리하다. 직접 코딩한 팀이 더 좋은 점수를 받을 것이다."
그렇지 않습니다. 이 수업에서 AI 도구 사용은 감점 요인이 아니라 전제입니다. 계산기가 허용된 시험에서 암산 실력을 평가하지 않는 것과 같습니다. 평가되는 것은 코드를 누가 작성했는가가 아니라, 무엇을 만들지 정의했는가, 만든 것을 검증했는가, 피드백으로 개선했는가라는 과정의 기록입니다. 이 과정은 AI가 대신해 줄 수 없습니다.
오히려 도구 사용의 기록 자체가 평가 대상입니다. 최종보고서의 "개발 과정" 항목은 어떤 도구를 어떤 작업에 썼고 시간과 비용이 얼마나 들었는지를 요구합니다. "AI에게 어떻게 지시했더니 어디까지 되었고, 어디서 사람이 개입해야 했다"를 구체적으로 쓸 수 있는 팀은 그만큼 많이 배웠다는 것을 보여 주는 것이며, 그 기록까지가 이 수업에서 말하는 실력입니다.
출처 최종보고서 요구 항목 "제품 및 서비스 개발 과정(시간, 비용, 개발 tool, 핵심 기능, 시장 테스트 계획)" — 수업 계획서 기준, 확정본은 eclass 공지.
MVP 범위 — 무엇을 안 만들 것인가
MVP 범위는 넣을 기능보다 뺄 기능을 정하는 일에 가깝습니다. 서비스 개념도에는 거래와 수익 프로세스가 포함되어야 합니다.
최단 경로 하나, 기능 3개 이하
첫 루프에서 만드는 것은 "가입 → 핵심 가치 경험 → 거래(신청·예약·구매)"로 이어지는 최단 경로 하나입니다. 이 경로에 필요하지 않은 기능은 아무리 좋아 보여도 넣지 않습니다. 기준선은 기능 3개 이하입니다.
- 경로는 하나만 만듭니다. 첫 루프의 가설은 하나("사용자가 이 거래 행동을 하는가")이고, 가설 하나를 판정하는 데는 경로 하나면 충분합니다. 경로가 둘이면 어느 쪽에서 문제가 생겼는지 데이터로 구분하기 어렵습니다.
- 기능은 3개 이하로 잡습니다. 숫자 자체보다 상한이 있다는 사실이 중요합니다. 상한이 있어야 "이 기능이 정말 첫 가설에 필요한가"라는 질문이 기능마다 붙습니다. 상한이 없으면 모든 기능이 "있으면 좋은 것"으로 통과됩니다.
- 뺀 기능은 백로그에 기록합니다. 버리는 것이 아니라 미루는 것입니다. 뺀 기능을 이유와 함께 목록으로 남겨 두면, 다음 루프에서 피드백이 그 기능을 요구할 때 근거를 갖고 다시 넣을 수 있습니다. "무엇을 왜 뺐는가"의 기록은 2차 보고서에서 범위 판단의 근거 자료가 됩니다.
"최소(minimum)"와 "생존 가능(viable)"은 서로 반대 방향으로 당기는 조건입니다. 최소만 좇으면 가치가 경험되지 않는 미완성 앱이 되고, 생존 가능만 좇으면 범위가 계속 늘어납니다. 균형을 잡는 실용적인 질문은 다음과 같습니다 — "이 기능이 없으면 첫 가설을 판정할 수 없는가?" 판정할 수 있다면 뺍니다. 예를 들어 채팅이 없어도 참가 신청이 일어나는지는 판정할 수 있으므로, 채팅은 첫 루프에서 뺍니다.
범위를 줄이는 것이 목표를 낮추는 것은 아닙니다. 루프당 범위가 작을수록 학기 동안 돌릴 수 있는 루프 수가 늘고, 그만큼 검증할 수 있는 가설도 많아집니다. 최종보고서에 담기는 검증된 학습의 총량은 한 번에 만든 기능 수가 아니라 돌린 루프 수에 비례합니다.
출처 Ries, The Lean Startup, 2011, MVP와 Build-Measure-Learn · 범위·백로그 기록과 보고서의 연결은 이 수업 운영 기준(1장 참조).
거래와 수익이 보이는 서비스 개념도
이 수업의 서비스 개념도 규칙은 다음과 같습니다. 고객·운영자·파트너 등 이해관계자의 협력 과정을 그리되, 거래와 수익이 발생하는 프로세스를 반드시 포함합니다. 가상의 "동네 러닝 크루 매칭" 서비스로 예를 들면 아래와 같습니다.
서비스 개념도는 이해관계자(고객·운영자·파트너)의 협력 과정을 그리되, 거래와 수익이 발생하는 프로세스를 반드시 포함해야 합니다. 화면 흐름도(어느 버튼이 어느 화면으로 이동하는가)와는 다른 문서입니다 — 화면 흐름도에는 돈의 흐름이 나타나지 않습니다.
개념도에서 가장 흔한 미비점은 화살표가 전부 서비스 흐름(청록색)인 그림입니다. "사용자가 검색하고, 매칭받고, 채팅한다"까지만 그리면 기능의 나열이지 사업의 구조가 아닙니다. 연습으로는 붉은 화살표부터 그려 보는 방법이 유용합니다 — 누가, 누구에게, 왜 돈을 내는가를 먼저 정하면, 그 지불이 성립하는 데 필요한 서비스 흐름이 역으로 정해집니다. 2장의 린 캔버스에서 수익원 칸을 채웠다면, 개념도의 붉은 화살표는 그 칸을 그림으로 옮긴 것입니다.
첫 루프의 MVP가 결제 기능을 포함하지 않는 것과 개념도에 돈 흐름을 그리는 것은 모순이 아닙니다. 개념도는 사업이 완성되었을 때의 구조를 그리는 문서이고, MVP는 그 구조로 가는 첫 가설만 검증합니다. 광고비를 받는 일은 러너의 참가 신청이 실제로 일어난다는 근거가 생긴 다음 단계의 일입니다.
출처 서비스 개념도 규칙(거래·수익 프로세스 필수)은 수업 계획서의 명시 요구 사항 · 수익 모델 유형 정리: Osterwalder & Pigneur, Business Model Generation, Wiley, 2010.
배포: 피드백 수집의 시작
배포는 개발의 마지막 단계가 아니라 피드백 수집의 시작입니다. 데모 발표에서도 배포된 서비스의 시연을 권장합니다.
배포의 의미와 무료 배포 경로
배포(deploy)란 서비스를 인터넷의 공개 주소(URL)에 올려서 누구나 접속할 수 있게 만드는 일입니다. 피드백 루프는 이 시점부터 돌기 시작합니다 — 다른 사람이 자신의 폰으로 링크를 열어 가입해 볼 수 있어야, 사용자의 행동이라는 데이터가 생기기 때문입니다.
- 프롬프트→앱 빌더를 쓰는 팀: 대부분 배포 기능이 내장되어 있습니다. 배포 버튼을 누르면 공개 URL이 나오며, 첫 루프에는 이것으로 충분합니다.
- 직접 코드를 다루는 팀: 무료 정적 호스팅 서비스가 여럿 있습니다. 이 학부의 인공지능 과목 과제에서 쓰는 Cloudflare Pages가 익숙한 선례이므로 같은 방식을 그대로 쓸 수 있고, Vercel·Netlify·GitHub Pages 등도 같은 역할을 합니다.
- 비용: 위 경로들의 무료 범위로 캡스톤 규모의 트래픽은 충분히 감당됩니다. 유료 결제가 필요해 보인다면 먼저 범위 설정을 다시 점검해 보는 것이 좋습니다.
"기말에 완성해서 한 번에 배포"는 이 수업의 일정과 맞지 않는 계획입니다. 일정을 역산해 보면 이유가 분명해집니다. 2차 보고서(8주차)에 배포된 MVP와 첫 피드백 결과가 들어가야 하고, 9주차 데모 발표는 배포된 서비스의 시연을 권장합니다. 즉 늦어도 7주차에는 첫 배포가 끝나 있어야 피드백을 모을 시간이 확보됩니다. 첫 배포가 빠를수록 같은 학기 안에서 돌릴 수 있는 루프 수도 늘어납니다.
배포를 미루게 되는 흔한 이유는 "아직 보여 주기에 부족해서"입니다. 그러나 첫 루프의 목적은 좋은 인상을 남기는 것이 아니라 가설을 판정하는 것입니다. 완성도가 낮은 버전이라도 실제 사용자에게 보여 주고 얻은 행동 데이터가, 배포 없이 다듬기만 한 몇 주보다 더 많은 정보를 줍니다.
출처 Cloudflare Pages 공식 문서: developers.cloudflare.com/pages · 2차 보고서·데모 발표 요건은 수업 일정 기준(목차 페이지의 마일스톤 표 참조).
배포 직후에 확인할 네 가지
배포 직후 10분의 점검이 첫 사용자들의 경험을 좌우합니다. 아래 순서대로, 개발에 쓰지 않은 기기 — 가급적 본인 폰 — 로 직접 확인합니다.
- 모바일 화면. 첫 사용자 대부분은 메신저로 받은 링크를 폰에서 엽니다. 폰 화면에서 글자가 잘리거나 버튼이 겹치면 그 지점에서 이탈이 일어납니다. 데스크톱에서만 확인한 배포는 절반만 확인한 것입니다.
- 첫 로딩 속도. 링크를 눌러서 화면이 뜨기까지 몇 초가 걸리는지 확인합니다. 수 초 이상 걸리면 원인을 찾습니다 — 압축하지 않은 대용량 이미지가 흔한 원인입니다.
- 가입 흐름을 끝까지. 새 이메일로 실제 가입하고, 검색하고, 신청 버튼까지 눌러서 기록이 남는지 확인합니다. §2 원칙 ④의 배포판입니다 — 로컬에서 되던 것이 배포 환경에서 조용히 깨지는 일은 드물지 않습니다.
- 콘솔 에러. 브라우저 개발자 도구(F12)의 콘솔 탭을 엽니다. 빨간 에러가 있으면 화면이 정상으로 보여도 어딘가 동작하지 않는 부분이 있다는 뜻입니다. 에러 문구를 그대로 AI 도구에 붙여 넣으면 대부분 원인을 찾는 데 도움이 됩니다.
8주차 2차 보고서에는 배포된 MVP(URL 포함)와 첫 피드백 결과, 갱신된 캔버스가 들어갑니다. 9주차 데모 발표는 그 URL을 심사자 앞에서 실제로 열어 시연하는 자리입니다. 위 네 가지 점검을 매 배포마다 반복해 온 팀이라면 발표 당일의 라이브 시연도 특별히 준비할 것이 없습니다.
점검 목록에 "모든 브라우저 테스트"나 "부하 테스트"가 없는 이유도 범위 규칙과 같습니다. 첫 루프의 사용자는 수십 명 수준이고, 이들의 접속 환경은 사실상 폰 브라우저 한두 종입니다. 이 단계에서 완벽한 호환성에 쓰는 시간은 가설 검증에서 빼 오는 시간입니다. 다만 넷 중 ③(흐름 끝까지)만은 생략하지 않아야 합니다 — 가입이 되지 않는 서비스는 피드백 자체를 수집할 수 없어서, 루프가 돌지 않기 때문입니다.
출처 Cloudflare Pages 배포 안내: developers.cloudflare.com/pages · 점검 항목은 이 수업의 운영 기준이며, 발표 방식 확정본은 eclass 공지.
MVP 다이어트
기능 후보 9개 중 3개를 남기는 연습을 통해, 범위 결정의 기준이 기능의 좋고 나쁨이 아니라 첫 가설임을 확인합니다.
남길 3개 고르기
한 줄 목표: "동네 러닝 크루 매칭" 서비스의 기능 후보 9개에서 첫 루프에 남길 3개를 직접 고르고, 그 선택이 가입 → 가치 경험 → 거래(신청)의 최단 경로를 이루는지 판정해 봅니다.
첫 루프의 가설: "러너가 크루에 참가 신청을 보내는가"
아래 9개 중 정확히 3개를 선택하면 판정 버튼이 활성화됩니다. 남길 이유보다 뺄 이유를 생각하며 골라 보세요.
조작 안내 — ① 9개를 훑고 3개를 체크합니다(4번째 체크는 자동으로 해제됩니다). ② 판정을 누르고 선택별 해설을 읽습니다. ③ "다시 고르기"로 다른 조합, 특히 참가비 결제를 포함한 조합도 한 번 판정해 보세요.
관찰 포인트 — 남긴 3개가 가입 → 가치 경험 → 거래(신청)의 경로를 끊김 없이 이루는지 확인합니다. 참가비 결제를 골랐다면 해설에서 왜 첫 루프의 가설과 어긋나는지 확인해 보세요. 이 실습의 핵심은 권장 조합을 맞히는 것이 아니라, 뺀 6개 각각에 대해 "왜 뺐는지"를 한 문장으로 설명할 수 있게 되는 것입니다 — 그 문장들이 그대로 팀의 백로그가 됩니다.
권장 조합이 유일한 정답은 아닙니다. 예를 들어 팀의 첫 가설이 "러너가 아니라 크루장이 크루를 등록하는가"라면 남길 3개는 완전히 달라집니다. 실습의 판정이 확인하는 것은 조합의 일치가 아니라 구조입니다 — 어떤 가설을 세웠든, 남긴 기능들이 그 가설을 판정하는 하나의 경로를 이루고 있는가. 팀 회의에서 이 실습을 실제 기능 후보 목록으로 반복해 보기를 권합니다. 후보가 9개에서 20개로 늘어도 규칙은 같습니다.
출처 MVP 범위 규칙은 §3, 첫 루프 가설의 설정은 2장(문제 발견과 사업 모델) 참조.
퀴즈와 핵심 정리
먼저 스스로 답한 뒤 펼쳐서 확인해 보세요.
퀴즈
"로그인 기능을 만들어 줘"보다 "러너가 이메일로 가입하고, 크루를 검색해, 참가 신청을 보낼 수 있다"가 더 나은 프롬프트인 이유는 무엇일까요? 두 가지 이상 들어 보세요.
첫 루프에서 뺀 기능은 어떻게 처리하나요? 그 처리 방식은 첫 루프의 가설과 어떤 관계가 있나요?
API 키를 코드에 넣은 채 공개 배포하면 어떤 문제가 생기나요? 이미 노출되었다면 무엇을 해야 하나요?
하나. 도구는 계속 바뀌지만, 명세를 작성하고 결과를 검증하는 일은 사람의 역할로 남습니다. 그것이 이 수업에서 평가하는 능력이며, 어떤 도구를 어떻게 썼는지는 최종보고서 "개발 과정" 항목의 기록 대상입니다.
둘. MVP 범위는 가입 → 가치 경험 → 거래로 이어지는 최단 경로 하나, 기능 3개 이하로 정합니다. 뺀 기능은 이유와 함께 백로그에 기록합니다. 서비스 개념도에는 거래와 수익이 발생하는 프로세스를 반드시 포함합니다.
셋. 배포는 피드백 수집의 시작이며, 데모 발표에서도 배포된 서비스의 시연을 권장합니다. 배포 직후에는 모바일 화면, 로딩 속도, 가입 흐름, 콘솔 에러의 네 가지를 점검합니다.
참고문헌
링크는 확실한 것만 걸었습니다. 도구 예시는 작성 시점 기준이며, 학기 중 권장 도구는 eclass 공지 기준입니다.
개념과 방법
- Ries, E. (2011). The Lean Startup. Crown Business. — MVP(최소 기능 제품)와 Build-Measure-Learn 루프를 정리한 책입니다.
- Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley. — 사용자 스토리 형식의 표준 참고서입니다.
- Osterwalder, A., & Pigneur, Y. (2010). Business Model Generation. Wiley. — 수익 모델 유형과 이해관계자 구조를 다룹니다.
- "바이브 코딩(vibe coding)" — 이 표현은 2025년 초 안드레이 카파시(Andrej Karpathy)의 소셜미디어 언급에서 널리 퍼진 것으로 알려져 있습니다(정황 표기).
도구와 배포
- Cloudflare Pages 공식 문서. developers.cloudflare.com/pages — 무료 정적 호스팅 서비스로, 이 학부 인공지능 과목 과제와 같은 배포 방식입니다.
- 개별 AI 빌드 도구 (Claude Code, Cursor, GitHub Copilot, v0, Lovable, Bolt, Replit, Figma 등)의 기능·요금은 각 공식 사이트 기준입니다. 본문 표는 작성 시점의 계열 예시로만 인용했습니다.
인용 원칙 수업 요건(개념도 규칙, 보고서 항목, 발표 방식)은 수업 계획서 기준으로 서술했으며 확정본은 eclass 공지가 우선합니다. 1차 자료 확인이 어려운 서술은 "~로 알려져 있습니다"로 구분해 적었습니다.
이 자료는 단일 HTML 파일로 배포되며, 실습은 순수 JavaScript로 구현되어 오프라인에서도 동작합니다. 색상 규약: 청록색 = 서비스 흐름, 붉은색 = 돈 흐름, 회색 점선 = 다음 루프 후보.