11주간의 Kubernetes 이전 후 회사, 존재 이유를 잊다 (2020)

 (theolognion.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 실리콘밸리 스타트업 Xenobroom Inc. 는 2020년 5월 팬데믹 중 일일 사용량이 급증하자 기존 서버 인프라를 Kubernetes로 이전하기로 함
  • 이전은 단순 배포 개선을 넘어 bash 스크립트와 VPS 기반 구성을 다시 검토하고 재설계하는 장기 작업으로 커짐
  • 의존성·라이브러리 업그레이드, PostgreSQL 일부의 분산 KV 스토리지 전환, AWS 유연성 활용까지 함께 추진되며 범위가 계속 넓어짐
  • 기존 staging 서버와 develop 브랜치 기반 일일 배포는 production-only CI 워크플로우, 동적 라우팅, A/B 테스트, 지역 의존성 지원으로 대체됨
  • 이전이 끝난 듯한 시점에는 구성원 누구도 제품의 목적을 기억하지 못했고, 사용자와 투자자도 원래 제품을 이해하지 못했다고 인정해 복원이 사실상 어려워짐

Kubernetes 이전으로 커진 작업 범위

  • Xenobroom Inc. 는 2020년 5월 서버 인프라 업그레이드를 시작함
    • CEO의 일지 조각과 CTO의 엔지니어링 노트에 따르면, 팬데믹 중 일일 사용량이 급격히 늘어남
    • 이후 기존 인프라를 Kubernetes로 이전하기로 결정함
  • 작업은 예상보다 길어짐
    • 단순한 bash 스크립트와 VPS 머신을 다시 만들고, 검토하고, 재엔지니어링해야 했음
    • 회사 내부에서는 이 기회에 소프트웨어 의존성과 라이브러리도 업그레이드할 수 있다고 봄
  • 인프라 변경은 더 큰 구조 개편으로 이어짐
    • 단일 머신에서 동작하던 PostgreSQL 데이터베이스의 큰 부분을 분산 KV 스토리지로 바꿀 수 있다고 판단함
    • AWS의 유연성을 활용한다는 명분도 붙음
    • develop 브랜치에서 매일 배포하던 단순 staging 서버는 사라짐
    • 대신 동적 라우팅을 갖춘 production-only CI 워크플로우가 도입되고, A/B 테스트와 지역 의존성을 매끄럽게 지원하는 구성이 됨

제품 목적 상실과 외부 도움

  • 이전 절차가 완료된 듯 보였을 때, 회사 안에서는 누구도 제품의 목적을 기억하지 못함
  • 사용자와 투자자도 상황을 해결하지 못함
    • 두 집단 모두 애초에 제품을 제대로 이해한 적이 없었다고 공개적으로 인정함
    • 몇 주간의 다운타임 이후 제품의 의미를 복원하는 일은 사실상 불가능해짐
  • CEO는 Phutar Afrayughum이라는 심령술사이자 초감각 지각 전문가에게 도움을 구함
    • 그는 Google의 메시징 앱 시장 점유율 증가를 도왔고 Material Design 프레임워크 개발에도 관여한 인물로 소개됨
    • 다만 이 도움은 “allegedly”로 처리돼 사실로 단정되지는 않음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 글이 더 웃김: 중간관리자 20%를 해고했더니 개발 생산성이 우연히 3배 증가했다는 내용
    https://www.theolognion.com/p/company-accidentally-increased...

    • 이건 풍자라고 보기도 어려움

  • 우리 $dayjob에서도 이런 이전 작업을 하는 중인데, 2년 전 시작했지만 아직 30%도 끝나지 않았음
    예전에 “Kubernetes로 가야 한다, 모놀리스를 죽여야 한다”고 가장 크게 외치던 사람들이 이제는 LLM을 만지작거리느라 Kubernetes는 잊어버림
    어떤 사람들은 개념 증명과 반짝이는 새것을 정말 좋아하고, 그 역할도 나름 쓸모는 있는 듯함

    • 새롭고 반짝이는 기술로 직무 만족을 얻는 구조임
      그래서 똑똑한 사람들이 비윤리적인 거대 기술 기업, 광고 회사, 감시 회사에서도 꽤 만족하며 일하는 것처럼 보임
      회사가 왜 존재하는지, 자기 컴퓨터 밖에서 실제로 무엇을 하는지는 별로 중요하지 않고, 기술과 새것을 추구할 자유가 중요함
      회사는 이들이 만들어내는 생산성과 열정을 좋아하고 보수도 잘 줌
      보통 이런 개발자들도 양심은 있는데, 그 양심은 기업 친화적인 선한 사회운동 형태로 흡수되어 전시되는 경우가 많음
    • 이건 범위 확장이라기보다 의도적인 이력서 주도 개발에 가까움
      누군가 “X를 해봤다”고 말하려고 체크박스를 하나씩 지우는 중임
      작은 팀에서는 이런 방식이 생산성을 정말 빠르게 멈춰 세울 수 있고, 흔히 모든 문제를 해결하려는 욕구로 포장됨
      하지만 그 결과 아무 문제도 해결되지 않고, 오히려 새 문제가 더 많이 생김
    • FAANG 인접 회사에서는 승진이 매우 어렵고, 레벨 체계 때문에 급여를 올리는 방법도 승진뿐인 경우가 많음
      승진에는 승진 패키지가 필요하고, 승진 패키지에는 크고 묵직한 프로젝트가 필요함
      결국 해결하려는 핵심 문제가 사업 필요가 아니라 승진이 되면서, 문제를 찾는 거대한 프로젝트들이 생겨남
    • 회사 돈 태우는 데는 쓸모가 있을지도 모름
      설명한 건 개념 증명조차 아닌 듯함. 개념 증명의 기본 조건은 일단 동작해야 한다는 것인데, 이건 무리를 따라가며 바빠 보이기 위한 구성을 만들어내는 쪽에 가까움
      직원 입장에서도 오래 머물기 좋은 환경은 아닐 듯함
    • 그런 사람들이 오히려 가장 많이 승진하는 사람들일 것 같음. 정말 꼬인 구조임

  • 그 블로그에는 더 웃긴 글도 많음. 특히 이게 마음에 들었음:
    https://www.theolognion.com/p/dev-builds-perfect-note-taking...
    그리고 이것도 있음:
    https://www.theolognion.com/p/ai-solves-all-political-econom...

  • 농담인 건 알지만, 사후 분석을 한다면 실패 원인은 아마 “회사 내 많은 사람이 이 기회에 소프트웨어 의존성과 라이브러리 업그레이드도 같이 하자고 생각했다. 단일 머신에서 돌아가던 PostgreSQL 데이터베이스의 큰 부분도 AWS의 엄청난 유연성을 활용해 분산 키-값 저장소로 바꿀 수 있다고 봤다”가 될 것 같음
    범위를 지켜야 함

    • 그게 바로 이 농담의 핵심에 가까움
      세상에는 자신들이 만드는 제품보다 사용하는 기술에 더 집중하는 사람이 많음
      제품에 집중한다는 건 범위를 알고, 너무 일찍 과도하게 설계하지 않는다는 뜻임
      농담은 Kubernetes에 집중하지만, 서버 측 렌더링, AI, $modernFrontendLib, $modernLanguage로도 똑같이 만들 수 있음
    • 회사의 범위도 지켜야 함
      사업이 클라우드 인프라 판매가 아니라면 기성 클라우드 제공자를 쓰면 됨
      이미 클라우드 제공자에 돈을 내고 있다면 특히 Kubernetes를 쓰지 않는 편이 나음

  • 현실에서는 11주짜리 Kubernetes 이전이면 대성공으로 인정받았을 것임

    • 실제로는 11개월이 걸리고, 이제 “클라우드 네이티브” 같은 상태가 됐을 것임
      물론 데이터베이스 운영은 조금 힘들었겠지. Kubernetes 저장소 설정을 제대로 해두는 걸 잊어서 파드가 갑자기 이동한 뒤 데이터가 사라졌을 테니까
    • 이미 Docker를 쓰고 있다면 그렇게 오래 걸릴 이유가 거의 없음
      Docker도 안 쓰고 있었다면, 비슷한 이전 작업에서 문제는 Kubernetes 자체가 아닐 가능성이 큼

  • 시스템을 운영하기가 지금만큼 쉽고 저렴했던 적이 없음
    그런데 엔지니어들은 피자 하나 배달하려고 원정대를 꾸리고, 에베레스트를 오르고, 정상에서 피자 사진을 찍은 다음, 다시 비행기로 집에 가져오고, Lamborghini를 빌려 몽골 랠리를 달린 뒤, 18개월 후에야 그 피자를 배달하려는 쪽을 선호함
    그동안 그냥 저렴한 스쿠터를 타고 길 아래로 내려가면 이김

    • 엔지니어가 주입한 복잡도가 경영진이 주입한 복잡도에 견줄 만했던 곳에서는 일해본 적이 없음

  • 복잡한 기술이라면 먼저 배워야 함. 작고 중요하지 않은 서비스에서 먼저 시도해야 함
    한 번에 하나만 하고, 단순하게 시작해야 함
    나는 우리 서비스를 문제없이 Kubernetes로 이전했지만, 작은 서비스들을 옮기며 배우고 실험하는 데 2년이 걸렸음
    여러 접근을 시도한 뒤 가장 적합한 방식에 도달했는데, 인터넷에서 바로 찾을 수 있는 방식은 아니었음
    GitOps를 쓰지만 자동화는 하지 않고, 필요한 것에 대해 그냥 kubectl apply -k를 실행함. 당시에는 flux가 시작하기엔 불필요하게 복잡하다고 판단했기 때문임
    이제 서비스가 수십 개가 되고 이해도도 생겨서, flux 도입을 생각하고 있음

  • 1977년에 시간 단위로 청구하는 로펌에서 젊은 재판 변호사로 일했음
    사건별로 어떤 일을 했는지 종이에 기록했고, 사무 직원들이 완료된 종이에서 떼어낼 수 있는 띠를 잘라 각 사건의 종이 폴더 안쪽 보드에 붙였음
    1979년에 RadioShack Tandy I를 샀고, 곧 집에서 DOS 기반 데이터베이스 프로그램인 Foxbase를 깊이 파고들었음. 나중에 FoxPro가 되었고 1990년대 초 Microsoft가 인수함
    1981년에 내 로펌을 열었고, 당시 사무 생산성의 최신 혁신은 팩스와 한 줄 화면, 메모리, 양식 저장용 작은 디스크가 달린 전동 타자기였음. 기업들은 아직 개인용 컴퓨터를 쓰지 않았음
    내 로펌은 곧 변호사 약 10명과 지원 직원 12명 규모가 됐고, 모든 비서에게 Compaq 컴퓨터를 사줬음
    수작업 띠 붙이기를 대체할 시간·청구 프로그램을 작성하는 데 많은 시간을 썼고, 네트워크 설치 방법도 배워 직접 설치함
    내가 알던 다른 로펌에는 컴퓨터가 하나도 없었지만, 우리는 지원 직원용 10대 이상과 고객에게 보내기 전 청구서를 검토할 변호사용 “휴대용” Compaq 4~5대를 갖췄음
    동시에 나는 사업을 망치고 있었음. 남들이 컴퓨터 한 대도 없던 시절에 세계 최고 수준의 기술을 갖췄지만, 변호 업무나 기업 고객 영업에 집중하지 않고 문 닫고 프로그래밍만 했음
    결국 1994년에 로펌을 닫았음
    그래도 흥분되는 시기였음. 곧 모든 로펌이 워드프로세싱용 컴퓨터를 갖추게 됐지만 상용 청구 프로그램은 아직 없었음
    약 24개월 동안 함께 일한 다른 로펌의 변호사들이 모두 내 청구 프로그램을 원했음
    하지만 나는 사건 업무에 허덕이면서도 재미있는 프로그래밍에만 몰두했고, 내 법률 업무는 프로그램을 위한 완벽한 실험실이었음. 아쉽게도 그 프로그래밍이 내 사업을 망쳤음

    • 그 떼어내는 띠 방식이 정말 흥미로움. 당시 시간 추적에 흔한 방식이었는지 궁금함
      혹시 사진이 남아 있으면 보고 싶음

  • 내 분야에서는 “Kubernetes”를 GraphQL/React/Next로 바꿔도 그대로 맞음
    물론 완벽히 잘 동작하는 앱, 그것도 대부분 CRUD인 앱을 옮기기 위한 일임
    GraphQL이나 상호작용형 프런트엔드가 주는 절충이 전혀 필요하지 않은데도 그렇게 함
    이 업계에 오래 있을수록, 책임 있는 자리에 있는 사람들이 자신들이 뭘 하는지 모르는 경우가 많다는 걸 더 많이 봄

    • 사람들은 계속 잘 돌아가게 유지하는 일로는 보상받지 못함
      변화에 대해 보상받고, 그 변화가 성과를 내고 있거나 언젠가 낼 것처럼 최소한 가장할 수 있으면 됨

  • 자체 호스팅 MinIO에서 관리형 블롭 저장소로 50만 개 블롭을 옮기려고 4개월 동안 밤낮으로 싸우는 중인데, 정치와 관료주의가 아닌 실제 생산적인 작업은 1주도 안 됨
    그래서 11주짜리 Kubernetes 이전이면 대성공처럼 들림

답변달기