문제는 도구가 아니라 통합 구조다
AI 코딩 에이전트를 팀에 붙이면 생산성이 올라갈 거라고 기대한다. 실제로 올라가긴 한다—처음엔. 그런데 몇 주 지나면 이상한 일이 벌어진다. AI가 짠 코드가 리뷰를 통과하고, 테스트도 통과하고, 프로덕션에 올라갔는데 사고가 난다. 혹은 AI에게 매번 같은 맥락을 설명하느라 오히려 시간을 더 쓰고 있다는 걸 깨닫는다.
이건 도구의 문제가 아니다. 통합 구조의 문제다. AI 에이전트는 세 개의 레이어가 제대로 설계되어 있을 때만 '동료'로 작동한다. 컨텍스트 주입, 생성 시점 보안 검증, 그리고 리뷰 역할 재분배. 이 세 레이어를 각각 살펴보고, 왜 하나라도 빠지면 전체가 흔들리는지 짚어보겠다.
레이어 1: 컨텍스트 주입 — AI가 우리 조직을 알게 만들기
dev.to에 올라온 한 사례가 이 문제를 정확하게 짚는다. AI 코딩 어시스턴트는 공개 라이브러리와 프레임워크에 대해서는 방대한 학습 데이터를 갖고 있지만, 내부 인프라에 대해서는 완전히 깜깜하다. 어떤 디자인 시스템을 쓰는지, CI/CD 파이프라인이 어떻게 구성됐는지, 내부 로깅·메트릭·트레이싱 라이브러리가 무엇인지—이 모든 게 AI에게는 블랙박스다.
결과는 예측 가능하다. 개발자가 AI에게 매번 같은 설명을 반복하거나, AI가 조직 표준을 무시한 코드를 뱉어내거나, 둘 다다. 이 팀이 선택한 해법은 Model Context Protocol(MCP) 서버였다. 조직의 지식을 구조화된 문서 레이어(아키텍처 문서, 컨벤션, 워크플로우)와 프로젝트 카탈로그로 정리하고, MCP 서버를 통해 AI 에이전트가 이를 자율적으로 조회하게 만들었다.
list_projects, get_architecture_docs, clone_template 같은 도구를 AI가 직접 호출하면서, 개발자는 더 이상 컨텍스트 전달에 시간을 쓰지 않아도 된다. Okta 인증을 통해 AI가 접근할 수 있는 정보도 권한 범위 내로 제한된다. 핵심은 AI를 조직의 지식 그래프에 연결하는 것이다. 문서가 있다고 되는 게 아니라, AI가 기계적으로 읽고 활용할 수 있는 형태로 노출해야 한다.
레이어 2: 생성 시점 보안 차단 — PR 올라가기 전에 막아야 한다
컨텍스트를 잘 주입해도 AI는 여전히 위험한 코드를 짠다. 그리고 그게 더 무섭다. 잘못된 코드가 아니라, 맞는데 위험한 코드를 짜기 때문이다.
dev.to에 올라온 실제 사고 사례다. Claude Code가 설정 파서 통합 작업에서 eval('(' + configString + ')') 를 썼다. 코드는 깔끔했고, 주석도 친절했고, 테스트도 통과했다. 시니어 엔지니어 두 명이 리뷰했고 머지됐다. 3일 후 보안 스캐너가 원격 코드 실행 취약점을 잡아냈다.
문제의 근본은 타이밍이다. SonarQube나 Snyk 같은 기존 도구들은 AI가 코드를 생성하고 개발자가 이미 다음 작업으로 넘어간 뒤에 알림을 보낸다. 그 시점엔 이미 노이즈다. 23개 발견 중 19개가 오탐인 상황에서 진짜 위협은 묻힌다.
이 팀이 만든 오픈소스 플러그인 Quadruple Verification은 다른 전략을 쓴다. Claude Code의 도구 실행 파이프라인에 훅을 걸어 파일이 기록되기 전에 차단한다. eval(), shell=True, innerHTML 직접 할당, chmod 777, curl | bash 파이프 실행—24개의 정규식 규칙이 50ms 이내에 실행되고, 위반이 감지되면 AI에게 즉시 피드백을 돌려보낸다. AI는 이유를 이해하고 JSON.parse()로 코드를 다시 쓴다. 개발자는 위험한 버전을 볼 일조차 없다.
세션 종료 시점에 AI가 자체 출력을 검토하는 스톱 훅도 있다. 이 컴포넌트만으로 에이전트 태스크 품질이 31.8% 향상됐다는 게 이 팀의 측정값이다. 완벽하진 않지만, 취약점을 트리아지 큐에 쌓지 않고 생성 루프 안에서 소거한다는 점에서 기존 접근과 근본적으로 다르다.
레이어 3: 리뷰 역할 재분배 — AI가 할 일과 사람이 할 일을 분리하라
Google 내부 연구에 따르면 개발자는 PR 리뷰에 주당 6~12시간을 쓴다. Microsoft 데이터로는 평균 PR이 첫 리뷰를 받기까지 24~48시간을 기다린다. LinearB의 2025년 조사에선 개발자 73%가 리뷰 대기를 개발 사이클의 최대 마찰 요소로 꼽았다.
AI 코드 리뷰 도구를 이 병목에 투입하는 건 당연한 수순이다. 그런데 'AI냐 사람이냐'를 고르는 게 아니라, 무엇을 AI에게, 무엇을 사람에게 맡길지를 설계하는 문제다.
AI(CodeRabbit, GitHub Copilot 등 LLM 기반 도구)가 잘하는 건 명확하다. null 체크 누락, 할인 로직 덮어쓰기 버그, 에러 핸들링 부재, 파라미터 유효성 검증 누락—코드의 의미를 읽고 논리적 결함을 잡는 일. 정규식 기반 정적 분석 도구는 알려진 패턴을 결정론적으로 탐지하는 데 최적화돼 있다. 이 두 가지를 조합하면 PR이 열리는 순간 반복적인 검사가 자동으로 완료된다.
사람이 해야 할 건 다르다. '이 접근법이 맞는가', '우리 도메인 모델에 부합하는가', '이 데이터 볼륨이 10배 늘면 어떻게 되는가', '지금 이 추상화 수준이 적절한가'—이런 판단은 조직 맥락과 경험이 없으면 불가능하다. AI는 코드가 '작동하는지' 볼 수 있지만, '옳은지'를 판단하려면 배포 환경과 성장 궤적을 알아야 한다.
실용적 역할 분리는 이렇다. AI가 첫 번째 리뷰어로 PR을 즉시 검토하고, 문법 오류·보안 패턴·명백한 논리 버그를 걸러낸다. 사람 리뷰어는 AI가 정리한 컨텍스트를 바탕으로 설계 의사결정, 비즈니스 로직, 아키텍처 영향을 판단하는 데 집중한다. 리뷰 대기 시간은 줄고, 사람의 인지 자원은 실제로 사람이 필요한 곳에 투입된다.
세 레이어가 맞물려야 한다
각 레이어를 따로 보면 개별 도구 도입처럼 보인다. 하지만 실제로는 연결된 하나의 설계 문제다.
컨텍스트 레이어(MCP)가 없으면 AI는 조직 표준을 무시한 코드를 생성한다. 생성 시점 보안 레이어가 없으면 깔끔하게 포장된 취약점이 리뷰를 통과한다. 리뷰 역할 재분배가 없으면 AI가 속도를 올려도 병목이 리뷰 큐로 이동할 뿐이다.
세 레이어가 맞물릴 때 비로소 AI 에이전트는 팀의 컨텍스트를 이해하고, 위험한 패턴을 스스로 피하고, 사람 리뷰어의 판단이 필요한 지점에만 에스컬레이션된다. 이게 'AI-First 워크플로우'가 실제로 작동하는 구조다.
테크 리드로서 내일 당장 시작할 것
전체 구조를 한번에 구축하려 하지 마라. 지금 팀에서 AI가 가장 자주 실패하는 지점 하나를 찾아라. 거기서 시작해라.
- AI가 내부 라이브러리를 모른다면: 가장 자주 쓰는 내부 도구 2~3개의 문서를 기계 가독성 있는 형태로 정리하고, MCP 서버 구성을 시작한다
- AI 생성 코드에서 보안 이슈가 반복된다면: Quadruple Verification 같은 생성 시점 훅을 붙여 팀이 가장 민감하게 보는 패턴부터 차단한다
- 리뷰 병목이 문제라면: AI 도구를 첫 번째 리뷰어로 설정하고, 사람 리뷰어가 집중할 체크리스트를 별도로 정의한다
레이어는 점진적으로 쌓인다. 중요한 건 순서가 아니라, 세 레이어가 모두 있어야 한다는 사실을 팀이 인식하는 것이다. 하나만 있으면 절름발이다. AI 에이전트가 빠른 만큼, 통제 설계의 빈틈도 빠르게 벌어진다.