아래 이미지는 책에서 나온 최종 시스템 설계도입니다.

• 피드발행[그림3-3]
• 뉴스 피드 가져오기[그림3-4]

위 설계도는 “팔로우 기반 개인 피드”이지만, 아이바는 “팔로우 없는 전역 최신 피드”를 기준으로 합니다.
그래서 포스팅 전송 서비스의 fan-out 파이프라인이 별도로 존재하지 않습니다.
또한 사용자 정보는 user-service에서 별도로 가져와야 해서 Redis 캐시 및 gRPC 기술을 사용하였습니다.

** [Aiva community-service 요약]**

• 피드 목록은 Redis Sorted Set(ZSET), 게시글 본문은 Redis Hash, TTL 24시간
• 작성자 정보(닉네임/아바타 등)도 헤더에서 받아 캐시
• 최신 피드 조회: ZSET에서 커서 기반 페이지네이션 → Post Hash 다건 조회 → 작성자 정보 캐시 조합
• 교차 서비스 조회: user-service는 gRPC로 동기 통신
• 알림: 댓글/대댓글/좋아요 이벤트를 Kafka 토픽에 퍼블리시 → notification-service가 컨슘 후 FCM 발송

1. 피드 발행

레디스 데이터/키 설계 요약

• 피드 인덱스(ZSET): feed:global score = createdAt(epochMillis), member = postId
• 게시글 본문(HASH): post:{postId} title, content, authorId, createdAt, likeCount ...
• 작성자 정보 캐시(HASH): user:{authorId}:profile nickname, avatarUrl, ...

흐름

1. Community에 글 작성 요청 수신
2. DB 트랜잭션: 게시글 영속화(MySQL)
3. 캐시 반영(TTL 24h)

• HSET post:{id} ... (본문 저장)
• ZADD feed:global score=now member=postId (최신순 인덱스 갱신)
• HSET user:{authorId}:profile (작성자 정보 캐시)

Redis 키 설계 이유

• ZSET(feed:global)

  • 점수(score)에 createdAt(epochMillis)를 쓰면 최신순 정렬이 자동이고, 커서 기반 페이지네이션에서 O(logN + M)로 안정적입니다.
  • 목록에는 postId만 넣어 정렬/페이지네이션과 본문 캐시를 관심사 분리 → 메모리 사용량 절감, 갱신 충돌 감소.
  • 팔로우가 없는 전역 피드라 “사용자별 피드 상자”가 불필요해 키 수가 적고 단순합니다.
  • 참고: Redis SortedSet

• HASH(post:{postId})

  • 필드 단위 접근/갱신이 쉽고 명확합니다(예: HINCRBY likeCount).
  • 본문/메타 일부만 읽어도 되어 네트워크/CPU 낭비 최소화.
  • 포스트 스키마가 변해도 필드 추가로 유연하게 진화 가능.

• 작성자 프로필 HASH(user:{authorId}:profile)

  • 헤더의 사용자 정보를 기본으로 캐시에 저장
  • 사용자 정보 수정시 해당 캐시 내용 업데이트 필요

TTL 시간(24H)

• 사용 패턴 가정: 전역 최신 피드는 ‘하루 단위’ 소비가 강함 → “전일 최신” 컨셉과 정합.
• 신선도 vs 비용: 너무 짧으면 미스/DB 부하↑, 너무 길면 스테일·메모리↑. 24h는 합리적 시작값.
• 운영 조정(히트율 보며 튜닝)
  • 히트율↑·메모리 여유→ 늘림(예: 36h)
  • 미스↑·DB 과열→ 늘림 (DB 보호)
  • 메모리 압박·스테일 이슈→ 줄임(예: 12h)

2. 피드 목록 조회

커서 기반 페이지네이션 설계

페이지네이션 비교

성능 벤치마크 (100만 레코드 기준)

-> 소셜피드 같은 경우 커서 기반으로 페이지네이션을 구현한다.

페이지네이션의 기준(정렬 키)은 “항상 동일”해야 합니다. 아이바에선 createdAt DESC, id DESC(= 최신순 + 동점 보조키)로 통일하고,

• 24h 캐시 구간은 Redis ZSET 커서로,
• 그 아래(오래된 구간)는 DB Keyset Pagination(= 커서 기반)으로 자연스럽게 넘겨 받으면 됩니다.

1. 기준 정렬(커서) 통일

• 커서 형태: (lastCreatedAtEpochMs, lastPostId)
• 정렬: ORDER BY created_at DESC, id DESC
• 조건: (created_at < :lastCreatedAt) OR (created_at = :lastCreatedAt AND id < :lastId)

이렇게 하면 캐시 → DB로 넘어가도 커서의 의미가 동일해서 끊김 없이 다음 페이지를 이어감

2. 캐시 → DB “컷오버(cutover)” 규칙

• cutoff = now - 24h

• 각 페이지를 만들 때:

  1. ZSET에서 score(=createdAt)가 > cutoff인 아이템만 커서 기준으로 가져옴(예: 최대 limit개).
  2. 가져온 개수가 limit보다 부족하면, 남은 개수만큼 DB Keyset으로 추가로 채움.
     • DB 조회의 시작 경계는:
       • 캐시에서 마지막으로 가져온 (lastScore, lastId)가 있으면 그걸 사용
       • 없다면 cutoff를 시작점으로 사용

즉, “페이지 하나”는 캐시 결과 + DB 결과가 합쳐질 수 있습니다. 커서는 항상 “마지막으로 반환한 항목의 (score,id)”로 갱신

3. Redis 쿼리 예시(커서 기반)

# 첫 페이지
ZREVRANGEBYSCORE feed:global +inf -inf LIMIT 0 :limit

# 다음 페이지
# (lastScore, lastId) 커서가 있을 때: score는 open range, 동점은 앱에서 postId로 필터
ZREVRANGEBYSCORE feed:global ( :lastScore  -inf  LIMIT 0 :limit

※ 동점 처리: 동일 score가 많은 경우, 여유분을 조금 더 가져와서 (score < lastScore) OR (score = lastScore AND postId < lastId)로 애플리케이션에서 필터.

4. DB Keyset Pagination 쿼리

-- 인덱스
CREATE INDEX idx_posts_created_id ON posts (created_at DESC, id DESC);

-- 다음 페이지 조회
SELECT id, title, content, author_id, created_at, like_count
FROM posts
WHERE
  (created_at <  :lastCreatedAt)
  OR (created_at = :lastCreatedAt AND id < :lastId)
ORDER BY created_at DESC, id DESC
LIMIT :limit;

• 첫 DB 페이지라면 :lastCreatedAt = :cutoff, :lastId = 'MAX' 같은 형태로 시작.
• 응답 마지막 레코드의 (created_at, id)를 다음 커서로 적용.

gRPC를 통한 작성자 정보 조회

피드 발행 시 작성자 프로필을 user:{authorId}:profile에 캐시(기본 TTL 24h) 해둡니다. 하지만 TTL이 만료되었거나 캐시에 없는 경우, user-service에서 작성자 정보를 gRPC로 조회해 결합합니다. 핵심 흐름은 아래와 같습니다.

1. 피드 목록에서 수집한 authorId들을 중복 제거
2. 캐시에서 우선 조회 → 존재하는 것은 즉시 사용
3. 캐시 미스 난 ID만 묶어서 gRPC 벌크 호출(지연/호출 수 최소화)

선택 이유: 작성자 정보는 재사용률이 높고(여러 게시글에 반복 등장), gRPC는 낮은 지연·작은 페이로드·타입 안정성으로 비용 대비 효용이 큽니다.

MSA에서의 서비스 간 통신 선택지와 트레이드오프

3. 알림 발송

댓글/대댓글/좋아요 이벤트를 본요청 경로에서 분리하여, Kafka → notification-service → FCM 파이프라인으로 비동기 처리합니다.

전체 흐름

이벤트 스키마 & 토픽

• 토픽: community.events (파티션 N, 압축 on)
• 파티셔닝 키: targetUserId (동일 사용자 알림 순서 보장/스로틀 유리)
• 소비 모델: at-least-once → 멱등 처리 필수

{
  "eventId": "uuid-...",            // 멱등키(필수)
  "type": "COMMENT|REPLY|LIKE",
  "actorId": "user-123",
  "targetUserId": "user-999",
  "postId": "post-456",
  "commentId": "c-789",             // (선택)
  "createdAt": 1695972100123
}

notification-service 소비 로직

1. 멱등 체크: eventId가 이미 처리되었으면 즉시 스킵
2. 수신 가능 여부: user-service gRPC로 토큰/알림 설정 조회 → 거부/야간 차단이면 종료
3. FCM 전송: 토큰 단위 전송(배치/병렬), 결과 수집
4. 결과 처리:
   • 재시도 대상(429/5xx/네트워크): 지수 백오프 + 지터로 재시도
   • 영구 실패(잘못된 토큰 등): 토큰 폐기 + 기록
   • N회 실패: DLQ 이동
5. 멱등키 기록: 성공/영구 실패 모두 eventId 저장(중복 방지)

@KafkaListener(topics = ["community.events"], groupId = "notification")
fun handle(e: Event) {
    if (idem.exists(e.eventId)) return
    val info = userGrpc.getPushInfo(e.targetUserId) // tokens, settings
    if (!info.settings.allow(e.type)) { idem.save(e.eventId); return }

    val payload = render(e, info.settings.lang)
    sendWithRetry(info.tokens, payload) // 429/5xx만 재시도

    idem.save(e.eventId) // 최종 기록(성공/영구실패)
}

코틀린 비동기 전송(코루틴)

• 경량 동시성으로 수백~수천 전송을 스레드 과증식 없이 처리
• withTimeout/retry(backoff+지터)/SupervisorJob로 취소/재시도/격리 제어

suspend fun sendWithRetry(tokens: List<String>, payload: Payload) = coroutineScope {
    val sem = Semaphore(50) // 동시 전송 50
    tokens.chunked(500).map { batch ->
        async {
            sem.withPermit { retry(3) { fcm.sendAll(batch, payload) } }
        }
    }.awaitAll()
}

신뢰성 전략 (멱등 · 재시도 · DLQ)

• 멱등성: eventId에 Unique 보장(테이블/캐시)
• 재시도 정책: 429/5xx/일시 네트워크만 재시도(최대 N회, 지수 백오프)
• DLQ: 스키마 오류/참조 무효/최대 재시도 초과 이벤트 격리
• Exactly-once 착각 금지: 현실은 at-least-once → 멱등으로 해결

마무리

이번 글에서는 ‘가상 면접 사례로 배우는 대규모 시스템 설계 – 뉴스 피드’의 아이디어를 참고해, 아이바(Aiva)의 현실 제약(팔로우 없음·전역 최신 피드)을 반영한 커뮤니티 서비스 설계를 정리했습니다. 핵심은 다음과 같습니다.

• 목록/정렬은 ZSET, 본문은 HASH로 관심사 분리
• TTL 24h(히트율/비용 균형)과 커서 기반 페이지네이션(createdAt DESC, id DESC)
• 작성자 정보는 캐시 우선 → gRPC 폴백
• 알림은 Kafka 비동기 처리 + 멱등/재시도/DLQ로 유실·중복·폭주에 강하게

아직 분산환경을 위해 기술적으로 손볼 부분이 많습니다... 나머지 서비스들을 채워가며 계속 디벨롭할 예정입니다..

최근 해커톤에 참여했던 프로젝트를 계속 디벨롭하고 있고, 그 과정을 기록으로 남기고자 합니다. 프로젝트명은 아이바(Aiva) 로, 생성형 AI 기반 육아 챗 서비스입니다. 팀 내 AI 개발자분께서 7세 미만 육아 도메인에 특화된 모델을 파인튜닝해주셨고, 회원가입 시 입력한 육아 정보를 바탕으로 사용자가 채팅으로 질문하면 맞춤형으로 답해줍니다.

채팅뿐 아니라 커뮤니티 기능을 통해 양육자 간 정보 공유와 소통을 지원하고, 알림 서비스로 개인별 육아 정보를 큐레이션합니다. 또한 구독제를 도입해 더 전문적인 모델 사용과 일일 채팅 횟수 상향을 제공하도록 설계했습니다.

msa 도입배경

아이바는 표면적으로는 ‘채팅 서비스’이지만, 실제로는 커뮤니티/알림/구독/결제 등 다양한 도메인이 얽혀 있습니다. 이 참에 MSA(Microservices Architecture) 를 직접 도입해보며 학습·검증하자는 목표를 세웠습니다.

해커톤 기간 내 전부 구현하는 건 무리라는 걸 알았기에, 해커톤 종료 후 개인적으로 프로젝트를 이어가며 적용했습니다. 솔직히 지금 단계에서는 오버스펙에 가깝지만, 개념으로만 알던 MSA를 실전에서 다뤄보며 배우는 것에 의의를 두었습니다.

그렇다면 실무에서는 왜 MSA를 택하고, 어떻게 도입할까요? 아주 짧게 개념을 정리하면:

• 왜: 팀 단위 병렬 개발, 독립 배포, 장애 격리, 도메인 경계 명확화, 확장성(서비스별 스케일 아웃)
• 어떻게: 도메인 분해 → 데이터베이스 분리 → 서비스 간 통신 전략(REST/gRPC/이벤트) 수립 → 모니터링(로그/메트릭/트레이싱) → 배포/테스트 자동화(CI/CD 등)

(각 항목의 구체 적용과 트레이드오프는 다음 글들에서 서비스별로 자세히 다룰 예정입니다.)

아이바: msa 아키텍처 설계

기본 설계

• 도메인 분리: User / Chat / Community / Notification / Subscription (총 5개)
• 데이터 격리: 각 서비스는 자체 MySQL(스키마/인스턴스 분리)
• API Gateway: Spring Cloud Gateway로 라우팅, 인증, 로드밸런싱 중앙화
• 캐싱/세션: Redis로 세션 공유와 읽기 최적화 캐싱
• 통신 방식: 서비스 내부는 동기(REST/gRPC) + 비동기(Kafka) 혼합
• 모니터링: 로깅/메트릭/트레이싱을 서비스별로 수집·대시보드화(예정예정)

기술 스택

• Backend: Kotlin/Spring Boot
• API Gateway: Spring Cloud Gateway
• DB: MySQL (서비스별 독립 인스턴스/스키마)
• Cache/Session: Redis
• Messaging: Kafka (알림/이벤트)
• Push: FCM
• CI/CD & Monitoring: (Not yet..)

마무리

MSA 도입의 시작.. 대서막....! 해커톤 일정에 쫓겨 초반 아키텍처를 엉성하게 잡았고, 이후 『가상 면접 사례로 배우는 대규모 시스템 설계』 스터디와 추가 학습을 거치며 여러 번 갈아엎었습니다. 이제야 벨로그에 정리하며 기반을 다질 수 있을 만큼 방향이 잡힌 듯합니다.

물론 아직 부족한 부분이 많고, 앞으로도 계속 수정과 개선이 뒤따를 겁니다. 개발은 원래 그런 과정이니게.. 점진적으로 나아가 보겠습니다. 아좌좌~

필사 프로젝트 내에서 제공하고 있는 메모 기능은 전체 사용자 중 5% 미만만이 사용하는 상황이었다. 기능 활성화 방안을 고민하던 중, 단순히 메모 공간을 제공하는 것만으로는 참여율 제고가 어렵다는 결론에 도달하였다.

이에 따라 구글잼을 통해 학습하던 Vertex AI Gemini API를 활용하여, 매일 제공되는 명언을 기반으로 사용자가 사유해볼 수 있는 질문을 생성하고 이를 메모 기능과 연동하는 접근을 시도하였다. 즉, 단순한 기록 공간에서 벗어나, AI가 제공하는 질문을 통해 자연스럽게 메모 참여를 유도하는 방식이다.

github: https://github.com/LEE-DAYOUNG-SARAH/fillsa-ai

2. 기술적 환경 설정

1. 의존성 설치

   pip install google-genai

2. 데이터 소스

   • 명언 데이터는 로컬 DB에서 조회하도록 구현하였다.

3. 모델 설정 아래와 같이 모델 파라미터를 설정하였다.

   GEMINI_MODEL=gemini-2.5-flash-lite
   GEMINI_MAX_OUTPUT_TOKENS=248
   GEMINI_TEMPERATURE=1.0
   GEMINI_TOP_P=0.92
   GEMINI_TOP_K=60

   • gemini-2.5-flash-lite를 선택한 이유: 가볍고 빠른 응답 속도를 제공하며, 짧은 질문 생성에 적합.
   • Temperature=1.0: 다양성과 창의성을 확보.
   • Top-P=0.92, Top-K=60: 문장 다양성 확보를 위한 확률 샘플링 보정.

4. JSON 응답구조

   client.config = types.GenerateContentConfig(
    response_mime_type="application/json",
    response_schema={
         "type": "object",
         "properties": {
            "question_en": {"type": "string"},
             "question_ko": {"type": "string"},
        },
        "required": ["question_en", "question_ko"],
    },
    ...
   )

3. 프롬프트 설계 및 실험 과정

(1) 1차 시도

• 설정: 온도=0.5, Top-P=0.9

• 프롬프트: 영어 명언을 입력으로 받아, 영어 질문과 한국어 직역 질문을 동시에 생성하도록 요구.

  Generate one thought-provoking question for users based on this English quote.
  First create the question in English, then translate it to Korean.
  Both versions must be exactly the same question, just in different languages.
  
  Quote: "{eng_quote}"
  
  Requirements:
  Question that helps with self-reflection and personal development 
  Specific and practical question 
  Question that explores the core meaning of the quote 
  Korean question must be a direct translation of the English question

• 실패 원인:

  • 출력 문장이 과도하게 길고 딱딱함.
  • 일상적 대화톤이 아닌 학술적 문체로 출력됨.

(2) 2차 시도

• 변경 사항: 온도=0.8, Top-P=0.9
• 프롬프트:
  • “You are a warm journaling coach”로 톤을 부드럽게 지정.
  • 10~18 단어 제한.
  • 쉬운 단어 사용(academic term 금지).
  • 실용적·구체적 질문 요구.

  You are a warm journaling coach.
  Write ONE short, conversational question inspired by the quote below.

  Quote: "{eng_quote}" 

  Constraints:
  - 10–18 words in English. Keep Korean the same meaning and similar length. 
  - Use plain, everyday words; avoid stiff/academic terms(e.g., “genuine”, “personal development”, “self-reflection”, “opportunity”). 
  - Must (a) invite self-reflection/growth, (b) be specific and practical, (c) probe the quote’s core meaning. 
  - Do NOT restate the quote, add explanations, or include code fences.

  [KO] 
  - 한국어는 자연스러운 구어체(또는 부드러운 존댓말)로, 영어 문장을 충실히 번역.

• 실패 원인:
  • 여전히 문장이 길고 반복적 단어(small) 등장.
  • 특정 시점(예: “오늘”)이 고정적으로 포함됨.

(3) 3차 시도

• 변경 사항: 온도=1.0, Top-P=0.9,TOP_K=60

• 프롬프트:

  • 질문 길이: 8~14 단어.
  • 랜덤 시간 앵커 정책 도입:
    • 시간x, 24시간, 이번 주, 특정 상황(비판·의심·좌절 시) 등 랜덤 선택.
  • 한국어는 부드러운 존댓말 번역 요구.

    You are a warm journaling coach.
    Write ONE short, conversational question inspired by the quote below.
    

  Quotes: {quotes_text}

  Time anchor policy:

  - Randomly choose ONE for each question:
  A) no time anchor

  B) next 24 hours / this week C) next time D) last time E) today

  • If C or D, pick from: ["you get criticism","you feel stuck","you doubt yourself","you feel upset"].
  • 8–14 words in English; Korean same meaning and similar length.
  • Use plain words. Do Not use "small"
  • Be specific and practical; no restating the quote; no code fences; max one comma.

  [KO]

  • 한국어는 부드러운 존댓말(–요) 또는 편한 구어체.
  • 영어와 의미·길이를 비슷하게 유지. ```

• 실패 원인:

  • 단일 문장을 보낼 경우 랜덤 정책이 정상 작동하지 않음.

• 해결:

  • 10개의 명언을 한 번에 보내어, 프롬프트 내 랜덤성이 효과적으로 적용됨.
  • 결과적으로 자연스럽고 짧은 질문이 생성되었으며, 만족스러운 품질 확보.

4. 결론

1. 데이터 기반 문제 인식

   • 기능 사용률을 수치로 확인하면서, 단순 제공만으로는 기능 활성화가 어렵다는 사실을 재확인.

2. AI 적용 효과

   • Gemini API를 활용해 사용자 경험을 보완하는 방식은 효과적이었다.
   • 특히, 짧고 실용적인 질문을 통해 사용자가 메모 기능에 자연스럽게 참여할 수 있는 계기를 제공.

3. 학습과 성장

   • 새로운 기술을 실제 문제 해결에 적용하며 성장 경험을 얻음.
   • 프롬프트 설계와 파라미터 튜닝 과정을 통해 AI 모델의 출력 제어 기법을 체득.
   • 지표 기반 문제 해결 접근이 서비스 운영에서 얼마나 중요한지 체감.

Redis는 다양한 데이터 구조를 제공하지만, 그 중에서도 Sorted Set은 실시간 순위 시스템 구현에 있어 독보적인 성능을 자랑합니다. 해당 챕터를 읽으면서 Redis의 다양한 기능 중 Sorted Set에 대해 집중적으로 조사해보았습니다.
이 글에서는 Redis Sorted Set의 내부 동작 원리부터 실무에서의 활용 패턴, 그리고 대규모 서비스에서의 확장 전략까지 실전 경험을 바탕으로 공유하겠습니다. (우와 이 글을 작성하고 얼마 안되어서 사이드 프로젝트에 Redis Sorted Set을 사용해보게 되었습니다. 이에 대해선 글 마지막에 추가하였습니다.)

레디스 Sorted Set

Redis Sorted Set의 정교한 아키텍처와 실무 활용

Redis Sorted Set은 Skip List와 Hash Table의 이중 구조를 통해 O(log N) 성능을 보장하면서도 점수 기반 정렬과 범위 쿼리를 지원하는 고성능 데이터 구조입니다. 2024-2025년 현재, Redis 7.2+에서 30-100% 성능 향상을 달성했으며, 게임 리더보드부터 실시간 분석까지 다양한 분야에서 핵심 기술로 활용되고 있습니다. 특히 대용량 데이터셋에서도 초당 7만 건 이상의 삽입 성능과 마이크로초 단위 지연시간을 제공하여, 실시간 시스템 구축의 필수 요소로 자리잡았습니다.

1. 핵심 개념과 내부 구조

Redis Sorted Set의 혁신적 이중 데이터 구조

Redis Sorted Set은 동일한 데이터를 두 개의 서로 다른 구조에 저장하는 독창적인 접근 방식을 사용합니다. Hash Table은 member → score 매핑을 위한 O(1) 조회를 제공하고, Skip List는 score 기반 정렬 순서를 유지합니다. 이 이중 구조는 빠른 검색과 효율적인 범위 쿼리를 동시에 가능하게 합니다.

Skip List는 확률적 다층 연결 리스트로, 각 레벨에서 span 변수를 통해 건너뛰는 노드 수를 저장합니다. 이를 통해 순위(rank) 계산을 O(log N)으로 최적화하며, 최대 32개 레벨(ZSKIPLIST_MAXLEVEL)까지 지원합니다. 레벨 결정은 0.25 확률의 기하 분포를 사용하여 평균적으로 균형 잡힌 구조를 유지합니다.

메모리 최적화와 임계값 전환

작은 데이터셋(기본값: 128개 요소 미만, 각 64바이트 미만)에서는 Ziplist 인코딩을 사용하여 메모리를 최대 10배 절약합니다. 임계값을 초과하면 자동으로 Skip List 구조로 전환되며, 이때 평균 37바이트의 오버헤드가 발생합니다. Redis 6.2+에서는 ZRANGESTORE 같은 대량 연산 시 예상 크기를 미리 계산하여 처음부터 적절한 구조를 선택하는 최적화가 추가되었습니다.

시간 복잡도 분석

주요 연산의 시간 복잡도는 다음과 같습니다. ZADD와 ZREM은 O(log N), ZSCORE는 Hash Table 덕분에 O(1), ZRANGE는 O(log N + M) (M은 반환 요소 수)입니다. 실제 벤치마크에서는 ZADD가 초당 70,000-100,000회, ZRANGE가 초당 66,000-111,000회의 처리량을 보여줍니다. 이는 단일 스레드 기준이며, 네트워크 오버헤드가 실제 성능에 큰 영향을 미칩니다.

2. 대체 기술과의 심층 비교

Redis vs 관계형 데이터베이스

성능 벤치마크 결과에 따르면, 5,000개 레코드 기준으로 Redis는 쓰기 작업을 1초 미만에 완료하는 반면, MySQL은 400-500개 이후 급격한 성능 저하를 보입니다. PostgreSQL의 경우 업데이트에 10초 이상 소요됩니다. 실제 게임 리더보드를 PostgreSQL에서 Redis로 마이그레이션한 사례에서는 응답시간이 500ms에서 5ms로 100배 개선되었고, 동시 사용자 수용량이 10K에서 100K로 증가했습니다.

관계형 DB는 ACID 트랜잭션과 복잡한 조인 연산이 필요한 경우에 적합하지만, Redis Sorted Set은 실시간 랭킹과 빈번한 점수 업데이트가 필요한 시나리오에서 압도적인 성능 우위를 보입니다.

Redis vs MongoDB

리더보드 성능 비교에서 MongoDB는 p99 레이턴시 350ms, p90 40ms, p50 15ms를 기록한 반면, Redis Sorted Set은 각각 9ms (39배 빠름), 2.5ms (16배 빠름), 1.5ms (10배 빠름)를 달성했습니다. 메모리 사용량 측면에서는 Redis가 MongoDB 대비 약 2배를 사용하지만, 이는 초고속 성능을 위한 트레이드오프입니다.

Redis vs Elasticsearch

RediSearch와 Elasticsearch 벤치마크에서, 5.6M 문서 인덱싱 시 RediSearch가 221초로 Elasticsearch의 349초보다 58% 빠르며, 2단어 검색 쿼리에서 4배 빠른 성능을 보였습니다. 특히 벡터 검색에서는 OpenSearch 대비 최대 52배 높은 QPS와 106배 낮은 지연시간을 기록했습니다.

Redis vs Kafka

Kafka는 수백만 메시지/초의 처리량과 수평 확장이 가능하지만 일반적으로 100ms 미만의 지연시간을 보입니다. 반면 Redis는 제한적 처리량과 메모리 제약이 있지만 마이크로초 단위의 지연시간을 제공합니다. 이벤트 소싱과 대용량 스트림 처리에는 Kafka가, 실시간 상태 관리와 낮은 지연시간이 중요한 경우 Redis가 적합합니다.

3. 성능 특성과 2024-2025 최신 트렌드

메모리와 성능 최적화

Redis Sorted Set은 멤버당 평균 103바이트의 오버헤드 (16바이트 값 기준 6.4배)를 가지며, Skiplist 인코딩 시 엔트리당 37바이트의 추가 오버헤드가 발생합니다. 작은 데이터셋(≤128 elements)에서는 Listpack 인코딩으로 최대 10배 메모리를 절약할 수 있습니다.

대용량 데이터셋 처리 성능은 6백만 요소 기준 초당 70,000회 삽입, 동일 데이터셋에서 초당 40,000회 ZINCRBY, 10개 요소 조회 시 초당 132,718회 요청을 처리합니다. CPU 사용 패턴 분석 결과, 읽기 작업이 쓰기보다 더 많은 CPU를 소모하며, 80% CPU 사용률은 수천 개 키에서 초당 수천 회 읽기와 수백 회 쓰기 시 발생합니다.

Redis 7.2+ 혁신과 Redis 8 전망

Redis 7.2에서는 Sorted Set 성능이 30-100% 향상되었으며, 특히 게임 리더보드 시나리오에서 최적화가 이루어졌습니다. 복제 성능은 최대 18% 빨라졌고, Query Engine 최적화로 최대 16배 향상된 쿼리 처리 성능을 달성했습니다.

2024년 말 출시된 Redis 8 GA는 30개 이상의 성능 개선을 통해 최대 87% 빠른 명령어 실행과 2배의 처리량 증가를 실현했습니다. 특히 AI/ML 워크로드를 위한 Vector Set 데이터 타입이 추가되어, Vector Similarity Search와 Sorted Set의 점수 기반 정렬을 결합한 혁신적인 활용이 가능해졌습니다.

클러스터링과 확장성 도전

Redis Cluster에서 Sorted Set은 단일 키로만 존재하여 자동 샤딩이 불가능한 제약이 있습니다. 16,384개 해시 슬롯을 통한 분산과 해시태그를 활용한 수동 샤딩 전략이 필요하며, 여러 샤드에 걸친 집계 쿼리는 애플리케이션 레벨에서 처리해야 합니다. Read-heavy 워크로드에서는 최대 5개 replica를 활용한 읽기 분산이, Write-heavy 워크로드에서는 파이프라이닝과 Lua 스크립트를 통한 최적화가 권장됩니다.

Serverless Redis의 부상

위와 같은 '클러스터링 & 샤딩'과 같은 제약으로 인해, 이를 자동으로 처리해주는 ElasticCache를 활용해 볼 수 있다.

ElastiCache는 Redis OSS에서 직접 처리해야 하는 샤딩, 클러스터링, 페일오버, 백업 같은 복잡한 운영을 AWS가 대신 관리해 줍니다.

Serverless 모드를 사용하면 트래픽에 맞춰 자동으로 규모 확장이 가능해, 게임 순위표나 실시간 랭킹 같은 고트래픽 워크로드에서도 안정적으로 대응할 수 있습니다.

• 참고: ElastiCache 공식 문서 / 실시간 게임 순위표 구축 사례

4. 실무 최적화 권장사항

메모리 최적화 전략

설정 최적화를 통해 zset-max-listpack-entries를 128로, zset-max-listpack-value를 64로 설정하여 작은 집합의 메모리 효율을 극대화합니다. 데이터 설계에서는 긴 문자열 대신 ID 참조를 사용하고, ZREMRANGEBYRANK로 정기적으로 오래된 데이터를 제거하며, KEY 레벨 TTL을 활용하여 자동 만료를 구현합니다.

파이프라이닝과 배치 처리

10,000개 명령어 단위의 배치 처리로 5배 성능 향상이 가능하며, 서버 측 응답 버퍼링 부담을 최소화하기 위해 적절한 배치 크기를 유지해야 합니다. Lua 스크립트를 활용한 원자적 연산으로 race condition을 방지하고, Redis Functions를 통해 네트워크 트래픽을 절약할 수 있습니다.

모니터링 핵심 지표

CPU 사용률 80% 초과 시 확장을 고려하고, 메모리 사용률이 물리 메모리 한계에 접근하면 알림을 설정합니다. P99 기준 응답 시간을 지속적으로 모니터링하며, SLOWLOG를 통해 임계값을 초과하는 명령어를 분석합니다. RedisInsight 2024의 메모리 분석기와 실시간 프로파일러를 활용하여 성능 병목을 식별하고 최적화합니다.

5. 결론

Redis Sorted Set은 이중 데이터 구조의 정교한 설계를 통해 실시간 정렬 데이터 처리에서 탁월한 성능을 제공합니다. 2024-2025년 기준으로 Redis 7.2+의 성능 향상과 Redis 8의 혁신적 기능들, 그리고 클라우드 네이티브 Serverless 서비스의 발전으로 더욱 강력해졌습니다.

메모리 사용량과 클러스터 환경에서의 샤딩 제약 같은 한계가 존재하지만, 적절한 최적화 전략과 하이브리드 아키텍처를 통해 이를 극복할 수 있습니다. 특히 게임 리더보드, 실시간 분석, 우선순위 큐, Rate Limiting 등의 시나리오에서 Redis Sorted Set은 여전히 최고의 선택지이며, AI/ML 워크로드와의 통합을 통해 미래 애플리케이션 개발의 핵심 기술로 자리매김하고 있습니다.

• 참고: 리더보드 시스템 설계

추가) 사이드 프로젝트(필사): 명언 데이터 캐싱

최근 진행한 사이드 프로젝트에서는 1년치의 명언 데이터를 DB에 저장하고 날짜별로 조회하는 기능을 제공하고 있습니다. 자주 변경되지 않는 데이터의 특성상, 매번 DB를 조회하는 대신 Redis 캐시를 사용해 응답 속도를 최적화하기로 결정했습니다.

이때, 저는 단순한 Key-Value 구조인 String이나 Hash 대신 Redis Sorted Set을 선택했습니다. 일반적인 캐싱 시나리오에서 사용되는 String이나 Hash는 정렬 기능이 없기 때문에, BETWEEN과 같은 범위 조회를 지원하지 않습니다. 이 구조들을 사용했다면 모든 데이터를 가져와 애플리케션 단에서 날짜별로 필터링해야 하는 비효율이 발생했을 것입니다.

하지만 Sorted Set은 멤버(member)와 함께 정렬 기준이 되는 스코어(score)를 저장하는 구조적 강점을 가지고 있습니다. score는 정수형이면서 시간의 흐름에 따라 증가하는 속성을 가지고 있어, 시간 기반 정렬에 최적화된 스코어 역할을 했습니다.

이러한 구조 덕분에, 저는 ZSetOperations의 rangeByScore와 removeRangeByScore와 같은 Redis 명령어를 활용하여 "오늘부터 일주일치" 같은 특정 기간의 명언을 O(log N + M)의 효율적인 시간 복잡도로 가져올 수 있었습니다. 이는 DB에 의존했을 때 발생할 수 있는 부하를 줄여주면서, 동시에 매우 빠른 응답 속도를 보장했습니다. Sorted Set의 이러한 특성 덕분에, 데이터 정렬이 필요한 조회 시나리오에서 Redis를 효과적으로 활용할 수 있었습니다.

이번 장은 제가 스터디에서 발표를 맡았던 부분입니다. 기본적인 아키텍처 정리는 노션에 별도로 정리해 두었고, 이 글에서는 분산 이메일 서비스와 AI의 융합에 초점을 맞추려 합니다.
이메일은 본질적으로 보안 위협에 취약하고, 동시에 사용자가 감당하기 어려울 만큼의 정보가 집약되는 채널이다. 그렇기에 단순한 메시징 도구를 넘어, 이제는 AI 없이는 성립하기 어려운 서비스로 발전해왔다.
따라서 이번 글에서는 실제로 이메일이 어떤 방식으로 AI를 적극 도입해왔는지, 그리고 그 과정에서 발견할 수 있는 인사이트에 집중해 살펴보고자 합니다.

1. 보안 위협 대응: 스팸·피싱에서 행위 기반 탐지로

이메일은 사이버 공격의 주요 매개체다. Google의 Gmail은 하루 수천억 통의 메시지 중 99.9% 이상의 스팸을 차단하는데, 이는 머신러닝 기반 스팸 필터와 딥러닝 기반 피싱 탐지 모델 덕분이다. 최근에는 단순 키워드 차단을 넘어서, 텍스트 내 변형(이모지·오타), 이미지화된 문자, QR코드 기반 피싱까지 탐지하는 다층적 모델이 적용된다.

Microsoft의 Advanced Threat Protection(ATP)은 한 걸음 더 나아가, 사용자 행동 시퀀스를 학습한다. 로그인 위치, 첨부 다운로드, 링크 클릭과 같은 일련의 행동이 비정상적일 경우, 개별 이벤트를 넘어 전체 맥락에서 위협을 탐지한다. 이는 기존 룰 기반 보안 체계로는 포착 불가능한 영역이다.

<참고문헌> Google Tech Blog – How we’re using AI to combat the latest scams Microsoft Security Blog – Deep learning-based fusion of behavior signals for threat detection

2. 정보 과부하 완화: 자동 분류, 검색, 요약

사용자는 매일 수십~수백 통의 메일을 관리해야 한다. Gmail의 Priority Inbox는 사용자의 읽기·삭제 패턴을 바탕으로 메일을 Primary, Social, Promotion으로 자동 분류한다. 이는 정보 과부하를 줄이고, 중요한 메일을 놓치지 않도록 하는 핵심 장치다.

최근에는 시맨틱 검색과 자동 요약이 도입되었다. NLP 기반 검색은 “지난주 계약 관련 메일”과 같은 질의를 문맥 수준에서 해석하고, LLM 기반 요약 기능은 긴 스레드를 압축하여 제공한다. 결과적으로 이메일은 단순한 저장소에서 능동적 정보 관리 시스템으로 변모하고 있다.

<참고문헌> Google Cloud - 시멘틱 검색이란 무엇인가요?

3. Gmail과 Gemini: 이메일의 LLM 통합

특히 Gmail은 자사 AI 모델인 Gemini를 본격적으로 통합하면서, 이메일을 사용자 친화적 AI 플랫폼으로 진화시키고 있다. Google Workspace Labs의 “Help me write” 기능은 Gemini를 기반으로 메일 초안을 자동 작성하거나, 기존 메일을 정중·간결·공식 등 다양한 톤으로 변환해 준다.

또한, Gemini는 Gmail 내에서 LLM 기반 문맥 이해를 수행한다. 예를 들어,

• 여러 메일 스레드의 맥락을 분석해 요약 제공
• 메일에서 일정·액션 아이템을 추출해 Google Calendar와 연동
• 특정 키워드 검색이 아닌 의미 기반 검색 지원

즉, Gmail은 더 이상 단순 메일 클라이언트가 아니라, Gemini를 중심으로 한 개인 비서형 플랫폼으로 진화하고 있다. 이는 이메일 서비스가 LLM의 상용화·대중화를 가장 빠르게 보여주는 사례이기도 하다.

<참고문헌> Gmail Blog – 6 Gmail AI features to help save you time

4. 운영 효율화: 분산 시스템과 AI 결합

AI는 사용자 기능에 국한되지 않는다. 글로벌 이메일 서비스는 본질적으로 대규모 분산 메시징 인프라다. Gmail, Outlook과 같은 서비스는 매일 수십억 건의 메시지를 송수신하며, 이 과정에서 큐 적체, 서버 지연, 네트워크 병목이 빈번히 발생한다. Kafka 기반 메시징 시스템에 머신러닝을 접목하여 실시간 트래픽 예측과 자원 최적화를 수행한다.

<참고문헌> How Kafka AI Agents Leverage Real-Time Data for Smart Decision Making

결론

이메일 서비스는 단순한 메시징 도구를 넘어, 이미 AI 없이는 운영되기 어려운 서비스로 자리 잡아가고 있다. 보안 위협 대응, 정보 과부하 완화, 분산 시스템 운영 효율화 등 거의 모든 영역에서 AI가 핵심적인 역할을 하고 있으며, Gmail의 Gemini 통합은 이러한 변화를 상징적으로 보여준다.

그렇다면 왜 이 조합이 표준이 되었을까? 내가 이전 회사에서 경험했던 Datadog과 비교해 보며, 지금 사이드 프로젝트에서는 어떻게 적용할 수 있을지 정리해본다.

업계 표준: Prometheus + Grafana

컨테이너, 마이크로서비스, 멀티 리전 클라우드 환경에서는 단순 “업타임 체크”만으로는 부족하다. 서비스와 리소스가 초 단위로 생겼다 사라지고, 자동 확장/축소되며, 수많은 구성 요소가 분산되어 있기 때문이다.

이런 복잡한 환경에 필요한 것은 실시간 가시성, 유연한 질의, 사전 경보, 확장성이다. 그리고 이를 해결하는 오픈소스 표준 스택이 바로 Prometheus + Grafana다.

Prometheus — 지표 수집의 핵심

• Pull 기반 아키텍처 : 서비스 엔드포인트에서 지표를 안정적으로 긁어옴
• 레이블 기반 메트릭 : 다차원 데이터 구조로 세분화 및 집계 용이
• PromQL : 시계열 데이터 분석에 최적화된 강력한 쿼리 언어
• Alertmanager : 내장된 조건 기반 알림 기능
• 쿠버네티스 친화적 : 동적 서비스 디스커버리 기본 지원

→ 단순 수집이 아니라 “맥락 있는 모니터링”을 제공한다.

Grafana — 데이터를 인사이트로

• 실시간 대시보드 : KPI를 직관적으로 추적
• 알람 연동 : Slack, PagerDuty, 이메일 등과 통합
• 멀티 데이터 소스 지원 : Prometheus뿐 아니라 InfluxDB, Elasticsearch, CloudWatch 등도 연결
• 로그/트레이스 상관분석 : Loki, Tempo 같은 툴과 함께 활용 가능

→ 수집된 데이터를 시각화하여 운영 의사결정에 바로 활용할 수 있게 한다.

OpenTelemetry — 데이터 수집의 표준 레이어

최근 몇 년 사이 OpenTelemetry(OTel) 가 CNCF를 중심으로 사실상 업계 표준으로 자리잡고 있다. Prometheus와 Grafana가 각각 “지표 수집/저장”과 “시각화/알림”에 특화되어 있다면, OTel은 Metrics, Logs, Traces를 모두 아우르는 데이터 수집 표준이다.

• 3 Signals 통합 : 메트릭(Prometheus), 로그(Loki/Elastic), 트레이스(Jaeger/Zipkin)로 흩어져 있던 관측 신호를 하나의 SDK/API로 통합.

• 벤더 독립성 : Datadog, New Relic 같은 SaaS를 쓰더라도, OTel로 수집하면 백엔드 전환이 자유로움 → No Vendor Lock-in.

• Collector 아키텍처 : OTel Collector가 데이터를 받아서 Prometheus Remote Write, Kafka, Jaeger, Elastic 등 다양한 백엔드로 팬아웃 가능.

• Prometheus/Grafana와의 궁합 :

  • Prometheus가 OTel Collector에서 노출하는 Exporter 엔드포인트를 스크랩
  • Grafana는 Collector를 직접 붙여서 Metrics/Logs/Traces를 한 화면에 시각화

즉, OpenTelemetry는 데이터 수집의 표준화 레이어, Prometheus는 저장·질의 엔진, Grafana는 시각화/분석 도구로 보완적인 역할을 한다.

👉 앞으로는 “OTel → Prometheus → Grafana”가 현대 관측성 스택의 정석이 될 가능성이 크다. 특히 서비스가 성장하면서 “단순 지표”에서 “로그/트레이스까지 연결된 풀옵저버빌리티”를 원할 때, OpenTelemetry는 필수다.

세 가지의 시너지

• OpenTelemetry: 벤더에 독립적인 데이터 수집
• Prometheus: 안정적인 메트릭 저장 및 분석
• Grafana: 직관적이고 유연한 시각화

이 세 가지를 결합하면, 클라우드 네이티브 환경에서 현대적 관측성(Observability) 스택을 완성할 수 있습니다.

실제 사례: Airbnb의 결제 서비스 모니터링

Airbnb 같은 대규모 플랫폼은 결제 서비스 장애 시 즉각적인 매출 손실이 발생합니다.

• Prometheus가 결제 서비스 노드의 응답시간, 에러율, 메모리 사용량 등을 실시간으로 수집·저장.
• Grafana가 이를 시각화해 운영팀이 한눈에 상태를 확인.
• Prometheus 알람 규칙: 에러율 증가, 지연 시간 급등 시 즉각 Slack/PagerDuty 알림.
• OpenTelemetry는 서비스 전반에서 공통적으로 Metrics/Logs/Traces를 수집, 다른 시스템과 연계 가능.

결과적으로 문제 발생 전에 선제 대응이 가능하고, 비즈니스 연속성을 보장합니다.

(확장 설계) 왜 Thanos/Mimir 같은 LTS와 Kafka가 필요할까?

Prometheus 단독으로도 훌륭하지만, 장기 보관·멀티 클러스터 통합·대규모 트래픽 흡수 같은 요구가 생기면 확장 컴포넌트가 필요하다.

Thanos/Mimir — 장기보관 & 글로벌 뷰

• 장기 보관(수개월~수년): Prometheus 로컬 블록을 오브젝트 스토리지(S3/GCS)에 올려 보관(저렴).
• 글로벌 쿼리/중복 제거: 여러 클러스터·리전에 분산된 Prometheus를 하나의 글로벌 쿼리로 조회, 이중화된 시계열은 dedup.
• 다운샘플링/컴팩션: 오래된 데이터는 5m/1h 등으로 해상도를 낮춰 비용·성능을 균형화.
• 구성 요소(개념): Sidecar(업로드/프록시), Store Gateway(콜드 데이터 제공), Query/Frontend(글로벌 쿼리/캐시), Compactor(다운샘플링), Ruler(장기 규칙/알림).

효과: Grafana 한 화면에서 단기(로컬) + 장기(S3)를 끊김 없이 조회하고, 멀티 클러스터를 한 번에 본다.

Kafka — 버퍼링 & 팬아웃

Prometheus의 표준은 Pull이지만, 폭주 트래픽·다양한 소스·멀티 소비자 요구가 있으면 Kafka를 중간 버스에 둔다.

• 디커플링/버퍼링: 수집 ↔ 저장/소비를 분리해 스파이크와 일시 장애를 흡수.
• 팬아웃: 한 번 들어온 메트릭 스트림을 알림·이상탐지·ML·장기 저장 등 여러 소비자가 공유.
• 적용 패턴(개념):
  • 가장 단순: remote_write → Thanos/Mimir (Kafka 없음)
  • 확장형: OTel Collector → Kafka →(여러 Consumer)→ remote_write(LTS)
• 설계 팁: 파티션 키는 metric_name + 안정 라벨(app/namespace) 중심, 고카디널리티 라벨(user_id/URL full path)은 금지/정규화.

사용했던 모니터링 도구

1. Datadog

직전 회사에서는 지표 모니터링 도구로 Datadog을 사용했다. Datadog은 모니터링, 로깅, APM(Application Performance Monitoring)을 아우르는 SaaS 기반 플랫폼이다.

• 장점

  • 올인원(All-in-one) 플랫폼 : 인프라 모니터링, 애플리케이션 성능 추적, 로그 분석, 사용자 경험 모니터링까지 하나의 콘솔에서 제공한다.
  • 빠른 도입 : 에이전트 설치와 간단한 설정만으로 대부분의 클라우드 리소스와 애플리케이션이 자동 계측된다.
  • 운영 부담 최소화 : 시계열 DB, 저장소, Alertmanager 등 개별 컴포넌트를 직접 관리할 필요가 없고, SaaS이므로 장애 대응이나 확장성 확보도 Datadog이 맡아준다.
  • 통합 생태계 : AWS, GCP, Kubernetes, DB, 메시지 큐 등 수백 개의 서비스와 원클릭으로 연동 가능하다.

• 단점

  • 비용 구조 : 모니터링 지표(metric)의 수와 카디널리티가 늘어날수록 과금이 기하급수적으로 증가한다.
  • 벤더 종속성 : 모든 모니터링이 Datadog SaaS 안에서 이루어지므로, 서비스 성장 시 비용 최적화를 위한 자유도가 떨어진다.

• 왜 사용했는가?

  • 빠르게 모니터링 체계를 구축할 수 있다.
  • 즉시 효과 : 대시보드, 알림, 트레이싱까지 바로 구축할 수 있다.

👉 그러나 서비스가 성장하면서 모니터링 지표 수와 사용자 트래픽이 늘어나자, 비용 부담이 현실적인 한계로 다가왔다. 결국 대규모 서비스를 운영하는 기업들은 SaaS보다는 Prometheus + Grafana 같은 오픈소스 조합을 선택할 수밖에 없다는 걸 체감할 수 있었다.

2. CloudWatch

현재 사이드 프로젝트 ‘필사(Fillsa)’에서는 AWS CloudWatch를 활용해 기본적인 모니터링을 하고 있다.

• 장점

  • AWS 리소스와 네이티브 통합 : EC2, RDS, Lambda, ALB 등 AWS에서 운영되는 모든 서비스가 CloudWatch 메트릭을 기본적으로 노출한다. 별도의 에이전트 설치나 엔드포인트 구성 없이 바로 수집 가능하다.
  • 운영 부담 최소화 : 시계열 DB 운영, 저장소 증설, 인덱스 최적화 등을 신경쓸 필요가 없다. AWS가 백그라운드에서 관리해주므로 개발자는 모니터링 로직이 아닌 서비스 개발에 집중할 수 있다.
  • 비용 효율성 : 기본 메트릭은 대부분 무료 제공되며, 알람 설정 및 단순 대시보드 사용은 추가 비용이 거의 없다. 사이드 프로젝트 같은 소규모 서비스에는 가장 경제적인 옵션이다.
  • 확장성 : 서비스가 확장되더라도 AWS 인프라 위에서라면 CloudWatch 메트릭 수집 범위는 자동으로 늘어난다.

• 단점

  • 지표 표현의 제약 : 시스템 리소스 수준(CPU, Memory, Network, Disk 등) 지표에는 강하지만, 비즈니스 레벨 지표나 애플리케이션 내부 메트릭(API 응답 속도, 에러율 등) 추적에는 한계가 있다.
  • 데이터 보존 및 분석 한계 : 세밀한 시계열 분석(예: PromQL 같은 질의)은 불가능하며, 장기간 데이터는 집계 단위가 거칠어져 정밀한 분석이 어렵다.

• 왜 CloudWatch를 쓰는가?

  • 초기 단계의 요구사항에 부합 : 현재 필사 프로젝트는 트래픽이 크지 않고, 운영 인프라도 단순하다. 따라서 “서버가 다운되기 직전 CPU가 급등하면 알림 받는다” 수준이면 충분하다.
  • 운영 복잡성을 최소화 : Prometheus 같은 시계열 DB를 직접 운영하려면 Exporter 설치, 스토리지 관리, 업그레이드, Alertmanager 설정 등 관리 비용이 커진다. 사이드 프로젝트 단계에서 이런 인프라 운영 리소스를 쓰는 것은 과도하다.
  • TCO(Total Cost of Ownership) 관점의 합리성 : 인건비까지 고려했을 때, CloudWatch는 "Zero Ops"에 가깝다. 즉, 별도의 운영 담당자 없이도 기본적인 모니터링 체계를 유지할 수 있다.

👉 결론적으로, CloudWatch는 작은 규모 서비스에서는 운영 비용을 최소화하면서 안정성을 확보할 수 있는 가장 현실적인 선택이다. 하지만 장기적으로 서비스가 성장하면 애플리케이션 지표, 사용자 지표, 커스텀 메트릭을 추적해야 하고, 이때는 CloudWatch만으로는 부족하다. 그 시점부터는 Prometheus + Grafana 같은 확장 가능한 오픈소스 모니터링 스택으로의 전환이 필요하다.

왜 Prometheus+Grafana가 표준이 되었을까?

다른 도구와 비교해 보면 이유가 명확하다.

• Datadog : 쉽고 강력하지만 비용이 급격히 증가
• New Relic : APM에 강점 있으나 가격·벤더 종속 문제
• Zabbix : 전통적 환경에는 적합하나 클라우드 네이티브 확장성 부족
• Elastic Stack : 로그 분석엔 탁월하지만 운영 난이도 높음

반면 Prometheus+Grafana는:

• 오픈소스 → 비용 효율
• 완전한 데이터 소유권, 벤더 락인 없음
• 쿠버네티스 친화적, 확장성 탁월
• 활발한 커뮤니티

즉, “비용 + 확장성 + 커스터마이즈” 3가지를 동시에 충족한다. 그래서 GitLab, Red Hat 같은 대규모 기업들도 이 조합을 표준으로 사용한다.

앞으로: CloudWatch에서 Prometheus+Grafana로

현재 필사(Fillsa) 사이드 프로젝트에서는 AWS CloudWatch만으로 모니터링을 하고 있다. → CPU 알림 수준의 단순 모니터링이라, 애플리케이션 성능이나 비즈니스 지표를 파악하기에는 부족하다.

앞으로는 Aiva 프로젝트에 Prometheus + Grafana를 적용해보고자 한다.

• 초기: CloudWatch로 최소 리소스만 확인
• 성장: Prometheus로 API 레이턴시/에러율/DB 상태 수집
• 운영: Grafana 대시보드로 운영팀/개발팀 실시간 확인
• 확장: Kafka 파이프라인 + Cold Storage 정책으로 규모 확장

👉 CloudWatch에서 출발해 Prometheus+Grafana로 발전시키는 것이 내 다음 목표다.

결론

• Datadog : 빠른 도입과 운영 편의성, 하지만 비용이 발목
• CloudWatch : 단순 리소스 모니터링은 충분, 애플리케이션 지표는 한계
• Prometheus+Grafana : 현대 모니터링의 표준, 비용 효율·확장성·가시성 모두 충족

책에서 배운 설계안과 업계 사례를 내 경험에 비추어 보니, 내 사이드 프로젝트도 CloudWatch를 넘어서 Prometheus+Grafana로 디벨롭해야겠다는 다짐이 섰다.

참고문서 Medium - Why Prometheus and Grafana Are the Gold Standard for Monitoring Modern Systems

이번 챕터에서 양방향 통신을 위해 웹소켓 서버가 나오는데, 마침 채팅 서비스를 최근에 구현해야 해서 이부분에 대해 학습했는데 타이밍이 ㄷㄷ 1장보단 한큐에 이해가 가진 않았다. 집중력이 떨어진건지,, 한 4번 속독한듯. 레디스 펍/섭 부분은 개념적으로는 이해가 가는데 실제로 어떻게 구현된다는 건지 이해가 부족한것 같아 이부분은 더 찾아봐야 할듯

1단계

기능적 요구사항

• 주변 친구 목록 표시
  • 거리이내
• 주변 친구 목록 갱신
  • 10분 이상 비활성화 사라짐

비기능 요구사항

• 낮은 지연 시간

추정

• 5마일 검색 반경
• 위치 갱신 주기: 30초
• 위치 정보 갱신 QPS: 334k/초

2단계

계획적 설계안

• RESTful API 서버
  • 일반전인 친구 추가/삭제/수정
• 웹소켓 서버
  • 위치 / 주변 친구 활성화
• 레디스 위치 정보 캐시
  • 10분간 비활성화 시 데이터 삭제
• 위치 이동 이력 데이터베이스
  • 주변 친구 표시와 직접 관계된 기능 x
• 레디스 펍/섭 서버
  • 위치 정보 갱신 시 펍/섭 채널에 이벤트 발행

주기적 위치 갱신

1. 모바일 클라이언트가 위치 변경된 사실을 로드밸런서에 전송
2. 로드밸런서는 위치 변경 내역을 해당 클라이언트와 웹소켓 서버 사이에 설정된 연결을 통해 웹소켓 서버로 보낸다.
3. 웹소켓 서버는 해당 이벤트를 위치 이동 이력 데이터 베이스에 저장
4. 웹소켓 서버는 새 위치를 위치 정보 캐시에 보관. TTL 갱신.
5. 웹소켓 서버는 레디스 펍/섭 서버의 해당 사용자 채널에 새 위치 발행 (3 ~ 5 병렬로 수행)
6. 레디스 펍/섭 채널에 발행된 새로운 위치 변경 이벤트는 모든 구독자에게 브로드캐스트. 이때 구독자는 위치 변경 이벤트를 보낸 사용자의 온라인 상태 친구들. 구독자의 웹소켓 연결 핸들러는 친구의 위치 변경 이벤트를 수신.
7. 메시지를 받은 웹소켓 서버, 즉 연결된 웹소켓 서버는 새 위치를 보낸 사용자와 메시지를 받은 사용자 사이의 거리 새로 계산.
8. 7에서 계산한 거리가 검색 반경을 넘지 않는다면, 해당 구독자의 클라이언트 앱으로 위치 정보 변경 내역 전송.

API 설계

1. [서버 API] 주기적인 위치 정보 갱신
2. [클라이언트 API] 클라이언트가 갱신된 친구 위치를 수신하는 데 사용할 API
3. [서버 API] 웹소켓 초기화 API
4. [클라이언트 API] 새 친구 구독 API
5. [클라이언트 API] 구독 해지 API

데이터 모델

• 위치 정보 캐시
  • ‘주변 친구’ 기능은 사용자의 현재 위치만 이용 → 영구저장 x → 캐시 처리
• 위치 이동 이력 데이터베이스

3단계

각 컴포넌트의 규모 확장 전략

• API 서버
• 웹소켓 서버 클러스터
  • 웹소켓 서버는 유상태 → 기존 연결 종료시 주의
• 사용자 정보 데이터베이스
  • 사용자 ID를 기준으로 샤딩
• 위치 정보 캐시
  • 사용자의 위치 정보 → 서로 독립적 → 사용자 ID를 기준으로 샤딩
• 레디스 펍/섭 서버 클러스터
• 레디스 펍/섭 외의 대안
  • 얼랭

친구 추가/삭제

친구가 많은 사용자

주변 임의 사용자

서울시여성가족재단에서 운영하는 스터디에 지원했다.구글 클라우드와 협력해 생성형 AI 분야를 실습까지 해볼 수 있는 좋은 기회였기 때문이다 ! ! ! 마침 대규모 시스템에 관심이 많아 도서관에서 가상 면접 사례로 배우는 대규모 시스템 설계 기초 1권을 읽고 있었는데, 이번 시즌에 2권 스터디를 진행하는 팀이 있는 것을 발견했다. (운명인가ㄷㄷ)

합격 발표날 연락이 없어 탈락했다고 생각했는데, 저녁 늦게 결과가 나왔다. 합격이었다 ~~ (오예) OT에서 팀장님과 팀원분들과 간단히 인사와 자기소개를 나누었는데, 30명이 넘게 지원했다고 한다. 약 3:1 경쟁률을 뚫었다니 더욱 열심히 임해야겠다고 다짐했다 ^___^

[학습흐름]

1. 2회 속독
2. 도식화 요약본 확인
3. 기억나는 내용 작성
4. 부족한 부분 재독
5. 보완

1단계

기능적 요구사항

• 주변 사업장 검색
  • 사용자가 검색 변경 지정 가능한지 (YES)
    • 최대 허용 반경(20km)
    • 검색변경 반경 목록(0.5km, 1km, 2km, 5km, 20km)
  • 주어진 반경 내 정보가 충분하지 여부 → 더 넓혀야 하는지 (NO)
  • 사용자 위치 → 상시 갱신 해야 하는지 (NO, 이동속도가 그렇게 빠르지 않을거라)
• 사업장 정부 추가/삭제/갱신
  • 즉시 반영되어야 하는가 (NO, 다음날 반영가능 계약서상)
• 사업장 정보 조회

비기능 요구사항

• 낮은 응답 지연 → 사용자는 주변 사업장을 신속히 검색 가능해야 한다.
• 데이터 보호 → 사용자 위치는 민감한 정보
• 5k 검색 QPS → 고가용성 및 규모 확장성(인구 밀집 지역 + 트래픽 집중 시간 감당 가능해야 한다)

2단계

API 설계

• 검색 API
• 사업장 정보 관리 API
• 페이지 분할

데이터 모델

• 읽기/쓰기 연산 비율
  • 사업장 정보는 읽기 > 쓰기
  • 읽기 연산이 압도적이므로 관계형 데이터베이스가 적합
• 데이터 스키마
  • business 테이블
  • 지리적 위치 색인 테이블

개략적인 설계 도면

• 로드밸런서
  • 읽기/쓰기 연산 분리
• LBS(위치 기반 서비스)
  • 읽기 요청 서비스
  • QPS 가 높다.
  • 무상태 서비스 → 수평적 규모 확장이 쉽다
• 사업장 서비스
  • 쓰기 요청 서비스
  • QPS가 높지 않다.
  • 고객이 사업장 조회할때 QPS 높아진다.
• 데이터베이스 클러스터
  • 주-부(primary-secondary) 데이터베이스 형태
  • 주 데이터베이스 → 쓰기 요청 처리
  • 부 테이터베이스 → 읽기 요청 처리
  • 복제에 걸리는 시간 지연이 있을수 있다. → 사업장 정보는 실시간 반영 아니라 괜찮

알고리즘

• 해시 기반 방안: 균등 격자, 지오해시, 카르테시안 계층
• 트리 기반 방안: 쿼드트리, 구글 S2, R 트리

→ 지도를 작은 영역으로 분할하고 고속 검색이 가능하도록 색인을 만든다.

가장 널리: 지오해시, 쿼드트리, 구글 S2

• 2차원 검색
• 균등 분할 격자
• 지오해시
  • 격자를 나누어 비트를 하나씩 늘려 재귀적으로 분할해 나간다.
  • 이슈: 격자 가장자리 이슈
  • 구현/사용이 쉽다. 색인 갱신이 쉽다.
• 쿼드트리
  • 특정 기준을 만족할 때까지 2차원 공간을 재귀적으로 사분면 분할(내부/말단 노드)
  • 이슈: 메모리에 쿼드트리 인덱스를 미리 구축해야하고, 이에 시간이 소요된다. → 청/녹배포
  • 인구 밀도에 따라 격자 크기를 동적으로 조정할 수 있다.
  • 지오해시보다 색인 갱신은 까다롭다. (그 부분 다시 구축해야 하니깐)
• 구글 S2
  • 구글맵, 틴더
• 지오해시 vs 쿼드트리

3단계

데이터베이스 규모 확장

• 사업장 정보 테이블
  • 한 서버에 담을 수 없을 수 있다 → 샤딩 적용하기 좋은 후보 (사업장 ID)
• 지리 정보 색인 테이블
  • 지오해시 - 사업장id

캐시

• 캐시 계층 도입 전 정말 필요한가? → 읽기 연산이 하나로 부족하면 도입 ㄱ
• 캐시에서 없으면 디비 읽고 캐시에 추가(정보 업뎃되면 무효화 ㄱ)
• 캐시 키
• 데이터 유형

지역 및 가용성 구역

• 위치 기반 서비스는 여러 지역과 가용성 구역에 설치한다.
  • 사용자와 시스템 사이의 물리적 거리 최소한(미국인 → 미국 센터)
  • 트래픽을 인구에 따라 고르게 분산하는 유연성 확보(일본/한국은 인구 밀도 높다. 별도로 빼기)

결과 필터링

필터링할 데이터도 추가해 두면 됨.

최종 설계 도면

최근 해커톤에 참가하면서, 기획서에 앱 화면 구성(프로토타입)을 함께 제출해야 하는 상황이 생겼다. 아직 디자인이 픽스된 상태는 아니고, 개발 일정도 빠듯한 상황에서 디자인 + 개발 + 프로토타이핑을 동시에 빠르게 해결할 방법이 필요했다.

바로 그때 눈에 들어온 게 Figma Make. 기획서 내용과 스토리보드만으로, 디자인부터 코드까지 한 번에 만들어주는 AI 기능이다. 이걸 제대로 써보니, 상상 이상으로 유용했다.

2. Figma Make란?

Figma에서 최근 공개한 AI 생성 기능 중 하나로,

• 기획 설명
• 스토리보드 이미지
• 간단한 텍스트 프롬프트 만 있으면, 실제 앱 화면을 자동으로 디자인해준다.

심지어 React, HTML 등 실제 코드로 변환까지 가능해, 디자인 → 개발 전환의 간극을 크게 줄여주는 도구다.

3. 내가 활용한 방식

기획서 작성 중, 다음과 같은 방식으로 활용했다:

① 프롬프트 1: 서비스 설명 + 스토리보드

• 어떤 기능을 제공하는지 간략히 설명
• 각 화면(총 4개): 어떤 목적이고, 어떤 요소가 들어가는지 요약 → 이 내용을 기반으로 기초적인 화면 구성과 Flutter 코드를 생성해줌

② 프롬프트 2: 앱 이름 기반 디자인 시스템 적용

• 앱 이름과 성격을 다시 알려주고(앱 명칭 변경이슈로 인해 다시 알려준;;)
• “이 앱에 어울리는 디자인 시스템 몇 개 보여줘”라고 요청 → 디자인 테마를 제안받고, 디자인별 설명과 함께 즉시 화면에 적용해보며 선택 가능 → 무채색 와이어프레임 → 실제 디자인 느낌으로 전환

4. 사용 후기

• 단 3번의 프롬프트만으로

• UI 구성 → 디자인 시안 → React 코드 생성*까지 전 과정을 자동으로 처리할 수 있었다.

• 물론 완성본이 아닌 프로토타입용 퀄리티지만, 화면 구성력과 코드 구조가 너무 괜찮아서 설득력 있는 기획서 작성에 큰 도움이 됐다.

• 결과적으로 이 기획서를 통해 해커톤 예선 통과까지 성공! 이후에는 기획자분이 본격적인 디자인을 진행하고, 나는 그걸 기반으로 Figma Make + MCP + Cursor AI를 연동해 협업형 바이브 코딩까지 진행할 예정이다.

5. 요약 – 이 기능, 언제 쓰면 좋을까?

• 아이디어가 있는데 디자인 인력이 없는 경우
• 빠르게 앱 화면 흐름을 보여줘야 할 때
• 기획자/개발자가 기획-디자인-개발을 혼자 해야 하는 사이드 프로젝트
• 해커톤 등 프로토타입 중심의 데모 제작에 매우 적합

다음 글 예고 ✍

Figma Make가 만들어준 UI 코드를 실제 프로젝트에 어떻게 적용하는지에 대해 다뤄보겠습니다. MCP + Cursor AI 연동 바이브코딩까지 실제 예시와 함께 풀어볼게요!

API를 운영하다 보면 트래픽이 갑자기 몰려 서버에 부하가 걸리는 상황을 종종 겪게 된다. 이럴 때 보통은 코드 레벨에서 캐시를 추가하거나, 비동기 처리로 대응하려고 하지만, 이런 방식만으로는 한계가 있다.
그래서 이번엔 코드가 아니라, 그보다 한 단계 더 높은 레벨(예: 인프라나 API 게이트웨이)에서 어떻게 트래픽을 제어하고 방어할 수 있을지 고민하던 중, API7.ai에서 잘 정리된 아티클을 발견하게 되었다.
Rate Limiting과 Throttling이라는 개념을 중심으로, API를 어떻게 안정적으로 보호하고 남용을 막을 수 있는지를 다루고 있어서, 그 내용을 번역하고 정리해봤다.

✅ 소개

API는 디지털 고속도로와 같으며, 트래픽 규칙 없이 운용되면 서버 과부하, 보안 취약점, 사용자 불만이 발생합니다. Alibaba Cloud의 2023년 설문조사에 따르면 개발자 78%가 API 남용을 주요 보안 문제로 꼽았습니다. 이를 방지하기 위해 사용하는 기술이 바로 Rate Limiting과 Throttling입니다.

✅ 문제: 통제되지 않는 API 트래픽

✅ 용어 정리

📌 Rate Limiting (요청 수 제한)

• 정해진 시간 안에 보낼 수 있는 요청 수 제한
• 예: 분당 100건 요청 허용
• 주요 용도:
  • DDoS 방어 (예: 트위터는 앱당 분당 150만 건 제한)
  • 프리미엄/프리 유저 차등 적용

📌 Throttling (요청 속도 제한)

• 초과 요청을 차단하지 않고 느리게 처리
• 예: 블랙프라이데이처럼 요청이 몰릴 때 점진적으로 응답
• 주요 용도:
  • 트래픽 급증 완화
  • 우선순위 요청(예: 결제 API) 처리

✅ 주요 차이점

✅ 왜 중요한가?

✔ 남용 및 공격 방지

• LinkedIn: 로그인 시도 시간당 5회 제한 → 무차별 대입 차단
• Cloudflare: 2023년 3분기에 1,280만 DDoS 차단

✔ 공정한 사용 보장

• Zoom: 일반 100만 건/월, 기업 1천만 건/월 API 요청 허용
• AWS Lambda: 요청당 과금 → 무제한 사용 시 요금 폭탄 가능

✔ SLA 및 규정 준수

• Shopify: 분당 100건으로 SLA 99.99% 보장

✅ Rate Limiting 전략

✅ 알고리즘 예시

1. Token Bucket

• 일정 수의 토큰을 소비하며 요청 처리
• 토큰은 일정 속도로 리필됨
• 예: Cloudflare → 트래픽 급증에도 일정 처리

2. Leaky Bucket

• 고정 속도로 요청 처리, 넘치면 폐기
• 예: RabbitMQ → 큐 폭주 방지

✅ 구현 시 모범 사례

✅ 실제 사례

✅ 사용 가능한 도구

API Gateway

오픈소스 & 클라우드

✅ 미래 동향

• AI 기반 Throttling: Azure는 ML로 이상 트래픽 탐지
• 예측 기반 자동 조절: Google Cloud AutoML로 트래픽 예측
• 표준화: OpenAPI 문서에 x-rate-limit 같은 확장 필드 사용 증가
• 서버리스 연동: AWS Lambda는 동시 실행 제한을 통해 자동 Throttling 가능

✅ 결론

Rate Limiting과 Throttling은 API 안정성과 보안을 위한 핵심 전략입니다. 올바른 알고리즘 선택, 도구 활용, 정책 설계로 서비스 신뢰성 확보 및 비용 절감이 가능합니다. API 중심 아키텍처가 증가하는 시대에선 필수적인 요소입니다.

프로젝트를 시작한 건 4월. 그리고 드디어! 두달만에 앱을 출시하게 되었습니다!!!!! 중간에 우여곡절도 많았지만, 하나씩 해결해가며 막판 스퍼트를 올린 덕분에 이렇게 출시까지 완주할 수 있었습니다.

시작은 '민음사 일력'에서

처음 앱을 기획하게 된 계기는 '민음사 일력'이었습니다. 작년 말, 민음사 책을 구매하면서 ‘2025 민음사 일력’을 사은품으로 받았고, 매일 좋은 문장을 보며 개인적으로 필사를 하기 시작했습니다.

그러던 중, 민음사에서 '2025 세계문학 일력'을 앱으로 출시한 사실을 알게 되었고, 거기서 제공하는 타이핑 기반의 필사 기능을 보며 이런 생각이 들었죠!

"아, 이렇게 소비자의 니즈를 앱으로 풀어낼 수 있구나."

그게 시작이었습니다. 뚜둥-

시장조사와 차별화 아이디어

'나도 앱을 만들어볼까?'란 생각이 들었고, 같은 주제인 ‘필사’로 시장 조사를 시작했습니다. 이미 많은 필사 앱들이 존재하고 있었지만, 대부분 ‘타이핑’ 방식이었습니다. 그런데 MZ가 아닌? 제게 ‘필사’란 직접 손으로 쓰는 것이란 생각이였죠.

그래서 이런 아이디어가 떠올랐습니다..!

“타이핑 기능 플러스 추가적으로 손으로 직접 필사한 내용을 사진으로 업로드하는 기능을 넣으면, 더 다양한 사용자층에게 어필할 수 있지 않을까?”

이 아이디어를 중심으로 빠르게 목업 화면과 기획서를 만들고, 팀 구성을 시작했습니다.

앱 이름, 그 고민의 끝

앱 이름을 정하는 것도 쉽지 않았다죠.. 한참을 고민하다가 결국 단순하게 ‘필사’로 결정했습니다. 검색하면 무조건 걸리도록! (개발자스러운 발상 😅)

그래도 감성을 담고 싶어서 부제로 ‘Fillsa’를 붙였습니다. 느낌적인 느낌은... 낼 수 있었던 것 같습니다....

정확한 앱 명칭은 '필사 - 하루 한 문장, 나만의 기록' 입니다!

서버: AWS 처음부터 끝까지 직접 구성

이번 기회에 AWS 프리티어를 이용해 처음부터 끝까지 직접 서버를 구성해보았습니다. 책에서만 보던 AWS의 다양한 기능을 실전에 적용해보며 많은 걸 배웠죠.

무엇보다 운영을 고려하다 보니 비용을 가장 신경 썼고, 현재는 고정 IP 비용 정도만 나오며 월 약 $10 수준으로 유지되고 있습니다. (프리티어가 끝나면 비용을 고려해 다른 인프라로 이전할 계획도 있음)

백엔드

빠른 출시를 목표로 했기에, 백엔드는 기존에 사용하던 스택을 그대로 사용했습니다.

• Kotlin
• Spring Boot 3
• MySQL
• JPA 등등

PM 역할을 병행하다 보니 백엔드에 집중을 많이 하진 못한것 같습니다.. 다만!! 이후 버전부터 업데이트를 통해 하나씩 디벨롭해나갈 예정입니다. 재밌겠다~(눈물 스윽)

조심스레.. GitHub 저장소 링크도 남깁니다

PM 업무를 하며 느낀 점

처음엔 목업을 기반으로 디자이너님과 UI 흐름을 맞췄고, 기획서를 나름 꼼꼼히 썼다고 생각했지만… 막상 진행하다 보니 빠진 부분이 계속 생겼습니다.

그래서 플로우차트도 그리고, 앱 흐름을 다시 공유하면서 정리해갔습니다.

이 과정에서 기획자 분들에 대한 리스펙이 생겼고, "협업을 잘하는 개발자란 어떤 사람인가?"란 질문에 대한 답을 나름대로 정의내렸습니다..

협업을 잘하는 개발자란?

• NO보다 긍정적 검토로 결과를 답할 수 있는 개발자
• 새로운 기술과 기능에 대한 거부감이 없는 개발자
• 사용자의 입장과 사업적인 요소를 고려하여 기획적인 부분을 제안할 수 있는 개발자.
• 무엇보다 알잘딱깔쎈(업무공유, 일정공유 항시 하는. 말하지 않아도 결과물을 내오는..)인 개발자

출시를 가로막은 뜻밖의 장벽: 비공개 테스트

앱 출시를 위해선 비공개 테스트를 반드시 거쳐야 합니다. 그런데 조건이 생각보다 까다로웠습니다.

“2주 동안 12명 이상의 테스터가 매일 앱을 사용해야 한다.”

처음엔 네이버 카페를 통해 자발적 참여자를 모집해보려 했지만, 매일 사용해줄 수 있을지 불확실해서 크몽을 활용해보았습니다.

크몽만 믿고 시간을 보내던 어느날 뚜둥!!! 아래와 같은 구글 개발자 콘솔의 오류가 발견되었습니다.

• 시계열 데이터가 이상하게 찍힘
• 사용자 수가 왔다 갔다 함 (1명 → 10명 → 0명)

크몽 작업자분이 최근에도 이런 이슈를 겪은 사례와 무사 통과한 예시를 공유해주셔서 조금은 안심되었습니다.. (하지만 계속 불안에 떨긴함..)

그리고 드디어! 프로덕션 심사를 넣고 12시간도 안 돼서 심사 통과 메일 도착! 😂

이제 다시 시작해보자~~

"출시는 끝이 아니라 시작이다." - 개발자 리다영 -

바로 version 2 개발에 착수할 예정이고, 지속적인 QA를 통해 앱 품질을 향상시켜 나가려 합니다!

무엇보다, 저를 믿고 함께 해준 팀원들에게 무한한 감사를 전합니다. 계속 함께 달려나괍시돠~

마지막으로…

이 글을 보고 있는 당신.. 한 번만 사용해주실 수 있을까요…? (네, 구걸 맞습니다…)

구글 플레이 스토어 앱 소개 홈페이지

"서버 없이도 빠르게 웹페이지 배포하는 방법, 그리고 구글/카카오 간편 로그인 탈퇴 구현 후기까지!"

앱 출시 심사 준비 중, 갑자기 “웹 탈퇴 페이지가 별도로 필요하다”는 게 떠오름. 예전에 회사에서도 비슷한 이슈로 프론트엔드 팀이 급하게 처리하던 기억이 있었는데, 이번엔 그 역할을 내가 하게 됨..

프론트 프로젝트야 React + Vite로 빠르게 만들 수 있지만, 문제는 배포. 서버 띄워야 하나? SSL 인증서는 또 어떻게 하지...? 라는 고민이 시작됨.

그래서 찾아보니 아래의 방법으로 하면 해결 완.

✅ 정적 웹사이트는 S3 ✅ SSL 인증은 CloudFront + ACM ✅ 도메인 연결은 Route 53

덕분에 별도 서버 없이도, 클라이언트만 있는 웹사이트를 바로 띄울 수 있었음. AWS에 한 걸음 더 가까워졌달까? 😅

🔧 구성도 요약

1️⃣ 웹 탈퇴 페이지 프론트 개발

구현한 기능:

1. 간편 로그인 연동 (카카오 / 구글)
2. 백엔드에 탈퇴 API 호출 a. access token 발급 b. user info 조회 -> oauth id 확인 c. 필사 탈퇴처리 로직

✔ 카카오 unlink 처리

카카오는 JavaScript SDK에서 Kakao.API.request({ url: '/v1/user/unlink' })를 호출하면 쉽게 연결을 끊을 수 있음. 그리고 해당 oauth ID로 탈퇴 요청 보내면 끝.

✔ 구글은 다소 복잡...

반면 구글은 https://oauth2.googleapis.com/revoke API를 호출해서 발급된 토큰을 무효화할 수 있지만, 계정 연결 해제는 사용자가 직접 해야 함. 😅

그래서 앱 약관에 소셜계정 연결해제는 직접 해야한다는 문구만 남기고, 실제 연결 끊는 기능은 제외함. 대부분의 앱도 그렇게 하고 있었음.

2️⃣ AWS 인프라 구성 및 배포

📁 S3 정적 웹사이트 설정

1. S3 버킷을 생성하고
2. "정적 웹사이트 호스팅" 옵션 활성화
3. 기본 문서를 index.html로 지정

🛠 프론트 빌드 및 업로드

npm run build  # vite 기준 빌드
aws s3 sync dist/ s3://${탈퇴 도메인}

(디자인 나오기 전 기능 테스트용 화면...개발자의 미감이란..)

🌍 CloudFront 연결

1. 원본에 S3 버킷 연결
2. Viewer Protocol Policy는 Redirect HTTP to HTTPS
3. ACM에서 인증서 발급받고 연결
4. Route 53에서 도메인에 A 레코드 추가 (CloudFront 배포 도메인 alias)

3️⃣ 앱 소개 페이지는 Slash Page로

약관/소개 페이지는 Notion으로 할까 고민하다가 Slash Page라는 서비스를 알게 됨. 완전 신세계.

• 커스텀 도메인 연결 가능 (베타)
• 에디터가 노션처럼 편리함
• 디자인도 깔끔하게 뽑힘

그 외 아래와 같은 다양한 베타테스터 기능들이 있다. 잘 활용하면 별도의 사이트 구축없이 해당 서비스를 이용하면 될듯?

🪧 필사 앱도 곧 출시합니다!

현재 준비 중인 앱 소개는 home.fillsa.store에서 보실 수 있어요. 이 페이지는 Slash Page를 활용해 만들었고, 아직 구축 중이지만 곧 완성될 예정입니다.

6월 중순 출시 예정이니 많관부 🙌

간편 로그인(OAuth2)을 카카오·구글로 연동하면서, 중복되는 코드를 줄이고 프로바이더별 로직을 분리함 특히 탈퇴(연동 해제) 과정이 카카오와 구글이 달라서 이를 어떻게 추상화할지 고민함

1. 간편 로그인 흐름

(자세한 내용은 여기 참고)

1. 사용자가 앱에서 “카카오/구글 로그인” 버튼 클릭
2. OAuth 서버에서 인증 후 code 발급
3. 백엔드 GET /oauth/{provider}/callback?code=…로 code 수신
4. 백엔드에서
   • code → oauth 액세스 토큰 발급
   • oauth 사용자 정보 가져오기
   • oauth token DB 에 저장

2. 로그인 연동: Strategy 패턴으로 공통 로직 묶기

OAuthLoginClient 인터페이스

interface OAuthLoginClient {
  fun getOAuthProvider(): Member.OAuthProvider
  fun getAccessToken(code: String): OAuthTokenInfo
  fun getUserInfo(accessToken: String): OAuthUserInfo
}

• 카카오·구글용 WebClient 구현체가 이 인터페이스를 따릅니다.
• 새 프로바이더를 추가할 때는 이 인터페이스를 구현한 클래스 추가

@Service class GoogleOAuthLoginWebClient : OAuthLoginClient { … }
@Service class KakaoOAuthLoginWebClient  : OAuthLoginClient { … }

OAuthCallbackService: 분기 없이 똑같은 처리

• 로그인 플로우는 카카오/구글 동일함
• oauth token을 DB 에 저장하는 이유 -> google 간편로그인 해제 시 이때 발급받은 refresh token이 필요함

@Service
class OAuthCallbackService(
    private val memberUseCase: MemberUseCase,
    private val tokenUseCase: OAuthTokenUseCase,
    private val clients: List<OAuthLoginClient>
): OAuthCallbackUseCase {

    override fun processOAuthCallback(provider: Member.OAuthProvider, code: String): Long {
        // 1) 클라이언트 조회
        val client = clients
            .firstOrNull { it.getOAuthProvider() == provider }
            ?: throw InvalidRequestException("지원하지 않는 provider: $provider")

        // 2) 코드로 토큰 발급
        val oauthTokenInfo = client.getAccessToken(code)

        // 3) 토큰으로 사용자 정보 조회
        val userInfo = client.getUserInfo(oauthTokenInfo.accessToken)

        // 4) DB에 회원 생성 또는 조회
        val member = memberUseCase.processOauthLogin(userInfo)

        // 5) 발급받은 토큰 DB에 저장
        tokenUseCase.createOAuthToken(member, oauthTokenInfo)

        return member.memberSeq
    }
}

3. 콜백 컨트롤러

@RestController
@RequestMapping("/oauth")
class OAuthCallbackController(
    private val callbackService: OAuthCallbackService,
    ...
) {
    @GetMapping("/{provider}/callback")
    fun callback(
        @PathVariable provider: String,
        @RequestParam code: String,
        response: HttpServletResponse
    ) {
        val memberSeq = oAuthCallbackService.processOAuthCallback(
            provider = Member.OAuthProvider.fromPath(provider),
            code = code
        )
            ...
    }
}

4. 탈퇴(연동 해제) 처리: 프로바이더별로 다른 로직

“탈퇴”라고 해도, 내부 회원 삭제와는 별개로 외부 OAuth 제공자에 연동 해제를 먼저 해야 함. 카카오와 구글이 API 방식이 달라서 이를 중점적으로 서술해봄

4.1 공통 인터페이스

interface OAuthWithdrawalUseCase {
  fun getOAuthProvider(): Member.OAuthProvider
  fun withdraw(member: Member)
}

4.2 서비스

@Service
class OAuthWithdrawalService(
    private val cases: List<OAuthWithdrawalUseCase>
) {
    fun withdraw(member: Member) {
        val useCase = cases
            .firstOrNull { it.getOAuthProvider() == member.oauthProvider }
            ?: error("지원하지 않는 provider: ${member.oauthProvider}")
        useCase.withdraw(member)
    }
}

4.3 카카오 vs. 구글 플로우

@Service
class KakaoOAuthWithdrawalService(
    private val kakaoClient: KakaoOAuthWithdrawalClient
): OAuthWithdrawalUseCase {
    override fun getOAuthProvider() = Member.OAuthProvider.KAKAO
    override fun withdraw(member: Member) {
        // oauth 탈퇴
        kakaoClient.withdraw(member.oauthId)
    }
}

@Service
class GoogleOAuthWithdrawalService(
    private val googleClient: GoogleOAuthWithdrawalClient,
    private val repo: OAuthTokenRepository
): OAuthWithdrawalUseCase {
    override fun getOAuthProvider() = Member.OAuthProvider.GOOGLE

    override fun withdraw(member: Member) {
        // DB의 oauth 토큰 조회
        val token = repo.findLatest(member)
            ?: throw OAuthWithdrawalException("OAuth 정보 없음")

        // refresh token 유효한지 확인    
        if (token.refreshTokenExpiresAt <= LocalDateTime.now()) {
            throw OAuthWithdrawalException("만료된 refresh token, 재로그인 필요")
        }

        // oauth access Token 재발급
        val accessToken = googleClient.getAccessToken(token.refreshToken)

        // oauth 탈퇴
        googleClient.withdraw(accessToken)
    }
}

4.4 컨트롤러·서비스 연결

@RestController
@RequestMapping("/auth")
class AuthController(private val authUseCase: AuthUseCase) {
    @DeleteMapping("/withdraw")
    fun withdraw(
        @AuthenticationPrincipal member: Member,
        @RequestBody request: WithdrawalRequest
    ) {
        authUseCase.withdraw(member, request)
    }
}

@Service
class AuthService(
    private val oauthWithdrawalService: OAuthWithdrawalService,
    private val memberUseCase: MemberUseCase,
    private val redisTokenUseCase: RedisTokenUseCase
): AuthUseCase {
    override fun withdraw(member: Member, request: WithdrawalRequest) {
        // 1) 외부 연동 해제
        oauthWithdrawalService.withdraw(member)

        // 2) 내부 회원 탈퇴
        memberUseCase.withdraw(member)

        // 3) Redis에 저장된 refresh token 삭제
        redisTokenUseCase.deleteRefreshToken(member.memberSeq, request.deviceId)
    }
}

5. 마무리

• 공통 부분을 추상화해서 로직을 하나로 합치고, 유지보수가 용이하도록 구현
• 추상 인터페이스 + 구현체 리스트로 분기처리 하도록 함

OAuth 인증 후 모바일 앱에서 안전하게 사용자 식별 정보를 받아 JWT로 최종 로그인 처리

• OAuth 인증이 끝나면 백엔드가 임시 토큰(UUID)을 발급해 Redis에 저장
• 앱은 딥링크를 통해 임시 토큰만 전달받아, 민감한 인증 코드를 직접 다루지 않음
• 임시 토큰을 검증한 뒤에야 실제 JWT Access/Refresh 토큰을 발급

로그인 플로우

1. 앱 → 브라우저 (OAuth 인증 요청)

• 앱에서 구글/카카오 간편 로그인을 제공
• 로그인 버튼 클릭 시 웹뷰로 동의 화면 이동

2. 브라우저 → OAuth 인증서버

• 사용자가 아이디/비밀번호 입력 및 권한 동의
• 완료되면 OAuth 서버가 redirect_uri(백엔드)로 인가 코드(code) 전달

3. OAuth 서버 → 백엔드 (Callback)

• 백엔드에서 /oauth/{provider}/callback?code={authorization_code} 호출
• 프로바이더별 로그인 로직은 OAuthCallbackService에서 추상화

4. 백엔드: 임시 토큰 생성·저장

1. 받은 code로 OAuth 서버에 토큰 교환(Access/Refresh 토큰 발급)
2. 사용자 정보 조회 후, 회원 가입/로그인 처리
3. UUID 기반 임시 토큰(tempToken) 생성
4. Redis에 아래 형태로 저장

   key   = temp_token:{UUID}
   value = memberSeq
   TTL   = 5분

5. 백엔드 → 앱: 임시 토큰 전달

• response.sendRedirect("{딥링크}?temp_token={UUID}")
• 앱은 딥링크를 받아 내부 로직으로 전달

6. 앱 → 백엔드: 임시 토큰으로 최종 로그인 요청

// 요청 예시
{
"tempToken": "{UUID}",
"deviceId": "디바이스식별자"
}

• deviceId를 함께 보내면 기기별 토큰 관리가 가능

7. 백엔드: 임시 토큰 검증 → JWT 발급

1. Redis에서 getAndDelete("temp_token:{UUID}") 호출
2. 값이 존재하면 memberSeq 획득, 없으면 에러(만료 또는 중복 사용)
3. JwtTokenProvider.createTokens(memberSeq)로 Access/Refresh JWT 생성
4. Redis에 아래 형태로 저장

   key   = refresh:{memberSeq}:{deviceId}
   value = refreshToken
   TTL   = (config에 설정된 기간)

5. 응답으로 토큰 및 회원정보 전송
6. 앱은 받은 JWT를 로컬에 저장하고, 보호된 화면으로 이동하여 로그인 완료

왜 OAuth 콜백에서 바로 JWT를 주지 않고 임시 토큰을 쓰는가?

OAuth 콜백 단계에서 JWT와 회원정보를 바로 내려주지 않고, 임시 토큰(temp token) 만 발급해 앱에서 다시 호출하도록 만든 이유

1. 브라우저 URL 노출 방지

• JWT를 쿼리 파라미터나 리다이렉트 URL로 직접 전달하면
  • URL 히스토리에 남아 악의적 접근에 노출
  • 중간자 공격(MITM) 또는 XSS에 의한 탈취 위험 증가
• 임시 토큰은
  • UUID 형태의 랜덤 값
  • TTL(예: 5분)이 짧음
  • Redis에만 저장 → 노출돼도 즉시 만료

2. 앱↔백엔드 보안 채널 분리

• 콜백: 브라우저/WebView 컨텍스트
• 로그인 API: 네이티브 앱 컨텍스트에서 HTTPS 호출
• JWT를 콜백 URL에 담으면 딥링크 과정에서 또 노출 위험
• 해결책
  1. 콜백 단계에서는 임시 토큰만 전달
  2. 앱에서 임시 토큰 + deviceId를 HTTPS POST로 전송 → 최종 JWT 발급
• 이로써 민감한 JWT 전송 구간을 앱↔백엔드 통신으로 한정, 보안을 강화

3. 디바이스 바인딩 & 토큰 수명 관리

• Refresh Token은 memberSeq + deviceId 조합으로 Redis에 저장하여 특정 기기에서만 유효
• 콜백 단계에선 deviceId가 없으므로
  1. 콜백 → 임시 토큰 발급 (기기 정보 없이)
  2. 앱 → 임시 토큰 + deviceId로 로그인 요청 → “이 기기만 유효한 Refresh Token” 생성
• 이중 단계 처리를 통해 기기별 토큰 관리를 깔끔하게 구현

문제

답

import java.util.ArrayList;
import java.util.List;

class Solution {
    public List<List<Integer>> generate(int numRows) {
        List<List<Integer>> triangle = new ArrayList<>();

        if (numRows == 0) {
            return triangle;
        }

        List<Integer> firstRow = new ArrayList<>();
        firstRow.add(1);
        triangle.add(firstRow);

        for (int i = 1; i < numRows; i++) {
            List<Integer> prevRow = triangle.get(i - 1);
            List<Integer> newRow = new ArrayList<>();

            newRow.add(1);

            for (int j = 1; j < i; j++) {
                newRow.add(prevRow.get(j - 1) + prevRow.get(j));
            }

            newRow.add(1);

            triangle.add(newRow);
        }

        return triangle;
    }
}

해결방안

numRows가 0인 경우 빈값, 1인 경우 1만 list 에 추가해서 반환 그 다음부터 for문으로 리스트를 만들어야 했다. 처음과 끝은 항상 1이 오도록 셋팅하고, 중간에 들어가는 값은 이중for문으로 만들어서 셋팅해주었다.

문제

• 문제 설명

점심시간에 도둑이 들어, 일부 학생이 체육복을 도난당했습니다. 다행히 여벌 체육복이 있는 학생이 이들에게 체육복을 빌려주려 합니다. 학생들의 번호는 체격 순으로 매겨져 있어, 바로 앞번호의 학생이나 바로 뒷번호의 학생에게만 체육복을 빌려줄 수 있습니다. 예를 들어, 4번 학생은 3번 학생이나 5번 학생에게만 체육복을 빌려줄 수 있습니다. 체육복이 없으면 수업을 들을 수 없기 때문에 체육복을 적절히 빌려 최대한 많은 학생이 체육수업을 들어야 합니다.

전체 학생의 수 n, 체육복을 도난당한 학생들의 번호가 담긴 배열 lost, 여벌의 체육복을 가져온 학생들의 번호가 담긴 배열 reserve가 매개변수로 주어질 때, 체육수업을 들을 수 있는 학생의 최댓값을 return 하도록 solution 함수를 작성해주세요.

• 제한사항

전체 학생의 수는 2명 이상 30명 이하입니다. 체육복을 도난당한 학생의 수는 1명 이상 n명 이하이고 중복되는 번호는 없습니다. 여벌의 체육복을 가져온 학생의 수는 1명 이상 n명 이하이고 중복되는 번호는 없습니다. 여벌 체육복이 있는 학생만 다른 학생에게 체육복을 빌려줄 수 있습니다. 여벌 체육복을 가져온 학생이 체육복을 도난당했을 수 있습니다. 이때 이 학생은 체육복을 하나만 도난당했다고 가정하며, 남은 체육복이 하나이기에 다른 학생에게는 체육복을 빌려줄 수 없습니다.

• 입출력 예

• 입출력 예 설명

예제 #1 1번 학생이 2번 학생에게 체육복을 빌려주고, 3번 학생이나 5번 학생이 4번 학생에게 체육복을 빌려주면 학생 5명이 체육수업을 들을 수 있습니다.

예제 #2 3번 학생이 2번 학생이나 4번 학생에게 체육복을 빌려주면 학생 4명이 체육수업을 들을 수 있습니다.

답

import java.util.HashSet;
import java.util.Set;

class Solution {
    public int solution(int n, int[] lost, int[] reserve) {
        Set<Integer> lostSet = new HashSet<>();
        Set<Integer> reserveSet = new HashSet<>();

        for (int l : lost) {
            lostSet.add(l);
        }
        for (int r : reserve) {
            if (lostSet.contains(r)) {
                lostSet.remove(r); 
            } else {
                reserveSet.add(r);
            }
        }


        for (int r : reserveSet) {
            if (lostSet.contains(r - 1)) {
                lostSet.remove(r - 1); 
            } else if (lostSet.contains(r + 1)) {
                lostSet.remove(r + 1); 
            }
        }

        return n - lostSet.size();
    }
}

해결방안

HashSet을 사용해서 여벌을 빌려주면 도난당한자에서 제거하였다. HashSet 데이터셋 할때, 여벌있는자도 도난당한 경우를 생각해서, 포함여부로 도난리스트에서 먼저 제거했다. 그 후 여벌set을 기준으로 for문을 돌려서 도난set을 제거해나갔다.

문제

• 문제 설명

과일 장수가 사과 상자를 포장하고 있습니다. 사과는 상태에 따라 1점부터 k점까지의 점수로 분류하며, k점이 최상품의 사과이고 1점이 최하품의 사과입니다. 사과 한 상자의 가격은 다음과 같이 결정됩니다.

한 상자에 사과를 m개씩 담아 포장합니다. 상자에 담긴 사과 중 가장 낮은 점수가 p (1 ≤ p ≤ k)점인 경우, 사과 한 상자의 가격은 p * m 입니다. 과일 장수가 가능한 많은 사과를 팔았을 때, 얻을 수 있는 최대 이익을 계산하고자 합니다.(사과는 상자 단위로만 판매하며, 남는 사과는 버립니다)

예를 들어, k = 3, m = 4, 사과 7개의 점수가 [1, 2, 3, 1, 2, 3, 1]이라면, 다음과 같이 [2, 3, 2, 3]으로 구성된 사과 상자 1개를 만들어 판매하여 최대 이익을 얻을 수 있습니다.

(최저 사과 점수) x (한 상자에 담긴 사과 개수) x (상자의 개수) = 2 x 4 x 1 = 8 사과의 최대 점수 k, 한 상자에 들어가는 사과의 수 m, 사과들의 점수 score가 주어졌을 때, 과일 장수가 얻을 수 있는 최대 이익을 return하는 solution 함수를 완성해주세요.

• 제한사항 3 ≤ k ≤ 9 3 ≤ m ≤ 10 7 ≤ score의 길이 ≤ 1,000,000 1 ≤ score[i] ≤ k 이익이 발생하지 않는 경우에는 0을 return 해주세요.

• 입출력 예

• 입출력 예 설명 입출력 예 #1

문제의 예시와 같습니다. 입출력 예 #2

다음과 같이 사과 상자를 포장하여 모두 팔면 최대 이익을 낼 수 있습니다.

답

import java.util.Arrays;

class Solution {
    public int solution(int k, int m, int[] score) {
        Arrays.sort(score);

        int maxProfit = 0;
        int n = score.length;

        for (int i = n - m; i >= 0; i -= m) {
            int minScoreInBox = score[i];
            maxProfit += minScoreInBox * m; 
        }

        return maxProfit;
    }
}

해결방안

오름차순으로 정렬한 후, for문을 도는데 뒤에서 부터 m개씩 묶고, score[i]는 묶은 배열중 가장 작은값이기에 * m 을 해줘서 이를 총 합한다.

문제

답

public class TreeNode {
    int val;
    TreeNode left;
    TreeNode right;
    TreeNode() {}
    TreeNode(int val) { this.val = val; }
    TreeNode(int val, TreeNode left, TreeNode right) {
        this.val = val;
        this.left = left;
        this.right = right;
    }
}


class Solution {
    private TreeNode newRoot = null;
    private TreeNode current = null;

    public TreeNode increasingBST(TreeNode root) {
        inOrderTraversal(root);
        return newRoot;
    }

    private void inOrderTraversal(TreeNode node) {
        if(node == null) return;

        inOrderTraversal(node.left);

        if(newRoot == null) {
            newRoot = new TreeNode(node.val);
            current = newRoot;
        } else {
            current.right = new TreeNode(node.val);
            current = current.right;
        }

        inOrderTraversal(node.right);
    }
}

문제해결

• 이진 탐색 트리(Binary Search Tree, BST) 왼쪽 서브트리의 모든 노드들은 현재 노드보다 작다. 오른쪽 서브트리의 모든 노드들은 현재 노드보다 크다.

• 중위 순회(in-order) 트리를 순회하는 방법 중 하나로, 트리의 노드들을 왼쪽에서 오른쪽으로 순서대로 방문하는 방식이다. 이 순회 방법을 사용하면 이진 탐색 트리에서는 노드들이 오름차순으로 방문하게 된다.

- 이진 탐색 트리 구조
    5
   / \
  3   7
 / \   \
2   4   8

- 중위 순회
2 -> 3 -> 4 -> 5 -> 7 -> 8

문제를 해결하기 위해

1. 이진 탐색 트리를 중위 순회한 후,
2. 모든 노드를 오름차순으로 나열하는 새로운 트리를 만들어야 한다. (새로운 트리에서는 각 노드가 오직 오른쪽 자식만을 가지며, 왼쪽 자식은 없다.)

• 새로운 트리 만들기 새로운 트리를 만들기 위해서 어떻게 접근해야 할지 아예 감이 안 잡혀서, gpt한테 힌트를 얻었다. 우선 class 내부에 변수 newRoot를 선언하여 새로운 트리를 선언한다.

• 오른쪽 트리만 있는 구조 만들기 그렇다면 오름차순으로 나열한 오른쪽 트리만 있는 구조는 어떻게 만들어야 할지 또 난관에 봉착했다.

1. current 내부변수 추가 이를 위해 class 내부 변수로 current 를 선언해서, 새로운 노드를 current.right 에만 추가하고, 이를 current로 변경해준다.

2. inOrderTraversal 메서드 내부에 재귀함수 호출 트리 구조에서는 재귀함수를 빼 놓을 수 없는데, 재귀함수를 언제 호출하며, 인자값을 무엇으로 주어주느냐 고민했다. 먼저 오름차순으로 정렬해야 하기 때문에 node.left를 먼저 인자로 넣어주고, 그 후 newRoot/current 를 처리하는 로직을 배치한 후, 마지막에 node.right 를 인자로 넣어서 재귀함수를 또 한번 호출해준다.

3. newRoot/current 내부변수 조작 newRoot 는 최상단 노드로 오름차순 정렬시 첫번째 값이 들어간다. 일단 newRoot의 null 여부로 분기를 가르고, null 인경우 new TreeNode로 값을 생성하고, current 를 newRoot로 할당한다. 만약 newRoot가 null이 아닐 경우, 새로운 트리는 오른쪽 트리만 가지기 때문에, current.right 에 new TreeNode를 추가하고, current 는 current.right 으로 재할당해준다.

회고

트리 구조 문제 좀 풀었다고, 이제 풀수 있을거란 오만한 생각을 함. 계속 새로운 문제를 접하면서 언젠가 능숙하게 풀 수 있는 날이 오기를.. 오늘 문제는 gpt 문제풀이를 보고도 이해하는데 한참 걸렸다. 복습 여러번 해야 할듯 아좌좌~

문제

답

import java.util.ArrayList;
import java.util.List;
import java.util.Stack;

public class TreeNode {
    int val;
    TreeNode left;
    TreeNode right;
    TreeNode() {}
    TreeNode(int val) { this.val = val; }
    TreeNode(int val, TreeNode left, TreeNode right) {
        this.val = val;
        this.left = left;
        this.right = right;
    }
}

class Solution {
    public List<Integer> inorderTraversal(TreeNode root) {
        List<Integer> result = new ArrayList<>();
        Stack<TreeNode> stack = new Stack<>();
        TreeNode current = root;

        while (current != null || !stack.isEmpty()) {
            while (current != null) {
                stack.push(current);
                current = current.left;
            }

            current = stack.pop();
            result.add(current.val);

            current = current.right;
        }

        return result;
    }
}

문제

• 문제 설명

명함 지갑을 만드는 회사에서 지갑의 크기를 정하려고 합니다. 다양한 모양과 크기의 명함들을 모두 수납할 수 있으면서, 작아서 들고 다니기 편한 지갑을 만들어야 합니다. 이러한 요건을 만족하는 지갑을 만들기 위해 디자인팀은 모든 명함의 가로 길이와 세로 길이를 조사했습니다.

아래 표는 4가지 명함의 가로 길이와 세로 길이를 나타냅니다.

가장 긴 가로 길이와 세로 길이가 각각 80, 70이기 때문에 80(가로) x 70(세로) 크기의 지갑을 만들면 모든 명함들을 수납할 수 있습니다. 하지만 2번 명함을 가로로 눕혀 수납한다면 80(가로) x 50(세로) 크기의 지갑으로 모든 명함들을 수납할 수 있습니다. 이때의 지갑 크기는 4000(=80 x 50)입니다.

모든 명함의 가로 길이와 세로 길이를 나타내는 2차원 배열 sizes가 매개변수로 주어집니다. 모든 명함을 수납할 수 있는 가장 작은 지갑을 만들 때, 지갑의 크기를 return 하도록 solution 함수를 완성해주세요.

• 제한사항

sizes의 길이는 1 이상 10,000 이하입니다. sizes의 원소는 [w, h] 형식입니다. w는 명함의 가로 길이를 나타냅니다. h는 명함의 세로 길이를 나타냅니다. w와 h는 1 이상 1,000 이하인 자연수입니다.

• 입출력 예

  Sizes	Result
  [[60, 50], [30, 70], [60, 30], [80, 40]]	4000
  [[10, 7], [12, 3], [8, 15], [14, 7], [5, 15]]	120
  [[14, 4], [19, 6], [6, 16], [18, 7], [7, 11]]	133

• 입출력 예 설명

입출력 예 #1 문제 예시와 같습니다.

입출력 예 #2 명함들을 적절히 회전시켜 겹쳤을 때, 3번째 명함(가로: 8, 세로: 15)이 다른 모든 명함보다 크기가 큽니다. 따라서 지갑의 크기는 3번째 명함의 크기와 같으며, 120(=8 x 15)을 return 합니다.

입출력 예 #3 명함들을 적절히 회전시켜 겹쳤을 때, 모든 명함을 포함하는 가장 작은 지갑의 크기는 133(=19 x 7)입니다.

답

class Solution {
    public int solution(int[][] sizes) {
        int maxWidth = 0;
        int maxHeight = 0;

        for (int[] size : sizes) {
            int w = size[0];
            int h = size[1];

            if (w < h) {
                int temp = w;
                w = h;
                h = temp;
            }
            maxWidth = Math.max(maxWidth, w);
            maxHeight = Math.max(maxHeight, h);
        }

        return maxWidth * maxHeight;
    }
}