AI 기반 개발의 현재와 향후 전망

지금 어디까지 왔고, 내 프로젝트에 쓸 만한가, 쓴다면 무엇이 어떻게 달라지며, 어떤 솔루션을 골라야 하나 — 발주기관·개발사·PMO의 질문에 데이터와 사례로 답한다.

2025년 6월, 일본 라쿠텐(Rakuten)의 한 머신러닝 엔지니어가 AI 코딩 도구에 작업 하나를 맡겼다. vLLM이라는 오픈소스 라이브러리 안에 특정 활성화 벡터 추출 기능을 구현하라는 것. 이 라이브러리는 여러 언어로 작성된 1,250만 줄짜리 거대 코드베이스였다. 도구는 사람의 개입을 거의 받지 않고 7시간 동안 단 한 번의 실행으로 작업을 끝냈다. 결과는 기준 구현 대비 99.9% 수치 정확도였다.

이 일화는 상반된 두 반응을 부른다. 하나는 "이제 개발자가 필요 없어진다"는 과장된 기대이고, 다른 하나는 "마케팅용 사례에 불과하다"는 냉소다. 둘 다 정확하지 않다. 진실은 그 사이에 있으며, 그 정확한 좌표를 파악하는 것이 지금 프로젝트를 책임지는 사람에게 가장 중요하다.

이 글은 세 가지를 약속한다. 첫째, AI 개발이 실제로 어느 수준에 도달했는지를 검증 가능한 사례와 데이터로 보인다. 둘째, 그것을 내 프로젝트에 적용하면 기존과 무엇이 어떻게 달라지는지를 구체적으로 그린다. 셋째, 발주기관·개발사·PMO 각자의 자리에서 어떤 솔루션을 어떻게 골라야 하는지에 답한다. 결론을 미리 말하면, 승부를 가르는 것은 도구가 아니라 도구를 둘러싼 운영 체계다.

PART 1지금 AI 개발은 정확히 어느 수준인가

막연한 "AI가 코딩한다"는 말은 쓸모가 없다. 현장에서 의미 있는 질문은 "얼마나 자율적으로, 무엇을, 얼마나 믿고 맡길 수 있는가"이다. 이것을 자율성의 스펙트럼으로 펼쳐보면 현재 위치가 또렷해진다.

왼쪽 끝의 ① 자동완성은 우리가 2~3년간 익숙해진 모습이다. 한 줄, 길어야 한 블록을 제안하고 사람이 즉시 수용하거나 기각한다. ② 대화형 보조는 ChatGPT나 Cursor처럼 대화로 함수와 파일을 만들어내되, 사람이 그 결과를 검토하고 고친다. 여기까지는 이미 대부분의 조직이 경험했다.

지금 실제 주류로 올라선 것은 ③ 감독형 에이전트다. 이 단계의 도구는 "로그인 기능을 추가하라" 같은 과업을 받으면 스스로 계획을 세우고, 코드를 쓰고, 테스트를 돌리고, 실패하면 고치는 일을 루프(loop)로 반복한다. 사람은 매 줄을 보는 대신 정해진 관문(게이트)에서 승인한다. Claude Code, AWS Kiro, OpenAI Codex, Cursor Agent가 모두 이 자리에 있다. 라쿠텐의 7시간 사례가 바로 이 단계의 능력을 극적으로 보여준 것이다.

오른쪽 끝의 ④ 자율 에이전트팀은 여러 에이전트가 팀처럼 협업해 수 시간씩 무인으로 일하는 단계다. Devin이나 Claude의 Agent Teams가 여기를 겨냥한다. 다만 이 단계는 아직 '도달'이 아니라 '실증 진행 중'이다. 이 구분이 결정적으로 중요하다.

현실 점검 — 사례의 이면에 있는 냉정한 수치

라쿠텐 사례만 보면 모든 작업을 위임해도 되리라 판단하기 쉽다. 그러나 같은 도구를 만든 Anthropic이 자체 사용 데이터를 분석해 내놓은 결론은 정반대 방향을 가리킨다.

이 비대칭을 이해하는 것이 핵심이다. AI 에이전트는 경계가 명확하고 검증이 자동화된 작업에서는 탁월한 속도를 낸다. 라쿠텐 사례에서 "99.9% 수치 정확도"라는 표현에 주목할 필요가 있다. 정답을 수치로 자동 대조할 수 있었기 때문에 7시간 무인 작업이 신뢰를 얻은 것이다. 반대로 정답이 모호하거나, 요구사항이 말로만 떠다니거나, 검증 기준이 없는 작업에서는 같은 에이전트가 '그럴듯하지만 부정확한' 결과를 높은 확신과 함께 산출한다.

그래서, 생산성은 정말 오르는가

여기서 가장 위험한 함정이 등장한다. 바로 '느낀 생산성'과 '실제 생산성'의 괴리다. 2025년 7월 METR이라는 연구 기관이 통제된 실험(RCT)을 했다. 평균 5년 이상 경력의 숙련 오픈소스 개발자 16명에게 실제 저장소에서 246개 작업을 시켰다.

이것은 AI가 쓸모없다는 뜻이 아니다. 이 실험은 '이미 코드베이스를 깊이 숙지한 시니어가, 익숙한 작업을' 수행하는 특수한 조건이었다. 그런 경우에는 AI에게 설명하고 결과를 검토하는 부가 비용이 직접 작성하는 것보다 클 수 있다. 핵심 교훈은 다른 데 있다 — "빨라진 느낌"을 근거로 도입 효과를 판단하면 반드시 오류에 이른다. 효과는 객관적으로 측정해야 한다.

실제로 대규모 텔레메트리는 더 미묘한 그림을 보여준다. 22,000명의 개발자 데이터를 분석한 2026년 보고서에서, AI 도입 후 기능 완료는 66% 늘었지만 동시에 코드 리뷰에 걸리는 시간이 4.4배로 폭증했고, 심각도 높은 장애도 31% 더 많아졌다. 코드를 '생산'하는 속도는 올랐지만, 그것을 '검증'하는 병목이 더 커진 것이다. 이 현상은 PART 3에서 PMO의 핵심 과제로 다시 다룬다.

그럼에도, 시장은 이미 임계점을 넘었다

개인 차원의 측정이 복잡하다고 해서 거시적 흐름까지 불확실한 것은 아니다. 시장 전체의 채택은 되돌릴 수 없는 단계에 들어섰다.

Gartner는 2028년까지 기업 소프트웨어 엔지니어의 90%가 AI 코딩 도구를 쓸 것으로 본다(2024년 초엔 14% 미만이었다). 전문 개발자 대상 조사에서 이미 71%가 매일 AI 코딩 에이전트를 사용한다고 답했다. 소프트웨어 엔지니어 한 명이 절감하는 시간은 주당 평균 9.4시간으로 추정된다. 더 상징적인 변화는, 2026년 5월 Gartner가 자사 Magic Quadrant의 카테고리 이름 자체를 'AI 코드 어시스턴트'에서 'Enterprise AI 코딩 에이전트'로 바꿨다는 점이다. '거드는 도구'에서 '일하는 에이전트'로 시장의 무게중심이 공식적으로 옮겨간 것이다.

PART 2내 프로젝트에 쓰면, 무엇이 어떻게 달라지나

도입을 결정했다고 하자. 그러면 프로젝트는 구체적으로 어디가 바뀌는가. 추상적인 "더 빨라진다"가 아니라, 단계별로 무엇이 이동하는지를 봐야 실제 계획을 세울 수 있다. 같은 '로그인 기능 추가'라는 과업을 두 방식으로 나란히 놓아보자.

변화 1 — 일의 순서가 바뀐다: '코드 먼저'에서 '명세 먼저'로

기존 방식에서 요구사항 문서와 설계서는 사람이 읽을 것을 전제로 쓰였다. 그래서 어느 정도 모호해도 괜찮았다. 개발자가 맥락으로 빈틈을 메웠으니까. 그런데 AI 에이전트에게는 이 모호함이 치명적이다. 에이전트는 빈틈을 '통계적으로 그럴듯한 추측'으로 메우기 때문이다. "로그인 추가"라고만 하면, 에이전트는 자기 나름의 합리적 기본값을 고르는데 그게 우리가 원한 것과 다를 확률이 높다.

그래서 등장한 것이 명세 주도 개발(Spec-Driven Development, SDD)이다. 핵심은 단순하다 — 코드를 짜기 전에, 무엇을 왜 만드는지를 기계도 읽을 수 있는 구조화된 명세로 먼저 고정한다. 그리고 그 명세를 코드 위에 두어 '단일 진실 공급원(source of truth)'으로 삼는다.

변화 2 — 명세가 '문서'가 아니라 '검증 게이트'가 된다

이것이 가장 본질적인 변화다. 전통적 명세는 작성 후 사실상 방치되는 정태적 문서였다. SDD에서 명세는 지속적으로 작동하는 검증 장치다. 2026년 초 학계(arXiv 2602.00180)와 Thoughtworks가 정리한 표현을 빌리면, "전통적 명세는 사람이 읽지만, SDD 명세는 검증 게이트로 실행된다."

무슨 뜻인가. 에이전트가 코드를 생성할 때, 단위 테스트는 개별 함수가 작동하는지만 본다. 그러나 AI가 생성한 코드의 진짜 위험은 함수 단위가 아니라 시스템 단위에서 발생한다 — 아키텍처 원칙 위반, API 계약의 미묘한 어긋남, 서비스 경계를 넘나드는 보안 안티패턴이 그것이다. 명세를 검증 게이트로 두면 이런 결함을 코드가 생성되는 시점에 차단한다. 통합 테스트 단계까지 결함이 누적된 뒤 한꺼번에 드러나는 기존 방식과는 근본적으로 다르다.

이 차이가 왜 중요한지는 보안 데이터가 말해준다. 여러 벤치마크에서 LLM이 생성한 코드는 9.8%에서 42.1%의 비율로 취약점을 포함했다. 2026년 2월까지 운영 저장소에 살아남은 'AI가 유입시킨 이슈'가 11만 건을 넘었다. 단위 테스트만으로는 이걸 못 잡는다. 명세 기반 검증 게이트가 필요한 이유다.

변화 3 — 사람의 일이 '1:1 작성'에서 '1:N 감독'으로

기존엔 개발자 한 명이 자기 코드를 직접 썼다. 에이전트 방식에서는 한 사람이 여러 에이전트를 동시에 감독한다. 라쿠텐의 매니저는 이렇게 표현했다 — "네 개를 Claude Code에 위임하고 나머지 하나에 집중하면, 다섯 개 작업을 병렬로 돌릴 수 있다."

이것은 단순한 속도 향상이 아니라 역할의 질적 변화다. 개발자는 '타이핑하는 사람'에서 '의도를 정의하고 결과를 검증하는 사람'으로 옮겨간다. Forrester는 2026년 이 전환을 '바이브 코딩(vibe coding)'에서 '바이브 엔지니어링(vibe engineering)'으로의 이동이라 명명했다. 즉흥적으로 프롬프트를 던지던 단계에서, 전체 생애주기를 책임지는 공학적 규율로 성숙한다는 뜻이다.

PART 3어떤 솔루션을, 누가, 어떻게 고를 것인가

이제 가장 실무적인 질문이다. 도구는 수십 개고 매달 새것이 나온다. 무엇을 기준으로 골라야 하나. 답의 출발점은 "우리 환경의 제약이 무엇인가"이다. 특히 한국의 공공·금융처럼 망분리와 보안등급이 걸린 환경에서는 이 제약이 모든 것을 결정한다.

분기별 솔루션 지형

폐쇄망·고보안 환경(공공/금융)이라면 외부 API 호출 자체가 불가능한 경우가 많다. 이때는 온프레미스나 VPC에 배포 가능한 모델(Tabnine 계열이 이 지점을 강조한다), 또는 자체 LLM에 오픈소스 하네스(GitHub Spec Kit, OpenSpec)를 얹는 구성이 현실적이다. Gartner Peer Insights에 IBM Bob 같은 엔터프라이즈 옵션이 등장하는 것도 이 수요 때문이다.

일반 기업·클라우드 허용 환경이라면 선택지가 넓다. IDE에 통합된 Cursor나 GitHub Copilot, 감독형 코딩 에이전트인 Claude Code나 OpenAI Codex가 기존 깃·CI 파이프라인과 자연스럽게 붙는다. 2026년 Gartner Magic Quadrant에서 GitHub과 OpenAI가 Leader로, Tabnine이 Visionary로 평가됐다.

대규모·레거시 현대화가 목표라면 멀티 에이전트 오케스트레이션, 명세-우선 IDE(AWS Kiro), 자율 코딩 에이전트(Devin), 그리고 도구 연결을 표준화하는 MCP(Model Context Protocol) 기반 구성을 검토한다. MCP는 2026년 4월 기준 공개 서버만 9,400개를 넘어서며 사실상 표준이 됐다.

그렇다면 성공하는 12%는 무엇이 다른가. 데이터가 놀랍도록 일관된 프로필을 보여준다.

• 94%가 예산 권한과 측정 가능한 목표를 가진 '에이전트 책임자(agent owner)'를 명시했다. 책임자를 둔 조직은 운영 전환율이 2.7배 높았다.
• 87%가 모든 프롬프트·모델·도구 변경 전에 자동 평가(eval)를 돌렸다. 자동 평가가 없는 에이전트의 롤백률은 47%, 있는 경우는 9%였다.
• 81%가 에이전트를 '만능 비서'가 아니라 단일 워크플로에 이진(binary) 성공 기준으로 좁게 한정했다.

여기서 한국 SI에 대한 직접적 함의가 나온다. 도구 선정에 쏟는 노력의 절반을 운영 체계 설계에 배분해야 한다. 어떤 도구를 도입하든, 책임자가 없고 평가 체계가 없으며 범위가 무한하면 88%의 실패 사례에 포함된다. 이것이 솔루션 선택의 실질적 출발점이다.

PART 4세 이해관계자, 세 개의 질문 — 그리고 답

같은 변화도 어느 자리에서 보느냐에 따라 질문이 다르다. 발주기관은 계약과 예산을, 개발사는 역량과 수익을, PMO는 거버넌스와 측정을 걱정한다. 각자가 가장 궁금해할 세 질문 — "쓸 만한가 / 뭐가 달라지나 / 뭘 준비하나" — 에 정면으로 답해보자.

발주기관 대가 산정의 지반이 흔들린다

발주기관의 가장 깊은 고민은 "투입한 사람·시간으로 가치를 매기던 방식이 무너진다"는 데 있다. 한국 공공 SI의 대가는 기능점수(FP)와 인월(MM)이라는 두 기둥 위에 서 있다. 2024년 개정 가이드에서 FP 단가는 한 점당 60만 5,784원으로 9.5% 인상됐고, AI 도입사업 대가 항목도 신설됐다.

문제는 이 체계가 '투입'을 전제한다는 점이다. 라쿠텐 사례처럼 에이전트가 "3개월짜리를 며칠로, 24일 걸리던 기능 출시를 5일로(79% 단축)" 만들기 시작하면, 투입 인월과 산출 가치 사이의 연결이 끊어진다. 가장 일을 잘하는(=AI를 잘 쓰는) 개발사가 인월 기준으로는 가장 적게 청구하게 되는 역설이 생긴다. 2026년 4월 디지털 정책포럼에서도 "데이터 정제·모델 평가·신뢰성 같은 수면 아래 기술이 성패를 가르는데 현행 대가 체계가 이를 반영하지 못한다"는 지적이 공식화됐고, 정부 차원의 새 대가체계 검토가 화두로 올랐다.

발주기관이 준비할 것

1. RFP와 산출물 정의에 명세 문서를 1차 산출물로 명문화한다. 요구사항 정의서를 위 '실행 가능한 명세 6요소' 구조로 재설계하면, AI 활용 여부와 무관하게 사업의 품질이 올라간다. 이것은 지금 당장 시작할 수 있는 가장 안전한 한 걸음이다.
2. 검수 기준을 '코드 라인·문서 존재'에서 '명세 충족도'로 옮긴다. 감리 항목에 명세–구현 추적성(traceability)을 추가한다.
3. 일부 사업부터 '기본 인월 + 성과 보너스' 하이브리드 대가를 시범한다. 납기 단축, 결함 밀도, 변경 실패율 같은 성과 지표를 보너스에 연동한다. 인월을 한꺼번에 버릴 필요는 없다. 그러나 균열을 외면하면 안 된다.
4. AI 생성 코드의 보안·책임 조항을 계약서에 명시한다. 앞서 언급한 '11만 건의 잔존 AI 이슈'는 결코 가벼이 넘길 문제가 아니다. 누가 어떤 검증을 거쳐 책임을 지는지를 계약 단계에서 규정해야 한다.

개발사 (SI) 무게중심을 '손'에서 '머리'로

개발사에게 이 변화는 위협이자 기회다. 위협은 분명하다. 코드를 빠르게 쳐내는 능력 자체의 시장 가치가 떨어진다. 특히 주니어가 맡던 단순·반복 구현 일감이 가장 먼저 줄어든다. Forrester는 2026년 신규 개발자 채용에 기존의 두 배 시간이 걸리고, CS 전공 지원자가 20% 줄 것으로 전망했다 — 입문 단계 일자리가 자동화되면서 생기는 구조적 충격이다.

그러나 기회가 더 크다. 무게중심이 '손(코딩)'에서 '머리(명세·설계·검증)'로 옮겨가면서, 도메인을 깊이 이해하고 의도를 정확히 명세하는 능력이 핵심 경쟁력이 된다. 이것은 한국 SI가 수십 년간 금융·공공·제조 도메인에서 축적한 지식이 오히려 핵심 자산으로 부각되는 국면이다. Addy Osmani(Google)의 진단이 이를 압축한다.

"AI 코딩 품질은 모델 단계에서 실패하기 전에, 명세 단계에서 먼저 실패한다." — Addy Osmani, Google (GitHub의 2,500여 개 에이전트 설정 파일 분석 기반)

즉 AI 도입 실패의 진짜 원인은 도구가 아니라 명세 역량이다. 명세를 잘 쓰는 조직이 이긴다. 실제 국내 빅3(삼성SDS·LG CNS·SK AX)는 이미 이 방향으로 조직을 재편했다. 삼성SDS는 RFP 분석·스펙인/스펙아웃 판단·제안서 초안·설계요청서 같은 문서 기반 반복 업무를 개별 에이전트로 분리해 자동화하고 있고, 전사 인사에서 '설계하는 축'의 컨설팅 리더를 전면 배치했다.

개발사가 준비할 것

1. 명세·검증 역량을 조직 차원에서 내재화한다. 개인기에 맡기지 말고, 좋은 명세의 템플릿·체크리스트·리뷰 프로세스를 표준 자산으로 만든다.
2. 도메인 지식을 재사용 가능한 '스킬·명세 자산'으로 패키징한다. 보험 청구 심사, 전력 계통 정산 같은 도메인 노하우를 에이전트가 참조할 수 있는 형태로 자산화하면, 이것이 경쟁사가 복제하기 어려운 해자가 된다.
3. 역할 트랙을 재편한다. 'AI 오케스트레이터'(에이전트 조율·명세 작성·검증), 'AI 아키텍트'(멀티 에이전트 시스템 설계), '거버넌스 리드'(평가·책임 체계). 주니어에게는 단순 코딩 대신 명세 작성과 검증을 처음부터 가르친다.
4. '에이전트 운영(Agent Operations)' 사업 비중을 매년 늘린다. 일회성 구축에서, AI 에이전트를 지속 운영·개선하는 서비스로 수익 모델을 확장한다.

PMO '느낀 생산성'을 버리고 텔레메트리로 측정하라

PMO에게 가장 위험한 함정은 PART 1에서 본 측정의 착시다. METR 실험이 보였듯, 사람은 자신의 생산성 변화를 정확히 인지하지 못한다. "팀이 빨라진 것 같다"는 체감은 의사결정 근거가 될 수 없다. 더구나 '기능 완료 66%↑, 리뷰 시간 4.4배↑'처럼 한쪽 지표만 보면 정반대 결론에 이를 수 있다.

비유하자면, 주방에 조리 인력을 열 명 더 투입했으나 완성된 요리를 검수해 내보내는 인원은 그대로인 상황과 같다. 주방의 활동량은 늘었지만 손님에게 음식이 도달하는 속도는 오히려 느려진다. PMO의 역할은 투입 인력의 규모를 내세우는 것이 아니라 '실제로 고객에게 전달된 결과물'을 측정하는 것이다. 병목이 '생산'에서 '검증'으로 이동했다는 사실을 인식하는 것이 그 출발점이다.

PMO가 준비할 것

1. 검수 게이트를 '명세 일치 + 속성 기반 테스트 통과'로 재정의한다. 단계 전환 승인은 결재 도장이 아니라, 명세와 구현이 일치하는지를 자동으로 검증한 결과여야 한다.
2. 측정 지표를 이원화한다. 기존 DORA 4대 지표(배포 빈도·변경 리드타임·변경 실패율·복구 시간)에 더해, AI 전용 지표(자동 생성 코드 비율, 명세–구현 일치율, PR 리뷰 시간)를 병행한다. 그래야 '개인 효율'과 '조직 처리량·안정성'의 디커플링을 잡아낸다.
3. 자동 평가(eval)와 롤백 체계를 1순위로 구축한다. 앞서 본 '롤백률 47%→9%'는 평가 체계 하나가 가른 차이다. 이것은 선택이 아니라 생존의 전제다.
4. PMO 자신의 무게중심을 끌어올린다. 진척·일정 추적 같은 단순 작업은 점차 도구가 흡수한다. PMO는 리스크·의도·예산·판단이라는 더 높은 층위로 올라가야 존재 이유가 강해진다.

PART 5우리는 지금 몇 단계이고, 어디로 가야 하나

전략을 세우기 전에 현 위치를 알아야 한다. 아래는 조직(또는 개별 사업)의 AI 개발 성숙도를 다섯 단계로 나눈 척도다.

냉정히 보면, 대부분의 한국 SI 조직과 공공 사업은 지금 L1(개인 활용)과 L2(팀 표준) 사이에 있다. 개발자 각자는 Copilot이나 Cursor를 쓰지만, 조직 차원의 명세 표준도, 검수 재정의도, 대가 체계 손질도 아직이다. 도구는 L3를 향하는데 방법론·계약·거버넌스는 과거에 머물러 있는 불일치 상태다.

현실적 목표는 18~36개월 안에 L3(명세 주도)에 안착하는 것이다. L4(조직 내재화)나 완전 자율은 — 자율주행에 비유하면 아직 '완전 무인'이 아니라 '운전자 감독하의 자율주행' 단계임을 기억해야 한다. Forrester도 에이전틱 소프트웨어 개발(ASD)을 '중기(몇 년) 기술'로 분류하며, 에이전트 협응과 가드레일이 더 성숙해야 본격적 효익이 나온다고 봤다.

향후 3년의 현실적 시나리오

• 단기(~1년) — 채택은 이미 되돌릴 수 없는 단계에 이르렀다. 경쟁의 초점은 '도입 여부'가 아니라 '운영 체계의 성숙도'로 옮겨간다. 책임자·평가·범위라는 세 요소를 갖춘 조직이 88%의 실패 사례에서 벗어난다. 명세를 표준 산출물로 편입한 발주가 앞서 나간다.
• 중기(1~2년) — RFP와 대가 체계 재설계가 본격화된다. '기능·성과 기반 청구'가 일부 사업에서 표준이 되고, 명세 역량이 개발사 선정의 평가 항목으로 들어온다. 멀티 에이전트 운영 비율(현재 22%)이 절반에 근접한다.
• 장기(2~3년) — PMO의 무게중심이 '추적·관리'에서 '거버넌스·판단'으로 완전히 이동한다. 다만 과속은 위험하다. Gartner는 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 것으로 경고했다. 속도와 통제의 균형이 승부를 가른다.

마지막으로, 가장 본질적인 역설을 짚는다. AI는 코드를 쓰는 일을 거의 공짜로 만들었다. 그래서 역설적으로, '무엇을 왜 만드는가'를 정확히 정의하고 검증하는 일의 가치가 그 어느 때보다 높아졌다. 발주기관에게는 그것이 더 나은 계약과 검수로, 개발사에게는 더 깊은 도메인 명세 역량으로, PMO에게는 더 본질적인 거버넌스로 나타난다.

라쿠텐의 7시간은 기술의 승리이기 이전에, '무엇을 검증할지'가 명확했기에 가능했던 명세의 승리였다. 도구는 계속 좋아질 것이다. 그러나 좋은 도구를 가진 모두가 이기는 것은 아니다. 이기는 쪽은, 그 도구를 책임 있게 정의하고 측정하며 운영하는 체계를 먼저 갖춘 쪽이다. 그 체계를 지금 만들기 시작하는 것 — 그것이 이 글이 전하려는 단 하나의 실천 과제다.