1인개발

개발자가 SNS·뉴스레터를 공장처럼 찍어내는 방법

이걸로 sns 글쓰기 걱정은 완전히 사라집니다

2026.07.08 | 조회 543 |
0
|
from.
개발자H

퍼스널 브랜딩을 시작하려는데, 오늘 뭘 써야 할지 모르겠다면

첨부 이미지

퍼스널 브랜딩, 이제는 해야 한다는 걸 모르는 개발자는 없습니다. 문제는 다들 알면서도 대부분 3주를 못 넘긴다는 겁니다. 혹시 지금 이 글을 열어둔 채로도 "그래서 오늘은 뭘 쓰지?"라는 질문 앞에서 커서만 깜빡이고 있다면, 이 이야기는 정확히 당신 이야기입니다.

AI가 웬만한 코드를 대신 짜주는 시대가 되면서, 채용 시장도 조용히 바뀌었어요. "무엇을 만들 수 있는가"만큼이나 "무엇을 아는 사람으로 보이는가"가 중요해졌습니다. 그래서 다들 링크드인을 켜고, 뉴스레터 플랫폼에 가입하고, 첫 글을 씁니다. 여기까지는 누구나 합니다.

진짜 어려운 건 시작이 아니라 지속이에요. 첫 글은 그동안 쌓아둔 이야기로 어떻게든 씁니다. 그런데 2주 차, 3주 차가 되면 통장 잔고처럼 소재가 바닥나요. 매주 백지 앞에서 "이번엔 뭘 쓰지"를 반복하다 보면, 글쓰기가 자기표현이 아니라 숙제가 됩니다. 숙제는 결국 밀리고, 밀린 숙제는 결국 포기로 끝나죠.

저도 똑같았습니다. 그래서 어느 순간 결론을 내렸어요. 의지의 문제가 아니라 시스템의 문제라고. 그래서 개발자답게, 글감이 마르지 않고 SNS와 뉴스레터가 매주 자동으로 굴러가는 파이프라인을 직접 만들었습니다. 이 글에서 그 구조를 통째로 공개합니다.

 

매번 처음부터 쓰는 글쓰기가 지속될 리 없습니다

왜 3주 만에 소재가 바닥날까요. 답은 의외로 단순합니다. 매번 빈 문서에서 시작하기 때문입니다.

한번 생각해 보세요. 월요일에 글 하나를 씁니다. 두 시간 넘게 고민해서 겨우 발행해요. 그런데 그 글은 발행 버튼을 누르는 순간 손을 떠납니다. 어딘가로 흘러가 버리고, 다음 주 월요일이 되면 나는 다시 완전한 백지 앞에 앉아요. 지난주에 쏟은 두 시간이 이번 주 글쓰기를 1분도 덜어주지 않습니다. 이게 반복되면 지치는 게 당연해요.

문제의 본질은 이겁니다. 쓴 글이 다음 글의 재료가 되지 않는다는 것. 개발로 치면 매번 라이브러리 없이, 재사용 가능한 함수 하나 없이 모든 기능을 처음부터 다시 짜는 셈이에요. 그 누구도 그렇게는 오래 일하지 못합니다. 지식은 분명 쌓이고 있는데, 그게 콘텐츠라는 결과물로 연결되는 통로가 없는 거죠.

여기서 한 가지가 더 겹칩니다. 저는 한동안 외부 매체에 기고글을 썼는데요. 시간당 페이는 나쁘지 않았지만, 그때그때 매체가 원하는 주제에 저를 맞추다 보니 결국 '콘텐츠 외주'가 되더라고요. 내 지식이 복리로 쌓이는 구조가 아니라, 매번 남의 요구에 맞춰 리소스를 태우는 구조. 열심히 할수록 남는 게 없다는 감각, 개발자라면 기술 부채에서 익히 느껴본 그 감각이었습니다.

그래서 결심했어요. 남의 판에서 소진되지 말고, 내 지식이 자동으로 축적되고 재사용되는 나만의 파이프라인을 만들자. 이름 붙여 부르자면 콘텐츠 운영 시스템, 저는 이걸 만들기 시작했습니다.

 

글 하나를 강의도 뉴스레터도 SNS 포스트도 만드는 방법


첨부 이미지

시스템의 뼈대는 두 개의 개념입니다. 하나는 플라이휠(Flywheel), 다른 하나는 원 소스 멀티 채널(One Source Multi Channel)이에요.

먼저 플라이휠. 이건 콘텐츠 활동을 3단계 선순환으로 보는 관점입니다.

1단계는 콘텐츠입니다. SNS와 뉴스레터로 시장의 반응을 봐요. 어떤 주제에 사람들이 반응하는지, 어떤 고민이 실제로 존재하는지를 검증하는 단계입니다. 사실상 무료 수요조사예요.

2단계는 제품입니다. 콘텐츠로 검증된 수요를 실제 서비스나 도구로 만듭니다. 이미 반응을 확인한 뒤에 만들기 때문에, 아무도 원하지 않는 걸 만들 위험이 크게 줄어요.

3단계는 자산입니다. 1·2단계에서 얻은 검증된 지식과 경험을 강의나 전자책으로 전환합니다. 여기서 비로소 수익이 발생하고, 그 수익과 반응이 다시 1단계 콘텐츠로 흘러 들어가 바퀴가 한 바퀴 더 돕니다.

핵심은 이 바퀴가 글 한 편에서 시작된다는 겁니다. 여기서 두 번째 개념, 원 소스 멀티 채널이 등장해요. 지식 노트 하나를 잘 정리해 두면, 그걸 소스로 삼아 링크드인 포스트, 스레드 포스트, 그리고 이 뉴스레터까지 각 채널에 맞는 형태로 파생시킵니다. 노트 1개가 채널 3개의 콘텐츠가 되는 거죠. 매번 백지에서 시작하는 게 아니라, 이미 검증된 내 지식 창고에서 꺼내 오는 방식입니다.

그래서 이 구조에서는 글이 흘러가 사라지지 않아요. 쓴 글은 노트로 남고, 노트는 다음 콘텐츠의 재료가 되고, 재료는 쌓일수록 자산이 됩니다. 제텔카스텐식 지식 축적과 플라이휠식 수익 선순환이 만나는 지점이 바로 여기예요. 콘텐츠는 소비되는 게 아니라, 쌓일수록 복리로 불어나는 자산이 됩니다.

 

어떻게 만들었나 — 비용 0원, 로컬 AI, GitHub Actions

첨부 이미지

그래서 실제로 뭘 썼느냐. 스택은 생각보다 단순하고, 놀랍게도 운영 비용이 0원입니다.

  • Obsidian — 지식 저장소입니다. 모든 노트가 마크다운 파일로 로컬에 쌓입니다. 제텔카스텐 방식으로 주제별 지식을 관리하는 본진이에요.
  • Claude Code — 로컬에서 도는 AI 워커입니다. 내 노트를 직접 읽어 각 채널용 초안을 생성합니다.
  • GitHub Actions — 자동화 담당입니다. 무료 한도 안에서 발행·수집 흐름을 굴립니다.
  • Buffer API — 발행된 콘텐츠의 반응 지표를 수집해 옵니다.

여기까지 오는 데 세 가지 핵심 결정이 있었어요.

첫째, 노션 대신 옵시디언. 노션은 보여주기엔 예쁘지만, AI가 내 지식을 읽어야 하는 시스템에서는 마크다운과 Git 친화적인 로컬 파일이 압도적으로 유리합니다. 로컬 파일은 AI가 수 밀리초 만에 읽어요. 도구가 아니라 콘텐츠의 밀도에 집중할 수 있는 환경이 됩니다.

둘째, 외부 AI API 대신 로컬 AI. 내 파일을 직접 읽는 로컬 방식이 속도, 보안, 비용 모든 면에서 나았습니다. 민감할 수 있는 내 지식 창고를 통째로 외부로 보낼 이유가 없었어요.

셋째, 완성 후 배포 대신 70%만 만들고 써보기. 이게 개발자로서 가장 중요한 결정이었습니다. 완벽하게 설계한 뒤 배포하는 것보다, 대충 굴러가는 상태로 먼저 써보고 피드백을 받는 게 훨씬 빨랐어요. 피드백 루프가 설계보다 항상 빠릅니다.

물론 순탄하지만은 않았어요. AI에게 긴 맥락을 넘기다 보면 품질이 뭉개지는 컨텍스트 문제, 생성물의 품질을 걸러낼 QA 레이어 설계 같은, 만들기 전엔 예상 못 한 문제들이 줄줄이 나왔습니다. 이 시행착오들은 그 자체로 한 편 분량이라, 다음 편에서 제대로 풀어볼게요. 시스템의 전체 구조가 어떻게 짜여져있는지부터 먼저 감을 잡아두시면 다음 편이 훨씬 잘 읽힐 거예요.

 

아직 미완성이지만, 이미 작동하고 있습니다

솔직하게 털어놓을게요. 이 시스템은 아직 완성이 아닙니다. 진행률로 치면 대략 64% 정도예요. 여전히 손이 가는 수동 단계가 남아 있고, 자동화하려다 만 부분도 있습니다.

그런데도 중요한 건, 이미 매주 SNS와 뉴스레터가 나가고 있다는 사실이에요. 지금 읽고 계신 이 글도 그 시스템에서 나온 결과물입니다. 완벽하지 않은 채로도 바퀴는 돌고 있어요. 완성하고 나서 시작하려 했다면, 저는 아직도 설계 문서만 붙잡고 있었을 겁니다. 완성하고 시작하려다가는 영원히 시작을 못 합니다.

그래서 이 글을 여기까지 읽은 당신에게, 거창한 시스템 말고 오늘 당장 할 수 있는 세 가지를 남깁니다. 셋 다 할 필요 없어요. 하나만 해도 바퀴는 처음 반 바퀴를 돕니다.

  1. 오늘 쓴 글이나 배운 것 하나를 노트 앱에 저장해 보기. 흘려보내지 말고 남기는 것, 그게 축적의 시작입니다.
  2. "이 지식은 어디서 왔나"를 출처로 달아 보기. 재료에 라벨을 붙여두면 나중에 꺼내 쓰기 쉬워집니다.
  3. 내 글감 3가지를 적어 보기. "나는 누구에게, 어떤 도움을 줄 수 있는가"를 세 문장으로. 이게 당신만의 지식 창고 첫 선반이 됩니다.

시작은 이 정도면 충분해요. 시스템은 그다음에 얹으면 됩니다.

 

투표

이 파이프라인을 직접 만든다면, 가장 자세히 알고 싶은 부분은?

AI가 긴 맥락에서 품질이 뭉개지는 문제 잡기 62.5% (5표)
생성물을 걸러내는 QA 레이어 설계 25.0% (2표)
GitHub Actions로 발행·수집 자동화 0.0% (0표)
노트 1개 → 여러 채널로 파생(원 소스 멀티 채널) 구조 12.5% (1표)

총 8명이 투표했습니다.


이 뉴스레터가 조금이라도 도움이 됐다면, 같은 고민을 하는 동료 개발자에게 공유해 주세요. 그리고 아직 구독 전이라면, 매주 이런 이야기를 받아보실 수 있도록 구독을 눌러주세요.

다음 편 예고 — 이번 편에서 살짝 언급한 시행착오들, 컨텍스트가 뭉개지는 문제와 AI 생성물의 QA 레이어를 어떻게 설계했는지를 상세히 풀어봅니다. 시스템을 직접 만들어보고 싶은 분이라면 다음 편이 진짜 알맹이일 거예요.

 

 

다가올 뉴스레터가 궁금하신가요?

지금 구독해서 새로운 레터를 받아보세요

✉️

이번 뉴스레터 어떠셨나요?

개발자H의 생존 비법서 님에게 ☕️ 커피와 ✉️ 쪽지를 보내보세요!

댓글

의견을 남겨주세요

확인
의견이 있으신가요? 제일 먼저 댓글을 달아보세요 !

다른 뉴스레터

© 2026 개발자H의 생존 비법서

개발자로 일하고, 벌고, 성장하는 법 | 취업/이직 준비, 커리어 성장, 부업, 1인개발 — 직접 부딪혀본 것만 씁니다.

뉴스레터 문의developerh@freefromjob.kr

메일리 로고

도움말 오류 및 기능 관련 제보

서비스 이용 문의admin@team.maily.so 채팅으로 문의하기

메일리 사업자 정보

메일리 (대표자: 이한결) | 사업자번호: 717-47-00705 | 서울특별시 송파구 위례광장로 199, 5층 501-2-31호

이용약관 | 개인정보처리방침 | 정기결제 이용약관 | 라이선스