AI 거품이 터지면 내 개발 환경은 7배 느려진다. 내 커밋 92%가 거기 얹혀 있었다

빅테크가 데이터센터를 빚으로 짓는다는 얘기를 올해 초부터 계속 봤는데, 볼 때마다 내 일과 무슨 상관인지가 잘 안 붙었다. 주식 얘기로 읽히니까 넘겼다. 그런데 어제 숫자 하나를 보고 생각이 바뀌어서, 내가 쓰는 추론 비용과 그 부채가 어디서 만나는지 종이에 그려봤다. 만나는 자리가 네 개 나왔고 넷 다 내 워크플로우 안이었다. 여기까진 예상한 결론이었다…

같이 나온 게 내 의존도였다. 회사 레포에서 내 커밋을 월별로 세보니 3월에 49%였던 게 5월부터 92%에서 안 내려오고 있었다. 그 숫자를 나는 모르고 있었다.

장부 밖에 얼마가 서 있나

숫자부터 본다. 니케이가 7월 23일에 알파벳과 마이크로소프트, 아마존, 메타, 오라클 다섯 곳의 장부 밖 부채를 1조 6,500억 달러로 집계했다. 4년 만에 여덟 배다.

이 숫자가 의미를 갖는 건 비교 대상이 있을 때다. 같은 다섯 회사가 장부에 올려둔 부채는 약 1조 3,500억 달러다. 장부 밖이 장부 안보다 크다. 메타 한 곳이 4,200억 달러를 장부 밖에 두고 있다.

어떻게 장부 밖에 두나. 데이터센터를 직접 짓지 않고 특수목적법인을 세운다. 그 법인이 채권을 발행하거나 사모 대출을 받아 돈을 빌리고, 빅테크는 그 법인과 장기 임대 계약을 맺어 컴퓨팅 용량만 받는다. 빌린 돈은 그 법인 장부에 잡히고 빅테크 장부에는 임대료만 남는다. 자본적 지출이 아니라 임차료로 기록되니까 감가상각 흐름도 달라진다. 메타가 텍사스에 짓는 1기가와트급 데이터센터가 이 방식이다. 125억 달러가 들어가는데 그 시설을 소유한 회사를 따로 세우고 사모 신용 펀드가 지분 대부분을 가져간다.

위험이 사라진 게 아니라 이동한다. 그 법인에 돈을 댄 채권 투자자와 보험사, 연기금이 위험을 든다. 빅테크는 계약상 일정 대가를 치르고 그 구조에서 빠져나올 선택권을 갖는 경우가 많다. 구조가 2008년 이전의 부채담보부증권과 겉모습이 닮았다는 지적이 여기서 나온다. 완전히 같지는 않다. 기초자산이 주택담보대출이 아니라 실제로 가동되는 데이터센터이고, 임차인이 세계 최대 현금 창출 기업들이다. 다만 위험을 장부 밖으로 옮기고 여러 겹의 법인을 거치게 만든다는 설계는 같은 계열이다.

규모도 커지고 있다. 빅테크가 2026년에 발행한 투자등급 채권이 1,820억 달러로 기록을 세웠고, 알파벳과 아마존, 메타, 마이크로소프트, 오라클의 이번 회계연도 설비투자 합계는 6,900억 달러를 넘을 것으로 집계된다. 벌어들이는 돈으로 감당할 수 있는 선을 넘어서면서 외부 조달이 늘어난 구조다.

채권 시장은 이걸 이미 다르게 값 매기고 있다. 로이터가 7월 29일에 정리한 부도 보험료를 보면 오라클이 200bp 근처, 메타가 93bp, 엔비디아가 78bp다. 같은 기사에 투자등급 지수가 53bp라고 적혀 있으니 오라클은 그 네 배 가까이 붙어 있다. 지구상에서 현금이 가장 많은 축에 드는 회사들에 매겨진 값이다.

여기서 한 번 멈췄다. 나는 이 회사들을 "돈이 남아서 뭘 해도 되는 곳"으로 놓고 내 워크플로우를 짜왔다. 그 전제가 채권 시장에서는 이미 안 통하고 있었다.

자산은 3년, 빚은 20년

이 구조에서 개발자가 봐야 할 대목은 총액이 아니라 기간이다.

AI 서버는 18개월에서 36개월이면 교체 대상이 된다. 다음 세대 가속기가 나오면 구형으로는 최신 모델 학습 경쟁에 못 낀다. 그런데 그 서버를 산 돈의 만기는 5년에서 20년이다. 자산이 값을 거의 다 잃은 뒤에도 원리금이 남는다.

100만 원짜리 장비를 10년 할부로 사고 3년 만에 갈아치우는 구조라고 보면 된다. 3년 뒤에 새 장비를 또 사야 하는데 앞 장비의 할부가 7년 남아 있다. 그래서 또 빌린다. 이게 반복되면 이자 비용이 누적되고 데이터센터 프로젝트의 수익성 계산이 계속 나빠진다.

이 기간 불일치가 표준적인 신용 모델에서 잘 안 잡힌다는 지적이 있다. 임대 계약의 현금 흐름은 예측 가능한 형태로 들어가는데, 그 계약을 뒷받침하는 자산이 계약 기간의 절반도 안 돼서 경쟁력을 잃는다는 사실은 별도로 계산해야 한다. 서버를 계속 새것으로 바꿔주는 비용이 어느 쪽 장부에 있는지, 그걸 누가 부담하는지가 계약마다 다르다.

감가상각 가정도 같은 자리에서 논쟁이 된다. 서버의 내구연한을 몇 년으로 잡느냐에 따라 분기마다 비용으로 털어내는 금액이 달라진다. 길게 잡으면 지금 이익이 좋아 보이고 짧게 잡으면 나빠 보인다. 그런데 실제 교체 주기는 회계 가정과 무관하게 다음 세대 가속기가 언제 나오느냐로 정해진다. 장부상 5년으로 잡아둔 장비를 3년 만에 갈아치우면 그 차액이 언젠가 한꺼번에 나타난다. 이걸 두고 현재 이익이 실제보다 좋게 보이고 있다는 분석이 반복해서 나온다.

여기서 개발자 입장에서 중요한 건 논쟁의 승패가 아니다. 내가 쓰는 추론 서비스의 원가가 회계 가정에 따라 달라 보인다는 사실 자체다. 지금 가격이 지속 가능한지를 가격표만 보고는 판단할 수 없다는 뜻이 된다.

한 가지 구분을 해두면 이 얘기가 내 쪽에 더 정확하게 붙는다. 빚으로 산 가속기는 용도가 두 갈래다. 하나는 모델을 학습시키는 데 쓰고 다른 하나는 사용자 요청을 처리하는 데 쓴다. 회수 구조가 다르다. 추론 설비는 쓰는 만큼 돈이 들어오니 사용량이 늘면 회수된다. 학습 설비는 다음 모델이 얼마나 좋아지고 그게 얼마나 팔릴지에 대한 베팅이라 회수가 몇 년 뒤로 밀린다.

문제가 생기는 자리는 학습 쪽인데 값이 조정되는 자리는 추론 쪽이다. 학습 설비 투자는 몇 년짜리 결정이라 중간에 세우기 어렵고, 세우면 경쟁에서 빠지는 걸 인정하는 셈이 된다. 그래서 손대기 쉬운 데를 손댄다. 이미 사용자가 붙어 있고 매달 돈이 들어오는 추론 쪽 단가와 정책이다. 학습 쪽에서 벌어진 계산 착오의 청구서가 내 API 사용료로 넘어오는 구조다.

수익성이 나빠지면 두 방향으로 움직인다. 하나는 설비 투자를 늦추는 것이다. 반도체 주문이 줄고 공급망이 먼저 체감한다. 다른 하나는 이미 깔아둔 설비에서 더 받아내는 것이다. 개발자에게 실제로 오는 건 두 번째다.

여기까지가 뉴스에 나오는 얘기고, 내가 알고 싶었던 건 그 다음이었다. 두 번째 방향이 구체적으로 내 쪽에 어떤 모양으로 도착하나.

순환 거래가 만드는 매출

한 가지 사례를 먼저 봐야 그림이 완성된다. 엔비디아가 오픈AI의 오하이오 데이터센터 부채 2,500억 달러를 보증하는 방안을 검토한다는 보도가 7월 27일에 나왔다. 별도로 오픈AI의 엔비디아 칩 구매 3,500억 달러어치를 금융 지원하는 안도 거론된다.

왜 보증이 필요한가. 오픈AI에는 투자등급 신용등급이 없다. 대주들이 오픈AI의 신용으로는 이 규모에 값을 매길 수 없다. 엔비디아가 뒤에 서면 대주는 엔비디아의 신용으로 값을 매긴다. 오픈AI는 그 돈으로 데이터센터를 짓고 그 안에 엔비디아 칩을 채운다. 엔비디아 장부에는 매출이 찍힌다.

현금을 거의 쓰지 않고 시장을 만든 셈이다. 2026년까지 이런 형태로 얽힌 거래가 8,000억 달러를 넘는다는 분석이 나와 있다. 엔비디아가 오픈AI에 투자하고, 오픈AI가 오라클 같은 클라우드에 수천억 달러를 약정하고, 그 클라우드가 약정을 이행하려고 엔비디아 GPU를 사고, 같은 지출이 여러 회사의 매출이나 수주 잔고로 동시에 잡힌다.

이 구조에서 수요는 실제로 존재한다. 칩은 실제로 팔리고 데이터센터는 실제로 돌아간다. 다만 그 수요의 일부가 빌린 돈으로 만들어진 수요다. 대금을 치를 쪽이 대금을 받을 쪽의 보증으로 돈을 빌렸다면, 그 매출은 수요를 반영하는 신호로서는 힘이 약하다. 빌린 돈이 안 돌아오기 시작하면 수요가 먼저 멈춘다.

개발자에게 이게 왜 상관있냐면, 수요 신호가 로드맵을 정하기 때문이다. 내가 쓰는 모델의 다음 버전이 언제 나오고 컨텍스트가 얼마나 늘어나고 단가가 어떻게 잡히는지는 전부 "이만큼 팔린다"는 계산 위에 서 있다. 그 계산에 순환 거래로 만들어진 몫이 섞여 있으면 계획의 정확도가 떨어진다. 실제 사용량이 예상만큼 안 나왔다는 판단이 서는 순간 조정되는 건 학습 설비 계획이 아니라 서비스 단가와 지원 정책이다. 앞쪽은 몇 년짜리 결정이라 못 되돌리고 뒤쪽은 공지 한 장이면 된다.

내 의존도를 세봤다

여기까지 읽고 나서 의문이 하나 생겼다. 이게 흔들리면 내 쪽에서 흔들리는 게 얼마나 되나. 감으로는 "많이"인데 숫자를 본 적이 없었다.

회사에서 맡고 있는 데스크톱 오디오 앱 레포에서 세봤다. 커밋 메시지에 AI 사용 여부를 표기하는 규칙이 있어서 셀 수 있는 자리였다. 내 커밋만 골라서 세면 이렇게 나온다.

월	내 커밋	AI 사용	비율
3월	74	36	49%
4월	22	16	73%
5월	94	88	94%
6월	59	54	92%
7월	63	58	92%

넉 달 만에 절반에서 열 중 아홉으로 올라가서 거기 머물렀다. 표기 규칙이 생긴 3월 12일 이후 전체로 보면 내 커밋 283건 중 254건, 89.8%다.

처음 셌을 때는 다른 숫자가 나왔다. 레포 전체 기간에서 내 커밋 1,533건 중 표기가 붙은 게 255건이라 16.6%였고, 그걸 최근 3개월 92.6%와 나란히 놓고 "3개월 만에 여섯 배가 됐다"고 쓸 참이었다. 쓰기 전에 한 번 더 확인한 게 표기 규칙이 언제 생겼는지였다. 2026년 3월 12일이었다. 그 전 커밋은 AI를 안 썼다는 뜻이 아니라 표기할 칸이 없었다는 뜻이다. 16.6%는 내 의존도가 아니라 규칙 도입 시점을 재고 있었다.

이걸 놓쳤으면 여섯 배라는 없는 숫자를 글에 박았을 것이다. 증가 자체는 실제로 있었다. 다만 폭이 49%에서 92%이고, 3월과 4월 사이에 이미 절반을 넘었으니 "최근에 갑자기"도 아니다.

정정한 숫자로 읽어도 결론은 같다. 지금 내 작업 열 건 중 아홉 건이 외부 추론 서비스가 정상 가격에 정상 속도로 동작한다는 가정 위에 있다. 그 가정이 흔들리는 사건이 앞의 부채 구조에서 나오는 경로다. 4월과 5월 사이에 73%에서 94%로 올라간 그 한 달이 특히 눈에 걸린다. 그때 내가 워크플로우를 크게 바꿨다는 자각은 없었다. 편해서 계속 썼고, 편한 게 어디까지 갔는지는 세보기 전까지 몰랐다.

내 쪽으로 오는 경로 네 갈래

종이에 그려봤을 때 나온 경로는 이렇다. 넷 다 이미 조금씩 일어나고 있는 일이라 상상은 아니다.

추론 단가. 지금 내가 쓰는 API 가격은 설비를 다 깔아둔 회사가 점유율을 위해 매기는 값이다. 원리금 부담이 커지면 그 값이 올라간다. 정확히는 표시 가격이 안 올라도 실질이 오른다. 컨텍스트 과금 구간이 조정되거나, 캐시 할인율이 줄거나, 같은 값에 더 작은 모델이 붙는 방식으로 온다. 나는 캐시 재사용 비율이 높은 형태로 일하는데, 캐시 읽기 단가가 기본 입력의 10분의 1 수준이라는 전제가 지금 내 비용 구조의 대부분을 설명한다. 그 비율이 5분의 1로 조정되면 표시 가격은 그대로인데 내 청구서는 두 배가 된다. 가격표를 보고 있으면 이런 변화를 놓친다.

저가 티어의 축소. 무료와 저가 구간은 원가 이하로 파는 자리다. 회수를 서두르면 여기가 제일 먼저 줄어든다. 한도가 낮아지거나, 동시 요청 수가 제한되거나, 저가 구간에서만 구형 모델을 주는 방식으로 바뀐다. 사이드 프로젝트나 개인 도구를 이 구간에 얹어둔 사람은 여기서 먼저 만난다. 나도 이 블로그 자동화를 그런 구간에 얹어놨다. 회사 일은 예산이 있어서 단가 인상을 흡수할 수 있는데 개인 프로젝트는 그럴 자리가 없다.

모델 지원 종료 가속. 구형 가속기에서 구형 모델을 계속 서비스하는 건 비용이다. 회수를 서두르면 지원 종료 주기가 짧아진다. 이게 제일 아픈 경로다. 단가는 예산으로 흡수할 수 있지만 모델이 사라지면 지시문과 워크플로우를 다시 맞춰야 한다.

이게 왜 반나절씩 가는지는 겪어보면 안다. 모델을 바꾸면 우선 출력 형식이 미묘하게 어긋난다. 표를 달라고 했는데 열 순서가 바뀌거나, 코드 블록 앞에 설명을 한 줄 더 붙이거나, 목록의 들여쓰기가 달라진다. 자동화가 그 출력을 파싱하고 있으면 여기서 깨진다. 그러면 판단이 하나 필요해진다. 파서를 새 형식에 맞출 것인가, 지시문을 고쳐 예전 형식을 다시 얻을 것인가. 파서를 고치면 앞으로 모델이 또 바뀔 때마다 같은 일을 한다. 지시문을 고치면 새 모델의 자연스러운 출력과 싸우게 되고 그쪽이 대체로 더 부서지기 쉽다.

형식이 맞아도 판단의 결이 달라진 부분이 남는다. 예전 모델이 짧게 답하던 자리에서 새 모델이 길게 설명하거나, 확신 없는 자리를 그냥 단정하고 넘어가거나 한다. 이건 회귀 테스트로 안 잡힌다. 출력이 유효하기 때문이다. 며칠 써보고 나서야 "여기가 전보다 헐거워졌다"를 알아챈다.

그래서 지원 종료가 분기마다 오면 그건 비용이 아니라 일정 리스크다. 예산으로 흡수할 수 없고 사람 시간으로만 흡수된다.

용량 배분. 네 번째 경로가 하나 더 있는데 이건 가격이 아니라 접근성으로 온다. 설비 투자를 늦추면 신규 용량이 늦게 들어오고, 그러면 붐비는 시간대의 요청 한도나 동시성 제한이 먼저 조여진다. 가격표는 그대로인데 피크 시간에 대기가 생기는 형태다. 이건 청구서에 안 나타나니까 원인을 엉뚱한 데서 찾게 된다.

네 경로를 적어놓고 보니 공통점이 하나 있었다. 넷 다 내가 통제하지 못하는 변수다. 그래서 통제할 수 있는 쪽을 봤다. 대안이다.

대안을 이미 재봤는데 결과가 나빴다

작년에 M4 맥북에 Qwen3.5 122B를 깔고 닷새를 살아봤다. 그때 목적은 비용 절감이었고 결과는 성공이었다. API 비용이 닷새 기준 45달러에서 14달러로 떨어졌다.

지금 같은 숫자를 다시 보면 의미가 다르다. 그건 비용 실험이 아니라 탈출 경로 점검이었고, 점검 결과는 경로가 좁다는 쪽이었다.

속도가 그렇다. Ollama에서 짧은 답이 6에서 8 토큰/초, 긴 답은 5에서 6 토큰/초였다. 백엔드를 MLX-LM으로 바꾸니 12에서 14로 올랐다. 두 배 넘게 빨라졌는데도 API의 100 토큰/초 이상과 비교하면 7배 차이다. 그때 메모에 "한 자릿수가 두 배가 돼도 한 자릿수다"라고 적어놨다.

체감은 작업 종류로 갈렸다. 한 줄 답에서는 7배가 거의 안 느껴진다. 첫 토큰 지연이 두 환경에서 비슷하기 때문이다. 컨텍스트가 4K 정도일 때 3초, 12K로 올라가면 6초까지 갔는데 이 구간은 클라우드도 사람이 기다리는 체감상 크게 다르지 않다. 차이는 긴 출력에서 누적된다. 60줄쯤 되는 코드를 부탁하면 Qwen은 4분, Opus는 8초였다. 4분은 흐름이 끊기는 시간이다.

자원도 좁았다. 모델 파일이 70GB, 메모리 점유가 약 55GB였다. 64GB 통합 메모리에서 다른 앱에 남는 게 8에서 9GB다. 크롬을 닫고 작업했다. 글을 쓰다가 컨텍스트가 12K로 올라가니 부담이 커져서 Gemma 3 27B Q4로 갈아탔다. 17GB짜리라 같은 컨텍스트가 훨씬 가볍다. 글이 끝날 무렵엔 다시 Qwen으로 돌아왔고, 한 작업 안에서 모델을 두 번 갈아타는 패턴이 생겼다. 클라우드에서는 해본 적 없는 일이다. 갈아타는 데 10분쯤 썼고 그걸로 아낀 돈이 0.4달러였다.

10분에 0.4달러. 이 비율이 지금 이 글의 요점 중 하나다. 단가가 오르면 이 비율은 좋아진다. 문제는 좋아져도 4분은 여전히 4분이라는 것이다. 돈으로 환산되는 손해와 시간으로 오는 손해를 따로 평가해야 한다는 걸 그때 배웠다.

기계 안에 안 쓰는 연산 장치가 있다는 것도 그때 확인했다. M4 Max에 38 TOPS짜리 신경망 처리 장치가 박혀 있는데 로컬 추론은 그걸 안 쓴다. MLX가 Metal 경유로 GPU를 쓰는 쪽이 더 빠르고, 신경망 처리 장치는 Core ML을 거쳐야만 접근이 되니 오픈 진영 도구가 들어가지 못한다. 트렁크에 엔진을 하나 더 싣고 다니면서 안 쓰는 상태였다.

회사 차원도 답이 아니었다

노트북이 좁으면 회사 장비는 어떤가 싶어서 그것도 사내 GPU 워크스테이션에서 재봤다. RTX Pro 6000 Blackwell 96GB 한 대에 같은 모델을 올렸다.

혼자 쓸 때 35 토큰/초가 나왔다. 노트북보다 훨씬 낫고, 배터리와 발열은 데스크탑 클래스라 애초에 변수가 아니다. 그런데 다섯 명이 동시에 들어오니 큐가 쌓이면서 다시 한 자릿수로 떨어졌다. 노트북에서 만난 한 자릿수를 회사 장비에서 다시 만난 자리였다.

더 의외였던 건 회계였다. 시트당 단가를 분해해봤더니 우리가 쓰던 클라우드 제로 데이터 보존 계약보다 비싸게 나왔다. "API 호출 0"이 KPI로는 깔끔한데 회계로 가면 네 줄로 쪼개진다. 시트당 단가, 안정성, 자율성, 모델 지원 종료. 이걸 다 합쳐야 진짜 비용이 보인다.

보안팀이 "누가 어떤 코드를 어떤 모델에 넣었는지 로그가 있느냐"고 물었을 때는 대답을 못 했다. 로컬 추론 서버는 그 로그를 기본으로 만들어주지 않는다. 클라우드 사업자는 감사 로그를 상품으로 파는데 로컬은 그걸 직접 짜야 한다. 자율성을 얻는 대가로 거버넌스를 직접 짓게 된다.

그때 알게 된 건 회사 도입 판단이 한 줄로 안 나온다는 것이었다. 축이 세 개다. 보안과 규제가 하나, 비용 회계가 둘, 직군별 워크플로우가 셋이다. 셋이 만나는 자리에서만 투자 수익이 보이고 그 자리는 회사마다 다르다. 우리 경우는 회계 축에서 먼저 걸렸다.

재밌는 건 클라우드 쪽에도 같은 종류의 종속이 있다는 점이다. 제로 데이터 보존 계약을 맺으면 입력이 학습에 안 쓰이고 일정 기간 뒤 삭제된다. 그런데 그 보장은 사업자 정책에 근거한다. 정책이 바뀌면 보장도 바뀐다. 금융이나 의료, 법무처럼 규제가 센 영역에서 이 구조를 별도 위험으로 검토하라는 요구가 나오는 이유다. 앞에서 본 부채 구조와 형태가 겹친다. 내가 의존하는 조건이 상대의 재무 상태나 정책에 달려 있고, 그 상태가 나빠지면 조건부터 조정된다.

내 노출도를 재는 방법

내가 쓴 방법이 그대로 절차가 된다. 15분이면 자기 숫자가 나온다.

커밋 메시지에 AI 사용 표기 규칙이 있는 레포라면 세는 건 한 줄이다. 자기 커밋만 골라서 월별로 끊어야 한다. 남의 커밋을 섞으면 팀 평균이 나오고 그건 내 노출도가 아니다.

for m in 2026-05 2026-06 2026-07; do
  t=$(git log --author="$(git config user.email)" --since="$m-01" --until="$m-31" --oneline | wc -l)
  a=$(git log --author="$(git config user.email)" --since="$m-01" --until="$m-31" \
        --grep='AI-Use: *yes' -i --oneline | wc -l)
  echo "$m  $a / $t"
done

표기 규칙이 언제 생겼는지 먼저 확인한다. 이걸 안 하면 규칙 도입 시점을 의존도로 착각한다. 내가 그 함정에 빠졌었다.

git log --grep='AI-Use' --reverse --date=short --format='%ad' | head -1

표기 규칙이 없는 레포라면 비율을 셀 수 없으니 다른 걸 센다. 최근 한 달 작업 중에 AI 없이 처음부터 끝까지 혼자 한 게 몇 건인지를 손으로 세보면 대략 나온다. 정확하지 않아도 열 건 중 한 건인지 다섯 건인지는 구분이 된다. 그 구분만으로 충분하다.

비용 쪽은 청구서 대신 세션 로그를 본다. 입력 토큰과 캐시 읽기, 출력 토큰을 따로 집계해야 어디에 의존하는지가 보인다. 총액만 보면 값이 올랐을 때 무엇을 줄여야 하는지 모른다. 캐시 읽기가 대부분을 차지하고 있다면 그 할인 구조가 내 비용의 핵심 전제라는 뜻이고, 그건 가격표에 굵게 적혀 있지 않은 조건이다.

숫자가 나오면 임계값을 하나 정해두는 게 좋다. 나는 이렇게 잡았다. 90%를 넘으면 대안 점검을 분기 일정에 넣고, 70%에서 90% 사이면 이식성만 신경 쓰고, 그 아래면 지금은 안 봐도 된다. 내 숫자가 92%라서 첫 칸에 들어갔고 그래서 로컬 완주를 월 단위로 넣었다.

이 임계값 자체에 근거는 없다. 내가 정한 선이다. 근거 있는 선을 만들려면 단가가 실제로 오르는 사건을 한 번 겪어봐야 하고, 그때는 이미 늦다. 그래서 임의의 선이라도 그어두는 쪽을 택했다. 아무 선도 없으면 92%든 60%든 똑같이 "많이 쓰네" 하고 지나간다. 실제로 내가 넉 달을 그렇게 지나갔다.

그러니까 단가가 올라서 클라우드를 떠나야 하는 상황이 오면, 내가 갈 수 있는 곳은 7배 느린 노트북이거나 시트당 단가가 더 비싼 사내 장비다. 어느 쪽도 지금 당장 옮겨갈 수 있는 데가 아니다. 그게 내 노출도의 실제 크기였다. 커밋 열 건 중 아홉 건이 얹혀 있는 구조에 대안이 없다는 뜻이다.

그래서 지금 해두는 것

경로가 좁다는 걸 알고 나서 바꾼 건 대안을 준비하는 방향이 아니라 의존의 모양이다. 옮겨갈 데가 없으면 옮겨가기 쉬운 상태로 만들어두는 쪽이 남는다.

작업 단위를 작게 쪼개는 습관이 생각보다 큰 방어였다. 60줄을 한 번에 부탁하면 저속 환경에서 4분이 통째로 빈다. 20줄씩 세 번 부탁하면 한 사이클이 1분 안에 끝나서 흐름이 살아난다. 로컬에서 배운 습관인데 클라우드로 돌아와서도 계속 쓰고 있다. 리뷰 품질이 더 좋아졌기 때문이다. 저속 환경에서 살아남는 작업 형태가 대체로 사람이 검증하기 쉬운 형태이기도 했다. 대신 그 60줄을 미리 세 덩어리로 나눠놓는 인지 부담이 붙는다.

모델 이름을 코드와 문서에 박지 않는 것도 그때부터 신경 쓴다. 특정 모델의 버릇에 맞춰 다듬은 지시문은 그 모델이 사라지면 같이 사라진다. 원하는 출력을 조건으로 적어두면 다른 모델에서 다시 맞출 때 출발점이 남는다. 예를 들어 "이 모델은 표를 잘 만드니까 표로 달라"고 적어두는 것과 "행마다 파일 경로와 줄 번호가 있어야 하고 정렬 기준은 심각도"라고 적어두는 것은 이식성이 다르다. 뒤쪽은 모델이 바뀌어도 그대로 쓴다.

내 청구서에서 무엇이 실제 비용인지도 봐둔다. 캐시 재사용에 얼마나 의존하는지, 긴 컨텍스트를 매번 다시 올리는 구간이 어디인지, 어느 작업이 출력 토큰을 많이 쓰는지. 이걸 모르면 값이 올랐을 때 무엇을 줄여야 하는지도 모른다. 나는 세션 로그에서 입력과 캐시 읽기, 출력을 따로 집계해보고 나서야 내 사용 패턴의 모양을 알았다.

한 달에 한 번은 로컬로 작업 하나를 끝까지 끝내보기로 했다. 이게 네 번째다. 벤치마크를 돌리는 게 아니라 실제 작업 하나를 저속 환경에서 완주하는 것이다. 닷새 실험에서 배운 게 있는데, 속도 숫자는 미리 알아도 도움이 안 되고 워크플로우가 어디서 부서지는지는 해봐야 안다는 것이었다. 크롬을 닫아야 한다는 것도, 컨텍스트가 12K를 넘으면 작은 모델로 갈아타야 한다는 것도 표에 없던 정보다.

한 번 해보는 데 반나절쯤 든다. 그 반나절이 보험료라고 보면 비싸지 않다. 값이 오르거나 모델이 사라지는 날에 처음 로컬을 켜보면, 그날 하루가 아니라 그 주가 날아간다. 이미 한 번 해본 상태면 첫날부터 20줄 단위로 쪼개는 습관이 몸에 있다.

넷 다 거품이 터지든 안 터지든 손해가 아닌 것들로 골랐다. 터질지 안 터질지를 내가 맞출 수 있다고 생각하지 않는다. 맞출 수 없는 걸 대비하는 방법은 어느 쪽이 와도 남는 걸 해두는 것뿐이다.

안 하기로 한 것도 적어둔다

대비를 생각하다 보면 과하게 가기 쉬워서, 검토했다가 접은 것도 같이 적어둔다. 접은 이유가 대비의 경계선이다.

로컬로 전면 이주하는 안을 먼저 접었다. 7배 차이를 매일 감당하는 대가가 대비 효과보다 크다. 지금 92%가 얹혀 있는 이유는 게을러서가 아니라 그게 실제로 빠르기 때문이고, 아직 오지 않은 가격 인상 때문에 지금의 속도를 포기하는 건 계산이 안 맞는다. 값이 실제로 오르면 그때 비율이 뒤집히고 그때 옮기면 된다. 그때 옮길 수 있도록 준비만 해두는 것이 앞 섹션의 내용이다.

여러 사업자를 동시에 유지하면서 어댑터로 추상화하는 안도 접었다. 이론상 좋은데 실제로는 추상화 계층이 각 모델의 장점을 다 깎는다. 최소 공통분모만 남기면 어느 쪽에서도 잘 안 되고, 각 모델의 특성을 다 살리려면 분기가 늘어나서 유지 비용이 두 배가 된다. 개인 프로젝트에서 이걸 짜다가 두 번 접었다. 대신 지시문에서 모델 고유 표현을 빼두는 정도로 그쳤다. 옮길 때 다시 맞추는 비용을 아예 지우려 하지 않고 반나절로 줄이는 쪽을 목표로 잡았다.

자체 모델을 파인튜닝해서 종속을 끊는 안은 아예 검토 대상이 아니었다. 사내 GPU 한 대에서 다섯 명이 큐를 만드는 걸 이미 봤다. 학습까지 얹으면 그 장비로 안 되고, 되는 장비를 사는 계산은 앞에서 본 시트당 단가를 더 나쁘게 만든다.

셋을 접고 남은 게 이식성과 습관, 그리고 월 1회 완주였다. 크지 않은데 이게 지금 내가 감당할 수 있는 크기다.

수요가 거품이라는 얘기는 아니다

균형을 하나 적어둔다. 나는 AI 반도체 수요 자체가 거품이라고 보지 않는다. 석 달 연속 92%가 그 증거다. 3년 전에는 없던 사용량이고 투기가 아니라 실제 작업이다. 자동화가 들어간 자리에서 일이 실제로 어떻게 바뀌는지는 볼 때마다 확인된다.

거품이 아니라고 보는 쪽 근거도 약하지 않다. 추론 수요는 학습 수요와 성격이 다르다. 학습은 한 번 크게 쓰고 끝나는 지출인데 추론은 사용자가 늘어나는 만큼 계속 늘어난다. 모델당 추론 단가는 세대가 바뀔 때마다 떨어져왔고, 같은 작업을 더 작은 모델로 처리하는 기술도 계속 나온다. 수요는 늘고 단가는 떨어지는 조합이면 설비 투자는 회수된다. 이 그림이 맞으면 지금 부채는 성장을 앞당겨 산 값이고 문제될 게 없다.

내가 이 반론을 진지하게 받는 이유는 내 사용 패턴이 정확히 그 그림 안에 있기 때문이다. 나는 3월보다 지금 훨씬 많이 쓰고, 같은 작업에 드는 돈은 오히려 줄었다. 내 청구서가 그 낙관을 지지한다.

다만 그 그림이 맞아도 내 노출도는 그대로다. 회수가 되는 경로에서도 사업자는 단가 구조를 조정하고 구형 모델을 정리한다. 오히려 잘 돌아갈 때 더 자주 한다. 새 모델을 자주 내려면 구형을 자주 접어야 하니까. 거품이 안 터져도 지원 종료는 오고, 터지면 거기에 단가 인상이 얹힌다. 내가 준비하는 건 어느 쪽이든 오는 그 부분이다.

위험한 건 수요 자체가 아니라 그 수요를 조달한 방식이다. 자산 수명보다 긴 만기, 장부 밖으로 옮긴 위치, 자기 고객의 신용을 자기가 보증하는 구조. 이 셋은 수요가 계속 늘어도 문제를 만들 수 있다. 수요가 늘어나는 속도가 조달 비용을 못 따라가면 그때 조정이 온다. 반도체 수요가 진짜라는 것과 그 수요를 뒷받침하는 재무 구조가 튼튼하다는 것은 다른 얘기다.

그리고 그 조정이 오면 나한테는 주가로 오지 않는다. 청구서와 지원 종료 공지로 온다. 반년째 이 뉴스를 주식 얘기로 읽고 넘겼던 게 그래서 실수였다. 어제 종이에 그려보고 커밋을 세보고 나서야 이게 내 도구 얘기였다는 걸 알았다.

지금 당장 뭘 갈아치울 계획은 없다. 다만 내 의존도가 92%이고 탈출 경로가 7배 느리며 사내 대안이 더 비싸다는 숫자는 알고 있는 게 낫다. 값이 오르는 날에 그 숫자를 처음 재기 시작하면 늦다.