어제 한 AI가 Slack으로 들어왔고 떠나지 않았습니다. 사용자가 /invoke(호출)하는 봇 형태가 아닙니다. 채널 내에 상주하는 존재로서 말이죠.

Anthropic은 6월 23일에 Claude Tag를 출시했습니다. 채널당 하나의 Claude가 팀과 공유되며, 앰비언트 모드(ambient mode)에서는 스레드를 모니터링하고, 관련 정보를 표시하며, 중단된 작업을 후속 조치하고, 아무도 프롬프트를 입력하지 않아도 연결된 도구들을 실행할 수 있습니다. 저는 이 발표를 한 번 읽고, 다시 한 번 읽었습니다. 왜냐하면 흥미로운 부분은 기능(capability)이 아니기 때문입니다. 그것은 카테고리의 변화이며, 이 시스템을 연결하는 사람들에게 정면으로 부딪히는 문제입니다.

반응형(Reactive)과 앰비언트(Ambient)는 두 가지 서로 다른 제어 표면(control surfaces)입니다

우리 대부분이 출시해 온 모든 AI 통합은 반응형(reactive)입니다. 사람이 호출하고, 사람이 출력을 읽으며, 사람이 결정합니다. 이러한 요청/응답(request/response) 구조에는 내장된 자유로운 안전 속성(free safety property)이 있습니다. 즉, 모든 상호작용의 양 끝에 사람이 존재한다는 점입니다.

앰비언트(Ambient)는 호출을 제거합니다. 때로는 읽는 과정조차 제거합니다. AI는 사람이 타이핑하는 것이 아니라 채널 내의 이벤트(events)에 의해 트리거됩니다. 만약 여러분이 이벤트 기반 시스템(event-driven systems)을 구축해 본 적이 있다면, 이미 실패 모드(failure modes)를 알고 있을 것입니다. 예상치 못한 시점에 트리거가 작동하고, 아무도 지켜보지 않을 때 부작용(side effect)이 실행되며, 오직 감사 로그(audit log)만이 그것이 일어났다는 유일한 기록이 되는 상황 말입니다.

따라서 앰비언트 AI를 "Slack에서 작동하는 반응형 AI"처럼 취급하는 것은 단순히 정책상의 오류가 아니라 코드상의 카테고리 오류입니다. 제어 표면(control surface)이 다릅니다. 반응형의 경우 호출(invocation)을 제어합니다. 앰비언트의 경우 인지(perception)와 실행(action)이라는 두 가지 별개의 요소를 제어해야 하며, 이 둘은 동일한 게이트가 아닙니다.

개발자가 실제로 구성하게 되는 두 가지 게이트

Claude Tag를 시스템 다이어그램에 매핑했을 때, 거버넌스(governance) 문제는 추상적인 논의를 넘어 엔지니어링 측에서 책임져야 하는 두 가지 구체적인 설정(config) 결정 사항이 되었습니다:

Gate 1 - 인지 범위 (scope of perception). 무엇을 알아차릴 수 있도록 허용할 것인가? 어떤 채널에 속해 있는지, 어떤 스레드를 보는지, 어떤 연결된 도구(tools)를 읽을 수 있는지에 대한 문제입니다. 이는 읽기 권한 범위 (read-scope) 문제이며, 실제로도 그렇게 작동합니다. #incidents 채널을 읽는 주변부 에이전트 (ambient agent)는 #design-crit를 읽는 에이전트와는 다른 폭발 반경 (blast radius)을 가집니다. 에이전트의 인지에 추가하는 모든 채널은 이제 실행 가능한 (actionable) 입력값이 됩니다. 왜냐하면 관찰되지 않은 것은 아무것도 실행될 수 없기 때문입니다.

Gate 2 - 인지-실행 임계값 (perception-to-action threshold). 언제 인지가 실행으로 전환되는가? 이는 사람들이 설정을 과소하게 할 가능성이 높은 게이트입니다. "도움이 된다"라는 말 뒤에는 최소 세 가지의 뚜렷한 모드가 숨어 있습니다:

flag-only      -> 사람에게 알림, 사람이 실행        (읽기 전용, read-only)
follow-up       -> 부작용 없이 넛지/핑을 보냄        (낮은 쓰기 권한, low-write)
autonomous      -> 연결된 도구를 직접 변경함          (쓰기 권한, write)

Claude Tag는 관리자에게 도구 액세스 제어, 지출 한도, 전체 감사 로그 (audit logs)를 제공하며, 이는 Gate 2를 위해 정확히 필요로 하는 툴킷입니다. 하지만 기본 설정값(defaults) 자체가 하나의 결정 사항이며, "활성화 버튼을 누른 사람"은 flag-only가 끝나고 autonomous가 시작되는 지점을 관리하기에 적절한 책임자가 아닙니다.

이것이 PM의 업무 범위 확장(scope-creep)이 아닌 개발자의 문제인 이유

직설적으로 말씀드리겠습니다. 이곳은 Dev.to이고 누군가는 이미 이 글을 쓰고 있을 테니까요. 이것은 여러분의 통합(integration)을 관리하러 나타난 PM의 문제가 아닙니다. 인지 범위와 실행 임계값은 토큰, 읽기 권한 범위, 쓰기 권한, 감사 로그 보존 기간 등 다른 서비스 계정(service account)을 설정하는 것과 동일한 곳에서 설정됩니다. 이는 스스로 작동하는 에이전트에 적용되는, '최소 놀람의 원칙 (least-surprise engineering)'이 적용된 엔지니어링입니다.

진정으로 새로운 부분은 트리거(trigger)가 주변부적 (ambient)이라는 점입니다. 크론 잡 (cron job)은 당신이 작성한 일정에 따라 실행됩니다. 웹훅 (webhook)은 당신이 등록한 이벤트에 따라 발생합니다. 하지만 주변부 에이전트는 스레드가 정체된 것처럼 보이면 후속 조치 (follow-up)가 필요하다고 스스로 판단합니다. 그 판단이 새로운 변수이며, "도움이 되는 넛지"와 "요청되지 않은 운영 도구(prod tooling)에 대한 쓰기" 사이를 가로막는 유일한 차이는 바로 당신이 Gate 2를 어디에 설정하느냐입니다.

따라서 워크스페이스(workspace)에서 앰비언트 모드(ambient mode)가 활성화되기 전에 유용한 것은 정책 문서(policy doc)가 아닙니다. 그것은 설정 검토(config review) 단계에 포함된 한 줄의 문구입니다: "이 에이전트는 X를 인지(notice) 할 수 있으며, Y까지는 행동(act) 할 수 있고, Y를 넘어서면 인간이 루프에 참여(human in the loop)한다." 이 문구를 의도적으로 작성하거나, 그렇지 않다면 기본값(default)으로 설정된 것을 그대로 상속받게 됩니다.

당신은 Y를 어디에 설정하시겠습니까? 플래그(flag)만 설정할 것인지, 후속 조치(follow-up)를 취할 것인지, 아니면 행동하도록 허용할 것인지 말입니다. 그리고 현재 당신의 팀에서 실제로 그 결정을 내리고 있는 사람은 누구입니까?

AI 네이티브 프로젝트 관리(AI-native project management)에 관한 나의 Substack에서 교차 게시되었습니다.