Agents, codebases, and teams — Aditya Khandelwal, Amazon AGI Lab
📺 원본 영상: Agents, codebases, and teams — Aditya Khandelwal, Amazon AGI Lab
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-08-11
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료, 차트, 코드, 슬라이드 등은 포함되지 않을 수 있습니다.
개요
이 강연은 코딩 에이전트(Coding Agent)를 개인 개발자의 생산성 도구로만 바라볼 때 왜 조직적 확산이 실패하는지 설명한다. Aditya Khandelwal은 Amazon AGI Lab에서 팀을 이끌며 얻은 경험을 바탕으로, 에이전트 도입의 핵심은 단순히 CLAUDE.md나 AGENTS.md 같은 지침 파일을 만들고 몇 개의 스킬을 추가하는 것이 아니라, 코드베이스와 팀 운영 방식을 함께 바꾸는 데 있다고 주장한다.
강연의 중심 메시지는 명확하다. 에이전트가 잘 작동하지 않는 이유를 “오늘 모델이 멍청하다”는 식으로 개인화하거나 모델 탓으로 돌리기보다, 팀이 공유하는 하네스 엔지니어링(Harness Engineering), 점진적 공개(Progressive Disclosure), 피드백 루프, 그리고 심리적 수용 과정을 설계해야 한다는 것이다. 결국 코딩 에이전트의 성공은 모델 성능만의 문제가 아니라, 조직이 코드를 어떻게 정리하고, 작업을 어떻게 검증하며, 개발자들이 그 시스템을 얼마나 신뢰하게 만드는가의 문제로 귀결된다.
개인의 도구에서 팀의 시스템으로
강연자는 먼저 코딩 에이전트 도입의 초기 흐름을 되짚는다. 처음에는 몇몇 개발자가 에이전트를 활용해 압도적인 생산성을 보여주었고, 이를 본 조직들은 “한 사람이 이렇게 잘한다면 모두에게 쓰게 하면 되지 않을까”라는 방식으로 접근했다. 그러나 곧 문제가 드러났다. 무작정 사용을 강제하고 토큰을 최대한 많이 쓰는 방식, 즉 token-maxing은 비용을 태우는 결과를 낳았고, 실제 프로덕션 환경에서는 품질 낮은 코드와 사고가 뒤따랐다.
이 지점에서 강연자는 개인 개발자의 심리 변화를 중요한 축으로 제시한다. 한쪽에는 “내 일자리가 사라지는가”라는 두려움이 있고, 다른 한쪽에는 “이 도구를 내가 얼마나 자신 있게 쓸 수 있는가”라는 실행 자신감이 있다. 초기에는 두려움은 높고 활용도는 낮았지만, 일부 early adopter가 높은 성과를 내면서 사람들은 에이전트를 배워야 한다고 느끼기 시작했다. 그러나 조직이 사용을 강제하고, 그 결과 품질 낮은 결과물이 쌓이면 개발자들은 다시 회의적으로 돌아선다. 에이전트가 코드를 잘못 만들고, 리뷰 부담만 늘린다고 느끼면 “이건 아직 쓸 만한 도구가 아니다”라는 판단이 강화되기 때문이다.
02:17 - 개발자의 두려움과 에이전트 활용 자신감을 두 축으로 놓고 팀 내 도입 상태를 설명하는 장면
따라서 팀 차원의 에이전트 도입은 단순한 툴 배포 문제가 아니다. 강연자에 따르면, 조직은 개발자들이 두려움은 낮고 활용도는 높은 상태로 이동하도록 도와야 한다. 이 과정에서 가장 위험한 선택은 “각자 알아서 잘 써보라”는 태도다. 그렇게 되면 일부 개발자는 하루에 10개의 PR을 만들고, 다른 개발자는 1~2개의 PR을 만들면서 동시에 앞선 개발자의 코드를 리뷰해야 하는 불균형이 생긴다. 생산성이 올라간 것처럼 보이지만, 실제로는 팀 내부에 품질 부담과 심리적 반감이 축적되는 구조가 된다.
CLAUDE.md 하나로는 충분하지 않다
많은 팀은 에이전트 도입의 첫 단계로 코드베이스 루트에 CLAUDE.md, AGENTS.md, 혹은 유사한 지침 파일을 만들고, 자주 쓰는 스킬을 몇 개 추가한다. 강연자는 이것이 필요한 출발점일 수는 있지만, 그것만으로 문제가 해결된다고 보는 것은 착각에 가깝다고 말한다. 실제 프로덕션 코드베이스에서는 문서, 테스트, CI, 리뷰 문화, 이슈 관리 방식, 코드 소유권, 배포 파이프라인이 모두 얽혀 있기 때문에, 에이전트가 잘 움직이려면 이 전체 환경이 에이전트 친화적으로 정리되어 있어야 한다.
강연자가 제시하는 실패 신호는 꽤 실용적이다. 개발자가 에이전트를 계속 지켜보며 개입해야 한다면, 그것은 좋은 설정이 아니다. 간단한 작업인데도 500k, 750k, 혹은 1M 컨텍스트를 소모하고 auto-compact에 도달한다면, 코드베이스가 필요한 정보를 적절히 제공하지 못하고 있다는 뜻이다. 긴 세션이 계속되고, 사용자가 매번 방향을 바로잡아야 하며, 결과물이 반복적으로 slop이 된다면 모델 하나의 문제가 아니라 하네스와 코드베이스 구조의 문제일 가능성이 크다.
05:24 - 에이전트 사용 실패 신호와 팀 단위 생산성 불균형을 설명하는 장면
여기서 중요한 통찰은 모델 성능을 절대화하지 않는 태도다. 강연자는 사람들이 자주 “오늘 최신 모델이 너무 멍청하다”고 말하지만, 실제로는 모델 자체보다 그 아래의 하네스가 바뀌었거나, 코드베이스가 작은 변화에도 취약하게 구성되어 있을 수 있다고 지적한다. 즉, 에이전트가 충분한 맥락을 적절한 시점에 찾지 못하고, 불필요한 파일을 뒤지며, 검증 루프 없이 긴 작업을 이어간다면 결과가 나빠지는 것은 당연하다. 좋은 에이전트 활용은 프롬프트 한 줄의 문제가 아니라, 코드베이스 전체가 에이전트에게 탐색 가능한 지도처럼 작동하도록 만드는 문제다.
리더십의 문제로 다루어야 하는 이유
강연자는 에이전트 도입을 IC(Individual Contributor) 개인의 책임으로 남겨두면 안 된다고 강조한다. 개인 개발자는 자기 작업 흐름을 개선할 수는 있지만, 코드베이스 구조를 바꾸거나 CI/CD를 재설계하거나 팀 공통의 리뷰 정책을 정비하는 데에는 한계가 있다. 에이전트가 팀 전체에서 잘 작동하게 만들려면 조직 차원의 합의와 리더십의 지원이 필요하다.
이 주장은 단지 관리론적 선언이 아니라 매우 구체적인 엔지니어링 현실에서 나온다. 예를 들어 코드베이스가 에이전트에게 필요한 정보를 단계적으로 제공하려면 문서 위치, 코드 주석, 런북(runbook), 테스트 명령, 모듈 경계, 이슈 관리 방식이 함께 정리되어야 한다. 이런 변화는 한 명의 개발자가 몰래 적용할 수 있는 성질의 일이 아니다. 팀 전체가 “이제부터 에이전트가 이 코드베이스를 이렇게 탐색하게 만들자”는 공통된 기준을 가져야 하고, 그 기준을 계속 유지보수해야 한다.
강연자에 따르면, 조직이 할 수 있는 가장 영향력 있는 일 중 하나는 엔지니어가 에이전트와 함께 더 빠르고 자신 있게 배포할 수 있는 환경을 만드는 것이다. 이는 단순히 생산성을 높이는 문제가 아니라, 사고를 줄이고 리뷰 부담을 균형 있게 분산시키며, 팀 전체의 실행 속도를 끌어올리는 문제다. 따라서 에이전트 도입은 도구 구매나 개인 교육 프로그램이 아니라, 코드베이스 운영 모델을 바꾸는 리더십 과제로 이해해야 한다.
하네스 엔지니어링과 점진적 공개
강연에서 가장 기술적인 핵심은 하네스 엔지니어링(Harness Engineering)이다. 여기서 하네스는 모델이 코드베이스와 상호작용할 때 사용하는 지침, 도구, 문맥 주입 방식, 파일 탐색 경로, 검증 루프를 포함하는 실행 환경을 의미한다. 좋은 하네스는 모델에게 모든 것을 한꺼번에 넣어주는 것이 아니라, 필요한 시점에 필요한 맥락만 제공하도록 설계되어야 한다.
07:35 - 코드베이스 전체를 대상으로 필요한 시점에 필요한 맥락을 주입하는 하네스 엔지니어링 원칙을 설명하는 장면
이를 위해 강연자는 점진적 공개(Progressive Disclosure)를 반복해서 강조한다. CLAUDE.md나 AGENTS.md 같은 최상위 지침 파일은 거대한 백과사전이 아니라 얇은 색인(thin index)이어야 한다. 에이전트가 처음 작업을 시작할 때 이 파일을 읽고, 거기서 필요한 하위 문서와 런북, 테스트 방법, 코드 규칙으로 이동할 수 있어야 한다. 반대로 모든 규칙과 배경지식을 최상위 파일에 몰아넣으면 시작부터 컨텍스트가 비대해지고, 에이전트는 정작 필요한 세부 정보를 찾기 전에 토큰을 낭비하게 된다.
강연자는 코드 주석의 역할도 중요하게 본다. 특정 코드가 별도의 런북이나 운영 문서를 필요로 한다면, 그 연결이 코드 주변 주석에 드러나야 한다. 에이전트가 해당 파일에 도달했을 때 “이 코드를 제대로 이해하려면 이 문서를 봐야 한다”는 단서를 얻을 수 있어야 하기 때문이다. 이는 사람이 읽기 위한 문서화와도 겹치지만, 에이전트 시대에는 문서의 위치와 연결 구조 자체가 실행 품질에 직접 영향을 주는 인프라가 된다.
점진적 공개가 잘 작동하는지 판단하는 기준도 실용적이다. 강연자는 첫 프롬프트를 줬을 때 에이전트가 곧바로 무차별적으로 grep을 시작하는지, 아니면 어디로 가야 하는지 알고 움직이는지를 보라고 말한다. 기본적으로 20k에서 25k 정도의 토큰은 사용될 수 있지만, 시작하자마자 40k나 50k로 불어난다면 설계가 잘못되었을 가능성이 높다. 이 기준은 에이전트 워크플로를 감으로 판단하는 대신, 컨텍스트 소비량과 탐색 행동으로 진단하라는 매우 구체적인 운영 지표로 볼 수 있다.
15:36 - CLAUDE.md 또는 AGENTS.md를 얇은 인덱스로 유지하고 Progressive Disclosure를 구현하는 구체적 전략을 설명하는 장면
한 가지 고가치 스킬에 집중하기
강연자가 팀에서 적용한 플레이북 중 특히 인상적인 부분은 “하나의 고가치 스킬”에 집중했다는 점이다. 이 팀의 경우 그 스킬은 Ship It이라는 이름으로 불렸고, 개발자가 코드를 작성한 이후부터 PR이 리뷰 가능한 상태가 될 때까지의 과정을 맡았다. 여기에는 PR 생성, PR 설명 작성, 코멘트 처리, 머지 관련 코멘트 정리, CI 실패 대응 등이 포함된다.
09:56 - 코드 완료 후 PR 준비, 코멘트 처리, CI 실패 대응까지 수행하는 Ship It 스킬을 설명하는 장면
이 접근이 중요한 이유는 에이전트 도입의 신뢰 형성과 직결되기 때문이다. 팀원들이 처음부터 모든 작업을 에이전트에게 맡기기는 어렵다. 그러나 코드 작성 이후 PR 준비까지의 반복적이고 귀찮은 구간을 안정적으로 자동화하면, 개발자는 “이 AI는 실제로 내 일을 덜어준다”는 경험을 하게 된다. 강연자는 이 스킬이 한 시간 이상 실행되는 경우도 있었고, 처음에는 사람들이 이를 불안하게 느꼈다고 설명한다. 하지만 시간이 지나 결과가 쌓이면, 긴 실행 시간은 오히려 개발자가 다른 일을 할 수 있게 해주는 신뢰의 근거가 된다.
이 사례는 에이전트 도입에서 “작은 성공 경험”이 얼마나 중요한지를 보여준다. 팀 전체에 수많은 스킬을 뿌리는 것보다, 정말 고통스럽고 반복적인 한 지점을 정확히 자동화하는 편이 더 효과적일 수 있다. 특히 PR 준비와 CI 대응은 개발자가 이미 규칙을 알고 있지만 매번 시간을 빼앗기는 영역이기 때문에, 에이전트가 가치를 증명하기 좋은 지점이다. 이런 성공 경험이 쌓이면 회의적인 개발자도 도구를 단순한 실험이 아니라 팀의 실제 생산성 인프라로 받아들이기 시작한다.
닫힌 루프와 자기 회복 시스템
강연자는 slop이 완전히 사라질 것이라고 기대하지 않는다. 오히려 어느 정도의 품질 낮은 결과물은 필연적으로 스며들기 때문에, 이를 감지하고 제거하며 시스템을 회복시키는 루프를 만들어야 한다고 말한다. 이 관점은 에이전트 활용을 “완벽한 자동화”가 아니라 “오류를 포함한 반복 시스템”으로 보는 데서 출발한다.
팀이 적용한 방식은 이슈와 보드를 코드베이스에 연결하고, CI/CD와 agentic review를 붙이며, 매일 밤 코드베이스를 점검하는 code gardener를 운영하는 것이었다. code gardener는 코드가 올바르게 조직되어 있는지 확인하는 역할을 한다. 여기서 “올바른 조직”의 의미는 모든 팀에 동일하게 적용되는 보편 규칙이 아니라, 각 코드베이스의 구조와 운영 기준에 따라 달라진다. 중요한 것은 에이전트가 만든 결과물을 인간 리뷰에만 의존해 거르는 것이 아니라, 시스템 자체가 반복적으로 품질을 점검하게 만드는 것이다.
10:42 - 이슈, 보드, CI/CD, agentic review, code gardener를 연결해 닫힌 피드백 루프를 만드는 방식을 설명하는 장면
이 구조는 전통적인 소프트웨어 엔지니어링 원칙과도 맞닿아 있다. 테스트가 없는 자동화는 신뢰하기 어렵고, 리뷰 체계가 없는 대량 PR은 팀을 압박하며, 문서 연결이 없는 에이전트는 불필요한 탐색으로 비용을 태운다. 따라서 에이전트 시대의 좋은 코드베이스는 단지 사람이 읽기 좋은 코드베이스가 아니라, 자동화된 작업자가 탐색하고 수정하고 검증할 수 있는 코드베이스여야 한다. 강연자의 표현을 빌리면, slop이 들어오는 것을 전제로 하되 이를 닫힌 루프 안에서 감지하고 회복하는 구조가 필요하다.
회의론자를 설득하는 것이 진짜 테스트다
강연자는 에이전트 도입에서 회의적인 사람들을 단순히 “두려워하는 사람”으로 치부해서는 안 된다고 말한다. 오히려 회의론자를 설득할 수 있다면, 팀이 올바른 방향으로 가고 있다는 신호에 가깝다. 회의적인 개발자는 품질, 검증, 리뷰 부담, 장기 유지보수성에 민감하게 반응하기 때문에, 이들이 받아들일 수 있는 시스템은 실제 운영 환경에서도 버틸 가능성이 높다.
이를 위해서는 공유 설정을 일방적으로 강요하기보다, 팀원들이 그 설정을 직접 수정하고 실험할 수 있어야 한다. 강연자는 사람들이 공통 설정을 “가지고 놀 수 있고 편집할 수 있어야” 진짜로 투자하게 된다고 설명한다. 이 말은 에이전트 운영 체계를 중앙에서 만든 정답으로 배포하는 것이 아니라, 팀 전체가 계속 개선하는 코드 자산처럼 다뤄야 한다는 의미다.
동시에 이는 엔지니어에게 불편한 사실을 요구한다. 자신의 개인 설정이 완벽하지 않을 수 있고, 팀의 더 나은 관행을 받아들여야 하며, 설정은 영원히 완성되지 않는다는 사실을 인정해야 하기 때문이다. 강연자는 일정 비율의 IC 시간이 이 시스템을 개선하는 데 쓰일 수밖에 없다고 말한다. 당장은 의미 있는 PR로 보이지 않을 수 있지만, 장기적으로는 팀 전체의 에이전트 활용 능력을 끌어올리는 투자다.
실제로 부딪힌 문제들
강연자는 자신들의 접근이 완벽했다고 말하지 않는다. 오히려 매우 많은 문제가 있었고, 그것을 피드백으로 삼아 반복했다고 설명한다. 대표적인 문제는 이슈 폭증이었다. 팀은 몇 주 안에 400~500개의 이슈가 생기는 상황을 겪었고, 여러 에이전트가 제대로 연결되지 않은 상태에서 각자 이슈를 생성하면서 저장소가 혼란스러워졌다.
12:04 - 수백 개의 이슈가 생성되는 문제와 에이전트 운영 과정에서 발생한 실제 실패 사례를 설명하는 장면
또 다른 문제는 기대치의 불일치였다. 어떤 개발자는 스킬이 자신이 기대한 방식으로 동작하지 않으면 곧바로 개인적으로 에이전트를 지켜보는 방식으로 돌아가려 했다. 그러나 강연자는 그런 반응을 실패로만 볼 것이 아니라, 피드백을 스킬과 공유 설정에 반영해야 한다고 강조한다. 불편함이 생겼을 때 개인 워크플로로 후퇴하는 대신, 팀의 공통 하네스를 개선하는 재료로 삼아야 한다는 것이다.
에이전트가 오래 걸리는 문제도 있었다. 하지만 강연자는 이것을 반드시 나쁜 신호로 보지 않는다. reasoning 중심의 모델에서는 더 오래 생각할수록 결과가 좋아질 수 있고, 에이전트가 신뢰할 수 있는 루프 안에서 오래 실행된다면 개발자는 그 시간 동안 다른 일을 할 수 있다. 문제는 시간이 긴 것 자체가 아니라, 긴 시간 동안 무엇을 하고 있는지 알 수 없고, 검증 루프가 없으며, 결과를 믿을 수 없는 상태다.
마지막으로 merge hell과 실험 코드 문제가 있었다. 많은 사람이 에이전트로 코드를 만들면 머지 충돌은 필연적으로 늘어난다. 또한 실험용 코드와 실제 배포될 코드를 같은 기준으로 다루면 불필요한 마찰이 생긴다. 강연자는 프로토타입은 프로토타입으로 취급하고, 엄격한 프로덕션 기준에서 벗어날 수 있는 별도의 경로를 마련해야 한다고 설명한다. 이는 품질을 낮추자는 뜻이 아니라, 탐색과 배포를 같은 파이프라인에 억지로 넣지 말라는 현실적인 조언이다.
“모델이 멍청하다”에서 “우리가 더 똑똑하게 만들려면”으로
강연의 후반부에서 가장 중요한 태도 변화가 등장한다. 강연자는 “모델이 너무 멍청하다”고 말하는 대신, “어떻게 하면 내가, 더 정확히는 우리가 공유 설정을 더 똑똑하게 만들 수 있을까”라고 물어야 한다고 말한다. 여기서 그는 “my setup”이 아니라 “shared setup”을 강조한다. 에이전트 도입은 개인의 프롬프트 비법 경쟁이 아니라, 팀이 함께 개선하는 운영 체계의 문제라는 것이다.
이 관점은 에이전트 시대의 소프트웨어 조직에 중요한 기준을 제시한다. 모델이 바뀌고, 하네스가 바뀌고, 코드베이스가 커지고, 팀원의 숙련도가 달라지면 기존 설정은 언제든 낡을 수 있다. 따라서 좋은 설정을 한 번 만드는 것보다, 설정이 낡는 것을 전제로 계속 고치는 체계가 더 중요하다. 팀은 에이전트의 실패를 개인의 실패나 모델의 결함으로만 해석하지 말고, 코드베이스가 어떤 신호를 충분히 주지 못했는지, 검증 루프가 어디서 끊겼는지, 문서 연결이 어디서 부족했는지를 질문해야 한다.
강연자는 이를 스키를 배우는 경험에 비유한다. 속도를 두려워해 계속 제동만 걸면 오히려 넘어지기 쉽고, 어느 순간에는 속도에 몸을 맡기며 방향 전환을 익혀야 한다는 것이다. 에이전트 도입도 비슷하다. 실패하지 않으려는 태도로 모든 것을 손으로 붙잡고 있으면 팀은 끝내 자동화의 감각을 얻지 못한다. 중요한 것은 넘어지지 않는 것이 아니라, 넘어졌을 때 회복할 수 있는 시스템을 갖추는 것이다.
참고할 만한 개념
이 강연은 특정 라이브러리나 모델 사용법을 다루기보다, 에이전트 친화적인 코드베이스 운영 원칙을 다룬다. 따라서 함께 참고하면 좋은 개념은 Prompt Engineering 자체보다 Context Engineering, Developer Experience, CI/CD 자동화, Internal Developer Platform, 그리고 Socio-technical System에 가깝다. 특히 에이전트가 필요한 정보를 한 번에 모두 받는 것이 아니라, 작업 과정에서 필요한 만큼 찾아가도록 만드는 Progressive Disclosure는 대규모 코드베이스에서 컨텍스트 비용과 품질을 동시에 관리하는 핵심 설계 원칙으로 볼 수 있다.
또한 code gardener라는 표현은 강연자의 팀 맥락에서 나온 운영 개념이지만, 넓게 보면 정적 분석, 리팩터링 봇, nightly check, architecture lint, documentation drift detection과 같은 자동 품질 관리 흐름과 연결된다. 에이전트가 코드를 대량으로 생성하는 환경에서는 이런 자동 점검 장치가 선택 사항이 아니라 기반 시설에 가까워진다. 사람이 모든 PR의 구조적 일관성을 수작업으로 검토하는 방식은 에이전트가 만드는 작업량을 따라가기 어렵기 때문이다.
마무리 / 핵심 정리
이 강연의 핵심은 코딩 에이전트를 잘 쓰는 팀은 모델을 많이 쓰는 팀이 아니라, 모델이 좋은 판단을 할 수 있도록 코드베이스와 작업 흐름을 정리한 팀이라는 점이다. CLAUDE.md나 AGENTS.md 파일을 만드는 것은 출발점일 뿐이며, 진짜 과제는 그 파일을 얇은 인덱스로 유지하고, 필요한 문서와 런북을 코드 가까이에 연결하며, CI/CD와 리뷰 루프를 통해 결과물을 지속적으로 검증하는 데 있다.
Aditya Khandelwal은 에이전트 도입을 리더십의 문제이자 인간의 문제로 본다. 개발자들의 두려움과 회의론을 무시한 채 사용을 강제하면, 조직은 생산성 향상 대신 리뷰 부담과 품질 저하를 얻게 된다. 반대로 회의론자를 설득할 만큼 견고한 공유 설정을 만들고, 팀 전체가 그 설정을 반복적으로 개선하게 만들면 에이전트는 개인의 장난감이 아니라 조직의 실행 능력을 높이는 인프라가 된다.
결국 질문은 “오늘 모델이 왜 이렇게 못하지?”가 아니다. 더 정확한 질문은 “우리의 공유 하네스와 코드베이스는 이 에이전트를 충분히 똑똑하게 만들고 있는가?”이다. 이 질문을 계속 던지는 팀만이 에이전트가 만드는 속도와 실패를 감당하면서도, 실제 프로덕션 환경에서 의미 있는 결과를 낼 수 있다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Agents, codebases, and teams — Aditya Khandelwal, Amazon AGI Lab |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-08-11 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.
Related Reports
- Harness Engineering - How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI
- Simon Willison in conversation with Cat Wu & Thariq Shihipar, Anthropic
- From Blind Spots to Merged PRs Continuous Agentic Performance Optimization - May Walter, Hud
- Don’t Build Agents You Can’t Answer For — Addy Osmani
- Velocity Sickness - What Happens When Your Whole Team Gets 10x Faster — Matt Dailey, Ref.