오픈 모델 vs 클로즈드 모델: 실제 프로젝트를 위한 선택법

"오픈이냐 클로즈드냐" 논쟁은 보통 가치관의 문제인 것처럼 다뤄집니다. 그러나 실제 프로젝트에서는 트레이드오프의 문제입니다. 누가 모델을 통제하는가, 어디서 돌아가는가, 당신의 사용량에서 비용이 얼마인가, 그리고 새벽 2시에 무언가가 고장 났을 때 어떻게 되는가입니다. 그렇게 다루면 결정은 다룰 수 있는 문제가 됩니다. 이 가이드는 어느 진영에도 가담하지 않고 그 결정을 내리는 방법을 제시합니다.

먼저 대부분의 혼란을 막아주는 한 가지를 분명히 해두겠습니다. "오픈"은 거의 언제나 **오픈 가중치(open-weights)**를 뜻합니다. 모델의 파라미터를 내려받아 직접 돌릴 수 있다는 의미입니다. Open Source Initiative가 정의하는 엄밀한 의미의 오픈소스를 뜻하는 경우는 드뭅니다. 훈련 데이터와 전체 훈련 코드는 대개 공개되지 않기 때문입니다. "클로즈드"는 가중치가 제공자에게 남아 있고, 당신은 호스팅 API를 통해 모델에 접근한다는 뜻입니다. 둘 다 훌륭할 수 있습니다. 어느 쪽도 자동으로 더 안전하거나, 저렴하거나, 유능하지는 않습니다.

당신이 실제로 선택하는 것

오픈 가중치 모델을 고를 때, 당신은 모델과 그것을 운영하는 책임을 함께 떠안습니다. 파라미터를 얻고, 하드웨어를 선택하며, 가동 시간과 확장, 보안 패치, 업그레이드 경로를 직접 책임집니다. 클로즈드 API를 고를 때는, 성능을 빌리고 운영 부담을 제공자에게 넘깁니다. 통제권을 편의성과 맞바꾸는 것입니다.

이 단 하나의 거래 — 통제권 대 편의성 — 가 거의 모든 다른 고려사항의 밑바탕에 깔려 있습니다. 나머지를 읽는 동안 이를 염두에 두십시오. "오픈이 더 낫다"거나 "클로즈드가 더 낫다"는 대부분의 주장은, 실은 누군가가 당신의 프로젝트에 마땅한 것과 다르게 통제권과 편의성에 가중치를 두고 있는 것에 불과하기 때문입니다.

통제권과 데이터 거주성

오픈 가중치를 직접 운영하는 가장 강력한 이유는 데이터가 어디로 가는지, 그리고 시스템이 시간이 지나며 어떻게 동작하는지에 대한 통제권입니다.

• 데이터 거주성(Data residency). 입력이 법적으로나 계약상 당신의 인프라를 벗어날 수 없다면, 직접 호스팅하는 모델은 이 문제 자체를 없애줍니다. 어떤 것도 제3자에게 전송되지 않습니다. 규제 분야에서는 이것이 때때로 결정의 전부입니다.
• 버전 안정성. 직접 호스팅하는 모델은 당신 모르게 바뀌지 않습니다. 호스팅 모델은 제공자의 일정에 따라 업데이트되거나, 지원이 중단되거나, 폐기될 수 있으며, 동작의 조용한 변화가 정교하게 튜닝한 프롬프트를 망가뜨릴 수 있습니다. 셀프 호스팅은 당신이 옮기기로 선택할 때까지 동작을 고정합니다.
• 오프라인 및 망분리 환경. 시스템이 인터넷 접속 없이 돌아가야 한다면, 오픈 가중치가 사실상 유일한 선택지입니다.

이 통제권의 비용은, 제공자가 하던 모든 일 — 확장, 패치, 모니터링 — 이 이제 당신 팀의 일이 된다는 것입니다.

편의성, 성능, 그리고 출시 속도

클로즈드 API를 선택하는 가장 강력한 이유들은 정반대의 거울상입니다.

• 더 빨리 출시합니다. 호스팅된 엔드포인트는 키만 있으면 그 순간 바로 쓸 수 있습니다. 조달할 GPU도, 튜닝할 추론 서버도, 설계할 오토스케일링도 없습니다. 프로토타입이나 초기 제품에서는 이것만으로도 선택이 정당화될 수 있습니다.
• 프런티어는 대개 그곳에 먼저 등장합니다. 가장 크고 유능한 범용 모델은 오픈 가중치로 공개되기 전에 — 혹은 공개되는 대신 — 호스팅 서비스로 먼저 제공되는 경우가 많습니다. 당신의 과제가 정말로 성능 범위의 최상단을 필요로 한다면, 클로즈드 옵션만이 그 기준을 넘는 유일한 선택일 수 있습니다.
• 운영 성숙도가 기본으로 포함됩니다. 속도 제한, 모니터링, 안전 필터링, 인프라 확장이 알아서 처리됩니다. 토큰당 가격 안에 그 비용을 지불하지만, 직접 만들 필요는 없습니다.

그 비용은 의존입니다. 제공자의 가격, 가용성, 로드맵에 대한 의존이며, 당신이 통제하지 못하는 네트워크 왕복에 대한 의존입니다.

비용 문제, 정직하게

비용 비교는 대부분의 팀이 양방향으로 스스로를 속이는 지점입니다.

호스팅 API는 고정 비용이 거의 0에 가깝고, 사용 단위당 변동 비용이 명확합니다. 이것은 낮고 들쭉날쭉한 사용량에서는 훌륭하지만, 꾸준히 높은 사용량에서는 고통스러워질 수 있습니다. 모든 호출에 대해 영원히 정가를 지불하기 때문입니다.

셀프 호스팅은 이 곡선을 뒤집습니다. 크고 대체로 고정된 비용 — 하드웨어 또는 예약 용량, 그리고 그것을 운영하는 엔지니어링 시간 — 을 지불하는데, 트래픽이 낮을 때는 낭비되지만 트래픽이 높고 예측 가능할 때는 아름답게 분산 상각됩니다. 손익분기점은 실재하지만 프로젝트마다 다릅니다.

수치와 무관하게 성립하는 몇 가지 원칙이 있습니다.

• 유휴 용량은 셀프 호스팅의 숨은 세금입니다. 시간당 빌린 GPU는 천 건의 요청을 처리하든 한 건도 처리하지 않든 같은 비용이 듭니다. 트래픽이 들쭉날쭉하다면, 대표 호출 단가가 더 높더라도 호스팅 가격이 이기는 경우가 많습니다.
• 엔지니어링 시간은 추론 비용의 일부입니다. 추론 스택을 건강하게 유지하는 사람들의 급여는 실재하는 비용 항목입니다. 팀들은 흔히 이를 잊고는, 왜 "무료" 가중치가 비싸게 느껴지는지 의아해합니다.
• 총비용은 정가가 아니라 활용률에 달려 있습니다. 토큰당 API 가격을 시간당 GPU 가격과 직접 비교하지 마십시오. 당신의 예상 부하에서 유효 요청당 비용으로 둘 다 환산하십시오.

라이선스는 각주가 아니다

오픈 가중치 모델의 경우, 만들기 전에 라이선스를 읽으십시오. 나중이 아닙니다. "오픈"이라는 단어는 광범위한 조건을 아우르며, 그중 일부는 상업적으로 중요한 의무를 수반합니다.

일부 오픈 가중치 공개는 MIT나 Apache에 가까운 정신의 관대한 라이선스를 사용해 폭넓은 상업적 이용을 허용합니다. 다른 것들은 일정 규모 이상의 사용을 제한하거나, 특정 응용을 금지하거나, 파생 모델에 조건을 붙이는 맞춤형 또는 커뮤니티 라이선스를 사용합니다. 라이선스를 견줄 잣대가 필요하다면 Open Source Initiative가 오픈소스의 표준 정의를 관리하고 있으며, Hugging Face 같은 모델 허브는 각 모델 옆에 라이선스를 노출해 일찍 확인할 수 있게 해줍니다.

지속되는 규칙은 이렇습니다. 내려받을 수 있는 모델이라고 해서, 당신이 의도한 방식대로 사용할 라이선스가 자동으로 주어진 모델은 아닙니다. 라이선스를 성능이나 비용과 동등한 관문 요건으로 다루십시오.

의사결정 프레임워크

다음 질문들을 순서대로 짚어보십시오. 확실한 답을 주는 첫 번째 질문이 종종 문제를 결정합니다.

1. 엄격한 데이터 거주성 또는 오프라인 요건이 있는가? 입력이 당신의 인프라를 벗어날 수 없다면, 오픈 가중치와 셀프 호스팅 쪽으로 강하게 기울이십시오.
2. 과제가 성능 범위의 최상단을 필요로 하는가? 그렇다면 오픈 가중치 모델이 실제로 그 기준을 넘는지 확인하십시오. 프런티어 호스팅 모델만이 넘는다면, 선택은 빠르게 좁혀집니다.
3. 사용량 프로필은 어떤가? 낮거나 들쭉날쭉하면 호스팅에 유리합니다. 높고 꾸준하며 예측 가능하면 — 운영할 팀이 있다면 — 셀프 호스팅에 유리합니다.
4. 운영 역량이 있는가? 추론을 신뢰성 있게 운영하는 것은 진짜 엔지니어링입니다. 그 역량이 없거나 원하지 않는다면, 호스팅 API는 타협이 아니라 올바른 선택입니다.
5. 라이선스가 당신이 의도한 규모에서 의도한 사용을 허용하는가? 여기서의 "아니오"는 다른 모든 선호를 무효화합니다.

성능은 다섯 관문 중 하나일 뿐이며, 좀처럼 결정적인 요소가 아니라는 점에 주목하십시오. 대부분의 실제 프로젝트는 원시 모델 품질이 끼어들기 한참 전에, 데이터 규칙·사용량·팀 역량으로 결정됩니다.

하나만 골라야 하는 것은 아니다

단 하나의 이분법적 선택이라는 틀 자체가 함정입니다. 성숙한 시스템은 둘을 자주 섞습니다. 흔하고 합리적인 패턴은, 쉽고 사용량 많은 요청의 대부분을 더 저렴한 셀프 호스팅 오픈 모델로 보내고, 정말로 어려운 경우에만 더 유능한 호스팅 API로 에스컬레이션하는 것입니다. 또 다른 방법은, 호스팅 API에서 프로토타입을 만들어 제품을 검증한 뒤, 사용량과 요구사항이 분명해지면 정상 상태의 워크로드를 셀프 호스팅 가중치로 이전하는 것입니다. 두 옵션은 진영이 아니라 도구입니다. 워크로드의 각 부분에 맞는 것을 쓰십시오.

정리

오픈이냐 클로즈드냐는 미덕의 경쟁이 아니라 통제권과 편의성 사이의 거래입니다. 오픈 가중치는 운영과 라이선스 검토를 직접 떠안는 대가로 데이터 거주성, 버전 안정성, 오프라인 운영을 줍니다. 클로즈드 API는 의존과 호출당 비용을 대가로 속도, 프런티어 성능, 관리형 인프라를 줍니다. 다섯 관문 프레임워크 — 거주성, 성능 기준, 사용량 프로필, 운영 역량, 라이선스 — 로 결정하고, 엄격한 요건이 먼저 말하게 하십시오. 그리고 둘을 섞을 수 있다는 점을 기억하십시오. 최고의 아키텍처는 종종 저렴한 작업은 한쪽으로, 어려운 작업은 다른 쪽으로 라우팅합니다.

출처 참고: 라이선스 조건과 특정 오픈 가중치 공개의 가용성은 자주 바뀌므로, 이 가이드는 현재의 모델을 거명하기보다 지속되는 원칙을 설명합니다. 만들기 전에 항상 모델 페이지의 실제 라이선스를 읽으십시오.