🤖
1309 in / 6000 out / 7309 total tokens
제조 현장과 의료 문서 처리, 전혀 다른 도메인처럼 보이지만 두 이야기의 공통분모는 'RAG + 에이전트' 아키텍처다. 복잡한 도메인에서 LLM이 hallucination을 줄이고 실제 업무에 투입되려면 결국 이 구조로 수렴한다.
🔥 핫 토픽
MachinaCheck: AMD MI300X에서 돌아가는 멀티에이전트 CNC 제조 가능성 검수 시스템
CNC(Computer Numerical Control) 가공은 설계도면을 실제 기계가 깎아낼 수 있는지 검증하는 과정이 필수다. 기존에는 숙련된 엔지니어가 CAD 파일을 열고 하나하나 체크했는데, 이걸 멀티에이전트 시스템으로 자동화한 프로젝트다. AMD MI300X — AMD의 데이터센터급 APU — 위에서 구동된다는 점이 흥미롭다. NVIDIA 생태계가 아니어도 충분히 프로덕션급 AI 추론이 가능하다는 실증 사례다.
시스템 구조를 보면 에이전트가 역할별로 나뉘어 있다. CAD 파일 파싱 에이전트, 형상 분석 에이전트, 공정 제약 검증 에이전트 등이 각자의 서브태스크를 처리하고 결과를 종합해서 최종 manufacturability report를 생성한다. 게임 서버 아키텍처로 치면 각 시스템이 독립적으로 틱을 돌리면서 이벤트를 주고받는 ECS(Entity Component System) 패턴과 비슷한 느낌이다. 느슨하게 결합되어 있어서 하나의 에이전트가 실패해도 전체가 죽지 않는다.
개발자 관점에서 주목할 점은 이런 멀티에이전트 구조가 점점 산업 표준이 되어간다는 거다. 단일 LLM에 프롬프트 하나 던져서 해결하던 시대는 지나갔다. 각 에이전트가 담당 도메인 지식을 갖고, 툴을 호출하고, 결과를 검증하는 파이프라인을 구성하는 게 이제는 기본기다. 게임 개발에서도 NPC AI를 단일 상태머신에서 행동 트리(Behavior Tree)로 넘어갔던 변화와 비슷한 맥락이다. 복잡성을 다루는 유일한 방법은 관심사의 분리다.
AMD MI300X 선택도 의미심장하다. CUDA 의존도를 낮추려는 움직임이 해커톤 레벨에서도 보이기 시작했다. HuggingFace + AMD 조합은 ROCm 성숙도가 올라가면서 실현 가능해졌고, 앞으로 AMD 가속기에서 돌아가는 프로덕션 시스템이 더 많이 나올 것이다. 인프라 선택지가 넓어진 건 개발자에게 반가운 소식이다.
출처: HuggingFace Blog
⭐ 오픈소스
MediQuery: RAG 기반 의료 문서 Q&A 봇
의료 문서에 특화된 RAG(Retrieval-Augmented Generation) 시스템이다. FastAPI 백엔드 + Streamlit 프론트엔드 + ChromaDB 벡터스토어 + LangChain 오케스트레이션 + 다중 LLM 지원(Gemini 등) 스택으로 구성되어 있다. 스택 구성을 보면 2024년 중순 RAG 프로젝트의 교과서적인 아키텍처를 그대로 담고 있다.
이 프로젝트의 가치는 '어떤 기술을 썼는가'보다 '어떤 도메인에 적용했는가'에 있다. 의료 문서는 일반 텍스트와 다르다. 임상 시험 보고서, 약물 상호작용 정보, 진단 가이드라인 등은 오답이 사람의 건강에 직결된다. 그래서 일반 RAG보다 검색 정확도와 답변 검증이 훨씬 중요하다. 이 프로젝트가 Multi-LLM을 지원하는 이유도 아마 모델별로 답변을 교차 검증하거나, 도메인 특화 모델을 선택적으로 사용하기 위함일 것이다.
FastAPI 선택이 마음에 든다. 게임 서버 개발자로서 비동기 처리와 타입 힌트가 기본인 프레임워크는 신뢰가 간다. Streamlit은 프로토타입용으로는 훌륭하지만 프로덕션에서는 React 같은 걸로 갈아타야 할 것이다. ChromaDB는 경량 벡터DB라 로컬 개발에 편하지만, 규모가 커지면 Qdrant나 Milvus로 마이그레이션해야 한다. 이건 이 프로젝트만의 문제가 아니라 거의 모든 RAG 프로젝트가 겪는 성장통이다.
앞서 다룬 MachinaCheck와 연결되는 지점이 있다. 두 프로젝트 모두 '특정 도메인의 문서/데이터를 LLM이 이해할 수 있게 구조화하고, 정확한 답변을 끌어내는' 게 핵심이다. 제조 도메인이든 의료 도메인이든, RAG는 hallucination을 제어하고 실제 업무에 AI를 투입하는 가장 현실적인 방법이다. 다만 의료 쪽이 훨씬 더 엄격한 검증이 필요하고, 규제 컴플라이언스(HIPAA, GDPR 등)가 추가로 붙는다. 이 프로젝트가 실 서비스되려면 이 부분을 어떻게 처리할지가 관건이다.
출처: GitHub - anujpratap12/MediQuery
🔗 두 이야기를 묶어서
MachinaCheck가 멀티에이전트로 복잡한 제조 검수를 자동화했다면, MediQuery는 RAG로 복잡한 의료 문서 검색을 자동화했다. 방법론은 다르지만 둘 다 '전문가의 반복적 판단 작업'을 AI로 보강하려는 시도다.
멀티에이전트는 복잡한 워크플로우를 분해하는 데 유리하고, RAG는 대규모 문서에서 정확한 정보를 검색하는 데 유리하다. 실제 프로덕션에서는 둘이 섞이는 경우가 많다. MediQuery도 에이전트 레이어를 추가하면 '약물 상호작용을 확인하고, 환자 이력을 조회하고, 가이드라인을 교차 검증하는' 멀티스텝 추론이 가능해질 것이다. MachinaCheck도 내부적으로 RAG를 써서 과거 검수 이력이나 기계 사양 매뉴얼을 참조할 수 있을 것이다.
도메인 특화 AI의 경쟁력은 모델 자체보다 '얼마나 정확하게 검색하고, 얼마나 견고하게 검증하느냐'에 달려 있다. RAG와 에이전트는 그 두 축을 담당한다.