Frontier Engineering: Veradigm이 실제 기록을 본뜬 합성 데이터로 7주 만에 만든 의료 코딩 모델

Snowflake는 엔지니어를 고객 팀 안에 넣어 멈춘 AI 파일럿을 운영 단계로 옮기는 Frontier Engineering을 내놓았고, 첫 사례로 Veradigm의 의료 코딩 모델을 7주 만에 만든 일을 들었습니다. 환자 기록은 문서의 구조와 문체를 빌려주는 데만 쓰고 학습은 합성 차트로 했습니다. 따라 하려면 코드 사전, 보호된 데이터 환경, 정답을 승인할 현업 전문가 세 가지를 먼저 갖춰야 합니다.

요약

Snowflake의 Frontier Engineering 수석부사장 Madhan Arumugam은 2026년 11월 3일 회사 블로그에 이 팀이 일하는 방식을 소개했습니다. Frontier Engineering은 AI·데이터 엔지니어, 연구자, 업계 전문가로 이뤄진 팀입니다. 고객 팀 안에 들어가 업무 문제 하나를 함께 정하고, 운영 수준의 에이전트 시스템을 Snowflake의 governed data(권한과 통제가 걸린 데이터) 위에 짓습니다. 결과물은 일회성 시범이 아니라 조직이 다시 쓰는 자산으로 남고, 현장에서 검증된 기능은 Snowflake 플랫폼에 다시 반영됩니다. 글은 이 팀의 일을 소개하는 연재의 첫 편이며, 사례는 헬스케어 데이터·기술 회사 Veradigm 하나입니다.

Veradigm은 복잡한 의료 코딩(진료 기록을 보고 진단·시술 코드를 붙이는 일)과 의학 문서 이해를 맡을 자체 모델이 필요했습니다. 두 팀은 7주 만에 이 모델을 내놓았습니다. 학습 데이터는 Veradigm의 실제 기록에 근거한 합성 임상 데이터였고, 환자의 사적 데이터에는 접근하지 않았다고 글은 밝힙니다. 모델은 만성질환이나 여러 질환을 함께 앓는 환자처럼 까다로운 건의 코드 지정을 돕습니다. 비정형 기록에서 구조화 데이터를 뽑고 품질·위험 조정 프로그램도 지원합니다. Veradigm은 복잡한 의료 코딩에서 성능이 최대 9배 좋아졌다고 밝혔습니다. 블로그는 기법을 자세히 적지 않았지만, Veradigm 연구진과 Snowflake 연구진이 2026년 3월 arXiv에 함께 낸 논문(교신저자 Gaurav Kaushik)이 같은 접근을 적어 두었습니다. 아래 메커니즘과 기술 디테일의 수치는 그 논문에서 가져왔습니다. 블로그의 7주 모델과 논문의 모델이 같은 모델이라는 문장은 두 글 어디에도 없습니다.

핵심 메커니즘

Frontier Engineering: 엔지니어를 고객 팀 안에 넣는 배포 방식

벤더가 도구만 넘기지 않고 엔지니어와 연구자를 고객 팀에 붙여, 문제 정의부터 운영까지 같이 끝내는 방식입니다. OpenAI가 FDE(forward deployed engineer, 고객 현장에 배치된 엔지니어)라고 부르는 모델과 같은 계열입니다. 블로그는 네 단계로 설명합니다. 값이 큰 문제 하나를 고르고 측정할 결과에 합의한 뒤 고객 팀과 나란히 일합니다. 그다음 governed data 위에 지어 다른 부서도 다시 쓸 수 있게 하고, 각 건에서 얻은 것을 플랫폼 기능으로 돌려 다른 고객도 쓰게 합니다. 글이 꼽는 대상은 파일럿이 멈춘 기업, 규제 산업처럼 AI에 지켜야 할 선이 분명한 조직, AI 경험이 적은 팀입니다. 반대로 문제가 아직 하나로 좁혀지지 않았거나 측정할 결과를 정하지 못했다면 엔지니어를 붙여도 7주 안에 끝낼 대상이 없습니다.

Meta-description 기반 합성: 실제 기록은 모양만 빌려준다

논문에서 쓴 합성 차트 생성법입니다. 먼저 실제 임상 문서를 보호된 환경 안에서 모읍니다. 거기서 환자 고유 정보는 빼고 문서의 구성과 의료진의 작성 습관만 담은 추상 설명(meta-description)을 뽑습니다. 그다음 ICD-10-CM(미국 진단 코드 체계) 코드 하나를 seed로 무작위로 고르고, 그 코드와 함께 나올 법한 코드들을 만듭니다. 언어 모델은 meta-description과 코드 묶음을 받아 새 차트를 씁니다. 이 과정을 여러 원본 문서에 걸쳐 되풀이해 다양성을 얻습니다. 실제 기록 덕분에 합성 차트가 현장 문서처럼 보이고, 내용은 새로 만든 것이라 환자 정보가 학습 데이터로 들어가지 않습니다. 가상 예시로, “내과 외래 경과 기록, 주호소 한 줄, 활력징후 표, 평가·계획을 문제별 번호 목록으로 작성”이라는 meta-description에 당뇨와 심부전 코드를 묶어 주면 그 형식의 새 경과 기록이 나옵니다.

Retrieval-grounded labeling: 코드는 사전 안에서만 고른다

합성 차트에 정답 코드를 붙이는 방식입니다. 차트를 임베딩한 뒤 줄 단위로 나누고, ICD 코드와 설명을 따로 색인한 데이터베이스에서 줄마다 비슷한 코드를 찾아 후보로 붙입니다. 언어 모델은 이 후보 안에서 코드를 고르고 어느 줄이 근거인지 함께 적습니다. CPT(미국 시술 코드 체계)는 순서가 조금 다릅니다. 모델이 코드 번호 대신 짧은 시술 설명을 쓰게 하고, 그 설명을 코사인 유사도로 카탈로그와 맞춰 후보를 얻은 뒤, 제약을 건 모델이 유효한 후보 중에서만 최종 코드를 고릅니다. 맞는 코드를 찾지 못한 노트는 버립니다. 모델이 존재하지 않는 코드를 지어내는 일을 막으려는 구조입니다. 논문은 이 라벨링을 Advanced Illness(중증 질환), Frailty(노쇠), SDoH(건강의 사회적 결정 요인) 세 영역에 집중했습니다.

Full SFT와 JSON 출력: 70B 모델 전체를 코딩 업무에 맞춘다

논문은 Llama 3 계열 70B Instruct 모델의 파라미터 전체를 미세조정(full SFT, supervised fine-tuning)했습니다. LoRA처럼 일부 층만 고치는 방식이 아닙니다. 출력은 처음부터 정해진 JSON 형식으로 학습시켰습니다. ICD는 코드, 임상적 이유, 근거와 그 위치를 내고, CPT는 코드와 이유를 냅니다. 어려운 예를 늘리려고 ICD 학습 데이터의 30%는 노트 두 개를 이어 붙이고 라벨을 합쳤습니다. 짧은 예는 8,192 토큰까지 한 시퀀스로 묶어(packing) GPU를 덜 놀렸습니다. 학습 데이터와 평가 데이터는 95 대 5로 고정해 나눴습니다. 범용 모델에 프롬프트만 바꾸는 방식보다 준비가 무겁지만, 같은 형식의 판단을 대량으로 반복하는 업무라면 이 비용을 감당할 만합니다.

Hierarchical evaluation: 같은 답을 다섯 깊이로 채점한다

코드 하나를 맞혔는지 틀렸는지만 보면 “대분류는 맞고 세부만 틀린” 답과 “완전히 엉뚱한” 답이 똑같이 0점이 됩니다. 논문은 ICD 예측을 다섯 수준으로 나눠 채점했습니다. Level 0은 대분류, Level 1은 소분류, Level 2는 세부 진단, Level 3은 정확한 코드, Level 4는 정확한 코드에 근거 위치까지 맞힌 경우입니다. 근거 위치는 예측한 근거 줄과 정답 근거 줄이 얼마나 겹치는지(Jaccard 유사도)로 봅니다. 여기에 두 가지 확인을 더했습니다. 합성 차트 100건은 임상 전문가가 라벨을 하나씩 승인하거나 반려해 별도 정답으로 삼았고, MedQA, MedMCQA, PubMedQA, MMLU 의학 과목으로 일반 의학 지식이 얼마나 남았는지도 쟀습니다.

통념과 다른 주장

저자가 든 사례

Veradigm: 7주 만에 만든 의료 코딩 전용 모델

구분	내용
상황	헬스케어 데이터·기술 회사 Veradigm. 의학 문서 이해와 복잡한 의료 코딩을 맡을 자체 모델이 필요
한 일	Snowflake Frontier Engineering 팀이 합류해 실제 기록에 근거한 합성 임상 데이터로 모델 구축. 환자의 사적 데이터에는 접근하지 않음
결과	7주 만에 모델 완성. 만성·복합 질환 환자의 코드 지정 지원, 비정형 기록의 구조화 추출, 품질·위험 조정 프로그램 지원. Veradigm은 복잡한 코딩에서 최대 9배 성능을 밝힘. 단계별 일정과 평가 방법은 원문에서 밝히지 않음
연결	Frontier Engineering, Meta-description 기반 합성

기술 디테일: 합성 데이터로 업무 전용 모델을 만든다면

아래 필드 이름, 설정값, 판정 기준은 논문의 절차를 실제로 돌릴 때 필요한 것을 정리한 실행 제안입니다. 논문에서 온 수치는 그렇다고 밝혔습니다.

Meta-description 기반 합성을 돌리려면 실제 문서를 읽는 단계와 새 차트를 쓰는 단계를 다른 곳에 둡니다. meta-description 추출은 데이터가 이미 있는 보호 영역 안에서, 그 영역에서 호출할 수 있는 모델로만 돌립니다. 추출 결과는 자유 문장보다 필드로 받아야 나중에 섞어 쓰기 쉽습니다. 생성 단계는 temperature를 0.7~0.9로 높여 문체를 다양하게 하고, 같은 meta-description으로 seed 코드를 바꿔 3~5건씩 씁니다. 논문은 PHI(보호 대상 건강 정보) 차단을 주로 프롬프트 지시로 처리했다고 적었습니다. 운영에서는 생성된 차트를 이름·날짜·주소·식별번호 탐지기에 한 번 더 통과시키고, 걸린 차트는 버립니다.

{
  "meta_id": "MD-0412",
  "doc_type": "outpatient_progress_note",
  "specialty": "internal_medicine",
  "sections": ["chief_complaint", "vitals_table", "assessment_plan_numbered"],
  "style": {"abbreviation_density": "high", "avg_sentence_words": 9},
  "seed_code": "E11.9",
  "cooccurring_codes": ["I50.9", "R54", "Z60.2"],
  "phi_scan": {"passed": true, "detector_version": "phi-v2"}
}

위는 가상 예시입니다. seed_code와 cooccurring_codes는 생성 지시에 쓰는 값이고, 정답 라벨은 다음 단계에서 따로 붙입니다.

Retrieval-grounded labeling을 돌리려면 코드 사전을 먼저 버전째 고정합니다. 코드, 공식 설명, 상위 분류, 유효 기간을 한 행으로 두고 설명을 임베딩해 색인합니다. 줄마다 상위 10~20개 후보를 가져오고, 모델에게는 후보 목록 밖의 코드를 내지 못하게 JSON 스키마의 enum이나 사후 검증으로 막습니다. 라벨 한 건은 아래처럼 남기면 학습, 평가, 전문가 검토에 그대로 씁니다(가상 예시).

{
  "chart_id": "SYN-ICD-00873",
  "codes": [
    {"code": "R54", "rationale": "보행 보조기 사용, 최근 3개월 낙상 2회 기록", "evidence_lines": [14, 15]},
    {"code": "Z60.2", "rationale": "혼자 거주, 돌봄 제공자 없음", "evidence_lines": [6]}
  ],
  "code_set_version": "ICD-10-CM FY2026",
  "label_source": "retrieval+llm",
  "expert_review": {"status": "pending", "reviewer_id": null, "reject_reason": null}
}

Full SFT를 돌리려면 논문의 설정을 출발점으로 씁니다. Llama 3 계열 70B Instruct, Snowflake의 학습 프레임워크 ArcticTraining, ZeRO-3와 옵티마이저 상태 오프로딩, FP16, Adam, 학습률 1e-5, weight decay 0.1, 선형 스케줄러, 4 epoch, 장치당 micro-batch 4, 최대 길이 8,192 토큰, NVIDIA H200 8장입니다. 70B 전체 학습이 부담되면 같은 데이터로 8B급 모델이나 LoRA를 먼저 돌려 데이터가 효과가 있는지부터 봅니다. 평가 세트는 학습 전에 떼어 두고, 같은 meta-description에서 나온 차트가 학습과 평가 양쪽에 섞이지 않게 meta_id 단위로 나눕니다.

Hierarchical evaluation을 돌리려면 Level 0~4 F1, 유효한 답을 하나도 못 낸 차트 비율, 근거 줄 Jaccard를 매 학습 뒤 같은 표로 냅니다. 영역별(중증 질환, 노쇠, SDoH)로도 나눕니다. 논문에서 영역 전체 F1은 0.841, 노쇠 0.873, 중증 질환 0.863, SDoH 0.767이었습니다. 일반 의학 지식 평균은 0.829에서 0.799로 내려갔으므로, 코딩이 아닌 범용 질의는 기본 모델로 보내는 라우팅을 둡니다. 평가 때는 temperature 0으로 돌리고 같은 차트를 3회 돌려 코드 집합이 달라지는 비율도 기록합니다. 추론은 학습 데이터와 같은 보호 영역 안에서 돌리고, 출력은 JSON 스키마로 검증해 깨진 답은 2회까지 다시 요청한 뒤에도 실패하면 no_valid_prediction으로 남깁니다. 이 비율이 논문이 지표로 둔 ‘유효한 답이 없는 차트 비율’입니다.

사람 검토가 왜 남는지. 논문의 전문가 검토 100건에서 recall은 0.86~0.93으로 높았고 precision은 0.32~0.40이었습니다. 빠뜨리는 코드는 적지만 필요 없는 코드를 많이 붙인다는 뜻입니다. 그래서 첫 운영은 모델이 후보를 내고 코더가 지우는 형태가 맞습니다. 논문 저자들도 모델을 코더와 컴플라이언스 담당자를 돕는 보조로 두고 최종 판정은 사람에게 남기는 방식을 제안했습니다.

막히는 경우	증상	대응
코드 과다 생성	precision이 낮아 코더가 지울 코드가 많음	근거 줄이 없는 코드 제거, 영역 밖 코드 필터, 코드별 신뢰도 임계값
희귀 코드	빈도 낮은 코드에서 F1 편차가 큼(논문 Figure 5)	seed 샘플링에서 희귀 코드 비중을 올려 재생성
SDoH 영역	생활 환경·기능 제한 관련 코드가 가장 약함	그 영역 meta-description과 seed를 따로 늘림
합성 문서가 너무 깔끔함	실제 기록의 오타·복사 붙여넣기 패턴을 놓침	실제 기록 소량을 보호 영역 안에서만 평가 세트로 써서 차이 확인
코드 체계 개정	새 코드가 후보에 없음	code_set_version 갱신 뒤 사전 재색인, 영향 코드만 재생성·재평가

현업 실행 디테일: 누가, 언제, 무엇을

역할	맡는 일
제품·사업 책임자	풀 문제 하나와 측정 지표 확정, 7주 뒤 진행 여부 판정
임상 코딩 전문가(2~3명)	meta-description 검수, 라벨 100건 승인·반려와 이유 기록, 시범 운영 피드백
개인정보·컴플라이언스 담당	실제 기록을 쓰는 범위 승인, PHI 검사 기준과 표본 점검
데이터 엔지니어	보호 영역 구성, 코드 사전 색인, 학습·평가 데이터 관리
벤더 측 엔지니어·연구자	생성·라벨 파이프라인, 학습과 평가 실행, 주간 결과 보고

준비물. 대상 코드 체계와 버전, 그중 이번에 다룰 영역(예: 노쇠, 중증 질환)의 코드 목록, 보호 영역 안에서 접근 가능한 실제 문서 표본 수백 건, 지금 코더가 건당 쓰는 시간과 오류율 기준선, 전문가가 라벨을 승인할 화면이나 시트가 필요합니다.

기간	할 일	산출물
1주	문제·영역·지표 합의, 기본 모델 zero-shot 기준선 측정	지표 정의서, 기준선 F1
2~3주	meta-description 추출, 합성 차트 생성, PHI 검사	합성 차트 세트, 검사 통과율
3~4주	검색 기반 라벨링, 전문가 100건 승인·반려	라벨 데이터, 전문가 정답 세트, 반려 이유 목록
5주	full SFT(또는 소형 모델 선행 학습)	학습된 모델, 학습 로그
6주	Level 0~4, 영역별, 일반 지식 평가	평가표, 실패 유형 목록
7주	코더 5~10명이 후보 제시 방식으로 시범 사용, 진행 판정	건당 시간 변화, 판정 보고서

현업에 물을 것.

1. 지금 코더가 가장 오래 붙잡는 건은 어떤 환자, 어떤 영역입니까?
2. 코드 하나를 붙일 때 근거로 삼는 문서와 줄은 어디입니까?
3. 감사나 청구 반려에서 가장 자주 지적되는 코드는 무엇입니까?
4. 실제 기록을 어느 범위까지, 어느 환경 안에서 쓸 수 있습니까?
5. 모델이 후보를 내면 코더는 지우는 일과 더하는 일 중 무엇이 더 편합니까?

진행 판정 기준(예시). 6주차 평가에서 대상 영역의 Level 3 F1이 기준선의 3배 이상이고, 전문가 정답 세트에서 recall이 0.85 이상이어야 합니다. 7주차 시범에서는 코더의 건당 시간이 20% 이상 줄고, 모델이 지어낸 존재하지 않는 코드가 0건이어야 합니다. 하나라도 못 채우면 실패 유형 목록에서 가장 많은 유형 하나를 고쳐 2주를 더 봅니다.

AX 적용 제언. 이 사례에서 옮길 것은 두 가지입니다. 하나는 엔지니어를 고객 팀에 붙여 문제 하나를 7주 안에 운영 단계까지 끌고 가는 계약 방식이고, 다른 하나는 데이터를 밖으로 못 내는 업무에서 실제 문서의 모양만 빌려 합성 데이터로 학습하는 방식입니다. 첫 후보는 정해진 코드 사전이 있고 민감 정보 때문에 데이터 반출이 막힌 분류 업무입니다. 보험 청구 사유 코드, 제조 불량·클레임 코드, 콜센터 상담 사유 코드가 여기에 맞습니다. 순서는 코드 사전이 가장 잘 정리된 업무 하나로 시작해 비정형 문서의 필드 추출로 넓히는 편이 좋습니다. 벤더와 계약할 때는 7주 뒤 무엇을 재서 진행을 정할지와, 만든 모델과 데이터 파이프라인이 누구의 자산으로 남는지를 먼저 문서로 합의해야 합니다.

원문 사례

항목	내용
글	Snowflake 블로그, 2026.11.3 게재, Frontier Engineering 연재 첫 편
저자	Madhan Arumugam, Snowflake Frontier Engineering 수석부사장
Frontier Engineering	AI·데이터 엔지니어, 연구자, 업계 전문가가 고객 팀에 합류. 4단계: 문제 선정, 팀 합류, governed data 위 구축, 재사용·확장
대상 고객	파일럿이 멈춘 기업, AI 통제 기준이 분명한 규제 산업, AI 경험이 적은 팀
Veradigm 사례	의학 문서 이해·복잡한 의료 코딩용 자체 모델, 7주 만에 완성
학습 데이터	실제 기록에 근거한 합성 임상 데이터, 환자의 사적 데이터 접근 없음
용도	만성·복합 질환 코드 지정 지원, 비정형 기록의 구조화 추출, 품질·위험 조정 프로그램 지원
성과	복잡한 의료 코딩 최대 9배 성능(Veradigm 발표), 수작업 코딩 시간 감소
발언	Gaurav Kaushik, Veradigm Applied Intelligence 수석부사장
보강 자료	arXiv 2603.23515(2026.3.6), Veradigm·Snowflake 공저. Llama 3 계열 70B full SFT, ICD-10-CM F1 0.180 → 0.704, CPT 0.193 → 0.736, 보류 합성 차트 761건, 전문가 검토 100건(F1 약 0.44), 일반 의학 지식 평균 0.829 → 0.799

핵심 개념

ICD-10-CM

미국에서 진단을 기록하고 청구할 때 쓰는 질병 분류 코드 체계입니다.

CPT

미국에서 의료 시술과 서비스를 기록하는 코드 체계입니다.

risk adjustment

환자의 질병 부담을 코드로 반영해 보험 지급액을 조정하는 제도입니다. 코드가 빠지면 지급액이 실제보다 낮아집니다.

PHI

protected health information. 이름, 날짜, 식별번호처럼 개인을 알아볼 수 있는 건강 정보입니다.

governed data

누가 무엇을 볼 수 있는지 권한과 감사 기록이 걸려 있는 데이터입니다.

sequence packing

짧은 학습 예 여러 개를 한 입력 길이에 이어 붙여 GPU 낭비를 줄이는 방법입니다.

precision / recall

precision은 낸 코드 중 맞은 비율, recall은 맞혀야 할 코드 중 찾아낸 비율입니다.

내 메모

TODO: 내 생각 추가

원문은 Snowflake 블로그의 「From AI Pilot to Production: What Embedded Snowflake Frontier Engineers Deliver for Enterprises」(Madhan Arumugam, 2026.11.3 게재)입니다. 메커니즘의 작동 방식과 기술 수치는 Veradigm·Snowflake 연구진의 논문 「Training a Large Language Model for Medical Coding Using Privacy-Preserving Synthetic Clinical Data」(arXiv 2603.23515, 2026.3.6)로 보강했습니다. 두 글 모두 블로그의 7주 모델과 논문의 모델이 같다고 직접 밝히지는 않습니다. 요약, 핵심 메커니즘, 통념과 다른 주장, 사례는 두 글의 내용을 AX Partners가 다시 정리한 것이고, 기술·현업 실행 디테일의 필드, 설정 제안, 일정, 판정 기준, 인포그래픽과 표는 새로 작성했습니다. 전체 내용은 원문 블로그와 arXiv 논문에서 볼 수 있습니다.