Posts
All the articles I've posted.
-
Spring Boot #2 — REST API 로 CRUD · 레이어드 아키텍처 · 전역 예외 처리기
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건 (참조 클래스 없이 서버 켜기 요청 · 라이브러리 추가 전 패키지 작성) 은 학습 지침에 반영해서 다음부터 재발 방지.
-
Spring Boot #1 — 첫 실행 (bootRun · Tomcat 내장) · @RestController · 의존성 주입 감 잡기
자바 #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 부터 이어진 인터페이스 감각 — 구현체를 모르고 넘겨받아서 쓰는 계약성 — 이 스프링에서 자동화된 형태. 결합도가 낮아지고 테스트가 쉬워지는 이유가 여기 있다.
-
Eval 공부 #4 — HITL 에이전트 회귀 테스트, 통과했는데 원인이 틀린 경우
지난 편 (에이전트 도구 선택 · 멀티스텝 eval) 에 이어 HITL 에이전트 회귀 테스트. 이번엔 (질문 · 기대 도구) 테스트셋 대신 단위 테스트 스타일 — 함정 3축 (위험 도구 중단점 진입 / 멀티턴 매 턴 응답 / 안전 도구 오분류) 을 함수로 작성하고 sys.exit(1) 로 회귀 시 종료 코드. 1차 실행 3/3 통과 — 그런데 이게 정답이 아니었음. 이전에 문제였던 "명확한 의도 확인 후 호출" 프롬프트가 남아있어서 LLM 이 자체 방어기제로 통과시킨 것. 삭제 케이스로 도발하니 우리 HITL 은 발동 안 하고 LLM 자체 확인만 남음. 프롬프트 제거 → 도구 자체를 안 부르는 실패로 전환. 결국 프롬프트를 "사용자가 요청한 작업에 맞는 도구를 호출하세요" 로 최소화하니 delete_user 도구에서 정확히 중단 (HITL 작동, 종료 코드 0). Eval 통과 자체가 안전 신호가 아니라 무엇 때문에 통과했는지 원인 검증이 진짜 안전. 여기서 LLM 공부 시리즈 잠시 중단, 백엔드 공부 마무리 후 재개 예정.
-
Eval 공부 #3 — 에이전트 Eval, 단일 스텝의 한계와 멀티스텝 채점
RAG Eval 이후 에이전트 Eval 로 확장. 에이전트는 판정할 축이 6가지 (도구 선택 · 인자 추출 · 멀티스텝 궤적 · 종료 판단 · 안전장치 · 최종 답변 품질) 라 단위 테스트 → 통합 테스트 원리로 축을 분리해서 봐야 원인 특정이 빠름. 오늘은 도구 선택 · 멀티스텝 · 함정 회귀 3개만 진행. MCP 서버 도구 메타 (이름 · 설명 · 스키마) 를 넣고 (질문, 기대 도구, 기대 인자, 레벨) 테스트셋으로 측정 → 도구 선택 정확도 11/13 = 84.6%. 실패 케이스 2건이 재미있었음 — (1) 단일 스텝 eval 이 실제로는 멀티스텝 궤적으로 정답인 케이스를 오탐 → 단일 채점의 한계, (2) 도구 description 이 모호해서 "전기 요금" → consumption 오선택, "돈 얼마 나와?" 는 정답 — description 개선 대신 시스템 프롬프트 땜빵은 과적합 위험. 이어서 멀티스텝 eval 로 전환 (필요 도구 다 불렀나 · 순서 · 앞 결과 활용 · 종료 판단) → 4/4 = 100% 로 단일에서 실패로 처리된 케이스가 통과.