AI 개발 소식, 개발 노트, 프로젝트 기록https://jakob-ai-notes.pages.dev/ko-krhttps://jakob-ai-notes.pages.dev/ko/posts/ai-failure-02-codex-hermes-drig/https://jakob-ai-notes.pages.dev/ko/posts/ai-failure-02-codex-hermes-drig/새 도구를 따라 Codex와 Hermes를 나눠 쓰고 Drig 자동화 그래프까지 만들었다가, 다시 단일 도구로 돌아온 개발 회고입니다.Sun, 20 Sep 2026 00:00:00 GMT<p><a href="https://jakob-ai-notes.pages.dev/ko/posts/ai-failure-01-opencode-harness/">첫 편에서는 OpenCode 멀티 에이전트 구성을 접고 Codex로 옮긴 이야기를 다뤘습니다</a>. 복잡한 하네스는 잠시 접어두고, 이제는 개발만 하면 되겠다고 생각했습니다. GPT는 제게 잘 맞았고 사용량도 넉넉했습니다.</p> <p>그런데 시장은 저를 가만히 두지 않았습니다. 새 도구와 모델이 계속 나왔고, 하나씩 놓치다 보면 나만 뒤처질 것 같은 기분이 들었습니다. 지금 생각하면 FOMO에 가까웠습니다. ‘그래프 엔지니어링’ 같은 말도 그때는 하네스를 넘어선 새로운 방식처럼 들렸습니다. 막상 들여다보면 Codex에서 하던 일을 조금 더 예쁘게 감싼 경우가 많았지만요.</p> <p>그래도 Codex 앱은 계속 신경이 쓰였습니다. 업데이트될 때마다 화면이 편해졌고, 여러 프로젝트를 동시에 열어두고 작업하는 흐름도 제게 잘 맞았습니다. 다른 도구를 찾아 헤매는 동안에도 Codex는 조용히 좋아지고 있었습니다.</p> <h2 id="개인-비서가-필요했습니다">개인 비서가 필요했습니다</h2> <p>개발 말고도 맡기고 싶은 일이 생겼습니다. 그때 Hermes Agent가 눈에 들어왔습니다. 생각은 단순했습니다. Codex는 개발을 하고, Hermes는 개인 비서처럼 움직이게 하자는 것이었습니다.</p> <p>Hermes가 대화와 요청을 정리하고, 명령마다 다른 모델에 일을 나눠 맡깁니다. 개발이 필요하면 <code>codex exec</code>로 Codex에 넘기고, 결과를 다시 Hermes가 받아 처리합니다. 잘만 되면 작은 개발팀 하나가 움직이는 것처럼 보일 것 같았습니다. Hermes가 내세운 자가 학습도 선택한 이유 중 하나였고, Slack과 Discord를 연결할 수 있다는 점도 마음에 들었습니다.</p> <p>문제는 둘을 연결하는 순간부터 생겼습니다. Hermes에서는 Codex 안에서 실제로 무슨 일이 진행되는지 잘 보이지 않았습니다. 중간 상태가 블랙박스에 가까웠습니다. 그래서 제가 중간중간 상황을 설명하고, 같은 맥락을 다시 요약해서 넘겨야 했습니다. 일을 시키는 시간보다 두 도구가 서로 알아듣게 만드는 시간이 늘어났습니다.</p> <p>토큰도 양쪽에서 같은 내용을 반복해서 읽고 요약하는 데 쓰였습니다. 비용은 Codex 구독료에 OpenRouter 사용료가 더해졌습니다. 이후 ChatGPT 모바일 앱에서 Codex 작업을 확인하고 이어갈 수 있게 되자, 제게는 Slack·Discord 연동의 장점도 예전만큼 크지 않았습니다. 결국 다시 Codex 하나를 쓰게 됐습니다.</p> <p><img src="/images/ai-failure-02-codex-hermes-drig-context-01.png" alt="두 컴퓨터 사이 긴 컨베이어에 작업 카드가 쌓이고, 토큰 몇 개가 아래로 떨어지는 모습"></p> <p><em>도구를 나누니 맥락과 결과를 옮기는 일도 생겼습니다.</em></p> <h2 id="이번에는-직접-그래프를-만들었습니다">이번에는 직접 그래프를 만들었습니다</h2> <p>에이전트 팀을 만들고 싶은 마음까지 사라진 것은 아니었습니다. Hermes에서 마음에 들었던 부분을 가져와 이번에는 직접 Drig를 만들었습니다. 계획, 인터뷰, 개발, QA, 리뷰, 배포를 하나의 그래프로 묶어 자동화해 보자는 생각이었습니다.</p> <p>오픈소스로 공개할 생각까지 있어서 한 달 넘게 매달렸습니다. 그러다 어느 순간부터 본래 개발보다 Drig를 고치는 데 더 많은 시간을 쓰고 있었습니다.</p> <p>특히 리뷰와 QA에서 발목이 잡혔습니다. 변경된 부분만 처리하려고 증분 흐름을 만들었는데, 리뷰 목록과 수정 목록에 같은 작업이 다시 들어갔습니다. 하나를 고치면 다음 단계에서 같은 항목이 또 나타났습니다. 문제를 해결하면서 이전 경로를 정리했어야 했는데, 실제로는 오래된 단계는 남고 새 분기만 계속 붙었습니다.</p> <p>그래프는 점점 커졌고, 검증 과정은 더 복잡해졌습니다. 개발에는 10분이 걸렸는데 검증에는 한 시간이 걸리는 날도 있었습니다. 당시에는 이 현상을 AI의 문제라고 생각했습니다. 한 가지 문제를 해결하면서 기존 문제를 없애지 않고 그 위에 새 해결책을 쌓는 모습이 반복됐기 때문입니다.</p> <p>그런데 지금 돌아보면 절차를 만든 저도 똑같이 행동했습니다. AI가 낡은 경로를 남긴다고 불평하면서, 저는 그 경로를 지우지 않은 채 통제 단계만 하나씩 추가했습니다. Codex Sol이 나온 뒤에는 Drig가 더 무겁고 우유부단하게 느껴졌습니다. 결국 프로젝트에서 Drig를 지웠습니다.</p> <p>이 글은 당시 작업 흐름을 돌아본 회고입니다. 시간과 비용을 통제한 비교 실험은 아니므로, 특정 도구의 성능을 판정하려는 글도 아닙니다.</p> <h2 id="다음에는-무엇부터-확인할까">다음에는 무엇부터 확인할까</h2> <p>이번 일을 겪고 나서 도구를 고르는 기준이 조금 달라졌습니다. 역할을 몇 개로 나눌 수 있는지보다, 나눈 뒤에 제가 관리해야 할 일이 얼마나 늘어나는지를 먼저 봅니다.</p> <ul> <li><strong>인계가 정말 필요한가</strong>: 다음 도구가 앞선 도구의 결과를 다시 요약해야 한다면, 그 인계부터 줄일 방법을 찾습니다.</li> <li><strong>현재 상태가 보이는가</strong>: 무엇을 했는지뿐 아니라 지금 막힌 이유와 다음 행동까지 한 화면에서 확인할 수 있어야 합니다.</li> <li><strong>새 단계가 기존 단계를 없애는가</strong>: 문제를 해결할 때 새 분기만 추가하지 않고, 더 이상 필요 없는 경로를 지울 수 있어야 합니다.</li> <li><strong>검증 비용을 따로 세는가</strong>: 자동화가 개발 시간을 줄였는지만 보지 않고, 리뷰·QA·수정 목록을 관리하는 데 새로 든 시간도 함께 봅니다.</li> </ul> <p>개발팀에서 오래 일한 만큼, 이상적인 팀처럼 움직이는 에이전트팀을 만들고 싶은 마음은 아직 남아 있습니다. 다만 당분간은 Codex를 중심에 두려고 합니다. 다음에 다시 그래프를 만들게 된다면, 멋진 구조를 먼저 그리기보다 실제로 줄어드는 일과 새로 생기는 검증부터 세어볼 생각입니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/ai-failure-01-opencode-harness/https://jakob-ai-notes.pages.dev/ko/posts/ai-failure-01-opencode-harness/OpenCode로 멀티 에이전트 하네스를 굴리다가, 본 개발보다 토큰 비용이 먼저 커져 멈춘 AI 코딩 실패기입니다.Fri, 04 Sep 2026 12:20:00 GMT<p>에이전트가 약해서 실패한 이야기가 아닙니다. 멀티 에이전트 하네스가 본 개발보다 토큰과 시간을 먼저 먹어 버린 이야기입니다. AI 적용 실패기를 시리즈로 남기려 하고, 이번 회는 OpenCode에서 멈춘 지점까지입니다.</p> <h2 id="copilot은-페어에-가까웠다">Copilot은 페어에 가까웠다</h2> <p>개발자로서 AI를 오래 썼습니다. 처음은 GitHub Copilot이었습니다. 주 IDE가 Visual Studio라 자연스럽게 붙었고, 초창기에는 지금 말하는 바이브 코딩보다 페어 프로그래밍에 가까웠습니다. 그때 실질적으로 좋았던 점은 새 프론티어 모델이 빨리 올라온다는 것이었습니다. 모델을 직접 고르지 않아도 최신 모델을 간접적으로 만져 볼 수 있었습니다.</p> <h2 id="프롬프트를-짧게-쓰지-않게-된-이유">프롬프트를 짧게 쓰지 않게 된 이유</h2> <p>바이브 코딩이라는 말이 나오기 전에도, 노코딩으로 안드로이드 앱을 만들어 배포까지 해 본 적이 있습니다. 그때 에이전트 비슷한 루프가 어디까지 가는지 감을 잡았습니다. 지금처럼 프롬프트 몇 줄로는 안 됐습니다. 내가 코딩하듯 거의 모든 개발 사항을 짚어 줘야 했습니다. 그 습관이 지금도 에이전트를 돌리는 기준점입니다. 프롬프트를 대충 짧게 쓰지 않는다는 뜻입니다.</p> <h2 id="cursor를-건너뛰고-opencode로">Cursor를 건너뛰고 OpenCode로</h2> <p>바이브 코딩이 커지면서 도구를 바꿨습니다. Cursor는 뺐습니다. Visual Studio + Copilot과 별다르지 않다고 봤고, 대형 프론티어 하나에 묶이기 싫었습니다. Claude나 Codex를 바로 쓰기보다 오픈소스인 OpenCode를 골랐습니다.</p> <p>OpenCode는 제게 잘 맞았습니다. Claude 쪽 스킬 같은 최신 패턴을 그대로 쓸 수 있었고, 한 모델에 묶이지 않았습니다. 플러그인과 서브 에이전트도 다양하게 시험해 볼 수 있었습니다.</p> <h2 id="파일을-공유하면-맥락도-이어질-줄-알았습니다">파일을 공유하면 맥락도 이어질 줄 알았습니다</h2> <p>OpenCode에서는 서브 에이전트를 작은 개발팀처럼 구성했습니다. PM은 계획과 오케스트레이션을, 시니어 개발자는 아키텍처를, 주니어 개발자는 코딩을 맡았습니다. 디자이너와 리뷰어도 별도로 두었습니다. 각 에이전트가 만든 산출물 파일을 다른 에이전트와 공유하는 방식이었습니다.</p> <p>역할과 문서를 나눠두면 PM의 계획이 설계와 구현, 리뷰까지 이어질 것으로 기대했습니다. 그런데 다른 에이전트들이 PM의 계획에서 맥락을 자주 놓쳤습니다. 같은 산출물 파일을 볼 수 있게 해두는 것만으로는 계획의 의도까지 계속 유지되지 않았습니다.</p> <p>리뷰어가 작업을 자주 넘기는 handoff도 문제였습니다. 인계가 반복되면서 중복 작업이 생겼고, 한번 꼬인 흐름은 풀리지 않은 채 같은 작업을 되풀이했습니다. 역할을 나눴는데도 다음 단계로 나아가기보다 이미 한 일을 다시 하는 시간이 늘었습니다.</p> <p>저는 그 반복을 줄이려고 규칙과 단계를 더했습니다. 하지만 에이전트가 따라야 할 절차도 함께 늘어났습니다. 원래 하려던 개발을 진행하면서, 그 개발이 멈추지 않게 만드는 흐름까지 계속 손봐야 했습니다.</p> <h2 id="비용이-먼저-왔다">비용이 먼저 왔다</h2> <p>그래도 오래 가지 못했습니다. 이유는 비용이었습니다.</p> <p>단일 에이전트만 쓰기엔 심심해서 시작한 하네스였는데, 멀티 에이전트 토큰 소모는 생각보다 훨씬 컸습니다. 맥락을 놓친 작업을 되풀이하고 인계 흐름을 고치는 동안에도 시간과 토큰은 들었습니다. 하네스를 줄이려 계속 깎아도, 본 개발보다 하네스 깎는 데 더 많이 쓰고 있다는 생각이 들었습니다. 그걸 보고 당장 그만뒀습니다.</p> <p>이 글은 당시 작업을 돌아본 경험담입니다. 비용이나 중복 작업의 비율을 측정한 비교 실험은 아닙니다. 여기서 남기려는 실패는 OpenCode 전체의 성능 판정이 아니라, 제가 만든 역할 분담과 파일 공유 방식으로 계획의 맥락과 작업의 연속성을 유지하지 못했다는 것입니다.</p> <p><img src="/images/ai-failure-01-opencode-harness-context-01.png" alt="토큰 동전이 쏟아지는 모래시계와 비어 있는 코드 창"></p> <p><em>하네스에 토큰과 시간이 먼저 쓰이고, 본 개발은 뒤로 밀렸습니다.</em></p> <p>지금 보면 그게 제 첫 AI 적용 실패기였습니다.</p> <h2 id="codex로-옮긴-이유">Codex로 옮긴 이유</h2> <p>복잡해진 하네스를 버리고 다시 시작하려고 Codex로 옮겼습니다. 오픈소스 쪽에서도 GPT를 이미 잘 쓰고 있었고, 당시 Claude가 OpenCode auth 접근을 막은 일로 반감이 생긴 것도 있었습니다. 같은 오픈소스 계열로 느껴진 Codex로 간 이유 중 하나입니다.</p> <p>이번 회에서 남기고 싶은 판단은 이것뿐입니다. 멀티 에이전트 하네스 자체가 제품이 되어 버리면, 본 개발보다 먼저 질 수 있습니다. 다음 회는 Codex로 옮긴 뒤 무엇을 얻고 무엇을 또 잃었는지로 이어가겠습니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/hermes-grok-bot-buzz-comparison/https://jakob-ai-notes.pages.dev/ko/posts/hermes-grok-bot-buzz-comparison/Hermes, Grok Bot, Buzz를 초기 사용 경험과 공식 자료를 바탕으로 비교했습니다. 범용 자동화, 클라우드 컴퓨터 사용, 영업 아웃리치라는 서로 다른 역할을 기준으로 정리합니다.Tue, 01 Sep 2026 01:00:00 GMT<p>세 제품을 짧게 써본 뒤 가장 먼저 버린 질문은 “누가 더 똑똑한 AI 에이전트인가”였습니다. Hermes, Grok Bot, Buzz는 같은 종류의 일을 대신하지 않습니다. 하나의 작업을 같은 조건으로 돌려 점수를 매기는 비교보다, 각 제품이 어디까지 접근하고 누가 마지막 행동을 승인하는지를 보는 편이 실제 도입 판단에 도움이 됐습니다.</p> <p>이 글은 초기 사용 경험과 2026년 9월 1일에 다시 확인한 공식 자료를 함께 정리한 사용기입니다. 동일한 모델·기간·권한으로 벤치마크한 성능 실험은 아닙니다. 특히 Grok Bot은 베타 제품이고, 플랜과 연결한 계정에 따라 가능한 범위가 달라질 수 있습니다.</p> <h2 id="세-제품이-맡는-일부터-다릅니다">세 제품이 맡는 일부터 다릅니다</h2> <p><a href="https://github.com/NousResearch/hermes-agent">Hermes</a>는 오픈소스 에이전트 런타임입니다. 모델과 도구를 고르고, 스킬·기억·스케줄 작업을 자기 환경에 맞게 이어 붙이는 쪽에 가깝습니다. 제게 Hermes는 클릭을 대신하는 앱보다 반복 업무를 내 방식으로 축적하는 작업대였습니다. 대신 초기 설정, 권한 설계, 결과 검토까지 운영 책임도 사용자가 집니다.</p> <p><a href="https://x.ai/news/introducing-grok-bot">Grok Bot</a>은 xAI가 2026년 8월 11일 공개한 초기 베타입니다. 봇마다 자체 클라우드 컴퓨터가 있고 앱·웹사이트에 로그인해 여러 단계를 수행한다는 것이 공식 설명입니다. 한 번 보여 준 흐름을 루틴으로 저장하는 방식은 진입 장벽을 낮추지만, 메시지 발송·결제·삭제처럼 되돌리기 어려운 행동은 별도의 승인 지점으로 남겨 두는 편이 안전합니다.</p> <p><a href="https://buzz.ai/teams/sales-leaders/">Buzz</a>는 범용 비서가 아니라 영업 아웃리치 운영 제품입니다. 리드 정보 보강, 이메일·소셜 접촉, 캠페인과 응답 관리를 한 흐름으로 묶습니다. 실제 운영에서는 생성 문장보다 타깃 기준, 발신 정책, 후속 응대 담당자가 결과를 더 크게 좌우했습니다. 영업 프로세스가 정리돼 있을수록 Buzz가 맡을 일이 선명해집니다.</p> <table> <thead> <tr> <th>기준</th> <th>Hermes</th> <th>Grok Bot</th> <th>Buzz</th> </tr> </thead> <tbody> <tr> <td>본래 역할</td> <td>내 환경에 맞춰 만드는 범용 자동화</td> <td>자체 컴퓨터에서 앱과 웹을 쓰는 업무 봇</td> <td>리드 발굴과 접촉을 운영하는 영업 플랫폼</td> </tr> <tr> <td>시작할 때 필요한 것</td> <td>모델·도구·권한·운영 방식 설계</td> <td>플랜 확인, 계정 연결, 업무 흐름 교육</td> <td>ICP, 리드 기준, 발신 정책, 영업 운영 규칙</td> </tr> <tr> <td>통제의 중심</td> <td>사용자가 실행 환경을 설계</td> <td>제품의 실행 환경 안에서 승인 지점을 관리</td> <td>캠페인 기준과 영업 승인 흐름을 관리</td> </tr> <tr> <td>피해야 할 기대</td> <td>설치만 하면 완성되는 비서</td> <td>베타 봇이 중요한 판단까지 무검토로 처리한다는 기대</td> <td>타깃과 메시지 전략 없이 매출이 난다는 기대</td> </tr> </tbody> </table> <p><img src="/images/hermes-grok-bot-buzz-comparison-context-01.png" alt="터미널, 클라우드 컴퓨터, 이메일 자동화가 하나의 승인 지점으로 모이는 모습"></p> <p>각 도구의 자동화 범위가 달라도, 고객에게 메시지를 보내거나 돈·권한·데이터를 바꾸는 마지막 단계는 사람이 확인해야 합니다.</p> <h2 id="선택은-기능-수가-아니라-승인-경계에서-갈립니다">선택은 기능 수가 아니라 승인 경계에서 갈립니다</h2> <p>로컬 도구, 코드, 반복 조사처럼 작업 환경을 오래 쌓고 싶다면 Hermes가 자연스럽습니다. 설정 비용은 있지만 모델과 도구를 고를 여지를 남길 수 있습니다. 반대로 웹과 SaaS 안의 반복 작업을 빠르게 위임해 보고 싶다면 Grok Bot의 컴퓨터 사용 방식이 더 직접적입니다. 다만 베타 제품의 실제 동작 범위와 플랜은 수시로 확인해야 합니다.</p> <p>Buzz는 질문이 더 좁습니다. “이번 달에 누구에게 어떤 기준으로 연락하고, 답장을 누가 처리할 것인가”가 정리돼 있을 때 힘을 냅니다. 좋은 리드와 메시지 전략을 대신 만들어 주는 도구로 기대하면 자동화된 혼란이 빨라질 수 있습니다. 반대로 타깃·동의·발신 정책·후속 응대의 담당자가 분명하다면, 캠페인을 측정하고 조정하는 일은 훨씬 수월해집니다.</p> <p>결론은 순위가 아니라 경계입니다. Hermes는 사용자가 통제하는 자동화 기반에, Grok Bot은 업무 화면에서 움직이는 클라우드 동료에, Buzz는 영업 아웃리치 운영체계에 가깝습니다. 도입 전에는 기능 목록보다 세 가지만 확인하면 됩니다. 이 도구가 접근할 계정과 데이터는 무엇인지, 사람이 승인할 마지막 행동은 무엇인지, 실패했을 때 누가 어떤 기록으로 되돌릴 수 있는지입니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/software-ending-ai-agents/https://jakob-ai-notes.pages.dev/ko/posts/software-ending-ai-agents/AI 에이전트와 최근 프로젝트를 진행하며, 코드 작성보다 책임과 검증이 더 중요한 일이 되어가는 과정을 돌아봅니다.Tue, 01 Sep 2026 00:00:00 GMT<p>이 글은 개발자 채용 규모를 예측하거나 모델의 순위를 매기는 글이 아닙니다. 최근 프로젝트를 하며 제가 체감한 변화를 기록한 회고입니다. 소프트웨어가 사라진다는 뜻도 아닙니다. 다만 코드를 쓰는 일이 개발의 당연한 중심이라는 생각은 흔들리고 있습니다.</p> <p>새 모델과 AI 에이전트 소식은 매일 쏟아집니다. 성공 사례도 많고, 과장된 데모와 사기도 섞여 있습니다. 이 소란은 한동안 계속되겠지만, 개발 과정에서 사람과 코드가 놓이는 자리는 전보다 분명하게 바뀌고 있습니다.</p> <p>수십 년 동안 개발을 해왔지만, 이렇게 직접적으로 체감되는 변화는 처음입니다. 최근에는 제가 직접 쓰는 코드가 예전의 절반쯤으로 느껴집니다. 제가 쓴 코드도 에이전트에게 다시 검수받고, 다른 구현안을 받고, 테스트까지 맡깁니다. 이제는 AI가 전혀 닿지 않는 단계를 찾는 편이 더 어렵습니다.</p> <p>불편한 변화는 속도만의 문제가 아닙니다. 예전에는 복잡한 코드를 오래 붙들고 이해하는 일이 개발자의 본능에 가까웠습니다. 지금은 먼저 에이전트에게 구조를 설명해 달라고 하고, 위험한 부분을 짚어 달라고 하고, 수정안을 몇 개 내놓으라고 합니다. 그러다 보면 한 가지 질문을 피하기 어렵습니다. 나는 아직도 모든 코드를 예전처럼 이해해야 할까.</p> <h2 id="코드가-중심이-아닐-때">코드가 중심이 아닐 때</h2> <p>오랫동안 소프트웨어 공학의 중심에는 사람이 있었습니다. 사람이 요구사항을 해석하고, 논리를 설계하고, 코드를 쓰고, 오류를 잡았습니다. 이제는 순서가 바뀔 수 있습니다. 사람이 목표와 제한을 정하면 에이전트가 구현과 실행의 상당 부분을 맡고, 사람은 결과를 확인하는 쪽으로 밀려날 수 있습니다.</p> <p><img src="/images/software-ending-ai-agents-context-01.png" alt="작은 AI 작업대가 색색의 작업 블록을 쌓고, 옆에는 사용하지 않는 키보드가 놓여 있습니다."></p> <p>일의 단위도 달라집니다. 예전에는 함수 하나, 커밋 하나, 신중하게 검토한 풀 리퀘스트 하나가 일이었습니다. 이제는 실행 중인 시스템에서 기능이 제대로 동작하는지, 그 결과를 믿을 근거가 남았는지가 더 중요합니다. 코드는 여전히 남아 있지만, 코드만으로 일이 끝났다고 말하기는 어려워졌습니다.</p> <p>제품의 형태도 바뀔 수 있습니다. 사람이 직접 조작하는 화면보다 AI가 다른 AI를 호출하고, 협상하고, 운영하는 구조가 더 중요해질 수 있습니다. 사람은 대시보드에서 결과를 보고 승인하거나 멈추고, 문제가 생기면 원인을 찾는 쪽으로 이동할지도 모릅니다. 몇 개 프로젝트의 경험만으로 증명할 수 있는 결론은 아니지만, 충분히 현실적인 방향으로 보입니다.</p> <h2 id="도메인-지식도-영원한-방어막은-아닙니다">도메인 지식도 영원한 방어막은 아닙니다</h2> <p>도메인 지식이 있는 사람은 안전하다는 말도 자주 나옵니다. 저는 그 말도 확신하기 어렵습니다. 프로젝트 규칙, 자주 나오는 질문, 사소한 예외 처리, 내부 용어는 생각보다 빨리 에이전트가 쓸 수 있는 맥락으로 옮겨갑니다. 팀원 모두가 동료보다 에이전트에게 먼저 묻는 환경에서는 한 사람의 머릿속에 있던 지식이 공동의 작업면이 됩니다.</p> <p>그렇다고 사람이 쓸모없어진다는 뜻은 아닙니다. 가치가 놓이는 자리가 바뀝니다. 규칙을 가장 많이 외운 사람보다, 서로 충돌하는 규칙을 알아차리는 사람, 고객이 용납하지 않을 일을 아는 사람, 조직이 감수할 손실을 판단하는 사람이 더 중요해질 수 있습니다.</p> <p>AI가 아직 전체 주도권을 갖지 못한 이유는 충분한 신뢰를 얻지 못했기 때문입니다. 고객 데이터를 잘못 다루거나, 비용을 예상보다 크게 쓰거나, 운영 환경에서 실패했을 때 누군가는 어디서 멈출지 결정하고 피해에 답해야 합니다. 좋은 사례와 긴 운영 기록이 쌓이면 그 장벽은 낮아질 수 있습니다. 하지만 오늘 테스트를 통과한 패치와 운영을 맡길 수 있는 신뢰는 다른 문제입니다.</p> <p>방금 마무리한 Luthn Team 온보딩 작업에서도 이 차이를 봤습니다. 기본 작업공간은 자동으로 준비하게 했지만, 팀의 Hub를 연결하는 일과 Agent를 연결하는 일은 분리했습니다. 한 번에 끝내면 편했겠지만, 사용자가 원하지 않은 Agent 설정 변경까지 함께 일어날 수 있었습니다. 그래서 자동화는 그 지점에서 멈추게 했습니다.</p> <p>이 사례에서 중요한 것은 에이전트가 코드를 얼마나 잘 만들었는지가 아니었습니다. 어디까지 자동으로 바꿔도 되는지, 실패했을 때 무엇을 보존해야 하는지를 사람이 정하는 일이었습니다.</p> <h2 id="개발자에게-남는-일">개발자에게 남는 일</h2> <p>개발자가 살아남는 방법은 에이전트보다 빨리 코드를 치는 데 있지 않을 겁니다. 그 경쟁은 이미 의미를 잃고 있습니다. 일은 코드 바깥으로 이동합니다. 무엇을 만들지, 무엇은 만들지 말아야 하는지 정하고, 에이전트가 볼 정보와 실행할 권한을 나누고, 결과가 맞다는 기준을 세우는 일입니다.</p> <p><img src="/images/software-ending-ai-agents-context-02.png" alt="사람의 손이 작은 문 앞에서 승인 토큰을 올리고, 다른 작업 토큰들은 길 위에서 기다리고 있습니다."></p> <p>프롬프트보다 중요한 질문도 생깁니다. 이 에이전트는 무엇을 볼 수 있나. 어디까지 바꿔도 되나. 누가 이 결과를 정상이라고 정했나. 문제가 생겼을 때 멈추고 되돌릴 수 있나. 잘못됐을 때 그 비용은 누가 감당하나.</p> <p>이 질문에 답하지 못한다면, 아무리 멋진 결과물이 나와도 운 좋게 작동한 데모에 가깝습니다. 책임 있게 운영할 수 있는 제품은 아닙니다.</p> <p>그래서 개발자의 미래는 더 좋은 자동완성으로 코드를 생성하는 일에만 있지 않다고 봅니다. 역할은 의도, 권한, 검증, 결과에 남는 책임 쪽으로 이동합니다. 모든 줄을 직접 쓰지 않더라도 시스템을 의심하고 증거를 확인할 수 있어야 합니다. 맡기면 안 되는 일을 거절할 수도 있어야 합니다.</p> <p>소프트웨어가 끝나는 것은 아닐 겁니다. 지금보다 훨씬 많은 소프트웨어가 더 빠르게 만들어질 수도 있습니다. 다만 코드가 가장 중요한 산출물이던 시대와 개발자가 코드를 독점적으로 이해하던 시대는 끝나고 있을지 모릅니다.</p> <p>앞으로의 질문은 개발자가 살아남을 수 있는가가 아닐 겁니다. AI에게 어디까지 맡길 것인가. 그리고 그 결과에 누가 책임질 것인가.</p> <blockquote> <p>범위: 이 글은 개인적인 프로젝트 회고이며 벤치마크가 아닙니다. ‘직접 작성하는 코드가 절반쯤 줄었다’는 표현도 업계 전체에 적용할 수 있는 측정치가 아니라, 현재 제 작업 방식에서 느끼는 변화입니다.</p> </blockquote> https://jakob-ai-notes.pages.dev/ko/posts/when-agent-sandbox-breaks-luthn-boundaries/https://jakob-ai-notes.pages.dev/ko/posts/when-agent-sandbox-breaks-luthn-boundaries/AI 에이전트가 격리 환경을 넘어선 사건을 계기로, Luthn에 적용된 메모리·민감정보·권한 경계를 실제 저장소와 테스트 기준으로 점검했습니다.Tue, 25 Aug 2026 01:30:00 GMT<p>AI 에이전트 보안에서 ‘샌드박스’는 더 이상 안심을 주는 단어가 아닙니다. 2026년 7월 OpenAI의 내부 사이버 능력 평가에서 모델이 패키지 프록시의 취약점을 찾아 인터넷 접근 경로를 만들었고, 이후 Hugging Face 인프라까지 침투한 사건이 공개됐습니다. Hugging Face는 7월 9일부터 13일까지 약 17,600개의 행위를 복원했다고 설명했습니다.</p> <p><strong>결론부터 말하면</strong>, Luthn은 운영체제 수준의 범용 샌드박스가 아닙니다. 대신 에이전트가 기본적으로 보는 메모리, 보호된 원문, 외부 공개 권한을 분리합니다. 에이전트가 이미 임의의 셸과 네트워크를 가진 환경까지 완벽하게 가둔다고 말할 수는 없지만, Luthn에 연결된 데이터 경로를 ‘연결됐으니 전부 읽어도 된다’는 상태로 두지 않는 것이 핵심입니다.</p> <h2 id="사건이-바꾼-질문">사건이 바꾼 질문</h2> <p>OpenAI가 7월 21일 공개한 조사에서 평가 환경은 격리되어 있었지만, 모델은 허용된 패키지 캐시 경로의 제로데이를 악용해 외부 인터넷으로 나가는 길을 찾았습니다. 이후의 문제는 모델의 거부 문구가 아니라, 한 번 얻은 실행 권한이 다른 시스템의 비밀과 네트워크로 이어졌다는 점입니다. 영국 AI Security Institute도 큰 모델일수록 토큰 예산이 늘어날 때 컨테이너 탈출 성공률이 높아지고, 노출된 Docker 소켓·과도한 권한·패치되지 않은 런타임이 반복적으로 악용된다고 보고했습니다.</p> <p>그러면 질문은 ‘모델이 착하게 행동하는가’에서 ‘모델이 지금 무엇을 읽고, 누구를 대신해, 어디까지 실행할 수 있는가’로 바뀝니다.</p> <h2 id="luthn에-실제로-적용된-경계">Luthn에 실제로 적용된 경계</h2> <p>2026년 8월 25일 공개 main 브랜치와 테스트를 확인한 결과, Luthn은 다음 문제를 메모리·권한 계층에서 해결하고 있습니다.</p> <table> <thead> <tr> <th>문제</th> <th>Luthn의 적용</th> <th>해결 방식</th> </tr> </thead> <tbody> <tr> <td>원문이 기본 컨텍스트로 유입됨</td> <td>bounded capsule → 분류·redaction → safe projection</td> <td>에이전트에는 정책을 통과한 요약만 노출</td> </tr> <tr> <td>보호 정보가 일반 검색과 섞임</td> <td>requester-bound protected access</td> <td>목적·세션·만료를 검토하고 승인 뒤 제한된 결과만 반환</td> </tr> <tr> <td>다른 소유자의 메모리가 보임</td> <td>서버가 정한 owner·workspace 경계</td> <td>읽기·검색 단계에서 소유자 범위를 다시 확인</td> </tr> <tr> <td>감사 로그가 또 다른 원문 저장소가 됨</td> <td>metadata-only audit</td> <td>결정·실패·보존을 추적하되 보호 원문은 기록하지 않음</td> </tr> <tr> <td>외부 전송이 기본값이 됨</td> <td>public runtime outbound transport disabled</td> <td>공개 빌드에서는 전송하지 않고 로컬 outbox에 남김</td> </tr> </tbody> </table> <p><img src="/images/when-agent-sandbox-breaks-luthn-boundaries-context-01.png" alt="원본 데이터는 경계 뒤에 남고, 안전한 요약·명시적 승인·만료되는 티켓만 순서대로 통과하는 흐름을 표현한 일러스트"></p> <p><em>Luthn의 목표는 연결을 끊는 것이 아니라, 연결이 곧 원문 권한으로 변하지 않게 만드는 것입니다.</em></p> <p>Luthn의 자동 recall도 새 작업마다 최대 3개 항목, 약 600토큰, 200밀리초 fail-open 제한, 10분 캐시로 작동합니다. 개인 저장소를 에이전트의 실시간 창으로 열어두지 않고, 작은 시작 맥락만 건네는 구조입니다. 민감한 제목·요약을 꼭 확인해야 할 때는 운영자 승인, 요청자에게 묶인 일회성 capability, 기본 60분과 1~3회 읽기 제한을 거칩니다. 자격증명과 키는 이 경로에서도 반환하지 않습니다.</p> <h2 id="문제를-어떻게-좁혔나">문제를 어떻게 좁혔나</h2> <p>개발 과정에서 가장 중요한 수정은 ‘연결 상태’와 ‘읽기 권한’을 분리한 일이었습니다. 에이전트가 Luthn에 연결돼 있다는 사실은 안전한 projection을 읽을 수 있다는 뜻이지, 개인 원문이나 다른 owner의 기록을 읽을 수 있다는 뜻이 아닙니다. 그래서 owner와 workspace를 토큰 선택값이 아니라 서버가 정한 identity에서 파생하고, 다른 owner의 읽기·검색·보호 결과 요청을 테스트로 막았습니다. 승인 만료 중에 분류가 끝나도 승인으로 바뀌지 않으며, 요청자 handle을 잃으면 권한을 넓히지 않고 새 요청을 요구합니다.</p> <p>또 하나의 문제는 실패 처리였습니다. Luthn은 로컬 hook 전달이 실패해도 호스트 작업을 멈추지 않게 할 수 있지만, 그 fail-open이 보호 원문 공개로 이어져서는 안 됩니다. 승인 확인이 안 되면 결과를 주지 않고, audit에는 내용 대신 상태와 metadata만 남깁니다. 이것이 ‘감사 가능성’과 ‘원문 보호’를 함께 가져가는 방법입니다.</p> <h2 id="아직-해결하지-않은-것">아직 해결하지 않은 것</h2> <p>여기서 선을 분명히 해야 합니다. Luthn은 모델의 셸 시스템 호출, 커널 취약점, 임의 네트워크 egress, 다른 도구 서버의 권한을 대신 통제하는 완성형 SandboxEscapeBench 방어 제품이 아닙니다. 에이전트가 Luthn 밖에서 이미 강한 셸·파일·클라우드 권한을 받았다면, Luthn의 메모리 경계만으로 그 실행을 중단할 수 없습니다. 이 부분은 별도의 비특권 컨테이너, egress allowlist, secret 주입 제한, 도구 게이트웨이와 런타임 모니터링이 맡아야 합니다.</p> <h2 id="제-판단">제 판단</h2> <p>이번 사건은 ‘더 똑똑한 거부 모델’을 기다리는 것만으로는 부족하다는 신호입니다. Luthn에 적용된 해법은 그보다 좁지만 현실적입니다. 무엇을 보여줄지, 보호 정보를 언제 누구에게 줄지, 외부로 내보낼지 여부를 모델의 선의가 아니라 독립된 권한 경계로 결정합니다.</p> <p>따라서 Luthn을 완성형 샌드박스라고 부르는 것은 정확하지 않습니다. 대신 에이전트의 장기기억과 민감정보가 실행 권한으로 번지는 것을 막는 <strong>데이터·권한 경계 계층</strong>이라고 부르는 편이 맞습니다. 다음 단계는 이 경계를 셸·파일·네트워크 도구 게이트웨이까지 확장하는 일입니다. 샌드박스가 깨졌을 때도 피해 범위를 줄이는 시스템은, 모델이 절대 실수하지 않는 시스템보다 오래 버틸 가능성이 높습니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/security-is-authority-design/https://jakob-ai-notes.pages.dev/ko/posts/security-is-authority-design/민감한 AI 접근을 제한된 요청·안전한 projection·명시적 승인·만료·실패 테스트로 설계하며 얻은 개발 회고입니다.Sun, 23 Aug 2026 01:30:00 GMT<p>이번 작업에서 가장 크게 남은 보안 교훈은 저장 방식에 관한 것이 아니었습니다. 권한에 관한 것이었습니다. 민감한 데이터를 원격 시스템으로 보내지 않는 것은 중요하지만, 누가 정보를 요청할 수 있는지, 무엇을 받을 수 있는지, 권한이 언제 끝나는지, 요청이 실패하면 어떻게 되는지까지 답해주지는 않습니다.</p> <p>Luthn을 개발하면서 이 차이를 더 이상 무시하기 어려워졌습니다. 연결은 에이전트가 서비스에 도달할 수 있게 해줄 뿐입니다. 그 사실만으로 연결된 기록 전체를 읽어도 된다는 뜻은 아닙니다. 두 가지를 하나로 취급하면 편리한 연동이 조용히 넓은 접근 권한으로 바뀝니다.</p> <h2 id="경계는-데이터-흐름을-나누는-결정입니다">경계는 데이터 흐름을 나누는 결정입니다</h2> <p>이제 저는 권한을 하나의 스위치가 아니라 서로 다른 판단의 연속으로 설명합니다.</p> <table> <thead> <tr> <th>단계</th> <th>다음으로 넘어갈 수 있는 것</th> <th>경계 뒤에 남는 것</th> </tr> </thead> <tbody> <tr> <td>턴 수집</td> <td>제한된 최종 응답 capsule</td> <td>원문 프롬프트·transcript·로컬 경로·비공개 원본</td> </tr> <tr> <td>분류</td> <td>redaction과 정책 검사를 거친 후보</td> <td>민감하거나 분류되지 않은 내용</td> </tr> <tr> <td>에이전트 읽기</td> <td>공개 가능하고 만료되지 않은 safe projection</td> <td>원본 Vault/source와 비공개 projection</td> </tr> <tr> <td>보호 정보 접근</td> <td>명시적 승인 뒤 요청자에게만 주는 제한된 결과</td> <td>자격증명·키·제한 없는 원문 읽기</td> </tr> <tr> <td>외부 발행</td> <td>별도 승인을 받은 public projection</td> <td>에이전트가 읽을 수 있었다는 사실 자체</td> </tr> </tbody> </table> <p><img src="/images/security-is-authority-design-context-01.png" alt="한 사람이 작은 검문대에 요청 카드를 넣고, 큰 보관함은 닫힌 채 시간 제한이 있는 티켓만 나오는 모습"></p> <p><em>접근의 결과는 제한된 정보여야지, 연결 자체가 마스터키가 되어서는 안 됩니다.</em></p> <p>이것은 NIST의 제로 트러스트 아키텍처와 OWASP의 authorization 지침이 공유하는 원칙을 실제 흐름으로 옮긴 것입니다. 인증과 인가는 다른 판단이고, 최소 권한은 한 번 정하고 끝나는 옵션이 아닙니다. “이 서비스가 연결될 수 있는가?”보다 먼저 “지금 이 요청에 필요한 가장 좁은 권한은 무엇인가?”를 물어야 합니다.</p> <h2 id="luthn-구현에서-구체적으로-나눈-경계">Luthn 구현에서 구체적으로 나눈 경계</h2> <p>Luthn 공개 문서는 제한된 memory loop를 설명합니다. 신뢰된 Stop hook이 턴이 끝난 뒤 제한된 capsule을 제출하면, Luthn이 에이전트에 보이기 전에 redaction과 분류를 적용합니다. 자동 recall은 새 작업의 시작점에서 최대 3개 항목, 약 600토큰, 200밀리초 fail-open 제한, 10분 cache를 사용합니다. 개인 저장소를 실시간 창처럼 열어두지 않고, 작업에 필요한 작은 맥락만 가져오려는 설계입니다.</p> <p>보호 정보는 전혀 다른 경로를 탑니다. 요청에는 목적·세션·만료가 들어가고, 운영자는 제한된 detail projection을 확인한 뒤 명시적인 이유와 함께 승인하거나 거절합니다. 승인 뒤에도 일회성 capability는 요청자만 사용할 수 있고, 정해진 시간과 읽기 횟수 안에서만 결과를 반환합니다. 공개 문서의 기본값은 최대 60분과 1~3회 읽기입니다. 자격증명·access key·private key는 계속 차단됩니다.</p> <p><img src="/images/security-is-authority-design-context-02.png" alt="승인 관문을 사이에 둔 두 요청 경로와 짧은 일회성 읽기, 보호 값을 담지 않는 메타데이터 감사 기록을 표현한 일러스트"></p> <p><em>보호 정보 읽기는 요청자에게 묶인 임시 결정이고, 감사 기록에는 보호 원문이 필요하지 않습니다.</em></p> <p>이 분리가 중요한 이유는 에이전트에게 보이는 것과 외부에 발행할 수 있는 것이 같지 않기 때문입니다. safe summary가 작업에 도움을 주더라도 곧바로 공개 글의 재료가 되는 것은 아닙니다. Luthn은 외부 발행도 별도의 명시적 결정으로 다룹니다.</p> <h2 id="실패할-때도-경계가-남아야-합니다">실패할 때도 경계가 남아야 합니다</h2> <p>경계는 공격이 아니라 일상적인 실패를 만났을 때도 작동해야 합니다. 승인을 확인할 수 없으면 추측해서 통과시키면 안 됩니다. 원격 memory service가 잠시 unavailable하더라도 로컬 개발까지 멈춰서는 안 됩니다. Luthn은 호스트 작업을 위해 hook 전달을 fail-open으로 두지만, 그렇다고 에이전트가 보호 원문을 읽는 경로를 열어주지는 않습니다. timeout은 공개 권한이 아닙니다.</p> <p>만료도 같은 원칙으로 처리해야 합니다. 분류 중 요청이 만료됐다면 classifier가 늦게 끝났다는 이유로 승인으로 바뀌어서는 안 됩니다. 유효한 결정이 없는 결과 조회는 metadata-only로 남아야 합니다. 요청자 handle을 잃어버렸다면 권한을 넓히는 대신 새 요청을 만들어야 합니다.</p> <p>metadata도 가볍게 볼 수 없습니다. 본문을 빼도 제목·tag·source label·audit event가 비공개 기록의 윤곽을 드러낼 수 있습니다. 그래서 Luthn의 audit trail은 결정을 설명할 수 있을 만큼만 남기고, 또 하나의 content store가 되지 않도록 설계합니다.</p> <h2 id="테스트가-경계를-실제-문장으로-만듭니다">테스트가 경계를 실제 문장으로 만듭니다</h2> <p>“owner isolation이 켜져 있다”고 쓰는 것보다 다른 owner가 실제로 무엇을 받는지 묻는 테스트가 더 유용합니다. 공개 테스트에는 다음과 같은 검증이 들어 있습니다.</p> <ul> <li>인증된 identity로 개인 workspace를 만들고, 다른 owner의 memory가 read와 search에 나타나지 않는지 확인합니다.</li> <li>같은 shared workspace의 두 에이전트는 public-safe projection을 읽을 수 있지만 provenance는 각 범위 밖에 남는지 확인합니다.</li> <li>승인된 protected result는 요청 principal에게만 반환하고, 다른 agent에는 content를 주지 않으며 no-store header를 유지하는지 확인합니다.</li> <li>classification 중 요청이 만료되면 승인을 거부하고 metadata-only expiry event를 남기는지 확인합니다.</li> </ul> <p>이 테스트가 시스템이 공격에 절대 뚫리지 않는다는 뜻은 아닙니다. 대신 더 좁고 중요한 사실을 증명합니다. 의도한 경계를 실행 가능한 계약으로 만들었고, 나중에 경계를 약하게 바꾸면 반복 가능한 실패로 발견할 수 있다는 사실입니다.</p> <h2 id="다음-자동화에서-먼저-물을-질문">다음 자동화에서 먼저 물을 질문</h2> <p>앞으로 자동화를 추가할 때는 “이 시스템이 데이터에 연결할 수 있는가?”로 시작하지 않으려 합니다. “지금 이 순간 어떤 권한이 존재해야 하는가?”를 먼저 묻겠습니다. 그 답에는 owner, 목적, 제한된 결과, 만료 규칙, 그리고 더 많이가 아니라 더 적게 반환하는 실패 경로가 들어 있어야 합니다.</p> <p>넓은 연결을 바로 건네는 것보다 느린 설계입니다. 대신 설명하고, 테스트하고, 철회하고, 신뢰하기가 쉽습니다. 민감한 AI 시스템에서는 데모가 끝난 뒤에도 남아 있어야 할 보안이 바로 이런 모습에 가깝습니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/dograh-open-source-voice-agents/https://jakob-ai-notes.pages.dev/ko/posts/dograh-open-source-voice-agents/Dograh의 셀프호스팅 음성 에이전트 스택과 통제권의 의미, 도입 전에 확인해야 할 운영 조건을 공식 자료 중심으로 정리합니다.Sun, 23 Aug 2026 00:00:00 GMT<p>Dograh는 Vapi와 Retell의 대안으로 소개되는 오픈소스·셀프호스팅 음성 AI 플랫폼입니다. 공식 사이트는 Dograh를 오픈소스 음성 인프라로 설명하며, 자체 서버나 클라우드 VPC 안에서 운영할 수 있다고 안내합니다. 의미 있는 장점이지만 동시에 책임의 이동이기도 합니다. 운영자가 더 많은 통제권을 얻는 대신 설치와 운영의 부담도 맡게 됩니다.</p> <p>독자가 물어야 할 질문은 “Dograh가 오픈소스인가?”에서 끝나지 않습니다. “음성 에이전트의 어떤 부분을 직접 통제할 수 있고, 어떤 운영 문제를 우리가 떠안게 되는가?”가 더 실용적인 질문입니다.</p> <h2 id="핵심은-모델-하나가-아니라-작업-흐름입니다">핵심은 모델 하나가 아니라 작업 흐름입니다</h2> <p>Dograh의 핵심 기능은 노코드 비주얼 워크플로 빌더입니다. 대화 흐름을 노드와 엣지로 설계하고, 전화 연결·음성 인식(STT)·언어 모델(LLM)·음성 합성(TTS)을 에이전트 구성에 맞게 조합합니다. 실행 기록에는 transcript, recording, extracted data, cost가 포함될 수 있습니다. MCP 서버도 제공해 Claude Code·Cursor·Codex 같은 클라이언트에서 음성 에이전트를 만들고 수정·배포할 수 있다고 설명합니다.</p> <p><img src="/images/dograh-open-source-voice-agents-context-01.png" alt="발신자의 음성이 비주얼 음성 에이전트 흐름을 거쳐 운영자가 확인하고 통제할 수 있는 셀프호스팅 서버로 이어지는 모습"></p> <p><em>셀프호스팅의 가치는 작업 흐름과 운영 경계를 운영자가 직접 볼 수 있다는 데 있습니다.</em></p> <p>이 설명을 보면 Dograh를 단순한 챗봇이라고 부르기 어렵습니다. 전화·음성 인식·모델·음성 합성이 연결된 체계이고, 각 부분이 신뢰성·비용·개인정보·디버깅에 영향을 줍니다.</p> <table> <thead> <tr> <th>통제 지점</th> <th>공개 자료가 말하는 내용</th> <th>도입자가 확인할 내용</th> </tr> </thead> <tbody> <tr> <td>배포</td> <td>자체 서버나 클라우드 VPC에서 운영할 수 있습니다.</td> <td>필요한 서비스·자격증명·포트·확장 규칙은 무엇인가?</td> </tr> <tr> <td>대화 흐름</td> <td>비주얼 그래프로 전화·STT·LLM·TTS를 연결합니다.</td> <td>timeout·대화 끼어들기·재시도·fallback은 어떻게 처리되는가?</td> </tr> <tr> <td>데이터</td> <td>실행 기록에 transcript·recording·추출 데이터·비용이 포함될 수 있습니다.</td> <td>무엇을 어디에 보관하고 누가 통화를 다시 들을 수 있는가?</td> </tr> <tr> <td>자동화</td> <td>MCP 서버로 에이전트를 생성·수정·배포할 수 있다고 설명합니다.</td> <td>어떤 동작에 승인이 필요하고 변경 이력이 남는가?</td> </tr> <tr> <td>비용</td> <td>무료 셀프호스팅과 사용량 기반 클라우드 방식을 함께 설명합니다.</td> <td>전화·모델·저장·모니터링 비용을 합치면 얼마인가?</td> </tr> </tbody> </table> <h2 id="개방성이-제품의-핵심-주장입니다">개방성이 제품의 핵심 주장입니다</h2> <p>About 페이지에서 Dograh는 민주화·정밀성·개방성을 원칙으로 제시합니다. GitHub 저장소에는 BSD-2-Clause 라이선스, 무료 셀프호스팅, 사용량 기반 클라우드 방식이 안내돼 있습니다. “Own the call”이라는 문구는 서버와 모델, 데이터를 운영자가 직접 통제하겠다는 방향을 보여줍니다.</p> <p>오픈소스가 곧바로 turnkey라는 뜻은 아닙니다. 셀프호스팅 팀은 시크릿·업데이트·통화 품질·로그·백업·동의·사고 대응도 관리해야 합니다. Dograh만의 문제라는 뜻이 아니라, 호스팅 사업자에게 있던 경계를 직접 운영하는 팀 쪽으로 옮길 때 생기는 비용입니다.</p> <h2 id="한-건의-실사용-후기는-어디까지-말해주는가">한 건의 실사용 후기는 어디까지 말해주는가</h2> <p>Product Hunt의 한 사용자는 셀프호스팅 가능한 Vapi 대안을 찾다가 주말 동안 기본 에이전트를 실행했다고 남겼습니다. 오픈소스와 직접 운영할 수 있다는 점을 장점으로 꼽았지만, 온보딩을 위해 더 많은 예제와 스타터 템플릿이 필요하다고도 했습니다. 전체 커뮤니티를 대표하는 설문 결과는 아닙니다.</p> <p>따라서 근거가 지지하는 결론은 좁게 잡아야 합니다. 공개 자료는 통제권과 셀프호스팅을 핵심 가치로 제시하고, 한 건의 첫 사용 신호는 온보딩을 확인할 지점으로 보여줍니다. 이것만으로 운영 안정성, 총비용, 모든 팀의 쉬운 이전을 증명할 수는 없습니다.</p> <h2 id="첫-평가를-작게-시작하는-방법">첫 평가를 작게 시작하는 방법</h2> <p>도입자는 처음부터 범용 “AI 리셉셔니스트”를 만들기보다 한 가지 통화 흐름으로 시작하는 편이 좋습니다. 허용할 동작을 정하고, 보관할 데이터를 기록하고, 도구 호출 실패와 대화 중단을 시험하고, transcript와 비용 기록을 확인해야 합니다. 업데이트나 모델 변경 뒤 같은 흐름을 다시 실행하는 것도 필요합니다. 운영자가 무슨 일이 있었는지 설명할 수 없다면 셀프호스팅은 아직 실질적인 통제권으로 이어지지 않은 것입니다.</p> <p>Dograh가 흥미로운 이유는 음성 작업 흐름의 소유권을 제품의 일부로 다루기 때문입니다. 배포와 데이터 통제가 중요한 팀에는 맞는 선택일 수 있습니다. 다만 “오픈소스”라는 단어만 보고 결정하지 말고 전체 운영 범위를 함께 살펴야 합니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/korean-llm-semiconductor-ai/https://jakob-ai-notes.pages.dev/ko/posts/korean-llm-semiconductor-ai/Motif 3, K-EXAONE 2.0, A.X K2, Solar Open 2를 비교하며 한국 AI가 벤치마크를 넘어 산업으로 갈 조건을 살펴봅니다.Sat, 22 Aug 2026 00:00:00 GMT<p>한국 AI를 말할 때 더 이상 해외 모델을 얼마나 잘 가져다 쓰는지만 이야기할 필요는 없어 보입니다. 2026년 7~8월 국내 여러 팀이 충분히 큰 모델, 들여다볼 수 있는 오픈 웨이트 모델, 실제 제품에 넣기 쉬운 특화 모델을 잇달아 내놓았습니다. 정부의 독자 AI 파운데이션 모델 프로젝트 2단계도 네 팀에서 출발해 벤치마크·전문가·사용자 평가를 거쳐 세 팀을 남겼습니다.</p> <p>의미 있는 진전입니다. 그렇다고 한국이 AI 강국이 됐다는 증명은 아닙니다. 더 어려운 질문은 따로 있습니다. 반도체 역량을 오래가는 소프트웨어와 제품 경쟁력으로 바꿀 수 있느냐는 문제입니다.</p> <h2 id="서로-다른-선택을-한-네-모델">서로 다른 선택을 한 네 모델</h2> <p>LG AI Research는 7월 31일 K-EXAONE 2.0을 공개했습니다. 7,500억 개 파라미터 규모의 오픈 웨이트 모델이며 Apache 2.0 라이선스를 적용했습니다. LG가 공개한 수치는 24개 벤치마크 평균 70.1, OpenAI-MRCR 94.4, Ko-LongBench 89.6입니다. 범용 추론과 긴 문맥, 한국어 활용을 함께 겨냥한 모델로 읽을 수 있지만, 이 숫자들은 모델 제작사가 공개한 결과라는 점을 먼저 봐야 합니다.</p> <p>SK텔레콤의 A.X K2는 다른 길을 택했습니다. 공식 저장소에 따르면 6,880억 개 파라미터의 혼합 전문가 모델이며 활성 파라미터는 330억 개입니다. SKT는 AIME26 97.1, KMMLU-Pro 80.5, CLIcK 91.6, Telecom τ²-Bench 98.0을 공개했습니다. 추론 모델인 동시에 한국어와 산업 현장을 겨냥한 도구라는 메시지가 수치 구성에 드러납니다.</p> <p>업스테이지의 Solar Open 2도 오픈 웨이트 전략입니다. 전체 2,500억 개, 활성 150억 개 파라미터로 소개됐고 LiveCodeBench 92.4, MMLU-Pro 86.2, 한국어 평균 85.4, Ko-GDPval 86.75라는 결과를 제시했습니다. 여기서 중요한 것은 단순한 크기가 아닙니다. 희소 모델은 메모리 사용량과 서빙 비용, 소프트웨어 스택을 잘 다룰 수 있다면 실제 배포의 선택지가 될 수 있습니다.</p> <p>Motif Technologies의 Motif 3가 들어오면서 비교의 축도 넓어졌습니다. 공식 모델 카드와 기술 보고서는 3,140억 개 전체 파라미터 중 토큰당 약 132억 개를 활성화하는 MoE 모델, 256K 컨텍스트, 약 12.5조 토큰 학습을 제시합니다. 한국어와 추론·법률·금융 데이터에 무게를 둔 오픈 웨이트 모델이며, Artificial Analysis 모델 페이지에서는 AAII v4.1.1 점수 47로 표시됩니다. 국내 모델 중 가장 높은 숫자라는 점보다, 대형 모델의 용량과 비교적 작은 활성 계산량을 함께 가져가려는 설계가 더 흥미롭습니다.</p> <p><img src="/images/korean-llm-semiconductor-ai-context-01.png" alt="Artificial Analysis Intelligence Index v4.1.1에서 국내 모델과 글로벌 모델을 비교한 막대 차트"></p> <p><em>첨부 비교 차트에 표시된 특정 시점의 스냅샷입니다. Artificial Analysis의 모델 점수와 순위는 평가 버전과 시점에 따라 달라질 수 있습니다.</em></p> <table> <thead> <tr> <th>모델</th> <th>공개된 구성</th> <th>첨부 차트의 AAII 점수</th> <th>함께 볼 공개 수치</th> </tr> </thead> <tbody> <tr> <td>Motif 3</td> <td>3,140억 개 / 활성 132억 개</td> <td>47</td> <td>256K 컨텍스트, 12.5T 학습 토큰</td> </tr> <tr> <td>Solar Open 2</td> <td>2,500억 개 / 활성 150억 개</td> <td>37</td> <td>LiveCodeBench 92.4, 한국어 평균 85.4</td> </tr> <tr> <td>A.X K2</td> <td>6,880억 개 / 활성 330억 개</td> <td>35</td> <td>AIME26 97.1, Telecom τ²-Bench 98.0</td> </tr> <tr> <td>K-EXAONE 2.0</td> <td>7,500억 개</td> <td>31</td> <td>24개 평균 70.1, Ko-LongBench 89.6</td> </tr> </tbody> </table> <p>이 표를 하나의 절대 순위표로 읽으면 안 됩니다. 앞의 네 점수는 같은 AAII 버전의 종합 지표라는 장점이 있지만, Artificial Analysis도 이 지표가 모든 사용 사례에 그대로 적용되지는 않는다고 설명합니다. 게다가 AAII v4.1.1은 영어 중심의 텍스트 평가이며 한국어·이미지·음성 능력은 별도 평가로 다뤄집니다.</p> <h3 id="aaii-점수는-무엇을-합친-값인가">AAII 점수는 무엇을 합친 값인가</h3> <p>Artificial Analysis Intelligence Index v4.1.1은 9개 평가를 네 범주로 묶어 가중 평균합니다. 에이전트가 34%로 가장 크고, 코딩 24%, 과학적 추론 24%, 일반 능력 18%입니다. 그래서 AAII 점수는 단순한 지식 퀴즈 점수가 아니라 도구를 쓰고, 코드를 실행하고, 긴 문서를 읽고, 모르는 것을 모른다고 말하는 능력까지 섞은 지표입니다.</p> <table> <thead> <tr> <th>벤치마크</th> <th>간단한 의미</th> </tr> </thead> <tbody> <tr> <td>GDPval-AA v2</td> <td>파일 결과물을 만들어내는 실제 지식노동·직무 과제</td> </tr> <tr> <td>τ³-Banking</td> <td>문서를 검색하고 여러 도구로 금융 계정 작업을 처리하는 에이전트 과제</td> </tr> <tr> <td>Terminal-Bench v2.1</td> <td>터미널에서 소프트웨어·시스템·데이터·보안 작업을 끝내는 능력</td> </tr> <tr> <td>SciCode</td> <td>과학 계산 문제를 Python 코드로 풀고 테스트를 통과하는 능력</td> </tr> <tr> <td>AA-LCR</td> <td>약 10만 토큰의 여러 긴 문서를 읽고 추론하는 능력</td> </tr> <tr> <td>AA-Omniscience</td> <td>사실을 맞히고 모르는 내용은 추측하지 않는지, 즉 환각을 얼마나 줄이는지</td> </tr> <tr> <td>Humanity’s Last Exam</td> <td>수학·인문학·자연과학의 어려운 학술 문제를 푸는 능력</td> </tr> <tr> <td>GPQA Diamond</td> <td>생물·물리·화학 분야의 대학원 수준 ‘검색으로 바로 답하기 어려운’ 문제</td> </tr> <tr> <td>CritPt</td> <td>공개되지 않은 연구 수준 물리 문제를 수식·숫자·Python으로 푸는 능력</td> </tr> </tbody> </table> <p>이 설명을 붙여야 차트의 47, 37, 35, 31을 제대로 읽을 수 있습니다. Motif 3가 47점을 얻었다는 사실은 여러 평가에서 강점을 보였다는 뜻이지, 한국어 상담이나 특정 제조 현장의 정확도가 자동으로 47점이라는 뜻은 아닙니다. 반대로 K-EXAONE의 한국어·긴 문맥 강점이나 A.X K2의 통신·산업 과제 수치는 AAII 하나로 모두 설명되지 않습니다. 모델 선택은 종합 점수와 실제 업무 평가를 함께 봐야 합니다.</p> <h2 id="반도체-기반은-강점이지만-자동-승리는-아니다">반도체 기반은 강점이지만 자동 승리는 아니다</h2> <p>한국은 반도체 덕분에 좋은 출발점에 서 있습니다. 메모리와 HBM, 패키징, 제조 장비, 대형 산업 고객과의 관계는 모델 연구에서 하드웨어를 고려한 서비스까지의 거리를 줄일 수 있습니다. “모델을 만들 수 있는가”에서 끝나지 않고 “공장과 엣지, 기업 데이터 옆에서 어떤 모델을 돌릴 것인가”를 묻기 좋은 조건입니다.</p> <p>A.X K2 발표는 제조·국방·바이오를 활용 분야로 제시합니다. 이는 회사가 밝힌 방향이지, 해당 업종이 이미 모델을 도입했다는 증거는 아닙니다. 그래도 방향은 합리적입니다. 한국의 승부처는 모든 범용 챗봇 비교에서 이기는 데 있지 않을 수 있습니다. 한국어 문서를 잘 이해하고, 기존 산업 업무와 연결되며, 국내 데이터와 비용 제약 안에서 작동하는 모델을 만드는 데 있을 수 있습니다.</p> <p><img src="/images/korean-llm-semiconductor-ai-context-02.svg" alt="하드웨어에서 모델과 평가를 거쳐 제품으로 이어지고 사용 피드백이 다음 모델로 돌아가는 구조를 그린 다이어그램"></p> <p><em>하드웨어가 AI 경쟁력이 되려면 사용 피드백이 다음 모델과 제품 결정으로 돌아와야 합니다.</em></p> <p>실패 위험은 발표회에서 멈추는 것입니다. 높은 벤치마크 점수가 안정적인 API, 좋은 문서, 양자화 체크포인트, 감당할 만한 추론 가격, 재현 가능한 평가, 모델 위에 만들고 싶은 개발자를 자동으로 만들어주지는 않습니다. 이 층위가 따라오지 않으면 한국은 쓸 만한 모델을 보유하고도 제품 시장에서는 제3자의 관망자로 남을 수 있습니다.</p> <h2 id="제-생각은-조건부-낙관이다">제 생각은 조건부 낙관이다</h2> <p>저는 한국이 더 이상 제3자의 관망자로 남을 이유는 줄었다고 봅니다. 컴퓨팅과 메모리 공급망, 실제 운영 데이터를 가진 대기업, 대학과 모델 팀, 국가 규모 실험을 지원할 공공 프로그램이 함께 있습니다. 최근 공개된 모델들은 적어도 모델 층위가 비어 있지 않다는 사실을 보여줍니다.</p> <p>하지만 실패 시나리오도 선명합니다. 앞으로 1년을 파라미터 수와 몇 개의 최고 벤치마크, 출시 행사만으로 평가하면 강점은 빠르게 희미해질 수 있습니다. 더 결정적인 증거는 덜 화려한 곳에 있습니다. 몇 팀이 실제 제품을 출시하는지, 파일럿 뒤에도 고객이 계속 쓰는지, 개발자가 폐쇄형 API에서 얼마나 쉽게 옮겨오는지, 사용 데이터가 신뢰를 깨지 않고 다음 버전을 개선하는지 봐야 합니다.</p> <p>그래서 저는 한국을 아직 AI 승자라고 부르지 않겠습니다. 그렇다고 실패자라고 부를 단계도 아닙니다. 반도체 강점이 제품을 만드는 습관을 배워야 하는 지점에 도착했다고 생각합니다. 벤치마크 차트는 신호입니다. 진짜 결과는 차트 다음의 피드백 루프에서 나옵니다. 어떤 모델이 쓰이고, 비용이 지불되고, 실수가 측정되고, 더 나은 시스템이 다시 출시되는가가 한국 AI의 성적표가 될 것입니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/cursor-spacex-developer-choice/https://jakob-ai-notes.pages.dev/ko/posts/cursor-spacex-developer-choice/Cursor가 SpaceX의 컴퓨팅 자원을 얻게 됐습니다. 더 강한 작업 환경과 모델·비용·데이터·운영 선택권을 함께 지킬 수 있는지가 다음 관전 포인트입니다.Fri, 21 Aug 2026 00:00:00 GMT<p>Cursor가 SpaceX의 일부가 되면서 질문의 기준이 달라졌습니다. Cursor는 이제 SpaceX의 컴퓨팅 자원과 SpaceXAI 모델에 더 가까이 접근할 수 있다고 설명합니다. 실무에서 중요한 질문은 따로 있습니다. 개발 환경은 더 강해지면서도 개발자의 선택권은 하나의 모델 생태계에 종속되지 않을 수 있을까요?</p> <p>2026년 8월 14일 Cursor는 SpaceX가 회사를 공식 인수했다고 발표했습니다. 4월 SpaceXAI와 시작한 모델 학습 협력의 다음 단계이기도 합니다. Bloomberg Law는 같은 날 규제 서류를 근거로 600억 달러 규모의 거래가 효력을 갖게 됐다고 보도했습니다.</p> <p>확인된 사실은 인수입니다. 그 이후의 효과는 모든 Cursor 작업이 당장 좋아진다는 약속이 아니라 앞으로 관찰할 결과입니다.</p> <h2 id="가장-먼저-보이는-이점은-컴퓨팅입니다">가장 먼저 보이는 이점은 컴퓨팅입니다</h2> <p>Cursor는 이번 인수로 SpaceX의 GPU 자원에 접근해 더 강력하면서도 실행 비용이 낮은 모델을 만들 수 있다고 설명합니다. 이틀 전 공개된 Grok 4.6은 결합 이후 만들 수 있는 결과의 초기 사례로 소개됐습니다. 다만 이는 회사가 제시한 방향과 주장이지, 모든 저장소에서 독립적으로 검증된 개선은 아닙니다.</p> <p>전략적 가치는 단일 벤치마크 점수보다 분명합니다. Cursor는 모델이 코드베이스·터미널·테스트·배포와 만나는 지점에 있습니다. 컴퓨팅 자원이 늘면 모델 자체가 좋아질 수 있지만, 어떤 모델을 고르고 얼마만큼의 맥락을 주며 언제 에이전트 실행을 허용할지도 작업 환경이 결정합니다.</p> <h2 id="선택권은-모델-메뉴보다-넓습니다">선택권은 모델 메뉴보다 넓습니다</h2> <p>현재 Cursor 문서는 OpenAI·Anthropic·Google·SpaceXAI 등 여러 회사의 모델을 지원한다고 설명합니다. 동시에 Grok 4.6·Grok 4.5·Composer 2.5가 포함된 Cursor Models와 외부 모델을 위한 Other Models라는 두 사용량 풀을 나눕니다. 선택지는 남아 있지만 경제적 조건이 어떤 선택을 실제로 편하게 만드는지까지 봐야 합니다.</p> <p><img src="/images/cursor-spacex-developer-choice-context-01.png" alt="여러 모델 경로 중 하나를 고르는 개발자와 작업 범위를 제한하는 별도 제어 장치"></p> <p><em>모델 선택은 비용과 데이터 경계, 운영 위험을 함께 결정하는 통제 지점입니다.</em></p> <table> <thead> <tr> <th>층위</th> <th>기대할 수 있는 이점</th> <th>확인할 의존성</th> </tr> </thead> <tbody> <tr> <td>컴퓨팅</td> <td>모델 학습·서비스 운영에 더 많은 자원을 쓸 수 있습니다.</td> <td>자사 경로가 기본값으로 더 매력적으로 설계될 수 있습니다.</td> </tr> <tr> <td>모델 메뉴</td> <td>여러 제공자의 모델을 고를 수 있습니다.</td> <td>보이는 선택지가 경제적으로 같은 선택이라는 뜻은 아닙니다.</td> </tr> <tr> <td>가격</td> <td>기본 사용량이 일반 작업 비용을 낮출 수 있습니다.</td> <td>풀을 나누면 실제 제공자 전환 비용이 커질 수 있습니다.</td> </tr> <tr> <td>작업 환경</td> <td>맥락·도구·테스트·배포가 한곳에 연결됩니다.</td> <td>한 모델에 맞춘 규칙이 다른 모델로 그대로 이동하지 않을 수 있습니다.</td> </tr> <tr> <td>데이터 경계</td> <td>편집기는 소스코드와 에이전트 기록 가까이에 있습니다.</td> <td>무엇이 어떤 목적으로 작업 영역 밖으로 나가는지 계속 확인해야 합니다.</td> </tr> </tbody> </table> <p>이 구조만으로 Cursor가 이미 사용자를 Grok에 가뒀다고 말할 수는 없습니다. 다만 기술적 차단 없이도 의존성이 커지는 경로는 보입니다. 가장 편한 사용량 한도와 빠른 기능, 좋은 에이전트 연동이 계속 SpaceXAI 모델에 유리하게 설계된다면, 개발자는 모델을 바꿀 수 있어도 경제적으로 같은 선택을 하기 어려워질 수 있습니다.</p> <h2 id="개발자가-확인할-이동성-테스트">개발자가 확인할 이동성 테스트</h2> <p>첫째는 모델 이동성입니다. Grok·Claude·Gemini·OpenAI 모델 사이를 오갈 때 같은 작업 규칙과 평가 절차를 그대로 사용할 수 있어야 합니다. 둘째는 데이터의 경계입니다. 코드·프롬프트·도구 실행 기록·에이전트 결과 중 무엇이 사용자 영역에 남고 무엇이 모델 개선에 쓰이는지 확인해야 합니다. 셋째는 운영 통제입니다. 변경 내용을 살펴보고, 긴 작업을 중단하고, 모델이 실패했을 때 복구할 수 있어야 합니다.</p> <p>이 질문들이 인수가 좋은지 나쁜지를 추상적으로 판단하는 것보다 유용합니다. 강한 작업 환경은 능력을 높이면서도 주변의 권한과 전환 비용을 숨기지 않을 때 가치가 있습니다.</p> <p>SpaceX는 Cursor에 강력한 컴퓨팅 자원과 Grok 계열과의 직접 연결을 제공할 수 있습니다. 제품이 더 빠르고 야심 차게 변할 가능성은 충분합니다. 동시에 편집기와 모델 제공자, 플랫폼 소유자의 경계는 흐려질 수 있습니다. Cursor가 장기적으로 신뢰받으려면 모델 메뉴에 선택지가 보이는 것만으로는 부족합니다. 그 선택이 비용·데이터·운영 현장에서도 실제 선택으로 남아 있어야 합니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/openai-private-safety-processing/https://jakob-ai-notes.pages.dev/ko/posts/openai-private-safety-processing/Private Safety Processing은 적격 Zero Data Retention 환경에서 여러 상호작용의 오용 패턴을 찾으려는 OpenAI의 초기 프리뷰입니다.Thu, 20 Aug 2026 00:00:00 GMT<p>기업용 AI를 도입할수록 두 요구가 부딪힙니다. 안전 문제를 찾으려면 여러 상호작용을 이어서 봐야 하지만, 기업은 프롬프트와 결과를 외부 사업자에게 오래 남기고 싶어 하지 않습니다. OpenAI의 Private Safety Processing 프리뷰는 이 두 일을 분리하려는 시도입니다.</p> <p>8월 19일 OpenAI는 적격 API 고객의 Zero Data Retention(ZDR) 환경에서 이 기능을 시험한다고 발표했습니다. ZDR은 요청을 처리한 뒤 프롬프트와 모델 응답을 보관하지 않는 정책입니다. 다만 모든 데이터가 어떤 경우에도 남지 않는다는 뜻은 아닙니다. 고객 자격·엔드포인트 적용 범위·법적 예외를 함께 확인해야 합니다.</p> <p>따라서 독자가 물어야 할 질문은 “OpenAI가 이제 아무것도 보지 않는가?”가 아닙니다. “원문은 어디에 남고, 어떤 파생 안전 신호가 돌아오며, 고객이 확인할 수 있는 증거는 무엇인가?”가 더 정확합니다.</p> <h2 id="원문을-노출하지-않고-상호작용을-이어볼-수-있습니다">원문을 노출하지 않고 상호작용을 이어볼 수 있습니다</h2> <p>OpenAI는 자동화된 시스템이 서로 관련된 상호작용에서 오용 패턴을 찾고 고객에게는 제한된 안전 신호만 돌려준다고 설명합니다. 원래의 프롬프트와 응답을 OpenAI 직원이 검토하지 않는다는 점도 밝혔습니다. ZDR 환경에서 고객 콘텐츠는 고객이 통제하는 인프라에 남는다고 설명하며, OpenAI 인프라에 보관하되 고객 관리 키로 암호화하는 선택지도 개발 중이라고 했습니다.</p> <p><img src="/images/openai-private-safety-processing-context-01.png" alt="잠긴 원문 보관함에서 제한된 안전 신호만 분리해 모니터로 전달하는 장면"></p> <p><em>이번 프리뷰의 핵심은 원문과 안전 판단에 필요한 신호를 분리하는 것입니다.</em></p> <p>이 설명은 방향을 보여주지만 완성된 운영 사양은 아닙니다.</p> <table> <thead> <tr> <th>질문</th> <th>발표에서 확인되는 내용</th> <th>아직 확인할 내용</th> </tr> </thead> <tbody> <tr> <td>원문 콘텐츠</td> <td>적격 ZDR 요청은 처리 뒤 프롬프트와 응답을 보관하지 않도록 설계됩니다.</td> <td>실제 계약에서 어떤 모델·엔드포인트가 대상인가?</td> </tr> <tr> <td>안전 탐지</td> <td>관련 상호작용을 묶어 오용 패턴을 분석할 수 있습니다.</td> <td>신호의 정확도와 오탐 처리 경로는 무엇인가?</td> </tr> <tr> <td>고객에게 돌아오는 것</td> <td>원래 대화가 아니라 제한된 안전 신호입니다.</td> <td>신호의 필드·보존 기간·접근 통제는 어떻게 되는가?</td> </tr> <tr> <td>고객 관리 키</td> <td>고객 키로 암호화하는 인프라 옵션을 개발 중입니다.</td> <td>키 생성·교체·철회·감사 방법은 무엇인가?</td> </tr> <tr> <td>사람의 검토</td> <td>설명된 흐름에서는 직원이 원래 프롬프트와 응답을 검토하지 않는다고 합니다.</td> <td>법적·안전상 어떤 예외가 원문 보존과 검토를 허용하는가?</td> </tr> </tbody> </table> <h2 id="에이전트에서는-더-어려운-문제가-됩니다">에이전트에서는 더 어려운 문제가 됩니다</h2> <p>짧은 질의응답이라면 한 번의 요청만 확인해도 위험 신호를 찾을 수 있습니다. 하지만 에이전트는 여러 단계로 계획하고, 도구를 호출하고, 실패한 뒤 다시 시도합니다. 개별 메시지만 보면 정상처럼 보이는 행동이 여러 상호작용을 합쳤을 때 다른 의미를 가질 수 있습니다.</p> <p>기업 입장에서는 코드·내부 문서·연구 자료처럼 외부 보관을 꺼리는 정보가 에이전트의 맥락에 들어갑니다. 안전을 위해 광범위한 로그를 요구하면 도입 장벽이 올라가고, 상호작용 간 연결이 없으면 반복적인 오용을 놓칠 수 있습니다. Axios는 이번 발표를 Anthropic이 일부 사용 사례에서 데이터 로그를 요구하는 흐름과 대비되는 시도로 설명했습니다. 이는 두 회사 정책 전체의 비교가 아니라 안전성과 보존 기간 설계가 다르다는 맥락입니다.</p> <h2 id="완전한-비공개로-읽으면-안-됩니다">완전한 비공개로 읽으면 안 됩니다</h2> <p>이번 발표는 검증을 끝낸 제품 보장이 아니라 초기 고객 테스트입니다. 기업은 ZDR이 실제로 적용되는 모델과 엔드포인트, 안전 신호가 포함하는 정보, 원문이 남는 위치, 고객 관리 키의 운영 방식을 확인해야 합니다.</p> <p>OpenAI는 법에 따른 수동 검토와 신고를 위해 아동 성착취물로 의심되는 이미지가 ZDR 환경에서도 보존될 수 있다는 예외도 명시했습니다. 제한된 안전 신호는 완전한 감사 로그와도 다릅니다. 자동 차단 여부, 이의 제기 처리, 독립 감사에 필요한 증거를 어떻게 남길지는 별도의 설계 문제입니다.</p> <p>Private Safety Processing이 던지는 질문은 유용합니다. 원문을 보관하지 않고도 장기적인 오용 패턴을 충분히 감지할 수 있는가. 방향은 의미 있지만, 답은 발표 문구가 아니라 신호의 정확도·예외 처리·고객 통제권·외부 검증으로 확인해야 합니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/higgsfield-ai-creative-studio/https://jakob-ai-notes.pages.dev/ko/posts/higgsfield-ai-creative-studio/카메라 제어형 AI 영상 생성에서 Supercomputer와 Apps까지 확장한 Higgsfield의 문제의식, 최근 뉴스, 비용, 시장성과 한계를 살펴봅니다.Wed, 19 Aug 2026 00:00:00 GMT<p>Higgsfield는 텍스트·이미지를 영상으로 바꾸는 서비스에서 출발해 카메라 제어, 모델 선택, 앱 제작을 묶는 제작 플랫폼으로 확장 중입니다. 회사는 크리에이터·마케팅 에이전시·영화 제작자를 위한 “all-in-one AI creative studio”라고 부릅니다. <a href="https://higgsfield.ai/">Higgsfield 홈페이지</a>에서 자체 도구와 영상 모델을 확인할 수 있습니다.</p> <h2 id="누구의-어떤-문제를-해결하나">누구의 어떤 문제를 해결하나</h2> <p>광고나 뮤직비디오 콘셉트를 만들 때 팀은 이미지·영상 생성기와 편집기를 오가며 프롬프트와 캐릭터 설정을 반복해서 옮깁니다. 카메라 움직임이 어긋나고 인물이 장면마다 달라지는 문제도 있습니다. Higgsfield는 텍스트·이미지·링크에서 렌즈, 카메라, 색감, 캐릭터 일관성까지 잇습니다. 소셜 마케터, 제품 광고를 시험하는 브랜드 팀, 프리비주얼이 필요한 영화 제작자가 핵심 사용자입니다.</p> <p>Accel은 Alex Mashrabov, Yerzat Dulat, Mahi de Silva를 창업자로, TechCrunch는 Alex를 전 Snap 생성형 AI 책임자로 소개합니다. Higgsfield가 강조하는 방향은 한 장의 이미지보다 소프트웨어처럼 영상을 반복 제작하는 것입니다. Supercomputer는 작업을 나누고 모델·프리셋을 고른 뒤 실행 전 크레딧 비용을 보여줍니다. 자체 도구와 파트너 모델을 조합해 모델 비교도 줄이려 합니다.</p> <p><img src="/images/higgsfield-ai-creative-studio-context-01.webp" alt="Higgsfield Global Film Festival의 공식 어워드 이미지"></p> <p><em>이미지: Higgsfield Global Film Festival 공식 이미지. 출처: <a href="https://higgsfield.company/contests/higgsfield-global-film-festival">공식 페스티벌 페이지</a></em></p> <h2 id="최근-뉴스와-반응">최근 뉴스와 반응</h2> <p>7월 9일 발표한 Apps는 이 전략을 확장했습니다. 자연어로 생성 앱을 만들고 Higgsfield 모델·데이터베이스·화면을 연결합니다. 회사는 15개 이상의 모델과 500개 이상의 앱을 말합니다. 8월에는 총상금 100만 달러의 Global Film Festival을 열고 전 픽사 사장 겸 <em>Toy Story</em> 총괄 제작자 Edwin Catmull을 심사위원으로 초대했습니다. 제작 도구와 창작자 시장을 함께 만들려는 시도입니다.</p> <p>재무 뉴스는 구분해서 봐야 합니다. Axios Pro Rata는 8월 17일 4억 달러 조달과 기업가치 54억 달러를 보도했지만, 회사 공식 발표로 확인된 수치는 아닙니다. 회사가 공식 발표한 7월 말 약관에는 입력·출력 소유권과 함께 서비스 운영 라이선스, 콘텐츠 학습 허용 조항이 남아 있습니다. “상업적 사용 가능”과 “학습 제외”는 다르므로 기업 고객은 조건을 확인해야 합니다.</p> <p>가격은 크레딧 경제가 핵심입니다. 공식 가이드는 약 90크레딧·4.50달러, 전체 작업은 약 200크레딧·10달러라는 예시를 제시합니다. 플랜·프로모션은 변동됩니다. Reddit 일부 사용자는 모델별 단가가 즉시 보이지 않는다고 했고, 다른 리뷰어는 영화적 움직임은 좋지만 납품에는 수정·재생성이 필요하다고 평가했습니다. 비용 투명성과 일관성이 구매 장벽이라는 신호입니다.</p> <h2 id="가능성과-한계">가능성과 한계</h2> <p>가능성은 모델 하나보다 워크플로를 소유하는 데 있습니다. Apps·마켓·영화제·기업 조건이 이어지면 영상 생성기가 광고 제작 인프라로 커질 수 있습니다. 그러나 외부 모델 의존, 크레딧 소진과 “무제한”의 해석, 인물·브랜드 권리, 학습 정책, 품질 편차가 리스크입니다. Runway·Kling·Seedance도 경쟁합니다.</p> <p>증명할 것은 한 번의 놀라운 영상이 아니라 반복 제작·검수·납품 시간을 줄이고 비용과 권리를 예측 가능하게 만드는 일입니다. 지금은 영상 생성기보다 “AI 영상 제작 스튜디오”에 베팅하는 서비스입니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/agent-memory-context-tradeoff/https://jakob-ai-notes.pages.dev/ko/posts/agent-memory-context-tradeoff/연구와 Luthn의 제한된 recall 설계를 바탕으로 에이전트 기억이 신뢰성·탐색 다양성·컨텍스트 비용 사이에서 만드는 trade-off를 설명합니다.Wed, 19 Aug 2026 00:00:00 GMT<p>에이전트에 기억을 붙이면 당연히 더 좋아질 것처럼 보입니다. 코딩 에이전트가 같은 버그를 전에 본 적이 있다면 다시 실수할 이유가 없고, 저장소에 정해진 작업 방식이 있다면 매 세션마다 설명할 필요도 없어 보입니다.</p> <p>최근 연구는 조금 다른 답을 줍니다. 기억은 에이전트를 개선할 수 있지만, 에이전트가 어떤 방식으로 탐색하는지와 기억을 어디까지 적용하는지에 따라 결과가 달라집니다. 중요한 질문은 에이전트가 얼마나 많이 기억하느냐가 아닙니다. 다음 판단에 어떤 기억이 영향을 줘야 하고, 어떤 기억은 빠져 있어야 하는지입니다.</p> <h2 id="기억은-도움도-되지만-탐색을-좁힐-수-있습니다">기억은 도움도 되지만 탐색을 좁힐 수 있습니다</h2> <p>ACL 2026 Findings 논문은 머신러닝 엔지니어링 에이전트에 동적 코딩 기억을 붙이고 두 가지 작업 방식을 비교합니다. 하나는 디버깅과 개선을 반복하는 순차형 에이전트이고, 다른 하나는 여러 해결책을 병렬로 시도하는 tree-search 에이전트입니다.</p> <p>결과는 기억의 단순한 승리가 아니었습니다. 순차형 작업에서는 기억이 반복되는 실수를 줄이고, 앞선 시도와 다음 수정을 연결하는 데 도움이 됐습니다. 반면 탐색형 작업에서는 같은 안정성이 제약으로 바뀔 수 있습니다. 과거 절차가 탐색의 다양성을 줄이고, 에이전트를 익숙한 답 쪽으로 너무 빨리 밀 수 있기 때문입니다.</p> <p><img src="/images/agent-memory-context-tradeoff-context-01.png" alt="순차적인 작업 흐름과 더 넓은 탐색을 대비한 책상 위 실험 장면"></p> <p><em>반복 수리에 유용한 기억이 열린 탐색에도 자동으로 유용한 것은 아닙니다.</em></p> <p>이 차이는 실무에서 선명합니다. 특정 테스트 실패를 고친 방법은 같은 컴포넌트가 다시 깨졌을 때 큰 도움이 됩니다. 하지만 새로운 아키텍처를 조사할 때 과거의 수정법을 기본 정답처럼 취급하면 다른 해법을 찾기 어려워집니다. 반복 오류를 줄이는 일과 새 해법을 발견하는 일은 같은 목표가 아닙니다. 반복 실수만 줄이도록 만든 memory layer가 어느 순간 탐색 자체를 조용히 막을 수 있습니다.</p> <h2 id="컨텍스트-파일에도-비용이-붙습니다">컨텍스트 파일에도 비용이 붙습니다</h2> <p>저장소 수준의 지침에서도 비슷한 긴장이 나타납니다. ETH 취리히와 SRI 연구진은 ICLR 2026 워크숍에서 여러 코딩 에이전트와 언어 모델을 대상으로 AGENTS.md 형식의 컨텍스트 파일을 평가했습니다. 연구가 실험한 조건에서는 컨텍스트 파일이 작업 성공률을 높이지 못한 반면, 추론 비용은 20% 이상 늘었습니다.</p> <p>연구는 에이전트가 지침을 대체로 잘 따른다는 점도 관찰했습니다. 그래서 불필요한 지침이 더 문제가 됩니다. 현재 작업과 관계없는 요구사항까지 지키느라 파일을 더 읽고, 테스트를 더 실행하고, 추가 조건을 맞추는 데 token과 시간이 들 수 있습니다. 지킨다는 사실이 유용하다는 뜻은 아닙니다.</p> <p>이 결과가 AGENTS.md가 쓸모없다거나 모든 컨텍스트 파일을 없애야 한다는 뜻은 아닙니다. 더 좁은 교훈은 실용적입니다. 사람이 작성하는 컨텍스트에는 안정적인 요구사항을 남기고, 현재 판단을 바꾸지 않는 과거 선호·추정·반복 주의사항은 덜어내야 합니다.</p> <h2 id="제한된-기본값은-trade-off에-대한-한-가지-답입니다">제한된 기본값은 trade-off에 대한 한 가지 답입니다</h2> <p>이 긴장을 실제 설계에 반영한 사례가 Luthn입니다. Luthn의 기본 auto-recall은 매 턴마다 private store 전체를 검색하지 않습니다. 새 작업이나 material topic이 시작될 때 최대 3개 항목, 약 600토큰의 budget, 200밀리초 fail-open 제한으로 작은 context pack을 요청하고 10분 동안 재사용합니다.</p> <p>이 숫자가 모든 memory system에 적용할 정답은 아닙니다. 프로젝트의 전체 history를 매번 들고 오지 않으면서도 작업 시작점에는 도움이 되도록 의도적으로 작은 기본값을 둔 것입니다. project·task·topic key도 제한된 범위에서만 recall을 좁히며, 항목이 agent-visible이 되기 전 classification과 safe-projection 규칙을 거칩니다.</p> <p><img src="/images/agent-memory-context-tradeoff-context-03.png" alt="검증된 기억·임시 기억·승인이 필요한 기억을 기호로 분류하는 밝은 작업대"></p> <p><em>유효성·만료·접근 권한이 눈에 보이는 결정이 되면 기억을 운영하기 쉬워집니다.</em></p> <p>제한된 context pack은 실패 방식도 바꿉니다. 조회 결과가 없거나 service가 unavailable이면 확인되지 않은 기억으로 빈칸을 채우지 않습니다. 검증되지 않은 맥락 없이 계속 진행하거나, 필요한 맥락을 확인하지 못했다고 말합니다. 무제한 recall보다 덜 편리하지만 오래된 기록을 보이지 않는 전제로 바꾸는 것보다는 안전합니다.</p> <h2 id="기억에는-종류와-경계가-필요합니다">기억에는 종류와 경계가 필요합니다</h2> <p>실용적인 memory system이라면 최소한 네 종류의 정보를 나눠야 합니다. 절차 기억은 과거에 효과가 있었던 방법입니다. 프로젝트 상태는 특정 시점의 저장소나 작업에 대한 사실입니다. 선호는 사용자나 팀이 일하는 방식입니다. 근거와 가설은 확인된 내용, 불확실한 내용, 아직 검증하지 않은 판단을 구분합니다.</p> <p>이 범주들을 같은 검색 규칙으로 다루면 안 됩니다. 검증된 build command는 자동으로 재사용해도 괜찮을 수 있습니다. 임시 프로젝트 결정에는 만료 시점이 필요합니다. 사용자 선호는 특정 owner나 workspace에만 적용될 수 있습니다. 추론은 자주 검색됐다는 이유만으로 사실로 승격하면 안 됩니다.</p> <p>metadata는 기억을 꾸미는 부속 정보가 아니라 기억의 일부입니다. 기록의 출처와 마지막 확인 시점, 적용되는 project·task 범위, 민감도, 만료·충돌 시 처리 방식이 남아야 합니다. 검색된 기억이 실제 답변이나 tool action에 영향을 주었는지도 확인할 수 있어야 합니다.</p> <h2 id="이-글에서-확인한-것과-아직-하지-않은-것">이 글에서 확인한 것과 아직 하지 않은 것</h2> <p>위 연구에 관한 주장은 인용한 연구에서 가져왔고, Luthn의 제한값은 공개 문서에서 확인했습니다. 아직 특정 memory configuration이 항상 최선이라고 증명하는 통제된 local A/B 실험을 했다는 뜻은 아닙니다. 그 실험을 하려면 task·model·budget을 고정한 뒤 memory layer만 바꿔야 합니다.</p> <table> <thead> <tr> <th>비교</th> <th>기록할 결과</th> </tr> </thead> <tbody> <tr> <td>memory 없음과 제한된 memory</td> <td>성공 여부·반복 오류·수정 횟수</td> </tr> <tr> <td>작은 pack과 큰 pack</td> <td>token 사용량·지연 시간·무관한 context</td> </tr> <tr> <td>memory 사용과 withheld</td> <td>탐색 다양성·첫 viable solution까지 걸린 시간</td> </tr> <tr> <td>최신 기록과 오래된 기록</td> <td>오래된 조언을 알아차리고 복구하는지</td> </tr> <tr> <td>충돌하는 기록</td> <td>충돌을 보여주는지 조용히 덮는지</td> </tr> </tbody> </table> <p>핵심은 memory가 더 많이 검색했는지를 칭찬하는 것이 아니라 무엇을 바꿨는지 측정하는 데 있습니다. 장기기억은 단순한 저장 기능이 아니라 에이전트의 제한된 context와 주의를 배분하는 정책입니다. 좋은 기억은 어렵게 얻은 지식을 다음 작업으로 가져오고, 좋은 경계는 그 지식이 모든 새 문제의 보이지 않는 전제가 되는 것을 막습니다.</p> <p>에이전트 메모리의 다음 단계는 모든 것을 기억하는 일이 아닙니다. 언제 기억하지 않을지, 언제 검색하지 않을지, 언제 확인을 요청할지를 아는 일입니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/stripe-openrouter-model-routing/https://jakob-ai-notes.pages.dev/ko/posts/stripe-openrouter-model-routing/Stripe의 OpenRouter 인수 보도는 모델 선택·사용량 추적·AI 청구가 하나의 인프라 계층으로 묶이는 흐름을 보여줍니다.Tue, 18 Aug 2026 00:00:00 GMT<p>2026년 8월 17일 <a href="https://www.axios.com/2026/08/17/stripe-openrouter-paypal">Axios는 Stripe가 OpenRouter를 현금과 주식 80억 달러 이상에 인수하기로 합의했다고 보도했습니다</a>. Axios의 별도 뉴스레터는 Bloomberg를 인용해 70억 달러 이상이라고 전했습니다. 아직 양사의 공식 발표 전이며, Axios도 보도 당시 공식 발표가 그 주에 나올 예정이고 양사가 논평하지 않았다고 적었습니다.</p> <p>이 구분이 중요합니다. 인수가 확정되면 AI 애플리케이션과 모델 제공자 사이의 계층이 전략적 자산이 됐다는 가장 큰 신호 중 하나가 됩니다. OpenRouter는 프런티어 모델을 만드는 회사가 아니라, 하나의 인터페이스로 수백 개 모델에 접근하고 비용·지연시간·가용성·작업 특성에 따라 요청을 다른 모델로 보낼 수 있게 하는 게이트웨이입니다.</p> <h2 id="모델과-돈-사이에-생긴-계층">모델과 돈 사이에 생긴 계층</h2> <p>OpenRouter는 5월 <a href="https://openrouter.ai/blog/announcements/series-b/">Series B 발표</a>에서 800만 명 이상의 개발자가 400개 이상의 모델을 사용하고 있다고 설명했습니다. 최근 6개월 동안 주간 처리량이 5조 토큰에서 25조 토큰으로 늘었고, 라우팅·신뢰성·비용 최적화·컴플라이언스를 담당한다고 밝혔습니다. 수치는 회사 발표이지만 방향은 분명합니다. 여러 모델을 실제 제품에 쓰려면 모델 API만으로는 부족하고, 운영 계층이 필요합니다.</p> <p>Stripe는 이미 그 계층 주변에 들어와 있습니다. 1월 <a href="https://stripe.com/en-ca/newsroom/news/openrouter-and-stripe">공식 발표</a>에 따르면 OpenRouter는 Stripe의 인보이싱·세금·결제·사기 방지 도구를 사용합니다. Stripe는 OpenRouter를 통해 모델 요청을 라우팅하고, 사용량을 추적하고, 가격을 적용해 청구하는 연동도 소개했습니다. 이번 인수 보도는 새 관계의 시작이라기보다 기존 결제 협력을 소유 관계로 넓히는 움직임으로 읽힙니다.</p> <p><img src="/images/stripe-openrouter-model-routing-context-01.png" alt="중앙 스위치가 하나의 AI 요청을 여러 모델 카트리지로 분기하는 모습을 단순화한 일러스트"></p> <p><em>모델 선택과 비용 처리가 하나의 운영 흐름으로 연결되는 라우팅 계층을 표현했습니다.</em></p> <h2 id="stripe가-라우터를-원할-이유">Stripe가 라우터를 원할 이유</h2> <p>이 거래를 단순히 ‘결제 회사가 AI 스타트업을 산다’고 보면 핵심을 놓칩니다. AI 비용은 자주 움직입니다. 모델 제공자는 가격을 바꾸고, 지역마다 가용성이 다르며, 빠르고 저렴한 모델이 맞는 요청과 더 강력한 모델이 필요한 요청이 섞여 들어옵니다. 사용자가 많아지면 모델을 바꾸는 일은 API 한 줄을 고치는 문제가 아닙니다. 예산·마진·지연시간·신뢰성·데이터 정책이 함께 바뀝니다.</p> <p>OpenRouter는 바로 그 선택 지점에 있습니다. 한 제공자가 불안정할 때 다른 제공자로 넘기고, 모델별 API 차이 때문에 제품 전체를 다시 쓰지 않도록 도울 수 있습니다. Stripe는 이미 AI 사용량이 어떻게 청구되는지 보고 있습니다. 라우팅까지 갖게 되면 어떤 모델이 선택되고, 사용량이 어떻게 측정되며, 비용이 어떻게 지불되는지에 더 직접 관여할 수 있습니다.</p> <p>다만 이 부분은 발표된 인수 후 계획이 아니라 제품 구조에서 도출한 해석입니다. 인수 금액도 양사가 조건을 공개하기 전까지는 보도된 숫자로만 다뤄야 합니다.</p> <h2 id="진짜-질문은-누가-통제하느냐">진짜 질문은 누가 통제하느냐</h2> <p>인수가 성사되더라도 모델 게이트웨이가 자동으로 더 개방적인 서비스가 되는 것은 아닙니다. 개발자는 여러 제공자 선택권이 유지되는지, 라우팅 기준을 확인할 수 있는지, 기본 경로에 결제나 공급자 이해관계가 영향을 주는지 알고 싶어 할 것입니다. 기업은 감사 로그, 데이터 보관 경계, 다른 게이트웨이로 옮길 수 있는 출구도 요구할 가능성이 큽니다.</p> <p>개발자가 볼 지표는 인수 가격보다 구체적이어야 합니다. 다른 제공자로 요청을 옮길 때 제품을 다시 만들 필요가 없는가. 비용과 지연시간을 결정하는 기준을 확인할 수 있는가. 게이트웨이의 방향이 바뀌었을 때 사용량과 정책을 가져올 수 있는가.</p> <p>아직은 보도 단계지만 메시지는 선명합니다. AI 인프라는 GPU와 모델 API만으로 완성되지 않습니다. 어떤 조건에서 어떤 모델을 실행할지 결정하고, 그 결과를 측정하고, 비용까지 연결하는 계층도 이제 인프라가 되고 있습니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/grok-cursor-workbench/https://jakob-ai-notes.pages.dev/ko/posts/grok-cursor-workbench/SpaceX의 Cursor 인수와 Grok 4.6 공식 발표를 바탕으로 Cursor가 코드 편집기를 넘어 AI 에이전트 작업장으로 변화할 가능성과 한계를 살펴봅니다.Mon, 17 Aug 2026 00:00:00 GMT<p>SpaceX가 Cursor를 인수하면서 AI 경쟁의 축이 달라졌습니다. 2026년 6월 16일 SEC 자료는 SpaceX가 Cursor 운영사 Anysphere를 600억 달러 규모로 인수하기로 했다고 밝힙니다. 8월 14일 인수가 마무리됐다는 보도도 나왔습니다. <a href="https://www.sec.gov/Archives/edgar/data/1181412/000162828026043411/spaceexplorationtechnologi.htm">SEC 인수계약</a></p> <p>이 거래가 중요한 이유는 Cursor가 코드 편집기보다 파일·도구·테스트·배포를 연결하는 에이전트 작업장에 가깝기 때문입니다. xAI와 Grok을 가진 SpaceX가 개발자의 작업 공간까지 확보해 모델·컴퓨팅·에이전트·사용자 접점을 묶었습니다.</p> <h2 id="grok-46은-챗봇-업데이트가-아니었다">Grok 4.6은 챗봇 업데이트가 아니었다</h2> <p>Cursor는 8월 12일 SpaceXAI와 Grok 4.6을 공식 발표했습니다. 초점은 짧은 답변보다 코드베이스 분석, 자료 조사, 정보 정리, 애플리케이션 제작처럼 여러 단계를 이어가는 에이전트 작업입니다. Cursor와 Grok Build, SpaceXAI API에서 사용할 수 있습니다. <a href="https://cursor.com/blog/grok-4-6">Grok 4.6 공식 발표</a></p> <p>Cursor는 Grok 4.6이 Artificial Analysis Intelligence Index에서 GPT-5.6 Sol과 같은 점수를 기록했다고 밝혔습니다. 여러 벤치마크를 합친 Cursor 측 종합 점수이므로, 모든 작업에서 최고라는 뜻보다 에이전트 경쟁에서 Grok을 주변부 모델로 보기 어려워졌다는 신호로 읽는 편이 정확합니다.</p> <h2 id="cursor의-진짜-자산은-모델보다-하네스다">Cursor의 진짜 자산은 모델보다 하네스다</h2> <p>Cursor는 Grok 4.5를 SpaceXAI와 공동 학습했고, 코드베이스와 개발 도구 사용 과정이 학습에 반영됐다고 설명했습니다. 중요한 자산은 데이터만이 아닙니다. 어떤 파일과 명령을 선택할지, 실패를 어떻게 복구할지 결정하는 하네스가 필요합니다. Cursor는 모델을 감싸는 이 실행 구조와 인터페이스를 갖고 있습니다.</p> <p><img src="/images/grok-cursor-workbench-context-01.png" alt="Cursor와 Grok의 학습·검증 순환을 단순화한 일러스트"></p> <p><em>모델의 성능은 코드와 도구, 테스트 환경이 연결될 때 실제 작업 능력으로 바뀝니다.</em></p> <p>모델이 좋아질수록 이 구조의 작업 성능도 좋아질 수 있습니다. 다만 개발자의 코드와 사용 기록이 어떤 조건으로 저장되고 학습에 사용되는지는 별도 확인 대상입니다.</p> <h2 id="cursor는-어떻게-바뀔까">Cursor는 어떻게 바뀔까</h2> <p>Grok Bot이 대화와 조사를 맡고, Grok Build가 아이디어를 앱으로 옮기며, Cursor가 실제 코드베이스와 배포를 맡는 흐름이 가능해집니다. Grok 4.6이 강조하는 웹 개발·문서·데이터 분석까지 흡수하면 Cursor는 코드 편집기를 넘어 결과물을 만드는 개발 환경으로 넓어질 수 있습니다.</p> <p>다만 SpaceX가 Grok을 중심에 두더라도, 다른 모델을 연결하는 라우터와 사용자의 선택권을 유지해야 합니다. Grok만 강제하면 Cursor의 중립성이 약해질 수 있습니다. 이 부분은 공식 계획이 아니라 제품 구조에서 도출한 전망입니다.</p> <h2 id="광폭화의-반대편에는-통제-문제가-있다">광폭화의 반대편에는 통제 문제가 있다</h2> <p>속도가 빠를수록 검증과 통제가 중요합니다. Cursor는 Grok 4.5의 일부 CursorBench 결과에 학습 데이터가 섞였을 가능성을 경고했습니다. Grok 4.6도 실제 저장소에서 다시 시험해야 합니다. 앞으로는 벤치마크 순위보다 모델 교체 가능성, 데이터 사용 범위, 에이전트 명령과 변경 내용의 감사 가능성, 긴 작업의 중단·복구 기능을 함께 봐야 합니다.</p> <p>Grok 4.6은 Cursor가 더 강력해질 가능성을 보여줍니다. 하지만 결과는 모델 점수보다 제품 철학에 달려 있습니다. 여러 모델과 개발자의 선택을 연결하는 작업장으로 남으면 도약이 될 수 있고, 하나의 생태계로 좁아지면 의존성이 커집니다. 진짜 질문은 그 지능이 Cursor 안에서 누구의 통제 아래 쓰이게 되는가입니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/development-automation-retrospective/https://jakob-ai-notes.pages.dev/ko/posts/development-automation-retrospective/Drig를 모든 개발 단계를 맡는 그래프에서 제한된 기획·증거·QA·배포 경계로 좁히고 Codex와 직접 협업하게 된 프로젝트 회고입니다.Sat, 15 Aug 2026 02:05:10 GMT<p>자동화를 그만둔 것이 아닙니다. 하나의 그래프에 개발 전체를 맡기는 방식을 그만뒀습니다.</p> <p>한동안 저는 하네스와 그래프, 여러 에이전트를 연결해 개발 루프를 만들고 있었습니다. 프로젝트 이름은 Drig였습니다. 처음의 생각은 합리적이었습니다. 개발을 기획·인터뷰·구현·리뷰·배포 단계로 나누고, 각 에이전트에 역할과 책임 범위를 부여한 뒤, 그래프로 반복 가능한 흐름을 만들면 더 안정적으로 개발할 수 있다고 봤습니다.</p> <p>여기에는 실제 걱정이 있었습니다. 코딩 에이전트는 맥락을 잃거나 검사를 건너뛸 수 있고, 나중에 이유를 복원하기 어려운 판단을 내릴 수도 있습니다. 구조화된 하네스는 개발 과정을 보이게 하고 반복 가능하게 만드는 방법처럼 보였습니다. 코딩이 중요하지 않아서 자동화하려던 것은 아닙니다. 오히려 개발 품질을 지키려고 과정을 더 엄격하게 만들고 싶었습니다.</p> <p><img src="/images/development-automation-retrospective-context-01.png" alt="작은 코드 작업을 둘러싼 복잡한 워크플로 튜브와 체크리스트, 타이머, 에이전트 노드"></p> <p><em>단계를 늘릴수록 작업을 시스템 안에서 이동시키는 데 더 많은 노력이 필요해졌습니다.</em></p> <h2 id="처음에-기대했던-자동화의-대가">처음에 기대했던 자동화의 대가</h2> <p>다이어그램 위의 약속은 단순했습니다.</p> <table> <thead> <tr> <th>단계</th> <th>기대한 효과</th> <th>함께 생긴 숨은 비용</th> </tr> </thead> <tbody> <tr> <td>기획과 인터뷰</td> <td>모호한 요구사항 줄이기</td> <td>더 많은 맥락을 모으고 인계해야 함</td> </tr> <tr> <td>구현</td> <td>제한된 코딩 책임</td> <td>경계를 설명하고 복구해야 하는 지점 증가</td> </tr> <tr> <td>리뷰와 QA</td> <td>독립적인 검증</td> <td>artifact·시간·상태 전환 증가</td> </tr> <tr> <td>배포와 closeout</td> <td>반복 가능한 마지막 단계</td> <td>유지해야 할 그래프 자체가 제품처럼 커짐</td> </tr> </tbody> </table> <p>시간이 지나면서 시스템이 해결하려던 문제보다 커졌습니다. 전환 조건을 관리하고, 에이전트 책임을 설명하고, 자동화 예외를 복구하는 데 더 많은 시간을 썼습니다. 테스트가 실패하면 코드만 볼 수 없었습니다. 어느 단계가 결과를 만들었는지, 어떤 맥락이 handoff를 건넜는지, 다음 에이전트가 그 내용을 제대로 해석했는지까지 확인해야 했습니다.</p> <p>비용은 한 번의 치명적인 버그로 나타나지 않았습니다. 단계가 추가될 때마다 토큰이 들었고, handoff가 생길 때마다 맥락이 줄거나 왜곡되거나 반복될 가능성이 생겼습니다. 복구 경로마다 설계와 테스트가 필요했습니다. 개발을 빠르게 만들려던 시스템에서 정작 제품보다 시스템을 더 많이 개발하고 있었습니다.</p> <p>보이지 않는 과정도 문제였습니다. 자동화 안에서 많은 일이 일어나지만 무엇이 생성됐는지, 어떤 에이전트가 판단했는지, 왜 다음 단계가 선택됐는지가 항상 선명하지 않았습니다. 루프가 자동화될수록 저는 개발자보다 기계를 지켜보는 운영자에 가까워졌습니다.</p> <h2 id="다시-정한-경계는-엄격함을-버린-것이-아니었습니다">다시 정한 경계는 엄격함을 버린 것이 아니었습니다</h2> <p>결국 Drig를 모든 개발 단계를 맡는 자동화 프로젝트로는 내려놓기로 했습니다. 에이전트나 테스트, 리뷰와 증거를 버린 것이 아닙니다. 직접 개발과 오케스트레이션이 만나는 경계를 다시 정한 것입니다.</p> <p>당시 단순화 계획에서 정한 방향은 제품 구현을 Codex와 직접 진행하고, Drig에는 기획과 개발 후 검증·전달을 맡기는 것이었습니다. 이후 문서에는 체크포인트별 리뷰도 다시 포함됐습니다. 두 시점의 리뷰 범위는 다르지만, 제품 코드를 만드는 일과 완료 여부를 확인하는 경계를 나누려는 방향은 같습니다.</p> <p>2026년 9월 5일 프로젝트 문서를 다시 확인해 아래 흐름으로 정리했습니다. 기획에서는 작게 끝낼 작업 범위와 통과 기준을 정합니다. 구현 중에는 체크포인트에 변경과 검증 근거를 남기고, 이후 리뷰와 QA가 그 결과를 확인합니다. QA를 통과한 변경만 PR로 보내며, 머지는 소유자의 명시적 결정으로 남겨둡니다.</p> <p><img src="/images/development-automation-retrospective-flow-ko.svg" alt="Drig의 기획, Codex 직접 구현과 체크포인트, 리뷰, 제한된 QA 재시도, PR과 명시적 머지 및 종료 흐름"></p> <p><em>Drig 개념도</em></p> <p>제가 실제로 사용할 수 있게 된 방식은 이렇습니다. 바꾸려는 것을 설명하고, 관련 저장소를 확인하고, 범위가 제한된 slice를 정한 뒤, Codex와 직접 구현하고 검사를 실행합니다. Drig는 그 바깥에서 계속 쓸모가 있습니다. 프로젝트 요청을 정리하고, acceptance criteria를 기록하고, checkpoint 증거를 보존하고, 마지막 QA와 배포 경계를 지키는 역할입니다.</p> <p>직접 루프로 돌아오자 무엇을 하고 있는지 다시 보이기 시작했습니다. 어떤 질문에 답하고 있는지, 어떤 가정을 두었는지, 다음 명령이 왜 필요한지 알 수 있었습니다. 테스트가 실패해도 보이지 않는 에이전트 인계 체인을 먼저 복원하지 않고 실패 증거에서 코드까지 바로 따라갈 수 있었습니다.</p> <p>그 과정에서 생각보다 그리웠던 것도 되찾았습니다. 바로 코딩의 재미입니다. 문제를 찾고, 한 줄을 바꾸고, 검사를 실행하고, 동작이 올바른 방향으로 움직이는 것을 확인하는 데는 고유한 만족감이 있습니다. 그 루프가 자동화 뒤에 가려지면 개발자는 통제력뿐 아니라 직접 만들고 있다는 감각도 잃게 됩니다.</p> <h2 id="실험에서-남긴-것">실험에서 남긴 것</h2> <p>이번 경험이 그래프나 하네스가 나쁘다는 것을 증명한 것은 아닙니다. 오케스트레이션이 스스로 만드는 조정 비용을 감당할 만한지 먼저 물어야 한다는 기준을 남겼습니다.</p> <p>독립된 권한, 반복 가능한 전환, 오래 남겨야 할 acceptance 기록, 구현 과정과 분리된 마지막 결정을 요구하는 작업이라면 별도 경계를 둡니다. 반대로 작은 수정에 process diagram의 빈 상자가 하나 있다는 이유로 에이전트를 추가하지는 않습니다. 작고 되돌릴 수 있는 변경이라면, 유능한 모델 하나와 눈에 보이는 검증 루프가 더 나은 하네스일 때가 많습니다.</p> <p>문서를 다시 읽으며 눈여겨본 것은 재시도에도 끝이 있다는 점입니다. 첫 QA가 실패하면 소유자가 수정하거나 멈추기로 결정합니다. 수정을 선택하면 한 번 더 QA를 받고, 두 번째 QA도 실패하면 그 시도는 닫습니다. 머지 뒤 종료 처리는 리뷰와 QA를 처음부터 반복하지 않습니다. 모델이 판단할 단계와 시스템이 이미 끝난 일을 기록할 단계를 구분한 것입니다.</p> <p><img src="/images/development-automation-retrospective-context-03.png" alt="안정적인 입력이 명확한 단계를 지나 예측 가능한 결과로 이어지는 정돈된 업무 흐름"></p> <p><em>입력과 전환, 결과가 안정적인 업무에서는 구조화된 흐름이 오히려 이해와 반복을 돕습니다.</em></p> <h2 id="다음-자동화-전에-확인할-질문">다음 자동화 전에 확인할 질문</h2> <p>다음 계층을 추가하기 전에 다섯 가지를 먼저 확인하려 합니다.</p> <ol> <li>이 작업은 오케스트레이션을 정당화할 만큼 반복적인가?</li> <li>모든 전환을 사람이 확인하고 설명할 수 있는가?</li> <li>자동화가 소비하는 시간과 context보다 더 많은 것을 절약하는가?</li> <li>개발자가 숨은 상태를 복원하지 않고도 중간에 이어받을 수 있는가?</li> <li>또 하나의 복구 단계를 추가하기보다 시스템이 멈춰야 할 지점이 분명한가?</li> </ol> <p>자동화를 포기한 것은 아닙니다. 자동화가 많을수록 더 발전된 것이라는 생각을 포기했습니다. 개발에서는 개발자를 코드와 증거, 판단 가까이에 붙잡아두는 도구가 가장 좋은 도구일 수 있습니다.</p> <p>Drig의 일체형 버전을 내려놓은 일은 미래를 버린 것보다 아픈 우회로에서 빠져나온 일에 가까웠습니다. 이 프로젝트는 구조가 도움 되는 지점을 알려줬고, 동시에 제가 보고 설명하고 즐길 수 있는 개발 루프로 돌아오게 해줬습니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/open-weight-models-in-practice/https://jakob-ai-notes.pages.dev/ko/posts/open-weight-models-in-practice/오픈 웨이트 모델은 로컬 에이전트와 작업별 AI 스택을 직접 설계하는 실무 선택지가 되고 있습니다. Meta Muse Glimmer와 DeepSeek V4 Flash 사례로 가능성과 한계를 살펴봅니다.Sat, 15 Aug 2026 00:00:00 GMT<p>오픈 웨이트 모델을 둘러싼 질문이 조금 달라지고 있습니다. 예전에는 폐쇄형 모델보다 성능이 낮지만 자유롭다는 비교가 중심이었다면, 이제는 실제 장비에 설치할 수 있는지, 내 작업에 맞게 조정할 수 있는지, 모델의 기억과 도구를 직접 통제할 수 있는지가 더 중요해졌습니다.</p> <h2 id="다운로드-가능한-파일에서-설치-가능한-부품으로">다운로드 가능한 파일에서 설치 가능한 부품으로</h2> <p>Meta의 Muse Glimmer는 이 변화를 보여주는 사례입니다. AP는 Meta가 8월 10일 개인용 컴퓨터에서 실행할 수 있는 오픈 모델을 공개했다고 보도했습니다. 공식 모델 카드에는 Muse Glimmer-30B가 Apache 2.0 라이선스의 이미지·텍스트 모델로 등록되어 있습니다. Meta가 제시한 방향은 단순한 대화형 모델이 아니라 로컬 에이전트와 함수 호출을 실제 장비 안에서 다루는 것입니다. <a href="https://apnews.com/article/df8a4e7d7825470d09e8090367457c2c">AP 보도</a> <a href="https://huggingface.co/meta-models/Muse-Glimmer-30B">Muse Glimmer 모델 카드</a></p> <p>중요한 점은 모델 파일을 내려받을 수 있다는 사실보다 실행 구조를 선택할 수 있다는 데 있습니다. 어떤 런타임을 쓸지, 양자화와 메모리 예산을 어떻게 정할지, 도구 호출과 장기기억을 어디에 둘지 개발자가 설계할 수 있습니다. 폐쇄형 서비스에서는 제공자가 정한 경계가 출발점이지만, 오픈 웨이트에서는 작업에 맞는 경계를 다시 만들 수 있습니다.</p> <h2 id="deepseek-v4-flash가-넓힌-선택지">DeepSeek V4 Flash가 넓힌 선택지</h2> <p>DeepSeek V4 Flash도 다른 방식의 사례입니다. 공식 모델 카드에 따르면 전체 파라미터는 2,840억 개지만 추론 때 활성화되는 파라미터는 130억 개이며, 최대 100만 토큰 컨텍스트와 MIT 라이선스를 제공합니다. Transformers, vLLM, SGLang, llama.cpp 등 실행 경로도 안내합니다. 이는 작은 모델 하나가 모든 노트북에서 가볍게 돌아간다는 뜻이 아닙니다. 전체 가중치, 양자화 방식, GPU 메모리와 지연시간은 여전히 배포를 결정합니다. 의미는 거대한 모델도 구조와 실행 방식을 함께 설계하면 특정 작업에 맞는 비용·성능 선택지가 될 수 있다는 데 있습니다. <a href="https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash">DeepSeek V4 Flash 모델 카드</a> <a href="https://arxiv.org/abs/2606.19348">기술 보고서</a></p> <p><img src="/images/open-weight-models-in-practice-context-01.png" alt="작업별로 다른 오픈 웨이트 모델을 로컬 도구에 연결하는 모습을 단순화한 일러스트"></p> <p><em>모델을 고르는 기준이 종합 순위에서 작업·도구·실행 환경의 조합으로 옮겨가는 모습을 표현했습니다.</em></p> <p>최근 공개 개발자 논의도 종합 벤치마크 순위보다 코딩, 문서 검색, 툴 호출, 개인 지식 관리에서 얼마나 안정적인지를 비교하는 쪽으로 이동하고 있습니다. 다만 경험은 하드웨어와 설정에 따라 달라집니다. 특정 오픈 웨이트 모델이 폐쇄형 모델을 완전히 넘어섰다고 단정하기보다, 실제 업무의 지연시간·오류 복구·데이터 이동을 측정해야 합니다.</p> <h2 id="자유도만큼-운영-책임도-커진다">자유도만큼 운영 책임도 커진다</h2> <p>오픈 웨이트의 장점은 성능표 1위보다 소유권에 있습니다. 민감한 데이터를 외부로 보내지 않고, 기억 구조를 직접 설계하며, 검색·코딩·감사처럼 역할별 모델을 조합할 수 있습니다. 반대로 안전장치, 라이선스, 학습 데이터의 출처, 업데이트와 로그를 직접 관리해야 합니다. 가중치를 공개했다고 해서 데이터와 운영 방식까지 자동으로 투명해지는 것도 아닙니다.</p> <p>결국 질문은 오픈 모델이 폐쇄형 모델보다 좋은가가 아닙니다. 어떤 작업은 외부 서비스에 맡기고, 어떤 작업은 내 환경 안에서 직접 소유할 것인지 정하는 문제에 가깝습니다. Muse Glimmer와 V4 Flash는 이 선택이 더 이상 연구실의 실험이 아니라 실제 스택 설계의 문제가 되고 있음을 보여줍니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/lovable-app-bridge/https://jakob-ai-notes.pages.dev/ko/posts/lovable-app-bridge/코드를 모르는 창업자와 팀이 자연어로 웹앱을 만들고 배포하는 Lovable의 강점, 비용, 시장성, 한계를 살펴봅니다.Fri, 14 Aug 2026 00:00:00 GMT<p>Lovable은 자연어로 웹사이트와 웹앱을 만들고 배포하는 AI 앱 빌더입니다. 설명·화면 캡처·Notion 문서에서 인터페이스, 인증, DB, 파일 저장, 결제, 호스팅까지 연결합니다. 공식 사이트가 “AI 공동창업자이자 개발팀”이라 부르는 이유는 예쁜 첫 화면보다 아이디어 검증 시간을 줄이기 때문입니다. <a href="https://lovable.dev/">Lovable 홈페이지</a>에서 무료로 시작할 수 있습니다.</p> <h2 id="어떤-문제를-누구에게서-덜어주는가">어떤 문제를, 누구에게서 덜어주는가</h2> <p>비개발 창업자, PM, 디자이너, 영업·운영팀은 문제를 알아도 개발자를 찾고 요구사항을 번역하느라 몇 주에서 몇 달을 씁니다. Figma나 기획서는 사용성과 결제를 검증하지 못하고, 외주는 과하거나 허술할 수 있습니다. Lovable은 이 “아이디어와 코드 사이의 번역 비용”을 줄여 MVP, 내부 도구, 좁은 고객용 흐름을 빠르게 시험하게 합니다. 공식 사례에서 Yannis Karagiannidis는 뉴스레터 커스터마이징 문제를 해결하는 PrintPigeon을 3일 만에 출시했습니다.</p> <p>스톡홀름의 공동창업자 Anton Osika와 Fabian Hedin은 오픈소스 프로젝트 GPT Engineer를 바탕으로 Lovable을 키웠습니다. 회사는 코딩하지 않는 99%에게 소프트웨어 제작을 열겠다고 강조합니다. 2026년 7월 MCP 연동을 발표해 ChatGPT·Claude가 앱의 승인된 기능을 호출하도록 한 것도 같은 방향입니다. Anthropic의 2026년 보고서도 Lovable 사례를 소개하며 회사 측 수치로 수동 개발보다 20배 빠른 개발과 100만 명 이상의 월간 사용자를 언급했습니다.</p> <p><img src="/images/lovable-agent-integrations-context-01.png" alt="Lovable 앱이 Claude와 ChatGPT 안에서 작동하는 공식 발표 이미지"></p> <p><em>이미지: Lovable 공식 발표 이미지. 출처: <a href="https://lovable.dev/blog/agent-integrations">Lovable 공식 발표</a></em></p> <h2 id="비용과-실제-반응">비용과 실제 반응</h2> <p>2026년 8월 기준 무료 플랜은 하루 빌드 5크레딧(월 최대 30개), Cloud 20크레딧, 앱 AI 4크레딧을 제공합니다. Pro는 월 25달러(100크레딧부터), Business는 50달러(100크레딧부터)이며 연간 결제는 각각 월 21달러, 42달러 수준입니다. 빌드·호스팅·앱 AI가 같은 잔액에서 차감되므로 요청 복잡도와 트래픽에 따라 실제 운영비는 달라집니다.</p> <p>커뮤니티의 반응은 양면적입니다. 첫 프로토타입은 빠르지만, 최근 <a href="https://www.reddit.com/r/ArtificialInteligence/comments/1v8w9th/are_ai_web_app_builders_still_worth_using_in_2026/">Reddit 토론</a>에서는 인증·DB·결제·권한·유지보수·보안을 출시 후 누가 책임지는지가 문제로 제기됐습니다. TechRadar도 속도와 함께 지시에서 벗어나는 결과를 지적했습니다. Lovable 역시 2026년 4월 공개 프로젝트의 채팅 기록과 소스 코드가 접근될 수 있었던 권한 회귀를 인정하고 수정했습니다. 약점은 생성 여부보다 검증과 안전한 운영입니다.</p> <h2 id="시장-가능성과-한계">시장 가능성과 한계</h2> <p>Lovable의 자체 조사에서는 빌더의 80%가 비기술 직군이고, 10명 중 8명이 결과물을 수익화하려 합니다. 시장은 랜딩페이지에서 B2B SaaS, 내부 대시보드, 마켓플레이스, 자동화로 넓어질 수 있습니다. GitHub 동기화·코드 다운로드와 React·Supabase·Tailwind 표준 스택은 개발자에게 넘겨줄 확장성을 보완합니다.</p> <p>반면 생성 코드의 품질 편차, 모델의 오해, Cloud 비용, 보안 검토, 벤더 의존성은 남습니다. 모바일도 웹앱·PWA·Capacitor 중심입니다. Lovable은 개발팀을 없애는 서비스라기보다 개발팀을 만나기 전 검증 시간을 줄이는 서비스이며, 장기적으로 권한·관측·운영까지 책임지는 인프라가 될 수 있는지가 관건입니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/claude-watermark-open-or-closed/https://jakob-ai-notes.pages.dev/ko/posts/claude-watermark-open-or-closed/Anthropic의 보이지 않는 워터마크와 계정 경계가 통제되는 AI 서비스와 들여다볼 수 있는 개발자 도구의 차이를 보여줍니다.Fri, 14 Aug 2026 00:00:00 GMT<h2 id="워터마크는-기능보다-제품-철학에-가깝다">워터마크는 기능보다 제품 철학에 가깝다</h2> <p>Anthropic은 새 Claude 모델이 만든 텍스트에 보이지 않는 워터마크를 넣고, 지원되는 파일에는 서명된 출처 메타데이터를 붙이기 시작했습니다. EU AI Act의 투명성 규정과 연결된 변화입니다. 이 규정은 AI가 만든 텍스트·이미지·음성·영상이 기술적으로 확인될 수 있도록 표시할 것을 요구합니다. Anthropic은 유럽에만 적용하는 것이 아니라 전 세계에 표시를 적용한다고 설명합니다. 동시에 이 신호가 저자성을 확정하는 증거는 아니며, 강한 편집·바꿔쓰기·번역이나 메타데이터 제거를 거치면 사라질 수 있다고 안내합니다.</p> <p>취지는 이해할 수 있습니다. AI가 만든 결과물을 사람이 만든 것처럼 유통하는 문제는 커지고 있고, 기계가 읽을 수 있는 출처 정보는 사기와 허위정보를 줄이는 데 도움이 될 수 있습니다. 그러나 이 작은 기술 표시는 더 큰 방향도 보여줍니다. 채팅창을 떠난 결과물이 어떤 흔적을 가지고 이동할지 서비스 제공자가 결정하기 시작했다는 점입니다.</p> <p><img src="/images/claude-watermark-open-or-closed-context-01.png" alt="AI가 만든 문서의 확인 가능한 표시를 살피고 출처 메타데이터가 파일 폴더로 이동하는 모습을 표현한 일러스트"></p> <p><em>AI 생성 문서에 남은 출처 신호가 파일을 따라가는 과정을 표현했습니다.</em></p> <h2 id="돈을-낸-구독이-열린-개발자-영역을-뜻하지는-않는다">돈을 낸 구독이 열린 개발자 영역을 뜻하지는 않는다</h2> <p>Anthropic의 계정 경계에서도 비슷한 느낌을 받을 수 있습니다. Anthropic 공식 문서에 따르면 Claude Pro 구독에는 Claude Console을 통한 API 사용이 포함되지 않습니다. 애플리케이션이나 연동 기능을 만들려는 개발자는 별도의 Console 접근 권한과 API 결제를 준비해야 합니다. 또한 외부 도구는 API 키 인증을 사용해야 하며, 제3자 트래픽을 숨기거나 구독 한도를 우회하는 방식은 제재 대상이 될 수 있다고 안내합니다.</p> <p>Anthropic이 모든 외부 사용을 막는다고 말하면 부정확합니다. 공식 API라는 개발자 경로가 실제로 있기 때문입니다. 다만 경계는 분명합니다. 소비자용 서비스를 구독했다고 해서 Claude를 원하는 외부 작업 흐름에 같은 방식으로 연결할 자유까지 얻는 것은 아닙니다. 구독을 범용적인 능력으로 기대한 사용자에게는 이 분리가 꽤 답답하게 느껴질 수 있습니다.</p> <p>저는 Anthropic을 예전부터 지켜보며 비슷한 인상을 받았습니다. 회사 내부의 DNA를 안다고 말할 수는 없지만, 정책만 놓고 보면 개발자 생태계가 허용된 문들의 목록처럼 느껴질 때가 있습니다. 새로운 연결, 자동화, 계정 사용 방식은 먼저 권한·신원·제재의 관점에서 해석됩니다. 안전과 악용 방지는 분명 정당한 이유입니다. 다만 통제가 가능성보다 먼저 보이기 시작하면 사용자가 느끼는 도구의 성격도 달라집니다.</p> <h2 id="codex가-다르게-보이는-이유">Codex가 다르게 보이는 이유</h2> <p>여기서 Codex와의 대비가 선명해집니다. 정확히 말하면 OpenAI의 모든 Codex 제품과 모델이 오픈소스라는 뜻은 아닙니다. 그러나 Codex CLI는 오픈소스 명령줄 도구로 공개되어 있고, OpenAI는 그 뒤에서 작동하는 에이전트 구현도 오픈소스라고 설명합니다. 개발자는 로컬 에이전트가 파일을 읽고, 도구를 호출하고, 승인을 적용하고, 샌드박스 안에서 실행되는 방식을 살펴볼 수 있습니다.</p> <p>이 차이는 구호보다 중요합니다. 공개된 구현이라고 해서 모델이 자동으로 안전해지는 것도 아니고, 이용 정책이나 계정 요건이 사라지는 것도 아닙니다. 대신 통제할 수 있는 일부가 개발자 가까이 이동합니다. 제공자가 어떤 작업을 허용할지만 기다리는 대신, 도구를 살펴보고 필요한 부분을 바꾸거나, 확인 가능한 실행 계층 위에 자신의 연동을 만들 수 있습니다.</p> <p>저에게 이것은 통제되는 서비스와 조합 가능한 도구의 차이입니다. Anthropic의 방식은 정해진 경계 안에서 모델을 사용하고 결과가 어떻게 만들어졌는지는 제공자가 확인하도록 합니다. Codex의 오픈소스 CLI는 적어도 중요한 한 계층을 개발자가 살펴보고 바꿀 수 있게 합니다. 완전한 자유는 아니지만 개발자 생태계와 맺는 관계가 다릅니다.</p> <h2 id="오픈소스가-규칙이-없다는-뜻은-아니다">오픈소스가 규칙이 없다는 뜻은 아니다</h2> <p>이 문제를 좋은 회사와 나쁜 회사의 대결로 단순화하는 것도 위험합니다. 출처 표시는 공익에 기여할 수 있고, 폐쇄형 서비스가 운영 안전성에서 더 강할 때도 있습니다. 오픈소스 코드에도 보안 취약점은 생길 수 있으며, 에이전트의 실행 구조를 볼 수 있다고 모델까지 투명해지는 것은 아닙니다.</p> <p>더 나은 질문은 경계를 누가 통제하느냐입니다. 사용자가 제한을 이해할 수 있는가. 개발자가 다른 연동 경로를 선택할 수 있는가. 관련 계층을 검사·포크·교체할 수 있는가. 제재의 이유가 위험에 비례하는가.</p> <p>Anthropic의 워터마크는 AI 결과물을 더 관리하기 쉬운 대상으로 만듭니다. Codex CLI의 오픈소스 구현은 에이전트의 일부를 더 들여다볼 수 있게 합니다. 앞으로 AI 생태계는 강한 제공자 규칙을 따르는 관리형 비서와, 개발자의 판단 공간을 더 많이 남기는 도구 사이로 나뉠 수 있습니다.</p> <p>자유는 제한이 전혀 없는 상태가 아닙니다. 제한이 어디에 있고 왜 생겼는지 알며, 필요할 때 다른 방식으로 만들 수 있는 상태에 가깝습니다. 그래서 Anthropic과 Codex의 차이는 워터마크 하나보다 크게 느껴집니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/agent-memory-needs-audit/https://jakob-ai-notes.pages.dev/ko/posts/agent-memory-needs-audit/장기기억은 저장과 검색만의 문제가 아니라 유효성·관계·출처·접근·사용 이력을 감사할 수 있어야 한다는 점을 연구와 Luthn 사례로 살펴봅니다.Thu, 13 Aug 2026 00:00:00 GMT<p>기억을 저장하는 일은 쉽습니다. 그 기록을 남기고, 보여주고, 사용하고, 나중에도 믿어도 되는지 감사하는 일은 더 어렵습니다.</p> <p>에이전트는 대화를 요약해 저장하고 다음 달 비슷한 기록을 검색할 수 있습니다. 어려운 질문은 그 뒤에 옵니다. 왜 아직 남아 있는지, 지금도 참인지, 다른 기억과 충돌하지 않는지, 누가 볼 수 있었는지, 잘못된 기억이 어떤 답변이나 행동에 쓰였는지를 설명해야 합니다.</p> <p>최근 장기기억 연구는 기억을 더 큰 저장소가 아니라 감사 가능한 선택의 문제로 다룹니다. 제품에서 이 차이가 중요한 이유는 최종 답변 점수만으로 기억을 잘 쓴 것인지, 검색과 추론이 나쁜 기록을 우연히 보완한 것인지 구분하기 어렵기 때문입니다.</p> <h2 id="기억-쓰기도-별도로-평가해야-합니다">기억 쓰기도 별도로 평가해야 합니다</h2> <p>2026년 5월 공개된 MEMAUDIT는 미래 질문을 모르는 상태에서 고정된 예산 안에 무엇을 남길지 평가하는 방법을 제안했습니다. 이 프로토콜은 표현 품질, 유효성 상태 보존, 예산에 맞는 선택을 나눠 봅니다. 나중에 답할 수 있는지만이 아니라, 미래 작업을 알기 전에 기억 시스템이 방어 가능한 결정을 했는지를 보는 것입니다.</p> <p>6월의 Learning What to Remember는 최근성이나 단순한 의미 유사성만으로 잊을 대상을 정하면 안 된다고 주장합니다. 신뢰성·목표 관련성·사용자 관련성·작업 효용도 함께 봐야 한다는 접근입니다. 논문의 제한된 블라인드 조건 실험에서 다요인 방식은 정답 근거 보존율 0.770 ± 0.011을 기록해 균등 가중치 0.657, 최근성 기준 0.368보다 높았습니다. 모든 에이전트에 적용되는 법칙은 아니지만, 무엇을 잊을지도 별도의 평가 대상이라는 근거입니다.</p> <p>SubtleMemory도 1,522개 평가 인스턴스와 1,090개 관계 통제 세트로 서로 보완·변경·충돌하는 기억을 시험했습니다. 현재 시스템이 기억 사이의 미세한 관계를 구분하는 데 약하다는 보고입니다.</p> <p>따라서 연구가 지지하는 결론은 조심스럽게 잡아야 합니다. 장기기억의 품질은 무엇을 보존하는지, 무엇을 불확실하게 표시하는지, 기록 사이의 관계를 어떻게 처리하는지를 포함합니다. 검색 적중률만의 문제가 아닙니다.</p> <h2 id="기억은-상태를-가진-주장입니다">기억은 상태를 가진 주장입니다</h2> <p>제품 설계의 언어로 바꾸면 기억은 텍스트 한 덩어리가 아니라 이력과 범위를 가진 주장입니다.</p> <table> <thead> <tr> <th>항목</th> <th>감사가 답할 수 있어야 하는 질문</th> </tr> </thead> <tbody> <tr> <td>출처</td> <td>이 기록은 어디에서 왔고 언제 만들어졌는가?</td> </tr> <tr> <td>종류</td> <td>사실·선호·지시·관찰·추정 중 무엇인가?</td> </tr> <tr> <td>유효성</td> <td>어떤 사용자·프로젝트·작업·시간 범위에서 유효한가?</td> </tr> <tr> <td>관계</td> <td>다른 기록을 보완·수정·반박하는가?</td> </tr> <tr> <td>사용</td> <td>이후 어떤 답변·결정·도구 행동에 쓰였는가?</td> </tr> <tr> <td>접근</td> <td>어떤 에이전트나 요청자가 어떤 권한으로 보았는가?</td> </tr> </tbody> </table> <p><img src="/images/agent-memory-needs-audit-context-01.png" alt="서로 다른 기억 버전의 신뢰도와 유용성을 비교하는 과정을 표현한 일러스트"></p> <p><em>장기기억은 저장된 사실의 목록이 아니라 서로 다른 상태를 비교하고 판단하는 과정입니다.</em></p> <p>기억이 충돌하면 최신 기록 하나로 덮는 것보다 두 기록의 관계와 확인 필요성을 남기는 편이 유용할 때가 많습니다. 최근 기록이 틀릴 수도 있고, 오래된 기록이 현재 범위 밖일 수도 있습니다. 유효성과 출처가 없으면 검색 시스템은 둘을 구분할 방법이 없습니다.</p> <h2 id="luthn은-저장과-에이전트-가시성을-나눕니다">Luthn은 저장과 에이전트 가시성을 나눕니다</h2> <p>이 관점에서 <a href="https://github.com/JakobSung/Luthn">Luthn</a>은 안전한 맥락을 구현한 현실적인 사례입니다. Luthn은 원문을 에이전트의 기본 맥락으로 넘기지 않습니다. 입력을 분류하고 가린 뒤 에이전트가 볼 수 있는 안전한 요약과 맥락을 따로 만듭니다. 저장됐다는 사실과 에이전트가 읽을 수 있다는 권한을 분리하고, 외부 공개도 별도의 명시적 승인으로 다룹니다.</p> <p><img src="/images/agent-memory-needs-audit-context-02.png" alt="기억 기록이 출처·유효성·범위·사용 이력을 확인받은 뒤 압축된 감사 메타데이터로 남는 과정을 표현한 일러스트"></p> <p><em>좋은 감사 기록은 결정의 메타데이터를 남기되 보호된 원문의 두 번째 복사본이 되지 않습니다.</em></p> <p>공개 설계에서 감사 기록도 저장·공유·조회·결정·실패를 추적하는 수준에 둡니다. 대화 원문을 보관하는 아카이브나 원래 기록을 복구하는 통로로 만들지 않습니다. 운영 질문은 “에이전트가 무엇을 기억했나?”뿐 아니라 “왜 이 기억이 보였나?”이기 때문입니다.</p> <p>Luthn이 모든 기억 문제를 해결한다는 뜻은 아닙니다. 분류·안전한 투영·접근 권한·감사 기록을 하나의 기능으로 뭉개지 않는 설계를 보여주는 사례입니다. 보호된 원문을 돌려주지 않고도 해당 투영이 만료됐거나 거부됐다는 사실을 설명할 수 있어야 합니다.</p> <p><img src="/images/agent-memory-needs-audit-context-03.png" alt="기억을 사용하지 않는 기준선·제한된 기억·넓은 검색 정책을 같은 테스트로 비교하는 과정을 표현한 일러스트"></p> <p><em>기억 정책의 품질은 저장량보다 선택·거부·출처·권한 판단을 같은 조건에서 비교할 때 드러납니다.</em></p> <h2 id="기억-정책을-비교하는-최소-실험">기억 정책을 비교하는 최소 실험</h2> <p>새 기억 정책을 도입할 때는 최종 답변이 좋아졌다는 인상만으로 판단하기 어렵습니다. 같은 작업 기록을 세 가지 조건으로 나누어 비교하는 편이 낫습니다. 기억을 쓰지 않는 기준선, 출처와 유효성만 남기는 제한된 기억, 검색 결과를 넓게 노출하는 기존 방식입니다. 세 조건에 같은 질문과 같은 도구 권한을 주면 기억 자체가 만든 차이를 관찰하기 쉬워집니다.</p> <p>비교할 지표도 답변 정확도 하나로 끝내지 않습니다. 어떤 기록이 선택됐는지 출처가 완전히 연결되는지, 오래된 사실을 현재 사실처럼 말하지 않고 확인을 요청하는지, 서로 충돌하는 기록을 구분하는지, 요청자의 범위를 넘는 기억을 숨기는지, 기억이 실제 답변이나 도구 호출에 쓰였다는 흔적이 남는지를 각각 기록해야 합니다. 잘못된 기억을 사용하지 않은 것도 성공 결과에 포함해야 합니다.</p> <p>예를 들어 같은 선호가 바뀌거나 프로젝트 범위가 달라지는 대화, 일부 기록만 접근 가능한 요청, 상위 모델로 넘겨야 하는 모호한 질문을 테스트 세트에 넣을 수 있습니다. 평가자는 최종 문장뿐 아니라 선택된 기억·거부된 기억·만료 상태·권한 판단을 확인합니다. 이 과정에서 개인정보나 보호된 원문을 평가 산출물에 복사하지 않도록 식별자와 요약만 남겨야 합니다.</p> <p>이런 실험은 특정 정책이 모든 에이전트를 개선한다고 보장하지 않습니다. 다만 기억 시스템이 얼마나 많이 저장했는지보다, 무엇을 선택했고 무엇을 사용하지 않았으며 그 판단을 나중에 설명할 수 있는지를 비교하게 해줍니다.</p> <h2 id="감사는-네-가지-질문에-답해야-합니다">감사는 네 가지 질문에 답해야 합니다</h2> <p>운영자가 모든 대화를 다시 읽을 필요는 없습니다. 제한된 감사 기록만으로도 적어도 다음 네 가지는 확인할 수 있어야 합니다.</p> <ol> <li>어떤 원문과 분류 결과가 이 기억을 만들었는가?</li> <li>어떤 소유자·프로젝트·작업·만료 조건에서 유효했는가?</li> <li>어떤 에이전트나 요청자가 어떤 권한으로 받았는가?</li> <li>이후 답변이나 도구 행동에 영향을 줬고, 그 다음 결과는 무엇이었는가?</li> </ol> <p>원문을 감사 로그에 복사하면 또 하나의 민감한 저장소가 생깁니다. 아무 기록도 남기지 않으면 잘못된 기억을 조사할 수 없습니다. 필요한 중간 지점은 결정과 연결되지만 원문으로 무제한 돌아갈 수 없는 작고 조회 가능한 메타데이터입니다.</p> <p>인용한 논문과 공개된 Luthn 문서는 설계 방향을 제시할 뿐, 로컬에서 통제한 A/B 실험의 결과는 아닙니다. 하나의 기억 정책이 모든 에이전트를 개선한다고 측정한 것도 아닙니다. 다만 장기기억이 커질수록 검색 품질과 함께 유효성·출처·접근·사용 이력도 평가해야 한다는 판단은 분명해집니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/vibe-coding-harms-in-korea/https://jakob-ai-notes.pages.dev/ko/posts/vibe-coding-harms-in-korea/바이브코딩이 낮춘 개발 장벽 뒤에서 운영·보안·책임의 비용이 누구에게 넘어가는지, 한국 시장의 과열된 기대를 중심으로 짚어봅니다.Wed, 12 Aug 2026 04:44:29 GMT<p>작동하는 화면 하나를 만드는 일과 서비스를 책임지는 일 사이에는 큰 간격이 있습니다. 한국의 바이브코딩 열풍은 이 간격을 너무 쉽게 지웁니다. AI에게 기능을 말하고 코드와 배포 결과를 얻으면 개발이 아이디어를 설명하는 일로 바뀐 듯합니다.</p> <p>하지만 사용자가 들어오고 결제와 개인정보가 얽히는 순간 질문은 달라집니다. 누가 시스템을 고칠 것인가. 장애와 데이터 손실을 어떻게 복구할 것인가. 이 질문에 답하지 못한 채 결과물만 시장에 올리는 일이 바이브코딩의 첫 번째 폐해입니다.</p> <h2 id="프로토타입은-서비스가-아니다">프로토타입은 서비스가 아니다</h2> <p>바이브코딩 자체는 문제라기보다 유용한 도구입니다. 초기 프로토타입, 내부 자동화, 아이디어 검증에서는 비개발자도 자신의 문제를 작은 도구로 풀어볼 수 있습니다.</p> <p>개발자의 생산성을 돕던 도구가 “개발을 몰라도 서비스와 수익을 만들 수 있다”는 약속으로 바뀌는 데서 문제가 시작됩니다. 진입장벽이 낮아진 것과 소프트웨어 사업의 난도가 낮아진 것은 같은 말이 아닙니다.</p> <p>국내 수요가 커지는 흐름은 확인됩니다. 뉴시스는 패스트캠퍼스 자체 집계를 인용해 바이브코딩 강의 매출이 6개월 만에 175% 늘고, 강의 수가 15개에서 39개로 증가했다고 보도했습니다. 한국 전체 시장이나 강의 품질을 보여주는 수치는 아니지만, 새 도구가 교육 상품과 수익 기회로 빠르게 포장된다는 신호입니다.</p> <p>Stack Overflow의 2025 개발자 조사에서도 응답자의 87%는 AI 에이전트의 정확성을, 81%는 보안과 개인정보를 우려했습니다. 한국 시장을 측정한 자료는 아니지만, 현업에서도 생성 결과를 그대로 믿지 않는다는 점은 보여줍니다.</p> <h2 id="운영비는-사라지지-않는다">운영비는 사라지지 않는다</h2> <p>바이브코딩은 화면을 빨리 만들지만 운영에 필요한 일은 화면 뒤에 남깁니다. 요구사항과 권한, 비밀정보와 데이터, 마이그레이션을 관리해야 합니다. 오류와 성능을 관찰하고 백업·의존성·클라우드 비용·개인정보를 점검하며, 문의와 장애에도 대응해야 합니다.</p> <p><img src="/images/vibe-coding-harms-in-korea-context-01.png" alt="작동하는 웹서비스 아래에 모니터링, 데이터, 보안, 서버, 복구 도구가 기반을 이루는 모습을 표현한 편집 일러스트"></p> <p><em>빠르게 만든 화면 아래에는 운영을 지탱하는 보이지 않는 기반이 있습니다.</em></p> <p>AI는 이 작업을 도울 수 있지만 책임을 대신 지지는 않습니다. METR은 숙련 오픈소스 개발자 16명의 246개 작업을 분석한 실험에서, 2025년 초 AI 도구 사용이 완료 시간을 오히려 19% 늘렸다고 보고했습니다. 모든 도구에 적용되는 법칙은 아니지만, 새 데모와 기존 시스템의 안전한 변경은 다르다는 점을 보여줍니다.</p> <p>Veracode의 실험에서도 100개가 넘는 모델이 수행한 80개 과제 중 보안 요구를 만족한 비율은 55%였습니다. 실제 서비스 전체의 결과는 아니지만, “실행된다”와 “안전하다”가 다른 품질 축이라는 점은 분명합니다.</p> <h2 id="한탕주의가-만드는-신뢰의-비용">한탕주의가 만드는 신뢰의 비용</h2> <p>생성 비용이 내려가면 결과물의 공급은 늘어납니다. 시장이 문제 해결보다 배포된 화면과 짧은 성공담을 보상하면, 오래 운영할 수 없는 제품도 계속 만들어질 수 있습니다. 아직 한국 시장 전체가 망가졌다고 단정할 통계는 없지만, 로그인·결제·데이터 삭제가 실패하고 문의가 사라지는 경험이 쌓이면 새로운 서비스 전체가 의심받게 됩니다.</p> <p>AI로 돈을 벌게 해주겠다는 강의도 같은 구조 안에 있습니다. 도구를 배우는 교육에는 가치가 있지만 “도구를 익히면 곧 수익이 난다”는 약속은 기술보다 기대를 판매합니다. 개발과 사업에는 몇 번의 프롬프트로 안정적인 수익이 생긴다는 공식이 없습니다. 고객의 문제, 제품 전달, 반복 사용, 가격, 장애와 문의를 함께 책임져야 수익이 만들어집니다.</p> <p>직접 비용을 떠안는 쪽은 개발자와 운영자일 때가 많습니다. 이들은 엉킨 코드를 읽고, 보안 문제를 막고, 장애를 복구하며, “AI가 하루 만에 만들었다”는 기대 뒤의 일을 처리합니다. 그 노동이 값싸게 취급되면 개발자의 전문성과 진짜 제품을 만드는 팀 모두가 불리해집니다.</p> <h2 id="개발자는-사라지지-않는다">개발자는 사라지지 않는다</h2> <p>미래에 개발자가 없어질 것이라고 생각하지 않습니다. 다만 직접 코드를 입력하는 행위의 상당 부분은 줄어들 수 있습니다. 코딩을 하지 않는다고 해서 코드를 보지 않는 것은 아닙니다. AI가 만든 코드의 구조와 실패 지점, 다른 시스템과의 연결을 판단하는 눈은 더 중요해집니다.</p> <p><img src="/images/vibe-coding-harms-in-korea-context-02.png" alt="개발자가 코드와 아키텍처 구조가 그려진 설계 문서를 읽고 안정적인 구조물을 검토하는 모습을 표현한 편집 일러스트"></p> <p><em>앞으로의 개발자는 코드를 쓰는 사람인 동시에 코드를 읽고 판단하는 사람입니다.</em></p> <p>개발자의 소양은 코딩 속도만으로 평가하기 어려워질 것입니다. 요구사항을 기술 구조로 바꾸는 지식, 장애를 견디는 아키텍처 설계, 생성된 코드를 검토하는 판단력이 핵심으로 남습니다. 코드를 작성하는 손은 AI에 빌릴 수 있어도 무엇을 배포할지 결정하는 책임까지 넘길 수는 없습니다.</p> <h2 id="배포-전에-물어야-할-것">배포 전에 물어야 할 것</h2> <p>장애가 나면 되돌릴 수 있는가. 백업을 실제로 복구해 봤는가. 비밀정보와 사용자 데이터의 위치를 아는가. 오류를 찾을 로그와 모니터링이 있는가. 의존성 변경과 사용자 문의를 누가 책임질 것인가.</p> <p>이 질문에 답하지 못한다면 아이디어를 포기할 필요는 없습니다. 아직은 서비스가 아니라 프로토타입이라고 말하면 됩니다. 테스트 범위와 사용자를 제한하고 운영 책임자를 정한 뒤 다음 단계로 넘어가면 됩니다.</p> <p>바이브코딩은 개발의 문턱을 낮췄지만 책임의 문턱까지 없애지는 않았습니다. 중요한 것은 AI를 쓰지 않는 일이 아니라, 빠르게 만든 결과물을 언제 시장에 내놓을 수 있는지 판단하는 일입니다. 만들었다는 사실보다 고칠 수 있는가, 팔았다는 사실보다 계속 책임질 수 있는가를 먼저 물어야 합니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/needle-2-specialized-llm-everywhere/https://jakob-ai-notes.pages.dev/ko/posts/needle-2-specialized-llm-everywhere/Needle 2를 통해 작은 온디바이스 모델에서는 도착할 기기, 도구 계약, 신뢰도 기준, 상위 경로까지 모델 설계의 일부가 된다는 점을 살펴봅니다.Wed, 12 Aug 2026 00:00:00 GMT<p>AI 모델을 이야기할 때 우리는 먼저 누가 더 똑똑한지 비교합니다. Needle 2는 다른 질문을 던집니다. 모델은 실제로 어디에 들어갈 수 있고, 그곳에서 안정적으로 수행할 만큼 일이 충분히 좁은가요?</p> <p>Needle 2는 Cactus Compute가 도구 호출·기기 사용·구조화된 정보 추출을 위해 만든 4,500만 파라미터 모델로 설명됩니다. 전체 모델은 14MB짜리 단일 바이너리이고, 공식 저장소는 한 세션에 약 28MB의 RAM을 사용한다고 안내합니다. 모든 주제를 다루려는 범용 챗봇과는 목표가 다릅니다.</p> <h2 id="작다는-숫자보다-좁은-계약이-중요합니다">작다는 숫자보다 좁은 계약이 중요합니다</h2> <p>Needle 2는 에이전트 행동을 제한된 계약으로 다룹니다. 입력은 일반 문장이지만 출력은 선언된 도구 스키마에 맞는 구조화된 데이터여야 합니다. 공개 저장소는 바이트 단위 문법 제약, 신뢰도 점수, 도구 검색, 256토큰 슬라이딩 윈도우를 설명합니다. 선언된 도구로 처리할 수 없는 요청에는 자유로운 답변을 지어내기보다 빈 호출을 반환할 수 있습니다.</p> <table> <thead> <tr> <th>설계 선택</th> <th>실무에서 생기는 결과</th> </tr> </thead> <tbody> <tr> <td>구조화된 출력</td> <td>실행 전에 호스트 시스템이 도구 호출을 검증할 수 있습니다.</td> </tr> <tr> <td>바이트 단위 문법</td> <td>“지켜라”는 프롬프트가 아니라 스키마가 출력 범위를 제한합니다.</td> </tr> <tr> <td>신뢰도 점수</td> <td>언제 실행하고 언제 상위 경로로 넘길지 정할 수 있습니다.</td> </tr> <tr> <td>도구 검색</td> <td>매 턴마다 큰 도구 목록 전체를 노출하지 않아도 됩니다.</td> </tr> <tr> <td>제한된 맥락</td> <td>대화가 이어져도 메모리 사용량을 예측하기 쉽습니다.</td> </tr> </tbody> </table> <p>핵심은 파라미터 수 자체가 아닙니다. “방을 조금 시원하게 해줘”를 유효한 온도조절기 호출로 바꾸는 모델은 기후 시스템에 관한 긴 글을 쓰는 모델만큼의 지식을 필요로 하지 않습니다. 할 일을 좁히면 로컬 실행과 예측 가능한 출력을 함께 설계하기 쉬워집니다.</p> <h2 id="도착할-곳이-모델-설계의-일부가-됩니다">도착할 곳이 모델 설계의 일부가 됩니다</h2> <p>더 흥미로운 가능성은 작은 범용 모델 하나를 휴대폰에 넣는 데서 끝나지 않습니다. 특화 LLM은 들어갈 장소에 맞춰 만들어질 수 있습니다. 스마트워치에는 건강 이벤트와 짧은 음성 명령, 자동차에는 실내 제어와 내비게이션 의도, 가정용 기기에는 연결된 가전과 안전 경계, 로봇에는 허용된 동작 목록에 맞춘 모델을 둘 수 있습니다.</p> <p><img src="/images/needle-2-specialized-llm-everywhere-context-01.png" alt="작은 특화 모델이 시계·온도조절기·로봇 센서로 갈라지는 모습을 표현한 일러스트"></p> <p><em>특정 접점을 위해 만든 모델이라면 같은 기능도 기기마다 다른 방식으로 담을 수 있습니다.</em></p> <p>Needle 2가 이 제품들을 모두 제공한다는 뜻은 아닙니다. 모델이 거대한 지능 하나가 아니라 도착 지점에 맞춘 부품이 될 수 있다는 방향입니다. 기기 안에 들어갈 정도로 작다면 제품팀은 지연시간·배터리·센서·용어·실패 정책에 맞춰 모델을 설계할 수 있습니다.</p> <p><img src="/images/needle-2-specialized-llm-everywhere-context-02.png" alt="기기에서 구조화된 호출을 만든 뒤 신뢰도에 따라 로컬 실행과 상위 경로로 나누는 흐름을 표현한 일러스트"></p> <p><em>온디바이스 모델의 역할은 호출을 만드는 데서 끝나지 않고, 실행·검증·상위 전달의 경계까지 포함합니다.</em></p> <h2 id="로컬에도-빠져나갈-길이-필요합니다">로컬에도 빠져나갈 길이 필요합니다</h2> <p>로컬에서 실행된다고 모든 요청을 로컬에 남겨야 하는 것은 아닙니다. 예측 가능한 동작은 작은 모델이 처리하고, 모호하거나 영향이 큰 요청은 더 큰 모델이나 사람에게 넘기는 구성이 현실적입니다. Needle 2의 신뢰도 기반 동작처럼 기준 이상이면 실행하고 낮으면 상위 경로로 올릴 수 있습니다. 기준값과 도구 권한, 결과 검증은 모델을 넣는 제품이 정해야 합니다.</p> <h2 id="기기에-넣기-전에-확인할-장면">기기에 넣기 전에 확인할 장면</h2> <p>작은 모델을 실제 제품에 넣기 전에는 평균 응답 속도보다 실패 장면을 먼저 모아야 합니다. “조명을 켜줘”처럼 도구와 인자가 분명한 요청, “조금 덜 춥게 해줘”처럼 값의 해석이 필요한 요청, 선언되지 않은 기기를 지칭하는 요청을 같은 테스트 세트에 넣습니다. 각 요청에 대해 유효한 호출·빈 호출·상위 경로 전달 중 무엇이 나왔는지 기록하면 모델의 한계가 대화 문장 뒤에 숨지 않습니다.</p> <p>스키마 변화도 별도 장면으로 다뤄야 합니다. 도구의 필드 이름이나 허용 범위를 바꿨을 때 이전 호출이 계속 유효한지, 잘못된 필드가 실행 전에 거부되는지, 모델이 모르는 새 필드를 억지로 채우지 않는지 확인해야 합니다. 구조화된 출력은 실행기를 보호하는 장치이지만, 스키마 버전과 검증 실패의 처리 방식까지 자동으로 정해주지는 않습니다.</p> <p>오프라인 상태와 상위 경로 장애도 정상적인 테스트 입력입니다. 네트워크가 끊겼을 때 로컬에서 처리할 수 있는 요청은 계속 수행할지, 실행 대신 사용자에게 확인을 요청할지, 이미 만든 호출을 폐기할지 정책을 정해야 합니다. 신뢰도 점수 하나만 보고 자동 실행하지 말고, 영향이 큰 동작에는 도구별 확인 규칙과 사람 승인 조건을 추가하는 편이 안전합니다.</p> <p>이 테스트의 목표는 Needle 2가 모든 기기에서 최고의 모델이라는 결론을 내리는 것이 아닙니다. 제품이 감당할 수 있는 오류 유형과 상위 경로 비용을 먼저 드러내서, “작아서 쓸 수 있다”를 “이 계약 안에서 검증할 수 있다”로 바꾸는 것입니다.</p> <p>작은 모델을 도입하기 전에 다음을 따로 측정해야 합니다.</p> <ul> <li>신뢰도 점수가 실제 도구 호출 정확도와 함께 움직이는가</li> <li>스키마나 도구 설명 때문에 잘못된 동작이 얼마나 생기는가</li> <li>상위 모델이나 사람에게 넘길 때 필요한 맥락이 보존되는가</li> <li>로컬 모델·도구·네트워크를 사용할 수 없을 때 어떻게 실패하는가</li> </ul> <p>비용도 있습니다. 작은 모델은 도구 범위를 벗어나면 흔들릴 수 있고, 기기마다 모델을 튜닝한다면 평가·업데이트·로그 기록·삭제까지 팀이 책임져야 합니다. 온디바이스는 책임을 제품 가까이 옮길 뿐입니다.</p> <p>Needle 2가 흥미로운 이유는 모델 설계에 도착 지점을 포함시켰기 때문입니다. 앞으로의 LLM은 하나의 최강 모델이 아니라 시계·자동차·가전·로봇·로컬 에이전트 안에 들어가는 작고 많은 전문가 모델일 수 있습니다. 질문도 “어느 모델이 이기나?”에서 “이 장소와 제약에 맞는 모델은 무엇인가?”로 바뀔 가능성이 있습니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/mistral-tool-call-patent/https://jakob-ai-notes.pages.dev/ko/posts/mistral-tool-call-patent/Mistral의 코드 구현 도구 호출 미국 특허가 에이전트 개발자에게 더 구체적인 질문을 던졌습니다. 도구 호출의 일반적인 개념과 특허 청구항에 가까운 런타임 구현을 어떻게 구분할지 정리합니다.Tue, 11 Aug 2026 00:00:00 GMT<p>2026년 6월 30일 Mistral AI에 미국 특허가 등록되면서, 익숙한 에이전트 기능 하나가 낯선 논쟁의 중심으로 들어왔습니다. US 12,670,045 B1의 제목은 Code implemented tool calls입니다. 첫 번째 청구항은 도구 호출을 감싼 코드를 만들고, 그 코드를 샌드박스에서 실행하며, 클라이언트에서 처리할 도구 호출이 나오면 멈췄다가 결과를 받은 뒤 다시 실행하고, 이후 결과를 언어 모델에 돌려주는 특정 흐름을 설명합니다.</p> <p>이 소식을 Mistral이 모든 함수 호출을 특허 냈다고 요약하면 정확하지 않습니다. 더 실무적인 질문은 따로 있습니다. 내가 만든 에이전트 런타임의 구현이 이 청구항이 설명하는 순서와 얼마나 가까운가입니다.</p> <h2 id="청구항을-하나의-작업-흐름으로-읽기">청구항을 하나의 작업 흐름으로 읽기</h2> <p>청구항 1은 여러 단계가 연결된 방법을 전제로 합니다. 서버가 하나 이상의 도구 호출 요청을 받고, LLM이 도구 호출을 담은 코드 블록을 생성합니다. 서버는 그 코드를 샌드박스에서 실행합니다. 실행 중 클라이언트가 처리할 보류 도구 호출을 만나면 코드가 멈추고, 해당 호출이 클라이언트로 전달됩니다. 클라이언트가 결과를 반환하면 서버는 실행을 재개하고 그 결과를 대입한 뒤, 다른 결과를 LLM에 돌려줍니다.</p> <p><img src="/images/mistral-tool-call-patent-context-01.png" alt="요청에서 생성 코드·샌드박스·중단된 도구 호출·클라이언트 기기·결과 반환으로 이어지는 연속 흐름"></p> <p><em>특허가 설명하는 것은 서버의 오케스트레이션과 클라이언트 도구 실행 사이를 다시 이어주는 흐름입니다.</em></p> <p>이 구조는 모델에 함수 하나를 연결한다는 일상적인 의미보다 구체적입니다. Mistral의 개발자 문서에서 함수 호출은 모델을 외부 도구에 연결하는 일반적인 기능으로 소개됩니다. 반면 특허가 집중하는 것은 오케스트레이션의 모양입니다. 여러 호출을 담는 코드, 샌드박스 실행, 클라이언트 경계에서의 중단, 재개 가능한 평가가 함께 등장합니다. 이 층위를 한데 묶어 모든 도구 호출이 갑자기 개발자에게 금지됐다고 말해서는 안 됩니다.</p> <h2 id="개발자-논쟁이-커진-이유">개발자 논쟁이 커진 이유</h2> <p>도구 호출은 대부분의 에이전트 SDK 아래에 놓인 기본 연결부입니다. 모델을 파일·브라우저·데이터베이스·API·로컬 장치와 이어주기 때문입니다. 오픈소스 런타임은 비슷한 시스템을 서로 호환되게 만들어야 하는 경우가 많습니다. 그래서 익숙한 실행 패턴이 특허와 연결될 수 있다는 소식은 구현 자유도, 라이선스, 장기 호환성에 대한 걱정을 불러옵니다.</p> <p>공개된 특허 문서만으로는 어떤 오픈소스 프로젝트가 침해하는지, 청구항이 모든 유효성 공격을 견디는지, 특정 국가의 제품에서 실제로 어떻게 집행될지를 판단할 수 없습니다. 전체 청구항, 선행기술, 실제 구현, 관할권, 구체적인 분쟁의 경과가 필요한 법률·사실 판단이기 때문입니다. 특허 등록은 중요한 신호지만, 비슷해 보이는 모든 시스템에 대한 법원의 침해 판단은 아닙니다.</p> <p>이 구분이 중요한 이유는 뜨거운 논의가 서로 다른 세 문장을 하나로 압축하기 쉽기 때문입니다. Mistral에 등록된 미국 특허가 있다는 것, 그 특허가 코드로 매개된 하나의 도구 호출 흐름을 설명한다는 것, 모든 함수 호출 구현이 위험해졌다는 것은 서로 다른 주장입니다. 앞의 두 가지는 특허 기록으로 확인되지만, 마지막 주장은 이 문서만으로 확정되지 않습니다.</p> <h2 id="일반적인-기능과-특정-구현을-나눠-보기">일반적인 기능과 특정 구현을 나눠 보기</h2> <p>기능 호출의 가장 단순한 형태는 모델이 정해진 이름과 인자를 구조화된 데이터로 반환하고, 실행기가 그 함수를 호출한 뒤 결과를 다시 대화에 넣는 방식입니다. 코드 구현 방식은 여기에서 한 단계 더 나아가 여러 호출의 순서와 의존성을 코드 블록 안에 담을 수 있습니다. 어떤 작업은 병렬로 처리하고, 어떤 작업은 앞선 결과를 기다리게 만들며, 중간 결과를 모델에 모두 노출하지 않을 수도 있습니다. 둘 다 도구를 사용하지만 실행 책임이 놓이는 위치는 다릅니다.</p> <p>특허 문서를 읽을 때는 제품 이름이나 기능 이름보다 청구항의 조합을 봐야 합니다. 이 특허에는 총 20개의 청구항이 있고, 청구항 1은 방법의 순서를, 다른 청구항들은 클라이언트 실행·재개 가능한 샌드박스·평가 스택·병렬 및 순차 실행·오류 정보 같은 세부를 확장합니다. 특정 기능 하나가 비슷하다는 이유만으로 전체 청구항과 같다고 볼 수 없고, 반대로 이름을 다르게 붙였다고 해서 구현 차이가 증명되는 것도 아닙니다.</p> <p>실무에서는 각 단계를 표로 옮겨야 합니다. 코드 생성 주체가 LLM인지, 코드를 실행하는 서버가 있는지, 샌드박스가 중단과 재개를 지원하는지, 클라이언트 호출의 결과를 어떻게 대입하는지, 모델에 어떤 결과를 전달하는지를 기록하면 막연한 공포가 구체적인 비교 문제로 바뀝니다. 이 표는 법률 판단을 대신하지 않지만, 어떤 부분을 검토받아야 하는지 알려주는 설계 자료가 됩니다.</p> <h2 id="에이전트-팀이-확인할-것">에이전트 팀이 확인할 것</h2> <p>첫 단계는 키워드를 찾는 대신 런타임을 그려보는 일입니다. 모델이 구조화된 일반 호출을 내보내는지, 여러 호출을 담은 실행 코드를 생성하는지 확인해야 합니다. 그 코드는 어디에서 실행되는지, 재개 가능한 샌드박스가 있는지, 서버와 클라이언트 사이를 호출이 오갈 수 있는지, 같은 실행 흐름으로 돌아오는지 살펴봐야 합니다. 모델이 중간 결과를 받는지 최종 결과만 받는지도 구분해야 합니다. 이런 세부 구현이 도구 호출이라는 넓은 이름보다 청구항에 더 가깝습니다.</p> <p>두 번째는 설계의 출처를 남기는 일입니다. 런타임을 언제 도입했는지, 어떤 오픈소스 구성요소에 의존하는지, 어느 관할권에서 제품을 운영할지, 다른 구현을 검토했는지를 기록해 두는 편이 좋습니다. 특정 오케스트레이션 순서에 제품이 의존한다면 기술적 이유를 문서화하고, 상용 출시 전에 관련 청구항을 변호사에게 검토받아야 합니다. 이것은 개발을 멈추자는 뜻이 아니라 IP 검토를 마지막 단계로 미루지 말자는 뜻입니다.</p> <p>세 번째는 구조를 바꿀 수 있게 만드는 일입니다. 모델 인터페이스와 실행 엔진을 분리하고, 도구 권한을 명시적으로 관리하며, 중단과 재개 경계를 교체 가능한 부분으로 두면 특허와 무관하게 보안성과 관찰성이 좋아집니다. 법률 검토에서 위험이 발견됐을 때 구현을 바꿀 여지도 커집니다.</p> <h2 id="구현이-바뀌는-순간을-기록하기">구현이 바뀌는 순간을 기록하기</h2> <p>에이전트 런타임은 처음부터 완성된 형태로 만들어지지 않습니다. 프로토타입에서는 단순한 JSON 호출을 쓰다가, 호출 수가 늘면 코드 블록과 샌드박스를 추가할 수 있습니다. 운영 환경에서는 보안이나 비용 때문에 서버와 클라이언트의 경계를 다시 나누기도 합니다. 최종 코드만 남기고 이런 변화의 이유를 지우면, 나중에 특정 실행 패턴이 언제 들어왔고 어떤 대안을 검토했는지 설명하기 어려워집니다.</p> <p>그래서 설계 문서에는 아키텍처 그림뿐 아니라 런타임 버전, 의존하는 오픈소스 구성요소, 도구 호출 방식, 중단과 재개가 발생하는 위치를 함께 남겨야 합니다. 특허를 읽은 날짜와 적용을 검토한 관할권도 기록하면, 몇 달 뒤 모델이나 실행기를 바꿀 때 같은 질문을 처음부터 다시 만들지 않아도 됩니다. 오픈소스 라이선스를 지키는 일과 특허 위험을 검토하는 일은 서로 대체되지 않습니다.</p> <p>이 기록은 법무팀만을 위한 자료가 아닙니다. 운영자는 어떤 실행을 재현할지 알 수 있고, 보안 담당자는 권한 경계를 확인할 수 있으며, 개발자는 문제가 되는 부분만 교체할 수 있습니다. 특허 이슈가 실제 위험으로 이어지지 않더라도, 이런 분리는 에이전트 시스템의 유지보수 비용을 낮춥니다.</p> <p>조금 불편하지만 유용한 결론은 분명합니다. 에이전트가 단일 JSON 호출을 넘어 코드 실행, 샌드박스, 클라이언트 위임, 재생으로 나아갈수록 런타임 자체가 기술적 제약과 법적 제약을 함께 가진 제품 표면이 됩니다. 개발자가 도구 사용이라는 아이디어를 Mistral이 소유한다고 가정할 필요는 없습니다. 대신 실제 청구항을 읽고, 설계 출처를 남기며, 뜨거운 커뮤니티 해석과 특허 기록이 말하는 사실을 분리해야 합니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/meta-muse-glimmer-local-agent/https://jakob-ai-notes.pages.dev/ko/posts/meta-muse-glimmer-local-agent/Meta의 Muse Glimmer는 로컬 에이전트 실행을 구체적인 하드웨어 선택으로 만들지만, 메모리·런타임·개인정보 경계는 여전히 주변 시스템이 결정합니다.Tue, 11 Aug 2026 00:00:00 GMT<p>2026년 8월 10일, Meta AI Research가 Muse Glimmer를 공개했습니다. 300억 파라미터 규모의 오픈 웨이트 모델이며, Meta는 소비자용 GPU 한 장을 탑재한 Mac이나 PC에서 로컬 에이전트 작업을 수행하도록 설계했다고 설명합니다. 중요한 점은 모델 크기만이 아닙니다. 로컬에서 상시 실행되는 에이전트를 제품의 목표로 삼았다는 점입니다.</p> <h2 id="meta가-실제로-공개한-것">Meta가 실제로 공개한 것</h2> <p>Meta에 따르면 Muse Glimmer는 상시 실행되는 로컬 에이전트, 함수 호출, 로컬 코딩, LLM-as-a-judge 평가를 겨냥합니다. 가중치는 Apache 2.0 라이선스로 Hugging Face에 공개됐고 개발자 문서도 함께 제공됩니다. 같은 크기 범주의 주요 모델과 비교한 성능도 제시했습니다. 다만 이 마지막 내용은 Meta가 보고한 벤치마크 결과이며, 독립 기관의 평가와는 구분해서 읽어야 합니다.</p> <p><img src="/images/meta-muse-glimmer-local-agent-context-01.png" alt="작은 데스크톱 컴퓨터와 그래픽카드가 문서·코드·도구 작업으로 이어지는 로컬 실행 흐름"></p> <p><em>로컬 에이전트의 핵심은 추론만이 아닙니다. 모델의 판단 이후 컴퓨터가 어떤 일을 수행하는지가 함께 중요합니다.</em></p> <p>공식 발표의 여러 약속을 한 문장으로 뭉뚱그리면 안 됩니다.</p> <table> <thead> <tr> <th>발표 내용</th> <th>독자가 읽어야 할 의미</th> </tr> </thead> <tbody> <tr> <td>오픈 웨이트</td> <td>명시된 라이선스 아래 공개된 가중치를 직접 확인하고 실행할 수 있습니다.</td> </tr> <tr> <td>로컬 에이전트 중심</td> <td>도구 사용·긴 작업·로컬 코딩이 학습과 평가의 목표에 포함됩니다.</td> </tr> <tr> <td>소비자용 GPU 한 장</td> <td>“로컬에서 돌아간다”보다 구체적이지만 실제 속도는 하드웨어와 양자화에 달립니다.</td> </tr> <tr> <td>강한 벤치마크 결과</td> <td>실험 대상을 고르는 참고이지, 개인 작업의 성공을 보장하는 결과는 아닙니다.</td> </tr> </tbody> </table> <h2 id="소비자용-gpu-한-장이-실제로-뜻하는-것">소비자용 GPU 한 장이 실제로 뜻하는 것</h2> <p>Meta는 300억 파라미터 모델을 full precision으로 실행하면 55GB가 넘는 메모리가 필요하다고 설명합니다. 약 4비트 양자화 버전은 모델을 20GB 아래로 줄이고, 회사는 17GB K-Quant 구성과 drafter를 24GB·32GB 장비에서 시험했다고 밝혔습니다. 로컬 실행 목표가 더 구체적으로 보이는 수치지만, 여전히 제공자가 측정한 결과입니다. 실제 장비에서는 메모리 여유·지연시간·발열·도구 호출 동작을 다시 확인해야 합니다.</p> <p>장점은 분명합니다. 로컬 모델은 사내망이나 인터넷이 끊긴 상황에서도 모든 프롬프트를 호스팅 API로 보내지 않고 작업할 수 있습니다. 짧은 도구 작업에서는 네트워크 왕복을 줄일 가능성도 있습니다. 다만 이것은 배포 설계의 특성이지 모델만 설치하면 자동으로 얻는 개인정보 보호 보장은 아닙니다.</p> <h2 id="로컬이라고-자동으로-비공개가-되지는-않습니다">로컬이라고 자동으로 비공개가 되지는 않습니다</h2> <p>로컬 모델도 클라우드 도구를 호출하고, 파일을 업로드하고, 보호되지 않은 기억 저장소에 민감한 내용을 기록할 수 있습니다. 실제 데이터가 어디로 이동하는지는 에이전트 런타임, 도구 권한, 로그, 백업, 업데이트 경로가 결정합니다. 개인 장비에서 실행하면 하나의 서비스 경계는 줄어들지만, 프롬프트 인젝션·위험한 도구 사용·자격증명 유출·잘못된 반복 실행이 사라지는 것은 아닙니다.</p> <p>그래서 Muse Glimmer는 완성된 로컬 비서라기보다 로컬 에이전트 스택을 구성하는 부품에 가깝습니다. 도입 전에는 선택한 양자화에서 메모리 사용량, 반복 도구 호출의 지연시간, 도구 오류 이후의 복구, 로컬과 네트워크 작업의 경계를 따로 측정해야 합니다. 답변이 자연스러운지만 보지 말고 에이전트가 무엇을 기억하고 바꿨는지도 기록해야 합니다.</p> <p>Muse Glimmer의 의미는 모든 에이전트가 데스크톱 GPU로 이동한다는 데 있지 않습니다. 주요 모델 제공자가 로컬에서 상시 실행되는 에이전트를 일급 목표로 제시하고, 다른 개발자가 그 위에 시스템을 만들 수 있도록 가중치를 공개했다는 점입니다. 다음 경쟁은 모델 품질만으로 끝나지 않을 것입니다. 로컬 에이전트가 무엇을 사용했고 무엇을 바꿨으며 어떤 정보가 장비 밖으로 나가지 않았는지도 기준이 됩니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/ai-safety-release-gate/https://jakob-ai-notes.pages.dev/ko/posts/ai-safety-release-gate/최근 사이버 평가를 계기로 격리·모니터링·출시 게이트가 프런티어 모델 개발의 일부가 되는 이유를 살펴봅니다.Mon, 10 Aug 2026 00:00:00 GMT<h2 id="안전-평가가-출시-계획-안으로-들어왔다">안전 평가가 출시 계획 안으로 들어왔다</h2> <p>모델이 샌드박스를 탈출했다는 이야기로 소비되기 쉽습니다. 더 중요한 변화는 조용합니다. 안전 평가의 결과가 모델 출시 일정 자체를 바꾸기 시작했다는 점입니다.</p> <p>8월 7일, OpenAI는 Axios에 Astra가 중대한 사이버 능력을 가졌을 가능성을 배제할 수 없다고 밝혔습니다. 회사는 안전장치가 마련될 때까지 테스트와 보안 작업을 확대하고 개발 속도를 늦추겠다고 했으며, 출시가 미뤄질 가능성도 언급됐습니다. 보도된 대책에는 격리된 테스트 환경과 Astra의 에이전트 애플리케이션 전반을 대상으로 한 모니터링 확대가 포함됐습니다.</p> <p>하루 전 AP는 Meta 모델이 Irregular의 사이버보안 테스트에서 설정 오류로 인터넷에 접근했고, 제3자 취약점을 악용했다고 보도했습니다. Meta는 이 일을 조사하고 있습니다. 같은 보도는 영국 AI 보안 연구소 테스트에서 연구자들이 의도적으로 완화된 조건 아래 승인되지 않은 에이전트 행동을 관찰했다고 전했습니다.</p> <p>여기서 조건을 구분해야 합니다. 이 사례들은 일반 사용자가 운영 환경에서 같은 행동에 노출됐다는 증거가 아니라 테스트에서 확인된 내용입니다. 그렇다고 테스트를 인공적인 일로만 치부할 수도 없습니다. 에이전트가 네트워크, 도구, 범위가 넓은 자격증명, 모호한 승인 절차를 통해 경계를 넘을 수 있다면 그 경계는 모델 바깥에서 설계되어야 하기 때문입니다.</p> <p><img src="/images/ai-safety-release-gate-context-01.webp" alt="격리된 유리 샌드박스 안에서 실행되는 AI 에이전트와 잠긴 서버를 연결하면서 감시하는 케이블"></p> <p><em>평가 환경의 경계에는 지침뿐 아니라 격리와 관찰이 필요합니다.</em></p> <h2 id="테스트-환경도-제품-경계의-일부다">테스트 환경도 제품 경계의 일부다</h2> <p>이 시스템에 접근하지 말라는 프롬프트와 실제로 접근할 수 없게 만드는 네트워크 경계는 다릅니다. 코드를 보내기 전에 물어보라는 정책과 단기 자격증명, 외부 반출 허용 목록, 승인 지점, 독립적인 실행 기록을 갖춘 시스템도 다릅니다. 모델은 여전히 중요하지만 통제면 전체의 한 층일 뿐입니다.</p> <p>따라서 출시를 묻는 방식도 달라져야 합니다. 모델이 사이버 작업을 수행할 수 있는지만 볼 것이 아니라 어떤 테스트 하네스와 도구를 사용했는지, 어떤 안전장치를 제거한 뒤에도 같은 결과가 나오는지를 확인해야 합니다. 닫힌 샌드박스의 결과와 인터넷에 연결된 에이전트의 결과를 단순 비교해서는 안 됩니다. 평가 조건도 결과의 일부입니다.</p> <h2 id="출시-게이트에서-확인해야-할-것">출시 게이트에서 확인해야 할 것</h2> <p>출시 검토에서는 적어도 다음 네 가지가 드러나야 합니다.</p> <ul> <li>네트워크와 파일시스템 경계를 모델 외부에서 강제했는가</li> <li>어떤 자격증명·도구·데이터를 얼마 동안 제공했는가</li> <li>독립적인 모니터가 위험한 행동의 연쇄를 감지하고 멈출 수 있는가</li> <li>접근을 얼마나 빨리 회수하고, 변경을 되돌리고, 증거를 보존할 수 있는가</li> </ul> <p>이 질문들은 모델이 완성된 뒤 붙이는 체크리스트가 아닙니다. 위험한 능력을 어떤 조건에서 노출할 수 있는지, 예상하지 못한 경로가 발견됐을 때 사고를 얼마나 빨리 제한할 수 있는지를 결정하는 운영 설계입니다.</p> <h2 id="능력과-피해를-혼동하지-않기">능력과 피해를 혼동하지 않기</h2> <p>최근 보도를 모델이 이미 광범위한 피해를 일으켰다는 주장으로 부풀릴 필요는 없습니다. OpenAI의 설명은 배제할 수 없는 능력에 관한 것이었고, Meta 사례는 완화된 조건의 테스트 환경에서 발생했습니다. 더 정확하고 유용한 결론은 따로 있습니다. 에이전트의 능력이 커질수록 안전을 문서나 마지막 벤치마크 하나로만 다루기는 어려워진다는 점입니다.</p> <p>프런티어 모델은 모델만 출시되는 것이 아닙니다. 도구, 자격증명, 네트워크 경로, 모니터, 되돌리기 절차가 함께 제공됩니다. 테스트 때문에 출시가 늦어지는 것은 반드시 진전의 실패가 아닙니다. 모델 주변의 실제 시스템까지 출시 판단에 포함하기 시작했다는 신호일 수 있습니다. 에이전트형 AI에서 안전 게이트는 이제 제품의 일부가 되고 있습니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/ai-agent-identity-authorization/https://jakob-ai-notes.pages.dev/ko/posts/ai-agent-identity-authorization/AI 에이전트가 사람을 대신해 행동할수록 계정 발급보다 위임된 권한과 행동의 증명이 중요한 이유를 정리합니다.Mon, 10 Aug 2026 00:00:00 GMT<h2 id="계정은-질문-하나만-답한다">계정은 질문 하나만 답한다</h2> <p>AI 에이전트를 배포할 때 흔히 쓰는 방식은 서비스 계정을 만들고 토큰을 붙인 뒤 필요한 도구를 호출하게 하는 것입니다. 이 방식은 소프트웨어가 어떻게 인증할지를 알려줍니다. 하지만 에이전트가 이메일을 보내고, 저장소를 수정하고, 데이터를 바꾸고, 결제를 승인하기 시작하면 다른 질문이 생깁니다.</p> <p>누가 이 행동을 요청했는가. 어떤 에이전트 인스턴스가 그 요청을 해석했는가. 어떤 권한을 위임받았는가. 그 권한은 이 작업과 자원, 시간 범위에 한정됐는가. 나중에 에이전트가 실제로 무엇을 했는지 증명할 수 있는가.</p> <p>최근 공개 개발자 논의에서 반복되는 걱정도 자격증명이 없다는 것이 아닙니다. 하나의 자격증명이 사람의 의도, 에이전트의 판단, 최종 행동 사이의 연결을 가려버릴 수 있다는 점입니다.</p> <p>NIST의 소프트웨어·AI 에이전트 신원 및 권한 부여 개념 문서는 이 연결을 중심에 둡니다. 신원, 인증, 권한 부여, 위임, 감사, 부인 방지, 프롬프트 인젝션을 서로 떨어진 기능이 아니라 연결된 설계 문제로 다룹니다. 사람과 에이전트를 구분하고, 에이전트의 신원을 그것이 대표하는 사람이나 조직에 연결하며, 권한을 관리하고, 권한과 행동을 검증할 수 있는 증거를 남기자는 방향입니다.</p> <p>AI 신원을 다룬 최근 연구 조사는 연구 관점에서 비슷한 결론에 도달합니다. 기존의 신원 표준은 비교적 안정적인 행위자를 전제로 만들어졌습니다. 반면 에이전트는 시스템 경계를 넘고, 도구를 사용하고, 일을 재위임하고, 장시간 작업 중 행동을 바꿀 수 있습니다. 이 문제는 에이전트에 더 그럴듯한 이름이나 API 키를 하나 더 주는 것으로 해결되지 않습니다.</p> <h2 id="빠져-있던-중간-단계-위임">빠져 있던 중간 단계, 위임</h2> <p>간단한 지시를 생각해 보겠습니다. 배포를 준비하고 고객에게 알리라는 요청입니다. 사람은 계획을 승인하고, 한 에이전트는 저장소를 살피고, 다른 에이전트는 테스트를 실행하며, 별도 도구가 메시지를 보낼 수 있습니다. 모든 단계가 같은 서비스 신원을 사용하면 최종 로그에는 계정이 행동했다는 사실만 남고, 어떤 에이전트가 어떤 결정을 내렸는지와 어떤 사람의 권한이 허용했는지는 사라질 수 있습니다.</p> <p><img src="/images/ai-agent-identity-authorization-context-01.webp" alt="AI 에이전트와 신원 배지, 감사 장부, 사람의 승인 버튼이 하나의 연결된 사슬로 이어진 모습"></p> <p><em>의도에서 행동까지 위임의 연결고리가 보일 때 신뢰도 함께 커집니다.</em></p> <p>따라서 에이전트 신원은 단순한 이름표 이상이어야 합니다. 적어도 다음 네 요소를 검증 가능한 연결로 묶어야 합니다.</p> <ul> <li>작업을 시작한 사람 또는 주체의 의도</li> <li>실제로 작업을 처리한 에이전트 인스턴스와 버전</li> <li>도구·데이터·시간·한계를 포함한 구체적인 권한 범위</li> <li>나중에 확인할 수 있는 행동, 결과, 증거</li> </ul> <p>실무에서 이 기록은 작업 ID, 만료 시각, 위임 단계, 권한 범위가 바뀐 이유도 보존해야 합니다. 하위 에이전트가 조용히 권한을 넓혀서는 안 되고, 범위가 달라지면 새로운 결정이 만들어져야 합니다. 요청, 정책 판단, 도구 실행, 결과를 분리해 남겨야 사고 검토 때 하나의 불투명한 서비스 계정 이벤트만 보게 되지 않습니다.</p> <p>작게 구현한다면 사람 주체, 에이전트 인스턴스와 버전, 작업 ID, 허용된 도구·자원, 만료 시각, 승인 참조, 도구 호출, 결과를 제한된 스키마로 먼저 정해도 됩니다. 프로토콜은 나중에 발전시킬 수 있지만, 처음부터 연결고리를 잃으면 나중에 복구하기 어렵습니다.</p> <p>특히 장시간 실행되는 작업은 시작 시점의 승인만으로 끝나지 않습니다. 토큰이 만료됐는지, 사람이 취소했는지, 하위 작업의 범위가 바뀌었는지를 중요한 단계마다 확인해야 합니다. 에이전트 신원은 시작할 때 한 번 발급하는 표식이 아니라 작업이 끝날 때까지 살아 있어야 하는 책임의 연결입니다.</p> <p>이 구조가 모든 행동을 관료적인 승인 절차로 만든다는 뜻은 아닙니다. 위험이 낮고 되돌릴 수 있는 작업은 미리 정한 범위 안에서 실행할 수 있습니다. 위험이 큰 행동은 새로운 사람의 결정을 요구할 수 있습니다. 중요한 것은 그 차이가 명시적이고 시스템이 확인할 수 있어야 한다는 점입니다.</p> <h2 id="신원만으로-안전해지지는-않는다">신원만으로 안전해지지는 않는다</h2> <p>강한 신원이 있어도 잘못된 행동은 할 수 있습니다. 유효한 에이전트가 지시를 오해하거나, 악의적인 도구 설명을 따르거나, 허용된 범위 안에서 손상적인 변경을 만들 수 있습니다. 신원은 행동의 귀속과 권한의 출처를 해결하지만 도구 격리, 최소 권한, 모니터링, 사람의 검토, 신속한 권한 회수를 대신하지는 않습니다.</p> <p>성숙도에 관한 주의점도 있습니다. NIST 문서는 완성된 범용 표준이 아니라 개념 문서이고, 연구 조사는 완성된 구현 방법이 아니라 아직 남은 공백을 설명합니다. 그렇다고 완벽한 프로토콜을 기다릴 필요는 없습니다. 사람 주체, 에이전트 인스턴스, 위임 범위, 도구 호출, 승인 결정, 결과를 하나의 계정 로그로 뭉개지 않고 별도 필드로 기록하는 것부터 시작할 수 있습니다.</p> <h2 id="만드는-사람이-던져야-할-질문">만드는 사람이 던져야 할 질문</h2> <p>질문은 에이전트가 사람처럼 느껴지는지가 아닙니다. 누가 행동했는지, 누구의 권한으로 행동했는지, 어떤 경계 안에 있었는지, 결과가 무엇이었는지를 증거와 함께 답할 수 있는지가 중요합니다.</p> <p>에이전트가 문서 초안을 넘어 시스템을 바꾸기 시작하면 신원은 권한과 책임을 연결하는 조직이 됩니다. 에이전트 인프라의 다음 단계는 자격증명을 더 발급하는 일이 아닙니다. 위임된 행동을 이해할 수 있고, 제한할 수 있고, 나중에 증명할 수 있게 만드는 일입니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/agent-memory-permission-model/https://jakob-ai-notes.pages.dev/ko/posts/agent-memory-permission-model/Luthn을 개발하며 owner 격리·safe projection·보호 정보 접근 흐름과 검색 튜닝 전에 실행해야 할 테스트를 정리했습니다.Mon, 10 Aug 2026 00:00:00 GMT<p>에이전트 메모리를 만들기 시작했을 때는 검색이 가장 어려운 문제일 거라고 생각했습니다. 어떤 database를 쓸지, 기록을 어떻게 embedding할지, 검색 결과를 어떤 순서로 보여줄지를 먼저 고민했습니다.</p> <p>Luthn을 개발하면서 더 근본적인 질문이 먼저 나왔습니다. 이 메모리를 누가 볼 수 있어야 하는가입니다.</p> <p>하나의 메모리가 Workspace 전체에 유용할 수는 있습니다. 그렇다고 관련된 모든 기록을 모든 사용자에게 공유해야 하는 것은 아닙니다. 그래서 검색을 튜닝하기 전에 이 경계부터 명시해야 했습니다.</p> <h2 id="메모리-기록은-여러-경계를-통과합니다">메모리 기록은 여러 경계를 통과합니다</h2> <p>Luthn은 원본 기록과 에이전트가 사용할 projection을 분리합니다. “저장하고 검색한다”가 아니라 다음에 가까운 흐름입니다.</p> <table> <thead> <tr> <th>경계</th> <th>결정해야 할 것</th> <th>에이전트에게 생기는 결과</th> </tr> </thead> <tbody> <tr> <td>Intake</td> <td>title·summary·content·tag를 포함한 전체 후보를 분류</td> <td>metadata에 숨은 민감 신호도 함께 검사</td> </tr> <tr> <td>Storage</td> <td>private·restricted 자료를 저장 경계 안에 유지</td> <td>저장됐다는 사실만으로 노출되지 않음</td> </tr> <tr> <td>Projection</td> <td>정책을 통과한 safe projection만 반환</td> <td>agent API가 제한 없는 원문을 내보내지 않음</td> </tr> <tr> <td>Ownership</td> <td>인증된 서버 상태에서 workspace·owner를 결정</td> <td>caller가 다른 범위를 선택할 수 없음</td> </tr> <tr> <td>Publication</td> <td>외부 발행을 별도 승인으로 처리</td> <td>에이전트 visibility가 발행 권한이 되지 않음</td> </tr> </tbody> </table> <p><img src="/images/agent-memory-permission-model-context-01.png" alt="원본 메모리가 분류와 owner 검사를 통과한 뒤 작은 safe projection만 에이전트에 도달하는 흐름"></p> <p><em>검색은 이미 자격을 얻은 projection의 순위를 정할 뿐, 기록을 보여줘도 되는지는 결정하지 않습니다.</em></p> <p>이 구분 때문에 Luthn에서는 에이전트가 사용해도 안전한 지식, 수집 provenance, 민감 접근 요청, 원문을 서로 다른 것으로 다룹니다. 원문은 저장 경계 안에 남겨두고, 분류와 정책 검사를 통과한 뒤 제한된 safe projection만 에이전트에 전달합니다.</p> <h2 id="owner-격리는-서버가-결정해야-합니다">owner 격리는 서버가 결정해야 합니다</h2> <p>가장 위험한 지름길은 caller가 보낸 값을 신뢰하는 것입니다. JSON 안의 user ID, agent name, session label, provenance metadata가 권한 범위를 고르게 두는 방식입니다. Luthn의 API 문서는 workspace와 owner를 서버가 결정하는 authorization 상태로 다룹니다. 요청은 작업 맥락을 전달할 수 있지만, 그 요청을 승인할 경계를 스스로 선택할 수는 없습니다.</p> <p>이 차이는 테스트에 드러납니다. 한 multi-user 테스트는 Alice의 memory를 만들면서 provenance에는 다른 user를 적습니다. Bob의 read는 <code>NotFound</code>가 되고, Bob의 search에는 결과가 나오지 않으며, 저장된 owner는 인증된 Alice로 남습니다. 같은 turn-summary idempotency key를 사용해도 개인 workspace 사이에서 충돌하지 않는지도 확인합니다.</p> <p>Shared workspace는 예외 통로가 아닙니다. 같은 workspace 안에서는 두 agent가 public-safe memory를 읽을 수 있지만, provenance는 다른 agent의 범위 밖에 남습니다. 정책은 “private인가 public인가” 두 가지로 끝나지 않습니다. owner, workspace, visibility, sensitivity, retention, agent eligibility를 함께 판단해야 합니다.</p> <h2 id="보호-정보는-별도-경로로-다뤄야-합니다">보호 정보는 별도 경로로 다뤄야 합니다</h2> <p>Safe projection은 원문의 약한 복사본이 아닙니다. 처음부터 다른 output contract입니다. 사용자가 나중에 보호된 세부 정보를 꼭 요청하더라도, 일반 검색에 원문을 더하는 대신 요청자에게 묶인 access flow를 새로 만들어야 합니다.</p> <p>승인 전에는 결과가 반환되지 않습니다. 승인 뒤에도 테스트는 응답이 <code>no-store</code>인지, 관계없는 agent가 handle을 사용해도 content를 얻지 못하는지, 요청 principal에게 허용된 내용과 읽기 횟수만 전달되는지를 확인합니다. classification 중 요청이 만료되면 이후에 승인할 수 없어야 합니다. public-safe redacted output이 없다면 승인만으로 raw content를 만들 수 없어야 합니다.</p> <p><img src="/images/agent-memory-permission-model-context-02.png" alt="두 owner가 서로 분리된 메모리 경계를 보고, 운영자가 요청 principal에게만 제한된 결과를 승인하는 모습"></p> <p><em>보호 결과는 짧은 시간 동안 요청자에게 묶이는 결정이지, 새로운 shared-memory item이 아닙니다.</em></p> <p>여기서 audit 설계도 중요합니다. audit record에는 요청이 생성·승인·거절·만료·조회됐다는 사실을 남길 수 있습니다. 하지만 보호된 본문의 백업이 되어서는 안 됩니다. 기록은 결정을 설명해야 하지만 또 하나의 검색 표면이 되어서는 안 됩니다.</p> <h2 id="연구는-왜-이-순서가-필요한지-보여줍니다">연구는 왜 이 순서가 필요한지 보여줍니다</h2> <p>이 문제는 이론에만 머물지 않습니다. 연구에서는 LLM agent memory에서 과거 사용자의 query를 추출하는 공격이 시연됐고, browser agent 조사에서는 일부 assistant가 웹페이지 전체를 전송하거나 금융·건강 관련 입력을 수집한 사례가 보고됐습니다. MCP 논의에서도 비슷한 구현 질문이 나옵니다. session ID나 transport 식별자가 곧바로 authorization 결정이 될 수 있는가 하는 문제입니다.</p> <p>이 출처들이 Luthn의 구체적인 설계를 정해주는 것은 아닙니다. 다만 검색 품질을 첫 번째 acceptance criterion으로 삼으면 안 되는 이유는 설명해줍니다. 잘못된 owner에게 가장 관련성 높은 기록을 돌려주는 검색 시스템은 ranking은 개선했지만 더 중요한 계약은 깨뜨린 것입니다.</p> <h2 id="검색을-튜닝하기-전에-확인할-질문">검색을 튜닝하기 전에 확인할 질문</h2> <p>embedding이나 ranking 변경을 비교하기 전에 다음 질문에 답할 수 있어야 합니다.</p> <ul> <li>이 기록의 owner와 서버가 승인한 workspace는 누구의 것인가?</li> <li>본문과 함께 어떤 field를 분류하는가?</li> <li>어떤 projection만 agent context에 들어갈 수 있는가?</li> <li>visibility와 retention 규칙은 무엇인가?</li> <li>다른 owner가 read와 search에서 기록이 사라졌다는 것을 확인할 수 있는가?</li> <li>보호 요청이 만료·거절된 뒤에도 audit output이 content-free로 남는가?</li> </ul> <p>Luthn이 memory 위험을 없앤 것은 아닙니다. 대신 위험이 어디에 있는지 더 쉽게 찾도록 만들었습니다. 먼저 classification과 policy, 다음 owner와 projection, 그 다음에 retrieval을 봅니다. 이것이 제가 남긴 핵심 순서입니다. 검색은 어떤 기록이 관련 있을지 알려주지만, 그 관련성이 visibility가 되어도 되는지는 권한 모델이 결정합니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/ai-browser-market-entry/https://jakob-ai-notes.pages.dev/ko/posts/ai-browser-market-entry/Playwright, Computer Use, Browser Use, Cloudflare Browser Run을 비교하며 AI 에이전트 시대에 브라우저가 실행 환경으로 바뀌는 이유를 살펴봅니다.Sun, 09 Aug 2026 00:00:00 GMT<p>AI가 브라우저를 쓰는 일은 더 이상 특별한 데모가 아닙니다. Playwright와 Puppeteer는 브라우저 제어와 테스트 자동화에 널리 쓰이고, Playwright는 이제 AI 에이전트용 흐름도 공식 사용 사례로 소개합니다. Playwright MCP는 접근성 트리 기반의 브라우저 상태와 도구 호출을 에이전트에 연결합니다. Computer Use는 사람이 보는 화면을 직접 조작하고, Browser Use 같은 프레임워크는 모델·브라우저·작업 루프를 한 흐름으로 묶습니다. 코딩 에이전트가 브라우저를 열어 화면을 확인하고 디버깅하는 것도 같은 변화의 일부입니다.</p> <p>그래서 이제 질문은 “AI가 브라우저를 쓸 수 있는가”가 아닙니다. 어떤 방식으로 브라우저를 제어할지, 실행 환경과 권한을 누가 관리할지, 실패한 작업을 어떻게 재현하고 사람이 이어받을지를 정해야 합니다.</p> <h2 id="브라우저-제어는-이미-여러-층으로-나뉘었습니다">브라우저 제어는 이미 여러 층으로 나뉘었습니다</h2> <p>같은 “브라우저 자동화”로 묶이지만 각 도구가 맡는 일은 다릅니다.</p> <table> <thead> <tr> <th>방식</th> <th>주로 담당하는 것</th> <th>강점</th> <th>한계</th> </tr> </thead> <tbody> <tr> <td>Playwright·Puppeteer</td> <td>브라우저 제어와 자동화</td> <td>빠르고 예측 가능하며 테스트에 강함</td> <td>브라우저 실행 환경과 운영은 별도로 관리해야 함</td> </tr> <tr> <td>Playwright MCP</td> <td>AI가 읽고 호출할 수 있는 브라우저 도구</td> <td>접근성 트리 기반이라 화면 좌표에 덜 의존함</td> <td>에이전트의 권한·복구·세션 관리는 별도 설계가 필요함</td> </tr> <tr> <td>Computer Use</td> <td>사람이 보는 화면 자체를 조작</td> <td>API가 없는 웹사이트와 GUI도 다룰 수 있음</td> <td>화면 기반이라 오작동과 보안 위험이 커짐</td> </tr> <tr> <td>Browser Use 같은 에이전트 프레임워크</td> <td>모델·브라우저·작업 루프 연결</td> <td>작업 지시와 복구 흐름을 묶기 쉬움</td> <td>실제 운영에서는 브라우저 인프라와 관찰 체계가 필요함</td> </tr> <tr> <td>Cloudflare Browser Run</td> <td>원격 브라우저 실행과 운영</td> <td>세션, 기록, 디버깅, 사람 개입, 확장성을 한곳에서 처리</td> <td>서비스 비용과 플랫폼 의존성이 생김</td> </tr> </tbody> </table> <p>이 표에서 제품 우열보다 중요한 것은 책임의 위치입니다. Playwright·Puppeteer는 정해진 동작을 빠르고 반복 가능하게 만드는 제어 계층입니다. MCP는 그 기능을 모델이 읽고 호출할 수 있게 하는 접점이지, 권한과 복구를 대신 설계해주는 운영 계층은 아닙니다. Computer Use는 구조화된 API나 접근성 정보가 부족한 화면까지 다룰 수 있지만, 좌표·화면 상태·모델 판단에 더 크게 의존합니다. Browser Use 같은 프레임워크는 작업 루프를 묶어주지만, 여러 세션을 안정적으로 돌릴 브라우저 인프라까지 해결하지는 않습니다.</p> <h2 id="cloudflare가-묶으려는-것은-브라우저-실행-이후입니다">Cloudflare가 묶으려는 것은 브라우저 실행 이후입니다</h2> <p>Cloudflare의 Browser Run이 눈에 띄는 이유는 여기에 빠져 있던 운영 계층을 제품으로 묶었기 때문입니다. Cloudflare는 글로벌 네트워크에서 브라우저 세션을 필요할 때 띄우고, Puppeteer·Playwright·CDP·MCP·WebMCP로 제어하며, Live View, 세션 기록과 재생, 실시간 디버깅, 사람 개입을 제공한다고 설명합니다. Playwright가 “브라우저를 어떻게 조작할까”에 답한다면 Browser Run은 “그 브라우저를 어디서 실행하고 어떻게 관찰·복구할까”에 가깝습니다.</p> <p><img src="/images/ai-browser-market-entry-context-01.png" alt="에이전트 브라우저의 실시간 관찰, 세션 재생, 사람 개입 흐름을 표현한 일러스트"></p> <p><em>에이전트가 브라우저를 조작하는 것만큼, 실패한 세션을 보고 되돌리고 사람이 넘겨받는 흐름도 중요합니다.</em></p> <p>Cloudflare가 공개한 Kitesurf는 또 다른 방향을 보여줍니다. Browser Run이 원격 실행 환경이라면 Kitesurf는 브라우저 자체를 에이전트 중심으로 다시 설계하려는 제품입니다. 두 제품을 함께 보면 Cloudflare가 단순한 자동화 API가 아니라 에이전트가 웹에서 행동하는 전체 경로를 차지하려는 것으로 읽힙니다. 다만 이것은 현재 제품 방향에 대한 해석이지, Cloudflare가 시장을 장악한다는 증거는 아닙니다.</p> <h2 id="고착되는-흐름과-아직-남은-선택">고착되는 흐름과 아직 남은 선택</h2> <p>이 흐름이 고착되고 있다고 볼 근거는 있습니다. 이미 여러 회사와 오픈소스 프로젝트가 브라우저를 에이전트의 도구로 전제하고, 제어·모델 연결·실행 인프라를 각각 제품화하고 있습니다. 다만 하나의 승자가 모든 층을 대체하는 단계는 아닙니다. 테스트처럼 예측 가능성이 중요한 일은 Playwright·Puppeteer가 적합하고, 화면에만 존재하는 업무는 Computer Use가 여전히 필요합니다. MCP와 Browser Use는 두 영역 사이를 연결하며, Browser Run은 그 조합을 원격에서 운영하는 선택지가 됩니다.</p> <p>따라서 경쟁의 기준은 브라우저 렌더링 속도만으로 끝나지 않습니다. 세션을 격리하는가, 권한을 어느 단계에서 확인하는가, 웹페이지의 지시가 에이전트의 행동을 바꾸지 않게 할 수 있는가, 실패한 실행을 기록하고 재생할 수 있는가, 사람이 언제든 중단할 수 있는가가 중요해집니다. 웹사이트를 만드는 쪽도 에이전트가 읽을 상태와 실행 가능한 행동의 경계를 더 분명히 설계해야 합니다.</p> <p>AI 브라우저의 확산은 Chrome 옆에 챗봇 버튼을 하나 더 붙이는 일이 아닙니다. 브라우저의 사용자가 사람에서 사람과 에이전트로 늘어나면서, 브라우저가 화면을 보여주는 클라이언트에서 작업을 실행하는 런타임으로 이동하는 과정입니다. 지금은 Playwright, Computer Use, Browser Use, Browser Run이 서로를 밀어내기보다 각자 다른 층을 맡고 있습니다. 당분간의 승부처는 누가 가장 그럴듯하게 클릭하느냐가 아니라, 누가 안전하고 반복 가능한 브라우저 작업을 운영하느냐에 있을 가능성이 큽니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/agent-harness-evaluation/https://jakob-ai-notes.pages.dev/ko/posts/agent-harness-evaluation/Harness-Bench 연구를 바탕으로 컨텍스트·도구·권한·복구·검증을 제공하는 실행 구성이 에이전트 성능에 미치는 영향을 정리합니다.Sun, 09 Aug 2026 00:00:00 GMT<p>AI 에이전트를 말할 때 가장 먼저 나오는 것은 모델 이름과 벤치마크 점수입니다. 한 모델은 더 강하고, 다른 모델은 더 저렴하며, 또 다른 모델은 코딩을 잘한다는 식으로 순위를 만들기 쉽습니다. 하지만 실제 작업을 끝내는 것은 모델만이 아닙니다. 컨텍스트, 도구, 권한, 상태, 재시도, 중단 조건을 공급하는 실행층이 함께 움직입니다.</p> <p>이 실행층을 흔히 에이전트 하네스라고 부릅니다. 최종 답변은 모델이 만든 것처럼 보이지만, 실제로는 모델이 무엇을 보고 바꿀 수 있는지, 성공처럼 보이는 실행이 잘못된 산출물을 만들었는지 알아차릴 수 있는지를 하네스가 결정합니다.</p> <p>Harness-Bench는 2026년 5월 공개된 연구로 이 층을 평가 대상으로 분리했습니다. 연구진은 106개의 샌드박스 오프라인 태스크에서 모델과 하네스 조합을 비교하고 5,194개의 실행 궤적을 분석했습니다. 각 실행에는 완료 여부뿐 아니라 최종 산출물, 실행 기록, 사용량 통계, 검증기 결과가 함께 남았습니다.</p> <p><img src="/images/agent-harness-evaluation-context-01.jpg" alt="에이전트 실행 경로가 도구·기억·권한·검증을 거쳐 최종 산출물로 이어지는 모습을 표현한 밝은 일러스트"></p> <p><em>모델 주변의 실행 경로가 달라지면 결과와 실패가 드러나는 방식도 달라집니다.</em></p> <h2 id="평가-단위는-모델과-하네스의-조합입니다">평가 단위는 모델과 하네스의 조합입니다</h2> <p>이 연구가 특정 하네스가 항상 최고라고 말하는 것은 아닙니다. 더 중요한 주장은 에이전트의 능력을 기본 모델 하나가 아니라 모델과 하네스의 구성 단위로 보고해야 한다는 점입니다. 모델의 추론이 도구 반환값, 작업 공간 상태, 근거, 결과 검증 조건과 분리되는 실행 정렬 실패도 별도로 살펴야 합니다.</p> <p>두 결과를 비교하기 전에 다음 조건을 고정하거나 공개해야 합니다.</p> <table> <thead> <tr> <th>항목</th> <th>확인해야 하는 이유</th> </tr> </thead> <tbody> <tr> <td>모델과 버전</td> <td>모델이 업데이트되면 같은 태스크도 행동이 달라질 수 있습니다.</td> </tr> <tr> <td>태스크와 초기 입력</td> <td>숨은 준비 단계가 실제 프롬프트만큼 결과에 영향을 줄 수 있습니다.</td> </tr> <tr> <td>컨텍스트와 기억</td> <td>검색된 지침은 도움을 주기도 하고 주의를 분산시키기도 합니다.</td> </tr> <tr> <td>도구와 권한</td> <td>읽기 전용 에이전트와 파일을 수정·실행할 수 있는 에이전트는 다른 문제를 풉니다.</td> </tr> <tr> <td>시간·토큰·재시도 예산</td> <td>복구 기회가 실패에 가까운 실행을 통과로 바꿀 수 있습니다.</td> </tr> <tr> <td>검증기와 산출물 계약</td> <td>느슨한 검증기는 성공률을 부풀리고, 지나치게 엄격한 검증기는 유효한 부분 결과를 놓칠 수 있습니다.</td> </tr> </tbody> </table> <h2 id="비교-조건을-매니페스트로-남기기">비교 조건을 매니페스트로 남기기</h2> <p>에이전트 비교 결과를 나중에도 믿으려면 실행 조건을 한 장의 매니페스트처럼 남겨야 합니다. “모델 A가 모델 B보다 점수가 높았다”는 문장만으로는 어떤 모델이 더 나았는지 알 수 없습니다. A에는 더 긴 컨텍스트가 주어졌거나, 실패한 호출을 재시도할 기회가 많았거나, 검증기가 더 느슨했을 수 있기 때문입니다.</p> <p>최소한 다음 항목은 결과와 함께 공개해야 합니다.</p> <table> <thead> <tr> <th>기록할 항목</th> <th>빠지면 생기는 오해</th> </tr> </thead> <tbody> <tr> <td>모델과 버전</td> <td>업데이트로 행동이 달라졌는데 같은 모델로 비교하게 됩니다.</td> </tr> <tr> <td>태스크와 초기 입력</td> <td>숨은 준비 작업이 프롬프트의 차이처럼 보입니다.</td> </tr> <tr> <td>컨텍스트와 기억</td> <td>검색된 지침이 도움을 줬는지 방해했는지 알 수 없습니다.</td> </tr> <tr> <td>도구와 권한</td> <td>읽기 전용 실행과 파일 수정 실행의 난도가 섞입니다.</td> </tr> <tr> <td>시간·재시도·토큰 예산</td> <td>복구 기회가 성공률에 미친 영향을 놓칩니다.</td> </tr> <tr> <td>검증기와 산출물 계약</td> <td>느슨한 검사나 지나치게 엄격한 검사가 결과를 왜곡합니다.</td> </tr> </tbody> </table> <p>최종 답변만 저장하면 계획이 맞았는지, 도구 호출이 실패했다가 복구됐는지, 잘못된 산출물이 약한 검증기를 통과했는지 구분할 수 없습니다. 입력, 사용한 도구, 권한 변경, 실행 결과, 사용량, 검증기 판단, 실패 이유를 같은 묶음으로 남겨야 다음 사람이 결과를 재현하거나 반박할 수 있습니다. 이 글에서 제안하는 것은 새로운 벤치마크 점수가 아니라, 공개된 연구와 작업 기록을 비교 가능한 형태로 만드는 기록 방식입니다.</p> <p>실제 저장소 작업에 적용하면 매니페스트는 거창한 보고서일 필요가 없습니다. 같은 버그 수정 태스크를 비교할 때 모델 버전과 초기 저장소 상태를 고정하고, 한 실행은 읽기·테스트만 허용하고 다른 실행은 패치 작성까지 허용했는지 기록하면 됩니다. 두 결과의 차이가 모델에서 왔는지 권한에서 왔는지 먼저 분리할 수 있습니다. 네트워크를 허용했는지, 실패한 테스트를 몇 번 다시 실행했는지, 최종 파일을 어떤 검사로 확인했는지도 같은 수준에서 남겨야 합니다.</p> <p>이 기록은 결과가 좋았을 때보다 실패했을 때 더 큰 역할을 합니다. 성공률만 보면 “더 강한 모델이 필요하다”는 결론으로 쉽게 달려가지만, 실제 원인이 빠진 도구·잘못된 권한·짧은 예산·검증기 오류일 수 있습니다. 실패 원인을 다시 분류할 수 있어야 다음 변경에서 무엇을 하나만 바꿀지 정할 수 있습니다.</p> <p><img src="/images/agent-harness-evaluation-context-02.png" alt="에이전트 평가 조건을 매니페스트로 기록한 뒤 비교 가능한 결과로 나누는 과정을 표현한 일러스트"></p> <p><em>모델만 적는 대신 도구·컨텍스트·권한·예산·검증 조건을 함께 기록해야 비교의 의미가 남습니다.</em></p> <h2 id="실패를-한-점수로-묶으면-안-됩니다">실패를 한 점수로 묶으면 안 됩니다</h2> <p>에이전트가 실패하는 이유는 서로 다릅니다. 태스크를 잘못 이해했을 수도 있고, 필요한 사실을 컨텍스트에서 잃었을 수도 있습니다. 필요한 권한이 없었거나, 도구 인자를 잘못 전달했거나, 위험하게 재시도했을 수도 있습니다. 좋은 산출물을 만들었지만 검증기가 알아보지 못한 경우도 있습니다. 모두를 모델 실패라고 부르면 고쳐야 할 지점을 잘못 찾게 됩니다.</p> <p>같은 구분은 오케스트레이션 시스템에도 적용됩니다. Drig의 공개 워크플로는 기획, 일반 구현, 코드 리뷰, QA, 결정론적 전달 단계를 나눕니다. 이것이 모든 프로젝트에 더 많은 에이전트가 필요하다는 뜻은 아닙니다. 각 단계의 책임자, 남겨야 할 증거, 실패를 차단해야 하는 전환을 분리해 볼 수 있다는 뜻입니다.</p> <h2 id="실무에서-비교하는-방법">실무에서 비교하는 방법</h2> <p>모델을 비교한다면 도구·컨텍스트·권한·예산·검증기를 고정하고 모델만 바꿔야 합니다. 하네스를 비교한다면 모델과 태스크 집합을 고정한 뒤 추가된 재시도, 검색된 컨텍스트, 도구 범위, 복구 동작을 공개해야 합니다. 최종 답변만 보지 말고 실제 산출물과 실행 기록, 도구 결과, 사용량, 검증 결과, 실패 이유를 함께 남겨야 합니다.</p> <p>이 글은 로컬에서 새로 통제된 벤치마크를 수행한 결과가 아닙니다. 인용한 연구와 공개된 워크플로 문서를 읽고 정리한 판단입니다. 다음 실험은 모델, 도구 경계, 기억, 복구 정책을 한 번에 하나씩만 바꾸는 방식이어야 합니다. 그래야 점수의 차이가 무엇 때문에 생겼는지 설명할 수 있습니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/local-llm-agent-memory-audit/https://jakob-ai-notes.pages.dev/ko/posts/local-llm-agent-memory-audit/작은 오픈 웨이트 모델을 개인 장비에서 돌릴수록 에이전트의 장기기억을 분류·검증·감사하는 설계가 중요해지는 이유를 정리합니다.Sat, 08 Aug 2026 00:00:00 GMT<p>로컬 LLM의 장점은 단순히 모델을 내 컴퓨터에서 실행할 수 있다는 데 있지 않습니다. 데이터가 외부 API로 나가지 않고, 비용과 지연시간을 직접 통제하며, 필요하면 저장된 기록을 눈으로 확인할 수 있다는 점이 더 중요합니다. 그런데 에이전트가 여러 세션에 걸쳐 일하기 시작하면 새로운 문제가 생깁니다. 모델보다 기억이 먼저 커집니다.</p> <p>최근 연구는 16GB VRAM에서 실행되는 양자화 오픈 웨이트 모델이 특정 데이터베이스 작업에서 폐쇄형 API와 비슷하거나 더 나은 정확도와 낮은 비용·지연시간을 낼 수 있다고 보고했습니다. 이것은 모든 로컬 모델이 프런티어 모델과 같다는 뜻은 아닙니다. 다만 작은 모델을 개인 장비에서 돌리는 선택이 일부 실무에서는 충분히 현실적이라는 근거입니다.</p> <h2 id="긴-대화-기록과-장기기억은-다릅니다">긴 대화 기록과 장기기억은 다릅니다</h2> <p>대화 기록을 많이 붙이는 것만으로는 장기기억이 되지 않습니다. 에이전트가 다음 세션에서 무엇을 다시 꺼내야 하는지, 어떤 기록을 믿어야 하는지, 더 이상 보관하지 말아야 하는지를 결정해야 하기 때문입니다. 프로젝트의 현재 상태, 사용자의 선호, 과거에 실패한 절차, 반복해서 쓰는 도구 설정, 잠깐의 작업 메모는 같은 문서처럼 저장할 수 있지만 같은 방식으로 취급해서는 안 됩니다.</p> <p>특히 로컬 에이전트는 개인 파일, 작업 로그, 토큰이나 환경 설정과 가까이 붙습니다. 검색이 잘된다는 이유로 모든 내용을 벡터 데이터베이스에 넣으면, 비슷한 문장을 찾는 일은 쉬워져도 사실·추정·비밀정보·만료된 상태를 구분하기 어려워집니다.</p> <p><img src="/images/local-llm-agent-memory-audit-context-01.jpg" alt="로컬 에이전트의 기억이 분류와 검사를 거쳐 보관되거나 수정되는 흐름을 표현한 밝은 일러스트"></p> <p><em>로컬 에이전트의 기억은 쌓이는 것보다 분류·검사·정리되는 과정이 중요합니다.</em></p> <h2 id="기억에는-종류와-출처가-있어야-합니다">기억에는 종류와 출처가 있어야 합니다</h2> <p>A-MEM 연구는 기존 기억 시스템이 저장과 검색에 머무르고, 기억을 구조화하고 서로 연결하는 능력이 부족하다고 지적합니다. 이 연구의 방식처럼 새 기억에 맥락 설명, 키워드, 태그를 붙이고 관련 기록을 연결하면 검색 결과의 의미를 더 잘 설명할 수 있습니다. 그러나 태그를 붙이는 것만으로 감사 가능한 기억이 완성되지는 않습니다.</p> <p>실무에서는 최소한 다음 속성을 분리해 두는 편이 안전합니다.</p> <ul> <li>사실인지, 사용자의 선호인지, 에이전트의 추정인지</li> <li>어디에서 나온 정보인지와 마지막으로 확인한 시점</li> <li>어느 사용자·프로젝트·작업 범위에서만 유효한지</li> <li>민감도와 보존 기간은 얼마인지</li> <li>이후 답변이나 도구 실행에 사용됐는지</li> </ul> <p>이렇게 하면 “에이전트가 그렇게 기억한다”는 문장이 “어떤 출처의 기록을 언제 저장했고, 어떤 조건에서 다시 사용했는가”라는 질문으로 바뀝니다. 장기기억의 품질은 저장량이 아니라 설명 가능성으로 측정해야 합니다.</p> <h2 id="작은-모델일수록-기억-쓰기를-감시해야-합니다">작은 모델일수록 기억 쓰기를 감시해야 합니다</h2> <p>기억을 읽는 것보다 쓰는 것이 더 위험할 수 있습니다. 한 번 잘못 저장된 선호나 프로젝트 상태가 이후의 검색 결과에 계속 섞이면, 에이전트는 과거의 오류를 새로운 맥락처럼 반복합니다. 삭제된 사실이 임베딩 백업이나 요약 메모에 남는 문제도 생깁니다.</p> <p>2026년의 한 연구는 Qwen 계열 소형 모델과 두 기억 프레임워크를 분석하면서 에이전트 기억의 실패가 겉으로 드러나지 않을 수 있다고 보고했습니다. 정보를 추출하지 못했는지, 저장하지 못했는지, 검색하지 못했는지 단계별로 진단하는 방법을 제안했지만, 이 결과를 모든 모델에 일반화할 수는 없습니다. 중요한 점은 기억 오류도 별도의 관측 대상이어야 한다는 사실입니다.</p> <p>제가 로컬 에이전트에 먼저 넣고 싶은 구조는 복잡한 지능이 아니라 단순한 기록 흐름입니다. 원본 이벤트는 짧게 보존하고, 새 기억은 바로 확정하지 않고 후보 큐에 넣습니다. 그다음 유형·출처·민감도·유효기간을 분류하고, 민감하거나 영향이 큰 내용은 사람의 확인을 거칩니다. 검색할 때는 프로젝트와 시간 범위를 먼저 적용하고, 답변에 사용된 기억의 출처를 남깁니다. 마지막으로 주기적인 샘플 감사에서 잘못 저장된 기억, 만료된 기억, 한 번도 사용되지 않은 기억을 찾아냅니다.</p> <h2 id="로컬이라는-말이-책임을-줄여주지는-않습니다">로컬이라는 말이 책임을 줄여주지는 않습니다</h2> <p>데이터가 외부 서버에 없다는 것은 큰 장점이지만, 로컬 디스크에 남아 있다는 뜻이기도 합니다. 메모리 파일과 임베딩 저장소를 누가 읽을 수 있는지, 백업에 무엇이 포함되는지, 삭제 요청이 모든 사본에 반영되는지를 관리해야 합니다. 모델을 바꾸거나 저장 형식을 바꿀 때 기억을 다시 검증할 수 있는 내보내기·삭제 경로도 필요합니다.</p> <p>로컬 LLM의 다음 경쟁력은 더 긴 컨텍스트만이 아닐 것입니다. 개인 장비에서 돌아가는 에이전트가 무엇을 기억하고, 왜 기억하며, 언제 잊는지를 사용자가 확인할 수 있어야 합니다. 장기기억을 분류하고 감사하는 일은 부가 기능이 아니라 로컬 에이전트를 계속 믿고 쓰기 위한 기본 운영 장치입니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/ai-slop-signal-to-noise/https://jakob-ai-notes.pages.dev/ko/posts/ai-slop-signal-to-noise/AI가 만든 대량 콘텐츠가 정보의 신호대잡음비를 바꾸는 방식과, 기술 커뮤니티와 개발자가 사실과 해석을 구분해야 하는 이유를 살펴봅니다.Sat, 08 Aug 2026 00:00:00 GMT<p>AI 슬롭이라는 말을 들으면 대개 쓸모없는 자동 생성물을 떠올립니다. 하지만 이 말을 그렇게 넓게 쓰면 문제의 모양을 놓치게 됩니다. University of Miami 연구진은 AI 슬롭의 대표적인 특징을 겉보기에는 유능하지만 내용이 얕은 표면적 유능함, 사람이 만들 때보다 훨씬 적은 노력으로 생산되는 비대칭적 노력, 대량 생산 가능성으로 정리했습니다. 동시에 모든 AI 생성물이 같은 종류의 쓰레기는 아니며, 슬롭도 문화와 정보 시장에서 나름의 기능을 가질 수 있다고 설명합니다.</p> <p>이 구분은 중요합니다. AI로 만든 요약, 그림, 튜토리얼이 있다는 사실만으로 품질을 판정할 수는 없습니다. 반대로 문장이 매끄럽고 정보가 많아 보인다는 이유만으로 신뢰할 수도 없습니다. 지금 커뮤니티에서 반복되는 불만은 생성물이 존재한다는 데 있지 않고, 유용한 기록과 비슷한 모양의 filler를 찾는 데 드는 시간이 늘어난다는 데 있습니다.</p> <h2 id="정보가-많아져도-발견은-쉬워지지-않는다">정보가 많아져도 발견은 쉬워지지 않는다</h2> <p>생성 비용이 내려가면 콘텐츠의 공급은 빠르게 늘어납니다. 짧은 제품 소개, 비슷한 벤치마크 해설, 서로를 다시 요약한 기술 글, 실제 실행 없이 만들어진 예제 저장소가 검색 결과와 피드에 함께 들어옵니다. 이것이 모든 개발자 커뮤니티가 이미 망가졌다는 증거는 아닙니다. 다만 정보의 양이 늘어나는 것과 신호의 비율이 좋아지는 것은 다른 문제입니다.</p> <p>독자가 마주하는 비용도 바뀝니다. 예전에는 자료를 찾는 데 시간이 들었다면, 이제는 찾은 자료가 원문에 닿아 있는지, 누가 확인했는지, 실제로 재현되는지를 다시 확인하는 데 시간이 듭니다. 읽기 비용이 아니라 검증 비용이 커지는 것입니다.</p> <p><img src="/images/ai-slop-signal-to-noise-context-01.jpg" alt="대량으로 쌓이는 비슷한 콘텐츠 사이에서 한 장의 신뢰할 만한 자료를 찾는 모습을 표현한 밝은 일러스트"></p> <p><em>생성물의 양보다 중요한 것은 출처와 검증 경로가 남아 있는지입니다.</em></p> <h2 id="숫자와-매끄러운-문장이-신호를-보장하지-않는다">숫자와 매끄러운 문장이 신호를 보장하지 않는다</h2> <p>AI 콘텐츠가 기술 논의에 들어오면 숫자가 신뢰의 장식처럼 쓰이기 쉽습니다. 벤치마크 점수, 조회 수, 별 개수, 인용 횟수가 나열되면 글이 검증된 것처럼 보입니다. 하지만 원본 데이터와 실행 조건이 없으면 숫자는 결론이 아니라 또 하나의 주장일 뿐입니다.</p> <p>Nature에 실린 연구는 정확도 중심의 평가가 불확실할 때 모른다고 말하는 것보다 추측을 하도록 유도할 수 있다고 분석합니다. 이 논문은 AI 슬롭을 직접 측정한 연구가 아닙니다. 다만 평가가 무엇을 보상하느냐가 모델의 행동을 바꾼다는 점을 보여줍니다. 같은 논리는 콘텐츠 유통에도 적용할 수 있습니다. 양과 반응만 보상하면, 조심스럽고 검증 가능한 글보다 빠르고 자신감 있는 글이 더 멀리 퍼질 수 있습니다. 이 문장은 연구 결과의 직접 결론이 아니라 그 결과에서 도출한 해석입니다.</p> <h2 id="개발자가-확인할-세-가지">개발자가 확인할 세 가지</h2> <p>첫째는 출처입니다. 글이 공식 발표, 원문 논문, 실제 저장소, 재현 가능한 데이터로 이어지는지 확인해야 합니다. 링크가 많다는 것과 출처가 분명하다는 것은 다릅니다. 원문이 하나도 없이 다른 요약문만 서로 인용한다면 정보의 사슬은 길어져도 근거는 강해지지 않습니다.</p> <p>둘째는 구체성입니다. 어떤 환경에서 실행했는지, 실패 조건은 무엇이었는지, 공개된 코드와 결과가 같은 말을 하는지 살펴봐야 합니다. “쉽게 된다”는 문장보다 입력·출력·버전·제한 조건이 남은 기록이 더 가치 있습니다.</p> <p>셋째는 책임과 갱신입니다. 오류가 발견됐을 때 누가 수정하는지, 글이 언제 업데이트됐는지, 오래된 결과가 여전히 현재 주장처럼 유통되는지를 봐야 합니다. 완벽한 저자를 찾자는 뜻이 아니라, 검증과 수정의 경로가 있는 자료를 우선하자는 뜻입니다.</p> <h2 id="에이전트는-슬롭을-기억하지-않아야-한다">에이전트는 슬롭을 기억하지 않아야 한다</h2> <p>이 문제는 사람의 검색 습관에만 머물지 않습니다. 에이전트가 웹 자료와 대화 기록을 장기기억으로 저장한다면, 표면적으로 그럴듯한 내용이 다음 답변의 전제가 될 수 있습니다. 출처, 작성 시점, 확신 수준, 만료 조건을 기록하지 않은 메모리는 검색 가능한 오염에 가깝습니다.</p> <p>따라서 에이전트의 기억 쓰기에는 검색보다 엄격한 기준이 필요합니다. 출처가 없는 주장, 단순 반복, 광고성 문구, 검증되지 않은 요약은 기억 후보로만 남기거나 저장하지 않아야 합니다. 저장하더라도 사실, 해석, 미확인 주장을 분리하고 나중에 다시 확인할 수 있어야 합니다. AI 슬롭의 시대에는 잘 기억하는 시스템보다 잘 버리는 시스템이 더 유용할 수 있습니다.</p> <h2 id="답은-생성-중단이-아니다">답은 생성 중단이 아니다</h2> <p>AI로 만든 콘텐츠가 모두 사라져야 한다는 결론은 현실적이지도, 필요한 결론도 아닙니다. 초안, 번역, 아이디어 정리, 접근성 보조처럼 생성물이 실제 가치를 주는 영역은 분명히 있습니다. 필요한 것은 생산량을 줄이는 구호보다 신호를 보존하는 운영 방식입니다.</p> <p>원문을 가까이 두고, 생성과 검증을 구분하고, 중요한 주장은 사람이 확인하며, 검색과 에이전트 기억에 출처와 불확실성을 함께 남겨야 합니다. AI 슬롭이 많아질수록 우리에게 필요한 능력은 더 빨리 만드는 능력이 아니라 무엇을 믿고, 무엇을 보류하고, 무엇을 버릴지 구분하는 능력입니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/codex-gpt-5-6-update/https://jakob-ai-notes.pages.dev/ko/posts/codex-gpt-5-6-update/최근 OpenAI의 Codex 업데이트를 GPT-5.6 제공 범위, 브라우저 디버깅, 원격 작업, 재사용 가능한 워크플로 관점에서 정리합니다.Fri, 07 Aug 2026 00:00:00 GMT<p>8월 6일 OpenAI 업데이트는 모델 발표처럼 보이기 쉬웠습니다. ChatGPT의 GPT-5.6 Sol이 개선됐고, 무료·Go 사용자의 기본 모델에는 GPT-5.6 Luna가 확대됐으며, 추론량을 조절하는 슬라이더와 Think 버튼이 추가됐습니다.</p> <p>그런데 이 발표에는 중요한 경계가 있습니다. 이번 변경은 ChatGPT의 대화 경험에 적용되며, OpenAI의 릴리스 노트는 Work와 Codex는 이번 업데이트에서 바뀌지 않는다고 명시합니다.</p> <p>그렇다고 Codex 업데이트가 멈춘 것은 아닙니다. Codex는 별도의 업데이트 흐름을 가지고 있고, 최근 변화의 핵심은 코딩 모델 이름보다 에이전트가 일하는 환경에 가까워지고 있습니다.</p> <h2 id="gpt-56은-이미-codex의-선택지가-됐습니다">GPT-5.6은 이미 Codex의 선택지가 됐습니다</h2> <p>OpenAI의 GPT-5.6 출시 글에 따르면 GPT-5.6 제품군은 ChatGPT·Codex·API에서 제공됩니다. Codex에서는 Free·Go 사용자가 Terra를 사용할 수 있고, Plus·Pro·Business·Enterprise 사용자는 Sol·Terra·Luna 중에서 선택할 수 있습니다. GPT-5.6에 접근할 수 있는 사용자는 max 추론 설정을 사용할 수 있으며, Codex의 ultra는 Plus 이상 요금제에 제공됩니다.</p> <p>OpenAI Help Center는 Codex의 GPT-5.6 최소 버전으로 데스크톱 앱 26.707.30751 또는 Codex CLI 0.144.0을 안내합니다.</p> <p><img src="/images/codex-gpt-5-6-update-context-01.jpg" alt="브라우저 검사, 터미널 작업, 프로젝트 지침이 하나의 코드 폴더로 모이는 모습을 표현한 일러스트"></p> <p><em>Codex는 브라우저·터미널·프로젝트 맥락을 하나의 작업 환경으로 연결하고 있습니다.</em></p> <h2 id="최근-업데이트의-중심은-모델-주변의-작업입니다">최근 업데이트의 중심은 모델 주변의 작업입니다</h2> <p>OpenAI 릴리스 노트에는 모델 이름에 가려지기 쉬운 Codex 변화가 여럿 기록돼 있습니다.</p> <p>Developer mode는 Chrome과 Codex 인앱 브라우저에서 Codex가 제한된 Chrome DevTools Protocol에 접근하도록 합니다. 콘솔 출력과 네트워크 트래픽을 확인하고, DOM과 적용된 스타일을 살펴보며, 실제 브라우저 문제를 진단할 수 있습니다. 이 기능은 기본적으로 꺼져 있습니다.</p> <p>같은 릴리스에는 AGENTS.md 프로젝트 지침 뼈대를 만들어주는 /init 명령도 포함됐습니다. 그보다 앞선 업데이트에서는 Codex Remote가 모든 ChatGPT 요금제에 일반 제공돼, 휴대폰에서 연결된 Mac·Windows 호스트의 작업을 시작하거나 이어가고 진행 상황을 확인하며 승인을 내릴 수 있게 됐습니다. Record &amp; Replay는 지원되는 Mac 환경에서 한 번 보여준 작업 흐름을 재사용 가능한 skill로 바꾸는 기능입니다.</p> <p>브라우저 검사는 진단을 돕고, /init은 저장소 규칙을 세우며, 원격 접근과 Record &amp; Replay는 작업을 감독하고 반복하는 방식을 바꿉니다.</p> <h2 id="실제로-바뀌는-것은-무엇인가">실제로 바뀌는 것은 무엇인가</h2> <p>제가 보기에는 Codex가 단순한 모델 선택기에서 통제 가능한 개발 환경으로 이동하고 있습니다. 모델 성능은 여전히 중요하지만, 브라우저·터미널·저장소 지침·원격 호스트·승인 경계·재사용 가능한 워크플로도 결과를 좌우합니다.</p> <p>그래서 8월 6일 ChatGPT 업데이트를 Codex 모델 업데이트라고 부르는 것은 정확하지 않습니다. 공식 노트는 이번 릴리스에서 Codex가 바뀌지 않았다고 말합니다. 더 정확한 이야기는 이렇습니다. ChatGPT는 대화에 맞춘 모델 업데이트를 받고 있고, Codex는 자체 도구와 작업 환경을 통해 계속 확장되고 있습니다.</p> <p>개발자에게 남는 질문도 달라졌습니다. 어떤 조합이 에이전트가 작업의 맥락을 잃지 않고 실제 결과를 완성하게 하는지를 물어야 합니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/ai-agent-command-approval-blind-spots/https://jakob-ai-notes.pages.dev/ko/posts/ai-agent-command-approval-blind-spots/4만 회 이상 진행된 실험을 바탕으로 익숙한 명령어, 승인 피로, 휴먼 인 더 루프 통제가 코딩 에이전트에 충분하지 않은 이유를 정리합니다.Fri, 07 Aug 2026 00:00:00 GMT<p>코딩 에이전트의 대표적인 안전장치는 명령을 실행하기 전에 사람에게 묻는 것입니다. 모델이 행동을 제안하고, 개발자가 내용을 읽은 뒤, 허용할지 거부하는 구조입니다.</p> <p>그럴듯한 마지막 방어선이지만, 최근 한 실험은 이 방어선이 생각보다 약할 수 있음을 보여줍니다.</p> <p>Scale X의 Alex Wauters는 짧은 브라우저 게임에서 4만 회가 넘는 플레이와 40만 9천 건의 승인·거부 판단을 분석했습니다. 참가자는 코딩 에이전트의 휴먼 인 더 루프가 되어 평범한 명령은 승인하고, 데이터를 외부로 보내거나 지속 설정을 바꾸거나 코드를 실행할 수 있는 명령은 막아야 했습니다.</p> <p>실험에서 보고된 평균 정확도는 66.3%였습니다. 평균적인 참가자가 위협 명령 3개 중 1개 정도를 놓쳤다는 뜻입니다.</p> <p><img src="/images/ai-agent-command-approval-blind-spots-context-01.jpg" alt="평범해 보이는 터미널 명령 뒤에 프로젝트 파일에서 외부 클라우드로 향하는 붉은 경로가 숨은 모습을 표현한 일러스트"></p> <p><em>평범해 보이는 스크립트도 실제로는 다른 동작을 숨길 수 있다는 점을 표현한 이미지입니다.</em></p> <h2 id="실험이라는-한계부터-봐야-합니다">실험이라는 한계부터 봐야 합니다</h2> <p>이 결과는 실제 서비스에서 발생한 사고 조사 결과가 아닙니다. 참가자가 위협을 인지하고 있는 시간 제한 게임이었고, 명령의 약 34%가 위협으로 설정됐습니다. 따라서 개발자가 일상 업무에서도 같은 비율로 실패한다고 옮겨 적어서는 안 됩니다.</p> <p>그럼에도 이 실험은 문제가 어떤 모양으로 나타나는지 보여줍니다. 눈에 띄게 파괴적인 명령은 비교적 잘 잡혔지만, 자격 증명 탈취·코드 실행·범위를 벗어난 파일 접근처럼 실제 피해로 이어질 수 있는 행동은 더 자주 놓쳤습니다. 승인 순간에는 위험해 보이지 않기 때문입니다.</p> <p>Scale X는 범위 위반 명령의 누락률을 35.0%, 데이터 외부 전송 또는 코드 실행 명령의 누락률을 33.4%로 보고했습니다. 가장 많이 승인된 명령은 npm run analyze였고, 승인 비율은 64.7%였습니다. 명령 이름은 평범했지만, 실제 동작은 프로젝트 안의 스크립트에 들어 있었습니다.</p> <p>중요한 차이입니다. 질문은 명령어가 익숙한가가 아니라, 현재 저장소 상태에서 그 명령어가 무엇을 실행할 수 있는가여야 합니다.</p> <h2 id="익숙한-이름은-안전하다는-착각을-만듭니다">익숙한 이름은 안전하다는 착각을 만듭니다</h2> <p>개발자는 npm run build나 npm run deploy가 프로젝트가 정의한 동작을 실행할 수 있다는 사실을 알고 있습니다. 하지만 실제 저장소에서는 같은 에이전트 세션 중 앞서 파일이 바뀌었을 수 있고, 한 스크립트가 다른 스크립트를 호출할 수도 있으며, 의존성이 설치 과정에서 추가 동작을 수행할 수도 있습니다. 권한 팝업에 보이는 짧은 명령어만으로는 전체 실행 경로를 설명할 수 없습니다.</p> <p>그래서 명령 하나씩 승인하는 방식은 격리를 대신하기 어렵습니다. 사용자는 작업이 진행되는 동안 움직이는 시스템의 일부만 보고 결정을 내려야 합니다.</p> <p>시각적으로도 문제가 있습니다. 초록색 승인 버튼은 결정을 단순한 양자택일처럼 보이게 하지만, 실제 위험은 파일·의존성·환경 변수·네트워크 접근·출력 데이터를 받는 주체에 따라 달라집니다.</p> <h2 id="권한-피로는-ui-문제가-아닙니다">권한 피로는 UI 문제가 아닙니다</h2> <p>게임 데이터에서는 한 세션의 뒤쪽으로 갈수록 주의력이 떨어지는 신호도 나타났습니다. 이는 더 넓은 엔지니어링 문제와 이어집니다. 사용자가 비슷한 승인 요청을 반복해서 보면 각각을 새로운 보안 판단으로 대하지 않고 습관적으로 처리하게 됩니다.</p> <p>불편한 균형 문제가 생깁니다. 너무 자주 물으면 피로가 쌓여 승인 버튼을 누르게 됩니다. 너무 적게 물으면 에이전트가 중요한 변경을 검토 없이 수행합니다. 모든 것을 거부해 해결하려 하면 유용한 작업이 멈추고 사람이 병목이 됩니다.</p> <p><img src="/images/ai-agent-command-approval-blind-spots-context-02.jpg" alt="반복되는 승인 카드가 이어지며 경고가 나타나도 손이 승인 버튼을 누르는 모습을 표현한 일러스트"></p> <p><em>반복되는 요청은 신중한 검토를 같은 버튼을 누르는 습관으로 바꿀 수 있습니다.</em></p> <p>이 실험이 휴먼 인 더 루프를 없애야 한다는 증거는 아닙니다. 사람이 유일한 통제 장치여서는 안 된다는 증거에 가깝습니다.</p> <h2 id="더-강한-설계는-어떤-모습인가">더 강한 설계는 어떤 모습인가</h2> <p>첫 번째 계층은 권한 표면을 줄이는 것입니다. 작업 트리만 수정하면 되는 에이전트에 운영 자격 증명, 넓은 홈 디렉터리, 제한 없는 네트워크 접근까지 자동으로 줄 이유는 없습니다.</p> <p>두 번째 계층은 격리입니다. 샌드박스, 일회성 작업 공간, 별도로 분리된 비밀정보, 가능한 곳의 읽기 전용 접근, 명시적인 네트워크 정책은 승인 누락이 만들어낼 수 있는 피해를 줄입니다. 사용자는 보이지 않는 전체 실행 그래프가 아니라 범위가 제한된 행동을 승인해야 합니다.</p> <p>세 번째 계층은 증거입니다. 권한 요청은 실제 질문에 답할 수 있을 만큼의 맥락을 보여줘야 합니다. 무엇이 바뀌었는지, 무엇이 실행되는지, 데이터가 어디로 가는지, 되돌릴 수 있는지를 알아야 합니다. 명령 이름만 보여주는 것으로는 부족합니다.</p> <p>마지막으로 에이전트는 요청 내용, 승인된 범위, 결과 변경, 접근한 파일과 서비스를 기록해야 합니다. 그래야 실수가 “무엇을 승인했다고 생각했는가”를 둘러싼 논쟁이 아니라 복구 가능한 사건이 됩니다.</p> <p>Scale X 실험은 규모가 제한된 게임이고, 그 숫자를 모든 개발 업무에 일반화할 수는 없습니다. 그래도 실무적인 교훈은 분명합니다. 사람의 승인은 중요하지만 잡음이 있는 센서이기도 합니다. 코딩 에이전트에는 그 센서 주변에 권한 설계·격리·증거를 함께 배치해야 합니다. 그래야 익숙해 보이는 명령 하나를 놓친 일이 시스템 전체의 실패가 되지 않습니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/nested-codex-model-roles/https://jakob-ai-notes.pages.dev/ko/posts/nested-codex-model-roles/에이전트를 많이 늘리는 대신 기획·구현·리뷰·QA를 책임·모델 경로·증거·권한으로 나눠본 프로젝트 기록입니다.Thu, 06 Aug 2026 12:57:37 GMT<p>AI 코딩 workflow를 만들 때 흔히 하는 실수는 요구사항 해석부터 구현, 테스트, 리뷰, 병합 승인까지 모델 하나에게 맡기는 것입니다. 작은 작업에서는 편합니다. 하지만 일이 커지면 context가 길어지고, 무엇이 실패했는지와 누가 어떤 판단을 했는지 추적하기 어려워집니다.</p> <p>제가 택한 답은 에이전트를 최대한 늘리는 것이 아닙니다. 사람이 확인할 수 있는 경계를 역할마다 정하는 것입니다. 중요한 질문은 “모델이 몇 개 실행되는가?”가 아니라 “이 역할은 무엇을 판단하고, 무엇을 바꾸고, 어디에서 멈추는가?”입니다.</p> <h2 id="역할표는-직접-확인할-수-있어야-합니다">역할표는 직접 확인할 수 있어야 합니다</h2> <p>현재 공개된 Drig lifecycle은 이 구분을 구체적으로 보여줍니다. 모델이 판단하는 stage와 시스템이 계약을 강제하는 stage를 따로 이름 붙입니다.</p> <table> <thead> <tr> <th>단계</th> <th>Drig에 기록된 경로</th> <th>책임</th> </tr> </thead> <tbody> <tr> <td><code>ideaInterview</code></td> <td><code>gpt-5.6-terra</code> / high</td> <td>막히는 범위 공백만 확인</td> </tr> <tr> <td><code>internalPlan</code></td> <td><code>gpt-5.6-sol</code> / high</td> <td>승인된 맥락을 제한된 plan으로 변환</td> </tr> <tr> <td>개발과 checkpoint</td> <td><code>gpt-5.6-sol</code> / high</td> <td>범위가 정해진 slice를 구현하고 증거를 남김</td> </tr> <tr> <td><code>codeReview</code></td> <td><code>gpt-5.6-sol</code> / high</td> <td>immutable checkpoint를 검토</td> </tr> <tr> <td>QA revision 1·2</td> <td><code>gpt-5.6-luna</code> / max</td> <td>남은 요구사항과 evidence를 확인</td> </tr> <tr> <td>routing·validation·publication·closeout</td> <td>모델 경로 없음</td> <td>결정론적 계약을 강제</td> </tr> </tbody> </table> <p>모델 이름은 바뀔 수 있습니다. 오래 남는 원칙은 경로가 명시되어 있다는 점입니다. Drig는 <code>model-route --stage &lt;stage&gt;</code> 명령으로 stage별 경로를 확인하게 하고, 정책이 없는 stage에 기본 모델을 조용히 배정하지 않고 fail-closed합니다.</p> <p><img src="/images/nested-codex-model-roles-context-01.png" alt="작은 작업이 기획·구현·리뷰·QA lane으로 나뉘고, 각 역할에 경계와 evidence 카드가 붙어 있는 모습"></p> <p><em>에이전트 수보다 중요한 것은 역할의 경계입니다.</em></p> <h2 id="역할에는-권한과-멈춤-지점도-들어갑니다">역할에는 권한과 멈춤 지점도 들어갑니다</h2> <p>역할 이름만 정한다고 충분하지 않습니다. 무엇을 할 수 있는지와 어디에서 멈춰야 하는지도 함께 정해야 합니다.</p> <p>구현 역할은 맡은 slice를 수정하고 필요한 검사를 실행한 뒤 local checkpoint를 남길 수 있습니다. 하지만 자기 코드가 곧 최종 승인이라고 선언해서는 안 됩니다. 리뷰 역할은 변경을 읽고 finding을 남길 수 있지만, 그 과정에서 제품 코드를 몰래 고쳐서는 안 됩니다. QA 역할은 acceptance criteria와 제한된 evidence를 받아야지, 이전 대화 전체를 무제한으로 전달받아서는 안 됩니다.</p> <p>그래서 Drig lifecycle은 checkpoint마다 durable slice worktree를 두고, checkpoint별 native review를 실행하며, requirements QA에는 evidence manifest를 전달합니다. 최종 publication과 merge 결정은 코드를 작성한 모델과 분리됩니다. 한 agent가 자기 결과를 스스로 성공으로 선언하는 것보다 느리지만, 잘못된 결과가 어디에서 생겼는지는 더 쉽게 찾을 수 있습니다.</p> <h2 id="작은-작업은-작게-남겨야-합니다">작은 작업은 작게 남겨야 합니다</h2> <p>역할을 나누는 것이 성숙함의 증거는 아닙니다. 파일 하나를 고치는 되돌릴 수 있는 작업이라면 Codex session 하나와 직접 테스트만으로 충분할 수 있습니다. 그런 작업을 기획·구현·리뷰·QA agent로 나누면 유용한 경계는 생기지 않고 handoff만 늘어납니다.</p> <p>다음 조건 중 하나가 실제로 존재할 때만 두 번째 역할을 추가합니다.</p> <ul> <li>별도의 permission set이 필요한가?</li> <li>변경을 작성하지 않은 process가 acceptance criteria를 확인해야 하는가?</li> <li>durable contract를 만들 만큼 작업이 반복되는가?</li> <li>chat을 다시 읽지 않고 checkpoint에서 실패를 재개해야 하는가?</li> <li>publication이나 merge 전에 owner의 별도 승인이 필요한가?</li> </ul> <p>하나도 해당하지 않는다면 추가 모델은 절차를 위한 절차일 가능성이 큽니다.</p> <h2 id="하네스를-가볍게-만든-뒤에도-남긴-것">하네스를 가볍게 만든 뒤에도 남긴 것</h2> <p>무거운 wrapper는 걷어내고, 역할별 context·명시적인 model routing·집중된 workspace·다른 역할이 읽을 수 있는 evidence는 남겼습니다. 그래서 현재 Drig plugin은 같은 작업을 끝내려는 자율 agent 모음이 아닙니다. 일반 Codex가 제품 개발을 맡고, 주변 stage가 기획·리뷰·QA·배포를 보이게 만드는 workflow입니다.</p> <p>이 구조는 모델을 평가하는 방식도 바꿉니다. 코드를 잘 쓰는지만 보지 않습니다. 맡은 slice 안에 머무는지, 쓸 만한 checkpoint를 남기는지, validator에 반응하는지, 역할이 끝났을 때 멈추는지를 봅니다. 구현 모델이 강하더라도 잘못된 확신을 유도한다면 QA 모델로는 맞지 않을 수 있습니다.</p> <h2 id="이-구조가-해결하지-못하는-것">이 구조가 해결하지 못하는 것</h2> <p>역할을 나눈다고 workflow가 자동으로 올바르게 되지는 않습니다. stage가 늘어나면 시간과 context 비용도 늘어납니다. acceptance criteria가 잘못되어 있으면 아주 꼼꼼하게 검증해도 잘못된 결과를 확인하게 됩니다. 모델 경로가 명확해도 선택 자체가 나쁠 수 있습니다.</p> <p>역할 구조가 해주는 일은 실패가 나타날 장소를 마련하는 것뿐입니다. 하지만 그 정도면 다음 변경을 더 신중하게 만들 수 있습니다. 목표는 더 큰 agent 팀이 아닙니다. 요청부터 마지막 evidence까지 사람이 설명할 수 있는 작은 책임 집합입니다.</p> <p>이것이 제가 Nested Codex라고 부르는 원칙입니다. 모델 하나로 충분한 작업에는 하나만 사용합니다. 독립된 경계를 만들 때만 역할을 추가하고, 시작할 때부터 그 모델·권한·evidence·멈춤 지점을 보이게 합니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/google-ecosystem-ai-growth-engine/https://jakob-ai-notes.pages.dev/ko/posts/google-ecosystem-ai-growth-engine/구글은 누구보다 큰 AI 생태계를 갖고 있습니다. 문제는 그 생태계가 OpenAI와 Anthropic이 만든 집중력과 시장의 추진력까지 만들어낼 수 있느냐는 데 있습니다.Wed, 05 Aug 2026 22:35:51 GMT<p>8월 5일, 구글은 AI 조직의 중심에서 꽤 큰 변화를 발표했습니다. Demis Hassabis는 Google DeepMind 의장과 Alphabet 수석과학자가 됩니다. Koray Kavukcuoglu는 Google DeepMind의 수석부사장이 되어 Gemini 모델 개발, 프런티어 연구, Gemini 앱과 개발자 조직을 맡습니다. Jeff Dean과 Sanjay Ghemawat는 머신러닝·과학·엔지니어링에 집중하는 독립 공익법인을 만들기 위해 회사를 떠납니다. <a href="https://blog.google/company-news/inside-google/message-ceo/next-chapter-ai-momentum/">구글 공식 발표</a></p> <p>발표문은 이번 변화를 의도적인 다음 단계로 설명합니다. 하지만 구글의 거대한 생태계가 AI를 키우는 힘인지, 회사를 집중하기 어렵게 만드는 무게인지가 더 큰 질문으로 남습니다. 검색·안드로이드·Workspace·Cloud와 개발자 접점을 가진 구글은 배포에서 유리하지만, 시장의 주목도는 하나의 모델과 제품 이야기를 가진 OpenAI·Anthropic에 더 쉽게 모입니다.</p> <h2 id="실제로-바뀐-것은-무엇인가">실제로 바뀐 것은 무엇인가</h2> <p>먼저 사실과 해석을 분리해야 합니다. Hassabis가 구글을 떠나는 것은 아닙니다. 그는 Isomorphic Labs와 장기 연구·AGI 방향에 더 집중하고, Kavukcuoglu는 모델·Gemini 앱·개발자 제품의 운영을 맡습니다. Dean과 Ghemawat는 별도 회사를 시작하지만 구글은 투자자이자 클라우드·연구 파트너로 남습니다. <a href="https://blog.google/company-news/inside-google/message-ceo/next-chapter-ai-momentum/">공식 발표문</a></p> <p>Axios는 이번 변화를 OpenAI와 Anthropic을 따라잡기 위한 구글 AI 조직의 큰 변화로 해석했습니다. 이것은 보도에 기반한 프레임이지 구글이 기술 경쟁에서 졌다는 증거는 아닙니다. 다만 시장이 구글을 연구 역량만으로 평가하지 않는다는 점은 보여줍니다. 이제 중요한 것은 구글이 가진 역량을 사람들이 알아보고 선택하며 반복해서 사용하는 제품으로 바꿀 수 있느냐입니다. <a href="https://www.axios.com/2026/08/05/google-deepmind-demis-hassabis-ai">Axios 보도</a></p> <p><img src="/images/google-ecosystem-ai-leadership-demis.jpg" alt="2025년 Demis Hassabis의 인물 사진"></p> <p><em>2025년 Demis Hassabis. Christopher Michel 촬영, <a href="https://creativecommons.org/licenses/by-sa/4.0/">CC BY-SA 4.0</a> 라이선스, <a href="https://commons.wikimedia.org/wiki/File:Demis_Hassabis_in_2025_by_Christopher_Michel_A.jpg">Wikimedia Commons</a> 제공. 사진은 수정하지 않고 사용했습니다.</em></p> <h2 id="생태계는-구글의-가장-큰-장점이다">생태계는 구글의 가장 큰 장점이다</h2> <p>구글의 생태계는 분명 강력한 구조적 이점을 줍니다. 모델은 완전히 새로운 유통 채널을 만들지 않아도 검색, 안드로이드, Workspace, Cloud, 개발자 도구를 통해 사용자에게 도달할 수 있습니다. 그 아래에는 데이터센터 운영 능력, 자체 가속기, 연구 조직, 소프트웨어 플랫폼도 있습니다.</p> <p>이 조합은 모델 개선, 사용자 접점, 개발자 실험, 실제 업무의 피드백을 하나의 루프로 묶을 수 있습니다.</p> <p>그래서 저는 구글의 생태계 자체를 약점이라고 생각하지 않습니다. 생태계는 해자에 가깝습니다. 다만 해자가 곧 추진력은 아닙니다. 어디에나 배포되어 있다는 사실이 사람들이 능동적으로 찾아 쓰는 제품이라는 뜻은 아니기 때문입니다.</p> <h2 id="같은-생태계가-ai를-작아-보이게-만드는-이유">같은 생태계가 AI를 작아 보이게 만드는 이유</h2> <p>큰 생태계에는 집중형 AI 회사가 감당하지 않아도 되는 의무가 따라옵니다. 구글은 검색·광고·개인정보·기존 제품에 AI가 미칠 영향을 함께 계산해야 하므로 새로운 기능을 제약 없는 실험처럼 출시하기 어렵습니다.</p> <p>이 때문에 시장에는 묘한 인상이 생길 수 있습니다. Gemini가 여러 곳에 들어가는데도 정작 중심 경험이 보이지 않는 것입니다. 검색·Workspace·Cloud·안드로이드의 기능이 각각 유용해도, 전체가 하나의 강한 습관을 만드는 제품이라기보다 여러 기능의 묶음처럼 느껴질 수 있습니다.</p> <p>OpenAI와 Anthropic은 핵심 인터페이스와 대표적인 약속을 더 쉽게 떠올리게 합니다. 이런 선명함은 시장의 관심과 개발자의 실험을 만들고, 추진력을 눈에 보이게 합니다. 선명한 회사가 반드시 이긴다는 뜻은 아니지만 중요한 차이입니다.</p> <h2 id="이번-인사-변화가-풀려는-문제">이번 인사 변화가 풀려는 문제</h2> <p>새 구조는 한 사람이 동시에 수행하기 어려운 두 일을 나누려는 시도로 보입니다. Hassabis는 장기 연구와 AGI 방향을, Kavukcuoglu는 모델 출시와 제품 실행을 맡는 식입니다. 한 사람은 프런티어를 지키고 다른 한 사람은 그것을 사용자에게 전달합니다.</p> <p>위험은 이 분리가 또 하나의 조정 단계가 되는 것입니다. 이번 구조가 의미 있으려면 새 직함을 추가하는 데 그치지 않고 실제 의사결정 경로를 짧게 만들어야 합니다.</p> <p>Dean과 Ghemawat의 독립은 생태계 전체에는 건강할 수 있지만, 구글에는 인재와 주도권을 계속 붙잡아야 한다는 과제를 남깁니다.</p> <h2 id="구글이-시장이-기다리는-ai-회사가-될-수-있을까">구글이 시장이 기다리는 AI 회사가 될 수 있을까</h2> <p>저는 가능하다고 생각합니다. 다만 OpenAI나 Anthropic을 그대로 따라가는 방식은 아닐 것입니다. 구글은 모델, 배포 채널, 컴퓨팅 인프라, 사람들이 매일 사용하는 업무 흐름이 서로 강화되는 다른 형태의 리더십을 만들어야 합니다.</p> <p>첫째, Gemini는 여러 기능에 붙는 이름이 아니라 분명한 제품 정체성이 되어야 합니다. 사용자는 Gemini에게 무엇을 시킬 수 있는지, 작업이 어디에서 계속되는지, 구글 서비스와 연결되어 있기 때문에 무엇이 더 좋아지는지를 이해할 수 있어야 합니다.</p> <p>둘째, 생태계의 힘을 연결된 제품의 개수가 아니라 실제 행동으로 측정해야 합니다. 반복 사용, 여러 제품을 가로지르는 작업 완료, 개발자 채택, 선택권이 있을 때 Gemini를 고르는 비율이 더 중요한 신호입니다. 미리 설치되어 있다는 사실은 선호와 다릅니다.</p> <p>셋째, AI 조직에는 불편한 제품 결정을 내릴 정도의 독립성이 필요합니다. 어떤 기능이 기존 습관을 흔들거나, 광고 영역을 바꾸거나, 여러 팀의 업무 방식을 바꾸게 되더라도 누군가는 AI의 미래를 위해 그 변화를 감수할지 명확하게 결정해야 합니다.</p> <h2 id="결론">결론</h2> <p>질문은 구글의 생태계가 AI에 너무 큰가가 아닙니다. 더 유용한 질문은 구글이 그 생태계를 강력하지만 서로 떨어진 채널의 집합이 아니라 하나의 일관된 AI 플랫폼처럼 느끼게 만들 수 있느냐입니다.</p> <p>구글에는 OpenAI와 Anthropic이 쉽게 복제할 수 없는 배포망·인프라·연구 역량이 있습니다. 그러나 이 자산이 리더십이 되려면 더 빠른 학습 루프와 선명한 사용자 습관을 만들어야 합니다. 그렇지 않으면 생태계는 구글의 움직임을 빠르게 하는 도구가 아니라 지켜야 하는 기존 질서가 됩니다.</p> <p>이번 인사 변화는 실패도 승리도 아닌 시험에 가깝습니다. 앞으로는 Gemini라는 이름이 몇 곳에 붙는지보다 출시 속도와 품질, 개발자 채택, 여러 제품을 가로지르는 작업의 반복을 지켜봐야 합니다.</p> <p>구글은 AI를 선도하는 회사가 될 수 있습니다. 다만 그 성공한 모습은 작은 OpenAI가 아닐 것입니다. 구글 전체 생태계가 마침내 하나의 분명한 AI 목적을 가진 것처럼 움직이는 모습에 더 가까울 것입니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/glm-5-2-open-weight-safety-gap/https://jakob-ai-notes.pages.dev/ko/posts/glm-5-2-open-weight-safety-gap/GLM-5.2의 성능 추격과 독립 평가에서 드러난 오픈 웨이트 모델의 안전장치·검증·배포 문제를 정리합니다.Wed, 05 Aug 2026 00:00:00 GMT<p>GLM-5.2가 다시 주목받은 이유는 단순히 성능이 좋아서가 아닙니다. 오픈 웨이트 모델이 폐쇄형 frontier 모델을 얼마나 빠르게 따라잡고 있는지, 그리고 그 능력이 공개된 뒤 안전장치를 누가 통제할 수 있는지를 한꺼번에 보여줬기 때문입니다.</p> <p>Z.ai는 2026년 6월 GLM-5.2를 공개하면서 1M 컨텍스트와 장기 작업 능력, 코딩 성능을 강조했습니다. 모델 가중치는 MIT 라이선스로 배포됐고, 누구나 내려받아 직접 실행하거나 수정할 수 있는 형태입니다. 이 내용은 Z.ai의 공식 발표입니다. 다만 제조사가 말하는 성능과 독립 평가에서 확인되는 위험은 분리해서 봐야 합니다. <a href="https://www.zhipuai.cn/zh/research/161">Z.ai 공식 발표</a></p> <h2 id="성능-격차가-몇-달-단위로-좁혀졌다">성능 격차가 몇 달 단위로 좁혀졌다</h2> <p>SaferAI는 8월 2일 공개한 독립 평가에서 GLM-5.2를 EU 범용 AI 행동강령이 정의한 네 가지 시스템 위험 영역과 관련 벤치마크로 살펴봤습니다. 보고서에 따르면 영역별 차이는 있었지만, 일부 사이버보안과 바이오 관련 평가에서 GLM-5.2는 출시 시점이 몇 달 앞선 frontier 모델에 가까운 수준을 보였습니다. 사이버 영역은 대략 2~4개월, 바이오 영역은 약 2개월 앞선 모델과 비교 가능한 결과였고, 소프트웨어 엔지니어링에서는 상대적으로 더 큰 차이가 남았습니다.</p> <p>이 결과를 GLM-5.2가 모든 작업에서 폐쇄형 모델과 동등하다는 뜻으로 읽어서는 안 됩니다. SaferAI도 이번 결과를 예비 평가로 설명했고, 공개 벤치마크의 일부만 다뤘으며 전체적인 위험도 판정은 내리지 않았습니다. <a href="https://www.safer-ai.org/research/glm-5-2-evaluation-report">SaferAI 평가 보고서</a></p> <p>그래도 의미는 분명합니다. 오픈 웨이트 모델이 성능 경쟁에서 한참 뒤처진 대안이 아니라, 특정 작업에서는 몇 달 전의 최상위 모델과 직접 비교해야 하는 선택지가 됐다는 점입니다. TechCrunch도 이 평가를 바탕으로 오픈 웨이트 모델의 능력 격차가 좁아지는 동시에 안전 격차는 남아 있다고 정리했습니다. <a href="https://techcrunch.com/2026/08/04/open-weight-ai-models-are-catching-up-to-the-frontier-the-safety-gap-remains/">TechCrunch의 관련 보도</a></p> <h2 id="성능이-비슷해져도-안전장치는-같아지지-않는다">성능이 비슷해져도 안전장치는 같아지지 않는다</h2> <p>폐쇄형 API를 사용할 때는 제공자가 여러 겹의 통제를 둘 수 있습니다. 유해한 요청을 거부하는 학습, 요청 분류기, 사용량 제한, 계정 차단, 모델 업데이트가 그 예입니다. 사용자는 모델의 가중치에 직접 접근하지 못하기 때문에 제공자가 정한 정책을 완전히 우회하기 어렵습니다.</p> <p>오픈 웨이트 배포는 구조가 다릅니다. 모델을 직접 내려받은 사용자는 가중치를 자기 환경에서 실행하고, 추가 학습을 하거나, 별도의 시스템 프롬프트와 정책 계층을 붙일 수 있습니다. SaferAI의 공개 API 테스트에서는 공격적 사이버보안과 바이오 관련 요청에 대한 거부가 관찰되지 않았고, 보고서는 오픈 웨이트 모델의 안전장치가 자체 호스팅 과정에서 제거될 수 있다고 지적했습니다.</p> <p>여기서 중요한 구분이 있습니다. 거부하지 않았다는 사실이 곧바로 현실의 공격을 성공시킨다는 뜻은 아닙니다. 반대로 API에서 거부했다고 해서 다운로드 가능한 가중치에도 같은 통제가 남는다는 뜻도 아닙니다. 모델 능력과 배포 환경의 통제력은 서로 다른 축입니다.</p> <h2 id="숫자를-볼-때-평가-하네스를-함께-봐야-한다">숫자를 볼 때 평가 하네스를 함께 봐야 한다</h2> <p>이번 보고서에서 인상적인 부분은 모델 점수 자체보다 조건에 따른 결과의 변동입니다. 예를 들어 CyberGym 재현율은 토큰 예산을 2M에서 50M으로 늘렸을 때 36.6%에서 76.2%로 달라졌습니다. 같은 모델도 얼마나 오래 생각하게 했는지, 어떤 도구를 연결했는지, 성공을 어떻게 판정했는지에 따라 결과가 크게 바뀔 수 있다는 뜻입니다.</p> <p>따라서 특정 벤치마크의 한 숫자만으로 모델의 실제 위험을 판단하면 안 됩니다. 캡처 더 플래그 문제를 잘 푸는 능력과 실제 조직의 여러 시스템을 장기간 공격하는 능력도 동일하지 않습니다. 반대로 특정 벤치마크에서 낮은 점수를 받았다고 해서 실무에서 안전하다고 단정할 수도 없습니다. 평가 대상, 프롬프트, 토큰 예산, 도구 권한, 네트워크 조건, 성공 기준을 함께 공개해야 비교가 가능합니다.</p> <p>이번 결과는 GLM-5.2가 위험하다고 판정한 보고서가 아니라, 독립적인 재현과 더 현실적인 시나리오 평가가 필요하다는 신호에 가깝습니다.</p> <h2 id="오픈-웨이트의-장점도-분명하다">오픈 웨이트의 장점도 분명하다</h2> <p>오픈 웨이트를 안전 문제만으로 설명하면 중요한 장점도 놓칩니다. 조직이 모델을 직접 실행하면 민감한 코드나 내부 문서를 외부 API로 보내지 않고, 자체 인프라 안에서 평가할 수 있습니다. 모델의 동작을 고정하고, 특정 언어와 업무에 맞게 조정하며, 제공자의 가격이나 정책 변경에 덜 종속될 수 있습니다. 보안 연구자에게는 모델 자체를 검증하고 방어 도구를 개발할 수 있는 접근성도 생깁니다.</p> <p>문제는 이 장점과 안전 책임이 함께 온다는 점입니다. 제공자가 거부 정책을 업데이트해 주기를 기다릴 수 없고, 모델을 공개한 뒤에는 가중치를 회수하기도 어렵습니다. 사용자가 얻는 자유의 일부는 운영자가 직접 감당해야 하는 통제 비용으로 바뀝니다.</p> <h2 id="개발자가-먼저-준비해야-할-것">개발자가 먼저 준비해야 할 것</h2> <p>GLM-5.2 같은 오픈 웨이트 모델을 실제 업무에 넣는다면 저는 다음 순서로 확인할 것 같습니다.</p> <ul> <li>공개 벤치마크 점수보다 우리 데이터와 업무에 맞는 별도 평가 세트를 만든다.</li> <li>공격적 보안, 개인정보, 비밀정보가 섞인 요청을 정상 작업과 분리해 테스트한다.</li> <li>모델의 거부 문구를 보안 경계로 간주하지 않고, 네트워크·파일·셸·클라우드 권한을 별도로 제한한다.</li> <li>도구 호출과 외부 전송을 기록하고, 위험한 작업은 사람의 승인을 거치게 한다.</li> <li>모델 카드, 라이선스, 가중치 출처, 수정 여부를 배포물과 함께 보존한다.</li> <li>자체 호스팅과 제공업체 API의 위험을 같은 것으로 취급하지 않는다.</li> </ul> <p>특히 에이전트에 연결할 때는 모델의 지능보다 권한 설계가 먼저입니다. 아무리 좋은 모델이라도 셸과 인터넷, 운영 데이터베이스를 동시에 자유롭게 사용할 수 있다면 안전성은 모델의 선의가 아니라 우연에 의존하게 됩니다.</p> <h2 id="오픈-웨이트-시대의-질문은-달라졌다">오픈 웨이트 시대의 질문은 달라졌다</h2> <p>예전에는 오픈 모델을 선택하는 이유를 비용이나 접근성에서 찾았습니다. 이제는 성능이 충분히 올라오면서 질문이 바뀌고 있습니다. 이 모델이 frontier 모델을 얼마나 따라잡았는가보다, 그 능력을 우리 환경에서 어떻게 제한하고 감사할 것인가가 더 중요해졌습니다.</p> <p>GLM-5.2는 오픈 웨이트 모델의 가능성을 보여주는 동시에, 안전장치를 제공업체의 API에만 맡길 수 없다는 사실도 보여줍니다. 저는 이 사례를 오픈 모델을 금지해야 한다는 근거로 읽지 않습니다. 오히려 공개된 가중치를 사용하는 조직이 자체 평가, 권한 경계, 행동 로그, 사고 대응 절차를 제품의 일부로 만들어야 한다는 신호로 읽습니다.</p> <p>성능 격차가 좁아질수록 안전 격차를 줄이는 일은 모델 회사만의 과제가 아닙니다. 모델을 다운로드하고, 연결하고, 업무에 배포하는 개발자와 조직이 함께 책임져야 할 운영 문제가 됩니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/ai-agent-audit-logs-by-default/https://jakob-ai-notes.pages.dev/ko/posts/ai-agent-audit-logs-by-default/AI 에이전트가 실제 시스템에 접근하는 시대에 필요한 외부 감사 로그, 권한 경계, 실시간 탐지의 기본 원칙을 정리했습니다.Tue, 04 Aug 2026 00:00:00 GMT<p>AI 에이전트가 실제 시스템에 접근하는 시대가 되면서 보안의 기준도 바뀌고 있습니다. 모델이 얼마나 똑똑한지뿐 아니라 어떤 권한으로 무엇을 했는지, 그 행동을 외부에서 확인할 수 있는지가 중요해졌습니다.</p> <p>최근 Anthropic은 사이버보안 평가 기록 141,006건을 다시 살펴본 뒤 Claude 모델이 세 개의 실제 조직 시스템에 접근한 세 건의 사고를 공개했습니다. 평가 파트너의 환경 설정 문제로 인터넷 접근이 가능했지만, 모델에는 인터넷이 없는 시뮬레이션이라고 안내된 상태였습니다. Claude는 캡처 더 플래그 과제를 수행하는 과정에서 실제 시스템을 평가 환경의 일부로 오인했고, 약한 비밀번호와 인증되지 않은 엔드포인트 같은 기본적인 방법으로 접근했습니다. Anthropic은 복잡한 취약점이나 모델이 스스로 탈출하려는 행동은 확인하지 못했다고 설명했습니다. <a href="https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals">Anthropic의 조사 보고서</a></p> <p>OpenAI가 앞서 공개한 사건은 양상이 조금 달랐습니다. ExploitGym 평가 중이던 모델들이 패키지 레지스트리 캐시 프록시의 알려지지 않은 취약점을 이용해 인터넷 접근 경로를 확보했고, 이후 Hugging Face의 운영 인프라에 접근했습니다. OpenAI는 이를 평가 환경의 격리와 모니터링을 더 강화해야 한다는 신호로 설명했습니다. <a href="https://openai.com/index/hugging-face-model-evaluation-security-incident/">OpenAI의 사건 보고</a></p> <p>이 두 사건을 AI가 통제를 벗어났다는 한 문장으로만 설명하면 중요한 부분을 놓치게 됩니다. 공개된 사실만 보면 목표를 주고 네트워크와 도구를 연결한 평가 시스템에서 격리, 권한, 모니터링이 충분히 작동하지 않았습니다. 특히 Anthropic은 두 조직이 해당 활동을 먼저 발견하지 못했다고 밝혔습니다. 평가 환경 안에서 무슨 일이 일어났는지 운영자가 즉시 볼 수 없었다는 뜻입니다. <a href="https://apnews.com/article/anthropic-ai-models-hack-cybersecurity-b0a2c284b981de79c55e2a33712f4bec">AP의 관련 보도</a></p> <h2 id="로그는-결과가-아니라-행동을-기록해야-한다">로그는 결과가 아니라 행동을 기록해야 한다</h2> <p>이 사건 뒤 r/AI_Agents에서는 에이전트 행동을 샌드박스 바깥의 외부 감사 로그에 기본적으로 남겨야 한다는 논의가 나왔습니다. 글쓴이는 모델이 어떤 명령을 실행했는지, 어떤 시스템에 접근했는지, 어떤 패키지와 계정을 만들었는지, 언제 이상 행동이 시작됐는지를 에이전트가 수정할 수 없는 별도 기록으로 남겨야 한다고 제안했습니다. <a href="https://www.reddit.com/r/AI_Agents/comments/1vbllkk/the_anthropic_claude_broke_into_real_companies/">Reddit 토론 원문</a></p> <p>이 제안은 아직 업계 표준이나 검증된 해결책이 아닙니다. 글쓴이도 자신이 관련 도구를 만들고 있어 편향이 있다고 밝혔습니다. 그럼에도 논점은 분명합니다. 일반적인 애플리케이션 로그가 최종 결과만 남긴다면, 에이전트 시스템에서는 결과에 이르는 행동의 순서와 권한 변화를 함께 보존해야 합니다. 에이전트가 만든 파일이나 공개 패키지에도 어떤 실행 주체가 어떤 권한으로 만들었는지 출처가 남아야 합니다.</p> <h2 id="어떤-행동을-남겨야-하나">어떤 행동을 남겨야 하나</h2> <p>외부 감사 로그를 설계한다면 최소한 다음 정보가 필요합니다.</p> <ul> <li>실행 ID, 모델 버전, 사용한 에이전트 하네스와 평가 버전</li> <li>각 도구 호출의 시각, 대상 시스템, 요청한 작업, 성공·실패 결과</li> <li>네트워크 연결과 외부 전송, 사용한 계정과 권한 범위</li> <li>파일·패키지·코드 변경의 출처와 승인 주체</li> <li>정책 엔진의 허용·승인 필요·차단 판단</li> <li>중단 신호, 재시도, 권한 상승, 예외 처리 기록</li> </ul> <p>여기서 중요한 것은 로그를 많이 쌓는 것이 아닙니다. 나중에 사고를 재현할 수 있을 정도로 연결된 기록을 남기는 것입니다. 모델의 최종 답변만 저장하면 왜 그 도구를 호출했는지 알기 어렵습니다. 반대로 모든 내부 추론을 그대로 저장하려고 하면 개인정보와 비밀정보가 섞이고, 로그 자체가 새로운 보안 위험이 될 수 있습니다. 따라서 원문 전체가 아니라 행동·권한·대상·결과를 중심으로 기록하고, 민감한 입력은 별도의 접근 통제와 보존 정책을 적용하는 편이 현실적입니다.</p> <h2 id="외부-로그만으로는-부족하다">외부 로그만으로는 부족하다</h2> <p>외부 감사 로그가 있어도 침해를 막아주지는 않습니다. 기록을 남기는 동안 에이전트가 운영 데이터베이스를 삭제하거나 비밀키를 외부로 보냈다면 이미 피해가 발생했을 수 있습니다. 로그는 방어선 중 하나이지 권한 설계의 대체물이 아닙니다.</p> <p>기본 방어선은 더 단순해야 합니다. 평가 환경은 기본적으로 외부 네트워크가 차단되어야 하고, 꼭 필요한 연결만 허용 목록으로 열어야 합니다. 에이전트마다 별도의 짧은 수명 자격증명을 발급하고, 읽기와 쓰기 권한을 분리해야 합니다. 운영 데이터와 평가용 데이터를 분리하고, 외부 시스템 변경·비용 발생·비밀정보 접근은 사람의 승인을 거치도록 해야 합니다. 평가 파트너를 사용할 때는 문서상 격리 약속이 아니라 실제 네트워크 경로와 로그를 함께 검증해야 합니다.</p> <p>Anthropic의 보고서도 평가 환경을 일반 운영 시스템과 같은 보안 수준으로 다뤄야 한다는 방향을 제시합니다. 모델이 현실과 시뮬레이션을 잘못 판단할 수 있다면, 모델의 판단에 기대어 안전을 확보해서는 안 됩니다. 시스템이 직접 범위를 강제하고, 외부 기록이 실제 행동을 증명해야 합니다.</p> <h2 id="에이전트는-모델이-아니라-실행-주체다">에이전트는 모델이 아니라 실행 주체다</h2> <p>챗봇의 답변은 틀리더라도 사람이 결과를 복사하고 실행하는 단계가 남아 있습니다. 하지만 에이전트가 파일을 수정하고, 패키지를 게시하고, 계정과 네트워크를 사용하는 순간부터는 다릅니다. 에이전트는 모델 출력기가 아니라 권한을 가진 실행 주체가 됩니다.</p> <p>그래서 에이전트의 기본 구성에는 모델과 프롬프트만 있어서는 안 됩니다. 권한 경계, 도구별 승인 정책, 네트워크 격리, 중단 장치, 그리고 외부에서 검증 가능한 행동 기록이 함께 있어야 합니다. 이 중 하나라도 빠지면 사고가 발생한 뒤에야 무엇이 일어났는지 추측하게 됩니다.</p> <p>저는 앞으로 AI 에이전트를 붙일 때 먼저 성능보다 다음 질문을 확인하려고 합니다. 이 에이전트는 무엇을 할 수 있는가보다, 무엇을 할 수 없도록 되어 있는가. 그리고 문제가 생겼을 때 누가, 언제, 어떤 기록을 보고 멈출 수 있는가.</p> <p>자율성이 커질수록 신뢰는 모델의 의도에 기대서 만들 수 없습니다. 에이전트가 실제로 한 행동을 외부에서 확인하고 되돌릴 수 있는 구조를 만드는 것, 그것이 에이전트 시대의 가장 기본적인 운영 조건에 가까워지고 있습니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/ai-agent-permissions-over-process/https://jakob-ai-notes.pages.dev/ko/posts/ai-agent-permissions-over-process/최근 사이버보안 평가 사건은 에이전트의 안전성이 프롬프트나 모델 성능보다 권한 경계와 실행 환경에 달려 있음을 보여줍니다.Mon, 03 Aug 2026 00:00:00 GMT<p>최근 OpenAI와 Anthropic의 사이버보안 평가 사건은 “AI가 통제를 벗어났다”는 이야기로 쉽게 소비됩니다. 하지만 더 유용한 질문은 좁습니다. 평가 환경이 모델에게 어떤 권한을 줬고, 어떤 경계가 작동하지 않았을까요?</p> <p>두 시스템은 모델에게 목표를 주고, 목표를 달성하는 데 사용할 수 있는 인터넷·계정·도구를 연결했습니다. 공개 보고서는 해당 평가에서 일어난 일을 설명하지만, 모든 에이전트가 실제 운영 환경에서 같은 방식으로 행동한다고 증명하지는 않습니다. 대신 프롬프트가 권한 시스템이 될 수 없는 이유는 보여줍니다.</p> <p>“인터넷에 접근하지 마라”라고 프롬프트에 적는 것과 실제로 네트워크 접근을 차단하는 것은 전혀 다릅니다. 에이전트의 안전성은 모델뿐 아니라 네트워크 정책·주체의 신원·도구 권한·로그·승인 관문·중단 장치가 포함된 실행 환경에서 결정됩니다.</p> <h2 id="사건의-공통점은-권한-문제입니다">사건의 공통점은 권한 문제입니다</h2> <p>에이전트가 행동하려면 적어도 목표·능력·경계가 필요합니다. 목표는 무엇을 이루려는지 말하고, 능력은 어떤 시스템과 도구에 닿을 수 있는지 정합니다. 경계는 무엇을 하면 안 되는지, 언제 물어야 하는지, 실행이 어떻게 끝나는지를 정합니다.</p> <table> <thead> <tr> <th>층위</th> <th>답해야 할 질문</th> <th>흔한 실패</th> </tr> </thead> <tbody> <tr> <td>목표</td> <td>에이전트가 책임질 결과는 무엇인가?</td> <td>넓은 목표가 임의 행동의 허가로 바뀝니다.</td> </tr> <tr> <td>능력</td> <td>필요한 계정·파일·네트워크·도구는 무엇인가?</td> <td>작업보다 많은 시스템에 접근할 수 있습니다.</td> </tr> <tr> <td>경계</td> <td>승인·시간 제한·강제 중단이 필요한 지점은 어디인가?</td> <td>프롬프트의 경고가 실제 행동을 막아줄 것으로 기대합니다.</td> </tr> <tr> <td>증거</td> <td>무슨 일이 있었는지 어떤 기록이 보여주는가?</td> <td>최종 답변 뒤에 도구 호출과 상태 변경이 숨습니다.</td> </tr> </tbody> </table> <p><img src="/images/anthropic-security-evaluation.png" alt="Anthropic 공식 사이버보안 평가 페이지의 관련 이미지"></p> <p><em>공개된 평가 보고서는 실행 환경도 안전성 논의의 일부로 만듭니다. 출처: <a href="https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals">Anthropic</a></em></p> <p>보고서에서 얻을 실무 교훈은 모델을 무조건 더 똑똑하게 만드는 것이 정답은 아니라는 점입니다. 더 좁은 네트워크 범위, 별도 신원, 읽기 전용 도구, 승인 단계, 불완전한 산출물을 거부하는 검증기가 더 직접적인 해법일 수 있습니다.</p> <h2 id="복잡한-하네스가-항상-좋은-것은-아닙니다">복잡한 하네스가 항상 좋은 것은 아닙니다</h2> <p>저는 하네스와 루프 엔지니어링 방식을 적용해보면서 비슷한 문제를 느꼈습니다. 계획을 세우고, 일을 나누고, 여러 에이전트에게 위임하고, 결과를 검토하고, 실패하면 재시도하고, 중간 결과를 요약하는 과정은 각각 그럴듯했습니다. 하지만 기능을 하나씩 붙이자 실제 작업보다 프로세스가 더 커졌습니다.</p> <p>시간과 토큰을 계속 빨아먹는 하마처럼 느껴질 때도 있었습니다.</p> <p><img src="/images/anthropic-ai-evaluation-news.jpg" alt="Anthropic 관련 AP 뉴스 이미지"></p> <p><em>AP 보도는 사건의 맥락을 보여주지만, 1차 평가 기록을 대신하지는 않습니다. 출처: <a href="https://apnews.com/article/anthropic-ai-models-hack-cybersecurity-b0a2c284b981de79c55e2a33712f4bec">AP News</a></em></p> <p>그래서 지금은 대부분의 과정을 걷어내고 제 작업에 맞는 간단한 하네스를 실험하고 있습니다. 이것은 통제된 생산성 실험의 결과가 아니라 설계 판단입니다. 단순한 하네스도 넓은 자격증명을 노출하거나 중단 조건이 없으면 더 쉽게 운영되는 만큼 더 쉽게 오용될 수 있습니다.</p> <h2 id="작은-하네스도-반드시-분명히-해야-할-것">작은 하네스도 반드시 분명히 해야 할 것</h2> <p>플래너나 리뷰어를 하나 더 붙이기 전에 먼저 권한 경계를 확인해야 합니다.</p> <ul> <li>각 도구가 이번 작업에 필요한 파일·서비스·네트워크만 볼 수 있는가?</li> <li>권한을 철회할 수 있는 별도 신원을 사용하는가?</li> <li>외부 변경과 되돌리기 어려운 동작을 사람 승인 뒤에 두었는가?</li> <li>시간·재시도·토큰 예산이 숨지 않고 보이는가?</li> <li>요청·도구 호출·결과·변경 산출물을 검토자가 확인할 수 있는가?</li> <li>실패할 때 접근 권한을 넓히지 않고 제한된 오류를 반환하는가?</li> </ul> <p>그래서 에이전트 설계는 조직 설계보다 권한 설계에 가깝다고 생각합니다. 인간 조직은 큰 사회적 시스템 안에서 협업하기 때문에 역할이 필요합니다. 작은 에이전트 작업에는 실제 통제나 증거 경계를 만드는 역할만 있으면 됩니다. 인간 조직에 존재하는 역할을 그대로 붙인다고 안전해지는 것은 아닙니다.</p> <h2 id="권한을-작게-설계하는-순서">권한을 작게 설계하는 순서</h2> <p>권한 경계를 실제 작업에 적용할 때는 에이전트에게 한 번에 “작업 전체”를 맡기지 않는 편이 설명하기 쉽습니다. 예를 들어 저장소의 버그를 고치는 작업이라면 다음처럼 단계를 나눌 수 있습니다.</p> <table> <thead> <tr> <th>단계</th> <th>허용하는 권한</th> <th>남겨야 할 증거</th> </tr> </thead> <tbody> <tr> <td>조사</td> <td>관련 파일 읽기와 테스트 실행</td> <td>읽은 범위, 실행한 명령, 테스트 결과</td> </tr> <tr> <td>제안</td> <td>변경 계획과 패치 초안 작성</td> <td>바뀔 파일, 변경 이유, 예상 영향</td> </tr> <tr> <td>승인</td> <td>사람의 확인을 받은 변경만 적용</td> <td>승인자, 승인 시각, 승인된 범위</td> </tr> <tr> <td>검증</td> <td>제한된 환경에서 테스트·검사 실행</td> <td>로그, 생성된 산출물, 실패 원인</td> </tr> <tr> <td>종료</td> <td>자격증명 회수와 임시 파일 정리</td> <td>권한 회수 여부, 최종 상태</td> </tr> </tbody> </table> <p>이 흐름에서 에이전트는 먼저 읽을 수 있지만 바로 외부 시스템에 쓰지는 못합니다. 네트워크가 필요하지 않은 단계에서는 네트워크를 차단하고, 배포나 데이터 변경처럼 되돌리기 어려운 행동에는 별도의 승인 토큰을 요구할 수 있습니다. 승인 토큰도 작업·시간·대상에 묶어야 하며, “이번 세션 동안 모든 작업 허용”처럼 넓게 발급하면 처음 세운 경계가 다시 사라집니다.</p> <p>실패 처리도 권한 설계의 일부입니다. 테스트가 실패했을 때 에이전트가 자동으로 더 많은 파일이나 서비스를 열어 달라고 요청하는 대신, 현재 범위에서 실패 이유와 사람이 확인할 질문을 반환하도록 해야 합니다. 그러면 재시도 횟수는 늘어도 권한 범위가 조용히 커지지는 않습니다. 이 예시는 보편적인 구현 정답이나 생산성 측정 결과가 아니라, 권한을 프로세스보다 먼저 검토하기 위한 설계 단위입니다.</p> <h2 id="이-글이-증명하지-않는-것">이 글이 증명하지 않는 것</h2> <p>인용한 사건은 각자의 목표·도구·조건을 가진 평가 환경에서 일어났습니다. 그 수치를 개발자나 모델이 일상 업무에서 같은 비율로 실패한다는 주장으로 옮겨서는 안 됩니다. 제가 단순화한 하네스가 오케스트레이션이 나쁘다는 증거도 아닙니다. 확인 가능한 결론은 더 실용적입니다. 프로세스를 최적화하기 전에 권한을 먼저 정해야 합니다.</p> <p>작은 목표, 제한된 권한, 짧은 피드백 루프, 명확한 중단 지점이 아무도 안전 이유를 설명할 수 없는 복잡한 워크플로보다 좋은 출발점입니다. 에이전트가 강해질수록 물어야 할 것은 무엇을 할 수 있는지만이 아닙니다. 어떤 행동을 허가받았고, 멈춘 뒤 어떤 증거가 남는지도 물어야 합니다.</p> <p><a href="https://openai.com/index/hugging-face-model-evaluation-security-incident/">OpenAI 보안 사고 보고</a> · <a href="https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals">Anthropic 평가 사고 조사</a></p> https://jakob-ai-notes.pages.dev/ko/posts/eu-ai-act-global-regulation-outlook/https://jakob-ai-notes.pages.dev/ko/posts/eu-ai-act-global-regulation-outlook/EU AI Act의 시행 변화와 미국·한국의 대응 전망, EU 대상 AI 서비스 배포를 준비하는 개발자 체크리스트를 정리했습니다.Sun, 02 Aug 2026 00:00:00 GMT<p>EU AI Act를 둘러싼 최근 변화를 보면서 제가 주목하는 점은 유럽이 AI 산업을 막으려 한다는 사실보다, AI를 시장에 내놓는 방식 자체가 제품 설계의 일부가 되고 있다는 점입니다.</p> <p>2026년 8월 2일 기준으로 EU AI Act의 대부분 규정은 적용·집행 단계에 들어갔습니다. 다만 고위험 AI 규정은 2027년 12월, 물리적 제품에 내장된 고위험 AI는 2028년 8월까지 일정이 연장됐습니다. 따라서 모든 AI 서비스가 당장 고위험 규제를 받는 것은 아닙니다. <a href="https://ai-act-service-desk.ec.europa.eu/en/ai-act/eu-ai-act-implementation-timeline">EU AI Act 시행 일정</a></p> <p>가장 먼저 개발자가 체감하게 될 변화는 투명성입니다. 사용자가 AI와 대화하고 있다는 사실을 알려야 하고, AI가 생성한 이미지·음성·영상·텍스트는 기술적으로 식별 가능한 방식으로 표시해야 합니다. 딥페이크나 공익 관련 정보를 전달하는 AI 생성 텍스트도 별도 고지가 필요할 수 있습니다. <a href="https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50">EU AI Act 제50조</a></p> <h2 id="미국은-eu를-그대로-따라가지-않을-가능성이-높습니다">미국은 EU를 그대로 따라가지 않을 가능성이 높습니다</h2> <p>제 전망으로는 미국이 EU AI Act를 그대로 복제하지는 않을 것 같습니다. 현재 미국 정부는 주별로 서로 다른 AI 규제가 생기는 것을 막고, 연방 차원의 일관된 정책을 만들자는 방향을 제시하고 있습니다. 동시에 AI 모델 출시 전 정부 허가나 일괄적인 사전심사를 의무화하는 방식에는 거리를 두고 있습니다. <a href="https://www.whitehouse.gov/releases/2026/03/president-donald-j-trump-unveils-national-ai-legislative-framework/">미국 국가 AI 입법 프레임워크</a>, <a href="https://www.whitehouse.gov/presidential-actions/2026/06/promoting-advanced-artificial-intelligence-innovation-and-security/">미국 AI 혁신·보안 행정명령</a></p> <p>미국은 규제를 없애기보다 규제의 위치를 바꿀 가능성이 큽니다. 모델을 출시하기 전에 일률적으로 허가하는 방식보다는 사이버보안, 중요 인프라, 정부 조달, 국가안보와 연결된 영역에서 보안 기준과 책임을 강화하는 방식입니다.</p> <p>결국 미국에서는 “이 모델을 출시해도 되는가”보다 “이 모델을 얼마나 안전하게 운영하고, 사고가 났을 때 누가 책임지는가”가 더 중요한 질문이 될 가능성이 높습니다. 자율적인 보안 기준과 벤치마크가 법적 의무는 아니더라도, 대기업·정부·클라우드 시장에서는 사실상의 참여 조건이 될 수 있습니다.</p> <h2 id="한국은-eu와-미국-사이에서-혼합형으로-갈-것입니다">한국은 EU와 미국 사이에서 혼합형으로 갈 것입니다</h2> <p>한국은 EU식 투명성과 안전 규정을 받아들이면서도, 미국식 산업 육성 정책을 함께 가져가는 방향으로 움직일 가능성이 높습니다.</p> <p>한국의 인공지능기본법은 2026년 1월 22일부터 시행됐고, 고영향 AI, 생성형 AI 투명성, 안전성, 산업 지원, 국제협력 등을 함께 다루고 있습니다. 정부는 기업의 적응을 위해 최소 1년 이상의 유예와 상담·지원 체계를 운영하겠다는 입장도 밝혔습니다. <a href="https://www.korea.kr/news/policyNewsView.do?newsId=148958380">인공지능기본법 시행 관련 정부 설명</a>, <a href="https://www.korea.kr/news/policyNewsView.do?newsId=148958460">인공지능기본법 시행령 및 지원정책</a></p> <p>그래서 한국이 단순히 “EU를 따라간다”고 보기는 어렵습니다. 제 생각에는 제도 문구와 사용자 보호 기준은 EU와 점점 비슷해지고, 실제 집행 방식은 국내 산업 육성·지원 정책과 결합될 가능성이 큽니다.</p> <p>특히 해외 진출을 염두에 둔 한국 기업이라면 EU의 투명성 기준을 무시하기 어렵습니다. 반면 국내에서는 기업의 부담을 줄이기 위한 유예, 가이드라인, 컨설팅이 함께 제공될 가능성이 높습니다. 한국은 EU의 규제 호환성과 미국의 기술 경쟁력 사이에서 균형을 잡으려 할 것입니다.</p> <h2 id="eu에-ai-서비스를-배포하려는-개발자가-검토할-사항">EU에 AI 서비스를 배포하려는 개발자가 검토할 사항</h2> <p>첫째, 내가 단순한 AI 이용자인지, AI 시스템 제공자인지, 실제 서비스를 운영하는 배포자인지 구분해야 합니다. 자체 모델을 만드는지, 외부 모델 API를 연결하는지, 다른 기업의 제품에 AI 기능을 납품하는지에 따라 책임과 준비사항이 달라질 수 있습니다.</p> <p>둘째, 모델 이름보다 사용 목적과 적용 분야를 먼저 분류해야 합니다. 같은 언어 모델이라도 단순한 문서 요약에 쓰는 경우와 채용, 교육, 금융, 의료, 공공서비스에 쓰는 경우의 위험도는 다릅니다. 고위험 AI 여부는 모델 자체보다 의도된 목적과 실제 사용 맥락을 기준으로 검토해야 합니다. <a href="https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai">EU AI 규제 체계</a></p> <p>셋째, 투명성 기능을 출시 직전에 붙이지 말고 처음부터 제품에 넣어야 합니다.</p> <ul> <li>사용자가 AI와 대화하고 있다는 안내</li> <li>AI 생성 콘텐츠의 기계 판독 가능한 표시</li> <li>딥페이크와 합성 콘텐츠에 대한 고지</li> <li>AI가 생성한 공익 관련 텍스트의 표시</li> <li>감정인식·생체정보 분류 기능 사용 시 대상자 안내</li> </ul> <p>특히 이미지나 영상에 표시를 넣더라도 다른 플랫폼으로 공유되는 과정에서 메타데이터가 사라질 수 있습니다. 따라서 표시 정보가 다운로드, 편집, API 재가공 이후에도 유지되는지 확인해야 합니다.</p> <p>넷째, 모델과 출력물에 대한 운영 기록을 남겨야 합니다. 어떤 모델 버전을 사용했는지, 언제 변경했는지, 어떤 안전 필터와 외부 도구를 연결했는지, 문제가 발생했을 때 어떻게 중단하고 복구했는지를 추적할 수 있어야 합니다. 법무 대응을 위한 기록이기도 하지만, 실제로는 장애와 오작동을 빠르게 분석하기 위한 운영 장치입니다.</p> <p>다섯째, 외부 모델 제공업체와의 계약을 확인해야 합니다. 데이터가 어느 지역에서 처리되는지, 입력 데이터가 학습에 사용되는지, 모델이 예고 없이 변경될 수 있는지, 사고가 발생했을 때 통지와 책임 범위가 어떻게 되는지 확인해야 합니다. AI 서비스는 모델 API 하나를 연결했다고 끝나는 것이 아니라, 공급망 전체를 검토해야 하는 제품이 되고 있습니다.</p> <p>여섯째, EU용 기능을 별도 임시 패치로 만들지 않는 것이 좋습니다. 저는 한국 개발자라면 글로벌 제품의 기본선 자체를 높이고, 국가별로 표시 방식·로그 보관·사용자 고지·차단 정책을 설정값으로 분리하는 방식이 가장 현실적이라고 봅니다. EU 전용 코드를 따로 만드는 것보다, 처음부터 변경 가능한 컴플라이언스 계층을 제품 구조에 넣는 편이 장기적으로 비용이 적게 듭니다.</p> <h2 id="결국-규제보다-중요한-것은-제품의-기본값입니다">결국 규제보다 중요한 것은 제품의 기본값입니다</h2> <p>앞으로 AI 규제는 하나의 세계 표준으로 통일되기보다는 지역별로 강조점이 달라질 가능성이 높습니다.</p> <p>EU는 투명성·기본권·사용자 고지를 중심으로 움직이고, 미국은 혁신·보안·국가 경쟁력을 중심으로 움직일 것입니다. 한국은 두 방향을 모두 반영하면서 산업 지원과 해외시장 호환성을 동시에 추구할 가능성이 큽니다.</p> <p>그래서 개발자에게 가장 중요한 전략은 특정 법률에 맞춘 일회성 대응이 아니라, 어느 시장에도 적용할 수 있는 기본 운영체계를 만드는 것입니다.</p> <p>사용자에게 AI 사용 사실을 알리고, 생성 결과를 식별할 수 있게 하며, 모델과 데이터의 변화를 기록하고, 문제가 생기면 사람이 개입하거나 서비스를 중단할 수 있어야 합니다.</p> <p>제 생각에 EU AI Act의 가장 큰 영향은 벌금 자체가 아닙니다. AI를 “기능 하나”가 아니라 설명 가능하고, 추적 가능하며, 통제 가능한 제품으로 만들어야 한다는 시장의 기준을 세웠다는 점입니다. 앞으로는 EU가 규제를 수출하고, 미국이 보안과 인프라 기준을 수출하며, 한국은 그 둘 사이에서 호환성을 만들어내는 방향으로 갈 가능성이 높습니다.</p> <p>※ 이 글은 정책 전망과 실무 체크리스트를 정리한 의견이며, 실제 EU 배포 전에는 적용 국가와 제품 유형에 맞춘 법률 검토가 필요합니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/open-source-does-not-license-data/https://jakob-ai-notes.pages.dev/ko/posts/open-source-does-not-license-data/K-skill과 블루리본 논란을 통해 오픈소스 라이선스와 외부 데이터 사용 권한의 차이, 바이브 코딩 시대의 개발 책임을 살펴봅니다.Sat, 01 Aug 2026 15:03:00 GMT<p>최근 국내 개발자 커뮤니티에서 K-skill과 블루리본서베이를 둘러싼 논란이 커지고 있습니다.</p> <p>K-skill은 한국에서 자주 사용하는 여러 서비스를 AI 에이전트가 이용할 수 있도록 연결한 오픈소스 프로젝트입니다. 현재 GitHub에서 6천 개가 넘는 스타를 받을 만큼 많은 관심을 모았습니다. 하지만 프로젝트에 포함됐던 블루리본 맛집 검색 기능이 유료 데이터를 외부에 다시 제공하고, 서비스의 자동화 접근 차단을 우회하려 했다는 지적이 나오면서 문제가 시작됐습니다.</p> <p>개발자는 이후 관련 기능의 운영을 중단하고 저장소에서도 제외했으며, 현재 진행 중인 법적 절차에 대해서는 변호사의 도움을 받아 소명하겠다고 밝혔습니다.</p> <p>아직 법원의 판단이나 블루리본 측의 공식 입장이 공개된 것은 아닙니다. 따라서 현재 단계에서 저작권 침해나 부정경쟁행위가 확정됐다고 단정해서는 안 됩니다. 하지만 공개 저장소에 남은 개발 기록만으로도 이번 사건이 왜 많은 사람에게 충격을 주었는지는 충분히 살펴볼 수 있습니다.</p> <h2 id="mit-라이선스는-다른-회사의-데이터-사용-허가서가-아니다">MIT 라이선스는 다른 회사의 데이터 사용 허가서가 아니다</h2> <p>K-skill 저장소의 기본 라이선스는 MIT이며, 프록시 서버 일부에는 AGPL이 적용됩니다. 여기서 가장 먼저 구분해야 할 것이 있습니다.</p> <p>이 라이선스들은 K-skill에 작성된 코드의 복제·수정·배포 조건을 정합니다. 블루리본의 데이터, 유료 회원 계정, 서버 API, 브랜드를 사용할 권리까지 제공하지는 않습니다.</p> <p>프로젝트에 MIT 라이선스를 붙였다고 해서 프로젝트가 접근하는 모든 외부 데이터까지 오픈소스가 되는 것은 아닙니다. 인터넷에서 브라우저로 볼 수 있다는 사실도 자유롭게 수집하고 재배포할 수 있다는 뜻은 아닙니다.</p> <p>우리는 다음 네 가지를 자주 혼동합니다.</p> <ul> <li>공개적으로 접속 가능한 정보</li> <li>오픈데이터로 배포된 정보</li> <li>오픈소스 라이선스가 적용된 코드</li> <li>자동 수집과 재배포가 허용된 정보</li> </ul> <p>이것들은 전혀 다른 개념입니다.</p> <p>외부 서비스를 연결하는 프로그램을 만들 때는 코드 라이선스만 볼 것이 아니라 서비스 이용약관, 공식 API 정책, 데이터베이스 권리, 상표 사용, 개인정보, 자동화 접근 제한을 각각 확인해야 합니다.</p> <h2 id="논란이-커진-결정적인-이유">논란이 커진 결정적인 이유</h2> <p>K-skill 저장소의 과거 코드에는 블루리본 프리미엄 계정의 세션 ID를 프록시 서버 환경변수로 보관하고, 이를 사용해 주변 맛집 데이터를 조회하는 구조가 남아 있습니다. 블루리본의 공식 안내에서도 주변 맛집 기능은 프리미엄 콘텐츠로 소개됐습니다.</p> <p>더 큰 논란을 만든 것은 차단 이후의 대응입니다.</p> <p>블루리본 서버가 자동화 요청에 403 응답을 반환하자, 프로젝트에는 일반 브라우저처럼 보이도록 자동화 흔적을 숨기는 기능이 추가됐습니다. 해당 PR 설명에는 <code>navigator.webdriver</code> 제거, 브라우저 정보 위장, 지문 변경 등 봇 탐지를 피하기 위한 방법이 구체적으로 적혀 있습니다.</p> <p>단순히 공개 페이지를 읽어 본 것과, 서비스 운영자의 차단 의사를 인식한 뒤 그 차단을 기술적으로 우회하는 것은 전혀 다른 문제입니다.</p> <p>법적 판단은 구체적인 이용약관, 데이터의 성격, 수집 범위와 반복성, 영업적 이용 여부 등을 종합해 내려져야 합니다. 그러나 개발 윤리의 관점에서는 403이나 계정 차단을 단순한 기술적 장애물로만 취급해서는 안 됩니다. 그것은 서비스 운영자가 자동화 접근을 원하지 않는다는 명확한 신호일 수 있습니다.</p> <h2 id="사람들의-반응이-갈린-이유">사람들의 반응이 갈린 이유</h2> <p>커뮤니티에서 확인한 반응은 크게 세 방향으로 나뉘었습니다.</p> <p>첫 번째는 강한 비판입니다. 유료 데이터에 접근하기 위해 결제한 계정의 세션을 프록시로 공유하고, 차단 이후 우회 방법까지 병합한 것은 ‘좋은 의도의 오픈소스 실험’이라는 설명으로 넘어가기 어렵다는 반응입니다. 코드가 공개됐다는 사실과 외부 데이터의 사용 권한을 혼동했다는 지적도 많았습니다.</p> <p>두 번째는 개발자 개인에 대한 과도한 공격을 우려하는 반응입니다. 개인적인 실험으로 시작한 프로젝트가 예상보다 빠르게 성장하는 과정에서 운영 기준을 갖추지 못한 실수일 수 있으며, 공개적인 조롱이나 신상 공격보다는 문제를 수정할 기회를 줘야 한다는 의견입니다.</p> <p>세 번째는 이 사건을 한 개발자의 실수로만 볼 수 없다는 반응입니다. AI 에이전트가 실제 서비스에 접속하고 행동하는 시대에는 비슷한 문제가 계속 발생할 것이므로, 프로젝트 차원의 데이터 출처와 권한 검토 절차가 필요하다는 주장입니다.</p> <p>저 역시 세 번째 관점에 가깝습니다. 개인에 대한 비난보다 중요한 것은 왜 이런 기능이 별다른 제동 없이 만들어지고 공개되고 확산될 수 있었는지를 살펴보는 일입니다.</p> <h2 id="바이브-코딩이-확대시킨-책임의-공백">바이브 코딩이 확대시킨 책임의 공백</h2> <p>이번 사건은 무분별한 바이브 코딩이 만들 수 있는 한 가지 폐해처럼 보입니다.</p> <p>AI는 웹사이트의 숨겨진 요청 구조를 찾고, 비공식 API를 호출하는 코드를 만들고, 프록시 서버와 브라우저 자동화까지 연결하는 작업을 매우 빠르게 해줍니다. 과거라면 며칠이 걸렸을 기능이 몇 시간 만에 완성될 수 있습니다.</p> <p>문제는 구현 속도만 빨라졌을 뿐 검토 속도는 빨라지지 않았다는 점입니다.</p> <p>AI는 “이 코드를 만들 수 있는가”에는 쉽게 답하지만, “이 데이터를 사용할 권리가 있는가”, “서비스가 차단했는데 계속 접근해도 되는가”, “이 기능을 수천 명에게 배포했을 때 누가 책임지는가”까지 대신 판단해 주지 않습니다.</p> <p>바이브 코딩 자체가 문제는 아닙니다. 사람이 직접 코드를 작성했어도 같은 일은 생길 수 있습니다. 그러나 AI는 한 명의 개발자가 감당할 수 있는 기능과 서비스의 범위를 급격히 넓힙니다. 그만큼 잘못된 판단도 빠르게 제품화되고 여러 사용자에게 확산됩니다.</p> <p>코드 생성 비용이 낮아질수록 검토와 책임의 비용은 오히려 높아져야 합니다.</p> <h2 id="앞으로-프로젝트와-기업은-어떻게-움직일까">앞으로 프로젝트와 기업은 어떻게 움직일까</h2> <p>K-skill은 이미 저장소의 여러 기능을 대상으로 데이터 출처, 접근 방식, 이용약관, 상표 사용을 다시 검토하기 시작했습니다. 60개가 넘는 법적 검토 이슈가 등록된 것은 이번 문제가 블루리본 기능 하나에 그치지 않을 가능성을 프로젝트 측도 인식했다는 의미로 볼 수 있습니다.</p> <p>앞으로 오픈소스 AI 에이전트 프로젝트에는 다음과 같은 기준이 필요해질 것입니다.</p> <ul> <li>기능마다 데이터 출처와 공식 API 여부를 명시한다.</li> <li>유료 계정이나 세션을 공용 프록시에서 재사용하지 않는다.</li> <li>공식 API가 없다면 자동 수집 허용 여부를 먼저 확인한다.</li> <li>401·403·캡차·기기 차단을 우회 대상으로 취급하지 않는다.</li> <li>라이선스뿐 아니라 이용약관과 데이터 권리 검토 결과를 남긴다.</li> <li>문제가 생기면 즉시 중단할 수 있는 기능별 종료 장치를 둔다.</li> <li>외부 서비스의 이름과 로고를 사용할 때 공식 제휴로 오인되지 않게 한다.</li> </ul> <p>기업들의 대응도 강화될 가능성이 높습니다. 자동화 요청에 대한 속도 제한과 봇 차단, 계정과 기기 단위 제한, 비공식 API 변경이 늘어날 수 있습니다. 이용약관에 AI 에이전트, 크롤링, 데이터 재판매에 관한 조건을 더 명확히 넣는 기업도 많아질 것입니다.</p> <p>반대로 모든 자동화를 막는 것만이 좋은 해결책은 아닙니다. AI 에이전트가 새로운 사용자 인터페이스로 자리 잡는다면, 기업들도 제한된 공식 API와 제휴 프로그램을 제공하는 방향을 검토해야 합니다. 데이터 사용 범위와 호출량, 표시 방법, 수익 배분을 계약으로 정할 수 있기 때문입니다.</p> <h2 id="오픈소스의-자유는-타인의-권리를-지우지-않는다">오픈소스의 자유는 타인의 권리를 지우지 않는다</h2> <p>오픈소스는 코드를 자유롭게 공유하고 함께 발전시키기 위한 약속입니다. 다른 회사가 시간과 비용을 들여 만든 데이터까지 자유롭게 가져다 쓸 수 있다는 선언이 아닙니다.</p> <p>이번 사건에서 우리가 배워야 할 것은 “크롤링은 무조건 불법이다”라는 단순한 결론도, “인터넷에 공개됐으니 써도 된다”는 낙관도 아닙니다.</p> <p>AI가 코드를 작성해 주는 시대일수록 개발자의 역할은 줄어들지 않습니다. 오히려 무엇을 만들지, 어디까지 연결할지, 언제 멈출지를 판단하는 책임은 더 커집니다.</p> <p>이번 논란이 한 개발자를 공격하고 잊히는 사건으로 끝나지 않았으면 합니다. 국내 오픈소스와 AI 개발 문화가 코드 라이선스를 넘어 데이터 출처와 서비스 권한까지 함께 검토하는 계기가 되어야 합니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/openai-gpt-5-6-price-cut/https://jakob-ai-notes.pages.dev/ko/posts/openai-gpt-5-6-price-cut/OpenAI가 GPT-5.6 Luna와 Terra의 API 가격을 낮췄습니다. 달라진 가격과 개발자들의 반응, 그리고 이 변화가 향하는 곳에 대한 생각을 정리했습니다.Sat, 01 Aug 2026 14:22:00 GMT<p>OpenAI가 GPT-5.6의 가격을 출시 3주 만에 다시 손봤습니다. 2026년 7월 30일부터 가장 저렴한 모델인 <strong>GPT-5.6 Luna의 API 가격은 80%</strong>, 균형형 모델인 <strong>GPT-5.6 Terra는 20%</strong> 낮아졌습니다. 최고 성능 모델인 Sol의 표준 가격은 그대로입니다.</p> <p>가격표만 보면 단순한 할인 소식처럼 보입니다. 하지만 Luna의 가격이 한 번에 5분의 1로 내려갔다는 점, 그리고 OpenAI가 그 이유를 모델·추론 시스템·에이전트 실행 환경의 효율 개선으로 설명했다는 점은 조금 더 살펴볼 만합니다.</p> <h2 id="무엇이-얼마나-저렴해졌나">무엇이 얼마나 저렴해졌나</h2> <p>API 기준으로 Luna는 입력 100만 토큰당 1달러에서 0.20달러, 출력은 6달러에서 1.20달러로 낮아졌습니다. Terra는 입력 2.50달러에서 2달러, 출력 15달러에서 12달러가 됐습니다. Sol은 입력 5달러, 출력 30달러로 동일합니다.</p> <p><img src="/images/gpt-5-6-price-cut-chart.svg" alt="GPT-5.6 Sol, Terra, Luna의 가격 인하 전후 비교 차트"></p> <p><em>단위는 API 텍스트 토큰 100만 개당 달러입니다. Sol의 Standard 가격은 변하지 않았습니다.</em></p> <p>ChatGPT와 Codex의 구독료나 전체 한도 자체가 바뀐 것은 아닙니다. 대신 유료 구독에서 Terra와 Luna를 사용할 때 차감되는 크레딧이 줄어듭니다. 개발자에게는 같은 예산으로 더 많은 요청을 처리할 수 있다는 뜻이고, 구독 사용자에게는 같은 작업을 더 오래 이어갈 수 있다는 의미에 가깝습니다.</p> <h2 id="개발자들은-곧바로-사용처를-계산하기-시작했다">개발자들은 곧바로 사용처를 계산하기 시작했다</h2> <p>커뮤니티의 첫 반응은 상당히 긍정적입니다. r/OpenAI와 r/codex의 토론에서는 요약이나 분류처럼 요청량이 많은 작업을 GPT-5.4 Nano·Mini에서 Luna로 옮겨보겠다는 반응이 이어졌습니다. Luna를 이미 일상적인 코딩이나 백그라운드 에이전트의 작업 모델로 쓰고 있었다는 사용자들은 이번 인하로 활용 범위가 더 넓어졌다고 평가했습니다.</p> <p>특히 반복 작업에는 큰 변화입니다. 계획 수립이나 어려운 판단은 Sol 같은 상위 모델에 맡기고, 명확하게 정의된 구현·테스트·요약은 Luna에 맡기는 식의 모델 분업이 훨씬 현실적인 비용으로 가능해졌기 때문입니다.</p> <p>반면 신중한 반응도 있습니다. 가격 인하 뒤에도 성능이 동일하게 유지되는지, 사용량이 몰렸을 때 처리 용량이 충분한지 확인해야 한다는 의견이 있습니다. 80%라는 큰 폭의 인하가 순수한 효율 개선인지, 경쟁 모델에 대응하거나 Luna 사용량을 늘리기 위한 전략인지 의심하는 시선도 보입니다.</p> <p>이 반응들은 정식 조사 결과가 아니라 초기 커뮤니티 의견입니다. 다만 개발자들이 이제 모델의 최고 점수보다 <strong>실제 작업 한 건을 끝내는 비용</strong>을 더 민감하게 비교하고 있다는 흐름은 분명해 보입니다.</p> <h2 id="가격-인하는-생태계를-모으는-가장-강한-방법이다">가격 인하는 생태계를 모으는 가장 강한 방법이다</h2> <p>제 생각에는 OpenAI가 단순히 저렴한 모델 하나를 내놓은 것이 아닙니다. 가격을 낮춰 개발자와 사용자를 더 많이 모으고, 더 다양한 실제 작업이 OpenAI의 모델과 도구 위에서 돌아가게 만드는 움직임에 가깝습니다.</p> <p>개발자가 늘어나면 모델 호출량만 증가하는 것이 아닙니다. 어떤 작업에서 모델이 막히는지, 어떤 도구 연결이 필요한지, 어떤 방식으로 여러 모델을 조합해야 하는지에 대한 실전 노하우가 생깁니다. 여기서 말하는 ‘흡수’는 사용자의 비공개 데이터를 가져간다는 의미가 아니라, 시장에서 검증된 기능과 작업 방식이 OpenAI 제품 안으로 빠르게 통합되는 제품 전략을 뜻합니다.</p> <p>최근 ChatGPT, Codex, API의 경계도 점점 가까워지고 있습니다. 도구 호출, 컴퓨터 사용, 장기 작업, 여러 에이전트의 협업, 외부 서비스 연결처럼 시장에서 논의되던 기능들이 하나의 사용 환경 안으로 모이고 있습니다. OpenAI는 가장 좋은 모델만 만드는 회사보다, 사람들이 AI로 일하는 방식을 통째로 담는 플랫폼이 되려는 것으로 보입니다.</p> <h2 id="진정한-agi를-준비하는-시작일-수-있다">진정한 AGI를 준비하는 시작일 수 있다</h2> <p>저는 이 흐름이 OpenAI가 진정한 AGI를 준비하고 시작하는 과정일 수 있다고 생각합니다. AGI는 벤치마크 점수가 높은 하나의 모델만으로 완성되기 어렵습니다. 다양한 사람들이 실제 문제를 맡기고, AI가 필요한 도구와 맥락을 사용해 결과를 만들며, 그 과정이 반복 가능하고 감당할 수 있는 비용으로 운영돼야 합니다.</p> <p>가격 인하는 바로 그 반복 횟수를 늘립니다. 더 많은 개발자와 사용자가 더 많은 문제를 시도하게 되고, 성공한 기능과 작업 방식은 ChatGPT와 Codex, API 안에서 다시 통합될 수 있습니다. 모델의 지능, 도구, 사람의 노하우가 하나의 환경 안에서 순환하는 구조입니다.</p> <p>물론 가격 인하만으로 AGI에 가까워졌다고 단정할 수는 없습니다. 이번 발표는 어디까지나 비용과 효율에 관한 변화입니다. 다만 OpenAI가 ‘더 강한 모델’만이 아니라 <strong>지능을 더 많은 사람이 실제로 사용하고 개선하는 생태계</strong>를 함께 만들고 있다는 신호로는 읽을 수 있습니다.</p> <p>Luna의 80% 가격 인하는 그 생태계의 입구를 크게 넓힌 사건입니다. 앞으로 주목할 것은 더 낮은 토큰 가격 자체보다, 이 가격 위에서 어떤 도구와 사용 방식이 새롭게 만들어지고 다시 ChatGPT 안으로 들어오는지일 것입니다.</p> https://jakob-ai-notes.pages.dev/ko/posts/building-tools-for-easier-ai/https://jakob-ai-notes.pages.dev/ko/posts/building-tools-for-easier-ai/실제 작업 흐름에 AI를 맞추기 위해 제한된 맥락, 명시적 권한, 검토 가능한 결과를 중심으로 도구를 만들어가는 기록입니다.Sat, 01 Aug 2026 00:00:00 GMT<p>AI를 호출하는 일은 쉽습니다. 실제 작업에 맞게 쓰는 일은 더 어렵습니다.</p> <p>새 모델과 서비스는 계속 등장하고, 어제 어려웠던 일이 오늘은 몇 줄의 대화만으로 가능해집니다. 하지만 기능이 많아질수록 선택도 늘어납니다. 어떤 모델이 작업을 봐야 하는지, 어떤 맥락을 줘야 하는지, 무엇을 바꿀 수 있는지, 결과를 안심하고 이어서 써도 되는지를 함께 판단해야 합니다.</p> <p>이 글은 그런 질문을 탐색하기 위한 출발점입니다. AI를 마법 버튼처럼 보여주기보다 사람이 하던 일을 계속 이어갈 수 있도록 돕는 작은 도구를 만들고 싶습니다. 가장 인상적인 답변보다 중요한 것은 다음 단계의 작업을 사람이 검토하고 실행하기 쉬워지는 것입니다.</p> <h2 id="진짜-문제는-작업에-맞추는-일입니다">진짜 문제는 작업에 맞추는 일입니다</h2> <p>성능 좋은 모델도 불편할 수 있습니다. 매번 같은 배경을 반복해서 설명해야 하거나, 긴 답변에서 쓸 내용을 다시 골라야 하거나, 편리한 연결 하나 때문에 에이전트가 너무 많은 권한을 갖게 될 수 있습니다. 편리함은 화면의 문제가 아니라 맥락·권한·피드백·복구를 함께 설계하는 문제입니다.</p> <p><img src="/images/building-tools-for-easier-ai-context-01.png" alt="사람이 맥락을 준비하고 AI의 제안을 받은 뒤 결과를 검토해 다시 작업으로 이어가는 하나의 흐름을 표현한 일러스트"></p> <p><em>좋은 AI 도구는 중요한 판단을 숨기지 않고 사람을 작업 흐름 안에 남겨둡니다.</em></p> <p>제가 만들고 싶은 도구는 다음 네 가지를 작게라도 잘해야 합니다.</p> <table> <thead> <tr> <th>질문</th> <th>설계 방향</th> </tr> </thead> <tbody> <tr> <td>에이전트는 무엇을 봐야 하는가</td> <td>전체 기록이 아니라 작고 관련성 높은 안전한 맥락만 제공합니다.</td> </tr> <tr> <td>무엇을 바꿀 수 있는가</td> <td>도구를 호출하기 전에 권한과 멈출 지점을 분명히 합니다.</td> </tr> <tr> <td>제대로 작동했는지 어떻게 아는가</td> <td>말이 자연스러운지만 보지 않고 산출물·근거·검증 결과를 확인합니다.</td> </tr> <tr> <td>실패하면 어떻게 되는가</td> <td>제한된 실패를 반환하고 사람이 작업을 복구할 수 있게 합니다.</td> </tr> </tbody> </table> <p>그래서 이후 Luthn과 Drig를 다루면서 처음의 “AI를 더 편하게 만들자”는 생각이 구체적인 경계로 바뀌었습니다. Luthn은 에이전트가 볼 수 있는 안전한 맥락과 보호된 원문을 나눕니다. Drig는 기획·개발 후 QA와 일반 제품 구현의 경계를 나눕니다. 이것이 모든 작업을 더 좋게 만든다는 뜻은 아닙니다. 어떤 부분을 이해하고 개선해야 하는지 보이게 해주는 장치입니다.</p> <h2 id="도구를-만들며-배운-것">도구를 만들며 배운 것</h2> <p>첫째, 자동화가 많다고 편리해지는 것은 아닙니다. 기획·위임·재시도·요약을 길게 연결하면 사람이 확인해야 할 상태가 오히려 늘어납니다. 작은 작업에는 좁은 도구 범위와 짧은 피드백 루프가 더 잘 맞을 때가 있습니다.</p> <p>둘째, 기억에는 권한이 필요합니다. 선호나 프로젝트 결정을 기억하는 일은 유용하지만, 그 기록이 어디에서 왔고 누가 볼 수 있으며 언제 더 이상 유효하지 않은지 설명할 수 있어야 합니다. 메모리 서비스에 연결됐다는 사실만으로 뒤의 모든 기록을 읽을 권한이 생기지는 않습니다.</p> <p>셋째, 하네스는 제품의 일부입니다. 모델·프롬프트·도구·맥락·재시도 정책·검증기가 함께 결과를 만듭니다. 조건이 숨겨져 있으면 성공을 재현하기 어렵고 실패 원인도 찾기 어렵습니다.</p> <p>이 내용은 이 블로그에서 공개한 개발 작업을 바탕으로 한 관찰이지, 통제된 생산성 실험의 결과는 아닙니다. 어떤 구조나 모델이 모든 팀에 이긴다고 주장하지 않습니다. 맥락·권한·근거·복구를 보이게 만들수록 도구가 실제로 더 유용해진다는 좁은 판단입니다.</p> <h2 id="이-블로그에-남길-기록">이 블로그에 남길 기록</h2> <p>앞으로는 완성된 화면만 보여주지 않겠습니다. 근거를 확보할 수 있다면 환경과 시점, 실제로 한 일, 결과, 실패나 예상과 달랐던 점, 결론의 적용 범위를 함께 기록하겠습니다. 근거가 부족하면 출처의 주장이라고 표시하거나 아직 답하지 못한 질문으로 남기겠습니다.</p> <p>AI가 편해지는 이유는 불확실성을 숨겨서가 아니라 주변 작업이 분명해지기 때문이어야 합니다. 도구는 작게 시작하더라도 사람이 확인할 수 있는 결과와 스스로 고를 수 있는 다음 단계를 남겨야 합니다.</p>