콘텐츠로 건너뛰기
Codex

topics.json으로 글감 백로그를 관리하는 단순한 방법

topics.json으로 글감 백로그를 관리하는 단순한 방법

TECH NOTE · CONTENT PIPELINE

대시보드 없이 JSON 파일 하나로 글감 백로그를 굴리는 방법과, 그 파일에 무엇을 남겨야 하는지 정리했습니다.

topics.json 하나면 충분하다

글감 백로그는 거창한 대시보드가 없어도 topics.json 파일 하나로 굴러간다. 내 경우에는 글감이 문제라기보다, “이거 어디까지 생각했지?”를 매번 다시 떠올리는 게 더 문제였다. 그래서 제목, 상태, 짧은 메모 정도만 JSON으로 남겨두니 훨씬 덜 헷갈렸다.

처음엔 노션 보드나 스프레드시트도 생각했다. 그런데 글감 관리가 목적이면, 도구가 너무 커지는 순간 오히려 손이 안 간다. 파일 하나 열어서 고치고, 커밋에 같이 남기면 끝나는 정도가 딱 맞았다.

상태는 세세하게 나누지 않는다

상태값은 적을수록 오래 간다. 처음부터 researching, drafting, editing, published, archived처럼 많이 나누면 관리하는 맛은 나는데, 며칠 지나면 내가 그 차이를 안 지킨다.

내 경우에는 이 정도면 충분했다.

상태 의미
queued 글감으로 등록만 해뒀다
drafted 초안이 나왔다
reviewed 사람이 읽고 승인했다
uploaded 워드프레스에 초안으로 올라갔다
published 공개 발행했다

상태를 몇 개로 둘지는 취향이 아니라 필요에 따라 정해진다. 나는 초안 생성과 발행 사이에 사람이 확인하는 단계가 있어서 reviewed가 따로 필요했다. 그 단계가 없으면 셋이면 충분하다.

JSON은 이런 식으로 둔다.

[
  {
    "id": "codex-cli-login-check",
    "title": "Codex CLI 로그인 상태를 헷갈리지 않게 확인하는 법",
    "status": "drafted",
    "notes": [
      "codex login부터 다시 치면 오히려 상태가 꼬일 수 있음",
      "먼저 현재 폴더와 로그인 상태를 나눠서 봐야 함"
    ],
    "updated_at": "2026-07-26"
  },
  {
    "id": "topics-json-backlog",
    "title": "topics.json으로 글감 백로그를 관리하는 단순한 방법",
    "status": "queued",
    "notes": [
      "복잡한 대시보드 없이 JSON 파일 하나로도 상태를 굴릴 수 있음"
    ],
    "updated_at": "2026-07-26"
  }
]

여기서 핵심은 필드를 멋있게 만드는 게 아니다. 나중에 봤을 때 “아, 이 글은 여기까지 생각했구나”가 바로 보여야 한다. 그 정도면 백로그 역할은 한다.

파일을 열었을 때 바로 보여야 한다

topics.json은 사람이 계속 읽는 파일이다. 그러니 자동화하기 좋은 구조보다, 내가 눈으로 훑기 좋은 구조가 먼저다.

처음엔 메모를 문자열 하나로 길게 넣을까 했다. 그런데 그렇게 하면 나중에 문장을 덧붙일 때 지저분해진다. 짧은 메모 여러 개를 배열로 두는 편이 편했다.

{
  "id": "example-topic",
  "title": "예시 글감 제목",
  "status": "drafted",
  "notes": [
    "처음 막힌 지점",
    "나중에 본문에서 꼭 설명할 부분",
    "명령어를 넣을지 말지 고민할 부분"
  ],
  "updated_at": "2026-07-26"
}

id는 파일명처럼 생각하면 된다. 제목은 나중에 바뀔 수 있지만, id는 웬만하면 그대로 둔다. 그래야 다른 메모나 초안 파일에서 이어 붙이기 쉽다.

명령어로 확인할 수 있게 둔다

JSON 파일의 장점은 사람이 읽을 수도 있고, 필요하면 명령어로 걸러볼 수도 있다는 점이다. 예를 들어 지금 초안으로 옮길 만한 글감만 보고 싶을 때는 jq가 편하다.

먼저 파일이 JSON으로 깨지지 않았는지 확인한다. 별거 아닌데, 쉼표 하나 잘못 넣으면 뒤에서 더 헷갈린다.

jq . data/topics.json

아직 손대지 않은 글감만 보고 싶으면 이렇게 본다.

jq -r '.[] | select(.status == "queued") | .title' data/topics.json

내 경우에는 이 정도만 있어도 충분했다. 대시보드에서 필터를 누르는 대신, 터미널에서 한 줄 치고 지금 쓸 글감을 고르는 방식이다.

백로그와 초안은 분리한다

topics.json에 본문까지 다 넣기 시작하면 금방 망가진다. 이 파일은 백로그다. 초안 파일이 아니다.

그래서 topics.json에는 판단에 필요한 정도만 둔다.

넣는 것 안 넣는 것
제목 후보 완성된 본문
현재 상태 긴 문단
짧은 메모 이미지 설명 전체
마지막으로 본 날짜 발행용 최종 문장

글이 길어질 것 같으면 별도 마크다운 파일로 빼는 편이 낫다. topics.json에는 그 글이 왜 필요한지, 어디까지 왔는지만 남긴다.

정렬 기준도 단순하게 둔다

우선순위 필드를 넣을 수도 있다. 그런데 나는 숫자 우선순위를 잘 안 믿는다. 오늘의 1순위가 내일은 7순위가 되는데, 그걸 매번 고치는 게 귀찮다.

대신 상태와 업데이트 날짜만 본다.

jq -r 'sort_by(.updated_at) | .[] | "\(.status)\t\(.title)"' data/topics.json

오래 방치된 글감이 보이면 둘 중 하나다. 다시 살리거나, 그냥 done으로 닫는다. 백로그가 많아지는 것보다 애매한 글감이 계속 남아 있는 쪽이 더 피곤했다.

같이 나오는 질문

JSON이 꼭 필요할까?

꼭 필요하진 않다. 글감이 열 개도 안 되면 그냥 마크다운 목록이 더 편할 수 있다. 다만 상태별로 걸러보거나, 나중에 작은 스크립트로 이어 붙일 생각이 있으면 JSON이 덜 막힌다.

스프레드시트가 더 편하지 않나?

여럿이 같이 보면 스프레드시트가 낫다. 혼자 쓰는 블로그 백로그라면 파일 하나가 더 가볍다. 커밋에 같이 남는 것도 은근히 편하다.

필드를 더 추가해도 되나?

된다. 다만 처음부터 많이 넣지는 않는 편이 낫다. source, draftPath, publishedUrl 정도는 나중에 필요해지면 추가하면 된다.

다음에는 이 topics.json에서 ready 상태인 글감만 뽑아서 초안 파일을 만드는 흐름을 확인하면 좋다.

이 블로그 더 보기

이 블로그는 실제 프로젝트를 AI와 함께 굴리면서 남긴 기록입니다.

  • 새 글은 RSS로 받아볼 수 있습니다.
  • 시리즈 전체는 여기에 정리해 두었습니다.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다