오픈 소스 코딩 에이전트에게 필요한 것은 모델만이 아니라 유지 관리자(Maintainer)입니다

OpenAI는 어제 모두의 시선을 멈추게 할 만한 수치를 담은 Warp 사례 연구를 발표했습니다. 현재 에이전트(Agent)가 Warp 내부 풀 리퀘스트(Pull Request)의 약 90%를 공동 생성하고 있다는 내용입니다.

이는 엄청난 숫자입니다.

하지만 제가 계속해서 생각하고 있는 부분은 그 숫자가 아닙니다.

더 흥미로운 부분은 Warp가 장기 실행되는 에이전트 워크플로우(Workflow)에 필요하다고 언급한 요소들입니다: 관측 가능성 (Observability), 조정 (Coordination), 메모리 (Memory), 그리고 인간의 검토 (Human Review). 이는 "모델이 더 똑똑해졌다"라기보다는 "코드가 기계에 의해 생성되더라도 소프트웨어 개발은 여전히 사회적이고 운영적인 시스템이라는 것을 발견했다"라는 말에 더 가깝게 들립니다.

그렇습니다. 소프트웨어 엔지니어링의 세계에 다시 오신 것을 환영합니다.

오픈 소스는 결코 코드만이 아니었습니다

에이전트 이야기에 대한 게으른 버전은 오픈 소스가 구현 작업의 무한한 공급을 곧 받게 될 것이라는 점입니다.

버그 수정이 필요한가요? 에이전트 (Agent).

리팩터링 (Refactor)이 필요한가요? 에이전트 (Agent).

테스트가 필요한가요? 에이전트 (Agent).

40개의 파일에 걸친 마이그레이션 (Migration)이 필요한가요? 여러 명의 에이전트 (Agent).

그런 일은 일어날 것입니다. 그중 일부는 유용할 것입니다. 오픈 소스의 많은 지루한 작업들은 에이전트가 도움을 줄 수 있는 바로 그 유형의 제한적이고, 반복적이며, 테스트 가능한 작업들입니다. 저는 인간이 영원히 보일러플레이트 (Boilerplate)를 직접 편집하는 것에 대해 감상적인 태도를 취하지 않습니다.

하지만 오픈 소스 프로젝트가 실패하는 이유는 코드를 충분히 입력할 사람이 없어서가 아닙니다.

프로젝트는 유지 관리자 (Maintainer)들이 번아웃 (Burnout)되기 때문에 실패합니다. 이슈 트래커 (Issue Tracker)가 제2의 직업이 되어버리기 때문에 실패합니다. 모든 기여 (Contribution)에는 기여자가 알지 못하는 컨텍스트 (Context)가 필요하기 때문에 실패합니다. 프로젝트에는 태스크 프롬프트 (Task Prompt)에 깔끔하게 들어맞지 않는 보이지 않는 제약 조건, 오래된 호환성 약속, 릴리스 (Release) 습관, 보안 기대치, 그리고 사용자 워크플로우 (User Workflow)가 존재하기 때문에 실패합니다.

에이전트는 더 많은 디프 (Diff)를 생성할 수 있습니다.

하지만 그것이 자동으로 더 많은 유지 관리 (Maintainership)를 만들어내지는 않습니다.

희소 자원의 이동

코드 생성 비용이 저렴해지면, 희소 자원은 다른 곳으로 이동합니다.

에이전트 중심의 오픈 소스 프로젝트에서 희소 자원은 패치 (patch)의 초안이 아닙니다. 그 패치가 존재해야 하는지를 결정하는 것입니다.

이 변경 사항이 프로젝트에 속해도 되는가? 설계 방향 (design direction)과 일치하는가? 호환성 (compatibility)을 유지하는가? 단 한 사람만이 원하는 기능을 위해 유지 관리 부담 (maintenance burden)을 가중시키는가? 보고된 문제를 해결하는가, 아니면 단순히 이슈 제목만을 만족시키는가? 테스트가 실제 동작을 인코딩하고 있는가, 아니면 단지 생성된 구현 (implementation)에 축복을 내리고 있는가?

이것들은 유지 관리자 (maintainer)의 질문들입니다.

또한 이 질문들은 비용이 많이 듭니다.

인간 기여자 (contributor)는 보통 어느 정도의 마찰 (friction)을 동반합니다. 그들은 PR (Pull Request)을 열 만큼 충분히 신경을 써야 합니다. 문제를 설명하고, 댓글에서 논쟁하기도 하며, 리뷰 후에 패치를 수정하기도 합니다. PR을 생성하는 비용 자체가 충분히 높기 때문에 어느 정도의 노이즈를 걸러내는 역할을 합니다.

에이전트는 그 마찰을 줄여줍니다. 작업 내용이 좋을 때는 이것이 유용합니다. 하지만 작업이 모호하거나, 가치가 낮거나, 혹은 전문적인 형식으로 포장되어 있지만 틀린 내용일 때는 고통스럽습니다.

최악의 미래는 에이전트가 오픈 소스 코드를 작성하지 못하는 미래가 아닙니다.

최악의 미래는 유지 관리자들이 무한히 생성되는 그럴듯한 디프 (diffs)를 위한 무보수 감독관이 되는 것입니다.

그럴듯한 작업은 위험한 종류입니다

잘못 생성된 작업은 짜증스럽지만 거절하기는 쉽습니다.

위험한 종류는 그럴듯한 작업 (plausible work)입니다. 컴파일이 됩니다. 테스트를 통과합니다. PR 설명은 차분합니다. 에이전트는 기존 패턴을 따랐다고 말합니다. 체크리스트도 있습니다. 어쩌면 작은 벤치마크 (benchmark) 표까지 포함되어 있을지도 모릅니다.

그럼에도 불구하고, 그 변경 사항은 틀렸을 수 있습니다.

아마도 일반적인 케이스는 처리하지만, 아무도 기억하지 못하는 특이한 플랫폼을 망가뜨릴 수도 있습니다. 오래된 고객 때문에 존재하는 지저분한 분기 (branch)를 삭제할 수도 있습니다. 프로젝트가 적극적으로 제거하려고 노력 중인 패턴을 복사할 수도 있습니다. 혹은 테스트 범위가 너무 좁아서 테스트가 통과하는 것일 수도 있습니다.

이것이 바로 생성이 정교해질수록 리뷰의 품질이 더욱 중요해지는 이유입니다. 설득력 있는 패치를 만들어내기가 쉬워질수록, 리뷰어는 디프 (diff)보다는 프로젝트 자체를 더 깊이 이해해야 합니다.

이것은 아주 고약한 역전 현상입니다.

AI는 까다로운 질문들이 던져지기도 전에 코드가 더 완성된 것처럼 보이게 만들 수 있습니다.

에이전트 기반 오픈 소스에는 모델뿐만 아니라 큐(Queue)가 필요합니다

오케스트레이션 (Orchestration)에 대한 Warp의 프레임워크 설정은 올바른 방향입니다. 지속적인 에이전트 (Persistent agents)에게는 공유 메모리 (Shared memory), 재현 가능한 환경 (Reproducible environments), 조정 (Coordination), 권한 (Permissions), 평가 (Evaluations), 그리고 작업물을 검사할 수 있는 인간이 필요합니다.

오픈 소스를 위해, 저는 한 가지 더 지루한 요소를 추가하고 싶습니다: 바로 큐 규율 (Queue discipline)입니다.

만약 에이전트가 유지 관리자 (Maintainer)가 리뷰할 수 있는 속도보다 더 빠르게 작업물을 만들어낸다면, 프로젝트는 그것이 감정적 부채 (Emotional debt)가 되기 전에 작업 속도를 늦출 수 있는 방법을 마련해야 합니다.

모든 이슈 (Issue)가 에이전트의 대상이 되어서는 안 됩니다. 모든 리포지토리 (Repository)가 어디에서든 오는 에이전트의 PR (Pull Request)을 수락해서도 안 됩니다. 생성된 모든 패치 (Patch)가 실제 사용자 맥락을 가진 사려 깊은 인간의 기여와 동일한 리뷰 큐 (Review queue)에 놓여서도 안 됩니다.

저는 다음과 같은 라벨 (Label)들이 필요하다고 생각합니다:

agent-ok
needs-maintainer-context
good-first-agent-task
do-not-automate
requires-design-discussion

인기 있는 프로젝트가 주말 사이에 오래된 이슈들에 대해 200개의 에이전트 작성 "수정 사항"을 받는 상황을 상상하기 전까지는 이 말이 우스꽝스럽게 들릴 것입니다.

유지 관리자들은 이미 인간을 분류 (Triage)하고 있습니다. 그들은 자동화된 작업 또한 분류해야 할 것입니다.

메모리는 프로젝트 거버넌스 (Governance)입니다

메모리 부분은 사람들이 생각하는 것보다 더 중요합니다.

에이전트는 현재 리포지토리를 읽을 수 있습니다. 오래된 이슈를 검색할 수 있습니다. 테스트를 검사할 수 있습니다. 하지만 프로젝트의 메모리는 단순히 파일에 존재하는 것만이 아닙니다.

그것은 왜 그 보기 싫은 API가 공개 상태로 남아 있는지에 대한 이유입니다. 왜 의존성 (Dependency)이 고정되었는지에 대한 이유입니다. 왜 유지 관리자들이 인기 있는 기능을 계속 거부하는지, 왜 릴리스 프로세스 (Release process)가 이상한지에 대한 이유입니다. 왜 현재의 유지 관리자 중 누구도 Windows에서 개발하지 않음에도 불구하고 Windows 지원이 중요한지, 왜 명백한 정리 작업이 3년 동안 연기되었는지에 대한 이유입니다.

에이전트 기반의 오픈 소스가 제대로 작동하려면, 그 메모리가 머물 수 있는 공간이 반드시 필요합니다.

그중 일부는 기여자 문서 (contributor docs), 아키텍처 노트 (architecture notes), 이슈 템플릿 (issue templates), 설계 원칙 (design principles), 그리고 프로젝트 규칙 (project rules)으로 작성될 수 있습니다. 일부는 테스트 (tests)와 CI (지속적 통합)에 인코딩될 수 있습니다. 또 일부는 에이전트 메모리 시스템 (agent memory system)에 존재할 수 있습니다. 하지만 핵심은 동일합니다. 에이전트에게는 단순히 구문 (syntax)뿐만 아니라, 프로젝트의 취향 (taste)과 제약 사항 (constraints)이 필요합니다.

그렇지 않으면 에이전트들은 더 나은 포맷으로 똑같이 나쁜 아이디어들을 계속해서 재발견하게 될 것입니다.

인간의 검토 (human review)는 더 명시적이어야 합니다

"인간의 검토 (human review)"라는 문구는 많은 막연한 기대감을 숨길 수 있습니다.

에이전트의 PR (Pull Request)을 검토한다는 것이, 봇이 모든 체크를 통과했다고 말한다는 이유로 유지 관리자 (maintainer)가 밤 11시에 변경 사항 (diff)을 대충 훑어보는 것을 의미해서는 안 됩니다.

생성된 기여 (generated contributions)에 대해서라면, 저는 PR이 다음과 같은 몇 가지 질문에 명확히 답하기를 바랍니다:

에이전트에게 주어진 작업 (task)은 무엇인가?
어떤 파일이나 동작이 범위 외 (out of scope)였는가?
어떤 테스트를 실행했는가?
어떤 테스트를 실행하지 않았는가?
어떤 기존 이슈, 설계 노트, 또는 유지 관리자의 지침을 따랐는가?
어떤 불확실성이 남아 있는가?

이것은 관료주의가 아닙니다. 검토의 표면 (review surface)을 새로운 생산 속도에 맞추는 것입니다.

에이전트가 더 많은 업무를 만들어낼 것이라면, 검토를 위한 더 나은 증거 또한 만들어내야 합니다.

이것은 실제로 유지 관리자에게 도움이 될 수 있습니다

이 말이 에이전트 기반 오픈 소스에 대한 거부처럼 들리지 않기를 바랍니다. 저는 이 아이디어가 진정으로 유망하다고 생각합니다.

유지 관리자들은 엄청난 양의 영광스럽지 않은 업무를 수행합니다: 버그 재현 (reproducing bugs), 실패 사례 최소화 (minimizing failing cases), 스냅샷 업데이트 (updating snapshots), 작은 불일치 정리 (cleaning small inconsistencies), 마이그레이션 노트 작성 (writing migration notes), 이슈가 여전히 존재하는지 확인, 릴리스 작업 준비 (preparing release chores), 그리고 지저분한 보고서를 실행 가능한 작업 (actionable tasks)으로 전환하는 일 등입니다.

에이전트는 이 작업을 도울 수 있습니다.

비결은 에이전트를 유지 관리자의 대체재 (replacement)가 아니라, 유지 관리자의 레버리지 (leverage)로 겨냥하는 것입니다.

훌륭한 에이전트 워크플로 (workflow)는 유지 관리자의 판단력이 더 멀리 미칠 수 있도록 만들어야 합니다. 컨텍스트 (context)를 준비하고, 옵션을 좁히며, 지루한 체크를 수행하고, 자신의 한계에 대해 정직한 패치 (patch)를 제시해야 합니다.

잘못된 에이전트 워크플로 (workflow)는 지친 인간들에게 더 많은 리뷰 의무를 떠넘기면서 그것을 커뮤니티 참여라고 부릅니다.

그것들은 매우 다른 미래입니다.

핵심 (the punchline)

Warp 사례 연구가 흥미로운 이유는 개발 워크플로 (workflows)가 어디로 향하고 있는지를 보여주기 때문입니다: 인간은 목표를 설정하고, 에이전트 (agents)는 구현 (implementation)의 더 많은 부분을 담당하며, 오케스트레이션 (orchestration) 시스템이 작업을 하나로 묶어줍니다.

하지만 오픈 소스 (open source)의 경우, 어려운 점은 에이전트 (agents)가 코드를 작성할 수 있느냐가 아닙니다.

어려운 점은 프로젝트의 판단력을 책임지는 사람들을 소진시키지 않으면서 프로젝트가 코드를 흡수할 수 있느냐 하는 것입니다.

그러니 네, 에이전트 (agents)를 데려오십시오. 그들이 날카로운 모서리 (sharp edges)를 다듬게 하십시오. 그들이 지루한 잡무를 수행하게 하십시오. 그렇지 않았다면 결코 작성되지 않았을 패치 (patches)를 준비하게 하십시오.

하지만 모델 (model)이 유지 관리자 (maintainer)인 것처럼 가장하지는 마십시오.

유지 관리자 (maintainer)는 무엇이 포함되어야 하는지, 무엇이 오랫동안 가치를 유지할지, 무엇이 신뢰를 깨뜨리는지, 그리고 패치 (patch)가 기술적으로 정확하더라도 프로젝트가 무엇을 거부해야 하는지를 결정하는 사람입니다.

오픈 소스 코딩 에이전트 (open-source coding agents)에게는 더 나은 모델 (models)이 필요합니다.

그들에게는 샌드박스 (sandboxes), 평가 (evals), 메모리 (memory), 권한 (permissions), 그리고 오케스트레이션 (orchestration)도 필요합니다.

하지만 무엇보다도, 그들에게는 다른 모든 이들의 자동화 (automation)를 위한 리뷰 대기열 (review queue)로 전락하는 것으로부터 보호받는 유지 관리자 (maintainers)가 필요합니다.

그렇지 않다면 오픈 소스 (open source)의 미래는 에이전트 (agents)들이 함께 소프트웨어를 구축하는 아름다운 군집 (swarm)이 되지 않을 것입니다.

그것은 더 커진 편지함을 응시하는 동일한 소수의 인간들일 뿐일 것입니다.