반응형 이미지편집엔진3 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 다음 반응형
