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