- Published on
기술 글쓰기와 사이드 프로젝트에 관한 한국어 글 열 편 — 시작하는 법이 아니라 계속하는 법
- Authors
- Name
- Youngju Kim
- @fjvbn20031
첫 글은 쉽고 열 번째 글이 어렵습니다
기술 블로그를 시작하라는 조언은 어디에나 있습니다. 플랫폼을 고르고 첫 글을 올리는 데까지는 대체로 어렵지 않습니다. 문제는 그다음입니다. 두 번째 글은 무엇을 써야 할지 모르겠고, 세 번째 글쯤에서는 이 정도 내용은 이미 다들 아는 것 같아 손이 멈춥니다. 사이드 프로젝트도 똑같습니다. 초기 설계는 즐겁고, 배포 직전에 지칩니다.
그래서 이번 목록은 시작하는 법을 다룬 글을 거의 넣지 않았습니다. 대신 계속하게 만드는 조건을 다룬 글을 모았습니다. 왜 쓰는지, 어떻게 부담을 줄이는지, 어디에 쓰는지, 그리고 만든 것을 어떻게 끝까지 끌고 가는지에 관한 글입니다.
이 목록을 만든 방법
순위가 아니라 편집자 개인의 선택입니다. 조회수나 인기를 잴 방법이 없고 재지도 않았습니다. 세 가지 기준을 썼습니다.
첫째, 자기 경험에서 나온 판단을 담은 글을 골랐습니다. 일반론을 정리한 글보다, 직접 해 보고 생각이 바뀐 지점을 적은 글을 우선했습니다.
둘째, 강의나 코칭 판매가 주된 목적인 글은 제외했습니다. 후보 중에 사례처럼 보이지만 본문 곳곳이 유료 프로그램으로 연결되는 페이지가 있었고, 그런 글은 판단 기준을 흐리기 때문에 뺐습니다.
셋째, 링크를 직접 열어 확인했습니다. 접속이 막히거나 서비스 오류가 뜨거나 실제 내용이 검색 결과의 설명과 다른 후보는 버렸습니다. 실제로 이 단계에서 몇 개가 빠졌습니다.
링크는 2026-08-12에 직접 열어 확인했습니다. 개인 블로그 글은 사라지거나 주소가 바뀔 수 있습니다.
개발자가 글을 쓰는 이유
세 편 모두 같은 질문에 답하지만 결론이 조금씩 다릅니다. 함께 읽으면 자기 이유를 고르기 쉬워집니다.
개발자 글쓰기
브런치 — 쿠우보이 · 2019년 1월 30일
프로그래밍 교육이 코드에서 끝나면 안 되고 쓰기와 말하기를 포함해야 한다는 주장을 담은 글입니다.
이런 사람에게 — 글쓰기가 개발과 별개의 일이라고 생각해 온 사람.
이 글의 핵심 주장은 글쓰기와 코딩이 다른 일이 아니라는 것입니다. 둘 다 의도를 명확하게 표현하고 논리적인 구조를 만드는 작업이라는 점에서 같고, 그래서 한쪽을 잘하는 사람이 다른 쪽을 못한다면 그것은 취향이 아니라 훈련의 문제라고 봅니다. 교육 과정에 문서 작성과 학습 기록을 넣어야 한다는 제안까지 나아가기 때문에, 개인의 습관이 아니라 팀의 제도로 생각해 볼 여지도 줍니다. 오래된 글이지만 논지는 지금도 그대로 유효합니다.
개발자로서 글을 쓰는 이유
브런치 — swimjiy · 2020년 7월 29일
이력서를 위해서가 아니라 자기 이해를 위해 기술 블로그를 쓴다는 관점을 정리한 글입니다.
이런 사람에게 — 블로그를 취업용으로만 생각해 왔고 그래서 계속 쓰기가 힘든 사람.
동기를 어디에 두느냐가 지속성을 결정한다는 점을 짚는 글입니다. 취업이 목적이면 목적이 달성된 순간 쓸 이유가 사라지지만, 이해를 목적으로 두면 계속 쓸 이유가 남습니다. 그리고 글로 설명해 보면 자기가 얼마나 알고 있는지가 드러난다는 지적이 이 글의 중심에 있습니다. 아는 줄 알았던 것을 쓰다가 막히는 경험은 대부분의 개발자가 해 봤을 텐데, 그 경험을 학습의 도구로 재해석합니다.
개발자의 글쓰기
벨로그 — 콜트 · 2021년 7월 24일
기술 블로그를 더 쉽게 쓰기 위한 원칙과, 글의 종류를 네 가지로 나눈 분류를 제안한 글입니다.
이런 사람에게 — 완벽하게 이해하지 못한 주제는 못 쓰겠다고 생각해 손이 멈춘 사람.
이 목록에서 가장 실용적인 글입니다. 주제 의식을 버리고 글감 의식을 가지라는 조언, 독자 수준이 아니라 자기 수준에 맞춰 쓰라는 조언이 모두 쓰기 시작하는 문턱을 낮추는 방향을 향합니다. 그리고 글을 네 가지 종류로 나누는 분류가 특히 유용한데, 자기 글이 어느 종류인지 정하면 구조가 자동으로 정해지기 때문입니다. 모든 것을 다 설명하려 하지 말고 부족한 부분은 링크로 넘기라는 조언도 현실적입니다.
쓰는 습관과 쓸 곳
이유를 정했다면 다음은 유지하는 문제와 장소를 고르는 문제입니다.
글쓰기 습관 만드는 법
브런치 — 글장이 · 2024년 4월 7일
반복과 의식이라는 두 가지 장치로 글쓰기 습관을 만드는 방법을 정리한 글입니다.
이런 사람에게 — 쓸 마음은 있는데 매번 시작을 미루는 사람.
이 글의 유용한 지점은 습관을 의지가 아니라 환경과 신호의 문제로 다룬다는 것입니다. 같은 시간 같은 장소에서 쓰고, 쓰기 직전에 늘 같은 짧은 행동을 반복하면, 시작할지 말지를 매번 결정하지 않아도 됩니다. 습관이 고민을 줄여 준다는 표현이 이 글의 요지를 잘 담고 있습니다. 개발자를 대상으로 쓴 글은 아니지만 오히려 그래서 기술 주제와 무관하게 적용됩니다.
개발자를 위한 글쓰기 관련 책들
브런치 — gnugeun · 2023년 5월 24일
논리적인 글쓰기를 훈련으로 보는 관점에서, 도움이 된 책 몇 권을 소개한 글입니다.
이런 사람에게 — 블로그 글 몇 편으로는 부족하고 제대로 배워 보고 싶은 사람.
책 소개 글이지만 고른 기준이 분명해서 읽을 가치가 있습니다. 문학적인 글쓰기와 논리적인 글쓰기를 구분하고, 후자는 재능보다 노력의 영역이라는 전제에서 출발합니다. 일반 글쓰기 책과 개발자를 겨냥한 책을 나눠 소개하기 때문에 지금 자기에게 필요한 쪽을 고를 수 있습니다. 추천한 책에서 발견한 오류까지 적어 두는 태도가 이 글의 신뢰도를 높입니다.
개발자를 위한 블로그 플랫폼 비교분석
벨로그 — 박은미 · 2021년 6월 15일
여러 블로그 플랫폼의 장단점을 비교하고 그중 하나를 고르기까지의 판단을 적은 글입니다.
이런 사람에게 — 어디에 쓸지 정하지 못해서 아직 첫 글을 안 쓴 사람.
플랫폼 선택은 흔히 과대평가되는 결정이지만, 그렇기 때문에 이 단계에서 오래 멈추는 사람이 많습니다. 이 글은 후보를 나열하고 각각의 성격을 정리한 뒤 자기 기준으로 하나를 고르는 과정을 보여 주기 때문에, 같은 결정을 빨리 끝낼 수 있게 도와줍니다. 결론에 동의하지 않아도 판단의 축을 얻을 수 있다는 점이 중요합니다. 다만 오래된 글이라 각 플랫폼의 기능과 정책은 지금과 다를 수 있습니다.
개발 블로그로 브런치는 괜찮을까?
브런치 — 홍기린 · 2024년 8월 8일
코드 표시가 불편하다는 약점을 알면서도 특정 플랫폼을 고른 이유를 설명한 글입니다.
이런 사람에게 — 남들이 다 쓰는 곳 말고 다른 선택지를 고민 중인 사람.
앞의 글과 짝으로 읽으면 좋습니다. 같은 결정을 다른 기준으로 내렸기 때문입니다. 이 글의 필자는 기능적 우위가 아니라 반응이 오는지와 읽기 편한지를 기준으로 삼았고, 그 기준이 자기 목적과 맞았기 때문에 단점을 감수합니다. 도구 선택에서 정답이 아니라 목적과의 정합성이 중요하다는 점을 보여 주는 사례입니다. 결정을 남에게 맡기지 않고 자기 기준으로 내리는 방식 자체가 참고할 만합니다.
개발 블로그 운영 후기
공부 블로그 Blue log — Lee Jeongan · 2024년 4월 7일
3년 가까이 개인 블로그를 운영하면서 어떤 글이 남고 어떤 글이 의미가 없었는지를 정리한 글입니다.
이런 사람에게 — 블로그를 몇 년 했는데 이걸 계속할 이유를 찾고 있는 사람.
시간이 쌓인 사람만 쓸 수 있는 글입니다. 자기 글을 세 종류로 나눈 뒤 단순 정보 전달 글보다 자기 경험과 성장을 기록한 글이 남는다고 결론짓는데, 이 판단은 몇 년을 해 보지 않으면 나오기 어렵습니다. 조회수를 목표로 삼는 순간 블로그가 의무가 된다는 지적도 정확합니다. 블로그를 생각을 다듬는 필터로 보자는 결론이 앞의 글들과 이어지면서 이 절을 자연스럽게 마무리합니다.
사이드 프로젝트가 수익이 되기까지
만드는 것과 파는 것은 다른 문제입니다. 두 편 모두 그 간격을 다룹니다.
사이드 프로젝트 MVP부터 수익화까지
벨로그 — 정선교 · 2024년 9월 25일
직접 만든 서비스를 1년간 운영하면서 최소 기능 제품에서 수익화까지 간 과정을 정리한 회고입니다.
이런 사람에게 — 사이드 프로젝트를 만들었는데 사용자가 오지 않아 멈춘 사람.
이 글의 가장 큰 교훈은 마케팅보다 제품의 완성도와 빠른 배포를 앞세웠다는 선택입니다. 그리고 성장의 상당 부분이 광고가 아니라 검색 유입에서 나왔다는 점을 기록하는데, 이 구조는 혼자 만드는 사람에게 특히 중요합니다. 광고비를 쓸 수 없는 조건에서는 검색에 걸리는 제품을 만드는 것이 유일하게 지속 가능한 유입 경로이기 때문입니다. 팀으로 일하며 겪은 문제까지 함께 적어서, 혼자가 아니라 둘셋이 시작하려는 사람에게도 참고가 됩니다.
사이드 프로젝트를 월 수익 4,500만 원 비즈니스로
브런치 — 솔비나 · 2024년 10월 27일
해외 1인 개발자가 개인 재무 관리 서비스를 사이드 프로젝트로 시작해 여러 해에 걸쳐 키운 과정을 소개한 글입니다.
이런 사람에게 — 사이드 프로젝트를 오래 끌고 가는 사람들이 실제로 무엇을 견디는지 궁금한 사람.
이 목록에서 유일하게 남의 사례를 취재해 정리한 글입니다. 그래서 본인 회고에서는 잘 드러나지 않는 부분이 보이는데, 특히 출시 초기의 실수와 여러 차례의 번아웃을 함께 다룬다는 점이 그렇습니다. 가격을 잘못 정하고 무료 체험 기간을 너무 길게 잡았다는 식의 구체적인 실수가 적혀 있어서, 같은 단계를 앞둔 사람이 점검표로 쓸 수 있습니다. 성장이 광고가 아니라 오랜 시간의 개선과 솔직한 기록에서 나왔다는 결론도 앞의 글과 맞닿습니다. 다만 이 사례의 숫자는 특정 개인의 결과이며 일반적인 기대치가 아닙니다.
이 블로그의 관련 글
- 엔지니어를 위한 설득하는 글쓰기 — 기술 글쓰기의 다음 단계에 해당합니다.
- AI로 블로그 글 파이프라인 만들기 — 초안이 아니라 검증이 병목이라는 이야기입니다.
- AI가 쓴 글이 무너지는 지점들 — 도구를 쓰더라도 무엇을 직접 확인해야 하는지 다룹니다.
- Diátaxis를 네 개의 폴더로 오해하는 이유 — 한 글에 여러 목적을 섞으면 왜 무너지는지에 관한 글입니다.
이 목록의 한계
열 편 중 여덟 편이 글쓰기 쪽이고 사이드 프로젝트는 두 편뿐입니다. 이 불균형은 의도한 것이 아니라 검증의 결과입니다. 사이드 프로젝트 수익 공개 글은 후보가 많았지만, 열어 보면 유료 강의나 멤버십으로 연결되는 페이지이거나 접속이 되지 않는 경우가 많았습니다. 기준을 낮춰 채우는 대신 통과한 두 편만 실었습니다.
그리고 수익 사례를 읽을 때 한 가지만 유념하시면 좋겠습니다. 공개되는 것은 대체로 잘된 사례이고, 같은 방식으로 시작한 훨씬 많은 프로젝트는 기록으로 남지 않습니다. 여기 실린 글들도 방법의 보증이 아니라 한 사람이 지나온 경로로 읽으시기를 권합니다.