서비스

🧾 개요

ZARO는 자취생을 위한 후기, 팁, 질문을 나눌 수 있는 게시판 중심의 커뮤니티 서비스로, 게시판, 댓글, 프로필, 지도 등 다양한 기능을 제공합니다.

🎯 배경

1인 가구, 특히 자취인은 식사·소비·외로움 등 다양한 문제에 직면해 있지만, 이를 통합적으로 다루는 서비스는 없었습니다.

우리는 자취 커뮤니티 2,000개 데이터를 분석하고 자취인의 삶을 살펴본 결과, 정보 접근성 부족, 실질적인 해결 어려움, 소통의 단절이라는 문제를 발견했습니다.
이에 따라 자취인의 경험과 연결을 하나의 플랫폼으로 통합하는 커뮤니티 서비스를 기획하게 되었습니다.

✨ 주요 기능

홈

게시판

게시글, 댓글

프로필 변경

• 회원 기능: 이메일 가입, 카카오 로그인, 비밀번호 재설정, 휴면/탈퇴 처리
• 커뮤니티: 게시판, 댓글/좋아요/신고, 게시글 작성 및 검색 기능
• 프로필: 내 활동(글/댓글/좋아요), D-day, 팔로우, 즐겨찾기 관리
• 장소 탐색: 위치 기반 장소 조회, 메모 작성, 즐겨찾기 및 그룹 관리
• 기타: 실시간 알림, 인기 게시글/장소, 키워드·카테고리 검색

🎥 시연 영상

ZARO 서비스 시연 영상 유튜브에서 보기

• 페르소나 3인 시나리오에 따른 시연

기술

🗃️ ERD

• 사용자를 중심으로 기능과 책임이 명확하게 나뉘는 구조로 설계
• 게시글, 댓글, 좋아요, 신고 등의 커뮤니티 기능
• 팔로우, 알림 등 소셜 기능이 연결
• 장소 즐겨찾기, 그룹과 장소는 위치 기반 탐색 기능 담당
• 휴면 로그, 비밀번호 재설정, 이메일 인증 토큰 등은 별도 테이블로 관리해 운영과 보안을 분리

🏗️ 기술 아키텍처

• Jenkins에서 Docker 이미지 빌드 및 app.tar 생성 → 메인 서버에서 실행
• 빌드 시점에만 서브 서버로 프록시 전환, 빌드 완료 후 다시 메인 서버로 전환하여 무중단 배포 수행
• 이미지 파일은 S3에 저장되며, CloudFront를 통해 클라이언트에 전달
• Redis, Elasticsearch는 메인 서버의 Docker 컨테이너 내부에 구성, 서브 서버는 메인 서버의 EC2 내부 IP를 통해 해당 서비스에 접근하여 API 연동을 유지

🤼‍♀️ 기술적 도전 & 트러블 슈팅

운영을 고려한 회원 상태 관리 정책 수립 및 인증 흐름 구성

문제 1

• 커뮤니티 특성상 다양한 회원 상태(PENDING, ACTIVE, DORMANT, DELETE)를 고려해야 했고, UX 및 법적 요건(이메일 인증, 휴면 처리 등)도 함께 반영해야 했습니다.

문제 2

• 초기 탈퇴 회원의 정보를 30일 이후 DB에서 삭제하는 것으로 구현했으나 데이터 크기가 크지 않고, 실무에서도 n년 보관을 하는 것으로 알게되어 어떤 정책으로 구성할지 결정해 수정 구현이 필요했습니다.

문제 3

• DORMANT 전환 30일 전 메일 안내 시, 로그인 활동으로 lastLoginAt이 갱신되더라도 이전 발송 이력을 기준으로 재발송되지 않아 안내 메일 누락이 발생할 수 있었습니다.

로직 고민 및 결과 1

• 메일 인증 전 PENDING 회원 처리
  • 회원가입 시 이메일 인증을 완료하지 않은 회원을 PENDING 상태로 저장
  • 인증 완료 전이라면 1일 후 자동 삭제되도록 스케줄러 구성
  • 동일 이메일+닉네임의 재가입 요청이 있을 경우, “이미 가입된 계정입니다. 인증 메일을 다시 보냈습니다.” 식의 UX 메시지 처리
• 6개월 미 접속 DORMANT 회원 처리
  • 휴면 이전 회원 공지 필요 (법적 이슈) - 휴면 전환 30일 전 안내 메일 발송 스케줄러 처리
    • JavaMailSender, MimeMessage 를 활용해 HTML 템플릿 활용 메일 전송
    
  • 로그인 시 마지막 접속 시각(lastLoginAt)을 기준으로 6개월 이상 미접속 회원은 DORMANT 전환
  • 이후 6개월 동안 추가 미접속 시 DELETE 상태로 전환 (soft delete)
  • 로그인 시 DORMANT 상태일 경우 자동 활성화 처리 로직 추가
  

  휴면 상태 로그인 전, 후

해결 2

• 탈퇴 DELETE 회원 처리
  • 이전: 탈퇴 30일 후 DB 정보 삭제
    • 탈퇴 후 정보 삭제시 게시글, 댓글 유지가 어려움
  • 개선: 탈퇴 30일 후 익명화 처리
    • 법적 문제 해결, 운영시 필요 데이터 활용 용이

해결 3

• 휴면 안내 메일 중복 및 누락 방지
  • 현재 회원의 lastLoginAt 기준으로 5개월이 경과시 메일이 발송 되는 스케줄러를 구현
    • 5개월 경과 시점부터 매일 발송되기에 DormancyNoticeLog 테이블 생성으로 메일 전송 유무 저장
    

    휴면 스케줄러 및 repository query 변경 전, 메일 발송 누락 발생

  • 휴면 해제 후 lastLoginAt 변경, 이후 비로그인 5개월 경과 후 DormancyNoticeLog에 메일 전송 이력 존재로 메일 발송이 누락
    • 휴면 안내 메일 발송시 DormancyNoticeLog 테이블에 기준이 되는 lastCheckedLoginDate 시점을 함께 저장
  • 매일 스케줄러 실행 시, 현재 회원의 lastCheckedLoginDate 기준으로 5개월이 경과하고 해당 기준의 발송 이력이 없을 경우에만 메일 발송
    

    휴면 스케줄러 및 repository query 변경 후, 메일 중복 및 누락 해결

  • 이를 통해 로그인 등 행동 변화로 시간이 갱신되어도, 기준 시점 단위로 발송 이력을 관리하여 동일 기준으로의 중복 발송을 막고, 다음 기준점으로의 누락도 방지

배포 자동화 및 비용 효율을 고려한 무중단 배포 파이프라인 구축

문제 1

• Jenkins를 로컬 환경에서 운영 중이라 팀원들이 접근 및 빌드 상태 확인이 불가능했고, 팀 기반의 공동 배포/관리 체계가 필요했습니다.

문제 2

• AWS 비용을 고려한 무중단 배포를 구성하는 것을 목표로 했습니다.
• 일반 Blue-Green 무중단 배포를 구성 했으나, Main 서버가 블루일 때 빌드를 하면서 컨테이너가 내려가 Sub 서버도 통신이 불가능해지는 문제가 발견되었습니다.

접근 및 해결 1

• Jenkins 서버 이관 및 팀 기반 운영 환경 구성
  • Jenkins를 EC2 서버로 이전하고, SCM 연동(GitHub) 기반으로 파이프라인 관리
  
  • Jenkinsfile을 GitHub에 버전 관리하여 변경 이력을 공유
  • 사용자 계정을 추가하여 팀원 모두가 빌드 결과 및 상태 확인 가능하도록 설정(Role-Based Authorization Strategy 플러그인)
  
  

접근 및 해결 2

• Blue-Green 기반의 Hot Standby 방식의 Main/Sub 서버 무중단 배포 구성

  • 비용 효율을 고려해 프리티어 환경으로 시도했으나, 메모리 부족으로 한단계 높은 t2.micro 서버(Sub 서버)를 활용, Main 서버는 빌드 + Docker 이미지 생성, Sub 서버는 이미지 전달 후 실행 전용 서버로 역할 분리 (동일 스펙 서버 2대 구성 대비 약 76% 비용 절감)
  • Nginx 프록시 설정을 통해 현재 운영 서버를 기준으로 Main↔Sub 전환 구조 구현
  
  • 최초 일반 Blue-Green으로 시도 했으나 Main 서버가 블루일 때 빌드를 하면서 컨테이너가 내려가는 문제가 있어 Main 서버에서 빌드를 할 때에만 Sub 서버로 전환하는 방식을 선택
  
  • 배포 스크립트 흐름:
    
    1. 현재 운영 서버 확인
    2. Main 서버일 경우, Sub 서버로 프록시 전환
    3. Main 서버에서 빌드 및 이미지 생성 → Main 서버에서 실행
    4. Main 서버로 프록시 전환 후 Sub 서버로 새로운 이미지 전송 및 실행
  • docker system prune, 상태 기반 토글 스크립트 등으로 디스크 용량 및 오류 복구 로직 함께 구성

🔗 배포 관련 다른 트러블슈팅 |

• Jenkins + Docker 기반 배포 자동화 & DooD 구성 트러블슈팅
• Sub 서버 Redis 연결 트러블슈팅
• Jenkins 동시 빌드 문제 해결

📚 Learning Point

• 운영 관점의 백엔드 아키텍처 설계 경험
  • 인증/인가 시스템부터 상태 기반 회원 관리, 배포까지 서비스 운영 전반을 고려한 설계와 구현을 직접 주도하며, 백엔드 엔지니어로서의 실질적인 시스템 운영 역량을 기를 수 있었습니다.
• 정책 중심의 로직 구성과 코드 구조화 경험
  • UX·법적 요건을 함께 고려한 회원 상태 관리 정책을 설계하고, 인증 메일 발송/휴면 처리/탈퇴 처리 등 다양한 흐름을 스케줄러와 연계하여 자동화하면서, 정책 단위로 책임이 분리된 설계를 실제로 적용해볼 수 있었습니다.
• 실제 사용자 흐름 기반 API 설계와 프론트 협업
  • 프론트엔드 요청에 따라 직접 개발하지 않은 기능도 빠르게 파악하고, 원하는 동작을 구현하도록 API 응답 구조를 수정하며 사용자 시나리오에 적합한 문제 대응 능력을 키울 수 있었습니다.
• 비용 효율성과 확장성을 고려한 배포 환경 구축
  • Jenkins 기반 CI/CD 파이프라인과 무중단 배포 구조를 직접 구성하며, 리소스 최적화와 안정성을 고려한 운영 설계 경험을 쌓을 수 있었습니다.

🔗 GitHub | even-zaro-back
🔗 배포 링크 | ZARO - 25.06.30 인스턴스 종료로 기능 사용 불가

🔗 기타 트러블슈팅 |

• 서버 도메인 스웨거 API 실행 불가
• @EntityGraph로 N+1 문제 해결하고 쿼리 수 줄이기