“우리는 애자일로 개발하고 있습니다.”
공공·국방·대형 엔터프라이즈 IT 프로젝트 현장에서 가장 자주 들리는 말 중 하나다.
하지만 그 다음에 따라오는 현실은 익숙하다.
- 요구사항은 이미 수년 전에 확정돼 있고
- 승인과 검토는 여전히 수개월 단위이며
- 사용자는 개발이 거의 끝난 뒤에야 시스템을 만난다
그 결과, 애자일·DevSecOps를 도입했음에도 소프트웨어는 빠르지 않고, 현장은 만족하지 못한다.
이 모순을 정확히 짚어낸 보고서가 있다.
바로 미국 회계감사원(GAO)의 「’GAO-23-105867’ Defense Software Acquisitions: Changes to Requirements, Oversight, and Tools Needed for Weapon Programs」보고서이다.
애자일의 실패는 개발팀의 문제가 아니었다
GAO는 미 국방부(DOD)가 지난 수년간
- 애자일(Agile)
- DevSecOps
- 디지털 엔지니어링을 적극 도입했음에도, 소프트웨어 경쟁력이 기대만큼 개선되지 않았다는 점을 지적한다.
그 이유는 의외로 단순하다.
“애자일 개발을 하면서도, 애자일을 고려하지 않은 요구사항·관리·감독 체계를 그대로 유지했기 때문”
즉, 문제는 기술이나 개발 역량이 아니라 조직과 시스템의 정렬(alignment) 이었다. 이 지점이 국내 공공 SI, 국방 정보화, 대기업 DX 프로젝트에서도 그대로 반복되는 문제점이다.
여전히 폭포수에 묶여 있는 ‘애자일 프로젝트’
보고서에 따르면, 많은 무기체계·공공 성격의 대형 시스템은
형식적으로는 애자일 개발을 수행하지만, 실제로는 다음과 같은 구조를 벗어나지 못한다.
- 상세 기능까지 고정된 요구사항 문서
- 변경 시 고위급 승인과 장기 검토 절차
- 일정·예산 중심의 성과 관리
- 사용자 피드백은 “검수 단계”에서만 반영
이 구조에서는 아무리 스프린트를 돌리고, CI/CD 파이프라인을 구축해도
애자일의 핵심인 ‘빠른 학습과 적응’은 작동할 수 없다.
GAO는 이를 두고 사실상
“폭포수 위에 애자일을 얹은 상태”라고 평가한다.
GAO가 제시한 해법은 ‘기술’이 아니라 ‘구조’다
흥미로운 점은, GAO의 권고안이 특정 개발 방법론이나 도구를 강요하지 않는다는 것이다.
대신, 애자일이 작동하기 위한 3가지 구조적 조건을 명확히 제시한다.
1. 요구사항은 ‘고정 문서’가 아니라 ‘진화하는 기준’이어야 한다
GAO는 초기 단계에서
- 모든 기능을 상세히 정의하는 방식이 아니라
- 고수준 목표와 우선순위 중심의 요구사항을 설정하고
개발 과정에서 사용자 피드백을 통해 요구사항이 자연스럽게 진화해야 한다고 강조한다.
이는 공공·국방 IT에서 자주 발생하는
“요구사항 변경 = 실패”라는 인식을 정면으로 부정한다.
2. 사용자 참여는 선택이 아니라 전제조건이다
성공적인 애자일 프로젝트의 공통점은
사용자가 개발 프로세스의 ‘외부’가 아니라 ‘내부’에 있다는 점이다.
GAO는 이를 제도화하기 위해
- 사용자 참여 수준을 명확히 정의하고
- 개발 전 과정에서 지속적으로 피드백이 반영되도록 하는 구조를 요구한다.
이는 단순한 회의 증가가 아니라,
개발–운영–사용자가 하나의 흐름으로 연결되는 구조적 변화를 의미한다.
3. 성과는 ‘진행률’이 아니라 ‘전달된 가치’로 측정해야 한다
전통적인 공공·엔터프라이즈 IT 평가는
- 일정 준수
- 예산 집행에 초점이 맞춰져 있다.
하지만 GAO는 애자일 환경에서는
- 얼마나 자주 배포했는지
- 사용자가 실제로 어떤 가치를 얻었는지
- 품질과 안정성은 어떻게 개선됐는지를 중심으로 결과 기반 지표를 봐야 한다고 지적한다.
이 지점에서 모아소프트의 역할이 드러난다
GAO 보고서가 제시한 문제와 해법은,
사실상 국내 공공·국방·대형 SI 프로젝트에서 모아소프트가 지속적으로 마주해온 현실과 겹친다.
모아소프트는 애자일을
- “개발팀의 방식”이 아니라
- 요구사항, 협업, 운영, 성과 관리까지 연결하는 통합 구조로 바라본다.
그래서 모아소프트의 기술은 다음 질문에 답하는 데 초점이 맞춰져 있다.
- 요구사항 변경이 발생했을 때, 영향도와 우선순위는 즉시 보이는가?
- 사용자 피드백이 실제 개발 백로그로 연결되는가?
- DevOps/DevSecOps 파이프라인의 결과가 성과 지표로 이어지는가?
- 지금 이 시스템이 ‘얼마나 개발 중인지’가 아니라 ‘무엇을 제공하고 있는지’를 설명할 수 있는가?
이 질문에 답할 수 있을 때, 애자일은 비로소 속도가 아니라 경쟁력이 된다.
애자일은 선언이 아니라, 설계의 문제다
GAO 보고서의 메시지는 명확하다.
애자일은 도입 여부의 문제가 아니라,
조직·프로세스·플랫폼이 얼마나 일관되게 설계됐는가의 문제다.
공공 IT, 국방 소프트웨어, 대규모 엔터프라이즈 시스템이
진짜로 민첩해지기 위해 필요한 것은
더 많은 회의나 더 짧은 스프린트가 아니라,
애자일이 작동할 수 있도록 설계된 구조와 이를 뒷받침하는 기술이다.
그리고 그 구조를 현실에서 구현하는 것이
지금, 모아소프트가 집중하고 있는 영역이다.
(국방 무기체계) 소프트웨어 애자일 설계 문의 02-6945-2156