Mission Control을 사용하여 에이전트를 오케스트레이션하는 방법

Source: GitHub Blog

우리는 최근에 Agent HQ의 미션 컨트롤을 출시했습니다. 이는 GitHub Copilot 코딩 에이전트 작업을 관리하기 위한 통합 인터페이스입니다.

이제 레포지토리 전반에 걸쳐 Copilot에 작업을 할당하고, 커스텀 에이전트를 선택하며, 실시간 세션 로그를 확인하고, 실행 중에(일시 중지, 수정 또는 재시작) 조정하고, 결과 풀 리퀘스트로 바로 이동할 수 있습니다—모두 한 곳에서 가능합니다. 상태, 이유, 변경 사항을 확인하기 위해 여러 페이지를 오가던 대신, 미션 컨트롤이 할당, 감독, 검토를 중앙화합니다.

도구를 갖는 것과 효과적으로 사용하는 것은 별개의 문제입니다. 이 가이드는 여러 에이전트를 오케스트레이션하는 방법, 언제 개입해야 하는지, 그리고 작업을 효율적으로 검토하는 방법을 보여줍니다. 에이전트를 잘 오케스트레이션한다는 것은 하나의 작업에 소요되는 시간 안에 병렬 작업을 차단 해제하고, 로그에 편차가 보이거나 테스트가 실패하거나 범위가 확대될 때 개입한다는 의미입니다.

사고 모델 전환

순차에서 병렬로

이미 에이전트를 하나씩 사용하는 데 익숙하다면, 그것이 본질적으로 순차적이라는 것을 알고 있을 것입니다. 프롬프트를 제출하고, 응답을 기다리고, 검토하고, 조정하고, 다음 작업으로 넘어갑니다.

미션 컨트롤은 이를 바꿉니다. 몇 분 안에 여러 작업을 시작할 수 있습니다—하나의 레포든 여러 레포든 마찬가지입니다. 이전에는 서로 다른 레포로 이동해 각각 이슈를 열고 Copilot을 별도로 할당해야 했습니다. 이제 한 곳에서 프롬프트를 입력하면 Copilot 코딩 에이전트가 모든 레포에서 작업을 수행합니다.

하지만 기억해야 할 트레이드오프가 있습니다: 각 작업이 30초에서 몇 분 안에 완료되는 대신, 에이전트가 초안에 몇 분에서 한 시간 정도 소요될 수 있습니다. 하지만 이제는 단순히 기다리는 것이 아니라 오케스트레이션을 하고 있는 것입니다.

언제 순차적으로 유지해야 할까

모든 것이 병렬에 적합한 것은 아닙니다. 다음과 같은 경우 순차 워크플로를 사용하세요:

• 작업 간에 의존성이 있을 때
• 익숙하지 않은 영역을 탐색할 때
• 복잡한 문제에서 단계 사이에 가정 검증이 필요할 때

같은 레포에서 여러 작업을 할당할 때는 겹침을 고려하세요. 에이전트가 병렬로 작업하면 같은 파일을 수정해 병합 충돌이 발생할 수 있습니다. 작업을 나눌 때 신중히 계획하세요.

보통 병렬로 잘 수행되는 작업:

• 조사 작업(피처 플래그, 설정 옵션 찾기)
• 분석(로그 분석, 성능 프로파일링)
• 문서 생성
• 보안 검토
• 서로 다른 모듈이나 컴포넌트에서의 작업

시작을 위한 팁

전환은 간단합니다: 단일 실행을 기다리는 대신 여러 실행을 병렬로 감독하고, 테스트 실패, 범위 편차, 혹은 명확하지 않은 의도가 발견될 때 개입합니다.

컨텍스트를 포함한 명확한 프롬프트 작성

구체성이 중요합니다. 작업을 정확히 설명하세요. 좋은 컨텍스트는 좋은 결과를 위한 필수 요소입니다.

도움이 되는 컨텍스트 예시:

• 문제를 보여주는 스크린샷
• 원하는 패턴을 보여주는 코드 조각
• 관련 문서나 예시 링크

약한 프롬프트: “인증 버그를 고쳐 주세요.”

강한 프롬프트:

사용자들이 30분 활동 후 ‘Invalid token’ 오류를 보고합니다. JWT 토큰은 `auth.config.js`에서 1시간 만료로 설정되어 있습니다. 토큰이 일찍 만료되는 원인을 조사하고 검증 로직을 수정하세요. `api-gateway` 레포에서 풀 리퀘스트를 생성합니다.

일관성을 위한 커스텀 에이전트 활용

미션 컨트롤에서는 선택한 레포의 agents.md 파일을 기반으로 하는 커스텀 에이전트를 선택할 수 있습니다. 이 파일들은 에이전트에게 페르소나와 사전 작성된 컨텍스트를 제공해, 매번 동일한 예시나 지시를 제공해야 하는 부담을 없애줍니다.

팀이 정기적으로 에이전트를 사용하는 레포가 있다면, 일반적인 워크플로에 맞춘 agents.md 파일을 만들 것을 고려하세요. 이렇게 하면 작업 전반에 걸쳐 일관성을 유지하고, 상세 프롬프트를 매번 작성하는 인지 부하를 줄일 수 있습니다.

프롬프트를 작성하고 커스텀 에이전트를 선택한 뒤(해당되는 경우) 작업을 시작하면, 에이전트가 즉시 작업을 시작합니다.

적극적인 오케스트레이션을 위한 팁

이제 여러분은 에이전트의 지휘자입니다. 각 작업은 복잡도에 따라 1분에서 1시간까지 걸릴 수 있습니다. 두 가지 선택지가 있습니다: 에이전트가 작업하는 모습을 지켜보며 필요 시 개입하거나, 작업이 끝날 때까지 떠나 있는 것입니다.

신호 읽기

에이전트가 올바른 방향으로 진행되지 않을 때 나타나는 일반적인 징후:

• 테스트, 통합, 혹은 fetch 실패 – 의존성을 가져오지 못하거나 인증이 실패하거나 단위 테스트가 반복적으로 깨집니다.
• 예상치 못한 파일 생성 – 범위 밖 파일이 diff에 나타나거나 공유 설정을 수정합니다.
• 요청한 범위를 넘어서는 범위 확대 – 에이전트가 인접 코드를 리팩터링하거나 요청하지 않은 “개선”을 수행합니다.
• 의도 오해 – 세션 로그에 에이전트가 프롬프트를 다르게 해석한 내용이 드러납니다.
• 순환 행동 – 에이전트가 같은 실패 접근을 여러 번 시도하지만 조정하지 않습니다.

문제를 발견하면 심각성을 평가하세요. 그 테스트 실패가 핵심인가? 해당 통합 포인트가 이번 작업에 중요한가? 세션 로그는 보통 행동 전에 의도를 보여주므로, 모니터링 중이라면 개입할 기회를 제공합니다.

스티어링의 기술

에이전트를 재지시해야 할 때는 구체적으로 설명하세요. 왜 재지시하는지, 어떻게 진행하기를 원하는지 명확히 전달합니다.

나쁜 스티어링: “이거 맞지 않아요.”

좋은 스티어링:

`database.js`를 수정하지 마세요—그 파일은 서비스 전반에 공유됩니다. 대신 `api/config/db-pool.js`에 연결 풀 설정을 추가하세요. 이렇게 하면 변경이 API 레이어에만 국한됩니다.

시점도 중요합니다. 문제를 5분 정도 진행했을 때 잡아내면 비효율적인 작업을 한 시간 정도 절감할 수 있습니다. 에이전트가 작업을 마칠 때까지 기다리지 마세요.

작업 중간에 에이전트를 중단하고 정제된 지시를 줄 수도 있습니다. 더 나은 방향으로 재시작하는 것이 잘못 정렬된 에이전트를 계속 진행시키는 것보다 간단하고 빠릅니다.

세션 로그가 중요한 이유

세션 로그는 행동뿐 아니라 추론 과정을 보여줍니다. 풀 리퀘스트가 되기 전에 오해를 드러내며, 향후 프롬프트와 오케스트레이션 방식을 개선하는 데 도움을 줍니다. Copilot이 “전체 인증 시스템을 리팩터링하겠다”고 말한다면, 바로 스티어링을 해야 할 신호입니다.

검토 단계 팁

에이전트가 작업을 마치면 풀 리퀘스트를 검토하게 됩니다. 효율적으로 검토하는 방법은 다음과 같습니다.

• 세션 로그 – 에이전트가 무엇을 했고 왜 했는지 파악합니다. 병합된 코드가 되기 전에 추론 오류를 찾아냅니다. 에이전트가 의도를 오해했나요? 잘못된 가정을 했나요?
• 변경된 파일 – 실제 코드 변화를 검토합니다. 특히 다음을 중점적으로 살펴보세요:
  • 예상치 못한 파일이 수정된 경우
  • 공유되거나 위험도가 높은, 핵심 코드 경로를 건드린 경우
  • 팀 표준/관행에 맞지 않는 패턴
  • 누락된 엣지 케이스 처리
• 체크 – 테스트가 통과하는지 확인합니다(단위 테스트, Playwright, CI/CD 등). 체크가 실패하면 바로 에이전트를 재시작하지 말고 원인을 조사하세요. 실패한 테스트는 에이전트가 요구사항을 오해했을 가능성을 보여줍니다, 단순히 버그가 난 것이 아닐 수 있습니다.

이 패턴을 따르면 의도, 구현, 검증을 모두 파악할 수 있습니다.

Copilot에게 자체 검토를 요청하기

에이전트가 작업을 마친 뒤 다음과 같이 물어보세요:

• “어떤 엣지 케이스를 놓쳤나요?”
• “테스트 커버리지가 부족한 부분은 어디인가요?”
• “이 실패한 테스트를 어떻게 고쳐야 하나요?”

Copilot은 스스로의 작업에서 격차를 찾아낼 수 있어, 시간을 절약하고 최종 결과를 개선합니다. 이를 주니어 개발자가 자신의 reasoning을 설명해 주는 것처럼 활용하세요.

유사 리뷰 묶어서 처리하기

에이전트로 코드를 생성하는 것은 간단합니다. 그러나 그 코드를 검토하고, 기준에 맞는지, 원하는 동작을 하는지, 팀이 유지 관리할 수 있는지를 판단하는 데는 인간의 판단이 필요합니다.

비슷한 작업을 그룹화하면 리뷰 효율이 높아집니다. 예를 들어 모든 API 변경을 한 번에 검토하고, 문서 변경은 별도로 검토하는 식으로 진행하세요. Your bra