오늘 끝나면
컨텍스트와 프롬프트
- ✓컨텍스트와 프롬프트의 핵심 문제를 한 문장으로 설명한다
- ✓오른쪽 실습에서 컨텍스트와이 어떻게 움직이는지 관찰한다
- ✓다음 강의와 이어지는 한계를 말할 수 있다
실습 미션
무엇을·어떻게 시킬까 — 맥락이 품질을 정함 이 문장이 실제로 무슨 뜻인지 실습에서 한 번 손으로 확인한다.
성공 조건
- □실습의 기본값을 먼저 관찰
- □입력값이나 모드를 한 번 이상 바꿔 결과 비교
- □왜 결과가 바뀌었는지 한 문장으로 설명
바이브코딩 · 04
컨텍스트와
프롬프트
에이전트는 똑똑해도 독심술은 못 씀.
준 맥락만큼 일함. 맥락이 곧 품질임.
무엇을 · 어디서 · 어떻게 검증할지 적어주면 헛다리가 사라짐.
맥락이 품질을 정한다
에이전트는 LLM + 도구 루프임. 모델이 아무리 좋아도 받은 맥락 안에서만 추론함.
맥락이 비면 빈자리를 추측으로 메움.
그 추측이 맞으면 운이고, 틀리면 헛다리임.
그래서 결과 품질의 절반 이상은 모델이 아니라 내가 넣은 컨텍스트가 정함.
좋은 답을 받는 일은 곧 좋은 맥락을 주는 일임.
“고쳐줘”
“로그인 고쳐줘”
“비번 버그 · 파일 · 검증”
모호하면 헛다리를 짚는다
오른쪽에서 직접 해봄. “로그인 좀 고쳐줘” 같은 모호한 프롬프트와 구체적 프롬프트를 나란히 던져 봄.
모호 모드는 목표도 파일도 검증 기준도 없음.
에이전트가 파일 전부를 헤매다 아무 데나 손대고 끝남. 헛다리임.
구체 모드에선 무엇을·어디서·어떻게 검증을 토글로 채울 수 있음.
컨텍스트를 켤수록 동작이 또렷해지고, 셋 다 차면 곧장 명중함.
빈 칸 하나가 곧 헛다리 자리임.
로그인 시 비밀번호 틀려도 통과되는 버그를 막아줘
관련 파일: src/auth/login.ts
검증: 틀린 비번이면 false 반환 + 기존 테스트 통과
무엇을·어디서·어떻게 검증이 다 차면 에이전트가 곧장 명중함.
좋은 프롬프트의 세 요소
좋은 프롬프트는 화려한 말솜씨가 아님. 세 가지가 빠짐없이 들어있는 거임.
무엇을— 목표를 콕 집음 / “고쳐줘”가 아니라 “틀린 비번이 통과되는 버그를 막아줘”.
어디서 — 관련 파일·범위를 지정 / 헤매지 않게 길을 줌.
어떻게 검증 — 끝났다고 볼 기준 / 테스트·제약·예시.
이 세 칸을 채우면 에이전트가 추측할 여지가 줄어듦.
추측이 줄면 헛다리도 줄어듦. 프롬프트 품질 = 채운 칸 수임.
세 칸을 채울수록 추측이 줄어듦
관련 파일·예시를 직접 줘라
에이전트는 도구로 파일을 읽을 수 있음. 근데 어디를 읽을지는 내가 가리켜 줘야 빠름.
관련 파일 경로를 직접 박으면 탐색을 건너뛰고 바로 일함.
원하는 출력 모양을 예시로 보여주면 형식을 헛짚지 않음.
하지 말 것(제약)을 적으면 엉뚱한 방향으로 안 새어 나감.
말로만 “알아서 잘”은 맥락이 아님.
파일 · 예시 · 제약 — 손에 잡히는 걸 줘야 에이전트도 손에 잡고 일함.
| 주는 것 | 에이전트에게 생기는 일 |
|---|---|
| 관련 파일 경로src/auth/login.ts | 탐색을 건너뜀 |
| 원하는 출력 예시이런 모양으로 줘 | 형식을 안 헛짚음 |
| 하지 말 것(제약)DB 스키마는 건들지 마 | 방향이 안 샘 |
| 에러 메시지·로그이 줄에서 터짐 | 원인을 좁힘 |
헛다리는 컨텍스트부터 의심하라
에이전트가 엉뚱한 걸 내놨을 때, 모델 탓·운 탓부터 하면 못 고침.
첫 점검은 컨텍스트임.
목표가 모호하진 않았나 · 관련 파일을 줬나 · 검증 기준을 적었나.
대개 빈 칸 하나가 헛다리의 원인임.
프롬프트를 다시 쓰는 게 모델을 바꾸는 것보다 훨씬 빠르고 잘 먹힘.
맥락을 더 주고 다시 시키는 것 — 그게 바이브코더의 기본기임.
Q. 에이전트가 자꾸 헛다리를 짚을 때, 가장 먼저 점검할 것은? (모델을 더 큰 걸로 · 컨텍스트가 충분한가 · 같은 말로 한 번 더 · 운이 나빴다고 넘김)
정답은 컨텍스트가 충분한가임.목표(무엇을) · 관련 파일(어디서) · 검증 기준(어떻게)이 빠지지 않았는지부터 봄.
헛다리의 대부분은 모델이 아니라 빈 맥락에서 나옴.
빈 칸을 채워 다시 시키는 게 가장 빠른 교정임.
모델 교체보다 빠르고 잘 먹힘