의료 LLM 해커톤 후기 : 제대로 움직이는 개발팀이 되기 위한 조건

지난 주말에 우리 동아리(MD Winners)와 서울대병원이 함께하는 의료 LLM 개발 해커톤에 참여하였다. 2월에 참여했던 의료 AR 해커톤(https://cascade.tistory.com/39 - 인생 첫 해커톤) 때는 제대로 개발을 할 줄도 모르는 상태에서 참여해서 기획 위주로 했었는데, 이번에는 개발 프로세스의 일부를 담당하게 되어 지난번보다 조금 더 "해커톤다운" 경험을 할 수 있었다.

---

 

서론으로 우리 동아리인 MD Winners  소개를 조금 하자면, 서울대 의과대학 소속 경제경영 동아리 (사실상 창업동아리!) 로, 의료 분야에서 다양한 혁신을 하고자 하는 친구들이 모여 있고, 다들 하나같이 열정이 넘친다. 의대 들어와서 가장 잘한 것 중 하나가 이 동아리에 들어온 것이라고 생각할 정도로 내가 생각하는 삶의 방향성과 잘 맞는 단체인 것 같다. 올해 운영진은 특히나 각자의 분야에서 내가 모두 리스펙할 정도로 멋진 일들을 하고 있는 친구들인데, 회의 결과 앞으로 반기마다 해커톤을 열어서 기술적인 역량을 높여 보자는 이야기가 나와 기획된 것이 이번 대회이다.

https://www.mdwinners.co.kr/

MD WINNERS

이 블로그에서 우리 동아리 소개는 처음 하는 것 같다.

---

Vision AI 쪽을 공부하고 있는 내가 어떻게 LLM 개발을 맡게 되었냐 하면, 대회 전에 어렵게 섭외한 AI Nation이라는 회사에서 두 번에 걸쳐 RAG와 AWS cloud 세션을 열어 주셨다. 그래서 전문가급은 아니지만 코드 보고 이해할 수준 정도가 된 상태에서 대회에 참여했다.

 

아래는 그냥 재미로 만들어본...

 

서론이 길었는데, 본격적으로 이번 해커톤에서 배운 점들을 이야기해보기로 한다.

 

우리 팀의 주제와 역할분담

우리 팀의 주제는, RAG를 활용해서 임상 가이드라인 DB를 만들고 이를 기반으로 대답하는 챗봇을 만드는 것이었다. 프론트엔드, 데이터 전처리, LLM 개발(백엔드), Evaluation tool 개발로 네 명이 개발에 참여했고,  이 중 나는 데이터 전처리를 맡았다. 임상 가이드라인은 PDF로 되어 있었기 때문에, 이를 Vector DB에 전달하는 것이 내 역할이었다.

 

PDF에서 text data는 pymupdf 등 각종 모듈들이 아주 잘 뽑아준다. 문제는 표나 그래프, 이미지 같은 것들인데, 이것을 어떻게 벡터로 임베딩할지가 전처리 과정에서 가장 challenging한 주제였다. 우리가 낸 아이디어는, 표나 그래프를 representation할 수 있도록 자연어로 바꾼 뒤에 일괄적으로 텍스트 임베딩을 하자는 것이었다.

실제로 pdf에 들어간 그래프 데이터 같은 경우, 현업에서 뛰고 계신 RAG 회사들도 꽤나 임베딩하기 까다로운 작업이라고 한다. 대체 OpenAI는 어떻게 하는 걸까 그래서 우리 팀은 위 다이어그램과 같이, 텍스트, 이미지, 표, 세 가지에 집중하였다. 표는 Camelot이라는 라이브러리를 이용해 추출한 뒤 DataFrame으로 바꾼 것을 다시 Plain text로 바꾸는 과정을 거쳤고, 이미지는 클로드 API에 태워서 text로 읽어달라고 하였다. (그러면 표도 그냥 클로드에게 읽어달라고 하면 되는 거 아닌가? 그 방법도 써 봤고 정확도도 꽤 높았지만, API를 쓰는 것은 비용과 시간을 감안했을 때 그리 효율적인 방법은 아니라고 판단했기에 최대한 줄이고자 했다). 그리고 텍스트로 각 데이터를 바꾸고, 메타에서 개발한 FAISS라는 텍스트 임베딩 프레임워크로 임베딩한 뒤 RAG의 Vector DB로 사용하였다.

 

좋은 개발팀의 역량은?

우리 팀이 겪었던 최대의 시행착오는, FAISS 임베딩으로 Vector DB를 만들 때, 전처리 측에서 백엔드 측으로 .index와 .faiss 두 가지 파일을 넘겨주어야 하는데, 나는 FAISS를 처음 써보는 상황이었기 때문에 코드를 짤 때 .index만 넘겨주어도 서칭을 할 수 있을 것으로 오해하였다. 즉 .faiss를 저장하지 않는 식으로 코드를 작성한 채로 밤새 코드를 돌려놓은 것이다. 따라서 우리가 계획한 대로 전처리된 벡터 임베딩을 제대로 완성하지 못한 채로 시연을 진행했다.

 

이런 시행착오로 가장 뼈저리게 느꼈던 것은, 개발팀의 팀원으로 업무를 잘 하기 위해 가장 중요한 것은 내 코드를 잘 짜는 능력이 아니라는 점이다. 협업을 해야 하는 상황에서 가장 중요한 것은, 내가 전체 프로세스에서 어떤 역할을 맡고 있는지를 명확하게 이해하는 것이라고 느꼈다. 어떤 형태의 데이터를 받고, 그것을 어떤 형태로 다음 프로세스에 넘겨야 할지를 명확히 숙지하고 작업에 들어가는 것이다. 이를 위해 전체 코드를 한 번에 독자적으로 완성하기보다는, 프로세스 전체가 제대로 굴러가는지 확인하기 위해 한두 개 정도의 테스트를 먼저 돌려보는 것이 좋겠다는 생각이 들었다. 

 

또한, 좋은 개발팀 리더가 되기 위한 두 가지 조건을 배웠다. 개발팀에 경험 많고 실력 있는 리더가 필요한 이유는, 미숙한 구성원들을 하나의 프로세스로 이어주는 연결고리를 잘 알고 있기 때문에 시행착오를 줄일 수 있으리라는 생각이 들었다. 따라서 좋은 개발팀의 리더는 경험이 많고 노련하여 시행착오를 잘 줄이는 사람이 되어야 한다고 생각했다. 둘째로, 프로젝트 구성원들은 프로젝트의 일부분을 보고 맡은 역할을 하는 것이 일반적이므로, 프로젝트 전체 방향성에 대해 구성원들끼리 동상이몽을 하고 있을 수 있다. 이때 리더의 역할은 전체 그림을 조감하면서, 구성원들에게 명확한 objective를 제시하는 것이라고 느꼈다. 그래야 구성원들이 각자의 역할에 집중하면서 올바른 방향성으로 움직일 수 있는 것 같다.