게임듀오
DEV팀 Platform Part Leader 2026.04 — 현재
DEV팀 Server Developer 2025.01 — 2026.03
2025.01 — 현재
모바일 게임 개발 및 퍼블리싱 회사. 6개 라이브 게임 환경 (12 브랜치 운영) 공통 백엔드 플랫폼 설계, 데이터 파이프라인 구축, 공통 패키지 체계 운영
주요 성과
DEV팀 Platform Part Leader
- Platform Part 신설로 작업 추적·점수 측정 기준 부재 — 7단계 워크플로우(BACKLOG→SIZE REVIEW→DONE), 4가지 작업 유형별 처리 방식, 상태 전환 검증 로직 및 티켓 템플릿 라이브러리 정립, 파트 신설 직후 즉시 가동 가능한 운영 체계 확립 — 작업 유형별 처리 기준·의사결정 체계 동시 수립
- Claude Code 활용으로 개발 소요 시간이 단축되었으나 기존 점수 기준이 AI 활용도 미반영 — 범위·복잡도·불확실성·협업·검증 5기준 사이즈 체계 + Claude Code 영역별 시간 차감 기준(테스트 ~80%, 패턴 복제 ~70%) 수립, 팀 합의 기반 AI 시간 차감 기준 수립으로 Claude Code 도입 전·후 공정한 성과 측정 체계 확립
- Claude Code 등 AI 에이전트 활용도 팀원별 격차 + 개인이 발견한 컨텍스트·노하우가 팀 전체에 전파되지 않아 동일한 시행착오 반복 — 개인 노하우 문서화 대신 Git 기반 공유 설정 자동화(config-as-code)를 채택 — 문서는 사람이 다시 읽어야 하지만 코드화된 설정은 AI 런타임에 직접 연동돼 자동 적용되기 때문. 팀 원칙·코딩 표준·도메인 지식·전문 에이전트·자동화 훅을 단일 git repo로 통합한 팀 공통 AI 개발 인프라 설계, git pull만으로 팀원 전원이 동일한 AI 세션 컨텍스트로 시작 — 개인 지식의 팀 자산화 및 AI 활용 격차 해소 (구축 약 2주 만에 397개 도메인 지식 누적)
DEV팀 Server Developer
- 마케팅 데이터 조회 비용 급증(전체 스캔 과금 구조) — 파티셔닝 튜닝 분석 후 Write IOPS 증가 문제로 기각, gRPC 기반 분산 읽기(Storage Read API) 전환, 비용 82% 절감(TB당 $6.25→$1.1)
- 배치 처리의 수집 기간 한계(60일) — 배치 일괄 처리 대비 EDA 기반 온디맨드 처리로 전환 — 피크 부하 분산 및 처리량 확장, 수집 범위 6배 확장(60일→360일), 처리 시간 2시간→5분 단축
- 7개 프로젝트 간 코드 중복과 컨벤션 불일치 — 수동 코드 동기화 대신 공통 NestJS 패키지 체계 도입 (유틸 10모듈 + 게임서버 Kit 자동 배포), 업그레이드 자동화로 배포 시간 3시간→15분 단축
- 3개 광고 플랫폼 데이터 분산에 따른 마케팅 조회 지연(18초) — 100개 컬럼 전체 스캔 회피를 위해 읽기 경로 정규화 + 인덱스 튜닝, 조회 성능 97% 개선(18초→0.5초)
- 게임 확률 공시 의무화 규제 리스크 — DynamicModule 기반 확률 패키지를 다중 게임에 통합 + CDK 기반 감사 로그 파이프라인, 통합 테스트 커버리지 94%+ 확보(12 suites, 115 tests)
프로젝트
실시간 게임 채팅 서버 (멀티테넌트)
2026.04 ~ 현재여러 라이브 게임이 공유하는 멀티테넌트 실시간 채팅 서버를 설계하고, 6,000 동시접속·18,000 RPS 목표 용량을 부하 측정으로 검증
- 여러 게임이 공유하는 채팅 인프라의 용량 산정 기준이 없어 서버 사이징·SLO 목표를 정할 수 없음 — 추측 기반 산정 대신 상용 게임 채팅 솔루션의 공식 rate limit·PCU 기준을 채택해 멀티테넌트 통합 서버 1대 frame 용량 산정식 수립, 6,000 동시접속(sustained)·18,000 RPS·버스트 90,000 RPS 목표 확정 및 분기 OKR 반영
- Redis Streams 기반 WAL이 6K msg/s 부하에서 싱글스레드 쓰기 병목(EngineCPU 99.9%, ack p95 767ms) — WAL 스트림을 4-shard 클러스터로 분산하고 엔트리를 native field로 compact(Lua 직렬화 제거) — 싱글스레드 Redis는 쓰기를 순차 처리해 수직 확장으로 병목 해소 불가, 수직 확장 대신 샤딩 채택, ack p95 767ms→6.6ms(약 116배 단축), WAL 적체 80,000→2,838건 해소, 수용률 99.99% 달성
- 다중 테넌트 동시 부하에서 스코프 키 누락으로 메시지가 100% reject됨 — 5개 테넌트 동시 부하 측정 환경을 구성하고 hot-path 로그 제거·메시지 스코프 키 도입으로 reject 제거, 5분간 29.9만 메시지 sustained에서 ack p95 42ms(목표 <100ms)·에러율 0.04%(목표 <0.1%) 달성
- x86 Fargate가 6,000 동시접속 부하에서 CPU·메모리 사용률이 높아 운영 비용 부담 — 아키텍처 가정 대신 6,000 동시접속 실부하에서 x86 대비 자원 효율을 실측 비교한 근거로 ARM64(Graviton) 전환 — 멀티플랫폼 이미지(x86/ARM64) 빌드로 양 플랫폼 동시 지원, 동일 부하에서 CPU 사용률 15%·메모리 54% 감소, 단가 동등 — 운영 비용 절감 근거 확보
기술 선택 이유
메시지 순서 보장을 위해 Redis Streams 기반 WAL(Write-Ahead Log)을 채택하고, 단일 노드 수직 확장 대신 4-shard Valkey 클러스터로 분산 — 싱글스레드 Redis는 코어 증설로 쓰기 병목을 해소할 수 없기 때문. ECS Fargate ARM64 전환은 동일 부하 자원 효율 비교 측정으로 검증 후 채택.
마케팅 통합 플랫폼
2025.02 ~ 현재마케팅 전용 DB 분리 기반 위에 Google Ads/Meta/TikTok 캠페인·소재·지표를 단일 시스템에서 관리하는 통합 마케팅 플랫폼
- 3개 광고 플랫폼 캠페인 관리 분산 — Google Ads/Meta/TikTok 캠페인 생성·배포·수정과 리텐션 지표 관리를 단일 플랫폼에서 처리하는 API 정립, 3개 광고 플랫폼 통합 캠페인 자동화로 마케터 콘솔 전환 작업 제거
- Meta 에셋 동기화 성능 병목 — 행별 ORM 단건 저장이 트랜잭션 오버헤드를 유발해, 단건 저장 대신 벌크 INSERT·일괄 삭제로 전환, Image 동기화 72% 단축(25.7s→7.1s), DB 트랜잭션 95% 단축(10~16s→0.3~0.5s)
- 마케팅 데이터 조회 비용 급증 — BigQuery Storage Read API 도입으로 gRPC 스트리밍 기반 고성능 데이터 읽기 전환, BigQuery 비용 82% 절감(TB당 $6.25→$1.1)
- 100+ 컬럼 테이블 조회 성능 저하(18초) — 테이블 3개(메인/시계열/예측) 정규화, 인덱스+커서 페이지네이션 적용, 조회 성능 97% 개선(18s→0.5s)
- 마케팅 지표 아카이브 대용량 백필 중 Lambda 실행 63초·RDS CPU 99.8% 포화로 처리 ETA 15시간 — 근본 원인을 N+1 쿼리와 비SARGable 날짜 조건(DATE() 인덱스 미스)으로 규명 후 제거 — 행별 조회가 RDS를 포화시켜, 행별 조회 대신 30일치를 단일 배치 쿼리로 모아 in-memory에서 최신 버전만 dedup, 처리량 26배 개선(9.3→247건/분), Lambda 실행 63s→1.36s, RDS CPU 99.8%→5~7%
- 마케팅 RCP 데이터 엑셀 전용 + BigQuery 통합 테이블이 복수 소스 조합 구조라 콘솔 통합 조회 불가 — 엑셀 수작업·복수 소스 통합 테이블의 값 불일치 문제로, 복수 소스 결합 대신 단일 정규화 소스 테이블로 전환 + Criteria-Result 패턴 metadata API 신설로 표시 형식 하드코딩 제거, 콘솔 내 RCP 통합 조회 내장, 하드코딩 currency/소수점 표시를 BE metadata 기반으로 대체
기술 선택 이유
BigQuery Storage Read API로 비용 82% 절감. GCP Pub/Sub → AWS Lambda/SQS 하이브리드 파이프라인으로 이벤트 기반 처리 전환, Outbox 패턴으로 API 비차단 비동기 발행 설계.
사내 공통 라이브러리 체계
2025.07 ~ 현재NestJS 유틸 10개 모듈 + 게임서버 Kit 2개 패키지 개발·운영으로 다중 프로젝트 코드 일관성 달성
- 서비스 간 공통 코드 중복 및 유지보수 비용 증가 — core, repository, cache, lock, slack, crypto, smb, hash, type, iac 10개 모듈 라이브러리 체계 설계, 7개 프로젝트 공통 코드 일원화 및 의존성 관리 표준화
- Repository 계층 코드 비대화(2000+줄) 및 타입 안전성 부족 — read-then-write 방식이 동시 쓰기에서 경쟁 상태(중복 키 충돌)를 유발해, read-then-write 대신 atomic upsert + 감사 로그 자동 분기 구현 — 함수 오버로딩·제네릭으로 타입 좁히기 지원, SRP에 따라 비대한 Repository를 목적별 모듈로 분리, 2000+줄 코드 정리 후 공용 Repository 계층 도입으로 CRUD 중복 제거 및 데이터 접근 표준화
- 멀티 인스턴스 환경의 동시성 제어 부재 — ElastiCache (Redis) 기반 분산 락을 AOP 데코레이터로 추상화하여 비즈니스 로직과 분리, 분산 락 데코레이터로 멀티 인스턴스 동시성 제어 일관 적용
- 7개 프로젝트 패키지 업그레이드 수작업(3시간) — workflow_dispatch+matrix 병렬 실행, 변경 패키지 CI 테스트 자동화(GitHub Packages), 업그레이드 배포 시간 3h→15m 단축
- CI 테스트 실행 시간 과다(15m47s) — @swc/jest는 decorator 메타데이터 호환성이 낮아 @swc/jest 대신 tsc 네이티브 transpiler 기반 ts-jest isolatedModules + Entity 타입 명시 채택, CI 61% 단축(15m47s→6m06s), 81 suites 978 tests 통과
- 게임서버 공통 코드가 5개 브랜치로 분산 + 한 게임은 게임 데이터 정의 모듈 17개가 외부 패키지와 2년+ diverged — 게임 데이터 정의 모듈+5개 서브모듈을 독립 패키지로 추출 후, 한 게임에 610 파일/310+ import 일괄 마이그레이션 + config 주입·인터페이스 누락 등 9건 hotfix, 패키지 체계 확립 및 첫 게임 적용 — 9건 hotfix 무사고, 이후 데이터 모듈 업데이트는 npm 버전 bump 1건으로 자동 통합(수동 마이그레이션 610 파일→0)
- 게임 서버 공통 캐시 로직이 프로젝트마다 중복 구현되어 정합성·유지보수 부담 — 로컬 LRU(핫패스 지연 최소화)와 분산 캐시(인스턴스 간 일관성)를 결합한 Hybrid 전략을 데코레이터 기반 AOP 라이브러리로 패키지화 — 순수 분산은 네트워크 왕복, 순수 로컬은 인스턴스 간 불일치 문제로 결합형 채택. SRP에 따라 태그 인덱스·single-flight를 별도 모듈로 분리, 캐시 라이브러리 v0.5.0 릴리스 — 28 스위트 262 테스트 통과, 코드 표준 100% 준수
기술 선택 이유
ElastiCache(Redis) 기반 분산 락을 AOP 데코레이터로 구현하여 비즈니스 로직에서 락 코드 분리. Jest 30 VM 격리 대응 시 5가지 옵션 검토 후 poolSize=2 채택.
CS 상담 채팅 서버
2026.04 ~ 현재게임 운영 고객 상담(CS)용 채팅 서버를 공유 배포 환경에서 ECS로 완전 분리하고, 인증·보안·부하 한계를 검증
- 고객 상담(CS) 채팅이 공유 배포 환경에 묶여 자원 경합·배포 결합 발생 — ECS Fargate로 서비스를 완전 분리하고 Terraform IaC(S3 state)·GitHub Actions OIDC·관측 sidecar로 배포 자동화 — 게임별 분산 토큰 검증 대신 중앙집중 game token 검증 경로 채택, 독립 서비스 cutover 및 Terraform 모듈화, Grafana 11-panel 대시보드·8 알림 구성
- 신규 CS 채팅 도메인이 계층 결합·임의 토큰 수명으로 보안·유지보수 리스크 — Clean Architecture 4계층으로 책임 분리하고 OAuth2 access(5분)/refresh(1시간) 토큰과 ETag/304 폴링을 도입 — 매 폴링마다 전량 응답하는 대신 변경분만 전송, 12 스위트 39 테스트 통과, IaC plan +10 리소스 무사고 적용
- 1.0 vCPU 한계·cold start 40~90초·이미지 비대로 스파이크 트래픽 대응 불가 — task 자원·ALB RPS 오토스케일 정책을 재설계하고 ARM64 native 빌드 + Dockerfile 경량화·마이그레이션 분리로 cold start 단축, 이미지 381→254MB(-127MB)·빌드 5→2분·cold start 30% 단축, k6 500 VU 스파이크 0% 실패
- 프로젝트 간 데이터 격리·요청 rate 제한·첨부 접근 제어 부재 — cross-project 격리(삼중 검증 헬퍼)와 Redis 저장소 기반 rate limit(인증 5/분·refresh 10/분·메시지 30/분), 첨부 FK 정합 마이그레이션을 도입 — 인메모리 throttler는 다중 인스턴스 우회 가능성으로 기각, 보안 통합 머지, 타입 검사 0 에러, cross-org/project 격리 spec 정립
기술 선택 이유
공유 배포 환경의 자원 경합·배포 결합을 끊기 위해 ECS로 독립 분리(Terraform IaC + GitHub Actions OIDC)하고, 게임별 분산 토큰 검증 대신 중앙집중 game token 검증 경로를 채택. rate limit은 다중 인스턴스 정합을 위해 Redis 저장소 기반 throttler로 구현.
AWS Lambda 마이그레이션 & Event-Driven Architecture
2025.06 ~ 2025.08마케팅 지표 60일 → 360일 확장에 따른 배치 작업 한계 해결 및 배치 처리 서버리스 전환
- 전체 서버리스 이관 시 운영 안정성 리스크 — API 서버(EC2)는 유지하고 배치/Job 처리만 Lambda로 분리하는 하이브리드 아키텍처 설계, API 가용성 무영향 보장, 배치 워크로드만 격리 이관해 운영 리스크 차단
- 배치 처리의 수집 기간 한계(60일) 및 처리 시간 2시간 — SQS+Lambda+EventBridge 기반 Event-Driven 비동기 처리 전환, 처리 시간 2h→5m 단축, 수집 범위 6배 확장(60일→360일)
- 비동기 전환 시 데이터 정합성 보장 필요 — 예약·지연 발행 기반 트랜잭션 아웃박스 패턴 적용, 이벤트 기반 아키텍처에서 데이터 정합성 보장
- Lambda 스로틀링, CloudWatch 비용 증가, 빌드 OOM 발생 — Batch Size 벌크 처리, CloudWatch 로그 경량화, 빌드 OOM 조치, 격리된 Lambda 워크로드 자동화로 배포 시간 3시간→15분 단축
- Lambda 대량 실행 시 DB 커넥션 고갈 — RDS Proxy 풀링 기반 커넥션 관리 도입, DB 커넥션 고갈 문제 해결
기술 선택 이유
배치·이벤트성 작업이 서버 본체에 묶여 독립 배포 불가한 제약 해소를 위해 Lambda 선택. SQS로 비동기화하여 트래픽 변동 시 처리 지연과 확장성 한계 해결.
게임 인앱 다국어 번역 시스템
2026.02 ~ 현재게임 내 알림/공지 다국어 번역 체계의 도메인 모델 재설계 — AI 번역과 라이브러리 기반 변환을 3단계 파이프라인으로 분리
- 간체는 AI 지원 언어가 아님에도 AI 번역 설정 도메인 내부 옵션으로 모델링되어 도메인 의미 왜곡, 설정 저장·조회가 번체 AI 번역 상태에 의존하여 breaking change 없이 독립 on/off 불가 — 파생 변환 모듈을 AI 번역 모듈에서 독립 분리(9개 use case + 전용 entity/repository/scheduler), effective 설정 글로벌 상속 패턴 적용, 9개 use case 분리로 도메인 경계 명확화, 파생 변환 규칙 독립 토글 지원
- 설정 decoupling 과정에서 breaking API change 필요 — FE/BE/Gateway 동시 배포 전략과 역할 권한 마이그레이션으로 무중단 전환, breaking API change 장애 없이 전환 완료, effective 설정 DB 쿼리 50% 감소(4→2)
- detect 크론의 버전 우선순위 부재로 최신 버전 변환 지연 + 30초 주기 응답 지연 — detect SQL에 버전 ID 기반 우선순위 정렬 추가, 처리 주기 30초→10초, 배치 limit 100→200 최적화, 최신 버전 변환 지연 해소, 진행률 UI와 총 건수 캐시로 사용자 가시성 확보
- detect 스케줄러가 159개 버전을 한 번에 스캔(3.27M rows full scan) → RDS IOPS 포화로 사용자 로그인 60초 장애 — AI detect 모듈의 per-version loop 이식 + 분산락 timeout/recovery + NOT EXISTS full scan을 인덱스 staged lookup으로 대체, 쿼리 260× 단축(전체스캔→39ms 인덱스 lookup), driving filesort 제거, 사용자 로그인 latency 정상 복원
기술 선택 이유
AI 번역 도메인과 라이브러리 기반 파생 변환의 책임 경계를 코드 구조에 실체화. Detection→Processing(AI)→Conversion(라이브러리) 3단계 파이프라인을 독립 모듈로 분리하고, 2단계 race guard와 pessimistic write lock으로 동시 요청 정합성 확보
마케팅 플랫폼 Audit Log 시스템
2025.01 ~ 2025.04게임 운영 중 데이터 변경 이력 추적 불가로 인한 밸런스 문제 대응 지연 해결
- 6개 게임 간 데이터 변경 이력 추적 불가 — UUID 기반 크로스 환경/프로젝트 엔티티 추적 Git-like 버전 관리 시스템 정립, 6개 게임 간 데이터 일관성 보장
- 엔티티 변경 기록의 수동 관리 부담 — Auditable 데코레이터 + TypeORM Subscriber 패턴으로 이벤트 소싱 기반 변경 자동 기록 파이프라인 설계, 엔티티 변경 이력을 자동 추적하고 모든 게임 환경에서 데이터 변경을 일관되게 기록
- 다중 환경 간 엔티티 충돌 감지 및 병합 부재 — 상위/하위 엔티티 충돌 감지와 유니크 제약조건을 고려한 3-Way Merge 엔진 구현, 6개 게임 다중 환경 간 버전 병합 자동화
- 버전 간 변경 사항 비교 비효율 — Base Audit 유무에 따른 증분 비교와 스냅샷 비교의 이중 전략 Diff 엔진 설계, 증분 및 스냅샷 이중 전략으로 버전 비교 성능 최적화
- PK 의존 엔티티 추적의 환경 간 불일치 — 공유 식별자 기반 크로스 환경 엔티티 추적 체계 설계로 PK 의존 탈피, 마이그레이션/비교/병합 시 정확한 엔티티 추적 보장
기술 선택 이유
TypeORM EntitySubscriberInterface 동작과 제약을 별도 분석 후 채택. Auditable 데코레이터 + Subscriber 조합으로 엔티티 변경을 표준화된 Audit 파이프라인으로 자동 수집하는 AOP 방식 설계.
Cloud Data 동기화 시스템
2025.08 ~ 현재환경 간 동적 게임 데이터 불일치 문제를 해결하기 위한 S3 기반 동기화 및 DDL 자동 관리 시스템
- 환경 간 동적 게임 데이터 불일치 — S3 기반 개발/스테이징/프로덕션 환경 간 동기화 시스템 구축, 환경 간 데이터 일관성 보장
- 환경 간 스키마 불일치 수동 관리 부담 — PK 컬럼 타입 동적 결정, 컬럼 타입 불일치 감지·MODIFY, 인덱스 자동 생성·RENAME DDL 자동 관리 엔진 구현, 데이터베이스 스키마 변경사항 자동 추적 및 동기화
- Cloud Data 적재 및 S3 업로드 성능 병목 — 병목 구간 분석 및 저장/업로드 최적화, TRUNCATE→DELETE 전환으로 대용량 데이터 처리 시간 77% 단축(57.5초→12.9초)
- 동기화 작업 불안정(타임아웃, 스케줄링 충돌) — job 분리, 스케줄링 방식 전환, timeout 조정, non-blocking 처리 적용, 마이그레이션 및 스키마 최적화로 데이터 계층 안정성 강화
- 데이터 동기화 서비스 운영 장애 4건(캐시 정합·메타데이터·복사 키·데이터 보호 옵션 누락) — Redis 캐시 무효화, DDL SKIP 메타데이터 정리, 복사 키 삭제, 데이터 보호 옵션 전달 누락 수정, 4건 장애 원인 분석·수정으로 데이터 동기화 서비스 안정성 확보
- 데이터 마이그레이션 시 보호 옵션(클라우드 보관 데이터 제외)이 일부 경로에 미전파되어 전체 삭제 리스크 — 누락된 POST 경로 4곳에 보호 옵션 전달 보강, 운영 데이터 전체 삭제 리스크 차단
기술 선택 이유
S3 Lifecycle 정책(30일 Glacier IR, 90일 만료)으로 비용 최적화. 이벤트성 실행에서 스케줄링 방식으로 전환하여 동기화 누락 위험 감소.
확률 계산 및 감사 로그 분석 파이프라인
2026.02 ~ 현재게임 확률 검증 체계 부재에 따른 규제 리스크 해소를 위한 확률 계산 패키지와 CDK 기반 감사 로그 분석 인프라 개발
- 6개 라이브 게임 환경 (12 브랜치 운영) 확률 계산 로직 분산 및 규제 대응 부재 — NestJS DynamicModule 기반 5개 확률 함수+Kinesis 로깅을 확률 계산 공통 패키지로 분리, 6개 라이브 게임 환경 (12 브랜치 운영) 확률 패키지 통합 (cherry-pick main + 11 branches)
- 확률 감사 로그 분석 인프라 부재 — Kinesis→Firehose(Dynamic Partitioning+Parquet)→S3→Glue→Athena E2E 파이프라인 CDK 코드화, 6개 라이브 게임 환경 (12 브랜치 운영) 프로젝트에 통합하여 확률 공시 감사 로그 파이프라인 구축
- 모킹 기반 테스트의 회귀 신뢰도 부족 — 모킹 삭제, LocalStack+Testcontainers 기반 통합 테스트 교체, 회귀 신뢰도 강화, 12 suites 115 tests 커버리지 94%+ 확보
기술 선택 이유
Kinesis → Firehose(Dynamic Partitioning + Parquet) → S3 → Glue → Athena 파이프라인을 CDK로 코드화. Parquet 컬럼형 포맷으로 Athena SQL 분석 비용 최적화, LocalStack Testcontainers로 모킹 기반 테스트 제거.
마케팅 데이터 아카이빙 & 커스텀 대시보드
2026.04 ~ 현재마케팅 지표의 일별 스냅샷 아카이빙(불변성 보장), 4천 행 규모 커스텀 대시보드, 알림 관측성을 구축
- 4천 행 규모 마케팅 메트릭을 단일 대시보드에 표시 시 스크롤 성능 저하·셀 동기화 버그 — BE는 Raw SQL DISTINCT JOIN(ORM hydration 회피)+in-memory 캐시, FE는 가시 행 lazy fetch+200행 단위 청킹(네트워크 왕복과 렌더 지연의 균형점)+pair별 캐싱으로 분리 — 전량 로딩은 응답 크기·렌더 비용으로 기각, 4,458행 중 3,341행 매핑 표시, 응답 cold 573ms/warm 221ms로 안정화
- 동기화 경로가 reference-date cutoff 대신 최신 스냅샷을 사용해 아카이브 불변성 위반(데이터 오염) — cutoff semantics를 준수하도록 usecase·repository를 재설계하고 stale-writer guard를 트랜잭션 처리, 동기화 상태에 tombstone을 도입, live 15,333개 아카이브 재구축(오염 0), 287,020개 archive-date 검증 통과
- 로그 쿼리 스택(Loki) 일시 장애 시 마케팅 알림 16건이 동시 발화해 운영 채널 도배 — 장애 원인을 규명한 뒤 알림 16건을 단일 분석 DB(ClickHouse) 쿼리로 전환하고 대시보드 API로 재작성, 레거시 로그 스택 폐기 정책 수립, 알림 16/16 마이그레이션(25분), 로그 스택 장애 시 알림 도배 재발 방지
기술 선택 이유
아카이브는 조회 시점이 아닌 reference-date cutoff 기준의 불변 스냅샷이어야 하므로 stale-writer guard와 tombstone 상태로 무결성을 강제. 대용량 그리드는 전량 로딩 대신 가시 영역 lazy fetch + chunk 캐싱으로 처리.