지식과 도구: Just-in-time으로 context를 조립한다

Q1 Analyze mcq_single

Upfront context dump와 just-in-time(JIT) retrieval을 토큰 비용·최신성·정확성 세 축에서 비교할 때, 가장 정확한 서술은?

A. A. Upfront는 매 호출마다 문서 전체를 동봉하므로 토큰 비용이 높지만, index가 호출 시점에 평가되어 최신성은 JIT보다 항상 우수하다. B. B. JIT는 쿼리당 top-k 조각만 넣어 토큰 비용 곡선이 완만하고, 호출 시점의 index를 따라가므로 최신성 측면에서도 upfront보다 유리한 경우가 많다. C. C. 두 방식은 토큰 비용에서만 차이가 있고, 최신성과 정확성은 근본적으로 동일하다. D. D. Upfront는 문서를 모두 넣기 때문에 긴 문서에서도 needle-in-a-haystack 문제에 강하고, JIT보다 정확도가 높다.

정답: B
노트에서 upfront는 매 호출마다 전체 문서를 지불하고 snapshot 시점에 고정되어 stale 위험이 있는 반면, JIT는 top-k만 지불하고 호출 시점 index를 따라 최신성을 유지하며, 관련 조각에만 집중해 신호 대 잡음비가 높다고 설명한다.
오답 해설:

A. 토큰 비용 설명은 맞지만 '최신성이 upfront가 항상 우수'라는 주장은 정반대. upfront가 snapshot에 고정되어 stale해진다.
C. 세 축 모두에서 차이가 난다는 것이 노트의 핵심 비교이므로 틀리다.
D. 긴 문서를 통째로 넣으면 오히려 needle-in-a-haystack과 context rot에 취약하다는 서술과 반대된다.

Q2 Understand true_false

문서가 1~2페이지로 작고 거의 바뀌지 않으며 매 쿼리가 사실상 전문을 필요로 한다면, upfront context dump가 여전히 타당한 선택일 수 있다.

참 (True) 거짓 (False)

정답: A
노트는 '작고·안정적·전문 필요'의 세 조건이 맞으면 upfront가 여전히 옳다고 명시한다. JIT가 만능이라는 오해를 교정하기 위한 문항이다.
오답 해설:

B. JIT가 항상 정답이라는 흔한 오개념. 노트는 upfront가 맞는 경계 조건을 분명히 둔다.

Q3 Apply mcq_multi

검색 tool 하나(`search_docs`)를 장착한 최소 JIT 에이전트를 설계할 때, 노트가 강조한 '설계 레버'와 '강제 규칙'에 해당하는 것을 모두 고르시오. (정답 2개)

A. A. `top_k`와 `max_tokens_per_chunk`로 한 번에 들어오는 노이즈의 양을 제한한다. B. B. tool 반환 스키마에 `doc_id`/`section`을 필수로 넣고 system prompt에서 citation을 강제한다. C. C. 검색 결과 대신 매 요청마다 전체 문서 코퍼스를 프롬프트에 함께 동봉해 정확도를 끌어올린다. D. D. 검색 tool을 호출하지 말고 모델의 파라미터 지식만으로 답하게 해 호출 지연을 줄인다. E. E. snippet 밖 사실을 자유롭게 창작해 답변을 매끄럽게 만들라고 system prompt에 지시한다.

정답: A, B
노트의 JIT 최소 구성은 '검색 tool 1개 + 반환 크기 제어(top_k, max_tokens_per_chunk) + citation 강제(doc_id 인용)'이다. A, B가 정확히 이 두 레버에 대응한다.
오답 해설:

C. 전체 동봉은 upfront로 되돌아가는 것으로, JIT 설계 레버가 아니다.
D. knowledge 채널을 닫아버리는 것으로, 근거 없는 답(헛소리) 위험을 키운다.
E. 노트가 'snippet 밖 사실은 만들지 마세요'로 금지한 바로 그 반대 지시다.

Q4 Apply short_answer

고객 지원 에이전트의 tool 목록을 받았다. `search_docs(query: str)` 하나만 장착한 JIT 에이전트에서, 모델이 snippet을 보고도 근거 없이 말을 지어내는 현상이 관찰된다. system prompt와 tool 반환 스키마에 각각 어떤 한 줄을 추가해야 이 현상이 줄어드는지 2가지를 쓰시오.

정답 예: (1) system prompt에 '모든 문장 뒤에 [doc_id]를 붙이고 snippet 밖 사실은 만들지 마세요' 같은 citation 강제 규칙을 추가한다. (2) tool 반환 스키마에 `doc_id`(또는 `section`) 필드를 필수로 포함시켜 citation을 실제로 쓸 수 있게 한다. 두 가지 모두가 맞물려야 JIT가 '검색했지만 근거 없는 답'을 막는다.채점 기준:

만점(2/2): system prompt의 citation/근거 강제 규칙 + 반환 스키마의 doc_id 필드 둘 다 언급.
부분(1/2): 둘 중 하나만 언급하거나, citation 대신 'snippet 밖 사실 금지'만 적음.
0점: top_k 조절·모델 교체 등 엉뚱한 해결책만 제시.

Q5 Evaluate mcq_single

한 에이전트에 아래 tool 두 개가 함께 등록되어 있다. - `get_data(query: str) -> dict` — "데이터를 가져옵니다." (raw JSON ~5KB 반환) - `search(q: str) -> dict` — "검색합니다." tool 인터페이스를 context로 간주해 진단할 때, 가장 핵심적인 문제로 보아야 하는 것은?

A. A. 두 tool 모두 동사가 지나치게 구체적이어서 모델이 적용 범위를 과도하게 좁게 해석한다. B. B. 이름이 모호하고(무엇을/왜 쓰는지 안 보임), 설명이 '언제 고르는가'를 담지 않으며, 둘의 역할이 중복되어 선택 경계가 사라졌다. C. C. 파라미터 타입(str)이 명시되어 있어 LLM이 자연어/SQL 여부를 혼동할 수 없다. D. D. 반환값이 JSON이어서 LLM이 파싱할 수 없고, XML로 바꾸는 것이 가장 시급하다.

정답: B
노트의 네 체크포인트(이름 구체성, 설명의 선택 기준, 파라미터 타입+설명, 반환 요약) 중 이 예시는 이름 모호 + 설명 동어반복 + 중복이 복합된 전형적 실패 사례다. '언제 고르는가'가 빠진 것이 핵심.
오답 해설:

A. 정반대 진단. 이름이 너무 일반적인 것이 문제이지 지나치게 구체적이지 않다.
C. `str` 타입만으로는 자연어/키워드/SQL 구분이 안 된다는 것이 노트의 지적이다.
D. 반환 포맷(JSON vs XML)이 아니라 반환 크기·요약 스키마가 문제의 본질이다.

Q6 Evaluate mcq_multi

고객 지원 에이전트에 `search`, `find`, `query_db`, `get_user`, `fetch_ticket` 5개 tool이 주어졌다. 노트의 원칙에 따라 개선안으로 적절한 것을 모두 고르시오. (정답 2개)

A. A. `search`와 `find`는 이름·역할이 중복되므로 하나로 합치거나 제거하고, 남는 tool의 description에 '언제 이걸 고르는가 / 언제 다른 tool을 쓰는가'의 경계 문장을 넣는다. B. B. 이름을 `search_knowledge_base_by_keyword`, `lookup_user_by_id`, `lookup_ticket_by_id`처럼 동사+대상+기준으로 구체화한다. C. C. 선택 품질을 높이기 위해 동일 기능 tool을 이름만 바꿔 10개 이상으로 늘려 선택지를 풍부하게 만든다. D. D. 각 tool description을 한 문단 이상으로 크게 늘려 가능한 모든 사용 사례를 나열한다. E. E. 모든 tool의 반환을 raw JSON 5KB 덩어리로 통일해 일관성을 확보한다.

정답: A, B
노트는 (1) 중복 tool 제거 + 선택 경계 문장, (2) 동사+대상으로 이름 구체화, (3) 최소 tool 집합, (4) 반환 요약 스키마를 원칙으로 제시한다. A·B가 정확히 이 두 원칙을 따른다.
오답 해설:

C. tool 수가 늘수록 선택 품질이 가파르게 떨어진다는 '최소 집합 원칙'의 정반대다.
D. '설명에 모든 걸 다 쓰면 되지 않을까?'라는 흔한 오해를 그대로 반영한 잘못된 방향. 짧고 선택 기준 중심으로 써야 한다.
E. raw JSON 덩어리 반환은 context rot의 씨앗이라고 명시되어 있다.

Q7 Apply mcq_single

상품 카탈로그 검색과 주문 상태 조회를 모두 담당하는 에이전트를 설계하고 있다. 노트의 'Before/After' 원칙을 따라 가장 잘 쓰인 tool description 한 쌍은?

A. A. `search_product_catalog`: "상품명으로 상품을 검색할 때만 사용하세요. 주문 조회는 lookup_order_by_id를 쓰세요." / `lookup_order_by_id`: "주문 ID로 단일 주문의 현재 상태를 조회합니다." B. B. `get_data`: "데이터를 가져옵니다." / `get_data2`: "다른 데이터를 가져옵니다." C. C. `do_everything`: "상품, 주문, 사용자, 티켓, 로그 등 필요한 모든 조회와 변경을 수행합니다." (단일 tool로 통합) D. D. `search`: "자유롭게 검색하세요. 파라미터는 아무 문자열이나 됩니다." / `search_v2`: "v2 버전의 검색입니다."

정답: A
A는 이름(동사+대상 구체), 설명(언제 고르는가 + 경계 문장), 책임 분리가 모두 충족된 정답 예시. 노트의 after 코드 예시와 정확히 일치한다.
오답 해설:

B. 이름 모호 + 설명 동어반복 + 중복 — 노트가 나쁜 예로 든 before 유형 그대로.
C. 'do_everything'류 거대 tool은 선택 기준이 사라져 오히려 실패율이 올라간다.
D. 'v2' 같은 의미 없는 버전 접미사와 모호한 파라미터 설명은 LLM의 선택 경계를 지운다.

Q8 Understand mcq_single

다음 중 S2 전체(JIT retrieval + tool as context)를 관통하는 핵심 관점을 가장 정확히 요약한 것은?

A. A. 가능한 한 많은 문서와 tool을 프롬프트에 미리 넣어 모델이 스스로 최적 경로를 찾게 하는 것이 context engineering의 목표다. B. B. 검색 tool은 곧 knowledge 채널이며, tool의 이름·설명·반환 자체가 LLM에게 instruction이다. 따라서 '무엇을 언제 가져오느냐'와 '무엇으로 가져오느냐'를 함께 설계해야 한다. C. C. retrieval 품질은 전적으로 임베딩 모델 성능에 달려 있으므로, tool 설계는 부수적 문제다. D. D. tool은 구현 코드만 잘 쓰면 되고, 설명과 이름은 LLM 성능에 거의 영향을 주지 않는다.

정답: B
S2.C1이 '무엇을 언제 가져올 것인가(JIT)'를 다루고, S2.C2가 '그 도구 자체의 설계(tool as context)'를 다룬다. 두 class가 합쳐져 knowledge 채널 설계의 전체 관점을 만든다.
오답 해설:

A. upfront 만능주의와 과잉 tool 노출을 동시에 긍정하는 입장으로, S2·S4가 명시적으로 경고하는 anti-pattern이다.
C. 임베딩 성능은 한 변수일 뿐, tool 인터페이스 설계가 선택 품질을 좌우한다는 것이 S2.C2의 핵심 주장이다.
D. 에이전트는 구현 코드를 보지 않고 이름·설명·스키마·반환만 읽는다는 서술과 정반대.