이 작품은 오프라인 단일 HTML이다. npm 설치나 외부 API 호출 없이 브라우저에서 바로 연다. Three.js 장면·UI·합성 바람·풀벌레 소리(Web Audio)가 한 파일에 들어가 있다. 메타 설명은 「보름달 아래 따뜻한 한옥 마당. 황금빛 들판과 감나무, 송편을 나누는 가족이 있는 인터랙티브 Three.js 한가위 풍경」이다.
장면과 조작
시점(VIEW): 01 고향집 · 02 송편 마당 · 03 황금 들녘 · 04 달맞이
슬라이더: 빛의 온도(저녁 등) · 가을바람(산들 등)
단축: 드래그로 둘러보기 · 스크롤(또는 두 손가락)로 가까이 · Space 일시정지 · H 풍경만 보기 · 처음 자리로 돌아가기
핫스팟: 감나무에 바람 한 줌 · 송편 드시고 가세요 · 낮잠 한숨(마당 지킴이)
기타: 합성 가을 소리 켜기 · 지금 풍경 PNG 저장 · 전체화면(데스크톱)
브랜드 카피: 한가위, 작은 고향 — A LITTLE PIECE OF HOME · 에디션 표기: AUTUMN, IN MINIATURE — A warm homecoming.
업데이트 2026-10-01 (한국시간): 구글이 한국 시간 10월 1일 오전 5시(미국 9월 30일) ‘제미나이 4 아르곤(Gemini 4 Argon)’을 공식 발표했습니다. 공식 모델명은 ‘Gemini 4 Pro’가 아니라 ‘아르곤’이며, Argon은 코드네임이 아니라 정식 모델 이름입니다. 공식 출력 한도는 100만 토큰으로 아래 유출 스펙(25만 6천)과 다릅니다. 지금은 구글 내부와 페어윈드 프로그램 기관만 쓸 수 있고, 일반 공개 날짜는 발표되지 않았습니다. Arena의 3.8 Flash 라벨 시연이 아르곤이었는지는 공식 발표에 언급이 없어 여전히 미확정입니다. 공식 발표 내용과 벤치마크 검증은 제미나이 4 아르곤 정리에 정리했습니다. 아래 본문은 2026년 9월 23일 시점의 기록입니다.
한 줄로. Arena에 Gemini 3.8 Flash 라벨로 올라온 고품질 SVG·미니게임 출력이 “숨겨진 Gemini 4 Pro(Argon)”인지(Argon은 9월 30일 제미나이 4 아르곤으로 공식 발표됨), 아니면 이미 공개된 Flash를 더 세게 돌린 것인지 아직 확정되지 않았다. 작성 당시 Google이 이름으로 붙인 사실은 Gemini 4 사전학습이 시작됐다는 수준까지였다. 이후 9월 30일(미국) 구글이 제미나이 4 아르곤을 공식 발표하면서 모델명·출력 한도·발표 가격·벤치마크가 공개됐다.
먼저 읽는 면책
이 글은 YouTube 채널 BitBiasedAI의 정리 영상을 확인·미확인·반박으로 나눈 AI 소식 메모다. moonlang이 Arena·유출물을 직접 재현·측정한 결과가 아니다.
X 계정 유출 스펙·벤치마크 시트는 독립 검증 전제로만 적는다. 확인되지 않은 숫자를 사실처럼 쓰지 않는다.
다루는 축: Arena 시연 라벨, Argon 유출 주장, Google이 공개한 문장, 반박 신호
확인 사다리 — 위로 갈수록 근거가 약함 · moonlang 재현 아님
확인된 것 (회사·공개 기록 쪽)
영상은 DeepMind/관련 발언을 인용하며, Sundar Pichai가 Gemini 4의 가장 야심 찬 사전학습 런을 이미 시작했다고 말한 수준까지를 “확인”으로 둔다. 출시일·Pro 티어·코드네임·벤치마크는 그 인용에 없다. (작성 당시 기준. 9월 30일 공식 발표로 모델명과 출력 한도·벤치마크가 공개됐다.)
영상이 정리한 공개 제품 쪽 숫자는 Gemini 3.8 Flash 기준 컨텍스트 약 100만 토큰 · 출력 상한 약 6만 4천 토큰이다. (영상·공개 스펙 시트 서술. moonlang API 재측정 아님.)
영상 타임라인: Flash 계열이 2026년 들어 자주 올라왔고, 3.8 Flash는 9월 2일 전후로 서술된다.
Arena에서 무엇이 보였나 (라벨은 3.8 Flash)
영상·포럼 보고에 따르면 9월 17일 전후 Arena 익명 배틀에서, 인터페이스 라벨이 Gemini 3.8 Flash인 응답이 단순 그림이 아니라 조작 가능한 SVG·HTML을 냈다.
자전거 타는 펠리컨 — 색·낮/밤 토글이 동작했다고 보고
자전거 타는 주전자 — 같은 식의 인터랙션
ウルトラマン×ゴジラ SVG/HTML 미니게임 — 레이저·점수 카운터 등이 동작했다고 보고 (점수 예: 234,350은 시연 화면 숫자이며 벤치마크가 아님)
요점은 “출력이 인상적이었다”와 “라벨이 이미 공개된 Flash였다”가 동시에 붙었다는 점이다. 링크가 Arena 도메인이라는 점까지는 영상이 “진짜 세션”으로 보지만, 세션이 진짜라고 해서 모델이 4 Pro라는 뜻은 아니다.
Argon 유출 주장 (미검증)
9월 14일 X 계정 Lentils80이 당시 ‘Gemini 4 Pro’의 코드네임으로 주장된 Argon(9월 30일 실제 모델명으로 공개)의 첫 출력이라고 주장하는 영상을 올렸다고 한다. 주장 스펙은 대략 컨텍스트 200만 · 출력 25만 6천이고, 고 thinking 설정에서 한 장면이 약 2.4분 걸렸다는 서술이다. (공식 출력 한도: 100만 토큰. 유출 스펙의 25만 6천과 다르며, 컨텍스트 200만은 공식 확인이 없다.)
작성 당시에는 독립 모델 카드·공식 API 목록·코드 안 지문으로 확인되지 않았다고 영상도 밝혔다. 이 영상이 실제 아르곤 출력이었는지는 공식 발표 뒤에도 확인되지 않았다. Arena 시연과 날짜가 가깝다는 이유로 커뮤니티가 점을 이었을 뿐, 동일 체크포인트 증명은 아니다.
이미 한 번 깨진 신호
8월 12일경 X에 돌던 “Gemini 4 Pro 벤치마크 시트”(예: 컨텍스트 150만 등)는 독립 분석이 다른 회사 공개 점수와 숫자가 같다고 보고 재라벨 조작으로 반박됐다고 영상은 말한다. 유출처럼 보이는 표가 금방 퍼질 수 있다는 배경으로만 적는다.
4 Pro 가설을 약하게 만드는 관찰
linux.do 테스터 중 일부가 Arena에서 Gemini 3.8 Flash high(같은 공개 모델의 높은 thinking)로 바꾸면 같은 품질이 재현된다고 보고했다. 영상은 이를 “숨은 플래그십”보다 “공개 Flash를 더 세게” 쪽으로 기울이는 가장 강한 단일 관찰로 둔다.
주장된 Argon 생성은 분 단위로 느린데, Arena 펠리컨·게임 출력은 초 단위로 빨랐다는 속도 불일치가 있다. (양쪽 모두 사용자 보고.)
생성물 안에 Argon/Gemini 4를 스스로 밝히는 문자열·토큰 지문은 보고되지 않았다.
점수형 Arena 리더보드에는 Gemini 4/Argon 항목이 없고 3.x만 보인다고 한다. 미공개 체크포인트는 보통 의미 없는 임시키로 가려지는데, 이미 출시된 Flash 이름으로 위장한다는 가정은 어색하다는 회의도 같은 스레드에 있다.
아직 모르는 것
9월 14일 유출 영상이 실제 아르곤 출력이었는지
Arena 출력이 지금도 같은 설정으로 재현되는지, Google이 빼 갔는지
수학·추론 등 창작 SVG 밖 벤치
다음이 3.9인지 4인지, 언제 공개인지 → 해소(10월 1일 업데이트): 제미나이 4(아르곤)로 공개됐다. 지금은 구글 내부와 페어윈드 프로그램 기관에만 제한 공개 중이고, 일반 공개 날짜는 미정이다.
영상 진행자 개인 판단(확정이 아님): 오늘 시점에서 가장 강한 데이터는 Flash high 재현 쪽이며, 아직 유출 플래그십이라고 단정하지 않는다. Arena 배틀에서 해당 출력이 사라지거나 리더보드에 별도 항목으로 뜨면 그때 다시 보면 된다고 말한다.
moonlang에서 읽을 때
스크린샷·유출 숫자보다 라벨·재현 조건·속도·공식 문장을 같이 적는다.
“Insane / Leaked” 제목은 클릭용이며, 본문은 확인 계층을 나눈다.
제품 도입·학원 수업과 직접 연결하지 않는다. 필요하면 별도 실험 글을 쓴다.
FAQ
Q. Arena SVG 시연이 Gemini 4 Pro라는 뜻인가요?
A. 아닙니다. 보고된 인터페이스 라벨은 Gemini 3.8 Flash였고, 출력이 인상적이라는 점과 모델이 4 Pro라는 점은 별개입니다. Flash high로 같은 품질이 재현됐다는 커뮤니티 보고가 4 Pro 가설을 약화합니다. 9월 30일 공식 발표에도 Arena 건은 언급되지 않아, 이 시연이 아르곤이었는지는 지금도 미확정입니다.
Q. Argon 유출 스펙은 확인됐나요?
A. 이 글·참고 영상 기준으로는 독립 모델 카드·공식 API 목록·코드 지문으로 확인되지 않았습니다. 과거 벤치마크 시트 위조 선례도 같이 적었습니다. 9월 30일 공식 발표로 ‘Argon’이라는 이름은 실제 모델명으로 확인됐지만, 공식 출력 한도는 100만 토큰으로 유출 스펙(25만 6천)과 다르고 컨텍스트 200만은 공식 확인이 없습니다.
Q. Argon은 Gemini 4 Pro의 코드네임인가요?
A. 아닙니다. 구글 공식 글에 나온 정식 모델명이 ‘제미나이 4 아르곤(Gemini 4 Argon)’입니다. 구글은 최상위 모델에 ‘Pro’ 대신 이 이름을 붙였습니다.
Q. Google이 확인한 범위는 어디까지인가요?
A. 이 글을 쓴 9월 23일에는 영상 인용 기준으로 Gemini 4의 사전학습 런이 시작됐다는 수준까지였습니다. 이후 구글은 한국 시간 10월 1일 오전 5시(미국 9월 30일) 제미나이 4 아르곤을 공식 발표하고 출력 한도(100만 토큰), 발표 가격, 벤치마크를 공개했습니다. 10월 1일(한국시간) 기준으로는 구글 내부와 페어윈드 프로그램 기관만 쓸 수 있고, API·일반 공개 날짜는 발표되지 않았습니다.
Q. 제품 도입·수업과 바로 연결해도 되나요?
A. 이 글은 확인 계층을 나눈 AI 소식 메모입니다. 제품 도입·학원 수업과 직접 연결하지 않습니다.
실험용 버튼을 바꿀 때마다 “지금 어떤 변형이 살아 있지?”를 사람 기억에 맡기면 금방 깨집니다. 그래서 moonlang-tools에는 dif.sh를 넣었습니다. 실험은 레포 안 Markdown이고, 빌드가 남기는 dif/context.json이 에이전트와 사람이 같이 읽는 요약장입니다.
아래는 그 흐름을 Archify 워크플로로 그린 것입니다. 인터랙티브 HTML에서는 Play를 누르면 스토리 애니메이션으로 전체 경로를 따라갈 수 있습니다.
한 줄 요약
실험 .md를 작성한다 (draft 또는 active).
dif validate로 스키마·충돌을 검사한다.
dif build(보통 prebuild)가 active만 컴파일한다.
결과물 두 갈래: 커밋되는 context.json, gitignore되는 generated/client.ts.
앱은 DifBoot → dif.init → dif()로 방문자를 변형에 배정한다.
함대 에이전트는 CTA를 손대기 전에context.json을 읽는다.
draft vs active
상태
빌드
방문자 화면
draft
건너뜀
안 바뀜
active
클라이언트에 포함
dif()로 갈라짐
예로 넣어 둔 home-hero-submit-cta는 처음에 draft였기 때문에, 머지 직후에도 홈 CTA 문구는 그대로였습니다. 스위치를 켠 뒤에야 겉모습이 갈라집니다.
context.json이 하는 일
context.json은 대시보드가 아닙니다. 활성 실험·변형·surface 학습을 한 파일로 요약한, 레포에 커밋되는 스냅샷입니다. 코딩 에이전트나 moonlang 봇이 세션을 시작할 때 이걸 보면, 모르는 사이에 실험 중인 카피를 덮어쓰지 않습니다.
학습 루프는 카드로도 적어 두었습니다. dif conclude가 surfaces/에 한 줄을 남기고, 다음 dif new가 그 로그를 읽어 draft를 채웁니다.
저장소는 가볍게
Archify HTML(인터랙티브)과 JSON 스펙은 설명용 산출물로 두고, 긴 WebM을 git에 넣지 않는 쪽을 권합니다. 영상은 미디어 호스팅·CDN에 올리고 글에서는 URL만 참조하면 클론과 PR이 무거워지지 않습니다. 이 글의 본 첨부도 HTML 다이어그램을 기준으로 합니다.
Aside 에이전트(영상 속 브라우저 에이전트)로 가입·등록을 돕고, Discord 경로로 더 빠른 접근을 시도했다고 한다.
초대 메일은 하룻밤 정도 뒤에 왔다고 본인 경험으로 말한다. 모든 사용자에게 같은 시간이 걸린다는 뜻이 아니다.
Aside가 API 키 생성을 도왔고, 문서를 Aside에 넣어 Jev 사용법을 학습시킨 뒤 스킬로 설치했다.
요점은 “채팅창에 Jev를 켠다”가 아니라, 코드·에이전트가 호출하는 판단 레이어라는 점이다.
패턴 2 — 맥락은 LLM·도구가 모으고, Jev는 긴급도·분기만 (Gmail)
Aside + Gmail 시연에서 메일 본문·스레드를 긁어 오는 쪽은 에이전트와 도구다. Jev에게는 회신 긴급도 Top 5 같은 순위·분기만 맡겼다. 크리에이터는 잊고 있던 급한 스레드가 위로 올라왔다고 보고한다.
게이트로 바꾸면 이렇게 나뉜다.
입력: 스레드 요약·발신자·마감·과거 맥락(도구가 수집)
Jev: 긴급도 점수·순위·“지금 답할지”
출력: 사람이 볼 짧은 리스트 (자동 발송이 아님)
패턴 3 — 모델 라우터 (수능 데모는 ‘예측 보고서’)
과거 수능 수학 문항을 넣고 “2027 예측” 보고서를 만드는 데모에서, Jev는 난이도·작업 종류를 판단하는 라우터로 쓰였다. 쉬운 문항 / 깊은 추론 / 서술(쓰기)을 서로 다른 생성 모델로 넘기는 식이다. 크리에이터는 라우터가 아직 미완이며 GitHub 공유를 검토한다고 했다.
중요. 보고서 자체도 실제 출제를 보장하지 않는다고 명시한다. moonlang도 “수능 적중”으로 읽히게 쓰지 않는다. 교육 상담이 필요하면 readmaster 안내를 보면 된다. 학원 CTA를 이 글에 늘리지 않는다.
투자 봇 예시 — 확률·현금 맥락; 따라 사지 말 것
Grok Bot / 투자 봇 시연에서는 LLM이 시장을 요약하고, Jev는 삼성·하이닉스에 대해 추가 매수 예/아니오와 확률만 판단했다. 현금·포지션 맥락이 결과에 영향을 줬다고 한다. 출력은 참고용으로 프레이밍됐다.
따라 사지 말 것. 이 절은 영상 속 아키텍처 메모일 뿐이다. 수익·수익률·추천을 주장하지 않는다. 투자 결정은 본인 책임이다.
moonlang에서 이미 쓰는 쪽
moonlang 쪽에서도 같은 결을 쓴다. 판단은 Jev(또는 동등한 게이트), 발행·실행은 코드다. claim-seal / content-route처럼 “이 문장을 올릴지 / 어느 파이프로 보낼지”를 구조화 질문으로 두고, 실제 게시·파일 쓰기는 스크립트가 맡는다. 비밀 경로·내부 키·운영 디테일은 이 글에 적지 않는다. API 튜토리얼 본문은 기존 가이드로 보낸다.
체크리스트
Jev를 채팅 모델이 아니라 Choice / Score / 예아니오 게이트로 설계했는가
맥락 수집(LLM·브라우저·메일)과 판단을 분리했는가
라우터면 “어디를 어떤 모델에”만 Jev에 맡기고 생성은 다른 쪽에 두는가
투자·시험 예측 출력을 조언·적중으로 포장하지 않았는가
waitlist·속도·비용 숫자를 자사 측정처럼 쓰지 않았는가
상세 셋업은 기존 moonlang 가이드와 공식 docs를 링크했는가
FAQ
Q. Jev를 채팅 모델처럼 켜면 되나요?
A. 이 글·영상 기준으로는 아닙니다. 스킬+API로 붙여 Choice/Score/예아니오 게이트로 쓰는 쪽이고, 긴 답 생성은 다른 모델·도구가 합니다.
Q. Gmail 시연은 자동 회신인가요?
A. 아닙니다. 메일 맥락 수집은 에이전트·도구가 하고, Jev는 긴급도·분기만 맡기며 출력은 사람이 볼 짧은 리스트로 프레이밍됩니다.
Q. 수능 예측 보고서가 출제를 보장하나요?
A. 보장하지 않습니다. 영상도 예측 보고서이지 출제 확정이 아니라고 하고, moonlang도 수능 적중으로 읽히게 쓰지 않습니다.
Q. 투자 봇 예시를 따라 사도 되나요?
A. 안 됩니다. 투자 조언이 아니며 따라 사지 말 것을 본문에 명시합니다. 수익·추천을 주장하지 않습니다.
TypeSafe AI의 Jev는 긴 문장을 생성하는 채팅 모델이 아니라, 프로그램 상태(state)와 타입 있는 질문을 받아 선택·점수·예/아니오 확률을 돌려주는 System One 모델이다. 이 글은 공개 실전 가이드 How to Use Jev: A practical guide to TypeSafe’s System One model의 구조를 바탕으로, moonlang에 이미 올린 소개 초안(WP 1704)과 공식·언론 교차 확인 범위 안에서 설정·세 프리미티브·다섯 패턴·실패 모드·언제 쓸지만 정리한다.
숫자 주의. 지연·가격 배수·벤치마크·“출시 48시간 데모” 비용은 대부분 TypeSafe 또는 데모 작성자 보고다. 가이드 본문도 자사 측정·미재현을 전제로 한다. 아래에서는 그 한계를 반복해 표시한다.
한 줄로
Jev는 state + 질문(Choice / Score / Noul)을 한 요청에 넣고, 수십~수백 밀리초 구간의 구조화 답을 받는 쪽에 가깝다. 텍스트·코드·요약을 “쓰게” 하는 도구가 아니다. 싸게 분류·라우팅·게이트한 뒤, 필요한 소수만 큰 LLM이나 사람에게 넘기는 캐스케이드가 실무 기본형이다.
가이드 기준 기본 모델은 jev-latest, HTTP는 POST https://api.typesafe.ai/v1/systemone. 패키지명·환경 변수명은 배포 시점에 바뀔 수 있으니 공식 문서와 콘솔을 한 번 더 확인한다.
회사·게이트웨이 쪽에 반복되는 입력 단가는 약 $0.042 / 1M input tokens, 출력 토큰 무료 주장이다. (Vercel AI Gateway 모델 카드·공식 소개와 동일 계열. 지속 가능 여부는 회사가 “장기 과제”로 남긴 바 있다.)
세 프리미티브
API의 질문 타입은 세 가지가 전부다. 우회할 제한이 아니라 설계 자체다. (공식 Primitives 문서와 동일 계열)
Choice — 집합에서 하나
Choice(
instructions="Which team should handle this",
criteria={
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions",
},
)
.choice, .probabilities, .confidence를 돌려준다. 가이드는 옵션을 최대 255개까지, 짧은 숏리스트보다 전체 목록을 넘기라고 한다. 맞는 게 없을 때를 위해 명시적 other를 넣으라고 권한다.
Score — 스펙트럼 위 위치
Score(
instructions="How frustrated the customer appears",
criteria=[
"Calm, just stating facts",
"Frustrated but civil",
"Very angry, strong language",
],
)
2~10단계의 순서 있는 수준. .score는 단계 사이 값(예: 1.035)이 될 수 있고, 단계 인덱스는 배열 순서(0부터)다.
Noul — 예/아니오를 확률로
Noul(instructions="The message conveys urgency or time-sensitivity")
.noul은 0~1. 가이드 기준으로는 별도 confidence 필드가 없고, 숫자 자체가 믿음의 표현이다.
한 요청에 묶기
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
client = TypeSafeClient()
response = client.system_one(
state={
"ticket": {
"subject": "Duplicate charge",
"messages": [
{"from": "customer",
"text": "I was charged twice for order A-104. Please refund the duplicate."},
],
},
"order": {"id": "A-104", "charges": [
{"amount_usd": 49, "status": "captured"},
{"amount_usd": 49, "status": "captured"},
]},
"refund_policy": "Duplicate charges are eligible for a refund.",
},
questions={
"department": Choice(
instructions="Which team should handle this",
criteria={"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions"}),
"frustration": Score(
instructions="How frustrated the customer appears",
criteria=["Calm, just stating facts",
"Frustrated but civil",
"Very angry, strong language"]),
"refund_requested": Noul(
instructions="The customer is explicitly asking for a refund"),
"policy_supports": Noul(
instructions="The stated refund policy covers this situation"),
},
)
TypeScript 가이드 예시도 같은 모양이다. state는 문자열·객체·문자열 배열. 이미지·오디오·비디오는 없고, 필요하면 먼저 전사·캡션한다. 가이드가 적는 컨텍스트 한도는 대략 state+질문 합 64k, state+가장 긴 질문 32k 토큰(문서·버전과 다를 수 있음).
훔칠 만한 다섯 패턴
1) Speculative fan-out
질문은 병렬이라, “싼 호출 먼저 → 필요할 때만 후속” 본능을 뒤집는다. 카테고리와 무관해 보이는 후속 질문도 같이 묻고, 코드가 어떤 답을 쓸지 고른다. 가이드가 인용하는 TypeSafe 쿡북 주장: 위키 장문 위에 13질문을 한 번에 묶으면, 하나씩 물을 때보다 약 12.2× 싸고 10.0× 빠르며 답은 동일 — 자사 쿡북 수치다.
2) Confidence-gated routing
가이드는 Jev가 RLCD(Reinforcement Learning for Calibrated Decisions)로 확률을 결과에 맞춘다고 설명한다. (공식 소개는 보정된 결정 학습을 채팅용 RLHF와 대비한다.) 그래서 전역 임계값 하나보다, 행동 비용별로 다른 막을 둔다. 잔액 조회는 낮게, 이체 승인은 높게. 분포가 평평하면 모델보다 criteria 설계 문제인 경우가 많다.
3) Composite scoring
“이 지원자 얼마나 좋은가” 한 방 대신, 파이썬 깊이·리더십·시스템 설계처럼 원자 Score를 나눈 뒤 가중 평균은 코드에서 한다. 가중치 변경이 재프롬프트가 아니라 코드 변경이 된다.
4) Cascade
AI로 제작한 Cascade 흐름 안내 이미지
Jev는 Opus/GPT급을 대체하지 않는다. 누가 큰 모델을 받을지를 값싸게 고른다. intent+complexity로 나눈 뒤, 순수 코드 / 전문 LLM / 사람 에스컬레이션으로 분기. 가이드의 백만 티켓 비용 예시($6,480 vs $30,400 등)는 TypeSafe per-case 가정에 따른 산술 — 재현·트래픽 전제 없이 그대로 믿으면 안 된다.
5) Retrieve, then judge
Jev는 넘겨준 state 밖의 세계를 모른다. 관련 없는 텍스트를 넣으면 정확도가 떨어진다고 jaggedness/문서 계열에서 경고한다. 검색·필터는 코드(또는 검색 API)로 하고, 논문·패시지마다 Noul/Score로 값싼 판정만 맡긴다. “잘 보정된 잘못된 자료에 대한 판단”이 나올 수 있다.
dif.sh에서 context.json이 빌드·런타임·에이전트에 어떻게 쓰이는지 Archify 워크플로로 풀어 쓴 글입니다.
출시 직후 데모 (참고만)
가이드는 2026-09-15 론칭 이후 약 48시간 산출물을 모았다. 작성자 자기 보고이며 프로덕션 사례가 아니다. 패턴만 요약한다.
대량 논문: 생성 모델로 요약 + Jev Choice로 토픽 분류(비용 비대칭을 보여 주는 파이프라인).
브라우저/컴퓨터 사용: 페이지·OCR을 기호 상태로 압축한 뒤 Jev가 행동·타깃을 고르고, 텍스트 입력 등만 작은 생성 모델.
트레이딩·드론 등: 제어 루프·안전은 코드, Jev는 낮은 Hz의 전술 판단만.
공통점: 루프·안전·산술은 평범한 코드에 두고, 코드로 쓰기 어려운 좁은 판단만 Jev에 둔다.
실패 모드 (가이드·jaggedness 계열)
글자 그대로 읽는다. 부정·범위·암시 조건이 곧이곧대로 적용된다. 틀린 답을 보고 “내가 진짜 뜻한 말”을 설명하게 되면, 그 설명이 빠진 instruction이다.
계산기가 아니다. 세기·날짜 순서·창 안 여부 등은 약하다. 항목마다 Noul을 돌리거나, 날짜는 열거 Choice + “미기재”, 조립은 코드.
Context rot. 질문에 필요 없는 state가 늘수록 성능이 떨어진다. 먼저 회수·필터.
적대적 state. 사용자 통제 텍스트가 스스로를 변호하면 답이 움직인다. 위협 모델은 애플리케이션 몫.
모순된 criteria. true가 “아니오”를 뜻하는 Noul 등은 약해진다.
생성 없음. 텍스트·코드·요약 불가. 후보는 정규식/생성 모델로 뽑고 Jev가 고른다.
메타 규칙: 코드가 정확히 계산할 수 있는 것을 모델에 묻지 말고, 한 질문에 여러 판단을 숨기지 말 것.
운영 메모 (가이드 시점)
레이트 리밋 예시: jev-1.13 기준 초당 토큰·분당 요청 상한과 429 + SDK 백오프 — 용량에 따라 예고 없이 변할 수 있다고 TypeSafe가 경고.
임계값을 튜닝했다면 jev-latest 대신 버전 핀. 응답의 model 필드를 로그.
과금은 입력 중심·출력 무료 주장이라 speculative fan-out이 싸다는 논리다.
정직한 스코어카드
가이드가 인용하는 TypeSafe 4-워크플로 평가에서 Jev가 일부 프론티어와 비슷한 합의 점수·훨씬 낮은 비용/지연을 주장한다. 다만 (1) 정답이 아니라 두 프론티어 평균 레이블과의 합의도, (2) TypeSafe가 설계·실행한 자사 평가, (3) “환각 0%”는 스키마 밖 값을 못 낸다는 뜻이지 틀린 valid 답을 안 낸다는 뜻이 아님, (4) 가격 지속성은 증명되지 않음. 우리 트래픽으로 다시 재야 한다.
언제 쓰고 / 언제 안 쓰나
맞음: 라우팅·트리아지, 모더레이션, 비싼 컨텍스트 전 관련성 필터, LLM 출력 가드레일, 초저가 대량 태깅, 요청 핸들러 안 서브세컨드 판정.
아님: 생성 전반, 산술·카운트·날짜 연산, 감사 추적용 서술 근거가 필요한 결정, 열린 답 공간, 일회성 복잡한 추론.
싸진 LLM이 아니라, 타입을 반환하고 신뢰도를 말하는 함수 호출에 가깝다. 문자열 출력을 견디려고 쌓아 둔 파서·재시도 상당수를 걷어낼 수 있는지가 핵심 질문이다.
교육·문해력 쪽에서 보면
수업용 채팅봇 대체가 아니다. 다만 “한 방에 총평” 대신 기준을 Choice/Score/Noul로 쪼개고, 임계값 아래에서 사람이 개입하는 구조는 읽기 교육의 근거·판단 분리와 닮아 있다. 학생 산출물 자동 채점도 동일하게 문항 단위 판정 + 사람 게이트가 더 안전하다.
가격·지연·한도는 PoC와 게이트웨이 카드로 재확인. early access·모델 버전 변경을 전제한다.
FAQ
Q. Jev는 ChatGPT처럼 긴 글을 써 주는 모델인가요?
A. 아닙니다. 이 글 기준으로 Jev는 채팅·생성 모델이 아니라, state와 타입 있는 질문(Choice / Score / Noul)을 받아 선택·점수·예/아니오 확률을 돌려주는 System One 모델입니다.
Q. 언제 쓰고, 언제 안 쓰나요?
A. 맞음: 라우팅·트리아지, 모더레이션, 비싼 컨텍스트 전 관련성 필터, LLM 출력 가드레일, 초저가 대량 태깅, 서브세컨드 판정. 아님: 생성 전반, 산술·카운트·날짜 연산, 서술 근거가 필요한 감사형 결정, 열린 답 공간.
Q. “환각 0%”처럼 읽히면 틀린 답을 안 낸다는 뜻인가요?
A. 아닙니다. 가이드·스코어카드가 말하는 범위는 스키마 밖 값을 못 낸다는 쪽에 가깝고, 틀린 valid 답을 안 낸다는 뜻이 아닙니다. TypeSafe 자사 평가·합의도 한계도 본문에 적혀 있습니다.
Q. 본문의 지연·가격·벤치마크 숫자를 그대로 믿어도 되나요?
A. 대부분 TypeSafe 또는 데모 작성자 보고입니다. 가이드도 자사 측정·미재현을 전제로 합니다. 우리 트래픽으로 다시 재야 한다고 본문에 적었습니다.
Q. 교육·채점에 바로 써도 되나요?
A. 수업용 채팅봇 대체가 아닙니다. 기준을 쪼개고 임계값 아래에서 사람이 개입하는 구조, 문항 단위 판정 + 사람 게이트가 더 안전하다고 본문에 적어 두었습니다.
짧은 영상을 “한 번 생성”하는 도구는 많다. 어려움은 그다음이다. 장면이 이어져야 하고, 캐릭터·배경이 흔들리면 안 되며, 비용·승인·실패 재시도가 파이프라인 안에 있어야 한다. video-auto(Chained Video Studio) 작업은 그 문제를 에이전트 오케스트레이션 + Electron 도구 + 외부 생성기로 나눠 붙잡은 실험이다.
이 글은 출시 후기가 아니라, 로컬 저장소에 남은 운영 계약과 검증된 산출물 기준으로 적은 회고다. 성과 수치나 미공개 API 키는 쓰지 않는다.
한 줄로 말하면
코딩 에이전트가 지능(오케스트레이터·디렉터·리뷰어)을 맡고, Electron/Node는 도구와 상태만 제공한다. 미디어는 Grok Imagine, Google Flow(Gemini Flow), Kling 등 외부 제공자가 만들고, 이 앱은 체인(순서·게이트·체크포인트) 을 소유한다.
Sora는 경로에서 제외했다. 제공자 표는 README 기준으로 grokWeb / grokApi / geminiFlow / klingApi / klingFal / klingWeb이다.
두 개의 제어면
CLAUDE.md가 못을 박아 둔 경계가 있다.
일 · 하네스 · 진입점
멀티 씬 필름 제작 · Claude production skills · shot-studio (plan → assets → render → post)
Electron 앱 코드 변경 · 앱 개발 하네스 · AGENTS.md → harness manifest
유료·비가역 단계(렌더 등)는 shot-studio 승인 게이트 뒤에 둔다. shot-plan 등을 직접 호출해 게이트를 우회하지 않는다.
병렬로 OpenMontage 흡수형 /video 경로도 있다. research·prompts·QA는 팬아웃하고, last-frame 릴레이만 순차로 두는 하이브리드다. 보드·체크포인트·코스트 스크립트(om:*)가 “지금 어느 스테이지인지”를 사람에게 보여 준다.
실제로 남긴 것
문서에 적힌 검증 산출물 예시는 다음과 같다.
최종 컷: runs/chain/black-file-twelve-faces/out/...-final-cut.mp4
프로덕션 레저: 同 프로젝트 ledger.json
편집 가능한 타이틀 AEP
두 번째 검증 레저: runs/chain/skyduel/ledger.json
즉 “데모 GIF 한 장”이 아니라, 런 디렉터리 + 레저 + 게이트가 남는 구조를 목표로 했다.
스토리 → 영상 E2E는 대략 이런 명령으로 묶인다.
npm run produce -- --story "..." --scenes 6 --yes --provider grokWeb
npm run produce:status -- --project <projectId>
npm run produce:stitch -- --project <projectId>
Three.js를 본선으로 쓰지 않은 이유
선택지 제목에 “Three.js 렌더”가 있었지만, video-auto 본 저장소의 중심은 생성형 비디오 체인 + ffmpeg 스티치 + 에이전트 게이트다. Three.js/WebGL 언급은 관련 학습 스펙 문서에 스치듯 나타날 뿐, 프로덕션 경로의 기본 렌더러로 고정되어 있지 않다. 회고에서 과장하지 않기 위해 본선은 체인 자동화로 적는다.
배운 점
파이프라인 없는 생성은 재현되지 않는다. Rule Zero — 모든 프로덕션은 manifest 스테이지를 탄다.
병렬과 순차를 섞어야 한다. 이미지·리서치는 병렬, 컷 연속성(릴레이)은 순차.
비용·연속성 게이트를 스킬 밖에 두면 반드시 우회된다. 진입점을 shot-studio 하나로 모은 이유다.
사람에게는 보드가 필요하다. dry-run·gate·ship 샘플이 온보딩을 대신한다.
캐릭터/월드 락 없이 씬을 늘리면 얼굴과 소품이 먼저 붕괴한다.
한계
브라우저 로그인 기반 제공자(grokWeb 등)는 세션·UI 변경에 취약하다.
외부 API 요금·쿼터는 레저로 추적해도 “창작 품질”을 보장하지 않는다.
Electron 앱 UX와 에이전트 스킬이 이중으로 있으면, 문서가 어긋날 때 드리프트가 생긴다. 변경 이력표를 CLAUDE/AGENTS에 남긴 이유다.
다음에 같은 일을 한다면
스토리 입력 → plan-only로 SCENE_TABLE 승인 → 그다음 gen.
provider는 한 프로젝트에 하나만 기본값으로 고정하고, 폴백은 명시적 게이트 뒤에.
최종물은 mp4만이 아니라 ledger + review 아티팩트를 함께 아카이브.
영상 자동화의 핵심은 모델 이름이 아니라, 에이전트가 같은 계약을 다시 실행할 수 있는가에 있었다.
코딩 에이전트에게 “예쁜 UI”를 맡기면 결과는 매번 조금씩 달라진다. 같은 브랜드인데도 버튼 색, 여백, 타이포가 세션마다 흔들린다. google-design-2026 작업에서 붙잡은 질문은 단순했다. 디자인을 에이전트가 다시 읽을 수 있는 하나의 문서로 고정할 수 있는가?
이 글은 Google의 DESIGN.md 형식과, 그 스펙을 Tailwind 테마·토큰으로 옮긴 로컬 워크플로를 정리한 회고다. 제품 출시 공지가 아니라, 실제로 무엇을 남기고 무엇을 버렸는지에 초점을 둔다.
DESIGN.md가 하려는 일
DESIGN.md는 시각 아이덴티티를 코딩 에이전트에게 설명하기 위한 포맷이다. 파일은 두 층으로 나뉜다.
공식 README의 요지는 명확하다. 토큰은 정확한 값을 주고, 산문은 적용 방식을 준다. 에이전트가 이 파일을 읽으면 “딥 잉크 헤드라인 + 따뜻한 석회 배경 + 단일 액센트 CTA”처럼 한 세트의 판단으로 UI를 맞출 수 있다.
철학 문서가 더 강하게 말하는 지점도 있다. 문장(의도)의 질이 숫자 정밀도보다 생성 품질을 좌우한다. “모던하고 신뢰감 있는 프리미엄” 같은 형용사 나열보다, “오래된 대학의 대학원 세미나 유인물”처럼 구체적 참조 한 줄이 여백·잉크·장식 금지를 함께 실어 나른다. 무엇을 빼는지가 캐릭터를 만든다.
로컬에서 한 일 (워크플로)
로컬 design.md 모노레포는 CLI·린터·예시(DESIGN.md + Tailwind config + DTCG JSON)를 한곳에 두었다. 실무에서 반복한 흐름은 대략 이렇다.
의도 먼저 쓰기 — Overview에 참조 세계와 Don’ts를 적는다.
토큰을 프론트매터에 고정 — primary/secondary/neutral, 타입 스케일, spacing.
npx @google/design.md lint — 깨진 참조, 구조, WCAG 대비 등을 JSON finding으로 받는다.
Tailwind로보내기 — 예시처럼 tailwind.config / design tokens JSON으로 옮겨 유틸리티가 같은 이름을 쓰게 한다.
diff로 회귀 감지 — 토큰·산문 변경이 “조용한 브랜드 붕괴”인지 확인한다.
중요한 운영 규칙 하나: 토큰을 “렌더 명령서”로 과대 해석하지 않는다. 스펙 쪽 관점도 토큰은 맥락이고, 산문이 디자인이다. Tailwind는 그 맥락을 빌드 타임에 붙잡는 다리일 뿐이다.
잘 된 점
세션 간 드리프트가 줄었다. 에이전트에게 “이 DESIGN.md를 따르라”고 하면, 색·타입의 중심이 문서에 남는다.
리뷰 언어가 생겼다. “느낌이 다르다” 대신 lint finding·token diff로 말할 수 있다.
예시 세트(예: Atmospheric Glass)가 온보딩을 짧게 만든다. DESIGN.md → Tailwind → DTCG JSON이 한 폴더에 있으면 설명 비용이 떨어진다.
깨진 점 / 주의
형용사만 채운 DESIGN.md는 무용하다. lint를 통과해도 산문이 비면 결과물은 다시 중간값 UI로 돌아간다.
컴포넌트 토큰을 Tailwind에 전부 밀어 넣으면 유틸리티 철학과 충돌한다. 예시 README도 컴포넌트 토큰은 JSON 쪽에 두고, Tailwind는 프리미티브에 집중하는 편을 택한다.
에이전트는 Don’ts를 잊기 쉽다. 산문에 금지를 쓰고, 체크리스트로 한 번 더 고정하는 편이 안전하다.
이 글은 Google 공식 제품 로드맵을 대변하지 않는다. 로컬에서 스펙을 읽고 적용해 본 작업 노트다.
다음에 남길 체크리스트
Overview에 구체적 참조 세계가 있는가.
색·타입·spacing 토큰 이름이 산문과 같은 어휘인가.
lint를 돌렸고, 대비·깨진 참조를 처리했는가.
Tailwind theme이 프론트매터와 이름 단위로 맞는가.
변경 시 diff로 회귀를 남겼는가.
디자인을 “예쁜 스크린샷”이 아니라 에이전트가 다시 실행할 수 있는 계약으로 두는 것. DESIGN.md → lint → Tailwind 연결은 그 계약을 짧고 검증 가능하게 만드는 한 가지 방법이었다.
인공지능(AI) 기술은 눈부신 속도로 발전하며 우리 삶의 다양한 영역에 혁신을 가져오고 있습니다. 특히 대규모 언어 모델(LLM)은 자연어 처리 능력을 넘어 코딩, 이미지 생성, 복잡한 추론 등 다재다능한 역량을 선보이며 개발자, 창작자, 그리고 교육자들에게 새로운 가능성을 열어주고 있습니다. 최근 발표된 Qwen3.6-27B 모델은 이러한 AI 발전의 최전선에 서 있으며, 비교적 작은 규모에서도 플래그십 수준의 코딩 성능을 달성했다는 점에서 주목받고 있습니다. 이 글에서는 Qwen3.6-27B의 등장 배경과 핵심적인 성능, 그리고 이것이 우리 실무와 교육 현장에 어떤 의미를 가지는지 심층적으로 탐구하고자 합니다.
Qwen3.6-27B: 작지만 강력한 AI의 등장
알리바바 클라우드에서 공개한 Qwen3.6-27B는 270억 개의 파라미터(매개변수)를 가진 ‘dense’ 아키텍처 기반의 멀티모달 모델입니다. 여기서 ‘dense’ 아키텍처는 모델의 모든 파라미터가 각 연산에 참여하는 구조를 의미하며, 이는 Mixture-of-Experts(MoE)와 같은 다른 아키텍처에 비해 구조가 단순하고 배포가 용이하다는 장점을 가집니다. Qwen3.6-27B는 이러한 단순함에도 불구하고, 이전 세대의 플래그십 오픈소스 모델이었던 Qwen3.5-397B(3970억 개 파라미터)를 코딩 관련 주요 벤치마크에서 능가하는 놀라운 성능을 보여주었습니다. 이는 단순히 모델의 크기만이 성능을 결정하는 것이 아니라, 효율적인 아키텍처 설계와 학습 데이터의 질이 얼마나 중요한지를 방증합니다.
이 모델의 가장 큰 특징 중 하나는 ‘thinking’ 모드와 ‘non-thinking’ 모드를 하나의 통합된 체크포인트에서 지원하며, 이미지 및 비디오 처리와 같은 멀티모달 능력까지 갖추고 있다는 점입니다. 이는 AI가 단순히 텍스트를 이해하고 생성하는 것을 넘어, 시각적 정보를 바탕으로 추론하고 복잡한 작업을 수행할 수 있음을 의미합니다. 특히 ‘agentic coding’ 성능, 즉 AI 에이전트가 코딩 작업을 자율적으로 수행하는 능력에서 Qwen3.6-27B는 SWE-bench Verified 77.2점, SWE-bench Pro 53.5점, Terminal-Bench 2.0 59.3점, SkillsBench 48.2점 등 인상적인 수치를 기록하며, 파라미터 수가 최대 15배 큰 모델들과도 경쟁할 수 있는 수준임을 입증했습니다.
왜 Qwen3.6-27B의 등장이 중요한가?
Qwen3.6-27B의 등장은 AI 모델 개발의 두 가지 중요한 흐름을 보여줍니다. 첫째, 모델의 크기가 절대적인 성능 지표가 아니라는 점입니다. 270억 개라는 비교적 작은 파라미터 수로도 최적화된 아키텍처와 학습 전략을 통해 플래그십급 성능을 달성할 수 있음을 보여줌으로써, 더 많은 개발자와 연구자들이 고성능 AI 모델에 접근하고 활용할 수 있는 길을 열었습니다. 이는 AI 기술의 민주화에 크게 기여할 것입니다. 둘째, AI의 멀티모달 능력과 코딩 능력이 융합되고 있다는 점입니다. AI가 시각적 정보를 이해하고 코드를 생성하는 능력을 동시에 갖추게 되면서, 더욱 복잡하고 실제적인 문제 해결이 가능해졌습니다. 예를 들어, 사용자가 그린 스케치를 보고 웹사이트 코드를 생성하거나, 비디오를 분석하여 관련 소프트웨어를 개발하는 등의 작업이 현실화될 수 있습니다.
또한, LLM이 생성한 보안 보고서를 기반으로 커널 코드에서 불필요한 부분이 제거되는 사례(Hacker News 기사 참조)는 AI가 단순히 코드를 생성하는 것을 넘어, 코드의 품질과 보안을 검증하고 개선하는 데에도 중요한 역할을 할 수 있음을 시사합니다. 이는 AI가 소프트웨어 개발 생태계 전반에 걸쳐 신뢰성과 효율성을 높이는 데 기여할 수 있음을 보여주는 강력한 증거입니다.
실무 적용: 개발자와 창작자를 위한 새로운 도구
Qwen3.6-27B는 개발자, 1인 창작자, 그리고 AI 도구를 실무에 적용하려는 모든 이들에게 강력한 새 도구를 제공합니다. 이 모델은 다음과 같은 방식으로 활용될 수 있습니다.
코드 생성 및 보조: 복잡한 알고리즘 구현, 반복적인 코드 작성, 특정 라이브러리 사용법 탐색 등 다양한 코딩 작업에서 Qwen3.6-27B는 개발자의 생산성을 크게 향상시킬 수 있습니다. 특히 ‘agentic coding’ 능력은 AI 에이전트가 개발 워크플로우에 통합되어 코드 작성, 테스트, 디버깅 과정을 지원하는 데 활용될 수 있습니다.
멀티모달 애플리케이션 개발: 이미지나 비디오를 입력받아 관련 코드를 생성하거나, 시각적 데이터를 분석하여 인사이트를 도출하는 애플리케이션 개발에 활용될 수 있습니다. 예를 들어, 제품 디자인 이미지를 기반으로 웹사이트 프론트엔드 코드를 생성하거나, 비디오 콘텐츠를 분석하여 요약 및 관련 기능 구현에 도움을 줄 수 있습니다.
AI 에이전트 구축: OpenClaw, Claude Code, Qwen Code와 같은 오픈소스 코딩 에이전트와의 통합을 통해, 사용자는 더욱 정교하고 자율적인 AI 개발 에이전트를 구축할 수 있습니다. 이러한 에이전트는 복잡한 개발 프로젝트를 관리하고, 개발자의 지시 없이도 일정 수준의 작업을 수행할 수 있습니다.
API 및 클라우드 서비스 연동: Alibaba Cloud Model Studio API, Hugging Face, ModelScope 등 다양한 경로를 통해 Qwen3.6-27B를 쉽게 접근하고 활용할 수 있습니다. 특히 OpenAI 호환 API와 Anthropic 호환 API 지원은 기존 개발 워크플로우에 통합하기 용이하게 만듭니다.
교육 현장의 시사점: AI 리터러시와 미래 교육
Qwen3.6-27B와 같은 고성능 AI 모델의 등장은 교육 현장에도 중요한 시사점을 던집니다. 미래 사회의 주역이 될 학생들에게 AI 리터러시는 필수적인 역량이 되었습니다. AI 모델이 코드를 이해하고 생성하는 능력을 갖추면서, 다음과 같은 교육적 활용이 가능해집니다.
코딩 교육의 혁신: 학생들이 코딩을 배우는 과정에서 AI 도구를 활용하여 즉각적인 피드백을 받고, 복잡한 개념을 시각적으로 이해하며, 실제 프로젝트를 더 쉽게 완성하도록 도울 수 있습니다. AI 튜터는 학생 개개인의 학습 속도와 스타일에 맞춰 맞춤형 학습 경험을 제공할 수 있습니다.
AI 윤리 및 책임 교육: AI가 생성한 코드의 잠재적 취약점이나 윤리적 문제에 대해 학생들이 비판적으로 사고하고 토론할 수 있는 기회를 제공해야 합니다. LLM이 보안 보고서를 생성하는 사례처럼, AI가 사회에 미치는 긍정적, 부정적 영향을 탐구하는 것은 미래 시민으로서 필수적인 교육입니다.
창의적 문제 해결 능력 함양: AI 도구를 단순히 사용하는 것을 넘어, AI와 협력하여 새로운 아이디어를 탐색하고 복잡한 문제를 해결하는 창의적 사고 능력을 길러주는 것이 중요합니다. 멀티모달 능력을 활용하여 텍스트, 이미지, 비디오 등 다양한 형태의 정보를 통합적으로 이해하고 활용하는 훈련도 필요합니다.
어린이 문해력 교육 측면에서도 AI는 흥미로운 가능성을 제시합니다. AI가 이야기를 만들거나, 그림을 묘사하거나, 동화책의 삽화를 생성하는 데 도움을 줄 수 있습니다. 이러한 과정을 통해 아이들은 언어와 창의성의 관계를 탐구하고, 자신만의 이야기를 만들어나가는 즐거움을 경험할 수 있습니다. 물론, AI의 도움을 받더라도 인간의 창의성과 비판적 사고 능력이 우선되어야 함을 강조하는 교육이 병행되어야 합니다.
결론: AI와 함께 만들어갈 미래
Qwen3.6-27B는 AI 기술이 얼마나 빠르고 효율적으로 발전하고 있는지를 보여주는 또 하나의 증거입니다. 270억 파라미터라는 비교적 작은 규모로도 플래그십급 코딩 성능을 달성하며, 멀티모달 능력까지 갖춘 이 모델은 AI 기반 개발 도구의 새로운 기준을 제시하고 있습니다. 이는 개발자들의 생산성을 극대화하고, 창작자들에게는 무한한 영감을 제공하며, 교육 현장에서는 미래 세대가 AI와 함께 성장할 수 있는 기반을 마련해 줄 것입니다. AI 기술의 발전 속도를 인지하고, 이를 우리 삶과 업무에 어떻게 긍정적으로 통합할 것인지 고민하는 것이 그 어느 때보다 중요해지고 있습니다.
