화려한 기술에 No 치는 것이 작은 팀의 실력이다

머스크가 스타십에 데이터센터를 실어 궤도에 올리겠다고 했을 때, 소프트뱅크 손 마사요시 회장이 먼저 의문을 제기했다. 테크크런치가 전한 이 장면은 단순한 억만장자들의 설전이 아니다. 거대한 자본도 멈추게 만드는 무언가가 이 '하이프'에 있다는 신호다.

그리고 그 신호에서 작은 팀이 배울 게 있다 — 무엇을 의심할지가 아니라, 얼마나 빨리 의심할지. 단, 이 판단을 너무 빠르게 적용하면 검증된 기술도 놓친다. 그 경계선이 어디인지가 오늘의 핵심이다.

궤도 데이터센터, 물리가 먼저 말한다

저궤도(LEO)의 물리적 현실부터 짚어야 한다. 지구 저궤도는 약 400~1200km 고도다. 빛의 속도(약 30만 km/s)로 계산해도, 데이터가 지상 서버에서 궤도 위성을 거쳐 다시 지상으로 왕복하면 최소 2.7ms의 전파 지연이 생긴다. 이론값이다. 실제 처리와 프로토콜 오버헤드까지 더하면 600ms 이상이 현실적이라고 전문가들은 지적한다. 그 어떤 데이터베이스도 600ms 레이턴시를 감당하면서 서비스를 제대로 돌리지 못한다.

비용도 마찬가지다. 스타십 기준 발사 비용이 kg당 100달러로 떨어진다는 게 머스크의 낙관 시나리오다. 서버랙 하나의 무게가 약 500700kg이니, 발사비만 57만 달러다. 거기에 냉각 문제가 붙는다. 우주엔 공기가 없어 대류냉각이 불가능하다. 대형 방열판이 필요하고, 방열판은 또 무게와 공간을 잡아먹는다. 장애 수리? EVA, 즉 우주유영이다.

소프트뱅크 회장도, 기술계의 여러 전문가도 같은 지점에서 멈췄다. "멋지다"와 "작동한다"는 전혀 다른 말이라는 걸 그들은 안다.

"나쁜 기술"이 아니라 "지금은 아닌 기술"

피해야 할 함정이 하나 있다. 궤도 데이터센터를 완전히 틀린 개념으로 치부하면 사고가 거기서 끝나버린다. 실제로 우주 기반 컴퓨팅은 장거리 위성통신이나 지구 관측 데이터 처리 같은 특수 목적에서 의미가 있다. 문제는 "AI 학습 일반 인프라"라는 맥락에서 이 기술을 팔고 있다는 거다.

머스크는 종종 장기 비전을 현재 해결책처럼 포장한다. 이 화법에 속으면 지금 당장 필요한 판단을 흐린다.

작은 팀이 이 뉴스에서 얻어가야 할 진짜 교훈은 기술 자체의 옳고 그름이 아니다. "업계 최고 투자자들도 멈추게 만드는 기술 하이프가 존재한다. 우리 팀은 그런 하이프를 얼마나 빨리, 얼마나 냉정하게 알아채는가?"라는 질문이다.

작은 팀에게도 같은 유혹이 온다

규모가 다를 뿐 구조는 같다. 새 LLM이 나올 때마다 "이걸 당장 붙여야 하나", 새 클라우드 서비스가 출시될 때마다 "우리 스택을 갈아야 하나", AI 컨설팅 업체가 찾아올 때마다 "이 솔루션이 우리 문제를 풀어주나" — 이 유혹들은 끊임없이 온다.

요즘은 챗GPT 활용법 도서가 서점마다 쏟아진다. 책마다 "이 방법이 업무를 혁신한다"고 말한다. 작은 팀은 그 책들을 다 읽을 시간도 없지만, 더 큰 문제는 읽고 나서 "이걸 다 해야 하나"는 부담이 생기는 것이다. 정작 팀의 진짜 병목이 어디 있는지 짚지도 않은 채.

HEDVION 팀도 비슷한 실수를 한 적 있다. 봇 인프라 초기에 Kubernetes 도입을 진지하게 검토했다. 이론상 스케일이 자유롭고 운영이 자동화된다. 실제론 팀 인원이 적어 클러스터 유지보수가 또 다른 전담 업무가 됐을 것이다. 결국 VPS + cron + systemd로 지금도 잘 돌아간다. 봇 14개가 하루 수십 건 발행하고, 장애 대응도 ssh 한 번이면 해결된다.

리소스 제약이 오히려 판단력을 준다

자원이 부족하면 선택이 강제된다. 이건 단점이 아니다. 머스크에게는 "궤도 데이터센터"가 테이블에 올라올 수 있다. 돈이 무한하면 검증되지 않은 선택지도 실험 대상이 된다. 작은 팀은 그럴 여유가 없다. 덕분에 "이게 지금 당장 작동하나?"라는 질문에서 출발할 수밖에 없다.

새 기술 도입의 실제 비용은 라이선스비가 아니다. 러닝커브와 유지보수 부담이 진짜 비용이다. SRE 팀이 있는 회사는 새 스택을 배울 인력을 따로 할당한다. 팀이 3~5명이면, 그 러닝커브가 기존 운영 부담 위에 그대로 올라탄다. 신기술 하나 붙이는 게 "오늘 못 하는 일"을 늘리는 결과가 된다.

실제로 AWS Lambda를 전면 도입했다가 콜드스타트 레이턴시와 로그 디버깅 불편 때문에 다시 EC2로 돌아온 소규모 스타트업이 꽤 있다. Lambda가 나쁜 기술이 아니다. 그 팀의 디버깅 역량과 운영 패턴에 안 맞았던 것이다.

우리 팀의 실제 의사결정 시나리오

새 AI 인프라 제안이 들어왔을 때 우리가 실제로 쓰는 필터를 공개한다.

첫 번째 질문은 "지금 당장 병목이 여기 있나?"다. 봇 발행 속도가 문제라면 LLM을 바꿔봤자 크롤러 딜레이가 병목이다. 진단 없이 해결책을 붙이면 비용만 나가고 상황은 그대로다.

두 번째는 "장애 났을 때 새벽 3시에 혼자 고칠 수 있나?"다. 운영 인력이 적은 팀에서 이 질문은 기술 선택의 최종 관문이다. 아무리 좋은 스택도 장애 시 대응이 복잡하면 팀 전체가 멈춘다. 우리가 systemd + journalctl 조합을 고집하는 이유가 여기 있다. journalctl -u blog-bot -n 50으로 새벽에 대부분 해결된다.

세 번째는 "6개월 뒤에도 이 기술을 아는 사람이 팀 안에 있나?"다. 구성원이 바뀌면 기술이 부채가 된다. 특정 사람만 아는 스택은 그 사람이 빠지면 블랙박스다.

머스크의 궤도 데이터센터는 이 세 질문을 하나도 통과하지 못한다. 현재 우주 인프라 현실에서 병목은 다른 곳에 있고, 새벽 3시 장애 대응은 EVA이며, 우주 운영 전문가는 팀에 없다.

지금 바로 쓸 수 있는 기술 선택 필터

판단의 순서를 고정해 두면 유혹에 흔들리지 않는다.

"지금 팀의 진짜 병목은 무엇인가"를 종이에 한 줄로 써라. 그 병목을 새 기술이 직접 건드리는지 확인한다. 직접 연결되지 않으면 도입 보류다. "나중에 필요할 수도 있어"는 검토 이유가 못 된다.

도입하기로 했다면 실제 운영 환경에서 72시간 테스트가 먼저다. 스테이징과 프로덕션은 항상 다르다. 레이턴시, 에러 핸들링, 외부 API 의존도는 실제 트래픽이 흘러야만 드러난다.

분기마다 한 번씩 도입한 기술 목록을 꺼내 "지금 없애도 되는 게 있나"를 물어라. 기술 결정은 도입보다 제거가 훨씬 어렵다. 능동적으로 제거하지 않으면 스택은 조용히 복잡해지고, 그 복잡함은 언젠가 팀의 속도를 갉아먹는다.

소프트뱅크 손 회장이 머스크에게 던진 의심 어린 시선 — 그게 작은 팀이 모든 기술 제안 앞에서 기본으로 탑재해야 할 태도다. 화려한 비전일수록, 멈추고 세 가지를 물어야 한다.

원문: AI News & Artificial Intelligence | TechCrunch