r/ClaudeCode•4개월 전•5•29

내 프롬프트가 너무 복잡한가?

Am I over complicating my prompts?

핵심 요약

Claude Code 사용 시 지나치게 상세한 프롬프트가 오히려 모델의 성능을 저하시키는지에 대한 고민과 조언.

프롬프트 비대화 — 지나치게 상세한 제약 조건이 오히려 모델의 추론 능력을 방해함.
부정적 지시 지양 — '하지 마라'는 식의 부정 명령보다 긍정적인 지시가 더 효과적임.
워크플로우 최적화 — 반복 작업은 CLAUDE.md나 별도의 계획 모드를 활용하는 것이 효율적임.
모델별 차이 — Opus와 Sonnet 등 모델마다 프롬프트 최적화 방식이 다름을 인지해야 함.

Claude Code에 구조화된 프롬프트를 직접 입력하는 걸 좋아하는데, 좀 과한 것 같기도 함. 비교적 단순한 코드베이스라 ChatGPT로 프롬프트를 생성해서 Claude에 입력하는데 아주 잘 작동함. Claude가 각 슬라이스마다 수행하는 모든 작업을 문서화하게 하고, 검토 후 승인되면 문서에 표시함. 아래는 내가 쓰던 긴 프롬프트 예시임. 최소 5분은 걸리고 토큰도 엄청 잡아먹음. 근데 오늘부터 짧은 프롬프트를 써봤는데 똑같은 결과를 15초 만에 냄. 장기적으로는 긴 프롬프트가 오류가 적을 것 같긴 한데, 그럴 가치가 있을까? 다들 CC에 어떤 프롬프트를 보내는지 궁금함.

짧은 프롬프트:

mark SPECIALORDERS-CREATE-FLOW-CUSTOMER-FIRST-CONTRACT-001 as approved

긴 프롬프트:

Act as Claude Code performing an approval-recording docs update only.

Context:
Principal Engineer reviewed:

SPECIALORDERS-CREATE-FLOW-CUSTOMER-FIRST-CONTRACT-001

Principal Review verdict:

READY TO PROCEED

Task:
Record this Principal Review approval in the repo’s durable docs.

Strict scope:

Do not change runtime code.
Do not change templates.
Do not change tests.
Do not change URLs.
Do not change views.
Do not change services.
Do not change models.
Do not create migrations.
Do not start the next slice.
Do not add implementation details to slice_roadmap.md.
Do not bloat executive_summary.md / executive_handoff.md.
Do not mark any future slice as implemented.

Required docs to update:

slice_roadmap.md
docs/archive/slices/SPECIALORDERS-CREATE-FLOW-CUSTOMER-FIRST-CONTRACT-001.md

Durable-doc discipline:

slice_roadmap.md must remain concise.
Update only the status/verdict for SPECIALORDERS-CREATE-FLOW-CUSTOMER-FIRST-CONTRACT-001.
The entry may say APPROVED / READY TO PROCEED with the Principal Review date.
Leave detailed design content in the archive doc.
The archive doc may record the Principal Review verdict.
executive_summary.md / executive_handoff.md should not be updated unless it already has an incorrect status for this slice.
docs/planning/future_slice_backlog.md should not be updated unless it already has an incorrect status for this slice.

원문

커뮤니티 목록

r/ClaudeCode•4개월 전•5•29

내 프롬프트가 너무 복잡한가?

Am I over complicating my prompts?

핵심 요약

Claude Code 사용 시 지나치게 상세한 프롬프트가 오히려 모델의 성능을 저하시키는지에 대한 고민과 조언.

프롬프트 비대화 — 지나치게 상세한 제약 조건이 오히려 모델의 추론 능력을 방해함.
부정적 지시 지양 — '하지 마라'는 식의 부정 명령보다 긍정적인 지시가 더 효과적임.
워크플로우 최적화 — 반복 작업은 CLAUDE.md나 별도의 계획 모드를 활용하는 것이 효율적임.
모델별 차이 — Opus와 Sonnet 등 모델마다 프롬프트 최적화 방식이 다름을 인지해야 함.

짧은 프롬프트:

mark SPECIALORDERS-CREATE-FLOW-CUSTOMER-FIRST-CONTRACT-001 as approved

긴 프롬프트:

Act as Claude Code performing an approval-recording docs update only.

Context:
Principal Engineer reviewed:

SPECIALORDERS-CREATE-FLOW-CUSTOMER-FIRST-CONTRACT-001

Principal Review verdict:

READY TO PROCEED

Task:
Record this Principal Review approval in the repo’s durable docs.

Strict scope:

Do not change runtime code.
Do not change templates.
Do not change tests.
Do not change URLs.
Do not change views.
Do not change services.
Do not change models.
Do not create migrations.
Do not start the next slice.
Do not add implementation details to slice_roadmap.md.
Do not bloat executive_summary.md / executive_handoff.md.
Do not mark any future slice as implemented.

Required docs to update:

slice_roadmap.md
docs/archive/slices/SPECIALORDERS-CREATE-FLOW-CUSTOMER-FIRST-CONTRACT-001.md

Durable-doc discipline:

slice_roadmap.md must remain concise.
Update only the status/verdict for SPECIALORDERS-CREATE-FLOW-CUSTOMER-FIRST-CONTRACT-001.
The entry may say APPROVED / READY TO PROCEED with the Principal Review date.
Leave detailed design content in the archive doc.
The archive doc may record the Principal Review verdict.
executive_summary.md / executive_handoff.md should not be updated unless it already has an incorrect status for this slice.
docs/planning/future_slice_backlog.md should not be updated unless it already has an incorrect status for this slice.

주요 댓글

r/claudecode

지나치게 상세한 프롬프트보다는 모델의 추론 능력을 믿고, 제약 조건보다는 명확한 지시를 내리며, CLAUDE.md 같은 시스템 파일을 활용하라는 조언이 주를 이룸.

요즘은 사소하지 않지만 작은 작업은 내장된 계획 모드를 사용해. 중요한 건 github.speckit 같은 제3자 계획 프로세스를 거치지. 이건 네 질문과 관련이 있는데, 이런 경우엔 프롬프트가 아니라 사양(spec)을 작성하고 CLAUDE.md, 메모리, 그리고 수많은 README와 아키텍처 분석 문서를 참고해서 사양, 계획, 작업을 개발하도록 유도하거든. AI 자체가 실제 프롬프트 생성을 처리하는 방식이지.

아직 CLAUDE.md 파일은 안 쓰는데, 비슷한 방식으로 구체적인 파일들을 참조하긴 해. 근데 프롬프트에 그걸 다 언급해야 해서 프롬프트가 더 비대해지는 것 같아. 내 워크플로우가 꽤 잘 작동하긴 하지만 확실히 개선이 필요해. 거의 다 온 것 같아. 의견 고마워.

4.7은 특히 '하지 마라'는 문구를 안 좋아해. 대신 뭘 해야 할지를 말해줘. 그리고 CLAUDE.md를 사용해.

정확히 이거야. 딥 씽킹 모델에서 'x를 하지 마라' 같은 초강력 제약을 걸면, 모델이 더 나은 방법을 찾았는데도 제약 때문에 못 해서 생각의 사슬(chain of thought) 안에서 갇혀 무한 루프를 돌게 돼. 4.7 Opus나 qwen3.6 씽킹 모드도 같은 문제가 있어. 모델이 스스로 추론하게 두는 게 최고야. 엄격하게 하고 싶으면 Sonnet이나 Haiku를 써. 추론하게 하고 싶으면 출력에 대한 가이드를 제공해야 해.

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

하하, QWEN이 Opus 출력을 학습 데이터로 썼다는 게 딱 보이네. 솔직히 Anthropic의 프롬프트 문서에도 나와 있는 내용이라 Opus의 의도된 동작이지 꼭 문제라고 볼 순 없어.

오, 당연히 문제는 아니지. 하지만 Sonnet 4.6에 쓰는 프롬프트를 Opus 4.7에 그대로 쓰면 같은 결과를 얻을 순 없을 거야.

맞아, 프롬프트 문서에 두 모델 모두에 대한 가이드가 다 있어.

프롬프트 요소 중 많은 부분은 CLAUDE.md(또는 AGENTS.md 등)에 넣을 수 있어. 작업에 따라 변동이 있다면 그 변동성을 포함하거나 그걸 포괄하는 기술(skill)을 작성할 수도 있고. 왜 그걸 다 프롬프트에 넣는지 모르겠네. 그리고 '하지 마라'고 하는 것보다 '뭘 하라'고 말하는 게 더 잘 먹힐 거야.

프롬프트를 확실히 줄여야겠네. '하지 마라'는 표현은 줄이거나 없애야겠어. 도와줘서 고마워.

ChatGPT가 프롬프트를 쓰게 하는 건 괜찮아. 근데 그렇게 쓰게 하지는 마. 다음엔 이렇게 해봐. 대화가 끝나고 GPT가 프롬프트를 쓰게 할 때, 대신 이렇게 말해봐: '내 개발자에게 보낼 편지를 써줘(인사는 생략). 우리가 여기서 논의한 내용과 내가 달성하고 싶은 걸 말해줘. 코드를 잔뜩 쓰지 마. 그는 아주 똑똑하니까. 그냥 무엇을, 왜 해야 하는지만 설명해.' 네 워크플로우에 아주 잘 맞을 거야.

그렇게 많은 '하지 마라'로 모델 품질을 떨어뜨리고 있어. 프롬프트에 의존하지 말고, 계획을 검토해서 그런 일을 안 하도록 확인해야지. '해라/하지 마라' 목록이 너무 길면 Claude는 지시사항을 잊거나 무시하기로 유명해.

젠장, 거의 모든 프롬프트에 명시적인 '하지 마라' 섹션이 있었는데. 다시 생각해봐야겠네. 지금 실행 중인 구현 프롬프트의 일부 예시야. 너무 복잡하게 만들고 있는 것 같아서 이 글을 쓴 건데! 의견 고마워. 명시적 비목표: - 고객 선택 중에 SpecialOrder를 생성하지 마라.

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

응, 이거 엄청나게 비대해. Claude의 시스템 프롬프트 자체가 이미 거대한 엉망진창이라는 걸 명심해야 해. 넌 그 위에 모순되는 쓰레기를 얹고 있는 거야. 아마 같은 프롬프트 안에서 에이전트한테 x를 하라고 하고 동시에 하지 말라고 하고 있을 텐데, 그게 너무 많은 컨텍스트를 넣었을 때 발생하는 문제야.

원문r/ClaudeCode