워크어웨이 테스트 — 개발자가 사라져도 살아남는 소프트웨어 설계

아무도 대답하고 싶지 않은 질문

모든 소프트웨어 팀은 버스 팩터를 알고 있습니다. 진지하게 받아들이는 팀은 거의 없습니다.

버스 팩터는 프로젝트가 멈추기까지 몇 명이 버스에 치여야 하는지를 측정합니다. 대부분의 스타트업은 1명입니다. 대부분의 엔터프라이즈 팀은 2~3명입니다. 모두가 이것이 문제라고 동의합니다. 아무도 해결하지 않습니다.

저희는 그런 여유가 없었습니다.

저희의 소프트웨어 -- De Novo xGrid -- 는 재난 지역의 Raspberry Pi 장치에서 작동합니다. 야전 병원. 지진 후 커뮤니티 대피소. "벤더에게 전화하라"는 선택지가 없는 곳입니다. 전화 신호도 없고, 인터넷도 없으며, 벤더 자체가 더 이상 존재하지 않을 수도 있기 때문입니다.

그래서 저희는 버스 팩터 질문의 더 어려운 버전을 던졌습니다.

개발팀 전원이 내일 사라지더라도, 배치된 시스템이 무기한 계속 작동할 수 있는가?

"대체 인력을 고용할 때까지 며칠"이 아닙니다. 무기한입니다.

다섯 가지 테스트, 예외 없음

이를 워크어웨이 테스트(Walkaway Test)로 정식화했습니다. 모든 릴리스가 통과해야 하는 다섯 가지 인수 기준입니다. 이름은 의도적입니다. "재해 복구 테스트"나 "연속성 계획 검토"가 아니라 워크어웨이(떠나기)입니다. 개발자가 떠나고, 시스템은 계속 작동한다는 의미입니다.

WK01: 오프라인이 기본. 시스템은 네트워크 연결 제로 상태에서 운영되어야 합니다. "우아한 기능 저하"가 아닌 완전한 운영입니다. 저희의 15개 이상의 PWA 모두가 오프라인으로 작동합니다. 환자 등록, 약물 조제, 혈액 은행 관리, 수술 일정. 전부입니다. 네트워크는 보너스이지 요건이 아닙니다.

WK02: 엣지에서 허브 복구. 중앙 Raspberry Pi가 물리적으로 파괴되더라도, 생존한 휴대폰이나 태블릿이 이를 재구축할 수 있어야 합니다. 저희는 이를 구명보트 프로토콜(Lifeboat Protocol)이라 부릅니다. 간호사가 자신의 휴대폰에서 80달러짜리 새 Raspberry Pi로 두 개의 QR 코드를 스캔합니다. 데이터가 돌아옵니다. 불가사리가 팔을 재생하는 것처럼. 2026년 1월 26일, 12단계 테스트에서 검증했습니다. 통과율: 100%.

WK03: IT 의존성 제로. SSH 접근, 명령줄 개입, 로그 분석이 필요한 시스템은 이 테스트에 불합격합니다. 저희의 운영자는 간호사와 물류 담당자이지 엔지니어가 아닙니다. 모든 작업은 브라우저 인터페이스를 통해 이루어집니다.

WK04: 라이선스 잠금 없음. 서버 인증 통신 없음. 구독 검증 없음. 만료일 없음. 배치된 후 소프트웨어는 현장 팀의 것입니다. 저희 회사가 사라져도 소프트웨어는 영향받지 않습니다.

WK05: 인간이 감사 가능한 데이터. 소프트웨어를 더 이상 신뢰하지 못해도 데이터는 검증할 수 있습니다. 데이터베이스는 범용 도구로 열 수 있습니다. 모든 레코드에 타임스탬프와 운영자 ID가 있습니다. 자신의 데이터를 읽는 데 저희 소프트웨어가 필요하지 않습니다.

"버스 팩터가 무한대에 근접"이 실제로 의미하는 것

2026년 1월 27일, 다섯 가지 테스트를 모두 통과한 후 내부 로그에 한 줄을 기록했습니다.

Bus factor approaching infinity.

이것은 허세처럼 들립니다. 그렇지 않습니다. 이것은 정밀한 엔지니어링 선언입니다.

전통적인 버스 팩터는 사람을 셉니다. 3명이 떠나고 프로젝트가 죽으면 버스 팩터는 3입니다. 저희의 버전은 조직 자체에 대한 의존성을 셉니다. WK01~WK05 이후, 배치된 시스템은 De Novo Orthopedics에 대한 의존성이 제로입니다. 서버 없음, 라이선스 없음, 자격 증명 없음, 지속적 유지보수 없음. 버스 팩터는 몇 명이 떠날 수 있는가가 아닙니다. 회사 전체가 떠날 수 있는가입니다.

답은 "예"입니다.

불편한 설계 철학

대부분의 소프트웨어 비즈니스는 의존성 위에 구축됩니다. 반복 수익은 고객이 다음 달에도 필요로 하는 것에 의존합니다. 클라우드 호스팅은 벤더가 열쇠를 쥐고 있음을 의미합니다. 라이선스 서버는 규정 준수를 보장하며, 동시에 고객이 떠나지 못하게 합니다.

워크어웨이 테스트는 이를 뒤집습니다. 모든 설계 결정은 하나의 렌즈를 통해 평가됩니다. 이것이 사용자를 저희에게 더 의존하게 만드는가, 아니면 덜 의존하게 만드는가?

이것은 나쁜 사업처럼 들립니다. 실제로는 재난 지역에서 야전 병원을 운영하는 사용자에 대한 유일하게 정직한 접근법입니다. "그들은 우리가 필요하지만 연락할 수 없다"는 기능적으로 "그들은 소프트웨어가 없다"와 동일합니다. 충족될 수 없는 의존성은 의존성이 없는 것보다 나쁩니다. 적어도 소프트웨어 없이는 사람들이 종이를 사용할 줄 압니다.

여러분의 시스템을 위한 세 가지 질문

워크어웨이 사고방식의 혜택을 받기 위해 재난 의료 소프트웨어를 만들 필요는 없습니다. 여기서 시작하십시오.

네트워크 없이 시스템이 얼마나 오래 작동합니까? 답이 0이라면, 모든 네트워크 장애가 전면 장애입니다. 그것은 여러분이 내리고 있는 선택입니다.
데이터는 어디에 있으며, 누가 접근할 수 있습니까? 답이 "한 사람이 관리하는 하나의 클라우드 계정"이라면, 클라우드가 방지해야 할 바로 그 방식으로 위험을 집중시킨 것입니다.
사용자가 여러분의 도움 없이 모든 것을 내보낼 수 있습니까? 그렇지 않다면, 여러분은 제품을 판매하는 것이 아닙니다. 제품에 대한 접근권을 판매하는 것입니다. 이 둘은 윤리적 함의가 다른 별개의 것입니다.

워크어웨이 테스트는 테스트 방법론이 아닙니다. 여러분이 유지보수하기 위해 그 자리에 있지 않을 것이라고 가정한다면 무엇을 만들 것인가를 묻는 설계 철학입니다.

그 답은, 결국, 더 나은 소프트웨어입니다.