최영선의 블로그

벡터 검색 101 시리즈 (2/6)예제 코드: github.com/yeongseon-books/vector-search-101지난 글에서 임베딩의 개념을 잡았다면, 이번 글은 실제로 벡터를 만들고 다루는 방법에 집중합니다. 이론을 코드로 옮기는 과정에서 자주 막히는 부분이 있습니다. 모델 로딩 시간을 어떻게 줄일지, 배치를 어떻게 구성할지, 벡터를 디스크에 저장했다가 재사용하는 방법은 무엇인지 같은 실용적인 질문들입니다.langchain-community의 HuggingFaceEmbeddings는 sentence-transformers를 LangChain 호환 인터페이스로 감싼 클래스입니다. LangChain 생태계와 연동하지 않더라도, 임베딩 래퍼 패턴 자체가 실제 앱에서 어떻게 쓰이는지 이해하는 데 ..

벡터 검색 101 시리즈 (1/6)예제 코드: github.com/yeongseon-books/vector-search-101검색 엔진은 오랫동안 키워드를 비교했습니다. 사용자가 "파이썬 비동기"를 입력하면 엔진은 그 단어가 문서에 얼마나 많이, 어떤 위치에 등장하는지를 봤습니다. 이 방식은 단어가 정확히 일치할 때 잘 작동하지만, "파이썬으로 동시성 처리하기"처럼 의미는 같아도 표현이 다른 경우에는 약합니다.임베딩(embedding)은 이 문제를 다르게 풉니다. 텍스트를 숫자 벡터로 바꿔서, 의미가 비슷한 문장은 벡터 공간에서도 가깝게 놓습니다. "파이썬 비동기"와 "파이썬으로 동시성 처리하기"는 단어 수준에서는 다르지만, 잘 만든 임베딩 공간에서는 서로 가까운 위치에 놓입니다. 이 성질 덕분에 키워드..

LLM API 프로덕션 101 시리즈 (6/6)예제 코드: github.com/yeongseon-books/llm-api-production-101API를 오래 운영해 본 팀이라면 언젠가 같은 장면을 봅니다. 평소에는 문제없던 호출이 특정 시간대나 배치 시작 시점에 갑자기 실패하고, 로그에는 429 또는 rate limit 관련 메시지가 찍힙니다. LLM API도 예외가 아닙니다. 오히려 입력 토큰과 출력 토큰이 커서 요청 하나의 무게가 큰 만큼, 같은 순간에 트래픽이 몰리면 더 거칠게 제한에 부딪힐 수 있습니다.이때 많은 시스템이 두 가지 극단으로 흔들립니다. 하나는 아무 제어 없이 요청을 그대로 보내다가 공급자 제한에 계속 부딪히는 방식입니다. 다른 하나는 너무 보수적으로 직렬화해 처리량을 불필요하게..

LLM API 프로덕션 101 시리즈 (5/6)예제 코드: github.com/yeongseon-books/llm-api-production-101LLM API를 운영 경로에 붙이면 실패는 예외가 아니라 일상입니다. 네트워크가 잠깐 흔들릴 수 있고, 공급자 API가 순간적으로 느려질 수 있으며, 클라이언트가 제한 시간 안에 응답을 못 받을 수도 있습니다. 문제는 실패 그 자체보다, 실패 뒤의 코드가 얼마나 예측 가능하게 동작하느냐입니다. 같은 오류를 매번 손으로 다시 던지고 로그만 찍는 수준에서는 서비스가 금방 거칠어집니다.이 지점에서 가장 흔한 실수는 모든 예외를 한데 묶어 재시도하는 것입니다. 인증 오류도 다시 시도하고, 잘못된 요청 본문도 다시 시도하고, 모델이 구조화 출력 검증에 실패한 경우도 같..

LLM API 프로덕션 101 시리즈 (4/6)예제 코드: github.com/yeongseon-books/llm-api-production-101LLM API를 운영 환경에 붙이면 성능 문제보다 먼저 비용 문제가 눈에 들어오는 경우가 많습니다. 같은 질문이 반복되는데도 매번 모델을 다시 부르고, 같은 시스템 프롬프트와 같은 컨텍스트를 매 요청마다 토큰으로 재전송하면 응답 시간과 사용량이 같이 커집니다. 이때 많은 팀이 모델 교체나 프롬프트 축소부터 고민하지만, 실제로는 더 싼 해법이 앞에 있는 경우가 많습니다. 이미 계산한 답을 다시 쓰는 일, 즉 캐싱입니다.캐시는 새 개념이 아닙니다. 웹 서버, DB, CDN, 검색 시스템은 모두 오래전부터 같은 문제를 풀어 왔습니다. 다만 LLM 경로에서는 캐시 키..

LLM API 프로덕션 101 시리즈 (3/6)예제 코드: github.com/yeongseon-books/llm-api-production-101스트리밍은 데모에서는 화려한 효과처럼 보이지만, 운영에서는 부분 응답을 다루는 프로토콜 문제입니다. 첫 글자라도 빨리 보여 주면 사용자는 앱이 살아 있다고 느끼고, 긴 답변에서도 이탈이 줄어듭니다. 하지만 구현 난도는 단순한 stream=True 한 줄에서 끝나지 않습니다. 청크가 비어 있을 수 있고, 연결이 중간에 끊길 수 있으며, 마지막 메타데이터가 오기 전에 타임아웃이 날 수 있습니다. 완성된 문자열 하나를 받던 시절과는 실패 모양이 달라집니다.앞선 글에서 스트리밍의 기본 소비 패턴을 익혔다면, 이제는 스트림을 운영 경로로 다루는 기준이 필요합니다. 사용..

LLM API 프로덕션 101 시리즈 (2/6)예제 코드: github.com/yeongseon-books/llm-api-production-101구조화 출력까지 붙이고 나면 다음 요구가 자연스럽게 따라옵니다. 모델이 답변만 하지 말고, 애플리케이션 기능을 직접 선택해서 실행하게 만들고 싶다는 요구입니다. 예를 들어 배송 상태를 물으면 get_order_status()를 호출하고, 환율을 묻으면 내부 가격 조회 함수를 실행하고, 일정 생성 요청이 오면 캘린더 API를 붙이고 싶어집니다. 이때 많은 입문자가 모델에게 함수 이름을 문자열로 내놓게 한 뒤 if/elif로 해석합니다. 작게는 동작하지만, 호출 규약이 느슨하면 곧 예외 처리가 늘어납니다.툴 호출의 본질은 모델에게 "무슨 말을 할까"만 맡기는 것이..

LLM API 프로덕션 101 시리즈 (1/6)예제 코드: github.com/yeongseon-books/llm-api-production-101LLM API를 처음 붙인 뒤 가장 먼저 겪는 운영 문제는 모델 품질보다 출력 모양입니다. 데모 단계에서는 자연어 한 덩어리를 화면에 보여주면 끝이지만, 실제 서비스는 그 다음 단계가 더 중요합니다. 분류 결과를 DB에 넣어야 하고, 추출된 필드를 검증해야 하며, 후속 파이프라인이 같은 키 이름을 기대합니다. 여기서 모델이 보기 좋은 문장을 써 주는지는 두 번째 문제입니다. 더 중요한 것은 애플리케이션이 읽을 수 있는 형태로 답이 돌아오는가입니다.많은 팀이 이 지점에서 문자열 파싱으로 시간을 잃습니다. 모델에게 "JSON으로 답해 주세요"라고 적고 json.l..

LLM 앱 기초 시리즈 (6/6)예제 코드: github.com/yeongseon-books/llm-app-foundations-101아래 다이어그램은 스트리밍 응답에서 청크가 순차적으로 전달되는 흐름을 보여 줍니다.LLM 앱을 처음 붙이면 많은 입문자가 같은 실수를 합니다. 모델 호출을 일반적인 CRUD API처럼 다루는 것입니다. 요청을 보내고, 몇 초 기다린 뒤, 응답 본문 전체를 한 번에 받아 화면에 넣습니다. 기능만 보면 문제없어 보입니다. 실제로 데모도 돌아갑니다. 하지만 사용자가 체감하는 품질은 여기서 크게 갈립니다. 같은 5초라도 아무 변화 없이 멈춰 있는 5초와, 첫 글자가 300ms 안에 나타나고 그 뒤로 답이 계속 이어지는 5초는 완전히 다르게 느껴집니다.이 차이는 겉보기 효과가 아닙..

LLM 앱 기초 시리즈 (5/6)예제 코드: github.com/yeongseon-books/llm-app-foundations-101아래 다이어그램은 멀티턴 챗봇에서 메시지 이력이 누적되는 기본 흐름을 요약합니다.챗봇 UI를 처음 붙이면 많은 입문자가 같은 장면을 봅니다. 첫 질문에는 잘 답했는데, 두 번째 질문에서 방금 한 말을 잊어버립니다. 사용자는 대화를 이어 간다고 느끼는데 모델은 문맥이 끊긴 듯 반응합니다. 여기서 중요한 사실 하나를 먼저 분명히 해야 합니다. LLM은 기본적으로 상태를 들고 있지 않습니다. 우리가 매번 “대화처럼” 보이게 만들어 주기 때문에 대화가 되는 것입니다.실무에서는 이 차이를 빨리 이해해야 합니다. 상태가 없는 모델 앞에 상태가 있는 애플리케이션을 세우는 순간, 누가 ..