제174화 — 호환된다고 같은 것은 아니다

Lumen-1 성공 뒤 업계 분위기가 너무 빨리 낙관적으로 변했다.

기사.

`Rocket interoperability solved.`

Daniel은 제목을 보고 얼굴을 찌푸렸다.

“안 풀렸는데.”

Cole이 전화로 말했다.

“마케팅은 이미 풀었대.”

두 회사 모두 정정.

공통 인터페이스 검증.

일부 차량 전환 가능.

그 정도.

그런데 고객들이 바로 더 큰 걸 요구했다.

한 통신 스타트업.

위성 180kg.

세 차량 호환.

Daniel이 말했다.

“가능할 수도.”

Reyes가 표정을 봤다.

“또 빨라집니다.”

Daniel이 웃었다.

“시험부터.”

이번 위성은 전력요구 큼.

진동 민감.

배터리.

추진계.

Lumen과 다르다.

첫 차량 환경시험.

Helioxen.

통과.

Meridian.

배터리 구조진동 한계 근접.

세 번째 발사사.

음향 초과.

고객이 말했다.

“공통규격인데 왜.”

Reyes가 답했다.

“인터페이스만 공통입니다.”

같이 꽂힌다와 같은 환경에서 살아남는다는 다르다.

Daniel은 이 문장을 표준교육에 넣었다.

`Compatible is not identical.`

고객은 어댑터·보강으로 해결 가능.

무게 증가.

성능.

비용.

어디까지 공통성을 살 것인가.

경제문제.

Cole은 말했다.

“고객이 세 차량 다 필요 없으면 하나에 최적화하면 돼.”

Daniel이 동의.

상호운용은 의무가 아니다.

선택권.

중요.

모든 제품을 다중공급 가능하게 만들면 비용이 너무 커질 수 있다.

고객이 위험과 비용을 선택.

통신 스타트업은 두 차량 호환만.

세 번째 포기.

합리적.

Daniel은 만족했다.

다음 문제.

소프트웨어.

발사체별 telemetry 용어.

규격상 공통 코어.

확장필드.

고객 지상국이 Helioxen 확장필드를 쓰고 있었다.

Meridian으로 바꾸면 기능 일부 손실.

기술적 락인.

고객이 말했다.

“표준이라고 했잖아요.”

Daniel이 얼굴을 굳혔다.

Helioxen이 표준을 어긴 건 아니다.

확장 기능.

하지만 고객은 그걸 표준처럼 사용.

이게 지난 삶의 시작과 닮았다.

호환성 프로파일을 공개한 뒤 기업들은 예상대로 자기 강점만 광고했다.

`3-provider compatible`

큰 글씨.

세부를 보면: 기계 3. 전력 2. 환경 1. 계약 3.

Daniel이 말했다.

“이건 오해.”

표준기구는 표시규칙을 정했다.

총점 금지.

항목별.

그리고 `qualified`와 `interface-compatible` 구분.

마케팅팀들이 싫어했다.

고객은 좋아했다.

한 스타트업이 `3-provider compatible` 광고를 내렸다.

대신 정확히: `Mechanical interface: 3 providers. Full mission qualification: 1.`

정직.

판매가 줄까?

오히려 전문고객 신뢰 증가.

Daniel은 이걸 봤다.

좋은 정보표준은 기술뿐 아니라 시장언어도 바꾼다.

문제 하나 더.

환경시험을 매 발사사마다 반복하면 작은 고객은 돈이 없다.

표준 환경 `envelope`를 만들자.

세 발사사의 진동·음향·열을 합친 보수적 공통범위.

그 범위 통과하면 일부 차량특화 시험 면제.

Cole이 반대.

“너무 보수적이면 위성 무거워져.”

맞다.

또 트레이드.

두 등급.

Common envelope.

Provider-specific optimized.

고객 선택.

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

고속이 필요한 고객은 특정 차량 최적화.

유연성이 중요한 고객은 common.

마치 소프트웨어 portable vs optimized.

OICI 경험이 우주로.

그날 Reyes가 말했다.

“공통규격팀이 차량설계까지 침범하면 안 됩니다.”

왜?

차량들이 같은 방향으로 수렴할 수 있다.

독립성이 줄어듦.

공통 인터페이스가 너무 많은 내부 요구를 지정하면 다른 발사체가 결국 비슷해진다.

Daniel의 눈빛이 달라졌다.

좋은 지적.

표준은 접점만, 내부는 자유.

다시 명문화.

기계포트.

전원범위.

데이터 최소.

안전신호.

환경정보 형식.

그 이상은 회사별.

Cole은 좋아했다.

“내 로켓 건드리지 마.”

Daniel이 웃었다.

“우리도.”

이 차이가 나중 공통모드 위험을 줄인다.

서로 다른 엔진.

다른 공급망.

다른 소프트웨어.

같은 탑재물만 연결.

한 회사의 설계결함이 전체 산업에 퍼질 가능성 낮음.

물론 표준 자체 결함은 공통.

그래서 표준도 다중 검증.

공개 테스트.

변경관리.

Daniel은 끝없는 계층에 한숨.

“표준의 백업도 필요하고.”

Whitaker가 말했다.

“헌법도 수정절차가 있죠.”

Daniel이 웃었다.

기술표준을 헌법에 비교하는 건 거창하지만 비슷한 면.

여러 조직이 같이 쓰는 규칙.

한 사람이 마음대로 바꾸면 안 됨.

변경은 느리다.

그래서 안정.

그해 한 고객이 Helioxen 최적화 인터페이스를 선택.

성능 최고.

다른 발사사 전환 불가.

Daniel은 막지 않았다.

고객 선택.

계약서에 명시.

`provider-specific`.

몇 년 뒤 바꾸고 싶으면 비용 낸다.

투명.

그게 충분.

독립성은 모든 사람에게 강요하는 도덕이 아니다.

대가와 이익을 보이게 하고 선택 가능하게 하는 것.

Daniel은 이 원칙을 점점 중요하게 봤다.

자신이 과거 실패를 겪었다고 현재 모든 사람에게 최대 백업을 강요할 권리는 없다.

정보.

표준.

선택지.

그 뒤 선택은 현재 사람들의 몫.

그것도 사람의 agency를 존중하는 방식이었다.

확장기능이 사실상 표준이 되는 순간.

Daniel은 OICI 위원회와 우주 인터페이스 기구에 문제 제기.

확장필드에는 `portable / provider-specific` 표시 의무.

고객 UI에서도.

Daniel의 회사가 불리.

Helioxen 고급기능이 provider-specific로 보인다.

영업팀 반발.

“고객이 안 쓸 수 있습니다.”

Daniel이 말했다.

“그게 선택권입니다.”

몇 달 뒤 경쟁사도 같은 표시.

시장이 더 투명.

호환성 점수.

기본.

2-provider.

3-provider.

각 수준.

Daniel은 한 숫자 점수로 줄이는 걸 싫어했다.

그래서 프로파일.

mechanical.

power.

data.

environment.

contract.

각각.

고객이 본다.

이번에는 총점 함정을 피했다.

Elena가 그 문서를 보고 말했다.

“많이 배우셨네요.”

Daniel이 웃었다.

“누구한테요.”

Elena는 모른다.

Daniel이 그녀에게서 이미 40년을 배웠다는 걸.

“여러 사람.”

그가 답했다.

호환성은 동일성을 만드는 일이 아니다.

차이를 숨기지 않고 차이 사이를 이동할 수 있게 만드는 일.

이 원칙은 우주에서도, 제조에서도, 사람 관계에서도 비슷했다.

Daniel은 마지막 생각은 입 밖으로 내지 않았다.

Mina가 다른 도시에서 자기 삶을 살고 있어도 그 관계를 실패라고 부르지 않는 것처럼.

같지 않아도 연결될 수 있다.

그게 이번 세계의 구조였다.

호환성 프로파일은 얼마 지나지 않아 보험사 계약에도 들어갔다.

공급자 전환이 쉬운 탑재물은 일정지연 보험료가 조금 낮아졌다.

완전 미션 손실 위험과는 별개.

하지만 경제적 차이.

고객들은 더 진지하게 보기 시작했다.

Daniel이 말했다.

“이제 마케팅이 아니라 돈.”

Ethan이 만족한 표정.

“드디어.”

한 스타트업은 초기엔 특정 발사사 최적화를 선택했다.

성능.

싸다.

2년 뒤 투자유치 후 임무가 중요해지자 두 번째 공급자 qualification 추가.

표준 덕분에 전환 가능.

독립성은 처음부터 최대치로 살 필요 없다.

사업이 커지며 단계적으로.

Daniel은 이 구조가 좋았다.

사람과 회사의 성장에 맞춰 백업도 자란다.

미래를 안다고 현재 작은 회사에 문명종말급 기준을 강요하지 않는다.

현재 위험에 맞는 만큼.

그게 이번 삶에서 Daniel이 배운 절제였다.