Spring AI Agentic Patterns (Part 2): AskUserQuestionTool — AI가 먼저 확인 질문을 해야 하는 이유
Spring AI Agentic Patterns (Part 2): AskUserQuestionTool — AI가 먼저 확인 질문을 해야 하는 이유
AI 에이전트를 실제 업무에 붙이면 금방 느끼게 되는 문제가 있다.
모델이 너무 빨리 답하려 든다는 점이다.
사용자는 대충 “블로그 글 써줘”, “유럽 여행 추천해줘”, “설정 화면 개선해줘”라고 말하지만, 그 안에는 빠진 조건이 많다. 예산, 톤, 우선순위, 대상 독자, 제약사항 같은 것들이다. 사람이 함께 일할 때는 보통 먼저 되묻는다. 그런데 많은 AI 앱은 이 과정을 건너뛰고 바로 답부터 만들어 낸다.
Spring AI의 AskUserQuestionTool은 이 지점을 겨냥한다. 답을 급하게 내놓기보다, 필요한 조건을 먼저 확인하고 나서 더 맞는 결과를 내도록 만드는 패턴이다.
이 글은 Spring 공식 블로그 글 Spring AI Agentic Patterns (Part 2): AskUserQuestionTool의 핵심을 한국어로 정리한 것이다.
왜 이 도구가 필요한가
AskUserQuestionTool의 핵심은 단순하다.
- 에이전트가 불확실한 부분을 감지하고
- 사용자에게 선택지 기반 질문을 던지고
- 답을 받아서
- 그 다음 작업을 이어간다
즉 “한 번에 맞히는 AI”가 아니라, 조건을 협의하는 AI에 가깝다.
이 방식이 특히 잘 맞는 경우는 아래와 같다.
- 요구사항이 아직 흐릿한 작업
- 취향이나 우선순위를 물어봐야 하는 추천형 작업
- 옵션 간 트레이드오프가 중요한 작업
- 한 번 잘못 가면 다시 되돌리기 귀찮은 작업
예를 들어 “다음 유럽 여행지는 어디가 좋을까?”라는 질문만으로는 답이 너무 넓다. 역사/미식/자연 중 무엇을 원하는지, 계절은 언제인지, 예산은 어느 정도인지에 따라 답은 완전히 달라진다.
AskUserQuestionTool은 바로 이 가정의 낭비를 줄이려는 도구다.
Spring AI 구현에서 눈에 띄는 점
원문은 이 도구를 spring-ai-agent-utils 안의 일부로 소개한다. 흥미로운 점은 이 구현이 특정 모델에 묶여 있지 않다는 것이다.
즉 질문 핸들러를 한 번 정의해 두면,
- OpenAI
- Anthropic
- Gemini
- 그 밖의 Spring AI 지원 모델
어느 쪽으로 옮겨도 같은 패턴으로 활용할 수 있다.
이건 꽤 중요하다. 상호작용형 요구사항 수집을 특정 벤더의 전용 기능으로 두지 않고, 애플리케이션 레벨의 패턴으로 끌어올렸기 때문이다.
동작 방식은 생각보다 단순하다
AskUserQuestionTool은 대체로 아래 흐름으로 이해하면 된다.
1) 모델이 질문이 필요하다고 판단한다
에이전트는 현재 정보가 부족하다고 판단하면 질문 세트를 만든다.
질문에는 보통 다음 정보가 들어간다.
- 질문 제목(header)
- 실제 질문 문장
- 2~4개 정도의 선택지
- 단일 선택인지, 다중 선택인지 여부
2) 애플리케이션이 질문을 사용자에게 보여 준다
여기서 중요한 건 UI는 애플리케이션이 책임진다는 점이다.
- 콘솔 기반이면 터미널에 질문을 출력하고
- 웹 앱이면 프런트엔드에 질문을 띄우고
- 모바일 앱이면 폼이나 선택 UI로 보여 줄 수 있다
3) 답을 다시 모델에게 돌려준다
사용자가 고른 답이나 자유 입력 텍스트를 다시 에이전트에 전달하면, 모델은 그 문맥을 가지고 다음 단계로 넘어간다.
즉 AskUserQuestionTool은 “질문을 예쁘게 보여 주는 위젯”이 아니라, 에이전트와 사용자 사이의 확인 질문 루프라고 보는 편이 맞다.
자유 텍스트까지 허용하는 점이 실용적이다
원문 예제에서 좋은 부분은 질문이 객관식으로 끝나지 않는다는 점이다.
선택지는 기본 가이드 역할을 하지만, 사용자는 항상 자유 텍스트를 넣을 수 있다. 이게 실무적으로 꽤 중요하다.
왜냐하면 현실의 요구사항은 자주 선택지 밖에 있기 때문이다.
예를 들어:
- “예산은 중간 정도인데 항공권은 아끼고 숙소는 좋은 데로 가고 싶다”
- “도시도 좋지만 2박 정도는 자연이 있었으면 좋겠다”
- “완전 초보용보다는 실무 적용 중심으로 설명해 달라”
이런 답변은 드롭다운 하나로 깔끔하게 안 담긴다. 그래서 AskUserQuestionTool은 정형 입력과 자유 입력을 함께 허용하는 구조가 핵심이다.
MCP Elicitation과 비슷하지만 위치가 다르다
원문에서 흥미로운 비교 포인트 하나는 AskUserQuestionTool과 MCP Elicitation의 관계다.
둘 다 구조화된 사용자 입력을 요청한다는 점에서는 비슷하다. 다만 차이는 위치다.
- AskUserQuestionTool: 에이전트 내부 로컬 패턴
- MCP Elicitation: MCP 서버가 구조화된 입력을 요청하는 패턴
즉 AskUserQuestionTool은 MCP 서버를 따로 두지 않아도 애플리케이션 안에서 바로 쓸 수 있는 방식이다. Spring AI를 쓰는 입장에서는 더 가볍게 시작하기 좋다.
시작은 어렵지 않다
원문 기준으로 시작 흐름은 명확하다.
spring-ai-agent-utils의존성을 추가한다.ChatClient에AskUserQuestionTool을 기본 도구로 연결한다.QuestionHandler를 구현한다.
핵심은 이 핸들러다. 결국 질문을 사용자에게 어떻게 보여 주고, 답을 어떤 방식으로 회수할지는 애플리케이션마다 다르기 때문이다.
콘솔 앱이라면 Scanner로도 충분하고,
웹 앱이라면 WebSocket/SSE + CompletableFuture 같은 방식으로 이어 붙일 수 있다.
즉 Spring AI가 제공하는 건 질문 패턴의 골격이고, 실제 UX는 개발자가 서비스 맥락에 맞게 설계한다.
이 도구가 특히 잘 맞는 제품 유형
개인적으로 AskUserQuestionTool은 아래 종류의 앱에서 효과가 크다.
1) 요구사항 수집형 에이전트
예: 글쓰기 보조, PRD 초안, 기획서 작성, 문서 생성
처음부터 다 추측하지 않고, 빠진 조건을 먼저 채우게 만들 수 있다.
2) 추천형 에이전트
예: 여행 추천, 강의 추천, 상품 추천, 일정 추천
추천의 질은 결국 질문의 질에서 많이 갈린다.
3) 고비용 액션 전 단계
예: 데이터 삭제, 대규모 수정, 외부 시스템 반영
애매하면 바로 실행하지 말고 먼저 확인 질문을 거치게 하는 게 안전하다.
한계도 있다
좋은 패턴이지만 만능은 아니다.
- 질문이 너무 많아지면 UX가 피곤해진다.
- 잘못 설계된 질문은 오히려 답을 좁혀 버린다.
- 사용자가 빨리 끝내고 싶어 하는 상황에서는 마찰이 될 수 있다.
그래서 핵심은 “무조건 질문 많이 하기”가 아니다.
정말 필요한 정보만 짧게 묻는 것, 그리고 이미 가진 문맥으로 충분히 판단 가능한 건 굳이 되묻지 않는 것이 중요하다.
이 글에서 가져가야 할 핵심
AskUserQuestionTool의 가치는 아주 현실적이다.
에이전트가 덜 추측하고, 더 맞는 답을 하게 만든다.
이건 화려한 데모보다 훨씬 중요하다. 실제 제품에서는 첫 답변이 얼마나 똑똑해 보이느냐보다, 사용자 의도에 얼마나 맞느냐가 더 중요하기 때문이다.
마무리
AskUserQuestionTool은 AI 에이전트를 “성급한 응답기”에서 “조건을 먼저 확인하는 협업자”로 바꾸는 패턴이다.
Spring AI 관점에서 특히 좋은 점은 이게 특정 모델 기능이 아니라, 이식 가능한 애플리케이션 패턴이라는 점이다.
즉 개발자는
- 질문이 필요한 시점을 설계하고
- 사용자 입력 루프를 구현하고
- 그 결과를 기존 ChatClient 흐름과 자연스럽게 연결할 수 있다.
다음 단계로 넘어가면 자연스럽게 또 다른 문제가 보인다. 조건은 잘 물어봤는데, 복잡한 작업을 수행하다 보면 에이전트가 중간 단계들을 잊어버리기 쉽다. 그 지점에서 이어지는 것이 바로 TodoWriteTool이다.
Series Links
- Part 1: Agent Skills 한국어 정리
- Part 2: AskUserQuestionTool (원문)
- Part 3: TodoWriteTool 한국어 정리
- Part 4: Subagent Orchestration 한국어 정리
- Part 5: A2A Integration 한국어 정리
- Dynamic Tool Discovery 한국어 정리
- Tool Argument Augmentation 한국어 정리