기획 가이드: 개발자가 듣고 싶어 하는 AI 기획안, 챗봇을 넘어 AI 에이전트로

단순한 시나리오 봇을 넘어, 구글 Gemini 및 업스테이지 Solar 기반의 똑똑한 AI 에이전트를 기획하는 방법

목차

1. 1. 프롤로그: 왜 챗봇이 아니라 AI 에이전트인가?
2. 2. 정체성 정의: 결정론적 챗봇인가, 확률적 AI 에이전트인가?
3. 3. 지식 주입 방식: 학습이 아니라 그라운딩이다
4. 4. 답변 제어: 톤앤매너 대신 시스템 지시문과 온도 값
5. 5. 행동 능력: 말만 하는 챗봇에서 일하는 에이전트로
6. 6. 마치며: 사용자 여정에 따른 하이브리드 아키텍처 설계
7. 부록: 용어 팩트 체크 및 출처

1. 프롤로그: 왜 챗봇이 아니라 AI 에이전트인가?

기획자가 "우리도 AI 챗봇 하나 도입하죠"라고 제안할 때, 개발자는 난감해하곤 합니다. 기획자가 상상하는 것은 사람처럼 자연스럽게 대화하는 '자비스'지만, 개발자가 당장 떠올리는 것은 수많은 예외 처리가 필요한 '조건문 덩어리'일 수 있기 때문입니다.

성공적인 프로젝트를 위해서는 우리가 만들고자 하는 것이 과거의 단순 챗봇(Legacy Chatbot)인지, 아니면 구글의 제미나이(Gemini)나 업스테이지의 솔라(Solar)와 같은 추론 엔진을 탑재한 AI 에이전트(AI Agent)인지 명확히 정의해야 합니다.

이 글은 구글 클라우드 공식 문서와 국내 대표 AI 기업인 업스테이지의 개발자 가이드를 비교 분석하여, 기획자가 개발자와 오해 없이 소통하기 위한 전문적인 기획 가이드를 제시합니다.

2. 정체성 정의: 결정론적 챗봇인가, 확률적 AI 에이전트인가?

기획의 첫 단추는 시스템의 작동 방식을 결정하는 것입니다. 단순히 "똑똑한 챗봇"이 아니라, 어떤 메커니즘으로 답변을 생성할지 정의해야 합니다. 여기서 중요한 점은 우리가 흔히 말하는 '규칙 기반(Rule-based)'이라는 용어가 최신 생성형 AI 문서에서는 다르게 표현된다는 것입니다.

결정론적 시스템 (Deterministic System): 규칙 기반

우리가 흔히 고객센터에서 접해온 챗봇입니다. 구글의 공식 가이드에 따르면 이를 의도 분류(Intent Matching) 혹은 결정론적(Deterministic) 방식이라고 부릅니다. 또한 국내 업스테이지 공식 가이드 등에서는 LLM의 생성 능력과 구분하여 룰베이스(Rule-based) 로직 또는 애플리케이션 단의 하드 코딩으로 설명되기도 합니다.

1. 기획 가이드
2. 적용 대상: 금융 거래, 예약 변경 등 오류 무관용(Zero-Tolerance)이 필수적인 기능
3. 기획 의도: 100% 예측 가능한 결과와 리스크 관리가 필요함
4. 요청 예시: "이 프로세스는 LLM의 창의성보다는 의도 분류 방식을 사용하여 결정론적으로 처리해주세요."
5. [실무 참고] 개발자는 이렇게 말합니다
6. 현장 용어: 하드 코딩(Hard Coding), 시나리오 봇
7. 개발자 발화: "이건 하드 코딩된 룰베이스로 가는 게 안전합니다. 시나리오 뎁스(Depth)가 너무 깊어지면 관리가 안 됩니다."

확률적 시스템 (Probabilistic System): AI 에이전트

우리가 만들고 싶은 챗봇이 바로 AI 에이전트의 확률적 시스템입니다. 거대언어모델(LLM)이 문맥을 이해하고 스스로 답변을 생성합니다. 구글 공식 용어로는 생성형 AI 에이전트(Generative AI Agent)입니다. 업스테이지의 솔라(Solar) 문서에서는 이를 챗 모델(Chat Model) 혹은 지시 따르기(Instruction Following) 모델로 정의하며, 대화의 맥락을 이해하는 능력을 강조합니다.

1. 기획 가이드적용 대상: 사용자 질문 형태 예측 불가, 복잡한 상품 추천, 요약 업무
2. 기획 의도: 맥락 파악과 자연스러운 대화 연결이 중요함
3. 요청 예시: "고객의 모호한 질문을 처리하기 위해 제미나이(혹은 솔라) 모델을 활용하되, 답변의 일관성을 위해 프롬프트를 정교하게 설계합시다."
4. [실무 참고] 개발자는 이렇게 말합니다현장 용어: LLM(엘엘엠), 젠에이아이(GenAI)
5. 개발자 발화: "이건 LLM을 태워야 자연스럽습니다. 다만 답변의 일관성(Consistency)을 100% 보장하기는 어렵습니다."

3. 지식 주입 방식: 학습이 아니라 그라운딩이다

기획자들이 가장 많이 하는 오해가 "우리 회사 매뉴얼을 AI에게 학습시켜 주세요"라는 요구입니다. 개발자에게 '학습'은 모델의 뇌 자체를 뜯어고치는 엄청난 비용의 작업을 의미합니다.

검색 증강 생성 (RAG, Retrieval-Augmented Generation)

AI를 재학습시키는 것이 아닙니다. 답변 전에 사내 데이터베이스나 문서함에서 정보를 먼저 찾아보고(Retrieval) 답변하는 방식입니다. 구글 공식 가이드에서는 버텍스 AI 서치(Vertex AI Search)를 통해 이를 구현합니다. 반면, 업스테이지의 문서에서는 이를 도큐먼트 AI(Document AI)와 결합된 RAG 파이프라인으로 설명하며, 특히 문서의 구조를 분석하는 레이아웃 분석(Layout Analysis) 기술의 중요성을 강조합니다.

1. 기획 가이드적용 대상: 사내 규정, 매뉴얼, 자주 바뀌는 상품 정보
2. 기획 의도: 데이터가 업데이트될 때마다 모델을 재학습하는 비용 절감
3. 요청 예시: "모델을 미세 조정(Fine-tuning)하기보다는, 사내 규정집을 검색 증강 생성(RAG) 방식으로 연동해 주세요."
4. [실무 참고] 개발자는 이렇게 말합니다현장 용어: 컨텍스트 주입(Context Injection), 벡터 DB(Vector DB)
5. 개발자 발화: "데이터를 학습시키는 게 아니라 컨텍스트에 태워서 보냅시다. 문서들을 벡터 DB에 넣어서 연동하겠습니다."

그라운딩 (Grounding)

AI가 사실이 아닌 내용을 지어내는 환각(Hallucination) 현상을 막기 위한 기술입니다. 구글은 이를 그라운딩(Grounding)이라고 명칭하며 검색 결과에 기반한 답변 생성을 지원합니다. 업스테이지 역시 이와 유사하게 답변이 문맥에 근거했는지 검증하는 그라운디드니스 체크(Groundedness Check)라는 별도의 API 기능을 제공하여 신뢰성을 확보합니다.

1. 기획 가이드적용 대상: 신뢰도가 중요한 정보 제공, 뉴스, 사실 확인
2. 기획 의도: 답변의 근거를 명확히 하여 사용자 신뢰 확보
3. 요청 예시: "답변 신뢰도를 위해 그라운딩(혹은 그라운디드니스 체크) 기능을 활성화하고, 답변 하단에 반드시 정보의 출처(Source Citation)가 표시되도록 기획하겠습니다."
4. [실무 참고] 개발자는 이렇게 말합니다현장 용어: 할루시네이션 제어, 인용(Citation) 표기
5. 개발자 발화: "그라운딩 소스를 구글 검색으로 할까요, 사내 데이터로 할까요?"

4. 답변 제어: 톤앤매너 대신 시스템 지시문과 온도 값

"친절하게 대답해 주세요"나 "전문가처럼 보이게 해 주세요"라는 요청은 모호합니다. 공식 API 문서에 존재하는 파라미터로 소통해야 합니다.

시스템 지시문 (System Instruction)

AI 모델에게 부여하는 페르소나와 제약 사항을 정의하는 프롬프트입니다. 구글 공식 문서는 이를 시스템 지시문(System Instruction)이라고 부릅니다. 업스테이지 솔라 API 문서에서는 이를 시스템 메시지(System Message) 혹은 시스템 프롬프트(System Prompt)라고 정의하며, 'role: system'으로 설정하여 전달합니다.

1. 기획 가이드적용 대상: 에이전트의 성격, 말투, 금기 사항 설정
2. 기획 의도: 브랜드 이미지에 맞는 일관된 답변 스타일 유지
3. 요청 예시: (아래와 같이 구체적인 프롬프트 초안 제공)
4. "당신은 10년 차 IT 상담사입니다. 전문 용어 사용은 지양하고 비유를 들어 설명하세요. 답변은 항상 '해결할 수 있습니다'라는 긍정적인 말로 시작하세요."
5. [실무 참고] 개발자는 이렇게 말합니다현장 용어: 시스템 프롬프트(System Prompt)
6. 개발자 발화: "시스템 프롬프트에 제약 조건을 걸어두겠습니다. 페르소나 설정이 너무 길면 토큰 비용이 많이 나갑니다."

온도 값 (Temperature)

모델의 창의성, 즉 답변의 다양성을 조절하는 수치(0.0 ~ 1.0)입니다. 이 용어는 구글과 업스테이지 모두 공통적으로 템퍼러처(Temperature)라는 명칭을 사용합니다. 값이 높을수록 창의적이고, 낮을수록 결정론적입니다.

1. 기획 가이드적용 대상: (0.2 이하) 규정 안내 / (0.8 이상) 아이디어 제안
2. 기획 의도: 기능의 목적에 맞는 답변 다양성 조절
3. 요청 예시: "상품 추천 기능은 온도 값을 0.7로 높여 다양하게 제안하고, 반품 규정 안내는 0.1로 설정해 정확하게 답변합시다."
4. [실무 참고] 개발자는 이렇게 말합니다현장 용어: 템퍼러처, 랜덤니스(Randomness)
5. 개발자 발화: "템퍼러처를 낮춰서 랜덤니스를 줄이는 게 좋겠습니다. 모델이 너무 소설을 쓰지 않게 파라미터를 조절하겠습니다."

5. 행동 능력: 말만 하는 챗봇에서 일하는 에이전트로

과거의 챗봇은 링크 전달이 한계였지만, AI 에이전트는 실제 업무를 수행합니다.

함수 호출 (Function Calling)

AI가 대화 도중 외부 도구(API) 사용이 필요하다고 판단하면, 개발자가 미리 만들어둔 코드를 실행하는 기능입니다. 구글 공식 가이드는 이를 함수 호출(Function Calling)이라고 부르며, 업스테이지 공식 가이드 역시 툴 유즈(Tool Use) 혹은 펑션 콜링(Function Calling)이라는 용어를 사용하여 외부 API와의 상호작용을 설명합니다.

1. 기획 가이드적용 대상: 예약, 결제, 조회 등 실제 데이터 변경이 필요한 작업
2. 기획 의도: 대화만으로 복잡한 시스템 기능 수행
3. 요청 예시: "사용자가 시간을 언급하면 구글 캘린더 API를 함수 호출(Function Calling)하여 실제 일정을 등록하는 플로우를 설계합시다."
4. [실무 참고] 개발자는 이렇게 말합니다현장 용어: 툴 유즈(Tool Use), API 콜(Call), 액션(Action)
5. 개발자 발화: "AI가 의도를 파악해서 API를 콜하게 만들겠습니다. 이건 챗봇이 직접 액션을 취해야 하는 부분입니다."

6. 마치며: 사용자 여정에 따른 하이브리드 아키텍처 설계 (보험사 사례)

성공적인 AI 에이전트는 하나의 기술로 만들어지지 않습니다. 기획자의 역할은 사용자 여정(User Journey)을 세분화하고, 각 단계의 UX 목표에 맞춰 확률적 모델(LLM)과 결정론적 시스템(Code)을 적재적소에 배치하는 것입니다.

보험 상품 판매 에이전트를 예시로, 대화의 시작부터 종결까지 기획자가 개발자와 어떤 용어로 소통해야 하는지 그 흐름을 풀어드립니다.

1단계: 대화 시작 및 맥락 파악 (개인화 데이터 연동)

개발자와 소통하기 위한 기술 스토리

기획자가 "고객이 들어오면 알아서 정보를 띄워주세요"라고 말하면 개발자는 막막해합니다. 이때는 함수 호출과 컨텍스트 주입이라는 용어를 써야 합니다. 개발자에게 이렇게 말해보세요. "AI가 첫 마디를 뱉기 전에 백엔드 API를 먼저 호출해서 고객의 세션 데이터를 가져오게 합시다. 그리고 그 정보를 AI의 기억, 즉 컨텍스트에 미리 주입한 상태로 대화를 시작해 주세요."

2단계: 탐색 및 추천 (비정형 입력 처리)

개발자와 소통하기 위한 기술 스토리

고객의 모호한 말을 찰떡같이 알아듣고 정확한 약관을 찾아내는 기술, 구글 공식 가이드는 이를 버텍스 AI 서치와 그라운딩이라고 부릅니다. 업스테이지 문서에서는 레이아웃 분석을 통한 RAG라고 설명합니다. 현장에서는 흔히 벡터 검색이라는 표현을 씁니다. "AI가 아무 말이나 지어내지 말고, 우리가 가진 PDF 약관 문서를 벡터 DB에 넣어두고 거기서 내용을 찾아 답변하도록 그라운딩 해주세요"라고 요청하세요.

3단계: 조건 확정 및 정보 입력 (정형 데이터 수집)

개발자와 소통하기 위한 기술 스토리

이제부터는 AI의 창의성을 꺼야 할 때입니다. 구글 문서는 이를 매개변수 수집이라고 부르며, 업스테이지 등 국내 개발 현장에서는 이를 빈칸 채우기, 즉 슬롯 필링이라고 부릅니다. "지금부터는 대화형보다는 인터뷰형으로 갑시다. 보험 설계에 필요한 차종, 나이, 용도라는 3가지 엔티티(Entity)가 다 채워질 때까지 AI가 집요하게 되묻도록 슬롯 필링 로직을 적용해 주세요"라고 말하세요.

4단계: 계산 및 결과 제시 (결정론적 실행)

개발자와 소통하기 위한 기술 스토리

AI는 계산기가 아닙니다. 언어 모델이 직접 숫자를 계산하게 두면 엉뚱한 값을 내놓을 수 있습니다. 이때 필요한 것이 함수 호출을 통한 외부 API 연동입니다. 개발자에게 명확히 선을 그어주세요. "여기서 AI는 답변 생성자가 아니라 전달자 역할만 합니다. 아까 받은 정보들을 가지고 우리 회사의 기존 가격 산출 API를 호출해서, 거기서 나온 숫자 그대로를 보여주게 해주세요."

5단계: 대화 종결 및 액션 유도 (UI/UX 강화)

개발자와 소통하기 위한 기술 스토리

마지막으로 고객이 가입하기 버튼을 누르게 만들어야 합니다. 구글 문서는 이를 커스텀 페이로드라고 부르며, 국내 실무 현장에서는 흔히 리치 메시지라고도 합니다. "텍스트로만 끝내지 말고, 가입 페이지로 넘어가는 버튼을 띄우고 싶습니다. 답변 하단에 커스텀 페이로드를 심어서 가입하기 버튼 UI가 렌더링되도록 해주세요"라고 요청하세요.

요약: 기획자가 그려야 할 청사진

결국 기획자는 단순한 시나리오 작가가 아니라, 오케스트라 지휘자가 되어야 합니다. 아래의 청사진을 통해 개발자에게 각 단계에 맞는 정확한 기술 용어를 제안해 보세요.

[Version 1] 사용자 경험 중심 명세서 (기획자 → 개발자 전달용)

기획자가 개발자에게 "사용자가 어떤 경험을 해야 하는지(What)"를 명확히 전달하기 위한 명세서입니다. 기술 용어보다는 사용자 상황과 의도에 집중하여 작성합니다.

[Version 2] 구글 표준 기술 명세서 (테크니컬 스펙 정의용)

구글의 Dialogflow CX 및 Vertex AI Conversation 설계 표준을 따른 기술 명세서입니다. 개발자가 인텐트(Intent), 파라미터(Parameter), 풀필먼트(Fulfillment)를 즉시 설정할 수 있도록 합니다.

부록: 용어 팩트 체크 및 출처 (Glossary & References)

본 문서에 사용된 기술 용어는 Google Cloud 및 Upstage 공식 문서를 기반으로 작성되었습니다. 각 용어의 정의와 출처는 다음과 같습니다.