코파일럿을 쓰고 있는데 뭔가 아쉽다는 느낌, 저도 처음엔 똑같이 받았어요. 자동완성이 뜨면 Tab 누르고, 아니면 그냥 지나치는 식으로만 쓰다 보면 결국 “그냥 자동완성 좀 빠른 툴” 이상이 안 되거든요. 실제로 코파일럿이 도움이 된다고 느끼는 시점은, 몇 가지 설정을 손보고 쓰는 방식을 바꾼 이후더라고요. 이미 기본 사용법은 아시는 분들을 위해, 현업에서 차이를 만드는 설정과 전략 위주로 정리해 봤습니다.
먼저 손봐야 할 VSCode 설정들
코파일럿은 기본값으로도 돌아가지만, 설정을 조금만 건드리면 제안의 질이 눈에 띄게 달라져요. 제가 실무에서 꼭 바꾸는 항목들을 먼저 짚을게요.
inlineSuggest.enabled와 suggest.preview 분리 이해하기
이 둘을 같은 거라고 생각하는 분이 많은데, 역할이 달라요. editor.inlineSuggest.enabled는 코파일럿의 인라인 제안 자체를 켜고 끄는 스위치고, github.copilot.editor.enableAutoCompletions는 타이핑할 때 자동으로 제안을 트리거할지를 결정해요. 자동 트리거가 너무 잦아서 집중이 흐트러진다면 후자를 false로 바꾸고 단축키(Alt+\)로 수동 호출하는 방식을 써보세요. 필요할 때만 꺼내 쓰는 감각이 생기면 오히려 더 잘 활용하게 됩니다.
언어별로 코파일럿 활성화 범위 조정하기github.copilot.enable 설정은 언어 ID 단위로 켜고 끌 수 있어요. 예를 들어 마크다운 문서 작성 중에는 제안이 오히려 방해가 되는 경우가 있고, 반대로 Python이나 TypeScript 파일에서는 항상 켜두고 싶을 수 있죠. settings.json에서 아래처럼 세팅해두면 됩니다.
"github.copilot.enable": {
"*": true,
"markdown": false,
"plaintext": false
}이렇게 하면 일반 텍스트나 마크다운 편집 중에는 코파일럿이 끼어들지 않아요.
Copilot Chat 패널, 사이드바보다 분리 창이 낫다
Chat 기능을 사이드바에서만 쓰면 코드 보면서 채팅하기가 불편해요. VSCode에서 코파일럿 채팅 탭을 별도 에디터 그룹으로 분리해서 오른쪽에 띄워두는 방식이 훨씬 작업 흐름에 맞더라고요. 드래그로 탭을 끌어서 분리할 수 있고, 이걸 workspace 레이아웃으로 저장해두면 프로젝트 열 때마다 자동으로 배치가 유지됩니다.
제안 품질을 올리는 컨텍스트 관리 전략
코파일럿은 현재 열려 있는 파일들과 커서 주변 코드를 바탕으로 제안을 생성해요. 결국 얼마나 좋은 컨텍스트를 모델에게 주느냐가 제안 품질을 결정하는 핵심이에요.
관련 파일을 에디터에 열어두는 습관
코파일럿은 현재 탭에 열려 있는 파일들을 참조해요. 인터페이스 파일, 타입 정의 파일, 유사한 기능의 구현체를 같이 열어두면 더 프로젝트 스타일에 맞는 제안이 나와요. 실제로 저는 새 서비스 클래스를 작성할 때 비슷한 기존 서비스 파일을 탭에 열어두고 시작하는데, 네이밍 컨벤션이나 에러 핸들링 패턴을 꽤 잘 따라오더라고요.
주석을 ‘명세서’처럼 쓰기
단순히 “// 유저 조회 함수” 수준의 주석이 아니라, 입력·출력·예외 케이스까지 기술한 주석을 먼저 써두고 함수 본문을 비워두면 코파일럿이 그걸 스펙으로 받아들여요. 예를 들어 이런 식이에요.
// 사용자 ID로 활성 구독 목록을 조회한다.
// - userId: string (UUID)
// - 반환: Subscription[] (비어있으면 빈 배열)
// - DB 오류 시 SubscriptionFetchError를 throw
async function getActiveSubscriptions(userId: string) {이렇게 해두면 try-catch 구조, 반환 타입, 에러 클래스까지 상당히 의도에 맞게 채워줘요. 주석이 곧 프롬프트라는 감각으로 접근하면 달라집니다.
.github/copilot-instructions.md 파일 적극 활용하기
비교적 최근에 추가된 기능인데, 저장소 루트에 .github/copilot-instructions.md 파일을 만들어두면 코파일럿 Chat이 해당 저장소 전체의 컨텍스트를 학습해요. 팀 코딩 컨벤션, 사용 중인 프레임워크 버전, 금지 패턴 같은 걸 여기에 적어두면 Chat에서 질문할 때마다 따로 설명 안 해도 됩니다. 팀 프로젝트라면 이 파일을 깃에 커밋해서 공유하는 게 좋아요.
코파일럿 Chat을 코드 리뷰·리팩터링에 쓰는 법
자동완성 외에 Chat을 어떻게 쓰느냐가 숙련도 차이를 만들어요. 단순 질문보다 특정 작업에 맞는 슬래시 커맨드와 패턴을 써야 제대로 활용하는 거예요.
/explain, /fix, /tests 슬래시 커맨드 제대로 활용하기
코드를 선택한 상태에서 Chat에 /explain을 입력하면 해당 코드의 동작을 설명해줘요. 레거시 코드를 인수인계받았을 때 특히 유용해요. /fix는 선택한 코드의 버그나 문제를 찾아서 수정 제안을 줘요. /tests는 선택한 함수에 대한 유닛 테스트 코드를 생성해주는데, 실무에서 테스트 커버리지 올릴 때 꽤 쓸 만합니다. 다만 생성된 테스트가 항상 엣지 케이스를 완벽히 커버하진 않으니, 출력을 기반으로 추가 케이스를 직접 보완하는 방식이 현실적이에요.
리팩터링 요청할 때 기준을 명확히 주기
“이 코드 리팩터링해줘”보다 “이 함수를 단일 책임 원칙에 맞게 분리하고, 중복된 DB 호출을 제거해줘”처럼 기준을 주면 훨씬 실용적인 결과가 나와요. 코파일럿 Chat은 모호한 요청에는 일반적인 답변을 내놓는 경향이 있거든요. 요청이 구체적일수록 결과물이 바로 쓸 수 있는 코드에 가까워집니다.
PR 설명 초안 생성에 쓰기
코파일럿 Chat에 변경된 파일들을 컨텍스트로 주고 “이 변경사항을 PR 설명으로 정리해줘, 변경 이유와 영향 범위 포함해서”라고 하면 꽤 쓸 만한 초안이 나와요. 저는 직접 쓰는 것보다 이 초안을 수정하는 방식으로 바꿨는데, PR 작성 시간이 많이 줄었어요.
팀에서 코파일럿 쓸 때 놓치기 쉬운 것들
개인 생산성 도구로만 쓰면 한계가 있어요. 팀 단위로 세팅이 맞춰져 있어야 일관성이 생기고, 코파일럿이 만든 코드가 팀 코드베이스에 자연스럽게 녹아들어요.
앞서 언급한 copilot-instructions.md 파일 외에도, ESLint나 Prettier 설정이 저장소에 제대로 있으면 코파일럿 제안도 그 규칙을 어느 정도 따라와요. 코파일럿이 생성한 코드가 린트에서 계속 걸린다면, 린트 설정 파일을 명확히 해두는 것부터 다시 점검해보는 게 맞아요.
또 한 가지, 코파일럿이 만들어준 코드를 그냥 머지하는 문화가 생기지 않도록 주의해야 해요. 제안을 받아 쓰더라도 코드 리뷰 기준은 그대로 유지해야 하고, 특히 보안에 민감한 부분(인증, 암호화, 외부 API 호출)은 코파일럿 제안을 더 꼼꼼하게 검증하는 습관이 필요합니다. 편리함과 책임은 같이 가는 거라서요.
코파일럿을 잘 쓰는 팀과 그냥 쓰는 팀의 차이는 결국 ‘어떤 컨텍스트를 주고, 어떤 요청을 하느냐’에서 갈리더라고요. 툴보다 사용하는 방식이 더 중요하다는 게, 여러 프로젝트를 거치면서 느낀 결론이에요.