오늘은 셋입니다 — 브라우저 벤더가 직접 낸 에이전트용 MCP 서버, 의존성에서 AI 코드를 걷어낸 어느 메인테이너의 100시간, 그리고 Postgres를 통째로 무너뜨리는 OOM 킬러를 다루는 커널 설정. 성격은 달라 보여도 묶이는 한 가지가 있어요: 무엇이 무엇을 건드리게 둘지, 그 경계를 어디에 그을 것인가. 각 항목은 ‘한 줄 판단’부터 던집니다.

오늘의 핵심

1. Safari MCP 서버 — 브라우저 벤더가 직접 낸 에이전트 디버깅 도구

• 한 줄 판단: 주목할 건 ‘MCP 서버가 또 나왔다’가 아니라 경계를 어떻게 그었나입니다. WebKit은 15개 도구를 열되 로컬 전용·외부 호출 없음·AutoFill 등 사용자 데이터 미접근으로 못을 박았어요. 에이전트에 권한을 줄 때 무엇을 막을지부터 정한 설계입니다.
• 사실: WebKit이 Safari Technology Preview 247(2026년 7월)에 Safari MCP 서버를 도입했습니다. safaridriver --mcp로 붙이고, 탭 제어·DOM(JS 평가)·네트워크 요청·콘솔·접근성 검사·스크린샷·뷰포트 에뮬레이션 등 15개 도구를 Claude 같은 MCP 클라이언트에 노출합니다. STP 247+에서 ‘개발자용 기능’과 ‘원격 자동화·외부 에이전트 허용’을 켜야 동작.
• 이번 주 할 일: Safari 호환성·접근성 디버깅을 반복한다면 STP에서 한 번 붙여 결과를 보시길 권합니다. 단, 아직 STP 전용이라 안정 채널·CI엔 이르니, 이번 주는 실험 범위로 재보는 편이 균형이 맞습니다.

2. “의존성에 AI 코드는 안 된다” — git-annex 메인테이너의 100시간

• 한 줄 판단: AI가 쓴 코드가 의존성 트리로 스며들면서 *‘누가·어떻게 썼나’*가 새 감사 항목이 됐습니다. 코드가 돌아간다는 것과 신뢰 경계 안에 들여도 된다는 건 다른 문제예요.
• 사실: git-annex 메인테이너 Joey Hess가 약 100시간을 들여, git-annex가 기계 생성 코드가 든 의존성 없이 빌드되도록 정리하고 그 과정을 공개했습니다. 근거로 릴리스 사이 대량 AI 코드가 설명 없이 되돌려진 사례, 26,000줄 코드베이스에 1만 줄을 바꾸며 붙은 1,489줄짜리 “지리멸렬한” 커밋 메시지, 프로젝트 간 코드 복사를 시킨 LLM 프롬프트로 저작권 문제를 아슬하게 피한 사례를 듭니다. (개인 블로그의 의견 겸 실천 기록 ⚠️.)
• 이번 주 할 일: 핵심 의존성 몇 개의 최근 대형 커밋 이력(provenance)을 한 번 훑어보시길 권합니다. 단, 트리 전체 감사는 이렇게 100시간급이 되니, 보안·규정이 걸린 의존성부터 좁게 시작하는 게 현실적입니다.

3. Postgres와 OOM 킬러 — strict 오버커밋으로 ‘늦은 참사’를 ‘이른 에러’로

• 한 줄 판단: 백엔드 하나가 OOM 킬되면 서버의 모든 커넥션이 끊깁니다. vm.overcommit_memory=2는 이 늦고 파괴적인 실패를, 이르고 우아한 실패로 바꿔 놓아요.
• 사실: Ubicloud의 기술 글입니다. Postgres 백엔드가 OOM 킬되면 postmaster는 공유 메모리 손상을 가정해 남은 백엔드 전체를 종료 — 모든 커넥션이 끊기고 진행 중 트랜잭션이 중단되며, 최악엔 크래시 복구까지 겹칩니다. strict 오버커밋 모드는 커밋 총량이 CommitLimit을 넘는 할당에 즉시 ENOMEM을 돌려줘, 해당 백엔드만 에러·트랜잭션 취소로 끝내고 postmaster와 다른 커넥션은 살립니다. 권장 한계는 물리 메모리의 80% + 2GB(80%는 커널 자료구조 몫, +2GB는 사이드카 프로세스의 가상 영역 몫).
• 이번 주 할 일: Postgres를 직접 운영한다면 vm.overcommit_memory와 CommitLimit 값을 점검해 보시길 권합니다. 단, 한계를 너무 조이면 앱이 잦은 ENOMEM을 만나니, 실측 사용량을 본 뒤 여유를 얹는 편이 안전합니다.

그래서, 무엇이 바뀌나

셋을 관통하는 흐름은 경계 설계입니다. 에이전트가 브라우저에서 무엇을 만질 수 있는지(1), AI가 쓴 코드가 어디까지 내 신뢰 경계에 들어오는지(2), 메모리 압박이 어디서 격리되는지(3) — 대상은 브라우저·공급망·커널로 제각각이지만 승부처는 하나예요: 무엇이 무엇을 건드리게 둘지를 미리 긋는 것. 그럼의 편집 기준(느슨한 결합 = 안정성, AI도 역할·입출력·검증·복구 경계가 있어야 제품)으로 보면, 공개된 기술사에서 시스템이 강해지는 지점은 늘 ‘더 많은 연결’이 아니라 ‘잘 그은 경계’였습니다. 새 도구가 마찰을 줄여 줄수록, 남는 사람 몫은 이 선을 어디에 그을지의 판단으로 옮겨갑니다. (어제의 ‘Postgres 워크플로 상태·MCP 클라우드’도, 데일리 트렌드를 고르는 기준도 같은 렌즈입니다.)

참고 / 출처

• Introducing the Safari MCP Server for web developers — WebKit 공식 블로그
• No LLM code in dependencies — Joey Hess 블로그 (개인 의견·실천)
• PostgreSQL and the OOM Killer: Why We Use Strict Memory Overcommit — Ubicloud 엔지니어링 블로그
• 함께 보기: 어제의 데일리 트렌드