Claude Code, Codex, Devin 등의 AI 코딩 에이전트를 사용하는 조직이 늘어나고 있다고 생각합니다. 구현, 조사, 테스트 추가, 리뷰 관점 도출 등 이미 개발 방식은 상당히 변하고 있습니다.

한편, "AI가 있으니까 개발 조직은 작아진다", "엔지니어는 필요 없어진다"와 같은 단순한 이야기로 보이지는 않습니다. 구현이 빨라질수록 무엇을 만들어야 할지, 어떻게 검증할지, 누가 책임을 질 것인지를 생각하는 일이 늘어나고 있는 것처럼 보입니다.

자신의 커리어를 생각하는 데 있어서도, 바람직한 개발 조직을 생각하는 데 있어서도, AI 에이전트가 개발 조직을 어떻게 변화시키는지가 상당히 중요하다고 생각했기에, 공개된 조사나 사례를 바탕으로 정리했습니다.

조사와 각 기업의 사례를 나열해 보면 보이는 방향성은 상당히 일관적입니다.

AI는 개발 조직을 대체하기보다, 기존의 강점과 약점을 증폭시킨다.

DORA 2025도 AI의 주요 역할을 "amplifier(증폭기)"라고 표현하고 있습니다. 즉, 테스트, 리뷰, 요구사항 관리, 설계 판단, 조직 지식 관리가 잘 갖춰진 팀에서는 효과가 나타나기 쉽고, 반대로 그 부분이 약한 팀에서는 혼란도 커집니다.

이 기사에서 정리할 포인트는 다음 세 가지입니다.

• 개발의 중심이 "구현"에서 "의도·검증·통솔"로 이동한다
• 애자일 (Agile), 테스트, 자동화된 품질 게이트 (Quality Gate)의 중요성은 낮아지지 않는다
• 개인의 커리어에서는 코드를 쓰는 능력에 더해, 맡기는 방법과 확인하는 방법을 설계하는 능력이 중요해진다

DORA 2025는 2025년판의 테마를 AI-assisted Software Development로 다루고 있습니다. 해당 보고서는 AI가 조직의 강점과 약점을 증폭시킨다는 점, AI 투자의 리턴은 툴 단독이 아니라 조직 시스템에 대한 투자로부터 발생한다는 점을 강조하고 있습니다.

기존 메모에서 참조한 DORA 2025의 요점은 다음과 같습니다.

• AI 툴 채택률은 개발자의 약 90%
• 80% 이상이 생산성 향상을 실감
• 반면, 약 30%는 생성된 코드를 거의 또는 전혀 신뢰하지 않음

여기서 읽어낼 수 있는 것은 "사용되고 있다"와 "신뢰받고 있다"는 별개라는 점입니다. AI 코딩은 보급되었지만, 생성물을 어떻게 검증할지는 아직 성숙해가는 과정에 있습니다.

이 격차는 개발 조직에게 상당히 중요합니다. 2025년 시점에서는 AI가 코드를 쓰는 양을 늘릴수록 리뷰, 테스트, 보안 확인, 운영 관점의 확인이 병목 현상을 일으키기 쉽습니다. 2026년 현재는 또 상황이 조금 변해 있겠지만 말입니다.

AI 에이전트는 일정 수준의 구현 작업을 빠르게 합니다. 결과적으로 "코드를 쓰는 것" 자체의 희소성은 낮아져 갑니다.

하지만 이것이 엔지니어의 가치가 떨어진다는 의미는 아닙니다. 가치의 중심이 구현 그 자체에서 구현의 전후 단계로 이동한다는 이야기입니다.

중요해지는 것은 예를 들어 다음과 같은 업무입니다.

• 무엇을 만들어야 할지를 정의한다
• 요구사항, 제약 조건, 비기능 요구사항을 명문화한다
• AI에게 맡길 태스크의 입도(Granularity)를 나눈다
• 출력이 올바른지 검증한다
• 설계 판단과 추적성 (Traceability)을 남긴다
• 여러 명의 인간과 에이전트의 작업을 통솔한다

생성형 AI에 의해 많은 소프트웨어 엔지니어가 역할 적응을 요구받는다는 내용이 여러 문헌에 기재되어 있습니다. 방향성으로는 구현 중심에서 문제 해결, 설계, 오케스트레이션 (Orchestration)으로 나아가는 견해입니다.

이 변화는 개발자뿐만 아니라 프로덕트 오너 (Product Owner), 아키텍트 (Architect), 테스터 (Tester), 스크럼 마스터 (Scrum Master)에게도 영향을 미칩니다.

AI가 개발을 빠르게 한다면 애자일이나 테스트의 규율은 불필요해지는 것일까요? 조사나 전문가의 견해를 보면 오히려 반대입니다.

Thoughtworks Technology Radar Vol.33은 AI의 성공을 위해서는 문맥, 인프라, 보안을 진지하게 고려할 필요가 있으며, AI 관련 안티 패턴 (Anti-pattern)으로 shadow IT나 생성된 코드에 대한 과신을 꼽고 있습니다.

Kent Beck 씨와의 인터뷰에서도 TDD (Test-Driven Development)는 AI와 함께 일할 때 중요하다고 언급되었습니다. AI는 그럴싸한 코드를 빠르게 내놓을 수 있지만, 올바름을 보장하지는 않습니다.

따라서 AI를 사용할수록 다음과 같은 토대가 중요해집니다.

• 자동 테스트
• CI를 통한 품질 게이트
• 코드 리뷰
• 요구사항과 구현, 테스트의 대응 관계
• 실패했을 때 되돌릴 수 있는 버전 관리

AI가 실수하는 것 자체는 피할 수 없습니다. 문제는 실수를 빠르게 탐지할 수 있는 메커니즘이 있느냐 하는 것입니다.

Anthropic의 multi-agent research system(멀티 에이전트 연구 시스템) 기사에서는, 여러 에이전트로 구성된 구조가 단일 에이전트보다 더 나은 성과를 냈다고 보고하고 있습니다. 사내 평가에 따르면, Claude Opus 4를 리드 에이전트(Lead Agent)로, Claude Sonnet 4를 서브 에이전트(Sub Agent)로 설정한 구성이 단일 에이전트보다 90.2% 더 높은 성능을 보였다고 합니다.

하지만 동일한 기사에서는 제약 사항도 명확하게 기술하고 있습니다.

• 일반적인 채팅에 비해, 에이전트는 약 4배, 멀티 에이전트는 약 15배의 토큰(Token)을 사용함
• 병렬화하기 쉬운 조사 태스크(Task)에는 적합함
• 많은 코딩 태스크와 같이 의존성이 강한 작업에는 현시점에서 적합하기 어려움

즉, 멀티 에이전트가 만능 개발 체제는 아닙니다. 가치가 높고, 병렬화가 가능하며, 평가하기 쉬운 태스크에서 효과가 나타나기 쉽다고 보는 것이 현실적입니다.

자동차, 항공, 의료와 같은 영역에서는 요구사항(Requirement)부터 설계, 코드, 테스트에 이르기까지의 추적성(Traceability)이 중요해집니다. AI는 요구사항 추출, 테스트 생성, 트레이스(Trace) 작성을 지원할 수 있지만, 인증이나 책임(Accountability) 그 자체는 조직에서 사라지지 않습니다.

CoLab의 AI for MBSE 기사에서도 MBSE(모델 기반 시스템 엔지니어링) 및 설계 검증에 AI 에이전트를 사용하는 방향성이 소개되고 있습니다.

이러한 관점에서 MBSE, Digital Thread, ALM/ELM과 같은 기반은 단순한 관리 도구가 아니게 됩니다. 인간과 AI 에이전트가 공유하는 '조직의 기억'으로서 중요성이 높아질 가능성이 있습니다.

조사 결과를 바탕으로 볼 때, AI 에이전트 도입 시 먼저 살펴봐야 할 것은 도구 선정보다 토대입니다.

설계 지침, 용어집, 리뷰 관점, 보안 기준, 운영 제약, 과거의 판단 근거가 사람의 머릿속이나 흘러가는 채팅 속에만 있다면, AI는 조직의 문맥(Context)을 이해할 수 없습니다.

리포지토리(Repository) 상의 문서, CLAUDE.md와 같은 에이전트용 문맥, ADR(Architecture Decision Record), 운영 런북(Runbook) 등을 정비하는 것이 AI 활용의 전제 조건이 되어갈 것입니다.

AI의 출력을 모두 사람이 일일이 확인하는 데에는 한계가 있습니다. 테스트, 린트(Lint), 타입 체크(Type Check), 보안 스캔, 의존성 체크 등 기계로 확인할 수 있는 것들은 CI(지속적 통합)로 넘겨야 합니다.

이는 인간의 리뷰를 없애는 것이 아니라, 인간이 보아야 할 판단에 집중할 수 있는 상태를 만드는 것을 의미합니다.

AI에 적합한 것은 요구사항이 명확하고 결과물을 검증하기 쉬운 태스크입니다. 마이그레이션 작업, 취약점 수정, 테스트 생성, 정형화된 구현, 문서 업데이트 등은 시작하기 쉬운 영역입니다.

반대로, 핵심 비즈니스 로직이나 여러 부서를 가로지르는 판단이 필요한 변경 사항은 여전히 인간의 동기적인 감독이 필요합니다.

개인적인 차원에서 코드를 쓰는 능력이 불필요해지는 것은 아닙니다. AI의 출력을 판단하려면 구현 내용을 이해하고 있어야 합니다.

다만, 그와 더불어 중요해지는 기술은 변할 것입니다.

• 의도를 언어화하는 능력
• 검증 방법을 설계하는 능력
• 시스템 전체를 읽고 트레이드오프(Trade-off)를 판단하는 능력
• AI에게 맡길 입도(Granularity)를 나누는 능력
• 팀의 개발 플로우에 AI를 통합하는 능력

특히 중요한 것은 "AI에게 무엇을 부탁할 것인가"보다 "어떤 결과가 돌아왔을 때 수용해도 좋은가"를 정의하는 능력이라고 생각합니다.

AI 에이전트가 당연해지면, 개발 조직은 "인간이 전부 구현하는 조직"에서 "인간이 의도, 제약, 검증, 책임을 지고 AI 에이전트를 사용하여 구현을 진행하는 조직"으로 옮겨갈 것입니다.

조사 결과로 볼 때, AI는 개발 조직을 단순히 대체하는 것이 아닙니다. 기존의 개발 규율, 테스트, 리뷰, 요구사항 관리, 조직 지식을 증폭시키는 것입니다.

그렇기에 개인으로서는 맡기는 법과 확인하는 법을 연마하는 것, 조직으로서는 AI에게 맡겨도 무너지지 않는 토대를 만드는 것이 중요해질 것으로 보입니다.

• DORA 2025 State of AI-assisted Software Development
• Thoughtworks Technology Radar Vol.33
• Gartner: Generative AI Will Require 90% of Engineers in Software Engineering Teams to Adapt Roles by 2028
• Kent Beck: TDD, AI agents and coding
• Anthropic Engineering: How we built our multi-agent research system
• Scrum.org: AI Augmented Scrum Framework
• CoLab: AI for MBSE