안녕하세요, 멘토 김부장입니다. 저는 코딩을 마흔 넘어 늦게 시작한 사람이라, 새로운 도구가 나올 때마다 처음엔 늘 겁부터 먹었어요. "이건 진짜 개발자들이나 쓰는 거겠지" 하고요. 그런데 GitHub의 Copilot 코딩 에이전트를 처음 써 보고 나서는 생각이 좀 달라졌습니다. 이건 '내가 코드를 더 잘 짜게 도와주는 도구'라기보다, '내 대신 초안을 만들어 오는 신입 동료'에 가깝더라고요.
지난 몇 년간 우리가 AI를 쓰던 방식은 대체로 '물어보기'였습니다. 챗봇 창을 열고 "이 코드 왜 에러 나요?"라고 묻고, 답을 복사해서 내 프로젝트에 붙여넣고, 안 되면 또 묻고… 이 과정을 수십 번 반복했죠. 그런데 코딩 에이전트는 방식이 다릅니다. 물어보는 게 아니라 일을 맡기는 겁니다. "이 버그 좀 고쳐 줘"라고 일감(이슈)을 붙여 주면, 알아서 코드를 뒤지고 고치고 테스트까지 돌린 다음, 결과물을 '검토해 주세요' 하고 가져옵니다.
에이전트라는 개념 자체가 낯선 분은 먼저 AI 에이전트가 뭔가요 글을 가볍게 읽고 오셔도 좋습니다. 오늘은 그 개념이 'GitHub에서 코드 작업'이라는 구체적인 일에 어떻게 적용되는지를, 겁먹지 않게 하나씩 풀어 드릴게요.
코딩 에이전트는 한마디로 "일감(이슈)을 붙여 주면 알아서 초안(PR)을 만들어 오는 신입/인턴 동료"입니다. 내가 하는 일은 딱 두 가지예요. 일을 맡기는 것, 그리고 가져온 결과를 검토하는 것.
코딩 에이전트가 대체 뭔가요
회사에 신입 사원이 한 명 들어왔다고 생각해 봅시다. 이 신입에게 "게시판에 글 삭제 버튼이 가끔 안 눌린대요, 한번 봐 주세요"라고 업무를 하나 넘깁니다. 그러면 신입은 자기 자리에 앉아 코드를 열어 보고, 원인을 찾고, 고쳐 보고, 잘 되는지 확인한 다음, "이렇게 고쳐 봤는데 확인 부탁드립니다"라며 결과를 가져옵니다. 여러분은 그 결과를 보고 "좋네, 반영하자" 또는 "여기는 이렇게 바꿔 줘"라고 말하면 되죠.
GitHub Copilot 코딩 에이전트가 하는 일이 정확히 이겁니다. 정식으로 말하면, 이 기능은 유료 Copilot 플랜에서 제공되며 이미 일반 사용(GA) 단계에 들어간, GitHub에 정식 탑재된 기능입니다. 실험실 안의 장난감이 아니라, 실제로 팀들이 매일 쓰고 있는 도구라는 뜻이에요.
여기서 '에이전트(agent)'라는 단어가 핵심입니다. 기존 AI가 내 옆에서 거들어 주는 조수였다면, 에이전트는 목표를 주면 스스로 여러 단계를 밟아 일을 끝내는 대리인입니다. 코드를 어디서 고쳐야 할지 스스로 탐색하고, 파일을 여러 개 수정하고, 테스트를 돌려 보고, 결과가 이상하면 다시 시도하는 이 일련의 과정을 사람이 일일이 지시하지 않아도 알아서 진행합니다.
왜 이게 지금 나왔을까요
코딩을 조금이라도 해 본 분들은 압니다. 개발이라는 게 '멋진 새 기능을 만드는 일'만 있는 게 아니라는 걸요. 오히려 시간을 잡아먹는 건 사소하고 귀찮은 일들입니다. 오타 하나 고치기, 버튼 색깔 바꾸기, 안 쓰는 코드 정리하기, 문서에 설명 한 줄 추가하기, "언젠가 하면 좋을 텐데" 하고 미뤄 둔 자잘한 개선들. 이런 일감은 백로그(할 일 목록) 아래쪽에 쌓여만 가고, 정작 손은 안 갑니다. 왜냐하면 이런 일 하나하나가 '엄청 어렵진 않지만, 자리에 앉아 집중해야 하는' 일이거든요.
바로 이 지점을 코딩 에이전트가 파고듭니다. 작고 명확한 일감을 던져 두면, 내가 회의를 하는 동안, 혹은 퇴근한 사이에 에이전트가 알아서 초안을 만들어 놓습니다. 아침에 출근해서 검토만 하면 되는 거죠. 마치 부지런한 인턴이 밤새 숙제를 해 놓은 것처럼요. 이게 없던 시절엔 이런 자잘한 일들이 그냥 영영 안 되거나, 아까운 개발 시간을 갉아먹었습니다.
기존 Copilot이랑 뭐가 다른가요
여기서 많은 분들이 헷갈려 하십니다. "Copilot이면 원래 코드 자동완성해 주는 거 아니었나요?" 맞습니다. 그런데 Copilot이라는 이름 아래에는 성격이 꽤 다른 여러 기능이 있어요. 크게 세 단계로 나눠 볼 수 있습니다. 자동차에 비유하면, 자동완성은 내비게이션 안내(내가 운전, 옆에서 길 알려줌), 채팅은 조수석 내비게이터(물어보면 상세히 대답), 코딩 에이전트는 대리운전 기사(목적지만 말하면 알아서 도착)에 가깝습니다.
| 구분 | 코드 자동완성 | Copilot 채팅 / 에이전트 모드 | 코딩 에이전트(클라우드) |
|---|---|---|---|
| 언제 쓰나 | 내가 코드를 타이핑하는 그 순간 | 막히거나 물어볼 게 생겼을 때 | 일감(이슈)을 통째로 넘기고 싶을 때 |
| 어디서 도나 | 내 편집기 안, 커서 옆에서 | 내 편집기 / 브라우저 채팅창에서, 내 화면 안에서 | GitHub의 별도 임시 개발환경에서(내 컴퓨터 밖) |
| 누가 운전하나 | 사람(내가 계속 타이핑) | 사람이 주도, AI가 옆에서 실행 거들기 | 에이전트가 스스로 주도, 사람은 검토만 |
| 결과물 | 다음에 칠 코드 몇 줄 제안 | 답변 + 내 화면에서의 코드 수정 | 새 브랜치 + 완성된 PR 한 개 |
| 비유 | 내비 길 안내 | 조수석 내비게이터 | 대리운전 기사 |
차이가 보이시나요? 앞의 두 가지는 내가 내 화면 앞에 앉아 있어야 돌아갑니다. 반면 코딩 에이전트는 내가 자리를 비워도 됩니다. 일을 넘겨 두고 다른 일을 하면 되는 거죠. '내 화면 안'이 아니라 'GitHub 서버 어딘가의 자기 작업실'에서 일한다는 게 결정적인 차이입니다.
어디서, 어떻게 일을 맡기나요
일을 맡기는 방법은 생각보다 여러 갈래입니다. 어렵게 생각하실 것 없어요. '이 신입에게 어떻게 업무를 전달할까'와 똑같습니다.
- 이슈를 할당(assign)하기: GitHub에서 이슈(할 일 카드)를 하나 만들고, 담당자로 사람 대신 Copilot을 지정합니다. 가장 정석적인 방법이에요.
- @copilot 으로 부르기: PR, 이슈, 혹은 Copilot Chat 안에서
@copilot하고 멘션하며 "이거 해 줘"라고 말합니다. 마치 단톡방에서 누군가를 콕 집어 부르듯이요. - VS Code나 github.com의 Copilot Chat에서: 편집기나 브라우저의 채팅창에서 바로 작업을 넘길 수도 있습니다.
- 예약·이벤트 자동화: 특정 조건이나 일정에 맞춰 자동으로 작업을 맡기도록 설정하는 것도 가능합니다.
방법은 여러 가지지만, 본질은 하나입니다. "이런 일을 해 주세요"라는 요청을 에이전트에게 전달하는 것. 그리고 가장 이해하기 쉽고 관리하기 좋은 방법이 바로 '이슈 할당'이라, 아래에서는 이걸 기준으로 전체 흐름을 설명하겠습니다.
이슈를 잘 쓴다
무엇을, 왜, 어디까지 해야 하는지 적습니다. 맥락과 '이 정도면 완성'이라는 수용 조건까지 써 주면 결과가 확 좋아집니다. (뒤에서 자세히)
Copilot에게 맡긴다
그 이슈의 담당자로 Copilot을 지정하거나 @copilot 으로 부릅니다. "이 일감 자네가 맡아 줘" 하고 넘기는 거죠.
에이전트가 임시 작업실에서 일한다
에이전트는 GitHub Actions 기반의 자기만의 임시(ephemeral) 개발환경을 켭니다. 거기서 저장소를 탐색하고, 코드를 고치고, 테스트와 린트(코드 검사)를 돌려 봅니다.
PR을 만들어 온다
작업이 끝나면 원본을 건드리지 않고 별도 브랜치에 변경을 담아 풀 리퀘스트(PR)를 엽니다. "이렇게 고쳐 봤어요, 봐 주세요" 하는 제출물입니다.
사람이 검토하고 병합한다
여러분(또는 팀)이 PR을 읽고 리뷰합니다. 좋으면 병합(merge), 아쉬우면 "여기 이렇게 바꿔 줘"라고 수정을 요청합니다. 최종 결정은 언제나 사람 몫입니다.
이 흐름 곳곳에 이미 여러분이 알아 두면 좋은 개념들이 등장했습니다. '별도 브랜치'가 무슨 뜻인지는 브랜치 이야기에서, PR을 검토하고 병합하는 절차는 PR·코드리뷰 글에서, 에이전트가 일하는 '임시 개발환경'의 정체인 GitHub Actions는 GitHub Actions 글에서 각각 자세히 다뤘으니, 낯선 단어가 나오면 그쪽을 참고하세요. 이 글만 읽어도 큰 그림은 다 잡히도록 썼으니 겁먹지 않으셔도 됩니다.
전체 흐름을 한눈에
말로 풀면 복잡해 보이지만, 그림으로 보면 정말 단순합니다.
할 일 + 조건
일 맡기기
탐색·수정·테스트
별도 브랜치
수정·병합
왼쪽 끝(이슈 작성)과 오른쪽 끝(사람 검토)은 사람의 일입니다. 가운데 세 칸은 에이전트의 일이고요. 그러니까 여러분이 실제로 신경 쓸 곳은 양쪽 끝, '일을 잘 맡기기'와 '결과를 잘 검토하기'뿐입니다. 가운데는 에이전트가 알아서 합니다.
에이전트가 잘하는 일 vs 못하는 일
여기가 정말 중요합니다. 코딩 에이전트를 실망스럽게 쓰는 분들의 90%는 '못하는 일을 시켜서'입니다. 이 친구는 만능이 아니에요. 신입 인턴에게 시키기 좋은 일과 나쁜 일이 있는 것처럼, 에이전트에게도 딱 맞는 일과 안 맞는 일이 뚜렷합니다.
👍 잘 맞는 일 (작고 명확한 것)
- 범위가 분명한 버그 수정
- 기존 구조에 얹는 점진적 기능 추가
- 테스트 코드·문서 보강
- 안 쓰는 코드 정리 등 기술부채 처리
- 백로그에 쌓인 '있으면 좋을' 개선들
- "이 기능 어디서 처리되나?" 같은 코드베이스 사전 조사
👎 안 맞는 일 (크고 모호한 것)
- 여러 서비스를 아우르는 대규모 아키텍처 설계
- "알아서 멋지게 해 줘" 식의 모호한 요구
- 한 번에 수십 개 파일을 크게 뒤엎는 작업
- 사람 간 합의·판단이 필요한 정책 결정
- 여러 저장소에 걸친 동시 작업
- 보안·과금처럼 실수가 치명적인 민감 영역
기준을 하나만 기억하세요. "작고, 명확하고, 한 저장소 안에서 끝나는 일"이면 맡길 만합니다. 반대로 "크고, 모호하고, 여기저기 걸쳐 있는 일"이면 사람이 먼저 잘게 쪼갠 다음에 맡겨야 합니다. 신입에게 "우리 회사 시스템 전체를 개선해 봐"라고 하면 사고가 나지만, "이 화면의 이 버튼만 고쳐 봐"라고 하면 잘 해내는 것과 똑같아요.
좋은 이슈 쓰기 = 좋은 프롬프트 쓰기
코딩 에이전트를 잘 쓰는 사람과 못 쓰는 사람의 차이는 딱 하나입니다. 일을 얼마나 명확하게 맡기느냐. 결국 이슈를 쓰는 일이 곧 프롬프트를 쓰는 일이거든요. 실제 회사에서 신입에게 업무를 넘길 때를 떠올려 보세요. "그거 좀 해 놔"라고만 하면 엉뚱한 걸 해 오지만, "무엇을, 왜, 어디까지, 뭘 참고해서"까지 알려 주면 제대로 해 옵니다. 에이전트도 똑같습니다.
배경(왜)을 적는다
"삭제 버튼이 모바일에서만 안 눌린다는 문의가 늘고 있어요" 처럼, 이 일이 왜 필요한지 상황을 알려 줍니다. 배경을 알면 엉뚱한 방향으로 새지 않습니다.
원하는 결과(수용 조건)를 적는다
"모바일·PC 양쪽에서 삭제 버튼이 정상 동작하고, 관련 테스트가 통과하면 완료"처럼 '이 정도면 끝'의 기준을 못박습니다. 이게 가장 중요합니다.
건드리지 말 것을 적는다
"결제 관련 코드는 손대지 마세요" 같은 금지선입니다. 인턴에게 "이 서랍은 열지 마"라고 미리 말해 두는 것과 같아요.
참고 파일·힌트를 준다
"관련 코드는 아마 components/DeleteButton 근처일 거예요"처럼 출발점을 알려 주면 훨씬 빠르고 정확하게 일합니다.
한계와 반드시 알아야 할 주의점
자, 이제 솔직한 이야기를 할 차례입니다. 이 도구는 훌륭하지만 분명한 한계가 있어요. 이걸 모르고 쓰면 "왜 안 되지?" 하며 답답해집니다. 기술적인 제약부터 정리하겠습니다.
| 한계 | 무슨 뜻인가요 |
|---|---|
| 한 세션 = 한 저장소 | 한 번의 작업은 하나의 저장소 안에서만 이뤄집니다. 여러 저장소를 넘나드는 작업은 못 합니다. |
| 세션당 PR 한 개 | 한 번 맡기면 결과물 PR은 하나입니다. 여러 개를 원하면 일을 나눠서 여러 번 맡겨야 합니다. |
| 최대 실행시간 약 59분 | 한 세션이 무한정 돌지 않습니다. 대략 한 시간 안에 끝날 만한 크기의 일이어야 한다는 뜻이에요. |
| 브랜치 보호 규칙에 막힐 수 있음 | '특정 사람만 커밋 가능' 같은 저장소 규칙이 걸려 있으면 에이전트가 작업하지 못할 수 있습니다. |
| GitHub 저장소에서만 동작 | GitHub에 올라간 프로젝트에서만 씁니다. 다른 곳에 있는 코드에는 쓸 수 없습니다. |
이 한계들을 보면 오히려 힌트가 됩니다. '한 저장소, 한 PR, 한 시간 안'이라는 제약이 곧 '작고 명확한 일에 맡겨라'라는 앞의 조언과 정확히 일치하거든요. 큰일을 맡기면 안 되는 게 아니라, 애초에 못 하도록 설계되어 있는 셈입니다.
그리고 기술적 한계보다 훨씬 중요한 것이 하나 있습니다. 바로 사람의 검토입니다.
비용도 짚고 넘어갈게요. 코딩 에이전트는 유료 Copilot 플랜에서 제공되는 기능이고, 임시 개발환경을 돌리는 만큼 자원(예: Actions 사용량)을 씁니다. 구체적인 요금과 포함 한도는 플랜에 따라 다르고 정책이 자주 바뀌니, 반드시 GitHub 공식 문서와 요금 안내에서 최신 값을 확인하세요. 제가 여기에 특정 금액을 적어 두면 그게 곧 틀린 정보가 될 수 있어서, 숫자는 일부러 적지 않습니다.
비개발자에게 이게 왜 중요한가요
여기까지 읽고 "나는 코드도 잘 모르는데 이게 나랑 무슨 상관이야?" 하실 수 있습니다. 그런데 저는 오히려 비개발자에게 더 큰 의미가 있다고 봅니다. 왜냐하면 지금까지 '만들기'는 어떻게든 AI의 도움으로 흉내라도 냈지만, '유지보수'는 늘 벽이었거든요.
예를 들어 제 책 「코딩 몰라도 AI로 사주앱 만들기」를 따라 앱을 하나 만들었다고 칩시다. 만드는 것까지는 신나게 했는데, 몇 달 뒤 "여기 오타가 있네", "이 버튼 위치를 바꾸고 싶은데" 같은 사소한 수정이 생기면 다시 막막해집니다. 이럴 때 이슈 하나 잘 써서 에이전트에게 맡기면, 그 자잘한 유지보수까지 위임할 수 있게 된 겁니다. '만들기'뿐 아니라 '고치고 다듬기'까지 손을 빌릴 수 있게 된 거죠.
다만 여기에 반전이 있습니다. AI가 만드는 일을 대신 해 줄수록, 사람에게 더 중요해지는 능력은 '검토하는 눈'입니다. 코드를 처음부터 짜는 능력보다, 가져온 결과가 맞는지 판단하는 능력이 더 귀해진다는 뜻이에요. 그래서 저는 이 도구를 '코딩을 안 배워도 되는 이유'가 아니라 '무엇을 배워야 하는지 바뀌는 신호'로 읽습니다. 이 검토의 중요성에 대해서는 AI를 쓸 때 조심할 것들 글에서 더 깊이 다뤘으니 함께 읽어 보세요.
AI 시대에 위험한 건 'AI를 안 쓰는 사람'이 아니라 'AI가 해 온 걸 검토 없이 그대로 믿는 사람'입니다. 맡기는 능력만큼 검토하는 능력을 함께 키우세요.
자주 묻는 질문 (FAQ)
Q. 코딩 전혀 몰라도 쓸 수 있나요?
A. 이슈를 만들고 Copilot을 지정하는 조작 자체는 어렵지 않아, 코딩을 몰라도 '일을 맡기는' 단계까지는 충분히 할 수 있습니다. 다만 결과물인 PR을 검토하고 병합하는 마지막 단계에서는 최소한의 판단력이 필요합니다. 완전히 몰라도 되는 건 아니고, 함께 자라야 하는 관계라고 보시면 됩니다.
Q. AI가 잘못 짠 코드가 그냥 병합되면 어떡하죠?
A. 그런 일이 없도록 '사람이 반드시 검토하고 병합'하는 구조로 설계되어 있습니다. 에이전트는 PR이라는 '제출물'을 만들 뿐, 그것을 실제 코드에 반영할지는 사람이 결정합니다. PR 검토를 건너뛰지 않는 것, 그리고 코드리뷰·자동 테스트 같은 안전장치를 갖춰 두는 것이 핵심입니다.
Q. 무료인가요?
A. 아니요. 코딩 에이전트는 유료 Copilot 플랜에서 제공되는 기능입니다. 구체적인 금액과 포함 한도는 플랜별로 다르고 자주 바뀌므로, 정확한 값은 반드시 GitHub 공식 요금 안내에서 확인하세요. (그래서 이 글에는 일부러 금액을 적지 않았습니다.)
Q. 에이전트가 일하는 동안 제 컴퓨터가 켜져 있어야 하나요?
A. 아니요. 에이전트는 여러분의 컴퓨터가 아니라 GitHub의 임시 개발환경에서 일합니다. 그래서 일을 맡겨 두고 컴퓨터를 꺼도, 퇴근을 해도 작업은 계속 진행됩니다. 이게 자동완성·채팅과의 가장 큰 실용적 차이예요.
Q. 큰 기능 하나를 통째로 맡기면 안 되나요?
A. 권장하지 않습니다. 한 세션은 한 저장소·한 PR·약 59분이라는 제약이 있고, 무엇보다 크고 모호한 일일수록 결과가 나빠집니다. 큰일은 사람이 먼저 작은 이슈 여러 개로 쪼갠 뒤 하나씩 맡기는 게 훨씬 잘 됩니다. 이게 에이전트를 잘 쓰는 사람들의 공통된 노하우입니다.
마무리 체크리스트
오늘 내용을 실제로 써 보기 전에, 이것만 점검하세요.
- ✅ 유료 Copilot 플랜이 준비되어 있고, 코딩 에이전트 기능이 켜져 있다
- ✅ 맡길 일이 작고 명확하며 한 저장소 안에서 끝나는 일이다
- ✅ 이슈에 배경·수용 조건·건드리지 말 것·참고 파일을 적었다
- ✅ 결과물인 PR을 내가(또는 팀이) 반드시 검토하고 병합할 준비가 되어 있다
- ✅ 브랜치 보호 규칙 등에 막히지 않는지 미리 확인했다
- ✅ 요금·한도는 GitHub 공식 문서에서 최신 값을 확인했다
처음엔 아주 사소한 일부터 맡겨 보세요. 오타 하나 고치기, 문서에 설명 한 줄 추가하기 같은 거요. 신입에게 처음부터 큰일을 안 맡기는 것처럼, 에이전트와도 작은 일로 손발을 맞춰 가면 됩니다. 몇 번 해 보면 '아, 이런 일은 잘하고 저런 일은 못하는구나' 하는 감이 생깁니다. 그 감이 생기면, 여러분은 이제 코드를 직접 다 짜지 않고도 프로젝트를 굴려 가는 새로운 방식을 손에 넣은 겁니다. 저도 처음엔 반신반의했지만, 지금은 이 '인턴 동료' 없이 일하는 걸 상상하기 어려워졌어요.
이 시리즈의 큰 그림이 궁금하시면 DevOps 시리즈 개요부터, 자동화의 다른 축이 궁금하시면 CI/CD 이야기를 이어서 읽어 보세요. 다음 글에서는 에이전트가 일하는 '임시 개발환경'을 우리가 직접 만들어 쓰는 이야기, 바로 컨테이너 편으로 찾아뵙겠습니다. 코드를 '어디서든 똑같이 돌아가게' 담는 도시락통 같은 기술인데, 이것도 겁먹을 것 하나 없으니 기대해 주세요.
(2026년 8월 기준 — 기능·플랜·한도는 바뀔 수 있으니 GitHub 공식 문서를 확인하세요.)
← 기술 블로그 목록으로