AI 서비스 기획 직무를 준비하는 취업 준비생의 포트폴리오를 함께 점검하다 보면 화면 구성과 사용자 흐름은 잘 만들어져 있는데, 정작 AI가 예상과 다른 결과를 만들었을 때 어떻게 처리할 것인지가 빠져 있는 경우가 있습니다. 사용자가 질문을 입력하면 AI가 답변하고, 답변을 저장하거나 다시 생성하는 기능까지는 상세하게 기획되어 있지만 모델이 잘못된 정보를 생성했을 때 어떤 문구를 보여줄지, 근거가 부족한 질문에서는 어디까지 답변하게 할지, 같은 질문에 조금 다른 결과가 나와도 정상으로 볼 수 있는지는 정리되지 않은 식입니다. 일반적인 서비스 기획에서는 회원가입이 성공했는지, 결제가 정상적으로 끝났는지처럼 비교적 명확한 성공과 실패 조건을 정의할 수 있습니다. 하지만 생성형 AI 서비스에서는 같은 입력에도 출력이 달라질 수 있고, 문법적으로 자연스러운 답변이 사실과 다른 경우도 있습니다. OpenAI도 생성형 AI 시스템은 출력 변동성이 있기 때문에 기존 소프트웨어 테스트만으로는 충분하지 않으며, 실제 사용 상황을 반영한 평가를 반복적으로 설계해야 한다고 설명합니다.
데이터에서도 차이가 나타납니다. 일반 서비스에서는 상품명과 가격, 사용자 정보처럼 시스템에 저장된 값을 정확하게 보여주는 것이 중심이라면 AI 서비스에서는 모델이 어떤 문서와 데이터를 참고하고, 오래된 정보와 최신 정보를 어떻게 구분하며, 정보가 부족한 상황에서 무엇을 답하지 않아야 하는지까지 기획 범위에 포함될 수 있습니다. Google Cloud 역시 생성형 AI에서 입력 데이터의 품질과 정확성이 결과에 직접적인 영향을 줄 수 있고, 모델이 그럴듯하지만 사실과 다른 내용을 생성할 가능성이 있음을 명시하고 있습니다. 이 때문에 AI 서비스 기획자는 화면과 기능 요구사항만 작성하는 역할로 준비하기 어렵습니다. 모델이 무엇을 잘하고 어떤 상황에서 흔들리는지 이해해야 하며, 서비스가 사용할 데이터의 범위와 품질을 정의하고, 출시 전후에 AI 결과를 어떤 기준으로 평가할지도 함께 설계할 필요가 있습니다. AI 서비스 기획이 일반 서비스 기획과 가장 크게 다른 점은 기능이 정상적으로 동작하는지만 보는 것이 아니라 모델과 데이터의 불확실성을 제품 안에서 어떻게 통제하고 평가할 것인지까지 기획해야 한다는 점입니다.
이번 글에서는 AI 서비스 기획 직무의 차이를 모델, 데이터, 평가 세 가지 기준으로 나누어 정리하겠습니다.
모델은 정해진 기능을 실행하는 대상이 아니라 결과의 범위와 한계를 함께 설계해야 하는 요소입니다
- AI 서비스 기획에서는 모델이 할 수 있는 일과 하면 안 되는 일을 먼저 구분할 필요가 있습니다
일반 서비스에서는 버튼을 누르면 어떤 API가 실행되고 어떤 화면으로 이동하는지 비교적 명확하게 정의할 수 있습니다. AI 서비스에서는 모델이 사용자의 자연어를 해석하기 때문에 예상하지 못한 표현과 질문이 계속 들어올 수 있습니다.
모델 관점에서는 다음 내용을 기획 단계에서 연결할 수 있습니다.
- 서비스가 모델에 맡길 업무 범위를 구분합니다.
- 모델이 직접 답변할 수 있는 질문 유형을 정리합니다.
- 근거가 부족한 경우의 응답 방식을 정의합니다.
- 민감하거나 서비스 범위를 벗어난 요청의 처리 기준을 구분합니다.
- 답변 형식과 길이, 반드시 포함해야 하는 내용을 정합니다.
- 잘못된 결과가 실제 실행으로 이어지지 않도록 승인 단계를 나눕니다.
예를 들어 여행 추천 AI라면 여행지를 추천하는 것과 실제 항공권을 구매하는 것은 전혀 다른 수준의 기능입니다. 추천 결과는 사용자가 다시 판단할 수 있지만 결제와 예약은 실제 행동으로 이어지기 때문에 더 강한 검증과 확인 과정이 필요합니다. 따라서 AI 서비스 기획에서는 기능 목록보다 먼저 모델에게 어느 수준의 판단과 실행 권한을 줄 것인지를 구분하는 작업이 중요합니다.
- 일반 기능과 AI 기능은 결과의 확정성에서 차이가 있습니다
일반적인 기능은 정해진 입력과 비즈니스 로직에 따라 예상한 결과가 나오는지를 중심으로 검증할 수 있습니다. AI 기능은 내용이 매번 완전히 같지 않아도 목적을 충족할 수 있기 때문에 결과 기준을 다르게 설정해야 할 수 있습니다.
- 일반 기능의 성공 기준: 요청한 기능이 정확하게 실행되고 지정된 결과가 반환됩니다.
- AI 요약 기능의 성공 기준: 표현은 달라도 핵심 내용과 중요한 사실이 유지되어야 합니다.
- AI 추천 기능의 성공 기준: 하나의 정답보다 사용자 조건과 실제 선택 목적에 적합한 후보를 제공해야 합니다.
- AI 상담 기능의 성공 기준: 필요한 정보를 제공하면서도 근거가 없는 내용을 확정적으로 추가하지 않아야 합니다.
- AI 에이전트의 성공 기준: 답변뿐 아니라 필요한 도구 선택과 실행 순서까지 올바르게 수행해야 합니다.
이런 차이를 이해하면 요구사항도 항상 같은 문장을 출력한다는 방식보다 반드시 지켜야 하는 결과와 허용 가능한 변동 범위를 나누는 방식으로 작성할 수 있습니다. 기획자는 AI가 매번 조금 다르게 말해도 괜찮은 부분과 절대로 달라지면 안 되는 부분을 구분할 필요가 있습니다.
- 모델 선택은 최신 모델을 고르는 것보다 서비스 조건에 맞게 비교하는 과정이 중요합니다
AI 서비스 기획 포트폴리오를 보면 가장 성능이 좋은 모델을 사용했다는 내용을 강조하는 경우가 있습니다. 하지만 실제 제품에서는 품질뿐 아니라 응답시간과 비용, 입력 길이, 구조화된 출력, 도구 연결 여부 등 여러 조건을 함께 고려할 필요가 있습니다.
모델 선택 과정에서는 다음 내용을 비교할 수 있습니다.
- 실제 서비스에서 자주 발생할 질문으로 품질을 비교합니다.
- 사용자가 기다려야 하는 응답시간을 확인합니다.
- 입력과 출력량에 따라 비용이 어떻게 달라지는지 계산합니다.
- 필요한 언어와 도메인에서 결과 차이를 살펴봅니다.
- JSON이나 특정 형식의 출력을 안정적으로 제공하는지 확인합니다.
- 모델을 변경했을 때 기존 핵심 질문의 결과가 유지되는지 재검증합니다.
예를 들어 고객 문의를 짧게 분류하는 기능과 복잡한 계약 문서를 검토하는 기능에 반드시 같은 모델을 사용할 필요는 없습니다. 전자는 응답속도와 비용이 더 중요할 수 있고, 후자는 긴 문맥과 복잡한 조건을 처리하는 품질이 더 중요할 수 있습니다. 이런 비교 과정이 있으면 AI 서비스 기획자는 모델 이름을 나열하는 사람보다 제품 목적에 맞춰 품질과 비용, 속도의 우선순위를 결정한 사람으로 설명될 수 있습니다.
- AI UX는 성공 화면보다 실패와 불확실성을 어떻게 보여줄지도 설계해야 합니다
일반 서비스에서는 시스템 오류가 발생하면 오류 메시지나 재시도 버튼을 제공하는 방식으로 대응할 수 있습니다. AI 서비스에서는 시스템은 정상인데 답변 품질이 부족한 상황이 발생할 수 있기 때문에 실패의 종류를 더 세밀하게 나눌 필요가 있습니다.
- 시스템 오류 상태: 모델 호출이나 서버 연결 자체가 실패했으므로 기술적인 재시도 흐름이 필요합니다.
- 근거 부족 상태: 서비스가 보유한 정보만으로 정확하게 답하기 어렵다는 사실을 사용자에게 전달할 수 있습니다.
- 부분 응답 상태: 일부 질문에는 답할 수 있지만 전체 판단에는 정보가 부족한 상황을 구분합니다.
- 높은 위험의 결과: 의료·금융처럼 중요한 판단으로 이어질 경우 사람 확인이나 추가 절차를 포함할 수 있습니다.
- 실행 전 확인 상태: AI가 외부 도구를 이용해 실제 변경을 수행하기 전에 사용자 승인을 받도록 구성할 수 있습니다.
이런 구분이 있으면 AI가 항상 정답을 제공하는 것처럼 보이는 UX를 피할 수 있습니다. AI 서비스 기획에서 중요한 것은 결과가 좋을 때의 화면뿐 아니라 결과를 믿기 어려운 순간에도 사용자가 다음 행동을 판단할 수 있게 만드는 경험입니다.
데이터는 단순한 서비스 저장정보에서 AI가 무엇을 사실로 판단할지 결정하는 영역까지 확장됩니다
- AI 서비스에서는 모델과 함께 어떤 데이터를 사용할 것인지가 제품 기능을 결정합니다
생성형 AI 서비스라고 하면 모델과 프롬프트를 먼저 생각하기 쉽습니다. 하지만 기업 내부정보나 특정 산업의 지식을 정확하게 답해야 하는 서비스에서는 모델보다 어떤 데이터를 연결하는지가 더 중요한 문제가 될 수도 있습니다.
데이터 기획에서는 다음 내용을 함께 볼 수 있습니다.
- 서비스가 사용할 공식 데이터와 참고 데이터를 구분합니다.
- 최신 정보와 폐기된 정보를 나눕니다.
- 같은 내용이 서로 다른 문서에서 충돌하지 않는지 확인합니다.
- 사용자별로 볼 수 있는 데이터 범위를 구분합니다.
- 개인정보와 내부 기밀의 사용 기준을 정의합니다.
- 데이터가 변경되었을 때 AI에 언제 반영되는지 정합니다.
예를 들어 사내 규정을 답하는 AI에 2025년과 2026년 규정 문서가 동시에 남아 있다면 모델 성능이 좋아도 잘못된 결과가 나올 수 있습니다. 이 경우 문제는 모델 자체가 아니라 어떤 문서를 최신 기준으로 사용할지 정하지 않은 데이터 설계에 있을 수 있습니다. 따라서 AI 서비스에서 데이터는 개발팀이 나중에 붙이는 기술 요소가 아니라 서비스가 어떤 정보를 사실로 간주할지 결정하는 기획 요소가 됩니다.
- 일반 서비스 데이터와 AI용 데이터는 사용되는 방식에서 차이가 있습니다
일반 서비스에서도 데이터 정확성과 보안은 중요합니다. AI 서비스에서는 같은 데이터가 검색과 생성, 판단과 평가에 직접 사용될 수 있기 때문에 활용 단계가 더 많아질 수 있습니다.
- 일반 서비스 데이터: 화면에 보여줄 값과 기능 실행에 필요한 정보를 저장하고 조회합니다.
- 검색용 데이터: 사용자 질문과 관련된 문서와 정보를 찾는 데 활용됩니다.
- 콘텍스트 데이터: 사용자의 현재 상황이나 이전 기록을 AI가 답변에 반영할 때 사용됩니다.
- 평가 데이터: 모델과 프롬프트 변경 전후 품질을 비교하는 기준으로 사용됩니다.
- 운영 데이터: 실제 사용자 질문과 실패 사례를 분석해 개선 우선순위를 만드는 데 활용됩니다.
이 구조를 이해하면 AI 서비스에서 데이터가 필요하다는 말을 단순 수집 요구로 끝내지 않을 수 있습니다. 어느 단계에서 어떤 목적으로 사용할 것인지와 해당 데이터가 잘못되었을 때 어떤 결과가 발생할지까지 구분할 수 있습니다.
- 데이터 기획에서는 수집보다 품질과 갱신 기준까지 연결해야 합니다
AI 서비스 기획 포트폴리오에서 사내 문서를 RAG에 연결했다는 내용을 자주 볼 수 있습니다. 하지만 실제 서비스에서는 문서가 몇 개 있는지보다 어떤 문서를 신뢰할 수 있고 얼마나 빠르게 최신 상태를 유지할 수 있는지가 중요합니다.
데이터 기획에서는 다음 내용을 포함할 수 있습니다.
- 문서를 관리하는 부서와 책임 범위를 구분합니다.
- 작성일과 마지막 갱신 시점을 기록합니다.
- 폐기된 문서와 현재 기준 문서를 분리합니다.
- 동일 주제에서 서로 다른 기준이 나타나는지 확인합니다.
- 검색 결과에 문서명과 날짜 같은 출처를 유지합니다.
- 데이터 갱신 이후 주요 질문 결과를 다시 확인합니다.
예를 들어 상품 정책이 변경되었는데 기존 문서가 검색에서 계속 상위에 나오면 AI가 오래된 내용을 답할 수 있습니다. 이 경우 모델을 바꾸는 것보다 데이터 갱신 정책과 검색 기준을 수정하는 것이 우선일 수 있습니다. 이런 경험이 포트폴리오에 포함되면 기획자가 단순히 AI 기능 아이디어를 제안한 것이 아니라 서비스가 참고하는 정보의 신뢰도까지 설계했다는 점을 보여줄 수 있습니다.
- 데이터 문제와 모델 문제를 구분해야 개선 방향도 달라집니다
AI가 틀린 답을 만들면 프롬프트부터 수정하거나 더 좋은 모델을 적용하고 싶어질 수 있습니다. 하지만 필요한 정보 자체가 없거나 오래된 데이터를 제공하고 있다면 모델 변경으로 문제를 해결하기 어렵습니다.
- 데이터 부재: 사용자가 요청한 내용을 판단할 정보가 서비스 안에 존재하지 않습니다.
- 검색 실패: 필요한 정보는 존재하지만 시스템이 적절한 문서를 찾지 못했습니다.
- 데이터 충돌: 두 개 이상의 문서가 서로 다른 기준을 제시하고 있습니다.
- 모델 해석 실패: 정확한 정보가 제공되었지만 모델이 의미를 잘못 이해했습니다.
- 출력 정책 실패: 사실은 맞지만 서비스에서 요구한 형식이나 표현 기준을 지키지 못했습니다.
이 구분이 가능하면 개발팀에 단순히 AI 답변이 이상하다고 전달하는 대신 어느 단계에서 문제가 발생했는지를 더 구체적으로 설명할 수 있습니다. AI 서비스 기획에서는 모델을 평가하는 능력뿐 아니라 모델이 잘못되기 전에 데이터 단계에서 무엇이 잘못되었는지 찾는 능력도 중요합니다.
평가는 개발이 끝난 뒤 확인하는 절차에서 AI 서비스의 성공 기준을 만드는 영역으로 확장됩니다
- AI 기능은 기획 단계에서부터 어떤 결과를 성공으로 볼지 정의할 필요가 있습니다
일반 서비스에서는 요구사항대로 기능이 구현되면 개발 완료 여부를 비교적 명확하게 판단할 수 있습니다. AI 서비스에서는 답변이 생성되었다는 사실만으로 기능 완료라고 보기 어렵습니다.
평가 설계에서는 다음 내용을 연결할 수 있습니다.
- 실제 사용자 상황을 반영한 테스트 질문을 구성합니다.
- 반드시 맞아야 하는 핵심 질문을 별도로 구분합니다.
- 서비스가 답하지 않아야 하는 질문도 포함합니다.
- 정확성과 관련성, 완전성 같은 평가 기준을 나눕니다.
- 사람의 판단이 필요한 주관적인 품질 항목을 구분합니다.
- 모델이나 프롬프트 변경 전후 같은 질문으로 다시 비교합니다.
OpenAI의 평가 가이드 역시 실제 사용 환경과 가까운 task-specific 평가를 만들고, 개발 초기부터 지속적으로 평가하며, 운영 로그에서 새로운 테스트 사례를 확보하는 방식을 권장합니다. 즉 AI 서비스에서 평가는 개발 마지막에 QA팀이 하는 절차만이 아닙니다. 기획자가 어떤 결과를 출시 가능한 품질로 볼 것인지 정의하는 과정부터 평가가 시작될 수 있습니다.
- 일반 기능 QA와 AI 품질 평가는 확인하는 대상에서 차이가 있습니다
AI 서비스에서도 로그인과 결제, 화면 이동처럼 일반적인 기능은 기존 QA 방식으로 테스트할 수 있습니다. 하지만 생성된 답변과 에이전트의 행동은 추가적인 평가 기준이 필요합니다.
- 기능 QA: 버튼과 API, 화면 이동이 요구사항대로 정상 동작하는지 확인합니다.
- 관련성 평가: 사용자의 질문에 필요한 내용을 직접적으로 답하고 있는지 살펴봅니다.
- Groundedness 평가: 답변이 제공된 문서나 데이터에 근거하고 있는지 확인합니다.
- 완전성 평가: 사용자가 필요로 하는 핵심 정보를 빠뜨리지 않았는지 확인합니다.
- 에이전트 프로세스 평가: 필요한 도구를 올바르게 선택하고 적절한 순서로 실행했는지 확인합니다.
Microsoft Foundry의 현재 에이전트 평가 체계에서도 최종 결과의 Task Completion, Relevance, Groundedness 같은 항목과 Tool Selection, Tool Call Accuracy, Tool Output Utilization 같은 실행 과정 평가를 나누어 다룹니다. 이 차이를 이해하면 AI 서비스 평가가 답변이 괜찮아 보인다는 감각적인 판단에서 벗어나 구체적인 제품 기준으로 발전할 수 있습니다.
- 실제 사용자 로그와 실패 사례가 다음 평가 데이터가 되어야 합니다
서비스 출시 전에 기획자가 예상한 질문만 테스트하면 실제 사용자 행동을 모두 반영하기 어렵습니다. 운영이 시작되면 짧은 질문과 모호한 표현, 오타, 여러 요구가 한 문장에 섞인 질문처럼 예상하지 못한 입력이 생길 수 있습니다.
운영 이후에는 다음 내용을 평가 과정에 포함할 수 있습니다.
- 반복적으로 실패하는 질문을 수집합니다.
- 실패 원인을 데이터와 검색, 모델, 정책 문제로 분류합니다.
- 중요한 실패 사례를 테스트 셋에 추가합니다.
- 개선 이후 동일한 질문에서 결과가 달라졌는지 확인합니다.
- 새 모델 적용 전에 기존 실패 사례를 다시 테스트합니다.
- 정량 평가와 실제 사용자 피드백을 함께 비교합니다.
OpenAI의 현재 평가 지침도 개발과 운영에서 로그를 충분히 남기고, 실제 사용 분포를 반영한 사례를 평가 데이터로 확장하며, 평가를 일회성 과정이 아니라 지속적인 개선 과정으로 운영할 것을 강조합니다. 이런 경험이 있으면 AI 서비스 기획 포트폴리오에서 서비스를 기획했다는 결과보다 사용자 실패 사례를 수집하고 다음 개선 기준으로 연결한 과정을 보여줄 수 있습니다.
- 평가 결과는 점수를 높이는 것보다 다음 제품 결정을 만드는 데 사용되어야 합니다
AI 평가를 시작하면 정확도나 관련성처럼 여러 지표를 만들 수 있습니다. 하지만 평가 점수가 높아졌다고 해서 무조건 좋은 서비스가 되는 것은 아닙니다.
- 품질은 좋아졌지만 응답이 느려진 경우: 품질과 사용자 대기시간 사이의 우선순위를 판단할 필요가 있습니다.
- 정확도는 높지만 비용이 크게 늘어난 경우: 실제 서비스 가치와 운영비용을 함께 비교해야 합니다.
- 특정 질문에서만 오류가 발생하는 경우: 전체 모델 변경보다 해당 데이터나 프롬프트를 조정하는 방법이 적합할 수 있습니다.
- 자주 사용되는 핵심 질문에서 실패하는 경우: 전체 평균 점수가 높아도 개선 우선순위를 높게 볼 수 있습니다.
- 새 모델에서 기존 기능이 악화된 경우: 이전 평가 결과를 기준으로 회귀 여부를 확인할 수 있습니다.
AI 서비스 기획자는 평가 도구를 직접 개발하는 사람이 될 필요는 없습니다. 다만 어떤 지표가 서비스 성공과 연결되는지, 어느 실패를 먼저 개선해야 하는지, 품질과 속도·비용 사이에서 어떤 선택이 필요한지를 판단할 수 있어야 합니다.
- conclusion
AI 서비스 기획 직무가 일반 서비스 기획과 다르다고 해서 기존 기획 역량이 필요 없어지는 것은 아닙니다. 사용자 문제를 정의하고 서비스 흐름을 설계하며 요구사항과 정책을 문서화하는 기본 역량은 그대로 중요합니다. 달라지는 부분은 그 위에 모델과 데이터, 평가라는 새로운 변수가 추가된다는 점입니다. 모델에서는 어떤 AI를 사용할 지보다 어떤 일을 맡기고 어느 수준까지 결과를 신뢰할 것인지를 정의해야 합니다. 같은 입력에도 출력이 달라질 수 있기 때문에 허용 가능한 변동과 반드시 지켜야 하는 기준을 구분하고, 실제 행동으로 이어지는 기능에서는 사람이 확인해야 할 지점도 설계할 필요가 있습니다. 데이터에서는 서비스가 어떤 정보를 사실로 사용할지와 그 정보가 얼마나 최신이고 신뢰할 수 있는지를 관리해야 합니다. AI 결과가 잘못되었을 때 모델을 교체하기 전에 데이터가 없었던 것인지, 오래된 정보가 사용된 것인지, 검색 과정에서 필요한 정보를 찾지 못한 것인지를 나눌 수 있어야 합니다.
평가에서는 개발이 끝난 뒤 결과를 몇 번 확인하는 방식으로는 부족합니다. 실제 사용 상황을 반영한 질문을 만들고 모델과 프롬프트, 데이터가 변경될 때 같은 기준으로 다시 비교해야 합니다. 현재 주요 AI 개발 플랫폼들도 생성 결과의 관련성이나 Groundedness뿐 아니라 에이전트의 도구 선택과 실행 과정까지 평가하는 구조를 제공하고 있습니다.
최종적으로 확인할 항목은 다음과 같습니다.
- AI가 담당할 업무와 사람이 판단할 업무를 구분할 수 있는지 확인합니다.
- 모델 결과에서 허용할 수 있는 변동과 허용하기 어려운 오류를 나눌 수 있는지 살펴봅니다.
- 서비스가 사용할 데이터의 출처와 최신성 기준을 정의했는지 확인합니다.
- 데이터 문제와 모델 문제를 구분하는 기준이 있는지 점검합니다.
- 실제 사용 상황을 반영한 평가 질문과 성공 기준을 만들었는지 살펴봅니다.
- 모델과 프롬프트 변경 이후 같은 조건으로 다시 평가했는지 확인합니다.
AI 서비스 기획 직무 준비 흐름은 다음과 같이 연결할 수 있습니다.
- conclusion일반 서비스 기획 기초 → 사용자 문제 정의 → AI 적용 필요성 판단 → 모델 특성과 한계 이해 → AI 기능 성공·실패 기준 정의 → 서비스 데이터 구조 파악 → RAG와 검색 구조 이해 → 데이터 출처와 권한 기준 설정 → 실패 시나리오 설계 → 평가 질문 구성 → 품질 지표 정의 → 사용자 로그 분석 → 모델·데이터·검색 문제 분리 → 개선 우선순위 결정 → 재평가 → 기획 문서와 포트폴리오 연결
결국 AI 서비스 기획자에게 필요한 것은 개발자처럼 모델을 직접 학습시키는 능력이 아닙니다. 모델에서는 AI의 가능한 행동과 한계를 제품 요구사항으로 바꾸고, 데이터에서는 AI가 사용할 정보와 신뢰 기준을 설계하며, 평가에서는 실제 사용자에게 제공할 수 있는 품질 수준을 결정할 수 있어야 합니다. 이 세 영역이 기존 서비스 기획 역량 위에 연결되어 있다면 단순히 AI 기능을 넣은 서비스를 제안하는 수준을 넘어, 실제 운영 과정에서 발생할 문제와 개선 기준까지 고려한 AI 서비스 기획 경험으로 포트폴리오와 면접에서 설명할 수 있습니다.