팀원이 보내준 예측 모델을, 우리 서비스에 이식한 날 — AutoGluon과 파이썬 버전 전쟁

📚 「AI 헬스케어 파이널 프로젝트」 연재 13편입니다. (12편: AI로 챗봇 테스트하다 운영 데이터베이스를 통째로 날렸다)

📝 한줄 요약

예측 모델을 맡은 팀원이 노트북(Colab) 파일로 보내준 콩팥병 위험 예측 모델을, 우리 실제 서비스에 옮겨 붙인 날입니다. 옮기자마자 “AutoGluon이라는 자동 머신러닝 도구가 파이썬 3.13을 지원 안 한다”는 벽에 부딪혀, 프로젝트 전체를 3.11로 다운그레이드하는 버전 전쟁을 치렀습니다. 모델이 제대로 작동하는지 확인한 뒤, 밤에는 코드 전체를 점검해 보안 취약점 65건까지 잡았습니다.

바쁘시면 이것만 읽어도 돼요:

팀원의 노트북(실험용) 코드를 우리 서비스 코드로 옮기는 건, 그냥 복사가 아니라 “다시 짓는” 작업
핵심 검증: 옮긴 모델이 팀원이 만든 그대로 작동하는지 숫자로 증명 (이른바 train/serve 불일치 0)
버전 전쟁: 도구 하나가 새 파이썬을 안 받아줘서, 프로젝트 전체를 3.13 → 3.11로 내림. 기계적으론 쉽지만 진짜 변수는 “팀 전원 동시 전환”
실제로 돌려보니 건강한 사람은 낮은 위험, 고혈압·당뇨는 중간, 콩팥 기능 저하는 높은 위험으로 정확히 반응
“위험도가 너무 낮게 나온다”는 게 버그가 아니라 모델 특성임을 데이터로 구분
밤엔 AI에게 코드 전체를 점검시켜 보안 구멍 65건을 찾고, 가장 위험한 것부터 막음

🎯 이런 분들께 도움돼요

누군가 만든 결과물(코드·모델·문서)을 내 환경에 옮겨 붙여야 하는 분
도구·라이브러리 버전이 안 맞아 골치 아팠던 분
AI에게 내 프로젝트 전체를 점검시켜 문제를 미리 찾고 싶은 분

😫 문제 상황 (Before)

우리 팀은 역할을 나눠 일합니다. 저는 챗봇과 시스템 통합을 맡았고, 다른 팀원이 콩팥병 위험을 예측하는 AI 모델을 따로 학습시켰습니다. 그런데 그 팀원이 모델을 만든 곳은 **코랩(Colab)**이라는 실험용 노트북 환경이었습니다. 거기서 만든 코드는 그 자리에서 한 번 돌려보기엔 좋지만, 24시간 돌아가는 진짜 서비스에 그대로 붙일 수는 없습니다.

비유하자면, 요리연구가가 자기 주방에서 만든 레시피를 받아 우리 식당 주방 동선과 장비에 맞게 다시 정리해야 하는 상황이었죠. 게다가 옮기는 과정에서 맛이 변하면 안 됩니다. 팀원이 만든 모델과 똑같이 작동해야 했습니다.

🛠️ 사용한 도구

도구: Claude Code
모델: Claude Opus
특이사항: 팀원의 실험용 노트북 → 서비스용 코드로 이식. 옮긴 결과가 원본과 같은지 숫자로 검증. 밤엔 코드 전체 보안 점검

🔧 작업 과정

노트북을 받았는데, “데이터는 어디서부터 넣지?”

오늘할 작업은 우선 ckd예측 모델을 우리 시스템에 결합하는 작업이야
예측 모델 담당 팀원이 코드를 보내줬는데 코랩 환경의 노트북 파일로 보내줬어
이걸 우선 우리 시스템 코드에 맞게 변경해야되
그전에 질문이 있어 우리시스템에는 데이터가 어디서 부터 들어가야되는거야?
원본데이터로부터 학습데이터를 만드는 데이터 파이프라인이 필요한가 아니면
어느 정도 가공된 데이터부터 넣어서 시작하는게 맞느건가?

제가 막혔던 건 코드가 아니라 개념이었습니다. “원본 데이터부터 다시 만들어야 하나, 아니면 어느 정도 다듬은 데이터부터 시작해도 되나?”

AI가 깔끔하게 정리해줬습니다. AI 모델에는 두 개의 세계가 있다고요. 하나는 모델을 만드는 세계(원본 데이터 → 학습), 다른 하나는 모델을 쓰는 세계(사용자 입력 → 예측). 이 둘은 데이터가 아니라 ‘완성된 모델 파일’과 ‘계산 규칙 코드’로만 만난다는 거였죠. 그래서 원본 62GB를 다 짊어질 필요 없이, 팀원이 이미 다듬어 둔 학습용 데이터부터 시작하면 됐습니다.

이 정리 덕분에, 팀원의 노트북을 우리 서비스용 코드 묶음 8개로 차근차근 옮길 수 있었습니다.

💡 막히면 코드가 아니라 개념부터 물어보세요. “어디서부터 시작해야 하나”라는 질문 하나로, 안 해도 될 일(원본 전체 처리)을 안 하게 됐습니다.

옮긴 게 ‘원본과 똑같은지’ 숫자로 증명하기

남의 코드를 옮길 때 가장 무서운 건 “옮기다 미묘하게 달라지는” 것입니다. 모델은 결과가 조금만 틀어져도 엉뚱한 사람에게 엉뚱한 위험도를 줄 수 있으니까요.

여기서 똑똑한 방법을 썼습니다. 팀원이 이미 변환을 끝낸 데이터 표가 있었는데, 그 표에는 “입력값”과 “계산 결과”가 나란히 들어 있었습니다. 그래서 제가 옮긴 코드에 그 입력값을 넣어, 결과가 표의 계산 결과와 똑같이 나오는지 맞춰봤습니다. 똑같이 나오면, 제 코드가 팀원의 노트북과 같다는 게 증명되는 거죠. 실제로 차이가 0으로 나왔습니다.

💡 “잘 옮겨졌겠지”는 믿음이고, “결과가 0으로 일치한다”는 증거입니다. 남의 작업물을 옮길 땐, 원본과 같은지 확인할 ‘정답표’를 먼저 찾으세요.

AutoGluon이 파이썬을 안 받아준다 — 버전 전쟁의 시작

우선 모델 오토글루온 부터 하자

이제 모델을 실제로 돌리려면 AutoGluon(여러 모델을 자동으로 만들어 가장 좋은 걸 골라주는 자동 머신러닝 도구)을 우리 환경에 깔아야 했습니다. 그런데 깔리지가 않았습니다. 이유는 황당할 만큼 단순했습니다 — AutoGluon이 우리가 쓰던 파이썬 3.13 버전을 아직 지원하지 않았던 겁니다.

선택지는 둘이었습니다. 모델을 포기하거나, 우리가 파이썬 버전을 내리거나. 당연히 후자였죠. 그런데 한 가지 걸렸습니다.

버전을 전환하는건 어려운 작업은 아닌가?

AI의 답이 정확했습니다. 기계적으로는 어렵지 않다, 설정 몇 줄 바꾸고 다시 만들면 된다. 게다가 이번엔 **올리는 게 아니라 내리는 것(3.13 → 3.11)**이라 더 안전하다고요. 다만 진짜 어려운 건 코드가 아니라 사람이라고 짚어줬습니다. 팀원 모두가 동시에 같은 버전으로 맞춰야 하니까요. 결국 저는 프로젝트 전체를 3.11로 내리고, 팀과 합의해 함께 전환하기로 했습니다.

💡 버전 충돌은 흔하고, 보통은 “맞추면” 풀립니다. 진짜 변수는 기술이 아니라 “팀 전원이 같이 바꾸기”라는 협업입니다. 혼자 바꿔놓으면 오히려 더 꼬여요.

진짜로 작동할까? — 건강한 사람·아픈 사람으로 시험

버전을 맞추고 나니 드디어 모델이 돌았습니다. 이제 제대로 작동하는지 확인할 차례. 저는 가상의 입력 세 종류를 넣어봤습니다.

건강한 사람 → 낮은 위험(가장 건강한 등급)
고혈압·당뇨가 있는 사람 → 중간 위험
콩팥 기능 수치(eGFR, 콩팥이 피를 거르는 능력)가 크게 떨어진 사람(29.8) → 높은 위험

셋 다 의학적 상식과 정확히 맞아떨어졌습니다. 모델이 입력에 따라 제대로 반응한다는 뜻이었죠.

그런데 한 가지 의심스러운 점이 있었습니다. 위험 점수의 절대값이 전반적으로 너무 낮게(0.001~0.01) 나오는 거였어요. “이거 버그 아냐?” 싶었지만, AI와 함께 따져보니 버그가 아니라 모델의 성격이었습니다. 콩팥병 환자가 전체의 10% 정도밖에 안 되는 불균형한 데이터로 학습했고, 일부러 특정 수치를 빼고 학습했기 때문에 점수가 낮은 범위에 머무는 거였죠. 실제 위험 등급 판정은 점수가 아니라 **임상 규칙(콩팥 기능 수치 등)**이 주도하도록 설계돼 있어서 문제없었습니다.

💡 “이상하다”와 “틀렸다”는 다릅니다. 숫자가 예상과 다르다고 무조건 버그로 몰지 말고, “왜 이렇게 설계됐는지”를 따져보세요. 정상인데 낯선 것일 수 있습니다.

이 모델을 우리 백그라운드 작업자(ai_worker, 사용자가 안 볼 때 뒤에서 계산을 돌리는 일꾼)에 통합하고, 도커 이미지로 묶어 변경 사항을 정리했습니다.

밤엔 코드 전체를 AI에게 점검시켰다 — 보안 구멍 65건

ultracode 전체 프로젝트 코드를 심층적으로 검증해보자 오류나 문제가 없는지 (workspaces 폴더에 있는)

모델 작업을 마치고, 이참에 프로젝트 전체가 안전한지 점검하기로 했습니다. AI에게 코드 전체를 깊이 검증시켰더니, 여러 검토 결과를 모으고 그중 허위 경고를 걸러낸 뒤 진짜 문제 65건을 추려줬습니다.

가장 충격적이었던 건 가장 위험한 한 건이었습니다. 우리 서비스의 **비밀 열쇠(SECRET_KEY)**가 깃 저장소에 그대로 올라가 있었던 거죠. 이 열쇠가 노출되면 누구나 관리자인 척 위조할 수 있습니다. AI는 추측에 그치지 않고, 그 값이 실제 운영 값과 글자 하나까지 똑같은지 직접 대조해 확인까지 해줬습니다.

키 회전이나 H1/.gitignore 정리를

그래서 곧바로 손을 썼습니다. 노출된 비밀 열쇠를 **새 열쇠로 교체(키 회전)**하고, 다른 위험한 구멍들도 막았습니다. 로그인 토큰 검증을 강화하고, 같은 이메일로 중복 가입되는 걸 막고, 운영 환경 설정의 불일치(데이터베이스 종류가 운영과 개발에서 다른 문제)도 통일했습니다. 이 모든 걸 두 번에 나눠 정리해 반영했습니다.

💡 AI에게 “내가 만든 것 전체를 점검해줘”라고 시키면, 내가 놓친 위험을 찾아줍니다. 단, 가장 중요한 경고는 AI 말만 믿지 말고 “진짜 그런지” 직접 확인하는 습관이 안전합니다.

✅ 결과 (After)

Before vs After

항목	Before	After
예측 모델	팀원의 실험용 노트북 파일	우리 서비스 코드로 이식 (원본과 결과 일치 0)
파이썬 버전	3.13 (AutoGluon 안 깔림)	3.11로 통일 (모델 정상 작동)
모델 검증	안 해봄	건강·고혈압당뇨·콩팥저하 → 정확히 반응 확인
보안	점검 안 함	취약점 65건 진단, 가장 위험한 것부터 수정·키 교체

결과물

우리 서비스에서 작동하는 콩팥병 위험 예측 모델(도커 이미지에 통합)
파이썬 3.11로 통일된 프로젝트 환경
보안 취약점 진단 보고서와 핵심 수정(비밀 열쇠 교체 포함)

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

개념부터 묻기: “어디서부터 시작하나”를 정리하면 불필요한 작업을 통째로 건너뛸 수 있음
옮긴 결과를 숫자로 검증: “잘 됐겠지” 대신 “원본과 0으로 일치” 같은 증거를 확보
전체 점검 맡기기: 코드 전체를 AI에게 검증시켜 내가 못 본 위험을 발굴

이렇게 하면 안 돼요

버전을 혼자만 바꾸기: 팀 작업이면 전원이 동시에 맞춰야 함. 혼자 바꾸면 더 꼬임
낯선 숫자를 무조건 버그로 몰기: “이상하다”와 “틀렸다”를 구분. 설계 의도를 먼저 확인
가장 중요한 경고도 AI 말만 믿기: Critical 항목은 직접 한 번 더 대조

🌍 다른 업무에 적용한다면?

“남이 만든 결과물을 내 환경에 옮겨 붙이는” 일은 어디에나 있습니다. 다른 팀이 만든 보고서 양식, 외부 업체가 준 자료, 동료의 엑셀 파일. 이때 핵심은 두 가지예요. 옮긴 게 원본과 같은지 확인할 ‘정답표’를 먼저 찾는 것, 그리고 도구·버전이 안 맞으면 혼자 바꾸지 말고 함께 맞추는 것. 코드가 아니어도 똑같이 통합니다.

🚀 앞으로의 계획

이제 모델이 “위험하다 / 안전하다”를 판정합니다. 그런데 다음 질문이 생기죠 — “왜 그렇게 나왔는데?” 사용자 입장에선 “당신은 위험 등급입니다”만 듣고는 답답합니다. 그래서 다음 편에서는 AI가 내린 건강 점수가 ‘왜’ 그렇게 나왔는지까지 설명하게 만드는 작업을 다룹니다. “혈압이 이만큼, 혈당이 저만큼 영향을 줬어요”처럼 변수별 기여도를 보여주는 리포트(SHAP)를 붙이는 이야기예요. 다음 막에서 풀어볼게요.

📋 재사용 가능한 프롬프트

프롬프트 1: 남의 결과물 이식 전 개념 정리

[받은 결과물]을 내 환경에 옮기려고 해. 옮기기 전에 먼저 묻고 싶은 건, 어디서부터 가져와야 하는지야. 처음부터 다시 만들어야 하는지, 어느 단계부터 받아 쓰면 되는지 정리해줘.

프롬프트 2: 옮긴 게 원본과 같은지 검증

[옮긴 작업물]이 원본과 똑같이 작동하는지 확인하고 싶어. 원본의 “입력과 결과”가 같이 들어 있는 자료가 있으면, 그 입력을 넣어 결과가 일치하는지 숫자로 증명해줘.

프롬프트 3: 프로젝트 전체 점검

[내 프로젝트] 전체를 깊이 점검해서, 오류나 보안 문제가 없는지 찾아줘. 허위 경고는 걸러내고, 가장 위험한 항목은 추측하지 말고 실제로 그런지 직접 대조해서 확인해줘.

📌 「AI 헬스케어 파이널 프로젝트」 연재 13편입니다. 다음 막에서 또 이어집니다.