인터넷에는 새로운 종류의 콘텐츠 오염이 존재합니다.

그것은 깔끔해 보입니다.
그것은 빠릅니다.
그것은 자신감이 넘칩니다.
그것은 보통 인스턴트 라면이 대개 식사가 되는 것과 비슷한 방식으로 정확합니다.

여러분도 보셨을 것입니다.

의심스러울 정도로 동일한 예시를 사용하여 분산 시스템 (distributed systems)을 설명하는 20개의 포스트.
모두가 캐싱 (caching)에 대한 동일한 조언으로 끝나는 성능에 관한 30개의 스레드.
무언가를 직접 구축해 보려 할 때까지는 유용하게 들리지만, 결국 2018년에 작성된 누군가의 블로그 포스트를 누군가가 요약하고, 그것을 또 누군가가 요약한 것을 다듬어 놓은 것에 불과하다는 것을 깨닫게 되는 기술 콘텐츠의 홍수.

이것이 바로 AI 노이즈 (AI noise) 시대입니다.

그렇다고 해서 AI가 나쁘다는 뜻은 아닙니다.
그렇지 않습니다.
AI는 유용합니다.
AI는 빠릅니다.
AI는 훌륭한 작가들이 더 잘 생각하고 더 빠르게 움직일 수 있도록 도울 수 있습니다.

하지만 AI는 출판 환경을 한 가지 중요한 방식으로 변화시켰습니다.

평범한 콘텐츠는 이제 거의 공짜가 되었습니다.

이는 일반적인 조언을 담은 기술적으로 정확한 포스트를 작성하는 기존의 전략만으로는 더 이상 충분하지 않다는 것을 의미합니다. 만약 여러분의 포스트가 프롬프트 (prompt)와 괜찮은 모델 (model)을 통해 6초 만에 재현될 수 있다면, 여러분의 포스트는 범용 상품 시장 (commodity market)에서 경쟁하고 있는 것입니다. 범용 상품 시장은 저자에게 친절하지 않습니다.

따라서 질문은 어떻게 더 많은 포스트를 작성하느냐가 아닙니다.

질문은 모두가 즉시 발행할 수 있는 시대에 어떻게 여전히 가치 있는 기술 포스트를 작성하느냐입니다.

정답은 깊이 (depth)입니다.
하지만 가짜 같은 깊이가 아닙니다.

진정한 깊이 말입니다.

현실과의 접촉에서 오는 그런 깊이 말입니다.

첫 번째 규칙은 간단합니다

설명하기 전에 경험으로부터 쓰십시오.

대부분의 기술 포스트는 개념부터 시작해서 문제에 도달하지 못하기 때문에 실패합니다.

그들은 어떤 것이 무엇인지 설명합니다.
그들은 이점을 나열합니다.
그들은 용어를 정의합니다.
그들은 교육적인 것처럼 들립니다.
그들은 독자를 변화시키지 못한 채 남겨둡니다.

사람들은 정의를 기억하지 않습니다.
사람들은 긴장감 (tension)을 기억합니다.

AI 노이즈 속에서 포스트가 살아남는 것은, 모델이 스스로는 잘 흉내 낼 수 없는 무언가로 시작할 때입니다.
실제 사건.
고통스러운 트레이드오프 (trade-off).
시간을 허비하게 만든 실수.
똑똑해 보였지만 나중에 운영 환경 (production)에서 실패한 결정.
문서 (docs)가 약속한 대로 작동하기를 거부하는 문제.

이것이 모든 포스트에 전쟁 이야기 (war story)가 필요하다는 뜻은 아닙니다.

모든 포스트에는 마찰 (friction)이 필요하다는 뜻입니다.

만약 재시도 (retries)에 대해 쓰고 있다면, 재시도에 대한 교과서적인 설명으로 시작하지 마세요.

중복 지급 사건으로 시작하세요.
두 번 결제된 고객의 사례로 시작하세요.
즉시 대규모로 재시도를 수행하는 바람에 하류 서비스 (downstream service)를 정중하게 녹여버린 큐 (queue) 이야기로 시작하세요.
이제 독자는 관심을 갖게 됩니다.

AI는 개념을 요약할 수 있습니다.
하지만 축적된 판단력 (earned judgment)을 대체하는 데는 어려움을 겪습니다.

그것이 당신의 강점입니다.
그것을 활용하세요.

결정을 내려야 하는 사람들을 위해 쓰세요

많은 기술 문서들이 무한한 시간과 완전한 맥락을 가지고 있으며, 예산 압박도 받지 않는 가상의 독자를 위해 작성됩니다.

그런 독자는 존재하지 않습니다.

실제 독자들은 무언가를 결정하려고 노력 중입니다.

이 도구를 도입해야 할까.
이 서비스를 리팩터링 (refactor)해야 할까.
데이터베이스를 분리해야 할까.
큐 (queue)를 도입해야 할까.
모놀리스 (monolith)를 1년 더 유지해야 할까.
이 벤치마크 (benchmark)를 믿어도 될까.
이 기술을 가진 사람을 채용해야 할까.

만약 당신의 포스트가 누군가의 결정을 돕지 못한다면, 그 글은 훑어보고, 북마크하고, 잊혀질 것입니다. 이는 '영원히 무시된다'는 말을 아주 정중하게 표현한 것입니다.

강력한 기술 포스트는 기사로 위장한 '의사결정 지원 문서'입니다.

그것들은 독자가 다음과 같은 질문에 답할 수 있도록 돕습니다.

이것은 실제로 어떤 문제를 해결하는 데 탁월한가.
실제 환경에서 운영하는 데 비용이 얼마나 드는가.
무엇이 가장 먼저 망가지는가.
어느 정도의 팀 성숙도 (team maturity)가 요구되는가.
도입하기에 너무 이른 시점임을 알려주는 신호는 무엇인가.
이미 너무 늦었다는 것을 알려주는 신호는 무엇인가.

이 지점에서 경험이 드러납니다.

주니어 작성자는 종종 무엇이 '가능한지'를 설명합니다.
숙련된 작성자는 무엇이 '권장되는지'를 설명합니다.

후자가 살아남습니다.

백과사전을 쓰는 것을 멈추세요

똑똑해 보이면서도 아무런 쓸모가 없게 만드는 가장 쉬운 방법 중 하나는 '완벽한 가이드(complete guide)'를 쓰는 것입니다.

완벽한 가이드는 종종 선택을 내리지 않은 것에 대한 긴 사과문에 불과합니다.

그것은 모든 것을 포함합니다.
판단(judgment)은 배제합니다.
어떠한 입장도 취하지 않기에 반박하는 것조차 불가능합니다.

AI가 범람하는 인터넷 환경에서, 완벽함(completeness)은 더 이상 해자(moat)가 아닙니다.
기계는 방대한 개요(exhaustive overviews)를 작성하는 데 매우 능숙합니다.

기계가 못하는 것은 유용한 축약(useful reduction)입니다.

독자들에게 필요한 것은 더 많은 정보가 아닙니다.
그들은 더 나은 압축(compression)을 필요로 합니다.

더 좁게 쓰세요.
더 과감하게 쳐내세요.
관점(point of view)을 선택하세요.

이렇게 쓰지 마세요.

'이 글은 관측 가능성(observability)에 관한 모든 것을 설명합니다.'

이렇게 쓰세요.

'팀의 엔지니어가 10명 미만이라면, 별도의 온보딩 절차가 필요한 대시보드를 구매하기 전에 지연 시간(latency), 에러율(error rate), 그리고 하나의 비즈니스 지표로 관측 가능성(observability)을 시작하세요.'

이 문장에는 혈압(blood pressure)이 있습니다.
사용자가 있습니다.
제약 조건(constraints)이 있습니다.
권장 사항(recommendation)이 있습니다.
누군가는 이에 반대할 수 있습니다.
좋습니다.
이제 당신은 글을 쓰고 있는 것입니다.

AI 노이즈 속에서도 살아남는 포스트는 대개 척추(spine)가 있습니다.
무언가를 대변합니다.

독창성은 이상해지는 것이 아니다

많은 사람이 독창성(originality)이라는 말을 들으면 즉시 혼돈(chaos)을 만들어냅니다.

아니요.
그것은 독창성이 아닙니다.
그것은 그저 서식이 갖춰진 카페인 섭취일 뿐입니다.

독창적인 기술 글쓰기(technical writing)는 대개 더 날카로운 정직함으로 묘사된 익숙한 진실입니다.

혁명적인 이론이 필요한 것이 아닙니다.
명확하게 진술된 실제 관찰(observation)이 필요할 뿐입니다.

예를 들어보겠습니다.

'대부분의 팀은 확장성(scaling) 문제를 겪는 것이 아니라, 확장성이라는 가면을 쓴 조정(coordination) 문제를 겪고 있다.'

이것은 새로운 물리 법칙이 아닙니다.
하지만 유용합니다.
날카롭습니다.
많은 엔지니어가 목격했지만 소리 내어 말하는 사람은 거의 없는 현실을 반영합니다.

독창성은 종종 패턴 인식(pattern recognition)에서 옵니다.

수년이 흐르면, 동일한 실패가 다른 옷을 입고 계속 반복된다는 것을 깨닫게 됩니다.
스택(stack)은 다르지만,
실수는 같습니다.
로고는 다르지만,
조직적 문제는 같습니다.
도구(tooling)는 다르지만,
소유권(ownership)의 부재는 같습니다.

그 패턴을 글로 적으세요.

그것이 바로 여러분이 해야 할 일입니다.

AI는 언어를 재조합할 수 있습니다.
하지만 수년간의 관찰(noticing)을 쉽게 대체할 수는 없습니다.

중요한 곳에서는 구체적으로, 도움이 되는 곳에서는 추상적으로

이것은 숙련된 기술(craft skill)이며, 모든 것을 변화시킵니다.

부실한 기술 포스트는 너무 오랫동안 추상적인 상태로 머물러 있습니다.
강력한 포스트는 적절한 순간에 구체적인 세부 사항(concrete detail)과 일반적인 원칙(general principle) 사이를 오갑니다.

추상적인 상태에만 머문다면, 포스트는 공허하게 느껴집니다.
너무 구체적인 상태에만 머문다면, 포스트는 다른 사람이 사용할 수 없는 일기장(diary entry)이 되어 버립니다.

여러분은 두 가지 모두를 원해야 합니다.

구체적인 사례(concrete case)를 보여주세요.
그다음 원칙(principle)을 추출하세요.
그다음 그 원칙이 깨지는 지점을 보여주세요.

예시적인 리듬(rhythm)입니다.

"우리는 재시도(retries) 로직을 워커(worker) 내부로 옮겼고, 제공자 성능 저하(provider degradation) 상황에서 실수로 부하를 배가시켰습니다."

원칙은 회복 탄력성 메커니즘(resilience mechanisms)이 제한(bounded)되지 않으면 실패 압박(failure pressure)을 증가시킬 수 있다는 것입니다.

실질적인 해결책(practical fix)은 백오프(backoff), 지터(jitter), 멱등성 키(idempotency keys), 그리고 비즈니스 가치와 결합된 엄격한 재시도 예산(hard retry budget)이었습니다.

이제 독자는 한 번의 읽기만으로 이야기, 교훈, 그리고 구현 방향을 얻게 됩니다.

이것이 살아남는 이유는 단순한 사실(facts) 이상의 것을 가르치기 때문입니다.
그것은 사고방식(thinking)을 가르칩니다.

어른처럼 트레이드오프(trade offs)를 설명하세요

AI가 생성한 기술 콘텐츠는 종종 익숙한 냄새가 납니다.
모든 것이 유익합니다.
모든 도구는 강력합니다.
모든 패턴은 확장성(scalability), 신뢰성(reliability), 개발자 경험(developer experience), 그리고 아마도 여러분의 태세(posture)를 개선합니다.

실제 시스템은 그렇게 작동하지 않습니다.

모든 기술적 결정은 승자와 패자를 만듭니다.
모든 추상화(abstraction)는 복잡성을 어딘가로 이동시킵니다.
모든 편의성에는 청구서(bill)가 따릅니다.
보통은 매달 말에 말이죠.

여러분의 글이 살아남기를 원한다면, 그 청구서의 내용을 명시하는 사람이 되십시오.

이벤트 기반 시스템(event driven systems)이 결합도(decoupling)를 개선한다고만 말하지 마세요.

그것이 디버깅을 더 어렵게 만들고, 데이터 일관성(data consistency)을 기술적인 문제보다 사회적인 문제로 만들며, 출시의 흥분이 가라앉은 훨씬 후에도 팀이 계약(contracts)에 신경 쓰도록 만든다고 말하세요.

마이크로서비스(microservices)가 확장성을 개선한다고만 말하지 마세요.

팀 구조가 여전히 더 많은 회의를 동반한 하나의 모놀리스(monolith)처럼 운영되고 있다면, 마이크로서비스(microservices)가 시스템의 일부에 대한 확장성(scaling)은 개선할 수 있지만 소유권(ownership), 테스트(testing), 그리고 장애 대응(incident response)은 극적으로 악화시킬 수 있다고 말하세요.

이것이 성숙한 독자들이 신뢰하는 방식입니다.

낙관론이 아니라,
조정(Calibration)입니다.

좋은 기술 포스트는 적어도 한 번의 잘못된 결정에 대한 대가를 치러본 사람의 조언처럼 느껴져야 합니다.

AI가 보통 누락하는 것들을 추가하세요

많은 인간의 기술적 글쓰기와 AI가 생성한 글을 비교해 보면, 한 가지 패턴이 빠르게 나타납니다.

기계는 종종 '무엇(what)'과 '왜(why)'를 다룹니다.
하지만 '언제(when)', '만약(if)', 그리고 '다음에 어떤 일이 일어나는가(what happens next)'에 대해서는 훨씬 취약합니다.

그 간극이 바로 여러분의 글이 지속 가능해질 수 있는 지점입니다.

타이밍(timing)을 포함하세요.

팀이 이것을 언제 채택해야 하는가.
어느 단계가 너무 이른 단계인가.
준비가 되었음을 시사하는 증상은 무엇인가.

전제 조건(prerequisites)을 포함하세요.

이 접근 방식이 작동하기 위해 이미 충족되어야 하는 것은 무엇인가.
팀의 기술 수준.
운영 성숙도(operational maturity).
트래픽 패턴(traffic patterns).
비즈니스 제약 사항(business constraints).

실패 모드(failure modes)를 포함하세요.

실제 상황에서 이것이 어떻게 잘못되는가.
사람들이 과소평가하는 것은 무엇인가.
장애(incidents) 발생 중에 무엇이 망가지는가.
조용히 비용을 발생시키는 것은 무엇인가.

유지보수의 현실(maintenance reality)을 포함하세요.

9개월 차에는 누가 이것을 책임지는가.
업그레이드는 어떻게 이루어지는가.
어떤 지식이 한 사람에게 집중되어, 그 사람이 오프라인일 때 모두의 주말을 망치게 되는가.

가역성(reversibility)을 포함하세요.

팀이 되돌아갈 수 있는가.
롤백(rollback) 비용은 얼마나 드는가.
어떤 결정이 고착화(sticky)되는가.

이것들은 장식적인 세부 사항이 아닙니다.
기술적 글쓰기(technical writing)와 기술적 마케팅(technical marketing)을 가르는 차이입니다.

독자들은 왜 하나가 더 신뢰할 만하게 느껴지는지 항상 설명할 수는 없더라도, 그 차이를 알고 있습니다.

구문(syntax)만이 아닌, 판단력(judgment)을 드러내는 예시를 사용하세요

코드 예시는 좋습니다.
맥락이 없는 아주 작은 토이 스니펫(toy snippets)은 종종 그렇지 못합니다.

구문을 가르치는 용도도 있겠지만, 목표가 노이즈 속에서도 살아남는 포스트라면 예시는 단순히 컴파일되는 것 이상의 역할을 해야 합니다.

예시는 설계 선택(design choices)을 드러내야 합니다.

단순히 재시도 루프 (retry loop)를 어떻게 구현하는지 보여주는 대신, 왜 비핵심 작업 (non-critical operations)에 대해서는 재시도 횟수를 낮은 숫자로 제한하고 나머지는 데드 레터 큐 (dead letter queue)를 사용했는지 그 이유를 보여주세요.

단순히 캐시 래퍼 (cache wrapper)를 보여주는 대신, 도메인 (domain)에 따라 데이터 신선도 허용치 (stale data tolerance)가 어떻게 변하는지 보여주세요.
제품 카탈로그는 몇 분 정도는 허용할 수 있습니다.
지갑 잔액은 그럴 수 없습니다.
이제 독자는 단순한 코드가 아니라 아키텍처 (architecture)를 배우게 됩니다.

가장 가치 있는 예시는 모든 엔지니어의 마음속에 있는 숨겨진 질문에 답하는 예시입니다.

"좋습니다, 하지만 사람들이 실제로 사용하는 시스템에서는 이것을 어떻게 수행하나요?"

그 질문을 위해 글을 쓰세요.

당신의 글을 반증 가능하게 (falsifiable) 만드세요

이것은 학술적으로 들릴 수 있습니다.
하지만 실제로는 매우 실용적입니다.

잊히기 쉬운 많은 콘텐츠는 검증 가능한 내용을 아무것도 말하지 않기 때문에 살아남습니다.
그것은 모두 분위기 (vibes)와 동사 (verbs)뿐입니다.

견고한 기술 문서 (technical writing)는 도전받을 수 있는 주장을 합니다.

"소규모 팀의 경우, 기본적인 관측성 (observability)을 확보하기 전에 서비스 메시 (service mesh)를 추가하는 것은 일반적으로 신뢰성 (reliability)을 높이는 것보다 운영 복잡성 (operational complexity)을 더 빠르게 증가시킵니다."

이것이 하나의 주장입니다.
사람들은 이에 대해 토론할 수 있습니다.
사람들은 자신의 경험에 비추어 이를 테스트할 수 있습니다.
사람들은 미묘한 차이 (nuance)를 더할 수 있습니다.
그것이 건강한 상태입니다.

당신의 글에 반대 의견이 존재할 수 있을 때, 그 글은 형태 (shape)를 갖게 됩니다.
형태를 갖추었을 때, 비로소 기억됩니다.

끝없는 단서 (caveats) 뒤에 숨지 마세요.
네, 맥락 (context)은 중요합니다.
항상 중요합니다.
하지만 그럼에도 당신은 무언가를 말해야 합니다.

당신의 역할은 비판받는 것이 불가능하게 만드는 것이 아닙니다.
당신의 역할은 비판을 감수할 만큼 충분히 유용해지는 것입니다.

다른 사람을 만나본 적이 있는 사람처럼 쓰세요

기술 문서 작성에는 진지하게 들리기 위해 모든 개성을 제거하려는 이상한 트렌드가 있습니다.

이는 대개 토스터기를 설명하는 준수 문서 (compliance document)처럼 들리는 텍스트를 만들어냅니다.

스탠드업 코미디를 할 필요는 없습니다.
하지만 당신만의 목소리 (voice)는 필요합니다.

유머는 공유된 고통을 압축해주기 때문에 도움이 됩니다.

레거시 시스템 (legacy system)을 유지보수해 본 사람이라면 누구나 다음과 같은 문장을 이해합니다.

"우리가 코드를 들여다보기 전까지는 코드가 완벽하게 작동했습니다."

그 문장은 실제로 효과가 있습니다.
그것은 공감대 (rapport)를 형성합니다.
경험이 있다는 신호를 보냅니다.
독자에게 계속 읽어야 할 이유를 제공합니다.

적절한 양의 풍자 (Sarcasm) 또한 도움이 됩니다.
핵심은 '적절한'입니다.
당신은 요리에 양념을 치는 것이지, 주방에 불을 지르는 것이 아닙니다.

목표는 개성을 과시하는 것이 아닙니다.
목표는 공개적인 장소에서 명확하게 사고하는 유능한 사람처럼 들리는 것입니다.

그러한 톤이 살아남는 이유는 독자들이 필자와 생성기 (generator) 사이의 차이를 느낄 수 있기 때문입니다.

구조는 이전보다 지금 더 중요합니다

AI 노이즈는 독자들이 공격적으로 훑어 읽도록(scan) 훈련시켰습니다.

그들이 무례한 것이 아닙니다.
그들은 적응하고 있는 것입니다.

만약 당신의 포스트에 형태 (shape)가 없다면, 독자들은 당신의 가장 핵심적인 논점이 나타나기도 전에 떠날 것입니다.

독자에게 경로를 제시하십시오.

긴장감으로 시작하십시오.
문제를 명시하십시오.
주장을 밝히십시오.
추론 과정을 따라가십시오.
예시를 보여주십시오.
트레이드오프 (trade-offs)를 인정하십시오.
실용적인 시사점 (takeaway)으로 마무리하십시오.

좋은 구조는 장식이 아닙니다.
그것은 존중입니다.

그것은 당신이 독자의 시간을 요구하기 전에 이미 정보를 분류 (sorting)했다는 사실을 독자에게 알려줍니다.

유용한 테스트 방법은 다음과 같습니다.