The Agents Were Fine. Everything Around Them Broke. - Joey Wang, Harvey

한 줄 핵심

에이전트 자체보다 더 중요한 것은 에이전트가 실제 업무를 끝까지 수행하도록 감싸는 하네스·권한·큐·검증 체계이며, 이 주변 시스템이 없으면 에이전트는 곧바로 규모와 안정성 문제에 부딪힌다.

시간별 요약

1. 0:00
   에이전트보다 어려운 것은 주변 시스템 Harvey의 클라우드 에이전트 플랫폼은 한 달에 수천 개의 PR을 만들 정도로 사용이 늘었지만, 실제로 문제를 일으킨 것은 모델이 아니라 그 주변의 실행·검증·병합 체계였다. 에이전트는 쉽게 시작할 수 있지만, 조직 전체에서 안전하게 쓰려면 클라우드, 비밀 정보, 실제 스택, 알림, 규칙이 함께 움직여야 한다.
2. 3:01
   코드 작성보다 중요한 후속 루프 사용자는 원하는 에이전트를 무엇이든 선택해도 되지만, 핵심은 로컬에서 시작한 작업을 클라우드로 넘기고 다시 되돌릴 수 있는 공통 레이어다. 특히 실패한 CI를 읽고 다시 수정해 PR까지 마무리하는 후속 루프가 없으면 에이전트는 코드를 '작성'만 하고 일을 '완료'하지 못한다.
3. 5:01
   도구 호출과 지식 공유의 표준화 사람이 클릭으로 할 수 있는 일이라면 에이전트도 호출할 수 있게 만들어야 하며, CLI·브라우저·샌드박스·CI에서 같은 작업을 시작할 수 있어야 확장된다. 또 팀의 암묵지와 운영 노하우를 문서화하고 감사 추적과 검증을 남겨야 에이전트가 개인의 기억에 의존하지 않고 같은 품질로 일할 수 있다.
4. 7:01
   과부하를 막는 공정한 큐와 자원 관리 알림 폭주나 대량 작업이 한꺼번에 몰리면 하나의 버그가 수백·수천 개의 작업으로 증폭되므로, 중복 알림 병합과 공정한 런치 큐가 필요하다. 작업 시작 지연을 줄이고, 사람이 직접 시작한 작업에 우선권을 주며, 클러스터 자원을 공정하게 배분하지 않으면 에이전트가 플랫폼 자체를 멈춰 세운다.
5. 10:01
   자동화가 커질수록 안전장치가 핵심 가장 빠르게 늘어난 사용 방식은 사람이 시작하는 작업이 아니라 스케줄·이벤트 기반 자동화였고, 실패 반복 시 자동 중지와 예산·만료일 같은 가드레일이 필수였다. 앞으로는 Slack 채널 단위의 상시 에이전트와 사전 검증된 병합이 늘어날수록, 병합·검증·권한 통제가 제품의 성패를 좌우하게 된다.

실무 인사이트

• 에이전트 도입의 성패는 모델 성능보다 작업 시작, 실패 재시도, 검증, 병합까지 이어지는 실행 경로를 얼마나 표준화했는지에 달려 있다.
• 대규모 에이전트 운영에서는 중복 작업 억제, 공정한 큐잉, 자원 상한 설정이 없으면 사용자 편의가 곧바로 시스템 장애로 바뀐다.
• 팀 지식과 운영 규칙을 문서화해 에이전트가 참조하게 만들면, 특정 개인의 경험에 묶인 병목을 줄이고 안정적인 자동화를 만들 수 있다.