제가 글로 쓰지 않는 것들

작가가 무엇을 믿는지 가장 빠르게 읽어내는 방법은 그가 쓸 수 있었지만 쓰지 않기로 선택한 것들의 목록입니다. 발행 분량은 무엇이 출판되었는지 알려줍니다. 거부 목록은 입장을 알려줍니다. 정의된 거부 목록을 가진 블로그는 한 사람처럼 읽히고, 그렇지 않은 블로그는 피드처럼 읽힙니다.

Apple Ecosystem 클러스터에는 목소리가 있습니다. 그 목소리는 주로 발행된 글로 구성되지 않습니다. 발행되지 않은 글, 그리고 명목상 주제에 부합하지만 어쨌든 잘려나간 반복적인 글쓰기 형태로 구성됩니다. 클러스터에서 읽은 글들은 그 잘림의 결과물입니다. 이 글의 나머지 부분은 그 잘림을 명명합니다.

구분해 둘 가치가 있는 두 종류의 거부가 있습니다. 범주적 거부(Categorical refusals)는 클러스터의 영역 밖에 있는 주제들입니다. 패턴 거부(Pattern refusals)는 주제와 무관하게 초안을 실격시키는 목소리와 구조 선택입니다. 첫 번째는 취향이고, 두 번째는 장인정신입니다. 둘 다 여러분이 읽는 것을 형성합니다.

TL;DR

• 범주적 거부: Apple 스택과 에이전트의 교차 영역에 속하지 않는 모든 것. 일반적인 웹 개발, 클라우드 LLM 튜토리얼, 채용 기술, 클러스터의 정체성을 희석할 만한 모든 것.
• 패턴 거부: 재활용된 셋업 프레이밍(“120개 hook으로 배운 것”), 증거로 사용되는 비공개 텔레메트리, 편집 비계(기획 라벨, PRD 번호), 아키텍처 없는 튜토리얼, 근거 없는 핫테이크.
• 흥미로운 거부: 클러스터의 명목적 영역 안에 있지만 입장을 누적하지 않기 때문에 잘려나가는 주제(visionOS 생산성 앱, 서버 사이드 Swift, AppKit 전용 Mac UI).
• 거부는 부재가 아닙니다. 거부는 남는 것의 형태입니다.

범주적 거부

이 클러스터는 AI 에이전트와 교차하는 Apple 개발을 다룹니다. 그 교차점 밖의 모든 것은 범위 밖이며, 흥미가 없어서가 아니라 누적되지 않기 때문입니다.

일반적인 웹 개발. Blakecrosley.com 자체는 FastAPI와 HTMX 위에서 동작합니다. 그 스택에 대해 쓸 수 있는 글은 수십 개입니다. HTMX 스왑 패턴, FastAPI 의존성 주입, async SQLAlchemy의 함정 같은 것들이죠. 그중 어느 것도 이 클러스터에 속하지 않습니다. 클러스터의 독자는 에이전트를 고민하는 iOS 개발자이며, 웹 개발 글은 자체적인 독자를 끌어들이더라도 신호를 희석시킵니다. 그런 글들이 있을 자리는 따로 있고, 이 클러스터는 그 자리가 아닙니다.

클라우드 LLM API 튜토리얼. Anthropic의 API. OpenAI의 API. Python SDK들. Claude Sonnet과 Opus의 지연시간 차이. 백엔드 서비스에서 클라우드 LLM를 호출하는 법을 배우는 사람을 위한 튜토리얼 형태의 콘텐츠. 클러스터의 입장은 에이전트가 결합된 Apple이 희소한 것이라는 점이며, 클라우드 LLM 튜토리얼은 인터넷의 나머지 부분이 충분히 다루는 범용 상품입니다. 그런 글을 쓰는 것은 문서를 소리 내어 읽는 작업이 될 뿐 클러스터의 권위에 아무것도 더하지 않습니다.

ResumeGeni와 941 채용 기술. 별개의 회사, 별개의 브랜드, 별개의 사이트입니다. 둘 사이의 교차 수분은 양쪽 모두를 약화시킵니다. 채용 스택에는 글로 쓸 만한 자체적인 기술적 결정이 있습니다(ATS 파서, 임베딩 파이프라인, 후보자 매칭 알고리즘). 그것들은 다른 정체성 아래의 다른 블로그에 속하지, 여기에 속하지 않습니다.

클러스터의 정체성을 희석할 모든 것. Postgres 커넥션 풀링에 대한 정말 좋은 글, JavaScript 프레임워크의 변화에 대한 Hacker News 분노글, Rust async 런타임에 대한 사려 깊은 글. 모두 옹호 가능한 글쓰기지만, 모두 클러스터의 영역 밖입니다. 포함의 기준은 “이 글이 좋은가”가 아닙니다. 기준은 “이 글이 이미 여기 있는 것을 누적시키는가”입니다.

범주적 거부는 클러스터의 정체성에 의해 결정됩니다. 정체성이 명명되면 거부는 따라옵니다.

패턴 거부

패턴 거부는 주제를 넘나듭니다. 초안이 클러스터의 주제에 부합하더라도 쓰여진 방식 때문에 거부될 수 있습니다.

재활용된 셋업 프레이밍. “6개월 동안 120개 hook과 49개 명령어로 배운 것.” “500번의 세션 후 남은 세 가지.” “내 95-hook 구성.” 재활용된 셋업 패턴은 작가의 작업 환경을 전문성의 증거로 재활용합니다. 클러스터의 앱은 작은 집합이며, 작가가 그것들에 의존하면 동일한 hook 수, skill 수, 명령어 수, 세션 수가 글마다 등장하게 됩니다. 논증이 아니라 헛기침처럼 읽힙니다. 클러스터가 정착한 규칙은 이렇습니다. 분량은 프레임워크 해설자와 프론티어 에세이 쪽으로 기울이고, 출시된 코드 글은 작가의 도구 분류가 아니라 실제 공개 프로젝트를 가리킵니다.

증거로 사용되는 비공개 텔레메트리. “hook이 34일 동안 52번 작동했다.” “환영 검증(phantom verification)이 세션의 12%에서 2% 미만으로 떨어졌다.” 비공개 숫자는 외부에서 검증할 수 없습니다. 자랑처럼 읽히고, 어떤 공개 산출물과도 대조할 수 없습니다. 올바른 형태의 증거는 공개 출처(Apple Developer 문서, Anthropic 사양, 출시된 오픈소스 코드, 논문)에 추론을 더한 것입니다. 비공개 지표는 커밋 메시지와 사후 분석에서 작동하지, 출판된 산문에서 작동하지 않습니다.

편집 비계. 작가의 내부 분류에 따라 글을 분류하는 굵은 라벨. 본문 안의 PRD 번호. “cave plan ladder에 따라.” 독자는 이 글이 작가의 기획 문서에서 어느 버킷에 속하는지 알 필요가 없습니다. 장르는 첫 문장에서 명백합니다. 계획은 워크플로우 도구이지 독자에게 보여줄 카피가 아닙니다. 산출물은 산출물이고, 워크플로우는 워크플로우에 머무릅니다.

아키텍처 없는 튜토리얼. “XcodeBuildMCP를 설치하는 방법은 다음과 같습니다”라고 말하면서 에이전트가 구조화된 도구 접근권을 가질 때 아키텍처적으로 무엇이 바뀌는지 명명하지 않는 글은 튜토리얼입니다. 튜토리얼은 가치가 있지만 클러스터의 기여는 아닙니다. 클러스터의 기여는 클러스터의 나머지와 누적되는 아키텍처 패턴입니다. 그 수준에 도달하지 못하는 튜토리얼은 도달할 때까지 다시 쓰이거나 잘려나갑니다.

근거 없는 핫테이크. “Codex가 Claude Code보다 낫다.” “MCP는 과대평가되었다.” “App Intents는 막다른 길이다.” 핫테이크 장르는 트래픽을 끌어들이지만 면밀한 검토에서 살아남지 못합니다. 참인 테이크는 작가가 직접 본, 방어할 수 있는 구체적인 동작에 근거합니다. 거짓인 테이크는 그것을 읽는 두 번째로 뛰어난 동시대 개발자 앞에서 무너집니다. 클러스터의 강한 의견 글들(Trust, Tool RL, App Intents vs MCP)은 입장이지 테이크가 아닙니다. 입장은 영수증을 갖춥니다.

뻔한 것을 읊어야 하는 모든 것. “먼저 Xcode를 설치하세요.” “npm install을 실행하세요.” “Apple의 문서는 developer.apple.com에 있습니다.” 채움재입니다. Xcode를 설치하는 방법을 알려줘야 하는 독자는 이 클러스터의 독자가 아닙니다. 클러스터는 독자가 이미 이 글을 읽을 만한 종류의 사람이라고 가정합니다. 그런 독자를 그들이 있는 곳에서 만나는 것은 다른 사이트의 다른 글입니다.

흥미로운 거부

범주적 거부는 쉽습니다. 패턴 거부는 규칙을 따릅니다. 흥미로운 거부는 클러스터의 명목적 영역 안에 있지만 입장을 누적하지 않기 때문에 여전히 잘려나가는 주제들입니다.

생산성 앱을 위한 visionOS. “두 번째 화면으로 visionOS를 사용하기” 또는 “Vision Pro에서 저널링 앱 출시하기”에 대한 긴 글. Apple 스택, 주제 부합. 잘리는 이유는 클러스터의 visionOS 입장이 RealityKit + 공간적 사고 모델이 아키텍처적 지렛대라는 것이고, “visionOS를 평면 생산성 표면으로 사용하기”는 다른 프레임워크의 영역이며 클러스터를 확장하지 않기 때문입니다. 오너먼트, 몰입형 공간, 손 추적에 대한 글은 누적되겠지만, “iPad 앱을 visionOS에서 실행하게 만들기”에 대한 글은 그렇지 않습니다.

서버 사이드 Swift. Vapor, Hummingbird, Linux 컨테이너의 서버 사이드 Swift. 실재하고, 성장하고 있고, 기술적으로 흥미롭습니다. 클러스터 밖입니다. 클러스터의 서버 입장은 “iCloud Drive 더하기 JSON 파일 더하기 MCP 서버”이며, 의도적으로 작은 서버 사이드 약속입니다. 더 큰 약속(Swift 백엔드 서비스)은 에이전트가 결합된 Apple 프론티어와 교차하지 않는 다른 아키텍처 대화이기 때문입니다. Swift 백엔드가 iOS+에이전트 아키텍처에 하중을 견디는 부분이 되는 날, 그 글은 자리를 얻습니다. 오늘은 그렇지 않습니다.

AppKit 전용 Mac UI. Mac 앱은 여전히 깊이 있는 AppKit 작업으로 출시됩니다. 클러스터의 멀티 플랫폼 출시 글은 Mac에서의 SwiftUI를 다루지만, AppKit 특화 주제(NSToolbar 커스터마이징, NSResponder 체인의 특이점, AppKit-to-SwiftUI 브리징 함정)는 클러스터의 목소리 바로 바깥에 있습니다. 그것들은 다른 클러스터의 입장(Mac 개발 자체)을 누적시키는 데 더 적합하지, 이 클러스터를 누적시키는 데 적합하지 않습니다.

이미 존재하는 것을 넘어선 비교 글. App Intents vs MCP가 자리를 얻은 이유는 그 비교가 아키텍처 규칙을 드러내기 때문입니다. iOS 개발을 위한 Cursor vs Zed vs JetBrains 비교는 트래픽을 끌어들이겠지만 “다른 IDE는 다르게 작동한다” 이상을 드러내지 못할 것입니다. 비교 글을 추가하는 기준은 이렇습니다. 비교 자체가 프론티어 에세이급의 통찰을 만들어내는가, 아니면 단지 벤치마크일 뿐인가?

제가 권위를 꾸며내야 하는 모든 것. Core ML 팀원에게 깊은 인상을 줄 수준의 Core ML 양자화에 대한 글. 그래픽 엔지니어에게 깊은 인상을 줄 수준의 visionOS Metal 셰이더에 대한 글. 클러스터의 권위는 에이전트가 결합된 Apple 아키텍처의 교차점에 있습니다. 그 교차점 밖으로 손을 뻗으면 틀리지 않을 만큼 정확하지만 누적되기에는 너무 얕은 글이 나옵니다. 정직한 행보는 더 깊은 목소리(Core ML 연구자의 블로그, 그래픽 엔지니어의 글)를 인용하는 것이지, 그 사람을 흉내 내는 것이 아닙니다.

제품으로서의 거부

거부 목록은 한계의 고백이 아닙니다. 거부 목록은 포지셔닝 행위입니다. 1984년 Apple의 Mac 광고 캠페인이 IBM을 위한 캠페인이 아니었다는 점은 유명합니다. 1998년 Steve Jobs의 2x2 그리드 시점의 Apple 제품 라인(소비자/프로 × 데스크톱/포터블, Mac 라인 전체에 대한 네 개의 박스)은 살아남은 것이 아니라 잘려나간 것으로 유명했습니다. 어떤 범주를 거부하는 선택은 그 안에서 출시하는 선택보다 더 강한 제품 신호입니다.

글쓰기에서도 거부는 같은 일을 합니다. 클러스터의 목소리(직설적이고, 의견이 분명하며, 증거 기반이고, 잔인할 정도로 솔직한 footer를 가진)가 존재하는 이유는 재활용된 셋업 프레이밍이 잘렸고, 비공개 텔레메트리가 잘렸고, 편집 비계가 잘렸고, 클라우드 LLM 튜토리얼이 잘렸기 때문입니다. 각각의 잘림은 양의 공간을 정의하는 음의 공간입니다.

이 패턴은 The Repo Shouldn’t Get to Vote on Its Own Trust와 메아리칩니다. 신뢰 다이얼로그의 가치는 사용자가 승인하기 전에 해석하기를 거부하는 것에서 나옵니다. 워크스페이스 바이트를 읽는 신뢰 게이트는 게이트가 아닙니다. 주제에 부합하는 모든 글에 yes라고 말하는 블로그 클러스터는 클러스터가 아닙니다. 경계에서의 거부야말로 산출물에 의미를 부여하는 것입니다.

따름정리는 이렇습니다. 거부 목록이 없는 작가도 괜찮지만, 그들은 입장이 아니라 피드를 생산하고 있습니다. 둘 다 실재하는 산출물입니다. 시간이 지나면서 권위를 누적하는 것은 그중 하나뿐입니다.

이것이 Apple 스택 프론티어의 작가들에게 의미하는 것

세 가지 시사점.

1. 범주적 거부를 먼저 명명하세요. 무엇이 클러스터의 영역 밖인가? 목록을 쓰세요. 클러스터는 그 답에서 정체성을 얻고, 그 답은 명시적이라는 점에서 지속성을 얻습니다.

2. 다음으로 패턴 거부를 명명하세요. 주제와 무관하게 금지되는 목소리와 구조의 형태는 무엇인가? 재활용된 셋업 프레이밍, 비공개 텔레메트리, 편집 비계, 근거 없는 핫테이크. 코퍼스에 살아남는 각각의 패턴은 목소리를 희석시킵니다.

3. 흥미로운 거부에 주목하세요. 영역 안에 있지만 여전히 잘려나가는 주제들. 그것들이 하중을 견디는 취향 결정입니다. 다른 작가들은 그것들을 출시할 것입니다. 여러분은 그러지 않습니다. 그러지 않는 이유가 클러스터의 입장입니다.

전체 Apple Ecosystem 클러스터: Apple Intelligence 표면을 위한 타입드 App Intents; 에이전트 표면을 위한 MCP 서버; 둘 사이의 라우팅 질문; 인앱 온디바이스 LLM 기능을 위한 Foundation Models; 런타임 vs 툴링 LLM 구분; 세 가지 표면 종합; 단일 진실의 원천 패턴; Xcode 통합을 위한 Two MCP Servers; Apple 개발을 위한 hook; Live Activities; watchOS 런타임 계약; SwiftUI 내부; RealityKit의 공간적 사고 모델; SwiftData 스키마 규율; Liquid Glass 패턴; 멀티 플랫폼 출시. 허브는 Apple Ecosystem Series에 있습니다. iOS+AI 에이전트의 더 넓은 맥락은 iOS Agent Development guide를 참고하세요.

FAQ

“제품으로서의 거부”는 무슨 의미인가요?

제품으로서의 거부란 산출물에서 무언가를 빼는 선택이 빠진 콘텐츠 결정이 아니라 포지셔닝 결정이라는 의미입니다. 특정 주제나 특정 구조 패턴을 거부하는 블로그 클러스터는 주제에 부합하는 모든 것을 발행하는 클러스터보다 더 식별 가능한 목소리를 만들어냅니다. 이 패턴은 물리적 제품에서도 나타납니다. Steve Jobs의 1998년 Apple 제품 그리드는 살아남은 것이 아니라 잘라낸 것으로 유명했습니다. 같은 논리가 글쓰기에도 적용됩니다.

이 거부들은 영구적인가요?

일부는 그렇고, 일부는 아닙니다. 범주적 거부(클라우드 LLM 튜토리얼, 채용 기술)는 클러스터의 정체성과 묶여 있고 바뀔 가능성이 낮습니다. 패턴 거부(재활용된 셋업 프레이밍, 편집 비계)는 실제로 강제력이 있는 목소리 규칙이며 앞으로도 적용됩니다. 흥미로운 거부(서버 사이드 Swift, AppKit 전용)는 기저 아키텍처가 변할 때 재평가됩니다. Swift 백엔드가 에이전트가 결합된 Apple 워크플로우에 하중을 견디는 부분이 되는 날, 서버 사이드 Swift는 자리를 얻습니다. 이 목록은 도그마가 아니라 현재의 취향입니다.

왜 거부 목록을 굳이 발행하나요?

목록을 발행하는 것은 세 명의 청중을 위한 것입니다. 독자는 글을 표본으로 읽는 것보다 더 빠르게 클러스터의 영역을 알게 됩니다. 미래의 자신은 비교할 체크포인트를 얻습니다. 클러스터가 거부한다고 주장한 영역으로 표류했는가? 다른 작가들은 인터넷의 이 구석에서 취향이 형성된 글쓰기가 어떤 모습인지 보게 되고, 같은 일을 하기 위한 활성화 에너지가 낮아집니다. 비용은 작고(글 하나), 효과는 지속적입니다.

주제를 거부하면 청중이 줄어들지 않나요?

네, 의도적으로 그렇습니다. 클러스터는 원시 청중을 최대화하기보다는 특정 독자(에이전트를 고민하는 iOS 개발자)와 누적되도록 설계되었습니다. 클러스터 영역 밖의 글은 다른 독자를 끌어들일 수 있지만, 그 독자들은 다른 주제 때문에 왔기 때문에 어차피 다음 글을 위해 돌아오지 않을 것입니다. 누적의 움직임은 같은 독자를 위해 스무 번 연속으로 쓰는 것이지, 스무 명의 다른 독자를 위해 한 번씩 쓰는 것이 아닙니다.

경계선상의 주제는 어떻게 처리하나요?

흥미로운 거부 섹션의 기준을 적용하세요. 그 주제가 클러스터의 입장을 누적시키는가, 아니면 그저 옆에 놓여 있을 뿐인가? 누적시키는 경계선상의 주제는 글로 쓰입니다. 누적시키지 않는 경계선상의 주제는 트래픽을 끌어들일 수 있더라도 잘립니다. 결정은 분량에 관한 것이 아닙니다. 결정은 시간에 따른 클러스터의 일관성에 관한 것입니다. 누적이 유지되는 기준입니다.

References

클러스터의 목소리 규칙(재활용된 셋업 프레이밍 없음, 편집 비계 없음, 증거로서의 비공개 텔레메트리 없음)은 코퍼스 자체에서 보입니다. 클러스터 글 하나를 읽고 또 다른 글을 읽으면, 등장하지 않는 반복적인 형태들이 작동 중인 규칙입니다. 발행된 클러스터가 정전(canonical) 출처입니다.