Architecture

AI 데이터 플랫폼의 서비스 계층과 배포 구조

note

재직 중인 회사의 자료 유출 방지를 위해, 회사명·제품명·도메인·노드명 등 식별 정보를 제거하고 공개 가능한 아키텍처 수준에서만 정리합니다.

계층을 나눈 기준

서비스는 4개 계층으로 구분됩니다. 나눈 기준은 기술 종류가 아니라 바뀌는 이유와 속도입니다.

• Product Service (제품 진입점): 프론트엔드 SPA 가 직접 호출합니다. 하위 서비스를 gRPC 로 오케스트레이션해 제품 UX 응답을 합성합니다. 순수 BFF 가 아니라 제품 도메인 로직까지 수행합니다.
• Platform / Core (크로스 도메인 공통): account, organization, billing, community, observability
• Domain (단일 책임): datasets, agent, llmgateway, rag
• Workers (비동기): Temporal, NATS 컨슈머가 담당합니다. 이메일·알림·에이전트 실행·이벤트 포워딩·비식별 워크플로가 여기에 속합니다.

화면 문구는 자주 바뀌지만 과금 규칙은 잘 바뀌지 않습니다. 반대로 모델을 다루는 부분은 바깥 생태계가 움직일 때마다 흔들립니다. 자주 바뀌는 것과 그렇지 않은 것을 같은 자리에 두면 배포가 서로를 붙잡습니다.

Product Service 가 순수 BFF 가 아닌 이유

BFF(Backend For Frontend)는 보통 여러 서비스의 응답을 화면에 맞게 모아 주는 얇은 층을 뜻합니다. 판단은 하지 않고 모양만 맞추는 자리입니다.

여기서는 그보다 한 걸음 더 들어갑니다. "이 사용자가 이 데이터셋에 이 작업을 요청할 수 있는가", "지금 상태에서 다음 단계가 무엇인가" 같은 제품 고유의 판단이 화면 하나를 그리는 데 필요하기 때문입니다.

이 판단을 프론트엔드에 두면 SaaS 와 온프레미스 두 벌이 서로 어긋나기 시작합니다. 그래서 화면 조립과 제품 판단을 한 자리에 모으고, 그 아래 서비스들은 자기 도메인만 알도록 두었습니다.

두 제품이 같은 컨테이너를 공유한다는 것

이 구조에서 가장 까다로웠던 요구는 하나의 백엔드로 성격이 정반대인 두 배포 대상을 감당하는 일이었습니다.

	SaaS (AWS)	온프레미스 (K3s)
테넌시	여러 고객이 한 클라우드 공유	고객사마다 통째로 설치
인증	매니지드 서비스에 위임	클러스터 안에서 자급
네트워크	인터넷 전제	오프라인 환경과 양립
업데이트	우리가 배포	설치본을 전달

같은 기능인데 밑바닥이 다르니, 서비스 코드가 "지금 어디에서 도는가"를 알아야 하는 순간이 자꾸 생깁니다. 이걸 코드 곳곳에 분기로 흩어 두면 나중에 손댈 수 없게 됩니다.

그래서 차이를 설정과 어댑터 경계로 밀어내고, 서비스 본체는 양쪽에서 같은 이미지로 돌도록 맞췄습니다. 배포 분기를 화면 쪽에서 다룬 이야기는 SPA 런타임 설정 분기에, 폐쇄망 설치본 쪽은 에어갭 컨테이너 설치에 따로 적어 두었습니다.

Workers 를 따로 둔 이유

데이터셋 검증이나 비식별 처리는 요청 하나가 몇 분씩 걸리기도 합니다. 이런 작업을 요청 처리 경로에 두면 사용자는 브라우저를 붙잡고 기다려야 하고, 중간에 실패했을 때 어디까지 진행됐는지 알 수 없게 됩니다.

그래서 오래 걸리는 일은 전부 비동기로 넘기고, 진행 상태를 따로 관리합니다. 여러 단계 중 하나가 실패했을 때 앞 단계를 되돌리는 처리는 Saga 로 다룹니다. 관련 내용은 Temporal Saga 보상 트랜잭션과 NATS JetStream 리텐션에 정리해 두었습니다.

제품 아키텍처

두 엔드 서비스(SaaS / 온프레)가 같은 백엔드 컨테이너를 공유하는 구조.

전체 화면으로 열기 >>