매달 새 모델이 나온다. 어제도 하나 나왔다. 벤치마크가 오르고, 더 길고 복잡한 작업을 더 잘한다고 한다. 반가운 일이다. 그런데 그 모델로 며칠 일해보면, 머릿속에 남는 질문은 의외로 다른 것이다. "이 모델이 얼마나 똑똑한가"가 아니라, "이걸 어디까지 믿고 맡길 수 있는가."

두 질문은 전혀 다르다. 그리고 두 번째 답은 모델 안에 없다. 모델을 감싼 구조 — 흔히 하네스(harness) 라 부르는 오케스트레이션 골격 — 안에 있다. 같은 모델이라도 어떤 하네스로 감싸느냐에 따라, 혼자 폭주하는 장난감이 되기도 하고 믿고 맡길 일꾼이 되기도 한다. 데모에서 그럴듯해 보이는 것과, 실제 운영에서 사고 없이 굴러가는 것은 전혀 다른 일이다.

빅테크 경쟁이 모델 파라미터에서 하네스 설계로 옮겨간 이유가 여기 있다. 모델은 부품이고, 하네스는 골격이다. 부품은 매달 갈리지만 골격은 한 번 잘 지으면 오래 간다. 그래서 우리는 새 모델을 좇는 대신, 골격이 "어디까지" 가능한지를 직접 밀어붙여 봤다. 그 경계선들을 공유한다.

첫 경계 — 웹과 로컬은 비대칭이다

가장 먼저 부딪히는 건 공간이다. 최신 기능은 거의 항상 클라우드에 먼저 열린다. 새 워크플로우, 새 자동화, 새 연결은 전부 그쪽에서 시작된다. 그런데 정작 통제하고 싶은 것 — 내 파일, 내 서버, 내 환경 — 은 로컬에 있다.

여기서 중요한 사실 하나. 이 벽은 한 방향으로만 단단하다. 클라우드 에이전트는 내 로컬에 함부로 닿지 못한다(보안상 당연하다). 반대로 로컬 에이전트는 클라우드 API를 얼마든지 호출한다. 이 비대칭이 설계의 답을 준다. 중심축을 클라우드에 두려 하면 벽에 막히고, 중심축을 로컬에 두고 클라우드 신기술을 "불러 쓰는 부품"으로 격하시키면 벽이 사라진다. "클라우드가 내 작업을 지휘"하는 게 아니라 "클라우드가 신호를 보내고 로컬이 실행"하는 구조다. 화려한 실시간 협업 데모는 포기해야 할 수도 있다. 하지만 그 대가로 통제권을 얻는다. 대부분의 실무에서 이 교환은 남는 장사다.

둘째 경계 — 모든 것을 모델에 맡기지 마라

하네스를 처음 짜면 욕심이 난다. 똑똑한 모델이 있으니 모든 단계를 맡기고 싶어진다. 그런데 이건 비싸고, 느리고, 무엇보다 불안정하다.

원리는 단순하다. 패턴이 잡힌 일은 코드로 고정하고, 판단이 필요한 일만 모델에 맡긴다. 우리는 이걸 농담처럼 "자판기"라 부른다. 입력을 넣으면 정해진 출력이 나오는, 판단 없는 결정론적 배선이다. 포맷 변환, 스키마 검증, 채널 분기 같은 일은 매번 똑같다. 모델에 시키면 토큰을 태우고 가끔 엉뚱한 짓을 하지만, 코드로 박아두면 공짜로, 영원히, 똑같이 작동한다.

흥미로운 건 도구 호출조차 그렇다는 점이다. "이 단계엔 이 도구"가 정해져 있다면, 모델에게 고르게 하는 것보다 코드가 직접 호출하는 편이 훨씬 단단하다. 모델은 도구가 있는지조차 몰라도 된다. 그저 텍스트만 뱉으면, 코드가 그 출력을 받아 정해진 도구를 실행한다. 불확실성이 0이 된다.

판단을 없애라는 게 아니다. 판단을 위로 올리라는 것이다. 자판기는 신경이 아니라 척수 반사다. 무엇을 할지는 위에서 정하고, 자판기는 실행만 한다. 그리고 자판기는 작을수록 견고하다. 거대한 자판기 하나는 잘 깨지지만, 작은 자판기 여럿을 레고처럼 잇는 구조는 좀처럼 무너지지 않는다. 비싼 판단을 최소화하고 값싼 실행을 최대화할수록, 하네스는 더 빠르고 더 싸고 더 안정적이 된다.

셋째 경계 — 작은 로컬 모델의 진짜 자리

비용 이야기가 나왔으니, 작은 로컬 모델을 직접 돌려본 경험도 나눈다. 소비자용 GPU 한 대에 오픈소스 경량 모델 몇 개를 올리고, 똑같은 과제를 시켜봤다.

결론은 명확했다. 긴 창작은 아직 무리다. 글 한 편을 쓰라고 하면 언어가 섞이고, 주제를 벗어나고, 같은 문장을 무한히 반복하며 무너졌다. 작은 모델에게 "주인공"을 맡기면 실망한다.

그런데 같은 모델이 다른 일에선 쓸 만했다. 코드에서 결함을 찾아내는 검증 과제는 큰 모델에 근접한 점수를 냈고, 짧고 정형화된 문제는 1초대에 정답을 내놓았다. 즉 작은 모델의 자리는 생성이 아니라 검증과 분류, 짧은 정형 작업이다. 주연이 아니라 조연 — 검증자, 분류기, 자판기의 부품으로 배치할 때 빛난다. 무거운 하네스를 통째로 작은 로컬 환경에 옮기려는 시도는, 시스템 프롬프트와 도구 정의만으로 컨텍스트가 꽉 차 실패했다. 교훈은 분명하다. "통째 로컬화"가 아니라 "가벼운 자판기 + 로컬 모델 노드"가 정답이다. 무거운 건 클라우드에, 가벼운 건 로컬에. 다시 첫 경계로 돌아온다.

넷째 경계 — 가장 강한 모델도 검증받아야 한다

마지막 경계가 가장 중요하다. 우리는 가장 강력한 최신 모델로 큰 분석 과제를 돌렸다. 결과는 인상적이었다. 그런데 그 결과를 곧이곧대로 쓰지 않았다. 일부러 다른 환경의 다른 에이전트들이 교차검증하게 했다.

이유는 하나다. 단일 에이전트는 자기 환각을 자기가 걸러내지 못한다. 자기 눈으로 자기 맹점을 못 보는 것과 같다. 그리고 모델이 새롭고 강력할수록, 그럴듯하게 틀릴 위험은 오히려 커진다. 강함과 신뢰는 다른 축이다. 벤치마크가 높다고 믿을 수 있는 게 아니다.

실제로 1차 분석에는 오탐이 있었다. 한 환경에서 "없다"고 판정한 것이 다른 환경에는 멀쩡히 있었다. 일부만 보던 에이전트가 전체 맥락을 놓친 것이다. 교차검증이 이걸 즉시 걸러냈다. 만약 그 1차 보고를 그대로 신뢰했다면, 멀쩡한 것을 문제로 오해한 채 일을 키웠을 것이다.

그래서 좋은 하네스에는 반드시 검증 루프가 있다. 생성하는 에이전트와 검증하는 에이전트를 분리하고, 판단이 비가역적일수록 — 돈이 오가거나 되돌릴 수 없는 작업일수록 — 검증 층을 더 두껍게 쌓는다. 단서 하나. 비슷한 모델끼리는 같은 맹점을 공유하므로, 교차검증은 서로 다른 계열의 모델이 맡아야 효과가 난다. 똑같은 둘이 서로 확인하면, 둘 다 같은 곳에서 틀린다.

그래서, 어디까지인가

다시 처음 질문으로. 클로드 하네스는 어디까지 가능한가.

답은 역설적이다. 하네스의 "어디까지"는 모델 지능이 아니라 구조가 정한다. 더 똑똑한 모델을 기다릴 필요가 없다. 지금 모델로도 구조를 제대로 지으면 놀랄 만큼 멀리 간다. 반대로 구조가 없으면, 아무리 강한 모델을 넣어도 혼자 폭주하다 사고를 낸다.

그 구조의 핵심 원리를 한 문장으로 줄이면 이렇다.

에이전트로 탐색하고, 패턴이 잡히면 코드로 정착시킨다.

에이전트는 영원한 일꾼이 아니라 정찰병이다. 그 가치는 일을 끝없이 반복하는 데 있지 않고, 일의 패턴을 드러내는 데 있다. 패턴이 보이면 그 부분은 코드로 굳히고, 에이전트는 풀려나 다음 미지의 영역으로 간다. 이렇게 하면 비싼 지능은 늘 최전선에만 머물고, 뒤쪽은 값싸고 안정적인 코드가 받친다.

모델은 부품이고 하네스는 골격이다. 부품은 매달 갈린다. 어제도 새것이 나왔고, 다음 달에 또 나올 것이다. 그때마다 흔들리지 않으려면, 모델을 좇지 말고 골격을 지어야 한다. 골격이 단단하면, 새 부품이 올 때마다 그저 더 좋아질 뿐이다. 하네스는 모델이 똑똑한 만큼이 아니라, 구조를 지은 만큼 멀리 간다.