FIXING Opus 5: PROOF that Prompt Engineering IS NOT DEAD

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Opus 5를 고치는 핵심은 더 강한 모델을 기다리는 것이 아니라 시스템 프롬프트로 행동·문체·작업 경계를 정밀하게 설계하는 것이며, 이는 프롬프트 엔지니어링이 여전히 필요하다는 증거다.

📌 핵심 요점

1. Opus 5는 추론 능력은 뛰어나지만 장황한 설명, 반복되는 상투어, 요청 밖의 작업 확장으로 출력 토큰과 검토 시간을 낭비할 수 있다.
2. 사용자 프롬프트가 개별 작업을 지시한다면 시스템 프롬프트는 모든 입력과 출력에 공통으로 적용되므로 에이전트의 소통 방식과 운영 범위를 지속적으로 통제한다.
3. 효과적인 프롬프트는 역할극보다 원하는 행동과 금지할 패턴을 구체적으로 명시한다. 평이한 언어, 중복 제거, 상세도 조절, 근거 없는 동의 금지 같은 규칙이 여기에 해당한다.
4. 결정·위험·질문에 D1·R1 같은 참조 코드를 붙이고 SCR·ELI·FOC 같은 별칭을 정의하면 긴 대화를 반복하지 않고도 답변을 압축하거나 필요한 부분만 다시 확장할 수 있다.
5. 시스템 프롬프트에 요청 범위 준수, 불필요한 리팩터링 금지, 증거 없는 완료 주장 금지, 좋은 답과 나쁜 답의 실제 예시를 함께 넣으면 모델의 높은 지능을 더 일관되고 실용적인 결과로 전환할 수 있다.

🧩 배경과 문제 정의

• Opus 5는 높은 지능에도 불구하고 장황한 답변, 상투적인 표현, 불필요한 작업 확장으로 출력 토큰과 사용자의 검토 시간을 과도하게 소비한다.
• 사용자 프롬프트는 개별 작업만 제어하지만, 시스템 프롬프트는 모든 입력과 출력에 반복 적용되므로 에이전트의 소통 방식과 운영 범위를 일관되게 바꿀 수 있다.
• 좋은 프롬프트 엔지니어링의 핵심은 역할극을 부여하는 것이 아니라 원하는 행동, 피해야 할 패턴, 작업 경계와 구체적인 예시를 명확하게 작성하는 데 있다.
• 모델이 기본적으로 유능해져도 간결성, 참조 체계, 별칭과 같은 고유한 작업 방식을 자동으로 갖추지는 않으므로 시스템 프롬프트의 필요성은 사라지지 않는다.

🕒 시간순 섹션별 상세정리

1. Opus 5의 지능과 소통 품질 사이의 격차

• Opus 5는 뛰어난 추론 능력을 갖췄지만 load-bearing, worth stating plainly 같은 상투어와 장황한 답변을 반복해 비용과 검토 부담을 키운다. [00:04]
• 에이전트와 효과적으로 일하려면 기술과 정확히 소통해야 하며, 프롬프트 엔지니어링은 모델이 바뀌어도 유지되는 핵심 역량이다. [01:14]

2. 사용자 프롬프트보다 넓은 시스템 프롬프트의 영향력

• 사용자 프롬프트가 현재 작업 하나를 지시한다면 시스템 프롬프트는 에이전트가 수행하는 모든 작업에 적용되는 공통 규칙이다. [01:58]
• 시스템 프롬프트의 각 문장은 모든 입력과 출력에 반복 적용되므로 소통 패턴을 정착시키고 비싼 출력 토큰을 줄이는 지렛대가 된다. [02:26]

3. 기본 Opus 5의 장황함을 확인한 비교 실험

• 같은 장문 글을 두 Claude Code 인스턴스에 입력하고, 기본 Opus 5와 시스템 프롬프트를 수정한 Opus 5를 나란히 비교하는 실험 환경을 구성한다. [02:52]
• 기본 상태에서는 응답에 35~53초가 걸리고 대부분의 시간이 긴 텍스트 출력에 쓰여, 핵심 정보를 찾는 데 시간과 토큰이 함께 낭비된다. [04:16]

4. 목적과 관계부터 정의하는 첫 번째 계층

• 시스템 프롬프트는 자동 생성에 맡기지 않고 직접 작성하며, 여러 실행에 반복 적용되는 자율 소프트웨어일수록 기술과 동작을 이해한 상태에서 세밀하게 설계해야 한다. [05:20]
• 역할을 부여하는 대신 “불필요한 말 없이 명확하고 간결하며 실행 가능하게 소통한다”는 관계와 목적을 정하고, 팀·사업·고객을 위한 결과라는 이유까지 연결한다. [05:46]

5. 원하는 행동을 고정하는 긍정 패턴

• 긍정 패턴과 부정 패턴을 함께 두어 에이전트가 반복해야 할 행동과 피해야 할 행동을 대조적으로 구분한다. [08:11]
• 중요한 정보를 마지막에 배치하고, 평이하고 구체적인 언어로 사실을 한 번만 쓰며, 작업 규모에 맞춰 상세도를 조절하도록 규칙을 세운다. [08:59]

6. 상투어와 불필요한 문체를 제거하는 부정 패턴

• load-bearing, here’s the honest truth처럼 반복되는 상투어를 금지 목록에 넣고, 불필요한 비유와 과도한 대시 연결도 제한한다. [10:06]
• 근거 없는 칭찬·동의, 장식적인 제목과 이모지, 동기부여 문구를 금지해 문제 해결과 무관한 출력 토큰을 줄인다. [11:08]

7. 행동 패턴 적용 후 나타난 출력 변화

• 수정된 인스턴스에서는 금지한 상투어가 사라지고 대시가 줄었으며, 실행 시간도 약 31초로 감소해 출력 토큰 절감 효과가 나타난다. [12:20]
• 대시를 완전히 금지하지 않았기 때문에 일부 표현은 남지만, 문장이 더 명료해지고 헤더 구조와 정보 탐색성이 개선된다. [12:40]

8. 긴 대화를 압축하는 참조 포인트

• 결정·선택지·위험·질문·행동처럼 항목이 세 개 이상인 정보에는 번호와 마크다운 제목을 사용해 빠르게 탐색할 수 있는 참조 체계를 만든다. [13:27]
• 결정은 D1, 위험은 R1처럼 짧은 코드를 부여하고 대화 전체에서 같은 코드를 유지하되, 짧고 단순한 답에는 불필요한 코드를 만들지 않는다. [14:11]

9. 참조 코드로 반복을 없앤 후속 대화

• 비교 실행에서 위험과 핵심 주장에 코드가 자동으로 붙고, 에이전트가 기존 내용을 다시 풀어 쓰지 않고 R6 같은 참조로 직접 연결한다. [15:15]
• R6을 더 설명해 달라는 짧은 입력만으로도 해당 위험의 의미와 논리 순서를 이어서 분석할 수 있어 후속 프롬프트의 길이와 모호성이 줄어든다. [15:44]

10. 요청 범위를 지키는 강한 운영 경계

• 고성능 모델은 답을 찾는 과정에서 요청하지 않은 문제와 주변 작업까지 끌어들여 초점을 잃을 수 있으므로 명시적인 운영 경계가 필요하다. [16:49]
• 요청된 범위만 수행하고 정리·리팩터링·문서화·인접 기능으로 작업을 확대하지 않으며, 미래 요구사항을 위한 추상화도 추측하지 않도록 제한한다. [17:44]

11. 짧은 명령을 확장하는 별칭

• 별칭은 정확히 일치하는 짧은 코드를 미리 정의된 지시문으로 확장하지만, 더 긴 문자열의 일부로 등장하면 실행하지 않아 오작동을 방지한다. [18:43]
• SCR은 응답을 단순화·압축·재작성하고, ELI는 18세가 이해할 언어로 바꾸며, FOC는 가장 중요한 신호와 가치만 남긴다. [19:33]

12. 별칭을 이용한 즉각적인 응답 재구성

• 개선된 시스템 프롬프트는 핵심 주장과 위험을 참조 코드로 구조화하며, 약 30초 안에 기본 응답보다 탐색하기 쉬운 결과를 만든다. [20:19]
• SCR 하나로 긴 답변을 더 짧고 실행 가능한 형태로 압축하고, FOC로 전체 주장 가운데 가장 중요한 논점만 다시 추출한다. [20:56]

13. 반복 실행에 적용될 규칙은 손으로 정밀하게 다듬기

• 여러 작업에 곱셈식으로 영향을 미치는 프롬프트일수록 속도를 늦추고 직접 작성해야 하며, 음성 기반의 즉흥 지시는 세부 조건을 놓쳐 모델의 기본 성향에 더 의존하게 된다. [22:00]
• 두 문단을 한 문단으로, 두 문장을 한 문장으로 줄일 수 있다면 정보 손실 없이 압축하고, 같은 아이디어는 후속 질문에 필요할 때만 반복한다. [22:52]

14. 비결정적 결과를 보완하는 압축 명령과 시스템 규칙

• 정밀 조정 후 상투어와 대시는 줄고 문장은 단순해졌지만 실행 시간은 35초로 변동해, 생성형 시스템의 비결정성 때문에 매번 동일한 속도 향상을 기대할 수는 없다. [23:58]
• 출력이 여전히 길면 SCR이나 ELI를 추가로 실행할 수 있으며, 각 사용자 요청 사이에서도 시스템 프롬프트는 계속 유지되어 재작성 방식에 영향을 준다. [24:25]

15. 실제 예시와 인컨텍스트 증류로 완성하는 행동 기준

• 좋은 답과 나쁜 답의 실제 쌍을 넣으면 추상적인 긍정·부정 규칙보다 구체적인 행동 기준이 생기며, Redis 추가 여부 같은 질문에도 제약 조건과 실패 영역을 근거로 직접 답할 수 있다. [26:44]
• 예시 기반 프롬프트는 GPT-3.5와 GPT-4 시기부터 계속 유효했으며, 명확한 소통이라는 원칙은 특정 모델 세대가 바뀌어도 유지된다. [27:47]

16. 시스템 프롬프트로 응답 형식과 추론 수준 통제

• 선호하는 소통 예시를 참조점으로 추가하고 언어를 간결하게 정리하면, 불필요한 대시와 장황한 문장을 줄이면서 원하는 응답 형식을 반복해서 얻을 수 있다. [30:11]
• ref 같은 짧은 별칭을 시스템 프롬프트에 정의하면 참조 자료나 명령으로 자동 확장할 수 있으며, 간결한 작업에서는 출력 토큰과 응답 시간을 줄이는 데 유리하다. [30:54]

17. 개발자의 소통 병목과 기본 원칙의 가치

• 많은 에이전트 작업에서 병목은 모델이나 도구가 아니라 개발자이며, 필요한 가치를 빠르고 간결하게 전달하는 능력이 결과의 품질을 좌우한다. [32:08]
• 복잡한 에이전트 조합이 토큰과 시간을 낭비한다면 올바른 시스템 프롬프트 하나가 더 나은 해법이며, 공통 법칙은 시스템 프롬프트에 두고 개별 작업은 사용자 프롬프트로 분리해야 한다. [33:05]

🧾 결론

• 모델 성능이 높아져도 간결성, 참조 체계, 별칭, 운영 경계와 같은 사용자의 고유한 작업 방식이 자동으로 생기지는 않는다.
• 반복 적용할 공통 법칙은 시스템 프롬프트에 두고, 개별 작업의 요구사항은 사용자 프롬프트로 분리하는 것이 핵심 설계 원칙이다.
• 긍정 규칙과 부정 규칙만 나열하는 데서 그치지 않고 실제 선호 응답과 비선호 응답을 예시로 제공해야 원하는 출력 형태를 더 구체적으로 전달할 수 있다.
• 프롬프트 엔지니어링의 본질은 모델을 속이는 문구가 아니라 사람과 에이전트 사이의 소통 규약을 명시적으로 설계하는 데 있다.

📈 투자·시사 포인트

• 고성능 모델의 경쟁력은 추론 점수뿐 아니라 출력 토큰, 응답 탐색성, 검토 시간까지 포함한 실제 운영 효율로 평가할 필요가 있다.
• 시스템 프롬프트만으로도 불필요한 출력을 줄일 수 있다는 사례는 모델 교체보다 저비용의 운영 설계가 먼저일 수 있음을 시사한다.
• 참조 코드와 별칭처럼 사용자의 작업 방식을 축적하는 인터페이스는 범용 모델을 실제 업무 시스템으로 전환하는 차별화 요소가 될 수 있다.
• 복잡한 다중 에이전트 구성이 항상 정답은 아니며, 명확한 시스템 프롬프트 하나가 토큰과 시간을 덜 쓰면서 더 나은 결과를 낼 가능성도 함께 검토해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 비교 실험에서 응답 시간이 약 31초로 줄어든 사례가 제시되지만, 이후 실행은 35초로 변동했다. 생성 결과의 비결정성 때문에 동일한 속도 개선이 반복된다고 단정할 수 없다.
• 기본 응답과 수정 응답의 출력 토큰이 정확히 몇 개였는지, 여러 작업과 반복 실행에서 평균적으로 얼마나 절감됐는지는 제시되지 않았다.
• 비교가 같은 장문 글을 입력한 두 Claude Code 인스턴스를 중심으로 이뤄졌으므로 다른 작업 유형이나 모델에서도 같은 효과가 유지되는지는 추가 검증이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 시스템 프롬프트에서 장황한 표현, 근거 없는 칭찬, 반복 설명, 요청 범위 밖 작업 확장을 유발하는 규칙과 누락된 경계를 점검한다.
• 원하는 행동과 피해야 할 행동을 긍정·부정 패턴으로 나누고, 각 규칙을 관찰 가능한 문장으로 다시 작성한다.
• 결정·위험·질문·행동이 세 개 이상 등장하는 긴 대화에 D1·R1 같은 참조 코드를 시험 적용한다.
• SCR·ELI·FOC처럼 자주 쓰는 재작성 지시를 정확히 일치할 때만 작동하는 별칭으로 정의한다.

❓ 열린 질문

• 어느 정도의 규칙과 예시를 넣었을 때 얻는 일관성보다 시스템 프롬프트 자체의 길이와 유지보수 비용이 더 커지는가?
• 작업별 상세도와 공통 문체 규칙이 충돌할 때 시스템 프롬프트는 어떤 우선순위로 설계해야 하는가?
• 참조 코드와 별칭이 긴 대화에서는 효율적이더라도 짧은 작업에서는 언제부터 불필요한 형식 비용이 되는가?