왜 AI 에이전트는 '예측 불가능'하다고 느껴질까?

최근 AI 코딩 에이전트, 문서 자동화 에이전트가 주목받고 있지만, 많은 실무자가 공통적으로 느끼는 아쉬움이 있습니다. '결과가 매번 달라진다' 는 점입니다. 같은 문서를 넣었는데 오늘은 잘 읽고, 내일은 엉뚱한 필드를 추출한다면 신뢰하기 어렵죠.

이 문제의 근본 원인은 LLM의 확률적 특성에 있습니다. LLM은 본질적으로 '다음 토큰을 맞추는' 방식이기 때문에, 입력이 동일해도 출력이 달라질 수 있습니다. 하지만 실제 프로덕션 시스템에서는 이런 변동성을 허용할 수 없습니다. 특히 계약서, 법률 문서, 의료 기록처럼 높은 정확도가 요구되는 도메인에서는 더욱 그렇습니다.

여기서 핵심 해결책으로 떠오른 개념이 바로 '강력한 피드백 루프(Feedback Loop)' 입니다. 단순히 LLM에 질의를 던지고 결과를 받는 1회성 파이프라인이 아니라, 출력 결과를 다시 입력으로 삼아 지속적으로 개선하는 구조가 필요합니다.

이 글에서는 실제 AWS 기반 프로덕션 시스템인 Doczy.ai의 아키텍처를 통해, 예측 가능한 AI 에이전트를 만드는 구체적인 설계 패턴을 분석해보겠습니다. 단순한 개념 설명이 아니라, 실제 99% 정확도를 달성한 사례를 바탕으로 여러분의 프로젝트에 적용할 수 있는 인사이트를 전달하는 것이 목표입니다.

AI agent architecture diagram showing feedback loop between LLM and structured data output System Abstract Visual

피드백 루프의 3단계: Input → Process → Feedback

Doczy.ai의 아키텍처를 분석해보면, 피드백 루프는 크게 세 단계로 구성됩니다. 각 단계가 어떻게 예측 가능성을 높이는지 살펴보겠습니다.

1단계: 스마트 청킹(Smart Chunking) — 문서 구조를 보존하는 입력 전처리

일반적인 RAG 시스템은 문서를 단순히 토큰 길이로 자르거나(chunk), 의미 단위로 나누는 데 그칩니다. 하지만 Doczy.ai는 '스마트 청킹' 이라는 특허 기술을 사용합니다.

# 스마트 청킹 개념을 단순화한 의사 코드 예시
# 실제 시스템은 더 복잡한 알고리즘을 사용합니다.

def smart_chunk(document_text: str) -> list[dict]:
    """
    문서의 계층 구조와 의미를 보존하는 청킹 알고리즘.
    단순한 길이 기반 청킹과 달리, 섹션/조항/표 등의 구조를 유지합니다.
    """
    chunks = []
    
    # 1) 의미적 분할: 문단, 섹션 헤더 기준으로 1차 분할
    semantic_segments = split_by_semantic_boundary(document_text)
    
    # 2) 구조적 태깅: 각 세그먼트에 메타데이터(조항 유형, 중첩 레벨) 부여
    for segment in semantic_segments:
        segment['clause_type'] = classify_clause(segment['text'])
        segment['nesting_level'] = detect_nesting_level(segment)
        # 예: Exhibit(별첨)는 3레벨 중첩, Schedule(일정)은 1레벨 등
    
    # 3) 중복 제거 및 연관 그룹핑
    deduplicated = remove_overlaps(semantic_segments)
    grouped = group_by_sequential_id(deduplicated)
    
    return grouped

핵심 인사이트: 문서를 '평평한 텍스트'로 보지 않고, 원래의 계층 구조와 관계를 보존하는 것이 정확도의 첫걸음입니다. 국내 SI 환경에서도 PDF나 워드 문서를 처리할 때, 단순 텍스트 추출을 넘어 문서 템플릿 분석 → 구조화된 청킹 단계를 도입하면 이후 LLM의 출력 품질이 크게 향상됩니다.

2단계: 이중 클러스터링(Dual Clustering) — 의미와 구조를 동시에 분석

청킹된 데이터는 두 가지 관점에서 동시에 분석됩니다.

# 이중 클러스터링 개념을 단순화한 의사 코드

def dual_clustering(chunks: list[dict]) -> list[dict]:
    """
    의미적 유사도와 구조적 패턴을 동시에 고려하여 클러스터링.
    두 결과를 합성하여 최종 문서 모델을 생성합니다.
    """
    # 1) 의미적 클러스터링: 임베딩 기반 유사도
    semantic_clusters = cluster_by_embedding(chunks, threshold=0.85)
    
    # 2) 구조적 클러스터링: 패턴 인식 (조항 유형, 테이블 레이아웃 등)
    structural_clusters = cluster_by_pattern(chunks)
    
    # 3) 투영(Projection) 알고리즘: 두 클러스터를 정렬하고 합성
    enriched_model = project_and_merge(
        semantic_clusters, 
        structural_clusters
    )
    
    return enriched_model

왜 이중 클러스터링이 중요한가?

LLM만으로는 문서의 '의미'는 잘 잡아내지만, '구조적 맥락'을 놓치는 경우가 많습니다. 예를 들어, "3층까지 건물을 올린다"는 조항이 본문에 있고, 별첨(Exhibit)에 "지하 2층 주차장"이 있다면, LLM은 이를 별개의 내용으로 볼 수 있습니다. 하지만 구조적 분석을 통해 '이 문서는 본문+별첨 구조'라는 것을 인지하면, 두 내용을 통합 해석할 수 있습니다.

3단계: 프롬프트 최적화 피드백 루프 — Few-shot에서 Multi-shot으로

가장 중요한 단계입니다. Doczy.ai는 단순히 프롬프트를 한 번 작성하고 끝내지 않습니다.

# 프롬프트 최적화 피드백 루프 개념

class PromptOptimizer:
    """
    실제 출력 결과를 기반으로 지속적으로 프롬프트를 개선하는 루프.
    Few-shot → Multi-shot으로 진화하며 정확도를 높입니다.
    """
    def __init__(self):
        self.base_prompt = """
        다음 계약서 조항에서 주요 정보를 추출하세요:
        - 당사자 이름
        - 계약 금액
        - 유효 기간
        - 해지 조건
        """
        self.example_pool = []  # 과거 성공/실패 사례 저장
    
    def generate_optimized_prompt(self, document_type: str) -> str:
        # 도메인별 few-shot 예제 선택
        relevant_examples = self.select_examples(document_type)
        
        # 최근 실패 사례를 바탕으로 경고 문구 추가
        failure_patterns = self.analyze_recent_failures()
        
        optimized = f"""
        {self.base_prompt}
        
        [참고 예제]
        {relevant_examples}
        
        [주의사항]
        - {failure_patterns}
        - 중첩된 별첨이 있는 경우 반드시 본문과 함께 해석할 것
        """
        return optimized

실무 적용 포인트:

  • Few-shot → Multi-shot: 단순히 예제 2~3개를 주는 것을 넘어, 실제 출력 결과와 비교하며 지속적으로 프롬프트를 수정합니다.
  • 오류 패턴 피드백: '이런 경우에 자주 틀리더라'라는 패턴을 축적하여 프롬프트에 경고로 추가합니다.
  • 도메인 특화: 의료 계약서와 금융 계약서는 프롬프트가 달라야 합니다. 문서 분류(File Class)를 먼저 수행한 후, 그에 맞는 프롬프트 템플릿을 선택하는 구조입니다.

이 3단계 루프가 제대로 작동하면, 시간이 지날수록 에이전트의 정확도가 향상되는 선순환이 만들어집니다. Doczy.ai의 경우 22개월 동안 2.5백만 건의 계약서를 처리하며 99% 정확도를 유지하고 있습니다.

Cloud infrastructure diagram with AWS services like Lambda, S3, and Bedrock connected in a pipeline Algorithm Concept Visual

한국 개발 생태계에서의 적용 맥락

국내 SI/금융권 문서 자동화에 주는 시사점

국내에서는 아직도 많은 금융사, 공공기관이 규칙 기반(Rule-based) 문서 처리에 의존하고 있습니다. Doczy.ai 사례가 주는 핵심 교훈은 다음과 같습니다.

  1. 규칙 기반(55% 정확도) → AI 기반(99% 정확도)으로의 도약이 현실적입니다.

    • 국내에서도 금융감독원 전자공시, 특허 문서, 건설 계약서 등에 적용 가능합니다.
    • 단, 초기 도입 시에는 '100% 자동화'보다는 '인간 검토자 + AI 보조' 방식으로 시작하는 것이 안정적입니다.

  2. 스마트 청킹이 특히 중요합니다.

    • 한국어 문서는 영어보다 조사, 어미 변화가 복잡하고, 표/목록 구조가 자주 등장합니다.
    • 단순 토큰 기반 청킹은 한국어에 특히 취약하므로, 형태소 분석 + 구조 인식을 결합한 청킹 전략이 필요합니다.

  3. 프롬프트 최적화 루프는 '지식 관리'의 문제입니다.

    • 실무에서 가장 간과하기 쉬운 부분이 '오류 사례 수집 및 피드백'입니다.
    • 단순히 LLM API만 붙이는 프로젝트는 실패할 확률이 높습니다. 에이전트가 틀린 케이스를 체계적으로 수집하고, 프롬프트에 반영하는 프로세스를 먼저 설계해야 합니다.

이 기술의 한계 또는 주의사항

  • 초기 구축 비용: 스마트 청킹, 이중 클러스터링은 단순 RAG보다 엔지니어링 비용이 높습니다. 소규모 프로젝트에는 오버엔지니어링일 수 있습니다.
  • 도메인 전문성: 99% 정확도는 의료 계약서에 특화된 결과입니다. 다른 도메인(예: 특허, 부동산)에 적용하려면 처음부터 다시 학습시켜야 합니다.
  • LLM 비용: 137M API 호출, 442B 토큰은 상당한 비용입니다. 비용 대비 효용을 계산하고, 꼭 필요한 부분에만 LLM을 사용하는 하이브리드 접근이 중요합니다.

다음 단계 학습 방향

  1. RAG(Retrieval-Augmented Generation) 기본기 다지기: LangChain, LlamaIndex를 활용한 기본 RAG 구현부터 시작하세요.
  2. 문서 구조 분석 라이브러리 탐색: python-layoutparser, pdfplumber 등으로 문서 구조를 추출하는 연습을 해보세요.
  3. 프롬프트 엔지니어링 고도화: 단순 프롬프트 작성이 아니라, Few-shot, Chain-of-Thought, Self-Consistency 등 다양한 기법을 실험해보세요.
  4. AWS Bedrock + Lambda 기반 파이프라인 구축: 실제 서버리스 아키텍처로 문서 처리 파이프라인을 직접 만들어보는 것이 가장 좋은 학습입니다.

참고: 이 글에서 다룬 피드백 루프 개념은 AI 코딩 에이전트에도 동일하게 적용됩니다. AI 코딩 에이전트, 예측 가능한 결과를 만드는 핵심 강력한 피드백 루프에서 더 자세한 내용을 확인하세요. 또한 최신 LLM 모델 비교와 AI 게이트웨이 구성에 관심이 있다면 DeepSeek V4, Vercel AI Gateway에 정식 등장 Pro vs Flash 완벽 비교도 함께 읽어보시길 추천합니다.

Data analyst reviewing contract insights dashboard with charts and key metrics Coding Session Visual

결론: 예측 가능한 AI 에이전트는 '설계'의 문제다

Doczy.ai 사례가 명확히 보여주듯, AI 에이전트의 예측 가능성은 '어떤 LLM을 쓰는가'보다 '어떻게 피드백 루프를 설계하는가' 에 달려 있습니다.

단순히 GPT-4o나 Claude를 API로 호출하는 것을 넘어, 다음과 같은 질문을 스스로에게 던져보세요.

  • 입력 전처리: 내 문서의 구조를 보존하면서 청킹하고 있는가?
  • 분석 엔진: 의미와 구조를 동시에 고려하고 있는가?
  • 피드백 메커니즘: 출력 결과를 분석하여 프롬프트를 지속적으로 개선하고 있는가?

이 세 가지 질문에 모두 'Yes'라고 답할 수 있다면, 당신의 AI 에이전트는 이미 예측 가능한 수준에 도달한 것입니다. 아니라면, 지금부터라도 피드백 루프를 설계에 포함시키세요. 그래야만 AI가 단순한 '신기술'이 아니라, 비즈니스에 실제 가치를 더하는 '도구'가 될 수 있습니다.

근거자료: Automating contract intelligence with Doczy.ai™ on AWS - AWS Architecture Blog

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.