에이전트가 실패하는 순간은 모델이 답을 틀릴 때만이 아니다. 코딩 하네스와 관측성 시스템이 그 실패를 정상 실행처럼 기록할 때 문제가 커진다. Codex 이슈 #30364에서 볼 대목은 516이라는 숫자 자체가 아니다. reasoning token, 모델 품질, 비용 제어, 하네스 실행 환경이 한 지점에서 부딪혔다는 점이다. 에이전트가 긴 작업을 맡으면 모델 선택은 API 호출 옵션을 넘어 운영 정책이 된다. Codex reasoning token 516 이슈가 말하는 문제 해당 이슈의 주장은 조심스럽다. 작성자는 비공개 Chain-of-Thought가 잘렸다고 단정하지 않는다. 대신 Codex의 token_count 메타데이터에서 GPT-5.5 응답이 reasoning_output_tokens 516에 비정상적으로 몰린다고 말한다. ...
홈랩, 셀프호스팅, 인프라 자동화, 관측성 논쟁의 핵심은 장비 숫자가 아니다. 운영 책임을 어디에 둘 것인가다. 서버를 네 대에서 한 대로 줄인 사람은 자유를 얻었고, LLM 게이트웨이를 직접 띄우려는 팀은 비용과 데이터 경로를 되찾으려 한다. 둘 다 같은 질문으로 모인다. 직접 운영한다는 말은 통제권을 갖는다는 뜻이다. 동시에, 장애의 마지막 담당자가 자신이라는 뜻이다. 셀프호스팅은 취미가 아니라 책임 경계 설계다 원문 속 홈랩은 일부러 작다. 여러 서버, 클러스터, 하이퍼바이저, 하이브리드 클라우드 조합을 버리고 단일 물리 서버 하나로 서비스를 모았다. 작성자는 네 대에서 한 대로 줄였기 때문에 유지보수가 75% 줄었다고 말한다. 이 수치는 멋진 자동화 도구보다 더 강한 메시지를 가진다. ...
Testcontainers는 실제 의존성을 띄운다. 그래서 믿음직해 보인다. 문제는 운영 장애가 실제 의존성의 정상 동작에서만 나오지 않는다는 점이다. 테스트 자동화에서 mocks, Testcontainers, fakes 논쟁이 다시 붙는 이유는 단순하다. 코드 생성 에이전트가 더 많은 코드를 만들수록, 팀의 병목은 작성 속도가 아니라 깨진 것을 얼마나 빨리 잡느냐로 옮겨간다. 빠른 테스트도 필요하고 실제 서비스에 가까운 테스트도 필요하다. 다만 둘 다 운영 장애의 핵심인 부분 실패(partial failure)를 놓치면 하네스는 안심 장치가 아니라 장식이 된다. Testcontainers가 잡는 버그와 끝내 놓치는 버그 Testcontainers의 장점은 분명하다. PostgreSQL, Kafka, Redis 같은 실제 의존성을 Docker 컨테이너로 띄우면 SQL 문법, 마이그레이션, 드라이버 설정, 기본 연결 흐름을 검증할 수 있다. 이 층의 버그는 mock으로 잡기 어렵다. ...
첫 줄부터 긴장감이 있다. 2003년에 나온 Command & Conquer Generals: Zero Hour가 Apple Silicon Mac, iPhone, iPad에서 네이티브로 돈다는 소식은 단순한 복고 게임 포팅으로 끝나지 않는다. 더 날카로운 쟁점은 작업 방식이다. 이 포트의 README는 엔진 포팅과 수정 작업이 Claude Code의 Fable 모델, 인간 디렉션, 실제 기기 플레이테스트를 거쳐 만들어졌다고 밝힌다. 사람들은 게임보다 먼저 작업 방식에 반응했다. GPL로 공개된 옛 엔진, 별도 보유가 필요한 상용 게임 에셋, DirectX 8에서 Metal까지 이어지는 그래픽 변환층, 코딩 에이전트가 남긴 대형 포팅 로그가 한 화면에 같이 놓였다. Hacker News에서 이 글감이 482포인트와 192개 댓글을 모은 이유도 여기에 있다. “AI가 게임을 포팅했다”는 식의 요약보다, 오래된 코드베이스의 운영 리스크를 어디까지 자동화에 맡길 수 있는지가 핵심에 가깝다. ...
Codex GPT-5.5 reasoning tokens 논란의 핵심은 한 번의 오답이 아니다. 사용자가 볼 수 없는 예산 경계가 516, 1034, 1552 같은 숫자로 드러난 것처럼 보였고, 그 경계가 복잡한 Codex 작업의 성능 저하와 겹쳤다는 점이다. 모델이 틀릴 수 있다는 사실은 모두 안다. 더 불편한 문제는 왜 틀렸는지 추적할 수 없는 상태에서, 에이전트가 조용히 덜 판단한 것처럼 보이는 순간이다. Codex GPT-5.5 516 토큰 논란은 성능보다 신뢰 문제다 2026년 6월 27일, GitHub의 openai/codex 공개 저장소에 이슈 #30364가 올라왔다. 작성자는 2026년 2월 1일부터 6월 27일까지의 Codex token_count 메타데이터를 분석했고, GPT-5.5 응답이 reasoning_output_tokens = 516에 비정상적으로 몰린다고 주장했다. ...
Linux kernel epoll 취약점 CVE-2026-46242의 핵심은 낯선 API가 아니다. 끌 수 없는 커널 기본 기능에서 6개 명령어 폭의 레이스가 99% 신뢰도의 권한 상승으로 이어졌다는 점이다. Bad Epoll은 epoll 서브시스템의 레이스 컨디션(Race Condition) 기반 사용 후 해제(Use-After-Free, UAF) 취약점이다. 비권한 프로세스가 root 권한을 얻을 수 있으며, 대상은 일반 Linux 서버와 데스크톱에 그치지 않는다. Android 기기와 Chrome 렌더러 샌드박스 이후 단계까지 위험 범위에 들어간다. 이 사건은 “AI가 커널 취약점을 찾을 수 있는가”보다 “AI가 찾은 버그 옆에 무엇이 남아 있었는가”에 가깝다. Anthropic의 Mythos는 같은 epoll 코드 경로에서 다른 레이스 버그를 찾았다. 그러나 Bad Epoll은 놓쳤다. 사람 연구자는 그 틈에서 실제 exploit과 root shell까지 도달했다. ...
구글북스 스캔 데이터에 20만 달러 바운티가 걸렸다는 말은 디지털 보존 이야기처럼 들리기 쉽다. 하지만 이 사건의 핵심은 책을 누가 더 사랑하느냐가 아니다. 검색창 뒤에 있는 대규모 문화 데이터가 누구의 통제 아래 있어야 하는지, 그 통제를 깨려는 시도를 보존으로 볼지 침해로 볼지의 문제다. Anna’s Archive 쪽 이슈는 Google Books 또는 비슷한 규모의 전체 도서 스캔 컬렉션을 확보하는 방법에 200,000달러 보상금을 제시한다. 설명은 노골적이다. Google Books에는 많은 스캔 도서가 있지만 검색 결과 주변의 작은 스니펫으로만 노출된다고 적었다. 확장 가능한 방법을 찾으면 일찍 연락하라고 했고, Google 내부 접근권한이 있는 사람에게는 데이터를 빼내면 전설적인 아키비스트로 불릴 것이라는 문장까지 붙었다. ...
닫힌 냉각 루프(Closed-loop cooling)는 Meta 데이터센터 폐수 논쟁에서 방패처럼 쓰였다. 물을 계속 증발시키는 대신 한 번 채운 뒤 순환시킨다는 설명은 그럴듯하다. 그런데 와이오밍주 샤이엔(Cheyenne)에서는 바로 그 한 번 채우고 씻어내는 과정이 도시 재생수 시스템을 멈춰 세웠다. Meta 데이터센터 폐수 사건의 핵심은 물 사용량이 아니다 확인된 사실부터 좁혀보자. 2026년 7월 2일, 샤이엔 공공유틸리티위원회(BOPU)는 데이터센터의 fill-and-flush와 폐쇄형 냉각 시스템 관련 산업폐수를 더 받지 않겠다고 밝혔다. Tom’s Hardware가 2026년 7월 4일 보도한 내용에 따르면, 오염원은 Meta 샤이엔 캠퍼스 공사에 참여한 법인 Goat Systems LLC로 추적됐다. ...
AI 에이전트의 LLM 비용 문제는 더 싼 모델을 고르는 일로 끝나지 않는다. 길어진 시스템 프롬프트, 도구 문서, 로그, 과거 대화가 매 요청마다 컨텍스트로 붙으면 비용은 모델 선택보다 컨텍스트를 어떻게 운반하느냐에 더 크게 흔들린다. pxpipe가 던진 질문은 단순하다. 텍스트를 꼭 텍스트 토큰으로 보내야 하는가. LLM 비용 최적화는 압축률보다 손실 경계가 먼저다 pxpipe는 Claude Code류 작업에서 부피가 큰 입력을 PNG 이미지로 렌더링해 모델이 OCR처럼 읽게 만든다. 처음 보면 꼼수처럼 들린다. 텍스트 토큰은 글자 수와 강하게 묶이지만, 이미지 토큰 비용은 픽셀 크기에 묶인다. 코드, JSON, 툴 출력처럼 빽빽한 텍스트는 이미지 한 장에 많이 들어간다. ...
AI 에이전트의 병목은 모델 성능이 아니라 도구 호출(tool calling) 계약이다. 모델이 더 똑똑해질수록, 다른 하네스(harness)에서는 더 고집스럽게 틀릴 수 있다. AI 에이전트, 코딩 에이전트, MCP, 하네스 자동화가 만나는 지점에서 위험한 착각이 하나 있다. 성능 좋은 모델을 붙이면 운영 품질도 같이 오른다는 믿음이다. 실제 장애는 반대쪽에서 난다. 모델은 정답에 가까운 편집 내용을 만들고도, 스키마에 없는 필드를 끼워 넣어 도구 호출을 실패시킨다. Armin Ronacher가 공개한 사례는 이 문제를 정확히 보여준다. Pi의 편집 도구는 edits[] 안에 oldText, newText를 받는 중첩 스키마를 쓴다. 그런데 Opus 4.8과 Sonnet 5는 같은 배열 안에 requireUnique, oldText2, matchCase, in_file, forceMatchCount 같은 존재하지 않는 키를 붙였다. 더 불편한 점은 편집 본문 자체는 바이트 단위로 맞았다는 것이다. 지능은 맞았고, 계약은 틀렸다. ...