DEVOCEAN

상용 프론티어 언어 모델 API를 호출해 기능을 구현하면 초기 개발 속도는 빠릅니다. 하지만 사용량이 늘어나는 순간 매달 수천만 원에 달하는 토큰 비용 청구서와 네트워크 지연 시간이 시스템을 옥죕니다. 동시에 데이터베이스 런타임에서도 "단순 조회니까 기본 트랜잭션 격리 수준이면 충분하다"는 안일한 전제가 데이터 불일치를 일으킵니다.

채널 AI팀은 상담 분석 파이프라인을 상용 대형 언어 모델(LLM)에서 자체 학습 모델로 전면 교체해 비용을 99.4% 절감하고 성능을 끌어올린 사례를 공개했습니다. 한편 Mercury 3는 토큰을 하나씩 순차적으로 뽑아내던 오토리그레시브(Auto-regressive, 이전 단어를 바탕으로 다음 단어를 차례대로 예측하는 방식) 한계를 깨고 텍스트를 병렬로 다듬어내는 확산 기반 언어 모델을 선보였습니다. 백엔드 데이터베이스 계층에서는 단순 SELECT 조회 API에서도 트랜잭션 격리 수준을 잘못 다루면 캐시 키와 값이 서로 다른 시점을 바라보는 결함이 발생한다는 구체적인 재현 결과가 공유되었습니다.

세 사례는 모두 같은 질문으로 수렴합니다. 시스템의 기본 설정과 범용 모델이 제공하는 편의 뒤에 숨은 비용, 지연 시간, 정합성 왜곡을 어디까지 걷어내고 도메인에 맞는 명시적 경계를 세울 것인가입니다.

닫힌 도메인에서 프론티어 모델 호출을 중단해야 하는 이유

채널코퍼레이션의 채널 AI팀은 고객 상담 분석에 사용하던 상용 프론티어 LLM을 직접 학습한 자체 모델 하나로 통합했습니다. 상담 분석은 세 가지 핵심 작업으로 나뉩니다. 첫째는 고객이 문의한 본질을 파악하는 핵심 이슈 추출, 둘째는 유사한 상담을 범주별로 분류하는 토픽 배정, 셋째는 상담원의 응답 품질과 완결성을 측정하는 상담 평가입니다.

기존에는 이 세 단계를 모두 상용 LLM API 호출로 처리했습니다. 하지만 호출 횟수에 비례해 기하급수적으로 늘어나는 비용 구조와 외부 API 응답 지연 시간은 실시간 대규모 분석 파이프라인의 명확한 병목이었습니다. 채널 AI팀은 세 가지 태스크를 단일 소형 모델로 해결하도록 전용 데이터셋을 구축해 파인튜닝했습니다. 결과는 명확했습니다. 상용 LLM 대비 인프라 운영 비용을 99.4% 절감했고, 세 가지 작업 전반에서 추출 정밀도와 토픽 분류 일치율 등 벤치마크 성능이 상용 LLM보다 개선되었습니다.

여기부터는 DEVOTEE의 해석입니다. 범용 프론티어 모델은 상식, 다국어 번역, 복합 코딩 등 광범위한 맥락을 처리하기 위해 거대한 파라미터 공간을 유지합니다. 그러나 상담 분류나 엔티티 추출처럼 입력 데이터의 패턴과 출력 형식(JSON 스키마 등)이 고정된 도메인에서는 90% 이상의 파라미터가 불필요한 연산 낭비로 작용합니다. 도메인이 명확히 닫혀 있을 때 소형 언어 모델(SLM)을 전용 태스크로 증류(Distillation)하거나 파인튜닝하는 아키텍처는 비용 구조를 완전히 재편합니다.

이 전환이 실무에서 주는 의미는 자명합니다. API 호출당 비용 과금(Pay-per-token) 방식에서 자체 서빙 인스턴스(GPU 서빙 노드) 고정 비용 구조로 전환되므로 트래픽이 폭증할수록 단위 요청당 처리 단가는 0에 수렴합니다.

이 판단은 지금 써볼 만합니다. 조건은 세 가지 작업처럼 입출력 인터페이스가 명확히 닫혀 있고, 사내에 평가 라벨링 데이터가 최소 수천 건 이상 축적되어 있어야 합니다. 반대로 태스크의 범위가 계속 바뀌거나 사용자의 자유 질의를 광범위하게 다루어야 하는 시스템이라면 자체 모델 파인튜닝과 서빙 파이프라인 구축 비용이 API 호출 비용을 초과할 수 있습니다.

순차 토큰 생성을 깨뜨리는 확산 기반 병렬 LLM: Mercury 3

소형 모델 전환이 서빙 비용을 해결한다면, 생성 모델의 근본적인 지연 시간(Latency)은 텍스트 생성 방식 자체를 재설계해야 풀립니다. 인셉션(Inception)이 공개한 Mercury 3는 기존 LLM의 표준 공식이었던 자기회귀(Auto-regressive) 방식을 탈피하고 확산(Diffusion, 노이즈 상태의 전체 문맥에서 동시에 단어를 정제해 나가는 방식) 구조를 도입했습니다.

기존 트랜스포머 기반 LLM은 첫 번째 토큰을 생성한 뒤 그 토큰을 다시 입력으로 넣어 두 번째 토큰을 예측하는 순차적 반복 루프를 돕니다. 생성해야 할 응답 길이가 1,000토큰이라면 어텐션 연산과 디코딩 패스를 최소 1,000번 반복해야 하므로 첫 토큰 지연 시간(TTFT) 이후에도 전체 토큰 생성 완료 시간(Total Generation Time)이 길어집니다. 반면 Mercury 3는 전체 텍스트 시퀀스의 여러 위치를 동시에 병렬로 다듬어 생성합니다. 원문에 따르면 첫 모델 대비 총 파라미터를 40배 이상 늘렸음에도 생성 속도를 유지하며 복잡한 태스크의 벤치마크 성능을 개선했습니다.

이 구조가 실무 백엔드 시스템에 던지는 질문은 명확합니다. 실시간 대화형 서비스에서 스트리밍 방식으로 글자가 한 자씩 타이핑되는 UI가 필요한지, 아니면 API 호출 간 통신이나 백그라운드 데이터 처리에서 완성된 JSON 페이로드를 단 몇 밀리초(ms) 안에 한꺼번에 받아야 하는지입니다.

여기부터는 DEVOTEE의 해석입니다. 오토리그레시브 모델은 인간의 사고 흐름처럼 순차적 추론 체인(Chain-of-Thought)을 전개할 때 문맥의 일관성을 유지하기 유리합니다. 반면 확산 기반 언어 모델은 초안 전체를 한 번에 올려두고 반복 정제(Denoising steps)하므로, 스키마에 맞춘 문서 생성, 고정 템플릿 변환, 데이터 추출처럼 전체 구조가 상호 의존적인 작업에서 순차 모델보다 훨씬 적은 스텝 수로 결과를 도출할 수 있습니다.

이 기술에 대한 판단은 조건부로 유효합니다. 백엔드 서비스 간 RPC 통신에서 구조화된 긴 페이로드를 즉각적으로 병렬 생성해야 하거나 실시간 코드 패치를 생성하는 파이프라인에는 매우 유용합니다. 하지만 인과적 논리 전개가 엄밀해야 하는 수학적 연역이나 초장문 텍스트 생성에서는 확산 모델 특유의 노이즈 제거 과정에서 미세한 환각이나 토큰 불일치가 발생할 수 있으므로 벤치마크 검증을 거친 후 도입해야 합니다.

읽기 전용 API에서도 발생하는 정합성 붕괴와 트랜잭션 경계

언어 모델 계층에서 추론 구조를 정돈하더라도, 서비스의 근간인 데이터베이스 읽기 로직에서 데이터 시점이 뒤틀리면 전체 파이프라인이 오염됩니다. 최근 PostgreSQL 환경에서 게임 통계를 집계하고 캐시하는 과정에서 발생한 버그 보고는 많은 엔지니어에게 경종을 울립니다.

상황은 단순해 보이는 읽기 전용 로직이었습니다. 시스템은 게임 통계 데이터를 읽기 위해 첫 번째 SELECT 쿼리로 통계 기준 대상(예: 정산 회차나 집계 기준 키)을 조회하고, 두 번째 SELECT 쿼리로 해당 통계 수치(집계 값)를 계산하여 Redis 등 외부 캐시에 키-값 형태로 저장하는 구조였습니다. 그런데 두 SELECT 쿼리 실행 사이에 별도의 비동기 배치인 '정산 처리 트랜잭션'이 데이터베이스에 커밋되었습니다.

결과는 치명적이었습니다. 캐시의 키(Key)는 정산 전 기준 시점의 메타데이터를 담고 있었지만, 캐시의 값(Value)은 정산 후 갱신된 수치를 읽어 저장했습니다. 캐시 키와 값이 서로 다른 데이터베이스 스냅샷 시점을 가리키게 된 것입니다. 더 심각한 문제는 이미 열려 있던 다른 읽기 전용 트랜잭션(Read Only Transaction)조차 기본 격리 수준에서는 새로 커밋된 데이터를 그대로 읽어 들이며 불일치 상태를 애플리케이션 전반으로 전파했다는 점입니다.

원문은 PostgreSQL 18.4 환경에서 이 현상을 재현하고, 단순 READ ONLY 트랜잭션 선언과 REPEATABLE READ 격리 수준 간의 결정적 차이를 증명했습니다.

PostgreSQL의 기본 트랜잭션 격리 수준은 READ COMMITTED입니다. 이 격리 수준에서는 트랜잭션이 시작될 때 스냅샷을 고정하는 것이 아니라, 트랜잭션 내부의 '각 쿼리가 실행될 때마다' 새로운 스냅샷을 캡처합니다. 따라서 트랜잭션 내에서 SELECT 쿼리를 두 번 실행하는 사이에 다른 커밋이 발생하면, 같은 트랜잭션 안에서도 두 번째 SELECT는 첫 번째 SELECT와 완전히 다른 세상(스냅샷)을 보게 됩니다. READ ONLY 옵션은 오직 쓰기 작업을 금지할 뿐, 쿼리 간 스냅샷 격리를 보장하지 않습니다.

이 문제를 해결하기 위해서는 트랜잭션 시작 시점의 스냅샷을 트랜잭션 종료 시까지 고정하는 REPEATABLE READ 격리 수준을 명시해야 합니다.

-- 잘못된 방식: 단순 READ ONLY는 각 SELECT마다 최신 커밋 스냅샷을 다시 읽습니다.
BEGIN TRANSACTION READ ONLY;
-- 1. 캐시 키 생성을 위한 메타데이터 조회 (시점 T1 스냅샷)
SELECT current_season_id, settlement_status FROM game_metadata WHERE id = 100;

-- [이 시점에 외부에서 정산 배치 트랜잭션이 커밋됨: T2 시점]

-- 2. 캐시 값 생성을 위한 집계 쿼리 실행 (시점 T2 스냅샷을 바라보며 데이터 불일치 발생)
SELECT user_id, SUM(score) FROM game_logs WHERE season_id = 100 GROUP BY user_id;
COMMIT;

-- 올바른 방식: REPEATABLE READ를 통해 트랜잭션 전체를 동일한 스냅샷(T1)으로 고정합니다.
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ READ ONLY;
-- 1. 첫 쿼리가 실행되는 순간 트랜잭션의 단일 스냅샷이 생성됩니다.
SELECT current_season_id, settlement_status FROM game_metadata WHERE id = 100;

-- [외부에서 정산 배치 트랜잭션이 커밋되어도 이 트랜잭션은 영향을 받지 않습니다.]

-- 2. 두 번째 쿼리 역시 첫 번째 쿼리와 동일한 T1 시점의 데이터를 읽습니다.
SELECT user_id, SUM(score) FROM game_logs WHERE season_id = 100 GROUP BY user_id;
COMMIT;

애플리케이션 계층(예: Node.js, Spring)에서 캐싱 서비스를 구축할 때도 쿼리를 분리해 호출하지 않고 단일 쿼리(CTE 또는 JOIN)로 조회 시점을 하나로 묶거나, 트랜잭션 템플릿의 격리 수준을 명시해야 합니다.

import { Pool, PoolClient } from 'pg';

interface GameStatsCache {
  seasonId: number;
  totalScore: number;
}

export async function fetchConsistentGameStats(pool: Pool): Promise<GameStatsCache> {
  const client: PoolClient = await pool.connect();
  try {
    // 단순 조회가 아니라 두 개 이상의 데이터를 조합해 원자적 캐시를 만들 때는
    // 반드시 REPEATABLE READ 격리 수준을 지정합니다.
    await client.query('BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ READ ONLY');

    const metaResult = await client.query<{ current_season_id: number }>(
      'SELECT current_season_id FROM game_metadata WHERE id = $1',
      [100]
    );
    const seasonId = metaResult.rows[0].current_season_id;

    const statsResult = await client.query<{ total_score: string }>(
      'SELECT COALESCE(SUM(score), 0) AS total_score FROM game_logs WHERE season_id = $1',
      [seasonId]
    );
    const totalScore = parseInt(statsResult.rows[0].total_score, 10);

    await client.query('COMMIT');

    return { seasonId, totalScore };
  } catch (error) {
    await client.query('ROLLBACK');
    throw error;
  } finally {
    client.release();
  }
}

이 판단은 지금 써볼 만합니다. 여러 테이블의 상태를 순차적으로 읽어 Redis 캐시를 빌드하거나 외부 시스템으로 전송하는 배치 및 API라면 격리 수준 설정은 선택이 아닌 필수입니다. 다만 REPEATABLE READ를 장시간 열어두면 데이터베이스가 롤백 세그먼트와 MVCC(다중 버전 동시성 제어) 튜플을 청소하지 못해 블로트(Bloat)가 발생하므로, 조회가 끝나면 즉시 트랜잭션을 닫아야 합니다.

도입 전 확인할 것: 세 가지 런타임 최적화 체크리스트

시스템을 기본값에서 전용 아키텍처로 전환하기 전에 각 팀이 먼저 확인해야 할 점검 기준을 정리합니다.

1. 소형 모델(SLM) 자체 학습 전환 검토

• 분석 태스크의 입력 프롬프트와 출력 구조(스키마)가 지난 3개월간 안정적으로 유지되었는지 확인합니다.
• 상용 API 호출 비용이 월간 수백만 원 이상 발생하고 있으며, 자체 GPU 인스턴스 1~2대를 띄워 유지하는 비용보다 현저히 큰지 계산해야 합니다.
• 상담 분석처럼 도메인 데이터가 외부 클라우드로 유출되는 것을 차단해야 하는 보안 규제가 존재하는지 검토합니다.

1. 확산 기반 생성 모델 도입 시 지연 시간 특성 검토

• 시스템이 사용자와의 인터랙션을 위해 글자 단위 스트리밍(SSE, Server-Sent Events) 출력을 전제로 설계되어 있는지 확인합니다. 단어 스트리밍이 필수적인 UI라면 확산 기반 LLM의 장점이 반감됩니다.
• 한 번의 호출로 정형화된 JSON 데이터나 다중 필드를 동시에 고속 완성해야 하는 내부 RPC 구간인지 평가합니다.

1. 읽기 전용 트랜잭션의 격리 수준 검증

• 애플리케이션 내에서 캐시 키와 밸류를 생성할 때 복수의 SELECT 쿼리가 독립된 연결이나 기본 READ COMMITTED 상태에서 실행되고 있지 않은지 확인합니다.
• 조회가 긴 배치 작업에 REPEATABLE READ를 적용할 경우 데이터베이스의 dead tuple 증가율과 VACUUM 지연 모니터링 알림이 설정되어 있는지 점검합니다.

그 밖의 소식

• 모바일 앱 QA, 어디서 어떻게 검증해야 할까 — 디자인 검수를 넘어 소프트 키보드, 시스템 UI, 홈 인디케이터 등 실기기 사용 흐름 검증 전략을 공유했습니다.
• 서버 터질까 봐 만든 도구, 돈 내고 쓰는 기능이 되기까지 — 앨범 예약판매로 초당 4,723건 트래픽이 몰렸을 때 무중단 대응을 이끌어낸 내부 도구 '아임터보'의 상용화 이야기입니다.
• GitHub Actions, GitHub Pages, Webhooks 가용성 저하 — 2026년 10월 19일 16:56 UTC 기준 워크플로 및 웹훅 지연 장애가 복구되었습니다.