버려야 살아남는다: 제약 속 작은 팀의 선택법

필라델피아 남쪽, 한때 정유공장이 가동되던 부지에 데이터센터를 짓겠다는 계획이 나왔다. 지역 주민들이 즉각 반발했다. 이미 중금속에 오염된 땅, 천식 유병률이 도시 평균의 두 배를 넘는 동네에 이번엔 초고압 전선과 냉각탑이 들어선다는 소식이었다.

빅테크 입장에서 이 부지는 '최적화된 선택'처럼 보였을 것이다. 중공업 인프라가 이미 깔려 있고, 땅값이 싸고, 전력 인입이 쉽다. 체크박스를 채우면 합리적인 결정처럼 읽힌다. 그런데 그 결정이 몇 달 뒤 시의회 청문회, 환경영향평가 재심, 착공 지연으로 돌아오고 있다. 아껴야 했던 비용이 다른 형태로 배가돼 돌아오는 구조다.

이 패턴은 규모만 다를 뿐, 작은 팀에서도 정확히 반복된다.

빠른 최적화가 느린 재앙이 되는 순간

데이터센터 입지 선정은 전형적인 '단기 리소스 최적화' 결정이다. 지금 당장의 비용을 줄이는 데 집중하다가, 그 선택이 만들어낼 외부 효과를 계산에서 빠뜨린다. 필라델피아 케이스에서 회사들이 놓친 건 주민 감정이 아니다. 커뮤니티 반발이 행정 절차에 얽히면 얼마나 긴 지연을 만드는지, 그 지연이 초기에 아꼈다 싶었던 땅값의 몇 배를 날려버리는지다.

미국에서 데이터센터 관련 주민 반대 운동이 조직적 반대(organized opposition)로 번진 사례들을 분석하면, 착공까지 평균 14~18개월의 추가 지연이 발생했다는 보고가 있다. 전력 인프라 계약 변경, 각종 허가 재신청, 법적 검토가 한꺼번에 묶이면 단순 토지 비용 절감분은 순식간에 증발한다. '싸게 시작했더니 비싸게 끝난' 구조.

이 구조가 낯설지 않은 이유는 단순하다. 우리가 일상적으로 내리는 결정들이 이것과 닮아 있기 때문이다.

작은 팀의 '폐허 입지'

우리 팀에서 이와 닮은 결정이 나올 때가 있다. 유지보수가 사실상 멈춘 라이브러리를 계속 쓰는 것, 한 사람만 알고 있는 프로세스를 문서 없이 운영하는 것, 이미 낡은 코드베이스 위에 새 기능을 계속 얹는 것. 매번 '당장은 이게 빠르다'는 판단으로 시작한다.

직접 겪은 이야기를 하면, AI와 함께 VR 우주 핵추진 박물관을 제작할 때였다. 기존 씬 에디터 플러그인을 재활용하면 2주를 아낄 수 있었다. 기술 스택이 낡았고 커뮤니티 지원이 이미 끊긴 상태였지만, 일단 빠르게 가는 게 우선이었다. 결과는 4주 뒤 전체 씬을 다시 빌드하는 작업이었다. 아낀 2주가 4주 부채로 돌아왔다.

리소스가 제한된 팀일수록 이 함정에 빠지기 쉽다. 지금 당장 쓸 수 있는 걸 쓰는 게 합리적으로 느껴지기 때문이다. 그런데 '지금 당장의 합리성'이 중기 계획을 통째로 날리는 사례가 반복된다.

무엇을 버릴지가 전략의 핵심이다

필라델피아 데이터센터 논란에서 빅테크가 진짜 실패한 지점은 입지 선정 그 자체가 아니다. 버려야 했지만 버리지 않은 것, 즉 '현재 비용만 보는 의사결정 프레임'이다.

작은 팀의 운영에서 '무엇을 버릴지'는 전략의 핵심 변수다. 인력도, 시간도, 집중력도 유한하다. 봇 여러 개를 동시에 돌리다 보면 몸으로 배우게 된다. 새로운 걸 얹는 건 상대적으로 쉽다. 운영 중인 걸 끄는 건 훨씬 어렵고, 그래서 끊임없이 "이게 지금도 필요한가?"를 묻지 않으면 팀 리소스는 자연스럽게 낡은 것들로 잠식된다.

트레이드오프를 숫자로 보면 이렇다. 레거시를 유지하는 비용은 처음에 거의 0으로 보인다. 이미 돌아가고 있으니까. 그런데 이 숨은 비용이 누적된다. 유지보수 시간, 새 팀원이 이해하는 데 드는 시간, 문제가 생겼을 때 원인을 찾는 시간. 운영 중인 봇 하나가 디버깅에 하루를 잡아먹으면, 그날 새로 만들 수 있었던 걸 못 만든다. 기회비용은 보이지 않을 뿐, 사라지지는 않는다.

버려야 할 걸 버리지 못하는 팀은 결국 새로운 것을 시작할 여력 자체를 잃는다. 데이터센터가 낡은 정유 부지를 택했다 지역사회 부채를 떠안은 것처럼.

우리 팀이라면 어떻게 결정할까

리소스 결정에서 실제로 써보고 효과가 있었던 기준은 세 가지다.

첫째, "이 결정이 6개월 뒤에도 방어 가능한가?" 지금 당장의 속도 때문에 선택한 것이 반 년 후에도 합리적으로 보일지 묻는 것이다. 데이터센터 회사들이 이 질문을 제대로 했다면 '주민 반발이 예상되는 곳에 짓는 게 6개월 뒤에도 좋은 선택인가?'를 따졌을 것이다.

둘째, "이걸 유지하는 사람이 빠지면 어떻게 되는가?" 단일 의존성을 만드는 결정은 지금은 빠르지만, 의존하던 사람이나 시스템이 사라지면 팀 전체가 흔들린다. 이 리스크를 의사결정 시점에 가격표에 얹어야 한다.

셋째, "이걸 끝내는 비용을 지금 계산할 수 있는가?" 시작할 때 종료 방법이 없는 프로젝트나 기능은 처음부터 신중하게 봐야 한다. 데이터센터는 한번 지으면 40년이다. 기술 선택도 생각보다 길게 팀을 묶는다.

'반발이 예상되는 부지에 밀어붙이다 착공도 못 하고 수백억을 날린' 케이스처럼, '빠른 시작'이 결국 '가장 느린 경로'가 되는 순간은 생각보다 자주 온다.

지금 당장 써먹을 수 있는 기준

지금 운영 중인 프로젝트, 기능, 프로세스 목록을 꺼내라. 각각에 대해 "이게 없어지면 어떻게 되는가?"를 솔직하게 적어라. 대답이 "사실 별 영향 없다"거나 "담당자 한 명만 알고 있다"면, 그건 지금 당신 팀의 폐허 입지다.

월 1회, 30분짜리 '버릴 것 회의'를 제안한다. 새 기능 회의는 많아도 기존 것을 끄는 회의는 거의 없다. "이번 달 하나를 끈다면 무엇인가?"라는 질문 하나만 던지면 된다. 거창하게 시작할 필요 없다.

새 기능을 시작할 때 시작 문서가 아니라 종료 기준 문서를 먼저 써라. "이 기능이 언제, 어떤 조건이 되면 중단할 것인가"를 시작 시점에 정해두면 나중에 레거시로 굳어지는 걸 막을 수 있다. 필라델피아 데이터센터 사업이 "주민 반발이 이 수준을 넘으면 부지를 바꾼다"는 기준을 사전에 갖고 있었다면, 지금처럼 진퇴양난에 빠지진 않았을 것이다.

리소스 제약은 선택을 강제한다. 그 강제가 나쁜 게 아니다. 뭘 버릴지 명확하게 만들어주는 압력이다. 이 압력을 제대로 쓰는 팀이, 자원이 넘치는 팀보다 오히려 더 나은 선택을 하는 경우가 실제로 있다.

원문: AI News & Artificial Intelligence | TechCrunch