오픈 웨이트 모델을 직접 돌릴 수 있게 되면서 개발자와 팀 사이에서 반복되는 질문이 하나 있다. "GPU와 메모리를 갖춘 장비를 사서 로컬로 추론을 돌리는 게, 상용 API를 쓰는 것보다 결국 이득일까?" Show HN에 올라온 'Sunk Cost'(sunkcost.ai)는 바로 이 질문을 정면으로 다루는 계산기다. 어떤 오픈 모델이 내 장비에 들어가는지, 얼마나 빠르게 돌아가는지, 그리고 API 대비 하드웨어 값을 회수하려면 몇 개의 토큰을 처리해야 하는지를 추정해 보여준다. 이 도구의 성격을 가장 잘 드러내는 표현은 스스로 붙인 설명 문구다. "필요하면 '영원히 회수 못 한다'고 말할 만큼 정직하다."
왜 지금 이런 계산기가 필요한가
로컬 추론에 대한 관심은 프라이버시, 오프라인 동작, 데이터 통제 같은 이유로 꾸준히 커졌다. 여기에 성능이 쓸 만한 오픈 웨이트 모델이 계속 공개되면서, 이제는 '가능한가'보다 '경제적인가'가 실질적인 판단 기준이 됐다. 문제는 이 경제성 계산이 생각보다 간단하지 않다는 점이다. 장비 구매는 한 번에 나가는 고정비용이지만, API는 토큰당 과금되는 변동비용이다. 두 비용 구조가 어디서 교차하는지는 사용량, 모델 크기, 하드웨어 사양에 따라 크게 달라진다. Sunk Cost는 이 교차점을 눈에 보이게 만들어, 감으로 내리던 결정을 숫자 위에 올려놓으려 한다.
핵심 아이디어는 '손익분기 토큰 수'다. 하드웨어에 들인 돈을, 같은 양의 작업을 API로 처리했을 때 들었을 비용으로 나누면, 몇 개의 토큰을 로컬에서 돌려야 본전에 도달하는지가 나온다. 사용량이 많을수록 이 지점에 빨리 닿고, 사용량이 적으면 장비값을 회수하기 전에 모델이 구형이 되어버릴 수도 있다. 이 도구가 '영원히 회수 못 함'이라는 결론을 숨기지 않겠다고 강조하는 이유가 여기에 있다. 많은 개인 사용자에게 로컬 장비는 경제적 선택이라기보다 취미나 통제권에 대한 지출에 가깝다는 현실을, 계산기가 대신 확인해 주는 셈이다.
속도는 어떻게 추정하나
주목할 부분은 속도 산출 방식이다. Sunk Cost는 실제로 측정된 값이 있으면 그것을 쓰고, 측정치가 없는 조합에 대해서는 로컬 추론 속도를 '메모리 대역폭 ÷ 토큰당 읽는 바이트 수' 형태로 추정한다고 밝힌다. 그리고 이렇게 추정된 값에는 추정임을 명시하는 라벨을 붙인다. 이는 대규모 언어 모델의 추론, 특히 토큰을 하나씩 생성하는 디코딩 단계가 연산량보다 메모리 대역폭에 의해 병목이 걸리는 특성을 반영한 접근이다. 모델 가중치를 매 토큰마다 메모리에서 읽어와야 하므로, 대역폭을 읽어야 할 데이터 양으로 나누면 초당 토큰 수의 상한을 가늠할 수 있다.
이 방식은 실무자에게 두 가지 의미가 있다. 첫째, 아직 벤치마크가 없는 장비·모델 조합에 대해서도 대략의 성능 감을 얻을 수 있다. 둘째, 그 값이 어디까지나 이론적 상한에 가까운 추정이라는 점을 도구 스스로 인정한다는 것이다. 실제 처리량은 배치 구성, 양자화 방식, KV 캐시 크기, 소프트웨어 스택의 최적화 수준에 따라 이론값 아래로 떨어지는 경우가 흔하다. 따라서 추정 속도는 순위와 규모감을 잡는 참고치로 받아들이는 편이 안전하다.
계산 결과를 읽을 때 유의할 점
또 하나 짚어둘 설계상의 선택은, API 속도가 회수 여부 자체가 아니라 '시간 비교'에만 영향을 준다는 점이다. 즉 손익분기에 필요한 토큰 수는 비용 구조로 결정되고, API가 얼마나 빠른지는 그 토큰을 처리하는 데 걸리는 시간을 비교할 때만 반영된다. 비용과 시간을 분리해 다룬 것으로, 두 축을 뒤섞어 잘못 결론 내리는 것을 막으려는 의도로 읽힌다.
다만 이런 계산기는 본질적으로 몇 가지 요소를 단순화할 수밖에 없다. 전기요금, 냉각과 소음, 장비의 감가상각과 재판매 가치, 유지보수에 드는 사람의 시간, 그리고 모델이 빠르게 세대교체되며 하드웨어의 효용이 줄어드는 속도까지 온전히 담기는 어렵다. API 쪽도 마찬가지로 가격은 수시로 조정되고, 오픈 모델과 상용 모델의 품질 차이는 토큰 단가만으로 환산되지 않는다. 결국 Sunk Cost가 내놓는 숫자는 정답표가 아니라, 논의의 출발점을 잡아주는 기준선에 가깝다.
그럼에도 이 도구의 가치는 분명하다. 로컬 장비 구매를 정당화하고 싶은 심리적 편향—이미 관심을 쏟은 대상에 더 많은 자원을 붓게 되는, 이름 그대로의 '매몰비용' 함정—을 숫자로 견제한다는 점이다. 장비를 지르기 전에 자신의 실제 사용량을 대입해 보고, '이 정도 쓰면 몇 년이 걸리는지' 혹은 '아예 회수가 안 되는지'를 확인하는 것만으로도 판단의 질은 올라간다. 로컬이냐 API냐를 두고 고민하는 한국의 개발팀이라면, 결론을 미리 정해두지 말고 자신의 워크로드 숫자를 먼저 넣어보길 권한다.