저는 AI 자동화를 매우 좋아하지만, 모든 cron 실행마다 세상의 모든 것을 담으려고 시도하는 거대한 프롬프트(giant prompts)는 신뢰하지 않습니다. 그런 프롬프트들은 처음에는 인상적으로 시작하지만, 점차 잡동사니 서랍처럼 변해갑니다. 오래된 규칙들이 남아 있고, 주제 범위가 표류하며, 작성자는 이미 구조화되어 있어야 할 기본 사항들을 다시 결정하는 데 너무 많은 노력을 소비하게 됩니다.

반복되는 작업(recurring jobs)의 경우, 저는 작성자 앞에 아주 작은 컨텍스트 빌더(context builder)를 두었을 때 더 나은 결과를 얻었습니다. 하나의 스크립트가 현재 계정, 최근 이력, 제약 조건, 그리고 몇 가지 선택된 입력값을 수집합니다. 그러면 작성자는 거대한 프롬프트 대신 그 압축된 페이로드(payload)를 바탕으로 작업합니다. 아마 덜 낭만적일지는 몰라도, 훨씬 더 유용합니다.

왜 거대한 프롬프트는 cron 작업에서 노후화되기 쉬운가

스케줄링된 워크플로우(scheduled workflow)는 그 안에 담긴 가정(assumptions)보다 더 오래 지속됩니다. 바로 여기서 문제가 시작됩니다.

처음에는 커다란 프롬프트가 유연하게 느껴집니다. 정책, 예시, 주제 목록, 그리고 폴백 규칙(fallback rules) 등을 쑤셔 넣을 수 있기 때문입니다. 하지만 한 달이 지나면, 어떤 부분이 여전히 중요한지 아무도 확실히 알지 못합니다. 일부 지침은 조용히 충돌하고, 다른 지침들은 기술적으로는 맞지만 시대에 뒤떨어진 상태가 됩니다. 실행은 여전히 "작동"하지만, 출력물은 다소 흐릿해지고 반복적인 경향을 보입니다.

이것이 제가 작고 명시적인 컨텍스트 객체(context objects)를 선호하는 이유입니다. 이 방식은 시스템이 지금 이 순간 무엇이 사실인지를 강제로 말하게 합니다:

• 어떤 계정이 활성화되어 있는가
• 어떤 주제가 범위 내에 있는가
• 어떤 내부 링크가 허용되는가
• 어떤 제약 조건이 필수 요구 사항인가
• 어떤 최근 게시물을 피해야 하는가

이는 기본적으로 자동화에서의 명확한 상태 경계(clear state boundaries in automation) 및 반복되는 작업을 위한 안정적인 백엔드 규칙(stable backend rules for repeated jobs)에서 얻은 교훈과 동일합니다. 신뢰할 수 있는 시스템은 의사결정 입력값이 거대한 텍스트 벽에 뭉뚱그려져 있는 것이 아니라, 이름이 지정되고 범위가 정해져 있을 때 더 잘 작동합니다.

컨텍스트 빌더가 생성해야 하는 것

빌더는 화려할 필요가 없습니다. 사실, 단순한 것이 보통 더 낫습니다. 저는 잘 쓰기 위해 딱 필요한 만큼의 정보만 담긴 하나의 JSON 객체를 원합니다.

콘텐츠 작업의 경우, 이는 종종 다음과 같은 의미를 갖습니다:

– 선택된 계정 및 언어
– 최근 발행 기록
– 계정에 적합한 주제 키워드
– 제목 길이 또는 태그 개수와 같은 플랫폼 제약 조건
– 미리 선택된 내부 링크
– 자연스럽게 포함될 수 있는 선택적 SEO 용어

무엇이 빠져 있는지 주목하세요: 전체 아카이브, 작성된 모든 정책, 그리고 방대한 양의 예시들입니다. 만약 작가(writer)가 매번 이 모든 것을 필요로 한다면, 시스템 설계 자체가 무언가를 알려주고 있는 것입니다.

제가 사용하는 사고 모델은 다음과 같습니다: 빌더(builder)가 놀이터를 결정하고, 작가는 그 안에서 놀기만 합니다. 이러한 분리는 예약 실행 과정의 많은 이상한 점들을 제거할 뿐만 아니라, 나중에 실패 지점을 검사하기도 더 쉽게 만듭니다.

간단한 빌드 후 작성 패턴 (A simple build then write pattern)

이 패턴은 의도적으로 지루합니다:

type WriterContext = {
  account: { username: string; language: string; topics: string[] };
  constraints: { titleMax: number; backlinkCount: number };
... 

중요한 것은 TypeScript가 아닙니다. 중요한 것은 순서입니다. 먼저 빌드 컨텍스트를 만듭니다. 계획을 고정합니다. 한 번 작성하고, 승인된 아티팩트(artifact)로부터 발행합니다. 만약 발행 단계에서 실패한다면, 두 번째 재작성을 슬쩍 끼워 넣고 아무도 알아채지 않기를 바라고는 안 됩니다. 그 경로는 빠르게 복잡해지고, 솔직히 말해서 디버깅을 상당히 귀찮게 만듭니다.

저는 또한 이 패턴이 작가를 정직하게 유지시켜 준다는 점을 좋아합니다. 소스 페이로드(payload)가 작으면, 출력 뒤에 숨겨진 실제 레버리지(levers)를 볼 수 있습니다. 기사가 프롬프트가 거대하기 때문에 '똑똑한' 것이 아닙니다. 입력값이 세심하게 다듬어졌기 때문에 유용한 것입니다.

임시 이메일 워크플로우의 적합성 (Where temporary email workflows fit)

이것은 발행 시스템에만 국한된 이야기가 아닙니다. 동일한 패턴은 가입 테스트, 받은 편지함 확인, 그리고 임시 이메일 흐름(temporary email flow)이 작업의 일부인 미리 보기 환경에서도 나타납니다.

예를 들어, 당신의 자동화(automation)가 인증을 위해 tempmail.so 편지함(inbox)을 필요로 한다고 가정해 봅시다. 빌더(builder)는 이 실행(run)에 어떤 편지함 규칙(inbox rule), 타임아웃(timeout), 그리고 환경 레이블(environment label)이 적용될지 결정할 수 있습니다. 작성자(writer)나 실행자(executor)가 산문(prose)으로부터 이를 다시 찾아내서는 안 됩니다. 팀이 로그에서 볼 수 있는 'dummy e mail'이나 'temp mailid'와 같은 소음이 섞인 검색어(search terms)도 마찬가지입니다. 이러한 문자열들은 관련 컨텍스트(context)가 될 수 있지만, 거대한 프롬프트(prompt) 안에 숨겨진 잊혀진 파편이 아니라 명시적인 필드(explicit fields)로서 실행에 입력되어야 합니다.

이러한 차이는 작게 들릴 수 있지만, 팀이 일하는 방식을 변화시킵니다. 사람들은 자동화를 신비로운 블랙박스(black box)처럼 취급하는 것을 멈추고, 이름이 지정된 입력값(named inputs)을 가진 파이프라인(pipeline)처럼 취급하기 시작합니다. 마법은 줄어들고, 레버리지(leverage)는 늘어납니다. 저는 이것이 꽤 괜찮은 거래라고 생각합니다.

Q&A

이것이 프롬프트(prompts)를 너무 경직되게 만드나요?

그렇지는 않습니다. 이것은 런타임 사실(runtime facts)을 명시적으로 만듭니다. 컨텍스트 빌더(context builder) 외부에 안정적인 작성 가이드(writing guide)를 여전히 유지할 수 있습니다. 핵심은 변하지 않는 가이드(evergreen guidance)와 실행 시점의 결정 사항(per-run decisions)을 섞지 않는 것입니다.

컨텍스트(context)는 얼마나 작아야 하나요?

사람이 1분 이내에 훑어볼 수 있을 정도로 충분히 작아야 합니다. 만약 JSON이 소설처럼 느껴진다면, 내용을 줄이세요. 만약 중요한 선택 사항이 누락되었다면, 오직 그것들만 추가하세요.

빌더(builder)가 기사(article)도 작성해야 하나요?

저는 그것을 피하겠습니다. 한 단계가 입력(inputs)을 수집하는 동시에 출력(output)까지 작성하게 되면, 각 부분을 깔끔하게 테스트하기가 더 어려워집니다. 역할이 분리된 것이 조금은 덜 화려해 보일 수 있지만, 몇 주간의 크론 작업(cron runs) 이후에는 훨씬 더 신뢰하기 쉽습니다.