개발자 글이 읽히지 않는 가장 흔한 이유는
내용이 틀려서가 아니다.
대부분의 경우,
말하는 언어가 다르기 때문이다.
개발자는 기술의 언어로 말하고,
독자는 삶의 언어로 이해한다.
이 간극을 넘지 못하면
아무리 좋은 내용도
사람들에게 남지 않는다.
사람들은 코드를 기억하지 않는다
상황을 기억한다
이런 글을 본 적이 있을 것이다.
“이 함수는 O(n)으로 동작합니다.”
“이 구조는 확장성이 좋습니다.”
“이 방식이 더 효율적입니다.”
틀린 말은 아니다.
하지만 며칠 뒤,
이 글의 내용을 기억하는 사람은 거의 없다.
반대로 이런 문장은 남는다.
“새벽 3시에 서버가 죽었을 때 이 코드가 나를 살려줄 수 있을까?”
이 문장에는
복잡한 기술 설명이 없다.
하지만 상황이 있다.
사람들은
기술이 아니라 상황을 통해 이해하고,
상황을 통해 기억한다.
좋은 개발자 글의 공통점
잘 읽히는 개발자 글을 가만히 들여다보면
공통된 특징이 있다.
코드보다 먼저 상황이 나온다
기능 설명보다 맥락이 먼저 등장한다
정답보다 선택의 이유가 강조된다
즉, 이렇게 흐른다.
상황 → 고민 → 판단 → 선택 → 결과
이 구조는
기술 블로그라기보다
이야기에 가깝다.
그리고 이야기는
사람의 머리가 가장 잘 받아들이는 형태다.
기술을 삶의 언어로 바꾼다는 것
기술을 삶의 언어로 번역한다는 건
어려운 말을 쉽게 풀라는 뜻이 아니다.
이건 관점의 이동이다.
예를 들어보자.
“이 API는 RESTful하지 않다”
“이 API는 처음 쓰는 사람이 계속 문서를 다시 보게 만든다”
“이 구조는 결합도가 높다”
“이 구조는 한 군데만 고치려 해도 다른 곳이 같이 깨진다”
“성능 최적화를 했다”
“트래픽이 몰려도 잠을 자러 갈 수 있게 됐다”
기술 용어를 없앤 게 아니다.
기술이 만들어내는 ‘현실의 변화’를 드러낸 것이다.
왜 이 방식이 브랜딩에 강력한가
기술 중심 글은
항상 경쟁자가 많다.
이미 누군가는
더 잘 정리했고,
더 자세히 썼고,
더 빠르게 설명한다.
하지만 당신이 겪은 상황은 복제되지 않는다.
어떤 맥락에서 이 문제를 만났는지
왜 이 선택이 필요했는지
그 선택이 삶을 어떻게 바꿨는지
이건 오직 당신만 쓸 수 있다.
그래서 삶의 언어로 번역된 기술 글은
비교되지 않고,
대체되지 않는다.
독자가 “아, 이거 내 얘기네”라고 느끼는 순간
브랜딩은
사람들이 이런 말을 하기 시작할 때 완성된다.
“이 사람 글은 항상 내 상황이랑 겹친다.”
이 말이 나오면
기술의 깊이와 상관없이
사람들은 계속 돌아온다.
왜냐하면
그 글이 정보를 주기 때문이 아니라
자기 자신을 비춰주기 때문이다.
이렇게 써보자
글을 쓰기 전에
이 질문부터 던져보자.
이 기술이 필요한 순간은 언제였나
이 선택이 나를 어떤 상태에서 꺼내줬나
이걸 도입하기 전과 후의 차이는 무엇이었나
그리고 문장을 이렇게 시작해보자.
“이걸 처음 도입했을 때 가장 불안했던 건…”
“이 기능을 만들기로 결심한 날은…”
“이 구조를 선택한 이유는 단순했다…”
이렇게 쓰면
자연스럽게 기술은 뒤로 물러나고,
이야기가 앞으로 나온다.
다음 글에서는
다음 글에서는
이렇게 쌓인 이야기들을
어디에, 어떻게 쌓아야 브랜드가 되는지를 다룬다.
플랫폼을 많이 쓰는 게 왜 답이 아닌지,
왜 ‘본진’을 하나 정해야 하는지,
그리고 브랜딩이 왜
흩뿌리는 게임이 아니라
축적의 게임인지에 대해 이야기하자.
다음 글에서 계속하자.