⌁15년차 백엔드 개발자의 기술 블로그

세상에 필요한 서비스를 만들고
쉽고 편리한 경험에 가치를 더합니다.

복잡한 문제를 단순하게 풀고, 오래 남는 사용자 경험을 고민합니다. Spring·Java 서버를 운영하며 겪은 문제와 AI 도구를 실무에 넣는 과정을 이곳에 기록합니다.

기술 글 보러가기

change_the_world.java

public class BetterWorld {

void deployJoy(Day today) {

// 작은 개선이 큰 변화를 만든다.

today.fixOneBug();

today.shareCoffee(HOT);

return users.smile() ? Status.BLOOMING : Status.LOADING;

} // deployJoy

}

About

재밌는걸 평생 만들고 싶어요.

“

기술적 부채(Tech Debt)보다 무서운 것은 '창의적 부채'다.
AI가 다 해줄 때, 당신의 독창성은 어디에 있는가?

”

Tech

기술 블로그

전체보기 >

LLM 회귀 테스트를 CI에 넣기: 매번 다른 출력을 어떻게 통과/실패로 가를까

같은 입력에 매번 다른 답이 나오는 걸 전제로 테스트를 짰습니다. 정확 일치 대신 성질 검사, 1회 실행 대신 통과율 임계값으로 CI 게이트를 만든 과정을 정리했습니다.

코딩 에이전트, 벤치마크 말고 우리 코드베이스 기준으로 고르기

여러 코딩 에이전트를 실제 작업에 번갈아 쓰면서 갈리는 지점이 분명해졌습니다. 탐색 범위·실행 루프·운영 적합성 세 축으로 판단 기준을 정리했습니다.

MCP가 바꾸는 연동 비용: 시스템마다 도구를 새로 만드는 반복을 끊다

붙일 시스템이 늘 때마다 도구 정의와 스키마를 새로 쓰는 일이 반복됐습니다. MCP를 표준 인터페이스로 두고 연동 비용이 곱셈에서 덧셈으로 바뀌는 지점을 정리했습니다.

에이전트 하네스 설계: 성능을 만드는 건 모델이 아니라 그 주변 구조였다

같은 모델인데 어떤 에이전트는 일을 해내고 어떤 건 계속 헛돕니다. 도구를 몇 개 쥐어줄지, 권한을 어디까지 열지, 실패했을 때 어떻게 되돌릴지를 설계한 과정을 정리했습니다.

컨텍스트 엔지니어링: 무엇을 넣을지가 아니라 무엇을 버릴지의 문제

RAG 파이프라인을 붙이고도 답변 품질이 들쭉날쭉했던 이유는 검색이 아니라 컨텍스트 구성에 있었습니다. 토큰을 예산으로 보고 도구 정의·대화 히스토리·검색 결과를 재배분한 과정을 정리했습니다.

커스텀 에러 포맷을 RFC 9457 ProblemDetail로 표준화하며 고민한 것들

code·message로 만든 커스텀 에러 응답을 Spring의 ProblemDetail(RFC 9457) 표준으로 옮기면서, 클라이언트 호환과 확장 필드 설계를 어떻게 정리했는지 기록했습니다.

Spring AI Tool Calling(@Tool)로 LLM이 사내 API를 직접 호출하게 만든 과정

@Tool 어노테이션으로 Java 메서드를 LLM이 호출 가능한 도구로 등록해, LLM이 사내 API와 DB를 직접 조회하도록 만든 함수 호출(Function Calling) 구현 과정을 예제 기반으로 정리했습니다.

Java 25 StructuredTaskScope로 여러 API 병렬 호출을 하나의 작업 단위로 묶기

Java 25 구조적 동시성(JEP 505, 5차 프리뷰)의 StructuredTaskScope와 Joiner API를 직접 예제로 돌려보며, 여러 외부 API 병렬 호출의 에러 전파·취소·관측성을 개선한 과정을 정리합니다.

Spring Boot 4 AOT Repositories로 앱 시작 시간 줄이기 — 쿼리 파싱을 빌드 타임에

Spring Data JPA 4.0의 AOT 리포지토리가 쿼리 메서드를 빌드 타임에 미리 만들어 시작 시 리플렉션 파싱을 없애는 원리를, 공식 문서와 예제를 직접 돌려보며 정리했습니다.

세상에 필요한 서비스를 만들고쉽고 편리한 경험에 가치를 더합니다.