밤마다 돌아가는 에이전트에 사람 계정이 꼭 필요했을까
매일 새벽 저장소를 검사해 중복된 이슈를 정리하거나, 여러 프로젝트의 변경 내용을 한꺼번에 요약하는 서비스를 만든다고 가정해 보자. 사람이 직접 터미널에서 실행할 때는 자신의 GitHub 계정으로 로그인하면 된다. 하지만 같은 프로그램을 서버에서 주기적으로 돌리면 누가 로그인했는지, 그 사용자가 회사를 떠나면 어떻게 되는지, AI 사용료가 어느 계정에 청구되는지가 운영 문제가 된다. 인증이 단순한 로그인 절차가 아니라 자동화의 가동 시간을 좌우하게 되는 것이다.
GitHub는 2026년 10월 27일 Copilot SDK에 서버 간 인증을 도입했다고 발표했다. 조직에 설치한 GitHub App을 서비스 자체의 신원으로 사용하고, 개인의 로그인 상태를 빌리지 않고 Copilot 요청을 보내는 방식이다. GitHub는 이를 공개 프리뷰라고 명시했다. 누구나 모든 환경에서 바로 쓸 수 있는 완성된 정식 기능이라고 소개해서는 안 되며, 조직별 지원 상태와 권한을 먼저 확인해야 한다.
예를 들어 사내 품질 점검 봇이 특정 담당자의 개인 인증 정보를 저장하고 있다면 담당자가 퇴사하거나 인증이 갱신됐을 때 문제가 생길 수 있다. 반면 GitHub App을 설치 주체로 삼으면 담당자의 브라우저 세션과 서비스의 인증을 분리할 수 있다. 이는 사람이 해야 할 코드 리뷰를 전부 대체한다는 뜻이 아니다. 먼저 바뀌는 것은 AI를 호출하는 서비스의 신원과 운영 책임이다.
개인 토큰 대신 GitHub App 설치 토큰을 사용하는 흐름
GitHub 공식 문서는 GitHub Actions 외부에서 동작하는 서버를 기준으로 세 단계를 설명한다. 먼저 조직 수준의 Copilot Requests 권한을 읽기 전용으로 설정한 GitHub App을 만든다. 이어서 AI 요청 비용을 부담할 조직에 앱을 설치한다. 마지막으로 앱 설치에 대한 짧은 수명 액세스 토큰을 발급받아 Copilot SDK에 전달한다. 토큰은 앱을 설치한 조직의 권한을 대표하며, 기존 사용자 토큰과 같은 것으로 취급하면 안 된다.
토큰을 생성할 때 공식 문서에 제시된 권한 값은 organization_copilot_requests의 read다. 실제 요청에서는 사용 중인 SDK 언어의 gitHubToken 또는 github_token 같은 명시적 토큰 옵션을 사용한다. 이미 실행 중인 런타임에 연결하는 구성이라면 문서가 안내하는 COPILOT_GITHUB_TOKEN 환경 변수를 런타임 프로세스에 전달하는 방법을 사용한다. 이 글의 구성은 공식 문서를 읽고 설명한 것이며, 실제 조직에 GitHub App을 설치하거나 유료 AI 요청을 실행한 결과는 아니다.
중요한 세부 사항도 있다. 공식 문서는 useLoggedInUser: false로 자동 인증 정보 탐색을 끌 경우 환경 변수에 있는 토큰까지 자동으로 읽지 않는다고 안내한다. 따라서 이 설정을 사용할 때는 설치 토큰을 SDK의 명시적 옵션으로 전달해야 한다. 토큰을 발급받았다고 무조건 인증이 성공하는 것은 아니며, 조직에서 앱 설치 기반 Copilot 요청을 허용해야 한다. 권한이 없거나 조직 정책으로 막혀 있다면 관련 오류부터 확인해야 한다.
한 시간짜리 토큰을 영구 API 키처럼 다루면 안 된다
GitHub App의 설치 액세스 토큰은 오래 보관하는 비밀번호가 아니다. 공식 서버 간 인증 문서는 설치 토큰이 한 시간 후 만료된다고 명시한다. 그러므로 주기적으로 작업을 실행하는 서비스라면 실행 전에 유효한 설치 토큰을 발급받고, 장시간 실행하는 서비스라면 만료 전에 새로운 토큰으로 교체하는 절차가 필요하다. 한번 발급받아 환경 변수에 영구 저장하는 설계는 다음 실행에서 인증 실패를 만들 수 있다.
문서가 권장하는 갱신 방식은 구성에 따라 다르다. 자식 프로세스로 SDK 클라이언트를 실행했다면 새 토큰으로 클라이언트를 다시 시작하고, 인프로세스나 기존 런타임에 연결하는 경우에는 해당 호스트 런타임을 새 인증 정보로 다시 시작한다. 서비스가 실행 중인 동안 토큰이 만료될 때의 동작을 개발자가 따로 고려해야 한다. 토큰을 갱신한다는 이유로 비밀값을 Git 커밋이나 로그에 남기는 것도 피해야 한다.
진단할 때는 오류의 종류를 나누는 편이 빠르다. 401은 만료되거나 유효하지 않은 토큰일 수 있고, 403은 필요한 조직 권한이나 앱 설치 기반 요청 허용 정책이 빠진 경우에 나타날 수 있다. 요청한 모델이 보이지 않는다면 인증 문제만 찾을 것이 아니라 조직의 모델 정책과 런타임 지원 여부도 확인해야 한다. 이 구분은 장애가 났을 때 토큰만 계속 재발급하는 불필요한 시도를 줄이는 데 도움이 된다.
AI 호출 비용은 누구에게 청구되고 누가 통제할까
이 기능은 자동화 서비스에 사용자가 로그인하지 않아도 된다는 편의성만을 의미하지 않는다. GitHub 발표에 따르면 Copilot SDK 사용량은 GitHub App을 설치한 조직에 귀속되며, 해당 조직의 모델 정책과 예산 및 지출 제어가 적용된다. 조직이 여러 서비스의 사용을 관리할 때 개인의 구독 상태나 팀원의 계정에 모든 비용을 맡기지 않아도 된다는 점이 핵심이다. 다만 이 설명이 Copilot 호출을 무료로 만든다는 뜻은 아니다.
조직 관리자는 어떤 앱이 Copilot에 접근할 수 있는지 검토할 수 있다. GitHub는 AI 이용량 CSV 보고서에서 app_client_id 필드로 앱별 사용량을 식별할 수 있다고 설명한다. 사용자와 앱의 활동을 구별할 수 있으면 서로 다른 봇이 얼마나 요청을 보내는지 살펴보기 쉬워진다. 특정 자동화에 문제가 생기면 앱을 정지하거나 제거해 접근을 차단하는 관리 방법도 제공한다.
도입 전에 확인할 운영 항목은 명확하다. 앱을 어느 조직에 설치할지, 허용할 모델은 무엇인지, 지출 한도는 얼마인지, 사용량을 누가 검토할지 합의해야 한다. 사용량이 조직에 귀속된다는 것은 책임도 조직이 진다는 뜻이다. 자동 에이전트가 무한히 반복 호출하도록 두고 나중에 결제 내역을 확인하는 방식보다는 작업별 호출량과 실패 횟수를 관찰하도록 만드는 것이 낫다. 정확한 단가는 조직의 계약 및 사용 모델에 따라 달라질 수 있으므로 공식 관리 화면에서 확인해야 한다.
GitHub Actions에서 실행한다면 인증 방법이 다르다
모든 자동화를 위해 새 GitHub App을 만들어야 하는 것은 아니다. GitHub 공식 문서는 조직이 소유한 저장소의 GitHub Actions 워크플로에서는 내장 GITHUB_TOKEN을 활용할 수 있다고 구분한다. 해당 토큰에 contents: read와 copilot-requests: write 권한을 지정하고, 조직의 Copilot CLI 사용 정책이 허용돼 있다면 별도의 저장형 인증 비밀이나 GitHub App 없이 요청할 수 있다는 설명이다. 설정의 권한 이름과 수준은 다른 서비스를 위한 GitHub App의 읽기 전용 조직 권한과 혼동하면 안 된다.
반면 별도의 VPS, 사내 서버 또는 다른 CI 시스템에서 장시간 운영되는 작업은 GitHub App 설치 토큰 방식이 고려 대상이다. 두 경우 모두 일단 실행은 될 수 있어도 운영 제약은 다르다. Actions는 저장소와 워크플로 권한의 경계 안에서 작동한다. 외부 서버는 배포 환경에서 토큰 발급 및 갱신 절차를 직접 챙겨야 한다. 따라서 단순한 정기 작업이라면 기존 Actions로 충분한지 먼저 판단하고, 여러 시스템에서 사용하는 공용 서비스라면 앱 기반 인증의 장점이 커질 수 있다.
인증 방식만 바꾼다고 코드가 안전해지는 것도 아니다. AI 모델이 제안한 명령을 자동 실행하는 기능을 만들었다면 파일 접근, 쉘 명령 실행, 외부 네트워크 접속 같은 권한은 별도 단계에서 통제해야 한다. Copilot 요청을 할 수 있는 권한과 GitHub 저장소를 수정하거나 운영 서버에서 명령을 실행할 권한은 서로 다른 문제다. 최소 권한으로 앱을 설치하고 운영 작업의 승인 범위를 좁히는 기본 원칙은 그대로 유지된다.
어떤 자동화에서 의미가 있고, 지금 무엇을 확인해야 할까
활용 범위를 생각하면 사람이 옆에서 매번 로그인하지 않는 서비스가 가장 분명한 대상이다. 사내 저장소의 주간 변경 요약, 오류 티켓의 초안 분류, 여러 팀 프로젝트의 문서 변경 점검처럼 정기적으로 돌아가는 AI 프로그램이 여기에 해당한다. 다만 이 기능이 직접 문서를 분석하거나 이슈를 분류해 주는 것은 아니다. 그 일을 수행할 로직은 Copilot SDK를 사용하는 개발자가 만들어야 하고, 이번 발표는 그 프로그램이 Copilot에 접근하는 인증 경로를 추가한 것이다.
바로 도입할지 결정할 때는 네 가지를 살펴보면 된다. 조직이 설치 토큰 기반 Copilot 요청을 허용하는지, 현재 SDK가 해당 인증 방식을 지원하는지, 사용할 모델이 조직 정책에서 허용되는지, 비용과 사용량을 추적할 담당자가 있는지다. 그 뒤에 개발 환경에서 단일 요청부터 검증하고, 짧은 수명 토큰을 자동 갱신하는 운영 절차를 확인하는 순서가 적절하다. 먼저 대규모 서비스에 붙였다가 인증 방식이 다르다는 사실을 발견하는 시행착오를 피할 수 있다.
2026년 10월 28일 기준 이 기능은 공개 프리뷰이며, GitHub가 정식 출시 날짜를 발표한 것으로 확인되지는 않는다. 따라서 소개글을 읽고 당연히 모든 조직에서 즉시 사용 가능하다고 판단하지 않는 편이 좋다. 장기 운영 계획을 세울 때는 공식 변경 기록과 인증 문서의 최신 내용을 다시 확인해야 한다. 이 글은 해당 문서를 근거로 동작과 적용 조건을 설명한 것으로, 특정 조직에서 성공적으로 실행된 사례나 성능 측정치로 오해해서는 안 된다.