반응형 분류 전체보기61 AI가 만든 JSON이 계속 퇴짜맞을 때: LLM 호출을 75% 줄인 세 가지 처방 LLM 프로덕트 엔지니어링 AI가 만든 JSON이 계속 퇴짜맞을 때: LLM 호출을 75% 줄인 세 가지 처방 PydanticAI 구조화 출력 · 검증-재시도 루프 최적화 실측 기록 핵심 요약 자연어를 복잡한 트레이딩 전략 JSON으로 바꿔주는 AI 기능이, 간단한 요청 하나에 131초 · LLM 호출 8회를 쓰고 있었다. 범인은 모델이 아니라 검증 실패 → 전체 재생성(retry) 루프였다. 처방 세 가지: ① 프롬프트에 완전한 동작 예제 JSON(규칙 목록 10줄보다 효과적) ② 흔한 파라미터는 quick reference로 인라인(불필요한 도구 호출 제거) ③ 흔한 실수는 검증 전에 코드로 수리. 결과: LLM 호출 8회 → 2~3회, 토큰 66K → 13~26K.. 2026. 8. 23. GitHub Actions 러너로 VPS 사양 재는 법: 36% 편차와 측정 함정 이미지 편집 엔진 GitHub Actions 러너로 VPS 사양 재는 법: 36% 편차와 측정 함정 분모 오염, 재본 적 없는 구간, 그리고 성공을 실패로 표시하는 신호 핵심 요약 서버를 사기 전에 사양을 정하려면 배포 아키텍처에서 재야 한다. CI 러너를 쓰면 돈을 안 들이고 상대 비교를 얻을 수 있지만, 절대 시간은 못 믿는다. 같은 코드가 8,004ms와 10,927ms로 나왔다(36% 차이). 한 번만 쟀다면 최적화 효과와 러너 상태를 구분하지 못했을 것이다. 동시성 배율이 한 번 1.30배로 튀었다. 그것만 보면 "병렬 처리가 이득"이라는 정반대 결론이 나온다. 네 번 중 세 번은 1.00배였다. 더 위험한 건 편차가 아니라 재고 있다고 믿었지만 안 재고.. 2026. 8. 9. 병목은 OCR이 아니었다: 요청의 53%를 쓰던 폰트 추론 2.2배 줄이기 이미지 편집 엔진 병목은 OCR이 아니었다: 요청의 53%를 쓰던 폰트 추론 2.2배 줄이기 탐색 공간 축소 · 계산 시점 이동 · 배열 연산화 세 단계 실측 기록 핵심 요약 이미지에서 글자를 뽑아 편집 가능한 텍스트로 만드는 서비스에서, 병목은 OCR이 아니었다. 폰트 스타일 추론이 요청의 53%(16,369ms 중 8,676ms)로 OCR 추론(6,468ms)보다 컸다. 이 단계는 규칙 기반이 아니라 후보 폰트를 실제로 렌더해서 원본 픽셀과 대조하는 완전탐색이다. 비용은 전부 "크기" 축에 있었고 "폰트 후보" 축은 평평했다 — 측정 전에는 반대로 짐작했다. 세 단계로 줄였다: ① 크기 탐색을 성긴 훑기 + 국소 정밀화로(2.65배) ② 추론 시점을 감지 → 사용자.. 2026. 8. 9. x86에 배포하고 나서야 보인 결함 둘: 추론 런타임과 Docker WORKDIR 이미지 편집 엔진 x86에 배포하고 나서야 보인 결함 둘: 추론 런타임과 Docker WORKDIR 빌드 성공을 배포 가능으로 세던 검증 커버리지, 그리고 CI 보강 핵심 요약 OCR·인페인팅을 돌리는 이미지 처리 서비스를 배포하기 직전, 하루에 배포를 완전히 막는 결함 두 개를 찾았다. 둘 다 유닛 테스트·타입체크·빌드를 전부 통과한 상태였다. ① 추론 백엔드가 x86에서 실행 자체가 불가능했다. 개발기는 arm64 맥이라 해당 코드 경로에 닿은 적이 없었다. 기본 설정 그대로 배포하면 모든 업로드가 실패한다. ② 프로덕션 웹 컨테이너가 매 부팅마다 즉시 종료됐다. 이미지 빌드는 성공했고, 아무도 그 컨테이너를 켜 본 적이 없었을 뿐이다. 공통 원인은 하나다 —.. 2026. 8. 9. 이전 1 2 3 4 5 ··· 16 다음 반응형
