“PM이 코드 리뷰를 한다고?” 2년 전까지만 해도 황당한 소리였다.
지금은 꼭 황당한 말이 아니다.
들어가며 — 현장에서 느낀 이상한 조짐
올해 초, 금융권 SI 프로젝트 미팅에 들어갔다가 흥미로운 장면을 목격했다. 개발팀 리더가 노트북을 열더니 터미널 창에 뭔가를 타이핑하기 시작했다. 잠시 후 화면에 수백 줄의 코드가 줄줄이 생성됐다. 그가 한 건 딱 세 줄짜리 자연어 지시문이었다.
“기존 고객 테이블과 거래 이력 테이블 조인해서 최근 3개월 비활성 고객 추출하는 쿼리랑 배치 스크립트 만들어줘.”
10년 차 개발자가 2시간 걸릴 작업이 3분 만에 초안으로 나왔다. 물론 검토와 수정이 필요했다. 하지만 ‘시작점’이 완전히 달라진 것이다.
이게 2026년 현재 개발 프로젝트 현장에서 실제로 벌어지고 있는 일이다. AI 자동화 툴이 개발 프로젝트를 어떻게 바꾸고 있는지, 거품 없이 현장 시각으로 정리해 보려 한다. PM과 IT 아키텍트 관점에서 본 날 것의 이야기다.
1. 지금 무슨 일이 벌어지고 있나 — 숫자로 보는 충격
감이 아니라 숫자로 보면 더 선명하다.
GitHub 통계가 말해주는 것: 2025년 한 해 동안 GitHub에 병합된 풀 리퀘스트(PR)가 월평균 4,320만 건이었다. 전년 대비 23% 증가다. 코드 커밋 수는 10억 건, 증가율 25%. 전 세계 개발자 수가 갑자기 25% 늘어난 게 아니다. AI가 코드를 쓰기 시작한 것이다.
가트너의 예측: 2026년까지 기업 애플리케이션의 40%가 작업 특화 AI 에이전트를 내장할 것이라고 한다. 2025년 기준 5% 미만이었던 수치가 단 1년 만에 8배 뛰는 셈이다. 더 나아가 2028년에는 90%의 기업 앱이 AI 에이전트를 품게 된다.
생산성 데이터에서 가장 눈에 띄는 수치: 한 글로벌 컨설팅 펌 보고서에 따르면, 생성형 AI 도입으로 개발자 생산성이 약 30% 향상됐는데, 에이전틱 AI로 넘어가자 무려 200% 향상됐다고 한다. 생성형 AI와 에이전틱 AI 사이에 이렇게 큰 벽이 있다.
이 숫자들이 의미하는 건 하나다. 우리는 지금 ‘도구 교체’가 아니라 ‘개발 패러다임의 전환’을 목격하고 있다.
2. Agentic AI — ‘보조’에서 ‘실행 주체’로
여기서 핵심 개념 하나를 짚고 넘어가야 한다. 요즘 업계에서 가장 많이 들리는 키워드, **에이전틱 AI(Agentic AI)**다.
쉽게 말하면 이렇다. 기존 생성형 AI는 “이 코드 함수 하나 만들어줘” → AI가 만들어줌 → 내가 붙여넣음 → 끝. 한 번의 요청-응답이다.
에이전틱 AI는 다르다. “이 레거시 시스템을 새 아키텍처로 마이그레이션해줘”라고 하면, AI가 스스로 현재 코드베이스를 분석하고, 마이그레이션 플랜을 세우고, 단계별로 코드를 수정하며, 테스트를 실행하고, 오류가 나면 스스로 수정한다. 몇 시간, 심하면 며칠짜리 작업을 자율적으로 처리한다.
AWS re:Invent 2025에서 CEO 맷 가먼이 이런 말을 했다. “AI가 더 이상 도구가 아니라 팀의 연장(extension of your team)이다.” 립서비스가 아니었다. AWS가 발표한 ‘프론티어 에이전트’는 소프트웨어 개발팀의 팀원처럼 작동하면서, PR을 분석하고, 피드백을 학습하고, 버그 트리아지와 코드 커버리지 개선을 여러 리포지토리에 걸쳐 자율적으로 수행한다.
마이크로소프트의 GitHub Copilot도 2025년 11월 공개된 Copilot Studio를 통해 이메일, 캘린더, Teams, SharePoint를 넘나들며 회의 일정 조율부터 사전 자료 업로드까지 전 과정을 혼자 처리하는 에이전트를 만들 수 있게 됐다.
개발자가 타자수에서 오케스트레이터가 되어가는 시대다.
3. 현장에서 쓰이는 주요 AI 개발 툴 — 솔직한 비교
말만 들으면 다 좋아 보인다. 현장에서 실제로 어떤 툴이 쓰이고, 각각 어떤 맥락에 맞는지 정리해 보자. 2026년 현재 가장 뜨거운 5종 비교다.
🛠 Cursor — “아직 이걸로 충분하다”
AI 퍼스트 IDE. VS Code를 포크(Fork)해서 만든 에디터인데, AI 기능이 에디터 안에 완전히 녹아들어 있다. 특징은 프로젝트 전체 인덱싱이다. 수만 줄의 코드베이스를 통째로 이해하고, 새 라이브러리 도입이나 대규모 리팩토링 때도 맥락을 잃지 않는다.
‘Composer’ 모드는 여러 파일을 동시에 수정해야 하는 복잡한 기능을 자연어 한 줄로 처리한다. 스타트업이나 빠르게 결과물을 뽑아야 하는 팀에서 압도적인 지지를 받는 이유가 여기 있다.
2025년 초 ARR 1억 달러를 달성했고, 기업가치 99억 달러로 평가받으며 9억 달러를 투자받았다. 일 활성 사용자 100만 명. 직원 수 100명. 이 비율이 무섭다.
적합한 팀: 빠른 프로토타이핑이 필요한 스타트업, AI 바이브코딩 개발자, 풀스택 개발자
요금: Pro $20/월, Pro+ $60/월
한계: 아키텍처나 요구사항 수준의 거버넌스 기능은 부족하다
🛠 GitHub Copilot — “엔터프라이즈의 표준”
전 세계 엔터프라이즈 80% 이상이 도입했다는 수치가 이 툴의 위상을 말해준다. VS Code, JetBrains 등 기존 IDE에 자연스럽게 붙는 구조라 개발팀 온보딩이 쉽다.
2025년부터는 단순 코드 완성을 넘어 리포지토리 인텔리전스(Repository Intelligence) 기능이 본격화됐다. 코드 변경 이력, 변경 이유, 패턴을 분석해서 더 스마트한 제안과 빠른 오류 탐지, 수정 자동화를 지원한다.
GitHub Copilot Agent 모드는 이슈 생성부터 PR까지 개발 프로세스 전체를 자동화한다. 멀티 모델 지원으로 가벼운 작업은 빠른 모델, 복잡한 설계는 고성능 모델을 선택해 쓸 수 있다.
적합한 팀: 대규모 엔터프라이즈 개발팀, GitHub 생태계에 깊이 연결된 조직
요금: Pro $10/월, Pro+ $39/월
한계: 비용 대비 기능을 따지면 다른 툴에 밀릴 수 있다
🛠 Claude Code — “아키텍트의 선택”
Anthropic이 내놓은 터미널 기반 코딩 어시스턴트. 철학부터 다르다. GitHub Copilot이 “개발자가 항상 주도권을 갖는다”라면, Claude Code는 “개발자와 대등하게 협업한다”는 접근이다.
터미널에서 연속적으로 처리를 이어가면서 중간에 확인을 최소화하는 방식이라, 복잡하고 장기적인 작업에서 진짜 힘이 난다. 난이도 높은 아키텍처 분석, 레거시 코드 이해, 대규모 리팩토링에서 다른 툴보다 탁월하다는 평가가 지배적이다.
현장 개발자들 사이에서 “일 시키면 알아서 한다”는 말이 나온다. 실제로 수십 개 파일을 넘나들며 맥락을 유지한 채로 작업을 완결짓는 능력이 다르다.
적합한 팀: 아키텍트, 선임 개발자, 복잡한 레거시 시스템을 다루는 팀
요금: Pro $17/월, Max $100~
한계: 터미널 기반이라 시각적 IDE에 익숙한 개발자에게는 러닝 커브가 있다
🛠 Windsurf — “흐름을 끊지 않는 도구”
Codeium이 출시한 AI 코딩 에디터로, Cursor의 강력한 대항마다. 핵심 기술은 Cascade. 개발자의 작업 흐름(flow)을 끊지 않으면서 맥락을 장기간 유지하는 능력이 독보적이다.
Cursor가 여러 파일 동시 수정에 강하다면, Windsurf는 긴 시간 동안 컨텍스트를 잃지 않고 작업을 이어가는 데 강하다. 장시간 복잡한 기능 개발이 필요한 세션에서 진가를 발휘한다.
적합한 팀: AI 바이브코딩에 익숙한 개발자, 장시간 복잡한 기능 개발이 잦은 팀
🛠 AWS Kiro — “스펙에서 배포까지, 전 주기”
2026년에 등장한 가장 야심 찬 신인이다. 개발 전 주기를 커버하는 유일한 도구를 표방한다. 기존 AI 코딩 툴이 ‘코드를 어떻게 잘 쓰느냐’에 집중했다면, Kiro는 ‘스펙을 어떻게 잘 정의하고, 그것이 끝까지 추적되느냐’를 본다.
EARS(Easy Approach to Requirements Syntax) 기반의 요구사항 작성부터 시작해서, 그 요구사항이 코드로 구현되고, 테스트가 자동 생성되고, PR 전 체크리스트가 자동 실행되는 전 과정을 하나의 흐름으로 잇는다. PM 입장에서 보면, 이건 단순한 개발 도구가 아니다. 요구사항 추적(Requirement Traceability)을 AI가 자동화하는 것이다.
적합한 팀: 빠른 프로토타이핑 후 프로덕션까지 이어가는 스타트업, 스펙 기반 거버넌스가 필요한 조직
한계: 현재 프리뷰 버전이라 일부 기능 제한이 있고, Spec·EARS·Hooks 등 개념의 러닝 커브가 존재한다
4. 툴 선택 가이드 — 어디에 뭘 써야 하나
솔직히 말하면, 2026년 현재 이 툴들은 서로 수렴하고 있다. “All of these products are converging.” 글로벌 개발자 커뮤니티에서 이미 나오는 말이다. 핵심 기능은 대동소이해지고 있다.
그렇다면 선택 기준은 팀 성격과 프로젝트 맥락이다.
| 상황 | 추천 툴 | 이유 |
|---|---|---|
| 스타트업, 빠른 MVP 개발 | Cursor | 빠른 프로토타이핑, 멀티 파일 동시 수정 |
| 엔터프라이즈 대형 프로젝트 | GitHub Copilot | 보안, 컴플라이언스, 생태계 통합 |
| 레거시 시스템 분석/마이그레이션 | Claude Code | 깊은 추론, 장기 컨텍스트 유지 |
| 장시간 복잡한 기능 개발 | Windsurf | Cascade 기술, 흐름 유지 능력 |
| 요구사항~배포까지 전 주기 관리 | AWS Kiro | 스펙 기반 추적, PM 친화적 거버넌스 |
한 가지 확실한 건 — 지금 이 툴들 중 하나도 쓰지 않는 팀은, 쓰는 팀보다 명백히 느리다. 이건 이제 취향의 문제가 아니다.
5. PM은 이 변화를 어떻게 봐야 하나 — 현장 관리자의 시각
솔직히 털어놓자. 나는 25년 가까이 IT 프로젝트를 관리해 왔다. IBM에서 금융권, 공공, 컨택센터 SI까지. 이 업계에서 ‘혁명적 변화’라는 말은 수도 없이 들었다. 대부분은 과장이었다.
이번에는 다르다고 느낀다. 단순히 개발 속도가 빨라지는 게 아니라, 프로젝트 관리 방식 자체가 흔들린다.
변화 1: WBS 산정 방식이 달라진다
지금까지 WBS를 짤 때 개발 공수는 ‘경험 기반 + 유사 사례 참조’였다. AI 툴이 들어오면 이 공수 산정 자체가 변한다. 기존에 5일 걸리던 작업이 2일로 줄어들 수 있다. 반면 AI가 생성한 코드를 검토하고 검증하는 시간이 새로 생긴다. WBS 항목이 재편된다.
발주처와의 견적 협의도 달라질 수밖에 없다. “AI 썼으니까 인건비 낮춰야 하는 거 아니냐”는 말이 나오기 시작한다. 실제로 일부 발주처에서 벌써 이런 협상 압박이 들어오고 있다.
변화 2: 팀 구성과 역할 재정의
코딩은 AI가 하는 비중이 커질수록, 개발자의 역할은 ‘AI가 생성한 코드를 검증하고, 아키텍처적 판단을 내리고, 비즈니스 컨텍스트를 연결하는 것’으로 이동한다. 단순 구현 중심 개발자보다 도메인 지식 + 아키텍처 사고력 + AI 오케스트레이션 능력을 갖춘 사람이 팀에서 가치 있어진다.
PM은 이 변화에 맞게 팀 구성 논리를 바꿔야 한다. ‘개발자 몇 명’이 아니라 ‘어떤 AI 툴을 쓰는 어떤 역할의 개발자 몇 명’이라는 프레임이 필요해진다.
변화 3: 품질 관리의 새로운 위험
AI가 코드를 생성할 때 가장 무서운 건, 틀렸는데 그럴싸해 보이는 코드다. 코드 리뷰를 제대로 못 하면, AI가 만든 취약한 코드가 그대로 프로덕션에 올라간다.
GitHub Copilot은 이미 하드코딩된 자격증명, SQL 인젝션, 경로 인젝션 같은 보안 취약 패턴을 탐지하는 필터를 내장하고 있다. 하지만 비즈니스 로직의 오류나 도메인 특화 버그는 여전히 사람이 잡아야 한다.
결국 PM은 코드 리뷰 게이트를 강화하고, AI 생성 코드에 대한 검증 프로세스를 별도로 정의해야 한다. 이게 새로운 품질 관리 과제다.
변화 4: 거버넌스와 감사 추적
가트너는 AI 에이전트 도입 실패의 주요 원인으로 ‘거버넌스 모델 부재’를 꼽는다. AI가 자율적으로 코드를 수정하고 배포 파이프라인을 건드리는 상황에서, 감사 로그(Audit Log)와 책임 소재가 불분명해지는 문제가 실제로 발생하고 있다.
GitHub Copilot Enterprise는 이미 ‘상세 감사 로그로 에이전트 활동 추적’을 핵심 기능으로 내세우고 있다. 프로젝트 거버넌스 문서에 ‘AI 사용 정책’과 ‘생성 코드 검증 절차’를 포함시키는 게 이제 필수다.
6. 에이전틱 AI 시대의 프로젝트 관리 — 실전 적용 프레임
25년 현장 경험과 최신 트렌드를 결합해서, AI 자동화 툴이 투입된 프로젝트에서 PM이 실제로 써먹을 수 있는 프레임을 정리해 보면 이렇다.
Phase 1: 파일럿 기반 도입 (0~1개월)
처음부터 전 팀에 AI 툴을 박는 건 실패 확률이 높다. 반복적이고 업무량이 많으며 규칙이 명확한 작업부터 시작해라. FAQ 응답, 예약 관리, 단순 CRUD API 생성 같은 것들. 여기서 빠른 ROI를 확인하고 수작업 감소 효과를 측정한 뒤 확장한다.
팀 내에서 AI 툴에 친숙한 개발자 1~2명을 ‘파일럿 챔피언’으로 지정하고, 그 사람들이 먼저 실전에서 검증해서 베스트 프랙티스를 만들게 하는 방식이 효과적이다.
Phase 2: 워크플로우 통합 (1~3개월)
AI 툴이 단순 코드 생성을 넘어 실제 개발 파이프라인에 녹아들어야 한다. CI/CD 파이프라인에 AI 기반 코드 검토 단계를 추가하고, 테스트 자동화 커버리지를 AI가 관리하도록 설정한다.
요구사항 관리 도구(Jira, 또는 Kiro 같은 AI 네이티브 도구)와 코딩 툴이 연동되면, 요구사항 변경이 코드에 어떤 영향을 주는지 실시간으로 추적하는 것이 가능해진다. 이게 되면 변경 관리(Change Management)의 품질이 완전히 달라진다.
Phase 3: 에이전틱 운영 (3개월 이후)
이 단계에서는 AI가 단순 보조를 넘어 특정 작업 영역의 실질적인 실행 주체가 된다. 버그 트리아지, 테스트 코드 작성, 문서 업데이트 같은 영역에서 AI가 자율적으로 PR을 생성하고, 사람이 최종 승인만 하는 방식이다.
단, 이 단계에서 가장 중요한 건 ‘인간 개입 지점’을 명확히 정의하는 것이다. AI가 알아서 다 하도록 두면 안 된다. 특히 비즈니스 로직 변경, 보안 관련 코드, 외부 API 연동 부분은 반드시 사람이 검토하는 게이트를 유지해야 한다.
7. 지금 당장 써야 할 도구 vs. 조금 더 두고 봐야 할 도구
현장 관리자 시각에서 솔직하게 나눠보자.
지금 당장 도입 권고:
- GitHub Copilot: 가장 안전하다. 엔터프라이즈 보안, 컴플라이언스가 이미 검증됐다. IDE 통합이 자연스러워서 팀 저항이 낮다. ROI가 빠르게 나온다.
- Cursor: 스타트업이나 빠른 결과가 필요한 프로젝트. 프로토타이핑 속도가 압도적으로 빠르다.
- Claude Code: 레거시 코드 분석이나 복잡한 아키텍처 설계가 필요할 때. 선임 개발자나 아키텍트 레벨에서 먼저 적용하면 좋다.
조금 더 두고 볼 도구:
- AWS Kiro: 방향성은 옳다. PM 관점에서 가장 흥미롭다. 하지만 프리뷰 버전이라 안정성 검증이 더 필요하다. 6개월 후 재평가 권고.
- 완전 자율 Agentic 파이프라인: 기술적으로 가능해지고 있지만, 거버넌스와 리스크 관리 체계 없이는 도입하면 안 된다. 준비 없는 도입은 높은 실패율로 이어진다는 게 가트너의 경고다.
8. 국내 상황 — 우리는 어디에 있나
한국 상황도 짚어보자.
정부 차원에서 AI 3강 국가 도약을 선언하고, 2026년 AI 예산을 전년 대비 약 3배 확대하는 대규모 투자가 발표됐다. 대통령실에 AI 미래기획수석 직제까지 신설됐다.
문제는 기업 현장이다. 대기업 IT 부서는 빠르게 움직이고 있다. GitHub Copilot 엔터프라이즈 도입은 이미 상당수 대기업에서 진행 중이다. 금융권은 보안 이슈로 에어갭(Air-gap) 환경에서 쓸 수 있는 온프레미스형 AI 코딩 어시스턴트를 찾고 있다. CodeCenter 같은 온프레미스 AI 코딩 솔루션이 주목받는 이유가 여기 있다.
중소 SI 업체나 공공 프로젝트 현장은 여전히 속도가 느리다. 도입 의지는 있지만 어떻게 도입할지, 발주처가 AI 사용을 허용할지 같은 실무적인 질문들이 아직 정리가 안 돼 있다.
특히 공공 프로젝트에서는 ‘AI가 생성한 코드는 저작권이 누구에게 있나’, ‘AI 생성 산출물을 검수 기준에 어떻게 적용하나’ 같은 법적, 계약적 이슈가 아직 회색지대다.
이 회색지대를 먼저 정리하고 표준 프레임을 만드는 PM이, 앞으로 이 시장에서 가장 큰 가치를 가질 것이라고 생각한다.
9. AI 자동화 도입의 함정 — 현장에서 직접 본 실패 패턴
장밋빛 이야기만 하면 거짓말이다. 현장에서 직접 목격한 실패 패턴도 공유해야 한다.
함정 1: AI가 생성한 코드를 검토 없이 배포 빠른 게 좋은 게 아니다. AI가 그럴싸한 코드를 생성하지만, 실제 비즈니스 로직과 미묘하게 다른 경우가 있다. 특히 도메인 특화 규칙이 많은 금융, 보험 시스템에서 이런 문제가 두드러진다. 검토 프로세스를 간소화하고 싶은 유혹을 참아야 한다.
함정 2: 팀원 저항을 무시한 강제 도입 “이제부터 다 AI로 해”라고 선언하면 반드시 부작용이 난다. 개발자들의 두려움(내 일자리가 없어지는 건 아닌가)과 불신(이게 진짜 내 코드가 맞나)을 먼저 다뤄야 한다. 파일럿 챔피언을 내세워 동료가 동료를 설득하게 하는 방식이 훨씬 효과적이다.
함정 3: 하나의 도구로 모든 걸 해결하려는 착각 Cursor 하나로 엔터프라이즈 전체를 돌리려다 실패하는 케이스가 있다. 요구사항 관리, 코드 생성, 테스트 자동화, 배포 파이프라인 각 단계에 맞는 도구를 조합해야 한다.
함정 4: 컨텍스트 없는 프롬프트 AI 툴은 좋은 지시문(instruction)이 없으면 나쁜 결과를 낸다. 프롬프트 품질이 곧 산출물 품질이다. 팀의 코딩 규약, 아키텍처 원칙, 도메인 용어를 정리한 ‘컨텍스트 파일’을 먼저 만들고 AI에게 먹이는 것이 선행돼야 한다.
10. 앞으로 2년 — PM과 개발자가 준비해야 할 것
2026년이 에이전틱 AI의 원년이라면, 2027~2028년은 정착의 시기다. 이 흐름 속에서 IT 프로젝트 관리자와 개발자가 준비해야 할 것을 정리한다.
PM이 갖춰야 할 것:
- AI 생성 코드에 대한 기본적인 리뷰 능력 (비개발자 PM도 이제는 코드 감각이 필요하다)
- AI 도구 활용 정책과 거버넌스 문서 작성 역량
- 발주처와의 AI 관련 계약 조항 협의 능력
- AI 도구 도입 시 공수 산정 기준 재정립
개발자가 갖춰야 할 것:
- AI 오케스트레이션 능력 (AI에게 무엇을, 어떻게 지시할지 설계하는 능력)
- 도메인 지식 심화 (AI가 대체 못 하는 영역이 결국 비즈니스 컨텍스트 이해다)
- AI 생성 코드 검증 역량 (빠르고 정확하게 AI 산출물을 검토하는 스킬)
- 아키텍처적 사고력 (AI가 구현을 하더라도, 무엇을 구현할지는 사람이 설계한다)
마치며 — 개발이 바뀌는 것이지, 개발자가 사라지는 것이 아니다
다시 처음으로 돌아가서.
AI 자동화 툴이 개발 프로젝트를 바꾸고 있다. 이건 부정할 수 없는 사실이다. 하지만 “개발자가 없어진다”는 말에는 동의하지 않는다.
타이피스트가 없어진 건 타자기가 사라진 게 아니라, 타이핑이 누구나 하는 기본 스킬이 됐기 때문이다. 마찬가지로, 기본적인 코드 생성은 AI가 하게 되면서 ‘개발자’의 정의가 바뀌는 것이다.
AI가 코드를 빠르게 쓸 수 있게 됐다는 것은, 더 많은 아이디어를 더 빠르게 실험할 수 있게 됐다는 뜻이다. 오히려 더 많은 개발이 필요해질 수 있다.
중요한 건 이 변화를 무시하거나 두려워하는 것이 아니라, 이 도구들을 프로젝트 현장에 어떻게 안착시킬지를 설계하는 것이다.
그게 지금 우리 PM들이 해야 할 일이다.