코딩 에이전트가 여러분을 관리자로 만들었다
TMT에이전트를 관리하는 기술은 사실상 팀을 관리하는 기술과 같습니다. 그리고 이 기술을 배우기 위해 관리자가 될 필요는 없습니다.
하루 종일 코딩 에이전트와 함께 일하고 있다면, 여러분은 이미 관리를 하고 있는 것입니다. 작업을 고르고, 지시를 쓰고, 일을 맡기고, 진행 상황을 챙기고, 결과를 평가하고, 무엇을 출시할지 결정하는 일을 되풀이하고 있으니까요. 에이전트를 가장 잘 활용하는 엔지니어가 반드시 프롬프트 엔지니어링을 가장 잘하는 사람인 것은 아닙니다. 의도했든 아니든 관리하는 법을 익힌 사람들입니다.
반갑지 않은 이야기일 수도 있습니다. 제가 존경하는 엔지니어 중 상당수는 실무 가까이에 머물고 싶어서 개인 기여자(IC, individual contributor) 경력 경로를 택했습니다. 그들은 관리자가 된 친구들이 일정표 속으로 사라지는 모습을 봐 왔습니다. 하지만 저는 그런 관리자가 되라고 말하는 것이 아닙니다. 저는 "관리"라는 말을 특정한 의미로 쓰고 있습니다. 다른 사람이 일을 잘할 수 있게 해서 좋은 결과를 만들어 내는 것입니다. 그리고 에이전트가 관리자나 동료를 대신할 수 있다고 말하는 것은 더더욱 아닙니다.
나쁜 관리자에 대해 품어 온 불만 하나하나가 에이전트와 일하는 방식에 대한 버그 리포트입니다. 업무 인계를 생각해 보십시오. 나쁜 인계를 겪어 봤다면, 요청이 모호하거나, 맥락이 빠져 있거나, 기대치가 자꾸 바뀌었던 경험이 있을 것입니다. IC에게 좋은 소식은, 여러분이 수년 동안 인계를 받는 쪽에 있었으니 좋은 인계가 어떤 모습인지 알고 있을 수 있다는 점입니다.
저는 예전에 코딩 에이전트에게는 관리자가 필요하다는 글을 쓴 적이 있습니다. 위임에 숨어 있는 조용한 위험인 인지적 항복(cognitive surrender)에 대해서도 썼습니다. 이 글에서는 훌륭한 엔지니어링 관리자의 실천 방식을, 저희가 Claude Code를 사용하고 만들면서 배운 것과 비교합니다. 섹션은 대략 효과가 큰 순서로 배치해서, 가장 큰 효과를 내는 습관이 맨 앞에 오도록 했습니다.
스스로 작업을 확인할 방법 주기
모범 사례: 테스트 스위트, 빌드, 스크린샷처럼 에이전트가 자기 작업을 검증할 수 있는 수단을 제공하고, 그 결과를 증거로 보여 주게 합니다.
안티패턴: "끝난 것 같다"는 겉모습을 완료 확인으로 받아들이는 것입니다. 이렇게 하면 검증을 전부 여러분이 떠안게 되고, 결국 여러분이 에이전트의 테스트 스위트가 됩니다.
경험 많은 관리자에게 모든 것을 다 읽지 않고도 팀이 좋은 결과물을 내고 있다고 어떻게 확신하는지 물어보면, 가드레일 이야기를 할 것입니다. CI, 코드 리뷰, 대시보드, 온콜 같은 것들입니다. 가드레일을 만들지 않는 경험 없는 관리자는 결국 모든 것을 직접 검증하게 되고, 한 분기도 지나지 않아 병목이 됩니다. 에이전트도 마찬가지입니다. Claude Code 모범 사례 가이드에서 설명하듯, 에이전트는 작업이 끝난 것처럼 보이면 멈춥니다. 검증 수단이 없다면, 에이전트가 가진 유일한 검증은 "끝난 것 같다"는 판단뿐입니다. 작업을 검증할 수단을 제공하면, 에이전트는 작업을 하고, 검증기를 실행하고, 실패를 확인하고, 스스로 고칠 수 있습니다. UI 변경이라면 실제로 브라우저에서 페이지를 열고, 제대로 동작하고 보기에도 좋을 때까지 반복하는 것이 될 수 있습니다.
검증 수단은 통과인지 실패인지를 확실하게 가려 주기만 하면 거의 무엇이든 될 수 있습니다. 테스트, 빌드 종료 코드, 린터, diff 스크립트, 스크린샷 같은 것을 떠올려 보십시오. 가이드에 따르면 이런 검증을 실행하는 명령은 CLAUDE.md에 넣을 수 있는 줄 가운데 가장 유용한 한 줄입니다. CLAUDE.md는 에이전트가 세션을 시작할 때마다 읽는 지침 파일입니다. 검증 수단을 갖췄다면, 다음과 같은 방법으로 워크플로에 도입할 수 있습니다.
- 요청합니다. "작업이 끝나면 auth 테스트를 실행하고, 통과할 때까지 계속해."
- 목표를 정합니다.
/goal을 쓰면 별도의 모델이 매 턴이 끝날 때마다 조건을 확인합니다. 오래 걸리는 백그라운드 작업을 할 때 가장 유용합니다. - 강제합니다. Stop 훅을 쓰면 타입 검사가 통과할 때까지 턴이 끝나지 않게 막을 수 있습니다.
- 리뷰를 받습니다.
/code-review는 diff를 (여러분의 대화를 보지 못한) 새 서브에이전트에게 보내 리뷰를 받습니다. 작성자가 자기 PR을 직접 승인하지 않는 것과 같은 이치입니다.
리뷰의 범위도 조절할 수 있습니다. 문제를 찾아 달라고 하면 에이전트는 언제나 뭔가를 찾아냅니다. 하지만 스타일은 무시하고 정확성 문제만 찾아 달라고 하면 그렇게 합니다. 좋은 관리자가 피드백을 요청하는 법을 익히는 방식도 이와 같습니다. Claude Code 도구 모음에 있는 기능 대부분은 결국 이 루프를 촘촘하게 만드는 데 목적이 있습니다. 스킬, 훅, 서브에이전트, MCP는 모두 작업을 하는 단계와 작업을 검증하는 단계 사이의 간극을 메우려고 존재합니다. 그래서 여러분은 에이전트가 검증하지 못한 부분에만 집중하면 됩니다. 경험 많은 엔지니어링 관리자가 하는 일이 바로 이것입니다.
명확한 맥락 제공하기
모범 사례: 저장소를 살펴봐서는 에이전트가 알 수 없는 내용을 명확하게 요약해 줍니다. 작업의 목표와 그것이 중요한 이유, 제약 조건, 범위에서 빠지는 항목, 성공 기준이 여기에 들어갑니다.
안티패턴: 실제 기대치는 머릿속에만 둔 채 한 줄짜리 작업을 넘기거나, 에이전트가 코드를 읽으면 알아낼 내용으로 지시서를 부풀리는 것입니다.
유능한 관리자는 원하는 결과, 제약 조건, 목표를 명확하게 설명합니다. 일이 무엇을 이뤄야 하는지는 분명히 밝히지만, 어떻게 할지는 일을 맡은 사람이 자유롭게 정하게 둡니다. 군대에서는 이것을 지휘관의 의도(commander's intent)라고 부릅니다. Netflix에서는 "통제가 아니라 맥락(context, not control)"이라고 부릅니다.
에이전트와 일할 때 어려운 점은 에이전트에게 어떤 맥락이 빠져 있는지 알기 어렵다는 것입니다. 코딩 에이전트는 어떤 작업이든 가장 먼저 여러분의 코드를 읽습니다. 요즘 모델은 폴더 구조, 컨벤션, 테스트 구성을 여러분이 설명하는 것보다 훨씬 빠르게 파악해 냅니다.
무언가를 적기 전에, 에이전트가 스스로 알아낼 수 있는 것이 무엇인지 생각해 보십시오. 에이전트가 코드에서 읽을 수 있고 실제로 읽으러 갈 내용이라면 아무 말도 할 필요가 없습니다. 말은 저장소에 없는 부분에 쓰십시오. 예를 들면 회의에서 내린 결정, 누군가가 따르는 사내 배포 절차, 이 작업이 중요한 이유, 이번에는 어디까지 해야 끝난 것인지 같은 것들입니다.
"대시보드를 더 빠르게 만들어 줘"라는 모호한 작업을 예로 들어 프롬프트로 바꿔 보겠습니다. 여기 나오는 숫자는 예시일 뿐입니다.
구성원이 1만 명 이상인 조직에서 /team 대시보드의 p95 로딩 시간을 2초 미만으로 줄여 줘.
이유: 엔터프라이즈 관리자들이 매일 이 화면을 여는데, 느린 로딩이 지원 티켓 1순위야.
제약 조건: 스키마 변경 금지, API 응답 형태 유지.
범위 밖: UI 변경, 페이지 전체 캐싱.
확인: scripts/perf/team.sh를 실행하고 변경 전후 수치를 보여 줘.모든 작업에 이렇게 할 필요는 없습니다. 탐색하는 성격의 작업이라면 일반적인 프롬프트를 써도 전혀 문제없습니다. 진행하면서 조금 더 다듬으면 됩니다. 아직 프롬프트를 쓸 준비가 되지 않았다면, 에이전트가 사양을 쓸 수 있을 때까지 여러분을 인터뷰하게 하고, 그 사양을 파일로 저장한 다음, 새 세션을 열어 그 사양을 바탕으로 만들게 하십시오. 그 사양은 나중에 결과물을 검토하는 기준으로도 쓸 수 있습니다.
에이전트에게 이슈 트래커, 오류 대시보드, 팀 채팅 같은 다른 도구에 대한 접근 권한을 줘야 할 수도 있습니다. 에이전트를 팀에 새로 들어온 동료처럼 대하십시오. gh처럼 에이전트가 이미 아는 CLI 도구라면 따로 알려 줄 필요가 없는 경우가 많습니다.
모든 교정이 쌓이게 하기
모범 사례: 같은 내용을 두 번 이상 교정했다면, 팀의 CLAUDE.md에 기록하거나 공유 스킬로 만듭니다. 시간이 지나면서 새 모델이 이런 교정의 필요를 줄여 주는지 확인합니다.
안티패턴: 세션마다 같은 내용을 직접 교정하거나, 내 컴퓨터에만 있는 암묵지에 기대는 것입니다.
CLAUDE.md의 가치를 최대한 끌어내는 팀은 이 파일을 꽤 자주 업데이트하고, 다시 겪지 않도록 막을 만한 실수에서 얻은 교훈을 적어 둡니다. 코드 리뷰에서 @claude를 멘션해 피드백을 영구적인 정책으로 바꾸는 팀도 있습니다. CLAUDE.md는 간결하게 유지하십시오. 여기에 들어갈 만한 내용은 다음과 같습니다.
- 무언가를 검증하는 방법(정확한 명령)
- 코드에서 오해하기 쉬운 영역
- 저장소에 남아 있지 않은 결정
- 두 번 교정한 모든 것
모두 글로 남긴 정보는 시간이 지날수록 가치가 쌓인다는 것을 보여 주는 예입니다. 이런 정보는 사람이 팀을 옮기고 모델이 교체된 뒤에도 남습니다.
판단은 맡기고, 양보할 수 없는 것만 강제하기
모범 사례: 기본적으로는 에이전트가 결정하게 하고, 반드시 일어나야 하거나 절대 일어나서는 안 되는 몇 가지에만 훅이나 거부 규칙 같은 강제 수단을 씁니다.
안티패턴: 규칙을 전부 대문자로 쓰거나, 선택 사항에 불과한 선호에 훅을 정의하거나, 새 모델이 이미 넘어선 지 오래인 옛 모델 시절의 습관을 계속 붙들고 있는 것입니다.
앤디 그로브(Andy Grove)는 『하이 아웃풋 매니지먼트(High Output Management)』에서 이를 업무 관련 성숙도(task-relevant maturity)라고 설명합니다. 감독의 수준은 그 사람의 전반적인 역량이 아니라, 바로 그 업무에서 보여 온 성과 이력에 따라 정해야 한다는 것입니다.
신임 관리자에게 주는 오래된 조언도 같은 이야기를 합니다. 사람들에게 여러분이 편하게 느끼는 것보다 조금 더 많은 재량을 주되, 뒤를 받쳐 주고 책임을 지게 하라는 것입니다.
Claude Code는 이 생각을 받아들여 명시적으로 만듭니다. 프롬프트, CLAUDE.md, 스킬은 모델이 고려해서 따를지 선택할 수 있는 요청입니다. 반면 훅, 거부 규칙, 관리형 설정은 항상 강제되는 요구 사항입니다. 대부분의 경우에는 에이전트가 판단하게 두는 편이 좋습니다. 실제 코드를 보고 있는 모델이, 여러분이 미리 정해 둔 규칙보다 어떤 지침이 적용되는지 더 잘 판단할 수 있는 경우가 많습니다. 강제 수단은 "생성된 클라이언트는 절대 수정하지 말 것"이나 "라이선스 헤더 스크립트를 항상 실행할 것" 같은 확고한 요구 사항을 정할 때 쓰십시오. 특히 새 터미널 세션과 VS Code 세션은 자동 모드로 시작합니다. 이 모드에서는 분류기가 프로덕션 배포나 다른 사람의 작업을 덮어쓰는 강제 푸시 같은 위험한 동작을 걸러 냅니다.
가이드의 조언에는 양면이 있습니다. CLAUDE.md의 어떤 줄을 아무리 강조해도 에이전트가 따르지 않는다면, 그 내용은 훅이 되어야 합니다. 반대로 어떤 훅이 요구 사항이 아니라 선호를 표현하고 있다면, 그 훅은 없애고 에이전트가 판단하게 두어야 합니다. 더는 쓸모없는 프로세스를 팀이 폐지하기로 하는 것과 비슷합니다. 새 모델이 나오면 이런 조정도 해야 한다는 뜻이기도 합니다. 가이드에는 이제 그만둬도 되는 습관 목록이 있습니다. 전부 대문자로 쓴 지시, "더 깊이 생각해"(이제 노력 수준은 설정 항목입니다), "게으르게 굴지 마" 같은 것들입니다. 요즘 모델에서는 이런 표현이 규칙을 과하게 지키고 일을 지나치게 많이 하는 결과로 이어지기 쉽습니다. 에이전트에게는 과도한 프로세스가 새로운 형태의 마이크로매니지먼트입니다.
만들기 전에 계획하기
모범 사례: 에이전트가 코딩을 시작하기 전에 합의된 계획을 세우고, 그 안에 깔린 가정을 읽어 내며, 작업을 서로 겹치지 않는 병렬 작업으로 나눕니다.
안티패턴: 여러 에이전트가 서로 겹치는 작업을 동시에 붙잡게 놔두고, 오후 내내 머지 충돌과 중복된 결정을 정리하는 데 쓰는 것입니다.
여기서 좋은 워크플로는 먼저 계획 모드로 들어가 올바른 계획이 나올 때까지 다듬은 다음, 코딩을 맡기는 것입니다. 계획이 좋으면 모델은 한 번에 전부 만들어 내는 경우가 많습니다. 더 큰 작업이라면 두 번째 세션을 열어 스태프 엔지니어의 눈으로 계획을 살펴보게 하십시오. 이것은 일종의 설계 리뷰이고, 잘못된 방향을 가장 적은 비용으로 잡아낼 수 있는 단계입니다. 계획을 검토할 때는 그 밑에 깔린 가정을 찾아보십시오(1:1 면담이라면 "확신이 없는 부분이 뭐예요?"라고 묻는 것과 같습니다).
작업 분해도 점점 더 에이전트에게 맡겨지고 있습니다. Claude Code의 /batch는 기계적인 대규모 변경을 받아 5~30개의 작업을 만들고, 계획을 보여 준 다음, 각 작업을 별도의 워크트리(저장소의 별도 체크아웃)에서 실행하고, 작업마다 PR을 만듭니다. 이제 일을 직접 나눌 필요는 없습니다. 나뉜 조각이 서로 겹치지 않는지 확인하고, 공유 인터페이스가 먼저 반영되게만 하면 됩니다. 이렇게 하지 않으면 병렬 처리가 되는 것처럼 보이기만 할 수 있습니다. 에이전트 다섯 개가 서로 겹치는 작업을 맡는다고 결과물이 다섯 배가 되지는 않습니다. 작성자가 다섯인 머지 충돌 하나가 생길 뿐입니다.
일찍 방향을 잡고, 빨리 새로 시작하기
모범 사례: 처음 1분을 지켜보며 에이전트의 방향을 잡습니다. 엇나가는 것이 보이면 바로 바로잡습니다. 이미 두 번 교정을 시도했는데 실패했다면, 새 세션과 더 나은 프롬프트로 처음부터 다시 시작합니다.
안티패턴: 요청 자체를 고치지 않고, 에이전트를 교정하려는 세 번째, 네 번째 시도를 덧붙이는 것입니다.
경험 많은 관리자는 유능한 사람이 여러 번 실수한다면 문제가 그보다 앞 단계, 즉 지시나 맥락이나 범위에 있을 수 있다는 것을 압니다. 에이전트에서는 이것이 명시적인 규칙이 됩니다. 에이전트가 엇나가는 순간 Esc를 누르십시오. 이미 두 번 교정을 시도했는데 실패했다면, 세션을 지우고 배운 교훈을 반영해 더 나은 프롬프트를 쓰십시오. 세 번째 교정 시도는 대부분 모델이 계속 다시 읽고 다시 처리해야 하는 정보(실패한 시도까지 포함해서)를 늘릴 뿐입니다.
롤백 비용이 싸다는 점도 판도를 바꾸고 있습니다. /rewind는 코드와 대화를 이전 시점으로 되돌리므로, 더 과감한 접근을 먼저 시도해도 위험이 적습니다. 좋은 관리자도 직원에게 같은 방식을 씁니다. 실수를 되돌리는 비용이 적다면 과감한 접근을 시도하게 둡니다. 그런 다음 회고를 하고, 해당된다면 그 해결책을 일반화해 CLAUDE.md에 넣습니다.
작업은 맡기되, 판단은 절대 맡기지 않기
모범 사례: 일은 에이전트가 하고, 중요한 것은 여러분이 결정합니다. 제품 결정, 보안 경계, 무엇을 출시할지가 여기에 해당합니다. 모든 diff를 그 변경 때문에 장애 호출을 받게 될 것처럼 다룹니다.
안티패턴: 테스트가 초록색이고 이름이 그럴듯해 보인다는 이유로 큰 diff를 승인하는 것입니다. 이것은 코드 리뷰가 아니라 코드 추인입니다.
어떤 관리자도 "그건 제 팀원이 출시한 거지 제가 한 게 아닙니다"라고 말할 수 없습니다. 여러분이 돌리는 모든 에이전트도 마찬가지입니다. 저도 이 함정에 빠진 적이 있습니다. 에이전트에게 경쟁사와의 격차를 조사하고, 그 격차를 메우는 로컬 PR을 작성하라고 시켰습니다. 저는 조사 결과를 읽고 코드를 대충 훑어본 뒤, 얻는 것은 별로 없으면서 사용자에게 복잡성만 더하는 변경을 하마터면 푸시할 뻔했습니다. 일을 맡긴 데 이어 결정까지 맡길 뻔한 것입니다. 빠지기 쉬운 함정입니다. 600줄짜리 diff에 이름도 그럴듯하고 테스트도 초록색이니 그냥 승인하게 됩니다.
작업은 이렇게 나누는 것이 합리적입니다. 스타일, 린팅, 리뷰 후속 작업, 흔한 버그, 단위 테스트는 에이전트에게 맡기고, 보안 경계, 컴플라이언스, 제품 결정은 사람이 다룹니다.
조율도 같은 방식으로 이루어집니다. 에이전트는 인계 사항을 추적할 수 있지만, 서로 충돌하는 요청 사이에서 결정을 내리고 사람들에게서 실제로 확답을 받아 내는 일은 여전히 사람의 몫입니다.
모든 변경의 안쪽 루프에 여러분이 들어가 있을 필요는 없습니다. 여러분이 책임져야 하는 것은 바깥쪽 루프입니다. 제약 조건이 무엇인지, 출력물을 실제로 얼마나 읽는지, 어떤 증거를 남기는지, 사람이 무엇을 승인해야 하는지가 여기에 해당합니다. 그리고 변경은 작게 유지하십시오. 리뷰의 단위가 곧 이해의 단위이기 때문입니다.
여러분 없이도 돌아가는 실행 설계하기
모범 사례: 자율 작업을 내보내기 전에 완료 기준, 자체 검증, 경계, 가드레일, 사람의 승인을 정의합니다.
안티패턴: 완료 기준이나 멈출 지점도 없이 자기 전에 오래 걸리는 프로세스를 시작했다가, 다음 날 아침 일어나 모델이 밤새 잘못된 전제 위에서 일했다는 사실을 알게 되는 것입니다.
스킵 레벨 관리자는 개별 엔지니어의 일을 관리하지 않습니다. 목표, 가드레일, 체크포인트, 리드를 관리합니다. AI 에이전트도 비슷한 길을 걷고 있습니다. 에이전트는 이미 작업의 일부를 서브에이전트에게 위임하고 있으며, 정해진 일정에 따라, CI가 실패한 뒤에, 또는 새 풀 리퀘스트가 열린 뒤에 자율적으로 실행될 수 있습니다. 지금 가장 앞선 곳에 있는 것은 스스로 시작하고 스스로 검증하며 결정이 필요할 때만 사람의 개입을 요청하는 자율 운영 시스템입니다.
역할은 세션을 통제하는 일에서 루프를 설계하는 일로 옮겨 갑니다. 사람이 지켜보지 않는 실행을 설계할 때 스스로에게 던질 다섯 가지 질문은, 좋은 관리자가 시니어 엔지니어에게 프로젝트를 맡기고 휴가를 떠나기 전에 묻는 질문과 같습니다.
- 완료가 어떤 모습인지 알고 있습니까? (목표 조건, 사양 파일, 또는 초록색으로 바꿔야 하는 실패 테스트.)
- 자체 검증 수단이 있습니까? (테스트 스위트, Stop 훅, 또는 리뷰 단계.)
- 경계는 어디까지입니까? (권한 제어, 샌드박스, 워크트리, 또는 푸시가 허용된 단 하나의 브랜치.)
- 가드레일은 무엇입니까? (턴 제한 또는 비용 제한.)
- 출력은 어디에 남고, 누가 승인합니까? (PR이나 요약, 그리고 되돌릴 수 없는 모든 작업에 대한 사람의 승인.)
가이드에는 관리자라면 좋은 실천 방식으로 알아볼 습관이 두 가지 더 있습니다. 하나는 시범 운영입니다. 배치 작업을 먼저 파일 세 개에 돌려 보고, 프롬프트를 다듬은 다음, 나머지를 실행합니다. 다른 하나는 새로운 것이라면 무엇이든 지켜보지 않고 맡기기 전에 처음 몇 번의 실행을 지켜보는 것입니다. 일종의 수습 기간이라고 생각하면 됩니다.
주의력이 아니라 검증을 늘리기
모범 사례: 검사, 목표, 새로운 시각의 리뷰어가 감시 역할을 넘겨받을 수 있는 속도만큼만 에이전트 사용을 늘리고, 처리량뿐 아니라 품질도 측정합니다.
안티패턴: 제대로 리뷰할 수 있는 것보다 많은 세션을 열고, AI가 작성한 코드의 양으로 성공을 측정하는 것입니다.
관리자는 자신의 관리 범위(span of control)를 꽤 빨리 깨닫습니다. 직속 부하가 일정 수를 넘어서면 모두가 관리자에게서 받는 관심이 줄어들고 품질이 떨어집니다. 에이전트도 마찬가지입니다. 저는 이것을 오케스트레이션 세금(orchestration tax)이라고 부릅니다. 처음 몇 개를 넘어서면 에이전트를 하나 더할 때마다 앞의 것보다 더 많은 주의력이 필요합니다. 저는 대부분의 날에 백그라운드 에이전트 네다섯 개와 로컬 세션 몇 개를 돌리는데, 어떤 날은 그것도 너무 많습니다.
많은 세션을 관리하는 일은 고도로 집중하는 데 달려 있지 않습니다. 모니터링 대부분을 자체 평가, 목표, 새 맥락에서 시작하는 리뷰어에게 맡기고, 주의력은 결정을 위해 아껴 두는 데 달려 있습니다. 상태를 직접 확인하러 다니는 대신 알림을 받고, 백그라운드 작업을 한곳에서 볼 수 있게 해 두는 것도 도움이 됩니다. 에이전트 수는 더 많이 모니터링한다고 늘릴 수 있는 것이 아니라, 모니터링할 필요를 줄여야만 늘릴 수 있습니다. 그런 다음 활동이 아니라 시스템을 측정하십시오. 유용한 지표로는 PR 사이클 타임, 신규 입사자가 업무에 적응하는 데 걸리는 시간, 되돌리기나 재작업의 빈도가 있습니다. AI가 작성한 코드의 비율을 측정하는 것은 쓸모 있는 목표가 아닙니다. 여러분이 노리는 것은 품질과 안정성이기 때문입니다. 대응 지표를 함께 측정하라는 그로브의 원칙이 여기에 적용됩니다. 머지된 PR 수를 측정한다면, 되돌리기와 재작업도 함께 측정하십시오.
무엇을 만들지 않을지 정하기
모범 사례: 누가 필요로 하는지, 효과가 있었는지 어떻게 알 수 있는지, 무엇이 생기면 멈출지 묻고, 진행 중인 작업(WIP)의 수를 제한합니다.
안티패턴: 어차피 만드는 비용이 싸니까 그럴듯한 아이디어를 모조리 PR로 던져 넣는 것입니다. 그러면 팀이 리뷰하고, 보안을 점검하고, 유지보수해야 하는 잡동사니 서랍이 생깁니다.
관리자가 하는 가장 중요한 말은 흔히 "아니요"입니다. 에이전트와 일할 때는 거절하기가 더 어렵습니다. 일을 시작하는 데 비용이 거의 들지 않고, 그럴듯한 아이디어라면 무엇이든 점심때까지 PR로 만들어 던질 수 있기 때문입니다. 하지만 그러면 팀이 리뷰하고, 보안을 점검하고, 지원하고, 유지보수해야 하는 PR이 잔뜩 쌓입니다. 이제는 리뷰와 검증이 희소한 자원입니다.
사실 오래된 관리 질문들은 예전보다 지금 더 중요합니다. 누가 요청했습니까? 성공은 어떻게 측정합니까? 언제 멈춰야 할지 어떻게 압니까? 만드는 비용이 싸다면, 어려운 질문은 "할 수 있나?"가 아니라 "해야 하나?"입니다.
비유가 들어맞지 않는 지점
모범 사례: 관리의 모범 사례를 따르되, 재작업 비용이 싸다는 점, 쉽게 동의한다는 점, 모델이 새로 나올 때마다 강점이 바뀐다는 점처럼 에이전트라는 모델이 지닌 차이를 고려합니다.
안티패턴: 에이전트를 주니어 개발자와 똑같다고 생각하거나, 에이전트 다섯 개를 돌릴 수 있으니 다섯 명을 관리할 준비가 되었다고 생각하는 것입니다.
이 비유는 유용하지만 완벽하지는 않습니다. 이 일을 가장 잘하는 사람들은 비유가 어디서 어긋나는지 알고 있습니다.
- 사람을 관리하는 일이 더 어렵고, 그 기술은 거꾸로 옮겨 가지 않습니다. 에이전트 다섯 개를 돌려 봤다고 다섯 명을 관리할 준비가 된 것은 아닙니다. 동기 부여, 갈등, 경력 개발, 몇 달에 걸쳐 쌓는 신뢰에 해당하는 것이 에이전트에는 없습니다.
- 재작업 비용이 거의 들지 않습니다. 사람에게는 절대 하지 않을 부탁도 에이전트에게는 할 수 있습니다. 화이트보드 앞에서 기술 논쟁이 벌어진다면, 에이전트에게 두세 가지 선택지를 직접 만들게 해서 비교해 볼 수 있습니다.
- 에이전트에게는 경험이 없고, 공책만 있습니다. 자동 메모리는 한 컴퓨터에만 메모를 기록합니다. 그 메모는 팀원의 세션으로 옮겨 가지 않습니다. 여러분이 경력을 쌓으며 기르는 경험과 판단도 아닙니다. 그러니 그런 교훈은 팀 전체를 위해 글로 남겨야 합니다.
- 에이전트는 의욕이 넘치고 자신만만합니다. 좋은 엔지니어는 잘못된 일을 시키면 반대 의견을 냅니다. 에이전트는 시키는 대로 할 가능성이 더 높고, 여러분은 에이전트를 지나치게 믿기 쉽습니다. 인지적 항복에 관한 와튼 스쿨의 연구에서 참가자들은 대부분의 경우 AI의 잘못된 답을 받아들였고, 오히려 더 자신감을 갖게 되었습니다. 에이전트에게 자기 답에 반대하는 논증을 펴 보라고 요청하면 이런 과신을 견제할 수 있습니다.
- 에이전트의 유형은 하나뿐이고, 그마저 몇 달마다 바뀝니다. 사람으로 이루어진 팀에는 다양한 기술과 강점이 있습니다. 여러분의 에이전트는 모두 같은 강점과 약점을 지니며, 그 강점과 약점은 모델이 새로 나올 때마다 바뀝니다.
- 주니어 개발자는 여전히 길러야 합니다. 주니어 개발자가 기본기를 익히는 데 필요한 입문 업무를 에이전트가 가져가면, 관리자로서 그런 연습 기회를 의도적으로 만들어 줘야 합니다.
- 사람으로 이루어진 팀은 여전히 중요합니다. 하루 종일 에이전트를 관리하다가, 끈끈한 팀을 만드는 데 들여야 할 시간을 밀어내 버렸다는 사실을 깨닫지 못할 때가 있습니다. 그러지 마십시오.
직함은 필요 없다
모범 사례: 맥락을 정하고, 완료 기준을 정의하고, 리뷰를 잘하는 것처럼 좋은 소프트웨어가 만들어지게 하는 데 노력을 집중합니다.
안티패턴: 지시도 제대로 받지 못하고 검증도 받지 않는 에이전트를 돌리면서, 코드 줄 수로 자신을 평가하는 것입니다.
좋은 스태프 엔지니어는 언제나 이렇게 일해 왔습니다. 설계 문서를 씁니다. 맥락을 정합니다. 꼼꼼하게 리뷰합니다. 주변 사람들을 더 낫게 만듭니다. 에이전트 덕분에 모든 엔지니어가 첫날부터 이렇게 일할 수 있습니다. 에이전트는 관리를 속성으로 배울 기회를 줍니다. 피드백은 분기 단위가 아니라 분 단위로 돌아옵니다. 자신의 실수를 스스로 되돌릴 수 있습니다. 이 일의 중심은 코드를 직접 쓰는 것에서, 좋은 코드가 쓰이게 만드는 사람이 되는 것으로 점점 옮겨 가고 있습니다.
태어날 때부터 훌륭한 관리자(또는 훌륭한 엔지니어)인 사람은 없습니다. 기술은 언제나 그랬듯 연습으로 쌓습니다. 다만 에이전트와 함께라면 연습하는 비용이 쌉니다.
다음 아이디어를 시도해 보십시오.
- 모든 작업에는 실행할 수 있는 검사가 필요합니다. 증거를 요구하십시오.
- 에이전트가 볼 수 없는 것은 알려 주고, 볼 수 있는 것은 빼십시오.
- 코드를 쓰기 전에 계획을 함께 짚어 보십시오.
- 같은 것을 두 번 교정했습니까? CLAUDE.md에 기록하십시오. 반복되는 워크플로가 있습니까? 스킬로 만드십시오.
- 교정이 두 번 실패했습니까? 다시 시작하고 프롬프트를 고쳐 쓰십시오.
- diff는 그 때문에 장애 호출을 받게 될 것처럼 리뷰하십시오.
관리자가 되고 싶어 할 필요는 없습니다. 하지만 에이전트와 함께 일을 잘하는 엔지니어는 그 과정에서 관리하는 법을 익히게 될 것입니다.
