1. 왜 Retriever로 감싸서 쓸까?

출처: 원본 PDF 11차시_Retriever기초실습.pdf 3~4쪽 · 쪽 그림 3쪽 4쪽

10차시까지 우리는 store.similarity_search를 직접 불렀습니다. 동작은 잘 했는데, 왜 굳이한 겹을 더 씌우라는 걸까요?

1-1) 직접 호출의 문제

⚠️ store를 직접 부르면 생기는 일
① 저장소를 바꾸면 코드를 다 고쳐야 합니다
FAISS → Chroma로 바꾸면?
similarity_search를 부른 모든 곳을 확인해야 합니다
② 검색 방식마다 함수 이름이 다릅니다
similarity_search / max_marginal_relevance_search /
similarity_search_with_relevance_scores ...
방식을 바꿀 때마다 호출부를 수정해야 합니다
③ 옵션이 코드 곳곳에 흩어집니다
k=3이 여기저기 하드코딩되어 있으면
튜닝할 때 다 찾아다녀야 합니다
④ 체인·그래프에 끼워 넣기 번거롭습니다
17차시 이후 LangGraph에서 특히 문제가 됩니다

1-2) Retriever의 해결책

🔌 표준 콘센트 비유
집안 가전은 종류가 다 다릅니다.
냉장고, TV, 청소기...
하지만 플러그 모양은 다 똑같습니다.
그래서 어느 콘센트에나 꽂힙니다.
Retriever가 그 표준 플러그입니다.
FAISS든, Chroma든, 웹 검색이든
retriever.invoke(질문) 하나로 통일됩니다.
안에서 무엇이 돌아가든 부르는 쪽은 몰라도 됩니다.

■ 직접 호출 (저장소에 종속)
store.similarity_search(q, k=3)
store.max_marginal_relevance_search(q, k=3, fetch_k=10)
    ↑ 방식 바꿀 때마다 호출부 수정

■ Retriever 사용 (호출은 항상 동일)
retriever = store.as_retriever(
    search_type="mmr",
    search_kwargs={"k": 3, "fetch_k": 10})

retriever.invoke(q)      ← 방식을 바꿔도 이 줄은 그대로