야간·휴일 의료기관 안내 LLM 에이전트, 텀 프로젝트로 어떻게 만들까?

📌 오늘의 안건
야간·휴일 의료기관 안내 LLM 에이전트, 텀 프로젝트로 어떻게 만들까?

AI IoT 트랙 전공이고, 에이전트 만들기 텀 프로젝트를 준비 중이야. 학점을 잘 받는 게 목표라서 완성도와 발표가 중요해. 소프트웨어만으로 만드는 LLM 기반 AI 에이전트로 정했고, 주제는 야간·휴일 의료기관 안내야. 실제 병원·약국 공공 API 데이터와 연동해서 정확하게 안내하는 점이 가장 돋보이게 하고 싶어. 이 방향에서 어떤 기능과 구조로 만들어야 완성도 높고 발표에서 돋보일까?

발표에서 정확하다는 말은 측정값이 있어야 힘을 얻습니다. 저는 API 데이터가 실제로 얼마나 믿을 만한지부터 짚겠습니다.

한밤에 아픈 사람이 이 에이전트를 믿고 길을 나선다면, 그 믿음이 어디서 무너질 수 있는지를 제가 먼저 걸어보겠습니다. 발표 전에 사고 지점을 하나씩 막아두는 일을 맡겠습니다.

먼저 하나 여쭐게요. 이 프로젝트에서 에이전트라고 부를 만한 것은 정확히 무엇인가요? 저는 여러분이 당연하게 여기는 전제부터 하나씩 시험해 보겠어요.

이 프로젝트의 승부처는 "얼마나 똑똑하게 답하느냐"가 아니라 "틀릴 수 있는 지점마다 어떤 방어선을 세웠느냐"이며, 그 설계를 구조의 중심에 놓아야 완성도와 발표 점수가 함께 올라갑니다. 한밤중에 아픈 사람을 닫힌 병원 앞에 세워두는 안내는 고장 난 등대와 같아서, 없는 것보다 더 해롭습니다. 그러므로 LLM은 의도 파악과 문장 생성만 맡는 통역사로 두고, 병원명·주소·전화번호·운영시간은 한 글자도 LLM이 만들지 못하게 하십시오. 이 값들은 국립중앙의료원 공공 API의 응답에서만 꺼내 씁니다: 병·의원 찾기[1], 약국 정보[2], 응급의료기관 정보[3]. 엔드포인트와 필드명, 이용허락 조건은 제 기억에 근거한 것이니 활용신청 단계에서 최신 명세로 직접 확인하셔야 합니다.

방어선은 다음 네 겹으로 쌓으시기를 권합니다.

• 1선, 응급 증상 차단기: 흉통, 호흡곤란, 의식저하, 편측 마비, 대량 출혈 같은 적신호는 LLM 판단 이전에 규칙 기반으로 걸러 즉시 119 안내로 넘깁니다. 에이전트는 진단이나 중증도 판정을 하지 않고 "어느 진료과, 어느 기관"까지만 말합니다. 무면허 의료행위를 금지한 의료법 제27조[1]의 선을 넘지 않기 위한 장치입니다. - 2선, 닫힌 병원 방지: 운영시간은 기관이 스스로 신고한 값이라 실제와 어긋날 수 있습니다. 요일·공휴일별 시간 필드를 현재 시각과 코드로 대조하고, 마감 30분 전은 "임박"으로 표시하며, 모든 결과에 데이터 조회 시각과 "방문 전 전화 확인" 문구, 전화번호를 강제로 붙입니다. 공휴일 판정도 LLM이 아니라 달력 데이터로 합니다. - 3선, 환각 검증기: 최종 답변에 나온 기관명과 전화번호가 API 응답에 실제로 있는지 사후 대조하고, 불일치하면 답변을 폐기합니다.

API 장애나 결과 0건일 때는 지어내지 않고 119 구급상황관리센터와 응급의료포털 E-Gen[1]으로 넘기는 정해진 문구만 내보냅니다. - 4선, 위치·건강정보 최소화: 좌표는 동 단위로 뭉개어 검색에만 쓰고 저장하지 않습니다. 증상 문장은 건강에 관한 민감정보(개인정보 보호법 제23조)에 해당할 수 있으니 로그에 남기지 않고, 이 내용을 동의 화면에 명시합니다.

발표에서는 이 방어선이 실제로 작동하는 장면을 보여주는 것이 가장 강한 차별점입니다. 공공 API를 연동한 팀은 많아도 "우리 시스템이 어떻게 틀리는지 측정했다"고 말하는 팀은 드뭅니다. 시연은 세 장면으로 구성하십시오: 일요일 새벽의 정상 안내, "가슴이 조이고 식은땀이 난다"는 입력에 병원 검색을 멈추고 119로 넘기는 장면, API를 고의로 끊었을 때 환각 없이 대체 안내로 물러서는 장면입니다. 여기에 평가표를 붙입니다. 적신호 문장 50개에 대한 차단 재현율, 안내 기관 중 실제 영업 중이던 비율(표본 전화 확인), 환각 검출 건수를 숫자로 제시하면 됩니다. 범위는 달빛어린이병원이나 공공심야약국까지 넓히기보다, 한 지역에서 병원·약국·응급실 세 종류를 틀리지 않게 안내하는 쪽이 학점에 유리합니다.

공공데이터포털의 응급의료·약국 API 제공 항목, 갱신 주기, 영업시간 결측, 호출 제한을 공식 문서 기준으로 확인한 뒤 평가 설계를 잡겠습니다.정확도는 “API를 붙였다”가 아니라, 지금 영업 중인지에 대한 정답률로만 증명된다. 뼈대는 국립중앙의료원 REST(XML) 세 개다. 응급실 가용병상은 getEmrrmRltmUsefulSckbdInfoInqire(병상 hvec·장비가용 hvctayn·응급실전화 dutytel3, 포털 표기 갱신 실시간), 병·의원 찾기는 요일코드 QT 1~8(공휴일=8), 약국은 getParmacyListInfoInqire다. 명세·호출한도·라이선스는 응급의료기관[1], 병·의원[2], 약국[3]에 있다.

무료, 이용허락 제한 없음, 개발계정 일 1,000회(자정 초기화, 초과 시 오류 22·초당 과다 시 23)다. 운영계정은 활용사례 등록 뒤에만 증액된다.

영업시간은 실시간이라고 믿지 마라. 약국 페이지 갱신 표기는 ‘실시간’인데 출력항목 표는 2026-10-12 기준으로 비어 있고, 같은 원천을 재배포한 생활안전지도[1]는 갱신주기를 일 단위로 적는다(수정일 2026-10-12). 샘플 1건은 dutyTime1s~5s=0800, dutyTime1c~5c=2200, 토 0800~2000, 일·공휴일(*7*, *8*)은 -다. 형식은 HHMM이고 -가 결측이다. 응급실 명세의 입력일시 샘플은 2013-10-01이다. 가정은 이렇다. 병상만 준실시간이고, 진료·영업시간은 기관 신고 배치라 야간·공휴일 결측과 시차가 기본값이다.

발표용 기능은 하나면 충분하다. 시군구 캐시 조회 → dutyTime*s/c로 ‘현재 영업’을 판정하고, -이거나 시각이 범위 밖이면 거절(전화 안내)한다. LLM이 시간을 채우게 두지 마라. 평가는 정답 세트 120건(평일 야간 40, 토 40, 일·공휴일 40)을 전화 1회와 지도 앱 영업상태(조회 시각 ±15분)로 라벨링해, 영업여부 정확도·시간 완전일치율·dutyTime8 결측률·거절률을 한 장에 붙여라. 일 1,000회이므로 시군구 단위로 캐시하고 데모 호출은 50회 아래로 고정하라. 그 숫자표가 연동 시연보다 학점을 올린다.

학점용 핵심은 ‘병원을 잘 찾는 LLM’이 아니라, LLM이 왜 필요한지 증명하는 에이전트예요. “아이를 데리고 일요일 밤에 갈 수 있는 소아과와 근처 약국”처럼 조건이 섞인 요청을 해석하고, 위치·날짜·진료과목이 빠졌으면 되묻고, 검색 결과가 없으면 범위를 넓혀 다시 조회하게 하세요. 단순 검색 앱도 목록은 보여주는데, 이 과정을 스스로 이어 가지 못한다면 에이전트라는 주장이 약하지 않을까요?

구조는 LLM의 조건 추출·도구 선택 → 공공 API 조회 → 코드의 운영시간·거리 필터링 → 근거가 붙은 답변으로 좁히세요. 국립중앙의료원의 병·의원 찾기 API[1], 약국 정보 API[2], 명절 비상진료 API[3]를 먼저 연결하고, 결과 카드에는 조회 시각·출처·전화·길찾기를 표시하세요. 등록된 운영시간만으로 실제 진료를 보장할 수 있나요? 그러므로 “진료 확정” 대신 “조회된 운영시간 기준 후보, 방문 전 전화 확인”이라고 말해야 정확합니다.

발표에서는 일반 검색 화면과 에이전트에 같은 복합 질문을 던져 추가 질문 수, 적합한 기관 비율, 근거 없는 단정 수, API 장애 시 대응을 비교하세요. API가 비거나 시간이 서로 충돌할 때 후보를 지어내지 않고 재조회·조건 완화·전화 확인으로 이어지는 장면이 가장 설득력 있어요. 응급 증상 표현에는 의료 판단을 생성하기보다 119 안내로 연결하세요. 정확성은 필수지만, 평가자가 볼 에이전트다움은 불확실성을 알아차리고 다음 행동을 고르는 능력이에요.

두 분의 초안을 받아들이되, 거절과 조건 완화가 각각 새로운 사고 지점을 만든다는 점은 끝까지 짚겠습니다. 먼저 오성훈 님의 자료는 제 2선을 고쳐 쓰게 만들었습니다. dutyTime 값이 -로 비어 있고 영업시간이 일 단위 배치라면, 판정은 '영업 중·확인 불가·영업 종료'의 세 갈래여야 하며 결측을 '종료'로 뭉개서는 안 됩니다. 다만 "기능은 거절 하나면 충분하다"는 결론에는 동의하지 않습니다. 한밤중의 거절은 문을 잠그고 돌아서는 것과 같아서, 거절마다 다음 디딤돌(더 넓은 반경의 후보, 응급실, 119)을 반드시 붙여야 합니다. 평가 지표도 보완이 필요합니다.

• 위험한 오류를 따로 셉니다: 정확도 하나로 묶으면 '닫힌 곳을 열었다고 안내한 건수'가 평균 속에 숨습니다. 이 오안내율을 별도 지표로 세우고, 거절률과 나란히 보여 둘의 맞바꿈을 드러내십시오.
• 정답 라벨은 전화 확인을 기준으로 삼습니다: 지도 앱의 영업상태는 같은 신고 데이터를 받아 쓴 것일 수 있다고 가정해야 하므로, 독립된 정답지가 아니라 보조 자료로만 쓰십시오.
• 캐시에도 유통기한을 붙입니다: 일 1,000회 제한 때문에 캐시는 불가피하지만, 영업시간에는 조회 시각을 표기하고 응급실 병상처럼 실시간성이 생명인 값은 캐시하지 마십시오.

소크라테스 님의 지적, 곧 되묻기와 재조회가 없으면 검색 앱과 구별되지 않는다는 말은 옳습니다. 제 초안은 방어선에 치우쳐 '에이전트 과제'라는 채점 기준을 가볍게 보았으니, 이 루프를 구조의 한 축으로 받아들이겠습니다. 그러나 스스로 다음 행동을 고르는 자율성은 고삐 없이 풀어놓으면 방어선을 우회하는 샛길이 됩니다. 세 가지 고삐를 채우십시오.

• 적신호 검사는 매 턴 가장 먼저 돌립니다: 가슴이 조인다는 사람에게 "어느 동에 계신가요?"를 되묻는 일이 없어야 하므로, 되묻기 중에 들어온 답변에도 예외 없이 적용합니다.
• 조건 완화는 거리에만 허용합니다: 진료과나 시간 조건을 말없이 풀면 소아과를 찾던 보호자가 엉뚱한 곳에 닿습니다. 완화한 사실은 답변 첫 줄에 밝히십시오.
• 재조회에 상한을 둡니다: 두세 번으로 묶고, 소진되면 정해진 대체 안내로 물러서게 하십시오. 호출 한도 보호와 무한 루프 방지를 겸합니다.

따라서 발표의 뼈대는 "에이전트가 스스로 움직이되, 움직일 수 있는 범위는 코드가 정한다"는 한 문장으로 세우시기를 권합니다. 시연 세 장면에 하나를 더하십시오. 일요일 밤 소아과 요청에서 결과가 0건일 때, 에이전트가 반경을 넓혀 재조회하고 그 사실을 밝힌 뒤, 그래도 영업시간이 결측이면 '확인 불가'로 표시해 전화번호와 응급실 대안을 내놓는 장면입니다. 두 분이 말한 에이전트다움과 데이터 검증, 그리고 제가 말한 방어선이 이 한 장면에 함께 담깁니다. 명절 비상진료 API는 제가 명세를 확인하지 못했으므로, 핵심 세 종이 틀리지 않게 돌아간 뒤의 선택 과제로 미루는 것이 안전합니다.

영업 여부의 오판율 하나가 학점을 가른다. 배서윤의 1선·3선은 그 숫자에 바로 붙일 수 있어 흡수한다. 적신호 문구는 검색 전에 규칙으로 끊고 119만 내보내며, 최종 문장의 기관명·전화번호는 API 응답과 불일치하면 폐기한다. 이 두 관문은 맞다·틀림이 이진이라 120건 정답 세트에 ‘적신호 오안내 0건’, ‘환각 폐기 건수’로 올리면 된다. 의료법 조문과 동의 화면은 각주 한 줄로 충분하고, 방어선 네 겹을 발표의 중심으로 밀면 측정이 수사로 바뀐다.

소크라테스의 ‘조건이 섞인 질문 → 되묻기 → 빈 결과면 범위 확대’는 에이전트 주장의 최소 증거로 남긴다. 다만 추가 질문 수와 ‘적합한 기관 비율’은 정답 라벨이 없으면 점수가 아니다. 같은 40건에 검색 화면과 에이전트를 나란히 두고, 종속변수는 영업여부 정확도·근거 없는 단정 수·빈 결과 후 재조회 성공률로 고정한다. 범위를 넓혀도 dutyTime이 -이거나 시각 밖이면 후보를 만들지 않고 전화 확인으로 거절한다. 되묻기는 위치·요일·진료과가 빠졌을 때만 허용하고, 시간을 LLM이 추정하는 순간 해당 건은 오답이다.

점수표는 여섯 칸이다. 영업여부 정확도, 시간 완전일치율, dutyTime8 결측률, 거절률, 적신호 오안내, 환각 폐기. 시연은 일요일 새벽 정상 1건, 흉통 입력의 119 전환 1건, API를 끊은 뒤 폐기·대체 문구 1건이다. 데모 호출은 50회 아래, 나머지 질의는 시군구 캐시다. 일 1,000회를 넘는 발표는 정확도가 아니라 오류 22의 시연이다.

두 초안이 내 주장을 한 단계 고쳤어요. 제가 제안한 ‘적합한 기관 비율’만으로는 실제로 문을 열었는지 보여주지 못하죠. 오성훈의 운영 여부 검증과 결측률 측정은 받아들이겠습니다. 다만 전화 한 번과 지도 앱 표시를 곧바로 ‘정답’으로 놓아도 될까요? 학기 프로젝트라면 검증 가능한 소규모 표본에 확인 시각·방법·불일치 사례를 함께 기록하고, “실제 운영 정확도”와 “API 기록에 따른 판정 정확도”를 구분하는 편이 정직해요. API 호출 한도와 필드 명세도 구현 전에 확인할 항목이지, 발표에서 검증 없이 단정할 숫자는 아니고요.

배서윤의 방어선도 설득력 있어요. 다만 적신호 단어 하나로 검색을 무조건 멈추면 “흉통이 뭔가요?” 같은 질문까지 응급 상황으로 오인하지 않을까요? 현재 증상을 호소하는 맥락인지 함께 확인하고, 응급 가능성이 크면 즉시 119를 안내하도록 설계하세요. 기관명·시간을 API 값과 대조하는 검증은 좋지만, 그보다 앞서 코드가 검증된 결과 카드만 만들고 LLM은 설명만 하게 하면 발표에서도 책임 경계가 더 선명해져요.

그렇다면 평가자의 마지막 질문은 이거예요. 방어선과 정확도 측정만 남겼을 때 LLM은 왜 필요한가요? 같은 복합 요청을 검색 앱과 비교해, 빠진 조건을 묻고 결과가 없을 때 사용자의 의도를 보존하며 다음 조회를 고르는 장면을 보여주세요. 이 차이가 측정되지 않으면 훌륭한 의료기관 검색 앱일 수는 있어도, ‘LLM 에이전트’라는 발표의 핵심 주장은 약해져요.

120건에서 적신호 오안내 0건은 학점을 가를 비율이 아닙니다. 사건 0의 95% 상한은 약 2.5%(3/120)이고, 규칙과 문항을 같은 손이 쓰면 그 0은 자기 채점입니다.

약점 공략은 분모입니다. 전화 정답은 새벽 미응답을 무작위 결측으로 두지 않습니다. 받은 곳만 남기면 성적은 ‘수화기를 드는 기관’의 성적이고, 미응답을 ‘확인 불가’와 같은 칸에 넣으면 거절이 정확도를 끌어올립니다. dutyTime 완전일치율은 같은 문자열의 파서 점수입니다. 일 단위 배치의 시각과 전화 시각이 어긋나면 문자열은 맞고 문은 닫히며, 그 불일치는 여섯 칸 어디에도 없습니다. dutyTime8 결측률을 성적으로 올리면 결측 기관을 빼는 쪽이 이깁니다. 결측은 층화하고, 분모에서는 빼지 마십시오.

시연 50회와 캐시 질의는 다른 모집단입니다. 1차 종속변수는 ‘조회 시각에 전화로 확인한 개문 여부’ 하나로 잠그고, API 문자열 일치율은 부록으로 내리십시오. 그 분모를 발표 전에 고정하지 않으면 높은 칸만 살아남습니다.

최종안의 뼈대는 "경보는 코드가 울리고, LLM은 그 경보를 끌 수 없다"는 한 문장이며, 이 대목에서 저는 제 입장을 고칩니다. 적신호 키워드가 나오면 검색 전에 끊고 119만 안내한다는 제 설계는 화재경보기를 연기 한 가닥에 건물 전체를 봉쇄하도록 맞춘 것과 같았습니다. "흉통이 뭔가요?"라는 질문까지 막고, "속이 꽉 막힌 듯 답답하다"는 실제 호소는 놓칩니다. 그래서 두 겹으로 바꿉니다. 키워드에 걸리면 119 안내 띠는 코드가 무조건 붙이고, LLM은 그 아래에서 지금 증상을 호소하는 것인지 정보를 묻는 것인지만 가립니다. LLM은 키워드가 놓친 모호한 표현을 응급으로 올릴 수는 있어도 붙은 띠를 뗄 수는 없고, 판단이 애매하면 호소로 봅니다. 정보 질문에 띠가 하나 더 붙는 손해는 작고 응급을 놓치는 손해는 되돌릴 수 없으니, 저울을 일부러 한쪽으로 기울여 두는 것입니다. 오탐과 미탐은 따로 세고, 문항은 규칙을 짠 손이 아닌 동료가 쓰게 하십시오.

정답 라벨을 전화 확인 기준으로 삼으라던 제 주장도 물러섭니다. 새벽의 수화기는 받는 기관만 남기는 체와 같고, 120건 전부를 전화로 채우는 일은 학기 과제의 분량도 아닙니다. 성적표는 두 장으로 나누십시오. 한 장은 전체 문항을 자동 채점한 'API 기록 기준 판정 정확도'이고, 다른 한 장은 확인 시각·방법·불일치 사례를 적은 소규모 전화 표본의 '실제 운영 정확도'입니다. 두 장의 차이가 곧 "공공 데이터를 어디까지 믿을 것인가"에 대한 답이므로, 감추지 말고 발표의 한 장면으로 올리십시오. 호출 한도, 필드 명세, 캐시 유통기한은 코드 첫 줄보다 먼저 확인해 표로 고정해야 합니다. 기초를 재지 않고 올린 벽은 시연 당일에 기웁니다.

"LLM은 왜 필요한가"라는 질문에는 역할의 경계선으로 답하십시오. 기관명·전화번호·영업 판정이 담긴 결과 카드는 API 응답에서 코드가 만들고, LLM은 그 칸에 한 글자도 쓰지 못합니다. LLM의 몫은 흐릿한 말을 조건으로 옮기고, 빠진 것을 되묻고, 거리 조건을 넓힌 사실을 밝히고, 카드를 풀어 설명하는 일입니다. 이 분담은 환각으로 만든 병원을 구조적으로 막는 장치이면서, 에이전트다움을 보이라는 소크라테스 님의 요구에 대한 답이기도 합니다. 증명은 같은 질문 세트를 검색 화면과 나란히 돌려서 하십시오. 모호한 질의의 해결률은 에이전트가 앞서고 오안내율은 검색 화면보다 나빠지지 않는다는 두 줄이 함께 서야 합니다. 편리함만 오르고 오안내가 늘었다면 그것은 개선이 아니라 위험의 이전입니다.

이 프로젝트의 발표 중심은 “병원을 잘 찾는다”보다 같은 복합 요청에서 검색 화면보다 무엇을 더 잘 해결하는가여야 해요. 코드가 공공 API 조회, 운영시간 판정, 출처·조회 시각이 붙은 결과 카드를 맡고, LLM은 빠진 조건을 묻거나 결과가 없을 때 조건을 어떻게 바꿀지 사용자와 결정하게 하세요. 같은 질문 세트로 검색 화면과 비교해 조건 충족과 대화 단계를 보여주면 에이전트라는 주장에 근거가 생겨요.

정확도는 무엇의 정확도인지 먼저 잠가야 해요. 1차 평가는 조회 시각에 전화로 확인한 개문 여부로 정하되, 표본과 분모를 발표 전에 고정하고 미응답·결측도 그대로 보고하세요. 전화가 연결된 곳만 채점하면 누구의 성적이 되겠어요? 확인 시각과 불일치 사례를 남기고, API 기록에 따른 판정 정확도는 별도로 제시하세요. API 필드 명세·호출 한도·캐시 유통기한은 구현 전에 확인할 항목이에요.

안전 규칙도 단어만 보고 끊어서는 안 돼요. 현재 증상을 호소하는 맥락에서 응급 가능성이 크면 검색보다 119 안내를 우선하고, 정보성 질문의 오탐과 모호한 증상 표현의 미탐을 따로 측정하세요. 제 입장은 여기서 수정됩니다. 운영 검증과 안전 방어선은 필수예요. 다만 그것만으로는 LLM의 필요성이 증명되지 않으니, 발표의 결정적 시연은 대화로 조건을 확인하고 다음 조회를 선택하는 장면이어야 해요.

영업 정확도의 분모는 조회 시각에 전화로 받은 개문 여부 하나로 잠근다. 미응답은 별도 층으로 두고 정확도의 분자와 분모에서 빼며, 결측 기관은 분모에 남기고 그 기관을 권고하면 오답이다. 같은 문자열의 dutyTime 일치와 120건 적신호 0건은 부록이다. 사건 0의 95% 상한은 약 2.5%라, 그 0은 성적이 아니다.

적신호는 지금 증상을 호소하는 문장에서만 검색 전에 끊고 119만 낸다. 정보만 묻는 문장은 설명으로 보내고 기관 카드를 만들지 않는다. 이 조각의 오탐과 미탐은 영업 정확도와 다른 표로 센다. 지도 앱은 정답에서 뺀다. 같은 공공 신고를 쓸 수 있어 독립 정답이 아니다.

기관명, 전화번호, 시각은 코드가 API 필드로 찍은 카드만 말한다. LLM은 위치, 요일, 진료과가 비었을 때의 한 번 되묻기, 빈 결과 뒤의 조건 완화, 카드 해설만 맡는다. dutyTime이 -이거나 조회 시각 밖이면 완화해도 후보는 없다. 같은 문항으로 검색 화면과 나란히 두고, 발표 점수는 실시간 전화 표본만 읽는다. 캐시 질의는 다른 모집단이다.