2026년 6월 11일, 도쿄 Fairmont Tokyo에서 Anthropic이 주최하는 개발자 이벤트 「Code with Claude Tokyo 2026」이 개최되었습니다.

세션, 핸즈온(Hands-on), 데모 부스, Anthropic 팀과의 1on1 오피스 아워(Office Hours) 등 풍성한 내용으로 구성되었으나, 이 기사에서는 기술적으로 특히 인상 깊었던 내용을 정리해 나가겠습니다.

오늘의 결론을 먼저 3줄로 요약하자면 다음과 같습니다:

업무는 「코드를 작성하는 것」에서 「AI가 잘 작동할 수 있는 조건을 정비하는 것」으로 이동했다
에이전트는 "만드는" 단계에서 "운영하는" 단계로. 실행 기반·기억·평가·보안 부품이 갖춰졌다
AI 에이전트 투자에 앞서, 업무 컨텍스트와 데이터 기반의 정비가 성패를 가른다

Anthropic의 엔지니어, Jason Schwartz 씨의 강연입니다. 더치페이 앱 개발을 소재로, Claude Code를 더욱 효과적으로 사용하는 3가지 테크닉을 소개해주었습니다.

프롬프트(Prompt)의 차이가 첫 1시간을 크게 좌우합니다.

AskUserQuestion

도구를 사용하여 에이전트 스스로 사양의 모호함을 인터뷰하게 하는 것이 효과적입니다.

"HTML 계획이 읽기 더 쉽고 — 모델의 사고 과정을 더 많이 포착한다"

Markdown은 불렛 포인트(Bullet point)로 작성되기 쉬워 우선순위·플로우(Flow)·구조가 잘 보이지 않을 수 있습니다. HTML로 출력하게 하면 인간의 리뷰 정밀도가 높아집니다.

「리뷰하지 않는 계획은 계획이 아니다」 라는 말이 인상적이었습니다.

• Build for it from the start (만들면서 검증을 생각한다)
• Modularize by verifiability (독립적으로 검증 가능한 단위로 코드를 나눈다)
• Verify across the stack (unit / integration / visual / behavioral)

데모에서는 14건의 테스트가 모두 통과했음에도 불구하고 UI가 깨져 있는 충격적인 상황을 보여주었습니다. 테스트는 「누군가가 작성한 범위」만을 보호합니다. 에이전트는 테스트가 통과(Green)된 것을 믿고 그대로 배포해 버립니다.

해결책: 검증 컨트랙트 (Verification Contract)

• 컴포넌트가 상태를 DOM에 각인 (data-verify-* 속성) → 렌더링 결과가 기계 판독 가능해짐
• Claude에게 verify spec (fixtures + invariants)을 작성하게 함
• 하네스(Harness)가 매번 동일한 방법으로 규칙을 자동 체크

"업무는 더 이상 코드를 작성하는 것이 아니다. 업무는 코드가 잘 작성될 수 있는 조건을 설정하는 것이다."

「실제 투입을 10~15배 빠르게 한다」는 슬로건을 내건 신규 서비스입니다. 태스크(Task)·도구(Tool)·가드레일(Guardrail)을 정의하면 나머지는 Anthropic이 운영해 줍니다.

/v1/agents → 인격과 능력. 모델·시스템 프롬프트·도구. 버전 관리되며 불변.
/v1/environments → 실행 환경. 컨테이너 설정·네트워크 제한. 한 번 만들면 재사용.
/v1/sessions → Agent × Environment로 대화를 시작. 이벤트를 스트림(Stream)으로 수신, 언제든 재개.

기존에는 「두뇌(루프)」와 「손(도구 실행)」이 동일한 컨테이너에 공존했습니다. Managed Agents는 이를 분리하고 있습니다.

이전: 세션마다 1개의 컨테이너
[Agent loop + 도구 실행 (동거)]
→ 크래시(Crash) 발생 시 전부 삭제됨. 스케일링(Scale)도 비효율적.
...

세션은 이벤트 드리븐(Event-driven) 방식으로, user.message를 보내면 agent.message나 agent.tool_use가 SSE 스트림(SSE stream)으로 반환됩니다. 상태 머신(State machine)으로 관리되며, 대화는 클라우드에 영속화(Persistence)됩니다.

"새벽 2시, 결제의 p99 레이턴시(Latency)가 10배로 급증했다"라는 시나리오에서, agent.py의 7개 함수를 순서대로 구현하는 것만으로 장애 조사 에이전트가 완성되었습니다. 완성 후에는 "레이턴시 급증의 원인은?"이라는 질문에 대해, 클라우드 샌드박스(Cloud sandbox)에서 7만 행의 로그를 grep하고, 메트릭(Metrics)과 배포(Deploy) 내역을 대조하여 문제의 커밋(Commit)을 특정해 주었습니다.

세션은 일회성(기억 상실)을 전제로 했으나, 기억의 "유지"와 "정리"가 독립된 부품으로 등장했습니다.

Memory (기억):

• Store: 파일 시스템형 영속 스토어(Persistent store). 세션에 리소스로 마운트(Mount)하면 에이전트가 읽고 쓰며 기억을 가질 수 있습니다. 두 세션에 동일한 스토어를 마운트하면 기억을 공유할 수 있습니다. 무엇을 기억할지는 프롬프트(Prompt)란에서 제어합니다.
• Dreaming (드림): 과거의 대화 이력과 스토어를 읽고, 증류(Distillation)한 기억을 새로운 스토어에 쓰는 비동기 배치(Asynchronous batch) 처리입니다. 인간이 수면 중에 기억을 정리하는 것과 같은 발상입니다.

운영 플로우:

• 스토어를 생성하여 에이전트에 장착
• 주 단위로 Dreaming 실행
• 출력 스토어를 다음 세션으로 교체

Console에서 "에이전트가 무엇을 기억했는지"를 인간이 확인 및 비교할 수 있다는 점도 거버넌스(Governance) 측면에서 중요합니다.

Vault: API 키 및 OAuth 토큰은 Vault에 보관되며, 컨테이너 내부에는 들어가지 않습니다. 통신이 외부로 나가는 순간 Anthropic의 프록시(Proxy)가 주입하는 설계이므로, 에이전트 스스로도 키를 읽을 수 없습니다 = 프롬프트 인젝션(Prompt injection)으로 유출되지 않습니다.

샌드박스 실행: 도구는 세션마다 격리된 컨테이너에서 실행됩니다. Agent loop와도 분리되어 있어, 코드 실행의 영향 범위가 제한됩니다.

데모 부스의 "하드 게이트(Hard gate)": 자율 에이전트가 "스크린샷을 실제로 읽기 전까지는 테스트를 통과할 수 없다"라는 제약 조건 하에서 수 시간 동안 자율 주행하고 있었습니다. 에이전트의 자기 보고를 신뢰하지 않고, 검증을 기계적으로 강제하는 설계는 리스크 관리(Risk management)의 사고방식과 일치합니다.

야생 패키지(Wild package) 주의: 서드파티(Third-party) 패키지는 공급망 공격(Supply chain attack)의 입구입니다. 설치 전에 스캔하는 SDK/도구 도입을 권장한다는 오피스 아워(Office hour)에서의 조언도 인상적이었습니다.

Tsukumo Labs의 강연과, 30일간 878개 세션 동안 코드 0줄로 진행된 Claude Code 활용 사례 강연에서 공통적으로 도출된 결론입니다.

대기업 AI 프로젝트의 실패율은 80~95%입니다 (MIT·RAND 조사).

실패의 핵심은 업무 컨텍스트(Context)의 결여입니다.

"AI 에이전트에 투자하기 전에, 데이터 기반(Data foundation)에 투자하라"

특히 인상적이었던 말은 "병목은 사고 시간이 아니라, 재료를 모으는 시간이었다"라는 문구였습니다. BigQuery만으로는 "CV +20%"라는 숫자만 나오지만, Slack과 GA4를 결합하면 "특정 세그먼트에 효과가 있다. 해당 고객은 사전에 콘텐츠 A를 읽었고, Slack에서도 과제 B에 대한 인식이 공유되어 있었다"라는 문맥과 인과 관계를 맺을 수 있습니다.

에이전트가 역량을 발휘하기 위한 3가지 조건:

• 파이프라인(Pipeline) 자동화
• 메타데이터(Metadata) 관리
• 데이터 품질 모니터링

또한, 에이전트 개발의 평가에 대해서도 중요한 시사점이 있었습니다. PoC를 시작할 때는 먼저 평가 데이터와 합격 기준을 만드십시오. "작동했다"가 아니라 "합격했다"를 기준으로 진행해야 합니다.

워크숍 자료는 github.com/anthropics/cwc-workshops에서 모두 공개되어 있습니다. Python 3.10+와 Anthropic의 API 키가 있다면 직접 체험해 볼 수 있습니다.

Managed Agents는 아직 베타(β) 단계이지만, SRE 에이전트와 같은 실무 유스케이스(use case)에는 충분히 사용할 수 있을 것 같다는 인상을 받았습니다. 특히 Vault와 샌드박스 실행(sandbox execution) 설계는 보안을 중시하는 현장에서도 안심하고 도입할 수 있는 기반이라고 느꼈습니다. 다음에는 Managed Agents 핸즈온(hands-on)을 저도 직접 시도해 보고 싶습니다!