[A-S01-02] 지난 1회차 포스트(A-S01-01)에서는 공공 SI 프로젝트에서 요구사항 정의가 왜 산으로 갈 수밖에 없는지, 그 구조적인 한계에 대해 이야기했습니다. 수천 페이지의 제안요청서(RFP)와 과업지시서는 백 장을 넘겨도 발주처와 수행사 간의 ‘동상이몽’을 해결 못합니다. 불명확한 글(Text)로 된 요구사항은 결국 개발 막판에 ‘화면 엎기’라는 부메랑으로 돌아옵니다. 하지만 AI 요구사항 정의(ai-requirements-definition)만 가능하다면 대안이 있을 것도 같습니다.
이번 2회차에서는 이 고질적인 문제를 어떻게 해결할 것인가에 대한 실무적인 대안을 제시하고자 합니다. 결론부터 말씀드리면, AI를 활용해 요구사항의 ‘실체’인 프로토타입을 먼저 만드는 것입니다. 뜬구름 잡는 말 대신, 굴러가는 화면 하나로 소통의 밀도를 극대화하는 방법을 공유합니다. 자! 그럼 ‘AI 요구사항 정의’ 함께 보시죠.
1. 개념 전환 : 복잡한 요구사항 정의, 단순한 ‘화면’으로
요구사항을 정의한다는 것은 SI 분야에 몸담고 있는 사람이라면 누구나 아시겠지만, 수많은 이해관계자와 정책, 기술적 제약이 얽혀 있는 상당히 복잡한 일입니다. 그런데 사실 이 복잡한 일이 종국에 가서는 고객들이 매일 사용하게 될 ‘화면(GUI)’으로 귀결됩니다. 그렇게 복잡했던 논의 과정이 결국엔 직관적인 화면들로 완결된다니, 무언가 허무하기도 합니다. AI 요구사항 정의가 가능해지면 더 허무해질지도 모릅니다.
물론 화면으로만 정의할 수 없는 비기능적 요구사항들이 있지만, 이는 대부분 정책이나 비즈니스 규칙(Rule)과 관련된 것들이어서 별도로 정의하면 됩니다. 핵심은 AI 요구사항 정의를 통해 프로젝트의 시작과 동시에, 혹은 시작하기에 앞서 기획 수준으로 동작 가능한 프로토타입을 먼저 만들고, 이 실체를 기준으로 요구사항을 명확하게 역정의하는 것입니다. AI는 이 과정의 속도를 혁신적으로 높여줍니다.
2. 첫 단추: AI 학습용 ‘기준 문서’ 준비(RFP, 매뉴얼)
AI 요구사항 정의를 통해 프로토타입을 만들려면 그 근거가 되는 정보가 필요합니다. 하지만 고객의 머릿속에만 있는 요구사항을 꺼내는 것은 시간이 걸리고 어려운 일입니다. 그래서 우리는 이미 존재하는 파편화된 문서들을 활용합니다. AI는 수천 페이지의 매뉴얼과 파편화된 RFP를 단 몇 분 만에 교차 분석하여 인간이 놓치기 쉬운 ‘논리적 구멍’을 찾아냅니다.
최소한 아래 3가지 유형의 문서가 필요합니다.
제안요청서(RFP) : 목표시스템과 핵심 과업이 담겨 있는 1차적 기준
AS-IS 메뉴구조도(Information Architecture) : 제안 단계에서 분석한 현행 시스템 정보설계 산출물들을 통해 목적 시스템에 대핸 정보구조를 파악해둔 결과물
업무 매뉴얼 : 실제 사용자들이 업무를 처리하는 상세 프로세스가 담겨 있어 구체적인 화면 기획이 가능해짐
3. 두 번째 단추: 전문 BA 역할을 부여한 ‘AI 프롬프트’
기준 문서가 준비되었다면 이를 AI에게 학습시킵니다. 이때 단순히 문서를 업로드하는 것보다 AI 요구사항 정의 효율을 높이려면, AI에게 명확한 역할(Role)과 미션을 부여해야 합니다. 프롬프트 예시는 다음과 같습니다. 제가 한글로 작성해서 줬더니 AI가 영문으로 이미지를 도출되긴 했지만 읽어보면 바로 이해되실 만큼 단순한 문장입니다.
이 정도의 구체적인 프롬프트를 통해, AI는 기준 문서들을 바탕으로 TO-BE 시스템의 근간이 될 메뉴구조도 초안을 도출해 냅니다.
4. 구체적 실행: 메뉴구조도에서 프로그램 목록까지, AI의 연쇄 설계
AI에게 메뉴구조도를 도출하게 힌 이유는 결국 프로토타입을 설계할 수 있는 정보 기준을 잡게 하기 위함입니다. 정보 기준이 잡혔다면, 다음으로 실제로 AI가 프로토타입을 상세 설계할 수 있도록 연쇄적인 학습 과정을 거칩니다. AI 요구사항 정의 추론과정이라고 보면 됩니다.
- 화면 목록 식별 : 메뉴구조도와 연결하여 특정 메뉴에 어떤 화면이 필요하고, 해당 화면은 어떤 유형(조회, 등록, 수정 등)이며, 어떻게 정의되는지를 매트릭스 형태로 도출합니다.
- 프로그램 목록 및 기능 정의 : 식별된 화면을 실제 동작하는 프로토타입으로 만들기 위해 필요한 프로그램 목록과 응용기능분해도(FDD)까지 도출시킵니다.
시스템을 구현하기 위해 필요한 주요 산출물들을 이와 같은 패턴으로 반복 학습 및 도출시키면서 AI 요구사항 정의를 위한 설계의 밀도를 높여갑니다.
5. 완벽하지 않은 프로토타입: 사람이 밸런싱을 잡다
상기 과정을 거친 후 학습된 자료를 바탕으로 AI에게 프로토타입을 만들게 합니다. 처음이라 모든 면에서 부족하고 서투를 것입니다. 하지만 그게 정상입니다.
이제부터는 프로젝트 팀이 주체가 되어 부족한 프로토타입을 실제 요구사항에 맞춰 계속 강화시키는 작업을 합니다. 이 단계에서 임시적인 데이터 설계를 진행하여 프로토타입을 실제로 동작하게 할 수준의 데이터 목록을 도출시킵니다.
핵심은 “AI가 초안을 잡고, 사람이 거버넌스적 관점에서 검수하고 밸런싱을 한다”는 점입니다. AI가 만능이 아니라는 점을 명시함으로써 프로젝트의 위험을 관리합니다.
마무리: 대망의 AI 요구사항 정의 준비 완료
프로토타입이 완성되면 이제 AI 요구사항 정의를 할 준비가 끝난 겁니다. 글로 된 요구사항을 보고 상상하는 것이 아니라, 이미 만들어진 실체를 보고 “이 부분은 이렇게 고쳐주세요”, “여기에 이 기능이 추가되어야 합니다”라고 구체적인 피드백을 주고받을 수 있습니다.
이때 각 단계에서 AI가 도출해 준 산출물도 모두 사람이 검수하되, 현재 우리 프로젝트에서 필요한 산출물 양식에 맞는지를 중점적으로 검수하고 결과값 밸런싱을 합니다. 추가적으로 행정안전부 또는 기관별 표준 가이드(UI/UX 가이드, 명명 규칙 등)를 함께 학습시킨다면, 프로토타입은 단순한 시안을 넘어 실제 개발 단계에서 즉시 활용 가능한 ‘표준 준수형 모델’로 진화하게 됩니다. 이는 공공 SI에서 막판에 화면을 다 갈아엎는 고통을 예방하는 최고의 무기가 됩니다.
이제 AI에게 물어보겠습니다. “이런 과정 학습 가능한 자료만 있다면 어느 정도나 소요되겠니? 시작부터 프로토타입 도출까지 말이야”하고요. 자~ 다음 회차에서는 AI 제미나이와 어떻게 협업하는지 실제 워크플로우를 그려보겠습니다.
[A-S01-01] 공공 SI 프로젝트 산으로 가는 이유, 요구사항정의의 함정
[A-S01-02] AI 요구사항 정의 : 눈에 보이는 프로토타입으로 실체화하기
[A-S01-03] 요구사항 정의를 위한 AI 제미나이 협업 워크플로우
[A-S01-04] “기억상실”에 걸린 AI치료를 위한 AI 기획 실전 전략
“AI 요구사항 정의 : 눈에 보이는 프로토타입으로 실체화하기”에 대한 1개의 생각