B2B 프로덕트 디자이너가 AI 기획자가 되기까지
1편 AI 에이전트 기획이 뭔데?
어느 날 갑자기 AI 기획을 맡게 되었다
저는 B2B 프로덕트 디자이너였습니다. 사용자 리서치를 하고, 와이어프레임을 그리고, 인터랙션을 정의하는 일상이 익숙했죠. 그런데 어느 날, "우리 제품에 AI 에이전트 기획해야 할 것 같은데, AI TF에서 PM겸 디자인을 해줄 수 있어?
처음엔 막막했습니다.
"AI 에이전트가 정확히 뭐지? 챗봇이랑 뭐가 다른 거야?"
"화면 설계는 어떻게 하지? 버튼이 필요한가?"
"기존 기획 방식대로 플로우차트 그려도 되나?"
기존에 제가 알던 프로덕트 디자인 방법론은 AI 에이전트 앞에서 잘 작동하지 않았습니다. 사용자 여정(User Journey)을 선형적으로 그릴 수 없었고, 모든 예외 케이스를 미리 정의할 수도 없었습니다. AI는 스스로 판단하고 행동하는데, 제가 통제할 수 있는 건 제한적이었죠.
그래서 새로운 방식으로 접근해야 했습니다. 수많은 시행착오 끝에, AI 에이전트 기획은 '직원을 채용하고 교육하는 것'과 더 비슷하다는 걸 깨달았습니다. 화면을 설계하는 게 아니라, 판단 기준을 만들고, 업무 매뉴얼을 작성하고, 협업 구조를 설계하는 일이었습니다.
AI 에이전트란 무엇인가?
AI 에이전트는 사용자를 대신해 독립적으로 작업을 수행하는 시스템입니다. 단순한 챗봇이나 감정 분류기와 달리, LLM(대규모 언어 모델)을 사용하여 워크플로우의 실행을 관리하고 스스로 의사결정을 내린다는 점이 핵심입니다.
예를 들어, 고객 문의를 받으면 단순히 답변만 하는 것이 아니라 데이터베이스를 조회하고, 필요하면 다른 팀에 에스컬레이션하며, 상황에 따라 환불 처리까지 진행할 수 있습니다. 마치 숙련된 직원이 업무를 처리하듯이 말이죠.
기존 소프트웨어 기획과 무엇이 다른가?
AI 에이전트를 이해하려면 먼저 기존 소프트웨어와의 차이를 알아야 합니다.
실제 사례로 보는 기획 접근법의 차이
시나리오: 고객 환불 처리 시스템
기존 소프트웨어 방식의 기획:
기획자는 모든 경우의 수를 미리 정의해야 합니다.
IF 주문일자가 7일 이내 AND 제품 상태가 '미개봉'이면
→ 전액 환불 승인
ELSE IF 주문일자가 14일 이내 AND 제품 상태가 '개봉'이면
→ 80% 환불 승인
ELSE IF 주문일자가 30일 이내 AND 제품 상태가 '불량'이면
→ 담당자에게 에스컬레이션
ELSE
→ 환불 거절
AI 에이전트 방식의 기획:
모든 경우의 수를 코딩하는 대신, 원칙과 판단 기준을 제시합니다.
[환불 정책 원칙]
- 고객 만족을 최우선으로 하되, 회사 손실을 최소화한다
- 제품 상태, 구매 일자, 사유를 종합적으로 판단한다
- 명백한 고객 과실이 아니라면 유연하게 대응한다
[판단 프로세스]
1. 고객에게 주문번호, 환불 사유, 제품 상태를 질문한다
2. 주문 데이터베이스를 조회하여 구매 이력을 확인한다
3. 다음 기준으로 환불 가능 여부를 판단한다:
- 구매 후 7일 이내 + 미개봉 → 즉시 전액 환불
- 제품 불량 → 사진 요청 후 전액 환불
- 단순 변심이지만 14일 이내 → 부분 환불 제안
4. 판단이 애매한 경우(예: 고액 제품, 특이 사유) → 담당자 검토 요청
같은 "배송 중 파손" 케이스도:
기존 방식: 이 케이스를 예측하여 미리 규칙을 만들어놔야 함
AI 에이전트: "제품 불량에 준하는 상황"이라고 추론하여 처리
쉽게 비유하자면, 기존 소프트웨어가 정해진 항목을 하나씩 체크하는 '체크리스트'라면, AI 에이전트는 주어진 상황과 증거를 바탕으로 최선의 방법을 찾아나가는 '숙련된 수사관'과 같습니다.
AI 에이전트 구축의 3대 핵심 요소
에이전트를 구성하는 기본 뼈대는 다음 세 가지입니다.
1. 모델(Model)
에이전트의 추론과 의사결정을 담당하는 두뇌입니다. Claude, GPT 같은 LLM이 여기에 해당합니다.
2. 도구(Tools)
외부 시스템과 상호작용하기 위한 기능입니다. 데이터베이스 조회, API 호출, 이메일 발송 등이 도구에 포함됩니다.
3. 지시사항(Instructions)
에이전트가 어떻게 행동해야 하는지 정의하는 가이드라인입니다. 사람으로 치면 업무 매뉴얼이나 SOP(표준 운영 절차)에 해당합니다.
실전: AI 에이전트 구축 4단계 프로세스
성공적인 에이전트를 만들기 위해서는 단계적이고 반복적인 접근이 필요합니다.
1단계: 모델 선정 및 베이스라인 수립
처음에는 가장 성능이 뛰어난 모델로 프로토타입을 만들어 성능의 기준점을 잡습니다. 이후 성능이 확인되면 비용과 지연 시간을 줄이기 위해 점진적으로 더 작고 효율적인 모델로 교체하는 전략을 취합니다.
실무 팁: 처음부터 비용 효율적인 모델을 쓰려다가 성능이 안 나오면 "AI가 이 업무에 맞지 않나?"라는 오해가 생길 수 있습니다. 먼저 가능성을 검증한 후 최적화하세요.
2단계: 도구(Tool) 정의
도구(Tool)란 무엇인가?
도구는 AI 에이전트가 외부 세계와 상호작용할 수 있게 해주는 기능입니다. LLM은 본질적으로 텍스트를 생성하는 모델이지만, 도구를 통해 실제 시스템에 접근하고 행동할 수 있게 됩니다.
실무 예시로 이해하기:
고객 지원 에이전트를 만든다고 가정해봅시다. 에이전트는 다음과 같은 도구들이 필요합니다:
3단계: 지시사항(Instructions) 구성 - 에이전트의 업무 매뉴얼 만들기
지시사항이란?
지시사항은 에이전트에게 "어떻게 일해야 하는지" 알려주는 프롬프트입니다. 사람으로 치면 신입사원에게 주는 업무 매뉴얼이나 SOP(표준 운영 절차)와 같습니다.
지시사항의 품질이 에이전트의 판단력을 결정합니다. 같은 도구를 가지고도 지시사항이 잘 작성되었느냐에 따라 완전히 다른 결과가 나옵니다.
나쁜 예시:
이렇게 쓰면
"친절하게"가 구체적으로 뭘 의미하는지 모호합니다
언제 환불을 해야 하는지 기준이 없습니다
예외 상황에 어떻게 대응할지 알 수 없습니다
좋은 예시:
효과적인 지시사항 작성 5가지 핵심 원칙:
1. 기존 문서 활용하기
새로운 내용을 창작하기보다 기존 SOP, 고객 응대 스크립트, 정책 문서를 바탕으로 만드세요. 실제 직원들이 쓰는 매뉴얼이 가장 좋은 출발점입니다.
[기존 문서] "환불 정책: 구매 후 7일 이내 미개봉 제품 전액 환불"
[지시사항으로 변환] "주문일자를 확인합니다. 7일 이내이고 product_status가 'unopened'면 process_refund(amount=full_price)를 실행합니다"
2. 작업의 세분화
복잡한 업무를 작고 명확한 단계로 쪼개세요.
"고객 응대를 잘 해주세요"보다는 "1) 인사 → 2) 정보 확인 → 3) 문제 파악 → 4) 해결책 제시 → 5) 확인"처럼 구체적으로 나눕니다.
3. 구체적인 행동과 멘트 정의
"친절하게 응대"(X) → "고객님, 무엇을 도와드릴까요?"(O)
"환불 처리"(X) → "process_refund(order_id, amount) 도구를 실행한 후 '환불이 접수되었습니다. 3-5일 내 계좌로 입금됩니다'라고 안내"(O)
4. 예외 상황 캡처
정보가 없거나 예상 밖의 질문이 들어올 때 어떻게 할지 명시하세요.
- 주문번호를 3번 요청했는데도 제공하지 않으면 → "이메일로 문의해주세요"
- 정책에 없는 특이 케이스 → escalate_to_supervisor()
- 도구 실행이 실패하면 → "시스템 오류입니다. 잠시 후 다시 시도해주세요"
5. 프롬프트 템플릿 사용
매번 처음부터 새로 쓰지 말고, 공통 정책은 베이스 템플릿에 넣고 상황별 변수만 바꾸세요.
지시사항 작성은 프롬프트 엔지니어링입니다
결국 지시사항 작성은 에이전트에게 주는 프롬프트를 체계적으로 설계하는 작업입니다. 단, 일회성 프롬프트가 아니라 반복적으로 사용될 "표준 업무 지침서"를 만드는 것이라는 점이 다릅니다.
4단계: 오케스트레이션(Orchestration) - 에이전트들의 협업 구조 설계하기
오케스트레이션이란?
오케스트레이션(Orchestration)은 원래 오케스트라의 지휘를 뜻하는 말로, 여러 악기가 조화롭게 연주하도록 조율하는 것을 의미합니다. AI 에이전트에서는 여러 에이전트나 도구들이 협업하여 복잡한 작업을 수행할 수 있도록 워크플로우를 설계하는 것을 말합니다.
쉽게 말해, "누가, 언제, 무엇을 하고, 다음은 누구에게 넘길 것인가?"를 정하는 것입니다.
실무 예시: 고객 센터의 조직 구조처럼 생각하기
고객 센터를 떠올려보세요.
1차 상담원이 모든 문의를 받습니다
단순 문의는 바로 처리하고
기술적인 문제는 기술팀으로 연결하고
환불 요청은 결제팀으로 넘기고
해결 안 되는 문제는 매니저에게 에스컬레이션합니다
이것이 바로 오케스트레이션입니다.
먼저, 단일 에이전트로 시작하는 것이 좋습니다. 대부분의 경우 하나의 에이전트만으로도 충분합니다.
단일 에이전트로 시작하다가 멀티 에이전트가 필요해지는 순간이 존재하는데요.
아래 케이스가 발생한다면 조금씩 에이전트를 늘려가면 됩니다.
에이전트가 복잡한 지시사항을 제대로 따르지 못함
같은 실수를 반복함 (예: 항상 잘못된 도구를 선택)
응답 시간이 너무 오래 걸림
멀티 에이전트 패턴 선택하기
멀티 에이전트가 필요하다면 두 가지 패턴 중 선택합니다.
- 패턴 1: 관리자(Manager) 패턴 - 추천
고객 문의가 들어오면 관리자 에이전트가 먼저 받음
관리자가 문의 유형을 파악하여 적절한 전문 에이전트에게 전달
전문 에이전트가 작업 수행 후 결과를 관리자에게 반환
관리자가 고객에게 최종 응답
언제 사용해야 하나?:
명확하게 영역이 구분되는 작업들 (배송/결제/기술 등)
중앙 집중식 제어가 필요한 경우
대부분의 실무 상황에서 이 패턴을 추천합니다
패턴 2: 분산(Decentralized) 패턴
에이전트들이 서로 직접 통신하며 협업
관리자 없이 peer-to-peer로 작업 전달
언제 사용해야 하나?:
작업의 흐름이 예측 불가능하고 동적인 경우
에이전트 간 긴밀한 협업이 필요한 경우
구현과 디버깅이 어려우므로 꼭 필요한 경우만 사용
오케스트레이션 설계 원칙
작게 시작하기: 단일 에이전트 → 2-3개 에이전트 → 필요시 추가 확장
명확한 책임 분리: 각 에이전트의 역할이 겹치지 않도록
컨텍스트 전달 설계: 에이전트 간 어떤 정보를 넘겨줄지 미리 정의
실패 처리: 한 에이전트가 실패하면 어떻게 할지 계획
기획 시 반드시 고려해야 할 핵심 포인트
1. 가드레일(Guardrails) 설정
데이터 프라이버시, 안전성, 관련성 검증 등 다층적인 방어 메커니즘을 구축하여 에이전트가 예기치 못한 행동을 하지 않도록 제어해야 합니다.
2. 인적 개입(Human-in-the-loop)
에이전트가 스스로 판단하기 어려운 한계치에 도달하거나, 고액 결제 승인과 같은 고위험 작업을 수행할 때는 반드시 사람이 검토하는 단계를 포함해야 합니다.
3. 단계적 확장
처음부터 모든 것을 자동화하려 하기보다, 작은 유즈케이스부터 시작해 점진적으로 역량을 키워가는 것이 성공 확률이 높습니다.
전체 프로세스 정리: 신입 사원 교육하듯 접근하기
에이전트 기획은 마치 '신입 사원에게 업무 매뉴얼을 만들어주는 과정'과 비슷합니다.
유즈케이스 선정 및 검증: 기존의 규칙 기반 자동화로는 해결하기 어려웠던 복잡한 의사결정이나 비정형 데이터 처리가 필요한 영역을 식별합니다.
모델 선정 및 베이스라인 수립: 처음에는 가장 똑똑한 사원(고성능 모델)에게 일을 시켜보고 성능 기준점을 잡습니다.
도구 정의: 업무에 필요한 시스템 접근 권한과 기능을 정의합니다.
지시사항 구성: 구체적인 매뉴얼을 만들어 어떻게 일해야 하는지 알려줍니다.
오케스트레이션 설계: 일이 너무 많아지면 팀을 나누고(멀티 에이전트), 역할을 분담합니다.
가드레일 및 인적 개입 설계: 중요한 결정은 팀장의 승인을 받게 하는(인적 개입) 안전장치를 마련합니다.
이렇게 단계적으로 시스템을 정교화해 나가는 것이 AI 에이전트 구축의 핵심인 것 같습니다.
