지난 1년 동안 저는 업무와 개인 프로젝트에서 GitHub Copilot을 사용해 왔습니다. '바이브 코딩 (vibe coding)'에서

코드 에이전트 (code agent)란 파일을 검사하고, 코드를 수정하며, 명령어를 실행할 수 있는 도구를 가지고 목표를 향해 작동하는 Copilot을 의미합니다. 저는 Copilot을 단순히 영리한 프롬프트 응답자로 취급하는 것을 멈추고, 제 엔지니어링 프로세스의 일부로 취급하기 시작했습니다.

저는 VS Code의 Copilot Chat으로 시작하여 CLI로 옮겨갔고, 이제는 대부분의 작업을 Copilot App에서 수행합니다. Copilot에게 완전한 작업을 맡겨보면서, 좋은 프롬프트만으로는 충분하지 않다는 것을 배웠습니다. 저장소 (repository)를 이해 가능하게 만드는 아키텍처 (architecture), 규칙 (rules), 그리고 검증 명령어 (validation commands)도 필요합니다. 일단 그 지식을 코드와 함께 저장해 두면, 매 새로운 세션은 훨씬 더 나은 상태에서 시작됩니다.

이것이 실무에서의 에이전틱 엔지니어링 (agentic engineering)입니다. 저장소가 컨텍스트 (context)를 제공하고, 에이전트와 그 도구들이 작업을 수행하며, 자동화된 체크 (automated checks)가 증거를 제공하고, 사람이 결과물이 준비되었는지 결정합니다. 제어 방식은 App과 CLI 간에 차이가 있지만, 동일한 모델이 Copilot의 여러 인터페이스 (surfaces)에서 작동합니다.

코드 에이전트가 처음이라면, 모든 것을 한꺼번에 설정하지 마세요. 먼저 작은 작업 하나를 완료한 다음, 필요성이 실제로 느껴질 때 커스텀 에이전트 (custom agents), 스킬 (skills), MCP, 또는 Spec Kit을 추가하세요.

Copilot 작업의 구조 (Anatomy of a Copilot task)

Copilot이 작업을 처리할 때마다 여러 요소가 결합됩니다.

Copilot 작업의 구성 요소들.

Copilot은 에이전트 하네스 (agent harness)를 제공합니다. 이는 컨텍스트 (context), 도구 (tools), 권한 (permissions), 세션 (sessions), 그리고 실행 (execution)을 관리하는 모델 주변의 런타임 (runtime)입니다. 그러면 저장소가 해당 하네스를 팀이 소프트웨어를 구축하는 방식에 맞게 조정합니다.

작업을 수행하기 전에, Copilot은 나의 프롬프트(prompt), 내가 첨부하거나 언급한 파일, 관련 저장소(repository) 콘텐츠, 그리고 변경되는 파일에 적용되는 지침(instructions)으로부터 컨텍스트(context)를 구축합니다. 더 나은 컨텍스트는 추측을 줄여주지만, 생성된 코드가 자동으로 정확해지는 것은 아닙니다. 나는 여전히 제안된 모든 변경 사항을 검토합니다.

다음 결정 사항은 누가 작업을 수행할 것인가입니다. 나는 커스텀 에이전트(custom agent)를 선택하거나, Copilot이 작업 내용과 일치하는 설명을 가진 에이전트를 선택하도록 할 수 있습니다. 적합한 전문가가 없다면, 메인 Copilot 에이전트가 요청을 처리합니다. 첫 번째 작업에는 그 기본 설정으로도 충분합니다. 나는 책임 범위가 아키텍처(architecture), 구현(implementation), 리뷰(review), 테스트(testing), 또는 문서화(documentation)임이 명확할 때 전문가를 선택합니다.

일상적인 작업의 경우, 모델을 기본값으로 둡니다. 문제의 난이도가 추가 비용과 시간을 정당화할 때만 더 강력한 모델이나 더 높은 추론(reasoning) 능력을 가진 모델을 사용합니다. 앱(App)은 모델 선택기(model picker)를 제공하며, CLI는 /model 명령어를 사용합니다.

또한 에이전트가 얼마나 독립적으로 작동할지도 선택합니다. 대화형 모드(Interactive mode)는 나를 대화 흐름 속에 유지시킵니다. 계획 모드(Plan mode)는 코드 변경이 시작되기 전에 접근 방식을 검토할 수 있게 해줍니다. 오토파일럿(Autopilot)은 작업이 명확하고 신뢰할 수 있는 검증(checks)이 가능할 때 기다리지 않고 작업을 계속합니다. 앱에서는 이러한 옵션들이 세션 컨트롤(session controls)의 일부로 포함되어 있습니다. CLI에서는 Shift+Tab을 눌러 이 모드들을 전환합니다.

마지막 설정 선택은 작업이 어디에서 실행될 것인가입니다. 앱에서는 현재 저장소, 새로운 워크트리(worktree), 또는 GitHub에서 호스팅하는 클라우드 샌드박스(cloud sandbox)를 사용할 수 있습니다. 나는 보통 워크트리를 선택하는데, 이는 나의 메인 체크아웃(main checkout)을 방해하지 않으면서 작업에 별도의 폴더와 브랜치(branch)를 부여하기 때문입니다.

CLI는 이미 열려 있는 디렉토리와 Git 브랜치에서 로컬로 시작됩니다. 세션이 시작될 때 별도의 워크트리를 생성하지는 않습니다. 나는 첫 번째 작업을 수행하기 전에 기능 브랜치(feature branch)를 생성하며, 대신 호스팅된 환경에서 작업을 실행하고 싶을 때는 copilot --cloud를 사용합니다.

격리(isolation) 관련 용어들은 서로 연관되어 있지만, 각기 다른 역할을 수행합니다. 세션 (session)은 대화와 작업 컨텍스트 (context)를 유지합니다. 브랜치 (branch)는 작업의 커밋 (commits)을 main으로부터 분리합니다. 워크트리 (worktree)는 해당 브랜치에 별도의 폴더를 부여하며, 이는 메인 체크아웃 (main checkout)을 열어둔 상태를 유지하거나 작업을 병렬로 실행하고 싶을 때 유용합니다. 샌드박스 (sandbox)는 명령어가 도달할 수 있는 범위를 제한하거나 실행을 격리된 클라우드 환경 (cloud environment)으로 옮김으로써 다른 경계를 보호합니다.

이러한 계층 중 어느 것도 리뷰 (review)를 대체하지는 않습니다. 결과를 수락하기 전에 저는 디프 (diff), Copilot이 실행한 명령어, 그리고 그 출력 결과 (output)를 검사합니다. 앱 (App)에서는 'Changes'가 디프를 보여주며, 'Plan'과 'Artifacts'는 세션이 어떻게 진행되었는지 설명합니다. CLI에서는 /diff를 통해 변경 사항을 한데 모아 확인합니다. 저는 풀 리퀘스트 (pull request)를 생성하기 전에 예상된 체크 (checks)가 통과되었는지 확인합니다.

실무에서의 에이전트 (Agents), 서브 에이전트 (subagents), 그리고 스킬 (skills)

커스텀 에이전트 (custom agent)가 선택되지 않았을 때는 메인 Copilot 에이전트가 요청을 처리합니다. CLI에는 탐색 (exploration), 명령어 실행 (command execution), 코드 리뷰 (code review), 리서치 (research), 그리고 러버덕 분석 (rubber-duck analysis)을 위한 내장된 전문가 (specialists)들도 포함되어 있습니다.

커스텀 에이전트는 고유한 지침 (instructions)과 도구 (tools)를 가진 재사용 가능한 역할 (role)이며, 보통 .github/agents/에 저장됩니다. 저는 책임 범위가 바뀔 때 커스텀 에이전트를 사용합니다. 예를 들어, 아키텍처 에이전트 (architecture agent)는 옵션들을 비교하고 아키텍처 결정 기록 (architecture decision record)을 준비할 수 있습니다. 제가 그 방향을 승인하면, 구현 에이전트 (implementation agent)가 코드를 변경하고 체크 (checks)를 실행할 수 있습니다.

서브에이전트 (subagent)는 다릅니다. 이는 더 큰 작업의 일부를 처리하기 위해 생성된, 자체적인 컨텍스트 (context)를 가진 임시 작업자입니다. 예를 들어, 저는 메인 에이전트 (main agent)에게 전체 변경 사항에 대한 책임을 유지하면서, 유닛 테스트 (unit tests)를 위해 테스트 작성 에이전트 (test-writer agent)를 사용하도록 요청할 수 있습니다. Fleet command는 여러 개의 독립적인 서브에이전트를 병렬로 실행함으로써 이러한 개념을 확장합니다.

스킬 (skill)은 새로운 역할이라기보다 재사용 가능한 방법을 포착합니다. 리포지토리 스킬 (Repository skills)은 코드와 함께 유지되므로, 프로젝트의 모든 구성원이 동일한 가이드를 사용할 수 있습니다. 저는 여러 프로젝트에 걸쳐 재사용하는 워크플로 (workflows)를 위해 개인 스킬 (personal skills)을 유지합니다. 스킬이 필요할 때는 단순히 Copilot에게 사용해 달라고 요청하면 됩니다: "이 엔드포인트 (endpoint)를 검토하기 위해 API 호환성 스킬을 사용해줘."

이러한 구분을 통해 설정은 간소하게 유지됩니다. 하나의 구현 에이전트 (implementation agent)가 적절한 스킬을 로드하고 변경할 파일에 대한 지침을 따를 수 있으므로, 별도의 Python, TypeScript, Terraform 에이전트가 필요하지 않습니다.

도구 (Tools)는 기능입니다

Copilot에는 파일을 검색하고, 코드를 읽고 편집하며, 빌드나 테스트와 같은 명령을 실행하기 위한 내장 도구 (built-in tools)가 있습니다. 저는 모든 단계를 규정하기보다 결과를 설명합니다. 만약 제가 "API 토큰 검증이 어디에 구현되어 있나요?"라고 묻는다면, Copilot은 토큰 참조를 검색하고, 일치하는 미들웨어 (middleware)와 설정을 조사한 뒤, 관련 경로와 함께 답변할 수 있습니다.

파일을 편집하거나 명령을 실행하는 도구에는 권한이 필요합니다. CLI에서 Copilot은 제가 해당 작업을 이미 허용하지 않은 한 승인을 요청합니다. 저는 작업에 필요한 액세스 (access)만 허용합니다. GitHub는 Copilot CLI 권한 모델 (Copilot CLI permission model)에서 선택 가능한 옵션들을 설명하고 있습니다.

Model Context Protocol (보통 MCP라고 불림)은 이러한 기능들을 저장소(repository) 외부의 시스템으로 확장합니다. MCP 서버는 GitHub, Azure DevOps, 브라우저 자동화(browser automation), 데이터베이스, 클라우드 리소스 또는 관측성 플랫폼(observability platforms)을 위한 도구(tools)를 노출할 수 있습니다. 저는 이를 선택 사항으로 취급하며, 작업이 진정으로 외부 데이터나 동작을 필요로 할 때만 추가합니다.

App에서는 Settings > MCP servers에서 이러한 연결을 관리합니다. 카탈로그에서 서버를 설치하거나, 커스텀 서버를 추가하거나, 사용하지 않는 항목을 비활성화할 수 있습니다.

Copilot App 내의 MCP 서버들.

CLI에서는 /mcp add로 서버를 추가하고, /mcp show로 구성된 서버들을 검사할 수 있습니다. 서버가 연결되면, Copilot은 작업이 필요할 때 관련 도구를 선택할 수 있습니다. 또한 다음과 같이 명시적으로 명령할 수도 있습니다: "Azure DevOps MCP 서버를 사용하여 나에게 할당된 활성 작업 항목(work items)을 나열해줘."

저는 MCP 액세스를 좁게 유지합니다. 사용하지 않는 서버는 비활성 상태로 유지하고, 노출되는 도구는 워크플로(workflow)에 필요한 것으로 제한하며, 모든 로그인 또는 토큰은 실무적으로 가능한 가장 작은 권한 세트만 부여받습니다.

시작하는 방법

App 또는 CLI 중 하나를 선택하세요. 둘 다 구성할 필요는 없습니다. 검증 명령(validation command)이 알려진 저장소에서 작고 되돌릴 수 있는 변경 사항부터 시작하세요.

Copilot App에서 프로젝트(project)는 Copilot에 연결된 폴더 또는 저장소입니다. 세션(session)은 에이전트가 해당 프로젝트에서 하나의 작업을 처리하는 워크스페이스(workspace)입니다. GitHub의 App quickstart에서는 App 설치, 로그인 및 첫 번째 저장소 연결 방법을 설명합니다.

시작하려면 Sessions 옆의 플러스(+) 기호를 클릭하고 코드베이스(codebase)를 선택합니다. 이는 이미 내 컴퓨터에 있는 폴더, 로컬 클론(local clone), 또는 App이 GitHub이나 다른 Git 호스트로부터 클론하는 저장소일 수 있습니다.

첫 번째 작업으로, 저는 Copilot이 무엇인가를 변경하기 전에 접근 방식을 검토할 수 있도록 Plan mode를 사용합니다. 저는 하나의 결과물(outcome)을 설명하고, 그 경계(boundary)를 정의하며, 그것이 작동함을 증명할 명령어를 지정합니다. 유용한 첫 번째 프롬프트 예시는 다음과 같습니다: "빈 작업 제목을 거부하는 검증(validation) 로직을 추가하세요. 다른 동작은 변경하지 마세요. pytest를 실행한 다음, diff와 테스트 결과를 보여주세요."

이슈(Issues)와 파일은 Composer에서 유용한 컨텍스트를 제공할 때 직접 첨부할 수 있습니다. 중요한 부분은 구문(syntax)이 아닙니다. Copilot에게 명확한 결과물, 경계, 그리고 결과를 검증할 방법을 제공하는 것입니다.

격리된 로컬 작업을 위해, App은 자체 브랜치(branch)와 체크아웃(checkout)을 가진 Git worktree를 생성할 수 있습니다. 이 옵션은 Git 저장소(repositories)에서 사용할 수 있으며, 에이전트가 나의 메인 작업 폴더를 변경하지 않고 파일을 편집할 수 있게 해줍니다. Quick chat은 다른 용도로 사용됩니다. 저는 질문이나 브레인스토밍을 위해 이를 사용하는데, 이는 브랜치나 worktree를 생성하지 않기 때문입니다.

터미널을 선호한다면, GitHub의 CLI 설치 가이드를 따르고, 저장소 내부에서 터미널을 연 다음, Copilot을 시작하기 전에 기능 브랜치(feature branch)를 생성합니다:

git status
git switch -c copilot/input-validation
copilot

처음 실행할 때, 요청이 오면 인증을 수행하고 디렉토리를 승인합니다. 저장소 내부에서 Copilot을 시작하면 Copilot이 올바른 프로젝트를 작업 컨텍스트(working context)로 갖게 됩니다.

로컬 CLI 세션은 이미 열려 있는 디렉토리와 브랜치를 사용합니다. 만약 나의 메인 체크아웃을 건드리지 않고 유지하고 싶거나 여러 CLI 세션을 병렬로 실행하고 싶다면, 먼저 worktree를 생성하거나 열고 해당 폴더에서 Copilot을 시작합니다.

첫날부터 반드시 익혀두어야 할 명령어가 하나 있습니다: copilot init입니다. 저는 저장소(repository) 루트에서 이 명령어를 실행한 뒤, 생성된 지침(instructions)을 검토하고 플레이스홀더(placeholders)를 저장소의 목적, 중요한 디렉토리, 신뢰할 수 있는 검증 명령어, 제약 사항, 그리고 작업이 완료되기 전 필요한 증거(evidence)로 교체합니다. 그런 다음 검토된 파일을 커밋하여 향후 세션과 팀원들이 동일한 컨텍스트(context)를 공유할 수 있도록 합니다.

엔지니어링 지식을 적절한 위치에 배치하기

이 시점에서 Copilot은 코드를 읽고 수정할 수 있습니다. 하지만 팀이 어떻게 일하는지는 여전히 알지 못합니다. 저장소 가이드(repository guidance)가 없다면, Copilot은 아키텍처(architecture), 신뢰할 수 있는 명령어, 중요한 제약 사항, 그리고 무엇이 "완료(done)"를 의미하는지를 추론해야만 합니다.

저는 모든 세션이 이 지식과 함께 시작될 수 있도록 해당 지식을 코드와 함께 저장합니다. 기존 저장소의 경우, copilot init으로 생성된 지침으로 시작하여 에이전트(agent)에게 무엇이 필요한지 발견함에 따라 이를 개선해 나갑니다. 새로운 프로젝트의 경우, 제가 만든 agentic-engineering template을 사용하여 스택(stack)과 팀에 맞게 조정할 수 있는 더 완전한 시작점을 제공합니다.

템플릿은 다음과 같은 구조를 사용합니다:

.
|-- AGENTS.md
|-- .github/
...