GitHub Agent HQ: 무엇인지, 누구를 위한 것인지, 그리고 그 밖의 것들

기능을 하나 설명하고, 코딩 에이전트에게 넘겨준 뒤, 에이전트가 풀 리퀘스트를 열 때까지 자리를 비운다. 그러고는 두 번째 에이전트, 세 번째 에이전트에게 똑같이 반복한다. 그러다 보면 진짜 문제는 에이전트를 새로 띄우는 게 아니라, 이들을 계속 파악하고 관리하는 일이 된다. GitHub Agent HQ는 이 혼란에 대한 GitHub의 답이다. 여러 벤더의 코딩 에이전트를 GitHub 안의 하나의 관제 센터로 모아주는 미션 컨트롤인 셈이다. 이는 정말 강력한 아이디어이며, 이 가이드에서는 Agent HQ가 무엇이고 누구에게 맞는지, 그리고 대부분의 글이 건너뛰는 단 한 가지 경계선, 즉 Agent HQ는 GitHub 생태계 안에 있는 작업을 조율할 뿐 그 바깥에 있는 도구는 조율하지 않는다는 점을 다룬다.

이 경계는 팀 전체가 GitHub에 올인하지 않은 순간부터 중요해진다. 이슈 트래커로 Jira를 쓰거나, 저장소가 GitLab에 있거나, 에이전트 절반이 GitHub 클라우드에 닿지 않는 노트북과 터미널에서 돌아간다면, 특정 도구 안이 아니라 모든 도구 위에 놓이는 레이어가 필요하다. 그 레이어가 바로 Sharkly다. 올인원 Agent 명령 및 관리 플랫폼이다. 이 글에서는 Agent HQ가 빛을 발하는 지점, 그 한계가 정확히 어디인지, 그리고 중립 레이어가 어떻게 뒤섞인 에이전트 무리를 요청부터 릴리스까지 한눈에 보이게 유지하는지 살펴본다.

이 글에서는 Agent HQ의 가장 좋은 모습을 전제로 깔고 간다. 그럴 만한 가치가 있기 때문이다. 그런 다음 경계를 명확히 그어, Agent HQ만으로 충분한지 아니면 이미 단일 생태계 허브를 넘어섰는지 2분이면 판단할 수 있게 해준다.

TL;DR

GitHub Agent HQ는 GitHub 내부의 컨트롤 플레인으로, Mission Control이라는 브랜드가 붙어 있으며, 유료 GitHub Copilot 구독의 일부로 여러 벤더(Claude, Codex, Google, Cognition, xAI)의 코딩 에이전트를 할당하고 조종하고 추적한다. 모델 측면에서 에이전트에 구애받지 않으며, 작업이 이미 GitHub 저장소, 풀 리퀘스트, Actions 안에 있는 경우 탁월하다. 그 경계는 에이전트 벤더가 아니라 생태계다. 즉 GitHub 안에서 작업하는 에이전트를 조율하므로 GitLab, Jira 보드, Bitbucket, 또는 GitHub 클라우드 바깥의 Computer에서 로컬로 실행되는 에이전트의 실행은 관리하지 않는다. GitHub에 완전히 올인한 조직이라면 Agent HQ를 쓰면 된다. 팀이 트래커, 호스트, 런타임을 뒤섞어 쓰면서 이들 전체에 걸친 하나의 공유 기록과 사람의 리뷰가 필요하다면 Sharkly 같은 중립 레이어를 쓰면 된다.

GitHub Agent HQ는 실제로 무엇인가

GitHub Agent HQ는 여러 벤더의 코딩 에이전트를 할당하고 조종하고 추적하기 위한 GitHub 내부의 관제 센터로, 유료 GitHub Copilot 구독을 통해 제공된다. 이 한 문장에 전체 아이디어가 담겨 있다. 각 에이전트가 저마다의 실행 화면을 가진 개별 도구에 사는 대신, Agent HQ는 이들을 GitHub이 Mission Control이라 부르는 한곳으로 모은다. GitHub 자체, VS Code, 모바일 앱, 커맨드 라인에서 접근할 수 있다.

주목할 만한 전환점은 Agent HQ가 특정 벤더의 에이전트가 아니라는 점이다. GitHub는 Anthropic, OpenAI, Google, Cognition, xAI의 코딩 에이전트에 이를 개방했기 때문에, 허브를 떠나지 않고도 한 단계에는 Claude를, 다른 단계에는 Codex를 고를 수 있다. 에이전트에 작업을 할당하면 에이전트는 GitHub 환경의 브랜치에서 작업하고, 검사를 실행한 뒤, 이미 코드를 리뷰하던 방식 그대로 리뷰할 수 있는 풀 리퀘스트를 돌려준다. Mission Control은 그런 실행 여러 개를 한꺼번에 지켜보는 곳이며, Plan Mode 같은 기능은 에이전트가 시작하기 전에 작업 형태를 잡아주는 데 도움을 준다.

이 허브의 핵심은 조율이다. 다섯 개의 개별 에이전트 도구를 오가며 어느 것이 무엇을 하고 있는지 기억하려 애쓸 필요가 없다. AI 에이전트 오케스트레이션이란 무엇인가에 관한 해설 글을 읽어봤다면, Agent HQ는 단일 생태계 형태의 오케스트레이션이다. 여러 에이전트 벤더, 하나의 플랫폼, 그리고 그 플랫폼은 GitHub다.

Agent HQ가 잘하는 것

최선의 모습을 기준으로 보자. 가장 좋은 버전은 강력하니까. Agent HQ가 제 역할을 해내는 지점은 다음과 같다.

벤더 중립적인 에이전트 선택. 대부분의 에이전트 허브는 특정 모델 제작사에 묶어버린다. Agent HQ는 그렇지 않다. Claude, Codex 등을 나란히 실행하고, 도구를 바꾸거나 맥락을 잃지 않으면서 단계마다 다른 에이전트를 써서 아이디어에서 구현으로 넘어갈 수 있다. 이는 모델 종속에 대한 실질적인 해답이며, 출시 당시 이 기능을 앞세운 데는 그만한 이유가 있다.

여러 화면을 아우르는 하나의 관제 센터. Mission Control은 GitHub, VS Code, 모바일, CLI에서 에이전트 활동을 하나의 뷰로 보여준다. 이미 있는 자리 어디서든 할당하고, 조종하고, 추적할 수 있다. 예전에 병렬 실행을 손으로 처리하던 팀이라면, 여러 Claude Code 에이전트를 병렬로 실행하기 가이드에서 직접 하는 방식이 얼마나 까다로운지 알 수 있을 것이다. Agent HQ는 GitHub 안에서 그런 잡일을 없애준다.

리뷰가 이미 이뤄지는 곳에 도착하는 작업. 에이전트는 브랜치에서 작업하고 풀 리퀘스트를 돌려준다. 결과물은 팀이 신뢰하는 GitHub 리뷰 흐름에 그대로 들어가며, 이미 돌리고 있는 동일한 코드 리뷰, 검사, 병합 규칙을 따른다. diff를 확인할 새로운 장소가 필요 없다.

팀이 이미 살고 있는 플랫폼에 네이티브. GitHub가 팀의 집이라면 Agent HQ는 덧붙인 부품이 아니다. 여러분의 아이덴티티, 권한, Actions, 저장소를 그대로 공유한다. 사용자 지정 에이전트 지침과 제어가 그것이 작용하는 코드 옆에 놓이므로, 설정이 별도 콘솔에 떨어져 있지 않고 작업 가까이에 있다.

GitHub를 처음부터 끝까지 표준으로 삼은 팀에게 이는 깔끔하고 강력한 순환 구조다. 작업을 설명하고, 에이전트를 고르고, 풀 리퀘스트를 리뷰하고, 병합한다. 여러분이 그런 팀이라면 Agent HQ가 필요한 오케스트레이션의 전부일 수 있으며, 여기서 읽기를 깔끔하게 마쳐도 된다.

Agent HQ는 누구를 위한 것인가

Agent HQ는 GitHub에 올인한 조직을 위해 만들어졌고, 그런 조직에 잘 맞는다. 가장 명확한 적합 사례는 이렇다. 소스가 GitHub 저장소에 있고, CI가 GitHub Actions에서 돌고, 팀이 GitHub 풀 리퀘스트로 리뷰하고 병합하며, 유료 Copilot 구독을 보유하고 있다. 에이전트가 읽고, 바꾸고, 테스트하고, 배포하는 데 필요한 모든 것이 이미 하나의 플랫폼 안에 있으므로, 그 플랫폼 내부의 허브는 작업 전체에 완전히 닿을 수 있다.

2026년까지 이어지는 롤아웃이 진행되면서 그 팀에게 가치는 더 커진다. 새로운 에이전트 벤더와 새로운 Mission Control 기능이 모두 작업이 이미 자리한 곳에 도착한다. 통합할 것이 없다. 이미 돌리고 있는 플랫폼의 기능을 더 켜는 것뿐이다. GitHub 중심의 엔지니어링 조직에게 이는 설명된 작업에서 리뷰되고 병합된 변경까지 가는 가장 짧은 경로다.

문제는 Agent HQ가 이 일을 잘하느냐가 아니다. 팀의 현실 전체가 GitHub 안에 들어가는지가 문제다. 바로 여기서 경계가 등장한다.

솔직한 경계: 다른 도구가 아니라 GitHub 생태계를 오케스트레이션한다

발표 자료가 좀처럼 그어주지 않는 선이 여기 있다. 그리고 사람들이 예상하는 그 선이 아니다. 한계는 에이전트 벤더가 아니다. Agent HQ는 그 지점에서 놀랄 만큼 개방적이다. 한계는 생태계다. Agent HQ는 GitHub 안에서 작업하는 에이전트, 즉 GitHub 저장소, GitHub 풀 리퀘스트, GitHub Actions, GitHub 아이덴티티를 GitHub Copilot 구독 아래에서 조율한다. 그 모든 요소가 GitHub의 요소다. 이는 결함이 아니다. 설계다. 하지만 팀의 작업이 더 이상 전적으로 GitHub 안에 머물지 않는 날, 단단한 경계가 된다.

Agent HQ는 GitLab이나 Bitbucket의 작업을 관리하지 않는다. 저장소나 파이프라인 일부가 GitHub 바깥에 있다면, Agent HQ가 조율하는 에이전트는 거기에 닿지 못한다. 그런 실행은 공유 타임라인 없는 별개의 세계에 존재한다.

Agent HQ는 여러분의 프로젝트 트래커가 아니다. 코드와 풀 리퀘스트를 대상으로 에이전트를 조율할 뿐이다. 팀이 Jira나 Linear에서 작업을 계획하고 할당한다면, 누가 그 작업을 맡는지, 무엇에 의존하는지, 무엇이 막혀 있는지는 Agent HQ가 돌리지 않는 시스템에 있다. 풀 리퀘스트는 리뷰 화면이지, 할당과 맥락의 레이어가 아니다.

Agent HQ는 자신의 클라우드 바깥에서 실행되는 에이전트를 조율하지 않는다. 동료가 로컬 터미널에서 Claude Code를 돌리거나, 자기 Computer에서 Codex를 돌리거나, 직접 호스팅하는 런타임에서 에이전트를 돌린다면 그 작업은 Mission Control에 나타나지 않는다. 이 허브는 GitHub 안에서 자신이 실행한 에이전트를 보는 것이지, 팀이 다른 곳에서 돌리는 에이전트를 보는 게 아니다.

이 중 어느 것도 GitHub를 깎아내리는 말이 아니다. 독자가 잘못 가정할 만한 지점에서 도구가 아닌 것을 담백하게 말해두자. Agent HQ는 단일 생태계 컨트롤 플레인이지, 팀이 쓰는 모든 트래커, 호스트, 런타임을 아우르는 중립적 조율 레이어가 아니다. 스택 전체가 GitHub라면 이 경계는 전혀 문제되지 않는다. 일부라도 그렇지 않은 순간, 문제가 된다.

선택의 갈림길: GitHub 올인 조직이냐, 혼합 도구 팀이냐

선택은 "좋은 허브 대 나쁜 허브"가 아니다. "어떤 형태의 조율이 우리 팀에 맞는가"다. 솔직한 두 갈래는 이렇다.

GitHub에 완전히 올인한 조직이라면 GitHub Agent HQ를 써라. 저장소, Actions, 풀 리퀘스트, Copilot 구독이 전부이고 그 생태계 바깥에 의미 있는 작업이 없는 경우다. 그런 세계에서 Agent HQ는 작업에서 리뷰된 브랜치까지 가는 가장 짧은 경로이며, 레이어를 하나 더 얹는 건 필요 없는 오버헤드다. 작업이 하나의 집에 있으니 허브가 완전히 닿는다.

팀이 트래커, 호스트, 런타임을 뒤섞어 쓴다면 중립 레이어를 써라. 현실에 Jira 보드, GitLab 저장소, 또는 GitHub 클라우드 바깥에서 여러분이 통제하는 Computer에서 돌아가는 에이전트가 포함되는 순간, 부족한 것은 에이전트가 더 아니다. 공유 기록이다. 어느 호스트, 트래커, 런타임이 작업을 했든 목표와 diff, 논의, 사람의 리뷰를 담는 하나의 Task가 필요하다. 그건 특정 도구 안이 아니라 모든 도구 위에 놓이는 레이어가 할 일이다.

이는 개발자들이 어떤 단일 벤더 허브에서든 마주치는 동일한 갈림길이며, 에디터 사례는 Cursor 백그라운드 에이전트 해설에서, 로컬 보드 사례는 Vibe Kanban 대안 가이드에서 다룬다. 단일 생태계 오케스트레이션은 그 생태계가 더 이상 전체 이야기가 되지 않는 순간까지는 편안하다.

Sharkly의 자리: 모든 런타임과 트래커를 감싸는 중립 레이어

Sharkly는 GitHub, Copilot, Claude Code, Codex 또는 다른 실행 도구를 대체하지 않는다. 팀이 이미 쓰는 도구 주위에 공유 Task, Computer, 맥락, 제어, 리뷰 레이어를 더한다. 이 문장이 관계의 전부이니 두 번 읽어보자. GitHub는 그대로 둔다. Agent HQ는 맞는 곳에 그대로 둔다. Sharkly는 에이전트 무리가 하나의 생태계보다 클 때 그 무리를 조율하는 것이다.

역할 분담은 깔끔하다. GitHub, Copilot, Claude Code, Codex 및 비슷한 도구는 실행을 담당한다. Sharkly는 그런 도구 전반에 걸친 팀 차원의 할당, 연결된 Computer, Task 맥락, 진행 상황, 장애 요소, 결과, 사람의 리뷰를 관리한다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고한다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인한다. 자동화는 팀의 판단이 필요한 지점에서 멈춘다.

구체적으로, Sharkly의 Task는 작업의 기본 단위이며, 한 가지 작업에 관한 모든 것을 한곳에 담는다. 여러분이 통제하는 Computer에서 실행되는 Agent에 할당하고, Runtime은 원하는 대로 고르면 된다. 실행, 장애 요소, 결과, 후속 논의가 하나의 플랫폼 클라우드와 별도 트래커, 그리고 여러 개인 터미널에 흩어지는 대신 Task 타임라인으로 돌아온다. GitHub 안의 Agent HQ를 통해 이뤄진 실행이든, 동료의 Computer에서 Claude Code를 통해 이뤄진 실행이든, 내년에 도입할 무언가를 통한 실행이든, 모든 실행의 목표, diff, 논의, 리뷰가 함께 남는다.

또한 무엇도 다시 만들라고 요구하지 않는다. 팀이 이미 이해하는 프로젝트, 작업, 상태, 워크플로를 그대로 유지하고, 이미 돌리는 트래커와 호스트에 Sharkly를 연결한 뒤, 팀이 이미 쓰는 프로세스를 다시 짜지 않고 작업을 라우팅하기 시작하면 된다. 모델 사용은 해당 도구에 설정된 구독이나 API 키를 통해 계속되므로, 구독은 직접 가져오고 Sharkly가 그 위에 조율을 더한다. 플랫폼이 처음이라면 Sharkly 소개에서 핵심 개념을 살펴볼 수 있고, 첫 Task 할당 워크스루에서 가장 작은 유용한 버전을 처음부터 끝까지 보여준다. Sharkly를 다운로드하고 Computer 하나를 연결해 실제 작업에 적용해볼 수 있다.

피해야 할 흔한 실수

• "벤더 중립"을 "도구 중립"으로 착각하기. Agent HQ는 어떤 에이전트가 작업을 실행하는지에 열려 있고, 그건 진짜 강점이다. 하지만 작업이 어디에 사는지에 대해서는 열려 있지 않다. 에이전트는 여전히 GitHub 안에서 움직인다. 경계는 모델 제작사가 아니라 생태계로 읽어야 한다.
• 한 생태계의 허브를 마치 전체 전략인 양 도입하기. 오늘 Agent HQ로 표준화하고 다음 분기에도 GitLab 저장소나 Jira 보드를 살려둔다면, 조율 화면을 조용히 둘로 쪼갠 셈이다. 정말 GitHub에 올인한 것인지 혼합 도구 팀인지 일찍 정하자.
• 풀 리퀘스트를 조율 레이어로 취급하기. 풀 리퀘스트는 리뷰 화면이지 할당과 맥락의 레이어가 아니다. Task를 누가 맡는지, 무엇에 의존하는지, 왜 막혀 있는지는 diff에 담기지 않는다.
• 허브에 닿지 않는 에이전트를 잊기. 로컬 터미널이나 직접 호스팅하는 Computer 등 GitHub 바깥에서 시작된 실행은 Mission Control에 나타나지 않는다. 허브 하나를 단일 진실 공급원이라 부르기 전에 그런 실행이 몇 개인지 세어보자.

GitHub Agent HQ vs 중립 오케스트레이션 레이어

이건 점수판이 아니라 역할 분담으로 읽자.

어느 쪽 열도 "틀렸다"가 아니다. 항목별 답이 대부분 왼쪽 열에 놓인다면 Agent HQ가 맞는다. 답이 오른쪽으로 기운다면, 특히 작업이 존재하는 위치, 트래커, 공유 기록 항목에서 그렇다면, 단일 생태계 오케스트레이션은 이미 한계를 넘어선 것이다.

핵심 요약

• GitHub Agent HQ는 GitHub 내부의 컨트롤 플레인으로, Mission Control이라는 브랜드가 붙어 있으며, 유료 Copilot 구독의 일부로 여러 벤더의 코딩 에이전트를 할당하고 조종하고 추적한다.
• 이 일을 잘한다. 벤더 중립적인 에이전트 선택, GitHub, VS Code, 모바일, CLI를 아우르는 하나의 관제 센터, 그리고 이미 신뢰하는 풀 리퀘스트 리뷰 흐름에 도착하는 작업이 그것이다.
• 그 경계는 에이전트 벤더가 아니라 생태계다. GitHub 안에서 작업하는 에이전트를 조율하므로 GitLab 저장소, Jira 보드, GitHub 클라우드 바깥에서 실행되는 에이전트는 그 바깥에 있다.
• GitHub에 올인한 조직이라면 Agent HQ를 써라. 팀이 호스트, 트래커, 런타임을 뒤섞어 쓰면서 이들 전체에 걸친 하나의 공유 기록과 리뷰가 필요하다면 중립 레이어를 써라.
• Sharkly는 GitHub를 대신하는 게 아니라 함께 돈다. 도구는 그대로 두고 구독은 직접 가져오며, 모든 실행이 요청부터 릴리스까지 하나의 Task로 돌아오게 하라.

다음 단계는 일부러 작게 잡았다. Computer 하나를 연결하고, Agent 하나를 만들고, 지루한 일 하나를 맡겨보자. 각 개념에 대한 더 깊은 설명은 docs.sharkly.ai 문서에서 확인할 수 있다.

FAQ

GitHub Agent HQ를 한 문장으로 설명하면? GitHub 내부의 관제 센터로, Mission Control이라는 브랜드가 붙어 있으며, 유료 GitHub Copilot 구독의 일부로 여러 벤더의 코딩 에이전트를 할당하고 조종하고 추적한다. 에이전트는 브랜치에서 작업하고 풀 리퀘스트를 돌려준다.

Agent HQ에서는 어떤 에이전트를 실행할 수 있나? GitHub는 Anthropic, OpenAI, Google, Cognition, xAI의 코딩 에이전트에 이를 개방했기 때문에, 허브를 떠나지 않고도 한 단계에는 Claude를, 다른 단계에는 Codex를 고를 수 있다. 정확한 라인업은 2026년까지 이어지는 롤아웃과 함께 늘어난다.

GitHub Agent HQ는 무료인가? 아니다. 유료 GitHub Copilot 구독을 통해 제공되며, Copilot Pro+와 Copilot Enterprise 같은 플랜에 따라 이용 가능 여부가 달라진다. 롤아웃에 따라 바뀌므로 최신 플랜 정보는 GitHub 자체 페이지에서 확인하자.

Agent HQ는 GitLab이나 Jira와 연동되나? Agent HQ는 GitHub 생태계 안에서 작업하는 에이전트, 즉 GitHub 저장소, Actions, 풀 리퀘스트를 조율한다. GitLab이나 Bitbucket에서의 작업, Jira나 Linear에서의 계획은 그 바깥에 있다. 이들을 연결하는 것은 모든 도구 위에 놓이는 중립 레이어다. 같은 경계의 에디터 버전은 Cursor 백그라운드 에이전트 해설을 참고하자.

Sharkly를 쓰려면 GitHub를 교체해야 하나? 아니다. Sharkly는 GitHub나 어떤 실행 도구도 대체하지 않는다. 이미 쓰는 도구 주위에 공유 Task, 맥락, 리뷰 레이어를 더할 뿐이므로, GitHub, Copilot, Agent HQ는 이전과 똑같이 작동한다.

Agent HQ 위에 오케스트레이션 레이어를 얹지 말아야 할 때는 언제인가? 저장소, Actions, 풀 리퀘스트, Copilot까지 전체 스택이 GitHub이고 다른 곳에 의미 있는 작업이 없다면, Agent HQ가 필요한 오케스트레이션의 전부일 수 있다. 여러 호스트, 트래커, 런타임을 돌리면서 이들 전체에 걸친 하나의 공유 기록이 필요할 때만 중립 레이어를 더하자.

Sharkly가 모델 비용 지불 방식을 바꾸나? 아니다. 구독은 직접 가져온다. 모델 사용은 연결된 도구에 설정된 구독이나 API 키를 통해 계속되며, 모델 할당량은 팀이 연결한 플랜과 API 계정에 따라 달라진다.

큰 마이그레이션 없이 중립 레이어 방식을 시험하려면? 가장 작은 유용한 워크플로로 시작하자. Computer 하나를 연결하고, Agent 하나를 만들고, 위험 부담이 낮은 Task 하나를 할당하면 된다. 첫 Task 할당 워크스루에서 단계별로 다루며, 여러 Claude Code 에이전트를 병렬로 실행하기에서 에이전트 무리 쪽을 보여준다.