Codex를 답변기가 아니라 에이전트로 쓰는 법 – 옵시디언 블로그 운영 실전기

Posted on by

Quick Answer
Codex를 잘 쓰는 핵심은 질문을 멋있게 던지는 게 아니라, 산출물 경로, 채널 역할, 검증 기준을 먼저 고정하는 거다. 실제로 이번 세션에서는 블로그 전략 문서 통합, 에이전트 규칙 수정, 검증용 기사 초안 작성, 채널별 QC 스킬 생성까지 이어졌고, 생산성보다 더 크게 달라진 건 “중간에 끊기지 않는 흐름”이었다.

이 글이 필요한 사람

  • Codex를 아직 답변 잘하는 챗봇 정도로만 쓰는 사람
  • 옵시디언 볼트나 블로그 운영처럼 파일이 많은 작업에 AI를 붙여보고 싶은 사람
  • AI가 글 하나 써주는 것보다, 작업을 처음부터 끝까지 굴리는 방식이 궁금한 사람
  • “에이전트”라는 말이 마케팅 문구인지 진짜 실무용인지 확인하고 싶은 사람

지금 결론

  1. Codex는 질문 응답보다 작업 위임에 더 강했다. 파일 경로와 목표가 명확하면 손이 꽤 적게 간다.
  2. 진짜 병목은 생성이 아니라 검수였다. 초안은 빨리 나오는데, 채널에 맞는지 거르는 기준이 없으면 다시 사람이 흔들린다.
  3. 그래서 답은 글 생성 스킬보다 QC 스킬이었다. 이번에 만든 blog-channel-qc 같은 최종 필터가 있어야 결과가 덜 무너진다.

이번에 실제로 뭘 시켰냐

이번 세션에서 내가 Codex에 맡긴 일은 대충 이런 흐름이었다.

  1. 세 개 블로그(TECHTAEK, TAEK2, 배당노마드) 수익화 전략 문서 통합
  2. 블로그 아이디어/모닝브리핑/파이프라인 에이전트 규칙 수정
  3. 샘플 출력으로 규칙이 실제로 먹히는지 검증
  4. 배당노마드용 실전 글 2편 작성
  5. TAEK2와 TECHTAEK 쪽은 글 수정보다 에이전트/스킬 중심으로 가는 게 맞는지 재판단
  6. 최종적으로 blog-channel-qc 스킬 초안 생성 및 검증

이게 좋았던 이유는 단순하다. 보통 AI한테는 한 번에 한 작업만 맡기게 되는데, 이번에는 문서 -> 규칙 -> 검증 -> 초안 -> QC 도구까지 한 줄로 이어졌다.

뭐가 달라졌냐 – 답변기와 에이전트의 차이

1. “설명”보다 “산출물” 중심으로 대화하게 된다

답변기로 쓰면 보통 이런 식이다.

  • 이거 어떻게 생각해?
  • 어떤 전략이 좋아?
  • 예시 좀 보여줘

에이전트로 쓰면 질문이 바뀐다.

  • 이 폴더 안 문서 두 개 합쳐서 새 마스터 전략 문서 만들어줘
  • 이 에이전트 파일들 읽고 규칙 바꿔줘
  • 샘플 출력 2개로 검증해줘
  • 그 결과 보고 새 스킬 만들 가치 있는지 판단해줘

즉, 대화보다 납품 중심이 된다. 이 차이가 생각보다 크다.

2. 중간에 끊기지 않게 해주는 게 진짜 장점이었다

이번에 가장 좋았던 건 속도보다 흐름이었다.

예전에는 이런 작업이 보통 이렇게 끊겼다.

  • 전략 정리하고 멈춤
  • 다음날 에이전트 수정하다가 다시 맥락 복구
  • 며칠 뒤 글 초안 만들면서 “우리가 왜 이 방향이었지?” 다시 생각

이번에는 같은 세션 안에서 맥락이 계속 이어졌다. 그래서 “전략은 이거였고, 그러면 에이전트는 이렇게 바꿔야 하고, 그러면 테스트 글은 이런 형태여야 한다”가 한 번에 굴렀다.

이건 체감상 꽤 컸다. 생산성 숫자보다 피로도가 더 줄었다.

3. 파일 경로를 공유하는 작업에서 특히 강했다

옵시디언 볼트처럼 경로가 많은 환경에서는 AI가 말만 하면 솔직히 반쪽짜리다. 결국 파일을 읽고, 고치고, 새로 만들고, 다시 연결해야 한다.

이번 세션에서는 실제로:

  • 전략 문서를 특정 폴더에 만들고
  • .claude/agents/ 아래 에이전트 파일들을 수정하고
  • 02.Areas/blog/dividend/와 02.Areas/finance/에 초안을 만들고
  • 마지막엔 /Users/jtpark/.codex/skills/blog-channel-qc/에 스킬까지 만들었다

이런 흐름이 가능했다. 즉 “아이디어 제안”을 넘어서 “작업물 이동”이 된다.

어디서 별로였냐

좋은 얘기만 하면 또 광고문 된다. 직접 써보니 명확한 한계도 있었다.

1. 생성보다 검수 비용이 더 크다

글 초안은 생각보다 빨리 나온다. 근데 그 글이 진짜 TECHTAEK답냐, TAEK2답냐, 배당노마드답냐는 전혀 다른 문제다.

예를 들어:

  • TECHTAEK인데 뉴스 요약처럼 써버리면 바로 망한다
  • TAEK2인데 공식 출처와 절대 날짜가 약하면 신뢰가 흔들린다
  • 배당노마드인데 세후 현금흐름 얘기가 없으면 그냥 배당률 소개글이 된다

즉 초안 생성은 쉬운데, 채널 적합성 검수는 여전히 사람 기준이 필요했다. 이번에 QC 스킬을 만든 이유가 딱 이거다.

2. 질문이 애매하면 결과도 애매하다

Codex가 알아서 다 해줄 것 같지만, 사실 입력 품질은 여전히 중요했다.

잘 된 요청은 대체로 이런 특징이 있었다.

  • 산출물 경로가 명확함
  • 채널 역할이 명확함
  • “무엇을 만들지”보다 “무엇으로 검증할지”가 포함됨

반대로 애매한 요청은 결과도 예쁘게 애매했다. AI가 무능해서가 아니라, 내가 애매하게 던지면 그냥 정중하게 애매해진다.

3. 리뷰 기준이 없으면 같은 작업을 반복하게 된다

이건 은근 무섭다. 글 하나 고치고 나면 좋아진 것 같은데, 다음 글에서 또 같은 문제를 반복한다.

그래서 이번에 느낀 건:

  • 글 수정은 치료
  • 에이전트 수정은 예방
  • QC 스킬은 정기검진

이 셋이 같이 가야 한다는 거였다.

이번에 만든 내 워크플로우

지금 기준으로 내가 다시 쓰라면 이렇게 쓸 것 같다.

Step 1. 전략 문서 먼저 만든다

채널 역할이 먼저다.

  • TAEK2 = 검색형/결정형/공식출처형
  • 배당노마드 = 세후 현금흐름/계좌 배치/배당 구조형
  • TECHTAEK = 실사용/워크플로/실패담형

이게 먼저 고정돼야 초안 품질이 안정된다.

Step 2. 에이전트를 고친다

아이디어 캡처, 모닝브리핑, 파이프라인 단계에서 채널별 우선순위와 템플릿을 반영한다.

이번에 실제로 바꾼 것도 이거였다. 글감을 뽑는 순간부터 TECHTAEK 뉴스형보다 TAEK2 결정형, 배당노마드 실수령형이 더 위에 오게 바꿨다.

Step 3. 샘플 출력으로 검증한다

여기가 중요하다. 규칙 바꾸고 끝내면 기분은 좋은데, 실제 출력이 그대로면 아무 의미 없다.

그래서:

  • 모닝브리핑 샘플
  • 글감 스캔 샘플
  • 실제 글 초안 1~2개

를 꼭 돌려보는 쪽이 맞다.

Step 4. 마지막은 QC로 거른다

이번에 만든 blog-channel-qc 스킬이 딱 이 단계용이다.

역할은 간단하다.

  • 이 글이 어느 채널에 맞는지
  • 왜 맞거나 안 맞는지
  • 최소 수정안이 뭔지

를 빠르게 짚는다.

즉 생성기가 아니라 판정기다.

실수 TOP 5

1. AI한테 처음부터 완성품을 기대하는 실수

완성품보다 연속 작업자로 보는 게 더 잘 맞는다.

2. 채널 역할 정리 없이 글부터 뽑는 실수

이러면 초안은 나오는데 채널 정체성은 흐려진다.

3. 검수 기준 없이 “좋아 보인다”로 넘기는 실수

이게 제일 위험하다. 계속 비슷한 실수를 반복하게 된다.

4. 전략 문서와 실제 글 사이를 사람이 계속 손으로 메우는 실수

그 간극을 줄이려고 에이전트를 고치는 건데, 자꾸 수작업으로 메우면 다시 원점이다.

5. 스킬을 너무 크게 만드는 실수

이번에 느낀 건 스킬은 거창할수록 좋은 게 아니었다. 오히려 마지막에 채널 적합성만 거르는 얇은 스킬이 더 실용적이었다.

FAQ

Q. Codex는 그냥 글쓰기 도구 아닌가요?

아니다. 글만 쓰게 하면 그렇게 보일 수 있는데, 실제론 파일 읽기, 수정, 새 문서 생성, 규칙 정리, 검증 흐름까지 이어갈 때 훨씬 강하다.

Q. 그럼 사람은 뭘 해야 하나요?

채널 역할과 검수 기준을 정하는 일이 가장 중요하다. 초안 생성보다 “무엇을 좋은 결과로 볼지” 정하는 쪽이 아직 사람 몫이다.

Q. 제일 먼저 바꿔야 하는 건 프롬프트인가요?

이번 경험 기준으로는 프롬프트보다 작업 구조가 먼저였다. 산출물 경로, 채널, 검증 기준을 먼저 고정하는 편이 훨씬 덜 흔들린다.

Q. 다시 쓴다면 제일 먼저 뭘 만들 건가요?

전략 문서 하나, 채널별 QC 기준 하나. 이 둘이 먼저다. 글 생성 스킬은 그다음이다.

다음에 읽을 글

  • 옵시디언에 Gemini Embedding 2를 붙여보니 검색이 덜 멍청해졌다 사용기
  • Claude Cowork 실사용 후기 - 폴더 하나 지정했더니 6개월 영수증이 정리됐다
  • 배당금 100만원 받으면 실제로 얼마 남나 - 세금·건보료 실수령표

결론

이번에 직접 써보니 Codex를 잘 쓰는 핵심은 프롬프트 미사여구가 아니었다. 파일 경로, 채널 역할, 검증 기준, 최소 산출물 이 네 개를 먼저 고정하면 답변기가 아니라 에이전트처럼 굴기 시작한다.

그리고 그다음 교훈은 더 현실적이다. 초안 생성은 이미 충분히 빠르다. 앞으로 더 중요한 건 채널 적합성 검수다. 이번에 blog-channel-qc 같은 얇은 필터를 따로 만든 이유도 그거다. 이제는 더 많이 쓰는 것보다, 덜 틀리게 쓰는 단계로 넘어가는 게 맞다.

참고 자료

📱 SNS 포스트 (복사용)

🐦 X (280자)

Codex를 그냥 답변기처럼 쓰면 “그럴듯한 말”은 잘 해주는데, 일은 중간에 끊긴다. 반대로 산출물 경로, 채널 역할, 검증 기준, 최소 산출물부터 고정하면 진짜 에이전트처럼 굴기 시작한다. 이번엔 블로그 전략 문서, 에이전트 수정, QC 스킬 생성까지 한 세션에서 이어봤다.

🧵 스레드 (500자)

이번에 Codex를 다시 써보면서 제일 크게 느낀 건, 잘 쓰는 핵심이 프롬프트 문장빨이 아니라는 점이었다.

진짜 중요한 건 4개였다.
– 어디에 저장할지
– 이 글/작업이 어느 채널 역할인지
– 무엇으로 통과/탈락을 판정할지
– 최소 산출물이 뭔지

이걸 먼저 고정하니까 Codex가 “설명 잘하는 챗봇”이 아니라 실제 작업을 밀어주는 에이전트처럼 움직였다.

이번 세션에서는 블로그 전략 문서 통합, 에이전트 규칙 수정, 검증용 글 초안, 채널별 QC 스킬 생성까지 한 줄로 이어졌다.

결론은 단순하다. 앞으로 병목은 생성이 아니라 검수다. 그래서 이제는 더 많이 쓰는 것보다, 덜 틀리게 쓰는 시스템이 중요하다.