아무도 쓰지 않는 회귀 테스트가 실제 동작을 고정한다

Stack Overflow 원문

응답은 그대로인데 뒤에서 DB 쿼리가 하나 늘어난 회귀는, 의도를 적은 일반 테스트로는 절대 잡히지 않습니다.

• 오래 운영된 시스템에는 아무도 계획하지 않고 기록하지 않은 동작 층이 쌓입니다. 2019년에 누군가 정한 기본값, 이상한 엣지 케이스 같은 것들입니다. Hyrum의 법칙대로 사용자가 충분히 많으면 문서화된 계약뿐 아니라 결과 순서, 에러 문구, 필드가 null인지 아예 없는지까지 누군가는 의존하게 되는데, 일반 회귀 테스트는 작성자가 의도한 것만 검사하므로 이런 우발적 동작을 놓칩니다.
• 해법은 Michael Feathers가 「레거시 코드 활용 전략」에서 말한 특성화 테스트입니다. 이해하지 못한 코드를 건드리기 전에 "해야 하는 일"이 아니라 "지금 하는 일"을 테스트로 고정하고, 버그처럼 보여도 일단 고정합니다. 정확성이 아니라 동작이 바뀌는 순간 알려주는 안전망이 목적입니다. 일반 테스트가 "코드야, 이걸 지켜라"라면 특성화 테스트는 "이게 현실이니 바꾸려면 이유가 있어야 한다"입니다.
• 널리 쓰이지 않는 이유는 사람 쪽에 있습니다. 입력과 출력을 하나씩 적는 일이 고되고, 버그로 보이는 동작을 단언하는 것이 본능에 어긋납니다. 골든 마스터 테스트와 프런트엔드 스냅샷이 비용을 낮췄지만 함수나 컴포넌트에 강하고 서비스에는 약합니다. 서비스의 동작은 반환값뿐 아니라 어떤 쿼리를 날리고 어떤 서비스를 부르고 어떤 메시지를 보내는지까지 포함하기 때문입니다.
• 저자의 제안은 운영 트래픽 자체를 특성화 테스트로 쓰는 것입니다. 네트워크 수준에서 요청과 응답, 그리고 DB와 큐를 포함한 의존 서비스로 나가는 호출을 녹화하고, 나중에 의존성을 같은 녹화로 응답시키며 재생합니다. 응답이 같아도 DB 호출이 하나 늘면 diff에 드러나므로, 테스트에서는 무해하고 규모에서는 치명적인 새 쿼리 같은 회귀를 잡습니다. 타임스탬프와 생성 ID 같은 잡음 필드만 정확히 무시해야 신호가 묻히지 않습니다.
• 빨간 특성화 테스트는 버그가 아니라 "동작이 바뀌었다"는 뜻이고, 다음 질문은 "의도한 변화인가"입니다. 이 diff를 PR에서 리뷰하면 동작 변화가 사고에서 결정으로 바뀝니다. 효과가 큰 경우로 레거시 리팩터링, 프레임워크와 ORM 메이저 업그레이드, 언어나 아키텍처를 바꾸는 재작성(옛 서비스의 녹화가 곧 새 서비스의 명세가 됩니다), 그리고 AI가 코드와 테스트를 함께 고친 변경을 듭니다.

마지막 경우가 핵심입니다. AI가 코드와 테스트를 함께 고치면 테스트가 변경과 같은 가정을 공유하게 되는데, 사전에 캡처한 기준선은 그 가정을 공유하지 않는 드문 독립 검증입니다. 재작성이나 메이저 업그레이드를 앞둔 서비스가 있다면 바로 적용해 볼 만하고, 녹화와 재생 도구를 직접 만들지 않더라도 "응답이 같다"와 "동작이 같다"를 구분하는 리뷰 관점만 가져와도 값이 있습니다.

읽을 만한 것

AI가 생성한 HTML 미리보기는 샌드박스만으로 부족하다

Frontend Masters 원문

sandbox를 켜도 fetch와 new Image().src로 토큰이 밖으로 나가며, 이를 막는 것은 sandbox가 아니라 별개의 CSP입니다.

• 가장 흔한 첫 구현은 모델 출력을 iframe.srcdoc에 넣는 두 줄입니다. sandbox 없는 srcdoc iframe은 호스트와 같은 origin에서 돌아서 parent.document, parent.localStorage, 쿠키에 접근합니다. 프롬프트에는 사용자나 모델이 읽은 문서가 넣은 내용이 담기므로, 이는 낯선 사람의 HTML을 읽지도 않고 앱에 붙이는 일입니다. 보안 엔지니어인 저자 자신도 읽지 않은 코드를 세션이 보이는 문서에 렌더링했다고 고백합니다.
• sandbox="allow-scripts"를 켜면 프레임은 opaque origin을 받아 부모 DOM을 읽을 때 SecurityError가 납니다. 최상위 창 이동, 팝업, 폼 제출은 토큰을 따로 주지 않으면 막히는데, 사람들은 뭔가 깨질 때 allow-top-navigation이나 allow-same-origin을 무심코 붙입니다. 특히 allow-scripts와 allow-same-origin의 조합은 프레임이 자기 sandbox 속성을 지우고 다시 로드해 제한을 벗을 수 있게 하므로 금지입니다.
• sandbox는 프레임이 페이지에 하는 일을 막을 뿐 네트워크를 막지 않습니다. fetch나 new Image().src로 URL에 데이터를 실어 밖으로 보낼 수 있고, 이를 막는 것은 미리보기 문서의 CSP(default-src 'none')입니다. sandbox와 CSP는 서로 다른 구멍을 막는 독립 통제이므로 둘 다 필요합니다. 다만 프레임이 스스로 이동하는 것까지 막지는 못하는 한계는 남습니다.
• 메시지 채널은 event.source로 검증합니다. sandbox된 프레임은 origin이 모두 문자열 "null"로 직렬화되므로 이를 허용 목록에 넣어 발신자를 식별할 수 없습니다. 대신 임베드한 contentWindow와 event.source를 비교하고, 페이로드 형태를 검증하고, 높이 같은 값은 범위로 제한합니다. 비공개 통로가 필요하면 MessageChannel을 씁니다.
• 고가치 서비스라면 사용자 콘텐츠를 별도의 버리는 도메인에서 서빙합니다. CodePen이 결과를 cdpn.io에서 서빙하는 이유와 같습니다. sandbox 탈출이 일어나도 세션, 쿠키, 다른 고객 데이터가 없는 origin에 떨어집니다.

저자가 제시한 순서는 빈 sandbox, 이유를 주석으로 단 allow-scripts 하나, 별도 origin, CSP, 좁은 메시지 검증입니다. LLM 출력물을 화면에 그리는 기능을 만들고 있다면 그대로 체크리스트로 쓸 수 있고, 특히 "sandbox를 켰으니 됐다"는 흔한 착각 하나를 바로잡아 줍니다.

Docker는 이상하다, 컨테이너는 실재하지 않는다

codeandcake.dev (Lobsters 경유) 원문

Docker의 런타임 runc는 Go에 fork가 없고 런타임이 멀티스레드라서, Go가 초기화되기 전에 도는 C 모듈과 /proc/self/exe 재실행으로 우회합니다.

• 컨테이너는 VM과 달리 실재하는 단위가 아닙니다. 특수한 제한이 걸린 평범한 프로세스이고 호스트 커널이 그대로 실행하므로 /proc에서 찾을 수 있습니다. 리눅스에 "컨테이너"라는 기능은 없고, 호스트와 컨테이너가 보는 것을 가르는 namespace, 자원을 제한하는 cgroup, 네트워크 격리 같은 다섯 가지 커널 기능을 겹쳐 입은 것입니다.
• 이미지는 Docker가 어딘가에 풀어 둔 폴더이고, 실행은 그 폴더를 chroot(또는 pivot_root)로 프로세스의 새 루트 디렉터리로 삼는 일입니다. docker run -it --rm ubuntu /bin/bash는 이미지를 받아 어딘가에 두고 그 안의 bash를 실행하는 것뿐입니다.
• Docker의 런타임 runc는 Go로 쓰였는데, 필요한 syscall 일부는 단일 스레드 환경에서 해야 하지만 Go 런타임은 기본이 멀티스레드입니다. 그래서 runc는 Go 런타임이 초기화되기 전에 도는 C 모듈로 그 syscall을 처리합니다. Go에는 fork도 없습니다. 필요한 것은 fork 후 제한을 걸고 exec하는 흐름이라, runc는 특별한 인자를 준 /proc/self/exe를 다시 exec해 자식 프로세스를 흉내 냅니다.
• 컨테이너 런타임이 쓰는 많은 커널 API는 root를 요구했거나 요구하므로 Docker 데몬은 보통 root로 돕니다. macOS에서 쓰면 놓치기 쉬운 점입니다. 요즘은 나아졌지만 rootless 런타임은 같은 네트워킹 기능을 주려고 네트워크 스택을 사용자 공간에서 다시 구현해야 합니다.

쓰는 도구를 직접 만들어 보는 것이 배우는 좋은 방법이라는 것이 저자의 결론입니다. SSR 컨테이너를 운영하면서도 그 아래가 궁금했던 분께 짧고 명확한 입문이 되고, "컨테이너는 그냥 프로세스"라는 한 문장은 디버깅할 때 호스트의 /proc과 일반 도구를 왜 그대로 쓸 수 있는지 설명해 줍니다.

장기 정적 자격증명을 없애자, OIDC로 가는 Vercel의 마감일

Vercel 원문

1,000곳 넘는 SaaS 벤더 중 안전한 인증 방식을 지원하는 곳은 8.4%뿐이고, Vercel은 마켓플레이스 벤더에 2026-11-30 경고, 2027년 1월 퇴출이라는 마감일을 겁니다.

• 주장은 기계 간 인증이 지금 2010년의 HTTPS와 같다는 것입니다. OAuth, OIDC, DBSC 같은 표준은 이미 있지만 API 키와 DB 비밀번호 같은 만료 없는 정적 자격증명이 SaaS의 기본값입니다. 이런 자격증명은 저장소나 채팅에 새고, 침해된 의존성이 운영 환경에서 읽어 가고, 에이전트가 프롬프트 인젝션으로 노출할 수 있으며, 폐기될 때까지 권한이 그대로 쓰입니다. Vercel은 과거 키 교체에 수천 시간의 엔지니어링을 썼다고 밝힙니다.
• 대안은 OIDC입니다. 신뢰하는 발급자가 앱을 식별하는 서명된 단기 토큰을 주고 수신 서비스가 검증합니다. 훔친 토큰은 만료와 함께 쓸모가 없어지고, 앱이 프로그램으로 새 토큰을 받으므로 키를 퍼뜨리고 수동 교체할 필요가 없습니다. Vercel의 OIDC 연합은 2024년부터 GA였고, 앱이 Vercel 토큰을 AWS, GCP, Azure의 임시 자격증명으로 바꿀 수 있습니다.
• 채택이 안 되는 이유로 세 가지를 듭니다. 정적 키보다 설정이 복잡하고, 요청 경로에서 토큰을 받거나 교환하는 지연이 늘며, 벤더가 지원할 유인이 약합니다. 1,000곳 넘는 SaaS 벤더를 조사하니 안전한 인증 방식을 지원하는 곳은 8.4%였습니다. 환경 변수의 키는 네트워크 요청이 필요 없지만 토큰은 필요하다는 점을 인정하고, 요청 헤더로 받는 토큰의 재사용과 프로세스 내 캐시로 비용을 줄인다고 설명합니다.
• 도구로는 신뢰 정책 폼과 서버 측 토큰 검증기를 담은 OIDC UI(shadcn/ui 레지스트리)와, 배포 신원으로 런타임에 제공자 토큰을 요청하는 Vercel Connect를 내놓습니다. 가장 눈에 띄는 것은 압박입니다. Chrome이 HTTP에 "Not secure" 표시를 붙이고 기한을 둔 방식을 따라, 2026-11-30까지 OIDC를 지원하지 않고 장기 비밀로 인증하는 마켓플레이스 벤더는 목록에 "Not secure"가 붙고 2027년 1월에는 퇴출됩니다.

제품 발표가 섞인 글이므로 도구 소개보다 주장과 마감일 설계에 주목할 만합니다. 에이전트에게 권한을 맡기는 시대에 자격증명의 수명을 줄이는 것이 공급망 방어의 일부라는 논지는 npm 공급망 쪽 관심사와 이어지고, 플랫폼이 기한으로 생태계를 미는 방식은 다른 곳에서도 따라 할 가능성이 큽니다.

Interop 2027 전에 보는 다음 CSS 후보

Josh Comeau 원문

Subgrid는 Firefox가 2019년에 구현하고도 정체했지만 Interop 2023에 들어가자 그해 안에 모든 브라우저로 퍼졌습니다.

• Interop은 Google, Apple, Microsoft, Mozilla가 Igalia, Bocoup과 함께 브라우저 지원을 맞추는 프로젝트입니다. 포커스 영역에 들어가면 보통 1년 안에 모든 브라우저에서 거의 100% 지원에 이릅니다. Subgrid는 2019년에 Firefox가 구현하고 몇 년간 정체했지만 Interop 2023에 들어가자 그해 안에 전 브라우저에 퍼졌습니다. Mozilla가 2027 후보를 투표받고 있어 저자가 투표한 상위 10개를 풀어 씁니다.
• CSS 함수(@function --name(--arg) { result: ... })는 Chrome 155와 Edge 154에 구현되어 있고 Firefox 157과 Safari 27에는 없습니다. 저자는 극좌표를 translate()로 바꾸는 함수처럼 반복되는 계산을 묶는 용도를 가장 기대합니다.
• corner-shape(bevel, squircle 등)와 border-shape는 clip-path나 mask와 달리 border-box 자체의 모양을 바꾸므로 테두리, outline, box-shadow가 바뀐 모양을 따라갑니다. 지원이 없는 브라우저에서도 점진적 향상으로 지금 쓸 만하다는 판단입니다.
• 앵커 포지셔닝 Level 2의 컨테이너 쿼리는 툴팁이 폴백 위치로 뒤집혔는지 CSS에서 알게 해 줍니다. 말풍선 꼬리 방향 같은 용도입니다. 아직 어떤 브라우저에도 없는 inherit() 함수는 상속값에 calc(inherit() - 4px)처럼 변환을 걸어 중첩 border-radius 문제를 풀고, 스크롤 트리거 애니메이션은 지금 IntersectionObserver로 하는 일을 CSS로 옮깁니다.
• reading-flow와 reading-order는 반응형 레이아웃에서 시각 순서와 DOM 순서가 달라 탭 순서가 틀어지는 접근성 문제를 풉니다. interpolate-size와 calc-size()는 height: 0에서 auto로의 애니메이션을 가능하게 합니다.

지금 당장 쓸 기능이 아니라 1년 뒤 어디까지 쓸 수 있을지 보는 지도입니다. Interop에 들어간 기능은 그해 안에 전 브라우저에 퍼진다는 전례가 있으니, 투표 결과가 나오면 2027년의 CSS 계획을 세우는 근거가 됩니다. 이 요약은 글의 앞 8개 항목을 기준으로 합니다.

짧게 알아두기

• Node.js 22.23.4 (LTS) Node.js Blog 보안 릴리스입니다. tls, dns, brotli 쪽 High 3건과 Medium 2건, Low 1건을 고쳤으니 22.x를 쓰는 환경은 올립니다.

수집 상태

수집 7609건, 본문 확보 24건, 실은 글 5편. 실패한 소스: CSS-Tricks (파싱 결과 0건)

코드를 이해하지 못할 때 에이전트로 디버깅하기

Martin Fowler 원문

에이전트에게 버그를 맡길 때 코드를 먼저 읽게 하는 것은 안티패턴이고, 코드 읽기는 조사의 맨 마지막 수단이어야 합니다.

• 핵심은 Cindy Sridharan의 장문 글 "How to effectively debug when you no longer understand the code"를 Fowler가 요약한 대목입니다. 출발점은 "에이전트는 사람이 아니다"라는 관찰입니다. 에이전트에게 사람의 문제 풀이 방식을 흉내 내게 하지 말고 에이전트의 강점을 쓰라는 것입니다.
• 버그 조사는 코드 읽기로 시작하지 않습니다. 코드를 읽어 가설부터 세우는 일은 조사의 맨 마지막 수단이어야 합니다. 먼저 시스템 동작에 대한 원자료(사실 계층)를 모두 모으고, 그다음 그 사실을 전부 만족하는 가설(가설 계층)을 찾습니다.
• 절차는 세 단계입니다. 사실 중 버그와 관련 있는 신호를 가려내고(이때 버그가 나지 않는 동작이라는 고품질 대조군이 필요합니다), 신호와 가장 잘 맞는 가설을 표로 비교하고, 남은 가설을 모든 사실에 제약 조건으로 대어 검증합니다.
• 사람과 에이전트는 데이터 취향이 반대입니다. 사람은 적은 데이터를 원해서 집계와 시각화를 만들었지만, 에이전트에게 집계는 신호의 가치를 없애는 경우가 많고 로그는 많을수록 좋습니다. 인용된 저자의 경험으로는 세 버그 모두 에이전트가 혼자 원인에 닿을 능력이 있었지만 대조군을 세우는 일조차 사람이 시켜야 했습니다.
• 같은 글의 앞부분에서 Fowler는 Gergely Orosz의 "AI 흔적이 보이면 전부 AI라고 간주한다"는 입장에 동의하면서도, 번역에 AI를 쓰는 비영어권 저자에게 불공정할 수 있다는 단서를 답니다.

결론은 에이전트 중심 세계에서 잘하는 엔지니어가 코드를 이해하는 사람이 아니라 검증 루프를 설계하는 사람이라는 것입니다. AI 시대의 리뷰와 검증 체계를 고민한다면 "대조군을 세우고 검증되지 않은 가설을 기각하는 것"이 사람의 일이라는 정의가 구체적인 출발점이 됩니다. 장애 조사에 에이전트를 붙여 본 적이 있다면 대시보드부터 보여 준 것이 왜 안 통했는지도 설명됩니다.

읽을 만한 것

웹 컴포넌트는 아무도 쓰지 않는 시대에 미래가 있나

Nolan Lawson 원문

웹 컴포넌트를 수년간 만든 저자가 직접, Google의 에이전트용 웹 가이드가 첫 6개월간 웹 컴포넌트를 거의 언급하지 않았다는 점을 근거로 그 존재 이유가 약해졌다고 씁니다.

• 웹 컴포넌트는 사람이 HTML을 손으로 치고 코드가 귀하니 재사용이 경제적 필수이던 세계를 전제로 설계됐습니다. 에이전트가 UI를 처음부터 생성하는 지금은 "공통 표준으로 만들면 쉽게 재사용된다"는 핵심 가치가 크게 약해졌다고 씁니다. 저자는 웹 컴포넌트 기반 프레임워크 LWC를 수년간 만든 사람이라 이 결론이 쓰기 고통스러웠다고 밝힙니다.
• 근거로 Google의 Modern Web Guidance를 듭니다. 에이전트가 CSS scroll snap, scroll-driven animations 같은 최신 브라우저 기능을 쓰도록 유도하는 스킬 모음인데, 첫 6개월간 웹 컴포넌트 언급이 거의 없었고 3주 전 커밋 하나로 비로소 들어왔습니다. 내용도 "커스텀 엘리먼트가 정말 필요한지 먼저 판단하라"는 식이라 새 제품을 만드는 에이전트가 웹 컴포넌트를 고를 가능성은 낮다고 봅니다. 쉐도우 DOM의 CSS 성능 이점도 Svelte, Vue, Tailwind 같은 컴파일 타임 스코핑으로 똑같이 얻는다고 직접 벤치마크했다고 말합니다.
• 영향은 웹 컴포넌트에서 끝나지 않습니다. "에이전트에게 더 낫다"는 분위기만으로 프레임워크를 통째로 갈아엎는 팀이 늘고 있고, 프레임워크 층을 일회용으로 보면 그 아래 층에 가치를 두기는 더 어렵습니다. shadcn처럼 보일러플레이트를 직접 소유하는 방식은 LLM 덕에 단점이 장점으로 바뀝니다. 다만 저자는 이런 재작성이 "토큰이 덜 든다", "사용자 경험이 빠르다" 같은 근거 위에서 이뤄져야 한다고 덧붙입니다.
• 구해낼 여지는 두 가지입니다. 에이전트 여럿이 UI의 다른 부분을 맡을 때 CSS, 이벤트, 전역을 격리하는 마이크로 프런트엔드 용도, 그리고 스탠드얼론 <emoji-picker> 같은 재사용은 여전히 의미 있다는 논리입니다. 하지만 격리는 iframe이 더 강하고, React가 이미 에이전트의 재사용 층이라는 반론에는 React가 마지막 프레임워크일 리 없다고 답합니다.

결론은 지지자가 표준, 프레임워크, 브라우저 쪽에서 두 배로 노력해야 한다는 것입니다. 서버 사이드 렌더링, 스타일시트 공유, 접근성이 여전히 미해결이고 이는 AI 코딩과 무관하게 사용자 경험에 직접 닿는 결함이라는 지적이 실무에 더 가깝습니다. 가장 서늘한 논거는 어떤 프레임워크든 결국 AGENTS.md의 각주 정도로 밀려날 수 있다는 것입니다.

짧게 알아두기

• Node.js 26.12.1 (Current) Node.js Blog 보안 릴리스입니다. tls IP 검증, dns 입력 검증 등 High 4건이 포함됐으니 24.22.1 (LTS)와 함께 올려야 합니다.
• Node.js 24.22.1 (LTS) Node.js Blog 같은 보안 수정이 들어간 LTS 릴리스입니다. 운영 중인 SSR 컨테이너의 베이스 이미지를 확인해야 합니다.
• Announcing TypeScript 7.1 Beta TypeScript 앰비언트 모듈에서 import attributes(with { type: "json" } 등)를 지원합니다. typescript@beta로 시험해 볼 수 있습니다.
• pnpm 12.15.0 pnpm pnpm-workspace.yaml의 설정 분리(include), 압축하지 않은 tar 해시를 고정하는 lockfile.integrityTarget: tar, 패키지명이 다른 레지스트리 메타데이터 거부가 추가됐습니다.

수집 상태

수집 7596건, 본문 확보 30건, 실은 글 2편. 실패한 소스: 없음

프로덕션급 LLM과 에이전트 현장 가이드

Stack Overflow 원문

에이전트를 프로덕션에 올리는 열쇠는 더 큰 모델이 아니라 모델을 더 좁은 상자에 가두는 것이고, 그 순서까지 정해져 있습니다.

• 데모가 잘 되는 에이전트와 고객이나 돈 앞에 세울 에이전트 사이에는 협곡이 있고, 건너는 열쇠는 더 큰 모델이 아니라 모델 주변의 지루한 장치입니다. 결정성, 평가, 보정된 신뢰도, 겹겹의 가드레일, 감사 기록, 관측성을 꼽습니다.
• 핵심 주장은 LLM이 확률적이므로 모델을 결정적으로 만들 수는 없지만, 모델의 일을 판단이 필요한 가장 작은 결정으로 줄이고 그 결정을 테스트하고 막고 감사하고 관측할 수 있는 결정적 장치로 감싸면 보장을 얻는다는 것입니다.
• 성숙도 모델은 6단계입니다. 0은 노트북, 1은 결정성(에이전트는 제안만 하고 적용은 별도 컴포넌트가 하며, 기능마다 고정된 그래프와 루프 상한을 둡니다), 2는 평가(CI 게이트, 기준선 대비 드리프트), 3은 신뢰도(자동 처리와 사람 검토의 임계값), 4는 안전과 거버넌스(경계에서 PII 처리, 추가만 가능한 감사 원장), 5는 운영성(비용 통제, 모델 라우팅과 폴백, 배포 없이 켜는 킬 스위치), 6은 빌드 자체의 규율(결정 로그)입니다.
• 사용법은 가장 약한 단계를 찾아 순서대로 고치는 것입니다. 대부분의 팀은 0단계에 강하고 5단계를 바라지만, 결정성은 평가보다, 평가는 신뢰도보다, 안전은 확장보다 먼저라고 말합니다. 열 개 체크리스트 중 절반 미만이면 데모가 암시하는 것보다 이르다고 진단합니다.

AI 코딩 도구의 검증 체계를 고민한다면 "제안과 적용을 분리하라"는 1단계가 바로 맞닿습니다. 에이전트가 쓴 코드를 사람이나 결정적 게이트가 적용하는 구조와 같은 원리입니다. 다만 25편짜리 시리즈의 지도 글이라 각 단계의 근거와 수치는 하위 글에 있고 이 글에는 없습니다.

읽을 만한 것

그래도 프로그래밍을 즐겨도 된다

chriskiehl.com (Hacker News 경유) 원문

벽돌깨기를 손으로 짜는 저자는 Claude가 한 번에 만들 수 있다는 사실이 요점이 아니라고 말하고, 즐거움에는 경제적 정당화가 필요 없다고 씁니다.

• 회사에서는 손으로만 짜는 코드의 경제성이 바뀐 게 맞지만, 그것은 일이지 삶이 아니라고 구분합니다. 인터넷에서 가장 목소리 큰 쪽이 가장 우울하고 전염성이 강하다는 진단입니다.
• 저자는 주말마다 직접 코드를 짭니다. 지금은 충돌 판정이 엉성한 벽돌깨기를 만들며 게임 프로그래밍을 배웁니다. Claude가 한 번에 만들어줄 수 있다는 사실은 요점이 아니라고 말합니다.
• 곁가지 공부의 예로 Agda 같은 종속 타입 언어의 아이디어를 Java 타입 안전성에 밀어붙여 본 것, 재귀 도식(recursion scheme)을 몇 시간씩 붙들고도 가치를 아직 모르는 것을 듭니다. 좋은 아이디어는 몇 해 머릿속에서 익은 뒤에야 보이고, 당장 쓸모가 없어도 어려운 것을 이해하는 일 자체가 보상이라고 봅니다.
• "더 이상 즐기면 안 되는 분위기"라는 사회적 압력을 느껴 글을 썼고, 즐거움에는 경제적 정당화가 필요 없다는 것이 결론입니다. 각주에서 vibe coding도 즐겁다고 인정합니다. 코드를 한 줄도 안 본 앱이 여럿이고 보면 경악할 것 같지만, 그 방식은 그 방식대로 독특하게 재미있다고 씁니다.

아래 "프로그래밍의 부고"와 짝으로 읽으면 같은 변화를 두 사람이 어떻게 다르게 받아들이는지 보입니다. 한쪽은 일과 삶을 갈라 즐거움을 지키고, 다른 쪽은 직업으로서의 프로그래밍이 끝났다고 애도합니다.

프로그래밍의 부고

Simon Willison 원문

결과물만 원하던 개발자에게 LLM은 계속 주는 선물이지만, 퍼즐을 푸는 과정이 즐거움이던 개발자에게는 상실이 실제로 큽니다.

• Simon Willison의 링크 블로그 글로, Jeremy Scheff의 "프로그래밍의 부고"를 인용해 코딩 에이전트가 경력 프로그래머에게 남긴 상실을 짚습니다. 본문은 인용이 대부분이라 원문 전체는 Scheff의 글에 있습니다.
• Scheff의 회고에 따르면 프로그래밍은 상상할 수 있는 최고의 직업 중 하나였습니다. 까다로운 작은 논리 퍼즐을 풀면 돈을 받았고, 퍼즐이 까다로울수록 더 받았습니다. 평범한 사람은 그걸 못 했기 때문에 사람들이 개발자를 필요로 했고, 개발자가 전략과 일정과 가능한 범위를 정했습니다.
• 갈림길은 무엇을 좋아했느냐입니다. 동작하는 시스템을 만드는 일이 좋고 풀이 과정의 문제 자체에는 깊은 관심이 없던 사람에게 LLM은 계속 주는 선물입니다. 문제를 직접 푸는 일이 즐거움의 큰 부분이었다면 상실은 실제로 큽니다.

짧은 인용 글이라 2분이면 읽습니다. 위의 Chris Kiehl 글과 함께 읽으면, 같은 도구 앞에서 "일이 아니라 취미로 지키면 된다"와 "직업의 핵심이 사라졌다"가 어떻게 갈리는지 보입니다.

모든 나눗셈을 느리게 만든 0.000000000000000000542퍼센트 버그

futhark-lang.org (Lobsters 경유) 원문

나눗셈에 분기 하나를 붙인 수정이 CPU에서는 차이가 없는데 GPU(CUDA)에서는 5548μs를 12592μs로 늘렸습니다.

• 2의 보수에서는 가장 작은 음수에 대응하는 양수가 없어서 x를 -1로 나눈 값은 x가 최솟값일 때 표현할 수 없습니다. 32비트에서는 입력 2의 64제곱 가지 중 한 가지가 해당해 제목의 비율이 나옵니다. C에서 부호 있는 정수 오버플로는 미정의 동작이고, x86에서는 CPU 예외로 프로그램이 죽기도 합니다.
• Futhark는 C 코드를 생성하는 언어이고 자체 의미론에서는 오버플로가 감싸기(wrap)로 정의됩니다. 그래서 모든 정수를 부호 없는 C 타입으로 표현해 연산하고, 비교와 나눗셈처럼 부호가 중요한 연산만 부호 있는 타입을 씁니다. 나눗셈이 그 구멍이었고 약 10년간 버그로 남아 있었습니다.
• 수정은 y == -1이면 부호 없는 산술로 음수화하는 분기를 모든 나눗셈에 넣는 것입니다. 비용은 모든 나눗셈에 붙는 분기입니다.
• 측정은 갈립니다. 실제 벤치마크 모음과 순차 CPU 백엔드에서는 차이가 없었습니다(3390148μs 대 3389215μs). 나눗셈만 반복하게 만든 인위적 프로그램을 CUDA에서 돌리면 5548μs가 12592μs로 2배 넘게 느려졌습니다. PTX를 보니 기존에는 div.s32 네 개가 한 블록에 이어져 풀렸지만 수정 후에는 나눗셈 사이마다 분기가 끼었고, AMD GPU에서도 비슷하되 영향은 더 작았습니다.
• 결론은 정확성은 양보할 수 없으니 감수하되, 음수가 없다고 아는 코드는 부호 없는 나눗셈을 쓰면 된다는 것입니다. 저자가 기억하는 마지막 미정의 동작이며, 정의가 구현에 맡겨진 비트 시프트 초과 사례가 하나 남아 있습니다.

"거의 일어나지 않는 경우"의 정확성에 얼마를 지불할지, 그리고 그 비용이 플랫폼에 따라 얼마나 다르게 나타나는지를 실측으로 보여 줍니다. 벤치마크 모음에서 안 보이던 비용이 인위적 프로그램에서 2배로 드러나는 대목은 성능 측정을 어떻게 설계해야 하는지에 대한 교훈이기도 합니다.

짧게 알아두기

• Blocking Identity Resolution Infrastructure WebKit Blog iOS, iPadOS, macOS, visionOS 27의 Safari가 이메일을 몰래 수집해 추적 ID로 바꿔주는 identity resolution 서드파티 도메인의 네트워크 접근을 막습니다. 로그인이나 뉴스레터 폼에서 이런 서드파티 스크립트에 기대는 기능이 있다면 Safari 27에서 동작을 확인해야 합니다.

수집 상태

수집 7587건, 본문 확보 22건, 실은 글 4편. 실패한 소스: 없음

이번 주에 실은 글은 스물세 편입니다. 가장 뚜렷한 흐름은 이해를 맡길 수 없다는 주장이 이번에는 실험 결과와 시스템 설계 논리로 뒷받침됐다는 점입니다. DHH가 코드를 읽지 않고 AI에 맡긴 Campfire 재작성을 Piotr Sarnacki가 해부했더니, 프롬프트가 비워 둔 결정이 동전 던지기가 되고 벤치마크도 결론을 속였습니다. n-the-loop는 일관성 같은 전역 속성은 어느 컴포넌트도 보장하지 못하므로 시스템 전체를 아는 사람이 있어야 한다고 같은 결론을 설계 쪽에서 끌어냈습니다. 둘째 흐름은 에이전트가 "끝났다"고 말하는 것을 믿지 않는 장치를 어디에 두느냐입니다. Stack Overflow, Cloudflare, GitHub가 각자 다른 층에 검증을 심는 방법을 내놓았고, 수학 쪽에서는 검증기가 통과시켜도 의도한 것이 검증된 것은 아닐 수 있다는 논문이 나왔습니다. 셋째로 개인의 층위에서는 세부를 아는 즐거움을 잃는 슬픔, 평범한 일을 지키자는 주장, AI가 지적 공동체의 동기를 없앤다는 진단이 한꺼번에 나왔습니다. 넷째로 에이전트의 규모가 Git 저장소와 시크릿 보호 같은 인프라에 압력을 주고, 하네스가 모델보다 먼저 한계에 닿는다는 불만이 함께 보였습니다. 이 모든 글의 바탕에는 일을 맡기는 속도가 이해와 검증의 속도를 앞질렀다는 인식이 깔려 있습니다.

맡긴 일의 이해와 책임은 누가 지는가

읽지 않고 맡긴 Campfire 재작성이 보여준 것, 그래도 생각해야 한다 (Piotr Sarnacki)는 이번 주 가장 구체적인 실험 기록입니다. DHH가 Campfire를 Rails에서 Rust, Elixir, Go로 AI에게 다시 쓰게 했는데, 프롬프트가 정하지 않은 결정(하위 호환, 지연과 처리량의 우선순위, 메모리 사용)을 LLM이 구현하면서 암묵적으로 답해 버려 두 구현은 같은 제품이 아니었습니다. 벤치마크도 문제였습니다. 요청에 응답이 와야 다음 요청을 보내는 폐쇄 루프 방식은 빠른 시스템이 더 많은 부하를 받게 해서 비교 자체를 왜곡하고, 일정한 도착률로 다시 재자 순위와 약점이 달라졌습니다. 이 글은 앞서 다룬 이해는 위임할 수 없다 (Codex 수석 엔지니어)와 Dex Horthy- 컨텍스트 엔지니어링에 있던 "코드를 안 읽고 배포한 실험" 계열의 후속편으로 읽힙니다. 일관성은 국소적 속성이 아니다 (n-the-loop)는 같은 결론을 시스템 설계에서 끌어냅니다. Kafka의 정확히 한 번 처리조차 종단 간 보장이어서 애플리케이션이 깨지 않게 설계돼야 하므로, 컴포넌트 담당자가 각자 "내 부분은 잘 돈다"고 말해도 전역 속성은 보장되지 않고 전체에 책임지는 사람이 필요하다는 논지입니다. Fowler- 에이전트 시대에 코드는 어디에 남는가 (Fragments 10월 4일)는 이 책임을 개념 모델로 풀어 줍니다. 코드는 기계에 주는 명령이면서 도메인의 개념 모델이므로, 생성이 싸질수록 명령 작성보다 어휘를 찾아가는 일이 중요해지고 수동적 리뷰어가 되어서는 안 된다는 것입니다. 다만 Fowler는 사람이 읽는 최상위 표기를 남겨야 한다는 쪽이고, DHH와 Geoffrey Huntley는 사람이 이해하기 쉬운 코드라는 목표를 더는 믿지 않는다는 쪽이어서 여기서 입장이 갈립니다. Sam Ruby가 든 숫자(같은 앱이 Ruby/Rails로는 약 6만 토큰, C로 컴파일하면 400만 토큰)는 후자의 가정이 컨텍스트 창 때문에 성립하기 어렵다는 반론입니다. LLM 역량에 대한 공유된 이해의 격차가 벌어진다 (Andrej Karpathy)는 이 논쟁의 배경이 되는 관찰입니다. 최상위 모델을 업무로 쓰는 약 0.2%와 나머지 사이의 인식 격차가 깔때기처럼 벌어지고, 사람의 검토와 이해가 뒤처지기 시작했다는 것입니다. 네 글을 이으면, 이해를 맡길 수 없다는 주장이 감각(이해가 병목이다)에서 실험(Campfire)과 설계 논리(일관성)로 내려왔고, 남은 쟁점은 사람이 읽는 표기를 어디까지 남기느냐입니다. 앞서 다룬 이해가 새로운 병목이다 (Geoffrey Litt, Notion)과 Naur- 이론 구축으로서의 프로그래밍 (1985)에 이어서 읽을 수 있습니다.

에이전트의 자기 보고를 어디서 검증하는가

초록색 종료 코드는 일이 됐다는 증거가 아니다 (Chase Hughes)는 에이전트 루프의 exit 0이 관찰이 아니라 모델이 "done"을 냈다는 자기 평가일 뿐이라고 짚고, 검증은 에이전트가 쓰지 않은 산출물 상태에서 해야 한다고 처방합니다. 이 처방을 시스템으로 구현한 사례가 단일 에이전트는 증거와 권한을 섞는다 (Cloudflare 보안 운영 하네스)입니다. Cloudflare는 증거 수집과 고객 범위 고정을 모델 앞단의 결정론적 코드로 옮기고, 전문 에이전트가 증거 항목을 인용하면 코드가 그 인용이 실제로 존재하고 주장을 뒷받침하는지 검사합니다. 핵심 교훈인 "프롬프트는 경계가 될 수 없다"는 앞의 Campfire 사례에서 프롬프트가 비워 둔 결정이 동전 던지기가 된 것과 같은 문제를 반대편에서 본 것입니다. 에이전트의 확신을 합성하고 보정하고 심판에게 검증시키기 (Stack Overflow)는 검증을 확신도로 계량합니다. 모델 자기평가의 가중치를 가장 낮게(0.25) 두고 결정론적 검증, 다른 계열 심판의 반박, 과거 정확도를 합성하며, 사람 이관이 승인 버튼뿐이면 앵커링 때문에 가짜 책임만 만든다고 경고합니다. ReviewBench- AI 코드 리뷰 오프라인 벤치마크 (GitHub)는 검증하는 쪽, 곧 AI 리뷰어 자체를 재는 도구입니다. 오프라인 점수가 온라인 A/B 결과의 방향을 예측했다고 하지만 제작자가 자기 제품에 쓴 자체 보고라서 에누리해서 읽어야 합니다. 이 흐름에서 가장 서늘한 글은 Lean 검증이 자연어 증명의 정확성을 보장하지 않는다 (Navier-Stokes 사례)입니다. AI가 자연어 증명을 Lean으로 번역해 기계가 검증해도, 번역이 충실한지는 별개의 문제이고 그것이 정지 문제보다 어렵다는 주장입니다. 개발에 옮기면 "검증기가 통과시켰다"와 "의도한 것이 검증됐다"는 다른 말이라는 뜻이고(이는 이 글의 해석이고 논문의 주장은 아닙니다), 명세나 테스트를 AI가 번역해 만든 경우에도 같은 간극이 생길 수 있습니다. 앞 글들이 검증을 에이전트 바깥에 두자고 한다면 이 논문은 바깥의 검증기도 번역 층에서 속을 수 있다고 덧붙이는 셈입니다. 앞서 다룬 에이전트는 끝났다고 했고 데이터베이스는 아니라고 했다 (Microsoft ThinkingBox)와 TLA+가 검증할 수 있는 것과 없는 것 (Hillel Wayne)이 지난주에 같은 문제를 다뤘고, 이번 주 글들은 그것을 설계 패턴과 한계 증명으로 확장했습니다.

세부, 평범한 일, 공동체를 잃는 개인의 목소리

세부를 잃는 슬픔 (purplesyringa)은 논증이 아니라 일기라고 스스로 밝힌 글입니다. 저수준 세부와 기계를 이해하는 데서 즐거움을 얻던 저자가, LLM이 느린 코드의 핫 루프를 찾고 포인터 출처까지 설명해 주니 세부 전문성을 따로 고용할 이유가 줄었다고 쓰며 아끼는 일에는 LLM을 쓰지 않기로 합니다. 프로그래밍은 특별하지 않다 (Glyph)는 같은 상실감을 논증으로 바꿉니다. 작가와 미술가는 집단으로 AI에 저항하는데 프로그래머만 체념하고, 평범한 일을 AI로 지우면 걸작이 나올 연습 기회가 사라진다는 것입니다. 평범한 프로젝트 하나가 걸작이 될 확률을 0.1%로 놓으면 모든 프로젝트를 AI로 하는 순간 "가끔은 반드시"가 "영영 없음"이 된다는 확률 비유가 핵심입니다. AI는 지적 공동체를 해체한다 (borretti.me)는 한 단계 더 나아가 개인의 지적 활동에 연료가 되는 외부 공동체와 인정이 AI 때문에 사라진다고 봅니다. 블로그 글은 학습에 흡수되고 질문은 출처 없이 답해지니 공유지에 기여할 이유가 줄어든다는 것입니다. 세 글은 모두 "AI가 일을 대신하면 사람의 성장 경로가 막힌다"는 같은 직관을 다른 층위에서 말하고, 앞서 다룬 AI 코딩은 전문성을 막는다 (Lars Faye)와 AI 사용을 그만두기로 한 이유 (Brett)에 이어집니다. 갈리는 지점은 처방입니다. purplesyringa는 쓰지 않는 쪽으로 물러나고, Glyph는 평범한 일을 의도적으로 지키라고 하며, 지속 가능한 웹 커리어 (David Bushell)는 접근성, CSS, 소통처럼 희소해질 기술을 쌓고 React와 GitHub 의존은 버리라고 합니다. 다만 Bushell의 글은 근거나 수치가 없는 의견 에세이여서, 앞의 두 글과는 달리 "남는 기술"에 대한 한 실무자의 판단으로 읽어야 합니다. 이 쪽의 반대편 증거로 2026 Stack Overflow 개발자 설문 결과는 사용자의 73%가 AI 도구를 매일 쓰고도 52%는 여전히 일반 코딩 기술을 배운다고 답한 숫자를 줍니다. 그리고 소프트웨어 블로깅 안티패턴 (Refactoring English)은 글쓰기를 AI에 맡겨 블로그가 밋밋하고 비슷해지는 지금은 개성이 차별점이라고 해서, borretti의 공동체 진단과 닿는 실용적인 이면을 보여줍니다.

에이전트의 규모와 속도가 인프라와 하네스에 거는 압력

에이전트 규모의 개발을 위한 Git 인프라 재설계 (GitHub)는 에이전트가 행동 하나마다 커밋하므로 월간 push가 1년 새 6.9억에서 33.5억 건으로 4.9배 늘었고, 병목은 읽기가 아니라 쓰기라고 합니다. 복제본이 곧 읽기 확장 수단이자 모든 쓰기의 참여자인 현재 구조(Spokes)를, 합의가 필요한 ref 갱신만 조율하고 저장과 컴퓨트를 분리하는 구조로 바꾼다는 선언이지만 실제 설계 세부는 후속 글로 미뤄져 있습니다. 에이전트가 코드를 쓰는 속도를 보호가 따라가야 한다 (GitHub 시크릿 보호)는 같은 압력을 보안에서 봅니다. AI 에이전트가 관여한 PR이 1년 사이 10건 중 1건 미만에서 3건 중 1건이 됐는데, 푸시당 유출 비율에는 유의한 추세가 없었으니 개발자가 부주의해진 것이 아니라 양이 늘어난 것이고, 예방은 컴퓨트로 확장되지만 유출 한 건을 수동으로 폐기하는 데 평균 약 40일이 걸리는 사후 대응은 사람 수로만 확장된다는 논지입니다. 두 글 모두 자사 제품 홍보를 겸한 자체 보고이니 숫자는 방향을 보는 용도로 쓰는 편이 안전합니다. 코딩 에이전트는 왜 이렇게 멍청한가 (Michael Lynch)는 이 규모의 바닥에서 사용자가 겪는 불만을 모읍니다. 모델은 좋아졌는데 병목은 모델과 코드베이스를 잇는 하네스이고, 작업 위임, 계획 전달, 샌드박스가 기본 수준에도 못 미친다는 것입니다. 반대로 DeepSeek 4.1 Flash를 한 달 쓴 후기- 충분히 좋은 모델이 일하는 방식을 바꾼다 (dgt.is)는 값싼 모델이 충분히 좋으면 무인 작업과 탐색에 부담 없이 에이전트를 돌릴 수 있고, 중요한 곳에만 상위 모델을 "새로운 눈"으로 부른다는 주관적 사용기입니다. 이 사용기는 벤치마크가 아닌 체감에 기댄 글이어서 근거가 약하지만, 비용이 내려가면 위의 쓰기 부하와 검증 부담이 더 커진다는 방향으로는 앞의 글들과 이어집니다. 기술 쪽의 작은 소식들은 이 주제와 거리가 있지만 같은 결로 읽을 수 있습니다. Workers 운영 환경 온디맨드 프로파일링 (Cloudflare)는 로컬이 아니라 운영 환경에서 프로파일해야 앱이 이해된다는 사례이고, Deno를 떠나 Node로 돌아온 이유 (David Bushell)은 pnpm의 릴리스 지연 설정으로 공급망을 방어하는 개인 구성입니다. 앞서 다룬 Ferd- 인간은 루프의 어디에 있어야 하나와 느려져야 빨라진다 (Gergely Orosz, Craft 2026 키노트)가 던진 "속도를 사람이 감당할 수 있는 양으로 맞춰라"라는 질문이 인프라 층에서도 확인된 한 주였습니다.

이번 주의 두 편

• 읽지 않고 맡긴 Campfire 재작성이 보여준 것, 그래도 생각해야 한다 (Piotr Sarnacki): 코드를 읽지 않고 맡긴 재작성을 실제 코드와 부하 측정으로 해부해 "이해는 위임할 수 없다"를 실험으로 뒷받침한 글입니다.
• 일관성은 국소적 속성이 아니다 (n-the-loop): 전역 속성은 컴포넌트가 아니라 전체를 이해하는 사람에게 뿌리를 둔다는 논지가 이론 구축과 책임 논의를 설계 쪽에서 잇는 짧고 단단한 글입니다.