MVP에 대한 사용자들의 피드백들과 스터디장님의 피드백들을 수집했습니다.
많은 피드백들이 있었고, 제가 생각해도 별로인 기능과 서비스들이 있어서
열심히 반 영해서 개선시켜야 하겠다라고 생각을 해서 추가 작업을 진행해봤습니다.
우선 피드백들과 개선의견들을 모두 한 파일에 모으고
이거를 제가(사람이) 깔끔하게 정리하고 무슨 작업을 할지 고민하려다가
문뜩 든 생각은
이것도 AI에게 정리시켜 보자.
그리고 개발자들도 무언가 자동화해서 작업할 것 같으니 찾아보자 였습니다.
또한, 피드백들을 하나씩 반영하는 것 보다는 종합적이고 체계적으로 반영하는 것이 좋겠다라고 생각을 했습니다.
ChatGPT와 Gemini에게 물어보니 다음을 배울 수 있었습니다.
1️⃣ 일반적인 개발팀은 이 상황에서 이렇게 움직인다
전체 그림 (현업 표준 흐름)
사용자 피드백 수집
→ 피드백 정제(번역·요약·중복 제거)
→ 문제 정의(What is broken?)
→ 우선순위 결정(무엇부터?)
→ 작업 단위로 쪼개기
→ 개발/수정
→ 재배포
→ 다시 피드백
여기서 개발자들이 가장 공을 들이는 지점은 2~4번이야.
왜냐하면 피드백 자체는 대부분 불완전하고 감정적이며 모호하거든.
2️⃣ 피드백이 “이해하기 어려운 이유” (정상적인 현상)
사용자 피드백은 보통 이런 문제를 가진다:
❌ 증상만 말함 (“불편해요”, “헷갈려요”)
❌ 해결책을 착각함 (“버튼 위치를 바꿔야 할 듯”)
❌ 개인 취향 + 실제 문제 섞임
❌ 서로 충돌하는 요구
그래서 개발자는 피드백을 그대로 구현하지 않는다.
반드시 ‘번역’한다.
3️⃣ 핵심 개념 하나만 기억해도 된다
피드백 → 요구사항이 아니라 → ‘문제 신호’다
그래서 Antigravity에게 시켜야 할 일은
❌ “이 피드백들 반영해서 고쳐줘”
가 아니라
✅ “이 피드백들에서 ‘구조적인 문제’를 뽑아내라”야.
4️⃣ Antigravity에게 넘기기 전에, 피드백을 이렇게 구조화해라
🔹 Step 1. 피드백을 4가지 카테고리로 분류
Antigravity가 가장 잘하는 구조야.
카테고리
질문
기능(Function)
안 되거나, 기대와 다르게 동작
사용성(UX)
헷갈림, 불편, 동선 문제
가치(Value)
“왜 써야 하는지 모르겠다”
버그(Bug)
오류, 깨짐, 데이터 문제
👉 이 단계에서 중복 피드백은 자동으로 묶인다.
🔹 Step 2. “사용자 말” → “개발자 언어”로 변환
예시:
사용자:
“이거 뭔지 잘 모르겠어요”
개발자 언어:
초기 진입 시 핵심 가치 설명이 부족함
→ 온보딩/헤더 메시지 개선 필요
이게 바이브코딩에 필요한 진짜 입력값이야.
5️⃣ Antigravity에게 바로 써먹을 수 있는 지시 템플릿
아래는 그대로 복붙해서 써도 된다.
🧠 Antigravity Vibe Coding Prompt (개선 스프린트용)
역할:
너는 시니어 프로덕트 엔지니어 + 프로덕트 매니저 역할을 동시에 수행한다.
목표:
아래 사용자 피드백들을 바탕으로
1) 핵심 문제를 구조적으로 정리하고
2) 우선순위를 정한 뒤
3) MVP 개선을 위한 작업 리스트를 도출하라.
작업 단계:
Step 1. 피드백을 다음 4가지로 분류하라
- Function
- UX
- Value Proposition
- Bug
Step 2. 각 피드백을
- 사용자 표현
- 실제 문제 정의
형태로 재정의하라.
Step 3. 임팩트 × 수정 난이도를 기준으로
- 즉시 수정
- 다음 스프린트
- 보류
로 나누어라.
Step 4. 각 항목을 개발 작업 단위(Task)로 쪼개고
- 수정 대상
- 수정 방향
- 기대 효과
를 명확히 기술하라.
출력 형식:
- 표 + 간결한 요약
- 개발자가 바로 작업 가능한 수준
6️⃣ “피드백이 많을 때” 실전 팁 (아주 중요)
✅ 100개 피드백 → 실제 수정 포인트는 보통 5~10개
나머지는 같은 문제의 다른 표현
✅ 사용자 제안 ≠ 구현해야 할 요구
“버튼 옮겨라” → 정보 구조 문제
“기능 추가해달라” → 기존 기능 인지가 안 됨
✅ MVP 단계에서는 이 기준을 써라
“이 수정이 재방문율 / 이해도 / 이탈률 중 하나라도 개선하는가?”
7️⃣ 이 방식의 장점 (왜 이게 좋은가)
Antigravity가 코딩 노예가 아니라 ‘제품 파트너’처럼 움직임
감정 섞인 피드백을 냉정한 작업 리스트로 변환
수정 범위가 통제됨 (스코프 폭주 방지)
다음 투자·고도화 단계에서도 그대로 재사용 가능
참고로, 이 흐름은 어디서 쓰이나?
YC 스타트업들의 MVP iteration 방식
Intercom, Stripe, Notion의 초기 PM 플레이북
“Build → Measure → Learn” 루프의 실전 버전
또한, 이러한 방법론에 따라서 Gemini에게 일을 시켜보니 몇 가지 프롬프트를 뽑아줍니다.
주제: CXO 리더십 트레이닝 AI 로직 고도화 (LEINN 벤치마킹)
1. 프롬프트 데이터베이스화 (Prompt as Data)
"현재 하드코딩된 AI 프롬프트를 데이터베이스에서 관리할 수 있도록 구조를 변경해줘. ai_prompts 테이블을 설계하고, 관리자 UI에서 실시간으로 프롬프트를 튜닝할 수 있는 API 엔드포인트를 생성해줘. 이를 통해 코드 배포 없이도 대화의 톤앤매너나 분석 로직을 즉시 수정할 수 있어야 해."
2. 동적 맥락 주입 시스템 (Context Injection)
"AI 분석의 정확도를 높이기 위해 프롬프트 실행 시 사용자 및 상황 데이터를 동적으로 주입하는 기능을 구현해줘. 다음 변수들이 프롬프트 템플릿 내의 중괄호{{ }}에 매핑되어야 해:
{{user_name}}: 대화 참여자 이름
{{situation_context}}: 선택된 리더십 시나리오 (연봉 협상, 명예퇴직 권유 등)
{{conversation_history}}: 이전 대화 맥락 전체
{{selected_persona}}: 유저가 선택한 코칭 루트 (공감형, 책임탐색형 등)"
3. 구조화된 출력 제어 (Structured Output)
"AI가 단순 텍스트로 답변하는 대신, UI에서 처리하기 쉬운 정형 데이터(JSON) 형식을 반환하도록 강제해줘. 출력 구조는 반드시 다음 섹션을 포함해야 해:
analysis_summary: 리더십 역량 및 현재 상태 요약
risk_signals: 사용자가 놓친 위험 신호나 리더십 실수 (위험도: 높음/중간/낮음 표시)
coaching_suggestions: 즉시 실행 가능한 액션 아이템 제안
ai_response: 페르소나가 반영된 실제 대화 답변"
4. 시나리오 민감도 및 페르소나 강화
"시나리오의 현실성을 높이기 위해, AI 페르소나가 사용자의 호의적인 태도에 즉각 수긍하지 않도록 설정을 강화해줘. 특히 '명예퇴직 권유'와 같은 민감한 상황에서 리더가 법적/윤리적 실수를 할 경우 이를 예리하게 포착하여 피드백 엔진에 전달하는 로직을 포함해줘."
💡 Antigravity 작업 확인 사항
위 작업 완료 후,
scripts/update-ai-prompts.ts와 같은 설정 파일이 DB와 잘 연동되는지 확인해줘.힌트 스크립트 오류(특정 루트 선택 시 다른 루트가 업데이트되지 않는 문제)가 해결되었는지 유저 플로우 테스트를 진행해줘.
이런 식으로 왔다갔다 하면서 Antigravity에게 시킬 작업들을 체계적으로 정리하고 피드백과 개선의견들을 반영하는 작업 방법을 익힐 수 있었습니다.
feedback.md 등의 파일을 만들어서 프로젝트 폴더에 넣어주고 또한, ChatGPT/Gemini와 대화하면서 얻었던 작업 지시서들을 바탕으로 여러 작업을 Antigravity에게 주고 작업을 독려했습니다
역시 여러 번 티키타카를 치고 에러도 계속 잡고 작업을 하면서 개선 작업을 끝낼 수 있었습니다.
Improvement plan이라는 문서를 만들더니 하나하나씩 작업을 하더군요
피드백과 개선 의견들을 제대로 반영했는지 꼼꼼이 따져묻고 확인까지 했습니다.
마지막까지 여러가지를 확인후에 다시 배포를 하기 위해 준비를 하고
코드 리팩토링까지 완료했습니다.
한국어 페이지 스크린샷
그리고 추가적으로 스터디장님에게 배운
QA 리스트를 만들고 리뷰해달라고 요청해서 진행했고,
한국어 텍스트가 있는 화면의 스크린샷
또한, 유저 입장에서 허점이 없는지 알아봐 달라고 요청해서 수정도 했습니다.
한국어 텍스트가 있는 화면의 스크린샷
완료했습니다.
그래서 이제 다시 배포합니다.
한국어 텍스트가 있는 페이지의 스크린샷
배포 후 테스트 해봅니다.
이전 보다는 확실히 좋아진 것 같습니다.
이래서 MVP를 만들고 빨리빨리 피드백 받고 개선해 가면서 업그레이드 하는 거군요.
잘 배웠습니다!
그리고 이러한 개선 작업은 언제까지 해야 하나 싶어서 또 물어봤습니다.
역시 답이 있군요
1️⃣ 현실부터 짚자: “모두가 good이라고 말하는 순간”은 없 다
실제 개발 현장에서는 이런 상태가 존재하지 않는다.
어떤 사용자는 계속 불만을 말한다
어떤 사용자는 아무 말도 안 한다
어떤 사용자는 개선을 느끼지만 굳이 피드백하지 않는다
그래서 “피드백이 더 이상 안 나올 때까지”는 기준이 될 수 없다.
이 기준을 잡으면 개발은 끝나지 않는다.
2️⃣ 개발자들이 실제로 쓰는 기준은 이것이다
핵심 질문 3가지
개선 스프린트를 계속할지 멈출지 판단할 때, 팀들은 아래만 본다.
✅ Q1. 이 문제가 핵심 사용자 흐름을 막고 있는가?
가입
첫 사용
핵심 기능 1회 성공
재방문
👉 핵심 플로우에 영향 있으면 즉시 개선 대상
✅ Q2. 같은 피드백이 반복적으로 들어오는가?
1~2명 → 참고
5명 이상 → 신호
계속 등장 → 구조적 문제
👉 빈도가 곧 우선순위
✅ Q3. 이 개선이 지표를 바꿀 수 있는가?
예:
이탈률
전환율
재사용률
체류 시간
👉 지표에 영향 없으면, MVP 단계에서는 과감히 보류
3️⃣ 그래서 보통 “언제까지” 하느냐면
개발팀의 실제 운영 방식은 이렇다
📌 개선은 “기간 단위”로 끊는다
1주
2주
많아도 4주
이걸 개선 스프린트(iteration) 라고 부른다.
“이번 스프린트에서는 이 문제까지만 고친다”
→ 끝나면 무조건 배포
→ 다시 측정
4️⃣ 아주 중요한 개념: “피드백 포화점”
실무에서는 이런 순간이 온다.
기능/UX 관련 피드백이 줄어든다
대신 취향, 방향성, 개인적 요청이 늘어난다
이때가 바로 👇
제품의 ‘기본 구조’는 맞아졌다는 신호
이 시점부터는
❌ 모든 피드백을 반영하지 않는다
✅ “우리 제품이 가려는 방향과 맞는가?”만 본다
5️⃣ MVP 단계에서의 정석적인 종료 기준 (아주 실전적)
아래 4개 중 2~3개가 만족되면 “1차 개선 종료”
신규 사용자가 설명 없이도 핵심 기능을 1회 이상 사용
같은 UX 불만이 반복적으로 등장하지 않음
“이게 뭐냐” → “아 이런 거구나” 반응으로 바뀜
사용자가 기능 추가를 말하기 시작함
이건 이해했다는 뜻이다
👉 이 시점부터는
‘개선’이 아니라 ‘확장’ 단계로 넘어간다.
6️⃣ 지금 상황에 딱 맞는 운영 전략 (현실적)
당신처럼 Antigravity로 바이브코딩을 하는 경우,
가장 잘 맞는 방식은 이거다.
🔁 3-Loop Rule
Loop 1: 치명적 문제 제거 (막히는 것들)
Loop 2: 이해도/UX 개선 (헷갈리는 것들)
Loop 3: 사용 흐름 다듬기 (덜 불편하게)
→ Loop 3까지 끝나면 일단 멈춘다
그 다음은:
새로운 기능 ❌
더 예쁜 UI ❌
“A가 이런 말 했어요” ❌
👉 이제는 데이터와 방향성으로만 움직인다.
7️⃣ 절대 빠지면 안 되는 함정 하나
“아직 완벽하지 않은 것 같은데…”
이 생각이 들 때가 가장 위험하다.
완벽해졌을 때는
이미 시장은 다른 놈이 먹고 있다
실제 프로덕트 팀들은 이렇게 말한다:
“조금 불편한 상태에서 시장에 있는 게
완벽하지만 아무도 안 쓰는 것보다 낫다.”
MVP 개발 후 뒷단의 프로세스를 경험하고 체화한 좋은 스터디 경험이었습니다.
기획자민지 스터디장님 감사합니다.! 🙇 👍 🥰
