Michael Johnson에이전트에게 작업을 맡기고 저장소의 변경 사항이 준비될 때까지 기다리면, 검토할 풀 리퀘스트 초안을 받을 수 있습니다. 하지만 코드와 함께 이런 질문도 생깁니다. 결과가 작업의 목적에 부합하는지, 테스트가 중요한 문제를 놓치지는 않았는지 말입니다.
2026년 2월 4일, GitHub는 Claude와 Codex를 코딩 에이전트로 공개 프리뷰 제공한다고 발표했습니다. 회사는 이 에이전트에 이슈와 풀 리퀘스트의 작업을 할당하고, 에이전트가 준비한 PR 초안을 검토할 수 있다고 밝혔습니다. 이는 이런 작업 방식이 개발 인터페이스에 도입됐음을 보여주지만, 시간을 절약하거나 코드 품질을 높인다는 점까지 입증하지는 않습니다.
따라서 질문은 에이전트가 코드를 작성할 수 있는지에 그치지 않습니다. 위임한 작업을 둘러싸고 사람이 어떤 일을 해야 하는지, 즉 제약 조건을 정하고 진행 상황을 살피며 결과를 평가하는지가 중요합니다.
감독은 최종 검토에 그치지 않는다
2026년 9월 21일 arXiv에 공개된 프리프린트에서 연구진은 코딩 에이전트 감독을 연속적인 과정으로 바라볼 것을 제안합니다. 연구진은 숙련된 개발자 19명의 관찰과 작업 흐름 도식을 바탕으로 위임 뒤에 숨은 작업(The Work Behind Delegation)을 작성했습니다. 논문은 감독의 일곱 단계를 설명하고, 이 틀을 Reddit의 공개 개발자 토론에 적용합니다.
연구진이 설명한 접근법에는 계획에 더 많은 주의를 기울이고, 감독 업무의 일부를 다른 에이전트에 맡기며, 반복되는 지시를 재사용 가능한 자료로 만드는 방법이 포함됩니다. 이는 분석을 위한 틀이지 시간 비용을 측정한 연구가 아닙니다. 개발자가 감독에 얼마나 시간을 쓰는지, 이 과정이 수작업보다 빠른지는 밝혀내지 않았습니다. arXiv 페이지에는 프리프린트가 심사 중이라고 표시되어 있으므로, 그 결과는 잠정적인 것으로 보아야 합니다.
실무에서는 세 가지 활동을 구분하면 유용합니다. 작업 지시는 목표와 제약 조건을 정합니다. 모니터링은 에이전트가 의도에서 벗어나지 않는지 파악하는 데 도움이 됩니다. 검토는 요구 사항과 코드, 테스트를 고려해 결과를 받아들일 수 있는지 평가합니다. 한 단계의 성공이 다음 단계의 성공을 보장하지는 않습니다. 패치가 그럴듯해 보여도 엉뚱한 문제를 해결하거나 대대적인 수정이 필요할 수 있습니다.
커뮤니티 경험은 통계가 아니다
r/LocalLLaMA의 토론에서 한 참여자는 로컬 모델과 에이전트를 사용한 경험이 실망스러웠다고 썼습니다. 그의 말에 따르면 결과를 수정하고 에이전트에게 지시를 다시 상기시켜야 했습니다. 같은 스레드의 다른 참여자들은 작업 범위를 제한하고, 단계별로 진행하며, 코드를 꼼꼼히 검토하는 방식이 자신에게는 더 유용했다고 설명했습니다. 이는 개별 사용자의 관찰일 뿐, 모델을 비교하는 통제된 테스트나 팀 생산성 측정은 아닙니다.
서로 다른 후기는 경험이 작업과 모델, 환경, 작업 방식에 따라 달라질 수 있음을 보여줍니다. 그러나 단 하나의 토론만으로 어떤 관행이 평균적으로 더 효과적인지, 문제가 얼마나 자주 발생하는지 판단할 수는 없습니다. 이 스레드는 로컬 모델을 다루므로, 그 관찰을 모든 에이전트 도구에 그대로 적용해서는 안 됩니다.
사람이 참여한다고 해서 위임이 무의미한 것은 아닙니다. 개발자는 작업을 나누고, 변경 사항을 검토하고, 요구 사항을 구체화하면서 최종 결과에 대한 책임을 유지할 수 있습니다. 하지만 작업 지시와 수정, 리뷰에 든 시간을 고려하지 않으면 전체 작업량이 줄었는지 알 수 없습니다.
PR 초안은 아직 승인된 PR이 아니다
GitHub가 설명한 방식에서는 에이전트에게 이슈를 할당하고 풀 리퀘스트 초안을 받을 수 있습니다. 초안 작성과 승인 사이에는 여전히 별도의 확인 사항이 남습니다. 변경 사항이 요구 사항에 부합하는지, 예외 상황을 고려했는지, 테스트가 충분한지, 해결책이 프로젝트 아키텍처에 맞는지 확인해야 합니다.
이 기준들을 하나의 지표로 요약할 수는 없습니다. 생성된 변경 사항의 수가 실제로 쓸 수 있는 변경 사항의 수와 같지는 않으며, 테스트를 통과했다고 해서 패치의 중요한 속성이 모두 확인된 것도 아닙니다. 결과가 겉보기에 훌륭하더라도 준비와 검증에 얼마나 많은 작업이 필요했는지는 알 수 없습니다.
전체 효과를 평가하려면 작업 지시와 결과 대기, 리뷰, 수정, 이후의 코드 유지 관리까지 전체 과정을 고려해야 합니다. 살펴본 자료는 이러한 종합적인 비교를 제시하지 않습니다.
무엇을 결론 내릴 수 있을까
프리프린트는 감독을 논의하기 위한 틀을 제안하고, GitHub는 에이전트에게 작업을 할당한 뒤 준비된 PR을 검토하는 방식을 소개했습니다. Reddit 토론에서는 일부 사용자가 로컬 모델을 활용하면서 어려움과 유용한 작업 방식을 모두 경험했다고 설명합니다. 이 자료들은 위임한 코드를 어떻게 검증할지 질문하게 하지만, 순생산성에 대한 답을 제시하지는 않습니다.
개발자 전반이 이미 코드 작성에서 감독으로 전환했다거나, 에이전트가 언제나 추가 작업을 만들거나, 업계 생산성을 높인다고 이 자료만으로 결론 내릴 수는 없습니다. 그런 결론을 내리려면 다양한 작업과 팀에서 시간과 품질을 비교해 측정해야 합니다.
팀이 실무에서 던질 질문은 더 구체적입니다. 에이전트가 어떤 변경 사항을 독립적으로 준비할 수 있는가? 병합 전에 무엇을 확인해야 하는가? 결과가 처음의 작업 목적을 달성하도록 할 책임은 누구에게 있는가? 위임이 이런 엔지니어링 작업을 없애지는 않습니다. 다만 그 작업이 어디서 시작되고 무엇에 집중되는지를 바꿉니다.