제125화 — 한 번만 더 빨리

RD-2 네 번째 고고도 비행 준비.

이번에는 세 고객.

Stratos Labs.

대학 재료팀.

통신 하드웨어 스타트업.

총 탑재물은 질량 기준 안.

전력도.

데이터도.

통합은 복잡했다.

각 고객이 자기 장비를 마지막 순간까지 수정하려 했다.

통신 스타트업은 비행 5일 전 펌웨어 업데이트를 요청했다.

Daniel이 말했다.

“가능?”

탑재물팀이 말했다.

“기술적으로는.”

Reyes가 물었다.

“재시험?”

“필요.”

“시간?”

2일.

비행창까지 5일.

가능해 보인다.

고객은 강하게 원했다.

새 펌웨어가 핵심 실험.

Daniel은 승인하려 했다.

탑재물팀장이 말했다.

“이번에 하나 허용하면 다음 고객도 막판 변경합니다.”

Daniel이 멈췄다.

변경 동결 기준.

현재는 T-7일.

이번 요청은 T-5.

예외를 줄 것인가.

고객 대표.

“이 업데이트 없으면 실험 가치 절반입니다.”

계약.

Helioxen 귀책 아님.

그냥 기존 버전으로 날릴 수도 있다.

Daniel은 고민했다.

첫 고객이면 유연하게 해주고 싶다.

Reyes는 말하지 않았다.

결정은 계약·운영 문제.

경영팀.

영업: 예외 찬성.

운영: 재시험 가능.

안전: 기준 재검증 필요.

재무: 비용 고객 부담 가능.

Daniel은 말했다.

“한 번만.”

말하고 스스로 멈췄다.

`이번 한 번만.`

42화 A1 예산초과.

여러 번 썼던 문장.

위험.

“아니.”

Daniel이 말했다.

사람들이 봤다.

“예외 만들지 맙시다.”

고객은 실망.

“그럼 다음 비행으로 업데이트 버전.”

현재 비행은 기존 펌웨어.

고객이 잠깐 불만을 표시했지만 계약대로.

비행 전날.

다른 고객에서 센서 캘리브레이션 값 수정 요청.

T-1.

이번에는 바로 거절.

기준이 생기니 쉬웠다.

비행 당일.

기상 양호.

추적.

차량.

탑재물.

Go.

상승.

이번 목표고도 82킬로미터.

Daniel은 화면을 봤다.

71.3 통과.

75.

80.

최고.

82.4.

하강.

열환경 예상보다 조금 높음.

Amina 경고.

기준 안.

착륙.

성공.

세 고객 탑재물.

두 개 정상.

막판 변경 동결규칙은 고객에게만 적용되는 게 아니었다.

Helioxen 내부도.

비행 T-7일부터 소프트웨어·하드웨어 변경은 등급별 승인.

Critical.

Safety.

Mission.

Cosmetic.

Daniel은 분류표를 보고 말했다.

“이거 너무 관료적인 거 아닙니까?”

Reyes가 말했다.

“비행체를 매일 고칠 겁니까?”

“좋은 개선이면.”

“다음 비행에.”

Daniel은 입을 다물었다.

개발자는 항상 더 좋은 걸 본다.

그걸 모두 지금 넣으면 검증은 영원히 끝나지 않는다.

첫 적용.

제어팀에서 T-4일 작은 알고리즘 개선 제안.

시뮬레이션상 착륙 연료 0.7퍼센트 절감.

Daniel이 좋아했다.

Reyes는 물었다.

“현재 비행에 필요한가?”

아니다.

다음.

`defer`.

Daniel의 표정이 아쉬웠다.

비행 후 실제 연료마진은 충분했다.

다음 릴리스에 개선.

두 번째.

T-2일 센서 필터 버그 발견.

특정 드문 조건에서 잘못된 상태전환 가능.

안전 관련.

변경 승인.

재검증.

비행 하루 연기.

Daniel은 받아들였다.

좋은 변경관리는 ‘아무것도 바꾸지 않는다’가 아니다.

무엇을 지금 바꿀 가치가 있는지 구분한다.

비행 82.4km 성공 뒤 변경목록을 다시 열었다.

연기했던 0.7퍼센트 개선.

추가 데이터와 함께 보니 실제 이익은 0.3퍼센트 수준.

우선순위 낮아짐.

Daniel이 웃었다.

T-4에 넣었으면 검증비용이 효과보다 컸을 수 있다.

한편 센서 버그 수정은 실제로 필요했다.

선택이 맞았다.

Reyes가 말했다.

“Freeze는 생각할 시간을 사는 겁니다.”

Daniel이 고개를 끄덕였다.

변경을 미루면 더 좋은 데이터로 다시 판단할 수 있다.

`Not now`와 같은 철학.

그날 사내 게시판의 ‘한 번만 빨리’ 문장 아래 누군가 댓글을 달았다.

한 번만 바꾸자도 비슷합니다.

직원들이 웃었다.

Daniel도.

이런 문장이 위에서 내려온 슬로건이 아니라 직원들 사이에서 생기기 시작했다는 게 좋았다.

문화가 복제되는 느낌.

그런데 같은 주 공급망 리뷰에서는 반대 신호가 있었다.

일부 외부업체가 Helioxen 변경동결 때문에 자기 일정이 더 빡빡해졌다고 말했다.

왜?

Helioxen이 일찍 사양을 동결하면 좋을 것 같지만, 동결 직전 주문이 몰렸다.

부품 확정.

한꺼번에 발주.

공급업체 피크.

Vogel이 말했다.

“우리 내부 안정이 외부 피크를 만든 겁니다.”

Daniel이 얼굴을 찌푸렸다.

어디서나 인터페이스.

한 팀의 좋은 절차가 다른 팀에 부담이 될 수 있다.

발주를 더 분산.

장기예고.

예상수요 공유.

동결 전 사전 물량범위 제공.

공급업체가 미리 준비할 수 있게.

Daniel은 깨달았다.

변경관리도 회사 경계에서 끝나지 않는다.

좋은 시스템은 이웃 시스템이 감당할 수 있는 방식으로 설계돼야 한다.

그렇지 않으면 안전을 한쪽에서 만들고 다른 쪽에서 없앨 수 있다.

통신 스타트업의 기존 펌웨어.

예상대로 데이터 일부 한계.

고객 대표가 말했다.

“업데이트 넣었으면 좋았을 텐데.”

Daniel도 그렇게 생각했다.

하지만 시스템은 예외를 허용하지 않았다.

그날 밤 놀라운 일이 생겼다.

통신 스타트업이 비행 데이터로 문제 원인을 더 잘 파악했다.

업데이트 아이디어 자체가 일부 틀렸다.

만약 T-5 변경을 허용했어도 원하는 결과가 안 나왔을 가능성.

고객 대표가 말했다.

“안 바꾼 게 오히려 나았네요.”

Daniel은 웃었다.

“운이 좋았습니다.”

중요한 표현.

규칙이 항상 정답을 보장한 건 아니다.

이번 결과가 좋았다고 모든 막판 변경을 영원히 금지하는 근거도 아니다.

다만 변경관리.

재시험.

동결.

이게 필요한 이유가 한 번 더 확인됐다.

정비.

열데이터.

일부 코팅영역이 이전보다 높은 온도.

Amina 추가검사.

정상.

다음 고도 상승 전에 TML-1에서 재현.

Daniel은 고개를 끄덕였다.

비행 다음날, 직원 게시판에 한 문장이 올라왔다.

“한 번만 빨리”가 반복되면 그게 표준이 된다.

누가 썼는지 몰랐다.

Reyes인지.

Vogel인지.

다른 직원인지.

Daniel은 사진을 찍었다.

자기 자신에게 가장 필요한 문장 같았다.

성공한 조직의 규칙은 큰 사고에서 무너지지 않는다.

작은 예외가 쌓여 무너질 수 있다.

이번 한 번.

이번 고객.

이번 일정.

이번 비행.

그걸 막는 건 기술보다 문화였다.

비행 후 변경관리 리뷰에서 고객 대표도 회의에 참여했다.

“우리 요청 때문에 비행 늦어질 수 있다는 걸 이제 압니다.”

그가 말했다.

“다음엔 T-10 전에 동결하겠습니다.”

Helioxen이 고객을 통제한 게 아니다.

고객도 절차를 배운다.

표준이 양쪽 행동을 바꾼다.

Daniel은 이 관계가 좋았다.

좋은 고객은 요구만 하는 사람이 아니라 같이 운영능력을 키우는 사람.

다음 Hosted Test Flight 계약부터 변경동결 일정이 계약 첫 장에 들어갔다.

그리고 고객에게도 예외를 요청할 수 있는 조건을 명시했다.

안전.

핵심 임무오류.

규제.

그 외는 다음 비행.

원칙이 투명해지자 막판 협상도 줄었다.

팀의 스트레스도.

Daniel은 작은 규칙 하나가 사람의 밤을 지킬 수 있다는 걸 봤다.

비행팀은 변경동결 기간에 ‘다음 비행으로 미룬 개선’도 별도 목록으로 관리했다.

미룬다고 잊지 않는다.

다만 현재 차량에 억지로 넣지 않는다.

Daniel은 그 목록을 보며 `Not now`가 또 다른 형태로 돌아왔다는 걸 느꼈다.

좋은 조직은 모든 좋은 아이디어를 지금 하지 않아도 된다.

그 원칙은 비행 준비회의 첫 화면에도 그대로 남았다.

작은 예외를 줄이는 일이 결국 큰 사고확률을 낮추는 일이었다.