ESC(Equalizer + Socratic + Chain) Prompting — 일관된 결과를 만드는 실전 프롬프트 프레임워크
ESC(Equalizer + Socratic + Chain) Prompting — 일관된 결과를 만드는 실전 프롬프트 프레임워크
LLM을 쓰다 보면 이런 순간이 자주 옵니다.
같은 요청을 했는데 결과가 들쭉날쭉하다
답이 “그럴듯”한데, 내 상황/제약을 잘못 가정한다
한 번에 끝내려다가, 수정 요청을 여러 번 왕복한다
이럴 때 도움이 되는 프롬프트 운영 방식이 ESC (Equalizer + Socratic + Chain) Prompting입니다.
핵심은 “좋은 문장 하나”를 만드는 게 아니라, 대화를 3단계로 설계해서 품질을 안정화하는 것입니다.
ESC Prompting 한 문장 정의
ESC는 아래 흐름으로 LLM과 일을 나누는 프레임워크입니다.
- Equalizer: 목표/제약/용어/출력형식을 먼저 맞춰서(정렬해서) 오해를 줄인다
- Socratic: 질문을 통해 요구사항을 명확히 하고, 빠진 정보/리스크를 드러낸다
- Chain: 작업을 단계로 쪼개어 계획→실행→검증 순서로 결과물을 만든다
왜 ESC를 써야 하나 (프롬프트가 “안정”해지는 이유)
LLM 결과가 흔들리는 큰 이유는 대체로 세 가지입니다.
- 입력의 모호함: 내 업무 맥락이 빠져 있거나, “좋게 알아서”의 영역이 너무 큼
- 숨은 제약의 누락: 시간/도구/버전/정책/포맷/금지사항이 뒤늦게 등장
- 작업이 한 번에 너무 큼: 큰 문제를 한 번에 요청하면, 중요한 누락이 생기기 쉬움
ESC는 이 문제를 구조적으로 막습니다.
- Equalizer가 “추측 기반 답변”을 줄이고
- Socratic이 “필수 질문”을 앞당기며
- Chain이 “한 번에 큰 실수” 대신 “작은 단계의 누적”으로 완성도를 올립니다
1) Equalizer: 기준을 먼저 맞추는 단계
Equalizer는 말 그대로 모델과 기준을 동일하게 맞추는 단계입니다. 특히 아래를 먼저 고정하면 효과가 큽니다.
- 목표: 무엇을 만들고/결정하고/해결하고 싶은가
- 환경: 언어/프레임워크/버전/운영체제/배포 환경
- 제약: 시간, 정책, 보안, 금지사항, 사용 가능한 도구
- 출력 형식: 마크다운, 체크리스트, 코드, 표, 섹션 구성
- 성공 기준: 무엇이 “완료”인지
예시 템플릿:
[Equalizer]
목표: (무엇을 얻고 싶은지)
배경/맥락: (현재 상태, 문제 상황)
환경: (언어/프레임워크/버전/OS/도구)
제약: (시간, 정책, 금지사항, 선호)
출력 형식: (예: 마크다운 포스트, 섹션 헤딩, 예시 포함)
성공 기준: (검증 가능한 완료 조건)
2) Socratic: 답을 내기 전에 “필수 질문”을 하는 단계
Socratic은 “바로 답하기”를 잠깐 멈추고, 성공에 필요한 질문을 먼저 던지는 단계입니다.
좋은 소크라테스 질문은 보통 아래 축으로 구성됩니다.
- 범위: 어디까지/어디부터는 제외?
- 우선순위: 가장 중요한 1~2개는?
- 대상: 독자/사용자/고객이 누구?
- 리스크: 실패하면 어떤 비용이 큰가?
- 예시/반례: 원하는 예/원하지 않는 예는?
예시 템플릿:
[Socratic]
정확도를 위해 5~8개 질문만 먼저 할게요.
1) (핵심 모호점 질문)
2) (환경/버전/데이터 확인)
3) (범위/우선순위)
4) (금지사항/정책/보안)
5) (원하는 출력 예시/톤)
질문에 답하면 그 다음 단계로 바로 실행할게요.
“질문이 많아지면 느려지는 것 아닌가?”
오히려 반대인 경우가 많습니다. 질문 5개로 왕복 10번을 줄이는 구조라서요.
3) Chain: 계획→실행→검증을 ‘연쇄’로 진행하는 단계
Chain은 작업을 작은 단계로 쪼개어 진행합니다.
- Plan: 단계별 계획(짧게)
- Do: 단계별 결과물
- Check: 누락/모순/테스트/검증 체크
- Deliver: 최종 산출물(요구 형식대로)
예시 템플릿:
[Chain]
Step 1) 계획: (3~6단계로 짧게)
Step 2) 실행: (각 단계 결과물 생성)
Step 3) 검증: (체크리스트로 누락/모순 확인)
Step 4) 최종 출력: (요구한 포맷으로 정리)
ESC를 “복붙해서” 바로 쓰는 마스터 프롬프트
아래 블록을 그대로 복사해서, 괄호만 채우면 됩니다.
너는 (역할: 예: 시니어 엔지니어/기술 작가/PM)다.
[Equalizer]
목표: (내가 원하는 최종 결과)
배경/맥락: (현재 상황/문제/대상)
환경: (언어/프레임워크/버전/OS/도구)
제약: (시간, 정책, 금지사항, 선호)
출력 형식: (예: 마크다운, 섹션 구조, 톤, 길이)
성공 기준: (완료 조건)
[Socratic]
답을 만들기 전, 성공에 꼭 필요한 질문을 5~8개만 해줘.
각 질문은 “왜 필요한지”를 한 줄로 덧붙여줘.
[Chain]
내 답변을 받으면,
1) 짧은 실행 계획을 제시하고
2) 그 계획에 따라 결과물을 만들고
3) 마지막에 체크리스트로 검증해서
4) 최종 결과물만 깔끔하게 출력해줘.
활용 예시 1) “오늘자 블로그 포스트”를 안정적으로 쓰기
목표가 “글 작성”일 때 ESC가 특히 강한 이유는, 글은 톤/구성/독자/범위가 흔들리면 품질이 급락하기 때문입니다.
너는 기술 블로그 에디터다.
[Equalizer]
목표: ESC(Equalizer+Socratic+Chain) Prompting에 대한 오늘자 포스트 초안을 작성
배경/맥락: LLM 사용 시 결과가 들쭉날쭉해지는 문제를 해결하고 싶음
환경: 한국어, Jekyll 마크다운 포스트
제약: 과장 금지, 실무 관점, 예시 3개 이상 포함
출력 형식: (1) 제목 (2) 요약 (3) 본문 헤딩 구조 (4) 예시 프롬프트 블록 (5) 마무리
성공 기준: 초보자도 바로 따라할 수 있고, 왜 써야 하는지 납득됨
[Socratic]
글이 실제로 도움되려면 필요한 확인 질문 6개만 해줘.
[Chain]
질문 답변을 받으면, 섹션별로 글을 완성해줘.
왜 ESC가 좋나: 글을 “그럴듯하게” 쓰는 게 아니라, 독자/범위/형식을 먼저 맞춰서 편집 비용을 줄입니다.
활용 예시 2) 디버깅/원인 분석(로그 기반)에서의 ESC
디버깅은 “정보 부족”이 가장 큰 적입니다. ESC는 여기서 질문을 강제하고, 재현/검증 단계를 체계화합니다.
너는 시니어 백엔드 엔지니어다.
[Equalizer]
목표: 에러의 원인을 좁히고, 재현/수정/검증 플랜을 만든다
배경/맥락: (에러 메시지, 발생 시점, 영향 범위)
환경: (언어/프레임워크/버전/인프라: 예: Django 5, Postgres 16, Nginx)
제약: 프로덕션에서 위험한 변경 금지, 로그/메트릭 기반으로 우선 진단
출력 형식: (1) 가설 Top 3 (2) 확인 질문 (3) 진단 순서 (4) 수정안 (5) 검증 체크리스트
성공 기준: “다음 액션”이 명확하고, 실패해도 다음 분기가 준비됨
[Socratic]
원인 규명을 위해 꼭 필요한 질문을 우선순위대로 7개만 해줘.
[Chain]
답변을 받으면, 가장 싼 검증부터 순서대로 진단 플랜을 작성해줘.
왜 ESC가 좋나: 디버깅은 “답”보다 “절차”가 중요합니다. ESC는 절차를 자동으로 만들게 해서 랜덤 워크(찍기)를 줄입니다.
활용 예시 3) 요구사항이 자주 바뀌는 기능 기획/명세에서의 ESC
기획/명세는 “말이 바뀌는” 게 아니라, 초기 Equalizer가 없어서 기준이 없던 것인 경우가 많습니다.
너는 제품 기획자 겸 테크 리드다.
[Equalizer]
목표: 기능 요구사항을 PRD 수준으로 명확히 정리
배경/맥락: (기능 아이디어, 해결하려는 문제)
환경: (서비스 형태, 사용자, 플랫폼)
제약: 일정 (예: 2주 MVP), 인력(예: FE 1, BE 1), 정책/보안(예: 개인정보 최소화)
출력 형식: 문제정의 → 목표/비목표 → 유저 스토리 → 화면/플로우 → 데이터/이벤트 → 엣지케이스 → 수용 기준
성공 기준: 개발자가 구현 범위를 오해하지 않음
[Socratic]
PRD를 쓰기 위해 모호한 지점을 질문 8개만 해줘.
[Chain]
답변 후 PRD 초안을 작성하고, 마지막에 “누락 가능성 높은 항목” 체크리스트를 붙여줘.
왜 ESC가 좋나: “좋은 문서”가 아니라 오해를 줄이는 문서를 만들게 해줍니다.
ESC 운영 팁 (실전에서 더 잘 먹히는 방법)
- Equalizer는 짧게, 그러나 단호하게: 형식/제약/성공 기준은 초반에 못 박을수록 이득
- Socratic 질문 개수 제한: 5~8개로 제한하면 템포가 좋아짐(과도한 질문 방지)
- Chain에서 ‘검증’을 빼먹지 않기: 마지막 체크리스트가 품질을 올리는 핵심
- 반례를 한 줄 넣기: “이런 답은 원치 않는다” 한 줄이 결과를 크게 바꿈
정리
ESC Prompting은 “프롬프트 문장”이 아니라 프롬프트 운영 방식입니다.
기준을 맞추고(Equalizer), 질문으로 모호함을 제거하고(Socratic), 단계적으로 완성(Chain)하면 결과의 일관성과 재현성이 크게 올라갑니다.
다음번에 LLM이 자꾸 “잘못 알아서” 답을 만들거나, 수정 요청을 여러 번 왕복하고 있다면, 오늘부터는 한 번 ESC로 대화를 설계해보세요.