바이브 코딩 교육 2편: 사용자의 한 마디가 어떻게 구체적인 스펙이 되는가

목차

1. 들어가며
2. 실제 사용자가 입력한 프롬프트
3. 이 프롬프트에 빠져 있는 것들
4. AI가 빈 곳을 채우는 방식
5. Before / After 비교
6. 왜 AI가 대신 채워도 괜찮은가
7. 정리

---

들어가며

지난 글([바이브 코딩 교육: 좋은 프롬프트로 Python 샘플 프로젝트 설계하기])에서는 이미 완성된 형태의 프롬프트, 즉 환경변수 이름, 오류 코드, 테스트 항목까지 다 정해진 프롬프트를 예시로 다뤘습니다.

그런데 실제로 바이브 코딩을 처음 하는 사람은 그렇게 완벽한 프롬프트를 처음부터 쓰지 않습니다. 보통은 "이런 흐름으로 만들어줬으면 좋겠다"는 자연스러운 요청에서 시작합니다.

이번 글에서는 일반 사용자가 실제로 입력할 법한 프롬프트를 시작점으로 놓고, 이 프롬프트가 AI와의 상호작용을 통해 어떻게 지난 글의 구체적인 스펙으로 발전하는지를 살펴봅니다.

---

실제 사용자가 입력한 프롬프트

공공데이터 API를 연동하는 Python 샘플 프로젝트를 만들어줘.
내가 쓰려는 API는 공공데이터포털의 기상청 단기예보 조회서비스야.
API 인증키는 .env에 넣어서 관리하고, 코드에는 노출되지 않게 해줘.

샘플에서 보여주고 싶은 흐름은 이거야.
1. 기상청 단기예보 API를 호출한다.
2. 조회 결과를 콘솔에 보기 좋게 출력한다.
3. 결과를 로컬 JSON 파일로 저장한다.
4. 필요하면 Gmail로 조회 결과를 공유한다.
5. Gmail 메일은 원본 JSON만 첨부하지 말고, 받는 사람이
   바로 이해할 수 있게 HTML 요약 본문으로 보내준다.
6. 원본 JSON 첨부는 옵션으로 켜고 끌 수 있게 해준다.
7. 주기적으로 다시 조회하는 예시도 있으면 좋겠다.
8. 기본적인 오류 처리와 테스트 코드도 같이 만들어줘.

나는 UI는 필요 없고, 소스 코드를 통해 공공데이터 API를
어떻게 호출하고 사용하는지 보여주고 싶어.
기술 스택은 Python으로 해줘.

필요한 라이브러리, 실행 방법, .env 예시, 테스트 방법까지
README에 정리해줘.
공공데이터 API 호출에 필요한 조회 파라미터 기본값은
네가 학습용으로 적절히 정해줘.

이 프롬프트는 문법이나 완성도가 부족한 것이 아니라, 오히려 실제 사람이 쓰는 방식에 가깝습니다. 목적과 원하는 흐름은 분명하지만, 구현에 필요한 세부값은 정해두지 않았습니다.

---

이 프롬프트에 빠져 있는 것들

지난 글의 완성된 프롬프트와 비교하면, 이번 프롬프트에는 다음과 같은 정보가 빠져 있습니다.

빠진 정보 완성된 프롬프트에서는

API의 정확한 Endpoint 주소	https://apis.data.go.kr/1360000/VilageFcstInfoService_2.0/getVilageFcst
.env 변수 이름 목록	PUBLIC_DATA_SERVICE_KEY, WEATHER_NX 등 구체적 이름
조회 격자(nx, ny) 값	nx=60, ny=127 (서울시청 인근)
base_time 자동 선택 로직	후보 8개 시각, 10분 규칙, 전날 값 사용 조건
오류 종류 구분	API_AUTH_ERROR 등 7가지 코드
테스트 항목 목록	7가지 구체적 테스트 시나리오
CLI 옵션 이름	--send-email, --monitor
저장 파일명 규칙	data/forecast_YYYYMMDD_HHMMSS.json
주기 실행 간격 설정 방법	MONITOR_INTERVAL_SECONDS 환경변수

이 목록을 보면, 사용자가 "무엇을 하고 싶은지"는 다 말했지만 "어떻게 구현할지"는 말하지 않았다는 것을 알 수 있습니다. 이 간극을 메우는 것이 바이브 코딩에서 AI의 실제 역할입니다.

---

AI가 빈 곳을 채우는 방식

AI는 이 빈 곳을 아무렇게나 채우지 않습니다. 사용자가 준 맥락과 API 자체의 특성을 근거로 값을 결정합니다.

1. Endpoint 주소 확정

사용자는 "기상청 단기예보 조회서비스"라고만 했습니다. AI는 이 서비스명을 근거로 공공데이터포털에 등록된 실제 Endpoint(VilageFcstInfoService_2.0/getVilageFcst)를 찾아 프롬프트/코드에 반영합니다.

2. 환경변수 이름 설계

".env에 인증키를 넣어줘"라는 요청만으로는 변수 이름이 정해지지 않습니다. AI는 코드 안에서 값의 역할이 드러나도록 이름을 짓습니다.

PUBLIC_DATA_SERVICE_KEY   → 공공데이터 인증키라는 것이 이름에서 드러남
WEATHER_NX / WEATHER_NY   → 날씨 조회용 격자값임을 구분
GMAIL_APP_PASSWORD        → 일반 비밀번호가 아니라 앱 비밀번호임을 이름으로 표시

3. 조회 파라미터 기본값 결정

사용자가 직접 "학습용으로 적절히 정해줘"라고 위임한 부분입니다. AI는 다음 기준으로 값을 정합니다.

• nx=60, ny=127: 특정 지역이 언급되지 않았으므로, 예시로 가장 널리 쓰이는 서울시청 인근 격자를 기본값으로 선택
• numOfRows=1000: 단기예보 API는 한 번의 조회에 여러 시간대·항목이 섞여 나오므로, 결과가 잘리지 않도록 충분히 큰 값을 선택
• dataType=JSON: Python에서 다루기 쉬운 형식을 우선 선택(XML도 가능하지만 파싱이 더 복잡함)

4. 도메인 로직 설계 (base_time 자동 선택)

사용자는 "최신 데이터를 가져와줘" 같은 말조차 하지 않았습니다. 다만 "조회 결과를 보여준다"는 목적에서, AI는 기상청 단기예보 API가 하루 8회, 특정 시각에만 데이터를 발표한다는 특성을 반영해 다음 로직을 스스로 설계합니다.

발표시각 후보: 0200, 0500, 0800, 1100, 1400, 1700, 2000, 2300
규칙: 각 발표시각 + 10분이 지나야 데이터를 조회할 수 있음
예외: 당일 첫 발표(0200) 전에 실행되면 전날 마지막 발표(2300) 사용

이 부분은 사용자가 전혀 언급하지 않았지만, API를 실제로 정상 동작시키기 위해서는 반드시 필요한 로직입니다. 바이브 코딩에서 AI는 사용자가 말하지 않은 "API 자체의 제약"까지 파악해서 로직을 보완하는 역할을 합니다.

5. 오류 처리와 테스트를 구체적 항목으로 분해

사용자는 "기본적인 오류 처리와 테스트 코드"라고만 했습니다. AI는 이 요청을 구현 가능한 단위로 쪼갭니다.

"오류 처리를 해줘" → API_AUTH_ERROR, API_TIMEOUT, API_EMPTY_RESULT ... (7종)
"테스트 코드를 만들어줘" → base_time 선택 테스트, JSON 파싱 테스트,
                          이메일 첨부 옵션별 테스트 ... (7종)

이렇게 나누는 이유는 명확합니다. "오류 처리 해줘"라는 한 문장으로는 코드에 무엇을 작성해야 하는지 알 수 없지만, 오류를 종류별로 나누면 각각 대응하는 if/except 분기와 테스트 함수가 자연스럽게 생깁니다.

6. 사용자 경험을 고려한 세부 결정

사용자는 "HTML 요약 본문으로 보내달라"고만 했지만, AI는 여기에 "받는 사람이 바로 이해할 수 있게"라는 목적을 근거로 본문에 들어갈 구체적인 항목(발표일자, 조회 격자, 항목 수, 저장 시각, 예보 시간별 표)까지 정합니다.

---

Before / After 비교

구분 사용자의 원래 요청 AI가 구체화한 결과

API 정보	"기상청 단기예보 조회서비스"	정확한 Endpoint URL 지정
인증키 관리	".env에 넣어줘"	변수명, .env.example, .gitignore 규칙까지 지정
조회 파라미터	"네가 적절히 정해줘"	nx/ny/numOfRows/dataType 값과 그 이유
최신 데이터 조회	(언급 없음)	base_time 자동 선택 로직 8단계
오류 처리	"기본적인 오류 처리"	7개 오류 코드로 세분화
테스트	"테스트 코드도 같이"	7개 구체적 테스트 시나리오
주기 실행	"예시가 있으면 좋겠다"	--monitor 옵션과 간격 설정 변수
이메일 내용	"HTML 요약 본문"	포함할 5가지 항목 구체화

이렇게 놓고 보면, 사용자가 한 줄로 요청한 항목이 AI를 거치면서 여러 줄의 구체적인 스펙으로 확장되는 것을 볼 수 있습니다. 이것이 지난 글에서 다룬 "완성된 프롬프트"가 실제로 만들어지는 과정입니다.

---

왜 AI가 대신 채워도 괜찮은가

여기서 한 가지 질문이 생길 수 있습니다. "AI가 알아서 정한 값을 그대로 믿어도 될까?"

답은 **"검증 가능한 형태로 채우는 한 괜찮다"**입니다. 이 프롬프트에서 AI가 채운 값들은 다음과 같은 공통점이 있습니다.

• 값이 코드나 .env.example에 그대로 드러나 있어 나중에 쉽게 바꿀 수 있다 (nx=60, numOfRows=1000 등)
• 로직이 README나 주석으로 설명되어 있어 왜 그렇게 동작하는지 추적할 수 있다 (base_time 규칙)
• 사용자가 원래 위임한 범위(“학습용으로 적절히 정해줘”) 안에 있다

반대로, 만약 사용자가 실제 운영 서비스를 만드는 것이었다면 격자값이나 조회 간격 같은 값은 AI에게 위임하지 않고 처음부터 직접 지정하는 것이 안전합니다. 학습·샘플 목적처럼 위임 범위가 넓을 때만 AI가 기본값을 정하도록 두는 것이 바이브 코딩에서의 합리적인 경계입니다.

---

정리

이번 글에서 살펴본 흐름을 한 문장으로 정리하면 다음과 같습니다.

사용자는 "무엇을 원하는지"를 말하고, AI는 그것을 "어떻게 구현할지"로 번역한다.

바이브 코딩을 잘하기 위해 처음부터 완벽한 스펙 문서를 쓸 필요는 없습니다. 오히려 다음 두 가지만 지키면, 이번 글에서 본 것처럼 AI가 나머지를 자연스럽게 구체화해 줍니다.

1. 목적과 원하는 흐름을 순서대로 명확히 말한다 (이번 프롬프트의 1~8번 항목처럼)
2. AI에게 위임할 부분과 위임하지 않을 부분을 구분해서 알려준다 ("파라미터 기본값은 네가 정해줘"처럼)

이렇게 시작한 요청은 AI와의 대화를 거치며 지난 글에서 본 것처럼 변수명, 오류 코드, 테스트 항목까지 갖춘 구체적인 스펙으로 자연스럽게 발전하게 됩니다.

vibe_coding_education_2.md.pdf

0.36MB