제152화 — 작은 Helioxen

Helioxen이라는 이름을 다시 쓰는 데 Daniel은 반년이 걸렸다.

처음에는 쓰지 않으려 했다.

이름만 봐도 40년이 돌아왔다.

서버실.

로켓.

NEXUS.

Mina.

Evelyn.

Noah.

Reyes.

그리고 무너지는 천장.

다른 이름을 만들 수도 있었다.

Ethan은 말했다.

“이름이 뭐가 중요해.”

Daniel이 대답했다.

“저한텐 중요합니다.”

“그럼 버려.”

Daniel은 그러지 못했다.

Helioxen은 실패한 회사이기도 했다.

동시에 수백만 사람이 일했고, 문명을 살리려고 만든 기술이 쌓인 회사.

사라진 사람들의 시간을 이름째 없애고 싶지 않았다.

결국 다시 등록했다.

Helioxen Systems.

다만 처음부터 작게.

정관과 투자계약에 구조를 넣었다.

Helioxen이 직접 소유할 것:

- 시스템 통합

- 핵심 연구도구

- 공통 인터페이스 개발

- 일부 고위험 프로토타입

직접 소유하지 않을 것:

- 대부분의 제조

- 대규모 발전

- 지역 서비스 운영

- 장기적으로 발사 인프라 전체

Ethan이 문서를 보고 말했다.

“왜 회사가 자기 성장 제한을 계약에 써?”

“미래의 저를 못 믿어서.”

Ethan이 웃었다.

“그건 좋은 이유네.”

물론 법적으로 영원히 못 바꾸는 절대조항은 아니다.

그래서 이사회 구조.

독립사외이사.

파트너 대표.

표준위원회 분리.

Daniel 혼자 바꾸기 어렵게.

Ethan이 말했다.

“너 회사 만들기 전에 창업자부터 견제하네.”

“네.”

“정말 뭔 일 있었구나.”

Daniel은 대답하지 않았다.

첫 직원.

이전과 다르다.

Daniel은 과거 팀 사람을 찾아가지 않았다.

공개 채용.

현재 지원자.

과거에 없던 사람도 들어왔다.

첫 기술책임자는 Daniel 기억에 없는 사람이었다.

Rachel Singh.

분산시스템과 산업용 소프트웨어 경험.

Daniel은 면접에서 놀랐다.

자기가 미래에 만든 시스템과 다른 접근.

더 단순.

현재 하드웨어에 맞음.

채용.

Ethan이 말했다.

“옛날 지인 아니지?”

Daniel의 심장이 움직였다.

“무슨 뜻.”

“너 가끔 사람 처음 보면서 오래 본 표정 하잖아.”

Daniel은 웃지 못했다.

Rachel은 모르는 사람.

그래서 편했다.

현재가 새로 만든 사람.

첫 제품 방향.

고성능 계산.

여기까지는 이전과 비슷하다.

하지만 하드웨어를 Helioxen 전용으로 묶지 않는다.

서버 공급업체 세 곳.

네트워크 두 곳.

냉각 규격 공개.

운영 소프트웨어도 핵심 API 공개.

Daniel은 속도가 느려지는 걸 체감했다.

“이 부분은 통합하면 일주일.”

Rachel이 말했다.

“대신 고객이 다른 공급업체로 바꿀 수 있습니다.”

“알아요.”

“그게 목표라면서요.”

Daniel이 한숨.

“맞습니다.”

첫 고객이 요구했다.

“그럼 Helioxen 장비 안 사도 소프트웨어 씁니까?”

“네.”

고객이 놀랐다.

“왜 그렇게 팔죠?”

Daniel이 말했다.

“결과를 사시는 거니까.”

오래전 배웠던 문장.

이번에는 더 일찍.

고객은 Helioxen 하드웨어 대신 다른 공급사 서버를 선택했다.

Daniel은 묘한 질투를 느꼈다.

자기 회사가 돈을 덜 번다.

Ethan이 웃었다.

Helioxen Systems 첫 이사회에는 일부러 Daniel보다 지분이 적은 사람도 강한 권한을 가졌다.

기술안전.

감사.

공개표준.

이 세 영역.

Daniel이 단독으로 뒤집을 수 없게.

Ethan이 말했다.

“주주들이 나중에 싫어할 텐데.”

“그럼 처음부터 알고 들어와야죠.”

“투자받기 어려워.”

“그런 투자자는 안 받습니다.”

말은 쉽다.

실제로 돈을 덜 받을 수도.

기업가치도 낮아질 수 있다.

Daniel은 받아들였다.

첫 삶에는 Helioxen의 압도적 성장 자체가 신뢰를 만들었다.

이번에는 구조가 신뢰를 만들어야 한다.

첫 고객 실사.

상대가 물었다.

“Helioxen이 서비스 종료하면 데이터 가져갈 수 있습니까?”

“네.”

“다른 업체로?”

“표준형식.”

“계약 끝나도?”

“네.”

고객이 놀랐다.

대부분 회사는 락인을 만든다.

Helioxen은 일부러 낮춘다.

Ethan이 말했다.

“사업부가 싫어합니다.”

“알아요.”

“고객 평생가치 줄어.”

“대신 들어오기 쉬워집니다.”

실제로 그랬다.

작은 고객들이 계약을 덜 무서워했다.

나가기가 쉬우니까.

매출은 천천히.

해지율도 생각보다 낮음.

서비스가 좋으면 남는다.

Daniel은 그 구조가 마음에 들었다.

억지로 잡지 않는다.

사람 관계와 비슷하다는 생각이 들어 조금 웃겼다.

Rachel이 물었다.

“왜 웃어요?”

“아무것도.”

또 하나.

첫 삶 Helioxen은 내부 공통도구를 매우 강하게 통일했다.

이번에는 일부러 두 번째 구현을 허용.

개발팀이 불만.

“중복인데요.”

Daniel이 말했다.

“네.”

“유지보수 두 배.”

“핵심 기능만.”

표준 테스트는 하나.

구현은 둘.

한 팀이 패치.

다른 팀 독립 검증.

초기속도는 느림.

몇 달 뒤 첫 효과.

주 구현에서 메모리 누수.

백업 구현으로 일부 고객 이동.

서비스 중단 제한.

개발팀이 말했다.

“이제 왜 했는지 알겠습니다.”

Daniel이 웃었다.

2045년에 배울 걸 2010년에.

그게 회귀의 가치.

하지만 또 위험.

Daniel이 과거 답을 너무 쉽게 내놓으면 팀은 이유 없이 따라야 한다.

그래서 매번 근거를 현재 언어로 설명했다.

공통모드 실패.

업데이트 리스크.

고객 탈출권.

현재 산업에서도 충분한 이유.

Rachel이 어느 날 물었다.

“대표님은 왜 회사 팔기 어렵게 만드는 걸 좋아합니까?”

Daniel이 말했다.

“팔기 어렵게?”

“락인도 낮고. 표준도 공개고. 독점도 안 잡고.”

“회사를 팔 생각이 없어서.”

“그 뜻 말고요.”

Daniel은 생각했다.

이번 Helioxen의 가치는 독점이 아니라 신뢰와 통합능력에서 나와야 한다.

“고객이 나갈 수 있는데도 남는 회사를 만들고 싶습니다.”

Rachel이 고개를 끄덕였다.

“그건 멋있네요.”

Daniel은 순간 뜨끔했다.

멋있게 말하려 한 게 아니다.

그래도 좋았다.

현재 사람들이 Daniel의 과거 죄책감 때문이 아니라 현재의 좋은 이유로 구조를 받아들이기 시작한다.

그게 이번 회사가 진짜 현재에 뿌리내리는 신호였다.

“분산 좋아한다며.”

“좋아한다기보다 필요합니다.”

“그럼 참아.”

첫 설치.

문제.

공급업체 A와 네트워크 B의 드라이버 충돌.

통합회사가 하나면 Daniel이 내부팀 호출로 끝냈을 문제.

지금은 두 회사 회의.

책임경계.

계약.

느리다.

Rachel이 제안했다.

“Compatibility test suite 공개합시다.”

공급업체가 자기 제품을 미리 검증.

Helioxen만 테스트하지 않는다.

좋다.

테스트 스위트.

표준.

인증결과 공개.

경쟁사도 볼 수 있다.

Daniel은 잠깐 망설였다.

공개.

첫 삶의 Elena가 떠올랐다.

틀린 연구를 독점하는 것보다 낫다.

“공개.”

몇 달 뒤 공급업체 하나가 Helioxen보다 먼저 문제를 찾아 패치를 냈다.

다른 고객들도 쓸 수 있다.

Daniel은 화면을 봤다.

자기가 통제하지 않은 개선.

그게 기뻤다.

2010년.

Helioxen 직원 수는 첫 삶 같은 시기보다 적었다.

매출도.

기업가치도.

대신 호환 파트너는 더 많았다.

Daniel은 이선에게 말했다.

“느립니다.”

“네가 설계한 대로.”

“너무 느린 건.”

“또 바꿀래?”

Daniel은 숫자를 봤다.

고객 전환비용.

낮음.

공급업체 한 곳 장애 시 대체시간.

짧음.

Helioxen 서버 없이는 못 쓰는 고객.

거의 없음.

좋다.

“아뇨.”

Daniel이 말했다.

“계속.”

작은 Helioxen.

첫 삶의 거대한 Helioxen과 비교하면 초라하다.

그러나 Daniel이 사라져도 고객의 계산이 멈추지 않는다.

그게 이번 회사의 첫 성공이었다.