42개 Worker가 단일 ECS Task(4vCPU/16GB)에 묶여 운영되며 다음 문제가 누적된 상태였습니다.

• 모든 워커가 한 Task에서 동시에 부팅돼 기동이 오래 걸리고, 메모리가 부족해 일부 워커가 아예 실행되지 못하는 문제
• Consumer를 cron_restart로 주기마다 강제 재시작해 시간당 약 40회 리밸런싱·메시지 중복이 발생하고, 재시작 시점마다 CPU가 90%까지 치솟는 문제
• 푸시 알림 컨슈머가 단일 인스턴스로만 동작해, 피크 시간대 알림이 몰리면 Consumer LAG가 수만 건까지 쌓이고 해소에 6시간 넘게 걸리는 처리 지연
• idle Batch 프로세스가 약 7.7GB를 상시 점유하는 자원 낭비

• cron_restart 제거 + Graceful Shutdown 래퍼로 Consumer 13개 교체 → 리밸런싱·메시지 중복 해소
• 단일 push consumer에 몰리던 알림을 도메인별(추천/채팅/기타) 전용 ECS 서비스·Kafka 토픽으로 분리 → 도메인 간 간섭 제거, 도메인별 독립 스케일링
• 관계 알림을 CDC 우회 경로에서 Kafka 직접 발행으로 전환 → 불필요한 우회 제거·실시간성 향상
• Batch를 PM2 cron에서 EventBridge + ECS RunTask로 분리, 실행 이력·DLQ·실패 알림 확보
• 알림 Worker에 Consumer LAG 기반 ECS Auto Scaling 적용, 기존 방식에서 새 방식으로의 전환은 롤백을 대비하여 feature flag 기반 무중단 cutover로 진행

• 피크 Consumer LAG 37,402 → 778건(약 48배↓), 해소 시간 389분 → 9분
• 리밸런싱 시간당 약 40회 → 0회
• 실측 기반 Worker Task 4vCPU/16GB → 1vCPU/6GB 축소, idle 약 7.7GB 해소
• 인프라 비용 연 약 USD 2,800 절감
• 공통 Worker 운영 구조로 일반화 → 케밋에서 검증 후 타 서비스로 확장 적용 가능한 기반 마련

• push 분리 작업의 무중단 롤백을 위해 둔 feature flag가, 조회될 때마다 설정을 매번 직렬화하면서 CPU를 끌어올려 피크 시간 API latency가 20초까지 치솟던 문제를 발견했습니다 → 즉시 서버 수를 늘려 피크를 넘긴 뒤, 전환이 끝난 flag를 제거해 직렬화 비용을 없애 근본 해결했습니다. 무중단을 위한 안전장치가 역으로 비용이 될 수 있음을 확인했습니다
• Batch command가 완료돼도 커넥션 풀이 이벤트 루프를 붙잡아 ECS task가 종료되지 않고 10분 이상 RUNNING으로 남는 문제를 발견했습니다 → 완료 시 명시적으로 프로세스를 종료하도록 전환하고, at-least-once 트리거에 대비해 중복 실행 방지 락을 함께 적용했습니다
• 배포 중 Batch 종료 로직과 잔존 PM2 cron 설정이 충돌해 재시작 루프가 발생했습니다 → 코드 변경과 운영 설정 변경을 같은 배포 단위로 묶어야 한다는 기준을 세워 재발을 방지했습니다

케밋에서 얼굴·신상을 드러내지 않고 깊은 취향·성향으로 맞는 상대를 발견하도록, 게시글·댓글·추천·친구신청·알림·제재를 포함한 익명 커뮤니티를 신규 설계·구축했습니다. DAU 약 27K·read-heavy 특성에 맞춰 스키마·캐시·집계·모더레이션 구조를 설계했습니다.

• 쉐도우 임계치·정지 단계·피드 가중치·추천 비율 등 정책값을 브랜드별 config로 분리해, 다른 브랜드에도 동일 구조를 재사용할 수 있도록 설계
• soft delete와 내부 제재 이력 관리로 관리자 모더레이션에 대응
• 게시글 정렬은 실시간 쿼리 스코어링·Redis 피드 캐시와 비교해 feed_score 선계산 컬럼 채택 → 현 규모에선 인덱스 활용이 최적, Redis는 오버엔지니어링으로 판단(latency 악화 시 전환)
• 조회수는 Redis INCRBY 버퍼 + Dirty Set으로 5분마다 일괄 flush하도록 설계해, 조회마다 DB UPDATE가 발생하지 않도록 부하를 방지
• BEST·추천 글은 Redis ZSET 실시간 랭킹 + 주기적 스냅샷으로 산정, 추천은 조건별 후보 풀 가중치 샘플링으로 구성
• 도배는 ZSET 기반 Sliding Window Log로 윈도우 내 요청 수를 제한해 차단
• 이미지 모더레이션 자동화를 위해 Amazon Rekognition 도입을 제안하고, 검증 latency가 작성 흐름을 막지 않도록 텍스트는 동기(SNS ID 정규식·금지어), 이미지는 비동기(pending 후 MSK → Amazon Rekognition)로 분리해 작성 응답 지연 최소화

• 출시 후 커뮤니티 API 월 1억 건+ read-heavy 요청을 캐싱·사전집계로 안정 운영 (가용성 99.9%+)
• A/B 테스트매칭 전환율 +3.9%(여성 +14.5%), 일 체류시간 +35.1%(9분 10초 vs 6분 47초)
• 커뮤니티 경로 친구신청 수락률 32.5%(일반 경로 19.3% 대비), 신규·기존 이탈 및 결제 악영향 없음 확인
• 이미지 모더레이션을 자동화해 운영팀의 수동 검수 부담을 줄이고, 부적절 콘텐츠 노출 리스크를 사전 차단

• SNS ID를 막는 정규식이 기본 닉네임을 오탐해 정상 유저가 쉐도우 처리되던 문제가 있었습니다.
  • SNS ID를 막는 영문+숫자 패턴이 기본 닉네임 형식과 충돌 — 댓글에 상대 닉네임을 @멘션으로 넣으면 그 닉네임이 SNS ID로 오탐됐음
  • SNS 패턴 검사 직전에 @멘션을 마스킹하도록 수정 → 처음엔 대문자·6자리 숫자만 막다가 소문자·짧은 자릿수가 새는 걸 확인해 필터 범위를 @[A-Za-z]{4}\d{1,6}로 넓혀 차단, 회귀 방지 테스트 추가

일본 진출용 로컬 BM이자 한국에도 공통 적용할 수 있도록, Google·Apple 스토어 기반 월 단위 자동갱신 구독 정기권 시스템을 신규 구축했습니다. 결제 성공·실패·유예·일시중지·만료·취소·환불 등 다양한 구독 상태를 처리하고, 무제한 대화·프로필 보기·좋아요 지급 등 혜택의 지급·동기화를 자동화했습니다.

• 스토어 실시간 알림(Google RTDN(Pub/Sub), Apple Server Notification·JWS)을 Webhook으로 수신 → MSK publish → Validation Worker가 영수증 검증 후 상태 반영하는 비동기 구조 설계
• Google·Apple의 인증·알림 포맷 차이(Apple JWT(ES256) 직접 생성, JWS의 x5c 인증서 체인을 Apple Root CA까지 검증 후 payload 파싱, Google Pub/Sub push 인증)를 전략 패턴 기반 인터페이스로 분리해 스토어별 정책 변경에 대응
• 알림 중복은 notification 단위 유니크 제약으로, 순서 역전은 이벤트 타임스탬프 비교로 최신 상태만 반영하도록 분리 처리하고, Validation Worker에 멱등성 검증을 적용해 구독 상태 정합성 확보
• Webhook 수신 후 내부 처리 구간은 Outbox로 발행 정합성을 보장하고, 스토어→서버 인바운드 알림 유실은 1일 1회 주기 재검증 Worker로 보완해 이중 안전장치 구성
• 혜택 지급·회수를 자동화하고, 중복 지급은 지급 단위 유니크 제약을 최종 방어선으로 두고 Redis SETNX 분산 락으로 경합을 1차 차단
• 결제 실패 grace 처리와 환불 시 즉시 혜택 종료·소모성 아이템 회수, 사용 후 환불 악용은 이용정지로 대응

• Google·Apple 양 스토어 결제·혜택 지급 기반을 신규 구축해 한국·일본 구독 정기권 출시 지원
• Webhook + 주기 재검증 이중화로 스토어 알림 누락 상황에서도 구독 상태 동기화 보장
• 혜택 지급·회수 자동화로 수동 운영 개입을 제거하고, 혜택 누락·중복 지급으로 인한 CS 리스크 감소

• 다운그레이드는 두 가지 이유로 구현이 까다로웠습니다.
  • 즉시 적용되는 업그레이드와 달리 다운그레이드는 다음 갱신부터 적용되는 예약 상태를 유지해야 하는데, 두 스토어의 표현 방식이 근본적으로 달랐음 — Apple은 알림 subtype(또는 플랜 tier 비교)으로, Google은 linkedPurchaseToken과 lineItems의 이전 항목 유무로 판정 → 스토어별 신호를 DOWNGRADE/UPGRADE 공통 이벤트 타입으로 변환하고, 다운그레이드는 현재 플랜은 두고 예약 플랜에만 반영해 상위 혜택을 현재 주기 끝까지 유지
  • 구독 갱신 주기(샌드박스도 수 시간 단위)를 기다려야 하고 상태 조합이 많은 데다 검증이 Validation Worker에서 비동기로 일어나 자동 재현이 어려웠음 → dev 서버에서 실제 스토어 알림을 흘리며 상태 전이를 로그로 추적해 케이스별로 검증

일본은 데이팅 앱 이용에 18세 이상 본인·나이 인증을 규제로 요구합니다. 일본 서비스 출시를 위해 Liquid eKYC 기반 인증 결과 조회, 프로필 이미지 비교, 인증 상태 반영으로 이어지는 인증 플로우와, 인증 이벤트 비동기 처리 및 인증 수단·이미지의 완전 삭제까지 포함한 규제 대응 구조를 설계했습니다.

• 인증 요청 → eKYC 결과 조회 워커 → Amazon Rekognition 기반 프로필·인증 이미지 비교 워커 → 인증 상태 반영·알림으로 이어지는 단계를 MSK 토픽으로 분리한 비동기 파이프라인으로 설계
• 검증된 생년월일로 만 18세 미만을 차단하고, 인증 미완료 유저에게는 채팅 발신 알림을 제어해 규제 요건 충족
• 기존 메시지 처리 구조의 이벤트 유실 가능성을 발견해 Outbox 패턴으로 인증 이벤트 처리 정합성을 확보 — 발행 방식은 사내 CDC 인프라와 Polling Publisher를 비교한 뒤, 인증 이벤트는 빈도가 낮아 CDC 운영 부담 대비 이득이 적다고 판단하여 앱 스케줄러 기반 Polling Publisher로 단순하게 구현
• Liquid 기밀 데이터 삭제 API latency(5~30초)를 고려해 탈퇴 로직과 분리한 비동기 삭제 워커를 두고, Liquid·S3에 저장된 PII를 자동 삭제
• 일본 외 국가 확장을 대비해 country-restricted 가드로 국가별 게이트를 두고, 알림·에러 메시지를 i18n으로 처리

• 일본 18세 본인인증 요건을 충족해 서비스 정식 심사 통과에 기여
• Outbox 기반 이벤트 처리 구조로 인증 이벤트 유실 가능성을 제거하고, 운영 기간 내 미처리 이벤트 0건 유지
• 기밀 데이터 자동 삭제 구조를 구축해 일본 규제·감사 대응 체계 마련

프로필 기반 탐색의 한계를 보완하고 취향 기반 매칭 경험을 강화하기 위해, 관심사·라이프스타일·MBTI·연애성향 등 프로필 태그를 기반으로 친구를 추천하는 탐색 탭을 구현했습니다. 인기 태그 랭킹과 태그별 사용자 추천을 제공해 태그 기반 탐색·매칭 경험을 개선했습니다.

• 태그 등록·리뷰 카운트를 Redis ZSET(ZINCRBY)으로 실시간 누적하고, 주기 배치 워커가 카테고리별 랭킹을 ZUNIONSTORE로 머지해 인기 태그 목록을 산정
• 태그별 사용자 추천은 매력점수·성별(키)·거리·공통 관심사 등 서로 다른 조건의 후보를 Elasticsearch msearch로 묶어 단일 요청으로 처리
• 추천 결과는 변동이 잦고 캐시 적중률이 낮아 Redis 캐시 대신 Elasticsearch 직접 조회로 단순화
• 일본 진출을 고려해 태그 데이터를 언어별로 분리 관리할 수 있도록 설계

• 태그 카운트는 실시간으로 누적하고 랭킹은 주기 배치로 산정하는 구조로, 서로 다른 추천 조건을 단일 요청으로 처리
• Elasticsearch msearch 기반 복합 쿼리로 P95 500ms 달성
• 추천 정확도 개선 A/B 테스트 결과, 추천 경로 좋아요 전송 수 +7%, ARPDAU +12%

• 여러 태그 쿼리를 msearch로 합산할 때 같은 유저가 중복 노출돼 Set으로 중복을 제거했는데, 중복 제거 후 개수로 다음 페이지 존재 여부를 판정하던 탓에 수천 명 규모의 태그에서도 페이지네이션이 조기 종료되는 문제를 발견 → 다음 페이지 판정을 중복 제거 전 원본 쿼리 합계 기준으로 바꿔 해결

지역 기반 만남 수요에 대응하고 가까운 친구 탐색 경험을 제공하기 위해 위치 기반 동네 친구 추천 기능을 구축했습니다. H3 기반 geosharding과 Redis 캐싱으로 위치 데이터를 효율적으로 관리하는 추천 구조를 설계했습니다.

• 위경도를 H3 hex 셀로 변환해 성별 Redis sorted set에 저장하고, 지역 밀집도에 따라 셀 크기를 분기해 추천 풀의 크기를 조절
• 추천은 Redis에서 인접 hex 후보를 1차로 좁힌 뒤 Elasticsearch에서 선호설정·차단·연결·like 관계를 필터링하는 2단계 구조로 설계
• 이미 추천한 유저는 72시간 동안 재추천에서 제외하고, 정규 추천과 섞이지 않도록 추천 이력을 별도 테이블로 분리
• 추가 추천은 재화 소비로 제공하고, 소비·추천 이력 기록을 트랜잭션으로 묶어 정합성 확보

• H3 geosharding과 Redis 캐싱으로 P95 250ms 이하 응답 속도 달성
• A/B 테스트 결과 결제 +12%(p=0.02), D+1 리텐션 +0.7%, 신규 남성 LTV day6 기준 +26.6%
• 위치 기반 동네 탐색 출시 후 DAU 대비 해당 기능 일간 사용률 40% 기록

기존 재화 시스템은 유저별 잔액 합계만 보유해 지급 단위별 추적이 불가능했고, 사용 순서·소멸 정책이 없어 미사용 재화가 무한정 쌓이는 회계 리스크가 있었습니다. 적립·사용·소멸 이력을 추적할 수 있는 공통 재화 관리 시스템으로 전면 재구축했습니다.

• 지급 단위별로 잔여량을 추적하는 상세 이력 테이블을 신설하고, 먼저 지급된 재화부터 차감하는 FIFO 사용 로직을 핵심 도메인 규칙으로 설계(동시간 지급 시 유료 우선)
• 유료 5년·무료 3개월의 소멸 정책을 정책 적용일자를 키로 관리해 향후 정책 변경에 대응하고, 보상 지급 시 만료 시각이 리셋되도록 처리
• 만료 재화 처리는 커서 페이지네이션 기반 배치 워커로 구현하고, 소멸 내역도 사용 이력에 함께 기록해 감사 추적성 확보
• 소멸 사전 고지를 위해 대상 유저를 Redis Set으로 수집하고, 캐시 장애를 대비해 S3로 이중화
• 기존 데이터는 잔액 유무로 분리해 청크 단위로 마이그레이션하고, 잔액이 없는 유저도 빈 이력을 남겨 마이그레이션 누락과 구분할 수 있게 한 뒤 전후 잔액을 검증

• FIFO 기반 사용·소멸 정책과 이력 추적 구조를 도입해 감사 대응이 가능한 재화 관리 체계 구축
• 소멸 알림 도입 후 4주간 재화 사용률 약 +15% (도입 직전 동기간 대비)
• 공통 라이브러리로 구현해 멀티 브랜드에서 동일 구조를 재사용할 수 있는 기반 마련

• 잔액이 있어도 소비가 실패하는 정합성 문제가 두 가지 원인으로 발생했습니다.
  • 트랜잭션 누락 — 일부 무료 재화 지급 경로에서 합계 증가와 상세 생성이 한 트랜잭션으로 묶이지 않아, 중간 실패 시 합계는 늘었지만 상세가 생성되지 않았습니다 → 지급 경로를 트랜잭션으로 묶어 원자적으로 커밋되게 하고, 상세 생성 함수의 트랜잭션 인자를 필수로 변경해 누락을 차단했습니다
  • read replica 지연 — 차감 시 상세를 읽는 조회가 트랜잭션 밖에서는 복제본으로 향해, 지급 직후 소비하면 복제 지연으로 방금 만든 상세가 아직 보이지 않아 차감에 실패했습니다 → 소비 흐름을 트랜잭션 경계로 묶어 같은 커넥션에서 조회와 차감이 일관되게 일어나도록 수정했습니다

피크 시간 API 응답이 20초까지 치솟는 장애가 반복됐고, 매번 '이벤트 루프 포화'로 결론을 냈지만 같은 처방이 다음 장애를 막지 못했습니다. 원인을 하나로 뭉뚱그린 것이 문제라고 보고, 서로 다른 실패 방식으로 나눠 규명했습니다.

• 동기 직렬화로 인한 이벤트 루프 포화 — Datadog Continuous Profiler로 추적해 유저 수만큼 증폭되던 동기 JSON 딥클론·설정 재파싱을 원인으로 규명하고 제거 → 이벤트 루프 지연 71ms → 0.2ms(약 350배↓) · 처리량 +14.5% 확보
• 헬스체크가 장애를 증폭 — 로드밸런서 헬스체크가 DB·Redis·Kafka·검색엔진을 순차 확인하는 깊은 검사에 연결돼 있어, 의존성 지연 하나가 정상 task까지 교체 대상으로 만들고 트래픽이 남은 소수에 몰리는 연쇄를 유발 → 인스턴스 자체만 확인하는 경로로 교체해 연쇄를 차단하고, 배포마다 반복되던 알림 노이즈도 함께 해소
• GC 정지 — stop-the-world 정지가 최대 3.13초, 이벤트 루프 지연이 6.88초까지 오른 장애에서 이벤트 루프 이용률(ELU)은 0.845에 그쳐 탐지에 실패 → ELU는 지속 포화에만 유효하고 순간 정지는 GC 정지 시간·이벤트 루프 지연 분위수로 봐야 함을 확인해 지표를 유형별로 분리
• 메시지 발행 직렬화 — 전역 프로듀서가 동시 전송 1건 + 멱등 옵션으로 동작해 프로세스 내 모든 발행이 한 줄로 직렬화되고, 요청 핸들러가 이를 그대로 대기하면서 API가 최대 209초까지 멈추던 문제를 규명 → 브로커 중단을 재현한 로컬 A/B로 40초 → 3.02초 개선을 검증

• 프로덕션과 같은 2vCPU 조건을 재현하는 로컬 측정 환경을 구축해, 추정 대신 A/B 수치로 개선 여부를 판단하는 절차를 확보
• 요청 스코프 read 캐시(처리량 +12.4% · 요청당 Redis 호출 208 → 118회), 응답 딥클론 제거(+10%), 카탈로그 메모이제이션(CPU −88.6%) 등 개선안을 실측 기반으로 도출
• 컨슈머가 축소 배포 중 비정상 종료돼 생존 인스턴스가 멈춘 채 살아 있고, 지연량이 알람 임계 사이 구간에 갇혀 자가 복구되지 않던 문제를 규명해 임계값 조정으로 해소

• CPU 절감이 곧 지연 개선은 아니었습니다. 프로덕션 CPU를 약 10% 줄였지만 같은 시간대 지연은 움직이지 않았고, 피크는 이벤트 루프 포화이고 상위 지연은 I/O 대기라 CPU 여유가 체감으로 이어지지 않음을 확인했습니다 → 이후 성능 작업은 무엇을 개선하는지를 지표와 함께 먼저 정의하고 착수합니다
• 팀 문서에 기록해둔 원인이 실제 코드와 맞지 않는 것을 확인하고 정정했습니다. 축적된 장애 기록도 주기적으로 코드와 대조해야 한다는 기준을 세웠습니다

• 배포·마이그레이션·코드리뷰·장애 조사처럼 반복되지만 실수 비용이 큰 작업이 개인 숙련도에 의존하고 있었습니다
• AI 도구를 그대로 쓰면 프로덕션 DB·배포를 건드릴 수 있어, 안전장치 없이는 팀에 권하기 어려운 상태였습니다

• 개인 설정이 아니라 레포에 체크인해 팀 공용 자산화 — 배포·마이그레이션·리뷰·테스트·장애 조사용 에이전트 20여 개를 버전 관리 대상으로 운영하고, 작업 난이도에 따라 모델 등급을 나눠 비용을 배분
• 프로덕션 경로에 안전 게이트를 설계해 내장 — 테스트는 로컬 DB 대상임을 검증해야 실행되고, 프로덕션 DB 권한은 읽기 전용으로 고정하며, 마이그레이션은 적용 대상 확인 → 명시적 승인 → 사후 검증 순서를 강제
• AI 코드리뷰의 오탐을 구조로 제거 — 찬성·반대 두 에이전트가 각 지적을 검증하고 남은 것만 반영하도록 절차화
• 결정론적으로 생성 가능한 부분은 스크립트에 위임하고 AI는 오케스트레이션만 담당하도록 역할을 분리
• Datadog·Sentry·Notion·DB를 MCP로 연결해 관측 → 원인 분석 → 티켓화를 한 흐름으로 처리

• 배포·검증·리뷰 절차가 문서가 아닌 실행 가능한 형태로 남아, 담당자가 달라도 같은 순서로 수행할 수 있는 기반을 마련
• 장애 원인·아키텍처 결정을 90여 개의 상호 링크 문서로 축적해 같은 조사를 반복하는 비용을 절감
• 실제로 이 구조 위에서 프로덕션 장애 원인 분석과 크로스리전 매칭 설계를 수행

• AI 결과를 그대로 신뢰하지 않고 실측·코드 재확인으로 검증하는 절차를 함께 둬야 실효가 있었습니다. 실제로 이전에 기록해둔 장애 원인이 틀렸음을 후속 검증에서 발견하고 정정했습니다
• 도구가 반복적으로 틀리는 지점은 그때마다 규칙 문서로 환류해, 같은 실수가 재발하지 않도록 관리하고 있습니다

단독 백엔드로 케밋을 운영하며 성능·정합성·악성유저 대응·해외 확장 등 안정화 과제를 지속적으로 처리했습니다. 트래픽 증가와 일본 진출에 맞춰 병목과 운영 리스크를 발견하는 대로 개선했습니다.

• 태그 랭킹 조회를 Redis pipeline으로 묶어 라운드트립을 280회에서 4회로 줄여 p50 응답을 약 11배(481ms → 42ms) 단축
• 알림 전송 로직을 개선해 메시지당 DB 호출을 약 400회에서 수 회로(약 98%↓) 줄이고 Worker 메모리 사용을 낮춤
• 좋아요 전송·성향 테스트 저장 등 동시성 이슈를 Redis 분산 락과 원자적 upsert로 해결해 중복 처리·정합성 오류 제거

• 악성유저 등록 시 기기 식별자·전화번호를 함께 차단하고 재가입·재로그인 시점에 검증해 번호 변경 우회를 차단
• 피해 유저 보상을 일정 기간 내 상호작용으로 한정하고 지급 이력 플래그로 중복 지급을 제거해 보상 누수를 차단

• 하드코딩된 리소스를 제거하고 언어코드 기반 리소스 로딩 + 템플릿 치환 구조로 리팩터링해 다국어 처리를 일반화
• 국가별 운영 환경(DB·SMS 전송·리소스)을 분리해 한국·일본을 동시에 서비스할 수 있는 구조 확보

• 수동 git pull·재기동에 의존하고 API·워커가 한 EC2에 묶여 메모리가 부족하던 dev 환경을, 7개 서비스를 ECS로 옮겨 배포를 자동화하고 리소스를 격리
• 수동 재기동이 사라지면서 백엔드·프론트엔드 모두 서버 접속 없이 배포할 수 있게 되어 팀 배포 편의성과 생산성 개선