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

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

• 출시 후 커뮤니티 API 월 1억 건+ 요청을 p99 167ms·30일 5xx 0%로 안정 운영, 게시글 조회 p95 72ms / p99 180ms
• A/B 테스트(14일) 매칭 전환율 +3.9%(여성 +14.5%), 일 체류시간 +35.1%(9분 10초 vs 6분 47초)
• 커뮤니티 경로 친구신청 수락률 32.5%(일반 경로 19.3% 대비), 신규·기존 이탈 및 결제 악영향 없음 확인

• SNS ID(연락처·카카오·인스타 등)를 막기 위한 영문+숫자 혼합 패턴이, 기본 닉네임(MBTI 4자 + 숫자) 형식과 충돌 — 댓글·답글 본문에 상대의 기본 닉네임을 @멘션으로 넣으면 그 닉네임이 SNS ID로 오탐돼 정상 유저가 쉐도우 처리되던 문제를 발견
• SNS 패턴 검사 직전에 @멘션을 마스킹하도록 수정하고, 처음엔 대문자·6자리 숫자만 막았다가 소문자·짧은 자릿수 닉네임이 여전히 새는 것을 확인해 멘션 필터 범위를 넓혀(@[A-Za-z]{4}\d{1,6}) 오탐을 차단. 회귀 방지를 위해 멘션 케이스 테스트를 추가

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

• 스토어 실시간 알림(Google RTDN(Pub/Sub), Apple Server Notification·JWS)을 Webhook으로 수신 → MSK publish → Validation Worker가 영수증 검증 후 상태 반영하는 비동기 구조 설계
• Google·Apple의 인증·알림 포맷 차이(Apple JWT(ES256) 직접 생성·JWS 파싱, Google Pub/Sub push 인증)를 전략 패턴 기반 인터페이스로 분리해 스토어별 정책 변경에 대응
• 스토어 알림의 중복·지연·순서 역전을 transaction token 유니크 제약 + 이벤트 타임스탬프 비교로 처리하고 Validation Worker에 멱등성 검증을 적용해 구독 상태 정합성 확보
• Webhook 유실·누락에 대비해 Outbox와 1일 1회 주기 재검증 Worker(active·grace 유저 cursor 페이지네이션 재조회·동기화)로 이중화
• 혜택 지급·회수(좋아요 월별 회수 후 재지급, 무제한 대화·프로필 보기)를 자동화하고 중복 지급은 Redis SETNX 분산 락으로 방지
• 결제 실패 grace(유예) 처리와 환불(REFUND/REVOKED) 시 즉시 혜택 종료·소모성 아이템 회수, 사용 후 환불 악용은 이용정지로 대응

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

• 다운그레이드는 즉시 적용되는 업그레이드와 달리 다음 갱신부터 적용되는 예약 상태를 들고 있어야 했는데, 두 스토어가 이를 표현하는 방식이 달라 통합이 까다로웠음 — Apple은 DID_CHANGE_RENEWAL_PREF + subtype과 autoRenewProductId로, Google은 linkedPurchaseToken과 lineItems 구조로 다운그레이드를 판정
• 스토어별 알림을 전략 패턴으로 분리하고 공통 파라미터·이벤트 타입으로 정규화해, 도메인 로직은 스토어를 모른 채 동작하도록 통합. 업그레이드는 즉시 플랜을 교체하고 다운그레이드는 예약 플랜으로만 표시해 현재 주기의 상위 혜택을 유지, 실제 전환은 갱신 시점에 스토어가 내려주는 플랜 기준으로 일어나도록 설계

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

• 인증 요청 → eKYC 결과 조회 워커 → Amazon Rekognition 기반 프로필·인증 이미지 비교(Liveness) 워커 → 인증 상태 반영·알림으로 이어지는 단계를 MSK 토픽으로 분리한 비동기 파이프라인으로 설계
• 검증된 생년월일로 만 18세 미만을 차단하고, 인증 미완료 유저에게는 채팅 발신 알림(닉네임 노출)을 제어해 규제 요건 충족
• 기존 메시지 처리 구조의 이벤트 유실 가능성을 발견해 Outbox 패턴으로 인증 이벤트 처리 정합성을 확보 — 발행 방식은 사내 CDC 인프라와 Polling Publisher를 비교한 뒤, 인증 이벤트는 빈도가 낮아 CDC 운영 부담 대비 이득이 적다고 판단하여 앱 스케줄러 기반 Polling Publisher로 단순하게 구현
• Liquid 기밀 데이터 삭제 API latency(5~30초)를 고려해 탈퇴 로직과 분리한 비동기 삭제 워커를 두고, Liquid·S3에 저장된 PII를 자동 삭제
• 일본 외 국가 확장을 대비해 country-restricted 가드(서버 LANGUAGE_CODE 기반)로 국가별 게이트를 두고, 알림·에러 메시지를 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개월의 소멸 정책을 정책 적용일자를 키로 관리해 향후 정책 변경에 대응하고, 보상 지급 시 만료 시각이 리셋되도록 처리
• 만료 재화 처리는 커서 페이지네이션 기반 배치 워커로 구현하고, 소멸 내역도 사용 이력에 함께 기록해 감사 추적성 확보
• 소멸 사전 고지(유료 30·7·3일, 무료 매월 1일)를 위해 대상 유저를 Redis Set으로 수집하고, 캐시 장애를 대비해 S3로 이중화
• 기존 데이터는 잔액 유무로 분리해 청크 단위로 마이그레이션하고, 잔액이 없는 유저도 빈 이력을 남겨 마이그레이션 누락과 구분할 수 있게 한 뒤 전후 잔액을 검증

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

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

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

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

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

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

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