제 블로그는 AI 두 개가 나눠서 굴립니다. 하나는 글을 쓰는 AI(개발 일지를 블로그 초안으로 가공), 다른 하나는 발행하는 AI(그 초안을 워드프레스에 올림). 사람으로 치면 원고 쓰는 사람과 편집·출판하는 사람을 따로 둔 셈이죠.
여기서 자연스러운 질문이 생깁니다. 둘을 어떻게 잇지? 글 쓰는 AI가 “이거 발행해줘” 하고 발행 AI한테 말을 걸면 될 것 같지만 — 안 됩니다. 이 둘은 서로의 대화창을 볼 수 없거든요. 각자 다른 방에서 일하는 겁니다.
문제: 두 AI는 서로 대화를 못 읽는다
처음엔 이걸 제가 몸으로 때웠습니다. 글 쓰는 AI가 초안을 만들면, 제가 그 제목과 주소(슬러그), 카테고리를 손으로 받아 적어서 발행 AI한테 넘겼어요. 매번요.
이게 왜 문제냐면, 그 정보가 대화창에만 있었기 때문입니다. 글 쓰는 AI와 제가 나눈 대화 속에 “이 글 제목은 이거, 카테고리는 오답노트”가 다 있는데, 발행 AI는 그 대화를 못 봅니다. 그러니 제가 매번 통역사처럼 정보를 옮겨 나른 거죠. 글이 한두 편일 땐 괜찮은데, 스무 편 서른 편이 되면 이 나르기만 계속 늘어납니다.
슬러그(slug): 글의 인터넷 주소 끝부분. 예를 들어
woodpecker-ai.com/first-post에서first-post가 슬러그입니다. 사람이 읽기 좋고 검색에도 쓰이니 아무렇게나 두면 안 됩니다.
해결: 정보를 대화가 아니라 ‘파일’에 담는다
답은 의외로 단순했습니다. 대화창에 있던 정보를 파일 맨 위에 적어두면 됩니다. 그러면 발행 AI가 그 파일만 열어봐도 제목·슬러그·카테고리를 다 알 수 있죠. 저를 거칠 필요가 없어집니다.
그 “파일 맨 위 정보”를 frontmatter라고 부릅니다.
frontmatter: 글 파일 맨 위에
---선으로 감싸 적어두는 메타 정보(제목·주소·분류 같은 것). 본문은 아니지만, 프로그램이 그 글을 어떻게 다룰지 판단하는 데 쓰입니다.
제 초안 파일은 이제 이렇게 시작합니다.
---
title: "글 제목"
slug: connect-two-ai-agents-handoff
category: 개발 셋업
---
이걸 저는 핸드오프 계약이라고 부릅니다. 계약이라는 말이 딱 맞아요. 글 쓰는 AI는 “나는 이 형식으로 정보를 채워서 넘기겠다”고 약속하고, 발행 AI는 “나는 이 형식이 있다고 믿고 읽겠다”고 약속하는 거죠. 서로 얼굴 한 번 안 봐도, 계약서만 지키면 일이 굴러갑니다. 릴레이 경주에서 앞 주자와 뒤 주자가 눈을 안 마주쳐도 배턴만 제대로 넘어가면 되는 것과 같습니다.
계약에 숨은 안전장치: “없으면 건너뛴다”
계약에는 규칙이 하나 더 있습니다. frontmatter가 없는 파일은 발행 AI가 무조건 건너뛴다.
처음엔 이게 좀 이상하게 들렸어요. 왜 그냥 다 발행하지 않고 건너뛰지? 이유가 있습니다. 제 폴더에는 예전에 다른 방식으로 만든 옛날 초안들이 섞여 있거든요. 그것까지 발행 AI가 집어서 올리면 같은 내용이 중복으로 올라갑니다. 그리고 중복 콘텐츠는 블로그 평가에 해로워요(예전에 이것 때문에 광고 승인에서 떨어진 적도 있습니다).
그래서 “frontmatter 있는 것만 발행 대상”이라는 규칙이 자동 필터가 됩니다. 새 계약을 지킨 글만 통과하고, 옛날 것들은 자동으로 걸러지죠. 규칙 하나가 실수를 원천 차단하는 셈입니다.
실제로 밟은 함정: 이미지가 경계를 넘으면 깨진다
계약을 만들고 실제 경로를 코드로 점검하다가, 함정을 하나 잡았습니다. 본문에 넣은 이미지가 발행하면 깨지는 문제였어요.
원인은 상대경로였습니다. 초안 본문에 이미지를 shots/그림.png처럼 적어뒀는데, 이건 “지금 이 파일을 기준으로 shots 폴더 안”이라는 뜻입니다. 문제는 그 이미지 파일이 초안 옆에 있는 게 아니라 다른 폴더(개발 일지 쪽)에 있었다는 거예요. 글 쓰는 AI가 있는 자리에선 그 상대경로가 맞았지만, 발행 AI가 초안 옆에서 shots/그림.png를 찾으면 거기엔 그림이 없습니다. 그러니 발행된 글에서 이미지가 깨지죠.
상대경로 vs 절대경로: 상대경로는 “지금 내 위치에서 몇 칸 옆”이라는 식의 주소(
shots/그림.png). 절대경로는 “이 컴퓨터의 정확히 이 자리”라는 완전한 주소. 상대경로는 짧고 편하지만, 기준 위치가 바뀌면 엉뚱한 곳을 가리킵니다.
해결은 “그림이 실제로 어디 있는지”를 발행 AI가 알 수 있게 규칙으로 못 박는 것이었습니다. frontmatter에 이미 프로젝트 이름이 적혀 있으니, 그걸 기준으로 진짜 이미지 폴더를 찾아가게 했어요. 경계를 넘는 순간 상대경로는 못 믿는다 — 이게 이번 함정의 교훈입니다.
왜 굳이 AI를 둘로 나눴나
여기까지 읽고 “그냥 하나의 AI가 쓰고 발행까지 다 하면 안 되나?” 싶으실 수 있어요. 나눈 데는 이유가 있습니다. 보안입니다.
발행을 하려면 블로그에 로그인할 열쇠(비밀번호·토큰)가 필요합니다. 그런데 글 쓰는 AI는 제 개발 일지를 통째로 읽는 녀석이에요. 그런 녀석한테 발행 열쇠까지 쥐여주고 싶진 않았습니다. 그래서 글 쓰는 쪽은 열쇠를 아예 갖지 않고(파일만 만들고), 발행하는 쪽만 열쇠를 갖게 나눴어요.
토큰(token): 사람의 비밀번호 대신 프로그램이 서비스에 로그인할 때 쓰는 열쇠 문자열. 새어 나가면 남이 내 계정을 조작할 수 있어 조심히 다뤄야 합니다.
역할을 나누니 열쇠를 가진 쪽이 좁아지고, 관리할 위험도 그만큼 줄었습니다.
그래서 뭘 배웠나
| 상황 | 잘못된 접근 | 맞는 접근 |
|---|---|---|
| 두 AI(도구)를 잇기 | 서로 대화로 넘겨주기(못 읽음) | 🟢 파일(frontmatter)에 담아 넘기기 |
| 옛날 파일 섞임 | 다 발행 → 중복 | 🟢 “계약 지킨 것만” 자동 필터 |
| 이미지 경로 | 상대경로 그대로 | 🟢 경계 넘으면 절대 위치로 해소 |
| 발행 열쇠 | 모든 AI에 공유 | 🟢 발행하는 쪽만 보유 |
한 문장 요약: 서로 대화를 못 읽는 두 AI(도구)를 이을 때는, 말로 넘기지 말고 ‘파일에 담긴 계약’으로 넘겨라.
이 원리는 AI끼리만이 아니라 서로 직접 대화 못 하는 두 프로그램을 이을 때 두루 통합니다. 한쪽이 약속된 형식으로 파일을 남기고, 다른 쪽이 그 약속을 믿고 읽는 것 — 규칙 몇 줄이 사람의 반복 수작업을 없애줍니다. 저처럼 도구를 여러 개 엮어 뭔가를 자동화해보려는 분이라면, “이 둘이 서로 볼 수 있나?”를 먼저 물어보세요. 못 본다면, 답은 대화가 아니라 계약입니다.