By Erin Jang — 03 Jul 2026

의료 비전모델, AI 개발자는 어디서 AI 도구의 도움을 받을까

문제: 모델보다 먼저 막히는 지점들

의료 비전모델을 처음 만들어보면 예상과 다른 곳에서 시간이 새는 걸 느끼게 됩니다.
논문을 보고 아키텍처를 고르고 손실 함수를 설계하는 일은 생각보다 빨리 끝납니다.
정작 몇 주씩 걸리는 건 다음과 같은 작업들입니다.

수천 장의 이미지 중 어떤 걸 학습에 쓸지 정리하고 마스크를 그리는 일
실험을 할 때마다 반복되는 전처리·증강·로깅 코드를 다시 짜는 일
"지난주 돌린 실험이랑 이번 실험이 정확히 뭐가 다른지" 기억이 안 나서 로그를 뒤지는 일

이 세 가지는 각각 데이터 라벨링, 파이프라인 개발, 실험 추적 단계에 해당합니다.

그리고 다행히도, 2025년 말부터 2026년 상반기 사이에 이 세 단계 각각에 특화된 AI 도구들이 실무에서 쓸 만한 수준으로 성숙했습니다.

아래 그림처럼, 각 단계마다 자리를 잡은 도구가 다릅니다.

이 글에서는 환자 이미지를 보고 중증도를 예측하는 분류 모델처럼 의료 분야의 비전모델을 개발할 때, 데이터 라벨링, 파이프라인 개발, 실험 추적 세 단계를 순서대로 따라가며 유용하게 활용 가능한 AI 도구들을 살펴봅니다. 그리고 각 도구가 정확히 무엇을 하고, 어떻게 써야 하고, 어디서 멈춰야 하는지를 다룹니다.

단계별 도구 깊게 보기

1. 데이터 라벨링: SAM 3 / 3.1과 Cleanlab

SAM - 왜 파운데이션 모델을 라벨링에 쓰는가

몇 년 전까지 segmentation mask는 사람이 픽셀 단위로 직접 그려야 했습니다.

Meta의 Segment Anything Model(SAM)은 "프롬프트를 주면 마스크를 뽑아준다"는 접근으로 이 작업을 뒤집었습니다.

2025년 11월 공개된 SAM 3는 여기서 한 단계 더 나가서, 점이나 바운딩 박스 같은 위치 프롬프트뿐 아니라 짧은 텍스트 문구나 예시 이미지 한 장만 줘도 이미지·영상 안에서 해당 개념에 해당하는 모든 인스턴스를 한 번에 찾아 분리하는 기능(Promptable Concept Segmentation, PCS)을 지원합니다.

2026년 3월 공개된 SAM 3.1은 여기에 멀티플렉싱과 전역 추론을 더해 실시간 영상 처리에 맞게 속도를 끌어올린 버전입니다.

세 가지 프롬프트 방식은 용도가 다릅니다.

포인트/박스 프롬프트: 이미지 한 장에서 특정 위치의 객체 하나를 빠르게 분리할 때. 라벨러가 클릭 몇 번으로 마스크 초안을 얻고 다듬는 인터랙티브 라벨링 도구에 적합합니다.
텍스트 프롬프트(PCS): "이미지 안의 병변 전부"처럼 개념 단위로 대량의 이미지를 한 번에 스크리닝할 때. 새 데이터셋이 들어올 때마다 이런 후보를 1차로 걸러내는 용도로 유용합니다.
예시 이미지 프롬프트: 이미 확정한 기준 이미지와 유사한 패턴을 가진 이미지들을 자동으로 찾아 매칭할 때.

라벨링 워크플로우에 SAM을 넣는 가장 흔한 패턴은 다음과 같습니다.

SAM으로 전체 데이터셋에 1차 마스크를 자동 생성 (포인트/박스 또는 PCS)
마스크의 confidence 점수가 낮은 이미지만 사람이 검토·보정
검토가 끝난 마스크를 최종 학습 데이터로 확정

다만 SAM은 자연 이미지 기준으로 학습된 모델이라, 의료·특수 도메인 이미지에서는 자연 이미지 대비 정확도가 떨어지고, 애초에 "이게 무슨 병변인지" 같은 클래스 이름을 붙여주지는 않습니다.

그래서 SAM은 "마스크의 경계를 잡아주는 도구"로, 클래스 판정은 여전히 사람(또는 별도로 학습한 분류기)이 맡는 역할 분담이 안정적입니다.

Cleanlab - 라벨 품질 검증

마스크나 클래스 라벨을 다 붙인 뒤에도, 라벨러 간 기준 차이나 단순 실수로 생기는 오류는 남습니다.

Cleanlab은 confident learning이라는 방법론을 기반으로, 이미 학습된 모델의 예측 확률과 실제 라벨을 비교해서 각 이미지에 라벨 품질 점수(label quality score)를 매기는 오픈소스 라이브러리입니다. 점수가 낮을수록 라벨이 틀렸을 가능성이 높다는 뜻이고, 이 점수로 정렬하면 전체 데이터셋을 다시 보지 않고도 검토 우선순위를 정할 수 있습니다.

사용법은 몇 줄이면 충분합니다.

from cleanlab.classification import CleanLearning
from cleanlab.filter import find_label_issues

# out-of-sample 예측 확률(pred_probs)과 라벨(labels)만 있으면 바로 실행 가능
label_issues = find_label_issues(
    labels=labels,
    pred_probs=pred_probs,
    return_indices_ranked_by="self_confidence",  # 의심스러운 순서로 정렬
)

segmentation 데이터에도 같은 개념을 확장해서, 픽셀 단위 라벨의 품질 점수를 매기는 기능도 제공합니다.

실제로 안과 영상(안저 사진, OCT) 데이터셋에 이 방식을 적용한 연구에서는, 자동으로 제안된 라벨 교정안이 대부분(약 87~98%) 정확하게 반영되었고 놓치거나 잘못 교정한 비율은 한 자릿수 초반에 그쳤다는 결과가 보고된 바 있습니다. 즉 "사람이 전부 다시 보지 않아도, 자동 교정만으로도 상당 부분 해결된다"는 뜻입니다.

여기서 사람이 반드시 남겨야 하는 부분: 라벨링 기준(등급 경계를 어떻게 나눌지) 자체를 정하는 일은 임상 도메인 지식이 필요한 판단입니다.

SAM과 Cleanlab은 "이미 정해진 기준을 일관되게, 빠르게 적용" 하는 데 강하지만, 기준 자체를 만들게 하면 그럴듯하지만 근거 없는 경계를 만들어낼 위험이 있습니다.

2. 파이프라인 개발: Cursor, GitHub Copilot, Claude Code

전처리, 증강, 학습/검증 스플릿, 로깅처럼 패턴화된 코드는 AI 코딩 어시스턴트로 빠르게 만들 수 있습니다.
2026년 현재 이 영역의 대표 도구 세 가지는 성격이 뚜렷하게 다릅니다.

Cursor

VS Code를 포크한 AI native IDE로, 코드 자동완성(Tab)뿐 아니라 자연어 지시 하나로 여러 파일에 걸친 변경을 계획·실행·검증하는 Agent Mode가 핵심 기능입니다.

2026년 4월 나온 Cursor 3부터는 최대 8개의 agent를 서로 독립된 Git 브랜치에서 병렬로 돌릴 수 있고, 2026년 2분기에 나온 Cursor 2.1은 실행 전에 변경 계획을 먼저 보여주는 2단계 Plan Mode와, 코드 리뷰를 대신해주는 인라인 리뷰 패널을 추가했습니다. ML 파이프라인처럼 여러 파일(데이터 로더, 학습 스크립트, 설정 파일)에 걸친 변경을 한 번에 처리해야 할 때 특히 유리합니다.

GitHub Copilot

특정 에디터에 얹는 확장 형태로, Cursor 대비 여러 파일에 걸친 편집 능력은 다소 약하지만 GitHub 생태계(이슈 → PR → 리뷰)와의 통합이 매끄럽고 가격도 상대적으로 저렴합니다. 기업 IP 보증(indemnity)이 필요한 조직에서 선호되는 편입니다.

Claude Code

터미널 기반 agent로, IDE가 아니라 명령줄에서 동작합니다. 실무에서 흔한 조합은 "평소 코드 편집은 Cursor, 코드베이스 전체 분석이나 대규모 리팩터링처럼 오래 걸리는 자율 작업은 Claude Code"로 나눠 쓰는 방식입니다.

실제 프롬프트 전략

ML 파이프라인 코드를 짤 때는 요청을 좁게 던질수록 결과가 좋습니다.

나쁜 예: "학습 스크립트 짜줘"
좋은 예: "기존 train.py 구조를 유지한 채, 클래스 불균형 처리를 class_weight에서 focal loss로 바꿔줘. 다른 하이퍼파라미터는 건드리지 말고."

Cursor의 .cursorrules 파일에 프로젝트의 코딩 컨벤션(디렉터리 구조, 네이밍, 즐겨 쓰는 라이브러리)을 미리 적어두면, 매 요청마다 맥락을 반복 설명하지 않아도 됩니다.

AI 코딩 어시스턴트에게 맡기기 어려운 결정

라벨이 순서형(ordinal) 데이터일 때 이를 손실 함수에 어떻게 반영할지
클래스 간 오분류의 임상적 비용이 서로 다를 때 평가지표를 어떻게 설계할지

AI 어시스턴트는 "이런 패턴의 코드는 보통 이렇게 짠다"는 통계적 패턴에 기반해 그럴듯한 구현을 빠르게 내놓습니다.

그러나 문제는 의료 데이터처럼 라벨의 성격 자체가 일반적인 분류 문제와 다를 때, 표준적인 접근을 그대로 제안하고 넘어가는 경향이 있다는 점입니다. 실제로 여러 AI 코딩 어시스턴트 리뷰에서 공통으로 지적되는 한계도 이 지점입니다. 코드는 자신 있게 내놓지만, 기존 설계 전제 자체가 잘못됐을 때 그 전제를 의심하기보다는 전제 안에서 계속 패치를 시도하는 경향이 있다는 것입니다.

그래서 문제 정의와 직결된 설계는 사람이 먼저 하고, AI에게는 그 설계를 구현하는 역할을 맡기는 순서가 안전합니다.

3. 실험 추적: W&B Sweeps와 MLflow

모델 실험을 여러 번 돌리면 "이번엔 뭘 바꿨고 결과가 어떻게 달라졌는지"를 계속 추적해야 합니다.

이 영역에서는 Weights & Biases(W&B)와 MLflow가 표준으로 자리 잡았습니다.

W&B Sweeps

W&B Sweeps로 하이퍼파라미터 탐색을 자동화하는 코드는 이렇게 생겼습니다.

import wandb

sweep_config = {
    "method": "bayes",  # grid, random, bayes 중 선택
    "metric": {"name": "val_loss", "goal": "minimize"},
    "parameters": {
        "learning_rate": {"min": 1e-5, "max": 1e-2},
        "batch_size": {"values": [8, 16, 32, 64]},
    },
}

sweep_id = wandb.sweep(sweep_config, project="ibd-severity-classifier")

def train():
    wandb.init()
    config = wandb.config
    # config.learning_rate, config.batch_size로 학습 루프 실행
    ...
    wandb.log({"val_loss": val_loss, "val_accuracy": val_acc})

wandb.agent(sweep_id, function=train, count=50)

탐색 범위를 YAML(또는 위처럼 딕셔너리)로 정의해두면, 그리드·랜덤·베이지안 탐색을 자동으로 돌리면서 분산된 실험 agent를 관리해줍니다.

아래 그림처럼 학습률·배치 크기 조합별로 검증 손실이 어떻게 바뀌는지 한눈에 볼 수 있고, 베이지안 방식은 이전 실험 결과를 참고해서 다음에 시도할 조합을 점점 더 좋은 방향으로 좁혀갑니다.

W&B의 Artifacts 기능은 데이터셋·모델 체크포인트 버전을 자동으로 추적하고, 어떤 실험이 어떤 데이터 버전에서 나왔는지 계보(lineage)를 남겨줍니다. 규제가 있는 분야에서는 이 계보 추적이 "있으면 좋은 기능"이 아니라 사실상 필수 요건에 가깝습니다.

MLflow

MLflow는 오픈소스 기반으로 모델 레지스트리와 계보 관리에 강점이 있어서, 특정 벤더에 종속되지 않는 것이 중요한 조직이나 온프레미스 환경이 필요한 조직에서 자주 선택됩니다. W&B가 UX와 협업 기능에서 앞서지만, 데이터 거주(data residency) 요건이 엄격한 환경에서는 MLflow의 완전 자체 호스팅 옵션이 더 매력적일 수 있습니다.

여기에 LLM을 더 얹는 방식도 늘고 있습니다. 실험 로그와 지표를 정리해서 "이전 대비 무엇이 개선/악화 됐는지"를 짧은 리포트로 요약하게 시키는 식입니다. 다만 의료 데이터는 클래스 불균형이 심하고 샘플 수 가 제한적인 경우가 많아서, 지표 하나가 좋아졌다고 곧바로 의미 있는 개선이라 보기는 어렵습니다.

그래서 어디서 멈춰야 하는가

세 도구를 다 붙여놓고 나면 "이제 AI가 다 해주는 거 아닌가" 싶은 착각이 들기 쉽습니다. 그런데 세 단계를 관통하는 공통된 함정이 있습니다.

첫째, 그럴듯함과 정확함은 다른 문제입니다.

SAM은 자연스러운 마스크를, AI 코딩 어시스턴트는 자연스러운 코드를, LLM 리포트 요약은 자연스러운 문장을 만듭니다. 세 경우 모두 "자연스럽다"는 것이 "맞다" 는 것을 보장하지 않습니다. 특히 의료 데이터에서는 이 간극이 실제 환자에게 영향을 줄 수 있는 판단으로 이어질 수 있습니다.

둘째, AI는 문제 정의를 의심하지 않습니다.

라벨링 기준, 손실 함수 설계, 지표 해석은 모두 "이 문제를 어떻게 정의할 것인가"의 문제입니다. AI 도구들은 이미 정의된 문제 안에서 빠르고 일관되게 작업하는 데 강하지만, 그 정의 자체가 우리 데이터·우리 임상 맥락에 맞는지는 사람만이 판단할 수 있습니다.

셋째, 맥락을 넘겨줄수록 결과가 좋아집니다.

SAM에게 텍스트 프롬프트로 명확한 개념을 주고, AI 코딩 어시스턴트에게 .cursorrules나 기존 코드로 컨벤션을 알려주고, 실험 리포트 요약에 "이전 실험과 비교해서" 같은 구체적인 기준을 줄수록 결과물의 품질이 확연히 달라집니다.

결국 AI 도구 활용의 병목은 모델 성능이 아니라, 우리가 얼마나 명확한 맥락과 기준을 제공하느냐에 있습니다.

글을 마치며

결국 AI 도구를 잘 쓴다는 건 "얼마나 많이 맡기느냐"보다 **"어느 결정 지점까지 맡길 수 있는가"**를 단계별로 명확히 나누는 일입니다.

특히 판단 하나가 실제 환자에게 영향을 줄 수 있는 의료 데이터 분야에서는, 이 경계를 계속 다시 확인하면서 도구를 골라 쓰는 게 맞다고 생각합니다.