SIC Club Portal

프로젝트 개요

대학 동아리 운영을 위한 클럽 포털 웹 서비스.

투자 보고서가 네이버 카페에 분산되어 있고,
출석 또한 수기로 관리되어 누락되는 문제가 반복되는 상황이었습니다.

이를 해결하기 위해 웹 서비스를 직접 제안했고,
14–15명(FE/BE/AI/Design) 팀을 구성하여 프로젝트를 리딩했습니다.

서비스 기획부터 협업 구조 설계, 인프라 구축 및 배포까지 전 과정을 담당했습니다.

항목	내용
Stack	React, Vite PWA, Spring Boot, PostgreSQL, Redis, Docker(Compose)
DevOps	GitHub Actions, JaCoCo, Jira
Cloud	AWS (EC2, S3, CloudFront, RDS, IAM, EventBridge, Lambda)
팀 규모	15명 (FE / BE / AI / Design)
담당 기간	2025.09(개발 시작) ~ 2025.11(후임 인계)

초기에는 FE와 BE를 역할 기준으로 분리해 스프린트를 진행했습니다.

하지만 프론트엔드는 API가 준비되어야 테스트가 가능했기 때문에
백엔드 작업 상태를 알기 어려워 개발이 지연되는 문제가 발생했습니다.

또한 역할 단위로 작업이 분리되면서
전체 기능 단위의 진행 상황을 추적하기 어려운 구조였습니다.

이 문제를 해결하기 위해
FE/BE 분리 구조를 기능 단위 스프린트로 재설계했습니다.

각 기능마다 프론트엔드와 백엔드를 함께 묶어
API 준비 상태를 기준으로 개발이 진행되도록 구조를 변경했습니다.

또한 Jira와 GitHub를 연동하여
이슈 → PR → 배포 흐름을 추적할 수 있도록 협업 프로세스를 정리했습니다.

→ 기능 단위로 개발 흐름이 정리되며
팀 내 협업 효율과 작업 가시성이 개선되었습니다.

→ 병합 단계에서 오류를 사전에 검출하고
안정적인 배포가 가능한 구조를 구축했습니다.

학업과 병행하는 환경에서 스프린트 일정이 지연되는 문제가 발생했습니다.

MVP 완성을 위해 테스트 기준을 일시적으로 완화하고
기능 개발 중심으로 전략을 전환했습니다.

대신 서버 로그를 직접 분석하며 오류 원인을 파악하고
FE-BE 간 API 해석 문제를 정리하여 반복 이슈를 줄였습니다.

초기 EC2 t3.micro 환경에서
Spring Boot 컨테이너 실행 시 서버가 응답 불가 상태에 빠졌습니다.

SSM과 직렬 콘솔 접근이 모두 차단된 상황에서
인스턴스 로그와 free -h 실측을 통해 메모리 부족을 원인으로 특정했습니다.

이후 t3.medium으로 사양을 변경하고
EBS에 1GB swap 영역을 추가하여 메모리 급증 상황에서도 안정적으로 동작하도록 개선했습니다.

→ 해당 경험을 기반으로 인프라 운영 기준을 정리했습니다.

서비스 기획부터 협업 구조 설계, 핵심 API 구현, 인프라 구축까지 팀의 개발 생산성과 배포 안정성을 높이는 역할을 담당했습니다.
스프린트 구조 재설계, 품질 기준 수립, 인프라 구축을 통해
서비스가 실제로 배포되고 운영되는 환경을 만들었습니다.