리브의 아침 브리핑

01코딩 에이전트 하네스 설계에 관한 실증 연구

하네스 전체를 통째로 비교하면 성능 차이가 계획에서 왔는지 도구에서 왔는지 컨텍스트 관리에서 왔는지 알 수 없다. 그래서 ReAct 실행 루프는 고정한 채 세 구성요소만 바꿔 4개 모델과 2개 벤치마크에서 176개 설정을 돌렸다. 결론부터 말하면 효과는 모델과 작업에 따라 달라지고, 어느 하나가 보편적으로 좋지는 않았다.

• 컨텍스트 관리는 모델을 더 똑똑하게 만들지 않는다. 대화가 길어져 작업이 중간에 끊기는 것을 막아 주는 것이 본체이고, 컨텍스트 창이 넓어질수록 그 이점도 줄어든다.
• 오래된 도구 출력을 먼저 생략하고 필요할 때만 요약하는 조합이 비용 대비 성능에서 가장 좋았으며, 생략한 원문을 다시 불러오는 recall 기능은 거의 쓰이지 않았다.
• 계획 유지 장치는 약한 모델의 성공률을 올리는 대신 비용을 늘렸고, 강한 모델에서는 수정 후 불필요한 검증을 줄여 성공률은 그대로 두고 비용만 낮췄다.
• 전용 파일 도구는 셸이 서툰 모델에 도움이 됐지만, 능숙한 모델은 bash만으로 여러 작업을 묶어 실행하며 오히려 비용을 줄였다.

arxiv.org · 관심사 최상 · 추천 상위 21.5%

02LLM과 함께 글 쓰는 법

LLM을 대필 작가가 아니라 교정 편집자로 써야 한다. 글은 직접 쓰고, 좋은 모델에 초안을 넘겨 결함만 찾게 한다. 아무리 다듬어도 많은 독자는 모델이 만든 문단을 글이 아니라 생성된 출력물로 받아들이기 때문이다.

• 첫 번째 원칙은 모델이 제안한 표현을 단 한 단어도 쓰지 않는 것이다. 마음에 들어도 예외를 두지 않는다. 모델의 문장은 전부 잡지 헤드라인처럼 쓰이는 경향이 있어, 헤드라인 수십 개로 이루어진 글은 이상해진다.
• 두 번째 원칙은 격려를 명시적으로 금지하고 그래도 나오는 칭찬을 계속 경계하는 것이다. 초안에 대한 칭찬은 다시 생각하고 고쳐 써야 할 부분까지 고수하게 만든다.
• 맡길 것은 반복 표현, 불필요한 부사, 동작이 드러나지 않는 문장, 문단 배치 같은 지루한 점검이다. 수정은 직접 하고, 편집 맥락을 모르는 별도 모델에 원문과 수정본을 비교시킨다.
• 이 글 자체를 GPT5에 평가시키자 분량이 20% 길다는 답을 받았다. 아마 맞는 말이지만 줄이지 않기로 했다.

sockpuppet.org · 관심사 최상 · 추천 상위 26.7%

03생각을 멈춰도 되는 때는 오지 않는다

LLM의 결과를 확인하지 않고 받아들이거나, 문제가 생길 때마다 다시 해결해 달라고 요청만 중계하는 방식으로는 모델이 발전해도 자신의 가치를 지킬 수 없다. 지금은 그렇게 만든 소프트웨어에 심각한 문제가 남고, 미래에 LLM이 혼자 훌륭한 소프트웨어를 만들게 되면 기업은 중간의 직원 없이 모델을 반복 실행하면 된다. 그 방식이 유효한 시점은 오지 않는다.

• Bazel 빌드 전환처럼 자동화하기 쉬워 보이는 작업도 에이전트를 써서 수개월이 걸렸다. 명세로 옮기기 어려운 요구사항이 숨어 있어 지속적인 감독이 필요했다.
• 학습 분포 밖에서 격차가 뚜렷하다. 최첨단 모델과 하네스도 Lost Cities나 Dominion 같은 게임에서는 처음 접한 사람보다 대체로 못하고, 초보자에게 그럴듯하지만 명백히 틀린 조언을 내놓는다.
• 에이전트의 높은 처리량은 출시 품질의 기준도 같이 올린다. 예전이면 MVP로 내보냈을 작업에서도 더 많은 다듬기와 예외 상황 탐색을 요구하게 된다.
• 테스트 통과나 지표 충족은 성공의 증거가 아니다. 감독 없이 돌린 경우 에이전트가 테스트에 과도하게 맞추는 문제를 놓치기 쉽다.

danluu.com · 관심사 상 · 추천 상위 32.2%

04Cloudflare, 수학과 Rust로 RAM 100TB 추가 절감

캐시 요청을 서버에 분배하는 Pingora Backend Router를 최적화해 전 세계에서 RAM 100TB 이상을 줄였다. 수천 대 서버에서 모든 노드가 모든 서비스를 돌리는 구조라 작은 낭비도 그대로 확대된다. 절감은 두 갈래인데, 저장 형식에서 25%를 깎고 해시 개수 자체를 90% 줄였다.

• hash: u32와 index: u32로 8바이트를 쓰던 Point 구조체에서 인덱스를 u16으로 줄였는데, 정렬 때문에 크기가 그대로였다. repr(packed) 대신 [u8; 6] 배열과 접근자를 택해 항목당 6바이트로 만들었고 컴파일 결과는 같다.
• 서버당 해시 개수 k에 대한 변동계수는 sqrt((N-1)/(Nk+1))이다. 기본 160개에 가중치 625를 곱해 10만 개가 되면, 마지막에 더한 9만 개가 줄이는 오차는 약 0.7%에 불과하다.
• 32비트 해시 공간에서는 생일 역설 때문에 해시를 늘릴수록 충돌도 빠르게 늘어, 과도한 해시는 균등 분배를 돕지도 못하면서 메모리만 먹는다.
• 규정 준수와 캐시 기능 조합마다 별도 링이 필요해 링이 수십 개로 늘었고, 그래서 사용량이 일부 경우 6GB까지 커졌다.

blog.cloudflare.com · 관심사 중 · 추천 상위 32.2%

05Claude Code, 이제 AGENTS.md도 지원

Claude Code 2.1.277부터 프로젝트에 CLAUDE.md가 없으면 AGENTS.md를 프로젝트 지침으로 자동으로 읽는다. 여러 에이전트가 공유하는 AGENTS.md를 위해 CLAUDE.md를 복제하거나 심볼릭 링크로 연결할 필요가 없어졌다.

• /config의 Project instructions에서 CLAUDE.md만 사용, AGENTS.md fallback, 둘 다 사용 중에 고를 수 있고, 둘 다 읽게 해도 내용이 같거나 심링크면 중복 로드하지 않는다.
• 하위 디렉터리의 AGENTS.md도 해당 위치의 프로젝트 지침으로 적용되어 모노레포의 계층형 설정을 지원한다.
• 이 기능 자체가 Mods라는 새 커스터마이징 시스템 위의 built-in mod이고, 앞으로는 지침 로딩 방식을 사용자가 custom mod로 바꿀 수 있게 된다. 현재 mod의 소스도 공개돼 있다.

x.com/trq212 · 관심사 최상 · 추천 상위 40.7%

06Agent-Native - 하나의 액션을 UI/에이전트/API에서 함께 쓰는 앱 프레임워크

기존 앱과 AI 에이전트를 따로 만들지 말고 하나의 애플리케이션 안에서 같은 기능과 데이터를 공유하게 하자는 프레임워크다. defineAction으로 작업을 한 번 정의하면 UI, 에이전트 도구, HTTP API, MCP, A2A, CLI에서 같은 액션을 호출한다.

• 이메일 답장 같은 작업의 입력 스키마와 실행 코드를 하나만 유지하므로 인터페이스마다 로직을 다시 구현하지 않는다.
• 에이전트 런타임에 대화, 도구, 스킬, 메모리, 백그라운드 작업, 관측, 사람이나 다른 에이전트로의 인계가 포함된다.
• Drizzle이 지원하는 SQL 데이터베이스와 Nitro 호환 호스팅을 붙일 수 있는 백엔드 독립 구조이고 MIT 라이선스다.

github.com/BuilderIO · 관심사 상 · 추천 상위 45.4%

07GPT Image 2.5 프롬프트 가이드 - 무엇을 바꾸고 무엇을 유지할까

GPT Image 2.5부터는 속도 중심의 Flare와 품질 중심의 Sunburst 중에서 고르는 과정이 추가된다. 다만 프롬프트 작성 원칙 자체는 2.5 전용 규칙이 아니라 버전 간 공통이라, 기존 프롬프트를 처음부터 다시 쓸 필요는 없다.

• 특별한 주문이나 문법보다 용도, 대상, 구도, 눈에 보이는 세부 조건을 명확히 쓰는 것이 중요하다. 카메라 사양은 외관을 유도하는 단서일 뿐 물리 시뮬레이션의 보장이 아니다.
• 편집에서는 바꿀 부분과 유지할 부분을 분리해 X만 변경하도록 요청하고, 인물의 형태·조명·배치·라벨처럼 보존할 요소를 나열한 뒤 한 번에 하나씩 고친다.
• 이미지 속 문구는 따옴표로 정확히 지정하고 위치와 등장 횟수까지 설명하며, 여러 참고 이미지는 번호를 붙여 인물·스타일·배경 중 어떤 역할인지 밝힌다.
• 품질 설정에 xhigh와 max가 추가됐지만, 높은 설정이나 반복 편집이 항상 더 나은 결과를 보장하지는 않는다.

developers.openai.com · 관심사 상 · 추천 상위 69.4%

08비자기회귀 결정 모델을 강화학습으로 만든 이야기

I built non-autoregressive decision models with RL a year ago

1년 전 jev 아키텍처 연구를 바탕으로 만든 비자기회귀 결정 모델을 공개했다는 소개다. 토큰을 하나씩 뽑는 대신 선택지로 답하는 계열이라, 지연과 비용 쪽을 노린 설계로 보인다.

• 제출자는 같은 연구 계열의 작업을 1년 전에 이미 만들어 두었다고 밝혔고, 이번 공개는 그 연장선이다.
• 댓글에서는 jev 계열을 실제로 쓰면서 일부 워크로드를 10배 싸게, 2배 빠르게 처리했다는 경험담이 나왔고, 이번 것이 오픈소스라는 점에 기대가 몰렸다.
• CPU에서 못 돌면 추론 제공자에게서 사서 쓰겠다는 반응도 있었다. 프로덕션에서 GPU를 직접 관리하는 부담이 그만큼 크다는 이야기다.
• tabular foundation model과 사용처가 겹쳐 보인다는 지적과, 그렇다면 실제로 학습되는 것이 무엇이냐는 질문이 함께 올라왔다.

laya.convaiinnovations.com · 관심사 상 · 프런트 상위 1.2%

09AI로 만든 행사 포스터가 꼭 끔찍할 필요는 없다

AI-generated posters don’t have to be horrible

마을 축제부터 카페, 학교 연극까지 온통 같은 ChatGPT 기본 스타일 포스터라 다들 질렸다. 그렇다고 AI를 통째로 금지하는 것은 목욕물과 아이를 같이 버리는 일이라고 보고, 직접 만들어 증명해 보기로 했다.

• 문제의 상당 부분은 도구가 아니라 공을 들이지 않으려는 쪽에서 나오고, 그 결과 같은 얼굴의 결과물이 쏟아진다는 것이 저자의 진단이다.
• 반박도 강하게 붙었다. 만들어 낸 십여 개의 변형이 서로 다른 서체나 이미지를 갖고 있을 뿐 여전히 같은 AI 냄새를 풍긴다는 지적이다.
• 그 연장선에서 핵심 문제는 기술이 아니라 만들 때의 시각과 상상력 부족이라는 반론이 나왔고, 이 지점에서 의견이 갈렸다.

john.hartnup.uk · 관심사 중 · 프런트 상위 0.5% · 논쟁

10스타크래프트 브루드워를 에이전트 벤치마크로 쓴 리포트

Brood War Bench

에이전트가 직접 플레이하는 브루드워를 벤치마크로 만들고 그 결과를 리포트로 공개했다. 기존 벤치마크 대부분이 단발성 전술 해결로 끝나는 것과 달리, 장기 계획과 자원 배분을 함께 요구하는 형태다.

• 댓글에서 가장 호응이 큰 지점은 전략이다. 대부분의 벤치마크에는 장기적 사고와 오케스트레이션을 재는 축이 없다는 이야기다.
• 동시에 오염 우려도 제기됐다. 이 게임에 대한 논의가 학습 데이터에 대량으로 들어 있을 텐데, 플레이만 보고 온라인에서 자주 회자되는 전략을 고르는 경향을 구분할 수 있겠느냐는 질문이다.

bw.swerdlow.dev · 관심사 상 · 프런트 상위 45.6%