에이전트가 하루에 수만 줄을 쏟아내는 팀에서 가장 먼저 무너지는 것은 코드가 아니다. 설계의 주인이 누구인지가 먼저 흐릿해진다. codingwithjesse.com이 제기한 "AI 록스타 개발자의 뒷정리" 문제는 표면적으로는 코드 품질 이슈처럼 보이지만, 실제로는 AI-First 팀이 지금 당장 설계 레벨에서 답해야 할 구조적 질문을 드러낸다.
록스타 에이전트가 만드는 부채 구조
과거 '록스타 개발자' 문제를 기억한다면 지금 상황이 낯설지 않을 것이다. 빠르게 움직이고, 혼자 아키텍처를 뒤집고, 팀이 이해하지 못하는 코드를 남기고 떠난 그 개발자. 그런데 지금은 그 록스타가 채팅창마다 소환된다. 에이전트는 어제의 컨텍스트를 기억하지 못한 채 새 채팅마다 리셋되고, 시스템 전체 일관성 따위는 고려하지 않은 채 태스크 완료를 향해 달린다.
록스타 개발자 한 명의 코드는 최소한 설계 의도라도 있었다. 하지만 바이브 코딩으로 누적된 코드베이스는 수십 개의 채팅 세션이 남긴 조각들의 합산이다. 어떤 경우에는 기술 부채가 너무 깊어져 갚을 수 없는 수준에 이른다. 이 글에서 핵심은 하나다. 에이전트에게 생성을 시키는 것과, 그 결과물의 복잡도를 책임지는 것은 완전히 다른 역할이다.
디렉터로서의 엔지니어: 낭만이 아닌 구조 문제
dev.to의 Jenuel은 이 전환을 'Agentic Engineering'이라고 명명한다. 에이전트가 파일을 읽고, 커맨드를 실행하고, PR을 열고, 오류를 반복 수정하는 시대에—엔지니어의 역할은 타이핑에서 디렉팅으로 이동한다. GitHub Copilot의 에이전트 모드, Google의 Jules, Anthropic의 Claude Code가 모두 같은 방향을 가리킨다. 엔지니어는 무엇을 만들지, 어떤 제약이 있는지, 결과를 어떻게 검증할지를 결정하는 사람이 된다.
그런데 이 전환이 낭만적으로만 보여서는 안 된다. 디렉터 역할이 제대로 작동하려면 팀 구조와 온보딩 프로세스가 먼저 바뀌어야 한다. 에이전트는 태스크가 모호하면 틀린 방향으로 자신 있게 달린다. 저장소에 테스트가 없으면 에이전트가 만든 10개의 파일을 검증할 방법이 없다. 수락 기준이 누군가의 머릿속에만 있으면 에이전트가 실패해도 실패인지 모른다. 에이전트가 강해질수록, 느슨한 엔지니어링 습관의 비용은 더 빠르게 증폭된다.
현장은 이미 움직이고 있다
OpenAI가 공개한 Nextdoor와 Notion의 Codex 활용 사례는 이 전환이 실제로 어디서 일어나고 있는지를 보여준다. Nextdoor는 재현하기 어려운 결함 조사와 크로스플랫폼 구현에 Codex를 투입했다. 단순 코드 생성이 아니라, 로그와 재현 조건과 플랫폼 차이를 함께 추적해야 하는 불확실한 작업에 에이전트를 배치한 것이다. Notion은 사양 문서를 코드 변경으로 연결하는 'one-shot specs' 흐름에 Codex를 썼다. 작은 팀이 더 넓은 범위의 기능을 소화하는 방식이다.
두 사례 모두 AI 도입의 질문이 달라졌음을 보여준다. "코드를 얼마나 빨리 쓰는가"가 아니라 "어떤 종류의 불확실한 작업을 위임할 수 있는가"로. 그리고 그 위임을 가능하게 하는 조건이 있다. Nextdoor처럼 결함 조사에 에이전트를 넣으려면, 테스트 재현 절차와 권한 경계와 롤백 절차가 먼저 설계돼 있어야 한다. Notion처럼 사양 구현을 위임하려면, 사양 문서가 에이전트가 읽을 수 있는 형태여야 한다.
AI-First 팀 리빌딩이 먼저 설계해야 할 것
여기서 테크 리드가 실질적으로 직면하는 질문은 셋이다.
첫째, 컨텍스트 설계. Jenuel은 이것을 'Context Engineering'이라 부른다. 에이전트가 잘 작동하는 조건은 프롬프트 스킬이 아니라 프로젝트 지식의 구조화에서 온다. 셋업 커맨드, 아키텍처 노트, 테스트 규칙, API 계약, 알려진 함정, 코드베이스 내 좋은 작업 예시. 기존 워크플로우에서는 문서화되지 않은 지식이 신규 입사자를 느리게 만들었다. 에이전트 워크플로우에서는 같은 지식의 부재가 에이전트를 혼란스럽게 만든다. 숨겨진 비용이 가시화된다.
둘째, 검증 파이프라인 설계. 에이전트가 10개의 파일을 수정하고 "테스트 통과"라고 말할 때, 그 테스트가 실제로 무엇을 커버하는지를 팀이 알아야 한다. Martin Fowler가 반복해서 강조하는 지점이 여기다. 루프에는 여전히 사람, 피드백, 엔지니어링 규율이 필요하다. Thoughtworks Technology Radar도 같은 경고를 달았다. 에이전트 코딩 도구는 팀이 워크플로우를 함께 바꿀 때 효과가 있다. 에이전트 출력을 프로덕션에 붙여 넣는 방식으로는 아니다.
셋째, 에이전트 사용 범위의 명시적 설계. 모든 작업을 에이전트에게 위임하는 것이 아니다. codingwithjesse.com이 제안하는 방향은 명확하다. LLM은 작은 코드 조각 생성에 제한하고, 사람이 설계를 이끌며, 과잉 엔지니어링을 막고, 아키텍처를 문제의 복잡도에 맞게 단순화한다. 때로는 에이전트를 도구함에 그대로 두고 직접 코드를 쓰는 것이 맞다. 어떤 작업은 위임하고 어떤 작업은 직접 하는지를 팀 레벨에서 명문화해야 한다.
온보딩이 바뀌어야 하는 이유
AI-First 팀 리빌딩에서 온보딩은 단순히 "AI 도구 사용법 교육"이 아니다. 신규 팀원이 에이전트 워크플로우 안에서 디렉터 역할을 수행할 수 있는 판단력을 갖추는 과정이다. 에이전트가 틀린 방향으로 가고 있을 때 알아채는 능력, 태스크를 명확하고 검증 가능하게 정의하는 능력, 에이전트가 생성한 복잡도가 적정 수준인지 판단하는 능력—이것들은 AI 도구 사용법 문서로 가르칠 수 있는 것이 아니다. 코드베이스의 설계 원칙과 품질 기준이 팀 전체에 내재화돼 있을 때 비로소 작동한다.
전망: 속도는 기본값, 설계가 차별화
에이전트가 코드를 짜는 속도는 앞으로 더 빨라진다. Nextdoor와 Notion 같은 사례는 더 많아진다. 하지만 속도가 팀의 차별화 요소가 되는 시간은 짧다. 모두가 같은 에이전트를 쓰면, 차별화는 얼마나 빨리 생성하는가가 아니라 무엇을 만들지 결정하는 판단, 생성된 복잡도를 통제하는 설계, 결과물의 품질을 검증하는 구조에서 온다.
테크 리드 입장에서 지금 가장 실용적인 질문은 이것이다. 우리 팀에서 에이전트가 만든 코드의 복잡도가 이익보다 커지는 순간을 누가, 어떤 기준으로, 얼마나 빨리 감지하는가. 그 감지 능력을 설계하는 것—그게 AI-First 팀 리빌딩의 진짜 과제다.