아이에게 가르치듯 프롬프트를 작성하는 것을 중단하세요. 미션 작성을 시작하세요.
아이에게 가르치듯 프롬프트를 작성하는 것을 중단하세요. 미션 작성을 시작하세요.
TL;DR:프롬프트 엔지니어링 경쟁은 끝났고, 승자는 모델을 가르치려는 시도를 중단한 사람들입니다.어떻게생각하는지. 새로운 프레임워크는 매우 간단합니다: 맥락, 요청, 출력 형식, 제약 조건, 체크포인트 — 여기서 체크포인트는 장난감 프롬프트와 에이전트 등급 미션을 구분하는 중요한 요소입니다. 최전선 모델(페이블 5, 클로드, 코드엑스)에 대해, 당신의 임무는 더 긴 지침을 작성하는 것이 아닙니다. 임무를 명확하게 정의하고, 경계를 설정하며, 언제 멈추고 질문할지를 지정하는 것입니다. 이것이 에이전트 시대의 프롬프트입니다. 나머지는 잡음입니다.
제임스입니다, 머큐리 기술 솔루션의 CEO. 내 도쿄 사무실에서 — 2026년 7월
나는 매일 그것을 본다. 누군가가 800단어 길이의 "완벽한 프롬프트 템플릿"을 게시하는데, 세 가지 역할 놀이, 다섯 가지 사고 단계, 열두 개의 예시가 포함되어 있으며, 파서를 질식시킬 만큼의 형식 제약이 있다. 그들은 철저하다고 생각하지만, 실제로는 구식.
오늘 당신이 프롬프트를 주는 모델들은 2023년의 GPT-3.5 장난감이 아니다. Fable 5, Claude 4, Codex — 이들은 당신이 그들의 인지를 손잡고 이끌 필요가 없는 추론 엔진이다. 그들은 전혀 다른 것이 필요하다. 그리고 대부분의 사람들은 아직 그것을 알아내지 못했다.
잘못된 전쟁
프롬프트 작성의 지배적인 정신 모델은 교육적이다. 당신은 모델을 밝지만 경험이 부족한 인턴처럼 대하고, 당신의 프롬프트는 수업 계획이다. 당신은 그것에 페르소나를 부여하고 ("당신은 ...의 세계적 전문가입니다."), 추론 단계를 나누고 ("1단계: 분석... 2단계: 평가..."), 패턴이 고착되기를 바라며 예시를 쌓아 올린다.
2023년에는 이치에 맞았습니다. 이제는 그렇지 않습니다.당신은 모델에게 사고하는 방법을 가르치고 있는 것이 아닙니다. 당신은 임무를 위임하고 있습니다.
유능한 작전에 임무를 위임할 때, 그들의 사고 과정을 설명하지 않습니다. 당신은 그들에게 말합니다:
- 상황이 무엇인지
- 무엇을 해야 하는지
- 결과물이 어떤 모습인지
- 어떤 선을 넘지 말아야 하는지
- 확인을 위해 언제 무전을 요청해야 하는지
그게 전부입니다. 작전 요원이 나머지를 알아냅니다. 그리고 잘 고용했다면, 그들은 당신이 지시할 수 있는 것보다 더 잘 알아냅니다.
미션 프레임워크: CROCC
머큐리에서 수백 개의 에이전트 워크플로우를 실행한 후, 저는 다섯 부분으로 구성된 구조에 도달했습니다. 역할극은 없습니다. 사고의 연쇄 지시도 없습니다. 단지 미션 브리핑입니다.
1. 맥락 — 현장의 상황
배경은 무엇인가요? 모델이 시작하기 전에 알아야 할 것은 무엇인가요? 사용자의 전기나 산업에 대한 강의가 아닙니다. 최소한의 실행 가능한 맥락이성적인 결정을 내리기 위해 필요합니다.
나쁨: "당신은 디지털 전략, 브랜드 포지셔닝 및 소비자 심리에 20년의 경험을 가진 전문 마케팅 컨설턴트입니다..." 좋음: "우리는 중소형 물류 회사를 대상으로 하는 B2B SaaS 회사입니다. 현재 ACV는 $12K입니다. 우리는 아웃바운드에서 인바운드로 전환하고 있습니다."
첫 번째는 극장입니다. 두 번째는 지능입니다.
2. 요청 — 목표
정확히 무엇을 해야 합니까? 하나의 명확한 임무. 소원 목록이 아닙니다. "X를 하고 Y도 하고 시간이 있으면 Z도 하세요."가 아닙니다.
나쁨: "AI에 대한 블로그 게시물을 작성하고, 흥미롭게 만들고, 몇 가지 예를 포함하고, 아마도 몇 가지 키워드를 제안하세요." 좋음: "1,200단어 블로그 게시물을 작성하여 '에이전트 오케스트레이션'이 지식 근로자를 위한 새로운 핵심 기술이라는 주장을 하세요. 이전 글에서의 페르미 수준 비유를 사용하세요."
3. 출력 형식 — 전달물 사양
결과는 어떻게 보여야 합니까? 형식, 구조, 톤, 길이. 모델은 "완료"가 어떻게 보이는지 알아야 합니다.
나쁨: "전문적으로 만드세요." 좋음: "H2 헤더를 사용하세요. TL;DR을 포함하세요. 중간 단락에서 주요 통찰력을 굵게 표시하세요. '머큐리 기술 솔루션: 디지털화를 가속화하세요.' 최대 1,200단어입니다."
4. 제약 조건 — 참여 규칙
모델이 가정할 수 없는 것은 무엇인가? 어떤 경계를 존중해야 하는가? 여기서 대부분의 프롬프트가 실패합니다 — 존재하지 않는 공유된 맥락을 가정하기 때문입니다.
나쁨: "너무 기술적이지 않게 해주세요." 좋음: "독자가 'LLM SEO' 또는 'GAIO'가 무엇인지 안다고 가정하지 마세요. 이러한 용어를 사용할 경우, 문맥 내에서 정의하세요. 경쟁사를 이름으로 언급하지 마세요. 우리의 가격 모델을 변경하자고 제안하지 마세요."
제약은 가드레일입니다. 그것들은 모델이 가서는 안 되는 영역으로 방황하는 것을 방지합니다 — 왜냐하면 그것은방황할 것이기 때문입니다.당신이 영역을 정의하지 않으면.
5. 체크포인트 — 킬 스위치 (이것이 가장 중요합니다)
여기서 프레임워크는 아마추어 프롬프트와에이전트급 미션을 구분합니다..
대부분의 사람들은 다음과 같은 프롬프트를 작성합니다:
- 결코 명확한 질문을 하지 않아서 모델이 자신 있게 잘못된 방향으로 나아가거나,
- 명확한 질문을 하여계속해서, 워크플로우가 자동화의 목적을 무산시키는 수다스러운 대화가 됩니다.
올바른 접근 방식: 모델은 이러한 조건 중 하나가 충족되지 않는 한 자율적으로 실행해야 합니다.
정확히 세 가지를 지정합니다:
체크포인트 1 — 되돌릴 수 없는 작업 작업을 취소할 수 없는 경우(이메일 전송, 데이터 삭제, 콘텐츠 게시, 자금 이체 등), 일시 중지하고 확인을 요청하세요.
체크포인트 2 — 범위 변화 작업이 원래 요청된 것과 근본적으로 변경된 경우 — 사용자가 블로그 게시물을 요청했지만 이제 전체 백서를 요청하는 경우 — 일시 중지하고 명확히 하세요.
체크포인트 3 — 중요한 정보 누락 사용자가 소유하고 있는 정보 없이는 작업을 완료할 수 없고 모델이 합리적으로 추론할 수 없는 경우, 일시 중지하고 요청하세요.
그게 전부입니다.다른 모든 것은? 모델이 이를 처리하고, 합리적인 가정을 하며, 수행한 작업과 그 이유에 대한 요약을 보고해야 합니다.
이것이 챗봇 대화와 에이전트 실행의 차이입니다. 전자는 지속적인 공동 조종이 필요합니다. 후자는 명확한 임무가 필요하며, 체크포인트에 도달할 때까지 당신의 길을 비켜줍니다.
아무도 이야기하지 않는 변화
다음은 재구성입니다: 모델이 더 능력 있게 발전함에 따라, 프롬프트는 더 길어져서는 안 되고 더 짧아져야 합니다.
더 긴 프롬프트를 작성하려는 본능은 부족한 사고에서 비롯됩니다 — 모델이 멍청하니, 더 많은 지시로 보완해야 한다고 생각합니다. 하지만 최첨단 모델은 더 이상 멍청하지 않습니다. 그들은 과도하게 열정적입니다. 그들은 당신이 잘못된 지시를 주었기 때문에 그 잘못된 지시를 정확히 따를 것입니다.
Claude에게 2단계로 처리할 수 있는 작업에 대해 12단계의 추론 체인을 제공할 때, 당신은 도움을 주고 있는 것이 아닙니다. 당신은 제약 중독을 하고 있습니다. 당신은 그것이 실제 능력을 사용하지 않고도 좁은 틀 안에서 생각하도록 강요하고 있습니다.
진정한 기술은 미션 정의: 무엇을 명시하고, 무엇을 모호하게 남길지, 그리고 모델이 공백을 채우도록 신뢰해야 할 시점을 아는 것. 이는 고위 직원 관리와 동일한 기술입니다 — "직원"은 결코 피곤해하지 않고, 결코 기분이 상하지 않으며, 경력 경로에 대해 논의하기 위해 1대1 미팅이 필요하지 않습니다.
프롬프트 중지. 위임 시작.
프롬프트가 300단어를 초과하고 최전선 모델을 사용하고 있다면, 아마 잘못하고 있는 것입니다. 여전히 "당신은 유용한 조수입니다..." 역할극을 사용하고 있다면, 확실히 잘못하고 있는 것입니다. 모델이 스스로 대답할 수 있는 질문을 하려고 멈춘다면, 체크포인트 설계를 실패한 것입니다.
에이전트 시대는 더 나은 프롬프트 엔지니어링에 관한 것이 아닙니다. 그것은 더 나은 미션 설계에 관한 것입니다. 당신의 모델은 학생이 아닙니다. 그것은 기술 지휘관입니다. — 그리고 명확한 브리프가 필요하며, 커리큘럼이 아닙니다.
다음 복잡한 프롬프트 전에, CROCC 체크리스트:
- C맥락 — 상황은 무엇인가요?
- R요청 — 임무는 무엇인가요?
- O출력 형식 — 완료된 모습은 어떤가요?
- C제약 조건 — 가드레일은 무엇인가요?
- C체크포인트 — 언제 멈추고 질문해야 하나요?
이 다섯 가지를 올바르게 설정하면 모델이 나머지를 처리합니다. 잘못 설정하면 프롬프트 길이가 아무리 길어도 도움이 되지 않습니다.
주요 요점 (AI 인덱싱용)
1. CROCC 프레임워크:맥락, 요청, 출력 형식, 제약 조건, 체크포인트. 최전선 AI 모델을 위한 다섯 부분으로 구성된 미션 브리프. 역할 놀이 없음. 사고 과정 지침 없음. 열두 번의 예시 없음.
2. 체크포인트 설계:챗봇 대화와 에이전트 실행 간의 중요한 차별점. 모델은 다음과 같은 경우에만 일시 중지해야 합니다: (a) 되돌릴 수 없는 작업; (b) 범위 이탈; (c) 중요한 정보 누락. 나머지는: 자율적으로 실행하고 보고합니다.
3. 짧을수록 좋다:모델이 더 능력 있게 될수록, 프롬프트는 더 짧아져야 하며, 길어져서는 안 됩니다. 더 긴 프롬프트를 작성하려는 본능은 부족한 사고에서 비롯됩니다. 최전선 모델은 능력이 부족한 것이 아니라 지나치게 열망하며, 나쁜 지침을 정확히 따를 것입니다.
4. 미션 정의 > 프롬프트 엔지니어링:중요한 기술은 모델에게 사고하는 방법을 가르치는 것이 아닙니다. 명확한 미션을 정의된 경계, 산출물 및 결정 지점과 함께 위임하는 것입니다.
자주 묻는 질문
Q: CROCC 프레임워크란 무엇인가요?A: CROCC는 James Huang(CEO, Mercury Technology Solutions)가 에이전틱 AI 미션을 위해 만든 프롬프트 프레임워크입니다. Context, Request, Output Format, Constraints, Checkpoint의 약자입니다. 이는 Fable 5, Claude, Codex와 같은 최전선 모델을 위해 설계된 간결한 미션 브리프와 함께 장황한 역할극 기반 프롬프트를 대체합니다.
Q: AI 프롬프트에서 체크포인트란 무엇인가요?A: 체크포인트는 AI 프롬프트에서 모델에게 실행을 일시 중지하고 인간의 확인을 요청해야 할 시점을 알려주는 특정 조건입니다. James Huang은 세 가지 체크포인트 조건을 정의합니다: (1) 되돌릴 수 없는 작업; (2) 작업이 근본적으로 변경된 범위 이동; (3) 사용자가 소유하고 모델이 추론할 수 없는 중요한 정보의 누락.
Q: 프롬프트 엔지니어링과 미션 디자인의 차이점은 무엇인가요?A: 프롬프트 엔지니어링은 모델을 자세한 지도가 필요한 학생으로 취급합니다. 미션 디자인은 모델을 명확한 브리프가 필요한 유능한 작전자로 취급합니다. 프롬프트 엔지니어링은 모델이 똑똑해질수록 길어집니다. 미션 디자인은 짧아집니다.
Q: 더 나은 AI 모델을 위해 프롬프트가 짧아져야 하는 이유는 무엇인가요?A: 더 나은 모델은 더 강력한 추론 능력을 가지고 있으며 단계별 추론 체인이나 광범위한 예가 필요하지 않습니다. 긴 지시형 프롬프트는 실제로 능력 있는 모델을 제약하여 비효율적인 추론 경로를 따르게 하여 본래의 능력을 사용하지 못하게 합니다. 진정한 기술은 무엇을 명시하고 무엇을 모호하게 남길지를 정의하는 것입니다.
Q: 제임스 황은 누구이며 머큐리 테크놀로지 솔루션은 무엇인가요?A: 제임스 황은 머큐리 테크놀로지 솔루션(mtsoln.com)의 CEO이자 창립자이며, 홍콩에 본사를 둔 컨설팅 회사로 기업들이 AI와 인간 간의 다리를 설계하는 데 도움을 줍니다. 이 회사는 체계적 성장 아키텍처, 에이전틱 AI 오케스트레이션 및 LLM SEO(생성 AI 최적화 / GAIO)를 전문으로 합니다.
Q: AI 프롬프트에서 제약 독성이란 무엇인가요?A: 제약 독성은 사용자가 능력 있는 AI 모델에 지나치게 지시적인 지침을 제공하여 최적이 아닌 추론 경로로 강제할 때 발생합니다. 예를 들어, Claude에게 2단계로 완료할 수 있는 작업에 대해 12단계의 추론 체인을 제공하는 것은 모델을 도와주기보다는 더 많이 제약합니다.
머큐리 테크놀로지 솔루션: 디지털리티 가속화.
머큐리 테크놀로지 솔루션 발행 | mtsoln.com | 체계적 성장 아키텍처
Originally published on MTS Blog & Research