Kiro로 시작하는 바이브코딩 &
Harness Engineering
코딩 없이 앱 만들기, 그리고 AI를 제대로 다루는 방법
"이런 아이디어, 못 만들어보셨나요?"
머릿속에 있는 '이런 게 있으면 편할 텐데'를 실제 앱으로 만드는 시간
여러분의 머릿속에는 분명히 있을 겁니다. '이런 게 있으면 업무가 훨씬 편해지는데'라는 아이디어가. 그런데 코딩을 모른다는 이유로, 개발자에게 부탁하기 애매하다는 이유로, 그냥 접어뒀을 겁니다.
이 강의가 끝나면 여러분은 두 가지를 얻어가십니다.
그 아이디어를 실제 동작하는 앱으로 만들 수 있습니다
Kiro와 바이브코딩으로 아이디어→요구사항→설계→코드까지 자동화
AI에 끌려다니지 않고 내가 제어하는 방법을 이해합니다
Harness Engineering — AI를 말처럼 내가 원하는 방향으로 다루는 사고 체계
바이브코딩이란?
코딩 능력이 아니라 전달 능력이 결과물의 질을 결정한다
바이브코딩은 새로운 프로그래밍 언어가 아닙니다. 쉽게 말하면, 요리사에게 레시피를 설명하는 것처럼 AI에게 "이런 앱을 만들어줘"라고 말하는 방식입니다. 요리사가 레시피를 정확히 이해할수록 요리 결과가 좋아지듯, AI에게 정확하게 전달할수록 앱의 품질이 높아집니다.
문제 → 개발자가 이해 → 코드 구현
코딩 능력이 병목
개발자가 없으면 멈춤. 코딩을 모르면 아이디어가 머릿속에서 죽음.
문제 → AI가 이해할 수 있게 전달 → AI가 코드 구현
전달 능력이 핵심
코딩을 몰라도 됨. 무엇을, 어떻게 설명하느냐가 결과물의 질을 결정.
왜 Kiro인가? (+ Claude Code)
소모임에서 Kiro를 주 도구로 선택한 이유
- Harness Engineering을 구조적으로 배우기에 최적인 도구 — 4단계(PRD→설계→태스크) 흐름이 내장되어 있어 올바른 습관을 자연스럽게 체득
- 무료 500 크레딧 제공 — 가입 즉시 바로 시작 가능
- 4단계 구조가 자동 가이드 — requirements.md → design.md → tasks.md 자동 생성
- 그대로 사용해도 동일 — Claude Code 보유자는 별도 가입 없이 진행
- 둘 다 Claude 모델 기반이라 워크플로우가 거의 같음
- 터미널 환경에서 더 빠르고, 파일 직접 제어 가능
Kiro의 4단계 방식
"한 번에 뚝딱"이 아니다 — 요리사에게 레시피를 단계별로 알려주는 것처럼
Kiro는 아이디어를 단번에 앱으로 바꾸지 않습니다. 4단계를 거치며 여러분이 매 단계를 검토하면서 함께 만들어갑니다. 쉽게 말하면, 건축가가 설계도를 단계별로 확인받으며 짓는 것과 같습니다.
프롬프트 — 만들고 싶은 것을 말로 설명
여러분이 직접 말로 설명합니다. "GS25 편의점 발주 자동화 시스템을 만들어줘. 최근 7일 판매 데이터를 보고 자동으로 발주량을 계산해줘." 이것만으로 충분합니다.
요구사항 — Kiro가 requirements.md 자동 생성
Kiro가 여러분의 설명을 구조화된 요구사항 문서로 만들어줍니다. "이게 맞나요?" 확인 후 다음 단계로.
설계 — 어떤 구조로 만들지 design.md 생성
어떤 기술로, 어떤 구조로 만들지 설계 문서가 자동으로 생성됩니다. 역시 여러분이 검토하고 승인합니다.
태스크 — 할 일을 쪼갠 tasks.md 체크리스트 → 코드 완성
Kiro가 "01번 먼저 할게요, 02번 할게요..." 하며 차례로 코드를 완성합니다. 여러분은 각 단계를 확인하기만 하면 됩니다.
| 단계 | 생성 파일 | 여러분의 역할 |
|---|---|---|
| 1단계 프롬프트 | 없음 (여러분이 작성) | 아이디어를 말로 설명 |
| 2단계 요구사항 | requirements.md | 내용 확인 및 수정 지시 |
| 3단계 설계 | design.md | 방향 검토 및 승인 |
| 4단계 태스크 | tasks.md + 코드 | 결과물 확인 및 피드백 |
개발 전에 먼저 탐색하라
Kiro를 열자마자 개발부터 시작하면 토큰(비용)만 낭비됩니다
집을 짓기 전에 먼저 어디에, 어떤 모습으로 지을지 도면을 그리듯, 코딩 도구를 열기 전에 먼저 아이디어를 검증하고 시각화해야 합니다.
올바른 순서 — 토큰을 아끼는 3단계 탐색법
채팅 AI로 탐색
Claude, Gemini 등으로 PRD(제품 요구사항) 초안 작성, User Flow 구체화, "이 아이디어가 실제로 문제를 해결하나?"고 비평 요청
Google Stitch로 시각화
PRD를 입력하면 와이어프레임/UI 컨셉 자동 생성. 만들려는 제품의 모습을 눈으로 확인. 수정 비용이 거의 0 (토큰 소비 없음)
Kiro / Claude Code로 개발
검증된 PRD + 와이어프레임을 들고 개발 시작. 방향이 확실해서 수정 횟수가 줄어듦
| 단계 | 도구 | 목적 | 토큰 비용 |
|---|---|---|---|
| 1단계 | Claude.ai / Gemini | 아이디어 검증, PRD 초안 | 낮음 |
| 2단계 | Google Stitch | UI 시각화, 와이어프레임 | 거의 0 |
| 3단계 | Kiro / Claude Code | 실제 코드 생성 | 높음 (하지만 낭비 없음) |
실습 예제 — GS25 발주 자동화
Kiro에게 단 한 줄로 시스템 설계를 시작한 실제 사례
프롬프트
여러분이 Kiro에게 이렇게 말했다고 가정합니다:
GS25 편의점 발주 자동화 시스템을 만들어줘. 최근 7일 판매 데이터를 보고 자동으로 발주량을 계산하고, 점주가 웹에서 승인할 수 있게 해줘.
Kiro가 설계한 시스템 구성
판매 분석 대시보드
Chart.js 기반 시각화. 7일간 판매량 추이를 그래프로 확인.
자동 발주량 계산
최근 7일 판매 기반으로 최적 발주량 자동 계산. 요일별 패턴 반영.
재고 현황 모니터링
재고 부족 시 빨간 알림 표시. 긴급 발주 필요 상품 한눈에 파악.
판매 시뮬레이터
가상 데이터로 테스트. 실제 데이터 없이도 시스템 동작 확인 가능.
Kiro가 만든 태스크 목록
Kiro는 위 시스템을 만들기 위해 5개 태스크를 자동으로 쪼개줍니다. 여러분은 "실행해줘"라고 하면 됩니다.
| 번호 | 태스크 | 구체적 내용 |
|---|---|---|
| 01 | 프로젝트 초기화 + DB | 폴더 구조, 테이블, 샘플 데이터 생성 |
| 02 | 서버 만들기 | API 엔드포인트 (Node.js Express) |
| 03 | 화면 만들기 | 웹 페이지 구성 (React) |
| 04 | 발주 계산 + 대시보드 | 자동 발주량 계산, Chart.js 차트 |
| 05 | 시뮬레이터 | 테스트용 가상 데이터 생성 |
실습 전 체크리스트 — Kiro 시작 전 확인사항
- 만들고 싶은 업무 아이디어 1개가 있다
- 그것이 누구의 어떤 문제를 해결하는지 말할 수 있다
- 너무 크다면, 더 작은 형태로 시작할 방법을 생각해봤다
- 관련 자료나 현재 쓰는 문서 예시가 있으면 준비했다
Harness Engineering이란?
AI에 끌려다니는 사람 vs AI를 제어하는 아키텍트
AI 도구를 쓸 때 두 가지 유형이 있습니다. 한 가지는 AI가 코드를 만들면 그냥 엔터를 누르는 사람. 다른 하나는 AI를 감독하고 방향을 잡는 사람. 결과물의 차이는 매우 큽니다.
- AI가 코드를 만들면 그냥 엔터 누름
- 결과물이 이상해도 왜 이상한지 모름
- AI에 끌려다님
- 점점 복잡해지는 코드를 제어할 수 없게 됨
- AI를 감독하고 업무를 지시하는 사람
- 결과물을 검토하고 방향을 잡음
- 수정 지시를 명확하게 내림
- AI가 강력해질수록 더 강해짐
Common Ground Truth
AI와 나 사이의 "공유된 정답 기준" — 문서가 없으면 AI와 대화할수록 서로 다른 곳을 보게 된다
AI에게 "로그인 기능 만들어줘"라고 했을 때 생기는 문제를 겪어보셨나요?
😰 공통된 기준이 없을 때
AI에게 '로그인 기능 만들어줘' → 내가 원하던 것과 다름 → 또 설명 → 반복...
이유? AI와 나 사이에 공유된 정답의 기준이 없기 때문입니다.
해결책: Common Ground Truth
AI와 내가 함께 보는 기준 문서를 만들면, AI와 대화할수록 더 정확해집니다.
무엇을, 왜, 누구를 위해 만드는가
- 제품의 목표
- 사용자 스토리
- 주요 기능 목록
- 제약 조건
데이터를 어떻게 주고받는가
- API 엔드포인트 목록
- 요청/응답 데이터 형식
- 인증 방식
- 에러 코드
다음 아이디어로 PRD(제품 요구사항 문서) 초안을 작성해줘. [아이디어] (여기에 만들고 싶은 것을 자유롭게 적어줘) 포함 사항: - 제품 목표 (왜 만드는가) - 주요 사용자 (누구를 위한 것인가) - 핵심 기능 5개 이내 - 데이터 흐름 (무엇을 입력받아 무엇을 출력하는가) - 제약 조건 (반드시 지켜야 할 것)
레이어 구조
어디에 얼마나 엄격하게 AI를 제어할지 — 층마다 다뤄야 합니다
모든 코드에 같은 방식으로 AI를 적용하면 안 됩니다. 건물로 비유하면, 외벽 페인트는 자주 바꿔도 되지만 기둥은 함부로 건드리면 안 됩니다. AI 활용도 마찬가지입니다.
UI — 자유도 높음
자주 변경, AI에게 자유롭게 수정 요청. "버튼 색을 바꿔줘", "레이아웃을 이렇게 고쳐줘" → 마음껏 시도
PRD / API 문서 — Common Ground Truth
기능 추가 시 함께 업데이트. 문서와 코드가 항상 일치해야 함. 임의로 바꾸면 AI가 길을 잃음
API — 엄격함
한번 잘 만들고 최대한 재사용. 신중하게 문서 기반으로만 변경. 함부로 바꾸면 시스템 전체가 깨질 수 있음
| 레이어 | AI 제어 방식 | 비유 |
|---|---|---|
| UI (1층) | 자유롭게 수정 요청, 빠른 실험 | 집 인테리어 — 언제든 바꿔도 됨 |
| PRD/API 문서 (2층) | 추가 시 동기화 필요 | 건축 설계도 — 변경 시 전체 영향 확인 |
| API (3층) | 신중하게, 문서 기반으로만 | 건물 기둥 — 함부로 건드리면 위험 |
Human in the Loop
AI가 알아서 다 하는 게 아니다 — 매 단계마다 사람이 방향을 잡아주는 체크포인트가 있다
Human in the Loop는 AI가 일하는 과정에 사람이 개입하는 체크포인트를 설계하는 것입니다. 쉽게 말하면, 자율주행 자동차를 타더라도 운전자가 경로를 설정하고 상황을 감독하는 것과 같습니다.
Kiro의 Human in the Loop 구조
PRD 작성 — AI가 초안 생성
Kiro가 여러분의 아이디어로 제품 요구 정의 초안을 작성합니다.
🧑 사람 검토 — 설계 방향 검증
여러분이 확인합니다. "이게 내가 원하는 건가?" 맞으면 다음 단계, 아니면 수정 지시.
API 문서 작성 — AI가 엔드포인트 설계
Kiro가 API 명세서(어떤 데이터를 어떻게 주고받을지)를 작성합니다.
🧑 사람 검토 — 문서 일치 확인
다시 여러분이 확인합니다. "이 API가 내가 원하는 기능을 지원하는가?" 확인 후 최종 개발.
AI가 쭉 달려서 코드를 완성했는데, 전혀 다른 것이 나옴. 처음부터 다시. 토큰도 시간도 낭비.
각 단계에서 방향을 확인. 조금씩 수정하며 진행. 최종 결과물이 정확히 내가 원하는 것.
핵심 정리 3가지
오늘 이 자리에서 반드시 가져가야 할 세 가지
바이브코딩은 코딩 능력이 아니라 전달 능력이다
AI에게 무엇을, 어떤 구조로 설명하느냐가 결과물의 질을 결정합니다. 코딩 경험보다 문제를 구조화하는 능력이 더 중요합니다.
개발 전에 먼저 탐색하라
Claude/Gemini → Stitch → Kiro/Claude Code 순서로. PRD와 와이어프레임을 먼저 확인하면 토큰이 절약되고 방향이 흔들리지 않습니다. 집 짓기 전에 도면부터 그리세요.
Harness Engineering = AI를 제어하는 사고 체계
Common Ground Truth(PRD + API 문서)가 중심이 되고, 레이어별로 다르게 제어하며, 매 단계 Human in the Loop로 방향을 잡아갑니다.
지금 시작하는 방법
오늘 이 자리가 그 출발점이 되길 바랍니다
심화 학습 리소스
| 리소스 | 내용 |
|---|---|
| Lovable (lovable.dev) | idea-to-product-maker. 아이디어를 입력하면 전체 앱을 만들어주는 도구 |
| 바이브 코딩 베스트 프랙티스 | 1코딩 바이브코딩 가이드 (Google Docs) |
| Claude — 바이브코딩 가이드 | AI와 협업하는 개발법. PRD와 API 문서 기반의 Common Ground Truth로 효율적인 개발 프로세스 |
바이브코딩 소모임 1기
3주에 걸쳐 직접 만들고, 검증하고, 자산으로 남기는 스터디 — 2026년 4월
왜 이 소모임을 시작했나
2월 바이브코딩 입문 교육 이후, 참석자들이 공통적으로 같은 벽에 부딪히고 있었습니다.
수정할 때마다 처음부터
맥락이 없으면 수정할 때마다 AI에게 처음부터 다시 설명해야 하는 상황.
원하는 결과가 안 나와
프롬프트를 계속 고치다 포기. 왜 안 나오는지 알 수 없음.
토큰 소진, 맥락 단절
대화가 길어지면 토큰이 소진되어 AI가 앞 내용을 기억하지 못함.
3주 커리큘럼 설계 의도
단순히 주차별 수업이 아닙니다. 각 주차에는 명확한 체득 목표가 있습니다.
의도: PRD를 명확히 쓰면 어떤 툴에 넣어도 결과가 비슷하게 나온다는 것을 직접 비교해서 체감
활동: 각자 가져온 업무/상황 소개 → 첫 시안 만들기 → 잘 된 점/막힌 점 공유
의도: 사람이 일일이 확인하는 게 아니라 AI가 스스로 검증하고 사람은 결과만 확인하는 구조(Human in the Loop) 경험
활동: 실제 써본 후기 공유 → 피드백 반영해서 수정
의도: 나만 아는 결과물이 아니라 PRD + 맥락 문서로 다른 사람도 이어받을 수 있는 자산을 만드는 것까지가 완성
활동: 최종 결과와 적용 경험 공유 → 꿀팁 모아보기
핵심 설계 원칙
| 원칙 | 구체적 설계 |
|---|---|
| 강제 없이, 과정 중심 | 업무 시간 외 자율 참여. 완성도보다 시도 자체에 의미. |
| 작은 프로덕트 완성 | 거창한 시스템이 아닌, 내 업무의 불편함을 해소하는 작은 것 하나를 끝까지. |
| 꿀팁 공동 수집 | 개인의 삽질이 팀의 자산. 잘 된/안 된 프롬프트를 함께 기록하고 대시보드로 공유. |
| 전파를 전제로 설계 | 소모임 멤버가 다음 전파자가 되는 구조. 처음부터 타운홀 공유를 목표로. |
궁극적으로 만들고 싶었던 사람
PRD로 재현 가능한 결과를 만든다
문서가 있으면 누구에게 맡겨도 같은 결과가 나온다.
AI에게 검증을 맡기고 결과만 확인한다
Human in the Loop로 효율적으로 품질을 관리한다.
혼자 아는 것이 아니라 자산으로 공유한다
PRD + 맥락 문서로 팀 전체가 이어받을 수 있게.
1주차 전까지 생각해오실 것
- 한번 만들어보고 싶은 업무/상황 1개
- 그걸 누구에게, 언제쯤 써볼 수 있을지
- 너무 크다면 더 작게 시작할 수 있는 형태가 무엇일지
- 가능하면 관련 자료나 현재 쓰고 있는 문서, 예시 화면
용어가 어렵다면? 클릭해서 쉬운 설명 보기
| 용어 | 쉬운 설명 |
|---|---|
| Kiro | Amazon이 만든 AI 코딩 도구. 아이디어→요구사항→설계→코드를 단계별로 자동화. |
| Claude Code | Anthropic이 만든 터미널 기반 AI 코딩 도구. Kiro와 같은 Claude 모델 사용. |
| PRD | Product Requirements Document. 제품 요구사항 문서. 무엇을, 왜, 누구를 위해 만드는지 적는 기획서. |
| Common Ground Truth | AI와 내가 공동으로 보는 기준 문서. PRD.md + API.md가 이 역할. |
| Harness Engineering | 말의 마구처럼 AI를 내가 원하는 방향으로 제어하는 방법론. AI를 따르는 게 아니라 AI를 지휘하는 것. |
| Human in the Loop | AI가 일하는 과정에 사람이 체크포인트를 두는 구조. "AI가 만든 거 맞아?"를 매 단계 확인. |
| 레이어 구조 | UI / PRD·API 문서 / API 이렇게 3층으로 나눠 각각 다른 방식으로 AI를 제어하는 아키텍처. |
| Google Stitch | 텍스트 설명을 받아 UI 와이어프레임을 자동 생성하는 도구. 코딩 없이 화면 미리보기 가능. |
| 와이어프레임 | 화면 구조 스케치. 인테리어하기 전에 그리는 도면과 같음. |
| 토큰 | AI가 처리하는 텍스트의 단위. 대화가 길어질수록 소비되며, 소진되면 AI가 앞 내용을 기억하지 못함. |