기능 설명서가 아니라, 이걸 왜 만들었고 무엇에 기대어 만들었는지에 대한 글입니다.
진료실에서 매번 같은 상병코드 몇 개만 반복해서 청구하고 있다는 걸 어느 순간 깨달았습니다. 분명히 더 정확한 코드가 있는데도, 그걸 찾아서 확인하는 과정이 번거로워서 손에 익은 코드로 돌아가게 되는 일이 반복됐습니다. 이건 저만의 습관이 아니라 진료 현장 전체에서 흔히 벌어지는 일이라고 생각합니다. 문제는 이게 단순히 "덜 정밀한 청구"로 끝나지 않는다는 점입니다 — 관성적으로 반복되는 코드는 시간이 지날수록 점점 더 관성적으로 굳어집니다.
그래서 이 도구를 만들기 시작했습니다. 거창한 진단 알고리즘을 만들겠다는 생각보다는, 매번 새로 검색하고 확인하는 그 귀찮음을 줄여서, 정확한 코드를 쓰는 쪽이 더 쉬운 선택이 되도록 만들고 싶었습니다.
처음 설계할 때부터 분명히 하고 싶었던 게 있습니다. 이 프로그램은 정답을 대신 정해주지 않습니다. 질문에 답을 하다 보면 후보가 점점 좁혀지지만, 마지막 한 개를 고르는 건 항상 진료실에 있는 한의사의 몫으로 남겨둡니다. 이 도구가 할 일은 후보군을 정확하고 충분히 넓게 보여주는 것까지입니다.
환자의 주소증과 문진 내용들을 입력해서 후보군을 추려내는 과정을 AI가 뽑아낼 수도 있겠습니다만, 이건 제가 원하는 방향은 아니었습니다. 어디까지나 한의사의 진단과 판단이 어딘가에는 위치하고 있어야 한다고 판단했습니다. 저는 이 과정을 마지막 선택지로 남겨두었습니다. 그런 이유로, 이 과정까지 오기 위해 꼭 해야 할 건 '정답인 걸 골라내지 말고 오답인 걸 걸러내자'였습니다.
가장 신경 쓴 원칙은 하나입니다 — 정답이 후보군에서 빠지는 일은 절대로 없어야 한다는 것입니다. 후보가 좀 많이 나와서 그중에 눈으로 걸러야 하는 오답이 섞여 있는 건 괜찮습니다. 그건 한의사가 보면 바로 걸러낼 수 있으니까요. 하지만 맞는 코드가 필터링 단계에서 조용히 사라지는 건 이 도구 존재 이유 자체를 부정하는 일이라고 봤습니다. 그래서 새로운 정렬 기준(청구빈도 같은 것)을 넣을 때도 항상 "후보를 강조하고 정렬하는 용도"로만 쓰고, 그걸로 후보를 걸러내는 데는 절대 쓰지 않는다는 선을 지켰습니다.
이 프로그램의 판단은 전부 근거가 있습니다. 어디서 가져온 데이터인지, 왜 그렇게 분류했는지를 남겨두고 싶었습니다.
모든 상병코드의 뿌리는 통계청·보건복지부가 고시한 KCD-9(한국표준질병사인분류)입니다.
이를 손대지 않는 원천 정본으로 하고, kcd_origin.db로 1차 DB 처리하였습니다.
여기서 한의원에서 쓰이지 않는 코드를 제거하고 임상적으로 다듬어 실제 진료에 쓸 수 있게 2차 DB 처리한 게
kcd_hani.db입니다. 여기 쓰이는 모든 상병명은 이 데이터베이스를 참조합니다.
부위별·기전별·조직군별로 상병을 소거해나가는 카비네이터의 핵심 로직(대부위 → 발병기전 → 세부분절 → 조직군 → 청구안전도)은 기존 분류 체계를 사용하면서도, 다른 코드지만 비슷한 부류의 질병을 걸러내지 않고 같이 포함시켜서(관절은 대부분 M코드지만 턱관절은 K코드 같은) 같은 카테고리에서 한 번에 볼 수 있게 분류하도록 설계했습니다. 여기에 영상진단이나 혈액검사 같은 객관적 근거가 없어도 진료가 가능한 코드를 서로 분류하는 단계를 AI 교차검증으로 추가하였기 때문에, 일선 진료환경에서 상병명을 선택하기에 조금이나마 편리하게 사용하지 않을까 싶습니다. 이 부분이 이 앱의 특장점이기도 합니다.
건강보험심사평가원이 공개하는 한방·양방 청구통계(2025년 기준)를 반영했습니다. 이 자료는 웹에 단순 방문하여 다운로드 받을 수는 없고, 공공데이터포털(https://data.go.kr)에 건강보험심사평가원_질병정보서비스 API 키를 신청하면 받을 수 있습니다. 하루 호출 제한이 걸려 있어, 3일 동안 나눠 받아 정리해야 할 정도로 양이 꽤 됩니다. 다만 이 숫자는 후보군 내부에서 "어떤 코드가 더 자주 쓰이는지" 참고용으로 정렬·강조하는 데만 씁니다. 앞서 말씀드린 원칙대로, 청구빈도가 낮다는 이유로 후보에서 빠지는 코드는 없습니다.
본 저작물은 '건강보험심사평가원'에서 2025년 작성하여 공공누리 제1유형으로 개방한 '질병정보서비스(청구통계)'를 이용하였으며, 해당 저작물은 '공공데이터포털(data.go.kr)'에서 무료로 다운받으실 수 있습니다.
보험약과 연계하여 적절한 U코드를 매칭하기 위해, U코드를 표리·허실·음양·한열의 팔강과 장부 변증으로 U코드를 수작업으로 매핑하는 작업을 별도 프로젝트로 진행했습니다. 각 U코드가 어떤 변증 축에 해당하는지를 하나씩 대조해 정리했습니다만, 제 주관이 꽤나 들어가 있기 때문에 오류가 있을 수 있습니다. 오답을 걸러내기 위한 용도이지 정답을 고르기 위한 용도는 아니어서, 사용자가 크게 불편함을 느낄 요소는 없을 것이라 생각됩니다.
보건복지부가 고시한 (보건복지부 고시 제2026-124호) 한약제제 급여목록 및 상한금액표(별표2, 기준처방별 가격표)를 정본으로 삼았습니다. 여기에는 56종의 처방 중 48종이 현재 어느 제약회사에서 제조되고 있고, 이 처방의 출전은 어디이고, 어떤 약재구성으로 한의원에 제공되고 있는지까지 자세히 적혀 있는 통계자료입니다. 그래서 약재구성은 이 고시의 g단위 표기를 그대로 따랐고, 원문 주치는 처방의 근거가 되는 원전 문헌을 직접 인용해 출처를 남겼습니다. 이에 더해, 각 처방을 생산하는 제약회사 정보 또한 빠짐없이 수록하였습니다.
처음엔 데이터를 한 번 잘 다듬어 넣으면 그걸로 어느 정도 끝나는 일이라고 생각했습니다. 그런데 실제로 각 대분류·세부분절·조직군마다 코드를 하나씩 다 열어서 눈으로 확인하는 전수조사를 진행하다 보니, KCD 자체가 생각했던 것만큼 완결된 체계는 아니라는 것을 알게 됐습니다.
KCD는 상병마다 부위를 나타내는 표준화된 접미사(여러 부위 / 어깨부분 / 위팔 / 아래팔 / 손 /
골반 및 대퇴 / 아래다리 / 발목 및 발 / 기타 부분 / 상세불명 부분)를 형식적으로는 거의 모든 코드에
동일하게 붙여둡니다. 문제는 이 접미사가 그 질환이 실제로 발생할 수 있는 부위와 무관하게 기계적으로만
붙어있는 경우가 꽤 있었다는 점입니다. 예를 들면, 방아쇠수지(M65.3)처럼 손에서만 생기는 병인데도,
부모코드(3단)만 참조했을 땐 "위팔(M65.32)"이나 "골반 및 대퇴(M65.36)" 같은,
임상적으로는 있을 수 없는 부위 접미사가 나란히 존재하는 것처럼 오해할 수 있습니다. 반대로 류마티스관절염(M79.0)처럼
전신에 걸쳐 나타나는 병은, "이 병이 전신성 질환이라는 것"과 "이 코드가 가리키는 구체적인 신체 부위"가
같은 축에 뒤섞여 있어서, 데이터를 그대로 가져다 쓰면 오히려 멀쩡히 존재하는 부위 정보를 놓치게 되는
경우도 있었습니다. "기타"나 "상세불명" 같은 포괄 코드가 형제 코드들과는 다른 진단 기준을 그대로
물려받아, 실제로는 임상 진찰만으로 충분한데 정밀검사가 필요한 것처럼 분류돼 있는 경우도 여럿
발견했습니다.
결국 KCD를 있는 그대로 기계적으로 따라가는 것만으로는 부족하다는 걸 깨달았고, 코드군을 하나씩 열어서 실제 임상적 의미에 맞게 다시 배치하는 작업을 진행했습니다. 이 글을 쓰는 시점 기준으로 내과 7대 분과 전체와 근골격계 상병 전 영역을 이 방식으로 검토를 마쳤습니다. 물론 이걸로 완벽해졌다는 뜻은 아닙니다. 앞으로도 코드를 쓰다가, 혹은 검토를 이어가다가 이상한 부분이 발견되면 계속 고쳐나갈 생각입니다.
이 작업을 하면서 개인적으로 가장 뜨끔했던 사례 하나를 덧붙입니다. M48.06(척추협착, 요추부)은
타 병원에서 이미 협착 진단을 받고 온 환자에게, 별다른 재확인 없이 그대로 옮겨 적기 쉬운 코드입니다.
저도 그렇게 별생각 없이 몇 번 썼던 것으로 기억합니다. 이번에 정리하다 실제 청구 데이터를 보니 한의의료기관에서 연간 110만 건 넘게
청구되고 있었습니다. (양방 전체 1,017만 건의 약 11% 수준) 척추협착은 KCD 정의상 영상소견이 있어야
확정할 수 있는 진단이라, 이 앱에서는 기본 화면(임상 진찰만으로 확인 가능한 코드 목록)에는 뜨지 않고
"영상검사 필요" 쪽으로 넘어가야만 보입니다. 이 앱을 자주 쓰다 보면 저의 이 잘못된 습관도 차차 고쳐질 거라 생각합니다.
이 프로그램은 혼자 완결되는 도구로 끝나진 않습니다. 이 Web-app 말고도 현재 작업 중인 약재도매시세분석앱, 원문 AI 번역 DB 구축, 처방검색웹앱(InSAM 프로그램 오마주), 원내처방전 및 복용법출력 Rx, 본초처방별논문수집앱 등 다른 도구들과 함께 저만을 위한 하나의 한의학 통합 플랫폼으로 이어질 예정입니다. 대부분은 이미 개발이 끝났지만 일부는 지금도 개발 중이기도 하고, 통합 플랫폼은 아직 구현되지 않아 각자 따로 돌아가지만, 언젠가 서로의 데이터를 참고하면서 진료 전체 흐름을 도와주는 하나의 생태계가 되는 게 최종 목표입니다. 그중에 kcd_match(카비네이터)는 여러분들 에게도 아주 조금이나마 도움이 될까 싶어 부족한 기능이지만 이렇게 공개해봅니다.
거창하게 시작한 프로젝트는 아니었습니다. 매번 반복되는 작은 불편을 줄여보자는 생각에서 출발했을 뿐인데, 만들다 보니 데이터를 하나씩 검증하고 근거를 남기는 일이 생각보다 큰 작업이 됐습니다. 그래도 이 도구를 쓰는 순간만큼은, 익숙한 코드로 돌아가지 않고 한 번 더 확인해보는 계기가 되길 바랍니다.
오류가 있거나 개선할 점이 있다면 elaminus1@gmail.com으로 메일 보내주시면 검토 후 반영하도록 하겠습니다.