매니저가 Langraph 대신 Autogen을 고집하네요

Autogen은 죽었습니다. Microsoft Agent Framework에 흡수되면서 Autogen의 잔재, Semantic Kernel, 그리고 Langchain 워크플로우 짝퉁들만 남았죠. 만약 보스가 이 사실을 모른다면, 그 사람은 기술적 의사결정을 할 자격이 전혀 없는 겁니다.

Langchain/Langraph를 사용해 여러 앱을 프로덕션에 배포해 봤습니다. 대부분은 꽤 괜찮았지만, 현재 사용자 기반이 꽤 큰 프로젝트에서는 경험이 별로 좋지 않았습니다. 실제로 일관성 있게 작동하고 오류를 스스로 복구하는 앱을 원하게 되자 문제가 생기기 시작했죠. 결국 Langchain의 작은 기능들을 우리가 원하는 대로 작동하게 하려고 계속 덮어쓰기(override)를 해야 했습니다. 예를 들어 우리만의 LLM 클래스를 구현한다거나...

윈도우 서버 쪽에서 10년 일하면서 재앙 같은 상황들을 직접 많이 봐왔음. 대부분의 팀은 풀 프레임워크가 제공하는 기능의 10% 정도만 필요로 하는데, 그건 한 달이면 코드 생성으로 충분히 만들 수 있고, 나중에 요구사항 바뀔 때 수정하기도 훨씬 편함. 사실 대부분의 소프트웨어는 그냥 비즈니스 프로세스 자동화하는 거라, 프롬프트 몇 개랑 도구 호출하는 결정론적인 흐름만 있으면 됨. 문제는 대부분의 프레임워크가 데모 빨리 만드는 데만 최적화되어 있어서 이것저것 다 때려 박아놓는다는 거지.

에이전트 배포는 어떻게 했음? 랭스미스(Langsmith) 썼음, 아니면 FastAPI로 래퍼 만들어서 썼음? 그리고 백엔드 API랑 연동해서 끊김 없이 스트리밍하려고 프론트엔드에 어떤 라이브러리 썼는지 궁금함.

Autogen은 쓰지 마세요. 최근 Gemini 3 시리즈 모델 문제 때문에 Autogen에서 Langchain으로 마이그레이션했습니다. Gemini 3 모델은 도구 호출을 할 때 암호화된 사고 서명(encrypted thought signatures)을 다시 보내야 하는데, Autogen은 그걸 처리하지 못해서 LLM 호출이 실패하거든요. 게다가 마이크로소프트는 Autogen을 사실상 포기했고, 최근 업데이트도 전혀 없습니다.