첫째로,

이거 RAG고 FastAPI서버 쓴 거 보면 다수에게 내보내는 서비스를 염두에 둔 건데

캡쳐 방식으로는 여러 유저가 쓸 수 있도록 하기가 매우 어려움

현재 구조로는 아예 불가능함 (클린업 추가해도 불가능)

글고 오래 써도 망가지게 되어잇음.

둘째로,

캡쳐 방식으로는 사용 도중에 변경 시 문제가 많이 발생됨

즉 정적인 사용을 가정하고 개발됨

지원해주는 걸 안쓰고 우회했으니까 이런 약점이 있는 건 당연하다

셋째로,

노드별로 다른 인스턴스를 쓰게 하고 싶다던지

유저의 config에 맞춰서 별개의 그래프를 빌드하고 싶었다면

팩토리 패턴에 레지스트리를 쓰면 쉽고 간단히 될 일임.

코드 보니까 교과서적으로 잘 쓴 부분도 있던데 왜 이렇게 하는지 이해가 안됨.

이렇게 하는 게 기능 덧붙이기 쉬워서 그렇게 했다는 것 같은데

코드도 길어지고 성능도 느린데 어떻게 기능 덧붙이기가 더 쉬워짐?

넷째로,

개념에서 좀 헷갈리는 부분들이 있는 것 같은데

1. 상태의 I/O관리

상태관리를 잘못말하고 있는 것 같음

상태에는 입출력이 없고 그냥 변경만 있지.

글고 네가 만든 함수형 캡쳐도 결국 싱글톤임. 근데 얘만 상태관리가 편하다는 게 무슨 뜻이야?

2. app.state

이건 패턴이 아니라 걍 저장소임.

보통 여기다가 전역 변수 같은 거 담음. 앱이 죽을 때 같이 정리되라고

3. 의존성 실패

아마 의존성 주입 실패를 말하는 것 같은데 주입 과정에서 뭔가 실패가 발생하면

FastAPI가 서버 잘못이라고 500 에러 보내고

UI는 그걸 받아서 유저에게 알리거나

아니면 서버 쪽에서 보내준 풀백을 받아서 계속 처리를 이어나가면 되는데

UI가 왜 치명적으로 멈춘다는 거임?

글고 애초에 서버 쪽에서 의존성 주입 실패라는 상황이 발생했는데

유저가 어떻게 그걸 모르고 그냥 쓸 수 있음? 멋대로 풀백되거나 반응 안하는 거 보고 짜증이 날 수는 있겠지

근데 그냥 모를 순 없지

글고 마지막으로,

제일 밑에 이견은 없다. 내 말이 맞다고 써놨던데

네가 연구원이면 그럴 수 있음

사실 코딩스타일부터가 딱 연구자 스타일이긴 함

나도 연구원으로 시작했기 때문에 어떤 건지 잘 안다

대부분의 연구원들이

한 번이라도 돌아가면 성공 <-- 이런 식으로 개발하지

근데 실제로 서비스 개발하려면 그렇게 하면 안됨

100번 돌려봤는데 95번 잘 돌아간 기계면 정상적인 기계냐? 고장난 기계잖음

이런 식으로는 연구 이외의 의뢰는 수행 못함

자주 고장나는 제품은 누구도 좋아하지 않아

타로에 RAG붙여보면 뭔 소린지 바로 느낄 거임

안 고장나고 계속 돌아가는 게 그 무엇보다 중요하다

왜냐면 개발자 본인의 시간이 무엇보다 큰 비용이기 때문

자칫하면 개발자가 아니라 콜센터 직원이 되어버리는 수가 있음