[A-S01-04] 지난 3회차 포스트(A-S01-03)를 올린 이후 동료들과 AI 요구사항 정의 프로세스를 실제 프로젝트에 적용하며 어떤 실패 리포트가 도출되었는지 공유하는 시간을 가졌습니다. 이 리포트를 바탕으로 AI 기획 실전 전략이 수립되기 때문입니다.
동료들이 공유해준 실패사례는 대부분이 우리가 이 실험(AI를 통해 빠르게 프로토타입을 만들고 설계에서 구현까지 갈 수 있는 발판을 마련하는 것)을 시작하기 전부터 우려하던 사항이었습니다. 여러분도 느끼고 계시겠지만, “AI가 알아서 다 해주겠지”라는 생각은 실패로 가는 지름길입니다. 그럼 AI 활용 단계에서 실제 현장이 맞닥뜨린 ‘실패의 기록’을 공유합니다.
1. AI의 ‘기억상실’과 작업 맥락의 구조화
AI와 대화가 길어지면 어느 순간 AI가 앞선 맥락을 놓치고 처음부터 다시 작업을 시작해버리는 현상이 발생합니다. 이런 부분에서 AI 기획 실전 전략이 가장 필요하다는 것이 가장 강하게 느껴집니다. 그만큼 가장 허탈하고도 쎄한 느낌이 찾아드는 순간입니다. ‘지금까지 한거 다 어떻게 된거지?’ 실제로 이런 일이 빈번하기 때문에 동료들은 이런 실패리포트를 공유해주었습니다.
- 실전 솔루션 A: 작업 계획과 맥락, 후속 체크리스트를 매 단계마다 자동으로 구조화하도록 설정합니다. AI가 갈 길을 잃지 않도록 이정표를 계속 박아주는 것이 ‘기억상실’을 막는 핵심입니다. AI의 실수가 확 줄어듭니다. 프롬프트 방법론에 포함시키기에 충분히 값어치가 있는 부분입니다.(AI 기획 실전 전략 A)
2. “검증용 AI”를 따로 두어야 하는 이유
하나의 AI에게 요구사항 정의부터 기능 목록 추출까지 다 맡기면, 정작 무엇이 누락되었는지 AI 스스로 판단하지 못하는 상황이 생깁니다. 이런 이유 때문에 우리는 검증 AI를 따로 둘 생각이었습니다. 그러나 실제로 검증 AI와 함께 일해본 적이 없었기 때문에 어떤 일들이 일어날지 몰랐습니다. 하지만 오늘 어떤 일이 일어났는지 실제 사례를 전해들을 수 있었습니다. 이 사례는 AI 기획 실전 전략을 수립함에 있어 가장 중요한 부분이 되었습니다. AI 시대에는 최종적으로 AI가 수행한 일에 대한 완벽한 신뢰가 생기기 전에는 검증과 테스트에 대한 방법론과 메커니즘이 보강되어야만 하기 때문입니다.
- 실전 솔루션 B: 역할을 나눕니다. 메인 AI가 요구사항 기반의 리스트를 뽑으면, 검사용 AI가 원본 요구사항과 대조하여 누락된 항목이 없는지 체크리스트를 추출합니다. “검증 과정”을 분리하는 것만으로도 재작업 시간을 획기적으로 줄일 수 있었습니다. 이거 정말 가능할 것 같습니다.(AI 기획 실전 전략 B)
3. 유료 모델의 ‘포크레인’ vs 무료 모델의 ‘삽질’
실무진들의 공통된 의견은 “무료 버전으로는 업무 퀄리티를 담보하기 어렵다”는 것이었습니다. 무료 버전의 가장 큰 약점은 에이전트 수를 할당하기 어렵다는 것이고 처리량과 처리속도가 지극히 제한적이라는 것이었습니다.
반면에 유료 모델은 복잡한 로직을 리액트(React) 코드로 변환해 10분 안에 실제 구동되는 프로토타입을 뽑아내는 ‘포크레인’ 수준의 성능을 보여줬습니다. 금액에 따라 차등적이지만 에이전트 수를 확보해 동시에 복잡한 여러 작업이 가능합니다. 일반적으로 개인이 지불해서 쓰기에 적합한 수준으로는 한번에 동시에 3개의 에이전트를 돌려서 각기 프로그래밍을 진행하는 것이 가장 효과적이었다고 합니다. 이 이상 넘어가면 사람이 AI가 어디서 무엇을 어떻게 하는지 운영하기가 어려서워, 수량적으로 고도화된 작업을 진행할 생각이라면 대시보드가 필요할 것 같다는 의견도 있었습니다.
그럼에도 불구하고 저는 **무료 모델(Gemini Free 등)**을 통해 어디까지 실체를 구현할 수 있는지 끝까지 기록해 보려 합니다. 도구의 성능 차이를 인정하되, ‘프롬프트 설계 능력’으로 그 간극을 메우는 과정을 증명하고 싶기 때문입니다. 제가 AI 무료모델과 함께 삽질하는 동안 동료들은 유료 모델을 통해 효율의 극대화를 추구할 것입니다. AI 기획 실전 전략을 다방면으로 수립하기 위해서입니다.
마무리: 결국 ‘프롬프트 디렉팅’ 싸움이 될듯
동료들의 AI 기획 실전 전략 수립사례에서 보듯, 백엔드 개발자조차 “앞단의 효율(AI 기반 프로토타이핑)이 극대화된다면 기꺼이 새로운 프레임워크를 수용하겠다”고 할 만큼 AI의 파급력은 이제는 거스를 수 없는 대세가 되었습니다. 사람이 일일이 설계하고 코딩했으면 수일이 걸렸을 일을 10분 안에 끝내니 대세가 안될수 없죠. 사실 이 10분도 스킬의 누적이나 프롬프트의 구조화 없이 달성한 시간이어서 실제 제대로 접근했다면 더 놀라운 결과를 얻었을 것입니다.
실제로 동료들이 AI를 통해 10분 만에 완성한 동작 페이지는 우리의 목적대로 ‘프로토타입은 충분히 가능하다’는 것을 입증했습니다. 소위 비싼 포크레인(AI)만 있다면 이제 정말 서비스 구현은 아이디어, 계획력, 그리고 자본에 달렸다고 해도 과언이 아닙니다. 프롬프트를 작성하는 기술력을 여기 이 포스트에서 다 공개할 수는 없는 것이 아쉽지만 이 놀라움만큼은 꼭 공유하고 싶습니다.
프롬프트 자체가 사람의 질문과 검증 로직인 것 같습니다. AI에게 모든 것을 맡기지 마세요. AI를 검증하고, 맥락을 가두고, 구조화하는 기획자의 디렉팅이 ‘진짜 실체’를 만들어야 합니다.
💡이 블로그의 다른 글
[A-S01-01] 공공 SI 프로젝트 산으로 가는 이유, 요구사항정의의 함정
[A-S01-02] AI 요구사항 정의 : 눈에 보이는 프로토타입으로 실체화하기
[A-S01-03] 요구사항 정의를 위한 AI 제미나이 협업 워크플로우
[A-S01-04] “기억상실”에 걸린 AI치료를 위한 AI 기획 실전 전략