ORIGINAL FICTION
제153화 — 열린 규격
지난 화 끝부분 다시 보기
Helioxen의 첫 공개 산업규격 회의에는 경쟁사도 왔다.
Daniel은 그게 아직도 이상했다.
회의실 한쪽.
자기 고객.
반대쪽.
자기와 같은 고객을 노리는 회사.
가운데.
공통 규격.
Ethan이 말했다.
“네가 초대한 거잖아.”
“알아요.”
“그런데 왜 싫은 표정.”
“본능.”
Ethan이 웃었다.
규격 대상은 거창하지 않았다.
계산장비의 상태정보.
작업큐.
전력.
열.
오류.
제조공장과 연구소가 서로 다른 장비를 연결하려면 공통으로 알아야 할 최소 데이터.
Helioxen이 첫 삶에서 내부적으로 만든 것과 비슷하다.
차이.
이번에는 처음부터 공개.
Daniel은 초안을 너무 자세하게 만들었다.
Rachel이 절반을 지웠다.
“왜요?”
“Helioxen 구현 설명입니다.”
“필요한 기능인데.”
“다른 회사가 같은 방식으로 만들 필요는 없습니다.”
Daniel이 문서를 다시 봤다.
표준은 답을 지정하는 게 아니다.
인터페이스를 지정한다.
입력.
출력.
안전조건.
그 안은 자유.
회의 첫날부터 충돌.
경쟁사 대표가 말했다.
“Helioxen이 이미 구현한 규격을 왜 표준으로 받아들여야 합니까?”
합리적.
Daniel이 말했다.
“받지 마세요.”
회의실이 조용해졌다.
“초안을 가져온 겁니다. 더 나은 안 있으면 바꿉니다.”
상대가 의심스러운 얼굴.
실제로 바뀌었다.
필드 이름.
전력상태.
오류코드.
Helioxen 방식 일부 삭제.
Daniel은 불편했다.
자기 시스템과 완벽히 맞지 않는다.
Helioxen도 수정해야 한다.
비용.
하지만 그게 표준.
공통소유.
두 번째 회의.
표준위원회 의장을 Daniel이 맡지 않았다.
외부 연구기관의 시스템 엔지니어.
Helioxen 한 표.
경쟁사 한 표.
고객.
공급업체.
Daniel은 뒤쪽에 앉았다.
이선이 물었다.
“기분 어때.”
“제 회사 기술인데 제가 결정 못 합니다.”
“목표 달성.”
Daniel이 웃었다.
“네.”
첫 규격 v0.1.
완벽하지 않다.
세 회사 구현.
상호연결 시험.
첫날 실패.
데이터는 읽힌다.
의미가 다름.
`available power`
한 회사는 최대 설계전력.
다른 회사는 현재 사용 가능한 추가전력.
기억 속 병원 프로젝트에서 겪었던 `available bed`와 같은 문제.
Daniel은 웃었다.
“40년 지나도 똑같네.”
Rachel이 물었다.
“뭐가요?”
“정의.”
의미를 다시 맞췄다.
필드에 단위.
시간범위.
정확도.
unknown 허용.
Elena와 Mina가 가르친 모든 게 아직 만나지도 않은 팀의 표준에 들어간다.
Daniel은 가끔 죄책감을 느꼈다.
그들의 아이디어를 훔치는 건가.
아니다.
자기가 배운 것.
경험.
그래도 출처를 기억했다.
OICI 회의에서 가장 큰 논쟁은 기술이 아니라 라이선스였다.
누가 규격을 소유하는가.
Helioxen?
위원회?
재단?
경쟁사는 Helioxen 소유를 싫어했다.
Daniel도 이제 싫었다.
결론.
독립 비영리 표준기구.
상표와 규격 저작권도 그쪽.
Helioxen은 초기 기여자.
그 이상 아님.
Ethan이 말했다.
“너 이번엔 진짜 모든 걸 회사 밖으로 빼네.”
“표준은 그래야 합니다.”
“누가 나중에 엉망으로 바꾸면?”
“투표.”
“우리가 지면.”
“따르거나 포크.”
Ethan은 고개를 저었다.
“민주주의 싫어할 얼굴인데.”
Daniel이 웃었다.
“느려서 싫어합니다.”
“근데 한다?”
“대체가 더 위험해서.”
첫 표준기구 회의에는 작은 회사 대표도 대기업과 같은 발언권을 일부 가졌다.
Daniel은 답답했다.
한 회사가 사소한 필드명 때문에 40분.
다른 회사는 단위 표현.
시간이 아깝다.
그런데 회의 끝에 Helioxen이 놓친 두 가지 문제가 나왔다.
유럽 일부 장비의 전력표현 방식.
레거시 연구기기의 null 상태.
Daniel은 인정했다.
자기 팀만 만들었으면 놓쳤다.
느린 합의가 더 넓은 현실을 담는다.
규격 v0.3부터는 `unknown`이 공식 상태가 됐다.
예전처럼 0이나 false로 채우지 않는다.
Daniel은 그 항목을 보며 Mina와 Elena를 떠올렸다.
모른다고 말할 수 있는 시스템.
사람들이 계속 같은 교훈을 준다.
어느 날 경쟁사 엔지니어가 Helioxen 버그를 발견했다.
공개 테스트 스위트.
특정 상태전환에서 오류.
게시판에 이슈.
누구나 본다.
Helioxen 개발팀은 당황했다.
“비공개 보안채널로 먼저 줬으면.”
Daniel이 물었다.
“보안문제?”
“아닙니다.”
“그럼 공개면.”
고쳤다.
감사.
경쟁사 이름 크레딧.
다음 주 그 경쟁사 제품에서 다른 버그.
이번엔 Helioxen 엔지니어가 발견.
같은 방식.
공개.
Daniel은 이 장면이 이상하게 좋았다.
경쟁하면서 서로 고친다.
제로섬이 아니다.
물론 영업에서는 서로 고객 뺏는다.
가격도.
그래도 공통 기반은 같이 강해진다.
이선이 말했다.
“너무 이상적인 거 아니야?”
Daniel은 고개를 저었다.
“표준 위에서는 싸우면 됩니다.”
바닥이 무너지면 모두 손해.
이 철학은 나중에 우주에도 적용할 생각.
추진 인터페이스.
탑재물.
궤도 데이터.
그러나 너무 빨리 다 열지는 않는다.
보안.
안전.
지식재산.
각각 경계.
첫 삶 Elena가 가르친 것.
공개는 선악 문제가 아니다.
검증이익과 비밀가치의 균형.
Daniel은 아직 Elena를 만나지 않았는데 그 철학은 이미 회사 안에 있다.
그게 가끔 죄책감.
Daniel은 그 생각을 Rachel에게 털어놓지는 않았다.
대신 현재 팀이 자기 방식으로 다시 검증하도록 했다.
“왜 공개합니까?”
질문.
“내가 원해서” 금지.
팀이 현재 근거를 만들지 못하면 공개하지 않는다.
그렇게 하면 과거의 교훈이 현재의 교리가 되는 걸 막을 수 있다.
OICI 1.0 발표.
Daniel은 무대에 서지 않았다.
독립 표준기구 의장이 발표.
Helioxen 로고도 첫 페이지 구석.
작음.
Daniel은 객석에서 박수쳤다.
이전 삶이었다면 Helioxen 이름이 표준과 함께 기억되는 걸 원했을지도 모른다.
이번에는 반대.
표준이 Helioxen보다 오래 살아남으면 좋다.
그게 성공이었다.
공식 문서에는 현재 기여자만 기록.
마음속에는 다른 사람도.
v0.2.
상호운용.
성공.
경쟁사 장비가 Helioxen 소프트웨어와 연결.
Helioxen 고객이 다른 회사 장비를 추가.
문제 없음.
Daniel은 매출을 계산했다.
하드웨어 매출 일부 줄었다.
소프트웨어·통합 매출 증가.
Ethan이 말했다.
“돈도 나쁘지 않네.”
“다행입니다.”
“돈 안 돼도 했을 거잖아.”
“네.”
“그게 걱정.”
Daniel이 웃었다.
규격 공개 뒤 예상 못 한 일이 생겼다.
유럽의 작은 제조소프트웨어 회사가 자기 제품에 규격을 지원.
Helioxen과 아무 계약도 없음.
또 다른 아시아 장비업체가 지원.
Daniel은 알지도 못하는 회사들.
생태계가 자라기 시작했다.
Daniel이 말했다.
“이게 더 빠를 수도 있네요.”
Ethan이 놀랐다.
“분산이?”
“우리 사람만 일하는 게 아니니까.”
중앙집중은 초기 결정이 빠르다.
개방형 생태계는 합의가 느리다.
그러나 합의 뒤에는 여러 회사가 동시에 개선한다.
Daniel은 처음으로 그 가속을 봤다.
첫 삶에서 Helioxen이 모든 걸 잘해서 빨랐다.
이번에는 Helioxen이 아닌 사람들도 움직여서 빨라질 수 있다.
그 차이는 중요했다.
규격 이름에는 Helioxen을 넣지 않았다.
`Open Industrial Compute Interface`
OICI.
Ethan이 말했다.
“이름 못 짓는 재능은 그대로네.”
Daniel이 웃었다.
“Vogel이 있었으면 더 평범하게 지었을 겁니다.”
“누구?”
Daniel의 얼굴이 굳었다.
“아는 제조 엔지니어.”
거짓말.
아직 모르는 사람.
Ethan은 잠깐 봤지만 넘어갔다.
Daniel은 마음속으로 경고했다.
기억 속 사람을 현재보다 먼저 말하지 않는다.
그날 규격 첫 페이지에 쓴 문장.
No implementation is the standard.
어떤 회사도.
Helioxen도.
표준 그 자체가 아니다.
2046년 마지막 9시간 17분을 다시는 만들지 않기 위한 첫 작은 장치였다.
읽은 화로 기록했습니다. 다음 화는 바로 이어집니다.