1.RAG로 여러 유저가 쓰는게 아니라, 노드로 따로 둬서 에이전트마다 RAG를 쓰고 안쓰고 하는거임


이게 무슨뜻이냐


A 에이전트는 RAG로


B 에이전트는 RAG 없이 쓰는거임. 이렇게 하는 이유->RAG쓴 A 에이전트 코드를 리뷰하는 B 에이전트는 RAG를 쓸 이유가 없음 이때문에 캡쳐 방식 쓴거


랭그래프도 이방식임




24b0d121e09c28a8699fe8b115ef0464d789e0cb


랭그래프는 노드 함수는 state -> pasrtial update dict 형태로 값 반환하고 상태를 리듀서로 합함


이게 바로 전역 싱글톤 없이 구현한 나와 같은 방식임. DI방식 구현 ㅇㅇ


물론 내 코드보다 랭그래프가 훨씬 더 유연하지만. 그건 둘째치고 방식 원리는 랭그래프와 같음


오히려 여러 유저가 쓴다기보다 여러 에이전트가 RAG를 언제 참조해야하는가에 대한 거임


2.캡쳐방식이 오히려 훨씬 안전하고 싱글톤이 더 위험함. 우회하는게 아니라 그게 바로 Fast API가 권장하는 방식임. 


왜? FastAPI는 의존성 주입을 우선하는데, 그 주입할때 값이 중요함


3. 성능에 자꾸 집착하는데 성능은 빨라봤자 ns 단위임. 그런데 노드로 그래프 만들기가 함수형이 훨씬 편함


4. 상태의 I/O관리는 상태관리랑 다름. 상태에 들어가는 데이터의 순수성을 말하는거


4-1. appstate에서 전역변수 담는게 문제가 아니라, 싱글톤으로 쓰면 이 값에 보장이 안되기때문임 왜? 에이전트는 병렬임 


병렬 처리에서 싱글톤으로 한다는게 말이 안됨. 이게 오히려 심각함. 병렬 코딩에서 데이터 순수성을 보장하는 걸 함수형으로 하는게 맞음


4-2 의존성 실패는 다른거임. 예외처리 문제로


여기서 말하는 실패는 싱글톤 처리하다가 DB 주입 


나는 병렬처리를 위해서 하는거임. 


왜냐하면 


Fast API에서 애플리케이션 스코프 리소스는 lifespan 이벤트 핸들러에 덧대서 초기화하는게 맞음


지금보면 함수형에 팩토리와 레지스트리를 쓰는건데 이게 훨씬 나은거임


이 방식이 더 현대적인데 OOP가 무조건 맞는게 아님


병렬 처리를 위한 데이터의 경쟁 현상때문에 나중에 추가 확장성이 싱글톤이 뒤떨어짐