이미 수학적으로 정답임이 증명된 알고리즘을 AI에게 계속 검사시키면 어떻게 될까. HVM·Bend 프로그래밍 언어를 만든 개발자 테일린(Taelin, @VictorTaelin)이 지난 8월 9일 새벽(한국시간 오전 3시 30분) X에 던진 이 질문의 답은 예상 밖이었다. 완벽했던 코드가 몇 차례 루프만에 망가졌다는 것이다. 이 게시물은 조회수 5.8만, 리포스트 84회, 좋아요 약 1,300회를 기록하며 개발자 커뮤니티에서 빠르게 퍼졌다. 원문 게시물은 여기서 확인할 수 있다.
"정답인 코드"를 AI에게 계속 감사시켰더니
테일린이 설계한 실험은 단순하다. 그는 GPT-5.6 Pro(OpenAI가 2026년 7월 공개한 GPT-5.6 계열의 최상위 모델)와 Fable 5(앤트로픽이 같은 해 6월 선보인 클로드 계열 최신 모델의 코드네임)를 짝지어 다음과 같은 루프를 반복했다.
- 1단계: GPT-5.6 Pro가 알고리즘 코드를 감사(audit)하며 버그를 찾는다.
- 2단계: Fable 5가 GPT가 지적한 버그를 고친다.
- 3단계: 이 과정을 다시 반복한다.
핵심은 함정이었다. 이 루프에 넣은 알고리즘은 이미 올바름이 증명된, 문자 그대로 "정답" 코드였다. 고칠 버그가 애초에 없는 코드를 넣고 감사·수정 루프를 돌린 것이다. 결과는 완전한 붕괴였다. 초반 몇 차례 루프만에 정답이었던 알고리즘이 오답으로 바뀌었고, 이후 루프에서는 그 오답을 다시 "패치"하는 과정이 반복됐다. 문제는 이 패치들이 새로운 케이스와 새로운 버그를 계속 만들어냈다는 점이다. 테일린은 이 과정이 코드가 완전히 파괴될 때까지 멈추지 않았다고 전했다.
왜 정답인 코드도 "버그처럼" 보이는가
테일린이 짚은 원리는 명확하다. LLM에게 "코드를 감사해달라"고 요청하면, 모델은 실제로는 "이 코드에 버그처럼 보이는 패턴이 있는가?"라는 질문에 답하고 있을 뿐이라는 것이다. 문제는 많은 코드 패턴이 "버그처럼 보이면서도" 실제로는 정확하다는 데 있다. 그리고 이미 옳은 것을 "고치는" 행위는 그것을 틀리게 만들 뿐이다.
| 구분 | 버그처럼 보이는 패턴 | 실제 버그 |
|---|---|---|
| 판단 기준 | 익숙하지 않은 구조, 관용적이지 않은 분기 | 실행 결과가 명세와 어긋남 |
| LLM의 반응 | "수정 필요"로 표시 | 수정이 실제로 정확성을 개선 |
| 루프에서의 결과 | 정답 코드를 오답으로 만듦 | 오답 코드를 정답으로 만듦 |
이 실험이 흥미로운 지점은 테일린이 이를 "LLM은 코드를 못 본다"는 식의 비관론으로 끝내지 않았다는 것이다. 그는 모델이 더 똑똑해질수록 "버그처럼 보이는 것"과 "실제 버그"의 간극이 좁혀져, 실질적으로 거의 100%의 경우에 둘이 일치하게 될 것이라 전망했다. 그리고 "우리는 그 지점에 꽤 가까워졌다고 생각하며, 오차율이 충분히 낮아져 이런 루프가 실제로 작동하기 시작하는 순간이 오면 흥미로울 것"이라고 덧붙였다. 다만 "2026년 현재로서는 아직 거기에 도달하지 못했다"는 게 그의 결론이다.
자동 리뷰·자동 수정 파이프라인을 짜는 개발자가 조심할 것
에이전트에게 코드 리뷰와 수정을 맡기는 파이프라인을 설계하고 있다면 이 실험은 단순한 흥밋거리가 아니다. "AI가 AI를 감사하고 고치게 하면 코드 품질이 올라간다"는 직관은, 적어도 이미 검증된 코드에 반복 적용할 경우 정반대로 작동할 수 있다는 점을 이 사례는 보여준다. 실무적으로 점검해볼 만한 지점은 다음과 같다.
- 무한 루프를 걸지 마라. "지적 사항이 없을 때까지" 감사·수정을 반복시키는 설계는, 모델이 어떤 식으로든 "지적할 거리"를 만들어낼 가능성을 늘 열어둔다. 종료 조건을 감사자의 침묵이 아니라 테스트 통과·회귀 여부 같은 객관적 기준으로 잡아야 한다.
- 수정 전후 테스트 스위트로 회귀를 검증하라. "버그처럼 보이는 패턴"을 고쳤을 때 기존 테스트가 깨지는지 확인하는 안전망이 없으면, 패치가 패치를 부르는 악순환을 사람이 눈치채기 어렵다.
- 이미 검증된 핵심 로직은 감사 루프 대상에서 제외하는 것도 방법이다. 특히 증명되었거나 장기간 프로덕션에서 검증된 코드라면, 매 커밋마다 AI 감사를 다시 태우는 것이 오히려 리스크가 될 수 있다.
- 감사자와 수정자를 같은 모델로 쓰지 마라. 테일린의 실험처럼 서로 다른 모델(GPT-5.6 Pro ↔ Fable 5)을 쓰면 편향이 상쇄될 것 같지만, 실제로는 "버그처럼 보인다"는 판단 자체의 오류율이 누적되며 문제가 더 커질 수 있다는 점에 유의해야 한다.
논문이 아니라 개인 실험
이 글의 근거는 테일린 한 사람이 X에 직접 밝힌 실험 결과이며, 논문이나 벤치마크로 공개된 재현 가능한 연구가 아니다. 실험에 사용된 알고리즘의 종류, 루프 반복 횟수, "이미 증명된 정답"이라는 판단의 근거, 프롬프트 설계 등 세부 사항은 게시물 본문에 나와 있지 않고, 제3자가 동일 조건에서 재현했다는 보고도 아직 확인되지 않는다.
테일린은 HVM(고차 가상머신)과 GPU에서 동작하는 고수준 언어 Bend를 만든 HigherOrderCO 설립자로, 프로그래밍 언어·형식 검증 분야에서 실제 성과를 낸 인물이다. 다만 그는 LLM의 추론 능력을 두고 공개적으로 강한 주장을 던지고 이를 검증받는 방식의 실험을 자주 벌여온 것으로도 알려져 있다 — 예컨대 2024년에는 "GPT 계열 모델은 특정 추론 문제(A::B)를 절대 풀지 못한다"며 1만 달러 현상금을 걸었다가, 다른 개발자들이 프롬프트만으로 하루 만에 풀어내면서 논쟁이 된 전례가 있다. 이번 감사 루프 실험 역시 같은 맥락의 개인 실험으로 봐야 하며, 결과 자체는 구조적으로 설득력이 있지만 "모든 감사 루프가 이렇게 작동한다"는 일반화까지 단정할 근거는 아직 부족하다. 자동 감사·수정 파이프라인을 프로덕션에 도입하기 전에는, 이 사례를 경고 신호로 삼되 자신의 코드베이스와 모델 조합으로 소규모 검증을 먼저 해보는 것이 안전하다.
