SWARM: Natera가 실험실 장비 고장 티켓에 에이전트 진단서를 먼저 붙인 방법

Natera는 실험실 장비 고장 티켓이 들어오면 엔지니어가 열어 보기 전에 에이전트가 진단 보고서를 먼저 붙이게 했고, 평균 첫 응답이 17.4시간에서 약 8분으로 줄었습니다. 따라 하려면 모델보다 세 가지가 먼저 있어야 합니다. 장비 계열마다 빠짐없이 모은 문서, 틀린 진단을 부품 단위로 추적할 수 있는 스킬 라이브러리, 엔지니어의 실제 수리 결과로 매번 채점하는 평가 루프입니다.

요약

Natera는 무세포 DNA(cfDNA, 혈액 속에 떠다니는 DNA 조각) 검사를 하는 진단 기업입니다. 실험실에는 여러 계열의 장비가 돌고, 장비가 멈추면 검체 처리와 환자 결과 보고가 함께 늦어집니다. 장비 계열마다 고장 양상, 제조사 문서, 해결법이 다른데 서비스 엔지니어링은 표준 절차서보다 숙련 기술자의 경험에 기대 왔습니다. 숙련자가 떠나면 그 지식도 함께 사라졌습니다. 세 개의 Jira 큐에 하루 65건이 넘는 티켓이 쌓였고 평균 첫 응답은 17.4시간이었으며, 채용으로는 따라잡지 못했습니다. Natera의 Ariel Jirau와 AWS의 Tamara Gagliardi, Veronica Rule이 2026년 11월 12일 AWS 블로그에 쓴 글은 이 문제를 풀려고 만든 SWARM(Systematic Workflow Analytics and Resolutions Manager)의 설계를 설명합니다. SWARM은 Amazon Bedrock AgentCore(에이전트의 실행, 메모리, 신원, 관측을 맡아 주는 AWS 관리형 서비스) 위에서 돌고, 두 에이전트가 스킬 라이브러리 하나를 나눠 씁니다. swarm-agent는 새 티켓마다 진단 보고서를 써서 붙이고, swarm-hive는 엔지니어가 사진을 올려 가며 후속 질문을 하는 대화 창구입니다.

티켓 접수에서 엔지니어 착수까지. 보고서는 엔지니어가 티켓을 열기 전에 붙습니다.

90일 운영 기간에 Jira 티켓 메타데이터로 잰 평균 첫 응답은 약 8분이 됐습니다. 약 130배 빨라진 셈입니다. 티켓의 96.2%는 엔지니어가 진단을 시작하기 전에 SWARM 보고서를 받았습니다. 저자들은 그 이유를 모델 성능보다 운영 설계에서 찾습니다. 장비 메타데이터 없이 일반 검색을 붙인 초기 시제품은 결과가 들쭉날쭉했고, 표와 도식이 많은 장비 문서를 위한 파싱 파이프라인을 따로 만들고 나서야 나아졌습니다. 진단 논리는 프롬프트에 묻지 않고 버전 관리되는 스킬 33개로 나눠, 틀린 진단이 어느 스킬에서 나왔는지 찾을 수 있게 했습니다. 처리한 티켓은 모두 엔지니어가 기록한 실제 수리 결과와 맞춰 채점합니다. 점수가 가장 낮던 장비 계열은 빠진 제조사 매뉴얼을 넣는 것만으로 정확도가 71%에서 75%로 올랐습니다. 아래에서는 이 구조를 여섯 가지 메커니즘으로 나눠 보고, 장비 정비나 기술 지원 티켓에 같은 구조를 옮길 때 필요한 기술·현업 디테일을 덧붙입니다.

평균 첫 응답 시간 비교(분, 0 기준). 약 130배 빨라졌고 티켓의 96.2%가 엔지니어 검토 전에 보고서를 받았습니다.

핵심 메커니즘

Two Runtimes, One Skill Library: 일괄 처리용과 대화용 에이전트를 나눈다

SWARM은 같은 스킬을 쓰는 에이전트 둘을 서로 다른 런타임(에이전트가 실행되는 환경)에 둡니다. swarm-agent는 처리량을 맡습니다. 티켓의 장비 종류와 증상을 보고 쓸 스킬을 고른 뒤 지식 베이스를 조회해 HTML 보고서를 만듭니다. 보고서에는 가장 유력한 원인 가설(lead cause hypothesis), 순위를 매긴 조치 단계, 신뢰도 라벨이 들어갑니다. 보고서는 Amazon S3에 저장되고 몇 분 안에 Jira 티켓에 링크됩니다. swarm-hive는 깊이를 맡습니다. 엔지니어가 후속 질문을 던지고, 이미지를 올리고, 다른 조치 경로를 따져 보는 곳입니다. AgentCore Memory가 엔지니어별 맥락을 세션을 넘어 기억하고, 자유 입력은 Amazon Bedrock Guardrails(입력·출력 내용을 거르는 기능)를 거칩니다. 둘을 나눈 이유는 배경 분석과 대화형 작업이 요구하는 지연 시간과 맥락이 달라서입니다. 모든 건을 빠르게 훑는 일과 어려운 건 하나를 깊게 파는 일이 함께 있을 때 이렇게 나눕니다. 둘 중 하나만 필요하면 런타임 하나로 시작해도 됩니다. 가상 예시를 들면, 원심분리기 진동 경보 티켓에 swarm-agent가 “로터 불균형”을 첫 가설로 붙이고, 현장 엔지니어는 swarm-hive에 베어링 사진을 올려 다른 원인을 확인하는 식입니다.

두 런타임은 스킬 33개를 함께 쓰고, 지연 시간과 필요한 맥락에 따라 나뉩니다.

Versioned Skill Library: 진단 논리를 프롬프트 대신 시험할 수 있는 부품으로

스킬은 에이전트가 불러 쓰는 기능 단위입니다. Natera는 진단 논리를 시스템 프롬프트에 지시로 적는 대신 버전 관리되는 스킬 라이브러리로 만들었습니다. 스킬은 33개이고, 지원하는 장비 계열 전체를 덮는 장비별 스킬 24개와 장비와 상관없이 쓰는 공통 워크플로 스킬 9개로 나뉩니다. 각 스킬은 정해진 인터페이스를 갖고 따로 시험할 수 있으며, 시스템 전체와 같은 평가 기준을 적용받습니다. 저자들은 스킬을 운영 소프트웨어처럼 다룬다고 설명합니다. 일의 성격에 따라 실행 방식도 나눕니다. Jira 필드 파싱이나 HTML 보고서 서식처럼 같은 입력에 같은 결과가 나와야 하는 일은 결정적인 Python 코드가 맡습니다. 증상 해석, 제조사 문서와 맞춰 보기, 진단 서술처럼 해석이 필요한 일은 LLM 스킬이 맡습니다. 이렇게 하면 진단이 틀렸을 때 어느 스킬이 원인인지 짚을 수 있고, 그 스킬만 고쳐 다시 시험할 수 있습니다. 장비 종류가 하나뿐이고 질문 유형이 단순하다면 이런 분해 없이 프롬프트 하나로 충분할 수 있습니다.

스킬 33개 = 장비별 24 + 공통 워크플로 9. 같은 입력에 같은 결과가 필요한 일은 Python, 해석이 필요한 일은 LLM이 맡습니다.

Equipment-aware Document Pipeline: 장비 문서에 맞춘 검색 기반

SWARM의 맥락 층(context layer)은 제조사 매뉴얼, 과거 티켓, 운영 데이터입니다. 처음에는 장비 메타데이터 없이 일반 검색을 붙였는데 결과가 일정하지 않았습니다. 그래서 기술 장비 문서 전용 파이프라인을 만들었습니다. 임베딩(문장을 의미 검색용 숫자 벡터로 바꾸는 것)은 Amazon Titan Text Embeddings로 만들고, 검색 증강 생성(RAG)은 Amazon Bedrock Knowledge Bases가 관리합니다. 청크(문서를 잘라 넣는 단위)는 1,000토큰, 앞뒤 겹침은 150토큰이고, 토큰 수는 tiktoken의 cl100k_base 인코딩으로 셉니다. 임베딩은 100건씩 묶어 보내 색인 속도와 API 호출 한도 사이에서 균형을 잡습니다. 표와 도식이 많은 문서는 기본 청킹보다 전용 파싱이 더 잘 맞았습니다. 새 문서나 개정 문서가 들어오면 그 부분만 다시 처리해 운영을 멈추지 않고 색인을 갱신합니다. 저자들은 청크 크기와 겹침을 정답이 있는 값이 아니라 문서 구조에 따라 조정하는 값으로 다루라고 권합니다.

Natera가 밝힌 문서 파이프라인 설정값. 청크 크기와 겹침은 문서 구조에 따라 조정하는 값으로 둡니다.

Event-driven Intake: 티켓 시스템과 에이전트를 큐로 떼어 놓는다

티켓 수집은 이벤트 방식으로 짰습니다. Amazon EventBridge Scheduler가 정해진 주기로 AWS Lambda 함수를 깨우고, 이 함수가 Jira를 조회합니다. webhook(티켓 시스템이 변경 때마다 먼저 알려 주는 방식)을 설정하지 않아도 됩니다. 확인된 티켓은 Amazon SQS 큐에 들어가 안정적으로 전달됩니다. Amazon DynamoDB는 ticket ID를 파티션 키로 써서 같은 티켓을 두 번 처리하지 않게 막고, TTL(일정 시간이 지나면 기록을 자동 삭제하는 설정)로 오래된 기록을 지웁니다. 같은 테이블에 실행별 상태, 비용, 토큰 사용량도 남겨 평가 루프에서 씁니다. 큐를 사이에 두면 Jira가 잠시 멈춰도 에이전트 런타임은 영향을 받지 않습니다. 하루 수십 건 이상 티켓이 들어오고 원천 시스템을 고치기 어려운 환경이라면 이 구조가 맞습니다.

티켓 수집 경로. 큐를 사이에 두어 Jira가 잠시 멈춰도 에이전트 쪽은 영향을 받지 않습니다.

Continuous Evaluation Loop: 처리한 티켓마다 채점하고 고친다

평가는 배포 때 한 번이 아니라 처리한 티켓마다 돕니다. 에이전트는 원인 가설, 순위 매긴 조치 단계, 스스로 매긴 신뢰도 라벨(High, Moderate, Low)을 냅니다. 엔지니어는 실제로 찾은 원인과 실제로 한 조치를 기록합니다. 평가자는 각 응답을 Accurate(정확), Partial(부분), Wrong(오답)으로 매기고 장비 계열별로 나눠 집계합니다. 성적이 낮은 곳이 보이면 원인을 살펴 고치는데, 대개는 지식 베이스를 보강하는 일입니다. 그다음 평가 세트를 다시 돌려 실제로 나아졌는지 확인합니다. 이 루프를 받치는 것이 관측(observability) 설계입니다. Natera는 첫 운영 배포 전에 이것부터 만들었습니다. Amazon CloudWatch에 실행마다 검색 가능한 로그를 남기고, AWS X-Ray로 티켓 접수부터 보고서까지 한 번의 실행을 추적하며 도구 호출마다 시간과 비용을 기록합니다. 그래서 어느 스킬이 느리거나 비싼지 보입니다. 실패는 Amazon SNS 이메일 알림으로, 진행 상황은 Slack 트래커로 팀에 실시간으로 보입니다.

처리한 티켓마다 도는 평가 루프. 5단계에서 개선이 확인되면 다시 1단계로 돌아갑니다.

Keyless, PHI-free Deployment: 장기 키 없이 배포하고 환자 정보는 들이지 않는다

임상 실험실 시스템이라 보안과 규제 요건이 설계 초기부터 들어갔습니다. 배포 파이프라인인 GitLab CI는 OIDC(외부 시스템이 짧게 쓰는 신원 토큰으로 인증하는 표준)로 IAM 신원 공급자에 인증하고, AWS STS가 배포 범위로 좁힌 단기 자격 증명을 발급합니다. 파이프라인에 장기 키를 저장하지 않습니다. IAM은 구성 요소마다 최소 권한만 주고, 트래픽은 VPC 사설 서브넷과 VPC 엔드포인트로 공용 인터넷을 거치지 않게 합니다. 남은 몇 개의 자격 증명은 AWS Secrets Manager가 30일마다 자동으로 바꿉니다. 규제 측면에서 SWARM은 BAA(HIPAA상 의료 데이터 처리 위탁 계약) 아래 HIPAA 대상 AWS 서비스에서 돌고, 모든 에이전트 호출을 검색 가능한 감사 로그로 남깁니다. 환자를 식별할 수 있는 정보는 벡터 색인에도 언어 모델에도 들어가지 않습니다. 티켓에는 장비와 작업 흐름 메타데이터만 담깁니다. 저자들은 지식 베이스를 설계하기 전에 BAA 범위와 데이터 분리 요건부터 확인하라고 권합니다.

보안·규제 설계 네 영역. 티켓에는 장비와 작업 흐름 메타데이터만 들어가고 모든 호출은 감사 로그로 남습니다.

통념과 다른 주장

흔히 이렇게 봅니다에이전트의 진단 정확도가 더 오르지 않으면 더 좋은 모델로 바꾸거나 프롬프트를 손봅니다.

저자는 이렇게 봅니다정확도가 멈추면 모델을 손대기 전에 데이터 커버리지부터 봅니다. 진단을 놓치는 가장 흔한 원인은 문서 공백입니다.

근거점수가 가장 낮던 장비 계열에 빠진 제조사 매뉴얼을 넣자 모델을 바꾸지 않고도 정확도가 71%에서 75%로 올랐습니다. Jirau는 "Diagnostic accuracy is a data quality problem first"라고 정리합니다.

흔히 이렇게 봅니다에이전트가 할 일은 시스템 프롬프트에 지시문으로 적어 둡니다.

저자는 이렇게 봅니다진단 논리는 버전 관리되는 스킬로 나누고 운영 소프트웨어처럼 시험합니다. 그래야 틀린 진단을 특정 스킬까지 거슬러 찾을 수 있습니다.

근거SWARM의 스킬 33개는 각각 인터페이스가 정해져 있고 따로 시험할 수 있으며, 시스템 전체와 같은 평가 기준을 적용받습니다.

흔히 이렇게 봅니다에이전트 평가는 배포 전에 시험 세트로 한 번 통과시키면 됩니다.

저자는 이렇게 봅니다평가는 처리하는 모든 티켓에서 계속 돌아야 합니다. 엔지니어가 확인한 실제 결과가 채점 기준이 됩니다.

근거Natera는 엔지니어가 기록한 실제 원인과 조치로 응답을 장비 계열별로 채점하고, 고친 뒤에는 평가 세트를 다시 돌려 개선을 확인합니다.

세 가지 통념과 Natera의 선택. 오른쪽 칸이 원문이 밝힌 방식입니다.

저자가 든 사례

SWARM 90일 운영: 첫 응답 17.4시간에서 약 8분으로

상황: 3개 Jira 큐에 하루 65건 넘게 장비 지원 티켓이 들어왔고 평균 첫 응답은 17.4시간이었습니다. 채용으로는 차이를 메우지 못했습니다.
한 일: swarm-agent가 모든 신규 티켓에 진단 보고서를 자동으로 만들어 붙이게 했습니다.
결과: 90일 운영 기간 Jira 메타데이터 기준으로 평균 첫 응답이 약 8분(약 130배 단축)이 됐고, 티켓의 96.2%가 엔지니어 검토 전에 보고서를 받았습니다.
연결: Two Runtimes, Event-driven Intake.

자동 1차 보고서 비율(0 기준). 엔지니어가 진단을 시작하지 않아도 보고서가 먼저 붙었습니다.

점수가 가장 낮던 장비 계열: 매뉴얼만 채워 71%에서 75%로

상황: 장비 계열별 채점에서 한 계열의 정확도가 가장 낮았습니다. 계열 이름은 원문에서 밝히지 않았습니다.
한 일: 그 계열에 빠져 있던 제조사 매뉴얼을 지식 베이스에 넣었습니다. 모델은 바꾸지 않았습니다.
결과: 정확도가 71%에서 75%로 올랐습니다.
연결: Equipment-aware Document Pipeline, Continuous Evaluation Loop.

최하위 장비 계열의 진단 정확도(0 기준). 바꾼 것은 지식 베이스의 문서뿐입니다.

신뢰도 라벨 보정: High만 뚜렷이 높았다

상황: 기준 평가는 티켓 524건으로 했습니다. 이 가운데 신뢰도 라벨과 엔지니어가 확인한 해결 기록이 모두 있는 건은 269건이었고, 나머지는 라벨이 none이거나 확인된 해결이 없었습니다.
한 일: 269건을 에이전트가 스스로 매긴 라벨별로 나눠 정확도를 비교했습니다.
결과: High는 154건에서 74%, Moderate는 78건에서 65%, Low는 37건에서 65%였습니다. Moderate와 Low가 같게 나왔지만 Low는 표본이 작아 통계적 결론을 내리기 어렵고, 팀은 데이터가 쌓이면 둘이 벌어질 것으로 봅니다. 지금 엔지니어가 보고서를 얼마나 믿을지 정할 때 실제로 쓸 만한 신호는 High입니다.
연결: Continuous Evaluation Loop.

신뢰도 라벨별 정확도(0 기준). 524건 중 라벨과 엔지니어 검증 해결이 모두 있는 269건이 대상입니다.

기술 디테일: 같은 구조로 첫 프로토타입을 만들려면

아래 스키마, 설정값, 기준은 원문에 없는 내용입니다. 비슷한 시스템을 처음 만들 때 필요한 것을 새로 정리했습니다.

보고서를 구조화 출력으로 받으려면 (Two Runtimes, Versioned Skill Library와 연결) LLM 스킬은 HTML이 아니라 고정 스키마의 JSON을 내게 하고, 서식은 Python 스킬이 맡깁니다. 원문의 결정적·LLM 분담을 출력 단계까지 그대로 적용하는 방식입니다. 스키마 검증에 실패하면 한 번만 다시 부르고, 그래도 실패하면 보고서 대신 confidence: "none"으로 남겨 엔지니어에게 넘깁니다. 진단 스킬의 temperature는 0~0.2로 낮게 둡니다.

{
  "ticket_id": "LAB-12345",
  "instrument_family": "centrifuge",
  "symptoms": ["진동 경보", "회전 중 정지"],
  "lead_cause": {
    "hypothesis": "로터 불균형",
    "evidence": [{"doc_id": "vendor-manual-cf-07", "section": "4.2", "chunk_id": "c-0193"}]
  },
  "steps": [
    {"rank": 1, "action": "튜브 무게 균형 확인", "check": "균형 후 재시작 시 경보 여부"},
    {"rank": 2, "action": "로터 장착 상태 점검", "check": "고정 나사 토크"}
  ],
  "confidence": "High",
  "skills_used": [{"name": "cf-vibration", "version": "1.4.0"}],
  "kb_version": "2026-11-10",
  "tokens": 8421,
  "cost_usd": 0.06
}

evidence가 비어 있으면 confidence를 High로 쓰지 못하게 검증 규칙을 둡니다. skills_used와 kb_version이 있어야 나중에 틀린 진단을 특정 스킬과 특정 문서 상태까지 거슬러 갈 수 있습니다.

실제로 돌릴 때 권하는 출력 경로(새로 작성). 판단은 JSON까지, 서식은 Python이 맡습니다.

스킬을 따로 시험하려면 (Versioned Skill Library와 연결) 스킬마다 매니페스트를 둡니다. 필드는 name, version, kind(python 또는 llm), instrument_family(공통 스킬은 비움), input_schema, output_schema, eval_set_id 정도면 됩니다. 장비별 스킬은 그 계열의 해결된 과거 티켓 20~30건을 골든 세트로 묶어, 스킬 버전을 올릴 때마다 이 세트를 돌립니다. 스킬 선택은 티켓의 장비 계열 필드로 먼저 결정적으로 거르고, 남은 후보 가운데에서만 LLM이 고르게 하면 엉뚱한 계열의 스킬을 부르는 일이 줄어듭니다.

문서를 장비별로 검색하려면 (Equipment-aware Document Pipeline과 연결) 청크마다 instrument_family, model, doc_type(manual, service_bulletin, past_ticket), doc_version, page를 메타데이터로 붙이고, 검색할 때 티켓의 장비 계열로 먼저 거릅니다. 청크 설정은 Natera의 1,000/150에서 시작하되, 표가 많은 문서 묶음에는 더 작은 청크를 따로 시험해 평가 세트 점수로 고릅니다. 무엇보다 먼저 계열 × 문서 종류 커버리지 표를 만들어 0인 칸을 찾습니다. 원문의 71%→75% 사례처럼 그 칸을 채우는 것이 모델을 바꾸는 것보다 싸고 빠를 수 있습니다.

가상 예시: 계열 × 문서 종류 커버리지 표. 0이 있는 칸부터 채웁니다.

평가 기록을 남기려면 (Continuous Evaluation Loop와 연결) 티켓을 닫을 때 engineer_root_cause, engineer_fix를 필수 필드로 받고, 채점 결과는 verdict(Accurate, Partial, Wrong), grader(human 또는 llm), instrument_family, confidence, skill_versions, kb_version과 함께 저장합니다. 채점을 LLM에 맡긴다면 같은 건을 3번 채점해 다수결을 쓰고, 매주 10~20%는 사람이 다시 채점해 어긋남을 봅니다. Partial을 정확도에 어떻게 넣을지(제외, 0.5점, 정답 취급)는 시작 전에 정해 두어야 계열 간 비교가 흔들리지 않습니다. 원문의 Low 라벨(37건)처럼 표본이 작은 칸은 결론을 미루고, 대략 50건이 넘을 때 판단하는 식으로 기준을 정합니다.

대화형 창구를 붙이려면 (Two Runtimes와 연결) swarm-hive 세션은 티켓 ID로 시작하게 해, 첫 턴에 swarm-agent 보고서 JSON을 맥락으로 넣습니다. 그래야 엔지니어가 처음부터 다시 설명하지 않습니다. 메모리는 엔지니어 ID 단위로 나누고, 남길 항목을 장비 계열, 이미 시도한 조치, 선호하는 보고 형식처럼 좁게 정합니다. 사진은 이미지를 읽을 수 있는 모델에 보내되 원본은 S3에 티켓 ID로 저장해 감사 로그와 묶습니다. 대화에서 새로 확인된 원인은 티켓의 engineer_root_cause 초안으로 제안만 하고, 확정은 엔지니어가 합니다.

비용과 지연을 스킬 단위로 보려면 (Event-driven Intake, Continuous Evaluation Loop와 연결) 실행 하나를 trace 하나로, 도구 호출 하나를 span 하나로 기록하고, span마다 스킬 이름과 버전을 태그로 답니다. DynamoDB의 실행 기록에서 실행 시간과 비용을 꺼내, 예를 들어 실행이 10분을 넘거나 비용이 지난 7일 평균의 3배를 넘으면 알림을 보내는 식으로 기준을 둡니다.

실패 상황	대응
해당 계열 문서가 없음	`evidence` 빈 배열, `confidence` Low, 보고서에 “문서 없음” 표시, 커버리지 표에 기록
Jira 장애	SQS에 쌓아 두고 복구 후 처리, 중복은 ticket ID로 차단
같은 티켓 재수집	DynamoDB 조건부 쓰기로 두 번째 실행 차단
티켓에 개인정보가 섞임	수집 Lambda에서 패턴 검사 후 해당 필드 제거, 건수 집계
스킬 버전 교체 후 점수 하락	골든 세트 비교 결과로 이전 버전으로 되돌림

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

아래 역할과 일정은 원문에 없는 내용입니다. 장비 정비나 기술 지원 티켓에 같은 구조를 들이려는 조직이 실제로 돌릴 때 필요한 것을 가상 예시로 정리했습니다.

역할	하는 일	산출물
운영 리더(스폰서)	첫 대상 장비 계열 결정, 진행 판정	대상 범위, 판정 회의록
서비스 엔지니어	보고서 사용, 실제 원인·조치 기록	티켓별 결과 기록
지식 담당	계열별 매뉴얼·서비스 공지 수집과 갱신	커버리지 표
플랫폼 엔지니어	수집 경로, 스킬, 런타임, 관측	동작하는 파이프라인
평가 담당	채점 규칙, 주간 계열별 집계	주간 성적표
품질·규제 담당	개인정보 차단, 감사 로그, 위탁 계약 범위	규제 점검표

시작 전 준비물: 최근 3~6개월 동안 닫힌 티켓과 그 해결 메모, 장비 목록과 계열 분류, 계열별 제조사 매뉴얼과 서비스 공지, 티켓 큐의 필드 정의, 지금의 평균 첫 응답 시간(비교 기준)을 모읍니다. 해결 메모가 비어 있는 티켓이 많다면 평가 세트를 만들기 전에 그것부터 보강해야 합니다.

가상 예시: 8주 도입 일정. 1~2주에 평가 세트를, 3~4주에 결과 기록 필드를 함께 만들고 6주 끝에 판정 회의를 엽니다.

인터뷰·확인 질문

이 장비 계열 티켓을 열면 가장 먼저 무엇을 확인합니까?
어떤 매뉴얼이나 공지를 펼칩니까? 그 문서는 어디에 있고 누가 최신으로 유지합니까?
작년에 해결하는 데 가장 오래 걸린 고장은 무엇이었고, 결국 무엇이 원인이었습니까?
숙련 엔지니어 한 명이 빠지면 처리가 가장 먼저 막히는 계열은 어디입니까?
보고서의 첫 가설이 틀렸을 때 그 사실을 어디에, 어떤 형식으로 남기겠습니까?

진행 판정 기준(가상 예시): 섀도 운영 4주 동안 대상 계열에서 엔지니어 결과 기록률이 80% 이상이고, Accurate 비율이 매주 내려가지 않으며, High 라벨 정확도가 다른 라벨보다 높게 유지되고, 개인정보 유입이 0건이면 다음 계열로 넓힙니다. 결과 기록률이 낮으면 기술보다 기록 절차를 먼저 고칩니다. 평가 루프가 엔지니어의 기록 위에서 돌기 때문입니다.

적용 제언. 반도체·디스플레이 팹 설비, 제약·바이오 품질관리(QC) 장비, 병원 의료기기, 제조 설비 보전, B2B 장비 기술 지원처럼 장비 계열이 여럿이고 숙련자 경험에 기대는 곳이 첫 후보입니다. 순서는 문서 커버리지 감사, 한 계열 섀도 운영, 결과 기록 필드 의무화, 계열 확대입니다. 경영진에게는 응답 시간 단축과 함께 숙련자 퇴직에 대비한 지식 이전 수단이라는 점을 같이 보고하는 편이 좋습니다. Natera의 출발점도 숙련 기술자가 떠나면 지식이 함께 사라진다는 문제였습니다. 첫 투자는 모델 선택이 아니라 문서 정리와 결과 기록에 두는 것이 원문의 경험과 맞습니다.

원문 사례

항목	내용
원문	AWS Machine Learning Blog, 2026년 11월 12일
저자	Ariel Jirau(Natera Principal Software Engineer), Tamara Gagliardi, Veronica Rule(AWS)
회사	Natera, 무세포 DNA(cfDNA) 검사 기업
문제	장비 계열별 지식이 숙련자 개인에게 묶임, 3개 Jira 큐에 하루 65건+, 평균 첫 응답 17.4시간
시스템	SWARM: swarm-agent(자동 보고서) + swarm-hive(대화형), Amazon Bedrock AgentCore
스킬	33개 = 장비별 24 + 공통 워크플로 9, 결정적 작업은 Python, 판단은 LLM
지식 베이스	Titan Text Embeddings, Bedrock Knowledge Bases, 청크 1,000토큰·겹침 150토큰(cl100k_base), 100건 배치
수집	EventBridge Scheduler → Lambda 폴링 → SQS → DynamoDB 중복 제거(ticket ID, TTL)
관측	CloudWatch 로그, X-Ray 도구 호출별 시간·비용, SNS 알림, Slack 트래커
보안·규제	GitLab CI OIDC + STS, VPC, Secrets Manager 30일 교체, HIPAA 대상 서비스·BAA, 환자 식별정보 미유입
성과	평균 첫 응답 약 8분(약 130배), 자동 1차 보고서 96.2%, 90일 운영 기준
정확도	최하위 계열 71%→75%(매뉴얼 추가), 신뢰도별 High 74%(154건)·Moderate 65%(78건)·Low 65%(37건)
공개하지 않은 것	추론에 쓴 언어 모델 이름, 장비 계열 이름

핵심 개념

cfDNA: cell-free DNA. 세포 밖 혈액 속에 떠다니는 DNA 조각으로, Natera 검사의 대상입니다.
Amazon Bedrock AgentCore: 에이전트의 실행 환경, 메모리, 신원, 관측을 관리형으로 제공하는 AWS 서비스입니다. Natera는 별도 실행 계층을 만들지 않으려고 골랐습니다.
AgentCore Memory: 세션이 끝나도 사용자별 대화 맥락을 남겨 다음 세션에서 이어 쓰게 하는 기능입니다.
Lead cause hypothesis: 보고서가 첫 번째로 제시하는 가장 유력한 원인 가설입니다.
Confidence label: 에이전트가 자기 진단에 스스로 매기는 High, Moderate, Low 등급입니다. 실제 정확도와 맞는지 따로 확인합니다.
Deterministic skill: 같은 입력에 늘 같은 결과를 내는 코드 기반 스킬입니다. 파싱과 서식처럼 판단이 필요 없는 일을 맡습니다.
Chunk overlap: 문서를 자를 때 앞 청크 끝부분을 다음 청크 앞에 겹쳐 넣는 길이입니다. 문장이 잘려 의미가 끊기는 것을 줄입니다.
OIDC: OpenID Connect. 배포 도구가 장기 키 대신 짧게 쓰는 신원 토큰으로 클라우드에 인증하는 표준입니다.
BAA: Business Associate Agreement. 미국 HIPAA에서 의료 정보를 다루는 외부 업체와 맺는 위탁 계약입니다.
TTL: Time to Live. 정해진 시간이 지나면 기록을 자동으로 지우는 설정입니다.

내 메모

TODO: 내 생각 추가

원문은 AWS Machine Learning Blog 「How Natera designed an agentic AI system for lab ops with Amazon Bedrock AgentCore」(Ariel Jirau, Tamara Gagliardi, Veronica Rule, 2026.11.12)입니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 저자가 든 사례, 원문 사례 표는 원문이 언급한 내용을 AX Partners가 다시 정리했습니다. 핵심 메커니즘의 원심분리기 예시, 기술 디테일의 JSON 스키마·매니페스트·설정값·실패 대응표, 현업 실행 디테일의 역할·일정·질문·판정 기준, 적용 제언, 모든 인포그래픽은 새로 작성한 것이며 가상 예시는 그렇게 표시했습니다. 원문의 그림과 IAM·DynamoDB 정의 예시는 옮기지 않았습니다. 전체 내용과 아키텍처 그림은 원문에서 볼 수 있습니다.