모델이 강해질수록 하네스는 단순해진다

Anthropic 엔지니어링 블로그에 올라온 Managed Agents 설계 회고를 읽다가 한 문장 앞에서 멈췄다. "모델이 강해질수록 하네스는 단순해진다." 여기서 하네스란 모델 위에 얹는 외부 제어 구조를 말한다. 스케줄링 루프, 컨텍스트 조립, 도구 라우팅 같은 것들이다. 글을 끝까지 읽고 나서도 이 한 문장이 머릿속에서 떠나지 않았다.

이 문장이 AI 인프라 이야기로 읽히지 않았기 때문이다. 내가 지난 몇 년간 기획해온 제품들의 구조가 먼저 떠올랐다. 지금 유저가 못 하는 걸 전제로 박아둔 플로우, 지금 조직이 못 하는 걸 메우려 덧씌운 프로세스, 지금 기술이 부족해서 임시로 만든 래퍼. 이 땜질들은 전부 그 순간에는 합리적이었는데, 시간이 지나면서 하나씩 족쇄가 되어 돌아왔다.

Anthropic이 짚은 하네스의 딜레마는 본질적으로 이런 구조다. 모델이 못 하는 걸 외부 코드로 땜질하면 당장의 안정성은 확보되지만, 그 땜질은 모델의 미래 능력치를 예측해서 박은 것이라서 모델이 강해지는 순간 족쇄가 된다. 이 딜레마를 푸는 Anthropic의 방식이 인상적이었다. 구체적인 하네스 모양에 베팅하지 않고, 오래 살아남을 인터페이스 몇 개에만 베팅하는 것. 이것이 그들이 말하는 메타 하네스의 핵심이다. 내가 자꾸 돌아보게 되는 지점은, 제품 설계에서 나는 얼마나 많은 임시방편을 영구 구조로 굳혀왔는가, 그리고 그걸 스스로 알아차릴 수 있었는가 하는 것이다.

Anthropic의 담담한 고백

블로그에서 특히 인상 깊었던 대목이 있다. 초기 에이전트 아키텍처에서는 하네스와 세션과 샌드박스를 하나의 컨테이너에 묶어뒀다고 한다. 이유는 단순했다. 모델이 긴 작업을 안정적으로 복구할 수 없었고, 상태를 분리해서 관리할 만큼 정교하지 않았다. 그래서 전부 한 곳에 묶어두고, 컨테이너가 죽으면 처음부터 다시 시작하는 구조로 갔다.

이 결정은 그 시점에는 합리적이었을 것이다. 그런데 모델의 작업 시간이 METR 벤치 기준으로 매 7개월마다 두 배씩 늘어나면서 이 구조가 병목이 되었다. 컨테이너 하나 죽으면 며칠 작업이 날아가고, 디버깅을 위해 컨테이너에 들어가면 사용자 데이터가 노출되고, 세션 로그를 재사용하려 해도 컨테이너 라이프사이클에 묶여 있어서 꺼낼 수 없었다. 지금 못 한다를 전제로 박은 설계가, 이제는 할 수 있다의 발목을 잡는 순간이 온 것이다.

글을 읽으면서 가장 인상 깊었던 건 Anthropic이 이걸 숨기지 않고 썼다는 점이었다. 흔히 회사가 기술 블로그를 쓸 때는 "처음부터 잘했다"는 식으로 포장하기 마련이다. 그런데 이 글은 "우리도 임시방편을 영구 구조로 박았다가 다시 뜯어냈다"고 담담하게 인정한다. 그리고 그 재작업의 진짜 비용은 코드가 아니라 우리가 2년 전에 박은 가정이 이제 틀렸다는 걸 인정하는 것이었다고 덧붙인다. 이 고백이 나한테 가장 크게 들어왔다.

내가 과거에 박아둔 것들

이 고백을 읽으니 내 쪽에서도 떠오르는 장면들이 있다. 특정 제품 사례로 쓰지는 않겠다. 그 사례 하나하나가 결국 그때의 나와 팀이 가진 정보 안에서 내린 판단이었고, 지금 와서 돌이켜 욕하기 위한 재료가 아니기 때문이다. 다만 패턴은 선명하다.

초기 유저가 금융 용어를 어려워한다는 전제로 설계된 온보딩 플로우가 있었다. 팝업, 단계별 가이드, "이게 무슨 뜻인가요?" 링크가 곳곳에 박혔다. 이 선택은 당시의 데이터로는 옳았다. 그런데 시간이 지나면서 유저의 상당수가 이미 서비스를 능숙하게 쓰고 있고, 새로 들어오는 유저조차 3년 전과는 리터러시가 달랐다. 그런데 플로우는 여전히 유저는 아무것도 모른다를 전제로 작동하고 있었다. 이걸 바꾸자고 제안하면 꼭 이런 반론이 돌아왔다. "그래도 모르는 유저가 있잖아요."

운영 쪽에서도 비슷한 장면이 반복됐다. "이건 일단 수기로 처리하고, 나중에 자동화하자"는 판단이 수없이 쌓였다. 고객 환불, 어뷰징 탐지, 콘텐츠 심사 같은 것들이었다. 그 시점에는 합리적이었다. 케이스 수가 적고, 패턴이 덜 쌓였기 때문이다. 그런데 시간이 지나면서 이 수기 처리가 조직 안에서 이 일은 원래 사람이 하는 일이라는 합의로 굳는 걸 본다. 담당자가 지정되고, 담당자의 리듬이 생기고, 담당자의 암묵지가 조직의 판단 기준이 된다. 이 상태에서 자동화를 꺼내면 반발이 나온다. "지금 우리가 잘하고 있는데 왜 굳이."

이 두 장면은 표면적으로 다르지만 구조가 같다고 느꼈다. 지금 못 한다를 전제로 박은 구조가, 시간이 지나면서 영구 구조로 굳는 것이다. 그리고 굳은 뒤에는 그 구조 자체를 유지하려는 관성이 조직 안에 자리잡는다. Anthropic의 초기 컨테이너와 다를 게 없다는 생각이 들었다.

아직 내가 답을 못 찾은 질문

글을 읽고 나서 가장 오래 붙잡고 있었던 질문은 이거였다. 그럼 나는 지금 무엇을 임시방편으로 박고 있고, 무엇은 본질이라서 박아도 되는가. 이걸 설계 시점에 구별할 방법이 있을까.

Anthropic의 답은 메타 하네스의 세 층 분리에 담겨 있는 것 같다. 세션은 복구 가능한 이벤트 로그, 하네스는 스케줄링 뇌간, 샌드박스는 실행 환경. 이 세 층은 각각이 독립적으로 진화할 수 있게 인터페이스로 못 박혀 있다. 그 안의 구현체는 언제든지 교체할 수 있지만, 세 층의 경계 자체는 안정적이다. 이 구조가 나한테 주는 메시지는, 무엇이 변할지 모를 때는 변할 것과 변하지 않을 것을 먼저 분리하고 그 경계에만 투자하라는 것에 가까웠다.

제품 설계에 이걸 번역하면 어떻게 될지 한참 고민했는데 아직 깔끔한 답은 없다. 다만 한 가지 질문은 유용하게 쓰고 있다. 유저나 조직이나 기술이 지금보다 두 배 더 똑똑해지면, 이 설계의 어느 부분이 거치적거릴까. 이 질문에 답이 떠오르는 부분이 내가 지금 땜질 중인 부분이라는 건 확실하다. 그 부분만큼은 영구 구조에 섞지 않고 분리해두려고 노력하는 중이다. 다만 이게 얼마나 잘되고 있는지는 3년 뒤에나 알 수 있을 것 같다.

메모로 남기는 이유

Anthropic이 쓴 한 문장은 사실 새로운 통찰은 아니다. 소프트웨어 엔지니어링 쪽에서는 오래 쌓인 원칙이다. 그런데 그 원칙이 AI 에이전트 인프라라는 맥락에서 다시 쓰였을 때, 내 기획 습관까지 되돌아보게 만드는 힘이 있었다. 아마 내가 요즘 만드는 것들이 결국 지금의 한계를 전제로 박은 구조인 경우가 많아서 그랬을 것이다.

임시방편 자체가 나쁜 건 아니라고 생각한다. 제품을 출시하려면 땜질은 반드시 필요하다. 다만 그 땜질이 영구 구조로 굳지 않도록, 경계를 긋는 감각을 잃지 않으려고 노력하는 중이다. 이게 Anthropic의 글을 읽고 내가 남긴 가장 솔직한 메모다.