끝났다는 말을 믿게 만드는 법, Humanize가 설계한 판단의 자리

안녕하세요, 패트릭입니다.

Humanize: Judgement Engineering for Agentic Coding라는 이름으로 arXiv 2610.08900에 공개된 작업은 에이전트 코딩에서 완성을 어떻게 믿을 수 있게 만들지를 다룹니다. 이 작업이 내세우는 주장은 한 문장으로 정리됩니다. 코드를 쓰는 에이전트에게 완성 여부를 맡기지 말고, 계획과 실행과 검토와 학습 사이에 사람이 승인하고 기계가 강제하는 판단 지점을 끼워 넣자는 것입니다. 원문으로 이어지는 링크는 이 글 제목 아래에 걸어 두었습니다.

왜 완성됐다는 말이 가장 믿기 어려울까

코드를 대신 짜주는 도구를 써본 분이라면 비슷한 경험을 해보셨을 겁니다. 처음 몇 분은 감탄이 나오는데, 어느 순간부터는 다른 걱정이 생깁니다. 돌아는 가는데 이게 다 된 건지, 테스트가 초록색인데 제출해도 되는 건지, 그 판단이 서지 않는 것이죠. 그렇다면 완성을 확인하는 일은 왜 쓰는 일보다 더 어려울까요?

이 작업은 그 질문에서 출발합니다. 코드를 만들어내는 일은 이제 싸졌지만, 믿음직하게 마무리하는 일은 여전히 어렵다는 진단입니다. 제가 이 진단에 고개를 끄덕인 이유는 현장의 감각과 맞닿아 있기 때문입니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 코드 생성도 마찬가지인데, 생성 속도는 빨라졌지만 완성을 선언하는 권한이 어디에 있는지는 흐릿해진 경우가 많습니다.

여기서 이 작업이 던지는 문장은 꽤 직설적입니다. 코드를 쓴 에이전트는 그 코드가 끝났는지를 판단하는 데 약한 심사자라는 것입니다. 쓴 사람이 자기 원고를 교정하기 어려운 것과 비슷한데, 왜냐하면 자기가 본 것은 의도이고 남이 보는 것은 결과이기 때문입니다. 그래서 Humanize는 처음부터 쓰는 힘보다 판단의 자리를 먼저 설계합니다. 그렇다면 그 자리는 어떻게 생겼을까요?

코드를 쓰는 손과 끝났다고 말하는 입을 떼어놓으면 무슨 일이 생길까

Humanize를 한 장면으로 줄이면 이렇습니다. 여기서 사람이 계획 계약(plan contract)을 승인하면 빌더(builder) 에이전트가 라운드 단위로 구현하고, 그 끝에서 완성을 선언하는 쪽은 다른 벤더의 리뷰어(reviewer) 에이전트입니다. 그래서 쓰는 역할과 끝났다고 말하는 역할이 처음부터 다른 주체에게 나뉘어 있는데, 저는 이 분리가 전체 설계의 뼈대라고 봅니다.

그렇다면 왜 같은 모델이 두 역할을 겸하면 안 될까요? 이유는 스스로 채점하는 시험처럼 관대해지기 쉽기 때문인데, 특히 에이전트 코딩에서는 그 관대함이 조용히 쌓여 멈추는 지점을 뒤로 밀기 때문입니다. 이를테면 테스트 몇 개를 통과하면 된 것으로 보고 남은 찜찜함을 다음 라운드로 미루는데, 그러다 보면 어느새 완료의 기준 자체가 미끄러집니다. 반면 쓰는 쪽과 보는 쪽이 다르면 대화가 달라집니다. 이때 빌더는 어떻게든 앞으로 가려 하고, 리뷰어는 아직 안 된 이유를 찾으려 하기 때문에 전체가 앞으로 가면서도 선을 넘지 않습니다. 저는 이 긴장 자체가 설계라고 봅니다. 그 팽팽함에서는 한쪽이 밀어야 가고 다른 한쪽이 잡아당겨야 멈추는데, 저는 이 당김이 없으면 완성이란 말이 헛돈다고 봅니다.

여기서 눈에 띄는 선택이 하나 더 있습니다. 그것은 리뷰어를 다른 벤더의 모델로 두었다는 점인데, 같은 집안 식구끼리 심사하면 공유된 버릇까지 그대로 통과될 수 있기 때문입니다. 이를 사람 조직으로 치면 같은 팀원이 아니라 다른 부서 사람에게 감리를 맡기는 셈인데, 저는 이 비유가 딱 맞다고 봅니다. 그런데 이것만으로 모든 편향이 사라지지는 않습니다. 그렇다면 남은 구멍은 누가 막을까요? 그 답이 다음 장면에 나옵니다.

사람 승인 한 줄이 전체 작업의 방향을 고정한다

Humanize에서 사람은 구경꾼이 아닙니다. 계획 계약이라는 문서에 직접 서명하는 역할인데, 무엇을 만들지, 어디까지가 범위인지, 무엇으로 완성을 가릴지를 미리 적어 두는 약속입니다. 빌더가 아무리 빨리 달려도 이 계약에서 벗어나면 소용이 없게 되는 것이죠. 건축으로 치면 착공 도면에 도장을 찍는 일과 비슷합니다.

이 장치가 마음에 드는 이유는 실패의 모양을 바꾸기 때문입니다. 계약이 없으면 에이전트는 중간에 목표를 슬쩍 바꾸면서도 일을 했다고 말할 수 있습니다. 어렵던 부분을 빼고 쉬운 부분만 끝내놓고는 완료라고 보고하는 식인데, 이런 미끄러짐은 로그를 봐도 잡아내기 어렵습니다. 그런데 계약이 있으면 이야기가 달라집니다. 나중에 리뷰어가 물을 수 있는 말이 미리 정해져 있기 때문인데, "그건 계약서에 있었나요"라는 한 마디가 전체 라운드를 붙잡습니다.

그렇다면 사람은 매번 코드를 읽어야 할까요? 이 작업이 그리는 그림은 그보다 가볍습니다. 사람은 매 줄을 검수하는 대신 방향과 종료 조건을 승인하고, 그 뒤의 왕복은 에이전트와 기계 장치에 맡깁니다. 저는 이 분담이 현실적이라고 봅니다. 사람의 시간은 비싸고 주의력은 금방 닳는데, 판단이 필요한 자리에만 사람을 앉히면 전체 비용이 낮아지기 때문입니다. 다만 계약 자체가 부실하면 이후 단계가 아무리 정교해도 소용이 없습니다. 그래서 다음 질문이 바로 따라옵니다. 계약 다음의 흐름은 누가 지키나요.

라우팅을 모델에게 맡기지 않는 편이 속 편한 이유

Humanize에서 다음 역할로 일을 넘기는 일은 모델이 아니라 결정적 후크(deterministic hook)가 맡습니다. 계획이 끝나면 사람 승인으로, 구현 라운드가 끝나면 리뷰어로, 리뷰가 끝나면 학습 단계로 이어지는 식인데, 이 길목마다 72개의 기계적 관문이 걸려 있습니다. 모델이 기분에 따라 지름길을 찾지 못하게 턱을 깔아둔 셈입니다.

저는 이 숫자를 처음 보고 피식했습니다. 72개라니, 너무 빽빽한 것 아닌가 싶었기 때문입니다. 그런데 조금 더 생각해보니 그 빽빽함이 의도라는 생각이 들었습니다. 에이전트 시스템에서 가장 흔한 고장은 모델이 똑똑하지 않아서가 아니라, 절차를 슬쩍 건너뛰기 때문입니다. 리뷰를 했다고 말만 하고 기록을 남기지 않거나, 학습 단계에서 얻은 교훈을 다음 계획에 반영하지 않는 식인데, 이런 누락은 개별적으로 보면 작아 보여도 쌓이면 전체를 무너뜨립니다. 그래서 관문을 코드로 박아두면 모델의 성실함에 기대지 않아도 됩니다. 말하자면 성실함을 성격이 아니라 설비로 만드는 일입니다.

여기서 재미있는 질문이 생깁니다. 모델이 점점 똑똑해지면 이런 빽빽한 관문은 필요 없어지지 않을까요? 저는 반대로 봅니다. 모델이 똑똑해질수록 그럴듯한 지름길도 더 정교해지기 때문에, 어디를 반드시 거쳐야 하는지를 코드로 적어두는 일은 오히려 무게가 커집니다. 공항 검색대를 생각하면 이해가 쉬운데, 베테랑 승무원이라고 검색대를 면제해주지는 않기 때문입니다. 그렇다면 이 관문들을 통과한 작업물은 실제로 얼마나 단단해질까요? 그 계산이 다음 대목에 나옵니다.

결함이 살아남으려면 두 번 운이 좋아야 한다

이 작업은 전체 과정을 저장소 상태 위의 마코프 체인(Markov chain)으로 그립니다. 여기서 코드가 고장 난 상태와 고쳐진 상태와 검토를 통과한 상태를 점으로 놓고, 라운드가 돌 때마다 점 사이를 옮겨 다니는 것으로 보는데, 저는 이 그림이 수학보다 직관에 가깝다고 봅니다. 그래서 말하고자 하는 바는 단순합니다. 그것은 결함 하나가 끝까지 살아남으려면 빌더와 리뷰어가 둘 다 놓쳐야 한다는 것입니다.

이를 확률로 풀어보면 감이 옵니다. 그 계산에서는 빌더가 실수할 확률과 리뷰어가 실수할 확률이 서로 기대어 있지 않다면, 둘 다 동시에 놓칠 확률은 각각의 확률을 곱한 만큼 작아집니다. 그래서 리뷰어를 다른 벤더로 두는 선택이 다시 살아납니다. 이때 같은 계통의 모델이면 놓치는 지점도 비슷해서 곱셈의 이득이 줄지만, 다른 계통이면 놓치는 모양이 달라 전체가 단단해지기 때문입니다. 그런데 현실에서는 두 실수가 완전히 독립이지는 않습니다. 그 이유는 어려운 문제는 누구에게나 어렵기 때문인데, 저는 그래서 이 모형을 약속이 아니라 방향으로 읽었습니다. 이 안내판이 말하는 것은 하나입니다. 그것은 독립에 가까워질수록 얻는 이득이 크다는 것입니다.

그렇다면 이 모형이 말하지 않는 것은 무엇일까요? 그것은 멈추는 법입니다. 이 간극은 결함을 잡는 구조와 일을 끝내는 구조가 같은 구조가 아니기 때문에 생기는데, 이 작업이 모은 기록을 보면 그 간극이 또렷하게 드러납니다. 그래서 수치 이야기로 넘어가기 전에 한 가지만 정리하면, Humanize는 잘 만드는 법보다 잘못 끝내지 않는 법에 가깝고, 저는 이 차이가 생각보다 크다고 봅니다. 그 차이를 가볍게 보면 완성을 오해합니다.

108일 동안 68번 고쳐 쌓은 1,468개의 별을 어떻게 읽을까

Humanize는 108일 동안 68개의 버전을 내고 1,468개의 GitHub 별을 모았습니다. 숫자를 나란히 놓으면 리듬이 보입니다. 이틀에 한 번꼴로 뭔가를 고쳤다는 뜻인데, 조용히 논문만 쓰고 앉아 있던 작업이 아니라는 인상이 듭니다. (참고로 버전 숫자를 세는 방식은 저장소마다 조금씩 달라서, 68이라는 수 자체를 다른 프로젝트와 직접 비교하기는 어렵습니다.)

여기서는 조금 조심해서 읽을 필요가 있습니다. 별의 수는 관심의 크기이지 품질의 증명은 아니기 때문입니다. 에이전트 코딩처럼 모두가 목말라 하는 주제에서는 별이 빨리 모이는 편인데, 그 별이 실제 채택으로 이어졌는지는 다른 문제입니다. 저는 이 숫자보다 그 뒤의 움직임이 먼저 눈에 들어옵니다. 짧은 간격으로 고쳤다는 것은 현장의 불평을 계속 받아먹었다는 뜻이고, 그런 작업은 대개 문서보다 설비가 먼저 늙습니다. 관문이 72개까지 불어난 것도 이런 손때의 결과로 읽히는데, 책상에서 한 번에 설계한 숫자라기보다 부딪히며 덧댄 흔적에 가깝기 때문입니다.

그렇다면 별과 버전 다음에는 무엇을 봐야 할까요? 데모가 아니라 상류로 간 기록입니다. 별은 마음을 얻었다는 뜻이고, 상류 리뷰는 남의 저장소에 흔적을 남겼다는 뜻인데, 둘의 무게는 다릅니다. 그래서 다음 두 장면이 이 글에서 차지하는 자리가 큽니다.

567개 파일을 옮기는 일은 왜 데모와 다를까

이 작업이 내세우는 적용 사례 가운데 하나는 567개 파일에 걸친 gem5 빌드 시스템 마이그레이션으로, 지금 상류 리뷰를 받고 있는 건입니다. 파일 수백 개를 옮기는 일은 작은 스크립트 몇 개를 고치는 일과 차원이 다른데, 왜냐하면 빌드 시스템은 건드리면 조용히 깨지고 깨지면 모두가 멈추기 때문입니다. 밤사이 공시가 늦게 도착하거나 아침에 특정 종목이 거래 정지에 걸리면 예측 라인이 멈추면 안 되는 것처럼, 빌드도 누군가의 아침을 지킵니다.

제가 이 사례를 길게 보는 이유는 검토의 밀도가 다르기 때문입니다. 상류 저장소는 남의 집 마당이라서 잔디 하나까지 트집을 잡히는데, 그 트집이 오히려 품질을 보증합니다. 내부 데모에서는 "돌아간다"면 박수를 받지만, 상류에서는 "왜 이렇게 고쳤는지"를 설명해야 하기 때문입니다. 567개라는 숫자는 그래서 양의 자랑이 아니라 설명의 부담으로 읽어야 합니다. 파일마다 이유를 대야 하는 작업에서 567은 567개의 질문과 같기 때문입니다.

물론 아직 리뷰가 끝나지 않았다는 점은 마음에 걸립니다. 받아들여지기 전까지는 진행 중인 일이지 끝난 일이 아닌데, 이 글에서는 그 상태를 있는 그대로 적어둡니다. 그럼에도 이 사례가 남기는 인상은 분명합니다. Humanize가 작은 예제에서만 도는 장난감이 아니라, 남의 눈치가 보이는 큰 작업장에도 들어갔다는 것입니다. 그렇다면 더 시끄러운 무대에서는 어땠을까요?

커널 경쟁 세 트랙 모두에서 상위권에 든다는 것은

또 다른 장면은 커널 설계 에이전트(Kernel Design Agents) 이야기로, MLSys 2026 FlashInfer 콘테스트의 Full-Agent 트랙 세 개 모두에서 상위 세 팀 안에 들었다는 결과입니다. 트랙 하나에서 잘하는 것과 세 트랙 모두에서 상위권에 드는 것은 다른데, 왜냐하면 한쪽에 맞춘 요령으로는 다른 쪽을 통과하기 어렵기 때문입니다.

커널 작업은 에이전트에게 가혹한 시험대입니다. 정확히 돌아가는 것만으로는 부족하고 빨리 돌아가야 하는데, 그 빠름은 추상적인 이야기가 아니라 메모리와 대역폭과 실행 순서가 얽힌 구체적인 숫자이기 때문입니다. 저는 그래서 이 결과를 점수보다 체질로 읽었습니다. 여러 트랙에서 고르게 상위권에 들었다는 것은 특정 문제에 맞춘 비법이 아니라, 계획하고 구현하고 검토하는 왕복 자체가 어느 정도 단단하다는 뜻이기 때문입니다. 다만 콘테스트와 현장은 다른 게임이라는 점도 함께 적어둡니다. 콘테스트에는 규칙과 심판과 마감일이 있지만, 현장에는 그 셋이 모두 흐릿하기 때문입니다.

그렇다면 가장 화려해 보이는 성적표는 어떻게 읽어야 할까요? 올림피아드 만점 이야기인데, 여기서야말로 브레이크를 밟고 읽어야 합니다.

멈추지 못하는 에이전트에 대한 118개의 기록

Humanize 올림피아드 에이전트(Olympiad Agents)가 거둔 성적표는 이렇게 적혀 있습니다. IOI 2026과 IMO 2026과 IPhO 2026과 IBO 2024에서 만점, PutnamBench에서 672점 만점에 672점, Lean-Eval에서 251점 대 303점으로 1위입니다. 숫자를 나란히 놓으면 숨이 멎는 수준인데, 그래서 오히려 한 걸음 물러서서 볼 일입니다.

제가 먼저 던지고 싶은 질문은 이것입니다. 이 성적표는 무엇을 증명할까요? 적어도 한 가지는 분명합니다. 판단 지점을 촘촘히 둔 워크플로우가 극한의 문제 풀이에서도 버틴다는 것입니다. 올림피아드 문제는 답만 맞히면 되는 시험이 아니라 풀이의 빈틈을 집요하게 파고드는 시험인데, 빌더와 리뷰어를 나눈 구조는 그런 빈틈 찾기와 잘 맞습니다. 한쪽이 답을 내면 다른 쪽이 트집을 잡는 왕복이 시험의 문법과 닮았기 때문입니다.

그런데 같은 작업이 모은 또 다른 숫자가 이 흥분을 식힙니다. 공개된 회고 118건을 뜯어보니 멈추는 일이 여전히 약한 고리로 남았는데, 단계를 나눠 적은 보고서에서는 구현이 받아들여진 뒤에 돌아간 라운드가 전체의 3분의 2를 차지했기 때문입니다. 이미 됐다는 판정이 나왔는데도 에이전트는 계속 손을 댄 셈인데, 생각해보면 사람도 비슷한 실수를 합니다. 보고서를 다 쓰고도 문장을 만지다가 마감 시간을 넘기는 것처럼요. 다만 에이전트의 경우는 그 만지작거림이 조용히 돈을 쓰고 기록을 어지럽힙니다.

여기서 이 작업이 스스로 덧붙인 단서가 마음에 남습니다. 이 관찰은 통제된 비교가 아니라 관찰 기록이라는 점입니다. 워크플로우끼리 조건을 맞춰 붙인 실험이 아니라, 공개된 회고를 모아 읽은 결과라는 뜻인데, 그래서 "어디가 약한가"는 말할 수 있어도 "누가 더 낫다"는 말할 수는 없습니다. 저는 이런 솔직함이 오히려 신뢰를 만든다고 봅니다. 성적이 좋을수록 약한 고리를 크게 말하기 어려운데, 그 어려운 말을 먼저 꺼냈기 때문입니다. 그렇다면 남은 질문은 하나입니다. 멈추는 법은 배울 수 있을까요?

그래서 다음에 제가 지켜보고 싶은 장면은

이 이야기를 한 줄로 모으면 이렇습니다. 여기서 Humanize는 쓰는 힘을 키우는 대신 끝났다는 말을 믿을 수 있게 만드는 데 재주를 걸었고, 그 방법으로 사람 승인 한 줄과 기계 관문 72개와 벤더를 가른 리뷰를 골랐습니다. 그 선택은 108일 동안 68번 고치며 1,468개의 별을 받았고, 567개 파일의 이사를 상류로 보내고, 커널 경쟁 세 트랙에서 모두 상위권에 들고, 올림피아드 성적표에 만점을 채우는 과정으로 이어졌습니다. 그리고 그 끝에서 멈추는 법이라는 숙제를 남겼습니다.

그렇다면 사람의 역할은 무엇일까요? 저는 이 질문이 이 글의 끝이 아니라 시작이라고 봅니다. 이 자리에서 계획 계약에 서명하는 일이야말로 사람이 가장 사람다워야 하는 자리인데, 무엇을 만들지 말지를 정하는 일은 모델이 대신해줄 수 없기 때문입니다. 그런데 기계 관문이 아무리 빽빽해도 계약서에 적힌 방향이 틀리면 전체가 틀린 곳으로 빨리 갈 뿐입니다. 그래서 앞으로 보고 싶은 것은 더 화려한 만점이 아니라 더 단단한 멈춤입니다. 그 멈춤이란 언제 손을 떼고 무엇을 미완으로 남기며 어떤 찜찜함은 다음 계약으로 넘기는지, 그 판단의 문법이 문서로 남는 장면을 말합니다.

이렇게 에이전트가 더 오래 일하고 더 많은 저장소를 넘나들수록, 개별 모델 하나가 똑똑한지만 보는 것을 넘어 무엇을 전파하고 어디서 멈추는지까지 함께 보게 될 것입니다. 저는 그래서 이 작업을 점수표가 아니라 질문으로 기억하려 합니다. 그 질문은 이것입니다. 그 끝났다는 말 앞에서 우리는 무엇을 믿어야 할까요? 그 물음에 대답하는 설비가 하나 늘었다는 것, 그것이 Humanize가 남긴 자리입니다.