3년간 AI 요구사항 정의에 매진해 온 모든 기록

안녕하세요. 주로 X에서 AI 주도 개발(AI-driven development)에 대해 발신하고 있는 쿠마이 유(Kumai Yu)입니다!

현재는 AI 스타트업 기업의 CEO 겸 CTO를 맡고 있습니다!

저는 전직인 SIer, IT 컨설팅 기업에서 상류 공정(Upstream process)에 관여할 기회가 많았습니다.

그렇기 때문에 생성 AI(Generative AI)가 등장했을 때, 가장 먼저 "이것은 요구사항 정의(Requirements Definition)·상류 공정의 영역을 크게 변화시키지 않을까"라고 느끼고, 즉시 사내에서 검증을 시작했습니다.

이 기사에서는 약 3년에 걸친 요구사항 정의 × 생성 AI의 시도를 시계열로 되돌아봅니다. 결론부터 말씀드리면, 3년 동안 도달한 답은 조금 의외의 것이었습니다.

이 기사에 대하여

• SIer / 컨설팅 출신인 제가 2023년부터 추진해 온 「요구사항 정의 × 생성 AI」의 변천사를 정리한 기록입니다
• 각 단계에서 「무엇을 시도했고, 무엇을 배웠는가」를 시계열로 따라갑니다
• 앞으로 AI 요구사항 정의에 도전하실 분들에게 힌트가 된다면 기쁘겠습니다

먼저, 이 기사에서 따라갈 경로의 매핑입니다.

후반부로 갈수록 개발 공정 전체에 대한 이야기도 다소 등장합니다.

시기	시도	얻은 배움
2023.7	텍스트로부터 플로우 차트를 자동 생성하는 실험	사전 정보(용어집·전제)의 정리가 정밀도를 결정함
...	툴의 비용을 「결단」의 장벽으로 만들지 않는다

처음으로 시도한 것은 약 3년 전입니다. 메일이나 Slack 등의 텍스트 정보를 바탕으로, OpenAI API(주로 gpt-3.5)를 이용하여 업무 요구사항 정의에서의 업무 플로우를 생성하는 프로그램을 사내 실증 실험으로서 만들고 있었습니다.

결과적으로, 잡담이나 관계없는 대화를 포함하여 정밀하게 판별할 수 없었기에, 사전에 용어집·등장인물·어느 정도의 업무 가설을 정의한 후 생성함으로써 겨우 그럴듯한 플로우 차트를 만들 수 있었습니다.

사실 지금도 사전 정보의 의의를 중요하게 여기는 이유는 이 경험이 있기 때문입니다. 정성적인 정보라 하더라도 컨텍스트(Context)에 포함하도록 하는 것만으로 생성의 정밀도는 격하게 달라집니다.

여기에서의 배움

용어집·전제 사항의 나열이 중요 (이후 Rule의 개념으로 이어짐)

2023년 10월경에는 Cursor가 등장하기도 하여 이용을 시작했습니다. 모델은 gpt-3.5가 중심이었지만, 참고할 수 있는 컨텍스트(용어집·요구사항 정보)를 코드로부터 취득함으로써, 엔한스(Enhance) 시의 요구사항 문서 생성은 격하게 수월해졌습니다.

또한 당시에는 Amazon Bedrock이 등장하기도 하여, 업무 이용을 포함해 상당히 가능성이 보이기 시작한 시기이기도 했습니다.

이 당시에 의식했던 것은, 「코드베이스(Codebase)」를 적절하게 취득하여 Markdown에 필요한 정보를 나열하는 것입니다. 이를 통해 추가 요구사항이 발생했을 때의 문서 생성을 매우 하기 쉬운 상태로 만들 수 있었습니다.

여기에서의 배움

코드베이스를 이용하는 것이 중요 (이후 코드 인덱스(Code Index)로 이어짐)

지금까지의 시도로 생성 AI의 가능성을 느꼈기에, 2024년 봄 무렵에는 일부 팀에서 도입을 시작했습니다.

한편으로는, 「채팅 기반형 AI 이용 + 컨텍스트를 올바르게 정리하여 전달하기」라는 부분을 조직화하는 시행착오의 과정 중이기도 했기에, 전사 전개까지는 이르지 못하고 일부에서의 이용이라는 형태를 취했습니다.

역시 당시에는 AI에 대해 회의적인 의견도 많아, 전사 도입까지는 단행하지 않고 신중하게 진행했습니다.

당시에는 나중에 조어로 부르게 됩니다만, 프로젝트의 정보를 모두 Markdown이나 코드로 표현하자며 「Project as Code」라고 부르며 오로지 축적을 진행했습니다. 이 프로젝트 정보를 코드로 일원 관리하는 수법이 나중에 소개해 드릴 「코드베이스로부터의 역추적 생성」에 의한 요구사항 정의의 기반이 됩니다.

여기에서의 배움

• 우선은 에반젤리스트(Evangelist) 역할을 하는 멤버를 중심으로 활용 노하우를 쌓는다
• 노하우를 전개하기보다, 쌓는 방향(코드화)을 추진했다

2024년 9월, 지금까지 쌓아온 노하우를 토대로 요구사항 정의의 모든 공정에서 AI를 본격 활용하는 단계에 들어갔습니다. 주로 3가지 접근 방식을 병행하여 진행하고 있습니다.

첫 번째는, 코드베이스로부터의 역추적 생성에 의한 문서화입니다. 기존 코드를 기점으로 사양이나 업무 플로우의 문서를 생성합니다. 수작업으로 작성하는 것보다 빠르고, 구현과의 괴리도 일어나기 어렵습니다.

두 번째는, UI 생성 AI를 활용한 목업(Mockup) 제작부터 요구사항 정의 문서로의 전개입니다. v0 등으로 먼저 목업을 만들어 인식을 맞추고, 거기서부터 요구사항을 확정합니다. 실제로 작동하는 것을 보여줌으로써 고객과의 인식 차이를 조기에 해소할 수 있습니다.

세 번째는, GEAR.indigo를 활용한 프리세일즈(Pre-sales) 단계에서의 요구사항 정의입니다. 상담 단계부터 요구사항 정의를 시작함으로써, 수주 전에 요구사항의 해상도를 단번에 높일 수 있습니다.

여기서의 배움

단발적인 프롬프트가 아니라, 컨텍스트(Context), 코드베이스(Codebase), 노하우를 통합하여 '시스템(仕組み)'으로서 요구사항 정의에 편입시키는 것이 생산성 향상의 포인트입니다.

2024년부터 실천을 거듭하는 가운데, 다음에 마주한 것은 '개발 그 자체를 어떻게 진행할 것인가'라는 틀(型) 만들기였습니다. 개별 공정에서 AI를 사용할 수 있게 된 그 너머에서, 요구사항 정의부터 구현까지 팀 전체가 안정적으로 돌릴 수 있는 방법론을 공고히 하는 단계에 들어선 것입니다.

특히 AI 요구사항 정의를 조직에 뿌리내리게 함에 있어 "누구나 동일한 아웃풋을 얻으려면 어떻게 해야 하는가?"라는 질문에 답할 필요가 있었기 때문입니다.

이 과정에서 확립한 것이, **"골격은 코드 컨텍스트, 요구사항은 프롬프트"**라는 사고방식입니다.

아무것도 없는 상태에서 자연어 지시만으로 개발하는 완전한 바이브 코딩(Vibe Coding)보다, 스켈레톤 코드(Skeleton Code, 기반 코드)를 토대로 하는 편이 생성되는 코드의 품질도, 멤버의 학습 효율도 안정적입니다.

골격은 기존 코드로부터 읽어오게 하고, 요구사항은 프롬프트로 전달한다. 여기까지의 배움이 하나의 형태로 결실을 보았습니다.

개발 프로세스 자체도 제가 'AI 구동 애자일(AI-driven Agile)'이라고 부르는 하이브리드형으로 진화했습니다. 단계적인 진행 방식은 애자일(Agile), 개별 개발은 설계 편중의 고속 워터폴(Waterfall). 요구사항·사양이 모호한 상태에서 코드를 생성함으로써 발생하는 재작업(Rework) 리스크를 최소화하기 위해, 요구사항 정의·설계 페이즈를 두텁게 가져가는 것이 요점입니다.

여기서의 배움

골격을 코드에 담음으로써 요구사항에 집중할 수 있는 플로우를 정비한다.

한 걸음 더 나아간 것이 **"0일 도입"**이라는 방법론입니다. 프로젝트 시작 시점에 기반 코드를 테스트 환경에 배포하여, "이미 작동하고 있는 시스템"을 전제로 고객과 요구사항 정의·설계를 진행하는 접근 방식입니다.

문서는 기반 코드를 전제로 한 템플릿을 차분 수정하는 것만으로 충분합니다.

정례 회의에서는 가능한 한 실제로 작동하는 것을 보여주며 인식을 맞춥니다. 요구사항 정의는 '스코프(Scope, Issue)를 나누는' 작업으로 재정의하여, 개발이 1시간 이내에 완完결될 수 있는 입도(Granularity)까지 분해합니다. 이러한 입도의 스코프 나누기는 가능하다면 비즈니스 측 인원이 담당하는 것이 바람직하다고 생각합니다.

중요한 점은, 요구사항 정의의 주역이 '문서를 쓰는 것'에서 '올바른 스코프를 나누는 것'으로 옮겨갔다는 점입니다. AI가 개발을 가속화하면 할수록, 상류 단계의 "무엇을, 어느 정도의 입도로 만들 것인가"를 정의하는 능력이 병목(Bottleneck)이 됩니다.

여기서의 배움

AI로 개발이 빨라질수록 병목은 상류로 이동한다. 요구사항 정의는 '문서 작성'이 아니라 '스코프 설계'로 역할이 변한다.

요구사항 정의의 노하우를 3년에 걸쳐 연마하는 과정에서, 우리는 하나의 프로덕트를 만났습니다. 위에서도 언급했듯이, AI 구동 요구사항 정의 툴인 **"GEAR.indigo"**입니다. 처음에는 유저로서 이용을 시작하여 그 효과를 가까이서 체감하고 있었습니다. 지금까지 이야기한 방법론이 솔루션으로서 모두 담겨 있는 프로덕트였습니다.

그리고 2025년 12월, 우리는 이 GEAR.indigo 사업을 개발원인 Stellaps사로부터 양도받았습니다. 시스템을 강화하고 싶다, 더 많은 사람에게 이 감동을 전달하고 싶다. 그러한 의사결정이었습니다.

나아가 자사가 3년에 걸쳐 연마한 요구사항 정의 노하우와 양도받은 프로덕트. 이 두 가지를 결합하여, 요구사항 정의·설계 페이즈를 가속하는 "GEAR.indigo Biz"로 키워나가고 있습니다. 컨셉은 심플합니다. "회의 메모를 붙이기만 하면, 요구사항과 설계가 알아서 진행된다".

3년 전, 잡담이 섞인 텍스트로부터 플로우 차트를 생성하려고 수작업으로 고군분투했던 그 실험. 그때 파악한 "사전 정보가 핵심이다", "코드베이스가 핵심이다"라는 배움은 지금 GEAR.indigo Biz를 다듬어가는 토대로 이어져 살아있습니다.

사실 개발 프로세스를 Claude Code 중심으로 바꾸게 된 지금도, 요구사항 정의·기본 설계에서의 정보 정리 및 합의 형성 프로세스까지 Claude로 구현하는 것은 다소 어렵습니다.

그것은 Markdown의 가시성이나 승인 프로세스(지시 이력)의 가시화 등, 기존 방식의 워터폴 (Waterfall) 프로세스에는 맞지 않는 부분도 있기 때문입니다. 그러한 배경에서 GEAR.indigo Biz에 그 핵심적인 요소들을 모두 담았습니다.

그림: 현재의 개발 플로우 도표

2026년, 우리는 GEAR.indigo Biz를 BYOK (Bring Your Own Key / 이용자가 자신의 API 키를 가져오는 방식)로 설정함으로써, 이용료는 무료라는 형태로 공개했습니다. 사내에서는 "공들여 만든 프로덕트를 왜 공짜로 만드는가"라는 반대 의견도 있었습니다. 그럼에도 불구하고 무료로 했습니다.

이유는 요구사항 정의라는 공정의 의미 자체가 변했기 때문입니다. AI가 정리와 문서화를 고속으로 수행하는 지금, 인간에게 남은 것은 **"무엇을 만들지 결정하는 것"**입니다. 요구사항 정의는 "정리하는 공정"에서 **"결단하는 공정"**으로 변했습니다. 그리고 이 결단은 더 이상 일부 전문가만의 것이 아닙니다. 사업 부문 담당자도, 경영자도, 사내 SE도, 전원이 "무엇을 만들 것인가"를 정의하는 상황에 놓여 있습니다.

요구사항 정의·설계는 민주화되어야 하는 공정이 되었다.

그렇다면, 그 민주화를 가로막는 장벽은 모두 제거해야 한다.

월간 과금이라는 진입 장벽을 남겨둔 채 "민주화"를 말하는 것은 모순됩니다. AI의 API 이용료는 사용자 스스로가 컨트롤할 수 있습니다.

그렇다면, 그 위에 얹는 플랫폼 이용료는 제로로 만든다. 말하는 것과 행동하는 것을 일치시킨다. 그것이 BYOK라는 선택이었습니다.

도구는 공기와 같아야 합니다. 비용도 락인 (Lock-in)도 의식하지 않고, 사용자가 "무엇을 만들 것인가"라는 결단에만 몰입할 수 있는 상태를 만드는 것. 3년에 걸쳐 도달한 답은, 시스템이나 노하우를 열심히 제공하는 것이 아니라, 그것들을 과거의 논의로서 두고, "본래의 가치 창조에 직면할 수 있는 토양을 만드는 것"이었습니다.

여기서의 배움 (＝이 기사의 결론)

• 생성형 AI가 해야 할 일은 "문서를 생성하는 것"이 아니라, "올바른 컨텍스트 (Context)를 수집하고, 올바른 스코프 (Scope)를 설정하는 메커니즘을 만드는 것"이었다.
• 요구사항 정의는 "정리하는 공정"에서 "결단하는 공정"으로 변했다.

돌이켜보면, 각 페이즈 (Phase)의 배움은 하나의 선으로 이어져 있었습니다.

사전 정보 (컨텍스트)가 모든 기점: 잡담이 섞인 텍스트에서 정밀도를 내기 위해서는 용어집·전제·업무 가설의 정리가 필수적이었다 (이후의 Rule 개념) -
코드베이스야말로 최상의 컨텍스트: 사람이 직접 정보를 받아쓰는 것보다, 기존 코드에서 역으로 찾아내는 것이 더 빠르고 정확했다 (이후의 코드 인덱스, 그리고 "골격은 코드 컨텍스트"로) -
노하우는 전개보다 축적에서: 회의적인 분위기 속에서는 에반젤리스트 (Evangelist) 중심으로 프롬프트 집합으로서 쌓아두는 것이 효과적이었다 -
AI가 빠를수록 병목은 상류로: 개발이 고속화된 결과, 요구사항 정의는 "문서 작성"에서 "스코프 설계"로 역할을 바꾸었다

생성형 AI를 "마법의 상자"로 기대하는 것이 아니라, 어떻게 올바른 컨텍스트를 전달하고 올바른 스코프를 설정하는 메커니즘을 만들 것인가.

하지만, 그 메커니즘을 논의하는 페이즈는 이미 끝났습니다. 지금은 "무엇을 만들 것인가"에 몰입하는 것이 중요합니다. 3년간의 실증을 통해, 이것이 핵심이라고 느낍니다.

이상입니다. 더 상세하게 이야기하려고 의욕적으로 썼지만, 생각보다 쓸 내용이 많아 상당히 생략되었습니다. 혹시 궁금한 점이나 더 자세히 알고 싶은 것이 있다면 꼭 알려주세요!

여기까지 읽어주셔서 감사합니다. 조금이라도 참고가 된다면 기쁘겠습니다!

GEAR.indigo Biz 는 BYOK로 무료로 사용할 수 있습니다

"회의 메모를 붙여넣기만 하면. 요구사항과 설계가 알아서 진행된다." —— 본 기사에서 쓴 "도구를 잊고, 결단에 집중하는" 상태를 꼭 직접 체험해 보세요.