긴 작업용 오픈 모델이 실전 구간에 들어왔다

📋 오늘의 3줄 요약

• 오픈 모델 GLM-5.2가 100만 토큰 문맥과 긴 코딩 작업 성능을 앞세워 공개됐어요.
• 단순히 긴 입력을 받는 수준을 넘어, 몇 시간짜리 개발 흐름을 버티는 쪽으로 경쟁이 옮겨가고 있어요.
• 이번 주엔 실제 저장소와 고객 로그를 넣고, 비공개 모델 대비 비용과 성공률을 같이 재보세요.

안녕하세요, 오늘은 "오픈 모델을 어디까지 믿고 제품 안에 넣을 수 있나"라는 질문이 꽤 현실적으로 바뀐 날이에요.

📌 오늘의 딥다이브 — GLM-5.2가 100만 토큰 코딩 에이전트를 겨냥했다

무슨 일이 있었나

Z.AI가 Hugging Face 블로그를 통해 GLM-5.2를 공개했어요. 핵심은 두 가지입니다. 하나는 100만 토큰 문맥, 다른 하나는 긴 시간 이어지는 코딩 에이전트 작업이에요. 여기서 문맥은 모델이 한 번에 참고할 수 있는 코드, 문서, 로그, 대화 기록의 양을 뜻해요. 출처

이번 발표가 눈에 띄는 이유는 숫자가 꽤 직접적이기 때문이에요. GLM-5.2는 Terminal-Bench 2.1에서 81.0점을 냈고, 이전 GLM-5.1의 63.5점보다 크게 올랐다고 설명합니다. SWE-bench Pro도 62.1 대 58.4로 개선됐어요. Vercel도 바로 AI Gateway에 GLM 5.2를 추가했고, 모델 이름을 `zai/glm-5.2`로 지정하면 AI SDK에서 쓸 수 있다고 안내했어요. 출처

왜 지금인가

요즘 코딩 에이전트의 병목은 "함수 하나 고치기"가 아니에요. 실제 제품에서는 저장소 전체 구조, 과거 PR, 테스트 실패 로그, 고객 이슈, 사내 코딩 규칙을 같이 봐야 하잖아요. 짧은 문맥 모델은 여기서 자꾸 일부만 보고 결론을 냅니다. 그래서 빌더 입장에서는 모델이 똑똑한지도 중요하지만, 작업 흐름을 끊지 않고 버티는지가 더 중요해졌어요.

GLM-5.2 발표도 이 지점을 정확히 겨냥합니다. Z.AI는 100만 토큰을 받는 것만으로는 부족하고, "길고 지저분한 코딩 에이전트 궤적"에서도 품질을 유지해야 한다고 설명해요. 그래서 대규모 구현, 자동화 연구, 성능 최적화, 복잡한 디버깅 시나리오를 포함해 100만 문맥 학습을 넓혔다고 합니다. 출처

디테일

성능 주장도 긴 작업 쪽에 맞춰져 있어요. FrontierSWE에서는 Claude Opus 4.8보다 1% 뒤지고, GPT-5.5보다 1% 앞섰다고 합니다. PostTrainBench에서는 Opus 4.8 다음 순위라고 설명해요. SWE-Marathon에서는 Opus 4.8보다 13% 뒤졌지만, 여전히 Opus 계열 다음이라고 적었습니다. 모두 Z.AI가 제시한 벤치마크 기준입니다. 출처

아키텍처 쪽 포인트는 IndexShare예요. 쉽게 말해, 긴 문맥을 볼 때 매 층마다 비슷한 검색 계산을 반복하지 않고 여러 층이 일부 인덱서를 공유하게 만든 방식입니다. 발표에 따르면 100만 토큰 길이에서 토큰당 FLOPs(계산량)를 2.9배 줄였어요. 또 MTP 계층을 개선해 speculative decoding(초안을 먼저 만들어 속도를 높이는 방식)의 acceptance length를 최대 20% 늘렸다고 합니다. 출처

라이선스도 제품팀이 볼 지점이에요. GLM-5.2는 MIT 오픈소스 라이선스를 내세웠고, 발표문은 지역 제한 없는 접근을 강조합니다. 동시에 Vercel AI Gateway는 사용량과 비용 추적, 재시도, failover(장애 때 다른 경로로 넘기는 기능), API 키별 예산, Zero Data Retention 지원을 함께 제공한다고 설명해요. 즉 모델 자체와 운영 레이어가 같은 날 같이 움직인 셈입니다. 출처

왜 중요한가

오픈 모델의 의미가 조금 바뀌고 있어요. 예전에는 "로컬에서 돌아가나", "라이선스가 괜찮나"가 중심이었죠. 이제는 "긴 작업을 맡겼을 때 닫힌 모델과 비교할 만큼 버티나"가 질문입니다. HN에서 크게 퍼진 "Open source AI must win" 글도 같은 불안을 건드렸어요. 지능을 소수 기관에서 빌려 쓰기만 하면, 가격과 약관, 원격 플랫폼, 모델 availability에 종속된다는 문제의식입니다. 출처

한국 빌더에게 이건 꽤 실용적인 얘기예요. 고객 데이터나 내부 코드를 외부 API에 넣기 어려운 팀은 늘 있었거든요. 그런데 오픈 모델이 긴 문맥 코딩 작업까지 따라오기 시작하면 선택지가 늘어납니다. 완전 자체 호스팅으로 갈 수도 있고, Vercel AI Gateway 같은 중간 계층을 통해 비용과 장애 대응을 관리할 수도 있어요. 중요한 건 "오픈이라 좋다"가 아닙니다. 우리 워크로드에서 실패율과 청구서가 어떻게 달라지는지예요.

다음 전개

다음으로 볼 것은 실제 재현성입니다. 벤치마크는 방향을 보여주지만, 우리 제품의 저장소와 고객 질문은 다르게 생겼거든요. 특히 100만 토큰 문맥은 입력비, 지연시간, 캐시 비용이 같이 따라옵니다. Z.AI도 긴 문맥에서는 병목이 계산에서 KV-cache 용량, 긴 문맥 커널, CPU 쪽 오버헤드로 옮겨간다고 설명했어요. 출처

정리하면 이렇습니다. 오픈 모델은 이제 "싸고 자유로운 대체재"만은 아니에요. 긴 작업을 맡길 수 있는 제품 부품으로 들어오고 있다. 하지만 제품에 넣기 전에는 반드시 자기 데이터로 재야 합니다.

⚡ 빠른 소식

• Vercel Connect 공개 베타 — Vercel이 에이전트가 Slack, GitHub 같은 외부 도구에 접근할 때 오래 저장된 토큰 대신 짧고 작업 범위가 제한된 자격 증명을 받게 하는 Vercel Connect를 공개 베타로 소개했어요. 출처
• Vercel Sandbox 최대 24시간 실행 — Vercel Sandboxes의 중단 없는 세션 시간이 5시간에서 24시간으로 늘어, 긴 E2E 테스트와 장시간 에이전트 워크플로에 맞춰졌어요. 출처
• AWS Strands Robots와 LeRobot 연결 — Hugging Face 블로그에 AWS Strands Robots가 LeRobot 데이터셋, 시뮬레이션, 실제 SO-101 하드웨어 배포를 하나의 에이전트 루프로 묶는 예제가 올라왔어요. 출처
• OpenAI, 배포 전 행동 예측 방법 소개 — OpenAI가 실제 대화 데이터를 활용해 배포 전 모델 행동을 예측하는 Deployment Simulation을 소개했어요. 출처
• 카카오톡 추천 지표 분석 자동화 사례 — 카카오테크가 카카오톡 추천 시스템에서 CTR 변화, 실험군 반응, 배포 이후 사용자군 변화를 AI 에이전트로 분석 자동화한 사례를 공유했어요. 출처
• 카카오의 바이브 코딩 회고 — 카카오테크는 비개발자가 AI 에이전트와 함께 내부 도구를 만들고 실제 업무에 쓰면서 관심사가 다음 단계로 넘어간 경험을 정리했어요. 출처

🇰🇷 빌더 포인트 — 그래서 오늘 뭘 해야 하나

1. 실제 저장소 하나로 100만 토큰 실험 세트를 만드세요. README, 최근 PR, 실패한 테스트 로그, 고객 이슈 10개를 한 번에 넣어보세요. GLM-5.2와 지금 쓰는 주력 모델에 같은 작업을 시키고, 성공 여부와 수정 횟수, 총 지연시간을 표로 남기면 됩니다.

1. "긴 문맥 = 싸다"라고 가정하지 마세요. 100만 토큰은 편하지만, 비용과 속도를 같이 먹어요. Vercel AI Gateway처럼 사용량·비용 추적과 API 키별 예산을 제공하는 경로를 쓰든, 자체 로그를 붙이든, 작업당 원가를 먼저 보세요.

1. 내부 코드와 고객 데이터 정책을 다시 나누세요. 민감한 저장소는 오픈 모델 후보를 별도 평가하고, 일반 업무는 Gateway나 API로 돌리는 식의 2트랙이 현실적이에요. 이번 주에는 "외부 API 가능", "ZDR 필요", "자체 호스팅 필요" 세 칸으로 워크로드를 분류해 보세요.

오늘의 한 줄: 긴 문맥 오픈 모델은 이제 취미가 아니라 제품 아키텍처 선택지다.

—
Korean AI Builder Brief · 매일 아침 한국 AI 빌더에게