🏗️ 인프라 아키텍처 스터디 (Season 1)

"당신의 서비스는 안녕하십니까? 내 서버가 터진다면 그 이유는 무엇일까요?"

단순히 기능 구현을 넘어, High Availability, Scalability 인프라 아키텍처를 설계하고 검증하는 스터디입니다.

1. 🎯 스터디 개요 및 목표

개요

많은 개발자가 "사용자가 많아지면 서버를 늘리면 되지"라고 생각합니다.

하지만 "얼마나 많아졌을 때, 몇 대를, 어떤 기준으로 늘릴 것인가?" 에 대한 대답은 명확하지 않은 경우가 많습니다.

이 스터디는 현재 운영 중이거나 개발했던 프로젝트의 인프라를 진단하고, **구체적인 수치(Traffic Estimation)**를 근거로 개선안을 도출하는 과정을 훈련합니다.

우리의 목표

• SPOF(단일 실패 지점) 제거: 서버 한 대가 죽어도 서비스가 중단되지 않는 고가용성 아키텍처 설계.

• 근거 있는 설계: "그냥 좋다니까" 쓰는 기술이 아니라, "예상 트래픽이 RPS 2,000이므로 Redis가 필요하다" 는 식의 논리적 근거 마련.

• Trade-off 분석: 비용, 관리 복잡도, 데이터 정합성 등 기술 도입에 따른 반작용을 이해하고 방어.

2. 📅 주차별 커리큘럼 (4 Weeks)

매주 정해진 주제에 맞춰 자신의 아키텍처를 분석하고 개선안을 발표합니다.

주차 주제 핵심 내용(예시) 1주차 아키텍처 진단 & SPOF 찾기

• AS-IS 아키텍처 그리기 (Web-WAS-DB 구조)
  
• "지금 당장 터진다면 어디가 터질까?" (SPOF 분석)
  
• 기본적 이중화(Failover) 전략 수립

2주차 용량 산정(Capacity Planning) & DB 전략 - [핵심] 예상 사용자 수(DAU) 기반 RPS/데이터 용량 추산

• 산정된 수치를 근거로 DB 구조(Replication, Sharding) 결정
  
• "DB가 죽었을 때 데이터는 안전한가?" (Backup/Recovery)

3주차 확장성(Scalability) & 배포 전략

• Scale-up vs Scale-out 의사결정
  
• 트래픽 폭주에 대비한 캐싱(Redis) 및 비동기 큐(Kafka/MQ) 도입
  
• 무중단 배포 전략(Rolling, Blue/Green) 설계

4주차 최종 아키텍처 방어 & 회고 - 최종 TO-BE 아키텍처 리뷰

• 초기 설계 대비 비용/복잡도 변화 분석
  
• "내일 트래픽이 10배 뛴다면?" 시나리오 시뮬레이션

3. 📝 진행 방식 및 규칙 (Rule)

매주 스터디원은 아래 3단계 프로세스를 거쳐 발표 자료를 준비해야 합니다.

Step 1. 시각화 (Visualization)

• 모든 발표에는 아키텍처 다이어그램이 포함되어야 합니다.

• 툴 권장: Draw.io, Eraser.io, PPT 등

• 서버, DB, 로드밸런서, 외부 API 등 구성 요소를 명확히 표기합니다.

Step 2. 수치화 (Quantification) - 2주차부터 필수

• "사용자가 많을 것 같아요"라는 모호한 표현은 지양합니다. 페르미 추정을 통해 구체적인 숫자를 제시해야 합니다.

[포함 항목(예시)]

가정: 목표 DAU, 1인당 평균 요청 수, 피크 시간대 집중률

결과: 평균 RPS, 최대(Peak) RPS, 일일 데이터 적재량

판단: "Peak RPS가 000이므로, 톰캣 1대로는 처리가 불가능하여 3대로 증설함."

Step 3. 토론 및 방어 (Defense)

• 발표 후 스터디원들은 '공격수'가 되어 아키텍처의 허점을 질문합니다. (비난이 아닌 건설적인 비판)

"Redis가 죽으면 DB로 요청이 쏠려서 같이 죽지 않을까요?"
"Master DB 장애 시 Slave 승격은 수동인가요, 자동인가요?"
"이 구조라면 AWS 비용이 너무 많이 나올 것 같은데, 비용 최적화 방안은?"

4. 🗣️ 제출 및 진행 방법 (GitHub Discussions)

Step 1. 발표 자료 업로드 (스터디 전) 매주 정해진 마감 시간 전까지 ISSUE 탭의 해당 주차 [1주차] 머리글을 달아 글을 작성합니다.

제목 양식: [1주차] 이름 - 주제/프로젝트명 예시: [1주차] 홍길동 - 선착순 예매 시스템 아키텍처 진단
본문 내용: 필수 템플릿(아키텍처 이미지, 트래픽 계산 근거, 주요 고민 등)을 포함하여 작성합니다.

Step 2. 온라인 토론 및 질의응답 (스터디 기간 중)
스터디원은 다른 참여자의 글을 읽고 최소 1개 이상의 질문이나 피드백을 댓글로 남겨야 합니다.
단순한 "좋아요"보다는 "왜?" 를 묻는 질문을 권장합니다.

💬 "Redis를 굳이 도입하신 이유가 Peak 트래픽 때문인가요, 아니면 응답 속도 때문인가요?" 💬 "WAS가 2대일 때 세션 정합성은 어떻게 해결하셨나요?"

Step 3. 오프라인/온라인 미팅 (스터디 당일) 작성된 글을 화면에 띄워놓고 발표를 진행합니다. 댓글로 달린 질문들에 대해 작성자가 답변(방어)하며 심도 있는 토론을 이어갑니다. 토론 후 결론이나 수정된 아키텍처가 있다면, 해당 글의 댓글이나 본문 업데이트로 기록을 남깁니다.

5. ✅ 참여 전 준비사항

• 본인이 아키텍처를 개선해보고 싶은 프로젝트 하나 선정 (토이 프로젝트, 실무 프로젝트 무관)

• 현재 상태의 인프라 구조를 설명할 수 있는 도메인 지식

• 열린 마음으로 피드백을 주고받을 태도

📢 Code of Conduct

근거 없는 비난 금지: "이건 별로네요" 대신 "이 방식은 ~한 비용이 발생할 것 같은데 어떻게 생각하시나요?"라고 질문합니다.

보안 주의: 실무 프로젝트를 가져올 경우 민감 정보는 반드시 마스킹 처리합니다.