개발하기 바쁜데 글까지 쓰라고? (글쓰는 개발자가 되자.)

신입시절. 배워야 할 것도 회사 업무도 많아 허우적대던 때가 있었다. 그렇게 하루에 3~4시간 자며 정신없이 하루를 보내던 날 문득 동기 형이 “개발자는 기술 블로그를 해야 돼!“라는 전혀 이해가 안 되는 말을 해온다. 이렇게 바빠 죽겠는데 블로그에 글까지 쓰라고? 말이 되는 소릴 하라며 반박하다 못내 이기는 척 하나 둘 글을 쓰기 시작했고, 다른 유명 블로거처럼 엄청나진 않지만 하루에 1,000~2,000명 정도 들어오며 점점 성장해 가는 나만의 기술 블로그가 되었다.

또한 필자의 개발자 경력(?)을 돌이켜 보자면 기술 블로그를 하기 전과 하고 난 후로 나뉠 만큼 기술 블로그는 개인적으로 엄청난 영향력이 되었다.

이 기회를 빌어 동기 형에게 감사의 인사를 전하고 싶다. 형. 보고 있죠? ;]

이번 포스팅은 꼭 “블로그를 하자” 라기 보다 “글을 왜 써야 하고 어떻게 써야 하는지"에 대해 이야기해보고자 한다. 처음 이 글을 쓰려고 마음먹었을 땐 개발자라는 직군에 국한되지 않고 누구에게나 적용될 정도의 범용적인 글을 쓰려 했으나 “S"의 조언으로 독자(타깃)을 최대한 개발자에 맞춰 써보고자 한다. thanks to “S”

사실 조금만 검색을 해보면 특히 개발자에게 글쓰기가 얼마나 중요한지 찾아볼 수 있을 정도로 다양한 글들에서 “개발자가 왜 글을 써야 하는가"에 대한 내용이 언급이 되곤 했었다. 글을 쓰지 않던 개발자. 하지만 지금은 글쓰기가 정말 중요하다고 느끼며 적어도 2주에 하나 이상의 글을 쓰려는 현업 개발자의 시선에서 정리를 해보고자 한다. 그리고 마침 멘토링 해주고 있는 분께도 글 쓰는것에 대한 중요성을 알려주고 싶었고, 팀 내에도 공유를 하고 싶어 겸사겸사.

왜 글을 써야 할까?

비로소 내 것이 되기 위한 과정

프로그래밍 언어를 처음 배울때 꼭 만나는 문구 Hello World를 출력하시오. 이게 의미하는 의미가 무엇일까? 정말 새로운 세계를 알려주려 하는 것 일까?(그럴수도 있다…) 우리가 살아가며 “배움"이라는 과정은 대부분 비슷하겠지만 특히 IT 기술은 책을 다 읽었다든지, 동영상 강의를 다 들었다고 해서 내 것이 되었다고 말하기는 어려울 것 같다. 직접 키보드를 두드려 가며 거기서 얻을 수 있는 또 다른 “인사이트” 가 생길 수도 있기 때문이다.

다른 예로, 운영하던 시스템이나 서비스에서 장애를 맞았다고 가정해보자. 하지만 우리는 늘 그래왔듯 어떻게든 장애를 해결할 것이다. 이러한 상황에서 분명 “문제의 원인"이 있었을 테고 “해결 과정"이 있기 마련인데 이곳에서도 “인사이트"가 분명 있을 것이다.

이러한 “인사이트"를 글로 적다 보면 그냥 “아~ 그렇구나, 그랬었지” 하는 머릿속에서의 기억보다는 훨씬 더 오래 남을 것이고 혹여 글에서 정리를 잘못해 다른 사람들의 피드백이 있다면 더할 나위 없이 좋은 효과라고 생각이 된다. (이것이 바로 공유의 힘!)

더불어 글을 쓸 때 올바른 정보에 기반하여 쓰는 습관이 중요한데 그러다 보면 원래 쓰려고 했던 내용보다 더 깊게 알아가는 과정 속에서 또 다른 배움을 얻을 수 있는 반강제적 기회가 생길 수 있다. 누가 시키지 않았어도 배운 것에 대한 활용을 하고 싶은 생각이 들고 이를 또 글로 쓰고. 긍정적인 순환 속에 생겨나는 작은 발자국일지라도 성장해가는 자신을 느낄 수 있을 것이다.

몸이 기억하는 정리하는 습관

개발을 하다 보면 정말 간단한 “CRUD”(Create, Read, Update, Delete) 부터 시작해서 엄청나게 복잡한 도메인 지식에 기반하여 개발을 해야 하는 상황이 생긴다. 그럴 때면 머릿속으로 정리하는 것보다 그림이나 글을 써가면서 정리하는 게 좋다는 건 굳이 말하지 않아도 아는 사실. 글을 쓰다 보면 기승전결의 정리 방법과 목적이 무엇이고 근거가 무엇인지에 대해 구분하는 스킬이 늘어나는 것 같다.(적어도 필자는 기술 블로그를 운영하면서 정리하는 스킬이 그전보다 엄청나게 늘어났다고 자부한다.)

구조가 보기 어렵게 꼬여버린 스파게티 코드나 기능(스펙)이 너무 복잡한 도메인 지식도 글을 쓰며 갈고닦은 “정리 스킬"이 있다면 보다 깔끔한 코드로, 복잡하지만 간결한 스펙으로 정리하는 데 도움이 될 수 있다. 이러한 스킬은 비단 개발할 때나 스펙 정리할 때 뿐만 아니라 상대방과의 이야기를 할 때나 어떠한 계획을 세울 때. 고민이 생겼을 때 등 정말 다양한 곳에서 사용할 수 있는 정말 “나만의 무기"가 될 수 있다.

나를 브랜딩하는 수단 (a.k.a 기술블로그)

특히 이 글을 읽고 있는 독자가 학생이시라면 “글쓰기”, 나아가서는 “기술 블로그"를 강력 추천하고 싶다. (그렇다고 학생이 아니라면 늦었다는 소리는 아니다. 지금 당장 시작하자.)

자신이 어떤 생각을 가지고 어떤 기술에 관심을 가지며 어떤 문제 해결을 해왔는지에 대해 나만의 개발 히스토리로 한눈에 볼 수 있는 수단이 된다고 생각하기 때문이다. 참, 요즘 채용시에 Github 계정이나 기술 블로그를 제출해야 하는 곳이 많이 생길 정도로 기술 블로그에 대한 관심이 부쩍 늘어난 것 같다. (적어도 필자가 취업할 때보다는… 아. 옛날이여)

필자는 기술 블로그를 운영하면서 집필, 추천평 등 전혀 예상하지 못한 경험을 할 수 있었다. (그중에 한 것도 있고 거절한 것도 있지만…) 그에 발표를 할 수 있었던 좋은 기회도 생겼고, 개인 메일로 이직 제안이나 기술 문의 등 “회사"라는 명찰을 떼고 외부에서 오롯이 나 혼자 일어설 수 있는 힘이 조금씩 생겨나고 있는것 같다. (그렇다고 이직 의사가 있다는 건 전~혀 아니니 오해는 말자. 회사님 사랑해요.)

취업이나 이직을 할 때. 나에 대해 누군가에게 알리는 순간이 있을 때 구구절절 이런저런 기술들을 할 줄 알고 이런저런 경험을 해봤어요라고 말하는 것도 방법이 될수 있지만 우아하게 기술 블로그 링크하나 딱! 전달해 보는건 어떨까? 뭔가 더 있어 보이지 않을까?

글을 쓸때 중요한 핵심 6가지

그래서 너가 말하고 싶은게 뭔데?

글을 쓰다 보면 이야기하고 싶은 게 많아서(잘 쓰고 싶어서) 결론보다는 그 결론을 말하기 위한 보충 설명이나 근거를 먼저 말하곤 한다. 하지만 글을 읽는 독자 입장에서는 정답(=결론)이 가장 궁금한데 그것이 글의 말미에 있다면 자칫 글의 퀄리티가 아무리 좋더라도 지루한(?) 과정을 거치는 수고가 필요할 수밖에 없다. 가급적 글의 무게중심은 서두에 두는 게 “글"이라는 목적에 부합하는 것 같다. 결론을 앞에서 이야기하고 근거를 이야기한 후 마지막에 한 번 더 결론을 이야기하는 것도 하나의 방법이 될 수 있겠다.

그래도 뚜렷한 결론이 있다면 다행이다. 결론마저 없는 글은 독자로 하여금 왜 글을 썼는지 모를 느낌을 안겨줄 수 있다.(최악의 경우 읽다가 중단하게 된다…ㅜㅜ) 글쓰기에 있어 결론도 중요하지만 이 글을 쓰는 목적이 명확해야 설령 목표가 글 뒤에 배치되었다고 해도 끝까지 읽을 수 있는 힘이 생기지 않을까?

누가 읽게 되는 글인가?

글을 쓰는 사람(필자)이 있으면 글을 읽는 사람(독자)이 있기 마련. 대부분의 글들은 필자가 독자를 “설득"하기 위한 내용이 주를 이룬다. 독자가 한정적이라면. 예컨대, 주간 보고를 쓴다고 가정했을 때 독자는 오롯이 팀장님이 된다. 이런 경우 주저리주저리 쓰거나 다시 한번 묻게 되는 문장들보다는 팀장님이 정말 궁금해할 내용을 적어주는 게 좋다. 한 번 더 안 물어볼 수 있게 작성한 글을 팀장님의 위치에서 다시 한번 읽어보는 것도 하나의 방법이 될 수 있다.

만약 독자의 스펙트럼이 넓거나 기술 블로그처럼 불특정 다수라면 가장 지식이 없는 사람에게 쓰는 것처럼 글을 써보자. 가끔 너무 쉽고 자세히 써서 당신이 아마추어처럼 보일 것 같다는 우려를 할 수도 있다. 하지만 지금 글을 쓰는 당신이 적어도 글을 안 쓰고 읽기만 하는 독자보다는 가장 프로에 가깝다.

독자가 다 알 거라는 생각은 하지 말자. 최대한 쉽게. 처음 보는 사람도 보고 따라 하거나 이해가 되도록 눈높이를 낮춰서 쓰는 습관을 길러보자. 무려 당신의 글을 시간을 할애하면서까지 읽어주는데 최대한 친절해야 하지 않을까?

앵무새가 되지 말자.

링크만 복붙하거나 소위 말해 펌 글, 정작 내용은 없고 코드만 덩그러니 있거나 단순히 “글쓰기"를 위해 쓰는 글들은 오히려 안 쓰는게 좋다.

글에는 자신만의 생각이 녹아있어야 한다고 생각한다. 그렇지 않고서는 따라쟁이 앵무새와 다를 게 없다. 어떠한 오픈소스를 도입하는 과정을 글로 썼다고 생각해보자. Step By Step으로 따라 할 수 있게 작성한 글일지라도 최소한 마지막에는 자신만의 생각이 정리되어 있어야 글을 쓰는 자신도, 글을 읽는 독자도 “마무리"가 될 수 있기 때문이다. 왜 오픈소스를 도입하게 되었고, 도입하는 과정에서의 문제, 도입하고 나서의 장점과 단점 등 이야기할 거리는 무궁무진하다.

글쓰기에도 호흡이 중요

TV나 인터넷 영상들을 보고 있노라면 편집의 기술이 엄청나게 발전된 것을 체감할 수 있다. 혹시 체감하지 못했다면 화면의 전환이나 자막 등 너무 자연스러워서일 수 있다. 글쓰기에서도 이러한 전환이나 문장의 흐름, 호흡은 정말 중요하다.

이러한 글쓰기에서의 호흡은 문장 쪼개기, 단락 구분하기, 적절한 그림 및 표 활용 등 독자가 읽을 때 지루하지 않을 정도의 말 그대로 “숨 쉴 수 있는 타이밍"을 제공해야 한다. 읽을 때 집중이 잘 안되거나 어디까지 읽었지 하며 흐름이 끊긴 경우를 경험해 봤을 거라 생각이 든다. 사실 이 부분은 필자도 잘 안되긴 하지만 이번 포스팅처럼 말하고자 하는 메인 키워드 단위로 나눈다거나 약간의 위트를 더하기 위한 짤 같은 것도 이러한 “호흡"의 기술이라 생각한다.

퇴고. 글쓰기의 가장 중요한 단계

지금 이 글을 쓰는 순간에도 퇴고를 10번 이상 하는 것 같다. 필자가 생각하는 퇴고라 함은 쓴 글의 처음부터 끝까지 읽어보며 맞춤법이나 띄어쓰기 교정, 실제로 소리 내어 읽어보며 숨이 차거나 집중이 흐려지진 않은지 하는 일련의 과정을 말한다.

퇴고를 꼭 몇번 해야 한다는 정해진 규칙은 없지만 최소 3번은 하는 것 같다. 그러면서 더 중요한 것을 위로 올리고 불필요하게 글자 수만 늘린 건 없는지. 글의 목적과는 거리가 있는 문장은 없는지 등 우리가 서비스를 출시하기 위해 개발 환경에서 테스트를 하고 QA 단계를 거쳐 최종 운영환경에 릴리즈 하는것 처럼.

글쓰기는 말하고자 하는 것을 “텍스트"로 전달하는 아주 기본적이며 제한적인 수단이기 때문에 몇 번이고 읽어보면서 고칠 수 있는 부분은 최대한 고치자. 그러면서 글을 썼던 자신을 되돌아보며 무슨 생각으로 이런 글을 썼나 돌아보는 기회도 되고.

나만의 글쓰기 플랫폼을 찾자.

정말 다양한 글쓰기 플랫폼이 있다. Github, 네이버 블로그, 티스토리, 워드프레스 등 서버호스팅 비용 없이도 무료로 제공해주는 곳들인데 각 플랫폼 마다의 장단점이 있으니 자신에게 맞는 곳을 찾아서 글을 써보자. 특히 Github 블로그는 정말 다양한 방법으로 블로그를 만들 수 있고 테마 또한 무궁무진하며 웹에 대한 지식이 있다면 얼마든지 커스터마이징이 가능하다.

블로그를 만들었으면 검색에 잘 되도록 SEO 설정을 해두고 RSS를 만들어 국내 기술블로그를 모아둔 awesome-devblog에 자신의 블로그 정보에 대해 PullRequest를 날려보자. 그러면 필자가 만든 기술블로그 구독서비스에서 여러 사람들에게 매일 오전 10시에 친절하게, 그것도 무료로 홍보를 해주기 때문이다. (갑 분 서비스 홍보, 후원좀…)

GA(Google Analytics)를 붙여 어디서 유입되고 얼마나 들어오는지 보는 재미도 쏠쏠하다. 필자도 처음엔 많아야 10명(그게 전부 필자였다는건 비밀)이었지만 점점 방문자수가 늘어나니 글을 좀더 재미있고 잘 써야겠다는 사명감과 책임감도 생겨서 초창기에 썼던 글과 요즘의 글을 비교를 해보면 글의 퀄리티가 훨씬 늘어난것 같다.

마치며

우리는 사실 어렸을때부터 글쓰기를 해왔다. 어렸을적 그림일기부터 시작하여 사랑하는 사람에게 손편지를 쓰고 싸이월드에 흑역사를 만들었던 시절들. 개발자가 된, 혹은 이제 개발자가 되려는 사람들이 있다면 그냥 글이 아닌 자신이 가지고 있는 기술에 대한 글을 써보는건 어떨까. Stack Overflow Driven Development (SODD) 라는 말이 있듯이 개발은 사실 엄청난 성능과 최적의 알고리즘을 요하는게 아니라면 개발자 간의 경쟁력은 일반적인 개발실력 이외엔 시간과 경험의 차이인것 같다. 여기에 글쓰기 연습을 하며 보다 논리적이고 정리하는 습관을 기른다면 이또한 남들과는 다른 나만의 무기가 될수 있지 않을까 하는 생각을 해본다.

이 글을 읽는 독자분들 중 자신만의 기술블로그가 없다면 지금 당장이라도 시작하라고 권하고 싶다. 첫 시작은 어렵겠지만 자신만의 스타일로 “글쓰는 개발자"가 되는데 건투를 빈다.

# 참고

좋은 기술 블로그를 만들어 나가기 위한 8가지 제언

강원국의 글쓰기 : 남과 다른 글은 어떻게 쓰는가