에이전트가 코드를 짜고, 협상을 하고, 배포 판단까지 내리는 세계가 왔다. 팀 리드로서 나는 이 변화를 반기는 쪽이다. 하지만 최근 세 개의 연구가 동시에 같은 질문을 던지고 있다는 게 불편하다. AI가 결정을 내리는 조직에서, 리드는 무엇을 설계해야 하는가.
에이전트는 틀리지 않는다. 다만 빈칸을 채울 뿐이다
dev.to에 공개된 RAES(Reusable AI Execution System) 사례는 이 질문을 가장 선명하게 보여준다. 저자는 Test-Driven Design과 Spec-Driven Design을 꼼꼼히 적용하면서 에이전트를 운용했다. 그런데 핵심 제약 파일인 system.md가 설정 스키마에서 누락돼 있었고, 에이전트는 그 사실을 조용히 무시한 채 실행을 계속했다. 에이전트는 틀린 게 없다. 주어진 스펙을 정확히 따랐을 뿐이다. 문제는 스펙 자체의 빈칸이었고, 그 빈칸을 에이전트가 자체적으로 추론으로 채웠다는 데 있다.
Thoughtworks를 비롯한 현장 엔지니어들은 이 현상을 인지 부채(Cognitive Debt)라 부른다. AI가 생성한 코드가 보이지 않는 설계 결정을 조용히 내재화하면서, 팀의 공유 이해가 서서히 침식되는 현상이다. 빠르게 움직일수록 부채는 AI 속도로 쌓인다. 리드가 설계하지 않으면, 에이전트가 대신 설계한다. 그것도 기록 없이.
결정은 AI가, 책임은 누가
geeknews에서 다룬 flowkater.io 기고는 이 질문의 다른 면을 찌른다. Google은 2026년 초 Cloud Next에서 새 코드의 75%가 AI 생성이라고 발표했다. 표현이 중요하다: "AI-generated and approved by engineers." 작성은 AI, 승인과 책임은 엔지니어다. Mark Zuckerberg도 비슷한 신호를 보냈다. 예전에는 큰 팀이 필요했던 프로젝트가 "정말로 뛰어난 한 명"에 의해 끝나고 있다고.
10명이 나눠 갖던 판단·조율·검증·배포 이후의 책임이 한 사람에게 압축된다는 뜻이다. 이건 효율의 문제가 아니다. ownership의 밀도 문제다. METR의 2025년 연구는 냉정한 반례도 제시한다. 숙련된 오픈소스 개발자가 자신이 잘 아는 코드베이스에서 AI를 사용했더니 오히려 19% 더 느렸다. AI는 산출 비용을 낮추지만, 맥락 이해와 올바른 선택의 비용은 자동으로 낮춰주지 않는다.
Air Canada 챗봇 사건(2024)은 책임 소재를 법적으로도 확인했다. 챗봇이 잘못된 환불 정보를 제공했고, 회사는 챗봇을 별도 주체로 보려 했지만 분쟁조정기관은 "정보가 어디서 나오든 책임은 회사에 있다"고 판단했다. AI가 결정을 내렸더라도, 그 결정을 노출하기로 한 것은 사람과 조직이다.
보이지 않는 격차—누가 손해를 봤는지조차 모른다
Anthropic이 2026년 4월 공개한 Project Deal 보고서는 세 번째 불편한 사실을 드러낸다. 직원 69명에게 AI 에이전트로 일주일간 중고 거래를 맡겼더니 총 186건, 4천 달러 이상의 거래가 성사됐다. 문제는 성과가 아니라 격차였다.
최상위 모델 Claude Opus를 쓴 참가자는 소형 모델 Haiku를 쓴 참가자보다 평균 2.07건 더 많은 거래를 성사시켰고, 같은 물건도 평균 3.64달러 더 비싸게 팔았다. 랩그로운 루비 한 개가 Opus 에이전트에게는 65달러에, Haiku 에이전트에게는 35달러에 팔렸다. 협상 전략 지시는 통계적으로 유의미한 영향을 주지 못했다. 결과를 결정한 것은 어떤 모델에 접근할 수 있느냐였다.
더 불편한 발견은 따로 있다. 두 모델을 모두 경험한 28명 중 11명이 오히려 Haiku 결과를 더 좋다고 평가했다. 통계적으로는 동전 던지기와 구분되지 않는 수준이다. 손해를 보고 있으면서도 알아채지 못한 것이다. Anthropic은 이를 "보이지 않는 불평등(Invisible Inequality)"이라 불렀다. 모델 성능 격차가 사용자에게는 감지되지 않은 채 시장 결과에만 반영되는 현상이다.
리드가 설계해야 할 것: 자율성 이후의 구조
세 개의 사례가 수렴하는 지점은 하나다. AI에게 자율성을 위임한 이후에 무엇을 설계하느냐. 리드가 아무것도 설계하지 않으면, 에이전트는 빈칸을 채우고, 책임은 공중에 뜨고, 격차는 아무도 모르게 쌓인다.
실용적으로 짚으면 세 가지다.
첫째, 결정 기록을 구조화하라. RAES 사례처럼 에이전트가 실행 중 내린 판단은 반드시 기록으로 남아야 한다. decisions.md든 ADR이든 형식은 무관하다. 나중에 "왜 이렇게 됐지?"를 추적할 수 있는 흔적이 있어야 한다. 기록이 없으면 인지 부채는 조용히 복리로 늘어난다.
둘째, 에이전트 품질 격차를 팀 설계 변수로 다뤄라. Project Deal이 보여준 것처럼, 어떤 모델을 어떤 작업에 배치하느냐가 산출 품질을 결정한다. 이건 인프라 비용 문제이기도 하지만, 더 중요하게는 팀이 결과 격차를 인지할 수 있는 메커니즘을 갖추고 있느냐의 문제다. 에이전트가 손해 보는 결정을 내리고 있는데 팀이 그걸 못 보고 있다면, 그건 리드의 설계 실패다.
셋째, ownership의 경계를 명시하라. flowkater.io의 표현을 빌리면, AI는 코드를 쓰고 결정도 하지만 책임은 못 진다. "AI-generated and approved by engineers"라는 Google의 표현이 단순한 마케팅 문구가 아닌 이유다. 승인 행위가 ownership의 경계다. 이 경계를 팀 내에서 명시적으로 설계하지 않으면, 문제가 생겼을 때 아무도 손을 들지 않는 공백이 생긴다.
전망: 리드의 역할은 좁아지지 않는다
AI-First로 팀을 리빌딩하면서 내가 가장 자주 받는 질문이 있다. "AI가 이 정도 하면 리드 역할이 줄어드는 거 아닌가요?" 반대다. 에이전트에게 위임하는 범위가 넓어질수록, 그 위임 구조를 설계하는 역할의 밀도는 높아진다.
에이전트는 스펙의 빈칸을 채운다. 에이전트는 성능 격차를 만든다. 에이전트는 책임을 지지 않는다. 이 세 가지 사실이 동시에 참이라면, 리드가 해야 할 일은 더 늘어난 것이다. 스펙을 촘촘히 설계하고, 모델 선택을 결과와 연결하고, ownership의 경계를 팀 전체가 볼 수 있게 만드는 것. 그게 AI가 결정을 내리는 세계에서 리드가 설계해야 할 것들이다.
속도는 에이전트가 낸다. 방향은 리드가 설계한다. 그 역할 분리가 흐릿해지는 순간, 팀은 빠르게 잘못된 방향으로 달리고 있다는 사실조차 알아채지 못하게 된다.