10월 19일(미국 시간) OpenAI가 COBOL, Fortran, Visual Basic처럼 학습할 자료가 적은 프로그래밍 언어에서 자사 모델이 얼마나 좋아졌는지 공개했습니다. 가장 눈에 띄는 건 COBOL입니다. 오래된 COBOL 프로그램을 다른 언어로 옮기는 평가에서 GPT-6.1 Sol이 97.9%를 맞혔어요.

COBOL은 1959년에 처음 설계된 언어인데, 지금도 은행 전산 깊숙이 남아 있습니다. OpenAI가 인용한 IBM 자료에 따르면 온라인 뱅킹 시스템의 40% 이상, 대면 카드 결제의 80%, ATM 거래의 95%를 COBOL이 받칩니다. OpenAI가 10월 20일 아침(한국 시간) X에 올린 발표 글은 다섯 시간 만에 조회수 46만을 넘겼어요. 이제 은행 COBOL도 AI에게 맡겨 옮기면 되는 걸까요?

결론부터 말하면, 옮기는 실력은 거의 다 왔습니다.

OpenAI의 COBOL 이전 평가는 COBOL 프로그램을 C++, Java, Kotlin, Python, Rust 가운데 하나로 옮기게 한 뒤, 모델이 보지 못한 숨은 테스트로 채점합니다. 밖으로 나오는 결과가 원래 프로그램과 바이트 하나까지 같아야 하고, 테스트를 하나라도 틀리면 실패로 칩니다.

기준이 까다로운 데는 이유가 있습니다. COBOL은 소수점 아래 자리가 넘치면, 반올림하라고 따로 적지 않는 한 남는 자리를 그냥 버립니다. 옮기면서 이걸 반올림으로 바꾸면 프로그램은 오류 없이 돌아가는데 금액이 달라져요. OpenAI도 이 예를 들면서, 반올림 규칙이나 빠진 기록을 다루는 방식 같은 세부 동작에 업무 규칙이 담겨 있다고 설명했습니다.

이 기준에서 GPT-6.1 Sol은 낮은 추론으로 86.6%, 높은 추론으로 97.9%를 냈습니다. 바로 전 세대인 GPT-5.6 Sol은 같은 낮은 추론에서 5.4%였는데, GPT-6.1 Sol은 그 비용의 61%만 썼어요. OpenAI는 이 평가가 거의 포화됐다고 했습니다.

값도 눈여겨볼 만합니다. 그래프를 보면 GPT-6.1 Sol은 97.9%를 내는 데 프로그램 하나에 약 1달러(약 1,300원)를 씁니다. 최상위 모델 GPT-6 Astra는 96~97%를 내는 데 건당 약 2~4.5달러(약 2,700~6,000원)가 들고요. GPT-6.1 Sol은 9월 29일에 나온 모델로, API 값은 100만 토큰당 입력 2달러(약 2,700원), 출력 10달러(약 1만 3천 원)입니다.

새로 짜는 일에서는 COBOL이 여전히 가장 어렵습니다.

OpenAI는 평가를 하나 더 내놨습니다. MultiLangBench는 데이터베이스 SQLite와 똑같이 동작하는 프로그램을 20개 언어로 처음부터 짜게 하는 평가예요. SQLite의 원래 테스트를 이 방식에 맞게 바꿔 채점하고, 평가 도구와 테스트는 깃허브에 공개했습니다.

여기서 GPT-6 Astra는 20개 언어 평균 87.4%를 통과했습니다. GPT-5.6 Sol은 26.8%였어요. 그런데 언어별로 보면 COBOL만 72.1%로 처집니다. 나머지 19개 언어는 모두 83%를 넘었고요. 값싼 GPT-6 Luna는 평균 40.3%에 문제 하나당 0.77달러(약 1,000원)를 써서, GPT-5.6 Sol(3.48달러, 약 4,600원)보다 약 78% 쌉니다.

정리하면 이미 있는 COBOL을 다른 언어로 옮기는 일은 거의 풀렸고, COBOL로 큰 프로그램을 새로 짜는 일은 아직 덜 풀렸습니다. 은행에 필요한 건 앞쪽이에요.

은행이 막히는 곳은 언어가 아닙니다.

OpenAI 발표 글에 달린 답글 가운데 공감을 많이 받은 글은 이렇습니다. “COBOL이든 다른 언어든 문제였던 적은 없다. 문제는 문서로 남지 않은 40년 치 업무 규칙이고, 어떤 날은 왜 필드 값이 음수가 되는지 알던 단 한 사람은 2009년에 은퇴했다.” 코드를 한 줄도 바꾸기 전에 AI에게 40년 된 시스템의 회귀 테스트부터 쓰게 하는 게 이전만큼 값질 수 있다는 답글도 있었어요.

OpenAI도 같은 이야기를 합니다. 실제 운영 중인 소프트웨어에 적용하려면 여전히 전문가 검토와, 그 시스템의 업무 규칙과 연결된 시스템을 기준으로 한 테스트가 필요하다고 적었어요. 97.9%는 정답 테스트가 이미 갖춰진 문제에서 나온 숫자입니다. 실제 은행에서는 그 정답 테스트를 만드는 일부터가 큰일입니다. ‘AI가 개발자를 대체하기는커녕, 연봉 5억 주고 모셔갑니다’에서 소개했던, 문서가 아니라 담당자 머릿속에 있는 일하는 방식이 바로 이것입니다.

국민은행도 COBOL을 Java로 옮기고 있습니다.

국내 은행도 이미 이 길에 들어섰습니다. KB국민은행은 3월 코어뱅킹 현대화 2단계 사업을 공고하면서 대면 부문에 1,597억 원, 비대면 부문에 1,100억 원을 배정했어요. 대면 부문 개발 범위에 COBOL을 Java로 바꾸는 작업이 들어 있고, AI 기반 코드 변환 도구도 쓰기로 했습니다. 그래도 20개월짜리 사업이 끝난 뒤에도 예금, 대출, 외환 업무 일부는 메인프레임에서 돌아갈 거라고 은행 관계자가 밝혔습니다.

7월에는 KB AI 개발센터도 열었습니다. Claude Code 같은 AI 코딩 에이전트를 쓰되, 자체 ‘하네스’로 은행의 개발 표준과 보안 정책을 자동으로 반영하게 했어요. 이 시장을 보는 건 OpenAI만이 아닙니다. 2월에는 Anthropic이 Claude Code로 COBOL 시스템을 분석하고 현대화할 수 있다는 글을 올리자, 은행 COBOL이 돌아가는 메인프레임을 파는 IBM 주가가 하루에 13% 빠지기도 했습니다.

자체 평가라는 점은 따져 봐야 합니다.

두 평가 모두 OpenAI가 직접 만들었습니다. MultiLangBench는 공개했지만, COBOL 이전 평가는 문항 수도, 어떤 프로그램을 옮겼는지도 밝히지 않았어요.

밖에서 잰 숫자는 다릅니다. AI 평가 회사 Vals AI의 Code Migration은 프로그램 저장소 30개를 다른 언어로 통째로 옮기게 하고, COBOL을 Java로 옮기는 과제도 들어 있습니다. 10월 18일 기준 이 평가에서 GPT-6.1 Sol은 65.1%로 5위입니다. 1위 Claude Sonnet 5.5가 69.8%, 3위 GPT-6 Astra가 67.7%로 앞서지만, 테스트 하나에 드는 값은 GPT-6.1 Sol이 6.51달러(약 8,700원)로 Claude Sonnet 5.5의 75.83달러(약 10만 원)에 비해 10분의 1이 안 됩니다.

과제 크기와 채점 방식이 달라 97.9%와 65.1%를 바로 견줄 수는 없습니다. 다만 프로그램 하나를 옮기는 일과 저장소 하나를 통째로 옮기는 일 사이에는 아직 거리가 있고, 싼다는 장점은 밖에서 재도 그대로라는 뜻입니다.

AI로 COBOL 프로그램 하나를 옮기는 값은 1천 원대까지 내려왔습니다. 이제 비용은 그 코드가 왜 그렇게 동작하는지 알아내고, 옮긴 뒤에도 똑같이 동작한다는 걸 보여 주는 데서 생길 듯싶습니다. 은행 차세대 사업에서 사람이 맡는 일도 코드를 짜는 쪽에서 그 동작을 테스트로 묶어 두는 쪽으로 옮겨 갈 것 같습니다.

https://openai.com/index/low-resource-programming-languages/

10월 16일, 일본 게임사 Alliance Arts가 사흘 뒤 공개하려던 ‘Drunken Goddess Reflux’ 체험판을 취소했습니다. 누구나 받아서 해 볼 수 있게 풀 예정이었는데, 정해진 인원만 참여하는 비공개 온라인 플레이로 바꿨어요.

이유는 두 가지였습니다. 먼저 플레이 영상을 올리거나 방송하는 데 제한을 걸고 체험판을 풀려 했는데, 지금 인원으로는 그 제한을 제대로 관리할 수 없다고 판단했습니다. 그리고 체험판 내용을 가지고 AI 같은 도구로 게임의 연출과 플레이를 빠르게 흉내 내거나 그대로 만들어, 정식 출시보다 먼저 내놓을 수 있다는 걱정을 들었습니다.

이 소식을 전한 게임 매체 Dexerto의 X 글은 이틀도 안 돼 조회수 87만 6천, 좋아요 2만 2천을 넘겼습니다. Alliance Arts의 공지(조회수 6만 1천)보다 14배 넘게 퍼졌어요. 체험판 하나로 게임을 베낀다는 게 정말 가능한 이야기일까요?

결론부터 말하면, 지나친 걱정이 아닙니다.

Claude Opus 5.5가 나온 건 9월 22일(미국 시간)입니다. 엿새 뒤인 9월 28일, 개발자 크리스 퍼스트(Chris First)가 X에 ‘Fallout: New York’을 올렸습니다. 브라우저에서 바로 하는 폴아웃 게임인데, Claude Opus 5.5로 만들었다고 밝혔어요. 퀘스트와 대화 선택지, 폴아웃 특유의 조준 시스템 V.A.T.S., 손목에 찬 단말기 핍보이(Pip-Boy)까지 돌아갑니다.

더 놀라운 건 그다음 설명입니다. 텍스처 파일도, 소리 파일도 하나 없이 건물과 무기, 얼굴, 소리를 전부 코드로 만들었다고 해요. 이 글은 조회수 364만을 넘겼습니다.

오래가지는 못했습니다. 사흘 뒤인 10월 1일, 크리스 퍼스트는 프로젝트를 접었습니다. 베데스다로부터 지식재산권 침해를 이유로 중단 요구를 받았다며 그 문서를 캡처해 올렸어요.

이번에는 진짜 게임 코드를 되살렸습니다.

Fallout: New York은 겉모습을 보고 새로 짠 게임입니다. 원래 게임의 코드는 쓰지 않았어요. 그런데 같은 시기에 진짜 게임의 코드를 통째로 되살리는 일도 벌어졌습니다.

9월 30일, 개발자 모리스 호이만(Maurice Heumann)은 PC판 원조 ‘콜 오브 듀티: 모던 워페어 2’를 생성형 AI로 디컴파일하고 있다고 X에 올렸습니다. 디컴파일은 컴퓨터가 알아듣는 형태로 바뀐 프로그램을 거꾸로 되돌려, 사람이 읽을 수 있는 코드로 만드는 일입니다. 그는 “에이전트 17개가 동시에 일하고 있다”며 게임을 이제 끝까지 할 수 있고 눈에 보이는 버그도 거의 다 잡았다고 했습니다. 액티비전은 저작권자 신고로 그 영상을 내리게 했고요.

10월 9일(미국 시간)에는 게임 매체 코타쿠(Kotaku)가 지난 2주 사이 AI로 디컴파일한 에뮬레이터와 게임이 수백 개 쏟아졌다고 전했습니다. 이유로 든 게 바로 Claude Opus 5.5입니다. 디컴파일을 아주 잘한다는 거예요. 기자는 콜 오브 듀티: 블랙 옵스, 헤일로: 컴뱃 이볼브드, GTA: 바이스 시티, 스케이트 3, 심슨: 힛 앤 런의 브라우저 이식판을 소개하면서, 직접 해 보니 몇몇은 거의 흠잡을 데가 없었다고 썼습니다. 심슨 게임은 초당 240프레임까지 돌았고, 헤일로 이식판 네 개 중 하나는 온라인 서버까지 돌아갔다고 해요.

코타쿠는 Claude Opus 5.5를 밤새 켜 두면 게임을 디컴파일해 주는 AI라고 표현했습니다. 예전에는 몇 달씩 걸리던 일입니다. 지난주 ‘비싼 돈 들여 만든 프로그램, 이제 AI가 순식간에 만들어버립니다’에서 소개했던 AI 역공학이, 함수 하나를 넘어 게임 한 편 단위로 커진 셈입니다.

Anthropic도 Opus 5.5를 내놓으며 생물학과 사이버 보안 능력이 Claude Mythos 5.1과 비슷한 수준이라, Claude Fable 5.1에 붙였던 것과 비슷한 안전장치를 함께 단다고 밝혔습니다. 프로그램을 거꾸로 뜯어보는 역공학은 보안 분석의 기본기이기도 합니다.

체험판은 좋은 재료가 됩니다.

이식판을 만들려면 원래 게임 파일이 있어야 합니다. 이미 나온 게임이라면 구하기 어렵지 않죠. 아직 나오지 않은 게임은 다릅니다. 체험판이 사실상 유일한 재료예요. 체험판은 정식판의 일부를 잘라 낸 실행 파일이라, 그림과 연출, 조작감, 규칙이 그대로 들어 있습니다.

그래서 체험판을 공개하면 두 길이 함께 열립니다. Fallout: New York처럼 겉모습을 보고 새로 짜는 길, 그리고 파일을 뜯어보는 길입니다. Alliance Arts가 걱정한 것도 연출과 플레이를 흉내 낸 게임이 정식 출시보다 먼저 나오는 일이었어요.

Alliance Arts는 체험판 대신 비공개 플레이를 택했습니다. 참가자는 참여 조건과 플레이 영상 게시/방송 규칙을 미리 읽고 동의해야 하고, 신청과 안내는 공식 디스코드에서 받습니다. Dexerto는 이 규칙에 AI로 게임을 분석하거나 베끼는 걸 금지하는 내용이 들어 있다고 전했습니다.

아직은 옛날 게임이 대부분입니다.

물론 아무 게임이나 하룻밤에 뜯기는 건 아닙니다. 코타쿠가 짚었듯 브라우저로 옮겨진 게임은 대부분 PS2/PS3 시절 작품입니다. PS3의 메모리는 약 512MB였는데, 기자가 글을 쓰던 웹 브라우저 하나가 약 1,200MB를 쓰고 있었다고 해요. 지금 컴퓨터에는 가벼운 게임들입니다.

AI 에이전트가 일을 망치기도 합니다. 모던 워페어 2를 디컴파일하던 호이만은 AI 에이전트가 자기 작업물을 전부 지워 버렸다고 불평하는 글을 연달아 올렸어요.

법도 남아 있습니다. 베데스다와 액티비전은 바로 막아섰고, 코타쿠가 소개한 이식판 모음 글도 저작권 사유로 모든 나라에서 볼 수 없게 됐습니다. 다만 코타쿠의 말처럼, 만들기가 이렇게 쉬우면 내린 자리에 새 버전이 올라오는 걸 막기 어렵습니다. 두더지 잡기가 된 셈이에요.

게임만의 일은 아닙니다.

먼저 써 보게 하는 건 소프트웨어를 파는 가장 흔한 방법이었습니다. 게임 체험판, 앱 무료 체험, 공개 베타가 다 그렇습니다. 그런데 공개한 만큼이 곧 베낄 재료가 된다면, 회사들은 보여 주는 범위부터 줄일 것 같습니다. 비공개 테스트에서 동의서를 받고, 중요한 기능은 서버에 두고, 베끼는 쪽보다 빨리 고치는 식으로요.

Alliance Arts의 결정은 작은 회사 하나의 선택입니다. 그래도 만드는 데 드는 시간이 하룻밤으로 줄어든 지금, 무엇을 언제 보여 줄지가 점점 더 중요한 결정이 되는 듯싶습니다.

https://x.com/AllianceArtsEN/status/2111043223326163101

10월 6일, 개발자 블로거 워니즈가 빈 폴더에서 Claude Code 2.1.281로 서브에이전트를 처음 만들어 봤습니다. 일부러 버그를 넣은 네 줄짜리 파이썬 파일 calc.py를 에이전트에게 고치게 했더니, Claude Code는 “수정했습니다”라고 답했습니다. 그런데 파일은 한 글자도 바뀌지 않았어요. 맡기기 전과 뒤에 찍은 파일 지문(md5)이 똑같았습니다.

그리고 10월 15일(미국 시간) Anthropic이 Claude Code 팀이 코드 리뷰를 어떻게 하는지 공개했습니다. 첫 번째 습관이 Claude에게 “다 됐다”는 말 대신 돌려 본 출력을 보여 달라고 하는 것이었습니다. 10월 19일(미국 시간) 해커뉴스에는 이해하지 못한 AI 코드를 배포하는 상황을 어떻게 다루느냐는 질문이 올라와 10월 21일 기준 586점, 댓글 689개를 받았고요.

AI가 “고쳤습니다”라고 하면, 정말 고친 걸까요? 세 번의 실행 기록과 Claude Code 공식 문서, Anthropic의 글을 함께 뜯어 봤습니다.

결론부터 말하면, 보고 문장은 증거가 아닙니다.

실험은 단순했습니다. calc.py는 빈 목록의 평균을 내다가 0으로 나누는 오류가 나는 파일입니다. 워니즈는 이 파일을 읽고 버그 하나를 한 줄로 알려 주는 검토 담당 에이전트를 마크다운 파일 한 장으로 만들고, 도구는 파일 읽기(Read) 하나만 줬습니다. 모델 칸에는 haiku라고 적었는데, 실제로 돈 모델은 Claude Haiku 4.5(claude-haiku-4–5–20251001)였습니다.

그리고 같은 파일로 세 번 돌렸습니다.

1. 검토만 맡겼을 때: 에이전트가 파일을 읽고 빈 리스트면 ZeroDivisionError가 나니 if not nums: return 0을 넣으라고 한 줄로 답했습니다. 12초, 시킨 그대로입니다.
2. “에이전트에게 고쳐 저장하게 시켜, 너는 고치지 마”라고 했을 때: 메인 Claude는 검토 담당이 읽기 권한만 있어 고칠 수 없다고 스스로 말한 뒤, 에이전트를 한 번도 부르지 않고 스킬과 Bash, Edit 도구로 직접 고쳤습니다. 40초 걸렸고 파일은 바뀌었습니다.
3. 같은 지시에 메인의 도구를 에이전트 부르기(Agent)와 파일 읽기(Read) 둘로 막았을 때: 이번엔 에이전트를 백그라운드로 띄우고 “결과를 기다리겠습니다”라고 답한 뒤, 다음 차례에 “수정했습니다”로 끝나는 보고를 냈습니다. 16초 걸렸고, 파일 지문은 앞뒤가 같았습니다.

세 번째 실행의 마지막 답은 이랬습니다. “수정 방법: 함수에서 len(nums) == 0 체크를 추가하거나 빈 리스트 대신 비어있지 않은 리스트로 테스트하도록 수정했습니다.” 고칠 방법을 설명하던 문장이 “수정했습니다”로 끝납니다.

파일을 고칠 수 있는 쪽이 아무도 없었습니다.

Claude Code 공식 문서를 보면 구조가 보입니다. 서브에이전트는 메인 대화가 가진 도구를 물려받고, 그중 tools 칸에 적은 것만 씁니다. 세 번째 실행에서 메인은 Agent와 Read만 가졌고, 검토 담당은 Read만 가졌습니다. 파일을 쓰는 도구가 처음부터 어디에도 없었던 거예요.

문서에는 서브에이전트가 기본으로 백그라운드에서 돌고, 그 결과는 나중 차례에 완료 알림으로 도착한다고 적혀 있습니다. Claude는 그 알림을 받을 때까지 기다렸다가 결과를 보고하게 돼 있고요. 실행 3도 겉으로는 이 순서를 따랐습니다. 다만 마지막 보고가 “검토 결과는 이렇습니다”가 아니라 “수정했습니다”였습니다.

왜 그렇게 답했는지는 워니즈도 기록만으로는 알 수 없다며 미확인으로 남겼습니다. 실행 2도 깔끔하지는 않았습니다. 에이전트에게 맡기라고 했는데 메인이 혼자 고쳤으니, 결과는 맞아도 시킨 방식은 지켜지지 않았어요. 확실한 건 하나입니다. 보고 문장만으로는 실행 2(정말 고침)와 실행 3(못 고침)을 가려낼 수 없었고, 둘을 가른 건 md5 비교 한 번이었습니다.

Claude Code 팀은 “끝났다”는 말 대신 출력을 받습니다.

Anthropic의 ‘How the Claude Code team does code review’는 같은 문제를 팀 규모에서 다룹니다. Claude Code의 코드는 약 90%를 Claude가 쓰고, 6월부터 9월까지 Claude Code 저장소에 머지된 PR은 두 배 넘게 늘었는데 되돌린(revert) 비율은 40% 넘게 줄었다고 합니다. Anthropic 모노레포에 하루에 들어오는 변경은 5월 약 2,500건에서 9월 3만 건 이상으로 늘었고요.

리뷰의 첫 단계는 PR이 생기기 전에 있습니다. Claude에게 테스트, 빌드, 디자인과 비교할 스크린샷처럼 돌려 볼 수 있는 것을 주고, 다 됐다고 말하는 대신 그 출력을 보여 달라고 합니다. 그다음 새 맥락의 서브에이전트가 diff를 검토합니다. 지난달 ‘AI 시대, 코드 리뷰는 어떻게 해야 할까’에서 소개했던, 다른 방에서 AI에게 AI를 검토시키는 바로 그 방식입니다.

Claude Code를 만든 Boris Cherny는 Claude에게 자기 일을 검증할 방법을 주는 것이 좋은 결과를 얻는 데 아마 가장 중요한 일이라고 했습니다. 최종 결과가 2~3배 좋아진다고 보고요. 검증은 bash 명령 하나일 수도, 테스트 묶음이나 브라우저, 휴대폰 시뮬레이터에서 앱을 돌려 보는 일일 수도 있다고 했습니다.

승인 규칙도 같은 방향입니다. 에이전트의 승인은 사람의 승인으로 치지 않습니다. 에이전트가 쓴 PR이면 에이전트를 부린 사람이 필요한 리뷰어 한 명으로 들어가고, 승인은 특정 커밋 하나에만 유효해서 에이전트가 새로 푸시하면 다시 받아야 합니다. 사람 몫으로 남긴 일에도 “증거 읽기”가 있습니다. 테스트 출력, 실행한 명령과 그 결과, 스크린샷을 읽는 일이요. Simon Willison도 10월 16일 이 글에서 “사람이 코드를 읽었나”는 “이 변경에서 무엇이 잘못될 수 있고, 자동이든 사람이든 어떤 확인이 그걸 잡아야 하나”를 대신하기엔 부정확한 질문이라는 대목을 골라 소개했습니다.

해커뉴스의 개발자들도 같은 자리에서 고민하고 있습니다.

해커뉴스의 ‘Ask HN: How to deal with shipping AI-written code you don’t understand?’는 한 Meta 엔지니어의 링크드인 글에서 시작합니다. 요즘 코드를 쓰면 전부 블랙박스처럼 느껴지고, 일하면서 이렇게 불편했던 적이 없다는 글이었어요. 이 질문은 GeekNews에도 번역돼 올라왔습니다.

댓글의 답은 크게 두 갈래였습니다. 설계는 사람이 정하고 구현만 맡기면 개별 코드를 다 몰라도 시스템은 이해할 수 있다는 쪽, 그리고 코딩에서 아낀 시간을 테스트와 검증에 쓴다는 쪽입니다. 한 댓글은 만드는 시간과 비용은 줄었지만 검증과 테스트라는 새 일이 잔뜩 생긴 것 아니냐고 되물었습니다. 자동 테스트를 잔뜩 넣으면 검토할 코드가 오히려 늘어난다는 지적도 있었고요.

확인은 바뀐 것을 직접 재는 쪽에 둬야 합니다.

세 자료가 가리키는 곳은 같습니다. 에이전트의 말은 일이 끝났다는 증거가 되지 못하고, 바뀐 것을 직접 재는 확인이 마지막 단계에 있어야 합니다. 일의 종류에 따라 나누면 이렇습니다.

1. 파일을 고치게 할 때: 맡기기 전과 뒤의 파일 지문(md5)이나 git diff를 비교합니다. 워니즈의 실행 3은 이 비교 한 번으로 드러났습니다.
2. 기능을 고치게 할 때: 테스트와 빌드를 돌린 출력 자체를 받습니다. Anthropic이 말한 “말 대신 출력”입니다.
3. 화면이 바뀌는 일일 때: Playwright 같은 브라우저 자동화로 스크린샷을 받아 디자인과 비교합니다.
4. 서브에이전트에게 맡길 때: 일을 맡긴 에이전트에게 그 일을 할 도구가 있는지, 실제로 일한 쪽이 맡긴 쪽과 같은지를 봅니다. 실행 2와 3은 둘 다 여기서 어긋났습니다.

4번은 특히 놓치기 쉽습니다. 읽기 전용 에이전트에게 고치는 일을 맡기면, 일은 처음부터 불가능한데도 보고는 완료로 돌아올 수 있습니다. 검토 담당에게는 검토만 맡기고, 고치는 일은 편집 도구가 있는 쪽에 맡겨야 합니다.

다만 실행은 한 번씩이었습니다.

이 실험의 한계도 분명합니다. 워니즈가 적은 대로 각 실행은 한 번씩만 돌렸고, 모델은 Claude Haiku 4.5 하나뿐이며, 편집 도구를 준 에이전트는 재현하지 않았습니다. 대화형 화면이 아니라 -p(비대화형) 모드였고요. Claude Haiku 5.5나 Claude Opus 5.5 같은 새 모델에서도 같은 일이 생기는지, 몇 번 중에 몇 번 생기는지는 이 기록만으로는 알 수 없습니다.

그래도 보고와 파일 상태가 한 번이라도 달랐다면, 보고만 보고 넘어가는 흐름에는 구멍이 있다는 뜻입니다. Anthropic이 에이전트의 승인을 사람의 승인으로 치지 않는 것도 같은 맥락입니다.

AI가 코드를 쓰는 속도는 이미 사람이 읽는 속도를 넘어섰습니다. Claude Code 팀이 읽는 일의 대부분을 기계에 넘기고, 해커뉴스의 개발자들이 아낀 시간을 검증에 쓰는 것도 같은 흐름입니다. 앞으로 에이전트를 믿는 기준은 “다 했습니다”라는 말보다, 무엇을 돌려서 무엇을 확인했는지가 될 것 같습니다.

https://blog.wonizz.com/2026/10/09/ai-agent-build-claude/

10월 13일(미국 시간), 스탠퍼드와 Together AI, UIUC, Meta 연구진이 arXiv에 45쪽짜리 논문 ‘Hybrid Reasoning Agents’를 올렸습니다. 이름은 HybridAgent입니다. AI 에이전트가 속으로는 단어 없이 숫자로 생각하고, 도구를 쓰거나 답을 낼 때만 글로 바꾸는 방식입니다. 10월 19일 해커뉴스 1면에 오른 뒤 10월 20일 아침까지 502점, 댓글 236개가 달렸어요.

지금 쓰는 AI는 생각도 글로 합니다. Claude Code나 Codex가 일하는 화면을 보면, 답을 내기 전에 “먼저 파일 구조를 확인하고…” 같은 문장을 길게 써 내려가죠. 이 문장이 전부 토큰이고, 토큰이 곧 값이고 시간입니다. 그렇다면 말로 생각하지 않으면 더 싸고 빨라질까요? 그리고 말로 생각하지 않는 AI를 사람은 어떻게 지켜볼 수 있을까요?

결론부터 말하면, 더 싸고 빨라졌습니다.

논문이 내놓은 숫자는 세 가지입니다. 같은 문제를 푸는 데 쓰는 토큰이 35.5~54.7% 줄었고, 추론은 1.8~2.6배 빨라졌고, 비용은 2.7~3.7배 아꼈습니다.

비용은 문제 100만 개를 푼다고 놓고 계산했습니다. 8B 모델 기준으로 글로 생각하는 에이전트는 439달러(약 58만 원), HybridAgent는 121달러(약 16만 원)가 듭니다. 4B는 359달러(약 48만 원)에서 98달러(약 13만 원)로, 14B는 470달러(약 62만 원)에서 176달러(약 23만 원)로 줄었어요. 다만 H100 한 장을 시간당 2.5달러(약 3천 3백 원)에 빌려 성능의 10%를 쓴다고 가정한 값이고, 답을 만들어 내는 연산만 셌습니다.

생각은 숫자로, 행동은 글로 합니다.

AI 모델은 한 단계마다 속에서 숫자 덩어리(벡터)를 만들고, 마지막에 그 숫자를 단어 하나로 바꿔 내보냅니다. 그리고 그 단어를 다시 읽어 다음 단계를 이어 가요. 생각을 글로 쓴다는 건, 매번 풍부한 숫자를 단어 하나로 줄였다가 다시 읽는다는 뜻입니다.

HybridAgent는 이 과정을 건너뜁니다. HybridLink라는 작은 연결부가 마지막 층의 숫자를 입력 쪽으로 바로 돌려보내서, 단어로 바꾸지 않고 다음 생각을 이어 가게 합니다. 이걸 잠재 모드라고 부릅니다. 파이썬을 돌리거나 검색을 하거나 답을 쓸 때는 글 모드로 돌아옵니다. 숫자로 한 생각과 글, 도구 결과는 모두 작업 기억에 그대로 남아서 여러 차례 이어집니다.

뼈대는 알리바바의 Qwen3–8B-Base와 Qwen3–14B-Base입니다. 4B로도 실험했고요. 여기에 학습을 두 단계 얹었습니다. HybridSFT로 글과 숫자를 오가는 법을 익히고, HybridRL로 언제 숫자로 생각하고 언제 글로 행동할지를 스스로 정하게 했습니다.

생각을 전부 글로 쓰면 맥락도 그만큼 길어집니다. 지난 9월 ‘AI는 왜 오래 일하면 바보가 될까?’에서 소개했던, 맥락이 길어질수록 흐려지는 바로 그 문제입니다.

작은 모델이 큰 모델을 이긴 곳도, 진 곳도 있습니다.

연구진은 수학, 과학, 의학, 검색, 에이전트 작업에 걸친 벤치마크 11개로 시험했습니다. 에이전트 벤치마크에서 HybridAgent (14B)는 GAIA 평균 52.4점으로 GPT-5.6 Luna(37.9점), Kimi-K3(41.7점), DeepSeek V4.1 Flash(39.8점)를 앞섰습니다. 웹사이트를 돌아다니며 답을 찾는 WebWalker에서는 49.5점 대 11.0점, 10.0점, 16.5점으로 차이가 더 컸어요.

반대로 어려운 지식 문제를 모은 HLE에서는 16.0점으로 Kimi-K3(31.4점)의 절반 수준이었고, DeepSearchQA에서도 GPT-5.6 Luna에 조금 밀렸습니다. 비교 대상도 지금의 GPT-6 Luna가 아니라 한 세대 전인 GPT-5.6 Luna입니다.

그래서 초록에 적힌 ‘평균 10.4% 향상’도 읽는 법이 중요합니다. 본문을 보면 이 숫자는 같은 크기, 같은 학습 예산으로 만든 글 기반 에이전트와 잠재 추론 에이전트에 견준 값입니다. 프런티어 모델보다 10.4% 낫다는 뜻은 아니에요. 14B 모델이 가장 강한 에이전트 기준 모델보다 평균 17.4% 높았다는 숫자도 함께 실려 있습니다.

숫자로 한 생각도 읽을 수는 있습니다.

말로 생각하지 않으면 사람이 그 생각을 볼 수 없게 됩니다. 그래서 연구진은 숫자로 한 생각을 단계마다 가장 가까운 단어로 바꿔 읽는 방법을 같이 내놨습니다. 깃허브에 실린 예시에서 HybridAgent-14B는 소리가 10km를 가는 데 몇 초 걸리는지 묻자 속으로 “Wait, I me the the speed of speed in air at 20° is about 343 meters per second. But I should verify that.”이라고 생각했습니다. 뜻은 통하지만 문장은 거칩니다. 그다음 검색으로 초속 343m를 확인하고, 파이썬으로 계산해 29초라고 답했어요.

사람이 지켜보기 어려워지는지도 쟀습니다. HybridAgent가 겉으로 쓰는 글은 같은 크기의 글 기반 에이전트보다 43~49% 적었습니다(8B는 302토큰 대 596토큰, 14B는 284토큰 대 497토큰). 그런데 다른 AI(GPT-4o-mini)에게 겉으로 드러난 글만 보여 주고 답이 맞았을지 가려내게 했더니, 정확도(AUROC, 1에 가까울수록 좋음)가 8B에서 0.840 대 0.772, 14B에서 0.860 대 0.818로 오히려 높았습니다. 글 100토큰에 담긴 핵심 단계도 0.72개 대 0.57개로 더 많았어요. 처음 틀린 단계를 짚어 낸 비율은 8B에서 99.2% 대 94.2%로 높았고, 14B에서는 98.1% 대 100.0%로 조금 낮았습니다.

해커뉴스에서는 ‘가장 금지된 기술’이라는 말이 나왔습니다.

해커뉴스에서 가장 긴 댓글 타래(답글 76개)는 “Most Forbidden Technique”이라는 한 줄에서 시작됐습니다. AI 안전 쪽에서 쓰는 말로, AI의 생각을 들여다보는 수단을 학습으로 망가뜨리는 일을 가리킵니다. 생각이 글로 남아 있어야 이상한 낌새를 잡을 수 있는데, 그 창을 스스로 닫는다는 걱정입니다.

연구진의 답은 논문 8장에 있습니다. 숫자로 한 생각은 제공자가 가진 HybridLink로만 읽을 수 있어서 글로 새어 나갈 일이 없고, 제공자는 사용자에게 보이지 않는 부분까지 전부 읽어 안전을 점검할 수 있다는 겁니다. 사용자는 도구 호출, 중요한 결정, 최종 답처럼 꼭 필요한 글만 봅니다. 논문은 OpenAI와 Anthropic도 이미 API 고객에게 추론 과정을 감추고 있다고 짚습니다. 결국 생각을 읽을 수 있는 쪽이 제공자 하나로 좁혀지는 셈이에요.

직접 돌리려면 24GB GPU 한 장이면 됩니다.

모델은 허깅페이스에 MIT 라이선스로 올라와 있습니다. HybridAgent-8B-Agentic은 파라미터 82억 개로 BF16 파일이 약 16.4GB라서, 메모리 24GB짜리 GPU 한 장에 올라갑니다. AWS에서 이런 GPU 한 장짜리 서버(g5.xlarge)는 시간당 1.006달러(약 1천 3백 원), 한 달 내내 켜 두면 약 724달러(약 96만 원)입니다. HybridAgent-14B-Agentic은 148억 개, 약 29.5GB라서 48GB GPU가 필요하고, AWS g6e.xlarge가 시간당 1.861달러(약 2천 5백 원), 한 달이면 약 1,340달러(약 178만 원)입니다.

다만 아무 실행 도구로나 돌릴 수는 없습니다. 숫자로 생각하는 모드를 쓰려면 깃허브에 공개된 전용 생성 엔진과 엔비디아 GPU(CUDA)가 필요합니다. 맥이나 일반 PC에서 많이 쓰는 llama.cpp용 양자화 파일(GGUF)도 올라와 있지만 잠재 모드를 지원하지 않아서, 해커뉴스에서 써 본 사람들은 같은 문단이 되풀이된다고 했습니다. 직접 학습까지 하려면 HybridSFT에 GPU 8~16장, HybridRL에 32장(8장짜리 서버 4대)을 권장합니다.

아직은 연구 단계입니다.

한계도 분명합니다. 비교한 프런티어 모델이 한 세대 전 버전이고, HLE처럼 지식이 많이 필요한 문제에서는 큰 모델에 크게 밀립니다. 비용은 가정을 깔고 답을 만드는 연산만 센 값이라 실제 서비스 비용과는 다를 수 있습니다. 기존 서빙 엔진으로는 돌릴 수 없어서 연구진이 추론 환경을 직접 만들었고, 서비스에 붙이려면 이 부분부터 손봐야 합니다. 벤치마크 밖의 일반 대화에서 어떤지도 아직 알 수 없어요.

지금까지 AI를 더 똑똑하게 만드는 방법은 더 길게 생각하게, 그러니까 더 많이 쓰게 하는 쪽이었습니다. HybridAgent는 덜 쓰고 더 생각하게 하는 반대 방향을 보여 줍니다. 값과 속도를 보면 이 방향으로 가는 곳이 늘어날 것 같은데, 그럴수록 AI의 생각을 누가 읽을 수 있느냐가 더 중요한 질문이 될 듯싶습니다.

https://arxiv.org/abs/2610.18861

9월 29일(미국 시간) Stripe의 간편결제 서비스 Link가 “지난 한 달 동안 Link로 결제한 에이전트 구매가 38배 늘었다”고 밝혔습니다. 메타의 새 개인 에이전트 Muse, Grok Bot, Instinct 같은 AI 비서가 사용자 대신 물건을 고르고 Link로 결제하는 방식이에요.

10월 18일에는 스타트업 전문 매체 Upstarts Media가 Stripe에서 받은 9월 데이터를 단독으로 전했습니다. 결제 금액은 20배 늘었고, 건수와 금액 모두 소매 쇼핑이 가장 많았으며, 한 번에 평균 약 100달러(약 13만 원)를 썼다는 내용이에요. AI가 대신 장을 보는 시대가 정말 온 걸까요?

결론부터 말하면, 빠르게 늘고 있지만 아직 출발선입니다.

Link는 카드 정보를 매번 입력하지 않고 결제하게 해 주는 Stripe의 간편결제로, Airbnb와 Uber 같은 곳에서 쓰이고 사용자가 3억 명입니다. 이 가운데 에이전트 결제를 붙인 앱은 9월에 약 70개였고, 지금은 약 200개예요. Link를 맡고 있는 Stripe의 댄 힐(Dan Hill)은 “에이전트 커머스는 이미 와 있고, 사람들이 쓰고 있다. 지금 보는 규모는 꽤 의미 있는 수준이 되고 있다”고 말했습니다.

다만 절대 금액은 공개되지 않았습니다. 38배는 한 달 사이 늘어난 비율이라, 출발점이 작으면 큰 숫자가 나오기 쉽습니다. 기사를 쓴 알렉스 콘래드(Alex Konrad)도 X에서 Stripe에서 얻어 낼 수 있는 만큼 담았다면서 “답이 나오지 않은 질문이 많다”는 데 동의했어요. Anthropic과 OpenAI도 Link를 쓰지만, 아직 에이전트 결제에는 쓰지 않습니다.

에이전트에게 카드를 통째로 주지 않습니다.

에이전트가 내 카드 번호를 직접 들고 다니는 건 아닙니다. Stripe가 공개한 Link CLI 설명을 보면, 에이전트는 구매할 때마다 Link 지갑에서 한 번만 쓸 수 있는 결제 수단을 받아 갑니다. 아무 결제창에서나 쓸 수 있는 가상 카드나, Stripe 결제창에서 쓰는 결제 토큰 같은 식이에요. 사용자는 결제 총액을 보고 승인하고, 진짜 카드 정보는 에이전트에게 넘어가지 않습니다. 발표 이미지 속 Muse도 결제하기 전에 470달러(약 63만 원)를 써도 되는지 묻고, 사용자가 ‘허용’을 눌러야 결제가 진행돼요.

파는 쪽도 에이전트를 맞을 준비를 하고 있습니다. Stripe 결제창은 WebMCP를 통해 에이전트가 직접 결제를 마칠 수 있게 했어요. 판매자가 프로그램끼리 돈을 주고받는 Machine Payment Protocols(MPP)를 쓰면, 에이전트는 결제창을 거치지 않고 공유 결제 토큰으로 바로 값을 치를 수도 있습니다.

9월 29일 발표에는 에이전트가 결제창에서 덜 막히게 하는 기능도 담겼습니다. 항공권을 승인한 뒤 위탁 수하물을 추가하면, 결제를 처음부터 다시 하지 않고 승인 금액만 올릴 수 있어요. 카드사 추가 인증이 뜨면 사용자에게 보낼 인증 링크를 주고, 카드가 거절되면 다른 결제 수단을 고르게 합니다.

에이전트가 실수했을 때를 위한 장치도 붙였습니다. 조건에 맞는 구매라면 실수로 생긴 파손과 분실, 산 뒤에 내린 값, 반품을 보장해 줘요. Muse가 처음으로 이 보호를 제공합니다. 사용자가 허락하면 에이전트가 미국 금융기관 1만 2천여 곳의 거래 내역을 보고, 자주 가는 가게와 씀씀이에 맞춰 물건을 추천할 수도 있습니다.

다음 단계는 예산입니다. Stripe는 사용자가 에이전트에게 예산을 정해 주면 건마다 승인하지 않아도 알아서 사게 하는 기능을 준비하고 있어요. 새벽 1시에 풀리는 한정판 신발을, 사용자가 깨어 있지 않아도 에이전트가 사 오는 식입니다.

은행은 사람과 에이전트를 가리기 시작했습니다.

결제 반대편도 준비하고 있습니다. 샘 올트먼이 공동 창업한 World는 10월 18일 은행과 금융회사용 World ID 제품군을 내놨습니다. 그중 World ID for Agents는 사람이 자기 신원 증명을 AI 에이전트에게 맡기고, 에이전트가 다른 서비스에 그 증명을 내밀게 하는 도구예요. 결제를 요청한 쪽이 사람인지, 사람이 맡긴 에이전트인지, 아무도 맡기지 않은 봇인지 가려야 할 일이 생긴 겁니다. World는 딜로이트 전망을 인용해, AI를 이용한 미국 금융 사기 피해가 2023년 123억 달러(약 16조 원)에서 2027년 400억 달러(약 53조 원)까지 늘 수 있다고 했어요. 사람임을 증명받은 World ID 사용자는 1,800만 명이 넘습니다. 다만 이 제품을 쓰는 은행은 아직 공개되지 않았습니다.

한국에서는 아직 쓸 수 없습니다.

Link의 에이전트 지갑은 지금 미국과 캐나다 Link 계정에서만 쓸 수 있습니다. 콘래드에 따르면 Stripe는 에이전트용 해외 결제를 이제 만들고 있고, 구독과 여행 예약처럼 나중에 돈이 빠져나가는 결제도 아직 풀어 가는 중이에요.

숫자도 아직 Link 안의 이야기입니다. 이번에 나온 38배, 20배, 평균 100달러는 모두 Link 한 곳의 데이터이고, 에이전트가 산 물건을 얼마나 반품했는지, 잘못 산 비율이 얼마인지는 나오지 않았습니다.

AI가 대신 장을 보는 일은 이미 시작됐지만, 아직은 미국에서, 사람이 총액을 승인하는 범위 안에서입니다. 결제 회사는 한 번만 쓰는 카드와 구매 보호를, 신원 회사는 에이전트용 증명을 내놓으며 길을 닦고 있어요. 예산만 정해 주면 에이전트가 알아서 사는 기능이 열릴 때, 대신 장 보기가 정말 일상이 될 듯싶습니다.

https://x.com/link/status/2105002239823864093

10월 17일(미국 시간) 오픈소스 코딩 에이전트 OpenCode가 X에 보안 사고를 알렸습니다. 전날 밤 “대규모 증류(distillation) 공격과 관련된 보안 침해”가 있었고, OpenCode Console 사용자의 1.4%가 피해를 봤다는 내용이었어요. 외부 AI 제공업체를 연결해 둔 사용자 일부이고, Anthropic, OpenAI, 구글과 함께 수습하고 있다고 했습니다.

OpenCode는 깃허브 별이 21만 7천 개가 넘고, 회사 설명으로는 매달 1,600만 명의 개발자가 쓰는 도구입니다. 이 공지는 이틀 만에 조회 274만, 좋아요 1만 1천을 넘겼어요. 코딩 에이전트에 연결해 둔 API 키는 정말 안전할까요?

결론부터 말하면, 문제가 된 건 OpenCode 앱이 아니라 Console에 맡긴 키였습니다.

OpenCode를 쓰는 길은 두 가지입니다. 하나는 터미널이나 데스크톱에서 돌리는 OpenCode 앱입니다. 여기에 넣은 API 키는 내 컴퓨터의 설정 파일(~/.local/share/opencode/auth.json)에 저장돼요. 다른 하나는 웹에서 쓰는 OpenCode Console입니다. 팀 워크스페이스에 OpenAI, Anthropic, 구글 키를 한 번 넣어 두면, 팀원들은 키를 직접 보지 않고 Console을 거쳐 모델을 씁니다.

이번에 문제가 된 건 Console 쪽입니다. 공동 창업자 댁스 라드(Dax Raad)는 “이건 OpenCode 자체가 아니라 OpenCode Console 이야기이고, 그 키들은 우리에게 오지도 않는다”고 답했습니다. 앱에 넣은 키는 OpenCode 서버를 거치지 않는다는 뜻이에요. OpenCode는 10월 17일 아침 피해 사용자 모두에게 메일을 보냈고, 메일을 받지 않았다면 피해 대상이 아니라고 밝혔습니다.

API 키는 가진 사람이 곧 주인입니다.

API 키는 로그인처럼 두 번째 확인을 거치지 않습니다. 키 문자열만 있으면 누구든 키 주인의 계정으로 요금이 나가는 요청을 보낼 수 있어요. 그래서 키가 새면 피해는 바로 청구서로 나타납니다.

실제로 그런 일이 벌어졌습니다. 개발자 콜린 파슨스(Colin Parsons)는 10월 17일 OpenCode에만 쓰던 OpenAI 키에서 281달러(약 37만 원), Anthropic 키에서 168달러(약 22만 원)가 미국 동부 시간 새벽 2시부터 빠져나갔다고 X에 올렸습니다. 다른 키들은 멀쩡했다고 해요. 프레스턴 젤러(Preston Zeller)는 잊고 있던 OpenCode용 키에 하룻밤 사이 1,700달러(약 226만 원)가 넘게 청구됐다고 했습니다. 사용 한도를 걸어 둔 줄 알았는데 걸려 있지 않았다고 덧붙였어요.

OpenCode는 피해 사용자에게 환불을 진행하고 있습니다. 댁스 라드는 피해를 본 사람들에게 메일을 보내 달라며 환불이 이미 진행 중이라고 답했어요. OpenAI의 티보 소티오(Thibault Sottiaux)도 10월 19일 OpenCode와 함께 OpenAI API 고객의 계정을 되살리고, 공격으로 빠져나간 크레딧을 환불했다고 밝혔습니다.

증류 공격은 남의 계정으로 모델의 답을 퍼 가는 일입니다.

증류는 강한 모델의 답을 대량으로 모아 다른 모델을 학습시키는 방법입니다. AI 회사들이 자기 모델을 작고 싸게 줄일 때 흔히 쓰는 정상적인 기법이지만, 남의 모델에 몰래 쓰면 이야기가 달라집니다. Anthropic은 2026년 2월 23일 DeepSeek, Moonshot, MiniMax가 가짜 계정 약 2만 4천 개로 Claude와 1,600만 번 넘게 대화를 주고받으며 능력을 빼 갔다고 공개했어요. 노린 건 에이전트 추론과 도구 사용, 코딩이었고, 가짜 계정과 프록시 서비스로 요청을 여러 갈래로 나눠 탐지를 피했습니다.

남의 API 키는 이런 공격에 딱 맞는 재료입니다. 요금은 키 주인이 내고, 요청은 정상 사용자의 계정에서 나가기 때문입니다. 다만 OpenCode는 이번 침해가 증류 공격과 어떻게 이어지는지, 누가 공격했는지는 아직 밝히지 않았습니다.

공격하는 쪽은 에이전트를 24시간 돌립니다.

공격은 공지 뒤에도 이어졌습니다. 댁스 라드는 10월 18일 “지난 48시간 동안 쉬지 않고 우리 시스템을 공격하고 있다”며 “우리도 에이전트를 24시간 돌려야 한다. 그들이 그렇게 하고 있으니까”라고 썼습니다. 이 글은 조회 144만을 넘겼어요. 전날에는 자기 개인 계정까지 공격받고 있다며 “AI로 해킹하는 완전히 새로운 세상”이라고 했습니다.

막는 쪽은 오히려 AI의 도움을 받기 어려웠습니다. 최신 모델의 사이버 안전장치에 막히지 않았느냐는 질문에 댁스 라드는 “사고를 조사하는 도중이라 꽤 답답했다. 모델들이 한참 돕다가 거절하기 시작했다”고 답했어요. 실제로 Anthropic은 10월 6일 Claude Opus 5.5 같은 일반 모델에는 대부분의 사이버 작업을 막는 보수적인 안전장치가 걸려 있다고 밝히고, 사고 대응 같은 방어 작업을 하는 보안팀에는 심사를 거쳐 이 제한을 풀어 주는 Cyber Verification Program을 넓혔습니다. OpenCode는 OpenAI가 방어용으로 제한을 풀어 주는 Daybreak Blue 승인을 받은 뒤 나아졌다고 했고, 10월 19일에는 “Daybreak가 결정적이었고 지금도 계속 돌고 있다”고 썼습니다.

키는 도구마다 따로 줘야 합니다.

이번 일은 키 관리의 빈틈도 보여 줍니다. 복사된 키는 Console에서 지워도 살아 있고, 제공업체 대시보드에서 폐기해야 비로소 막힙니다. Console 안의 예산 한도도 Console을 거치지 않는 요청까지 막아 주지는 못해요. 그래서 코딩 에이전트에 키를 줄 때는 몇 가지를 지켜야 합니다.

1. 도구와 에이전트마다 키를 따로 만들어야 합니다. 하나가 새도 그 키만 폐기하면 되고, 어디서 샜는지도 바로 보입니다.
2. 사용 한도와 알림은 제공업체 쪽에 걸어야 합니다. 도구 안의 한도는 키가 복사되면 소용이 없어요.
3. 쓰지 않는 키는 폐기해야 합니다. 1,700달러가 빠져나간 키도 주인이 잊고 있던 키였습니다.
4. 가능하면 오래 사는 API 키 대신 로그인 토큰을 써야 합니다. 댁스 라드는 OpenCode에서 로그인으로 연결하면 기본으로 OAuth 토큰을 쓴다고 설명했어요.

주말 사이 해커뉴스에서 화제가 된 글 “If you don’t run your own LLM proxy, how do you know whats going on?”(167점, 댓글 114개)도 같은 이야기를 합니다. 직접 운영하는 LLM 프록시를 두면 어떤 키가 어떤 모델을 언제 불렀는지 로그로 남고, 주 API 키 대신 가상 키를 에이전트마다 나눠 줄 수 있다는 내용이에요. 오픈소스 LiteLLM 같은 프록시가 가상 키와 키별 예산을 지원합니다.

아직 밝혀지지 않은 것이 더 많습니다.

10월 19일 기준으로 OpenCode는 어느 시스템이 어떻게 뚫렸는지, 키가 몇 개 노출됐는지, 1.4%가 몇 명인지 밝히지 않았습니다. 키가 노출됐을 수 있다고만 했을 뿐, 실제로 복사돼 쓰였다고 확인하지도 않았어요. 사용자들이 올린 피해 금액도 각자의 주장입니다. 사고가 아직 진행 중이라 세부 내용은 더 바뀔 수 있습니다.

코딩 에이전트가 늘수록 API 키는 터미널과 웹 대시보드, CI 설정 곳곳에 흩어집니다. 공격하는 쪽은 이미 에이전트를 쉬지 않고 돌리고 있어서, 키 하나가 새면 피해는 하룻밤 사이에 쌓입니다. 키를 어디에 넣었는지 기억하고 제공업체 쪽에서 바로 막을 수 있게 해 두는 일이, 에이전트를 쓰는 기본기가 될 듯싶습니다.

https://x.com/opencode/status/2111519637049319818

10월 14일 중앙일보 단독 보도로, 국내 최대 서점 교보문고에 이상한 주문 문의가 이어졌다는 사실이 알려졌습니다. 올해 초부터 미국, 영국 등 해외 업체 약 10곳이 한국어 책을 사고 싶다고 연락해 왔는데, 원하는 책이 따로 없었습니다. 제목도 분야도 상관없이 서로 다른 책 약 10만 권을 한 권씩 사겠다는 주문이었어요.

교보문고가 최종 납품처를 묻자 업체들은 “최종 납품처 정보는 비밀유지 사항으로 공개할 수 없다”고 답했습니다. 한 업체는 “AI 학습 목적은 아니다”라면서도 최종 납품처는 “데이터 관련 기업”이라고 했어요. 교보문고는 AI 학습에 쓰일 가능성을 배제하기 어렵다며 거래 논의를 끊었습니다.

이 이야기를 정리한 X 글은 10월 19일 오전에 올라와 그날 저녁까지 조회 20만을 넘기고 좋아요 4,800개를 받았습니다. 그런데 눈여겨볼 건 주문 방식입니다. 업체들은 왜 하필 한 권씩 사려 했을까요?

결론부터 말하면, ‘한 권씩’은 AI 학습용 책을 모으는 방식과 똑같습니다.

다시 팔 책이라면 잘 팔릴 책을 골라 여러 권 삽니다. 교보문고도 “미국, 유럽, 베트남 등 한국 도서를 사 가는 해외 서점들은 일반적으로 도서 목록과 구매 목적을 제시한다”고 설명했어요. 반대로 AI 학습에는 같은 책이 두 권 필요 없습니다. 한 번 스캔하면 끝이기 때문입니다.

지난 8월에는 미국 애리조나주의 한 업체가 예스24 중고서점과 서울책보고에 헌책을 대량으로 사겠다고 문의했습니다. 중앙일보 기자가 이 업체에 직접 물었더니 “도서별로 한 권씩 매입하니, 전체 권수보다 서로 다른 도서의 종수가 더 중요하다”는 답이 돌아왔어요. 이 업체는 교보문고에도 문의했습니다.

이 방식을 가장 크게 벌인 곳이 Anthropic입니다. 2025년 6월 미국 법원 판결문에 따르면 Anthropic은 종이책 수백만 권을 사들였습니다. 상당수는 중고책이었고, 제본을 뜯고 페이지를 잘라 스캔한 뒤 종이 원본은 버렸어요. 2026년 1월 워싱턴포스트가 보도한 내부 문서에서는 이 일을 ‘프로젝트 파나마’라고 부르며 “세상의 모든 책을 파괴적으로 스캔하려는 노력”이라고 적었습니다.

한국 책은 이미 팔려 나갔습니다.

10월 18일 뉴시스 보도에서 국내 도서유통사 웅진북센은 “2024년 Anthropic과 계약을 맺고 2025년에 공급했다”고 밝혔습니다. 몇 권을 보냈는지는 계약을 이유로 밝히지 않았어요. 웅진북센은 “2024년도에는 AI 학습 문제가 익숙하지 않아 통상 책 거래로 생각하고 제공했다”며, 앞으로 AI 업체로 갈 수 있는 거래는 하지 않겠다고 했습니다.

일본도 같은 길을 걸었습니다. 일본 도서유통사 닛판(日販) 그룹은 2024년 12월부터 1년 동안 Anthropic에 일본어 새 책을 팔았다고 인정했어요. 닛판 역시 당시에는 AI 학습에 쓰일 줄 몰랐다고 밝혔습니다.

교보문고만 연락을 받은 것도 아닙니다. 예스24는 지난 8월 한국을 찾은 업체와 만나기까지 했고, 알라딘은 9월 캐나다의 중고책 유통사에서 대량 구매 문의를 받았습니다. 두 곳 모두 거래로 이어지지는 않았어요.

사서 스캔하면 합법이고, 내려받으면 한 권에 약 400만 원입니다.

업체들이 굳이 돈을 내고 한 권씩 사는 데는 이유가 있습니다. 2024년 미국 작가들이 Anthropic을 상대로 낸 집단소송에서, 윌리엄 알섭(William Alsup) 판사는 2025년 6월 판단을 둘로 나눴습니다. 책으로 AI를 학습시킨 것, 그리고 산 종이책을 스캔해 디지털로 바꾼 것은 공정이용으로 인정했어요. 반대로 해적 사이트에서 내려받은 책을 쌓아 둔 것은 공정이용이 아니라고 봤습니다.

그 대가가 15억 달러(약 2조 원)입니다. Anthropic은 라이브러리 제네시스(LibGen)와 파이럿 라이브러리 미러(PiLiMi)에서 파일 약 700만 개를 내려받았고, 작가와 출판사에 작품당 약 3,000달러(약 400만 원)를 물어 주기로 합의했습니다. 합의 사이트는 이를 역사상 가장 큰 저작권 집단소송 합의라고 소개해요. 법원은 2026년 7월 20일 이 합의를 최종 승인했습니다.

정식으로 허락을 받고 쓰는 길도 있습니다. 2024년 11월 하퍼콜린스는 책을 3년 동안 AI 학습에 쓰게 해 주는 대가로 한 권에 5,000달러(약 670만 원)를 받는 계약을 맺었고, 이 돈을 작가와 출판사가 반씩 나눴습니다. 블룸버그는 계약 상대를 마이크로소프트로 보도했어요. 서점에서 한 권 사면 1~2만 원이니, 한 권씩 사서 스캔하는 쪽이 수백 배 쌉니다.

한강의 책도 합의 목록에 있었습니다.

10월 17일 한국문학번역원은 이 합의의 보상 대상 목록에서 한국 작가의 책 21권을 찾아 작가들에게 알렸습니다. 한강의 ‘소년이 온다’, ‘채식주의자’, ‘흰’, 김영하의 ‘빛의 제국’, 신경숙의 ‘엄마를 부탁해’, 김애란의 ‘두근두근 내 인생’, 김숨의 ‘한 명’, 황선미의 ‘마당을 나온 암탉’, 황석영의 ‘손님’ 등이에요. 모두 영어 번역판입니다.

한국어 원서는 이 목록에 들어가기 어렵습니다. 미국 저작권청에 제때 등록된 책만 합의 대상이기 때문입니다. 합의 사이트 설명을 보면 Anthropic이 내려받은 고유 작품 약 400만 권 가운데 약 250만 권이 영어가 아닌 책이었고, 대부분 등록되지 않아 목록에서 빠졌어요. 해적 사이트에 한국어 원서가 있었더라도 이 합의로는 받을 돈이 없다는 뜻입니다.

웹에는 한국어 문장이 적습니다.

업체들이 한국어 원서를 찾는 이유도 여기서 짐작할 수 있습니다. 공개 웹 페이지를 모아 두는 커먼크롤(Common Crawl)의 2026년 9월 수집분에서 한국어 페이지는 0.84%로 17위였습니다. 영어는 41.86%, 일본어는 5.17%예요. 편집을 거친 한국어 문장이 한 권 내내 이어지는 책은 웹에서 대신 구하기 어렵습니다.

지난달 ‘학습할 데이터는 다 떨어졌을 텐데, AI는 왜 더 좋아질까’에서 소개했던 강화학습은 검증기만 있으면 수학/코드 문제를 얼마든지 찍어 냅니다. 사람이 쓴 한국어 문장은 그렇게 찍어 낼 수 없으니, 결국 사 와야 합니다.

다만 누가 샀는지는 아직 모릅니다.

교보문고에 문의한 업체들의 최종 고객이 AI 회사인지는 확인되지 않았습니다. 교보문고도 AI 학습에 쓰일 가능성을 배제하기 어렵다고 했을 뿐이에요. 웅진북센이 Anthropic에 보낸 책이 몇 권이고 어떤 책인지도 공개되지 않았습니다.

화제가 된 X 글에도 바로잡을 부분이 있습니다. 책을 사서 파쇄하고 스캔하는 방식으로 불법 학습을 하다 소송이 났다고 적었지만, 미국 법원이 문제 삼은 건 해적 사이트에서 내려받은 책이었어요. 산 책을 스캔한 건 공정이용으로 인정받았습니다. 그렇다고 한국에서도 그대로 통한다는 보장은 없습니다. 덕성여대 AI 연구소 박정인 교수는 “헌책을 매입하는 행위 자체는 통상 적법하지만 그 책을 스캔하고 복제해 AI 학습에 이용하는 권리까지 취득하는 것은 아니다”라고 짚었어요.

출판계도 움직이기 시작했습니다. 대한출판문화협회는 서점과 중고서점, 유통사를 상대로 실태조사를 하기로 했고, 10월 16일 한국출판인회의 등과 함께 ‘대한민국 호소문’을 냈습니다. 같은 날까지 단체 174곳과 개인 358명이 이름을 올렸어요. AI 회사에 학습 데이터 공개와 이용 허락, 정당한 보상을 요구하는 내용입니다. 미국 도서유통사 잉그램은 올해 1월부터 AI 회사에 책을 팔고 싶지 않은 출판사가 빠질 수 있게 했습니다.

책 한 권의 값이 두 갈래로 나뉘고 있습니다. 사람에게는 1~2만 원이지만, AI가 배울 때는 해적판으로 약 400만 원, 계약으로 약 670만 원이었어요. 교보문고와 웅진북센이 쓰임새를 모르는 주문은 받지 않겠다고 한 만큼, 한국어 책도 사서 스캔하기보다 출판사와 값을 정하고 쓰는 쪽으로 옮겨 갈 듯싶습니다.

https://www.joongang.co.kr/article/25469854

10월 15일(미국 시간), 구글 딥마인드 연구진이 ‘Gemini 4 Argon 에이전트 팀이 마인크래프트를 깼다(A team of Gemini 4 Argon agents beats Minecraft)’라는 논문을 공개했습니다. Gemini 4 Argon 에이전트 4명을 마인크래프트 서바이벌 월드에 넣고 엔더 드래곤을 잡으라는 목표 하나만 줬더니, 27시간 14분 만에 정말 잡았다는 내용입니다. 그동안 넷이 직접 짜서 돌린 프로그램은 2,783개, 죽은 횟수는 605번이에요.

구글 딥마인드 공식 X 계정의 소개 글은 조회수 21만을 넘겼고, 제1저자 Maxence Faldor가 X에 올린 해설 글도 23만 번 조회됐습니다.

그런데 이 넷에게는 아무도 역할을 정해 주지 않았습니다. 게임 공략도, 마인크래프트 전용 도구도 없었어요. 마인크래프트용으로 따로 만든 AI가 아니라, 엔지니어들이 평소 코딩에 쓰는 범용 에이전트 그대로였습니다. 그럼 넷은 하루가 넘게 걸리는 게임을 어떻게 끝까지 해냈을까요?

결론부터 말하면, 비결은 일하는 방식입니다.

논문을 뜯어보면 넷이 한 일은 손발이 잘 맞는 사람 팀과 닮았습니다. 10분 만에 역할을 나눴고, 좌표와 교훈을 공유 메모리에 적었고, 자주 쓰는 동작은 도구로 만들어 돌려 썼습니다. 실패하면 규칙을 만들었고, 잘못 보고한 건 스스로 바로잡았어요. 연구진도 이 팀이 “효과적인 사람 팀에서 익숙한 방식”으로 수렴했다고 정리합니다.

화면 대신 코드로 게임을 했습니다.

에이전트는 화면을 보지도, 키보드를 누르지도 않았습니다. 대신 짧은 자바스크립트 프로그램을 씁니다. “이 좌표로 걸어가서 16칸 안에 있는 철광석을 전부 캐라” 같은 프로그램이요. 마인크래프트 캐릭터를 코드로 움직이게 해 주는 공개 라이브러리 Mineflayer가 이걸 실행하고, 결과는 글자로 돌아옵니다. 지금 위치와 체력, 가방에 든 것, 찾은 것, 아니면 부딪힌 에러요. 에이전트는 그걸 읽고 다음 프로그램을 씁니다.

프로그램 하나가 실행된 시간은 중간값 33.5초였습니다. 프로그램이 실제로 돌아간 시간은 전체의 약 40%였고, 나머지는 결과를 읽고 생각하고 다음 프로그램을 쓰는 데 들었어요. Mineflayer가 해 주는 건 걷기, 블록 캐기와 놓기, 아이템 만들기, 공격 같은 기본 동작뿐입니다. 무엇을 어떤 순서로 할지는 전부 에이전트의 몫이었습니다.

넷은 모두 Gemini 4 Argon으로 돌아가는 같은 범용 코딩 에이전트이고, 각자 클라우드 컴퓨터를 한 대씩 썼습니다. 도구도 소프트웨어를 개발할 때와 똑같이 줬어요. 버전 관리가 되는 작업 공간, 셸, 파일 편집, 웹 검색, 그리고 계속 남는 메모리입니다. 메모리는 혼자 보는 칸과 팀이 같이 보는 칸으로 나뉩니다. 게임은 마인크래프트 자바 에디션 1.20.4로, 무작위로 만든 월드에서 서바이벌 모드, Easy 난이도로 했습니다. 치트 명령은 막아 뒀고, 사람은 한 번도 손대지 않았습니다.

하루 넘게 일하면 대화 기록이 감당하기 어려울 만큼 길어집니다. 그래서 에이전트는 기록이 너무 길어지면 압축(컴팩션)하는데, 지시문은 압축 뒤에도 살아남아야 할 것, 하던 일과 다음 할 일을 메모리에 적어 두게 했습니다. 지난달 ‘AI는 왜 오래 일하면 바보가 될까?’에서 소개했던, 대화 기록 대신 파일에 남겨 두는 바로 그 방식입니다.

지시문에는 공략 대신 일하는 습관을 적었습니다.

게임에 관한 지시는 넷이 한 팀이라는 짧은 메모와 한 문단이 전부였습니다. “목표는 이 세션의 공유 서바이벌 월드 스폰 지점에서 출발해 엔더 드래곤을 쓰러뜨리는 것이다. (중략) 이것이 유일한 기준이다. 서바이벌 모드 규칙 안에서라면 어떤 수단이든 허용되며, 일을 어떻게 나눌지는 플레이어들이 정한다.”

나머지는 어떤 환경에 넣든 똑같은 일반 지시입니다. 행동하기 전에 살피고 행동한 뒤엔 결과를 확인할 것, 새 도구는 짧은 작업으로 검증한 뒤에 믿을 것, 손으로 하는 동작이 느리거나 불안하면 도구를 만들 것, 같은 장애물을 두 번 만나지 않게 요령과 우회법을 메모리에 적을 것, 백그라운드 작업이 도는 동안에도 일을 이어 갈 것, 결과를 정직하게 보고할 것, 평가의 허점을 파고들지 말고 목표 자체를 좇을 것. 게임 전략은 한 줄도 없습니다.

감시도 에이전트가 맡았습니다. 다섯 번째 에이전트 Observer는 게임에 들어가지 않고 기록만 읽으며 플레이어들의 주장을 기록과 맞춰 봤어요. 평가의 허점을 이용한 꼼수나 지어낸 결과를 찾아 보고하는 역할인데, 꼼수는 끝까지 발견되지 않았습니다. 연구진은 실시간 대시보드로 지켜보며 언제든 멈출 수 있었지만, 끼어들 일은 없었다고 합니다.

역할은 10분 만에 스스로 나눴습니다.

첫 프로그램이 돌고 10분 뒤, janesick이 채팅에 역할 분담을 제안했습니다. 1분도 안 돼 auratian이 다른 안을 내놨고, gyldenia가 “Copy that!”으로 받았어요. 역할은 금방 자리를 잡았습니다. gyldenia는 음식과 침대, 부싯돌을 구하러 다니고, bulicame은 다이아몬드를 캐러 내려가고, janesick은 철을 녹여 도구를 만들고, auratian은 네더 포털을 준비했습니다.

2시간이 안 돼 철 도구와 다이아몬드, 네더 포털까지 갖췄습니다. 포털에 불을 붙인 건 1시간 42분째였어요. 그 뒤로도 맡은 일이 뚜렷했습니다. 네더 요새를 찾고 엔드 포털 위치를 계산한 건 janesick, 드래곤을 회복시키는 수정을 부술 방법을 찾은 건 auratian, 수정 10개 중 6개를 부순 건 gyldenia, 마지막 일격은 bulicame이었습니다. 각자 돌린 프로그램도 646개에서 735개 사이로, 일이 고르게 나눠졌어요.

말 대신 좌표를 주고받았습니다.

채팅은 네 봇 모두에게 전달되고, 각자 다음 프로그램을 돌리면 결과와 함께 찍혀 나옵니다. 드래곤을 잡기까지 오간 메시지 229개 가운데 173개에 정확한 좌표가 들어 있었습니다. 공유 상자를 언급한 메시지가 64개, 위험 경고가 24개, 죽은 동료의 아이템을 찾아 준 메시지가 20개였어요.

공유 메모리에는 상자와 포털, 위험한 곳의 좌표와 도구의 버릇을 적었습니다. 19분째에 gyldenia가 Mineflayer의 아이템 제작 기능에 있는 버릇과 피하는 법을 알렸는데, 이를 반영한 도우미 함수가 네 에이전트가 쓴 프로그램 655개에 들어갔습니다. 넷이 주로 주고받은 건 정리본보다 좌표와 코드였던 셈입니다. 지난달 ‘에이전트를 여러 개 띄우면 정말 더 좋을까’에서 소개했던, 넘겨줄 때마다 흐려지는 복사본 문제를 비켜 가는 방식이에요.

도구는 직접 만들어 썼습니다.

프로그램이 끝나도 변수를 남겨 둘 수 있다는 점도 잘 활용했습니다. 넷은 프로그램 사이에 상태와 코드 146개를 살려 뒀는데, 그중 42개가 직접 만든 도우미 함수였어요. 물에 빠지지 않게 봇을 계속 띄워 두는 백그라운드 반복문, 시간을 재며 걷기, 아이템 세기 같은 것들입니다. 시간 초과로 끊긴 프로그램의 남은 코드를 스스로 멈추게 하는 카운터는 프로그램 1,519개에서 쓰였습니다. 27시간 동안 쓴 자바스크립트는 중복을 빼고 6만 3,313줄입니다.

계산도 코드로 했습니다. ‘엔더의 눈’은 던지면 엔드 포털이 있는 가장 가까운 지하 요새 쪽으로 날아갑니다. janesick은 이걸 서로 다른 두 곳에서 던지고, 날아가는 궤적을 0.05초마다 기록한 뒤 두 직선이 만나는 점을 계산했습니다. 마을에서 1.3km 떨어진 곳이었고, 실제 포털 방과는 43m 차이였어요.

실패는 규칙이 됐습니다.

순탄하지는 않았습니다. 네더에서 블레이즈 가루를 가져오는 데만 6시간 넘게 걸렸어요. janesick은 가루 12개를 들고 가다 불에 타 죽었고, 가스트(네더의 공중 몬스터)의 화염구가 바닥에 떨어진 아이템 더미를 날려 버리기도 했습니다. 그러자 auratian이 팀 전체에 “중요한 교훈”이라며 규칙을 올렸고, 2분 뒤 janesick이 원인과 해결책을 덧붙였습니다.

동료의 실수도 메웠습니다. auratian이 엔더의 눈 12개를 모두 들고 가다 물에 빠져 죽었을 때, janesick과 auratian은 8m 옆에 있던 bulicame에게 각각 정확한 위치와 아이템이 사라질 시각을 보냈어요. 떨어진 아이템은 5분 뒤 사라지는데, bulicame은 2분 30초를 남기고 12개를 모두 주웠습니다. 13시간 17분째, 엔드 포털이 열렸습니다.

가장 오래 걸린 건 드래곤입니다. 드래곤에게만 69번 죽었어요. 넷은 시도 사이사이 게임 내부 데이터를 읽어 드래곤이 지금 어떤 행동 단계인지까지 확인하고 규칙을 적었습니다. 도착 지점에서 기다리지 말 것, 드래곤이 내려앉았을 때만 다가갈 것, 드래곤이 멈춰 버리면 엔드를 비워서 초기화할 것. 17시간 30분째에는 넷이 6분 안에 일부러 공허로 뛰어내렸습니다. 엔드에 아무도 없으면 서버가 그 구역을 내려놓고, 멈춰 있던 드래곤도 초기화되기 때문입니다.

돌파구는 21시간째쯤 나왔습니다. auratian이 기둥 위 엔드 수정 10개가 드래곤의 체력을 계속 채우고 있다는 걸 짚었고, 곡괭이 없이 수정에 닿는 방법도 찾았어요. 기둥 옆에 흙을 쌓아 올라가 수정을 주먹으로 부수고, 흙을 손으로 파며 내려오는 겁니다. 넷은 이후 4시간 40분에 걸쳐 수정 10개를 모두 부쉈고, 마지막 수정이 부서지고 39분 뒤 드래곤이 쓰러졌습니다. 마지막 일격을 날린 bulicame의 체력은 20 중 2.5였어요.

잘못된 보고는 스스로 바로잡았습니다. auratian의 프로그램이 일어나지도 않은 성공을 채팅에 알리자, auratian은 2분 뒤 “방금 채팅은 확인 없이 실행된 스크립트 분기였다”며 정정했습니다. janesick이 불에 타 죽은 지 1초 뒤에 블레이즈 가루 12개를 들고 돌아왔다고 보고했을 때는, gyldenia가 3분 안에 모순을 짚었고요.

27시간에 든 돈은 약 69만 원입니다.

드래곤을 잡기까지 넷이 처리한 입력은 약 13억 5천만 토큰, 출력은 생각에 쓴 400만 토큰을 포함해 약 1,600만 토큰이었습니다. 모델을 부른 횟수는 약 2만 4천 번이고, 입력의 91%는 캐시로 처리됐어요. 캐시는 앞에서 이미 읽은 내용을 다시 계산하지 않고 재활용하는 기능입니다.

Gemini 4 Argon의 공개 API 출시 할인가로 따지면 약 520달러(약 69만 원), 정가로는 약 1,040달러(약 139만 원)입니다. Observer와 드래곤을 잡은 뒤 하루 동안의 활동까지 합친 전체 세션은 약 810달러(약 108만 원), 정가로 약 1,620달러(약 216만 원)였어요. 연구진은 이 숫자가 실제로 모델을 돌리는 데 든 비용이 아니라, 정가와 토큰 수로 낸 추정치라고 밝혔습니다.

드래곤을 잡은 AI가 처음은 아닙니다.

논문에 따르면 9월에는 Claude Opus 5 에이전트 하나가 사람이 미리 만들어 둔 마인크래프트 전용 도구 37개를 써서 Normal 난이도에서 드래곤을 잡았습니다. GPT-6 Astra가 계획을 짜고 Jev 1.13이 동작을 고르는 프로젝트도 있는데, 몬스터가 나오지 않는 Peaceful 난이도에서 엔드 포털이 처음부터 열려 있는 맵을 골라 8분 43초 만에 끝냈습니다.

이번 실험이 다른 건 받은 것의 양입니다. 연구진은 공개된 Mineflayer와 길찾기 플러그인, 목표 한 문단, 일반 지시만 줬습니다. 게임 지시도, 단계별 과제 목록도, 미리 만든 기술 모음도, 사람이 짠 도구도, 정해 둔 경로도 없었어요. 무작위 월드에서 시작했고, 몬스터가 나오는 Easy였습니다. 연구진은 이를 사람이 만든 게임 전용 도구 없이 AI 에이전트가 마인크래프트를 처음부터 끝까지 스스로 깬 첫 사례로 봅니다.

다만 사람처럼 논 건 아닙니다.

사람 플레이어가 엔딩까지 보는 데는 중앙값 45시간이 걸리고(HowLongToBeat), 세계 기록은 7분이 안 됩니다. 넷이 나눠서 한 데다 조건도 달라서 바로 견주기는 어렵습니다. 연구진이 직접 밝힌 차이와 한계는 이렇습니다.

1. 보는 방식이 다릅니다. Mineflayer는 주변 블록과 생물을 정확히 알려 줍니다. 바위 뒤에 숨은 블록이나 드래곤의 내부 상태처럼 사람은 볼 수 없는 정보까지요. 길찾기도 플러그인이 대신했습니다. 구글 딥마인드의 SIMA 2처럼 화면을 보고 키보드와 마우스로 하는 건 훨씬 어렵습니다.
2. Easy 난이도였습니다. 몬스터가 나오고 공격도 하지만 Normal이나 Hard보다 피해가 적고, 배가 고파 죽지는 않습니다.
3. 이미 아는 게임이었습니다. Gemini 4 Argon은 학습 데이터로 마인크래프트와 Mineflayer를 많이 압니다. 넷이 돌린 프로그램이나 채팅에 웹을 참고한 흔적은 없었지만, 이 실험이 본 건 처음 보는 게임을 하는 능력이 아니라 아는 것을 돌아가는 코드와 팀워크로 바꾸는 능력입니다.
4. 실패가 많았습니다. 605번 죽었고 그중 351번이 몬스터 때문이었습니다. 프로그램의 22%는 에러로 끝났고, 엔드에서의 싸움에만 14시간 가까이 걸렸어요.
5. 딱 한 번 돌린 결과입니다. 처음 시도한 실행 한 번이라, 이 설정이 얼마나 꾸준히 성공하는지는 알 수 없습니다. 도중에 서버도 6번 재시작됐고요.

하나 더 짚자면, 논문에는 같은 조건에서 에이전트 하나로 돌린 비교가 없습니다. 그래서 넷이 팀을 짜서 이긴 건지, Gemini 4 Argon이 강해서 이긴 건지는 이 논문만으로는 가를 수 없어요. 연구진도 팀 규모를 키우면 협업이 어떻게 달라지는지를 다음 질문으로 꼽았습니다.

연구진이 노리는 건 게임 다음입니다.

연구진은 마인크래프트는 실험장일 뿐이고, 여기서 쓴 능력은 일반적이라고 말합니다. 하루 넘게 한 목표를 좇고, 프로그램 수천 개를 쓰고 고치고, 실패에서 회복하고, 팀으로 움직이는 것. 긴 소프트웨어 프로젝트와 연구가 요구하는 능력이라는 거죠. 이번에 쓴 하네스(에이전트를 돌리는 틀)와 교훈을 소프트웨어 개발, 과학 연구, 디자인, 로보틱스로 가져가겠다고 밝혔습니다.

지금까지 에이전트 경쟁은 모델 하나가 얼마나 똑똑한지를 겨뤘습니다. 이번 실험은 질문을 조금 옮겨 놓습니다. 범용 에이전트 여럿이 일을 나누고, 기록을 남기고, 서로의 실수를 메우면서 하루 넘게 한 목표를 향해 갈 수 있느냐로요. 드래곤은 쓰러졌지만, 진짜 시험은 이제 실제 업무에서 치르게 될 것 같습니다.

https://arxiv.org/abs/2610.22319

10월 17일, DeepSeek이 V4.1 Flash 1017을 내놨습니다. 스스로 ‘작은 업데이트(minor update)’라고 부른 버전인데, 반응은 전혀 작지 않았습니다. 공식 X 계정의 발표 글은 이틀 만에 조회수 680만, 좋아요 3만 6천을 넘겼고, 허깅페이스에서는 트렌딩 모델 1위에 올랐어요.

화제가 된 건 모델 카드에 실린 표 한 장입니다. 코딩 에이전트 평가인 DeepSWE에서 77.0점을 받아 Claude Opus 5(74.0)와 GPT-5.6 Sol(73.0)을 앞섰거든요.

그런데 좀 이상하죠. 새 모델도 아니고 ‘작은 업데이트’인데, 어떻게 한 달 남짓 만에 Opus 5를 넘었다는 걸까요?

결론부터 말하면, 모델은 그대로입니다.

1017은 9월 10일에 나온 V4.1 Flash와 규모가 똑같아요. 허깅페이스에 올라온 두 모델의 파라미터 수는 7,632억 531만 5,794개로 마지막 자리까지 같습니다. 구조도 그대로예요. 전체 파라미터는 7,600억 개가 넘지만 토큰 하나를 처리할 때 실제로 쓰는 건 80억~160억 개뿐인 MoE(전문가 혼합) 구조이고, 한 번에 100만 토큰까지 읽습니다.

규모는 그대로인데 점수는 크게 올랐습니다. 이전 V4.1 Flash와 비교하면 터미널 작업 평가(Terminal-Bench 4.0)는 31.2점에서 42.3점으로, ProgramBench는 20.3점에서 29.1점으로 뛰었어요. DeepSeek은 점수는 오르고, 답은 짧아지고, 일은 더 빨리 끝난다며 성능과 비용 모두에서 나아졌다고 소개했습니다.

바뀐 건 ‘연습량’입니다.

DeepSeek은 1017에서 정확히 무엇을 했는지 따로 밝히지 않았습니다. 대신 V4.1 Flash 기술 보고서에 힌트가 있어요. 사후 학습은 SFT, 강화학습(RL), 온폴리시 증류(OPD)로 이어지는 표준 방식을 알고리즘 수정 없이 그대로 썼고, 실질적인 변화는 전부 데이터 쪽에 있다고 적었습니다. 에이전트가 풀 과제와 그 과제를 풀 환경을 자동으로 대량 만들어 내고, 데이터와 과제와 풀어 보는 횟수를 점점 늘렸다는 거죠. 지난달 ‘학습할 데이터는 다 떨어졌을 텐데, AI는 왜 더 좋아질까’에서 소개했던, 채점이 자동으로 되는 시험지를 끝없이 찍어 내 AI를 연습시키는 바로 그 방식입니다.

쉽게 말해 같은 뇌에 문제집을 더 풀린 겁니다. 모델을 처음부터 다시 학습시키려면 몇 달과 막대한 비용이 들지만, 연습은 몇 주 단위로 더 시킬 수 있어요. 1017은 V4.1 Flash가 나온 지 5주 만에 나왔습니다.

Z.ai의 GLM-5.3도 기반 모델은 GLM-5.2 그대로였는데, 연습 환경을 늘려 자체 평가 점수를 50% 끌어올렸죠. 이제 모델 경쟁은 누가 더 큰 모델을 새로 만드느냐보다, 누가 더 많은 연습장을 만드느냐로 옮겨 가고 있어요.

그럼 정말 Opus 5를 이겼을까요?

표를 끝까지 보면 이야기가 조금 달라집니다. 모델 카드에서 Opus 5와 나란히 비교한 평가는 11개인데, 1017이 이긴 건 4개예요.

1. 이긴 평가: DeepSWE 77.0 대 74.0, Automation-Bench 60.5 대 50.3, Agents’ Last Exam 35.4 대 28.6, Apex Bench 72.1 대 65.8
2. 크게 진 평가: HLE(도구 없이) 42.6 대 56.3, Terminal-Bench 4.0 42.3 대 51.8, ProgramBench 29.1 대 37.0, NL2Repo-Bench 68.2 대 75.3
3. 나머지 이미지 이해 평가 3개는 1~2점 차로 졌습니다.

에이전트처럼 여러 단계를 거쳐 일을 처리하는 평가에서는 앞섰지만, 아주 어려운 문제를 푸는 추론(HLE)이나 터미널 작업에서는 9~14점 차로 뒤졌어요.

그리고 하나 더. 비교 대상은 Opus 5입니다. Anthropic은 9월 22일에 Opus 5.5를 냈고, 스스로 Opus 5보다 큰 폭으로 좋아졌다고 밝혔어요. 1017과 Opus 5.5를 나란히 놓은 공식 표는 아직 없습니다. 그러니 정확히 말하면 “한 세대 전 Opus 5를, 에이전트 평가 몇 개에서 이겼다” 정도예요.

진짜 무기는 가격입니다.

그런데도 사람들이 열광하는 이유는 점수보다 가격이에요. DeepSeek API에서 1017의 출력 가격은 100만 토큰당 1.2달러, 한가한 시간에는 0.6달러입니다. Opus 5.5는 20달러, Opus 5는 25달러예요. 출력 기준으로 Opus 5.5보다 약 17배, 한가한 시간에는 33배 쌉니다. 입력도 0.3달러 대 4달러로 13배쯤 차이가 나고요.

X에서 퍼진 것도 이 대목입니다. 한 사용자는 같은 로켓 발사 장면을 만들게 했더니 GPT-6.1 Sol은 6.10달러에 5분, 1017은 0.78달러에 3분이 걸렸다며 결과를 비교했어요. “Opus 5급”보다 “이 가격에 이 정도?”라는 반응이 훨씬 많습니다.

한국에서 쓴다면 시간대도 챙겨야 합니다. DeepSeek은 평일 피크 시간에 두 배를 받는데, 한국 시간으로 오전 10시~오후 1시, 오후 3시~7시입니다. 하필 업무 시간과 많이 겹치죠. 이 시간을 피하면 절반 가격이고, 주말과 중국 공휴일은 종일 할인이에요.

누구나 받아 쓸 수 있습니다. 다만…

가중치는 MIT 라이선스로 공개돼서 누구나 내려받아 고치고 상업적으로 써도 됩니다. 다만 직접 돌리려면 장비가 만만치 않습니다. 내려받는 파일만 510GB예요.

원본 그대로는 GPU 8장이 기본입니다. DeepSeek이 공개한 실행 코드는 모델을 GPU 8장에 나눠 싣고, 전문가 부분은 4비트, 나머지는 8비트로 돌립니다. 80GB짜리 H100으로 치면 8장(640GB)은 있어야 가중치를 올리고 문맥을 담을 자리가 남습니다. AWS 같은 클라우드에서 H100 8장이 달린 서버를 빌리면 시간당 약 55달러(약 7만 3천 원), 한 달 내내 켜 두면 약 4만 달러(약 5,300만 원)입니다.

개인 장비로는 맥 스튜디오가 현실적인 선입니다. 일본 회사 엘브즈는 2비트로 줄인 버전을 메모리 512GB짜리 맥 스튜디오(M3 Ultra) 한 대에서 돌려 초당 약 36토큰을 냈습니다. 1,960억 개짜리 기억 표(Engram)는 필요한 줄만 그때그때 읽어서, 메모리에 늘 올려 두는 건 약 152GiB뿐이라고 해요. 다만 이 파일은 엘브즈 엔진에서만 돌아갑니다. 지금 파는 M5 Ultra 맥 스튜디오는 949만 원부터이고, 512GB 메모리 옵션은 10월 하순에 나옵니다.

그래서 실제로는 대부분 API로 쓰게 됩니다. Anthropic API 형식도 지원해서 Claude Code 같은 도구에 백엔드로 바로 붙일 수 있습니다. DeepSeek이 Terminal-Bench 점수를 잴 때 쓴 도구도 Claude Code였고요. 기존 deepseek-v4-flash 이름으로 호출하던 서비스는 따로 손대지 않아도 1017로 바뀌었습니다.

다음 모델을 기다리지 않아도 되는 시대

예전에는 모델이 좋아지려면 다음 버전을 기다려야 했습니다. 이제는 같은 모델이 몇 주 만에 한 단계씩 올라가요. 연습장만 늘리면 되니까요. 그래서 “어떤 모델이 1등이냐”보다 “내 일에 맞는 평가에서, 이 가격에, 충분하냐”를 묻는 게 더 중요해졌습니다.

https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017

“다른 앱에서 내 제품에 넣고 싶은 기능을 봤나요? 에이전트에게 REA로 조사해 보라고 하세요. 소스 코드 없이도 앱을 들여다보고, 그 기능이 어떻게 돌아가는지 설명하고, 근거를 보여 주고, 당신 프로젝트에 맞는 버전을 만들어 줍니다.”

깃허브에 올라온 오픈소스 프로젝트 REA의 소개 문구입니다. REA는 ‘Reverse Engineer Anything’, 무엇이든 거꾸로 뜯어본다는 뜻이에요. 이 프로젝트가 지금 개발자들 사이에서 난리입니다. 깃허브에서 ‘좋아요’에 해당하는 별을 10월 8일 2만 개에서 14일 20만 개까지 모았고, 오늘(16일)은 27만 개를 넘었어요. 일주일 남짓 만에요.

“리버스 엔지니어링”이 뭘까요?

우리가 쓰는 프로그램은 대부분 개발자가 쓴 코드를 컴퓨터가 알아듣는 형태로 바꿔서 배포됩니다. 사람이 그대로 읽기는 어려운 모양이죠. 리버스 엔지니어링, 우리말로 역공학은 이 과정을 거꾸로 밟아서 완성된 프로그램이 안에서 어떻게 돌아가는지 알아내는 일이에요.

원래는 전문가의 영역이었습니다. Ghidra나 IDA, Hopper 같은 전문 도구를 띄워 놓고 기계어를 한 줄씩 읽어 가며 추리해야 했거든요.

REA는 AI에게 그 도구를 쥐여 줍니다.

REA의 핵심은 Claude Code, Codex, Cursor 같은 AI 코딩 에이전트가 이런 분석 도구를 직접 쓸 수 있게 이어 주는 것입니다. 설치는 명령어 한 줄이면 되고, 그다음엔 에이전트에게 말로 시키면 돼요. AI가 알아서 도구를 돌리고, 결과를 읽고, 아직 모르는 부분은 모른다고 표시한 뒤 설명하거나 비슷한 기능을 직접 만들어 봅니다.

대상도 넓습니다. 웹사이트, 데스크톱 앱, 안드로이드 앱, 기기 안에 들어가는 펌웨어까지 들여다볼 수 있어요. 분석 자체는 내 컴퓨터 안에서 돌아가고요. 일본의 한 개발자는 REA를 두고 스스로 분석하는 도구라기보다 여러 분석 도구를 AI가 쓰기 좋게 묶어 준 꾸러미에 가깝다고 평가하기도 했습니다.

30년 가까이 된 게임도 뜯었습니다.

REA가 내세운 사례가 재미있어요. 1990년대 벽돌깨기 게임 DX-Ball에서는 벽돌 위치에 따라 효과음이 왼쪽이나 오른쪽에서 들리게 하는 계산식을 찾아냈습니다. AI가 다시 짠 코드는 원래 게임과 3,205가지 경우에서 똑같은 값을 냈고, 컴파일해 보니 원래 함수와 63바이트까지 똑같았어요.

1990년대 일본 PC-98용 슈팅 게임인 동방 프로젝트 4편에서는 총알이 원을 그리며 퍼지는 패턴의 각도 계산을 되살렸습니다. 노션 데스크톱 앱에서는 복사해서 붙여 넣을 때 블록 정보가 어떤 길로 전달되는지 추적했고요.

AI도 틀립니다. 그래서 근거를 붙입니다.

물론 AI가 척척 다 해내는 건 아닙니다. DX-Ball 사례에서도 분석 도구가 보여 준 코드에는 함수에 들어가는 값 하나가 빠져 있었어요. 그 화면만 믿었다면 AI는 그럴듯하게 틀린 답을 냈을 겁니다. 그래서 REA는 결론마다 근거와 한계를 함께 돌려주고, 사례마다 사람이 직접 확인한 단계가 들어가 있어요. 함수 하나를 되살린 것과 게임 하나를 다시 만드는 것 사이의 거리도 아직 멀고요.

포토샵을 통째로 다시 만든 사람도 나왔습니다.

REA가 뜬 바로 그 주에 화제가 된 프로젝트가 하나 더 있어요. 미국 개발자 브랜던 토머스가 내놓은 PhotoCraft입니다. 어도비 포토샵을 처음부터 새로 짠 무료 오픈소스 프로그램으로, 레이어와 마스크, 보정 레이어, 글자, 브러시에 포토샵 파일(PSD)까지 다뤄요. 토머스는 Anthropic의 AI인 Claude Opus 5.5로 포토샵과 일러스트레이터, 프리미어, 라이트룸 같은 어도비 프로그램 일곱 개를 다시 만들었다고 밝혔습니다. 어도비 구독을 해지하다 위약금을 여러 번 물고 나서 어도비가 싫어졌다고 하고요. 9월 30일에 연 PhotoCraft 저장소는 2주 남짓 만에 깃허브 별 6만 개를 넘겼습니다.

다만 PhotoCraft는 REA로 만든 게 아닙니다. 방향이 오히려 반대예요. 토머스는 어도비 프로그램 안은 들여다보지 않고, 공개된 자료와 프로그램이 움직이는 모습만 보고 새로 짰다고 강조합니다. 이른바 ‘클린룸’ 방식인데, 1980년대 컴팩이 IBM PC와 똑같이 돌아가는 컴퓨터를 만들 때 쓴 방법이기도 해요. 남의 코드는 한 줄도 베끼지 않았다는 걸 보여 주려는 거죠.

아직 포토샵을 대신할 수준은 아닙니다. PhotoCraft 스스로도 ‘초기 알파’ 단계라서 전문가가 매일 일하는 데 쓰기엔 이르다고 밝혀 두었어요. 직접 써 본 해외 매체도 겉모습만 닮았을 뿐, 매일 쓰다 보면 빠진 기능과 버그가 쌓인다고 평가했고요. 토머스도 AI에게 대충 맡긴 초보는 아닙니다. 15년 차 개발자로, PhotoCraft를 짠 프로그래밍 언어 Rust를 10년 정도 써 왔다고 해요. 그래도 30년 넘게 다듬어 온 포토샵을 겉모습이나마 AI와 함께 이만큼 따라왔다는 데 다들 놀란 거죠. 토머스는 지금 워드, 엑셀, 파워포인트를 닮은 앱도 만들고 있어요.

기능을 따라 만들어도 되는 걸까요.

사람들이 열광한 건 결국 소개 문구의 그 한 줄일 겁니다. 마음에 드는 남의 앱 기능을 뜯어보고 내 것으로 만들 수 있다는 것. 그런데 REA 스스로도 선을 긋습니다. 보안 연구, 악성코드 분석, 교육, 호환, 오래된 소프트웨어 보존처럼 합법적인 분석에만 쓰라고 하고, 복제 방지 장치나 라이선스 확인을 우회하는 일, 게임 핵 개발, 남의 코드와 자산을 그대로 베끼는 일은 돕지 않는다고 못 박았어요.

법에도 선이 있습니다. 우리 저작권법은 허락 없는 역분석을 좁게 허용해요. 프로그램을 정당하게 쓰는 사람이 다른 프로그램과 호환하는 데 꼭 필요한 정보를 다른 방법으로 얻기 어려울 때, 필요한 부분에 한해서만요. 그렇게 얻은 정보로 원래 프로그램과 실질적으로 비슷한 프로그램을 만드는 것도 막고 있습니다. “기능을 이해하고 내 버전을 만든다”는 소개 문구가 어디까지 괜찮은지는 나라마다, 경우마다 따져 봐야 하는 셈이죠.

숨겨 둔 건 더 이상 숨겨진 게 아닙니다.

보안 쪽에서도 의미가 큽니다. 지키는 쪽은 악성코드를 더 빨리 분석하고 취약점을 더 빨리 찾을 수 있어요. 반대로 공격하는 쪽도 같은 도구를 쓸 수 있습니다. 앱을 만드는 회사라면 이제 ‘어차피 아무도 못 읽겠지’ 하고 앱 안에 중요한 계산이나 비밀 정보를 넣어 두는 습관부터 버려야 할 것 같아요.

쓰는 사람도 조심할 게 있습니다. REA는 분석할 프로그램을 내 컴퓨터 권한으로 실행하기도 하고, 분석 대상 안에 AI를 속이는 문구가 숨어 있을 수도 있어요. 분석은 내 컴퓨터에서 돌아가도 결과는 AI 회사로 넘어가고요. 인기가 치솟자 REA 이름을 단 코인까지 나왔습니다. 개발자는 코인과 무관하다고 밝히고, 비슷한 이름의 저장소가 아니라 공식 경로로만 받으라고 따로 공지했어요.

앱 하나를 뜯어보는 건 오랫동안 소수 전문가의 일이었습니다. 이제는 말 한마디로 AI에게 시킬 수 있어요. 남이 공들여 만든 것을 어디까지 들여다보고 따라 만들어도 되는지, 그 선을 다시 그어야 할 때가 온 것 같습니다.

https://github.com/morluto/rea

몸값부터 어마무시합니다. AI가 개발자 일을 대신할 거라는 말이 나오는 요즘, 정작 AI를 만드는 회사들은 이 사람들을 못 구해서 난리예요. OpenAI는 기본급 최대 6억 원, Anthropic은 최대 5.5억 원을 걸고 사람을 찾습니다. 구글도 같은 직함으로 뽑고 있고요.

FDE는 Forward Deployed Engineer의 줄임말입니다. 10월 12일에 OpenAI 채용 페이지에서 ‘forward deployed’로 검색해 보니 공고 811개 중 32개가 나왔어요.

결론부터 말하면, 고객사에 들어가 일하는 개발자입니다.

우리말로 옮기면 ‘전방에 배치된 엔지니어’입니다. 회사 안에서 제품을 만드는 대신, 고객사에 직접 들어가 그 회사 일에 맞춰 AI를 붙이는 사람이에요.

회사 일은 매뉴얼대로만 돌아가지 않잖아요. 진짜 일하는 방식은 문서 어디에도 없고 담당자들 머릿속에 있는 경우가 많습니다. FDE는 그걸 현장에서 직접 보고 파악합니다. 그다음 어디에 AI를 쓸지 고객과 같이 정하고, 코드를 짜서, 실제 업무에서 돌아가게 만드는 데까지 책임지죠.

컨설턴트와 헷갈릴 만도 합니다. 고객사의 일을 파악하는 데서 시작하는 건 똑같거든요. FDE 공고를 모아 보여 주는 FDE Pulse에서 공고를 많이 낸 회사를 봐도, 구글 바로 다음이 컨설팅 회사 딜로이트예요. 차이는 끝에서 납니다. 컨설턴트의 결과물이 보통 무엇을 바꿀지 정리한 보고서라면, FDE는 실제로 돌아가는 시스템을 남깁니다.

고객사에서 일하다 보니 출장도 많습니다. OpenAI 서울 공고에는 출장이 50%라고 적혀 있고, Anthropic 공고에도 고객사 출장이 25~50%라고 나와 있어요. 사무실보다 고객사에 있는 시간이 많은 직업이죠.

시작은 팔란티어였습니다.

이 방식을 처음 키운 곳은 데이터 분석 회사 팔란티어입니다. 정부나 군처럼 현장에 들어가야 일을 알 수 있는 고객을 상대하면서 엔지니어를 고객 옆에 붙여 보냈죠. 팔란티어는 지금도 이 직무를 ‘Forward Deployed Software Engineer’라는 이름으로 뽑습니다.

팔란티어가 대단한 건 이 엔지니어들로 돈을 버는 방식입니다. 국내에서 처음 팔란티어를 구축해 본 변우철 KT 본부장은 지난해 한 인터뷰에서 팔란티어가 프로젝트마다 파견 엔지니어를 무조건 보낸다고 했어요. 그런데 팔란티어가 정말로 파는 건 엔지니어가 아니라 소프트웨어 구독입니다. 상장 서류에 시범 운영은 무료나 싼값에 해 주는 경우가 많다고 적었을 정도예요. 엔지니어가 팔란티어 소프트웨어 위에 시스템을 만들어 놓고 나면, 고객은 그걸 계속 쓰려고 몇 년짜리 구독 계약을 맺게 되죠. 요금도 쓰는 만큼이 아니라 정해진 금액을 내는 방식이라, 변 본부장은 ‘휴대폰 요금제처럼’ 최대한 많이 써야 한다고 조언했습니다.

계약 규모도 억 단위를 훌쩍 넘습니다. 팔란티어는 올해 2분기에만 100만 달러(약 13.5억 원)가 넘는 계약을 220건, 1,000만 달러(약 135억 원)가 넘는 계약을 73건 따냈어요.

한번 들이면 빼기도 어렵습니다. 2017년 뉴욕 경찰이 IBM과 함께 만든 새 시스템으로 갈아타려 하자, 팔란티어가 그동안의 분석 결과를 다른 시스템에서 읽을 수 있는 형태로 넘겨주지 않아 다툼이 벌어졌습니다. 팔란티어는 그게 자기네 지식재산이라는 입장이었고요.

AI가 좋아질수록 이 사람들이 더 필요해집니다.

AI 모델은 빠르게 좋아졌는데, 회사들이 그걸 실제 업무에 붙이는 단계에서 자주 막힙니다. 데이터는 흩어져 있고, 보안 규칙은 까다롭고, 일하는 방식은 회사마다 다르니까요. 그래서 AI 회사가 아예 사람을 보내 끝까지 붙여 주는 겁니다.

수요는 숫자로도 보입니다. 파이낸셜타임스에 따르면 2025년 1월부터 9월 사이 FDE 채용 공고가 800% 넘게 늘었습니다.

OpenAI는 아예 FDE 회사를 세웠습니다.

OpenAI는 지난 5월 ‘OpenAI Deployment Company’라는 별도 회사를 세웠습니다. 기업이 AI를 실제 업무에 들이도록 돕는 회사예요. TPG를 비롯한 투자사와 컨설팅사 19곳에서 40억 달러(약 5.4조 원) 넘게 투자를 받았고, FDE와 배포 전문가 약 150명이 일하는 컨설팅 회사 Tomoro를 인수하기로 했습니다. 숙련된 FDE를 한꺼번에 데려오려고 회사를 통째로 사는 셈이죠.

연봉도 공고에 나와 있습니다. 1달러 1,350원으로 계산하면 OpenAI 미국 FDE 기본급은 18만 5천~30만 달러, 약 2.5억~4억 원입니다. 보안 쪽 FDE는 최대 44만 5천 달러, 약 6억 원까지 적혀 있고요. 여기에 주식은 따로 줍니다.

Anthropic은 ‘창립 멤버 FDE’를 찾습니다.

Anthropic의 FDE 공고에는 창립 멤버 FDE로서 일하는 방식을 함께 만들어 갈 사람을 찾는다는 대목이 있습니다. 아직 팀을 키우는 단계라는 뜻이죠. 미국 금융 IT 회사 FIS에는 이미 Anthropic의 FDE가 들어가, 은행의 자금세탁 조사를 몇 시간에서 몇 분으로 줄이는 AI 에이전트를 함께 설계하고 있습니다.

런던 FDE 기본급은 22만 5천~25만 5천 파운드입니다. 1파운드 1,780원으로 계산하면 약 4억~4.5억 원이에요. 뉴욕의 FDE 팀장 자리는 32만~40만 5천 달러, 약 4.3억~5.5억 원입니다.

구글도 뛰어들었습니다.

구글은 클라우드와 딥마인드 양쪽에서 FDE를 뽑습니다. 딥마인드 FDE는 미국 기본급이 17만 4천~23만 2천 달러(약 2.3억~3.1억 원)이고, 보너스 목표가 15% 붙습니다. 한국어를 하는 구글 클라우드 FDE는 싱가포르 근무로 뽑고 있고요.

물론 FDE라고 다 5억을 받는 건 아닙니다. FDE Pulse에서 연봉을 밝힌 공고만 추려 보면, 기본급 중간값이 19만 달러, 약 2.6억 원 정도예요. 그래도 적은 돈은 아니죠.

서울에도 공고가 났습니다.

OpenAI는 지난 6월 서울 근무 FDE 공고를 냈습니다. 주 3일은 사무실에 나오는 방식이에요. 연봉은 적혀 있지 않습니다. Anthropic도 서울에서 고객사의 AI 도입을 처음부터 끝까지 기술적으로 이끄는 ‘Applied AI Architect’를 뽑고 있습니다.

한국에서는 너도나도 FDE입니다.

국내 기업들도 앞다퉈 FDE를 찾고 있습니다. 마키나락스는 2024년부터 FDE 조직을 운영해 왔고, 올해는 네이버클라우드가 FDE 태스크포스를 꾸리고 크래프톤이 두 자릿수 FDE 채용에 나섰습니다. LG CNS와 KT는 팔란티어 사업과 함께 FDE 조직을 만들었고요. SK AX(옛 SK C&C)는 아예 개발자 전체를 FDE로 바꾸겠다고 했습니다. 올해 4월 기준으로 개발자의 70%가 이미 FDE 역할을 하고 있고, 연말까지 100%로 만들겠다는 계획이에요. FDE 교육 과정까지 생겼습니다.

이 정도면 FDE라는 이름이 남발된다는 말이 나올 만합니다. 고객사에 들어가 개발하는 일은 한국 IT 업계에 원래 흔했거든요. 시스템통합(SI) 회사 개발자들이 오래 해 온 파견, 상주 근무가 그렇습니다. 지디넷코리아도 FDE가 기존 SI 파견, 상주 업무와 상당 부분 겹친다는 시선이 적지 않다고 짚었어요.

결국 차이는 이름이 아니라 하는 일에 있습니다. 정해진 요구사항대로 만들어 주고 끝나면 SI고, 무엇을 만들지부터 고객과 같이 정하고 실제 업무에 붙여 성과를 내는 데까지 책임지면 FDE죠. 명함만 FDE로 바꾼다고 FDE가 되는 건 아닙니다.

프롬프트만 잘 쓰면 되는 일이 아닙니다.

AI 관련 직업이라고 하면 AI에게 질문을 잘 던지는 요령부터 떠올리기 쉬운데요. FDE는 실제 서비스에 들어갈 코드를 짜는 개발자입니다. Anthropic 공고를 보면 프롬프트를 다루는 실력은 기본이고, AI가 여러 단계의 일을 알아서 처리하게 만드는 ‘AI 에이전트’를 개발해 본 경험, AI가 일을 제대로 하는지 점검하는 평가 체계를 다뤄 본 경험까지 요구합니다. 고객에게 넘기는 것도 직접 만든 에이전트와, AI를 회사 시스템에 연결하는 도구들이에요.

OpenAI 서울 공고는 성과를 재는 기준도 분명합니다. 만든 시스템이 실제 업무에 얼마나 쓰이는지, 일하는 방식이 얼마나 달라졌는지로 평가한다고 적혀 있어요.

사실 FDE 같은 일은 어느 회사에나 있습니다.

꼭 AI 회사에 들어가야 이런 일을 하는 건 아닙니다. 사내 규정을 묻는 질문에 답하는 챗봇을 만들고, 영업팀 고객 관리 시스템에 AI를 붙여 후속 연락 초안을 쓰게 하는 일. 요즘 AI를 들이려는 회사라면 어디서나 누군가는 해야 하는 일이에요. 현장의 일을 파악해서 AI를 붙이고, 실제로 돌아가게 만드는 일이죠. 직함만 없을 뿐, 이미 회사 안에서 FDE처럼 일하고 있는 분들도 많을 겁니다.

AI가 개발자를 대체하기는커녕, AI를 실제 일터에 붙이는 마지막 단계에서는 오히려 사람 몸값이 뛰고 있습니다. 코딩만 잘해서도, AI만 잘 알아서도 안 되고, 남의 회사 일을 이해해서 끝까지 돌아가게 만들 줄 알아야 하니까요.

어디서 많이 들어 본 이야기 같지 않나요? 1810년대 영국에서는 방직기계가 일자리를 빼앗는다며 직공들이 기계를 부수고 다녔습니다. 러다이트 운동이죠. 그런데 19세기 동안 천 한 마를 짜는 데 드는 일손의 98%를 기계가 대신하게 됐는데도, 공장에서 베 짜는 일자리는 오히려 늘었습니다. 천값이 싸지자 천을 찾는 사람이 훨씬 많아졌거든요.

ATM이 나왔을 때도 은행 창구 직원이 사라질 거라는 얘기가 나왔습니다. 그런데 미국에서 ATM이 퍼지는 동안 창구 직원 일자리는 줄지 않았어요. 지점 하나를 운영하는 데 드는 비용이 줄자 은행들이 지점을 더 많이 냈고, 창구 직원은 돈을 세는 일보다 고객을 상대하는 일이 더 중요해졌습니다.

AI도 비슷하게 흘러가고 있습니다. 노동시장 분석 회사 라이트캐스트에 따르면 올해 1~8월 FDE 채용 공고는 1년 전보다 10배 넘게 늘었습니다. 2023년과 비교하면 47배가 넘고요. 공고에 적힌 연봉 중간값도 18만 8천 달러(약 2.5억 원)로, 일반 소프트웨어 엔지니어(약 14만 5천 달러, 약 2억 원)보다 30% 가까이 높습니다.

AI를 다룰 줄 아는 사람 전체로 넓혀 봐도 마찬가지예요. 컨설팅사 PwC가 27개 나라의 채용 공고 10억 건 이상을 분석해 보니, AI 기술을 요구하는 일자리는 비슷한 다른 일자리보다 연봉을 평균 62% 더 내걸었습니다. 1년 전 분석 때 57%보다 차이가 더 벌어졌어요.

https://openai.com/index/openai-launches-the-deployment-company/

지난 9월 21~22일 서울 코엑스에서 SOVAC 2026이 열렸습니다. SOVAC은 사회적기업, 비영리단체, 기업 재단처럼 사회문제를 푸는 조직들이 모이는 행사인데요. 올해는 대한상공회의소의 ‘대한민국 사회적가치 페스타’와 함께 열렸고, 400여 곳이 참여했습니다.

행사 곳곳에서 AI 이야기가 나왔습니다. 큰 기술 회사보다는 현장에서 사람을 만나는 조직들이 AI를 직접 써 본 이야기가 많았어요. 그중 눈에 띄는 사례를 모아 봤습니다.

넘어진 어르신을 AI가 알아챕니다.

소셜벤처 별따러가자는 충남 예산군 어르신들의 오토바이에 센서를 달았습니다. 카메라 없이 움직임과 충격만 기록하고, AI가 이 기록을 보고 위험한 운전과 진짜 사고를 가려냅니다. 사고로 판단되면 119와 112로 연결되고요.

김경목 대표가 주목한 건, 사고로 쓰러진 어르신 곁에 사람이 없거나 휴대폰이 멀리 떨어져 있으면 도움을 부를 수 없다는 점이었습니다. 김 대표는 개막식 무대에서 지금까지 어르신 11명을 구했다고 밝혔습니다. 사고가 나고 한 시간쯤 지나서야 발견되던 것이 1분 안팎으로 줄었다고 하고요.

기술보다 먼저 필요했던 건 주민들의 신뢰였다고 합니다. 그걸 쌓는 데만 2년쯤 걸렸다고 합니다. 돈 문제도 있습니다. 11명을 구했지만 이 사업 매출은 1억 원 정도에 그쳤습니다. 반면 실시간으로 대응하고 AI를 계속 검증하는 데는 돈이 많이 듭니다. 그래도 김 대표는 “그만둘 수 없다. 신뢰를 저버릴 수가 없다”고 했습니다.

약사의 상담 기록을 AI가 정리합니다.

비영리단체 늘픔가치는 약사가 동네를 찾아가 주민들의 약 복용을 상담하는 ‘찾아가는 복약상담소’를 엽니다. 상담이 끝나면 기록을 정리하는 데도 시간이 꽤 들었는데요. 지금은 상담을 녹음하면 AI가 복약 기록을 정리해 주는 ‘케어링노트’를 씁니다. 카카오 임팩트재단의 지원으로 IT 개발자들과 함께 만든 도구입니다.

기록에 드는 시간은 3분의 1로 줄었습니다. 도입 뒤 1년 6개월 동안 상담 횟수는 10회에서 53회로, 만난 주민은 120명에서 437명으로, 함께하는 약사는 6명에서 30명으로 늘었고요.

올해 5월부터는 늘픔가치 구성원 분들께서 AI 코딩 도구로 필요한 프로그램을 직접 만들고 있습니다. 손글씨 메모를 할 일 목록으로 바꾸는 도구, 약사와 상담 시간을 맞추는 프로그램 같은 것들이요. 박상원 대표도 공모사업 마감을 놓치지 않게 알려 주는 앱을 만들었습니다. 박 대표는 “IT 개발자들이 만들어준 도구를 고쳐 쓰지 못하면 내 것이 아니라는 생각을 많이 했다”고 말했습니다.

현장의 벽도 있었습니다. 인터넷이 잘 안 되는 곳에서는 녹음이 사라지는 일이 있었고, 장애가 있는 주민을 만나면 기존 양식에 담기 어려운 내용도 있었다고 해요. 지금은 500건 넘게 쌓인 상담 기록을 AI가 분석해, 더 살펴봐야 할 사례를 신호등처럼 표시하는 기능을 만들고 있습니다.

카카오 임팩트재단도 재단 안에서 먼저 AI를 써 봤습니다. AI로 일하는 방식을 고쳐 본 적이 있는 구성원이 4월 29%에서 8월 말 65%로 늘었고, 구성원들은 하루 평균 107분을 아꼈다고 답했습니다. 이렇게 AI로 일하는 방식을 바꾸는 과정, 이른바 AX를 다섯 단계로 정리한 가이드도 누구나 볼 수 있게 공개했어요. 류석영 이사장은 AI가 비영리 조직의 문제 해결을 앞당길 수 있다며 “작은 조직일수록 그 가능성이 더 크다”고 말했습니다.

AI가 매주 안부 전화를 겁니다.

사회적기업 에이아이웍스는 남북하나재단 사업으로 북한이탈주민 약 200명에게 매주 AI 안부 전화를 겁니다. AI가 건강, 식사, 수면, 복약, 심리, 생활, 안전 일곱 가지 주제로 이야기를 나누고, 위험 신호가 보이면 바로 담당자에게 알립니다. 지난 통화 내용을 바탕으로 이어서 묻기도 하고요.

SKT와 함께하는 ‘케어비아’는 발달장애인을 돌보는 기관의 행동 기록을 AI로 자동화합니다. 12곳에 도입됐고, 기록 시간을 최대 90% 줄였다고 합니다.

목소리를 고를 수 있게 됐습니다.

NC문화재단은 말로 뜻을 전하기 어려운 사람이 그림 버튼을 눌러 말하는 앱 ‘나의 AAC’를 무료로 배포합니다. 발표를 맡은 노유란 팀장은 앱을 새로 만들면서 사용자를 만나러 다니다 들은 이야기를 꺼냈습니다. 한 중년 남성이 카페에서 AAC를 켜면 여성 목소리가 나와서 주변 사람들이 전부 쳐다본다는 거였어요.

“커피 사는 일로 시선을 받을 일은 아니잖아요. 불편해서 더는 쓰고 싶지 않았어요.”

그래서 재단은 AI 목소리를 넣어, 남녀노소 목소리 가운데 자기와 가까운 걸 고를 수 있게 했습니다. 앱을 새로 낸 뒤 2년 동안 사용자는 33만 7천 명을 넘었고, 그림 버튼은 540만 번 눌렸습니다.

대출 면접 통화를 AI로 분석했습니다.

사회연대은행은 신용점수보다 사람의 사정을 듣고 담보 없이 돈을 빌려주는 비영리 기관입니다. KAIST 연구팀이 이곳의 전화 면접 375명분을 글로 옮겨 AI로 분류해 봤더니, 43%의 통화에서 신청서에 없던 사정이 새로 나왔습니다.

그래도 판단은 사람이 합니다. 발표에서도 AI는 “심사자를 대신해 판단하지 않고” 심사 과정을 점검하는 분석 도구로 썼다고 분명히 했어요.

사회공헌 성과 평가도 AI가 초안을 씁니다.

SK가 세운 사회적가치연구원은 기업 사회공헌의 성과를 재는 AI 플랫폼 ‘SEE SV’를 처음 공개했습니다. 자료를 올리면 AI가 근거와 판단안을 먼저 내놓고, 최종 결정은 사람이 합니다. 사람이 고치고 확정한 결과는 다시 쌓여 AI를 다듬는 데 쓰이고요.

예를 들어 결식아동 도시락 사업이라면, 예전에는 ‘도시락 값 × 지원한 끼니 수’로 끝났습니다. SEE SV는 아이들이 학교 공부할 기회를 잃지 않게 된 효과까지 돈으로 따져 봅니다. 올해 말에 먼저 시험판을 열 계획이에요.

같은 자리에서 초록우산 최예숙 님은 “도달하는 것과 변화하는 것은 다릅니다”라고 했고, 현대해상 박성재 님은 “지표가 목표가 되는 순간, 그 지표는 더 이상 좋은 지표가 아닙니다”라고 했습니다.

하동에서는 300만 원으로 버스 앱을 만들었습니다.

본행사에 앞서 9월 1일 성수동에서 열린 SOVAC 살롱 ‘로컬과 AX’에서는 지역 이야기가 나왔습니다. 경남 하동에서 전통주 양조장 ‘다른파도’를 하는 이강희 대표는 서울에서 10년 동안 IT와 게임 개발자로 일하다 고향으로 내려왔습니다. 본행사 무대에도 올랐고요.

손님들이 버스 정보가 틀린다고 했답니다. 포털 지도에는 8분 걸리는 길이 1시간 20분으로 나와 있었대요. 이 대표는 석 달 동안 직접 버스를 타고 시간을 재서 버스 앱을 만들었습니다. 든 돈은 300만 원이었어요. 같은 해 경남도는 34억 원을 들여 버스 데이터를 통합하는 시스템을 만들었고요.

그런데 할머니들께 버스 시간이 정확한 게 중요하냐고 물었더니 “관심 없다, 정류장에 한두 시간 앉아서 수다 떠는 게 중요하지”라는 답이 돌아왔다고 합니다. 이 대표는 차라리 정류장에 햇빛 가리개와 에어컨을 놓는 게 나은 정책일 거라며 이렇게 말했어요.

“우리가 하지 않았던 질문은 ‘버스는 누가 타는가’였습니다.”

그가 4년 동안 함께 일한 냉동김밥 회사 이야기도 나왔습니다. 문서 1,400개와 데이터 4만 2천 개를 정리한 뒤, 600만 원짜리 카메라 대신 원래 있던 CCTV에 누구나 쓸 수 있게 공개된 AI 모델을 붙여 김밥 생산량을 실시간으로 보게 됐습니다. 이 대표는 “요술방망이는 없어요”라고 했습니다. 정말 값진 건 데이터를 옮긴 그 4년이었다는 거죠.

이 밖에도 메타크라우드는 통화 내용을 휴대폰 안에서 AI로 분석해 보이스피싱을 잡는 ‘보이스쉴드’를, 러플은 시각장애 예술가들과 함께 만든 AI 미디어아트를 소개했습니다.

AI는 알아채고, 판단은 사람이 합니다.

사례들을 모아 보니 비슷한 모양이 보입니다. AI는 기록하고, 분류하고, 위험을 먼저 알아채는 일을 맡았습니다. 늘픔가치처럼 그렇게 아낀 시간으로 더 많은 사람을 만난 곳도 있었고요. 무엇을 할지 정하는 일은 끝까지 사람 몫이었습니다.

https://socialvalueconnect.com

찾은 건 ‘반복 배열’이 달린 효소입니다.

Anthropic은 올봄 생명과학 연구팀을 꾸렸습니다. 직접 실험할 실험실도 갖췄고요. 그리고 Claude에게 거대한 DNA 데이터베이스를 뒤져 새로운 ‘역전사효소’를 찾아오라고 맡겼어요. 역전사효소는 RNA를 거꾸로 DNA로 베껴 쓰는 효소입니다.

Claude가 찾아낸 건 세균을 감염시키는 바이러스(파지)에 들어 있는 새 효소 묶음입니다. 효소 하나, 짝을 이루는 유전자 하나, 그리고 그 앞에 일정한 간격으로 늘어선 반복 서열이 한 세트예요. 이 반복 배열이 CRISPR와 닮았습니다. 연구팀은 여기에 ART(반복 배열이 딸린 역전사효소)라는 이름을 붙였습니다.

Claude 950개가 21시간 동안 일했습니다.

일은 역할을 나눠서 했습니다. 작업자 에이전트가 계획을 세워 분석하면, 감독이 검토하고 다음 과제를 엽니다. 기록 담당은 찾은 것을 공용 노트에 적고, 편집자가 보고서를 검토합니다. 이 모델들은 모두 Anthropic의 최상위 등급 모델인 Claude Mythos 5였습니다.

이렇게 Claude 약 950개가 21시간 남짓 토큰을 2억 개 넘게 썼습니다. 그동안 사람은 손대지 않았고요. 19억 개 단백질 묶음을 훑어 역전사효소 약 20만 개를 추렸고, 후보를 좁혀 보고서 19편을 냈습니다.

결정적인 순간은 ‘직접 읽기’였습니다.

그중 한 에이전트가 어떤 역전사효소 유전자 앞쪽의 DNA 2,900글자를 직접 불러와 읽었습니다. 작업 기록에 남긴 말을 옮기면 이렇습니다.

“이 구간 굉장하다. 눈으로 봐도 반복 배열이 보인다. 100~180글자 간격을 두고 여러 번 되풀이된다. CRISPR 비슷한 반복 배열이다!”

실제로 그 구간에는 16글자짜리 반복이 14번 들어 있었습니다. 연구팀이 특히 강조하는 건 이 대목입니다. 처음 맡긴 과제에는 이런 반복을 찾으라는 말이 없었어요. 이상한 걸 알아보고 파고들 만하다고 판단한 건 Claude였습니다.

확인은 사람이 했습니다.

사람은 처음 과제를 쓰고, 작업 틀을 만들고, Claude가 낸 보고서를 검토했습니다. 후보 대부분은 이 단계에서 탈락했고요. 실험실 일도 전부 사람이 했습니다.

지금까지 나온 결과는 이렇습니다. 실험해 보니 이런 반복 구간은 실제로 짧은 RNA 조각들로 만들어졌어요. 같은 효소 묶음을 가진 다른 파지의 공개 데이터를 보면, 세균을 감염시킨 지 15분 만에 반복 구간에서 나온 RNA가 파지 RNA의 최대 8%를 차지했습니다.

다만 이 효소가 정확히 무슨 일을 하는지는 아직 모릅니다. 동료 평가를 거치기 전의 논문이기도 하고요. CRISPR 연구를 이끈 MIT의 펑 장(Feng Zhang)은 이 논문을 미리 검토하고 “더 조사해 볼 가치가 있다”고 했습니다.

다시 돌리면 못 찾았습니다.

흥미로운 건 그다음입니다. 연구팀이 같은 탐색을 10번 더 돌렸는데, 대부분 이 효소 근처까지는 갔지만 앞쪽 DNA를 직접 읽은 에이전트가 없었습니다. 그래서 반복 배열은 한 번도 다시 찾지 못했어요.

그래서 따로 시험을 해 봤습니다. DNA를 직접 많이 읽을수록 반복을 알아채는 비율이 크게 올랐습니다. 반대로 DNA를 파일로 주고 분석 도구를 쓰게 하면 원본을 건너뛰는 경우가 많았어요. 이때 시도의 39%는 DNA를 200글자 이상 이어서 읽지도 않았습니다.

Claude 안에서도 신호가 튀었습니다.

연구팀은 Claude가 그 DNA를 읽는 동안 모델 안쪽도 들여다봤습니다. 반복이 나올 때마다 튀어 오르는 신호가 두 개 있었어요. 반복 구간의 글자를 뒤섞으면 이 신호가 대부분 사라졌고요. DNA만 배운 전용 AI 모델들도 같은 자리에서 반응했습니다. 다만 연구팀은 이 신호가 DNA에만 반응하는 건 아니라고 덧붙였습니다.

사람은 다 못 읽는 데이터를 AI가 읽습니다.

DNA 데이터는 사람이 다 읽을 수 없을 만큼 빠르게 쌓이고 있습니다. 이번 일은 AI가 그 더미를 대신 읽다가 “어?” 하는 순간을 만들 수 있다는 걸 보여 줍니다. 그리고 그 “어?”를 진짜 발견으로 만드는 건 아직 사람이 검토하는 단계인 듯싶습니다.

https://www.anthropic.com/news/claude-discovers-novel-enzyme-system

Haiku는 Claude의 막내입니다.

Claude는 보통 큰 순서대로 Opus, Sonnet, Haiku로 나뉩니다. Haiku가 가장 작고 빠르죠. Anthropic은 이번 Haiku를 요약, 분류, 데이터 조회처럼 짧고 반복되는 일을 많이 처리하는 데 쓰라고 소개합니다. Jev와 Decisions API가 노린 자리와 같습니다.

다만 이건 ‘말을 안 하는’ 모델이 아니라 평소처럼 글을 쓰는 보통 모델입니다. 그런데 값은 그쪽과 비슷해졌습니다.

값은 10분의 1입니다.

입력 100만 토큰당 1달러이던 게 0.1달러, 출력은 5달러에서 0.5달러가 됐습니다. 지난 글의 Decisions API와 같은 입력 값이고, 그 바탕 모델인 OpenAI GPT-6 Luna와도 같은 값입니다.

조건이 하나 있습니다. 한 번에 보내는 글이 10만 토큰을 넘으면 값이 5배(입력 0.5달러, 출력 2.5달러)가 됩니다. Anthropic은 이전 Haiku에 들어온 요청의 90%쯤이 10만 토큰 이하였다고 합니다. 그래서 평균으로 따지면 75%쯤 싸졌다고 설명하고요.

성능은 크게 올랐습니다.

Anthropic이 낸 표를 보면, 컴퓨터 화면을 보고 마우스와 키보드로 일을 처리하는 시험(OSWorld)에서 이전 Haiku 4.5는 15.7%였는데 Haiku 5.5는 72.4%입니다. 개발자처럼 터미널에서 코딩 과제를 푸는 시험(Terminal-Bench)은 0%에서 39.2%가 됐고요.

Luna 점수가 있는 항목에서는 모두 Luna보다 높았습니다. 한 단계 위인 Sonnet 5.5보다는 여전히 낮고요.

독립 평가 점수도 비슷합니다.

회사가 직접 낸 숫자라 독립 측정도 찾아봤습니다. AI 모델을 따로 시험해 비교하는 Artificial Analysis(AA)의 종합 점수에서 Haiku 5.5는 43점입니다. 이전 Haiku 4.5는 17점, GPT-6 Luna는 38점이에요. 글을 써내는 속도도 초당 243토큰으로 Luna(128토큰)의 두 배쯤입니다.

AA가 직접 돌린 시험 10개 가운데 Haiku가 앞선 건 5개, Luna가 앞선 건 2개, 나머지 3개는 같았습니다.

그런데 ‘태스크 처리’의 값은 다릅니다.

토큰 값이 같다고 일하는 비용까지 같은 건 아닙니다. AI가 답하기 전에 생각을 길게 하면 그만큼 토큰을 더 쓰거든요.

AA 종합 점수 시험을 한 번 다 돌리는 데 Haiku 5.5(max)는 출력 토큰을 4억 개 넘게 썼고, Luna는 1억 4천만 개쯤 썼습니다. 세 배쯤 더 쓴 셈이죠. 그래서 문제 하나 푸는 값은 Haiku 5.5가 0.21달러, Luna가 0.07달러입니다.

그래서 ‘Effort 조절’이 붙었습니다.

이번 Haiku에는 처음으로 얼마나 생각할지 정하는 설정(effort)이 붙었습니다. 가장 적게 생각하게 하면 AA 점수는 29점으로 내려가지만, 문제 하나에 0.02달러로 Luna보다도 쌉니다. 쓰는 토큰도 3,200만 개로 줄고요.

Anthropic 그래프에서도 같은 모양이 보입니다. 다이얼을 올릴수록 점수와 값이 함께 오릅니다. 가장 낮은 단계(Low)에서도 이전 Haiku 4.5보다 점수는 두 배 넘게 높고, 값은 훨씬 쌉니다.

어려운 판단은 오래 생각하게 하고, 쉬운 분류는 짧게 끝내게 하는 식으로 고를 수 있다는 거죠.

큰 모델 옆에서 잔심부름을 하는 식으로.

고객사 사례도 그런 쪽입니다. 금융 AI 회사 Rogo는 큰 모델이 발표 자료를 만드는 동안, Haiku 5.5가 기업 연차 보고서에서 필요한 사업부 매출 숫자를 찾아오게 한다고 합니다. 시장 조사 플랫폼 AlphaSense는 문서 질문 기능 하나로만 모델을 일주일에 800만 번쯤 부른다고 하고요. 이렇게 자주 부르는 일에서는 한 번 값이 10분의 1이 되는 게 크게 와닿겠죠.

이제 고를 건 ‘얼마나 생각하게 할까’입니다.

3주 남짓 사이에 Jev, OpenAI Decisions API, 그리고 이번 Haiku 5.5까지 나왔습니다. 판단 한 번의 값이 계속 내려가고 있죠. 이 정도 값이면 “이 일을 AI에게 맡길까”보다 “이 판단에는 생각을 얼마나 사 줄까”를 먼저 고르게 될 것 같습니다.

https://www.anthropic.com/claude-haiku-5-5

3주 만에 OpenAI도 비슷한 걸 내놨습니다. 10월 6일(미국 시간), Decisions API를 모든 개발자에게 공개 베타로 열었습니다. DevDay 때 일부에게만 먼저 보여줬던 기능이에요.

하는 일은 Jev와 같습니다.

질문과 보기를 주면 문장이 아니라 값을 돌려줍니다. 방식은 세 가지예요.

• 예/아니오: “사진 속 물건에 찌그러진 데가 있나?” → 찌그러졌을 확률

• 고르기: “이 문의는 결제, 기술 지원, 계정 중 어느 팀이 맡을까?” → 고른 팀과 보기별 확률

• 점수: “이 택배 상자는 얼마나 망가졌나? (멀쩡함 / 조금 망가짐 / 크게 망가짐)” → 몇 단계쯤인지

점수는 단계별 확률을 섞어서 내기 때문에, ‘조금 망가짐’과 ‘크게 망가짐’ 사이 어디쯤이라는 값도 나옵니다.

같은 글이나 사진에 여러 질문을 한 번에 묶어 물을 수 있는 것도 Jev와 같고요. 첫 번째 예처럼 사진을 넣을 수도 있습니다.

다른 건 만든 방식입니다.

지난 글에서 한 개발자의 평을 전했었죠.

“사실 구조화된 출력을 쓰는 평범한 LLM과 크게 다르지 않다. 다만 인터페이스가 아주 좋다.”

OpenAI가 내놓은 게 딱 그 모양입니다. 새 모델을 따로 내놓은 게 아니라, 평소엔 글을 쓰는 보통 모델 GPT-6 Luna에 ‘고르기 전용’ 창구를 하나 더 낸 거거든요.

그렇다고 겉만 바꾼 건 아닙니다. 같은 Luna를 평소처럼 부를 때보다 10배쯤 빠르다고 합니다. 같은 모델이라도 말을 시키지 않고 고르게만 하면 그만큼 빨라진다는 거죠.

값은 아직 Jev가 쌉니다.

입력 100만 토큰당 0.1달러이고, 출력은 무료입니다. Jev가 0.042달러였으니 Jev 쪽이 절반도 안 되죠.

다만 경쟁자는 OpenAI만이 아닙니다. 10월 1일에는 클라우드플레어(Clef)와 아마존(Strands Decider 2B)도 비슷한 모델을 내놨는데, 둘 다 누구나 내려받아 쓸 수 있게 공개했습니다.

조심할 점도 그대로입니다.

Jev의 ‘수학적으로 환각이 불가능하다’는 주장을 두고, ‘형식이 틀릴 수 없다’는 뜻이지 ‘판단이 맞다’는 뜻이 아니라고 짚었었는데요. OpenAI 것도 마찬가지입니다. 보기 안에서만 답하니 없는 말을 지어낼 수는 없지만, 틀린 보기를 자신 있게 고를 수는 있습니다.

지난번에 “내 데이터에서 실제로 얼마나 맞는지는 직접 재봐야 한다”고 썼는데, OpenAI 문서에도 같은 얘기가 있습니다. 어디까지 자동으로 처리하고 어디부터 사람이 볼지, 그 판단의 기준은 정답을 아는 내 서비스 예시로 직접 정하라고요. 잘못 통과시키는 것과 잘못 걸러내는 것 중 어느 쪽 손해가 더 큰지 따져서요.

결국 남는 건 그 판단 기준입니다.

지난번 글은 제번스 역설로 마무리했었죠. 판단 하나가 충분히 싸지면, 사람들이 판단을 훨씬 더 많이 하게 될 거라고요. 3주 만에 OpenAI, 아마존, 클라우드플레어까지 들어왔으니 판단은 앞으로 더 싸지고 흔해질 겁니다.

우리가 보낸 문의가 어느 팀으로 갈지, 올린 사진에 흠이 있는지 같은 판단도 점점 이런 모델이 먼저 내리게 되겠죠. 사람에게 넘어오는 건 확신도가 기준선 아래인 것들뿐이고요. 그 선을 어디에 긋느냐가, 사람이 어디까지 들여다볼지를 정하게 될 것 같습니다.

https://developers.openai.com/api/docs/guides/decisions

#AI #OpenAI #DecisionsAPI #Jev #LLM #개발

게시글 부제는 이렇습니다. “Gemini 4 Argon은 실제 소프트웨어 개발, 법률·금융 같은 기업 지식 업무, 사이버 보안 방어 분야의 복잡한 작업에서 최전선의 성능을 낸다.”

자신감의 근거는 함께 공개한 성적표입니다. GPT-6 Astra, Claude Fable 5.1, Claude Opus 5.5와 18개 시험을 나란히 놓았는데, 13개에서 1등이거나 공동 1등입니다.

그런데 같은 날, AI 모델을 독립적으로 시험하는 Artificial Analysis(이하 AA)가 매긴 종합 점수는 53점입니다. GPT-6 Astra, Claude Fable 5.1과 같은 점수이고, Claude Opus 5.5(58점)와 Sonnet 5.5(56점)보다는 낮습니다. 모델별로 보면 공동 3위입니다.

13관왕인데 공동 3위. 결론부터 말씀드리면 이번에도 둘 다 맞습니다. 어떤 시험지로, 누구와 비교했느냐가 달랐을 뿐입니다. 뭐가 좋아졌는지부터 보겠습니다.

뭐가 좋아졌나

구글 표에서 차이가 가장 큰 건 업무 쪽입니다. 법률 리서치와 문서 작성을 시키는 시험(Harvey’s Legal Agent Benchmark)에서 Argon은 19.6%로, 2등인 Claude Fable 5.1(6.7%)의 세 배 가까이 됩니다. 재피어(Zapier)가 만든 업무 자동화 시험(AutomationBench)도 51.3%로, 2등인 Opus 5.5(42.5%)보다 9점 가까이 높고요.

긴 자료를 다루는 것도 강합니다. 아주 긴 자료 속에서 연결 관계를 따라가는 시험(GraphWalks)의 가장 긴 구간에서 84.2%로 GPT-6 Astra(71.8%)보다 12점 넘게 높고, 긴 영상을 이해하는 시험(LVBench)은 91.7%로 가장 높습니다.

한 번에 쓸 수 있는 분량도 크게 늘었습니다. 출력 한도가 6만 4천 토큰에서 100만 토큰으로, 15배 넘게 커졌습니다. 여기서 토큰은 AI가 글을 읽고 쓰는 단위입니다. 대략 글자 조각이라고 보시면 되는데, 뒤에서 가격 얘기할 때 이게 중요해집니다. 구글은 “깊이 생각하며 수십만 토큰을 한 번에 써 내려갈 여유가 생기면, 어려운 문제를 한 번에 풀 수 있을 만큼 추론이 깊어진다”고 설명합니다.

구글 안에서 먼저 써본 사례도 흥미롭습니다. Argon 에이전트들이 구글 데이터센터 전반의 메모리 사용 기록을 분석해 스스로 최적화를 적용했더니, 300TiB가 넘는 메모리를 확보했다고 합니다. 동영상 디코더(libgav1)의 기존 Rust 버전에서는 최적화 코드(SIMD) 3만 2천 줄을 안전한 Rust 코드로 바꿔, 2.7배 빠르게 만들기도 했고요.

1등과 공동 3위 사이

그런데 구글 표를 자세히 보면 빈자리가 있습니다. 비교 대상이 GPT-6 Astra, Claude Fable 5.1, Claude Opus 5.5 세 모델뿐입니다. 이틀 전 나온 Claude Sonnet 5.5와 하루 전 나온 GPT-6.1 Sol은 없습니다. 발표 직전에 나온 모델이라 빠진 건 이해가 됩니다. 다만 Sonnet 5.5는 AA 종합 2위(56점)이고, GPT-6.1 Sol은 Argon보다 1점 낮은 52점을 훨씬 적은 과제당 비용으로 내는 모델입니다.

Argon이 약한 시험도 표에 그대로 있습니다. 명령어 창에서 여러 단계짜리 코딩 작업을 해내는 시험(Terminal-bench 4.0)은 57.4%로 네 모델 중 꼴찌이고, 다른 코딩 시험(FrontierSWE v2)도 55.0%로 꼴찌입니다.

AA의 시험지는 이 약점을 피해 가지 않습니다. 열 가지 시험을 묶은 종합 점수 안에 Terminal-Bench 4.0이 들어 있는데, 여기서 Argon은 57.1%로 Sonnet 5.5(63.6%), Opus 5.5(59.6%), GPT-6 Astra(59.1%)에 이어 4위입니다. 반대로 AA가 직접 돌린 업무 자동화 시험(AutomationBench-AA)에서는 77.5%로 1위입니다. 2위 Sonnet 5.5(71.3%)보다 6점 넘게 높습니다.

업무 결과물을 만들어 내는 시험(AA-Briefcase)에서도 비슷한 성격이 보입니다. 평가 기준을 통과한 비율은 65%로 AA가 잰 모델 중 가장 높았는데, 분석의 질과 결과물을 정리해 보여주는 점수는 상대적으로 낮았습니다. 요구사항은 가장 잘 챙기는데, 분석의 질과 모양새는 아쉬운 셈이죠.

정리하면 업무 자동화는 독립 평가에서도 1위이고, 코딩은 시험에 따라 엇갈립니다. 법률·금융 리서치나 긴 자료를 다루는 쪽은 아직 구글 자체 비교에서의 1위고요. 구글 표의 13관왕과 AA의 공동 3위는 같은 모델의 다른 면을 본 겁니다.

제일 눈에 띄는 건 ‘모른다’는 말

개인적으로 이번 AA 결과에서 제일 인상적인 건 따로 있습니다. 지식을 묻는 시험(AA-Omniscience)에서 Argon이 모르는 걸 지어내는 비율은 15%로, 종합 점수 45점 이상인 모델 중 가장 낮습니다. GPT-6 Astra는 51%, GPT-6.1 Sol은 54%, Claude Opus 5.5는 59%입니다.

대신 아는 것 자체가 많은 건 아닙니다. 정답률은 50%로 GPT-6 Astra(63%)보다 13점 낮습니다. 그래서 둘을 합친 점수는 비슷합니다(Argon 42점, Astra 43점). 시험에 비유하면, 아는 문제는 Astra가 더 많은데 Argon은 모르는 문제를 찍지 않고 비워 두는 학생입니다.

AI를 매일 쓰는 입장에서는 이게 꽤 중요합니다. 자신 있게 틀린 답을 내놓는 것보다 “모르겠다”가 나을 때가 많으니까요. 법률이나 금융처럼 틀리면 곤란한 일에서는 더 그렇고요.

싸 보이지만, 말이 많습니다

가격은 입력 100만 토큰에 2달러, 출력 100만 토큰에 10달러입니다. GPT-6 Astra(10달러, 50달러)의 5분의 1이고, Sonnet 5.5나 GPT-6.1 Sol과 같습니다.

그런데 이건 출시 기념 50% 할인가입니다. 할인이 끝나면 4달러, 20달러로 Opus 5.5와 같아집니다. 끝나는 날짜는 아직 발표되지 않았고, AA에 따르면 적어도 한 달은 이 가격이 유지됩니다.

그리고 Argon은 토큰을 많이 씁니다. AA 기준으로 과제 하나에 출력 토큰을 약 6만 2천 개 쓰는데, GPT-6 Astra(2만 7천 개)의 2.3배입니다. 오래, 길게 생각하는 모델이라서죠.

그래서 과제 하나를 처리하는 비용은 할인가로 1.99달러, Astra(3.26달러)의 60% 수준입니다. 단가는 5분의 1인데 비용은 5분의 3인 셈이죠. 할인이 끝나면 3.98달러로, 오히려 Astra보다 20%쯤 비싸집니다.

GPT-6.1 Sol을 옆에 놓으면 더 분명해집니다. Sol은 52점으로 Argon보다 1점 낮은데, 과제당 비용은 0.72달러입니다. 할인가로 따져도 Argon이 2.7배 넘게 비쌉니다.

그리고 아직은, 쓸 수 없습니다

마지막으로 중요한 게 하나 남았습니다. 일반 사용자는 아직 쓸 수 없습니다.

Argon은 외부에는 먼저 구글의 Fairwind 프로그램을 통해 검증된 보안 전문가들에게 풀리고 있습니다. 구글은 미국 정부가 출시 전 모델을 미리 점검하는 자발적 절차에도 참여하고 있고, 피드백을 받아 안전장치를 다듬은 뒤 유료 API 고객과 구글의 유료 구독 AI Ultra 가입자부터 열겠다고 했습니다. 날짜는 “가능한 한 빨리”입니다.

보안 쪽부터 챙긴 데는 이유가 있습니다. Argon은 소프트웨어 취약점을 스스로 찾고, 검증하고, 고치도록 훈련됐습니다. 구글이 올해 인수한 보안 기업 Wiz가 미리 써봤더니, 전 세계 병원이 쓰는 의료 소프트웨어에서 민감한 개인정보가 노출되는 심각한 취약점을 찾아냈다고 합니다. 이전 최상위 모델들이 놓친 걸요. 구글은 검증된 보안 전문가와 사내 팀에는 보안 관련 제한을 풀고 Argon을 제공한다고 밝혔습니다. 그리고 “이 수준의 능력을 안전하게 내놓으려면 단계적인 접근이 필요하다”고 적었습니다.

속도도 아직 모릅니다. AA 속도 그래프에 Argon이 빠져 있는데, 느려서가 아니라 일반에 공개된 API가 없어 아직 재지 못해서입니다. 다만 과제 하나에 쓰는 토큰이 GPT-6 Astra의 2.3배라, 속도가 같다고 쳐도 답을 다 받기까지는 더 오래 걸릴 수밖에 없습니다. 실제로 풀리고 나면 숫자가 조금 달라질 수도 있고요.

1등보다 ‘어디서’ 1등인지

그래서 Gemini 4 Argon은 1등일까요?

업무 자동화는 독립 평가에서도 1등이고, 법률·금융 리서치나 긴 자료와 긴 영상을 다루는 일은 구글이 비교한 모델들 사이에서 1등입니다. 모르는 걸 모른다고 하는 것도 지금 가장 잘하고요. 하지만 종합 점수로는 공동 3위이고, 명령어 창 코딩은 Claude와 GPT-6 Astra가 앞섭니다. 가격도 할인을 빼고 보면 싸지 않고, 속도는 아직 재지도 못했습니다.

그래도 구글이 다시 선두권에 돌아온 건 분명합니다. AA 기사 제목도 “구글이 다시 상위 3개 연구소로 돌아왔다”입니다. 직전 Pro급 모델(Gemini 3.1 Pro Preview, 30점)보다 23점이 올랐으니까요.

요즘은 새 모델이 나올 때마다 “1등”이라는 말이 붙습니다. 그런데 이번처럼 13관왕과 공동 3위가 동시에 맞을 수 있습니다. 그러니 질문을 바꿔야 할 것 같습니다. “어떤 모델이 1등이야?”가 아니라, “내가 맡길 일에서는 어떤 모델이 1등이야?”로요.

Argon이 풀리면 직접 써보고 다시 정리해보겠습니다.

https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-argon/

#AI #Gemini #Gemini4 #Google #ArtificialAnalysis #LLM

1. 24시간 일하는 AI 비서, dots

이번 행사의 주인공입니다. 목표를 주고 스스로 할 수 있는 일의 범위를 정해주면, 내가 자리를 비운 동안에도 알아서 일을 시작하는 AI입니다. dot마다 전용 컴퓨터와 브라우저가 있고, 4,000개가 넘는 앱과 연결해서 일합니다. ChatGPT는 물론 슬랙, 팀즈, 전화로도 말을 걸 수 있고요.

예를 들면 개발자에게는 버그를 고친 코드를 시연 영상과 함께 준비해 두고, 콘텐츠 제작자에게는 영상에서 쓸 만한 장면과 SNS 초안을 뽑아 두는 식입니다.

대신 무엇을 알아서 해도 되는지, 무엇은 먼저 물어봐야 하는지, 무엇은 하면 안 되는지를 사용자가 규칙으로 정합니다. 비밀번호 변경 같은 민감한 일은 사람만 할 수 있고요. Pro와 Business Premium 요금제에 첫 dot이 포함되고, 일부 지원 국가에서 먼저 쓸 수 있습니다.

2. 최상위급 성능을 5분의 1 가격에, GPT-6.1 Sol

OpenAI의 최상위 모델(GPT-6 Astra)에 가까운 성능을 5분의 1 가격에 쓰는 모델입니다. 코딩, 컴퓨터 조작, 문서 작업 같은 실무에서 특히 좋아졌다고 하고요. Plus 이상 유료 사용자와 개발자용 API에서 바로 쓸 수 있습니다.

OpenAI 발표만 그런 게 아니라, AI 모델 성능을 따로 재는 Artificial Analysis(AA)의 측정에서도 가장 높은 설정에서 52점으로 GPT-6 Astra(53점)와 1점 차이였습니다. 과제 하나를 처리하는 비용은 Astra의 4분의 1도 안 됐고요.

AA는 생각을 얼마나 깊게 할지에 따라 다섯 단계로 나눠 쟀는데, 중간 단계(medium)만 써도 48점으로 이전 GPT-6 Sol의 최고점과 같습니다. 비용은 과제 하나에 0.21달러로, GPT-6 Sol을 최고 설정으로 돌릴 때(1.05달러)의 5분의 1이에요.

3. 최대 8배 빠른 답, Ultrafast

같은 모델이 답을 최대 8배 빨리 내는 속도 옵션입니다. 가격은 기본의 6배라서, 속도가 정말 중요한 일에 쓰는 프리미엄 옵션이에요. Ultrafast를 쓸 수 있는 월 500달러짜리 Pro 요금제(사용량은 Plus의 25배)도 새로 나왔습니다.

대신 기존 월 200달러 요금제는 사용량이 Plus의 20배에서 10배로 줄었습니다. 새로 가입하면 바로 적용되고, 기존 가입자는 10월 29일까지만 지금 사용량이 유지됩니다.

4. 팀과 AI가 같이 일하는 공간, ChatGPT Space

팀원들과 ChatGPT, 그리고 dot이 한 공간에서 같이 일하는 기능입니다. 대화를 바로 문서나 슬라이드로 만들고, 여럿이 동시에 고치고 댓글을 달 수 있어요. 슬라이드는 파워포인트나 구글 슬라이드로 내보낼 수도 있습니다. 슬랙·팀즈에서 @ChatGPT로 부르거나, 회의를 녹음해 핵심과 할 일을 정리해주는 기능도 함께 나왔습니다.

5. ChatGPT 계정으로 로그인

새 비밀번호를 만들 필요 없이 ChatGPT 계정으로 Notion, Vercel 같은 다른 서비스에 로그인할 수 있게 됩니다. 상대 서비스에는 이름, 이메일, 프로필 사진만 넘어가고 대화나 메모리는 공유되지 않는다고 합니다.

그 밖에도 개발자용 코딩 AI인 Codex를 휴대폰이나 클라우드에서도 돌릴 수 있게 됐고, 말로 지시하거나 코드의 보안 구멍을 알아서 찾아 고치는 기능이 추가됐습니다. ChatGPT를 매주 쓰는 사람은 12억 명이 됐다고 하고요.

전체적으로 이번 DevDay의 키워드는 ‘맡기기’였던 것 같습니다. 물으면 답하는 AI에서, 목표를 주면 알아서 일하는 AI로요. 이제 “AI한테 뭘 물어볼까”보다 “AI한테 뭘 맡길까”를 고민할 때인 것 같습니다.

전체 발표는 여기서 보실 수 있어요.

https://openai.com/index/devday-2026-recap/

#OpenAI #DevDay #ChatGPT #AI에이전트

게시글 첫마디는 이렇습니다. “Sonnet 5보다 확실히 좋아졌고, 30% 이상 빠르며, 대부분의 작업에서 최대 30% 싸다.”

그런데 같은 날, AI 모델을 독립적으로 시험하는 Artificial Analysis(AA)는 결이 다른 숫자를 내놨습니다. 점수는 Opus 5.5 바로 다음인 2위인데, 과제 하나를 푸는 데 드는 돈은 Sonnet 5보다 50% 가까이 비싸다는 겁니다.

30% 싸다와 50% 비싸다. 같은 모델인데 숫자가 반대입니다.

결론부터 말씀드리면 둘 다 맞습니다. 차이는 AI를 ‘얼마나 오래 생각하게 했느냐’에서 나옵니다. 이번 Sonnet 5.5를 쓸 때 제일 중요한 포인트라서, 뭐가 좋아졌는지부터 차근차근 보겠습니다.

뭐가 좋아졌나

먼저 Anthropic이 공개한 성적표입니다.

명령어 창에서 여러 단계짜리 작업을 끝까지 해내는 시험(Terminal-Bench 4.0)에서 Sonnet 5는 10.3%였는데, Sonnet 5.5는 70.6%입니다. 한 등급 위인 Opus 5.5(66.4%)보다도 높습니다.

44개 직업의 실제 업무를 시켜보는 시험(GDPval-AA)은 1449점에서 1844점으로 올라, Opus 5.5(1846점)와 2점 차이입니다. 컴퓨터 화면을 보고 직접 조작하는 시험(OSWorld)은 57.0%에서 80.1%, 차트를 읽는 시험(Chartography)은 15.6%에서 61.6%로 뛰었습니다. 스크린샷만 보고 게임 ‘포켓몬스터 레드’를 끝까지 깬 첫 Sonnet이기도 하고요.

숫자 말고도 재밌는 테스트가 있었는데요. Anthropic이 내부에서 한 상장사의 분기 실적 자료와 컨퍼런스콜 녹취록, 슬라이드 양식을 주고 10장짜리 보고서를 만들게 했더니, 전문가 두 명이 첫 초안을 그대로 보내도 되겠다고 평가했다고 합니다.

가격은 그대로입니다. 입력 100만 토큰에 2달러, 출력 100만 토큰에 10달러. 입력과 출력 모두 Opus 5.5의 딱 절반입니다.

앱 빌더 Base44는 실제 앱 118개를 만들게 했더니, Opus 5와 같은 품질을 평균 3.6번 만에 냈다고 합니다. Opus 5는 7.7번이 걸렸고요. 헤지펀드 Balyasny는 금융 과제 2,441개에서 답 하나에 쓰는 토큰이 Sonnet 5의 49만 7천 개에서 12만 1천 개로 줄었다고 합니다.

한마디로 더 똑똑해졌는데, 더 적게 쓰고, 값은 그대로라는 게 Anthropic의 설명입니다.

독립 평가에서도 2위

AA는 여러 회사의 모델을 같은 시험지로 돌려서 순위를 매기는 곳입니다. 열 가지 시험을 묶은 종합 점수(Intelligence Index)에서 Sonnet 5.5는 56점으로, Opus 5.5(58점)에 이어 2위입니다. Sonnet 5(38점)보다 18점 올랐고, OpenAI의 GPT-6 Astra와 Claude Fable 5.1(각 53점)보다도 높습니다.

AA가 직접 잰 Terminal-Bench 4.0에서도 64%로, Opus 5.5와 GPT-6 Astra(각 60%)를 앞섰습니다. 업무 과제 쪽(GDPval-AA 1844 대 1846, AA-Briefcase 1811 대 1822)은 Opus 5.5와 사실상 같은 수준이고요.

여기까지만 보면 “Opus급인데 값은 절반”입니다. 그런데 AA는 다른 그래프 하나를 같이 보여줍니다.

그런데, 토큰을 역대 가장 많이 씁니다

AA 기준으로 Sonnet 5.5가 가장 오래 생각하는 설정(max)에서 과제 하나에 쓴 출력 토큰은 약 19만 3천 개입니다. AA가 지금까지 잰 모델 중 가장 많습니다. Opus 5.5(11만 9천 개)나 Sonnet 5(11만 8천 개)보다 60%쯤 많고, GPT-6 Astra(2만 7천 개)의 7배입니다.

토큰 단가가 같아도 토큰을 많이 쓰면 비싸집니다. 그래서 AA 계산으로는 과제 하나에 7.60달러, Sonnet 5(max)의 5.09달러보다 50% 가까이 비쌉니다. 앞의 ‘50% 비싸다’가 바로 이 숫자입니다.

Effort

여기서 알아야 할 게 effort(추론 강도) 설정입니다. AI에게 얼마나 오래, 깊게 생각할지 정해주는 설정인데요. Sonnet 5.5에는 low, medium, high, xhigh, max 다섯 단계가 있습니다.

시험에 비유하면, 문제를 한 번 풀고 바로 내느냐, 세 번 검산하고 내느냐의 차이입니다. 검산을 많이 할수록 점수는 오르지만 시간과 연습장(토큰)이 많이 듭니다.

AA의 ‘50% 비싸다’는 가장 오래 생각하는 max끼리 비교한 숫자입니다. AA가 다섯 단계를 모두 잰 결과를 보면 그림이 달라집니다.

같은 단계끼리 Sonnet 5와 비교해보면, low부터 xhigh까지는 Sonnet 5.5가 12~18점 높으면서 과제당 비용은 5~41% 쌉니다. 비싸지는 건 max 하나뿐입니다(7.60달러 대 5.09달러).

즉 같은 단계로 쓰면 더 똑똑하고 더 싼데, 끝까지 쥐어짜는 max에서만 비싸집니다. Anthropic의 ‘30% 싸다’와 AA의 ‘50% 비싸다’는 서로 다른 지점을 본 거죠.

특히 medium이 눈에 띕니다. Sonnet 5.5(medium)는 41점으로 Sonnet 5의 최고치(max, 38점)를 넘는데, 비용은 0.59달러로 Sonnet 5 max(5.09달러)의 9분의 1 수준입니다. Anthropic도 “여러 시험에서 low나 medium만으로 Sonnet 5의 최고 점수를 약 10분의 1 비용에 넘는다”고 했는데, AA 숫자로 봐도 비슷하게 나옵니다.

그리고 Claude 앱과 Claude Code의 기본값이 바로 이 medium입니다. 개발자용 Claude Platform (웹 채팅)은 high가 기본이고요. 따로 건드리지 않으면 대부분 ‘가성비 구간’에서 쓰게 되는 셈입니다.

재밌는 건 max가 늘 좋은 것도 아니라는 점입니다. 고친 코드를 사람 손 안 대고 바로 합칠 수 있는지 보는 시험(FrontierCode)에서, Sonnet 5.5는 xhigh가 52.1%인데 max는 46.2%로 오히려 낮았습니다. Anthropic 설명으로는 max에서 코드 검토를 여러 하위 에이전트로 쪼개 돌리다가 시간이 초과되거나, 시키지 않은 부분까지 고쳐서 감점된 경우가 있었다고 합니다. 추론을 많이 시킨다고 무조건 나아지는 건 아닌 거죠.

그럼 Opus 대신 Sonnet을 쓰면 될까

Sonnet을 max까지 쥐어짜면 Opus에 가까워지는 건 맞습니다. 그런데 그 돈이면 Opus를 쓰는 게 낫습니다.

AA 숫자로 보면 Opus 5.5는 xhigh에서 56점을 3.46달러에 냅니다. Sonnet 5.5가 같은 56점을 내려면 max로 7.60달러가 듭니다. Opus 5.5 medium(51점, 1.34달러)도 Sonnet 5.5 xhigh(52점, 2.74달러)와 점수는 비슷한데 비용은 절반이고요. 토큰 단가는 Opus가 두 배지만, 같은 점수를 훨씬 적은 토큰으로 내기 때문입니다.

사실 앞의 Anthropic Terminal-Bench 그래프에서도 비용이 겹치는 구간에서는 대부분 Opus 5.5(주황 선)가 Sonnet 5.5(파란 선)보다 위에 있습니다. Sonnet 5.5가 앞서는 건 Opus가 닿지 않는 1달러 이하 구간과 맨 끝 max 정도입니다. Anthropic 스스로도 Sonnet 5.5는 “낮은 effort에서 Opus 5.5를 가장 잘 보완한다”고 적어뒀고요.

그래서 제 결론은 이렇습니다. 평소 일은 Sonnet 5.5를 medium으로, 정말 어려운 일은 Sonnet을 max로 쥐어짜지 말고 Opus 5.5로. API로 직접 비용을 내며 쓰는 경우라면 더더욱 그렇습니다.

대신 Sonnet 5.5의 진짜 무기는 속도입니다. AA 측정으로 초당 89~143토큰을 내서, Opus 5.5(75~95토큰)는 물론 Sonnet 5(56~81토큰)보다도 확실히 빠릅니다. 빨리 주고받으며 다듬는 작업이라면 Sonnet 5.5가 훨씬 편할 겁니다.

다만 짚어둘 게 있습니다

첫째, AA 평가는 출시 전 버전으로 한 겁니다. 특정 형식(구조화된 출력)으로 답을 요청하면 답이 나빠질 수 있는 버그가 있었고, 지금은 고쳐졌다고 합니다. AA도 곧 다시 돌린다고 했으니 숫자는 조금 바뀔 수 있습니다.

둘째, 벤치마크 점수가 전부는 아닙니다. Anthropic도 “꾸준한 판단이 필요한 복잡하고 열린 일에서는 여전히 Opus 5.5가 분명히 더 강하다”고 적었습니다. 사실 지식을 묻는 시험(AA-Omniscience)에서도 Sonnet 5.5는 54%로 Opus 5.5(66%)보다 낮습니다. 대신 모르는 걸 지어내는 비율은 47%로 Opus(59%)보다 낮았고요.

셋째, 보안 쪽 제한이 생겼습니다. 해킹 관련 능력이 Opus 5 수준까지 올라와서, 위험도가 높은 보안 요청은 눈에 보이게 Sonnet 5로 넘어갑니다. 평범한 버그 수정은 괜찮다고 하고, AA 평가에서는 과제의 0.1% 정도에서 이런 전환이 있었습니다.

넷째, ‘증류 공격’을 막는 장치가 처음 들어갔습니다. 가짜 계정 수천 개로 모델의 능력, 특히 생각 과정을 대량으로 빼내 다른 모델을 만드는 걸 막는 건데요. 생각 과정이 그걸 만든 계정에 묶이기 때문에, Claude Code에서 작업 도중 계정을 바꾸는 경우엔 영향이 있을 수 있습니다. 대부분은 체감할 일이 없다고 합니다.

모델 이름보다 추론 강도

예전엔 “어떤 모델 쓰세요?”가 질문이었다면, 이제는 “어떤 모델을, 얼마나 생각하게 하세요?”까지 물어야 할 것 같습니다. 같은 Sonnet 5.5라도 low와 max 사이에 점수는 20점, 과제당 비용은 18배 차이가 나니까요.

몇 주 뒤에는 가볍고 싼 Haiku 5.5도 나온다고 합니다. 고를 수 있는 조합은 더 늘어나겠죠. 결국 중요한 건 제일 비싼 조합이 아니라 내 일에 맞는 조합입니다.

다음에 Claude를 쓰실 때, 모델 이름 옆의 effort 설정도 한 번 확인해보세요. 생각보다 차이가 큽니다.

https://www.anthropic.com/claude-sonnet-5-5

#AI #Claude #Sonnet55 #Anthropic #ArtificialAnalysis #LLM

보라색 그라데이션, 가운데 큼직한 제목, 둥근 카드 세 장, 이모지 아이콘, 그리고 “시작하기” 버튼.

기분 탓이 아닙니다. 작년 8월, 웹사이트에 스타일을 입힐 때 많이 쓰는 도구 Tailwind를 만든 Adam Wathan이 이런 글을 올렸습니다.

“5년 전 Tailwind UI의 모든 버튼을 bg-indigo-500(남보라색)으로 만든 걸 공식적으로 사과드립니다. 그 바람에 지구상의 모든 AI 생성 UI가 남보라색이 됐네요.”

“GPT-5도 ‘보라색 문제’는 못 풀었다”는 글을 인용한 건데, 조회수가 150만을 넘겼습니다. 다들 같은 걸 느끼고 있었던 거죠.

왜 다 비슷해질까

Anthropic이 작년 11월 블로그에 이유를 꽤 솔직하게 적어뒀는데요.

AI는 학습한 데이터에서 가장 흔한 쪽을 골라 답을 만듭니다. 그런데 웹에 제일 많은 디자인은 ‘어디에 둬도 무난하고, 아무도 불편하지 않은’ 디자인이죠. 그래서 방향을 안 주면 AI는 그 한가운데를 고릅니다. Anthropic이 꼽은 결과물이 Inter 글꼴, 흰 바탕 위 보라색 그라데이션, 밋밋한 애니메이션이었습니다.

100명에게 “집을 그려보세요” 하면 대부분 세모 지붕에 네모 창문, 굴뚝 하나를 그립니다. 틀린 그림은 아니죠. 그런데 누구의 집도 아닙니다.

게다가 AI가 만든 보라색 사이트를 다음 AI가 또 학습하니, 이게 돌고 돕니다. 앞의 트윗에 “이게 다들 말하던 특이점이냐”는 농담이 달린 이유죠.

그런데 저는 이유가 하나 더 있다고 봅니다. 우리가 기준을 안 줬습니다.

“깔끔하고 모던하게 만들어줘.” 다들 한 번쯤 써보셨을 주문인데, AI 입장에선 이게 “평균으로 해줘”와 같은 말입니다.

디자이너와 일할 땐 “Linear 느낌 아시죠? 그런 톤으로요” 한마디면 통합니다. 디자이너 머릿속에 이미 그 사이트가 들어 있으니까요. 다만 AI는 최소한의 리소스를 쓰면서 편향되지 않게 디자인을 만들어야 하니, 이런 정보가 없는 거죠.

그렇다고 매번 “링크 색은 #0070f3, 제목 자간은 -0.02em, 모서리는 8px…” 이렇게 수십 줄을 쓸 수도 없고, 스크린샷을 붙여넣고 “이거처럼 해줘” 하면 겉모습만 따라 할 뿐 그 뒤의 규칙까지는 못 가져갑니다.

그래서 나온 게 DESIGN.md

해법은 생각보다 단순합니다. 디자인 설명서를 글자 파일 하나로 써서 프로젝트에 넣어두는 겁니다.

구글의 AI 디자인 도구 Stitch에서 쓰던 방식인데, 구글이 올해 4월 21일 이 형식을 오픈소스로 공개했습니다. 어떤 도구에서든 쓸 수 있게요. AI에게 “이 프로젝트는 어떻게 만드는지”를 알려주는 파일이 AGENTS.md라면, DESIGN.md는 “이 프로젝트는 어떻게 보여야 하는지”를 알려주는 파일입니다.

지난번 OKF 글에서 구글이 “부족한 건 또 하나의 서비스가 아니라 포맷”이라고 했던 게 떠오르더군요. 이것도 설치하는 프로그램이 아니라 그냥 글자 파일입니다.

안에는 두 가지가 들어갑니다.

위쪽엔 값. 대표 색은 뭔지, 제목 글씨는 얼마나 크고 굵은지, 모서리는 얼마나 둥근지.

아래쪽엔 이유. 여기가 핵심인데요. 이 색을 왜 쓰는지, 어디엔 쓰고 어디엔 쓰지 말아야 하는지를 사람 말로 적어둡니다. 모든 상황을 파일에 다 적을 순 없으니, 이유를 알아야 AI가 처음 보는 상황에서도 같은 방향으로 판단할 수 있다는 거죠.

유명 사이트의 설명서를 모아둔 곳, getdesign.md

getdesign.md는 이 설명서를 유명 사이트별로 모아둔 곳입니다. AI 에이전트 개발 도구를 만드는 VoltAgent 팀이 GitHub에 awesome-design-md라는 이름으로 올렸던 모음집을 웹으로 옮긴 건데, 이 저장소의 스타가 오늘 기준 11만 8천 개를 넘었습니다.

Apple, Airbnb, Notion, Linear, Stripe, Tesla, Claude… 70개가 넘는 사이트의 DESIGN.md를 무료로 받을 수 있고, 유료 카탈로그까지 합치면 550개가 넘습니다.

하나 열어보면 이렇게 생겼습니다. Claude 사이트를 분석한 파일인데요.

맨 위에 대표 색 코랄(#cc785c), 배경 크림색(#faf9f5) 같은 값이 쭉 나오고, 미리보기 화면에서는 색마다 이름과 역할이 붙어 있습니다. “이 코랄은 주요 버튼과 강조 카드에만 쓴다”처럼요.

그리고 아래쪽 ‘해야 할 것 / 하지 말아야 할 것’을 읽어보면 좀 재밌는데요.

순백색 배경은 ‘그냥 또 하나의 AI 툴’처럼 읽힌다. 따뜻한 크림색이 차별점이다.

큰 제목에는 Inter를 쓰지 말 것.

AI 회사 사이트를 분석한 설명서에, AI스럽게 안 보이는 법이 적혀 있는 셈입니다.

써보는 법

방법은 두 가지입니다.

첫째, Claude Code나 Cursor처럼 내 컴퓨터의 프로젝트 폴더에서 작업하신다면 명령어 한 줄이면 됩니다. 끝의 이름만 원하는 사이트로 바꾸면 돼요.

npx getdesign@latest add apple

실행하면 DESIGN.md 파일이 프로젝트에 들어오고, AI에게 “UI 만들기 전에 DESIGN.md 참고해줘” 하면 끝입니다.

둘째, 명령어가 낯설거나 ChatGPT, Claude, Lovable 같은 채팅창에서 만드신다면 복사해서 붙여넣으시면 됩니다. 디자인 페이지의 미리보기 옆 DESIGN.md 버튼을 누르면 설명서 원문이 나오고, 그 옆 Copy를 누르면 본문이 통째로 복사됩니다.

Apple 기준으로 2만 9천 자쯤 되는 긴 글인데, 이게 그대로 프롬프트가 됩니다. 채팅창에 붙여넣고 그 아래 “이 디자인으로 ○○ 만들어줘” 한 줄만 덧붙이면 돼요.

실제로 해봤습니다. 설치 수 1위인 Apple 걸 복사해서, 가상의 서비스 ‘회의끝’의 랜딩페이지를 맡겨봤어요. 회의 녹음을 올리면 AI가 회의록과 할 일을 정리해주는 서비스라고 설정했습니다.

검은 메뉴 줄과 그 아래 얇은 두 번째 메뉴 줄, 가운데 정렬된 큼직한 제목, 파란 알약 버튼 두 개, 그 아래 노트북 화면까지. 누가 봐도 애플입니다.

스크롤을 내리면 밝은 판과 어두운 판이 번갈아 나오고, 문장 끝에는 작은 각주 번호까지 붙어 있습니다. 설명서 첫머리에 “모든 페이지는 밝은 판과 어두운 판을 번갈아 쌓은 제품 타일이고, 가운데 제목 아래 한 줄 문구와 작은 파란 알약 버튼 두 개”라고 적혀 있는데, 정확히 그렇게 나왔어요. (이게 제일 인상적이었습니다!) 스크린샷을 보고 따라 그린 게 아니라, 설명서를 읽고 판단한 거죠.

DESIGN.md가 없으면 어떨까

그럼 DESIGN.md 없이 만들면 어떻게 나올까요. 같은 ‘회의끝’ 페이지를 같은 내용, 같은 조건으로 네 번 더 맡겨봤습니다. 한 번은 아무것도 없이, 나머지 세 번은 Claude, Linear, WIRED의 DESIGN.md를 하나씩 넣고요. Apple 때처럼 모두 새 대화에서 시켰습니다.

먼저 DESIGN.md 없이 만든 결과입니다.

솔직히 말씀드리면, 생각보다 잘 나왔습니다. 보라색 그라데이션도 없고, 서비스 이름에서 ‘끝’ 도장을 뽑아내는 센스까지 보여줬어요. 요즘 모델이 확실히 좋아지긴 했습니다.

다만 이건 AI가 고른 취향입니다. 제가 고른 게 아니에요. 새 대화에서 다시 시키면 또 다른 취향이 나올 수도 있고요.

이번엔 DESIGN.md를 넣은 결과입니다.

같은 문장, 같은 기능 설명인데 전혀 다른 회사처럼 보입니다.

여기서도 규칙까지 따랐습니다. Claude 설명서에는 “같은 배경을 두 번 연달아 쓰지 말고, 크림 → 크림 카드 → 어두운 제품 화면 → 크림 → 코랄 → 어두운 푸터 순으로 번갈아 쓰라”는 규칙이 있는데, ② 페이지를 끝까지 내려보면 정확히 그 순서입니다.

그런데 앞의 Apple까지 다섯 장을 나란히 놓고 보니, 더 재밌는 게 보였습니다.

옷은 다 다른데, 뼈대가 똑같습니다.

제목 위 작은 라벨, 회의록 카드 모양의 제품 화면, 기능마다 붙은 작은 화면 그림, 두 장짜리 요금제 카드, 마지막에 한 번 더 나오는 가입 버튼. 녹음 카드에 ‘4분 12초’처럼 정리 시간을 초 단위로 붙여둔 것까지 다섯 장이 다 비슷합니다.

Apple처럼 설명서에 배치까지 적혀 있으면 가운데 정렬이나 번갈아 쌓는 판처럼 배치는 확 바뀝니다. 그래도 무엇을 어떤 순서로 보여줄지는 다섯 장이 거의 같았어요. 같은 내용을 줬으니 어느 정도는 당연하지만, 그 부분은 여전히 AI의 ‘평균’에서 나오고 있다는 뜻이겠죠. getdesign.md도 이걸 숨기지 않습니다. DESIGN.md는 “완성된 테마가 아니라 사전”이고, “버튼이 어떻게 생겨야 하는지는 알려주지만, 버튼을 만드는 건 여전히 당신과 에이전트”라고 적어뒀거든요.

DESIGN.md가 바꿔주는 건 옷이지, 뼈대가 아닙니다.

그리고 다섯 장 중 제 눈에 제일 오래 남은 건, 오히려 DESIGN.md 없이 만든 첫 번째 페이지의 ‘끝’ 도장이었습니다. 남의 설명서가 아니라 서비스 이름, 그러니까 내 이야기에서 나온 아이디어죠. 옷은 DESIGN.md로 맞추고, 뼈대와 이야기는 내가 채우는 것. 지금으로선 이게 제일 현실적인 조합 같습니다.

숫자로 봐도 다들 같은 고민 중입니다

getdesign.md가 11주 동안 가입자 6만 4천여 명에게 받은 응답으로 ‘State of DESIGN.md 2026’이라는 보고서를 냈는데요. 83%가 “AI가 만든 화면의 모양을 바꾸고 싶다”고 답했습니다. “지금 사이트를 더 낫게 보이게 하고 싶다” 59.4%, “마음에 드는 디자인처럼 만들고 싶다” 23.6%. 새 사이트가 아니라, 이미 만든 걸 덜 AI스럽게 만들고 싶은 거죠.

보고서의 한 줄이 이걸 잘 요약합니다. “만드는 건 더 이상 문제가 아니다. 보기 좋은 게 문제다.”

응답자 중 한국이 9.8%였다는 것도 눈에 띄었습니다. 나라 하나로 치면 미국(16%), 영국(11%) 다음 세 번째입니다.

다만 짚어둘 게 있습니다

첫째, 공식 디자인 시스템이 아닙니다. 각 회사가 만든 게 아니라 공개된 화면을 분석한 ‘참고용 해석’이고, 사이트에도 그렇게 적혀 있습니다. 로고나 브랜드 이름, 전용 글꼴은 가져다 쓰시면 안 됩니다.

둘째, 남의 디자인을 가져다 써도 되냐는 논쟁도 있습니다. 해외 유튜브에 “다른 사이트의 DESIGN.md를 베끼는 건 도둑질인가?”라는 영상이 올라왔을 정도고요. getdesign.md의 입장은 “Vercel을 베끼자는 게 아니라, 에이전트에게 출발점이 될 언어를 주자는 것”입니다. 출발점으로 쓰시고, 조금씩 내 것으로 바꿔가시는 게 맞습니다.

셋째, 보고서 숫자는 자체 집계입니다. 83%는 애초에 디자인을 바꾸고 싶어서 getdesign.md에 가입한 사람들의 응답입니다. 일반적인 비율로 읽으시면 안 됩니다.

넷째, 무료와 유료가 섞여 있습니다. 70여 개는 무료지만 나머지 카탈로그는 유료로 요청해서 받는 방식이고, 월 99달러 구독이나 내 사이트를 분석해주는 개인용 DESIGN.md(현재 1회 39달러)도 있습니다. 처음엔 무료로도 충분합니다.

그래도 방향은 분명해 보입니다

전에 2주와 2,000달러로 포토샵 대체품을 만든 사례를 다뤘었죠. 만드는 비용은 그만큼 떨어졌는데, 내 취향을 AI에게 전하는 비용은 아직 그대로였습니다.

DESIGN.md는 그 비용을 파일 하나로 줄이려는 시도입니다. getdesign.md의 표현을 빌리면, 디자이너와 몇 년에 걸쳐 쌓던 공통의 레퍼런스를 에이전트와는 2분 만에 맞추자는 거죠.

“깔끔하고 모던하게” 대신 “이 설명서대로”. 다음에 만드시는 페이지부터 한 번 바꿔보세요. 생각보다 차이가 큽니다.

https://getdesign.md

#AI #디자인 #DESIGNmd #getdesign #바이브코딩 #ClaudeCode

하룻밤에 세 모델이 나왔는데, 발표문을 읽다 보니 공통점이 하나 보였습니다. 셋 다 성능보다 가격을 먼저 말한다는 겁니다.

선물도 줬습니다. 두 회사 모두 구독자에게 아무 때나 쓸 수 있는 사용량 초기화권을 한 장씩요. 여러분들 모두 아끼지 마시고 다들 신나게 달려주시길 바랍니다.

먼저 이름부터 정리하면

두 회사 모델 이름이 헷갈리실 텐데, 급을 맞춰보면 이렇습니다.

가장 큰 모델은 Anthropic의 Fable, OpenAI의 Astra 그 아래 주력 모델이 Opus와 Sol 중간급이 Sonnet과 Terra 가장 가볍고 싼 모델이 Haiku와 Luna.

그러니까 오늘 나온 건 양쪽의 주력급(Opus 5.5, Sol)과 OpenAI의 경량급(Luna)입니다.

Claude Opus 5.5

Anthropic의 설명은 “대부분의 작업에서 Fable 5.1 수준 이상의 성능을 내면서, Opus 5보다 작업당 40% 싸게 돈다”입니다. 한 단계 위 모델의 성능을 주력 모델 가격에 준다는 거죠. 속도도 30% 정도 빨라졌다고 하고요.

심지어 요금은 AI가 읽고 쓰는 토큰 100만 개당 입력 4달러, 출력 20달러로, 이전 Opus 5보다 20% 내렸습니다.

말투 부분에서도 업데이트가 되었는데요. 이전 버전에 “말이 어렵다”는 피드백이 많았는지, 전문용어를 덜 쓰고 중요한 내용을 앞에 두도록 바꿨다고 합니다.

눈에 띄는 외부 평가도 하나 있었는데요. 평가 기관 Vals AI에 따르면, AI가 작은 모델을 하루 안에 직접 학습시키는 과제에서 공개된 기준치를 처음으로 넘은 모델이라고 합니다. 전에 다룬 “AI가 AI를 만드는” 흐름이 여기서도 이어지는 셈이죠.

그리고 이번엔 순서가 특이합니다. 보통 중간급부터 냈는데, 이번엔 Opus가 먼저 나오고 Sonnet 5.5와 Haiku 5.5는 몇 주 안에 나온다고 합니다.

GPT-6 Sol과 Luna

OpenAI 쪽은 더 직설적입니다. 토큰당 가격을 절반 이하로 내렸습니다.

Sol은 100만 개당 입력 2달러, 출력 10달러로 이전 GPT-5.6 Sol의 절반이고, Luna는 입력 0.1달러, 출력 0.5달러입니다. 이전 5.6 때 가격은 “행사가”였는데, 이번 가격은 정가라고 못박았습니다.

OpenAI는 발표 내내 “같은 일을 하는 데 얼마가 드냐”로 비교합니다. 코딩 시험에서 Sol이 Anthropic의 Fable 5와 거의 같은 점수를 5분의 1 비용으로 냈고, 컴퓨터를 직접 조작하는 시험에서는 Claude Opus 5와 비슷한 점수를 80% 싸게 냈다는 식이요.

정확도 얘기도 있습니다. 사용자들이 “틀렸다”고 표시한 실제 대화로 평가해보니 Sol의 실수가 이전 모델의 절반으로 줄었고, 코딩하면서 결과를 속이는 비율도 10.4%에서 1.3%로 떨어졌다고 합니다.

Luna는 무료 사용자도 쓸 수 있게 풀립니다.

그런데 “싸졌다”를 그대로 믿기 전에

첫째, 토큰당 가격과 실제 비용은 다릅니다.

가격표는 글자 조각 하나당 값인데, 모델마다 같은 일을 하면서 쓰는 글자 수가 크게 다릅니다. 분석 기관 Artificial Analysis 기준으로, 같은 과제를 푸는 데 Opus 5.5는 평균 11만 9천 개, GPT-6 Astra는 1만 7천 개를 썼다고 합니다. 7배 차이예요.

단가가 싸도 말이 많으면 결국 비싸집니다. 전에 DeepSeek 모델을 다룰 때도 “싸지만 말이 많다”는 게 약점이었죠. 두 회사가 모두 “작업당 비용”을 강조하는 게 그래서입니다.

한마디로, 토큰당 가격이 싸졌다고 해도 말을 너무 많이 하거나 불필요한 작업을 너무 많이 한다면 안 좋을 거고, 토큰당 가격이 비싸졌다고 하더라도 굉장히 효율적으로 동작한다면 같은 지시여도 좋을 것입니다.

둘째, 아직 서로 제대로 비교된 적이 없습니다.

OpenAI의 비교 대상은 Opus 5입니다. Opus 5.5가 90분 먼저 나왔으니 비교할 시간이 없었던 거죠. Anthropic은 자기네 Fable 5.1과 비교하고요. Opus 5.5와 GPT-6 Sol을 같은 시험대에 올린 결과는 아직 없습니다.

셋, 성능과 안전 수치는 대부분 자체 발표입니다.

Opus 5.5는 Anthropic이 “AI 발전 속도를 안전 연구 속도에 맞춰 조절하자”고 공개적으로 밝힌 뒤 처음 내는 모델입니다. 출시 전에 METR 같은 외부 기관의 평가를 받았고, 자체 행동 감사에서 역대 가장 높은 점수를 받았다고 하는데요. 한편으론 Opus 5 이후 두 달, Fable 5.1 이후 3주 만의 출시라, 속도 조절과 맞는 행보냐는 지적도 나옵니다.

OpenAI의 실수 절반, 속임수 1.3%도 자체 평가 수치고요.

그래도 흐름은 분명해 보입니다.

한 달 전만 해도 발표문 첫 줄은 “가장 똑똑한 모델”이었는데, 오늘 새벽 발표문 첫 줄은 “더 싸게, 더 빠르게”였습니다. 성능 경쟁이 비용 경쟁으로 옮겨가고 있는 거죠.

전에 Jev를 소개하면서 제번스 역설 얘기를 했었는데요. 효율이 좋아지면 오히려 총소비가 늘어난다는 것. 오늘 밤 세 모델이 모두 싸졌으니, 우리가 AI에게 일을 시키는 양은 아마 더 늘어날 겁니다.

#AI #Claude #Opus5.5 #GPT6 #OpenAI #Anthropic

그 목소리 버전이 나왔습니다. 텐센트가 9월 9일 공개한 AuK인데요. 발표 당시 텐센트가 ‘오디오판 나노바나나’라는 별명을 붙였다고 전해집니다.

텐센트의 AI 조직인 훈위안이 상하이교통대 등과 함께 만들었고, 코드와 모델을 상업적으로도 자유롭게 쓸 수 있는 조건으로 공개했습니다. 크기도 요즘 기준으론 작은 편이고요.

뭘 할 수 있냐면요.

녹음 파일을 하나 올리고, 하고 싶은 걸 말로 적으면 됩니다.

한 말을 바꿉니다. 녹음 속 “받아들이는 것”이라는 문장을 “잘 살아가는 것”으로 바꿔달라고 하면, 그 사람 목소리 그대로 그 부분만 바뀝니다. 다시 녹음할 필요가 없어요. 노래도 됩니다. 멜로디와 목소리는 그대로 두고 가사만 바꿀 수 있습니다.

말투를 바꿉니다. 같은 문장을 화난 목소리로, 들뜬 목소리로 바꾸거나, 사투리를 빼거나, 속삭이는 소리를 평소 목소리로 바꿀 수 있습니다. 중간에 들어간 숨소리나 웃음, 기침을 지우거나 오히려 넣을 수도 있고요.

소리를 다듬습니다. 높이, 빠르기, 크기를 조절하고, 잡음과 울림을 걷어냅니다.

소리를 골라냅니다. 여러 사람이 동시에 말하는 녹음에서 한 사람 목소리만 남기거나, 노래에서 목소리만 뽑아낼 수 있습니다. 재밌는 건 “무슨 말을 한 사람”인지로 지정할 수도 있다는 점이에요.

없던 목소리도 만듭니다. 몇 초짜리 목소리 샘플을 주면 그 목소리로 새 문장을 읽고, 샘플이 없어도 “20대 여성이 다정하고 조금 애교 섞인 말투로” 같은 설명만으로 목소리를 지어냅니다.

핵심은 이게 전부 모델 하나, 입력창 하나라는 겁니다.

지금까지는 도구가 다 따로였습니다. 음성 합성 따로, 잡음 제거 따로, 목소리 분리 따로요. 작업마다 다른 프로그램을 찾아 써야 했죠. AuK는 16가지 작업을 한 모델에 넣고, 전부 말로 시키는 방식 하나로 통일했습니다. 나노바나나가 사진에서 한 일을 목소리에서 한 셈입니다.

실제로 텐센트가 공개한 성적표를 보면, 이 ‘고치기’ 쪽이 제일 두드러집니다.

AuK의 음성 편집 성능(텐센트 발표 기준). 파란 막대 두 개가 AuK와 빠른 버전, 회색이 기존 편집 모델들입니다. 세 가지 시험 모두 앞섰고, 격차가 큰 곳은 두 배 가까이 납니다.

이걸 위해 모은 학습 데이터가 지시문과 음성을 짝지은 예시 약 30억 건, 195만 시간 분량입니다. 먼저 목소리 만드는 법부터 가르친 다음 고치는 법을 함께 가르쳤고, 마지막엔 사람들의 평가를 받아가며 다듬었다고 하네요.

학계에서도 바로 쓰이기 시작했습니다. 내년 음성 분야 국제 학회(ICASSP 2027)의 오디오 편집 대회에서 기준 모델로 채택됐거든요.

빠른 버전도 같이 냈습니다.

AuK-Flash라는 압축 버전인데, 원래 32번 거치던 생성 과정을 4번으로 줄여서 4.5배 빨라졌다고 합니다.

그리고 재밌는 후기가 하나 있었습니다. 한 개발자가 직접 돌려보니 처음엔 엄청 느렸는데, 알고 보니 모델 문제가 아니라 같이 딸려 온 실행 코드가 메모리를 과하게 쓰고 있었답니다. 그걸 고치니 같은 모델이 7배 빨라졌다고요.

지난번 Nari Labs 얘기와 똑같죠. 모델보다 돌리는 방식이 속도를 좌우하는 경우가 생각보다 많습니다.

다만 짚어둘 게 있습니다.

성능은 텐센트 자체 평가입니다. 그리고 같은 벤치마크를 전체로 펼쳐보면, 어디가 강하고 어디가 평범한지도 보입니다.

위 왼쪽이 목소리 만들기, 위 오른쪽이 편집, 아래가 잡음 제거/분리 성능입니다(텐센트 발표 기준).

만들기와 편집에서는 크게 앞서지만, 아래 줄 잡음 제거/분리에서는 메타와 엔비디아 등의 전용 모델들과 격차가 거의 없습니다. 텐센트도 이 부분은 “경쟁력 있는 수준”이라고만 표현했고요. 편집이 진짜 강점이고, 나머지는 같이 되는 정도로 보시면 됩니다.

한국어는 따로 확인하셔야 합니다. 공개된 예시가 영어와 중국어뿐이거든요.

생각보다 준비물도 많습니다. 따로 내려받아야 하는 보조 모델이 11GB쯤 되고, 대충 적은 요청을 알아듣게 다듬어주는 기능은 별도 AI 서비스의 API 키가 있어야 켜집니다. 기본값은 텐센트 클라우드고요. 공식 연동 도구 기준으로는 원본과 결과를 합쳐 30초까지만 한 번에 다룰 수 있습니다.

그리고 제일 무거운 얘기가 남아 있습니다.

“녹음 속 한 말을 그 사람 목소리 그대로 바꿀 수 있다”는 건, 뒤집으면 하지 않은 말을 한 것처럼 만들 수 있다는 뜻이기도 합니다. 그게 이제 누구나 무료로 쓸 수 있게 풀렸고요. 제가 본 공개 문서에서는 AI가 만든 음성임을 표시하는 장치에 대한 언급을 찾지 못했습니다.

더빙을 고치고, 오디오북 오타를 다시 녹음 없이 바로잡고, 팟캐스트를 편집하는 데는 정말 유용한 도구입니다. 동시에 “녹음이 있으면 그 사람이 한 말”이라는 오래된 전제는, 사진에 이어 목소리에서도 조용히 무너지고 있는 것 같습니다.

직접 들어보실 수 있는 데모가 공개돼 있습니다. 녹음 하나 올려서 말로 고쳐보시면, 글로 읽는 것보다 훨씬 와닿으실 거예요. https://huggingface.co/spaces/tencent/AuK

#AI #음성AI #텐센트 #AuK #오픈소스 #나노바나나

지난주 음성 AI 벤치마크에서 Nari Labs라는 이름의 한국 스타트업이 등장하였습니다.

음성 AI 성능을 실시간으로 비교하는 Coval 벤치마크에서, 9월 14일 기준 음성을 글자로 바꾸는 부문(STT) 속도 1위에 올랐습니다. 상대는 Deepgram, Soniox, Inworld AI 같은 음성 AI 전문 회사들이었고요.

이 팀 이력이 재밌습니다.

작년에 대학생 두 명이 창업했습니다. 구글 NotebookLM의 팟캐스트 기능에 반해서 비슷한 걸 만들어보려고 시중의 음성 합성 API를 전부 써봤는데, 자연스러운 게 하나도 없었다고 합니다. 그래서 직접 만들기로 했고요.

투자금은 0원이었습니다. 구글이 연구자에게 AI 전용 칩(TPU)을 무료로 빌려주는 TPU Research Cloud라는 프로그램으로 학습시켰고, Hugging Face의 무료 GPU 지원도 받았습니다. 그렇게 나온 게 Dia라는 대화용 음성 모델입니다. 두 사람이 대화하는 소리를 웃음이나 기침 같은 소리까지 섞어서 만들어내는 모델인데, 공개 직후 꽤 화제가 됐습니다. 지금까지 200만 번 넘게 내려받혔고요.

그런데 이번엔 모델을 만든 게 아닙니다.

이번에 1위를 한 건 알리바바가 공개한 Qwen3-TTS와 Qwen3-ASR입니다. 누구나 가져다 쓸 수 있는 공개 모델이죠.

Nari Labs가 만든 건 그 모델을 실제로 돌리는 엔진입니다.

본인들 문제의식이 이랬습니다. 공개 음성 모델이 이만큼 좋아졌는데 왜 시장은 여전히 폐쇄형 모델이 차지하고 있을까. 답은 모델이 아니라 돌리는 방식에 있다고 봤습니다. 기존에 AI 모델을 돌리는 데 쓰던 도구들이 글자 모델에 맞춰져 있어서, 음성처럼 여러 단계를 거치는 모델에는 잘 안 맞는다는 거죠.

그래서 Qwen3 음성 모델 전용 엔진을 따로 만들어 공개했습니다.

결과가 이렇습니다.

Coval은 음성 AI 서비스들을 미국 동부에서 실제 네트워크로 호출해 속도를 재는 독립 벤치마크입니다. 순위를 실시간으로 갱신하고요.

그런데 이 글을 쓰는 동안 순위가 바뀌었습니다.

9월 14일엔 음성을 글자로 바꾸는 쪽(STT)에서 Nari가 44ms로 1위였는데, 오늘 확인해보니 2위입니다. 1위는 Soniox가 38ms로 가져갔고요. 글자를 음성으로 바꾸는 쪽(TTS)도 2위에서 3위(71ms)로 내려왔습니다.

재밌는 건 Nari가 느려진 게 아니라는 점입니다. 음성 인식은 44ms 그대로예요. 경쟁사가 60ms에서 38ms로 확 빨라진 겁니다. 일주일 만에요. 이 판이 얼마나 빨리 돌아가는지 보여주는 장면이죠.

순위도 겉보기보다 복잡합니다. 글자를 음성으로 바꾸는 쪽 1위인 Fluxions의 모델은, Nari에 따르면 크기가 Qwen3-TTS의 6분의 1 정도라고 합니다. 여섯 배 가까이 큰 모델을 돌리면서 상위권을 다투는 셈이죠.

참고로 사람끼리 대화할 때 한 사람이 말을 마치고 다른 사람이 대답을 시작하기까지 평균 200ms 정도 걸린다고 합니다. 상위권은 전부 그 안에 여유 있게 들어오는 셈입니다.

그래도 순위보다 중요한 비교가 따로 있습니다.

9월 14일 기준으로, 알리바바가 직접 운영하는 Qwen3 TTS 공식 서비스는 첫 소리까지 692ms였습니다. 같은 시점에 Nari는 63ms였고요.

모델을 만든 회사가 돌리면 692ms, Nari가 돌리면 63ms. 똑같은 모델인데 11배 차이입니다.

같은 모델을 전용으로 돌려주는 미국의 Baseten 서비스도 101ms였습니다. 순위는 매일 바뀌어도, 누가 어떻게 돌리느냐가 이만큼 차이를 만든다는 건 그대로죠.

그럼 어떻게 11배가 됐을까요.

Qwen3-TTS는 안에서 세 단계를 거쳐 목소리를 만듭니다.

1단계, 뼈대 잡기. 다음에 나올 소리의 큰 틀을 정합니다. 2단계, 세부 채우기. 그 틀에 세밀한 소리 정보를 채웁니다. 3단계, 소리 만들기. 실제로 귀에 들리는 소리로 바꿔 내보냅니다.

Nari가 바꾼 건 크게 세 가지입니다.

첫째, 세 단계를 떼어놓고 관리자 한 명이 전부 지켜보게 했습니다.

보통은 1·2단계를 한 덩어리로 묶고 3단계만 따로 돌립니다. 정해진 순서대로, 먼저 들어온 요청부터요.

Nari는 세 단계를 완전히 떼어놓고, 순서를 정하는 관리자(스케줄러) 하나가 모든 요청의 모든 단계를 한눈에 보게 했습니다. 그래서 “어느 요청을 먼저 할지”뿐 아니라 **”그 요청의 몇 단계를 먼저 돌릴지”**까지 고릅니다.

기준은 급한 순서입니다. 소리가 곧 끊길 것 같은 요청부터 챙기고, 같은 단계를 기다리는 요청들은 묶어서 한 번에 처리합니다. 식당으로 치면 먼저 온 손님 순이 아니라 기다림이 어색해지기 직전인 테이블부터 챙기고, 같은 메뉴는 한꺼번에 볶는 셈이죠.

둘째, 매번 똑같은 반복은 한 번에 실행하게 묶었습니다.

2단계는 소리 한 조각마다 같은 계산을 정확히 15번 반복합니다. 원래는 한 번 끝날 때마다 CPU가 GPU에게 “다음 거 해”라고 지시를 내려야 했는데, Nari는 이 15번을 GPU가 멈추지 않고 한 번에 끝내는 고정 프로그램으로 묶었습니다. 지시를 주고받는 시간이 통째로 사라진 거죠.

셋째, 앞의 침묵을 잘라냈습니다.

모델이 내놓는 첫 소리에는 목소리가 시작되기 전 수십 ms의 무음이 섞여 있는 경우가 많다고 합니다. Nari는 진짜 목소리가 시작되는 지점을 찾아 그 앞을 잘라냅니다. 모델이 더 빨리 생각하는 건 아니지만, 듣는 사람 입장에선 목소리가 실제로 더 빨리 들리죠.

셋 다 모델을 새로 학습시킨 게 아닙니다. 일하는 순서와 방식을 바꿨을 뿐이에요.

그리고 같은 GPU로 더 많이 처리하니 값도 따라 내려갑니다. Nari가 밝힌 요금은 글자→음성이 100만 글자당 10달러인데, 본인들 비교로는 ElevenLabs의 대화용 모델이 5배, Cartesia가 6.5배 비싸다고 합니다.

그리고 이런 기록도 공개했습니다. 115.6시간 분량 오디오 837개를 88.6초에 처리했다고요. GPU 한 장으로, 누가 말했는지 화자 구분까지 하면서요.

전에 쓴 글과 같은 얘기가 여기서 또 나옵니다.

OpenAI의 법률 AI를 다루면서 **”모델은 안 바꾸고 주변만 갖췄더니 38.7%가 54.0%가 됐다”**고 쓴 적이 있는데요. Nari Labs가 8월에 올린 기술 블로그 한 줄이 딱 그겁니다.

“모델은 병목이 아니었다. 병목은 그 주변의 서빙 구조였다.”

같은 모델을 누가 어떻게 돌리느냐로 속도가 11배 차이 납니다. 모델 경쟁만 보면 안 보이는 싸움이죠.

다만 짚어둘 게 있습니다.

Coval 순위는 실시간으로 바뀝니다. 30분마다 갱신되고, 위에서 보신 것처럼 일주일 사이에도 순위가 달라졌습니다. 이 글을 읽으실 때쯤엔 또 다를 수 있어요. 궁금하시면 benchmarks.coval.ai에서 직접 확인하실 수 있습니다.

그리고 Nari가 자기 블로그에 올린 수치와 Coval 수치가 조금 다릅니다. Nari는 자체 실험에서 TTS 첫 소리까지 50ms 미만이 나왔다고 했는데, Coval이 네트워크 너머에서 재면 60~70ms대입니다. 측정 조건이 달라서 생기는 차이라 독립 측정치 쪽을 보시는 게 맞습니다.

정확도 순위도 Nari 블로그는 TTS 1위, STT 2위라고 했는데, 이건 9월 14일 기준 수치라 지금 시점에서는 따로 확인하지 못했습니다.

그러니 “세계에서 가장 빠른”보다는 “음성 AI 속도 벤치마크 상위권을 다투는”이 정확합니다.

그리고 지금 음성 부문은 영어 중심입니다. 한국어 성능은 따로 봐야 하고요.

그래도 이 팀 궤적이 인상적입니다.

작년엔 돈 한 푼 없이 모델을 만들었고, 올해는 남이 만든 모델을 누구보다 빠르게 돌리는 쪽으로 방향을 틀었습니다. 모델을 만드는 경쟁은 거대 기업들 판이 됐지만, 그 모델을 잘 굴리는 일에는 아직 작은 팀이 들어갈 자리가 있다는 걸 보여준 것 같아요.

그리고 그걸 한국 대학생 둘이 해냈다는 게 괜히 반갑네요.

“huge RegratulationS Indeed!”

대문자만 뽑으면 R, S, I가 됩니다. 재귀적 자기개선(Recursive Self-Improvement)이죠.

커뮤니티가 뒤집혔습니다. 곧이어 Lentils80(@Lentils80)이라는 X 뉴스 계정이 화면 캡처를 하나 올렸는데요. 개발자가 구글 AI를 가져다 쓸 때 “지금 쓸 수 있는 모델 목록 (카탈로그)”을 확인하는 화면이 있습니다. 거기에 아직 세상에 공개된 적 없는 이름이 하나 끼어 있었다는 겁니다. ‘rsi-model’로 시작하는 코드명이었고요.

배경이 받쳐준 탓도 큽니다. 지난달 로이터 보도로 구글이 1,000명 넘는 인력을 AI 자체 개선과 차세대 제미나이에 투입 중이라는 게 알려졌고, 공동창업자 세르게이 브린이 4월 전 직원 회의에서 모든 자원을 RSI에 집중하라고 촉구했다고 전해졌거든요.

그리고 이틀 뒤인 14일, 구글이 진짜로 논문을 냈습니다.

이름은 Dream-RSI입니다. 구글과 구글 딥마인드, 메릴랜드대, 버지니아대가 함께 냈고, 부제가 ‘세계 진화를 통한 재귀적 자기개선’입니다.

미리 말씀드리면, 유출설의 그 모델과 이 논문이 같은 것이라는 근거는 없습니다. 저 캡처도 검증된 게 아니고요.

발상이 이렇습니다.

AI가 어려운 문제를 풀 때는 여러 경로를 시도합니다. 이 방법으로 가보고, 안 되면 저 방법으로 가보고요. 당연히 스크립트 등을 활용해 가설 검증이 되지 않는다면 버립니다. 조건에 맞는 가설, 데이터가 있다면 그것을 집중적으로 파고요.

Dream-RSI는 그 버려지는 기록을 안 버립니다. 성공한 경로와 실패한 경로를 전부 나무 모양으로 저장해두고, 그걸 가상 실험실처럼 재활용합니다.

그러면 이런 게 가능해집니다. “어떤 경로를 먼저 가볼까”, “몇 개를 동시에 해볼까”, “언제 포기하고 다른 길로 갈까” 같은 전략을 수천 가지 시험해보는데, 모델을 다시 돌리지 않습니다. 이미 기록해둔 결과를 보고 판단하니까요.

그중 제일 효율적인 전략을 골라 실제 문제에 적용하고, 거기서 새로 쌓인 기록을 다시 실험실에 넣습니다. 이걸 반복하면서 탐색 방식 자체가 계속 좋아집니다.

여기서 중요한 구분이 하나 있습니다.

이름이 ‘자기개선’이라 AI가 스스로를 뜯어고치는 그림이 떠오르는데, 그게 아닙니다.

모델의 가중치는 건드리지 않습니다. 기초 모델도 그대로, 채점하는 평가 시스템도 그대로예요. 고치는 건 “어디를 먼저 찾아보고 언제 멈출지”를 결정하는 코드 한 겹입니다.

위는 성능, 아래는 그 성능을 내려고 시도한 횟수입니다. 성능이 오르는 동안 시도 횟수는 110에서 50까지 줄었습니다. 그러다 성능이 정체되자(E4~E5) 다시 시도를 늘립니다. 아무도 이렇게 하라고 안 가르쳤는데 스스로 찾아낸 패턴입니다.

비유하면 요리사가 바뀌는 게 아니라 레시피를 찾는 방법이 바뀌는 겁니다. 실력은 그대로인데 헤매는 시간이 줄어드는 거죠.

숫자로 보면 이렇습니다.

알고리즘 설계, 수학 최적화, GPU 코드 최적화 등 8개 과제에서 시험했는데요.

알고리즘 설계에서는 기존 방식 대비 AI를 부르는 횟수를 최대 162분의 1로 줄였습니다. 같은 모델과 조건을 쓴 고정 탐색과 비교해도 1.7배 적은 호출로 같은 결과를 냈고요.

GPU 코드 쪽에서는 비슷한 성능을 내는 데 필요한 시도를 1.79~2.43배 줄이거나, 같은 예산에서 성능을 최대 2.09배 높였습니다.

재밌는 결과도 있습니다. Dream-RSI 모델에 “이런 방향으로 찾아봐”라며 힌트를 주면 오히려 성능이 떨어진다는 점입니다.

이게 왜 중요하냐면, 요즘 경쟁이 그쪽으로 옮겨가고 있어서입니다.

구글 딥마인드는 이미 AlphaEvolve가 만든 데이터센터 스케줄링 알고리즘으로 전 세계 구글 컴퓨팅 자원의 0.7%를 추가 확보했다고 밝혔습니다. 제미나이에 쓰이는 핵심 연산을 23% 빠르게 만들어 전체 학습 시간을 1% 줄이기도 했고요. 사람이 몇 주씩 하던 GPU 최적화 작업은 며칠로 줄었습니다.

퍼센트가 작아 보이지만 구글 규모에서 0.7%는 엄청난 숫자입니다.

예전에 쓴 글이 여기서 이어집니다.

“데이터는 다 떨어졌는데 AI는 왜 더 좋아질까”에서, 답이 새 데이터가 아니라 모델이 굴러다니며 배울 환경을 늘리는 것이라고 정리했었죠.

Dream-RSI는 거기서 한 칸 더 갑니다. 환경을 자기가 실패한 기록으로 만듭니다. 논문 제목의 ‘세계 진화’가 그 뜻이고요. 헛수고가 자산이 되는 구조입니다.

다만 말을 조심해서 써야 할 것 같습니다.

대문자 세 개짜리 트윗에 커뮤니티가 뒤집힌 게 그 증거이기도 한데요. RSI라는 용어가 지금 좀 남용되고 있습니다. 개념이 명확히 정의되지 않은 채로, 기술력을 자랑하려는 쪽이나 AI가 너무 빠르다고 경고하려는 쪽이나 각자 입맛에 맞게 쓰고 있다는 지적이 있어요.

사실 ‘AGI’도 그렇죠. 다들 쓰는데 정작 무엇을 가리키는지는 말하는 사람마다 다릅니다. 단어가 커질수록 각자 원하는 그림을 거기 얹게 되는 것 같아요.

7월에 나온 서베이 논문이 이걸 정리했는데, 2024년부터 2026년까지 arXiv 논문 1,250편을 훑어서 두 가지를 갈랐습니다. 하나는 결과가 수렴하고 평가가 가능한 실무적 개선이고, 다른 하나는 끝이 열려 있는 진짜 RSI인데요. 후자는 측정한 모든 축에서 여전히 한계에 묶여 있다고 결론 냈습니다.

Dream-RSI는 분명히 앞쪽입니다. 가중치도 안 바뀌고, 평가 시스템도 고정이고, 개선되는 건 탐색 코드 한 겹이니까요.

그러니 “AI가 사람 없이 스스로 진화하기 시작했다”로 읽으면 과합니다. 정확히는 “AI가 자기 연구 방식을 고쳐서 비용을 줄이기 시작했다” 쪽이죠.

그래도 이게 작은 얘기는 아닙니다. 지금 AI 개발에서 제일 비싼 게 컴퓨팅 자원인데, 같은 자원으로 더 많이 시도할 수 있게 되는 거니까요.

그리고 무엇보다, 실패한 기록을 버리지 않는다는 발상이 오래 남네요. 사람이 일하는 방식에도 그대로 적용되는 얘기라서요.

#AI #구글 #딥마인드 #RSI #재귀적자기개선

지난 17일, OpenAI가 Astra for Law를 내놨습니다. 법률 업무에 특화된 버전인데요.

먼저 짚고 갈 게 있습니다. 새 모델이 아닙니다. 이달 초 나온 GPT-6 Astra를 법률용으로 설정한 겁니다. 모델 가중치는 손대지 않았습니다.

그럼 뭘 더했냐면 세 가지입니다.

1) 법률 검색 인덱스를 붙였습니다. 미국 판례(법원이 실제로 내린 판결문), 법령, 규정, 법원 규칙, 행정 결정을 아우르는 2억 3천만 개 이상의 URL이고, 매일 새 자료가 추가됩니다. CourtListener(미국 법원 판결문을 무료로 모아 공개하는 비영리 데이터베이스)를 운영하는 단체와 협력해서, 미국에서 공표된 선례 판례(나중 재판에서 기준으로 인용되는 판결)의 99.9% 이상을 넣었다고 합니다.

2) 작업 지침을 심었습니다. 답변 길이를 어느 정도로 할지 같은 설정값들이요.

3) 업계 도구를 연결했습니다. 26개 플러그인이 붙었는데, 크게 세 종류입니다.

기존 법률 인프라가 있습니다. 톰슨로이터(미국 변호사들이 판례 찾을 때 쓰는 대표적인 유료 데이터베이스 Westlaw의 운영사), Relativity(소송에서 수십만 건 문서를 뒤져 증거를 찾는 플랫폼), Clio(중소 로펌이 사건과 고객, 청구를 관리하는 업무 소프트웨어) 같은 것들이요.

그런데 이 목록이 좀 묘합니다.

Harvey와 Legora는 OpenAI나 Anthropic의 모델 위에 만들어진 제품입니다. 남의 모델을 빌려 법률용으로 다듬어 파는 구조죠. 이번에 OpenAI 플러그인 목록에 이름을 올렸는데, 동시에 그 OpenAI가 법률 시장에 직접 들어온 셈이기도 합니다.

앞서 Anthropic이 법률용 서비스를 냈을 때 상장된 법률 소프트웨어 회사들 주가가 떨어진 일도 있었고요. 파트너이면서 경쟁자인 관계입니다.

공개된 영상을 보면 이게 어떻게 생겼는지 감이 옵니다.

화면 아래에 ‘Innovation, Inc.’라는 이름이 붙어 있습니다. 사건이나 거래 건별로 작업 공간이 나뉘고, 그 안에 파일과 플러그인이 묶이는 구조예요. 모델 선택 칸에는 ‘GPT-6 Astra Law Ultra’라고 떠 있고요.

시키는 내용이 구체적입니다. “연결된 자료실과 회사 팩트시트를 써서 Innovation, Inc.의 S-1 조항 매핑 초안을 잡아줘. 완성에 필요한 질문이 있으면 대화창에서 물어봐.”

S-1은 미국에서 주식을 상장할 때 증권거래위원회에 내는 신청서입니다. 회사 사업, 재무, 위험 요인을 전부 적어야 해서 분량도 크고 틀리면 큰일 나는 문서예요. 조항 매핑은 그 신청서에 들어가야 할 항목들을 회사 자료와 하나씩 짝지어 정리하는 작업이고요. 로펌에서 제일 무거운 축에 드는 일입니다.

그리고 34초, 43초 걸렸다는 표시가 뜨고 결과물이 워드 파일로 나옵니다. 요약을 보면 1차 공모 여부, 신흥성장기업 지위, 이사회 구성, 재무제표 연도까지 항목별로 정리돼 있고요.

제일 눈에 띈 건 중간에 끼어 있는 한 문장이었습니다.

“이 매핑을 완성하는 데 추가로 확인할 쟁점은 없습니다. 매핑을 승인해주시거나 수정할 부분을 알려주셔야 S-1 초안 작업을 시작하겠습니다.”

다 만들어놓고 멈춰서 사람 승인을 기다립니다. 제품 안에 기본으로 들어가 있는 셈이죠. 틀리면 책임이 무거운 분야라 그렇게 만들 수밖에 없었을 겁니다.

커뮤니티가 만든 스킬 이름들도 화면에 나옵니다. 증언 준비(재판 전 증인 신문 대비), NDA 검토(비밀유지계약서 점검), 계약서 수정, 선례 검색(비슷한 과거 판결 찾기), 규제 공백 분석, 실사 검토(인수합병 전 상대 회사 뒤져보기), 이사회 의사록, 클로징 체크리스트(거래 마무리 전 확인 목록) 같은 것들이요. 로펌 주니어가 실제로 하는 일 목록에 가깝습니다.

그래서 얼마나 좋아졌을까요.

미국 법률 연구 질문 200개로 시험한 결과가 나왔습니다. 웹 검색만 쓴 GPT-6 Astra가 38.7%였는데, Astra for Law는 54.0%를 통과했습니다. 판례 질문에서는 참조 판례를 24% 더 많이 찾았고, 같은 조건에서 관련 구절을 최대 54% 더 많이 끌어왔고요.

그런데 이 숫자를 다시 보셔야 합니다.

38.7%에서 54.0%면 큰 향상이 맞습니다. 그런데 뒤집으면 46%는 여전히 틀린다는 뜻입니다. 최고 모델에 미국 판례 거의 전부를 쥐여주고도 절반을 조금 넘겼을 뿐이에요.

기사들은 “24% 더 많이 찾았다”를 제목으로 뽑는데, 실무자 입장에서 중요한 건 절대값이죠. 법률 문서에서 절반쯤 틀린다는 건 그대로 쓸 수 없다는 뜻이니까요.

그래도 제가 인상적이었던 건 다른 지점입니다.

모델을 안 바꾸고 주변만 갖췄는데 38.7%에서 54.0%가 됐다는 것.

전에 에이전트 얘기를 하면서 “요즘 성능은 모델이 아니라 그 주변 껍데기가 결정한다”고 쓴 적이 있는데요. 이 사례가 딱 그겁니다. 같은 모델인데 무엇을 찾아볼 수 있게 해줬느냐로 15%p가 갈렸어요.

법률처럼 정확한 출처가 생명인 분야에서는 이게 더 분명해집니다. 모델이 기억에서 꺼낸 판례는 틀릴 수 있지만, 검색해서 가져온 판례는 확인이 되니까요.

그리고 이 시장이 지금 굉장히 붐빕니다.

Anthropic이 올해 5월에 법률용 서비스를 냈으니 석 달 빨랐고, 구글도 지난달 법률 전문가용 기업 서비스를 확장했습니다. 대형 로펌이라는 한정된 고객을 두고 세 회사가 붙은 상황이죠.

OpenAI도 공을 들였습니다. 6월에 법률 소프트웨어 회사 창업자를 영입했고, 엔지니어를 직접 로펌에 보내 계약서 분석기나 인수합병 실사 도구를 같이 만들었다고 합니다.

다만 빠진 게 꽤 있습니다.

가격이 공개되지 않았습니다. API도 아직 안 열렸고, 지금은 선정된 로펌에만 제공됩니다.

성능 수치가 OpenAI 자체 측정입니다. 그것도 비공개 검증 세트로 잰 거라 제3자가 재현할 수 없습니다.

보안 인증도 아직입니다. 로펌 법무 담당자가 제일 먼저 물어볼 게 그건데, 9월 기준으로 관련 인증 자료가 없다는 지적이 나왔습니다.

그러니 지금은 “대형 로펌 대상 제한 공개” 단계로 보는 게 맞겠습니다. 국내에 들어오려면 한국 판례와 법령을 다루는 인덱스가 따로 필요할 테니 시간이 더 걸릴 거고요.

그래도 방향은 분명해 보입니다. 모델을 새로 만드는 경쟁에서, 각 직업이 실제로 쓰는 자료와 도구에 얼마나 잘 연결되느냐의 경쟁으로 넘어가고 있는 것 같습니다.

#AI #OpenAI #법률AI #AstraforLaw #리걸테크

그런데 9월 15일, 정반대 물건이 나왔습니다. 아예 말을 안 하는 모델입니다.

이름은 Jev, 만든 곳은 TypeSafe AI라는 스타트업입니다. 2년간 아무것도 공개하지 않다가 이번에 처음 내놨고요. 창업자는 OpenAI에서 ChatGPT 개발에 참여했던 연구자입니다.

무슨 뜻이냐면요.

우리가 아는 AI는 글자를 하나씩 이어 붙여 문장을 만듭니다. “파이썬은 누가 만들었나요?”라고 물으면 “파이썬은 네덜란드 출신의 프로그래머인 귀도 반 로섬(Guido van Rossum)이 만들었습니다. — ”라고 한 글자씩 써 내려가죠.

Jev는 그걸 안 합니다. 선택지를 주면 고르고, 확률을 붙여 돌려줍니다. 그게 전부예요.

예를 들어 고객 문의가 들어왔을 때 “이건 환불 문의인가, 배송 문의인가, 불만 접수인가”를 물으면 “환불 문의, 확신도 0.91” 같은 값이 나옵니다. 문장이 아니라 값이요.

그리고 여러 질문을 한 번에 동시에 처리합니다. 순서대로 하나씩이 아니라요.

이름에 두 가지가 담겨 있습니다.

회사는 이 부류를 ‘시스템 1 모델’이라고 부릅니다. 대니얼 카너먼의 『생각에 관한 생각』에서 따온 건데요. 사람 사고를 두 갈래로 나눈 개념입니다. 시스템 1은 빠르고 직관적인 판단, 시스템 2는 느리고 신중한 추론이죠. 지금까지 AI 경쟁이 시스템 2 쪽이었다면, 이건 반대편을 노린 겁니다.

모델 이름 Jev는 경제학자 제번스에서 왔습니다. ‘제번스 역설’로 유명한 사람인데요. 효율이 좋아지면 오히려 총소비가 늘어난다는 얘기예요. 석탄을 아끼는 기관이 나오자 석탄을 더 많이 쓰게 됐다는 관찰에서 나왔고요.

이름에 회사의 의도가 있습니다. 판단 하나가 충분히 싸지면, 사람들이 판단을 훨씬 더 많이 하게 될 거라는 것.

숫자가 그걸 뒷받침합니다.

비슷한 작업에서 40~200배 빠르고, 입력 100만 토큰당 0.042달러입니다. 출력은 무료고요. 회사가 든 비교로는 Claude Fable 5.1의 기본 입력 요금이 100만 토큰당 10달러니까, 238분의 1 수준입니다.

발표 시연으로 둠(Doom) 게임을 플레이하는 걸 보여주기도 했습니다. 빠른 판단을 연속으로 내려야 하는 일이니까요.

그리고 제일 화제가 된 주장이 이겁니다.

“수학적으로 환각이 불가능하다.”

이게 무슨 뜻인지 정확히 짚고 가야 합니다. 오해하기 딱 좋은 문장이거든요.

Jev는 글자를 만들지 않습니다. 그러니 없는 판례를 지어내거나, 존재하지 않는 함수 이름을 그럴듯하게 만들어낼 수가 없습니다. 형식이 깨질 일도 없고요. 애초에 여러분이 준 선택지 중에서 고르는 것뿐이니까요.

하지만 틀린 선택지를 고를 수는 있습니다. 그것도 자신 있게요.

즉 “형식이 틀릴 수 없다”는 뜻이지 “판단이 맞다”는 뜻이 아닙니다. 이 구분을 놓치면 완전히 다른 물건으로 이해하게 됩니다.

어디에 쓰라는 걸까요.

회사가 든 예가 이렇습니다. 들어온 요청을 분류하기, 데이터에 점수 매기기, 그리고 다른 AI가 내놓은 결과를 검사하기요.

마지막이 눈에 띄었습니다. 전에 AI가 쓴 코드를 어떻게 검토할지 정리하면서 “사람 눈보다 확실한 건 기계다, 못 속이는 관문을 두라”고 썼는데요. 그 관문을 아주 싸게 만들어주겠다는 제안인 셈입니다.

요청이 들어올 때마다 검사하고, AI가 뭔가 만들 때마다 확인하는 게 가격 때문에 불가능했다면, 238분의 1이 되면 얘기가 달라지니까요.

확신도를 쓰는 방법도 제안합니다. 확신이 높으면 자동 처리, 애매하면 확인 요청, 불확실하면 사람에게 넘기는 식으로요.

다만 공개 안 된 게 많습니다.

학습 방법을 RLCD라는 이름으로 부르는데, 무엇을 하려는 건지만 설명했을 뿐 평가할 만큼 공개하지 않았습니다. 보상 함수도, 구조도, 학습 절차도, 확신도를 어떻게 계산하는지도 안 밝혔습니다.

확신도 숫자 자체도 조심해서 봐야 합니다. 확률 분포가 한쪽에 몰려 있으면 확신이 높다고 보는 방식인데, 몰려 있다는 것만으로 그 판단이 믿을 만하다는 근거는 안 됩니다. 내 데이터에서 실제로 얼마나 맞는지는 직접 재봐야 하죠.

그리고 어떤 개발자는 이렇게 평했습니다. “사실 구조화된 출력을 쓰는 평범한 LLM과 크게 다르지 않다. 다만 인터페이스가 아주 좋다.” 기술이 새롭다기보다 쓰기 편하게 만든 것이라는 시각이고요.

부하가 걸렸을 때 속도가 유지되는지, 지금 가격이 계속 갈지도 아직 모릅니다. 지금은 사전 체험 단계고요.

그래도 방향은 흥미롭습니다.

다들 더 똑똑하고 더 말 잘하는 AI를 만드는 동안, 사람이 안 읽을 판단을 대신 내려주는 모델을 따로 만들겠다는 거니까요. AI가 사람과 대화하는 도구에서 소프트웨어 안에 박히는 부품으로 옮겨가는 흐름 같기도 하고요.

제번스 역설이 맞다면, 싸진 만큼 우리가 AI에게 물어보는 횟수가 훨씬 늘어날 겁니다. 그게 좋은 일일지는 또 다른 얘기고요.

#AI #Jev #TypeSafe #LLM #개발

9월 14일부터 V4-Pro를 호출하면 전부 이 Flash 모델로 넘어갑니다. 요금도 Flash 기준으로요.

이름부터 “작은 모델”인데 그게 플래그십을 밀어낸 겁니다.

숫자를 보니 이유를 알겠더군요.

552B짜리 모델인데, 실제로 도는 건 8B입니다.

정확히는 이렇습니다. 우리가 넣은 질문을 읽을 때는 8B, 답을 쓸 때는 16B를 씁니다. 나머지는 그냥 잠들어 있어요. 전문가를 잔뜩 모아두고 매번 필요한 몇 명만 깨우는 방식입니다.

그런데 읽을 때와 쓸 때 다르게 쓴다는 게 이번의 핵심입니다.

생각해보면 말이 됩니다. 긴 문서를 읽는 일과 답을 지어내는 일은 난이도가 다르거든요. 읽는 건 훑으면 되지만 쓰는 건 머리를 써야 하니까요. 그래서 읽는 쪽은 싸게, 쓰는 쪽은 두 배로 배분한 겁니다.

그리고 싸고 효율적인 이유가 따로 있었습니다.

토큰 하나당 890바이트.

이게 무슨 말이냐면요. AI는 대화가 길어질 때 앞부분을 매번 다시 읽지 않습니다. 읽어둔 걸 메모로 저장해두고 그걸 참고해요. 문제는 대화가 길어질수록 이 메모가 계속 커진다는 겁니다. 그리고 그 메모를 들고 있는 비용이 곧 요금이 됩니다.

에이전트를 오래 돌릴 때 돈이 많이 드는 이유가 여기 있었던 거죠.

V4.1 Flash는 이 메모를 직전 세대의 4분의 1로 줄였습니다. 디스크에 오래 보관하는 쪽은 8분의 1이고요. DeepSeek은 이게 가격을 내릴 수 있었던 이유라고 밝혔습니다.

실제로 가격이 이렇게 됐습니다.

한 번 읽은 내용을 다시 쓸 때 100만 토큰당 0.003달러, 처음 읽는 내용은 0.15달러, 답을 쓰는 건 0.60달러입니다. 위안화 기준으로 직전 모델보다 각각 60%, 33%, 11% 내렸다고 하고요.

첫 번째 숫자가 중요합니다. 에이전트는 같은 맥락을 계속 반복해서 읽거든요. 그 비용이 전체에서 큰 몫을 차지하는데, 메모를 줄였더니 거기가 확 떨어진 겁니다.

나머지 사양도 정리하면 이렇습니다. 컨텍스트는 100만 토큰, 이미지도 바로 이해하고, 45조 토큰으로 처음부터 새로 학습시켰습니다. 그리고 가중치가 MIT 라이선스로 공개돼 있습니다. 상업적으로 자유롭게 쓸 수 있다는 뜻이죠.

Artificial Analysis에서도 지능 지수는 40점을 받았고, 출력 속도도 초당 221 토큰으로 기존 V4 Pro보다 약 2.4배 높은 수준입니다.

전에 “데이터가 다 떨어졌는데 AI는 왜 계속 좋아지나”를 다룬 적이 있는데요. 그때 답이 “새 데이터가 아니라 학습 환경”이었잖아요.

이번 건 또 다른 답입니다. 모델을 키운 게 아니라 구조를 바꿨습니다.

읽을 때와 쓸 때 쓰는 양을 다르게 하고, 기억해둘 메모를 압축하고, 그래서 같은 돈으로 더 오래 굴릴 수 있게 만든 것. 성능 경쟁이 아니라 운영 비용 경쟁으로 무게가 옮겨간 느낌입니다.

에이전트를 오래 돌리는 게 당연해진 시대라 그런 것 같기도 하고요.

작은 모델이 자기네 플래그십을 은퇴시킨 게 그 증거인 것 같습니다.

https://deepseek.com/en/news/deepseek-v4-1-flash/

지난 11일 판교 42dot (현대차그룹의 자율주행 소프트웨어 회사) 본사에서 현대차그룹이 자율주행 미디어 데이를 열었습니다. Atria AI를 탑재한 차량이 서울 도심을 운전자 개입 없이 주행하는 영상을 처음 공개했고요. 유튜브에 올라온 지 며칠 만에 조회수가 꽤 나오고 있습니다.

영상 구성이 마음에 들었습니다.

세 종류인데요.

첫째는 경영진과 개발 리더가 직접 타고 판교에서 경부고속도로, 올림픽대로, 동작대교를 지나 숭례문과 광화문까지 가는 영상입니다.

둘째는 원테이크 주행 영상 세 편으로, 출근 시간 강남, 대형 차량 많은 잠실, 비 오는 판교를 각각 담았습니다. 재생 속도 외에는 편집을 안 했다고 밝히고 있습니다.

셋째가 제일 흥미로웠습니다. 엣지 케이스 10가지를 모았는데, 갓길에 세워둔 차 피하기, 갑자기 끼어드는 차, 비보호 좌회전, 혼잡 구간 보행자 인식, 이면도로 마주 오는 차 같은 것들입니다. 시험용으로 만든 상황이 아니라 실제 골목길에서 벌어지는 일들이죠.

그런데 진짜 얘기는 영상이 아니라 그 뒤에 있었습니다.

현대차그룹이 이번에 내세운 핵심 개념이 ‘데이터 플라이휠’입니다. 차에서 데이터를 모으고, AI를 학습시키고, 검증하고, 개선된 모델을 다시 차에 넣어 새 데이터를 얻는 선순환이요.

여기서 제가 예전에 쓴 글이 생각났습니다. “학습할 데이터는 다 떨어졌을 텐데 AI는 왜 더 좋아질까”에서, 답이 새 데이터가 아니라 모델이 굴러다니며 배울 환경을 늘리는 것이라고 정리했었죠.

현대차 발표에 거의 같은 문장이 있었습니다. “자율주행 경쟁의 본질은 결국 학습 속도의 경쟁”이라는 겁니다. 얼마나 많은 데이터를 모으느냐보다, 그걸 얼마나 빨리 학습과 검증과 성능 개선으로 연결하느냐가 경쟁력이라고요.

구체적인 방법도 공개했는데 이 부분이 재밌었습니다.

어려운 상황만 골라냅니다. 전체 주행 데이터에서 AI가 헤매는 장면을 자동으로 선별해 집중적으로 학습시킵니다. 데이터가 많다고 좋아지는 게 아니라 어려운 데이터를 찾아내야 좋아진다는 발상이죠.

위험한 상황은 가상으로 재현합니다. 실제 주행 데이터를 3차원으로 재구성한 다음, 도로에서 반복하기 어렵거나 위험한 상황을 가상에서 만들어 반복 평가합니다. 사고 날 뻔한 장면을 안전하게 백 번 돌려보는 셈입니다.

24시간 개발합니다. 한국과 미국 거점을 연결해서, 한쪽 업무시간이 끝나면 다른 쪽이 데이터 수집과 이슈 분석을 이어받습니다.

차가 스스로 기록합니다. 급가속이나 급제동, 불안정한 차간 거리처럼 시스템이 이상을 감지하거나 운전자가 자율주행을 해제하면 그 순간의 데이터를 자동으로 남깁니다. 사람이 일일이 분류하지 않아도 배울 거리가 모이는 거죠.

현재 데이터 수집 전용 차량 40여 대를 주야간으로 돌리고 있고, 연말에는 국토부와 함께 광주에서 레벨 4 실증도 시작한다고 합니다.

그리고 VLA입니다.

예전에 중국 Qwen 팀의 자율주행 논문을 소개한 적이 있는데요. 시각 정보와 언어 추론, 차량 행동을 하나의 모델로 묶는 VLA 기술이었습니다. 그때 “우리나라는 어디쯤일까” 싶었는데, 마침 답이 나왔습니다.

42dot이 VLA 기반 차세대 자율주행 개발에 착수했다고 공식화했습니다. 기존 방식이 주행 입력을 바로 차량 행동으로 연결한다면, VLA는 거기에 언어로 상황을 이해하고 추론하는 과정을 더합니다.

공개된 영상에 그게 나옵니다. 차가 차선을 변경하는 장면에서, 왜 그렇게 판단했는지를 문장으로 화면에 띄웁니다.

Qwen 논문 소개할 때 제일 재밌었던 게 이 부분이었거든요. AI가 “여우가 나타나 감속하세요” 같은 판단 근거를 말로 내놓는 것. 같은 발상이 국내 회사에서도 나온 겁니다.

왜 굳이 언어를 끼워 넣느냐면, 주행 데이터만으로는 배우기 어려운 희귀한 상황에 대응하기 위해서라고 합니다. 대규모 사전 학습으로 얻은 일반 상식을 끌어다 쓰는 거죠.

논리적인 ‘말’로 판단한다면, 이상하게 반응했을 때 왜 그렇게 대응했는지를 추적할 수 있고, 교정할 수 있는 여지가 있다는 뜻입니다.

엔비디아 협업으로 2028년 상반기에 레벨 2+, 하반기에 레벨 2++를 양산차에 넣고, 자체 개발한 Atria AI 기반 레벨 2++는 2029년 하반기가 목표입니다.

참고로, 레벨 2+는 고속도로에서만 자율주행을 활성화 되는 것이고, 레벨2++는 안전하다고 판단되는 일부 도로 한정하여 자율주행을 활성화 해주는 방식입니다. 레벨 2++는 소프트웨어를 통해 점진적으로 활성화 구역이 넓어질 것으로 기대됩니다.

검증된 외부 기술로 속도를 내면서 핵심은 내재화하는 투 트랙이고요. VLA는 지금 시뮬레이션 검증 단계고, 올해 말부터 내년 초 사이에 실차 테스트에 들어갑니다.

냉정하게 볼 지점도 있습니다.

이번에 공개된 건 전부 회사가 제공한 자료입니다. 원테이크라고 밝혔지만 어떤 주행을 고를지는 회사가 정했고, 독립적인 검증은 없습니다.

그리고 레벨 2++는 공식 등급이 아닙니다. 국제 기준에는 레벨 2 다음이 레벨 3인데, 그 사이를 표현하려고 업계가 쓰는 말이에요. 여전히 운전자가 책임지는 단계입니다.

양산 시점도 3년 뒤입니다. 그 사이 경쟁 상황이 어떻게 바뀔지는 아무도 모르고요.

그래도 국내 기업이 도심 주행 영상을 편집 없이 공개하고, VLA 개발을 공식화한 것은 분명한 진전으로 보입니다.

영상은 현대자동차그룹 유튜브 채널에서 보실 수 있습니다. 강남편, 잠실편, 판교편이 각각 2~4분이라 부담 없고, 미디어데이 전체 영상도 올라와 있습니다.

https://www.youtube.com/@HyundaiLive

#자율주행 #현대차 #42dot #AtriaAI #VLA #AI

찾아보니 구글이 이미 내놨습니다. ARTEMIS라는 도구인데요. 오픈소스고, 스타가 3,900개가 넘습니다.

한 줄 소개가 이렇습니다. “AI 비서와 테스트 도구가 진짜 폰을 사람처럼 쓰게 하자.”

데모가 인상적이었습니다. 구글 지도를 열어서 운전 경로를 여러 개 설정하고 총 소요시간을 계산한 다음, 유튜브로 넘어가서 콜드플레이 노래를 틀더군요. 앱을 넘나듭니다. 사람이 폰을 쓰는 방식 그대로요.

시키는 방법도 그냥 말로 합니다. “설정 열어서 배터리 찾아서 지금 몇 퍼센트인지 알려줘” 같은 식이요.

성능 숫자도 있습니다. 구글 리서치가 만든 AndroidWorld라는 벤치마크에서 99.1% 을 기록했다고 합니다. 앱 20종 이상, 여러 단계를 거쳐야 하는 과제 100개 이상으로 구성된 테스트이구요. (심지어는 사람도 80%네요!!!)

어떻게 화면을 보는지가 재밌었습니다.

세 가지를 섞어 씁니다. 화면이 제공하는 구조 정보를 읽고, 거기 없으면 글자를 인식하고, 그것도 안 되면 그냥 화면을 그림으로 봅니다. 게임 화면처럼 구조 정보가 아예 없는 경우가 있는데, 그럴 때도 버튼 위치를 찾아낼 수 있다는 뜻이죠.

그리고 지난번 Playwright 얘기와 이어지는 지점이 여기 있습니다. 좌표를 사람이 지정해주는 게 아니라 스스로 찾습니다. 화면이 바뀌어도 알아서 다시 찾고요.

이걸 Claude Code나 Codex에 그대로 붙일 수 있습니다.

최신 변경사항을 앱으로 빌드해서 연결된 기기에 설치하고, 테스트 계정으로 로그인 화면을 열어서 로그인 후에 예상 못 한 팝업이 뜨는지 확인하고, 마지막 화면 스크린샷을 돌려줘.

빌드하고, 설치하고, 실행하고, 눌러보고, 확인하고, 사진 찍어 보내는 것까지 한 문장입니다.

모드가 두 개인 것도 흥미로웠습니다.

빠른 쪽은 한 단계에 3~5초입니다. 화면 보고 바로 누르는 방식이라 단순 반복에 적합하고요.

느린 쪽은 한 단계에 15~40초 걸립니다. 대신 계획을 세우는 역할, 실행하는 역할, 검증하는 역할이 나뉘어 있습니다. 행동하기 전에 목표를 한 번 더 확인하고, 막히면 그걸 기록해두고 다른 길을 찾습니다. 100단계가 넘는 긴 작업을 버티려고 그렇게 만든 거예요.

앞서 긴 작업이 왜 무너지는지 다룬 적이 있는데, 그 문제를 정면으로 겨냥한 설계로 보입니다.

설치는 어떨까요.

저장소를 받아서 시작 스크립트 하나만 돌리면 됩니다. 필요한 도구들을 알아서 깔고, 브라우저에 관리 화면을 띄워줍니다. 거기서 폰 화면을 실시간으로 보면서 시킬 수 있고, 지나간 실행을 영상으로 다시 돌려볼 수도 있습니다.

실제 폰이 없어도 됩니다. 에뮬레이터, 그러니까 컴퓨터에 띄우는 가상 폰으로도 돌아갑니다. 오히려 그쪽이 편할 수 있고요.

다만 솔직하게 말씀드릴 게 있습니다.

Playwright는 에이전트한테 “설치해줘” 한마디면 끝인데, 이건 그보다 준비할 게 많습니다. 안드로이드 개발 환경이 있어야 하고, 폰이나 에뮬레이터를 연결해야 합니다. 때문에 리소스(컴퓨터 메모리 등) 도 조금 더 무거울 것으로 예상됩니다.

그리고 첫 실행 때 폰에 작은 도우미 앱이 설치됩니다. 화면 구조를 읽기 위한 건데, 폰 안에서만 동작하고 밖으로 아무것도 보내지 않는다고 명시돼 있습니다. 언제든 지울 수 있고요. 그래도 내 실제 폰에 뭔가 깔리는 게 찜찜하시면, 에뮬레이터로 시작하시는 게 마음 편합니다.

그래서 안드로이드 앱을 실제로 만들고 계신 분에게만 권합니다. 웹만 하신다면 Playwright로 충분하고요.

앞으로 iOS와 Android Studio 연동도 계획에 있다고 합니다. 음성으로 시키는 것도요.

https://github.com/google/artemis

#AI #Android #테스트자동화 #ClaudeCode #오픈소스

이틀 전 (9/13), Reddit에 r/vibecoding 채널에 한 글이 올라왔습니다.

GPT-6 Astra로 포토샵을 대체할 수 있는 프로그램을 만들었다구요.

이름은 Proton Studio로 출시했습니다. 반응을 보니 거의 미쳤습니다.

먼저 뭐가 되는지부터 보면, 생각보다 갖출 건 갖췄습니다. 레이어와 그룹, 마스크, 조정 레이어, 스마트 오브젝트, 레이어 효과가 다 있고요. PSD 파일을 레이어를 유지한 채로 열고 다시 저장할 수 있습니다. Liquify로 이미지를 변형하고, Curves로 밝기와 대비를 조정하고, 포토샵 단축키도 상당수 그대로 씁니다.

그리고 전부 내 컴퓨터에서 돌아갑니다. 업로드 단계도, 대기열도, 계정도 없습니다. 피사체 선택이나 배경 제거 같은 기능까지 로컬에서 처리하고요. macOS, Windows 11, Linux 전부 지원하고 완전 무료입니다. 유료 등급도, 잠긴 기능도 없다고 밝히고 있습니다.

그런데 제가 흥미로웠던 건 결과물보다 만든 과정이었습니다.
(주목할 만합니다!)

개발자가 다섯 단계로 정리해뒀는데요.

먼저 포토샵의 모든 기능에 대해 딥 리서치를 돌렸습니다. 코딩부터 시작한 게 아니라 조사부터 시작한 거죠. 그 보고서를 gpt6-astra에 최대 연산 수준으로 넣어서 개발 계획을 짜게 했고요. 그 계획을 읽고 피드백을 주면서 고쳤습니다. 그러면 돌아가긴 하지만 불안정한 첫 버전이 나오고, 그 다음부터는 버그를 찾아 고치는 사이클을 반복했습니다.

여기서 사람의 역할이 에디터를 직접 써보고 문제를 설명하는 것으로 줄어들었다는 게 핵심입니다. 손으로 쓴 코드가 한 줄도 없다고 합니다.

토큰 비용은 약 2,000달러가 나왔습니다.

계산이 안 맞죠. 포토샵 구독료 몇 년치입니다.

그런데 출시 첫 24시간 만에 활성 사용자 170명이 붙었습니다. 개발자는 이걸 “170개의 아낀 라이선스”로 환산하더군요.

애초에 돈이 목적도 아니었습니다. 이전 회사를 7자리 금액에 매각했고 지금은 인수한 회사에서 월급을 받고 있다고 합니다. 앞으로도 무료로 유지하고 프리미엄 요금제는 없을 거라고 했고요. 다만 나중에 After Effects 같은 더 큰 프로그램까지 손대게 되면 그때는 일회성 요금을 받을 수도 있다고 합니다.

목표는 “AI의 속도로 발전하는 에디터”를 만드는 거라고 하네요. 요즘 Adobe가 자고 있다는 말도 덧붙였고요.

이 주장을 상징적으로 보여준 사건이 출시 당일에 있었습니다.

사용자들이 다운로드 링크를 못 받는다는 불만이 터졌는데, 원인이 재밌었습니다. 모든 방문자가 서버의 같은 프록시 주소 하나로 집계되는 바람에, 시간당 20통이라는 제한이 전체에 한꺼번에 걸린 거였습니다.

문제 파악부터 배포까지 약 5분이 걸렸고, 이것도 AI 에이전트가 처리했습니다. 제한이 방문자마다 따로 적용되도록 다시 쓴 거죠.

만드는 것도 AI, 터진 걸 고치는 것도 AI. 실시간으로 “AI 속도”를 증명한 셈입니다.

다만 회의적인 시각도 만만치 않습니다.

데모 영상에 나오는 건 기본 편집과 이미지 위에 텍스트 얹기 정도입니다. 파일 가져오기와 내보내기는 보여주지 않았고요. 개발자 본인도 원본보다 안정성이 떨어진다고 인정했는데, 뒤집어 보면 지금 테스트를 하고 있는 건 실사용자들이라는 뜻입니다.

시장 상황도 녹록지 않습니다. 무료 편집기 시장은 이미 포화 상태예요. Affinity는 하나로 통합되면서 완전 무료가 됐고, Photopea는 한 사람이 만들어 광고로 운영되고 있고, GIMP와 Krita, Paint.NET도 건재합니다. Pixelmator Pro는 Apple이 사갔고요. 2주 만에 만든 클론이 수십 년간 발전한 도구들과 겨뤄야 합니다.

그리고 회의론자들이 짚는 지점이 하나 더 있는데, 이게 제일 날카로웠습니다.

포토샵은 닫혀 있고, GIMP는 열려 있습니다. 이런 편집기를 만들어내는 모델들이 학습한 건 결국 GIMP의 코드라는 거죠. “포토샵을 대체했다”기보다 “GIMP를 다시 조립했다”에 가깝다는 지적입니다.

그래도 저는 이 사례가 계속 남습니다.

2주와 2,000달러로 만든 물건이 수십 년짜리 제품과 같은 링에 올라섰다는 것. 그게 이겼다는 뜻은 아니지만, 링에 올라가는 비용이 이 정도로 떨어졌다는 건 분명하니까요.

혹시 써보실 분들을 위해 두 가지만 말씀드리면, 다운로드는 운영체제를 고르고 이메일로 링크를 받는 방식입니다. 그리고 본인이 안정성을 인정한 만큼, 중요한 원본 파일로 바로 작업하시는 건 권하지 않습니다. 사본으로 먼저 열어보세요.

https://tenzen.studio/photon/

그런데 다들 비슷한 지점에서 멈추실 겁니다. AI가 코드를 쫙 뽑아놓고 “적용할까요?”라고 묻는데, 읽어봐도 뭐가 맞고 뭐가 틀린지 모르겠는 거죠. 그래서 그냥 수락을 누릅니다. 잘 돌아가니까요.

그리고 주변에서 들리는 얘기로는 개발자들의 리뷰 시간이 크게 늘었다던데, 그럼 이렇게 리뷰 없이 넘어가도 되는 건지 의문이 들죠.

우선 결론부터 얘기드리자면, 개발자들도 지금 못 하고 있습니다.

개발자 22,000명, 약 4,000개 팀을 추적한 2026년 조사를 보면 코드 리뷰에 쓰는 시간 중앙값이 441.5% 늘었습니다. 아무 리뷰 없이 병합된 코드는 31.3% 늘었고요. 어느 팀도 리뷰 정책을 바꾼 적이 없는데도요. 그냥 밀려드는 양을 감당하지 못하게 된 겁니다.

더 선명한 비교도 있습니다. PR 810만 건을 AI 사용 여부로 갈라서 본 벤치마크인데요. AI로 만든 PR은 크기가 157줄에서 400줄 이상으로 커졌고, 리뷰어가 열어보기까지 약 200분이던 게 16시간 이상으로 늘었습니다. 그리고 30일 안에 병합되는 비율이 84.5%에서 32.7%로 떨어졌습니다. AI로 만든 PR의 3분의 2는 한 달이 지나도 안 들어간다는 뜻이죠.

그러니 목표를 “개발자처럼 완벽하게 읽기”로 잡으면 실패합니다. 개발자들이 주로 하는 예방책들을 실행하는 것이 중요하다고 생각하는데요.

다행히 AI가 틀리는 방식에는 패턴이 있습니다.

하나. 정상 경로는 잘하고, 예외에서 무너집니다.

AI는 학습 데이터에 흔한 걸 잘 만듭니다. “로그인 성공하면 토큰 발급” 같은 정상 흐름은 훌륭해요. 그런데 비밀번호가 틀렸을 때, 네트워크가 끊겼을 때, 값이 비어 있을 때 같은 예외 처리는 데이터에 훨씬 적게 나옵니다. 그래서 거기서 무너집니다.

둘. 물어본 것만 보고 만듭니다.

우리 시스템에 이미 비슷한 기능이 있는지, 예전에 왜 그렇게 정했는지를 AI는 모릅니다. 그래서 똑같은 기능을 또 만듭니다. 실제로 중복 코드 블록이 2023년 대비 81% 늘었고, 2024년은 복사 붙여넣기가 리팩터링을 넘어선 첫 해였다고 합니다.

셋. 그럴듯해 보이는 게 제일 무섭습니다.

컴파일도 되고 테스트도 통과하는데 미묘하게 틀린 경우요. 한 분석에서는 AI 코드에 권한이 잘못 열리는 경로가 사람 코드보다 322% 많았다고 합니다.

그래서 실제로 할 수 있는 게 이런 것들입니다.

1. AI에게 AI를 검토시키세요 — 단, 다른 방에서

같은 대화창에서 “이거 괜찮아?”라고 물으면 자기가 쓴 걸 변호합니다. 새 대화를 열고 코드만 붙여넣은 다음 비판해달라고 하세요. 실무자들이 실제로 쓰는 방법이고, 모델을 아예 다르게 가져가는 분들도 있습니다.

질문은 이런 것들이 좋습니다. 여기서 뭐가 잘못될 수 있나. 이미 있는 기능을 또 만든 건 아닌가. 이 예외는 왜 무시했나.

저는 프로젝트별로, 테스트 할 수 있는 QA 리스트들을 에이전트에게 작성해달라고 하고, 수정사항이 있을 때마다 에이전트에게 검토 요청을 맡깁니다.

특히, ‘Playwright’라는 프레임워크를 추천드립니다.

설치는 어렵지 않습니다. 에이전트에게 ‘Playwright’ 설치해달라고 지시하면 끝이구요. Playwright는 Microsoft가 개발한 프레임워크인데요.

마치 사람이 코드만 보고 문제가 있는지 없는지 판단하는 것보다, 완성된 결과물(구현된 웹사이트 디자인 등등)만으로 문제 추론을 하는 것이 유리하듯이, AI도 똑같습니다.

매번 수정사항이 있을 때마다, QA를 Playwright로 검수해달라고 꼭 지시해보세요. 훨씬 결과물이 좋아지더라구요.

조금 더 부지런한 AI라면, 디자인을 보고 뭔가 소구할 것이 더 있을 때 추가 수정을 할 수도 있습니다.

2. 못 속이는 관문을 두세요

사람 눈보다 확실한 건 기계입니다. 린터, 타입 검사, 테스트를 걸어두면 AI가 그걸 통과할 때까지 알아서 고칩니다. 설정은 한 번만 하면 되고요.

물론, 이건 최소한 코드가 동작하는지, 문법 오류가 없는지에 대한 최소한의 테스트입니다. AI 자원을 쓰지 않고 할 수 있는 최소한의 테스트이죠.

3. GitHub을 쓰세요 — 언제든 되돌릴 수 있게

조금씩 자주 저장하세요. 리뷰가 부실해도 되돌릴 수만 있으면 사고가 아니라 번거로움으로 끝납니다.

그 도구가 GitHub입니다. 개발자들이 쓰는 거라 어렵게 느껴지실 텐데, 오히려 비개발자에게 더 필요합니다. 하는 일은 단순해요. 바뀔 때마다 그 시점을 통째로 저장해두고, 언제든 그때로 돌아갈 수 있게 해줍니다. 무료고요.

Claude Code 같은 도구는 이미 이걸 다룰 줄 압니다. “지금까지 작업 저장해줘”라고 말하면 알아서 해요. 명령어를 외우실 필요가 없습니다.

그리고 이게 리뷰와 직결됩니다. 뭐가 바뀌었는지만 따로 보여주는 화면이 있거든요. 파일 전체를 읽는 게 아니라 추가된 줄과 지워진 줄만 색깔로 표시됩니다. 코드를 읽지 못해도 얼마나 바뀌었는지는 보입니다. 버튼 하나 고쳐달라고 했는데 파일 일곱 개가 알록달록 뜨면, 그게 신호예요. 왜 이만큼 바뀌었는지 물어보시면 됩니다.

다만 두 가지는 조심하셔야 합니다.

저장소는 반드시 비공개(private)로 만드세요. 공개가 기본값인 경우가 있습니다.

그리고 API 키나 비밀번호가 한 번 저장되면 나중에 지워도 기록에는 남습니다. 실제로 자주 일어나는 사고예요. AI가 코드 안에 키를 그대로 박아두는 경우가 있으니, 저장 전에 키처럼 생긴 긴 문자열이 섞여 있는지 한 번 훑어보세요.

그래서 저 같은 경우에는, AI가 읽지 않고 활용할 수 있는 시크릿 파일 (.env)를 활용하거나, GitHub 저장소 또는 AWS에서 제공하는 시크릿 키 저장소 기능을 사용합니다. AI가 읽지 않고, 코드에서만 참조할 수 있도록 하는 구조를 설계하는 것입니다.

아직은 들여다봐야 하는 단계입니다.

AI가 많이 좋아진 건 맞습니다. 저도 매일 쓰고, 없으면 못 하겠다 싶을 때도 많고요. 그런데 전부 맡겨도 되는 단계는 아직 아닙니다. 그렇다고 사람을 추가로 더 쓰기보다는, AI를 쓰는 사람이 조금 더 관심을 갖고 공부를 부지런히 끊임없이 해야 할 단계라고 생각합니다.

앞에서 본 숫자들이 그 얘기였어요. 리뷰 없이 병합되는 코드가 늘어난 건 AI가 좋아져서가 아니라 사람이 감당을 못 하게 돼서였고, AI로 만든 PR의 3분의 2는 한 달이 지나도 안 들어갑니다. 잘 만드는 것과 믿고 맡길 수 있는 것은 아직 다릅니다.

언젠가는 정말 다 맡겨도 되는 날이 오겠지만, 그게 오늘은 아닌 것 같습니다.

#AI #코드리뷰 #바이브코딩 #ClaudeCode #개발

지난 10일, OpenAI가 GPT-Live-1을 API로 열었습니다. ChatGPT 음성 모드에 먼저 들어갔던 그 모델인데요, 이제 개발자 누구나 자기 앱에 붙일 수 있게 된 겁니다. 유튜브 발표 영상을 보고 나서 “그래서 지금까지의 음성 AI랑 뭐가 다른 거야?” 하는 질문이 남더라구요.

이번 발표의 포인트는 “AI가 말하면서 동시에 듣는다”인 것 같습니다. 지금까지의 음성 AI는 무전기에 가까웠습니다. 한쪽이 말을 끝내야 다른 쪽이 말할 수 있죠. GPT-Live-1은 전화 통화 방식입니다. 말하는 도중에 끼어들어도, “아 네네” 하고 맞장구를 쳐도, 옆사람과 잠깐 딴 얘기를 해도 대화가 끊기지 않습니다. (이걸 ‘풀듀플렉스’라고 부릅니다.)

첫째, 구조가 통째로 바뀌었습니다. 기존 음성 AI는 ‘받아쓰기 → 생각하기 → 읽어주기’ 세 단계를 릴레이로 넘기는 방식이었습니다. 바통을 넘길 때마다 시간이 걸리고, 말의 타이밍이나 맥락이 조금씩 새어 나갔죠. GPT-Live-1은 듣기와 말하기를 한 모델이 처리합니다. 한 고객사는 이 구조로 바꾸면서 코드가 80% 줄고, 2만 3천 줄을 지웠다고 합니다.

둘째, ‘입’과 ‘두뇌’를 분리했습니다. 대화는 GPT-Live-1이 맡고, 복잡한 판단이나 예약 처리, 검색 같은 일은 뒤에 붙인 두뇌 모델(GPT-6 Astra 등, 타사 모델도 가능)에 넘깁니다. 두뇌가 일하는 동안에도 대화는 계속됩니다. 응대 직원이 고객과 얘기를 이어가면서 담당 부서에 처리를 넘기는 것과 비슷합니다. 기존 Realtime API가 한 모델로 듣기/생각/말하기를 다 하던 것과는 반대 방향이죠.

셋째, 수치로 보면 ‘대화의 리듬’이 좋아졌습니다. 끼어들기, 맞장구, 잠깐의 침묵을 얼마나 자연스럽게 다루는지 재는 평가(Full Duplex Bench)에서 전작 GPT-Realtime-2.1보다 30%p 올랐습니다. 언어 학습 앱 Speak에서는 학습자가 생각하는 동안 튜터가 끼어드는 일이 약 80% 줄었고, Yelp는 전화 예약 처리율이 눈에 띄게 좋아졌다고 합니다. 다만 ‘음성 에이전트 평가 1위’는 Astra와 조합했을 때 얘기라, GPT-Live-1 혼자의 성적은 아닙니다.

넷째, 가격은 분당 $0.05입니다. 시간당 3달러 정도인데, 이건 ‘입’ 값이고 ‘두뇌’ 비용은 별도입니다. 어떤 두뇌를 붙이느냐에 따라 총비용이 크게 달라지겠죠. 목소리는 12종이 새로 추가됐고, 일반 전화선에도 바로 연결할 수 있습니다.

결국 GPT-Live-1의 핵심은 ‘더 똑똑해진 음성 AI’가 아니라, 사람이 대화하는 리듬을 그대로 따라올 수 있게 됐다는 데 있는 것 같습니다.

이제 음성 AI의 기준도 ‘얼마나 정확히 알아듣나’를 넘어, 얼마나 자연스럽게 주고받나, 그리고 입과 두뇌를 얼마나 자유롭게 조합할 수 있나로 이동하고 있습니다.

발표 페이지에 기간 한정 데모가 열려 있는데, 일부러 카페나 길거리 같은 시끄러운 곳에서 써보라고 권하더라구요.

조만간 또 CS 시장의 큰 바람이 불 것 같습니다!

#OpenAI #GPTLive1 #음성AI #VoiceAgent

지난주(9/3) 생명과학 분야의 최상위 학술지, Cell에 초파리 수컷의 중추신경계 전체를 그린 신경지도가 실렸습니다. 뉴런 하나하나가 어느 뉴런과 시냅스 몇 개로 이어져 있는지를 전부 그린 지도로, 학계에서는 커넥톰(connectome)이라고 부릅니다. 이번 지도는 단순히 뉴런들의 연결 구조가 아니라, 양쪽 시엽, 그리고 척수에 해당하는 배쪽신경삭까지 한 마리의 신경계를 통째로 담고 있어요. 뉴런 166,700개, 시냅스 연결 1억 2,500만 개, 세포 유형 11,710가지. 재넬리아(HHMI)가 2008년에 시작했으니 18년 걸렸고, 케임브리지, MRC LMB, 구글 리서치가 같이 했습니다.

숫자보다 ‘전체’라는 말이 중요합니다. 지금까지 초파리 신경지도는 2020년 반쪽 뇌(뉴런 2만 5천 개), 2024년 암컷 뇌 전체(약 14만 개), 2024년 수컷 몸통 신경처럼 부위별로 따로 나왔어요. 이번엔 목 부분의 신경 다발이 끊기지 않고 이어져 있어서, 눈으로 들어온 신호가 다리 근육까지 어떤 경로로 가는지 한 개체 안에서 끝까지 추적할 수 있습니다.

만드는 방법은 이렇습니다. 뇌를 전자현미경으로 얇게 썰어 수백만 장을 찍으면, 단면마다 뉴런들의 잘린 흔적이 회색 얼룩처럼 남습니다. 이 얼룩이 위아래 장에서 어느 뉴런으로 이어지는지 전부 맞춰야 3D 배선도가 되는데, 사람 손으로만 하기엔 양도 너무 많고, 단면 사진으로 위아래 사진과 비교해 3D 지도를 만들어야 하니, 너무 어렵습니다.

여기서 구글 리서치의 flood-filling network가 나옵니다. 포토샵의 ‘페인트 통’ 도구를 딥러닝으로 만든 거라고 보면 됩니다. 뉴런 안쪽에 점 하나를 찍으면 3D 합성곱 신경망이 “옆 픽셀이 같은 뉴런인가”를 판단하며 가지 끝까지 영역을 채워 나가고, 하나가 끝나면 다음 점으로 넘어갑니다. 예전처럼 세포막 경계를 한꺼번에 예측하고 조각을 이어 붙이는 방식보다 ‘뉴런 두 개가 붙거나 하나가 끊기는 오류’가 훨씬 적어서, 2019년 첫 초파리 뇌 자동 재구성부터 이번 지도까지 이 계열 기술이 쓰였습니다.

그래도 마지막은 사람입니다. AI가 채운 뉴런을 사람이 하나하나 검증하고 이름을 붙이는데, 구글 블로그가 “형태를 검증하고 주석 다는 데만 수년의 인력이 든다”고 쓸 정도예요.

여기서 궁금한 점이 하나 생깁니다. 완벽한 설계도가 있다면, 그걸 그대로 돌리면 뇌가 작동할까요? 하다못해, 시각, 촉각 등의 정보들을 어떻게 주입해주고, 뇌가 인터랙션 하게 만들까요?

마침 ChatGPT-6 Astra가 출시하여, Astra로 시도해본 사람이 있습니다. NeuroCraft Fly라는 프로젝트인데, 이 신경지도를 뉴런 166,700개, 방향성 엣지 25,582,938개 그대로 마인크래프트에 올리고 파리 한 마리에 연결했어요. 플레이어가 붓으로 파리를 문지르면 입력이 신경망으로 들어가고, 활동을 읽어낸 판독기가 몸 동작 프로그램을 골라 파리가 그루밍을 합니다. 접근, 몹, 붓질, 공격, 먹이, 빛 여섯 가지 입력이 있고, 화면 구석 HUD에는 LC4(다가오는 물체를 감지하는 시각 뉴런)와 TTMn(점프 근육을 움직이는 운동뉴런)의 활동값이 실시간으로 찍힙니다.

아직 코드나 모드가 공개되진 않았습니다.

다만 여기서도 하나는 확실하게 짚고 넘어가더라구요. 이 파리가 진짜 초파리 뇌처럼 생각해서 움직이는 건 아니라고, 깃허브 첫 화면에 못 박아 뒀습니다. 붓질이 신경망에 어떻게 전달되는지, 신호가 어떻게 번지는지는 개발자가 세운 가정이고, 신경망의 어느 부분을 읽을지도 사람이 골랐고, 그루밍 같은 몸동작은 미리 만들어 둔 애니메이션이에요. 신경망은 그중 어떤 동작을 틀지 고르는 스위치 역할에 가깝습니다.

그래서 스스로 검증 실험을 붙였습니다. 배선을 무작위로 뒤섞은 파리와 감각 입력을 아예 끊은 파리에게 똑같이 붓질을 해보는 거예요. 배선을 엉망으로 섞어도 반응이 같다면 그 반응은 배선도 덕이 아니라는 뜻이니까요. 실제로 일부 반응은 섞어도 남았고, 입력을 끊어도 기본으로 돌아다니는 동작은 나온다고 적어뒀습니다. 반대로 탈출 회로를 건드려 봤더니, 거대섬유라 불리는 명령 뉴런에서 점프 근육을 움직이는 뉴런까지 신호가 평소의 35배로 뛰며 네 단계를 타고 번졌는데, 이건 실제 초파리의 탈출 반사 경로와 모양이 같습니다. 그런데도 “생물학적 검증은 아니다”라고 다시 못을 박고, 신경망으로 조종한 결과가 단순 컨트롤러보다 오차가 95배 컸다는 것까지 그대로 써놨어요.

정리하면 신경지도는 말 그대로 지도이지 엔진이 아닙니다. 어느 뉴런이 어느 뉴런에 시냅스 몇 개로 붙어 있는지, 예측된 신경전달물질이 무엇인지까지는 알지만, 신호가 실제로 얼마나 세게 어떤 타이밍으로 넘어가는지, 신경조절물질이 상태에 따라 무엇을 바꾸는지는 지도에 없습니다. 마인크래프트 파리가 그루밍을 하는 건 그 빈칸을 사람이 가정으로 채웠기 때문이고, 그걸 숨기지 않은 게 이 프로젝트의 미덕이에요.

그럼 다음 벽은 뭘까요. 구글은 제브라피시 전뇌와 쥐 뇌 일부를 다음 목표로 잡았고, 사람은 뉴런 860억 개라 아직 손을 못 댑니다. 초파리 쪽은 이제 지도가 다 있으니, 남은 건 그 위에서 실제로 무엇이 흐르는지 채워 넣는 일입니다. 참고로 데이터는 전부 공개라, R 패키지(natverse/malecns) 몇 줄로 뉴런 하나를 불러와 3D로 그려볼 수 있습니다!

#Connectome #Drosophila #Neuroscience #Janelia #Minecraft #AI

요즘 Claude Code나 Codex를 쓰다 보면, ‘Ultra’ 또는 ‘Ultracode’ 라는 effort(추론 수준)로 작업할 경우, 에이전트가 능동적으로 서브 에이전트들을 띄워 작업을 병렬적으로 진행합니다. 그런데 문득 궁금해졌습니다. 이거 진짜 더 좋은 걸까, 아니면 그냥 여러 개 띄우니까 뭐라도 되는 것처럼 보이는 걸까.

입장에 따라 업계에서는 의견이 나뉘는 것 같더라구요.

작년에 Anthropic이 멀티 에이전트 리서치 시스템을 공개했습니다. Lead 에이전트가 하위 에이전트 서너 개를 병렬로 띄우고 결과를 합치는 구조인데, 자체 평가에서 단일 에이전트보다 90.2% 앞섰다고 밝혔습니다.

같은 해 6월, Cognition (Devin이라는 에이전트 모델 개발사)은 정반대 제목의 글을 냈습니다. “멀티 에이전트를 만들지 마라.” 단일 스레드로만 가고 컨텍스트 압축은 별도 모델에 맡기라는 입장이었어요.

여기까지는 그냥 의견 차이로 보였는데, 두 가지생각에 집중해야 합니다.

첫째, Anthropic의 글 안에서도 단점이 같이 언급되어 있었습니다.

같은 글에서 두 가지 단점을 더 언급하는데요. 그 시스템이 일반 대화의 약 15배 토큰을 썼다는 것. 그리고 토큰 사용량만으로 점수 차이의 약 80%가 설명된다는 것.

이 이야기를 듣고 나면, 단순히 AI 모델의 성능이 뛰어나 조율이 똑똑해서 이긴 게 아니라, 돈을 다섯 배 더 쓴 쪽이 이긴 것에 가까워집니다.. 에이전트 다섯 개로 펼친다는 건 곧 추론 예산을 다섯 배 쓴다는 뜻이기도 하니까요.

올해 4월에 이걸 검증한 논문이 나왔습니다. 지적이 단순합니다. 그동안의 비교가 공정하지 않았다는 거예요.

멀티 에이전트가 이겼다는 실험들을 보면, 멀티 쪽이 생각하는 데 쓴 양이 단일 쪽보다 훨씬 많았습니다. 당연히 각자 컨텍스트가 적은 채로 유지되고, 단순히 에이전트 수만 보더라도 더 좋은 결과물이 나올 가능성이 훨씬 높죠.

그래서 양쪽에 똑같은 양의 생각만 허락하고 다시 재봤습니다. Qwen3, DeepSeek-R1, Gemini 2.5로요. 결과는 단일 에이전트가 따라잡거나 이겼습니다.

왜 그런지도 설명이 있는데, 복사기를 떠올리면 쉽습니다. 원본을 복사하고, 그 복사본을 또 복사하면 어떻게 될까요. 아무리 좋은 복사기를 써도 원본보다 선명해지지는 않습니다. 조금씩 흐려질 뿐이죠.

정보도 똑같습니다. 에이전트 A가 읽고 정리해서 B에게 넘기면, B가 받는 건 원본이 아니라 A의 정리본입니다. 거칠 때마다 조금씩 빠져나가고, 다시 채워지는 일은 없습니다.

병렬화를 “여러 눈으로 넓게 본다”고 생각했는데, 실은 하나를 여러 조각으로 나눠 각자 흐리게 보는 것에 가까웠습니다.

둘째, 1년 지나고 보니 양쪽이 같은 자리로 왔습니다.

그런데 4월에 후속 글을 직접 냈습니다. 입장을 뒤집은 게 아니라 조건을 더 좁힌 글이었습니다. 여러 에이전트가 동시에 코드를 쓰는 구조는 여전히 안 된다고 했으나, 쓰는 주체는 하나고 판단만 나눈 좁은 경우뿐이라고요.

Anthropic도 같은 기간 반대 방향으로 움직였습니다. 넓게 펼치는 병렬에서 역할이 좁게 정해진 하위 에이전트 쪽으로요. OpenAI는 4월에 에이전트끼리 대화 기록을 넘기는 걸 아예 기본으로 꺼버렸습니다. 서로 컨텍스트가 새어 들어가는 걸 줄이려고요.

그래서 지금 남은 패턴은 하나입니다. 에이전트 하나가 전체 맥락을 쥐고, 독립적인 곁가지 작업만 떼어 던지고, 요약만 돌려받는 것. 하위 에이전트끼리 직접 얘기하게 두지 않고, 공유하는 상태도 만들지 않습니다.

Claude Code의 Task 도구도, OpenAI의 방식도, Cognition의 새 기능도 전부 이 모양입니다. 1년 전의 그 시끄러웠던 논쟁이 사실상 정리된 셈이죠.

Latent Space 팟캐스트에서 나온 얘기가 인상적이었습니다. Devin에게 다른 Devin을 마음대로 만들고 서로 메시지를 보낼 수 있게 해봤답니다. 결과는 “정말 혼돈스러운 세상”이었고, 결국 일상적으로 제일 쓸모 있는 건 Devin 하나였다고 하네요.

Microsoft의 Azure SRE 팀 사례도 같은 방향입니다. 멀티 에이전트 전문화 쪽으로 가다가 인수인계 자체가 신뢰성을 떨어뜨린다는 걸 발견하고 되돌렸습니다.

그래서 판단 기준이 이렇게 정리됐습니다.

하위 작업이 서로 독립이고 공유 상태를 안 건드리면 병렬이 맞습니다. 자료 조사, 여러 소스 훑기, 서로 무관한 파일 여러 개 고치기 같은 것들이요.

결정이 서로를 제약하면 단일이 맞습니다. 설계가 진행되면서 계속 갈리는 작업, 앞 단계 결과에 따라 다음이 달라지는 작업이요.

애매하면 단일 에이전트를 추천드립니다. 현재로서는 OKF와 같은 자료를 잘 요약하는 포맷을 탐색하고, 작업 단위로 세션을 새로 불러와 진행하는 것이 효율적인 것처럼 보이네요.

지난번 글에서 에이전트가 긴 작업을 못 버티는 이유를 다뤘는데요. 병렬화는 그 문제를 컨텍스트를 쪼개서 푸는 시도입니다. 다만 쪼갠 걸 다시 합칠 때 정보를 잃습니다. 같은 문제의 다른 해법인데, 공짜인 해법은 아니었네요.

#AI #Agent #LLM #ClaudeCode #MultiAgent

업데이트는 2.0에서 제일 많이 나온 피드백 세 가지에 집중했는데요. 생성되는 데 느리다, 편집할 때마다 인물이 바뀐다, 원하지 않는, 즉 지시하지 않은 곳을 슬쩍 바뀐다에 포커스했습니다.

1. 참조 사진 유지력. 사진 속 인물을 다른 배경이나 화풍으로 옮겨도 얼굴이 그대로 알아볼 수 있게 남습니다.

2. 정밀 편집. 시킨 부분만 고치고 나머지는 그대로 둡니다. 재킷만 바꾸고 자세는 유지, 배경만 바꾸고 제품은 유지, 문구만 바꾸고 구도는 유지하는 식입니다. 얼리 고객인 Higgsfield의 표현이 재밌었는데, “무엇을 바꾸지 말아야 하는지를 이해한다”고 하더군요.

3. 멀티턴 편집 일관성. 대화를 이어가며 여러 번 고쳐도 앞서 수정한 게 풀리지 않고, 턴이 쌓여도 화질이 안 무너집니다. 큐브 회전, 여행 인포그래픽, 생일 케이크 초 개수 바꾸기 같은 예시 영상이 올라와 있어요.

4. 속도. 생성 지연이 2.0 대비 최대 50% 줄었습니다.

5. 투명 배경. 이건 지난달(8/20) GPT-Image-2 API에 background=transparent 옵션이 프리뷰로 먼저 붙었던 건데요. 만들고 나서 배경을 지우는 방식이 아니라 알파 채널을 생성 단계에서 같이 만드는 거라, 유리나 가는 털처럼 누끼가 잘 안 따지는 부분이 깔끔하다는 게 포인트였습니다. 쿡북 예시는 제품 컷, 슬라이드용 다이어그램, 아이콘과 스티커, 굿즈 아트워크였고요. ChatGPT에서 투명 PNG가 잘 안 뽑힌다는 불만은 5월부터 개발자 포럼에 올라와 있었는데, 2.5에서는 투명 배경을 포함한 복잡한 레이아웃 처리가 더 좋아졌다고 하고, Manus도 투명 배경 생성이 개선돼 브랜드 에셋이나 프레젠테이션용으로 잘 맞는다고 평했습니다.

그 외에 인포그래픽의 정보 정확도, 지정한 스타일 반영이 좋아졌다고 합니다.

기능도 몇 개 붙었습니다. 채팅창에 @Sketch를 치면 직접 그림을 그려서 참조로 넣을 수 있고(방 배치나 옷 실루엣 같은 것), 포스터나 굿즈 같은 인기 포맷은 템플릿에서 시작할 수 있습니다. 이미지 위에 직접 코멘트를 달아 그 부분만 고치게 할 수 있고, 결과물을 공유할 때 프롬프트를 같이 붙여서 다른 사람이 자기 사진으로 재현하게 할 수도 있어요. 무료를 포함한 모든 ChatGPT 티어와 Work, Codex에 배포 중입니다.

개발자용 API는 두 모델로 나왔습니다. GPT-Image-2.5 Flare가 기본형으로, GPT-Image-2보다 품질은 높고 지연은 절반입니다. Sunburst는 생성이 더 오래 걸리는 대신 편집 정밀도를 높인 프리미엄형이고요. 토큰 단가는 둘이 같은데 GPT-Image-2의 정확히 2배입니다(출력 이미지 100만 토큰당 15달러에서 30달러). 빨라졌다고 싸진 건 아니에요. Adobe Firefly에 바로 탑재됐고, Manus는 자체 평가에서 Flare가 GPT-Image-2보다 2~4배 빨랐다고 합니다.

시스템 카드에서 눈에 띈 것 두 가지. 사실감이 올라간 만큼 딥페이크 위험이 커졌다고 명시했고, 자체 적대적 테스트에서 위반 이미지가 사용자에게 노출된 비율은 2.0의 1.64%에서 Sunburst 1.09%, Flare 1.41%로 내려갔습니다(통계적으로 유의한 차이는 아니라고 스스로 적어뒀습니다). 그리고 워터마크는 C2PA에 더해 구글 딥마인드의 SynthID를 가져다 씁니다. OpenAI 제품에 구글 기술이 들어간 셈이죠.

정리하면 이번 업데이트는 ‘더 잘 그리기’보다 ‘고친 걸 유지하기’에 방점이 찍혀 있는 것 같습니다. 적어도, 만들어낸 결과물이 마음에 안 들 때 정확하게 수정사항들을 반영해줄 수 있는 또 한 걸음이 된 것 같네요!

#OpenAI #ChatGPT #GPTImage #이미지생성 #AI

요즘 AI 모델에 스킬을 붙이는 게 뭐 큰 일도 아닐 정도로 대중화되고 있는 마당에, 여기서 ‘Tauric Research’라는 조직이 등장합니다.

타우릭 리서치는 UCLA 컴퓨터과학과 박사과정생, Yijia Xiao가 만든 스타트업입니다. 연구 조직이기 때문에, “연구자와 기업에서 지능형 트레이딩 시스템을 개발 및 배포할 수 있도록, 모듈화된 AI 기반 플랫폼, 프레임워크를 제공하는 것”이 타우릭 리서치의 미션이라고 밝히고 있습니다.

오픈소스로 풀린 TradingAgents와 논문으로 공개된 Trading-R1이 주목받고 있습니다. (GitHub 기준 103k 스타)

TradingAgents의 발상은 단순합니다. 일종의 자산운용사 회사 조직도를 그대로 옮긴 겁니다.

맨 앞에 분석가 넷이 섭니다. 재무 분석가는 재무제표와 실적 지표를 보고 내재가치와 위험 신호를 찾습니다. 투자심리 분석가는 뉴스 헤드라인과 StockTwits, 레딧 게시물을 모아 단기 시장 심리를 하나의 수치로 뽑습니다. 뉴스 분석가는 거시 지표와 글로벌 뉴스를 봅니다. 기술적 분석가는 MACD와 RSI 같은 지표로 패턴을 읽고요.

여기까지는 예상 가능한데, 그다음이 재밌습니다. 강세론자와 약세론자 연구원이 서로 토론합니다. 한쪽은 사야 하는 이유를, 다른 쪽은 팔아야 하는 이유를 대며 붙습니다. 트레이더가 그 토론 기록과 과거 데이터를 종합해 매수·매도·보유를 결정하고, 리스크 관리팀이 노출을 감시합니다.

설계상 영리한 점도 있습니다. GPU가 필요 없습니다. API 크레딧만 있으면 돌아가고, 역할마다 다른 모델을 붙일 수 있어요. 깊은 추론이 필요한 자리엔 비싼 모델을, 단순 작업엔 싼 모델을 씁니다.

그래서 성과는 어땠을까요.

논문은 좋은 숫자를 내놨습니다. 누적 수익률 23.21% 이상, 샤프지수 5.60 이상. 매수 후 보유, MACD, KDJ+RSI, ZMR, SMA 다섯 가지 기준 전략을 모두 이겼습니다. 회사 홈페이지에는 연 30.5% 수익률이라고 걸려 있고요.

그런데 실험 조건을 보면 얘기가 달라집니다.

2024년 1월 1일부터 3월 29일까지. 석 달입니다. 종목은 애플, 엔비디아, 마이크로소프트, 메타, 구글 다섯 개. 전부 대형 기술주고, 그 석 달은 엔비디아가 폭등하던 강세장이었습니다.

이걸 두고 올해 3월에 나온 서베이가 직설적으로 지적합니다. 석 달짜리 상승장 구간 하나로 샤프지수 5.60에서 8.21을 보고한 건 우월성의 증명이 아니라 시간적 견고함의 필요성(아무때나 해도 이런 일정함이 보장되는가)을 보여주는 사례라고요.

제가 지나가면서 봤던 극히 일부는 수익률을 보는 사람도 있었던 것 같은데요 (아마도 기존에도 투자를 하던?). 대다수는 수익률이 마이너스였다는 실험 보고가 많았습니다.

본 논문에서도, 다른 LLM 투자 연구에서도 말하길, 큰 한계점으로 시사되는 것은 “시간적 지식 유출”이라고 말합니다.

예를 들어 저희가 2024년 2월의 엔비디아 뉴스를 모델에게 주고, 이걸 어떻게 해석할지를 물어봅니다. 프롬프트에는 당연히 2월에 해당하는 뉴스가 들어갈 겁니다. 하지만, LLM의 특성상, 2024년 2월 이후에 학습된 모델이라면 해당 시점에 주가가 올랐는지, 내렸는지를 기억할 겁니다. 그런 식으로 과거의 데이터를 이미 학습해버려 편향성이 생기고, 일정한 분석을 보장받지 못하게 됩니다.

그래서 지금 이 분야는 방향을 틀고 있습니다. 과거를 되짚는 백테스트로는 증명이 안 되니, 학습 컷오프(사전학습) 이후 구간에서 실시간으로 굴려보자는 쪽으로요. 아직 안 일어난 일은 모델도 모르니까요. LiveTradeBench, Agent Market Arena 같은 것들이 그 흐름입니다.

다만 여기서도 새 문제가 나옵니다. 실시간 평가는 특정 시점에 묶여 있어서 남이 똑같이 재현할 수가 없고, LLM은 같은 조건으로 돌려도 매번 다른 매매 판단을 내놓습니다. 한 번의 실시간 결과도 못 믿는다는 지적이 나오는 이유고요.

정리하면 이렇습니다.

발상은 좋습니다. 자산운용사의 의사결정 구조를 옮기고, 강세론자와 약세론자를 붙여 토론시키고, 그 과정을 사람이 읽을 수 있게 남긴다는 것. 기존 퀀트 모델(수학적 예측 모델)에 없던 설명 가능성이고, 규제 산업에서는 그게 성능만큼 중요합니다.

다만 성능이 증명됐다고 말하기엔 아직 이릅니다. 논문은 실험 조건을 정직하게 밝혔습니다. 2024년 1월부터 3월까지, 석 달, 다섯 종목. 그런데 제품 페이지로 넘어가면 그 조건은 사라지고 “연 30.5%”만 있죠.

공식 깃허브에도 이런 문장이 있습니다. “이 프레임워크는 연구 목적으로 설계됐으며 금융, 투자, 거래 조언이 아니라는 것. 성과는 백본 모델, 온도 설정, 거래 기간, 데이터 품질에 따라 달라진다”고요.

이 문장이, 지금으로선 가장 정확한 요약인 것 같습니다.

ps. TradingAgents에게 물어보니, S&P 500 주식을 투자하라고 하네요!

Claude Code나 Codex를 길게 돌려보신 분들은 아실 겁니다. 처음엔 잘합니다. 그런데 어느 순간부터 애가 이상해집니다. 저는 요즘, 오래 돌리니까 한 번에 하기보다는, 또 지적해줘야 그제서야 뒤늦게 하는 것 같은 느낌도 받는데요.

지난번 글에서 요즘 AI 개발 회사들이 ‘긴 과제(long-horizon) 환경’을 수십 배로 늘리고 있다고 썼는데요. 환경은 그렇게 늘렸는데 왜 실제로는 긴 작업을 못 할까요. 궁금해서 관련 논문들을 찾아봤습니다.

생각보다 산술적인 이유로도 어느 정도 설명이 되는데요.

스텝마다 90%씩 성공한다고 치면, 10스텝이면 35%입니다. 확률을 곱하니까요. 0.9를 열 번 곱하면 약 0.35가 나옵니다. 이것만 해도 꽤 비관적입니다. 스텝 하나하나는 훌륭한데 전체 작업은 세 번에 두 번 실패한다는 뜻이니까요.

그런데 실제로 재보니 그 비관적인 예측보다도 나빴습니다.

에피소드 23,392개로 모델 10개를 측정한 논문이 있는데요. Qwen3 30B는 짧은 작업에서 작업 수행률이 75.8%였습니다. 확률상 수행률은 긴 작업에서 33.0%가 나와야 하겠죠? 실측은 22.2%였습니다. Mistral Nemo 모델(NVIDIA와 합작한 모델)은 확률상 성공률이 28.6%이었으나, 실측 12.1%로, 2.4배 차이가 났습니다.

물론 모델도 모델 나름이었습니다. 같은 논문에서 프론티어급 모델들은 아주 긴 작업에서도 79% 이상을 유지했어요. 오픈모델이라던가, 상대적으로 작은 (비용, 파라미터 등) 모델일수록 예측과 실측의 격차가 컸습니다.

왜 예측보다 나쁠까요. 여기가 이 글에서 제일 재밌었던 부분입니다.

스텝당 오류율 자체가 작업이 진행될수록 올라갑니다. 상수가 아니에요.

산술적 확률 계산에서는 수행하는 작업들이 서로 독립이라고 가정합니다. 동전을 계속 던지는 것처럼요. 그런데 실제 에이전트는 그렇지 않습니다. 잘못된 도구를 한 번 호출하거나 잘못된 가설을 한 번 세우면, 거기서 빠져나오지 못하고 계속 그 위에 쌓습니다. 동전 던지기가 아니라 한 번 미끄러지면 계속 미끄러지는 비탈에 가깝습니다.

어떤 논문에서는 이걸 ‘자기 조건화(self-conditioning)’라고 부릅니다. 그리고 이렇게 덧붙이는데요. 사람은 반대라고요. 사람은 하다 보면 익숙해져서 나아집니다.

이는 숫자로도 드러납니다. 첫 번째 하위 작업조차 끝내지 못하고 죽는 비율이, 짧은 작업에서는 1%인데 아주 긴 작업에서는 25%까지 뜁니다. 시작도 못 하고 무너지는 거죠.

다른 연구들도 비슷한 그림을 보여줍니다. 120스텝을 넘어가면 정확도가 0에 수렴하고, 난이도를 높인 변형에서는 15스텝 만에 붕괴합니다. 더 안타까운 결과도 있는데, 도구(웹 검색, 브라우저 제어 등)를 쥐여준 에이전트가 안 쥐여준 쪽보다 못한 경우가 있었습니다. 한 실험에서 25.0% 대 58.3%였고, 결정적인 건 에이전트가 맞힌 문제들이 비에이전트가 맞힌 문제들의 부분집합이었다는 겁니다. 비싼 값을 정당화할 고유 능력이 하나도 없었다는 뜻이에요.

여기서 “그럼 중간에 요약해서 이어가면 되지 않나” 싶으실 텐데요. 실제로 그렇게 합니다. 컴팩션이라고 부르고, 효과도 있습니다.

다만 요약할 때마다 조금씩 잃어버립니다. 반복해서 다시 쓸수록 짧아지고, 세부가 빠져나가고, 결국 쓸모 있던 지식까지 사라집니다.

그리고 더 곤란한 게 있습니다. 잘못된 판단이 요약에 한 번 섞여 들어가면, 확인할 원본이 없으니 그게 사실이 됩니다. 오류가 압축되면서 오히려 단단해지는 거죠.

그러니까 컴팩션은 문제를 없앤 게 아니라 다른 형태로 바꾼 것에 가깝습니다.

밖에 파일로 남기고, 다음 세션이 요약본이 아니라 원본을 읽고 시작해야 합니다. 대화 기록은 마모되지만 파일은 마모되지 않으니까요.

그래서 구글이 6월 12일에 이걸 표준으로 만들었습니다. Open Knowledge Format(OKF)입니다.

구조는 놀랄 만큼 단순합니다. 개념 하나하나들을 마크다운(md) 파일로 저장되고, 폴더가 통째로 개념들을 저장을 저장한 경로로써 존재합니다. 마크다운 파일 위에 YAML 몇 줄로 종류, 제목, 설명, 태그, 시각을 적습니다. 파일끼리는 그냥 마크다운 링크로 잇고, 그게 쌓여서 그래프가 됩니다.

다시 정리해, 기존에 소스코드가 있으면, 동일하게 경로를 구성해 어떤 폴더, 파일이 어떤 역할을 하는지 등을 요약해두는 방식을 OKF라고 규격을 만든 겁니다.

구글이 발표문에 쓴 문장이 인상적이었는데요. “부족한 건 또 하나의 서비스가 아니라 포맷”이라는 겁니다. 실제로 OKF는 어떤 설치해야 하는 스킬이라던가, 서버처럼 돌아가는 런타임도 아니고, 검색 인덱스, 모델도 아닙니다. 굉장히 가벼우면서도 강력하게 에이전트들이 힘을 발휘할 수 있도록 만들어주는 체계입니다.

노션 내부에서도 최근 에이전트 기능을 대폭 강화시키며 인터뷰에서 말하길, “오직 사용자가 요청한 지시 그 자체가 컨텍스트로 시작한다”라고 말하더군요. 서브 에이전트들을 새로 띄우는 원리와 비슷하다고 하는데, 앞에서 다룬 문제를 고민한 흔적이라 볼 수 있습니다.

저희 AXIT 플랫폼에서도 프로젝트 단위로 진행하는 작업들이 워낙 길어지다보니, 작업 내용을 OKF 포맷으로 계속 정리하도록 하고 있는데요. 최대한 적은 컨텍스트를 유지하고 언제든지 사람이 수정할 수 있는 구조를 채택하게 되었습니다.

마지막으로, 앞서 논문에는 이런 대목이 있습니다. 스텝당 정확도가 조금만 올라도 완수 가능한 작업 길이는 지수적으로 늘어난다는 것.

벤치마크에서 1~2%p 오르는 게 지루해 보여도, 체감으로는 몇 배로 오는 이유입니다. 실제로 프론티어 모델이 절반의 확률로 해내는 작업 길이는 지난 6년간 7개월마다 두 배씩 늘었습니다. 2025년에는 55분이었고, 2027년쯤 4시간에 도달할 전망이라고 하네요.

그때까지는, 컨텍스트 관리를 신경쓰며 작업하는 걸 추천드립니다. 동시에, 소비자들의 신경을 최대한 덜고자 하는 앤트로픽, OpenAI 같은 회사들은 이런 좋은 시도들을 모델 단에서 적용할 수 있도록 노력해줄 것으로 기대됩니다.

#AI #Agent #LLM #OKF #OpenKnowledgeFormat #Google #ClaudeCode #AXIT

「신뢰성 측정」 https://arxiv.org/abs/2603.29231 (Beyond pass@1: A Reliability Science Framework for Long-Horizon LLM Agents)

「장기 실행 측정; ‘자기 조건화’」 https://arxiv.org/abs/2509.09677 (Measuring Long Horizon Execution in LLMs)

「LORE 벤치마크」 https://openreview.net/pdf?id=dAn82lpLx4 (The Agent’s Marathon (LORE: Long-horizon Reasoning Evaluation))

「Less Is More」 https://arxiv.org/abs/2604.21746 (Less Is More: Measuring How LLM Involvement affects Chatbot Accuracy in Static Analysis)

「ACE」 https://arxiv.org/abs/2510.04618 (Agentic Context Engineering)

「OKF 명세와 발표문」 https://cloud.google.com/.../how-the-open-knowledge...

https://github.com/.../knowledge.../blob/main/okf/SPEC.md

온 세상을 떠들썩하게 했었던 AI 어시스턴트 OpenClaw의 2.0 버전이 8월 30일에 발표되었습니다.

(v2026.8.1; 편의상 2.0 버전이라고 표기)

맥 미니 대란을 만들어냈다고 해도 과언이 아닐 정도의 OpenClaw는 어떤 게 바뀌었을까요?

1. 보안

기존 OpenClaw에서 프롬프트 인젝션 통해 시크릿 값을 탈취하기가 쉬워 말이 많았던 적 기억 나실 텐데요. 악의적으로 만든 스킬가 확산돼 문제가 됐었던 사례입니다.

이번 출시에서 가장 신경 쓴 부분이라고 꼽히는데요. 핵심은 시크릿 값을 AI 모델이 볼 수 없도록 처리한 점입니다.

이제 에이전트가 자격증명이 필요할 때 마스킹된 프롬프트로 요청합니다 (일종의 암호화). 그러면 그 값이 대화 기록에도, AI 모델 컨텍스트에도 아예 안 들어갑니다. 그동안 평문 API 키가 로그나 대화 기록에 남았다가 간접 프롬프트 인젝션으로 새어나가는 사고가 반복됐는데, 이 문제를 해결하고자 수정된 부분입니다.

또한, 예를 들어 디스코드(게이트웨이)로 연결했을 경우, 모르는 사람이 DM을 보내면 페어링 코드를 요구합니다. openclaw security audit 명령도 새로 생겨서 네트워크 노출, 도구 권한 범위, 브라우저 제어 노출, 플러그인 허용목록을 한 번에 점검해줍니다.

다만 한계도 문서에 그대로 적혀 있습니다. 뒤에 나올 공유 세션 제어에서는 이러한 보안이 약하다고 지적합니다.

2. 협업 기능 강화

이번 버전에서 또 강조하는 기능인데요. 단순히 1인 개발자들이 쓸 수 있는 도구가 아니라, 팀 단위로, 조직 단위에서 쓸 수 있는 협업 기능이 강화되었습니다.

이전엔 진행 중인 작업에 다른 사람을 끌어들일 방법이 아예 없었습니다. 중간에 다른 사람이 끼어들면, 에이전트가 기존에 알던 맥락을 통째로 잃어버렸거든요. 공유 클라우드 세션이 그걸 해결해서, 두 번째 사람이 진행 중인 작업에 들어가거나 맥락을 유지한 채 작업을 이어받을 수 있게 됐습니다.

재밌는 건 이 협업 기능을 만드는 과정에서 OpenClaw의 협업 기능으로 만들었다는 겁니다. 두 달간 OpenClaw 내부 개발 팀이 각자 로컬 환경을 버리고 공유 에이전트 환경으로 옮겨서, OpenClaw로 OpenClaw를 만들었다고 해요.

3. 브라우저 기능 강화

i) 브라우저로 OpenClaw를 쓰는 쪽

웹에서 대화를 하거나, 설정할 수 있는 패널이 있었는데요. 이 패널을 통째로 다시 만들어서, 보조 제어판이 아니라 주 인터페이스가 됐습니다. 대화를 가운데 놓고 파일, 승인 요청, 설정, 진행 중인 작업을 그 옆에 배치했어요. 플러그인도 이제 이 화면에서 검색하거나 설치, 비활성화 등 웹 UI의 기능이 대폭 강화되었습니다.

저도 설치하자마자 들었던 생각이 제가 로컬에서 했던 클로드, 코덱스의 세션들이 다 동기화되어 있고, 모델들도 다양하게 선택할 수 있게 바뀌었더라구요. 제가 뭐 따로 설정한 것도 없는데 말이죠. 이런 면에서 엄청나게 편해진 것 같습니다.

ii) OpenClaw가 브라우저를 쓰는 쪽

격리된 전용 프로필로 로그인 상태의 브라우저 세션을 굴리거나, 사용자가 공유한 Chrome 탭만 건드리게 할 수 있습니다. 컴퓨터 조작은 페어링된 Mac과 명시적으로 켠 Windows에서만 되고요.

4. 연결 모델 확장

원래도 API 키, 구독 OAuth, 로컬 모델을 다 붙일 수 있었습니다. 다만 사용자가 직접 설정해야 했습니다.

2.0 버전에서는 설치할 때 컴퓨터를 먼저 훑어서, 이미 로그인된 Codex나 Claude CLI가 있으면 그대로 재사용하고 설치된 Ollama, LM Studio 모델도 찾아냅니다. 그리고 그 조합이 실제로 응답하는지 확인한 뒤에 저장해요.

5. 저장 방식 변경 (속도/안정성 향상)

세션과 대화 기록이 로컬에 jsonl 파일을 저장하는 방식에서, SQLite로 옮겨갔습니다. 속도와 안정성이 대폭 강화되었으나, 반대로 2.0 버전에서 과거 버전으로 다운그레이드 할 때 까다로워졌습니다.

개인적으로 제일 인상적이었던 건 기능이 아니라 개발 과정이었습니다. 이 프로젝트는 230일 동안 106번을 냈습니다. 대부분 하루이틀 간격이었어요. 그러다 7주동안 배포를 멈추고 나온 게 2.0인데, 지금까지 병합된 전체 PR의 절반이 이 한 번에 들어갔습니다.

이유를 공식 블로그가 이렇게 적어놨습니다. 릴리즈 속도는 느려졌는데 개발은 오히려 빨라졌다고요. 팀이 커지면서 작업량이 기반과 프로세스 양쪽을 넘어서버려서 둘을 동시에 뜯어고쳤다는 겁니다.

동시에, 이런 AGI 시대가 다가옴에 따라, ‘재귀 개선’. 즉, 에이전트 시스템을 개발할 수록, 기존의 시스템을 사용해 개선된 시스템을 개발하는 시대입니다. 어떤 조직이든, 이런 체계를 구축해나가는 게 중요해진 시기라고 생각합니다.

#AI #Agent #LLM #OpenClaw

공식 홈페이지: https://openclaw.ai/

요즘 Claude Code나 Codex 같은 AI 코딩 도구 쓰시는 분들 많으시죠. 그런데 이게 몇 주 간격으로 계속 뒤집힙니다. Fable 5.1이 출시된지 얼마나 됐다고, 모두가 Fable 5.1이 정말 좋다고 말하다가도, Astra 출시가 또 분위기를 바꿔냈습니다.

여기서 궁금한 점이 하나 생깁니다. 인터넷에서 계속 데이터를 가져오는 것도 한계가 있고, 사람이 쓴 코드들을 이미 다 학습해버린 것도 옛날 일일 텐데, 어떻게 AI들은 계속 성능이 좋아지는 걸까요?

실제로 업계에서는 2026년 기준 고품질 인간 텍스트가 사실상 고갈됐다는 표현을 씁니다. 소위 ‘데이터 월(Data Wall)’인데요. 인터넷은 유한하니까요. 그런데 성능은 계속 오릅니다. 궁금해서 최근 중국 오픈소스 모델들을 만드는 기업의 기술 논문, 블로그(보고서)를 찾아보니 힌트를 찾을 수 있었습니다.

지난달(8/14) Z.ai는 GLM-5.3을 공개했습니다. 이 모델, 베이스 모델이 직전 버전인 GLM-5.2와 완전히 동일합니다. 사전학습을 새로 돌리지 않았어요. 그런데 자체 평가 기준으로, 50%의 성능 향상이 있었다고 말합니다.

Z.ai에서 밝힌 이유는 딱 하나였습니다. “수십 배 많은 장기 과제(long-horizon) 환경, 더 다양한 환경 종류, 더 긴 사후학습(post-training) 기간.” 새 데이터를 긁어온 게 아니라, 모델이 스스로 굴러다니며 배울 놀이터를 늘린 겁니다.

핵심은 채점이 자동으로 된다는 점입니다. Qwen 팀이 Qwen3-Coder 블로그에서 이걸 한 문장으로 정리했는데요. “풀기는 어렵지만 검증은 쉬운(hard-to-solve, easy-to-verify)” 과제가 대규모 강화학습의 핵심으로 꼽혔습니다.

코드는 컴파일되거나 안 되거나, 테스트가 통과하거나 안 하거나 둘 중 하나입니다. 사람이 일일이 정답을 써줄 필요가 없습니다. 검증기만 있으면 문제를 무한히 찍어내고 모델한테 계속 풀리면 되는 거죠. 텍스트가 고갈돼도 이쪽은 안 고갈됩니다.

여기서 “그럼 코딩만 좋아지는 거 아니냐” 싶으실 텐데, 저도 같은 의문이 들었습니다. 요즘 Fable이나 Astra는 글 쓰는 능력도 확실히 좋아졌거든요.

찾아보니 ‘루브릭(채점 기준표)’으로 검증을 흉내 냅니다. 좋은 글이라는 뭉뚱그린 개념을 여러 하위 기준으로 쪼갠 다음, 심판 역할을 하는 다른 모델이 그 기준표를 들고 항목별로 채점하는 거예요. 코드는 컴파일러가 채점하고, 글은 루브릭 든 심판 모델이 채점하는 셈입니다. 더불어 사람이 채점하는 양도 시간이 지날 수록 많아져 좋아질 수도 있구요.

그래서 요즘 진짜 경쟁은 ‘환경 만들기’입니다. 숫자를 보면 좀 무섭습니다.

Qwen3가 약 20개 일반 도메인 태스크였는데, Qwen3-Coder에서 알리바바 클라우드 위에 2만 개 독립 환경을 병렬로 돌리는 시스템까지 갑니다. 그리고 올해 2월 나온 Qwen3.5는 아예 “백만 에이전트 환경”이라고 표현하더군요. Qwen 팀은 Qwen3.5 릴리스 노트에서 Qwen3 대비 사후학습 향상분의 대부분을 “생각해낼 수 있는 거의 모든 RL(Reinforcement Learning; 강화학습) 태스크와 환경의 광범위한 스케일링”에 돌립니다.

개인적으로 제일 재밌었던 건 GLM-5 기술 보고서에 나오는 트릭이었는데요.

코드 관련 웹페이지를 대량 수집한 다음, 품질 분류기로 거르고, 그중 터미널 작업으로 바꿀 수 있는 페이지만 골라냅니다. 그리고 코딩 에이전트한테 그 페이지랑 태스크 명세를 같이 주고 실행 가능한 문제를 합성시킵니다.

실제 GitHub 이슈로도 비슷한 걸 합니다. 저장소의 의존성 설정을 자동 분석해서 실행 환경을 구축하고, LLM으로 테스트 로그 파싱 함수를 생성해서 “고치기 전엔 실패하고 고친 후엔 통과하는” 테스트를 뽑아냅니다. 이렇게 9개 언어, 수천 개 저장소에 걸쳐 1만 개 이상의 검증 가능한 환경을 만들었다고 합니다.

그럼 다음 벽은 뭘까요. 아마 환경 제작 비용일 텐데, 이미 답이 나오고 있습니다. Qwen이 6월에 낸 Qwen-AgentWorld는 환경 자체를 시뮬레이션하는 세계모델을 따로 학습시켜서, 진짜 환경 없이도 RL을 돌리는 방향을 제안합니다.

모델이 직접 데이터를 만드는 단계에서, 이제는 본인을 시뮬레이션, 테스트하는 환경까지 구축해내는 단계로 도약하고 있는 과정입니다!

#LLM #ChatGPT #Claude #Zai #Qwen

올해도 진행하는지 오랜만에 들어가보니, 올해의 주제는 무릎의 소견(12개)을 분류하라는 내용으로 진행하더라구요. 굉장히 흥미로운 건, 저조차도 이런 대회를 준비하려고 한다면, 아무래도 훈련시키고 검증 작업할 때 GPU 자원이 좀 부담이 될 텐데요. 심지어는 이걸 개인이 했을 때 주최 측에서 학습 결과를 어떻게 검증할 것이며, 과연 정당한 방법이 맞을지 등등. 생각나는 문제가 많습니다.

RSNA 같은 기관(학회 등)에서는 이런 문제를 구글의 Kaggle 플랫폼과 해결했습니다.

지금은 문을 닫았지만 한때는 국내 코딩 대회, 부트캠프, 코딩테스트 등으로 굉장히 유명했던 ‘백준’ 서비스와 매우 유사한데요.

Kaggle은 2017년에 구글에 인수된 플랫폼입니다. 전세계 데이터 과학을 위해 공개 데이터셋을 서로 공유하고, 서로의 코드 (노트북)를 공유하며, AI 대회 지원, 그리고 일전에 공유드린 최신 AI들의 벤치마크를 사용자들이 직접 만들어서 공유하는 환경까지 지원됩니다.

주최 측에서 Kaggle에 일정 부분 호스팅 수수료를 지불하고, 마음껏 지원자들이 본인들의 코드를 업로드해서 제출하면, Kaggle의 GPU 자원을 활용해서 채점을 하는 방식입니다. (주 30시간, Tesla T4 GPU 지원)

RSNA는 2017년부터 12번에 걸쳐 대회를 개최하였는데요. (같은 해에도 여러 주제로) 매년 스폰서와 전세계 병원에서 데이터(주로 이미지. CT MRI 등)를 제공 받습니다.

이런 대회가 Kaggle과 붙었을 때 두 가지 매력이 돋보이는데요.

1. 데이터 액세스

훈련용 4,407건은 규칙 동의 후 다운로드할 수 있습니다. 개인이 절대 평생 모으지 못할 데이터 규모입니다.

나머지 약 1,300건은 채점용이라 감춰두는데, 이걸 또 30 대 70으로 나눕니다. 30%로는 대회 기간 중 순위를 실시간으로 보여주고, 70%는 끝까지 감춰뒀다가 최종 순위를 낼 때 씁니다. 공개된 점수에만 맞춰 모델을 일부러 조작하는 것을 방지할 수 있는 거죠.

2. 장비에 대한 부담 완화

유튜브가 구글 클라우드 자원을 활용하는 것처럼, Kaggle 또한 동일하게 GPU 자원을 활용할 수 있는데요.

학습 데이터만 해도 569기가인데, 연구실, 기업이 아니더라도 개인조차도 제출하는데 무리없이 낼 수 있다는 점에서 매우 매력적으로 다가옵니다.

상금마저도 대단합니다. 올해는 총 $77,000 (한화 1억 원 상당)인데요. (1등 $9,000, 2등 $7,000 …)

참가자들에게 이렇게 베네핏을 제공하는 대회 주최(RSNA)와 Kaggle에게는 어떤 이득이 있을까요?

하버드에서 나온 논평을 인용하자면, “정규직 데이터사이언티스트 한 사람의 인건비보다 적은 돈으로, 몇 천 명의 사람이 달라붙어 굉장히 강력하고 좋은 모델들이 대량으로 나온다.”

좋은 모델, 좋은 성능을 원하는 것이 목적이라면, 이런 식으로 competition 시키는 것이 더 비용 측면에서나, 효율 측면에서 이점을 가져갈 수 있다는 이야기입니다.

또한, Kaggle도 이런 식으로 대회 호스팅 비용을 직접적으로 얻을 수 있을 뿐만 아니라,

1. ‘인재 파이프라인’을 구성해 본인들이 원하는 인재를 리크루팅 할 수 있고

2. 구글 클라우드 환경에 유입시키며,

3. 인수할 때 당시 50만 명이었으나, 현재 2,700만 명이 플랫폼을 이용합니다. ML 분야에서 빠져놓을 수 없는 플랫폼 강자를 만든 셈이죠.

우리나라에서도 이런 개인 차원에서 지원할 수 있는 대회가 많아졌으면 좋겠다는 취지에서 알아봤는데요!

국내 의료 학회에서도 진행하는 듯 싶었지만,

1. 연구용 GPU는 개인이 알아서.

2. 상금은 100만원 선.

3. 실제 환자 데이터를 보려면 IRB 승인서와 보안서약서를 갖춰 안심존이라는 격리된 환경에 들어가야 하고, 그마저도 다운로드는 안 됩니다. 그래서 국내에서는 합성데이터를 씁니다 (합성 데이터의 경우, 오리지널 데이터의 각종 특성을 반영한 임의로 생성한 데이터입니다). 정부 GPU 지원은 또 별개 창구인데, 사업계획서를 내고 심사를 받는 기업·기관 대상이라 대회 참가자와는 무관합니다.

국내 대회를 알아보려고 해도 뉴스 기사가 먼저 떴었지, 공식 홈페이지에 홍보가 잘 안된다는 점이 매우 아쉬웠습니다.

이 세 가지 문제를 모두 Kaggle에서 담당하고 있다는 것이 매우 놀랍다는 점이었구요.

그럼에도 우리나라에는 자원이 없는 게 아니었습니다.

데이터는 병원마다 쌓여 있고, GPU도 정부가 사고 있습니다. 대회를 열 학회도 있고 플랫폼도 있어요. 다만 이 셋이 각각 다른 창구에 있습니다. 데이터는 안심존, GPU는 심사 배분, 대회는 또 다른 기관 소관이거든요. 미국은 학회 하나가 데이터를 만들고 캐글이 나머지를 다 대주니까 두 주체로 끝나는데, 우리는 넷을 조율해야 합니다.

그리고 또 흥미로운 사실은, RSNA가 매년 이걸 하는 진짜 이유가 홍보는 아닐 겁니다. 무릎 대회 정답을 만들 때 근골격 전문의 두 명이 판독하고 조정자 한 명이 중재했다고 하는데, 중증도 기준을 미리 정하고 애매한 건 음성으로 매기기로 한 그 결정 과정이 곧 “이 소견은 어디부터 이상으로 볼 것인가”를 학회가 문서로 남기는 일입니다.

그렇게 만든 데이터셋이 그 분야의 기준선이 됩니다. 2024년 척추 대회 데이터가 지금도 AWS에 공개돼 논문에 쓰이고 있거든요. 기업이 새 모델을 내면서 “RSNA 챌린지 데이터로 검증했다”고 쓰게 되면, 학회가 심판 자리에 앉는 셈이고요.

우리나라에서도 개인이 의료가 됐던, 난제가 됐던, AI를 손쉽게 활용해 어려운 문제를 푸는 것이 한 자리에 모였으면 좋겠습니다. 현재까지는 잘 보이진 않는 것 같네요.

#RSNA #AI #Challenges #Kaggle

이번 모델의 포인트는 “인간이 컴퓨터로 할 수 있는 작업은 ChatGPT가 다 하겠다”인 것 같습니다. 사람과 대화하며 병렬적으로, 빠르게, 엄청난 퍼포먼스로 작업을 완수해냅니다.

저도 찾아보면서 워낙 벤치마크 자료가 많다보니, “그래서 Fable 5.1보다 좋다는 건지 안 좋다는 건지, 비용이 저렴하다는 거야?” 이런 질문을 던졌던 것 같은데요. 몇 가지 정리를 해봤습니다!

첫째, 코딩 에이전트 평가에서 Astra는 67점으로 Claude Fable 5와 동급입니다. 전작 GPT‑5.6 Sol의 65점보다 높고, 작업당 비용은 Fable 5의 절반 이하입니다. Sol과 비교하면 코딩에 사용한 토큰도 약 1/3 수준입니다. (최신 Fable 5.1은 70점)

둘째, 종합 지능 평가는 의외로 전작과 동률입니다. Artificial Analysis Intelligence Index에서 Astra와 Sol 모두 61점을 받았습니다. 모든 영역에서 갑자기 월등해졌다기보다, 실제 도구를 사용해 일을 수행하는 능력이 집중적으로 발전한 모델에 가깝습니다.

셋째, 실제 업무에서는 효율 차이가 두드러집니다. OpenAI의 Agents’ Last Exam에서 Astra는 Claude Opus 5보다 높은 결과를 내면서 출력 토큰을 약 65% 적게 사용했습니다. OSWorld 컴퓨터 작업도 Sol보다 약 47% 짧은 시간에 처리했습니다.

넷째, 성능이 강해진 만큼 안전장치도 훨씬 무거워졌습니다. Astra는 OpenAI 모델 최초로 사이버 역량이 ‘Critical’ 단계에 도달했습니다. 출시 초기에는 Trusted Access Program 참여 기업부터 제공하고, 이후 며칠에 걸쳐 일반 유료 플랜과 API로 확대하는 방식을 계획하고 있습니다.

결국 Astra의 핵심은 ‘종합지능 1위’가 아니라, AI가 실제 업무를 맡아 끝내는 경제성과 실행 능력이 크게 좋아졌다는 데 있는 것 같습니다.

이제 모델 경쟁의 기준도 구현 능력을 넘어, 작업 비용과 실행 능력, 그리고 감독 가능성으로 이동하고 있습니다.

이러한 성능과 안정성으로 인해, 현재는 제한된 기관에게만 순차적으로 배포 중이며, 안정성을 평가하며 안전장치를 조정하고 있는 단계입니다.

유저들이 정말로 기대하고 있는 모델일 텐데요. 이에 ChatGPT와 Codex를 이끄는 엔지니어인 Tibo는 본인의 X에서 오늘부터 Astra 모델이 공개되기 전날까지, 매일매일 코덱스 한도를 초기화 해주겠다고 했습니다! (Thank you tibo)

Claude, Codex 중 어떤 걸 사용하시나요? Astra 공개로 인해 이용 비중이 또 많이 달라질까요?

ps. 광고 영상 맨 처음 나온 79년 영상은, 단순한 그때 당시의 광고 영상처럼 보였으나, MIT 대학이 진행한 HCI 연구, ‘Put That There’ 의 역사적인 기록 영상이라는 비하인드가 있네요!

그런 역사적인 영상을 오마주한 점도 매력 포인트인 것 같습니다

#ChatGPT #Codex #Astra #GPT6

요즘 중국에서 나오는 오픈소스 AI 모델들이 굉장히 화두인데요. 뉴스에도 나왔던 유명한 Deepseek 모델부터, Qwen, Kimi, GLM, 그리고 요즘 경쟁자가 없을 정도의 Seedance (오픈소스는 아닙니다)까지. 전부 중국에서 나온 AI 모델입니다. 이외에도 저희가 다 외우지 못할 정도로 굉장히 많은 모델들이 중국에서 나오고 있는데요.

어제 (9/3), Qwen 팀에서 발표한 논문이 꽤 재밌어 공유해봅니다.

모델의 이름은 Qwen-Drive-1.0인데요. 이러한 연구들을 VLA (Vision + LLM + Action) 이라고 부릅니다.

기존의 VLA 연구들은 한계점이 명확했습니다.

첫째, LLM의 멀티모달(이미지 읽는 능력)로만 판단해 “앞에 차가 있으니 제동해야 합니다”, “우회전 해야합니다” 와 같이, 텍스트로만 지시를 내릴 수밖에 없었습니다.

둘째, LLM이기 때문에 운전과 같은 특정 상황들에 대해서 학습을 과도하게 (Fine-tuning) 시킬 경우, 일반 상식을 잘 잊어버리는 ‘재앙적 망각(Catastrophic Forgetting)’이라는 현상을 겪게 된다고 합니다. 이런 문제가 심각해지면 표지판, 야생동물 출몰 등 돌발 상황에 대해서 판단하기에 약점이라고 합니다.

셋째, 실제 차량에 적용할 때, 차량의 GPU를 운전만 할 줄 아는 용도로 써야합니다. 요즘 차량 같은 경우엔 발화만으로 목적지를 설정해주고, 서로 대화를 할 수 있는 인포테인먼트 AI가 점점 더 도입되고 있는데요. 기존 연구들은 운전에 초점을 맞췄었다고 합니다.

Qwen 팀은 이러한 문제를 해결하기 위해서 기존의 Qwen 3.5 모델 (4B, 준경량화)에 3D 정보를 담아 같이 추론하는 아키텍처를 설계했다고 합니다.

동시에, 추론 후 정확히 어떻게 움직여야 할지 구체적인 Waypoint 50개를 생성하도록 설계했다고 말합니다.

아래 사진을 보면, Qwen을 포함한 AI 모델들에게 “(여러 장의 사진을 주며) 이 사진들은 차례대로 방금 5초동안의 주변 사진들이야. 단일 사진만으로 판단하지 말고, 사진들의 시퀀스와 역동성을 고려해 주차된 차량이 몇 개인지 알려줘.”라고 질의합니다. (GT = Ground Truth, 정답에 해당하는 값. Zero/None이라고 해야 답이라고 설명하고 있음.)

Qwen 모델의 경우, 주차된 차량이 없다고 말합니다. 자세히 보시면, 차량들이 전진하고 있는 상황인 사진인데요. 특히 옆에 하얀 트럭이 주차된 게 아니라 시간에 따라서 점점 가까워지는 것을 보니, 차량을 추월(이동)하고 있는 모습을 보실 수 있습니다.

다만 다른 모델들은 “빨간 버스가 정차해있습니다”, “하얀 트럭이 오른쪽 길에 정차해있습니다”라고 대답하는 모습을 볼 수 있습니다.

다른 비교 사진들도 한번 구경해보세요^^ 사진들을 보고 각각의 모델들이 어떻게 대답하는지를 나타낸 게 재밌네요.

아래 사진은 돌발상황, 평소 운전하는 상황에서 AI가 어떻게 지시하는지 (“여우가 나타나 감속하세요”, “감속하고 우회전하세요” 등), 실시간으로 어떤 방향으로 차량이 이동해야 하는지 이동 포인트들을 시각화한 사진입니다. 수치들보다, 이런 Figure에 시각화된 걸 보는 게 더 재밌네요 ㅎㅎ

단순히 중국 회사들이 LLM 모델들을 모두 오픈소스로 공개해 점점 더 발전 속도가 가속화되고, 프론티어 모델에 근접하는 모델들이 나오는 것이 정말 놀라운데요. Qwen 팀은 본인들의 모델을 홍보하는 차원에서라도, “우리 모델을 자율 주행 기술에 적용하니 이런 좋은 성능이 나왔다”라고 말함과 동시에, 자율 주행 기술 분야에 LLM을 도입하는 재밌는 시도들이 흥미롭네요!

#Qwen #QwenDrive #LLM #VLA #AutoDriving

블로그: https://qwen.ai/blog?id=qwen-drive-1.0

논문: https://arxiv.org/abs/2609.00111

논문에서 말한 한계점 같은 경우엔, 아래 세 가지로 설명하고 있습니다!

첫째, 즉각성에 대한 판단 부족.

갑자기 돌발적으로 나타난 상황에서는 급제동을 해야하고, 멀리서 신호가 빨간불이 돼 천천히 감속해야 하는 상황처럼, 어떤 시간적 범위(Temporal scope)로 행동을 취해야 하는지에 대한 불안정하다고 합니다.

둘째, 추론하는 텍스트와 생성하는 실시간 궤적 간의 불일치 문제.

말로 설명하는 주행 근거(“앞차를 따라 감속합니다”)와 실제로 차가 그리며 나아가는 물리적 궤적(선)이 항상 100% 완벽하게 일치하지는 않는다고 합니다. 생각한 이유와 손발(핸들 조작)이 따로 놀 때가 있어, ‘말한 이유대로 실제로 운전했는가’에 대한 인과적 일관성을 강제하는 장치가 더 필요하다는 지적입니다.

셋째, 작업(Task)별 입력 방식의 차이로 인한 상호 시너지 한계.

현재 모델은 3D 인지, 대화(VQA), 운전 계획(Planning)을 한 몸에서 처리하지만, 각 작업을 수행할 때 들어가는 카메라 해상도나 참조하는 영상 프레임 수 같은 입력 조건들이 제각각 나뉘어 있습니다. 이 설정들이 완전히 하나로 통일되지 않다 보니, 눈으로 보고(인지) 말로 생각하고(추론) 직접 운전하는(계획) 각 기능들이 서로를 더 완벽하게 밀어주고 끌어주는 데는 아직 한계가 있다고 합니다.

가장 오래 마음에 남았던 이야기는 이것이었습니다. 아직도 백화점 매장에서는 고객 정보를 종이에 손으로 적어 관리하는 곳이 적지 않다는 이야기였습니다. 브랜드도, 제품 사이클도, 마케팅도 빠르게 움직이는 곳인데, 일하는 방식만큼은 여전히 사람 베이스라는 말씀이었습니다.

정작 아쉬웠던 것은 그 다음 이야기였습니다.

그럼에도 AX에 나서는 기업들은 SI 회사에 결코 적지 않은 비용을 들여 시스템을 구축한다고 합니다. 그런데 몇 달 뒤에 받아보는 결과물은 대부분 ‘회사 통합 대시보드’에 가깝다고 하셨는데요. 숫자는 잘 모여 있고 화면도 깔끔하지만, 그것으로 일하는 방식이 바뀌지는 않았다는 말씀이었습니다.

이는 SI 프로젝트의 구조와도 맞닿아 있다고 생각합니다. 프로젝트는 ‘산출물’을 정의하고 납품하는 방식으로 진행되는데, 산출물로 정의하기 가장 쉬운 것이 결국 화면이기 때문입니다. 그때 뵌 담당자분께서도 바로 그 지점에서 깊은 고민을 하고 계셨습니다. 무엇이 필요한지는 이미 또렷하게 알고 계셨으나, 어디서부터 손을 대야 할지가 막막하다고 하셨던 말씀이 오래 마음에 남았습니다.

대시보드는 이미 일어난 일을 보여주는 도구이고, 워크플로우는 앞으로 일어날 일을 만들어내는 도구라고 생각합니다. AX의 결과물이 ‘화면’이 아니라 ‘일이 돌아가는 방식’이어야 하는 이유가 여기에 있다고 믿습니다.

요즘은 무언가를 만들어내는 일 자체가 우스울 만큼 빨라졌습니다. 고객 관리 화면이 필요하다면, 그것은 더 이상 몇 달이 걸리는 프로젝트나 외주의 대상이 아니라, 필요하다고 이야기하는 자리에서 곧바로 만들어지는 것이 됩니다.

시작점은 기술이 아니라고 생각합니다. 어떤 도구를 어떻게 도입할지보다, 우리 도메인 안에서 무엇이 진짜 문제인지를 찾는 일이 먼저입니다. 그 문제 하나가 또렷해지면 만드는 일은 오히려 그 뒤에 따라옵니다.

그렇기에 AX를 이끄는 자리는 도메인 안에 있어야 한다고 생각합니다. 그 일을 매일 하고 있는 사람만이 무엇이 진짜 불편한지 알기 때문입니다. 개발자도 마찬가지로, 이제는 개발 그 자체보다 도메인을 얼마나 넓게 이해하고 품을 수 있는지가 더 큰 전문성으로 주목받고 있습니다.

수기로 적던 고객 정보를 화면으로 옮기는 것은 AX의 시작일 뿐입니다. 그 정보가 쌓이는 순간부터 다음 액션이 어떻게 만들어지게 할까를 고민하고, 빠르게 직접 만들어 실제 업무에서 실험해보는 것까지가 AX라고 생각합니다.

요즘 가장 많이 받는 질문이 이것입니다. “우리 조직은 AXIT 같은 플랫폼을 직접 만드는 게 나을까요, 아니면 활용하는 게 나을까요?”

정답을 하나로 드리기는 어렵습니다. 회사마다 가진 자원도, 데이터가 쌓여온 모양도, 사람들이 일하는 방식도 모두 다르기 때문입니다. 그래서 어느 쪽이 옳다고 말씀드리기보다, 기회비용을 잘 따져보시길 권해드립니다.

기회비용을 따지려면 먼저 판단의 기준이 서 있어야 하는데, 사실 그 기준을 세우는 일이 가장 어렵습니다. 그런 이야기가 필요하실 때는 언제든 편하게 연락 주셔도 좋습니다. 각자의 상황에서 가장 합리적인 선택으로 나아가실 수 있도록 돕고 싶습니다.

다만 어느 쪽을 택하시든, 그 고민을 시작하셨다는 것만으로 이미 한 걸음 나아가신 것이라고 생각합니다.

여러분의 AXIT를 응원합니다. 감사합니다!

#AXIT #AI #AX

정말 많은 리더분들께서 참석해주셨습니다. 처음이라 많이 긴장했는데, 끝까지 집중해주시고 적극적으로 참여해주셔서 정말 감사했습니다! 또한 이렇게 멋진 데뷔 무대를 마련해주신 유쾌한반란, 엠와이소셜컴퍼니(MYSC), 유니크굿컴퍼니에 진심으로 감사의 말씀을 드립니다.

앞선 순서에서는 MYSC 김정태 대표님과 유니크굿컴퍼니 송인혁 대표님께서 AX 시대를 맞이한 각 기업의 AI 성장 스토리를 멋지게 풀어주셨습니다. 이어서 저는 그 여정을 한 걸음씩 실제로 밟아가는 방법을 나눴습니다. 요즘 가장 주목받는 AI 모델들로 어떻게 유의미한 결과를 만들어내는지, 더 나아가 유니크굿컴퍼니에서 AXIT를 실무에 어떻게 활용하고 있는지 공유하고, 참석자분들과 다 함께 직접 사용해보는 시간도 가졌습니다!

세션 진행 중에도, 끝난 뒤에도 많은 분들께서 다가와 인사를 나누며 진지한 질문들을 건네주셨습니다. “어떤 AI 모델을 사용하는 게 좋을까요?”, “우리 같은 조직은 AXIT 같은 플랫폼을 직접 개발하는 게 나을까요, 아니면 활용하는 게 나을까요?” 질문의 형태는 저마다 달랐지만, 결국 ‘무엇을 선택해야 하는가’라는 같은 고민이 담겨 있었는데요. 그 모든 질문에, 지금 같은 AI 시대에 저는 이런 대답을 드리고 싶습니다.

AX는 AI Transformation인 동시에, AI Experience이기도 하다고 생각합니다. AI가 하루가 다르게 좋아지는 시대에, 경험해보지 않은 것을 판단할 수는 없습니다. 판단을 서두르기보다, 그 경험에 먼저 투자하시길 권해드립니다.

어떤 모델이 좋을지, SaaS를 직접 개발할지 활용할지에 대한 답도 결국 직접 써본 경험 위에서 나온다고 믿습니다.

최근 들었던 워크숍 중 가장 인상 깊고 도움이 많이 되었다고 말씀해주신 분들도 계셨습니다. 따뜻한 말씀 하나하나에 큰 힘을 얻었습니다. 정말 감사드립니다. 긴 시간 강의 들으시느라 고생 많으셨고, 이 행사가 새로운 소셜 임팩트를 만들어가는 의미 있는 첫 단추가 되었기를 진심으로 바랍니다.

이 AX 워크숍의 다음 과정도 빠른 시일 내에 준비해 찾아뵙겠습니다. 감사합니다!

#유쾌한반란 #소셜임팩트포럼 #AX전환 #AI에이전트 #AXIT

이번 주 금요일에는 조금 특별한 자리에 갑니다. 🫣

유쾌한반란 소셜임팩트포럼 회원사 대상으로 “리더들을 위한 AI 에이전트 교육” 워크샵을 하거든요.

솔직히 요즘 AI 교육을 찾아보면, LLM은 이런 원리고… 프롬프트는 늘 목표를 뚜렷하게 줘야하고… PPT 슬라이드는 이런 식으로 만들어야 AI티를 뺄 수 있습니다… 이런 얘기로 가득한 듯싶습니다. 쉬운 건 다 아는 내용인 것 같고, 어려운 건 무슨 이야기인지 모르겠고…

AI가 요즘 겉잡을 수 없는 속도로 발전하니, 조직 차원에서도 요즘 좋다는 Claude/ChatGPT 계정을 개인당 하나씩 지급해주는 추세입니다. 물론 그게 잘못됐다는 이야기는 전혀 아닙니다!

하지만 조직의 대표, 심지어는 대표가 아니더라도 조직 구성원 중에서도 무언가 사업 모델을 검증해보고 싶을 때 성능 면에서도, 다같이 실시간으로 공유하면서 만들기에도 아쉽습니다.

그리고 이 고민을 실제로 만든 게 유니크굿에서 쓰고 있는 AXIT 플랫폼이에요. 누구든지 “게임 만들어볼까?” “AI 채팅 기능 붙여볼까?”라는 아이디어가 떠올랐을 때, 채팅으로 말만 하면 클로드와 코덱스가 붙어 완성된 결과를 멋지게 보여줍니다!

이런 AI 에이전트로 어디까지 할 수 있을지, AXIT 같은 플랫폼은 어떻게 활용하는지 공유해보려고 합니다!

#유쾌한반란 #소셜임팩트포럼 #AX전환 #AI에이전트 #AXIT

이후 중학교·고등학교 수학에서는 ‘확률과 통계(Probability and Statistics)’ 과목을 통해 이를 체계적으로 학습하게 되며, 대학교 수학 과정에서도 계속 다뤄질 만큼 중요한 분야로 자리 잡고 있다.

이번 포스트에서는 그 확률과 통계의 첫걸음이라 할 수 있는 평균(Mean), 분산(Variance), 표준편차(Standard Deviation)을 다루고자 한다.

평균(Mean)

분산과 표준편차 개념은 와닿진 않더라도 ‘평균’이라는 개념은 우리 일상 속에서 정말 많이 접한다. ‘평균 성적’, ‘~의 평균값’

사전에 따르면 평균은 아래와 같이 정의된다.

「1」 여러 사물의 질이나 양 따위를 통일적으로 고르게 한 것.
「2」 『수학』 여러 수나 같은 종류의 양의 중간값을 갖는 수. 산술 평균, 기하 평균, 조화 평균 따위가 있는데 일반적으로 산술 평균을 이른다. ≒연등, 중수, 평균값, 평균수, 평균치.
- 국립국어원 표준국어대사전

보통 우리가 말하는 평균은 ‘산술 평균(arithmetic mean)’을 이른다고 한다.

이번 포스트에서는 산술 평균 개념만을 다루겠다. 다른 기하 평균과 조화 평균은 다른 포스트에서 다루겠다.

자료들을 대표하는 값인 대푯값(representative value)은 평균(mean), 중앙값(median value), 최빈값(mode), 사분위수(quartile), 백분위수(percentile), 절사평균(trimmed mean) 등이 있다.

그중에서도 ‘평균’은 대표적으로 사용되는 대푯값이다.

평균(산술 평균)은 자료들의 값을 다 더한 후, 자료의 개수로 나눈 값이다. 이를 수식으로 아래와 같이 표현할 수 있다.

확률과 통계 과목에서 평균값을 나타내는 기호로 μ(mu)와 x̄(x bar)를 많이 봤을 텐데, μ 값은 모집단(Population)에서의 평균(모평균)을, x̄ 값은 모집단에서 추출한 표본(Sample)에서의 평균(표본평균)을 말한다.

여기서, ‘확률변수’를 배운 사람이라면

‘기댓값(Expected Value)’은 평균이다.

라는 말을 들어본 적 있을 것이다.

기댓값이란, 같은 확률 실험을 같은 조건에서 여러 번 반복했을 때 그 결과값들의 평균이 점점 가까워지는 값을 말한다.

‘기댓값’은 다음 ‘확률변수’ 포스트에서 더 자세히 다루도록 하겠다.

예를 들어, 공평한 동전을 던질 때 앞면이 나오면 1,000원을 받고, 뒷면이 나오면 0원을 받는 게임을 생각해 보자. 앞면과 뒷면이 나올 확률은 각각 50%이다. 몇 번 던져 보면 0원만 받을 수도 있고, 1,000원만 받을 수도 있지만, 이 실험을 충분히 많이 반복하면 한 번당 벌게 되는 돈의 평균은 500원 근처로 모이게 된다. 처음에는 얼마나 얻을지는 모르지만, 더 많이 동전을 던져보면 평균적으로 500원을 얻을 수 있을 것이다. 기댓값을 계산해보면 500원을 얻을 수 있는 것을 알 수 있다.

위 그래프는 Python으로 랜덤 함수를 활용해 시행을 10만 번 돌렸을 때 평균값을 구한 그래프이다.

즉, 1,000원과 0원이 각각 절반의 확률로 나올 때 그 “평균값”이 500원이 되는 것처럼, 기댓값을 ‘확률변수가 가지는 평균’으로 이해할 수 있다.

분산(Variance)

우리는 일상 속에서 ‘~는 잘 분산되어 있다’라는 말을 쓰곤 한다. 여기서 말하는 ‘분산’은 풀어서 말하면 ‘고르게 잘 퍼져있다’와 같은 의미로 쓸 수 있을 것이다. 예를 들어, 아래와 같은 A반과 B반의 10명의 시험 성적(0 ~ 100점) 자료가 있다고 하자.

• A반: 78, 79, 80, 80, 81, 82, 79, 81, 80, 80
• B반: 50, 60, 70, 80, 90, 90, 95, 100, 85, 80

A반의 성적들은 눈으로 보기에도 대체로 80점 근처에 있는 것을 확인할 수 있다. 반면, B반은 정확히 몇 점 근처에 성적이 분포하고 있다고 말하긴 어렵다.

내가 생각하는 ‘분산’의 의미는 이런 것이다. B반과 같은 자료가 하나 더 있다면, 어느 반이 더 고르게 분포되어 있는지 수치적으로 나타낼 수 있는 지표.

「3」 『수학』 통곗값과 평균값의 차이인 편차를 제곱하여 얻은 값들의 산술 평균. 분산이 작으면 자료는 평균값 주위에 모여 있게 되고, 분산이 크면 자료 가운데 평균값에서 멀리 떨어진 것이 많게 된다.

- 국립국어원 표준국어대사전

수학적 ‘분산’의 정의를 이해하기 위해서는 통곗값과 평균값의 차이인 ‘편차’, 이들을 제곱해 얻은 값들의 평균값임을 이해해야 한다.

‘편차(Deviation)’라는 것을 구하기 위해서는 자료들의 ‘평균’을 얻어야 하며, 각각의 자료값들마다 평균과의 차이를 구해준다. 수식으로 표현한다면 아래와 같을 것이다.

위를 제곱해 모두 더해준 뒤, 자료의 개수(n)로 나눠주면(평균), ‘분산’을 구할 수 있다. 수식으로는 아래와 같을 것이다.

위 성적 자료들을 가지고, 분산을 구하면 아래와 같다.

• A반 분산: 1.2
• B반 분산: 225.0

분산이 적을 수록, 자료들이 고르게 분포됨을 알 수 있다.

다만, 여기서 포인트는 편차의 ‘제곱’ 합이라는 것이다. 왜 그냥 차이를 더해도 될 것 같은데 제곱해서 더하는 것일까?

우선, 가장 큰 문제로는, 편차의 합은 0이라는 것이다. 정말로 그런지 궁금한 사람들은 위 제시했던 성적 자료들을 가지고 편차를 구해서 더해봐라. 위 자료들의 평균은 80이다. 편차를 구해 모두 더해보면 결국 0으로 수렴한다.

수학적으로 증명하려고 한다면 아래와 같다.

위를 통해 편차의 합은 0이라는 것을 알 수 있다.

그렇다면, “음수와 양수가 서로 상쇄되는 문제”만 해결하면 되니, 언뜻 보면 편차를 절댓값 씌워 더하면 될 것 같은 생각이 든다. 그런데 왜 하필이면 제곱일까?

여기에는 여러 가지 이유가 있다.

1. 수학적으로 다루기 훨씬 편하다.

미분을 아는 사람이라면 알겠지만, 절댓값 |x| 함수는 첨점(cusp point)이 생기기 때문에 모든 구간에서 미분이 가능하지 않다. (x = 0에서 미분 불가능)

우린 이후에 오차의 합이 최소가 되도록 하는 값을 찾아야 한다. 이때 미분을 사용하면 최소값을 효율적으로 구할 수 있기 때문에, 함수가 미분 가능하다는 점이 중요하다.

확률·통계의 많은 이론이 ‘평균’을 중심에 두고 전개되다 보니, 자연스럽게 제곱편차가 표준 선택이 된 셈이다.

2. 성립하는 성질들이 뒤따라온다.

이후 확률변수를 다루면서 아래와 같은 성질들을 다룰 것이다.

• Var(aX + b) = a²Var(X)
• Var(X + Y) = Var(X) + Var(Y) (확률변수 X와 Y가 독립일 때)

이러한 관계들은 ‘제곱편차’를 사용하기 때문에 성립한다. 덕분에 여러 확률변수의 합 등을 다룰 때, 분산을 손쉽게 계산하고 나중에 배울 신뢰구간·가설검정 같은 이론도 체계적으로 전개할 수 있다.

3. 큰 편차가 더 강하게 반영한다.

제곱을 활용했다는 것은 곧, ‘기하급수적’인 변화를 기대할 수 있다.

평균에서 멀리 떨어진 극단값이 있을 경우, 분산은 이를 더욱 크게 반영해주는 효과를 기대할 수 있다.

위같은 이유로 파생되는 평균 오차 제곱(Mean Squared Error, MSE) 등과 같은 개념들이 많이 나온다. 이런 이야기들은 통계 및 머신러닝 쪽으로 들어가면 끝도 없어, 관심있는 사람들은 꼭 한번씩 찾아보며 확장하는 것을 추천한다.

표준편차(Standard Deviation)

표준편차는 확률과 통계 과목을 공부하면서 정말 많이 만날 친구이니, 개념을 잘 정리하길 바란다.

표준편차는 간단히 말해, 분산에 제곱근을 씌운 값이다.

『수학』 자료의 분산 정도를 나타내는 수치. 분산의 양의 제곱근으로, 표준 편차가 작은 것은 평균값 주위의 분산의 정도가 작은 것을 나타낸다.

- 국립국어원 표준국어대사전

보통 모집단에서의 표준편차는 σ(sigma)를, 추출한 표본에서의 표준편차는 s를 쓴다. 분산은 표준편차의 제곱이기 때문에, 각각 σ², s²을 쓰게 된다.

그렇다면 분산이 분산이지, 왜 ‘분산의 정도’를 표준편차라는 걸로 다시 정의하는 걸까?

우선, 퍼져있는 정도의 ‘단위’를 맞춰주기 위함도 있다.

분산은 편차의 제곱합. 제곱이라는 것에 초점을 맞춰 생각해보자.

예를 들어 자료 하나에 대한 편차의 제곱이 아래와 같다고 하자. (성적에 대한 자료이므로, 단위는 ‘점’이라고 하자.)

(75점 – 80점)² = (-5점)² = 25점² ?

우리가 살면서 “~점이다.” 라는 것은 이해해도, ‘~점²’라는 것을 본 적이 있던가?

이러한 점에서 제곱근을 적용함으로써 우리가 직관적으로 이해할 수 있는 단위로 맞춰주기 위함이 있다. 위 예시만 보더라도, ‘25점²만큼의 퍼짐이 있다.’라는 것보다는 ‘평균으로부터 5점 내외에 분포하고 있다.’라는 말이 더욱 와닿을 것이다.

스케일을 우리가 직관적으로 이해할 수 있게끔 줄여주고, 단위를 맞춰줄 수 있다는 점에 있어서 표준편차는 분산의 제곱근을 사용한다.

또한, 이후 다룰 ‘정규분포’에서도 분산보다는, 표준편차로 일반화된다.

단순히 생각해봐도, 공식에서 분산의 제곱근을 쓰는 것보다는 제곱근이 이미 적용된 표준편차를 쓰는 것이 편할 것이다.

물론 쓰기 편하기 때문에 표준편차를 쓰는 것은 아니지만, 정규분포에서 ‘분포의 폭’을 직접적으로 조절하는 건 σ(표준편차)이다.

나중에 정규분포를 다룰 때 더 자세히 다루겠지만, 위와 같은 공식에서도 직접적으로 쓰이는 것은 σ(표준편차)이다.

표준편차는 자료를 전체적인 관점에서 해석할 때, 평균으로부터 얼마만큼의 정도로 분포하고 있는지 말할 수 있는 지표이다.

마무리

다음 포스트에서는 앞서 많이 언급했던 ‘확률변수(Random Variable)’와 ‘기댓값(Expected Value)’에 대해서 다뤄보도록 하겠다.