프롬프트를 늘리지 마라: 실패해도 닫히는 공학적 경계를 설계하라

많은 엔지니어링 팀들이 LLM을 도입할 때 가장 흔히 범하는 실수는 **“원하는 출력이 나오지 않을 때 시스템 프롬프트(Prompt)에 더 긴 지시문과 제약조건을 덧붙이는 것”**입니다.

“절대 거짓말하지 마세요."
"다음 규칙을 어기면 큰 페널티를 받습니다."
"반드시 지정된 JSON 포맷으로만 응답해야 합니다.”

하지만 안타깝게도, 프롬프트가 길어질수록 모델의 주의 집중도(Attention)는 분산되며, 복잡한 엣지 케이스나 의도적인 탈옥(Jailbreak) 프롬프트 앞에서 지시문은 모래성처럼 허물어집니다.

1. 프롬프트는 안전장치가 될 수 없다

LLM은 근본적으로 확률론적 다음 토큰 예측기(Stochastic Next-Token Predictor)입니다. 아무리 정교하게 프롬프트를 작성해도, 모델이 특정 조건에서 규칙을 어길 확률을 수학적으로 0%로 만들 수는 없습니다.

결과가 조금 틀려도 괜찮은 B2C 챗봇이라면 프롬프트 엔지니어링으로 충분할지 모릅니다. 하지만 단 한 번의 오류가 금융 손실, 보안 유출, 서비스 장애로 직결되는 B2B 엔터프라이즈 환경에서는 확률에 비즈니스를 걸 수 없습니다.

엔터프라이즈 AI 도입의 본질은 **“모델을 신뢰하는 것”**이 아니라, **“모델이 언제든 실패할 수 있음을 전제하고, 실패했을 때 시스템이 안전하게 닫히는(Fail-Closed) 물리적 경계를 설계하는 것”**입니다.

2. BOUNDAXE의 3대 공학 원칙

BOUNDAXE는 프롬프트의 길이를 늘리는 대신, 시스템의 구조적 경계를 다음 세 가지 원칙으로 고정합니다.

flowchart LR
    A["자연어 요청<br/>(User Input)"] --> B["1. CONTRACT<br/>생성 계약 (Schema)"]
    B --> C["2. EVIDENCE<br/>근거 게이트 (Audit)"]
    C --> D["3. HARNESS<br/>실행 하네스 (TDD)"]
    D --> E["신뢰할 수 있는<br/>비즈니스 산출물"]

1) CONTRACT (생성 계약)

모델에게 자유로운 텍스트 서술이나 코드를 생성하도록 두지 않습니다.
OpenAI Structured Outputs(strict: true)와 Zod 스키마를 통해 모델의 출력을 비즈니스에 필요한 특정 객체 구조로 100% 강제합니다. 스키마에 어긋난 출력은 클라이언트에 도달조차 하지 못합니다.

2) EVIDENCE (근거 게이트)

모델이 아무리 유려한 문장으로 요약 보고서를 작성해도, 각 문장(Claim)이 출처(Evidence)와 일치하는지 정적 룰과 심사 노드로 2단계 Fast-Fail 검증합니다.
지지하는 자료만 찾는 확증 편향을 차단하기 위해 반대 쿼리를 병행 검색하며, 근거를 통과하지 못한 문장은 보고서에 단 한 줄도 실리지 않습니다.

3) HARNESS (실행 하네스)

에이전트의 워크플로우를 수정할 때 프롬프트를 임의로 변경하지 않습니다.
마크다운으로 스펙을 정의하고, 실패하는 테스트(TDD)를 먼저 작성한 뒤, 회귀 테스트 스위트를 100% 통과한 것만 운영에 머지합니다.

결론: 비즈니스를 모델에게 넘기지 마십시오

진정한 AX(AI Transformation)는 화려한 데모를 보여주는 챗봇을 붙이는 것이 아닙니다.
업무의 프로세스를 모델에게 통째로 넘기지 않고, 모델이 활동할 수 있는 안전한 공학적 경계를 엔지니어가 직접 통제하는 것. 그것이 바로 엔터프라이즈가 가야 할 유일한 길입니다.