코빗 기술 블로그는 어떻게 만들어졌나
들어가며
코빗은 지난 몇 년간 기술적으로 많은 진전을 이루었습니다. 하루 24시간 쉬지 않고 돌아가는 가상자산 거래소의 특성상, 시스템을 멈추지 않으면서 거대한 레거시를 걷어내고 차세대 거래 시스템을 새로 구축하는 일은 결코 쉽지 않았습니다. 계정 시스템, 입출금이나 블록체인, 인프라 등과 관련해서도 안정성과 성능을 크게 개선했고요.
그런데 CTO로서 늘 아쉬운 게 하나 있었습니다. 바로 동료들이 만들어낸 성취와 고민의 흔적을 회사 밖에도 알리고 싶다는 것이었는데요.
테크 브랜딩(Tech-Branding)이나 채용을 위해서도 회사가 어떤 기술을 쓰고 어떤 문제를 어떻게 해결하는지 보여주는 것은 중요합니다. 그래서 기술 블로그는 예전부터 꼭 만들고 싶었는데, 늘 그렇듯 바쁜 일정에 밀리다 2025년 9월이 되어서야 비로소 첫 글을 올리게 되었습니다.
하나 특기할 만한 점은 이 블로그는 CTO인 제가 기획부터 디자인, 개발, 배포까지 직접 만들었다는 것입니다.
오늘은 왜 제가 기술 블로그를 모두 직접 만들었는지, 그리고 어떻게 만들었는지 이야기해보려 합니다.
왜 굳이 직접 만들었나
"CTO가 왜 직접 블로그를 개발했지?" 싶으실 수 있습니다. 쉽게 Medium 같은 서비스를 써도 됐겠죠. 하지만 회사 기술 블로그는 그저 글을 모아 놓는 공간이 아니라, 기술을 대하는 태도나 추구하는 품질을 보여주는 창이 될 수 있다고 생각했습니다. 그래서 단순한 형태더라도 디자인부터 작은 요소 하나까지 신경 쓴 웹페이지를 만들고 싶었습니다. 개발도 어렵지 않아 보여 제가 직접 빠르게 만드는 게 가장 효율적이겠다 싶었습니다.
선택지도 여럿 있었습니다.
제가 Go와 Vue를 좋아하다보니 Hugo와 VitePress가 먼저 떠올랐습니다. 또, Astro도 이런 용도에 딱 맞는 도구입니다.
그런데 결국 Node.js로 직접 정적 사이트 생성기를 만들기로 했습니다. 이유는 네 가지였습니다.
- 우선, 단순하게 "마크다운 파일을 넣으면, HTML이 나오는 것" 만 필요했습니다.
- 회사 블로그인 만큼 작성자별 프로필 같은 기능도 필요했고, 기존 테마를 수정하거나 새로운 문법을 익히는 데 시간을 쓰고 싶지도 않았습니다.
- 개발자로서의 호기심도 있었습니다. "이거 그냥 AI 시켜서 만들면 되겠는데?"
- 이미 있던 정적 페이지 배포 파이프라인(GitHub, Jenkins, Node.js, S3)을 그대로 쓰려고 했습니다.
아키텍처와 기술 스택
직접 만든다고 해서 당연히 모든 코드를 밑바닥부터 만든 것은 아닙니다. 코빗 기술 블로그의 기술 스택은 다음과 같습니다.
- 웹페이지 빌드: Vite
- 마크다운 변환: markdown-it
- CSS: Tailwind CSS
- 코드 하이라이터: Shiki
- 이미지 처리: sharp
파일 기반 블로그
CMS나 DB 없이, 모든 데이터는 JSON 파일과 Markdown 파일로만 관리됩니다. 텍스트 에디터만으로 모든 내용을 편집하고 Git으로 버전 관리까지 이어지는 구조를 만들고자 했습니다.
authors.json: 작성자의 정보(이름, 사진, 직함, 소셜 링크, 인사말 등)를 정의posts.json: 게시물의 메타데이터(제목, 작성자 ID, 날짜, 태그, 출력 순서 등)를 관리
빌드 스크립트는 이 JSON 파일들을 순회하며 마크다운 파일을 읽고 렌더링합니다. 즉, 글을 발행하는 과정은 단순합니다. 마크다운을 쓰고, posts.json에 한 줄을 추가하면 끝입니다. Git 히스토리가 곧 기록이 되고요.
주요 기능 구현
직접 만든 만큼, 잘 알려진 블로그 도구들과 비교해도 크게 부족함이 없도록 신경을 썼습니다.
코드 하이라이팅
기술 블로그에서는 코드 블록이 얼마나 읽기 좋게 보이느냐도 중요합니다. 브라우저에서 자바스크립트로 코드를 하이라이트하면 로딩도 필요하고 순간적으로 깜빡임도 생길 수 있습니다. 그래서 빌드 타임에 Shiki를 사용해서 미리 코드 하이라이팅을 적용한 HTML을 생성하도록 했습니다. 브라우저는 자바스크립트 없이도 바로 예쁜 코드 블록을 바로 보여줍니다.
package main
import "fmt"
func main() {
fmt.Println("Hello, World!")
}SEO 대응
글을 잘 쓰는 것만큼이나 잘 검색되게 만드는 것도 중요합니다. 그래서 SEO 요소의 생성도 자동화했습니다.
- 메타 태그와 구조화된 데이터: Meta 태그, Open Graph 태그 및 schema.org 구조화 데이터를
JSON-LD형식으로 삽입합니다. - 오픈 그래프 이미지:
node-canvas로 빌드 시점에 글 제목과 배경 패턴을 합성해 소셜 공유용 썸네일(og:image)을 생성합니다. - RSS/Atom 피드: 구독자를 위한
feed.xml를 갱신합니다.
이미지 최적화
모든 이미지는 sharp를 사용해서 자동으로 WebP로 변환하고 크기도 줄입니다.
가독성을 위한 디자인
화려한 인터랙션보다 글 읽기에 편안한 화면을 만드는 데 집중했습니다.
- 폰트: 널리 쓰이는 프리텐다드를 기본 폰트로 선택
- 글자 크기: 17px (여러 값을 놓고 비교해 보았는데, 흔히 16px를 쓰지만 프리텐다드로 한글을 블로그 같은 페이지에서 보여줄 때에는 17px가 가독성이 더 좋아 보였습니다.)
- 문단 너비: 688px (가독성을 고려해 데스크톱 기준으로 한 줄당 약 50~60자가 나오도록 문단 너비를 688px로 설정했습니다.
ch단위는0글리프를 사용하기에 이런 목적으로는 쓸 수 없고, 결국 기술 블로그에 어울리는 Lorem Ipsum을 만들어 적당히 값을 맞췄습니다.) - No-JavaScript: 단순히 글을 읽는 경험에 자바스크립트는 불필요하다고 생각했습니다.
- Lighthouse 100점: 덕분에 Lighthouse에서 모든 항목 100점을 달성했습니다. (클릭하는 순간 화면이 뜨는 쾌적함이야말로 웹의 기본이니까요.)
생성형 AI와 함께한 개발
혼자 개발했다지만 사실 든든한 파트너가 있었습니다. 바로 생성형 AI입니다.
예전 같으면 귀찮아서 그냥 있는 도구 갖다 쓰자고 했을 일들이 AI 덕분에 금방 해결되었습니다.
"마크다운을 HTML으로 바꾸고 블로그 템플릿에 합쳐줘!"
"이미지 파일 있으면 WebP로 모두 변환해."
원하는 기능을 말하면, AI가 그걸 구현해 주는 식이었습니다. '바퀴를 다시 발명하지 말라'는 말도, 생성형 AI 시대에는 '바퀴가 작고 단순하다면, AI와 함께 빨리 깎아 만드는 게 더 나을 수 있다'로 바뀌지 않을까하는 생각이 들었습니다.
기술 공유 문화를 위한 작은 당근
이제 플랫폼은 준비되었습니다. 하지만 결국 중요한 것은 콘텐츠입니다.
개발자에게 글쓰기는 코딩만큼, 어쩌면 그보다 더 어려운 일입니다. 바쁜 와중에 시간을 내서 블로그 글까지 쓴다는 것은 적지 않은 노력이 필요하겠죠.
그래서 코빗은 기술 블로그에 글을 쓰는 것을 장려하기 위해 작은 보상을 마련했습니다. 기술 블로그에 글을 게시하는 직원에게 '자유롭게 양도 가능한 1일 휴가권'을 지급합니다.
단순하게 글을 쓰면 보상을 주겠다는 의미가 아니라, 자신의 경험을 글로 정리해 회사 블로그를 통해 공유하는 것도 업무의 일부로 보겠다는 뜻입니다.
마치며
솔직히 이 글을 쓰면서도 "아, 그냥 Astro 쓸 걸 그랬나?" 싶을 때가 없지는 않았습니다.
그래도 직접 마크다운을 다루고 렌더링 파이프라인을 구축하며 기본에 충실한 웹페이지를 만들어 본 것은 CTO인 저에게도 재미있고 유익한 경험이었습니다. 생성형 AI 덕분에 큰 리소스 들이지 않고도 원하던 것을 직접 만들었다는 만족감도 크고요.
코빗 기술 블로그는 화려함보다는 기술 블로그라는 콘텐츠의 본질에 집중한 단순한 웹사이트입니다. 가독성과 작은 디테일에 대한 고민이 읽는 분들께 전해지기를 바랍니다. 앞으로도 이 공간을 통해 코빗이 만들어갈 기술적 도전과 성취를 꾸준히 나누겠습니다.
감사합니다.