공공 SI 프로젝트 산으로 가는 이유, 요구사항정의의 함정

들어가며, 공공SI에서의 고객요구사항

 

제안요청서(RFP), 그 추상적 언어의 잡채

일을 제대로 하시는 분들은 아시겠지만 공공 SI에서도 기획임무를 잘 수행한다는 것은 쉬운 일이 아닙니다. 언제나 그렇듯 수요기관의 제안요청서는 빽빽하지만 정합성도, 구체성도 결여된 경우가 대부분입니다. 정보화사업 기획단계에서의 RFI(Request for Information·정보요청서)를 작성하고 RFP(Request for Proposal·제안요청서)를 작성하는 담당자들의 전문성 부족도 문제지만, ‘추상적인 언어’로 범위를 모호하게 설정해두는 관행을 여전히 답습 중인 공무사회의 매너리즘도 큰 문제입니다.

• 제안요청서의 현실 : 기능 하나를 만드는 건지, 전 화면에 적용하는 건지도 모호한 상태
• 이에 따른 결과 : 고객요구사항 분석 단계가 테크니컬한 작업이 아닌, ‘밑도 끝도 없는 인터뷰’와 ‘공수로 인정받지 못하는 컨설팅’등으로 변질

공공 SI 제안요청서 예시(AI 생성 이미지)

무엇보다 구조적으로 요구사항의 정확도가 낮을 수 밖에 없다는 점이 공공 SI의 가장 큰 문제입니다. 공공 SI에서도 기능점수(Function Point)를 산출해서 사업규모를 산정하지만 정확도가 높지 않습니다. 이유는 요구사항 자체가 추상적인 것도 모자라 주로 간이법(Estimated Function Point)으로 기능점수를 산출하기에 요구사항을 정확히 수렴하기 어렵습니다. 간이법이란 것이 기능의 복잡도를 따지지 않고 각 기능 유형(데이터/트랜잭션)별로 평균 복잡도 가중치를 일괄 적용하기 때문에 정확도가 낮을 수밖에 없습니다.

상황이 이러하니 공공 SI 사업을 발주하면서 사업규모를 정확하게 산정하는 것에는 극명한 한계가 있습니다. 안타깝지만 실제로 소위 대충 치고 쫑보는 식으로 사업들이 쏟아진다고 해도 과언이 아닙니다. 이런 이유 때문에 최근 몇년 사이에 대기업들도 공공 SI에 두손두발 다 들었습니다. 더러워서 못해먹겠다는 것이죠. 10개만 하면 되다고 해서 사업수주 했는데 110개를 시키더라. 고객은 요구사항을 결정하지 않고 지체보상금은 수행사에게만 물리더라. 대충 이런 느낌인거죠. 물론 수행사가 형편 없는 경우도 많이 있고요. 아무튼 실제로 정부를 대상으로 계약 관련 소송이 여러건 진행중에 있습니다.

어이가 없는 건 이렇게 대충 기능점수를 산정해 사업의 규모(또는 대가)를 산정하지만, 실제 수행에 들어가서 분석설계가 완료되거나 사업이 종료될 때에는 정통법(Detailed Function Point)으로 다시 기능점수를 정산하는데, 간이법으로 산출한 내용 대비해 그 차이가 상당하다는 것입니다. 요구사항이 샘솟는 샘을 품고 있는 것 마냥 고객은 크고 작은 요구사항을 계속 뿜어냅니다. 때문에 프로젝트 현장에서 업무분석가가 “이 요구사항 무슨 뜻이에요? 범위가 어디까지죠?”라는 질문을 자주하게 됩니다. 이런 질문이 잦아진다는 것은 프로젝트의 위기가 가까워지고 있다는 방증이기도 하죠.

 

태생부터 불완전한 요구사항, ‘노가다’ 같은 분석

공공 SI 사업은 건설산업의 품셈처럼 정량화된 일거리만 해내고 끝낼 수 있는 구조가 아닙니다. 누군가는 고객이 풀어 쓴 형이상학적 요구를 ‘요구사항정의서’에 구체화시켜야만 합니다. 바로 분석 단계(*CBD 방법론 기준)의 일입니다. 프로젝트 현장에서의 분석은 전문적인 메커니즘을 통해 혁신을 창조하는 단계가 아닌 사람을 인터뷰하며 산출물을 정리하는 ‘노가다’에 가깝습니다.

“선생님, 이게 맞아요? 저게 맞아요? 언제까지 정해줄 수 있는데요?” “이건 좀 애매한데, 절차가 아예 없으신데, 업무절차를 만들어달라고요? 대충 이렇게 가면 안 되나요?”

 

철학책인가 ‘요구사항정의서’인가? 개발 가능하겠는가?

공공 SI 프로젝트 현장에서 마주하게 되는 요구사항정의서는 텍스트 기반이며 늘 끝없는 추론을 동반합니다. 메뉴구조도 같은 기초 정보문서조차 고객이 감을 잡지 못해 스무고개 같은 컨설팅 업무가 동반되곤 하죠. 문제는 이런 연구작업의 소요가 ‘공수’로 인정받지 못한다는 점입니다. 관련해 사업을 발주하기 전에 미리 ‘요구사항 구체화 및 규격화를 위한 연구용역’을 진행하는 것을 규제화하고, 누가봐도 명백하게 요구사항을 구체화시키는 것이 정상적인 흐름이라고 생각합니다. 현재 대한민국 공공SI는 비정상적인 생태계를 방치하고 있습니다.

관련해, 실제로 소프트웨어 공학 통계(IBM)에 따르면, 분석 단계 오류를 구현 단계에서 수정할 때 드는 비용은 초기보다 최소 10배 이상 증가합니다. 그럼에도 불구하고 대한민국 공공SI 시장은 이 비용을 수행사가 고스란히 지불하는 구조로 돌아가고 있습니다. 명확하지 않은 요구사항들이 수행사의 ‘손해’를 불리우고 있는 것입니다.(출처: IBM Systems Sciences Institute 및 Barry Boehm의 소프트웨어 공학 연구 자료)

 

<그림 설명 : Software development: The tree swing>
“우리는 모두 같은 요구사항 정의서를 보고 있지만, 머릿속으로는 각자 다른 그네를 만들고 있습니다. 이것이 텍스트 기반 분석의 한계입니다.”

 

패러다임의 전환: AI와 함께만드는 프로토타입

지금까지 다소 개괄적이긴 하지만 대한민국 공공SI의 핵심적인 문제점을 살펴봤습니다. 관련해 이런 내용에 대해 관련 협회들을 중심으로 기업들의 목소리를 모아 정부제도의 변화를 촉구하는 것도 필요합니다. 하지만 여러분도 잘 아시다시피 정부는 언제나 너무 늦게 바뀌거나 바뀌지 않는 집단이니 일단은 기업 스스로 생존법을 마련해두는 것이 상당히 중요하다고 생각합니다.

관련해 이제는 텍스트 기반으로 요구사항을 정의하는 패러다임을 바꿔야 한다고 생각합니다. 이 문제를 해결하는 가장 적합한 방법은 ‘AI와 함께 신속하게 초기 프로토타입을 만들고, 이 프로토타입을 바탕으로 고객요구사항을 분석하는 방법이라고 판단하고 있습니다. 실제로 저는 프로토타입을 통한 요구사항정의 단계를 얼마나 혁신적으로 개선할 수 있을지에 대해 동료들과 함께 실험을 진행하고 있습니다. 저는 무료버전의 Gemini를 사용하고 프로그래머 참여자들은 클로드코드와 같은 다양한 유료 AI를 사용해서 차이점을 비교하며 워크플로우를 추가 또는 삭제해가며 하나의 절차를 완성해가고 있습니다.

우리는 이 실험을 통해 AI를 활용해 혁신적인 속도로 프로토타입을 만들고 이를 바탕으로 빠른 요구사항 추론하고, 점차적으로 프로토타입의 구현 수준을 개발 목적물에 가깝게 조절하고, 이를 모든 설계의 기준점으로 승화시키려는 목표를 공유하고 있습니다.

 

다음 회차 예고

어떻게 이 일을 실행할 것인가? 현재 저희 회사에서 프로그래머들과 진행 중인 ‘AI와 실패하기’ 프로젝트를 통해 그 실전 개념을 공유하겠습니다. 다음 회차가 궁금하시다면 구독(혹은 북마크)해 주세요 2회차 글을 작성하는대로 링크 걸겠습니다.

“더 많은 IT 기획 인사이트는 [7instant 블로그 메인]에서 확인하실 수 있습니다.”

---

💡이 블로그의 다른 글

[A-S01-01] 공공 SI 프로젝트 산으로 가는 이유, 요구사항정의의 함정
[A-S01-02] AI 요구사항 정의 : 눈에 보이는 프로토타입으로 실체화하기
[A-S01-03] 요구사항 정의를 위한 AI 제미나이 협업 워크플로우
[A-S01-04] “기억상실”에 걸린 AI치료를 위한 AI 기획 실전 전략