OpenAI가 GPT-5.5를 공개했다. 요즘IT가 정리한 릴리즈 노트에 따르면 이번 모델은 GPT-5.4 대비 지능을 높이면서도 토큰당 레이턴시는 동일하게 유지했고, 같은 Codex 작업을 더 적은 토큰으로 처리한다. SWE-Bench Pro에서 58.6%, Terminal-Bench 2.0에서 82.7%를 기록했다. 얼리 테스터들은 "지금까지 써본 코딩 모델 중 진정한 의미의 개념적 명료함을 갖춘 첫 모델"이라고 평가했다. 수백 건의 프론트엔드 변경이 담긴 브랜치를 단 20분 만에 메인 브랜치로 병합하는 사례도 나왔다.
같은 시간대에 정반대의 뉴스가 터졌다. 디지털투데이 보도에 따르면, Anthropic이 Claude Code의 성능 저하를 공식 인정했다. AMD AI 그룹 수석 디렉터가 GitHub에서 "복잡한 엔지니어링 작업을 맡기기 어려울 정도로 퇴행했다"고 지적한 지 수 주 만이다. Anthropic이 밝힌 원인은 세 가지—기본 사고 수준 설정 변경, 캐시 최적화 과정의 버그, 응답 길이를 줄이기 위한 시스템 프롬프트 수정. 기저 모델 자체의 문제는 아니었다. 하지만 사용자 입장에서는 그 구분이 중요하지 않았다. 모델은 그냥 망가져 있었다.
이 두 사건을 나란히 놓으면 불편한 진실 하나가 드러난다. 모델 업그레이드 사이클이 빨라질수록, 팀이 그 변화를 감지하고 대응하는 속도는 구조적으로 뒤처진다는 것이다. GPT-5.5가 에이전트 코딩 능력을 한 단계 끌어올리는 동안, Claude Code는 시스템 프롬프트 한 줄 수정으로 수 주간 조용히 성능이 떨어져 있었다. 팀이 그걸 감지한 건 벤치마크가 아니라 Reddit과 GitHub의 불만 제보였다.
여기서 세 번째 퍼즐 조각이 필요하다. dev.to에 올라온 한 시니어 엔지니어의 글은 이 문제의 본질을 정확하게 짚는다. 그는 이렇게 썼다. "몇 년 전만 해도 나는 팀이 주 단위로 올리는 PR을 따라갈 수 있었다. 훑는 게 아니라 실제로 읽었다. 지금은 그럴 수 없다. 엔지니어가 늘어서가 아니다. AI가 엔지니어 한 명이 읽을 수 있는 속도보다 더 많은 코드를 주당 생성하기 때문이다." 코드 출력 속도는 올라가는데, 이해 처리량은 사실상 올라가지 않는다. 그 갭을 채우는 건 기술 부채다. 지저분한 코드가 아니라, 아무도 그 존재에 책임지지 않는 '주인 없는 코드'.
이게 AI-First 팀 운영에서 실질적으로 위험한 지점이다. 모델 성능이 좋아질수록 에이전트가 더 자율적으로, 더 넓은 범위의 코드를 건드린다. GPT-5.5는 "별도의 지시 없이도 문제를 미리 잡아내고 앞으로 어떤 테스트가 필요할지 내다본다"는 평가를 받는다. 그런데 그 결과물을 검토하는 인간 팀원의 맥락 파악 속도는 모델 출시 주기와 무관하게 선형적이다. 한 엔지니어에게 12개짜리 diff 묶음을 돌아와서 발견했다는 사례가 미담처럼 소개되지만, 팀 차원에서 보면 그건 미담이 아니다. 아무도 그 12개 diff의 의도를 즉시 설명할 수 없는 상황이다.
Claude Code 성능 저하 사태는 이 리스크의 다른 단면을 보여준다. 시스템 프롬프트 변경 같은 제품 레벨의 수정이 몇 주간 감지되지 않은 채 팀의 생산성에 영향을 미쳤다. 팀이 AI 도구의 출력을 신뢰하기 시작하면, 역설적으로 그 신뢰 자체가 감지 능력을 낮춘다. 도구가 잘 작동할 때 팀은 결과물을 덜 검토한다. 도구가 조용히 나빠질 때 팀은 그걸 늦게 알아챈다. Anthropic이 재발 방지책으로 "실제 사용자 환경과 동일한 공개 빌드를 내부에서도 더 많이 사용"하겠다고 밝힌 건, 그들 스스로도 이 감지 구조의 약점을 인정한 셈이다.
지금 AI-First 팀에 실질적으로 필요한 건 두 가지다. 첫째, 도구 성능의 기준선을 팀 차원에서 주기적으로 측정하는 루틴. 모델 업데이트 이후 벤치마크가 아니라, 우리 팀의 실제 작업 유형으로 측정한 내부 기준선이 있어야 한다. Claude Code 사태를 Reddit이 먼저 탐지했다는 건, 공식 채널보다 커뮤니티의 집단 경험이 더 빠른 신호였다는 뜻이다. 팀 내에도 이런 신호 수집 구조가 필요하다.
둘째, AI가 생성한 코드에 대한 '이해 가능성'을 검증 기준으로 명시적으로 포함해야 한다. 코드가 동작하는가와 코드를 팀원이 설명할 수 있는가는 다른 질문이다. dev.to 글의 저자가 SourceBridge.ai를 만든 이유도 여기에 있다. 에이전트가 매 대화를 제로 베이스에서 시작하고, 그 이해가 세션과 함께 사라지는 구조에서 팀의 집단 지식은 축적되지 않는다. 이 문제를 '좋은 AI 도구가 나오면 해결되겠지'로 미루는 팀은 기술 부채를 AI 속도로 쌓고 있다는 걸 잊지 말아야 한다.
모델은 계속 빨라질 것이다. GPT-5.5 이후에도, 그 다음에도. 그 속도를 팀이 따라가는 방법은 더 빠르게 읽는 게 아니다. 읽지 않아도 되는 구조를 설계하거나, 읽어야 할 것과 신뢰해도 되는 것을 명확히 구분하는 기준을 만드는 것이다. 지금 이 시점에서 팀이 가장 먼저 물어야 할 질문은 "어떤 모델을 쓸까"가 아니다. "AI가 생성한 코드를, 우리 팀은 지금 어떻게 검증하고 있는가"다.