에이전트가 PM, Dev, QA를 직접 흉내 내기 시작했다
dev.to에 공개된 VegaAI 프로젝트는 흥미로운 실험이다. Notion MCP를 '두뇌'로 삼고, PM 에이전트·스크럼 마스터 에이전트·Dev 에이전트·QA 에이전트가 스프린트를 돌린다. PRD 작성부터 스토리 분해, 코드 생성, GitHub 푸시, QA 검토까지 한 사이클이 자동으로 돌아간다. 스토리가 실패하면 QA가 Notion에 실패 노트를 남기고, Dev 에이전트가 이전 실패 맥락을 참고해 재시도한다. 겉으로 보면 인간 팀의 스프린트 루프와 구조가 같다.
이걸 보고 '우리 팀 절반을 대체할 수 있겠다'고 생각했다면, 잠깐 멈춰야 한다. VegaAI가 증명한 것은 역할 대체가 아니라 역할 재정의의 가능성이다. Notion이 상태 머신이 되고, 에이전트들이 그 상태를 읽고 쓰는 구조—이건 기존 애자일 보드를 AI 실행 컨텍스트로 전환한 것이다. 인간이 빠진 게 아니라, 인간의 역할이 '실행자'에서 '상태 설계자'로 이동한 것이다.
대부분의 팀이 AI를 잘못 쓰고 있다는 불편한 진실
dev.to의 또 다른 글 'Most Developers Are Using AI Wrong'은 직설적이다. 지금 대부분의 개발자가 AI를 쓰는 패턴은 이렇다: 프롬프트 → 코드 생성 → 복붙 → 실행 → 반복. 문제는 이 루프가 속도를 올리는 게 아니라 혼란을 가속시킨다는 점이다. AI는 생각의 필터가 아니라 증폭기다. 명확한 의도가 있으면 더 좋은 결과가 나오고, 흐릿한 의도로 쓰면 흐릿한 시스템이 빨리 만들어진다.
에이전트 레벨로 올라가면 이 문제는 더 심각해진다. VegaAI처럼 멀티 에이전트가 자율로 코드를 짜고 배포하는 구조에서, 팀이 '빠르게 결과물이 나온다'는 사실에 취해 출력물을 제대로 검증하지 않으면—그 시스템은 빠르게 무너진다. AI가 만든 결과물을 AI가 리뷰하는 루프는, 인간의 판단이 개입하지 않으면 확증 편향의 자동화일 뿐이다.
에이전트 도입이 진짜 깨뜨리는 것: 인가, 컨텍스트, 인지 부채
3년간 170만 개발자 플랫폼 인프라를 구축하고 OpenFGA를 메인테인한 Siddhant Khare의 'Agentic Engineering Guide'(216페이지, 33챕터)는 이 지점을 가장 정확하게 짚는다. 팀이 Level 2(챗 에이전트)에서 Level 3(코드 실행·API 호출·파일 쓰기 에이전트)으로 전환할 때 가장 먼저 터지는 건 모델 성능이 아니라 인가(Authorization) 문제다.
에이전트는 개발자 권한 그대로 DB에 접근하고, 새벽 2시에 프로덕션 환경에서 자율로 실행된다. 아무도 보지 않는다. VegaAI가 GitHub MCP로 코드를 푸시하는 구조도 동일한 리스크를 안고 있다. 가이드가 제안하는 'Rule of Two'—어떤 에이전트 액션도 되돌릴 수 없는 작업은 두 번 이상 확인 없이 실행하지 않는다—는 AI-First 팀이 워크플로우 설계 단계에서 반드시 내재화해야 할 원칙이다.
컨텍스트 문제도 간과하기 쉽다. LLM에 보내는 컨텍스트의 30~40%가 중복이다. 같은 사실이 코드 주석, 문서, FAQ, API 문서에 각각 다르게 기술되어 있으면 모델은 혼란스러워하고, 같은 입력에도 다른 출력이 나온다. VegaAI가 Notion을 단일 상태 머신으로 삼은 설계는 이 문제를 구조적으로 완화하는 시도이기도 하다—모든 에이전트가 같은 소스에서 맥락을 읽는다.
가장 조용하고 가장 위험한 문제: 인지 부채
Khare의 팀에서 머지된 PR의 88.5%가 에이전트 작성 코드라는 수치는 자랑이 아니라 경고라고 그는 직접 말한다. 코드가 맞아도 팀의 시스템 이해도는 계속 떨어진다. 개발자는 개별 PR을 리뷰할 수 있어도, 그 PR들이 쌓여 만드는 시스템 전체를 이해하지 못하게 된다. 이게 인지 부채(Cognitive Debt)다.
기술 부채는 리팩터링으로 갚을 수 있다. 인지 부채는 더 비싸다. 에이전트가 짠 코드를 처음부터 다시 읽고, 설계 맥락을 재구성하고, 팀 전체가 돌아가며 코드베이스를 만져야 한다. AI-First 팀 리빌딩에서 '누가 어떤 AI 도구를 쓰는가'보다 '팀이 시스템 전체를 얼마나 이해하고 있는가'를 주기적으로 점검하는 프로세스가 필요한 이유다.
AI 에이전트 도입, 우리 팀은 어디 서 있나
Khare의 성숙도 모델은 팀 현황 진단에 실용적이다. Level 1(개인 Copilot 사용, 공유 정책 없음)에서 Level 5(에이전트 24/7 자율 운영, 인간은 목표 설정과 결과 리뷰만)까지 5단계다. 2026년 초 기준 대부분의 팀은 Level 2에 머물러 있다고 그는 말한다. Level 3로의 전환—에이전트가 CI/CD 파이프라인에 들어가고, 자동 품질 게이트가 생기는 단계—이 진짜 엔지니어링 규율이 요구되는 지점이다.
VegaAI 같은 실험이 보여주는 건 Level 4~5의 가능성이다. 하지만 우리 팀 대부분은 아직 Level 2에서 Level 3로 넘어가는 구간에 있다. 이 구간에서 해결해야 할 건 더 좋은 에이전트 선택이 아니다. 에이전트 인가 정책, 컨텍스트 정제 구조, 인지 부채 관리 프로세스—이 세 가지를 팀 워크플로우에 명시적으로 설계하는 일이다.
에이전트 시대의 팀 리빌딩, 진짜 질문은 따로 있다
'AI 에이전트가 PM, Dev, QA 역할을 대체하는가'는 사실 잘못된 질문이다. 옳은 질문은 이것이다: 에이전트를 팀에 투입했을 때, 인간 팀원이 해야 하는 더 어려운 판단은 무엇인가. 문제 정의, 시스템 설계, 출력 검증, 인지 부채 관리—이게 에이전트 시대에 팀이 더 잘해야 하는 일들이다. AI는 실행 속도를 올려주지만, 판단의 질은 여전히 인간에게 달려 있다. 그리고 그 판단이 흐릿할수록, AI는 그 흐릿함을 더 빠르게 증폭한다.