Codex로 블로그를 정리하고 포스팅하는 흐름

이 글은 Codex에게 글 한 편 써 달라는 이야기가 아니다. 이번에는 블로그 저장소를 같이 만지면서, 오래된 글을 지우고, devlog를 다시 쪼개고, 프로젝트 페이지를 정리하고, 새 글까지 쓰는 흐름을 꽤 오래 같이 굴렸다. 해 보니 초안을 뽑는 용도보다 편집 파트너나 작업 운영자에 더 가까웠다.

전제는 하나 있다. 내 의견과 경험이 들어가야 하는 부분은 내가 직접 답해야 한다는 점이다. Codex가 구조를 잡고, 글을 다듬고, 파일을 고치고, 이미지를 붙이고, mermaid 렌더링까지 붙여 줄 수는 있어도 내 경험을 대신 만들어 주지는 않는다. 이번 작업이 잘 굴러간 것도 그 선을 꽤 분명하게 잡고 갔기 때문이다.

실제로는 대체로 이런 순서로 갔다.

먼저 글의 역할부터 정했다. devlog, article, 프로젝트 페이지가 각각 뭘 해야 하는지부터 정했다.
오래된 글을 훑으며 지울 것, 살릴 것, 다시 쓸 것을 갈랐다.
경험이 필요한 글은 인터뷰부터 했다.
초안이 잡히면 본문, 제목, 설명, 이미지, 링크를 같이 손봤다.
글을 고치다 막히는 UI나 렌더링 문제는 그대로 저장소에서 해결했다.
한 배치가 끝나면 커밋하고 다음 묶음으로 넘어갔다.

처음엔 기준부터 정했다

처음부터 글을 고치기 시작하지는 않았다. 먼저 블로그 안에서 글이 어떤 역할을 가져야 하는지부터 정리했다. devlog는 프로젝트에 연결된 진행 기록으로 두고, article은 특정 주제를 설명하는 글로 분리하고, 프로젝트 페이지는 README처럼 짧고 건조하게 유지하는 식이었다. 프로젝트 페이지는 frontmatter와 섹션 순서도 먼저 정해 두고 그 틀 안에서만 다듬었다.

이 기준을 먼저 정해 두니 나중에 판단이 빨라졌다. Epoch: Unseen devlog를 프로젝트별 시리즈로 다시 묶고, Character Forge 같은 글은 관련 article로 따로 세우고, 의미가 약한 글은 과감히 지우는 식의 결정이 훨씬 쉬워졌다. 오래된 Vulkan, AWS, LangChain, DeepLearning 글을 대량 정리한 것도 결국 이 기준 덕분이었다.

그다음은 글을 바로 쓰지 않고 인터뷰부터 했다

이번에 가장 자주 쓴 방식은 인터뷰였다. 내가 OpenCode, FlyingCat, OpenClaw, Character Forge, Harness-Monitor 같은 글을 다듬으려고 할 때, Codex가 먼저 몇 가지 짧은 질문으로 재료를 모았다. 왜 그 툴을 쓰게 됐는지, 어디서 한계를 느꼈는지, 실제로 어떤 작업을 맡겼는지, 결과가 어느 정도였는지를 짧게 확인하는 식이다.

이 방식이 좋았던 이유는 단순하다. AI가 제멋대로 그럴듯한 경험담을 꾸며 넣을 위험이 크게 줄어든다. 대신 내가 짧게 답한 내용을 중심으로 글이 자라난다. 이번에 FlyingCat 글이 살아난 것도, NANACA CRASH를 모티브로 잡은 이유나 Antigravity + Gemini 3.0 Pro로 어디까지 맡겼는지를 인터뷰로 다시 꺼냈기 때문이다.

결국 Codex를 글쓰기 도구로 쓸 때 제일 중요한 건 좋은 문장을 대신 쓰게 하는 것보다 내가 실제로 겪은 걸 제대로 끌어내게 하는 것에 더 가깝다고 느꼈다.

편했던 건 글쓰기와 저장소 작업이 한 루프로 묶인다는 점이다

보통 글을 쓰다 보면 문장만 고치는 게 아니라 저장소도 같이 건드리게 된다. 이미지 파일을 옮기고, 프로젝트 썸네일을 바꾸고, 관련 글 링크를 다시 연결하고, 어떤 경우에는 렌더러 코드까지 손봐야 한다. 이번에도 딱 그랬다.

예를 들어 Character Forge 글에는 mermaid 다이어그램을 넣었는데, 그냥 코드블록으로만 보여서 결국 MDX 렌더러 쪽에 mermaid 지원을 붙였다. FlyingCat, Epoch: Unseen, Harness-Monitor 프로젝트 페이지는 썸네일과 설명문을 다시 손봤고, 홈에서는 project 필터와 topic 필터를 분리했다. 글을 고치다가 UI나 렌더링 문제가 보이면 그대로 저장소까지 이어서 손대는 흐름이 자연스러웠다.

이게 생각보다 컸다. 글의 설명과 실제 블로그 구조가 한 저장소 안에서 같이 정리되니, 글은 맞는데 화면은 어색한 상태로 오래 남아 있지 않았다.

이번에 자주 쓴 스킬

몇 가지는 꽤 분명하게 손에 익었다.

technical-blog-writing 구조를 세울 때 가장 먼저 도움이 됐다. 이 글이 비교 글인지, 실험 기록인지, 운영기인지부터 정하고, 도입과 결론이 흩어지지 않게 잡는 데 좋았다.
humanizer 다듬을수록 글이 너무 반듯해지거나 설명문처럼 굳는 경우가 많은데, 그걸 풀 때 자주 썼다. 특히 프로젝트 페이지나 예전 Unity/Unreal 글처럼 짧은 글에서 효과가 컸다.
grammar-checker 마지막에 맞춤법, 띄어쓰기, 표현 꼬임을 한 번 더 보는 용도로 괜찮았다. 기술 글은 문장보다 내용이 먼저라서 이런 마감이 의외로 중요했다.

스킬 말고도 자주 쓴 흐름이 있었다. 계획을 먼저 세우고, 실제 파일을 읽고, 본문을 수정하고, 이미지 파일을 복사하고, 필요하면 관련 코드까지 고친 뒤, 배치가 괜찮아질 때까지 다시 보는 식이다. 이번처럼 블로그를 크게 손볼 때는 이 반복이 잘 맞았다.

좋았던 점은 세 가지였다

첫째, 범위가 큰 정리를 계속 밀 수 있었다. 글이 수십 개 섞여 있는 상태에서 무엇을 지우고 무엇을 살릴지 판단하는 건 손이 잘 안 간다. Codex와 같이 하면 그 막막한 첫 단계를 넘기기가 쉬웠다.

둘째, 글과 구조를 함께 정리할 수 있었다. devlog 번호, project 링크, 태그, 썸네일, 관련 글 허브처럼 글 밖의 요소도 같이 만질 수 있다는 점이 컸다. 단순한 문장 생성형 도구와는 이 지점이 꽤 다르게 느껴졌다.

셋째, 내가 놓친 기준을 계속 다시 물어봐 줬다. 어떤 글은 삭제할지, 어떤 글은 devlog에 다시 흡수할지, 프로젝트 페이지에는 기술 내용을 얼마나 남길지 같은 걸 여러 번 짧게 확인하면서 방향을 고정할 수 있었다.

아쉬운 점도 분명했다

물론 그냥 맡겨 두면 알아서 좋은 글이 나오는 건 아니다. 가장 위험한 건 역시 경험이 필요한 부분이다. 내가 직접 겪은 판단이나 감각이 들어가야 하는데, 그 부분을 확인하지 않으면 금방 밋밋하고 AI 같은 글이 된다.

또 하나는 너무 반듯해지기 쉽다는 점이다. 구조는 잘 잡아도 문장 리듬이 전부 비슷해지고, 소제목 아래 첫 문장이 모범답안처럼 굳는 경우가 자주 있었다. 그래서 이번에는 사람답게 다시 다듬어 달라는 요청을 여러 번 넣었다.

프로젝트 페이지와 article, devlog의 역할을 섞지 않는 것도 중요했다. 이 경계가 흐려지면 프로젝트 페이지는 쓸데없이 자세해지고, devlog는 잡탕이 된다. 그래서 먼저 역할을 정하고 들어가는 편이 훨씬 나았다.

지금 기준의 결론

지금 내 기준에서 Codex는 블로그 글을 대신 써 주는 유령 작가라기보다, 저장소 안에서 같이 움직이는 편집 파트너에 가깝다. 기준을 먼저 세우고, 필요한 경험은 인터뷰로 끌어내고, 본문 수정과 파일 작업을 한 루프로 묶으면 꽤 강하다.

특히 이미 글이 쌓여 있는 블로그라면 더 그렇다. 새 글 한 편보다도 무엇을 지우고, 무엇을 남기고, 무엇을 다시 써야 하는지를 같이 판단하는 쪽에서 더 큰 도움을 받았다. 이번에 블로그를 정리하면서 가장 분명하게 느낀 것도 그 부분이었다. 좋은 글 한 편을 뽑는 것보다, 블로그 전체를 계속 손볼 수 있는 흐름을 만드는 일이 더 중요했다.