Agents, codebases, and teams — Aditya Khandelwal, Amazon AGI Lab

한 줄 핵심

에이전트를 팀에 실제로 정착시키려면 개인의 사용법이 아니라 코드베이스 구조, 피드백 루프, 그리고 사람의 불안까지 포함한 조직 설계를 함께 바꿔야 한다.

시간별 요약

1. 0:01
   개인 저장소에서는 통하던 에이전트 설정도 팀의 실서비스 환경에서는 쉽게 무너진다. 핵심 문제는 도구 자체보다 여러 사람이 함께 쓰는 생산 환경에서 어떻게 같이 ship할 수 있게 만드느냐에 있다.
2. 1:00
   에이전트 도입은 처음엔 두려움이 높고 활용은 낮다가, 일부 사용자가 큰 성과를 내면 확산되지만, 무분별한 token maxing과 AI slop 때문에 다시 회의론이 커지는 흐름을 보인다. 결국 비용과 품질 문제를 동시에 해결하지 않으면 팀 차원의 지속 사용으로 이어지지 않는다.
3. 4:00
   에이전트가 자꾸 babysitting을 필요로 하거나, 긴 세션과 잦은 개입, 불필요한 컨텍스트 소모가 발생하면 코드베이스와 하네스 설계가 잘못된 신호다. 이런 문제는 모델의 단순 성능 문제가 아니라, 팀이 공유하는 실행 환경이 에이전트 친화적으로 설계되지 않았다는 뜻이다.
4. 7:01
   해결의 핵심은 harness engineering이며, 코드를 단순히 잘 쓰는 것이 아니라 필요한 정보를 제때 찾게 만드는 구조를 설계하는 일이다. smart prompt injection, close the loop, 지속적 개선, 그리고 인간의 두려움을 다루는 접근이 함께 있어야 팀 전체의 채택이 가능해진다.
5. 9:00
   실행 전략은 작동하는 관행을 찾아 공유하고, 고가치 skill 하나를 끝까지 다듬고, issues·boards·CICD·code gardener로 피드백 루프를 닫는 방식이다. 또한 skeptical한 구성원을 설득해 shared setup을 함께 편집하게 만들어야 진짜 조직 표준이 된다.
6. 12:02
   운영하면서는 issue 폭증, 에이전트 간 충돌, 긴 추론 시간, merge hell, 실험용 slop 같은 문제가 반드시 생긴다. 이를 실패로 보지 말고 prototype은 별도 표준으로 다루고, 사용자의 불만을 개별 탓이 아니라 shared setup 개선 신호로 받아들여야 한다.
7. 14:01
   progressive disclosure는 skill.md를 짧고 얇게 유지하고, runbook을 코드 주석과 연결하며, 첫 프롬프트에서 에이전트가 어디로 가야 하는지 알게 만드는 방식으로 구현된다. 초기 컨텍스트 소모량이 과도하게 커지면 설계가 잘못된 것이므로, 기준을 정해 반복적으로 튜닝해야 한다.

실무 인사이트

• 에이전트 도입 성패는 모델보다 팀의 공유 실행 구조에 더 크게 좌우되므로, 개인 생산성 실험이 아니라 조직 표준화 과제로 다뤄야 한다.
• 첫 성공 사례를 만드는 것보다, babysitting 없이도 돌아가게 하는 루프 설계와 컨텍스트 절약 구조를 만드는 것이 장기적으로 더 중요하다.
• 실무에서는 단일 skill의 완성도, 짧은 인덱스형 문서, 코드 주석과 runbook 연결, 야간 점검 자동화를 우선 적용하면 효과를 빨리 볼 수 있다.