제49화 — 남은 것

A1 제품은 죽었지만 팀은 바빠졌다.

오히려 전보다.

해체회의 다음날부터 재사용 가능한 걸 분류했다.

냉각.

전력관리.

작업 스케줄러.

모니터링.

드라이버 일부.

수치 라이브러리.

설치 자동화.

벤치마크 도구.

고객 포팅 경험.

대니얼은 목록을 보며 놀랐다.

“생각보다 많네요.”

팀장이 말했다.

“그래서 실패했다고 다 버리면 아깝죠.”

첫 번째 적용.

H-001 계열의 전력 스케줄러.

A1에서 만든 더 정교한 모니터링 코드를 옮겼다.

고객 시스템의 피크전력이 조금 내려갔다.

장애탐지도 빨라졌다.

두 번째.

설치 자동화.

A1 현장평가에서 고생하며 만든 환경검사 도구를 기존 제품 설치에 사용했다.

설치시간이 몇 시간 줄었다.

세 번째.

수치 라이브러리.

가속기 전용으로 만들었던 일부 코드는 CPU에서도 최적화 효과가 있었다.

대니얼이 말했다.

“이건 처음부터 했어도 됐겠는데.”

연구원이 웃었다.

“A1 안 만들었으면 안 했을 겁니다.”

맞았다.

실패 프로젝트가 현재 제품을 개선하고 있었다.

하지만 대니얼은 조심했다.

“그래도 실패는 실패입니다.”

“알고 있습니다.”

“자꾸 성공 스토리처럼 만들지 마세요.”

팀장이 말했다.

“대표님이 제일 그러실 것 같은데.”

대니얼은 반박하지 못했다.

사람은 실패에서 남은 것을 찾다 보면, 실패 자체를 합리화하기 쉽다.

그 경계도 필요했다.

A1 보드 두 대는 랙에 남았다.

내부 계산서비스 시험용.

서비스 아이디어는 단순했다.

고객이 장비를 사지 않는다.

Helioxen이 장비를 운영한다.

고객이 데이터를 보내면 계산 결과를 받는다.

문제는 2009~2010년의 현실이었다.

대용량 데이터 전송.

보안.

인터넷 속도.

고객 규정.

모든 고객에게 되는 모델이 아니었다.

대니얼은 이번에는 처음부터 시장을 좁혔다.

“누구한테 됩니까?”

영업팀이 답했다.

보안제약이 낮고.

데이터 크기가 상대적으로 작고.

계산량은 큰 곳.

대학.

초기 연구회사.

일부 소형 엔지니어링 팀.

“몇 곳?”

목록.

열다섯.

대니얼이 말했다.

“전부 연락합시다.”

이선이 물었다.

“제품부터 안 만들고?”

대니얼은 쓴웃음을 지었다.

“이번엔 물어봅니다.”

첫 전화.

“시간당 계산서비스 관심 있습니까?”

“가격은?”

가격부터 묻는다.

좋은 신호.

두 번째.

“데이터 외부로 보내도 됩니다.”

세 번째.

“시험계정 가능합니까?”

네 번째.

“우리 코드 설치해줄 수 있어요?”

다섯 번째.

“작업 하나만 맡겨보고 싶습니다.”

서비스 프로토타입을 만들기 전에 팀은 고객 데이터 하나를 받아 손으로 처리해봤다.

자동화하지 않았다.

일부러.

파일 받기.

환경 확인.

코드 설치.

작업 실행.

결과 검증.

전송.

처음부터 끝까지 사람이 해보니 어디서 시간이 사라지는지 보였다.

계산 자체는 두 시간.

준비가 세 시간.

결과 정리가 한 시간.

대니얼이 말했다.

“계산보다 주변이 더 길네요.”

지원담당이 웃었다.

“A1 때 배운 거 또 나오네요.”

전체 작업시간.

고객은 계산칩을 사는 게 아니다.

결과까지의 시간을 산다.

그들은 자동화 순서를 계산속도부터 잡지 않았다.

업로드 검사.

환경 템플릿.

작업 포장.

결과 전달.

주변을 먼저 줄였다.

첫 반복.

총 6시간.

두 번째.

4시간 20분.

세 번째.

3시간 15분.

A1 하드웨어는 그대로였다.

그런데 고객이 기다리는 시간은 거의 절반이 됐다.

대니얼은 그 결과가 충격적이었다.

자기는 반년 동안 하드웨어를 7배 빠르게 하려고 싸웠다.

실제 서비스는 파일처리와 자동화만으로 더 큰 체감효과를 만들었다.

기술적으로 덜 화려했다.

사업적으로는 훨씬 강했다.

“이걸 먼저 했어야 했네요.”

누군가 말했다.

대니얼이 고개를 저었다.

“아마 A1 실패 안 했으면 중요성을 몰랐을 겁니다.”

이번에는 그 말을 합리화가 아니라 사실로 느꼈다.

실패의 가치는 실패를 미화하는 데 있지 않다.

다음번 우선순위를 바꾸는 데 있다.

대니얼은 전화를 끊고 이선을 봤다.

이선이 웃었다.

“이번엔 반응이 다르네.”

“네.”

“왜?”

“고객이 장비를 안 사도 되니까.”

“그리고?”

대니얼이 생각했다.

“바꾸는 게 적습니다.”

고객이 자기 환경 전체를 바꾸지 않는다.

필요한 작업만 외부로 보낸다.

변화의 크기가 작았다.

그게 도입을 쉽게 했다.

그러나 서비스는 다른 문제를 만들었다.

데이터센터.

운영.

보안.

과금.

고객분리.

지원.

또 새로운 병목들.

대니얼은 웃었다.

“왜 웃어?”

이선이 물었다.

“다음 문제 보여서.”

“치료 안 되네.”

이번에는 대니얼도 웃었다.

그날 오후 A1 팀은 서비스용 작업큐를 만들기 시작했다.

기존 H-001 서버도 함께 묶었다.

A1이 잘하는 작업만 자동으로 가속기로 보낸다.

나머지는 범용 노드.

제품이 아니라 자원풀.

하드웨어 종류를 고객이 몰라도 된다.

대니얼은 구조도를 보며 말했다.

“이게 더 맞네요.”

연구원이 말했다.

“처음부터 이랬으면.”

대니얼이 고개를 저었다.

“처음부터는 몰랐을 겁니다.”

“고객들이 말했잖아요.”

정곡.

대니얼이 웃었다.

“알았는데 안 들었습니다.”

그 말도 이제는 조금 쉽게 할 수 있었다.

A1의 실패에서 남은 가장 중요한 건 냉각도 라이브러리도 아니었다.

고객이 하는 말을, 자기 미래기억보다 먼저 보는 습관.

그건 코드로 복사할 수 없는 자산이었다.

첫 유료 서비스 가격을 정하는 데도 논쟁이 있었다.

대니얼은 낮게 시작하고 싶었다.

고객을 빨리 늘리기 위해서.

이선은 반대했다.

“원가 계산했어?”

“시험단계니까.”

“시험도 전기 먹고 사람 쓰잖아.”

지원담당이 실제 시간을 계산했다.

데이터 확인.

환경 세팅.

실행.

오류대응.

결과전달.

계산장비 비용보다 사람 시간이 컸다.

대니얼이 놀랐다.

“이렇게 많이 듭니까?”

“아직 자동화가 덜 돼서요.”

가격을 너무 낮추면 고객이 늘수록 손실이 커진다.

A1과 반대의 함정.

A1은 안 팔려서 문제.

서비스는 팔려도 손해일 수 있다.

대니얼은 가격을 올렸다.

영업팀은 걱정했다.

첫 고객에게 견적을 보냈다.

대답.

생각보다 비싸네요. 그래도 내부 장비 구매보다는 낫습니다.

그리고 주문.

대니얼은 그 문장을 여러 번 읽었다.

비싸도 가치가 있으면 산다.

싼 게 답도 아니었다.

다음 고객은 가격 때문에 거절했다.

그것도 괜찮았다.

모든 고객이 맞는 고객일 필요는 없다.

서비스팀은 첫 세 작업을 손으로 돌리면서 각 단계 시간을 쟀다.

Daniel은 ‘계산시간’만 보지 말라고 강조했다.

업로드부터 결과수령까지.

첫 번째 작업.

총 7시간 12분.

실제 계산 2시간 5분.

두 번째.

5시간 40분.

세 번째.

4시간 11분.

주변작업 자동화가 효과를 냈다.

대니얼은 수치를 보며 말했다.

“하드웨어 손 안 대고 세 시간 줄였네요.”

연구원이 말했다.

“대표님이 싫어하는 종류의 혁신.”

“제가 왜요?”

“멋이 없잖아요.”

사람들이 웃었다.

대니얼도 인정했다.

파일검사 자동화.

환경 템플릿.

결과압축.

화려하지 않았다.

하지만 고객은 체감했다.

한 고객이 이메일을 보냈다.

지난번보다 결과 받는 과정이 훨씬 편했습니다.

성능 몇 배라는 말이 없었다.

대니얼은 이상하게 그 칭찬이 더 좋았다.

그날 서비스팀은 처음으로 고객 세 곳의 반복 주문 가능성을 확보했다.

아직 작은 돈.

그러나 A1 선주문 0과는 전혀 다른 감각이었다.

시장은 조용히 ‘예’라고 말하고 있었다.

대니얼은 이번에는 그 말을 놓치지 않으려고 했다.

서비스팀 첫 주간회의에서 대니얼은 이번에는 성능그래프를 마지막에 보자고 했다.

첫 화면은 고객 반복주문 여부.

두 번째는 총 처리시간.

세 번째가 비용.

하드웨어 벤치마크는 맨 뒤였다.

회의 순서부터 바꾸는 작은 행동이었지만, Daniel에게는 사고순서를 바꾸는 연습이었다.