오늘은 넷입니다 — Copilot에 들어온 첫 오픈 웨이트 모델, 워크플로 상태를 DB 옆에 두자는 주장, 코딩 에이전트 벤치마크의 신뢰성 검증, MCP 서버 전용 클라우드. 묶고 보니 방향이 하나예요: 모델도 서버도 ‘갈아끼우는 부품’이 되는 대신, 무엇으로 고르고 어디에 상태·검증 경계를 둘지는 각자의 몫으로 남습니다. 각 항목은 ‘한 줄 판단’부터 던집니다.

오늘의 핵심

1. Kimi K2.7 Code — Copilot 모델 피커에 들어온 첫 오픈 웨이트 모델

• 한 줄 판단: 어제 본 ‘하네스와 모델의 분리’가 하루 만에 본진에서 확인됐습니다. 오픈 웨이트 모델이 Copilot의 선택지로 들어왔다는 건, 이제 모델은 성능·비용 표를 놓고 고르는 부품이라는 뜻이에요 — 잠금의 대상이 아니라.
• 사실: GitHub이 오픈 웨이트 모델 Kimi K2.7 Code를 Copilot에서 GA로 제공하기 시작했습니다. 모델 피커에 선택지로 들어온 첫 오픈 웨이트 모델이고, Pro·Pro+·Max부터 순차 적용, Business·Enterprise는 수 주 내 확대(기본 꺼짐·관리자 활성화 필요)입니다. 과금은 제공사 정가 기준 사용량 과금.
• 이번 주 할 일: Copilot을 쓰신다면 반복적이고 위험이 낮은 작업 한 종류로 기존 모델과 결과·비용을 나란히 재보시길 권합니다. 단, 사용량 과금이라 정액 감각으로 돌리면 청구서가 먼저 놀라니, 소규모로 재는 편이 균형이 맞습니다.

2. DBOS — “워크플로 상태는 데이터 옆에” · exactly-once의 실체

• 한 줄 판단: exactly-once는 늘 한 트랜잭션 경계 안에서만의 약속입니다. 체크포인트와 데이터 갱신을 같은 Postgres 트랜잭션에 넣으면 그 안에서는 성립하지만, 외부 API·다른 시스템을 건드리는 순간 멱등 설계는 다시 각자의 몫이에요 — 이 경계를 아는 게 도입의 절반입니다.
• 사실: DBOS가 워크플로 엔진의 상태(체크포인트)를 애플리케이션 데이터와 같은 Postgres에 두면, 단계 체크포인트와 데이터 갱신을 한 트랜잭션으로 묶어 부분 실패를 없앨 수 있다고 주장했습니다. 트랜잭션 안에서 워크플로를 큐잉하는 트랜잭셔널 아웃박스 패턴도 함께 제시. (자사 오픈소스 라이브러리 DBOS Transact 홍보를 겸한 개발사 공식 글 ⚠️.)
• 이번 주 할 일: 사가·재시도 로직을 손으로 짜고 있다면 이 구조를 한 번 읽어 보시길 권합니다. 단, 상태와 데이터를 한 DB에 모으면 그 Postgres가 결합점이자 병목이 되는 셈이라, 트래픽이 큰 흐름이면 느슨한 결합(큐 분리)과의 득실을 먼저 재보시면 좋습니다.

3. 코딩 에이전트 ‘성능 최적화’ 벤치마크 — 순위표를 믿어도 되나

• 한 줄 판단: 리더보드 점수로 에이전트를 고르는 건 아직 이르다는 신호입니다. 재현 환경만 바꿔도 기준 과제의 다수가 무효가 됐으니, 벤치마크는 참고로, 채택 판단은 사내 워크로드 검증으로 하는 편이 안전해요.
• 사실: 연구진이 GSO·SWE-Perf·SWE-fficiency 세 벤치마크의 과제 740개를 4종 클라우드 머신에서 재실행하니, 기준 패치가 유효하게 남은 과제가 GSO는 102개 중 39개, SWE-Perf는 140개 중 11개에 그쳤습니다. 공식 순위는 공유 제출물 쌍 비교 28건 중 9건에서 서로 어긋났고, 한 벤치마크는 점수의 58~83%가 하위 10개 과제에 쏠려 있었습니다.
• 이번 주 할 일: 에이전트·모델 선정 문서에 벤치마크 점수를 인용하고 있다면, 자체 과제 몇 개로 재검증한 수치를 한 줄 병기해 두시길 권합니다. 단, 자체 평가 세트를 만들고 유지하는 데도 손이 가니, 도입 결정이 걸린 도구부터 좁게 시작하는 게 현실적입니다.

4. Manufact — ‘MCP의 Vercel’을 표방하는 전용 클라우드

• 한 줄 판단: 2010년대 웹이 Heroku→Vercel로 배포를 상품화했던 사이클이 MCP 서버에서 반복되고 있습니다. 통합의 마찰이 줄면 다음 병목은 ‘어떤 도구를 에이전트에 물릴지’라는 큐레이션과 권한 설계로 옮겨가요.
• 사실: YC 출신 Manufact가 MCP 서버 개발 SDK(mcp-use, 오픈소스)와 호스팅 플랫폼(Manufact Cloud)을 발표했습니다. git push 배포·브랜치별 프리뷰·커스텀 도메인에, 한 번 만들어 ChatGPT·Claude·Gemini·코딩 에이전트에 함께 물리는 걸 내세웁니다. (다운로드 수·대형 고객 사용 주장은 벤더 발표 기준 ⚠️.)
• 이번 주 할 일: 사내 도구를 MCP로 노출할 계획이 있다면, 직접 호스팅과 이런 전용 플랫폼의 운영 부담을 비교해 보시길 권합니다. 단, 초기 플랫폼에 올리면 배포는 쉬워져도 장애·보안·가격 변경을 플랫폼과 함께 겪는 의존이 생기니, 내부 전용 도구라면 자체 호스팅이 여전히 무난합니다.

그래서, 무엇이 바뀌나

넷을 관통하는 흐름 — AI 스택의 부품화입니다. 모델은 Copilot 피커에서 고르고(1), MCP 서버는 push 한 번으로 배포되는(4) 쪽으로 마찰이 사라지는데, 정작 무엇으로 고를지의 근거인 벤치마크는 흔들리고(3), 상태·멱등의 경계 설계는 여전히 사람 몫으로 남습니다(2). 그럼의 편집 기준(느슨한 결합=안정성, AI도 역할·입출력·검증·복구 경계가 있어야 제품)으로 보면, 공개된 기술사에서 부품이 흔해질 때마다 승부처는 늘 조립 기준과 경계 설계로 옮겨갔습니다 — 이번에도 같은 자리로 가고 있어요. (데일리 트렌드를 고르는 기준도 같은 렌즈입니다.)

참고 / 출처

• Kimi K2.7 Code is generally available in GitHub Copilot — GitHub 공식 체인지로그
• Postgres transactions are a distributed systems superpower — DBOS 공식 블로그 (자사 제품 홍보 성격)
• Are Performance-Optimization Benchmarks Reliably Measuring Coding Agents? — arXiv 원 논문
• Manufact — MCP Cloud — 당사자 발표 (Launch HN)
• 함께 보기: 어제의 ‘GLM 코딩 에이전트·하네스와 모델의 분리’