2026년 6월 2일부터 6월 4일에 공개된 영어 1차 정보를 추적해 보면, AI의 주전장은 "어떤 모델이 강한가"가 아니게 되었습니다.

초점은 AI를 지탱하는 시스템을 어떻게 설계하고, 어떤 문맥(Context)을 전달하며, 어디서 멈추고, 어떻게 감사(Audit)하며, 어떤 기준으로 외부 파트너나 거버넌스(Governance)를 재검토할지로 옮겨가고 있습니다.

Microsoft는 "AI alone won’t change your business. The system running it will."라고 명시했습니다. 여기서 중요한 것은 AI 그 자체보다 주변에 있는 권한, 문맥(Context), 감사(Audit), 개선 루프(Improvement loop)가 성과를 결정한다는 점입니다.

원문: "the system around the AI" (Microsoft Blog)

한국어 번역: 「AI 주변에 있는 시스템」。

같은 흐름으로 Microsoft 365의 Work IQ APIs는 에이전트(Agent)에게 전달해야 할 입력을 raw data가 아닌 업무 문맥(Business context)으로 다루어야 함을 보여주었습니다.

원문: "work with business context, not just raw data" (Microsoft 365 Blog)

한국어 번역: 「생데이터가 아니라, 업무 문맥으로 동작한다」。

실무에서 해야 할 일은 간단합니다.

Context

은 "전부 전달하기"가 아니라 "사용 가능한 형태로 정돈하기"

State

는 대화 메모리(Conversation memory)와 분리하고, 정본(Source of truth)을 DB / CRM / 티켓(Ticket)에 두기

Tools

는 읽기(Read)와 실행(Execute)을 나누고, 파괴적인 조작(Destructive operation)을 직접 연결하지 않기

Output

는 초안(Draft), 제안(Proposal), 실행(Execution)의 3단계로 나누기

Microsoft Foundry의 기사는 운영의 실패가 어디서 발생하는지를 상당히 솔직하게 기술하고 있습니다.

원문: "written policies do not translate into working runtime controls" (Microsoft Foundry Blog)

한국어 번역: 「작성된 방침은 그대로 동작하는 실행 시 제어(Runtime controls)로 이어지지 않는다".

이 한 문장이 그대로 설계 지침입니다. 프롬프트(Prompt)에 주의 사항을 추가하는 것만으로는 불충분하며, 평가와 제어를 동일한 라이프사이클(Lifecycle)에 포함시켜야 합니다.

agent_runtime_contract:
context:
allow:
...

체크포인트는 적더라도 다음 4가지입니다.

• 입력 시점에서 거부하기
• 툴(Tool) 실행 시점에 멈추기
• 출력 시점에서 재검사하기
• 실패 시 되돌리기(Rollback)

Anthropic은 Claude Partner Network의 Services Track과 Partner Hub를 공개하여 도입 지원의 신뢰성을 가시화했습니다.

원문: "a successful pilot is not the same as a system a business can run on" (Anthropic)

한국어 번역: 「성공한 파일럿은 사업으로서 운용할 수 있는 시스템과는 별개다".

여기서 배울 수 있는 점은 AI 도입이 "모델이 동작했다"로 끝나지 않는다는 것입니다. 실운용에서는 누가 구축하고, 누가 평가하며, 누가 유지보수하고, 어떤 실적으로 선택할지까지 포함하여 설계해야 합니다.

• 파트너 선정은 "영업력"이 아니라 "실제 운영 도입 실적"으로 판단한다
• 증명 자료는 certification / production deployment / public reference로 세분화한다
• 도입 후의 리뷰 주기를 처음부터 결정한다

Anthropic의 보안 분석은 AI가 공격의 초기 단계뿐만 아니라 더 깊은 공정에 진입하고 있음을 보여주었습니다.

원문: "the type of scaffolding attackers build around the model" (Anthropic)

한국어 번역: 「공격자가 모델 주변에 구축하는 발판(Scaffolding)의 종류".

실무상의 포인트는 단발적인 부정 출력(Improper output)이 아니라, 다단계 연쇄(Multi-step chain)를 탐지하는 것입니다. 즉, 모니터링 대상은 "1회의 프롬프트"가 아니라 "연속된 의사결정"입니다.

attack_chain_monitoring
1. reconnaissance
2. privilege escalation
...

• 단발적인 위험어 탐지만으로는 부족하다
• 도구 호출 (Tool calling) 순서와 밀도를 모니터링한다
• 인간 승인 (Human approval)은 '중요 조작'뿐만 아니라 '연쇄의 끊김 지점'에도 넣는다

OpenAI의 blueprint는 프런티어 AI (Frontier AI)의 제도 설계가 '현재의 기술'에 고정되지 않도록 하는 중요성을 보여줍니다.

원문: "durable federal framework capable of evolving alongside the technology itself" (OpenAI)

한국어 번역: 「기술 그 자체의 진화에 맞춰 변화할 수 있는 지속적인 제도적 프레임워크 (framework)".

이는 기업 내 거버넌스 (Governance)에도 그대로 적용됩니다. 정책 (Policy)은 작성하는 것으로 끝나는 것이 아니라, 모델 업데이트, 도구 추가, 권한 변경이 일어날 때마다 재검토되어야 합니다.

policy를 문서가 아닌 버전 관리 대상으로 만든다 -
review cadence를 분기별이 아닌 변경 이벤트 기준으로도 실행한다 -
incident review를 재발 방지까지 포함하여 남긴다

첫 실전 투입 시 최소한 이 부분들을 고정해 두면, 나중에 체계가 무너지는 것을 방지할 수 있습니다.

• Context의 공급원을 허용 목록 (allowlist)화 했다
• Secrets / PII / full thread dump를 차단했다
• 파괴적인 조작은 require_human_approval로 설정했다
• eval을 prompt injection / stale context / tool misuse / data exfiltration으로 실행했다
• trace_id와 approval_id를 저장했다
• rollback_path를 구현했다
• 파트너 선정 기준을 deployment evidence로 정의했다
• policy version의 업데이트 절차를 정했다

지난 일주일간의 영어 AI 뉴스는 동일한 메시지를 반복하고 있었습니다.

• AI는 단독으로는 가치가 되기 어렵다. 주변 시스템이 가치를 결정한다.
• 문맥 (Context)은 raw data가 아니라, 업무에서 사용할 수 있는 계약 형태로 변환해야 한다.
• 정책 (Policy)은 런타임 제어 (runtime controls)와 평가 (eval)로 구현되어야 비로소 실전에서 효과를 발휘한다.
• 도입 지원 파트너 선정도 AI 운영의 일부로서 설계해야 한다.
• 공격 측과 거버넌스의 진화 속도에 맞춰 규칙을 지속적으로 업데이트해야 한다.

모델 비교부터 시작하기보다, context / policy / control / trace / review를 먼저 고정하는 것이 결과적으로 더 빠르고 안전합니다.

• Microsoft Blog
• Microsoft 365 Blog
• Microsoft Foundry Blog
• Anthropic: Services Track and Partner Hub
• Anthropic: AI-enabled cyber threats
• OpenAI: A blueprint for democratic governance of frontier AI