Github Copilot Agent 사용기

VSCode에서

Github Copilot 설정

설정 과정은 복잡하지 않다.

먼저 Brower로 Github에 Login하여 Copilot Pro에 가입하기: Login을 한 후 오를쪽 위쪽에 나오는 사용자 Icon을 Click하면 "Your Copilot"이라는 메뉴가 나온다. 여기에서 Pro로 Upgrade 하면 된다. 여러 모델들을 무제한으로 사용 가능하면서 한 달에 $10이니 비싸지 않다.

한 달쯤 전에는 Github Copilot의 Agent와 같은 최신 기능을 사용하기 위해서는 VSCode가 아닌 VSCode - Insiders를 사용해야만 했었는데, 어느새 VSCode에서도 Copilot Agent를 사용할 수 있게 되었다. 그럼에도 난 계속 VSCode - Insiders를 사용하고 있다. 하루에 두번 update가 있는 경우가 있을 만큼 매우 빈번하게 update가 일어난다는 불편함(?) - 아주 빠르게 update가 되고, 내가 원할 때 몰아서 해도 되기 때문에 크게 불편하지는 않다 - 만 빼면, "Github Copilot"과 "Github Copilot Chat"과 같은 Extension에서 pre-release version이 기본으로 사용되고 있어서, 뭔가 앞선 기능을 사용할 수 있지 않을까 하는 막연한 기대 - 자세히 알아보지 않았다. - 를 안고 있기 때문이다.

VSCode에서 Github으로 Login을 하면 준비 끝!

Github Copilot Agent Mode

VSCode의 최상단에 Copilot icon을 click 하면 Agent 창이 보인다. 좀 큰 화면 (해상도가 높은) 이 있어야 편집 영역과 Agent 영역을 함께 볼 수 있다. Agent 창을 별도로 분리해서 사용할 수도 있으나 아무래도 작은 화면에서는 좀 불편했다.

Copilot Agent는 Ask, Edit, Agent 이렇게 3가지 mode를 제공하고 있다. 각 mode의 특성을 이해하고 작업 목적에 맞게 사용하는 것이 필요하다.

그리고 중간에 Edit <=> Agent 로 mode를 바꾸게 되면 기존 session이 종료되면서 그간의 context를 잃어버리게 되는 것도 염두에 두자. Warning 창이 뜨니 상황에 맞게 선택하면 된다.

1. Ask

사용자가 질문을 입력하면 Copilot이 답변을 제공하는 Q&A 모드이다. 코드 설명, 문법 질문, 사용법 안내 등 다양한 프로그래밍 관련 질문에 답할 수 있다.

사용 예시

코드의 동작 원리나 특정 함수/라이브러리 설명이 필요할 때

에러 메시지의 의미나 해결 방법이 궁금할 때

간단한 코드 예시나 사용법이 필요할 때

2. Edit

선택한 파일이나 코드 블록을 수정하거나 개선하는 데 사용하는 모드이다. Copilot이 코드의 버그를 수정하거나, 리팩토링, 최적화, 주석 추가 등 직접적인 코드 변경을 제안하게 되면 이를 선택적으로 코드에 적용할 수 있다.

사용 예시

코드의 버그를 빠르게 수정하고 싶을 때

코드 스타일을 개선하거나 리팩토링할 때

기존 코드에 주석이나 문서화를 추가하고 싶을 때

3. Agent

Copilot이 더 복잡한 작업(여러 파일에 걸친 변경, 테스트 코드 생성, 프로젝트 구조 변경 등)을 자동으로 수행하는 모드이다. 일종의 "자동화된 개발 도우미" 역할을 한다고 보면 되는데, 엄청 똑독하다고 느껴질 때도 있지만 말귀를 못알아 듣는다고 생각할 때도 있어서 편차가 좀 난다고 느껴진다.

사용 예시

여러 파일을 동시에 수정해야 할 때

테스트 코드 자동 생성, 프로젝트 초기화 등 반복적이고 복잡한 작업이 필요할 때

대규모 코드베이스에서 일괄적인 변경이 필요할 때

Copilot Agent에게 일 시키기

먼저 무턱대고 일을 시키면 나중에 가서 "처음부터 다시 할까?" 하는 갈등 상황을 맞이할 수도 있으니 단순하더라도 계획을 좀 세우고 일을 시작하는 것을 추천한다. 히지만 처음부터 다시 하더라도 시간은 좀 낭비가 되더라도 - 두세시간 정도? 그 이상이라면 나의 판단력에 의문을 가져보는 것도... - Copilot Agent의 특성을 체험할 수 있으니 그리 나쁘다고 생각하지는 않는다.

그리고 앞서 설명한데로 Agent 모드와 Edit 모드를 번갈아가면서 쓰지 말아야 한다. context를 잃어버려도 상관없는 작업이면 괜찮지만, 아마도 그렇지 않은 경우가 많을 것이다. 그래서 계획을 좀 세우라고 한 것이다.

그럼 지금까지 Copilot Agent를 사용하면서 나름 정리한 내용을 공유해 보고자 한다.

신규 기능 개발은 Top-Down 방식으로

새롭게 개발하는 기능이 필요할 때는 Agent mode로 여러 file에 걸친 작업을 완료하고 - Model 이나 Class design, function/method prototyping 작업 등에 좀 더 집중 해서 -, 테스트 코드 까지 생성하는 것을 마무리 짓는다. 그 후 Edit mode로 바꾸어서 개별 file에서 추가적인 작업 - Bug 수정, Performance 개선, 주석 추가 등 - 을 수행하는 방향을 추천 드린다.

명확하고 구체적으로

원하는 작업, 변경 범위, 기대 결과 등을 구체적으로 작성해야 한다. 때에 따라서는 사용해야 하는 Tool, 해당 version 등도 명시해 주는 것이 좋다. 내가 Block을 선택해서 Copilot에게 해당 block에 대한 업무를 지시할 수 있기 때문에 이를 적극 활용하는 것도 추천한다.

직접적인 coding 작업이 아닐 경우에 더더욱 구체적인 작업 지시가 필요하다. Model이나 Class를 Design할 때 그 object를 어떻게 사용할지, API는 어떻게 설계할지 등이 구체적일 수록 당신이 원하는 작업을 제공할 것이다.

결과물 리뷰는 필수

Coplot은 작업하기에 앞서 자신이 어떻게 수행할 지 물어 보는 경우도 있다. 이를 검토하고 수정할 부분에 대한 지시를 내린다. 또한 변경된 코드는 꼼꼼하게 Review를 수행해야 한다. 당신의 지시가 명확하고 구체적이었다면 Copilot의 결과물을 그대로 사용해도 되는 경우가 보통이겠지만, 그래도 모른다. 꼼꼼하게 확인하자.

큰 일은 작게 나누어서

내가 개발해야 하는 내용이 있다면 이를 충분히 작게 나눌 필요가 있다. 큰 일을 한 꺼번에 시키면 그만큼 내가 검토해야 하는 사항들이 늘어나고 자꾸 대충 Review를 하게 된다. 어디에서 무슨 작업이 일어났는 지 모르는 코드가 자꾸 생기는 것이다. 사고는 이럴 때 터지는 법.

이렇게 일을 잘게 나누어야 commit 올리고 거기에 설명을 달기도 편하며, 혹시 문제가 발생하면 원인 파악 및 Rollback이 용이하다.

작업 내역과 변경 이유 기록

작업의 범위, Copilot Agent가 수행한 작업 내역 등을 commit description에 넣는다. 그래야 협업 시 변경 사항을 쉽게 공유할 수 있으며, 시간이 지난 후 변경된 내용을 내가 이해할 수 있다.

작업 예시

인터뷰의 한 과정으로 48시간 동안 예술작품에 투자하는 서비스를 위한 Backend system 설계를 요청받았다. 이를 요청 받으면서 "이 작업을 정리해서 글을 써야 하겠구나" 생각이 들었다. interview 요청 사항으로 Django를 써야 한다는 내용이 있었고, 난 Django가 세상에 있다는 정도만 알고 있었다는 사실도 참고해 주길 바란다.

시험 삼아서..

처음에는 잘 안될 것 같았지만, 어떻게 안되는 지 확인해 보기 위해서 시험삼아 몇가지 작업을 해 보았다.

간단히 Guide를 주면서 큰 덩어리로 일 시키기.

요구 사항 몇 줄 적고, Django를 이용해서 MSA로 architecture를 잡아서 Backend를 구현하라는 식으로 일을 시켰다. 시간이 좀 걸린다. - 그래 봤자 1분 남 짓? - 그리고 아주 많은 양의 file이 생성되었다. Django를 모르니 뭐가 어떻게 된 건지 전혀 판단하기가 어려웠다. 성격상 Django 공부 시작.. 몇 시간 후에 대충 파악을 하고, 제시된 코드를 보면서 Django에 대한 이해도 높이고 코드 하나하나의 완성도를 채워 나갔다.

이렇게 대여섯 시간 작업을 하였지만, 뭔가 점점 잘 못되어가고 있다는 느낌. 생성된 File이 어디에 쓰이는 지, 상호간의 관계는 어떻게 되는 건지 내가 이해하지 못하는 상태에서 코드가 생성되고 있었다. 더군다나 Django는 MSA와 잘 맞지 않았다. 중복된 코드도 많이 생기고 있었고, 더군다나 MSA라는 단어에 너무 충실했던 것인지 너무 잘게 component 들을 잡아서 코드가 불필요하게 많이 생긴 경향도 있었다.

두어시간 잘못된 내용을 수습하려 애써 보았지만, 결과는 처음부터 다시 하는 것이 좋겠다는 판단으로 기존 작업물은 엎었다. 이틀의 시간이 주어졌으나 하루를 날린 셈이다. ㅠㅠ

일 잘하는 신입 사원을 대하 듯

이제 전략을 바꿀 차례. 평소에 사람과 작업하는 방식을 적용하였다. 즉 Application 개발의 기본적인 흐름 - 그 것이 Agile 일 수도 있겠지만, 이 상황에서는 거의 한 방에 끝낼 수 있으므로 큰 차이는 없겠지.. - 을 따라 가는 것이다.

아래에 기술된 내용은 Github에 올려 두었으니, README의 내용과 같이 보면 좀 더 이해하기가 좋을 것이다.

요구 사항 정리

Agent를 Ask 모드로 켜고 요구 사항을 잡아 나갔다. 생각나는데로 요구 사항을 쭉 적었고, Agent가 이를 정리, 약간의 보완을 수행해 주었다. backoffice admin을 위해서는 RBAC을 적용시켜야 한다고 명시적으로 기술해 놓았는데, 이를 구현과정에서 실체화 시켜주지는 않았지만 정리된 요구 사항이 있으니 이를 바탕으로 Agent의 작업이 이루어지는 것 같아서 꽤 만족스러웠다.

API 정의

Frontend나 App에게 노출할 API를 정의할 차례. 요구 사항을 충족시킬 수 있도록 RESTFul API를 정의하라고 시켰다. 이 때 Input/Output에 대해서도 상세화 하라고 요청했다. 잘 한다. API를 쭉 검토하면서 추가/변경/삭제를 수행하고 이를 문서로 정리하고 Agent에게도 다시 알려주었다.

Component 정의

앞에 헤매는 과정에서 Django의 특성을 어느 정도 파악하고 나니, RESTFul API는 하나의 Django server에서 처리하는 것이 좋을 것이라 판단하고 - 혹시 이 부분에 대해서 견해가 있으신 분들은 comment 달아주시면 감사하겠습니다. - 투자를 mapping 하는 작업 등은 차후 traffic 상황에 따라서 확장 가능해야 하므로 RabbitMQ를 사용하여 Asynchronous하게 처리시키려고 하였고, 기타 다른 작업들도 실패 발생시 재처리 등을 고려했을 때 단계별로 작업을 하는 것이 좋겠다는 판단으로 모드 RabbitMQ worker로 작업하는 형태로 component를 구성하고자 하였다. API-Gateway를 따로 두고자 하여 component 정의 때는 넣어 두었지만, 아래 구현하는 과정에서 빠졌다. 아무래도 하루라는 시간을 날리고 나니 우선 순위에 따라서 차후에 시간이 남으면 구현하고자 미루어 두었다가 결국 빠졌다.

구현

구현은 각각의 component를 하나씩 따로 구현하는 방식을 택했다.

RESTful API Server => Investment Worker => Benefit Sharing Worker => Point Worker 순으로 하나씩 구현하였다. 앞서 말한 것처럼 위의 단계까지 Ask 모드로 사용을 하였고, 구현 단계에서는 Agent 모드로 놓고 요구 시작하여 Edit 모드로 놓고 상세화를 진행했다. 시간이 좀 촉박하여 Test 관련 내용은 건너 뛰었는데, 이 부분이 좀 아쉽긴 하다.

먼저 RESTful API Server를 구현하기 위해서 API를 다시 상기 시키고 이를 Django로 구현하라고 시켰다. 이 과정에서 Worker에서 어떤 작업이 이루어지고, 어떻게 output이 저장되어야 하는 지도 자연스럽게 정의가 되었으며, 이를 따로 기록해 두었다가, 각각의 Worker 들을 구현하는 과정에서 이를 알려주고 구현을 지시하였다.

추가 작업

Interview project 마감 시간이 1시간 정도 남았다. 미루어 두었던 API Gateway를 구현에 도전해 보았다. 먼저 API Gateway와 API Server가 공동으로 사용할 수 있도록 Auth Server를 먼저 구현해 보았고, gRPC로 서비스를 제공할 수 있도록 지시하여 그 결과까지 commit 해 놓았다.

이제 API Server가 Auth Server를 이용하도록 수정해야 한다. 각각의 View 에서 permission_classes 부분을 고쳐야 할 것 같은데, 허걱.. Django에 대한 지식이 부족하다. 1시간 안에 절대로 못끝낸다는 판단.. 여기서 일단 모든 작업을 중단하였다.

글을 마무리하며,

역시 사람은 - 아니, 적어도 나는 - 해야 할 일이 구체적으로 있을 때 움직인다. 글을 써보자 하는 목표만 가지고는 시간을 투자해서 뭔가 작업하는 게 어렵다. 다행히 interview에서 project를 요청해 와서 이를 수행하면서 많은 공부를 할 수 있는 시간이 되었고, 여러분들도 나의 경험을 조금이나마 공유할 수 있었으면 하는 바람이다.