LLM 관측성: 토큰·지연·비용 트레이싱 대시보드 구축
LLM 애플리케이션을 프로덕션에 올리면, 전통적인 웹 관측성 도구만으로는 설명되지 않는 공백이 생깁니다. HTTP 상태 코드는 200인데 사용자는 “답이 틀렸다”고 하고, 지연은 평균적으로 괜찮은데 특정 요청만 30초씩…
LLM 애플리케이션을 프로덕션에 올리면, 전통적인 웹 관측성 도구만으로는 설명되지 않는 공백이 생깁니다. HTTP 상태 코드는 200인데 사용자는 “답이 틀렸다”고 하고, 지연은 평균적으로 괜찮은데 특정 요청만 30초씩…
단일 에이전트로 처리하던 작업이 커지면, 하나의 프롬프트 안에 도구 수십 개와 상충하는 지시가 뒤섞이기 시작합니다. 컨텍스트가 길어질수록 모델은 앞쪽 지시를 잊고, 도구 선택은 흔들리며, 디버깅은 “어디서…
LLM을 실제 파이프라인에 연결하는 순간 가장 먼저 부딪히는 벽은 “모델의 답이 문장”이라는 사실입니다. 다운스트림 코드가 필요한 건 if resp["risk"] == "high"처럼 바로 분기할 수 있는 필드입니다.…
RAG 파이프라인의 품질을 좌우하는 것은 화려한 임베딩 모델이나 재랭커가 아니라, 그 앞단에서 원문을 어떻게 잘라 넣었는가입니다. 문서를 조각(chunk)으로 나누는 방식이 검색 리콜과 답변 정확성을 사실상 결정합니다.…
RAG 파이프라인을 처음 만들 때 대부분 벡터 검색 하나에 의존합니다. 문서와 질문을 임베딩으로 바꿔 코사인 유사도가 높은 청크를 뽑아 프롬프트에 붙이는 구조입니다. 데모에서는 잘 돌아가지만, 실사용…
LLM 애플리케이션이 외부 텍스트를 다루기 시작하는 순간, 새로운 공격 표면이 열립니다. 검색된 웹페이지, 업로드된 문서, 이메일 본문, 도구가 반환한 API 응답 — 이 모든 것이 모델의…
LLM을 자체 서빙할 때 값비싼 GPU를 사놓고도 처리량이 기대만큼 나오지 않는 경험은 흔합니다. 원인은 대개 연산이 아니라 메모리와 스케줄링입니다. 트랜스포머 추론은 매 토큰마다 이전 토큰들의 키·값…
대형 언어 모델을 자기 도메인에 맞게 파인튜닝하려 할 때 가장 먼저 부딪히는 벽은 VRAM입니다. 70억 파라미터 모델을 전체 파인튜닝(full fine-tuning)하려면 가중치·그래디언트·옵티마이저 상태를 모두 올려야 하고, 이…
LLM으로 도메인 특화 애플리케이션을 만들 때 반드시 마주치는 갈림길이 파인튜닝(fine-tuning)과 RAG(Retrieval-Augmented Generation)입니다. 둘 다 “기본 모델을 우리 문제에 맞게 만든다”는 목적은 같지만, 무엇을 바꾸는지가 근본적으로 다릅니다.…
LLM 에이전트에 도구(tool)를 붙이는 순간, 데모는 화려하지만 프로덕션은 지옥이 됩니다. 모델이 존재하지 않는 도구를 부르고, 인자를 엉뚱하게 채우고, 같은 도구를 무한 반복 호출하고, 도구가 던진 에러를…