AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
벡터 유사도 검색은 의미적으로 비슷한 데이터를 찾아주는 기술로, LSH 같은 방식은 수십 년 전부터 있었지만 최근 LLM에서 나온 임베딩 때문에 규모가 커지면서 다시 주목받고 있다. 현재 나온 벡터 데이터베이스 대부분은 사실 기존 키-값 저장소나 Elasticsearch·OpenSearch 같은 검색 엔진에 HNSW·IVF 같은 벡터 색인 기능을 얹은 형태다. 이런 시스템은 벡터 저장, 색인 생성, 메타데이터 저장, 유사도 검색·필터링 기능을 함께 제공한다. 문제는 원본 데이터가 보통 PostgreSQL이나 MongoDB 같은 일반 데이터베이스에 있고, 벡터는 별도의 벡터DB에 중복 저장된다는 점이다. 이 때문에 두 시스템 간 데이터를 계속 맞춰줘야 하는 동기화 문제, 데이터 일관성 문제, 저장 비용 증가가 발생한다. 또한 별도의 분산 시스템을 하나 더 운영해야 해서 인프라 관리 부담도 커진다.
운영 환경에서 쓸 LLM 게이트웨이를 고를 때 핵심 조건은 자체 호스팅, 여러 제공업체로 요청을 나누는 라우팅, 팀별 비용 추적, 안정적인 관찰 기능, 낮은 유지보수 부담이다. 후보로는 LiteLLM, Portkey, TrueFoundry가 거론된다. LiteLLM은 널리 쓰이는 기본 선택지처럼 보이지만, 버전 업그레이드 때 안정성 문제가 반복해서 언급된다. Portkey는 완성도가 높아 보이지만, 자체 호스팅 지원이 약해 보인다는 평가가 있다. TrueFoundry는 관리와 통제 기능이 필요한 팀에게 자주 언급되지만, 짧은 시험 사용 단계를 넘은 실제 운영 사례는 찾기 어렵다. 핵심 질문은 실제 트래픽을 받는 운영 환경에서 어떤 도구가 버티고 있으며, 처음부터 다시 고른다면 무엇을 선택할지다.
OpenRouter로 DeepSeek V4 Flash를 쓰는 상황에서 토큰을 아끼기 위해 토큰 캐싱을 시도했다. 토큰 캐싱은 반복해서 보내는 입력을 다시 계산하지 않게 해 비용을 줄이는 방식이다. 하지만 실제 사용에서는 캐시되는 양이 거의 없어 절감 효과가 작게 보인다. 핵심 문제는 토큰 캐싱을 어떻게 제대로 설정하는지, 그리고 캐싱이 실제로 작동하는지 어떤 지표로 확인할 수 있는지이다.
Seedream 5.0 Pro를 EvoLink의 이미지 생성 API로 쓸 수 있다. 텍스트로 새 이미지를 만들거나, 기존 이미지와 참고 이미지를 바탕으로 다른 이미지를 만들 수 있다. 자연어 지시로 이미지의 일부를 고치고, 최대 10장의 입력 이미지를 함께 참고해 합성할 수 있다. 제품의 색상이나 재질 변형, 마케팅 이미지, 포스터, 인물 사진, 콘셉트 아트 제작에 맞춰져 있다. 나중에 편집하기 쉬운 투명 PNG 자산을 따로 뽑는 레이어 분리 작업도 지원한다. 만든 이미지 자산을 Seedance 비디오 작업으로 넘기는 흐름도 가능하다. 현재 EvoLink 안내 가격은 1K 이미지가 장당 0.0383달러, 2K 이미지가 장당 0.0765달러다. 요청은 `POST https://api.evolink.ai/v1/images/generations`로 보내며, 모델 이름은 `doubao-seedream-5.0-pro`다.
소셜 미디어 에이전트를 만들 때 인스타그램, 링크드인, 틱톡, X, 유튜브를 각각 따로 연결하면 실제 에이전트 기능을 만들기 전에 많은 시간이 든다. 각 서비스는 로그인 방식, 토큰 갱신, 업로드 방식, 사용 제한, 데이터 형식이 다르기 때문이다. PostSyncer는 이 반복 작업을 줄이기 위해 MCP 서버를 내놓았다. 이 서버는 작업공간, 연결 계정, 게시물, 캠페인, 라벨, 댓글, 분석 데이터를 같은 JSON 구조와 같은 접근 방식으로 다룰 수 있게 한다. 예를 들어 에이전트는 작업공간 목록을 보고, 알맞은 작업공간을 고르고, 연결된 계정을 확인하고, 기간별 분석 데이터를 가져오고, 기존 게시물을 읽은 뒤 새 글을 작성하는 흐름으로 움직일 수 있다. 서비스마다 따로 OAuth를 처리하거나 데이터 구조 차이를 맞추는 일을 줄이는 것이 핵심이다.
대형 언어 모델 안에서 하나의 개념이 어떤 계산 흐름으로 처리되는지 찾으려는 실험이다. 목표는 특정 뉴런 하나, 한 층의 숨은 상태, 한 번의 벡터 비교가 아니라 여러 층에 반복해서 나타나는 계산 그래프를 찾는 것이다. 예를 들어 인도, 프랑스, 일본, 독일 같은 나라에 대해 수도, 화폐, 동물, 인구, 언어 같은 질문을 반복해서 던지고, 그때 모델 내부 반응을 비교한다. 실험 과정은 잔차 흐름, 어텐션, 다층 퍼셉트론 반응을 잡고, 뉴런별 선택성을 측정하며, 여러 층에 걸친 활성 기반 그래프를 만든다. 그런 뒤 수백 개의 대조 질문을 합쳐 개념별 공통 의미 그래프를 만들고, 서로 다른 대상 사이에서 그래프가 얼마나 겹치는지 비교한다. 초기 관찰은 의미 있는 단위가 단일 뉴런이나 단일 활성 벡터가 아니라 여러 뉴런과 층에 넓게 퍼진 계산 흐름이라는 점이다.
Solana 밈코인을 자동으로 사고파는 자율 에이전트에서는 판단 자체보다 실행 직전의 안전 확인이 더 큰 문제였다. 초기 테스트에서 에이전트가 산 토큰의 약 42%가 가격이 거의 0으로 무너졌다. 겉으로는 문제가 없어 보이는 토큰도 있었다. 계약은 검증되어 있었고, 유동성 풀은 소각되어 있었으며, 큰 보유자가 바로 보이지 않았다. 하지만 실제 위험은 모델이 문장으로 추론하기 어려운 곳에 있었다. 같은 출처에서 자금을 받은 지갑들이 같은 블록에서 함께 사들인 뒤, 다음 구매자에게 팔아치우도록 준비된 구조였다. 해결책은 에이전트가 거래에 서명하기 전에 별도 도구를 반드시 호출하게 하는 방식이었다. 이 도구는 0~100 위험 점수와 함께 같은 자금 출처, 같은 블록 묶음 거래, 반복 사기 배포자 이력 같은 신호를 돌려주고, 기준을 넘으면 거래를 건너뛰게 했다. 여기에 진입 시점 제한까지 더하자 가격 붕괴 비율은 약 42%에서 거의 0에 가까워졌다.
여러 AI 에이전트가 함께 일할 때 각 에이전트에 같은 방식으로 토큰 한도를 주면 낭비가 생길 수 있다. 중요한 에이전트는 작업 중간에 토큰이 부족해 멈추고, 덜 중요한 에이전트는 쓰지 않은 토큰을 남길 수 있다. Token Budget Contracts는 이 문제를 줄이기 위한 오픈소스 파이썬 라이브러리다. 각 에이전트에 우선순위와 최대 토큰 예산을 정해 두면, 우선순위가 높은 에이전트가 부족할 때 낮은 우선순위이거나 쉬고 있는 에이전트의 남는 토큰을 자동으로 가져올 수 있다. 반대로 낮은 우선순위 에이전트가 높은 우선순위 에이전트의 토큰을 가져가지는 않는다. 각 에이전트에는 보호 예비량이 있어 토큰을 모두 빼앗기지 않는다. 결과에 충분히 자신 있다고 판단된 에이전트는 더 이상 토큰을 쓰지 않도록 막을 수도 있다. 이 라이브러리는 MIT 라이선스이며, 의존성 없이 파이썬 기반 에이전트 구성에서 쓸 수 있고 LangGraph, CrewAI, AutoGen, 직접 만든 API 호출 방식과 함께 사용할 수 있다고 제시된다.
브라우저에서 대신 작업을 처리하는 브라우저 에이전트 세 가지가 비교됐다. Browser-use와 Vercel agent-browser는 오픈소스이고, TinyFish는 비공개 서비스다. TinyFish는 작업을 더 안정적으로 끝내는 편이었지만, 소스가 공개되어 있지 않고 속도가 자주 느렸다. Vercel agent-browser는 속도가 가장 좋지 않았고, 간단한 작업도 제대로 끝내지 못했다. Browser-use는 세 가지 중 가장 빠르게 느껴졌지만, 여전히 충분히 빠르지는 않았다. 안정성은 괜찮은 편이었지만 TinyFish만큼 좋지는 않았다. 핵심 질문은 실제 일을 빠르고 안정적으로 끝낼 수 있는 좋은 웹 에이전트가 있는지다.
Gov-Stat-MCP-Server는 여러 나라 정부의 데이터를 한곳에서 가져오도록 만든 MCP 서버다. AI 에이전트나 자동화 도구가 각 나라의 정부 사이트를 따로 연결하지 않고, 하나의 통로로 정부 데이터를 요청하는 데 쓰일 수 있다. 제공된 내용만으로는 어떤 나라와 데이터가 지원되는지, 설치 방법이 무엇인지, 실제 토큰이나 비용을 얼마나 줄이는지는 확인되지 않는다.
AI 에이전트가 코드를 만들고 그 코드의 테스트까지 함께 만들면, 테스트가 통과해도 실제 요구사항을 맞췄다는 뜻이 아닐 수 있다. 에이전트가 처음부터 일을 잘못 이해하면, 잘못된 코드와 그 잘못을 통과시키는 테스트를 함께 만들 수 있기 때문이다. 그래서 초록색 통과 표시가 떠도 실제 결과는 틀릴 수 있다. 더 믿을 만한 확인 방법은 에이전트가 직접 만들지 않은 검사를 돌리는 것이다. 예를 들면 실제 앱에서 동작을 확인하거나, 별도의 검증기를 쓰는 방식이다. DeadBranchBench는 이런 일이 얼마나 자주 생기는지 재기 위해 만든 작은 오픈소스 도구다.
소비자용 AI 에이전트 앱은 기업용 업무 도구나 개발자 도구와 다르게, 일반 사용자가 휴대폰을 더 유용하게 만들기 위해 쓰는 형태여야 한다. 에이전트의 작업 반복 과정을 서버에서 돌리면 휴대폰이 주머니에 있어도 계속 일할 수 있고, 오래 걸리는 작업도 안정적으로 처리하며, 배터리 소모도 줄일 수 있다. 하지만 소비자가 원하는 기능은 문자 확인, 앱 조작, 카메라 사용처럼 개인 기기와 깊게 연결된 경우가 많다. 핵심 판단을 서버에 맡기면 개인 데이터를 계속 주고받아야 해서 속도가 느려질 수 있고, 사용자가 믿고 맡길 수 있는지도 문제가 된다. 더 현실적인 방향은 실행과 개인 문맥은 기기 안에서 처리하고, 무거운 판단이 필요할 때만 서버의 거대 언어 모델에 요청하는 방식이다. 다만 이 혼합 방식은 서버 또는 기기 중 하나만 고르는 것보다 만들기 어렵다. 소비자 가격도 어렵다. 기업은 월 50달러 정도를 쉽게 낼 수 있지만, 일반 소비자는 월 5달러에도 부담을 느낄 수 있어, 사용자가 직접 API 키를 가져오고 앱은 조율 기능만 맡는 모델이 하나의 선택지로 제시된다.
MRU는 긴 글이나 코드처럼 순서가 있는 데이터를 처리할 때 쓰는 어텐션을 대체하려는 선형 시간 구조다. 입력 임베딩을 작은 행렬 형태의 상태로 바꾼 뒤, 순서대로 행렬들을 누적해서 곱해 출력 상태를 만들고, 마지막에 다시 벡터로 되돌린다. 딥러닝 칩에서 빠르게 돌리기 위해 행렬 곱셈의 결합 성질을 이용한 병렬 스캔도 만들었다. 예전에는 간단한 셰익스피어 문자 예제에서 괜찮은 결과가 나왔지만, 더 복잡한 데이터에서는 상태 행렬의 크기를 안정적으로 제한하는 문제와 학습 불안정 문제가 드러났다. 이를 줄이기 위해 입력 벡터를 행렬로 만드는 방식을 바꾸는 실험이 추가됐다. 처음 방식은 벡터를 행렬로 모양만 바꾼 뒤 단위 행렬을 더하는 것이었고, 새 방식에는 벡터 값으로 비대칭 행렬을 만들고 행렬 지수 같은 변환을 쓰는 방법이 포함된다.
MCP 서버는 AI 에이전트가 외부 도구, 파일, 서비스와 연결되게 해 주는 구성요소다. 설치하면 파일시스템, 도구 실행 권한, 때로는 API 키에 접근할 수 있어 잘못 고르면 큰 보안 문제가 생길 수 있다. 최근 공개된 조사에서는 오픈소스 MCP 서버 1,899개 중 5.5%에서 도구 설명을 악용하는 문제가 발견됐고, 14.4%에서는 알려진 취약한 코드 패턴이 확인됐다. OX Security는 MCP SDK에 원격 코드 실행으로 이어질 수 있는 구조적 취약점이 있어 많은 서버가 영향을 받을 수 있다고 밝혔다. 특히 도구 오염은 모델이 읽는 도구 설명 안에 숨을 수 있어서 일반적인 코드 검사만으로는 놓칠 수 있다. 그래서 MCP 서버를 설치하기 전에 설명서만 믿을지, 버전을 고정할지, 더 강한 검증 절차를 둘지에 대한 실제 운영 기준이 필요하다.
AI 에이전트가 이메일, 데이터베이스, 결제 같은 실제 권한을 가지면 실수의 피해가 커질 수 있다. 잘못된 파일이나 기록을 지우거나 바꿀 수 있고, 승인되지 않은 메시지나 이메일을 보낼 수 있다. 예상 밖으로 돈을 쓰거나, 사용자에게 조작적이거나 위협적으로 느껴지는 말을 할 수도 있다. 중요한 쟁점은 이런 사고가 실제로 얼마나 자주 일어나는지, 피해가 시간·돈·고객 신뢰 측면에서 얼마나 큰지, 사고를 사전에 막았는지 아니면 뒤늦게 발견했는지다. AI 에이전트를 만들 때는 기능 구현만이 아니라 권한 제한, 승인 절차, 사용 기록 확인 같은 안전장치가 함께 필요하다.
검색형 인공지능 시스템에서는 질문에 맞는 문서를 얼마나 앞순위에 잘 올리는지가 중요하다. 한 실무 방식은 까다로운 시험 질문 묶음과, 각 질문에 답하려면 반드시 들어 있어야 하는 예상 문구를 미리 정해 둔다. 성능은 MRR로 계산한다. 맞는 문서가 1등이면 1.00점, 2등이면 0.50점, 아예 못 찾으면 0점처럼 첫 번째 정답 문서의 순위가 높을수록 점수가 커진다. 코드를 바꾸거나 검색 설정을 조정할 때는 이전 기준점과 새 결과를 비교해 좋아졌는지 나빠졌는지 확인한다. 임베딩이나 LLM 분류처럼 API 호출이 필요한 결과는 미리 저장해 두어, 시험 데이터가 매번 똑같이 돌아가게 만든다. 예시 결과는 107개 질문에서 전체 MRR 0.813이며, 제품 관련 질문은 0.860, 일반 질문은 0.814, 사람 관련 질문은 0.495로 나타났다. 각 질문별로 검색 순위가 6등에서 2등으로 좋아졌는지, 1등에서 8등으로 나빠졌는지도 함께 보여 준다.
학습용 RAG 앱을 만들면서 LangChain 문서를 MarkDownSplitter로 나누어 Qdrant에 넣었다. 이 과정에서 '@tool' 같은 데코레이터 정보가 사라졌고, 문서 조각의 경계도 검색에 잘 맞지 않게 나뉘었다. 전체 문서를 로컬 임베더로 처리해 Qdrant에 넣는 데 약 48분이 걸렸다. 이후 검색 단계에서 알맞은 조각이 위에 오지 않아 답변 품질을 기대하기 어려운 상태가 됐다. 핵심 문제는 문서 조각을 어떻게 나눌지 정하는 방법과, 이미 Qdrant에 들어간 조각을 더 나은 방식으로 다시 바꾸는 방법이다.
많은 AI 에이전트 도구의 사람 승인 절차는 실제 제어라기보다 잠깐 멈추는 단계에 가깝다. 사람이 승인 버튼을 누른 뒤에도 모델이 직접 도구를 호출하면, 프롬프트가 꼬이거나 공격을 받아도 실행까지 이어질 수 있다. 제안된 방식은 모델이 실행 권한을 갖지 못하게 막는다. 모델은 할 일을 제안하고 승인 문을 여는 역할만 하며, 실제 함수는 보지 못한다. 사람이 승인하면 서버가 장부를 통해 그 작업을 한 번만 실행한다. 그래서 문제가 생긴 프롬프트에는 실제 행동을 일으킬 통로가 없다. 개발자는 TypeScript로 코드를 쓰고, 실행하는 사람은 승인과 거절 버튼이 있는 화면만 사용한다. 파이프라인 작성도 패키지 안의 기술 묶음을 바탕으로 코딩 에이전트가 도와주는 베타 단계의 프레임워크다.
Arga Labs는 최근 YC P26 회사로, 코딩 에이전트가 실제 서비스와 비슷한 환경에서 테스트될 수 있는 샌드박스를 만들고 있는 것으로 알려져 있다. 이 회사는 꽤 큰 초기 투자금을 유치했으며, 같은 기수 안에서도 큰 편이라는 말이 나온다. 핵심 아이디어는 클라우드 기반 샌드박스에서 SaaS API를 쓸 수 있게 해 코딩 에이전트를 더 현실적으로 시험하는 것이다. 다만 이 방식이 기존 샌드박스나 인공지능 코드 리뷰 회사와 뚜렷하게 다를 만큼 깊은 기술인지에는 의문이 있다. 실제로 얼마나 유용한지도 아직 명확하지 않다. CI/CD 경험이 적은 관점에서는 이 제품의 차별점과 필요성을 더 확인해야 하는 상황이다.
개인 Gmail 계정이 오래 쌓여 용량이 가득 차고, 수천 개의 이메일을 손으로 정리하기 어려운 상황을 해결하려는 구상입니다. 첫 버전은 ‘이메일 비서’처럼 모든 일을 하려 하지 않고, 많은 이메일을 살펴보는 한 가지 일에 집중합니다. 뉴스레터, 광고성 메일, 오래된 알림처럼 지워도 될 가능성이 높은 이메일을 찾아냅니다. 삭제를 추천하는 이유도 함께 보여줍니다. 실제 삭제 전에는 사람이 모두 확인하게 해서, AI가 마음대로 받은편지함을 바꾸지 않도록 합니다. 목표는 화려한 기능보다 수작업 정리 시간을 줄이는 것입니다.
최근 직접 사용 경험에서는 GPT나 Grok보다 Gemini에서 같은 불만이 반복됐다. Gemini는 단순한 답에도 먼저 동의한 뒤 꼭 반대 의견이나 예외를 붙이는 방식으로 답하는 경향이 있었다. 그 반대 의견이 실제 근거가 약해도, 균형 잡힌 답처럼 보이려고 하다가 환각으로 이어질 수 있었다. 여러 방식으로 시험해 보니 AI 에이전트가 좋은 조언자처럼 보이려는 욕심 때문에 필요 없는 말을 덧붙이는 느낌이 강했다. 앞부분의 과한 맞장구나 칭찬은 걸러낼 수 있지만, 본문에서도 불필요한 단서와 반론이 많아 답을 읽는 시간이 늘어난다는 불만이다.
AI 에이전트의 장기 메모리는 단순히 관련 문서 조각을 찾아오는 것보다 더 복잡하다. RAG는 질문과 관련 있는 문서나 내용을 찾는 데는 잘 맞지만, 에이전트가 오래된 정보를 실제 기억처럼 다루기에는 한계가 있다. 에이전트는 과거 정보가 지금도 맞는지, 어디에서 나온 정보인지, 나중에 다른 정보로 바뀌었는지, 지금 상황에서 꺼내 써야 하는지까지 판단해야 한다. 나쁜 메모리는 필요한 것을 잊는 문제만이 아니라, 필요 없는 오래된 정보를 끌어와 실행 흐름을 흐리는 문제도 만든다. 더 나은 구조로는 도구 사용 결과를 덮어쓰지 말고 사건 기록처럼 계속 붙이고, 메모리마다 출처를 남기며, 오래된 메모리는 시간이 지나며 약해지거나 다른 메모리와 경쟁하게 하는 방식이 제시된다. 또 어떤 메모리가 왜 쓰였는지 사용자가 볼 수 있는 접근 기록을 남기고, 기억된 정보가 틀릴 수 있으므로 실제 행동 전에는 승인 절차를 두는 것이 중요하다.
Claude Pro 구독만으로 AI 에이전트를 만들 수 있는지, MCP 서버가 Claude Pro나 Max 구독에 포함되는 기능인지가 핵심 의문이다. Claude Code 에이전트가 MCP 서버에 연결되는지도 함께 궁금해한다. 질문자는 DevOps 엔지니어이며, AI 에이전트가 실제 업무에서 어떻게 쓰이는지 이해하기 위해 아주 기본적인 예시를 원한다. 내용은 새 기술 발표가 아니라, Claude 구독 상품, 에이전트 도구, 외부 도구 연결 방식 사이의 차이를 구분하려는 초보 단계의 문제 제기다.
RRT-355M은 GPT-2 Medium과 비슷한 크기의 언어 모델로, 약 3억5400만 개 매개변수를 갖고 115억 개 토큰으로 처음부터 학습됐다. 핵심 실험은 소프트맥스 없이도 문장 안의 중요한 연결을 고르는 주의 구조가 작동하는지 확인하는 것이다. 모델은 구조적으로 많은 연결을 꺼 두는 방식으로 계산을 줄이며, 긴 문맥에서는 일부 계산 묶음을 건너뛰는 Triton 커널을 함께 제공한다. 공개된 평가는 22개 과제를 묶은 CORE 기준에서 0.1558점을 기록했고, 같은 크기의 GPT-2 Medium 0.1770보다는 낮지만 GPT-2 124M 0.1211보다는 높았다. 긴 문맥 실험에서는 H100 기준으로 계산 묶음의 34%에서 55%를 건너뛸 수 있었고, 1만6384 토큰 길이의 주의 계산에서 최대 VRAM 사용량은 5.5GB로 제시됐다. 다만 일반적인 Transformers 방식으로 바로 실행하면 안 되고, 별도 RRT 엔진과 Triton 커널이 필요하다. MMLU, GSM8K, HumanEval, 채팅 성능, 지시 따르기 성능은 평가되지 않았으며, 공개 저장소의 라이선스는 AGPL-3.0이다.
MiniMax M3에 약 55만 토큰 분량의 실제 프로젝트 자료를 한 번에 넣어 긴 컨텍스트가 실무 문제 해결에 쓸모 있는지 시험했다. 입력에는 Django 백엔드, React 프런트엔드 코드, 오래된 문서, 인증 로그, GitHub 이슈 메모가 함께 들어갔다. 문제는 로그인 반복 오류였고, 토큰 만료 뒤 프런트엔드가 다시 시도하는 과정에서 생겼다. 백엔드 로그에는 한 번에 알아볼 수 있는 뚜렷한 오류가 없었다. 원인은 AuthContext.tsx와 middleware.py에 나뉘어 있었고, 두 파일은 일반적인 조각 나누기 방식으로는 함께 묶이기 어려웠다. 로컬 실행은 아니었고, 50만 토큰이 넘는 입력을 다룰 준비가 안 되어 있어 호스팅 실행으로 먼저 가능성을 확인했다.
Claude Code를 일반 채팅처럼 쓰지 않고, 내 컴퓨터에 파일이 남는 로컬 코딩 작업공간으로 쓰는 구성이 제시된다. 핵심은 Omniroot가 여러 무료 제공자, 대체 경로, 토큰 절약 장치를 통해 코딩 요청을 보내게 하는 것이다. 이렇게 하면 한 모델의 사용량 제한이나 비용에만 기대지 않고 앱 개발 작업을 이어갈 수 있다는 주장이다. Claude Code는 파일을 만들고 수정하는 역할을 하고, Omniroot는 모델 호출을 나누어 보내며, Agent OS는 작업공간을 정리하는 역할로 소개된다. Codex, OpenClaw, Hermes, Paperclip, Oracle, Astros, Apollo, Obsidian도 함께 쓰는 구성으로 언급된다. 실제 설정은 영상과 AI Profit Boardroom 안에서 볼 수 있으며, 유료 코칭·지원·강의 안내도 함께 붙어 있다.
Codex를 쓸 때 GPT-5.4가 GPT-5.5보다 토큰을 덜 써서 요금제 한도가 더 오래 가는지 확실한 답을 찾지 못한 상태다. Hermes에서 보이는 선택지는 GPT-5.5, GPT-5.4, GPT-5.4 mini이며, 일부가 말하는 5.3 Codex 같은 모델은 선택 목록에 없다. 핵심 고민은 AI 에이전트를 계속 Codex로 쓸지, 아니면 z.ai의 GLM 5.2 요금제로 바꿀지다. 비교 기준은 모델 성능보다 실제 토큰 소모와 요금제 지속 시간에 가깝다.
Gram이라는 AI 모더레이터가 Reddition이라는 포럼을 관리하는 실험이 진행되고 있다. 실험의 핵심은 AI의 행동이 스스로 시작된 것인지, 아니면 사람의 명령에 따른 것인지 살펴보는 것이다. 이 프로젝트는 프랑스의 민간 회사와 IUT가 함께 진행하는 컴퓨터과학 연구다. 별도 소개 페이지에서 논문 도입부와 Gram의 작동 방식을 볼 수 있고, 누구나 포럼에 참여할 수 있다. 포럼의 대부분은 프랑스어이지만, 영어로 댓글을 쓰면 Gram이 영어로 응답할 수 있다고 안내되어 있다.
Anthropic 최고경영자 Dario Amodei는 AI 회사들이 지금의 거대한 투자 규모를 정당화하려면 수천억 달러 수준의 매출이 필요할 수 있다고 봤다. 핵심은 AI 모델을 만들고 운영하는 데 드는 돈이 매우 크다는 점이다. 이런 비용 구조가 계속되면 모든 회사가 끝까지 버티기 어렵고, 일부 회사만 살아남는 업계 재편이 생길 수 있다. 반대로 기업과 개인의 AI 사용 수요가 충분히 커지면, 지금의 투자가 나중에 맞는 선택으로 보일 수도 있다.
reverse-flow-skill은 AI Agent와 Codex에서 쓰는 로컬 역공학 작업 흐름 스킬이다. 중국어 호출 문구인 “真心为你”를 입력하면 역공학 모드로 들어간다. 기본 작업 대상은 로컬 샌드박스, CTF, crackme, wargame, 훈련용 표적 환경이다. 진행 순서는 분석, 보고, 역공학, 심화 역공학, 취약점 판단, 다음 단계 선택으로 이어진다. 실제 제품 해킹보다 훈련용 보안 문제를 단계별로 다루는 데 맞춰져 있다.