02 실무형 애자일 기초

AI 서비스 기획을 공부하며 남기는 메모

by 김신영


"빠르게 바뀌는 환경에서는 완벽한 계획보다 빠른 실행과 피드백이 더 중요합니다."


최근 AI 서비스 기획을 공부하면서 가장 많이 접하는 키워드는 바로 애자일(Agile)입니다. 특히 AI 프로젝트는 기술 변화 속도가 빠르고, 사용자 요구사항이 자주 변경되기 때문에 전통적인 워터폴 방식보다는 유연하게 대응할 수 있는 방식이 요구됩니다. 서비스 기획자 또는 PM을 준비하는 분들을 위한 애자일 기초 지식을 소개합니다.




왜 AI 서비스에 애자일이 필수인가?

AI 서비스를 기획하고 운영하다 보면 예상치 못한 변수와 지속적인 요구사항 변경에 직면하게 됩니다. 모델 성능의 개선, 데이터 구조의 변화, 고객 피드백 반영 등으로 인해 ‘한 번에 완벽하게’라는 접근은 현실적으로 어려운 경우가 많습니다. 이런 상황에서는 반복적으로 실험하고, 빠르게 피드백을 반영해나가는 애자일 방식이 특히 효과적입니다.

기존의 워터폴 방식은 일련의 작업을 순차적으로 완성해 나가야 하기 때문에 중간 변경에 대한 유연성이 부족합니다. 반면, 애자일은 짧은 주기의 스프린트를 통해 결과물을 빠르게 만들고, 고객과의 상호작용 속에서 점진적으로 서비스를 완성해 나갈 수 있습니다. 이러한 점에서 AI 서비스 기획에 있어 애자일은 선택이 아닌 필수에 가깝습니다.


즉,

- AI 프로젝트는 특징: 모델 성능 개선, 요구사항 변화, 기술 불확실성

- 워터폴의 한계: 초기 요구 고정, 변화 대응 어려움

- 애자일의 강점: 짧은 사이클(스프린트), 고객 피드백 기반 개선

-> 유연한 반복과 협업 구조를 갖춘 애자일은 AI 서비스 기획자에게 필수입니다.




1. 워터폴 vs 애자일: 개발 방법론의 차이 이해하기


워터폴 방법론(Waterfall Model)


모든 작업이 순차적으로 단계별로 진행됩니다: 요구사항 정의 → 설계 → 구현 → 테스트 → 유지보수

각 단계가 끝나야 다음 단계로 넘어갈 수 있고, 중간에 되돌아가기 어렵습니다.


장점: 명확한 문서화, 일정 및 예산 계획이 용이함


단점: 변경에 취약, 최종 제품이 나오기까지 고객 피드백 반영이 어려움


AI 서비스와의 부적합성: AI 프로젝트는 반복적인 실험과 빠른 수정이 필수인데, 워터폴은 유연성이 부족합니다.


애자일 방법론(Agile Methodology)

짧은 주기(스프린트)로 반복적으로 개발하고, 피드백을 통해 개선해 나가는 방식입니다. 고객과의 긴밀한 소통을 중시하며, 요구사항의 변화도 반영할 수 있습니다.


장점: 빠른 피드백, 사용자 중심 설계 가능, 유연한 대응


단점: 팀 간 커뮤니케이션 미비 시 혼란 발생, 일정 예측 어려움


AI 서비스와의 적합성: 모델 성능 개선, 사용자 피드백 수렴, 반복 실험이 필요한 AI 서비스에는 최적화된 방식입니다.




2. 애자일의 기본 철학과 핵심 가치

애자일은 단순한 개발 방법론이 아닙니다. 그것은 ‘사람 중심의 일하는 방식’이며, 고객 가치를 최우선으로 여기는 철학에 기반을 두고 있습니다.


애자일 4대 핵심 가치(Agile Manifesto)


프로세스와 도구보다 개인과 상호작용


포괄적인 문서보다 작동하는 소프트웨어


계획을 따르기보다 변화에 대응


계약 협상보다 고객과의 협업


애자일 12가지 원칙 중 핵심 요약


고객 만족을 위한 조기 및 지속적인 소프트웨어 전달


변화하는 요구사항을 수용


동기 부여된 개인을 중심으로 프로젝트 구축


자주 작동하는 제품 제공


지속 가능한 개발 속도 유지


이러한 가치와 원칙은 AI 서비스를 기획할 때 더욱 강력한 무기로 작용합니다. 고객이 직면한 문제를 빠르게 정의하고, 기능 중심이 아닌 문제 해결 중심으로 사고하는 것이 애자일 철학의 핵심입니다.




3. 애자일 팀 구성과 역할 이해

AI 프로젝트는 다양한 전문성과 역할의 융합이 필요합니다. 따라서 애자일 팀도 이에 맞게 구성되어야 합니다.


주요 구성원 역할

Product Owner (PO): 제품의 목표와 방향 설정, 백로그 작성 및 우선순위 관리


Scrum Master: 팀이 애자일 프로세스를 잘 따를 수 있도록 지원하고 장애 요인을 제거


Development Team: 개발, 디자인, QA, 기획 등을 수행하는 실질적 작업 팀


기타 이해관계자

Stakeholder: 고객, 경영진 등 외부 요구를 가진 이들


AI 프로젝트에서 추가 고려할 역할: 데이터 엔지니어: AI 학습 데이터 전처리, 파이프라인 구축 ML 엔지니어/리서처: 모델 개발, 튜닝, 성능 개선


이처럼 기획자는 다양한 직군과 긴밀하게 협업해야 하며, 각 직무의 언어와 우선순위를 이해하는 것이 중요합니다.



4. 애자일 용어 정리: 실무에 꼭 필요한 개념들

애자일 방식에서는 일하는 단위를 명확하게 정의하고 이를 반복적으로 실행합니다. 실무에서 자주 접하는 개념을 정리해보겠습니다.


스프린트(Sprint): 2~4주 단위로 반복되는 개발 주기


제품 백로그(Product Backlog): 제품에 필요한 모든 기능 요구사항 목록 (PO가 관리)


스프린트 백로그(Sprint Backlog): 이번 스프린트에 수행할 작업 목록


스크럼(Scrum): 애자일 프레임워크 중 하나. 규칙과 회의 체계가 명확히 정리됨


일일 스크럼(Daily Scrum): 매일 15분 이내 진행되는 짧은 회의로 진행 상황 점검


회고(Retrospective): 스프린트 종료 후 팀 내 개선점 및 성과를 리뷰




5. 실무 흐름: 에픽 → 사용자 스토리 → 태스크

단계별 설명


에픽(Epic)

> 큰 사용자 요구사항의 묶음 (예: "AI 추천 엔진 고도화") 여러 개의 사용자 스토리로 나눌 수 있음


사용자 스토리(User Story)

> 한 명의 사용자 관점에서 기능 요구를 서술 형식.

사용자 스토리는 기능 중심이 아닌 ‘사용자 경험’ 중심으로 작성되어야 하며, 구체적인 테스트 기준을 함께 정의하는 것이 바람직합니다.


사용자 스토리 예시
“사용자로서, 내가 작성한 문장의 문맥 오류를 AI가 제안해줄 수 있어야 한다. 그래야 빠르게 문서를 완성할 수 있다.”


태스크(Task)

> 사용자 스토리를 실현하기 위한 실제 개발, 디자인, 테스트 작업 예: 모델 API 연동, 프론트엔드 결과 표시 UI 구현 등


테스트 케이스 작성

> 사용자 스토리가 충족되었는지를 검증하는 명확한 기준 제시

예: “3개의 문법 오류가 있는 문장을 입력했을 때, AI가 3가지 수정 제안을 보여준다.”




6. 스프린트 전체 프로세스 상세 흐름

애자일 팀은 일반적으로 2주 단위의 스프린트를 운영합니다. 이 과정은 다음과 같은 단계로 이루어집니다.


스프린트 계획 회의: 이번 스프린트의 목표와 범위를 정의하고, 제품 백로그에서 우선순위가 높은 항목을 선정합니다.


일일 스크럼 미팅: 매일 15분 이내로 진행 상황을 공유하며, 발생한 이슈를 논의합니다.


실제 개발 및 구현: 정의된 사용자 스토리와 태스크를 기반으로 개발이 이루어집니다.


스프린트 리뷰: 완성된 결과물을 공유하고, 이해관계자에게 피드백을 받습니다.


스프린트 회고: 팀 내부에서 잘된 점과 개선점을 정리하여 다음 스프린트에 반영합니다.


AI 프로젝트에서는 이 모든 과정이 일종의 ‘실험과 학습의 사이클’로 작동합니다. 그래서 회고의 중요성이 더욱 강조됩니다.




7. 협업을 돕는 애자일 도구들

JIRA: 이슈 트래킹 및 스프린트 관리, 스토리 포인트 관리 가능


Confluence: 기술 및 기획 문서 정리, 회의록 및 회고 내용 기록


Trello: 칸반 기반 프로젝트 보드, 소규모 팀에서 간단하게 사용 가능


Notion: 통합 협업 도구로 최근 스타트업에서 폭넓게 활용




마치며 : AI 서비스 기획에 애자일이 필요한 이유


AI 프로젝트는 명확한 정답이 없는 영역입니다. 고객의 피드백, 모델 성능 개선, 새로운 데이터 요구 등 변화에 유연하게 대응해야 하는 과제들이 수시로 발생합니다. 따라서 ‘완벽한 설계’보다 ‘빠른 실험과 반복’을 통해 방향성을 찾아가는 애자일 방식이 가장 적합합니다.


기획자 또는 PM은 애자일을 단순히 도구나 개발 방식이 아니라, 문제를 정의하고 팀을 리딩하며 고객 중심으로 의사결정하는 프레임워크로 이해해야 합니다.


읽어주셔서 감사합니다. 함께 고민하고 성장할 수 있기를 바랍니다. :)


keyword
작가의 이전글고객문제 발견 및 기회창출하기