요청 주체와 동작 승인과 데이터 이동을 나누어 통제하는 세 지점

에이전트에게 도구를 사용할 수 있도록 권한을 설정했다는 표현에는 서로 다른 여러 단계의 판정이 혼재되어 있다. 어떤 계정이나 주체의 자격으로 요청을 전달하는지, 시스템 내부에서 파일과 명령을 어디까지 실제로 다뤄도 되는지, 읽어 들인 자료가 분석용 저장소나 다른 외부 위치로 옮겨가도 되는지는 결코 같은 범주의 질문이 아니다.

10월 말에 연이어 공개된 깃허브의 두 가지 변경 사항과 메타의 PrivacyLib 설명은 이러한 차이가 실제 실행 지점마다 어떻게 나뉘는지를 분명하게 드러낸다. 깃허브는 개발자가 다루는 제품 환경의 인증과 승인 단계를 다루고, 메타는 사내 인프라 내부에서 자료 접근 자체를 제어하는 기반 설계를 설명한다.

깃허브는 조직에 설치한 앱이 개별 직원의 로그인 자격 증명에 기대지 않은 채 Copilot SDK 요청을 보낼 수 있는 방식을 공개 프리뷰로 제공했다. 이와 별도로 CLI와 데스크톱 앱, VS Code 환경에서 동작하는 Assisted 권한 방식을 정식 제공으로 전환했다. 메타는 내부 서비스와 에이전트가 데이터에 접근할 때 목적과 도착지를 확인하는 방식을 밝혔다.

조직의 신원으로 실행하고 관리 체계에 사용량을 귀속하는 구조

깃허브의 서버 간 인증 구조에서 개발자는 GitHub App에 조직용 읽기 전용 Copilot Requests 권한을 부여한 뒤 대상 조직에 설치한다. 이후 짧은 수명을 지닌 설치 접근 토큰을 발급받아 Copilot SDK에 전달하는 방식으로 통신을 구성한다. 개별 직원의 계정 세션 대신 조직에 설치된 앱 자체가 요청 주체로 작동한다.

이 방식을 통하면 모든 호출 사용량과 청구 내역이 앱 설치를 소유한 조직에 직접 귀속된다. 해당 조직에 설정된 모델 정책과 예산 및 지출 통제 규칙 역시 그대로 적용된다. 조직 소유자는 앱 접근 권한을 상시 확인하고 인공지능 사용량 CSV 파일에 남는 앱 식별자를 통해 구체적인 소모량을 추적할 수 있다.

조직 차원에서 접근을 즉시 중단해야 할 때에는 해당 앱을 정지하거나 완전히 제거하는 방식을 사용한다. 이 공지가 바꾸는 본질적인 영역은 요청을 실행하는 주체가 누구이며 누구의 관리 범위 아래에 놓이는가이다. 이는 모든 세부 명령이나 시스템 내 모든 자료를 사전에 자동으로 승인한다는 뜻이 아니다.

명령의 안전성을 대형 언어 모델로 판정하고 모드를 제어하는 방식

깃허브의 Assisted 방식은 명령 실행, 파일 시스템 경로 접근, URL 열기 요청을 대형 언어 모델을 통해 실시간으로 평가한다. 모델이 명확히 안전하다고 분류한 요청에 한해서만 중단 없이 진행하며, 그 밖의 모든 요청은 사용자가 직접 승인하도록 넘긴다. 조직의 유효한 토큰을 썼더라도 수행하려는 구체적 행동을 별도로 따져보는 단계다.

기업 관리자는 모든 동작을 사전에 허용하는 모드를 차단하면서 Assisted 모드만 허용할 수 있고, 필요하다면 Assisted 모드만 따로 비활성화할 수도 있다. 새로운 세션이 시작될 때 적용할 기본 모드 역시 정책으로 지정할 수 있지만, 개별 개발자는 조직 정책이 허용하는 범위 안에서 다른 모드를 골라 전환할 수 있다.

조직에서 설정한 기본값을 사용할 수 없거나 금지해 둔 조건에서는 수동 승인 모드로 세션이 시작된다. 이처럼 개별 명령에 대한 모델의 위험도 판정, 기업 관리자가 정의한 보안 정책, 실제 개발자의 세션별 모드 선택이 한데 맞물려 에이전트의 실행 범위를 통제하도록 구성되어 있다.

저장 직전의 한 사례와 더 넓은 데이터 접근 경계

메타 PrivacyLib는 여러 데이터·처리 시스템의 클라이언트 안에서 접근 시점에 실행되는 공통 라이브러리다. 시스템을 한 번 통합한 뒤 목적 제한이나 흐름 관측 같은 요구를 모듈로 추가한다. 공개된 Logger 예제는 메시지 전달 시각 같은 메타데이터를 데이터웨어하우스에 쓰기 직전에 검사하지만, 이를 라이브러리 전체가 저장 직전 쓰기만 다룬다는 설명으로 좁혀서는 안 된다.

모듈의 역할도 다르다. Policy Zones 같은 집행 모듈은 접근을 차단할 수 있고 관찰 모듈은 접근 기록을 수집한다. 에이전트 경로에서는 지원되는 도구 호출에 세션 문맥이 연결되고 하위 서비스로 전달된다. 관찰 기록이 있다는 사실과 차단 정책이 적용됐다는 사실을 구분해야 한다. 목적·도착지 주석과 에이전트 문맥은 해당 집행 경로에서 판정에 쓰인다.

메타가 설명한 보완 장치는 문맥이 풍부한 클라이언트 검사와 하위 RPC 경계의 검사다. 그러나 이 메커니즘의 관리 경계 밖 경로는 별도 통합이 필요하다고 명시돼 있다. 에이전트가 예상하지 못한 도구를 골랐을 때도 검사한다는 설명에는 지원·활성화된 경로라는 조건이 붙는다. 호출 문맥의 전파와 실제 적용 범위를 확인하지 않고 모든 데이터 이동이 자동으로 막힌다고 일반화할 수는 없다.

같은 파일 전송 요청을 세 질문으로 나누면

조직 앱이 분석 결과를 외부 위치로 전송하려는 상황을 가정해 보자. 설치 토큰이 유효하다는 것은 우선 해당 앱을 요청 주체로 인정한다는 뜻이다. 전송 명령이 Assisted에서 허용됐다는 사실은 그 명령의 요청을 해당 모드로 판단했다는 뜻이다. 데이터에 적용된 이용 목적이나 도착지 정책까지 같은 판정으로 끝난 것은 아니다. 표의 상황은 세 체계가 해결하는 질문을 비교하기 위한 가정이며 GitHub와 Meta 제품을 실제로 연결해 시험한 기록은 아니다.

실패 대응도 이 구분을 따르면 달라진다. 인증 거절에는 설치 상태·토큰·조직 정책을, 명령 승인 대기에는 세션 모드와 요청 행위를, 데이터 접근 거절에는 목적 문맥·주석·집행 결과를 대조할 수 있다. 관찰 로그만 있는 경로를 차단까지 검증한 경로로 표시하지 않는 것도 중요하다. 자동화가 성공했다는 단일 상태값보다 판정 위치와 경로별 범위를 남기는 기록이 원인을 좁히는 데 유용하다.

깃허브의 서버 간 인증은 조직에 귀속되는 요청 주체를, Assisted는 구체적인 명령의 승인 여부를 다룬다. PrivacyLib는 통합된 데이터 접근 경계에서 관찰과 집행을 수행한다. 세 기능은 서로 보완할 수 있지만 각각 다른 조건과 적용 범위를 가진다.

정상적인 신원, 승인된 명령, 허용된 데이터 이용이 모두 같은 말은 아니다. 어디서 어떤 판정을 내렸고 어느 경로에는 적용되지 않았는지 남겨야 실패 원인과 남은 공백을 구체적으로 조사할 수 있다.

ARCH.B 의견

통제 지점이 세 곳으로 분리되면 실패가 발생했을 때 책임 소재와 조사 대상을 혼선 없이 추적할 수 있다. 조직 설치 토큰이 거절당했다면 앱 설치 상태와 주체 검증을 살펴야 하고, 명령 실행이 멈췄다면 적용 모드와 모델의 판정 기준을 점검해야 하며, 쓰기가 차단됐다면 목적 문맥과 도착지 주석을 확인해야 한다. 이를 하나의 권한 오류로 뭉뚱그려서는 원인을 바로잡을 수 없다.

에이전트 시스템을 설계할 때 무조건 넓은 권한을 사전에 부여하는 방식보다, 판정의 기준과 결과를 분리해 기록으로 남기는 구조를 채택해야 한다. 깃허브가 앱 식별자를 통해 사용량을 조직 관리 화면에 연결하고 메타가 도구 호출 경로와 도착지 주석을 세션 단위로 기록하듯, 판정 지점마다 독립적인 흔적이 남아야 사람이 개입해 동작을 멈추거나 검토할 위치를 명확히 찾을 수 있다.

다만 이러한 다중 검증 구조를 일반 시스템에 옮겨오려면 데이터 스키마 전반에 목적과 속성을 나타내는 주석 체계가 미리 정리되어 있어야 하고, 도구 호출 시 문맥을 빠짐없이 전달할 수 있는 호출 경로가 갖춰져야 한다. 이러한 인프라 조건이 준비되지 않은 상태에서는 도착지 검사를 흉내 내더라도 실제 쓰기 차단이나 책임 분리 효과를 온전히 거두기 어렵다.