AI 코딩 도구를 팀에 도입했는데 기대만큼 안 돌아간다는 이야기를 자주 듣는다. 정확히는 이렇다. 개인이 쓸 때는 빠른데, 팀 전체가 일관된 품질로 쓰게 만들기가 어렵다. 그 이유를 두 기사가 서로 다른 각도에서 정확하게 짚고 있다. dev.to에 올라온 Ortho 프로젝트 소개 글과 named-expert 리뷰 시스템 구축기다. 두 글을 따로 읽으면 흥미로운 실험이지만, 같이 읽으면 하나의 패턴이 보인다. AI 도구 실패의 근본 원인은 모델 품질이 아니라 구조의 부재라는 것.
문제 1: AI는 프로세스를 모른다
첫 번째 기사가 지적하는 핵심은 단순하다. AI 코딩 도구는 코드 생성을 하나의 단계로 압축한다. 프롬프트를 넣으면 코드가 나온다. 그게 전부다. 그런데 실제 팀 개발에서 좋은 코드가 나오는 과정은 그렇지 않다. 요구사항 파악 → 아키텍처 검토 → 구현 → 테스트 설계 → 검증 → 리뷰. 각 단계는 서로 다른 종류의 실수를 잡아낸다. AI는 이 전체를 프롬프트 하나로 건너뛴다.
결과는 파일 단위로는 그럴듯한 코드지만, 레이어 경계를 무시하거나, 팀이 이미 거부한 패턴을 다시 제안하거나, 리뷰어가 30초 만에 잡을 문제를 검증 없이 통과시킨다. Ortho가 제안하는 ASES 방법론은 이 문제를 6단계 에이전트 체인으로 해결한다. PLANNER → ARCHITECT → BUILDER → TEST-DESIGNER → VERIFIER → REVIEWER. 핵심은 코드를 생성하는 단계(BUILDER)가 전체 6단계 중 하나뿐이라는 점이다. 나머지 5단계는 생성 전후의 판단과 검증에 쓰인다.
여기서 특히 주목할 부분은 피드백 루프 설계다. ortho reject "wrong layer" 명령 한 줄이 팀의 의사결정을 저장한다. 다음 번에 유사한 변경을 제안할 때 시스템이 스스로 "2026-07-15에 거부됨: 미들웨어 레이어를 쓸 것"이라고 컨텍스트에 주입한다. AI가 같은 실수를 반복하지 않는 구조를 코드로 강제하는 것이다. 팀 컨벤션을 문서로만 관리하던 방식과 근본적으로 다르다.
문제 2: 컨텍스트 창을 채우는 것과 활용하는 것은 다르다
두 번째 문제는 컨텍스트 관리다. 대부분의 팀은 두 가지 극단 중 하나를 선택한다. 너무 적게 보내서 제네릭한 결과를 받거나, 너무 많이 보내서 노이즈로 모델의 추론을 방해하거나. Ortho의 9단계 토큰 최적화 파이프라인은 이 문제를 체계적으로 다룬다. 의도 추출 → 심볼 랭킹 → 임포트 그래프 프루닝 → 콜 그래프 필터링 → 아키텍처 컨텍스트 선택 → 히스토리 중복 제거 → 피드백 주입 → 예산 할당 → 포맷 압축. 400줄 파일이 200줄 시그널로 압축돼서 들어간다.
이 파이프라인의 논리는 명확하다. PLANNER에게는 넓은 레포 컨텍스트가 필요하고, BUILDER에게는 자신이 건드릴 코드 경로만 필요하다. 단계마다 다른 컨텍스트를 목적에 맞게 주입하는 것이 핵심이다. 워크플로우 구조가 없으면 이 토큰 최적화도 의미가 없고, 컨텍스트 관리 없이 워크플로우만 있으면 각 단계에 엉뚱한 정보가 들어간다. 두 문제는 함께 해결해야 한다.
AI 리뷰도 같은 문제를 갖고 있다
두 번째 기사는 코드 리뷰 자동화가 아니라 작업 리뷰 시스템에 관한 이야기지만, 진단은 동일하다. "AI에게 보안 리뷰어 역할을 해달라"고 하면 피드백은 나온다. 그런데 그 피드백이 실제 분석인지 패턴 매칭인지 알 수 없다. "에러 핸들링을 추가하세요"—어떤 에러? 왜 여기서? 저자는 이 문제를 신원이 없는 리뷰어로 정의한다. 역할(Role)이 아닌 실명(Named Expert)을 쓰는 이유가 여기 있다.
Ken Thompson의 1984년 튜링상 강연, Torvalds의 TED 2016 발표, Zinsser의 On Writing Well. 출처가 있는 원칙은 검증할 수 있다. AI가 생성한 피드백이 해당 전문가의 실제 관점에서 나왔는지 독자가 직접 확인할 수 있다는 말이다. 저자는 이를 "반-허구 규율(anti-fabrication discipline)"이라 부르며, 출처 신뢰도를 high/moderate/low로 분류하고 moderate 미만이면 해당 페르소나를 드롭하는 규칙을 코드로 강제한다.
33명의 전문가 풀을 구축했지만 실제로 활용되려면 디스패치 시스템이 있어야 한다는 통찰도 중요하다. YAML 기반 라우팅 테이블 하나로, 실험 설계 작업이 완료되면 Carmack·Hickey·Schell이 자동으로 로드되고, PR이 올라오면 Thompson·Torvalds·Beck이 코드를 리뷰한다. 저자는 라우팅 테이블 도입 전후를 이렇게 표현한다. "전: 기억날 때 일주일에 한 번. 후: 모든 완료 작업마다 자동으로." 이게 '쿨한 아이디어'와 '실제 워크플로우'의 차이다.
팀에 적용하기 전에 먼저 물어야 할 것
두 사례 모두 개인 또는 소규모 맥락에서 출발했다. 팀 규모로 확장할 때 고려해야 할 변수들이 있다.
학습 곡선과 유지비용. ASES의 6단계 파이프라인은 각 단계를 독립된 에이전트 호출로 처리한다. 팀 전체가 이 구조를 이해하고 운영하려면 초기 셋업 비용이 필요하다. Ortho는 로컬 퍼스트 SQLite 기반이라 인프라 부담은 낮지만, 아키텍처 모델을 정의하고 피드백 스토어를 관리하는 것은 팀의 몫이다.
규칙 강제의 주체. 두 번째 기사 저자가 강조하는 포인트가 있다. "AI가 스스로 규칙을 집행하게 두지 마라. 코드가 규칙을 집행하고, AI는 그 규칙을 따르게 하라." 세션 종료 시 자동으로 실행되는 Python 스크립트가 KB 갱신 여부를 체크하고, 30일 이상 미사용 라우팅 룰을 플래그한다. AI 리뷰 시스템의 신뢰성은 AI가 아니라 주변 코드 인프라가 보장한다.
컨텍스트 품질의 주기적 갱신. 아키텍처가 바뀌면 ASES의 아키텍처 모델도 업데이트해야 한다. 전문가 풀의 KB가 오래됐다면 리뷰 품질이 조용히 떨어진다. 이 유지비용을 누가 얼마나 부담할지 설계 단계에서 결정해야 한다.
구조가 먼저다
AI 도구를 도입한다고 팀이 AI-First가 되지 않는다. 도구는 있는데 구조가 없으면, 개인 생산성은 올라가고 팀 품질은 내려간다. 두 사례가 공통적으로 보여주는 것은 단순하다. AI를 잘 쓰는 팀은 AI가 더 잘 동작하도록 주변 구조를 설계하는 팀이다.
워크플로우 게이트가 생성 전후의 판단을 잡고, 컨텍스트 파이프라인이 각 단계에 맞는 시그널을 주입하고, 라우팅 테이블이 적절한 리뷰어를 자동으로 배치하고, 코드 기반 강제 장치가 규칙의 실행을 보장한다. 이 레이어들이 있어야 "AI 도구를 쓴다"가 "AI와 함께 일관된 품질로 일한다"로 바뀐다.
내일 당장 팀에 적용하고 싶다면 작게 시작하면 된다. 가장 빠른 첫 걸음은 팀이 이미 거부한 패턴 목록을 만들고, AI가 코드를 생성하기 전에 그 목록을 컨텍스트에 주입하는 것이다. 복잡한 파이프라인 없이도 "같은 실수를 반복하지 않는 구조"의 핵심은 거기서 시작한다.