AX를 위한 SaaS/Cloud 아키텍처 설계 원칙

홍동희

CTO

Rutgers Univ. 컴퓨터공학 석사, 메가존클라우드 Tech 그룹장

2024.11.13

AX 기능은 데모로 만들 때와 운영할 때의 난이도가 다릅니다. 데모에서는 모델 호출 한 번으로 멋진 결과가 나오지만, 실제 기업 환경에서는 권한, 비용, 장애, 로그, 데이터 격리, 재처리, 감사 대응까지 고려해야 합니다. 그래서 AX를 위한 SaaS/Cloud 아키텍처는 일반 웹서비스보다 운영 설계가 더 중요합니다.

AI 자동화 기능은 외부 모델, 내부 데이터, 사용자 권한, 비동기 작업, 파일 처리, 알림, 관리자 검수 화면이 얽혀 있습니다. 이 구조를 처음부터 단순한 API 호출로만 설계하면 사용량이 늘어나는 순간 비용과 장애가 폭발합니다. 좋은 아키텍처는 모델보다 먼저 경계와 흐름을 정의합니다.

원칙 1: 테넌트와 권한을 먼저 분리한다

기업용 AX에서 가장 중요한 것은 데이터 격리입니다. 고객사별 데이터, 부서별 권한, 사용자별 접근 범위가 명확히 나뉘어야 합니다. AI 기능은 여러 데이터를 조합하기 때문에 권한 오류가 한 번 발생하면 피해가 큽니다.

멀티테넌시 설계에서는 다음 항목을 분리해야 합니다.

테넌트별 데이터 저장 범위
사용자 역할과 권한
AI가 조회할 수 있는 데이터 범위
생성 결과물의 소유권
로그와 감사 데이터의 보관 범위

특히 RAG나 문서 검색을 붙일 때는 벡터 저장소의 네임스페이스를 반드시 분리해야 합니다. 문서 원본은 분리되어 있어도 임베딩 인덱스가 섞이면 검색 결과에서 정보가 새어 나갈 수 있습니다.

원칙 2: AI 호출은 비동기 작업으로 다룬다

AI 호출은 일반 API보다 지연 시간이 길고 실패 가능성이 높습니다. 사용자가 버튼을 누를 때마다 동기적으로 모델 응답을 기다리게 만들면 UX가 느려지고, 장애 처리도 어려워집니다. 중요한 AX 작업은 비동기 큐로 처리하는 편이 안전합니다.

대표적인 구조는 다음과 같습니다.

사용자가 작업을 요청합니다.
서버는 작업 ID를 만들고 큐에 넣습니다.
워커가 데이터 조회, 프롬프트 구성, 모델 호출을 처리합니다.
결과와 로그를 저장합니다.
사용자에게 완료 상태를 보여주거나 알림을 보냅니다.

이 구조를 쓰면 재시도, 타임아웃, 우선순위 처리, 비용 제한을 적용하기 쉽습니다. 또한 사용자는 기다리는 동안 다른 작업을 할 수 있고, 실패해도 작업 단위로 복구할 수 있습니다.

원칙 3: 비용을 기능 단위로 추적한다

AI 비용은 사용량이 늘수록 예측이 어려워집니다. 특히 문서 요약, 대량 분류, 리포트 생성처럼 토큰 사용량이 큰 기능은 월말에야 비용 문제가 보이는 경우가 많습니다. AX 아키텍처는 초기부터 비용 추적을 넣어야 합니다.

기능 단위로 다음 값을 기록합니다.

호출한 모델
입력 토큰과 출력 토큰
작업 유형
사용자와 테넌트
성공 여부
재시도 횟수
예상 비용

이 로그가 있으면 어떤 고객사, 어떤 기능, 어떤 워크플로가 비용을 많이 쓰는지 알 수 있습니다. 비용을 모르면 가격 정책도 만들 수 없고, 사용량 제한도 설계할 수 없습니다.

원칙 4: 프롬프트와 결과를 버전 관리한다

AX 기능은 프롬프트 변경만으로도 결과가 크게 달라질 수 있습니다. 따라서 프롬프트는 코드처럼 버전 관리해야 합니다. 어떤 버전의 프롬프트가 어떤 결과를 만들었는지 추적할 수 있어야 오류 분석이 가능합니다.

우리는 다음 정보를 함께 저장합니다.

항목	이유
프롬프트 버전	결과 변화 추적
입력 데이터 스냅샷	재현 가능성
모델명	성능과 비용 비교
출력 결과	품질 평가
사람 수정 내용	개선 데이터
승인 여부	운영 품질 판단