XGEN 뉴스레터 vol.3

에이전트에 도구와 데이터를 붙이는 표준 MCP의 새 명세가 7월 28일 확정됐습니다. 가장 큰 변화는 프로토콜이 상태를 갖지 않게 된 것입니다. 세션 ID와 핸드셰이크가 사라져, 서버를 평범한 로드밸런서 뒤에 여러 개 띄워도 됩니다. 확장이 정식 기능으로 올라서면서 서버가 화면을 그리는 MCP Apps와 오래 걸리는 작업을 다루는 Tasks가 들어왔고, OAuth 2.0 · OpenID Connect 호환과 기능 폐기 정책도 자리를 잡았습니다. 지난해 12월 리눅스 재단 산하로 넘어가 벤더 중립 표준이 된 뒤 처음 나온 큰 개정입니다.

세션을 버렸다는 건 결국 운영 이야기입니다. 그동안은 MCP 서버를 늘리려면 같은 사용자를 같은 파드로 계속 보내야 했는데, 그 제약이 사라집니다. 이번 호에서 외부 API를 컬렉션에 붙이는 이야기를 했는데, 그 붙이는 일을 업계가 어떻게 표준으로 만들고 있는지가 이 문서에 있습니다. MCP 서버를 늘릴 계획이 있다면 세션 고정을 빼도 되는지부터 확인해볼 만합니다.

스포티파이가 사내 AI 코딩 환경 Xirp를 공개했습니다. 진단이 눈에 띕니다 — 에이전트는 빠르고 자신 있게 결정하지만 조직 맥락을 몰라 운영 사고를 낸다는 것. 이 서비스를 누가 소유하는지, 무엇에 의존하는지, 왜 그렇게 설계됐는지는 코드에 없고 슬랙 스레드와 사람 머릿속에 있습니다.

Xirp는 그 맥락을 개발자 포털에서 끌어와 세션마다 넣어주고, 세션에서 새로 나온 지식은 다시 문서로 되돌립니다. 에이전트를 더 똑똑하게 만드는 대신 아는 것을 늘리는 쪽입니다.

우리에게 없는 것이 이 되돌리는 고리입니다. 산출물 자동화가 매일 기록을 남기지만, 거기 담기는 것은 코드가 왜 바뀌었는지까지입니다. 회의에서 정해진 것과 그 방향으로 가기로 한 이유는 여전히 어디에도 남지 않습니다.

새 시스템이 필요한 이야기가 아닙니다. 이미 매일 도는 자리에 한 줄을 더 담을지의 문제입니다.

기업이 쓰는 AI 추론 비용이 올해 최저를 찍었습니다. 100만 토큰당 평균 단가가 지난해 1분기 18.40달러에서 올해 1분기 6.07달러로 내렸고, 8월 초에는 1.16~1.18달러 선입니다. 오픈 모델이 기업 토큰 사용량에서 차지하는 몫도 1년 사이 11%에서 38%로 늘었습니다.

그런데 기업이 실제로 내는 돈은 줄지 않았습니다. 비슷한 기간 기업 AI 지출은 35억 달러에서 84억 달러로 두 배 넘게 늘었습니다. 값이 내려간 만큼 더 쓰기 때문입니다. 구글은 2년 사이 월 토큰 처리량이 330배가 됐다고 밝혔습니다.

새는 곳은 꽤 구체적입니다. 어느 에이전트는 루프에 빠져 11일을 도는 동안 4만 7천 달러를 썼습니다. 단계마다 대화 전체를 다시 보내는 구조라 비용이 대화 길이의 제곱으로 붙습니다. 작은 모델로 될 일을 최상위 모델에 맡기면 최대 50배, 반복되는 입력에 캐시를 걸지 않으면 90%까지 더 냅니다.

줄이는 방법은 이미 자리를 잡았습니다. 값싼 모델로 먼저 거르고(분류·스캔은 100만 토큰당 0.10달러짜리로, 최종 판단만 10달러대 모델로), 안 바뀌는 앞부분은 캐시에 두고, 매번 대화 전체를 다시 보내지 않는 것. 셋을 겹치면 운영 환경에서 60~80%가 줄었다는 보고가 나옵니다. 도구를 2,500개 붙였던 클라우드플레어는 도구 목록만 117만 토큰이던 것을 두 개로 접어 1,000 토큰으로 만들었습니다.

싸졌다는 말이 성립하려면 세는 단위가 같아야 합니다. 토큰 하나의 값은 3분의 1이 됐지만, 일 하나를 끝내는 데 드는 토큰 수는 그보다 빨리 늘었습니다. 셋 중 무엇부터 손댈지 정하려면 어디서 새는지가 먼저 보여야 합니다. 스탠퍼드 HAI는 도구 호출 단위로 토큰을 재는 팀이 청구서 총액만 보는 팀보다 절감 지점을 3배 빨리 찾는다고 정리했습니다. 우리 관리 화면에는 지금 사용자별 합계까지 있습니다. 그 옆에 호출 단위로 보는 칸이 하나 더 필요해 보입니다.

레디스를 만든 antirez가 요즘 자기 작업 방식을 적었습니다. 코드를 짜는 일과 버그를 찾는 일은 모델에 맡기고, 아이디어 설계와 QA, 최적화 전략, 설계 문서는 직접 씁니다. 로컬에서 도는 LLM 추론 소프트웨어를 만들면서 DeepSeek과 GLM 구현을 모델에 시켰지만, "구현해줘"라고 말하고 그게 돌아가기를 기대할 수는 없었다고 합니다. 설계와 성능을 이해하고 있어야 지시가 성립합니다.

그의 결론은 이렇습니다. 소프트웨어의 아이디어를 내가 쥐고 있다면 코드 자체를 들여다보는 일은 대체로 무의미하다는 것입니다. 아무도 이 코드를 보지 말고 코드가 담은 아이디어만 보라고 씁니다. 그리고 70년대에 나온 책이 2000년에서 2020년 사이에 나온 많은 것보다 지금을 더 잘 설명한다고 덧붙입니다.

불편한 쪽은 그의 주장이 아니라 우리입니다. 코드를 봐야 한다고 말하는 사람들도 실제로는 보지 않습니다. 승인 버튼을 누르기 전에 diff를 끝까지 내려본 게 최근 언제였는지 떠올려보면 됩니다. antirez는 안 보기로 정하고 대신 설계를 쥐었습니다. 우리는 본다고 말하면서 안 봅니다. 둘 중 정직한 쪽은 그입니다.

구글이 "Go가 AI 보조 개발에 적합한 언어"라는 글을 냈는데, 언어 이야기보다 앞의 진단이 남습니다. 사람이 코드를 얼마나 빨리 쓰는지는 이제 별로 중요하지 않고, 중요한 것은 이미 쓰인 코드를 리뷰하고 검증하고 유지하는 일이라고 씁니다. 병목이 생성에서 검증으로 통째로 옮겨갔다는 표현도 나옵니다.

수치도 있습니다. 첫 생성은 95% 맞지만, 같은 작업을 반복시킬수록 오류가 쌓이고 맥락이 오염되면서 정확도는 떨어지고 토큰 비용은 올라갑니다. 그래서 읽기 쉬운 문법, 자동 안전망 역할을 하는 정적 타입, 15년 전 코드도 그대로 컴파일되는 호환성이 값을 갖는다는 논리입니다.

지난 2주에 사내 브랜치로만 293건이 머지됐습니다. 이번 호 개발 중 항목에 있는 산출물 자동화 시스템이 겨냥하는 곳이 바로 여기입니다 — 코드가 바뀌면 매뉴얼이 따라 바뀌게 해서, 사람이 뒤쫓아야 할 몫을 줄이는 쪽입니다. 지난 2주에만 스무 개 넘는 챕터가 그렇게 갱신됐습니다.

다만 생성이 싸져서 생긴 문제를 또 다른 생성으로 막는 구조이기도 합니다. 자동으로 쓰인 문서는 누가 읽고, 맞는지는 무엇으로 확인할까요. 이 질문이 다음 자리에서 기다립니다. 지금 우리가 가진 답은 사람이 챕터를 열어본다 하나뿐입니다.

8월 4일에 올라온 글인데 전제가 과감합니다. 코드를 만드는 값이 계속 떨어져서, 큰 코드베이스를 통째로 다시 구현하는 비용이 지금의 SaaS 구독료 수준까지 내려간다면 어떻게 될까. 그때는 소프트웨어를 만드는 방식 자체가 달라져야 한다는 것이 저자의 출발점입니다.

구상은 이렇습니다. 저장소에 코드를 두지 않고 요구사항 명세를 둡니다. 보안 정책이 바뀌거나 성능 기준이 달라지면 명세를 고친 뒤 버튼을 눌러 전체를 다시 생성합니다. 새 요구사항으로 재생성하는 일이 프로그램을 다시 컴파일하는 것만큼 간단해야 한다고 씁니다. 코드는 오래 남는 진짜 산출물의 일회용 부산물이 된다는 표현도 나옵니다.

다만 자동 생성만으로는 안 된다고 못 박습니다. 만들어진 코드가 요구사항을 지켰는지 확인할 수 있어야 하고, 그러려면 뜻이 흔들리지 않는 언어로 명세를 써야 한다고 덧붙입니다. 자연어로 적어둔 요구사항만으로는 이 그림이 성립하지 않습니다.

이 구상이 겨냥하는 곳은 결국 고치는 일입니다. 개발에 드는 시간의 많은 부분은 새로 만드는 데가 아니라 이미 만든 것을 붙잡고 고치는 데 들어갑니다. 명세에서 다시 뽑을 수 있다면, 고치는 대신 새로 만드는 선택지가 생깁니다.

그래서 우리는 얼마나 고치고 있는지 세어봤습니다. 지난 2주 사내 브랜치에 올라온 293건 가운데 무언가를 고치는 MR이 125건, 43%였습니다. 그중 제목에 [긴급]이 붙은 것이 둘 있었습니다. 업로드가 통째로 안 되던 오류와 DB 조회 노드가 죽던 오류입니다. 이 숫자는 품질이 나쁘다는 뜻일 수도 있고, 빨리 고칠 수 있으니 그만큼 자주 고친다는 뜻일 수도 있습니다. 어느 쪽인지는 숫자만 봐서는 알 수 없습니다.

짚고 갈 것이 하나 있습니다. 우리는 지금 코드가 바뀌면 매뉴얼이 따라 바뀌는 시스템을 만들고 있습니다. 코드가 원본이고 문서가 그 뒤를 따라갑니다. 이 글은 정반대를 제안합니다. 요구사항이 원본이고 코드가 그 결과물이라는 쪽입니다. 무엇이 원본이어야 하는지는 아직 답이 없지만, 이렇게 물어보면 조금 선명해집니다. 지금 우리 저장소에서 없어지면 안 되는 것은 무엇입니까. 코드가 전부 날아가도 요구사항이 남아 있으면 다시 만들 수 있습니다. 반대라면 어렵습니다.