생성형 AI로 소프트웨어 제공 라이프사이클 가속화: IBM Enterprise Payment Services의 교훈

3개월 전만 해도 우리 팀의 회귀 테스트 백로그와 실행 시간은 모든 스프린트를 계속 지체시켰습니다. 하지만 지금은 Bob 덕분에 테스트에 소요되는 노력이 70% 이상 줄었습니다. 이러한 결과는 테스트 워크플로에 기본적으로 내장된 IBM의 AI 개발 어시스턴트인 IBM Bob을 테스트 팀의 정식 팀원으로 도입함으로써 달성할 수 있었습니다. 이는 AI 보조 소프트웨어 전달이 더 이상 미래의 개념이 아님을 증명합니다.

소프트웨어 엔지니어링 팀은 여러 방향에서 동시에 증가하는 압박에 직면해 있습니다. 규제 기관들은 규정 준수 요건을 강화하고 있습니다. 보안 감사관들은 취약점 관리 및 해결 일정에 대해 더 높은 투명성을 요구하고 있습니다. 한편, 고객들은 품질이나 안정성에 영향을 주지 않으면서도 시장 출시가 더 빨라지기를 기대하며 기능 요구를 가속화하고 있습니다.

IBM Payments Center Enterprise Payment Services(EPS) 팀은 엄격하게 규제가 적용되는 고가치 결제 플랫폼을 운영하고 있으며, 매일 이러한 압박을 받고 있습니다. 결제 플랫폼은 금융 규제, 운영 복원력 요구 사항, 보안 검토 및 고객 경쟁력 요구 사항을 비롯한 모든 요소가 하나의 코드베이스에 수렴하는 교차점에 위치합니다.

올해 제가 답하고자 했던 질문은 명확합니다: 품질이나 안정성을 타협하지 않으면서 동일한 인원으로 더 많은 일을 더 빠르게 할 수 있는 방법은 무엇일까요?

그 해답은 2026년 초에 EPS 엔지니어링 팀의 정식 팀원으로 온보딩한 생성형 AI, 특히 IBM Bob입니다. 우리 팀은 단 몇 달 만에 상당한 진전을 이루었으며, 이러한 결과는 업계 전반에서 일어나고 있는 광범위한 변화를 반영합니다.

생성형 AI는 더 이상 자동 완성 제안에 국한된 시범적 실험이 아니며, 요구 사항 수집부터 프로덕션 인시던트 대응에 이르기까지 소프트웨어 개발 라이프사이클(SDLC)의 모든 주요 분야에 통합되어 있습니다. 아직 생성형 AI에 투자하지 않은 조직은 실질적인 경쟁 불이익을 경험할 만큼 그 결과는 충분히 설득력이 있습니다.

우리의 경험은 소프트웨어 전달의 전체 흐름과 깔끔하게 연결됩니다. 각 단계를 살펴보겠습니다.

요구 사항: 노이즈를 체계로 전환
 

요구 사항 수집은 항상 가장 모호하고 후속 비용 발생 가능성이 가장 큰 단계였습니다. 부실한 요구 사항은 프로젝트 재작업, 범위 누락 및 결함 발생의 주요 원인입니다. 요구 사항 단계에서 발견된 결함은 실제 생산 단계에서 발견된 결함에 비해 비용이 훨씬 적게 듭니다.

생성형 AI는 이 단계의 경제적 구조를 근본적으로 변화시킵니다. EPS 컨텍스트에서 Bob은 다음을 처리합니다.

• 신속한 사용자 스토리 및 문서 생성—회의 메모와 이해관계자의 대화를 구조화된 Jira 지원 사용자 스토리 및 승인 기준으로 직접 변환합니다.
• 누락된 요구 사항 식별—기존 스토리를 비즈니스 맥락에 비추어 분석하고, 인간 비즈니스 분석가가 스프린트 후반까지 발견하지 못할 수 있는 격차를 표시합니다.
• 비정형 입력 자료 번역—녹취록, 이메일, 비공식 메모 등을 공식 요구 사항 문서로 변환합니다.

비즈니스 분석가를 지원하기 위해 Bob을 사용할 때 요구 사항 단계에서 30~40%의 생산성 향상을 확인했으며, 주로 수동 전사 제거, 형식 변경 및 상호 참조 작업 제거를 통해 이를 확인할 수 있었습니다. 팀이 측정한 이러한 추정치는 Bob이 팀에 도입되기 전 및 후에 추적된 비즈니스 분석가의 노력을 기반으로 합니다.

핵심 원동력은 Bob의 상황 인식입니다. 우리는 플랫폼의 전체 문서 세트, 규제 표준, 코딩 표준 및 비기능적 요구 사항을 Bob에 모두 로드했습니다. 이러한 기반은 생성된 요구 사항이 단순히 문법적으로 올바를 뿐 아니라 결제 플랫폼의 아키텍처 및 규제 현황을 반영하도록 합니다.

엔지니어링 및 개발: 최대의 기회
 

개발은 엔지니어링 시간 중 가장 많은 부분을 할애하는 분야이며, 따라서 생성형 AI가 가장 큰 혁신적 이점을 제공하는 분야입니다. IBM 엔지니어링 단계에서 Bob은 30~50%의 효율성 향상을 제공하는 것으로 예상되었으며, 이는 엔지니어링 작업의 폭과 각 작업에 필요한 컨텍스트의 심도를 반영하는 범위입니다.

본 구현에서는 세 가지 방향에 걸쳐 엔지니어링 가속화를 추구합니다. 각각에서 Bob은 반자율 모드로 작동하여 주제 전문가가 승인 전에 아웃풋을 검토하고 검증하는 동안 작업을 수행합니다. 이 페어링은 제한이 아니라, 지금의 AI 성숙 단계에 맞는 올바른 아키텍처 패턴입니다.

1. Bob 지원 검토: Bob은 EPS 소스 리포지토리에 대한 액세스 권한을 부여받았으며, 인간 SME 검토자와 함께 검토를 수행합니다. 이중 검토 방식을 통해 규제 요건, 보안 및 개인정보 보호 표준, 기능적 및 비기능적 아키텍처 요건을 준수함으로써 테스트나 운영 단계가 아닌 개발 단계에서 결함을 발견할 수 있습니다. Copilot에 관한 GitHub의 연구에 따르면 AI 지원 코드 검토는 풀 요청 주기당 보안 관련 문제를 15~20% 더 많이 포착하고 해결 시간을 단축했는데, 이는 AI가 결과와 함께 수정 가능한 차이를 제안했기 때문입니다.
2. 취약점 관리 및 업그레이드: 언어 및 라이브러리 버전이 발전하고 규제 요구 사항이 변경됨에 따라 Bob은 코드베이스 전체에서 라이브러리 업그레이드의 영향 범위를 평가합니다. 이 시스템은 호환되지 않는 호출 사이트를 식별하고 필요한 수정 사항을 몇 분 만에 권장합니다. 이는 이전에는 선임 엔지니어가 수동으로 종속성을 추적하는 데 며칠이 걸렸던 작업입니다.
3. 코드 생성 및 수정: Bob은 명확한 요구 사항(기능 및 비기능), 코드베이스 컨텍스트 및 관련 규제 제약이 주어지면 기존 코드 수정에 대한 권장 사항을 제공합니다. 데이터 레지던시 규칙, 오류 처리 기준 또는 규제 의무를 인식하지 않고 결제 처리 코드를 생성하는 AI는 자산이 아니라 부채입니다. Bob에 해당 컨텍스트를 미리 로드하면 이 문제가 바로 해결됩니다.

테스트: 병목 현상 제거
 

테스트는 오랫동안 소프트웨어 납품을 지체시키는 주범이었습니다. 개발 팀은 QA 팀의 검증 속도보다 더 빠르게 코드를 생성합니다. 이러한 비대칭성은 스프린트 이월, 릴리스 지연 및 회귀 테스트 백로그 증가의 주요 요인입니다.

우리 QA 팀의 결과는 가장 성숙도 높고 놀랍습니다. EPS Wires 결제 플랫폼을 위한 테스트 자동화 생성기로 Bob을 배포한 지 3개월 후 다음과 같은 성과를 거둘 수 있었습니다.

• 테스트 자동화 생성 70% 감소 
• 회귀 테스트 백로그 90% 감소
• 회귀 실행 주기 시간 80% 단축

이러한 결과는 미미한 개선이 아니라, 팀 운영 방식의 구조적 변화를 보여줍니다. QA 엔지니어는 상용구 테스트 자동화 작성에서 근본적으로 활용성이 더 높은 활동인 AI 생성 테스트 검토 및 개선으로 전환했습니다. CI/CD 파이프라인 통합을 통해 커밋 후 며칠이 아닌 몇 시간 내에 회귀 오류가 탐지되므로, 결함 있는 변경으로 인한 비용을 크게 절감할 수 있습니다.

이러한 경험은 업계 전반에서 관찰된 바와 일치합니다. 테스트 생성을 위해 생성형 AI를 구현하는 조직에 대한 연구에 따르면 회귀 주기 시간이 평균 60% 단축되었으며, 우리와 같은 고성능 구현을 통해 더 큰 이점을 달성한 것으로 나타났습니다. 일관된 차별점은 컨텍스트입니다. 즉, 전체 코드베이스, 기존 테스트 케이스 및 비즈니스 요구 사항에 접근할 수 있는 AI 테스트 생성기는 코드 스니펫만으로 작동하는 시스템보다 훨씬 더 나은 테스트를 만듭니다.

EPS의 전체 GitHub 리포지토리, 규제 표준 및 기능 문서가 로드된 IBM Bob은 이러한 상황에 기반한 접근 방식을 잘 보여줍니다.

설계 및 아키텍처: 선제적 개선
 

생성형 AI이 선제적 설계 인텔리전스에서 중요한 역할을 하기 시작했습니다. 이는 이미 명시된 내용을 구축하고 테스트하는 반응적인 주기에서 벗어나는 것을 의미합니다. 우리 로드맵에는 Bob이 다음을 수행할 수 있도록 지원하는 내용이 포함되어 있습니다.

• 시간이 지날수록 누적되는 인식되지 않은 성능 병목 현상과 아키텍처 비효율성을 파악합니다.
• 코드 구조와 인시던트 이력 및 성능 데이터를 연관지어 기술 부채 제거의 우선순위를 평가하고 정합니다.
• 기존 아키텍처, 규제 제약 조건 및 비기능 요구 사항을 고려하면서 새로운 기능 개선을 위한 설계 권장 사항을 생성합니다.

이 접근 방식은 코드 수정이나 테스트 자동화보다 더 정교한 사용 사례이며, Bob의 권장 사항에 대해 더 높은 수준의 컨텍스트 신뢰를 필요로 합니다. 권장 사항에 따라 조치를 취하기 전에 인간 설계자가 권장 사항을 검증하는 루프를 유지하는 것은 현재의 AI 성숙도 단계에 대한 올바른 태세입니다.

전체 코드베이스, 문서화된 아키텍처, 수년간의 설계 결정을 수집한 시스템이 몇 주에 걸친 아키텍처 연구가 필요했던 인사이트를 도출할 수 있다는 점에서 그 가치는 상당합니다.

3단계 지원: 문제 해결 과정 마무리
 

우리 로드맵에서 운영에 가장 큰 영향을 미치는 AI 활용 사례는 인시던트 해결 가속화입니다. 고가치 결제 플랫폼에 대한 L3 지원은 위험이 크고 시간에 민감한 활동입니다. 프로덕션 인시던트가 발생하면 근본 원인을 확인하고 해결하는 데 소요되는 시간이 고객에 발생하는 영향을 직접적으로 결정합니다.

Bob의 SDLC 배포 로드맵에는 L3 지원 인시던트 분석, 보고된 증상과 리포지토리의 코드 경로 간 상관관계, 가능한 근본 원인 식별 및 수정 조치 제안이 포함됩니다. Bob을 효과적인 코드 검토자로 만드는 컨텍스트와 동일한 컨텍스트, 즉 코드베이스, 규제 요구 사항 및 오류 처리 패턴에 대한 온전한 지식은 이 작업에 매우 적합합니다.

Bob이 보조하는 인간 L3 엔지니어는 단 몇 초 만에 전체 코드베이스에서 인시던트 서명과 일치하는 패턴을 스캔하여 인시던트 해결을 가속화하고 고객 영향을 최소화할 수 있습니다.

이러한 생산성 중 어느 것도 위험 없이 이루어지지 않습니다. 생성형 AI 시스템은 할루시네이션을 일으킬 수 있으며, 이로 인해 그럴듯해 보이지만 잘못된 아웃풋을 자신 있게 생성할 수 있습니다. 규제 감시를 받는 결제 플랫폼에서는 검토되지 않은 AI 생성 코드 변경이나 잘못 지정된 테스트 케이스가 심각한 향후 결과를 초래할 수 있습니다.

당사의 위험 관리 프레임워크는 반자율 모델을 중심으로 구축되었습니다. Bob은 모든 SDLC 단계에 걸쳐 긴밀하게 통합된 팀원으로 배포되며, 항상 아웃풋이 승인되기 전에 검증하는 인간 검토자와 짝을 이룹니다. 비즈니스 분석가는 Bob이 생성한 요구 사항을 검토합니다. 코드 소유자는 Bob이 식별한 버그와 제안된 수정 사항을 검토합니다. QA 엔지니어는 Bob이 생성한 테스트 케이스를 검토합니다. L3 엔지니어는 Bob의 인시던트 분석을 검토합니다.

이 접근 방식은 제한이 아니라, 지금의 AI 성숙도 단계에 맞는 올바른 아키텍처 패턴입니다. 이 모델은 오류 위험의 대폭 감소를 위해 이론적 효율성 상한의 일부를 타협하며, 이는 신뢰를 점진적으로 구축할 수 있는 방식으로 이루어집니다.

Bob의 아웃풋이 각 영역에서 신뢰할 수 있는 것으로 입증되면 인간의 검토 수준을 적절하게 보정할 수 있습니다. 저는 이 반자율 구성이 몇 년 동안 표준으로 유지될 것으로 예상하며, Bob은 시간이 지날수록 업무 경험을 통해 계속 배우고 점진적으로 더 높은 품질의 아웃풋을 생산할 것입니다.

IBM은 요구 사항, 엔지니어링 및 테스트 전반에 걸쳐 단계와 특정 작업에 따라 Bob을 통해 25%에서 70%의 효율성 향상을 예상합니다. 결과가 각 범위의 가장 보수적인 수준에 머무르더라도, 팀 전체에 미치는 누적 효과는 유효 팀 수용 능력이 25~40% 증가하는 것과 같습니다.

수치를 구체적으로 설명하기 위해 모든 SDLC 단계에서 30%의 효율성 향상을 달성한 10명으로 구성된 팀을 가정해 보겠습니다. 유효 아웃풋은 인력을 추가하거나 그에 비례하여 비용을 늘리지 않고 엔지니어 13명이 원래 속도로 작업하는 것과 같습니다.

정액 예산에 대한 수요가 급증하는 상황에 직면한 조직의 경우, 이는 점진적인 개선이 아닙니다. 이는 동일한 팀이 비례하는 비용 증가 없이 더 많은 기능을 제공하고, 더 높은 품질을 유지하고, 인시던트에 더 빠르게 대응하고, 증가하는 규제 의무를 흡수할 수 있는 역량을 배가시키는 요소입니다.

우리의 경험에서 모든 엔지니어링 리더가 지금 당장 해결해야 할 세 가지 질문이 도출됩니다.

1. 어떻게 회사의 환경에 맞게 AI를 컨텍스트화하고 있나요? Bob에게 코드베이스, 표준, 규제 요구 사항 및 문서를 미리 로드하는 EPS 접근 방식은 이후 모든 작업의 기반이 됩니다. 이러한 컨텍스트 없이 작동하는 AI 어시스턴트는 올바른 기반을 보유한 어시스턴트보다 가치가 낮고 잠재적으로 더 위험할 수 있습니다.
2. 어디서부터 시작해야 할까요? 결과에서 알 수 있듯이, 테스트는 측정 가능한 ROI를 얻는 가장 빠른 방법입니다. 명확한 성공 기준, 비교적 낮은 위험 임계치, 그리고 현상 유지에서 높은 수작업 노력이 결합되어 이 여정을 시작하는 어떤 팀에게도 이상적인 교두보가 됩니다.
3. 신뢰를 점진적으로 쌓아가는 방법은 무엇인가요? 반자율 모델(즉, 인간이 참여하는 AI)은 타협이 아니라, 조직이 가치를 포착하는 동시에 시간이 지날수록 AI의 역할을 확장하는 데 필요한 제도적 신뢰를 구축할 수 있도록 하는 책임감 있는 구현 패턴입니다.

우리 팀이 백로그가 제한된 수동 QA 부서에서 3개월 만에 AI 증강 CI/CD 통합 품질 조직으로 거듭난 여정을 통해 이러한 변화를 빠르게 달성할 수 있음을 알 수 있습니다. 더 광범위한 교훈으로는 SDLC에 내장된 생성형 AI가 미래의 파일럿 프로그램이 아니라는 점을 명확히 알 수 있습니다. 기존에 투자한 팀은 이미 가시적인 성과를 얻고 있습니다. 지금은 바로 그러한 기반을 다질 때입니다.