김영식KIM YOUNGSIK

화면은 최신값만 지연 없이 필요해서 Pub/Sub을, 알람 평가·이력 적재는 값이 유실되면 안 되기 때문에 Stream을 씁니다. deliveryReliability 값(realtime / durable / both)으로 구독마다 채널을 선택하게 해서, 소비자 특성에 안 맞는 채널을 강제하지 않도록 했습니다.
→ 자세히 읽기

500ms는 트랜잭션 수 대비 화면 체감 개선이 미미했고, 5초는 운영자가 느리다고 느끼는 지연이었습니다. 가장 느린 프로토콜(BACnet)의 폴링 사이클을 온전히 담는 최소 단위가 1.5초였고, 실측 p99 이벤트 루프 지연(38.6ms)에도 여유가 남는 값이었습니다.
→ 자세히 읽기

구독 설정 변경 빈도가 데이터 유입 빈도보다 압도적으로 낮아서, 최대 30초 지연은 감내할 수 있다고 판단했습니다. 캐시 갱신 자체가 실패하면 예외만 로깅하고 기존 캐시를 그대로 유지해, 파이프라인 전체가 멈추지 않도록 했습니다.
→ 자세히 읽기

서버가 받은 순서를 신뢰하지 않고, 디바이스가 값을 측정한 시각을 기준으로 최신값을 판정합니다. 화면용 미러 테이블은 최신값 덮어쓰기로 충분하다고 보고 별도 순서 보장 장치를 두지 않았고, 원본 이력은 전량 적재해 필요하면 타임스탬프로 재정렬할 수 있습니다.
→ 자세히 읽기

배포와 장애가 서로 전이되지 않게 됐습니다. poller만 재시작해도 API가 끊기지 않고, API를 배포해도 수집이 멈추지 않아 조회 시점 기준 11.6일 연속 무중단 가동을 유지할 수 있었습니다.
→ 자세히 읽기

장애 격리(한 서비스의 쓰기 부하가 다른 서비스 커넥션 풀에 영향을 주지 않아야 함)와 배포 독립성(서비스마다 마이그레이션 시점이 다름) 때문입니다. 스키마만 나누면 커넥션 풀과 락 경쟁은 여전히 공유되어 리소스 격리가 되지 않습니다.
→ 자세히 읽기

순찰은 회차·구역별로 담당자 1인이 배정되는 운영 구조라 동시 수정 자체가 발생하지 않도록 이미 배제돼 있었습니다. 그래서 복잡한 병합 로직 대신, 작성 시각 기준 업로드와 회차·포인트 단위 고유 키로 중복만 막는 단순한 규칙을 선택했습니다.
→ 자세히 읽기

회사에서는 백엔드·서버 운영이 중심이고, 제가 만든 API가 실제로 어떻게 소비되는지(런덤메이트) 그리고 제가 만든 코드가 안전한지(바이브쉴드)를 직접 확인해보고 싶어서 사이드 프로젝트로 채웠습니다. 두 경험 모두 결국 백엔드를 더 잘하기 위한 확장이라고 생각합니다.
→ 자세히 읽기