Split View: 기술 글쓰기와 사이드 프로젝트에 관한 한국어 글 열 편 — 시작하는 법이 아니라 계속하는 법
기술 글쓰기와 사이드 프로젝트에 관한 한국어 글 열 편 — 시작하는 법이 아니라 계속하는 법
첫 글은 쉽고 열 번째 글이 어렵습니다
기술 블로그를 시작하라는 조언은 어디에나 있습니다. 플랫폼을 고르고 첫 글을 올리는 데까지는 대체로 어렵지 않습니다. 문제는 그다음입니다. 두 번째 글은 무엇을 써야 할지 모르겠고, 세 번째 글쯤에서는 이 정도 내용은 이미 다들 아는 것 같아 손이 멈춥니다. 사이드 프로젝트도 똑같습니다. 초기 설계는 즐겁고, 배포 직전에 지칩니다.
그래서 이번 목록은 시작하는 법을 다룬 글을 거의 넣지 않았습니다. 대신 계속하게 만드는 조건을 다룬 글을 모았습니다. 왜 쓰는지, 어떻게 부담을 줄이는지, 어디에 쓰는지, 그리고 만든 것을 어떻게 끝까지 끌고 가는지에 관한 글입니다.
이 목록을 만든 방법
순위가 아니라 편집자 개인의 선택입니다. 조회수나 인기를 잴 방법이 없고 재지도 않았습니다. 세 가지 기준을 썼습니다.
첫째, 자기 경험에서 나온 판단을 담은 글을 골랐습니다. 일반론을 정리한 글보다, 직접 해 보고 생각이 바뀐 지점을 적은 글을 우선했습니다.
둘째, 강의나 코칭 판매가 주된 목적인 글은 제외했습니다. 후보 중에 사례처럼 보이지만 본문 곳곳이 유료 프로그램으로 연결되는 페이지가 있었고, 그런 글은 판단 기준을 흐리기 때문에 뺐습니다.
셋째, 링크를 직접 열어 확인했습니다. 접속이 막히거나 서비스 오류가 뜨거나 실제 내용이 검색 결과의 설명과 다른 후보는 버렸습니다. 실제로 이 단계에서 몇 개가 빠졌습니다.
링크는 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를 네 개의 폴더로 오해하는 이유 — 한 글에 여러 목적을 섞으면 왜 무너지는지에 관한 글입니다.
이 목록의 한계
열 편 중 여덟 편이 글쓰기 쪽이고 사이드 프로젝트는 두 편뿐입니다. 이 불균형은 의도한 것이 아니라 검증의 결과입니다. 사이드 프로젝트 수익 공개 글은 후보가 많았지만, 열어 보면 유료 강의나 멤버십으로 연결되는 페이지이거나 접속이 되지 않는 경우가 많았습니다. 기준을 낮춰 채우는 대신 통과한 두 편만 실었습니다.
그리고 수익 사례를 읽을 때 한 가지만 유념하시면 좋겠습니다. 공개되는 것은 대체로 잘된 사례이고, 같은 방식으로 시작한 훨씬 많은 프로젝트는 기록으로 남지 않습니다. 여기 실린 글들도 방법의 보증이 아니라 한 사람이 지나온 경로로 읽으시기를 권합니다.
Ten Korean Posts on Technical Writing and Side Projects — Not How to Start, How to Keep Going
- The first post is easy; the tenth is hard
- How this list was assembled
- Why developers write
- Habits, and where to publish
- From side project to revenue
- Related writing on this blog
- Limits of this list
A note on language. Every linked piece below is written in Korean. The descriptions here are mine, in English, but the destinations are Korean-language pages.
The first post is easy; the tenth is hard
Advice to start a technical blog is everywhere. Choosing a platform and publishing the first post is usually not difficult. The trouble comes after. You have no idea what the second post should be, and around the third your hands stop because it feels like everyone already knows this much. Side projects behave the same way: the early design is fun and you run out of energy just before shipping.
So this list contains almost nothing about getting started. Instead it gathers writing about the conditions that let you keep going: why you write, how to lower the cost, where to publish, and how to carry a built thing all the way through.
How this list was assembled
An editorial pick by one person, not a ranking. I have no way to measure view counts or popularity, and I did not try. I used three criteria.
First, I chose pieces carrying judgment earned from experience. Writing that records where the author's thinking changed after doing the thing was preferred over general summaries.
Second, I excluded anything whose main purpose is selling a course or coaching. Some candidates read like case studies but routed to paid programs throughout the body, and that compromises the reader's judgment, so they are out.
Third, I opened every link and checked it. Candidates blocked from access, returning a service error, or whose content did not match the search snippet were dropped. Several fell out at exactly this step.
Every link was opened and verified on 2026-08-12. Personal blog posts can disappear or change addresses.
Why developers write
All three answer the same question and reach slightly different conclusions. Read together, they make it easier to pick your own reason.
Developer writing
Brunch — 쿠우보이 · January 30, 2019
Argues that programming education cannot stop at code and must include writing and speaking.
Read this if — you have treated writing as separate from engineering.
The central claim is that writing and coding are not different activities. Both are about expressing intent precisely and building a logical structure, so if someone is good at one and poor at the other, the author reads that as a training gap rather than a matter of taste. It goes as far as proposing that documentation and learning logs belong in the curriculum, which opens room to think about this as a team practice rather than a personal habit. An older post, but the argument holds up.
Why I write as a developer
Brunch — swimjiy · July 29, 2020
Frames technical blogging as something done for self-understanding rather than for a resume.
Read this if — you have thought of your blog as a hiring artifact and consequently struggle to keep writing.
This piece identifies that where you locate the motive determines whether you persist. If employment is the goal, the reason to write disappears the moment the goal is met; if understanding is the goal, the reason remains. At its center is the observation that explaining something in writing exposes how much you actually know. Most developers have had the experience of stalling while writing up something they assumed they understood, and this reframes that experience as a learning instrument.
A developer's writing
Velog — 콜트 · July 24, 2021
Proposes principles for writing technical posts more easily, plus a four-way classification of post types.
Read this if — you stop because you feel you cannot write about anything you have not fully mastered.
The most practical piece on this list. The advice to drop topic-consciousness in favor of material-consciousness, and to write at your own level rather than calibrating to the reader, all points toward lowering the threshold for starting. The four-way classification is especially useful, because deciding which kind your post is settles the structure automatically. The advice to stop trying to explain everything and link out for the gaps is realistic too.
Habits, and where to publish
Once the reason is settled, what remains is sustaining it and choosing a place.
How to build a writing habit
Brunch — 글장이 · April 7, 2024
Builds a writing habit out of two devices: repetition and ritual.
Read this if — you intend to write and postpone starting every time.
The useful move here is treating habit as a matter of environment and cues rather than willpower. Write at the same time in the same place, repeat the same short action immediately beforehand, and you no longer have to decide whether to start each time. The line about habits reducing deliberation captures the thesis well. It was not written for developers, which is precisely why it transfers regardless of subject matter.
Writing books for developers
Brunch — gnugeun · May 24, 2023
Recommends several books, from the view that logical writing is a trainable skill.
Read this if — a few blog posts are not enough and you want to study this properly.
It is a book roundup, but the selection criteria are explicit enough to make it worth reading. It separates literary writing from logical writing and starts from the premise that the latter rewards effort more than talent. Splitting general writing books from developer-targeted ones lets you pick whichever side you need now. Recording the errors the author found inside a recommended book raises the credibility of the whole piece.
Comparing blog platforms for developers
Velog — 박은미 · June 15, 2021
Compares the strengths and weaknesses of several platforms and records the reasoning behind choosing one.
Read this if — you have not written a first post because you cannot decide where.
Platform choice is commonly overrated as a decision, which is exactly why so many people stall at this step. This piece lists the candidates, characterizes each, and then chooses on the author's own criteria, which helps you finish the same decision quickly. What matters is that you gain an axis for judging even if you disagree with the conclusion. It is an older post, so each platform's features and policies may differ now.
Is Brunch acceptable as a development blog?
Brunch — 홍기린 · August 8, 2024
Explains choosing a particular platform while fully aware that code display on it is awkward.
Read this if — you are considering something other than the default everyone uses.
Good as a pair with the previous piece, because it is the same decision made on different criteria. This author optimizes for whether responses arrive and whether the reading experience is good, not for feature superiority, and accepts the drawbacks because those criteria match the purpose. It is a demonstration that in tool selection there is no right answer, only fit with intent. The method of deciding on your own criteria rather than deferring to others is itself worth borrowing.
Notes on running a development blog
공부 블로그 Blue log — Lee Jeongan · April 7, 2024
Nearly three years of running a personal blog, sorted into what lasted and what turned out meaningless.
Read this if — you have blogged for a few years and are looking for a reason to continue.
This is a piece only someone with accumulated time could write. It sorts the author's own posts into three kinds and concludes that records of personal experience and growth outlast simple information transfer, a judgment hard to reach without several years of evidence. The observation that a blog becomes an obligation the moment view counts become the goal is accurate. Concluding that a blog is a filter for refining your thinking connects back to the earlier pieces and closes this section naturally.
From side project to revenue
Building and selling are different problems. Both of these address the gap.
A side project from MVP to monetization
Velog — 정선교 · September 25, 2024
A one-year retrospective on running a self-built service from minimum viable product through to monetization.
Read this if — you built a side project and stalled because nobody came.
The largest lesson is the choice to prioritize product quality and fast deployment over marketing. It also records that much of the growth came from search rather than advertising, a structure that matters enormously for someone building alone. When you cannot spend on ads, making something discoverable through search is the only sustainable acquisition path available. Problems encountered working as a team are included too, so it is useful for people starting in twos and threes rather than solo.
Turning a side project into a business with monthly revenue of 45 million won
Brunch — 솔비나 · October 27, 2024
Profiles an overseas solo developer who started a personal finance service as a side project and grew it over several years.
Read this if — you want to know what people who sustain side projects long-term actually endure.
The only piece here reported about someone else rather than written as self-retrospective, which surfaces things personal write-ups tend to omit — notably the early launch mistakes and repeated burnout, treated together. Concrete errors such as mispricing and setting the free trial too long are recorded, so someone approaching the same stage can use it as a checklist. The conclusion that growth came from long improvement and honest storytelling rather than advertising meets the previous piece. Note that this case's figures are one individual's outcome, not a general expectation.
Related writing on this blog
- Persuasive writing for engineers — the stage after technical writing.
- Building a blog pipeline with AI — on verification, not drafting, being the bottleneck.
- Where AI-written text falls apart — what you still have to check yourself when using tools.
- Why Diátaxis gets mistaken for four folders — on why mixing several purposes into one piece collapses.
Limits of this list
Eight of the ten sit on the writing side and only two are side projects. That imbalance was not intended; it is the result of verification. There were many candidate revenue-disclosure posts, but opening them usually revealed pages routing to paid courses or memberships, or pages that would not load at all. Rather than lowering the bar to fill the section, I published only the two that passed.
One thing to keep in mind when reading revenue stories. What gets published is generally the case that worked, and the far larger number of projects begun the same way leave no record. Read these as one person's path rather than as a guarantee of method.