책에 포함된 노트컨텍스트 엔지니어링: 프롬프트를 넘어 AI가 제대로 일하게 만드는 정보 설계의 기술

Select 지금 필요한 것만 고르기

2026-04-30Views 6약 11분생성형 AI 활용

같은 사무실에서도 일 잘하는 사람의 책상은 조금 다릅니다. 자료가 없는 책상이 아니라, 지금 필요한 자료만 올라와 있는 책상에 가깝습니다. 지난달 회의록, 예전 초안, 이미 폐기된 아이디어, 관련은 있지만 당장 쓰지 않을 참고문서가 한꺼번에 쌓여 있으면, 책상은 넓어도 일은 느려집니다.

AI의 컨텍스트도 똑같습니다. 많은 사람은 정보가 많을수록 답이 좋아질 것이라고 생각합니다. 하지만 실제로는 그 반대가 자주 벌어집니다. 너무 많은 정보를 넣으면 모델은 중요한 것과 덜 중요한 것을 스스로 가려야 하고, 그 과정에서 정작 핵심을 놓치기 쉽습니다. 그래서 컨텍스트 엔지니어링에서 중요한 질문은 단순히 무엇을 저장할까가 아닙니다. 지금 이 단계에 무엇을 보여 줄까가 더 중요합니다.

바로 이때 필요한 것이 Select 전략입니다. Write가 중요한 정보를 밖에 남기는 기술이었다면, Select는 그 저장소에서 지금 필요한 것만 골라 컨텍스트 안으로 데려오는 기술입니다. 저장은 창고를 만드는 일이고, 선택은 작업대를 정리하는 일입니다. 둘은 붙어 다니지만, 같은 일은 아닙니다.

Select 지금 필요한 것만 고르기

Select는 저장이 아니라 호출이다

앞 장에서 본 Write 전략이 없다면, 긴 작업은 흔적 없이 흩어집니다. 하지만 Write만 있고 Select가 없으면 또 다른 문제가 생깁니다. 기록은 잔뜩 쌓였는데, 막상 쓸 때는 무엇을 가져와야 할지 몰라 전부 들고 오게 됩니다. 그러면 바깥 저장소가 거대한 창고가 아니라, 단지 더 큰 혼잡이 되어 버립니다.

Select의 핵심은 단순합니다. 기록된 정보 가운데 현재 질문을 푸는 데 직접 필요한 것만 고른다. 여기서 직접 필요하다는 말이 중요합니다. 관련 있어 보이는 것과 실제로 필요한 것은 다르기 때문입니다.

예를 들어 사용자가 사내 휴가 규정을 물었다고 해 봅시다. 이때 관련 있어 보이는 정보는 인사팀 문서 전체, 조직 문화 가이드, 출장 규정, 복지 안내, 예전 개정 이력까지 모두 포함할 수 있습니다. 하지만 실제로 필요한 정보는 훨씬 좁습니다. 최신 버전의 휴가 정책, 해당 사용자의 고용 형태에 맞는 조항, 예외 규정, 시행일이 핵심일 가능성이 큽니다. 나머지는 그럴듯한 배경음일 뿐입니다.

좋은 Select는 AI를 더 많이 먹이는 기술이 아닙니다. 덜 먹이되, 더 정확하게 먹이는 기술입니다.

왜 모든 정보를 넣으면 오히려 못 푸는가

긴 컨텍스트는 분명 유용합니다. 긴 문서를 한 번에 읽을 수 있고, 더 많은 대화 기록과 더 많은 검색 결과를 담을 수 있습니다. 하지만 길게 넣을 수 있다는 사실과, 길게 넣는 것이 항상 좋다는 말은 다릅니다. 실제로 장문 컨텍스트는 성능 저하, 주의 분산, 중간 정보 무시 같은 문제를 일으킬 수 있습니다.¹²

쉽게 말해, 모델의 작업 책상이 커졌다고 해서 집중력이 자동으로 좋아지는 것은 아닙니다. 오히려 책상 위에 자료를 잔뜩 펼쳐 놓으면 이런 일이 생깁니다.

중요한 제약이 덜 중요한 배경 설명에 묻힌다.
앞부분과 뒷부분은 잘 보는데 가운데 자료는 약하게 다뤄진다.
서로 다른 버전의 문서가 함께 들어와 충돌한다.
검색 결과가 많아질수록 그럴듯한 헛소리도 늘어난다.

특히 긴 컨텍스트에서는 중간에 놓인 정보가 약해지는 현상이 자주 보고됩니다. 겉으로는 백만 토큰, 이백만 토큰을 넣을 수 있어 보여도, 실제로는 그 전체를 똑같은 품질로 활용하지 못하는 경우가 많습니다.¹ 그래서 실무에서는 늘 이렇게 생각하는 편이 낫습니다. 넣을 수 있는 양이 아니라, 제대로 읽힐 양이 얼마인가를 기준으로 삼아야 합니다.

고신호 정보는 무엇이 다른가

Select를 잘하려면 먼저 고신호 정보가 무엇인지 알아야 합니다. 고신호 정보는 단순히 검색 점수가 높은 정보가 아닙니다. 현재 작업을 앞으로 밀어 주는 정보입니다. 보통 다음 네 가지 조건을 많이 만족합니다.

현재 질문의 핵심 제약을 직접 해결한다.
최신성, 권한 범위, 문서 버전이 맞다.
출처와 맥락이 분명해서 다시 검증할 수 있다.
비슷한 말의 반복이 아니라 새로운 판단 근거를 준다.

반대로 저신호 정보는 얼핏 관련 있어 보여도 실제 답변 품질에 거의 기여하지 않습니다. 이미 같은 뜻을 반복하는 문장, 현재 질문과 시간 범위가 맞지 않는 문서, 다른 대상에 대한 규정, 권한상 볼 수 없어야 하는 자료, 배경 설명만 길고 결론이 없는 문단이 여기에 속합니다.

Select의 실력은 결국 여기서 갈립니다. 검색 결과를 많이 가져오는 능력이 아니라, 무엇이 문제 해결에 직접 연결되는지 알아보는 눈이 필요합니다.

Select는 검색 한 번으로 끝나지 않는다

많은 팀이 검색을 곧 선택이라고 생각합니다. 하지만 검색은 시작일 뿐입니다. 실전에서는 보통 네 단계가 이어집니다.

검색: 가능한 후보를 넓게 찾는다.
필터링: 명시적 제약으로 후보군을 잘라 낸다.
랭킹: 남은 후보를 중요도 순으로 다시 세운다.
주입: 상위 결과만 현재 컨텍스트에 넣는다.

이 흐름을 이해하면 왜 단순 벡터 검색만으로는 부족한지 보입니다. 검색은 비슷한 것을 찾는 데 강합니다. 하지만 비슷하다는 이유만으로 필요한 것은 아닙니다. 필요한 정보를 고르려면 제약, 우선순위, 최신성, 신뢰도, 권한 같은 기준이 추가로 들어가야 합니다.

검색: 넓게 찾되 막연하게 찾지 말라

좋은 선택은 좋은 검색에서 시작합니다. 다만 여기서 중요한 것은 넓게 찾는 것과 아무 생각 없이 많이 찾는 것을 구분하는 일입니다.

검색 방식은 보통 세 갈래로 생각할 수 있습니다.

키워드 검색은 정확한 용어, 에러 코드, 법령명, 제품명처럼 글자 자체가 중요한 경우에 강합니다.
의미 검색은 표현은 달라도 뜻이 비슷한 내용을 찾는 데 유리합니다.
하이브리드 검색은 이 둘을 섞어, 정확한 단어와 의미 유사성을 함께 챙깁니다.

예를 들어 코딩 에이전트가 에러를 조사할 때는 로그 속 정확한 함수명과 에러 메시지가 중요하므로 키워드성이 강합니다. 반면 고객지원 챗봇이 고객의 불만을 정책 문서와 연결할 때는 같은 의미를 다른 표현으로 말하는 경우가 많아 의미 검색이 중요해집니다. 실무에서는 둘 중 하나만 고집하기보다, 질문 성격에 맞춰 섞는 편이 훨씬 안정적입니다.

또 하나 중요한 점은 질문을 그대로 검색어로 쓰지 않는 것입니다. 사용자의 질문은 종종 너무 길거나, 너무 애매하거나, 여러 조건이 한 문장에 섞여 있습니다. 그럴 때는 먼저 질문을 풀어야 합니다. 시간 조건이 있는가, 특정 제품군인가, 최신 문서만 필요한가, 개인 권한과 연결되는가, 비교가 필요한가를 나누어 보면 검색 후보가 훨씬 좋아집니다.

필터링: 비슷한 것 말고 맞는 것을 남겨라

필터링은 Select의 진짜 힘이 드러나는 구간입니다. 검색이 후보를 불러오는 일이라면, 필터링은 후보의 자격을 심사하는 일입니다.

이 단계가 중요한 이유는 벡터 검색이 사용자의 명시적 조건을 자주 놓치기 때문입니다. 의미상 비슷한 문서를 잘 찾더라도, 최신 연도, 특정 국가, 특정 고객 등급, 특정 제품 버전 같은 조건은 별도로 걸러 주지 않으면 엉뚱한 자료가 섞일 수 있습니다. Microsoft의 Azure AI Search 예시에서도, 단순 벡터 검색은 질문 속 연도 조건을 충분히 반영하지 못했지만 메타데이터 사전 필터를 적용하자 원하는 문서만 남았습니다.³

이 차이는 아주 큽니다. 사용자는 보통 단지 비슷한 정보를 원하는 것이 아니라, 자기 상황에 맞는 정보를 원합니다. 그래서 필터링은 단순 최적화가 아니라 정답의 울타리를 세우는 과정입니다.

실무에서 자주 쓰는 필터 조건은 다음과 같습니다.

날짜와 버전: 최신 문서만, 특정 시행일 이후 문서만
출처와 권한: 사내 위키만, 승인된 정책만, 내 권한 범위 내 문서만
대상과 범위: 한국 고객용, 엔터프라이즈 플랜용, 특정 제품군만
형식과 상태: FAQ만, 정책 문서만, 폐기되지 않은 문서만

이런 조건이 빠지면 검색 점수는 높아도 실무 답변은 틀릴 수 있습니다. 특히 기업 환경에서는 필터링이 단지 품질 문제가 아니라 보안 문제이기도 합니다. 사용자의 권한 등급에 맞는 자료만 보게 만드는 일은 Select의 일부입니다.³

메타데이터는 선택의 눈이다

필터링을 가능하게 하는 핵심 재료가 메타데이터입니다. 메타데이터는 본문 바깥에 붙는 설명표처럼 보이지만, 실제로는 검색 품질을 크게 좌우하는 정보입니다. 날짜, 출처, 주제, 문서 유형, 페이지 번호, 권한 수준, 문서 버전 같은 값이 여기에 들어갑니다.⁴

특히 RAG에서는 청크에 메타데이터를 붙이는 습관이 중요합니다. 같은 문서에서 쪼개진 조각이라도, 어느 문서에서 왔는지, 몇 페이지인지, 어떤 섹션인지, 최신 버전인지가 함께 저장되어 있어야 나중에 제대로 고를 수 있습니다.⁴⁶

메타데이터가 없으면 어떤 일이 생길까요. 검색은 그럴듯한 문단을 가져오지만, 그 문단이 오래된 정책인지, 초안 문서인지, 신뢰할 수 있는 출처인지, 같은 문서의 몇 번째 조각인지 알기 어려워집니다. 반대로 메타데이터가 잘 붙어 있으면 선택은 훨씬 정밀해집니다.

예를 들어 이런 필드들은 특히 자주 도움이 됩니다.

source: 어디서 온 정보인가
date / version: 지금도 유효한가
topic / category: 어떤 질문 유형에 맞는가
page_number / section: 답변 근거를 어디서 찾았는가
access_level: 이 사용자가 봐도 되는가

메타데이터를 잘 설계한 시스템은 검색 결과가 적어도 강하고, 메타데이터가 빈약한 시스템은 검색 결과가 많아도 흔들립니다. 결국 Select는 본문만의 싸움이 아니라, 본문을 둘러싼 설명 정보의 설계이기도 합니다.

랭킹: 먼저 읽힐 자격을 다시 정하라

검색과 필터링을 거쳤다고 끝이 아닙니다. 여전히 여러 후보가 남습니다. 이제는 무엇을 먼저 읽힐지 순서를 정해야 합니다. 이것이 랭킹입니다.

좋은 랭킹은 단순히 유사도 점수만 보지 않습니다. 실무에서는 보통 여러 신호를 함께 봅니다. 질문과의 직접 관련성, 문서의 최신성, 출처 신뢰도, 중복 여부, 다양한 관점의 포함 여부가 대표적입니다. 예를 들어 같은 뜻을 반복하는 청크 다섯 개보다, 핵심 정책 조항 하나와 예외 조항 하나, 적용 범위를 설명하는 문단 하나가 더 좋은 상위 결과일 수 있습니다.

이 단계에서 자주 쓰는 방법이 리랭킹입니다. 처음 검색에서는 넓게 후보를 가져오고, 그다음 더 정교한 모델이나 규칙으로 다시 줄을 세우는 방식입니다. Multi-Meta-RAG 연구는 메타데이터 필터링과 리랭킹을 함께 사용했을 때 상위 청크 선택 품질이 개선되었고, 특히 적은 수의 청크만 넣는 상황에서 실질적인 이득이 커질 수 있음을 보여 주었습니다.⁵

이 말은 곧 이런 뜻입니다. 많이 뽑는 능력보다, 적게 넣어도 맞게 넣는 능력이 더 중요하다. 컨텍스트 엔지니어링은 늘 최종적으로 제한된 공간을 다루기 때문입니다.

Select가 자주 실패하는 패턴

실무에서 반복해서 보이는 실패 패턴도 있습니다.

많이 넣으면 안전하다고 믿는 경우: 실제로는 핵심이 묻히고 비용만 늘어납니다.
검색 점수를 맹신하는 경우: 유사한 문장과 필요한 문장은 다를 수 있습니다.
메타데이터를 대충 붙이는 경우: 최신성, 버전, 권한, 출처를 구분하지 못합니다.
문서 단위로만 넣는 경우: 필요한 문단 하나를 위해 긴 문서 전체를 넣어 잡음을 늘립니다.
선택 결과를 검토하지 않는 경우: 상위 결과가 왜 뽑혔는지 확인하지 않으면 실패가 반복됩니다.

특히 마지막이 중요합니다. 선택은 눈에 잘 안 보이는 설계라서, 잘못되어도 모델 탓으로 넘어가기 쉽습니다. 하지만 성능이 흔들릴 때는 먼저 상위에 올라온 청크를 직접 봐야 합니다. 질문과 정말 맞았는지, 오래된 문서가 섞였는지, 거의 같은 내용이 반복되었는지 확인하면 문제의 절반은 이미 보입니다.

Select를 잘하려면 질문부터 구조화하라

좋은 선택은 좋은 질문 해석에서 시작합니다. 사용자 질문을 그대로 검색기에 던지는 대신, 먼저 어떤 종류의 질문인지 분해하면 훨씬 정교해집니다.

아래 순서를 습관처럼 적용해 보면 좋습니다.

먼저 질문의 목적을 구분한다. 설명 요청인지, 비교인지, 최신 정보 확인인지, 행동 판단인지 본다.
다음으로 필수 제약을 뽑는다. 날짜, 버전, 권한, 대상 사용자, 지역, 제품군 같은 조건이다.
그다음 넓은 검색으로 후보를 모은다. 이 단계에서는 놓치지 않는 것이 중요하다.
이후 메타데이터 필터로 후보를 자른다. 여기서 실무 정확도가 크게 올라간다.
마지막으로 리랭킹해 상위 몇 개만 컨텍스트에 넣는다.

이 흐름은 단순하지만 강력합니다. 검색이 recall, 즉 놓치지 않기 위한 단계라면, Select의 나머지 과정은 precision, 즉 맞는 것만 남기기 위한 단계라고 생각하면 이해가 쉽습니다.

작은 예제로 보는 Select 설계

예를 들어 사용자가 이렇게 물었다고 해 봅시다. 신제품 A의 기업 고객 환불 규정은 2026년 기준으로 어떻게 되나.

이 질문에 대해 나쁜 시스템은 환불, 반품, 배송, 멤버십, 일반 소비자 정책, 구형 제품 정책까지 한꺼번에 불러옵니다. 검색 결과는 많고 그럴듯하지만, 정작 답변은 흐려집니다.

좋은 시스템은 먼저 질문을 구조화합니다. 제품은 신제품 A, 고객군은 기업 고객, 시간 조건은 2026년 기준, 주제는 환불 규정입니다. 그런 다음 정책 문서 중에서 제품=A, 고객유형=기업, 시행일이 2026년 이전이면서 최신 버전, 문서 상태=활성만 남깁니다. 그 후 환불 기간, 예외 조건, 승인 절차가 직접 언급된 청크를 상위로 올립니다.

이렇게 하면 컨텍스트에 들어가는 정보는 훨씬 적어지지만, 정답 가능성은 오히려 올라갑니다. 이것이 Select의 맛입니다. 적게 넣었는데 더 잘 맞습니다.

선택은 한 번이 아니라 반복이다

좋은 Select는 한 번에 완벽하게 끝나지 않습니다. 첫 선택은 가설에 가깝고, 답이 부족하면 다시 찾고 다시 자르는 과정이 이어집니다. 예를 들어 상위 청크를 읽어 보니 최신 조항은 보이는데 예외 규정이 빠져 있을 수 있습니다. 그러면 두 번째 검색은 예외 조건만 노리고 더 좁게 들어가면 됩니다.

이 반복이 중요한 이유는 현실의 질문이 늘 깔끔하지 않기 때문입니다. 사람도 서류를 찾을 때 첫 번에 끝내지 않습니다. 먼저 폴더를 찾고, 그다음 필요한 문서를 고르고, 마지막으로 그 안에서 정확한 조항을 집습니다. AI도 마찬가지입니다. Select는 한 번의 벡터 검색이 아니라, 질문을 따라 점점 초점을 맞춰 가는 과정입니다.

좋은 Select는 모델을 더 자유롭게 하는 것이 아니라 더 집중하게 한다

많은 사람이 AI 성능 향상을 생각할 때 더 큰 모델, 더 긴 컨텍스트, 더 많은 문서를 먼저 떠올립니다. 하지만 실무에서는 종종 그 반대가 더 효과적입니다. 범위를 줄이고, 후보를 자르고, 우선순위를 다시 세우는 일 말입니다.

AI는 빈칸을 채우는 데 능하지만, 무엇이 중요한지 환경이 말해 주지 않으면 엉뚱한 빈칸도 열심히 채웁니다. 그래서 Select는 단순한 검색 기술이 아니라, 모델의 주의를 설계하는 기술입니다. 어떤 정보가 먼저 보일지, 무엇은 아예 보이지 않게 할지, 어떤 조건을 반드시 만족해야 할지를 정하는 일입니다.

Write가 긴 작업의 흔적을 남기는 기술이라면, Select는 그 흔적 가운데 지금 답을 바꾸는 정보만 전면에 세우는 기술입니다. 이 감각이 생기면, 관련 있어 보이는 자료 더미와 실제로 필요한 근거를 구분하는 눈도 함께 자랍니다.

컨텍스트 엔지니어링에서 실력 차이는 종종 여기서 벌어집니다. 많이 아는 사람이 아니라, 지금 필요한 것만 남길 줄 아는 사람이 더 안정적인 시스템을 만듭니다.