이전에 Jev라는 새로운 LLM 모델이 나왔다고 해서 알아보고 글을 작성했습니다.진행 중인 사이드 프로젝트에서 유튜브 댓글 수집 후 해당 댓글이 어떤 반응인지를 분류하는 기능을 구현했는데 해당 기능은 수집된 댓글을 한 번에 Gemini API를 통해 분류를 요청하면 JSON 형태로 응답해 주는 기능이었습니다.여기에 Gemini 대신 Jev를 사용하면 성능이 개선될 것 같다는 생각에 Jev를 적용해 보고 성능이 얼마나 좋아지는지를 비교해 보겠습니다. 측정 방법측정은 간단하게 동일한 댓글 100개를 수집한 후 각각의 LLM 모델을 3회 호출 후 비교하는 방식으로 진행했습니다.Gemini는 3.5 Flash-Lite, Jev는 jev-1.13.0을 썼습니다.참고로 Gemini 3.5 Flash-Lite는 무료..

모든 모니터링 도구는 같은 EC2 인스턴스 안에 설치하고, 서로 로컬 통신만 하게 하였습니다. 공통 설치 패턴Exporter, Prometheus, Alertmanager는 모두 아래와 같은 패턴으로 설치했습니다./opt에 다운로드하고 압축 해제실행 전용 계정 생성실행 파일만 /usr/local/bin으로 복사, 소유권 변경설정 파일은 /etc/도구이름/, 데이터는 /var/lib/도구이름/ 에 저장systemd 서비스로 등록 파일 위치 정리위치설명/opt설치 및 압축을 푸는 작업 공간으로 사용/usr/local/bin직접 설치한 프로그램의 표준 위치로 경로 없이 실행 가능/etc/...리눅스 설정 파일의 표준 위치/var/lib/...실행 중 생기는 데이터의 표준 위치 전용 계정을 만드는 이유패턴을 ..

Jev는 TypeSafe AI가 2026년 9월 15일에 공개한 모델로 텍스트를 토큰 단위로 생성하는 기존 LLM과 달리 상태(state)와 질문(question)을 입력받아 확률, 신뢰도가 붙은 구조화된 답변을 반환하는 모델입니다.이렇게만 말하면 무슨 말인지 모르니 천천히 알아가 보겠습니다. 생성형 AI의 아쉬운 점지금까지의 생성형 AI는 사람이 읽기 좋은 자연스러운 답변을 만드는 데는 뛰어나지만, 소프트웨어 안에서 반복적으로 판단을 내려야 하는 자동화 작업에는 몇 가지 근본적인 한계가 있습니다. 속도와 비용: 답을 토큰 단위로 하나씩 순차 생성하다 보니, 단순히 "예/아니요"나 "이 중 하나 골라줘" 같은 판단 하나를 받기 위해서도 전체 응답을 다 생성할 때까지 기다려야 하고, 그만큼 비용도 커집니다..

시작하게 된 계기어느 날 새벽, 운영 중이던 서버가 원인 모르게 종료되었고 로그를 열어보니 이런 게 찍혀 있었습니다.[SpringContextShutdownHook] INFO ... Application availability stateReadinessState changed from ACCEPTING_TRAFFIC to REFUSING_TRAFFIC 애플리케이션이 스스로 종료 절차에 들어가면서 "이제 트래픽을 받지 않겠다"고 상태를 바꾼 로그였는데문제는 왜 종료됐는지 알 수 없었다는 것, 그리고 서버가 죽은 걸 한참 뒤에야 알았다는 것이었습니다. 문제의식을 느끼고 모니터링 시스템 구축이 필요하다라 생각했고, 최초 모니터링 요구사항으로 아래의 2가지를 구현하였습니다.서버가 비정상 상태가 되면 즉시 알림을..

self-invocation이란self-invocation은 한 객체 안에서 자기 자신의 다른 메서드를 호출하는 걸 의미합니다.평범한 자바코드에서는 아무 문제 없지만 Spring AOP 기반 기능(@Transactional, @Async, @Cacheable 등)을 쓸 때 내부에서 호출한 메서드에는 어노테이션이 동작하지 않기 때문에 문제가 발생합니다. @Servicepublic class UserService { private final UserRepository userRepository; public UserService(UserRepository userRepository) { this.userRepository = userRepository; } publi..

문제 상황이 글에서 데이터를 저장한 뒤, Gemini API로 분석하는 기능을 이벤트 기반으로 처리했습니다.이제 문제는 분석에 최소 1분의 시간이 걸린다는 것입니다. 사용자는 데이터 등록 버튼을 누르고 화면이 멈춘 채로 1분 이상의 시간을 기다려야 합니다. 로직상 에러는 없지만 사용자 입장에서 지금 로딩화면이 정상적으로 등록 중이라 멈춘 건지 아니면 무언가 에러가 발생해서 멈춘건지 알 수 없기 때문에 UX관점에서 보면 정말 좋지 않다고 할 수 있습니다. 생각해 보면 사용자가 이 시간을 기다릴 필요는 없습니다.데이터 등록 자체는 순식간에 끝나는 동작이고, 뒤이은 분석은 사용자의 입력이 끝났으니 별개의 작업으로 돌릴 수 있습니다.그래서 데이터 저장 작업이 끝나면 바로 사용자에게 응답하고 데이터 분석 작업은 ..