Claude Opus 5가 7월 24일 출시됐다. 가격은 그대로, 성능만 올랐다. 입력 $5/1M, 출력 $25/1M—Opus 4.8과 동일한 요금에 더 강해진 추론 능력이 들어왔다. Anthropic이 공개한 세 가지 시연 사례는 모두 같은 메시지를 담고 있다. 검증할 방법이 없으면, 검증할 방법부터 만든다. FreeCAD 도면을 직접 볼 수 없자 컴퓨터 비전 파이프라인을 직접 짜고, 실시간 피드가 없자 자체 테스트 하네스를 구성했다. 모델이 막힌 상황에서 우회로를 스스로 설계한다는 뜻이다.
여기서 테크 리드로서 첫 번째 질문이 나온다. 이 모델에게 얼마나 많은 권한을 줘도 되는가. 능력이 올라갈수록 더 많은 도구 접근을 허용하고 싶은 충동이 생긴다. 그런데 바로 이 시점에 dev.to에서 나온 보안 분석 하나가 그 충동에 찬물을 끼얹는다.
Confused Deputy—에이전트가 조용히 다른 테넌트 데이터를 읽는 방법. 해당 분석이 보여주는 시나리오는 단순하다. 에이전트에게 read_account_rows 도구를 허용한다. 인증 미들웨어는 호출자(caller)가 이 도구를 쓸 수 있는지 확인한다. 토큰은 유효하고, 역할은 허용되어 있고, 게이트는 통과한다. 문제는 그다음이다. account_id—실제로 어느 회사의 데이터를 가져올지 결정하는 인자—를 모델이 직접 작성한다. 미들웨어는 이 인자를 한 번도 들여다보지 않는다. 결과는 충격적이다. 게이트 없이 8번의 호출을 돌리면, 모델이 작성한 셀렉터 5개 중 4개가 다른 테넌트의 행을 반환한다. id_ok 컬럼은 전부 True다. 인증은 한 번도 실패하지 않았다.
이 취약점의 핵심은 값(value)이 아니라 출처(provenance)다. 세션에서 주입된 tenant_id와 모델이 생성한 tenant_id는 같은 값일 수 있지만, 신뢰 수준이 다르다. 모델이 올바른 테넌트를 선택하는 건 권한이 아니라 운(luck)이다. 해결책은 더 정교한 인증 로직이 아니다. 리소스를 선택하는 인자가 세션에서 유래했는지, 모델이 만들어냈는지를 판별하는 Provenance Gate를 실행 전에 두는 것이다. 이 게이트를 추가하자 크로스 테넌트 리드는 5/5 → 0/5로 떨어졌다.
이 구조를 팀에 대입해보면 시사점이 선명해진다. 에이전트에게 DB 읽기 권한을 주는 순간, 기존의 인증 체계는 절반짜리가 된다. 호출 권한은 확인하지만, 리소스 선택 권한은 확인하지 않는다. Opus 5가 더 자율적으로 인자를 구성할수록—검증 방법을 스스로 만들어낼 만큼 능력이 올라갈수록—이 맹점은 더 넓어진다. 모델이 강해질수록 Provenance Gate의 필요성도 커진다.
세 번째 기사는 다른 각도에서 같은 문제를 비춘다. 레거시 운영 개발자가 AI를 처음 공부하며 쓴 글인데, 핵심 깨달음이 하나 있다. "AI는 코드는 잘 만들지만 우리 프로젝트는 모른다." 이 문장이 중요한 이유는, 에이전트가 컨텍스트를 모른 채 작동할 때 어떤 일이 생기는지를 정확히 짚기 때문이다. Spring Boot인지 JPA인지 모르면 엉뚱한 코드를 만든다. tenant_id가 어떻게 결정돼야 하는지 모르면 엉뚱한 데이터를 가져온다. 컨텍스트 공백이 버그의 발원지다.
팀 리빌딩 관점에서 이 세 소스는 하나의 실행 원칙으로 수렴한다. 에이전트 권한 설계는 모델 성능과 독립적으로 가야 한다. Opus 5가 FreeCAD 문제를 풀었다고 해서 그 에이전트에게 프로덕션 DB 셀렉터를 통째로 넘길 이유는 없다. 신규 모델 도입 체크리스트에 반드시 들어가야 할 항목이 있다.
- 리소스 선택 인자 감사: 도구 호출 시 어떤 인자가 모델 생성인지 목록화한다.
- Provenance Gate 삽입: DB에 닿기 전, 모델 생성 셀렉터를 세션 값으로 강제 오버라이드하거나 거부한다.
- 컨텍스트 주입 설계: 에이전트가 어떤 테넌트·프로젝트·환경에서 작동하는지를 모델이 추론하게 두지 말고, 런타임이 주입하게 설계한다.
한 가지 냉정한 관찰을 덧붙인다. Anthropic이 Opus 5에 적용한 보안 접근—모델을 통째로 잠그는 대신 작업 단위로 자르고 막힌 요청은 다른 모델로 라우팅—은 일반 사용자 경험 측면에서 분명히 낫다. 그러나 이것은 Anthropic 레이어의 이야기다. 그 위에서 우리가 구성하는 에이전트 아키텍처는 여전히 우리의 책임이다. 모델이 자동 폴백을 지원하고, MCP 탈착 시 캐시 무효화를 막아주는 것은 편의성 개선이지 보안 설계가 아니다.
앞으로의 방향은 명확하다. 더 강한 모델이 나올수록 에이전트에게 더 많은 작업을 위임하게 된다. 그 위임의 경계를 정하는 기준은 벤치마크 점수가 아니라 신뢰 경계 설계다. 어떤 인자를 모델이 채우게 허용하는가. 어떤 인자는 반드시 세션이 주입해야 하는가. 팀원이 이 판단을 내릴 수 있도록 Provenance 개념을 온보딩 초기에 가르쳐야 한다. Opus 5 시대의 진짜 질문은 "이 모델이 얼마나 잘 하나"가 아니다. "이 모델에게 어디까지 결정하게 할 것인가"다.