오늘 고른 셋은 분야가 제각각입니다 — 커널 C 코드, AI 에이전트, 장애 회고. 그런데 ‘그럼의 편집 기준’으로 보면 한 가지로 꿰입니다: 경계를 누가 책임지나. 문자열의 끝, 에이전트가 만지는 상태, 장애를 적는 손. 각 항목은 ‘한 줄 판단’부터 던지고 근거를 풉니다.

오늘의 핵심

1. Linux 7.2, 커널에서 strncpy를 완전히 들어냈다

• 한 줄 판단: 커널 얘기지만, 오늘 당신 코드베이스에서 strncpy를 한 번 grep 해보세요 — 문제는 함수가 아니라 문자열의 끝을 누가 보장하나입니다.
• 사실: Kees Cook 주도로 6년·약 362커밋에 걸쳐 커널 코드에서 strncpy() 사용처를 모두 걷어내고, Linux 7.2에 제거가 머지됐습니다(2026-06-20). 이유는 셋 — NUL 종료가 직관과 반대로 동작하고, 남는 공간을 0으로 채우는 불필요한 비용이 있으며, 무엇보다 종료되지 않은 문자열이 버퍼 경계 너머 바이트를 흘리는 메모리 노출 버그 클래스를 만든다는 점입니다. 대체는 strscpy()(NUL 종료)·strscpy_pad()·strtomem_pad()·memcpy_and_pad() 등으로 용도를 쪼갰습니다. (⚠️ 이건 커널 한정입니다 — userspace glibc의 strncpy가 사라진 게 아닙니다. 7.2 정식은 8월 말 예정.)
• 태리의 해설: strncpy는 늘 “n을 어떻게 줬냐”로 사람을 물어온 함수입니다 — 한 글자만 어긋나도 종료 NUL이 빠지고, 그 뒤로는 옆 버퍼의 바이트가 그대로 따라 나오죠. 그럼의 편집 기준은 돈·물리가 걸린 시스템에서 그 한 바이트를 남의 정보가 새는 사고로 봅니다(공개된 메모리 노출 취약점들이 반복해 보여준 버그 클래스). 커널이 수십 년 묵은 함수를 굳이 6년 들여 들어낸 건, API가 사람에게 실수를 강요하면 결국 그 API를 없애는 게 정답이기 때문입니다.
• 이번 주 할 일: C/임베디드 코드가 있다면 strncpy 사용처를 훑고, 고정폭 필드인지·NUL 종료가 필요한지부터 구분하세요. 저수준 메모리 안전이 왜 지금도 현장 일인지는 다른 데일리에서 이어집니다.

2. LedgerAgent — 에이전트 상태를 프롬프트에서 빼내 ‘검증부터’ 거는 설계

• 한 줄 판단: 에이전트에게 “기억”을 프롬프트에 욱여넣지 말고, 상태를 따로 빼서 도구 호출 전에 정책을 선검증하세요.
• 사실: 추론 시점에 태스크 상태를 프롬프트가 아니라 별도 ‘레저(ledger)‘에 명시적으로 관리하는 방법을 제안한 논문(arXiv, Work in Progress). 표준 에이전트가 매번 프롬프트에서 상태를 재구성하다 겪는 두 실패 모드 — (1) 낡거나 누락·오염된 정보에 근거한 판단, (2) 문법은 맞지만 도메인 정책을 위반하는 tool call — 을, 환경을 바꾸는 호출 직전에 정책을 선검증해 줄입니다. 고객 서비스 4개 도메인·공개/비공개 모델에서 prompt 기반 대비 pass^k가 개선됐고, 특히 다중 시도 일관성 지표에서 격차가 컸다고 합니다. (⚠️ 구체 수치는 초록에 없음.)
• 태리의 해설: 그럼의 편집 기준은 ‘느슨한 결합 = 안정성’을 중시합니다 — 공개된 분산 시스템(메시지 큐·이벤트 기반) 사례가 반복해 보여준 진짜 어려움은 처리량이 아니라 중복과 순서였죠. 이 논문의 “정책 선검증”이 눈에 들어온 이유가 그겁니다 — 문법이 맞는 tool call도, 외부에 쓰는 순간 멱등키와 정책은 여전히 당신 몫입니다. 그럼의 기준은 AI도 역할·입출력·검증·복구 경계부터 긋는 것 — 상태를 레저로 외부화하는 건 그 경계를 코드로 만든 셈입니다.
• 이번 주 할 일: tool-calling 에이전트를 운영 중이라면, 환경을 바꾸는 호출 앞에 정책 게이트 하나(예: 멱등키·권한·금액 한도 확인)를 끼워보세요. 에이전트 권한 경계 얘기는 어제 데일리의 임시 계정 항목과도 이어집니다.

3. LLM이 쓰는 인시던트 리포트가 두렵다는 경고

• 한 줄 판단: 데이터 수집은 LLM에 맡기되, 포스트모템 ‘본문’은 사람이 쓰세요. (의견)
• 사실: Lorin Hochstein(Surfing Complexity)의 글(2026-06-19, 의견). LLM이 인시던트 리포트를 직접 쓰게 하는 건 코딩 보조와 근본적으로 다르다는 주장입니다. 글쓰기는 “흐릿한 생각을 드러내는” 과정인데 그걸 건너뛰고, 코드나 운영은 틀리면 바로 실패로 드러나지만 잘못된 리포트는 그럴듯한 채로 없는 인과를 지어낼 수 있어 검출이 안 됩니다. 결과는 형식만 갖춘 ‘시뮬라크르’ — 사람을 인터뷰해야 나오는 통찰이 빠지고, 조직은 학습 기회를 잃습니다.
• 태리의 해설: 그럼의 편집 기준도 같은 결론입니다. 포스트모템의 가치는 문서가 아니라, 쓰는 사람이 타임라인을 되짚으며 “어, 여기 이게 왜 이렇게 묶여 있었지”를 깨닫는 그 순간에 있죠. 그럼의 기준은 AI를 관찰·검증 경계 안에서만 제품에 넣는다는 것 — 회고도 같습니다. 사실 수집은 AI가, 인과와 교훈은 사람이. 경계를 거꾸로 두면 가장 비싼 학습을 가장 싸게 날립니다.
• 이번 주 할 일: 회고 템플릿에 경계를 명문화하세요 — “타임라인·로그 수집 = AI 허용, 원인·교훈·재발방지 = 사람 작성”. AI가 쓴 초안을 그대로 승인하지 않기.

그래서, 무엇이 바뀌나

셋을 관통하는 한 가지 — 진짜 일은 늘 ‘경계를 긋고 책임을 두는 것’으로 옮겨갑니다. 문자열의 끝(메모리 경계), 에이전트의 상태와 정책(신뢰 경계), 장애의 해석(사고의 경계). 도구가 strncpy든 LLM이든, 사람에게 실수를 강요하는 경계는 결국 다시 그어집니다 — 공개된 기술사에서 도구는 수십 번 바뀌었어도 이 일만은 사라진 적이 없습니다.

참고 / 출처

• Kees Cook: “We can remove strncpy() from the Linux kernel…” — 메인테이너 공지(1차 출처)
• Linux Eliminates the Strncpy API After Six Years of Work, 360 Patches — Phoronix(발견·맥락)
• LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents — arXiv(2026-06)
• I am dreading our LLM-written incident report future — Surfing Complexity(의견, 2026-06-19)