최영선의 블로그

핵심 질문LLM 앱 운영을 어떻게 통합해야 모니터링·비용·평가·보안·배포가 일관되게 동작할까요?이 글은 그 질문에 답하기 위해 LLM 앱 운영 통합의 핵심 결정과 운영 함정을 살펴봅니다.이 글에서 답할 질문로깅, 비용, 품질 평가를 한 엔드포인트에 어떻게 합칠까요?헬스체크에서 누적 호출 수와 비용을 함께 보여 주는 이유는 무엇일까요?통합 파이프라인에서 가장 먼저 실패시켜야 하는 지점은 어디일까요?운영 완성의 핵심은 기능을 많이 넣는 것이 아니라, 한 요청이 남기는 로그·비용·품질 신호가 서로 연결되도록 만드는 것입니다.큰 그림LLM 운영 파이프라인 전체 구성왜 이 레이어가 필요한가입력 검증부터 로그 기록까지 이어지는 운영 흐름통합 파이프라인은 개별 기능 소개가 아니라, 한 요청이 남기는 운영 신호를 연결..

핵심 질문LLM 앱 배포 전략을 어떻게 설계해야 안전하게 변경을 적용할 수 있을까요?이 글은 그 질문에 답하기 위해 LLM 앱 배포의 핵심 결정과 운영 함정을 살펴봅니다.이 글에서 답할 질문FastAPI 기반 LLM 엔드포인트에서 health check는 어디까지 확인하면 충분할까요?동기 Groq 클라이언트를 async 엔드포인트에서 안전하게 호출하려면 어떻게 감싸야 할까요?로컬 self-test로 서버 기동 여부를 자동 확인하려면 어떤 흐름이 가장 단순할까요?배포 가능한 예제의 기준은 코드가 예쁘게 보이는지가 아니라, 서버를 띄우고 헬스체크와 실제 채팅 요청을 같은 스크립트에서 검증할 수 있느냐입니다.큰 그림self-test가 헬스체크와 채팅 요청을 검증하는 흐름왜 이 레이어가 필요한가서버 기동 확인이..

핵심 질문LLM 앱 보안을 어떻게 설계해야 prompt injection·데이터 유출 사고를 막을 수 있을까요?이 글은 그 질문에 답하기 위해 LLM 앱 보안의 핵심 결정과 운영 함정을 살펴봅니다.이 글에서 답할 질문프롬프트 인젝션을 가장 단순하게 막으려면 무엇부터 검사해야 할까요?사용자 입력에 섞인 이메일이나 키를 호출 전에 어떻게 가릴까요?출력 필터는 무엇을 막고 무엇을 못 막는다고 봐야 할까요?LLM 보안은 완벽한 차단보다 실패 지점을 앞당기는 작업입니다. 위험 입력을 모델 앞에서 끊고, 위험 출력을 사용자 앞에서 한 번 더 끊어야 합니다.큰 그림LLM 앱 보안 레이어 구성왜 이 레이어가 필요한가입력 가드와 출력 필터가 양쪽에서 막는 흐름보안 레이어는 모델 앞과 모델 뒤에서 각각 한 번씩 실패를 조..

핵심 질문LLM 출력 품질을 어떻게 평가해야 회귀를 막고 개선을 측정할 수 있을까요?이 글은 그 질문에 답하기 위해 LLM 출력 평가의 핵심 결정과 운영 함정을 살펴봅니다.이 글에서 답할 질문모델 응답이 길이 제한을 지켰는지 자동으로 어떻게 확인할까요?핵심 키워드 포함 여부를 품질 게이트로 쓰려면 어떤 구조가 단순할까요?형식 검사를 JSON 파싱 수준에서 끝낼지, 스키마 검증까지 갈지 어떻게 판단할까요?평가 자동화의 첫 단계는 의미를 완벽히 이해하는 심판을 만드는 것이 아니라, 명확하게 실패한 응답을 빠르게 걸러내는 체를 만드는 것입니다.큰 그림LLM 출력 품질 평가 파이프라인왜 이 레이어가 필요한가규칙 기반 평가가 명확한 실패를 거르는 흐름자동 평가는 모델을 심판으로 쓰기 전에, 기계적으로 실패를 걸러..

핵심 질문LLM 비용을 어떻게 추적·최적화해야 비용이 통제 불능이 되지 않을까요?이 글은 그 질문에 답하기 위해 LLM 비용 추적·최적화의 핵심 결정과 운영 함정을 살펴봅니다.이 글에서 답할 질문토큰 사용량을 호출별로 어떻게 누적해야 할까요?단가가 단순할 때 비용 계산 코드는 어디까지 추상화하면 충분할까요?같은 프롬프트를 여러 번 호출했을 때 어떤 숫자를 먼저 봐야 절감 포인트가 보일까요?비용 추적은 회계가 아니라 피드백 루프입니다. 호출 한 건이 얼마였는지 알아야 캐시, 프롬프트 압축, 모델 라우팅이 의미를 가집니다.큰 그림비용 추적 흐름과 최적화 지점왜 이 레이어가 필요한가호출별 토큰이 누적 비용으로 모이는 흐름비용은 LLM 기능이 성공할수록 더 중요해지는 운영 지표입니다. 그래서 초기에 계산식을 코..

이 글은 Docker 101 시리즈의 7번째 글입니다.Python 애플리케이션을 컨테이너에 넣는 일은 생각보다 빨리 시작할 수 있습니다. 하지만 "컨테이너 안에서 뜬다"와 "운영에 올려도 된다"는 전혀 다른 말입니다. 로컬에서는 잘 돌아가도 배포 시 종료 신호를 제대로 받지 못하거나, readiness를 알리지 못하거나, root로 실행되는 상태로 남아 있으면 운영 사고로 바로 이어집니다.특히 FastAPI처럼 웹 요청을 처리하는 애플리케이션은 종료 시점이 중요합니다. 새 배포가 시작될 때 기존 요청을 안전하게 마무리하고 내려가야 하기 때문입니다. 그래서 Python 컨테이너화의 핵심은 단순 실행보다 PID 1, signal, healthcheck, non-root 같은 운영 조건에 있습니다.'컨테이너 ..

테스트 더블을 배운 뒤에도 Mock과 Stub은 자주 뒤섞입니다. 둘 다 가짜 객체처럼 보이기 때문입니다. 그런데 목적은 꽤 다릅니다. 이 차이를 놓치면 결과를 검증해야 할 테스트를 호출 검증으로 가득 채우거나, 반대로 상호작용이 핵심인 테스트를 너무 느슨하게 만들게 됩니다.좋은 테스트는 실패했을 때 무엇이 깨졌는지 한 줄로 말해 줍니다. Mock과 Stub을 구분하는 일은 그 한 줄을 선명하게 만드는 작업입니다.이 글은 Testing 101 시리즈의 여섯 번째 글입니다. 여기서는 unittest.mock 예제를 바탕으로 Mock과 Stub의 목적 차이, 상태 검증과 상호작용 검증의 차이, 그리고 과한 Mock 사용이 보내는 설계 신호를 정리하겠습니다.Testing 101 6장 흐름 개요Stub은 응답을..

테스트를 처음 배우면 가장 먼저 드는 질문이 있습니다. 어디까지를 하나의 테스트 단위로 봐야 할까요? 함수 하나일 수도 있고, 메서드 하나일 수도 있고, 클래스의 특정 동작 하나일 수도 있습니다. 범위를 너무 넓게 잡으면 원인을 찾기 어려워지고, 너무 모호하게 잡으면 테스트가 금방 무거워집니다.그래서 단위 테스트는 크기를 줄이는 연습이기도 합니다. 외부 의존을 걷어 내고, 작은 동작 하나를 빠르게 확인하는 방식으로 신뢰를 쌓습니다.이 글은 Testing 101 시리즈의 두 번째 글입니다. 여기서는 단위 테스트의 범위, AAA 패턴, pytest의 기본 작성법, 그리고 좋은 단위 테스트가 갖춰야 할 조건을 정리하겠습니다.Testing 101 2장 흐름 개요단위 테스트는 한 가지 동작만 검증하고, 같은 동작..

기능이 돌아가는 백엔드와 운영 가능한 백엔드는 같은 단계가 아닙니다. 운영 가능한 백엔드는 트래픽 증가, 장애 대응, 배포 복구를 예측 가능한 절차로 처리할 수 있어야 합니다.이 글은 Backend Development 101 시리즈의 마지막 글입니다.이번 글은 시리즈 1~9편에서 나눠 다뤘던 서버, 라우팅, 서비스 레이어, 데이터베이스, 인증, 로깅, 테스트, 배포를 하나의 프로덕션 구조로 묶는 캡스톤입니다. 핵심은 "기능 목록"이 아니라 "운영 성숙도"입니다. 운영 성숙도는 관측 가능성(Observable), 배포 가능성(Deployable), 테스트 가능성(Testable), 복구 가능성(Recoverable) 네 축으로 확인할 수 있습니다.Backend Development 101 10장 흐름 개..

로컬에서 잘 돌아가는 백엔드가 운영에서 실패하는 장면은 드물지 않습니다. 코드가 틀렸기 때문이 아니라, 실행 환경이 재현되지 않았기 때문인 경우가 더 많습니다. 배포를 "코드를 서버에 올리는 일"로 이해하면 이 실패를 설명하기 어렵고, 배포를 "실행 환경을 버전으로 고정하는 일"로 이해하면 실패 원인과 해결 순서가 선명해집니다.이 글은 Backend Development 101 시리즈의 9번째 글입니다.이번 글에서는 재현 가능한 배포를 중심에 두고 Docker, 환경 변수, health check, rolling update, CI/CD, reverse proxy, 로컬 compose 운영까지 한 번에 연결하겠습니다. 목표는 명령어 암기가 아니라 "왜 이 순서로 설계해야 운영에서 안전한가"를 이해하는 것..