XGEN 뉴스레터 vol.4

지난 호에 MCP 새 명세 이야기를 전해드렸는데, 그 뒷이야기가 이어졌습니다. 구글이 만든 에이전트 간 통신 표준 A2A가 8월 17일 리눅스 재단 산하 AAIF(Agentic AI Foundation)로 옮겨 왔습니다. 도구를 붙이는 표준 MCP가 이미 있는 곳입니다. 이로써 에이전트가 도구를 부르는 규약(MCP)과 에이전트끼리 일을 주고받는 규약(A2A)이 같은 중립 재단에서 관리됩니다. 재단 멤버는 출범 여덟 달 만에 40곳에서 250곳을 넘겼고, AWS·구글·마이크로소프트·앤트로픽·OpenAI가 모두 이름을 올렸습니다.

두 표준의 역할 구분은 우리 지형에도 그대로 겹칩니다. XGEN이 도구를 붙일 때 쓰는 것이 MCP이고, DeX가 내 PC의 도구를 서버 에이전트에 잇는 것도 이 규약 위입니다. 비어 있는 쪽은 A2A입니다. XGEN 에이전트끼리는 일을 주고받지만, 다른 회사 제품의 에이전트와 주고받는 표준 경로는 아직 없습니다. 고객이 이미 쓰는 에이전트 옆에 XGEN이 서야 하는 날이 오면 이 규약부터 꺼내게 될 텐데, 그때 정할 게 하나 있습니다. A2A를 열어 남의 에이전트와도 대화하게 할지, 한 플랫폼 안에서 다 끝낸다는 지금의 강점을 지킬지. 상호운용은 우리 울타리 안으로 경쟁 제품을 들이는 문이기도 해서, "표준을 따른다"가 곧 우리 이득은 아닙니다. 언제 이 문을 열지가 다음 숙제입니다.

중국 Zhipu가 GLM-5.3을 8월 중순 내놓고 8월 말 가중치까지 공개했습니다(744B MoE, 활성 40B, 200K 컨텍스트). 터미널 작업 벤치마크에서 점수가 4.6에서 28.3으로 여섯 배 넘게 뛰어 오픈 모델 1위에 올랐고, 보안 벤치마크(CyberGym 84.5%)에서는 Claude·GPT 최상위를 살짝 앞섰습니다. 발표는 해커뉴스에서 800포인트를 넘겼습니다.

핵심은 값입니다. 한 분석에 따르면 비슷한 성능을 프런티어의 5분의 1 비용에 낸다고 합니다(공식 단가는 아직 미공개). 지난 호에서 "토큰 값은 3분의 1이 됐다"고 전해드렸는데, 그 하강선이 오픈 모델 쪽에서 더 가팔라지는 중입니다. 오픈 모델이 프런티어를 5분의 1 값에 따라잡는다면, 폐쇄망에 오픈 모델을 들인다는 우리 베팅은 맞아 들어가는 셈입니다. 다만 어려운 일은 자리를 옮깁니다. 모델 자체가 아니라, 달마다 쏟아지는 새 오픈 모델(이번 달만 GLM·Qwen 둘)을 얼마나 빨리 검증하고 서빙하고 통제 아래 두느냐가 관건이 됩니다. 값이 싸질수록 경쟁력은 모델이 아니라 그 위의 층, 곧 서빙 파이프라인과 거버넌스에서 납니다.

알리바바가 8월 중순 Qwen3.8을 오픈웨이트로 풀었습니다. 최상위 Qwen3.8-Max(2.4조 파라미터 MoE)까지 가중치를 공개한 건 이 계열에서 처음이고, 곧이어 나온 Qwen3.8-27B는 아파치 2.0 라이선스에 이미지·영상까지 읽습니다. 독립 벤치마크 Artificial Analysis에서 27B가 52점을 받아 이 크기대에서 앞선 축에 들었고, 발표마다 해커뉴스에서 수백에서 천 단위 추천을 받았습니다.

이건 우리에겐 남의 뉴스가 아닙니다. 이번 호 관측 카드의 채팅 통계 화면에 이미 Qwen3.8-27B가 이름을 올리고 있습니다(개발 환경). 다만 개발 통계에 이름이 오르는 것과, 고객 폐쇄망에서 실제로 도는 것 사이엔 먼 거리가 있습니다. 한국어 성능 검증, 양자화(FP8) 안정성, 그리고 금융·공공 고객이라면 모델 출처까지 따집니다. 모델을 갈아 끼우는 "여는 쪽"에 선다는 건, 새 오픈 모델이 나올 때마다 "이번 것도 고객이 믿고 맡길 수 있나"를 매번 다시 답한다는 뜻이기도 합니다. 그 답을 빠르고 미덥게 내는 절차가 우리의 진짜 자산입니다.

13년 차 엔지니어링 매니저가 쓴 글의 요지는 한 문장입니다. AI는 조직의 성질을 바꾸지 않고 증폭한다. 소통이 잘 되고 구조가 깨끗한 팀에서는 속도가 오르고, 프로세스가 엉킨 팀에서는 모두가 잘못된 방향으로 더 빨리 갑니다.

지난 호 스포티파이 이야기(에이전트가 모르는 건 코드가 아니라 조직이다)와 같은 자리를 짚는 글입니다. 측정 연구가 붙은 글은 아니고 경험담입니다만, 도구를 들이기 전에 던질 질문 하나는 남습니다. 우리 조직은 지금 증폭되면 좋아지는 상태인가. 한 겹 더 있습니다. XGEN은 고객 조직도 똑같이 증폭합니다. 정돈된 곳에선 빨라지지만, 프로세스가 엉킨 곳에 그대로 넣으면 엉킴이 더 빨라질 뿐입니다. 도입에서 기술만큼 중요한 게 "어디에, 어떤 순서로 넣느냐"라는 이야기이기도 합니다.

취약점 분석에 LLM을 쓰던 저자가 부딪힌 문제는 우리 것과 같습니다. 오래 조사하다 보면 모델이 이미 확인한 사실을 잊거나, 무효가 된 가정 위에서 계속 추론합니다. 진단이 날카롭습니다. 벡터 검색은 "관련 있는 기억인가"에는 답해도 "지금도 참인가"에는 답하지 못한다는 것.

그래서 기억을 문장이 아니라 사실 단위로 저장하고, 사실이 바뀌면 그 위에 쌓인 결론만 자동으로 무효가 되는 엔진(Datalog)을 붙였습니다. 대화 전체를 다 넣는 방식보다 문맥이 38분의 1로 줄었는데, 앞선 말이 뒤집히는 적대적 질문에서는 오히려 크게 앞섰습니다(F1 0.707 대 0.509). 검색이 "관련 있는가"만 묻고 "지금도 참인가"는 못 묻는다는 지적은, 우리가 대화로 에이전트를 만들고 오래 쓰게 하려 할 때 곧 만날 벽입니다. 벡터로 기억을 쌓는 것만으로는, 어제 정한 게 오늘 뒤집혔을 때 조용히 옛 사실을 물어옵니다. 개인 맥락을 오래 기억하는 에이전트일수록 치명적입니다. 기억을 고쳐지는 사실로 다루는 이 설계를 우리가 얼마나 들일지, 지금이 들여다볼 때입니다.

한 개발자가 "긴 영어로 매번 지시하는 데 완전히 지쳤다"며 코딩 방식을 뒤집은 실험을 공개했습니다(HN 384포인트). Huzzah는 자연어 대신 간결한 의사코드로 의도를 적는 에디터입니다. "100까지 돌며 3의 배수면 fizz"라고 문장으로 쓰는 대신, loop 100 / modulo 3 ? "fizz" 처럼 몇 줄로 적습니다. 그 의사코드를 파일로 저장해 두고, 고칠 때는 바뀐 부분(diff)만 모델에 프롬프트로 넘깁니다. 매번 대화 전체를 다시 보내지 않으니 토큰도 아낍니다.

핵심은 코드가 아니라 의도를 원본으로 삼는다는 발상입니다. 의사코드가 곧 사람이 읽는 설계 문서가 되고, 버전 관리도 됩니다. 지난 호에 "코드 대신 요구사항을 원본으로 두자"던 글과 같은 자리이고, 이번 호 산출물 자동화(코드에서 문서를 뽑는 우리)와는 정반대입니다. 어느 쪽이 원본인가. 흥미로운 건 XGEN 안에 이미 두 답이 함께 산다는 점입니다. 개발자가 짠 코드는 산출물 자동화가 문서로 풀어내고(코드가 원본), 기획자가 Canvas에서 만드는 워크플로우는 의도가 먼저고 실행이 따라옵니다(의도가 원본). 자동 생성이 싸질수록 이 경계가 어디에 그어지느냐가 제품의 모양을 정할 겁니다. 저자가 인정한 한계(큰 코드베이스엔 아직 무리)까지 같이 읽어볼 만합니다.