Portfolio
experience
Created: 2025, 03 21 >Updated: 2025, 03 21DevOps & 인프라 엔지니어링
데브옵스 엔지니어로서 "더 뺄 게 없을 때까지 고민하고 줄여나가는" 미니멀리즘 철학을 인프라 설계에 적용합니다. 개발자들이 개발에만 집중할 수 있는 안정적이고 자동화된 환경을 구축하는 것을 추구하며, 다음과 같은 핵심 역량을 보유하고 있습니다:
- IaC(Infrastructure as Code): Terraform, Kubernetes Helm 기반 인프라 구축/배포
- CI/CD 자동화: ArgoCD 기반 GitOps 운영, 자동화된 배포 파이프라인 구축
- 클라우드 인프라: AWS 클라우드 서비스 설계 및 최적화 (EKS, Lambda, Kinesis, CloudFront 등)
- 시스템 자동화: Linux BASH, Python, Node.js 활용 운영 자동화
- 성능 최적화: 대용량 처리 시스템 설계 및 최적화 (분당 5만건 메시지 처리 등)
- 모니터링 및 관찰성: Grafana, Loki 등을 활용한 모니터링 시스템 구축
주요 프로젝트 및 성과
퍼플아이오 (2021.08 ~)
메시지(SMS/Email/Kakaotalk) 발송 서비스 성능 최적화
- 업무 요약: 대용량 메시지 발송 서비스 인프라 설계 및 성능 최적화
- 기술 환경: AWS Beanstalk, Lambda, Kinesis, Spring Boot
- 서비스 규모: 일 최대 1,300만건 메시지, 온/오프라인 고객 600만명 대상
- 주요 기술적 도전과 해결책:
- Lambda 병렬 처리 아키텍처 설계:
- 문제: 외부 API 초당 300회 이상 요청 필요, 단일 Lambda에서 비동기 요청 시 socket 부족으로 실패/지연 발생
- 해결: Lambda가 Lambda를 재호출하는 파이프라인 아키텍처 설계, 각 Lambda의 처리량 제한 및 병렬 처리로 요청량 충족
- 결과: 분당 1만건 → 5만건 처리 성능 향상, 안정적인 API 호출 구현
- Kinesis 용량 최적화:
- 문제: 분당 1만건 이상의 메시징 데이터 처리 필요, SQS FIFO의 처리 속도 한계
- 기술적 검증: SQS와 Kinesis 비교 테스트 후 Kinesis 선택 (처리량과 순서 보장 균형)
- 최적화: 데이터 압축 라이브러리 도입으로 1000개 데이터를 1개로 압축, 데이터 전송 비용 1/1000로 절감
- 튜닝: Lambda 트리거 설정 최적화로 데이터 누락 최소화 및 대용량 처리 검증
- AWS Beanstalk 관리 개선:
- 문제: 멀티 인스턴스 환경에서 특정 인스턴스만 기능 배포 필요
- 해결: AWS 문서 기반으로 Beanstalk의 leader_only 기능 활용, 특정 인스턴스에만 스크립트 실행
- 한계 및 대응: AWS 자체 플랫폼 업데이트 시 기능 동작 안하는 경우 처리 방안 수립
- 배치 서버 배포 프로세스 개선:
- 문제: 배치작업 중 새 인스턴스 생성/기존 인스턴스 종료 시 작업 강제 종료 이슈
- 해결: 배치 중단 확인 후 배포 진행하는 안전 메커니즘 구현
- Lambda 병렬 처리 아키텍처 설계:
- 성과:
- 분당 1만건 메시지 안정적 발송 환경 구축, 최대 분당 5만건 처리 가능
- 메시지 누락 없는 안정적 서비스 구현
- 서비스 중단 없는 배포 프로세스 확립
전사 EKS 버전 업그레이드 (1.20 → 1.27)
- 업무 요약: 쿠버네티스 클러스터 전체 버전 업그레이드 및 안정화
- 기술 환경: AWS EKS, Terraform, Kubernetes, ArgoCD
- 난이도 및 영향: 관리 종료 기한이 다가오는 1.20 버전에서 최신 1.27 버전으로의 마이그레이션은 단계적 업그레이드가 아닌 신규 환경 생성 방식으로 진행하여 시간 효율성 확보
- 주요 이슈 및 해결 과정:
- AWS CNI 확장 프로그램 Timeout: 확장 프로그램 버전 업그레이드 및 재설치로 해결
- LoadBalancer 이름 제한: Ingress 생성 시 32글자 제한 문제 해결
- Namespace 전환 문제: ArgoCD에서 리소스가 제대로 삭제되지 않는 이슈 파악 및 해결
- 인증서 문제: Route53 연결 후 ACM 인증서 재발급 및 DNS 전파 완료 확인
- ArgoCD 실행 불가: 최신 버전 호환성 문제 해결 및 설정 마이그레이션
- 네트워크 연결성: VPC CNI 설정 및 보안 그룹 조정으로 멀티 컨테이너 파드, RDS, 캐시 통신 문제 해결
- S3 접근 정책: AWS 정책 변경에 따른 필요 설정값 추가
- 성과:
- 버전 업그레이드 완료 및 운영 안정화로 보안 취약점 해소
- 기술 부채 해소 및 최신 쿠버네티스 기능 활용 가능
- 문제 해결 과정 문서화로 향후 버전 업그레이드 시간 단축 기반 마련
Slack 기반 배포 자동화 시스템 구축
- 업무 요약: Slack을 통해 원클릭으로 여러 서비스를 배포할 수 있는 봇 개발
- 기술 환경: Node.js, Kubernetes, Helm, ArgoCD, Slack API
- 배경 및 문제점:
- 테스트 배포 시 GitLab의 ArgoCD 설정파일에 브랜치명을 수동으로 변경해야 했음
- 버티컬 사이트 운영에 필요한 3개 레포지토리 각각 배포 필요
- 고정된 테스트서버 1대로 인해 다수 개발자 동시 테스트 어려움
- 구현 내용:
- Slack 커맨드를 처리하는 Node.js 서버 구현 및 ArgoCD API 연동
- 사용자별 스테이징 환경 동적 생성 및 관리 기능
- Kubernetes Helm 차트로 패키징하여 배포 및 관리 용이성 확보
- 운영 중인 ArgoCD 환경에 통합하여 추가 권한 관리 불필요
- 성과:
- 개발자 배포 프로세스 간소화 (설정파일 수동 변경 → Slack 커맨드 한 번으로 배포)
- 인원별 독립적인 스테이징 환경 제공으로 개발/테스트 효율성 향상
- 작업 과정 및 사용 방법 문서화 및 팀 내 공유로 전사적 활용도 향상
- 개발팀 배포 시간 약 70% 단축 효과
야간 파드 스케줄러 개발을 통한 비용 최적화
- 업무 요약: 야간 미사용 애플리케이션 자동 종료/재시작 스케줄러 개발
- 기술 환경: Kubernetes CronJob, ArgoCD, Kubernetes Secret
- 구현 내용:
- 야간 시간에 서비스 필요없는 앱 자동 종료 및 오전 자동 재시작 메커니즘 구현
- 쿠버네티스 CronJob을 활용한 스케줄링 시스템 구축
- 민감 정보는 Secret으로 관리하여 보안성 확보
- 성과:
- 전체 150개 애플리케이션 중 80개 야간 비가동 처리 자동화
- 클라우드 인프라 비용 20% 절감 효과
- 수동 관리 업무 제거로 운영 효율성 향상
버티컬 사이트 배포 관리 시스템 구축
- 업무 요약: 신규 버티컬 사이트 추가를 위한 자동화된 인프라 관리 시스템 구축
- 기술 환경: AWS Route53, CloudFront, Kubernetes, ArgoCD, Helm
- 문제 상황: 메인몰 외 브랜드별 자체 사이트 요구 증가, 사이트 추가 시마다 반복적인 수동 작업 발생
- 구현 내용:
- GitOps 기반 CD 시스템 구축 및 설정 파일 Git 관리
- 설정 파일에서 빌드된 브랜치명만 변경하여 간편한 배포 지원
- Helm 차트 세팅으로 ArgoCD 배포본 → Route53 Ingress 자동 설정
- 신규 사이트 추가 프로세스 표준화: 소스 분기, 도메인 추가, 설정 파일 생성, 배포
- 성과:
- 버티컬 사이트 추가 작업 시간 75% 단축 (1일 → 2시간)
- IaC 기반으로 인프라 관리 일관성 및 재현성 확보
- Helm 차트 활용으로 복잡한 설정을 추상화하여 실수 가능성 최소화
로그 추적 시스템 개선
- 업무 요약: Grafana, Loki를 활용한 로그 추적 시스템 구축
- 기술 환경: Grafana, Loki, Spring Boot
- 구현 내용:
- 백엔드 개발자와 협업하여 로그에 TraceID 추가 구현
- TraceID별 로그 조회가 가능한 대시보드 구축
- 분산 시스템 간 요청 추적 가능한 관찰성 확보
- 성과:
- 문제 발생 시 트러블슈팅 시간 50% 이상 단축
- 서비스 간 연관 관계 가시화로 시스템 이해도 향상
- 개발 및 운영팀 간 협업 효율성 개선
코오롱몰 및 버티컬 사이트 인프라 관리
- 업무 요약: AWS EKS 환경 기반 인프라 비용 및 운영 효율성 최적화
- 주요 업무:
- 클라우드 인프라 비용 최적화: 리소스 사용량 분석 및 적정 크기 조정, 예약 인스턴스 활용
- 반복 작업 자동화:
- 엑셀 데이터 → HTML 변환 자동화 스크립트 개발로 작업 시간 90% 단축
- 배송 상태 처리 API 자동화로 수동 처리 시간 대폭 감소
- 국가/디바이스별 콘텐츠 개인화:
- CloudFront Functions 활용 가능성 검토 및 비용 분석
- 트래픽(월 20TB, 시간당 60만) 기준 비용 계산 및 ROI 분석
- 빌드 최적화:
- Next.js 빌드 시간 개선 및 CI 캐시 성능 최적화
- 배포 시간 30% 단축 효과
국가 또는 디바이스 유형 헤더별 콘텐츠 개인화
- 업무 요약: cloudfront functions의 비용을 계산하고 처리
- 배경
- 사이트 접속 시 한국에서 접속하는지 체크해서 특정 사이트로 리다이렉트 시켜주는 동작이 필요했습니다. 이를 구현하는 다양한 방식이 있는데 Cloudfront Functions를 활용 가능한지 점검하고 이에 따른 비용 분석을 수행하여 제안했습니다.
- 비용 계산
- 요청당 비용이 들어서 꽤 넉넉한 용량만큼 프리티어로 사용 가능했고 (1TB 전송량/월, 1000만건 요청/월, 함수 200만건/월)
- 하지만 우리의 트래픽은 대략 시간당 60만 정도에 사용용량이 월 20TB 정도였고 이 자체로만 월 700만원 정도 비용이 예상되는 수치입니다
- 여기서 functions의 비용은 100만건 호출당 $0.1 정도이고 한달에 4만원 정도의 비용이 나오게 됩니다. 즉 function 하나 추가하는데 월 4만원 정도의 비용이 들게 됩니다.
- (주의 : 해당 처리량은 운영중인 특정 한 사이트의 대략적인 수치이자 예시일 뿐 실제 환경은 다를 수 있음을 안내드립니다)
- 결과
- 이는 서버 사양을 어떻게 관리하느냐에 따라 트레이드오프를 고려하여 cloudfront를 이미 사용하고 있다면 충분히 합리적으로 고려해볼만한 서비스인 것 같습니다.
- 결과적으로는 해당 기능이 불필요하게 되어 사용하지는 않았지만 cloudfront의 비용과 가능성에 대해 깊게 알게되어 의미있는 경험이었습니다.
백엔드 개발
쇼핑 컨텐츠 알림 시스템 개발
- 업무 요약: 코오롱몰의 이벤트, 기획전 등 컨텐츠 알림 시스템 개발
- 기술 환경: AWS Lambda, Kinesis, Serverless Framework
- 구현 내용:
- 기존 주문 및 컨텐츠 데이터를 Lambda로 크롤링 후 Kinesis로 전달하는 파이프라인 구축
- 알림 유형별(기획전, 타임딜, 출고/배송, 재입고) 처리 로직 개발
- 5분 주기 데이터 조회 및 알림 생성 시스템 구현
- 설계 고려사항:
- 멱등성: 중복 데이터 방지 및 재실행 가능한 구조 설계
- 확장성: 푸시 알림, SMS, 카카오톡 등 다양한 채널 지원 구조
- 성능: Pull/Push 방식 트레이드오프 분석 및 최적 방식 선정
- 성과:
- 사용자 관심 브랜드/상품에 대한 자동 알림으로 고객 참여도 향상
- 서비스 신뢰성 확보로 운영 안정화
추가 개발 프로젝트
-
쇼핑몰 시스템 마이그레이션:
- 쇼핑몰솔루션(아임웹)에서 사내 시스템으로 데이터 마이그레이션
- 게시판 기능 개발 및 DB 마이그레이션 (Node.js, GraphQL, Hasura)
- 웹 취약점 검사 대응 및 보안 강화
-
소셜 로그인 개발:
- 기존 CRM 시스템 로직에 맞춘 카카오, 애플 로그인 개발 (Spring)
- 정보보안 가이드 준수 및 보안 감사 대응
- 접속 이력 관리 및 취약점 대응 시스템 구축
-
사내 해커톤 - 좌석 예약 시스템 개발:
- 게더타운 컨셉의 좌석 예약, 회의실 예약, 사내 도서 관리 시스템 개발
- Next.js + Supabase 활용으로 빠른 개발 및 배포
- 7개 팀 중 2등 및 인기상 수상
- 관련 기사: https://yozm.wishket.com/magazine/detail/2490/
- 사이트: https://purple-place.vercel.app