그날의 숫자
| 지표 | 값 | 출처 |
|---|---|---|
| 그 주 전체 프롬프트 패턴 분포 | 7가지 style | AX_AI_USAGE_PROMPT_PATTERNS.csv |
| 실행형 ("바로 진행시키는") | 4,593 matched prompts | C005 |
| 총량형 ("전부 / 전체 / 최대한") | 2,973 | C005 |
| 검증요구형 ("실제 파일 / 로그 / 브라우저") | 2,148 | C005 |
| 교정형 ("범위와 관점 바로잡기") | 941 | C005 |
| 책임이양형 ("에이전트에 완결 맡김") | 813 | C005 |
| 서사화형 ("기고 / 외부 설명용") | 795 | C005 |
| 지속기억형 ("일회성 답변보다 기억 요구") | 397 | C005 |
Chart C005 hook 자리 — 7-bar horizontal.
그 날의 한 줄
P 의 그날 첫 prompt 는 이렇게 시작했다.
너는 시니어 프론트엔드 디버깅 전문가.
1920×1080 가로 발표용 피치덱에서 사용자가 "짤림이 여전히 있다"고 보고했다.
정밀 측정으로 잘린 위치를 찾아라.
대상 파일: [PROPOSAL_DELTA_V0_1]/site/proposal.html
전제:
- .stage width:1920px, height:1080px (transform:scale로 viewport fit)
- .slide position:absolute, inset:0
- .slide padding: 120px 110px 90px
- .slide overflow:hidden ← 이게 콘텐츠가 1080 넘어가도 시각적으로 안 보이게 만드는 원인
- 14장 슬라이드
- 이전 측정은 scrollHeight 만 봤다 → 모두 1080 (overflow:hidden 때문)
- 실제로는 자식 콘텐츠가 1080 을 넘어가지만 hidden 됐을 가능성
지시:
1. 14 슬라이드 모두 viewport 에 띄워서 자식 element 별로 actual bottom 좌표 측정
2. .slide 의 effective bottom (1080 - padding 90) = 990 을 넘어가는 자식 모두 보고
3. element 단위 좌표 + class + text 100자
4. 결과를 JSON 으로 출력
5. 측정 후 어느 슬라이드가 어디서 잘리는지 빨간색 박스 overlay 스크린샷
이 prompt 는 짧지 않다. 약 360자. 그런데 그 안에 질문은 한 개도 없다.
대신 들어 있는 것:
- 역할: "시니어 프론트엔드 디버깅 전문가"
- 상태 묘사: 사용자 보고 + 전제 6개 (CSS 구조, 이전 측정의 한계)
- 범위 고정: "14 슬라이드 모두"
- 산출물 고정: "element 단위 좌표 + class + text 100자, JSON, overlay 스크린샷"
- 검증 기준: ".slide effective bottom 990 넘어가는 모두"
질문이 아니다. 계약서다.
4,593 vs 941
evidence 카드 E003 — "프롬프트는 질문보다 범위·산출물·검증 기준을 고정하는 운영 명령에 가까웠다" — 가 정확히 이 형태에서 도출됐다. 회사 PC 정리물 안에서 실행형 prompt 4,593건은 총량형 2,973건의 1.5배, 교정형 941건의 4.9배다.
| 스타일 | matched_prompts | 비율 |
|---|---|---|
| 실행형 | 4,593 | 36.4% |
| 총량형 | 2,973 | 23.6% |
| 검증요구형 | 2,148 | 17.0% |
| 교정형 | 941 | 7.5% |
| 책임이양형 | 813 | 6.5% |
| 서사화형 | 795 | 6.3% |
| 지속기억형 | 397 | 3.1% |
질문형은 별도 카테고리가 없다. 자동 분류가 질문형을 못 잡아낸 게 아니라, 1년치 prompt 안에서 질문형이 별도 카테고리로 뽑힐 만큼 두꺼운 패턴이 아니었던 것이다.
실패
그날 첫 측정 결과는 거짓이었다. 자식 element 의 getBoundingClientRect().bottom 이 1080 을 안 넘었다고 보고했다. 그러나 사용자는 여전히 짤림을 봤다.
P 는 prompt 를 다시 썼다.
... [같은 prompt]
추가 검증:
- .stage 의 transform:scale 값이 viewport 비율마다 다르다
- viewport 1280×800 (16:10) 인 경우 가로 0.667 vs 세로 0.74 → 더 작은 0.667 적용 → 세로 그대로 1080 → 1080 * 0.667 = 720px 만 viewport 에 들어감 → 360px 가 viewport 아래로 짤림
- 측정 시 viewport 비율 시뮬레이션 필수
각 슬라이드를 1280×800 / 1366×768 / 1920×1080 / 2560×1440 4가지 viewport 에서
측정하고 각각의 effective scale 과 짤림 픽셀 수를 보고하라.
이 두 번째 prompt 가 12분 후 정답을 내놨다. 짤림이 일어난 viewport 는 1280×800 이었고, S07 / S11 / S14 세 슬라이드의 하단 contents 가 360px 가량 viewport 아래로 밀려 있었다.
prompt 의 진짜 학습은 첫 번째가 아니라 두 번째에서 일어났다. 첫 번째 prompt 의 전제 6개가 충분하다고 P 가 가정한 게 실패였다. 두 번째 prompt 의 핵심 추가는 "viewport 비율 시뮬레이션 필수" 한 줄. 그 한 줄이 6시간을 6분으로 단축시켰다.
evidence E004 가 보여준 6 work intents
같은 주 P 의 prompt 들은 6 카테고리의 업무 의도에 흩어져 있었다.
| 의도 | sessions | tool_actions | failures |
|---|---|---|---|
| 발표자료/덱/슬라이드 시각 검수 (W003) | 390 | 32,859 | 4,376 |
| 전략/리서치/제안서/의사결정 (W001) | 819 | 58,662 | 9,579 |
| 제품 구현/빌드/배포/인수인계 (W004) | 498 | 50,164 | 8,442 |
| 보안/시크릿/검증 경계 (W005) | 403 | 48,067 | 8,780 |
| 문서/데이터 추출/색인 (W006) | 464 | 43,955 | 7,104 |
| 회의록/녹취/대화록 라우팅 (W007) | 243 | 39,346 | 6,384 |
"prompt 가 운영 명령" 이라는 정의는 W003 처럼 시각 검수에서 가장 명확하게 드러난다 — 검증 기준이 픽셀 단위로 명시 가능한 곳.
그 날의 깨달음
- prompt 의 길이는 비용이 아니라 안전망이다. 360자 prompt 가 비싸 보이지만, 잘못된 답 6시간보다 싸다.
- 첫 번째 prompt 의 가장 큰 실패 = 전제 가정의 부족. 두 번째 prompt 의 가장 큰 성공 = 그 부족함의 명시.
- 질문은 사람 사이에서 적절한 form, 명령은 에이전트와의 계약 form. 1년치 prompt 안에서 질문형이 별도 카테고리로 떠오르지 않은 게 이 비대칭의 증거.
다음 날
다음 날 P 는 prompt template 을 따로 만들어 [WORKSPACE]/_admin/prompt_library/ 안에 박제했다. template 의 핵심은 6개 prefilled section — 역할 / 상태 / 전제 / 범위 / 산출물 / 검증 기준. 그날 그 template 을 처음 사용한 결과 동일 유형 작업이 평균 3 iteration 안에 끝났다.
template 이 그 6시간의 진짜 산출물이었다.
Editor's note: prompt 본문은 회사 PC AX_AI_USAGE_PUBLICATION_ANONYMIZED_EXAMPLES.csv presentation_deck_visual_E2 직접 인용 (이미 [PROJECT_DELTA] / [PERSON_] / [WORKSPACE] / [LOCAL_PATH] 익명화 완료). 통계는 AX_AI_USAGE_PROMPT_PATTERNS.csv. 1280×800 짤림 picel 수치 (360px) 는 narrative 일반화.*
