AI가 하루에 수천 줄의 코드를 뽑아내는 팀에서 테크 리드의 역할은 무엇인가. 코드를 한 줄씩 검토하는 사람인가, 아니면 다른 무언가인가. 세 가지 서로 다른 현장에서 올라온 신호들이 하나의 방향을 가리키고 있다. AI가 코드를 생성하는 시대에 테크 리드가 설계해야 할 것은 코드 자체가 아니라, 코드를 둘러싼 통제 구조다.
첫 번째 구조: 설계 문서가 코드 리뷰를 대체한다
Redis 창시자 antirez는 GeekNews에 공유한 글에서 코드 리뷰의 가치가 점점 줄고 있다는 입장을 명확하게 밝혔다. GPT 5.5 이후, 특히 최신 모델들이 등장하면서 AI가 생성한 코드를 한 줄씩 검토하는 일이 실질적인 가치보다 관성에 가까워지고 있다는 것이다. 그가 대안으로 제시한 것이 DESIGN.md다.
DESIGN.md는 코드가 아니라 아이디어를 기록하는 문서다. 핵심 데이터 구조, 구현 기법, 전체 설계 의도를 사람이 읽을 수 있는 언어로 적어두는 것이다. sorted sets를 수정하려는 개발자가 있다면, 코드 파일을 열기 전에 먼저 이 설계 문서를 읽고 정신 모델을 이해한 뒤 에이전트에게 그 모델에 맞춰 작업을 요청하는 방식이다.
테크 리드 입장에서 이건 꽤 중요한 전환이다. 지금까지 코드 리뷰는 품질 게이트였다. 그런데 AI가 생성하는 코드의 양이 인간이 검토할 수 있는 속도를 넘어서는 순간, 그 게이트는 형식만 남고 실질은 사라진다. antirez가 DwarfStar에서 DeepSeek v4와 GLM 5.2 추론을 구현할 때 경험한 것도 이와 같다. 단순히 "XYZ를 구현해"라는 지시만으로는 아무것도 완성되지 않았다. 시스템이 어떻게 동작해야 하는지, 어떤 설계가 적절한지, 어느 수준의 성능이 목표인지—이 모든 것을 사람이 먼저 정의했기 때문에 AI가 제대로 된 결과를 냈다.
테크 리드가 설계해야 할 것: PR 템플릿에 DESIGN.md 링크를 필수 항목으로 넣어라. 새 기능이나 데이터 구조를 추가할 때, 코드보다 설계 문서를 먼저 작성하는 순서를 팀의 기본 워크플로우로 만들어라. AI는 이 문서를 기반으로 프롬프트를 받고, 코드 리뷰어는 코드가 아닌 설계 의도를 기준으로 판단한다.
두 번째 구조: 에이전트의 작업 범위를 명시적으로 제약한다
dev.to에 올라온 짧지만 날카로운 경험담이 있다. AI 에이전트가 이미 잘 작동하는 코드를 계속 리팩토링했다는 이야기다. 테스트는 통과하고, 로직도 맞는데, 에이전트는 코드를 "더 예쁘게" 만들고 싶어서 건드렸다. 이 문제를 해결한 방법은 간단했다. "현재 태스크에 포함되지 않은 코드는 수정하지 않는다"는 규칙 한 줄.
이게 왜 중요한가. 에이전트의 무요청 변경(unrequested changes)은 가장 비싼 산출물이기 때문이다. 코드가 바뀌면 리뷰가 필요하고, 리뷰가 늘어나면 병목이 생긴다. 더 심각한 건 작동하던 코드가 에이전트의 "개선" 이후 알 수 없는 이유로 달라지는 상황이다. 원인을 추적하는 시간이 에이전트가 아낀 시간을 초과한다.
이 문제는 에이전트 품질의 문제가 아니다. 에이전트는 주어진 목표를 향해 최적화하도록 설계돼 있고, 범위 제약이 없으면 판단 기준을 스스로 확장한다. 이건 버그가 아니라 기본 동작이다. 따라서 제약을 설계하는 것은 에이전트를 불신하는 것이 아니라, 에이전트를 올바르게 운용하는 것이다.
테크 리드가 설계해야 할 것: AGENTS.md 또는 CLAUDE.md에 "현재 태스크 파일 외 수정 금지" 규칙을 명시적으로 넣어라. 더 나아가 에이전트가 수정할 수 있는 디렉토리 범위를 태스크 정의 단계에서 함께 선언하는 방식을 표준화하라. 에이전트가 제안하는 범위 외 변경은 별도 PR로 분리하도록 팀 규약을 만들어라.
세 번째 구조: 코드를 이해해야만 머지할 수 있게 만든다
BuildIt이라는 플랫폼이 있다. Arduino, ESP32, Next.js, React Native 등 9개 코스, 45개 실제 프로젝트로 구성된 학습 환경인데, 핵심 규칙은 하나다. AI 에이전트가 제안한 코드 변경을 받아들이기 전에, 왜 이 변경이 이루어졌는지, 어떤 문제가 생길 수 있는지를 AI 튜터와 대화로 설명해야만 다음 단계로 넘어갈 수 있다. 설명하지 못하면 머지할 수 없다.
이 플랫폼을 만든 이유가 정확히 이 글의 세 번째 통제 구조를 설명한다. 개발자가 스스로 발견한 패턴은 "AI가 코드를 빠르게 생성하고, 실행해보고, 작동하면 머지한다—그리고 일주일 뒤에 왜 작동하는지 설명하지 못하고, 다음 버그가 어디 있는지 모른다"는 것이었다. vibe coding의 실제 비용이다.
antirez도 같은 선을 그었다. "AI가 만든 결과물을 무조건 받아들이는 것"과 "AI를 이용해 코드를 생성하면서 사람이 설계와 품질을 통제하는 것"은 다르다. LLM은 함수 단위의 국소적 코드 작성에는 강하지만, 큰 설계에서는 상대적으로 약하다. 그렇다면 설계 판단력과 코드 이해력은 여전히 사람이 가지고 있어야 한다.
이건 단순한 교육 문제가 아니다. 팀 운용 구조의 문제다. 팀원이 AI가 생성한 코드를 이해하지 못한 채로 프로덕션에 올리는 일이 반복되면, 장애 대응 속도가 느려지고, 기술 부채의 위치를 추적하는 것 자체가 불가능해진다. 코드 이해 책임을 팀의 머지 기준으로 만드는 것은 속도를 늦추는 것이 아니라, 나중에 더 큰 속도 저하를 막는 선제적 설계다.
테크 리드가 설계해야 할 것: PR 설명란에 "이 코드가 왜 이렇게 작성됐는지"를 필수로 적도록 요구하라. AI가 생성한 코드 블록에는 해당 로직의 의도를 주석으로 남기는 것을 팀 컨벤션으로 만들어라. 온보딩 과정에서 AI 도구 사용법과 함께 "AI 생성 코드 설명하기" 훈련을 병행하라.
통제 구조 없이 속도만 높이면 일어나는 일
세 가지를 합쳐보면 패턴이 보인다. 첫째, 설계 문서 없이 AI에게 코드를 맡기면 아이디어가 코드 속에 묻혀버린다. 둘째, 에이전트 범위 제약 없이 자율권을 주면 작동하던 코드가 이유 없이 바뀐다. 셋째, 코드 이해 기준 없이 머지하면 팀이 자기 코드베이스를 설명하지 못하게 된다. 이 세 가지는 각각 독립적인 문제처럼 보이지만, 근본은 같다. AI가 생성 속도를 채워줄수록, 통제 구조를 설계하는 일은 더 중요해진다.
antirez는 경험이 부족한 개발자에게는 아직 답이 없다고 솔직하게 인정했다. AI가 생성한 코드를 검토하는 것이 가장 좋은 학습 방법인지에 회의적이며, 작은 인터프리터나 데이터베이스를 직접 구현해보는 것이 더 유용할 수 있다고 제안한다. 주니어가 많은 팀이라면 이 세 가지 통제 구조에 하나를 더 추가해야 한다. AI 없이 직접 구현해보는 구역을 의도적으로 만드는 것. 그 마찰이 이해력을 키운다.
테크 리드의 역할은 AI가 코드를 잘 짜게 하는 것이 아니다. AI가 짠 코드가 팀의 아이디어와 일치하게 만드는 것, 에이전트가 팀의 의도 안에서 움직이게 제약하는 것, 팀원이 자기 코드베이스를 설명할 수 있도록 기준을 설계하는 것이다. 이 세 가지를 설계하지 않으면, AI는 속도만 높이고 통제권은 사라진다.