beautifulsoups.dev
Published on

CoT 유출 없이 추론 품질 올리는 5가지 기법

Authors

서버에서 LLM을 붙여 제품을 만들다 보면 금방 마주치는 딜레마가 있습니다. 추론 품질을 높이려면 모델이 충분히 생각하도록 유도해야 하는데, 그 과정(Chain-of-Thought, 이하 CoT)을 그대로 사용자에게 노출하면 보안·정책·프롬프트 인젝션·데이터 유출 측면에서 위험해집니다. 또한 CoT는 길어질수록 토큰 비용이 늘고, 내부 로직이 노출되면 공격자가 이를 역이용하기도 쉽습니다.

이 글에서는 CoT를 사용자에게 보여주지 않으면서도 실제 품질을 올리는 데 효과적인 5가지 기법을 정리합니다. 핵심은 “모델이 생각은 하되, 출력은 구조화된 결과와 근거 요약만 제공”하도록 파이프라인을 설계하는 것입니다.

또한 운영 환경에서는 재시도·백오프 같은 안정화가 품질에 직결됩니다. 호출 실패가 늘면 샘플링 편향이 생기고, 부분 실패가 누적되어 결과 품질이 떨어지기 때문입니다. 관련해서는 Claude 429 과금폭탄 막는 재시도·백오프 전략도 함께 참고하면 좋습니다.

1) 최종 출력만 강제하는 “요약 근거” 포맷

가장 간단하면서도 효과적인 방법은 CoT를 쓰지 말라가 아니라, CoT를 출력하지 말라를 강제하는 것입니다. 즉, 모델 내부에서는 충분히 사고하되, 사용자에게는 짧은 근거 요약과 최종 답만 내보내게 합니다.

프롬프트 패턴

  • 모델에게 “내부 추론은 생략하고, 검증 가능한 근거만 bullet로 요약”을 요구
  • 출력 스키마를 고정해 산만한 장황함을 줄임
시스템:
- 너는 정확한 답을 내는 분석가다.
- 내부 추론(Chain-of-Thought)은 절대 출력하지 않는다.
- 출력은 아래 JSON 스키마를 반드시 따른다.

사용자:
질문: {question}

출력(JSON):
{
  "answer": "...",
  "key_points": ["...", "..."],
  "assumptions": ["..."],
  "uncertainties": ["..."],
  "next_checks": ["...", "..."]
}

왜 품질이 오르나

  • 모델이 최종 답을 내기 전에 스스로 전제와 불확실성을 정리하게 되어 환각이 줄어듭니다.
  • 사용자에게는 CoT 대신 검증 가능한 요약 근거만 제공되므로 정책 리스크가 낮습니다.

주의점

  • “절대 출력하지 말라”는 지시만으로 100퍼센트 보장되진 않습니다. 아래 4가지 기법과 함께 “가드레일”로 보완해야 합니다.

2) Self-Check: 내부 검증 단계 분리(답변과 검증을 분리)

CoT 유출을 막으면서 품질을 올리는 핵심은 단계를 나누는 것입니다.

  • 1단계: 답 생성
  • 2단계: 검증(사실성, 누락, 모순, 요구사항 충족 여부)
  • 3단계: 검증 결과를 반영해 최종 답 확정

중요한 포인트는 검증 단계의 산출물을 사용자에게 그대로 보여주지 않는 것입니다. 검증 결과는 내부 메타데이터로만 쓰고, 최종 답만 노출합니다.

오케스트레이션 예시(의사 코드)

def answer_with_self_check(llm, question):
    draft = llm.generate(
        system="내부 추론은 출력하지 말고, 최종 답만 간결히 작성",
        user=question,
        temperature=0.4,
    )

    critique = llm.generate(
        system=(
            "너는 검증자다. 내부 검증 메모를 작성하되 사용자에게 노출될 텍스트가 아니다. "
            "사실성/요구사항/모순/누락을 체크하고, 개선 지시만 항목으로 써라."
        ),
        user=f"질문: {question}\n초안: {draft}",
        temperature=0.0,
    )

    final = llm.generate(
        system=(
            "너는 편집자다. 아래 개선 지시를 반영해 최종 답만 출력하라. "
            "내부 검증 메모나 추론 과정은 절대 출력하지 말라."
        ),
        user=f"질문: {question}\n초안: {draft}\n개선 지시: {critique}",
        temperature=0.2,
    )

    return final

팁

  • 2단계는 temperature를 0.0에 가깝게 두면 체크리스트 성격이 강해져 안정적입니다.
  • “검증 메모”가 유출되지 않도록 로그/트레이싱에서도 마스킹 규칙을 적용하세요.

3) Retrieval + 인용 강제: 근거를 외부로 이동

CoT를 공개하지 않고도 설득력과 정확도를 높이는 가장 실용적인 방법은 근거를 모델 내부 추론이 아니라 외부 문서로 옮기는 것입니다. 즉 RAG를 쓰되, “인용 가능한 근거가 없으면 답을 유보”하도록 정책을 둡니다.

패턴

  • 검색 결과(사내 위키, 스펙 문서, 정책 문서, 코드)만 근거로 답하도록 제한
  • 인용이 없으면 unknown 또는 need_more_info를 반환
시스템:
- 제공된 문서 조각 안에서만 답하라.
- 문서에 없는 내용은 추측하지 말고 "모름" 또는 "추가 정보 필요"로 답하라.
- 출력에는 근거 문서 ID를 반드시 포함하라.

사용자:
질문: {question}
문서 조각:
[doc-1] ...
[doc-2] ...

출력:
- answer: ...
- citations: ["doc-2", "doc-1"]

왜 CoT 없이도 좋아지나

  • 사용자는 “추론 과정” 대신 “근거 문서”를 확인할 수 있어 신뢰도가 올라갑니다.
  • 모델은 임의의 추론을 길게 늘어놓을 필요가 없어 토큰을 절약합니다.

운영 팁

4) 다중 샘플링 + 합의(Consensus)로 편향 줄이기

단일 샘플의 약점은 “한 번 삐끗하면 그대로 끝”이라는 점입니다. CoT를 공개하지 않더라도, 여러 후보를 생성한 뒤 합의로 고르는 방식은 정확도를 꽤 올립니다.

대표 방식

  • n개 후보 생성
  • 후보 간 상호 비교로 최종 선택
  • 또는 간단히 다수결, 점수화(요구사항 충족 여부)로 선택
def consensus_answer(llm, question, n=5):
    candidates = []
    for _ in range(n):
        candidates.append(
            llm.generate(
                system="최종 답만 출력. 내부 추론은 출력 금지.",
                user=question,
                temperature=0.7,
            )
        )

    judge_prompt = """
너는 심사자다.
- 아래 후보 중 질문 요구사항을 가장 잘 만족하는 하나를 고른다.
- 선택 이유는 내부용 한 줄 메모로만 작성하고, 사용자에게는 선택된 답만 반환한다.

후보:
{cands}

출력:
selected_index: number
"""

    selected = llm.generate(
        system="내부 메모는 출력해도 되지만, 최종 API 응답에는 포함되지 않는다.",
        user=judge_prompt.format(cands="\n\n".join(f"[{i}] {c}" for i, c in enumerate(candidates))),
        temperature=0.0,
    )

    idx = int(selected.split("selected_index:")[-1].strip().split()[0])
    return candidates[idx]

비용과 지연

  • 당연히 토큰과 지연이 증가합니다.
  • 하지만 “중요한 요청에만” 적용하는 계층형 전략이 가능합니다. 예를 들어 신뢰도 낮음 신호(검색 근거 부족, 불확실성 높음, 사용자 영향도 큼)가 감지되면 합의 모드로 승격합니다.

5) 규칙 기반 가드레일 + 실패 시 안전한 재질문(Clarifying)

추론 품질의 상당 부분은 “모델이 잘못 생각했다”가 아니라 “입력이 애초에 모호했다”에서 발생합니다. CoT를 보여주지 않으려면 더더욱 질문을 선명하게 만드는 전략이 중요합니다.

기법 A: 입력 검증 체크리스트

모델 호출 전에 규칙 기반으로 요구사항을 검사합니다.

  • 필수 파라미터 누락 여부
  • 날짜/단위/범위 모호성
  • 금지된 요구(정책 위반) 여부
type ValidationResult =
  | { ok: true }
  | { ok: false; questions: string[] };

export function validateQuestion(q: string): ValidationResult {
  const questions: string[] = [];
  if (q.length < 10) questions.push("질문이 너무 짧습니다. 목표/맥락을 조금 더 알려주세요.");
  if (!/(\d|%|ms|sec|원|달러)/.test(q)) {
    questions.push("수치/단위가 없으면 답이 모호할 수 있습니다. 목표 지표나 단위를 알려주세요.");
  }
  return questions.length ? { ok: false, questions } : { ok: true };
}

기법 B: Clarifying 질문을 우선

검증에서 ok: false가 나오면 LLM에게 바로 답을 시키지 말고, 추가 질문을 먼저 반환합니다. 이때도 CoT는 필요 없습니다.

시스템:
- 사용자의 요구가 모호하면 답을 만들지 말고, 확인 질문 2~4개만 출력하라.
- 내부 추론은 출력하지 않는다.

사용자:
질문: {question}

운영에서의 이점

  • 잘못된 전제를 깔고 장황한 답을 만드는 것보다, 짧은 확인 질문이 전체 품질을 크게 올립니다.
  • 고객 대응, 장애 대응, 보안 민감 질의에서 특히 효과가 큽니다.

실전 조합 레시피: “RAG + Self-Check + 합의”의 최소 구성

현업에서 가장 성능 대비 구현 난이도가 괜찮은 조합은 아래입니다.

  1. 입력 검증으로 모호하면 확인 질문 우선
  2. RAG로 근거 문서를 붙임
  3. 답 생성(최종 출력만)
  4. Self-Check로 요구사항/모순 점검 후 재작성
  5. 중요한 요청에만 다중 샘플링 합의 적용

이 구조는 CoT를 사용자에게 노출하지 않으면서도, 실제로는 모델이 여러 번 “생각하고 검증”하게 만들어 품질을 끌어올립니다.

디버깅과 관측: CoT 없이도 문제를 찾는 방법

CoT를 숨기면 디버깅이 어려워진다는 걱정이 많습니다. 대신 다음을 로깅하면 운영 품질을 충분히 관리할 수 있습니다.

  • 검색 쿼리와 상위 문서 ID, 스코어
  • 출력 스키마 준수 여부
  • 불확실성 플래그(예: uncertainties 길이, need_more_info 발생률)
  • 재시도 횟수, 레이트 리밋 발생률

또한 배포 환경에서 지연과 오류가 늘면 품질이 같이 흔들립니다. 모델 API 호출이 불안정하거나 콜드스타트가 심하면 RAG 문서가 비거나 타임아웃으로 샘플이 줄어 합의 로직이 깨질 수 있습니다. 인프라 측면 최적화는 GCP Cloud Run 503·콜드스타트 줄이는 튜닝도 참고할 만합니다.

마무리

CoT를 노출하지 않는다고 해서 품질을 포기할 필요는 없습니다. 핵심은 “생각은 내부에서, 근거는 외부에서, 출력은 구조화된 결과로”입니다.

  • 요약 근거 포맷으로 출력 통제
  • Self-Check로 단계 분리
  • RAG와 인용 강제로 근거를 외부화
  • 다중 샘플링 합의로 편향 완화
  • 입력 검증과 확인 질문으로 모호성 제거

이 5가지를 상황에 맞게 조합하면, 정책 리스크를 줄이면서도 사용자 체감 품질을 꾸준히 올릴 수 있습니다.

Discuss on Twitter • View on GitHub