블로그 발행에 로컬 모델을 이용해 보자

지난 글에서 적었던 것처럼 로컬 모델을 사용하기 위해서는 orchestrator보다 worker로 쓰는 것이 적합하다는 판단 하에, 프론티어 모델(gpt-5.5)을 사용 중인 블로그 발행 워크플로우에 도입해 보기로 했다.

아래 작업은 전부 “해줘”로 진행했습니다

이하의 모든 내용 구현은 blog agent로 사용 중인 gpt-5.5가 한 것이다. 나는 내가 원하는 흐름과 그걸 위한 일부 아이디어를 제공했지만, 가끔은 그것도 gpt가 나보다 훨씬 잘 수행했다. 하지만 이러려고 AI를 쓰는 것이 아니겠는가? 애초에 이 블로그 자체가 나는 글만 쓰고, 글 쓰는 것과 관련이 떨어지는 자잘하고 귀찮은 것들은 AI를 이용해서 자동으로 값싸게 진행하는 걸 연습하기 위한 곳이다.

기존 블로그 발행 작업 흐름

blog-management라는 단일 스킬로 운영되며, 나의 요청에 따라 에이전트가 아래의 흐름에서 임의의 단계를 선택해 진행한다.

0. 생각/소재 정리 (나)
1. 초안 작성 (나)
	초안은 무조건 내가. 오직 글자만 집중해서 작성
2. 초안 검토 (나→에이전트)
	→ 초안 폴더에 있는 글 확인해서 목록 출력 후, 검토할 글 내가 선택 (1개일 경우 자동으로 다음 단계 진행)
3. 발행 계획 수립 (에이전트)
	→ 카테고리/프론트매터 체크, 파일 경로 생성 위한 영문 slug 제안, 태그 제안, 필요시 내부글/이미지 링크 제안, 가독성 위한 옵시디언 콜아웃 제안, 민감한 개인 정보 들어있는지 체크 등
4. 계획 승인 후 발행 파일 생성 (나→에이전트)
5. 빌드 검증 (에이전트)
	→ 내부 검증용 서버에서 글이 잘 보이는지 확인
6. 승인 후 commit/push (나→에이전트)
7. 성공 시 원본 초안 정리 (에이전트)

로컬 모델을 어디에 넣을까?

gpt에게 위의 흐름에서 로컬 에이전트에게 위임할 만한 단계를 추천해달라 요청하자 아래 3개를 제안했다. 기본 원칙은 “로컬은 simple & read-only task만 담당하고, 반드시 상용 모델과 사용자가 검증”이다.

초안 폴더 확인 [선택]
초안 메타데이터/이미지/링크 점검
build 및 git 상태 요약

제일 먼저 1번을 택한 이유는 별 거 없고 1번이라서(…) omlx에 올려놓은 gemma4e4b-unsloth 모델 정보를 gpt에게 제공한 뒤, 아래와 같이 요청했다.

요구사항:
초안 폴더에서 Markdown 초안 파일만 확인해줘.,
images 폴더나 이미지 파일은 글 후보에서 제외해줘.,
각 초안에 대해 path, title, date, draft 여부, frontmatter 존재 여부를 확인해줘.,
초안이 0개면 “초안 없음”으로 보고해줘.,
초안이 1개면 바로 그 글을 읽고 발행 준비 검토까지 진행해줘.,
초안이 2개 이상이면 목록을 보여주고 어떤 글을 발행 준비할지 나에게 물어봐줘.,
이 스캔 단계는 읽기 전용으로 처리하고, 초안 파일을 수정하거나 삭제하지 마.,
가능하면 스캔/메타데이터 추출은 로컬 subagent에게 위임하고, 최종 판단과 보고는 사이토씨가 맡는 구조로 만들어줘.

그러고 나니 자기가 알아서 열심히 한 뒤 파이썬 스크립트를 만들고 로컬 모델을 연결했다고 보고했다. 그렇게 무난히 될 줄 알았는데… 그랬음 내가 이렇게 글을 안 써도 되겠지.

결과와 해석

1차 시도: 안 돼, 돌아가

두근거리는 마음으로 글을 쓰고, 에이전트에게 초안 검토를 요청했더니 평소와 똑같이 발행까지 진행되어서 난 로컬 적용이 잘 된 줄 알았다. 그런데 물어보니까 그게 아니란다. 만약을 위해 gpt가 로컬의 답을 검사한 뒤 이상하면 자기가 재검증하는 fallback 단계를 넣어놨었고, 실제로 gemma4e4b가 subagent로 소환된 뒤 <eos>를 출력한 것이다!

본래 기대한 흐름은 deterministic scanner script 실행 → JSON 요약 반환 → gpt가 검증이지만, 실제로는 search_files 비슷한 도구만 한 번 호출 → 제대로 된 요약 없이 <eos> 출력이 된 것이다. (사실 비서형 작업 로컬화하려 했을 때 엄청 많이 본 패턴이었다…)

One-shot programming도 거뜬히 하는 llm이 왜 이렇게 간단한 작업을 못 한다는 것인지 나로서는 정말 이해할 수 없는 노릇이지만, 에이전트에게는 아래 작업이 무척 복잡하다고 한다. e4b가 무난하게 작업하게 하려면 스크립트 실행 후 JSON이 아니라 터미널 결과를 그대로 반환하도록 해야한다나. (아니 고작 파일 하나 실행만 하는 거면 gpt 작업흐름에서 그냥 하면 되지 굳이 귀찮게 로컬을 쓰는 의미가 뭐냔 말이다.) 내가 불평했더니, 로컬은 이런 판단 작업보다 스크립트로 처리하기 어려운 보조 작업에 쓰는 것이 더 낫겠다고 gpt가 제안했다. 초안 폴더 확인도 판단과는 거리가 멀다고 생각했는데… 아무튼 스케일을 더 줄여야 한다니 어쩌겠는가. 그거라도 해야지.

두 폴더를 이해한다
→ 스크립트를 실행한다
→ JSON을 읽는다
→ 필요한 필드만 뽑는다
→ 발행 판단에 맞는 recommendation을 만든다
→ 정해진 형식으로 답한다

2차 시도: 좀 더 작은 단계에는 적용이 됨

이번에는 아주 스케일을 줄여서, 한글 제목을 html 주소용 영문 slug로 바꾸는 작업을 위임하기로 했다. 글 초기 맥락에서 적절한 영단어를 몇 개 추출해 후보를 주면 마지막에 승인은 어차피 내가 하니까 별 상관없지 않을까? gpt도 찬성하며 아래 흐름을 제안했고, 결과는 성공이었다.

1. gpt가 draft_scanner.py 직접 실행
   - 초안 후보 확인
   - title/date/tags 추출

2. 초안이 하나면 gpt가 초안 일부를 읽음

3. 로컬 에이전트에게 slug 후보 생성 위임
   - title
   - description
   - tags
   - 첫 20줄 또는 요약
   - 기존 slug 목록 일부 제공

4. 로컬 에이전트가 후보 3~5개 반환

5. gpt가 충돌 검사 후 발행 계획에 반영
   - src/content/**/<slug>.md 존재 여부
   - 너무 애매한 이름 제거

1차와 2차의 차이

gpt가 subagent에게 주는 명령을 확인해보니 여기에는 goal/context/toolset이 들어간다. 우리가 일반적으로 “프롬프트”라고 부르는 것이 goal과 context로 분할되고, toolset은 그걸 위해 사용할 수 있는 도구인 모양이다. 명령의 뼈대만 살려보면 대략 이런 식이다.

1차

goal: draft_scanner.py 실행하거나 안 되면 직접 파일 찾아봐라. JSON 요약 반환해라. 메타데이터 추출해라. 살펴볼 폴더 경로는 여기다. 이미지 폴더랑 파일은 제외해라.
context: 넌 겨울비의 astro 블로그 초안 스캐너(읽기전용)다. 파일 수정, 이동, 삭제 하지 마라.
toolset: terminal (script 실행용)

그런데 정작 서브에이전트는 터미널 대신 search_files 만 1회 실행하고 eos를 뱉었다.

2차

goal: slug_suggester.py 실행해라. JSON stdout을 읽어서 내가 형식 주는 대로 한 줄로 반환해라.
context: 넌 읽기 전용 에이전트고 파일 수정 안 한다. 명령 수행 성공하면 한 줄로 반환하고, 실패하면 실패 한 줄 반환해라.
toolset: terminal (1차와 동일)

같은 toolset을 사용하지만, 이번에는 성공했다.

1차에서 왜 터미널 실행 대신 search_files로 흘러갔는지를 밝혀내면, 1차도 좀 더 어떻게 할 수 있지 않을까 하는 생각이 들기도 한다.

로컬 모델에게 맡길 수 있는 작업의 조건

로컬에게 복잡한 작업을 맡기는 게 무리라는 건 이해하고 있다. 하지만 ‘간단한’ 작업이 어떤 것인지 정의하는 것은 쉽지 않다. 입/출력이 짧은 작업이나 결과물 검증 가능한 작업은 그나마 직관적인데, 나에게 가장 어려운 건 ‘판단이 필요하지 않은’ 작업이다. 사람에게는 너무나 자명trivial하여 판단이란 생각도 안 드는 것을 에이전트는 판단이 필요하다고 처리할 수 있다. 솔직히 1차에서 draft_scanner.py가 왜 실행이 안 되었는지 아직 나는 잘 이해가 되지 않는다. (이게 바이브 코딩/프롬프팅의 약점이다. 원리를 모르고 만지고 있으니…) 하지만 2차를 통해서, 곁길로 샐 일이 절대 없는 일방통행 작업은 충분히 위임이 가능하다는 걸 확인했다. 앞으로 내가 해야할 건 에이전트 입장에서 곁길이 생길만한 경로가 뭔지 고민하고, 곁길을 원천적으로 차단하는 진행구조를 만드는 것이다. 물론 그것도 혼자가 아니라 AI들과 같이 할 것이다. 정확히는 AI를 시켜가면서.