케밋에서 얼굴·신상을 드러내지 않고 깊은 취향·성향으로 맞는 상대를 발견하도록, 게시글·댓글·추천·친구신청·알림·제재를 포함한 익명 커뮤니티를 신규 설계·구축했습니다. 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% 확보
• 이후 같은 응답 지연이 재발했을 때는 원인이 다시 이벤트 루프 포화인데도 CPU·동기 헬스체크로는 정상으로 보여 포화된 task가 죽지 않고 계속 트래픽을 받는 것이 실질 문제임을 규명 → 포화가 CPU가 아닌 이벤트 루프 이용률(ELU)에서만 드러남을 확인해 ELU를 관측 지표로 추가하고, 포화 시 함께 실패하는 헬스체크로 되돌려 문제 task를 조기에 걸러내도록 개선
• 태그 랭킹 조회를 Redis pipeline으로 묶어 라운드트립을 280회에서 4회로 줄여 p50 응답을 약 11배(481ms → 42ms) 단축
• 알림 전송 로직을 개선해 메시지당 DB 호출을 약 400회에서 수 회로(약 98%↓) 줄이고 Worker 메모리 사용을 낮춤
• 좋아요 전송·성향 테스트 저장 등 동시성 이슈를 Redis 분산 락과 원자적 upsert로 해결해 중복 처리·정합성 오류 제거

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

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

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