목차

• 서론
• 실험 계획
  • 비용 고려 사항
• Copilot 코딩 에이전트 테스트
  • 코드 리뷰 (Code review) 코멘트
  • 중간 개선 사항
  • 우리의 페인 포인트 (Pain points)
  • 성능 고려 사항
  • 주요 시사점
• 리소스
• 결론

서론

이 블로그 포스트는 AI가 어떻게 나의 업무를 증강(Augmenting)하고 있는지, 그리고 그 과정에서 무엇을 배우고 있는지를 공유하는 시리즈의 일부입니다. 관심이 있으시다면 두 번째 포스트를 여기서 읽어보실 수 있습니다: AI를 통한 코드 리뷰 개선에서 얻은 교훈.
해당 포스트에서 저는 우리가 코드 리뷰를 위해 AI를 어떻게 도입하고 있는지 언급했습니다. 이번 포스트는 GitHub Copilot 코딩 에이전트가 우리 팀의 요구 사항에 어떻게 부합할 수 있는지 확인하기 위해 우리가 어떻게 실험했는지에 대한 심층 분석입니다. 솔직히 말하자면, 우리는 Claude Code를 훨씬 더 많이 사용하고 있으며, 그것이 우리가 집중하고 도입한 도구입니다. 하지만 그 내용은 이 시리즈의 별도 블로그 포스트에서 다룰 예정입니다 😆.

우리의 접근 방식은 간단했습니다: 무엇이 효과적인지 배우기 위해 실험하는 것입니다. 우리는 여전히 배우고 개선하는 중이지만, 이러한 도구들을 더 많이 사용하고 최적화할수록 팀으로서 더 많은 레버리지(Leverage)를 얻게 됩니다. 자세한 내용을 살펴보겠습니다.

실험 계획

좋습니다... 이제 우리 모두 Copilot 코딩 에이전트에 대해 들어보셨을 겁니다. 아마 GitHub의 기조 연설(Keynote)과 2026년 1분기 로드맵 웨비나에서 이 에이전트가 그들의 코드베이스에서 1위 기여자라는 이야기를 들어보셨을 것입니다.

글쎄요... 저에게 이것은 Anthropic의 CEO인 Dario가 했던 "3~6개월 안에 AI가 코드의 90%를 작성할 것이다"라는 발언과 똑같이 들립니다. 그들에게 그것이 효과가 있다면 다행이고, 그들이 이러한 슬라이드와 발언들에 마케팅 예산과 전략을 쏟아부을 수 있다면 그것도 좋은 일입니다. 하지만 그것은 제가 신경 쓰는 지표가 아닙니다. 코드의 90%를 작성하기 위해 키보드를 직접 입력하지 않아도 된다는 점은 괜찮지만, LOC(Lines of Code, 코드 라인 수)를 측정하는 것은 저에게 전혀 의미가 없습니다. 그것은 병합된 코드의 품질이나 도입된 버그 등에 대해 아무것도 말해주지 않습니다. 제 생각에 그것은 하이프(Hype, 과장된 광고)에 기반한 발언들입니다 🤣.
그럼에도 불구하고, 제 마음속에는 다음과 같은 질문이 남습니다. 코딩 에이전트(Coding agents)가 효과적으로 작동하며 고품질의 PR(Pull Request)을 생성할 수 있을까?

우리는 이 질문에 답하기 위해 GitHub Copilot 코딩 에이전트와 Claude Code를 사용하여 꽤 많은 실험을 진행해 왔습니다. 어쩌면 우리는 키보드 타이핑의 대부분을 프롬프팅(Prompting)으로 대체할 수 있을지도 모릅니다. 우리의 목표는 GitHub와는 전혀 다릅니다. 우리는 팔 물건이 없으니까요... 그들은 있죠 😅. 우리의 동기는 우리가 일하는 방식을 계속 개선하고 실제 고객들에게 가치를 전달하는 것입니다. 그래서 제가 GitHub Copilot 코딩 에이전트로 무엇을 했고 무엇을 실험했는지 공유하고자 합니다 🙂.

우리는 사용량 기반 과금 체계로의 변경이 있기 전에 이 계획을 세웠습니다. 8월에 아직 70%의 프리미엄 토큰이 남아 있었고, 이것은 매달 초기화되기 때문입니다. 우리는 다음과 같이 생각했습니다:

코딩 에이전트 실험에 엄청나게 쏟아붓지 않을 이유가 없지 않을까 😄! 그래서 우리는 실행에 옮겼습니다 😆. 우리의 접근 방식은 다음과 같았습니다:

• 다음 릴리스를 위해 우선순위가 지정된 작업 1개를 선정하여 코딩 에이전트(coding agent)에게 할당
• 완료하고자 하는 다른 백로그 항목 또는 일반 작업, 일부 버그 수정(bugfixes), 또는 코드 개선 사항 1개를 선정
• 모든 작업을 코딩 에이전트에게 할당 (대부분은 Copilot을 사용하고, 나머지는 Claude third-party agent에 할당)
• 다른 작업을 수행한 뒤, 잠시 후 PR(Pull Requests)을 검토
• 프리미엄 토큰 사용량 + PR 수 + 출력 품질 + 댓글 수에 대해 보고
• 다음 달에 더 많은 작업을 가지고 사이클을 다시 시작

다시 말씀드리지만, 우리의 목표는 무엇이 효과적인지 배우기 위해 실험하는 것이었습니다. 우리는 이 실험을 2025년 8월, 몇몇 다른 달, 그리고 (주로 많은 개선 사항이 도입되었기 때문에) 2026년 3월에 다시 수행했습니다. 우리의 초점은 다른 third-party agent가 아니라 Copilot에 있었다는 점을 유의하는 것이 중요합니다. 우리는 Codex를 사용하지 않았으며, 이번 실험의 일부 작업에만 Claude를 사용했습니다.

비용 고려 사항

우리는 비용에 대해 많이 분석하거나 고민하지 않았습니다. 목표는 실험을 통해 다양한 작업에 대한 PR의 품질을 확인하는 것이었습니다. 하지만 billing change가 필요한 변화였다는 점은 말씀드릴 수 있습니다. 우리는 프리미엄 요청(premium request) 1회 비용이 들지 않아야 할 작업에서 59분 타임아웃(timeout)에 도달하거나, 해당 비용으로 매우 많은 도구 호출(tool calls)을 받는 등의 상황을 겪었습니다. 예시는 다음과 같습니다:

프롬프트 (Prompt)	master 브랜치 대비 변경 사항	출력 (Output)
이 브랜치에서 수행된 모든 작업을 master 브랜치와 비교하여 검토하고, 사용 가능한 모든 기술을 동원해 철저한 코드 리뷰 (code review)를 수행해 주세요. 버그에 집중한 뒤 코드 품질도 확인하세요. 각기 다른 관점과 목표를 가진 여러 개의 서브 에이전트 (subagents)를 사용하세요.	약 47,300개 추가 및 약 11,000개 삭제	59분 타임아웃 (timeout) 발생으로 오류 발생. 4개의 서브 에이전트 사용. "prompt token count of 530706 exceeds the limit of 64000" 메시지와 함께 model_max_prompt_tokens_exceeded 오류 발생
함수 X의 메모리 소비를 개선하세요. 수락 기준: 처리되는 항목의 양에 관계없이 메모리가 Y를 초과해서는 안 됩니다.	약 900개 추가 및 약 40개 삭제	53분 만에 성공

엔지니어들이 프리미엄 요청 한 번을 위해, 혹은 Claude Code 구독료 20달러를 위해 엄청난 양의 추론 (inference) 비용을 사용하는 모습을 이미 많이 보셨을 겁니다 😅. 어쨌든, 만약 우리가 6월에 Copilot 코딩 에이전트 (Copilot Coding agent)를 도입한다면, GitHub Actions 사용 시간 (minutes)과 전체 토큰 (token) 사용량을 제어하기 위한 더 많은 통제 수단이 필요할 것이며, 비용 대비 편익 (cost-benefit)을 재평가해야 할 것입니다.

Copilot 코딩 에이전트 테스트

우리가 얻은 결과의 근사치를 공유하겠습니다:

작성자 (Author)	PR 수	머지 (Merged)	머지율 (Merge rate)
Copilot 코딩 에이전트	~130	~30	~23%
...
크기 (변경 라인 수)	Copilot/Claude PR
---	---
S (10-49)	~12
...

다시 말씀드리지만, 이것은 주로 실험적인 성격이므로 머지율 (merge rate)이 매우 낮을 것으로 예상됩니다. Copilot 코딩 에이전트의 많은 PR은 스파이크 (spikes)/탐색 목적이었거나, PRD를 분석하거나 보안 리뷰 (security reviews)를 수행하기 위해 GitHub 커스텀 에이전트 (custom agents)를 사용하는 용도였습니다.

Copilot이 저에게 리뷰를 요청했을 때의 PR (Pull Request) 품질에 대해 이야기해 보겠습니다. 무엇보다도, 저는 우리가 다른 성공적인 소프트웨어 팀들과 비교했을 때 품질 높은 PR에 대한 기준이 높지 않다고 생각합니다. 저에게 있어 고품질의 PR은 언제나 당연히 기대되는 것입니다. 둘째로, 제가 작성했거나 다른 엔지니어들이 작성한 많은 초안 PR (draft PRs)은 보통 v0 단계입니다. 이는 팀 내 엔지니어들로부터 피드백을 받기 위해 게시하는 버전일 뿐, 실제로 머지 (merge)될 준비가 된 상태는 아닙니다. Copilot이 생성하는 모든 PR은 초안 (drafts) 상태로 생성되는데, 저에게 이것은 Copilot이 모든 것을 완료했고 모든 것이 잘 작동한다고 말할지라도 실제로는 단지 v0를 수행했다는 신호로 느껴집니다. 현재 제 생각으로는, 이것은 사용자가 Copilot의 구현 과정을 다시 가이드하고 잘못된 부분을 찾아내기 위한 초기 코드 리뷰 (code review)를 할 기회를 주기 위해 의도적으로 만들어진 것입니다.

제 주장을 뒷받침하는 GitHub의 문서나 공식 성명을 본 적은 없습니다. 그렇긴 하지만, 저는 Copilot이 PR에 대해 계속해서 반복 작업 (iterating)을 수행하고, 더 이상 초안 상태가 아닐 때만 저에게 리뷰를 요청할 수 있는 옵션이 있었으면 합니다. 하지만 이 코딩 에이전트 (coding agent)는 현재까지의 마케팅과 문서가 소규모 및 중규모 작업에 집중되어 있기 때문에, 그런 방향으로 진화하지 않을 수도 있습니다. 또한, 장시간 실행되는 에이전트 (long-running agents)의 경우 비용 제어 (cost control)도 매우 중요해집니다.

상황을 단순화하기 위해, 저에게 리뷰를 요청하는 것을 다른 엔지니어가 저에게 자신의 PR을 리뷰해 달라고 요청하는 것과 같다고 가정해 보겠습니다. 우리 팀의 (또는 일반적으로 세상의) 어떤 엔지니어도 PR이 준비되고, 작업이 완료되었으며, 스스로 자신의 작업을 테스트하고 리뷰한 후에야 동료에게 리뷰를 할당합니다. 지금까지의 실험 결과로 볼 때, Copilot은 대부분의 PR에서 준비가 완료되고 다듬어진 PR을 내놓지 못했기 때문에, 저는 수많은 잘못된 부분들에 대해 많은 코멘트 (comments)를 남겨야 했습니다. 문제 중 하나는 피드백 루프 (feedback loop)입니다. 저희는 프론트엔드 로그인 흐름에 제한 사항이 있어 Playwright MCP를 제대로 활용하지 못했습니다. 그래서 에이전트가 프론트엔드 작업을 위한 필요한 코드를 제공하지 못하고 있습니다.

코드 리뷰 코멘트 (Code review comments)

제가 남긴 코멘트의 관점에서 보면, PR(Pull Request)을 리뷰 준비 완료 상태로 표시하기 전 CCR 및 Claude Code와 함께 남긴 코멘트는 약 2030개 정도입니다. 머지(Merge)된 것들은 보통 코멘트가 20개 미만이었으며, 대부분의 논의는 치명적이거나 저품질 코드에 관한 것이 아니었습니다. 다시 말씀드리지만, 이들은 대부분 명확하게 정의된 저중급 난이도의 작업이었으며 에이전트가 잘 수행해냈습니다. 반면, 여러 가지 이유로 인해 종료된(closed) PR들과 몇몇 실험들은 40개 이상의 코멘트를 받았습니다.

• 불필요한 테스트 케이스 (Test cases)
• 특정 모듈 및 함수의 재구현 (Re-implementation) 필요
• 기존 기능 삭제
• 저품질 코드 및 코딩 표준(Coding standards) 및 베스트 프랙티스(Best practices) 미준수 (예: 많은 중복 코드, 에러 핸들링(Error handling) 누락)
• 프론트엔드 구현 누락
• 존재하지 않는 CSS 클래스 사용

종료된 것들 중 단순한 실험이었던 것들은 리뷰를 많이 받지 않았습니다. 이것이 실험 측면에서 아주 좋은 결과는 아니라는 점은 이해하지만, 저희는 모든 PR에 동일한 시간을 투자하기보다 일부 PR에 더 많은 시간을 투자했습니다. 다시 말하지만, 일부는 단순히 스파이크(Spike) 작업이거나 의도적으로 과하게 진행된 것들입니다.

물론 이것이 저희 팀 자체의 PR과 동일한 것은 아닙니다. 왜냐하면 이러한 초안 PR(Draft PR)들은 약 15분 내외로 작성되기 때문입니다. 하지만 이러한 초안 PR이 다른 사람(그리고 Copilot 자체, Claude, CodeRabbit과 같은 AI 도구들)에 의해 리뷰될 준비가 되기 위해 필요한 코멘트의 수는 중요합니다. 제가 코드를 리뷰하는 데 시간을 쓰고 있기 때문입니다. 오타가 남아있거나 수락 기준(Acceptance criteria)이 완전히 충족되지 않았을 때 방해받고 싶지는 않으니까요 😅.

중간 단계의 개선 사항 (Improvements mid-way)

Copilot 코딩 에이전트가 잘 수행하지 못했던 기능들이 있었고, 이것이 저에게 명확화 질문을 요청하는 방법을 문의하도록 만들었습니다. 현재 에이전트 대시보드는 훨씬 좋아졌으며, 우리는 이 유형의 계획 수립으로 시작하여 명확화 질문도 하도록 만들 수 있습니다. 저는 이것을 몇 번만 실험해 보았는데, 주로 GitHub 이슈에 더 많은 컨텍스트와 세부 정보를 추가하기 시작했고, 또한 방향 전환(steering)이 프리미엄 요청 비용이 더 많이 들기 때문입니다. 이는 Cursor의 [

GitHub은 또한 코딩 에이전트가 Copilot 코드 리뷰를 사용할 수 있는 기능과 CodeQL을 실행하는 기능을 출시했습니다. 이는 매우 훌륭합니다. 일부 이슈가 휴먼 리뷰어(human reviewer)에게 도달하는 것을 방지함으로써 우리의 고충(pain points) 중 일부가 해결되었기 때문입니다. 하지만... 우리가 실험하고 확인한 PR(Pull Requests)들에 대해서는 여전히 문제점과 의견들이 있었으므로, 이제 그것들을 살펴보겠습니다 🙂.

우리의 고충 (Our pain points)

테스트 (Tests)