점심 메뉴 추천 앱 만들기

Kiro IDE의 핵심 기능을 한 번에 체험하는 hands-on 워크숍입니다. 처음부터 끝까지 Vibe 모드에서 자연어 대화만으로 진행하며, 모든 프롬프트는 그대로 복사해 채팅창에 붙여 넣으면 동작합니다. 흐름만 따라가면 점심 메뉴를 추천해 주는 웹사이트가 한 개 완성됩니다.

준비물

• Kiro IDE 최신 버전 (다운로드 및 설치 페이지 참고)
• Node.js 20 이상 — 없으면 모듈 0의 프롬프트로 Kiro에게 설치를 맡길 수 있습니다
• 빈 디렉터리 하나 (어느 OS든 홈 아래에 만드는 것을 권장). 예시 — macOS/Linux: ~/projects/lunch-pick, Windows PowerShell: $HOME\projects\lunch-pick, Windows cmd: %USERPROFILE%\projects\lunch-pick
• 인터넷 연결 (Playwright MCP 패키지와 Chromium 바이너리를 모듈 7에서 자동 다운로드합니다 — API 키 발급·계정 생성 불필요)

학습 목표

1. Vibe 모드의 자연어 대화만으로 프로젝트를 처음부터 끝까지 만든다
2. Steering으로 프로젝트 규칙을 등록해 일관된 코드를 받는다
3. Agent Hooks로 저장 시 자동 검증·문서 갱신을 트리거한다
4. MCP로 공식 Playwright 서버를 등록해 Kiro 가 직접 브라우저를 조작·캡처하도록 만든다
5. agent 를 만들어 코드 리뷰 같은 보조 작업을 분리한다
6. Skill 로 자주 쓰는 작업을 패키지화한다

워크숍 흐름 한눈에

모듈 0 — Steering으로 프로젝트 규칙 등록하기

1. Kiro IDE 를 실행하고 File → Open Folder…로 빈 폴더 lunch-pick 을 엽니다.
2. 좌측 채팅 패널을 열고 모드를 Vibe 로 둡니다. 워크숍 처음부터 끝까지 모드 변경 없이 Vibe 만 사용합니다.
3. 아래 한 프롬프트로 프로젝트 메타 정보·기술 스택·언어 규칙·작업 방식까지 한 번에 Steering 으로 등록합니다. Command Palette 를 따로 열거나 별도 대화 세션을 시작하지 말고, 지금 이 채팅에서 바로 파일을 만드는 식으로 진행합니다.

이번 세션에서 만들 프로젝트는 "Lunch Pick" 이라는 정적 웹앱입니다. 사용자가 기분, 예산, 동행 인원, 매운맛 강도를 입력하면 후보 메뉴 목록을 점수화해 상위 1~3개를 추천하는 사이트를 만듭니다. 기술 스택은 Vite + React + TypeScript + Tailwind CSS 이고, 빌드 결과물은 로컬에서 실행해 보는 용도입니다(배포는 다루지 않습니다). 워크숍 진행은 처음부터 끝까지 Vibe 모드만 사용하며, Spec 모드 전환이나 Spec 객체 생성은 하지 않습니다.

이제 이 워크스페이스에 아래 다섯 개의 Steering 파일을 직접 생성·작성해 주세요.
별도 대화 세션이나 Command Palette 명령(Kiro: Generate project steering documents 등)을 호출하지 말고,
지금 이 대화에서 곧바로 파일을 만드는 식으로 진행합니다.

생성할 파일:
- ./.kiro/steering/product.md
- ./.kiro/steering/structure.md
- ./.kiro/steering/tech.md
- ./.kiro/steering/language.md
- ./.kiro/steering/workspace.md

모든 파일의 frontmatter 에 inclusion: always 를 두어 항상 컨텍스트에 포함되게 합니다.

product.md:
- 한 문장 요약: "사용자의 기분·예산·인원·매운맛 강도에 맞춰 점심 후보를 점수화해 추천하는 정적 웹앱"
- 핵심 사용자 시나리오 3개 (예: 회의 직후 가벼운 한 끼, 비 오는 날 따뜻한 국물, 팀 회식 후보 고르기)
- 비목표(Non-goals): 결제, 매장 예약, 사용자 계정, 다국어. 모두 v1에서 제외.

structure.md:
- 디렉터리 트리 (src/components, src/data, src/lib, src/pages 정도로 단순하게)
- 데이터 위치: 메뉴 목록은 src/data/menus.json (씨드 데이터)
- 라우팅: 단일 페이지 SPA. 라우터 도입 금지.

tech.md:
- 빌드: Vite, 언어: TypeScript strict, UI: React 18 함수 컴포넌트, 스타일: Tailwind CSS
- 상태: useState/useReducer로 충분. Redux/Zustand 등 도입 금지.
- 테스트: Vitest + @testing-library/react
- 코드 스타일: 함수 컴포넌트, 화살표 함수, named export 우선. any 금지.
- 접근성: 입력에 label 필수, 키보드 네비게이션 가능해야 함.

language.md (새 Steering 파일 — 이후 모든 응답·산출물의 언어 규칙을 강제):
- 모든 모델 응답, 채팅 메시지, 그리고 생성·수정되는 결과물(코드 주석, 커밋 메시지, 문서, 테스트 설명, 에러 메시지 문구 등)은 가능한 한 한국어로 작성한다.
- 코드 식별자·라이브러리 이름·CLI 명령은 영어 원형 그대로 유지한다.
- 단, 사용자가 영어로 질문하거나 명시적으로 영어를 요구한 경우에는 그 요청을 우선한다.
- 이 규칙은 Steering 으로 항상 적용되며, 별도 지시 없이도 새 파일·새 메시지의 기본 언어가 한국어가 되어야 한다.

workspace.md (새 Steering 파일 — 이후 모든 모듈의 작업 방식을 강제):
- 워크스페이스 로컬 산출물 우선. Steering / Hooks / Skills / agents / MCP 설정 같은 Kiro 관련 산출물은 항상 현재 워크스페이스 안의 .kiro/ 트리에만 만들고, 사용자 홈 디렉터리의 글로벌 .kiro/ 에는 손대지 않는다. 정확한 디렉터리 경로 표기는 OS·셸에 따라 달라질 수 있으므로 상황에 맞게 Kiro 가 결정해 보고한다.
- 권한이 필요한 명령(sudo, 관리자 PowerShell, UAC 등)은 Kiro 가 임의로 실행하지 않는다. 명령 문자열만 보여 주고 사용자가 직접 실행하도록 안내한다.
- 셸 호환성. 명령을 실행할 때는 현재 OS 와 셸(macOS/Linux 의 zsh·bash, Windows 의 PowerShell·cmd) 을 먼저 확인하고, 그 환경에서 검증된 형태로 호출한다. 특정 셸에서만 동작하는 명령을 사용자에게 떠넘기지 않는다.
- 단계별 보고. 어떤 명령을 어떤 셸·디렉터리에서 실행했고, 어떤 결과·에러가 나왔는지 한국어로 짧게 보고한다. 막힌 단계가 있으면 어디서 막혔는지 정확히 알린다.
- 추측 금지·최소 변경. 한 단계가 끝나기 전에 다음 단계를 추측해 미리 반영하지 않는다. 큰 리팩터를 제안하기 전에 먼저 "최소 변경" 안을 검토한다. 코드 변경은 사용자가 적용을 승인할 수 있도록 가능한 한 작은 단위로 제시한다.
- 파일 삭제 금지. 사용자가 명시적으로 요청하지 않는 한 어떤 파일·디렉터리도 삭제하지 않는다.

작성이 끝나면 다섯 파일의 경로를 한 줄씩 보고하고 다음 단계 지시를 기다려 주세요.

모듈 1 — Node.js 준비

뒤에서 npm·vite·vitest 같은 도구를 쓰려면 Node.js 20 이상이 필요합니다. 이미 설치돼 있다면 Kiro 가 한 줄로 확인만 해 주고 넘어가고, 없다면 OS 에 맞는 방법으로 설치까지 안내합니다.

현재 머신에 Node.js 가 설치돼 있는지 확인하고, 없으면 설치까지 진행해 주세요.

진행 방식:
1) 터미널에서 "node --version" 과 "npm --version" 을 실행해 결과를 확인.
2) 두 명령 모두 성공하고 Node 버전이 v20 이상이면 "Node.js 준비 완료 (vXX.YY.ZZ)" 한 줄만 보고하고 종료.
3) 명령이 실패하거나 Node 버전이 v20 미만이면, 현재 OS(Windows / macOS / Linux) 를 자동 판별해 다음 중 가장 적합한 방법을 골라 안내·실행해 주세요.
   - macOS: Homebrew 가 있으면 "brew install node@20", 없으면 https://nodejs.org/ LTS 인스톨러 다운로드 안내
   - Windows: winget 가능 시 "winget install OpenJS.NodeJS.LTS", 아니면 https://nodejs.org/ 인스톨러 안내
   - Linux: 사용자의 패키지 매니저(apt/dnf/pacman 등) 감지해 NodeSource 또는 nvm 설치 가이드 제시
4) 설치 후 새 셸을 열어야 PATH 가 갱신되는 환경이면 그 사실도 안내해 주세요.

모듈 2 — 프로젝트 골격과 데이터 시드

이제 본격적으로 코드를 만듭니다. Vibe 모드에서 자연어로 골격 → 데이터 → 타입을 순차적으로 부탁합니다. 한 프롬프트로 "전체 다 만들어 달라"고 하지 말고, 결과를 확인하며 한 단계씩 진행하세요.

2-1. Vite + 기본 의존성

현재 빈 폴더에 Vite + React + TypeScript 프로젝트를 부트스트랩해 주세요.
다음을 모두 충족해야 합니다.

- npm create vite@latest 가 아닌, 필요한 파일을 직접 작성하는 방식으로 만들어 주세요
  (package.json, vite.config.ts, tsconfig.json, index.html, src/main.tsx, src/App.tsx)
- Tailwind CSS 설정 (tailwind.config.js, postcss.config.js, src/index.css에 @tailwind 지시문)
- 테스트는 Vitest + @testing-library/react. vitest.config.ts와 jsdom 환경 설정.
- "type": "module", "scripts": { dev, build, preview, test }
- TypeScript strict 모드, noUncheckedIndexedAccess 켜기

마지막에 다음을 직접 실행해 주세요. 사용자가 별도 터미널을 띄울 필요가 없도록 Kiro 가 모두 처리합니다.

1) npm install 으로 의존성을 모두 설치한다.
2) 백그라운드(혹은 별도 터미널 세션)에서 npm run dev 를 실행해 Vite 개발 서버를 띄운다. 콘솔에 출력된 로컬 URL(보통 http://localhost:5173 )을 확인해 채팅에 알려 준다.
3) 그 URL 을 사용자의 기본 브라우저로 자동으로 연다 (macOS: open , Linux: xdg-open , Windows: start ). OS 를 감지해 적절한 명령을 사용.
4) 페이지가 떴는지 시각적으로 확인해 "Lunch Pick" 헤더와 placeholder 한 줄이 보이는지 보고한다. 화면 캡처가 가능하면 첨부, 불가능하면 어떤 요소가 보이는지 텍스트로 묘사.

서버 프로세스는 죽이지 말고 계속 실행 상태로 유지해 주세요. 다음 모듈에서도 같은 dev 서버를 그대로 사용합니다.

2-2. 메뉴 데이터 시드

src/data/menus.json 을 작성해 주세요. 다음 스키마로 20개 이상 메뉴를 채웁니다.

{
  "id": "kebab-case 고유 id",
  "name": "메뉴 이름",
  "cuisine": "korean | japanese | chinese | western | asian | etc",
  "moods": ["hearty", "light", "spicy", "healthy", "special"] 중 1~3개,
  "spice": 0~3,
  "pricePerPerson": 원 단위 정수,
  "minGroupSize": 1, "maxGroupSize": 10,
  "tags": ["국물", "면", "면+밥", "혼밥OK" 등 3개 이내],
  "shortDesc": "한 줄 설명 (40자 내)"
}

한국에서 흔히 먹는 점심을 골고루 포함해 주세요 (백반·국밥·라멘·짜장·파스타·샐러드 등).
가격은 점심 평균에 맞게 7000~25000원 범위에서 현실적으로.
파일 끝에 trailing newline 한 줄 포함, 들여쓰기는 2칸.

모듈 3 — 점수 로직과 단위 테스트

핵심 도메인 타입과 점수 함수를 작성해 주세요. 다음 두 파일을 함께 만듭니다.

src/lib/types.ts:
- Mood = "hearty" | "light" | "spicy" | "healthy" | "special"
- Cuisine = "korean" | "japanese" | "chinese" | "western" | "asian" | "etc"
- Budget = "under-10k" | "10k-15k" | "15k-25k" | "over-25k"
- UserPrefs { mood: Mood; budget: Budget; group: number; spice: 0|1|2|3 }
- Menu { id; name; cuisine; moods: Mood[]; spice; pricePerPerson; minGroupSize; maxGroupSize; tags: string[]; shortDesc }
- ScoredMenu { menu: Menu; score: number; breakdown: { mood; budget; spice; group } }

src/lib/score.ts:
- export const scoreMenu = (menu: Menu, prefs: UserPrefs): ScoredMenu
- 가중치: mood 40, budget 30, spice 20, group 10 (총 100)
- mood: prefs.mood 가 menu.moods 에 포함되면 40, 아니면 0
- budget: prefs.budget 구간(상한/하한 표 코드 안에 정의)과 menu.pricePerPerson 비교 →
  적합 30 / 한 단계 차이 15 / 두 단계 이상 0
- spice: |prefs.spice - menu.spice| 가 0~1 → 20, 2 → 10, 3 → 0
- group: minGroupSize ≤ prefs.group ≤ maxGroupSize → 10, 아니면 0
- 동률 셔플은 score 함수 외부에서 처리 (여기선 결정적이어야 함)

그리고 src/lib/score.test.ts에 vitest 단위 테스트를 작성해 주세요.
- 모든 항목이 일치하는 메뉴는 100점
- mood 만 불일치할 때 60점
- budget 이 한 단계 어긋나면 85점
- 그룹 크기 범위 벗어나면 group 점수 0
- 매운맛 차이 3 이상은 spice 점수 0

마지막에 npm run test 실행해서 5/5 통과 확인까지 해 주세요.

모듈 4 — UI 결합과 localStorage 복원

UI 컴포넌트와 상태를 차례로 만듭니다. 한 단계가 끝날 때마다 npm run dev로 화면을 직접 확인하세요.

4-1. InputForm 만들기

src/components/InputForm.tsx 를 만들어 주세요.

- prefs 상태는 useReducer 로 관리. 초기값은 mood="hearty", budget="10k-15k", group=1, spice=1.
- 4개 입력:
  1) mood: 5개 ToggleButton (든든하게/가볍게/매콤하게/건강하게/특별하게)
  2) budget: 4개 ToggleButton (~1만, 1~1.5만, 1.5~2.5만, 2.5만+)
  3) group: number input 1~10
  4) spice: 0~3 라디오 (0=안매움, 3=아주매움)
- 모든 입력에 label 명시, 키보드 Tab 순서가 자연스럽도록 구성
- props: onSubmit(prefs: UserPrefs) => void, 폼 하단에 "추천 받기" 버튼
- Tailwind 로 다크 카드 스타일 (bg-zinc-900, rounded-xl, p-6)

src/components/InputForm.test.tsx 도 같이:
- 초기 렌더 시 "추천 받기" 버튼이 보이는지
- mood 토글을 클릭한 뒤 "추천 받기"를 누르면 onSubmit 이 갱신된 prefs로 호출되는지

App.tsx 에서 InputForm 을 임시로 렌더하고 onSubmit 결과를 console.log 해서 동작 확인.

4-2. 결과 패널과 카드

다음 두 컴포넌트를 만들어 주세요.

src/components/MenuCard.tsx:
- props: { scored: ScoredMenu; rank: number }
- 메뉴명(h3, 강조), shortDesc, 1인 가격, tags(작은 칩 3개), 점수 분해(작은 회색 텍스트 한 줄)
- rank === 1 일 때만 보라 그라디언트 테두리(border-2 + accent ring) 적용

src/components/ResultPanel.tsx:
- props: { prefs: UserPrefs | null; menus: Menu[] }
- prefs 가 null 이면 안내 문구만 ("기분과 예산을 골라 주세요")
- prefs 가 있으면 모든 menus 를 scoreMenu 로 점수화 → 점수 내림차순 정렬 → 상위 3개 → MenuCard rank 1~3 으로 렌더
- 동률은 안정적으로 셔플하기 위해 별도의 shuffleSeed 상태(부모에서 전달)를 받아 동률 그룹을 그 시드로만 셔플
- 결과 영역 위에 "다시 추천" 버튼: 클릭하면 부모에 새 shuffleSeed 알리기

App.tsx 에서 둘을 결합:
- 좌측 InputForm, 우측 ResultPanel (모바일에서는 세로 스택)
- import menus from "../data/menus.json" 으로 시드 데이터 사용
- onSubmit 으로 prefs 저장, "다시 추천" 버튼이 shuffleSeed(Date.now())를 갱신

4-3. localStorage 복원

src/lib/usePrefs.ts 라는 커스텀 훅을 만들어 주세요.

- export const usePrefs = (): [UserPrefs | null, (p: UserPrefs) => void]
- 마운트 시 localStorage.getItem("lunch-prefs") 로 읽어 초기값 세팅(JSON.parse 실패는 null)
- setter 호출 시 localStorage 에 저장
- SSR 호환은 신경쓰지 않아도 됨 (이 앱은 CSR 전용)

App.tsx 의 prefs state 를 이 훅으로 교체하고,
새로고침 후에도 마지막 입력이 유지되는지 직접 확인해 주세요.
간단한 통합 테스트 파일 (src/lib/usePrefs.test.ts) 도 함께 작성:
- 처음에는 null
- setPrefs 호출 후 다시 훅을 호출하면 그 값이 그대로 나오는지

모듈 5 — Hooks로 저장 시 자동 검증

Hooks를 쓰면 파일 저장·커밋 같은 이벤트에 자동 작업을 묶을 수 있습니다. 여기서는 menus.json이 바뀔 때마다 검증과 통계 갱신을 자동으로 돌리는 Hook을 만듭니다.

"validate-menus" 라는 이름의 Agent Hook 을 만들어 주세요. 저장 위치는 워크스페이스 규칙(workspace.md) 에 따라 적절한 .kiro/ 하위 디렉터리를 Kiro 가 결정해 주세요.

트리거: src/data/menus.json 저장 시
액션:
1) JSON 스키마 검증 — id 중복, 필수 필드 누락, pricePerPerson이 정수가 아닌 경우 등을 잡는다
2) 통계 요약을 src/data/menus.summary.md 에 갱신
   - 총 메뉴 수, cuisine 별 분포, 평균 가격, mood 별 카운트
3) 문제가 있으면 채팅으로 한국어 보고, 문제 없으면 "menus 검증 OK (N개)"만 출력

Hook은 백그라운드로 동작해야 하고, 사용자에게 매번 확인을 받지 않아도 되게
auto-approve를 켜 주세요. 단, 파일 삭제는 절대 하지 않습니다.

Hook이 만들어지면 menus.json에 일부러 잘못된 데이터(예: 중복 id 하나)를 넣어 저장해 봅니다. 채팅 패널에 한국어 경고가 떠야 정상입니다.

모듈 6 — Skill로 Hook 동작 확인

Skill 은 SKILL.md 와 보조 파일을 묶은 폴더로, 사용자의 요청이 Skill 의 description 과 매칭되거나 채팅에서 슬래시 메뉴로 직접 고를 때 활성화됩니다. 이 모듈에서는 add-menu Skill 하나를 만들어, 모듈 6 에서 등록한 validate-menus Hook 이 실제로 트리거되는지 눈으로 확인합니다.

현재 워크스페이스에 add-menu 라는 Skill 을 하나 만들어 주세요. 저장 위치는 workspace.md Steering 에 따라 Kiro 가 적절한 .kiro/ 하위 경로를 결정합니다.

폴더 구성:
- SKILL.md  (필수)

SKILL.md 의 frontmatter 와 본문은 다음 내용을 따릅니다.

frontmatter:
- name: add-menu
- description: 새 메뉴 1~5개를 src/data/menus.json 에 추가합니다. 사용자가 "라멘 두 개 추가" 같은 자연어로 메뉴를 등록하려 할 때 사용하세요.

본문에 담을 절차:
1) 사용자의 자연어 요청에서 메뉴 이름·개수·매운맛 정도 등의 단서를 추출한다.
2) 각 메뉴에 대해 cuisine, moods, spice, pricePerPerson, minGroupSize, maxGroupSize, tags, shortDesc 를 추론한다. id 는 kebab-case 로 만들고 menus.json 에 이미 존재하는 id 와 충돌하지 않도록 suffix 를 붙인다.
3) menus.json 스키마(모듈 3-2 에서 정의한 형태) 와 일치하는지 확인하고, 파일 끝의 trailing newline·들여쓰기 2칸 규칙을 유지하며 항목을 append 한다.
4) 저장 후에는 모듈 6 에서 만든 validate-menus Hook 이 자동으로 트리거되어 menus.summary.md 가 갱신되어야 한다는 점을 명시.
5) 어떤 파일도 삭제하지 않고, menus.json 외의 코드는 수정하지 않는다.

작성이 끝나면 채팅에서 "add-menu 로 마라탕 한 개 추가해 줘" 라고 자연어로 요청해 Skill 이 활성화되도록 한 뒤, 다음 두 가지를 한국어로 보고해 주세요.
- (a) menus.json 의 마지막에 마라탕 항목이 정상적으로 append 되었는지 (추가된 항목의 핵심 필드를 인용)
- (b) validate-menus Hook 이 자동으로 돌아 menus.summary.md 의 총 메뉴 수·cuisine 분포·평균 가격이 갱신됐는지 (변경된 라인을 diff 형태로 인용)

기대와 다른 부분이 있으면 어디서 어긋났는지 정확히 알려 주세요.

모듈 7 — MCP로 Playwright 연결

MCP 서버를 연결하면 외부 도구를 Kiro 채팅에서 직접 호출할 수 있습니다. 이 워크숍에서는 Microsoft 가 공식 배포하는 Playwright MCP(@playwright/mcp)를 붙여, Kiro 가 직접 브라우저를 띄우고 점심 추천 앱의 폼을 채워 추천 결과 화면을 캡처하도록 만듭니다.

7-1. Playwright MCP 등록 및 설치

다음 한 프롬프트로 Kiro 가 패키지 설치(필요 시 브라우저 바이너리 다운로드까지)와 mcp.json 등록을 모두 처리합니다.

현재 워크스페이스에 Microsoft 공식 Playwright MCP 서버(@playwright/mcp) 를 등록·실행 가능하도록 준비해 주세요. (workspace.md Steering 의 워크스페이스 로컬·셸 호환성·sudo 정책을 따릅니다.)

진행 방식:
1) 패키지 준비. @playwright/mcp 패키지를 현재 환경에서 가장 안정적으로 실행할 수 있는 방법으로 검증해 주세요. 어떤 명령으로 검증했고 어떤 결과가 나왔는지 짧게 보고.
2) 브라우저 바이너리. @playwright/mcp 가 처음 호출될 때 Chromium 다운로드가 필요하면 같은 환경에서 적절한 Playwright 설치 명령으로 미리 받아 두세요.
3) MCP 등록 파일 작성. mcp.json 의 mcpServers 객체에 "playwright" 항목을 추가합니다(이미 다른 서버가 있으면 병합).
   - command·args 는 1) 단계에서 실제로 검증한 호출 방식을 그대로 사용합니다. 셸 의존 없이 동작하는 형태로 채워 주세요. 필요하면 절대 경로 실행 파일을 쓰거나, "command": "" / "args": [...] 형태로 분리합니다.
   - "disabled": false 를 명시하고, autoApprove 에는 첫 tools/list 응답에서 노출되는 도구 중 navigate / snapshot / click / type / screenshot / wait 계열의 안전한 것들만 허용 목록에 넣어 주세요. (실제 도구 이름은 패키지 버전에 따라 다를 수 있으므로 추측하지 말고 응답을 보고 정한다.)
4) Kiro 의 MCP 서버를 다시 로드한 뒤, playwright 서버의 도구 목록을 한국어로 요약해 채팅에 보여 주세요.
5) 마지막으로 한 번 스모크 테스트: 도구를 사용해 https://example.com 으로 이동 → 페이지 스냅샷 또는 스크린샷을 받아 "정상 등록 완료" 라고 한국어로 보고.

7-2. Playwright 로 점심 추천 앱 시각 검증

방금 등록한 playwright MCP 의 도구를 사용해 모듈 3 에서 띄워 둔 Vite dev 서버(보통 http://localhost:5173) 의 점심 추천 앱을 직접 조작해 주세요.

시나리오:
1) browser_navigate 로 dev 서버 URL 을 연다.
2) browser_snapshot 으로 현재 화면 구조를 받아 InputForm 의 라벨·버튼이 의도대로 렌더되는지 확인.
3) "기분=매콤하게, 예산=10k-15k, 인원=2, 매운맛=2" 가 되도록 폼 위젯을 클릭·입력한다 (browser_click, browser_type 또는 그에 상응하는 도구 사용).
4) "추천 받기" 버튼을 클릭하고, ResultPanel 에 메뉴 카드 3장이 렌더될 때까지 짧게 기다린다.
5) browser_take_screenshot 으로 결과 화면을 캡처해 채팅에 첨부한다.
6) 동일한 시나리오를 한 번 더 돌리되 "다시 추천" 버튼을 한 번 더 눌러 결과가 동률 셔플로 달라지는지 확인하고 두 번째 캡처도 첨부한다.
7) 화면에 보이는 상위 3개 메뉴 이름과 점수를 한국어로 요약해 보고하고, scoreMenu 가중치 정의에 비추어 결과가 합리적인지 한 줄 코멘트.

조건:
- dev 서버가 살아 있는지 먼저 체크. 죽어 있으면 npm run dev 를 다시 띄운 뒤 진행.
- 브라우저 창은 헤드리스 기본값을 사용. 사용자가 별도 모니터에 띄워 보고 싶다고 하지 않는 한 시각 자동화는 백그라운드에서.
- 캡처 파일은 ./.kiro/screenshots/ 아래에 저장하고 .gitignore 에 해당 경로를 추가해 두세요. (이미 무시되고 있다면 생략)
- 시나리오 실행 중 발생하는 모든 보고는 한국어로, UI 라벨·코드 식별자는 영어 원형 그대로.

모듈 8 — agent 생성 및 실습

agent 는 메인 채팅과 분리된 컨텍스트에서 정해진 역할을 수행하는 보조 에이전트입니다. 여기서는 코드 리뷰 전용 agent 한 개를 만들고, 직접 호출해 결과를 확인합니다.

현재 워크스페이스에 code-reviewer 라는 agent 를 추가해 주세요.

정의에 포함할 내용:
- name: code-reviewer
- description: lunch-recommender 프로젝트의 TypeScript·React 코드를 리뷰하는 agent. 타입 안전성, 불필요한 useEffect, 직접적인 DOM 접근, key 누락, 접근성 라벨 누락 같은 항목을 우선 점검한다.
- 동작 가이드: 한 번에 한 파일만 깊이 있게 검토한다. 발견한 문제는 (a) 위치(파일·줄), (b) 무엇이 문제인지, (c) 어떻게 고치면 좋은지 세 줄로 정리해 보고한다. 코드를 직접 수정하지는 않고 사용자가 적용 여부를 결정할 수 있도록 제안만 한다.

작성이 끝나면 다음 두 가지를 수행해 주세요.
1) 방금 만든 code-reviewer agent 를 호출해 src/lib/score.ts 한 파일에 대한 리뷰를 받는다.
2) 같은 agent 를 한 번 더 호출해 src/components/InputForm.tsx 에 대한 리뷰를 받는다.

두 리뷰의 결과를 한국어로 정리해 채팅에 요약하고, 그중 사용자가 직접 적용해 보고 싶은 항목이 있는지 물어봐 주세요.

다음 도전 과제

여기부터는 정해진 정답이 없습니다. 본인이 가장 궁금했던 Kiro 기능, 또는 점심 추천 앱에 가장 적합해 보이는 아이디어를 하나 골라 자유롭게 확장해 보세요. 모두 Vibe 모드에서 자연어 한 두 프롬프트로 시작할 수 있습니다.

제품·UX 확장

• "오늘 못 먹는 음식이 있어" 입력 칸을 추가해 알레르기·비건·할랄 등 제외 조건을 점수 계산에 반영
• 최근 추천 받은 메뉴를 5개까지 기억해 "최근 추천에서는 빼 줘" 토글로 다양성 보장
• 점심·저녁 모드 토글을 만들어 가격대·메뉴 풀이 시간대별로 달라지도록
• 추천 결과를 카카오톡·슬랙으로 공유할 수 있는 "이 조합 공유" 버튼과 OG 이미지 자동 생성
• 지도 미리보기 — 결과 카드에 "근처에서 찾기" 링크를 붙여 검색 엔진 길찾기로 한 번에 이동

도메인 모델 확장

• menus.json 을 20개 → 100개 이상으로 늘리고, 본인 동네에서 자주 가는 메뉴로 시드를 직접 채우기
• 가중치(mood 40 / budget 30 / spice 20 / group 10) 를 사용자가 조절할 수 있는 "고급 설정" 패널 추가
• 같은 메뉴라도 "혼밥 / 2인 / 회식" 시점에 따라 별도 가격·태그를 가지도록 데이터 모델 확장
• 맛 그래프(매운맛 × 든든함) 를 2D scatter 로 보여 주는 시각화 추가

Kiro 기능 심화 활용

• Steering 에 회사·팀의 실제 코드 컨벤션을 옮겨 와 다른 프로젝트에서도 재사용해 보기
• Hook 을 한 개 더 만들어 "src/lib/score.ts 가 바뀌면 score.test.ts 도 같이 갱신해 주세요" 같은 자동 동기화 흐름 구성
• Skill 을 폴더 단위로 여러 개 만들어 보고, description 만 보고 어떤 Skill 이 활성화되는지 직접 실험
• agent 정의를 다듬어 본인이 평소에 받고 싶은 코드 리뷰 페르소나(보안·성능·DX 등) 를 분리

MCP 로 추가 정보 연결

• Playwright MCP 로 결과 화면을 매 빌드마다 자동 캡처해 README 에 붙이는 셀프 도큐멘팅 흐름
• 로컬 SQLite MCP 를 붙여 "내가 이번 달에 점심으로 먹은 메뉴" 통계를 추천 가중치로 연결
• 좋아하는 공개 API(공휴일·환율·캘린더 등) 를 MCP 로 만들어 추천 로직에 반영해 보기
• 본인 회사의 사내 도구(예: Jira, Notion) 와 연결되는 MCP 가 이미 있다면 워크숍 결과물에 붙여 새 메뉴 자동 등록 흐름 만들기

가벼운 실험

• 로딩 상태·에러 화면을 한 단계 더 다듬어 본인 취향의 톤으로 카피 다시 쓰기
• 다크/라이트 테마 토글 추가 후 prefers-color-scheme 기본값 처리
• "왜 이 메뉴를 추천했나" 펼침 패널을 만들어 점수 분해를 보여 주기
• 키보드만으로 모든 입력·선택·다시 추천이 가능한지 직접 Tab 으로 한 번 점검