Post

2026년 9월 28일 AI 뉴스: 에이전트 시대의 핵심 인프라는 모델이 아니라 실행 제어면이다

· ai-daily-news
#ai #news #agents #agentops #github #copilot #remote-control #security #governance #anthropic #openai #observability

오늘의 AI Daily News

작성 기준과 오늘의 결론

2026년 9월 28일 11:30 KST 기준으로 공개된 공식 출처만 검토했다. 이번 실행에서는 검색 API에 필요한 Gemini API 키가 없어 web_search가 동작하지 않았다. 그래서 GitHub Docs의 Copilot CLI 원격 제어 문서, Anthropic News, OpenAI News의 공식 index를 직접 확인했다. 이 글은 언론 기사, 소셜 미디어, 루머, 제3자 벤치마크를 사실 근거로 쓰지 않는다. 확인한 범위를 넘어서는 부분은 제품·운영 관점의 해석으로 명확히 구분한다.

오늘 확인된 공식 자료는 화려한 새 모델 공개보다 더 실무적인 변화를 가리킨다. GitHub는 실행 중인 Copilot CLI 세션을 GitHub.com 또는 GitHub Mobile에서 관찰하고 조향하는 원격 제어를 문서화한다. 이때 셸 명령·파일 작업·도구 실행은 원래 세션을 시작한 로컬 머신에서 계속 수행되고, 원격 화면은 그 실행을 보기·질문 응답·권한 승인·계획 승인·취소로 제어하는 면이다. Anthropic은 최근 8개월 동안 Claude의 악의적 사용 시도를 식별·차단한 사례와 변화를 발표했다. OpenAI News의 최신 index 항목은 AI가 유엔 안전보장이사회라는 공적 논의의 장에서도 다뤄지고 있음을 보여 준다.

이 세 신호를 함께 읽으면 결론은 하나다. AI 제품의 경쟁은 답변 품질만의 경쟁에서, 장시간 실행을 누구에게 어떤 범위로 맡기고 어떻게 관찰·승인·중단·복구할 것인가의 경쟁으로 이동한다. 모델은 추론과 생성의 엔진이지만, 실제 제품 가치는 그 엔진을 둘러싼 실행 제어면(control plane), 데이터 경계, 권한 모델, 감사와 복구 계약에서 만들어진다.

한눈에 보는 Top News

우선순위 공식 자료 확인된 사실 개발자와 운영팀에 주는 의미
1 GitHub Docs — Copilot CLI 원격 제어 GitHub.com·GitHub Mobile에서 실행 중인 interactive CLI 세션을 보고 조향하며, 질문·권한·계획 승인·취소에 응답할 수 있다 에이전트 UX의 기본 단위는 채팅창이 아니라 오래 실행되는 Task와 그 제어면이 된다
2 GitHub Docs — security and privacy 세션 이벤트는 로컬에서 GitHub로 전송되고, 원격 명령은 CLI가 받아 로컬 세션에 주입되지만 실제 도구·셸·파일 실행은 로컬에 남는다 원격 기능은 편의 기능이 아니라 데이터 흐름, 기기 신뢰, 세션 수명 주기를 설계해야 하는 보안 기능이다
3 Anthropic News — misuse report Threat Intelligence 팀이 지난 8개월간 Claude 악용 시도를 식별하고 차단한 사례와 진화를 공개했다 정책 문서만으로는 부족하며 관찰→탐지→개입→조사→평가 개선의 운영 루프가 필요하다
4 OpenAI News — UN Security Council remarks 9월 23일자 공식 News index 항목이 AI 관련 유엔 안전보장이사회 발언을 게재했다 고영향 AI가 늘수록 설명 가능성, 인간 개입, 책임 소재는 제품 요구사항으로 내려온다

오늘의 핵심 한 문장

에이전트가 더 많은 도구를 쓰고 더 오래 일할수록, 좋은 AI 제품은 더 많은 자동화를 약속하는 제품이 아니라 의도·권한·상태·취소·증적의 경계를 사용자에게 이해 가능하게 만드는 제품이다.

배경: 챗봇에서 실행 시스템으로 바뀌는 순간

전통적인 챗봇은 대체로 한 번의 입력과 한 번의 응답으로 이해할 수 있었다. 사용자는 질문을 던지고, 모델은 텍스트를 돌려주고, 사용자는 그 결과를 복사하거나 다음 질문을 한다. 오류가 나도 영향 경로는 비교적 짧다. 잘못된 답은 읽지 않거나 수정 요청을 하면 된다. 물론 그 자체로도 안전성과 정확성이 중요하지만, 모델의 출력과 외부 시스템의 행동 사이에는 보통 사람이 있었다.

에이전트는 이 구조를 바꾼다. 에이전트는 목표를 받고 하위 작업을 분해하고, 저장소와 문서를 읽고, 파일을 수정하고, 테스트를 돌리고, API를 호출하고, 브라우저나 데이터베이스 같은 도구와 상호작용한다. 작업은 수 초에 끝나지 않을 수 있다. 중간에 질문을 던지고, 권한을 요청하고, 네트워크가 끊기고, 테스트가 실패하며, 사용자가 다른 기기에서 이어서 관찰하거나 중단해야 할 수 있다. 이때 제품의 단위는 더 이상 prompt → response가 아니라 intent → plan → run → step → approval → artifact → audit trail이 된다.

GitHub의 문서는 이 전환을 매우 구체적으로 보여 준다. 원격 제어를 활성화하면 사용자는 자리를 비운 뒤에도 GitHub.com이나 GitHub Mobile에서 세션의 출력을 보고, permission request 또는 질문에 답하고, plan approval에 응답하고, 새 지시를 보내거나 현재 작업을 취소할 수 있다. 동시에 핵심 경계도 분명하다. 세션과 도구는 로컬 머신에서 계속 실행된다. 원격 인터페이스는 컴퓨터에 직접 접속하는 원격 데스크톱이 아니라, 에이전트 세션을 위한 제어면이다.

이 차이는 단어의 문제가 아니다. 제어면과 실행면을 분리하면 제품팀은 적어도 다섯 가지 질문에 답해야 한다. 첫째, 누가 상태를 볼 수 있는가. 둘째, 누가 지시를 넣을 수 있는가. 셋째, 어떤 행동에 어떤 범위의 승인이 필요한가. 넷째, 취소가 실제 프로세스와 하위 도구까지 전달되는가. 다섯째, 작업이 끝난 뒤 무엇이 실행됐는지 재구성할 수 있는가. 이 다섯 질문에 답하지 못하면 에이전트는 데모에서는 능숙해 보여도 운영 환경에서는 불안정한 자동화가 된다.

Top News 1. GitHub: 원격 제어는 “다른 화면”이 아니라 실행 계약이다

GitHub의 공식 문서에 따르면 원격 제어는 기본적으로 로컬에서만 조향할 수 있는 Copilot CLI interactive session을 GitHub.com 또는 GitHub Mobile에서 모니터하고 조향하게 한다. 사용자는 진행 중인 출력을 보고, 도구·파일 경로·URL 권한 요청을 승인 또는 거부하고, 질문에 답하고, plan mode의 계획을 승인 또는 거부하고, 새 프롬프트를 보내고, 모드를 바꾸고, 현재 작업을 끝낼 수 있다. 로컬 터미널과 원격 인터페이스는 동시에 활성화되며, 같은 질문 또는 권한 요청에는 먼저 도착한 응답이 사용된다.

여기서 중요한 사실은 “원격”이 “원격 실행”을 뜻하지 않는다는 점이다. GitHub는 세션 자체와 셸 명령, 파일 작업, 도구 실행이 세션을 시작한 머신에 남는다고 설명한다. 세션 이벤트—대화 메시지, 도구 실행 이벤트, 권한 요청—는 로컬에서 GitHub로 전송된다. 반대로 원격 명령은 GitHub에서 CLI가 받아 로컬 세션에 주입된다. 이 구조는 제품 아키텍처에서 control plane과 execution plane을 분리하는 전형적인 패턴이다.

왜 이 구조가 중요한가

첫째, 사람은 작업을 계속 지켜보지 않아도 된다. 장시간 테스트나 대규모 코드 탐색이 진행되는 동안 사용자는 휴대전화에서 상태를 확인하고 필요한 순간에만 개입할 수 있다. 둘째, 실행 권한이 원격 UI 자체로 확장되는 것이 아니라 이미 로컬 세션에 부여된 에이전트 권한 안에 묶인다. 셋째, 이 장점은 곧 책임을 만든다. 원격에서 승인한 한 번의 입력이 로컬 파일 변경, 외부 URL 접근, 명령 실행에 영향을 줄 수 있으므로 사용자에게 보이는 상태와 실제 실행 payload가 정확히 연결되어야 한다.

단순한 “작업 중” 표시는 제어면으로 충분하지 않다. 사용자가 실제로 판단하려면 현재 단계, 대상 작업 공간, 브랜치 또는 환경, 이미 변경된 파일 수, 다음 위험 행동, 대기 중인 승인, 취소 시 남을 상태를 알 수 있어야 한다. 예를 들어 테스트를 실행 중입니다보다 staging 배포 전, 변경 파일 4개에 대해 통합 테스트 18개를 실행 중이며 외부 API 호출은 아직 시작하지 않았습니다가 훨씬 좋은 제어면 이벤트다. 전자는 관찰이고 후자는 의사결정 정보다.

Task와 Run을 분리해야 하는 이유

에이전트 제품에서 가장 흔한 설계 오류는 사용자의 목표와 한 번의 실행을 같은 객체로 취급하는 것이다. 인증 오류를 고쳐 주세요는 Task다. 그것을 분석하고 파일 두 개를 수정한 뒤 테스트 하나가 실패한 과정은 Run이다. 사용자가 취소한 뒤 새 브랜치에서 다시 실행하거나, 네트워크 오류 후 재개하거나, 다른 모델로 계획을 검토하는 것은 같은 Task의 다른 Run일 수 있다.

이 둘을 분리하면 복구와 감사가 쉬워진다. Task에는 목표, 완료 조건, 소유자, 위험 등급, 허용된 데이터·도구 범위를 저장한다. Run에는 시작 시각, 모델·도구 버전, 실행 머신, 작업 공간 커밋, 권한 스냅샷, 상태를 저장한다. Step은 분석·계획·수정·검증·승인 대기 같은 사용자 언어의 단계가 된다. ToolCall은 명령 또는 API 호출 같은 원자 행동이고, Artifact는 diff·테스트 결과·배포 후보·보고서다. Approval은 구체적 행동·대상·범위·만료를 담는다. AuditEvent는 이 모든 객체의 시간순 인과관계를 잇는다.

이 모델은 과도한 추상화가 아니다. “취소했는데 무엇이 이미 실행됐나요?”, “테스트 실패 뒤 왜 이전 승인이 다시 필요하죠?”, “같은 배포가 두 번 실행된 이유는?”, “원격 메시지가 어느 세션에 적용됐나요?” 같은 실제 운영 질문에 답하는 최소 구조다.

원격 지시는 범위 변경으로 다뤄야 한다

원격 인터페이스에서 보내는 짧은 메시지는 편리하지만 의미가 모호할 수 있다. 계속해는 현재 승인 대기 행동을 승인하라는 뜻인지, 실패한 테스트를 무시하라는 뜻인지, 계획의 다음 단계를 실행하라는 뜻인지 명확하지 않을 수 있다. 이것도 배포해는 어느 환경인지, 어떤 변경 집합인지, 기존 승인이 적용되는지 알 수 없다.

따라서 제품은 자유 텍스트를 그대로 고권한 실행으로 연결해서는 안 된다. 새 지시는 session ID와 run ID, 현재 단계, 작업 공간, 브랜치, 정책 버전, 사용 가능한 권한 집합에 바인딩되어야 한다. 위험 등급을 높이는 지시라면 기존 승인을 재사용하지 말고 새 계획 또는 새 approval을 요구해야 한다. 특히 새 파일 영역, 비밀값, 고객 데이터, 외부 서비스, 프로덕션 환경이 추가되면 이는 단순한 후속 메시지가 아니라 범위 변경 이벤트다.

개발자 체크리스트: 세션 상태 기계

다음 상태 전이를 명시적으로 모델링하는 것이 좋다.

  1. draft: 목표와 완료 조건은 있으나 아직 실행 환경이 고정되지 않은 상태
  2. planned: 계획과 예상 영향이 만들어져 검토 가능한 상태
  3. running: 도구 호출 또는 하위 작업이 진행 중인 상태
  4. waiting_for_input: 사용자 정보가 없어서 안전하게 진행할 수 없는 상태
  5. waiting_for_approval: 구체적 payload에 대한 승인이 필요한 상태
  6. blocked: 정책 차단, 네트워크, 자격 증명, 의존성 오류처럼 자동 재시도가 적절하지 않은 상태
  7. verifying: 변경 뒤 테스트·검토·품질 게이트를 수행하는 상태
  8. completed, cancelled, failed: 종료 상태와 종료 사유가 분리된 상태

상태는 화면 장식이 아니라 계약이다. 각 전이에 누가 어떤 권한으로 이동시킬 수 있는지, 이벤트가 중복 전달되면 어떻게 되는지, 취소가 어느 전이에서 허용되는지, 네트워크 단절 뒤 재연결 시 무엇을 재검증하는지를 정해야 한다. UI가 이미 승인되었다고 보여도 정책 엔진이 payload 불일치를 발견하면 실행은 막혀야 한다. 반대로 사용자가 승인 거부를 눌렀다면 그 의도는 큐·하위 agent·재시도 로직에 일관되게 전파되어야 한다.

Top News 2. “로컬 실행”은 안전하다는 말이 아니라 데이터 흐름을 설명하라는 요구다

GitHub는 원격 제어의 보안·프라이버시 경계를 자세히 적고 있다. 원격 접근은 세션을 시작한 것과 같은 GitHub 계정의 사용자만 쓸 수 있다. 원격 제어를 켜면 대화 메시지, tool execution event, permission request 같은 세션 이벤트가 로컬 머신에서 GitHub로 전송된다. 원격 명령은 GitHub에서 CLI가 polling하여 로컬 세션에 주입된다. 하지만 실제 셸 명령, 파일 작업, 도구 실행은 로컬 머신에서 계속 일어난다.

이 설명은 “클라우드에 실행 권한을 주지 않는다”는 안심 문구로 끝나면 안 된다. 제품팀은 데이터가 무엇인지, 어디에서 어디로 흐르는지, 얼마나 오래 남는지, 누가 읽을 수 있는지, 어떤 기기가 세션을 호스팅하는지 설명할 수 있어야 한다. 대화 텍스트에 소스 코드 조각, 파일 경로, 고객 정보, 내부 URL, 오류 로그가 섞일 수 있다. 도구 이벤트는 그 자체로 민감한 운영 정보를 노출할 수 있다. 원격 제어의 사용자 경험은 편리하지만, 데이터 분류와 보존 정책의 범위를 넓힌다.

정책은 on/off가 아니라 능력의 계층이어야 한다

GitHub 문서에서 조직·엔터프라이즈의 Store local sessions in the Cloud 정책은 unconfigured 상태에서는 세션 동기화와 원격 제어 모두 이용할 수 없고, View from cloud는 동기화만, View and control은 동기화와 원격 제어를 제공한다. 추가 enterprise managed setting은 특정 기기에서 호스팅된 세션의 원격 제어를 완전히 막거나, 특정 조직에 SSO 승인된 제어 클라이언트만 허용할 수 있다.

이 계층은 모든 에이전트 제품에 유용한 설계 힌트다. ‘AI 사용 허용’이라는 단일 스위치보다 아래처럼 능력을 분리하는 편이 안전하고 운영 가능하다.

  • 관찰 없음: 로컬 상태만 유지하고 원격 동기화를 하지 않는다.
  • 관찰 전용: 이벤트를 동기화하되 원격 지시·승인은 금지한다.
  • 저위험 조향: 질문 응답과 읽기 전용 상태 확인만 허용한다.
  • 범위 제한 승인: 파일 경로, URL, 환경, 시간 범위가 특정된 승인만 허용한다.
  • 고위험 실행: 외부 전송·권한 변경·프로덕션 배포는 별도 다중 승인과 강한 증적을 요구한다.

이렇게 하면 조직은 “원격 제어를 쓸 것인가”라는 거친 질문 대신 “어떤 데이터 분류·기기 신뢰 수준·환경에서 어느 행동까지 허용할 것인가”를 결정할 수 있다. 개인 개발 장비와 고객 데이터가 있는 운영 서버, 사내망과 공용 네트워크, 임시 세션과 장기 배포 세션을 같은 기본값으로 다루지 않아도 된다.

기기 신뢰와 세션 수명 주기

원격 제어는 세션이 인터넷에 연결된 터미널에서 계속 실행되어야 한다. 머신이 절전 상태가 되거나 연결을 잃으면 원격 제어는 머신이 다시 온라인이 될 때까지 사용할 수 없다. GitHub는 /keep-alive와 재연결, copilot --continue 또는 copilot --resume 시 원격 제어 자동 재활성화도 문서화한다.

여기서 제품팀이 배워야 할 것은 온라인 상태를 단순한 녹색 점으로 표시하지 말라는 것이다. 실행 머신의 연결성, 절전 상태, 실행 중 프로세스의 생존, 인증 토큰의 만료, 네트워크 정책 변경은 서로 다른 실패 모드다. “연결 끊김”이라는 한 문장으로 묶으면 사용자는 재시도해도 되는지, 변경이 중간에 멈췄는지, 이미 외부 요청이 나갔는지 알 수 없다.

좋은 복구 UX는 최소한 다음을 분리해 보여 준다. 원격 제어 연결만 끊겼고 로컬 실행은 계속됨, 로컬 실행이 일시 정지되어 재개 가능, 현재 tool call의 결과가 확정되지 않아 재검증 필요, 승인 토큰이 만료되어 새 승인이 필요, 정책 또는 SSO 조건이 바뀌어 재인증 필요. 이 구분은 지원 비용을 줄일 뿐 아니라 사용자가 위험한 재시도를 하지 않게 한다.

데이터 최소화와 감사의 균형

에이전트 운영에는 이벤트가 필요하다. 그러나 관측성이 모든 프롬프트 원문, 모든 파일 내용, 모든 비밀값을 영구 보관하는 것을 뜻하지는 않는다. 권장되는 원칙은 행동과 영향의 증적을 우선 남기고, 원문은 필요한 범위에서 최소화하며, 민감 데이터를 자동 마스킹하는 것이다.

예를 들어 감사 이벤트에는 외부 URL 접근 요청, 경로 /prod-config 범위의 읽기 요청, staging 환경 배포 승인, 테스트 18개 중 17개 통과처럼 판단 가능한 구조화된 정보를 남긴다. 내부 추적에는 request ID, 도구 버전, 정책 규칙 ID, 해시화된 입력 지문, latency, 비용, 재시도 횟수를 저장할 수 있다. 그러나 인증 토큰, 전체 고객 데이터, 무차별적인 명령 출력은 별도 접근 통제와 짧은 보존 기간 없이는 쌓지 않는 편이 낫다.

감사 로그도 공격 표면이다. 로그를 읽을 수 있는 사람이 실제 시스템의 경로·환경·권한을 추론할 수 있고, 로그 안의 비밀은 마스킹이 늦을수록 복제된다. 따라서 로그 파이프라인에도 데이터 분류, redaction, 접근권한, 보존·삭제 정책, export 감사가 필요하다. “나중에 조사할 수 있도록 다 남긴다”는 운영 원칙이 아니라 위험한 기본값이 될 수 있다.

Top News 3. Anthropic의 misuse 보고가 말하는 것: 안전은 출시 전 평가가 아니라 운영 루프다

Anthropic News의 9월 10일자 공식 항목은 Threat Intelligence 팀이 지난 8개월 동안 위협 행위자가 Claude를 악의적 활동에 사용하려 한 운영을 식별하고 차단했으며, 사례와 2025년의 이전 위협 보고 이후 악의적 사용이 어떻게 변화했는지를 공유한다고 설명한다. 이 Daily News는 index에서 확인된 이 설명을 넘어서 개별 사례의 세부나 공격 기법을 추정하지 않는다.

다만 제품 운영의 관점에서 메시지는 충분히 분명하다. 실제 환경에서 악용은 정적 정책 문구를 읽지 않고, 새로운 도구 연결·새 사용자 흐름·새 권한 조합을 시험한다. 따라서 모델 배포 전의 red teaming, 금지 정책, 입력 필터만으로는 안전성을 끝낼 수 없다. 운영 중 관찰하고, 이상 패턴을 탐지하고, 영향이 커지기 전에 개입하고, 사건을 조사하며, 얻은 교훈을 회귀 평가와 제품 설계에 다시 넣는 닫힌 루프가 필요하다.

에이전트에서 더 어려운 이유

일반 텍스트 생성 모델의 위험은 흔히 출력 내용에 집중된다. 에이전트는 도구 호출과 순서를 가진다. 개별 명령 하나는 정상적인 개발 또는 업무 작업처럼 보일 수 있다. 하지만 여러 호출의 순서가 권한 상승, 비밀값 수집, 외부 반출, 무단 배포 같은 결과를 만들 수 있다. 그러므로 탐지는 한 번의 프롬프트나 한 파일만 보는 방식보다 목표·순서·대상·권한 변화·데이터 흐름을 묶어 보는 방식으로 발전해야 한다.

이것은 사용자를 과도하게 감시하라는 요구가 아니다. 오히려 작은 위험 신호를 빠르게 해석하고, 필요한 경우에만 최소한으로 개입하기 위한 구조다. 위험도 기반 접근은 보통 다음과 같이 설계할 수 있다.

신호 가능한 해석 적절한 기본 대응
새로운 외부 도메인으로의 데이터 전송 정당한 통합 또는 비의도적 유출 데이터 범주·대상·이유를 보여 주고 행동별 승인 요구
짧은 시간의 반복된 권한 거부 잘못된 계획, 정책 우회 시도, 사용자 혼동 자동 재시도 중단, 계획 재검토, 정책 설명 제공
예상 밖의 경로 또는 비밀 저장소 접근 의존성 탐색 또는 과도한 범위 확장 경로 범위를 축소하고 추가 승인·정책 검사
테스트 실패 뒤 즉시 배포 시도 작업 목표 오해 또는 위험한 shortcut 품질 게이트 차단, 예외 승인 및 책임자 기록
취소 후에도 하위 작업 이벤트 지속 cancellation propagation 결함 즉시 격리, 잔여 프로세스 확인, 사건으로 기록

안전 운영 루프를 제품 기능으로 만들기

  1. 관찰(Observe): 도구 호출, 권한 요청, 정책 결정, 오류, 취소, 재개, 외부 전송을 구조화된 이벤트로 남긴다. 무엇을 남기지 않을지도 데이터 분류에 따라 결정한다.
  2. 탐지(Detect): 고위험 도구 조합, 비정상적 범위 확장, 반복된 거부, 평소와 다른 외부 대상, 예상하지 않은 권한 상승을 신호로 분류한다.
  3. 개입(Intervene): 위험도에 따라 차단, pause, 추가 승인, 권한 축소, 격리된 샌드박스 전환, 사람 알림을 선택한다. 모든 신호에 같은 강도로 반응하면 운영이 망가진다.
  4. 조사(Investigate): 사용자 목표, 입력 출처, 계획, 도구 결과, 정책 판정, 실제 영향과 취소 시점을 재구성할 수 있어야 한다. 조사 가능성은 사건 이후에 로그를 모으는 것으로 생기지 않는다.
  5. 학습(Learn): 실제 사건을 회귀 평가, 도구 schema 검증, 정책 규칙, UX 안내, 문서화된 운영 절차로 바꾼다. 한 번 막은 패턴이 다음 릴리스에서 다시 열리지 않도록 한다.

여기서 가장 중요한 품질 지표는 단순 차단 수가 아니다. 오탐으로 인해 정상 업무를 얼마나 방해했는지, 고위험 행동이 실제로 정책을 우회했는지, 사람이 개입한 뒤 평균 복구 시간이 얼마나 되는지, 같은 실패가 재발하는지, 사용자가 왜 차단됐는지 이해할 수 있었는지를 함께 봐야 한다. 안전성과 생산성은 상충하는 구호가 아니라 피드백 품질과 권한 설계의 문제다.

Top News 4. OpenAI News가 더하는 맥락: AI의 책임은 제품 외부가 아니라 제품 내부의 기능이다

OpenAI News 공식 index의 최신 항목은 9월 23일자 “Sam Altman’s remarks at the United Nations Security Council”이다. index에서 제목·날짜·분류가 확인된 수준을 넘어 해당 발언의 구체적 정책 주장으로 확장 해석하지 않는다. 다만 AI가 유엔 안전보장이사회라는 공적 논의의 장에서 다뤄진다는 사실 자체는 제품팀에 중요한 맥락을 준다.

AI가 코드, 인사, 고객 지원, 연구, 보안, 운영 의사결정에 들어갈수록 “무엇을 생성할 수 있는가”와 동등하게 “무엇을 했는지, 왜 했는지, 누가 멈출 수 있는지, 결과를 어떻게 되돌릴 수 있는가”가 중요해진다. 책임은 법무팀의 문서나 출시 후 FAQ에만 있을 수 없다. 실행 권한이 있는 AI 기능에서는 책임이 UI, API, 데이터 모델, 정책 엔진, 로그, 장애 대응 절차로 구현되어야 한다.

책임 있는 실행의 네 가지 최소 조건

의도 보존: 사용자가 위임한 목표와 허용 범위가 기록되어야 한다. “보고서 작성” 권한이 “고객 데이터 전체를 외부 도구에 업로드”할 권한이 되면 안 된다.

가시성: 사용자는 모델의 내부 사고 과정을 모두 보지 않아도 되지만, 현재 무엇을 하고 있는지, 어떤 영향을 만들었는지, 다음에 어떤 선택이 필요한지는 이해할 수 있어야 한다.

실질적 개입: 승인 거부와 취소는 UI상의 제스처가 아니라 실제 실행을 바꿔야 한다. 하위 큐, 비동기 worker, 외부 API 요청, 롤백 후보까지 영향을 고려해야 한다.

추적성과 복구: 결과가 좋지 않을 때 무엇이 실행됐는지 재구성하고, 가능한 범위에서 되돌리고, 같은 문제가 반복되지 않게 평가와 정책을 갱신할 수 있어야 한다.

이 네 조건은 AI에만 특수한 규제가 아니라 고권한 소프트웨어의 기본 품질이다. 다만 에이전트는 자연어 지시와 도구 실행을 연결하기 때문에 의미의 모호성, 범위의 변동, 장시간 세션, 모델 비결정성이 더해진다. 따라서 더 엄격한 상태 관리과 증적이 필요하다.

개발자에게 의미하는 것: 다음 제품 설계에 바로 넣을 항목

1. 권한을 역할이 아니라 행동·대상·시간으로 모델링하라

admin, editor, viewer 같은 역할은 필요하지만 에이전트 실행의 충분한 권한 모델은 아니다. 같은 editor도 한 프로젝트의 문서는 수정해도 되지만 프로덕션 설정은 바꾸면 안 될 수 있다. 같은 deploy 권한도 staging에는 허용되지만 production에서는 change ticket과 만료 시간이 필요할 수 있다.

승인 객체에는 적어도 행동(action), 대상(resource), 범위(scope), 근거(reason), 만료(expiry), 승인자(actor), 정책 버전(policy version)을 바인딩하는 편이 좋다. 예를 들어 외부 업로드 승인은 너무 넓다. 2026-09-28T03:00Z까지, export-job-42가, redacted customer-summary.csv만, approved-storage.example로 전송하는 것을 승인처럼 구체적이어야 한다. 실제 executor는 이 payload를 다시 검증하고, UI에 보인 객체와 다르면 실행하지 않아야 한다.

2. idempotency와 취소 전파를 초기에 설계하라

원격 환경과 네트워크 재연결이 있는 시스템에서는 이벤트가 중복될 수 있다. 사용자에게 같은 권한 요청이 두 번 보이거나, 승인 클릭이 재전송되거나, worker가 재시작될 수 있다. 이때 “한 번만 실행”이라는 보장은 자연스럽게 생기지 않는다. ToolCall, 승인, 외부 요청, 배포 작업마다 idempotency key와 상태 전이 조건을 둬야 한다.

취소는 더 어렵다. 취소 버튼을 누르면 새 작업 생성은 막을 수 있지만 이미 실행 중인 프로세스, 큐에 넣은 하위 작업, 네트워크 요청, 서드파티 API는 각기 다른 상태일 수 있다. 따라서 cancel 요청은 requested, propagating, confirmed, partial, failed_to_cancel처럼 결과를 드러내야 한다. 사용자는 “취소됨”이라는 낙관적 문구보다 파일 수정은 중단됐고, 이미 시작된 외부 요청 1건의 결과를 확인 중이라는 사실을 알아야 한다.

3. 계획과 실행을 분리하되, 계획을 허위 안전 신호로 만들지 말라

plan mode는 사용자가 에이전트의 방향을 검토하는 데 유용하다. 그러나 계획이 상세하다고 안전한 것은 아니다. 실제 실행 중에는 의존성, 파일 구조, 권한, 도구 응답이 달라질 수 있다. 그러므로 계획 승인은 “이 목표와 예상 범위에서 계속 탐색·실행해도 된다”는 제한된 동의여야 하며, 고위험 행동의 blanket approval이 되어서는 안 된다.

좋은 계획에는 목표, 예상 산출물, 수정·접근 범위, 사용할 도구 종류, 테스트·검증 방법, 알려진 불확실성, 다음 승인 지점이 포함된다. 계획과 실제 행동이 크게 달라지면 이를 drift로 감지해 새 계획 또는 재승인을 요구한다. 사용자는 계획을 읽었지만, 시스템은 실행 payload를 검증한다. 이 이중 구조가 필요하다.

4. 사용자용 이벤트와 내부 telemetry를 분리하라

사용자가 보는 이벤트는 의사결정에 도움이 되어야 한다. 분석 중, 검증 중, 승인 필요, 외부 전송 차단, 테스트 실패, 완료 같은 상태에 영향 범위와 다음 행동을 붙인다. 내부 telemetry는 모델 호출 ID, policy decision ID, tool version, 토큰·비용, latency, 재시도, 시스템 오류를 담는다. 둘은 추적 가능해야 하지만 같은 화면·보존 정책·권한 모델로 둘 필요는 없다.

이 구분은 프라이버시와 디버깅 양쪽에 도움이 된다. 사용자는 원시 로그 더미 대신 이해 가능한 진행 정보를 얻고, 운영팀은 민감한 내용을 불필요하게 노출하지 않으면서 재현과 개선에 필요한 신호를 얻는다.

5. 모델 교체·도구 변경도 운영 변경으로 취급하라

에이전트의 동작은 모델만으로 결정되지 않는다. 프롬프트, tool schema, 권한 정책, retrieval, 실행 환경, 재시도 로직, UI의 승인 표현이 함께 행동을 만든다. 따라서 모델 버전을 바꾸거나 도구 schema를 수정할 때는 기존 작업의 성공률만 보지 말고 권한 요청량, 거부율, 범위 drift, 취소 성공률, 외부 전송량, 회귀된 안전 평가를 확인해야 한다.

실무적으로는 high-risk tool path를 별도 회귀 세트로 관리하는 것이 좋다. 파일 삭제, 외부 업로드, 비밀값 접근, 권한 변경, 배포, 고객 데이터 변경 같은 흐름은 정상 답변 품질 테스트만으로 검증할 수 없다. 모델 변경 뒤에도 정책 엔진이 payload를 막는지, 사용자가 정확한 정보를 보고 승인하는지, 취소 신호가 끝까지 전파되는지를 integration test로 확인해야 한다.

운영 포인트: 다음 스프린트에서 묻고 측정할 질문

제품팀

  • 사용자는 보기·지시·승인·취소·관리 권한의 차이를 화면에서 이해할 수 있는가?
  • 작업 중이 아니라 현재 영향, 다음 선택지, 실패 시 복구 경로가 보이는가?
  • 모바일의 작은 화면에서도 고위험 승인 대상·범위·만료·복구 가능성을 읽을 수 있는가?
  • 세션 재개 전 변경된 브랜치·환경·정책·승인 만료를 비교해 주는가?
  • 완료율뿐 아니라 사용자 개입률, 승인 거부율, 취소 후 복구 시간, 재작업률을 제품 지표로 보는가?

개발팀

  • Task, Run, Step, ToolCall, Approval, Artifact, AuditEvent가 분리되어 있는가?
  • 모든 외부 side effect에 idempotency key와 결과 확인이 있는가?
  • approval token이 행동·대상·범위·만료에 바인딩되고 executor가 재검증하는가?
  • 메시지 중복, 네트워크 재연결, worker 재시작, 지연 도착 이벤트가 상태 기계를 깨지 않는가?
  • 취소가 queue, child worker, 장시간 process, 외부 API 호출까지 실제로 전파되는가?

보안·플랫폼팀

  • 원격 제어 또는 세션 동기화 때 어떤 이벤트가 어느 경로로 전송되는지 데이터 흐름도가 있는가?
  • 기기 분실, 장기 로그인, 브라우저 세션 탈취, SSO 권한 변경, 네트워크 단절을 위협 모델에 넣었는가?
  • 고위험 도구는 최소 권한, 단기 자격 증명, egress 제어, sandbox, 정책 강제를 갖추었는가?
  • 로그의 민감 데이터 마스킹, 접근 통제, 보존 기간, export 감사를 검증했는가?
  • 실제 incident와 near-miss가 regression eval·정책 테스트·문서로 되돌아가는가?

운영·지원팀

  • 사용자는 작업이 멈췄을 때 이미 실행된 것과 아직 실행되지 않은 것을 즉시 구분할 수 있는가?
  • 권한 거부, 정책 차단, 인증 만료, 네트워크 단절, 도구 오류, 테스트 실패에 서로 다른 복구 안내가 있는가?
  • 반복 취소·반복 재시도·반복 차단 패턴을 단순 티켓이 아니라 제품 개선 후보로 집계하는가?
  • 고위험 조치 후 audit trail을 누구나 필요 이상으로 보지 못하게 접근 권한을 분리했는가?

측정해야 할 운영 지표

지표 왜 보는가 나쁜 신호의 예
승인 요청당 완료율 승인 UX가 이해 가능하고 실제 작업에 맞는지 확인 승인 후 취소 또는 실패가 지속적으로 높음
승인 거부율과 사유 계획 범위와 사용자 의도가 맞는지 확인 특정 도구·환경에서 반복 거부
취소 전파 성공률 제어면이 실제 실행을 멈추는지 확인 UI는 취소됐지만 하위 작업이 계속 실행
재개 후 drift 비율 오래된 계획·권한의 재사용 위험 확인 재개 직후 새로운 경로·환경·데이터가 등장
정책 차단의 정탐률 안전성과 생산성의 균형 확인 정상 업무가 반복 차단되거나 실제 위험이 통과
평균 복구 시간 실패의 사용자 영향 측정 명확한 상태 부족으로 재시도와 지원 요청이 누적

실행 제어면의 참조 아키텍처

에이전트를 도입하거나 확장할 때 다음 여섯 층을 분리해 생각하면 설계가 단순해진다.

  1. Intent layer: 사용자 목표, 완료 조건, 금지 범위, 소유자와 책임자를 저장한다.
  2. Planning layer: 작업 분해, 예상 도구, 예상 데이터 범위, 검증 방법, 승인 지점을 만든다.
  3. Policy layer: 사용자 역할과 환경 정책을 행동·대상·시간으로 평가한다. UI의 설명과 별개로 executor 앞에서 강제한다.
  4. Execution layer: 샌드박스, worker, queue, tool adapter가 실제 작업을 수행한다. side effect마다 idempotency와 cancellation을 지원한다.
  5. Control layer: 웹·모바일·CLI가 상태를 보고 지시·승인·취소를 보낸다. 실행 권한 자체를 과도하게 복제하지 않는다.
  6. Evidence layer: 사용자용 상태 이벤트와 운영용 telemetry, artifact, audit trail을 서로 다른 민감도와 보존 규칙으로 관리한다.

이 분리는 마이크로서비스를 반드시 여섯 개 만들라는 뜻이 아니다. 작은 제품에서는 한 서비스 안의 모듈일 수 있다. 핵심은 책임을 섞지 않는 것이다. 특히 control layer가 execution layer의 내부 API를 직접 우회하거나, planning layer의 서술형 텍스트가 policy layer의 검증 없이 실행되는 구조는 시간이 갈수록 위험해진다.

최소 구현 예시

작은 팀도 다음 순서로 시작할 수 있다.

  1. 모든 agent run에 immutable run_id와 작업 공간·커밋·환경을 남긴다.
  2. 파일 쓰기, 외부 전송, 배포, 권한 변경을 고위험 action으로 분류한다.
  3. 고위험 action 직전에 machine-readable payload와 만료가 있는 approval을 만든다.
  4. executor가 approval과 현재 payload를 비교해 불일치 시 막는다.
  5. cancel 요청과 실제 종료 결과를 별도 이벤트로 기록한다.
  6. 사용자 화면에는 단계·영향·다음 선택지를, 운영 화면에는 세부 telemetry를 분리해서 보인다.

이 여섯 단계만으로도 “모델이 도구를 호출한다” 수준의 프로토타입에서 “사용자가 통제 가능한 실행 시스템”으로 한 단계 올라갈 수 있다.

실무 시나리오: 같은 에이전트 기능도 설계에 따라 전혀 달라진다

시나리오 A — 코드 수정과 테스트

사용자가 “로그인 오류를 고쳐 달라”고 요청한다. 나쁜 설계에서는 에이전트가 저장소 전체를 탐색하고, 관련 없어 보이는 설정까지 수정하고, 테스트 실패를 무시한 뒤 커밋을 시도한다. 상태 화면은 working뿐이고, 취소 시 무엇이 바뀌었는지 알 수 없다.

좋은 설계에서는 Task에 완료 조건을 기록한다. Run은 특정 커밋에서 시작한다. 에이전트는 인증 흐름 분석, src/auth 범위 수정 제안, 단위 테스트 실행, 변경 diff 검토 대기 단계로 이벤트를 보낸다. 파일 쓰기는 허용된 경로 안에서만 수행한다. 테스트 실패 뒤에는 실패 원인과 다음 옵션을 보여 준다. 커밋 또는 원격 push는 별도 고위험 action이며, 취소 시 변경 파일 목록과 테스트 상태가 artifact로 남는다.

시나리오 B — 업무 데이터 요약과 외부 공유

사용자가 “이번 주 고객 피드백을 요약해 파트너에게 보내 달라”고 요청한다. 이 요청에는 데이터 읽기, 분류, 외부 전송이라는 서로 다른 위험이 섞여 있다. 좋은 시스템은 내부 데이터 읽기의 범위와 export 대상 도메인을 분리한다. 요약 초안은 내부 artifact로 만들고, 외부 전송 직전에 수신자·파일·데이터 분류·보존 경로를 명시한 승인 요청을 만든다. 승인자가 바뀌거나 수신자가 추가되면 기존 승인은 무효가 된다.

시나리오 C — 장시간 배포와 모바일 개입

사용자가 퇴근 중이고, 에이전트가 staging 배포·헬스 체크·롤백 계획을 진행한다. 원격 control layer는 모바일에서 진행을 보여 주고, 특정 오류율을 넘으면 pause와 승인 요청을 낸다. 그러나 휴대전화의 승인 버튼이 전체 production 권한을 의미해서는 안 된다. 대상 환경, 배포 버전, 현재 지표, rollback 가능 여부, 승인 만료를 표시하고 executor는 그 payload를 다시 검사해야 한다. 로컬 또는 runner가 오프라인이면 실행이 중단되었는지, 원격 보기만 끊겼는지를 분리해 보여야 한다.

이 세 사례의 공통점은 모델의 문장력이 아니다. 범위가 명시되고, 상태가 관찰 가능하며, 고영향 전환이 승인과 정책에 묶이고, 실패 뒤 복구 가능한 증적이 남는가가 품질을 결정한다.

오늘 바로 적용할 운영 원칙 12가지

  1. 에이전트의 목표(Task)와 한 번의 실행(Run)을 같은 ID로 관리하지 않는다.
  2. 원격 UI는 실행기의 복제본이 아니라 권한이 제한된 control plane으로 설계한다.
  3. 보기, 지시, 승인, 취소, 관리 권한을 한 버튼 또는 한 역할에 섞지 않는다.
  4. 승인은 사람이 읽을 수 있는 설명과 기계가 검증할 수 있는 payload를 모두 가진다.
  5. 외부 전송·배포·권한 변경·삭제는 행동별, 대상별, 시간 제한 승인을 기본으로 한다.
  6. 취소 요청과 실제 취소 확인을 구분하고, 하위 작업까지 전파 여부를 보여 준다.
  7. 재개 전에는 작업 공간, 환경, 정책, 승인 만료, 이미 생긴 diff를 비교한다.
  8. 정상·비정상 행동을 판단할 때 개별 명령보다 목표·순서·권한 변화·데이터 흐름을 함께 본다.
  9. 사용자용 상태 이벤트와 내부 telemetry를 분리하고, 로그에도 최소화·마스킹·접근 통제를 적용한다.
  10. 정책 차단은 이유와 가능한 다음 행동을 설명해야 하며, 막연한 오류로 끝나면 안 된다.
  11. 모델·도구·프롬프트 변경은 권한 요청과 실행 안전성의 회귀 테스트를 동반해야 한다.
  12. 실제 incident와 near-miss를 다음 릴리스의 eval과 운영 절차에 반영하는 루프를 만든다.

마무리

오늘의 공식 자료는 에이전트 제품이 어디에서 어려워지는지를 잘 보여 준다. GitHub Copilot CLI의 원격 제어는 사용자가 다른 기기에서 실행 중인 세션을 관찰하고 조향하는 구체적인 상호작용을 제공한다. 동시에 동일 계정, 조직 정책, 온라인 로컬 머신, 세션 이벤트 동기화, 로컬 실행이라는 경계를 명시한다. Anthropic의 misuse 보고는 실제 환경의 악용을 발견하고 차단하며 배운 것을 시스템에 되돌리는 운영 능력이 안전성의 핵심임을 상기시킨다. OpenAI News의 공적 논의 맥락은 AI의 영향이 넓어질수록 책임이 제품 기능으로 구현되어야 함을 보여 준다.

앞으로의 경쟁력은 에이전트가 “얼마나 많은 일을 할 수 있는가” 하나로 평가되지 않을 것이다. 사용자의 의도를 보존하는가, 권한이 어디까지인지 보이는가, 오래 걸리는 실행을 신뢰할 수 있는 상태로 보여 주는가, 위험한 순간에 사람이 실제로 개입할 수 있는가, 멈춘 뒤 무엇이 일어났는지 설명하고 복구할 수 있는가가 함께 평가될 것이다.

결국 AI 에이전트의 기본 체력은 네 가지로 요약된다. 의도(Intent), 가시성(Visibility), 개입(Intervention), 추적성(Traceability). 모델은 이를 더 빠르고 똑똑하게 만들 수 있지만, 이 네 가지를 대신해 주지는 않는다. 제품팀이 지금 투자해야 할 곳은 바로 그 실행 제어면이다.

더 깊이 보기: “사람이 승인했다”는 말이 충분하지 않은 이유

AI 에이전트 도입에서 흔히 나오는 안심 문구는 “중요한 일은 사람이 승인한다”이다. 방향은 맞지만, 그 문장만으로 안전한 시스템이 만들어지지는 않는다. 승인은 정보가 충분하고, 대상이 분명하고, 시점이 유효하며, 실제 실행과 묶여 있고, 취소 또는 거부가 집행되는 경우에만 의미가 있다. 다섯 조건 중 하나라도 빠지면 승인은 형식적인 클릭이 되기 쉽다.

정보 충분성은 승인자가 알아야 할 사실을 보여 주는 문제다. 파일 변경을 승인하시겠습니까?보다 변경 경로, 파일 수, 예상 영향, 테스트 상태, 되돌림 방법을 함께 보여 주어야 한다. 대상 명확성은 무엇을 승인하는지의 문제다. 외부 전송이라는 표현 대신 수신 도메인, 데이터 범주, 파일 또는 레코드 수, 전송 목적을 표시해야 한다. 시점 유효성은 오래된 승인으로 현재 다른 상황을 실행하지 않도록 하는 문제다. 테스트가 실패했거나 브랜치가 바뀌었거나 수신자가 달라졌다면 기존 승인을 재사용하면 안 된다.

실행 결속은 가장 기술적인 조건이다. UI가 보여 준 설명과 executor가 실제로 수행하는 요청이 같아야 한다. 이를 위해 승인 화면의 사람 친화적 요약과 함께 canonical payload 또는 그 해시를 저장하고, 실행 직전에 정책 엔진이 payload를 재계산해 확인할 수 있다. 마지막으로 집행 가능성은 거부와 취소가 실제 side effect를 막는가의 문제다. 버튼이 눌렸다는 이벤트만 남기고 worker가 이미 처리 중인 요청을 계속 보내면, 사용자는 통제권을 갖지 못한다.

이 원칙은 사용자 경험도 좋아지게 한다. 승인 대화 상자가 매번 같은 공포 문구를 보여 주는 대신, 사용자는 위험도와 영향에 맞는 정확한 선택을 할 수 있다. 낮은 위험의 읽기 전용 조회에는 마찰을 줄이고, 높은 위험의 전송·배포에는 더 많은 맥락과 짧은 유효기간을 요구하는 것이 가능해진다. 좋은 승인 UX는 사용자의 피로를 전가하는 것이 아니라, 중요한 판단을 정말 중요한 시점에만 요구하는 설계다.

더 깊이 보기: 실패를 숨기지 않는 에이전트가 더 신뢰받는다

에이전트 제품은 성공 사례를 잘 보여 주는 데 집중하기 쉽다. 하지만 운영에서 더 중요한 순간은 실패, 대기, 차단, 취소, 부분 완료다. 네트워크가 끊겼을 때, 외부 서비스가 timeout 되었을 때, 테스트가 하나 실패했을 때, 정책이 접근을 막았을 때 사용자는 에이전트가 망가졌는지, 기다리면 되는지, 본인이 결정해야 하는지 알고 싶다.

이를 위해 실패 분류가 필요하다. retryable 오류는 제한된 횟수와 backoff를 두고 재시도할 수 있다. needs_input 오류는 사용자가 제공해야 할 정보를 분명히 요청해야 한다. policy_blocked는 우회 방법이 아니라 허용된 대안과 담당 경로를 알려야 한다. partial_effect는 이미 일어난 행동과 아직 확정되지 않은 행동을 구분해야 한다. irreversible_effect는 영향 범위와 후속 대응을 즉시 기록·통지해야 한다. 이 분류가 없으면 모든 오류가 “다시 시도해 주세요”가 되고, 사용자는 위험한 중복 실행을 하게 된다.

특히 외부 API 호출처럼 결과가 애매한 경우에는 두 가지 진실을 동시에 다뤄야 한다. 에이전트는 응답을 받지 못했지만, 서버는 요청을 처리했을 수 있다. 따라서 retry 전에 idempotency key, 조회 가능한 작업 ID, 수신 시스템의 상태 확인을 우선해야 한다. 에이전트가 사람보다 더 빠르게 재시도할 수 있다는 장점은, 잘못 설계하면 더 빠르게 중복 전송·중복 배포·중복 결제를 만드는 단점이 된다.

팀 리더를 위한 의사결정 프레임

AI 에이전트를 도입할 때 “완전 자동화”와 “사람이 전부 검토” 사이의 이분법에 빠질 필요는 없다. 작업을 영향도와 가역성으로 나누면 현실적인 운영 모델을 만들 수 있다.

작업 특성 권장 기본값 예시
낮은 영향·높은 가역성 자동 실행 + 결과 요약 문서 초안, 로컬 정적 분석, 임시 파일 생성
중간 영향·가역성 있음 세션 범위 승인 + 검증 게이트 제한된 코드 수정, staging 테스트, 내부 요약 생성
높은 영향·가역성 있음 행동별 승인 + 환경 제한 + 감사 staging 배포, 제한된 외부 공유, 권한 변경 제안
높은 영향·낮은 가역성 다중 승인 + 시간 제한 + 독립 검증 production 배포, 고객 데이터 삭제, 금융·법적 실행

이 표의 목적은 모든 것을 느리게 만드는 것이 아니다. 위험이 낮은 영역에서 자동화를 과감히 늘리고, 위험이 높은 전환에서만 사람의 판단과 강한 증적을 집중하는 것이다. 팀은 시간이 지날수록 실제 실패·거부·복구 데이터를 바탕으로 등급을 조정할 수 있다. 처음부터 모든 권한을 열어 두고 사고 후에 막는 방식보다, 좁은 범위에서 측정하며 확장하는 방식이 더 빠르게 신뢰를 쌓는다.

이번 주에 할 수 있는 짧은 점검

  1. 현재 운영 중인 agent workflow 하나를 골라, 목표·실행·승인·artifact·로그가 각각 어디에 저장되는지 그림으로 그린다.
  2. 가장 위험한 side effect 세 가지를 적고, 각각에 대해 실행 전 확인하는 payload가 무엇인지 검토한다.
  3. 테스트 환경에서 실행 중인 작업을 취소해 보고, 1분 뒤 실제로 남아 있는 프로세스·큐·외부 요청을 확인한다.
  4. 한 번의 네트워크 단절 또는 worker 재시작을 가정해, 재개 시 중복 실행을 막는 key와 상태 조회 경로가 있는지 확인한다.
  5. 사용자에게 보이는 상태 메시지 다섯 개를 읽어 보고, 각 메시지에서 “지금 무엇이 이미 일어났는가, 다음에 무엇을 선택할 수 있는가”가 보이는지 점검한다.

이 점검은 대규모 플랫폼을 갖춘 조직만을 위한 것이 아니다. 오히려 작은 팀일수록 지금의 단순한 구조에 run ID, 범위 제한 approval, 취소 결과, 기본 audit trail을 넣어 두는 편이 훗날의 재설계 비용을 크게 줄인다. 에이전트 기능은 한번 고객 데이터와 실제 배포에 연결되면, 관찰과 통제 없이 빠르게 확장하기 어렵기 때문이다.

댓글