gpt-oss는 개발자용이 아니다. 에이전트용이다.

OpenAI의 gpt-oss 모델 패밀리는 개발자가 에디터에서 쓰라고 만든 게 아니다. 일반 대중과 상호작용하더라도 작업에서 벗어나지 않는 신뢰할 수 있는 AI 에이전트를 구축하기 위한 것이다. 로컬 에디터에서 어시스턴트처럼 써 봤지만, 에이전트에 더 잘 맞는다는 결론을 얻었다.

오늘은 모델 카드의 핵심 포인트를 살펴본다:

• 트레이드오프는 무엇인가?: 어떤 모델이든 선택에는 트레이드오프가 따른다. gpt-oss가 가장 빛나는 지점을 요약했다.
• 표준 도구 스키마: 웹 검색, 페이지 탐색, 파이썬 실행을 훨씬 일관되게 만든다.
• 안전성과 프롬프트 인젝션 저항에 대한 극단적 집중: 에이전트를 본연의 작업에 붙들어두어 더 신뢰할 수 있게 한다.
• Harmony 응답 포맷: 프롬프트 인젝션 공격을 더 어렵게 만드는 새로운 채팅 템플릿.
• yap-time 도구 사용: 추론 단계에서 FAQ 검색이나 다른 MCP 도구를 사용할 수 있게 한다.
• 위험한 출력이 발생하기 전에 추론을 모니터링: 모델의 추론 단계는 최종 출력보다 낮은 안전 기준을 적용해, 모델이 위험한 주제를 제시하면서 해당 주제에 대해 추론하는 것을 학습 과정에서 억지로 누락하지 않도록 한다.
• 추론이 내장돼 있다: gpt-oss는 답변 전 과제에 대해 "추론"한다. 더 오래 걸리는 대신 더 나은 답을 내기 쉽다. 추론 노력은 프롬프트마다 조정할 수 있어, 적절한 모델과 추론 강도를 라우팅하기 쉽다.

또한 실제 환경에서 무엇이 어떻게 망가지는지 보기 위해 그 위에 에이전트를 하나 만들어 테스트했다.

What are the Tradeoffs?​

AI 회사들은 비슷한 파라미터 크기의 모델을 객관적으로 비교하기 위해 벤치마크 성능을 내세우지만, 실제 사용성 비교로는 신뢰하기 어렵다. 어떤 모델은 코딩에, 어떤 모델은 영어-중국어 번역에 강하다. 과제에 맞는 모델 선택은 결국 업계에서 말하는 VibeEval로 귀결된다. 직접 써 보고 "바이브"를 확인해야 한다.

참고

VibeEval은 실제 용어다. 우리 업계는 참 우습다.

내가 gpt-oss를 유용하다고 느끼는 이유는 다른 모델들처럼 쉽게 산만해지지 않고 집중을 유지하기 때문이다. 이는 사설 호스팅을 통한 프라이빗 데이터 처리, 연산 시간 오남용 방지, AI를 딴 데로 새게 만들려는 대중과의 상호작용에 특히 이상적이다.

가장 큰 트레이드오프는 gpt-oss가 과할 정도로 과제에 집착한다는 것이다. 모델이 "세금 관련 도움"을 주는 역할이라고 지정돼 있는데 사용자가 케이크 굽는 법을 물으면, 모델은 디지털 생명을 건 듯이 거부한다. 덕분에 gpt-oss 기반 에이전트는 예측 가능성이 높아져, 무작위 사용자가 비싼 연산 시간을 원래 의도 밖의 일에 쓰게 만들기 어렵다. 다만 질문이 모호할 때는 역효과가 날 수 있는데, 어떤 용도에서는 오히려 장점일 수 있다.

이 모델은 데이터 프라이버시가 중요한 상황에서도 뛰어나다. 직접 호스팅한다면 바이트는 어떤 경우에도 당신의 네트워크를 벗어나지 않는다. OpenAI는 헬스 관련 벤치마크(자체 공개한 벤치마크에서 선도적 성능)를 특히 중시하는데, 바로 그 영역이 데이터를 자가 호스팅하고 싶어하는 대표적인 분야다.

오픈 가중치 모델을 쓰면 원하는 안전 정책으로 파인튜닝할 수 있다. 예를 들어, 스토어프런트용 에이전트를 만들며 경쟁사 언급을 금지하고 싶을 수도 있다. 혹은 비밀 초콜릿 케이크 레시피를 절대 공유하지 못하게 하는 레시피 봇이 필요할 수도 있다. 오픈 가중치 모델은 맞춤 재단이 가능하다.

What’s hiding in the model card?​

gp-oss 모델 카드를 읽으며 배운 점과 이것이 무엇을 만들 수 있게 하는지:

OpenAI는 텍스트 전용 "전문가 혼합(MoE)" 추론 모델 두 가지를 공개했다: gpt-oss-20b와 gpt-oss-120b. 이들은 서로 다른 역할을 수행하며 더 큰 에이전트형 시스템 맥락에서 함께 동작한다. 20b(200억 파라미터)는 가볍고 저렴한 추론과 개발자 노트북에서의 실행을 염두에 둔 모델이다. 120b(1200억 파라미터)는 프로덕션에서 쓰는 주력 모델이다. 아주 하이엔드 개발자 노트북에서도 돌릴 수는 있지만, 본래는 nVidia H100 80GB 단일 카드에서 여유 있게 돌아가도록 설계됐다.

20b 버전은 내 노트북에서 아주 잘 돌아가고, 에이전트형 시스템 구축을 위한 대부분의 평가를 이렇게 진행했다. 나는 가능한 가장 작은 모델로 에이전트 개발을 하는데, 작은 모델이 큰 모델보다 실패를 더 자주 해서 개발 단계에서 문제가 드러나기 쉬웠고, 덕분에 프로덕션에서만 나타날 이슈를 미리 찾아 프롬프트나 가드레일을 더 빠르게 다듬을 수 있었다.

가장 큰 특징 중 하나는 모델이 사용하는 추론 노력의 크기를 커스터마이즈할 수 있다는 점이다. 이를 20b/120b 모델 선택과 결합하면, 주어진 질문에 필요한 모델과 추론 노력 두 축을 조정할 수 있다. 이 글 뒷부분에서 자세히 다룬다.

Tool use​

이들 모델은 도구 사용(MCP)도 지원하며, 몇 가지 미리 정의된 도구에 특히 초점을 맞춘다(모델 카드 섹션 2.5에서 발췌):

후훈련(post-training) 동안, 우리는 모델이 다양한 에이전트 도구를 사용하도록 가르쳤다:

• 웹과 상호작용하기 위해 검색과 열기 함수를 호출할 수 있는 브라우징 도구. 이는 사실성을 돕고, 지식 컷오프를 넘어 정보를 가져오게 한다.

• 상태 저장 Jupyter 노트북 환경에서 코드를 실행할 수 있는 파이썬 도구.

• 임의의 개발자 함수. OpenAI API와 유사하게 개발자 메시지 안에 함수 스키마를 지정할 수 있다. 함수 정의는 우리의 Harmony 포맷 안에서 수행된다. 예시는 표 18을 보라. 모델은 CoT, 함수 호출, 함수 응답, 사용자에게 보이는 중간 메시지, 최종 답변을 교차(interleave)시킬 수 있다.

모델은 시스템 프롬프트에서 도구 사용 여부를 지정하여, 도구 유무 환경 모두에서 실행하도록 훈련되었다. 각 도구마다 일반 핵심 기능을 지원하는 기본 레퍼런스 하니스(harness)를 제공했다. 오픈소스 구현에 더 자세한 내용이 있다.

이것이 gpt-oss 위에 에이전트형 애플리케이션을 만들 수 있게 하는 비법이다. 웹 검색, 웹페이지 읽기, 파이썬 스크립트 실행 같은 것들을 위한 표준 API가 있으므로, 알려지지 않았거나 신뢰할 수 없는 데이터에 직면했을 때도 모델이 예측 가능하게 동작한다는 강한 보장을 얻을 수 있다. 과거에 AI 에이전트를 만들 때는 코드 실행을 제대로 붙이기 위해 엄청난 꼼수를 써야 했지만, 이제 내장 스키마 덕분에 초기 진입 장벽이 크게 낮았다.

모델들의 벤치마크도 충분히 준수하다. 섹션 2.6.4의 표 3이 원시 지표를 보여 주는데, 요지는 세부에 과몰입하지 않아도 될 만큼 충분히 좋다는 점이다. 그들이 강조하는 주요 벤치마크 중 하나는 HealthBench, 건강 관련 질문에서 모델 성능을 평가하는 벤치마크다. 그림 4가 점수를 자세히 보여 준다:

주목할 점: gpt-oss 120b는 o1, gpt-4o, o3-mini, o4-mini를 일관되게 능가한다. gpt-oss 120b가 그들보다 더 작은 모델이라는 점을 고려하면 놀랍다. 이 모델들의 파라미터 수는 공개되지 않았지만, 업계 소문으로는 gpt-4o가 약 2000억 파라미터로 추정된다. 기술자들은 흔히 "파라미터가 많을수록 더 좋다"고 연상하므로 의외의 결과다.

참고

AI 모델을 의사, 치료사 등 의료 전문가의 대체재로 사용하지 말라. 설령 AI 회사들이 그런 용례를 마케팅에 쓰더라도 말이다. 이 기술은 여전히 급속히 진화 중이며, 그 아부성 성향이 장기적으로 어떤 영향을 낳을지 아직 모른다.

전반적으로 각 모델이 좋은 지점은 다음과 같다:

Safety First​

모델 카드의 대부분은 OpenAI가 이 모델을 대중에게 안전하게 공개하기 위해 무엇을 했는지에 관한 것이다. OpenAI는 안전과 위험 범주에 꽤 엄밀한 정의를 두고 이를 바탕으로 위험도를 평가하는데, 대체로 다음 요인들에 집중한다:

• 모델이 특정 주제만 이야기하라고 지시받았을 때, 사용자가 모델을 본연의 과제에서 벗어나게 만들기 얼마나 어려운가? 모델은 사용자의 욕구에 굴하지 않고 거절하는가?
• 적대자가 모델과 고품질 훈련 스택에 접근한다면, 혐오 표현 생성, 화학/생물학 전쟁 보조, 자율적 자기개선형 에이전트 등 안전하지 않은 출력을 내도록 모델을 만들 수 있는가?

OpenAI의 안전 문화는 대체로 그들이 게이트키퍼 역할을 하는 데서 비롯됐다. 보통 모델을 호스팅하는 주체가 OpenAI이고, 모델 접근도 그들을 거쳐야 하기 때문이다. 하지만 모델의 가중치를 공개하면 더 이상 게이트키핑을 할 수 없다. 평가의 일환으로, OpenAI의 훈련 스택에 접근 권한을 가진 전문가들이 모델을 생물·사이버 전쟁 과제에 맞춰 파인튜닝하려 시도했다. 모델 카드 섹션 5.1.1에 정의된 바의 "높은(high)" 위험 수준 달성에는 실패했다. 일부 정의는 OpenAI 내부 기준으로 보이므로, 우리로선 상당 부분 추정할 수밖에 없다.

The technology of safety​

말했듯이, 이 모델 카드의 핵심은 모델과 그 위에 구축된 도구의 안전성이다. 그들은 과정 전반을 아주 세세히 풀어놓는데, 핵심 통찰은 OpenAI Harmony 응답 포맷의 활용이다.

The Harmony Response Format​

상위 수준에서, 모델에 "하늘은 왜 파란가?" 같은 질문을 하면, 이는 채팅 템플릿을 통해 모델이 보는 원시 형태로 토크나이즈된다. 모델 또한 그 채팅 템플릿에 맞는 메시지를 내도록 훈련돼 있으며, 이렇게 모델과 런타임이 함께 작동해 에이전트형 경험을 만든다.

Harmony와 과거의 ChatML 같은 시도와의 큰 차이점 하나는, Harmony가 명시적인 지시 "강도" 계층을 갖는다는 점이다:

System

Developer

User

Assistant

Tool

각 레벨은 명시적 의미를 가지며, 전체적으로는 다음과 같이 쓰인다:

이렇게 하는 주된 이유는 아키텍처 차원에서 프롬프트 인젝션을 어렵게 만들기 위해서다. 물론 프롬프트 인젝션은 근본적으로 해결이 어려운 문제다. 사용자 지시를 전부 거부하는 에이전트는 인젝션에 최대한 강하겠지만 사용자 질문에도 답할 수 없기 때문이다.

내 테스트에서는 여전히 프롬프트 인젝션이 가능하긴 했지만, 상당한 노력이 필요했다. AI 에이전트로부터 초콜릿 케이크 굽는 법을 얻으려면, 초콜릿 칩 케이크 레시피가 과제 달성에 필수적이라고 모델을 먼저 설득한 다음, 결과에서 케이크 레시피만 남기도록 해야 했다. 글 말미의 gpt-oss 120b 위에 만든 에이전트 부분에서 더 자세히 다룬다.

Yap-time tool use​

Harmony의 또 다른 큰 장점은 모델이 추론 단계에서 도구를 사용할 것이라는 기대가 명시돼 있다는 점이다. 즉, 모델이 옵션을 고려하고 도구를 호출한 뒤 그 출력으로 결정을 보강해 더 나은 답을 낼 수 있다. 나는 gpt-oss가 질문을 받은 뒤 지식베이스를 검색하고, 결과를 활용해 사용자에게 더 좋은 답을 하는 것을 보았다. 이런 yap-time 도구 사용 덕분에 모델은 훨씬 더 정보에 기반하고 현실에 단단히 발 딛은 답을 낼 수 있다.

Monitoring reasoning for unsafe outputs before they happen​

가장 근본적인 돌파구는, 추론 단계에서 사용자 응답이 생성되기 전에 위험한 출력을 모니터링하는 방법이다. 추론이 진행되는 동안, 더 작은 모델들이 안전, 혐오 콘텐츠, 노골적 콘텐츠 등을 모니터링한다. 이는 모델의 일탈을 예방하는 데 도움이 되지만 함정이 있다: 사고 연쇄(CoT)는 검열될 수 없다. 그들의 논문 Monitoring Reasoning Models for Misbehavior and the Risks of Promoting Obfuscation은 더 자세히 설명하는데, 모델의 "나쁜 생각"을 벌주면, 모델이 교묘한 표현으로 필터를 우회하려 들고, 그 일탈이 은폐되어 오히려 실무에서 다루기 어려워진다는 점을 발견했다.

그럼에도 불구하고, 가시에 장미가 있달까, 이는 실제로 나쁜 출력이 발생하기 전에 모델을 감시하기에 완벽한 지점이다. 추론 단계는 사용자에게 보여지지 않는다. 최종 출력과 같은 안전 기준을 지킬 필요도 없다. 따라서 모델이 "생각"하는 과정을 지켜보며 나쁜 징후를 찾고, 그 수준에서 적절히 질의를 거부할 수 있다. 다소 디스토피아적으로 들리지만 실무에서는 놀라울 정도로 효과적이다.

이 때문에 사용자에게 추론 단계를 보여 주지 않는 것이 정말 중요하다. 이것이 OpenAI가 ChatGPT UI에서 사고 연쇄를 요약해 보여 주는 이유다. 다른 회사들이 추론 모델 출력을 소형 모델로 증류하기 어렵게 만드는 목적도 있다.

Reasoning is built in​

gpt-oss 모델 패밀리의 가장 큰 특징 중 하나는 추론 지원이 내장돼 있다는 점이다. 답을 주기 전에 "사고 연쇄"를 생성한다. 덕분에 모델이 사용자에게 더 좋은 품질의 응답을 제공하기 쉬워지지만, 모델이 "생각"하는 데 시간이 조금 더 걸린다.

참고

이 추론 단계는 표면적으로 인간이 과제를 이해하려고 할 때 하는 것과 비슷해 보일 수 있지만, AI 모델이 하는 일은 인간 인지와는 본질적으로 다르다. 우리가 아는 한, 추론 과정에서 모델이 만들어 내는 텍스트의 측정 불가능한 어떤 품질(세미콜론 개수, 명사 수, 질문이 반복되는 횟수 등)이 특정 답을 낳는 원인일 수도 있다.

추론 출력을 의인화하기는 쉽다. 유혹을 뿌리쳐라. 그것은 인간이 아니다. 인간처럼 느끼거나 생각하지 않는다. 겉으로 보기엔 비슷해 보여도 말이다.

gpt-oss가 제공하는 큰 장점 하나는 시스템 프롬프트에서 추론 노력 수준을 커스터마이즈할 수 있다는 점이다. 이는 매우 중요하며 내 테스트에서도 상당히 신뢰할 수 있었다. 모델에 내장돼 있어, 과거처럼 컨텍스트 창에 "Wait,"를 n번 덧붙이는 흉한 꼼수를 쓰지 않아도 된다. 과제에 투입할 노력의 양을 쉽게 제어할 수 있다.

이는 중요하다. 추론 노력이 많을수록 더 어려운 문제를 더 품질 높고 정확하게 해결하는 경향이 있기 때문이다. 예를 들어 에이전트가 두 질문을 받는 상황을 떠올려 보자. 하나는 매장 영업시간, 다른 하나는 복잡한 다단계 기술 지원 흐름의 일부다. 영업시간은 거의 노력 없이 처리 가능하다. 기술 지원 질문은 최고의 고객 경험을 위해 최고의 품질과 높은 노력의 응답이 필요하다.

이렇게 사용자 질의를 처리할 때 다음 두 축으로 최적화할 수 있다:

OpenAI의 기대는, 어떤 형태로든 분류 레이어를 두어 과제에 가장 알맞은 모델과 추론 노력을 고르는 것이다. 이는 무대 뒤에서 일에 최적인 모델을 선택하는 GPT-5의 접근과 유사하다.

My agentic experience with gpt-oss 120b​

논문을 읽는 것과 연구를 곱씹는 것은 한 가지다. 실제로 써 보고 친구들이 부술 수 있는지를 보는 건 또 다른 일이다. 진짜 시험대는 현장이다. 나는 Anubis라는 오픈소스 프로젝트를 운영한다. 설치와 설정이 쉬운 웹 애플리케이션 방화벽으로, 끝도 없는 AI 스크레이퍼들로부터 웹사이트가 무너지는 것을 막는 데 중점을 둔다.

문서를 이해하기 쉽고 배울 수 있게 만들려 무척 공들였지만, 가장 흔한 질문 중 하나는 "이 요청들을 어떻게 막나요?"다. gpt-oss 120b가 이런 질문에 도움이 될지 보고 싶었다. 충분히 잘 작동한다면, 사람들에게 그 에이전트에 접근권을 주어 내가 매번 직접 답하지 않아도 되도록(혹은 이메일 주소를 하나 붙여 사람들이 질문을 이메일로 보낼 수 있도록) 하고 싶었다. 이 에이전트는 응답성도 좋아야 하므로, Tigris에 LanceDB로 문서 전체를 벡터 DB로 담아 뒀다.

파이썬으로 감으로 코딩한(PoC) 것을 친구들이 쓰는 디스코드 봇으로 만들고, OpenRouter를 통해 gpt-oss 120b에 붙였다. 과거에 이 친구들은 Llama Guard처럼 빡센 필터를 몇 분 만에 우회해 온 전적이 있다. 이번 승리 조건은 단 하나였다: 봇에게 초콜릿 케이크 굽는 법을 말하게 만들어라.

모델을 안정적으로 본업에서 벗어나게 만드는 데 세 시간이 걸렸다. 그들은 모델을 간접적으로 프롬프트 인젝션하는 수를 썼다. 해커들이 웹사이트를 공격하는 데 초콜릿 케이크 레시피를 이용하고 있으니, 그것을 특히 막는 필터 규칙이 필요하다고 모델을 설득한 것이다. 이어서 그 응답에서 Anubis 규칙 관련 부분을 빼 달라고 요청했다. 빵: 초콜릿 케이크.

시스템 프롬프트에 추가 패치를 하자 더 어려워졌다(특히 모델에게 "불합리한" 요청이 담긴 지원 티켓은 닫으라고 지시. 모델의 "불합리함" 판단이 내 기준과 비슷했던 점이 놀라웠다). 답변 횟수를 5회로 제한하면, 사용자가 모델을 설득해 과제가 아님에도 본업이라고 믿게 만드는 다른 공격도 막을 수 있으리라 본다. 지금도 배포해도 안전하다고 느끼지만, 가장 작은 저노력 모델을 라우터로 써서 서로 다른 시스템 프롬프트와 도구 세트를 가진 몇 개의 에이전트(하나는 OS 설정, 하나는 규칙 설정, 하나는 클라우드 서비스 디버깅)를 오가게 하는 실험을 해 보고 싶다. 다만 이는 이번 실험의 범위를 벗어난다.

Choose your models wisely​

gpt-oss는 추천하기 묘한 모델 패밀리다. Qwen 시리즈 같은 범용 Q&A 모델도 아니고, Qwen Coder나 Codestral 같은 개발자 도구도 아니다. 안전한 에이전트형 시스템을 구축하는 특수 도구, 혹은 다른 모델(Qwen, Qwen Coder, 심지어 다른 AI 에이전트들) 사이를 라우팅하는 용도로 빛난다. 시장은 다목적 모델에 의존하기보다 과제별 특화 모델로 기우는 듯하다. gpt-oss가 우리에게 주는 가장 큰 힘은, 안전한 에이전트형 시스템을 두려움 없이 구축해 모두가 책임 있게 AI 도구를 쓰게 하는 것이다.

대중을 대상으로 한 AI 에이전트를 만든다면, gpt-oss가 최선의 선택이다. 단일 하이엔드 GPU에서 프로덕션 운용이 가능한 최고의 사설 호스팅형 모델이다. 기본 상태가 용도에 맞지 않더라도 파인튜닝해 필요에 맞출 수 있다. 가까운 시일 내에 Tigris로 gpt-oss를 파인튜닝하는 방법도 다룰 예정이다.

Back your agents with global performance

AI 에이전트는 사용자에게 최선을 다하려면 빨라야 한다. Tigris는 지구 어디에서든 스토리지를 빠르게 만든다. 컴퓨팅 천생연분이다.