Blog Migration to Zola

Sep 26, 2025

블로그 환경을 변경한 것을 계기로 글쓰기에 대한 단상 과 Jekyll to Zola 전환기 에 대해 작성해 보았다.

글쓰기에 대한 단상

공부를 통해 새로운 사실에 대해 알게 되었을 때, 자기 스스로 그것에 대해 제대로 이해하였는지 확인하기 위해서, 또 그러한 이해와 지식을 오랫동안 유지하기 위해서 가장 좋은 방법으로 흔히들 글쓰기를 꼽는다.

그럼에도 공부나 프로젝트를 한 후에 회고하고 기록하는 것은 여간 귀찮은 일이 아니다.

블로그 환경을 Jekyll 에서 Zola 로 변경한지도 벌써 4개월이나 지났지만, 기존에 작성했던 글을 거의 옮기지 않았고 새로이 쓰는 글도 상당히 줄었다.

우선은 글쓰기가 왜 귀찮은지에 대해 원인부터 파악한 뒤, 그럼에도 불구하고 글을 꾸준히 자주 써야한다는 사실을 성찰하고자 이 글을 쓴다.

나의 경우 왜 글쓰기가 어려웠는지 생각나는대로 휘갈겨 쓰기 시작해서 정리해보니 대표적인 원인으로 아래 3가지가 있었다.

새로운 기술에 대한 피로감
디테일의 정도
게으른 완벽주의자

새로운 기술에 대한 피로감

내가 관심있는 분야는 블록체인 분야이고, 그에 따라 글을 쓰는 주제도 자연스레 블록체인에 대해 쓰게 되는 경우가 많았다.

블록체인 분야에서는 새로 출시되는 프로덕트나 기술, 그에 동반하는 마케팅에 의해 시장을 주도하는 내러티브가 순식간에 확확 바뀌곤 한다.

내러티브에서 핵심적으로 다루어지는 개념을 용어로 단순히 나열해도 DeFi, NFT, Metaverse, Layer 1/2, Bridge, AA¹, STO², RWA³, DAT⁴, Stable Coin 등 기존에 있던 개념이든, 새로이 대두된 개념이든간에 주제가 빠르게 바뀌어가며 논의되고 있다.

그러한 개념을 구현한 기술이나 담론을 쫓으려고 해당 기술을 구현한 대표적인 프로덕트의 개발 문서를 읽다보면 거듭 내가 모르는 새로운 사실에 압도되곤 한다.

문서를 읽어내려가며 거듭 모르는 사실이 등장하는 경험이 반복되면 결국 기술 부채로 느껴지고 상당한 피로감을 느낀다.

사실, 자세한 기술적 사항을 알기 위해 새로운 프로덕트의 문서를 꼼꼼히 완독할 필요는 없지만, '문서나 리서치 아티클을 대략적으로라도 읽는 속도' 보다 '새로운 기술과 담론이 대두되고 내러티브가 전환되는 속도' 가 더 빠르다고 느껴진다.

물론 성실하면서도 핵심적인 부분만 잘 골라 읽어나가는 능력을 갖추면 문제될 것이 없겠지만, 체감온도라는 개념이 있듯이 새로운 기술의 등장 속도에 따른 체감상의 피로감이 존재한다.

가령, AI에 대해서 잘 모르긴하지만, ChatGPT의 새로운 버전이 출시되어 개선되는 것만 봐도 그렇다.

사용자 입장에서는 ChatGPT의 어떠한 기술적 사항이 변경되어서 개선된건지 그렇게 깊게 알지 않아도 되지만, AI를 공부하거나 관련 Researcher들은 발빠르게 새로이 적용된 기술적 사항을 관련 논문을 읽거나 하는 식으로 숙지해야할 것이다.

ChatGPT가 근래 하루가 다르게 새로운 버전이 출시되어 개선되고 있다는 것을 생각하면 관련 Researcher들의 부담감도 상당할 것이라 십분 이해할 수 있을 것이다.

게다가, 굳이 내가 새로운 내용에 대해 글을 쓰지 않더라도 고퀄리티의 리서치 아티클이나 어려운 기술적 내용이 쉽게 이해하도록 잘 쓰여진 글도 많다.

또, 새로운 기술에 대한 담론은 일정한 기간이 지나면 사장되거나 또 다시 다른 새로운 기술에 대한 담론으로 전환되어 금방 진부한 것이나 현실적이지 못한 것으로 취급된다. 결국 이러한 현상으로 인해, 좋아하는 분야를 공부하면서 알게된 새로운 사실을 글로 작성하고 싶은 마음과 어차피 유행과 내러티브는 금방 전환될건데 자세한 사항까지 공부해서 쓸 필요가 있나 싶은 마음이 상충하게 된다.

디테일의 정도

그 어느때보다 고퀄리티의 컨텐츠들이 쏟아지고 있고, 이제는 인간이 아니라 AI 마저 컨텐츠를 생산하고 있다.

유튜브는 주로 개인이 촬영하고 편집하여 컨텐츠를 제공하던 플랫폼이었는데 어느새 연예인과 전문적인 방송 스태프들이 영상 컨텐츠를 제공하고 있다.

연예인이나 전문적인 방송 스태프들은 영상을 제작할 때에 적재적소에 어느 정도로 디테일을 부여해야하는지 잘 아는 전문가들이기에 좋은 품질의 영상 컨텐츠를 생산한다.

글도 마찬가지로 글에서 다루는 주제와 글의 목적에 맞게 얼마나 적절한 정도로 디테일한 사항을 다루고 있는지에 따라 그 글의 퀄리티가 결정된다.

악마는 디테일에 있다. (Devils is in the details.)

유명한 어구다. 문제점이나 불가사의한 요소가 세부사항 속에 숨어있다는 의미의 속담이며 어떤 것이 대충 보면 쉬워 보이지만 제대로 해내려면 예상했던 것보다 더 많은 시간과 노력을 쏟아부어야 한다는 것을 의미한다.

특히, 기술에 대해 논하다보면 자연스레 구체적인 설명을 하지 않고 넘어가는 용어들이 있다. 가령, 노드, 라이브러리, 프레임워크 와 같은 기술 용어들은 목표로 하는 독자가 개발자 라면 해당 용어에 대해서는 굳이 설명을 하지 않고 넘어간다.

이를 지식의 저주(curse of knowledge) 라고 표현하는데, 전문 지식을 가진 사람이 다른 사람들도 그 지식을 공유한다고 가정할 때 발생하는 인지 편향을 뜻한다. 위의 노드, 라이브러리, 프레임워크 같은 예는 개발 용어 중에서도 간단한 예이지만, 기술적인 내용을 쓰다보면 추가적인 설명이 필요해보이는 개념이나 용어가 빈번하게 등장한다. 기술 문서에서 glossary 나 terminology 페이지가 별도로 존재하는 경우가 많은 이유다.

즉, 추가적인 설명이 필요해보이는 개념이나 용어가 등장할 때마다, 설명을 실제로 할 것인지 말 것인지 고민하고 판단해야하는 공수는 기본으로 발생하고, 실제로 설명이 필요하면 따로 단락이나 절을 편성하여 작성해야하는 공수가 추가적으로 발생한다. 다시 말하자면, 좋은 글을 쓰려면 얼마나 디테일하게 작성할지 그 정도를 적절히 잘 정해야 하는데, 그 디테일의 수준을 정하는 일도 힘든일이거니와 실제로 좋은 퀄리티의 글을 생산하기위한 적절한 수준의 디테일을 확보하는 것도 힘든 일이다.

게으른 완벽주의자

'게으른 완벽주의자를 위한 심리학' 이라는 책이 있다. 해당 책에서는 할 일을 미루는 것이 게을러서가 아니라 역설적으로 일을 굉장히 잘하고 싶은 사람이라서 오히려 할 일을 자꾸만 미루는 사람을 '게으른 완벽주의자'라고 표현한다.

그런 부류의 사람들은 한번 일을 시작하면 나무랄데없이 완벽할 정도로 잘하고 싶은데, 완벽하게 하려고 하다보니 그에 따른 부담감도 상당해져서 일단 일을 시작하지말고 미루고 싶어하는 심리를 갖게 됐다는 것이다.

지금은 X로 불리우는 트위터의 초기 시절에 나는 당시 고등학생이었는데, '소통' 이라는 것이 화두였고 트위터와 같은 SNS에서 각 개인이 다양한 의견을 개진하는 것이 새로운 트렌드였다. 특히, 현실 정치에 대해 논하는 창구로 정치인들, 소위 폴리페서나 일반인 할 것 없이 트위터를 사용했다.

고등학생 시기의 나는 현실정치의 정치공학적인 내용에 흥미가 있었다. 사실 딴짓이 하고 싶었던 것이겠지만 그런 흥미 때문인지 글쓰기 연습과 정치적 다양성 공급이라는 거창한 목적으로 트위터를 한동안 사용했다. 당시의 트위터는 하나의 피드에 140자의 글자 수 제한이 있었는데, 해당 글자 수 제한 안에 본인의 의견을 어떻게든 현학적으로 잘 쓰려고 하다보니 그렇게 긴 글이 아님에도 피드 하나를 작성하는 것에 고민이 많았던 기억이 있다.

그렇게 짧았던 글자 수 제한 탓이 었을까, 대부분의 유저는 단지 140자 글자 수 제한 안에 근거까지 제시 할 순 없으니 단순한 주장만 제시하거나 이목을 끌기 위해 강한 어조로 작성하는 경향이 있었다. 그에 따른 부작용으로 지금도 유명인이 어떤 사회적으로 논란이 되는 행동을 하면 SNS에서 발언했던 해당 인물의 발언과 모순되어 'O적O'라는 식으로 조롱받는다. 그렇다보니 당시에도 멘체스터 유나이티드의 감독 퍼거슨이 '트위터는 인생의 낭비' 라고 발언하는 등 홧김에 감정적인 상태의 자신의 의견이나 주장을 개진하는 것을 경계하기도 했다.

트위터에서 140자 내에서 어떤 주장이든 할 수 있지만 그 해명은 1400자로도 부족하다.

— 트위터 유저 아무개

그 유명한 퍼거슨의 발언과 함께, 내가 봤던 트위터에 관한 언급 중 가장 기억에 남는 구절이다. 이 구절이 트위터를 그만둔 이유의 6-7할은 되는 것 같다. 완벽한 주장은 사실 존재하지 않겠지만, 적어도 손색없는 주장을 글로써 트위터에 남기려면 당시의 트위터 140자 제한과 UI 여건 하에서는 상당히 불편했던 것 같다.

결국, 괜히 적당히 완벽하지도 않고 꼬투리 잡힐 글, 써봐야 뭐하나— 라는 생각이 들고 만 것이다.

그럼에도 글을 써야 하는 이유

흥미로운 것을 글감으로 삼자

새로운 기술에 대한 피로감은 결국 조급함에서 비롯된다. 새 기술을 빨리 공부하고 글로 남겨야 한다는 의무감과 뒤처지기 싫다는 압박감이 글쓰기를 방해하는 것이다.

단지 그 기술이 새로운 것이라는 것 이유 하나만으로는 굳이 깊게 파고들어 글로 남길만큼 공수를 들일 필요는 없다.

무엇보다 새로운 기술 중에서도 굉장히 흥미가 있고 그것을 공부하고 글로 남기고 싶은 의욕이 강할 때 글감으로 삼아 골라 쓰면 되는 것이다.

글의 목적에 맞춘 디테일로 쓰자

내가 쓰는 글의 독자가 이해하는 데에 무리가 없도록 글감에 대한 디테일의 수준을 정하면 된다.

초급 개발자가 읽는 기술 문서를 쓸 때에는 수준에 따라 설명이 필요한 용어가 있다면 별도의 단락이나 페이지로 마련하여 설명하거나 해야할 것이다.

하지만 공부한 것을 회고하는 차원에서 쓰는 블로그 글에 대해서는 나 자신의 복습을 위한 차원이 글 작성의 가장 큰 목적이다.

블로그에 회고하는 글에 대해서는 전문적으로 자세히 써야한다는 강박을 좀 벗어나도 좋을 것 같다.

불완전함 속에서 성장한다

완벽한 글이라는 것은 애초에 없거니와, 처음부터 완벽한 글작가도 없을 것이다.

글 자체를 쓰지 않으면 글쓰기 실력또한 발전도 없는 것이다.

불완전한 글이라도 일단 써보면, 피드백 — 수정 — 성장 과 같은 과정이 있을 수 있다.

특히 개인 블로그 글은 일단 쓰고 윤문하고 퇴고하여 다듬으면 된다.

Jekyll to Zola 전환기

Jekyll

Jekyll 을 사용한 가장 큰 이유는 대중적으로 개발 블로그로서 많이 사용하는 SSG(Static Site Generator) 였기 때문이다. 이미 시행착오를 겪은 유저들이 작성한 여러 정보도 많고 다양한 테마도 제공하는 등 개발 블로그를 처음 만들어보는 입장에서 진입장벽이 크지 않을 거라고 생각했다. 또, 티스토리 나 velog 와 같은 플랫폼을 통하기보다 개발자로서 여러 옵션을 설정해가며 작성해보고 싶었다.

또, Github Pages 로 배포되고, 배포과정에 Github Actions 와 같은 기능도 사용되다보니 아주 약간의 Devops 측면으로 공부되는 지점도 있었다.

Why Zola then

Zola 를 선택한 계기는 사실 지인이 사용 중에 있었기 때문이다.

Rust 기반의 SSG 라는 사실 또한 기존에 비해 더 빨리 빌드되지 않을까하는 기대감도 있었다.

선택한 이유 중 가장 큰 이유는 사실 serene 이라는 테마가 상당히 마음에 들었다.

Code, Callout, KaTex를 통한 수식, Mermeid를 통한 차트 등 다양한 표현이 가능한 것도 serene Demo Site 에서 확인하여 곧장 Jekyll 에서 바꾸어야 겠다고 생각했다.

Settings in Zola

Zola 는 코드 구문을 작성할 때, sublime-syntax 파일 설정을 통해 코드의 Syntax Highlighting이 표현된다.

Zola 는 공식 문서의 Syntax Highlighting 절을 보면 현재 Solidity 나 Solidity 내부의 inline assembly 인 Yul 은 지원하지 않는다.

Syntax에 잘 맞추어 작성된 sublime-syntax 파일인지는 모르겠지만, 어느 한 유저가 만들어 둔 SublimeEthereum Github Repo 에서 제공하는 파일을 이용해서 추가했다.

또, 해당 레포에서 Solidity의 sublime-syntax 는 제공하고 있지만, Yul의 경우는 tmLanguage 파일 형태로만 제공하고 있어서 Sublime Text Editor 를 설치하여 해당 프로그램에서 tmLanguage 를 sublime-syntax 파일로 컨버트하여 적용했다.

아래는 그 결과다.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

contract HelloWorld {
    string public greet = "Hello World!";
}

{
    let size := calldatasize()
    let ptr := mload(0x40)
    calldatacopy(ptr, 0, size)
    return(ptr, size)
}

해당 sublime-syntax 파일은 내 블로그 깃헙 레포 에서 확인할 수 있다.

해당 파일을 syntaxes 폴더 등 적절한 경로에 두고, config.toml 에서 extra_syntaxes_and_themes = ["syntaxes", "themes/serene/highlight_themes"] 와 같은 형식으로 설정하면 된다.

Syntax Highlighting 추가에 대한 자세한 설명은 Zola 공식 문서의 Syntax Highlighting 에서 제공한다.

Account Abstraction

Security Token Offering

Real World Asset

⁴

Digital Asset Treasury