1. 고립을 넘어: 서버 관리의 딜레마
우리는 오랫동안 “코드를 작성하는 시간”보다 “코드가 돌아갈 환경을 구축하는 시간”에 더 많은 에너지를 쏟아왔습니다. EC2(VM) 시절에는 OS 업데이트와 보안 패치를 신경 써야 했고, Docker의 등장으로 컨테이너라는 자유를 얻었지만, 그 컨테이너를 관리하기 위해 Kubernetes라는 거대한 항모를 조종해야 하는 부담을 안게 되었습니다.
“나는 단지 내 Go 서버를 띄우고 싶을 뿐인데, 왜 클러스터의 노드 풀을 관리해야 하는가?”
이 질문에 대한 구글의 대답이 바로 Cloud Run입니다.
2. 선택: 인프라의 추상화 (Cloud Run)
Cloud Run은 복잡한 Kubernetes(Knative)를 구글이 대신 관리해 주는 Fully Managed Serverless Container 서비스입니다. 개발자가 할 일은 단 하나입니다.
“여기 내 코드가 담긴 컨테이너 이미지가 있어. 8080 포트로 들어오는 요청을 처리해 줘.”
이 선택을 통해 우리는 다음과 같은 이점을 얻습니다.
- 프로비저닝 불필요: 서버 사양을 미리 고민할 필요가 없습니다.
- 오토 스케일링: 트래픽이 오면 늘어나고, 없으면 0개로 줄어듭니다(Scale to Zero).
- 비용 효율: 서버가 켜져 있는 시간이 아니라, **요청을 처리하는 시간(100ms 단위)**만큼만 돈을 냅니다.
3. 대가와 극복: Cold Start와 Go의 필연적 만남
하지만 모든 선택에는 대가가 따릅니다. 트래픽이 없을 때 인스턴스를 0개로 줄인다는 것은, 첫 요청이 들어올 때 서버를 다시 켜야 한다는 뜻입니다. 이를 Cold Start라고 합니다.
여기서 **Go(Golang)**의 진가가 발휘됩니다.
무거운 런타임의 한계
Java(Spring)나 Node.js 같은 언어들은 런타임을 초기화하고 라이브러리를 로드하는 데 꽤 많은 시간이 걸립니다. 사용자는 첫 요청에서 3~5초 이상의 지연을 겪을 수 있습니다. 이는 서버리스 환경에서 치명적입니다.
Go: 가벼움의 미학
Go는 컴파일 언어이며, 단일 정적 바이너리(Static Binary)로 빌드됩니다.
- 초고속 부팅: 런타임 초기화가 거의 없이 즉시 실행됩니다. (수십 ms 수준)
- 작은 이미지 사이즈:
distroless나scratch베이스 이미지를 사용하면 컨테이너 크기가 10~20MB에 불과합니다. 이미지가 작을수록 Cloud Run이 이미지를 당겨오는(Pull) 속도도 빨라집니다. - 적은 메모리: 적은 메모리로도 높은 동시성 처리가 가능하여, Cloud Run의 리소스 할당 비용을 줄일 수 있습니다.
4. 결론: 가장 현대적인 배포 방정식
Cloud Run을 통해 인프라 관리의 짐을 벗어던지고, Go 언어를 통해 서버리스의 단점(Cold Start)을 극복합니다. 이 조합은 스타트업이나 MSA(Microservices Architecture)를 지향하는 조직에게 “가장 빠르고, 가장 저렴하며, 가장 관리가 편한” 배포 파이프라인을 제공합니다.
Dockerfile 하나면 충분합니다. Go로 짠 코드를 Cloud Run에 올리는 순간, 여러분은 온전히 서비스의 본질에만 집중하게 될 것입니다.