← 전체 글
#concurrency
글 3개
-
코덱스 말고 그록 다회 호출을 택한 실험 기록
같은 글감으로 두 엔진을 나란히 돌렸습니다. 정독 평가에서 이긴 쪽은 코덱스였지만, 결국 코드에서 지웠습니다. 일정 분량 이상은 아무리 지시해도 안 나오는 문제를 해소하기 위해 모델 교체는 하지 않고, 여러번 호출하는 쪽으로 방향을 잡았습니다. 짧게 여러 번 부르는 구조로 가자, 호출 속도가 판단을 결정했습니다. 모자랐던 그록의 답변 품질은 출처를 4,000자까지 넣고 숫자를 코드로 대조해 메웠습니다.
-
[메신저 부하 테스트 3편] 요청 경로의 FCM은 큐로, 삼키던 실패는 Sentry로 — 메시지 전송 핸들러 정리기
메신저 부하 테스트 실전기 3편: 메시지 전송 핸들러에 섞여 있던 FCM 푸시를 전용 워커 큐로 분리하고, 빈 catch에 삼켜지던 실패를 Sentry로 관측 가능하게 만든 이야기. 외부 I/O 격리와 에러 로그 처리, 두 축을 함께 다룹니다.
-
[메신저 부하 테스트 2편] AI가 생성한 코드에 deadlock이 숨어 있었다 — `unreadCount`를 `lastReadAt`으로 교체한 이야기
부하 테스트 시작 9분 만에 HTTP 오류율 42.8%, 목표 TPS의 12%. 범인은 AI 보조 코딩 중 무심코 작성한 단 한 줄의 updateMany였습니다.
