[기술선택근거] AI 채팅에 REST와 SSE를 선택한 이유

AI 쇼핑 채팅에 REST와 SSE를 선택한 이유

사용자 요청은 REST로 처리하고, 실시간 진행 상황과 결과 전달에는 SSE를 활용한다.

이번 프로젝트에서 AI와 대화하며 상품을 찾고, 견적을 받은 뒤 주문까지 연결하는 채팅 기능을 맡았다.

채팅 구현 방식으로 REST, SSE, STOMP를 비교했다. 기술의 특징을 먼저 살펴보고, 우리 기능에 필요한 통신 방식이 무엇인지 기준으로 구현 방향을 정했다.

---

01. REST — 요청을 보내고 응답을 받는다

REST는 자원을 중심으로 API를 설계하는 아키텍처 스타일이다. 일반적으로 HTTP의 GET, POST 등의 메서드로 데이터를 조회하거나 생성한다.

채팅에서는 사용자가 메시지를 보내면 서버가 AI와 도구를 호출하고, 완성된 답변을 HTTP 응답으로 반환하는 방식으로 활용할 수 있다.

메시지 전송 → AI·도구 호출 → 완성된 답변 반환

기존 Spring MVC 구조에서 구현하기 익숙하고, 채팅방 생성이나 대화 내역 조회에도 적합하다. 다만 일반적인 요청·응답만 사용하면 처리 중간의 진행 상황이나 나중에 발생한 상태 변경을 즉시 전달하기 어렵다.

02. SSE — 서버가 이벤트를 전달한다

SSE는 HTTP 연결을 유지하면서 서버가 클라이언트에 이벤트를 보내는 단방향 통신 방식이다. 사용자의 메시지는 REST API로 받고, 서버의 진행 상황과 결과는 SSE로 전달할 수 있다. 

우리 프로젝트에서는 다음과 같은 정보를 보내는 데 활용할 수 있다.

• “상품을 조회하고 있어요.”
• “견적이 준비됐어요.”
• “주문 상태가 변경됐어요.”

SSE를 사용한다고 반드시 AI 답변을 글자 단위로 출력해야 하는 것은 아니다. 검증이 끝난 견적이나 완성된 답변을 이벤트로 전달하는 것도 가능하다.

03. STOMP — 메시지 전송과 구독 규칙을 제공한다

STOMP는 메시지를 보내고 구독하는 규칙을 정의한 메시징 프로토콜이다. 브라우저에서는 일반적으로 양방향 통신을 지원하는 WebSocket 위에서 사용한다.

클라이언트가 특정 채팅방을 구독하면 서버가 해당 구독자에게 메시지를 전달하는 구조를 만들 수 있다. Spring에서는 이를 위한 메시지 처리와 브로커 연동 기능을 제공한다.

여러 사용자가 같은 방에서 대화하거나 양방향 이벤트가 빈번하게 발생하는 기능에 활용하기 좋다. AI 채팅에도 사용할 수 있지만, 현재 요구사항에서는 구독과 메시지 분배 구조의 필요성이 크지 않았다.

---

우리 채팅에 필요한 방식은 무엇인가?

현재 핵심 흐름은 사용자 요청 → 상품 조회 → 견적 발급 → 사용자 확인 → 주문이다.

사용자의 행동은 메시지 전송이나 견적 확인처럼 명확한 HTTP 요청으로 표현할 수 있다. 추가로 필요한 실시간 기능은 서버가 처리 중인 상태와 완료 결과를 알려주는 것이다.

이 요구사항을 기준으로 다음과 같이 역할을 나눴다.

구분	담당 기능	선택
사용자 요청	메시지 전송, 견적 확인	REST
데이터 조회	채팅방 목록, 과거 메시지	REST
실시간 알림	진행 상황, 처리 완료 결과	SSE
채팅방 구독·양방향 메시징	현재 필수 요구사항 없음	STOMP 도입 보류

REST와 SSE는 각각을 선택하는 것이 아니라 요청·조회와 실시간 알림을 나누어 함께 사용할 수 있다.

---

구현은 두 단계로 진행한다

① MVP: REST로 핵심 흐름 완성

먼저 메시지를 저장하고, AI와 상품·견적 도구를 호출한 뒤, 검증된 답변을 저장하여 HTTP 응답으로 반환한다. 처리 중에는 화면에 로딩 상태를 표시한다.

[예] 버튼도 REST API로 처리한다. 이때 LLM이 주문 여부를 다시 판단하게 하지 않고, 서버가 사용자 권한과 견적 유효성을 검증한 뒤 주문 기능을 호출한다.

② 확장: SSE로 진행 상황과 결과 전달

핵심 흐름이 완성되면 메시지 접수와 결과 전달을 분리하고, SSE로 처리 상태와 완료 결과를 보낸다.

Spring MVC의 SseEmitter를 사용할 수 있으므로 SSE를 도입하기 위해 전체 프로젝트를 WebFlux로 전환할 필요는 없다. 

최종 메시지는 DB에 저장하고, 연결이 끊겼다가 돌아온 사용자는 REST 조회로 대화를 복구하도록 한다.

이번 기술 선택에서는 현재 필요한 기능과 구현 부담의 균형을 기준으로 삼았다. REST로 상품 조회부터 주문까지의 흐름을 먼저 완성하고, SSE로 사용자가 처리 과정을 확인할 수 있도록 확장할 계획이다.