블로그를 직접 만들기로 했다 — 자동화의 시작

무언가를 만들고 나면 결과물은 남는다. 그런데 만드는 동안 했던 생각은 생각보다 쉽게 사라진다.

왜 이 기능을 넣었는지, 처음에는 무엇을 만들려고 했는지. 어디에서 막혔고, 왜 다른 방향을 택했는지. 작업이 끝나고 나면 이런 질문에 대한 답은 대화와 메모 사이에 흩어져 있다.

비개발자인 내가 AI와 함께 여러 실험과 프로젝트를 진행하면서 남기고 싶어진 것도 그 부분이었다. 완성된 화면뿐 아니라, 그 화면에 도착하기까지의 과정.

그래서 N-Layer 안에 작은 기록 공간을 만들기로 했다. 이름은 N-Layer Build Log. 잘된 일만 모으는 곳보다는 시도와 판단, 막혔던 이유를 함께 남기는 곳으로 시작하고 싶었다.

이 글은 ‘블로그 자동화 만들기’의 첫 번째 기록이다.

처음 생각은 단순했다

처음에는 그냥 블로그 하나를 만들면 된다고 생각했다. 글을 쓰고, 사진을 넣고, 게시하면 되는 공간.

그런데 내가 원한 것은 작업이 끝난 뒤 다시 처음부터 글을 쓰는 일이 조금 줄어드는 구조였다.

조사를 했다면 참고한 자료가 남고, 개발을 했다면 바뀐 내용이 남았으면 했다. 실패했다면 어디에서 막혔는지, 무엇을 바꿔 다시 시도했는지도 남기고 싶었다. 마지막에는 그 기록들을 살펴보며 하나의 글로 정리할 수 있도록.

아직 이런 연결이 모두 자동으로 이루어지는 것은 아니다. 다만 블로그를 만들면서 바라보는 질문이 달라졌다.

“어디에 블로그를 만들까?”가 아니라 “내가 하는 일을 어떻게 기록으로 바꿀까?”

그 질문의 첫 번째 답으로 기존 사이트에 Build Log를 붙였다.

기존 서비스를 쓸까, 직접 만들까

기존 블로그 서비스를 쓰면 시작은 훨씬 간단했을 것이다. 글을 올리기 위해 파일 구조나 빌드를 먼저 생각할 필요도 없다.

나도 그 편리함이 필요했다. 다만 이번에는 글을 올리는 공간을 다른 작업의 마지막 단계와 연결해 보고 싶었다. 작업 기록을 정리하고, 필요한 사진과 표를 준비하고, 검토한 글을 같은 형식으로 내보내는 흐름을 직접 다뤄 보고 싶었다.

고민했던 선택지를 내 목적에 맞춰 비교하면 이렇다. 각 서비스의 전체 기능을 평가한 표라기보다, 이번 작업에서 중요하게 본 점을 정리한 것이다.

직접 만든다고 해서 기존 서비스보다 더 좋은 블로그를 만들겠다는 뜻은 아니다. 내가 하는 다른 작업과 글이 이어지는 방식을 직접 정해 보고 싶었기 때문이다.

그렇다고 처음부터 큰 편집 시스템을 만들 필요는 없었다. 이번에는 기존 사이트를 유지하고, 글과 이미지를 파일로 넣어 웹페이지를 만드는 작은 구조부터 택했다.

글 한 편을 올리는 데는 생각보다 많은 일이 있다

평소에는 이 과정을 한마디로 ‘글쓰기’라고 부른다. 막상 나눠 보면 그 안에는 꽤 다른 종류의 일이 들어 있다.

무엇을 기록할지 주제를 정하고, 필요한 자료를 찾는다. 내용을 어떤 순서로 설명할지 구성한 뒤 본문을 쓴다. 사진을 고르고, 비교가 필요한 부분에는 표나 그래프를 준비한다. 마지막에는 사실과 표현을 다시 확인하고 게시한다.

내가 만들고 싶은 흐름을 도표로 옮기면 다음과 같다. 실제로는 검토하다가 자료 조사나 본문 작성으로 돌아갈 수도 있다.

어떤 문장을 쓸지 고민하는 일과, 그 문장을 웹페이지 형식에 맞춰 옮기는 일은 다르다. 사진의 크기와 설명을 챙기고, 표가 작은 화면에서도 읽히는지 확인하는 일도 따로 있다.

자동화를 생각하면서 먼저 살펴본 것은 이런 반복 작업이 어디에서 생기는가였다.

아래 그래프는 실제 측정 시간이나 생산성 데이터가 아니다. 자동화 프로젝트를 시작하며 작업 구조를 이해하기 위해 만든 개념도다. 2·6·4·7·5·5·4·3은 설명을 위해 정한 상대값이며 시간, 횟수 또는 절감 효과를 뜻하지 않는다.

이 그림으로 어느 단계가 가장 오래 걸린다고 결론 내릴 수는 없다. 다만 자동화의 대상을 본문 생성 하나로 좁히지 않도록, 작업 전체를 펼쳐 보는 데 의미가 있었다.

자동화의 목표를 다시 정했다

자동화하고 싶은 것은 생각 자체가 아니었다.

무엇을 기록할지, 내가 실제로 무엇을 겪었는지, 어떤 판단을 했는지는 내가 제공해야 한다. 글이 원래 의도와 맞는지 확인하고, 마지막에 게시할지를 결정하는 일도 내 몫이다.

반면 자료를 묶고 초안의 순서를 정리하는 일은 AI의 도움을 받을 수 있다. 표와 그래프에 필요한 내용을 정돈하고, 이미지가 들어갈 위치를 제안하는 일도 그렇다. 정해진 게시 형식으로 바꾸거나 빠진 항목과 오류를 검사하는 과정은 시스템이 맡도록 만들 수 있다.

이것들은 지금 모두 연결된 자동화가 아니라, 앞으로 나누고 연결하려는 작업들이다.

내가 원하는 것은 AI가 나 대신 블로그를 운영하는 일이 아니다. 내가 기록하고 싶은 생각을, 더 적은 반복 작업을 거쳐 한 편의 글로 연결하는 것이다.

그렇게 보니 글을 자동으로 만드는 문제보다, 사람의 생각이 웹에 올라가기까지의 파이프라인을 만드는 문제에 가까웠다.

그래서 블로그부터 직접 만들었다

지금 만든 기반은 작다. 기존 N-Layer 사이트에 /blog를 추가하고, MDX라는 글 파일을 읽어 웹페이지로 만들게 했다.

본문에는 이미지와 설명, 표, 코드, Callout을 넣을 수 있다. 이번 글에 들어간 실제 화면과 시각자료도 그 구조를 사용한다.

글을 준비하는 동안에는 공개 상태를 꺼 둘 수 있다. 그러면 공개 빌드에서 글뿐 아니라 그 글의 이미지 폴더도 빠진다. 게시를 준비한 글은 공개 상태를 켠 뒤 검증하고 배포하는 흐름이다.

파일 안에서 그 구분은 다음처럼 적는다. 이 코드는 비공개 초안 상태를 보여주는 짧은 예시다.

published: false

게시 전에는 lint와 타입 검사, 테스트, 빌드를 실행한다. 필요한 정보가 빠졌는지, 같은 주소를 쓰는 글이 있는지, 이미지 파일이 실제로 존재하는지도 확인하도록 했다.

아직 AI가 알아서 주제를 찾아 글을 쓰고 자동으로 게시하는 시스템은 아니다. 글을 검토하는 사람도 필요하고, 배포하는 단계도 남아 있다.

그래도 사람이 쓰든 AI의 도움을 받든, 같은 파일 구조를 통해 글을 웹페이지로 만들 수 있는 기반은 생겼다. 자동화를 더 붙이기 전에 기록을 담을 그릇부터 만든 셈이다.

다음에는 글의 구조를 들여다보려 한다

블로그 화면을 만들고 나니 다음 질문들이 남았다.

• 글은 어디에 저장되는가?
• 사진은 어디에 저장되는가?
• 표와 코드는 어떻게 웹페이지가 되는가?
• draft와 published는 어떻게 구분되는가?
• AI는 이 구조를 어떻게 이해할 수 있는가?

다음에는 이 질문들을 따라 글 한 편이 웹페이지가 되는 과정을 살펴보려 한다.

다음 글: 2편 — 글 한 편은 어떻게 웹페이지가 되는가 — 블로그의 구조를 만들다

블로그를 자동화하려 했는데, 첫 번째로 마주한 것은 AI가 아니었다. 글을 컴퓨터가 다룰 수 있는 형태로 만드는 일이었다.