솔직히 고백하면, 저는 처음에 GitHub Copilot을 그냥 자동완성 도구 정도로만 생각했습니다. 그런데 사내 디자인 토큰 자동화 외주를 맡으면서 생각이 완전히 바뀌었습니다. 디자이너가 직접 스크립트를 짤 수 있도록 Copilot을 가르쳐야 했는데, 그때서야 이 도구가 단순한 코드 보조가 아니라는 걸 체감했습니다.
코드를 처음 보는 사람도 이해할 수 있는 이유
새 프로젝트를 열면 가장 먼저 하는 질문이 있습니다. "이 코드가 도대체 뭘 하는 건가?" 저도 외주를 받을 때마다 이 벽에 부딪혔습니다. Copilot Chat 사이드 패널에 "이 애플리케이션의 목적, 구조, 핵심 컴포넌트가 뭔가요?"라고 물으면, 전체 프로젝트를 스캔해서 기능 요약과 사용 중인 NuGet 패키지, 주요 클래스 목록까지 한 번에 정리해 줍니다.
여기서 NuGet 패키지란 .NET 생태계에서 사용하는 외부 라이브러리 묶음을 의미합니다. 쉽게 말해 개발자가 처음부터 짜지 않아도 되는 기성 기능 모음집입니다. Copilot은 이 패키지 목록을 보고 어떤 기술 스택이 쓰였는지도 함께 설명해 줍니다.
제가 직접 써봤는데, 특히 유용했던 부분은 클래스나 메서드 위에 커서를 올리면 나타나는 "Describe with Copilot" 옵션이었습니다. SQLite를 비동기로 다루는 서비스 클래스가 있었는데, 주석 하나 없는 코드였음에도 Copilot이 초기화 흐름과 데이터 조회 패턴을 정확하게 설명해 줬습니다. 코드 리터러시(code literacy)가 부족한 디자이너도 이 기능을 통해 코드의 역할을 파악할 수 있었습니다. 코드 리터러시란 코드를 직접 짜는 능력이 아니라 코드를 읽고 맥락을 파악하는 능력을 뜻합니다.
제가 디자이너 3명에게 Copilot을 소개할 때 가장 먼저 가르친 것도 바로 이 코드 이해 기능이었습니다. 첫 주에 세 명 모두 자체 토큰 변환 스크립트를 작성하는 데 성공했는데, Copilot Chat이 없었다면 불가능했을 일입니다.
GitHub의 자체 조사에 따르면 Copilot을 사용하는 개발자는 코드 작성 속도가 평균 55% 향상되었다고 합니다(출처: GitHub Research).
디버깅할 때 진짜 달라지는 점
디버깅 중에 Copilot이 얼마나 유용한지는 직접 겪어봐야 압니다. 저는 솔직히 이 부분이 예상 밖이었습니다. 예외(Exception)가 터졌을 때 단순히 오류 메시지만 보는 게 아니라, 콜 스택과 로컬 변수 값을 함께 붙여서 Copilot에 물어볼 수 있습니다.
여기서 콜 스택(Call Stack)이란 어떤 함수가 어떤 함수를 호출했는지 순서대로 기록한 목록입니다. 오류가 어느 경로를 타고 발생했는지 역추적하는 데 필수적인 정보입니다. Visual Studio에서는 이 콜 스택과 로컬 변수를 한 번에 Copilot에 전달해서 "지금 이 예외가 왜 발생했는지, 어떻게 막을 수 있는지" 물어볼 수 있습니다.
제 경험상 이건 좀 다릅니다. 예전에는 스택 오버플로우를 뒤지거나 동료에게 물어봐야 했던 시간이, 이제는 그 자리에서 바로 해결 방향을 잡을 수 있게 됐습니다. 특히 "ounces 값이 0일 때 ArgumentException이 발생한다"는 식으로 현재 상태를 분석해서 사전 유효성 검증 코드까지 제안해 주는 부분은 꽤 인상적이었습니다.
Copilot Edits 모드를 쓰면 단순 채팅을 넘어서 여러 파일을 한 번에 수정하는 것도 가능합니다. 예를 들어 "편집 커피 페이지에 삭제 버튼을 추가하고, 뷰 모델과 데이터베이스 서비스도 함께 업데이트해 줘"라고 명령하면 변경 계획을 먼저 보여준 뒤, 각 파일의 diff(변경 사항 비교)를 확인하고 수락하거나 거부할 수 있습니다. 여기서 diff란 원본 코드와 수정된 코드의 차이를 줄 단위로 보여주는 비교 화면을 말합니다.
실무에서 이 기능을 쓰면서 느낀 한 가지 한계도 솔직하게 말씀드리면, Copilot이 네임스페이스(namespace)를 빠뜨리는 경우가 간헐적으로 있었습니다. 완성도가 90% 이상이라서 나머지 10%는 직접 손봐야 하는 상황이 생깁니다. 그래도 처음부터 전부 타이핑하는 것보다 훨씬 빠릅니다.
Copilot이 지원하는 디버깅 관련 핵심 기능을 정리하면 다음과 같습니다.
- 호버 시 "Analyze with Copilot" 버튼으로 현재 객체 상태 분석
- 로컬 변수 창과 와치(Watch) 창에서 Copilot 질의 가능
- 예외 발생 직후 "Ask Copilot" 버튼으로 전체 콜 스택 기반 원인 분석
- 분석 결과를 채팅 창으로 이어 후속 질문 가능
커밋 메시지와 PR 요약까지 자동으로 만들어지는 편의
개발자라면 커밋 메시지 쓰는 게 귀찮다는 걸 다들 알 것입니다. 저도 외주 프로젝트가 많을수록 커밋 메시지가 점점 "fix", "update" 같은 무의미한 단어로 채워지기 시작했습니다. Copilot은 변경된 파일 전체를 분석해서 커밋 메시지를 자동으로 생성해 줍니다.
더 유용한 건 커스텀 지침을 설정할 수 있다는 점입니다. Visual Studio 설정에서 "첫 줄은 변경 요약, 이후는 이모지가 붙은 불릿 리스트, 마지막에 서명 추가"처럼 구체적인 형식을 지정해 두면, 이후 커밋마다 그 형식을 따라줍니다. 저는 제 이니셜로 서명을 자동 삽입하도록 해뒀는데, 클라이언트에게 납품하는 커밋 히스토리가 훨씬 읽기 쉬워졌습니다.
PR(Pull Request) 요약도 자동화가 됩니다. 여기서 Pull Request란 변경된 코드를 메인 브랜치에 합치기 전에 팀원이 검토하도록 요청하는 절차를 말합니다. Copilot은 PR을 열 때 변경 내용을 분류해서 요약문을 만들어 줍니다. "신규 기능 추가", "리팩토링", "버그 수정" 같은 분류 태그까지 붙여주기 때문에 코드 리뷰 시간이 단축됩니다.
한 가지 더 눈에 띄었던 건 Mermaid 확장 연동이었습니다. Copilot Chat에서 "@mermaid-chart"를 호출하면 클래스 다이어그램이나 ER 다이어그램을 자동으로 생성해 줍니다. 여기서 ER 다이어그램(Entity-Relationship Diagram)이란 데이터베이스의 테이블 간 관계를 시각적으로 나타낸 구조도입니다. 외주 클라이언트에게 문서를 납품할 때 이걸 README에 삽입하면 코드를 모르는 이해관계자도 구조를 파악할 수 있어서, 저는 지금도 이 방식을 쓰고 있습니다.
Stack Overflow의 2023년 개발자 설문에 따르면 응답자의 55% 이상이 AI 코딩 도구를 이미 사용 중이거나 사용 계획이 있다고 답했습니다(출처: Stack Overflow Developer Survey).
5년 차 프리랜서로서 느끼는 건, Copilot이 코드를 대신 짜주는 도구가 아니라 코드와 사람 사이의 언어 장벽을 낮춰주는 도구에 가깝다는 것입니다. 디자이너가 스크립트를 직접 다루게 되고, 코드 리뷰 커뮤니케이션이 쉬워지고, 문서가 자동으로 만들어지는 흐름이 쌓이면서 외주 클라이언트와의 신뢰도가 달라집니다. 처음부터 모든 기능을 다 쓰려고 하기보다는 코드 이해 질의부터 시작해서 디버깅 분석, 커밋 자동화 순서로 하나씩 적용해 보시길 권합니다. 각 단계마다 체감하는 생산성 차이가 꽤 명확합니다.