AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

LLM 파이프라인 통과율 37%→94%, 블랙잭으로 증명한 설계 원칙

블랙잭 시뮬레이션을 LLM으로 돌렸더니 초기 통과율이 37%였습니다. 8번의 개선 끝에 94%까지 끌어올렸는데, 가장 큰 도약을 만든 건 프롬프트 개선도, 모델 교체도 아니었습니다. LLM이 하던 작업 하나를 10줄짜리 코드로 교체한 것이었습니다.

사진 출처: O’Reilly Radar

O’Reilly Radar에 엔지니어 Andrew Stellman이 LLM 파이프라인의 신뢰도 문제를 직접 실험한 글을 발표했습니다. 수백 번의 블랙잭 시뮬레이션을 반복하며 도달한 결론은 하나입니다. LLM이 어떤 작업을 ‘할 수 있다’는 것과 ‘LLM이 해야 한다’는 것은 다릅니다.

출처: Keep Deterministic Work Deterministic – O’Reilly Radar

실패가 쌓이는 구조, 나인의 행진

멀티스텝 LLM 파이프라인에는 단일 프롬프트와 다른 신뢰도 문제가 있습니다. 각 단계의 출력이 다음 단계의 입력으로 이어지는 구조에서는, 한 단계의 작은 오류가 이후 모든 단계로 전파됩니다.

Stellman은 이를 ‘나인의 행진(March of Nines)’으로 설명합니다. 시스템 신뢰도를 90%에서 99%로 올리는 데 드는 엔지니어링 노력이, 처음 90%를 달성하는 것과 맞먹습니다. 99%에서 99.9%도 마찬가지입니다. 각 단계가 95% 신뢰도를 가져도 7단계 파이프라인의 전체 신뢰도는 약 70%로 떨어집니다. 그리고 결과물은 항상 그럴듯하게 보입니다. 어디서 망가졌는지 모른 채 잘못된 결과를 받아들이게 되는 것이 더 큰 문제입니다.

실제로 Stellman의 첫 번째 파이프라인은 57% 통과율을 보고했지만, 데이터를 직접 확인해보니 검증 단계 자체에 버그가 있어서 거의 모든 결과가 그냥 통과되고 있었습니다. LLM이 검증을 담당하고 있었고, 그 LLM이 제대로 검증하지 않았습니다. 버그를 수정하고 나서야 실제 통과율이 31%라는 게 드러났습니다.

8번의 반복이 만든 37%→94%

31%에서 출발한 파이프라인이 어떻게 94%에 도달했는지, 개선 단계를 따라가 보면 패턴이 보입니다.

  1. 데이터 구조 개선 (31%→37%): LLM이 덱(deck) 안에서 자신의 위치를 계속 잃어버렸습니다. 데이터를 재구성해 LLM이 추적할 상태 정보를 줄였습니다.
  2. 연쇄 사고(Chain of Thought) 도입 (37%→48%): 최종 답만 내놓게 하는 대신 계산 과정을 단계별로 보여주도록 강제했습니다. 오류가 절반가량 줄었지만, 토큰과 시간이 더 들었습니다.
  3. LLM 검증자를 코드로 교체 (48%→79%): 이것이 단일 최대 개선입니다. 전략 준수 여부를 판단하던 두 번째 LLM 호출을 결정론적 룩업 테이블로 바꾼 것만으로 31%포인트가 올랐습니다. 해당 LLM은 올바른 규칙 대신 자신이 아는 블랙잭 상식으로 판단하고 있었고, 그 정확도가 27%에 불과했습니다.
  4. 출력 형식 강제, 반직관적 규칙 명시, 모델 교체를 거쳐 84%→94%에 도달했습니다.

LLM이 할 수 있다는 것과 해야 한다는 것

전략 검증은 처음에 판단이 필요한 작업처럼 느껴졌습니다. 그래서 LLM에게 맡겼습니다. 그런데 실제로 그 단계가 하는 일을 들여다보니, 특정 패에 대한 정답을 표에서 찾아오는 것이었습니다. 판단이 아니라 조회였습니다.

이 글이 제시하는 핵심 질문은 파이프라인을 설계할 때 각 단계마다 던져야 하는 것입니다. “이 단계가 실제로 판단을 필요로 하는가, 아니면 짧은 코드로 완벽하게 처리할 수 있는 결정론적 작업인가?” 카드 합산, 규칙 조회, 조건 분기는 코드가 매번 100% 정확하게 처리합니다. LLM에게 맡기면 대부분은 맞지만, 틀렸을 때 그 오류가 파이프라인 전체로 번집니다.

그 코드를 작성하는 데도 LLM을 쓸 수 있다는 점도 주목됩니다. Stellman은 글에서 실제로 채점 로직에 실패한 LLM에게 “방금 한 작업을 파이썬 스크립트로 작성해봐”라고 했더니, 모든 단계에서 정답을 맞히는 코드를 즉시 작성했다고 합니다. LLM은 결정론적 로직을 만드는 데는 능하지만, 그 로직을 매번 다시 실행하는 데는 불안정합니다.

파이프라인을 구축하거나 에이전트 워크플로를 설계하는 분이라면, 8번의 반복과 수백 번의 실험이 담긴 원문을 직접 읽어볼 만합니다. 각 개선 단계의 데이터와 실패 패턴이 상세하게 기록되어 있습니다.


AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)

Comments

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다