한 줄 요약!쿼리 최적화 → 캐싱 → CDN 교체까지, K6 부하 테스트로 검증한 성능 개선 여정 결과 미리 보기지표BeforeAfter개선율p50588 ms30ms96.5% ↓p95725 ms45ms93.7% ↓p99883 ms94ms89.3% ↓(Before/After 정수 기준으로 표시, 개선율은 원본 측정값 기준 계산하고 소수점 둘째 자리에서 반올림) RunPartner 베타를 운영한 지 1주일 차에 피드백이 들어왔습니다. 크루 페이지가 묘하게 느려요 바로 API 응답 시간을 확인했습니다. 문득 이런 생각이 들었습니다.느리다는 건 알겠는 데 얼마나 빨라야 쾌적하다고 느낄까요? 목표는 p95 ≤ 100ms로 설정했습니다. 이 기준은 Nielsen과 Google RAIL이 제시하는 사용자 체..
이전 글에선 LLM으로 러닝 앱 스크린샷에서 러닝 데이터 추출을 다루었습니다. 글을 공유하자 질문이 들어왔습니다.LLM은 완벽할 수 없을까요?규모가 커졌을 때 실패 건수가 0이라고 장담할 수 있을까요?완벽성에 어디까지 집착하고, 어디까지 타협할 수 있을까요? 이번 글은 이 질문에 대한 답입니다. 그리고 답에서 그치지 않고, 실제로 SLO를 정의하고 모니터링을 구축했습니다. 이 기준은 앞으로 이 프로젝트를 운영하는 기준이 될 것입니다. LLM은 구조적으로 완벽할 수 없다 OpenAI는 다음과 같이 설명합니다. 언어 모델의 기능이 점점 향상하고 있지만 완벽하게 해결하기 어려운 과제 한 가지가 여전히 존재합니다. 바로 환각입니다. 언어 모델 환각이 표준 훈련 및 평가 절차가 불확실성을 인정하는 것보다 추..
들어가며러닝 앱 스크린샷에서 페이스를 추출해야 합니다. 간단해 보이지만, 문제가 있습니다. 같은 "페이스"인데 표기가 다릅니다. 한쪽은 04'57" /km, 다른 쪽은 7:02 /km. 레이아웃도, 라벨 위치도, 숫자 포맷도 전부 다릅니다. 사람은 둘 다 보고 바로 페이스를 찾습니다. OCR은 텍스트만 추출할 뿐, 어떤 숫자가 페이스인지는 모릅니다. 러닝 크루 인증 서비스를 만들면서 이 문제를 만났고, 전통적인 OCR 대신 LLM 으로 해결했습니다. Haiku에서 Sonnet으로 모델을 바꾸며 정확도를 60%에서 100%로 끌어올린 과정입니다. 문제 정의: 왜 전통적인 OCR로 부족했나 도입부에서 포맷 차이를 봤습니다. 문제는 더 있습니다. 1. pace vs duration 구분"38:25"와 "0..
세상에 원래 그런 건 없습니다 책 "일의 감각"에서 가장 오래 마음에 남은 문장입니다. 왜를 묻는 것하지 않을 것을 정하는 것아무도 묻지 않은 질문에 먼저 답하는 것 러닝 크루를 위한 서비스를 만들며 이 세 가지를 직접 경험했습니다. 러닝 크루에서 활동하며 두 가지 불편함을 발견했습니다. 운영자는 매일 수십 장의 인증 사진을 눈으로 확인하고 수작업으로 기록했고, 크루원들은 본인이 얼마나 잘하고 있는지 확인하고 싶은 니즈가 있었습니다. 이 문제를 직접 해결하기 위해 'Run Partner'를 설계하고 개발하기 시작했습니다. 기획자도 요구사항 문서도 없이, 제가 정의한 문제를 제가 푸는 프로젝트입니다. 첫 번째 질문: "왜 느린가?"랭킹 조회 API의 응답 시간이 499ms였습니다. v1: 상관 서브쿼..
들어가며 러닝 크루 프로젝트에서 더블클릭으로 중복 회원가입이 발생한 적이 있다. 사용자가 가입 버튼을 두 번 눌렀을 뿐인데 동일한 계정이 두 개 생겼다. 원인은 단순했다. POST 요청은 원래 멱등하지 않고, 사용자는 언제든 여러 번 누를 수 있다. 그때 배운 교훈은 명확했다. 중복은 반드시 온다. 이번 러닝 인증 시스템을 설계할 때는 이 전제를 출발점으로 삼았다. 멱등성의 정의: "의도"를 식별하는 것 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질 사전적 정의는 이렇지만, 우리 시스템, 특히 API 레이어에서 멱등성은 클라이언트의 의도를 식별하는 것으로 재정의했다 가장 쉬운 예로 온라인 결제를 생각해보자. 네트워크 지연으로 결제하기 버튼을 실수로 두 번 눌렀다고 해서 돈이 두 번 빠져나가면 ..
목차시작하며 : “결제 버튼을 두 번 눌렀습니다만?”Why 멱등성, 선택이 아니라 필수일까?사례로 보는 멱등성 보장 전략Idempotency-Key로 안전한 API 만들기같은 키, 다른 바디 어떻게 막을까?멱등키를 이용하면, 사용자가 여러 번 눌러도 한 번만 결제가 되나요?한 줄 정리 시작하며 : “결제 버튼을 두 번 눌렀습니다만?”“결제가 두 번 승인 됐어요”여러 번 요청을 생각보다 많이 발생할 수 있는 일입니다.네트워크는 언제든 불안정할 수 있고, 사용자는 재시도를 할 수 있기 때문입니다.멱등성은 이런 예측 불가능한 실패 속에서 시스템의 신뢰성과 데이터 일관성을 지키는 핵심 개념입니다. Why 멱등성, 선택이 아니라 필수일까?멱등성이 없다면, 단순한 네트워크 재시도만으로도 시스템에 문제가 생깁니다..
