이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- AI 업무 요청을 어떤 유형으로 나누어야 하는가?
- 유형별로 필요한 백엔드 설계 장치는 어떻게 달라지는가?
- 챗봇 요청을 그대로 챗봇으로 만들면 왜 위험한가?
- 주니어와 시니어는 AI 업무 요청을 어떻게 다르게 읽어야 하는가?
개요
AI 기능 요청은 보통 모호하게 들어온다. “사내 문서를 답변하는 챗봇”, “상담 내용을 요약하는 기능”, “AI가 업무를 자동으로 처리하는 기능”처럼 표현된다. 백엔드 개발자는 이 요청을 기술 유형으로 다시 나눠야 한다.
요청 유형을 나누면 데이터 흐름, latency, 실패 처리, 권한, 비용, eval 기준이 보인다.
업무 요청 유형
대표 유형은 다음이다.
| 요청 | 주된 설계 축 |
|---|---|
| 문서 기반 QA | RAG, 권한 필터, source 표시 |
| 상담/회의/로그 요약 | 긴 입력, 민감정보, 요약 eval |
| 사용자 입력 분류 | structured output, 결정성, 회귀 테스트 |
| DB 데이터 기반 답변 | read-only 쿼리, 권한, SQL 제한 |
| 코드 생성/리뷰 | 보안, 실행 금지, diff 기반 검토 |
| 사내 업무 자동화 agent | tool 권한, 승인, idempotency |
| 개인 비서형 기능 | 메모리, 개인정보, 사용자 동의 |
같은 자연어 UI라도 내부 구조는 완전히 다르다.
문서 기반 QA
핵심 질문은 “모델이 무엇을 근거로 답하는가”다.
필수 판단:
- 문서 권한은 어디서 확인하는가?
- 삭제된 문서는 index에서 제거되는가?
- 답변에 source를 보여줄 것인가?
- 문서에 근거가 없으면 어떻게 답할 것인가?
- 최신 문서와 오래된 문서가 충돌하면 무엇을 우선할 것인가?
RAG QA는 모델 품질보다 retrieval 품질과 권한 설계가 먼저다.
요약 기능
상담, 회의, 로그 요약은 입력이 길고 민감정보가 많다.
필수 판단:
- 입력을 provider로 보내도 되는가?
- 개인정보를 마스킹할 것인가?
- 요약 형식은 자유 텍스트인가 JSON인가?
- 원문과 요약을 함께 저장할 것인가?
- 요약 실패 시 원문 업무 흐름은 계속 가능한가?
요약은 데모가 쉽지만 운영에서는 민감정보와 품질 기준이 중요하다.
분류 기능
분류는 후속 로직이 모델 결과를 소비하는 경우가 많다. 따라서 자유 텍스트보다 structured output이 필요하다.
필수 판단:
- 가능한 label 목록은 고정인가?
- confidence를 사용할 것인가?
- 낮은 confidence는 human review로 보낼 것인가?
- label 변경이 기존 데이터와 충돌하지 않는가?
- eval dataset이 있는가?
분류는 작은 모델과 낮은 temperature로 충분한 경우가 많다. 비용과 결정성을 우선 본다.
DB 데이터 기반 답변
사용자가 “매출 추이를 물어보면 DB에서 답하게 해 주세요”라고 하면 SQL 생성이 떠오르기 쉽다. 하지만 먼저 권한과 쿼리 제한을 봐야 한다.
필수 판단:
- read-only connection인가?
- tenant 필터가 강제되는가?
- 허용된 테이블과 컬럼만 조회하는가?
- 쿼리 timeout과 row limit이 있는가?
- 생성된 SQL을 실행 전 검증하는가?
모델에게 production DB를 직접 맡기는 것은 위험하다. semantic layer나 제한된 query API를 두는 편이 안전하다.
업무 자동화 Agent
agent 요청은 가장 위험도가 높다. 모델이 tool을 호출해 실제 업무를 수행하기 때문이다.
필수 판단:
- tool은 read-only인가 write인가?
- write tool에 approval이 필요한가?
- idempotency key가 있는가?
- tool 호출 audit log가 있는가?
- agent loop 종료 조건이 있는가?
- 실패했을 때 rollback 가능한가?
초기에는 “실행”이 아니라 “실행 계획 생성” 또는 “초안 생성”부터 시작하는 편이 좋다.
코드로 이해하기
요청 유형을 먼저 분류하면 구현 경로가 달라진다.
from enum import Enum
class AiRequestType(str, Enum):
DOCUMENT_QA = "document_qa"
SUMMARY = "summary"
CLASSIFICATION = "classification"
DB_ANSWER = "db_answer"
AGENT_WORKFLOW = "agent_workflow"
POLICIES = {
AiRequestType.DOCUMENT_QA: {
"requires_rag": True,
"requires_source": True,
"requires_permission_filter": True,
"allow_write_tool": False,
},
AiRequestType.AGENT_WORKFLOW: {
"requires_audit_log": True,
"requires_idempotency": True,
"requires_approval": True,
"max_tool_calls": 5,
},
}이런 분류는 기획 논의에서도 유용하다. “챗봇”이 아니라 “문서 QA와 티켓 생성 agent가 섞여 있다”고 말할 수 있어야 한다.
인프라 협업 포인트
유형별로 인프라 부담이 다르다.
- QA: vector DB, embedding batch, retrieval latency
- 요약: 긴 요청, provider token 비용
- 분류: 높은 QPS, 낮은 latency 요구
- DB 답변: DB 부하와 read-only 계정
- agent: tool 호출, audit log, queue, approval workflow
인프라팀에는 기능명보다 workload 특성을 설명해야 한다.
주니어 관점
주니어는 사용자의 요청 문장을 그대로 구현하지 말고, “이 요청은 QA인가, 요약인가, 분류인가, 자동화인가”를 먼저 나누는 연습을 해야 한다. 이 구분만 잘해도 모델 선택과 API 설계가 훨씬 쉬워진다.
시니어 관점
시니어는 요청 유형이 섞여 있는지 본다. 예를 들어 “사내 문서를 보고 환불 처리까지 해주는 챗봇”은 RAG QA와 write tool agent가 결합된 고위험 기능이다. 이 경우 읽기와 쓰기를 분리하고, approval과 audit log를 설계해야 한다.
위험 신호!
- 모든 요청을 하나의 chatbot endpoint로 처리한다.
- 문서 QA에 source 표시와 권한 필터가 없다.
- 분류 결과를 검증 없이 후속 DB 변경에 사용한다.
- agent가 write tool을 approval 없이 호출한다.
- DB 답변 기능이 production DB에 자유 SQL을 실행한다.
확인 질문
확인 질문
- AI 업무 요청을 유형별로 나누는 이유는 무엇인가?
- 유형마다 데이터, latency, 권한, 비용, 실패 처리, eval 기준이 다르기 때문이다.
- DB 데이터 기반 답변에서 SQL 생성보다 먼저 봐야 하는 것은 무엇인가?
- read-only 경계, tenant 권한, 허용 테이블, timeout, row limit이다.
- agent 업무 자동화에서 가장 먼저 제한할 것은 무엇인가?
- write tool 권한과 side effect 실행 경로다.