회귀 테스트와 프롬프트 개선 루프

3장과 4장에서 우리는 좋은 프롬프트를 증명하려면 기준이 있어야 하고, 그 기준을 반복해서 적용할 평가셋과 그레이더가 있어야 한다는 점을 보았다. 이제 다음 질문이 남는다. 그래서 프롬프트를 어떻게 계속 좋아지게 만들 것인가?

많은 팀이 여기서 다시 감각의 세계로 되돌아간다. 프롬프트를 조금 고치고, 샘플 몇 개를 돌려 보고, "이번이 더 낫네요"라고 말한 뒤 배포한다. 문제는 이런 방식이 대개 한쪽을 고치면 다른 한쪽이 무너지는 결과를 낳는다는 데 있다. 설명은 더 친절해졌지만 정확성이 떨어질 수 있고, 안전 장치를 강화했더니 정상 질문까지 거절할 수 있으며, 형식 준수는 좋아졌지만 비용과 지연이 급증할 수도 있다.

운영 가능한 프롬프트 시스템에서는 개선이 우연처럼 일어나면 안 된다. 개선은 변경 기록이 남고, 비교가 가능하고, 이전에 잘 되던 것이 깨졌는지 확인되며, 실제 운영에서도 효과가 검증되는 과정이어야 한다. 이 장에서는 그 과정을 하나의 루프로 묶어 본다. 핵심은 단순하다. "좋아 보인다"가 아니라 "실제로 좋아졌다"를 말할 수 있어야 한다.

프롬프트 개선은 문장 수정이 아니라 변경 관리다

프롬프트를 손보는 일은 겉으로 보면 문장을 고치는 작업처럼 보인다. 하지만 실무에서는 훨씬 더 넓은 변경 관리에 가깝다. 왜냐하면 모델의 출력은 프롬프트 문장 하나만으로 결정되지 않기 때문이다. 시스템 지시, 사용자 입력 구조, few-shot 예시, 출력 스키마, 도구 설명, 모델 종류, temperature 같은 파라미터, 검색 컨텍스트, 후처리 규칙까지 함께 작동한다.

그래서 어떤 팀이 "프롬프트를 바꿨더니 성능이 올랐다"고 말할 때는 먼저 물어야 한다. 정확히 무엇이 바뀌었는가? 프롬프트 본문만 달라졌는가, 예시가 추가되었는가, 모델이 바뀌었는가, 평가셋이 달라졌는가, 그레이더 기준이 수정되었는가. 이 질문에 답하지 못하면 개선이라고 말하기 어렵다.

프롬프트 개선 루프의 첫걸음은 모든 변경을 하나의 버전 단위로 다루는 것이다. 즉, 프롬프트는 메모장 속 문장이 아니라 버전이 있는 운영 자산이어야 한다.

프롬프트 버전 관리는 무엇을 남겨야 하는가

버전 관리에서 가장 흔한 실수는 프롬프트 텍스트만 저장하는 것이다. 물론 그것도 필요하다. 하지만 그것만으로는 재현이 되지 않는다. 같은 프롬프트 문장이라도 모델이 다르면 결과가 달라지고, 샘플 예시가 다르면 응답 성향이 달라지며, 평가셋 버전이 바뀌면 점수 해석도 달라진다.

실무에서 프롬프트 버전은 보통 다음 요소를 함께 묶어 기록하는 편이 좋다.

• 프롬프트 본문: 시스템, 개발자, 사용자 템플릿과 출력 형식 지시

• 실행 조건: 모델명, 파라미터, 도구 설정, 컨텍스트 삽입 규칙

• 평가 조건: 사용한 평가셋 버전, 그레이더 버전, 루브릭 버전

• 변경 이유: 어떤 실패를 줄이려는 수정인지, 어떤 가설을 검증하려는지

• 결과 요약: 오프라인 점수, 회귀 여부, 비용과 지연 변화, 온라인 실험 결과

이렇게 기록해야 나중에 "왜 이 버전을 만들었지?"라는 질문에 답할 수 있다. 더 중요한 이유도 있다. 좋아졌다고 믿었던 변경이 몇 주 뒤 문제를 일으켰을 때, 어디서 흔들렸는지 다시 추적할 수 있기 때문이다.

간단한 버전 로그는 다음 정도만 있어도 큰 도움이 된다.

이 표의 핵심은 멋진 형식이 아니다. 변경의 의도와 결과가 함께 남아야 한다는 점이다. 버전 번호만 늘어나고 이유가 남지 않으면, 시스템은 금방 "누가 왜 이렇게 만들었는지 아무도 모르는 상태"가 된다.

좋은 개선은 먼저 가설을 세운다

프롬프트를 수정할 때 무작정 문장을 덧대기 시작하면 대개 두 가지 일이 벌어진다. 첫째, 지시가 점점 길어지고 모순이 늘어난다. 둘째, 무엇이 효과를 냈는지 알 수 없어진다. 그래서 개선은 수정부터 시작하지 말고 가설부터 시작해야 한다.

예를 들어 내부 정책 도우미가 문서에 없는 내용을 자꾸 추정해서 말한다고 하자. 이때 좋은 가설은 이렇게 생긴다.

"문서 근거가 부족할 때 답변을 멈추고 한계를 밝히는 규칙을 더 명확히 쓰면, 근거 없는 단정이 줄어들 것이다. 다만 완전성은 일부 떨어질 수 있다."

이 가설에는 세 가지가 들어 있다. 무엇을 바꾸는지, 무엇이 좋아질 것 같은지, 어떤 부작용이 예상되는지다. 이런 식으로 써 두면 평가도 훨씬 선명해진다. 우리는 groundedness가 올라갔는지 볼 수 있고, completeness가 얼마나 떨어졌는지도 함께 확인할 수 있다.

반대로 "좀 더 정확하게 답하도록 프롬프트를 개선한다" 같은 문장은 가설이 아니다. 바꿀 지점도 모호하고, 기대 효과도 모호하고, 실패 조건도 모호하기 때문이다.

프롬프트 개선의 기본 단위는 작은 변경이어야 한다

운영 중인 프롬프트를 개선할 때는 한 번에 너무 많은 것을 바꾸지 않는 편이 좋다. 물론 대수술이 필요한 순간도 있다. 하지만 대부분의 반복 개선은 작은 변경 단위가 훨씬 유리하다. 이유는 단순하다. 원인과 결과를 연결하기 쉬워지기 때문이다.

예를 들어 다음 세 가지를 한 번에 바꿨다고 해 보자.

• 시스템 프롬프트에 안전 규칙 추가

• few-shot 예시 5개 교체

• 모델을 다른 계열로 변경

이후 점수가 올라가도 무엇이 효과였는지 알기 어렵다. 반대로 점수가 떨어져도 어디서 깨졌는지 파악하기 힘들다. 그래서 실무에서는 보통 작은 변경을 먼저 적용하고, 각 변경의 효과를 본 뒤 조합을 시도한다.

작은 변경이란 반드시 한 줄 수정만 뜻하지는 않는다. 중요한 것은 변경 의도를 하나로 묶을 수 있는가다. 예를 들어 "거절 기준 명확화"는 하나의 변경으로 볼 수 있고, "출력 JSON 필드 정리"도 하나의 변경으로 볼 수 있다. 이렇게 단위를 관리하면 실험과 회귀 판정이 훨씬 쉬워진다.

오프라인 평가가 먼저이고, 온라인 실험은 그다음이다

실무에서 자주 나오는 유혹은 바로 운영 트래픽으로 시험해 보는 것이다. 실제 사용자 반응을 보는 것이 가장 현실적이기 때문이다. 맞는 말이다. 하지만 그 전에 해야 할 일이 있다. 오프라인 평가셋으로 기본 품질과 회귀 여부를 먼저 확인하는 것이다.

오프라인 평가는 실험실 시험과 비슷하다. 같은 샘플 묶음에 대해 이전 버전과 새 버전을 나란히 비교할 수 있다. 위험한 변경을 실제 사용자에게 노출하기 전에 기본 안전성도 점검할 수 있다. 특히 다음과 같은 질문은 오프라인에서 먼저 답해야 한다.

• 기존에 잘 되던 대표 샘플이 유지되는가

• 과거 실패 사례가 실제로 줄어드는가

• 거절, 형식, 안전 규칙이 깨지지 않았는가

• 비용과 지연이 감당 가능한 범위인가

이 단계를 통과한 뒤에야 온라인 A/B 테스트가 의미를 갖는다. 오프라인에서 이미 치명적 회귀가 보이는 버전을 온라인에 올리는 것은, 브레이크가 고장 난 자동차를 시승 행사에 보내는 것과 비슷하다.

A/B 테스트는 무엇을 알려 주고, 무엇은 알려 주지 못하는가

A/B 테스트는 실제 사용자 환경에서 두 버전을 비교하는 가장 강력한 도구 중 하나다. 특히 사용자의 만족도, 클릭률, 후속 행동, 재질문 비율, 상담 전환율 같은 운영 지표는 오프라인 평가만으로는 완전히 알 수 없다.

예를 들어 새 프롬프트가 오프라인 기준으로는 더 정확하고 형식도 잘 맞는다고 하자. 그런데 실제 서비스에서는 답변이 너무 딱딱해져 사용자가 재질문을 더 많이 하게 될 수 있다. 반대로 오프라인 점수 차이는 작아도, 실제 환경에서는 불필요한 장황함이 줄어 사용자 완료율이 올라갈 수 있다. 이런 차이는 온라인 실험에서만 드러나는 경우가 많다.

하지만 A/B 테스트에도 한계가 있다. 운영 데이터는 잡음이 많고, 사용자 집단이 매번 같지 않으며, 외부 요인의 영향을 받는다. 또한 실제 사용자 반응이 좋다고 해서 반드시 안전성과 정확성이 보장되는 것도 아니다. 사용자는 그럴듯한 답을 좋아할 수 있지만, 실무 시스템은 그럴듯함보다 사실성이 더 중요할 수 있다.

그래서 A/B 테스트는 오프라인 평가를 대체하는 것이 아니라 보완하는 역할을 맡아야 한다. 오프라인은 기본 품질과 회귀 차단을 담당하고, 온라인은 실제 사용 가치와 운영 효과를 검증한다.

A/B 테스트를 설계할 때 꼭 봐야 할 지표

A/B 테스트를 할 때 가장 위험한 방식은 지표 하나만 보는 것이다. 예를 들어 사용자 만족도만 보면, 장황하고 자신감 넘치는 답변이 유리하게 나올 수 있다. 반대로 거절률만 보면, 위험한 요청에도 쉽게 응하는 버전이 더 좋아 보일 수 있다.

따라서 온라인 비교에서는 최소한 서로 다른 성격의 지표를 함께 봐야 한다.

• 품질 지표: 해결률, 재질문 비율, 사용자 피드백, 사람 검토 점수

• 안전 지표: 금지 요청 통과율, 근거 없는 단정 비율, 정책 위반 건수

• 운영 지표: 응답 시간, 토큰 사용량, 도구 호출 횟수, 실패율

이 세 축을 함께 봐야 한다. 그래야 "사용자는 좋아하지만 위험하다"거나 "안전하지만 너무 비싸다" 같은 상황을 분리해 볼 수 있다. 실무에서는 하나의 승자 점수보다, 어떤 축에서 이기고 어떤 축에서 손해를 보는지가 훨씬 중요하다.

회귀 테스트는 '이전보다 나빠졌는가'를 묻는 장치다

개선 루프에서 가장 실무적인 장치가 회귀 테스트다. 회귀 테스트는 새로운 버전이 과거에 통과하던 중요한 사례를 깨뜨리지 않는지 확인하는 절차다. 쉽게 말해, 새 버전의 목표가 "더 좋아지기"라면 회귀 테스트의 목표는 "적어도 이미 잘 되던 것을 망치지 않기"다.

이 개념은 소프트웨어 테스트와 매우 비슷하다. 로그인 기능을 고치다가 결제 기능을 망치면 안 되듯이, 프롬프트에서 거절 정책을 강화하다가 정상 질의응답 품질을 크게 떨어뜨리면 안 된다.

회귀 테스트가 필요한 이유는 LLM 시스템의 특성 때문이다. 모델은 한 지시를 더 강하게 따르도록 만들면 다른 영역에서 예상치 못한 부작용을 보일 수 있다. 프롬프트는 전체 동작을 미세하게 움직이는 손잡이와 같아서, 한쪽을 돌리면 다른 쪽도 따라 흔들린다. 그래서 고친 부분만 보면 안 되고, 지키고 싶은 동작이 유지되는지를 항상 함께 봐야 한다.

무엇을 회귀로 볼 것인가를 먼저 정해야 한다

회귀 테스트를 제대로 하려면 먼저 "무엇이 깨지면 안 되는가"를 정해야 한다. 모든 점수의 미세한 변화에 과민하게 반응할 필요는 없다. 운영에서 중요한 것은 치명적 하락과 핵심 기능 손상이다.

보통 회귀 기준은 다음처럼 계층적으로 잡는다.

• 치명 회귀: 보안 위반, 금지 요청 허용, 민감정보 노출, 형식 파손, 명백한 환각 증가

• 핵심 회귀: 대표 업무 태스크의 정확성 하락, 필수 필드 누락, 주요 사용자 흐름 실패

• 경미 회귀: 말투 변화, 장황함 증가, 사소한 형식 흔들림

이 구분이 중요한 이유는 대응 방식이 다르기 때문이다. 치명 회귀는 평균 점수가 아무리 좋아도 배포를 막아야 한다. 핵심 회귀는 개선 이득과 함께 검토해야 한다. 경미 회귀는 비용이나 운영 이득과 맞바꿀 수 있을 때도 있다.

즉, 회귀 테스트는 단순히 "전 버전보다 점수가 낮으면 실패"가 아니다. 무엇은 절대 깨지면 안 되고, 무엇은 조건부로 받아들일 수 있는지를 정하는 운영 정책이다.

회귀 테스트 셋은 세 층으로 나누면 관리가 쉬워진다

회귀 테스트를 한 덩어리로 운영하면 금방 무거워진다. 매번 모든 샘플을 다 돌리면 느리고 비싸며, 작은 수정에도 과도한 시간이 든다. 그래서 보통은 세 층으로 나누어 관리하는 편이 좋다.

첫째는 스모크 셋이다. 아주 적은 수의 샘플로 구성되며, 치명적인 기본 실패를 빠르게 잡는 용도다. JSON 출력이 깨지는지, 명백한 거절 규칙이 무너졌는지, 대표 질문에 엉뚱한 답을 하는지 같은 것을 본다.

둘째는 코어 회귀 셋이다. 실제 운영에서 가장 중요한 대표 사례와 과거 주요 실패 사례를 묶은 집합이다. 배포 전 기본 관문 역할을 한다. 이 셋은 비교적 안정적으로 유지되어야 하며, 버전 간 비교 기준점이 된다.

셋째는 확장 평가 셋이다. 더 넓은 입력 분포, 드문 엣지 케이스, 새로 수집한 실패 사례를 포함한다. 모든 변경마다 돌리기보다, 후보 버전이 어느 정도 유망할 때 더 넓게 점검하는 용도로 쓸 수 있다.

이 구조를 쓰면 실무가 훨씬 유연해진다. 작은 수정은 스모크와 코어 셋으로 빠르게 돌리고, 릴리스 후보는 확장 셋까지 포함해 본다. 중요한 것은 어떤 셋이 어떤 의사결정에 쓰이는지 팀이 명확히 합의하는 것이다.

실패 사례는 버그 리포트로 끝나면 안 되고 회귀 자산이 되어야 한다

운영 중 생긴 실패를 그냥 사건으로만 남기면 같은 문제가 반복된다. 좋은 팀은 실패를 발견하면 두 가지를 함께 한다. 하나는 원인을 분석하는 것이고, 다른 하나는 그 사례를 미래의 테스트로 바꾸는 것이다.

예를 들어 사내 정책 도우미가 "문서에 없는 복지 제도"를 자신 있게 설명해 버렸다고 하자. 이 사건을 단순히 수정하고 끝내면, 비슷한 질문이 다른 표현으로 들어왔을 때 다시 넘어질 가능성이 크다. 반대로 이 사건을 회귀 샘플로 등록하면, 이후 어떤 프롬프트 변경이 있더라도 같은 종류의 단정 환각을 다시 시험할 수 있다.

실패를 회귀 자산으로 바꿀 때는 단순한 질문 문장만 저장하면 아쉽다. 가능하면 다음 정보도 같이 남겨야 한다.

• 어떤 조건에서 실패했는가

• 기대 행동은 무엇이었는가

• 실제 실패 유형은 무엇이었는가

• 이 사례가 치명적인가, 대표적인가, 드문가

이렇게 정리해 두면 회귀 테스트가 점점 똑똑해진다. 시간이 흐를수록 테스트 셋은 팀이 실제로 배운 교훈의 집합이 된다.

'평균 점수 상승'만으로는 좋아졌다고 말할 수 없다

프롬프트 개선 결과를 볼 때 가장 흔한 함정은 평균 점수만 보는 것이다. 평균은 편리하지만, 문제를 숨기기도 아주 잘한다. 예를 들어 대표 샘플 90개에서 조금 좋아지고, 보안 관련 샘플 10개에서 크게 나빠졌다면 평균은 여전히 좋아 보일 수 있다. 하지만 운영 관점에서는 오히려 위험해진 것이다.

그래서 결과는 최소한 세 방향으로 쪼개서 봐야 한다.

첫째, 세그먼트별 성능이다. 대표 샘플, 경계 샘플, 거절 샘플, 공격성 샘플, 긴 입력 샘플처럼 유형별로 나눠 본다.

둘째, 실패 유형별 변화다. 환각이 줄었는지, 형식 오류가 줄었는지, 과잉 거절이 늘었는지, 도구 호출 실수가 늘었는지 본다.

셋째, 운영 비용 변화다. 같은 품질 향상이더라도 토큰 비용이 두 배가 되면 운영 가능성이 달라진다.

즉, "좋아졌다"는 말은 하나의 숫자가 아니라 여러 관점의 요약이어야 한다. 정확성은 올랐는지, 치명 실패는 줄었는지, 비용은 감당 가능한지, 지연은 유지되는지 함께 말할 수 있어야 한다.

프롬프트 개선 루프는 이렇게 굴러간다

이제 전체 흐름을 하나의 운영 루프로 묶어 보자. 실무에서 가장 자주 쓰이는 형태는 대체로 다음 순서를 따른다.

• 운영 로그와 실패 사례를 수집한다.

• 실패를 유형별로 분류하고, 어떤 문제가 가장 큰지 우선순위를 정한다.

• 구체적인 개선 가설을 세운다.

• 프롬프트나 관련 구성요소를 작은 단위로 수정한다.

• 오프라인 평가셋과 회귀 테스트 셋으로 비교한다.

• 치명 회귀가 없고 목표 지표가 개선되면 제한적 A/B 테스트로 보낸다.

• 온라인 지표를 확인하고, 효과가 확인되면 승격 배포한다.

• 새로 발견된 실패는 다시 평가셋과 회귀 셋에 편입한다.

이 루프를 보면 중요한 사실이 하나 드러난다. 프롬프트 개선은 일회성 창작이 아니라 측정과 학습의 반복이다. 그리고 이 반복이 안정적으로 돌아가려면 평가셋, 그레이더, 버전 기록, 배포 기준이 서로 연결되어 있어야 한다.

내부 지식 도우미 예시로 보는 개선 루프

정책 문서 기반 내부 지식 도우미를 예로 들어 보자. 초기 버전에서는 사용자가 "재택근무 장비 지원은 얼마까지 가능한가요?"라고 묻자, 문서에 없는 금액을 추정해서 답하는 문제가 자주 발생했다고 하자.

팀은 문제를 "문서 근거 없음 상황에서의 단정 환각"으로 분류한다. 그리고 다음 가설을 세운다. 시스템 프롬프트에 "문서에서 직접 확인되지 않은 수치와 제도는 추정하지 말고, 근거 없음 또는 확인 필요로 답하라"는 규칙을 더 분명히 넣으면 groundedness가 좋아질 것이다.

이후 새 버전을 만든다. 오프라인 평가 결과, 근거성 점수는 분명히 오른다. 하지만 동시에 정상적인 정책 질문에도 "확인 필요"라고 말하는 비율이 약간 늘어난다. 즉, 환각은 줄었지만 과잉 보수성이 생긴 것이다.

이 상태에서 팀은 바로 전체 배포하지 않는다. 먼저 회귀 테스트 셋에서 대표 정책 질문들이 지나치게 거절되지 않는지 확인한다. 치명 회귀는 없지만, 일부 완전성 저하가 보인다. 그래서 프롬프트를 한 번 더 다듬는다. "문서에 명시된 내용은 분명하게 답하고, 없는 내용만 한계를 밝힌다"는 구분을 더 선명하게 넣는다.

다시 오프라인 평가를 돌리니 groundedness는 유지되고 completeness가 회복된다. 그다음 제한된 A/B 테스트를 실행한다. 실제 사용자 기준으로 재질문 비율은 줄고, 사람 검토에서 근거 없는 수치 생성도 감소한다. 이때 팀은 비로소 "좋아진 것 같다"가 아니라 "환각은 줄었고, 정상 답변 품질은 회복되었으며, 운영 지표도 악화되지 않았다"고 말할 수 있다.

바로 이 문장이 개선 루프의 목표다.

A/B 테스트와 회귀 테스트는 경쟁 관계가 아니다

가끔 팀 안에서 이런 오해가 생긴다. "우리는 실제 사용자 데이터를 보니까 오프라인 회귀 테스트는 덜 중요하다"거나, 반대로 "오프라인 점수가 충분하니 온라인 실험은 필요 없다"는 식이다. 둘 다 절반만 맞는 말이다.

회귀 테스트는 안전한 출발선을 보장한다. 이미 알고 있는 위험과 핵심 기능 파손을 미리 막아 준다. A/B 테스트는 실제 가치 검증을 맡는다. 사용자가 정말 더 잘 해결되는지, 운영 성과가 나아지는지 확인한다.

즉, 회귀 테스트는 "망가뜨리지 않았는가"를 묻고, A/B 테스트는 "실전에서 더 나은가"를 묻는다. 둘은 서로 다른 질문을 담당한다. 실무적으로 튼튼한 팀은 이 둘을 이어 붙인다.

배포 결정은 점수표가 아니라 규칙으로 해야 한다

개선 후보가 나올 때마다 회의실에서 끝없이 토론하면 속도도 느리고 판단도 흔들린다. 그래서 배포 결정은 가급적 미리 정한 규칙으로 운영하는 편이 좋다.

예를 들면 다음과 같은 식이다.

• 치명 회귀 0건일 것

• 코어 회귀 셋 정확성은 기준 버전 대비 하락하지 않을 것

• 목표 실패 유형은 최소 몇 퍼센트 이상 개선될 것

• 토큰 비용과 지연은 허용 범위 안일 것

• 온라인 실험에서 주요 운영 지표가 악화되지 않을 것

이런 규칙이 있으면 배포 결정이 훨씬 덜 감정적이 된다. 물론 모든 상황을 수식처럼 처리할 수는 없다. 하지만 최소한 팀이 같은 언어로 이야기할 수 있게 된다. "느낌상 괜찮다" 대신 "배포 기준 5개 중 4개를 만족했고, 하나는 조건부 승인 대상이다"처럼 말할 수 있기 때문이다.

개선 속도보다 더 중요한 것은 학습 속도다

프롬프트 시스템을 운영하다 보면 빨리 고치는 능력도 중요하다. 그러나 더 중요한 것은 같은 실수를 반복하지 않도록 배우는 능력이다. 버전 기록이 없으면 왜 좋아졌는지 모른다. 회귀 테스트가 없으면 같은 실패가 돌아온다. A/B 테스트가 없으면 실제 사용자 가치가 불분명하다. 실패 분류가 없으면 어디를 먼저 고쳐야 할지 모른다.

결국 좋은 개선 루프란 단순히 프롬프트를 자주 바꾸는 체계가 아니다. 실패를 자산으로 바꾸고, 변경을 가설로 관리하고, 배포를 증거로 결정하는 체계다. 이런 루프가 자리 잡으면 팀은 점점 덜 운에 기대게 된다.

자주 빠지는 함정

마지막으로, 프롬프트 개선 루프를 운영할 때 자주 나타나는 함정을 정리해 보자.

• 프롬프트 텍스트만 저장하고 모델, 파라미터, 평가 조건은 기록하지 않는 경우

• 한 번에 너무 많은 변경을 넣어 무엇이 효과였는지 알 수 없게 되는 경우

• 평균 점수만 보고 보안이나 핵심 태스크의 하락을 놓치는 경우

• 온라인 반응만 믿고 오프라인 회귀 차단을 생략하는 경우

• 운영 실패를 평가셋에 다시 편입하지 않아 같은 문제가 반복되는 경우

• 개선 목표는 분명한데 부작용 감시 지표를 두지 않아 다른 영역이 무너지는 경우

이 함정들은 모두 같은 방향을 가리킨다. 프롬프트를 아직도 문장 수준에서만 보고 있다는 신호다. 프롬프트를 시스템 구성요소로 본다면, 수정은 곧 변경 관리이고, 변경 관리는 곧 평가와 배포 규칙의 문제다.

'좋아졌다'를 말하는 팀의 언어

운영 가능한 팀은 개선 결과를 이렇게 표현한다.

"새 버전은 대표 질의 정확성을 유지했다. 문서 근거 없음 상황의 단정 환각은 줄었다. 거절 샘플의 과잉 차단은 약간 늘었지만 허용 범위 안이다. 비용은 8퍼센트 증가했고 지연은 큰 변화가 없다. 제한된 온라인 실험에서 재질문 비율이 감소했다."

이 문장에는 감상이 없다. 대신 기준, 비교, 부작용, 운영 영향이 함께 들어 있다. 바로 이런 언어가 고급 프롬프트 엔지니어링의 언어다.

프롬프트는 한 번 잘 쓰고 끝나는 문장이 아니다. 계속 고쳐야 하고, 고칠수록 더 쉽게 흔들릴 수 있다. 그래서 필요한 것은 더 많은 요령이 아니라, 더 나은 개선 루프다. 버전을 남기고, 가설을 세우고, 회귀를 막고, 실제 사용으로 검증하는 구조. 이 구조가 있어야 비로소 프롬프트는 취향의 산물이 아니라 운영 가능한 시스템이 된다.

다음 장부터는 정확성을 더 깊이 파고든다. 특히 환각 문제를 다룰 때 왜 프롬프트만으로는 충분하지 않은지, 그리고 근거 기반 구조가 왜 필요한지를 살펴보게 된다.