지시랑 입력은 분리된 채로

"매크로는 재사용 지시 + 오늘 입력을 넣을 슬롯이야. 둘을 하나의 문자열로 흐리면, 재사용 가능하게 만든 그것을 잃은 거야."

매크로가 실제로 뭔가

prompt macro 는 저장된, 재사용 프롬프트야 — '이거 한국어로 번역해', '이거 세 불릿으로 요약해', '이 그림 구도 비평해'. 근데 매크로가 유용한 건 뚜렷하게 남는 두 부분이 있어서야: 지시(저장한 재사용 부분)랑 입력(지금 적용하는 구체적 내용). 지시는 템플릿; 입력은 슬롯을 채우는 것. 둘을 분리해 두는 게, 지시를 한 번 저장하고 백 개 다른 입력에 재사용하게 해줘.

왜 합치면 매크로가 썩나

게으른 구현은 일찍 이어붙여: instruction + "\n" + input, 하나의 blob 으로 저장하고 보내. 데모에선 되고 조용히 썩어:

지시를 더 이상 편집 못 해. 입력이랑 융합되면, 재사용 프롬프트를 바꾸는 게 첫 번째 붙었던 아무 내용에서 그걸 풀어내는 일이 돼.
깔끔하게 다시 적용 못 해. 핵심 — 같은 지시, 새 입력 — 은 지시가 어느 한 입력이랑 독립으로 존재해야 해. 융합되면, 안 그래.
경계가 모호해져. 지시가 어디서 끝나고 입력이 어디서 시작해? 뒤섞인 문자열 하나를 읽는 모델은 추측해야 하고, 그 경계의 추측이 prompt-injection 이랑 오해가 사는 데야.

이음매를 명시적으로 유지하라

매크로를 이름 붙은 부분들 — 지시 필드랑 입력 필드 — 을 가진 구조로 모델링하고, 문자열 join 이 아니라 요청 포맷이 그 구분을 나르게 해서 보내기 직전까지 분리해 둬. 이러면 지시가 독립적으로 편집 가능하게 남고(어떤 입력도 안 건드리고 템플릿 바꾸기), 재사용이 사소해지고(입력 갈고, 지시 유지), 경계가 사용자랑 모델 둘 다한테 읽기 쉽게 남아. '재사용되는 것'이랑 '오늘의 것' 사이 이음매가 매크로의 가치 전부야; 데이터 모델에 보존해, 문자열로 녹이지 마.

Code

이름 붙은 두 부분, 경계까지 분리·typescript

// 매크로는 미리 이어붙인 문자열이 아니라 구조야.
type PromptMacro = {
  id: string;
  name: string;
  instruction: string;   // 재사용 템플릿 — 독립적으로 편집
};

// 사용 시점에, 지시랑 입력이 요청의 뚜렷한 부분으로 남아.
function buildMacroCall(macro: PromptMacro, input: string, images: ResolvedImage[]) {
  return {
    instruction: macro.instruction, // 재사용
    input,                           // 오늘의 내용 — 별개 슬롯
    images,
  };
}

// 틀림: `const prompt = macro.instruction + "\n" + input;`
// 일찍 융합하면 편집성, 재사용, 읽기 쉬운 경계를 파괴해.

Exercise

자주 쓰는 재사용 프롬프트를 하나 골라(번역, 요약, 리뷰 루브릭). 두 방식으로 써: 한 번은 입력을 이어붙인 단일 문자열로, 한 번은 별개 지시 필드랑 입력 필드를 가진 구조로. 이제 각각에서 '지시를 편집'해봐. 이어붙인 버전은 입력 경계를 찾아 보존하게 강제하는데, 구조 버전은 템플릿을 자유롭게 편집하게 해주는 걸 봐.

Hint

구조 버전은 '지시 바꾸고, 새 입력들에 계속 적용'을 한 필드 편집으로 만들어. 이어붙인 버전은 매번 풀어내기 연습으로 만들어 — 그래서 진짜 매크로 시스템은 두 부분을 저장이랑 wire 에서 분리해 둬.