검색 결과가 없습니다
제목, 태그, 카테고리로 검색
메이퇀 기술 블로그가 정리한 단위 테스트의 세 쓰임새를 옮기고 그중 요구사항을 테스트로 건네는 방식에서 드는 비용과 테스트가 틀렸을 때의 행동을 b-studio에서 36회 돌려 쟀습니다. 맞는 테스트를 건넨 9회의 토큰은 말만 준 9회의 0.96배로 실행 전에 적어 둔 범위 안이었고 값 하나가 요청과 다른 테스트를 건넨 18회에서는 에이전트가 모두 테스트를 따랐습니다. 그래서 건넨 테스트 옆에 두는 확인 하나를 적었습니다.
AI 코더에게 구현을 맡기고 끝났다는 신호를 화면의 완료 문자열로 받았더니 두 번 연속 거짓으로 통과했습니다. 한 번은 자기 명령어를, 한 번은 지난 실행의 흔적을 읽었습니다. 표식을 고치다가 완료 신호를 화면에서 파일로 옮긴 과정입니다.
코드는 대부분 AI가 쓰고 저는 설계를 승인하고 결과를 확인합니다. 이렇게 일하면서 굳어진 방식 여섯 가지를 적었습니다. 역할을 먼저 나눈 이유와 한 묶음을 한 코더에게 끝까지 맡기는 이유, 끝났다와 맞았다를 따로 확인하는 방법을 다룹니다. b-studio에서 반복 실행으로 재 본 결과로 어디에 쓰면 이득인지도 함께 적었습니다.
b-studio는 요청을 말하면 코딩 에이전트가 프론트엔드와 백엔드 코드를 쓰고, 그 코드를 격리된 샌드박스에서 실제 서버로 띄워 검증까지 하는 AI 앱 빌더다. 에이전트가 만든 코드를 어떻게 믿게 했는지와 직접 실행하는 방법을 다룬다.
처음에는 검증 충분성을 기계가 결정적으로 판정하게 만들려 했다. 그런데 사람이 하던 그 판단은 원래 확률적이었다. 그래서 갈라야 할 것은 무엇을 고정하고 무엇을 맡길 것인가였다. 고정할 자리에는 경계와 검사를 두고, 맡길 자리에는 판단할 재료를 준다. 다만 자기를 심판하는 자리 하나는 기계가 붙잡아야 한다.
결제 운영 자동화 세 곳에서 모델을 켜고 끈 기준. 장애 로그 진단과 운영자용 요약은 켰고 대사 원인 분류는 껐다. 그 과정에서 평가 장치도 세 번 틀렸고, 마지막 한 건은 모델이 아니라 제 라벨이 틀렸을 가능성으로 남겼다.
규칙이 설명하지 못한 대사 예외에 모델을 붙였지만, 실제 잔여 분포에서 규칙 분류기와 같은 답을 냈다. 개발 표본의 91~100%만 보고 자동화를 켜지 않고, 홀드아웃에서 개선이 0임을 확인한 뒤 기본값을 규칙으로 유지한 이유를 정리한다.
결제 상담 초안을 자동 채점하는 루브릭이 평균 4.97/5점을 줬지만, 사람이 블라인드로 쓴 답과 비교하니 편집 거리 중앙값이 45.6%였다. 루브릭을 조이면 정상 문장을 놓치고, 고객 영향을 요구하면 모델이 모르는 것까지 단언했고, 다른 계열 심판도 틀렸다.
모델을 붙이기 전에 포트와 숫자 검증기부터 만들었다. 실제 데이터를 넣자 검증기가 분류기가 계산한 진짜 270원을 출처에 없다며 반려했고, 고친 뒤에도 반복 실행에서만 드러나는 결함이 둘 더 나왔다.
이미 쓰던 Claude 구독을 폰에서도 쓰고 싶어서 만든 봇이다. API 키로 따로 과금하는 대신 Claude Code 구독 인증(claude -p)을 그대로 호출하고, 메시지를 보내면 작업 과정을 실시간으로 흘려줍니다. 디스코드 봇을 이미 돌리고 있으면서도 이번엔 텔레그램을 고른 이유, 코딩 모드에서 확인 없이 파일을 고치는 대신 넣은 취소 장치, 같은 서버의 다른 서비스를 못 건드리게 막은 격리까지 정리했다.
Lucene BM25 검색 결과 Top-5 문서를 LLM 컨텍스트에 주입하는 RAG(Retrieval-Augmented Generation) 파이프라인을 구축한다. Spring AI 2.0 + Gemini 2.0 Flash로 SSE 스트리밍 답변을 생성하고, 인라인 출처 배지를 파싱하여 게시글 링크로 연결한다. 할루시네이션 방지(문서 기반 답변 제한 + 인용 강제), AI 요약 트리거 조건(네비게이션 의도 스킵), Redis Token Bucket rate limiting(10 RPM 전역), 동일 쿼리 캐싱(TTL 30분, LLM 비용 40-60% 절감), Grafana 7패널 대시보드(RPM, 응답시간, 토큰, 피드백, 비용 추정)까지 포함한다. BM25가 이 프로젝트에서 Dense Retrieval보다 적합한 근거와, Hybrid Retrieval 전환 로드맵도 정리한다.
LLM 워크플로우를 실행하고, 실패를 분석하고, 규칙을 자동 생성하고, 회귀 테스트까지 하나의 루프로 연결하는 평가 엔진.
BM25 수동 가중치(title:3, content:1)의 한계를 Learning to Rank(LTR)로 극복한다. 카테고리 28개 자동 분류(키워드 기반, 정확도 83%) → SortedSetDocValuesFacetCounts 네이티브 Facet 전환 → 태그 216만 건 인덱싱을 1회 재색인으로 통합 반영한다. LLM-as-a-Judge(Gemini)로 학습 데이터 900쌍을 생성하고(1차 실패 98% → 5초 딜레이+지수 백오프로 해결), XGBoost LambdaMART 14개 피처로 학습하여 NDCG@10을 0.6910 → 0.7387(+4.8%p) 개선한다. XGBoost4J ARM64 네이티브 추론, Rescorer Top-200 재랭킹, RefreshListener 기반 FacetState 캐싱, MultiCollectorManager 단일 패스 수집까지 구현하지만, 2코어 ARM Free Tier에서 LTR ON 시 CPU 포화(72배 악화)를 k6로 실측하여 LTR_ENABLED=false로 비활성화한다.