Bayer PRINCE 사례, agentic RAG가 운영 시스템이 되려면 필요한 것

Martin Fowler 사이트에 실린 Bayer와 Thoughtworks의 PRINCE 사례는 agentic AI를 제품 환경에 넣을 때 무엇이 필요한지 구체적으로 보여준다. PRINCE는 제약 연구자가 수십 년치 preclinical safety study report를 찾고, 질문하고, 규제 문서 초안을 만드는 데 쓰는 cloud-hosted platform이다. 구조는 Agentic RAG와 Text-to-SQL을 결합한다.

읽을 만한 대목은 agent 개수나 workflow diagram이 아니다. 글은 context engineering과 harness engineering을 나눠 설명한다. 어떤 정보를 어떤 agent에게 어떤 형태로 넘길지 설계하는 일, 그리고 orchestration, recovery, observability를 모델 바깥에서 잡는 일이 별도의 engineering 과제라는 얘기다.

PRINCE는 clarify intent, think and plan, researcher agent, reflection agent, writer agent 같은 단계로 움직인다. Reflection agent는 검색 결과가 충분한지, 근거가 맞는지, 답변을 생성하기 전에 빠진 부분이 있는지 확인한다. 신뢰를 위해 transparency, explainability, human-in-the-loop도 전면에 둔다. 제약 도메인에서는 그 장치가 기능 설명보다 더 중요하다.

커뮤니티 논점은 꽤 실무적이었다. 한 댓글은 agent tuning보다 agent가 볼 수 있는 database와 데이터 정리가 훨씬 큰 비중을 차지한다고 짚었다. 다른 쪽은 loop가 있는 dynamic workflow가 투명성 요구와 충돌할 수 있다고 봤다. 이 사례가 주는 결론은 단순하다. 생산 환경의 agentic AI는 prompt보다 데이터, 평가, 복구 경로, 운영 관찰성이 먼저다.