미리보기

• 주 단위로 챕터 학습 후 회의로 공유 (2025.01 ~ 현재 진행중)

• https://github.com/ljw1126/refactoring2

• ‘단위 테스트의 기술’ 도서 리뷰 (2025.01 ~ 2025.02)

• https://dev-ljw1126.tistory.com/478

• 게임 서비스 개발 및 운영 지원 파이프라인 구축 (프로젝트 리드/설계) 

  • PM팀 통계 대시보드 개발

  • QA팀 Jira 대시보드 개발

  • 레벨 디자인팀 오픈 모니터링 개발

• Jenkins, AWS ECS 활용해 CI/CD 자동화 및 고가용성 갖춘 환경 구축

• Spring Batch 기반 광고 및 외부 API 데이터 수집

• Hadoop 파이프라인에서 대용량 로그 데이터 통계 추출 및 유지보수

• Spring Boot 기반 차트 및 통계/대시보드 화면기능 개발 및 유지보수

• 컨벤션 제안, 문서 자동화, 스터디 주도, 기술 문서 공유 등 지식 활동 수행

• 전자정부프레임워크 기반 프로젝트 개발 및 유지보수 (총 15개)

  • 충남도청, 전북도청, 부산시 공공데이터 포털 개발

  • 그외 재난 지원금 관리 시스템, 구청 홈페이지 등 개발

• 레거시 테이블 구조 분석한 후 정규화 및 마이그레이션 수행

• 수집대상 선별 및 테이블 설계한 후 Quartz 기반 배치, 모니터링 개발

• PM, 디자이너와 소통하며 1인 개발로 관리자, 사용자 화면 기능 개발

• 뷰 테이블 사용 및 인덱스 튜닝 등을 통해 조회 쿼리 성능 개선 경험

• On-premise 환경에서 WEB, WAS, DB 등 인프라 구성 수행

• 지식 격차 해소하기 위해 기술문서 작성, 교육 수행 (중간 관리자 역할)

[포트폴리오] 

https://github.com/ljw1126/coupon-issue

[목표] 

• Docker Compose 활용해 부하 테스트 및 모니터링 환경 구축

• 지표 기반 병목 구간 분석과 리팩터링을 통해 성능 개선 경험 

• 분산락, 로컬 캐시, Kafka를 단계적으로 도입하여 동시성 문제 해결 및 시스템 성능, 확장성 확보

• AWS 인프라 구성, 배포, 부하 테스트 통해 성능 최적화 결과 확인 (목표 RPS: 5,000)

[트러블 슈팅 및 성능 개선 과정]

• 동시성 이슈

  • 분석: 쿠폰 최대 수량 500개 설정 후 부하 테스트(가상 유저 1,000명) 실행 시 쿠폰 초과 발급 확인

  • 액션: synchronized, MySQL 레코드 락, Redission 분산락을 적용 후 부하 테스트 및 성능 비교

  • 결과: RPS 성능이 가장 높은 Redission 분산락 적용 결정 → 동시성 제어 성공

• MySQL CPU 과부하

  • 분석: 

    • N명의 사용자가 N번의 트랜잭션을 발생시킬 경우 병목현상 야기하여 서버 부하 발생

    • 부하 테스트를 desktop 환경에서 함께 실행하여 CPU 사용률 상승 (환경적 영향)

  • 액션:

    • 멀티 모듈로 coupon-api(쿠폰 신청)와 coupon-consumer(쿠폰 발급) 서버 분리

    • Redis 도입 → 대기열 큐에 두 서버가 의존하여 트래픽 대응 및 MySQL 트랜잭션 제어 

    • 노트북에서 부하 테스트 실행하도록 환경 분리하여 측정 정확도 개선

  • 결과:  CPU 사용률 80% 감소, 동시 요청시 응답속도 개선, DB 안정성 확보

• RPS 성능 병목 이슈

  • 분석:

    • Redisson 분산락 사용할 때, 락 획득/해제로 인해 성능 저하 발생

    • 성능 테스트 결과, 락 제거 시 RPS 5배 증가 확인 → 동시성 이슈 재발생

    • Reids 명령어의 시간복잡도는 O(1)이지만, 네트워크 왕복 비용도 성능 저하 원인으로 분석

  • 액션: Redis Lua Script 사용 → 원자적 실행으로 네트워크 왕복 비용 절감

  • 결과: RPS 5.4배 향상, 평균 응답 시간 26.7배 단축, 네트워크 비용 감소 및 동시성 제어 최적화

• 사전 성능 개선(로컬 캐시 도입)

  • 분석: 쿠폰 정책을 글로벌 캐시에서 조회할 때 발생하는 통신 비용을 줄일 방법을 고민

  • 액션: 로컬(Caffeine) 캐시 추가 → 글로벌 캐시 조회 감소, 쿠폰 발급 완료시 캐시 초기화

  • 결과: RPS 1.33배 향상, 쿠폰 유효성 검사에서 예외 처리하여 불필요한 로직 실행 방지

• 사전 성능 개선(비동기 큐 분리)

  • 분석: Redis 대기열 큐에 두 서버가 의존하고 있어, 동시 요청 증가시 Redis 성능 저하 예상

  • 액션: Kafka 도입하여 Redis 대기열 큐의 부담을 분산 → 비동기 이벤트 처리로 요청 흐름 개선

  • 결과: RPS 성능 6.96% 향상, Redis 부하 감소, 확장성 향상

[결과]

• AWS 인프라 구성 후 부하 테스트 수행 → RPS 10,594로 초과 달성(가상 유저 5,000/초당 500 증가)

• 모니터링 분석 결과

  • Redis CPU: 2.76%, MySQL CPU: 5% → MySQL과 Redis는 여유 있어 더 처리 가능

  • 쿠폰 API 서버 CPU 사용량 99.9% → Scale-out(수평 확장)한다면 더 많은 트래픽 대응 가능

기여도: 95%

[문제 분석]

서버 크래시 주기가 이틀 간격으로 짧아져 서비스 개발 및 운영 부서의 업무가 지연되었습니다

• 3개 서비스가 각각 단일 서버(SPOF)로 운영되어 장애 발생시 전체 업무 차질

• 모니터링 환경 부재로 장애 발생 후 터미널 접속하여 로그 확인 → 정확한 원인 분석 어려움

• 배포 스크립트 오류로 인해 배포 시 서비스 끊김 현상 발생

• Health Check를 Slack과 연동하지 않아 장애 감지 지연

• Heap Dump 분석 결과, Hibernate QueryPlan Cache 비율 96% 확인(OOM 발생 원인)

[기술 선택 및 과정]

• 신속한 대응과 설정 기반의 배포/모니터링 환경 구축을 위해 AWS ECS Fargate 선택

• 기존 인프라 분석 후 Scale-up(2vCPU, 4GB), Task는 항상 2개 유지하도록 세부 spec 결정

• 운영 환경변수의 보안과 관리 강화를 위해 AWS Secrets Manager 선택

• Dockerfile 빌드 테스트, AWS Secrets Manager 호출 테스트 등을 거쳐 검증 진행

• 서브 도메인 발급 및 전체 인프라 구성 후 이슈 해결 →  사내 공지 후 안정적으로 3개 서비스 이관 진행

[트러블 슈팅]

• 일부 사용자 서비스 접속 불가(500 Internal Server Error)

  • 분석: 직렬화 관련 에러 로그를 확인하고, 깃 히스토리를 통해 과거 코드와 비교하며 원인 추적

  • 액션: 

    • 스프링 부트 버전업하면서 Security 직렬화 UID(510L→570L)변경이 원인으로 확인

    • 개별 브라우저 캐시 초기화 방법은 불편하여 Spring Session 테이블 초기화로 해결

  • 결과: 사내 모든 사용자가 정상적으로 서비스 접속

• AWS Secrets Manager 접근 권한

  • 분석: 컨테이너 실행시 운영 환경 변수를 읽지 못하는 문제 확인 → 접근 권한 부족 문제로 추측

  • 액션: ECS Task에 설정된 IAM Role에 SecretsManagerReadWrite 권한 추가

  • 결과: 정상적으로 운영 환경변수를 로드하여 컨테이너 애플리케이션 실행 확인

• 서비스 연결 이슈(504 Gateway Timeout)

  • 분석: Target Group에서 Health Check 실패 확인 → 서비스간 보안 그룹 설정 문제로 추측

  • 액션: ECS 보안 그룹의 인바운드 규칙에 ALB 보안그룹 규칙을 추가

  • 결과: Health Check 성공되며 서비스 연결 확인

• Multi ALB 설정

  • 분석: 서비스 생성시 ALB 연결을 하나만 설정할 수 있어, 추가 설정 방법이 숨겨져 있을 거라 추측

  • 액션: AWS CLI 공식 문서에서 추가 설정 방법 탐색 → Bastion Host에서 추가 설정 명령어 실행

  • 결과: 모니터링을 통해 Multi ALB가 정상 연결 확인

[결과]

• CI/CD 자동화, 고가용성 확보, 모니터링 & 장애 대응 체계 강화

• 역량 평가에서 팀원 8명 중 1위 달성, AWS 인프라 아키텍처 설계 역량 강화, Confluence로 경험 공유

• OOM 문제의 근본적인 해결까지는 이루지 못했지만, 이를 통해 원인 분석·재현·테스트·모니터링 역량의 중요성을 깨달았습니다. → 이후 “선착순 쿠폰 발급 시스템” 토이 프로젝트를 수행하며 해당 역량을 강화

기여도: 90% (프로젝트 리드/설계, 1인 개발)

[성과]

• 자원 생산, QA, 분석 및 전략 수립 과정을 지원하는 파이프라인 구축

• 대용량 로그 통계 자동화 및 대시보드 개발: 데이터 접근성과 편의성 개선하여 데이터 기반 의사 결정 지원

• 4개 팀의 문서 자동화 및 간소화하여 주간 보고 시간 75% 단축, 업무 생산성과 효율성 향상 기여

• 약 2년간 미해결된 프로젝트를 모두 해결 (문제 해결 및 커뮤니케이션 역량 강화)

  
  

PM팀 (Spring Boot, Spring Batch, Hibernate, MySQL, Docker, AWS, Git, Hadoop, crontab) 

월간 광고, KPI 대시보드 개발 (프로젝트 리드/설계, 1인 개발) - 2022년 12월 - 2023년 01월 (2개월)

• Spring Batch 활용해 대용량 광고 데이터 수집 및 S3 업로드 최적화

  • OOM 방지: OpenCSV 활용해 구분자 변경, 디스크 기반 저장, 압축 처리 후 안전하게 S3 업로드

  • 배치 실행 시간 66% 단축: 안정적인 트랜잭션 관리 및 장애 복구 고려하여 Partitioning Step 활용, 실행 시간 단축 (3분 →  1분)

  • 자동화: crontab 활용해 배치 및 Hadoop 데이터 파이프라인 통계 스크립트 자동 실행, 운영 부담 감소

• 대시보드 개발: 월간 광고 통계 차트, KPI 지표(26개)를 효율적으로 처리, 표출하여 분석 및 전략 수립 지원

레벨 디자인팀 (Spring Boot, Hibernate, MySQL, EhCache, Hadoop, Pig, Shell Script, Vim, Git)

오픈 모니터링 개발 (프로젝트 리드/설계, 1인 개발) -  2022년 05월 - 2022.11 (7개월)  

• 레벨 디자인팀 요구사항 정리 및 일정 수립: 

  • 커피챗 활용해 목적, 요구사항, 서비스별 정책 파악 후 Jira 티켓 200개 정리 및 우선순위 설정 

• 데이터 분석팀 컨벤션 제안 및 협업 문화 형성 시도:

  • 분석: 컨벤션 부재로 스크립트 중복과 불명확한 네이밍 문제(예: f1=꽃1)로 작업 난이도 상승

  • 액션:

    • 팀 데이에서 컨벤션 자료 발표 및 문서화 공유 → 중복 스크립트 제거 및 네이밍 수정 작업 수행

    • ‘Vim, 친해지길 바래’ 스터디(2회) 진행 → 스크립트 생산성 10배 향상 경험과 작업 환경 공유

• 통계 스크립트 개발 및 자동화: 

  • Hadoop 파이프라인 구축: 메타 명세화 후 Vim으로 Pig & Shell Script 120개 이상 작업

  • 자동화: crontab을 활용해 주기적으로 통계 스크립트 실행 및 Slack 알림 설정

• 대시보드 개발 및 성능 최적화: 

  • 구글 차트 데이터 규격에 맞춘 비즈니스 로직 설계 및 화면 기능 개발 (차트, 표: 약 640개)

  • 로컬 캐시(EhCache) 적용: 데이터베이스 조회 중복 요청 감소 및 응답 속도 개선

• 데이터 접근성과 사용자 편의성 확보:

  • 추가 요청 40건 해결: 로컬 스토리지 활용해 개별 설정 저장, 해시태그 및 파일 변환 기능 등 제공 

QA팀 (Spring Boot, Hibernate, MySQL, EhCache, AWS, Git, Jira, Confluence, Java, JavaScript)

Jira 대시보드 & Risk 현황 개발 (프로젝트 리드/설계, 1인 개발) -  2022년 02월 - 2022.06 (5개월)

• 요구사항 분석 및 설계: 화면 설계서 작성 후 HTML/CSS로 시안 제작 → 회의를 통해 의견 교환 및 피드백 반영

• 테이블 설계 및 정규화, 데이터 수집: 

  • Jira API 20개 분석 (Postman 활용) → 테이블 설계 및 정규화 진행

  • Spring Scheduler 활용해 배치 개발 → 주기적으로 API 데이터 동기화 및 자동 수집, 실행 로그 기록

  • 미제공 항목(2개) 보완: Jira History API와 일별 건수 연산해 원하는 값 구할 수 있어 요구사항 충족

• 대시보드 개발 및 성능 최적화: 사용자/관리자 화면 기능 구현 및  로컬 캐시(EhCache) 적용해 응답 속도 개선

• 데이터 정확성 검증 및 정책 문서화: 통계 불일치시 QA팀과 원인 추적 및 수정, 정책 문서화하여 공유

기여도: 80% (인원: PM, 디자인, 개발 각 1명씩)

[성과]

• 공공데이터 포털 프로젝트(1인 개발) 성공적 완료, 회사의 신뢰성과 전문성 확보

• 프로젝트 품질 향상 및 협업 문화 개선:  매뉴얼 작성·공유·설명하며 신규 직원 지원 및 지식 격차 해소

• 생산성 2배 향상: 2년차부터 11개 프로젝트 개발 및 유지보수팀 지원, On-premise 인프라 역량 강화

충남도청 (EgovFramework, MyBatis, MariaDB, Quartz, Apache, Tomcat, Git, Java, JavaScript) 

• 데이터 수집 및 공공 API 관리 시스템 구축 (1인 개발, 기여도 90%) - 2020년 10월 - 2021년 06월 (9개월)

  • 공공데이터 수집 및 표준화 (총 464건)

    • 공공데이터 포털, 인허가, 통계청, 직속기관 데이터 조사 및 표준 API 메타데이터 생성

    • Excel 활용 SQL Query 자동 생성 후 테스트 DB 적용 → 작업 효율성 확보

    • 테이블 정의서, 컬럼 정의서 등 감리 문서 20 종 작성

  • 배치 최적화 및 운영환경 이슈 해결 (OOM 방지, 성능 40% 개선)

    • DBMS 4종 설치 후 테스트 환경 구성, 운영 환경에서 발생할 장애 요소 사전 예측

    • ChunkSize(1,000건)조회 및 Batch Insert 적용 → 대량 데이터 처리 시 메모리 과부하 방지

    • 모니터링 통해 운영환경에서 발생한 IP 접근 문제, 권한 설정, 컬럼 변경 등 오류 추적 및 해결

  • 공공 API 관리 시스템 구축 및 시스템 안정성 개선

    • 신규 공공 API 20종 발굴 및 등록 서비스 개발 및 사용자/관리자 화면 기능 개발

    • On-premise 인프라 구성: WEB, WAS, DB, 배치, 프로젝트 설치까지 1시간 내 완료

    • 뷰 테이블 생성 및 접근 제어: 외부 연동 서비스에는 읽기 권한만 부여하여 보안 강화

    • 1주일간 출장가서 PM과 함께 종료 감리 대응 및 담당자 설명회 수행

전북도청 (EgovFramework, MyBatis, Oracle, Quartz, JEUS, Git, Java, JavaScript,  jqGrid.js)

• 공공 API 관리 시스템 구축, 홈페이지 리뉴얼 (기여도 70%) -  2019년 04월 - 2019년 10월 (7개월)

  • 레거시 데이터 정규화 및 마이그레이션 (정확성 99%)

    • 분석: 레거시 테이블 분석 후 비정규화된 데이터로 인해 카운팅 오류 발생 확인

    • 액션: 

      • 표준 공공 API 규격에 맞춰 테이블 및 메타데이터 설계 후 Excel로 쿼리 자동 생성

      • Java 이관 프로그램 개발 → 점진적으로 row수 늘리며 테스트 진행

    • 결과: 2만 건 데이터 마이그레이션 완료, 감리 통과 및 데이터 정확성 99% 보장

  • 관리자/사용자 화면기능 개발, geogate 지도 서비스 리뉴얼, 감리 문서 작성 수행

  • 공공데이터 조회 성능 최적화 (8s → 0.15ms)

    • 분석: 방문자 증가(17만 명)로 공공데이터 조회 속도(8s) 느려져 쿼리부터 확인

    • 액션: 

      • 조회수 서브 쿼리 제거, 역정규화하여 컬럼 추가, 쿠키 기반 중복 조회수 방지 적용

      • 기본키 누락되어 있어 추가 후 커버링 인덱스 및 복합 인덱스 최적화 

    • 결과: 조회 속도 0.15ms로 개선

  • 데이터 내보내기 OOM 이슈 해결 

    • 분석: row수 2만부터 OOM 확인 → 전체 데이터 조회 후 처리하면서 힙 메모리 낭비 발생

    • 액션: 

      • WAS 힙 메모리 설정 조정 및 chunkSize(1,000건) 단위로 분할 조회 변경

      • Apache POI의 XSSFWorkbook → SXSSFWorkbook 전환 (디스크 방식)

    • 결과: 메모리 사용량 80% 감소, 대량 데이터 처리 안정성 확보