프롬프트를 코드처럼 다루기 — 시리즈 개요

왜 이 시리즈를 쓰는가

현재까지 “프롬프트 엔지니어링 기법들”을 다룬 글은 많다. 그런데 대부분 “이렇게 쓰면 좋아진다”에서 끝나는 경우가 허다하다. 정작 실서비스에서 문제가 되는 건 다른 지점이다.

같은 프롬프트가 어제는 되고 오늘은 안 되는 것.

나는 생활기록부 PDF를 입력받아 학과 추천 리포트를 출력하는 Ai 에이전트를 운영하고 있다. 사용자는 약 500명이고, 출력이 한 번 깨지면 사용자가 이용할 프로세스가 통째로 틀어진다. 그래서 프롬프트를 “잘 쓰는 문장”이 아니라 버전과 테스트가 붙은 코드로 다루게 됐다.

이 시리즈는 그 과정에서 실제로 효과가 있었던 기법만 남긴 기록이다. 각 글은 같은 틀을 따른다.

1. 어떤 문제가 터졌는가 (실제 실패 사례)
2. 어떤 기법으로 막았는가 (before / after 프롬프트)
3. 무엇이 좋아졌는가 (측정값)
4. 이 기법이 안 통하는 경우

다룰 기법

#	기법	해결하는 문제
01	시리즈 개요	—
02	역할·제약 구조화	모델이 지시를 일부만 따른다
03	출력 스키마 고정	파싱이 간헐적으로 깨진다
04	Few-shot 예시 설계	형식은 맞는데 판단 기준이 흔들린다
05	태스크 분해 (체이닝)	긴 입력에서 앞부분을 무시한다
06	평가셋과 회귀 테스트	프롬프트를 고치면 다른 게 깨진다

전제: 프롬프트는 측정하지 않으면 개선할 수 없다

이 시리즈 전체를 관통하는 생각은 하나다. 프롬프트를 고쳤을 때 좋아졌는지 나빠졌는지 말할 수 없다면, 그건 개선이 아니라 교체다.

그래서 기법을 하나 적용할 때마다 같은 질문을 던졌다.

• 이 변경으로 무엇이 좋아졌다고 주장할 수 있는가
• 그 주장을 뒷받침하는 숫자가 있는가
• 그 숫자는 몇 건의 입력으로 측정했는가

(평가셋 규모와 프롬프트 버전 관리 방식을 여기에 적는다.)

이 시리즈를 읽는 방법

기법 이름만 궁금하면 위 표만 봐도 된다. 다만 각 글의 “이 기법이 안 통하는 경우” 섹션이 본론에 가깝다. 프롬프트 기법은 대부분 트레이드오프가 있고, 그걸 모르고 쓰면 다른 데서 터진다.