배경
개인적으로 블로그 글을 자동으로 작성하고 발행하는 실험을 진행하고 있습니다.
자동화 시스템이 글을 작성한 뒤 GitHub 저장소에 커밋을 푸시하면, Vercel이 이를 감지해 자동으로 빌드하고 배포하는 구조입니다. 무료로 쓸 수 있고 별도로 신경 쓰지 않아도 배포가 되니 꽤 편리하게 사용하고 있었습니다.
그런데 어느 날, 예상보다 많은 Vercel 요금 30만원이 넘게 청구되었습니다.
(Vercel 유료서비스도 활용하고 있기에 카드 등록이 되어있었어요.)
처음에는 단순히 트래픽이나 사용량이 많았나 보다 생각했습니다.
앞으로 자동 발행 빈도를 조금 줄여야겠다고 생각하며 Vercel 대시보드의 Billing 메뉴를 확인했습니다.
1월, 6월, 7월의 소비 내역을 보여주는 그래프
문제는 빌드 시간
사용 내역을 살펴보니 대부분의 비용이 하나의 프로젝트에서 발생하고 있었고, 그중에서도 가장 큰 비중을 차지한 것은 트래픽이 아니라 빌드 시간(Build CPU Minutes)이었습니다.
Google Analytics 대시보드의 스크린샷
글 작성할 때마다 빌드가 돌아간다
현재 자동화 시스템은 한 시간에 약 4~5개의 글을 발행합니다. 보통 글이 하나 올라올 때마다 GitHub에 새로운 커밋이 생성되고, 그때마다 Vercel에서 전체 빌드와 배포가 다시 실행된다는 점이입니다.
게다가 글 작성을 위해 개별 브랜치를 만들도록 하고 있는데 개별브랜치에서 1번 빌드되고, 메인브랜치에 올리면서 한번 더 빌드되면서 같은 빌드를 불필요하게 2번씩이나 하고 있었습니다.
항목 목록을 보여주는 중국 웹사이트의 스크린샷
한시간에 글을 5개씩 올리면 한달간의 빌드 횟수는 7200회입니다. 이게 5분씩 잡아도 대략 600시간을 예상할 수 있는데, 실제로 6월 한달간 해당 프로젝트에서만 집계된 빌드 시간은 892시간이었습니다.
빌드와 함께 동작하는 스크립트
물론 빌드 횟수가 많은 것도 문제였지만 또다른 문제는 따로 있었습니다.
빌드 과정에서 함께 실행되도록 만들어 둔 스크립트였습니다. 자주 발생하는 간단한 교정 실수 가 있어서 검수하고 수정하는 콘텐츠 검수 및 자동 교정이나 og 이미지 생성 같은 스크립트입니다..
기능 자체는 잘 작동하고 있었는데 문제는 실행 시간이었습니다.
원래라면 1분 안에 끝날 수 있는 빌드가 이런 과정 때문에 매번 5분 이상 걸리고 있었습니다. 이 차이가 작아보이지만, 횟수가 많아질수록 영향이 커집니다.
아마 하루에 몇번 정도 실행되는 빌드였다면 크게 눈에 띄지 않았겟죠. 하지만 하루에 약 200회 이상 이상 배포가 발생하니, 작은 비효율이 계속 누적되고 있었습니다.
자동화가 잘 돌아간다는 것만 확인했지, 한 번 실행될 때 얼마나 많은 시간과 컴퓨팅 자원을 사용하는지는 제대로 확인하지 않았던 것입니다.
개선 방향
글을 너무 많이 써서 생간 문제였습니다. 그러면 글 작성을 줄여야 할까요? 그렇지는 않습니다.
일단 빌드 횟수만 줄여도 시간을 많이 줄일 수 있습니다.
글작성은 똑같이 하더라도 실제 빌드를 1시간에 한번씩 진행하고, 개별 브랜치의 빌드를 생략하면 약 1/10 으로 시 간을 줄일 수가 있습니다.
빌드 효율을 개선하는 방법도 있습니다. 현재는 모든글의 검수와 og이미지 생성을 빌드할 때마다 새로 하고있는데요. 모든글을 검수하는 대신 새로 추가된 글만 검수하도록 하고, og이미지도 매번 새로 만들지 않고 미리 생성한 이미지를 재사용하도록 하면 빌드타임이 획기적으로 줄어들 것 같습니다.
좀더 근본적인 해결책은 빌드를 로컬머신에서 하는것입니다. 비용청구는 Vercel 서버에서 빌드가 진행되기 때문입니다. 그래서 Vercel 의 컴퓨팅 자원을 활용하는 비용이 청구되는거죠. 그런데 애초에 Vercel에서 빌드를 진행하지 않고 업로드만 시키면 이런 문제가 없습니다. github에 커밋이 push 될때마다 빌드되는게 자동 설정이지만 이렇게 하지않고 로컬에서 빌드해서 올리도록 하면 근본적인 문제가 해결됩니다.
개선 방안을 다시 정리하면 이렇습니다.
테스트용 브랜치에서는 불필요한 Vercel 빌드가 실행되지 않도록 설정
배포가 필요하지 않은 작업은 로컬에서 직접 빌드한 뒤 결과물만 업로드
빌드 타임에 실행되는 검수 및 자동 교정 스크립트 최적화
여러 번의 커밋을 모아 한 번에 배포하도록 발행 구조 개선
프로젝트별 빌드 시간과 사용량을 주기적으로 확인
“컴퓨팅 자원은 무료”라는 착각
그동안 개인 프로젝트를 만들면서 서버리스, CI/CD, 자동 배포 같은 기능을 자주 사용했습니다.
무료 플랜 안에서 사용하다 보니 컴퓨팅 자원을 사실상 무료처럼 생각했던 것 같습니다.
그래서 컴퓨팅자원을 효율적으로 운용하는 방식을 크게 고려하지 않았던 것 같습니다.
하지만 실제 요금을 청구받고 나니 생각이 달라졌습니다. 자동화는 공짜로 움직이는 것이 아닙니다. 눈에 보이지 않을 뿐, 자동화가 실행될 때마다 빌드 시간과 서버 자원, API 호출, 네트워크 사용량이 계속 소비되고 있다는걸 체감하게 되었습니다.
이번 일을 계기로 문제가 되었던 Vercel 빌드 뿐 아니라 제가 사용하고 있는 다른 자동화 워크플로도 전부 점검을 해보고 있습니다.
점검하다가 발견한 두 번째 사고
Vercel 문제를 계기로 다른 서비스의 사용량도 확인하던 중, 또 하나의 문제가 발견됐습니다.
어느날 갑자기 GitHub Actions로 실행되던 여러 워크플로가 모두 실패하고 있었습니다. 알고보니 무료 사용량을 모두 소진한 상태였습니다. 원인은 GitHub Actions에 으로 주기적으로 실행되도록 설정한 작업 때문이었습니다.
이 작업은 원래라면 2~3분 정도로 끝날만한 작업입니다. 실행 빈도도 하루에 2번밖에 실행을 안하기 때문에 문제가 될거라는 생각을 못했죠. 그런데 실제로 이작업은 약 40분 정도가 걸리고 있었습니다.
외부 동기화 제어 설정 스크린샷
자동으로 잘 돌아가는 것처럼 보여서 신경쓰지 않았는데 불필요한 실행 시간이 계속 누적됐고, 결국 GitHub 계정의 무료 Actions 사용량을 모두 소진했고. 무료 할당량을 다 사용하자 다른 저장소에서 사용하던 GitHub Actions 워크플로까지 전부 실행되지 않는 상황이 발생했습니다.
이문제도 비슷한 방식인데, 해당 레포에 있는 모든 게시물에 대해서 전부다 불필요한 검수와 수정이 이루어지고 있었습니다. 이것도 최신 등록된 부분만 검사하도록하고, 전수조사는 주1회만 하도록 별도로 새로 등록하여 해결했습니다.
자동화는 만드는 것보다 운영하는 것이 중요하다
이번 사건을 겪으며 자동화에서 중요한 것은 단순히 “잘 실행되는가”가 아니라는 점을 다시 느꼈습니다.
자동화는 다음 항목까지 함께 관리해야 합니다.
얼마나 자주 실행되는가
한 번 실행될 때 얼마나 오래 걸리는가
실패했을 때 자동으로 종료되는가
같은 작업을 불필요하게 반복하고 있지는 않은가
실행량이 증가했을 때 비용이 어떻게 늘어나는가
사용량 한도를 넘었을 때 다른 시스템에 어떤 영향을 주는가
자동화가 정상적으로 동작하고 있다는 사실만으로는 충분하지 않습니다. 오히려 자동화는 사람이 매번 확인하지 않아도 계속 실행되기 때문에, 비효율이나 오류가 발견되지 않은 채 오랫동안 누적될 가능성이 더 큽니다.
이번에 발생한 문제들도 모두 이러한 불찰에서 시작됐습니다.
자동화가 알아서 잘 돌아가고 있다고 생각해, 실행 시간과 비용을 제대로 확인하지 않았던 것
무료 플랜을 사용하더라도 완전한 무료가 아니라, 일정 범위의 사용량을 무료로 제공하는 것에 가깝기 때문에. 그 범위를 넘어서는 순간 비용이 발생하거나, 이번 GitHub Actions 사례처럼 중요한 자동화가 갑자기 멈출 수도 있습니다.
