스킬북
프롬프트 설계법 EP.04
Claude 2026 기준
프롬프트 설계법 EP.04 — 제약 조건 설계하기, 원하지 않는 것을 없애는 법
(Claude 2026 기준)
프롬프트 제약 조건을 제대로 설계하면 Claude가 쓸데없는 말을 빼고 원하는 답만 정확히 준다. claude.ai에서 바로 적용해볼 수 있고, 아직 기본기가 없다면 프롬프트 설계법 EP.01과 EP.02 (Role Prompting)을 먼저 보고 오면 이해가 훨씬 빠르다.
지난주에 회사 보고서 초안을 Claude한테 맡긴 적이 있다. “이 내용 요약해줘”라고만 했더니, 분량이 A4 두 장 가까이 나왔다. 분명 짧게 쓰고 싶었는데, Claude는 친절하게도 배경 설명부터 결론까지 하나도 안 빼고 다 풀어줬다.
그래서 다음엔 “짧게 요약해줘, 너무 길게 쓰지 마”라고 다시 부탁했다. 그런데 결과가 더 이상했다. 분량은 줄었는데, 이번엔 “본 내용을 짧게 요약하면 다음과 같습니다”라는 군더더기 문장이 또 붙어 나왔다. 빼달라고 한 게 오히려 더 도드라진 느낌이었다.
이때 알게 된 게 프롬프트 제약 조건 설계법이다. 게임으로 치면 “이 무기는 사용 금지”라고 룰을 거는 게 아니라, “이 던전에서는 이 무기만 쓸 수 있음”이라고 조건을 거는 것에 가깝다. 뭘 빼라고 말하는 것보다, 어떤 틀 안에서 답하라고 말하는 게 훨씬 잘 먹힌다.
이 글에서 다루는 것
- 프롬프트 제약 조건이 왜 필요한지, 안 쓰면 어떤 일이 생기는지
- “하지 마”가 오히려 역효과를 내는 이유 — 부정문 제약의 함정
- 분량·형식·내용, 3가지 종류의 제약 조건 설계법
- 금지 표현을 “원하는 행동”으로 바꾸는 변환 공식
- 바로 복사해서 쓸 수 있는 실전 제약 템플릿 6가지
- 제약을 너무 많이 넣었을 때 생기는 역효과와 적정선
// 이런 분께 추천합니다
Claude 답변이 항상 너무 길게 나와서 매번 “짧게 줄여줘”를 반복 입력하는 분. 분명 빼달라고 한 표현이 답변에 그대로 다시 등장해서 답답했던 분. 그리고 EP.01~EP.02로 기본 구조와 역할 부여까지는 익혔지만, 결과물의 형태를 더 세밀하게 컨트롤하고 싶은 분께 딱 맞는 글이다.
🔥 중급자 이미 “~하지 마” 류 프롬프트를 쓰고 있다면, 변환 공식 위주로 읽기
// 필요 아이템
- Claude 계정 (무료도 가능)
- EP.01에서 배운 기본 프롬프트 구조 (역할·맥락·지시·형식)
- 최근에 Claude한테 받은 답변 중, “이 부분만 없었으면” 싶었던 결과물 하나 (실습용)
// 프롬프트 제약 조건 완전 정복 — 공략 시작
1. 제약 조건이 없으면 Claude는 ‘풀코스’로 답한다
Claude는 기본적으로 친절하고 성실하다. 질문에 짧게 답해도 될 상황에서도, 배경 설명 → 본론 → 부연 설명 → 마무리 인사까지 풀코스로 차려주는 경우가 많다. 이건 Claude가 “더 도움이 되고 싶다”는 방향으로 학습되어 있기 때문이다.
문제는 이게 항상 도움이 되는 건 아니라는 점이다. 슬랙 메시지 하나 쓰는데 서론·본론·결론이 다 들어간 답변이 필요한 경우는 거의 없다. 이럴 때 필요한 게 프롬프트 제약 조건이다. “이 틀 안에서만 답해줘”라고 미리 울타리를 쳐주는 것이다.
이건 게임에서 난이도 옵션을 고르는 것과도 비슷하다. 같은 던전이라도 “노멀 모드”와 “하드코어 모드”는 규칙이 다르다. 마찬가지로 같은 질문이라도 “보고서용 답변”과 “메신저용 답변”은 길이도, 말투도, 담아야 할 정보도 완전히 다르다. 제약 조건은 이 “모드”를 미리 설정해주는 작업이라고 생각하면 된다.
2. “하지 마”의 함정 — 부정문 제약이 역효과 나는 이유
가장 흔한 실수가 “~하지 마”라고만 쓰는 것이다. “전문 용어 쓰지 마”, “너무 길게 쓰지 마”, “사과하지 마” 같은 표현들. 직관적으로는 맞는 것 같지만, 실제로는 Claude가 그 단어 자체에 더 집중하게 만드는 경우가 많다.
“이 내용을 요약해줘. 단, ‘요약하면 다음과 같습니다’ 같은 표현은 쓰지 마.”
→ 그 표현은 안 쓰지만, 비슷한 다른 군더더기 문장(“정리해보면”, “핵심은 다음과 같이 정리할 수 있습니다”)이 새로 등장.
“이 내용을 핵심 문장 3개로만 답해줘. 첫 문장부터 바로 본론으로 시작해.”
→ 형식 자체가 “3문장”으로 고정되어 군더더기가 들어갈 자리가 없음.
핵심은 이거다. “무엇을 하지 마라”가 아니라 “무엇을 해라”로 바꿔서 말하면, Claude가 따를 틀 자체가 명확해진다. 빈 공간을 주고 “이건 채우지 마”라고 하는 것보다, 빈 공간 자체를 원하는 모양으로 미리 잘라주는 셈이다.
3. 제약 조건의 3가지 종류 — 분량·형식·내용
프롬프트 제약 조건은 크게 세 가지로 나눠서 생각하면 설계하기 쉽다.
분량 제약 + 형식 제약 + 내용 제약
예) “3문장 이내로, 불릿 포인트 없이 줄글로, 숫자 데이터 위주로 답해줘.”
분량 제약은 “몇 문장”, “몇 단어”, “한 화면 안에” 처럼 결과물의 크기를 정하는 것이다. “짧게”보다 “3문장 이내”, “200자 내외”처럼 숫자로 말하면 훨씬 정확하게 지켜진다.
형식 제약은 답변이 어떤 모양으로 나올지를 정한다. 표로, 번호 목록으로, 줄글로, 또는 “제목 없이 본문만”처럼 구조를 지정하는 것이다.
내용 제약은 어떤 정보를 포함하거나 제외할지를 정한다. 이때도 “~빼줘”보다는 “~만 포함해줘”로 말하는 게 훨씬 효과적이다.
4. 금지를 행동으로 바꾸는 변환 공식
이미 “~하지 마”로 습관이 든 프롬프트가 있다면, 아래 공식으로 바꿔보자. 핵심은 “금지된 행동의 빈자리에 무엇이 들어가야 하는지”를 직접 적어주는 것이다.
분량 줄이기
(전) “너무 길게 쓰지 마” → (후) “전체 5문장 이내로, 핵심만 압축해서 답해줘.”
군더더기 표현 제거
(전) “서론 쓰지 마” → (후) “첫 문장부터 바로 결론이나 핵심 정보로 시작해줘.”
전문 용어 제어
(전) “어려운 말 쓰지 마” → (후) “중학생도 이해할 수 있는 단어로만, 전문 용어는 쓸 때마다 한 줄로 풀어 설명해줘.”
사족·과장 제거
(전) “과장하지 마, 아첨하지 마” → (후) “장점과 단점을 50:50 비율로, 담백한 사실 위주로 평가해줘.”
출력 형식 고정
(전) “표로 만들지 마” → (후) “줄글 문단 2개로만 구성해서 답해줘. 표나 목록은 사용하지 않는 형식으로.”
정보 범위 제한
(전) “다른 얘기 하지 마” → (후) “이 문서에 적힌 내용만 근거로 답해줘. 문서에 없는 내용은 ‘문서에 없음’이라고 표시해줘.”
5. 제약은 도구다 — 잘 작동할 때 vs 효과가 떨어질 때
- 제약을 “원하는 행동”으로 구체적으로 표현했을 때 (숫자, 형식, 범위 명시)
- 제약 조건이 1~3개로 명확하게 정리되어 있을 때
- 역할(EP.02)·맥락과 제약이 서로 충돌하지 않을 때
- “~하지 마”만 5개, 6개씩 나열할 때 (Claude가 우선순위를 못 잡음)
- 제약이 너무 추상적일 때 (“적당히”, “너무 안 길게” 같은 표현)
- 분량 제약과 내용 제약이 서로 모순될 때 (예: “모든 항목을 다루되 1문장으로”)
// 플레이 일지 — 직접 써봤더니
예전에 영어 이메일 초안을 부탁하면서 “절대 격식체 쓰지 마, 너무 딱딱하게 쓰지 마”라고 했더니, 오히려 어색하게 캐주얼한 표현을 억지로 끼워 넣은 결과가 나온 적이 있다. 분명 자연스럽게 써달라고 한 건데, “안 딱딱하게”라는 말 자체에 꽂혀서 균형이 깨진 느낌이었다.
그래서 다음엔 이렇게 바꿔봤다. “동료에게 보내는 캐주얼한 업무 메일 톤으로, 인사말은 ‘Hi [이름],’으로 시작하고, 본문은 3문단 이내로 작성해줘.”
결과가 확실히 달라졌다. “딱딱하지 않게”라는 모호한 기준 대신, “동료에게 보내는 캐주얼한 업무 메일”이라는 구체적인 틀을 줬더니 Claude가 그 틀 안에서 자연스럽게 톤을 맞춰줬다. 분량 제약(3문단 이내)과 형식 제약(인사말 형식)을 같이 넣으니 결과물이 한 번에 거의 완성본에 가깝게 나왔다.
요즘은 Claude한테 뭔가 부탁할 때, 머릿속으로 “이 결과물이 어떤 모양이어야 하는가”를 먼저 그려본다. 그 모양을 숫자와 형식으로 옮기면, 그게 곧 제약 조건이 된다.
// 함정 & 주의사항
부정 명령어를 한꺼번에 너무 많이 넣지 말 것 — “이것도 하지 마, 저것도 하지 마”가 쌓이면 Claude가 정작 본 작업보다 ‘하지 말아야 할 것 피하기’에 더 신경 쓰게 된다. 1~2개로 추리고, 나머지는 긍정 제약으로 바꾸자.
제약끼리 서로 모순되지 않는지 확인할 것 — “모든 내용을 빠짐없이 담되 한 문장으로”처럼 분량 제약과 내용 제약이 충돌하면, Claude는 둘 중 하나를 포기하게 된다. 우선순위를 먼저 정해서 말해주자.
역할(EP.02)과 제약이 맞는지 점검할 것 — “너는 친절한 상담사야”라는 역할과 “공감 표현 쓰지 마”라는 제약은 서로 부딪힌다. 역할에 맞는 제약인지 한 번 더 확인하면 결과가 훨씬 안정적이다.
- “~하지 마”보다 “~해줘”로 바꿔 말하면 Claude가 따를 틀이 명확해진다
- 프롬프트 제약 조건은 분량·형식·내용, 세 가지로 나눠 설계하면 쉽다
- 분량은 “짧게”가 아니라 숫자(문장 수, 글자 수)로 명시하자
- 부정 명령어는 1~2개로 제한하고, 나머지는 긍정형 행동으로 변환하자
- 제약은 역할·맥락과 충돌하지 않는지 항상 같이 점검하자
// 포스트 크레딧
제약 조건으로 결과물의 ‘모양’을 잡았다면, 다음은 그 안에서 Claude가 ‘제대로 생각하게’ 만드는 차례다. 복잡한 문제일수록 Claude가 단계를 건너뛰고 바로 결론으로 가버리는 경우가 있는데, 이걸 막는 방법이 있다. 그 이야기는 다음 편 — 단계별로 생각하게 만드는 법, Chain of Thought 프롬프트에서.
제약 조건까지 익혔다면 Claude AI 완전 활용 가이드 2026에서 다른 실전 기법도 함께 확인해보자. 제약 조건 설계는 프롬프트 결과물의 형태를 컨트롤하는 핵심 기술이다.
