누가 무엇을 갖는지 정하면 인터페이스는 따라 나온다.

flowchart LR
    subgraph BE["Backend · Java/Spring"]
        U["사용자 · 친구 · 알림"]
        P["취향 프로필"]
        L["추천 리스트 self · gift"]
        F["피드백 원장"]
    end

    subgraph AI["AI Server · Python"]
        S["대화 세션 상태<br/>Redis · TTL 30분"]
        C["상품 카탈로그 + 벡터<br/>PostgreSQL + pgvector"]
    end

    P -->|요청마다 주입| AI
    F -->|요약본만 주입| AI
    AI -->|계산 결과 반환| P
    AI -->|계산 결과 반환| L

    style AI fill:#f0f7ff
    style C fill:#fff4e6

• POST /v1/recommendations가 profile 전체를 요청 본문으로 받는 근거가 이 표다. AI 서버가 스테이트리스라서가 아니라, 프로필을 소유하지 않기로 했기 때문이다.
• "AI 서버는 저장하지 않는다"는 원칙은 사용자 데이터에만 적용된다. 카탈로그는 명시적인 예외다.
• 경계를 여기 그은 근거는 네 가지다. 언어가 다르고(Java와 Python이라 한 프로세스에 담을 방법이 없다), 배포 주기가 다르며(프롬프트 수정이 주 단위로 일어난다), 교체 가능성이 있고(2단계가 상용 API를 자체 서빙으로 바꿨는데 백엔드는 한 줄도 바뀌지 않았다), 실패가 격리된다. 니쥬 화면 대부분은 AI를 호출하지 않으므로(모델 API 설계의 「사용자 대기가 발생하는 구간」), AI 서버가 502를 내도 서비스는 "새 대화를 시작할 수 없다"로 축소될 뿐이다. 이 성질은 경계를 이렇게 그었기 때문에 생긴 것이다.

2단계 O4는 KV 캐시 재사용을 위해 같은 세션을 같은 인스턴스로 보내라고 요구한다. 반대로 리스트 생성 잡은 아무 인스턴스나 집어야 처리량이 난다. 한 프로세스에 두면 둘 중 하나를 포기해야 한다.

flowchart LR
    BE["Backend"]

    subgraph API["api — 세션 고정 라우팅"]
        A1["인스턴스 #1<br/>세션 s_7a2b"]
        A2["인스턴스 #2<br/>세션 s_3f1c"]
    end

    Q[("Redis<br/>잡 큐")]

    subgraph W["worker — 아무나 집기"]
        W1["인스턴스 #1"]
        W2["인스턴스 #2"]
    end

    BE -->|sessionId 해시| A1
    BE -->|sessionId 해시| A2
    A1 -->|잡 등록| Q
    A2 -->|잡 등록| Q
    Q --> W1
    Q --> W2

    style API fill:#f0f7ff
    style W fill:#f0f7ff

• 스케일 축이 다르다. api는 동시 세션 수로, worker는 큐 대기 길이로 늘린다. 한 단위면 둘 중 하나 기준으로만 늘어난다.
• 리스트 생성이 도는 동안 SSE 스트림이 같은 이벤트 루프에서 밀린다. 사용자가 기다리는 유일한 경로가 기다리지 않는 작업에 막히는 구조다.
• 잡 큐는 새로운 계약이 아니라 기존 계약의 구현이다. 1단계가 리스트 생성을 202 + jobId + 폴링으로 정해뒀기 때문에, 뒤를 큐로 구현해도 백엔드와 재협의할 것이 없다.
• 프로필 확정은 잡이 아니다. 모델 호출이 요약문 하나뿐이라 close 요청 안에서 동기로 끝난다. api에 남고 큐를 타지 않는다. 큐를 타는 것은 사용자 확인 이후의 리스트 생성뿐이다.
• 잡 트리거가 하나에서 둘로 늘었다. 사용자 확정과 백엔드의 재생성 트리거가 같은 잡을 등록한다. 진입점이 둘이어도 등록되는 잡의 종류는 하나라 worker의 책임은 달라지지 않는다.

카탈로그 수집과 속성 추출, 상품 임베딩, 가격 재고 갱신은 오프라인 작업이다. 이것이 서빙과 같은 프로세스면 성능 목표가 배치 스케줄에 의존하게 된다.

무중단 재색인은 batch가 분리돼 있어야 성립한다.

flowchart TD
    S1["① batch가 새 벡터 컬럼(v2)을 채운다"] --> S2["② 커버리지 100% 확인"]
    S2 --> S3["③ worker의 읽기 대상을 v2로 전환<br/>배포 1회"]
    S3 --> S4["④ 안정화 후 v1 컬럼 제거"]
    S1 -.그동안.-> R["worker는 v1으로 계속 검색<br/>서빙 무중단"]
    S3 -.실패하면.-> B["v1으로 되돌린다<br/>배포 1회"]

    style R fill:#e6f0ff

• TTFT p95 1초 목표가 배치가 안 돌 때만 성립한다면 목표로서 의미가 없다. 상품 벡터 재계산이 같은 GPU를 잡으면 대화 턴이 그만큼 밀린다.
• 임베딩 버전 불일치는 조용히 실패하는 유일한 계약이다. 다른 계약은 에러를 내지만 이것은 검색 결과가 이상해질 뿐이라 알아채기 어렵다. 그래서 상품 벡터 컬럼에 모델 버전을 박고, worker가 검색 전에 자기 임베딩 버전과 대조한다.
• 취향 벡터와 상품 벡터는 같은 벡터 공간이어야 한다. 이 제약이 batch와 worker를 데이터로 묶으므로, 코드로도 묶지 않으려면 공유 지점을 DB 컬럼 하나로 좁혀야 한다.
• 모듈화하지 않았다면 재색인은 새벽에 서비스를 내리고 하는 작업이 된다. 지금 설계에서는 배포 한 번이고, 되돌리는 것도 배포 한 번이다.

프롬프트 문구 수정은 주 단위로 일어나고 초 단위로 끝나야 한다. 8B BF16 모델 로드는 분 단위가 될 수 있다.

flowchart LR
    subgraph APP["앱 — 초 단위 배포 · 주 단위 변경"]
        A["api"]
        W["worker"]
        B["batch"]
    end

    subgraph RT["model-runtime — 분 단위 로드 · 드물게 변경"]
        M1["응답·요약·검색문 모델<br/>kanana-1.5-8b BF16"]
        M2["턴 델타 추출 모델<br/>kanana-2-1.3b BF16"]
        M3["외부 임베딩 API"]
    end

    A -->|OpenAI 호환 HTTP| RT
    W --> RT
    B --> RT

    style RT fill:#f3e8ff

• 앱과 모델이 한 단위면 프롬프트 한 줄을 고칠 때마다 모델을 다시 로드하게 된다. 배포 시간이 초에서 분으로 늘고, 변경 빈도가 가장 높은 작업이 가장 느린 작업에 묶인다.
• 과제문이 말하는 "모델 서빙 부분의 분리"가 니쥬에서는 이 항목이다. 프로토타입이 이미 OpenAI 호환 HTTP로 부르고 있으므로(chat/llm.py), 구조를 바꾸는 작업이 아니라 배포 단위로 못 박는 작업이다.
• 2단계 O5의 역할별 모델 분리(응답·재작성 8B, 추출 1.3B)가 이 경계 안에 들어온다. 앱은 어느 모델인지가 아니라 어느 포트인지만 알고 부르므로, 모델을 바꿔도 호출부가 바뀌지 않는다.
• 표준 인터페이스(OpenAI 호환)를 쓰는 덕에 vLLM과 SGLang, 상용 API가 같은 클라이언트로 교체된다. 2단계에서 상용 API를 로컬 서빙으로 바꿔도 백엔드가 바뀌지 않는다고 한 것을, 이 경계가 AI 서버 내부에서도 성립시킨다.

• 공유하는 것이 스키마 하나뿐이면 패키지 경계로 충분하고, 여러 개면 서비스로 나눠야 한다. 니쥬는 전자에 해당한다.
• 분할의 이득은 인스턴스 수가 아니라 배포와 실패가 독립된다는 데서 나온다. 초기에는 같은 노드의 별도 프로세스로 시작해도 이득이 실현되고, 인스턴스를 늘릴 때 코드를 고칠 필요가 없다.