토스증권 AI 백엔드 사례로 배우는 생성형 AI 서비스 설계
핵심: 모델이 응답을 생성하는 기능을 만든 뒤에도, 입력 수집부터 사용자 전달까지의 지연·비용·복구·내용 품질을 각각 설계하고 측정해야 한다.
이 문서는 토스증권 발표 영상 「토스증권 AI 서비스를 지탱하는 백엔드 엔지니어링」을 사례 연구로 정리하고, 공식 기술 문서에서 확인한 다른 해결 방법을 비교한다. 영상 속 실제 적용 사례와 외부 자료를 바탕으로 한 적용 제안을 구분했다. 영상은 자체 기반 모델의 사전학습이나 파인튜닝 경험이 아니라, 기존 생성형 모델을 제품과 API에 연결해 운영한 경험을 다룬다. 숫자와 고유명사는 자동 자막의 인식 오류 가능성을 고려해 확인 가능한 범위에서만 사용했다.
1. 먼저 잡아야 할 관점
발표자가 구분한 AI 구성 요소의 성질은 다섯 가지다. 같은 입력에도 다른 답이 나오는 비결정성, 긴 꼬리를 갖는 응답 시간, HTTP 요청이 성공해도 내용이 틀릴 수 있는 부분 실패, 호출량에 따른 비용 증가, 좋은 답의 기준을 직접 정의해야 하는 품질 목표의 어려움이다. 발표는 이 문제를 신뢰성·효율성·유지보수성으로 나누어 풀었다. 이는 소프트웨어 품질을 체계적으로 다루는 ISO/IEC 25010 제품 품질 모델의 취지와도 맞닿는다. 영상 01:00–02:56
ISO/IEC 25010이란? ISO와 IEC가 만든 소프트웨어·정보통신 제품의 품질을 살펴보는 분류 틀이다. 2023년 판은 품질을 아홉 가지 특성으로 나누고, 요구사항을 정하거나 테스트·평가 기준을 만들 때 참고하도록 한다. 예를 들어 “서비스가 좋다”는 막연한 말 대신 빠른가, 장애 뒤 복구되는가, 바꾸기 쉬운가, 원래 해야 할 일을 제대로 하는가를 따로 묻는 식이다. 표준의 이름을 붙였다고 제품 품질이 자동으로 보증되거나 점수가 나오는 것은 아니다. 우리 서비스에 맞는 측정값과 합격 기준은 팀이 정해야 한다. ISO/IEC 25010:2023 소개
| 이 글에서 참고할 품질 관점 | 쉬운 뜻 | 영상 사례에 대입하면 |
|---|---|---|
| 성능 효율성 | 기다리는 시간과 사용하는 자원이 적절한가? | 긴 문단 분할 뒤 첫 번역까지의 시간, 캐시 적용 뒤 DB·CPU 부담 |
| 신뢰성 | 실패하더라도 필요한 서비스를 이어가거나 복구할 수 있는가? | 추론 타임아웃 뒤 재시도·대체 모델과 최종 결과 누락 |
| 유지보수성 | 문제를 파악하고 요구가 바뀌었을 때 안전하게 고칠 수 있는가? | 대시보드로 원인을 찾고 뉴스 선별 조건을 변경·복원 |
| 기능 적합성 | 사용자에게 필요한 일을 실제로 해내는가? | 응답이 도착해도 숫자가 틀린 번역·요약이라면 목적을 못 이룸 |
이 표는 아홉 가지 전체를 설명하는 목록이 아니라 이 발표를 이해할 때 도움이 되는 네 관점만 골라 연결한 예시다. 특히 AI 결과의 정확성은 “API가 200을 반환했다”와 별도로, 어닝콜의 숫자·화자·누락 같은 업무별 기준으로 평가해야 한다.
생성형 AI 서비스의 성공은 한 숫자로 표현하기 어렵다. 아래 네 층을 따로 보아야 한다.
| 층 | 답해야 할 질문 | 예시 지표 |
|---|---|---|
| 전달 | 결과가 실제 사용자에게 도착했는가? | 연결 상태, 누락 구간 |
| 운영 | 작업이 끝나고 장애를 복구했는가? | 성공률, 재시도율, 복구 시간 |
| 경험 | 기다림과 사용 비용이 적절한가? | 종단간 지연, p95/p99, 작업당 비용 |
| 내용 | 결과가 정확하고 유용한가? | 숫자 보존, 누락, 근거 없는 주장 |
마지막 내용 품질의 자동 관측은 발표 당시 아직 진행 중인 과제였다. 아래의 평가 방법은 토스증권에서 이미 구현했다고 주장하는 내용이 아니다. 영상 08:17–08:24, 14:11–14:43
2. 영상의 여섯 문제와 실제 대응
사례 1 — 실시간 데이터 수집과 다수 사용자에게 결과 전달
문제. 해외 어닝콜의 오디오와 영어 스크립트를 외부 업체에서 받았다. 스크립트는 S3의 JSONL 파일이 갱신되는 형태였다. 이를 수집해 번역·요약하고, 같은 어닝콜을 보는 여러 사용자에게 빠르게 전달해야 했다.
영상 속 대응. 서버가 스크립트를 주기적으로 확인해 수집하고, Kafka를 이용한 처리 흐름에서 번역·요약을 수행한 뒤 SSE로 결과를 사용자에게 보냈다. 어닝콜 하나의 동일한 내용은 추론을 한 번 수행해 공유했다. 이는 시청자 수에 비례해 동일한 AI 호출을 반복하는 비용을 줄인다. Kafka 자체가 번역하는 것은 아니며, SSE는 서버에서 브라우저로 이벤트를 보내는 단방향 연결이다. 영상 03:04–04:13, MDN의 SSE 설명
대안과 선택 기준. 파일 제공자가 이벤트 통지를 지원한다면 S3 이벤트 통지와 큐를 써서 갱신을 감지하는 방법도 있다. 다만 S3 통지는 중복 또는 순서 변경 가능성이 있으므로 객체 버전·구간 ID를 기준으로 중복 제거와 순서 복원이 필요하다. 제공 방식이 단순 파일 갱신이라면 폴링이 이해·운영하기 쉬울 수 있다. 사용자가 결과를 즉시 받아야 할 때 SSE가 맞고, 나중에 완성본만 조회해도 된다면 비동기 작업과 일반 조회 API가 더 단순할 수 있다. S3 이벤트 통지 문서
확인할 지표. 원문 갱신부터 화면 표시까지의 시간, 구간 누락·중복, 어닝콜당 모델 호출 횟수, SSE 연결 실패율.
사례 2 — 긴 문단 때문에 번역·요약이 늦게 도착
문제. 외부 스크립트가 문장이 아니라 긴 문단 단위로 들어왔다. 문단 전체를 한 번에 추론하면 입력량이 커지고 결과를 보여줄 때까지 기다림이 길어졌다.
영상 속 대응. 수집 서버에 문단 분할 컴포넌트를 넣어 텍스트를 더 짧게 나누고 순서를 보장해 모델에 전달했다. 발표자는 추론 시간이 줄고 사용자 경험이 나아졌다고 설명하지만, 개선 폭의 수치는 제시하지 않는다. 영상 04:19–04:50
대안과 선택 기준. 입력 단위를 줄이는 것 외에 모델 응답을 스트리밍으로 보여주거나, 작업 성격에 맞는 더 빠른 모델을 비교할 수 있다. 스트리밍은 체감 대기 시간을 줄일 수 있지만 모델의 최종 완료 시간과 품질이 저절로 개선되지는 않는다. 분할은 문맥이 끊겨 숫자·화자·지시어가 왜곡될 수 있으므로, 원문 구간 ID와 주변 문맥을 보존한 평가가 필요하다. AWS의 추론 성능과 스트리밍 가이드
확인할 지표. 첫 결과까지의 시간, 전체 완료 시간, 입력 길이별 지연 분포, 분할 전후 번역 오류율.
사례 3 — 높은 조회량에서 DB와 그래프 생성이 부담
문제. AI 시그널 화면은 후보 데이터의 순위와 연관 종목 그래프를 보여준다. 발표에서는 랭킹 후보 최대 약 2,000개와 지면 최대 약 2,000 TPS를 언급한다. 매 요청마다 후보를 DB에서 읽고 그래프를 다시 생성하면 DB와 CPU에 부담이 생긴다.
영상 속 대응. AI 워크플로우가 결과를 만들 때 DB와 캐시에 함께 적재했고, 조회에는 캐시를 우선 사용하고 DB를 대체 경로로 두었다. 순위가 반영된 그래프 결과도 캐시하고 압축했다. 영상 04:51–05:56
대안과 선택 기준. 모든 결과를 생성 시점에 캐시에 넣는 방식 외에, 처음 읽힐 때만 채우는 cache-aside가 있다. 자주 조회되는 최신 데이터에는 미리 적재하는 방식이 유리할 수 있고, 조회가 드문 결과가 많다면 cache-aside가 캐시 공간을 절약할 수 있다. 어느 방식이든 갱신 기준, 만료 시간, DB와 캐시 간 불일치를 정의해야 한다. AWS의 캐시 패턴 비교
확인할 지표. 캐시 적중률, DB 폴백 비율, 데이터 생성 CPU 시간, 응답 크기, 오래된 결과가 노출된 시간.
사례 4 — 동시 어닝콜에서 모델 추론 타임아웃
문제. 어닝콜이 동시에 여러 개 열리자 모델 추론에 부하가 몰렸고 일부 번역·요약이 타임아웃됐다. 실시간 음성과 텍스트가 맞물리므로 한 구간이 빠져도 이용 경험이 흔들린다.
영상 속 대응. 실패 작업을 DLQ에 모아 재시도했다. 그 재시도까지 실패하면 품질 수준을 고려해 준비한 대체 모델을 사용했다. 발표의 핵심 판단은 AI 모델을 파이프라인의 실패 가능한 외부 노드로 보고 기존 복구 기법을 적용한 것이다. 영상 06:00–06:59
대안과 선택 기준. 재시도는 일시적 오류에 효과적이지만 과부하가 원인일 때 즉시 반복하면 상황을 악화시킨다. 제한된 횟수와 지수 백오프·지터를 적용하고, SDK와 애플리케이션 양쪽의 중복 재시도를 피한다. 같은 구간이 두 번 처리되어도 결과가 중복 발행되지 않도록 작업 ID로 멱등성을 보장한다. 실시간 가치가 사라진 작업은 무조건 재시도하기보다 중단·사후 처리 여부를 정해야 한다. AWS의 재시도 제한 지침, 멱등 API 설계
확인할 지표. 최초 실패율, 재시도 후 회복률, 대체 모델 사용률, 최종 누락률, 복구된 결과의 지연.
사례 5 — HTTP 성공만으로 실제 서비스 상태를 알 수 없음
문제. 서버가 살아 있고 요청에 성공 응답을 보내더라도 번역·요약이 몇 퍼센트 누락됐는지, 사용자가 결과를 받았는지 알기 어려웠다. 실시간 서비스는 다음 날 고객 문의로 알아차리면 늦다.
영상 속 대응. 추론 성공률, 시스템 응답, 인프라 상태, 오류 내용을 대시보드와 알림으로 관측했다. 실제 전달 여부를 이해하기 위해 SSE 연결 수도 보았다. 단, 발표자가 직접 강조했듯 추론 성공률은 결과가 좋다는 뜻이 아니다. 영상 07:01–08:24
대안과 선택 기준. 메트릭과 로그만으로 단계 간 원인을 연결하기 어렵다면 요청·작업·모델 호출에 공통 ID를 부여한 추적을 추가한다. 사용자 경험 관점에서 종단간 지연과 p95/p99를 함께 보고, 내용 품질은 별도 평가 세트와 운영 중 표본 검토로 확인한다. 모니터링 도구를 먼저 고르기보다 답하려는 질문을 먼저 정의한다. AWS의 생성형 AI 성능 기준, OpenTelemetry의 생성형 AI 관측 표준
확인할 지표. 수집·추론·전달 단계별 성공률, 사용자 기준 누락률, p95/p99 지연, 작업당 토큰과 비용, 품질 평가 점수.
사례 6 — 뉴스 선별 조건을 바꾸려면 코드 배포가 필요
문제. 어떤 뉴스를 AI 시그널 후보로 볼지 정하는 키워드와 임계값은 운영하면서 조정해야 했다. 이를 코드 상수로 두면 값 하나를 바꿀 때도 배포가 필요했고, 증권 서비스에서는 장중 배포가 쉽지 않았다.
영상 속 대응. 조건값을 동적 설정으로 분리했다. 관리 화면에서 바꾸면 재배포 없이 반영되므로, 대시보드에서 상태 확인 → 설정 조정 → 결과 확인의 순환이 가능해졌다. 영상 08:25–09:30
대안과 선택 기준. 단순 설정 파일·DB 테이블로 시작할 수 있다. 운영 영향이 큰 설정은 버전, 허용 범위 검사, 점진 적용, 이전 값 복원을 더해야 한다. 동적 변경은 빠른 만큼 잘못된 값도 빠르게 퍼지므로 변경 전후의 효과를 관측할 수 있어야 한다. AWS AppConfig의 검증·점진 배포·자동 복원
확인할 지표. 설정 변경 후 후보 건수와 품질 변화, 오류 급증 여부, 이전 설정으로 되돌리는 데 걸린 시간.
여섯 사례에서 개발자가 가져갈 원칙
| 영상 사례 | 개발자가 배울 점 | 내 API에서 확인할 순간 |
|---|---|---|
| 어닝콜 공동 추론·전달 | 같은 입력에서 생기는 공통 결과는 한 번 만들고 재사용한다. | 사용자가 늘 때 모델 호출도 같은 비율로 늘어나는가? |
| 긴 문단 분할 | 모델을 바꾸기 전에 입력 단위와 처리 순서를 측정한다. | 긴 입력에서 지연과 정확도가 함께 어떻게 변하는가? |
| AI 시그널 캐시·압축 | 계산과 조회가 반복되는 위치를 찾아 결과를 재사용한다. | DB 조회·CPU·응답 크기 중 실제 병목은 무엇인가? |
| DLQ·대체 모델 | 모델 호출을 실패 가능한 외부 의존성으로 다룬다. | 실패 뒤 재시도해도 중복 없이 제시간에 전달되는가? |
| 추론·연결 대시보드 | 서버 상태와 사용자에게 도착한 결과를 분리해 본다. | 성공 응답인데 사용자 결과가 빠진 적은 없는가? |
| 동적 설정 | 운영하며 달라지는 기준을 측정·조정·복원 가능하게 한다. | 조건을 바꿨을 때 좋아진 근거를 남길 수 있는가? |
3. 여섯 문제를 다른 업무에도 적용해 보기
영상의 구현을 그대로 복사하기보다 입력의 도착 방식, 동일 결과를 쓰는 사람 수, 결과의 유효 시간, 실패의 피해를 비교해야 한다. 아래의 오른쪽 사례는 다른 회사에서 실제로 했다는 주장이 아니라, 같은 문제가 나타날 수 있는 가상 적용 예시다.
| 영상에서 드러난 문제 | 비슷한 상황의 예시 | 공통 문제 정의와 먼저 확인할 것 |
|---|---|---|
| 어닝콜 스크립트 수집과 공동 추론 | 스포츠 경기 자막을 여러 시청자에게 번역해 전달 | 한 원본에서 나온 결과를 여러 사람이 소비한다. 원본 구간을 어떻게 식별하고, 중복 도착·역순 도착을 어떻게 다루며, 결과를 몇 번 생성해야 하는가? |
| 긴 문단으로 인한 응답 지연 | 상담 통화 녹취를 실시간 요약하거나 긴 계약서를 항목별로 검토 | 입력의 경계와 처리 단위가 사용자 대기 시간을 결정한다. 작은 단위로 자를 때 앞뒤 문맥과 숫자·화자 정보를 보존할 수 있는가? |
| 인기 화면의 DB 조회·그래프 재계산 | 같은 일일 분석 보고서를 수천 명이 여는 대시보드 | 생성 빈도보다 조회 빈도가 훨씬 높다. 언제 결과가 낡은 것으로 간주되는지 합의하고, 캐시·사전 계산의 효익을 측정해야 한다. |
| 동시 어닝콜에서 추론 타임아웃 | 월말 문서 처리나 이벤트 직후 문의 요약이 한꺼번에 몰림 | 외부 모델의 처리량은 수요 폭증을 항상 따라가지 못한다. 다시 시도할 만한 시간, 중복 처리 방지, 낮은 품질의 대체 결과 허용 여부를 정해야 한다. |
| 서버는 정상인데 결과 누락을 모름 | OCR API가 200을 반환했지만 필수 금액이 비어 있는 정산 업무 | 기술적 성공과 업무 완료가 다르다. 모델 응답, 필수 필드 검증, 사용자 전달, 최종 사용 가능성을 각각 측정해야 한다. |
| 뉴스 선별 기준을 바꾸려면 배포 필요 | 상담 자동 분류의 긴급도 기준이나 이상거래 알림 임계값 조정 | 업무 정책의 변경 속도가 코드 배포 주기보다 빠르다. 누가 바꿀 수 있고, 어떤 범위에서 시험하며, 잘못 바뀌면 어떻게 되돌릴지 정해야 한다. |
유사해 보여도 해결책은 맥락에 따라 달라진다. 예를 들어 실시간 자막은 몇 초 늦은 결과의 가치가 급격히 떨어질 수 있지만, 계약서 검토는 몇 분 더 걸리더라도 정확성과 검토 가능성이 더 중요할 수 있다. 따라서 “SSE를 쓰자”, “DLQ를 넣자”보다 먼저 사용자에게 결과가 언제까지, 어느 수준의 품질로 도착해야 하는가를 묻는다. 이 문제 정의 방식은 구현안을 먼저 제시받아도 사용자 목표와 제약으로 다시 풀어보라는 GOV.UK의 발견 단계 지침과 맞닿는다.
4. 현업과 개발자가 같은 문제를 정의하는 법
현업은 “요약을 더 빨리 보여 달라”처럼 경험을 말하고, 개발자는 “모델 지연을 줄이자”처럼 기술 원인을 먼저 떠올리기 쉽다. 둘 다 아직 가설이다. 누가 어떤 업무 중 무엇을 못 했는지를 실제 사례로 확인한 뒤, 관찰한 현상·가능한 원인·후보 해결책을 분리해야 한다. GOV.UK는 사용자 목표·제약·성공 측정을 이해한 뒤 구축 여부를 판단하도록 안내한다.
| 대화 순서 | 현업에게 묻고 함께 볼 것 | 개발자가 확인할 것 | 합의해서 남길 것 |
|---|---|---|---|
| 실제 업무 | 최근의 정상·실패·경계 사례를 각각 하나씩, 화면과 수작업까지 보여 달라 | 입력이 어디서 오고 누가 결과를 소비하는지 흐름을 그린다 | 사용자, 업무 단계, 대표 사례 3개 |
| 불편과 피해 | 어느 순간에 일을 멈췄고, 늦음·누락·오답 중 무엇이 더 치명적인가 | 해당 순간의 로그·지연·오류·품질 표본을 찾는다 | 관찰 사실과 사용자 영향, 아직 모르는 값 |
| 용어와 규칙 | “실시간”, “완료”, “중요 뉴스”, “정확한 요약”은 각각 어떤 상태인가 | 그 말을 API 상태·데이터 필드·알림 조건으로 옮길 수 있는지 확인한다 | 공통 용어, 예외, 업무 판단 책임자 |
| 목표와 제약 | 언제까지 결과가 필요하고, 틀렸을 때 누가 검토하며, 어떤 결과는 내보내면 안 되는가 | 목표를 지연·누락·품질·비용 지표와 수용 기준으로 바꾼다 | 목표, 비목표, 허용 범위, 검수 방법 |
| 작은 검증 | 어떤 사례를 먼저 해결하면 도움이 되는지 우선순위를 정한다 | 작은 시제품이나 과거 데이터 재생으로 가설을 확인한다 | 실험 범위, 성공 조건, 재논의 날짜 |
이 대화에서 현업은 업무의 의미와 실패 비용을 설명하고 결과를 검수한다. 개발자는 애매한 표현을 드러내고 현재 흐름을 측정해 구현 가능성과 부작용을 설명한다. PM/PO는 우선순위와 결정자를 분명히 하고, QA는 정상·경계·실패 사례를 검증 조건으로 고정한다. 용어는 한 번 정해 끝나는 사전이 아니라, 실제 사례가 나오면 수정하는 공동 언어다. Martin Fowler의 유비쿼터스 언어 설명, 작업공간의 DDD 입문 문서
요청을 문제 정의로 바꾸는 대화 예시
아래 문장은 영상 속 실제 회의 기록이 아닌 이 사례에 적용해 보는 대화 예시다.
현업: “어닝콜 번역을 더 실시간으로 보여 주세요.” 개발자: “늦었다고 느낀 실제 구간을 같이 볼까요? 원문이 도착한 시각, 화면에 뜬 시각, 그 사이에 놓친 발언을 확인하고 싶습니다.” 현업: “중요한 수치가 발표된 뒤 다음 주제로 넘어갈 때까지 번역이 없으면 이해하기 어렵습니다.” 개발자: “그렇다면 ‘모델이 빨리 응답한다’보다 ‘중요 구간의 번역이 사용 가능한 시간 안에 화면에 도착한다’가 목표겠네요. 숫자 오류와 지연 중 어느 쪽을 더 엄격히 제한할지도 예시로 정해 보겠습니다.”
같은 방식으로 “뉴스 알림이 너무 많다”는 요청에는 원치 않았던 알림 10건과 놓치면 안 됐던 뉴스 10건을 함께 본다. 후보 건수만 줄이면 중요한 뉴스까지 빠질 수 있기 때문이다. 현업과 중요, 오탐, 미탐의 의미를 합의하고, 개발자는 키워드·임계값 변경 전후에 두 오류가 어떻게 움직이는지 보여준다. 10건은 실습을 시작하기 위한 예시 수량이지 영상에서 제시한 기준이 아니다.
개발자가 남길 한 장짜리 문제 정의
사용자와 상황: 누가, 언제, 어떤 일을 끝내려 하는가?
관찰한 사실: 실제 실패 사례, 현재 흐름, 기준 수치는 무엇인가?
사용자 영향: 늦음·누락·오답이 어떤 결정이나 업무를 막는가?
원인 가설: 어떤 단계가 원인으로 의심되며 무엇을 아직 모르는가?
목표와 비목표: 이번에 개선할 것과 다루지 않을 것은 무엇인가?
성공 기준: 지연·누락·내용 품질·비용의 합의한 목표와 측정법은?
예외와 책임: 실패·재시도·사람 검토·정책 변경은 누가 결정하는가?
첫 실험: 어떤 사례로 언제까지 가설을 검증하고 다시 논의할 것인가?개발자는 관찰 → 영향 → 목표를 먼저 쓰고, “Kafka 도입”, “모델 교체” 같은 구현은 가설과 실험 후보에 둔다. 수치가 없으면 임의로 채우지 말고 기준선 미측정이라고 적어 측정 계획을 만든다. 수용 기준은 “주어진 어닝콜 구간에 숫자와 화자가 포함되고(조건), 번역 결과가 전달되면(행동), 화면에서 원문 구간과 대응하며 필수 숫자가 보존된다(결과)”처럼 사례로 검토한다. 이후의 지연 목표와 허용 오류는 현업과 실제 표본을 보고 결정한다. GOV.UK의 사용자 요구 정의
5. 발표 이후에도 남은 두 과제
생성 결과의 품질
발표 시점에는 요청 성공·실패와 시스템 상태를 볼 수 있었지만, 생성 결과가 정확하고 유용한지에 대한 시스템적 답은 없었다. 발표자는 추론 과정을 추적하고 품질 지표를 정의해 개선으로 연결하는 작업을 준비 중이라고 말했다. 이것을 이미 해결된 성과로 읽어서는 안 된다. 영상 14:11–14:43
외부 자료가 제안하는 출발점은 사용 사례에 맞는 평가 기준과 대표 입력을 먼저 만드는 것이다. 예를 들어 어닝콜 번역·요약에는 회사명·숫자·단위 보존, 중요한 조건 누락, 원문에 없는 주장, 화자·시간 구간 매칭을 검사할 수 있다. 코드로 확인 가능한 항목, 사람의 검토가 필요한 항목, 모델 평가기를 쓸 수 있는 항목을 구분한다. 평가용 모델도 오판할 수 있으므로 중요한 사례는 사람이 다시 확인한다. Anthropic의 평가 설계 가이드
직군 사이의 인수인계가 만드는 개발 병목
발표자는 기능 하나를 안정화하는 기술 외에 제품을 만들어내는 속도가 새 병목이 됐다고 설명한다. 워크플로우가 거의 정해진 뒤에 서버 엔지니어가 서빙을 맡으면 입력 단위나 지연 구조를 초기에 바꿀 기회가 줄어든다. 그래서 서버 엔지니어가 시제품 단계부터 참여하고, 프롬프트 조합·도구 연결·흐름 제어 수준의 워크플로우는 직접 개발하려 한다. 영상 10:00–14:10
발표가 인용한 Claude Code 팀의 다섯 역할로 보면, 영상에서 이미 보여준 것은 Builder(작동하는 구조와 복구 경로 구현), Sweeper(지연·자원 최적화), Maintainer(관측·운영 설정)다. 발표자가 더 채우려는 것은 Prototyper(초기 아이디어 실험)와 Grower(실제 반응에 맞춘 반복 개선)다. 이는 고정된 직책보다 현재 해결해야 하는 일의 성격을 가리킨다. 영상 11:36–12:43
6. 내 생성형 AI API에 적용할 설계 메모
아래는 영상의 복제가 아니라, 위 사례와 외부 지침에서 도출한 개인 프로젝트용 시작 설계다. 예시는 자료를 입력받아 요약을 생성하는 API를 가정한다.
| 결정할 것 | 첫 버전의 질문 | 나중에 확인할 근거 |
|---|---|---|
| 입력 계약 | 허용 길이·형식·언어는? | 잘못된 입력의 비율과 오류 유형 |
| 생성 결과 | 필수 필드와 출처는? | 형식 오류·숫자 오류·누락 사례 |
| 작업 상태 | 즉시 완료, 스트리밍, 비동기 중 무엇이 맞나? | 실제 처리 시간과 사용자의 대기 허용치 |
| 중복 방지 | 동일 원문과 설정을 어떻게 식별하나? | 같은 작업의 중복 모델 호출 횟수 |
| 실패 복구 | 언제 재시도하고 언제 중단하나? | 최초 실패와 최종 실패의 차이 |
| 비용 | 요청·성공 작업당 비용을 측정하는가? | 토큰, 캐시 적중률, 품질 변화 |
| 관측 | 단계별 작업 ID와 로그가 연결되는가? | 장애를 재현·설명하는 데 걸린 시간 |
| 품질 | 어떤 결과를 사람이 틀렸다고 판단하나? | 대표 평가 세트의 오류 유형 |
초기 구현은 입력 검증 → 작업 ID 생성 → 모델 호출 → 출력 형식 검증 → 결과 저장 → 응답으로 시작해도 된다. 실패가 실제로 나타나면 정확한 단계의 지표를 보고 재시도·큐·캐시·스트리밍을 추가한다. Kafka나 다수 모델 폴백은 모든 프로젝트의 기본값이 아니다. 모델·프롬프트·설정 버전과 작업 ID를 함께 기록하면 변경 전후 품질을 비교하기 쉬워진다. AWS의 생성형 AI 수명주기 가이드, Anthropic의 평가 설계 가이드
작은 실습 네 가지
- 중복 비용 실험: 동일 자료를 여러 번 요청해 모델 호출 횟수를 기록한다. 결과 재사용을 적용한 뒤 호출 횟수·지연·오래된 결과 여부를 비교한다.
- 긴 입력 실험: 짧은 자료와 긴 자료의 첫 응답·전체 완료 시간을 측정한다. 문단 분할을 적용하고 원문 숫자와 맥락이 유지되는지 확인한다.
- 실패 복구 실험: 모델 호출을 인위적으로 지연·실패시켜 재시도 한도, 중복 발행, 최종 실패 상태를 확인한다.
- 품질 실험: 숫자·날짜·조건문이 들어 있는 대표 입력을 모아 요약 결과를 평가한다. 프롬프트 변경 전후 같은 세트로 비교한다.
매 실험은 문제 → 예상 원인 → 측정값 → 변경 → 전후 비교 → 남은 한계의 여섯 줄로 기록한다. 이 기록이 기술 이름보다 오래 남는 학습 결과다.
한 단계 더 배울 운영 질문 일곱 가지
앞의 사례를 다시 살펴보면 기술을 하나 더 붙이는 것보다 언제 일을 그만둘지, 무엇을 좋은 결과로 판정할지, 어떤 입력에서 결과가 나왔는지, 변경의 영향을 어떻게 통제할지를 결정하는 일이 남는다. 아래는 발표에서 구현했다고 확인된 사항이 아니라, 해당 사례를 내 API에 적용할 때 추가로 검토할 질문이다.
| 더 배울 문제 | 영상과 연결되는 지점 | 내 API에서 정할 규칙과 작은 검증 |
|---|---|---|
| 늦은 성공은 성공인가? | 동시 어닝콜 타임아웃 뒤 DLQ 재시도 | 요청·작업마다 결과의 유효 기한을 정한다. 큐 대기 시간과 가장 오래된 작업의 나이를 측정하고, 기한이 지난 작업은 사용자에게 만료로 알릴지 사후 기록만 할지 정한다. 모의 모델을 느리게 만든 뒤 재시도 성공률과 기한 내 전달률을 따로 비교한다. |
| 평가 세트가 실제 실패를 대표하나? | 추론 성공률은 보지만 내용 품질 관측은 미완료 | 숫자·단위·화자·긴 문맥·중복·지연 구간처럼 실패 유형을 나눠 예시를 모은다. 현업이 오류의 심각도를 매기고, 고정 회귀 세트와 새 운영 표본을 분리한다. 모델·프롬프트 변경 때는 품질 기준과 지연·비용을 함께 비교하고, 새 실패가 나오면 평가 세트에 반영한다. |
| 어느 원문에서 이 결과가 나왔나? | JSONL 수집 → 문단 분할 → 모델 호출 → SSE 전달 | 원본 ID·버전, 구간 ID·순서, 작업 ID, 모델·프롬프트 버전, 결과 상태를 연결한다. 중복·역순·누락 입력을 만들어도 결과가 원문 구간에 한 번만 매핑되는지, 장애 후 특정 구간을 재처리할 수 있는지 확인한다. |
| 대체 모델의 답을 그대로 내보내도 되나? | 타임아웃 뒤 다른 모델로 복구 | 빠른 모델이 놓치는 숫자·조건·문맥을 같은 평가 세트로 비교한다. 업무에 필요한 최소 품질 기준을 못 넘으면 검토 필요나 생성 실패로 표시하고, 대체 모델 사용률과 오류율을 별도로 본다. |
| 입력 자료와 추적 로그를 누가 볼 수 있나? | 외부 스크립트 수집과 요청·추론 과정 기록 | 공개 자료와 내부 문서의 경계를 구분한다. 원문·출력·로그·캐시의 접근 권한과 보존 기간을 정한다. 외부 문서 안의 “이전 지시를 무시하라”는 문구를 명령이 아닌 데이터로 다루고, 모델이 도구를 쓰더라도 권한 검사는 애플리케이션에서 강제한다. |
| 설정과 프롬프트 변경을 어떻게 안전하게 퍼뜨리나? | 뉴스 키워드·임계값을 동적으로 변경 | 설정 버전과 변경자를 남기고, 유효 범위를 검사한 뒤 일부 대상에 먼저 적용한다. 후보 건수·오탐·미탐·지연을 확인해 확대하거나 이전 버전으로 되돌린다. 값이 바뀐 시각과 결과 변화를 함께 기록한다. |
| 싼 호출이 정말 싼 서비스인가? | 공동 추론·캐시·압축으로 비용을 줄임 | 토큰 단가만 보지 않고 유효 기한 안에 도착해 품질 검사를 통과한 결과 1건당 비용을 비교한다. 최초 호출, 재시도, 대체 모델, 캐시·저장·전달 비용을 포함하고 비용 감소가 품질 저하를 동반하는지 확인한다. |
첫 질문에서 DLQ는 실패 작업을 조사·재처리할 경로이지, 과부하를 무한히 받아도 된다는 뜻이 아니다. 큐에 오래 머문 작업은 처리돼도 이미 쓸모가 없을 수 있어 대기 시간과 오래된 메시지를 관측해야 한다. AWS의 빠른 실패·큐 제한 지침
둘째 질문의 핵심은 평가를 프롬프트 개발의 부속 테스트가 아니라 데이터·판정 기준·배포 조건을 가진 별도 작업으로 보는 것이다. 실제 입력이 바뀌면 표본도 갱신해야 한다. 자동 점수와 현업 검토가 충돌하면 사례와 기준을 다시 확인한다. AWS의 평가 데이터 설계, 주기적 성능 평가 지침
셋째 질문은 장애 분석뿐 아니라 품질 검토에도 중요하다. 숫자가 틀렸을 때 원본이 잘못 들어왔는지, 분할 과정에서 문맥을 잃었는지, 모델이 왜곡했는지, 전달 중 구간이 빠졌는지 구별할 수 있어야 한다. 다만 원문 전체를 무기한 로그에 남기는 방식으로 해결하지 않는다. 입력의 민감도에 맞춰 저장 범위·접근 권한·보존 기간을 정하고, 필요한 ID와 버전 정보로 추적한다. S3 이벤트의 중복·순서 고려, AWS의 멱등 API 설계
나머지 네 질문은 작동하는 기능을 업무에 맞는 서비스로 만드는 경계다. 대체 모델은 장애를 줄일 수 있지만 품질이 내려갈 수 있으므로, 현업과 허용할 오류와 사용자 표시 방식을 먼저 합의한다. 외부 텍스트는 모델이 읽는 자료일 뿐 운영 명령의 권한을 갖지 않는다. 프롬프트나 설정도 코드처럼 버전·검증·점진 적용·복원이 필요하다. 비용은 단순 호출 수보다 사용 가능한 결과를 만드는 데 든 전체 비용으로 비교하는 편이 이 사례의 목표에 맞다. 마지막 비용 지표는 공식 문서의 표준 명칭이 아니라 이 글에서 제안하는 업무 단위 지표다. AWS의 모델별 폴백 판단, OWASP의 프롬프트 인젝션 설명, AWS AppConfig의 점진 적용, AWS의 생성형 AI 비용 최적화 원칙
7. 출처와 해석 범위
| 구분 | 자료 | 이 문서에서 사용한 내용 |
|---|---|---|
| 사례 원문 | 토스증권 발표 영상 | 여섯 실제 문제·대응, 미완료 품질 과제, 역할 변화 |
| 품질 모델 | ISO/IEC 25010:2023 | 소프트웨어 품질 특성의 참고 틀 |
| 이벤트 전달 | MDN SSE, AWS S3 이벤트 | 영상 구조의 의미와 수집 대안 |
| 복구 | AWS 재시도 지침, AWS 멱등성 지침 | 제한된 재시도와 중복 처리 설계 |
| 큐의 유효 기한 | AWS 빠른 실패·큐 제한 | 오래된 작업의 가치와 큐 대기 시간 판단 |
| 캐시·비용 | AWS 캐시 패턴, AWS 비용 최적화 | 캐시 대안과 비용 측정 |
| 평가·관측 | Anthropic 평가 문서, AWS 성능 기준 | 결과 품질과 지연·비용을 분리해 측정 |
| 평가 운영 | AWS 평가 데이터 설계, 주기적 평가 | 평가 세트·판정 기준·배포 조건을 별도로 관리 |
| 운영 설정 | AWS AppConfig | 동적 설정 변경의 검증·복원 대안 |
| 대체 모델과 변경 배포 | AWS 작업별 모델 선택, AWS AppConfig 점진 적용 | 폴백의 품질 차이와 설정 변경의 단계적 검증 |
| 입력 자료의 신뢰 경계 | OWASP 프롬프트 인젝션, AWS 추적 데이터 보호 | 외부 텍스트의 권한 제한과 로그 접근 관리 |
| 업무 단위 비용 | AWS 생성형 AI 비용 최적화 | 모델 단가 외에 실제 유효 결과의 비용까지 비교 |
| 문제 발견과 공동 언어 | GOV.UK 발견 단계, 사용자 요구 정의, Martin Fowler의 유비쿼터스 언어 | 구현 요청을 사용자 문제로 다시 정의하고 현업·개발자가 용어를 맞추는 방법 |
해석 경계: 외부 자료에 나온 S3 이벤트, cache-aside, 백오프·지터, 멱등성, 평가 세트, 설정 점진 적용은 이 영상에서 토스증권이 사용했다고 확인된 기술이 아니다. 실제 사례를 바탕으로 검토할 수 있는 다른 방법으로 정리했다. 공식 문서의 제품별 조건과 가격은 적용 시점에 다시 확인해야 한다.
8. 작업공간의 비슷한 자료에서 보강한 관점
2026년 10월 1일에 Markdown Source Graph MCP로 C:/app/AI_MONITORING의 문서를 검색했다. 인덱스에는 2026년 9월 30일까지의 자료가 반영되어 있었다. 아래 문서는 이 발표의 근거를 대체하지 않고, 개발자가 사례에서 무엇을 학습할지 정하는 데 보조 자료로 쓴다. 링크는 이 문서가 있는 outputs 폴더를 기준으로 한 로컬 경로다.
| 찾은 문서 | 관련성 | 이 글에 반영한 질문 |
|---|---|---|
| LLM Service Engineering | 모델 호출을 서빙·관측·신뢰성·비용까지 확장한 개념 문서 | “API가 동작한다” 다음에 무엇을 측정할까? |
| Agent Evaluation | 최종 답뿐 아니라 실행 과정, 검증기 오류와 비용을 함께 보는 문서 | 내용 품질과 작업 성공을 어떻게 분리할까? |
| 2026년 9월 AI 트렌드 월간 보완판 | 최근 자료를 평가·실행 기록·복구·권한이라는 운영 기준으로 묶은 문서 | 새 모델이나 도구를 도입할 때 어떤 증거가 필요한가? |
| Claude의 속도 개선 사례 메모 | 측정 가능한 병목을 찾아 개선했다는 공급자 사례를 정리한 문서 | “느리다”를 어떤 구간의 측정값으로 바꿀까? |
이 자료들은 문서 유형과 근거 수준이 다르다. 개념 문서와 월간 리포트는 작업공간의 해석, Claude 사례 메모는 공급자 원문을 가리키는 2차 정리다. 특정 제품의 성능·지원 범위·가격은 로컬 요약만으로 확정하지 않는다. 토스증권의 영상 사례와도 직접적인 동일 구현으로 연결하지 않는다.
9. 개발자를 위한 마지막 정리: LLM API를 만들 때 항상 묻는 질문
영상의 교훈을 한 문장으로 바꾸면 “모델 호출을 기능으로 끝내지 말고, 사용자에게 도달하는 결과의 품질과 운영 경로까지 API의 계약으로 만들자”이다. 아래 표는 새 API를 시작하거나 기존 API를 고칠 때 반복해서 쓸 점검표다.
| 질문 | 먼저 해볼 방법 | 확인할 증거 |
|---|---|---|
| 무엇을 해결하나? | 현업과 실제 업무·실패 사례를 보고 관찰·영향·목표를 합의 | 대표 입력·기대 결과·실패 예시·문제 정의 기록 |
| 같은 말을 같은 뜻으로 쓰나? | 완료, 실시간, 정확의 업무 의미와 API 상태를 맞춘다 | 공통 용어와 정상·경계·실패 사례에 대한 현업 검수 |
| 어떤 입력과 출력을 약속하나? | 입력 길이·형식·필수 필드와 출력 스키마를 정하고 검증 | 잘못된 입력 처리, 형식 검증 통과율 |
| 좋은 답과 최소 품질은 무엇인가? | 사실 오류·누락·근거 없는 내용을 평가하고 대체 모델에도 같은 기준을 적용 | 고정 평가 세트와 사람 검토 결과, 대체 모델 오류율 |
| 어떤 모델을 선택하나? | 동일한 입력으로 후보의 품질·지연·비용을 비교 | 작업당 성공률·p95 지연·비용 |
| 사용자는 얼마나 기다리나? | 즉시 응답·SSE·비동기 작업 중 사용 흐름에 맞게 선택 | 첫 결과까지와 전체 완료까지의 시간 |
| 실패 후 어떻게 복구하나? | 오류를 분류하고 타임아웃·제한된 재시도·최종 상태를 정의 | 인위적 실패 실험과 최종 누락률 |
| 복구된 결과가 아직 쓸모 있나? | 결과의 유효 기한과 큐 대기 한도를 정하고 오래된 작업의 처리를 결정 | 기한 내 전달률, 가장 오래된 작업의 나이 |
| 같은 일을 반복하지 않나? | 원문·모델·프롬프트 버전을 고려해 작업 ID와 결과 재사용 규칙을 설계 | 중복 모델 호출 수, 중복 발행 수 |
| 사용량이 늘어도 감당 가능한가? | 토큰·재시도·캐시·전달 비용과 동시 요청을 기록 | 부하 실험, 비용 상한, 유효 결과 1건당 비용 |
| 문제의 위치를 찾을 수 있나? | 요청 ID로 수집·모델 호출·검증·전달을 연결 | 단계별 지연·실패 원인·추적 기록 |
| 입력 자료와 도구를 믿어도 되나? | 출처·접근 범위·도구 권한을 구분하고 외부 텍스트를 데이터로 처리 | 출처 누락, 허용되지 않은 도구 실행·민감 정보 노출 테스트 |
| 변경 후 좋아졌나? | 모델·프롬프트·설정 버전을 남기고 일부 대상부터 적용해 전후 비교 | 품질·지연·비용의 회귀 여부와 복원 가능성 |
| 새로운 실패를 평가에 반영했나? | 운영 표본의 오류를 분류하고 현업과 심각도·배포 기준을 갱신 | 평가 세트 버전과 새 오류 유형의 재발 여부 |
혼자 만들 때의 실행 순서는 다음과 같다.
- 대표 입력과 까다로운 입력을 모아 작은 평가 세트를 만든다. 정답 문자열 하나보다 무엇이 잘못된 답인지 기록한다.
- 입력 검증 → 모델 호출 → 출력 형식 검증 → 결과 반환의 가장 작은 API를 만든다.
- 요청별 시간·토큰·비용·모델/프롬프트 버전을 기록한다. 이때부터 개선 전 기준선이 생긴다.
- 타임아웃, 잘못된 출력, 중복 요청을 일부러 발생시켜 복구 경로를 시험한다.
- 실제 병목과 실패를 본 뒤 캐시·큐·스트리밍·대체 모델 중 필요한 것을 선택한다.
- 동일한 평가 세트와 운영 지표로 변경 전후를 비교하고, 사용자에게 가치가 있는지 다시 확인한다. 평가 기준 설계, 제한된 재시도
Claude Code 팀의 다섯 역할로 내 작업 되짚기
발표가 언급한 다섯 역할은 Claude Code의 필수 기능이나 다섯 명의 고정 담당자를 뜻하지 않는다. 혼자 개발해도 그날 하는 일을 구분하는 관점으로 쓸 수 있다. 영상 11:36–12:43
| 오늘의 역할 | 내 API에서 하는 일 | 남겨야 할 결과 |
|---|---|---|
| Prototyper | 아이디어를 작은 시제품으로 확인 | 계속 만들 이유와 버릴 이유 |
| Builder | 검증한 흐름을 API 계약·저장·복구까지 구현 | 작동하는 기능과 핵심 테스트 |
| Sweeper | 측정한 병목을 줄이고 불필요한 복잡성을 제거 | 변경 전후 지연·비용·품질 비교 |
| Grower | 실제 사용 기록과 피드백으로 결과를 개선 | 개선 가설과 사용자 반응 |
| Maintainer | 장애·회귀·비용 증가를 찾아 안정적으로 운영 | 대시보드·알림·복구 절차 |
다음 프로젝트에 복사할 짧은 기록 양식
현업과 함께 본 실제 정상·실패·경계 사례:
사용자·업무 상황과 관찰한 피해:
공통 용어·업무 규칙·결정자:
이번 목표·비목표와 현업 검수 조건:
사용자가 하려는 일:
좋은 결과의 기준과 실패 예시:
입력·출력 계약:
허용할 대기 시간과 작업당 비용:
타임아웃·재시도·최종 실패 처리:
중복 요청과 결과 재사용 규칙:
요청 ID로 확인할 처리 단계:
평가 세트와 변경 전 기준선:
이번 변경의 전후 결과와 남은 한계:'관심있는 주제 > 탐구 노트' 카테고리의 다른 글
| EmbeddingGemma 2와 LAYA의 Retrieve–Rerank 구조를 직접 실험해봤다 (0) | 2026.10.07 |
|---|---|
| LAYA 딥다이브: BERT와 무엇이 다르고, 한국어에서 얼마나 통할까? - 실험편 (0) | 2026.10.05 |
| LLM Wiki가 커질 때 어떻게 운영할까: 3만 문서·100만 링크에서 배운 확장 전략 (0) | 2026.09.23 |
| LLM 서비스 개발자는 어떻게 일해야 할까: 요청부터 AS-IS·TO-BE 검증, 배포까지 (0) | 2026.09.19 |
| MCP는 AI용 함수 호출을 넘어 어디로 가는가: Python 개발자가 알아야 할 2026 로드맵 (0) | 2026.08.24 |