1. Claude가 답을 만드는 방식

앞 장 마지막에서 어떻게 말하느냐에 따라 결과가 달라진다고 했습니다. 그런데 말하는 요령으로 바로 들어가는 대신, 여기서는 원리에서 시작하려 합니다. 주기적으로 새 대화를 열고, 길어진 대화를 압축하는 뒤에 나올 습관들이 모두 이 원리에서 나오는데, 이유를 모르는 규칙은 바쁠 때 가장 먼저 건너뛰게 되기 때문입니다.

우리가 쓰는 채팅, Cowork, Code는 모두 '모델'이라는 수학 공식 위에서 돌아갑니다. 조금 진부하더라도 이 공식이 답을 만드는 방식과 컨텍스트 윈도우를 살펴보고, 프롬프트 엔지니어링이 컨텍스트 엔지니어링과 하네스 엔지니어링으로 어떻게 넓어져 왔는지까지 따라가 보겠습니다.

1.1 생성형 AI의 원리

같은 질문을 해도 생성형 AI가 매번 다른 답을 내놓는다는 것을 우리는 경험으로 알고 있습니다. 생성형 AI는 다음에 올 단어를 확률로 따져 한 단어씩 골라 문장을 만듭니다. 이렇게 텍스트를 만들어 내고, 확률을 계산해 채택하게 만드는 수학 수식의 총체를 우리는 '모델'이라고 부릅니다.

그런데 왜 질문할 때마다 답이 달라질까요. 위 그림에서 모델은 '찌개'가 이어질 가능성을 58%로 가장 높게 봤지만, 그렇다고 매번 '찌개'만 고르지는 않습니다. 일부러 중간중간 확률이 낮은 단어도 채택하도록 만들어져 있기 때문입니다. 그래야 답이 더 자연스럽고 사람다워 보입니다. 단어 하나를 고를 때 생기는 이 작은 차이가 문장 전체로 쌓이고 또 쌓이면, 같은 질문에도 결이 사뭇 다른 답이 나오게 됩니다.

그러면 이런 질문을 던져볼 수 있습니다. 내가 원하는 최선의 대답이 아래 그림처럼 여러 갈래 중 하나라면, 차선이 아닌 그 최선만 골라 받을 수는 없을까요.

ChatGPT가 등장한 뒤 그 방법이 많이 연구되었습니다. 그 흐름이 프롬프트 엔지니어링에서 컨텍스트 엔지니어링, 하네스 엔지니어링으로 이어져 왔는데, 이 이야기는 1.3에서 하겠습니다. 이름은 낯설어도 목표는 하나입니다. 앞으로 우리가 하게 될 여러 세팅은 모두, 위 그림의 갈래 중 내가 원하는 하나가 나올 가능성을 높이는 작업입니다.

지금까지의 설명을 눈으로 직접 확인해 볼 수 있는 시뮬레이션을 준비했습니다. 입력 문장이 인공 신경망을 거쳐 다음 단어 확률로 바뀌는 과정을 한 단계씩 재생해 볼 수 있고, 방금 소개한 온도 손잡이를 직접 움직여 답이 어떻게 달라지는지도 실험할 수 있습니다. 왜 대화를 새로 여는 편이 좋은지, 학습이 무엇인지 같은 뒤쪽의 이야기도 미리 만날 수 있으니 한번 들러 보세요.

• 시뮬레이션: https://llmplay.weniv.co.kr/

1.2 컨텍스트 윈도우

답을 확률로 고른다면, 그 확률은 무엇을 보고 정해질까요. 바로 그 순간 Claude 앞에 놓인 정보 전체입니다. 그리고 그 정보는 우리가 입력창에 친 글만이 아닙니다.

Claude Desktop은 입력창에 넣은 내용과 함께, 그 입력창이 열려 있는 작업 폴더 안의 자료까지 같이 봅니다. 5장에서 보고서와 데이터 파일을 폴더에 넣어두자 Claude가 그걸 근거로 답했던 것을 떠올려보세요. 입력창의 말, 폴더 속 자료, 그리고 지금까지 주고받은 대화, 이렇게 그 순간 Claude가 보고 있는 것 전체를 맥락(컨텍스트)이라고 합니다. 같은 프롬프트라도 맥락이 다르면 답은 달라집니다. 맥락이 많으면 더 좋은 답을 줄 수도 있습니다.

그런데 이 맥락에는 흔한 오해가 두 개 붙어 있습니다.

1. 내 대화를 '학습'한다
2. 같은 주제라면 대화를 계속 이어가는 편이 좋다

먼저 '학습'은 수학 수식 자체를 개선하는 행위입니다. 여러분이 입력한 데이터가 그 즉시 모델에 학습되는 것은 아닙니다. 대화 중에는 앱에 남아 있다가 함께 컨텍스트로 전달될 뿐입니다. 이런 개선 작업은 그렇게 자주 일어나지 않고, 어떤 데이터를 학습에 쓸지도 약관과 설정(3장에서 본 'AI 모델 개선 돕기' 항목)에 따라 달라지며, 보통은 동의를 받고 엄선한 데이터로 이뤄집니다.

두 번째로, 같은 주제라고 대화를 한없이 이어가는 분이 있는데, 대화가 길어지면 안타깝게도 지능이 떨어집니다. 모델이 한 번에 들여다볼 수 있는 양에는 한계가 있고, 이 한계를 컨텍스트 윈도우(context window)라고 부릅니다. 아무리 넓은 책상도 올려둘 수 있는 서류에는 한계가 있는데, 그 책상이 컨텍스트 윈도우입니다.

처음에 했던 질문과 나중에 한 질문이 충돌할 수도 있고, 중간에 방향이 바뀔 수도 있으며, 사이에 들어온 방대한 데이터 때문에 여러분의 중요한 지시가 희석될 수도 있습니다. 책상 위에 서류가 잔뜩 쌓이면 정작 중요한 한 장을 찾기 어려워지는 것과 같습니다.

게다가 문제는 컨텍스트 윈도우가 가득 차기 한참 전부터 시작됩니다. 책상에 올려둔 서류가 많아지는 것만으로도 모델은 점점 둔해집니다. 관련 연구 세 가지를 살펴보겠습니다.

첫 번째는 NoLiMa라는 벤치마크 연구입니다. 벤치마크는 여러 모델에 같은 시험지를 주고 성능을 재는 방식을 말합니다. 이 연구는 컨텍스트가 길어질수록 모델이 의미로 연결된 정보를 찾아내는 능력이 급격히 떨어진다고 보고했습니다. 아래 그래프를 보면, 짧은 맥락에서 99%에 가깝던 정확도가 책 몇십 페이지 분량(약 3만 토큰)에서는 가장 선전한 모델조차 70% 아래로 내려가고, 상당수 모델은 절반인 50% 밑으로 주저앉습니다.

• 출처: NoLiMa: Long-Context Evaluation Beyond Literal Matching, https://arxiv.org/abs/2502.05167

두 번째는 정보의 '위치'를 다룬 연구입니다. Lost in the Middle은 긴 맥락 안에서 정답에 해당하는 정보를 어디에 두느냐에 따라 성능이 달라지는지를 살폈습니다. 그 결과 맨 앞이나 맨 뒤에 둔 정보는 잘 활용했지만, 가운데에 묻힌 정보는 놓치는 경향이 뚜렷했습니다. 정확도를 위치에 따라 그려보면 양 끝이 높고 가운데가 낮은 U자 모양이 나타납니다. 길게 쓴다고 다 읽히는 것이 아니라서, 중요한 내용일수록 맥락의 앞이나 끝에 둬야 합니다.

• 출처: Lost in the Middle: How Language Models Use Long Contexts, https://arxiv.org/abs/2307.03172

세 번째는 대화 방식 자체를 다룬 연구입니다. LLMs Get Lost in Multi-Turn Conversation은 같은 작업을 한 번에 정리해서 지시했을 때와, 여러 턴에 걸쳐 조금씩 나눠 지시했을 때를 비교했습니다. 그랬더니 나눠 지시한 쪽이 여섯 가지 과제에서 평균 39% 낮은 성능을 보였습니다. 최신 모델도 예외가 아니었습니다.

• 출처: LLMs Get Lost in Multi-Turn Conversation, https://arxiv.org/abs/2505.06120

세 연구를 한 표로 정리하면 이렇습니다. 결이 조금씩 다르지만, 셋 다 "맥락을 쌓는 방식에 전략이 필요하다"라는 같은 방향을 가리킵니다.

그런데 이 '여러 턴에 나눠서 지시하기'가 바로 우리가 가장 흔히 쓰는 방식입니다. 일단 시켜보고 결과를 보면서 한 줄씩 고쳐나가는, 우리에게 가장 자연스러운 방식이 모델에게는 가장 불리한 시나리오입니다.

따라서 우리는 이 컨텍스트 윈도우를 주기적으로 관리할 필요가 있습니다. 새로운 창을 열어 대화를 시작하거나, 이전 대화를 압축해 이어가는 것이죠.

이 내용도 앞에서 소개한 시뮬레이션에 준비되어 있습니다. 대화가 길어질수록 무슨 일이 벌어지는지, 왜 새 대화를 여는 편이 나은지를 직접 확인해 보세요.

• 시뮬레이션: https://llmplay.weniv.co.kr/

1.3 프롬프트, 컨텍스트, 하네스 엔지니어링

이 책은 엔지니어링을 본격적으로 다루는 책은 아닙니다. 다만 앞에서 언급한 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링이 각각 무엇인지는 여기서 간단히 정리하고 넘어가겠습니다.

AI의 지능이 낮았던 시절에는 어떻게 질문해야 좋은 답을 얻을 수 있는지에 대한 연구가 활발했습니다. 이렇게 프롬프트를 짜서 답의 질을 끌어올리는 전략을 프롬프트 엔지니어링이라 부릅니다. 대표적인 예가 답을 곧바로 내놓게 하는 대신 풀이 과정을 단계적으로 쓰게 하면 추론 능력이 올라간다는 연구(Chain-of-Thought)입니다. 어려운 수학 문제를 받았을 때 곧장 답부터 적게 하면 자주 틀리지만, 중간 계산을 한 단계씩 적어 내려가게 하면 정답률이 눈에 띄게 올라갑니다. 사람이 암산할 때보다 손으로 풀어 쓸 때 실수를 덜 하는 것과 비슷합니다.

• 출처: Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, https://arxiv.org/abs/2201.11903

지능이 충분히 높아진 다음에는 관심이 질문을 다듬는 일에서 맥락을 갖춰 주는 일로 옮겨 갔습니다. 이렇게 맥락을 제공해 나에게 더 맞는 답을 끌어내는 것을 컨텍스트 엔지니어링이라 부릅니다. 여러분이 직접 자료를 올리는 것뿐만 아니라, Claude가 기억하고 있는 내 정보인 '메모리'를 활용하는 것도 여기에 포함됩니다. 다만 이 메모리는 모델에 학습된 데이터가 아니라 대화에 함께 실려 들어가는 정보라는 점을 기억해 주세요. 학습이 모델의 수식 자체를 고치는 일이라면, 메모리는 답을 만들 때 필요한 맥락을 제공하는 일입니다. 평소에는 의식하지 않아도 자연스럽게 쓰게 되지만, 의식적으로 쓸 수도 있습니다. '이것을 메모리에 기억해 줘'라고 말해 두면, 이후에는 새 대화를 열어도 그 정보가 컨텍스트에 함께 실립니다. 앞에서 권한 대로 대화를 주기적으로 새로 열어도, 메모리에 넣어둔 정보는 사라지지 않는 것이죠.

그리고 모델이 다양한 도구를 직접 다루며 실제로 일하고 그 결과까지 검증할 수 있게 되자, 이번에는 모델이 일할 판 자체를 짜 주는 일이 중요해졌습니다. 모델이 쓸 도구, 결과를 확인하고 다시 시도하는 절차, 작업할 폴더와 권한처럼 모델을 둘러싼 환경 전체를 설계하는 것을 하네스 엔지니어링이라 부릅니다.

그래서 아래처럼 두루뭉술하게 질문하면, Claude는 답부터 내놓는 대신 필요한 맥락을 되묻습니다.

이런 연구 성과 상당수는 이미 모델과 제품 안에 녹아 있습니다. 위 화면처럼 사용자가 기법을 따로 알지 못해도 Claude가 알아서 맥락을 챙기는 식이죠. 그렇다고 사용자가 배울 것이 없어진 것은 아닙니다. 좋은 질문을 만드는 법, 필요한 맥락을 제공하는 법은 여전히 유효한 지식입니다.