시리즈

API는 stateless다. assistant 메시지를 messages 배열에 누적해서 보내야 챗봇이 직전 대화를 기억한다. 직접 비교 실험으로 확인했다.

Claude API에서 페르소나를 실험하다 마주친 의문: 시스템 프롬프트와 'user 메시지에 ~이렇게 해줘'를 그냥 적는 건 어떻게 다른가? 일관성·보안·출력 강제 측면에서 정리했다.

스트리밍은 단순한 'LLM처럼 글자가 흘러나오는 효과'가 아니다. 같은 총 시간이라도 사용자가 첫 결과를 보기까지의 시간(TTFT)이 달라지고, 그 차이가 UX의 핵심이다. 그리고 그걸 받는 이벤트 순서도 직접 찍어봤다.

LLM은 큰 수 계산도, 오늘 날씨도 모른다. 그 약점을 외부 함수 호출로 메우는 Tool Use를 처음 만져봤다. 메시지 흐름, 다중 도구 자동 선택, 에이전트 루프까지.

이미지를 base64로 인코딩해서 보내는 방식과 URL로 보내는 방식 두 가지를 모두 써봤다. 정확하지만 토큰 비용이 더 든다는 점, 작은 텍스트·복잡한 도형의 한계, 그리고 정확도가 필요한 작업에는 더 큰 모델로 옮겨야 한다는 감각까지.

긴 시스템 프롬프트나 같은 컨텍스트를 매 호출마다 보내는 챗봇·에이전트·RAG에 필수인 prompt caching. 직접 STM32/임베디드 질문으로 캐싱 유무를 비교 실험했더니 비용은 절반, 시간은 미미하게 줄었다.

신뢰성 있는 LLM 서비스를 만들려면 어떤 에러를 어떻게 처리해야 하는가. 에러 종류를 일시적 / 영구 / 사용자 입력 / 응답 형식으로 분류하고, 기본 try-except 래퍼 → Exponential backoff → Anthropic SDK 내장 재시도 → JSON 응답 검증까지 4단계로 실습.

RAG (Retrieval-Augmented Generation) 의 안쪽을 직접 코드로 깎으면서 임베딩이 무엇인지부터 의심스러운 결과를 디버깅하는 데까지. OpenAI text-embedding-3-small 로 1536차원 벡터를 뽑고, 코사인 유사도로 비교하고, 한국어 vs 영어 성능을 비교하고, 청크 분할까지. 의외로 한국어 임베딩 유사도가 낮은 게 관찰됨.

어제 RAG 의 부품 (임베딩 / 코사인 유사도 / 청크) 을 만져봤다면, 오늘은 그걸 통합한 시스템. Chroma 벡터 DB 도입, 블로그 270 청크를 인덱싱, OpenAI + Claude 로 Q&A. 가장 인상 깊었던 건 '블로그에 없는 정보' 를 받았을 때 모르겠다고 답한 순간.

공부 후보로 적어뒀던 LangGraph 시작. StateGraph 로 노드·엣지·조건 분기·루프 짜는 건 생각보다 직관적이었는데, 'State' 라는 용어가 와닿지 않아 헤맸다. 결국 게임 캐릭터의 인벤토리·HP 로 비유해서 정착.

메시지만 들고 다니던 State 를 사용자 이름·도구 호출 횟수·세션 시작 시간까지 확장하고, 그 State 로 시스템 프롬프트를 동적으로 구성. 마지막에 챗봇을 만들다가 '기억' 의 정체를 알아챈 게 오늘의 진짜 깨달음.

에이전트가 파일 삭제·이메일 발송·결제 같은 위험 도구를 자동으로 호출하면 사고난다. LangGraph 의 체크포인트 + Interrupt 메커니즘으로 위험 도구 직전에 사람의 승인을 받는 HITL 패턴 구현. 의외의 함정: LLM 자체 안전장치가 HITL 까지 도달을 막아버리는 케이스. 시스템 프롬프트와 HITL 게이트를 어떻게 분리해야 하는지.

FEMS 프로젝트를 진행하다가 '벡터 DB 에 뭘 어떻게 넣어야 하는가' 가 궁금해서 정리. 핵심 깨달음 — 데이터는 '도메인' 기준이 아니라 '검색되어야 할 질문' 기준으로 거꾸로 선정한다. 그 외 클렌징 / 청크 앞 메타데이터(문서 제목·섹션 경로) 의 효과 / 아날로그 데이터 OCR 전처리 / 평가셋 구축까지 RAG 데이터 파이프라인 전체 흐름.

오늘부터 MCP (Model Context Protocol) 공부 시작. Anthropic 이 만든 표준 프로토콜로, LLM 이 외부 시스템에 접근하는 방식을 표준화. Tool Use 와의 차이 비교 → Python SDK 로 첫 MCP 서버 (say_hello / add_numbers) 구현 → MCP Inspector 로 stdio 연결 확인 → FEMS 와 연결되는 가짜 에너지 관리 서버까지. venv python.exe 경로 문제로 연결 실패 + 해결.

어제 만든 energy-management MCP 서버를 Claude Desktop 에 실제로 연결. claude_desktop_config.json 찾는 법(설정 → 개발자 → 구성 편집) → 서버 등록 → 재시작 → 커넥터 메뉴에서 확인 → '공장 라인 목록 보여줘' 질문에 Claude 가 도구 호출 + '항상 허용/거부' 승인 UX 까지. 의문 — RAG 와 MCP 를 같이 쓰는 방법은? (답: RAG 를 MCP 서버로 감싸면 됨)

MCP 의 세 구성요소 중 #1 / #2 에서 다룬 Tools 외에 Resources(LLM 이 읽을 데이터, 백그라운드 컨텍스트, 읽기 전용) 와 Prompts(미리 정의된 템플릿) 까지. Inspector + Claude Desktop 으로 새 서버 확인 → langchain-mcp-adapters 로 MCP 서버를 LangGraph 에 통합. MCP 통신이 비동기라 `ainvoke` 필요한 이유, MultiServerMCPClient 가 서버 그대로 불러오는 비결(=MCP 표준 준수), Resources 를 시스템 프롬프트로 주입했을 때의 도메인 응답 품질 차이까지.

여태 프로젝트마다 '빠른 거 같다', '정확한 것 같다' 식 느낌 평가만 해왔는데, 이제 진짜로 수치화하는 Eval 공부 시작. Eval 의 4가지 종류(정확도 / 유사도 / LLM-as-Judge / 사람 평가) 정리 + 도구 선택 정확도 10/10 측정 + LLM-as-Judge 로 같은 질문에 대한 두 답변을 8/10 vs 3/10 으로 채점. LLM-as-Judge 의 한계(평가자 변동성, 같은 모델 답변 후한 점수)까지.

Eval 두 번째 시간. 유사도 기반 평가 (임베딩 코사인) 를 직접 돌려봤더니 예상 못 한 결과 — OpenAI text-embedding-3-small 과 bge-m3 둘 다 '틀린 답' 에 가장 높은 점수를 매김. 유사도는 내용이 아니라 주제·표현 근접성을 잡기 때문. 마크다운 형식 차이만으로도 유사도가 크게 흔들림. 실전에선 유사도 + LLM-as-Judge 병행이 표준. 그리고 테스트셋 설계 5원칙 + '회귀테스트가 아니라 개선 검증(A/B)' 이라는 용어 정정.

[퀀트 회고에서 '느낌 벤치마킹 → 수치 벤치마킹' 원칙](/posts/quant-study-00-pandas) 을 세운 뒤, 이번엔 임베딩 모델 비교를 실제로 수치화. 내 블로그 글 441청크에 OpenAI text-embedding-3-small 과 bge-m3 를 각각 인덱싱하고, 20개 질문·정답 출처 테스트셋으로 recall@3 을 측정. 전체 OpenAI 80% vs bge-m3 90%. hard 난이도에서 bge-m3 가 100% — 단어 안 겹쳐도 의미로 원문과 연결한 케이스가 결정적. easy 에서 놓친 원인은 오타(cladue, 언더스코어)라 채점 기준 자체가 틀렸다는 반전.

RAG Eval 이후 에이전트 Eval 로 확장. 에이전트는 판정할 축이 6가지 (도구 선택 · 인자 추출 · 멀티스텝 궤적 · 종료 판단 · 안전장치 · 최종 답변 품질) 라 단위 테스트 → 통합 테스트 원리로 축을 분리해서 봐야 원인 특정이 빠름. 오늘은 도구 선택 · 멀티스텝 · 함정 회귀 3개만 진행. MCP 서버 도구 메타 (이름 · 설명 · 스키마) 를 넣고 (질문, 기대 도구, 기대 인자, 레벨) 테스트셋으로 측정 → 도구 선택 정확도 11/13 = 84.6%. 실패 케이스 2건이 재미있었음 — (1) 단일 스텝 eval 이 실제로는 멀티스텝 궤적으로 정답인 케이스를 오탐 → 단일 채점의 한계, (2) 도구 description 이 모호해서 "전기 요금" → consumption 오선택, "돈 얼마 나와?" 는 정답 — description 개선 대신 시스템 프롬프트 땜빵은 과적합 위험. 이어서 멀티스텝 eval 로 전환 (필요 도구 다 불렀나 · 순서 · 앞 결과 활용 · 종료 판단) → 4/4 = 100% 로 단일에서 실패로 처리된 케이스가 통과.

지난 편 (에이전트 도구 선택 · 멀티스텝 eval) 에 이어 HITL 에이전트 회귀 테스트. 이번엔 (질문 · 기대 도구) 테스트셋 대신 단위 테스트 스타일 — 함정 3축 (위험 도구 중단점 진입 / 멀티턴 매 턴 응답 / 안전 도구 오분류) 을 함수로 작성하고 sys.exit(1) 로 회귀 시 종료 코드. 1차 실행 3/3 통과 — 그런데 이게 정답이 아니었음. 이전에 문제였던 "명확한 의도 확인 후 호출" 프롬프트가 남아있어서 LLM 이 자체 방어기제로 통과시킨 것. 삭제 케이스로 도발하니 우리 HITL 은 발동 안 하고 LLM 자체 확인만 남음. 프롬프트 제거 → 도구 자체를 안 부르는 실패로 전환. 결국 프롬프트를 "사용자가 요청한 작업에 맞는 도구를 호출하세요" 로 최소화하니 delete_user 도구에서 정확히 중단 (HITL 작동, 종료 코드 0). Eval 통과 자체가 안전 신호가 아니라 무엇 때문에 통과했는지 원인 검증이 진짜 안전. 여기서 LLM 공부 시리즈 잠시 중단, 백엔드 공부 마무리 후 재개 예정.

부족한 백엔드 · 상용화 경험을 채우기 위해 자바 학습 시작. 자바 설치부터 시작해서 switch 의 -> 화살표 문법 · for-each · 정수 나눗셈에서 double 캐스팅 필요성 · public class 파일 규칙 · private + getter 로 캡슐화 · static 유무의 차이 · @Override 어노테이션 · implements 로 인터페이스 연동까지 하루에 훑음. Python / C++ 경험이 있어 개념적으로는 익숙한 부분이 많았음.

자바 공부 2주차. Collection Framework 핵심 — List (ArrayList), Map (HashMap), Set 을 훑고, 각각 '인터페이스와 구현체' 패턴이 보임 (List<String> books = new ArrayList<>()). 이후 Stream 으로 넘어가 for 문 없이 filter → map → collect 파이프라인, method reference (System.out::println), groupingBy + counting 조합. 마지막은 Optional — get() 즉시 호출 대신 ifPresent / orElse / map 으로 값 없을 때를 항상 함께 처리해야 하는 감각.

자바 문법 훑기 마무리 편. 예외 처리는 디버깅 편의가 아니라 백엔드 서버가 프로덕션에서 안 죽게 하기 위한 방어막이었음을 이해. print vs throw 의 차이 — print 는 호출자에게 실패를 전달하지 않지만 예외는 강제로 전파. 동시성은 ExecutorService · newFixedThreadPool 로 3초 순차 → 1초 병렬 (실측 3008ms → 1006ms). record 는 필드·생성자·접근자·toString·equals·hashCode 자동 생성 — 강우량계 데이터로거의 RainDataDTO 같은 순수 데이터 컨테이너에 딱 맞음. var/switch 화살표/텍스트 블록 같은 Modern Java 도 훑음. 마지막으로 Gradle — 파일이 수백 개 될 때 java 로 하나씩 컴파일하는 건 불가능, 외부 라이브러리도 자동으로 받아옴. build.gradle 이 핵심 설정 파일.

자바 #3 (예외 · 동시성 · Gradle) 을 매듭짓고 오늘부터 Spring Boot. Spring Initializr 로 hello-spring 프로젝트를 뽑고 ./gradlew bootRun 으로 실행 — 터미널이 "80% EXECUTING" 에서 멈춘 것처럼 보이는데 사실은 이미 서버가 8080 에 뜬 상태 (Gradle daemon 이 프로세스를 붙잡고 있어서 진행률이 그렇게 표시됨). Spring Boot 는 Tomcat 을 내장하고 있어서 별도 WAS 설치 없이 8080 이 뜨는 것. 엔드포인트가 없으면 8080 에 접속해도 에러 페이지가 나오고, @RestController + @GetMapping 으로 경로를 지정해야 응답이 붙는다. 이후 의존성 주입 (DI) 감 잡기 — 컨트롤러가 서비스 인스턴스를 new 로 만들지 않는데도 서비스가 주입되는 이유는 스프링이 시작 시 @Service 클래스의 인스턴스를 하나 만들어 빈 (Bean) 으로 보관하고 있다가 컨트롤러 생성자에 자동으로 꽂아주기 때문. 자바 #1 부터 이어진 인터페이스 감각 — 구현체를 모르고 넘겨받아서 쓰는 계약성 — 이 스프링에서 자동화된 형태. 결합도가 낮아지고 테스트가 쉬워지는 이유가 여기 있다.

Spring Boot #1 (첫 실행 · DI) 에 이어 #2 는 REST API 로 CRUD. REST 는 URL + HTTP 메서드의 조합이라는 정의부터 정리 (GET/POST/PUT/DELETE), 컨트롤러에 @GetMapping · @PostMapping · @PutMapping · @DeleteMapping 붙여서 todos CRUD 완성. curl 옵션 (-X 메서드 · -H 형식 · -d 데이터) 정리 및 5스텝 curl 흐름 검증 (생성 → 전체 조회 → 수정 → 삭제 → 최종 조회). 컨트롤러가 로직까지 다 들고 있으니 서비스로 분리 → 레이어드 아키텍처 (Controller = 요청/응답 / Service = 로직 / Repository = 저장). 예외 처리는 커스텀 예외 → 404 응답, 그리고 전역 예외 처리기 (Global Exception Handler) 를 두면 컨트롤러는 그냥 throw 만 하고 응답 매핑은 처리기가 담당 — 자바 #3 편에서 배운 "throw 는 강제 전파" 계약성이 실전으로 확장됨. 시행착오 2건 (참조 클래스 없이 서버 켜기 요청 · 라이브러리 추가 전 패키지 작성) 은 학습 지침에 반영해서 다음부터 재발 방지.

SQLite만 쓰다 PostgreSQL을 처음 잡았다. CREATE부터 CRUD 대응, 그리고 ORDER BY가 가나다 순으로 안 되던 collation 문제까지.

인메모리 List 로 하던 CRUD 를 실제 PostgreSQL 로 교체했다. build.gradle 의존성부터 application.properties, record 를 버리고 @Entity 로, JpaRepository 는 빈 인터페이스인데 CRUD 가 되는 이유, 그리고 컨트롤러를 한 줄도 안 바꾼 레이어 분리의 배당금까지.

엔티티를 @ManyToOne 으로 연결하고 전체 조회를 했더니 쿼리가 1번이 아니라 6번 나갔다. LAZY 로딩이 부른 N+1 문제를 fetch join 으로 잡고, @Transactional 의 원자성과 더티 체킹까지 정리한다.

curl 을 날릴 때마다 스레드가 하나씩 늘어났다. 톰캣이 일꾼을 미리 뽑아두고 요청을 배정하는 구조부터, 스레드풀과 DB 커넥션 풀의 균형, 그리고 헷갈리는 '아파치'의 두 얼굴까지 정리한다.

jps·jstat 로 힙을 관찰하고 GC 로그를 찍어봤다. Young/Old 로 나뉜 힙 구조부터, C 의 수동 메모리 관리와의 대비, 그리고 DB 커넥션풀을 1개로 줄였더니 2초짜리 작업이 6초가 되는 병목을 직접 재현한 기록.

로그인/인증·예약·결제 같은 기능을 하나씩 파보기로 했다. 첫 주제는 세션 기반 인증. 인증 vs 인가, HTTP가 stateless라 생기는 근본 문제, 세션이 '사물함 번호표'처럼 동작하는 원리, Spring Security, 비밀번호를 왜 BCrypt로 해싱하는지, 그리고 세션 방식의 약점까지.

세션 방식의 약점(서버가 세션을 다 기억해야 함)을 JWT는 어떻게 푸는가. 토큰 자체에 정보를 담는 구조(헤더·페이로드·서명), 페이로드가 암호화가 아니라 그냥 base64라는 함정, jjwt로 토큰을 만들고 검증하는 코드, 그리고 JWT가 새로 만드는 문제(취소 불가)까지.

포트폴리오용 자율주행 자동차 사이드 프로젝트 1편. 라즈베리파이 5 + STM32 + RS485 조합으로, 오늘은 프레임 조립과 Pi 5 OS 세팅, ROS2 Jazzy 설치까지. 의존성 깨짐을 universe·noble-updates 저장소 추가로 해결한 기록 포함.

ROS2 talker / listener 패턴으로 첫 노드를 작성하고, geometry_msgs/Twist 로 /cmd_vel 을 받아 좌·우 바퀴 속도로 변환했다. 이후 STM32 에선 TIM4 PWM 설정으로 LED 순환 점등. 두 영역이 어떻게 만날지 감 잡기 시작.

오늘은 코딩 없는 날. DPDT 로커 스위치 도통 테스트하다 AI 지적으로 양극성 차단 구조 다시 확인, 배터리 + 스위치 납땜, 배터리 출하 전압 점검, 그리고 홀 센서용 네오디움 자석을 휠에 붙였다. 부품 추가 구매로 진도가 1주일 지연된 게 빡친다.

드디어 USB-UART 컨버터 도착. STM32F407 의 USART2 로 1초마다 메시지를 송신하고 PC 시리얼 모니터에서 수신 확인. USART3 을 RS485 용으로 남겨둔 이유, blocking 부터 시작하는 이유, STM32CubeIDE 안에서 시리얼 콘솔 띄우는 법까지. 그리고 ROS2 launch 파일로 노드 두 개 동시 실행.

AI에게 UI를 만들게 시킬 때 '예쁘게', '부드럽게' 같은 막연한 말은 통하지 않는다. 상태(state), 움직임(motion), 위계(hierarchy) 라는 세 축의 어휘를 직접 정리하면서 만든 첫 번째 용어 정리 글. 본문 끝에 직접 만져볼 수 있는 playground 링크도 같이.

UI 어휘 정리에 이은 용어 시리즈 2탄. 'DB 좀 짜줘' 라는 막연한 지시를 벗어나기 위한 6가지 핵심 어휘 — 정규화, 관계, 인덱스, 트랜잭션, 격리 수준, 마이그레이션 — 을 한 줄기로 엮어 정리. 핵심 개념은 playground에서 직접 만져볼 수 있게 따로 만들어뒀다.

용어 정리 시리즈 3탄. DB 테이블을 만든 다음 그 자원을 외부에 어떻게 노출하는가. 'API 짜줘' 라는 막연한 지시를 벗어나기 위한 5가지 핵심 어휘 — REST · 상태 코드 · 멱등성 · 페이지네이션 · 인증/인가 — 와 보너스 CORS 까지. 핵심 개념은 playground 에서 직접 만져볼 수 있게 따로 만들어뒀다.

용어 정리 시리즈 4탄이자 마지막. 'AI 에게 상태 관리 짜줘' 라는 막연한 지시를 벗어나기 위한 4가지 핵심 어휘 — Client/Server State 분리, Derived (파생 상태), Optimistic Update, Cache Invalidation + 트리거 패턴. 핵심 개념은 playground 에서 직접 만져볼 수 있게 따로 만들어뒀다.