종합 프로젝트 회고 (1/7~1/27)

📋 프로젝트 개요

프로젝트명: 대용량 통신 요금 명세서 및 알림 발송 시스템
기간: 2026년 1월 7일 ~ 1월 27일 (3주)
팀 구성: 6명
역할: 배치 시스템 개발 리드, 사용량 모니터링 구현

🎯 프로젝트 목표

월말 기준 수십만~수백만 건의 청구 데이터를 안정적으로 처리하고, 고객에게 정확한 요금 명세서와 알림을 발송하는 시스템 구축

📅 주차별 진행 상황

1주 차 (1/7~1/11): 설계 및 계획

요구사항 분석 및 구현 범위 확정
ERD 설계 및 API 명세서 작성
마이크로서비스 아키텍처 확정
역할 분담 및 개발 일정 수립

2주 차 (1/12~1/17): 핵심 기능 개발

담당 도메인 개발 집중
정기적인 코드 리뷰 진행

3주 차 (1/20~1/24): 통합 및 최적화

서비스 간 통합 테스트
부하 테스트 및 성능 튜닝
재실행 시나리오 검증

4주 차 (1/25~1/27): 배포 및 마무리

GCP Cloud Run 배포
Cloud Scheduler 설정
운영 매뉴얼 및 발표 자료 작성

💼 나의 기여

1. 월 청구서 생성 배치 시스템 구현

Spring Batch 기반 대용량 정산 배치 설계 및 구현
장애 발생 시 실패 지점부터 재시작 가능한 구조 설계
Chunk 기반 트랜잭션 처리로 안정성 확보

2. Batch 도메인 API 구현

배치 실행 및 모니터링 API 개발

배치 메타데이터 관리 및 실행 이력 조회 기능

3. 사용량 모니터링 API 및 UI 구현

실시간 데이터 사용량 조회 기능
사용자 친화적인 모니터링 대시보드 개발

4. 인프라 아키텍처 설계 참여

마이크로서비스 구성 및 역할 정의
Observability 스택 구축 (Grafana, Prometheus, Loki, Tempo)

🛠 기술 스택 및 선정 이유

핵심 기술

Spring Batch

채택 이유: 대규모 데이터 처리의 안정성

비교 항목	단순 스케줄러 기반 처리 (Cron + JPA / JDBC )	Spring Batch 기반 배치 처리
장애 복구	전체 재실행	실패 지점부터 재시작
트랜잭션 관리	수동 관리 필요	Chunk 기반 자동 처리
중복 방지	직접 구현	ExecutionContext 기반 관리
운영 가시성	별도 구축 필요	실행 이력 자동 제공
확장성	구현 난이도 높음	Partition/Parallel Step 지원

핵심 판단: 월말 수십~수백만 건의 청구 데이터를 처리하며,
장애 발생 시에도 데이터 정합성을 보장해야 하는 요구사항에 Spring Batch가 최적

Cloud Scheduler

채택 이유: 인프라 의존성 감소 및 유지보수성 향상

Spring Boot 내장 스케줄러 대신 Cloud Scheduler 채택
정산 배치와 데이터 수집 배치 모두 동일한 스케줄링 방식 적용
인프라 레벨에서 스케줄 관리로 애플리케이션 독립성 확보

Cloud Tasks (Queue)

채택 이유: 동시성 제어 및 안정성 향상

초기 설계: Cloud Function → Batch 직접 호출
문제 발견: 정산 배치와 데이터 수집 배치의 동시 DB 접근으로 병목 발생
해결책: Cloud Function → Cloud Tasks → 순차적 배치 실행
결과: DB 접근 경합 해소 및 안정적인 배치 처리

협업 도구

버전 관리: Git, GitHub (PR 기반 코드 리뷰)
CI/CD: GitHub Actions
문서화: Notion (기술 문서, 회의록, 일정 관리)
커뮤니케이션: Slack
이슈 트래킹: Jira
API 문서: Swagger/OpenAPI

Observability Stack ( 모니터링 )

Grafana Alloy: OTLP Collector (텔레메트리 수집)
Grafana: 통합 대시보드
Prometheus: 메트릭 저장 및 쿼리
Loki: 로그 수집 및 검색
Tempo: 분산 트레이싱

🎨 협업 체계

일일 협업

오전 스탠드업: 당일 진행 계획 및 협업 요청 공유
오후 리뷰: 진행 상황 점검 및 이슈 해결

주간 회고

매주 금요일 팀 회고
개선점 도출 및 다음 주 계획 수립

코드 품질 관리

모든 PR은 최소 1명 이상 승인(Approve) 필수
코드 리뷰를 통한 지식 공유 및 품질 향상

문서화

Notion에 기술 결정 사항 및 회의록 기록
모든 의사결정 과정 투명하게 공유

🔧 주요 기술적 도전과 해결

1. 단일 Step → PartitionStep 전환으로 성능 개선

문제점

단일 Step으로 수백만 건 처리 시 처리 시간 과다

해결책

PartitionStep 도입으로 병렬 처리 구현
데이터를 파티션 단위로 분할하여 동시 처리

결과

처리 시간 대폭 단축
확장성 확보

2. Page Size 및 Chunk Size 최적화

문제점

부적절한 청크 크기로 인한 메모리 이슈 및 성능 저하

해결책

다양한 Page Size, Chunk Size 조합 테스트
Sweet Spot 탐색을 통한 최적값 도출

결과

메모리 효율성 및 처리 속도 모두 개선
안정적인 배치 운영 기반 마련

3. SQL 쿼리 최적화

기존 방식

-- CASE WHEN 사용
SELECT 
  SUM(CASE WHEN condition THEN amount ELSE 0 END) as total
FROM usage_data;

개선 방식

-- FILTER 절 사용
SELECT 
  SUM(amount) FILTER (WHERE condition) as total
FROM usage_data;

효과

쿼리 실행 계획 개선
데이터베이스 부하 감소
처리 속도 향상

✅ 잘한 점 (Keep)

1. 철저한 요구사항 분석과 설계

상황: 복잡한 도메인 특성상 구현 범위 설정이 어려움
접근: 전체 팀원이 참여하는 기획 및 설계 세션 진행
효과:
- 각자의 개발 방향 공유 및 합의
- 서로의 부족한 부분을 보완하며 시너지 창출
- 원활한 개발 진행

2. 체계적인 일일 커뮤니케이션

오전 미팅: 금일 작업 계획 공유 및 협업 요청
오후 미팅: 진행 상황 점검 및 기술적 고민 공유
효과:
- 팀원 간 진행 상황 실시간 파악
- 즉각적인 협업 및 문제 해결
- 초기 부담감 → 생산적인 커뮤니케이션 문화로 정착

3. 모듈화된 Repository 구조

구조: 각 도메인별 독립적인 Repository + Template Repository
효과:
- 도메인별 독립적인 패키지 컨벤션 적용 가능
- 명확한 책임 분리
- 협업 시 충돌 최소화

4. Jira를 통한 체계적인 프로젝트 관리

활용 방법:
- 티켓 기반 작업 관리
- Story Point를 통한 작업 시간 추정
- 하위 태스크와 브랜치 연동
효과:
- 팀원 작업 현황 시각적 파악
- 효율적인 일정 관리
- 명확한 작업 추적성

5. 버전별 점진적 개발 전략

접근:
- 설계 단계: 확장된 최종 버전 구상
- 개발 단계: 최소 기능(MVP) 우선 구현 후 점진적 확장
효과:
- 명확한 우선순위 설정
- 리스크 관리
- 지속적인 개선 가능성 확보

6. 코드 리뷰 문화 정착

규칙: 모든 PR은 최소 1명 이상 Approve 필수
멘토 피드백: "실무에서 큰 차이를 만드는 습관"
효과:
- 코드 품질 향상
- 지식 공유 및 팀 역량 향상
- 버그 조기 발견

7. 테스트 문서화

🤔 아쉬운 점 (Problem)

1. 제한적인 코드 리뷰 범위

문제: 시간 부족으로 배치 도메인 외 다른 팀원 코드 리뷰 미흡
원인: 촉박한 일정과 예상치 못한 이슈 대응
영향: 전체 시스템에 대한 이해도 및 협업 품질 저하

2. Confluence Wiki 작업 미완료

계획: 설계/개발/테스트 단계별 문서화
현실: 일정 압박으로 미진행
영향: 지식 체계화 및 인수인계 자료 부족

3. 기술 선택에 대한 적극적 커뮤니케이션 부족

상황: Redis, Replica, 시계열 DB 등 기술 도입 검토
문제: 멘토링 시 선정 이유를 명확히 어필하지 못함
기회 손실: 더 빠른 의사결정과 고도화 시간 확보 가능했음

4. 성능 최적화에 편향된 시각

문제: 배치 처리 속도에만 집중
놓친 부분:
- 중복 검증 로직
- Write 롤백 전략
- 데이터 정합성 검증
학습: 성능과 안정성의 균형이 중요함

5. 비용 효율성 분석 누락

성과: 성능 10% 이상 향상 구간 도출
누락: vCPU 증가에 따른 비용 분석
필요: 성능 대비 비용 최적점(Cost-Performance Sweet Spot) 탐색

🚀 개선 방향 (Try)

1. Spring Batch 중복 검증 강화

현재 상태

Unique Key + ON CONFLICT DO NOTHING으로 중복 방지

개선 방향

ExecutionContext 활용한 처리 이력 관리
ItemProcessor 단계에서 선제적 중복 체크
메타데이터 기반 중복 실행 방지

기대 효과

더 안전한 멱등성 보장
데이터베이스 부하 감소

2. Skip 및 Retry 전략 도입

현재 상태

예외 발생 시 전체 Chunk 실패

개선 방향

@Bean
public Step billGenerationStep() {
    return stepBuilderFactory.get("billGenerationStep")
        .<Input, Output>chunk(1000)
        .reader(reader())
        .processor(processor())
        .writer(writer())
        .faultTolerant()
        .skip(TemporaryException.class)
        .skipLimit(100)
        .retry(RetryableException.class)
        .retryLimit(3)
        .build();
}

기대 효과

일시적 오류에 대한 복원력 향상
배치 안정성 증대

3. Write 롤백 전략 수립

개선 방향

보상 트랜잭션(Compensating Transaction) 패턴 적용
롤백 시나리오별 대응 방안 문서화
데이터 정합성 검증 로직 추가

기대 효과

장애 상황에서의 데이터 일관성 보장
운영 안정성 향상

4. DB Replica 적용

개선 방향

Read/Write 분리 아키텍처 도입
조회 쿼리는 Replica로 분산
부하 분산을 통한 성능 개선

기대 효과

메인 DB 부하 감소
조회 성능 향상
서비스 가용성 증대

📚 핵심 학습 및 성장

기술적 성장

대규모 배치 처리: Spring Batch를 활용한 수백만 건 데이터 안정적 처리 경험
성능 최적화: 병렬 처리, 쿼리 튜닝을 통한 실질적 성능 개선 역량
클라우드 아키텍처: GCP 서비스를 활용한 마이크로서비스 설계 및 배포 경험
Observability: 종합적인 모니터링 스택 구축 및 운영 노하우

협업 역량

체계적 커뮤니케이션: 일일 미팅과 주간 회고를 통한 투명한 협업 문화 경험
코드 리뷰 문화: 품질 향상과 지식 공유의 중요성 체감
문서화: 기술 결정 과정 기록의 중요성 인식
애자일 방법론: Jira 기반 스프린트 운영 실전 경험

문제 해결 능력

트레이드오프 고려: 성능, 안정성, 비용의 균형점 찾기
기술 선택의 근거: 요구사항 기반 기술 스택 선정 및 정당화 능력
점진적 개선: MVP 우선 개발 후 단계적 고도화 전략

💡 향후 적용할 인사이트

실무 적용 계획

설계의 중요성: 초기 설계에 충분한 시간 투자가 결국 전체 개발 속도를 높임
완벽함보다 완성: MVP를 빠르게 만들고 점진적으로 개선하는 접근
커뮤니케이션 우선: 기술적 의사결정은 명확한 근거와 함께 적극적으로 공유
성능과 안정성의 균형: 속도만큼 중요한 것이 안정성과 유지보수성
비용 효율성: 성능 개선 시 항상 비용 대비 효과 분석 필요

지속적 학습 목표

Spring Batch 고급 패턴 및 최적화 기법
클라우드 비용 최적화 전략
대규모 시스템 아키텍처 설계 역량
데이터 정합성 보장 메커니즘

📊 프로젝트 성과 요약

✅ 대용량 데이터 처리: 수백만 건의 청구 데이터 안정적 처리 시스템 구축
✅ 성능 최적화: PartitionStep 도입 및 쿼리 튜닝으로 처리 시간 대폭 단축
✅ 안정적 운영: 장애 복구 메커니즘 및 재시작 가능한 배치 구조 구현
✅ 협업 문화: 체계적인 커뮤니케이션 및 코드 리뷰 프로세스 확립
✅ 클라우드 배포: GCP 기반 마이크로서비스 아키텍처 구현 및 배포
✅ 모니터링 체계: 종합적인 Observability 스택 구축

📋 프로젝트 개요

🎯 프로젝트 목표

📅 주차별 진행 상황

1주 차 (1/7~1/11): 설계 및 계획

2주 차 (1/12~1/17): 핵심 기능 개발

3주 차 (1/20~1/24): 통합 및 최적화

4주 차 (1/25~1/27): 배포 및 마무리

💼 나의 기여

1. 월 청구서 생성 배치 시스템 구현

2. Batch 도메인 API 구현

3. 사용량 모니터링 API 및 UI 구현

4. 인프라 아키텍처 설계 참여

🛠 기술 스택 및 선정 이유

핵심 기술

Spring Batch

Cloud Scheduler

Cloud Tasks (Queue)

협업 도구

Observability Stack ( 모니터링 )

🎨 협업 체계

일일 협업

주간 회고

코드 품질 관리

문서화

🔧 주요 기술적 도전과 해결

1. 단일 Step → PartitionStep 전환으로 성능 개선

2. Page Size 및 Chunk Size 최적화

3. SQL 쿼리 최적화

✅ 잘한 점 (Keep)

1. 철저한 요구사항 분석과 설계

2. 체계적인 일일 커뮤니케이션

3. 모듈화된 Repository 구조

4. Jira를 통한 체계적인 프로젝트 관리

5. 버전별 점진적 개발 전략

6. 코드 리뷰 문화 정착

7. 테스트 문서화

🤔 아쉬운 점 (Problem)

1. 제한적인 코드 리뷰 범위

2. Confluence Wiki 작업 미완료

3. 기술 선택에 대한 적극적 커뮤니케이션 부족

4. 성능 최적화에 편향된 시각

5. 비용 효율성 분석 누락

🚀 개선 방향 (Try)

1. Spring Batch 중복 검증 강화

2. Skip 및 Retry 전략 도입

3. Write 롤백 전략 수립

4. DB Replica 적용

📚 핵심 학습 및 성장

기술적 성장

협업 역량

문제 해결 능력

💡 향후 적용할 인사이트

실무 적용 계획

지속적 학습 목표

📊 프로젝트 성과 요약

티스토리툴바