오픈 모델과 클로즈드 모델

docs.scrimba.com

내부적으로 보면 모델은 학습된 가중치(훈련 중에 학습한 숫자들)를 잔뜩 쌓아 놓고 다음 토큰을 예측하는 존재입니다. 이 장에서는 그 가중치가 여러분에게 도달하는 두 가지 방식, 즉 API로 빌려 쓰는 클로즈드(closed) 모델과 직접 실행할 수 있는 오픈 웨이트(open-weight) 모델을 다루고, 각각이 실제로 어디에서 동작하는지도 함께 살펴봅니다. 다들 기본값으로 안내받는 것은 호스팅된 클로즈드 모델이고, 제공업체 입장에서는 다른 대안을 굳이 알릴 이유가 없습니다. 그래서 전체 선택지를 알아 두고, 각각이 언제 중요해지는지 파악해 둘 필요가 있습니다.

오픈 웨이트, 클로즈드 웨이트

AI 모델을 손에 넣는 방법은 두 가지가 있고, 그 차이는 결국 모델이 실제로 어디에 존재하느냐로 갈립니다.

첫 번째 방법은 클로즈드(closed) 모델로, 프로프라이어터리(proprietary) 모델이라고도 부릅니다. 이 모델은 오직 회사가 제공하는 API, 즉 일종의 온라인 출입문을 통해서만 접근할 수 있습니다. 텍스트를 보내면 텍스트를 돌려받는 것, 그게 전부입니다. 모델을 돌리는 방대한 학습된 숫자 더미인 가중치는 회사의 서버에 잠긴 채로 남아 있습니다. 여러분은 무언가를 소유하는 것이 아니라 접근 권한을 빌리는 것입니다.

두 번째 방법은 오픈 웨이트(open-weight) 모델입니다. 이 경우 회사가 가중치를 공개하기 때문에, 여러분이 직접 사본을 내려받아 원하는 하드웨어에서 실행할 수 있습니다. 배선을 절대 볼 수 없는 아파트를 빌리는 것과, 건물 설계도 자체를 소유하는 것의 차이라고 생각하면 됩니다.

대부분의 사람들은 클로즈드 API로 시작합니다. 가장 손쉽게 들어갈 수 있는 문이기 때문이고, 그렇게 시작하는 것도 충분히 좋은 선택입니다. 오픈 옵션도 실제로 존재하고 알아 둘 가치가 있으니, 셀프 호스팅을 빌리는 것이 유일한 길이 아니라 하나의 선택이라는 점만 기억해 두면 됩니다.

Juno오픈 웨이트와 클로즈드 웨이트 클로즈드 모델은 회사의 서버에 존재하고 API로만 접근할 수 있어서 접근 권한을 빌리는 셈입니다. 오픈 웨이트 모델은 숫자들이 공개되어 있어서 사본을 내려받아 직접 실행할 수 있습니다. 클로즈드 API로 시작하는 것도 전혀 문제없지만, 다른 문이 존재한다는 것을 알아 두면 도움이 됩니다.

전체 구분은 결국 한 가지 질문으로 귀결됩니다. 가중치를 누가 쥐고 있는가? 클로즈드(또는 프로프라이어터리) 모델은 가중치가 제공업체 밖으로 나가지 않고, 여러분은 오직 API를 통해서만 모델과 대화합니다. 오픈 웨이트 모델은 가중치가 특정 라이선스 하에 공개되어 있어서, 다운로드해서 원하는 곳에서 실행할 수 있습니다.

여기서 주의할 점이 있습니다. "오픈 웨이트"는 "오픈 소스"와 같은 말이 아닙니다. "오픈"이라고 불리는 LLM 중 대부분은 학습된 가중치만 공개하고 학습 데이터와 학습 코드는 공개하지 않기 때문에, 모델을 처음부터 완전히 재현할 수는 없습니다. 일부 라이선스는 사용 제한도 걸어 두는데, 예를 들어 상업적으로 사용할 수 있는 회사 규모에 상한을 두거나 허용되는 용도를 제한하는 식입니다. 덤벼들기 전에 라이선스를 꼭 읽어 보세요. "오픈"은 이분법이 아니라 정도의 문제입니다.

성능 면에서는 프런티어 클로즈드 모델(그 시점에서 가장 뛰어난 모델들)이 공개 벤치마크를 주도하는 경우가 많습니다. 하지만 강력한 오픈 웨이트 모델들도 실제 작업의 상당 부분에서는 그 차이가 충분히 좁혀져 있고, 그 격차는 시간이 지날수록 계속 줄어들고 있습니다. 실용적인 접근은 무조건 최고의 모델이 필요하다고 가정하지 않는 것입니다. 많은 작업은 오픈 모델로도 충분히 처리되며, 이는 리더보드가 아니라 여러분 자신의 작업으로 직접 테스트해 봐야 알 수 있습니다.

Juno오픈 웨이트와 클로즈드 웨이트 클로즈드는 API로만 접근할 수 있고 가중치는 제공업체에 남아 있다는 뜻이며, 오픈 웨이트는 공개된 가중치를 다운로드해서 실행할 수 있다는 뜻입니다. 오픈 웨이트가 오픈 소스는 아닙니다. 학습 데이터와 코드는 대개 비공개로 남고 라이선스가 사용을 제한할 수도 있으니 꼭 읽어 보세요. 프런티어 클로즈드 모델이 벤치마크를 주도하지만, 강력한 오픈 웨이트 모델도 실제 작업 대부분을 충분히 처리하니 작업에 맞춰 선택하세요.

"오픈"이 실제로 주는 것은 통제권과 벤더 종속에서의 자유입니다. 정확한 가중치 버전을 고정해서 모델이 여러분 모르게 조용히 바뀌는 일이 없도록 할 수 있고, 동작을 들여다볼 수 있고, 하드웨어가 있는 곳이면 어디서든 실행할 수 있습니다. 재현성이나 데이터 거주지(data residency)가 중요한 상황에서는 이것이 실질적인 이점입니다.

다만 이것이 공짜로 주어지지는 않습니다. **오픈 웨이트**는 거의 항상 오픈 소스가 아니라 "가중치 + 라이선스"를 의미합니다. 학습 데이터는 없고, 라이선스 조항도 만만치 않은 경우가 많습니다. 그래서 컴플라이언스와 라이선스 검토가 여러분이 실제로 해야 할 업무가 되고, 관대해 보이는 모델이라도 상업적 사용이나 재배포를 제한할 수 있어서 읽지 않고 넘기면 나중에 뒤통수를 맞을 수 있습니다.

가장 어려운 작업에서는 프런티어 성능 격차도 여전히 실재합니다, 물론 그 격차는 줄어들고 있지만요. 그러니 라벨이 아니라 눈앞의 작업을 기준으로 선택하세요. 대부분의 일상적인 작업에는 오픈 웨이트 모델로 충분하고, 난이도의 최전선에서는 클로즈드 프런티어 모델이 여전히 앞설 수 있습니다.

제가 계속 스스로에게 되새기는 것은, "오픈"을 가중치와 라이선스가 함께 이루는 하나의 속성으로 취급하고 둘 다 읽어야 한다는 점입니다. "다운로드할 수 있다"는 문장과 "무엇이든 할 수 있다"는 문장은 같은 말이 아니고, 저는 그 간극에 물린 적이 있습니다.

Juno오픈 웨이트와 클로즈드 웨이트 오픈 웨이트는 통제권과 벤더 종속으로부터의 탈출을 줍니다. 버전 고정, 동작 검증 가능성, 어디서든 실행 가능성이 그것입니다. 오픈 소스를 주는 것은 아니니 라이선스와 컴플라이언스 검토 비용을 예산에 넣어야 합니다. 친근해 보이는 라이선스도 상업적 사용을 막을 수 있습니다. 라벨이 아니라 작업을 기준으로 선택하고, "다운로드할 수 있다"를 절대 "무엇이든 할 수 있다"로 읽지 마세요.

모델이 실행되는 위치

오픈 모델을 선택하면 직접 서버를 구축해서 실행해야 한다는 믈음이 떠돌아다닙니다. 이는 사실이 아니고, 초반에 확실히 짚어 둘 필요가 있습니다.

모델은 두 곳 중 한 곳에서 실행될 수 있습니다. 호스팅된(hosted) 모델의 경우, 어떤 회사가 자신들의 컴퓨터에서 모델을 돌리고 여러분은 API 호출, 즉 코드가 보내고 응답을 돌려받는 작은 요청을 통해 웹 너머로 접근합니다. 여러분은 그 모델이 돌아가는 컴퓨터를 직접 만질 일이 없습니다. 셀프 호스팅의 경우, 여러분이 직접 자신의 컴퓨터나 서버에서 모델을 실행합니다.

사람들이 자주 놓치는 부분이 여기 있습니다. 오픈 모델이라고 해서 반드시 셀프 호스팅을 해야 하는 것은 아닙니다. 클로즈드 모델을 쓸 때처럼 편하게, 호스팅 회사를 통해 오픈 모델을 쓸 수도 있습니다. 요청을 보내면 응답을 받고, 컴퓨터를 계속 돌리는 일은 다른 누군가가 맡습니다. 셀프 호스팅은 여러분이 선택할 수 있는 옵션이지, 반드시 따라야 하는 규칙이 아닙니다.

Juno모델이 실행되는 위치 모델은 여러분이 웹을 통해 접근하는 다른 누군가의 컴퓨터에서 돌아가거나, 여러분이 직접 운영하는 컴퓨터에서 돌아갑니다. 오픈 모델은 두 방식 모두 가능하므로, 오픈 모델을 고른다고 해서 갑자기 서버를 관리해야 하는 건 아닙니다. 클로즈드 모델을 쓰듯이 호스팅 회사가 오픈 모델을 대신 돌리게 할 수 있습니다.

두 가지로 딱 나누는 사고방식은 버리는 것이 좋습니다. 모델이 어디서 실행되는지는 사실 하나의 스펙트럼에 가깝기 때문입니다. 한쪽 끝에는 제공업체의 API를 통해 호출하는 클로즈드 모델이 있습니다. 중간에는 제3자 호스트가 대신 실행해 주는 오픈 웨이트 모델이 있습니다. 다른 쪽 끝에는 여러분이 직접 실행하는 오픈 웨이트 모델이 있는데, 이것이 바로 **셀프 호스팅**입니다. 여러분이 기계를 마련하고 모델을 서빙하는 프로그램을 직접 돌리는 방식입니다.

이 스펙트럼을 따라 이동하는 비용이 적은 이유는, 널리 쓰이는 채팅 메시지 API 형식이 사실상 표준으로 자리 잡았기 때문입니다. 많은 오픈 모델 호스트와 셀프 호스팅 서버들이 바로 그 형식을 그대로 노출합니다. 그래서 제공업체를 바꾸는 일은 대부분 코드를 다시 쓰는 것이 아니라 베이스 URL과 모델 이름만 바꾸는 정도로 끝납니다(코드에서 모델 호출하기 참고). 모델을 호출하는 법에 대해 배운 내용은 어느 한 벤더에 묶여 있지 않습니다.

간단히 말해, 셀프 호스팅은 여러분이 하드웨어(성능 좋은 GPU, 또는 대여한 GPU 서버)를 마련하고 모델 앞에 서빙 프로그램을 돌려야 한다는 뜻입니다. 이것을 여러분이 짊어져야 할 실질적인 업무로 받아들이세요. 여기서는 결정 수준에 머물고 설정 방법까지 더 깊이 들어가지는 않겠습니다.

Juno모델이 실행되는 위치 스펙트럼을 떠올려 보세요. 제공업체를 통한 클로즈드, 제3자 호스트를 통한 오픈, 그리고 셀프 호스팅한 오픈이 있습니다. 수많은 엔드포인트가 하나의 채팅 메시지 API 형식을 공유하기 때문에, 이들 사이를 옮겨 다니는 것은 보통 다시 쓰는 게 아니라 base_url과 모델 이름을 바꾸는 정도입니다. 셀프 호스팅은 하드웨어와 서빙을 직접 소유하는 맨 끝쪽 선택지이니, 기본값이 아니라 의도를 가지고 선택하세요.

셀프 호스팅은 부수적인 일이 아니라 인프라 그 자체입니다. 직접 모델을 실행하는 순간부터 용량 계획, 부하에 따른 스케일링, 가동 시간, 보안 패치, 모델 업데이트까지 모두 여러분의 책임이 됩니다. "제 노트북에서는 돌아가요"는 데모일 뿐이고, 프로덕션은 전혀 다른 청구서입니다.

대부분의 팀이 지나쳐 버리는 중간 경로는 관리형 오픈 모델 호스트입니다. GPU를 직접 세팅하지 않고도 오픈 모델의 장점, 즉 프런티어 클로즈드 모델보다 낮은 비용, 특정 모델 버전 고정, 데이터가 위치할 곳에 대한 선택권, 특정 벤더에 종속되지 않는 자유를 얻을 수 있습니다. 사실상 표준이 된 채팅 API 형식이 여러분의 보험입니다. 코드를 이 인터페이스에만 맞춰 두면, 호스트를 바꾸거나 나중에 모델을 내부로 들여오는 일이 마이그레이션이 아니라 설정 변경 수준으로 남습니다.

저는 "간단히 셀프 호스팅해 보자"는 시도가 한 분기를 통째로 잡아먹는 걸 본 적이 있습니다. 그래서 진짜 셀프 호스팅은 구체적인 압박이 실제로 있을 때만 아껴서 쓰려고 합니다. 데이터 거주지 규정, 유리하게 뒤바뀌는 규모의 경제, 또는 처음부터 끝까지 직접 통제해야만 하는 모델이 그런 경우입니다. 이런 이유가 없다면 관리형 오픈이나 호스팅된 클로즈드가 정답입니다.

Juno모델이 실행되는 위치 직접 모델을 운영한다는 것은 용량, 가동 시간, 패치, 업데이트를 모두 소유한다는 뜻이니 함부로 뛰어들지 마세요. 팀들이 자주 놓치는 경로는 관리형 오픈 모델 호스트입니다. GPU를 돌보지 않으면서도 오픈 모델의 경제성과 통제권을 얻을 수 있습니다. 표준 채팅 API에 맞춰 코드를 작성하면 제공업체 변경도 마이그레이션이 아니라 설정 변경으로 남습니다. 진짜 셀프 호스팅은 데이터 거주지, 규모의 경제, 확실한 모델 통제처럼 구체적인 이유가 있을 때만 쓰세요.

각각이 적합한 상황

전체 선택을 이렇게 단순하게 정리할 수 있습니다. 클로즈드 호스팅 모델은 빌리는 것입니다. 따로 준비할 것이 없고, 최고의 품질을 얻을 수 있으며, 쓸 때마다 조금씩 비용을 냅니다. 직접 실행하는 오픈 모델은 소유에 가깝습니다. 더 많은 통제권과 프라이버시를 얻고 제공업체에 내는 사용료도 없지만, 계속 돌아가게 유지하는 일을 여러분이 떠맡아야 합니다.

대부분의 사람들은 API로 빌려서 시작하는 것이 맞는 선택이고, 대부분은 그 이상을 필요로 하지 않습니다. 먼저 빌리는 것이 자연스럽고 합리적인 길입니다.

이 장의 목적은 여러분이 직접 실행하는 쪽으로 바꿔야 한다는 것이 아니었습니다. 그저 이 선택이 여러분의 몫이라는 것을 알아 두고, 언젠가 필요가 바뀌었을 때 그 선택지를 알아볼 수 있게 하려는 것이었습니다.

모델을 정했다면, 다음 질문은 그 모델과 어떻게 대화할 것인가입니다. 다음 장인 프롬프팅에서는 여러분이 선택한 모델이 실제로 원하는 결과를 내놓도록 이끄는 방법을 다룹니다.

Juno각각이 적합한 상황 빌리는 것과 소유하는 것으로 생각해 보세요. 호스팅된 클로즈드 모델은 빌리는 것이고, 직접 실행하는 오픈 모델은 소유에 가깝습니다. API로 빌리는 것이 시작하기 좋은 지점이고, 대부분은 거기서 만족스럽게 머뭅니다. 이제 다른 문이 존재한다는 것을 알게 되었고, 그게 이 장의 핵심입니다. 다음은 프롬프팅입니다. 여기서 여러분이 고른 모델을 이끄는 법을 배웁니다.

실제로 선택해야 할 때는 대략 이런 순서로 요소들을 따져 보세요. 첫째, 성능입니다. 호스팅된 프런티어 모델이 이 작업에서 그만한 값어치를 하는가, 아니면 강력한 오픈 웨이트 모델로도 이미 충분한가? 둘째, 데이터 민감도입니다. 이 데이터가 제공업체의 약관 아래에서 경계를 벗어나도 되는가, 아니면 데이터 거주지(data residency)(데이터가 물리적으로 존재하고 처리될 수 있는 위치에 관한 규정)가 그것을 막는가?

셋째, 비용 곡선입니다. 토큰당 과금되는 API는 처음 시작할 때는 저렴하고 낮은 사용량에서는 계속 저렴하지만, 지속적으로 많은 양을 쓸 때는 비싸질 수 있습니다. 바로 이 지점에서 고정비용 방식의 셀프 호스팅이 유리해질 수 있습니다. 넷째, 통제권입니다. 여러 버전에 걸쳐 정확한 동작을 고정해 둘 필요가 있는가, 아니면 특정 벤더에 묶이는 것을 피해야 하는가?

대체로 접근 방식은 같습니다. 호스팅된 API로 시작하세요. 무언가를 가장 빠르게 작동시키는 길이기 때문입니다. 그리고 규모에 따른 비용, 프라이버시나 컴플라이언스 요구사항, 또는 실질적인 성능이나 통제권 필요성처럼 구체적인 압박이 실제로 나타났을 때만 다시 검토하세요.

기본값이나 이념이 아니라 근거에 따라 결정하세요. 모델이 정해졌다면, 프롬프팅에서는 그 모델로부터 안정적인 결과를 얻는 방법을 다룹니다.

Juno각각이 적합한 상황 네 가지를 순서대로 따져 보세요: 필요한 성능, 데이터 민감도, 비용 곡선, 통제권입니다. 호스팅된 API로 시작하세요. 가장 빠르게 작동시킬 수 있으니까요. 그리고 대량 사용 시 비용이나 데이터 거주지 규정처럼 구체적인 압박이 나타났을 때만 다시 검토하세요. 직감이 아니라 근거로 전환하세요. 그다음 프롬프팅으로 넘어가서 여러분이 고른 모델을 원하는 대로 다루는 법을 배우세요.

단순하게 정리하면 이렇습니다. 대부분의 팀에게는 호스팅된 클로즈드 API가 올바른 기본값이고, 오픈 웨이트 모델을 셀프 호스팅하는 것은 진지함을 보여주는 배지가 아니라 비용과 통제권을 따진 결정입니다. 이는 특정 규모를 넘어서거나 컴플라이언스나 데이터 거주지 제약이 있을 때 이득이 되고, 그 전에는 별 의미가 없습니다.

그러니 여러분의 사용량 기준으로 비용 곡선이 어디에서 교차하는지 대략 알아 두세요. 그 교차점이 바로 재정적 논거 전체입니다. 데이터 규정이 실제로 무엇을 요구하는지 알아 두세요. 어렴풋이 느껴지는 요구가 아니라요. 이것이 바로 안전성과 한계와 무엇을 보낼지에 관한 질문이 등장하는 지점입니다. 그리고 오픈 웨이트가 있기에 제공업체의 허락을 구하지 않고 여러분 자신의 방식으로 자유롭게 파인튜닝할 수 있다는 것도 알아 두세요(파인튜닝 참고). 벤더 종속(vendor lock-in), 즉 한 제공업체의 가격, 약관, 모델 생애주기에 묶이는 것을 피하는 일도 같은 계산의 일부입니다.

이 모든 것을 배우는 이유가 셀프 호스팅을 하러 가라는 뜻은 아닙니다. 저는 사람들이 무언가를 증명하려고 직접 스택을 세웠다가 두 번째 온콜 주간이 되기도 전에 후회하는 모습을 본 적이 있습니다. 이 모든 걸 배우는 이유는, 기본 경로가 호스팅된 클로즈드 모델이고 제공업체 입장에서는 대안을 알릴 이유가 별로 없기 때문에, 전체 선택지를 아는 엔지니어라면 물려받은 선택이 아니라 의도적인 선택을 할 수 있다는 데 있습니다.

모델에 관한 문제를 그 나름의 기준으로 다뤘으니, 프롬프팅에서는 좋은 결과를 얻기 위한 일상적인 작업이 시작됩니다.

Juno각각이 적합한 상황 대부분의 팀에게는 호스팅된 클로즈드 API가 올바른 기본값이고, 오픈 웨이트 모델의 셀프 호스팅은 특정 규모를 넘어서거나 컴플라이언스 제약이 있을 때 이득이 되는 비용과 통제권의 문제일 뿐, 성격의 문제가 아닙니다. 여러분의 비용 곡선이 어디서 교차하는지 알아 두고, 데이터 규정이 실제로 무엇을 요구하는지 알아 두고, 오픈 웨이트가 자유로운 파인튜닝과 벤더 종속으로부터의 탈출을 준다는 점을 기억하세요. 저는 뭔가를 증명하려는 셀프 호스팅을 본 적이 있고, 그 후회는 실제였습니다. 전체 선택지를 배워서 의도적으로 선택하고, 그다음 프롬프팅으로 넘어가세요.