github action3 빌드 시간 86% 줄였는데 서버가 죽었다 - CI 최적화 그 이후 이전 글에서 4코어 4GB 러너 서버에서 Gradle 빌드 시간을 최대 86% 줄인 이야기를 썼다. 병렬 빌드, 캐시 전략, JVM 메모리 튜닝. 소프트웨어 설정만으로 꽤 의미 있는 개선을 이뤄냈다고 생각했다.그런데 최적화를 적용한 다음 날, 서버가 죽었다.최적화 다음 날, OOM03/20 오전. Harbor 이미지 빌드를 위해 3개 모듈(KubeManagement, Member, PortalManagement)의 워크플로우를 동시에 트리거했다. 러너가 1대니까 순차 실행될 거라 생각했고, 실제로 그렇게 동작해야 맞다. 그런데 세 번째 워크플로우가 시작되면서 서버가 응답을 멈췄다. SSH 타임아웃. 모니터링 메트릭 수집도 중단. 서버가 완전히 죽은 거다.원인을 추적해보니 세 가지가 겹쳤다.첫째, JVM .. 2026. 3. 31. 4코어 4GB 러너 서버에서 Gradle 빌드 시간 86% 줄이기 벼르고 있었다시제품화 마감이 코앞이다.프로젝트 막바지에 접어들면서 코드량과 PR 양이 급격하게 늘었다. AI 코딩 도구를 적극적으로 활용하면서 개발 속도 자체는 나름 빨라졌는데, 그 속도를 인프라가 못 받쳐주고 있었다. PR이 쏟아지는데 빌드/테스트 파이프라인이 병목이 되어 리뷰와 머지가 밀리기 시작했다.팀원들 사이에서 "PR 확인이 너무 오래 걸린다"는 말이 나왔다. 솔직히 말하면, 그 원인이 전부 CI 속도 때문만은 아니었다. AI 도구를 아직 제대로 활용하지 못하는 경우도 있었고, 코드 리뷰 시 맥락을 빠르게 짚지 못해서 시간이 걸리는 경우도 있었다. 하지만 그건 기술적으로 풀 수 있는 문제가 아니다. 사람의 사고 속도나 도구 숙련도는 강제할 수 없다.그래서 방향을 잡았다. 기술적으로 풀 수 있는 .. 2026. 3. 19. 팀 전원이 운영할 수 있는 CI/CD를 설계하다 - 망 분리 환경에서 GitHub Actions + Helm + ArgoCD로 들어가며사내 프로젝트를 진행하다 보면 "배포"라는 단순한 행위가 생각보다 큰 장벽이 되는 경우가 있다. 기존에 제공되는 CI/CD 파이프라인의 복잡도가 높고, 내부망과 Public Cloud가 분리된 환경이라면 더욱 그렇다. 개발팀이 기능 개발보다 배포 파이프라인을 이해하는 데 더 많은 시간을 쓰게 되는 상황, 나는 이 문제를 직접 겪었고 직접 해결했다.이 글은 CONE-Chain Portal(CCP) 프로젝트에서 Helm Chart 기반의 독립 CI/CD 구조를 설계한 배경, 의도, 그리고 실제 구현 내용을 정리한 것이다.1. 문제 인식 — 왜 기존 파이프라인을 쓰지 않았는가개발 환경의 구조적 제약CCP는 CONE-Chain 솔루션 위에 구축된 포탈 프로젝트다. 현재 개발환경용 CONE-Chain은 P.. 2026. 3. 7. 이전 1 다음
