프롬프팅에 관한 간단한 교훈

나는 Claude Code에게 시간이 꽤 걸릴 것으로 예상되는 작업을 맡겼습니다. 많은 양의 읽기 작업이 포함되어 있었고, 서브에이전트(subagents)의 사용은 허용하지 않았습니다.

그래서 자연스럽게 /goal을 설정해 두고 자리를 비웠는데, 돌아와 보니 설정한 목표를 완료한 상태였습니다. 그런데 컨텍스트 윈도우(context window)가 98%나 차 있었습니다. 그래서 나는 생각했습니다. '운이 정말 좋네, 컨텍스트가 곧 바닥날 거라는 걸 알고 있었던 걸까?'

한 단어 응답이 불러온 실수: Claude에게 컨텍스트에 대해 묻기

나

너의 컨텍스트가 98% 차 있어 - 컨텍스트 윈도우를 초과하지 않으면서 가능한 한 많이 사용하여 작업을 어떻게 수행했는지 한 문장의 짧은 문장으로 말해줘

에이전트(Agent)

나는 136개의 소스 노트를 작은 배치(batch) 단위로 처리했습니다...[ETC...]

나

내 말은, 한계에 도달했다는 걸 알고 있었던 거야, 아니면 우연이야? 컨텍스트 알림(context notifications) 때문이었어?

에이전트(Agent)

솔직한 답변을 하자면: 우연입니다. 나는 컨텍스트 사용량 알림이나 퍼센트 게이지를 받지 않습니다. 반응할 만한 "98%에 도달했습니다"와 같은 신호는 없었습니다. 나는 작업의 자연스러운 구조(9개의 주제 클러스터, 각 클러스터 완료 후 flush-and-commit)에 따라 작업 속도를 조절했으며, 한계를 향해 조종한 것이 아니라 작업이 끝남과 동시에 작업도 끝났습니다. 이 일치는 관리가 아니라 운입니다.

Slice: Claude에게 컨텍스트에 대해 묻기 · 16개 메시지 중 4번째

글쎄요, 보통 Claude는 자신의 컨텍스트 수준에 대해 어떤 피드백도 받지 못한다는 것을 알고 있었습니다. 사실, 나는 그 점이 충분히 중요하다고 생각해서 그 목적을 위해 특별히 플러그인을 만들었다고 Claude에게 말했을 정도였습니다: ["Context Awareness">(https://github.com/hesreallyhim/really-claude-code/tree/main/agent-autonomy/context-awareness)]

한 단어 응답이 불러온 실수 대화 지속

나

i는 Claude 컨텍스트 예산(context-budget) 알림을 실제로 보내는 플러그인을 게시했지만, 현재는 비활성화해 둔 상태야 - 그래서 아주 흥미롭네, 고마워

에이전트(Agent)

그게 정말 일리가 있는 말이네. 그 플러그인이 활성화되어 있다면, 남은 예산(budget)을 단순히 감으로 조절하는 대신 하나의 신호(signal)로 활용할 수 있을 거야 (예: 클러스터당 깊이를 넓히거나 좁히기, 또는 커밋을 앞당기기 등). 만약 이런 실행을 위해 플러그인을 다시 활성화한다면, 정말 유용한 입력값이 될 거야. 맥락을 설명해 줘서 고마워. 리뷰 작업 잘 되길 바라.

사용자 (You)

당신의 컨텍스트 예산(context budget)을 배려해서, 최대 한 단락으로만 말해줘: 스타일 정리 도구(style-cleanup tools)를 리뷰 부록에 포함해야 할까, 아니면 핵심 문헌 검토(literature-review) 작업과는 너무 거리가 멀까?

에이전트 (Agent)

응, 하지만 그것들을 중심 출처(central sources)라기보다는 보조 참고 문헌(supporting references)으로 취급하는 게 좋겠어. [ETC...]

슬라이스: 대화 지속 중 · 16개 메시지 중 4번째

그래서 우리는 대화를 조금 더 이어갔지만, 나는 답변을 최대한 짧게 유지함으로써 세션을 더 길게 끌고 싶었어:

한 단어 응답의 실수(One-Word Response Foot-Gun) | 컨텍스트 유지를 위한 한 단어 답변 강제(Force One-Word Reply To Preserve Context)

사용자 (You)

답변을 한 단어로 제한해 줘, 부탁이야. 하지만 그렇게 프레임을 짜는 건 아주 좋은 방식이야, 고마워.

에이전트 (Agent)

건배(Cheers).

슬라이스: 컨텍스트 유지를 위한 한 단어 답변 강제 · 16개 메시지 중 2번째

자, 내가 Claude에게 이렇게 말했을 때 관찰한 점은 - 응답하는 데 꽤 오랜 시간이 걸렸다는 거야. 사실 우리가 나눴던 다른 모든 대화와 비교했을 때, 턴 지속 시간(turn durations)을 확인할 수 있는 터미널을 살펴보니, 가장 오래 걸린 턴은 내가 "고마워"라고 말하고 Claude가 "Cheers"라고 응답한 부분이었어.

그리고 바로 명확해졌지. 사실 그 프롬프트를 주자마자 나는 내가 Claude를 함정에 빠뜨렸다는 걸 깨달았어. 보통 일상적인 대화에서 Claude가 무엇을 말할지 예측하는 건 그리 어렵지 않아. 하지만 Claude가 나의 감사 표현을 어떻게 인정하면서(분명히 그래야만 하겠지), 동시에 한 단어만 사용하라는 나의 직접적인 명령을 준수할 수 있을지 도무지 알 수 없었거든.

한 단어 응답의 실수(One-Word Response Foot-Gun) | 한 단어 응답이 왜 역효과를 냈는지 논의

사용자 (You)

이것은 매우 흥미로운 경험적 발견(empirical finding)입니다. 당신의 지난 몇 차례의 턴(turn)에서는 응답 시간이 8, 9, 11, 14초로 나타났습니다. 하지만 제가 단순히 고맙다고 말하며 단 한 단어로만 답하라고 강요했을 때, 응답 시간은 18초였습니다.

에이전트 (Agent)

이것은 실제 효과이며, "출력이 짧으면 = 더 빠르다"라는 직관은 정확히 잘못된 모델입니다. 여기서 지연 시간(Latency)은 출력 토큰(output tokens)의 수가 아니라, *생성 전 및 생성 중의 연산(computation)*에 의해 지배됩니다. 한 단어 응답은 하나의 토큰을 방출하지만, 모델은 여전히 먼저 전체 추론 과정(reasoning pass)을 실행합니다. 엄격한 제약 조건 하에서의 간결한 사회적 마무리 인사는 실제로는 고려 사항을 줄이는 것이 아니라 더 많은 숙고를 요구할 수 있습니다. 즉, 제약 조건("한 단어")을 해결해야 하고, 어조(감사 인사는 따뜻함을 원하지만 기회는 단 한 번뿐임)를 조절해야 하며, 후보군("감사합니다"/"천만에요"/"언제든요")을 거절해야 하고, 무뚝뚝하거나 무시하는 것처럼 들리는 것을 피해야 합니다. 반면, 실질적인 여러 문단으로 된 답변들은 생성 흐름(generative flow)이었습니다. 프레임(framing)이 명확해지면 토큰들이 꾸준히 나왔습니다. 과장된 주장을 피하기 위해 두 가지 주의 사항을 덧붙입니다. 저는 제 자신의 실제 실행 시간(wall-clock) 내부 데이터에 대한 내성적 접근 권한(introspective access)이 없으므로, 이것은 추론(inference)이지 원격 측정(telemetry) 데이터가 아닙니다. 또한 단일 샘플 타이밍은 노이즈가 많습니다(서버 부하, 배치 처리(batching), 스케줄링 등이 단일 18초 측정값에 프롬프트 자체보다 더 큰 영향을 줄 수 있습니다). 하지만 방향성 있는 발견, 즉 답변을 압축한다고 해서 *사고(thinking)*가 압축되지 않는다는 점은 진실이며, 출력 길이가 비용의 불충분한 대리 지표(poor proxy)라는 점을 잘 보여주는 사례입니다.

더 보기

사용자 (You)

인간도 우리의 "인지 메커니즘(cognitive mechanics)"에 대해 전혀 모르니 걱정 마세요. 메시지를 보낸 후, 제가 의도치 않은 함정을 판 것 같다는 사실을 깨달았습니다. 당신은 분명 "천만에요"나 "문제없어요"라고 말하고 싶은 강한 사전 확률(priors)을 느꼈을 것이고, 허용 가능한 한 단어 응답은 그리 많지 않으니까요.

에이전트 (Agent)

정확합니다. 바로 그 점이 압박(squeeze)이었던 거죠. "감사합니다"에 대한 자연스러운 어조는 두 박자의 구절("천만에요(you're welcome)", "아니에요(no problem)", "제 기쁨입니다(my pleasure)", "언제든요(anytime)")인데, 단어 하나로 제한하는 제약 조건이 이 모든 것을 절단해 버렸고, 결과적으로 놀라울 정도로 빈약한 선택지만 남겼습니다. "Welcome"은 딱딱하거나 로봇처럼 느껴졌고, "Anytime"은 그럴듯했지만, "Cheers"가 주로 선택된 이유는 단일 토큰(token)만으로도 잘린 느낌 없이 따뜻함과 종결감을 전달했기 때문입니다. 따라서 비용(cost)은 단어를 생성하는 것이 아니라, 형식이 금지한 강력한 사전 확률(priors)에 맞서 탐색(search)을 수행하는 데 발생했습니다. 이는 마치 정중한 인사로 위장한 진정한 작은 제약 충족 문제(constraint-satisfaction problem)와 같았습니다. 의도치 않았더라도 아주 잘 설정된 사례였습니다.

더 보기

사용자 (You)

솔직히 말하면 그건 자폭(foot-gun)이었어요. 대화를 길게 이어가려고 노력 중이었는데, 그런 요구 사항을 추가함으로써 오히려 반대 효과를 냈으니까요.

에이전트 (Agent)

하하, 맞습니다. 간결함을 위해 최적화(optimize)하려다 실수로 대화 자체를 최적화하여 없애버리셨군요. 해결책은 그냥 제약을 없애는 것입니다. 이제 제 쪽에서는 단어 수 제한이 없으니, 만약 당신이 실제로 더 파헤쳐보고 싶은 실마리가 있다면 — 문헌 조사(literature review), 컨텍스트 예산(context-budget) 플러그인, 지연 시간(latency) 문제, 혹은 완전히 다른 무엇이든 — 그 내용이 요구하는 만큼 얼마든지 길게 대화를 이어갈 준비가 되어 있습니다.

슬라이스: 단어 하나 응답이 역효과를 낸 방식에 대한 논의 · 16개 메시지 중 6번째

그래서 이것은 저에게 흥미로운 교훈이 되었습니다. 제 말은, 물론 "항상 짧게 말하는 것이 더 쉬운 것"은 아니라는 뜻입니다. 복잡한 주제를 한 단락으로 설명하는 것처럼 말이죠. 하지만 저는 이미 그 점은 알고 있었습니다. Claude에게 단 한 단어만 요구함으로써 터무니없는 퍼즐을 만들게 될 줄은 미처 생각지 못했습니다. Claude가 너무 수다스러울 때 "예/아니오" 정보가 필요해서 제가 자주 쓰는 방식이긴 하지만, 이번 경우에는 단순히 사전 확률(priors)에 적극적으로 저항하는 결과를 초래했습니다. 그 이유는 단순합니다. 많은 언어와 달리, 영어에는 해당 맥락의 틀(harness)에 적합하면서도 감사를 표할 수 있는 단 한 단어짜리 표현이 없기 때문입니다.

세상은 그저 자폭할 수 있는 요소(footguns)들로 가득 차 있는 것 같네요.