속도를 택할 때 무엇을 포기하는가

머스크가 선택한 건 18개월이다. SpaceX가 비공개 주조 시설을 직접 세워 터빈 블레이드를 캐스팅하면, 경쟁사보다 가스 발전을 18개월 빠르게 가동할 수 있다는 계산이다.

이 논리는 작은 팀에도 그대로 적용된다. 단, 머스크가 18개월과 함께 인수한 것 — 오염 소송, 지역 건강 역학 연구, 시설 자체의 환경 규제 분쟁 — 을 함께 봐야 배움이 완성된다. 속도를 얻으면 반드시 청구서가 따라온다. 그 청구서를 아는 채 선택했는지, 모른 채 선택했는지가 팀 운영의 품질을 가른다.

공급망 병목을 직접 제거한다는 것

터빈 블레이드는 고온 정밀 합금 부품이다. 전문 제조사가 몇 없고, 납기 대기열도 길다. 외부에서 조달하면 프로젝트 전체 일정이 공급망에 종속된다. SpaceX는 그 병목을 내재화하기로 했다.

수직통합은 대부분의 경우 비효율적인 선택이다. 전문 공급사가 이미 규모의 경제를 갖추고 있어서, 거기에 올라타는 편이 싸다. 그럼에도 직접 주조를 택한 이유는 단 하나다. 기다리는 비용이 직접 만드는 비용을 초과했기 때문이다.

작은 팀도 이 계산을 매일 한다. SaaS를 구독할까, 직접 짤까. 외주를 줄까, 내부에서 처리할까. 기준은 언제나 같다. 기다리는 비용이 얼마인가, 그리고 직접 했을 때 무엇을 포기해야 하는가.

18개월이라는 숫자의 무게

데이터센터 전력 수요가 연 30~40% 성장하는 지금, 18개월은 단순한 납기 차이가 아니다. 경쟁사보다 먼저 공급 계약을 체결하면 이후 몇 년치 수익 구조가 달라진다. AI 인프라 시장에서 18개월 선점은 시장 진입 자체를 결정하는 숫자다.

작은 팀에도 이런 '18개월'이 있다. 어떤 기능을 외주사에 맡기면 3개월이 걸리는데, 직접 짜면 6주에 끝낼 수 있다면? 그 6주 차이가 SEO 골든타임일 수도 있고, 경쟁 서비스 론칭 전후를 나눌 수도 있다.

단, "직접 하면 빠르다"는 계산이 항상 성립하진 않는다. 유지보수 비용, 전문성 부재로 인한 오류, 예상 못한 재작업이 나중에 합산되면 외주보다 비싸지는 경우가 실제로 꽤 많다. 그래서 이 판단은 한 번으로 끝내면 안 된다. 분기마다 재검토가 필요하다.

소송이 함께 온다는 것

머스크는 18개월을 얻은 대신, 각지 가스 터빈 발전소를 둘러싼 오염 소송과 건강 연구를 함께 인수했다. 주조 시설 자체의 환경 문제도 별개로 따라온다.

"외부효과를 무시했다"는 비판은 쉽게 할 수 있다. 하지만 작은 팀 운영자 입장에서 다른 프레임으로 읽히는 지점이 있다. 그는 어떤 비용을 감수할지 의식적으로 선택했다. 모호하게 회피한 게 아니라, 명확하게 선언한 것이다.

직접 경험해보니 — 발행 봇을 처음 만들 때 코드 품질과 배포 속도 사이에서 계속 타협을 했다. 완벽한 아키텍처보다 일단 돌아가는 것을 택했고, 그 기술 부채는 몇 달 뒤 조용히 청구서로 날아왔다. 머스크의 오염 소송과 구조적으로 같은 이야기다. 규모만 다를 뿐이다.

우리 팀이라면 이 논리를 어떻게 쓸까

헤드비온에서 봇을 운영하면서 비슷한 갈림길을 자주 만난다. 챗GPT 활용방법처럼 외부 AI 서비스를 바로 가져다 쓰는 건 "사오는" 결정이다. 빠르고, 즉시 쓸 수 있고, 유지보수도 외부에서 한다.

반면 공통 claude_cli 헬퍼를 직접 만들어 전 봇이 함께 쓰게 한 건 "만드는" 결정이었다. 초기 구축 비용이 들지만, 이후 모든 봇이 동일 패턴으로 돌아가면서 운영 일관성이 확보됐다. 이게 우리 팀의 18개월이었다. 각 봇마다 API 연결 방식이 달랐다면 장기 유지보수 비용이 폭증했을 것이다.

머스크식으로 질문을 바꾸면 이렇다. "이 결정이 우리 팀의 핵심 병목을 제거하는가?" 단순히 무엇이 더 싸냐가 아니다. 이 선택이 이후 팀 전체 일정을 지배하는 병목을 없애는가, 그게 기준이다. 그렇다면 약간의 부채를 감수할 수 있다. 아니라면 그냥 사오는 편이 낫다.

실제로 우리 팀에서 쓰는 기준이 있다. 어떤 작업이 주 3회 이상 반복된다면 자동화 후보다. 하지만 그 자동화 코드가 실패했을 때 30분 이상 디버깅해야 하는 구조라면, 그건 리소스를 절약한 게 아니라 이동시킨 것에 불과하다. 자동화의 복잡도가 원래 작업의 복잡도를 넘기 시작하면 그게 멈추고 다시 생각해야 할 신호다.

포기할 것을 먼저 정하는 팀이 빠르다

머스크 결정의 본질은 "납기 속도를 택하고, 환경 리스크는 감수한다"는 선언이다. 그 선택이 도덕적으로 옳은지는 별개 문제다. 무엇을 포기할지 명확히 했기 때문에 실행 속도가 나왔다는 점이 핵심이다.

작은 팀이 느린 이유는 대개 선택을 회피하기 때문이다. A도 하고 싶고 B도 포기하기 싫어서 절충점을 찾다가 결국 둘 다 반만 한다. 이 패턴이 반복되면 팀은 바쁜데 완성되는 게 없는 상태에 빠진다.

"이 프로젝트에서 우리가 명시적으로 포기하는 것은 무엇인가"라는 질문을 소리 내어 말하는 습관, 생각보다 강력하다. 답을 못 하면 아직 선택을 하지 않은 것이다.

지금 바로 써먹을 수 있는 것

현재 팀이 직접 만들고 있는 것들을 한 줄씩 적어라. 각 항목 옆에 하나만 적으면 된다. "이게 우리의 핵심 병목을 제거하는가, 아니면 그냥 직접 하는 게 익숙해서인가." 후자라면 SaaS 전환이나 외주를 진지하게 검토할 대상이다.

기술 부채나 운영 부하가 쌓이고 있는 영역을 하나 골라라. 그 부하가 의식적으로 감수한 비용인지, 그냥 처리를 미뤄온 것인지 구분해라. 전자는 청산 일정을 잡으면 된다. 후자는 다음 스프린트에 지금 당장 넣어야 한다.

팀 내 의사결정에서 "무엇을 포기하는가"를 반드시 글로 남겨라. 6개월 뒤에 왜 그 선택을 했는지 추적할 수 없으면 같은 결정을 또 반복하게 된다. 머스크의 주조 시설 결정도 어딘가에 기록됐을 것이다 — 오염 소송을 대비해서라도.

원문: AI News & Artificial Intelligence | TechCrunch