<div id="readability-page-1" class="page"><div><h2 id="intro">Intro</h2>
<p>“초기 스타트업에서 쿠버네티스까지 필요한가?”</p>
<p>제목을 보고 가장 먼저 드는 생각일 겁니다. 여러 개발자 커뮤니티에서 계속 오가고 있는 주제기도 합니다.</p>
<p>프로토타이핑으로 유저 반응부터 보려는 제품이라면 쿠버네티스 말고도 선택지가 많습니다.</p>
<hr>
<h2 id="진짜로-쿠버네티스가-필요하다구요">진짜로 쿠버네티스가 필요하다구요?</h2>
<p>저는 모든 <strong>초기</strong> 스타트업에서 쿠버네티스가 필요하다고 생각하지 않습니다. 대부분의 경우에는 필요하지 않다고 생각하는 쪽에 가깝습니다.</p>
<p>이 논쟁이 매번 평행선을 그리는 건 서로 다른 상황에 있는 사람들이 같은 단어로 이야기하기 때문입니다.</p>
<p>“초기 스타트업”이라는 말 안에는 아직 무엇을 만들지 모르는 팀도 있고, 무엇을 만들지는 알지만 사람 손으로 돌리는 팀도 있습니다. 두 팀에게 같은 답이 나올 리가 없습니다.</p>
<p>그래서, 이 글은 <strong>쿠버네티스를 쓰세요</strong>에 대한 글이 아닙니다. 우리 팀이 어떤 조건에 있었고, 중요하게 생각했던 게 무엇인지, 그리고 그 조건에서 왜 쿠버네티스가 가장 싼 선택이었는지를 적었습니다. 조건이 다르다면 결론도 달라집니다.</p>
<h2 id="1-프로토타이핑이-이미-끝나-있었습니다">1. 프로토타이핑이 이미 끝나 있었습니다</h2>
<p>“초기 스타트업에 쿠버네티스는 오버엔지니어링”이라는 말은 <strong>버려질 확률이 높은 코드에 인프라 비용을 쓰지 말라</strong>는 뜻으로 읽습니다.</p>
<p>맞는 말입니다. 내일 당장 갈아엎을 서비스에 클러스터를 세우는 건 낭비입니다.</p>
<p>저희는 그 단계를 이미 지나 있었습니다. <a href="https://homeco.kr/">홈코</a>는 집수리 서비스이고, 프로토타이핑은 구글 시트로 끝나 있었습니다. 고객이 요청을 넣고, 저희가 견적서를 보내고, 기사님을 배정하고, 시공이 끝나면 정산까지 하는 흐름 전체가 시트와 사람 손, 약간의 자동화 SaaS 위에서 돌아가고 있었습니다.</p>
<p>제가 만들어야 할 것은 <strong>이미 되고 있는 일을 풀어내는 인프라</strong>였습니다. “이게 될까?“는 확인이 끝난 상태였습니다. 도메인은 확정되어 있었고 필요한 화면과 배치, 상태 전이가 무엇인지 대략 알고 있었습니다.</p>
<p>제목을 Day 0 가 아니라 Day 1 으로 쓴 이유이기도 합니다.</p>
<p>저희에게 Day 1 은 <strong>앞으로 몇 년을 갈 인프라의 첫날</strong>이었습니다. 그렇게 잡고 나면 기준이 달라집니다.</p>
<h2 id="2-배치가-필연적입니다">2. 배치가 필연적입니다</h2>
<p>시트로 돌아가는 운영을 옆에서 보고 있으면 앞으로 무엇이 필요해질지가 선명하게 보입니다.</p>
<p>집수리 서비스의 운영은 요청-응답만으로 돌아가지 않습니다. 시공 전날 고객에게 나가는 리마인드, 기사님께 보내는 시공 전 알림, 자재 재고 확인, 아직 작성되지 않은 견적서 알림까지, 눈에 보이는 배치성 작업이 이미 많았습니다.</p>
<p>집수리 데이터가 쌓이고 나면 데이터 적재나 분석을 위한 배치도 당연히 따라옵니다.</p>
<p>배치는 하나 만들기 시작하면 요구사항이 붙습니다. 실패하면 재시도해야 하고, 겹쳐 돌면 안 되고, 실패했다는 사실을 누군가 알아야 하고, 지난 실행이 언제 어떻게 끝났는지 남아야 합니다. 서버에 crontab 을 걸어두는 방식으로 시작하면 이 요구사항들을 결국 하나씩 직접 만들게 됩니다.</p>
<p>쿠버네티스에서는 <code>CronJob</code> 하나에 스케줄, 동시 실행 정책, 재시도 횟수, 실행 이력 보관 개수가 전부 필드로 들어 있습니다. 배치가 늘어나도 관리하는 방식은 같습니다. 배치가 필연이라는 걸 알고 있었으니 배치를 잘 다루는 런타임에서 시작하는 편이 쌌습니다.</p>
<h2 id="3-형상화하지-않으면-아무도-이유를-모릅니다">3. 형상화하지 않으면 아무도 이유를 모릅니다</h2>
<p>개인적으로 중요하게 생각하는 부분입니다.</p>
<p>손으로 만든 인프라는 만든 사람의 기억에만 남습니다. 이 서버에 왜 이 프로세스가 떠 있는지, 저 포트가 왜 열려 있는지, 저 환경변수는 어디서 온 건지. 6개월 뒤에는 만든 본인도 기억하지 못하고 새로 합류한 사람은 알 방법이 없습니다.</p>
<p>쿠버네티스에서 가장 크게 얻은 건 컨테이너 오케스트레이션보다도 <strong>모든 것이 표준으로, 선언적으로 남는다</strong>는 점이었습니다. 어떤 서비스가 몇 개 떠 있는지, 어떤 환경변수를 받는지, 어떤 리소스를 쓰는지, 어떤 배치가 언제 도는지를 전부 형상으로 남길 수 있습니다.</p>
<p>그래서 인프라 변경을 코드 리뷰에 올릴 수 있고, 되돌릴 수 있고, “언제 누가 왜 바꿨는지”가 히스토리로 남습니다. 사람이 적은 팀일수록 여기서 얻는 게 큽니다. 한 사람의 머릿속에만 있는 “<strong>표준이 아닌 도메인 지식</strong>“은 그대로 단일 장애점이 되니까요.</p>
<h2 id="4-observability-가-자연스럽습니다">4. Observability 가 자연스럽습니다</h2>
<p>“일단 만들고 나중에 모니터링 붙이자”고 해두면, 피처 개발에 밀려 있다가 장애가 한 번 나야 붙입니다. 그리고 그 장애의 원인은 로그도 메트릭도 없어서 끝내 모른 채 넘어갑니다.</p>
<p>운영의 흐름이 확정된 상태에서는 이 비용이 특히 컸습니다. “어제 오후에 예약이 안 잡혔다”는 문의가 들어왔을 때 그 시점의 로그와 메트릭, 트레이스가 없으면 답할 방법이 없습니다.</p>
<p>쿠버네티스에서 관측성은 나중에 얹는 레이어라기보다 이미 바닥에 깔려 있는 쪽에 가깝습니다. 파드가 stdout 으로 뱉은 로그는 런타임이 노드의 정해진 경로에 쌓아두고, kubelet 과 컨트롤 플레인은 처음부터 프로메테우스 포맷으로 메트릭을 노출합니다. 파드가 몇 번 재시작했는지, 왜 죽었는지가 OOMKilled 인지 프로브 실패인지도 리소스 상태에 그대로 들어 있습니다. 데이터는 이미 나오고 있고, 남는 일은 그걸 어디로 보낼지 정하는 것뿐입니다.</p>
<p>헬름 차트 하나로 메트릭과 알럿의 기본이 서고, opentelemetry collector 를 <code>DaemonSet</code> 으로 띄우면 그 노드 위의 모든 파드 로그가 따라 들어옵니다.
쿠버네티스 API 를 그대로 서비스 디스커버리로 쓰기 때문에, 워크로드에 라벨만 맞춰두면 새로 뜬 파드가 알아서 수집 대상이 됩니다. 네임스페이스, 파드, 컨테이너 같은 키가 로그와 메트릭과 트레이스에 똑같이 붙어 나오는 것도 따로 설계한 게 아니라 기본값입니다. 셋을 같은 축으로 이어 보는 데 드는 비용이 처음부터 0에 가까웠습니다.</p>
<p>서비스마다 Observability 를 따로 챙겨야 하면 결국 안 챙기게 됩니다. 플랫폼 레이어에서 기본으로 딸려오게 만들 수 있다는 점이 초기에 쿠버네티스로 간 이유 중 하나입니다.</p>
<h2 id="5-오픈소스를-올리는-비용이-거의-사라집니다">5. 오픈소스를 “올리는” 비용이 거의 사라집니다</h2>
<p>여기까지의 이유는 쿠버네티스가 아니어도 됩니다. 형상화는 Terraform 과 태스크 정의로 똑같이 남고, 배치와 관측성도 ECS Fargate 위에서 상당 부분 따라옵니다. 운영할 것이 우리 서비스와 배치뿐이었다면 관리형 서비스가 더 싼 선택이었을 겁니다.</p>
<p>결정을 가른 건 이번 섹션입니다.</p>
<p>우리가 맞닥뜨린 문제들의 해결을 위한 오픈소스가 넘쳐납니다. <strong>바퀴를 재발명하지 않기 위해서</strong> 손쉽게 가져다 쓸 수 있어야 합니다. 쿠버네티스 환경에서는 “이 오픈소스 한번 써볼까?“라는 생각이 들면 그날 바로 올려볼 수 있습니다.</p>
<p>저희 클러스터에는 자동화 도구 n8n, BI 도구 metabase, Knowledge Base 가 되는 onyx, SEO 분석을 위한 open-seo 등이 올라가 있습니다. 공통점은 올리는 데 전부 30분이 채 안 걸렸다는 것입니다.</p>
<p>쿠버네티스 안에서는 오픈소스의 배포 방식이 사실상 표준화되어 있습니다.
요즘 웬만한 설치형 오픈소스 프로젝트의 README 에는 이 두 줄이 있습니다.</p>
<pre data-language="bash"><code>helm repo <span>add</span> <span>..</span>.
helm <span>install</span> <span>..</span>.</code></pre>
<p>프로젝트 입장에서도 쿠버네티스가 배포 타깃의 공통 분모라서 그렇습니다. 사용자가 AWS 를 쓰든 GCP 를 쓰든 온프레미스이든, 차트 하나만 잘 만들어두면 다 커버가 됩니다.</p>
<p>덕분에 무엇이 필요해질지 몰라도, 그때 필요한 건 대체로 이미 차트로 있습니다. 데이터 파이프라인이 필요해지면 Airflow 가, LLM 호출을 추적해야 하면 Langfuse 가, 사내 도구들의 계정을 한 곳에서 관리해야 하면 Keycloak 이 있습니다. Postgres 나 Redis 처럼 원래 운영이 까다로운 것들도 Operator 형태로 나와 있어서, 백업과 페일오버까지 포함된 상태로 올라옵니다. (<del>물론 실제 운영은 지옥입니다</del>)</p>
<p>같은 일을 다른 환경에서 하려고 하면 매번 달라집니다. 어떤 프로젝트는 docker compose 로, 어떤 건 소스를 직접 빌드해야 하고, 어떤 건 systemd 유닛을 직접 짜야 합니다. 의존성으로 붙는 Postgres 와 Redis 는 또 따로 준비해야 합니다.</p>
<p>쿠버네티스에서는 서버 리소스만 남아 있으면 <strong>운영까지 생각하지 않고 일단 올려서 테스트</strong>해보는 데 드는 품이 거의 없습니다.</p>
<p>그러면 판단하는 방식이 달라집니다. “한번 써볼까?“를 스프린트에 올리지 않고 오후 시간에 해봅니다. 써보고 안 맞으면 <code>helm uninstall</code> 로 흔적 없이 지웁니다. 되돌리는 비용이 낮으니 시도하는 횟수가 늘어납니다.</p>
<p>라이선스가 허락하면 한 걸음 더 갈 수도 있습니다. 포크해서 필요한 부분만 고치고, 이미지를 우리 레지스트리에 올리고, 차트의 이미지만 바꿔 끼우면 됩니다. 배포도 운영도 원래 차트 그대로 굴러갑니다. 예전에는 이 선택지가 비쌌지만, AI 로 이 비용이 많이 낮아졌고, 고칠 지점을 찾는 데 걸리던 며칠이 몇 시간이 되었습니다.</p>
<p>물론 helm 차트가 만능은 아닙니다.</p>
<p>차트는 설치를 쉽게 해줄 뿐 운영을 쉽게 해주지는 않습니다. 다만 그 비용이 도구 개수만큼 곱해지지는 않습니다. 도구를 늘려도 운영하는 방식이 크게 늘어나지 않는 구조에 가깝습니다.</p>
<h2 id="6-그리고-솔직한-이유">6. 그리고 솔직한 이유</h2>
<p>위의 이유들이 그럴듯해도, 이 두 가지가 없었다면 다른 선택을 했을 겁니다.</p>
<h3 id="이미-익숙한-도구였습니다">이미 익숙한 도구였습니다</h3>
<p>“쿠버네티스는 러닝커브가 높다”는 말은 사실입니다. 다만 러닝커브는 도구의 속성이라기보다 <strong>팀과 도구 사이의 거리</strong>에서 나옵니다. 저는 커리어 내내 쿠버네티스 환경을 운영해왔고, 이제는 쿠버네티스 없으면 어떻게 배포하지 (…) 라는 생각이 듭니다. 그래서 도구를 선택하면서 치른 학습 비용이 0에 가까웠습니다.</p>
<p>같은 이유로, 팀에 쿠버네티스 경험이 없다면 저도 위의 이야기들과 무관하게 다른 선택을 했을 것 같습니다. 팀이 새벽 3시에 디버깅할 수 없는 도구는 좋은 도구가 아닙니다.</p>
<h3 id="aws-크레딧이-있었습니다">AWS 크레딧이 있었습니다</h3>
<p>비용 이야기의 상당 부분을 여기서 건너뛸 수 있었습니다. 컨트롤 플레인 비용, <del>아주 살짝</del> 여유 있는 노드 구성, observability 스택이 먹는 리소스가 초기에 부담이 되지 않았습니다.</p>
<p>크레딧은 언젠가 소진됩니다. 공짜라서 고른 건 아니고, 제대로 된 기반을 까는 데 드는 초기 비용을 크레딧이 대신 내줬습니다. 크레딧이 없었다면 더 검소한 구성으로 시작했겠지만, 선택 자체를 바꾸지는 않았을 겁니다.</p>
<h2 id="7-결국-피한-건-이관-비용입니다">7. 결국 피한 건 이관 비용입니다</h2>
<p>나중에 옮기는 비용이 처음에 까는 비용보다 큽니다.
특히나 서비스의 척추가 되는 인프라에 대해서, 한번 결정한 이후에는 마이그레이션이 쉽지 않습니다.</p>
<p>Day 1 에 쿠버네티스를 올리는 건 며칠짜리 일입니다. 서비스가 몇 개 없고, 트래픽이 없고, 데이터가 없고, 무중단으로 옮겨야 할 이유도 없습니다. 실수해도 지우고 다시 만들면 됩니다.</p>
<p>같은 일을 2년 뒤에 하면 분기 단위 프로젝트가 됩니다. 옮겨야 할 서비스가 많아지고, 각각 조금씩 다른 방식으로 배포되고 있고, 무중단으로 옮겨야 하고, 그 사이에도 제품은 계속 나가야 합니다. 그리고 그 분기 동안 팀은 고객에게 아무것도 주지 못합니다.</p>
<p>같은 결과물을 얻는 데 드는 비용이 시간이 갈수록 비싸진다면 그 일은 가능한 한 앞에서 해야 합니다. 특히 저희처럼 도메인이 이미 확정되어 있어서 “안 하게 될 가능성”이 낮은 경우에는요.</p>
<h2 id="마치며">마치며</h2>
<p>“초기 스타트업에 쿠버네티스가 필요한가”라는 질문에는, 조건을 빼고 물어보면 답이 없습니다.</p>
<p>저는 이렇게 바꿔서 스스로에게 묻는 편입니다.</p>
<blockquote>
<p>우리 팀이 3개월 뒤에 반드시 필요해질 것이 무엇이고, 그걸 그때 만드는 비용과 지금 만드는 비용의 차이는 얼마일까? 그리고 우리 팀은 그걸 감당할 수 있을까?</p>
</blockquote>
<p>저희의 경우, 프로토타이핑이 이미 끝나 있었고, 배치가 필연이었고, 관측성이 필요했고, 그 도구가 익숙했습니다. 그리고 활용해야 할 많은 오픈소스들이 눈에 보였습니다. 그래서 쿠버네티스를 선택했습니다.</p>
<p>조건이 다른 팀의 답은 다를 수 있고, 달라야 합니다. “우리 조건에서 무엇이 가장 싼 선택인가”를 직접 계산해 보는 것, 쿠버네티스든 아니든, 선택의 근거를 확실히 말해볼 수 있다면 그게 맞는 (맞아야 하는) 정답이 아닐까요.</p>
</div></div>

sungjunyoung

프로토타이핑이 이미 끝나 있던 팀이 Day 1부터 쿠버네티스를 선택한 이유를 배치, 형상 관리, 관측성, 오픈소스 도입 비용의 관점에서 정리해 봤습니다.

왜 스타트업에서 Day 1부터 쿠버네티스를 선택했을까

댓글