[A-S01-03] 지난 2회차 포스트(A-S01-02)에서 AI를 통해 요구사항의 ‘실체’인 프로토타입을 먼저 만드는 개념을 다뤘습니다. 그렇다면 실제로 제미나이(Gemini) 앞에 앉아 무엇부터 물어봐야 할까요? 이 포스트에서는 ‘AI 제미나이 협업 워크플로우’를 공개합니다. 이 프로세스를 따라오시면 막막했던 요구사항 정의가 시스템 설계로 바뀌는 실마리를 얻으실 수 있지 않을까 기대해봅니다. 그럼 제미나이 협업 워크플로우 시작해보겠습니다.
1단계: Context Injection(맥락 주입)
제미나이 협업 워크플로우에서 가장 먼저 해야 할 일은 ‘기본 정보’를 주는 것입니다. 아시다시피 공공 SI는 산출물 중심으로 돌아갑니다. 과도하고 요식행위 적인 산출물 작성은 솔직히 프로젝트에 하등의 도움이 안됩니다. 하지만 설계를 위한 기준점을 제시한다는 점에서 산출물은 특히 공공 SI에서는 뗄레야 뗄수 없는 뗄감 같은 존재입니다. 그래서 아래와 같이 맥락을 주입할 때에는 소속된 조직의 표준 산출물 셋이 반드시 있어야 하며, 진행자가 무엇이 올바른 산출물 형상인지에 대한 개념이 잡혀 있어야 합니다. 그래야 좋은 결과를 도출할 확률이 높아집니다.
- 실행 : 제안요청서(RFP), 업무 매뉴얼, 현행 메뉴구조도를 업로드합니다.
- 프롬프트 핵심 : “너는 20년 경력의 공공 SI 비즈니스 분석가야. 지금부터 내가 주는 문서들을 완벽히 학습해줘. 질문이 생기기 전까지는 분석만 하고 대기해.”
- 효과 : 제미나이 협업 워크플로우에서 제미나이(AI) 자체가 프로젝트 배경과 도메인 지식을 업무전문가 수준으로 확보할 수 있도록 동기화할 수 있습니다.
2단계: Structure Extraction(뼈대 추출)
학습이 끝났다면 시스템의 근간이 되는 ‘메뉴 구조’부터 뽑아냅니다. 메뉴 구조는 웹사이트나 정보시스템 구축에 있어 정보설계의 첨단이라고 생각합니다. 제미나이 협업 워크플로우에서 가장 중요한 정보인 셈이죠. 특히 정보시스템의 경우 모든 업무의 관문에 달린 명패가 메뉴명입니다. 그래서 메뉴구조만 알면 내가 무엇을 어느 범위까지 만들어야 하는가에 대한 레이아웃을 도출할 수 있습니다. 여기서도 사람의 연륜은 필요합니다. 모든 산출물은 프로젝트 현장에서 가장 효율을 잘 끌어올려주는 최적의 형상이 있습니다. 메뉴구조도도 마찮가지인데요. 이런 노하우를 사람이 직접 AI에게 입혀줘야 합니다. 제미나이 협업 워크플로우 2단계의 상세 내용은 이렇습니다.
- 프롬프트 핵심: “학습된 문서를 바탕으로 TO-BE 메뉴구조도를 도출해줘. AS-IS의 단점을 보완하고 RFP의 신규 기능을 반영해서 3 Depth 구조의 시트로 작성해줘.”
- 기획자의 개입: AI가 뽑아준 메뉴 중 불필요하거나 과도한 부분을 사람이 쳐냅니다. 이 ‘검수’ 단계가 기획자의 역량이 발휘되는 시점입니다.
3단계: Detail Mapping(상세 매핑)
뼈대가 잡혔다면 이제 살을 붙입니다. 메뉴 하나하나에 어떤 화면과 기능이 들어갈지 정의합니다. 2단계에 설명드린 것처럼 결국 산출물이란 건 연관성과 영향도가 잘 기획되고 계획된 컬럼값들의 의 유의미한 나열입니다. 유의미한 결과를 얻으려면 다년간의 SI 경험노하우가 반드시 필요합니다. 우리는 지금 제미나이 협업 워크플로우 내에서 AI와 협업하는 것이니까요.
- 실행 : 메뉴 구조도를 다시 제미나이에게 입력하며 화면 목록과 프로그램 목록을 요구합니다.
- 프롬프트 핵심 : “각 메뉴별로 필요한 화면 유형(Grid, Form, Chart 등)과 주요 기능을 매트릭스 형태로 정리해줘.”
- 산출물 : 이 단계에서 화면 정의서의 기초 데이터가 완성됩니다.
- 검증 : 위의 실행부터 산출물까지 각 단계에는 반드시 검증이 있어야 합니다. 어떻게 검증하고 검증한 내역을 구조화시켜서 AI작업물에 대한 신뢰도를 높일 것이냐는 앞으로 점점 더 중요해질 겁니다.(참고 글: 검증용 AI를 따로 두어야 하는 이유)
4단계: Interactive Prototyping(대화형 프로토타이핑)
가장 흥미로운 단계입니다. 특정 화면을 구체화하는 단계거든요. 바로 이 단계를 위해 UX/UI 표준에 대한 사전학습이 필요합니다. 그리고 무엇보다 사람의 센스가 필요한 단계입니다. 프로토타입을 도출하는 과정에는 해당 화면으로 고객과 실제 인터뷰를 진행해야 한다는 시뮬레이션 전략이 깔려있어야 합니다. 우리는 단순하게 프로토타입을 위한 프로토타입을 도출하는 것이 아닙니다. 요구사항을 명확하게 정의하기 위한 요구사항의 가시화를 시도하고 있는 것입니다.
- 프롬프트 핵심: “위 목록 중 ‘A 기관 감사 대상 선정’ 화면을 설계해줘. 어떤 조건값(Condition)이 필요하고, 결과값(Result)에는 어떤 컬럼이 들어가야 업무 효율이 높을까?”
- 워크플로우: 제미나이가 제안한 화면 구성을 보고, 기획자는 “이 필드는 보안상 빼고, 대신 통계 그래프를 넣어줘”라며 대화로 튜닝합니다.
5단계: Artifact Generation(산출물 자동화)
마지막으로, 확정된 설계를 바탕으로 문서를 생성합니다. 이 부분 역시 전 두개의 단계에서 계속 강조했듯이 회사의 산출물 표준을 AI에게 먼저 학습시키고 AI와 충분한 토의를 거쳐야 합니다. 산출물의 퀄리티가 객관적으로 어느 수준에 올라와 있다는 신뢰도 있는 결과값을 가진 상태에서야 비로서 제미나이 협업 워크플로우를 통해 AI에게 산출물 자동화 임무를 부여할 수 있습니다.
- 실행: 요구사항 정의서, 기능분해도, 심지어 임시 DB 테이블 명세서까지 요청합니다.
- 효과: 수작업으로 일주일 걸릴 문서화 작업이 단 몇 시간으로 단축됩니다.
마무리: 우리는 ‘디렉터’가 되어야 합니다
제미나이 협업 워크플로우 가장 중요한 것은 ‘질문의 질’과 ‘검수’입니다. AI는 지치지 않고 수만 개의 조합을 만들어내지만, 그중 프로젝트의 성격에 딱 맞는 최적의 답을 고르는 것은 결국 사람의 몫입니다. 또한 때로는 엑셀 이미지 3장 안에 있는 100줄도 안되는 데이터를 sheet로 생성해달라는 요구도 수행하지 못할 때가 있습니다.(무료버전, 글쓰는 시점 기준) 따라서 사람은 반드시 날카로운 검수가가 되어야만 합니다.
자, 이제 제미나이 협업 워크플로우는 준비되었습니다. 다음 회차에서는 이 프로세스를 실제 공공 프로젝트 사례에 적용했을 때 어떤 결과가 나왔는지, 구체적인 경험치 또는 수치와 함께 보여드리겠습니다. 가급적 프로그래머들이 시도한 사례도 수집하여 보여드릴 수 있도록 노력해보겠습니다.
💡이 블로그의 다른 글
[A-S01-01] 공공 SI 프로젝트 산으로 가는 이유, 요구사항정의의 함정
[A-S01-02] AI 요구사항 정의 : 눈에 보이는 프로토타입으로 실체화하기
[A-S01-03] 요구사항 정의를 위한 AI 제미나이 협업 워크플로우
[A-S01-04] “기억상실”에 걸린 AI치료를 위한 AI 기획 실전 전략
“요구사항 정의를 위한 AI 제미나이 협업 워크플로우”에 대한 1개의 생각