개발 블로그 글쓰기의 안티패턴

개발 블로그에서 가장 흔한 실수는 본론에 도달하기까지 너무 오래 걸리는 것임. 제목과 첫 세 문장 안에 누구를 위한 글인지, 읽으면 무엇을 얻는지 알려야 함 독자가 자신과 같은 지식을 가졌다고 가정하지 않아야 함. 실제 친구나 동료를 기준 독자로 정하고, 그 사람이 아는 용어와 모르는 용어에 맞춰 설명을 점검함 생소한 용어에 링크만 붙이거나 이전 편을 읽으라고 요구하지 말고, 현재 글만으로 이해할 수 있는 최소한의 설명을 제공해야 함 진지하게 보이려고 딱딱하게 쓰기보다 평소 말하듯 자기 목소리로 써야 함. AI에 글쓰기를 맡기며 획일적인 글이 늘수록 개성 있는 문체가 중요해짐 좋은 내용도 읽기 불편하면 소용없음. 모바일에서 본문이 화면을 넘치지 않는지, 글꼴과 색상 대비가 읽기 편한지 게시 전에 확인해야 함 장황한 도입부와 불필요한 서문 소프트웨어 블로그에서 가장 흔한 실수는 핵심에 도달하기까지 너무 오래 걸리는 것임 배경 이야기, 역사적 맥락, 떠오르는 생각을 늘어놓는 것은 쓰는 사람에게 즐거워도 독자에게 흥미롭지는 않을 수 있음 독자는 다른 수많은 글을 선택할 수 있으므로, 얻을 것이 있다는 기대 없이는 20분을 투자해 끝까지 읽지 않음 제목과 첫 세 문장 안에 두 질문에 답해야 함 이 글은 나 같은 사람을 위해 쓰였는가? 읽으면 어떤 이익을 얻는가? 읽을 이유는 새로운 기술이나 개념, 새로운 시각, 재미있는 이야기나 신랄한 비판 등 무엇이든 될 수 있지만, 반드시 무언가를 제공해야 함 if got, want: 더 나은 Go 테스트를 작성하는 간단한 방법은 잘 알려지지 않은 Go 테스트 패턴을 30초 안에 배울 수 있다는 도입으로 대상 독자와 가치를 곧바로 알림 매력적인 도입을 썼더라도 부제, 자기소개, 이미지, 유명인의 인용문이 읽는 흐름을 방해할 수 있음 이런 요소를 넣을 수는 있지만, 독자의 제한된 집중력을 소모하고 계속 읽도록 설득할 기회를 줄인다는 점을 고려해야 함 독자가 무엇을 아는지 과도하게 가정하지 않기 새로운 개념은 독자에게 익숙한 대상과 비교하면 이해하기 쉽지만, 무엇이 익숙한지 먼저 판단해야 함 Jellyfin은 Netflix 같은 스트리밍 서비스이되, 오픈소스이고 사적으로 운영해 시청 습관을 감시받지 않는다는 식으로 소개할 수 있음 Docker 입문 글에서 Linux cgroups의 프런트엔드나 *BSD jails의 Linux 버전이라고만 설명하면, 해당 용어를 모르는 독자를 놓침 Do...