400개의 프롬프트 라이브러리를 구축했지만, 그중 12개 정도만 사용했다

프롬프트 라이브러리를 구축한 지 6개월이 지났을 때, 나는 11개의 폴더에 걸쳐 412개의 프롬프트를 보유하고 있었고, 민망할 정도로 많은 시간을 들여 설계한 색상 코드 시스템과 "창의적(creative)", "기술적(technical)", "기타(misc)"와 같은 태그가 달린 Notion 데이터베이스를 가지고 있었다. 그런데 생각해보니, 이는 결국 두 개의 카테고리만 있었다는 뜻이었다. 나는 매일 빈 ChatGPT 창을 열고 매번 처음부터 타이핑을 하고 있었다. 라이브러리는 내가 결코 방문하지 않는 박물관이었다.

실수 #1: 트리거(Triggers) 대신 주제(Topics)를 중심으로 정리하기

나의 첫 번째 본능은 서류 보관함을 정리하듯 주제별로 프롬프트를 정리하는 것이었다. 여기에는 글쓰기 프롬프트, 저기에는 코딩 프롬프트, 세 번째 더미에는 연구 프롬프트를 두는 식이었다. 이는 논리적으로는 말이 되었지만, 실제로는 완전히 쓸모가 없었다.

문제는 프롬프트가 필요할 때, 당신이 "글쓰기 프롬프트가 필요해"라고 생각하지 않는다는 점이다. 당신은 "앞으로 10분 안에 이 엉망인 불렛 포인트 목록을 이해관계자용 이메일로 바꿔야 해"라고 생각한다. 당신을 프롬프트 라이브러리로 이끄는 정신적 모델(Mental model)은 카테고리가 아니라 상황이다.

나는 모든 것을 트리거(Triggers), 즉 내가 프롬프트를 찾게 만드는 구체적인 맥락을 중심으로 다시 구축했다. "글쓰기"가 아니라 "거친 메모가 있고 빠르게 다듬어진 초안이 필요함"이다. "연구"가 아니라 "전혀 모르는 주제를 시작해야 하며 빠른 기초 지식이 필요함"이다. "코딩"이 아니라 "버그가 발생했고 너무 오래 들여다보고 있음"이다.

트리거 기반의 정리 방식으로 전환했을 때, 나의 사용률은 거의 0에서 실제로 추적할 수 있는 수준으로 올라갔다. 2초 만에 찾을 수 있는 프롬프트 하나가, 찾아 헤매야 하는 프롬프트 10개보다 가치 있다.

실수 #2: 그 순간을 위해, 그 순간에 프롬프트 작성하기

좋은 프롬프트 상호작용을 할 때마다, 나는 그 프롬프트를 복사해서 라이브러리에 붙여넣었다. 효율적인 것처럼 보였다. 하지만 그것은 사실 그저 수집(Hoarding)에 불과했다.

그 순간 즉흥적으로 작성된 프롬프트는 재사용하기에는 너무 구체적입니다. 프로젝트 이름, 특정 대상(Audience), 문구의 형식을 결정지었던 마감 기한의 압박 등 한때는 유효했던 맥락(Context)을 포함하고 있기 때문입니다. 나중에 다시 그 프롬프트들을 확인했을 때, 이를 수정하기 위해서는 다시 읽고 머릿속에서 그 맥락을 제거하는 데 2분 정도를 소비해야 했습니다. 그 시점에는 차라리 새로 작성하는 편이 나을 정도였습니다.

해결책은 저장하기 전에 한 단계를 더 추가하는 것이었습니다. 바로 추상화(Abstract)하는 것입니다. 성공적인 프롬프트를 가져와서 그것이 나타내는 '패턴(Pattern)'을 식별하고, 명시적인 변수(Variables)를 포함한 템플릿(Template)으로 다시 작성하는 것입니다. [AUDIENCE], [GOAL], [CONSTRAINT]와 같이 말이죠. 네, 3분 정도의 시간이 더 걸립니다. 하지만 그 3분은 향후 모든 사용 과정에서 복리로 쌓이게 됩니다.

이제 제 라이브러리에서 가장 훌륭한 프롬프트들은 명확한 입력값(Inputs)과 예측 가능한 출력값(Outputs)을 가진 작은 프로그램처럼 읽힙니다. 보기에는 약간 투박할지 몰라도, 배포(Deploy)하기에는 매우 빠릅니다.

실수 #3: 모든 프롬프트를 보관할 가치가 있다고 여기는 것

저에게는 프롬프트 공동묘지가 있었습니다. 한 번 사용하고 괜찮은 결과를 얻은 뒤 다시는 손대지 않은 프롬프트들, 더 이상 사용하지 않는 도구들을 위한 프롬프트들, 그리고 결코 실현되지 않을 사용 사례를 위해 "만약을 대비해" 저장해 둔 프롬프트들이었습니다.

이 공동묘지는 실제적인 비용을 발생시켰습니다. 라이브러리를 스크롤할 때마다 관련 없는 수십 개의 항목을 처리해야 했습니다. 저품질 프롬프트로 구성된 대규모 라이브러리를 관리하는 인지 부하(Cognitive load)가 라이브러리를 보유함으로써 얻는 가치를 넘어섰습니다.

저는 잔혹한 규칙을 적용하기 시작했습니다. 프롬프트가 최소 세 번 이상 사용되었거나, 매달 마주치는 문제를 해결하는 것이 아니라면 남겨두지 않는 것입니다. 그 외의 모든 것은 보관(Archive)하는 것이 아니라 삭제(Delete)합니다. 보관한다는 것은 나중에 다시 보겠다는 뜻인데, 여러분은 다시 보지 않을 것입니다. 그냥 삭제하세요.

제 라이브러리는 400개 이상의 항목에서 64개로 줄었습니다. 하지만 사용량은 줄어들기는커녕 오히려 늘어났습니다. 살아남은 프롬프트들은 실제로 제 업무를 수행하고 있는 것들이었습니다.

실수 #4: 프롬프트 노후화(Prompt Decay)를 무시하는 것

이 실수는 제 실제 시간을 낭비하게 만들었습니다. 특정 형식에서 구조화된 데이터 (Structured Data)를 추출하기 위해 작성한 프롬프트가 4개월 동안은 완벽하게 작동하다가, 어느 순간부터 일관되지 않은 결과를 내놓기 시작했습니다. 저는 제 잘못이라 생각했습니다. 입력값을 바꿔보고, 표현을 다르게 시도해 보며 좌절했습니다. 제가 사용하던 모델이 업데이트되었고, 응답 형식에 대한 기존 프롬프트의 가정이 구식이 되었다는 사실을 깨닫는 데 2주가 걸렸습니다.

프롬프트는 노후화 (Prompt Decay)됩니다. 모델은 변하고, API는 업데이트되며, 여러분 자신의 유스케이스 (Use Case)도 진화합니다. 유지보수 루프 (Maintenance Loop)가 없는 프롬프트 라이브러리는 당신에게 조용히 거짓말을 하기 시작하는 라이브러리일 뿐입니다.

이제 저는 모든 프롬프트에 검토 날짜를 지정합니다. 기본적으로는 3개월 뒤로 설정하고, 특정 모델 버전이나 API 동작에 영향을 받는 것은 1개월로 설정합니다. 이는 혼란스러운 디버깅 (Debugging)에 소요될 수 있는 수 시간을 아껴주는 5분짜리 캘린더 알림입니다. 알림이 울리면, 저는 2분 동안 테스트 케이스에 프롬프트를 실행해 보고 출력이 여전히 기대치와 일치하는지 확인합니다. 대부분의 경우 별문제가 없지만, 가끔은 이 과정이 엉망이 될 뻔한 하루를 구해줍니다.

실수 #5: 워크플로우 (Workflow)가 아닌 나 자신을 위해 구축하는 것

가장 뼈아픈 실수: 저는 프롬프트 라이브러리를 워크플로우 시스템이 아닌 저장 시스템으로 구축했습니다. 저는 잘못된 문제를 풀고 있었습니다. 진짜 마찰 (Friction)은 프롬프트를 찾는 것이 아니라, 프롬프트와 제가 실제로 작업 중인 도구 사이의 거리였습니다.

잘 정리된 라이브러리가 있더라도 제 워크플로우는 다음과 같았습니다: 필요 사항 생각하기 → 브라우저 탭 열기 → 라이브러리로 이동 → 프롬프트 찾기 → 복사 → AI 도구로 전환 → 붙여넣기 → 컨텍스트 (Context) 추가 → 실행. 이는 세 번의 컨텍스트 스위칭 (Context Switch)을 포함한 7단계의 과정이었습니다. 제가 결국 처음부터 직접 타이핑하는 방식을 택하게 된 것도 당연했습니다.

워크플로우 외부에 존재하는 프롬프트 라이브러리는 사용되지 않는 라이브러리입니다. 저장 문제는 쉽습니다. 통합 (Integration) 문제가 바로 대부분의 사람들이 구축을 멈추는 지점입니다.

실제로 작동하는 프레임워크: TVAR

이 모든 과정을 거친 후, 저는 제가 보관하는 모든 프롬프트에 대해 네 가지 부분으로 구성된 구조를 정착시켰습니다:

T — Trigger (트리거): 한 문장으로 작성합니다. 정확히 어떤 상황에서 이 프롬프트를 찾게 되는지를 기술합니다. "~가 필요할 때..."와 같은 형식으로 작성합니다. 카테고리가 아니라, 특정한 순간을 정의해야 합니다.

V — Variables (변수): 이 프롬프트를 사용할 때마다 바뀌는 요소들을 명시적인 목록으로 작성합니다. [TOPIC], [TONE], [OUTPUT FORMAT] 등이 해당됩니다. 숨겨진 가정은 허용되지 않습니다. 프롬프트가 무언가에 의존한다면, 그것은 변수입니다.

A — Assumptions (가정): 이 프롬프트가 잘 작동하기 위해 전제되어야 하는 조건들입니다. 모델 버전 (Model version), 컨텍스트 길이 (Context length), 입력 유형 (Type of input) 등이 포함됩니다. 프롬프트 성능 저하 (Prompt decay) 현상이 가장 먼저 나타나는 지점이 바로 여기입니다.

R — Result standard (결과 표준): 좋은 결과물이란 무엇인지 정의합니다. 한두 문장으로 작성합니다. 급하게 작업할 때는 결과물을 제대로 평가하지 않고 넘어가기 쉬운데, 이것이 여러분의 빠른 체크리스트 역할을 합니다.

TVAR는 한 번 작성하는 데 5분이 걸리지만, 위에 언급한 모든 실수로부터 여러분을 구해줍니다. TVAR는 트리거 기반의 사고를 강제하고, 추상화를 요구하며, 성능이 저하될 수 있는 가정들을 표면화하고, 품질 기준을 설정합니다.

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

위의 모든 내용은 저만의 시스템을 구축하고 재구축하며 어렵게 얻은 교훈들입니다. 일관된 문제는 프롬프트 라이브러리가 실제 작업이 일어나는 도구의 "외부"에 존재한다는 점입니다. Notion이나 Obsidian에서 정성스럽게 무언가를 만들어 두지만, 막상 코딩 어시스턴트(Coding assistant), 글쓰기 도구, 연구 워크플로(Research workflow) 등 작업의 흐름(Flow)에 들어간 순간, 프롬프트를 가져오기 위해 컨텍스트를 전환(Switch contexts)하지는 않습니다. 대신 즉흥적으로 대처하게 됩니다.

AI Handler는 바로 그 간극을 메우기 위해 제가 만들고 있는 도구입니다. 이는 프롬프트 라이브러리를 작업 흐름 옆에 두는 것이 아니라, 실제 워크플로 내부에 유지하는 통합 AI 워크플로 레이어 (Unified AI workflow layer)입니다. TVAR 구조를 갖춘 프롬프트, 트리거 기반 검색, 내장된 성능 저하 알림, 그리고 현재 실행 중인 어떤 모델이나 도구로든 직접 주입(Direct injection)할 수 있는 기능을 제공합니다. 일곱 단계가 아닌, 하나의 컨텍스트로 해결합니다.

목표는 프롬프트를 위한 더 나은 Notion을 만드는 것이 아닙니다. "내가 정확히 어떤 프롬프트가 필요한지 안다"와 "그 프롬프트가 지금 실행되고 있다" 사이의 거리를 최대한 제로(0)에 가깝게 만드는 것입니다.

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