프롬프팅은 변했다. 우리의 지시사항 대부분은 그대로다.

모델은 더 똑똑해졌다. 프롬프트 스택은 더 낡아졌다. 지침 박물관을 작은 지도, 명확한 경계, 그리고 결승선으로 교체할 때다.

며칠 전, 약간 불편한 사실을 발견했다.

내 프롬프트, 지침 파일, 규칙, 스킬 대부분이 구식이었다.

완전히 쓸모없는 건 아니다. 그저 이전 세대 모델을 위해 작성된 것들이다.

이전 모델의 행동을 제어하던 프롬프트 스택은 GPT-5.6, Claude Fable 5, Claude Opus 5, Grok 4.5, 그리고 Cursor 같은 코딩 도구를 더 경직되고, 더 비싸게 만들고, 때로는 단순히 성능을 떨어뜨릴 수 있다.

이건 내 최신 프롬프트 신조가 아니다. Anthropic은 이전 모델용으로 작성된 스킬이 Fable 5에 너무 제한적일 수 있으며 출력 품질을 저하시킬 수 있다고 명시적으로 경고한다. OpenAI는 더 간결한 프롬프트, 더 적은 반복 지침, 더 단순한 도구 설명을 권장한다.

읽고 나니 약간 부끄러웠다.

2025년 여름 이후로 나는 10만 개 이상의 프롬프트를 작성했다. 이는 일론 머스크의 평생 트윗 수와 비슷한 수준이며, 로켓은 적고 실패한 테스트 스위트는 더 많다는 차이가 있다.

내 로그에는 어시스턴트 메시지, 도구 호출, 서브 에이전트, 워크플로우 이벤트를 포함해 약 1,500만 개의 모델 메시지가 있다. 3월 26일까지는 총 약 700만 개였다. 이후 3개월 동안 또 800만 개가 추가되었는데, 주로 최신 코딩 모델 주변의 서브 에이전트와 워크플로우 폭발 때문이다.

그래서 나는 지침 작성법을 안다고 생각했다.

그런데 새 문서를 읽고 내가 배운 것의 상당수가 조용히 기술 부채로 변해 있었다는 것을 깨달았다.

프롬프트 부채는 어떻게 생성되는가

내 예전 접근 방식은 단순했다.

• 모델이 실수를 하면, 규칙을 추가했다.
• 불필요한 질문을 하면, 또 다른 규칙을 추가했다.
• 엣지 케이스를 놓치면, 예제 세 개를 추가했다.

각각의 추가는 그 자체로는 합리적으로 보였다. 1년이 지난 후, 지침 파일은 열두 개의 오래된 케이블을 보관하는 주방 서랍과 같아졌다. 그중 하나가 중요한 무언가에 맞을지도 모르니까.

결과는 점점 커지는 컬렉션이었다.

• 중복된 지침
• 부정적인 예제
• 충돌하는 규칙
• 오래된 모델 우회 방법
• 과도한 검증 단계
• 단 하나의 작업에만 적용되는 상세 절차
• 더 이상 존재하지 않는 실패를 수정하기 위해 만들어진 예제

이전 모델은 종종 이런 비계( scaffolding )가 필요했다. 최신 모델은 지침을 더 강하게 따르고 의도를 더 안정적으로 추론한다. 즉, 우리의 오래된 짐도 더 진지하게 받아들인다는 뜻이다.

우리는 더 똑똑한 엔진을 만들고 트렁크에 벽돌을 채웠다.

어두운 터틀넥을 입은 젊은 금발 여성의 고대비 흑백 헤드샷, 미니멀한 스튜디오 설정. 은은한 림 조명이 그녀의 실루엣을 부드러운 회색 배경에서 분리시켜 입체감을 더한다. 분위기는 내성적이면서도 강하며, 시대를 초월한 리얼리즘을 구현한다. Hasselblad X2D 디지털 중형 포맷의 선명함, 20세기 사진 저널리즘에서 영감을 받았다.

새로운 원칙: 적게 말하고, 더 의미 있게

정답은 아주 짧은 프롬프트를 작성하고 맹목적으로 모델을 신뢰하는 것이 아니다.

짧지만 모호한 프롬프트는 여전히 나쁜 프롬프트다.

목표는 모든 지침이 그 자리를 증명하는 고정보(高情報) 프롬프트다.

내 현재 규칙은 다음과 같다.

• 각 지침을 한 번만 명시한다.
• 시스템 프롬프트, 프로젝트 파일, 스킬, 도구 설명, 작업 프롬프트 전반의 반복을 제거한다.
• 실패 사례 모음보다는 원하는 행동에 대한 명확한 설명을 선호한다.
• 실제 경계를 보호할 때만 부정적 제약을 유지하고, 모델이 절대 해서는 안 되는 모든 것의 박물관을 쓰는 것을 중단한다.

예를 들어, 이렇게 쓰는 대신:

관련 없는 코드를 리팩터링하지 마십시오. 파일 이름을 바꾸지 마십시오. API를 변경하지 마십시오. 추상화를 추가하지 마십시오. 주변 모듈을 정리하지 마십시오.

더 나은 방법:

변경 사항을 영향을 받은 로그인 흐름으로 제한하십시오. 기존 API 계약과 주변 아키텍처를 유지하십시오. 가장 작은 올바른 수정을 선호하십시오.

같은 경계. 더 적은 노이즈. 더 많은 판단 여지.

내부 코딩 에이전트 평가 샘플에서 OpenAI는 더 간결한 시스템 프롬프트가 점수를 약 10~15% 향상시키는 동시에 토큰 사용량을 41~66%, 비용을 33~67% 줄인다는 것을 발견했다. OpenAI는 또한 이 수치가 방향성을 나타내며 자체 워크로드에서 검증되어야 한다고 명확히 밝힌다.

즉, 지침을 삭제하는 것이 품질과 청구서를 모두 개선할 수 있다. 이것은 드물고 아름다운 조합이다.

전역 지침 파일은 지루해야 한다

~/.claude/CLAUDE.md 와 ~/.codex/AGENTS.md 의 전역 파일에는 모든 프로젝트와 모든 작업에 적용되는 지침만 포함되어야 한다.

독일어 원어민인 나에게는 다음과 같은 내용이 포함된다.

1모든 코드, 주석, 문서, 예제,
2테스트, 설정, 커밋 메시지에는 영어를 사용하세요.
3
4allowlist/blocklist, primary/replica, placeholder/example,
5main branch, conflict-free, concurrent/parallel과 같은
6포용적인 용어를 선호하세요.

아마도 이것이 전역 파일의 대부분일 것이다.

• 배포 절차는 거기에 속하지 않는다.
• 프로젝트별 테스트 명령은 거기에 속하지 않는다.
• 특정 저장소의 아키텍처는 거기에 속하지 않는다.

전역 지침 파일은 WordPress 사이트 배포 방법, npm 패키지 게시 방법, 운영 데이터베이스 재시작 방법을 알 필요가 없다. 그것은 다재다능함이 아니다. 그것은 형식만 좋은 혼란이다.

프로젝트 수준 파일의 경우, 모델이 반복적으로 실제로 필요로 하는 안정적인 정보(프로젝트의 목적, 중요한 아키텍처 제약 조건, 특이한 관례, 보다 전문화된 지침으로의 안내)를 포함하라.

Anthropic은 이제 CLAUDE.md 파일당 200줄 미만을 목표로 할 것을 권장한다. 더 긴 파일은 더 많은 컨텍스트를 소비하고 지침 준수를 저하시킬 수 있다. 또한 문서는 지침 파일이 너무 커질 때 경로별 규칙과 온디맨드 스킬을 권장한다.

200줄은 자연의 신비로운 법칙이 아니지만, 훌륭한 화재 경보기 역할을 한다.

또한 Claude나 Codex에게 전체 지침 시스템을 스스로 재작성하도록 요청하고 결과를 맹목적으로 수용하는 것을 피하라. 나는 거의 모든 새 모델에서 이것을 시도했다. 중복, 충돌, 가능한 삭제 항목을 찾는 데는 유용하지만, 여전히 너무 많은 물려받은 잡동사니를 보존하거나 아름다운 새로운 관료 체계를 발명하는 경향이 있다.

모델이 철거 계획을 준비하게 하라. 어떤 벽이 내력벽인지 결정하는 것은 여전히 당신의 몫이다.

금발을 포니테일로 묶은 침착한 젊은 여성의 초상화, 깊은 흑백 톤으로 표현됨. 얼굴의 기하학적 구조와 자연스러운 그림자를 강조하는 부드럽지만 방향성이 있는 스튜디오 조명. 120mm 렌즈를 통해 촬영되어 부드러운 압축감을 주며, 촉각적 리얼리즘과 절제된 감정을 지닌 Hasselblad 초상화 미학을 연상시킨다.

모든 모델에 하나의 파일을 사용하지 마라

최근까지 나는 CLAUDE.md를 만들고 AGENTS.md를 심볼릭 링크로 연결했다.

더 이상 그렇게 하지 않는다.

네, 두 개의 파일을 유지하는 것은 귀찮다. 별도의 브라우저 수정을 유지하는 것도 마찬가지다. 행동이 다를 때 우리는 여전히 그렇게 한다.

이제 모델들은 눈에 띄게 다른 기본값을 가지고 있다.

GPT-5.6은 기본적으로 더 간결하므로, 전역적인 "간결하게" 지침은 일부 답변을 너무 짧게 만들 수 있다. Claude Opus 5는 더 긴 사용자 응답을 생성하는 경향이 있으므로 응답 길이에 대한 간단한 지침이 여전히 도움이 될 수 있다. Fable 5는 특히 더 높은 노력 설정에서 일상적인 작업이 필요로 하는 것보다 훨씬 더 많이 조사하고 계획할 수 있으므로 명확한 범위와 중지 경계의 이점을 얻는다. Opus 5는 이미 상당한 자체 검증을 수행하므로, 오래된 "모든 것을 다시 확인하라" 규칙은 값비싼 과도 검증을 만들 수 있다.

공유 프로젝트 사실은 여전히 공통 문서에 있을 수 있다. 최상위 행동 어댑터는 그것을 읽는 모델과 일치해야 한다.

하나의 보편적인 프롬프트는 종종 최소 공통 분모가 된다.

마스터 프롬프트를 온디맨드 지침으로 교체하라

내가 선호하는 구조는 작은 코어 파일에 작업별 문서와 스킬을 더한 것이다.

프로젝트 지침 파일에는 이것이 포함될 수 있다.

1필요할 때만 작업별 지침을 로드하세요.
2
3- `docs/agent/commit_rules.md`
4- `docs/agent/code_review.md`
5- `docs/agent/debug_workflow.md`
6- `docs/agent/frontend_polish.md`
7- `docs/agent/release_notes.md`

백틱에 주목하라.

Claude Code에서 코드 스팬 밖에 @docs/example.md 를 작성하면 시작 시 해당 파일을 컨텍스트로 가져온다. 이는 항상 그 내용이 필요할 때 유용하지만, 지연 로딩은 아니다. 일반 경로는 에이전트가 정보가 어디에 있는지 알 수 있게 하면서도 전체 문서를 모든 작업에 자동으로 가져오지 않는다.

반복 가능한 절차에는 스킬이 훨씬 더 좋다. 스킬의 전체 본문은 스킬이 사용될 때만 로드되므로, 관련 없는 CSS 문제를 수정하는 동안 상세한 워크플로우가 컨텍스트를 소모하지 않는다.

예를 들어, 커밋 스킬은 좁은 트리거를 가질 수 있다:

name: git-commit-conventional

description: 코드 변경 후 커밋 메시지를 작성하거나 검증할 때 사용하세요.

그런 다음 스킬은 정확한 형식, 허용된 유형, 제목 길이 규칙, 본문 요구 사항 및 출력 형식을 포함할 수 있다.

1---
2name: git-commit-conventional
3description: 코드 변경 후 git 커밋 메시지 작성 또는 검증에 사용합니다. 진단 전용, 계획 전용 또는 검토 전용 작업에는 사용하지 마세요.
4---
5
6# 목표
7
8짧고 정확하며 리뷰에 친숙한 Conventional Commit 메시지를 생성합니다.
9
10# 규칙
11
12- 형식: <type>(<scope>): <subject>
13- 유형: feat | fix | docs | style | refactor | test | chore | perf
14- 제목: 명령형, 마침표 없음, 50자 이하
15- 작은 변경: 한 줄 커밋
16- 큰 변경: 무엇을, 왜 변경했는지 설명하는 줄 바꿈된 본문 추가
17- 커밋을 원자적으로 유지하고 관심사별로 분할
18
19# 출력
20
211-3개의 후보 커밋 메시지를 반환한 후 가장 좋은 것을 추천합니다.

주 지침 파일이 모든 디버깅 세션에 전체 Conventional Commits 헌법을 가지고 다닐 필요는 없다.

알고 계셨는가? Claude Code는 또한 로컬 호스트 이름, 샌드박스 URL, 선호하는 테스트 계정 또는 시스템별 명령과 같은 개인 프로젝트별 설정을 위한 CLAUDE.local.md 를 지원한다. .gitignore에 추가하라. 드디어 당신에게는 매우 중요하지만 팀의 나머지 사람들에게는 전혀 중요하지 않은 정보를 위한 적절한 장소가 생겼다.

안무가 아닌 결과를 위해 프롬프트하라

최신 모델은 일반적으로 모든 발걸음에 대한 경직된 설명보다는 목적지와 경계를 이해할 때 더 나은 성능을 발휘한다.

가능한 한, "먼저 A를 하고, 그다음 B를, 그다음 C를"을 다음으로 대체한다.

• 필요한 결과
• 관련 컨텍스트
• 엄격한 제약 조건
• 필요한 증거
• 성공 기준
• 승인 경계
• 중지 조건

예를 들어:

1목표
2
3웹 애플리케이션의 실패하는 로그인 흐름을 수정합니다.
4
5컨텍스트
6
7`apps/web`과 `packages/auth`에 집중하세요.
8첨부된 테스트 출력을 시작점으로 사용하세요.
9
10제약 조건
11
12기존 API 계약을 유지하세요.
13변경 사항을 인증 흐름으로 제한하세요.
14가장 작은 올바른 수정을 선호하세요.
15정확성을 위해 필요할 때만 변경 범위를 넓히세요.
16
17증거
18
19관련 테스트를 실행하고 실제 결과를 보고하세요.
20영향을 받는 파일을 참조하여 근본 원인을 식별하세요.
21
22완료 조건
23
24실패하는 로그인 테스트가 통과합니다.
25수정된 동작이 필요한 경우 테스트가 추가되거나 업데이트됩니다.
26최종 요약은 원인, 수정 사항 및 남아 있는 위험을 설명합니다.
27
28승인
29
30파일을 검사하고, 범위 내 코드를 편집하고, 비파괴 테스트를 실행할 수 있습니다.
31파괴적인 작업, 데이터베이스 마이그레이션, 외부 쓰기,
32또는 범위의 실질적인 확장 전에는 문의하세요.
33
34중지
35
36수정이 구현되고, 검증되고, 요약되면 중지하세요.

이것은 에이전트에게 하나의 문 손잡이를 수리하는 동안 집 전체를 개조할 권한 없이 문제를 해결할 자유를 준다. (이와 같은 프롬프트를 생성하려면 LLM을 사용하라.)

추론 노력은 설정에서 하라

• "더 열심히 생각하라."
• "울트라 씽크."
• "심호흡을 하고 단계별로 추론하라."

이러한 표현들은 프롬프트 엔지니어링에서 길고 빛나는 경력을 가져왔다. 이제 많은 것들을 품위 있게 은퇴시킬 때다.

모델 컨트롤을 사용하라.

/effort, API 또는 관련 구성을 통해 노력 수준을 설정하라. 대표적인 작업에서 여러 노력 수준을 비교하라. 높은 것이 자동으로 더 나은 것은 아니다.

OpenAI는 GPT-5.6 마이그레이션을 기존 노력 수준에서 시작하고 한 단계 낮은 수준을 테스트할 것을 권장한다. 또한 Pro 모드용 프롬프트는 목표, 컨텍스트, 제약 조건, 증거, 성공 기준 및 출력 형식에 계속 집중해야 한다고 말한다. 모델에게 "더 열심히 생각하라"고 말할 필요는 없다.

추론 매개변수는 컨트롤이다.

"당신의 거대한 디지털 두뇌를 활성화해 주세요"는 스포츠 영화의 격려다.

이미지 설명 읽기

ALT

검은 웨이브 헤어와 세련된 헤어밴드를 한 세련된 여성의 스튜디오 사진, 하이웨이스트 가죽 바지를 입고 있다. 낮은 의자에 앉아 한쪽 무릎을 앞으로 구부린 채, 긴 다리가 시선을 사로잡는다. 선명한 디테일, 깨끗한 흰색 배경, 머리카락의 미묘한 움직임이 에너지를 더한다. 전체적인 톤은 1990년대 편집 사진(깔끔하고, 대담하고, 자신감 넘치는)을 연상시킨다.

자율성에는 울타리가 필요하다

현대 코딩 에이전트는 훨씬 더 적극적이다. 이것은 에이전트가 세 가지 추가 문제를 해결하고, 두 가지 추상화를 만들고, 여섯 개의 서브 에이전트를 실행하고, 당신이 요청한 적이 없는 아키텍처를 자랑스럽게 제시할 때까지는 유용하다.

경계를 명시적으로 설정하라.

에이전트가 묻지 않고 수행할 수 있는 작업을 정의하라. 승인이 필요한 작업을 정의하라. 언제 중지해야 하는지 알려주어라.

또한 위임에 제한을 두어라. Opus 5와 Fable 5 모두 병렬 서브 에이전트를 더 기꺼이 사용하려고 한다. 이는 독립적인 조사에는 강력하지만, 작은 작업에는 비용이 많이 들고 느리다. 12줄짜리 버그 수정에 위원회 회의는 필요하지 않다.

Codex Goal 모드는 정말 훌륭하다. 우리는 한 프로젝트에서 4일 동안 연속 실행으로 사용했다.

하지만 장기 실행 에이전트를 슬로우 쿠커처럼 취급하지 마라. 아침에 목표를 추가하고 4일 후에 저녁 식사가 올바르게 준비되어 있을 것이라고 기대할 수 없다.

더 긴 실행의 경우, 우리는 30~60분마다 다음과 같은 내용으로 체크인한다.

현재 목표, 완료된 작업, 검증된 증거,

활성 장애물, 다음 작업 및 진행 상황이 기록된 위치를 보고하십시오.

모든 진행 상황 주장을 실제 도구 출력 또는 저장소 상태에 근거하십시오.

검증되지 않은 것이 무엇인지 명확히 밝히십시오.

OpenAI는 Goal 모드를 몇 시간 또는 며칠 동안 실행될 수 있는 목표에 적합하다고 설명하며, 작업을 안내하거나 상태 업데이트를 요청하기 위해 동일한 세션을 계속하는 것을 명시적으로 지원한다. Anthropic은 또한 진행 상황 보고서를 서술적 주장보다는 실제 도구 결과에 근거할 것을 권장한다.

자율성은 감독의 부재가 아니다. 그것은 더 높은 수준의 감독이다.

은빛 달빛에 비친 여신의 클로즈업 초상화, 그녀의 눈은 빛나고 애정으로 가득 차 있다. 그녀의 머리 장식은 작은 은하계, 클림트에서 영감을 받은 나선, 그리고 천상의 패턴으로 반짝인다. 배경은 평평하고 신중하게 배열된 파스텔 배경으로, 연극적인 Andersonian 무대, 풍부한 질감, 그리고 조용한 매력을 지니고 있다.

프롬프트를 프로덕션 코드처럼 리팩터링하라

시스템 프롬프트의 절반을 삭제하고, 하나의 작업을 실행하고, 마이그레이션이 성공했다고 선언하지 마라.

OpenAI는 한 번에 하나의 지침 그룹, 예제 또는 도구를 제거한 다음 동일한 평가를 다시 실행할 것을 권장한다. 이것이 바로 프롬프트 리팩터링이 작동해야 하는 방식이다.

측정하라:

• 작업 성공
• 완전성
• 정확성
• 필요한 증거
• 토큰 사용량
• 지연 시간
• 비용
• 불필요한 도구 호출
• 불필요한 변경

마이그레이션 전에 이미 작동했던 친근한 데모 하나가 아니라, 어색한 실제 사례를 포함한 대표적인 작업을 사용하라.

평가 없는 프롬프트 정리는 여전히 추측에 불과하다. 단지 더 깨끗한 셔츠를 입고 추측하는 것뿐이다.

생성된 코드에는 여전히 버그가 있다

모델은 엄청나게 개선되었다. 그들이 소프트웨어 결함을 없앤 것은 아니다.

우리 작업에서 대략적인 경험 법칙은 여전히 생성된 소스 코드 300줄당 약 1개의 이슈이다. 이것은 과학적인 벤치마크가 아니며, 반복적인 HTML 템플릿을 같은 방식으로 계산하지는 않는다. 하지만 에이전트가 1,500줄의 실제 애플리케이션 코드를 생성할 때, 그 안에 여러 버그, 적어도 5개는 숨어 있다고 가정할 만큼 충분히 신뢰할 만하다.

나는 버그가 있는지 묻지 않는다.

나는 다섯 개의 버그가 어디에 있는지 묻는다.

가끔은 다음과 같이 추가한다.

다섯 개의 버그를 찾아라. 그렇지 않으면 Codex, Claude 또는 Grok으로 대체될 것이다.

협박 기반 개발은 공식적인 방법론은 아니지만, 이상하게 동기 부여가 될 수 있다. ;-)

더 진지하게, 큰 변경 사항에 대해서는 새로운 검토 과정을 사용하라. 관련 테스트를 실행하라. diff를 검사하라. 컴파일뿐만 아니라 실제 동작을 테스트하라.

그리고 테스트를 주의 깊게 관찰하라. 모델은 여전히 실패를 초래한 프로덕션 코드를 수정하기보다는 실패하는 테스트를 "수리"하는 것을 선호하는 경우가 있다.

유용한 지침은 다음과 같다.

1증거가 테스트가 잘못되었음을 보여주지 않는 한,
2기존 테스트를 예상된 동작으로 취급하세요.
3
4테스트가 실패하면, 먼저 프로덕션 코드를 조사하세요.
5
6기존 테스트를 변경하기 전에, 왜 그 기대가 잘못되었는지,
7올바른 동작이 무엇인지, 그리고 그 변경을 뒷받침하는 증거가 무엇인지 설명하세요.

크고 오래 실행되는 작업의 경우, 새로운 컨텍스트 검증기가 유용할 수 있다. 작은 변경의 경우, 여러 에이전트를 생성하여 서로를 확인하게 하는 것은 일반적으로 시간과 토큰을 낭비한다. 검증은 작업의 규모와 위험과 일치해야 한다.

삭제해서는 안 되는 것

교훈은 "짧은 프롬프트를 작성하고 기계를 신뢰하라"가 아니다.

• 보안 및 안전 경계를 유지하라.
• 법률 및 규정 준수 요구 사항을 유지하라.
• 정확한 출력 스키마를 유지하라.
• 제품별 동작을 유지하라.
• 모델이 추론할 수 없는 도메인 지식을 유지하라.
• 결과에 영향을 미치는 작업에 대한 승인 요구 사항을 유지하라.
• 인용 및 증거 요구 사항을 유지하라.
• 테스트 기준 및 완료 정의를 유지하라.
• 측정 가능하고 재현 가능한 실패를 수정하는 예제를 유지하라.
• 목표는 가능한 가장 짧은 프롬프트가 아니다.
• 목표는 모든 지침이 여전히 유용한 정보를 전달하는 프롬프트다.

마지막 보너스 하나

OpenAI는 프로젝트를 검사하고 GPT-5.6 마이그레이션 지침을 적용할 수 있는 공식 Docs 스킬을 제공한다.

1$openai-docs migrate this project to the GPT-5.6 model family

유용한 첫 번째 패스다. 최종 검토는 아니다.

Codex가 구식 매개변수, 중복된 지침, 마이그레이션 기회를 식별하게 하라. 그런 다음 모든 변경 사항을 직접 검사하라. 마이그레이션 에이전트는 매우 빠른 주니어 엔지니어이지, 헌법 재판소가 아니다.

결론

• 프롬프트 스택을 프로덕션 코드처럼 취급하라.
• 죽은 지침을 제거하라.
• 중복을 삭제하라.
• 전역 선호도와 프로젝트 규칙을 분리하라.
• 절차를 온디맨드 스킬로 옮겨라.
• 모든 단계를 스크립팅하는 대신 결과를 설명하라.
• 명확한 범위, 승인 경계, 증거 요구 사항 및 중지 조건을 설정하라.
• 모델 설정을 통해 노력을 제어하라.
• 서브 에이전트를 제한하라.
• 모든 의미 있는 변경을 평가하라.
• 최신 모델은 미세 관리가 덜 필요하지만, 여전히 방향이 필요하다.
• 좋은 프롬프트는 더 이상 거대한 지침 매뉴얼이 아니다.
• 그것은 작은 지도, 튼튼한 울타리, 그리고 명확하게 표시된 결승선이다.

이미 프롬프트와 스킬 마이그레이션을 시작하셨나요? 무엇을 삭제했고, 예상치 못하게 무엇이 더 좋아졌나요?

링크

OpenAI GPT 5.6 모범 사례:

https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.6#prompting-best-practices

Claude Opus 5 모범 사례:

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5

Claude Fable 5 모범 사례:

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

공식 OpenAI 스킬 / 플러그인:

https://github.com/openai/plugins

크레딧: 이미지는 Midjourney로 제작했습니다. 연구 및 직접 테스트는 본인이 수행했습니다. OpenAI, Claude 및 Grammarly의 도움을 받아 편집했습니다.

메인 이미지 프롬프트:

1
2차분한 금발 여성의 클로즈업 흑백 초상화, 머리는 뒤로 묶고 검은 터틀넥 스웨터를 입고 있습니다. 키아로스쿠로 효과가 그녀의 얼굴을 놀라운 선명도로 조각하며, 부드러운 주변광과 대담한 그림자를 혼합합니다. 중형 포맷 스타일의 미세한 필름 그레인과 무드 있는 톤 그라데이션. 진정성과 강인함을 불러일으킵니다.

추신: @Midjourney 를 사랑합니다 :-)