[기고] AI SDLC, ‘모두 다 된다’는 약속을 경계하라
— 지금 필요한 것은 장밋빛 청사진이 아니라 검증된 로드맵이다
베스핀글로벌 AI & Data Tech Center
지난 2~3년 사이 소프트웨어 개발 현장에서 가장 극적인 변화를 만든 것은 단연 AI 코딩 어시스턴트다. 코드 자동완성에서 출발한 이 기술은 이제 자연어 요청만으로 기능 단위 코드를 생성하고, 리팩토링과 결함 탐지까지 수행하는 수준에 도달했다. 개발자 개인의 생산성 향상이 수치로 입증되기 시작하자, 기업들의 시선은 자연스럽게 다음 질문으로 옮겨가고 있다. “코딩이 된다면, 개발 생명주기 전체는 왜 안 되는가?”
이것이 지금 시장의 화두인 AI SDLC(AI-driven Software Development Life Cycle)다. 요구사항 정의(BA)부터 설계, 코드 생성(Coder), 테스트(QA), 운영(SRE)에 이르는 소프트웨어 개발 전 주기에 AI를 적용해 리드타임을 단축하고 품질을 높이겠다는 구상이다. 방향 자체는 옳다. 소프트웨어 개발에서 코딩이 차지하는 비중은 통상 전체 공수의 3분의 1을 넘지 않는다. 요건 협의, 문서 작업, 테스트, 검수에 들어가는 시간이 훨씬 크다. AI의 효익이 코딩에만 머문다면 그것이야말로 절반의 혁신이다.
문제는 방향이 아니라 속도와 방법이다.
AI SDLC가 화두가 되면서, 시장에는 우려스러운 흐름이 함께 나타나고 있다. 적지 않은 서비스 기업들이 “요건만 입력하면 AI가 분석부터 개발, 테스트까지 알아서 해낸다”는 식의 완전 자동화 청사진을 제시하고 있다는 점이다. 데모 환경의 인상적인 시연이 곧 엔터프라이즈 운영 환경에서의 성능을 보장하는 것처럼 포장되고, 단계별로 전혀 다른 기술 성숙도가 하나의 패키지로 뭉뚱그려진다.
현장에서 다수의 엔터프라이즈 AI 구축을 수행해 온 당사의 판단은 명확하다. SDLC의 각 단계는 AI 적용 성숙도가 크게 다르며, 이를 구분하지 않는 제안은 발주사와 수행사 모두를 실패로 이끈다.
코드 생성(AI Coder)은 상대적으로 성숙한 영역이다. 글로벌 상용 LLM 기준으로 검증 사례가 풍부하고, 측정 지표(코드 채택률, 결함 검출률 등)도 정립되어 있다. 다만 여기에도 조건이 있다. 검증된 사례의 대부분은 표준화된 프레임워크 기반의 신규 개발(greenfield)에 집중되어 있다. 수십 년 축적된 레거시 코드의 수정·추가(brownfield)는 요구되는 컨텍스트의 양과 복잡도가 전혀 다른 문제로, 사내 프레임워크·도메인 로직에 대한 정교한 RAG 구성 없이는 기대 수준에 도달하기 어렵다.
테스트 자동화(AI QA)는 부분적으로 성숙한 영역이다. 요구사항 기반 테스트 케이스 생성과 합성 데이터 생성은 실용 단계에 진입했지만, 테스트 실행·증적 자동화는 대상 시스템의 환경 제약(단말, 전문, 망분리)에 크게 종속되어 일반화가 어렵다.
요구사항 정의(AI BA)는 아직 개척지다. 이 지점을 특히 강조하고 싶다. 엔터프라이즈 애플리케이션, 그중에서도 금융과 같은 규제 산업의 요건 수집·명세화는 현업의 암묵지, 부서 간 이해관계, 규제 요건이 뒤얽힌 고맥락(high-context) 작업이다. 최고 성능의 상용 LLM을 기준으로 하더라도, 이 영역을 완전 자동화한 검증 레퍼런스는 글로벌 시장에서도 찾기 어렵다. “AI가 현업과 대화하며 요건정의서를 완성한다”는 문장은 데모에서는 성립하지만, 수백 개 시스템이 얽힌 실제 기업 환경에서 그대로 성립한다고 약속하는 것은 정직하지 않다.
여기에 한 가지 변수가 더 있다. 국내 기업, 특히 금융권의 상당수는 망분리 규제로 인해 내부망 소형 언어모델(sLLM)을 우선 활용해야 하는 환경에 있다. 상용 LLM으로도 미검증인 과제를 sLLM으로 달성하겠다는 계획이라면, 그 격차는 더욱 커진다. 모델 전제를 명시하지 않은 성능 약속은 약속이 아니라 희망사항이다.
이렇게 말하면 “그러면 성숙할 때까지 기다리자”는 결론으로 흐르기 쉽다. 그러나 그것 역시 틀린 답이다. 두 가지 이유에서다.
첫째, AI SDLC의 성패를 가르는 것은 모델이 아니라 데이터와 프로세스 자산이며, 이것은 하루아침에 만들어지지 않는다. 과거 요구사항(SR) 이력, 표준 명세 템플릿, 코드베이스, 테스트 자산이 검색 가능한 형태로 정비되어 있어야 AI가 조직의 맥락을 학습할 수 있다. 모델 성능은 해마다 좋아지지만, 조직의 데이터 자산은 준비한 만큼만 쌓인다. 모델이 완숙해진 시점에 시작하는 기업과, 그 시점에 이미 2\~3년치 자산과 운영 경험을 갖춘 기업의 격차는 따라잡기 어렵다.
둘째, 단계적으로 접근하면 지금 당장 회수 가능한 효익이 분명히 존재한다. 코드 리뷰 자동화, 테스트 케이스 생성, 사업 문서 초안 작성 같은 영역은 이미 투자 대비 효과가 검증된 구간이다. 성숙 구간에서 효익을 회수하며 미성숙 구간을 검증하는 것 — 이것이 합리적 경로다.
그렇다면 어떻게 시작해야 하는가. 당사가 엔터프라이즈 현장에서 정립한 원칙은 네 가지로 요약된다.
첫째, ‘검증 후 확약(Prove, then Commit)’의 단계 구조를 취하라. 본 사업에 앞서 2~3개월의 기술 검증(PoC)을 선행해, 자사의 데이터·코드베이스·규제 환경에서 각 과제가 실제로 어느 수준까지 동작하는지 확인한 뒤 MVP 범위를 확정하는 방식이다. 이때 PoC는 수행사의 데모 재연이 아니라, 발주사의 실제 SR 이력과 실제 코드베이스를 대상으로 해야 의미가 있다. 그리고 PoC 결과에 따라 범위를 축소하거나 특정 과제를 제외하는 결정이 자연스럽게 수용되는 구조, 즉 ‘No-Go도 유효한 결론’이라는 합의가 사전에 이루어져야 한다.
둘째, 완료 기준을 착수 전에 정량화하라. AI 사업이 분쟁으로 끝나는 가장 흔한 원인은 “실제 운영에 적용 가능한 수준”과 같은 정성적 목표다. 같은 문장을 발주사는 ‘무인 자동화’로, 수행사는 ‘보조 도구’로 읽는다. 명세 초안 채택률, 테스트 케이스 커버리지, 리드타임 절감률과 같은 측정 가능한 KPI, 그리고 그것을 측정할 표본과 방법(예: 블라인드 평가)을 계약 단계에서 문서로 확정해야 한다. 절감률을 말하려면 현행 기준선(As-Is Baseline)부터 함께 측정해야 함은 물론이다.
셋째, Human-in-the-loop를 기본 운영 모델로 설계하라. 특히 규제 산업에서 AI 산출물의 무인 반영은 MVP 단계의 목표가 될 수 없다. 요건 명세든 코드든 테스트든, 담당자의 검토·승인을 거치는 보조(Copilot) 모델로 시작해 신뢰 데이터가 축적된 영역부터 자동화 수준을 높여가는 것이 지속 가능한 경로다. 이는 기술의 한계를 인정하는 후퇴가 아니라, 책임 소재와 감사 추적성을 요구하는 규제 환경에서의 필수 설계다.
넷째, 범위의 경계를 문서로 확정하라. ‘Start Small’은 좋은 전략이지만, ‘Small’의 경계가 모호하면 사업은 조용히 팽창한다. 대상 업무, 요구사항 유형, 시스템 계열, 그리고 신규 개발과 레거시 수정의 포함 여부까지 특정한 범위 정의서를 계약의 일부로 삼고, 그 밖의 요구는 변경관리 절차로만 반영하는 규율이 양사를 모두 보호한다.
마지막으로, AI SDLC 도입을 검토하는 기업이 착수 전에 점검해야 할 사전 준비사항을 정리한다. 이 준비 수준이 곧 사업의 성패를 좌우한다.
우선 데이터 자산의 정비다. 과거 요구사항 이력과 첨부문서, 표준 명세서 양식, 소스코드와 전문(電文) 정의, 테스트 케이스 자산이 접근 가능하고 검색 가능한 상태인지 확인해야 한다. 문서가 개인 PC와 이메일에 흩어져 있거나 DRM으로 잠겨 있다면, 데이터 수집·전처리 체계 구축이 선행 과업이 된다. 이때 개인정보 비식별화와 민감정보 필터링 체계는 선택이 아닌 전제조건이다.
다음은 인프라와 규제 대응이다. 망분리 환경에서 상용 LLM을 활용하려면 규제 샌드박스 지정, 망분리 예외 승인, 전용선과 프라이빗 연결 구성 등 상당한 리드타임이 필요하다. 이 승인 일정이 확보되지 않은 채 사업 일정을 확정하면, 프로젝트는 시작과 동시에 지연된다. 내부 sLLM과 외부 상용 LLM을 용도별로 라우팅하는 LLM 게이트웨이 등 하이브리드 아키텍처의 밑그림도 이 단계에서 그려져야 한다.
셋째는 기준선 측정과 KPI 체계다. 현재 요건 협의에 며칠이 걸리는지, 테스트 케이스 작성에 몇 시간이 드는지를 측정해 본 조직은 의외로 드물다. As-Is 공수와 리드타임의 기준선 없이는 AI 도입 효과를 증명할 방법도, 확산 투자를 정당화할 근거도 만들 수 없다.
마지막은 조직과 거버넌스다. AI BA·QA 과제의 품질은 현업 전문가의 피드백 루프에 직접 의존한다. 도메인 전문가의 참여 시간을 제도적으로 확보하고, 이슈 발생 시 의사결정 기한(SLA)과 산출물 승인 절차를 갖춘 협의체를 사업 개시 전에 구성해야 한다. AI 사업의 거버넌스는 기술 조직만의 일이 아니라 현업과 경영진이 함께 지는 책임이다.
AI SDLC는 분명히 온다. 그러나 그것은 어느 날 완성품으로 도착하는 것이 아니라, 검증과 축적을 거쳐 단계적으로 구현된다. 지금 이 시장에 필요한 것은 “모두 다 된다”는 약속이 아니라, 되는 것과 아직 안 되는 것을 구분하는 정직함, 그리고 안 되는 것을 되게 만들기 위한 준비의 로드맵이다.
고객에게 실패 가능성까지 투명하게 공유하고, 검증을 통해 범위를 확정하며, 정량 지표로 성과를 증명하는 것. 멀리 돌아가는 길처럼 보이지만, AI 전환의 시대에 기업과 파트너가 함께 갈 수 있는 가장 빠른 길이라고 우리는 믿는다.
본 기고는 베스핀글로벌 AI & Data Tech Center의 엔터프라이즈 AI 구축 경험을 바탕으로 작성되었습니다.