4.8 결정론적 출력을 위한 제약 조건(Constraints) 명시 기법

아무리 뛰어난 페르소나를 부여하고 완벽한 시스템 프롬프트를 작성했더라도, LLM은 본질적으로 통계적 다음 단어 예측기(Next-Token Predictor)에 불과하다. 이들은 질문을 받으면 가장 확률이 높은 답변의 꼬리를 무는 방식으로 문장을 생성하며, 이 과정에서 개발자가 의도하지 않은(혹은 오라클 검증 파이프라인을 망가뜨리는) 부가적인 설명, 친절한 인사말, 혹은 형식에 어긋난 출력물을 덧붙이려는 강한 내재적 편향(Alignment Bias)을 지닌다.

결정론적 오라클을 구축하기 위해서는, 모델의 출력 범위를 칼로 벤 듯 정확하게 재단하는 ‘강제적 제약 조건(Hard Constraints)’ 명시 기법이 프롬프트 엔지니어링의 핵심으로 자리 잡아야 한다.

1. 부정문(“하지 마라”)보다 긍정문(“해라”)을 통한 범위 한정

모델에게 특정한 행동을 금지하려 할 때, 초보적인 프롬프트 엔지니어들은 흔히 부정문을 남발한다. “절대 인삿말을 추가하지 마세요.”, “마크다운을 사용하지 마세요.“와 같은 지시가 대표적이다.

그러나 LLM의 어텐션(Attention) 메커니즘 특성상, 부정문 내에 포함된 금지어(예: ‘인삿말’, ‘마크다운’) 토큰 그 자체에 가중치가 부여되면서 오히려 해당 금지된 행동을 유발하는 역효과(Pink Elephant Problem)가 자주 발생한다. 완전한 결정론적 제어를 위해서는 “무엇을 하지 말 것인지“보다 **“정확히 무엇만 해야 하는지”**를 긍정문으로 백리스팅(Whitelisting) 해야 한다.

• 나쁜 예 (부정 제약): 부가적인 설명을 하지 마라. 오직 정답만 출력하라.
• 좋은 예 (긍정 치환 및 포맷 제약): 당신의 전체 응답은 오직 단일한 JSON 객체 하나로만 구성되어야 한다. 그 외의 어떠한 문자열도 출력의 앞이나 뒤에 포함되어서는 안 된다.

2. 폐쇄형 구조(Closed-Ended Structure)와 열거형(Enum) 제한

오라클이 코딩된 파이프라인에서 응답을 파싱(Parsing)할 때 자유 문장 형태의 자연어 응답은 최악의 적이다. 출력의 텍스트가 조금만 달라져도 정규식 검사기나 문자열 비교(String Matching) 로직이 실패하기 때문이다.

따라서 프롬프트 단계에서 모델이 선택할 수 있는 답변의 풀(Pool)을 객관식 보기 형태로 극단적으로 제한하여 무결성을 확보해야 한다. 답변의 범위를 특정한 열거형(Enum) 리스트로 강제하는 것이 결정론 달성의 열쇠다.

• 적용 예시 (분류 오라클 프롬프트):

다음 제공된 사용자 피드백 문서의 감정을 분석하라.
당신의 출력은 반드시 다음 세 가지 문자열 중 하나와 정확히 일치해야 한다: [“POSITIVE”, “NEGATIVE”, “NEUTRAL”].
이 배열에 명시된 문자 외에는 어떠한 구두점(.), 따옴표(“), 줄바꿈(\n)도 허용되지 않는다.

3. 구조적 마커(Structural Markers)와 XML 태그 강제

긴 응답이나 복잡한 추론 과정이 필요한 경우, 오라클 파서(Parser)가 최종 결과물만을 정확히 추출할 수 있도록 응답의 구조를 물리적인 태그로 구획화(Compartmentalization)해야 한다.
최근의 언어 모델들은 마크다운(Markdown)보다 XML 방식의 태그 구획화를 인식하고 분리하는 데 훨씬 강력한 성능을 보인다. 프롬프트 내에 사고 과정(CoT)의 영역과 최종 정답의 영역을 명시적으로 나누어 제약하라.

• 적용 예시 (태그 기반 제약):

문제 해결에 필요한 모든 논리적 사고 과정과 계산은 <scratchpad> 태그 안에 작성하라.
오토메이션 스크립트가 파싱할 최종적인 Python 코드 결과물은 반드시 <final_code> 태그 안에만 위치해야 한다.
<final_code> 태그 내부에는 실행 가능한 Python 코드 외의 어떠한 자연어 설명도 기재해서는 안 된다.

이처럼 출력의 경계를 명시적으로 제약하고 통제하는 기법이야말로, 비결정적 블랙박스인 LLM을 결정론적인 파이프라인의 핵심 부품(Component)으로 길들이는 유일하고도 확실한 공학적 접근이다.