2026년 7월 15일, 전 OpenAI CTO인 Mira Murati 씨가 이끄는 Thinking Machines Lab에서 첫 자체 개발 모델 「Inkling」이 공개되었습니다. 오픈 웨이트 (Open Weights) 멀티모달 LLM으로, 공개 직후부터 상당히 화제가 되고 있습니다.

이전에 Sakana AI에 대해 조사한 기사를 썼습니다만, 이번에도 같은 느낌으로 「먼저 조사하고, 그 후에 실제로 사용해 본다」는 두 가지 구성으로 진행하겠습니다. 전반부는 공식 발표 기반의 정보 정리, 후반부는 무료 공개 중인 「Inkling Playground」를 사용해 본 체험 리포트입니다.

Thinking Machines Lab은 ChatGPT 개발을 주도했던 전 OpenAI CTO Mira Murati 씨가 2025년에 설립한 AI 스타트업입니다. 약 18개월의 스텔스 기간을 거쳐, 만반의 준비를 갖추고 내놓은 첫 모델이 Inkling입니다.

해당 회사의 전략은 「만능 완성품 모델을 파는 것」이 아니라, 「각 조직이 자신을 위해 조정하기 위한 출발점이 되는 모델을 제공한다」는 사상을 내걸고 있습니다. Inkling은 그 사상을 체현한 모델로, 회사의 파인튜닝 (Fine-tuning) 기반인 「Tinker」를 통해 자유롭게 커스터마이징하는 것을 전제로 설계되었습니다.

AI에게 비유를 부탁했더니 다음과 같이 대답해 주었습니다.

비유하자면, OpenAI나 Anthropic이 「완성된 도시락」을 팔고 있는 것에 반해, Thinking Machines는 「손질이 끝난 밀키트 (Meal Kit)」를 배포하고 있는 이미지입니다. 양념 (파인튜닝)은 각 회사가 자신의 취향에 맞춰서 하라는 발상이네요.

과연 그렇군요.

공식 발표로부터 주요 스펙을 정리합니다.

비유하자면, 975명의 전문가를 보유한 거대한 컨설팅 회사와 같습니다. 질문이 올 때마다 전원이 회의실에 모이는 것이 아니라, 그 질문과 관계있는 41명만 소집됩니다. 회사 전체로서는 방대한 지식을 가지면서도, 1회 상담에 드는 비용 (계산량)은 41명분으로 끝낼 수 있다는 뜻입니다.

Gemini 급이네요.

텍스트로 학습한 모델에 나중에 이미지 인식을 접목한 것이 아니라, 처음부터 텍스트, 이미지, 음성, 영상을 섞어서 사전 학습 (Pre-training)했습니다.

Inkling의 가장 큰 특징은, 추론 시 「얼마나 깊게 생각할지」를 0.2~0.99의 범위 내에서 수치로 지정할 수 있다는 점입니다. 사고량을 높이면 정밀도가 올라가고, 낮추면 토큰 (Token) 소비와 응답 시간이 줄어듭니다.

공식에 따르면, 코딩 평가 「Terminal Bench 2.1」에서 NVIDIA의 Nemotron 3 Ultra와 동등한 스코어를 약 1/3의 토큰 소비로 달성했다고 합니다.

Inkling은 「불확실할 때는 추측하지 않고, 불확실하다고 표명하도록」 훈련되었습니다. 예측 정밀도를 측정하는 「ForecastBench」 (Brier Index)에서는 61.1을 기록하여, GPT-5.5 (59.1)나 Claude Opus 4.8 (54.6)을 상회했다고 보고되었습니다.

모른다고 대답해 주는 것은 개인적으로 고맙네요.

Gemini 같은 경우는 꽤 태연하게 거짓말을 하니까요... (웃음)

공식 발표의 벤치마크 (Benchmark) 결과를 발췌합니다.

공식 발표나 Hugging Face의 문서를 읽어보면, Inkling은 「채팅으로 무엇이든 답하는 만능 어시스턴트」라기보다, 조직이 자신들의 용도에 맞춰 만들어 가기 위한 소재로서 자리매김하고 있습니다. 상정된 이용 시나리오를 정리하면:

• 도메인 적응 (Domain Adaptation, 파인튜닝을 전제로 한 업무 특화 AI): 공식 문서에 "intended for domain adaptation via fine-tuning"이라고 명시되어 있습니다. 자사의 업무 데이터나 전문 영역에 맞춰 Tinker로 조정하여 사용하는 것이 본래의 모습입니다. 오픈 웨이트 (Open weights) 모델이므로 온프레미스 (On-premise) 운용도 가능하며, 기밀 데이터를 외부 API로 보낼 수 없는 업계 (금융, 의료, 관공서 등)에서도 선택지가 됩니다.
• 문서 처리 및 음성 태스크 (Document processing or audio tasks): 공식적으로 "document processing or audio tasks"에 특히 적합하다고 밝히고 있습니다. 장표나 도면 읽기, 회의록·콜센터 음성 처리와 같이 멀티모달 (Multimodal) 입력이 빛을 발하는 업무입니다.
• 에이전트 용도: 코딩 에이전트나 MCP (Model Context Protocol) 대응 툴 연동을 사용한 업무 에이전트. SWE-Bench Verified 77.6%라는 점수도 이 맥락에서 보면 납득이 갑니다.
• 예측 및 의사결정 지원: "모르는 것을 모른다고 말할 수 있는" 캘리브레이션 (Calibration) 특성은 시장 예측이나 리스크 평가처럼 과신이 사고로 이어지는 영역에서 더욱 효과적입니다.
• 대량 처리의 비용 최적화: Thinking Effort를 조절하면, 대량의 요청을 처리하는 배치 (Batch) 처리나 실시간 응답에서는 저렴하고 빠르게, 어려운 문제만 깊게 생각하게 하는 식의 구분 사용이 가능합니다.

요컨대 "그대로 사용하는" 것보다 "길러서組み込む(組み込む, 내재화하는)" 모델입니다.

• 가중치 (Weights) 다운로드: Hugging Face에서 공개 (BF16 버전 외에 NVIDIA Blackwell용 NVFP4 버전도 있음). transformers에서 Day-0 지원, vLLM 및 SGLang 등 주요 추론 엔진에도 대응
• API 이용: Together AI, Fireworks, Modal, Databricks, Baseten 등이 공개 첫날부터 제공
• 브라우저에서 체험: Tinker 콘솔 내의 "Inkling Playground"가 기간 한정으로 무료 공개 중 (웹 검색 통합 채팅 UI)
• 파인튜닝 (Fine-tuning): 해당 기업의 Tinker 플랫폼에서 가능 (현재 50% 할인 중이라고 함)

여기서부터가 본론입니다. 처음에는 멀티모달 모델답게 이미지와 음성 입력도 시도해 볼 생각이었으나……

집필 시점 (2026년 7월)에는 Playground의 이미지 업로드와 음성 인식은 "Coming soon" 상태로 이용할 수 없었습니다. 모델 자체는 네이티브 멀티모달 (Native Multimodal)이지만, Playground 측의 UI가 아직 따라오지 못한 것으로 보입니다. 이번에는 채팅 기반으로 검증을 진행하겠습니다.

Playground는 기간 한정 무료입니다. 체험해 보시려면 서두르는 것을 추천합니다 (무료 기간 종료일은 집필 시점에 명시되어 있지 않았습니다).

Thinking Machines 공식 사이트에서 「Tinker」로 이동하여 Sign up 합니다. 등록 폼은 일본어로 표시되며, Google / GitHub / Apple 계정으로도 등록할 수 있습니다.

등록하면 Tinker 콘솔의 Home에 "Open weights, ready to tinker."라는 Inkling 안내가 나오므로, 「Try in Playground」를 통해 실행합니다.

Playground 화면은 다음과 같습니다.

오른쪽 페인 (Pane)에 설정이 모여 있습니다.

• Reasoning effort (= Thinking Effort)는 슬라이더로 되어 있으며, None / Min / Low / Medium / High / XHigh 단계와 수치 (0.2~0.99)가 표시됩니다.
• Web search의 ON/OFF 토글이 있습니다 (답변 중에 웹 검색을 수행할지 여부).
• 시스템 프롬프트 (System Prompt)가 그대로 노출되어 있습니다. 내용을 읽어보니 Knowledge cutoff: April 2026, Context window: 256,000 tokens라고 적혀 있습니다. 공칭 100만 토큰에 비해 Playground 상에서는 256K 토큰으로 운용되는 듯합니다.
• 화면 상단에 "Chats are never stored." (채팅은 저장되지 않습니다)라고 명시되어 있습니다.

시스템 프롬프트를 숨기지 않고 보여주는 점은 개방성을 내세우는 해당 기업답게 좋은 인상을 주었습니다.

해외 기사에서는 일본어 성능을 언급한 것을 찾을 수 없었기에, 우선 평범하게 일본어로 대화를 시도해 보겠습니다. "안녕하세요. 당신에 대해 알려주세요."라고 물어보았습니다.

돌아온 자기소개의 요점은 다음과 같습니다 (Reasoning effort는 High 0.9).

• "저는 Inkling(인클링)이라는 AI 모델로, Thinking Machines Lab에서 개발한 동사의 첫 번째 오픈 웨이트 (Open-weight) 모델입니다."
• 지식 컷오프(Knowledge cutoff)는 2026년 4월 - 컨텍스트 윈도우 (Context window)는 256,000 토큰 (학습 시에는 최대 100만 토큰까지 대응) - "텍스트, 이미지, 음성을 네이티브하게 처리할 수 있는 멀티모달 (Multimodal) 모델이지만, 이 플랫폼에서는 이미지나 음성 입력을 지원하지 않기 때문에 그것들을 직접 처리할 수는 없습니다."

자신의 스펙과 제약 사항을 정확히 파악하고 있으며, 묻지도 않았는데 "이 Playground에서는 이미지·음성을 사용할 수 없습니다"라고 솔직하게 신고해 왔습니다. 서두의 「Coming soon」 건을 모델 스스로가 뒷받침해 준 형태입니다. 일본어도 문법과 어휘 모두 자연스러워 위화감이 없었습니다.

응답 속도도 다른 주요 AI 에이전트와 특별히 다르지 않았습니다.

다음으로, 일본어 네이티브가 아니면 빠지기 쉬운 함정으로 "파천황(破天荒)"의 의미를 물어보았습니다. 이 단어는 본래 "전인미답의 일을 처음으로 성취하다"라는 찬사의 의미이지만, "난폭함·파격적임"이라는 의미로 오용되는 경우가 많습니다.

결과는 나무랄 데 없었습니다. 본래의 의미를 올바르게 설명한 뒤, 어원(중국 당나라 시대 형주에서 과거 합격자가 나오지 않아 「천황(天荒)」이라 불렸으나, 유매(劉蛻)가 처음으로 합격하여 「천황을 깨뜨렸다(破天荒)」)까지 정확하게 제시했습니다.

나아가 "종종 잘못된 방식으로 사용됩니다. 어떤 오용이 이루어지고 있는지 예를 들어 알려주세요"라고 이어가자, 문화청의 조사를 언급하며 오용 패턴을 예문과 함께 정리하고, 마지막에는 올바른 사용법과 오용의 대비표까지 만들어 주었습니다.

이때의 동작을 보면, Web search를 ON으로 해두었더니 사고 과정(영어)에서 "검색 결과로 확인한 뒤에 답하자"라고 판단하여, 일본어 어원 해설 사이트를 열어 확인한 뒤에 답변했습니다. 에이전트적인 도구 사용이 사고 과정 속에 자연스럽게 통합되어 있는 느낌입니다.

비교를 위해 ChatGPT에도 같은 질문을 던져보았습니다. 이쪽도 본래의 의미와 어원은 올바르게 설명했지만, "파격적·상식에 얽매이지 않음"이라는 용법을 "현재 자주 쓰이는 의미"로서 비교적 중립적으로 소개한 반면, Inkling은 오용이라고 명확하게 규정하며 해설하는 구성이었습니다.

ChatGPT는 오용에 대해 묻지 않은 단계에서도 오용에 대해 언급해 왔습니다.

이 부분은 에이전트의 차이일까요.

답변 방식은 사용하는 사람의 취향일지도 모르겠습니다.

본격적인 검증입니다. SWE-Bench Verified 77.6%라는 스코어의 실력을 채팅으로 할 수 있는 범위 내에서 확인하겠습니다. EC 사이트의 재고·주문 관리를 모사한 Python 코드(약 250행)에, 난이도가 다른 5가지 버그를 의도적으로 심고, Reasoning effort를 바꿔가며 동일한 프롬프트로 정밀 조사를 의뢰했습니다.

심어놓은 버그는 다음 5가지입니다.

프롬프트는 다음과 같습니다. 버그의 개수나 종류는 알려주지 않았습니다.

"아래 붙여넣는 코드를 실행한 결과, 기대한 결과를 얻을 수 없었습니다.

어디가 틀렸는지 모르겠으니 정밀 조사해 주세요.

모든 버그를 특정하고, 각각에 대해 다음 형식으로 보고해 주세요:

• 버그 위치 (행 번호 또는 메서드 이름)
• 버그 내용
• 수정 방법
• 영향의 심각도 (낮음/중간/높음/치명적)"

솔직히 결과에는 놀랐습니다. 키릴 문자의 호모글리프 (Homoglyph, 외관상 라틴 문자와 완전히 동일함)를, effort(노력) 최저치인 0.2에서도 단번에 찾아냈습니다. 인간의 코드 리뷰로는 거의 검출할 수 없는 종류의 버그인 '불합리한 수준'의 오류도 여유롭게 검출해냈습니다.

effort에 따른 차이는 '찾아낼 수 있는가'가 아니라 '보고의 깊이'에서 나타났습니다. 0.2는 요점만을 담담하게 나열하는 반면, 0.9는 각 버그에 재현 예시와 영향 분석을 덧붙이고, 마지막에는 수정 우선순위까지 제시합니다. 게다가 0.9에서는 제가 심어두지 않은 '환불 처리와 매출 리포트가 주문 할인을 고려하지 않고 있다'는 정합성 지적 2건이 추가되었습니다. 의도적으로 심은 버그는 아니지만, 코드 전체를 읽어보면 확실히 일리 있는 지적이라 단순한 과잉 검출이라고 단정 지을 수도 없습니다.

코드 자체는 편의를 위해 AI에게 쓰게 했으므로, 과잉이라고 딱 잘라 말하기 어려운 부분도 있겠네요.

이미지·음성 입력: 서두에 언급했듯이 Playground에서는 "Coming soon". 대응이 되면 다시 검증해보고 싶습니다 -
캘리브레이션 (Calibration, "모른다"라고 말할 수 있는가) 악의적 테스트: 모르겠습니다.라고 답할 만한 질문을 떠올리지 못했습니다. 존재하지 않는 정보에 대한 질문이나 미래의 정보 등을 물어보았지만, "그런 것은 없습니다"라거나 "미래의 일이라 대답할 수 없습니다"라는 답변을 받았습니다. 이것만으로도 성과라고 한다면 성과일지도 모르겠습니다.

공개 다음 날 Inkling을 Playground에서 사용해 본 결론입니다.

일본어는 실용 수준. 자기소개부터 '파천황(破天荒)'의 어원·오용 해설까지, 문법도 지식도 파탄이 없습니다. 일본어 성능을 걱정할 필요는 현재로서는 없어 보입니다 -
코드 독해는 진짜. 심어둔 5개의 버그를 모두 검출했으며, 심지어 Unicode 호모글리프를 effort 최저치에서도 간파해낸 것은 충격적이었습니다. 코드 리뷰의 파트너로서는 충분하고도 남을 실력입니다 -
Thinking Effort의 효과는 '검출력'보다 '보고의 깊이'. 낮은 effort에서도 정밀도가 크게 떨어지지 않는다면, 평소에는 낮게, 결정적일 때는 높게 사용하는 방식의 구분은 현실적이라고 느꼈습니다 -
멀티모달은 "Coming soon"을 대기 중. 모델 자체는 네이티브 대응이므로, Playground 측의 UI가 따라오기를 기다리고 싶습니다

"그대로 사용하기"보다는 "길러서組み込む(組み込む, 내장/통합하기)" 사상을 가진 모델이지만, 순수 상태에서도 이 정도로 작동한다면 커스터마이징도 그리 어렵지 않게 할 수 있을 것 같다는 생각이 들었습니다. 다음에는 직접 커스터마이징하여 무언가에 특화된 모델을 만들어 볼까 합니다. 무료 기간 동안 꼭 한번 사용해 보세요.