Codex에게 Zenn 기획부터 초안 작성까지 맡겨보았다

Codex를 일상적인 구현 보조뿐만 아니라, 기술 기사의 기획이나 초안 작성에도 사용할 수 있는지 시험해 보았습니다.

이 기사에서는 KijiForge에서 전달하는 입력 JSON을 전제로, Codex에게 기사의 구성, 본문, Zenn 메타데이터까지 생각하게 하는 흐름과 실제로 사용해 보며 알게 된 판단 포인트를 정리합니다.

배경

Zenn 기사를 쓸 때, 의외로 시간이 걸리는 것은 본문 그 자체보다 다음과 같은 부분입니다.

• 무엇을 쓸지 결정하기
• 어떤 순서로 설명할지 정리하기
• Zenn에 적합한 입도(Granularity)로 헤딩(Heading) 정리하기
• 타이틀, topics, 기사 타입 등의 메타데이터 결정하기
• 공개 전에 기술적인 오류나 과도한 단정이 없는지 확인하기

이번에는 다음과 같은 입력만을 Codex에 전달하여, 기사로서 성립하는 초안을 만들 수 있는지 시험했습니다.

• 독자: Zenn를 읽는 개발자
• 토픽: Codex에게 기사를 생각하게 하면 어떻게 될까
• 기존 본문: 없음, 또는 러프한 메모 정도
• Zenn 메타데이터: article type, 이모지, topics

포인트는 단순히 문장을 쓰게 하는 것이 아닙니다. KijiForge에서 Zenn로 전달하기 쉽도록, 타이틀, 본문, 메타데이터를 분리한 구조화 데이터(Structured Data)로 다룰 수 있다는 점을 중시했습니다.

구현한 워크플로우

이번 입력은 JSON으로 전달하고, Codex로부터도 JSON만을 반환하는 형태로 만들었습니다. 출력 키를 고정해 두면 앱 측의 후속 처리를 상당히 단순하게 만들 수 있습니다.

기대하는 출력은 다음 5개 항목입니다.

• title: Zenn의 타이틀 칸에 넣을 문자열
• body: Markdown 본문
• emoji: Zenn의 아이캐치(Eyecatch) 이모지
• article_type: tech 또는 idea
• topics: Zenn용 토픽 배열

특히 중요한 점은 Zenn에서는 타이틀과 본문이 별개의 필드라는 점입니다.

Markdown 기사 느낌으로 본문 시작 부분에 동일한 타이틀의 H1을 넣어버리면, Zenn 상에서는 타이틀이 중복되어 보입니다. 따라서 프롬프트(Prompt)에서는 다음과 같은 제약을 명시했습니다.

• title은 Zenn의 타이틀 입력창용으로 한다
• body의 시작 부분에 동일한 타이틀의 H1을 넣지 않는다 - Frontmatter를 넣지 않는다
• 설명문이나 Markdown 펜스(Fence)를 붙이지 않고, JSON 객체만을 반환한다

또한, topics는 Zenn의 입력창에서 다루기 쉽도록 5개 이내, 영숫자 중심, 소문자 권장으로 설정했습니다. 예를 들어 이번 경우에는 codex, ai, markdown, zenn, automation과 같은 입도입니다.

Codex에게 맡긴 판단

Codex에는 단순한 작문이 아니라, 기사로서 성립시키기 위한 판단도 맡겼습니다.

구체적으로는 다음과 같은 관점입니다.

• 독자를 개발자로 간주하여, 추상적인 감상만으로 끝나지 않게 한다
• 입력 JSON으로부터 기사 테마를 확장한다
• 구현이나 운용 시 주의할 점을 본문에 포함한다
• Zenn 기사로서 자연스러운 헤딩 구성을 만든다
• 초안화하기 쉬운 메타데이터를 제안한다
• 공개 전에 인간이 확인해야 할 항목을 남긴다

이러한 종류의 태스크에서는 처음부터 완벽한 문장을 요구하기보다, 출력 제약을 명확히 하는 편이 안정적입니다.

특히 앱 연동에서는 "JSON만을 반환한다", "불필요한 설명을 섞지 않는다", "Markdown 본문과 타이틀을 분리한다"와 같은 제약이 효과적입니다. 인간이 읽는 채팅 답변으로는 다소 무뚝뚝하더라도, 후속 처리에 전달할 데이터로서는 다루기 쉬워집니다.

사용해 본 소감

우선 편리했던 점은 백지 상태에서 구성안을 만드는 부담이 상당히 줄어든다는 것입니다.

테마만 전달해도 배경, 구현한 흐름, 사용해 본 소감, 주의점, 요약과 같이 Zenn 기사로서 읽기 쉬운 흐름을 만들 수 있습니다. 특히 글을 쓰기 시작하기 전 "무엇부터 설명할까"에서 막히지 않게 되는 점이 큽니다.

한편으로는 Codex가 생성한 문장을 그대로 공개하기보다, 마지막에 인간이 구체성을 더한다는 전제가 더 실용적이라고 느꼈습니다.

예를 들어, 다음과 같은 정보는 본인의 경험으로서 추기하는 것이 기사의 가치를 높입니다.

• 실제로 사용한 스크립트 이름
• 화면상에서 확인한 동작
• 막혔던 부분
• 실패한 프롬프트
• 수동 구현에서 조정한 조건
• Zenn 편집 화면에서 깨달은 제약

즉, Codex는 저자의 대체라기보다, 초안을 단번에 만드는 편집 보조로서 사용하는 것이 적절했습니다. 문장의 골격을 만들어 달라고 하고, 인간이 경험과 검증 결과를 더해 완성하는 역할 분담입니다.

주의점

운용한다면, 최소한 다음 사항들은 체크하는 것이 좋을 것 같습니다.

• JSON 형식이 깨지지 않았는지
• title과 body의 맨 앞 H1이 중복되지 않았는지
• Zenn의 topics로서 부자연스러운 단어가 섞여 있지 않은지
• 실재하지 않는 툴 이름이나 API 사양을 단정적으로 작성하지 않았는지
• 커맨드 (Command), 라이브러리 이름, 버전 번호가 올바른지
• 공개 전에 개인정보나 미공개 정보가 포함되어 있지 않은지

특히 기술 기사에서는 존재하지 않는 사양을 그럴싸하게 작성해 버릴 위험이 있습니다. 라이브러리 이름, API 이름, 커맨드, 버전 번호가 등장했을 경우에는 1차 정보(Primary Information)나 직접 가지고 있는 코드로 확인한 뒤에 공개하는 것이 안전합니다.

또한, Zenn용으로 초안을 작성할 경우에는 본문뿐만 아니라 메타데이터 (Metadata)도 확인 대상으로 삼는 것이 좋습니다. topics가 너무 넓으면 독자에게 전달되기 어렵고, 반대로 너무 세세하면 검색이나 분류에 도움이 되지 않습니다.

요약

Codex에게 기사를 생각하게 하면 기획, 구성, 본문, 메타데이터까지 한꺼번에 초안 작성이 가능합니다. 백지 상태에서 쓰기 시작하는 부담을 줄일 수 있는 반면, 기술적인 정확성이나 본인의 경험에 기반한 구체성은 인간이 마지막에 확인하고 보완해야 합니다.

이번처럼 입력과 출력을 JSON으로 고정해 두면, KijiForge와 같은 기사 작성 도구로부터 Zenn 초안 작성까지 연결하기 쉬워집니다.

문장 생성을 단발적인 채팅으로 끝내지 않고, 포스팅 워크플로우 (Workflow)의 일부로 다룰 수 있다는 점이 가장 큰 수확이었습니다.

Discussion