Self-Consistency 기법으로 LLM 정확도 높이기

LLM이 같은 질문에 여러 번 답변하게 하고 그 중 가장 많이 나온 답을 선택하는 Self-Consistency 기법을 배웁니다. 실무에서 LLM 정확도를 높이는 검증된 방법을 실전 예제와 함께 살펴봅니다.

1. Self-Consistency의 원리

어느 날 이지혜 씨는 고객 지원 챗봇을 개발하다가 이상한 현상을 발견했습니다. 같은 질문을 했는데 때로는 정확한 답변을, 때로는 엉뚱한 답변을 내놓는 것입니다.

"왜 이렇게 일관성이 없을까요?" 팀장님께 여쭤보니 "Self-Consistency를 적용해보세요"라는 답변이 돌아왔습니다.

Self-Consistency는 LLM에게 같은 질문을 여러 번 하고, 그 중 가장 많이 나온 답변을 최종 답으로 선택하는 기법입니다. 마치 중요한 결정을 내릴 때 여러 전문가의 의견을 듣고 다수결로 정하는 것과 같습니다.

이 방법을 사용하면 LLM의 정확도를 크게 향상시킬 수 있습니다.

다음 코드를 살펴봅시다.

import anthropic

def self_consistency_query(prompt, n_samples=5):
    # Anthropic Claude 클라이언트 초기화
    client = anthropic.Anthropic(api_key="your-api-key")

    responses = []
    # 같은 질문을 여러 번 반복합니다
    for i in range(n_samples):
        message = client.messages.create(
            model="claude-sonnet-4-5-20250929",
            max_tokens=1024,
            temperature=0.7,  # 다양성을 위해 temperature 설정
            messages=[{"role": "user", "content": prompt}]
        )
        # 각 응답을 저장합니다
        responses.append(message.content[0].text)

    return responses

이지혜 씨는 3년 차 백엔드 개발자입니다. 최근 회사에서 고객 문의를 자동으로 분류하는 시스템을 개발하라는 임무를 받았습니다.

LLM API를 연동해서 프로토타입을 만들었는데, 문제가 생겼습니다. 같은 고객 문의를 입력해도 때로는 "배송 문의"로, 때로는 "결제 문의"로 분류되는 것입니다.

정확도가 70% 정도밖에 나오지 않았습니다. 이대로는 실서비스에 적용할 수 없었습니다.

고민하던 이지혜 씨는 팀장님께 상황을 보고했습니다. 팀장님은 모니터를 보더니 빙그레 웃으며 말했습니다.

"Self-Consistency 기법을 써보세요. 정확도가 확 올라갈 겁니다." Self-Consistency란 정확히 무엇일까요?

쉽게 비유하자면, Self-Consistency는 마치 의사가 어려운 진단을 내릴 때 여러 전문의에게 소견을 구하는 것과 같습니다. 한 명의 의사만 보면 오진할 가능성이 있지만, 다섯 명의 의사가 모두 같은 진단을 내리면 신뢰도가 크게 높아집니다.

LLM도 마찬가지입니다. 일반적인 LLM 활용에서는 어떤 문제가 있을까요?

LLM은 확률적 모델입니다. 같은 입력을 받아도 매번 조금씩 다른 추론 경로를 거칩니다.

특히 temperature 값이 높으면 더 창의적이지만 덜 일관적인 답변을 생성합니다. 한 번의 시도만으로는 우연히 잘못된 추론 경로를 선택할 수 있습니다.

더 큰 문제는 복잡한 문제일수록 이런 불확실성이 커진다는 점입니다. 수학 문제나 논리적 추론을 요구하는 질문에서는 한 번의 답변만으로 신뢰하기 어렵습니다.

바로 이런 문제를 해결하기 위해 Self-Consistency 기법이 등장했습니다. Self-Consistency를 사용하면 여러 개의 독립적인 추론 경로를 얻을 수 있습니다.

LLM이 다양한 방식으로 문제를 접근하게 하고, 그 중에서 가장 신뢰할 만한 답을 찾아냅니다. 무엇보다 통계적 안정성을 확보할 수 있다는 큰 이점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 함수는 prompt와 n_samples를 받습니다.

n_samples는 같은 질문을 몇 번 반복할지 정하는 매개변수입니다. 보통 5~10회가 적당합니다.

for 반복문에서는 지정된 횟수만큼 LLM API를 호출합니다. 각 호출은 독립적이므로 매번 다른 추론 경로를 거칩니다.

중요한 것은 temperature=0.7입니다. 이 값이 있어야 다양한 답변을 얻을 수 있습니다.

temperature가 0이면 매번 같은 답변만 나오므로 Self-Consistency의 의미가 없습니다. 모든 응답은 리스트에 저장되어 반환됩니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 금융 서비스에서 고객의 투자 성향을 분석한다고 가정해봅시다.

"공격적", "중립적", "보수적" 중 하나로 분류해야 합니다. 한 번의 LLM 호출로 "공격적"이라는 답을 얻었다고 해서 바로 믿을 수 있을까요?

Self-Consistency를 적용하면 5번을 물어봐서 4번이 "보수적"이라고 나올 수도 있습니다. 이렇게 하면 훨씬 신뢰할 수 있는 결과를 얻습니다.

많은 AI 스타트업에서 이런 패턴을 적극적으로 사용하고 있습니다. 특히 의료, 법률, 금융처럼 정확도가 중요한 분야에서 필수적입니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 적은 샘플 수를 사용하는 것입니다.

2~3번만 물어보면 통계적으로 유의미하지 않습니다. 최소 5번 이상은 해야 합니다.

또한 API 비용도 샘플 수만큼 증가한다는 점을 고려해야 합니다. 다시 이지혜 씨의 이야기로 돌아가봅시다.

팀장님의 조언을 듣고 Self-Consistency를 적용한 이지혜 씨는 놀라운 결과를 얻었습니다. 정확도가 70%에서 92%로 올라간 것입니다.

Self-Consistency의 원리를 제대로 이해하면 LLM을 더 신뢰할 수 있는 방식으로 활용할 수 있습니다. 여러분도 중요한 의사결정이 필요한 LLM 시스템을 개발할 때 이 기법을 적용해 보세요.

실전 팁

💡 - 샘플 수는 5~10개가 적당합니다. 너무 많으면 비용이 증가합니다.

temperature는 0.7~0.9 정도로 설정해서 다양성을 확보하세요.

2. 다중 추론 경로 생성

Self-Consistency의 핵심을 이해한 이지혜 씨는 다음 단계로 넘어갔습니다. "어떻게 하면 LLM이 정말 다양한 추론 경로로 생각하게 할 수 있을까?" 단순히 여러 번 호출하는 것만으로는 충분하지 않았습니다.

진짜 다양성을 만들어내는 방법이 필요했습니다.

다중 추론 경로 생성은 LLM이 같은 문제를 여러 각도에서 접근하도록 유도하는 기법입니다. 마치 한 문제를 풀 때 대수적 방법, 기하학적 방법, 귀납적 방법 등 여러 방식으로 접근하는 것과 같습니다.

temperature 조절과 프롬프트 설계를 통해 진정한 다양성을 확보할 수 있습니다.

다음 코드를 살펴봅시다.

def generate_diverse_responses(prompt, n_samples=5):
    client = anthropic.Anthropic(api_key="your-api-key")

    # 다양성을 위한 프롬프트 변형
    reasoning_prompts = [
        f"{prompt}\n\nLet's think step by step:",
        f"{prompt}\n\nLet's approach this from first principles:",
        f"{prompt}\n\nLet's consider different perspectives:",
        f"{prompt}\n\nLet's break this down systematically:",
        f"{prompt}\n\nLet's analyze this carefully:"
    ]

    responses = []
    for i in range(min(n_samples, len(reasoning_prompts))):
        message = client.messages.create(
            model="claude-sonnet-4-5-20250929",
            max_tokens=1024,
            temperature=0.8,  # 높은 temperature로 다양성 확보
            messages=[{"role": "user", "content": reasoning_prompts[i]}]
        )
        responses.append(message.content[0].text)

    # 추가 샘플이 필요하면 기본 프롬프트로 반복
    while len(responses) < n_samples:
        message = client.messages.create(
            model="claude-sonnet-4-5-20250929",
            max_tokens=1024,
            temperature=0.9,
            messages=[{"role": "user", "content": prompt}]
        )
        responses.append(message.content[0].text)

    return responses

이지혜 씨는 Self-Consistency를 적용해서 정확도를 올렸지만, 새로운 의문이 생겼습니다. 5번을 질문했는데 5번 모두 거의 비슷한 답변이 나오는 것입니다.

"이게 정말 다양한 추론 경로일까?" 코드를 다시 살펴보니 문제가 보였습니다. temperature가 0.5로 너무 낮았고, 프롬프트도 똑같이 반복했습니다.

이렇게 하면 LLM이 거의 같은 방식으로만 생각하게 됩니다. 선배 개발자 최민수 씨가 지나가다가 화면을 보더니 조언해주었습니다.

"추론 경로의 다양성을 높여야 해요. 같은 질문을 다른 방식으로 유도하는 거죠." 다중 추론 경로 생성이란 정확히 무엇일까요?

쉽게 비유하자면, 서울에서 부산까지 가는 방법을 생각해보세요. 고속도로로 갈 수도 있고, 기차를 탈 수도 있고, 해안도로를 따라 갈 수도 있습니다.

목적지는 같지만 경로가 다릅니다. LLM도 마찬가지로 같은 답에 도달하더라도 여러 사고 과정을 거칠 수 있습니다.

왜 추론 경로의 다양성이 중요할까요? LLM은 확률적으로 다음 토큰을 예측합니다.

한 가지 추론 경로만 사용하면 그 경로의 초반부에서 실수가 생기면 끝까지 틀린 답으로 갈 수 있습니다. 하지만 여러 출발점에서 시작하면 일부 경로는 실수를 피할 수 있습니다.

더 중요한 것은 교차 검증입니다. 여러 다른 방식으로 접근했는데도 같은 답이 나온다면 그 답은 매우 신뢰할 수 있습니다.

반대로 모든 답변이 다르다면 문제가 애매하거나 LLM이 확신하지 못한다는 신호입니다. 바로 이런 이유로 프롬프트 변형 기법이 중요합니다.

위의 코드를 자세히 살펴보겠습니다. reasoning_prompts 리스트에는 다섯 가지 다른 사고 유도 문구가 들어있습니다.

"step by step"은 순차적 사고를, "first principles"는 근본 원리부터의 접근을, "different perspectives"는 다각도 분석을 유도합니다. 각각은 LLM이 문제를 바라보는 관점을 바꿉니다.

temperature도 0.8로 높입니다. 이렇게 하면 LLM이 덜 확실한 선택지도 탐색하게 됩니다.

첫 번째 반복에서는 프롬프트 변형을 사용하고, 추가 샘플이 필요하면 temperature를 0.9까지 올려서 더 많은 무작위성을 추가합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 법률 자문 AI를 개발한다고 가정해봅시다. "이 계약서에 문제가 있나요?"라는 질문에 대해 LLM이 여러 관점에서 검토하게 할 수 있습니다.

계약법적 관점, 민법적 관점, 판례 중심 관점 등 다양한 각도에서 분석하게 하는 것입니다. 실제로 한 법률 테크 스타트업에서는 이런 방식으로 계약서 검토 정확도를 85%에서 94%로 높였습니다.

다양한 추론 경로가 놓친 조항을 발견하는 데 크게 도움이 되었다고 합니다. 하지만 주의할 점도 있습니다.

프롬프트 변형이 너무 다르면 오히려 답변이 산만해질 수 있습니다. 핵심 질문은 유지하되, 사고 방식만 유도해야 합니다.

"이 계약서에 문제가 있나요?"와 "이 계약서의 장점은 무엇인가요?"는 완전히 다른 질문입니다. 이렇게 하면 안 됩니다.

또한 temperature가 너무 높으면(0.95 이상) 답변이 비일관적이고 무의미해질 수 있습니다. 0.7~0.9 사이가 적절합니다.

다시 이지혜 씨의 경험으로 돌아가봅시다. 최민수 씨의 조언대로 프롬프트 변형을 적용한 후, 이지혜 씨는 확실히 다양한 추론 경로를 얻을 수 있었습니다.

어떤 답변은 키워드 중심으로, 어떤 답변은 문맥 중심으로 분석했습니다. 다중 추론 경로를 제대로 생성하면 Self-Consistency의 진정한 힘을 발휘할 수 있습니다.

여러분도 중요한 판단이 필요한 시스템을 개발할 때 이 기법을 활용해보세요.

실전 팁

💡 - 프롬프트 변형은 사고 방식만 바꾸고 핵심 질문은 유지하세요.

temperature는 0.7~0.9 사이로 설정하는 것이 좋습니다.
너무 많은 변형(10개 이상)은 오히려 혼란을 줄 수 있습니다.

3. 답변 집계와 투표

이제 이지혜 씨는 다섯 개의 서로 다른 답변을 손에 쥐고 있었습니다. 하지만 새로운 문제가 생겼습니다.

"이 다섯 개 중에서 어떻게 최종 답을 정하지?" 단순히 가장 많이 나온 답을 선택하면 될까요? 아니면 더 똑똑한 방법이 있을까요?

답변 집계와 투표는 여러 개의 LLM 응답에서 최종 답을 결정하는 과정입니다. 마치 선거에서 표를 세듯이 각 답변의 빈도를 계산하고, 가장 많이 나온 답을 선택합니다.

복잡한 경우에는 가중치를 부여하거나 답변의 신뢰도를 고려할 수도 있습니다.

다음 코드를 살펴봅시다.

from collections import Counter
import re

def majority_vote(responses, extract_answer_fn=None):
    # 답변에서 핵심 결과만 추출하는 함수
    if extract_answer_fn is None:
        # 기본: 마지막 줄이나 명확한 답변 부분 추출
        extract_answer_fn = lambda x: x.strip().split('\n')[-1]

    # 각 응답에서 답변 추출
    answers = [extract_answer_fn(response) for response in responses]

    # 빈도 계산
    answer_counts = Counter(answers)

    # 가장 많이 나온 답변과 그 빈도
    most_common = answer_counts.most_common(1)[0]
    winner_answer = most_common[0]
    winner_count = most_common[1]

    # 신뢰도 계산 (전체 중 몇 %가 이 답에 동의했는지)
    confidence = winner_count / len(responses)

    return {
        'answer': winner_answer,
        'count': winner_count,
        'confidence': confidence,
        'all_answers': dict(answer_counts)
    }

# 사용 예제
def extract_classification(response):
    # "분류: XXX" 형태에서 XXX 추출
    match = re.search(r'분류:\s*(\S+)', response)
    if match:
        return match.group(1)
    return response.strip()

이지혜 씨는 이제 다섯 개의 다양한 답변을 얻었습니다. 고객 문의를 분류하는 시스템이었으므로, 답변은 "배송 문의", "결제 문의", "환불 문의" 등이었습니다.

그런데 문제가 생겼습니다. 다섯 개 중 세 개는 "배송 문의", 하나는 "결제 문의", 하나는 "상품 문의"였습니다.

어떤 것을 최종 답으로 해야 할까요? 명백해 보이지만, 코드로는 어떻게 구현할까요?

이지혜 씨는 머리를 긁적이며 최민수 씨에게 또 물어봤습니다. "답변 집계는 어떻게 하나요?" 최민수 씨는 웃으며 대답했습니다.

"다수결 투표를 하면 돼요. 통계의 기본이죠." 답변 집계와 투표란 무엇일까요?

쉽게 비유하자면, 마치 다섯 명의 전문가에게 자문을 구한 후 가장 많은 사람이 동의한 의견을 따르는 것과 같습니다. 민주적 의사결정 방식입니다.

한 명이 이상한 답을 해도, 나머지가 올바르게 답하면 최종 결과는 정확합니다. 왜 단순 투표가 효과적일까요?

LLM은 확률적 모델이므로 가끔 실수를 합니다. 하지만 독립적인 여러 시도에서 모두 실수할 확률은 매우 낮습니다.

예를 들어 한 번 실수할 확률이 20%라면, 5번 중 3번 이상 실수할 확률은 약 5%입니다. 통계적으로 매우 안전해지는 것입니다.

더 중요한 것은 이상치 제거 효과입니다. 가끔 LLM이 완전히 엉뚱한 답을 할 때가 있습니다.

하지만 투표 방식을 사용하면 이런 이상치는 자동으로 무시됩니다. 다수의 정상적인 답변이 승리하기 때문입니다.

위의 코드를 자세히 분석해보겠습니다. 먼저 extract_answer_fn 함수가 중요합니다.

LLM의 전체 응답에서 실제 답변 부분만 추출하는 역할을 합니다. LLM은 보통 설명과 함께 답을 주므로, 핵심만 뽑아내야 합니다.

기본값으로는 마지막 줄을 사용하지만, 커스텀 함수를 제공할 수 있습니다. Counter 클래스는 Python 표준 라이브러리에 있는 매우 편리한 도구입니다.

각 답변이 몇 번 나왔는지 자동으로 세어줍니다. most_common(1)은 가장 많이 나온 답변 하나를 반환합니다.

중요한 것은 신뢰도 계산입니다. 5개 중 3개가 같은 답이면 신뢰도는 60%입니다.

만약 5개 모두 같은 답이면 100%입니다. 이 신뢰도를 보고 결과를 얼마나 믿을지 판단할 수 있습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 의료 진단 보조 AI를 개발한다고 가정해봅시다.

LLM이 X-ray 이미지 설명을 보고 질병을 추정합니다. 10번 물어봐서 8번이 "폐렴", 1번이 "기관지염", 1번이 "정상"이라고 했다면 신뢰도 80%로 "폐렴"을 제시할 수 있습니다.

하지만 만약 결과가 3:3:4로 나뉘어 있다면 어떨까요? 가장 많은 것이 4표이지만 신뢰도는 40%에 불과합니다.

이런 경우 시스템이 "확신 없음"으로 표시하고 인간 의사에게 넘기도록 설계할 수 있습니다. 실제로 한 의료 AI 스타트업에서는 신뢰도가 70% 미만일 때는 자동 판정을 하지 않고 전문의 검토를 요청하도록 했습니다.

이렇게 해서 안전성을 크게 높였습니다. 하지만 주의할 점도 있습니다.

답변 추출 로직이 잘못되면 전체 시스템이 무너집니다. 예를 들어 LLM이 "답변: 배송 문의입니다"라고 했는데 추출 함수가 "입니다"만 뽑아낸다면 쓸모없습니다.

정규표현식이나 명확한 파싱 로직이 필요합니다. 또한 모든 답변이 제각각이면 투표도 소용없습니다.

이런 경우 문제가 애매하거나 프롬프트가 불명확하다는 신호입니다. 신뢰도 임계값(예: 50%)을 설정해서 이런 경우를 감지해야 합니다.

다시 이지혜 씨의 이야기로 돌아가봅시다. 답변 집계 로직을 구현한 이지혜 씨는 이제 자동으로 최종 답을 얻을 수 있게 되었습니다.

신뢰도도 함께 표시되어 어떤 분류가 확실하고 어떤 것이 애매한지 한눈에 볼 수 있었습니다. 답변 집계와 투표를 제대로 구현하면 Self-Consistency의 마지막 퍼즐이 완성됩니다.

여러분도 여러 응답을 통합하는 시스템을 만들 때 이 패턴을 적용해보세요.

실전 팁

💡 - 신뢰도 임계값(예: 60%)을 설정해서 불확실한 경우를 처리하세요.

답변 추출 로직은 신중하게 작성해야 합니다. 정규표현식 활용을 권장합니다.
모든 답변 분포를 로깅하면 디버깅에 도움이 됩니다.

4. Temperature 조절 전략

시스템이 대체로 잘 작동했지만, 이지혜 씨는 미묘한 문제를 발견했습니다. 간단한 질문에도 5번씩 API를 호출하니 비용이 만만치 않았습니다.

"모든 질문에 같은 방식을 적용할 필요가 있을까?" temperature를 어떻게 조절해야 효율적일지 고민이 되었습니다.

Temperature 조절 전략은 문제의 난이도와 중요도에 따라 LLM의 창의성 수준을 조정하는 기법입니다. 마치 요리할 때 불의 세기를 조절하듯이, temperature 값을 적절히 설정하면 정확도와 다양성의 균형을 맞출 수 있습니다.

효율적인 Self-Consistency를 위해서는 동적 temperature 조절이 중요합니다.

다음 코드를 살펴봅시다.

def adaptive_self_consistency(prompt, complexity="medium"):
    # 복잡도에 따른 temperature 및 샘플 수 설정
    configs = {
        "simple": {"temperature": 0.3, "n_samples": 3},
        "medium": {"temperature": 0.7, "n_samples": 5},
        "complex": {"temperature": 0.9, "n_samples": 7}
    }

    config = configs.get(complexity, configs["medium"])
    client = anthropic.Anthropic(api_key="your-api-key")

    responses = []
    for i in range(config["n_samples"]):
        # 샘플마다 약간씩 temperature 변화 (다양성 증가)
        temp_variation = config["temperature"] + (i * 0.05)
        temp_variation = min(temp_variation, 1.0)  # 최대 1.0 제한

        message = client.messages.create(
            model="claude-sonnet-4-5-20250929",
            max_tokens=1024,
            temperature=temp_variation,
            messages=[{"role": "user", "content": prompt}]
        )
        responses.append(message.content[0].text)

    return responses

이지혜 씨는 Self-Consistency 시스템을 프로덕션에 배포했습니다. 처음에는 모든 것이 순조로웠습니다.

정확도는 92%로 만족스러웠습니다. 하지만 한 달 후 회계팀에서 연락이 왔습니다.

"AI API 비용이 예상보다 5배나 높습니다. 무슨 일인가요?" CFO가 직접 물어왔습니다.

이지혜 씨는 당황했습니다. 모든 질문에 5번씩 API를 호출했으니 당연한 결과였습니다.

팀장님이 회의에서 말했습니다. "간단한 질문과 어려운 질문을 구분해야 합니다.

'배송 조회'는 한 번만 물어봐도 충분하지 않을까요?" Temperature 조절 전략이란 무엇일까요? 쉽게 비유하자면, 마치 운전할 때 상황에 따라 속도를 조절하는 것과 같습니다.

고속도로에서는 빠르게, 주택가에서는 천천히 달립니다. LLM도 마찬가지로 문제에 따라 탐색의 폭을 조절해야 합니다.

Temperature가 낮으면(0.0~0.3) LLM은 매우 확신하는 답만 선택합니다. 거의 결정론적으로 동작합니다.

반대로 temperature가 높으면(0.8~1.0) 더 창의적이고 다양한 답을 탐색합니다. 왜 적응형 temperature가 필요할까요?

모든 문제가 같은 수준의 불확실성을 갖는 것은 아닙니다. "1+1은?"이라는 질문에는 높은 temperature가 필요 없습니다.

어차피 답은 2입니다. 하지만 "이 법률 조항을 어떻게 해석해야 하나요?"는 다양한 관점이 필요합니다.

더 중요한 것은 비용 효율성입니다. 간단한 질문에 7번씩 물어보면 돈과 시간이 낭비됩니다.

반대로 복잡한 질문에 3번만 물어보면 정확도가 떨어집니다. 적절한 균형이 필요합니다.

위의 코드를 단계별로 살펴보겠습니다. configs 딕셔너리는 세 가지 복잡도 수준을 정의합니다.

"simple"은 temperature 0.3에 3번만 시도합니다. 거의 확정적인 답이 나올 것으로 예상되는 경우입니다.

"complex"는 temperature 0.9에 7번을 시도합니다. 다양한 추론 경로가 필요한 경우입니다.

흥미로운 부분은 temperature 변화입니다. 같은 복잡도 내에서도 각 샘플마다 0.05씩 temperature를 증가시킵니다.

첫 번째는 0.7, 두 번째는 0.75, 세 번째는 0.8 이런 식입니다. 이렇게 하면 더 넓은 범위의 추론 공간을 탐색할 수 있습니다.

min(temp_variation, 1.0)으로 temperature가 1.0을 넘지 않도록 제한합니다. 1.0을 초과하면 답변이 너무 무작위적이고 일관성이 없어집니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 고객 지원 챗봇 시스템을 생각해봅시다.

질문을 분석해서 복잡도를 자동으로 판단할 수 있습니다. "주문 번호 조회"는 simple로, "환불 규정 문의"는 medium으로, "복잡한 기술 문제"는 complex로 분류합니다.

실제로 한 커머스 플랫폼에서는 이런 적응형 전략으로 API 비용을 60% 절감하면서도 정확도는 오히려 2% 향상시켰습니다. 복잡한 문제에 더 많은 리소스를 집중한 결과였습니다.

복잡도를 자동으로 판단하는 방법도 있습니다. 프롬프트의 길이, 키워드 분석, 심지어 첫 번째 답변의 신뢰도를 보고 동적으로 샘플 수를 조정할 수도 있습니다.

하지만 주의할 점도 있습니다. 복잡도 판단이 잘못되면 역효과가 납니다.

실제로는 복잡한 문제인데 simple로 분류하면 정확도가 크게 떨어집니다. 초기에는 보수적으로 설정하고, 로그 데이터를 분석해서 점진적으로 최적화하는 것이 좋습니다.

또한 temperature가 너무 낮으면(0.1 이하) 여러 번 물어봐도 똑같은 답만 나옵니다. Self-Consistency의 의미가 사라지는 것입니다.

simple 케이스라도 최소 0.3 정도는 유지하세요. 다시 이지혜 씨의 경험으로 돌아가봅시다.

적응형 temperature 전략을 도입한 후, 이지혜 씨는 CFO를 다시 만났습니다. "API 비용이 70% 감소했습니다"라고 보고했습니다.

CFO는 만족스러워했고, 정확도는 여전히 90% 이상을 유지했습니다. Temperature 조절 전략을 잘 활용하면 성능과 비용의 최적 균형점을 찾을 수 있습니다.

여러분도 프로덕션 시스템을 운영할 때 이런 최적화 기법을 고려해보세요.

실전 팁

💡 - 초기에는 보수적으로 설정하고 데이터를 모아서 최적화하세요.

복잡도 판단 로직은 별도 함수로 분리하면 유지보수가 쉽습니다.
Temperature는 최소 0.3 이상 유지해야 Self-Consistency가 의미있습니다.

5. 실습 Self-Consistency 시스템 구축

이론과 개별 기법들을 모두 배운 이지혜 씨는 이제 전체 시스템을 완성할 차례였습니다. "지금까지 배운 것들을 어떻게 하나로 묶을까?" 실무에서 바로 사용할 수 있는 완전한 Self-Consistency 시스템이 필요했습니다.

Self-Consistency 시스템 구축은 다중 추론, 답변 집계, temperature 조절을 모두 통합한 완전한 구현입니다. 마치 자동차의 엔진, 변속기, 브레이크가 조화롭게 작동하듯이 모든 컴포넌트가 유기적으로 동작하는 시스템을 만듭니다.

다음 코드를 살펴봅시다.

import anthropic
from collections import Counter
import re

class SelfConsistencySystem:
    def __init__(self, api_key):
        self.client = anthropic.Anthropic(api_key=api_key)

    def query(self, prompt, complexity="medium", extract_fn=None):
        # 1단계: 다중 응답 생성
        responses = self._generate_responses(prompt, complexity)

        # 2단계: 답변 추출 및 집계
        result = self._aggregate_responses(responses, extract_fn)

        # 3단계: 메타 정보 추가
        result['prompt'] = prompt
        result['complexity'] = complexity
        result['raw_responses'] = responses

        return result

    def _generate_responses(self, prompt, complexity):
        configs = {
            "simple": {"temperature": 0.3, "n_samples": 3},
            "medium": {"temperature": 0.7, "n_samples": 5},
            "complex": {"temperature": 0.9, "n_samples": 7}
        }
        config = configs[complexity]

        responses = []
        for i in range(config["n_samples"]):
            temp = min(config["temperature"] + (i * 0.05), 1.0)
            message = self.client.messages.create(
                model="claude-sonnet-4-5-20250929",
                max_tokens=1024,
                temperature=temp,
                messages=[{"role": "user", "content": prompt}]
            )
            responses.append(message.content[0].text)

        return responses

    def _aggregate_responses(self, responses, extract_fn):
        if extract_fn is None:
            extract_fn = lambda x: x.strip().split('\n')[-1]

        answers = [extract_fn(r) for r in responses]
        counts = Counter(answers)
        winner = counts.most_common(1)[0]

        return {
            'answer': winner[0],
            'count': winner[1],
            'confidence': winner[1] / len(responses),
            'all_answers': dict(counts)
        }

# 사용 예제
system = SelfConsistencySystem(api_key="your-api-key")
result = system.query("고객 문의: 배송이 안 왔어요", complexity="medium")
print(f"답변: {result['answer']}")
print(f"신뢰도: {result['confidence']:.0%}")

이지혜 씨는 지금까지 배운 기법들을 노트에 정리했습니다. 다중 추론 경로, 답변 집계, temperature 조절까지 모두 이해했습니다.

하지만 이것들이 여기저기 흩어진 함수들로만 존재했습니다. "이걸 어떻게 깔끔하게 정리하지?" 고민하던 이지혜 씨에게 최민수 씨가 조언했습니다.

"클래스로 만들어서 재사용 가능하게 하세요. 객체지향의 힘을 활용하는 거죠." Self-Consistency 시스템이란 정확히 무엇일까요?

쉽게 비유하자면, 마치 스위스 아미 나이프와 같습니다. 여러 도구가 하나의 패키지 안에 깔끔하게 정리되어 있고, 필요할 때 꺼내 쓸 수 있습니다.

시스템도 마찬가지로 모든 기능이 통합되어 있어야 합니다. 왜 시스템화가 중요할까요?

개별 함수들만 있으면 매번 같은 설정을 반복해야 합니다. API 키를 계속 전달하고, config를 매번 작성하고, 로직을 복붙합니다.

이는 유지보수 악몽입니다. 한 곳에서 버그를 고쳐도 다른 곳에는 여전히 버그가 남아있습니다.

더 중요한 것은 확장성입니다. 나중에 캐싱 기능을 추가하거나, 로깅을 넣거나, 모니터링을 붙이고 싶을 때 클래스로 구조화되어 있으면 훨씬 쉽습니다.

한 곳만 수정하면 모든 곳에 적용됩니다. 위의 코드를 구조적으로 분석해보겠습니다.

SelfConsistencySystem 클래스는 세 가지 책임을 갖습니다. 초기화에서 API 클라이언트를 설정하고, query 메서드로 전체 프로세스를 조율하고, 내부 메서드들로 세부 작업을 처리합니다.

query 메서드는 파사드 패턴입니다. 사용자는 이것만 호출하면 됩니다.

내부에서 다중 응답 생성, 집계, 메타 정보 추가를 자동으로 처리합니다. 복잡한 내부 로직은 감춰져 있습니다.

_generate_responses와 _aggregate_responses는 private 메서드입니다. 밑줄로 시작하는 이름은 "외부에서 직접 호출하지 마세요"라는 파이썬 관례입니다.

내부 구현 디테일이므로 나중에 자유롭게 변경할 수 있습니다. 결과 객체는 풍부한 메타데이터를 포함합니다.

단순히 답변만 반환하는 것이 아니라 신뢰도, 모든 답변 분포, 심지어 원본 응답까지 제공합니다. 디버깅과 분석에 매우 유용합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 여러 마이크로서비스에서 이 시스템을 사용한다고 가정해봅시다.

공통 라이브러리로 패키징해서 pip install로 설치하면 됩니다. 각 서비스는 단 몇 줄의 코드로 Self-Consistency를 적용할 수 있습니다.

실제로 한 핀테크 스타트업에서는 이런 시스템을 내부 패키지로 만들어 10개 이상의 서비스에서 재사용했습니다. 한 번 검증된 코드를 여러 곳에서 안전하게 사용하는 것입니다.

또한 단위 테스트도 쉬워집니다. Mock 객체로 API 클라이언트를 대체하면 실제 API를 호출하지 않고도 로직을 테스트할 수 있습니다.

하지만 주의할 점도 있습니다. 클래스를 너무 복잡하게 만들면 오히려 이해하기 어려워집니다.

단일 책임 원칙을 지키세요. Self-Consistency 외의 기능(예: 데이터베이스 저장, 알림 전송 등)은 별도 클래스로 분리하는 것이 좋습니다.

또한 설정 옵션이 너무 많으면 사용자가 혼란스러워합니다. 합리적인 기본값을 제공하고, 정말 필요한 옵션만 노출하세요.

나머지는 내부에서 자동으로 처리하는 것이 좋습니다. 다시 이지혜 씨의 이야기로 돌아가봅시다.

클래스 기반 시스템을 완성한 이지혜 씨는 팀 전체에 공유했습니다. 동료 개발자들이 "우와, 이거 쓰기 편하네요!"라며 칭찬했습니다.

코드 3줄이면 Self-Consistency를 적용할 수 있었습니다. 완전한 시스템을 구축하면 개인 프로젝트에서 벗어나 팀 전체가 활용할 수 있는 자산이 됩니다.

여러분도 재사용 가능한 컴포넌트를 만드는 습관을 들여보세요.

실전 팁

💡 - 클래스는 단일 책임을 가져야 합니다. 너무 많은 기능을 넣지 마세요.

합리적인 기본값을 제공하면 사용성이 크게 향상됩니다.
풍부한 메타데이터를 반환하면 디버깅과 분석이 쉬워집니다.

6. 실습 정확도 향상 실험

완성된 시스템을 손에 쥔 이지혜 씨는 궁금해졌습니다. "정말 Self-Consistency가 정확도를 높일까?

얼마나 높일까?" 데이터로 검증해야 확신할 수 있었습니다. 실험을 설계할 시간이었습니다.

정확도 향상 실험은 Self-Consistency의 효과를 정량적으로 측정하는 과정입니다. 마치 신약의 효능을 임상시험으로 검증하듯이, 체계적인 실험을 통해 성능 개선을 입증합니다.

샘플 수, temperature, 복잡도별로 정확도 변화를 분석합니다.

다음 코드를 살펴봅시다.

import json
from typing import List, Dict

class AccuracyExperiment:
    def __init__(self, sc_system: SelfConsistencySystem):
        self.system = sc_system
        self.results = []

    def run_experiment(self, test_cases: List[Dict],
                       configurations: List[Dict]):
        """
        여러 설정으로 테스트 케이스들을 실행하고 정확도 측정
        test_cases: [{"prompt": "...", "expected": "..."}, ...]
        configurations: [{"complexity": "medium", "name": "..."}, ...]
        """

        for config in configurations:
            correct = 0
            total = len(test_cases)
            config_results = []

            for test in test_cases:
                result = self.system.query(
                    test["prompt"],
                    complexity=config["complexity"]
                )

                is_correct = self._check_answer(
                    result["answer"],
                    test["expected"]
                )

                if is_correct:
                    correct += 1

                config_results.append({
                    "prompt": test["prompt"],
                    "expected": test["expected"],
                    "actual": result["answer"],
                    "confidence": result["confidence"],
                    "correct": is_correct
                })

            accuracy = correct / total

            self.results.append({
                "configuration": config["name"],
                "complexity": config["complexity"],
                "accuracy": accuracy,
                "correct_count": correct,
                "total_count": total,
                "details": config_results
            })

            print(f"{config['name']}: {accuracy:.1%} 정확도")

        return self.results

    def _check_answer(self, actual: str, expected: str) -> bool:
        # 답변 검증 로직 (간단한 포함 관계 체크)
        return expected.lower() in actual.lower()

    def save_results(self, filename: str):
        with open(filename, 'w', encoding='utf-8') as f:
            json.dump(self.results, f, ensure_ascii=False, indent=2)

# 사용 예제
test_cases = [
    {"prompt": "고객 문의: 배송이 늦어요", "expected": "배송"},
    {"prompt": "고객 문의: 결제가 안 돼요", "expected": "결제"},
    # ... 더 많은 테스트 케이스
]

configs = [
    {"complexity": "simple", "name": "Simple (3 samples)"},
    {"complexity": "medium", "name": "Medium (5 samples)"},
    {"complexity": "complex", "name": "Complex (7 samples)"}
]

experiment = AccuracyExperiment(system)
results = experiment.run_experiment(test_cases, configs)

이지혜 씨는 시스템을 완성했지만 한 가지 의문이 남았습니다. "정말 효과가 있을까?

그냥 한 번만 물어보는 것과 비교해서 얼마나 나을까?" 팀장님도 같은 질문을 했습니다. "데이터로 증명해주세요." 이지혜 씨는 실험 계획을 세웠습니다.

100개의 고객 문의를 준비하고, 각각에 대해 정답을 미리 레이블링했습니다. 그리고 여러 설정으로 시스템을 돌려보기로 했습니다.

최민수 씨가 조언했습니다. "실험도 코드로 자동화하세요.

그래야 재현 가능하고 신뢰할 수 있습니다." 정확도 향상 실험이란 무엇일까요? 쉽게 비유하자면, 마치 두 가지 약의 효과를 비교하는 대조 실험과 같습니다.

같은 환자들에게 약 A와 약 B를 각각 투여하고 결과를 비교합니다. 여기서는 같은 질문들에 대해 다양한 Self-Consistency 설정을 적용하고 정확도를 측정하는 것입니다.

왜 정량적 실험이 중요할까요? 개발자의 직관은 종종 틀립니다.

"이게 더 좋을 것 같아"는 감이지 사실이 아닙니다. 특히 AI 시스템처럼 확률적으로 동작하는 것은 통계적 검증이 필수입니다.

한두 번 잘 작동한다고 해서 항상 잘 작동하는 것은 아닙니다. 더 중요한 것은 최적 설정 발견입니다.

샘플 수를 3개, 5개, 7개 중 어떤 것으로 해야 할까요? 실험 없이는 알 수 없습니다.

데이터를 보면 비용 대비 효과가 가장 좋은 지점을 찾을 수 있습니다. 위의 코드를 실험 설계 관점에서 살펴보겠습니다.

AccuracyExperiment 클래스는 실험 프레임워크입니다. 테스트 케이스와 설정들을 받아서 체계적으로 실험을 수행합니다.

test_cases는 ground truth를 포함합니다. 각 질문의 정답을 미리 알고 있어야 정확도를 측정할 수 있습니다.

configurations는 실험 조건들입니다. 같은 데이터에 대해 여러 조건을 적용해서 결과를 비교합니다.

이것이 대조 실험의 핵심입니다. 이중 반복문 구조가 중요합니다.

외부 루프는 각 설정을, 내부 루프는 각 테스트 케이스를 처리합니다. 이렇게 하면 교차 검증이 가능합니다.

모든 조합을 빠짐없이 테스트하는 것입니다. _check_answer 메서드는 답변 검증 로직입니다.

여기서는 간단하게 포함 관계만 확인하지만, 실제로는 더 정교한 로직이 필요할 수 있습니다. 정규표현식, 유사도 계산, 심지어 다른 LLM을 사용한 평가도 가능합니다.

결과는 JSON 파일로 저장됩니다. 이렇게 하면 나중에 다시 분석하거나 시각화하기 쉽습니다.

재현 가능성이 보장되는 것입니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 새로운 프롬프트 기법을 도입하기 전에 A/B 테스트를 합니다. 기존 방식과 새 방식을 이런 프레임워크로 비교 실험합니다.

정확도가 통계적으로 유의미하게 높아진 것을 확인한 후에야 프로덕션에 적용합니다. 실제로 한 AI 챗봇 회사에서는 매주 실험을 돌려서 최적 설정을 찾습니다.

데이터가 쌓이면서 점점 더 좋은 설정을 발견하고, 정확도가 지속적으로 향상됩니다. 이지혜 씨의 실험 결과는 놀라웠습니다.

단일 질의(샘플 1개)는 정확도 73%였습니다. 하지만 medium 설정(샘플 5개)은 92%였습니다.

complex 설정(샘플 7개)은 94%였지만 비용이 40% 더 들었습니다. 이지혜 씨는 보고서를 작성했습니다.

"medium 설정이 최적입니다. 정확도는 92%로 충분히 높고, 비용 대비 효율이 가장 좋습니다." 팀장님과 CFO 모두 데이터를 보고 고개를 끄덕였습니다.

하지만 주의할 점도 있습니다. 테스트 케이스가 편향되면 실험 결과도 편향됩니다.

예를 들어 모두 간단한 질문만 모으면 Self-Consistency의 효과가 과소평가됩니다. 대표성 있는 샘플을 선정해야 합니다.

또한 통계적 유의성도 고려해야 합니다. 10개 테스트로 90% 나왔다고 해서 신뢰할 수 없습니다.

최소 50~100개 이상의 테스트 케이스가 필요합니다. 다시 이지혜 씨의 이야기로 마무리하겠습니다.

실험 결과를 바탕으로 최적화된 Self-Consistency 시스템이 프로덕션에 배포되었습니다. 3개월 후 고객 만족도가 15% 상승했고, 잘못된 분류로 인한 고객 불만이 절반으로 줄었습니다.

정확도 향상 실험을 통해 추측이 아닌 데이터 기반 의사결정을 할 수 있습니다. 여러분도 AI 시스템을 개발할 때 이런 체계적 검증 프로세스를 도입해보세요.

실전 팁

💡 - 테스트 케이스는 최소 50개 이상, 다양한 유형을 포함해야 합니다.

결과를 JSON으로 저장하면 나중에 재분석하기 쉽습니다.
정확도뿐만 아니라 비용, 지연시간도 함께 측정하면 더 좋습니다.

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#LLM#Self-Consistency#Temperature#Prompting#Optimization#LLM,Self-Consistency,최적화

CodeDeck

Self-Consistency 기법으로 LLM 정확도 높이기

목차

1. Self-Consistency의 원리

2. 다중 추론 경로 생성

3. 답변 집계와 투표

4. Temperature 조절 전략

5. 실습 Self-Consistency 시스템 구축

6. 실습 정확도 향상 실험

댓글 (0)

함께 보면 좋은 카드 뉴스

ReAct 패턴 마스터 완벽 가이드

AI 에이전트의 모든 것 - 개념부터 실습까지

프로덕션 RAG 시스템 완벽 가이드

RAG 캐싱 전략 완벽 가이드

실시간으로 답변하는 RAG 시스템 만들기