당신의 프롬프트 템플릿이 당신을 속이고 있습니다 (그리고 매주 몇 시간을 낭비하게 만듭니다)

지난 화요일, 저는 그 주에만 다섯 번째로 동일한 컨텍스트 블록(context block)을 다시 작성하는 데 47분을 소비했습니다. 작업은 달랐지만 문제는 같았습니다. 저는 제 코드베이스 구조, 선호하는 출력 형식(output format), 팀의 명명 규칙(naming conventions), 그리고 문제의 구체적인 제약 조건들을 빈 채팅창에 처음부터 다시 수동으로 설명하고 있었습니다. LLM은 충분히 똑똑합니다. 병목 현상은 바로 저였습니다. Notion에서 조각들을 복사하여 붙여넣고, 수정하고, 변수 하나를 업데이트하는 것을 잊어버려 쓰레기 같은 결과물(garbage output)을 얻고, 다시 처음부터 시작하는 과정 말입니다. 그 순간 저는 프롬프트를 일회성 메시지처럼 취급하는 것을 멈추고, 소프트웨어 산출물(software artifacts)처럼 취급하기 시작했습니다. 구조화된 프롬프트 템플릿(prompt templates)을 중심으로 전체 일일 워크플로우(daily workflow)를 재구축한 후 제가 발견한 것은 제가 결과물을 내놓는 속도를 근본적으로 변화시켰습니다.

당신의 임시(Ad-Hoc) 프롬프트가 실패하는 진짜 이유

AI에 진심인 대부분의 개발자들은 사물을 어떻게 표현할지에 대한 느슨한 정신적 모델인 "프롬프팅 스타일(prompting style)"을 가지고 있습니다. 그들은 가이드를 읽었고, 생각의 사슬(chain-of-thought)을 사용하며, 시스템 역할(system role)을 추가합니다. 하지만 그들은 여전히 모든 새로운 작업에 대해 새로운 프롬프트를 작성하고 있으며, 이는 매번 처음부터 컴파일하고 있다는 의미와 같습니다.

실패 모드(failure mode)는 품질의 문제가 아니라 변동성(variance)의 문제입니다. 임시(Ad-hoc) 프롬프트가 일관되지 않은 출력(output)을 생성하는 이유는 모델이 신뢰할 수 없어서가 아니라, 당신의 입력(input)이 일관되지 않기 때문입니다. 월요일에 표현한 컨텍스트(context)와 금요일에 표현한 컨텍스트가 약간 다릅니다. 서두르다 보면 출력 스키마(output schema)를 지정하는 것을 잊어버립니다. 제약 조건 스택(constraint stack)을 다른 순서로 설명하면 모델은 이를 다르게 가중치(weights)를 둡니다.

당신의 머릿속에만 존재하는 프롬프트는 버전 관리(unversioned)가 되지 않고 문서화(undocumented)되지 않은 코드와 같습니다. 배포할 때마다 기억에 의존해 새로 작성한 함수를 배포하지는 않을 것입니다. 프롬프트도 그렇게 하지 마십시오.

진짜 프롬프트 템플릿이 실제로 포함하는 것

프롬프트 템플릿은 단순히 {{task}}가 끼워져 있는 빈칸 채우기용 문자열이 아닙니다. 그것은 프롬프트 스텁(prompt stub)일 뿐입니다. 진짜 템플릿은 네 가지 레이어(layers)를 가지고 있습니다:

1. 지속적 문맥 (Persistent context) — 당신이 누구인지, 어떤 시스템에서 작동하고 있는지, 모델이 항상 알고 있어야 하는 것이 무엇인지입니다. 이는 호출(invocation)마다 바뀌지 않습니다. 당신의 기술 스택, 관례(conventions), 역할 등이 여기에 해당합니다. 한 번만 작성하고 반복을 멈추세요.

2. 작업 프레임 (Task frame) — 구체적인 작업이 아닌, 작업의 유형입니다. "가독성을 위한 리팩토링(Refactor)", "기술 명세서(technical spec) 초안 작성", "이 트레이스(trace) 디버깅" 등이 해당합니다. 이는 구체적인 내용을 전달하기 전에 모델의 모드(mode)를 설정합니다.

3. 동적 슬롯 (Dynamic slots) — 실제 가변 입력값입니다: 코드 스니펫(code snippet), 에러 로그(error log), 기능 개요(feature brief) 등이 해당합니다. 동일한 템플릿을 호출할 때 바뀌어야 하는 유일한 요소들입니다.

4. 출력 계약 (Output contract) — 결과물로 무엇을 원하는지 명시적으로 기술합니다: 형식(format), 길이, 생략할 내용 등입니다. 이를 지정하지 않으면, 모델은 당신의 파이프라인(pipeline) 다음 단계에 유용한 결과물이 아니라, 그저 도움이 되어 보이는 결과물을 내놓도록 최적화됩니다.

대부분의 사람들은 3번 레이어만 가지고 있습니다. 1, 2, 4번 레이어를 일관되게 갖춘 사람은 거의 없습니다. 그것이 바로 격차(gap)입니다.

우선적으로 구축할 가치가 있는 템플릿들

40개의 템플릿을 만들지 마세요. 실제 워크플로우의 80%를 커버하는 훌륭한 5개를 만드세요. 개발자와 빌더(builders)를 위한 핵심 목록은 다음과 같습니다:

코드 리뷰 템플릿 (Code review template) — 지속적 문맥에는 당신의 스타일 가이드와 언어가 포함됩니다. 작업 프레임은 항상 "문제를 식별하되, 요청받지 않는 한 재작성을 제안하지 말 것"입니다. 출력 계약은 심각도 태그(severity tags)가 포함된 번호 매기기 목록입니다. 이것만으로도 리뷰 과정의 불필요한 대화를 절반으로 줄일 수 있습니다.

버그 트리아지 템플릿 (Bug triage template) — 스택 트레이스(stack trace), 기대 동작 대비 실제 동작에 대한 설명, 관련 환경 정보(env info)를 개별 슬롯으로 받아들이도록 구조화합니다. 이는 프롬프트를 작성하기 전에 실제로 해당 정보를 수집하도록 강제하며, 이는 어차피 디버깅 작업의 절반을 차지하는 일입니다.

명세서 초안 작성 템플릿 (Spec drafting template) — 지속적 문맥에는 제품의 사용자 페르소나(user personas)와 기술적 제약 사항이 포함됩니다. 작업 프레임은 "내일 이것을 구현할 엔지니어를 위해 작성할 것"입니다. 출력 계약은 필요한 섹션(문제, 비목표(non-goals), 성공 기준, 미결 질문)을 명시합니다. 더 이상 블로그 포스트처럼 읽히는 명세서는 없을 것입니다.

회의/스레드 요약 템플릿 (Meeting/thread summary template) — 비동기적 맥락 (async context)을 위해 구축되었습니다: Slack 스레드나 회의 녹취록을 붙여넣으면, 팀 전체가 인식할 수 있는 일관된 형식의 결정 로그 (decision log)와 실행 항목 (action item) 목록을 얻을 수 있습니다.

리서치 합성 템플릿 (Research synthesis template) — 5개의 소스를 읽고 자신의 입장을 정리해야 할 때 사용합니다. 작업 프레임 (Task frame)은 "모순점을 식별하고, 불확실한 부분을 강조하며, 뉘앙스를 뭉뚱그리지 말 것"입니다. 결과물은 요약된 문단이 아니라 구조화된 브리프 (brief)입니다.

프레임워크: 템플릿 적합성 테스트 (Template Fitness Test)

어떤 프롬프트 템플릿 (prompt template)이라도 최종 확정하기 전에 이 체크리스트를 통해 검토하십시오. 하나라도 통과하지 못한다면 아직 준비되지 않은 것입니다.

프롬프트 템플릿 적합성 테스트 (PROMPT TEMPLATE FITNESS TEST)
─────────────────────────────────────────────
[ ] 지속적인 맥락 (Persistent context)이 안정적인가 — 시스템이 변경될 경우, 단 한 곳만 업데이트하면 되는가
...

마지막 두 가지 체크 항목은 팀들이 지속적으로 실패하는 지점입니다. 버전 관리 (versioned)가 되지 않는 템플릿은 눈에 보이지 않게 표류합니다. 어느 화요일에 문구를 살짝 수정했는데, 2주 뒤에는 왜 결과물이 바뀌었는지 설명할 수 없게 됩니다. 템플릿을 설정 파일 (config files)처럼 취급하십시오. 커밋 메시지 (commit messages)와 함께 버전 관리 시스템 (version control)에 포함되어야 합니다.

구성(Composition)에서 흥미로운 지점이 발생합니다

단일 템플릿도 유용합니다. 하지만 구성된 템플릿 체인 (composed template chains)에서 레버리지 (leverage)가 복리로 작용합니다.

실제 워크플로 (workflow)를 예로 들어보겠습니다: 당신은 새로운 API 엔드포인트 (endpoint)를 구축하고 있습니다. 템플릿 1은 기능 개요 (feature brief)로부터 명세서 초안 (spec draft)을 생성합니다. 템플릿 2는 해당 명세서를 가져와 테스트 계획 (test plan)을 생성합니다. 템플릿 3은 테스트 계획을 가져와 스텁 구현 (stub implementations)을 생성합니다. 각 결과물은 다음 템플릿을 위한 동적 슬롯 입력 (dynamic slot input)이 됩니다. 당신이 인수인계 (handoffs) 과정을 명시적으로 구조화했기 때문에 모델은 맥락을 결코 놓치지 않습니다.

이것이 사람들이 "AI 워크플로 (AI workflows)"에 대해 말할 때 의미하는 바입니다. 마법 같은 자동화가 아니라, 각 단계가 정의된 입력 스키마 (input schema)와 다음 단계가 의존하는 출력 계약 (output contract)을 갖는 구조화된 프롬프트의 의도적인 시퀀싱 (sequencing)을 의미합니다.

여기서 발생하는 실패 모드(failure mode)는 스키마 불일치(schema mismatch)입니다. 템플릿 1의 출력 형식이 템플릿 2가 기대하는 입력 형식에 깔끔하게 들어맞지 않는 것입니다. 템플릿들이 서로 다른 Notion 페이지, 서로 다른 시스템 프롬프트(system prompts), 서로 다른 채팅창에 흩어져 있을 때 이를 수정하는 작업은 매우 지루합니다. 실제 업무를 수행하는 시간보다 자신의 템플릿들 사이를 번역하는 데 더 많은 시간을 쓰게 됩니다.

이것이 바로 제가 계속해서 마주쳤던 문제이며, 제가 해결책을 만들고 있는 이유입니다.

AI Handler가 이 문제에 접근하는 방식

제가 이 문제에 대해 진지하게 고민하기 시작했을 때, 문제는 템플릿을 작성하기 어렵다는 것이 아니었습니다. 문제는 시스템으로서 템플릿을 '관리(manage)'하는 것이 불가능하다는 점이었습니다. 템플릿들은 너무 많은 곳에 존재했고, 공유된 컨텍스트 레이어(context layer)가 없었으며, 수동으로 이어 붙이지 않고서는 체이닝(chaining)할 수 없었고, 버전 기록(version history)도 전혀 없었습니다.

AI Handler는 단 하나의 기본 단위(primitive)인 **워크플로(workflow)**를 중심으로 구축되었습니다. 워크플로는 명시적인 입출력 스키마(input/output schemas)를 가진, 버전 관리가 가능하고 조합 가능한 프롬프트 템플릿의 체인(chain)입니다. 복사해서 쓸 프롬프트 조각들을 Notion 데이터베이스에 유지 관리하는 대신, 지속적인 컨텍스트(persistent context)를 한 번 정의하고 이를 모든 템플릿에 부착하며, 출력 스키마가 입력 슬롯(input slots)과 자동으로 일치하는 파이프라인(pipelines)으로 템플릿을 구성합니다.

모델 불가지론적(model-agnostic) 레이어 덕분에, 매번 컨텍스트 블록을 다시 작성할 필요 없이 동일한 워크플로를 GPT-4o, Claude, Gemini 등에 대해 실행할 수 있습니다. 특정 제공업체의 특이한 방식에 종속되지 않고, 현재 해당 작업 유형에 대해 가장 좋은 출력을 생성하는 모델을 대상으로 템플릿을 실행할 수 있습니다.

버전 관리(version control) 레이어 덕분에 템플릿을 수정할 때마다 이전 버전이 스냅샷(snapshot)으로 저장됩니다. 코드를 비교(diff)하는 것과 동일한 방식으로 템플릿 버전을 비교할 수 있습니다. 출력 품질이 저하되면, 그 원인이 된 템플릿 변경 사항을 직접 이분 탐색(bisect)하여 찾아낼 수 있습니다.

또한 저는 공유 컨텍스트 저장소(shared context store)를 구축하고 있습니다. 이는

이것은 솔직한 빌드 인 퍼블릭 (build-in-public) 영역입니다. 핵심 워크플로 엔진 (workflow engine)은 작동 중이며, 컨텍스트 저장소 (context store)는 활발히 개발 중이고, 버전 관리 레이어 (versioning layer)는 설계되었으나 아직 완전히 출시되지는 않았습니다. 저는 2026년 6월을 공개 출시 목표로 잡고 있습니다.

만약 당신이 이 글을 읽으며 고장 난 부분들에서 자신의 워크플로를 '인지'하고 좌절감을 느끼는 종류의 사람이라면, 바로 그런 분들을 위해 제가 이것을 만들고 있는 것입니다.

AI Handler는 제가 구축하고 있는 통합 AI 워크플로 (AI workflow) 도구입니다. 2026년 6월 출시 예정. 베타 액세스 권한을 원하시면 ceo@eternalsix.com으로 이메일을 보내주세요.