제72화 — 실패를 먼저 맞혀라

Elena의 첫 프로젝트는 새 모델을 만드는 일이 아니었다.

로그를 다시 읽는 일이었다.

3년치까지는 아니었다.

계산서비스가 생긴 뒤 쌓인 작업 수천 건.

성공.

실패.

재실행.

수동개입.

각 로그에는 원인이 있었다.

문제는 그 원인이 제각각이었다.

`memory`

`OOM`

`out of memory`

`mem fail`

`customer input`

`bad input`

`invalid input`

같은 문제를 다른 이름으로 적었다.

Elena는 첫날 말했다.

“이건 학습 못 합니다.”

Daniel이 물었다.

“정규화하면 되죠.”

“누가?”

“자동으로.”

“어떻게?”

Daniel은 입을 다물었다.

텍스트를 묶는 것도 가능하다.

하지만 처음부터 자동분류를 넣으면 또 다른 오류가 생긴다.

Elena는 먼저 운영팀 사람들을 모았다.

“실패 원인 몇 종류라고 생각하세요?”

사람마다 달랐다.

6개.

12개.

20개.

한 명은 말했다.

“사실 복합원인이 많습니다.”

Elena가 고개를 끄덕였다.

좋은 답.

팀은 실패분류 체계를 만들었다.

입력.

환경.

자원.

소프트웨어.

수치수렴.

하드웨어.

외부.

미상.

그리고 복합.

Daniel이 말했다.

“미상은 줄여야 합니다.”

Elena가 대답했다.

“나중에.”

“지금부터—”

“모르는 걸 억지로 아는 척하면 분류가 더 나빠집니다.”

Daniel은 입을 다물었다.

미상.

Unknown.

의료 데이터에서 배웠던 것.

이번에도 같다.

라벨정리가 끝나는 데 3주.

Daniel은 중간에 두 번 일정이 길다고 생각했다.

말하지 않았다.

4주차.

첫 모델.

목표: 작업 시작 전에 실패 가능성이 높은지 예측.

복잡한 모델이 아니었다.

Elena는 일부러 단순한 것부터 시작했다.

Daniel이 물었다.

“더 강한 모델 안 씁니까?”

“기준부터.”

“성능 빨리 올릴 수 있는데.”

“기준 없이 올랐는지 어떻게 알아요?”

또 맞다.

첫 결과.

정확도는 그럴듯했다.

하지만 실패가 드물어서 정확도만 보면 의미가 없었다.

Elena가 말했다.

“모델이 전부 성공이라고만 해도 정확도 높습니다.”

Daniel이 웃었다.

“투자에서도 그랬습니다.”

“그래서 다른 지표 봅니다.”

실패를 얼마나 놓치지 않는가.

괜히 실패라고 경고하는 건 얼마나 많은가.

운영팀이 감당할 경고량은?

이 질문이 중요했다.

경고를 너무 많이 만들면 아무도 안 본다.

39화의 알림피로.

또 돌아왔다.

Elena가 말했다.

“과학모델도 결국 사람한테 경고해야 하면 UI 문제입니다.”

Daniel이 고개를 끄덕였다.

“모델 성능만의 문제가 아니고.”

“네.”

첫 운영시험.

모델은 다음 100개 작업 중 13개를 위험하다고 표시했다.

실제 실패.

7개.

그중 모델이 미리 잡은 것.

5개.

오탐.

8개.

운영담당이 말했다.

“이 정도면 귀찮지만 볼 수는 있습니다.”

Daniel은 2개 놓친 게 마음에 걸렸다.

“왜 놓쳤죠?”

첫 번째.

고객 라이브러리 버전문제.

입력정보에 버전이 없었다.

두 번째.

하드웨어 간헐오류.

작업특성으로는 예측 불가.

Elena가 말했다.

“둘 다 모델을 더 똑똑하게 만든다고 해결될 문제가 아닙니다.”

“그럼.”

“데이터를 추가하거나 다른 감시가 필요합니다.”

Daniel은 잠깐 웃었다.

모든 문제를 AI로 해결하는 게 아니다.

어떤 문제는 센서.

어떤 건 입력.

어떤 건 시스템 구조.

“버전 자동수집.”

운영팀이 말했다.

“하드웨어 간헐오류는 모니터링 강화.”

역할이 갈렸다.

다음 달.

모델 개선.

경고 11개.

실제 실패 8.

미리 잡은 것 7.

오탐 4.

운영팀 반응이 좋아졌다.

한 직원이 말했다.

“이제 좀 쓸 만합니다.”

Elena는 기뻐하지 않았다.

“아직 특정 고객 환경에 편향됐습니다.”

Daniel이 물었다.

“성능 좋아졌는데.”

“현재 데이터에서요.”

“외부 검증?”

“필요합니다.”

Elena는 익명화 가능한 벤치마크 구조를 제안했다.

실제 고객 데이터는 공개 못 한다.

대신 특징을 합성하거나 공개 워크로드로 재현.

Daniel이 말했다.

“경쟁사도 쓸 수 있는데.”

Elena가 그를 봤다.

“우리가 진짜 잘하면 남이 검증해도 남습니다.”

“안 잘하면?”

“빨리 알아야죠.”

Daniel은 웃었다.

이 사람은 회사 사람인지 심사위원인지 헷갈렸다.

그 점이 좋았다.

외부 테스트에서 성능이 떨어졌다.

예상대로.

내부 실패 87퍼센트 포착.

외부 공개 워크로드에서는 61퍼센트.

Daniel의 표정이 굳었다.

“왜 이렇게.”

Elena는 오히려 만족했다.

“좋네요.”

“뭐가 좋습니까?”

“우리가 과적합했다는 걸 찾았잖아요.”

Daniel은 화면을 봤다.

내부에서는 훌륭.

외부에서는 평범.

A1과 닮았다.

자기 환경에서 잘된다고 세상에서도 잘되는 건 아니다.

원인을 분석했다.

Helioxen 고객은 특정 산업과 소프트웨어에 편중.

공개 워크로드는 다름.

모델은 회사의 현재 고객을 잘 배웠다.

일반적인 계산실패를 배운 건 아니었다.

Daniel이 말했다.

“데이터 넓힙시다.”

“어떻게?”

Elena가 물었다.

“더 많은 고객.”

이선이 들어오다 말했다.

“연구하려고 영업 늘리는 거냐?”

회의실에 웃음.

Daniel은 고개를 저었다.

“외부 협력.”

Elena는 오픈 벤치마크 제안을 했다.

다른 연구팀과 실패패턴을 공유.

민감한 코드가 아니라:

- 오류유형

- 워크로드 특성

- 재현가능 사례

Daniel은 동의했다.

몇 달 전이라면 망설였을 것이다.

이제는 검증이 빨라지는 가치도 알았다.

그리고 이 프로젝트에는 아주 중요한 변화가 하나 있었다.

Daniel이 모델구조를 직접 정하지 않았다.

Elena와 연구팀이 했다.

그는 질문만 했다.

“이걸 틀렸다고 만드는 데이터는?”

Elena가 웃었다.

“좋은 질문이네요.”

Daniel도 웃었다.

“어디서 배웠습니다.”

“누구한테요?”

Daniel은 첫 거래일지를 떠올렸다.

“예전의 저한테.”

첫 프로젝트의 결과물은 화려한 AI가 아니었다.

실패를 미리 경고하는 작은 모델.

하지만 Daniel은 그걸 꽤 중요하게 봤다.

성공을 예측하는 것보다 실패를 일찍 보는 시스템.

그건 2046년까지 수없이 필요할 것이다.

첫 운영시험에서 모델이 낸 오탐 하나는 생각보다 비용이 컸다.

고객의 긴 작업.

모델 위험경고.

예상: 메모리 부족 가능성 높음.

운영팀은 작업을 멈추고 설정을 확인했다.

메모리를 더 큰 노드로 옮겼다.

결과.

원래 노드에서도 충분했을 작업.

고객 완료시간이 40분 늦어졌다.

Daniel이 물었다.

“모델 때문에 늦은 겁니까?”

운영담당이 고개를 끄덕였다.

“실패는 안 했습니다.”

“근데 안 실패할 작업을 건드렸고.”

“네.”

Elena는 이 사건을 중요하게 봤다.

“오탐 비용입니다.”

Daniel은 숫자표를 봤다.

모델은 실패를 놓치지 않으려고 민감하게 만들수록 정상 작업도 위험하다고 말한다.

너무 둔하면 실패를 놓친다.

정답 하나가 없다.

운영팀이 물었다.

“어느 쪽이 더 중요합니까?”

Daniel은 바로 ‘실패 놓치지 않기’라고 하려 했다.

Elena가 먼저 말했다.

“작업 종류마다 다릅니다.”

긴 고비용 작업.

실패를 막는 게 중요.

짧고 재실행 쉬운 작업.

오탐으로 멈추는 비용이 더 클 수 있다.

그들은 하나의 임계치를 버렸다.

작업비용과 재실행비용에 따라 경고정책을 다르게 했다.

Daniel이 말했다.

“모델은 같은데 운영정책이 다르네요.”

“예측하고 행동은 다른 문제니까요.”

Elena가 대답했다.

또 경계.

Prediction.

Decision.

의료에서 추천과 임상결정.

연구에서 예측과 과학설명.

이번에는 예측과 운영행동.

Daniel은 점점 이 경계들이 중요하다고 느꼈다.

며칠 뒤 반대 사례.

모델이 고위험으로 표시한 작업.

운영자가 로그를 보고 말했다.

“또 오탐 같은데.”

그냥 돌리려 했다.

새 직원이 매뉴얼을 보고 재확인.

라이브러리 버전 불일치 발견.

실행했으면 두 시간 뒤 실패할 가능성이 높았다.

사전에 수정.

작업 정상.

운영팀 분위기가 달라졌다.

모델이 맞은 사례.

그러나 Elena는 또 경고했다.

“이거 하나 맞았다고 임계치 더 낮추지 마세요.”

Daniel이 웃었다.

“제가 할 말 예상합니까?”

“요즘 조금.”

“위험하네요.”

“대표님보다 데이터 먼저 봅니다.”

Daniel은 그 말을 듣고 웃었지만 73화에서 그 문장이 더 아프게 돌아올 거라고는 아직 몰랐다.

첫 달 운영리뷰.

모델이 만든 절약시간 추정.

사전 수정으로 피한 실패.

오탐 때문에 늘어난 지연.

둘 다 계산했다.

순효과는 플러스.

작지만 분명했다.

Daniel이 물었다.

“이걸 제품 기능으로 팔 수 있습니까?”

Elena가 바로 말했다.

“또 제품화?”

회의실 웃음.

Daniel이 손을 들었다.

“질문입니다.”

“아직은 서비스 내부도구가 낫습니다.”

“왜?”

“사용자가 경고를 어떻게 해석해야 하는지 아직 배우는 중입니다.”

맞았다.

모델만 떼어 팔면 고객은 임계치와 행동정책까지 새로 만들어야 한다.

A1이 다시 된다.

Daniel은 고개를 끄덕였다.

“내부도구.”

이번에는 쉽게 받아들였다.

실패예측 모델은 돈을 직접 받지 않았다.

대신 Helioxen 서비스의 실패율과 재실행비용을 조금 줄였다.

그게 충분했다.

모든 기술이 독립제품일 필요는 없다.

회사 내부의 능력으로 남는 기술도 있다.

Daniel은 이 구분을 점점 자연스럽게 받아들이고 있었다.