지난주 수요일, 메타가 코딩 도구를 하나 조용히 내놨다. 이름은 Muse Code. 터미널에서 돌아가는 코딩 에이전트로, 맥과 리눅스에서 명령어 한 줄로 설치할 수 있다.
발표 자체는 요란하지 않았다. 그럴 만도 한 게, 메타가 뛰어든 방은 이미 사람으로 붐빈다. 앤트로픽의 클로드 코드, 오픈AI의 코덱스, 구글의 제미나이 CLI가 각자 자리를 잡고 앉아 있는 터미널 코딩 에이전트 시장에 메타는 한참 늦게 도착했다. 늦게 온 손님이 할 수 있는 선택은 둘 중 하나다. 남들보다 훨씬 잘하거나, 남들과 다른 규칙을 들고 오거나. 벤치마크 숫자만 보면 메타는 전자를 하지 못했다. 그런데 이 발표에서 진짜로 봐야 할 것은 성능표가 아니라 가격표다. 메타는 "코드를 우리한테 넘기면 값을 스무 배쯤 깎아주겠다"는, 이 바닥에서 아무도 대놓고 꺼내지 않던 제안을 들고 왔다.
터미널에서 사는 코딩 에이전트란
먼저 Muse Code가 어떤 종류의 물건인지부터 짚고 가자. "터미널 코딩 에이전트"라는 말이 낯설 수 있다.
챗봇에 코드를 물어보는 방식은 다들 익숙하다. 질문을 던지면 코드 조각을 뱉어주고, 그걸 복사해서 내 편집기에 붙여넣는다. 편집기 안에서 다음 줄을 자동으로 채워주는 자동완성도 이제 흔하다. 터미널 코딩 에이전트는 여기서 한 발 더 나간다. 이 도구는 내 컴퓨터의 명령창(터미널) 안에 들어앉아, 프로젝트 폴더 전체를 직접 읽는다. 파일 수십 개에 흩어진 코드를 스스로 훑어보고, 어디를 고쳐야 할지 판단하고, 실제로 파일을 수정하고, 테스트 명령을 돌려서 제대로 됐는지 확인까지 한다. 사람이 "이 기능에 버그가 있으니 고쳐줘"라고 말하면, 코드 조각을 건네주는 게 아니라 일을 끝내놓는다.
조수와 대리인의 차이라고 보면 된다. 챗봇이 물어보면 답을 알려주는 조수라면, 터미널 에이전트는 열쇠를 받아 들고 방에 들어가 일을 처리하고 나오는 대리인이다. 클로드 코드가 이 방식으로 개발자들 사이에 빠르게 자리를 잡았고, 코덱스와 제미나이 CLI가 뒤를 이었다. Muse Code는 그 대열의 가장 끝에 붙은 신참이다.
늦게 온 만큼 구조는 손봤다
메타가 성능으로 앞서지 못했다고 해서 아무것도 안 한 건 아니다. 오히려 에이전트가 일하는 방식, 그러니까 구조 쪽은 꽤 공들여 다듬었다. 세 가지가 눈에 띈다.
첫째는 오래 사는 서브에이전트다. 서브에이전트는 큰일을 잘게 쪼갠 뒤 각 조각을 맡기는 보조 일꾼을 말한다. 예를 들어 "로그인 기능을 통째로 바꿔줘"라는 지시가 들어오면, 화면을 고치는 일꾼, 서버 쪽을 손보는 일꾼, 테스트를 짜는 일꾼으로 나눠 붙이는 식이다. 기존 도구들은 이 일꾼을 그때그때 만들었다 버린다. 한 번 시킬 때마다 새로 뽑아 쓰고, 일이 끝나면 해산시킨다. 문제는 새로 뽑힌 일꾼이 프로젝트 사정을 하나도 모른 채 시작한다는 데 있다. 매번 코드를 처음부터 다시 파악하느라 시간과 비용이 샌다. 코덱스 같은 도구가 매 턴 이런 콜드 스타트를 겪는다. Muse Code는 이 일꾼들을 작업이 끝날 때까지 살려둔다. 한 번 프로젝트를 파악한 일꾼이 계속 그 기억을 안고 다음 일을 하니, 매번 새로 눈치를 보는 낭비가 줄어든다.
둘째는 격리된 작업 공간에서의 병렬 처리다. 여기서 메타는 git worktree라는 기능을 끌어다 썼다. 이름은 어렵지만 발상은 단순하다. 여러 일꾼이 같은 코드를 동시에 건드리면 서로의 수정이 뒤엉켜 사고가 난다. 한 명이 고친 줄을 다른 명이 다시 덮어쓰는 식이다. 그래서 Muse Code는 일꾼마다 프로젝트 사본을 따로 하나씩 떼어준다. 각자 자기 사본 안에서 마음껏 작업하고, 결과만 나중에 합친다. 여러 요리사가 같은 도마 하나를 두고 부딪히는 대신, 각자 도마를 하나씩 받아 들고 일한 뒤 접시에 모으는 그림이다. 큰 프로젝트에서 여러 작업을 동시에 굴릴 때 유리하다.
셋째가 가장 실무적이다. 모든 행동을 순서대로 적어두는 기록장이다. 정식 용어로는 append-only event log, 즉 새 줄을 뒤에 계속 덧붙이기만 하고 앞의 기록은 고치지 않는 로그다. Muse Code는 모델을 부른 순간, 도구를 실행한 순간, 사람이 승인한 순간, 파일을 고친 순간을 하나도 빠짐없이 시간 순서대로 적는다. 이게 왜 중요하냐면, 에이전트가 작업 도중 멈추거나 컴퓨터가 꺼져도 이 기록장을 되짚어 정확히 끊긴 지점부터 다시 이어갈 수 있기 때문이다. 메타는 이걸 "재생하면 똑같이 재현되고, 다시 시작해도 안전하다"고 설명한다. 에이전트에게 긴 작업을 맡겨본 사람은 안다. 30분짜리 작업이 25분째에 엉뚱하게 멈췄을 때, 처음부터 다시 하느냐 끊긴 데서 잇느냐는 하늘과 땅 차이다.
벤치마크 숫자를 곧이곧대로 읽으면
구조는 그렇다 치고, 그래서 얼마나 잘하느냐가 남는다. 여기서 이야기가 묘해진다.
Muse Code를 굴리는 두뇌는 Muse Spark 1.2라는 모델이다. 7월에 나온 1.1을 손본 버전이다. 그런데 이 모델의 실력을 가늠하려면 앞선 버전인 오리지널 Muse Spark의 성적을 봐야 한다. 소프트웨어 수정 능력을 재는 대표 시험인 SWE-bench Verified에서 오리지널 Muse Spark는 77.4점을 받았다. 같은 시험에서 클로드 오퍼스 4.6은 80.8점, 제미나이 3.1 프로는 80.6점이었다. 3점 안팎이지만 방향은 분명하다. 메타의 모델은 선두를 살짝 못 따라간다.
흥미로운 건 메타가 1.2를 발표하면서 이 표준 시험 점수를 앞세우지 않았다는 점이다. 대신 "자체 하네스로 82.9%를 기록했다"는 식의 숫자를 흘렸다. 여기서 하네스(harness)라는 말이 핵심이다. 하네스는 모델을 감싸서 실제로 일하게 만드는 뼈대를 말한다. 같은 모델이라도 어떤 뼈대에 얹느냐에 따라 성적이 크게 달라진다. 문제를 잘게 쪼개주고, 중간 결과를 검토하게 하고, 실패하면 다시 시도하게 만드는 장치가 잘 갖춰지면 같은 두뇌로도 훨씬 나은 결과가 나온다. 그러니 "표준 시험 77점"과 "우리 하네스로 82.9%"는 사과와 오렌지다. 앞 숫자는 남들과 같은 조건에서 잰 것이고, 뒤 숫자는 메타가 자기 유리한 방식으로 잰 것이다.
이 대목을 냉정하게 읽으면 메타의 처지가 보인다. 모델 자체는 선두에 한 뼘 못 미친다. 그래서 메타는 대화의 주제를 슬쩍 옮겼다. "우리 모델이 제일 똑똑하다"가 아니라 "우리 뼈대에 얹으면 이만큼 나온다", 그리고 곧 이어질 이야기처럼 "게다가 값이 이만큼 싸다"로. 성능으로 이길 수 없으면 규칙을 바꾸는 것, 그게 늦게 온 손님의 전략이다.
진짜 이야기는 가격표에 있다
그 규칙 변경이 가장 또렷하게 드러나는 곳이 요금표다. 메타는 Muse Spark 1.2를 자사 API로 팔면서 두 개의 요금제를 나란히 뒀는데, 이 둘을 나란히 놓고 봐야 메타의 속내가 읽힌다.
표준 요금제는 입력 100만 토큰에 1.25달러, 출력 100만 토큰에 4.25달러다. 한 번 본 내용을 다시 넣을 때 쓰는 캐시 입력은 0.15달러로 더 싸다. 여기까지는 평범하다. 눈여겨볼 대목은 메타가 이 요금제에 붙인 약속이다. 이 요금제로 주고받은 내 프롬프트와 결과물은 메타의 모델 학습에 쓰지 않는다는 것이다.
그리고 그 아래에 기여자 요금제(contributor tier)라는 두 번째 문이 있다. 입력 100만 토큰에 0.10달러, 출력에 0.20달러. 표준 요금제와 견주면 입력은 약 12배, 출력은 약 21배가 싸다. 코딩 에이전트는 코드를 읽고 쓰느라 토큰을 어마어마하게 먹는 도구다. 그런 도구의 값이 20배 넘게 싸진다는 건 그냥 할인이 아니라 판 자체가 바뀌는 수준이다.
이 격차가 실제로 얼마나 벌어지는지는 셈을 해보면 확 와닿는다. 에이전트에게 큰 프로젝트를 며칠씩 맡기는 팀이 하루에 출력 5천만 토큰을 쓴다고 치자. 표준 요금제면 하루 출력값만 212달러가 넘고, 기여자 요금제면 10달러다. 한 달로 늘리면 6천 달러대와 3백 달러대로 갈린다. 입력값까지 더하면 격차는 더 벌어진다. 코딩 에이전트처럼 토큰을 많이 먹는 도구에서 이 정도 차이는 한 스타트업의 한 달 인프라 비용을 통째로 좌우한다.
당연히 공짜는 아니다. 이 요금제의 조건은 딱 하나, 데이터다. 기여자 요금제로 주고받은 프롬프트와 결과물은 메타가 앞으로 만들 모델의 학습에 쓰일 수 있다. 표준 요금제가 "안 가져간다"고 못 박은 바로 그것을, 기여자 요금제는 "가져가는 대신 깎아준다"로 뒤집은 것이다. 값과 데이터를 저울 양쪽에 올려두고, 어느 쪽을 내줄지 사용자가 고르게 만든 구조다.
코드를 학습 데이터로 내준다는 것의 무게
20배 할인이라는 말에 솔깃하기 전에, 그 대가로 넘기는 게 정확히 무엇인지 따져볼 필요가 있다.
코딩 에이전트에 흘려보내는 프롬프트에는 생각보다 많은 것이 담긴다. 단순히 "이 함수 고쳐줘"가 아니다. 회사의 코드베이스 구조, 서비스가 돌아가는 방식, 내부에서만 쓰는 규칙, 때로는 실수로 딸려 들어간 접속 정보나 열쇠까지 프롬프트와 결과물에 섞인다. 취미로 개인 프로젝트를 만드는 사람이라면 이걸 학습에 내주는 게 큰일이 아닐 수 있다. 하지만 남에게 보여선 안 되는 코드를 다루는 회사라면 이야기가 다르다. 20배 싸다는 이유로 회사의 핵심 코드가 남의 회사 모델 안으로 스며드는 것을, 비용 담당자는 반길지 몰라도 보안 담당자는 결코 반기지 않는다.
메타가 이런 데이터 정책을 들고 나온 게 처음도 아니다. 메타는 모델 가중치를 공개하는 전략으로 이 판에서 존재감을 키워 왔고, 그 전략을 떠받치려면 계속해서 방대한 학습 데이터가 필요하다. 개발자들이 실제로 코딩하며 주고받는 프롬프트와 코드는, 인터넷에서 긁어모은 데이터보다 훨씬 값진 재료다. 진짜 사람이 진짜 문제를 푸는 과정이 고스란히 담겨 있기 때문이다. 기여자 요금제는 이 값진 재료를 20배 할인이라는 미끼로 사들이는 장치인 셈이다. 표준 요금제가 굳이 "학습에 안 쓴다"를 명시한 것도 뒤집어 보면, 기여자 요금제에서는 확실히 쓴다는 뜻을 분명히 하기 위해서다.
한국의 조직과 개발자에게 무엇이 달라지나
그래서 이 발표를 어떻게 받아들여야 할까. Muse Spark가 클로드보다 똑똑한지 아닌지를 따지는 건 초점을 빗나간 질문이다. 이번 발표가 실무자에게 던지는 진짜 숙제는 다른 데 있다.
지금까지 코딩 도구를 고르는 기준은 대체로 "어느 게 더 잘 짜느냐"였다. 그런데 메타가 값과 데이터를 맞바꾸는 문을 대놓고 열어젖히면서, 여기에 "이 코드를 이 도구에 흘려보내도 되는가"라는 기준이 하나 더 붙었다. 앞으로 조직은 자기 코드를 성격에 따라 나눠 볼 수밖에 없다. 공개해도 무방한 오픈소스 성격의 코드나 학습용 실습 코드라면 기여자 요금제의 20배 할인을 마다할 이유가 없다. 반대로 사업의 핵심이 담긴 코드라면, 아무리 싸도 학습에 내주는 문 근처에 가면 안 된다. 데이터를 등급으로 나누는 일과 모델을 고르는 일이 하나로 합쳐지는 것이다.
앞서 구글이 Gemini Flash를 용도별로 쪼개면서 "어느 일에 어느 모델을 붙일까"가 실무 감각이 됐다면, 이번 메타의 수는 거기에 "어느 코드에 어느 요금제를 붙일까"라는 축을 하나 더 얹었다. 값과 성능만이 아니라 데이터의 행선지까지 저울에 올려 재는 시대다. 공교롭게도 이 판단을 돕는 도구가 Muse Code 안에 이미 들어 있다. 모든 행동을 빠짐없이 적어두는 그 기록장 말이다. 원래는 작업을 되살리려고 만든 장치지만, 어떤 코드가 어디로 흘러갔는지를 감사하는 데도 그대로 쓸 수 있다. 힘이 세진 도구에는 그 힘이 어디로 향했는지 되짚을 수단이 함께 필요하다는 것을, 메타가 의도했든 아니든 Muse Code는 한 몸으로 보여준다.
교육이나 기획을 하는 입장에서도 설명의 결이 바뀐다. "요즘 제일 좋은 코딩 AI가 뭐냐"는 질문에 이제는 모델 이름 하나로 답할 수 없다. 되물어야 한다. 그 코드를 남에게 학습 데이터로 내줘도 괜찮은 코드인지부터. 20배라는 할인폭은 분명 매력적이지만, 세상에 조건 없는 할인은 없다. 메타는 그 조건을 요금표 두 줄로 아주 솔직하게 적어뒀다. 읽고 고르는 건 결국 쓰는 사람의 몫이다.