JStory Box
별의 제국
001 / 130LONG-FORM EDITION

ORIGINAL FICTION

제166화 — 같은 규격, 다른 답

14,610일 · 166 / 287약 8분0자
지난 화 끝부분 다시 보기

OICI 2.0 상호운용 시험은 시작 11분 만에 멈췄다.

Daniel은 화면을 봤다.

세 회사.

같은 규격.

같은 입력.

서로 다른 출력.

Helioxen: `AVAILABLE`

싱가포르 파트너: `DEGRADED`

유럽 제조소프트웨어 회사: `UNKNOWN`

Ethan이 말했다.

“같은 규격이라며.”

Daniel이 웃었다.

“그래서 시험합니다.”

문제는 `available capacity`.

Helioxen은 현재 여유자원.

싱가포르 팀은 현재 여유에서 안전마진을 뺀 값.

유럽 회사는 필요한 입력 일부가 없으면 `unknown`.

모두 규격문서를 읽고 자기 방식으로 구현.

누구도 틀렸다고 하기 어렵다.

Rachel이 말했다.

“정의가 부족합니다.”

Daniel은 예전 의료 프로젝트의 병상정의를 떠올렸다.

초기 OICI 설계 때도 같은 일이 있었다.

같은 문제.

표준이 생겼다고 의미가 자동 통일되는 건 아니다.

위원회 긴급회의.

세 구현팀.

고객.

안전.

첫 제안.

필드를 더 세분.

`physical spare`

`operational spare`

`committed spare`

Daniel이 말했다.

“복잡해집니다.”

Elena가 원격으로 말했다.

“현실이 복잡합니다.”

Helioxen 직원이 아니면서 회의에 자연스럽게 들어와 반대.

Daniel은 그게 좋았다.

다른 회사 엔지니어가 말했다.

“세 개 다 필요 없습니다. 현재 여유와 예약량이면 계산 가능.”

또 다른 안.

논쟁.

결론.

두 기본 필드.

필요한 곳만 확장.

그리고 `unknown`은 허용.

Daniel이 고개를 끄덕였다.

표준은 모든 해석을 하나로 만들지 않는다.

다른 구현이 최소한 서로 오해하지 않을 정도.

재시험.

이번엔 세 시스템이 같은 의미범위.

숫자는 다름.

왜?

스케줄링 정책.

Helioxen은 긴 작업 우선순위 낮춤.

파트너는 에너지비용 우선.

유럽 회사는 납기 SLA 우선.

Daniel이 말했다.

“이건 맞출 필요 없습니다.”

Rachel이 웃었다.

“이제 이해하시네요.”

같은 인터페이스.

다른 정책.

고객이 선택.

상호운용 시험 두 번째 단계.

작업 하나를 Helioxen에서 파트너로 넘긴다.

컨테이너.

데이터.

권한.

실행.

문제.

소프트웨어 환경 버전.

표준에는 응용환경 전체가 포함되지 않았다.

작업 실패.

Daniel이 얼굴을 찌푸렸다.

“이건 우리 책임?”

파트너 엔지니어가 말했다.

“둘 다.”

Helioxen이 실행환경을 충분히 기술하지 않음.

파트너도 자동검증 부족.

Elena가 말했다.

“좋은 실패.”

Ethan이 웃었다.

“그 말 싫어.”

Daniel도.

실행환경 명세.

해시.

라이브러리.

하드웨어 요구.

하지만 특정 공급사 제품명은 넣지 않는다.

표준화.

재시험.

작업 이동.

성공.

시간.

원래보다 18퍼센트 느림.

Daniel이 말했다.

“너무 느린데.”

Rachel이 말했다.

“첫 이동.”

상호운용 시험 보고서를 공개하자 예상 밖의 반응이 나왔다.

한 고객이 물었다.

“Helioxen 시스템보다 파트너 시스템이 더 느린데 왜 써야 합니까?”

Daniel은 대답하려 했다.

resilience.

분산.

독립.

Rachel이 먼저 말했다.

“항상 쓰라고 하지 않습니다.”

좋은 답.

“평소엔 더 빠른 걸 쓰시고, 문제 생기면 이동할 수 있다는 걸 사시는 겁니다.”

고객이 말했다.

“보험처럼?”

“네.”

Daniel은 고개를 끄덕였다.

독립 구현은 주력과 완전히 같은 성능일 필요 없다.

최소기능.

전환가능성.

그게 가치.

다른 고객은 반대로 물었다.

“파트너 시스템이 더 싸면 Helioxen 안 써도 됩니까?”

Ethan이 Daniel 쪽을 봤다.

Daniel이 대답했다.

“네.”

영업팀 표정이 굳었다.

고객이 웃었다.

“이상한 회사네요.”

Daniel도.

몇 달 뒤 실제로 그 고객은 일부 워크로드를 파트너 쪽으로 옮겼다.

Helioxen 매출 감소.

대신 OICI 생태계 전체 사용량 증가.

이사회 회의.

한 이사가 말했다.

“생태계 지표가 우리 실적을 대신해주진 않습니다.”

맞다.

Daniel은 철학만으로 밀지 않았다.

Helioxen 수익모델도 바꿨다.

하드웨어 독점마진 대신: 통합. 고급운영. 보안. 검증. 고객지원. 고위험 산업.

고객이 다른 장비를 써도 Helioxen이 벌 수 있는 영역.

Rachel이 말했다.

“이게 더 어렵습니다.”

“압니다.”

“좋은 제품만으론 안 되고 서비스가 좋아야 해요.”

Daniel이 웃었다.

“그게 더 건강하죠.”

락인 대신 실제가치.

경쟁.

몇 달 동안 영업마진은 낮아졌다.

Ethan이 계속 불평.

Daniel도.

그런데 신규 고객 진입이 늘었다.

‘나가기 쉬운 계약’이 오히려 들어오기 쉽게 만들었다.

큰 고객 하나가 계약 이유에 썼다.

Vendor exit is operationally tested.

Daniel은 그 문장을 저장했다.

독립성이 비용만이 아니라 판매포인트.

좋다.

상호운용 시험은 기술팀 문화도 바꿨다.

개발자가 기능을 만들 때 묻는다.

“다른 구현이 이 데이터를 이해할 수 있습니까?”

“우리 서버 없으면?”

“이 필드가 없으면 unknown으로 버틸 수 있나?”

처음에는 리뷰 체크리스트.

나중에는 습관.

Daniel은 그걸 중요하게 봤다.

구조는 문서보다 사람 머릿속에 들어가야 오래 간다.

한 신입 개발자가 설계회의에서 말했다.

“이 기능은 Helioxen 전용으로 만들 이유가 없습니다.”

Daniel이 순간 기분이 좋았다.

자기 입으로 시킨 말이 아니다.

문화가 번진 것.

다만 모든 걸 공개하지도 않는다.

보안핵심.

고객기밀.

일부 최적화.

Helioxen만의 차별화.

Daniel은 팀에게 말했다.

“독립성과 경쟁력 둘 다 필요합니다.”

누군가 물었다.

“경계가 어디죠?”

Daniel이 웃었다.

“매번 판단.”

완벽한 원칙 하나 없음.

그게 현실.

그날 7일 독립시험 예비설계도 시작됐다.

24시간 성공.

다음은 72.

그 다음 7일.

Daniel은 시간을 늘릴수록 새로운 공통의존성이 나올 거라 예상했다.

Ethan이 말했다.

“일주일 끊었다가 진짜 고객 다 나가면?”

Daniel은 잠깐 생각했다.

“그럼 우리 가치가 그 정도였던 겁니다.”

Ethan이 욕했다.

Daniel은 웃었다.

강한 말.

실제로는 무섭다.

하지만 그 두려움까지 포함해 시험해야 한다.

독립성은 고객에게 선택권을 주는 순간에야 진짜가 된다.

두 번째.

9퍼센트.

세 번째.

4.

학습.

자동화.

Daniel은 화면을 오래 봤다.

지난 삶에는 Helioxen 내부 데이터센터끼리 이동.

빠름.

이번에는 경쟁사 인프라로.

조금 느리다.

하지만 Helioxen 데이터센터가 사라져도 작업은 계속.

그게 목적.

상호운용 시험 마지막 시나리오.

Helioxen 중앙서비스를 갑자기 끊는다.

파트너 두 곳.

독립.

작업큐.

일부 재배치.

고객 알림.

24분간 혼란.

그 뒤 안정.

Daniel은 말했다.

“24분.”

Rachel이 물었다.

“나쁩니까?”

“좋은데.”

Daniel은 지난 삶 2045년 11시간.

이번에는 2015년.

24분.

물론 규모가 다르다.

그래도 방향.

Daniel은 만족했다.

시험 보고서 첫 줄.

Same standard does not require same implementation.

두 번째.

Interoperability is proven by transfer, not documentation.

Daniel은 이 문장을 마음에 들어 했다.

문서로 호환된다고 말하는 건 쉽다.

실제로 넘겨봐야 한다.

이 원칙은 앞으로 제조.

우주.

전력.

의료.

모두에 적용할 수 있다.

Ethan이 말했다.

“그러다 세상 모든 걸 서로 바꾸게 만들겠네.”

Daniel이 웃었다.

“가능하면.”

“돈 많이 든다.”

“압니다.”

“회사도 덜 중요해지고.”

Daniel은 화면의 세 시스템을 봤다.

Helioxen 하나가 없어도 나머지 둘이 돌아간다.

“그게 좋습니다.”

Ethan은 여전히 완전히 이해하지 못했다.

그래도 이제 놀라지도 않았다.

이번 Daniel은 자기 회사가 덜 중요한 세상을 만들고 있었다.

END OF CHAPTER

읽은 화로 기록했습니다. 다음 화는 바로 이어집니다.

다음 화

읽는 흐름을 끊지 않고 바로 다음 화로 이어집니다.

읽던 위치를 저장했습니다.