VS Code에서 GitHub Copilot을 활용해 Agent 기반 개발을 하려면, 먼저 Copilot을 활성화하고 로그인한 뒤 /init으로 프로젝트 지침 파일을 만들고, 그 다음부터는 Ask·Edit·Agent 역할을 구분해 쓰는 방식이 가장 안정적입니다. Copilot의 Agent mode는 여러 파일을 스스로 탐색하고 수정 제안, 터미널 명령 제안, 반복 보정까지 수행할 수 있어 초기 구조 설계나 다중 파일 수정에 특히 강점이 있습니다.
개념 이해
GitHub Copilot의 Agent mode는 단순 자동완성 수준이 아니라, 작업 목표를 바탕으로 어떤 파일을 바꿔야 하는지 판단하고 코드 변경과 터미널 명령을 제안하며, 문제를 다시 고치는 흐름까지 수행하는 방식입니다. 그래서 “함수 하나 추천받기”보다 “기능 하나 구현하기”, “버그 한 묶음 수정하기”, “리팩터링 범위 정리하기” 같은 작업에 더 잘 맞습니다.
VS Code 쪽 customization 문서에서도 AI 활용을 단순 채팅이 아니라 프로젝트 규칙, 반복 작업, 외부 도구 연결, custom agent까지 확장하는 구조로 설명합니다. 즉, Copilot을 잘 쓰려면 단순히 설치하는 것보다 “프로젝트 문맥을 AI에게 어떻게 알려줄 것인가”가 실제 생산성을 좌우합니다.
초기 셋팅 방법
가장 먼저 VS Code 상태 표시줄의 Copilot 아이콘에서 Use AI Features를 선택하고 GitHub 계정으로 로그인하면 Copilot을 사용할 수 있습니다. 이미 구독이 연결된 계정이면 그대로 사용되고, 계정이나 프로필별로 다른 Copilot 계정을 연결하는 것도 가능합니다.
프로젝트를 연 뒤에는 채팅에서 /init을 실행하는 것이 좋습니다. 이 명령은 코드베이스를 분석해서 .github/copilot-instructions.md 파일을 생성하며, 이후 Copilot이 해당 저장소의 코딩 스타일과 작업 관례를 더 잘 따르도록 돕습니다.
실무에서는 여기서 끝내지 말고 아래 구조까지 바로 잡아두는 편이 좋습니다. VS Code는 프로젝트 공통 규칙용 파일과 특정 폴더·파일 유형별 규칙 파일을 함께 쓸 수 있다고 안내합니다.
.github/
copilot-instructions.md
instructions/
backend.instructions.md
frontend.instructions.md
sql.instructions.md예를 들어 copilot-instructions.md에는 저장소 개요, 빌드/테스트 방법, 브랜치 전략, 금지 패턴을 넣고, sql.instructions.md에는 MSSQL naming convention, schema prefix 규칙, view 작성 원칙 등을 분리하면 Agent가 훨씬 덜 헤맵니다. GitHub 문서도 리포지토리 지침 파일에 저장소 목적, 기술 스택, 빌드·테스트·검증 절차, 주요 경로 구조를 넣어 두면 agent가 효율적으로 동작한다고 설명합니다.
추천 운영 방식
실제로는 Ask, Edit, Agent를 섞어 쓰기보다 역할을 나눠 쓰는 방식이 안정적입니다. 한 국내 사용 경험 글에서도 새 기능이나 여러 파일에 걸친 변경은 Agent mode로 처리하고, 이후 개별 파일 단위 버그 수정이나 세부 보완은 Edit mode로 전환하는 방식을 추천합니다.
권장 흐름은 아래처럼 가져가면 좋습니다. 이 방식은 특히 Azure, API, ETL, dbt, Power BI 같은 여러 산출물이 동시에 움직이는 프로젝트에서 효과가 큽니다.
- Ask 모드에서 요구사항 정리, 설계안 초안, 변경 범위 도출.
/init과 instruction 파일로 저장소 규칙 주입.- Agent 모드에서 “여러 파일을 건드리는 작업” 실행, 예를 들어 API 추가, 데이터 모델 리팩터링, 테스트 생성.
- Edit 모드에서 개별 파일 정리, naming 보정, 성능 미세조정, 주석·문서화 수행.
- 마지막으로 사람이 diff, terminal command, 테스트 결과를 검토하고 merge 여부를 판단. Copilot은 명령과 변경을 제안하지만 승인과 검증은 사용자가 해야 합니다.
예시로 이런 식의 프롬프트가 좋습니다.
- “이 저장소는 Node.js 20, pnpm, MSSQL을 사용합니다. 주문 집계 API를 추가해 주세요. 변경 범위는
src/api,src/services,tests로 제한하고, 기존 repository pattern을 유지해 주세요. 완료 후 테스트 명령도 제안해 주세요.” - “Power BI용 mart 테이블을 위한 SQL view를 수정해 주세요.
sales,dim_date,dim_customer를 사용하고, 기존 naming convention과 nullable 정책을 따르며, breaking change가 있으면 먼저 알려 주세요.”
방향성
핵심 방향성은 Copilot을 “대신 개발해 주는 도구”가 아니라 “문맥을 먹여주면 빠르게 초안을 만들고 반복 수정해 주는 pair programmer + junior agent”로 보는 것입니다. GitHub와 VS Code 문서 모두 custom instructions, prompt files, custom agents, MCP 서버 같은 확장 구조를 강조하는데, 이는 결국 AI가 프로젝트 맥락 없이 잘 동작하지 않기 때문입니다.
특히 팀 단위에서는 다음 방향이 좋습니다.
- 저장소 공통 규칙은
.github/copilot-instructions.md에 고정. - 도메인별 규칙은 file-based instructions로 분리, 예를 들면 backend, frontend, infra, SQL.
- 반복 작업은 prompt 파일로 표준화, 예를 들면 “PR 설명 생성”, “테스트 보강”, “breaking change 점검”.
- 외부 시스템 연동이 많다면 MCP 서버를 검토, VS Code는 데이터베이스·API 등 외부 도구 연결용으로 MCP를 지원한다고 안내합니다.
이 구조를 잡아두면 Agent가 매번 저장소를 새로 해석하느라 시간을 쓰는 일이 줄고, 출력 품질도 점점 균일해집니다. 특히 monorepo 환경에서는 parent repository customization 탐색 기능도 있어, 하위 폴더만 열어도 상위 리포지토리의 customization을 가져오게 설정할 수 있습니다.
유의사항
가장 큰 유의사항은 Agent가 “그럴듯하게” 움직여도 항상 맞는 것은 아니라는 점입니다. GitHub Copilot Agent 관련 연구에서는 라이브러리 마이그레이션에서 API 변경은 상당히 수행했지만, 실제 기능 유지와 테스트 통과율은 낮게 나타난 사례도 보고되었습니다.
또 다른 연구와 가이드성 자료들은, Agent 성능이 입력 품질에 크게 좌우되며 잘 된 이슈나 지시문은 짧고 범위가 명확하며 관련 파일과 구현 힌트를 포함하는 경향이 있다고 설명합니다. 즉 “대충 시켜도 알아서 해주겠지”보다 “목표, 범위, 제약, 검증 방법”을 함께 주는 편이 훨씬 낫습니다.
실무에서 특히 조심할 부분은 아래와 같습니다.
- 승인 없는 터미널 명령 실행을 습관적으로 허용하지 않기, Agent는 터미널 명령도 제안합니다.
- 테스트와 lint를 프롬프트에 명시하기, 예를 들면 “완료 후
npm test와pnpm lint기준으로 수정”. - 큰 작업은 한 번에 던지지 않고 범위를 끊기, 예를 들면 “인증 모듈 개선”보다 “토큰 refresh 로직만 수정”.
- 설정 파일, CI/CD, 인프라 코드는 더 엄격히 리뷰하기, AI agent의 CI/CD 변경은 별도 검토가 특히 중요합니다.
- 개인정보, 비밀키, 운영 접속 정보는 instruction 파일에 직접 넣지 않기, customization은 문맥 공유용이지 비밀 저장소가 아닙니다.
장단점
아래처럼 이해하시면 현실적입니다.
| 항목 | 내용 |
| 장점 | 다중 파일 수정, 기능 초안 생성, 반복 리팩터링, 테스트 코드 생성 속도를 높일 수 있습니다. |
| 저장소 지침과 규칙을 주입하면 팀 코딩 스타일에 더 맞는 결과를 얻을 수 있습니다. | |
| 계정·워크스페이스·프로필별로 분리 운영이 가능해 개인/회사 환경을 나누기 좋습니다. | |
| 단점 | 코드가 돌아가는 것처럼 보여도 테스트 실패, 숨은 회귀, 설계 불일치가 생길 수 있습니다. |
| 프롬프트 품질이 낮으면 탐색 범위가 넓어지고 이상한 파일을 건드릴 가능성이 커집니다. | |
| 세밀한 아키텍처 판단, 보안, 데이터 정합성, 성능 튜닝은 결국 사람이 책임져야 합니다. |
조금 쉽게 비유하면, Copilot Agent는 “일 잘하는 인턴”에 가깝습니다. 문맥과 규칙을 잘 주면 엄청 빠르지만, 검토 없이 바로 운영 반영할 수준으로 믿으면 사고가 날 수 있습니다.
실전 적용 팁
질문하신 주제가 “초기 셋팅 방법과 방향성”인 만큼, 처음부터 아래 5가지는 꼭 잡아두시는 편이 좋습니다.
- 프로젝트를 열자마자
/init실행. .github/copilot-instructions.md에 빌드, 테스트, 실행, lint, 폴더 구조, 금지사항 기록.- Agent에 작업 요청할 때 변경 범위와 성공 조건을 반드시 명시.
- 새 기능은 Agent, 미세 수정은 Edit로 분리.
- 결과물은 반드시 diff, terminal command, test result까지 사람이 확인.
예를 들어 데이터 프로젝트에서도 충분히 응용 가능합니다. “Azure Data Factory 파이프라인 JSON 수정”, “dbt model naming 정리”, “MSSQL view 생성”, “Power BI semantic layer용 SQL 초안 생성” 같은 작업은 Agent 친화적이지만, 데이터 품질 규칙과 배포 순서는 instruction 파일에 명확히 적어두는 편이 좋습니다.
놓치면 아쉬운 추천 글, 함께 읽어보세요!
- 추천 글을 불러오는 중입니다...
