에이전트를 도입하면 팀 생산성이 폭발적으로 오른다는 기대, 솔직히 나도 한때 공유했다. 그런데 요즘 들어 확신이 바뀌고 있다. 정확히는 '에이전트 도입 자체'가 아니라 '도입 순서'에 대한 확신이다. AI 코딩 에이전트를 붙이기 전에, 팀 코드베이스가 먼저 준비돼야 한다는 것.
AI Engineer World's Fair 2026에서 나온 Tereza Tížková의 발언이 이 생각을 정리해줬다. "구조 없이는 AI가 코드를 더 나쁘게 만든다." 발표에서 Factory 팀이 제시한 agent-ready 코드베이스의 체크리스트는 단순하다. 스타일 가이드와 린트, 빌드 시스템, 테스트, 문서화, 개발 환경, 관찰 가능성, 보안, 태스크 탐색 가능성. 이 여덟 가지 영역에서 팀이 이미 잘 하고 있다면? 에이전트를 붙일 준비가 된 것이다. 반대로 이 영역들이 엉망이라면? 에이전트는 그 엉망을 더 빠른 속도로 복제할 뿐이다.
이게 단순한 이론이 아니라는 걸 보여주는 사례가 있다. 오픈소스 프로젝트 git-annex의 메인테이너 Joey Hess는 의존성 트리 전체에서 LLM 생성 코드를 걷어내는 데 한 달간 약 100시간을 쏟았다. 그가 발견한 것들이 충격적이다. 26,000줄 코드베이스에 10,000줄짜리 변경이 들어왔고, 커밋 메시지는 1,489줄의 일관성 없는 내용이었다. 대규모 LLM 생성 변경이 다음 릴리스에서 아무 설명 없이 통째로 되돌려진 사례도 있었다. LLM 프롬프트가 다른 프로젝트 코드를 복사하도록 유도한 흔적도 있었고, 운 좋게 저작권 침해를 피했을 뿐이라는 설명도 따라붙었다.
커뮤니티 반응 중 하나가 핵심을 정확히 짚었다. "신뢰가 깨진 시점은 LLM을 쓰기 시작했을 때가 아니라, 거대한 변경을 받아들이면서 읽기 어렵고 쓸모없는 커밋 메시지를 붙였을 때다. 이건 LLM 사용 여부와 별개인 소프트웨어 공학 실패다." 맞는 말이다. LLM이 문제가 아니라, 검증 없이 대량의 변경을 수용하는 관행이 문제다. 에이전트는 그 관행을 더 빠르게, 더 대규모로 실행할 수 있게 해줄 뿐이다.
그리고 메타의 사례가 이 논점에 현실 무게를 더한다. 저커버그는 7월 2일 내부 타운홀에서 공개적으로 인정했다. "지난 최소 4개월 동안 에이전트 개발의 궤적이 우리가 예상한 방식으로 실제 가속하지 않았다." 메타는 5월 전 세계 인력의 약 10%를 감원하고 7,000명을 AI 중심 팀으로 재배치했다. Claude Code 같은 코딩 어시스턴트가 더 빠르게 발전할 것이라는 낙관에 기반한 결정이었다. 결과는? 조직 개편이 "깔끔하게" 진행되지 않았고, 성과는 기대에 못 미쳤다. 세계 최고의 AI 투자 역량을 가진 조직도 에이전트 전환은 버튼 하나로 되지 않는다는 걸 몸으로 증명했다.
여기서 팀 리드로서 내가 뽑는 시사점은 하나다. agent-ready 체크리스트는 사실 에이전트와 무관하게 팀이 갖춰야 할 소프트웨어 공학 기본기와 완전히 겹친다. 린트, 테스트, 문서, 관찰 가능성, 보안. 이 영역을 에이전트 도입 때문에 정비한다면? 에이전트를 쓰든 안 쓰든 팀의 코드 품질과 유지보수성이 올라간다. 비용이 제로인 투자다. 반대로 이 기반 없이 에이전트를 먼저 붙이면? 빠른 기술 부채 생성기를 팀에 추가하는 것이다.
도구 도입 순서가 결과를 결정한다. 에이전트를 붙이기 전에 팀의 코드베이스를 먼저 진단하라. 지금 당장 위의 여덟 가지 영역에서 팀 코드베이스 점수를 매겨보는 것, 그게 에이전트 도입의 실질적인 첫 번째 스텝이다. World's Fair에서 나온 흐름이 이를 뒷받침한다. 초기 과대 선전의 사이클을 벗어나, 엔지니어들은 다른 도구를 배웠던 방식대로 AI 도구를 배우기 시작했다. '빠르게 토큰 태우고 배포'가 아니라 '좋은 것을 제대로 만드는' 방향으로.