예약 시스템 개편기: 우리는 왜 '예약 레고'를 만들었나
비브로스 병원 예약 시스템이 감기 10분 / 예방접종 5분 / 초음파 50분 등 가변 진료 시간을 고정 슬롯 + 카운팅 구조로 처리해 race condition 과 디버깅 불가 문제가 있었다.
비브로스 병원 예약 시스템이 감기 10분 / 예방접종 5분 / 초음파 50분 등 가변 진료 시간을 고정 슬롯 + 카운팅 구조로 처리해 race condition 과 디버깅 불가 문제가 있었다.
자연어 기반 내부 데이터 조회 서비스의 ChatAgent가 복잡한 다단계 작업에서 포맷 오류·토큰 낭비·유지보수 어려움을 초래함.
여러 서비스를 단일 Jira 보드로 관리해 서비스별 DORA Metrics 집계가 어렵고, Change Failure Rate·복구 시간 쿼리가 실제 운영 맥락과 맞지 않음.
EKS 1.29가 2025년 3월 표준 지원 종료. 기존 Blue-Green + Route53 방식은 DNS 전파 지연으로 트래픽이 구 클러스터로 잘못 라우팅되는 문제가 있었음.
똑닥닷컴의 네이버 월간 노출 수가 2만 건에 불과해 잠재 사용자 유입이 낮음.
테스트 코드를 어떻게 구조화하고, 어떤 패턴을 써야 하는지 팀 내 합의가 없어 유지보수 비용이 높아짐.
멤버십 정기 결제 API와 수단 변경 이벤트가 동시에 MongoDB 컬렉션에 접근해 Write Conflict로 인한 이중 결제가 발생했다.
try-catch 중첩과 Promise의 unknown 에러 타입으로 인해 에러 처리가 예측 불가능하고 코드 흐름이 복잡해진다.
마케팅 이벤트나 연휴 같은 비정기 상황에서 크론 작업을 DevOps가 수작업으로 생성·배포해야 해 운영 비효율이 컸다.
Backend와 Frontend가 동일 API에 대해 별도 타입을 정의해 중복 작업과 타입 파편화, response 불일치가 발생했다.
레거시 로그 서버가 시계열 데이터를 일반 컬렉션에 저장해 시간 경과에 따른 조회 성능이 저하됐다.
기존 Cluster AutoScaler는 스파크성 트래픽에 대응하는 노드 프로비저닝이 느리고 인스턴스 타입 최적화가 어려워 비용 효율성이 낮았다.
Kubernetes 1.22 지원 종료를 앞두고 1.25로 업그레이드해야 하지만, 인플레이스 업데이트는 롤백이 불가능하고 3단계 마이너 버전 순차 업그레이드가 필요하다.
하이브리드 앱에서 웹뷰와 Android/iOS 네이티브 사이의 양방향 통신 구현 방식이 플랫폼마다 달라 개발 복잡도가 높고, Safari·Android 웹뷰별 크로스 브라우징 버그도 빈번하다.
고사용률 페이지를 웹뷰로 전환하면서 LCP·FCP·CLS 등 Core Web Vitals 관리가 필요해졌고, 자체 Lighthouse 모니터링 시스템의 측정값이 가변적이어서 정확한 성능 기준 수립이 어렵다.
기이한 이름·중복 코드·긴 함수·전역 데이터 등 코드 악취가 쌓이면 이해도와 유지보수성이 떨어지고, 리팩터링 시점과 방법을 체계적으로 알기 어렵다.
웹 애니메이션에서 width 같은 레이아웃 속성을 변경하면 Reflow→Repaint→Composite 전 단계가 반복 실행되어 성능이 저하된다.
앱 설치 여부에 관계없이 특정 콘텐츠로 사용자를 유도하는 Dynamic Link를 서버에서 생성해야 하며, API 일일 20만 회 제한과 중복 생성을 방지해야 한다.
함수형 프로그래밍의 개념은 알지만 실제 JavaScript/TypeScript 코드에 어떻게 적용해야 하는지, 그리고 OOP와 어떻게 공존할 수 있는지 가이드가 필요하다.