함께 일하는 35B, Occamy-1.0이 가리킨 비용의 무릎

Occamy-1.0: Open Pareto-frontier 35B Intelligence for Co-work는 arXiv 번호 2609.11977로 공개된 연구다. 원문 링크는 제목 아래에 걸어두었다.

이 연구가 내세우는 주장은 하나의 문장으로 정리된다. 함께 일하는 에이전트의 가치는 정점 성능만이 아니라 그 성능을 어떤 비용으로 내는지에 달려 있으며, 실행에 뿌리를 둔 데이터와 환경 위에서 단계별로 다듬은 35B 개방형 모델로 그 비용 대비 성능 곡선의 무릎에 앉을 수 있다는 것이다. 이 글에서는 그 진단에서 출발해 co-work의 정의와 35B라는 선택, 기존 체크포인트 위의 추가 학습, 긴 실행 궤적과 단계별 후학습, 체급별 성적과 비용 곡선, 그리고 개방의 의미를 차례로 따라간다.

왜 답을 잘하는 모델이 일을 끝내지 못할까

제가 이 논문에서 가장 흥미롭게 본 부분은 출발점의 정의였다. 연구진은 co-work 에이전트를 정보 모으기와 도구 사용, 코딩과 파일 다루기가 여러 번의 모델 호출에 걸쳐 이어지는 워크플로로 규정하는데, 한 번의 질문에 한 번의 답을 내는 일이 아니라 상태를 바꾸면서 여러 단계를 밟아가는 일이라는 뜻이죠. 그런데 오랫동안 우리는 이런 일을 답 잘하는 능력으로 재어 왔다. 시험 문제를 풀 듯이 말이다.

생각해보면 사람도 비슷하게 배운다. 매뉴얼을 달달 외운 신입이 현장에서 바로 일을 끝내지 못하는 이유는, 자료를 찾아 모으고 도구를 고르고 스크립트를 고치면서 중간에 생긴 오류를 되돌리는 과정이 따로 있기 때문이다. 파일 하나를 읽었는데 인코딩이 깨져 있거나, 도구를 불렀는데 권한이 없거나, 아침에 돌아가던 명령이 오후에는 버전이 바뀌어 멈추는 일이 생기니까요. 이런 장면에서 필요한 능력은 정답을 아는 것이 아니라 다음 행동을 고르는 것이며, 지금 상태를 읽고 무엇을 시도할지, 실패하면 어디로 돌아갈지를 정하는 일이죠.

여기서는 조금 조심해서 읽을 필요가 있다. 정답 능력이 쓸모없다는 이야기가 아니기 때문이다. 정답 능력은 여전히 바탕 체력이죠. 그런데 함께 일하는 자리에서는 질문 자체가 달라지는데, 무엇을 아느냐에서 어떤 조건에서 버티며 끝까지 가느냐로 바뀐다. 저는 이 전환이 논문의 진짜 출발점이라고 본다. 점수를 조금 더 올리는 방법이 아니라 무엇을 재야 하는지를 다시 정하는 일이라서, 이런 선언이 있어야 뒤에 나오는 실행 이야기가 힘을 얻는다. 그렇지 않을까요?

그렇다면 실행을 본다는 것은 구체적으로 무엇일까요? 이 질문이 다음 장면으로 이어진다.

작은 모델이 싼값에 앉는 자리가 있을까

이 논문을 읽다 보면 크기 이야기가 계속 따라온다. Occamy-1.0은 35B 모델인데, 연구진은 이 모델을 훨씬 큰 프런티어급 시스템과 나란히 놓고 이야기한다. 몇몇 co-work 과제에서는 큰 모델과 겨룰 수 있다는 보고라서, 언뜻 들으면 작은 모델이 큰 모델을 이겼다는 소리처럼 들리죠. 그런데 논문의 문장을 가만히 뜯어보면 승패 이야기가 아니다. 비용 대비 성능이라는 축 위에서 어디에 앉느냐는 이야기다.

같은 일을 시켜놓고 생각해보자. 큰 모델은 한 번에 시원하게 풀어낼 때가 많다. 반면 작은 모델은 여러 번 호출하면서 조금씩 나아가는데, 호출 횟수로 보면 작은 모델이 더 많이 움직이지만 한 번 부를 때마다 드는 돈이 적으니까 전체 청구서는 오히려 가벼워질 수 있다. 마치 무거운 트럭 한 대로 옮길 짐을 작은 밴 여러 대로 나누어 옮기는 것과 비슷하다. 트럭이 한 번에 옮기는 양은 많지만, 밴이 자주 오가며 처리하는 쪽이 전체 연료값은 적게 나올 때가 있기 때문이죠. 물론 매번 그런 것은 아니고, 짐의 모양과 길의 상태에 따라 달라지니까 비용 이야기는 조건을 빼고 말하기 어렵다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 본다. 논문이 말하는 저비용 무릎이라는 표현은 가장 싸다는 뜻도, 가장 강하다는 뜻도 아니기 때문이다. 성능을 조금 더 올리려면 비용을 훨씬 더 내야 하는 지점과, 반대로 비용을 조금 아끼려면 성능이 크게 꺾이는 지점 사이에 있는 굽은 자리죠. 그래서 그 자리에 앉겠다는 것은 정점을 노리겠다는 말이 아니라 실용의 자리를 노리겠다는 선언이다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않고, 실제로 무엇이 바뀌었고 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 본다. 그런 눈으로 보면 이 무릎 이야기는 점수 자랑이 아니라 운영 선언에 가깝다.

문제는 그다음입니다. 싼값에 앉겠다는 말이 실제로 통하려면 싼값의 근거가 실행에서 나와야 하는데, 그 근거는 어디에서 올까요?

있는 뼈대 위에 다시 올린다는 것은 무슨 뜻일까

Occamy-1.0은 밑바닥부터 새로 만든 모델이 아니다. 이미 후학습까지 마친 Qwen3.6-35B-A3B 체크포인트를 가져와 거기서 다시 학습을 이어간 모델이죠. 저는 여기서 멈칫했다. 새로 짓는 것이 아니라 고쳐 쓰는 선택이기 때문이다. 왜 처음부터 만들지 않았을까요?

이유는 생각보다 현실적이다. 이미 잘 배운 언어 능력과 instruction 따르기, 도구 호출의 기초를 처음부터 다시 가르치는 일은 돈이 많이 들고 시간도 오래 걸리기 때문이다. 그래서 뼈대가 이미 서 있는 집에 인테리어를 다시 하는 편이 빠르다. 벽을 허물고 새로 올리는 대신, 배선과 수납을 손보고 동선을 바꾸는 일이죠. 연구진이 택한 길도 그런 셈으로, 있는 35B 뼈대 위에 함께 일하는 능력을 덧입히는 것이다.

그런데 덧붙인다는 말이 쉽게 들리지만 실제로는 그렇지 않다. 이미 후학습된 모델에 손을 대면 전에 배운 것이 흔들릴 수 있기 때문이다. 그래서 잘하던 일반 대화를 유지하면서 실행 능력을 올리려면, 무엇을 더하고 무엇을 건드리지 않을지를 가려야 하죠. 옷에 단추를 하나 더 단다고 생각해보자. 단추 구멍을 새로 낼 때마다 원단이 조금씩 늘어나는데, 너무 많이 고치면 옷의 형태가 틀어진다. 이런 점에서 추가 학습은 양의 문제가 아니라 배치의 문제이며, 어디에 얼마나 어떤 순서로 얹을지가 결과를 가른다.

그렇다면 무엇을 얹었다는 것일까요? 논문이 말하는 답은 실행에 뿌리를 둔 데이터와 환경인데, 그 말이 뜻하는 바를 조금 더 풀어볼 필요가 있습니다.

실행에 뿌리를 둔다는 말이 뜻하는 것

논문에서 반복되는 표현이 execution-grounded이다. 실행에 뿌리를 둔다는 뜻인데, 처음 들으면 당연한 말처럼 들리죠. 에이전트 학습이니 실행 데이터를 쓴다는 것이 뭐가 특별할까 싶기 때문이다. 그런데 조금만 들여다보면 이 말은 데이터의 출처를 가리는 말이다.

일반적인 학습 데이터에는 정답이 적혀 있다. 질문과 모범 답안이 짝을 이루기 때문이죠. 반면 실행 데이터에는 과정이 적혀 있는데, 어떤 도구를 어떤 순서로 불렀고 그때 환경이 어떻게 답했고 어디에서 실패했고 어떻게 돌아왔는지가 남는다. 그래서 정답지만 보고 공부하는 것과 실제 현장의 작업 일지를 보고 공부하는 것 사이의 차이와 비슷하다. 작업 일지에는 성공만 있는 것이 아니라 막혔던 대목과 우회로가 함께 적혀 있으니까요. 이런 이유로 실행 데이터는 길고 지저분해서 한 번에 읽히지 않지만, 함께 일하는 능력을 가르치려면 그 지저분함이 필요하다.

여기서 재미있는 질문이 생깁니다. 실행 기록을 그냥 많이 모으면 되는 것일까요? 저는 그렇지 않다고 본다. 기록이 실제로 다시 돌릴 수 있는 형태로 남아야 하기 때문이다. 다시 말해 replayable해야 한다는 것인데, 같은 상황에서 같은 행동을 다시 밟아볼 수 있어야 학습 신호로 쓸 수 있죠. 현장에서 흔히 겪는 일을 떠올려보자. 월요일 아침에 실패한 스크립트가 화요일에는 환경이 바뀌어 재현조차 안 되는 경우가 있다. 그때의 로그는 이야기로는 좋아도 교재로는 쓰기 어렵다. 다시 돌릴 수 없는 기록은 구경거리에 가깝기 때문이다. 연구진이 환경과 함께 묶어 기록을 남기겠다는 것은, 바로 그 재현 가능성을 확보하겠다는 뜻으로 읽힌다.

참고로 여기서 말하는 환경은 거창한 시뮬레이터만을 뜻하지 않는다. 파일과 도구가 실제로 반응하는 작업 공간, 명령이 진짜로 실행되고 결과가 돌아오는 자리라고 이해하면 가깝다. 이런 정의를 깔고 보면 다음 질문이 자연스럽다.

그렇다면 그 기록은 얼마나 길어야 할까요? 이 질문이 다음 이야기로 이어진다.

여러 하네스에서 긴 길을 모아오면 무엇이 달라질까

논문이 쓰는 또 하나의 표현은 long-horizon trajectories across multiple harnesses이다. 여러 하네스에 걸쳐 포착한 긴 실행 궤적이라는 뜻인데, 말이 길수록 헷갈리죠. 그래서 하나씩 풀어보자. 궤적이라는 것은 한 번의 호출이 아니라 여러 호출이 이어진 발자취이며, 정보를 찾고 파일을 열고 코드를 고치고 다시 실행하고 틀리면 고치는 흐름 전체죠. 그리고 long-horizon이라는 것은 그 흐름이 짧게 끝나지 않는다는 뜻으로, 열 번 수십 번의 손놀림이 이어진다는 의미다.

제가 이 대목에서 눈이 갔던 것은 multiple harnesses라는 부분이다. 하네스는 에이전트가 일하는 틀인데, 도구의 모양과 허용된 행동, 관찰 방식이 조금씩 다르기 때문이다. 그래서 한 하네스에서만 배우면 그 틀에 익숙해진다. 마치 한 회사의 결재 시스템에만 익숙한 직원이 다른 회사에 가면 헤매는 것과 비슷하다. 버튼 위치가 다르고 승인 순서가 다르고 파일이 잠기는 방식이 다르니까요. 이런 점에서 여러 하네스에서 기록을 모은다는 것은 여러 회사의 일하는 방식을 두루 겪게 한다는 뜻이며, 특정 버튼 위치를 외우게 하는 것이 아니라 낯선 사무실에서도 통하는 일하는 습관을 가르치려는 시도다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 여러 틀에서 모은 기록이 서로 충돌하면 어떻게 할까요? 한곳에서는 허용되는 행동이 다른 곳에서는 금지될 수 있기 때문이죠. 파일을 직접 고쳐도 되는 곳이 있는가 하면, 반드시 정해진 도구를 거쳐야 하는 곳도 있다. 이런 차이를 무시하고 한데 섞으면 에이전트는 눈치 없는 행동을 배우고, 어디서든 통하는 척하면서 어디서도 어긋나는 행동을 하게 된다. 그래서 여러 하네스라는 말은 양의 자랑이 아니라 설계의 약속이어야 하며, 서로 다른 틀의 기록을 어떻게 맞추고 무엇을 공통으로 가르칠지를 정했다는 약속이어야 한다. 논문은 그 약속을 지켰다고 말하는데, 저는 이 대목을 볼 때 근거의 모양을 함께 보고 싶었다. 어떤 틀에서 얼마나 모았고 겹치는 부분과 갈라지는 부분을 어떻게 다루었는지가 궁금했기 때문이다.

그렇다면 모은 기록을 어떤 순서로 먹여야 할까요? 재료가 좋아도 조리 순서가 틀리면 맛이 어긋나니까요.

단계를 나누어 가르친다는 것은 무슨 일일까

연구진은 staged post-training이라는 말을 쓴다. 단계별 후학습이라는 뜻인데, 서로 보완적인 실행 능력을 키우고 굳힌다는 설명이 붙죠. 처음 들으면 교육 과정표처럼 들린다. 기초반을 마치고 심화반으로 간다는 이야기처럼 말이다.

그런데 단계를 나눈다는 것은 생각보다 기술적인 결정이다. 한 번에 모든 것을 가르치면 모델이 이도 저도 아닌 상태에 머물 때가 있기 때문이다. 정보를 모으는 능력과 도구를 다루는 능력, 코드를 고치는 능력과 파일을 정리하는 능력은 서로 돕기도 하지만 서로 당기기도 한다. 그래서 한꺼번에 밀어 넣으면 강한 신호가 약한 신호를 삼킨다. 이런 이유로 먼저 넓게 발달시키고 그다음에 서로 어긋나지 않게 다듬는 순서가 필요한데, 악기를 배울 때와 비슷하다. 처음에는 각 악기가 따로 연습하다가 나중에는 합주를 맞추며, 따로 놀 때의 소리와 함께 낼 때의 소리는 다르기 때문이다.

여기서는 조금 조심해서 읽을 필요가 있다. 단계가 많다고 좋은 것이 아니기 때문이다. 단계가 늘어날 때마다 앞에서 배운 것을 잊는 문제가 생긴다. 이를테면 파일 다루기를 가르치느라 정보 모으기를 잊어버리는 식이다. 그래서 단계별 학습의 관건은 무엇을 먼저 가르치느냐가 아니라 무엇을 잊지 않게 하느냐에 있다. 뒤 단계로 갈수록 앞 단계의 실력이 조용히 새어 나가는데, 그 구멍을 어떻게 막았는지가 진짜 실력이죠. 논문은 보완적인 능력을 굳혔다고 말하는데, 저는 그 굳힌다는 말이 무엇을 뜻하는지 오래 생각했다. 아마도 한 능력이 올라갈 때 다른 능력이 꺾이지 않게 묶어두는 일일 텐데, 그 묶음의 방식이 다음 연구에서 더 풀리면 좋겠다.

저희가 새로운 AI 아키텍처를 볼 때도 이런 순서 감각을 먼저 본다. 재료를 무엇을 썼는지보다 어떤 순서로 먹였는지가 시스템의 성격을 더 잘 드러내기 때문이다. 같은 재료라도 순서를 바꾸면 전혀 다른 모델이 나오죠. 그런 눈으로 보면 staged라는 한 단어는 짧지만, 그 안에는 꽤 많은 시행착오가 들어 있을 가능성이 크다.

문제는 이렇게 가르친 결과가 실제로 통했느냐는 것인데, 그 이야기는 점수 이야기로 이어진다.

비슷한 체급에서는 어디에 서 있을까

논문의 보고를 있는 그대로 옮기면 이렇습니다. 넓은 co-work 벤치마크 묶음에서 Occamy-1.0은 비슷한 크기의 모델 가운데 꾸준히 상위권에 든다고 한다. 저는 이 문장을 읽을 때 두 가지를 함께 본다. 하나는 넓은 묶음이라는 말이고, 다른 하나는 꾸준히라는 말이다.

넓은 묶음이라는 것은 한두 시험에서 반짝했다는 뜻이 아니죠. 정보 모으기만 잘하거나 코딩만 잘하는 것이 아니라, 여러 일을 두루 처리했다는 뜻으로 읽힌다. 함께 일하는 자리는 원래 편식이 통하지 않는 자리라서, 파일은 잘 다루는데 도구를 못 부르면 일이 멈추고 코드는 잘 짜는데 정보를 못 모으면 엉뚱한 것을 만든다. 그래서 두루 잘한다는 말은 함께 일하는 모델에게는 꽤 큰 칭찬이며, 여러 종목을 돌아가며 뛰는 철인 경기와 비슷하다. 한 종목만 잘해서는 순위가 나오지 않기 때문이다.

꾸준히라는 말도 눈여겨볼 만하다. 특정 하네스나 특정 과제에서만 튀는 것이 아니라 여러 조건에서 위쪽에 머물렀다는 뜻이기 때문이다. 저는 이 대목에서 앞서 나온 여러 하네스 이야기가 겹쳐 보였다. 여러 틀에서 배운 모델이 여러 시험에서 덜 흔들린다면, 그 일관성 자체가 학습 방식의 증거가 되기 때문이다. 물론 여기서 한 걸음 더 들어가면 묻고 싶은 것이 생긴다. 상위권이라는 것은 누구와 겨뤄서 어디에 섰다는 것일까. 같은 30B대 개방형 모델들과의 비교인지, 상용의 작은 모델까지 포함한 비교인지에 따라 문장의 무게가 달라지기 때문이다. 논문이 말하는 비교 대상의 윤곽을 앞으로 더 뜯어보고 싶다.

그렇다면 체급을 넘어서는 비교에서는 어떨까요? 이 질문이 바로 논문이 가장 세게 던지는 대목으로 이어진다.

더 큰 모델과 나란히 놓으면 어디까지 갈까

논문은 몇몇 co-work 과제에서 훨씬 큰 프런티어급 시스템과 겨룰 만하다고 보고한다. 이 문장은 조심해서 다뤄야 한다. 모든 일에서 큰 모델을 대신할 수 있다는 뜻이 아니기 때문이다. 몇몇 과제에서 주어진 조건 아래에서 어깨를 나란히 했다는 뜻이며, 조건을 빼고 읽으면 오해가 생기죠.

여기서 논문이 꺼내는 장치가 네 개의 대표 벤치마크를 묶은 집계와 비용 대비 성능 곡선이다. 네 개를 묶어 본 aggregate 성능이 관찰된 곡선의 저비용 무릎에 앉는다는 것인데, 저는 이 설계가 솔직하다고 본다. 하나만 골라 자랑하지 않고 묶어서 봤기 때문이다. 하나의 시험은 우연히 잘 맞을 수 있지만, 네 개를 묶으면 우연의 자리가 줄어든다. 게다가 성능만 보지 않고 비용과 함께 보는데, 정답률만 놓고 줄을 세우면 큰 모델이 유리할 수밖에 없지만 한 번 부를 때 드는 값을 함께 놓으면 작은 모델의 자리가 보인다. 그래서 이 묶음과 곡선의 조합이 설득력을 만든다.

하지만 여기서 바로 다음 질문이 생깁니다. 비용은 어떻게 쟀을까요? 논문은 저자들의 평가와 가격 책정 방식 아래에서라는 단서를 붙이는데, 이 단서는 생각보다 중요하다. 가격은 고정된 물리량이 아니기 때문이다. 어떤 요금표를 쓰고 입력과 출력 토큰을 어떻게 치고 여러 번 호출한 궤적 전체를 어떻게 합산했는지에 따라 순위가 바뀐다. 아침에 재면 싸던 것이 저녁 요금표를 쓰면 비싸지는 것과 비슷하다. 그래서 무릎이라는 자리는 절대 좌표가 아니라 측량 방식 위의 자리다. 저는 그래서 이 결과를 이렇게 읽는다. 주어진 측량 방식 아래에서는 작은 개방형 모델이 실용의 자리에 앉을 수 있다는 가능성의 증거로 말이다. 다른 요금표, 다른 호출 예산, 다른 과제 묶음에서도 같은 자리에 앉을지는 아직 열린 질문으로 남는다.

이런 조심스러움에도 불구하고, 이 대목이 주는 감각은 분명하다. 함께 일하는 능력은 크기만으로 줄 세우기 어렵고, 어떻게 가르쳤느냐가 크기의 격차를 좁힐 수 있기 때문이다. 이 가능성은 다음 개방 이야기와 맞닿아 있다.

가중치와 데이터를 연다는 선택이 남기는 것

연구진은 모델 가중치와 학습 데이터의 일부를 공개하겠다고 밝힌다. 실용적인 co-work 에이전트와 에이전트형 후학습 연구를 돕겠다는 취지죠. 저는 이 결정을 점수보다 오래 본다. 점수는 다음 모델이 나오면 바뀌지만, 열린 자산은 남아서 쓰이기 때문이다.

왜 일부 데이터까지 여는지 생각해보자. 가중치만 열리면 결과는 쓸 수 있지만 과정은 배우기 어렵다. 어떻게 가르쳤는지를 알려면 재료의 모양을 봐야 하기 때문이다. 실행 기록이 어떤 틀에서 왔고 얼마나 길었고 어떤 실패와 복구가 들어 있는지를 알아야 다음 연구가 그 위에서 실험할 수 있다. 요리의 완성품만 받고 레시피 일부를 함께 받는 것과 비슷하다. 완성품으로는 배를 채울 수 있지만, 레시피가 있어야 다음 요리를 만들기 때문이다. 일부라는 단서가 붙은 것은 아쉬우면서도 현실적이다. 전부 열기 어려운 사정이 있을 수 있는데, 일부라도 모양을 알 수 있으면 재현과 변형의 출발점이 되기 때문이다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 열린 35B는 어디에 올릴 수 있을까요? 논문이 직접 서빙 가이드를 주지는 않지만, 35B라는 크기는 그 자체로 메시지를 준다. 가장 큰 모델보다는 손에 잡히는 크기라는 뜻이다. 그래서 큰 모델을 매번 부르는 대신, 자주 부르는 실행 일은 이 모델에 맡기고 어려운 판단만 큰 모델에 묻는 식의 나눔이 떠오른다. 밤사이 돌아가는 정리 작업이나 아침마다 반복되는 수집과 코딩 같은 일에서는 호출값이 쌓이기 때문에, 싼값에 자주 부를 수 있는 일꾼이 있으면 운영의 셈이 달라진다. 물론 메모리와 대역폭, 동시 호출 같은 조건을 따져봐야 하지만, 방향 자체는 분명하다. 자주 일하는 모델은 잘하는 것을 넘어 자주 부를 수 있어야 하기 때문이다.

그렇다면 이 모든 이야기를 한 줄로 모으면 무엇이 남을까요? 마지막으로 그 질문을 정리해보겠습니다.

그래서 함께 일하는 모델을 볼 때 무엇을 물어야 할까

돌아보면 이 논문이 던진 질문은 단순했다. 함께 일하는 능력은 정점의 똑똑함으로만 재야 할까요, 아니면 그 똑똑함을 어떤 값에 내주는지로도 재야 할까요? 연구진의 답은 후자 쪽에 가까운데, 실행에 뿌리를 둔 기록을 여러 틀에서 길게 모으고 단계별로 가르쳐 굳힌 35B 모델로 비용 곡선의 무릎에 앉아 보였기 때문이다. 비슷한 체급에서는 두루 위쪽에 서고, 몇몇 과제에서는 훨씬 큰 시스템과도 견주었다는 보고와 함께 말이다.

제가 앞으로 보고 싶은 것은 세 가지다. 먼저 측량의 조건이다. 네 개의 대표 묶음과 가격 책정 방식을 달리해도 무릎의 자리가 유지되는지 보고 싶다. 호출 예산을 빡빡하게 죄거나 넉넉하게 풀 때 순위가 어떻게 흔들리는지가 궁금하기 때문이다. 다음은 잊은 것이 없는지에 대한 확인이다. 실행 능력을 올리면서 일반 대화와 지시 따르기, 안전 측면의 행동이 어떻게 함께 움직였는지를 보고 싶다. 함께 일하는 모델일수록 권한 있는 도구를 만지기 때문에, 이 확인은 점수 바깥의 일이 아니라 점수 안의 일이다. 마지막은 열린 자산의 쓰임이다. 공개된 가중치와 일부 데이터 위에서 다른 팀이 어떤 변형을 만들어내는지가 이 연구의 진짜 수명이 될 텐데, 그 기록이 쌓이면 다음 단계의 질문도 달라질 것이다.

다 쓴 뒤에 남는 감각은 의외로 차분하다. 큰 모델이 만능이라는 생각, 작은 모델은 보조라는 생각이 조금씩 흔들리기 때문이다. 자주 부르고 오래 돌려야 하는 일에서는 싼값에 꾸준히 끝내는 능력이 따로 있기 때문이죠. 저는 그래서 이 논문을 점수표가 아니라 운영의 제안으로 읽었다. 무엇을 살 것인가가 아니라 어떻게 일시킬 것인가를 묻는 제안이다. 그렇다면 사람의 역할은 무엇일까요. 아마도 어떤 일을 어떤 모델에 어떤 예산으로 맡길지를 정하는 일이 아닐까 싶은데요. 그 나눔을 잘하는 팀이 다음 현장에서는 더 멀리 가지 않을까요?