
GitHub Copilot 제대로 쓰는 법, 프롬프트가 전부다
처음 GitHub Copilot 붙였을 때 "이게 뭘 해주는 거지?"라고 생각했다. 자동완성이 좀 더 똑똑해진 것 같은데, 딱히 생산성이 올라가는 느낌이 없었다. 그러다 프롬프트를 제대로 써보니 달랐다. 쓰는 방식이 결과를 바꾼다.

Copilot Chat을 제대로 쓰려면

역할을 줘라
Chat에서 단순히 "이 코드 리뷰해줘"보다 "Senior Backend Engineer로서 성능과 보안을 중심으로 이 코드 리뷰해줘"가 결과가 다르다. 역할을 명시하면 응답의 관점이 달라진다.
# 이렇게만 쓰면
"이 함수 개선해줘"
# 이렇게 쓰면 다르다
"Node.js 성능 최적화 전문가 입장에서,
이 함수의 메모리 사용과 비동기 처리 방식을 개선해줘"

/init으로 프로젝트 문맥 만들기
VS Code에서 Copilot Chat 열고 /init을 치면 현재 프로젝트 구조를 분석해서 커스텀 인스트럭션을 생성해준다. 이게 꽤 유용한데, 이후 Copilot이 프로젝트 맥락을 더 잘 이해하고 제안을 준다. 새 프로젝트 시작할 때 바로 해두면 좋다.
Copilot Spaces로 문맥 공유
팀에서 쓴다면 Copilot Spaces 기능이 있다. 관련 파일, 문서, 컨텍스트를 묶어두면 팀원 모두가 같은 맥락으로 Copilot과 대화할 수 있다. 아직 프리뷰지만 대규모 프로젝트에서 쓰면 일관된 답변을 받는 데 도움이 된다.
코딩 에이전트 기능, 이제 자동화가 된다
Copilot Coding Agent는 그냥 제안이 아니라 자율적으로 코드를 짜고 PR까지 올린다. GitHub Issues에 할당하면 브랜치 만들고, 코드 짜고, 커밋하고, PR 열고, 설명까지 써준다.
솔직히 처음엔 반신반의했는데, 간단한 기능 추가나 버그 수정은 생각보다 잘 한다. 물론 복잡한 비즈니스 로직이나 아키텍처 결정은 여전히 사람이 해야 한다. "PR 올리고 직접 코딩하는 단계를 에이전트가 처리한다"는 표현이 맞다.
인라인 제안 잘 받는 팁
주석을 구체적으로 쓰라
Copilot은 주석을 보고 코드를 예측한다. 막연한 주석보다 구체적인 주석이 훨씬 좋은 제안을 끌어낸다.
// 사용자 데이터 처리 (X)
// PostgreSQL에서 사용자 ID로 조회, 없으면 null 반환,
// 에러 시 throw UserNotFoundError (O)
파일 상단에 컨텍스트 남기기
파일 최상단에 주석으로 해당 파일의 역할, 사용 패턴, 제약사항을 써두면 Copilot이 일관된 스타일로 제안한다. 귀찮아 보이지만 한 번 써두면 계속 쓸 수 있다.
한계도 솔직하게
Copilot이 틀린 코드를 자신있게 제안하는 경우가 있다. 특히 최신 라이브러리 버전의 API나 레거시 코드가 섞인 상황에서. 무조건 받아쓰면 안 된다. 제안을 검토하는 시간이 코드를 직접 짜는 시간과 비슷해질 수 있다.
그래도 "어떻게 시작해야 하나" 막히는 순간에 방향을 잡아주는 건 확실히 한다. 첫 줄의 저항감을 낮춰주는 도구로 쓰면 효과적이다.
결론
Copilot을 단순한 자동완성 도구로 쓰면 그냥 편리한 정도다. 역할 부여, 프로젝트 컨텍스트 설정, 구체적인 주석 같은 것들을 제대로 활용하면 생산성 차이가 난다. 결국 AI 도구도 잘 쓰는 법을 배워야 한다는 게 2026년에도 변하지 않는 사실이다.
📎 참고 자료
'github' 카테고리의 다른 글
| GitHub Copilot 코딩 에이전트 업데이트, 이제 진짜 써볼 만해졌다 (0) | 2026.03.28 |
|---|---|
| GitHub 보안 스캐너에 AI 붙이기로 했다, 실제로 뭐가 달라지나 (1) | 2026.03.28 |
| GitHub Copilot이 Jira에서 직접 코드 짜준다, Confluence까지 연동됐다 (0) | 2026.03.27 |
| GitHub Spark 써봤는데, 생각보다 쓸만했다 (0) | 2026.03.26 |
| GitHub Code Security에 AI 탐지가 붙었다, PR에서 바로 취약점 잡아준다 (0) | 2026.03.26 |