좋은 지시문이 행동 기준이라면, 지식은 판단 재료입니다. 아무리 지시를 또렷하게 써도 AI가 참고할 사실이 없으면, 그럴듯한 말은 할 수 있어도 믿을 만한 답은 만들기 어렵습니다. 실무에서 이 차이는 아주 크게 드러납니다. 메일 문구를 다듬는 일은 대충 해도 되지만, 사내 규정, 제품 정책, 고객 계약, 최신 시장 정보가 걸린 질문에서는 "아는 척"이 곧 사고가 됩니다.
그래서 컨텍스트 엔지니어링에서 중요한 질문은 이것입니다. AI에게 무엇을 시킬까가 아니라, AI가 무엇을 보고 말하게 할까입니다. 이 장에서는 그 질문에 답해 보겠습니다. 내부 지식과 외부 지식은 어떻게 다르고, 문서와 데이터베이스와 웹 검색은 언제 써야 하며, RAG는 왜 필요한지 차근차근 살펴보겠습니다.
AI는 지식을 꺼내는 존재가 아니라, 지식을 참고하는 존재다
많은 사람이 AI를 처음 쓸 때 이런 기대를 합니다. "이 정도는 당연히 알고 있겠지." 하지만 실무에서는 이 기대가 가장 위험합니다. 모델은 학습 과정에서 엄청난 양의 텍스트를 접했을 수 있지만, 지금 내 회사의 최신 휴가 규정, 우리 제품의 이번 주 가격표, 어제 바뀐 법무 문구, 고객사별 계약 예외 조항까지 자동으로 알고 있는 것은 아닙니다.
여기서 중요한 감각이 하나 있습니다. 모델이 아는 것과 이번 답변에서 참조할 수 있는 것은 다르다는 점입니다. 전자는 막연하고 통제하기 어렵습니다. 반면 후자는 우리가 설계할 수 있습니다. 컨텍스트 엔지니어링은 바로 이 통제 가능한 쪽에 집중합니다.
실전에서는 차라리 이렇게 생각하는 편이 좋습니다. AI는 똑똑한 신입사원과 비슷합니다. 글은 잘 읽고, 요약도 잘하고, 형식도 잘 맞춥니다. 그러나 회사 사정은 모릅니다. 그러니 일을 맡기려면 자료를 줘야 합니다. 업무 매뉴얼을 주고, 관련 문서를 보여 주고, 필요하면 사내 시스템에서 값을 조회하게 해야 합니다. 이 과정을 설계하는 것이 지식 설계입니다.
내부 지식과 외부 지식은 성격이 다르다
AI에 넣을 지식은 크게 두 갈래로 나눠 생각하면 이해가 쉽습니다. 하나는 내부 지식이고, 다른 하나는 외부 지식입니다.
내부 지식은 우리 조직 안에 있는 정보입니다. 예를 들면 사내 위키, 업무 매뉴얼, 제품 문서, 회의록, 고객 응대 정책, 운영 기준서, 계약 템플릿 같은 것들입니다. 이 정보의 장점은 우리 일에 직접 맞닿아 있다는 점입니다. 단점은 정리가 엉성한 경우가 많고, 오래된 문서와 최신 문서가 섞여 있다는 점입니다.
외부 지식은 회사 밖에서 가져오는 정보입니다. 공개 웹사이트, 뉴스, 법령, 경쟁사 페이지, 시장 보고서, 기술 문서, 오픈 API 데이터 같은 것들이 여기에 들어갑니다. 장점은 최신성과 범용성입니다. 단점은 신뢰도와 관련성이 제각각이라는 점입니다. 검색으로 가져온 정보가 많다고 해서 좋은 답이 나오는 것은 아닙니다.
둘의 차이를 감각적으로 정리하면 이렇습니다.
내부 지식은 업무 적합성이 높다.
외부 지식은 범위와 최신성이 넓다.
실제 서비스는 대개 두 가지를 함께 다룬다.
예를 들어 고객지원 챗봇이라면 환불 규정은 내부 지식으로, 택배사 파업 뉴스는 외부 지식으로 다룰 수 있습니다. 제품 소개 문서를 쓰는 에이전트라면 우리 제품 기능표는 내부 지식이고, 경쟁사 비교 정보는 외부 지식이 됩니다. 중요한 것은 "어디서 왔는가"보다 "이 질문에 답하는 데 어떤 지식이 필요한가"입니다.
지식은 한 덩어리가 아니라 여러 그릇에 담겨 있다
실무에서 지식은 깔끔한 한 권의 교과서처럼 존재하지 않습니다. PDF 한 개에 모든 것이 들어 있지도 않습니다. 오히려 여기저기 흩어져 있습니다. AI 시스템은 이 흩어진 재료들을 상황에 맞게 꺼내 써야 합니다.
대표적인 지식의 그릇은 문서, 데이터베이스, 웹 검색입니다.
문서는 사람이 읽기 좋은 형태의 지식입니다. 정책서, 설명서, 회의록, 제안서, FAQ, 가이드 문서가 여기에 해당합니다. 문서의 장점은 맥락이 풍부하다는 것입니다. 다만 길고 장황할 수 있고, 필요한 정보가 여러 문단에 흩어져 있을 수 있습니다.
데이터베이스는 구조화된 지식입니다. 고객 등급, 주문 상태, 재고 수량, 가격표, 일정 정보처럼 칸과 행으로 정리된 값이 여기에 들어갑니다. 데이터베이스의 장점은 정확성과 조회 속도입니다. 하지만 서술적 설명에는 약합니다. 예를 들어 "왜 이런 정책이 만들어졌는가" 같은 배경은 데이터베이스보다 문서에 더 잘 담깁니다.
웹 검색은 외부 세계와 연결되는 창입니다. 최신 뉴스나 공개 규정, 실시간 변경 사항처럼 모델 내부 지식만으로는 다루기 어려운 정보를 끌어올 수 있습니다. 대신 검색 결과는 품질 편차가 큽니다. 제목은 그럴듯한데 내용은 빈약할 수 있고, 오래된 정보가 상단에 뜰 수도 있습니다.
결국 지식 설계는 "어느 저장소를 쓸까"의 문제가 아닙니다. 어떤 질문에 어떤 그릇의 지식을 연결할까의 문제입니다.
왜 모든 문서를 한꺼번에 넣으면 안 될까
처음 시스템을 만들 때 가장 흔한 실수는 단순합니다. 관련 있을 법한 자료를 전부 넣는 것입니다. 문서 50개를 한 번에 밀어 넣고, "이제 뭐든 잘 답하겠지"라고 기대합니다. 하지만 대개 결과는 반대입니다.
AI는 정보가 많다고 무조건 좋아지지 않습니다. 오히려 너무 많은 정보는 세 가지 문제를 만듭니다.
첫째, 중요한 정보가 묻힙니다. 고객 환불 조건 한 줄이 핵심인데, 부가 설명 20페이지에 파묻히면 모델은 엉뚱한 문장을 더 강하게 참고할 수 있습니다.
둘째, 서로 충돌하는 정보가 함께 들어옵니다. 예전 정책과 최신 정책이 동시에 보이면 어느 쪽을 우선해야 할지 흔들립니다. 사람도 헷갈리는 자료를 AI가 자동으로 깔끔하게 정리해 주리라고 기대하면 곤란합니다.
셋째, 질문과 관계없는 정보가 집중을 흐립니다. 회의실 예약 규정을 묻고 있는데 조직도, 복리후생 소개, 창립 스토리, 보도자료까지 같이 들어오면 답은 길어지고 핵심은 흐려집니다.
이 때문에 지식 설계의 핵심은 많이 넣는 것이 아니라 맞게 넣는 것입니다. 필요한 지식을 찾고, 고르고, 짧게 정리해 넣어야 합니다. 이 원칙이 바로 RAG로 이어집니다.
RAG는 필요한 지식을 그때 꺼내 붙이는 방식이다
RAG는 보통 검색 증강 생성이라고 부릅니다. 말이 어렵지만 개념은 의외로 단순합니다. 먼저 질문과 관련된 자료를 찾고, 그 자료를 컨텍스트에 붙인 다음, 그 자료를 바탕으로 답하게 만드는 방식입니다.
핵심은 "모델이 원래 다 알고 있기를 기대하지 않는다"는 데 있습니다. 대신 답변 직전에 필요한 지식을 찾아 보여 줍니다. 시험장에서 암기만 믿는 것이 아니라, 필요한 페이지를 펼쳐 놓고 답하게 만드는 셈입니다.
RAG의 기본 흐름은 보통 다음 순서로 이해하면 됩니다.
사용자가 질문한다.
시스템이 관련 문서나 데이터 조각을 찾는다.
찾은 내용을 정리해 모델에게 함께 전달한다.
모델은 그 자료를 근거로 답을 만든다.
이 구조의 장점은 분명합니다. 최신 정보 반영이 쉬워지고, 회사 내부 자료를 활용할 수 있으며, 답변의 근거를 추적하기도 쉬워집니다. 무엇보다 "아무 근거 없이 자신만만한 답변"을 줄이는 데 도움이 됩니다.
물론 RAG가 마법은 아닙니다. 검색이 틀리면 답도 틀리고, 가져온 자료가 장황하면 답도 흐려집니다. 그래서 중요한 것은 RAG를 쓴다는 사실 자체가 아니라, 무엇을 어떻게 찾고 어떤 형태로 붙이느냐입니다.
RAG를 이해하려면 검색보다 먼저 '지식 준비'를 봐야 한다
많은 초보자가 RAG를 검색 기능쯤으로 생각합니다. 하지만 진짜 성능 차이는 검색 버튼을 누르는 순간보다, 그 전에 지식을 어떻게 준비했느냐에서 갈립니다.
예를 들어 사내 정책 PDF를 통째로 넣는 것과, 주제별로 잘게 나누어 필요한 부분만 찾을 수 있게 만드는 것은 완전히 다른 결과를 냅니다. 긴 문서 한 권은 사람에게도 찾기 어렵습니다. 하물며 AI에게는 더 그렇습니다.
그래서 실무에서는 문서를 그대로 두지 않고, 찾기 쉬운 단위로 나누고, 제목과 날짜와 부서 같은 정보를 붙여 둡니다. 이 추가 정보는 흔히 메타데이터라고 부르는데, 쉽게 말하면 문서에 붙이는 꼬리표입니다. "인사팀", "2026년 개정", "환불 정책", "고객지원용" 같은 표시가 있으면 필요한 자료를 더 잘 가려낼 수 있습니다.
문서를 준비할 때 특히 중요한 것은 다음 네 가지입니다.
문서가 최신본인지
하나의 조각이 한 주제를 유지하는지
출처와 날짜를 확인할 수 있는지
오래된 문서와 새 문서를 구분할 수 있는지
RAG의 절반은 검색이고, 나머지 절반은 정리입니다. 정리가 안 된 지식창고는 AI에게도 그냥 어수선한 창고일 뿐입니다.
문서는 설명에 강하고, 데이터베이스는 사실 조회에 강하다
같은 질문이라도 어떤 지식원을 연결하느냐에 따라 품질이 달라집니다. 이 감각을 익히면 시스템이 훨씬 단단해집니다.
예를 들어 "우리 회사 반차 규정은 어떻게 되나요?" 같은 질문에는 문서가 적합합니다. 규정의 정의, 예외, 적용 범위, 신청 방식 같은 설명이 필요하기 때문입니다. 반면 "김민수 고객의 현재 구독 등급은 무엇인가요?" 같은 질문에는 데이터베이스가 적합합니다. 이건 설명보다 최신 값이 중요합니다.
실무에서는 둘을 이어야 하는 경우도 많습니다. "이 고객은 환불 대상인가요?"라는 질문을 보겠습니다. 여기에는 두 종류의 지식이 필요합니다. 환불 정책 자체는 문서에 있고, 이 고객의 결제 시점과 사용 이력은 데이터베이스에 있습니다. 즉, 규칙은 문서에서 읽고, 상태는 데이터베이스에서 조회해야 합니다.
이처럼 좋은 지식 설계는 한 가지 저장소를 고집하지 않습니다. 설명은 문서에서, 값은 데이터베이스에서, 최신 외부 변화는 검색에서 가져오는 식으로 역할을 나눕니다.
웹 검색은 만능이 아니라 '외부 최신성 보강 장치'다
웹 검색은 매우 유용하지만, 초보자가 가장 과신하기 쉬운 수단이기도 합니다. 검색을 붙이면 모든 답변이 좋아질 것 같지만 실제로는 그렇지 않습니다.
웹 검색이 특히 빛나는 순간은 최신성이 중요할 때입니다. 공개 정책 변경, 시장 동향, 언론 보도, 기술 문서 업데이트, 공공기관 발표처럼 시간이 민감한 정보에는 큰 도움이 됩니다. 반대로 사내 규정, 고객별 조건, 비공개 제품 로드맵처럼 내부 문맥이 중요한 질문에는 검색이 거의 도움이 되지 않거나 오히려 방해가 될 수 있습니다.
또 검색 결과는 언제나 검증이 필요합니다. 검색 상위 결과가 가장 정확한 것은 아닙니다. 광고성 글일 수도 있고, 오래된 블로그일 수도 있으며, 다른 나라 기준 문서일 수도 있습니다. 그래서 검색을 붙일 때는 "찾아오는 능력"만 볼 것이 아니라, "가져온 정보의 신뢰도를 가릴 능력"도 함께 설계해야 합니다.
검색을 쓸 때 실무적으로 자주 확인하는 기준은 이렇습니다.
출처가 공식 기관인지
게시일이나 개정일이 최신인지
질문의 지역과 맥락에 맞는지
원문과 요약 내용이 일치하는지
웹 검색은 훌륭한 보조 바퀴이지만, 운전대를 대신 잡아 주지는 않습니다.
검색된 정보의 품질은 어떻게 판단할까
RAG에서 많은 문제가 검색 단계에서 이미 시작됩니다. 관련 없는 문서가 들어오거나, 중요한 문서가 빠지거나, 오래된 문서가 최신 문서보다 먼저 선택되면 그다음 답변도 흔들립니다. 그래서 검색 품질을 보는 눈이 필요합니다.
좋은 검색 결과는 단순히 "비슷한 단어가 있는 문서"가 아닙니다. 이 질문에 답하는 데 실제로 도움이 되는 문서여야 합니다. 언뜻 관련 있어 보여도 쓸모없는 경우가 많습니다.
예를 들어 사용자가 "출장비 정산 시 택시비는 얼마까지 인정되나요?"라고 물었다고 해 봅시다. 이때 "출장 정책 전체 개요" 문서보다 "출장비 정산 세부 기준" 문서가 훨씬 유용합니다. 단어가 더 많이 겹치는 문서가 아니라, 답에 더 가까운 문서가 좋은 검색 결과입니다.
실무에서 검색 품질을 볼 때 유용한 기준은 다섯 가지입니다.
관련성: 질문과 직접 연결되는가
충실성: 실제 근거가 충분한가
최신성: 지금도 유효한 정보인가
권위성: 믿을 수 있는 출처인가
간결성: 핵심 답을 찾기 쉽게 담고 있는가
이 다섯 가지를 놓치면, 검색 시스템은 "무언가 많이 가져오는 기계"는 될 수 있어도 "쓸모 있는 지식을 건네는 시스템"은 되기 어렵습니다.
AI가 아는 척하지 않게 만드는 가장 현실적인 방법
현장에서 가장 듣기 싫은 말 중 하나는 이것입니다. "그럴듯하게 말했는데 틀렸어요." 이 문제는 모델 능력의 문제가기도 하지만, 더 자주 일어나는 원인은 근거 없이 답해도 되는 환경을 만들어 놓았기 때문입니다.
아는 척을 줄이려면 단순히 "환각을 줄여라"라고 말해서는 부족합니다. 시스템 차원에서 장치를 넣어야 합니다.
먼저, 근거 없는 답변을 허용하지 않는 규칙이 필요합니다. 제공된 자료에서 답을 찾지 못하면 모른다고 말하게 해야 합니다. 둘째, 가능하면 답변과 함께 근거 문서나 출처 구간을 제시하게 해야 합니다. 셋째, 정보가 모호하면 단정하지 말고 조건부 표현을 쓰게 해야 합니다. 넷째, 검색 결과가 빈약할 때는 성급히 답하게 하지 말고 추가 질문이나 사람 확인으로 넘겨야 합니다.
간단히 정리하면 이런 원칙입니다.
찾은 근거가 없으면 답을 축소한다.
근거가 약하면 자신감도 낮춘다.
정보가 충돌하면 차이를 드러낸다.
최신성이 중요하면 날짜를 확인한다.
AI를 똑똑하게 보이게 하는 것보다, 근거 있는 범위 안에서만 말하게 하는 것이 훨씬 중요합니다.
RAG의 결과는 검색만이 아니라 '붙이는 방식'에도 달려 있다
좋은 문서를 찾았다고 해서 자동으로 좋은 답이 나오는 것은 아닙니다. 찾은 자료를 모델에게 어떤 형태로 보여 주느냐도 중요합니다.
예를 들어 관련 문서를 다섯 개 찾았는데, 그중 세 개는 핵심 규정이고 두 개는 배경 설명이라고 해 보겠습니다. 이때 다섯 개를 같은 무게로 길게 붙여 넣으면 모델은 무엇이 핵심인지 놓칠 수 있습니다. 반대로 문서 제목, 날짜, 핵심 문단을 정리해서 우선순위까지 함께 보여 주면 답이 훨씬 안정됩니다.
실무에서는 검색 결과를 그냥 던지지 않고 다듬는 경우가 많습니다. 문서 제목을 붙이고, 날짜를 표시하고, 질문과 직접 관련된 부분만 발췌하고, 서로 충돌하는 자료가 있으면 그것도 표시합니다. 이렇게 하면 모델은 "자료 더미"가 아니라 "정리된 참고 묶음"을 받게 됩니다.
즉, RAG는 검색 시스템이면서 동시에 편집 시스템입니다. 무엇을 가져왔는지만큼, 어떻게 보여 줬는가도 중요합니다.
작은 예시로 보는 RAG: 사내 휴가 규정 챗봇
이제 아주 현실적인 예를 하나 들어 보겠습니다. 사내 챗봇이 "입사 6개월 차 직원도 연차를 쓸 수 있나요?"라는 질문을 받았다고 합시다.
이 질문에 답하기 위해 모델이 그냥 일반 상식을 꺼내면 위험합니다. 나라별 제도도 다르고, 회사 취업규칙도 다를 수 있기 때문입니다. 따라서 시스템은 먼저 인사 규정 문서에서 연차와 반차와 월차 관련 조항을 찾습니다. 필요하면 최신 개정본인지 확인하고, 수습 기간 예외나 계약직 예외 조항도 함께 찾아옵니다.
그다음 모델은 그 자료를 바탕으로 답합니다. 만약 규정에 "입사 후 1개월 개근 시 1일 부여"라고 적혀 있으면 그 문장을 근거로 설명할 수 있습니다. 반대로 규정이 애매하거나 예외 조건이 많다면, 단정하지 않고 "고용 형태에 따라 달라질 수 있으니 인사팀 확인이 필요하다"라고 안내해야 합니다.
이 예시에서 중요한 것은 모델이 똑똑하냐가 아닙니다. 올바른 규정 문서를 먼저 보게 했느냐입니다. 지식 설계가 답의 품질을 결정한 것입니다.
지식을 넣는 것만큼, 빼는 것도 중요하다
초보자는 늘 "무엇을 더 넣을까"를 고민하지만, 실무자는 자주 "무엇을 빼야 할까"를 고민합니다. 관련 없는 자료, 오래된 정책, 중복 문단, 서로 다른 버전의 문서가 함께 들어오면 시스템은 쉽게 흔들립니다.
그래서 좋은 지식 설계는 두 가지 일을 동시에 합니다. 필요한 정보를 넣고, 불필요한 정보를 뺍니다. 이 두 번째 작업이 생각보다 훨씬 중요합니다.
특히 조심해야 할 것은 오래된 정보입니다. 오래된 정책이 최신 정책보다 말이 더 자세하고 친절하면, 모델은 오히려 그 문서를 더 잘 참고할 수 있습니다. 그래서 문서 저장소에는 폐기, 보관, 최신본 표시 같은 관리 규칙이 있어야 합니다. AI 시스템은 정리되지 않은 문서 문화의 약점을 그대로 확대하기 때문입니다.
지식창고를 만들 때는 다음 질문을 꼭 던져야 합니다.
이 문서는 아직 유효한가
같은 주제의 최신 문서가 따로 있는가
이 문서는 누구를 위한 것인가
AI가 참고해도 되는 정보인가
이 질문에 답하지 못하면, 검색 성능 이전에 지식 품질부터 흔들리고 있을 가능성이 큽니다.
좋은 지식 설계는 질문의 종류에 따라 달라진다
모든 질문을 하나의 방식으로 처리하려 하면 금방 한계가 옵니다. 질문의 성격에 따라 필요한 지식도 달라지기 때문입니다.
정의형 질문은 설명 문서가 중요합니다. "우리 제품의 엔터프라이즈 플랜은 무엇이 다른가요?" 같은 질문이 그렇습니다.
조회형 질문은 데이터베이스가 중요합니다. "현재 재고가 몇 개인가요?" 같은 질문이 여기에 가깝습니다.
최신성 질문은 웹 검색이나 최신 피드가 중요합니다. "이번 주 업계 규제가 바뀌었나요?" 같은 질문이 그렇습니다.
판단형 질문은 여러 지식을 함께 봐야 합니다. "이 고객에게 예외 환불을 적용해도 되나요?" 같은 질문은 규정 문서, 고객 상태, 예외 승인 기준을 모두 확인해야 할 수 있습니다.
중요한 것은 질문 유형에 따라 지식 공급 경로를 다르게 설계하는 것입니다. 그래야 불필요한 검색을 줄이고, 정확도와 속도를 함께 챙길 수 있습니다.
결국 RAG는 '찾기' 기술이 아니라 '업무 이해' 기술이다
RAG를 기술 용어로만 바라보면, 자꾸 검색 엔진이나 벡터 데이터베이스 같은 도구 이야기로만 흘러갑니다. 물론 그런 요소도 중요합니다. 하지만 현장에서 더 본질적인 것은 따로 있습니다. 어떤 질문이 들어왔을 때, 답을 만들기 위해 어떤 지식을 어디서 가져와야 하는지 아는 감각입니다.
이 감각이 없으면 시스템은 겉보기에는 첨단이어도, 실제로는 엉뚱한 자료만 잔뜩 모아 옵니다. 반대로 이 감각이 있으면 복잡한 기술을 다 몰라도 꽤 실용적인 시스템을 만들 수 있습니다. 사내 FAQ를 잘 정리하고, 최신 문서만 남기고, 질문 유형에 따라 문서와 데이터베이스를 나눠 쓰게 하는 것만으로도 품질이 크게 오릅니다.
즉, RAG는 검색 라이브러리의 이름이 아니라 필요한 지식을 필요한 순간에 연결하는 운영 방식입니다.
실무에서 먼저 챙겨야 할 체크포인트
이 장을 마무리하며, 지식 설계를 시작할 때 가장 먼저 점검할 질문들을 정리해 보겠습니다.
이 AI는 답할 때 어떤 내부 지식을 꼭 봐야 하는가
최신성이 필요한 질문인가, 회사 내부 규정이 중요한 질문인가
문서로 풀 문제인가, 데이터 조회 문제인가
같은 주제의 오래된 문서가 섞여 있지는 않은가
찾은 자료를 근거와 함께 답하게 만들 수 있는가
근거가 없을 때는 모른다고 말하게 되어 있는가
이 체크포인트만 갖고 있어도 "프롬프트를 더 멋지게 쓰는 일"에서 한 단계 벗어나게 됩니다. 이제 우리는 AI에게 말을 잘 거는 사람이 아니라, AI가 무엇을 보고 말하게 할지 설계하는 사람에 더 가까워집니다.
좋은 답은 좋은 지식 경로에서 나온다
실무에서 AI의 품질은 종종 문장력보다 정보 공급 경로에서 갈립니다. 시스템은 친절한데 틀릴 수 있고, 문장은 매끄러운데 근거가 없을 수 있습니다. 이런 문제를 줄이는 가장 현실적인 방법은 모델을 맹신하지 않는 것입니다. 대신 필요한 지식을 준비하고, 적절한 저장소를 연결하고, 질문에 맞는 자료만 꺼내 보여 주는 구조를 만드는 것입니다.
이 장의 핵심은 단순합니다. AI가 아는 척하지 않게 하려면, 답변 전에 무엇을 보게 할지 설계해야 한다는 점입니다. 내부 지식과 외부 지식을 구분하고, 문서와 데이터베이스와 검색의 역할을 나누고, RAG를 통해 필요한 정보만 꺼내 붙이면 답은 훨씬 단단해집니다.
다음 장에서는 여기서 한 걸음 더 나아가, 지금까지 본 지식을 한 번 쓰고 버리는 대신 어떻게 기억으로 남길지 살펴보겠습니다. 어떤 정보는 매번 검색하면 되고, 어떤 정보는 계속 기억하게 해야 합니다. 바로 그 경계가 다음 설계의 핵심이 됩니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.