"퍼스널 브랜딩"이라는 단어를 들으면 반사적으로 거부감이 드는 개발자가 많을 거다. 나도 그랬다. 개발자가 무슨 인플루언서도 아니고, 코드나 잘 치면 되지. 브랜딩이라니. 링크드인에 "passionate about..."을 적으라는 건가. 아니면 트위터에서 매일 "오늘의 TIL" 스레드를 올리라는 건가.

그런데 이 거부감의 원인을 곰곰이 생각해보면, "브랜딩"이라는 단어 자체의 문제다. 브랜딩은 의도적으로 이미지를 설계하고 관리하는 뉘앙스가 있다. 마케팅 용어니까 당연하다. 개발자에게 이걸 적용하면 어색해진다. "나라는 상품을 포지셔닝합니다"라니 오글거리지 않을 수 없다.

그래서 이 글에서는 "브랜딩"이라는 단어를 안 쓰려고 한다. 대신 "찾아지는 사람"이라는 프레임으로 이야기하려고 한다. 본질은 같지만 접근 방식이 전혀 다르다.

3년 전에 나를 도운 그 사람#

한번 떠올려보면 좋겠다. 지난 1~2년 동안 개발하면서 막혔던 순간들. 특정 에러 메시지를 구글에 치면 나오는 블로그 글. Stack Overflow에서 정확히 내 상황에 맞는 답변을 달아준 사람. GitHub 이슈에서 "나도 같은 문제 겪었는데 이렇게 해결했어요"라고 댓글을 남긴 사람.

그 사람들의 이름을 기억하는가? 아마 대부분 기억하지 못할 거다. 그런데 중요한 건, 그 사람들이 의도적으로 "브랜딩"을 한 게 아니라는 거다. 그들은 그냥 자기가 겪은 문제와 해결 과정을 어딘가에 적어둔 거다. 그게 검색에 걸려서 누군가에게 도움이 됐다.

이게 "찾아지는 사람"의 본질이다. 소셜 미디어 전략이 아니다. 도움이 되는 빵 부스러기를 인터넷에 남기는 거다.

한 개발자가 "Learn in Public"이라는 개념을 정리한 적이 있다. 핵심은 이거다. 학습의 배기가스를 공개적으로 남겨라. 블로그를 쓰든, 튜토리얼을 만들든, Stack Overflow에 답변을 달든, 형태는 상관없다. 중요한 건 닫힌 공간(슬랙, 디스코드, 노션)이 아니라 열린 공간에 남기는 거다. 그래야 검색에 잡힌다. 검색에 잡혀야 누군가에게 도달한다.

그리고 그 글에서 가장 인상적이었던 부분은 이거다. 이 모든 것의 첫 번째 수혜자는 다른 사람이 아니라 3개월 뒤의 자기 자신이라는 것.

이력서와 블로그의 간극#

이직을 준비할 때 이걸 뼈저리게 느꼈다. 이력서에는 "React 기반 프론트엔드 개발 3년"이라고 적혀 있다. 같은 포지션에 지원하는 수십 명도 비슷한 이력서를 낸다. "Next.js 경험", "TypeScript 사용", "성능 최적화 경험". 채용 담당자 입장에서 이 사람들이 전부 비슷하게 보인다.

이때 차이를 만드는 게 "찾아지는 흔적"이다. 블로그에 "Next.js App Router 마이그레이션 중 겪은 캐싱 이슈와 해결 과정"이라는 글이 있으면, 이력서에 "Next.js 경험"이라고 적는 것과는 전달력이 완전히 다르다. 면접관이 "블로그 글 읽어봤는데, 캐싱 문제 해결한 과정이 인상적이었어요"라고 말하는 순간, 서류 더미 속의 이력서가 구체적인 사람으로 바뀐다.

이건 "브랜딩"이 아니다. 자기가 겪은 걸 적어둔 것뿐이다. 근데 그 기록이 나를 "찾아지는 사람"으로 만들어준다.

도움의 빵 부스러기#

"찾아지는 사람"이 되는 가장 자연스러운 방법은 자기가 해결한 문제를 기록하는 거다.

구체적일수록 좋다. "React 성능 최적화"라는 제목보다 "React.memo를 useMemo로 교체했더니 리렌더링이 300ms에서 50ms로 줄어든 과정"이 검색에 훨씬 잘 잡힌다. 왜냐하면 실제로 그 문제를 겪고 있는 사람은 "React 성능 최적화" 같은 일반적인 키워드가 아니라, 아주 구체적인 상황을 검색하기 때문이다.

"이 정도 내용을 글로 쓸 가치가 있나?"라는 생각이 드는 글이 오히려 가치가 높은 경우가 많다. 너무 기초적인 것 같아서 망설여지는 주제. 근데 누군가에게는 딱 그 기초적인 설명이 필요한 시점이 있다. 그리고 기초적인 내용을 정확하게 설명하는 것도 실력이다.

한 개발자 교육자의 철학이 이거다. "다른 사람이 웹을 더 잘 만들 수 있도록 돕다 보면, 가시성은 자연스럽게 따라온다." 자기 PR을 하려고 글을 쓰는 게 아니라, 도움이 되는 글을 쓰다 보면 결과적으로 "찾아지는 사람"이 된다는 거다. 순서가 반대다. 가시성이 목표가 되면 어색해지고, 도움이 목표가 되면 자연스러워진다.

사내에서 "찾아지는 사람"#

"찾아지는 사람"이 반드시 외부 활동을 해야 하는 건 아니다. 사내에서도 같은 논리가 적용된다.

회사 노션이나 위키에 기술 문서를 꾸준히 남기는 사람이 있다. 트러블슈팅 과정, 기술 선택의 배경, 삽질 기록. 처음에는 아무도 안 읽는 것 같다. 그런데 3개월쯤 지나면 다른 팀에서 "혹시 이 문서 쓰신 분이에요?"라고 물어오는 일이 생긴다. 비슷한 문제를 겪다가 검색으로 찾은 거다.

이게 사내에서 "찾아지는 사람"이 되는 과정이다. "이 문제는 그 사람한테 물어봐"라는 말을 듣기 시작하면, 그게 사내에서의 "찾아지는 사람"이다.

장점이 있다. 외부 블로그와 달리 피드백 루프가 빠르다. 동료가 바로 읽고 코멘트를 준다. "이 부분 설명 좋았는데, 실제로는 좀 다른 것 같아"라는 피드백이 오면 글쓰기 실력도 느는 거다. 그리고 사내 문서를 꾸준히 쓴 사람은 팀 내 기술적 의사결정에서 발언권이 자연스럽게 높아진다. 문서로 근거를 남겨온 사람의 말에는 무게가 실린다.

80%의 개발자는 보이지 않는다#

한 가지 구조적인 사실이 있다. 개발자의 대다수는 온라인에서 보이지 않는다. 블로그를 안 쓰고, SNS에 기술 글을 안 올리고, 오픈소스에 기여하지 않는다. 조용히 일하고 조용히 퇴근한다.

이건 나쁜 게 아니다. 대부분의 개발자에게 합리적인 선택이다. 글쓰기는 에너지가 들고, SNS는 피곤하고, 오픈소스 기여는 시간이 없다. 충분히 이해한다.

다만, 이 구조에서 파생되는 현상이 있다. 조금이라도 보이는 사람이 실제 실력 대비 과대평가되는 경향이 있다. 80%가 안 보이니까, 20% 안에만 들어가도 상대적으로 눈에 띈다. 블로그 글 다섯 개만 있어도 "이 사람은 정리하는 습관이 있구나"라는 인상을 준다. 글이 0개인 사람과 5개인 사람의 실력 차이는 크지 않을 수 있는데, 인식의 차이는 크다.

이걸 "불공평하다"고 볼 수도 있고, "활용할 수 있는 구조"라고 볼 수도 있다. 나는 후자 쪽이다. 특별히 뛰어나지 않아도, 기록하고 공유하는 것만으로 "찾아지는 사람"이 될 수 있다면 그건 꽤 효율적인 투자다.

과잉 포장의 문제#

반대로 너무 적극적으로 "보이려는" 사람의 문제도 짚어야 한다.

SNS에서는 대단해 보이는데 실제로 같이 일해보면 기대에 못 미치는 경우. 이건 "찾아지는 사람"이 아니라 "포장하는 사람"이다. 포장과 실체 사이의 간극이 생기면, 그 간극이 신뢰를 깎는다. 한 번 깎인 신뢰는 복구하기 어렵다.

"찾아지는 사람"의 핵심은 솔직함이다. 성공한 경험만 쓰지 않는다. 실패한 시도, 잘못된 판단, 아직 모르는 것도 적는다. "이 접근으로 해봤는데 안 됐다. 그래서 다른 방법을 찾았다." 이런 글이 "최적의 방법은 이것이다"라는 글보다 오히려 더 신뢰를 준다. 실제 업무에서 문제를 푸는 과정이 깔끔한 경우는 거의 없으니까. 삽질 과정이 드러나는 글이 현실적이고, 현실적인 글이 도움이 된다.

틀릴 수도 있다는 걸 인정하는 것도 중요하다. "이렇게 했는데, 더 좋은 방법이 있으면 알려주세요"라는 한 줄을 추가하는 것만으로도 글의 톤이 달라진다. 완벽한 전문가의 강의가 아니라, 같이 배우는 동료의 공유가 된다.

꾸준함이 깊이를 이기는 영역#

이건 흥미로운 점인데, "찾아지는 사람"의 세계에서는 한 편의 대작보다 열 편의 짧은 기록이 더 효과적이다.

팀에서 1년 넘게 매주 짧은 TIL(Today I Learned)을 올리는 동료가 있다. 글 하나하나는 500자 정도, 대단한 깊이는 아니다. 근데 1년치가 쌓이니까 그 사람의 프로필에 들어가면 "꾸준하다"는 인상을 먼저 받게 된다. 한 달에 한 편씩 대작을 쓰는 것보다, 매주 작은 기록을 남기는 게 "찾아지는 사람"으로서는 더 효과적이다.

이유가 있다. 검색 유입은 글의 수에 비례한다. 한 편의 완벽한 글은 한 가지 키워드로만 검색에 잡힌다. 열 편의 짧은 글은 열 가지 키워드로 검색에 잡힌다. 진입점이 열 배다. 그리고 방문자가 하나의 글을 읽고 다른 글도 클릭할 확률은 글의 수가 많을수록 올라간다. 양이 질을 만드는 구조다.

이건 "대충 쓰라"는 뜻이 아니다. "완벽하게 쓰려다가 아예 안 쓰는 것보다, 적당히 쓰고 발행하는 게 낫다"는 뜻이다. 완벽한 글 0편과 괜찮은 글 10편 사이의 선택이다.

작은 시작#

큰 전략이 필요한 게 아니다.

오늘 업무 중에 겪은 에러 하나를 해결했으면, 그 과정을 어딘가에 적어두는 거다. 사내 위키든, 개인 블로그든, 노션이든 상관없다. 형식도 중요하지 않다. "문제: OO 에러 발생. 원인: OO. 해결: OO." 이 세 줄이면 된다.

이걸 한 달에 두세 번만 해도 반년이면 열다섯 개가 쌓인다. 열다섯 개의 에러 해결 기록이 있는 사람과 0개인 사람. 실력 차이가 아니라 기록 차이인데, 외부에서 보이는 인상은 꽤 다르다.

그리고 한 가지 더. 글을 쓸 때 검색 유입을 약간만 신경 쓰면 도달 범위가 달라진다. "React 성능 최적화"보다 "React 리스트 렌더링에서 key를 index로 쓰면 안 되는 이유"가 검색에 잘 잡힌다. 사람들이 실제로 검색하는 건 포괄적인 주제가 아니라 구체적인 문제 상황이니까. 제목에 에러 메시지나 구체적인 상황을 넣으면 같은 문제를 겪고 있는 사람이 도달할 확률이 높아진다.

"브랜딩"이라고 하면 거창해지고 부담스러워진다. 소셜 미디어 전략, 콘텐츠 캘린더, 타겟 오디언스. 이런 건 다 필요 없다. 내가 겪은 문제와 해결을 열린 공간에 남기는 거다. 그게 검색에 잡히고, 누군가에게 도움이 되고, 그 누군가가 나를 기억한다. 이 흐름이 충분히 반복되면, 어느 순간 "찾아지는 사람"이 되어 있다.

그 3년 전에 Stack Overflow에서 나를 도운 사람처럼. 그 사람은 아마 자기가 나를 도왔다는 사실도 모를 거다. 의도하지 않았는데 도움이 된 거다. 그게 "찾아지는 사람"의 가장 좋은 형태라고 생각한다. 의도적으로 보이려는 게 아니라, 도움이 되는 흔적을 남기다 보니 자연스럽게 보이게 되는 것.