AIATTI 에이전트 구성도, 쉬운 질문은 기기에서 어려운 질문만 서버로

 

AIATTI는 공간 예약과 운영을 위한 통합 플랫폼입니다.
여러 모듈을 조합해서 공간마다 필요한 방식으로 운영할 수 있는 형태를 목표로 하고 있어요.
최근에는 여기에 AI가 업무를 자동으로 처리하거나 관리해 주는 기능을 더하려고, AIATTI 에이전트(가칭)를 개발하고 있습니다.
신규 버전을 본격적으로 만들기 전에 구조부터 정리하고 싶어서, 먼저 구성도를 한 장 그려 보았어요.
이 글에서는 그 구성도를 글로 풀어서, 왜 이런 구조를 골랐는지 기획자의 시선으로 정리해 보려고 합니다.

 

공간을 운영하다 보면 사용자가 하는 질문은 생각보다 단순한 것이 많습니다.
시설 위치나 운영 시간, 이용 방법처럼 이미 정해진 정보를 묻는 경우가 대표적이에요.
반대로 "토요일 오전에 아이가 할 수 있는 수영 프로그램 있어?"처럼 조건이 여러 개 섞인 질문도 있습니다.
이 두 가지를 같은 방식으로 처리하면 어느 쪽이든 아쉬워져요.
단순한 질문까지 큰 모델에 보내면 느리고 비용이 들고, 복잡한 질문을 규칙으로만 처리하면 의도를 놓치게 됩니다.
그래서 질문의 난이도에 따라 처리하는 곳을 나누는 구조를 생각하게 되었습니다.

 

이번 구조의 목표는 두 줄로 요약됩니다.

첫째, 사용자의 질문은 기기(앱과 웹)에서 규칙과 가벼운 모델로 먼저 처리해서, 쉬운 요청은 바로 답하고 검색까지 끝냅니다.
둘째, 그 단계에서 확신이 낮은 복잡한 요청만 서버의 모델(vLLM)로 보내서 정확한 의도와 조건을 뽑고 API로 연결합니다.

 

이렇게 나누면 얻는 게 세 가지입니다.

• 대부분의 질문이 기기에서 바로 끝나서 사용자가 체감하는 속도가 빨라집니다.
• 서버 모델 호출이 줄어서 비용과 부하를 통제하기 쉬워집니다.
• 서버 모델이 맡는 일이 "어려운 질문의 의도 파악"으로 좁혀져서 다루기 쉬워져요.

 

가장 위에는 클라이언트가 있습니다.
앱에서는 로컬 규칙과 키워드 처리, 경량 모델이 의도 분류와 날짜, 시간 해석을 맡고, 자주 쓰는 안내 정보는 캐시로 들고 있어요.
웹에서도 규칙 처리와 경량 모델, 캐시를 같은 방식으로 씁니다.
시설 정보나 자주 묻는 질문, 메뉴 이동, 단순한 조건 검색은 이 단계에서 끝납니다.
경량 모델이 확신을 내지 못하면 그 질문은 아래로 내려가요.

 

그 아래는 게이트웨이입니다.
인증과 권한, 요청 제한, 시설 단위로 나뉘는 멀티 테넌트, 감사 로그, 라우팅을 맡습니다.
AI 요청은 검증하고 정규화한 뒤 캐시를 먼저 확인하고, 간단한 질문은 곧바로 업무 API로 보냅니다.
복잡하거나 모호한 질문만 서버의 모델로 보내요.
게이트웨이를 AI 요청의 관문으로 둔 이유는, 모델 앞에서 한 번 더 걸러 내고 기록을 남기기 위해서입니다.

서버의 모델은 도구 호출을 지원하는 모델입니다.
이 모델이 하는 일은 사용자의 말을 이해하고, 어떤 도구를 쓸지 고르고, 그 도구에 넘길 파라미터를 JSON으로 만드는 것까지예요.
실제로 시스템을 움직이는 건 도구 실행기입니다.
도구 실행기가 파라미터를 검증하고, 권한을 확인하고, API를 호출하고, 실패하면 재시도합니다.
모델이 직접 시스템을 만지지 않게 한 것이 이 구조에서 제가 가장 중요하게 보는 부분이에요.

 

업무 API는 서비스 계층에 모듈로 나뉘어 있습니다.
회원, 프로그램, 공간과 대관, 이용권, 신청과 대기, 결제와 환불, 알림, CMS 같은 단위입니다.
각 모듈은 자기 데이터 저장소를 가지고, 검색을 위한 인덱스와 의미 검색을 위한 벡터 저장소가 옆에 붙어요.
그 바깥에는 모니터링과 로그 분석, 개인정보 최소화, 역할 기반 접근 제어, 응답 필터링 같은 운영과 보안 요소가 함께 놓입니다.

 

앞에서 든 예시로 흐름을 따라가 볼게요.
사용자가 "토요일 오전에 아이가 할 수 있는 수영 프로그램 있어?"라고 묻습니다.
기기의 경량 모델이 의도와 조건을 뽑아 보지만 확신이 낮아요.
질문은 게이트웨이를 거쳐 복잡한 질문으로 분류되고 서버의 모델로 넘어갑니다.
모델은 프로그램을 검색하는 도구를 고르고, 요일과 시간대, 연령 같은 조건을 JSON으로 만들어요.
도구 실행기가 권한을 확인하고 검색 API를 호출합니다.
결과는 모델의 짧은 답변과 함께 프로그램 목록 화면으로 이어져요.
사용자는 답을 읽고 바로 목록에서 원하는 프로그램을 고를 수 있습니다.

 

이 구조를 그리면서 고민한 점들이 있습니다.

 

첫째는 "기기에서 끝낼 질문"의 기준입니다.
확신도 기준을 너무 높이면 서버 호출이 늘어나고, 너무 낮으면 틀린 답이 즉시 나가요.
이 기준은 처음에 정한 값이 맞다고 믿기보다, 실제 질문을 보며 조정하는 값으로 다뤄야 한다고 생각합니다.

둘째는 모델이 부를 수 있는 도구의 범위입니다.
이번 구성도에서는 모델이 열람 전용 API를 부르는 것으로 그렸어요.
조회는 틀려도 되돌릴 수 있지만, 신청이나 변경, 취소, 결제는 되돌리기 어렵기 때문입니다.
실행 도구를 열 때는 사람의 확인 단계를 어디에 둘지를 먼저 정해야 한다고 봅니다.

셋째는 권한입니다.
AI가 여러 모듈을 넘나들며 일하면, 어떤 사용자의 어떤 권한으로 호출하는지가 흐려질 수 있어요.
권한 검증은 모델이 아니라 도구 실행기와 게이트웨이에서 하도록 두었습니다.

넷째는 개인정보와 비용, 지연입니다.
질문에 개인정보가 섞여 들어오면 어디까지 서버로 보낼지, 응답이 느려질 때 사용자에게 어떻게 보여 줄지도 아직 정리할 숙제로 남아 있어요.

 

 

이 글은 설계를 정리한 것이고, 구현이 끝났다는 이야기는 아닙니다.
1차 정리에서는 아래 네 가지를 문서로 확정하려고 해요.

• 기기에서 처리할 질문과 서버로 보낼 질문을 가르는 확신도 기준.
• 조회용 도구와 실행용 도구의 목록, 그리고 이번 버전에서 어디까지 열지.
• 모듈의 경계와, AI가 모듈을 넘나들 때의 권한 검증 위치.
• 개인정보, 지연, 비용, 외부 서비스 의존 같은 위험 목록.

앞서 쓴 글에서 "AI 기능의 자동화 수준을 어디까지 맡길지"와 "AI가 만든 결과를 내가 이해하고 있다고 말하려면"을 정리했는데, 이번 정리에서 그 기준을 그대로 적용해 볼 생각입니다.

정리가 끝나면 어떤 결정을 했고 왜 그렇게 정했는지 이어서 남겨 보겠습니다.