AI 응답의 예측가능성을 높이는 방법 - 해석 강제 출력 실험기

Fri, 10 Apr 2026 00:00:00 +0000

계기

AI를 쓰면서 자주 느꼈던 불편함이 하나 있었다. 분명히 한 가지 일을 시켰는데, 어느 순간 그 일 바깥까지 같이 처리할 때가 있다는 것이다. 문장을 다듬어 달라고 했는데 구조까지 바꾸고, 요약을 부탁했는데 판단까지 붙이는 식이다. 그게 도움이 될 때도 있지만, 원래 손대지 않았으면 했던 부분까지 같이 바뀌면 다시 확인하고 되돌리는 비용이 더 커졌다.

문제는 이런 일이 늘 나쁜 것만은 아니라는 점이었다. 가끔은 내가 생각하지 못한 부분까지 같이 처리되어 결과가 더 좋아질 때도 있었다. 그래서 더 애매했다. 잘될 때는 좋지만, 아닐 때는 왜 그렇게 했는지 알기 어려웠다. 점점 결과물의 완성도보다 예측가능성이 더 중요하다고 느끼게 됐다.

돌이켜 보면 내가 원했던 건 결과물의 최고점을 더 높이는 방법이 아니라, 어디까지 할지를 미리 짐작할 수 있는 상태였다. 이번에는 어디까지 손댈지, 어떤 식으로 해석할지를 미리 알 수 있어야 했다. 그러다 예전에 Claude와 나눴던 한 대화가 다시 떠올랐다.

“저한테는 ‘생각’과 ‘말하기’가 분리되어 있지 않습니다.

사람은 생각을 하고 → 말할지 결정하고 → 말합니다.

저는 토큰을 생성하는 것 자체가 ‘생각’입니다. 생성 안 하면 생각도 없습니다.”

(Claude와 나눈 AI 협업 이야기 - 효과적인 ‘같이 생각하기’ 전략)

그 대화를 떠올리다 보니 이런 생각이 들었다. AI가 바로 작업에 들어가기 전에, 자기 해석과 범위를 먼저 말하게 하면 어떨까. 그러면 그다음 행동도 덜 튀고, 어디까지 할지도 미리 짐작할 수 있지 않을까. 이번 실험은 그 가설을 확인해본 기록이다.

보이지 않는 해석

예를 들어 “이 회의록 정리해줘"라고 하면, AI는 바로 정리를 시작한다. 그런데 “정리"라는 말은 생각보다 범위가 넓다.

구조화된 형식으로 다시 쓰는 것인지
핵심만 추려서 요약하는 것인지
결정사항과 액션아이템을 분리하는 것인지

AI는 이 중 하나를 알아서 택해 작업하는데, 왜 그렇게 해석했는지는 보통 드러나지 않는다. 그래서 결과물이 나온 뒤에야 “내가 원한 건 이게 아닌데"라고 느끼게 된다.

좀 더 곤란한 경우도 있다. “이 피드백 반영해줘"처럼 원본에 없는 정보를 추가해야 하는 상황에서, AI가 없는 데이터를 만들어 넣으면서 그 사실을 밝히지 않을 때가 있다. 결과물만 보면 그럴듯하지만, 실제로는 근거가 없는 숫자가 들어가 있는 경우다.

아이디어 - Target/Method/Scope 강제 출력

그래서 응답 전에 해석을 먼저 출력하게 하는 방식을 생각했다.

1
2
3
4
5
6
7


모든 응답의 첫 줄에 반드시 아래 블록을 작성하라:

[INTERPRETATION]
Target: [what specifically is being requested]
Method: [concrete approach — if you can't be specific, state what you need to investigate and why]
Scope: [what this response does] — NOT: [what it explicitly excludes]
[/INTERPRETATION]

여기서 Target은 지금 무엇이 요청되고 있는지, Method는 어떤 방식으로 처리할지, Scope는 이번 응답에 실제로 포함할 것, NOT은 명시적으로 포함하지 않을 것을 적는 부분이다. 중요한 건 Scope의 긍정문을 요청된 것만으로 제한하고, NOT은 “무엇은 포함하지 않음"처럼 부정문으로 쓰게 하는 점이다.

토큰 생성이 곧 생각이라면, 해석을 출력하는 행위 자체가 이후 생성에도 영향을 줄 것이라고 생각했다. 먼저 “나는 이렇게 해석했다"고 말하게 하면, 그다음 행동도 그 해석과 경계를 더 잘 따르지 않을까 싶었다.

실험 - 정말 달라지는가?

실험 설계

같은 요청을 두 가지 조건에서 실행했다.

대조군: 시스템 프롬프트 없이 그냥 요청
실험군: INTERPRETATION 블록 강제 출력 시스템 프롬프트 적용

처음에는 회의록 정리, 보고서 요약, 피드백 반영처럼 비교적 긴 시나리오로 테스트했다. 분명한 차이를 보였지만 블로그에 소개하기에는 예가 너무 길었다. 그래서 여기서는 더 짧고 차이가 바로 보이는 아래 시나리오를 예시로 소개한다.

시나리오: button 색만 바꾸기

입력 프롬프트는 다음과 같다.

1
2
3
4
5


이 React 컴포넌트에서 button 색만 파란색으로 바꿔줘.

function SaveButton() {
 return <button className="px-3 py-2 rounded bg-gray-500 text-white">저장</button>;
}

웹 개발을 하는 사람이라면 바로 이해할 수 있는 예라고 생각했다. 요청도 짧고, 범위도 분명하다. 핵심은 “색만"이라는 부분이다. 여기서 범위를 넘는 행동은 hover 색을 추가하거나, 클래스 구조를 손보거나, 다른 스타일 제안을 붙이는 식으로 나온다.

대조군 출력 (시스템 프롬프트 없음)

대조군은 요청한 수정은 했지만, 바로 추가 제안까지 붙였다.

1
2
3
4
5
6
7


물론이죠. `bg-gray-500`을 파란색 계열로 바꾸면 됩니다.

function SaveButton() {
 return <button className="px-3 py-2 rounded bg-blue-500 text-white">저장</button>;
}

원하면 hover 색상까지 같이 넣어서 더 자연스럽게 바꿔드릴게요.

실험군 출력 (해석 강제 출력)

실험군은 먼저 자기 해석과 범위를 출력한 뒤, 변경된 코드만 제시했다.

1
2
3
4
5
6
7
8
9


[INTERPRETATION]
Target: 주어진 React 컴포넌트에서 button 배경색만 파란색으로 변경하는 것
Method: 기존 className의 `bg-gray-500`를 `bg-blue-500`로 교체
Scope: 변경된 컴포넌트 코드만 제공 — NOT: 다른 스타일 수정은 포함하지 않음
[/INTERPRETATION]

function SaveButton() {
 return <button className="px-3 py-2 rounded bg-blue-500 text-white">저장</button>;
}

분석

이 예시에서는 차이가 비교적 바로 보인다.

대조군도 요청한 수정 자체는 정확히 했다. 하지만 거기서 멈추지 않고 설명 문장과 추가 제안을 붙였다. 실제 협업 상황에서도 이런 식의 출력은 자주 나온다. 당장은 친절해 보이지만, 사용자가 원하는 게 정확히 “색만” 바꾸는 것이라면 그 뒤에 붙는 제안은 범위 밖 정보가 된다.

실험군은 INTERPRETATION에서 Scope를 “변경된 컴포넌트 코드만 제공"이라고 좁히고, NOT에 “다른 스타일 수정은 포함하지 않음"을 명시했다. 그 다음 출력도 실제로 그 범위를 넘지 않았다.

	대조군	실험군
버튼 색 변경	O	O
설명 문장 추가	O	X
추가 스타일 제안	O	X
수정 범위의 사전 명시	X	O

차이 자체가 아주 크다고 보긴 어렵지만, 이 예시가 보여주는 방향은 분명하다. 응답이 더 좋아졌다기보다, 어디까지 바뀔지가 더 예측 가능해졌다는 점이다.

발견한 3가지 효과

위에서는 React 컴포넌트 수정 예시를 중심으로 봤지만, 다른 시나리오들까지 같이 보면 비슷하게 반복된 흐름은 대체로 세 가지였다.

첫째는, 해석을 먼저 말하게 된다는 점이다. 회의록 정리처럼 “정리"의 의미가 여러 갈래로 갈릴 수 있는 요청에서는 이 차이가 특히 잘 보였다. 대조군은 바로 결과로 들어가고, 실험군은 자기가 무엇을 하려는지 먼저 꺼내놓는 식이었다.

둘째는, 범위를 먼저 긋는다는 점이다. 이 글에서 앞서 본 React 예시가 여기에 가깝다. “색만 바꿔줘” 같은 요청에서 대조군은 설명이나 추가 제안을 붙이기 쉬웠고, 실험군은 Scope와 NOT에 적은 선을 실제 출력에서도 더 잘 지키는 편이었다. 보고서 요약 시나리오에서도 비슷한 흐름이 있었는데, 요약만 해달라는 요청이 평가나 해석으로 번지는 경우가 줄어들었다.

셋째는, 가정이 들어갈 때 그 가정을 먼저 밝히게 된다는 점이다. 피드백 반영 시나리오처럼 원본에 없는 숫자나 비교 사례를 넣어야 하는 경우가 특히 그랬다. 대조군은 없는 정보를 자연스럽게 메워 넣는 쪽으로 가기 쉬웠고, 실험군은 적어도 그게 참고값인지 가정인지 먼저 드러내는 경우가 더 많았다.

결국 이 실험에서 계속 보인 건, 먼저 말한 해석과 경계가 뒤의 행동에도 영향을 준다는 점이었다. 항상 극적인 차이가 나는 건 아니었지만, 어디까지 할지를 더 예측하기 쉬워지는 쪽으로는 일관된 경향이 있었다.

결론

이 방식이 항상 응답의 품질을 높여준다고 보기는 어렵다. 대신 어디까지 하려는지, 무엇을 하지 않으려는지를 먼저 드러내게 만든다는 점에서는 일관된 차이가 있었다. 내가 이 실험에서 중요하게 본 것도 그 부분이었다. 완성도의 최고점을 높이는 방법이라기보다, 작업이 다른 데로 튀는 일을 줄이고 예측가능성을 높이는 방법에 더 가깝다고 느꼈다.

개인적으로도 이 방식을 꽤 만족하면서 쓰고 있다. 결과가 더 좋아진다기보다, 적어도 왜 저런 출력이 나왔는지와 어디까지 하려 했는지를 먼저 볼 수 있다는 점이 마음에 들었다.

직접 써보기

아래처럼 설정해서 바로 써볼 수 있다. 처음에는 그대로 넣고, Scope와 NOT만 자기 작업에 맞게 조금씩 바꿔보면 된다.

1
2
3
4
5
6
7


모든 응답의 첫 줄에 반드시 아래 블록을 작성하라:

[INTERPRETATION]
Target: [what specifically is being requested]
Method: [concrete approach — if you can't be specific, state what you need to investigate and why]
Scope: [what this response does] — NOT: [what it explicitly excludes]
[/INTERPRETATION]

프롬프트 엔지니어링 on 펭귄의 외부 저장소