P6-18.1 질문·근거·답변·기록을 묶는 작은 생성형 AI 기능¶

Section ID: P6-18.1 Version: v2026.07.23

LLM, RAG, 도구 사용, 에이전트, 평가, 실패 대응을 각각 따로 설명할 수 있어도 실제 기능 설계는 아직 끝나지 않습니다. 이제는 이 개념들이 실제 요청 하나 안에서 어떻게 함께 움직이는지로 질문이 모입니다.

작은 생성형 AI 기능은 요청 해석 -> 필요한 근거 검색 또는 도구 선택 -> 모델 응답 생성 -> 상태 판단 -> 기록의 흐름으로 묶어 이해하는 편이 안전합니다. 여기서 상태 판단에는 자동 게이트, 사람 검토, retry, fallback, stop, approval 같은 판단이 실제 요청 안에서 어느 상태값으로 남는지가 함께 들어갑니다.

요청 하나로 다시 묶는 기준¶

핵심 질문은 다음과 같습니다.

• Part 6에서 배운 개념들을 하나의 요청 흐름으로 어떻게 다시 묶을 수 있는가?
• 언제 프롬프트만으로 답하고, 언제 검색이나 도구를 붙여야 하는가?
• 작은 기능을 설계할 때 최소한 무엇을 기록해야 하는가?

검색과 근거 연결, 도구 선택과 실행 연결, 실행 기록과 재현성, 운영 제약과 실패 대응은 각각 따로 배웠습니다. 여기서는 그 조각들을 요청 하나가 실제로 닫히는 구조로 다시 묶습니다.

중요한 전환은 실패 경로를 고른다에서 그 판단까지 포함한 요청 하나의 구조를 묶는다로 관점이 바뀌는 데 있습니다. 질문, 근거, 실행, 평가를 한 요청 단위로 묶는 기준이 서야 요청 결과를 답변 초안 가능, 근거 보강 필요, 상태 조회 필요, 사람 검토 필요 같은 상태값으로 남길 수 있습니다.

평가와 운영에서 만든 판단은 요청 구조 안에서 다음처럼 내려옵니다.

같은 질문이 요청 안에서 언제 답변 초안, 사람 검토, 상태 조회 필요, 근거 부족으로 갈리는지 보는 편이 더 안전합니다. 요청 흐름 통합의 핵심은 구성요소 이름을 많이 붙이는 데 있지 않고, 평가와 운영 판단이 실제 요청 상태값으로 언제 바뀌는지 보이게 만드는 데 있습니다.

예를 들어 같은 인사 도우미에서도 아래처럼 갈립니다.

즉, 요청 흐름을 묶는다는 말은 질문 -> 답변만 그리는 것이 아니라, 이 요청은 지금 어디까지 닫혔는가를 같은 구조 안에서 함께 남기는 데 가깝습니다. 이 기준이 서야 요청 실행 기록도 단순 로그가 아니라 답변 가능, 근거 보강 필요, 상태 조회 필요, 사람 검토 필요를 구분하는 운영 메모가 됩니다.

프롬프트, 검색, 도구 사용 요청 흐름의 구분¶

• 작은 생성형 AI 기능을 요청 흐름으로 설명할 수 있습니다.
• 프롬프트만으로 처리할 일과 검색·도구가 필요한 일을 구분할 수 있습니다.
• 입력, 근거, 출력, 평가, 기록을 하나의 설계 문장으로 묶을 수 있습니다.
• 최소 구현에서 남겨야 할 요청 실행 기록을 더 쉽게 읽을 수 있습니다.

먼저 가를 장면은 아래처럼 정리할 수 있습니다.

이 표를 기준으로 아래 내용을 읽으면, 요청 흐름 통합을 단계 설명 목록보다 같은 질문이 어떤 요청 상태로 먼저 갈리는가를 가르는 기준으로 더 직접 읽을 수 있습니다.

어떤 기능을 예로 들 것인가¶

사내 문서 기반 휴가 정책 안내 도우미를 예로 들면, 사용자가 이번 달에 입사한 직원도 여름휴가를 바로 쓸 수 있나요?라고 물었을 때 겉으로는 단순한 질문 응답처럼 보일 수 있습니다. 하지만 실제로는 현재 규정 문서를 찾아야 하고, 경우에 따라서는 내 잔여 휴가는 며칠인가요?처럼 시스템 조회까지 이어질 수 있습니다. 또 답변 뒤에는 어떤 문서를 근거로 썼는지와, 문서를 못 찾았는지까지 남겨야 다음 수정이 가능합니다. 그래서 이 예는 Part 6에서 다룬 프롬프트, 검색, 도구 사용, 평가와 기록을 한 요청 안에서 함께 묶어 보기 좋습니다.

이 사례를 고른 이유는 prompt만으로 닫히는 질문, retrieval이 필요한 질문, 현재 상태 조회까지 필요한 질문을 한 흐름 안에서 나란히 비교하기 쉽기 때문입니다. 또한 근거 문서 선택, 실패 기록, 사람 검토 전환 같은 운영 판단도 같은 예에서 자연스럽게 드러낼 수 있습니다. 핵심은 특정 인사 도메인을 자세히 설명하는 것이 아니라, 작은 생성형 AI 기능이 어떤 구조로 묶여야 하는지 보여 주는 데 있습니다.

한 요청 흐름으로 그리면¶

방금 본 질문을 처리하는 가장 단순한 흐름은 다음과 같습니다.

1. 질문이 어떤 종류인지 읽는다.
2. 최신 규정이 필요한 질문인지 판단한다.
3. 필요하면 관련 문서를 검색한다.
4. 답변을 만들고 근거를 함께 붙인다.
5. 애매하거나 누락이 있으면 사람 확인 또는 추가 질문으로 넘긴다.

이 다섯 단계만 있어도 이미 단순 프롬프트 예제와는 다른 구조가 됩니다.

하지만 실제 요청 흐름을 운영 가능한 구조로 읽으려면 한 단계가 더 필요합니다.

1. 답을 바로 채택할지, 근거 보강이나 사람 검토로 돌릴지 상태를 남긴다.

즉, 요청 하나가 닫혔다는 말은 답변 문장이 만들어졌다는 뜻만이 아니라, 그 답이 어떤 상태로 남는지도 함께 정해졌다는 뜻입니다.

이 흐름을 한 번 더 단순화하면 다음과 같습니다.

flowchart LR
  A["사용자 질문"]
  B["요청 분류"]
  C["프롬프트만 / 검색 / 도구"]
  D["근거 또는 상태와 함께 답변"]
  E["기록하고 평가"]

  A --> B
  B --> C
  C --> D
  D --> E

이 그림의 핵심은 작은 기능도 질문 분류, 근거 또는 상태 확보, 답변, 기록의 흐름으로 읽어야 한다는 점입니다.

Part 6 뒤쪽 본류는 여기서 좋은 답 판정과 실패 시 운영 경로 선택을 질문, 근거/상태, 답변, 평가, 기록을 한 요청 흐름으로 묶는 일로 닫습니다.

언제 프롬프트만으로 충분한가¶

프롬프트만으로 충분한 경우는 주로 다음과 같습니다.

• 문장 다듬기
• 요약 형식 바꾸기
• 이미 입력된 자료 안에서 답하기
• 창의적 초안 작성

이 경우에는 모델이 현재 입력 안의 정보만으로도 작업을 수행할 수 있습니다.

예를 들어:

• 메일 문장을 더 공손하게 바꾸기
• 이미 붙여 둔 회의록을 세 문장으로 요약하기

같은 일은 검색이나 도구 호출 없이도 시작할 수 있습니다.

언제 검색이 필요한가¶

다음 조건이 붙으면 검색이 필요해집니다.

• 최신 규정이 중요하다
• 문서 근거를 함께 보여 줘야 한다
• 긴 내부 문서를 그대로 프롬프트에 다 넣기 어렵다
• 모델의 내부 기억보다 현재 저장소의 문서가 더 신뢰할 만하다

휴가 정책 안내 도우미는 여기에 해당합니다. 정답처럼 보이는 일반론보다 현재 회사 문서의 실제 규정이 더 중요하기 때문입니다.

즉, 이런 경우에는 말투를 더 잘 만드는 문제가 아니라 현재 문서를 정확히 찾아 근거와 함께 답하는 문제로 읽어야 합니다.

모델이 답을 잘 쓰는 능력과 올바른 근거를 가져오는 능력은 같은 문제가 아니다.

언제 도구 사용이 필요한가¶

검색만으로 충분하지 않은 경우도 있습니다.

예를 들어 사용자가:

• 남은 휴가 일수 조회
• 승인 상태 확인
• 신청 양식 생성

을 요청한다면, 이제는 문서 검색만으로는 부족합니다.

이 경우에는 실제 시스템에서 값을 읽거나 작업을 수행하는 도구가 필요합니다.

즉, 검색은 무엇이 규정인가를 확인하는 데 가깝고, 도구 사용은 현재 상태에서 무엇을 실행하거나 조회할 것인가를 다루는 데 가깝습니다.

작은 기능도 최소 평가가 필요하다¶

작은 기능이라고 해도 답변 하나만 보고 끝내면 개선이 어렵습니다.

최소한 다음 네 가지는 남기는 편이 좋습니다.

이 네 가지는 Part 6 뒤쪽의 평가와 실패 대응 설명을 실제 설계로 끌어오는 최소 장치입니다.

핵심은 생성형 AI 기능을 모델 호출 한 번으로만 그리지 않는 데 있습니다. 요청을 읽고, 필요한 근거나 상태를 확보하고, 답변과 기록까지 하나의 구조로 봐야 합니다.

사례 및 예시¶

앞에서 본 prompt 중심, retrieval 결합, tool use 결합 구분을 실제 기능 장면으로 다시 묶으면 다음처럼 읽을 수 있습니다.

이 사례들의 초점은 생성형 AI를 쓴다가 아니라 이 질문은 어떤 구조를 붙여야 닫히는가입니다.

사례 1. 문장 다듬기¶

입력된 안내 문장을 더 공손하게 다듬는 기능을 생각해 볼 수 있습니다. 사람은 생성형 AI 기능이면 검색이나 도구가 항상 붙어야 한다고 느끼기 쉽지만, 이 경우 먼저 확인할 것은 현재 문장 자체이고 외부 문서나 실시간 시스템 값은 필요하지 않을 수 있습니다. 예를 들어 서류를 다시 제출하세요를 더 부드럽게 바꾸는 작업은, 최신 규정을 찾는 문제가 아니라 이미 주어진 문장을 어떻게 표현하느냐의 문제입니다.

이때 검색까지 붙이면 오히려 관련 없는 규정 문구가 섞여 원래 문장보다 길고 딱딱한 답이 나올 수 있습니다. 그래서 핵심 구조는 좋은 지시와 예시를 넣는 프롬프트 쪽에 더 가깝습니다. 즉, 바꿔야 할 대상이 이미 입력 안에 다 들어 있으면 prompt 중심 구조로 충분할 수 있습니다. 여기서 바뀌는 점은 생성형 AI면 검색도 붙어야 하는가를 보던 기준에서 현재 입력만으로 작업이 닫히는가를 보는 기준으로 이동한다는 것입니다. 그래서 이 사례에서 확인해야 할 결과는 검색 없이도 입력 문장 자체만으로 원하는 표현 수정이 충분히 닫히는가입니다.

이 장면에서는 필요한 정보가 이미 주어졌는가를 먼저 묻는 습관이 중요합니다. 표현만 바꾸면 되는 요청에 검색을 붙이면, 없는 근거를 찾으려다 오히려 답이 산만해질 수 있습니다. 그래서 작은 생성형 AI 기능을 설계할 때는 더 많은 구성요소를 붙이는 것보다, 먼저 어떤 구성요소가 불필요한지 빼 보는 판단이 필요합니다.

사례 2. 사내 정책 안내¶

사내 정책 안내 챗봇을 생각해 보겠습니다. 사람은 휴가 신청은 며칠 전까지 해야 하나요?나 육아휴직 신청 순서는 어떻게 되나요? 같은 질문을 보면 모델이 바로 답을 써 주면 된다고 느끼기 쉽습니다. 하지만 이런 질문은 말투보다 최신 규정 문서를 정확히 가져오는 일이 먼저입니다. 예를 들어 지난 분기 규정에는 3일 전이라고 되어 있었는데 최신 규정은 5영업일 전으로 바뀌었다면, 프롬프트만 잘 써도 내부 기억만으로는 최신 기준을 보장하기 어렵습니다.

정책은 바뀔 수 있으므로, 말투가 자연스러운 답보다 최신 문서를 먼저 찾고 근거 문장을 붙이는 구조가 더 중요합니다. 이 경우 핵심 구조는 검색으로 최신 문단을 붙이고 그 근거를 바탕으로 답을 정리하는 쪽에 가깝습니다. 여기서 바뀌는 점은 답을 바로 잘 쓰는가를 보던 기준에서 최신 규정 근거를 실제로 가져오는가를 보는 기준으로 이동한다는 것입니다. 그래서 이 사례에서 확인해야 할 결과는 최신 문단을 붙였을 때 답이 말투보다 규정 근거 정확성 쪽에서 실제로 더 안정되는가입니다.

이 사례에서는 반대로 입력만으로는 부족하다는 신호를 빨리 읽어야 합니다. 정책 질문은 문장이 자연스러운지보다 지금 기준으로 맞는가가 더 중요하므로, 최신 문서를 붙이지 않은 채 답을 잘 쓰는 능력만 올려도 핵심 실패는 남습니다. 그래서 retrieval은 선택형 장식이 아니라, 질문을 닫기 위한 필수 구조가 됩니다.

사례 3. 잔여 휴가 조회¶

잔여 휴가 조회는 한 단계 더 다릅니다. 정책 문서만 읽어서는 연차는 어떤 기준으로 계산되는가는 설명할 수 있어도, 내 계정에 실제로 며칠이 남았는가는 알 수 없습니다. 사람은 정책을 찾았으니 답도 끝났다고 느끼기 쉽지만, 이 질문을 닫으려면 규정뿐 아니라 인사 시스템 값 조회가 필요하다는 점을 바로 구분해야 합니다.

예를 들어 정책상 연차 계산식은 알아도, 이미 사용한 일수와 승인 대기 휴가까지 반영된 현재 잔액은 시스템을 조회해야만 알 수 있습니다. 그래서 이 기능은 retrieval만으로도 부족하고, 실제 상태를 읽는 tool use가 붙어야 닫힙니다. 여기서 바뀌는 점은 규정 설명이 가능한가를 보던 기준에서 현재 상태 값을 실제로 조회해 답을 닫을 수 있는가를 보는 기준으로 이동한다는 것입니다. 그래서 이 사례에서 확인해야 할 결과는 규정 설명만으로는 못 닫히는 질문이 실제 시스템 조회를 붙였을 때 비로소 현재 상태 답변으로 닫히는가입니다.

세 사례를 실제 설계 판단으로 줄이면 다음과 같습니다.

같은 내용을 설계 선택 흐름으로 다시 그리면 다음과 같습니다.

flowchart TD
  A["질문이 들어옴"]
  B{"현재 입력만으로 충분한가?"}
  C{"최신 문서 grounding이 필요한가?"}
  D{"실시간 시스템 상태가 필요한가?"}
  H{"확답 위험이나 근거 부족이 있는가?"}
  E["프롬프트 중심 흐름"]
  F["프롬프트 + 검색 흐름"]
  G["프롬프트 + 도구 흐름"]
  I["사람 검토 또는 추가 질문"]
  J["답변과 실행 기록"]

  A --> B
  B -->|예| E
  B -->|아니오| C
  C -->|예| F
  C -->|아니오| D
  D -->|예| G
  D -->|아니오| E
  E --> H
  F --> H
  G --> H
  H -->|예| I
  H -->|아니오| J
  I --> J

이 도식의 핵심은 기능 구조를 모델 종류로 고르는 것이 아니라, 질문을 닫는 데 필요한 근거와 상태가 무엇인지로 고른다는 점입니다. 또한 어떤 구조를 골랐더라도 마지막에는 확답 위험이나 근거 부족을 다시 확인해, 사람 검토나 추가 질문으로 넘길 수 있어야 합니다.

요청 상태를 먼저 남겨야 하는 장면¶

작은 생성형 AI 기능 설계를 처음 읽을 때 자주 생기는 오해는 AI 기능이니까 일단 검색이나 도구를 많이 붙여야 한다고 생각하는 점입니다. 하지만 실제로는 지금 질문을 닫는 데 먼저 없는 것이 무엇인가를 가르는 편이 더 중요합니다. 이 기준을 실무 질문으로 바꾸면 다음처럼 읽을 수 있습니다.

같은 요청을 어떤 상태로 남길까까지 바로 내려오면 다음처럼 더 짧게 읽을 수 있습니다.

이 표의 핵심은 어떤 구조를 붙일까에서 한 번 더 내려와 이 요청은 지금 어디까지 닫혔는가를 바로 남기는 데 있습니다. 그래야 retrieval이나 tool use를 붙였더라도, 마지막 상태를 답변 가능, 근거 보강 필요, 상태 조회 필요, 사람 검토 필요로 다시 구분할 수 있습니다.

먼저 익혀야 할 기준은 단순합니다. 작은 생성형 AI 기능 설계는 모델 호출 방식을 고르는 일보다 현재 입력, 최신 근거, 현재 상태, 확답 가능한지 여부 중 무엇이 먼저 비어 있는지를 가르고 그에 맞는 구조와 상태값을 붙이는 일에 가깝습니다.

연습 및 예제¶

이 연습의 초점은 생성형 AI 기능을 붙인다가 아니라 질문을 닫는 데 필요한 구조를 고른다를 직접 판단해 보는 데 있습니다. 바로 위 사례를 읽었더라도, 실제 요청 문장을 보면 prompt, retrieval, tool use가 다시 섞여 보이기 쉽기 때문입니다. 그래서 질문을 보고 어떤 구조가 필요한가, 무엇을 기록으로 남겨야 하는가, 잘못 고르면 어디서 실패하는가를 적어 본 뒤 아래 해설과 비교합니다.

아래 연습은 요청 문장 네 개를 사용합니다. 같은 인사 도우미처럼 보여도 어떤 요청은 prompt 중심으로 닫히고, 어떤 요청은 prompt + retrieval, 어떤 요청은 prompt + tool use가 먼저 필요합니다.

확인할 핵심은 질문을 닫는 데 필요한 것이 현재 입력, 최신 근거, 현재 상태 중 무엇인지 먼저 구분하는 일입니다. 구조를 잘못 고르면 답 품질 문제보다 먼저 근거 누락, 상태 누락, 불필요한 검색이 생깁니다.

먼저 아래 표의 먼저 붙일 구조 열을 가리고, 각 요청에서 무엇이 먼저 필요한지 스스로 적어 봅니다. 그다음 답과 이유, 기록 항목을 비교합니다.

이 표를 읽을 때 중요한 것은 정답 기능 이름보다 무엇이 먼저 없으면 답이 닫히지 않는가입니다. 예를 들어 잔여 휴가 조회에 retrieval만 붙이면 규정 문장은 가져와도 현재 잔액은 못 닫고, 문장 다듬기에 retrieval까지 붙이면 오히려 답이 산만해질 수 있습니다.

같은 내용을 실무 검토 메모처럼 다시 줄이면 다음과 같습니다.

설계 문장으로 다시 묶기¶

긴 설계 문서를 다 쓰기보다, 기능 하나를 다음처럼 한 문장으로 요약할 수 있으면 충분합니다.

휴가 정책 안내 도우미는 사용자의 질문을 읽고, 관련 규정 문서를 검색한 뒤, 근거 문장을 포함한 답변을 만들고, 검색 실패나 근거 누락은 기록한다.

현재 상태 조회가 필요한 기능이라면 문장도 달라져야 합니다. 예를 들어 잔여 휴가 안내 기능은 사용자의 질문을 읽고, 필요한 경우 휴가 규정을 확인한 뒤, 인사 시스템 조회 도구로 현재 잔여 일수를 가져오고, 조회 결과와 답변을 함께 기록한다처럼 도구 호출과 조회 결과 기록까지 포함해야 합니다.

이런 설계 문장 안에는 이미 다음 요소가 들어 있습니다.

• 입력
• 검색 또는 도구 호출
• 출력
• 근거 또는 조회 결과
• 실패 기록

즉, Part 6 전체 내용을 작은 서비스 문장 하나로 압축한 셈입니다.

이 지점에서 한 번 더 분리해 두면, 요청 흐름 설계가 직접 정하는 것과 최소 구현에서 확인할 것이 더 선명해집니다.

이 표의 핵심은 무엇을 구현했는가보다 어떤 요청 구조를 붙여야 하는가를 먼저 정해야 한다는 점입니다. 같은 구조가 실제로 어떤 출력과 요청 실행 기록으로 남아야 하는지는 최소 구현에서 확인합니다.

여기까지를 한 줄로 묶으면, 작은 생성형 AI 기능 설계는 모델을 한 번 호출한다가 아니라 질문 종류에 맞는 구조를 고르고, 근거와 상태를 붙여 답하고, 그 경로를 기록한다는 문장으로 정리할 수 있습니다.

체크리스트¶

• 작은 생성형 AI 기능을 모델 호출 한 번이 아니라 질문, 근거/상태 확보, 출력, 평가, 기록의 요청 흐름으로 설명할 수 있는가?
• 프롬프트만으로 충분한 일과 검색·도구가 필요한 일이 다르다는 점을 구분할 수 있는가?
• 검색은 근거 확보 문제이고, 도구 사용은 상태 조회·실행 문제라는 차이를 말할 수 있는가?

출처와 참고 자료¶

• OpenAI, Prompt engineering, OpenAI API Docs, 확인 날짜: 2026-07-19.
• OpenAI, Retrieval, OpenAI API Docs, 확인 날짜: 2026-07-19.
• OpenAI, Function calling, OpenAI API Docs, 확인 날짜: 2026-07-19.