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

_
_

들어가며: 좋은 기술 블로그란 어떤 블로그일까요

많은 사람들이 자신의 생각과 정보를 전달하기 위해서 블로그를 사용합니다. 하지만 모든 블로그가 좋은 블로그는 아닙니다. 좋은 블로그라는 표현은 복합적인 의미를 담고 있습니다. 다음 예시의 블로그들이 좋은 블로그인지 한 번 생각해보시기 바랍니다.

이런 블로그들은 분명히 좋은 특징을 하나는 가지고 있습니다. 하지만 분명히 수많은 블로그 중에 손꼽아 좋은 블로그라고 이야기하기는 어려운 면이 있습니다. 그럼에도 불구하고 어렴풋이 좋은 블로그의 단서가 보이는 듯 합니다. 좋은 특징들을 잘 분리해서 생각해본다면 좋은 블로그에 조금 더 다가설 수 있지 않을까요?

이 글에서는 기술 블로그를 중심으로 좋은 블로그를 만들어나가기 위한 8가지 제언을 정리하고자 합니다.

44BITS 소식과 클라우드 뉴스를 전해드립니다. 지금 5,000명 이상의 구독자와 함께 하고 있습니다 📮

1. 완성된 글을 작성한다

가장 중요한 이야기부터 시작해보겠습니다. 좋은 블로그의 가장 중요한 요소는 바로 좋은 컨텐츠입니다. 좋은 컨텐츠를 정의하는 요소는 매우 복합적입니다. 하지만 하나 분명한 것은 기술 블로그의 가장 중요한 역할이 정보 전달에 있다는 점입니다. 독자들에게 어떤 주제에 대해 효율적으로 전달하는 글은 일단 좋은 컨텐츠입니다.

블로그를 시작하면서 쉽게 빠지기 쉬운 함정 하나가 완성된 글을 작성하는 대신 개인 노트를 수정 없이 올리는 일입니다. 심한 경우 문장의 형태를 갖추지 않고 있거나 링크나 코드만 늘어놓기도 합니다. 개인 노트의 가장 큰 문제는 저자와 독자가 맥락을 공유하지 않는다는 점입니다. 저자는 나중에 노트를 다시 보면서 자신의 경험과 기억을 통해 노트가 작성된 맥락을 재구성할 수 있습니다. 하지만 독자는 그렇지 않습니다. 때로는 그런 조각 하나가 도움이 될 수도 있지만 좋은 컨텐츠라고 보기는 어렵습니다. 따라서 완성된 글은 좋은 컨텐츠가 갖추어야할 최소한의 요건입니다.

완성된 글은 온전한 문장들로 이루어져야합니다. 개인적인 목적으로 끼적인 내용을 직접 올리기보다는 블로그에 작성할 글의 초안으로 활용해야합니다. 좋은 컨텐츠는 이러한 초안을 바탕으로 1. 누구에게, 2. 무엇을 3. 어떻게 전달할지에 대한 고민으로 다시 작성된 글입니다. 완성된 글을 작성하는 것은 여러가지 면에서 이롭습니다. 먼저 작가 자신에게 글을 쓰는 연습이 됩니다. 두 번째로 독자가 쉽게 읽을 수 있습니다. 또한 다른 사람들에게 발견될 가능성이 높아집니다.

2. 적당한 분량의 글을 작성한다

글을 소비하는 데 있어 글의 길이는 아주 중요한 역할을 합니다. 최근에는 워드프로세서나 노트앱을 사용해 작성중인 글의 분량을 쉽게 확인할 수 있습니다. 1번에서 얘기한대로 온전한 문장으로 단락을 구성해서 글을 작성한다면 아무리 짧아도 천 자에서 이천 자 정도의 분량이 됩니다. 책과 비교를 해보겠습니다. IT 서적은 A5와 B5 사이의 판형이 주로 사용됩니다. 적절한 여백을 포함하고 있는 경우 이 정도 판형의 1페이지에 들어가는 글자수는 이미지의 유무에 따라 600 자에서 1,000 자 정도가 됩니다. 저는 편의상 주로 800자를 기준으로 사용합니다. 따라서 서적을 기준으로 1,000 자 분량의 글이면 1-2페이지, 2,000 자 정도의 분량이면 2페이지에서 3페이지에 해당하는 분량입니다. 이 정도 분량이면 읽기에 큰 부담은 없습니다.

이전에 미디엄 데이터 랩에서는 독자의 관심을 가장 많이 끄는 글은 7분 정도의 분량이라는 분석 글을 공유한 적이 있습니다. 독자로부터 어떤 행동을 가장 많이 유도하는 것이 글을 쓰는 목적은 아닙니다만, 이러한 정보를 활용해 좀 더 전략적으로 글을 써보는 것도 가능합니다. 독서 시간을 정확히 측정하는 것은 어렵지만 대략적으로 1페이지를 1분 정도로 계산하면 무난합니다.* 이 기준을 사용하면 페이지로는 7페이지, 글자수로는 5,600자 정도 길이가 이상적입니다. 약간 길게 느껴질 수도 있습니다만, 주제에 관심이 있다면 충분히 끝까지 읽어볼만한 분량입니다.

* 미디엄에서는 영어 1,000 자당 1분, 한글 500자당 1분 정도로 계산이 됩니다. 글을 읽는 시간을 계산할 때 언어의 차이를 반영하는 것도 쉬운 일은 아닙니다. 어떤 기준을 사용할지는 스스로 고민해볼 필요가 있습니다.

더 긴 글을 작성하는 것도 좋은 전략입니다. 어떤 도구에 대한 튜토리얼을 작성해보면 보통 15,000 자에서 25,000 자 정도 분량이 나옵니다. 이런 글은 쓰는 데도 긴 시간이 걸리고 독자 입장에서도 그 자리에서 다 읽기 부담스러운 분량입니다. 온라인에서 이 정도 길이의 글을 완독하려면 마음을 단단히 먹고 읽어야합니다. 하지만 충분히 가치있는 일입니다. 너무 길어보인다고 걱정할 필요는 없습니다. 그래봤자 책으로 보면 한 챕터 분량에 지나지 않습니다. 그리고 잘 쓰여진 긴 글은 SEO 관점에서도 나쁠 게 없습니다. 하지만 하나의 글이 30,000자를 넘어간다면 글을 나눠서 작성하는 것을 추천합니다.*

* 짧은 글을 나눠쓰지 마세요. 글을 나누는 것은 아주 어려운 결정입니다. 대부분의 블로그 도구는 시리즈로 작성된 글을 잘 처리하지 못 합니다. 따라서 저자는 글마다 시리즈의 글들을 링크해야합니다. 저자가 링크를 빼먹기라도 하면 독자 입장에서는 나눠진 글을 직접 찾아다녀야합니다. 하나의 일관된 주제를 다루는 글을 나누는 것은 글이 정말로 길 때만 고민하는 것이 좋습니다. SEO 관점에서도 1,000 자 짜리 글 세 개보다 3,000자 짜리 글 하나가 훨씬 더 유리합니다.

베어(Bear)에서 확인한 이 글의 분량에 관한 정보
베어(Bear)에서 확인한 이 글의 분량에 관한 정보

일반적으로 4,000 자에서 10,000 자 정도가 독자가 흥미를 가지고 읽기에도 좋고, SEO 관점에서도 이상적인 분량입니다. 하지만 모든 면에서 완벽한 분량이라는 것은 없습니다. 글에 따라서 적절한 분량에 대해서 저자 스스로 계속해서 고민해볼 필요가 있습니다.

3. 글의 형식을 정한다

글을 작성하기에 앞서서 꼭 해야할 일이 하나 있습니다. 바로 어떤 형식으로 글을 작성할 지 정하는 일입니다. 예를 들어 시, 소설, 수필 사이에는 명백한 차이가 있습니다. 간과되곤 합니다만 기술 블로그를 작성할 때도 전형적인 몇 가지 형식이 있습니다.

Daniele Procida 씨의 아무도 알려주지 않는 문서화의 비밀에서는 소프트웨어 문서화 형식을 튜토리얼(tutorial), 하우투 가이드(how-to guide), 해설(explanation), 레퍼런스(reference) 4가지로 분류합니다. 레퍼런스를 제외하면 블로그에서 작성하는 글도 대부분 앞의 세 가지 형식에 속하게 됩니다. 여기에 뉴스 기사와 에세이 정도를 더하면 기술 블로그의 거의 모든 글을 분류할 수 있을 것입니다(기술 블로그를 시로 쓰시는 분은 아마 없을 테니까요).

Daniele Procida가 분류한 소프트웨어 문서화의 4가지 형식. 아무도 알려주지 않는 문서화의 비밀에서 인용.
Daniele Procida가 분류한 소프트웨어 문서화의 4가지 형식. 아무도 알려주지 않는 문서화의 비밀에서 인용.

따라서 글을 작성할 때 튜토리얼, 하우투 가이드, 해설, (시의성이 중요한) 뉴스 기사, (자신의 생각을 전달하는) 에세이 중 어느 형식에 속하는 글을 작성할 지 먼저 정하는 것이 좋습니다. 형식을 결정하면 글을 작성하는 방향이 좀 더 선명하게 그려집니다.

몇 가지 예를 들어보겠습니다. 튜토리얼을 작성할 때는 동작하는 예제를 작성하는 것이 아주 중요합니다. 어떤 환경에서 작성되었는지에 대한 정보가 전달되어야하고 직접 명령어를 실행해가며 동작 가능한 것을 확인해야합니다. 머리 속에 있는 지식을 단순히 재구성 해서는 절대로 좋은 튜토리얼을 작성할 수 없습니다. 해설 기사는 또 다릅니다. 해설 기사는 본문의 내용이 실제로 동작하는지를 보여주는 것보다 어떤 원리로 동작하는지를 설명하는 게 중요합니다. 에세이에는 특별한 제약이 없으므로 개인적인 생각을 전달하는 데 많이 사용됩니다. 한 분야의 구루들은 정보 전달보다는 자신의 생각을 전달하기 위한 에세이만을 작성하기도 합니다. 하지만 에세이는 가장 어려운 형식입니다. 어설프게 에세이 형식을 모방하면서 정보 전달을 위한 글을 쓰고 있지는 않은지 생각해볼 필요가 있습니다.

하나의 글을 쓰는 동안 여러가지 형식들을 혼용하기보다는, 하나의 형식을 정하고 그 형식에 맞게 글을 풀어내는 게 좋습니다. 이러한 글쓰기 과정을 통해서 자신에게 가장 적합한 형식을 찾을 수도 있고, 블로그의 색깔이 선명하게 드러나기도 합니다.

4. 컨텐츠 관리가 가능한 블로그 도구를 선택한다

지금 블로그가 없고 새로 시작해보고 싶으신 분에게는 워드프레스닷컴Wordpress이나 미디엄Medium을 추천합니다. 월 만 원 정도의 돈을 쓸 의향이 있다면 율리시스Ulysses와 워드프레스닷컴의 퍼스널 플랜을 추천 드립니다. *

* 이 글에서는 워드프레스나 율리시스에 대해서 자세히 다루지 않습니다. 율리시스는 맥OS만을 지원한다는 한계가 있지만 글쓰기 도구로서는 으뜸입니다. 특히 워드프레스, 미디엄 발행 기능이 있어서 작성한 글을 율리시스 위에서 바로 퍼블리싱하는 게 가능합니다. 워드프레스 퍼스널 플랜을 추천하는 이유는 커스텀 도메인을 지원하기 때문입니다.

블로그 도구를 선택할 때 가장 중요한 건 컨텐츠 관리가 가능한지 여부입니다. 이러한 도구를 전통적으로는 CMSContents Management System라고 부릅니다. 블로그는 다양한 제약이 가해진 특수한 목적의 CMS 도구라고 생각할 수 있습니다. 워드프레스는 CMS의 전통을 이어가고 있는 블로그 도구입니다. 다양한 비판을 받아왔지만 여전히 워드프레스를 대체할만한 도구는 찾기 어렵습니다. 미디엄은 좀 더 현대화 되어있지만 컨텐츠 관리 기능은 빈약한 편입니다.

컨텐츠 관리 면에서 정적 웹사이트 생성기는 좋은 선택지가 아니라고 생각합니다. 특히 프로그래머가 아니라면 절대로 선택하지 마시기 바랍니다. 프로그래머라도 가능하면 선택하지 마시기 바랍니다. 그럼에도 불구하고 정적 웹사이트 생성기를 사용하고자 한다면, 컨텐츠 관리를 어떻게 해나갈 지에 대한 전략부터 세우는 것이 좋습니다. 장기적으로 블로그를 운영하려면 어떤 도구를 선택하건 컨텐츠 관리 기능이 최우선적으로 고려되어야합니다.

5. 보존, 보존, 그리고 보존

마이크로소프트웨어는 한 번 폐간했다가 다시 복간되었습니다. 마이크로소프트웨어는 IT 잡지이기도 했지만 자체적인 취재를 하는 온라인 미디어이기도 했습니다. 폐간 소식이 알려졌을 때 웹사이트가 사라지지 않을까 걱정을 했던 기억이 있습니다. 폐간 당일, 웹사이트는 사라졌고 구글 사이트 도구로 만들어진 임시 페이지로 자동 리다이렉트되었습니다. 한국어로 작성되어있는 IT 정보들이 한순간에 사라져버렸습니다. 하물며 개인 블로그들은 더 쉽게 사라집니다. 예전에 북마크해둔 좋은 글을 다시 찾기란 여간해서 쉬운 일이 아닙니다.

보존에 드는 비용을 최소화하면 그 블로그가 살아남을 가능성이 높아집니다. 체감상 설치형 블로그의 10년 생존률은 극단적으로 낮습니다. 그래서 설치형보다는 서비스형 블로그를 무료 플랜으로 사용하는 걸 추천합니다. 워드프레스닷컴 정도면 2030년에도 살아남아 있을 것 같습니다. 원칙은 간단합니다. 최소한의 노력으로 최대한 보존해야합니다. 보존에 대한 고민을 아예 하지 않는다면 어느 시점에서는 저자 본인도 자신의 글을 찾을 수 없게 됩니다.*

* 정적 웹사이트 생성기는 보존 관점에서 아주 훌륭합니다. 하지만 위에서 이야기했듯이 컨텐츠 관리에 대한 명확한 전략이 없다면, 보존 때문에 정적 웹사이트 생성기를 선택하는 것은 추천하지 않습니다. 컨텐츠 관리와 보존은 트레이드 오프에 있는 것처럼 보이지만 이 둘을 양립시키는 방향으로 나아가는 것이 중요합니다. CMS 도구를 정적으로 배포하거나, 정적 웹사이트 생성기를 헤드리스 CMS와 함께 사용하는 방법도 있습니다.

한 번 사이트가 폐쇄되면 신뢰, 구독자, 페이지랭크를 모두 처음부터 쌓아나가야 한다는 걸 기억해야합니다. 많은 사람들이 반복하는 실수입니다. 보존은 블로그 운영의 주춧돌과 같습니다. 자신의 컨텐츠가 얼마나 오래 보존되기를 원하는지 스스로 고민해보아야합니다. 그 기간이 1년 정도라고 생각한다면 특별히 할 일은 없습니다. 하지만 10년 이상이라고 생각한다면, 그에 걸맞는 도구와 계획을 세워야합니다. 한 번 떠올려보시기 바랍니다. 블로그 중에 10년 이상 꾸준히 운영되는 기술 블로그가 몇 개나 되나요? 제가 알고 있는 10년 이상꾸준히를 모두 만족하는 한국어 기술 블로그는 손에 꼽을 정도입니다. 이보다 더 중요한 비결은 없습니다. 장기간에 걸쳐 꾸준히 좋은 컨텐츠를 생산하기만 하면 그것만으로도 좋은 블로그가 될 수 있습니다.

6. 수익을 얻는다 🤑

글을 쓰는 것은 어렵습니다. 글을 잘 쓰는 것은 더욱 어렵습니다. 하지만 글을 써서 먹고 사는 것은 절망적으로 어렵습니다. 돈을 버는 것에 비하면 글을 잘 쓰는 게 상대적으로 훨씬 쉬울지도 모릅니다. 블로그를 운영하는 다양한 동기가 있겠지만, 장기적으로 내적 동기를 유지하는 데 있어서 돈보다 좋은 것은 없습니다. 블로그를 통해 운영비를 마련하는 것부터 시작해보시기 바랍니다.

대표적인 수단으로는 구글의 애드센스가 있습니다. 애드센스의 광고단가는 지속적으로 떨어지고 있는 추세라고 합니다. 현재 애드센스를 사용하고 있지 않아서 정확한 수치는 모릅니다만, 1만 PV에 월 10달러 이하로 추정 됩니다.

광고 이외에도 돈을 벌수 있는 방법들이 있습니다. 좋은 컨텐츠를 생산한다는 걸 인정 받는다면 독자들에게 후원을 받을 수도 있습니다. 컨테이너 오케스트레이션 도구 쿠버네티스Kubernetes 글을 연재하고 계신 asbubam 님은 페트리온Patreon을 통해 독자들에게 정기적으로 후원을 받고 있습니다. 외국에서는 아마존 어필리에이트 프로그램도 많이 이용됩니다. 최근에는 쿠팡 파트너스라는 어필리에이트 프로그램도 시작되었습니다. 어필리에이트는 블로그에서 특정 상품에 대한 링크를 연결하고, 이 링크를 통해서 방문자가 물건을 구입하면 구입 금액의 일정 비율을 블로그 작성자에게 나눠주는 프로그램입니다.

현실적으로 블로그를 해서 생활에 도움이 될만큼 돈을 버는 것은 쉽지 않습니다. 하지만 기회가 아주 없는 것은 아닙니다. 블로그로 돈을 버는 일은 어쩌면 이제 걸음마 단계에 와있을지도 모릅니다. 이 주제에 좀 더 관심이 있으시다면 stdout_010.log: 블로그로 벌어 먹고 살 수 있나요? 편을 들어주세요. 😉

7. 글을 홍보하기 위한 채널을 만든다

블로그가 한 번 휩쓸고 간 자리에는 이제 페이스북과 트위터 같은 SNS 플랫폼들이 남아있습니다. 아직도 RSS 리더기를 사용하는 사람들은 구시대의 영광을 버리지 못한 컨텐츠 중독자들 정도입니다. 올블로그와 같은 메타 블로그도 없고 어디 가서 내 글을 좋은 글이라고 홍보할 만한 장소도 마땅치 않습니다.

사람들은 이제 RSS를 구독하는 대신 트위터 계정이나 페이스북 페이지를 팔로우합니다. 개인 계정이 있다면 이 계정을 통해서 새로운 글을 알리세요. SNS 계정이 없거나 좀 더 본격적으로 블로그를 운영하고 싶다면 블로그 전용 계정을 만드시기 바랍니다. 매번 글에 대한 소개를 간략하게 작성하면 베스트지만, IFTTT를 연동하는 것만으로도 충분합니다.

최근에는 이메일 뉴스레터도 자주 목격됩니다. 좋은 뉴스레터를 만드는 것은 어려운 일입니다. 꾸준히 컨텐츠를 생산할 계획이 있고, 이 컨텐츠들을 다시 한 번 포장해볼 의지가 있다면 뉴스레터를 병행하는 것도 좋은 전략입니다.

이도 저도 다 귀찮고 광고를 달 생각도 없다면 미디엄이나 브런치를 사용하는 것을 추천합니다. 미디엄이나 브런치는 플랫폼 안에서 구독 기능을 지원합니다. 글을 쓰는 데만 집중하면서 자연스럽게 구독자를 늘려나갈 수 있습니다. 플랫폼 내의 추천 기능을 통해 새로운 유입을 만들어내는 데도 유리합니다. 또한 이 플랫폼들은 기본적으로 검색 엔진 최적화가 잘 되어있는 편입니다.

8. 검색 엔진 최적화(SEO)를 한다

블로그의 주요한 유입 경로는 3가지 정도가 있습니다. SNS 구독, 다른 글의 링크, 그리고 검색엔진입니다. SNS 구독의 경우 새로운 글을 작성할 때 유입을 크게 늘리는 효과가 있습니다. 하지만 일반적으로 그 효과는 하루 이틀 정도입니다. 두 번째 유입경로는 블로거가 직접 컨트롤할 수 없는 영역입니다. 장기적으로 좋은 글을 쓰고 신뢰를 쌓아나가면 블로그를 향한 링크도 늘어날 것입니다. 가장 중요하다고 여기는 유입경로는 바로 검색엔진입니다. 까놓고 얘기하죠. 여기서 검색엔진은 바로 구글입니다.

구글에서 블로그를 검색되도록 하기 위해서는 컨텐츠 SEO 작업을 해야합니다. 어려운 건 없습니다. 저는 컨텐츠 SEO는 메타데이터에서 시작해서 컨텐츠로 끝난다고 믿습니다. 시작은 메타데이터입니다. 메타데이터에서 왕중의 왕은 title 태그입니다. 먼저 접근 가능한 모든 페이지에 적절한 제목이 붙어있는지 확인하시기 바랍니다. 여기까지 했다면 절반은 마쳤습니다. 나머지 절반은 구글, 트위터, 페이스북에서 지원하는 메타데이터 태그를 작성하는 일입니다. 블로그에서는 일반적으로 자동 요약기능을 제공합니다만, 조금 여유가 된다면 description 태그 안의 내용을 직접 작성해보시기 바랍니다.

이제 남은 일은 컨텐츠를 작성하는 일입니다. 구글은 특정 검색 키워드에 대해서 가장 적절한 글을 가장 앞에 보여줍니다. 개별 컨텐츠에 대한 이야기는 1번, 2번, 3번에서 다뤘습니다. 짧은 조각글을 10개씩 글을 올리는 대신 1. 완성된 2. 적당한 분량의 3. 형식을 갖춘 글을 갖춘 글을 작성해보시기 바랍니다. 만 자 정도 분량의 잘 정리된 글은 SEO 면에서는 가장 유리합니다. 단, 주제의 범위는 적절해야합니다. 예를 들어 파이썬Python이나 자바Java 같은 키워드로는 검색 결과 상위에 올라가는 것이 아주 어렵습니다. 좀 더 범위를 좁혀서 글을 작성한다면 해당 키워드로 검색했을 때 아주 높은 확률로 검색 결과 1페이지에 노출될 수 있습니다. 좋은 글은 적절한 글일 가능성이 높습니다. 구글의 분석기는 좋은 글을 알아볼만큼 똑똑합니다.* 검색 유입이 발생하기까지는 시간이 걸리지만, 검색 유입은 아주 장기간 유지되는 경향이 있습니다.

* 제가 이렇게 확신하는 데는 또 다른 이유가 있습니다. 아직까지는 온라인 상에 한국어로 작성된 “완성된 글”이 많지 않습니다. 단기적으로는 좋은 글은 아니지만 완성된 글을 쓰는 것만으로도 높은 평가를 받을 수 있습니다.

실제로는 조금 더 복잡합니다. 다른 사이트의 링크나 사 이트의 신뢰도 또한 중요한 역할을 합니다. 위키백과나 나무위키 같은 사이트가 시도때도 없이 검색 결과 상위에 나오는 것은 분명 해당 검색 키워드에 대한 최상의 컨텐츠이기 때문은 아닙니다. 이 사이트들이 가진 신뢰성이나 연결 관계가 그만큼 높게 평가되기 때문입니다. 4번, 5번, 7번에서 다룬 이야기는 사이트 평가에 직간접적으로 연결되는 주제입니다. 사이트에 대한 평가가 좋아지는 만큼 검색에 반영되는 속도도 점점 빨라집니다.

마치며

좋은 블로그를 만들기 위해서 생각해야만 하는 것들이 분명 많이 있습니다. 이 글의 제언들도 결코 정답은 아닙니다. 결국 어떤 블로거가 추구하는 좋은 블로그라는 답은 블로거 자신이 찾아가야하는 일입니다. 하지만 그 모험은 흥미로운 일입니다. 아직 블로그를 시작하지 않았다면, 너무 많은 고민을 하지는 않기를 바랍니다.

블로그가 필요하다는 말에 이제는 공감하는가? 그렇다면 다행이다. 여기까지 공감했다면 시작하는 방법도 궁금할 것이다. 시작은 무척 쉽다. 워드프레스 호스팅이나 블로거 같은 무료 서비스를 활용하면 5분 내에 블로그를 만들 수 있다.

— 21장 블로그 성공적으로 운영하기, 소프트 스킬, 존 손메즈

올 한 해도 좋은 블로그들을 더 많이 만날 수 있기를 기대해봅니다.

같이 읽으면 좋은 글들

이 글에서는 글을 쓰는 구체적인 과정에 대해서는 다루지 않았습니다. 뛰어난 블로거 분들은 자신만의 시스템을 만들어 꾸준히 글을 작성해 나갑니다. 다음 글들을 추천합니다.

좋은 글을 쓰고 좋은 블로그를 만들어나가기에 앞서 왜 기술 블로그를 운영해야하는 지 궁금할 수도 있습니다. 그런 분들께는 아래 글들을 추천합니다.

44BITS 로고

기술 블로그(Engineering Blog)란?

🏷️ 키워드, 2020-01-27 - 기술 블로그는 주로 IT 기업이 운영하는 프로그래밍, 인프라스트럭처, 프로덕션 운영 등을 다루는 블로그를 지칭합니다. 기술 블로그의 의미와 운영에 대해 살펴보고, 기술 블로그를 운영하기에 적합한 블로그 도구와 서비스들을 소개합니다.
도움이 되셨나요?
RSS 리더 피들리에서 최신 글을 구독할 수 있습니다.
트위터, 페이스북으로 44BITS의 새소식을 전해드립니다.
✔ 44BITS의 다른 활동도 확인해보세요. 다양한 채널에서 만나볼 수 있습니다.
✔ 따뜻한 댓글 하나와 피드백은 큰 힘이 됩니다.

scratch 도커 이미지를 활용한 초경량 이미지 만들기

🗒 기사, 2018-12-10 - C 프로그램을 작성하고 이를 동적 링크 컴파일한 경우와 정적 링크 컴파일한 경우로 나눠서 chroot로 실행해봅니다. 그리고 도커(Docker)의 scratch 이미지를 기반으로 같은 방식을 적용하는 법을 소개합니다.

깃허브(GitHub) 웹훅을 활용해 슬랙(Slack)에 이벤트 전달하기

🗒 기사, 2014-01-30 - 웹훅 기능을 사용하면 깃허브(GitHub)에서 특정 이벤트가 발생했을 때 다른 서버를 호출하는 것이 가능합니다. 이 글에서는 웹훅 호출을 처리하기 위한 간단한 서버를 구현하고, 슬랙에 깃허브 이벤트를 알리는 기능을 구현해봅니다.

tfenv로 테라폼(Terraform) 버전 관리하기

🗒 기사, 2019-09-30 - 테라폼을 여러 프로젝트에서 사용하면 다수의 버전이 필요한 경우가 생깁니다. 이럴 때 tfenv를 사용하면 손쉽게 테라폼 버전을 변경해서 사용할 수 있습니다. 이글에서는 tfenv를 사용해 테라폼의 버전을 관리하는 방법을 소개합니다.