AI를 써먹기 위한 최소 지식 2편: 프롬프트보다 중요한 컨텍스트

프롬프트 문장보다 컨텍스트 품질이 중요한 이유와, 코드 작업에서 목표/제약/로그/완료 기준을 함께 전달하는 방법을 정리합니다.

목차

1편에서는 LLM을 "문맥을 보고 다음에 올 가능성이 높은 답을 만드는 도구"로 보는 관점을 잡았습니다.

그 관점에서 바로 이어지는 질문이 있습니다.

그럼 AI가 참고하는 문맥은 어떻게 줘야 할까요?

AI를 처음 쓰기 시작하면 자연스럽게 프롬프트에 관심이 갑니다.

"어떤 문장으로 물어봐야 답을 잘할까?"

"역할을 지정하면 더 좋아질까?"

"전문가처럼 답해줘라고 하면 진짜 전문가처럼 답할까?"

물론 프롬프트 문장도 중요합니다. 그런데 개발 작업에서는 문장보다 더 중요한 게 있습니다.

AI가 판단에 사용할 수 있는 컨텍스트입니다.

좋은 컨텍스트 없이 좋은 프롬프트만 던지면, 답은 매끄럽지만 실제 작업에는 애매할 수 있습니다. 반대로 문장이 조금 투박해도 필요한 정보가 잘 들어 있으면 답은 훨씬 쓸만해집니다.

같은 질문도 컨텍스트에 따라 답이 달라진다

예를 들어 이렇게 물어보면 어떨까요.

이 API가 느린데 어떻게 개선하면 좋을까?

AI는 일반적인 답을 할 수 있습니다.

• 캐시를 붙인다
• DB 쿼리를 최적화한다
• 응답 payload를 줄인다
• CDN을 활용한다
• 비동기 처리로 분리한다

다 맞는 말입니다. 하지만 이 답만으로 바로 작업하기는 어렵습니다.

이제 컨텍스트를 조금 더 줘보겠습니다.

상황:
- Edge 환경에서 동작하는 API
- 작은 DB와 캐시에서 통계를 읽음
- 조회수/좋아요/댓글 수를 함께 반환

증상:
- 글 상세 진입이 느림
- 모바일에서 체감이 더 큼

제약:
- 월 고정비는 늘리고 싶지 않음
- 관리자용 미리보기 화면에서는 통계 API를 호출하면 안 됨
- 공개 글에서는 조회수가 올라가야 함

원하는 답:
- 먼저 확인할 지표
- 비용을 늘리지 않는 개선 순서
- 위험한 변경과 안전한 변경 구분

이렇게 주면 답의 방향이 달라집니다.

AI는 더 이상 "일반적인 웹 성능 개선"만 말하지 않고, 실행 환경/DB/미리보기 화면/비용 제약까지 고려해야 합니다.

여기서 프롬프트의 핵심은 멋진 문장이 아니라 판단에 필요한 경계 조건입니다.

컨텍스트는 많이 넣는다고 좋은 게 아니다

그럼 모든 파일과 모든 로그를 다 넣으면 될까요?

아닙니다.

컨텍스트도 설계해야 합니다.

너무 적으면 AI가 추측하고, 너무 많으면 중요한 정보가 묻힙니다. 필요한 건 "많은 정보"가 아니라 "관련 있는 정보"입니다.

저는 보통 이렇게 나눠서 봅니다.

이 정도만 정리해도 답의 품질이 많이 달라집니다.

개발 요청은 작업 카드처럼 만든다

AI에게 코딩을 맡길 때는 그냥 "고쳐줘"보다 작업 카드 형태가 좋습니다.

목표:
- 블로그 글 상세 페이지 진입 속도 개선

관련 파일:
- src/api/article-stats.js
- public/assets/article.js
- scripts/build-preview.mjs

제약:
- 관리자용 미리보기 화면에서는 조회수 API 호출 금지
- 공개 글만 통계 API 사용
- 기존 댓글/좋아요 동작 유지

확인:
- npm run build:preview
- curl로 공개 글 200 확인
- draft URL은 404 확인

보고:
- 변경 파일
- 성능상 기대 효과
- 남은 위험

이렇게 쓰면 AI는 작업 범위와 완료 기준을 같이 받습니다.

특히 "관련 파일"과 "하면 안 되는 것"을 적어두면 엉뚱한 방향으로 가는 일이 줄어듭니다.

로그는 요약보다 원문 일부가 낫다

문제가 발생했을 때는 "에러 남"이라고 쓰는 것보다 실제 로그 한 줄이 훨씬 좋습니다.

cat: /path/to/task-config.md: Operation not permitted

이 한 줄이 있으면 원인이 권한 문제 쪽으로 좁혀집니다.

반대로 "자동화가 안 돌아요"라고만 하면 cron, path, token, network, process, permission을 전부 의심해야 합니다.

로그는 길게 다 붙일 필요는 없습니다.

중요한 부분은 이 정도입니다.

명령어:
npm run build

결과:
HTTP/2 404

관련 로그:
...

기대:
관리자용 미리보기는 로그인 화면 또는 정상 페이지가 떠야 함
public draft URL은 404여야 함

AI에게도 좋고, 나중에 사람이 다시 봐도 좋습니다.

컨텍스트를 주는 순서도 중요하다

저는 보통 이 순서를 선호합니다.

1. 목표
2. 현재 상황
3. 관련 파일/로그
4. 제약
5. 완료 기준
6. 원하는 보고 형식

이 순서는 사람이 읽어도 자연스럽습니다.

AI도 먼저 목표를 잡고, 그 다음 근거를 보고, 마지막에 완료 조건을 맞추기 쉽습니다.

처음부터 모든 로그를 던지고 "분석해줘"라고 하면 답이 산만해질 때가 많습니다.

프롬프트 템플릿 하나만 만든다면

개발 작업용으로 하나만 만든다면 저는 이렇게 쓰겠습니다.

목표:
-

현재 상황:
-

관련 파일/로그:
-

제약:
-

완료 기준:
-

먼저 짧은 계획을 세우고, 그 다음 진행해줘.
마지막에는 변경 내용과 검증 결과를 정리해줘.

여기서 마지막 문장이 꽤 중요합니다.

먼저 계획을 세우게 하면 AI가 문제를 어떻게 이해했는지 볼 수 있습니다.

이 단계에서 틀린 방향이 보이면 구현 전에 바로 고칠 수 있습니다. 코드를 다 바꾼 뒤 고치는 것보다 훨씬 낫습니다.

정리하면

프롬프트를 잘 쓰는 건 중요합니다.

하지만 개발 작업에서는 "문장 예쁘게 쓰기"보다 "판단 재료를 제대로 주기"가 더 중요합니다.

좋은 컨텍스트 = 목표 + 현재 구조 + 증상 + 제약 + 증거 + 완료 기준

이걸 습관처럼 묶어주면 AI 답변은 훨씬 안정적이 됩니다.

다음 글에서는 이 컨텍스트가 실제로 어느 정도까지 들어갈 수 있는지, 토큰과 컨텍스트 윈도우를 기준으로 정리해보겠습니다.

좋은 컨텍스트를 주는 것만큼, 그 컨텍스트가 들어갈 수 있는 공간의 한계를 아는 것도 중요합니다.