5.2리스크와 한계, 실패 양상

"모델이 틀렸다"는 진술은 진단에 쓸모가 없습니다. 원인이 다르면 대응도 다르기 때문입니다. 실무에서 쓸 만한 분류는 다음과 같습니다.

유형	증상	주된 원인
사실성 실패	그럴듯하지만 틀린 내용	근거 부재, 검색 실패
지시 이탈	형식·범위를 벗어난 응답	프롬프트 모호성, 컨텍스트 과부하
도구 오용	잘못된 도구나 인자 선택	설명 부실, 도구 과다
컨텍스트 손실	앞선 합의를 잊음	윈도우 초과, 압축 손실
비결정성	같은 입력에 다른 결과	표본 추출 특성
자원 폭주	비용·지연 급증	루프 미종료, 컨텍스트 누적
보안 실패	유출, 인젝션 성공	신뢰 경계 부재, 과잉 권한

이 분류가 유용한 이유는 관측 지점이 유형마다 다르기 때문입니다. 사실성 실패는 출력 대조로, 자원 폭주는 토큰·턴 수 계측으로, 컨텍스트 손실은 대화 길이와 실패율의 상관으로 잡습니다. 진단 수업(4.4)과 이어지는 지점이니 함께 묶어 기억해 두십시오.

환각(hallucination)은 모델이 근거 없이 그럴듯한 내용을 생성하는 현상입니다. 아키텍트가 알아야 할 것은 원리보다 어떤 설계가 발생률을 낮추고, 무엇이 남는가입니다.

발생률을 낮추는 설계는 대체로 세 가지입니다.

• 근거 제공 — 검색으로 관련 문서를 넣어 주면 모델이 지어낼 여지가 줄어듭니다.
• 모른다고 답할 여지 — 시스템 프롬프트에서 근거가 없으면 모른다고 답하도록 명시적으로 허용합니다. 이 문장이 없으면 모델은 답을 만들어 내는 쪽으로 기웁니다.
• 인용 강제와 대조 — 응답에 출처를 달게 하고, 그 출처가 실제 검색 결과에 있는지 기계적으로 대조합니다.

여기서 중요한 한계가 있습니다. 검색을 붙였다고 환각이 사라지지 않습니다. 검색이 엉뚱한 문서를 가져오면 모델은 그 문서를 근거로 자신 있게 틀린 답을 만듭니다. 공식 요강의 예시 문항이 바로 이 상황을 묻습니다. 문서 갱신 직후 확신에 찬 오답이 늘고 지연시간과 모델 버전은 그대로라면, 원인은 모델이 아니라 검색·인덱싱 단계입니다.

# 근거 대조: 인용된 문서가 실제로 검색 결과에 있었는지 확인
cited = {c["doc_id"] for c in response["citations"]}
retrieved = {d["doc_id"] for d in retrieved_docs}
if not cited.issubset(retrieved):
    # 모델이 검색 결과 밖의 무언가를 근거로 들었다
    log.warning("근거 밖 인용", extra={"missing": cited - retrieved})

이 대조는 값싸고 효과가 큽니다. 환각 자체를 없애지는 못하지만, 환각이 일어났다는 사실을 탐지 가능하게 만들기 때문입니다.

단발 호출에는 없고 에이전트 구조에서만 생기는 실패가 있습니다. 시험에서 자주 다루는 것은 네 가지입니다.

루프 미종료 — 같은 도구를 같은 인자로 반복 호출하며 멈추지 않습니다. 원인은 대개 도구가 빈 결과를 돌려줄 때 무엇을 해야 하는지 설명이 없기 때문입니다. 반복 상한은 폭주를 끊는 최후 방어선이지 원인 해결책이 아닙니다.

부분 완료 후 완료 선언 — 다섯 단계 중 셋만 끝내고 작업이 끝났다고 보고합니다. 검증 수단이 없는 에이전트에서 특히 잦습니다. 완료 조건을 모델의 판단이 아니라 기계적으로 확인 가능한 기준으로 두어야 합니다.

도구 결과 오해 — 오류 응답을 성공으로 읽거나, 빈 배열을 "없음"이 아니라 "실패"로 해석합니다. 구조화된 오류 응답과 명시적 상태 필드가 완화책입니다.

누적 오류 — 초반의 작은 오판이 이후 모든 단계의 전제가 됩니다. 단계마다 검증을 넣으면 전파를 끊을 수 있지만 비용이 늘어, 어디에 검증을 넣을지가 설계 판단이 됩니다.

# 완료를 모델의 선언이 아니라 기계 검증으로 확인한다
def is_done(state):
    return (
        state["tests_pass"]          # 테스트 통과
        and state["lint_clean"]      # 린트 통과
        and not state["todo_left"]   # 남은 항목 없음
    )

마지막 줄이 요점입니다. "끝났다"를 모델에게 묻지 말고 시스템이 판정하게 만들면 부분 완료 실패가 크게 줄어듭니다.

아키텍트의 일은 실패를 아는 데서 끝나지 않고 문서로 남겨 의사결정에 쓰이게 하는 데까지입니다. 실무에서 통용되는 형태는 실패 양상 표입니다. 각 행에 다음을 채웁니다.

• 실패 양상 — 무엇이 잘못되는가
• 영향 — 사용자와 사업에 미치는 결과, 되돌릴 수 있는지
• 발생 가능성 — 관측된 빈도 또는 추정
• 탐지 수단 — 이 실패가 일어났음을 어떻게 아는가
• 완화책 — 어느 층에서 무엇으로 막는가
• 잔여 리스크 — 완화 후에도 남는 것과 그것을 수용하는 근거

가장 자주 비는 칸은 탐지 수단입니다. 탐지할 수 없는 실패는 완화책이 작동하는지도 알 수 없으므로, 이 칸이 비어 있으면 그 행의 완화책은 검증되지 않은 주장입니다.

잔여 리스크 칸도 중요합니다. 모든 리스크를 없앨 수는 없고, 남는 리스크를 명시적으로 수용하는 것이 이해관계자와의 기대치 정렬(6.3)에서 근거가 됩니다. "이 시스템은 안전합니다"라는 문장보다 "이 세 가지 실패는 남으며, 각각을 이렇게 탐지하고 이렇게 대응합니다"가 훨씬 방어 가능한 진술입니다.