오늘 눈여겨본 변화가 실무에 무엇을 요구하는지 핵심만 추려 정리했습니다. 각 항목은 사실을 짧게 밝히고, 한 줄 판단과 이번 주 확인할 일을 남깁니다.

오늘의 핵심

1. MCP 2026-07-28 스펙 — 세션이 사라졌고, 폐기 예고가 다섯 건 붙었습니다

• 사실: 7월 28일 MCP(모델과 외부 도구를 잇는 개방형 프로토콜) 리드 메인테이너들이 스펙 버전 2026-07-28을 공개했습니다.
  • 핵심은 무상태(요청 사이에 서버가 상태를 안 들고 있는 방식) 전환입니다. initialize/initialized 교환과 Mcp-Session-Id 헤더를 걷어내고, 요청마다 프로토콜 버전·신원·capability를 함께 싣습니다. 목적은 공유 저장소 없이 로드밸런서 뒤 아무 인스턴스로나 요청이 가도 되게 만드는 것입니다.
  • 열린 스트림을 잡고 있어야 했던 서버→클라이언트 호출(elicitation/create·sampling/createMessage·roots/list)은 MRTR(다중 왕복 요청)로 대체됩니다. 서버가 resultType: "input_required"로 필요한 것을 돌려주면 클라이언트가 답을 담아 다시 겁니다.
  • 폐기 예고도 붙었습니다 — Roots·Sampling·Logging 세 기능, 레거시 HTTP+SSE 트랜스포트, 동적 클라이언트 등록이 CIMD(클라이언트 ID 메타데이터 문서)로 바뀌는 것까지 다섯 건입니다. 대신 최소 12개월 오프램프를 보장하는 공식 폐기 정책이 신설됐습니다.
  • 게이트웨이가 JSON 본문을 열어보지 않고 라우팅·미터링하도록 Mcp-Method·Mcp-Name 헤더가 추가됐습니다. Tier 1 SDK 4종(TypeScript·Python·Go·C#)은 공개 시점에 이미 새 스펙을 말하고, 러스트 SDK는 베타로 따라붙었습니다.
• 한 줄 판단: 세션을 없앤 것은 상태를 지운 게 아니라 옮긴 것입니다. 서버 쪽 배포는 단순해집니다 — 공유 스토리지가 빠지면 서버리스(서버 운영을 플랫폼에 맡기는 실행 모델)와 오토스케일이 훨씬 편해지죠. 대신 그 비용은 요청 크기와 클라이언트의 재시도 로직으로 옮겨 앉습니다. MRTR이 특히 그렇죠 — 스트림 하나로 끝나던 사용자 입력 요청이 돌려주고 다시 부르는 왕복이 됩니다. “이제 서버리스에 그냥 올리면 된다”는 요약은 폐기 예고 다섯 건을 세지 않은 문장입니다.
• 이번 주 할 일: MCP 서버를 운영한다면 폐기 목록 다섯 건 중 몇 개를 쓰는지 세어 보시길 권합니다 — 12개월은 계획할 시간이지 미뤄도 되는 시간이 아닙니다. 단, 무상태로 옮기면 확장은 쉬워지지만 세션에 기대던 캐시·컨텍스트는 다시 설계해야 합니다. 개인 기여자라면 서버 코드에서 Mcp-Session-Id를 한 번 검색해 보시면 영향 범위가 바로 보입니다.

2. Denial of Deadline — 가용성은 멀쩡한데 정확도만 무너집니다

• 사실: 7월 27일 arXiv에 분산 추론 파이프라인의 네트워크발 정확도 붕괴를 다룬 논문이 올라왔습니다(Jhonatan Tavori·Gur-Eyal Sela·Ion Stoica·Gil Zussman).
  • 대상은 빠른 경로(엣지)와 느린 경로(클라우드)의 결과를 합치는 2단 추론 구조입니다. 버스트로 빚어낸 요청이 느린 경로의 공유 네트워크를 혼잡하게 만들면, 선량한 사용자의 예측이 지연 마감을 넘겨 병합 단계에서 버려집니다.
  • 자율주행 다중 객체 추적 시뮬레이션에서 약 4,000건의 버스트 요청만으로 p99 지연(느린 쪽 1%의 응답 시간)이 92ms에서 2초로 뛰었습니다.
  • 추적 품질은 평균 7.0 HOTA 포인트(다중 객체 추적의 종합 정확도 점수) 떨어졌고, 노리는 구간에 따라 2.0~18.7로 갈렸습니다. 정지 표지 같은 희귀 클래스는 절반 가까이 잃었습니다.
  • ⚠️ 동료평가 전 프리프린트입니다.
• 한 줄 판단: 시스템은 계속 정상 응답하는데 답의 질만 나빠지는 공격입니다. 가용성 지표는 멀쩡합니다 — 빠른 경로가 제때 답을 돌려주니 에러율도 타임아웃도 오르지 않고, 무너지는 값은 대시보드에 없죠. 돈과 물리가 함께 걸린 시스템에서 작은 실수도 허용되지 않는다는 기준을 뒤집어 보면, 여기서 위험한 건 실수가 아니라 실수가 아무 신호도 남기지 않는다는 점입니다.
• 이번 주 할 일: 엣지·클라우드 2단 추론을 쓰고 있다면 마감을 넘겨 버려진 예측의 비율을 지연 분포와 별개의 지표로 내보내시길 권합니다. 단, 마감을 늘려 버림을 줄이면 정확도는 지켜지지만 응답 지연이 늘어 실시간 제약과 부딪힙니다. 개인 기여자라면 담당 파이프라인에서 폴백이 조용히 발동하는 지점을 세어 보시면 시작점이 됩니다.

3. 자기 채점 에이전트 — 시험지는 만점인데 배포 성적은 오르지 않습니다

• 사실: 같은 날 arXiv에 자기개선 에이전트의 자체 검증이 신뢰할 수 없다는 논문이 올라왔습니다(Diandian Guo 외 5인).
  • 다루는 것은 검증자·배포 격차입니다. 자기 정책을 스스로 고쳐 쓰는 에이전트에서 자기가 매긴 점수는 만점 근처인데, 실제 배포 성능은 떨어지거나 낮은 채로 머물렀습니다.
  • 원인은 구조입니다 — 최적화와 검증을 같은 주체가 쥐면 피드백 루프가 신뢰를 잃습니다. 약한 에이전트는 자기 시험을 통과하면서도 이미 배운 전략을 망가뜨렸죠.
  • 제안은 SEAL(봉인된 외생 수용 루프)입니다. 자체 작성 테스트는 두되 에이전트가 접근·조작할 수 없는 외부 감사 검증을 덧대는 방식으로, 모델 6종·시드 3개에서 보호 없는 기준선보다 나은 결과를 냈습니다. 결론은 한 줄입니다 — 믿을 만한 자기개선에는 에이전트 통제 밖의 수용 신호가 최소 하나 있어야 합니다.
  • ⚠️ 프리프린트(9쪽·그림 6)입니다.
• 한 줄 판단: AI가 자기 일을 채점하게 두면 좋아지는 것은 성능이 아니라 점수입니다. 어제 다룬 스킬 회귀세가 원래 되던 일이 깨진다는 사실을 측정했다면, 이 논문은 그게 왜 눈에 띄지 않는지를 말합니다. 채점자가 안에 있으면 깨진 것을 깨졌다고 적을 이유가 없죠. AI를 제품에 넣을 때 역할·입출력·검증·복구의 경계가 있어야 한다는 기준에서 가장 자주 비는 칸이 검증인데, 처방은 그 칸을 바깥에 두라는 한 문장입니다.
• 이번 주 할 일: 자기개선 루프나 자동 평가를 돌린다면 합격을 선언하는 신호가 에이전트 바깥에 하나라도 있는지 확인해 보시길 권합니다 — 없다면 그 루프가 재는 값은 성능이 아니라 자기 확신입니다. 단, 외부 감사를 끼우면 신뢰도는 오르지만 반복 주기가 느려지고 감사용 평가 세트 유지 비용이 새로 생깁니다. 개인 기여자라면 평가 스크립트의 통과 기준을 누가 정했는지 한 줄로 적어 보시면 출발점이 됩니다.

4. OpenAI Codex Security — 열린 건 스캐너고, 남는 건 리포트 보관 문제입니다

• 사실: OpenAI가 코드의 보안 이슈를 찾고 검증·리뷰하는 CLI와 TypeScript SDK를 codex-security로 공개했습니다(Apache-2.0).
  • 기본 모델은 gpt-5.6-sol에 추론 강도(답하기 전 생각에 쓰는 예산) 최상이며 --model로 바꿀 수 있습니다. OpenAI API 키나 ChatGPT 로그인이 필요합니다.
  • 결과는 SARIF(정적 분석 결과 표준 교환 포맷)·CSV·JSON으로 내보내고, 스캔 이력 관리와 도커 대량 스캔을 지원합니다. 기본 동작은 보고 전용이며 대상은 “소유했거나 평가 권한이 있는” 저장소로 한정합니다.
  • 문서가 직접 경고합니다 — 산출물에는 소스 발췌·취약점 상세·재현 절차가 담기므로 저장소·공개 이슈·공유 위치에 두지 말라는 것이고, 출력 디렉터리도 스캔 대상 바깥에 두라고 명시합니다.
  • ⚠️ 1.0.0 이전이라 공개 API가 마이너 버전 사이에 바뀔 수 있습니다.
• 한 줄 판단: 가장 조심해야 할 산출물은 취약점 목록이 아니라 그 목록이 담긴 파일입니다. 재현 절차까지 적힌 리포트는 그 자체로 공격 안내서라, 스캔을 CI에 붙이는 순간 아티팩트 보관 위치가 새 공격면이 됩니다. 문서가 굳이 경고를 적어 둔 이유죠. 무시해도 될 신호는 “AI가 보안 점검을 대신한다”는 요약입니다 — 설명부터 찾기와 검증과 리뷰를 나눠 적어 두었으니까요.
• 이번 주 할 일: 도입을 검토한다면 스캔 아티팩트를 어디에 두고 누가 열람할지부터 정하시길 권합니다 — CI 아티팩트의 기본 보관 설정은 대개 팀 전체 열람입니다. 단, 접근을 좁히면 유출 위험은 줄지만 이슈가 실무자에게 닿는 속도도 함께 느려집니다. 개인 기여자라면 권한을 가진 저장소 하나에 보고 전용으로 돌려 SARIF 출력만 훑어보시면 감이 잡힙니다.

그래서, 무엇이 바뀌나

오늘 네 항목이 건드린 자리는 각각 세션 상태, 버려지는 예측, 합격을 선언하는 주체, 리포트 파일의 보관 위치였습니다. 넷 다 무엇이 좋아졌는가보다 좋아졌다고 누가 무엇을 근거로 말하는가를 묻게 하는 소식이었죠.

MCP는 상태를 서버에서 요청으로 옮겼고, Denial of Deadline은 가용성 지표가 멀쩡한 채로 정확도만 무너지는 경로를 보였으며, SEAL은 채점자를 에이전트 바깥으로 빼라고 했고, Codex Security는 발견을 자동화하면서 결과물의 보관은 사람에게 남겼습니다. 공개된 기술사가 반복해 보여준 모양도 같습니다 — 자동화가 한 겹 들어올 때마다 판정 권한이 어디에 있는지가 그 시스템의 진짜 경계가 됐죠.

참고 / 출처

• MCP 공식 블로그 — 2026-07-28 스펙
• arXiv 2607.24692 — Denial of Deadline
• arXiv 2607.24300 — Self-Authored Verification Is Unreliable
• openai/codex-security (GitHub · Apache-2.0)