Jeonggil - 쓰리뷰 기술블로그

200 OK, 텅 빈 body — Starlette Race Condition 장애 분석기

발생일: 2026-04-23 / 해결일: 2026-04-27 영향 범위: report-dev.machine365.ai 전체 API 들어가며 API가 200 OK를 반환하는데 body가 비어있다. 프론트엔드에는 아무것도 안 뜨고, Swagger UI(/docs)도 빈 화면. 그런데 로컬에서 돌리면 멀쩡하다. 배경은 이랬다. 미터링(Metering) 기능을 만들면서 API 호출 로그를 수집할 미들웨어를 작성했다. Spring Boot 백엔드에 먼저 적용하고, Python

쉬어가며2

개발 일만 하다 보면 눈앞의 코드에만 집중하게 된다. 오늘은 조금 다른 이야기를 해볼까 한다. 바로 주식에 대한 이야기다. 왜 주식을 해야 하는가? 주식을 시작하면 자연스럽게 질문이 많아진다. "왜 이 회사는 영업이익이 늘었는데 주가는 떨어졌을까?" "PER이 낮은데 왜 아무도 사지 않을까?" 재무제표를 읽고, 뉴스를 찾아보고, 시장의 흐름을 추적하다 보면 세상을 보는

쉬어가며

개발 일만 하다 보면 때로는 잠시 멈춰서 주변을 둘러보는 것도 중요하다. 오늘은 오래전에 다녔던 병원에서의 일을 가볍게 풀어볼까 한다. 고객이 병원에 방문하고, 그것이 수익으로 이어지기까지. 그 안에는 생각보다 훨씬 많은 전략과 기술, 그리고 사람들의 노력이 숨어있다. 1. 들어가며 오래전 다녔던 한 병원에서의 일이다. 당시 나는 "의료 IT"라는 낯선 도메인에

3view

[시리즈 2편] 실무로 배우는 메시지 큐 - RabbitMQ

들어가며 [시리즈1]에서는 프로세스 내부 메시지 큐를 다뤘습니다. 이번엔 네트워크 메시지 큐인 RabbitMQ를 다룹니다. RabbitMQ 공식 문서나 기술 블로그는 많지만, 실무에서 어떻게 사용하는지에 대한 글은 의외로 적습니다. "Producer가 뭐고 Consumer가 뭔지는 알겠는데, 그래서 실제로는 어떻게 쓰는데?" 이번 글에서는 우리 MES 시스템에서 RabbitMQ를 어떻게 활용하고 있는지 실제 코드와 함께 공유합니다. 우리

3view

[시리즈 1편] 실무로 배우는 메시지 큐 - Windows Message Loop

들어가며 이 글은 "실무로 배우는 메시지 큐" 시리즈의 첫 번째 글입니다. 실무에서 발견한 문제를 해결하는 과정에서, IME 입력 문제와 해결 과정을 공유합니다. 메시지 큐는 RabbitMQ, Kafka 같은 네트워크 레벨만 있는 게 아닙니다. 우리가 매일 쓰는 Windows 애플리케이션도 메시지 큐 기반으로 동작합니다. * 시리즈1 (이 글): 프로세스 내부의 메시지 큐 - Windows

3view

[시리즈 2편] 그림으로 풀어낸 SaaS 알림 시스템

이 글은 1편 - 그림으로 풀어낸 SaaS 알림 시스템의 후속편입니다. 들어가며 1편에서는 설비 연속 OFF 알림 기능의 핵심 로직과 어떤식으로 해결했는지 그림으로 알아봤습니다. 이번 글에서는 실무에서 마주한 진짜 고민들을 공유합니다: * 왜 3개의 새로운 테이블이 필요했나? * 어떻게 확장 가능한 구조를 만들었나? * SMS 14원짜리 알림이 왜 무서운가? * 운영 레벨로 나가기까지 무엇을 준비했나?

3view

[시리즈 1편] 그림으로 풀어낸 SaaS 알림 시스템

들어가며 제조업 IoT 플랫폼에서 N대 이상의 설비를 실시간으로 모니터링하고, 설비가 연속으로 꺼졌을 때 담당자에게 즉시 알림을 보내는 기능을 개발하게 되었습니다. 데이터는 실시간으로 쌓이지만, 설비이상을 체크하는 스케줄러 주기는 1분으로 설정하였습니다. 시스템 아키텍처 기존 인프라와 Push 기능은 이미 구축되어 있었습니다. 저는 중간에 들어가는 Alert Scheduler만 구현하면 되는 상황이었습니다. ┌──────────────────────────────────────────────────────────┐ │ 설비 IoT 센서 (실시간)

3view

풀스택으로 구현하는 전력 사용량 비교 대시보드: BFF 패턴부터 자동 Fallback UI까지

전력 사용량 비교 서비스를 구현하며 배운 BFF 패턴, 비동기 병렬 처리, 그리고 사용자 경험 설계 이야기 들어가며 전력 사용량 비교 분석 기능을 개발하면서 흥미로운 고민에 직면했습니다. 클라이언트에게 4가지 서로 다른 데이터를 제공해야 하는데, 각각을 독립적인 API로 개발할지, 아니면 하나의 API로 통합해서 제공할지 결정해야 했습니다. API 설계 방향 결론부터 말하자면, 단일