토스증권 AI 서비스를 지탱하는 백엔드 엔지니어링

원제: 토스증권 AI 서비스를 지탱하는 백엔드 엔지니어링
URL: https://www.youtube.com/watch?v=lfyKfUFf-sk
날짜: 2026-10-01
채널: Toss Challengers
발표자: 임효섭, 토스증권 AI User Journey Silo 백엔드 엔지니어
영상 길이: 15분 45초

---

메타데이터

• 콘텐츠 유형: AI 제품을 운영하기 위한 백엔드 엔지니어링 사례 발표
• 사례 제품: 해외 기업의 실시간 어닝콜 번역·요약 서비스, AI 시그널
• 핵심 질문: 생성형 AI의 비결정성·지연·부분 실패·비용·품질 측정 문제를 기존 백엔드의 품질 원칙과 운영 도구로 어떻게 다룰 것인가?
• 자막 처리: 한국어 자동 자막을 시간순으로 읽고, LLM, JSONL, Kafka, SSE, DLQ, SLO, dynamic config 등 문맥상 명확한 기술 용어를 보정했다.

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 제품의 백엔드 문제는 완전히 새로운 기술을 발명해야 하는 문제가 아니라, 기존 소프트웨어 품질 원칙을 생성형 AI의 특성에 맞게 다시 적용하는 문제다.==

• AI 컴포넌트는 같은 입력에도 결과가 달라지고, P99 지연이 초 단위이며, HTTP 200이어도 내용이 틀릴 수 있다.
• 사용량에 따라 비용이 선형으로 증가하고, 정답이 없는 출력 품질은 기존 가용성 지표만으로 측정할 수 없다.
• 토스증권 팀은 이벤트 스트리밍, 캐싱·압축, DLQ 재시도·폴백 모델, 모니터링, 동적 설정으로 효율성·신뢰성·유지보수성을 확보했다.
• 앞으로의 백엔드 엔지니어는 이미 정해진 AI 워크플로를 안정화하는 사람을 넘어 프로토타이핑과 제품 성장에도 참여해야 한다.

발표의 결론은 “AI라서 기존 백엔드가 무용해졌다”가 아니다. 모델은 파이프라인 안의 외부 노드처럼 다루고, 그 주변에 기존의 분산 시스템·운영·품질 관리 원칙을 적용하면 안정적인 AI 제품을 만들 수 있다. 다만 제품의 품질을 지키는 것과 AI 제품을 처음부터 만들고 시장에 맞게 키우는 것은 다른 문제이므로, 역할 경계를 넘나드는 새로운 개발 방식이 필요하다.

0. 도입: 토스증권이 AI 제품을 만들기 시작한 배경

0.1. 2025년 상반기, 성능 향상에서 제품 출시로

1. LLM 성능이 제품화의 문턱을 낮춤

   1. 2025년 상반기에는 언어 모델 성능이 빠르게 좋아지면서 생성형 AI를 실제 서비스에 넣을 수 있다는 분위기가 업계 전반에 퍼졌다.
   2. 토스증권도 AI 시대의 첫 항해를 시작했고, 출발점은 해외 기업 어닝콜을 실시간으로 번역하는 서비스였다.

2. 어닝콜 서비스의 빠른 출시

   1. 팀은 짧은 기간 안에 서비스를 최대한 빠르게 런칭했다. 자동 자막의 해당 구간은 출시 기간을 약 3.5~5개월로 인식하고 있어, 발표자는 이를 “빠르게 출시한 경험”으로 설명한다.
   2. 어닝콜을 성공적으로 출시한 경험은 AI를 제품에 적용하는 속도를 더 높이는 발판이 됐다.

0.2. 생성형 AI 컴포넌트가 전통적인 컴포넌트와 다른 점

어닝콜을 운영하면서 팀은 AI 컴포넌트가 기존에 만들던 결정론적 백엔드 컴포넌트와 성질이 다섯 가지로 다르다는 사실을 발견했다.

1. 비결정성(Non-determinism)

   1. 같은 입력을 넣어도 출력이 달라진다.
   2. 테스트가 일반적인 동일성 비교로 끝나지 않으며, “한 번 성공했으니 다음에도 같은 결과가 나온다”는 전제가 깨진다.

2. 레이턴시 분포(Latency distribution)

   1. P99 지연이 기본적으로 초 단위까지 늘어난다.
   2. 따라서 타임아웃을 어디에 얼마로 둘지는 단순한 인프라 설정이 아니라 사용자 경험(UX)을 설계하는 결정이 된다.

3. 부분 실패(Partial failure)

   1. HTTP 200처럼 응답 자체는 성공해도 번역이나 요약의 내용이 틀린 실패가 존재한다.
   2. 전통적인 상태 코드와 서버 생존 여부만으로는 사용자가 실제로 받은 결과의 유효성을 판단할 수 없다.

4. 비용의 선형 증가

   1. 모델 사용량이 늘면 비용도 대체로 사용량에 비례해 증가한다.
   2. 성능을 올리기 위해 무작정 재시도·병렬화하면 품질뿐 아니라 비용까지 함께 악화될 수 있다.

5. 정답이 없는 SLO

   1. 가용성은 응답이 200인지 500인지로 비교적 명확하게 측정할 수 있다.
   2. 그러나 번역·요약의 품질에는 항상 정답 데이터가 있는 것이 아니므로, 팀이 품질 측정 장치를 직접 만들어야 한다.
   3. 측정 장치가 없으면 문제를 실시간으로 발견하지 못하고 며칠 뒤 고객센터(CS) 문의로 알게 된다.

0.3. ISO 250 계열 품질 특성으로 다시 나누기

발표자는 위의 문제를 “AI만의 새로운 문제”로 취급하기보다, 올드 스쿨인 ISO 250 계열 소프트웨어 품질 특성에 연결해 해결 방향을 잡았다.

1. 신뢰성(Reliability): 비결정성과 부분 실패처럼 장애나 기능 상실로 이어지는 문제를 다룬다.
2. 효율성(Efficiency): 들쭉날쭉한 레이턴시와 사용량에 따라 증가하는 비용을 다룬다.
3. 유지보수성(Maintainability): 정답이 없는 출력 품질을 관측하고 조정할 수 있는 장치를 만든다.

문제를 품질 특성으로 분리하면 방향이 보인다. 이후 발표자는 어닝콜과 AI 시그널에서 실제로 적용한 여섯 가지 사례를 소개한다.

1. 효율성 사례 1 — 어닝콜 이벤트 스트리밍 아키텍처

1.1. 문제: S3에서 갱신되는 실시간 스크립트

1. 외부 데이터의 형태

   1. 토스증권은 해외 기업 어닝콜의 오디오 스트리밍과 그 오디오에 매핑되는 스크립트를 외부 업체로부터 받았다.
   2. 스크립트는 S3의 JSONL 파일로 실시간 업데이트됐다.
   3. 팀의 과제는 이 파일을 가져와 번역·요약하고, 결과를 사용자에게 실시간으로 전달하는 것이었다.

2. 한 번의 추론으로 여러 사용자에게 전달

   1. 어닝콜이 시작되면 하나의 서버 모듈이 스크립트를 폴링해 수집한다.
   2. 수집한 이벤트는 Kafka로 보내 번역과 요약을 처리한다.
   3. 처리 결과는 SSE(Server-Sent Events)로 클라이언트에 브로드캐스팅한다.

1.2. 설계 의도: 비용과 지연을 함께 줄이기

1. 추론 라인 단일화

   1. 한 어닝콜에 접속한 사용자가 몇 명이든 모델 추론은 한 번만 수행한다.
   2. 사용자마다 같은 내용을 다시 추론하지 않으므로 비용을 최소화할 수 있다.

2. 저지연 전달

   1. 번역과 요약 자체가 초 단위로 걸리기 때문에 애플리케이션이 추가하는 지연을 줄여야 한다.
   2. 모델의 번역·요약 품질은 모델과 프롬프트 처리에 맡기고, 백엔드 팀은 이벤트 수집·처리·전달 구조를 책임졌다.

2. 효율성 사례 2 — 문단 단위 입력을 더 짧게 쪼개기

2.1. 운영 중 발견한 레이턴시 병목

1. 사용자는 번역과 요약을 오래 기다렸다

   1. 어닝콜 출시 뒤 사용자들이 번역과 요약 결과를 예상보다 많이 기다린다는 사실을 알게 됐다.
   2. 외부 업체가 주는 스크립트가 문장이 아니라 문단 단위였고, 문단 전체를 모델에 보내면 추론 시간이 길어졌다.

2. 폴링 서버 안에 문단 분할 컴포넌트 추가

   1. 팀은 스크립트 폴링 서버에 문단 나누기 컴포넌트를 만들었다.
   2. 벤더의 긴 문단을 더 짧은 단위로 잘라 모델에 전달하고, 잘린 조각의 순서는 보장했다.
   3. 그 결과 추론 시간이 줄고, 사용자가 번역·요약을 받는 흐름도 훨씬 매끄러워졌다.

3. 효율성 사례 3 — AI 시그널의 캐시·압축 설계

3.1. AI 시그널 메인 화면의 부하

1. 화면 구성

   1. AI 시그널 메인 화면은 특정 시점에 발행된 리즈닝(reasoning) 목록에 랭킹을 적용한 Top 30과 연관 종목 그래프로 구성된다.
   2. 랭킹 대상 리즈닝 목록은 최대 2,000개까지 늘어날 수 있다.

2. 두 가지 규모 문제

   1. 화면 트래픽은 최대 2,000 TPS까지 발생할 수 있어, 매 요청마다 랭킹용 리즈닝 목록을 데이터베이스에서 읽으면 DB에 큰 부하가 걸린다.
   2. 응답은 그래프 데이터와 LLM이 생성한 텍스트를 함께 포함해 2KB를 넘을 수 있다.

3.2. 워크플로우 단계의 이중 적재와 응답 캐싱

1. 생성 시점에 데이터베이스와 캐시에 동시에 기록

   1. 리즈닝을 만드는 AI 워크플로우에서 생성 결과를 데이터베이스와 캐시에 동시에 적재한다.
   2. 요청 경로에서는 캐시를 우선 사용하고, 데이터베이스는 폴백으로만 사용한다.

2. 그래프 데이터 사전 생성·압축

   1. 랭킹이 적용된 그래프 데이터는 요청 때마다 만들면 CPU를 많이 사용하므로 미리 생성한다.
   2. 캐싱할 때는 응답 크기를 고려해 Gzip으로 압축했다.
   3. 이 설계는 DB 부하, CPU 재계산, 네트워크 전송량을 함께 낮추는 자원 효율성 전략이다.

4. 신뢰성 사례 — DLQ 재시도와 폴백 모델

4.1. 실시간 제품에서 추론 하나의 실패가 만드는 연쇄 장애

1. 번역과 요약이 오디오 흐름에 결합돼 있다

   1. 어닝콜은 오디오 스트리밍과 텍스트 번역·요약이 맞물려 돌아간다.
   2. 번역 또는 요약 하나가 빠지면 사용자 경험이 즉시 무너진다.
   3. 핵심 기능인 만큼 거의 99% 이상, 발표 맥락상 99.99%에 가까운 성공률이 요구된다.

2. 동시 어닝콜로 인한 모델 추론 문제

   1. 초기 런칭 때는 동시에 여러 어닝콜이 열리는 상황까지 충분히 고려하지 못했다.
   2. 운영 중 여러 어닝콜이 같은 시간에 열리자 모델 추론에서 문제가 발생하는 것을 확인했다.

4.2. 전통적인 메시지 처리 패턴의 적용

1. DLQ(Dead Letter Queue) 재시도

   1. 이벤트 스트리밍 파이프라인에서 실패한 메시지를 DLQ로 보내는 전통적인 복구 패턴을 먼저 적용했다.
   2. DLQ에 쌓인 작업을 재시도해 일시적인 모델·외부 시스템 문제를 복구한다.

2. 폴백 모델

   1. DLQ 재시도마저 실패하는 경우를 대비해, 비슷한 품질을 낼 수 있는 폴백 모델을 준비했다.
   2. 이 사례가 주는 핵심은 파이프라인 안에서 AI 모델을 외부 노드처럼 바라보면 기존의 재시도·대체·격리 패턴을 적용할 수 있다는 점이다.

5. 유지보수성 사례 1 — AI 제품 진단 대시보드

5.1. 기존 모니터링이 답하지 못한 질문

1. 서버가 살아 있는 것만으로는 부족하다

   1. 기존 모니터링은 서버가 살아 있는지, HTTP 응답이 200인지까지는 보여줬다.
   2. 그러나 어닝콜이 진행되는 동안 번역과 요약이 실제로 몇 퍼센트 성공했는지는 알려주지 못했다.
   3. 실시간 제품에서는 진행 중에 문제를 찾지 못하면 어닝콜이 끝난 뒤에야 CS를 통해 알게 된다.

2. 대시보드에서 볼 네 가지

   1. 추론 성공률: 번역·요약이 성공적으로 처리되는 비율을 본다.
   2. 시스템 응답 상태: 서비스가 요청에 어떤 상태로 응답하고 있는지 본다.
   3. 인프라 상태: 모델 주변의 실행 환경과 자원 상태를 본다.
   4. 오류 유형: 어떤 종류의 실패가 발생했는지 구분한다.
   5. SSE 커넥션 수: 추론이 성공해도 연결이 끊기면 사용자에게 결과가 도달하지 않으므로 현재 시청자 연결 수를 함께 본다.

5.2. 관측성의 본질

1. 지표를 정의하고 대시보드를 만들고 임계치를 넣으면 알림을 받는다는 점에서는 기존 서비스 운영과 크게 다르지 않다.
2. 달라진 점은 관측 대상에 AI 모델이 추가됐다는 것이다.
3. 모니터링 지표가 좋아도 생성 결과가 좋은 것이라는 뜻은 아니다. 상태를 보는 장치와 결과 품질을 판단하는 장치는 구분해야 한다.

6. 유지보수성 사례 2 — 동적 설정으로 운영 중인 조건값 바꾸기

6.1. 제품 품질을 결정하는 것은 코드보다 조건값일 수 있다

1. AI 시그널의 조건값

   1. 어떤 뉴스를 시그널 후보로 볼지 판단하는 키워드 목록이 있다.
   2. 이상 징후를 판단하는 임계값도 있다.
   3. 이런 값들은 제품 품질에 큰 영향을 주지만 출시 시점에 정답을 미리 알 수 없다.

2. 시장 중 배포할 수 없는 도메인 특성

   1. 운영 중 사용자 반응을 보고 조건값을 조정해야 한다.
   2. 값을 코드의 상수로 넣으면 작은 수정에도 배포가 필요하다.
   3. 증권 도메인에서는 시장이 가장 크게 움직여 조건을 바꿔야 하는 순간에 오히려 장중 배포가 자유롭지 않다.

6.2. 관리자 화면과 피드백 루프

1. 팀은 조건값을 코드에서 분리해 dynamic config로 만들었다.
2. 관리자가 어드민에서 값을 바꾸면 재배포 없이 설정이 즉시 반영된다.
3. 앞서 만든 대시보드로 결과를 보고, 어드민에서 조건을 조정하고, 다시 결과를 관측하는 순환이 만들어졌다.
4. AI라서 완전히 새로 발명한 방식이 아니라 기존 서비스에서 이미 사용하던 운영 패턴을 AI 제품에 적용한 사례다.

7. 기술을 넘어선 조직의 변화

7.1. 직무 경계가 낮아지고 업무가 늘어난다

1. 숙련도 장벽의 하락

   1. 예전에는 직무와 숙련도가 역할 사이의 경계를 만들어 줬다.
   2. 이제 AI가 그 숙련도 장벽을 낮추면서 디자이너가 동작하는 프로토타입을 만들고, 엔지니어가 화면 흐름과 카피를 손보는 일이 늘었다.
   3. “디자인을 할 줄 안다”, “코딩을 할 줄 안다”만으로는 더 이상 충분한 차별점이 되지 않는다.

2. 조직·업무의 재편

   1. 기존 도메인 조직 외에 AI 제품과 인프라를 전담하는 조직이 생긴다.
   2. 엔지니어는 AI 제품·인프라·모델을 잇는 직군 간 협업을 해야 한다.
   3. 원래 하던 백엔드 업무 위에 AI 워크플로우와 에이전트 개발, 모델을 위한 데이터 수집·정제 업무가 추가된다.

3. 경계에서 생기는 병목

   1. 제품을 담당하는 사람은 더 빨라지지만, 기존 직군의 인력 부족은 만성적으로 남을 수 있다.
   2. 익숙하지 않은 스택에 도전하면서 직군 경계에서 병목이 발생하고 안정화 기간도 길어진다.
   3. 따라서 개별 제품의 품질을 지키는 것과 조직 전체가 더 많은 AI 제품을 만들 수 있게 하는 것은 별도의 문제다.

8. Claude Code 팀의 다섯 가지 일하는 방식과 토스증권의 현재 위치

발표자는 Claude Code 팀을 관찰한 글에서 엔지니어링·프로덕트·디자인·데이터 사이언스가 하나의 제품 만들기 업무로 녹아들며 다섯 가지 작업 모드가 나타난다는 관점을 소개한다. 다섯 가지는 Prototyper, Builder, Sweeper, Grower, Maintainer다. 직함이 아니라 제품 생애주기에서 맡는 일의 방식이다.

8.1. 이미 채운 세 칸

1. Builder — 제품을 실제로 만들고 출하하는 사람

   1. 어닝콜 이벤트 스트리밍 아키텍처를 설계한 일은 Builder에 해당한다.
   2. DLQ와 폴백 모델로 실패를 복구해 제품의 신뢰성을 확보한 일도 Builder의 업무다.

2. Sweeper — 시스템을 정리하고 효율화하는 사람

   1. 긴 문단을 더 잘게 쪼개 추론 레이턴시를 줄인 일이 해당한다.
   2. 그래프 데이터를 사전 생성하고 압축해 CPU·캐시·전송 효율을 높인 일도 Sweeper에 해당한다.

3. Maintainer — 운영 중인 시스템을 건강하게 유지하는 사람

   1. 추론 성공률·SSE 연결·인프라 상태·오류를 보는 모니터링 대시보드를 만든 일이 해당한다.
   2. 동적 설정으로 운영 조건을 재배포 없이 조정할 수 있게 한 일도 Maintainer의 업무다.

8.2. 아직 채워야 하는 두 칸

1. Prototyper — 새로운 아이디어를 빠르게 실험하는 사람

   1. 서버 엔지니어가 제품의 요구사항을 전달받은 뒤 이미 정해진 구조의 레이턴시만 줄이는 방식에 머무르면 설계 선택지가 좁아진다.
   2. 프로토타이핑 단계부터 참여하면, 예컨대 문단 분할 같은 문제를 제품 구조를 굳히기 전에 해결할 수 있다.

2. Grower — 제품을 반복 개선해 시장 적합성을 높이는 사람

   1. 실제 사용자 반응을 보고 AI 워크플로우를 반복 개선하는 역할이다.
   2. 토스증권 서버 엔지니어가 이 두 모드를 충분히 수행하고 있다고 말하기는 아직 어렵고, 두 칸을 채우는 일이 현재의 조직 과제다.

9. 토스증권 서버 엔지니어가 바꾸고 있는 세 가지 일하는 방식

9.1. ML 의존도가 낮은 애플리케이션·워크플로우를 직접 만들기

1. 서버 엔지니어가 LLM 애플리케이션과 워크플로우 컴포넌트를 최대한 직접 개발하려 한다.
2. 이것은 모든 일을 서버 엔지니어가 맡겠다는 뜻이 아니다. 모델 성능 자체를 끌어올리는 일은 여전히 ML 엔지니어의 영역이다.
3. 서버 엔지니어가 맡으려는 영역은 프롬프트 조합, 도구 연결, 판단 흐름과 같은 애플리케이션 레이어다.
4. AI 생태계가 풍부한 Python 기반 스택을 배우고 있으며, LangChain·LangGraph 같은 프레임워크를 학습·적용하고 있다.
5. 더 어려운 문제는 프레임워크 사용법 자체가 아니라 기존 배포 파이프라인·모니터링·사내 인증 체계에 새 스택을 녹이는 것이다.
6. 그래서 공통 라이브러리와 모니터링 도구를 함께 준비하고 있으며, 이는 앞서 설명한 운영 사례와 연결된다.

9.2. 프로토타이핑 단계부터 서버 엔지니어가 참여하기

1. 기존에는 워크플로우가 어느 정도 정리된 뒤 요구사항을 넘겨받았다.
2. 그러면 이미 결정된 구조에서 레이턴시를 줄이는 일만 남아 설계 선택지가 매우 좁아진다.
3. 어닝콜의 문단 분할 컴포넌트도 더 이른 단계에 개입했다면 처음부터 다른 구조로 설계했을 가능성이 있다.
4. 제품 프로토타이핑부터 참여하는 것이 직군 경계의 병목을 줄이는 실제 지점이다.

9.3. 시스템 지표에서 생성 데이터 품질까지 관측하기

1. AI 특성 다섯 가지 중 가장 어려운 것은 정답이 없는 출력 품질 문제다.
2. 현재는 추론이 성공했는지 여부를 볼 수 있지만, 그 결과가 좋은지는 시스템이 아직 답하지 못한다.
3. 팀은 Langfuse로 추론 과정을 추적하고 품질 지표를 정의해 개선 프로세스에 연결하는 작업을 준비 중이다.
4. 이 부분은 발표 시점에도 진행 중이며, 발표자는 아직 완성된 답을 가져오지는 못했다고 분명히 말한다.

주요 발언 모음

“AI를 활용한 서비스 컴포넌트는 저희가 만들던 전통적인 컴포넌트와 성질이 달랐습니다.”

“타임아웃 설계가 곧 UX 설계가 됩니다.”

“응답은 200인데 내용이 틀린 실패가 존재합니다.”

“결국 어려워 보이던 문제도 나누어 보면 방향은 있었습니다.”

“파이프라인 안에서 AI 모델을 외부 노드처럼 바라보는 순간 이렇게 적용됩니다.”

“좋은 결과가 나왔다는 뜻은 아닙니다.”

“프레임워크를 익히는 것보다 어려운 게 따로 있었습니다. 이미 갖고 있는 배포 파이프라인, 모니터링, 사내 인증 체계에 이 스택을 어떻게 녹여 놓을 것인가?”

“제품 프로토타이핑 단계부터 서버 엔지니어가 참여하려고 합니다.”

핵심 데이터 & 수치

• 2025년 상반기: 토스증권 팀이 생성형 AI 제품 개발을 본격화한 시기다.
• 약 3.5~5개월: 어닝콜 서비스 출시 기간으로 자막에서 인식되는 범위다. 발표자는 짧은 기간의 빠른 출시 경험으로 소개한다.
• 다섯 가지 AI 특성: 비결정성, 초 단위 P99 레이턴시, 부분 실패, 사용량에 비례한 비용, 정답이 없는 SLO다.
• 최대 2,000개: AI 시그널 메인 화면에서 랭킹 대상이 되는 리즈닝 목록의 규모다.
• 최대 2,000 TPS: 해당 화면에 발생할 수 있는 트래픽 규모다.
• 2KB 초과: 그래프 데이터와 LLM 생성 텍스트를 합친 응답이 커질 수 있는 기준이다.
• 네 가지 운영 관측 영역: 추론 성공률, 시스템 응답 상태, 인프라 상태, 오류 유형이며 SSE 커넥션 수도 함께 봐야 한다.
• 여섯 가지 사례: 이벤트 스트리밍, 문단 분할, 캐시·압축, DLQ·폴백, 진단 대시보드, 동적 설정이다.
• 다섯 가지 작업 모드: Prototyper, Builder, Sweeper, Grower, Maintainer다.
• 세 가지 변화: ML 의존도가 낮은 컴포넌트 직접 개발, 프로토타이핑 조기 참여, 생성 데이터 품질 관측이다.

결론 및 시사점

1. 생성형 AI를 백엔드 파이프라인에 넣는다고 해서 이벤트 스트리밍, 캐시, 압축, DLQ, 모니터링, 동적 설정 같은 기존 기술의 가치가 사라지지 않는다.
2. 모델을 파이프라인의 외부 노드로 추상화하면 재시도·폴백·격리·관측 같은 전통적인 시스템 설계 원칙을 적용할 수 있다.
3. AI 서비스에서는 HTTP 성공과 사용자 가치가 다르므로, 응답 상태와 생성 결과 품질을 별도 지표로 관리해야 한다.
4. 실시간 제품에서 타임아웃은 인프라 값이 아니라 사용자가 기다릴 수 있는 경험의 상한을 결정하는 UX 정책이다.
5. 공유 결과를 사용자마다 다시 추론하지 않고 이벤트 스트림 하나를 여러 사용자에게 전달하면 비용과 지연을 동시에 줄일 수 있다.
6. 문단·배치 단위로 들어오는 입력을 더 작은 의미 단위로 쪼개는 것만으로도 모델 추론 시간과 체감 UX를 개선할 수 있다.
7. AI가 생성한 데이터도 생성 시점에 DB와 캐시에 함께 적재하고, 요청 경로에서는 캐시를 우선하는 구조가 유효하다.
8. 장중 배포가 어려운 증권 도메인에서는 제품 품질에 영향을 주는 키워드와 임계값을 dynamic config로 분리해야 한다.
9. 대시보드에서 결과를 보고 조건값을 바꾸고 다시 결과를 확인하는 피드백 루프가 AI 제품 운영의 핵심 자산이 된다.
10. 서버 엔지니어의 역할은 안정화된 워크플로를 구현하는 데서 끝나지 않고 Prototyper와 Grower의 역할까지 확장되어야 한다.
11. 제품·디자인·ML·백엔드의 경계가 낮아질수록 직군 사이의 병목을 줄이도록 프로토타이핑 단계부터 함께 일해야 한다.
12. LangChain·LangGraph 같은 프레임워크 자체보다 중요한 것은 배포, 인증, 모니터링 등 조직의 기존 운영 체계에 안전하게 통합하는 일이다.
13. 마지막 남은 품질 과제는 “추론이 성공했는가”가 아니라 “생성 결과가 좋은가”를 지속적으로 측정하는 것이다.
14. Langfuse 같은 추적 도구와 품질 지표를 개선 프로세스에 연결해야 AI 제품의 품질을 운영할 수 있다.

핵심 요약 (20줄)

1. 토스증권은 2025년 상반기 LLM 성능 향상을 계기로 해외 기업 어닝콜 실시간 번역 서비스를 빠르게 출시했다.
2. 운영 과정에서 AI 컴포넌트가 전통적인 백엔드 컴포넌트와 다섯 가지 면에서 다르다는 사실을 확인했다.
3. 같은 입력에도 결과가 달라지는 비결정성은 테스트와 품질 보증 방식을 바꾼다.
4. P99 레이턴시가 초 단위로 늘어나므로 타임아웃 설계가 곧 UX 설계가 된다.
5. HTTP 200이어도 번역과 요약 내용이 틀릴 수 있어 상태 코드만으로 품질을 판단할 수 없다.
6. 사용량에 비례하는 비용과 정답이 없는 출력 품질도 AI 서비스의 핵심 운영 문제다.
7. 팀은 이 문제들을 신뢰성·효율성·유지보수성이라는 기존 소프트웨어 품질 특성으로 다시 분류했다.
8. 어닝콜은 폴링 서버, Kafka, 모델 처리, SSE 브로드캐스트로 이어지는 이벤트 스트리밍 구조로 설계했다.
9. 한 어닝콜의 추론을 한 번만 실행하고 여러 사용자에게 공유해 비용과 지연을 줄였다.
10. 문단 단위 스크립트를 더 짧게 나누고 순서를 보장해 추론 레이턴시를 낮췄다.
11. AI 시그널은 생성 시점에 DB와 캐시에 함께 저장하고 요청 때는 캐시를 우선 사용했다.
12. 그래프 데이터를 사전 생성하고 Gzip으로 압축해 CPU 사용량과 응답 크기를 관리했다.
13. 동시 어닝콜로 모델 추론이 실패하자 DLQ 재시도와 품질을 유지하는 폴백 모델을 적용했다.
14. 대시보드에서 추론 성공률·응답 상태·인프라·오류와 SSE 연결 수를 관측한다.
15. 키워드와 이상 임계값은 dynamic config로 분리해 장중에도 재배포 없이 조정한다.
16. AI가 직무 경계를 낮추면서 디자이너·엔지니어·ML 엔지니어가 더 일찍 함께 일해야 한다.
17. Claude Code 팀의 다섯 작업 모드는 Prototyper, Builder, Sweeper, Grower, Maintainer다.
18. 토스증권 팀은 Builder·Sweeper·Maintainer 역할은 수행했지만 Prototyper·Grower는 더 강화해야 한다.
19. 서버 엔지니어는 ML 모델 자체보다 LLM 애플리케이션·도구 연결·운영 통합을 직접 맡으려 한다.
20. 다음 과제는 추론 성공 여부를 넘어 생성 데이터의 실제 품질을 Langfuse와 품질 지표로 측정하는 일이다.