AI 13명에게 우리 프로젝트를 채점시켰더니 87점 — 데모데이 전, 점수를 끌어올린 마지막 스퍼트

📚 「AI 헬스케어 파이널 프로젝트」 연재 23편(현재 마지막 편)입니다. (22편: 한눈에 들어오게, 대시보드와 로그인 화면을 2열로 다시 짠 하루)

📝 한줄 요약

데모데이를 코앞에 두고, 심사에 쓰일 평가표(6개 분류·20개 항목)를 그대로 가져다 우리 프로젝트를 AI 13명에게 깐깐하게 채점시켰습니다. 결과는 87점. 점수가 깎인 약점 여섯 군데를 그날 안에 실제로 메우고 배포해, 전망 점수를 95~97점까지 끌어올렸습니다. 지난 편이 “보기 좋게”였다면, 이번 편은 “잘한다고 증명하기”입니다. 그리고 이 글이 이 연재의 마지막 편입니다.

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

심사 평가표를 그대로 AI에게 주고 우리 편을 들지 말고 깐깐하게 채점시켰더니, 내 눈엔 안 보이던 빈틈이 드러남(87점)
가장 크게 깎인 곳은 “잘한다고 말만 하고 숫자로 증명 안 한” 부분 — AI 모델 성능을 한 번도 측정 안 했던 것
그래서 모델 정확도를 실제로 쟀더니 0.902 / 0.883(1에 가까울수록 잘 맞힘, 목표 0.80을 넘김)
같은 입력을 200개 × 20번 돌려도 결과가 완전히 똑같음(편차 0) — “믿을 수 있는 시스템”을 숫자로 보임
교훈: “잘한다”는 주장이고, “0.902”는 증거다. AI 여러 명에게 적대적으로 검증시키면 자기 빈틈이 보인다

🎯 이런 분들께 도움돼요

곧 발표·심사·평가를 앞두고 내 결과물의 약점을 미리 찾고 싶은 분
“잘 만들었다”는 느낌은 있는데 그걸 어떻게 증명할지 막막한 분
AI에게 내 편을 들지 말고 깐깐하게 봐달라고 시키는 법이 궁금한 분

😫 문제 상황 (Before)

데모데이가 며칠 안 남았습니다. 몇 주를 매달려 챗봇도 붙이고, 예측 모델도 이식하고, 리포트와 챌린지까지 만들었습니다. 손으로 만져지는 결과물은 충분했어요. 그런데 발표 직전에 가장 무서운 건 **“내가 못 본 약점”**입니다. 정작 심사위원 눈에는 빤히 보이는데, 만든 사람만 모르는 그런 구멍 말이죠.

마침 주최 측이 세부 평가표를 공개해 뒀습니다. 6개 분류, 20개 항목, 항목마다 0~5점. 보통은 이걸 “참고”만 하고 넘어갑니다. 저는 다르게 했어요. 이 표를 그대로 AI에게 넘기고, 우리 프로젝트를 이 기준으로 채점해달라고 했습니다. 단, 봐주지 말고요.

🛠️ 사용한 도구

도구: Claude Code
모델: Claude Opus
특이사항: 심사 평가표를 그대로 입력 → AI 여러 명에게 적대적(깐깐하게) 채점 → 깎인 약점을 그날 안에 실제 작업으로 메우고 배포

🔧 작업 과정

”우리 편 들지 말고, 이 기준으로 채점해줘”

ultracode 5_참여기업 주제 안내 (세부평가 기준 포함).md 여기 있는 평가기준으로 지금 프로젝트를 평가헤줘

저는 AI에게 혼자서 후하게 점수 주지 말라고 시켰습니다. 한 명이 채점하면 자기 편을 들기 쉬우니까, 여러 관점으로 나눠 채점한 뒤 서로 따져 깎는 방식으로요. 실제로 AI는 13개의 시선으로 분류별로 점수를 매기고, 그다음 “이 점수 너무 후한 거 아냐?” 하고 자기들끼리 검증하면서 부풀려진 항목 두 개를 5점에서 4점으로 끌어내렸습니다.

결과는 87점. 분류별로 보면 기획·화면·연동은 거의 만점이었는데, AI 부분이 20점 만점에 13점으로 가장 낮았습니다. 손에 잡히는 기능은 다 갖췄는데, “그게 진짜 잘 작동하는지 숫자로 보여주는” 부분이 비어 있던 거죠.

💡 AI에게 채점을 맡길 땐 “봐주지 말라”고 명시하세요. 한 명이 아니라 여러 관점으로 나눠 서로 깎게 하면, 자기 칭찬이 아니라 진짜 약점이 나옵니다.

가장 아팠던 한 마디 — “잘한다면서, 재본 적은 없잖아?”

채점 결과에서 가장 뼈아팠던 건 이거였습니다. 우리는 콩팥병 위험을 예측하는 AI 모델을 자랑했는데, 정작 그 모델이 얼마나 정확한지 한 번도 숫자로 재본 적이 없었던 겁니다. 심지어 우리 팀 내부 문서에 “아직 성능 측정 안 함, 정확도를 함부로 주장하지 말 것”이라고 적혀 있었어요. AI는 그 문장을 그대로 짚으면서 점수를 깎았습니다.

이건 변명의 여지가 없었습니다. “좋은 모델”이라는 건 느낌이고, 심사위원이 원하는 건 증거니까요. 그래서 바로 측정에 들어갔습니다. 한 번도 학습에 쓰지 않은 시험용 데이터로 모델을 돌려, 정확도를 나타내는 지표(ROC-AUC, 0에서 1 사이이고 1에 가까울수록 잘 맞힘)를 계산했습니다.

모델 1: 0.902
모델 2: 0.883

둘 다 우리가 목표로 잡았던 0.80을 넘겼습니다. “측정 안 했다”던 공백이, 한나절 만에 두 개의 또렷한 숫자로 바뀐 거죠. 여기서 한 가지 함정도 조심했습니다. 점수를 어디서 끊을지(합격/위험 경계선)는 시험용 데이터가 아니라 따로 떼어둔 검증용 데이터로 정했습니다. 시험지로 합격선을 정하면 점수가 부풀려지는 반칙이 되니까요.

💡 “잘한다”는 주장은 반드시 숫자로 증명해야 합니다. 그리고 그 숫자를 만들 때, 시험 문제로 채점 기준까지 만드는 반칙(데이터 누수)을 하지 않는 게 핵심입니다.

”이 시스템, 믿을 수 있어?” — 같은 입력을 200 × 20번 돌려보기

평가표에는 재현성이라는 항목도 있었습니다. 어려운 말 같지만 뜻은 단순합니다. “같은 걸 넣으면 항상 같은 답이 나오나?” 의료처럼 사람 건강을 다루는 서비스에서, 똑같은 사람이 같은 정보를 넣었는데 어제는 위험, 오늘은 안전이라고 나오면 아무도 못 믿습니다.

그래서 시험해봤습니다. 서로 다른 200명의 가상 입력을 만들고, 각각을 20번씩 반복해서 모델에 넣었어요. 만약 결과가 매번 조금씩 흔들리면, 그 흔들리는 폭이 숫자로 잡힙니다. 결과는 흔들림의 폭이 0. 같은 입력은 몇 번을 돌려도 글자 하나 안 틀리고 똑같은 답을 냈습니다.

이건 그냥 “잘 만들었다”가 아니라, “믿어도 된다”를 숫자로 보여준 작업이었습니다.

💡 “믿을 수 있다”도 숫자로 증명할 수 있습니다. 같은 입력을 여러 번 넣어 답이 흔들리는지 재보면, 시스템의 신뢰성을 막연한 말이 아니라 수치로 보일 수 있어요.

나머지 약점도 그날 안에 — 피드백 버튼, 부하 견디기, 결정 기록

큰 두 개를 메우고, 자잘하지만 점수에 걸린 약점들도 같은 날 정리했습니다.

첫째, 사용자 피드백 수집. 챗봇이 답을 주면 사용자가 좋아요 / 싫어요를 누를 수 있게 버튼을 달았습니다. 나중에 “어떤 답이 도움이 됐고 어떤 답이 별로였는지” 데이터로 쌓여, 모델을 개선할 재료가 됩니다. 평가표에 “사용자 피드백을 수집하는가” 항목이 있었는데, 그동안 그런 장치가 아예 없었거든요.

둘째, 부하 견디기(부하 테스트). 많은 사람이 동시에 몰렸을 때 서비스가 버티는지 재보는 일입니다. 그런데 여기서 재밌는 사고가 있었어요. 막상 50명이 몰리는 상황을 흉내 냈더니 전부 실패가 떴습니다. 알고 보니 우리 서비스에는 “한 사람이 너무 자주 두드리면 잠깐 막는” 보호 장치가 있었는데, 테스트를 한 컴퓨터에서 돌리다 보니 시스템이 그걸 “한 사람이 미친 듯이 두드린다”고 오해한 거였죠. 그래서 부하 측정을 할 때만 그 보호 장치를 잠시 끄는 스위치를 만들었습니다(평소엔 켜져 있고요). 다시 재보니 응답 속도가 15밀리초(0.015초)로 가뿐했습니다.

모두 머지완료 브랜치 최신화 확인

셋째, 중요한 결정을 글로 남기기(ADR). ADR은 “왜 이 기술을 골랐는지를 기록해두는 메모”입니다. 우리가 챗봇 두뇌로 무엇을 썼고, 왜 다른 후보 대신 그걸 골랐는지를 네 건의 결정 문서로 정리했습니다. 심사위원이 “왜 이걸 썼어요?”라고 물으면 즉답할 수 있게요. 마지막으로 이 결과들을 그래프가 들어간 평가 노트북으로도 묶어, 눈으로 볼 수 있게 만들었습니다.

💡 약점은 “느낌”이 아니라 “항목”으로 보면 메우기 쉽습니다. 평가표가 “피드백 없음 / 측정 없음 / 기록 없음”처럼 콕 집어주니, 하나씩 지워나가는 일이 됐어요.

”몇 시간 걸린다며?” — AI와 일하는 속도에 적응하기

작업 중에 제가 AI에게 이렇게 물은 적이 있습니다.

아니 몇시간 걸리고 반나절 걸린다고 하지않았어?

평가 단계에서 “이 약점들을 메우려면 사람 기준 반나절에서 하루”라는 추정이 나왔는데, 막상 AI와 함께 하니 각 작업이 10~30분 만에 끝나버린 거예요. 처음엔 “이렇게 빨리 됐다고? 대충 한 거 아냐?” 하고 의심했습니다.

그래서 따져봤습니다. 빠른 게 부실한 건지 확인하려고요. 결과를 보니 대충 한 게 아니었습니다. 모델 정확도는 실제로 측정했고, 200×20번 반복도 진짜로 돌렸고, 노트북의 그래프도 실제로 그려서 박혀 있었고, 자동 검사도 통과한 상태였습니다. **“사람이 반나절 걸릴 일”이 “AI와 함께면 30분”**이었던 것뿐이죠. 다만 한 가지, 기술 선택의 이유를 적은 문서는 AI가 기존 기록을 추론해 쓴 것이라 제가 직접 한 번 더 검토하기로 했습니다.

💡 AI와 일하면 “사람 기준 시간 감각”이 자꾸 어긋납니다. 빠르다고 의심부터 하지 말고, “결과가 진짜인지” 증거로 확인하세요. 빠른 것과 부실한 것은 다른 문제입니다.

✅ 결과 (After)

Before vs After

항목	Before	After
자가 진단	안 해봄(약점 모름)	평가표로 87점 진단, 약점 6곳 식별
모델 정확도	한 번도 측정 안 함	실측 0.902 / 0.883(목표 0.80 초과)
신뢰성(재현성)	미확인	200×20회 반복 편차 0
사용자 피드백	수집 장치 없음	챗봇에 좋아요/싫어요 추가
점수 전망	87점	약 95~97점

결과물

평가표 기준 자가 진단 보고서(분류별 점수와 약점 목록)
모델 성능 실측 결과와 그래프가 담긴 평가 노트북
같은 입력 반복 시 결과가 일치함을 보인 재현성 측정
챗봇 답변 피드백 버튼, 부하 견디기 측정, 기술 결정 기록 문서
위 작업 전부 실제 서비스에 배포 완료

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

효과적이었던 것

평가표를 그대로 입력하기: 막연히 “점검해줘”보다, 진짜 채점 기준을 주면 약점이 항목별로 또렷이 나옴
여러 명에게 깐깐하게: 한 관점이 아니라 여러 시선으로 나눠 서로 깎게 하면 자기 칭찬이 빠짐
주장 대신 숫자: “잘한다”를 “0.902”로 바꾸는 작업을 우선순위에 둠

이렇게 하면 안 돼요

시험 문제로 합격선까지 정하기: 측정할 땐 검증용/시험용 데이터를 섞지 말 것(점수 부풀림)
빠르다고 무조건 의심: 빠른 것과 부실한 것은 다름. 의심 대신 증거로 확인
AI가 쓴 “결정 이유”를 그대로 믿기: 추론으로 쓴 문서는 사람이 한 번 더 검토

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

발표·심사·평가를 앞둔 모든 일에 똑같이 통합니다. 보고서든 제안서든 포트폴리오든, 그걸 평가할 기준표를 먼저 구해서 AI에게 “내 편 들지 말고 채점해줘” 하고 시켜보세요. 내가 자신 있던 부분이 의외로 약점일 수 있고, 별것 아니라 여긴 데서 점수가 깎일 수 있습니다. 그리고 “잘했다”는 인상을 남기고 싶다면, 그 잘함을 숫자 하나로 압축하는 연습을 하세요. “성능이 좋다”보다 “정확도 0.9”가, “안정적이다”보다 “200번 돌려도 편차 0”이 훨씬 힘이 셉니다.

🚀 앞으로의 계획

이제 데모데이 본선이 남았습니다. 진단으로 찾은 약점을 메웠으니, 무대에서는 이 숫자들을 가지고 우리 서비스를 당당히 보여줄 일만 남았어요.

데모데이 이후의 숙제도 적어뒀습니다. 사용자가 눌러준 좋아요/싫어요를 모아 모델을 다시 학습시키는 순환 고리를 완성하고 싶어요. 더 많은 사람이 몰려도 끄떡없는지 확장성도 실제로 실증해봐야 하고요. 함께 만든 팀원 각자의 역할도 또렷이 기록해 두려 합니다. 이 숙제들은 다음 막의 씨앗으로 남겨둡니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 평가 기준으로 적대적 자가 진단

[평가 기준표/심사표]를 기준으로 내 [프로젝트/보고서]를 채점해줘. 내 편을 들지 말고, 여러 관점으로 나눠 점수를 매긴 다음 서로 너무 후한 항목이 없는지 깎아가며 검증해줘. 점수가 깎인 약점은 무엇을 어떻게 보완하면 되는지까지 정리해줘.

프롬프트 2: “잘한다”를 숫자로 증명하기

[내 결과물]이 잘 작동한다는 걸 숫자로 증명하고 싶어. 한 번도 쓰지 않은 시험용 데이터로 정확도를 재주고, 합격/경계 기준은 시험용이 아닌 별도 데이터로 정해서 부풀림이 없게 해줘.

프롬프트 3: 빠른 결과가 진짜인지 검증

방금 작업이 예상보다 너무 빨리 끝났어. 빠른 게 부실한 건 아닌지 확인하고 싶어. 실제로 측정·실행·검사가 됐는지 증거를 하나씩 보여줘.

마지막으로, 이 연재 전체를 한 번 돌아봅니다. 저는 나노소재와 전자현미경을 다루던 연구원이었고, 코드는 거의 몰랐습니다. 그런 제가 AI와 함께 의료 웹서비스 하나를 처음부터 끝까지 만들었습니다. 데이터를 모으고(1·2편), 라벨이 새는 함정을 발견해 콩팥병으로 방향을 틀었고(3편), 게임처럼 즐겁게 만들 방법과 자료를 찾아 답하는 챗봇 기술을 공부했습니다(4편). 데이터를 다시 짓고(5편), 서비스의 뼈대를 설계하고(6편), 자료를 근거로 답하는 챗봇을 한 단계씩 쌓아 올렸습니다(7~~12편). 팀원의 예측 모델을 우리 서비스에 이식하고(13편), “왜 그 점수인지”를 설명하는 리포트와 속도 개선까지 붙였습니다(14~~16편). 챌린지를 게임처럼 다듬고 기록 기능을 채우고(17·18편), 버그를 잡고 진단자와 비진단자를 갈라 다른 경험을 주고(19·20편), 실제 서버에 올려 디자인을 입혔습니다(21·22편). 그리고 오늘, 그 모든 걸 평가표 앞에 세웠습니다(23편).

코드를 모른다고 못 만드는 게 아니었습니다. 막히면 코드가 아니라 개념을 묻고, 느낌 대신 숫자를 확인하고, 혼자 끙끙대는 대신 AI에게 정확히 부탁하는 것 — 이것만으로도 연구원 한 명이 의료 서비스 하나를 끝까지 만들 수 있었습니다. 이 연재가, 코드 앞에서 멈칫하던 누군가에게 “나도 해볼 수 있겠다”는 한 줄의 용기가 되었으면 합니다.

📌 「AI 헬스케어 파이널 프로젝트」 연재 **23편(현재 마지막 편)**입니다. 데모데이를 향한 이 여정을 함께해 주셔서 감사합니다. 또 다른 막에서 이어집니다.