AI에 맡길 맥락, 많이 쌓기보다 덜 불러오게 정리해야 했다

Claude나 ChatGPT를 매일 쓰다 보면 어느새 ‘회사 소개’, ‘글 쓰는 말투’, ‘고객 응대 원칙’ 같은 파일이 하나둘 쌓입니다. 처음엔 이 파일 덕분에 AI가 내 사업을 아는 직원처럼 움직였는데, 몇 달 지나면 결과물이 묘하게 어긋나기 시작합니다. 어디가 틀렸는지 보려고 폴더를 열어 보면, 정작 그 파일이 어디 있는지 나도 모릅니다.

고수들도 지시문보다 맥락 파일 관리에 더 힘을 쏟고 있었습니다

사용성 연구 기관 Nielsen Norman Group(NN/g)은 여러 업종에서 Claude를 매일 쓰는 숙련 사용자들을 관찰한 연구를 내놓았습니다. 이들은 지시문은 말로 불러 주듯 가볍게 넣고, 정작 공은 ‘컨텍스트 라이브러리’에 들였습니다. 컨텍스트 라이브러리란 회사의 지식과 일하는 방식을 마크다운 파일이나 노션·슬랙 기록·회의록 같은 외부 도구에 모아 두고 AI가 참고하고 고치게 한 것을 말합니다. NN/g는 그 안의 맥락을 세 갈래로 나눕니다. 거의 바뀌지 않고 모든 대화에 영향을 주는 전역 맥락, 특정 프로젝트에만 쓰도록 범위를 정한 지역 맥락, 그리고 이메일이나 회의록처럼 정리되지 않은 채 AI가 뒤져 보는 주변 맥락입니다.

문제는 이 일을 도와주는 장치가 거의 없다는 점입니다. 참가자들은 맥락 다루는 법을 주로 X와 레딧의 글, 그리고 각자의 시행착오로 익혔습니다. 저마다 즉흥적으로 방식을 만들었고, 파일은 낡거나 사라졌으며, 많은 참가자가 ‘다른 누군가는 분명 더 잘하고 있을 것’이라고 여겼습니다. NN/g는 기술에 덜 익숙한 사용자라면 같은 문제를 더 크게 겪을 것이라고 봅니다. 다만 이 연구는 숙련 사용자를 직접 관찰한 질적 연구라서, 이런 일이 얼마나 흔한지를 비율로 보여 주지는 않습니다.

한 번 써 둔 지침은 몇 달 동안 아무도 고치지 않았습니다

가장 흔한 실패는 낡은 맥락이었습니다. 맥락 파일은 한 번 쓰인 뒤 몇 달씩 그대로 쓰였고, 그 사이 일하는 방식은 바뀌었습니다. 한 참가자는 매일 할 일을 요약해 주는 자동화를 돌렸는데, 본인의 일하는 방식이 조금씩 달라지면서 쓸모가 줄었습니다. Claude가 그의 메일과 메시지, 회의록에 폭넓게 접근할 수 있었는데도 자동화의 지침은 그 변화를 따라가지 못했습니다. 그는 쓸모없어진 부분을 그냥 건너뛰었을 뿐 AI에게 한 번도 말해 주지 않았습니다. 동료라면 다들 옛 양식을 안 쓴다는 걸 눈치채겠지만, AI는 아직 그런 신호를 알아채지 못한다는 것이 NN/g의 설명입니다.

외부 연결도 자주 끊겼습니다. 할 일 앱 연결이 계속 만료돼 손으로 다시 이어 붙여야 했던 참가자는 이를 ‘시스템 부패’라고 불렀습니다. 시간을 아끼려고 들인 도구가 관리할 거리를 늘린 셈입니다. 고치는 방식도 눈여겨볼 만합니다. 참가자 가운데 맥락 파일을 직접 타이핑해 고치는 사람은 거의 없었습니다. 파일이 눈앞에 열려 있어도 Claude에게 바꿔 달라고 했는데, 그게 더 빠르고 파일 전체의 문체와 구조도 일관되게 유지됐기 때문입니다. NN/g는 최근 회의록과 기존 지침을 AI에게 비교시켜 고칠 곳을 제안받고, 마음에 들지 않는 자동화가 있으면 몇 분 들여 그 불만을 말로 전하라고 권합니다.

정리 수준은 제각각이었고, 자기 파일을 못 찾는 일이 잦았습니다

파일 대부분을 AI가 만들고 관리하다 보니, 라이브러리 구조는 사용자가 설계한 것이 아니라 저절로 생겨난 것에 가까웠습니다. 관찰 도중 참가자들은 중요하다고 말한 문서를 자기 폴더에서 찾지 못해 결국 Claude에게 찾아 달라고 하곤 했습니다. 한 참가자는 Claude가 무엇을 해도 되고 안 되는지 정하는 전역 지침 파일을 그 자리에서 처음 발견했습니다. Claude 데스크톱 앱에서 만든 스킬이 어디에 저장됐는지 끝내 찾지 못한 사람도 있었습니다.

정리 습관은 극과 극이었습니다. 한 사람은 Claude가 만든 일회용 파일을 구글 드라이브에 흩어 두었고, 다른 한 사람은 2,700개가 넘는 맥락 파일을 꼼꼼한 계층 구조로 관리했습니다. 이 꼼꼼한 사용자는 폴더마다 ‘색인 카드’ 역할을 하는 파일을 두어 그 폴더에 무엇이 있고 언제 어떻게 쓰는지 적어 두었습니다. Claude 환경에서는 이 파일 이름을 CLAUDE.md로 짓습니다. NN/g는 이런 구조가 사람이 파일을 찾기 쉽게 해 줄 뿐 아니라 AI가 무엇을 불러올지까지 정한다고 강조합니다.

맥락을 많이 넣을수록 AI는 가운데를 놓쳤습니다

요즘 모델은 수백만 토큰을 받아들이니 다 넣어 주면 알아서 고르리라 기대하기 쉽지만, 연구 결과는 반대를 가리킵니다. 스탠퍼드 등의 연구진(Liu 외)은 여러 문서 가운데 정답이 든 문서 하나를 찾아 질문에 답하게 하면서, 그 문서의 위치와 전체 문서 개수를 바꿔 봤습니다. 성능은 정답 문서가 맨 앞이나 맨 끝에 있을 때 가장 높았고, 가운데에 있을 때 크게 떨어지는 U자 곡선을 그렸습니다. 당시 OpenAI 모델은 정답 문서의 위치만 바뀌어도 성능이 20% 넘게 떨어질 수 있었고, 가장 나쁜 경우에는 문서를 아예 주지 않고 기억만으로 답했을 때(56.1%)보다도 낮았습니다. 자료를 줬는데 주지 않은 것보다 못한 결과가 나온 것입니다.

모델을 바꿔도, 문서 수를 바꿔도 비슷한 모양이 반복됐습니다. 문서를 더 주는 것도 별 도움이 되지 않았습니다. 위키백과에서 검색해 답하는 실험에서 문서를 20개 대신 50개 넣어도 성능은 조금 오르는 데 그쳤습니다. 이 실험은 지금보다 앞선 세대 모델로 한 것이라 수치를 그대로 옮길 수는 없습니다.

최신 모델에서도 경향은 이어졌습니다. 검색용 데이터베이스를 만드는 회사 Chroma는 최신 모델을 포함한 18개 모델을 시험했습니다. 대화 기록을 바탕으로 질문에 답하는 과제 306개를 골라, 답에 필요한 부분만 준 경우와 관련 없는 내용까지 담긴 113k 토큰 분량 전체를 준 경우를 비교했더니, 모든 모델이 필요한 부분만 받았을 때 훨씬 잘 답했습니다. 추론 기능을 켠 모델에서도 그 차이는 남았습니다. Chroma는 실제 업무는 이 실험보다 복잡하니 성능 저하가 더 심할 것으로 예상하면서도, 왜 이런 현상이 생기는지는 밝히지 못했다고 한계를 적었습니다.

잘 쓰는 사람은 AI가 덜 불러오도록 설계했습니다

NN/g가 본 가장 정교한 라이브러리는 역설적으로 최대한 적게 불러오도록 만들어져 있었습니다. 주인은 작업을 어느 폴더에서 시작하느냐가 AI가 알 수 있는 범위를 정한다고 설명했습니다. 맨 위 폴더에서 시작하면 전체 지도를 보고 필요한 것을 끌어오고, 한 프로젝트 폴더 안에서 시작하면 그 프로젝트에만 머뭅니다. 규칙은 하나였습니다. “옆으로 가려면 먼저 위나 아래로 움직여야 한다.” 반대로 맥락을 범위 없이 넣은 사람들은 엉뚱한 적용을 겪었습니다. 팟캐스트용 디자인 지침이 전혀 상관없는 독서 기록 앱 작업에 적용되거나, 고객 통화와 메일을 읽던 Claude가 어떤 일을 본인이 했는지 동업자가 했는지 헷갈리기도 했습니다.

Anthropic도 같은 방향을 권합니다. 맥락은 한정된 자원이고 모델에게는 일종의 ‘주의력 예산’이 있어서, 토큰이 하나 들어올 때마다 그 예산이 줄어든다는 설명입니다. 그래서 좋은 맥락 설계를 원하는 결과를 낼 가능성을 가장 높이는, 신호가 강한 가장 작은 토큰 묶음을 찾는 일로 정리합니다. 실제로 Claude Code는 CLAUDE.md 파일만 처음부터 넣어 두고, 나머지는 필요할 때 파일을 검색해 그때그때 불러옵니다.

작은 온라인 사업에 옮겨 보면 이렇습니다. 상세페이지 작성, 고객 문의 답변, 홍보 글 원고처럼 일마다 폴더를 나누고, 각 폴더 맨 위에 무엇이 있고 언제 쓰는지 몇 줄로 적은 안내 파일을 둡니다. 회사 소개나 말투처럼 모든 일에 필요한 것만 위쪽에 두고, 특정 상품의 가격 정책은 그 상품 폴더 안에만 둡니다. 결과물이 어긋날 때는 그냥 넘기지 말고 “이 지침은 이제 이렇게 바뀌었으니 관련 파일을 고쳐 줘”라고 AI에게 말로 알려 줍니다. NN/g 참가자 대부분이 파일 하나를 수백 줄 아래로 유지했다는 점도 참고할 만합니다.

AI에게 더 많이 알려 주는 것보다, 지금 이 일에 필요한 것만 찾아 읽게 만드는 쪽이 결과를 지킵니다.