제32화 — 고객은 벤치마크를 사지 않는다

첫 시연은 실패하지 않았다.

그게 더 문제였다.

Helioxen의 시스템은 실제로 빨랐다.

기존 장비보다 평균 두 배 이상.

특정 작업에서는 세 배 가까이 빨랐다.

대니얼은 결과표를 들고 고객 사무실로 들어갔다.

자신 있었다.

“이 정도면 계약하시죠.”

사장은 결과표를 보더니 말했다.

“안 합니다.”

대니얼은 몇 초 동안 아무 말도 못 했다.

“왜요?”

“느려서.”

“기존보다 두 배 빠릅니다.”

“그 얘기가 아니고.”

사장이 화면을 돌렸다.

“우리 작업이 여기서는 잘 돌아가는데 이 모델은 실패했어요.”

대니얼이 확인했다.

특정 재료모델을 쓴 해석.

Helioxen 환경에서 작업이 중간에 멈췄다.

팀이 알고 있던 문제였다.

발생확률이 낮아서 후속 패치로 미루려 했다.

“수정 가능합니다.”

“언제?”

대니얼이 대답하기 전 사장이 말했다.

“우리는 오늘 일해야 합니다.”

대니얼의 입이 닫혔다.

“속도 두 배인데 열 번 중 한 번 멈추면, 우리 입장에선 느린 겁니다.”

정확했다.

벤치마크는 빨랐다.

업무는 불안정했다.

“그리고.”

사장은 전력비 추정치를 가리켰다.

“이거 맞아요?”

대니얼이 고개를 끄덕였다.

“기존보다 많이 먹네요.”

“속도가 두 배니까.”

“전기요금도 업무비용입니다.”

또 맞았다.

대니얼은 준비해온 발표자료를 천천히 덮었다.

첫 삶에서 그는 기술보고서의 성능수치를 수없이 봤다.

추력.

연산량.

효율.

질량.

하지만 고객은 다른 숫자를 봤다.

다운타임.

전기요금.

직원 교육시간.

유지보수.

“어떤 조건이면 사시겠습니까?”

대니얼이 물었다.

사장이 조금 놀랐다.

“지금부터 다시 영업하는 겁니까?”

“아뇨. 제품 조건을 묻는 겁니다.”

그는 손가락을 폈다.

“작업 실패율 지금의 절반 이하.”

하나.

“전력비 포함 총비용이 기존보다 낮을 것.”

둘.

“우리 엔지니어가 새 시스템 배운다고 일주일씩 날리지 않을 것.”

셋.

“그리고 밤에 문제 생겼을 때 전화받을 사람.”

넷.

대니얼이 메모했다.

“성능은요?”

사장이 웃었다.

“두 배면 충분하다고 했잖아요.”

대니얼은 이번에는 웃지 못했다.

사무실로 돌아오는 차 안.

이선이 운전했다.

대니얼은 계속 결과표만 보고 있었다.

“기분 나쁘냐?”

“조금.”

“벤치마크 이겼는데.”

“제품은 졌죠.”

“그게 사업이지.”

대니얼은 창밖을 봤다.

“미래에는 이런 시스템이 훨씬 빠릅니다.”

이선이 힐끗 봤다.

“또 미래.”

대니얼은 입을 다물었다.

이선은 그 말의 진짜 의미를 몰랐다.

“댄.”

“네.”

“고객은 미래 안 사.”

대니얼의 시선이 돌아갔다.

“뭐라고요?”

“자기 문제 해결해주는 걸 사지.”

그 문장이 바로 핵심이었다.

Helioxen으로 돌아오자 대니얼은 팀을 모았다.

성과표를 띄우지 않았다.

고객이 거절한 네 가지 이유를 띄웠다.

1. 안정성

2. 총비용

3. 교육

4. 지원

한 엔지니어가 말했다.

“성능은 통과네요.”

“네.”

제품 안정화 회의는 점점 재미없는 문제들로 가득 찼다.

“로그 파일 이름이 고객 환경에서 중복됩니다.”

“설치스크립트가 경로에 공백 있으면 깨집니다.”

“시간대 설정이 다르면 보고서 시간이 어긋납니다.”

대니얼은 처음 며칠 동안 이런 문제를 ‘나중에 고칠 것’로 분류하려 했다.

팀장이 막았다.

“이게 제품입니다.”

“핵심 기능은 아니잖아요.”

“고객한테는 핵심입니다.”

“계산은 잘되는데.”

“설치가 안 되면 계산을 못 하죠.”

대니얼은 입을 다물었다.

맞았다.

제품은 알고리즘 한 덩어리가 아니었다.

사람이 설치하고, 배우고, 쓰고, 고장 나면 복구하는 전체 경험이었다.

그날부터 버그목록에는 심각도만 있지 않았다.

고객이 실제로 일을 못 하게 되는 시간도 적었다.

작은 버그라도 현장에서 자주 만나면 우선순위가 올라갔다.

반대로 기술적으로 우아한 개선이라도 사용자가 거의 못 느끼면 뒤로 밀렸다.

대니얼은 이 순서가 마음에 들지 않을 때가 많았다.

미래를 만드는 느낌이 적었다.

하지만 매일 조금씩 제품이 실제 물건이 되어갔다.

일주일 뒤 고객 엔지니어 두 명을 Helioxen 사무실로 초대했다.

직접 써보게 했다.

첫 10분 만에 문제가 나왔다.

“이 메뉴 이름 무슨 뜻입니까?”

개발자가 설명했다.

고객 엔지니어가 말했다.

“그냥 ‘작업 제출’이라고 하면 안 돼요?”

개발자가 대답하려다 대니얼을 봤다.

대니얼은 웃었다.

“바꾸죠.”

또 하나.

상태코드.

숫자로만 표시돼 있었다.

“이거 누가 외웁니까?”

고객이 물었다.

지원담당이 메모했다.

대니얼은 옆에서 보고 있었다.

2046년의 시스템은 너무 많은 정보를 보여줬다.

전문가들은 알아봤다.

그러나 처음 보는 사람에게는 벽이었다.

좋은 시스템은 정보를 많이 보여주는 게 아니라, 지금 필요한 판단을 쉽게 만드는 시스템일 수도 있었다.

점심을 먹으며 고객 엔지니어가 대니얼에게 말했다.

“대표님은 성능 얘기만 할 줄 알았는데.”

“그렇게 보였습니까?”

“처음엔요.”

“지금은?”

“지금도 좀.”

둘이 웃었다.

대니얼은 기분 나쁘지 않았다.

적어도 변하고 있다는 뜻이었다.

그날 오후 그는 발표자료 첫 장을 바꿨다.

기존 문구:

Faster engineering computation.

새 문구:

Get the answer sooner.

이선이 보고 말했다.

“드디어 사람 말 하네.”

“이전 것도 사람 말입니다.”

“논문 사람.”

대니얼은 반박하지 않았다.

그런데 승인요청은 계속 쌓였다.

메뉴 이름.

문서 포맷.

지원정책.

대니얼은 계속 댓글을 달았다.

자신은 품질을 관리한다고 생각했다.

팀은 점점 대니얼이 답할 때까지 기다렸다.

아직은 아무도 크게 문제 삼지 않았다.

오히려 창업자가 세세하게 본다고 좋아하는 사람도 있었다.

그래서 더 위험했다.

“그럼 성능개선 멈춥니까?”

대니얼은 자동으로 ‘아니’라고 말하려 했다.

세 배.

다섯 배.

열 배.

미래를 생각하면 해야 한다.

그러나 고객이 원하는 건 아니었다.

“두 팀으로 나눕시다.”

직원들이 긴장했다.

또 병렬개발.

대니얼은 바로 덧붙였다.

“인원 추가는 없습니다.”

이선이 고개를 끄덕였다.

“한 팀은 제품 안정화. 한 팀은 연구.”

팀장이 물었다.

“누가 우선입니까?”

대니얼이 잠깐 생각했다.

“고객 납품 전까지는 제품.”

연구팀 직원 하나가 아쉬운 표정을 지었다.

대니얼이 말했다.

“연구를 버리는 게 아닙니다.”

“알아요.”

“아는 표정 아닌데.”

사람들이 웃었다.

분위기가 조금 풀렸다.

그날부터 Helioxen은 처음으로 ‘잘 돌아가는 것’을 성능과 같은 우선순위에 올렸다.

문제는 안정화가 재미없다는 것이었다.

재현이 안 되는 오류.

설정파일.

드라이버 충돌.

문서화.

설치절차.

미래 기술을 만든다는 느낌은 없었다.

대니얼은 셋째 날부터 직접 버그 목록을 보기 시작했다.

그리고 팀의 수정 요청에 댓글을 달았다.

처음에는 도움이 됐다.

그의 공학경험은 넓었다.

문제의 원인을 빨리 찾았다.

다섯째 날부터 요청이 대니얼에게 몰리기 시작했다.

“대표님 확인 대기.”

“대표님이 이 방향 보신다고 해서.”

“머서 승인 후 수정.”

대니얼은 그걸 좋은 현상이라고 생각했다.

문제가 빨리 모인다.

자기가 보면 빨리 결정한다.

일주일 뒤 팀장은 책상 위에 서류 세 장을 놓았다.

“이거 오늘 승인해주세요.”

“뭡니까?”

“전부 대표님이 보라고 한 것들.”

“메일로 보내면—”

“메일에도 스물일곱 개 있습니다.”

대니얼이 멈췄다.

“스물일곱?”

“네.”

이선이 지나가다 말했다.

“축하해.”

“뭘요?”

“네가 새 서버보다 바빠졌어.”

대니얼은 웃었다.

아직 농담으로 들렸다.

그게 문제의 시작이라는 걸 그때는 몰랐다.

며칠 뒤 고객은 수정된 시험버전을 다시 받았다.

이번에는 설치가 첫 시도에 끝났다.

고객 엔지니어가 말했다.

“이제 좀 제품 같네요.”

대니얼은 그 말이 벤치마크 3배보다 더 기뻤다.

제품은 빠른 코드가 아니라, 다른 사람이 자기 도움 없이 써도 되는 상태라는 뜻이었다.