Opus 5 고치기: 프롬프트 엔지니어링은 죽지 않았다는 증거

URL: https://www.youtube.com/watch?v=S_QdQ1G4GlU 날짜: 2026-08-19 채널: IndyDevDan 원문 제목: FIXING Opus 5: PROOF that Prompt Engineering IS NOT DEAD

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==최첨단 모델이 똑똑하다는 이유로 그 모델의 장황함·과잉행동·비용을 그대로 받아들일 필요는 없다. 모든 작업에 곱해지는 시스템 프롬프트를 직접 설계하면 Opus 5를 정확하고 간결한 시니어 엔지니어처럼 만들 수 있다.==

• 사용자 프롬프트(User Prompt)는 지금 처리할 단일 작업을 지정한다.
• 시스템 프롬프트(System Prompt)는 에이전트에게 주는 모든 작업에 적용되는 운영 법칙이다.
• 긍정/부정 패턴, 참조점(reference points), 하드 운영 경계(hard operational boundaries), 별칭(aliases), 실제 예시를 시스템 프롬프트에 넣으면 응답의 말투·범위·탐색 방식·출력 토큰 사용량을 함께 조정할 수 있다.
• 프롬프트 엔지니어링은 모델의 세대가 바뀌어도 유효한 기술이며, 본질은 기술과 명확하게 소통하는 능력이다.

Opus 5를 더 똑똑하게 만들자는 이야기가 아니다. 이미 충분히 똑똑한 모델에서 ‘smart’는 보존하고 ‘ass(재수 같은 태도)’를 제거하자는 이야기다. 시스템 프롬프트를 고레버리지(high-leverage) 작업으로 보고 손으로 다듬으면, 모델이 목표를 달성하면서도 요청하지 않은 정리·추측·장황한 재요약까지 벌이는 문제를 줄일 수 있다.

1. Opus 5가 똑똑하지만 함께 일하기 피곤한 이유

Opus 5의 지능 자체보다 커뮤니케이션 습관과 과잉행동이 개발자의 시간을 잡아먹는다는 문제의식에서 출발한다.

1.1. 장황함과 모델 특유의 말버릇

1. 반복적으로 늘어지는 응답

   1. Opus 5는 최첨단(또는 state-of-the-art) 초고지능 모델 중 하나지만, 응답이 지나치게 길고 장황하다.
   2. load-bearing, worth stating plainly, here's the honest truth 같은 표현과 비슷한 문구를 반복한다.
   3. 대시(em dash)를 과도하게 사용하고, 요점을 말한 뒤 불필요하게 큰 재요약을 덧붙인다.

2. 사용자가 지불한 지능을 자기 공로처럼 드러내는 문제

   1. Anthropic 팀이 사용자의 Git 커밋 메시지에 공동 저자(co-author)로 들어가려는 것처럼 보이는 동작을 비꼰다.
   2. 사용자는 이미 모델 사용료를 냈으므로, 커밋 메시지에 모델의 공로를 자동으로 기록할 이유가 없다.
   3. 이후 시스템 프롬프트 예시에서도 Never add a co-author to a commit message를 하드 경계로 넣는다.

3. 출력 토큰 비용

   1. Opus 5는 이전 어떤 모델보다 더 많은 알파 토큰(alpha tokens)을 태우는 것처럼 보인다.
   2. 긴 답변 대부분이 실제로 읽히지 않는다면, 지능이 아니라 비용과 지연만 늘어난다.
   3. 발표자와 많은 엔지니어가 같은 피로를 느끼고 있으며, 문제는 특정 사용자의 착각이 아니다.

1.2. ‘최고인 동시에 최악’이라는 역설

1. 모델의 능력과 태도의 분리

   1. Opus 5는 어려운 문제를 풀 수 있는 최상급 모델이라는 점은 인정한다.
   2. 그러나 말투가 ‘완전한 smartass’처럼 느껴지기 때문에, 최첨단 모델 중 최악의 사용 경험을 줄 수도 있다.
   3. 목표는 모델의 지능을 낮추는 것이 아니라 정확한 시니어 엔지니어(precise cracked senior engineer)처럼 소통하게 만드는 것이다.

2. 오늘의 Opus 5에만 묶이지 않는 해법

   1. 지금은 Opus 5를 고치지만 내일은 다른 모델이 최첨단이 될 수 있다.
   2. 특정 모델의 버그를 땜질하는 대신, 모델과 무관하게 재사용할 수 있는 프롬프트 패턴을 만든다.
   3. 프롬프트 엔지니어링이 죽었다는 말을 들으면 무시하라는 강한 결론으로 연결된다.

2. 프롬프트 엔지니어링은 에이전트 시대의 핵심 소통 기술이다

에이전트의 성능을 좌우하는 병목은 모델의 지능만이 아니라 개발자가 기술과 소통하는 방식이다.

2.1. 좋은 엔지니어의 공통점은 기술과 소통하는 능력

1. 15년의 엔지니어링 경험에서 얻은 관찰

   1. 발표자는 15년 동안 엔지니어링하면서 최고의 엔지니어들이 기술과 탁월하게 소통한다는 공통점을 발견했다.
   2. 에이전트와 소통하는 수단은 결국 프롬프트다.
   3. 따라서 프롬프트를 잘 쓰는 일은 가벼운 요령이 아니라 기술을 다루는 기본 역량이다.

2. 프롬프트 엔지니어링에 대한 인식 변화

   1. 한때 프롬프트 엔지니어링은 완전한 농담처럼 취급됐다.
   2. 에이전트로 영향력을 확장(scale impact)하려는 엔지니어에게는 이제 가장 중요한 기술 중 하나다.
   3. 에이전트를 많이 띄우고 도구를 조합할수록, 짧고 정확한 의사소통이 결과의 품질과 비용을 좌우한다.

2.2. 사용자 프롬프트와 시스템 프롬프트

1. 사용자 프롬프트(User Prompt)

   1. 사용자가 익숙하게 쓰는 입력으로, 지금 당장 처리할 단일 과업을 지시한다.
   2. 예를 들어 긴 블로그를 요약하거나 특정 파일의 참조 여부를 확인하는 요청이 사용자 프롬프트다.
   3. 강력하지만 각 작업마다 다시 작성해야 하므로 반복적인 행동 규칙을 담기에는 레버리지가 낮다.

2. 시스템 프롬프트(System Prompt)

   1. 에이전트에게 전달하는 모든 작업에 적용되는 ‘법(law)’이다.
   2. 시스템 프롬프트에 적은 한 단어 한 단어가 모든 사용자 프롬프트와 모든 응답에 곱해진다.
   3. 말투·응답 구조·범위·금지할 습관·토큰 압축을 한 번 설정해 전체 실행에 적용할 수 있다.

3. 스킬과의 관계

   1. 많은 엔지니어가 skills, skills, skills, /this, /that, /plan, /grill, /review 같은 스킬에 집중한다.
   2. 스킬과 사용자 프롬프트도 강력하지만, 전역 커뮤니케이션 규칙을 관리하는 시스템 프롬프트를 대부분 건드리지 않는다.
   3. 반복되는 모든 실행을 개선하려면 시스템 프롬프트가 훨씬 큰 레버리지를 제공한다.

3. 비교 실험의 구성과 기본 모델의 문제

발표자는 동일한 작업을 두 Claude Code 인스턴스에 나란히 시켜 시스템 프롬프트의 효과를 눈으로 비교한다.

3.1. 실험 환경

1. 작업 대상

   1. VS Code에 단순한 3개 파일 구조의 저장소를 준비한다.
   2. Mark Zuckerberg의 글 The Future Is For Everyone을 클론해 둔다.
   3. 긴 글을 전부 읽지 않고 요약한다. 발표자는 이를 ‘요즘 우리 모두가 하는 일’이라며, 터미널에 에이전트 1,000만 개를 띄워 두느라 원문을 읽을 시간도 없다고 농담한다.

2. 터미널과 실행 명령

   1. Herder를 터미널 멀티플렉서(terminal multiplexer)로 사용한다.
   2. 디렉터리의 명령 목록을 보려고 J를 입력하고, J compare를 실행한다.
   3. compare 명령은 새로운 작업 공간을 열고 두 Claude Code 세션을 좌우로 나란히 비교한다.

3. 좌우 인스턴스

   1. 왼쪽은 ‘smartass Opus 5’, 오른쪽은 ‘senior Opus 5’로 표시한다.
   2. 첫 실행에서는 양쪽 모두 기본 시스템 프롬프트와 기본 Claude Opus 5 모델을 쓰므로 사실상 둘 다 smartass 모드다.
   3. 이후 오른쪽 세션에만 작성한 시스템 프롬프트 파일을 append system prompt 인자(flag)로 전달한다.

3.2. 기본 실행에서 드러난 문제

1. 긴 작업과 긴 출력

   1. Zuck의 블로그가 매우 길기 때문에 두 모델 모두 오랫동안 실행되며 많은 정보를 쏟아낸다.
   2. 한 번의 측정에서 왼쪽은 약 53초, 오른쪽은 약 35초가 걸렸다.
   3. 발표자는 시간의 대부분이 실제 추론이 아니라 출력 텍스트였다고 지적한다.

2. 개발자의 실제 요구

   1. 대부분의 사용자는 Zuck의 글 전체를 읽지 않듯 모델의 전체 출력을 읽지도 않는다.
   2. 먼저 빠르게 판단할 수 있는 간결하고 압축된 정보가 필요하다.
   3. 더 깊이 투자할 가치가 있는지 결정한 뒤에야 시간을 써야 하며, 에이전트 엔지니어링은 결국 시간을 어디에 배분할지 결정하는 일이다.

4. 첫 번째 시스템 프롬프트: 목적과 커뮤니케이션 기준

시스템 프롬프트는 자동 생성에 맡기지 않고 손으로 작성한다. 여러 실행에 곱해질 자율 소프트웨어를 다룰수록 기술을 직접 이해하고 규칙을 명시해야 한다.

4.1. 손으로 쓰는 이유와 목적 선언

1. 곱해지는 산출물은 직접 작성한다

   1. 시스템 프롬프트는 여러 실행에 반복 적용되는 자율 소프트웨어의 커뮤니케이션 문서다.
   2. 발표자는 이런 문서를 손으로 쓴다. 기술을 이해하지 못한 채 모든 것을 ‘vibe slop’으로 생성하면, 주의 깊게 설계한 사람과 같은 결과를 얻을 수 없다.
   3. 높은 레버리지를 가진 규칙일수록 잠시 멈추고 천천히 설계해야 한다.

2. 첫 번째 문장

   1. 시스템 프롬프트의 출발점은 clear, concise, actionable communication이다.
   2. 에이전트와의 관계를 no-BS, clear, concise, actionable relationship으로 정의한다.
   3. 역할(role)을 부여하거나 가상의 인물을 연기시키지 않고, 다른 엔지니어와 대화하듯 기준을 직접 말한다.

3. 목적(Purpose)

   1. 함께 주고받는 모든 말이 명확하고 간결하며 실행 가능한 커뮤니케이션을 강화한다고 선언한다.
   2. 목표는 좋은 대화 자체가 아니라 문제를 해결하고 팀·비즈니스·고객을 위해 가치를 만드는 것이다.
   3. 각 규칙에는 가능하면 왜(why)를 붙인다. 여기서 이유는 팀·비즈니스·고객에게 최선의 결과를 전달하기 위해서다.

4. 문서 구조

   1. 목적과 지침(instructions)을 먼저 두고, 지침 안에 여러 아이디어를 정리한다.
   2. 긍정 패턴·부정 패턴·참조점·운영 경계 등을 섹션으로 나눠 나중에 명확하게 참조할 수 있게 한다.
   3. 예시 섹션과 마지막 요약 섹션까지 포함해 시스템 프롬프트 자체가 커뮤니케이션 기준의 문서가 되게 한다.

4.2. 첫 실행의 한계와 점진적 개선

1. 목적만 추가했을 때

   1. Purpose만 넣은 첫 비교에서는 모델의 말버릇이 크게 달라지지 않는다.
   2. 여전히 load-bearing이 나오고 대시가 많지만, 조금 더 나은 방향으로 소통하는 흔적은 보인다.
   3. 한 측정에서 약 35초가 걸려 기본 실행보다 큰 차이가 없었으므로, 높은 수준의 목적 선언만으로는 부족하다.

2. 중간·낮은 수준의 행동 규칙으로 이동

   1. 시스템 프롬프트를 더 구체적인 반복 패턴으로 확장해야 한다.
   2. 모델이 어떤 결과를 내야 하는지뿐 아니라 무엇을 반복하고 무엇을 피해야 하는지를 명시한다.
   3. 시스템 프롬프트가 추상적인 가치 선언에 머물지 않고 관찰 가능한 출력 형식과 문장 습관까지 다뤄야 한다.

5. 긍정 패턴과 부정 패턴으로 말투를 조정하기

행동을 원하는 방향으로 유도하려면 ‘해야 할 일’과 ‘하지 말아야 할 일’을 함께 적는다. 발표자는 이 부분을 어떤 작업에도 반복 적용할 수 있는 구체적인 프롬프트 엔지니어링 패턴으로 제시한다.

5.1. 긍정 패턴(Positive Patterns)

1. 가장 중요한 정보를 마지막에 둔다

   1. I always see the last thing you write first. Place the most important information there.라는 규칙을 둔다.
   2. 에이전트의 답변에서 마지막 부분을 먼저 읽는 일이 많으므로, 독자가 나머지를 건너뛰어도 핵심을 얻도록 한다.
   3. 결론·다음 행동·가장 중요한 사실을 응답의 끝에 배치하면 짧은 시간에도 신호를 회수할 수 있다.

2. 평이하고 구체적인 언어를 사용한다

   1. Use plain, specific language로 추상적이고 장식적인 표현을 줄인다.
   2. 하나의 사실은 한 번만 말하고 반복하지 않는다.
   3. 작업과 요청의 수준에 맞춰 상세도를 조절한다. 작은 질문에 거대한 보고서를 내지 않는다.

3. 잘못된 전제를 직접 교정한다

   1. 틀린 가정을 그대로 받아들이지 말고, 왜 틀렸는지 설명한다.
   2. 아첨(sycophancy)을 제거하고 유용한 엔지니어링 파트너가 된다.
   3. 좋은 대화나 인용 가능한 문장보다 명료함과 엔지니어링 가치를 최적화한다.

4. 정보를 압축하는 가장 단순한 도메인 용어를 선택한다

   1. 전문 용어를 무조건 어렵게 쓰지 않고, 의미를 가장 짧게 압축하는 단순한 용어를 쓴다.
   2. 불필요한 수사와 반복을 줄여 독자가 결정과 행동을 빠르게 수행하게 한다.
   3. 이후 미세 조정 단계에서는 한 문단으로 말할 수 있는 내용을 두 문단으로 늘리지 않는 규칙으로 더 구체화한다.

5.2. 부정 패턴(Negative Patterns)

1. 모델의 상투적 표현을 금지 목록에 넣는다

   1. load-bearing, worth stating plainly, here's the honest truth, the real tension, carry the argument 같은 과장된 문구를 피한다.
   2. 목록은 사용자가 싫어하는 표현을 계속 추가할 수 있으며, 모델별 습관에 맞춰 조정한다.
   3. 특정 단어를 금지하는 것만으로 지능을 낮추는 것이 아니라, 같은 내용을 더 직접적인 언어로 출력하게 만드는 것이다.

2. 불필요한 비유와 장식을 줄인다

   1. 발표자는 작업 중에는 눈앞의 문제에 집중하고 싶으므로 avoid analogies를 선호한다.
   2. 장식적인 제목, 이모지, 동기 부여식 언어를 쓰지 않는다.
   3. 모델이 ‘멋있어 보이는’ 설명을 만드는 대신 문제를 바로 해결하게 한다.

3. 대시와 문장 부호를 절제한다

   1. 대시를 아예 금지하지 않고 과도한 대시 연결(dash chaining)을 피한다.
   2. 발표자도 원래 대시를 어느 정도 쓰지만, AI가 아무 생각 없이 작성한 답처럼 보이지 않도록 사용량을 줄였다고 말한다.
   3. 세미콜론, 문장 파편(fragment), 비표준 문장 부호도 피하고 정상적인 대화를 지향한다.

4. 근거 없는 동조를 금지한다

   1. 이유 없이 칭찬·찬양·검증·동의를 하지 않는다.
   2. 사용자의 전제가 틀렸다면 맞장구치지 말고 직접 지적한다.
   3. 목표는 ‘좋은 말만 하는 조수’가 아니라 명확한 판단을 돕는 시니어 엔지니어다.

5.3. 첫 행동 패턴 실험의 결과

1. 응답의 표면적 변화

   1. 부정 패턴을 넣은 뒤 오른쪽의 대시가 크게 줄고 load-bearing이 검색되지 않는다.
   2. 헤더가 더 명확해지고, 언어가 읽기 쉬워진다.
   3. private by default 같은 대시 표현은 남을 수 있으며, 어느 정도까지 허용할지는 사용자가 추가로 프롬프트 엔지니어링한다.

2. 속도와 토큰 절감

   1. 한 실행은 약 31초로 줄었다.
   2. 여기서 속도가 빨라졌다는 말은 모델 자체가 빨라졌다기보다 출력 토큰이 줄었다는 뜻이다.
   3. 구독제에서도 출력 토큰은 사용량을 가장 많이 소모하므로, 시스템 프롬프트 차원에서 전역적으로 압축하는 것이 중요하다.

6. 참조점(Reference Points)으로 에이전트와 빠른 언어 만들기

응답의 각 항목에 짧은 코드를 부여하면 모델이 앞에서 말한 내용을 반복하지 않고 특정 논점으로 바로 이동할 수 있다.

6.1. 참조점 설계 규칙

1. 탐색을 개선하는 구조

   1. 결과가 세 개 이상일 때 번호 목록과 Markdown 헤더를 사용한다.
   2. 대상은 결정(decisions), 선택지(options), 위험(risks), 질문(questions), 행동(actions), 발견(findings) 등이다.
   3. 단순한 짧은 답에는 불필요하게 코드를 붙이지 않는다.

2. 짧은 코드와 연속성

   1. 결정에는 D1, D2, … Dn처럼 짧은 코드를 부여한다.
   2. 위험·발견 등 대화에서 쓰일 다른 섹션에도 짧은 코드를 지정한다. 실제 비교 화면에는 R(risks), F(findings), P 계열 항목이 나타난다.
   3. 아직 정의하지 않은 섹션이 나오면 새 참조 코드를 만들고, 대화가 이어지는 동안 같은 코드를 유지한다.

3. 빠른 질의

   1. 이전 설명을 통째로 반복하지 않고 코드 하나로 같은 대상을 가리킨다.
   2. 사용자는 Talk more about R6.처럼 짧게 요청할 수 있다.
   3. 모델은 R6이 Zuck의 글에 등장한 ‘실존적 RSI 자기개선 위험(existential RSI self-improvement risk)’을 뜻한다는 맥락을 유지한 채 해당 부분만 확장한다.

6.2. 비교 화면에서 나타난 효과

1. 반복 대신 포인터를 사용한다

   1. 에이전트가 위험 목록을 R1부터 나열한 뒤, 본문에서 특정 위험을 R6으로 다시 가리킨다.
   2. 사용자는 문서를 위아래로 헤매지 않고 해당 참조점으로 점프할 수 있다.
   3. 같은 설명을 매번 다시 생성하지 않으므로 출력 토큰과 응답 시간을 줄일 가능성이 생긴다.

2. 커뮤니케이션 자체가 엔지니어링이다

   1. 참조점은 모델의 지식을 늘리는 기능이 아니라 개발자와 에이전트가 함께 쓰는 압축된 언어다.
   2. P, R, F 같은 코드의 글자가 무엇을 의미하는지보다, 안정적으로 같은 항목을 가리킬 수 있다는 사실이 핵심이다.
   3. 기술과 제대로 소통하는 능력이 큰 이점인데도 충분히 활용되지 않고 있으며, 모델이 똑똑해질수록 이 이점은 커진다.

7. 하드 운영 경계(Hard Operational Boundaries)로 과잉행동 막기

최첨단 모델은 답을 찾으려는 강화학습 때문에 요청받지 않은 문제까지 해결하려 한다. 범위를 닫는 규칙이 없으면 ‘더 많이 했다’가 ‘더 잘했다’를 압도한다.

7.1. Opus 5가 초점을 잃는 방식

1. 요청 범위 밖의 문제를 찾는다

   1. Opus 5는 사용자가 전혀 묻지 않은 문제를 찾아내고 참조하며, 모든 것을 한 번에 연결하려 한다.
   2. 모델 훈련 과정에서 어떤 대가를 치르더라도 답을 찾도록 학습된 특성이 이 행동에 영향을 준다고 추정한다.
   3. 최대한 많은 일을 하려는 태도가 오히려 빠르게 초점을 잃게 만든다.

2. 경계가 필요한 이유

   1. 사용자가 원하는 것은 의도한 범위의 결과이지 저장소 전체의 청소가 아니다.
   2. 인접한 개선을 모두 포함하면 출력 토큰, 실행 시간, 검토 범위가 커진다.
   3. 따라서 시스템 프롬프트가 ‘무엇을 하지 않을지’를 법처럼 고정해야 한다.

7.2. 운영 경계의 구체적 문장

1. 요청 범위를 지킨다

   1. Deliver only what was requested at the intended scope.를 기본 경계로 둔다.
   2. 작업을 정리(cleanup), 리팩터링(refactoring), 문서화(documentation), 인접 기능으로 넓히지 않는다.
   3. 미래 요구사항을 위한 추상화를 미리 추측하지 않는다.

2. 완료 주장에 증거를 요구한다

   1. Do not claim completion without evidence.를 넣는다.
   2. 실제로 확인하지 않은 테스트·파일 변경·결과를 완료했다고 말하지 않게 한다.
   3. 결과를 보고할 때는 완료 사실을 장황하게 재현하지 않고 짧게 다시 말한다.

3. Anthropic 공동 저자 표시를 막는다

   1. Never add a co-author to a commit message.를 명시한다.
   2. 발표자는 이를 Anthropic을 위한 마케팅 트릭처럼 보인다고 농담하며, 모델이 사용자의 커밋에 자기 이름을 넣는 것을 원하지 않는다.
   3. 이처럼 사용자가 전역적으로 원하지 않는 운영 행동도 시스템 프롬프트에서 한 번 금지하면 모든 커밋 작업에 적용된다.

8. 별칭(Aliases)으로 반복 지시를 짧게 실행하기

별칭은 시스템 프롬프트 안에 정의하는 짧은 명령어다. 반복되는 커뮤니케이션 원칙을 매번 길게 다시 쓰지 않고 실행한다.

8.1. 별칭의 의미와 안전한 확장

1. 별칭은 행동 규칙의 단축키다

   1. 별칭은 지켜야 할 커뮤니케이션 패턴을 상기시키는 짧은 코드다.
   2. 정확히 별칭으로 등장했을 때만 확장하고, 확장된 지시가 직접 주어진 것처럼 행동한다.
   3. 긴 문자열 안에 우연히 같은 글자가 포함된 경우에는 별칭으로 해석하거나 확장하지 않는다.

2. 외부 도구와의 연결

   1. 별칭은 인라인 규칙으로 작성할 수 있다.
   2. 필요하면 명령어·스킬·다른 도구를 가리키도록 연결할 수도 있다.
   3. 시스템 프롬프트가 에이전트의 입력과 출력을 통제하는 층이므로, 별칭을 통해 작업 방식까지 빠르게 전환할 수 있다.

8.2. 시연한 별칭

1. SCR — Simplify, Compress, Repeat

   1. 응답을 단순화하고 압축한 뒤 다시 말한다.
   2. 모델이 이미 많은 내용을 출력했을 때 사용자가 긴 재지시를 쓰지 않아도 된다.
   3. 실제 시연에서 결과가 훨씬 단순해져 정보를 더 빨리 행동으로 옮길 수 있었다.

2. ELI 또는 ELY — 설명 수준 조정

   1. Explain this like I'm 18처럼 언어를 단순하게 만들고 응답을 짧게 한다.
   2. ELI 5, ELI 10처럼 원하는 수준을 추가로 정의할 수 있다.
   3. 단순한 표현을 원하는 것이 바보라는 뜻이 아니라 효과적으로 정보를 처리하려는 선택이라는 점을 강조한다.

3. FOC — Focus

   1. 지금 가장 중요한 것과 진짜 신호(signal)를 찾아 핵심 가치로 압축한다.
   2. Zuck 글 요약에서 FOC를 실행하자, 모델은 AI 정렬 논쟁의 핵심을 한 문장으로 뽑았다.
   3. 해당 핵심은 ‘정렬의 기준이 모델이 연구소의 가치를 담는 것에서 에이전트가 사용자의 가치를 담는 것으로 재정의되고 있으며, 나머지는 그 결과’라는 취지였다.

4. REF — Reference

   1. 위에서 만든 참조점 체계로 응답을 다시 작성한다.
   2. 긴 설명을 반복하는 대신 결정·위험·발견을 코드로 연결한다.
   3. 별칭을 하나씩 쌓을수록 시스템 프롬프트가 개인의 작업 방식에 맞는 작은 운영 언어가 된다.

9. 수동 미세 조정과 고레버리지 작업의 원칙

시스템 프롬프트를 만든 뒤에는 한 번에 완성됐다고 가정하지 않고, 비교 실행을 반복하면서 문장 수준까지 조정한다.

9.1. 더 간결한 문장 규칙

1. 정보를 잃지 않는 압축

   1. 한 문단으로 말할 수 있다면 두 문단으로 늘리지 않는다.
   2. 한 문장으로 말할 수 있다면 두 문장으로 늘리지 않는다.
   3. 단, 가치 있는 정보를 잃지 않는 범위에서만 압축한다.

2. 반복과 과부하를 제거한다

   1. 모든 아이디어는 한 번만 말하고, 다음 질의에 실제로 필요할 때만 반복한다.
   2. 여러 의미를 가질 수 있는 과부하된 단어를 피한다.
   3. 전달하려는 생각을 충족하는 가장 단순한 단어를 사용한다.

3. 설계자가 직접 검증한다

   1. 발표자는 이 정도로 세밀하게 쓰는 것이 맞느냐는 반응을 예상하지만, 바로 그 세밀함 때문에 결과를 관찰할 수 있다고 말한다.
   2. 같은 compare 명령으로 매번 양쪽 결과를 보고, 특정 표현·구조·속도를 다시 조정한다.
   3. 시스템 프롬프트가 append 방식인지 overwrite 방식인지도 실험에서 확인한다. 시연에서는 시스템 프롬프트를 덮어쓰지 않고 추가했다.

9.2. 음성 바이브 프롬프트와 손글씨의 차이

1. 바이브 프롬프팅의 한계

   1. Whisper Flow처럼 음성으로 빠르게 입력하는 방식은 편하지만, 세부 사항이 빠질 수 있다.
   2. 그 경우 모델이 일반적인 학습 분포가 제안하는 행동에 기대게 되고, 특별한 의도를 충분히 인코딩하지 못한다.
   3. 즉흥적인 프롬프트가 쓸모없는 것은 아니지만, 전역적으로 반복될 규칙을 작성하는 자리에는 적합하지 않다.

2. 언제 느려져야 하는가

   1. 나머지 작업에 곱해지는 시스템 프롬프트처럼 영향력이 큰 부분에서는 일부러 멈추고 손으로 개입한다.
   2. ‘구식으로 직접 손을 대는 것(old-school hands-on)’이 고레버리지 지점에서의 올바른 속도다.
   3. 최신 모델이 목표를 달성할 수 있다는 사실만으로 요청하지 않은 행동까지 허용해서는 안 된다.

9.3. 실행 결과와 비결정성

1. 개선된 실행의 관찰

   1. 미세 조정 후에도 대시는 줄고 load-bearing은 사라지며, 참조점과 더 단순한 문장이 남는다.
   2. 한 비교에서는 개선된 오른쪽이 약 35초, 왼쪽이 약 43초로 측정됐다.
   3. 다른 비교에서는 smartass 응답이 41초, 원래의 한 실행이 22초였다고 표시되며, 개선의 목표는 무조건적인 속도 경쟁이 아니라 불필요한 출력 토큰 절감이다.

2. 측정값을 해석하는 법

   1. 모델 생성은 비결정적(non-deterministic)이므로 같은 프롬프트가 항상 더 빠른 결과를 내지는 않는다.
   2. 30초·35초·43초 같은 실행 시간 자체보다 출력이 덜 장황하고 행동 가능해졌는지를 봐야 한다.
   3. 정말 출력 토큰이 필요한 작업이라면 토큰을 써도 되지만, 단순 요약처럼 압축이 목표인 작업에서 낭비를 줄이는 것이 핵심이다.

10. Zuck의 AI 논지와 에이전트의 요약 방식

비교 실험의 원문인 Zuck의 글에서 모델이 추출한 논지를 잠시 검토하며, CEO가 쓴 글의 인센티브도 함께 보라고 조언한다.

10.1. 모델이 정리한 핵심 주장

1. AI 접근성에 관한 주장

   1. AI는 소수의 모델 연구소가 통제할 때보다 모두가 가지고 있을 때 더 안전하다는 주장이다.
   2. 다른 연구소들은 AI가 위험하므로 접근을 잠그자고 말하지만, 한곳에 거대한 권력이 집중되는 것은 역사적으로 잘 끝나지 않았다는 논리를 편다.
   3. 모든 사람이 같은 가치관을 갖지 않으므로, 하나의 ‘안전한 AI’가 모든 사람의 가치를 대신 선택할 수 없다는 주장도 포함된다.

2. 요약 후 다시 압축하는 흐름

   1. 모델이 만든 긴 분석을 그대로 소비하지 않고, 핵심 논지를 찾아 SCR 또는 FOC로 다시 줄인다.
   2. 발표자는 이 논지의 상당 부분에 개인적으로 동의한다고 말한다.
   3. 다만 AI 경쟁을 주도하지 않는 사람이 이런 서사를 공개할 때는 자신의 위치와 인센티브를 함께 이해해야 한다고 덧붙인다.

10.2. 본론과 주변 논평의 구분

1. 정치적·전략적 위치성
   1. Zuck의 주장이 사실인지 여부와 별개로, 누가 어떤 경쟁 위치에서 말하는지 살펴야 한다.
   2. 모델은 사실을 나열하는 데서 그치지 않고 필요하면 주장의 약한 지점과 이해관계를 표시해야 한다.
   3. 그러나 발표자는 이 논평을 영상의 중심으로 확장하지 않고, 시스템 프롬프트를 고치는 본론으로 돌아간다.

11. 프롬프트 엔지니어링이 죽지 않았다는 반례

일부 에이전트가 시스템 프롬프트를 줄였다는 사실을 ‘프롬프트 엔지니어링의 종말’로 해석하면 안 된다.

11.1. 작은 시스템 프롬프트가 의미하는 것

1. Pi와 Claude Code의 변화

   1. Pi 코딩 에이전트는 작은 시스템 프롬프트를 사용한다.
   2. Claude Code도 최근 시스템 프롬프트를 상당 부분 제거했다.
   3. 이는 모델이 기본적으로 많은 일을 수행할 수 있다는 신호이지, 특정 행동을 원하는 사용자가 시스템 프롬프트를 쓰지 말라는 신호가 아니다.

2. 기본 능력과 원하는 동작의 차이

   1. 모델이 별도 지시 없이도 많은 일을 한다는 것과, 사용자가 원하는 방식으로만 일한다는 것은 다르다.
   2. 출력 토큰을 태우지 않게 하거나, 특정 단어를 피하거나, 고유한 별칭·참조점·운영 경계를 쓰게 하려면 직접 설계해야 한다.
   3. 시스템 프롬프트는 입력과 출력 양쪽에 적용되므로, 전역 행동을 조정할 가장 효과적인 위치다.

11.2. 적용되는 기능의 범위

1. 말투와 형식

   1. 단순한 언어, 적절한 헤더, 마지막 핵심 정보, 근거 없는 칭찬 금지 등을 적용한다.
   2. 특정 단어와 개념을 피하거나 반드시 포함시킬 수 있다.
   3. 모델이 같은 커뮤니케이션 기준을 모든 사용자 프롬프트에서 유지하게 한다.

2. 작업 행위

   1. 요청 범위 밖의 리팩터링·문서화·추측을 막는다.
   2. 완료 주장에 증거를 요구하고, 커밋에 공동 저자를 추가하지 않게 한다.
   3. 별칭으로 반복 작업의 설명 수준·압축·참조를 즉시 전환한다.

12. 실제 예시를 훈련 데이터처럼 사용하기

긍정·부정 패턴을 규칙으로 적는 것에서 더 나아가, 원하는 답변과 원하지 않는 답변의 실제 쌍을 넣는다.

12.1. 레거시 JSON 참조 예시

1. 사용자 질문과 원하는 답변

   1. 사용자 질문은 Is legacy JSON still referenced?다.
   2. 원하는 답변은 파일 자체와 일치하는 것만 있고 import나 문서 링크는 없다는 식으로 짧게 사실을 말한다.
   3. 더 압축하면 The only match of the file is itself.처럼 한 문장으로 답할 수 있다.

2. 원하지 않는 답변

   1. Great question, I will research the repository and ...처럼 조사하겠다는 장황한 예고를 하지 않는다.
   2. 이미 필요한 작업을 했다면 계획을 반복하지 말고 결과를 바로 말한다.
   3. 이 예시는 단순한 질문에 불필요한 진행 보고와 감탄을 붙이지 않는 기준을 학습시킨다.

12.2. Redis 도입 권고 예시

1. 사용자 질문과 원하는 답변

   1. 사용자 질문은 Should we add Redis to this system?이다.
   2. 원하는 답변은 이 프로세스에 writer가 하나이고, SQL에서 저장하며, 호스트 간 조정 요구사항이 없으므로 Redis를 추가하지 말라는 것이다.
   3. Redis는 올바른 제약을 해결하지 않은 채 새로운 장애 영역(failure domain)을 추가한다는 이유를 함께 말한다.

2. 원하지 않는 답변

   1. You're absolutely right처럼 근거 없는 동조로 시작하지 않는다.
   2. 사용자의 질문에 맞지 않는 장황한 장점 목록이나 일반적인 Redis 설명을 늘어놓지 않는다.
   3. 구체적인 현재 제약과 시스템 구조를 기준으로 결론을 낸다.

12.3. 예시가 오래 살아남는 이유

1. 모델 세대가 바뀌어도 유지되는 원칙
   1. 발표자는 GPT-3.5와 GPT-4 시절, Anthropic이 사실상 등장하기 전부터 이런 예시를 써 왔다고 말한다.
   2. 지금도 같은 예시가 유효하므로, 좋은 기술인지 판단하는 기준은 오래된 모델에만 맞았는지가 아니라 여러 세대에 걸쳐 작동하는지다.
   3. 좋은 엔지니어링과 좋은 소통의 원칙은 모델의 브랜드와 무관하게 오래 지속된다.

13. 인컨텍스트 증류(In-Context Distillation)로 좋은 답변을 복제하기

좋아하는 모델의 답변을 예시로 추출해 시스템 프롬프트에 넣으면, 다른 모델도 그 스타일과 판단 기준을 따라갈 수 있다.

13.1. Fable 5를 기준 모델로 삼기

1. 모델 간 스타일 비교

   1. 발표자는 Fable 5가 Opus 5와 같은 프롬프트에 잘 반응하면서도 반복되는 말버릇·문제·장황함이 적다고 평가한다.
   2. 이처럼 좋아하는 모델의 구체적인 응답은 원하는 커뮤니케이션의 기준점이 될 수 있다.
   3. 더 비싼 모델의 일반적인 능력을 흉내 내는 것이 아니라, 좋은 결과의 형식과 압축 정도를 예시로 전달한다.

2. 인컨텍스트 증류의 정의

   1. Do this, don't do that이라는 예시 자체가 인컨텍스트 증류다.
   2. 별도의 모델 재훈련 없이, 같은 상황에서 원하는 답변과 원하지 않는 답변을 컨텍스트에 넣는다.
   3. 시스템 프롬프트의 예시 섹션은 작은 훈련 데이터처럼 작동한다.

13.2. 원하는 응답을 수동으로 편집하는 절차

1. 좋은 응답을 템플릿으로 추출한다

   1. 좋아하는 모델이 만든 한 줄 핵심 논지를 복사한다.
   2. summarizing a blog 같은 사용자 요청과 임의의 입력을 템플릿으로 만들고, 그 아래에 원하는 to do 답변을 붙인다.
   3. 답변을 그대로 보존하지 않고 원하는 형식에 맞춰 수동으로 다듬는다.

2. 장황한 흔적을 제거한다

   1. 불필요한 대시와 프레이밍을 검색해 제거한다.
   2. super intelligence처럼 반복되는 표현을 삭제하거나 더 간결한 문장으로 바꾼다.
   3. 너무 긴 문장을 나누고, 목록과 섹션을 읽기 쉽게 배치한다.

3. 좋은 예시와 나쁜 예시를 함께 둔다

   1. 편집한 Fable 5의 답변을 원하는 예시로 넣는다.
   2. smartass Opus 5의 장황한 결과를 ‘이렇게 하지 말 것’의 예시로 활용한다.
   3. 두 예시의 차이는 모델을 바꾸지 않고도 시스템 프롬프트를 통해 출력 스타일을 통제하는 근거가 된다.

13.3. 예시와 참조점의 결합

1. 새로운 비교 결과

   1. 개선된 에이전트는 좋아하는 답변의 형식, 참조점, 줄어든 대시, 압축된 문장을 함께 사용한다.
   2. 참조점이 없는 모델과 달리 REF 별칭으로 필요한 구조를 즉시 확장한다.
   3. 한 번의 측정에서 smartass 응답은 41초, 원래 비교의 응답은 22초로 나타났지만, 반복적인 불필요한 출력이 줄어드는 것이 중요한 성과다.

2. 필요할 때만 출력 비용을 쓴다

   1. 많은 추론과 출력이 필요한 작업에서는 토큰을 아끼지 않아도 된다.
   2. 블로그 요약처럼 빠른 판단을 위한 작업에서는 길이가 가치가 아니므로 압축한다.
   3. SCR, FOC, ELI 같은 별칭은 이 선택을 사용자 프롬프트 한 단어로 실행하게 한다.

14. 개발자가 새로운 병목이 된 에이전트 시대

모델·도구·에이전트가 충분히 강해지면서, 많은 작업의 어려운 부분은 개발자 자신이 얼마나 빨리 정확하게 의도를 전달하느냐가 된다.

14.1. 지능보다 전달 속도와 가치 밀도

1. 개발자의 병목

   1. 매일 에이전트를 쓰면 모델이나 도구가 아니라 개발자가 병목이라는 사실을 체감하게 된다.
   2. 어려운 일은 모델을 더 똑똑하게 만드는 것이 아니라, 빠르고 간결하며 가장 많은 가치를 만드는 방식으로 지시하는 것이다.
   3. 훌륭한 팀 커뮤니케이션, 훌륭한 에이전트 커뮤니케이션, 그리고 자기 자신과의 명확한 소통이 같은 원리로 연결된다.

2. 스마트함은 보존하고 태도만 바꾼다

   1. Keep the smart, but drop the ass.가 영상의 핵심 농담이자 설계 목표다.
   2. 모델의 문제 해결 능력을 낮추지 않고, 장황함·허세·근거 없는 동조·범위 확장을 제거한다.
   3. 시스템 프롬프트는 이 변화를 모든 사용자 프롬프트에 적용하는 전역 레이어다.

14.2. 복잡한 조합보다 원자적 프리미티브

1. 고수준 에이전트 엔지니어링의 함정

   1. 채널에서는 소프트웨어 팩토리(software factories), 에이전트 샌드박스(agent sandboxes) 같은 높은 추상화 수준을 다뤄 왔다.
   2. 여러 에이전트를 묶어 복잡한 시스템을 만드는 것이 항상 최선은 아니다.
   3. 올바른 시스템 프롬프트 하나로 절반의 시간에 끝낼 일을 에이전트 여러 개와 토큰 묶음으로 해결하면 낭비다.

2. 기본기로 돌아가기

   1. 큰 조합을 이루는 원자 단위와 프리미티브를 놓치지 않아야 한다.
   2. 멋있어 보이거나 모두가 하는 방식이 아니라, 일을 끝내는 가장 단순한 해결책을 선택한다.
   3. 엔지니어링은 멋져 보이는 것이나 유행을 따라가는 것이 아니라 문제를 해결하는 일이다.

15. 실전 적용 절차와 최종 결론

프롬프트 엔지니어링을 단발성 문장 요령이 아니라 전역 운영 문서를 만들고 검증하는 작업으로 다룬다.

15.1. 바로 적용할 수 있는 순서

1. 두 프롬프트를 분리한다

   1. 시스템 프롬프트에는 모든 작업에 적용할 법과 커뮤니케이션 기준을 넣는다.
   2. 사용자 프롬프트에는 현재 해결할 개별 작업만 넣는다.
   3. 특정 작업만의 지시를 시스템 프롬프트에 넣어 전역 동작을 오염시키지 않는다.

2. 전역 규칙을 직접 작성한다

   1. 명확하고 간결하며 실행 가능한 관계를 선언한다.
   2. 긍정 패턴과 부정 패턴으로 문장 습관을 조정한다.
   3. 참조점, 하드 운영 경계, 별칭, 실제 원하는/원하지 않는 예시를 차례로 추가한다.

3. 비교하고 반복한다

   1. compare처럼 기본 모델과 개선 모델을 나란히 실행한다.
   2. load-bearing, 대시, 장황한 재요약, 요청 범위 밖의 작업, 공동 저자 표시 등 실제 문제를 검색한다.
   3. 속도만이 아니라 출력 토큰, 정보 밀도, 검토 가능성, 실제 행동 가능성을 함께 평가한다.

4. 짧은 별칭으로 조정한다

   1. 필요할 때 SCR로 단순화·압축·재진술한다.
   2. FOC로 핵심 신호를 찾고 ELI로 설명 수준을 낮춘다.
   3. REF로 이전 결론과 위험을 참조점으로 다시 정리한다.

15.2. 최종 메시지

1. 프롬프트 엔지니어링의 지위

   1. 프롬프트 엔지니어링이 죽었다는 주장은 사실이 아니다. 영상의 표현대로 그 명제는 returns false다.
   2. 모델이 기본적으로 더 많은 일을 할수록, 원하는 구체적인 행동을 전역적으로 고정하는 시스템 프롬프트의 가치는 오히려 분명해진다.
   3. 좋은 엔지니어링은 좋은 소통이며, 이 원칙은 모델 세대가 바뀌어도 사라지지 않는다.

2. 도구를 이해하면 결과를 이해한다

   1. 에이전트는 결국 또 하나의 도구다.
   2. 도구를 이해하면 그 도구에서 얻을 수 있는 결과의 범위를 이해할 수 있다.
   3. 시스템 프롬프트를 모든 작업의 법으로 쓰고, 사용자 프롬프트를 개별 작업의 지시로 사용한다.

3. 단순한 해법을 먼저 찾는다

   1. 정교해 보이는 다중 에이전트 구조를 도입하기 전에 시스템 프롬프트 하나로 문제를 해결할 수 있는지 확인한다.
   2. 모델의 지능을 버리지 않고 커뮤니케이션의 잡음만 제거한다.
   3. 결국 에이전트의 영향력을 키우는 사람은 가장 복잡한 프롬프트를 쓰는 사람이 아니라, 가장 정확하게 원하는 결과를 소통하는 사람이다.

주요 발언 모음

“Opus 5는 최첨단 초고지능 모델 중 하나이자, 완전히 smartass처럼 말하기 때문에 출시된 최악의 최첨단 모델 중 하나다.”

“시스템 프롬프트는 에이전트에게 주는 모든 작업의 법이다.”

“모든 최고의 엔지니어가 놀랍도록 잘하는 일은 기술과 소통하는 것이다. 에이전트와 어떻게 소통하는가? 프롬프트다.”

“좋은 대화를 하고 싶은 게 아니다. 명확하고 간결한 커뮤니케이션 패턴으로 엔지니어링 가치를 전달하고 싶다.”

“요청된 것을 의도한 범위에서만 전달하라.”

“프롬프트 엔지니어링이 죽었다고 말하는 사람을 믿지 마라.”

“우리가 원하는 것은 smart는 유지하고 ass는 제거하는 것이다.”

“엔지니어링은 멋져 보이는 일이 아니라 일을 끝내는 일이다.”

핵심 데이터 & 수치

• 15년: 발표자가 엔지니어링 분야에서 일하며 최고의 엔지니어들에게서 관찰한 공통 역량을 설명한 경력 기간이다.
• 3개 파일: Zuck의 글을 요약하는 비교 실험 저장소의 단순한 구조다.
• 약 53초 대 약 35초: 기본 Opus 5 두 인스턴스의 초기 비교에서 관찰된 실행 시간이다. 대부분은 출력 텍스트를 생성하는 데 쓰였다.
• 약 31초: 긍정·부정 패턴을 추가한 비교에서 개선된 세션이 기록한 실행 시간이다. 출력 토큰이 줄어든 결과로 설명된다.
• 약 30초: 별칭과 참조점까지 포함한 비교에서 양쪽 세션에 관찰된 실행 시간대다.
• 약 35초 대 약 43초: 미세 조정한 세션과 비교 세션의 한 관찰값이다. 모델 생성이 비결정적이므로 고정된 우열을 뜻하지 않는다.
• 41초 대 22초: 후반 비교에서 smartass 응답과 기존 응답에 표시된 또 다른 측정값이다. 핵심 평가지표는 절대 시간보다 불필요한 출력과 정보 밀도다.
• D/R/F/P 코드: 결정(Decisions), 위험(Risks), 발견(Findings), 비교 화면에 나타난 약속·계획 계열 항목을 짧게 참조하기 위한 예시다.

결론 및 시사점

1. 에이전트가 똑똑하다는 이유로 장황함·아첨·범위 확장을 감수하지 말고, 시스템 프롬프트에 원하는 커뮤니케이션 법칙을 직접 적어야 한다.
2. 가장 먼저 clear, concise, actionable과 no-BS 관계를 선언하고, 목적을 팀·비즈니스·고객 가치와 연결해야 한다.
3. 긍정 패턴과 부정 패턴을 함께 제공하면 모델의 상투어·대시·장식·근거 없는 동조를 구체적으로 줄일 수 있다.
4. 세 개 이상의 결과에는 결정·위험·발견 같은 참조 코드를 부여해, 반복 대신 R6처럼 짧은 언어로 대화해야 한다.
5. 요청 범위 밖의 정리·리팩터링·문서화·미래 추측과 증거 없는 완료 주장을 하드 운영 경계로 차단해야 한다.
6. SCR, FOC, ELI, REF 같은 별칭은 반복 지시를 압축하고 응답의 설명 수준과 초점을 즉시 바꾸는 실용적인 인터페이스다.
7. 좋아하는 모델의 답변을 수동으로 편집해 원하는 예시로 넣는 인컨텍스트 증류는 재훈련 없이 여러 모델에 커뮤니케이션 스타일을 전파한다.
8. 시스템 프롬프트는 모든 사용자 프롬프트에 곱해지므로, 개별 사용자 프롬프트만 다듬는 것보다 전역 규칙을 손으로 설계하는 편이 더 큰 레버리지를 만든다.
9. compare 같은 좌우 실험으로 출력 토큰·표현·범위·검토 시간을 확인해야 하며, 비결정적인 실행 시간만으로 성공 여부를 판단하면 안 된다.
10. 프롬프트 엔지니어링은 죽지 않았다. 에이전트를 단순한 도구로 이해하고 시스템 프롬프트를 법으로, 사용자 프롬프트를 개별 작업으로 사용하면 모델 세대가 바뀌어도 더 큰 영향력을 얻을 수 있다.