'제품이 실제 의료 현장에서 안정적으로 동작할 수 있도록 배포·연동·운영·장애 대응한다' 는 공고 문장이 이 도구의 형태(실제 배포 구동 + 로그 진단)를 그대로 정의합니다. AIVIS 가 병원 내부망·폐쇄망·GPU 서버 대응을 강조하는 만큼, 폐쇄망 가정 위에서 실제로 배포를 돌려 본 이 산출물이 그 현장 요건에 붙습니다. 이 포트폴리오가 입증하는 것은 컨테이너·Helm 배포 구성과 로그 기반 장애 진단 자동화이며, 병리·디지털 병리(DICOM·WSI) 도메인 전문성은 주장하지 않습니다. 의료 영상 판독의 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
공고가 병원·연구기관 환경에 AI 솔루션을 배포하고 Docker 기반 추론·API·뷰어 연동 환경을 구축하며 배포 후 로그 분석·트러블슈팅까지 담당한다고 밝힙니다. 배포·구동과 로그 진단을 함께 다루는 이 도구가 그 업무의 축소판입니다.
On-premise 서버와 Cloud 환경 구성, 방화벽·SSL/TLS·도메인·스토리지 환경 분석·설정을 요구합니다. 폐쇄망 가정 배포와 환경 프로필 점검이 그 요건에 붙습니다.
Linux·Docker·REST 기본기와 Kubernetes·Helm·Nginx·모니터링 경험을 우대합니다. 이 도구의 Helm 배포·헬스체크·로그 진단이 그 스택 그대로입니다.
병리 AI 추론 서버(모의 inference·API·뷰어)를 병원 폐쇄망을 가정한 로컬 쿠버네티스에 컨테이너·Helm 으로 실제 배포·구동하고, 배포 후 로그를 규칙으로 진단해 배포를 막는 원인(방화벽·인증서·GPU·스토리지)과 조치를 짚어주는 현장 배포 도구입니다. 배포 성공 여부는 헬스체크로, 장애 원인은 로그 규칙으로 결정합니다.
병원마다 다른 폐쇄망·방화벽·GPU 환경에 AI 서버를 설치하며 로그를 뒤져 무엇이 배포를 막는지 매번 손으로 찾던 현장 엔지니어입니다. 배포를 실제로 한 번 돌려 보고, 실패하면 원인과 조치를 로그 근거로 바로 받고 싶은 사람입니다.
폐쇄망을 가정한 로컬 쿠버네티스에 실제로 배포·구동해 헬스체크로 성공을 확인하고 배포 후 로그의 장애 원인을 규칙으로 매핑하면, 현장 배포에서 반복되는 방화벽·인증서·GPU 문제를 재현·진단하는 흐름을 혼자서도 돌릴 수 있습니다.
모의 추론·API·뷰어를 컨테이너로 만들어 로컬 쿠버네티스(kind/minikube)에 Helm 으로 실제 배포·구동하고, 배포 후 로그를 규칙으로 진단하는 콘솔까지 묶은 완결품입니다. 폐쇄망은 네트워크 격리 설정으로 가정합니다.
같은 Helm 차트를 AWS(EKS 가정)로 배포해 운영하고, 라벨링한 로그 정답표 대비 장애 원인 진단 일치율 리포트와 인증서·GPU·방화벽 경계 케이스 회귀 테스트가 남은 상태입니다.
Prometheus·Grafana 로 추론·GPU 지표를 수집하고, 사이트별 환경 프로필(방화벽·인증서·스토리지)을 배포 전에 점검해 차단 요인을 미리 리포트하는 흐름이 붙은 상태입니다.
폐쇄망 가정 로컬 클러스터에 Helm 으로 배포해 헬스체크 통과와 뷰어 연동까지 실제로 구동되는 흐름을 시연합니다.
배포 후 로그의 장애 원인 진단이 라벨 정답표와 일치함을 전수 채점으로 보여줍니다(표본: 로그 60건, 자가 라벨, 원인 분류 일치율 기준).
일부러 만든 인증서 오류·GPU 미인식·방화벽 차단·스토리지 부족 로그 30종을 넣어도 진단 형식이 깨지지 않고 원인·조치가 근거 로그를 인용함을 보여줍니다.
위 배포·진단은 작성자가 만든 모의 서버와 더미 로그 기준이라 성능 증명이 아니라 데모 조건 동작이며, 실제 병원 폐쇄망과 GPU 서버에서의 안정성은 에이비스의 현장 환경이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
배포·진단은 작성자가 만든 모의 서버와 더미 로그 기준의 자가 검증이라 성능 증명이 아닙니다. 면접에서는 실제 구동 데모와 검증 구조로 솔직하게 설명합니다.
장애를 내가 심었으니 규칙이 잘 잡는 게 당연해지는 함정이 있어, 규칙으로 안 잡히는 복합 장애와 정상인데 경고처럼 보이는 로그를 더미에 일부러 섞습니다.
실제 병원 폐쇄망·보안 심사·GPU 드라이버 조합은 재현 범위 밖이라, 로컬·AWS 가정과 달라지는 현장 변수는 도입 단계 과제로 분리합니다.
DICOM·WSI 뷰어 실연동과 의료 데이터 규정 준수는 모의 뷰어로 대체했으므로, 실연동은 도입 단계 과제로 분리해 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
배포 전 환경 점검과 로그 진단의 맥락이 되는 사이트 환경 프로필입니다. 결측·자가서명 인증서·GPU 부재를 일부러 담아 배포 분기를 시험합니다.
| site_id | deploy_target | gpu | firewall | tls | storage_gb | closed_network |
|---|---|---|---|---|---|---|
| H-01 | on_prem | NVIDIA A100 | true | valid | 2,000 | true |
| H-02 | on_prem | — | true | self_signed | 500 | true |
| H-03 | aws | NVIDIA T4 | false | valid | 1,000 | false |
| H-04 | on_prem | NVIDIA A100 | true | missing | — | true |
| H-05 | gcp | NVIDIA L4 | false | valid | 800 | false |
다음 JSON Schema 를 그대로 만족하는 사이트 환경 프로필 행을 25개 더 만들어 주세요: {"type":"object","properties":{"site_id":{"type":"string"},"deploy_target":{"type":"string","enum":["on_prem","aws","gcp","azure"]},"gpu":{"type":["string","null"]},"firewall":{"type":"boolean"},"tls":{"type":["string","null"],"enum":["valid","self_signed","missing",null]},"storage_gb":{"type":["integer","null"]},"closed_network":{"type":"boolean"}},"required":["site_id","deploy_target","firewall","closed_network"]} gpu·storage 는 현실적인 서버 사양이어야 합니다. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) gpu 가 null(GPU 없음·미인식) 4건, (2) tls 가 self_signed·missing·null 인 인증서 문제 5건, (3) storage_gb 가 null 이거나 100 이하로 부족 4건, (4) closed_network=true 인데 deploy_target 이 클라우드인 모순 2건.{"type":"object","properties":{"site_id":{"type":"string"},"deploy_target":{"type":"string","enum":["on_prem","aws","gcp","azure"]},"gpu":{"type":["string","null"]},"firewall":{"type":"boolean"},"tls":{"type":["string","null"],"enum":["valid","self_signed","missing",null]},"storage_gb":{"type":["integer","null"]},"closed_network":{"type":"boolean"}},"required":["site_id","deploy_target","firewall","closed_network"]}진단 규칙 엔진의 입력이 되는 배포 후 로그입니다. 장애 원인과 정상·경고를 일부러 섞어 진단 분기를 시험합니다.
| log_id | site_id | component | level | message | ts |
|---|---|---|---|---|---|
| L-001 | H-02 | gpu | ERROR | CUDA driver not found; falling back to… | 2026-07-01T09:00:00 |
| L-002 | H-04 | api | ERROR | SSL handshake failed: certificate miss… | 2026-07-01T09:05:00 |
| L-003 | H-03 | network | ERROR | connection refused to inference:8501 (… | 2026-07-01T09:10:00 |
| L-004 | H-08 | inference | ERROR | no space left on device while loading … | 2026-07-01T09:15:00 |
| L-005 | H-01 | inference | INFO | model loaded, health check OK | 2026-07-01T09:20:00 |
다음 JSON Schema 를 그대로 만족하는 배포 로그 행을 40개 더 만들어 주세요: {"type":"object","properties":{"log_id":{"type":"string"},"site_id":{"type":"string"},"component":{"type":"string","enum":["inference","api","viewer","gpu","network"]},"level":{"type":"string","enum":["INFO","WARN","ERROR"]},"message":{"type":"string"},"ts":{"type":"string"}},"required":["log_id","site_id","component","level","message"]} message 는 실제 배포 로그처럼 구체적이어야 합니다. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) 인증서(SSL/TLS) 관련 ERROR 5건, (2) GPU 미인식·메모리 부족 5건, (3) 방화벽·연결 거부 network ERROR 4건, (4) 스토리지 부족 3건, (5) 정상인데 WARN 으로 보이는 경계 로그(지연·자가서명 수용) 4건.{"type":"object","properties":{"log_id":{"type":"string"},"site_id":{"type":"string"},"component":{"type":"string","enum":["inference","api","viewer","gpu","network"]},"level":{"type":"string","enum":["INFO","WARN","ERROR"]},"message":{"type":"string"},"ts":{"type":"string"}},"required":["log_id","site_id","component","level","message"]}| Docker | 모의 추론·API·뷰어를 컨테이너 이미지로 만들어 어느 현장에서도 같은 방식으로 구동합니다 |
| Kubernetes | 폐쇄망을 가정한 로컬 클러스터(kind/minikube)에 배포·구동하는 오케스트레이션입니다 |
| AWS | 2주차부터 같은 Helm 차트를 AWS(EKS 가정)로 올려 클라우드 배포를 검증합니다 |
| GCP | 동일 배포를 GCP 로 옮길 때의 대안 타깃으로 두어 환경 이식성을 확인합니다 |
| Azure | 동일 배포를 Azure 로 옮길 때의 대안 타깃으로 둡니다 |
| FastAPI | 모의 추론 결과를 돌려주는 API 서버를 구현합니다 |
| Python | 배포 스크립트와 로그 파서·진단 규칙 엔진의 구현 언어입니다 |
| React | 배포 상태·로그 진단·환경 점검을 보는 운영 콘솔 화면을 만듭니다 |
| Spring | 고객사 기존 백엔드와 REST 로 연동되는 부분을 가정한 어댑터입니다 |
| REST | 추론·뷰어·외부 시스템 연동을 REST 로 설계합니다 |
| Linux | 폐쇄망 서버와 컨테이너가 도는 운영 환경을 가정합니다 |
| Nginx | 뷰어·API 앞단의 리버스 프록시와 TLS 종단을 구성합니다 |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 AWS 배포와 로그 정답 대조로 넘어갑니다.
✓ pass → 모니터링과 배포 전 환경 점검 리포트로 넘어갑니다.
배포 후 로그의 장애 원인·조치 진단입니다. 원인은 규칙이 결정하고 조치 문구마다 근거 로그를 인용합니다.
{"type":"object","properties":{"log_id":{"type":"string"},"cause":{"type":["string","null"]},"severity":{"type":"string","enum":["blocker","degraded","info"]},"action":{"type":"string"},"evidence":{"type":"string"},"hedge":{"type":"string"}},"required":["log_id","severity","action","evidence","hedge"]}[
{
"log_id": "L-002",
"cause": "TLS 인증서 부재",
"severity": "blocker",
"action": "사이트에 유효한 서버 인증서를 발급·설치하거나 내부 CA 인증서를 컨테이너 신뢰 저장소에 추가한 뒤 재배포합니다.",
"evidence": "SSL handshake failed: certificate missing",
"hedge": "진단은 더미 로그·규칙 기준이며 실제 인증서 정책은 사이트마다 다릅니다."
},
{
"log_id": "L-001",
"cause": "GPU 드라이버 미탐지",
"severity": "degraded",
"action": "CUDA 드라이버 설치를 확인하고, 불가 시 CPU 폴백으로 동작하되 추론 지연을 운영자에게 고지합니다.",
"evidence": "CUDA driver not found; falling back to CPU",
"hedge": "CPU 폴백 동작은 규칙이 degraded 로 분류했으며 성능 저하를 그대로 노출했습니다."
},
{
"log_id": "L-005",
"cause": null,
"severity": "info",
"action": "정상 기동으로 별도 조치가 필요 없습니다. 헬스체크 통과를 기록합니다.",
"evidence": "model loaded, health check OK",
"hedge": "정상 로그는 원인 없이 info 로 남겼습니다. 합성 로그 기준입니다."
}
][자동 검증 · 스크립트가 전수 수행] 1. 출력이 JSON Schema 형식을 통과하는지 확인합니다(형식 깨진 진단이 운영 콘솔에 나가는 것을 차단). 2. severity·cause 가 로그 규칙 재실행 결과와 100% 일치하는지 확인합니다(정답은 LLM 이 아니라 규칙이 결정). 3. evidence 가 입력 로그 message 에 실재하는지 확인합니다(지어낸 근거 차단). [수동 검증 · 사람이 표본 확인] 1. 조치 문구가 근거 로그를 넘어 과장하지 않는지 진단 30건을 표본 검토합니다. 2. 정상 로그가 장애로 오분류되지 않는지 확인합니다.