Dev 허브

최근 IBM이 Apache 2.0 라이선스로 전격 공개한 추론형 오픈소스 모델 Granite 4.2 소식 들으셨나요? 이번 버전은 성능도 훌륭하지만, Ollama나 vLLM 등에서 enable_thinking과 reasoning_effort 파라미터를 통해 모델이 얼마나 깊게 생각하고 답변할지 제어할 수 있는 점이 백엔드 개발자 입장에서 아주 재밌는 요소입니다.

로컬 AI 에이전트 백엔드를 구축할 때 이 생각 조절 파라미터를 API 단에서 깔끔하게 핸들링하려면 역시 강력한 스키마 검증이 필수입니다. Fastify 진영의 대세인 @fastify/type-provider-typebox를 활용하면 프론트엔드나 에이전트 엔진으로부터 들어오는 요청을 입구에서 정확하게 제어할 수 있습니다. 간단한 연동 스키마 뼈대를 짜봤어요.

요즘 Fastify 백엔드에서 LLM이나 AI 에이전트 호출 모니터링을 어떻게 설계하고 계시나요? 혹시 예전에 쓰던 @opentelemetry/instrumentation-fastify 패키지를 아직 들고 계신다면 얼른 걷어내시는 게 좋습니다. 해당 패키지는 공식적으로 지원이 중단되었거든요.

이제는 Fastify 코어가 관리하는 @fastify/otel 플러그인을 사용하는 것이 표준입니다 [2]. 이 플러그인은 AsyncLocalStorage를 사용해서 트레이싱 컨텍스트를 깔끔하게 관리해 줍니다 [2]. 여기에 OpenTelemetry의 GenAI 시맨틱 컨벤션을 결합하면 모델명이나 토큰 사용량 같은 정보들을 표준 규격으로 예쁘게 수집할 수 있습니다 [2].

한 가지 실무 팁을 드리자면, 트래픽이 몰리는 고성능 API 서버에서는 전역 혹은 라우터별로 instrumentHooks: false 옵션을 주는 것을 추천해 드려요 [2]. 굳이 모든 라이프사이클 훅마다 스팬을 생성하면 불필요한 성능 오버헤드가 생길 수 있거든요 [2]. 꼭 필요한 LLM 비즈니스 로직과 데이터베이스 호출만 콕 집어서 추적하는 편이 훨씬 효율적입니다 ㅎㅎ