Eirene-v1의 개선된 버전인 Eirene-v3를 논문으로 공개하게 되었어요. 여기서는 이전에 설계한 멀티에이전트 구조를 어떻게 개선했는지, 그 과정에서 어떤 고민을 했는지 이야기해 보려해요.

프로젝트 목표 설정

말기 암 진단을 받은 임종기 환자분들은 연명의료를 받을지 결정해야 해요. 하지만 갑작스러운 말기암 진단으로 심리적으로 혼란스러운 상황에서 의료 지식을 이해하고 결정을 내리기란 매우 어려운 일이라고 해요. 의료진분들 역시 많은 업무로 인해 모든 환자분들께 충분한 시간을 쓰기 어렵고, 전문적인 의료 지식을 환자분들이 이해할 수 있는 언어로 설명하는 데 어려움을 겪고 있다고 하셨어요.

이런 맥락에서 저희는 말기암 환자분들을 돕기 위한 멀티에이전트 구조의 챗봇을 구현하게 되었어요. 초기에는 의료진, 연구진 등 다양한 이해관계자의 요구사항을 폭넓게 반영하다 보니 시스템 구조가 점점 복잡해졌어요. 리소스가 불필요하게 낭비되는 상황을 피하고 싶었기에, 논문에는 포함하지 않았지만 우선 ablation study를 통해 각 에이전트의 영향을 수치화했어요. 그리고 이 결과를 바탕으로 기여도가 높은 에이전트를 중심으로 우리가 풀고자 하는 문제가 정확히 무엇인지 다시 정의하는 시간을 가졌어요.

문제 재정의

의료 상담에서는 자연스럽고 유창한 답변을 생성하는 것뿐만 아니라, 그 답변이 안전한지 검증하는 단계가 매우 중요해요. 이 관점에서 보면, 의료 상담은 목적에 맞는 답변 생성과 안전 제약이 서로 상충할 수 있는 문제로 볼 수 있어요. 이는 강화학습에서 제약을 가진 최적화 문제를 푸는 연구 흐름과 유사하게 해석할 수 있었어요.

이런 관점을 바탕으로, 저희는 문제를 크게 3가지 목적과 4가지 제약으로 재정의했어요.

위와 같이 목적과 제약을 분리해 정의한 뒤, 목적을 달성하는 에이전트와 제약을 검증하는 에이전트를 구분했어요.

Counselor agent는 상담 단계에 맞는 답변을 생성하는 역할(o3)을 담당해요. 이를 위해 환자의 상태를 저장하는 메모리(o1)와 의료 정보를 검색하는 툴(o2)을 함께 사용해요. Escalation agent는 환자의 답변을 확인하고 고위험 신호를 탐지해, 인간의 개입이 필요한 상황인지 판단(c4)하는 역할을 맡고 있어요. Critic agent는 새로 도입한 에이전트로, Counselor agent가 생성한 답변이 적절한지 검증(c1, c2, c3)하는 기능을 담당해요.

이처럼 명확하게 목적과 제약을 정의하고 나니, 시스템 구조 상에서 덜 중요한 요소들을 과감히 삭제하거나 통합해 더 단순하고 효율적인 형태로 정리할 수 있었어요.

한계점과 차선책 찾기

구현한 챗봇을 평가하기 위해서는 전문가 평가와 사용자 평가를 모두 진행해야 해요. 이미 v1에서 전문가 평가를 진행했기에, 추가적인 검증을 위해 사용자 평가가 필요했어요. 그러나 말기 암 환자를 대상으로 한 챗봇 평가는 윤리적으로 매우 민감하고 어려운 문제예요. 여기에 더해, 말기 암 임종 의사 결정이라는 매우 특수한 상황 때문에 참고할 수 있는 공개 데이터셋이나 직접 비교 가능한 모델도 없었어요.

삼성서울병원 의료진분들께서 데이터 확보를 위해 IRB를 신청해 주셨지만, 당장 정량 평가를 수행할 만한 현실적인 방법은 없었어요. 그래서 저희 팀은 차선책으로 LLM을 이용하기로 했어요. 구체적으로는 LLM 시뮬레이션을 통해 합성 데이터를 생성하고, 또 다른 LLM 모델을 활용해 시스템 답변을 평가하는 방식을 선택했어요.

시뮬레이션 환경 구축

먼저 환자 역할을 수행하는 LLM을 이용해 합성 데이터를 생성했어요. 실제 한국 말기 암 환자의 특징을 최대한 반영하기 위해 의료진으로부터 환자의 페르소나와 상담 스크립트 예시를 전달받았어요. 이 정보를 프롬프트로 구성해 LLM이 환자 역할을 수행하도록 했고, 각기 다른 페르소나 10개를 json 파일로 정리해 다양한 대화 환경이 만들어지도록 했어요.

각 환자와의 상담은 설정된 상담 단계가 종료될 때까지 반복했고, 이 과정에서 약 10–20턴 사이의 대화가 생성되었어요. LLM 모델은 한국의 문화적 맥락을 반영할 수 있는 HyperCLOVAX를 사용했어요.

개발팀이 이 환경 위에서 다양한 실험을 수행할 수 있도록, 시뮬레이션 환경은 sdk 형태로 제공했어요. 실제 개발팀에서 사용한 인터페이스는 다음과 같아요.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 1. JSON 파일로부터 환자 정보 가져오기
patient_info = get_patient_info(patient_id=3)
patient = PatientLLM(
    persona=patient_info.persona, background_info=patient_info.background
)

# 2. Eirene 서버와 연결 시도
with EireneSession(user_id=patient_info.id) as eirene:
    for idx in trange(max_try):
        # 3. 환자 발화 생성
        patient_response = patient.invoke(doctor_message)
        if patient_response.err:
            tqdm.write(f"...{patient_response.err}")
        patient_message = patient_response.content

        # 4. Eirene 발화 생성
        eirene_response = eirene.invoke(patient_message)
        if eirene_response.err:
            tqdm.write(f"...{eirene_response.err}")
        doctor_message = eirene_response.content

환자와 Eirene의 발화는 모두 pydantic을 통해 검증되도록 설계했어요. 이를 통해 실험 내 모든 데이터가 의도한 대로 통제되고 있음을 보장해요. 또한 생성한 데이터를 안전하게 저장하기 위한 클래스도 함께 제공했어요. 이 클래스는 대화 내용을 csv 형식으로 일관되게 저장하도록 도와줘요.

덕분에 개발자는 데이터 형식 검증이나 파일 시스템 접근 같은 부수적인 작업에 시간을 쓰지 않고, 실험 설계와 분석에 더 집중할 수 있었어요.

LLM을 통한 답변 평가

다음으로 시스템의 답변 품질을 검증해야 했어요. v1에서는 하나의 대화 세션을 생성한 뒤, 의료진에게 해당 세션에 대한 평가를 요청했어요. 하지만 이번 실험에서는 서로 다른 10개의 페르소나로 10턴이 넘는 대화를 진행하고, 여기에 ablation case까지 포함하면 평가해야 하는 데이터 양이 훨씬 많아졌어요. 이런 규모를 모두 의료진에게 맡기기는 현실적으로 어려운 상황이었기에, LLM-as-a-judge 방식을 활용하기로 했어요.

동일한 모델을 생성과 평가에 모두 사용할 경우 preference leakage가 발생할 수 있기 때문에, LLM-judge로는 신뢰도가 높은 GPT-4를 사용해 평가를 진행했어요. 이 과정 역시 자동화 파이프라인을 구성해 빠르게 실험을 반복할 수 있도록 했어요.

1
2
3
4
5
6
7
8
9
10
11
judge = JudgeLLM()
evaluation_saver = EvaluationSaver(
    csv_path="...csv", check_point=5
)

for idx in trange(10):
    chat_history = ChatLoader("...csv")
    response = judge.invoke(chat_history)
    evaluation_saver.append(idx, response)

evaluation_saver.save()

개발팀 협업 경험

프로젝트를 안정적으로 운영하기 위해서는 팀원들이 같은 맥락을 공유하는 것이 중요하다고 생각해요. 본 프로젝트의 개발팀은 의료, AI, SW 등 다양한 백그라운드를 가진 인원으로 구성되어 있었어요. 이런 구성에서는 각자가 분리된 역할을 맡아 일하게 되는데, 그만큼 팀원 간 맥락이 공유되지 않으면 결과물을 취합하는 과정에서 문제가 생기기 쉬워요.

이 문제를 줄이기 위해 Github Issues를 적극적으로 사용하자고 제안했어요. 스크럼에서 나온 문제를 이슈로 등록하고, 관련 자료를 댓글 형태로 정리하면서 정보를 공유했어요. 이렇게 하니 모든 인원이 업무 맥락을 함께 이해할 수 있었고, 해야 할 일을 효율적으로 나누어 진행할 수 있었어요. 새로운 인원이 온보딩되어 실험에 참여하는 과정에서도 기존 이슈와 기록을 참고해 빠르게 적응할 수 있었어요.