안녕하세요. KT AX플랫폼본부에서 서비스 기획을 담당하고 있는 정우승입니다.
최근 몇 달 동안 B2C Agent App 서비스인 TOKI와 Cally, 그 안에서의 캐릭터 구현을 테스트해보기 위한 점성술사 웹페이지, 그리고 AX Catalog Portal 기획을 진행하며 AI와 Agent를 여러 방식으로 사용해보았습니다.
처음에는 AI를 정보를 다시 확인하거나 문서 초안을 만드는 도구로 사용했습니다. 하지만 실제 업무와 개인 프로젝트를 오가며 사용해보니, AI는 단순히 답변을 받는 도구를 넘어 기획 문서, 와이어프레임, 프로토타입, QA를 빠르게 왕복하게 하는 작업 도구가 될 수 있었습니다.
다만 AI를 많이 사용할수록 한 가지 문제도 분명해졌습니다. AI는 빠르게 결과를 만들지만, 문제와 기준이 충분히 정의되어 있지 않으면 그럴듯하지만 맞지 않는 결과 역시 빠르게 늘어납니다.
이번 글에서는 제 개인의 경험에서 AI를 기획에 활용하며
- 무엇이 빨라졌는지,
- 어디서 어려움을 겪었는지,
- AI의 결과물을 실제 기획 산출물로 쓰기 위해 어떤 구조가 필요했는지
를 정리해보겠습니다.
1. AI를 기획에 활용하게 된 배경
기획은 하나의 아이디어를 문서로 정리하는 일에서 끝나지 않습니다. 요구사항을 정의하고, 정책을 결정하고, 사용자 흐름과 화면을 설계한 뒤, 개발과 디자인이 같은 기준으로 이해할 수 있도록 전달해야 합니다.
이 과정에서 같은 내용이 여러 형태로 반복됩니다.
아이디어 → 요구사항 → 정책 → 사용자 흐름 → 화면 정의 → 와이어프레임 → 프로토타입 → 개발 인계 및 QA
문제는 산출물이 늘어날수록 해석도 쉽게 갈라진다는 점입니다. 문서에는 있지만 화면에는 없는 정책, 프로토타입에는 있지만 요구사항에는 없는 기능, 이전에 결정한 내용과 충돌하는 새로운 문구가 생길 수 있습니다.
AI는 이 과정의 속도를 높여주었습니다. 막연한 아이디어를 구조화된 문서로 옮기고, 화면으로 구현하고, 여러 관점에서 빠르게 검토할 수 있었습니다. 기획자도 실제로 동작하는 프로토타입을 만들어보고, 사용자 입장에서 흐름을 점검할 수 있었습니다.
하지만 AI가 만든 결과를 그대로 신뢰할 수는 없었습니다. 특히 여러 번의 수정과 확장 과정에서 AI는 이전 맥락을 놓치거나, 요청하지 않은 기능과 정책을 새로 만들기도 했습니다.
결국 중요한 것은 AI가 얼마나 많은 결과를 만들 수 있는지가 아니라, AI가 무엇을 기준으로 작업해야 하는지를 기획자가 명확히 정의하는 일이었습니다.
2. 만들어보며 확인한 AI의 장점과 한계
TOKI 프로토타입: 아이디어를 빠르게 보여주는 능력
TOKI 초기 버전에 대한 기술 검증 차원에서 Google AI Studio를 활용해 너디 프로토타입을 만들었습니다.
대화, 검색, 이미지 생성과 같은 AI 기반 기능을 빠르게 붙여볼 수 있었고, 별도의 복잡한 초기 설정 없이 작동하는 경험을 확인할 수 있었습니다. 아이디어를 문서로만 설명하는 대신 실제 화면으로 보여줄 수 있었기 때문에, 논의 과정에서 설명 비용도 줄일 수 있었습니다.
또한 Agent를 직접 구현하기 전에 사용자가 어떤 흐름으로 서비스를 사용할 수 있는지, 어느 정도의 경험까지 제공할 수 있는지를 빠르게 확인하는 데 도움이 되었습니다.
반면 세부 수정 단계에서는 한계도 빨리 드러났습니다. 하나를 고치면 다른 영역도 함께 바뀌었고, 구조를 제가 통제하기보다 AI가 만들어낸 결과를 따라가게 되는 순간도 있었습니다. 사용량 제한으로 충분한 반복 테스트가 어려운 경우도 있었습니다.
이 경험을 통해 초기 아이디어와 경험을 검증하는 단계에서는 AI 기반 프로토타입이 매우 유용하지만, 서비스 구조와 세부 정책을 정교하게 다듬는 단계에서는 별도의 기준과 검증 방식이 필요하다는 점을 배웠습니다.
점성술사 사이트: 낯선 기술 영역에 들어가는 경험
점성술 캐릭터를 구현하는 과정에서는 Python 계산 로직, Gemini 연동, 페이지 구성, Streamlit 배포를 연결해 실제 서비스 형태까지 만들어보았습니다.
대화를 통해 Python 코드의 초안을 만들고 수정할 수 있었고, 익숙하지 않은 기술 영역에서도 계산 로직과 화면 흐름을 하나의 서비스로 연결해보는 경험을 할 수 있었습니다.
다만 AI가 작성한 결과를 그대로 믿고 갈 수는 없었습니다. Python 코드 일부를 수정하는 과정에서 다른 기능이 달라지거나 사라지는 일이 있었고, 생성형 응답에는 비용도 발생했습니다. 특히 점성술 계산처럼 결과의 정확성이 중요한 영역에서는 AI의 답변과 계산 결과를 별도로 확인하고, 다른 모델이나 자료를 통해 교차 검증해야 했습니다.
AI는 낯선 기술의 진입 장벽을 낮춰주지만, 정확도와 운영 책임까지 대신 가져가지는 않는다는 점을 확인한 경험이었습니다.
Cally 프로토타입: 설득력 있는 화면과 구현 가능한 화면의 차이
개인 일정 관리 비서 Cally는 Figma Make를 활용해 AI 기반 캘린더 앱 프로토타입을 만들고, 그 위에서 기능 흐름을 반복 수정해보았습니다.
화면 전환, 초기 온보딩, 선택 흐름처럼 인터랙션이 중요한 UX를 빠르게 확인할 수 있었습니다. 대화형 수정 요청을 통해 시나리오를 점진적으로 바꾸고, 아이디어를 바로 화면으로 확인할 수 있다는 점도 강점이었습니다.
하지만 기능이 복잡해질수록 “보기 좋은 프로토타입”과 “실제로 구현 가능한 서비스”의 차이가 커졌습니다. 요청하지 않은 기능이 추가되기도 했고, 프로토타입을 개발 인계에 사용할 수 있는 피그마 산출물로 정리하려면 페이지별 정리와 구조화가 다시 필요했습니다.
디자인·프로토타입 생성 AI는 빠르게 설득 가능한 결과를 만드는 데 강하지만, 개발 인계 기준으로 사용하려면 기능과 정책을 다시 구조화하는 과정이 반드시 필요하다는 점을 배웠습니다.
3. AX Catalog Portal: 문서, 화면, QA를 연결하는 작업
AX Catalog Portal은 AX 상품, 제안서, 적용사례를 한곳에서 조회하고 등록·수정·승인할 수 있도록 기획한 내부 포털입니다.
이 프로젝트에서는 화면을 빠르게 만드는 것보다, 정책이 문서와 화면에서 일관되게 작동하도록 만드는 일을 더 중요하게 보았습니다.
예를 들어 등록·수정·비활성화는 승인 후 반영되고, 승인 대기 중인 수정안은 기존 Active 정보를 유지한 채 노출되도록 정책을 정의했습니다. Draft는 작성자에게만 보이고, Review 상태에서는 추가 수정이나 비활성화 요청을 할 수 없도록 했습니다.
Draft → Register Review → Active
Active → Editing → Edit Review → Active
Active → Deactivate Review → Deactivated
이 정책을 먼저 상태 흐름으로 정리한 뒤, 상품·제안서·적용사례의 목록, 상세, 등록·수정, 승인함 화면에 같은 기준으로 적용했습니다.
작업은 다음 순서로 진행했습니다.
요구사항 문서 → 정책 및 상태 정의 → IA·사용자 흐름 → 페이지별 요구사항 → 와이어프레임 → HTML 프로토타입 -> 자체 테스트를 통한 개선 loop
프로토타입을 만든 뒤에는 AI를 이용하여 상품 담당자, 영업사원, 운영자, 기획자, UX 담당자의 관점에서 사용성을 검토했습니다. 이 과정에서 승인 대기 상태의 액션 처리, 검색과 필터의 동작, 상세 화면에서 연결된 제안서·적용사례로 이동하는 흐름, 빈 상태 화면과 같은 문제를 확인하고 수정했습니다.
또한 프로토타입 화면의 URL에 맞춰 화면 설명과 정책을 보여주는 스토리보드형 화면도 만들었습니다. 이를 통해 화면 자체와 화면이 왜 그렇게 동작하는지에 대한 설명을 함께 검토할 수 있었습니다.
4. 기획 하네스가 필요했던 이유
AI를 사용하면서 반복적으로 마주한 문제는 산출물 사이의 싱크였습니다.
요구사항 문서가 수정되면 페이지 정의와 와이어프레임, 프로토타입도 함께 바뀌어야 합니다. 하지만 작업이 길어질수록 이전 결정이 묻히고, AI는 일부 정보만 참고한 채 새로운 내용을 제안할 수 있습니다.
그래서 기획 작업에도 하네스가 필요하다고 생각했습니다.
여기에서의 하네스는 AI를 제한하는 규칙 모음보단 프로젝트의 원본 자료, 결정사항, 정책, 산출물의 순서와 연결 관계를 정리해 AI와 사람이 같은 기준으로 작업할 수 있게 만드는 구조로 프로젝트의 원천 소스(Single Source of Truth), 최종 조율된 정책적 의사결정, 핵심 산출물 간의 연결 고리와 빌드 순서를 명확하게 엮어주어, AI와 인간 기획자가 조화롭게 협업하게 만드는 안전 가이드라인입니다.
기획 하네스에서는 다음을 분리해 관리하고자 했습니다.
원본 요구사항과 이후 확정된 결정사항
정책, 상태, 역할, 예외 처리 기준
확정된 내용과 아직 결정되지 않은 질문
산출물 간의 참조 관계
프로토타입의 구현 상태와 기획상 기대 동작
이 구조가 있으면 AI에게 “서비스 전체를 만들어 달라”고 요청하는 대신, “이 정책을 기준으로 이 화면의 상태와 예외 처리를 검토해 달라”는 식으로 작업을 더 작은 단위로 나눌 수 있습니다.
5. AI를 기획에 활용하며 지키려는 원칙
AI의 문제와 기획자의 문제는 다릅니다
AI는 주어진 문제를 빠르게 해결하려는 경향이 있습니다. 반면 기획은 답을 빨리 만드는 것보다, 어떤 문제를 풀어야 하는지 정의하고 다양한 상황에서 가장 적절한 해결 방법을 찾는 일에 가깝습니다.
기획자가 아직 정리하지 않은 문제를 AI가 대신 정의하게 두면, 서비스 맥락과 맞지 않는 기능이나 문서가 만들어질 수 있습니다. AI가 만든 결과가 자연스럽고 그럴듯해 보일수록 이 문제는 더 발견하기 어렵습니다.
산출물은 작게 만들고 검증합니다
한 번에 전체 기획서, 전체 화면, 전체 프로토타입을 생성하면 검토해야 할 범위도 함께 커집니다. 어디에서 문제가 생겼는지 찾기 어려워지고, 수정 과정에서 다른 기준도 흔들릴 수 있습니다.
그래서 정책 하나, 흐름 하나, 화면 하나처럼 작은 단위로 만들고 검증한 뒤 다음 단계로 넘기는 방식이 더 안정적이었습니다.
AI는 답변보다 질문을 정리할 때도 유용합니다. 특히 AI는 답을 만드는 것뿐 아니라, 빠진 결정사항과 모호한 질문을 찾는 데에도 도움이 됩니다.
제가 자주 사용하는 문장은 아래와 같습니다.
이해하셨나요? 이해하지 못한 부분이 있으면 진행하기 전에 질문해 주세요.
특히 급할수록 요구사항이 짧아져서 혼란을 주기 쉬운데 이 문장은 AI가 빈 부분을 임의로 채우기보다, 불명확한 지점을 먼저 드러내도록 만드는 데 도움이 되었습니다. 앞으로는 이런 확인 구조를 개인적인 프롬프트 습관에 두지 않고, 하네스 안의 기본 동작으로 만들고자 합니다.
6. 앞으로의 계획
AI를 더 많이 사용하는 것이 목표는 아닙니다. 기획자의 판단이 필요한 영역과 AI가 반복적으로 도울 수 있는 영역을 구분하고, AI가 만든 결과를 검증 가능한 작은 산출물로 남기는 것이 목표입니다.
앞으로는 다음을 더 보완하려 합니다.
요구사항, 정책, 화면, 프로토타입 간 싱크 검증
역할별 사용자 시나리오와 QA 체크리스트 정리
화면과 스토리보드를 함께 검토할 수 있는 구조 개선
AI가 임의로 가정하지 않도록 질문과 확인 절차 강화
개발 인계 전 AI 산출물의 검증 기준 정리: 다양한 사용자 페르소나를 이용한 검증 수단 등
AI는 기획자를 대신해 문제를 정의할 수는 없습니다. 하지만 잘 정의된 문제를 빠르게 구체화하고, 반복 검토를 돕고, 실제로 확인 가능한 결과물로 바꾸는 데는 분명히 도움이 됩니다.
결국 중요한 것은 AI에게 많은 일을 맡기는 것이 아니라, AI가 잘할 수 있는 범위 안으로 문제를 나누고 그 결과를 끝까지 검증하는 일이라고 생각합니다.
7. 마치며
AI는 앞으로 더 넓은 범위의 일을 수행하게 될 것입니다. 특히 업무의 많은 부분을 AI가 대신하게 되며, 기획 - 디자인 - 개발 간의 접점이 바뀔 수도 있다고 생각합니다.
각자의 역할에서 AI를 잘 활용하기 위한 고민에 있어서 기획 / 디자이너에겐 고민을 같이 사람의 시행착오를 참고하는 기회, 개발자에겐 기획자의 AI 이용 방식에 대해 이해하며 AI를 이용한 새로운 접점 및 워크플로우 설계 등에 도움이 되길 바랍니다.
긴 글 읽어주셔서 감사합니다.