지난 2월 23일, IBM 주가가 하루 만에 13.5% 폭락했습니다. 2000년 닷컴 버블 붕괴 이후 25년 만의 최대 낙폭입니다. 원인은 간단했습니다. Anthropic이 블로그에 한 줄을 썼죠. "Claude Code 같은 도구는 컨설턴트들이 수작업으로 해오던 COBOL 현대화를 자동화할 수 있다." 미국 ATM 거래 시스템의 95%를 떠받치고 있는 COBOL 유지보수, 그게 IBM의 핵심 수익원이었고, AI가 그걸 건드린 겁니다.
저는 이 뉴스를 보면서 두 가지 감정이 동시에 들었습니다. 하나는 "드디어 왔구나"는 감각, 다른 하나는 "우리 팀은 준비됐나?"는 불안감. Claude Code가 IBM을 흔들었다면, 다음은 어떤 레거시 도메인이 타깃이 될까요. 그리고 우리 팀은 AI에 대체되는 쪽에 서 있을까, 아니면 AI를 다루는 쪽에 서 있을까요.
같은 시기에 국내 협업툴 플로우(Flow)가 흥미로운 업데이트를 발표했습니다. '프로젝트 설계 AI 에이전트'를 탑재해서, 사용자가 프로젝트 목적을 입력하면 전체 업무 구조·일정·담당자 배치까지 자동 설계해준다는 겁니다. 회사 측이 공개한 수치가 인상적입니다. 프로젝트 초기 기획·설계 시간을 평균 80% 이상 단축했다고 합니다. 이게 현실이라면, 기획 단계에서 사람이 하던 일의 상당 부분이 이미 에이전트로 넘어간 겁니다.
"기획 단계부터 AI를 끼면 훨씬 효율적이에요"라는 말을 저도 팀원들한테 자주 합니다. 근데 플로우 사례를 보면서 새롭게 생각하게 됐어요. 80% 단축이 가능하다면, 지금 우리 팀이 기획에 쓰는 시간의 80%는 사실 자동화 가능한 반복 작업이었다는 뜻이기도 하거든요. 기획자와 PM의 역할이 '구조 설계'에서 '판단과 결정'으로 이동하고 있는 거고, 그 전환을 준비한 팀과 아닌 팀의 격차는 이미 벌어지기 시작했습니다.
그런데 여기서 진짜 문제가 터집니다. AI 에이전트가 더 많은 권한을 갖고 더 자율적으로 움직일수록, 기존 QA 방식이 완전히 무력화된다는 겁니다. QA 경력 10년의 개발자가 dev.to에 쓴 글이 이 문제를 정확하게 짚고 있어요. 에어캐나다 챗봇이 존재하지 않는 환불 정책을 만들어내 법정 비용을 치렀던 사건, 변호사가 ChatGPT가 지어낸 판례를 실제 소송 문서에 제출했던 사건. 이것들이 단순한 해프닝처럼 보이지만, QA 관점에서 보면 테스트 프로세스 자체의 실패입니다.
전통적 QA가 AI 에이전트에 실패하는 이유는 명확합니다. 에이전트는 결정론적이지 않아요. "입력 X → 출력 Y"라는 테스트 공식이 성립하지 않습니다. 더 심각한 건, 에이전트는 잘못된 행동을 할 때도 자신 있게 합니다. 버그가 있는 전통 시스템은 500 에러를 던지고 스택 트레이스를 뱉습니다. 하지만 프롬프트 인젝션으로 고객 데이터를 유출시킨 AI 에이전트는 에러 없이 정중하고 친절하게 응답합니다. 겉으로는 완벽하게 작동하는 것처럼 보이죠. 이게 팀 리드 입장에서 정말 무섭습니다.
Anthropicの내부 데이터에서도 이 변화가 수치로 확인됩니다. 숙련된 Claude Code 사용자의 40% 이상이 완전 자율 세션으로 작업하고 있고, 세션당 평균 인간 개입 횟수는 5.4회에서 3.3회로 줄었습니다. Human-in-the-loop가 제거되는 게 아니라 자연스럽게 증발하고 있는 거예요. 에이전트가 더 유능해질수록, 인간은 매 액션을 승인하는 게이트키퍼에서 이상 징후를 발견하는 모니터로 역할이 바뀌고 있습니다.
이 변화가 팀 리드에게 의미하는 바는 뭘까요? 저는 세 가지를 당장 해야 한다고 봅니다.
첫째, 자동화 가능한 영역을 먼저 파악하세요. IBM COBOL 사례처럼 AI가 '컨설팅 영역'을 건드리기 시작했다는 건, 우리 팀 내의 반복적·구조적 작업도 이미 에이전트 타깃이라는 뜻입니다. 기획 구조화, 테스트 케이스 초안 생성, 코드 리뷰 1차 검토—이것들을 먼저 에이전트로 전환하고, 팀원이 더 고차원적인 판단에 집중할 수 있게 해야 합니다.
둘째, AI 에이전트 전용 QA 프로세스를 지금 설계하세요. "AI가 생성해준 걸 기반으로 우리가 다듬으면" 된다는 말을 저도 했는데, 그 '다듬는 과정'에 적대적 시나리오 검증이 포함되어 있어야 합니다. 에이전트가 처리하는 외부 입력이 하나라도 있다면, 프롬프트 인젝션은 이미 우리 팀의 보안 문제입니다.
셋째, 팀원에게 'AI 도구 사용법'이 아니라 'AI와 협업하는 사고법'을 가르치세요. 플로우의 AI 에이전트처럼 "일의 시작은 AI가 맡는" 환경이 되면, 팀원이 가져야 할 스킬은 도구 조작이 아닙니다. AI가 만들어 놓은 구조에서 무엇이 빠졌는지, 어디서 판단이 필요한지를 보는 비판적 검토 능력입니다.
IBM 쇼크를 보고 'AI가 일자리를 빼앗는다'는 공포에 집중하는 건 비생산적입니다. 경희대 이경전 교수가 말했듯, 중요한 건 AI를 기회로 삼아 새로운 가치를 만드는 조직과 그렇지 못한 조직의 격차입니다. 팀 리드가 지금 해야 할 일은 그 격차의 어느 쪽에 팀을 세울지 결정하는 것이고, 그 결정의 시간이 생각보다 빠르게 좁혀지고 있습니다.
"이거 자동화하면 우리가 더 중요한 일에 집중할 수 있어요"—이 말이 팀원을 설득하는 멘트가 아니라, 팀 리드 스스로에게 하는 질문이 되어야 할 시점입니다. 자동화한 다음, 우리 팀은 무엇에 집중할 건가요?