LLM에게 길게 생각하게 하기 전에 Evidence → Answer → Caveat을 시도하라

LLM에게 "더 깊게 생각해주세요"라고 쓰면, 답변이 언뜻 좋아질 때가 있습니다. 하지만 실무에서는 그것만으로는 부족합니다. 긴 추론을 작성하더라도 조건을 놓치는 경우가 있고, 간단한 문제에서 너무 많이 생각하여 시간과 비용만 늘어나는 경우도 있습니다.

이 기사에서 다루는 것은 LLM에게 길게 생각하게 하는 방법이 아닙니다. LLM에게 맡기는 작업을 **근거를 확인할 수 있는 작은 인지 단계 (Cognitive Step)**로 나누는 방법입니다.

먼저 전제를 맞추겠습니다. LLM은 대량의 문장에서 다음에 올 법한 말을 예측하여 답변하는 모델입니다. ChatGPT와 같은 채팅 AI를 떠올리면 이해하기 쉽습니다. 프롬프트 (Prompt)란 그 LLM에 전달하는 지시문입니다.

이 기사에서는 문제를 이해하고, 관련 지식을 떠올리고, 분해하고, 검증하고, 편향 (Bias)을 점검하고, 과도한 생각을 멈추는 등의 인지 조작을 명시하는 프롬프트를 "코그니티브 프롬프트 (Cognitive Prompt)"라고 부릅니다.

2025년 이후의 연구에서 눈에 띄는 것은 단순히 추론을 길게 하는 방향이 아닙니다. 필요한 인지 조작을 선택하여, 짧고, 검증하기 쉽게, 필요한 때에만 사용하는 방향입니다.

참고로, 이 기사에서 인용하는 연구 논문은 2025년 이후에 공개된 것만으로 한정합니다. 고전적인 수법도 언급하겠지만, 링크와 함께 소개하는 논문은 현재의 흐름을 보기 쉽게 하기 위해 2025년 이후의 연구로 제한합니다.

그 토대 위에서, 실무에서 사용할 수 있는 프롬프트 예시, 논문에서 보고된 효과, Hono 공식 문서를 사용한 작은 검증을 소개합니다. Hono를 특별 취급하기 위해서가 아니라, 공식 문서가 LLM용 llms-full.txt로 정리되어 있어 조건부 기술 QA를 만들기 쉬웠기 때문입니다.

읽고 난 뒤에 얻어갈 수 있는 것은 다음 세 가지입니다.

• 문서 QA나 사양 확인에서 우선 시도할 템플릿
• 무거운 추론 프롬프트를 사용해야 할 상황, 사용하지 않는 것이 좋은 상황
• 수중에 있는 태스크로 효과를 검증하는 최소 절차

우선 시도한다면 Evidence → Answer → Caveat

코그니티브 프롬프트는 LLM의 능력 그 자체를 바꾸는 방법이 아닙니다. LLM에게 맡기는 작업을 검증하기 쉬운 인지 단계로 분해하는 설계 기법입니다.

여기서 말하는 "검증하기 쉽다"는 것은 답변뿐만 아니라, 어떤 근거를 사용했는지, 어떤 조건을 확인했는지, 어디에 불확실성이 남아 있는지를 읽는 사람이 추적할 수 있는 상태를 의미합니다. 연구, 사양 확인, 사내 문서 QA와 같이 "왜 그런 답인가"가 중요한 상황에서 효과적입니다.

이 기사가 특히 도움이 되는 상황은 다음과 같습니다.

• 조건을 놓치기 쉬운 문제
• 여러 논점이 섞인 업무 판단
• 고난도의 수학·추론 태스크
• 출력이 너무 길어지는 추론 태스크
• 편향 (Bias)이 들어가기 쉬운 의사결정
• "생각하는 척"과 "확인된 사실"을 구분하고 싶은 조사

처음부터 완벽한 프롬프트를 찾을 필요는 없습니다. 우선 10~30문항 정도의 작은 검증 세트를 만들어 일반 프롬프트와 비교하는 것이 실무에서는 판단하기 쉽습니다.

그림으로 나타내면, 이 기사에서 말하고자 하는 것은 다음 흐름입니다.

1. 바로 사용할 수 있는 프롬프트 예시

다음 템플릿은 논문 중의 프롬프트를 그대로 베낀 것이 아닙니다. 2025년 이후의 연구에서 보고되고 있는 사고방식을 실무에서 사용하기 쉬운 형태로 재구성한 것입니다.

시간이 없다면 우선 1.3 Evidence → Answer → Caveat 형만 시도하는 것이 현실적입니다. 다른 템플릿은 문제가 복잡해졌을 때의 후보로서 훑어보는 정도로 충분하다고 생각합니다.

1.1 인지 조작 템플릿: 우선 구조화하여 풀기

Guilford의 Structure of Intellect를 사용한 cognitive prompt 설계 논문에서는 인지, 기억, 확산적 생성 (Divergent Generation), 수렴적 생성 (Convergent Generation), 평가와 같은 인지 조작을 프롬프트 설계에 도입하는 방향이 제안되고 있습니다 (Kramer, 2025, arXiv:2503.22036).

실무에서는 예를 들어 다음과 같이 사용할 수 있습니다.

다음 문제를 인지 조작으로 나누어 풀어주세요.
1. 인지: 문제문에서 무엇을 이해해야 하는지 정리한다.
2. 기억·지식: 관련될 법한 지식, 규칙, 과거의 유사 사례를 든다.
...

적합한 것은 요구사항 정리, 여러 안의 비교, 업무 판단, 복잡한 질문입니다. 단순한 사실 확인에는 너무 무겁습니다.

1.2 Cognitive Tools 형: 내적인 "사고 도구"를 선택하게 하기

Eliciting Reasoning in Language Models with Cognitive Tools는 외부 검색이나 계산기가 아닌, "문제를 이해하기", "관련 사항 떠올리기", "답변 검사하기", "백트래킹 (Backtrack) 하기"와 같은 내적인 인지 조작 (Cognitive Operation)을 도구로 정의합니다. 초록 (Abstract)에서는 GPT-4.1의 AIME2024 pass@1이 32%에서 53%로 개선되었다고 보고되었습니다 (Ebouky et al., 2025, arXiv:2506.12115).

이러한 사고방식을 일반적인 프롬프트에 적용하면 다음과 같습니다.

다음 문제를 풀기 위해 필요한 인지 도구를 선택하여 사용해 주세요.
사용 가능한 인지 도구:
- Understand: 문제의 의미, 목적, 제약을 명확히 한다.
...

고난도 추론에는 적합합니다. 다만, 출력이 길어지기 쉬우므로 중요한 문제에 한정하여 사용하는 것이 현실적입니다.

1.3 Evidence → Answer → Caveat 형: 문서 QA에서는 우선 이것을 시도하라

사양서, API 문서, 사내 규정과 같은 문서를 읽히고 답하게 하는 경우, 갑자기 긴 추론을 내놓게 할 필요는 없습니다. 우선 필요한 것은 다음 세 가지입니다.

• Evidence: 어떤 기술을 근거로 했는가.
• Answer: 질문에 대한 직접적인 답변.
• Caveat: 조건, 예외, 불확실성.

이 형식을 Hono 공식 문서로 작게 검증해 보았습니다. Hono는 TypeScript를 위한 경량 웹 프레임워크 (Web Framework)입니다. 공식 사이트에는 LLM이 읽기 쉬운 llms-full.txt라는 정리된 문서가 있습니다. 이번에는 거기서 라우팅 순서, HTTPException, ContextVariableMap, middleware, JSX, testing 등에 관한 30문제를 만들었습니다.

비교한 프롬프트는 3종류입니다.

프롬프트	형식	목적
일반 프롬프트	"문서만을 근거로 간결하게 답하라"	아무것도 더하지 않은 기준선
...

채점은 각 문제에 필요한 키워드가 답변에 포함되어 있는지를 보는 간이 스코어입니다. 예를 들어, HTTPException.getResponse() 문제라면 getResponse, Context, headers, new Response와 같은 단어가 들어있는지를 확인합니다.

이는 인간의 채점만큼 정확하지는 않습니다. 일본어의 유의어를 잡아내지 못할 수도 있습니다. 그럼에도 불구하고, 동일한 조건에서 3가지 프롬프트를 비교하는 거친 척도로는 사용할 수 있습니다.

결과는 다음과 같았습니다.

프롬프트	평균 키워드 스코어	중앙값	평균 대기 시간
일반 프롬프트	0.464	0.417	8.96초
...

이 결과만 보면, 일반 프롬프트보다 근거와 확인을 명시하는 형식이 더 안정적이었습니다. 반면, Goal → Evidence → Answer → Check는 대기 시간이 조금 더 길어졌습니다. Evidence → Answer → Caveat은 스코어가 비슷하면서도 더 짧고 빨랐습니다.

이 결과로부터, 문서 QA에서는 우선 다음 템플릿을 시도해 볼 가치가 있습니다.

다음 문서 본문만을 근거로 답변해 주세요.
긴 사고 과정을 쓰게 하지 말고, 짧은 사고 스케치 (Thinking Sketch)에 가깝게 작성합니다.
형식:
...

적합한 용도는 사양 확인, API 문서 QA, 사내 규정 확인, FAQ 작성입니다. 답변의 근거를 읽는 사람이 추적하기 쉽고, 출력도 길어지지 않기 때문입니다.

다만, 이 작은 실험만으로 "항상 이 형식이 최선이다"라고 말할 수는 없습니다. 검색된 문맥 (Context)이 어긋나 있으면 어떤 프롬프트로도 실패합니다. 채점 방법이 거칠면 올바른 일본어 답변이 낮게 채점될 수도 있습니다. 프롬프트뿐만 아니라 문맥을 추출하는 방법과 채점 방법도 함께 설계해야 합니다.

재시험을 할 경우의 최소 절차

• Hono 공식의 https://hono.dev/llms-full.txt

를 저장한다. - 문서로부터 30문항 전후의 QA를 만든다. 각 문제에는 질문, 기대되는 답변, 필수 키워드, 근거가 되는 헤딩(Heading)을 붙인다.

• 동일한 문서 검색 방법으로, 각 질문과 관련된 본문만을 추출한다. 이번에는 근거 헤딩에 가까운 본문을 우선적으로 추출했다.
• 동일한 실행 설정(모델, thinking/reasoning, API 이용 시 temperature 등), 동일한 3종류의 프롬프트로 답변하게 한다.
• 필수 키워드 일치율, 답변 시간, 명백한 오답을 기록한다.
• 마지막으로, 사람이 몇 문항을 읽고 키워드 채점과 실제 정답 여부가 일치하는지 확인한다.

완전한 재현을 위해서는 모델명뿐만 아니라 실행일, API 경로, 온도(Temperature), 검색 방법, 평가 항목도 필요하다. LLM은 같은 모델명이라도 업데이트되는 경우가 있으므로, 수치는 고정된 벤치마크(Benchmark)가 아니라 동일한 조건에서 비교한 작업 로그로서 읽는 것이 타당하다.

1.4 Sketch-of-Thought형: 길게 생각하지 않고, 짧게 구조화하기

CoT(Chain of Thought) 계열의 프롬프트는 추론을 길게 가져가는 경향이 있다. 비용이나 레이턴시(Latency)가 문제가 되는 경우에는 긴 문장이 아니라 짧은 중간 표현을 사용한다.

Sketch-of-Thought는 Conceptual Chaining, Chunked Symbolism, Expert Lexicons라는 짧은 표현 형식을 사용하여, 문제에 따라 추론의 표기 방식을 전환한다. 초록(Abstract)에 따르면, 18개의 추론 데이터셋에서 최대 84%의 토큰 절감, 최소한의 정확도 저하, 수학 및 멀티홉(Multi-hop) 추론에서의 정확도 개선이 보고되었다 (Aytes et al., 2025, arXiv:2503.05179).

다음 문제를 긴 설명 대신 "짧은 사고 스케치"로 풀어주세요.
형식:
- 요점:
...

"정확도를 떨어뜨리지 않으면서 짧게 만들고 싶을 때"의 후보 중 하나다. 초록의 보고를 바탕으로 한 실무상의 가설로서 시도해 볼 가치는 있지만, 감사(Audit)용으로 상세한 추론 과정을 남겨야 하는 상황에는 적합하지 않다.

1.5 Conceptual Metaphor형: 추상적 개념을 다른 구조로 투영하기

추상적인 문제는 그대로 다루면 모호해지기 쉽다. 이를 다른 구체적인 구조로 투영하면 논점이 명확해지는 경우가 있다.

Conceptual Metaphor Theory as a Prompting Paradigm for Large Language Models는 개념 은유 이론(Conceptual Metaphor Theory)을 사용하여, 추상적인 문제를 다른 영역의 구조로 사상(Mapping)함으로써 추론 정확도, 명확성, 은유적 일관성이 향상되었다고 저자들의 자동 평가를 통해 보고하고 있다. 평가에서는 Llama3.2, Phi3, Gemma2, Mistral과 각각의 CMT 확장 버전을 비교하였으며, Llama3.3 70B를 자동 평가기로 사용했다 (Kramer, 2025, arXiv:2502.01901).

다음 추상적인 문제를 이해하기 쉬운 은유(Metaphor)로 사상하여 생각해주세요.
절차:
1. 문제의 추상적 구조를 추출한다.
...

예를 들어, 조직 설계를 "교통 정리", 제품 개선을 "진단과 치료", 정보 설계를 "지도 만들기"로 생각하는 방식이다. 유용하지만, 현실의 제약을 지나치게 단순화할 위험이 있다.

1.6 Chain of Methodologies형: 방법론을 지정하여 풀기

업무에서는 처음부터 생각하는 것보다 기존의 방법론에 따라 정리하는 것이 더 빠른 경우가 있다.

Chain of Methodologies: Scaling Test Time Computation without Training는 인간이 사용하는 방법론을 프롬프트에 포함하여, LLM의 체계적인 추론을 촉진하는 프레임워크다. 초록에서는 명시적인 파인튜닝(Fine-tuning) 없이도 복잡한 추론 태스크에서 경쟁 베이스라인(Baseline)을 상회했다고 보고되었다 (Liu et al., 2025, arXiv:2506.06982).

다음 문제를 지정된 방법론에 따라 풀어주세요.
방법론:
{예: 가설 검증, 리스크 분석, 5 Whys, AARRR, SWOT, 유저 스토리 매핑 등}
...

방법론을 선택할 수 없는 경우에는 먼저 선택하도록 시킨다.

이 문제에 사용할 수 있는 방법론을 3가지 제안하고, 각각의 장단점을 비교한 뒤, 가장 적합한 방법론으로 풀어주세요.

1.7 Cognitive Debiasing형: 판단 편향 점검하기

의사 결정 태스크에서는 프롬프트 자체에 인지 편향(Cognitive Bias)이 포함될 수 있다.

Self-Adaptive Cognitive Debiasing for Large Language Models in Decision-Making은 bias determination(편향 결정), bias analysis(편향 분석), cognitive debiasing(인지적 디바이아싱)의 3단계로, 입력 프롬프트에 포함된 단일 또는 다수의 인지 편향(Cognitive Bias)을 완화하는 self-adaptive cognitive debiasing(자기 적응형 인지 디바이아싱)을 제안합니다. 금융, 의료, 법률 의사 결정 태스크에서 평가되었으며, 기존의 프롬프트 엔지니어링(Prompt Engineering) 기법이나 인지 디바이아싱 기법보다 낮은 평균 편향 점수를 달성했다고 초록(abstract)에서 보고되었습니다 (Lyu et al., 2025, arXiv:2504.04141).

다음 판단에 대해, 인지 편향을 점검한 후 답변해 주세요.
절차:
1. 입력문에 포함되어 있을 가능성이 있는 인지 편향을 나열한다.
...

의료, 법률, 금융과 같은 고위험 영역에서는 이 출력만으로 판단해서는 안 됩니다. 전문가 리뷰나 근거 확인이 필요합니다.

1.8 추론 정지 체크형: 생각 과잉을 멈추기

추론 모델은 어려운 문제가 아니더라도 길게 생각할 때가 있습니다.

CoRE: Enhancing Metacognition with Label-free Self-evaluation in LRMs는 Chain-of-Reasoning Embedding을 이용한 label-free self-evaluation(레이블 없는 자기 평가)을 통해, 불필요한 추론을 탐지하여 조기 정지하는 CoRE-Eval을 제안합니다. 수학 벤치마크에서 CoT(Chain-of-Thought) 길이를 13.7%~33.2% 감소시키고, 정확도(accuracy)를 약 10% 개선하였으며, 32B 모델에서 AIME 70.0%를 달성했다고 초록(abstract)에서 보고되었습니다 (Li et al., 2025, arXiv:2507.06087).

일반적인 프롬프트만으로 CoRE-Eval을 재현할 수 있는 것은 아닙니다. 다만, 정지 조건을 명시할 수는 있습니다.

다음 문제를 풀어주세요. 단, 추론이 동일한 내용의 반복이 된다면 정지해 주세요.
정지 조건:
- 새로운 정보나 제약이 늘어나지 않는다.
...

너무 짧게 만들면 필요한 검증까지 생략될 수 있습니다. 중요한 문제에서는 짧음과 검증 사이의 균형을 볼 필요가 있습니다.

2. 약간의 역사적 경위 파악하기

지금 '코그니티브 프롬프트(Cognitive Prompt)'가 중요해 보이는 것은 갑자기 새로운 발상이 태어났기 때문이 아닙니다. 그 배경에는 LLM에게 어떻게 생각하게 할지를 시도해 온 흐름이 있습니다.

첫 번째 큰 전환은 정답만 내놓게 하는 것이 아니라, 중간 추론 과정도 쓰게 하는 방향이었습니다. 이른바 Chain-of-Thought 계열의 발상입니다. 이는 LLM에게 '중간 풀이 과정'을 내놓게 하면 복잡한 문제에서 정답이 개선되는 경우가 있다는 경험을 확산시켰습니다.

그 후, 단일 추론 열(reasoning chain)만으로는 부족한 문제들도 보이기 시작했습니다. 여러 후보를 가지치기하거나, 외부 도구를 사용하거나, 자기 평가나 반성을 넣는 등의 방법이 시도되었습니다. 여기서의 목표는 LLM의 답변을 단판 승부로 두지 않고, 탐색, 검증, 수정을 넣는 것입니다.

다만, 이 방향에는 부작용도 있습니다. 추론을 길게 한다고 해서 반드시 정확해지는 것은 아닙니다. 오히려 정답과 관계가 적은 설명이 늘어나거나, 그럴듯한 이유를 사후에 갖다 붙이거나(post-hoc), 계산 비용이 증가하기도 합니다.

2025년 이후의 연구가 흥미로운 점은 이러한 부작용을 전제로 하고 있다는 점입니다. 단순히 '더 많은 추론을 쓰게 하는 것'이 아니라, 어떤 인지 조작을 사용할지, 어디서 짧게 할지, 어디서 검증할지에 관심이 옮겨가고 있습니다. 이 글에서 다루는 Evidence → Answer → Caveat이나 Cognitive Tools는 그 흐름 위에 있습니다.

즉, 역사적으로는 다음과 같이 볼 수 있습니다.

시기의 흐름	중심 질문	실무에서의 주의사항
정답만 내놓기	즉시 답할 수 있는가	근거나 조건을 보기 어렵다
...
이러한 경위를 고려하면, '더 많이 생각하라'는 것은 중간 단계의 해결책이었다고 할 수 있습니다. 실무에서 필요한 것은 그 다음입니다. 문제에 맞춰 필요한 인지 단계만을 선택하는 것입니다.

이 흐름을 도식화하면 다음과 같습니다.

3. 2025년 이후의 연구에서 보이는 프롬프트 설계의 변화

3.1 '길게 생각하기'에서 '사고 형식 선택하기'로

2025년 이후의 인지 계열 프롬프트 연구에서는 긴 추론을 내놓게 하는 것뿐만 아니라, 태스크에 따라 사고 형식을 바꾸는 방향이 눈에 띕니다.

Sketch-of-Thought는 문제에 따라 Conceptual Chaining, Chunked Symbolism, Expert Lexicons를 전환합니다 (arXiv:2503.05179). Fast, Slow, and Tool-augmented Thinking for LLMs는 LLM의 추론 전략을 빠른 직관적 응답, 느린 숙고, 외부 도구 확장이라는 관점에서 정리하고 있습니다 (Jia et al., 2025, arXiv:2508.12265).

즉, 모든 문제에 동일한 "깊게 생각하라"는 프롬프트를 사용하는 것이 아니라, 문제의 종류에 맞춰 짧은 스케치, 방법론, 인지 도구, 디바이어싱 (Debiasing)을 선택하는 것이 좋다는 흐름입니다.

3.2 외부 도구뿐만 아니라, 내적 도구도 설계 대상이 된다

도구 이용이라고 하면 검색, 계산기, 코드 실행을 떠올리기 쉽습니다. 하지만 Cognitive Tools는 문제 이해나 검사와 같은 내적인 인지 조작도 도구로 다룹니다 (arXiv:2506.12115).

이러한 관점은 프롬프트 설계에 활용하기 좋습니다. 매번 모든 단계를 강제하는 것이 아니라, "필요한 인지 도구만 골라서 사용하라"고 지시할 수 있기 때문입니다. 이를 통해 고정된 절차의 경직성을 줄일 수 있습니다.

3.3 정답률만으로는 평가가 부족하다

2025년 이후의 연구에서는 정답률뿐만 아니라 토큰 수, 추론 효율, 중복성, 편향 (Bias), 충실도 (Faithfulness)도 문제가 됩니다.

Sketch-of-Thought는 토큰 절감과 정확도 유지를 동시에 목표로 합니다 (arXiv:2503.05179).

CoRE-Eval은 과도한 생각을 감지하여 추론을 빠르게 중단시키는 방향을 지향합니다 (arXiv:2507.06087).

Cognitive Debiasing은 의사결정에서의 인지 편향을 다룹니다 (arXiv:2504.04141).

Measuring Chain of Thought Faithfulness by Unlearning Reasoning Steps는 CoT (Chain of Thought)가 모델의 내부적인 신념에 충실한지를 측정하는 프레임워크를 제안합니다 (Tutek et al., 2025, arXiv:2502.14829).

프롬프트 평가에서는 "정답 같은 답이 늘어났는가"뿐만 아니라, "비용이 얼마나 많이 들었는가", "설명은 신뢰할 수 있는가", "편향이 증가하지 않았는가"도 살펴봐야 합니다.

4. 어떤 템플릿을 선택해야 하는가

템플릿 선택을 감각에만 의존하면 흔들리기 쉽습니다. 그래서 간단한 의사결정 매트릭스를 활용합니다. 평가 항목을 정하고, 가중치를 부여한 뒤, 5점 만점으로 채점합니다.

여기서는 문서 QA, 사양 확인, 조사 답변에 사용하는 것을 가정합니다. 가중치는 다음과 같습니다.

평가 항목	가중치	5점에 가까운 상태
근거 확인 용이성	2.0	어떤 본문·조건에 기반하는지 추적하기 쉬움
...	...	...

이 기준으로 가채점하면 다음과 같습니다.

템플릿	근거 확인	조건 누락 방지	짧음·대기 시간	도입 용이성	고위험 판단	가중 합계
Evidence → Answer → Caveat	5	4	5	5	3	33.5
...	...	...	...	...	...	...

이 표는 보편적인 순위가 아닙니다. 문서 QA에 무게를 둔 가중치로 본 가채점 결과입니다. 수학 난제라면 Cognitive Tools 유형의 점수가 올라갑니다. 의사결정의 편향을 점검하고 싶다면 Cognitive Debiasing 유형의 점수가 올라갑니다.

고민될 때는 다음 순서로 생각하면 선택하기 쉽습니다.

문서 QA·사양 확인·조사 답변: Evidence → Answer → Caveat -
누락이 허용되지 않는 복잡한 질문: Goal → Evidence → Answer → Check -
고난도 수학·추론: Cognitive Tools 유형 -
출력을 짧게 하고 싶은 추론 태스크: Sketch-of-Thought 유형 -
의료·법무·금융 등 판단 편향이 우려되는 상황: Cognitive Debiasing 유형

점수는 결정을 자동화하기 위한 것이 아닙니다. 직관과 점수가 어긋날 때, "무엇을 중시하고 있는지"를 가시화하기 위한 것입니다.

5. 실무에서 평가할 때의 최소 체크리스트

인지 프롬프트 (Cognitive Prompt)는 도입하는 것만으로는 효과를 판단할 수 없습니다. 작더라도 검증 세트 (Validation Set)를 만들 필요가 있습니다.

검증 세트 (Validation Set)란 LLM에게 답을 하게 만드는 문제집을 의미합니다. 예를 들어, Hono 문서 QA에서는 다음과 같은 문제들을 만들었습니다.

HTTPException.getResponse()

는 Context에 설정된 헤더를 자동으로 포함하는가?

ContextVariableMap을 글로벌 확장하면 어떤 타입 안전성 (Type Safety) 측면의 함정이 있는가?

app.get('*', ...)를 먼저 등록했을 때, GET /foo는 어느 쪽에 매칭되는가?

c.set() / c.get()의 값은 다른 요청에 공유되거나 영속화(Persistence)되는가?

app.notFound()는 자식 앱 측에서도 호출되는가?

이러한 문제들에 대해, 통상적인 프롬프트 (Normal Prompt)와 인지 프롬프트 (Cognitive Prompt)를 동일한 모델로 실행하여 답변을 비교합니다. 이전 섹션의 Hono 검증에서는 통상적인 프롬프트보다 근거와 주의점을 명시하는 프롬프트가 조건의 누락을 줄이는 경향이 나타났습니다.

여기서 사용한 키워드 스코어는 "정답에 필요한 단어가 포함되어 있는가"를 보는 간이 지표입니다. 예를 들어, 미들웨어 (Middleware) 예외 처리 문제에서는 next(), never throw, onError, 500과 같은 단어가 포함되기를 기대했습니다. 완전한 정답률은 아니지만, 조건의 누락을 확인하는 데 유용합니다.

실무 평가에서 최소한으로 확인해야 할 것은 다음 5가지입니다.

• 정답률·타당성: 통상적인 프롬프트보다 답변이 좋아졌는가?
• 토큰 수·시간: 출력이 너무 길어지지는 않았는가?
• 실패 패턴: 조건 누락, 과잉 추론, 편향 (Bias), 사실 오인이 줄었는가?
• 검증 용이성: 답변의 근거이나 불확실성을 확인하기 쉬워졌는가?
• 검색·문맥 품질: 애초에 올바른 부분을 컨텍스트 (Context)에 넣고 있는가?

이 부분은 놓치기 쉬운 점입니다. 문서 QA에서는 LLM 이전에 "어느 본문을 전달할 것인가"라는 검색 (Retrieval) 처리가 있습니다. 필요한 부분이 전달되지 않으면 프롬프트를 아무리 개선해도 답하기 어려워집니다. 이번 검증에서도 제목 추출이 어긋난 문제의 경우, 구조화된 프롬프트 (Structured Prompt)를 사용했음에도 낮은 점수를 기록했습니다.

중요한 것은 프롬프트가 "좋아 보이는가"로 판단하지 않는 것입니다. 추론문이 깔끔하더라도 답이 틀렸다면 의미가 없습니다. 반대로 답변이 짧더라도 근거와 주의점이 갖춰져 있다면 실무적으로는 충분할 수 있습니다.

이 평가 흐름은 다음과 같이 생각하면 재사용하기 쉽습니다.

6. 주의점: 추론문은 "진짜 이유"가 아닐 수 있다

2025년 이후의 연구에서도 CoT (Chain of Thought)나 추론문의 신뢰성 (Faithfulness)은 미해결 과제로 다뤄지고 있습니다.

Measuring Chain of Thought Faithfulness by Unlearning Reasoning Steps는 생성된 추론 단계가 모델의 파라메트릭한 신념 (Parametric Belief)에 충실한지를 측정하는 프레임워크를 제안합니다. FUR라는 기법을 통해 추론 단계에 포함된 정보를 모델 파라미터에서 지우고, 그것이 예측에 미치는 영향을 살펴보는 방식입니다 (arXiv:2502.14829).

여기서 알 수 있는 점은 추론문을 감사 로그 (Audit Log)처럼 취급하는 것은 위험하다는 것입니다. 인지 프롬프트는 더 나은 답에 도달하기 위한 작업 분해 (Task Decomposition)일 뿐, 설명의 진실성을 보장하는 것이 아닙니다.

고위험 용도에서는 다음 중 하나가 필요합니다.

• 외부 소스 확인
• 테스트 케이스를 통한 평가
• 인간 리뷰 (Human Review)
• 반례 체크
• 로그와 실행 결과의 대조

7. 요약

2025년 이후의 논문들에 집중해 보면, 인지 프롬프트의 방향성을 어느 정도 파악할 수 있습니다.

• 인지 조작을 명시한다.
• 문제에 적합한 사고 형식을 선택한다.
• 긴 추론이 아니라 필요한 중간 표현 (Intermediate Representation)을 출력한다.
• 인지 편향 (Cognitive Bias)이나 과도한 생각을 탐지한다.
• 정답률뿐만 아니라 비용과 신뢰성 (Faithfulness)도 평가한다.

실무에서는 먼저 작은 검증 세트로 통상적인 프롬프트와 비교하는 것이 현실적입니다. 이번 Hono 문서 QA에서도 비록 30문제뿐이었지만, 이번 조건하에서는 통상적인 프롬프트와의 차이가 보이는 결과가 나왔습니다. 다만, 채점기나 검색기의 미흡함도 동시에 드러났습니다. 개선을 확인하는 지표는 정답률만이 아닙니다. 토큰 수, 실패 패턴, 검증 용이성, 검색된 문맥의 품질도 함께 살펴봐야 합니다.

첫걸음은 그리 거창하게 준비하지 않아도 된다고 생각합니다. 자주 묻는 질문을 10~30개 정도 모아, 통상적인 프롬프트와 Evidence → Answer → Caveat

패턴을 비교하는 것만으로도 조건 누락이나 근거 부족의 경향을 파악할 수 있습니다.

인지 프롬프트 (Cognitive Prompt)는 LLM을 갑자기 똑똑하게 만드는 방법이 아닙니다. LLM에게 맡기는 작업을 더 검증하기 쉬운 인지 단계 (Cognitive Step)로 분해하는 설계 기법입니다.

"더 깊이 생각해"라고 부탁하기 전에, 먼저 "무엇을 근거로, 무엇을 답하고, 어떤 주의사항을 남길 것인가"를 나누십시오. 이것만으로도 답변을 점검하기 쉬워지는 상황이 있습니다.

본문 내 보조 검증: Hono 문서 QA에서 무엇을 비교했는가

Hono 공식 문서를 사용한 검증은 연구 논문이 아닙니다. 이 기사의 주장을 실무 관점에서 확인하기 위한 작은 보조 실험입니다. 30개의 질문과 개별 답변 전체는 본문에 싣지 않았으므로, 공개 벤치마크가 아닌 수중에 있는 보조 검증으로 취급합니다. 제삼자가 유사한 조건에서 재현 실험 (Reproduce)을 하기 쉽도록 조건을 본문에 남깁니다.

이번 입력에는 Hono 공식이 공개하고 있는 llms-full.txt를 사용했습니다. 이는 LLM이 읽기 쉽도록 공식 문서 전체를 하나의 텍스트로 정리한 것입니다. Hono는 Cloudflare Workers, Deno, Bun, Node.js 등에서 동작하는 경량 Web Framework입니다. 문서에는 Routing, Context, Middleware, HTTPException, Testing, JSX 등 구현 시 실수하기 쉬운 사양들이 정리되어 있습니다.

이 문서를 선택한 이유는 세 가지입니다. 첫째, 공식 소스이므로 답변의 정오를 본문과 대조하여 확인하기 쉽다는 점입니다. 둘째, 단순한 개념 설명뿐만 아니라 c.set() / c.get()의 생명 주기 (Lifecycle), 라우팅 등록 순서, HTTPException.getResponse()의 주의점과 같이 조건을 놓치면 오답이 되기 쉬운 항목들이 포함되어 있다는 점입니다. 셋째, 하나의 공개 URL로 재취득할 수 있어 제삼자가 유사한 조건에서 재현 실험을 하기 쉽다는 점입니다.