LLM이 코드를 검증할 때: 도박을 공학으로 바꾸는 수식, 4/δ

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

최근 저희 팀은 LLM(거대언어모델)을 활용해 레거시 코드의 안정성을 높이는 작업을 진행하고 있습니다. 개발자가 코드를 짜면 AI가 이를 분석하고, 테스트 케이스를 만들고, 심지어 수학적으로 검증(Formal Verification)까지 시도하는 파이프라인을 구축하는 것이죠. 그런데 이 과정에서 우리를 가장 괴롭히는 건 '불확실성'이었습니다. 똑같은 프롬프트를 넣어도 어떨 때는 한 번에 통과하고, 어떨 때는 무한 루프를 돌며 API 비용만 태우기 일쑤였습니다. 마치 슬롯머신 레버를 당기는 기분이랄까요. 엔지니어링 리더로서 이런 '운'에 의존하는 시스템을 프로덕션에 올릴 수는 없었습니다.

그러다 최근 흥미로운 연구 결과 하나를 접했습니다. 'The 4/δ Bound'라는 제목의 논문인데, 이 문서는 LLM을 이용한 검증 시스템을 막연한 블랙박스가 아닌 예측 가능한 공학적 모델로 정의하고 있습니다. 오늘은 이 논문이 주는 통찰과, 우리가 LLM 시스템을 설계할 때 가져야 할 태도에 대해 이야기해 보려 합니다.

무한 루프의 공포와 마르코프 체인

보통 LLM 기반의 에이전트 시스템을 만들 때 우리는 '생각의 고리(Chain of Thought)'나 'Reflexion' 같은 기법을 씁니다. "틀렸어? 다시 고쳐봐"라는 식의 반복문이죠. 문제는 이 반복이 언제 끝날지 아무도 모른다는 겁니다. 운이 나쁘면 영원히 수렴하지 않고 발산해버립니다.

이 논문의 저자들은 이 과정을 단순히 '반복'으로 보지 않고 '순차적 흡수 마르코프 체인(Sequential Absorbing Markov Chain)'으로 모델링했습니다. 검증 과정을 CodeGen(코드 생성), Compilation(컴파일), InvariantSynth(불변식 합성), SMTSolving(SMT 해결)이라는 4단계로 나누고, 각 단계가 성공할 확률을 δ(델타)라고 정의했죠.

여기서 아주 아름다운 수식이 등장합니다. 시스템이 검증 완료(Verified) 상태에 도달하기까지 필요한 시도 횟수의 기댓값(E[n])은 정확히 4/δ 이하라는 것입니다.

왜 4/δ인가?

이 수식이 주는 의미는 단순히 수학적 증명에 그치지 않습니다. 이것은 우리의 막연한 불안감을 '예산'이라는 숫자로 바꿔줍니다.

만약 각 단계의 성공 확률(δ)이 0이 아니라면, 시스템은 언젠가 반드시 성공합니다. 그리고 그 비용은 4/δ로 수렴합니다. 저자들은 무려 9만 번 이상의 실험을 통해 이 이론을 검증했는데, 실제 데이터가 이론적 예측값과 놀라울 정도로 일치했습니다. 즉, 우리가 LLM 파이프라인을 짤 때 "이게 과연 끝날까?"를 걱정할 게 아니라, "각 단계의 성공 확률 δ를 어떻게 높일 것인가?"에 집중해야 한다는 뜻입니다.

휴리스틱을 넘어 아키텍처로

풀링포레스트 팀에서도 이 원리를 적용해 보았습니다. 이전에는 LLM이 답을 못 찾으면 "프롬프트를 좀 더 친절하게 바꿔볼까?"라며 감에 의존한 수정을 했습니다. 하지만 이제는 파이프라인을 4단계로 명확히 나누고, 각 단계의 병목이 어디인지 측정합니다.

예를 들어, 컴파일은 잘 되는데 SMT Solving 단계에서 자꾸 실패한다면, 전체 파이프라인을 재실행하는 게 아니라 해당 단계의 δ를 높이기 위해 파라미터를 동적으로 보정해야 합니다. 논문에서는 이를 통해 운영 구역을 한계(marginal), 실용(practical), 고성능(high-performance)으로 나누고 있습니다. δ값이 너무 낮아 '한계' 영역에 있는 작업을 무리하게 돌리면 리소스만 낭비하게 되니, 아예 일찍 실패(Fail Fast) 시키는 전략을 짤 수도 있게 된 것이죠.

결론: 예측 가능함이 곧 신뢰다

우리는 AI를 마법 지팡이처럼 여기는 경향이 있습니다. 하지만 CTO로서, 그리고 엔지니어로서 우리가 해야 할 일은 그 마법을 예측 가능한 기술로 길들이는 것입니다. 4/δ라는 경계값은 우리에게 "막연한 추측을 멈추고, 확률을 계산하라"고 말합니다.

여러분이 만드는 AI 서비스나 사내 도구가 혹시 '운'에 기대고 있지는 않나요? 시스템의 각 모듈이 가진 성공 확률을 측정해 보세요. 그리고 그 확률을 기반으로 비용과 시간을 계산해 보세요. 그때 비로소 불안한 도박판이 견고한 엔지니어링의 영역으로 들어오게 될 것입니다. 안전이 중요한 소프트웨어일수록, 우리는 더 집요하게 예측 가능성을 설계해야 합니다.