AI 에이전트를 팀에 앉혔더니 생긴 일
"이거 Claude한테 시켜보니까 PR까지 알아서 올리더라고요." 최근 팀 내에서 이런 말이 자연스러워졌습니다. 그런데 정작 운영해보면, 에이전트가 만든 PR의 절반은 사람이 다시 손봐야 하고, 빌드가 깨져서 되돌리는 일도 심심찮게 벌어집니다. AI 코딩 에이전트를 팀 워크플로우에 끼우는 건 이제 '할지 말지'의 문제가 아닙니다. '어디까지 맡기고, 어디서 사람이 끊을지' — 이 경계선을 설계하는 게 진짜 과제입니다.
세 개의 도구가 보여주는 자동화의 스펙트럼
GitHub가 테크니컬 프리뷰로 공개한 'Agentic Workflows'는 꽤 명확한 철학을 갖고 있습니다(디지털투데이 보도). 개발자가 마크다운으로 원하는 결과를 기술하면 GitHub Actions 위에서 Copilot CLI, Claude, Codex 같은 에이전트가 작업을 수행하되, 사용 시점과 범위의 결정권은 개발자에게 남긴다는 설계입니다. GitHub Next 팀이 출발점으로 삼은 질문 — "가드레일을 갖춘 리포지토리 자동화는 어떤 모습이어야 하는가" — 이 질문 자체가 이 도구의 성격을 규정합니다. 전자동이 아니라 의도 기반(Intent-driven) 반자동인 거죠.
한편 dev.to에서 소개된 Code Scalpel은 에이전트의 '비용'과 '안전'이라는 실무적 통증에 정면으로 대응합니다. 핵심은 AST 파서와 Program Dependence Graph(PDG)를 활용해 LLM에 넘기는 컨텍스트를 97% 이상 줄이는 것입니다. 파일 전체 대신 관련 함수와 의존성만 추출해서 200토큰으로 압축하면, GPT-4 기준 호출당 비용이 $0.025에서 $0.0006으로 떨어집니다. 더 중요한 건 에이전트가 생성한 코드를 디스크에 쓰기 전에 AST로 구문 검증하는 게이트키퍼 역할입니다. 괄호 하나 빠진 코드가 빌드를 깨뜨리기 전에 차단하고, 모든 판단을 감사 로그에 남깁니다. AI로 리뷰 받아보니까, "에이전트의 실수를 에이전트가 쓰기 전에 잡는" 이 구조가 팀 신뢰를 만드는 핵심이더라고요.
Claude Code의 활용 사례는 에이전트를 팀 워크플로우에 구조적으로 녹이는 방법을 구체적으로 보여줍니다. Custom Command로 /review 한 번이면 코드 리뷰가, /deploy를 치면 배포 전담 Sub-agent가 AWS 배포 절차 Skills을 참조해서 실행됩니다. 특히 Hook 시스템 — PreToolUse로 위험 명령어를 사전 차단하고, PostToolUse로 자동 포매팅을 걸고, 모든 도구 입력을 감사 로그에 기록하는 구조 — 은 Code Scalpel의 가드레일 철학과 정확히 같은 방향을 가리킵니다. CLAUDE.md에 프로젝트 컨텍스트를 주입해두면 매번 "우리 프로젝트는 Next.js 쓰고..."라고 설명할 필요가 없다는 점도, 기획 단계부터 AI를 끼면 훨씬 효율적이라는 걸 체감하게 해줍니다.
그래서 에이전트가 '못 하는' 건 뭔가
여기서 냉정하게 짚어야 할 지점이 있습니다. dev.to의 또 다른 글에서 한 React Native 개발자가 쓴 문장이 정곡을 찌릅니다: "AI can see the blueprint but it can't see the building." AI 어시스턴트는 정적 코드(static code)는 읽지만, 그 코드가 런타임에서 실제로 무엇을 하는지 — 네트워크 요청의 타이밍, 상태 변경의 인과 관계, 특정 디바이스에서만 재현되는 버그 — 는 전혀 알지 못합니다. 디버깅의 병목은 코드를 고치는 게 아니라 뭘 고쳐야 하는지 파악하는 것인데, 에이전트는 바로 그 파악 단계에서 눈이 멀어 있다는 겁니다.
AI-First 팀이 설계해야 할 '경계선'
세 도구와 한 편의 한계 분석을 종합하면, AI 코딩 에이전트를 팀에 도입할 때의 원칙이 꽤 선명해집니다.
- 생성은 에이전트, 검증은 구조로. Code Scalpel의 AST 게이트키퍼처럼, 에이전트가 만든 결과물이 디스크에 닿기 전에 자동 검증 레이어를 반드시 끼워야 합니다. Claude Code의 Hook 시스템도 같은 맥락입니다.
- 컨텍스트는 수술적으로 제공. 파일 전체를 던지면 비용도 폭발하고 정확도도 떨어집니다. PDG 기반 추출이든 CLAUDE.md 방식이든, 에이전트에게 '필요한 것만' 건네는 구조를 설계하세요.
- 런타임 맹점은 사람이 메운다. 에이전트는 코드를 쓰고 리뷰하고 배포까지 돕지만, 프로덕션에서 벌어지는 일의 인과를 추론하는 건 아직 사람의 몫입니다. 이 영역이야말로 팀원들이 집중해야 할 '더 중요한 일'입니다.
- 결정권은 개발자에게. GitHub Agentic Workflows가 에이전트 사용 시점과 범위를 개발자가 통제하도록 설계한 건 우연이 아닙니다. 자동화의 범위를 코드로 선언하고, 감사 추적이 가능하게 만들어야 팀 단위 신뢰가 쌓입니다.
AI 에이전트 시대, 팀의 역할은 '조종'이 아니라 '설계'
솔직히 말하면, 지금 AI 코딩 에이전트 도구들은 '자동 조종 장치'가 아닙니다. 반자동 기어에 가깝습니다. 기어를 언제 넣고 빼는지, 어떤 도로에서는 수동으로 전환하는지 — 그 판단 체계를 설계하는 것이 AI-First 팀의 진짜 역할입니다. 런타임 컨텍스트를 에이전트가 이해할 수 있는 포맷으로 변환하는 도구가 등장하면 이 경계선은 다시 움직이겠지만, 그때도 경계선을 '어디에 그을지' 결정하는 건 여전히 사람의 일일 겁니다. AI가 생성해준 걸 기반으로 우리가 다듬는 모델 — 이 협업 구조의 정밀도를 높이는 데 팀의 에너지를 쓰세요.