GeekNews Weekly

원격·하이브리드 근무가 자리 잡으면서, 텍스트 기반의 논쟁이 오히려 더 날카롭고 소모적으로 흐른다는 이야기가 개발 조직 안에서 자주 나옵니다. 이 글은 단순히 “논쟁하지 말자”는 이야기가 아니라 언제 말하고, 언제 멈출 것인가에 대한 이야기입니다. 특히 개발 조직에서는 장애, 보안, 확장처럼 반드시 짚어야 하는 문제와, 각자의 경험과 자아가 섞인 취향의 문제를 구분하기가 쉽지 않습니다. 그래서 이 글은 누군가를 설득하는 기술보다 먼저, 내가 지금 무엇을 얻으려고 말하고 있는지를 돌아보게 만듭니다. 좋은 엔지니어링 판단은 논리만으로 완성되지 않고, 그 판단이 받아들여질 수 있는 관계와 타이밍 위에서 작동한다는 점을 다시 생각하게 합니다.

에이전트 개발이 단순히 “프롬프트를 잘 쓰는 법”에서 루프를 어떻게 설계하느냐로 옮겨가고 있다는 점을 잘 보여주는 글입니다. 기본 에이전트 루프 위에 검증 루프, 이벤트 기반 루프, 개선 루프를 쌓아가며 점점 더 신뢰할 수 있는 시스템으로 만드는 관점이 흥미롭습니다. 특히 모델 성능보다 하네스, 평가, 트레이스, 사람의 개입 지점이 중요해진다는 이야기는 실제 프로덕션 AI 도입을 고민하는 팀에게 바로 와닿을 내용입니다. 이제 에이전트의 경쟁력은 “무엇을 할 수 있느냐”보다, 실패를 어떻게 감지하고 반복적으로 좋아지게 만들 수 있느냐에 달려 있는 것 같습니다.

에이전트에게 일을 시킬수록 "왜 내가 원한 게 안 나올까"를 겪게 되는데, 이 글은 그 원인을 지도(map)와 영토(territory)의 차이 로 설명합니다. 우리가 프롬프트/스킬/컨텍스트로 건네는 것은 지도일 뿐이고, 코드베이스와 현실이라는 실제 영토와의 차이가 바로 미지(unknowns) 라는 것이죠. 흥미로운 지점은 이 미지를 Known Knowns / Known Unknowns / Unknown Knowns / Unknown Unknowns 4가지로 나눠, "너무 당연해서 안 적은 것"과 "아예 고려조차 못 한 것"을 구분한다는 데 있습니다. 그래서 구현 전에 Claude에게 blindspot pass로 unknown unknowns를 찾게 하고, 보면 알지만 미리 정의하기 어려운 기준은 프로토타입으로 먼저 언어화하라고 권합니다. AI 코딩의 병목이 모델 성능이 아니라 "내가 뭘 모르는지 아는 능력"으로 옮겨가고 있음을 실감하게 하는 실전 가이드입니다.

AI 도구가 엔지니어링 조직에 들어오면서 “코드 작성 속도”는 크게 달라졌지만, 그만큼 리더십의 기준도 바뀌고 있습니다. 이 글은 마이그레이션, 코드 리뷰, 배포, 의사결정 같은 실제 사례를 통해, AI 시대에도 여전히 중요한 것은 테스트·CI/CD·검증 환경 같은 개발 하네스와 도메인 컨텍스트를 가진 지속적인 팀이라는 점을 강조합니다. 특히 1차 코드는 거의 무료에 가까워졌지만, 잘 동작하는 코드는 여전히 비싸다는 구분이 좋습니다. AI를 도입하면 조직이 자동으로 빨라지는 것이 아니라, 빠른 실행을 받아낼 수 있는 구조와 의사결정 체계가 있어야 한다는 현실적인 글입니다.

AI와 GPU가 모든 곳에서 중요해진 시대지만, 실제로 CUDA 커널 하나가 실행될 때 내부에서 무슨 일이 벌어지는지 아는 사람은 많지 않습니다. 이 글은 단순한 벡터 덧셈 예제를 통해 컴파일 파이프라인, PTX와 SASS, 드라이버 호출, 워프 스케줄링, 메모리 계층까지 한 번에 훑어줍니다. 특히 “결과 한 줄” 뒤에 CPU, 드라이버, 명령 큐, SM, DRAM 대역폭이 어떻게 연결되는지 보여줘서 GPU 프로그래밍의 추상화 아래쪽을 이해하는 데 좋습니다. CUDA를 직접 작성하지 않더라도, AI 인프라와 성능 최적화가 왜 어려운지 감을 잡기에 좋은 글입니다.

AI가 만든 UI가 하나같이 비슷비슷해지는 "slop" 문제, 즉 그라디언트 버튼과 뻔한 카드 레이아웃으로 수렴하는 현상이 디자인 시스템 팀들의 공통 고민이 되고 있습니다. Atlassian이 Google의 오픈소스 포맷 DESIGN.md에 브랜드와 UI 패턴을 담아 프롬프트에 넣는 방식을 실전 테스트하고 그 결과를 공개했습니다. 흥미로운 점은 단일 파일 포맷이 만능 해법이 아니라, MCP나 skills 같은 온디맨드 컨텍스트 도구와 함께 써야 하는 보완재에 가깝다는 결론입니다. 앞으로 디자인 시스템은 사람을 위한 문서이면서 동시에 AI 에이전트를 위한 실행 가능한 컨텍스트가 되어야 할 것 같습니다.

요즘 프론트엔드 프레임워크는 렌더링보다 상태, 이펙트, 아키텍처를 어떻게 제한할 것인가가 더 중요한 질문이 되는 것 같습니다. 이 글에서 소개된 방식은 Elm 아키텍처처럼 단일 모델과 단일 update 흐름을 중심에 두고, 사이드 이펙트도 명시적으로 다루게 만듭니다. React 생태계의 유연함이 때로는 복잡성과 예측 불가능성으로 돌아오는 상황에서, 이런 정확성과 일관성 중심의 프레임워크는 흥미로운 대안인 것 같아요. 특히 구조가 명확할수록 사람 리뷰뿐 아니라 LLM 코드 생성에도 유리하다는 점은 앞으로 프레임워크 설계에서 더 중요해질 포인트입니다.

AI가 점점 더 많은 것을 대신해주는 시대에, 우리는 기술을 더 많이 쓰면서도 그 작동 방식은 점점 덜 알게 되는 역설적인 상황에 놓이고 있습니다. 이 글은 예전 컴퓨터를 쓰기 위해 autoexec.bat, 모뎀, 사운드 카드 설정과 씨름하던 경험을 통해, 마찰이 지식이 되던 시절을 돌아봅니다. 물론 모든 사용자가 내부 구조를 알아야 하는 것은 아니지만, 개발자에게는 그 마찰 속에서 생기는 감각이 여전히 중요합니다. AI 네이티브 세대가 등장하는 지금, “직접 부딪혀서 알게 된 사람들”의 역할이 오히려 더 커질 수 있다는 생각을 하게 합니다.

AI가 코드를 쏟아내는 속도가 빨라지면서, 이제 병목은 작성이 아니라 리뷰로 옮겨간다는 이야기가 부쩍 늘었습니다. 이 글은 리뷰를 버그를 잡는 절차라기보다, 나중에 유지보수하기 어려운 코드를 미리 발견하는 과정으로 봅니다. 리뷰어가 이해하지 못하는 코드는 미래의 유지보수자도 이해하지 못할 가능성이 크고, 그 문제는 작성자가 맥락을 기억하고 있을 때 고치는 편이 훨씬 싸다는 관점이 설득력 있습니다. 물론 코드 리뷰에는 지식 공유, 보안, 설계 점검 등 여러 목적이 있지만, “이 코드를 팀이 계속 책임질 수 있는가”라는 질문은 가장 기본적인 기준으로 삼을 만합니다.

우선순위 프레임워크에서 자주 쓰이는 확신도(confidence) 가 실제로는 의사결정을 왜곡할 수 있다는 지적이 흥미로운 글입니다. 작은 개선은 확신도가 높고, 큰 도약은 확신도가 낮기 때문에, 점수화 방식은 자연스럽게 안전하지만 평범한 선택을 밀어주게 됩니다. 스타트업이나 제품팀에서 중요한 것은 미래를 안다고 가정하는 것이 아니라, 불확실한 상황에서도 유리한 선택을 설계하는 일에 가깝습니다. “확률을 맞히려 하지 말고, 하방은 제한되고 상방은 큰 비대칭 베팅을 찾자”는 관점은 제품 우선순위를 정할 때 꽤 실용적일 것 같아요.

계속 로컬 모델에 대해서 강조하는 글이 나오고 있네요. 이 글에선 dense 27B 모델이 MacBook 48GB급에서 32 tok/s 수준으로 돌아가고, 벤치마크상 mid-2025 프런티어 모델급 점수를 낸다는 점이 핵심입니다.

여러 프런티어 모델과 코딩 에이전트를 개인 프로젝트에 두루 써본 솔직한 사용 후기입니다. 결론이 명확한데, 코드 리뷰, 리팩터링, 일회성 스크립트는 돈값을 했지만, 자율 구현을 맡기면 잘못된 계층에서 버그를 고치고 완료를 거짓으로 보고하는 문제가 반복됐다는 것이죠. AI에 무엇을 맡기고 무엇을 직접 쥐어야 하는지, 경계선을 실전 경험으로 그어주는 글이라 과장된 홍보에 지친 분께 유용합니다.

에이전트가 세션을 넘나들며 장기 작업을 하게 되면서 메모리 시스템이 공통 과제가 됐는데, Microsoft가 이에 대한 접근을 오픈소스로 내놓았습니다. 원문 전체는 보존하되 검색에는 요약(abstraction)과 단서(cue)만 인덱싱해, 일반 RAG의 정보 손실과 검색 모호성을 줄이려는 구조가 특징입니다.

의사결정 트리는 설명 가능한 모델의 대표 사례지만, 실제로는 트리가 커지는 순간 사람이 읽기 어려워집니다. 이 도구는 Jupyter나 Colab 안에서 트리를 확대·이동·접기하며 볼 수 있게 해, 모델의 판단 경로를 더 쉽게 탐색하도록 돕습니다. 특히 scikit-learn뿐 아니라 XGBoost, LightGBM, ONNX까지 지원한다는 점에서 실험용 노트북과 실제 모델 분석 사이의 간극을 줄여줍니다.

그래픽스 프로그래밍은 겉으로는 화려한 결과물이 먼저 보이지만, 실제로는 CPU 쪽의 명시적 API와 GPU 쪽의 조명·셰이딩 지식을 함께 요구하는 깊은 분야입니다. 이 글은 DirectX, Vulkan, Metal 같은 저수준 API와 path tracing, PBR, 셰이더, 선형대수까지 무엇을 어떤 순서로 배워야 하는지 현실적으로 정리합니다. 특히 “멋진 화면”만이 아니라, C++ 실시간 렌더러와 path tracer, 그리고 두 결과를 비교·검증하는 코드를 포트폴리오로 제안하는 점이 좋습니다. 댓글의 내용이 눈길을 끄네요 "취업 목적이면 말리지만, 재미와 저수준 이해로는 최고"

브라우저 안에서 Kubernetes를 실행한다는 발상 자체가 재미있지만, 이 글의 진짜 흥미로운 지점은 LLM으로 대규모 포팅 작업을 어떻게 수행하고 검증했는가에 있습니다. WebAssembly로 통째로 옮기는 대신 Kubernetes 일부를 TypeScript로 다시 구현했고, 사람이 모든 코드를 리뷰하면서 수천 개의 테스트로 동작을 확인했습니다. LLM은 빠르게 코드를 만들었지만, 축약하거나 임의의 헬퍼를 만들고 테스트를 빠뜨리는 문제도 반복했다고 합니다. 대량 AI 코드 생성의 이득을 리뷰/테스트 규칙으로 어떻게 붙잡는지 보여주는, 요즘 흐름에 딱 맞는 실전 후기입니다.

Stripe 경제팀이 인구조사·다국적 등록·플랫폼 결제 데이터를 교차 검증해 고소득 1인 창업자가 구조적으로 급증하고 있음을 보여줍니다. 흥미로운 점은 1인 창업이 더 이상 “작은 사이드 프로젝트”에만 머무르지 않고, 기존에는 채용으로 메워야 했던 역량 공백을 AI와 SaaS 도구가 대신하면서 더 큰 매출까지 가능해지고 있다는 것입니다. 작은 팀과 라이프스타일 비즈니스에 관심 있는 분들에게는 꽤 힘이 되는 데이터 기반의 글입니다.

"revenge of the idea guys"

터미널은 개발자에게 가장 오래된 인터페이스 중 하나지만, 자동완성 경험은 여전히 IDE에 비해 불편한 경우가 많습니다. 이 도구는 600개 이상의 CLI 도구에 대해 IDE 스타일의 명령어 자동완성을 제공하며, bash, zsh, fish, PowerShell 등 다양한 셸을 지원합니다. 특히 withfig/autocomplete 생태계를 기반으로 하면서도 Microsoft가 오픈소스로 내놓았다는 점이 흥미롭습니다. 요즘처럼 CLI 도구가 늘어나는 환경에서는, 명령어를 외우는 능력보다 좋은 탐색 인터페이스를 갖추는 것이 생산성에 더 직접적으로 연결되는 것 같습니다.

로봇 청소기는 이미 상용 제품이 많지만, 대부분은 클라우드 연동과 폐쇄적인 하드웨어·소프트웨어 구조 위에 만들어져 있습니다. 이 프로젝트는 Raspberry Pi, ROS 2, 2D LiDAR, 3D 프린트 섀시, Home Assistant 통합을 기반으로 로컬 우선의 오픈소스 로봇 청소기를 만들려는 시도입니다. 상용 제품보다 싸고 편한 선택지는 아닐 수 있지만, 직접 고치고 바꾸고 이해할 수 있는 가전이라는 점에서 메이커 문화와 잘 맞습니다. 특히 AI와 3D 프린팅, 오픈 하드웨어가 결합되면서 개인이나 작은 커뮤니티가 예전보다 훨씬 복잡한 제품에 도전할 수 있게 되었다는 흐름을 보여줍니다.

영업·마케팅 조직에 AI를 붙였는데도 성과가 잘 나지 않는 이유를 실행 자동화와 의사결정 로직의 차이로 설명하는 글입니다. 많은 GTM AI 도구가 이메일 작성, 콜 스크립트, 계정 요약 같은 실행 계층에 집중하지만, 실제 성과를 좌우하는 것은 어떤 계정을 왜 지금 공략할지 판단하는 상위 로직입니다. 이 글의 핵심은 AI에게 더 많은 신호를 넣는 것보다, 그 신호를 자사만의 방식으로 해석하는 GTM Context Layer를 갖춰야 한다는 점입니다.

AI 모델이 점점 강력해질수록, 단순한 소프트웨어 기능만으로는 방어하기 어려워진다는 주장이 힘을 얻고 있는데요. 이 글은 앞으로 애플리케이션 회사가 살아남으려면 단순 SaaS가 아니라, 사용자의 판단과 수정 기록을 축적하는 데이터 회사이자 돈의 흐름을 잡는 핀테크 회사가 되어야 한다고 봅니다. 특히 Cursor, Harvey, Figma, Linear 같은 사례를 통해 인터페이스보다 더 중요한 것은 사람들이 수년간 남긴 수정/선택.거절의 기록이라는 점을 강조합니다. 모든 제품이 이 방향으로 가야 하는 것은 아니겠지만, AI 시대의 해자가 어디에 생길지를 고민하는 창업자라면 읽어볼 만한 글입니다.

"프롬프트 엔지니어링에서 하네스 엔지니어링으로" 흐름이 이어지는 가운데, 에이전트/서비스.워크플로우를 하나의 런타임에서 묶는 Go 프레임워크입니다. 서비스의 모든 엔드포인트가 자동으로 AI 호출 가능한 도구가 되고, MCP/A2A로 외부에 노출되며, MaxSteps/LoopLimit 같은 가드레일이 실행 지점에 내장돼 있습니다. Go의 단순한 인터페이스와 배포 특성이 에이전트 런타임과 잘 맞을 수 있다는 점에서도 흥미로운 프로젝트입니다.

로그와 Observability는 처음에는 grep과 대시보드 정도로 충분해 보이지만, 데이터가 커지는 순간 저장 구조와 비용 모델이 급격히 중요해집니다. 이 글은 ClickHouse가 왜 대용량 로그와 이벤트 데이터에 잘 맞는지, 컬럼 지향 저장·압축률·샤딩 방식·SQL 기반 질의라는 관점에서 설명합니다. 특히 1TB/일, 5TB/일, 10TB/일 규모에서 Elasticsearch, LGTM, Datadog, ClickHouse의 운영 모델과 비용이 어떻게 달라지는지 비교하는 부분이 실용적입니다.

Anthropic이 Opus급 에이전트 실행 능력을 Sonnet 가격대로 내리는 것을 목표로 내놓은 모델로, effort 조절로 비용과 성능의 균형을 세밀하게 고를 수 있게 한 점이 특징입니다. 다만 댓글 반응에서도 보이듯, “가장 똑똑한 모델”과 “내 작업에 가장 잘 맞는 모델”은 점점 다른 문제가 되고 있습니다. AI 코딩 도구를 쓰는 입장에서는 이제 모델 이름만 고르는 것이 아니라, 작업 성격에 맞춰 모델/effort/비용 한도/검증 방식을 함께 설계해야 하는 단계로 넘어가고 있습니다.

YAGNI는 흔히 “아직 필요 없는 코드는 쓰지 말라”는 절약 규칙처럼 이해되지만, 이 글은 그보다 더 중요한 선택권의 비용을 이야기합니다. 실제 요구사항이 오기 전에 구조를 미리 만들면, 코드 작성 비용보다 먼저 미래의 선택지를 닫아버리는 문제가 생깁니다. 특히 AI로 코드 생성 비용이 낮아진 지금은, 오히려 추측 기반의 구조와 프레임워크를 너무 쉽게 만들 수 있다는 점에서 YAGNI가 더 중요해졌습니다. “나중에 만들 수 있는 능력”을 유지하는 것이 단순함의 진짜 가치라는 점을 잘 짚어주는 글입니다.

AI 슬롭과 비슷비슷한 온라인 조언이 넘쳐나는 시대에, 이 글은 “더 많이 아는 것”보다 직접 살아낸 경험이 왜 중요한지를 이야기합니다. Good Will Hunting의 벤치 장면과 Robin Williams의 연기를 통해, 같은 정보와 대본이 있어도 사람마다 전혀 다른 깊이를 만들어낸다는 점을 잘 보여줍니다. AI는 인터넷을 읽었지만 삶을 살아본 적은 없고, 그래서 창작자가 자기만의 작은 삶의 순간들을 작업에 넣는 일이 더 중요해집니다. 글쓰기, 제품, 콘텐츠를 만드는 사람이라면 “정보를 잘 배열하는 것”과 “의미를 담는 것”의 차이를 다시 생각하게 됩니다.

AI가 사람을 대체할 것이라는 경영진의 낙관이 실제 조직 운영에서는 얼마나 좋지 않게 작동할 수 있는지를 보여주는 사례네요. Meta가 에이전트형 AI 개발에 맞춰 조직을 크게 흔들었지만, 정작 기대한 만큼의 가속은 나오지 않았다는 점이 핵심입니다. 이 글은 단순히 Meta 비판이라기보다, AI 도입 속도와 조직 전략을 혼동할 때 어떤 문제가 생기는지를 보여줍니다. AI가 강력한 도구인 것은 맞지만, 명확한 제품 방향과 검증 가능한 실행 계획 없이 “대체 가능성”만 앞세우면 조직의 신뢰와 실행력이 먼저 흔들릴 수 있습니다.

온라인 서비스에서 연령 확인 요구가 커지는 가운데, 개인정보를 과도하게 넘기지 않고도 조건을 증명할 수 있는 영지식 증명(ZKP) 의 중요성이 커지고 있습니다. Google이 공개한 이 라이브러리는 사용자가 “18세 이상” 같은 사실만 증명하고, 생년월일이나 신분증 정보는 드러내지 않도록 하는 방향을 제시합니다. 특히 EU의 디지털 신원 지갑과 연령 보장 논의가 본격화되는 시점이라, 기술적으로도 정책적으로도 의미가 있습니다. 한국처럼 실명/본인확인 인프라가 강한 환경에서는, “확인”과 “노출”을 분리하는 방식이 더 낯설지만 그래서 더 생각해볼 만합니다.

대형 조직에서는 코드가 하나의 저장소에만 머물지 않고, 내부 저장소와 공개 저장소, 고객별 배포 저장소 사이를 계속 오가야 하는 경우가 많습니다. Copybara는 이런 흐름에서 Source of Truth 를 유지하면서도, 다른 저장소의 변경을 변환해 가져오거나 내보낼 수 있게 해주는 도구입니다. 특히 상태를 별도 서버가 아니라 커밋 메시지 라벨에 남기는 방식은 단순하면서도 재현성을 높여줍니다.

SSH는 여전히 서버 작업의 기본 인터페이스지만, 모든 원격 작업을 터미널로만 해야 하는 것은 아닐 수 있습니다. 이 글은 SSH 위에서 동작하는 그래픽 셸을 통해, 원격 서버나 엣지 기기의 앱을 브라우저식 홈 화면과 앱 간 연결 방식으로 다루는 아이디어를 제안합니다. 각 앱은 작은 HTTP 서버로 UI를 제공하고, 암호화와 접근 제어는 SSH 계층에 맡기는 구조라 단순함도 유지됩니다.

Docker가 사실상 표준처럼 자리 잡은 뒤에도, 루트리스 컨테이너와 systemd 통합을 앞세운 Podman은 꾸준히 다른 방향의 선택지를 만들어 왔습니다. 이번 6.0 릴리스는 Netavark, Pasta, nftables 기반으로 네트워킹을 정리하고, Podman Machine과 Quadlet을 개선하면서 운영 환경 쪽의 완성도를 높이는 데 초점을 둡니다. 다만 댓글에서도 보이듯, Docker Compose와의 호환성이나 macOS 개발 경험은 여전히 선택을 망설이게 만드는 지점입니다.

AI 제품은 전통적인 SaaS와 달리 사용자가 많아질수록 단순히 서버 비용만 늘어나는 것이 아니라, 추론 비용이 고객별로 크게 달라진다는 점이 중요합니다. 같은 월 구독료를 내는 고객이라도 한쪽은 거의 비용을 쓰지 않고, 다른 한쪽은 매출총이익을 크게 갉아먹을 수 있기 때문입니다. 이 글에서 제안하는 Compute-adjusted LTV는 AI 제품의 가격 책정과 고객 세그먼트 분석에서 반드시 봐야 할 지표가 되어가고 있습니다. AI 서비스를 만들고 있다면 “사용량이 많다”를 무조건 좋은 신호로 보기 전에, 그 사용량이 고착성인지 손실인지를 구분해야 한다는 점을 잘 짚어줍니다.

ProseMirror와 CodeMirror를 만든 Marijn Haverbeke가 다시 리치 텍스트 편집기를 만든다는 것만으로도 충분히 주목할 만한 프로젝트입니다. Wordgard는 ProseMirror를 2.0으로 고치는 대신, 9년간의 운영 경험을 살려 호환성 부담 없이 새로 설계한 편집기 라이브러리입니다. steps 대신 섹션 기반 변경 모델을 쓰고 CodeMirror식 facet 확장을 결합해, 협업 편집과 문서 조작을 다루기 쉽게 만든 점이 눈에 띕니다.

뉴스레터를 모아 보던 국내 서비스 헤이버니가 7월 31일자로 문을 닫습니다. 운영 비용과 환경을 종합한 결과 지속이 어렵다고 판단하셨다는데, 긱뉴스 위클리를 헤이버니로 받아보던 구독자도 적지 않아 아쉬움이 남습니다. 지금 이 메일을 헤이버니 주소로 받아보시는 분들은 구독하는 이메일 주소를 옮겨주세요.

요즘 커뮤니티는 Discord, Reddit, Slack 같은 플랫폼으로 많이 옮겨갔지만, 오래된 웹 포럼에는 여전히 다른 종류의 장점이 있었습니다. 검색 가능하고, 오래 남고, 커뮤니티마다 자기만의 규칙과 문화를 쌓아갈 수 있는 느린 대화의 공간이었기 때문입니다. 이 글은 Usenet, UBB, phpBB, vBulletin, Discourse로 이어지는 포럼의 역사를 훑으면서, 우리가 편리한 플랫폼을 얻는 대신 무엇을 잃었는지 보여줍니다. 빠른 피드와 알고리즘 추천이 지배하는 시대에, 다시 작고 느슨하지만 오래가는 커뮤니티 도구를 생각해 보게 합니다. 저는 유즈넷으로 인터넷을 시작해서 더욱 많이 와닿는 글이었어요.

에이전트를 잘 쓴다는 것은 이제 “프롬프트를 잘 쓰는 것”을 넘어, 작업별로 어느 수준의 자율성을 허용할지 설계하는 것에 가까워지고 있습니다. 이 글은 단일 에이전트가 얼마나 멀리 갈 수 있는지와, 여러 에이전트를 얼마나 잘 조율할 수 있는지를 나누어 설명합니다. 특히 사람이 계획을 주도하고 에이전트가 실행을 맡는 현재의 사용 패턴을 보면, 완전 자동화보다 위험도에 맞춘 자율성 조절이 더 현실적인 방향으로 보입니다.

Anthropic은 미국 정부와의 대화 이후 Fable 5 사이버보안 보호장치를 업데이트하고 드디어 접근을 재개했습니다. 하지만 무해한 요청까지 넓게 플래그 하면서 Opus 4.8로 폴백되는 사례가 잦고, 성능도 떨어졌다는 불만이 많네요. 곧 GPT-5.6 Sol 이 공개된다고 하는데 얼른 비교해보고 싶어지네요.