Lobsters

AI 에이전트의 병목은 모델 성능이 아니라 도구 호출(tool calling) 계약이다. 모델이 더 똑똑해질수록, 다른 하네스(harness)에서는 더 고집스럽게 틀릴 수 있다. AI 에이전트, 코딩 에이전트, MCP, 하네스 자동화가 만나는 지점에서 위험한 착각이 하나 있다. 성능 좋은 모델을 붙이면 운영 품질도 같이 오른다는 믿음이다. 실제 장애는 반대쪽에서 난다. 모델은 정답에 가까운 편집 내용을 만들고도, 스키마에 없는 필드를 끼워 넣어 도구 호출을 실패시킨다. Armin Ronacher가 공개한 사례는 이 문제를 정확히 보여준다. Pi의 편집 도구는 edits[] 안에 oldText, newText를 받는 중첩 스키마를 쓴다. 그런데 Opus 4.8과 Sonnet 5는 같은 배열 안에 requireUnique, oldText2, matchCase, in_file, forceMatchCount 같은 존재하지 않는 키를 붙였다. 더 불편한 점은 편집 본문 자체는 바이트 단위로 맞았다는 것이다. 지능은 맞았고, 계약은 틀렸다. ...

비밀 관리는 .env를 어디에 둘지의 문제가 아니다. Python 에이전트, Go 검증기, Node.js API가 같은 정책으로 같은 비밀을 읽는지의 문제다. SecretSpec 0.13은 비밀 관리(secrets management)를 SDK 편의 기능처럼 발표했지만, 실무에서 다뤄야 할 쟁점은 더 크다. 하나의 secretspec.toml 선언을 Python, Node.js/TypeScript, Go, Ruby, Haskell 런타임에서 같은 방식으로 해석하게 만들었기 때문이다. 이 변화는 멀티 에이전트와 폴리글랏 인프라에서 자주 반복되는 문제를 건드린다. 서비스마다 비밀을 읽는 코드가 달라지고, 감사 로그가 빠지고, 장애 시 fallback 동작이 언어별로 어긋나는 문제다. ...

한 줄 요약: Guix substitute와 guix pull 취약점은 재현 가능한 빌드만으로는 소프트웨어 공급망 보안을 설명하기 어렵다는 사례다. 패키지 매니저의 신뢰 경계는 빌드 결과물뿐 아니라 업데이트 경로, 캐시, 키, 롤백 정책까지 포함한다. 왜 지금 이슈인가 개발자 커뮤니티에서 Guix 취약점이 이야기되는 이유는 Guix 자체의 점유율 때문만은 아니다. Guix는 재현 가능한 빌드(Reproducible Build), 함수형 패키지 관리, 롤백 가능한 프로필을 핵심 기능으로 삼아 온 도구다. 그런 도구에서도 guix substitute와 guix pull 같은 업데이트 경로가 문제가 될 수 있다는 점은 생각할 거리를 남긴다. ...

한 줄 요약: TLS 1.3에 ML-KEM을 넣는 논쟁은 포스트 양자 암호 전체의 문제가 아니라 더 좁은 운영 판단에 가깝다. RFC가 됐다는 사실을 보안성 검증으로 볼 것인지, 운영자가 따로 검증해야 할 선택지가 늘었다고 볼 것인지가 갈림길이다. 왜 지금 이슈인가 TLS, ML-KEM, IETF라는 단어가 한 문장에 붙으면 흐름은 대체로 정해져 보인다. 양자 컴퓨터에 대비해야 하고, 표준화가 필요하며, 구현 생태계도 따라와야 한다는 이야기다. 하지만 이번 논쟁의 불편한 지점은 포스트 양자 암호(Post-Quantum Cryptography)를 도입할지 말지가 아니다. TLS 1.3에서 ML-KEM을 어떤 형태로 넣을 것인지, 특히 기존 타원곡선 키 교환(ECDH)과 ML-KEM을 함께 쓰는 하이브리드 방식이 아니라 solo ML-KEM을 허용하는 RFC를 낼 것인지가 쟁점이다. ...

한 줄 요약: LUKS 전체 디스크 암호화는 노트북 전원이 꺼졌을 때 저장장치를 보호하는 장치다. suspend 상태에서 메모리까지 자동으로 안전해지는 것은 아니다. Linux 6.9 이후 LUKS 키가 suspend 동안 메모리에 남아 있었다는 제보도 결국 암호화 알고리즘보다 전원 상태와 운영 정책을 먼저 봐야 한다는 쪽에 가깝다. 왜 지금 이슈인가 Linux LUKS, suspend, 디스크 암호화, 커널 메모리 보안은 각각 놓고 보면 익숙한 주제다. 그런데 노트북을 덮은 뒤에도 LUKS 키가 메모리에 남아 있을 수 있다는 이야기가 나오면 논점이 조금 달라진다. ...

한 줄 요약: LLM 생성 코드가 의존성에 섞이는 문제는 취향 논쟁이 아니라 공급망 보안, 리뷰 비용, 유지보수 책임의 문제다. 먼저 볼 것은 출처, 검증 가능성, 장애가 났을 때 고칠 사람이 남아 있는 구조다. 왜 지금 이슈인가 LLM이 만든 코드, 오픈소스 공급망 보안, 에이전트가 올리는 PR은 이제 따로 보기 어렵다. 더 까다로운 질문은 “누가 썼나”가 아니라 “왜 이렇게 만들었는지 설명할 사람이 있나”다. git-annex의 Joey Hess는 LLM 생성 코드가 들어간 의존성을 피하려고 의존성 트리를 계속 점검했다고 썼다. 그 과정에서 큰 변경이 다음 릴리스에서 설명 없이 되돌려진 사례, 2만 6천 줄 규모 코드베이스에 1만 줄 변경과 1,489줄짜리 이상한 커밋 메시지가 붙은 사례, 다른 프로젝트 코드를 복사하라는 프롬프트에 가까운 변경을 봤다고 한다. ...

한 줄 요약: ClickHouse 기반 관측성이 자주 거론되는 이유는 로그 저장소를 싸게 바꾸자는 이야기가 아니라, 로그·메트릭·트레이스 비용과 장애 조사 방식이 같은 병목에 걸렸다는 신호다. 왜 지금 이슈인가 로그(Log)는 팀이 작을 때 가장 직관적인 디버깅 도구다. tail -f, grep, jq로 바로 답을 찾던 경험은 강력하다. 문제는 서비스 수, 팀 수, 데이터 소비자가 늘어나는 순간 그 방식이 거의 그대로 유지되지 않는다는 데 있다. 선정 글감이 건드리는 지점도 여기다. 관측성 플랫폼 논쟁은 Elasticsearch냐 Loki냐 Datadog이냐 ClickHouse냐의 제품 비교처럼 보이지만, 실제로는 로그를 누가 어떤 기대치로 소비하느냐의 문제에 가깝다. ...