Boolean으로 컨트롤 하기
이번 시간에는 쉬어가는 타이밍!
간단하게 조작 가능한 항목을 보고 넘어가려고 한다.
Response API에서 Boolean 값으로 컨트롤할 수 있는 것들!
참고로, Boolean 이란 True(참), False(거짓) 두 가지 값으로 조정하는 것을 의미한다.
Yes, No. 쓴다, 안 쓴다만 컨트롤하면 되는 녀석들이다.
Response API에서 True, False로 조정하는 옵션들.
True면 쓴다, False면 안 쓰겠다는 의미다.
찾아보면 더 있을 것 같은데 자주 쓸 법한 것만 세 가지를 뽑아봤다.
1. stream
2. parallel_tool_calls
3. store
답변을 스트리밍으로, 실시간으로 재생시킬지를 컨트롤하는 옵션이다.
요즘 대부분의 챗봇들은 스트리밍 옵션을 기본값으로 쓰고 있어서,
마치 실시간으로 입력하는 듯한 느낌을 준다.
stream = true로 설정하면
“고객님.. 문의하신.. 주문은” 이렇게 한 글자씩 타이핑하는 느낌이 들게 된다.
stream=false로 설정하면
“고객님 문의하신 주문은 보통 2~3일 이내 배송됩니다. “ 하고 한 번에 퉁! 하고 출력되는 형식이 된다.
대부분의 텍스트 생성형 AI들은 stream=true로 설정되어 있어 실시간 입력하는 느낌으로 답변을 준다.
챗GPT도, Gemini, Claude 모두 스트리밍 방식으로 답변을 주는 게 기본이다.
이 옵션은 모델이 여러 개의 툴을 동시에 호출하게 할 건지 아닌지를 설정하는 값이다.
첫 번째 글에서 RAG(Retrieval Augmented Generation)와 펑션 콜링(Functon Calling)을 배웠다.
모델과 자체 문서나 API를 연동해서 내부 정책에 답변할 수 있게 하는 것이었다.
그리고 MCP(Model Context Protocol)을 배우면서 이런 여러 가지 내부 문서를 규격화해서 툴 개념으로 묶는다는 것도 배웠다.
그러니까 이 옵션은 여러 가지 툴(tool)을 병렬로(prarllel) 호출(calls) 한다는 거다.
병렬로 호출한다는 의미는 거의 동시에 호출할 수 있다는 의미다.
고객이 “이 상품 재고 있어요? 그리고 배송은 얼마나 걸려요?”라고 문의했다고 가정해 보자.
재고 조회랑 배송 정책 2가지에 답변을 해야 한다.
그러면 재고 API랑 배송 정책 API 두 가지를 호출해서 답변을 해야 되는데,
parallel_tool_calls=true 면 한 번에 여러 개의 툴을 호출해서 응답을 한 번에 조합해서 생성할 수 있다고 한다.
prrallel_tool_calls=false 면 한 번에 하나씩 툴만 호출하고 여러 턴에 나눠서 순차적으로 처리를 하게 된다. 그래서 기능 자체는 단순해지지만 대화가 길어지는 단점이 있다.
이렇게 보면 무조건 parallel_tool_calls=true로 사용하는 게 좋을 것 같지만,
여러 API를 동시에 호출하니까 트래픽이 증가하고,
의존성이 있는.. 순차적으로 처리할 수밖에 없는 질문(주문 ID를 조회한 후에 배송조회가 가능하다던지..)의 경우에는 병렬 처리가 의미 없을 수 있다. 게다가 병렬 호출이면 어떤 순서로 처리되는지 관리가 잘 안돼서 디버깅이 잘 안 될 수도 있다.
따라서 무조건 옵션값을 켤지 말지가 아니라,
질문 의도에 따라 단일 툴만 호출할지, 멀티 툴을 호출할지 정책을 정하는 게 좋다.
“질문에 필요한 도구가 2개 이상이면 병렬 호출, 1개면 순차 호출로 처리하라 “ 와 같이 말이다.
store 옵션은 세션 내에서 대화 기록을 저장할 것인지 말지를 결정하는 옵션이다.
store=true로 해두면 같은 세션 내에서 대화를 이어나갈 수 있다.
사실 상담이 종료되기 전에는 무조건 켜 놔야 하는 옵션이기도 하다.
왜냐면 이전 대화를 기억해야 멀티턴 대화가 가능하기 때문이다.
즉, 멀티턴 대화를 처리하고 싶다면 store=true여야 한다.
그런데 간단해 보이지만 헷갈리는 부분이 아예 없는 것도 아니다.
상담 종료라는 것을.. 세션이 종료되었다는 것을 어떻게 판단할지. 어디까지 한 세션으로 볼 것인지 기획자가 정의해줘야 하기 때문이다.
예를 들면 사용자가 명시적으로 상담 종료 의사를 밝힐 때까지 상담이 계속된다고 볼지,
혹은 상담 프로세스를 정해두고 단계가 완료되어야지만 종료된다고 할지,
특정 시간 기준으로 문의가 더 없으면 종료할지.. 와 같은 기준을 정해야 기록 저장을 할지 말지를 정할 수가 있다.
왜 이렇게 해야할까.
멀티턴이 중요하니까 무조건 store=ture 값으로 해두면 되지 않나? 싶기도 한데..
일단 대화 기록이 길어지면 시스템에 저장해야 하는 내용도 많아지기 때문에 처리 비용이 증가한다.
또한, 상담 내용에 민감한 정보가 포함될 수 있으므로 보관 기간이나 삭제 정책은 필요하다.
게다가 세션이 무한정 길어지면 이전 대화를 읽고 처리하는 시간이 길어져서 응답 속도고 느려질 수 있다.
store=ture로 쓰면 편하지만, 비용, 속도, 보안 때문에 무작정 쓸 수가 없다.
필요한 구간에만 쓰는 것으로 접근해야 한다.
… 가.. 간단.. 하게 이 정도만 훑어봤다.
가..간.단..하죠?