🤖 Opus 4.6 + Agent Teams 발표 정리: 개발 환경이 달라지는 신호

안녕하세요, BQ개발자입니다.

어제 Anthropic에서 한꺼번에 세 가지를 쏟아냈습니다.
새 플래그십 모델, 멀티 에이전트 협업 기능, 그리고 AI끼리 협업해서 컴파일러를 만든 실험까지..
모델 업그레이드만이었으면 "오 숫자 올랐네~" 하고 넘어갔을 텐데, 도구까지 같이 나오니까 개발 환경 자체가 흔들리는 느낌이에요.

핵심 내용 세 가지로 나눠서 정리해봤습니다.


1️⃣ Opus 4.6 - 확실히 이전이랑 다릅니다

바로 돌려봤는데요. 이전 모델에서 컨텍스트 흘리면서 헤매던 작업을 이번엔 깔끔하게 처리하더라고요. 체감이 확 와요.

수치로 보면 Terminal-Bench 2.0(에이전틱 코딩)에서 65.4%로 현존 최고점을 찍었고, 실무 지식 평가인 GDPval-AA에서는 GPT-5.2를 144 Elo 차이로 앞섭니다. 컨텍스트 윈도우도 1M 토큰으로 늘었는데(베타), 롱 컨텍스트 벤치에서 76%예요. Sonnet 4.5가 18.5%였으니까.. 차원이 좀 다르죠 ㅋㅋ

근데 저한테 제일 와닿은 건 Adaptive Thinking이에요.
비유하자면 예전에는 수도꼭지가 "틀기/잠그기" 두 가지뿐이었는데, 이제는 수압 조절이 되는 거예요. 가벼운 질문에는 가볍게 답하고, 복잡한 문제에는 알아서 깊이 파고들어요. low/medium/high/max 4단계로 개발자가 직접 조절할 수도 있고요.

에이전트를 멀티턴으로 오래 돌려야 하는 환경에서 이건 비용이랑 속도 측면에서 꽤 유의미한 변화인 것 같아요. 쉬운 작업에 토큰 불필요하게 태우는 문제가 줄어드니까요.


2️⃣ Agent Teams - 드디어 나왔습니다

며칠 전에 누군가 Claude Code 바이너리를 까봤더니 TeammateTool이라는 게 이미 완성된 채로 들어있었거든요. feature flag만 꺼져 있던 상태에서 드디어 스위치가 올라갔습니다.

이전까지 있던 Subagent와 뭐가 다르냐면요.
Subagent는 회사에서 인턴한테 "이거 조사해서 보고서 갖다줘" 시키는 느낌이었어요. 결과물만 돌아오고 끝.
Agent Teams는 회의실에 시니어 개발자 여러 명 모아놓은 구조에 더 가까워요. 서로 의견 주고받고, "그 방식은 이런 리스크가 있지 않나?" 하고 챌린지하고, 할 일 목록에서 각자 가져가서 처리합니다.

환경변수 하나 켜면 바로 쓸 수 있어요:
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

저는 프론트엔드 리팩토링에 투입해봤는데, 한 명은 컴포넌트 구조 개선, 한 명은 타입 정리, 한 명은 테스트 보강 이렇게 나눠서 돌려봤더니 혼자 순차적으로 할 때보다 훨씬 빠르게 끝나더라고요. 서로 메시지 주고받으면서 조율하는 게 신기했습니다 ㅋㅋ

아직 실험 단계라 제약은 있어요. 팀 하나만 운영 가능하고, 동일 파일 동시 수정 시 충돌 나고, 세션 이어하기도 안 됩니다. 토큰 소모량도 꽤 되고요. 근데 나아갈 방향 자체가 강력해요.


3️⃣ C 컴파일러 실험 - Agent Teams의 극한 스트레스 테스트

이건 "이 기능으로 대체 어디까지 되는지" 보여주려고 만든 데모인 것 같아요.
Anthropic 연구원이 Opus 4.6 인스턴스 16개를 풀어놓고 거의 손을 뗐습니다. 2주 동안 약 2,000번의 세션을 거쳐서 Rust로 된 10만 줄짜리 C 컴파일러가 나왔고, API 비용은 약 $20,000이었다고.

결과물이 꽤 인상적인 게, Linux 커널 빌드가 되고, GCC 테스트 99% 통과하고, FFmpeg이나 PostgreSQL 같은 실제 프로젝트도 컴파일됩니다. Doom도 돌아간다고 하네요 ㄷㄷ

작업 구조도 재밌어요.
위에서 지시하는 매니저 에이전트가 없습니다. 각 에이전트가 컨테이너에서 독립적으로 돌면서 "지금 제일 해야 할 것 같은 작업"을 알아서 가져갑니다. 코드는 Git으로 공유하고, 같은 작업 중복 안 하게 락 파일 쓰고, 충돌 나면 에이전트끼리 알아서 정리하고..

비유하자면 프로젝트 매니저 없이 개발자 16명한테 칸반 보드만 주고 "알아서 해봐" 했는데 컴파일러가 나온 거예요.

물론 한계도 솔직하게 나와있어요. 16비트 x86 코드 생성은 끝내 실패해서 GCC한테 넘겼고, 자체 어셈블러/링커도 아직 불안정합니다. 코드 품질도 숙련된 Rust 개발자가 보면 아쉬운 수준이라 하고요. 연구원 본인도 "지금 모델이 할 수 있는 거의 끝자락에 도달했다"고 솔직하게 밝혔어요. 기능 하나 추가하면 다른 게 깨지는 패턴이 반복됐다고..


✏️ 개인적 생각

이번에 OpenAI가 발표 27분 후에 GPT-5.3 Codex로 맞불을 놨습니다. 양쪽 다 노리는 건 같아요. 멀티 에이전트 자율 코딩 환경.

경쟁 축이 바뀌고 있는 것 같아요. "어느 모델이 더 똑똑한가"에서 "어느 플랫폼 위에서 에이전트 팀을 더 잘 굴릴 수 있는가"로요.

개발자 입장에서 보면 이제 프롬프트를 얼마나 잘 쓰느냐보다, 작업을 어떻게 쪼개고 테스트를 어떻게 설계하느냐가 더 중요해지는 것 같습니다. C 컴파일러 실험에서도 핵심은 에이전트 자체가 아니라 "에이전트가 자율적으로 검증하며 일할 수 있게 만든 테스트 인프라"였거든요.

한 명의 AI한테 잘 지시하는 시대에서, AI 팀을 설계하고 관리하는 시대로 넘어가고 있는 느낌이네요.

---

여러분의 좋아요와 공유는 사랑입니다 🥰

#BQ개발자 #ClaudeOpus #AgentTeams #AI #ClaudeCode

🤖 Claude Code가 조용히 말을 안 듣기 시작할 때 — context 70%의 의미

안녕하세요, BQ개발자입니다.

요즘 AI가 정말 핫하죠 ㅎㅎ 오랜만에 AI 얘기를 조금 써보겠습니다.

Claude Code를 쓰다 보면 이상하고, 넘 짜증나는 경험을 하게되는데요,

에러도 안 나고, 작업도 멈추지 않는데,
어느 순간부터 CLAUDE.md에 적어둔 규칙들을 Claude가 점점 안 따르기 시작합니다.

오늘은 이 현상이 왜 생기는지 찾아봤습니다.

✔️ 요약
- context window는 "찼거나 / 안 찼거나" 두가지로 나눌 수 있는 상태가 아님
- 70%부터 이미 지시사항 반영이 줄어들기 시작함
- /compact 타이밍은 비용 문제가 아니라 품질 문제임


1️⃣ 왜 70%가 임계치인가

Transformer는 각 토큰이 다른 모든 토큰에 attention을 분배하는 구조입니다. 이 attention이 균등하게 분배되지 않아요.

context가 짧을 때는 CLAUDE.md의 지시사항이 전체 대비 비중이 높고, 현재 입력과의 연결도 충분합니다. 근데 코드, 파일 내용, 이전 대화가 쌓이면서 context가 70%를 넘으면, 앞부분 지시사항에 할당되는 attention weight가 상대적으로 낮아져요.

"잊어버리는" 게 아닙니다. 기술적으로는 지시사항이 context에 여전히 있거든요. 그냥 현재 입력 대비 상대적 weight가 낮아지는 것뿐이에요. 에러메시지도 없고, 작업이 멈추지도 않아요. 결과물이 조용히 나빠지는 게 전부입니다.


2️⃣ /compact 타이밍이 왜 90%가 아닌 70~80%여야 하는가

90%에서 /compact를 실행하면 이미 attention이 희석된 상태에서 압축이 일어납니다. Claude가 지시사항을 덜 반영한 채로 쌓아온 흐름을 요약하는 거라서, 압축된 요약 자체가 지시사항과 어긋난 방향으로 만들어질 수 있어요.

70~80%에서 실행하면 달라집니다. 지시사항이 아직 충분히 attention을 받는 상태에서 세션이 압축되니까, "내 지시사항을 제대로 이해한 상태의 Claude"가 요약하는 거죠. compact 이후 세션의 품질 기반 자체가 달라지는 겁니다.


3️⃣ /context를 다르게 볼 수 있을 것 같은..?

Claude Code에서 /context 명령어를 쓰면 현재 context 사용량이 표시됩니다. 보통 비용 확인 용도로 쓰는 경우가 많은데요.

이걸 "지금 내 지시사항이 얼마나 반영되고 있는가"를 간접적으로 측정하는 도구로 보는 게 더 정확할 것 같아요. 70%를 넘었다면, Claude가 규칙을 안 따르거나 지시를 무시하는 것 같을 때 코드나 프롬프트를 먼저 의심하기 전에 context 상태를 확인해보는 게 맞습니다.


✏️ 개인적으로 본 방향

context window는 비용 지표보다 품질 지표로 보는 게 더 유용한 것 같습니다.

수치가 70%를 넘는 순간부터 Claude는 여전히 작동하고 있지만, 내가 원하는 Claude가 맞는지는 점점 불확실해집니다.
/compact는 비용을 줄이는 게 아니라 품질 기준점을 리셋하는 거라고 보면 될 것 같아요.

---

다음 편에서는 MCP를 많이 설치할수록 Claude가 오히려 할 수 있는 일이 줄어드는 역설적인 구조를 다뤄볼게요.

여러분의 좋아요와 공유는 사랑입니다 🥰

#BQ개발자 #ClaudeCode #LLM #AIEngineering