이전 글인 Spring AI Tool Calling 설계: Tool과 DDD 계층의 책임 분리에서는 Tool을 LLM 요청을 Application UseCase로 변환하는 Adapter로 정리했다. 이 결론은 개별 Tool Wrapper와 Application UseCase의 경계를 설명하는 데 여전히 유효하다. 이번에는 질문의 범위를 Tool 하나에...

I. Shieldstral, ko-pii-public-v1 LLM 가드레일 프레임워크를 개발하면서 Shieldstral, ko-pii-public-v1 모델을 활용 중이었다. Shieldstral은 가드레일 모델로써 유해성 판정이나 업무 범위 판정 등에 활용했으며, ko-pii-public-v1는 마스킹에 활용했다. 1. Shieldstral 1....

분산 환경에서 식별자를 생성할 때 UUID는 편리한 선택지다. 별도의 중앙 발급기 없이도 각 애플리케이션에서 충돌 가능성이 매우 낮은 식별자를 만들 수 있기 때문이다. 가장 익숙한 UUIDv4는 대부분의 비트를 무작위 값으로 채운다. 고유성 측면에서는 유리하지만, 연속해서 생성한 값도 서로 멀리 떨어져 있어 생성 시점을 기준으로 정렬할 수 없다. 데...

검색형 Assistant의 모델을 교체할 때, 보통은 최종 답변만 비교하기 쉽다. 하지만 같은 정답을 내더라도 한 모델은 검색 결과 하나만 보고 답하고, 다른 모델은 추가 문맥과 예외 조건까지 확인한 뒤 답할 수 있다. 이번에는 gemini-3.5-flash와 gemini-3.1-flash-lite를 대상으로 다음 가정을 확인했다. gemin...

LLM API는 기본적으로 이전 요청을 기억하지 않는다. 같은 채팅 화면에서 연속으로 질문하더라도, 다음 요청에 과거 메시지를 포함하지 않으면 모델은 앞선 대화를 알 수 없다. 멀티턴 대화를 구현하려면 대화 내용을 저장하고, 다음 요청의 Prompt에 다시 포함하는 과정이 필요하다. Spring AI에서는 ChatMemory, ChatMemoryRe...

Spring AI를 활용하면 @Tool 메서드를 ChatClient에 등록해 LLM이 애플리케이션의 기능을 호출하게 만들 수 있다. 하지만 @Tool은 어느 계층의 책임인지 바로 드러나지 않아, 기존 Application Service나 AI 설정 클래스에 함께 두기 쉽다. 문제는 Tool이 늘어나면서 발생한다. LLM에 어떤 기능을 노출할지 결정해...

프로젝트 팀원에게 했던 PR 리뷰 중, 기록해두면 좋을 내용을 정리한 글이다. 실제 코드 리뷰를 통해 발견한 문제점과 제시했던 해결 방안을 정리했다. I. BoundedContext 독립성 문제 // content/content-api/build.gradle dependencies { implementation(project(":core...

개요 주요 아키텍처 패턴 멀티 모듈 Gradle 프로젝트 헥사고날 아키텍처 (Ports & Adapters) DDD (Domain-Driven Design) 원칙 적용 마이크로서비스 아키텍처 기반 모듈 설계 계층 분리: Presentation (API) → Application → Domain ← Infrastructure...

I. 문제 상황: Presentation 모듈의 정체성 혼란 1. 기존 구조 프로젝트 초기 구조는 다음과 같았다. connectors-backend/ ├── core/ ├── setting/ │ ├── cache/ │ ├── database/ │ ├── storage/ │ └── external/ ├── presentation/ ...

I. 문제 상황 Course(강의) 엔티티와 Skill(기술) 엔티티는 다대다 관계로 연결되어 있다. 하나의 Course는 여러 Skill을 가질 수 있고, 각 Skill도 여러 Course에 연결될 수 있다. 이 관계는 course_skill이라는 매핑 테이블로 관리된다. course 테이블 course_skill 테이블 ...