이제는 슬슬 에이전틱 코딩에 대해 나도 한마디 할 때가 온 것 같습니다.
최근 6개월 넘게 손으로 코드를 작성한 일이 거의 없습니다.
코드를 쓸 일이 없어진 것은 아닙니다. 제가 직접 타이핑하는 대신 AI 에이전트가 저장소를 읽고, 필요한 정보를 모으고, 코드를 고치고, 테스트를 실행합니다. 코드 전체를 따라가며 문맥을 유지하는 일도 이제는 에이전트가 훨씬 많이 맡습니다. 그 능력을 사람이 같은 방식으로 따라잡으려 애쓰는 것은 제게 큰 의미가 없어 보였습니다. 이쯤 되면 회사 업무 코딩을 사람 손으로 여유롭게 즐기는 건 배임에 가깝지 않나, 자조 섞인 농담까지 하게 됩니다.
대신 개발자로서 제가 붙잡는 일이 달라졌습니다. 만들려는 것을 정확히 설명하고, 구현 결과가 요구사항과 맞는지 확인하고, 작업이 필요 이상으로 커지지 않게 멈춰 세우는 일입니다.
수십 년 동안 해오던 일을 어느 날 넘겨주고 관리하는 쪽으로 자리를 옮겼으니 아쉬움이 없지는 않습니다. 직접 코드를 짤 때는 생각과 결과 사이의 거리가 짧았습니다. 지금은 에이전트가 낸 결과를 보고 판단하는 시간이 더 깁니다. 그래도 실제 작업에서는 이 방식이 이미 제 기본값이 됐습니다.
개발자의 일은 의도와 경계를 관리하는 쪽으로 옮겨갔습니다
제가 말하는 Agentic Coding은 자동 완성의 길이가 길어진 상태와는 조금 다릅니다. 에이전트가 저장소를 조사하고, 여러 파일을 수정하고, 테스트를 돌리고, 브랜치와 Pull Request까지 다루는 흐름을 뜻합니다. 사람은 그 흐름이 시작될 조건과 끝날 조건을 정합니다.
이때 가장 자주 생기는 문제는 구현 실패보다 범위가 번지는 일입니다. 요청한 기능을 만들면서 주변 구조까지 고치거나, 장기적으로 좋아 보인다는 이유로 이번 작업에 필요하지 않은 추상화를 더하기 쉽습니다. 코드가 그럴듯할수록 원래 목표에서 벗어났다는 사실을 늦게 알아차리기도 합니다.
그래서 저는 프롬프트를 잘 쓰는 것만으로는 부족하다고 봅니다. 구현 전에 확인된 사실을 남기고, 목표와 non-goal을 분리하고, 결과를 판정할 기준을 정해야 합니다. 구현이 끝난 뒤에는 코드의 모양보다 그 기준을 실제로 만족하는지 확인합니다.
반복할 작업은 스킬로 고정했습니다
이 과정을 매번 긴 프롬프트로 다시 설명하면 빠뜨리는 것이 생깁니다. 저는 자주 쓰는 절차를 Agent Skills로 만들어 관리합니다.
comfuture/agent-skills는 제가 여러 환경에서 같은 작업 방식을 쓰려고 만든 공개 저장소입니다. issue-creator, gh-implement-issue, writing-strategy가 들어 있습니다. 누군가에게 제공하는 제품이라기보다 제가 쓰는 지침을 기계 사이에서 동기화하기 위한 저장소에 가깝습니다. 스킬은 파일 수정, 셸 명령, 네트워크 요청처럼 상태를 바꾸는 행동까지 지시할 수 있으므로 설치 전에는 내용을 직접 확인해야 합니다.
제 구현 작업은 보통 다음 순서로 진행됩니다.
구현 전에 조사 결과를 이슈에 고정합니다
먼저 $issue-creator를 사용합니다. 현재 코드와 문서, 테스트, 관련 이슈와 Pull Request를 읽고 지금 확인할 수 있는 사실을 모읍니다. 사용자가 원하는 방향과 코드에서 확인한 현재 동작도 구분합니다.
그 결과를 GitHub 이슈의 목표, 구현 범위, non-goal, acceptance criteria로 남깁니다. 여기서 중요한 것은 멋진 해결책을 미리 정하는 일이 아닙니다. 다음 에이전트가 무엇을 근거로 구현을 시작하고 어디에서 멈춰야 하는지 알 수 있게 만드는 일입니다.
이슈에 적힌 만큼만 구현합니다
이슈가 준비되면 $gh-implement-issue에 넘깁니다. 이 스킬은 이슈와 조사 결과를 다시 읽고, 작업 브랜치를 만든 뒤, 필요한 코드와 회귀 테스트를 추가합니다. 작은 검증부터 저장소가 요구하는 전체 검사까지 실행하고 Pull Request를 만듭니다.
제가 이 단계에서 가장 많이 보는 것은 diff의 크기보다 이슈와 diff의 대응 관계입니다. acceptance criteria 하나가 어떤 코드와 테스트로 구현됐는지, non-goal에 적은 영역을 건드리지는 않았는지 확인합니다. 구현 범위가 커졌다면 코드가 좋아 보이더라도 먼저 이유를 묻습니다.
자동 리뷰도 범위를 정해 두고 처리합니다
GitHub에 자동 리뷰가 붙는 작업에서는 $gh-autoreview-resolve를 사용하기도 합니다. 리뷰가 시작됐는지 확인하고, 들어온 지적을 현재 코드와 테스트로 다시 검증한 뒤 대응합니다.
리뷰 의견이라고 모두 수정하지는 않습니다. 이번 Pull Request가 만든 문제이면서 이슈의 기준을 위반한 지적은 고칩니다. 맞는 말이지만 이번 범위를 벗어나면 별도 이슈로 분리하고, 이미 고쳤거나 현재 코드와 맞지 않는 지적에는 근거를 남깁니다. 수정한 내용은 테스트하고, 해당 리뷰 스레드에 답한 뒤 resolve합니다. 리뷰가 새로운 설계 작업으로 번지는 것도 여기서 막습니다.
구현이 여러 갈래라면 스레드에 나눠 맡깁니다
구현 범위가 크거나 서로 다른 이슈를 함께 처리해야 할 때는 Codex 앱의 스레드 위임을 자주 사용합니다. 한 스레드에서 다른 프로젝트나 작업 스레드로 메시지를 보내 구현을 시작하고, 원래 스레드는 조정 역할을 맡습니다.
아래 작업에서는 세 이슈를 각각 새 스레드에 맡겼습니다. 각 스레드는 같은 기준 커밋에서 출발하되 자기 이슈의 목표만 구현하게 했고, 원래 스레드는 종료하지 않은 채 진행 상황과 파일 겹침을 계속 확인했습니다.
작업을 나눴다고 조정이 끝나는 것은 아닙니다. 각 스레드가 조사한 의존성을 모아 보면 처음에는 보이지 않던 충돌이 드러납니다. 이 예에서는 한 이슈가 제안한 구조가 다른 이슈의 serializer 변경과 겹칠 수 있었습니다. 그래서 한쪽에는 계약만 먼저 고정하게 하고, 다른 쪽에는 그 계약을 받아 구현하도록 순서를 바꿨습니다.
이 방식은 여러 작업을 동시에 시작하는 것보다 조정 창구를 하나로 유지한다는 데 의미가 있습니다. 각 에이전트는 자기 이슈에 집중하고, 원래 스레드는 공통 기준과 작업 사이의 경계를 봅니다. 충돌을 자동으로 없애 주지는 않지만, 서로 다른 스레드의 판단이 갈라지는 시점을 일찍 발견할 수 있습니다.
이제 조정 인터페이스에 음성도 들어옵니다
OpenAI는 2026년 7월 23일자 릴리스 노트에서 ChatGPT Voice를 데스크톱 앱의 Work와 Codex에서 사용할 수 있다고 발표했습니다. macOS와 Windows의 대상 계정에서는 Voice로 새 작업을 시작하고, 진행 상황을 묻고, 자연스럽게 말을 끊어 방향을 바꾸고, 여러 에이전트의 작업을 한 대화에서 조정할 수 있습니다. Voice가 사용하는 도구와 권한은 선택한 Work 또는 Codex 환경을 그대로 따릅니다.
https://help.openai.com/en/articles/6825453-chatgpt-release-notes
https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex
이 발표가 제게 흥미로운 이유는 코드를 음성으로 작성할 수 있어서가 아닙니다. 여러 스레드에 일을 맡긴 뒤 상태를 확인하고, 겹치는 범위를 지적하고, 우선순위를 바꾸는 과정이 이미 개발 작업의 큰 부분이 됐기 때문입니다. 지금까지는 그 조정을 다시 텍스트로 입력했습니다. Voice Mode는 그 인터페이스를 대화로 바꿉니다.
아직 제 워크플로에서 충분히 오래 사용해 본 기능은 아닙니다. 공식 안내상 동시에 실행할 수 있는 Voice 대화는 하나이고, 연결된 Voice 시간은 별도로 측정될 수 있습니다. Voice로 시작한 작업도 기존 Work와 Codex의 에이전트 사용량을 씁니다. 무엇보다 음성 지시가 이슈의 acceptance criteria나 기록된 non-goal을 대신해 주지는 않습니다. 빠른 개입에는 잘 맞겠지만, 작업의 계약은 여전히 글로 남겨야 합니다.
코드를 놓은 대신 더 정확하게 확인합니다
가끔은 직접 코드를 쓰는 시간이 그립습니다. 문제를 따라가다 한 줄을 바꾸고 바로 결과를 확인하는 감각은 관리 작업과 다릅니다. 에이전트가 만든 코드를 검토하는 일만으로 그 재미가 모두 대체되지는 않습니다.
그래도 지금 제가 책임져야 할 부분은 분명합니다. 무엇을 만들지 정하고, 만들지 않을 것을 적고, 구현 결과를 확인할 증거를 요구하고, 범위를 벗어난 작업을 멈추는 일입니다. 에이전트가 더 많은 코드를 더 빨리 만들수록 이 판단을 늦게 해서는 안 됩니다.
그래서 제 Agentic Coding 워크플로는 에이전트를 얼마나 자유롭게 움직이게 할지보다, 어디까지 움직인 뒤 무엇을 보여줘야 하는지 정하는 데 더 많은 시간을 씁니다. 손으로 작성하는 코드의 양은 크게 줄었습니다. 대신 이슈와 테스트, Pull Request, 리뷰 스레드에 제가 의도한 경계가 남아 있는지를 전보다 더 자주 확인합니다.