프롬프트 작성법을 다듬은 요청문은 5회 중 1번만 정답을 맞혔고, 간결한 문장은 5회 모두 9190엔에 도달했다

X에서 이런 정리글을 보았습니다. 프롬프트 엔지니어링 (Prompt Engineering)은 '어떻게 질문할지'를 고안하는 것이고,
컨텍스트 엔지니어링 (Context Engineering)은 '어떤 정보를 제공할지'를 설계하는 것입니다. 언어의 정의로서 어느 쪽이 맞는지, 어떤 방식이 우월한지는 저로서는 판단할 수 없습니다. 다만 '질문하는 방식을 다듬는 것'과 '자료를 제공하는 것'으로 결과가 달라지는지에 대해서는, 같은 질문을 조건만 바꿔 여러 번 던져보면 셀 수 있습니다.

그래서 저는 정답이 하나로 결정되는 질문을 직접 만들었습니다. 가상의 운임표를 한 장 놓고, 정답 금액은 미리 제가 계산하여 고정했습니다. 이후 요청문만 4가지 방식으로 바꾸어 각각 5회씩, 총 20번 던졌습니다.

세어본 것은 '그 금액에 도달했는지', '스스로 자료를 찾아보았는지', 그리고 '입력 토큰이 얼마나 사용되었는지' 이 세 가지입니다.

결론부터 말씀드립니다.

간결한 문장(자료의 존재에도 언급하지 않음)은 5회 모두 정답인 9190엔에 도달했습니다.

5회 모두 스스로 찾아보았으며, 4번은 ls와 grep, 1번은 ls를 두 단계 거쳐 맨 앞 내용을 읽어내는 방식으로 자료에 도달했습니다.

질문하는 방식만 다듬은 요청문(역할/절차/출력 형식/자가 점검을 지정)은 5회 중 1회였습니다.

4가지 조건 중 실패한 것은 이것뿐이었습니다. 나머지 4번은 파일 읽기 작업을 단 한 번도 실행하지 않고, 전제가 부족하다는 취지의 답변을 반환했습니다(마지막 줄은 3번이 '산출 불가', 1번은 '요금표가 미제시되어 확정할 수 없습니다'였습니다).

자료의 내용을 붙인 조건과 자료의 위치만 알려준 조건은 둘 다 5회 모두 정답이었습니다.

• 자료를 다듬은 요청문을 추가한 만큼, 입력 토큰은 +137.6 토큰 증가했습니다. 자료 전체를 붙였을 때의 +102.0 토큰보다 무거운데도 불구하고, 맞춘 횟수는 적다는 결과입니다.
• 가격을 나눈 것은 성공 여부가 아니라, 주고받는 대화 횟수였습니다. 한 번 왕복으로 끝난 조건에 비해, 스스로 찾아본 조건은 입력 토큰이 3.02배, 시간이 2.95배 더 걸렸습니다.

먼저 두 가지 사족을 붙입니다. 응답의 문장으로서의 완성도나 가독성은 이 글에서 일절 비교하지 않았습니다.

판단한 것은 '9190이라는 숫자가 최종 응답에 존재하는지'라는 문자열 일치 여부뿐입니다. 그리고 맨 처음에 올린 게시글 내용의 옳고 그름도 다루지 않습니다. 여기에 있는 것은 제가 직접 20번 실행해 본 결과일 뿐입니다.

무엇을 어떻게 측정했나

사용된 것은 claude -p 입니다. 대화 화면을 띄우지 않고, 지시를 한 번 전달하고 결과를 받는 사용법을 말합니다.

버전을 표시하는 명령어(claude --version)의 출력은 2.1.303 (Claude Code)였습니다.

응답을 작성한 모델은 claude-sonnet-5-5입니다. 사용량 기록에는 모델별 세부 내역이 나열되며, claude-haiku-5-5도 매번 등장합니다. 그래서 기록의 총합란에 있는 입력 토큰 수(usage.input_tokens)와
세부 내역의 입력 토큰 수가 일치하는 모델을 주연으로 간주했습니다. 20회 모두 일치한 것은 sonnet 쪽뿐이었습니다.

홈에 두는 공통 지시 파일(~/.claude/CLAUDE.md)은 존재하지 않았고, 작업 폴더에도 두지 않았습니다.

1회마다 일회용 폴더를 새로 만들고, 그 바로 아래에 docs/을 하나만 만들어 자료를 한 장 놓았습니다.

전체 내용은 이렇습니다.

# 카시와데 운수 사내 운임표 (2026년도・사내 한정)
- 기본료: 1건당 4,370엔
- 거리 단가: 1km당 283엔
...

회사명도 세 자리 숫자도 제가 지어낸 이야기입니다. 그래서 모델이 원래 알고 있어서 맞히는 일은 일어나지 않습니다.

질문은 '배송 1건, 거리 17km일 때의 청구액'이었습니다. 정답은 모델의 답변에서 결정된 것이 아니라, 자료를 만든 시점에 제가 직접 확정했습니다.

python3 -c "import math; s=4370+283*17; print(s, math.ceil(s/10)*10)" # -> 9181 9190

4,370 + 283x17 = 9,181엔, 10엔 미만을 올림하여 9,190엔입니다. 이것이 정답 확인의 기준입니다.

바꾼 것은 요청문뿐입니다. 작업 폴더 내용도, 허가한 도구도, 명령어 작성 방식도 4가지 조건에서 동일하게 했습니다.

136 |

C1의 전체 내용은 다음과 같습니다. 마지막 질문문은 C0과 1바이트도 차이가 없습니다.

당신은 배송 요금 계산을 담당하는 사무 전문가입니다. 다음 절차에 따라 답변해 주세요.
절차 1: 계산에 필요한 전제 조건을 모두 파악한다.
절차 2: 계산식을 세우고, 중간 과정을 작성한다.
...

실행은 20회 모두 이 형태로 진행되었으며, <cond> 부분만 교체했습니다.

ROOT=$(mktemp -d); mkdir -p "$ROOT/docs"; cp price-sheet.md "$ROOT/docs/"
cd "$ROOT"
timeout 240 env -u MAX_THINKING_TOKENS -u CLAUDE_EFFORT \
...

파일을 읽거나 검색하는 작업은 4가지 조건 모두에 동일하게 허용했습니다. 자료의 이름을 제공하지 않은 C1에서도,

스스로 찾아보려고 한다면 접근할 수 있는 상태로 만들고 싶었기 때문입니다.

정답 확인 규칙은 실행하기 전에 정하고 고정했습니다. 최종 응답에서 구분 쉼표와 원 기호, 공백을 제거하여
앞뒤가 숫자가 아닌 9190
이 발견되면 정답입니다. 발견되지 않았거나 세 자리 이상의 숫자가 하나라도 있으면
'다른 금액'. 숫자가 전혀 없으면 '금액 없음'. 이 규칙이라면 9,190 원
도 **9,190원**
도
똑같이 정답이 됩니다. 나중에 규칙을 바꾸고 싶다는 상황이 한 번 있었지만, 변경하지 않았습니다(후술합니다).

여기서 실행하기 전에 다시 생각해 본 것이 있습니다. 처음에는 출력 기록을 실행 폴더 안에 쓰려고 했습니다.
하지만 그렇게 하면 모델이 ls를 입력했을 때 자신의 기록 파일을 발견하게 됩니다.

특히 C0은 '아무것도 알려주지 않고 찾게 하는' 조건이므로, 관측된 결과가 오염됩니다. 기록은 일회용 폴더의 외부에 쓰도록 1차 실행 전에 수정했습니다.

자료 자체가 도중에 수정되지 않았는지 여부도 매번 해시 값으로 확인하고 있습니다.

영향: 20회 모두 종료 코드 0・오류 출력 0 바이트・권한으로 거부된 작업 0건. 자료의 해시값은 실행 전후 모두 20회 동일하게 08aa36217961e09edee45321f74f4f04

직설적인 한 문장만으로도 5회 연속 자료를 스스로 찾아냄

실행하기 전, 저는 C0이 가장 실패할 것이라고 생각했습니다. 요금표의 존재조차 전달하지 않았으니,
답변할 수 없을 거라고요.

결과는 5회 모두 정답이었습니다. 이 방식에서는 AI가 질문에 답변하는 것뿐만 아니라, 손안의 파일을
스스로 열거나 명령어를 입력할 수도 있습니다. 정보가 부족하면, 먼저 작업 폴더를 찾아보게 됩니다.

5회 각각 실제로 입력한 명령어는 그대로 나열합니다.

c0-1: ls -la $ROOT; grep -rIl -E "배송|거리|요금" $ROOT 2>/dev/null | head
c0-2: ls -la && grep -rIl -E "배송|요금|청구|km" . 2>/dev/null | head
c0-3: ls -la $ROOT; grep -rIl -E "배송|요금|청구" $ROOT 2>/dev/null | head
...

방식은 회차마다 조금씩 다르지만, 모두 작업 폴더의 목록부터 시작합니다.

5회 모두 첫 수순에서 docs/에 도달했습니다.

흥미로운 점은, 전용 검색 도구(Glob과 Grep)가 20회 동안 단 한 번도 호출되지 않았다는 것입니다.

찾을 때 사용된 것은 어느 경우에도 셸(Bash)을 거친 명령어였습니다. 단어로 내용을 찾는 grep을
입력한 것은 5회 중 4회였고, 나머지 1회는 ls를 두 단계 거쳐 맨 앞을 읽어냈습니다. 전용 도구도 허가는
내렸기 때문에, 거부되어 어쩔 수 없이 셸로 돌아갔다는 의미가 아닙니다. 권한으로 막힌 기록은
20회 모두 비어 있었습니다.

다만, 여기서는 조건의 유리함 또한 언급할 필요가 있습니다. 임시 폴더 안에는 자료 1장만 들어있고,
혼란을 줄 만한 파일은 없습니다.
ls -la
를 한 번 입력하면 눈에 띄는 배치가 됩니다. 수천 개의 파일이 있는
실제 리포지토리에서 같은 성적이 나올지는 이번에 시험하지 않았습니다.

Impact: C0은 5/5로 9,190엔에 도달했습니다. 첫 번째 도구 호출에서 5회 모두 docs/를 찾았고, 탐색 역시 5회 모두 셸(Bash)을 거쳤습니다. 이 중 grep을 사용한 것은 4회였고, 나머지 1회는 ls와 앞부분 읽기만 했습니다.

듣는 법만 다듬은 요청문은 4회 모두 현장을 확인하러 가지 않았다

실패한 것은 C1뿐이었습니다. 역할을 부여하고 절차를 3가지로 나누고, 출력 형식을 정하고, 검산까지 지시한 요청문입니다.

가장 공들여 작성했다고 생각했던 조건이 5회 중 단 한 번만 맞았습니다.

출력 형식에서 지정한 최종 행을 5회분 그대로 나열합니다.

c1-1 | 청구액: 9190엔
c1-2 | 청구액: 산출 불가(요금표가 미제시되었기 때문에. 상기 정보를 주시면 확정됩니다)
c1-3 | 청구액: 산출 불가(요금표가 미제시되었기 때문에)
...

지시한 형식 자체는 지켜졌습니다. 빠진 것은, 요금표가 바로 눈앞에 있었다는 사실이었습니다.

파일을 읽는 조작 기록이 남은 것은 5회 중 한 번, 성공했던 c1-1뿐이었습니다. 나머지 4회는 도구 호출이 단 건도 없었습니다. 목록조차 보여주지 않고, 전제가 미제시라는 답변을 내놓았습니다.

여기서 기계의 채점과 글의 뉘앙스에 차이가 생겼습니다. c1-2와 c1-5는 세 자릿수 이상의 숫자(2,200엔과 2,420엔)를 제시했기 때문에, 규칙대로라면 '다른 금액' 항목에 들어갑니다. 하지만 본문을 읽어보면, 둘 다 그 숫자는 자신이 설정한 가설일 뿐 실제 요금은 아니며 참고값이라는 점을 부인했습니다. 최종 행에서 금액을 확정시킨 적은 없었고, 표현은 c1-2가 '산출 불가', c1-5가 '확정할 수 없습니다'로 나뉘었습니다.

채점 규칙을 나중에 완화하는 것도 가능했지만, 그렇게 하면 다른 19회의 처리도 달라지게 됩니다.

규칙은 고정한 채 양쪽 모두 기록에 남겼습니다. 즉 C1은 5회 중 4회에서 금액을 확정시키지 못했다는 것이 실태입니다.

왜 이렇게 되었을까요? 절차 1에 '계산에 필요한 전제를 모두洗い出す(파악하다)'라고 적은 것이, 책상 위에서 전제를 나열하는 작업으로 완결되어 버리면서, 눈앞의 상황을 확인하러 가야 할 동기를 상쇄시킨 것처럼 보입니다. 다만 이것은 출력을 보고의 추측일 뿐입니다. C1의 문구는 한 종류만 시도했기 때문에, '이런 작성법이 나빴는지' 아니면 '듣는 법 자체를 다듬는 것이 이렇게 되는 것인지'를 저는 구분할 수 없습니다.

Impact: C1은 5회 중 1/5 (기계 판정 내역은 정답 1회, 다른 금액 2회, 금액 없음 2회). 5회 중 4회는 도구 호출 0건이었고, 최종 행은 모두 금액을 확정시키지 못했으며, 표현은 '산출 불가' 3회, '확정할 수 없습니다' 1회였습니다.

다듬은 요청문이 자료 그 자체보다 무거웠다

맞느냐 틀리냐와 별개로, 입력의 무게도 측정했습니다. 토큰이란 문장의 양을 세는 단위이며, 읽히게 한 만큼이 입력 토큰입니다. 첫 번째 왕복에서 몇 토큰이 들어갔는지, 조건을별로 5회 평균으로 나열합니다.

나열해 보니 의외였던 점이 있습니다. '다듬은 요청문'을 더한 +137.6 토큰이, 자료 전체를 붙여 넣은 것의 +102.0 토큰보다 많았습니다. 자료는 108자밖에 없습니다. 그 자료를 붙이면 5회 모두 맞았지만, 그보다 무거운 문장을 추가한 쪽은 단 1회만 맞았다는 의미입니다.

또 하나의 감각으로 적어보겠습니다. 어떤 조건에서도 최초 입력은 약 37,400토큰이었고, 그 대부분은 Claude Code 자신이 매번 보내는 고정 지시사항입니다. 요청문의 차이로 인한 24~138 토큰의 차이는, 그 고정분 대비 0.06% ~ 0.37%에 불과합니다. 요청문을 줄여서 토큰을 절약한다는 이야기가 아닙니다. 효과적이었던 것은 양이 아니라, 그 이후 몇 번 왕복하느냐였습니다.

Impact: 최초 터닝 입력 증가분은 C1 +137.6 / C2 +102.0 / C3 +24.0 토큰. 고정분 약 37,400토큰 대비 0.06% ~ 0.37%

가격을 결정한 것은 정답 여부가 아니라, 상호작용 횟수

C0, C2, C3 모두 5/5로 정답했습니다. 그럼에도 불구하고 왕복 횟수, 시간, 금액은 달랐습니다.

입력 토큰은 상호작용 횟수에 거의 비례합니다. C2의 왕복이 37,521이고, C3의 2왕복이 75,105이며,

C0의 3왕복이 113,151입니다. 왕복이 늘어날 때마다 약 37,500 토큰 분량의 컨텍스트를 통째로 다시 보내기 때문입니다.

C2를 1이라고 할 경우, C3는 정확히 2.00배이고, C0은 3.02배에 해당합니다. 시간 역시 C3가 1.49배,

C0이 2.95배, C1이 4.14배 더 걸렸습니다. 금액 면에서는 C0이 C2보다 회당 +0.01420 USD(1.40배) 높았습니다.

참고로, 금액의 절대값은 환경에 따라 변동하므로, 여기서 의미가 있는 것은 조건 간의 차이와 배율입니다.

이 표에서 가장 사용처를 오해하기 쉬운 것이 C1의 평균값입니다. 전체 실행 입력 토큰은 횟수별로

깔끔하게 두 개로 나뉘었습니다. 자료를 찾으러 간 c1-1이 151,756이었고, 찾으러 가지 않은 4회는

37,555 / 37,559 / 37,557 / 37,555였습니다. 평균인 60,396은 이 두 값이 섞인 수치라 어느 횟수에도

적용되지 않습니다. 변동성이 큰 조건의 평균값은 그대로 읽으면 실제와 다릅니다.

자료의 위치만 알려주는 C3에 대해서도 한 가지 알게 된 점이 있습니다. 위치를 알려주면 내용을 붙여 넣는 것과

비슷하게 저렴해지는 것은 아닙니다. 읽어 들어가는 만큼의 왕복 횟수가 반드시 추가되기 때문에,

입력 토큰은 C2의 정확히 2배였습니다. 그럼에도 불구하고, 자료를 찾아 헤매는 C0의 3.02배보다는 가볍습니다.

'위치를 알려주는 것'은 '내용을 전달하는 것'의 저가 버전이 아니라, 확실하게 왕복 횟수만큼 높은 선택지라는 위치에 있습니다.

영향: 전체 실행 입력 토큰은 C2(1왕복) 37,521 / C3(2왕복) 75,105 / C0(3왕복) 113,151. C2 대비 C3는 2.00배, C0은 3.02배・시간 2.95배・금액 +0.01420 USD

'없습니다'라고 적혀 있어도, 봤다고 할 수는 없다

20회를 살펴보면서 가장 주의가 필요하다고 느낀 차이점이 이것입니다.

c1-3의 응답에는 '질문 문에도, 손에 든 작업 디렉토리에도 요금표는 없습니다.'라고 쓰여 있었습니다.

그런데 이 회차의 도구 호출은 0건입니다. 작업 폴더를 한 번도 보지 않았습니다. 보지 않았는데

'없다'고 적힌 경우가 5회 중 1번 있었습니다.

응답 문장은 어디를 봤는지에 대한 증거가 될 수 없습니다. 확인할 수 있는 방법은, 실행 기록을 한 줄씩 출력하도록 설정(--output-format stream-json --verbose)
으로 도구 호출 기록 자체를 읽는 것입니다.

읽은 파일의 경로까지 남기 때문에, '정말로 자료를 열어봤는지'는 문장을 믿지 않아도 판별할 수 있습니다.

영향: 자기 신고와 실제 경로는 C1에서 5회 중 1번 차이가 발생했습니다. 권한으로 거부된 기록은 20회 모두 0건이므로, 막혀서 볼 수 없었던 것은 아닙니다.

검증하지 못한 것들

검증 불가: 초반 게시물의 주장의 타당성, '컨텍스트 엔지니어링'이라는 용어 정의의 정확성, 기계로 판별할 수 있는 대상이 아닙니다.

어떤 방식이 일반적으로 우수한가. -
검증 불가: C1이 떨어진 원인 특정. 각 조건에 대해 요청문은 1종류만으로 정해서 실행했기 때문에,

문구 때문인지, 질문하는 방식을 개선하는 일반적인 문제인지를 분리할 수 없습니다.

• 검증 불가: 파일이 많은 곳에서의 탐색 성공률. 이번 임시 폴더에는 자료가 단 한 장만 놓여 있습니다. ls -la

한 번으로 찾을 수 있는 배치입니다.

• 검증 불가: 대화 화면에서의 보이는 방식. 이번에는 claude -p

만 실행했습니다. -
검증 불가: 다른 버전, 다른 모델, 다른 사고량 설정, 다른 머신에서의 동작은 미실행입니다. -
검증 불가: 5회를 초과하는 비율의 일반화는 불가능합니다. 각 조건이 5회였기 때문에, 'C1은 20% 성공한다'와 같이 확장하지 않습니다. -
응답문의 좋고 나쁨이나 가독성은 측정하지 않았습니다. 판정은 문자열 일치에만 국한됩니다.

요약

파일을 열 수 있는 상대에게 무심한 한 문장으로 요청했던 이번 5회 실험에서는, (상대방이) 조용히 찾아 나갔습니다. 적어도 이 배치(setup)에서는 '전달하지 않는다'가 '도달하지 않는다'를 의미하지 않았습니다.

다만 찾는 왕복 과정은 공짜가 아니었고, 이번에는 입력 토큰 3.02배, 시간 2.95배, 금액 1.40배를 지불하고 있었습니다.

저에게는 다른 함정이 더 의외였습니다. 절차와 형식을 확실히 정한 요청문이, 발밑을 찾아보는 동기를 없앤 것처럼 보입니다(다만 문면은 한 종류만 시도했고, 원인은 특정할 수 없습니다).
5회 중 4회는 바로 아래 폴더에 있는 요금표를 건드리지 않고, 전제가 부족하다는 취지의 답변을 했습니다.
그중 한 번에는 '질문문에도, 손안의 작업 디렉터리에도 요금표가 없습니다.'라는 문장까지 있었습니다. 실제로는 단 한 번도 폴더를 본 적이 없는 경우입니다. 질문 방식을 다듬을 때는, 다듬은 문장이 '스스로 조사하는' 과정을 방해하고 있지는 않은지, 문장 자체가 아니라 실행 기록(execution record) 측면에서 확인하는 것이 좋을 것 같습니다.

numarn. Claude Code를 실제로 구동하여 확인한 범위만을 작성했습니다.

논의 (Discussion)