코딩 에이전트의 가치는 코드를 대신 써주는 데서 끝나지 않는다. 작업을 작게 나누어 맡기고 격리된 환경에서 결과를 비교한 다음, 사람이 변경 사항을 검토하는 흐름이 있어야 실무에서 쓸 수 있다.
지금 이 변화에 주목할 이유
7월 30일 GitHub는 VS Code용 Copilot의 7월 업데이트를 공개했다. 이번에는 여러 에이전트 세션을 한곳에서 관리하고, 대화 옆에서 파일과 diff를 보며, 각 세션을 Git worktree로 분리해 실행하는 기능이 들어갔다. 실행 중인 하위 에이전트의 모델·경과 시간·도구 호출을 확인하고, 실패한 CI나 코드 리뷰 의견도 채팅에서 다룰 수 있게 한 점도 눈에 띈다.
겉으로 보면 개발 도구의 UI 개선처럼 보인다. 내가 보기엔 단순한 화면 개편보다 작업 방식의 변화에 가깝다. AI에게 한 번 묻고 답을 받는 데서 그치지 않고, 일의 일부를 맡긴 뒤 사람이 관리하고 검토하는 쪽으로 옮겨가고 있다. IT 학습자에게 중요한 질문도 달라진다. “어떤 프롬프트를 쓰면 한 번에 정답을 얻을까?”보다 “어떤 일을 안전하게 맡기고, 어떤 증거로 결과를 승인할까?”가 중요해진다.
채팅형 AI와 에이전트형 AI의 차이
채팅형 AI는 주로 질문에 답하거나 초안을 제시한다. 반면 에이전트형 AI는 저장소와 파일을 살피고, 명령을 실행하고, 여러 단계의 산출물을 바꾸는 식으로 사용자의 작업을 수행할 수 있다. 물론 경계는 절대적이지 않다. 채팅 도구에도 도구 실행 기능이 있고, 에이전트에게 단순 질문만 할 수도 있다. 핵심은 모델 이름이 아니라 AI가 실제로 무엇을 실행하고 무엇을 변경할 권한을 갖는가다.
최근 공개된 Codex 사용 연구는 이 차이를 구체적으로 보여준다. 연구진은 2026년 상반기 Codex의 주간 활성 사용자가 5배 이상 늘었고, 소프트웨어 개발 외에도 문서 작성·데이터 분석·커뮤니케이션 같은 지식 노동에 쓰인다고 보고했다. 다만 이 연구는 OpenAI 제품 사용 데이터를 분석한 것이므로 전체 개발자나 모든 조직을 대표한다고 볼 수는 없다. 특히 OpenAI 내부 환경은 접근 권한, 학습, 조직 지원이 일반 회사보다 훨씬 유리하다고 연구 자체도 명시한다.
연구에서 눈에 띈 건 집중 사용자의 방식이었다. 이들은 에이전트를 ‘답변 생성기’보다 반복 가능한 작업 흐름에 가깝게 썼다. 연구에서 주간 기준 사용자의 10% 이상은 세 개 이상의 Codex 에이전트를 동시에 관리한 경험이 있었고, 26.6%는 복잡한 절차를 재사용하는 skills를 사용했다. 병렬 실행이 목표가 아니라, 큰 일을 검토 가능한 작은 단위로 나누는 방식이 핵심이다.
이번 VS Code 업데이트가 보여주는 작업의 단위
GitHub의 업데이트를 기능 목록이 아니라 작업 설계의 관점에서 읽어 보자.
- 대화 옆 diff 검토: 에이전트가 바꾼 파일과 추가·삭제 줄 수를 보면서 검토한다. 결과물을 복사해 붙여 넣는 방식보다 변경 범위와 부작용을 파악하기 쉽다.
- worktree 격리: Copilot·Claude·Codex 세션을 각각 별도 작업 사본에서 시작할 수 있다. 실험용 변경이 현재 작업 브랜치와 섞이는 위험을 낮추는 장치다. 다만 병합 충돌과 의존성 차이는 여전히 사람이 확인해야 한다.
- 여러 대화와 하위 에이전트 추적: 같은 문제를 ‘원인 조사’, ‘테스트 추가’, ‘문서 초안’처럼 역할별로 나누고, 진행 상태를 확인할 수 있다. 이것은 한 에이전트에게 거대한 요구를 던지는 것보다 실패 원인을 추적하기 쉽다.
- 프롬프트 파일을 skills로 이전: 자주 쓰는 지시를 재사용 가능한 작업 규칙으로 바꾸는 기능이다. 좋은 skill은 긴 만능 프롬프트가 아니라 입력·허용된 도구·검증 기준·완료 조건을 명시한 작은 절차다.
여기서 특히 조심할 부분도 있다. GitHub가 에이전트 창에서 ! 접두어로 터미널 명령을 실행할 수 있다고 안내한 것은 편의 기능이지만, 신뢰하지 않는 저장소나 웹에서 복사한 명령을 그대로 실행해도 된다는 뜻은 아니다. AI가 제안한 명령도 사람이 읽고, 프로젝트 범위와 영향도를 확인한 뒤 실행해야 한다. 비밀값, 배포 권한, 운영 데이터가 있는 환경은 로컬 실험보다 훨씬 엄격한 권한 분리가 필요하다.
도구를 주는 것만으로는 부족하다
AI 도구를 지급하면 생산성이 자동으로 따라온다는 해석도 경계해야 한다. Gallup의 2026년 7월 미국 직장인 조사에서 조직이 AI 도구를 통합했다고 답한 비율은 47%였고, AI 사용자는 글쓰기·편집(51%), 검색·조사(49%), 일반 문제 해결(39%)에 가장 많이 활용했다. 반면 코딩 지원과 자동화를 쓰는 사람은 각각 16%였다.
조사에서 더 눈에 띈 수치는 생산성에 대한 응답이었다. 코딩 지원과 자동화 사용자의 77%가 AI가 생산성에 긍정적 영향을 줬다고 답했다. 이는 인과관계를 증명하는 실험 결과가 아니라 자기 보고 설문이므로, “도구를 쓰면 반드시 77%의 효과가 난다”는 뜻은 아니다. Gallup도 사용 범위가 넓은 사람이 원래 도구 활용에 적극적이거나, 업무 자체가 AI 적용에 적합할 가능성을 분리할 수 없다고 설명한다.
내가 이 조사에서 가져온 결론은 단순하다. 막연한 ‘AI에게 물어보기’보다 테스트 작성, 오류 재현, 문서 갱신, 데이터 정리처럼 시작과 끝이 분명한 업무에 연결할수록 가치와 검토 기준이 선명해진다. 에이전트가 만든 코드가 맞는지 판단하는 능력, 즉 테스트·diff·로그를 읽는 능력이 더 중요해지는 이유다.
오늘 시도할 수 있는 3가지
1. 다음 과제를 세 개의 산출물로 쪼개기
예를 들어 작은 웹 기능을 만들고 있다면 ‘현재 코드 구조 요약’, ‘실패하는 테스트 하나 추가’, ‘최소 수정안 제안’으로 나눈다. 첫 단계는 읽기 전용으로 두고, 수정은 두 번째 또는 세 번째 단계에서만 허용한다. 각 단계의 완료 조건을 한 문장으로 적어 두면 에이전트 결과를 평가하기 쉽다.
2. 변경 요청에는 반드시 검증 요구를 붙이기
“기능을 구현해 줘” 대신 “변경 파일 목록, 핵심 diff의 이유, 실행한 테스트와 결과, 남은 위험을 함께 제시해 줘”라고 요청해 보자. 테스트가 없으면 무엇을 수동으로 확인해야 하는지 적게 한다. 에이전트의 자신감 있는 문장보다 재현 가능한 검증 기록을 신뢰하는 습관이 필요하다.
3. 재사용할 지시를 짧은 skill로 정리하기
반복하는 작업 하나만 골라 템플릿으로 만든다. 예를 들면 ‘버그 수정 전: 재현 절차와 관련 파일을 먼저 제시할 것 / 수정 후: 단위 테스트 실행 / 완료 전: 변경하지 않은 영역과 불확실성을 적을 것’처럼 구성한다. 프로젝트마다 다를 수 있는 명령, 허용 파일 범위, 금지된 경로도 함께 기록한다. 처음부터 여러 에이전트를 병렬로 돌리기보다 이 절차가 한 번 안정적으로 작동하는지 확인하는 편이 낫다.
결국 남는 건 검토다
이번 Copilot 업데이트와 최근 사용 연구는 에이전트가 개발자의 작업 단위를 넓히고 있음을 보여준다. 그러나 병렬 세션, worktree, 하위 에이전트 같은 기능은 자동 품질 보증 장치가 아니다. 잘못된 요구사항, 부족한 테스트, 과도한 권한, 검토 없는 병합은 도구가 좋아져도 그대로 위험하다.
특정 모델의 사용법은 금방 바뀐다. 반면 일을 작은 단위로 정의하고 실행 권한을 제한하는 습관은 오래 간다. 결과를 테스트와 diff로 확인하고, 잘 작동한 절차를 다시 쓸 수 있게 남겨 두는 일도 마찬가지다. 에이전트를 빠른 답변 도구가 아니라 관리해야 하는 작업자로 보면 새 기능이 나와도 판단 기준을 잃지 않는다.