AI 프롬프트는 한 번 정하면 끝일까? 고정된 프롬프트보다 반복 검증이 중요한 이유

생성형 AI를 업무에 도입할 때 많은 사람이 가장 먼저 고민하는 것은 프롬프트다.

 

어떤 역할을 부여할지, 어떤 형식으로 답변하도록 요구할지, 반드시 포함해야 할 조건은 무엇인지 세밀하게 작성한다. 충분히 잘 만든 프롬프트라면 앞으로도 안정적인 결과를 얻을 수 있을 것이라고 기대하기도 한다.

 

그러나 실제로 LLM을 사용해 보면 프롬프트를 고정했다고 해서 결과까지 고정되지는 않는다.

 

동일한 프롬프트를 사용하더라도 모델이나 실행 환경이 달라지면 출력이 달라질 수 있다. 따라서 프롬프트를 한 번 작성하고 끝내는 방식보다, 결과를 지속적으로 검증하고 수정하는 반복 과정이 더 중요하다.

 

프롬프트를 고정해도 출력은 고정되지 않는다

LLM은 일반적인 프로그램처럼 정해진 명령을 항상 동일한 결과로 반환하는 시스템이 아니다.

전통적인 프로그램은 같은 입력과 같은 실행 조건이 주어지면 대체로 같은 결과를 반환한다.

입력값 + 프로그램 로직 = 예측 가능한 결과

 

반면 LLM은 입력된 문맥을 바탕으로 다음에 이어질 토큰의 확률을 계산하고, 그중 적절한 토큰을 선택하면서 응답을 생성한다.

프롬프트
→ 토큰별 확률 계산
→ 다음 토큰 선택
→ 다시 확률 계산
→ 응답 완성

따라서 프롬프트가 같더라도 생성 조건에 따라 표현, 구성, 설명의 깊이 또는 결론이 달라질 수 있다.

 

예를 들어 다음과 같은 동일한 요청을 여러 번 실행한다고 가정해 보자.

다음 시스템의 보안 위험을 분석하고 개선 방안을 제시하라.

 

한 번은 접근통제 문제를 중심으로 설명할 수 있고, 다른 실행에서는 데이터 유출이나 입력값 검증 문제를 더 중요하게 다룰 수 있다.

프롬프트는 같지만 모델이 응답을 생성하는 과정에서 선택되는 토큰의 흐름이 달라질 수 있기 때문이다.

새로운 모델이 나오면 기존 프롬프트의 효과도 달라질 수 있다

같은 모델에서도 출력이 달라질 수 있지만, 모델 자체가 변경되면 차이는 더 커질 수 있다.

새로운 모델은 기존 모델과 학습된 파라미터가 다르다. 학습 데이터, 학습 방법, 모델 구조, 정렬 방식, 토크나이저, 안전 정책 등도 달라질 수 있다.

 

이 때문에 동일한 단어나 지시문이라도 모델 내부에서 처리되는 방식이 달라진다.

 

다만 이를 단순히 “단어마다 고정된 가중치가 존재하고 그 값이 바뀐다”고 이해하는 것은 정확하지 않다.

 

모델에는 특정 단어에 하나의 중요도 값만 저장되어 있는 것이 아니다. 입력된 단어는 토큰으로 분리되고, 임베딩과 여러 계층의 계산을 거치며 현재 문맥에 맞는 내부 표현으로 변환된다.

 

같은 단어라도 주변 문장에 따라 의미와 영향력이 달라진다.

보안 정책을 우회한다.
도로를 우회한다.
질문에 직접 답하지 않고 우회한다.

 

세 문장에서 사용된 ‘우회’는 같은 표현이지만 문맥에 따라 모델이 해석해야 하는 의미는 다르다.

 

새 모델이 출시되면 이러한 문맥 처리에 사용되는 전체 모델 가중치가 달라지므로, 같은 프롬프트에 대한 반응도 달라질 수 있다.

프롬프트는 모델과 분리된 독립적인 규칙이 아니다

프롬프트를 프로그램의 소스코드처럼 생각하면 다음과 같은 기대를 하게 된다.

좋은 프롬프트를 만든다.
→ 프롬프트를 고정한다.
→ 언제나 일정한 품질의 결과를 얻는다.

 

하지만 실제 LLM 시스템에서 프롬프트는 모델과 분리된 독립적인 규칙이 아니다.

 

프롬프트의 효과는 다음과 같은 요소의 영향을 함께 받는다.

• 사용하는 모델과 모델 버전
• 시스템 프롬프트
• 이전 대화와 현재 문맥
• 입력 데이터의 길이와 구조
• temperature, top-p, seed 등의 생성 설정
• 외부 검색이나 도구 호출 결과
• 서비스 제공자가 적용한 안전 정책
• 출력 길이와 컨텍스트 제한

즉, 프롬프트를 고정하는 것은 전체 실행 환경 중 하나의 요소만 고정하는 것이다.

 

모델이 바뀌거나 시스템 지침이 변경되면 기존 프롬프트가 이전과 같은 품질을 제공하지 못할 수 있다.

프롬프트는 정답이 아니라 가설에 가깝다

프롬프트를 작성할 때는 원하는 결과가 나올 것이라는 가정을 세운다.

 

예를 들어 다음과 같은 프롬프트를 만들 수 있다.

보안 전문가의 관점에서 다음 구성의 취약점을 분석하라.
각 취약점에 대해 위험도, 공격 가능성, 대응 방안을 작성하라.
확인할 수 없는 내용은 추측하지 말고 확인이 필요하다고 표시하라.

이 프롬프트는 작성자가 기대하는 동작을 설명한다.

그러나 실제로 다음 조건을 만족하는지는 실행을 통해 확인해야 한다.

• 주요 취약점을 빠짐없이 찾았는가
• 위험도를 일관되게 판단했는가
• 근거가 없는 내용을 생성하지 않았는가
• 대응 방안이 구체적인가
• 출력 형식을 준수했는가
• 입력 데이터가 달라져도 품질을 유지하는가

따라서 프롬프트는 완성된 정답이라기보다 검증해야 할 가설에 가깝다.

프롬프트 작성
→ 결과 생성
→ 기대한 동작과 비교
→ 문제점 확인
→ 프롬프트 수정

한 번의 프롬프트보다 반복 루프가 중요하다

AI 결과를 고도화하려면 프롬프트를 한 번 실행하는 것으로 끝내지 않아야 한다.

보다 현실적인 방식은 생성, 평가, 수정, 재실행을 반복하는 것이다.

요청 정의
→ 초안 생성
→ 결과 검토
→ 오류와 누락 확인
→ 보완 요청
→ 수정된 결과 생성
→ 최종 검증

예를 들어 AI에게 기술 문서를 작성하게 했다면 첫 번째 결과를 바로 사용하기보다 다음과 같은 검토 단계를 추가할 수 있다.

1. 요구사항이 모두 반영되었는지 확인한다.
2. 기술적으로 잘못된 내용이 있는지 검사한다.
3. 중복되거나 불필요한 설명을 제거한다.
4. 누락된 항목을 다시 요청한다.
5. 코드나 명령어를 실제 환경에서 테스트한다.
6. 최종 결과를 사람이 검수한다.

이러한 반복 과정은 단순히 문장을 여러 번 고치는 것이 아니다.

LLM의 확률적인 출력을 실제 업무에 사용할 수 있는 수준으로 통제하는 품질관리 과정이다.

반복하면 무조건 정답에 가까워지는 것은 아니다

반복 과정이 중요하다고 해서 같은 모델에게 계속 질문하면 자동으로 정답에 도달하는 것은 아니다.

LLM은 초기 응답에서 잘못된 전제를 만들 수 있다. 이후 그 전제를 바탕으로 검토를 요청하면 잘못된 내용을 수정하는 대신 더 정교한 근거를 붙일 수도 있다.

잘못된 초안
→ 동일한 전제를 기반으로 검토
→ 잘못된 설명을 보강
→ 더 그럴듯한 오답 생성

따라서 반복 루프에는 단순한 재질문뿐 아니라 독립적인 검증 수단이 포함되어야 한다.

계산 결과는 계산기나 코드로 검증해야 하고, 기술적인 사실은 공식 문서와 비교해야 한다. 코드라면 실제 테스트를 실행해야 하며, 정형화된 출력은 스키마 검증을 적용할 수 있다.

LLM 결과
   ├─ 사실 확인 → 공식 문서·검색·RAG
   ├─ 계산 확인 → Python·계산기
   ├─ 코드 확인 → 테스트·정적 분석
   ├─ 형식 확인 → JSON Schema
   └─ 최종 판단 → 사람의 검수

LLM에게 작성과 검토를 모두 맡길 수는 있지만, 중요한 결과까지 LLM의 판단만으로 확정해서는 안 된다.

사람의 역할은 단순한 승인자가 아니다

반복적인 AI 활용 과정에서 사람은 마지막에 결과를 승인하는 역할만 수행하지 않는다.

사람은 AI가 무엇을 잘못했는지 판단하고, 다음 실행에서 어떤 부분을 보완해야 하는지 결정한다.

 

예를 들어 AI가 작성한 보안 분석에서 중요한 접근통제 문제가 누락되었다면 다음과 같이 구체적으로 다시 요청할 수 있다.

이전 분석에서는 인증과 입력값 검증을 다뤘지만,
사용자별 권한 분리와 리소스 소유권 검증이 빠졌다.

다음 항목을 추가로 분석하라.

1. 다른 사용자의 리소스에 접근할 가능성
2. 객체 식별자를 변경했을 때의 권한 검증
3. 관리자 기능의 서버 측 접근통제
4. 각 문제에 대한 검증 방법과 대응 방안

 

이 과정에서 사람은 단순히 “다시 작성해 달라”고 요청하는 것이 아니다.

누락된 영역을 판단하고, 부족한 부분을 정확하게 지정하며, 검증 가능한 형태로 다시 실행하도록 유도한다.

 

이러한 사람의 개입이 반복될수록 결과는 실제 요구사항에 가까워진다.

프롬프트 엔지니어링에서 평가 엔지니어링으로

초기 생성형 AI 활용에서는 좋은 프롬프트를 만드는 기술이 강조되었다.

 

물론 프롬프트의 품질은 여전히 중요하다. 역할, 요구사항, 출력 형식, 제한 조건을 명확하게 작성하면 응답 품질을 높일 수 있다.

 

그러나 실제 운영 단계에서는 프롬프트 자체보다 프롬프트를 어떻게 평가하고 관리하는지가 더 중요해진다.

프롬프트 작성
→ 테스트 데이터 준비
→ 결과 측정
→ 실패 유형 분류
→ 프롬프트와 워크플로 수정
→ 회귀 테스트

 

이를 평가 엔지니어링 관점에서 보면 다음과 같은 질문이 필요하다.

• 정확성을 어떤 기준으로 평가할 것인가
• 누락 여부는 어떻게 측정할 것인가
• 허용할 수 없는 오류는 무엇인가
• 모델이 변경되었을 때 기존 품질을 유지하는가
• 어떤 결과부터 사람의 승인이 필요한가
• 실패한 결과를 다음 개선 과정에 어떻게 반영할 것인가

결국 중요한 것은 가장 화려한 프롬프트를 만드는 것이 아니다.

 

AI 결과가 요구한 기준을 충족하는지 지속적으로 확인할 수 있는 체계를 만드는 것이다.

 

프롬프트도 소프트웨어처럼 버전 관리해야 한다

프롬프트를 업무에 사용한다면 단순한 텍스트 파일이 아니라 시스템 구성요소로 관리하는 것이 좋다.

 

최소한 다음 항목을 함께 기록할 필요가 있다.

model: example-model-v2
prompt-version: 1.4
temperature: 0.2
top-p: 0.9
system-prompt-version: 2.1
evaluation-dataset: security-review-v3
updated-at: 2026-07-17

 

프롬프트만 저장하면 동일한 환경을 재현하기 어렵다.

 

어떤 모델과 파라미터를 사용했는지, 어떤 테스트 데이터로 평가했는지, 이전 버전보다 무엇이 개선되었는지를 함께 관리해야 한다.

 

특히 모델을 변경할 때는 기존 테스트 데이터를 사용해 회귀 테스트를 수행해야 한다.

기존 모델 + 프롬프트
→ 기준 성능 측정

새 모델 + 기존 프롬프트
→ 동일한 평가셋으로 비교

성능 저하 또는 동작 변화 확인
→ 프롬프트와 워크플로 수정

 

새 모델이 더 높은 성능을 가진다고 해서 기존 프롬프트에서도 항상 더 좋은 결과를 제공하는 것은 아니다.

 

모델의 지시문 해석 방식과 출력 성향이 달라지면 기존에 잘 작동하던 표현이 오히려 불필요하거나 부정적인 영향을 줄 수도 있다.

고정해야 하는 것은 프롬프트가 아니라 품질 기준이다

프롬프트를 지속적으로 수정해야 한다고 해서 매번 즉흥적으로 작성해야 한다는 뜻은 아니다.

 

기본 프롬프트는 표준화하고 버전 관리해야 한다. 다만 그 프롬프트를 영구적으로 변하지 않는 정답으로 간주해서는 안 된다.

고정해야 할 것은 프롬프트 문장 자체보다 결과가 충족해야 하는 품질 기준이다.

 

예를 들면 다음과 같다.

• 사실과 추측을 구분할 것
• 확인할 수 없는 내용은 명시할 것
• 필수 항목을 누락하지 않을 것
• 지정된 출력 형식을 준수할 것
• 보안상 위험한 동작은 사람의 승인을 받을 것
• 기술적인 주장은 검증 가능한 근거를 제시할 것

이러한 기준을 먼저 정의하고, 현재 사용하는 모델과 업무에 맞게 프롬프트와 실행 절차를 계속 조정하는 방식이 적절하다.

 

결론

프롬프트를 고정한다고 해서 AI의 출력까지 고정되는 것은 아니다.

 

같은 모델에서도 생성 조건에 따라 결과가 달라질 수 있으며, 새로운 모델이 출시되면 학습된 가중치와 문맥 처리 특성이 변경되기 때문에 기존 프롬프트의 효과도 달라질 수 있다.

 

따라서 생성형 AI를 안정적으로 활용하려면 한 번 잘 작성한 프롬프트에 의존해서는 안 된다.

 

기본 프롬프트를 표준화하되, 실제 결과를 지속적으로 검증하고 부족한 부분을 다시 요청하며 모델과 환경 변화에 맞춰 수정해야 한다.

 

결국 AI 활용의 품질을 결정하는 것은 하나의 완벽한 프롬프트가 아니다.

프롬프트
→ 생성
→ 평가
→ 검증
→ 수정
→ 재실행
→ 사람의 최종 판단

 

이러한 반복 구조가 AI 결과를 더 정확하고 완전한 형태로 발전시킨다.

프롬프트는 정답이 아니라 출발점이다.

그리고 AI의 품질은 프롬프트를 고정하는 순간이 아니라, 결과를 끊임없이 검증하고 개선하는 과정에서 만들어진다.