10.4 대규모 장수 시스템의 지속

개요와 동기

소프트웨어 엔지니어링에 관한 대부분의 글은 새것을 만드는 이야기입니다. 그러나 세계의 중요한 소프트웨어 대부분은 오래되고, 크고, 여전히 돌아가고 있습니다. 세금 시스템, 급여 지급, 항공 교통 관제, 핵심 금융, 산업 제어, 일상생활의 인프라입니다. 이런 시스템은 일상적으로 10년, 20년, 30년을 운영됩니다. 만든 사람 누구의 재직 기간보다 훨씬 길고, 그것을 낳은 회사와 언어보다 긴 경우도 많습니다. 이런 시스템을 지속한다는 것은 수십 년과 여러 세대의 직원에 걸쳐 신뢰할 수 있고, 안전하고, 이해되고, 변경할 수 있는 상태로 유지하는 것을 뜻합니다. 이 분야에서 가장 어렵고 가장 화려하지 않은 규율 중 하나이며, 큰 기업과 정부가 가장 무거운 짐을 지는 곳입니다.

큰 조직에서 이것이 더 중요한 이유는 무엇일까요? 의무의 연속성 때문입니다. 스타트업은 소프트웨어를 다시 쓰거나 버릴 수 있습니다. 한 나라의 정부는 리팩터링하는 동안 연금 지급을 멈출 수 없습니다. 기업과 기관은 실패의 결과가 생계, 안전, 공적 신뢰로 측정되는 시스템을 소유합니다. 그것도 한꺼번에 많이, 수십 년에 걸쳐 들고 나는 사람들이 운영합니다. 핵심 위협은 이국적이지 않습니다. 시스템을 이해하는 사람들의 느린 침식(버스 팩터, 시스템 지식이 사라지기까지 몇 사람이 떠나면 되는가), 소수의 머릿속에 쌓이는 문서화되지 않은 지식, 수명 종료를 향한 기술 스택의 부식, 시스템이 건드리기엔 너무 중요하고 안전하게 바꾸기엔 너무 이해되지 않을 때 닥치는 마비입니다.

이 장은 스튜어드십에 관한 것입니다. 시스템이 작성자보다 우아하게 오래 살도록 돕는 의도적이고 화려하지 않은 일입니다. 소유권 연속성과 버스 팩터 완화, 계획된 폐기 예고와 종료, 지식 이전, 수십 년 시스템의 독특한 과제, 혁신과 시민 및 고객이 의존하는 안정성을 보존하는 것 사이의 끊임없는 균형을 다룹니다.

핵심 원칙

모든 핵심 시스템에는 항상 소유자가 필요합니다. 소유권은 누가 썼는지의 기억이 아니라 지속적인 배정입니다.
한 머릿속에 사는 지식은 자산이 아니라 위험입니다. 그 사람이 떠나기 전에 이해를 제도화하십시오.
지루함은 기능입니다. 오래 사는 핵심 시스템에서는 안정성과 예측 가능성이 참신함보다 앞서는 경우가 많습니다.
끝을 처음에 계획하십시오. 모든 시스템은 폐기되거나 교체됩니다. 그날을 위해 설계하고 문서화하십시오.
변화가 안전을 지키는 방법입니다. 건드리기에 너무 무서운 시스템은 이미 실패하고 있습니다. 변경할 수 있는 능력은 생존 형질입니다.
연속성은 개인보다 오래갑니다. 어느 한 사람의 이탈이 위기가 되지 않도록 팀, 문서, 프로세스를 설계하십시오.
신뢰가 진짜 제품입니다. 시민과 고객을 대면하는 시스템에서는 시간에 걸쳐 유지되는 신뢰성과 공정성이 임무입니다.

권장 사항

스튜어드십과 소유권 연속성을 확립한다

중요한 모든 시스템에 명시적이고 현재인 소유권을 배정하십시오. 개인 수준이 아니라 팀 수준에서 소유해 이탈에도 소유권이 살아남게 하십시오. 시스템마다 누가 소유하고, 무엇을 하고, 무엇에 의존하고, 얼마나 중요한지 기록하는 서비스 카탈로그를 유지하십시오. 소유권을 정기적으로 리뷰하고 시스템이 고아가 되게 두지 마십시오. 소유자 없는 핵심 시스템은 일어나기를 기다리는 비상 사태입니다. 팀이 개편될 때는 가정이 아니라 인수인계로 의도적으로 소유권을 옮기십시오. 가장 중요한 오래 사는 시스템에서는 소유권이 운영만이 아니라 시스템을 이해하고 변경하는 능력을 포함하도록 해, 스튜어드십이 단순한 아이 돌보기로 퇴화하지 않게 하십시오.

버스 팩터와 핵심 인물 위험을 완화한다

지식의 집중을 적극적으로 측정하고 줄이십시오. 한 사람만이 시스템을 배포하거나, 디버그하거나, 변경할 수 있다면 그것은 어떤 하드웨어만큼 실제인 단일 장애 지점입니다. 짝 작업과 순환, 의무적 코드 리뷰, 공유 온콜, 어떤 핵심 작업도 정확히 한 사람만 할 수 있어서는 안 된다는 의도적 규칙으로 줄이십시오. 각 필수 기능을 적어도 둘(가급적 셋)이 수행할 수 있도록 교차 훈련하십시오. 핵심 인물의 이탈을 충격으로 받아내는 것이 아니라 지속적으로 대비하는 예견 가능한 사건으로 다루십시오. 문서화가 도움이 됩니다. 그러나 실제 실천으로 팀에 퍼진 실용 지식이 아무도 연습하지 않은 문서보다 훨씬 오래갑니다.

지식 이전을 제도화한다

사람과 함께 떠날 지식을 포착하십시오. 재구성하기 어려운 지식에 먼저 집중하십시오. 결정이 왜 내려졌는지, 어떤 대안이 왜 기각되었는지, 날카로운 모서리와 시스템의 나머지가 조용히 의존하는 핵심 꼼수가 어디에 있는지, 스트레스 아래서 시스템이 어떻게 행동하는지입니다. 선택만이 아니라 선택 뒤의 추론을 보존하도록 아키텍처 결정 기록을 쓰십시오. 런북과 운영 문서를 시스템 가까이에 두고 정기적으로 연습해 사실로 유지하십시오. 신규 스튜어드가 진정한 숙련에 이르게 하는 온보딩 경로를 만드십시오. 이탈을 실제 인수인계 시간이 있는 지식 이전 행사로 다루십시오. 시스템에 대한 감각인 암묵지는 그것을 가진 사람과 나란히 해 보면서 주로 이전된다는 점을 기억하고, 가능한 곳에서는 떠나는 스튜어드와 도착하는 스튜어드를 겹치게 하십시오.

폐기 예고, 종료, 수명 종료를 관리한다

끝을 의도적으로 계획하십시오. 시스템을 폐기하거나 교체하기로 결정하면 종료를 그 자체의 프로젝트로 다루십시오. 모든 소비자와 의존성을 식별하고, 이전 경로와 현실적인 일정을 제공하고, 분명하고 반복적으로 소통하고, 전환 동안 소비자를 지원하십시오. 아무도 옛것을 끄는 어려운 일을 하지 않으려 해서 옛 시스템과 새 시스템을 영원히 병행 운영하는 덫을 피하십시오. 폐기 완료에 대한 명시적 책임을 배정하십시오. 특히 법적 보존 규칙이 적용되는 곳에서는 시스템이 멈춘 뒤에도 오랫동안 데이터, 기록, 폐기된 시스템에 대한 질문에 답할 능력을 보존하십시오. 잘못된 종료는 유지되지 않지만 여전히 의존되는 좀비 시스템을 남깁니다. 최악의 조합입니다.

수십 년에 걸쳐 시스템을 지속한다

20년, 30년 돌아야 하는 시스템은 모든 것보다 오래 살 계획을 세우십시오. 원래 팀, 벤더, 언어 생태계, 하드웨어입니다. 미래의 유지 보수자에게 기회가 있도록 독점 블랙박스보다 개방형 표준과 문서화된 인터페이스를 선호하십시오. 모듈화해서, 시도하기엔 너무 위험한 전부 아니면 전무의 재작성이 아니라 부분을 하나씩 교체할 수 있게 하십시오. 시스템을 지속적으로 유지 보수하십시오. 작은 단계로 최신으로 유지된 시스템은 지속 가능하게 남습니다. “동작하니까” 동결된 시스템은 스택이 지원 밖으로 나이 들면서 조용히 유지할 수 없게 됩니다. 그것을 운영할 기술도 유지하십시오. 정말 오래된 기술이라면 마지막 전문가가 은퇴하지 않기를 바라는 대신 의도적으로 후임을 훈련하십시오.

혁신과 안정성과 신뢰의 균형을 잡는다

참신함이 가치를 만드는 영역과 안정성이 곧 가치인 영역을 구별하십시오. 시민과 고객이 매일 의존하는 핵심 시스템은 대개 신뢰성, 하위 호환성, 신중한 변경에 보상하며 흥미로운 재작성에는 보상하지 않습니다. 가장자리(새 채널, 새 기능, 새 인터페이스)에 혁신을 투자하고 지속되는 핵심은 안정적이고 잘 이해된 상태로 두십시오. 핵심도 바꾸되, 영웅적 도약이 아니라 작고 되돌릴 수 있고 잘 테스트된 증분으로 바꾸십시오. 목표는 믿을 수 있으면서 진화할 수 있는 시스템입니다. 썩을 만큼 얼어붙지도, 신뢰할 수 없을 만큼 휘둘리지도 않는 것입니다.

장단점

접근	장점	단점
옛 시스템을 유지하고 보수	제도적 지식 보존. 낮은 혼란. 입증된 신뢰성	늙어 가는 스택. 희소한 기술. 유지되지 않으면 쌓이는 위험
일괄 재작성	새 스택. 쌓인 군더더기를 털어 냄	매우 높은 실패율. 어렵게 얻은 예외 사례 지식을 잃음
점진적 현대화	지속적인 위험 감소. 계속 운영됨	느림. 지속적인 자금과 규율 필요
문서 중심 이전	명시적이고 검색 가능한 기록	유지되지 않으면 퇴색. 암묵지를 놓침
사람 기반 이전(짝 작업/순환)	지속되는 실용 지식. 회복력 있는 팀	현재 생산성 비용. 의도적 일정 필요
핵심 동결	단기적으로 최대 안정성	스택이 유지 불가능하게 늙음. 건드리기 너무 무서워짐

결정적인 상충은 안정성 대 진화이며, 순진한 해법은 둘 다 실패합니다. 핵심 시스템을 보호하려고 동결하면 결국 유지할 수 없고 안전하지 않게 됨을 보장합니다. 현대화하려고 통째로 다시 쓰면 일괄 교체가 악명 높은 높은 실패율을 부르고, 아무도 거기 있는 줄 기억하지 못하는 수십 년치 인코딩된 예외 사례 지식을 버리게 됩니다. 지속되는 길은 지속적이고 점진적인 변화입니다. 작은 단계로 시스템을 살아 있고 움직이게 유지해 지원 밖으로 나이 들지도, 무서운 도약이 필요해지지도 않게 하십시오. 지식 이전도 문서의 용이함과 체험의 지속성 사이의 비슷한 상충입니다. 답은 둘 다입니다. 체험하고 팀이 지닌 지식을 뼈대로, 문서를 참고로 삼으십시오.

팀과 논의할 질문

핵심 시스템 중 지금 현재의 이름 붙은 팀 소유자가 없는 것은 무엇입니까? 소유권은 누가 코드를 썼는지의 기억이 아니라 지속적인 배정이며, 소유자 없는 핵심 시스템은 고장 날 때에야 알아채는, 일어나기를 기다리는 비상 사태입니다. 서비스 카탈로그를 훑거나(없으면 만들어) 모든 시스템이 누가 소유하고, 무엇에 의존하고, 얼마나 중요한지 기록하는지 확인하십시오. 증거를 가져오십시오. 중요한 시스템 셋을 골라 책임 팀과 소유권을 마지막으로 리뷰한 때를 대 보십시오. 시스템이 고아가 되었거나 개편에서 조용히 빠진 곳에서는 가정이 아니라 진짜 인수인계로 의도적으로 소유권을 배정하십시오. 소유권이 시스템을 이해하고 변경하는 능력을 포함하게 해 스튜어드십이 단순한 아이 돌보기로 퇴화하지 않게 하십시오.
시스템을 교체할 때, 옛것을 실제로 끄는 일은 누가 책임집니까? 영원한 병행 운영은 흔하고 비싼 실패입니다. 아무도 종료를 소유하지 않아서 옛 시스템과 새 시스템이 무기한 나란히 돌고, 두 시스템을 유지하면서 어느 쪽의 안전도 얻지 못합니다. 모든 종료를 폐기 완료에 대한 이름 붙은 책임, 지도화된 소비자 목록, 이전 경로, 현실적인 일정이 있는 관리되는 프로젝트로 다루십시오. 증거를 가져오십시오. 오늘 여러분의 자산에서 “임시” 병행 운영이나 반쯤 폐기된 시스템 중 얼마나 많은 것이 여전히 유지 보수를 먹고 있습니까? 시스템이 멈춘 뒤에도 오랫동안 법적 보존 규칙을 충족하도록 데이터와 기록을 보존하되, 보존이 끝내지 않는 핑계가 되게 하지 마십시오. 잘못된 종료는 유지되지 않지만 여전히 의존되는 좀비 시스템을 남기며, 최악의 조합입니다.
오래 사는 시스템에 필요한 기술 중 노동 시장이 공급을 멈출 것은 무엇이며, 승계 계획은 무엇입니까? 20년, 30년 도는 시스템은 언어 생태계, 벤더, 옛 스택을 이해하는 사람들의 경력보다 오래 살며, 시장이 대체 인력을 믿을 만하게 내주지는 않을 것입니다. 어떤 핵심 기능도 정확히 한 사람만 할 수 있지 않도록 버스 팩터를 의도적으로 줄이고, 각 필수 작업을 적어도 둘, 가급적 셋이 수행할 수 있도록 교차 훈련하십시오. 증거를 가져오십시오. 늙어 가는 각 핵심 시스템에 대해 안전하게 변경할 수 있는 사람이 몇인지, 가장 아는 것이 많은 사람들이 은퇴에 얼마나 가까운지 세어 보십시오. 답은 후임의 의도적 훈련과 떠나는 스튜어드와 도착하는 스튜어드의 실제 겹침을 이끌어야 합니다. 시스템에 대한 감각인 암묵지는 그것을 가진 사람과 나란히 하면서 주로 이전되기 때문입니다. 문서는 참고이고, 체험하고 팀이 지닌 지식이 뼈대입니다.
가장 중요한 오래 사는 시스템을 마지막으로 변경한 것은 언제이며, 아직도 감히 변경하는 사람이 있습니까? 일 년 동안 아무도 건드리지 않은 시스템은 안정적인 것이 아니라 “건드리기 너무 무서운” 덫으로 표류하는 중입니다. 모든 변경이 두려워지고 그래서 스택이 조용히 지원 밖으로 늙습니다. 큰 조직에서 이것이 중요한 이유는 마비가 복리로 쌓이기 때문입니다. 동결이 길수록 지식이 더 퇴색하고, 결국 피할 수 없는 변경이 더 위험해집니다. 증거를 가져오십시오. 각 핵심 시스템에 대해 마지막 의도적 변경 날짜, 오늘 누구든 시도할 가장 작은 변경의 크기, 일상적인 의존성이나 보안 패치를 이번 주에 영웅적 노력 없이 출하할 수 있는지입니다. 경쟁하는 고려는 실제입니다. 변경도 위험을 도입하므로 목표는 휘두르기가 아니라 작고 되돌릴 수 있고 잘 테스트된 단계의 꾸준한 리듬입니다. 동결된 핵심이 시민 서비스 아래 십 년간 있을 수 있는 기업과 정부 자산에서는 “우리는 절대 바꾸지 않는다”를 안심이 아니라 위험 신호로 다루고, 변경할 선택지를 살려 두는 지속적 유지 보수에 자금을 대십시오.
자산의 얼마나 많은 부분이 수명 종료에 이르렀거나 가까운 기술 위에서 돌고 있으며, 그 시계를 누가 추적합니까? 늙어 가는 런타임, 지원되지 않는 데이터베이스, 유지 보수 밖의 프레임워크는 보안 패치가 오지 않게 되는 날 갑작스러운 위기로 변하는 느린 실패 모드입니다. 큰 팀에서 위험은 아무도 지평을 소유하지 않는다는 것입니다. 개별 팀은 깨지는 것을 패치하지만, 어느 스택이 언제 벤더 지원을 잃는지의 포트폴리오 관점은 아무도 유지하지 않습니다. 증거를 가져오십시오. 각 핵심 시스템의 핵심 기술, 그 공표된 수명 종료나 지원 종료 날짜, 운영하는 것과 여전히 지원되는 것 사이의 현재 간극의 목록입니다. 긴장은 지속적 업그레이드의 비용과 미루기의 위험 사이에 있으며, 미루기는 보통 파국적으로 질 때까지 이깁니다. 조달과 인가 주기가 일 년 이상 걸릴 수 있는 기업과 정부 환경에서는 멀어 보이는 수명 종료 날짜가 이미 리드 타임 안에 들어와 있는 경우가 많으므로, 승계와 업그레이드 작업은 시계가 다 되기 한참 전에 시작해야 합니다.
자산에서 안정성이 가치이고 참신함이 부채인 곳은 어디이며, 그 경계를 어떻게 정직하게 유지합니까? 모든 시스템이 같은 대우에 보답하지는 않습니다. 시민과 고객이 매일 의존하는 핵심 시스템은 대개 신뢰성과 신중한 변경에 보답하고, 가장자리는 실험에 보답하며, 둘을 혼동하면 돈을 낭비하거나 장애를 부릅니다. 큰 조직에서 위험은 야망과 경력 유인이 흥미로운 재작성을 지루하게 남아야 할 지속되는 핵심으로 밀어 넣는다는 것입니다. 증거를 가져오십시오. 신뢰성이 임무인 곳과 참신함이 가치를 만드는 곳을 표시한 자산 지도, 그리고 최근 어느 방향으로든 그 선을 넘은 변경과 그 비용입니다. 경쟁하는 고려는 안정적인 핵심도 여전히 진화해야 하므로 “안정적”이 동결의 핑계가 될 수 없다는 것입니다. 기업과 정부 맥락에서는 이 경계를 명시적 중요도 등급과, 대중이 실패를 볼 여유가 없는 시스템의 위험한 재작성에 거부권을 행사할 수 있는 이름 붙은 권한에 묶어, 판단이 이번 분기에 가장 크게 말하는 사람에 따라 표류하지 않게 하십시오.

분야별 관점

스타트업. 엔지니어가 소수이고 런웨이가 짧으면 지속 위험은 결제나 인증처럼 잃을 수 없는 시스템을 쓴 한두 사람에게 집중됩니다. 프로세스에는 거의 쓰지 말고, 싸고 가치 높은 일을 지금 하십시오. 각 핵심 시스템을 거치도록 두 번째 사람을 짝지우고, 놀라운 부분에 한 페이지짜리 아키텍처 결정 기록을 쓰고, 실제로 쓰는 런북을 유지하십시오. 단지 오래되었다는 이유로 무언가를 다시 쓰고 싶은 충동을 억누르십시오. 여러분의 규모에서는 핵심 시스템의 재작성 실패가 회사를 끝낼 수 있기 때문입니다.

소기업. 전담 유지 보수 팀도 없고 예산도 빠듯하니, 직접 지속해야 하는 것을 만들기보다 사서 호스팅하는 쪽을 선호하십시오. 떠날 수 있게 해 주는 벤더와 개방형 표준을 선호하고, 어떤 외부 시스템이 어떤 핵심 기능을 돌리는지와 고장 났을 때 누구에게 전화할지의 단순한 기록을 유지하십시오. 직접 소유한 맞춤 코드가 있는 곳에서는 적어도 두 사람(또는 신뢰하는 계약자와 직원 한 명)이 이해하도록 해, 한 사람의 이탈이나 만료된 지원 계약이 발이 묶이게 만들지 않도록 하십시오.

대기업. 도전은 포트폴리오 규모입니다. 많은 오래 사는 시스템, 많은 팀, 수십 년에 걸쳐 순환하는 직원입니다. 서비스 카탈로그에서 팀 수준 소유권을 표준화하고, 자산 전체의 버스 팩터를 측정하고, 일괄 재작성에 거는 대신 지속적이고 점진적인 현대화에 자금을 대십시오. 수명 종료 지평을 중앙에서 다스려 어떤 핵심 스택도 조용히 지원 밖으로 늙지 않게 하고, 모든 종료를 폐기 완료에 대한 이름 붙은 책임이 있는 감사받는 프로젝트로 운영하십시오.

정부. 의무의 연속성은 절대적입니다. 리팩터링하는 동안 급여 지급이나 항공 교통 관제를 멈출 수 없고, 실패는 공개적이고 중대합니다. 조달 규칙은 미래의 유지 보수자와 미래의 벤더에게 기회가 있도록 개방형 표준, 데이터 이식성, 문서화된 인터페이스 쪽으로 밉니다. 노동 시장이 더 이상 공급하지 않는 옛 기술의 의도적 승계 훈련에 자금을 대고, 법정 보존을 충족하도록 폐기된 시스템의 기록을 보존하고, 시민 서비스의 지속적 신뢰성을 간접비가 아니라 책임지는 임무로 다루십시오.

사례

스타트업. 다섯 명의 스타트업에는 이미 잃을 수 없는 시스템이 있습니다. 한 창업자가 첫 달에 쓴, 지금은 모든 고객 청구를 돌리는 결제 청구 서비스입니다. 그것을 이해하는 사람은 그 창업자뿐이라, 팀은 버스 팩터를 칭찬이 아니라 실제 위험으로 다룹니다. 두 번째 엔지니어를 전체 청구 주기에 걸쳐 짝지우고, 이상한 재시도 로직이 왜 존재하는지 설명하는 짧은 아키텍처 결정 기록을 쓰고, 인시던트 중 실제로 연습하는 런북을 코드 옆에 유지합니다. 오래되고 화려하지 않다는 이유만으로 다시 쓰고 싶은 충동을 억누르고, 대신 작고 되돌릴 수 있는 단계로 개선해, 회사를 살려 두는 서비스를 한 머리 이상이 이해하게 합니다.

기업. 한 대형 보험사가 수십 년 전에 처음 쓰였고 여전히 사업의 중심인 보험 계약 관리 시스템을 운영합니다. 위험한 전면 재작성을 시도하는 대신, 잘 정의된 인터페이스 뒤로 시스템을 모듈화해 이제 한 번에 하나의 구성 요소를 교체하며, 각 변경은 작고 되돌릴 수 있습니다. 모든 핵심 기능을 수행할 수 있는 사람이 적어도 셋 있습니다. 온콜은 공유됩니다. 아키텍처 결정 기록이 시스템이 왜 그렇게 동작하는지 포착합니다. 큐레이션된 내부 과정이 신입 엔지니어를 레거시 스택의 숙련으로 이끌고, 떠나는 전문가가 후임과 겹쳐 암묵지가 해 보면서 이전됩니다.

정부. 한 국가 사회보장 기관이 삼십 년 넘게 돌아왔고 멈출 수 없는 급여 지급 시스템을 운영합니다. 서비스 카탈로그에 명시적 팀 소유권을 기록합니다. 시스템을 동결하는 대신 지속적 유지 보수에 자금을 댑니다. 노동 시장이 공급하지 않을 것이므로 옛 기술의 후임을 의도적으로 훈련합니다. 낡은 하위 시스템을 폐기할 때는 모든 소비자를 지도화하고, 이전 지원을 제공하고, 법적 보존 규칙을 충족하도록 기록을 보존하고, 폐기를 실제로 완료할 책임을 배정하는 관리되는 프로젝트로 종료를 운영해, 좀비 시스템이 남지 않게 합니다.

비즈니스 사례: 동기, ROI, TCO

오래 사는 시스템을 지속하는 수익은 그 총소유비용을 지배하는 두 가지 파국적 실패 모드를 피하는 데서 옵니다. 첫째는 갑작스러운 위기입니다. 핵심 인물이 떠나거나, 지원되지 않는 구성 요소가 침해되거나, 고아가 된 시스템이 이해하는 사람 없이 실패합니다. 둘째는 실패한 대형 프로젝트입니다. 초과하거나, 못 미치거나, 무너지는 서둘러 한 전면 재작성입니다. 둘 다 엄청나게 비싸고, 둘 다 꾸준한 스튜어드십으로 대체로 예방할 수 있습니다. 피한 단 한 번의 재작성 실패나 핵심 시민 서비스의 피한 단 한 번의 장기 장애 비용은 보통 수년의 지속적 유지 보수 투자를 넘습니다.

도입 비용은 지속적이고 화려하지 않습니다. 새 기능을 만들지 않는 유지 보수에 자금을 대고, 단기 산출을 줄이는 교차 훈련과 문서화 시간에 값을 치르고, 헤드라인이 되지 않는 점진적 현대화에 투자합니다. 도입하지 않는 비용은 미뤄지고 더 큽니다. 스택이 늙을수록 커지는 위험, 부풀어 오르는 핵심 인물 노출, 결국 비상 조건에서의 강제되고 위험하고 비싼 교체입니다. 리더십을 설득할 때 유지 보수를 “비용 센터”에서 “조직이 잃을 수 없는 시스템에 대한 위험 관리”로 다시 구성하십시오. 구축만이 아니라 유지와 결국의 폐기를 포함한 수십 년 전체 수명에 걸친 총소유비용을 제시하십시오. 그리고 이것을 강조하십시오. 시민과 고객을 대면하는 시스템에서 지속적 신뢰성은 간접비가 아닙니다. 실제 제품인 신뢰입니다.

안티패턴과 함정

영웅 유지 보수자. 시스템을 이해하는 대체 불가능한 한 사람. 그의 이탈은 존재론적 사건입니다.
동결하고 잊기. 핵심 시스템을 “완료”로 선언하고 유지 보수를 멈춰 스택이 유지 불가능하게 늙는 것을 지켜보는 것.
운명 지어진 재작성. 인코딩된 지식을 버리고 대개 초과하거나 실패하는 전면 교체에 조직을 거는 것.
고아가 된 시스템. 현재 소유자가 없어 고장 날 때에야 알아채는 핵심 소프트웨어.
문서화 연극. 낡고, 연습되지 않고, 아무도 믿지 않는 방대한 문서.
영원한 병행 운영. 아무도 종료에 책임이 없어서 옛 시스템과 새 시스템이 무기한 나란히 도는 것.
암묵지의 손실. 겹침 없이 전문가가 떠나게 두어 시스템에 대한 감각이 증발하는 것.
건드리기 너무 무서움. 너무 이해되지 않아 모든 변경이 두려운 시스템. 부식이 보장됩니다.

성숙도 모델

1단계, 시작. 지속이 임시적이고 반응적입니다. 시스템은 개인 영웅에 의존하고, 소유권은 배정되는 것이 아니라 기억되고, 지식은 소수의 머릿속에 문서화되지 않은 채 삽니다. 옛 시스템은 고장 날 때까지 동결되고, 늙어 가는 스택은 눈치채지 못한 채 수명 종료를 향해 표류하며, 폐기는 선언되지만 완료되지 않습니다.

2단계, 발전. 기본 실천이 나타나지만 팀마다 다릅니다. 가장 뻔한 주요 시스템에 소유권이 적혀 있고, 일부 런북과 문서가 있으며, 소수의 핵심 기능에 두 번째 숙련자가 있습니다. 유지 보수는 자금을 받지만 반응적이고, 교차 훈련은 누군가 기억할 때 이루어지며, 조직 전체에 이 중 어느 것도 하는 공유된 방식이 없습니다.

3단계, 표준화. 스튜어드십 실천이 문서화되어 조직 전체에 시행됩니다. 팀 수준 소유권이 서비스 카탈로그에 기록되고 개편에서도 살아남습니다. 순환과 교차 훈련을 통한 버스 팩터 완화가 상설 규칙이고, 아키텍처 결정 기록과 연습되는 런북이 기대되며, 현대화는 정책상 점진적이고, 모든 종료는 폐기 완료에 대한 이름 붙은 책임이 있는 관리되는 프로젝트로 운영됩니다.

4단계, 관리. 지속이 기준선에 대한 데이터로 측정되고 통제됩니다. 핵심 시스템별 버스 팩터, 각각을 안전하게 변경할 수 있는 사람의 수, 모든 핵심 기술의 수명 종료 날짜 대비 나이, 지속적 대 미뤄진 유지 보수 아래 있는 자산의 비중, 멈춘 병행 운영과 반쯤 끝난 폐기의 수를 추적합니다. 이 지표에는 행동을 촉발하는 임계값이 있습니다. 버스 팩터 하한 아래로 떨어지거나 지원 종료 지평을 넘는 시스템은 자금을 받는 시정을 받고, 스튜어드십 건강은 전달과 나란히 리더십에 보고됩니다.

5단계, 오케스트레이션. 스튜어드십이 조직 전체에 통합된 지속적으로 개선되는 것입니다. 어떤 핵심 시스템도 인적 단일 장애 지점이 아니고, 겹침을 통한 암묵지를 포함한 지식 이전이 일상이며, 시스템은 작고 되돌릴 수 있는 단계로 진화해 어느 것도 지원 밖으로 늙지 않습니다. 소유권, 수명 종료 추적, 승계, 종료 계획이 포트폴리오 및 위험 계획에 엮여 있고, 기술과 의무가 이동함에 따라 자산이 재균형되며, 수십 년 시스템은 그것에 의존하는 사람들의 신뢰를 보존하면서 지속됩니다.

논의를 위한 아이디어

버스 팩터를 의미 있게 측정하려면 어떻게 하며, 중요도 수준별로 적절한 목표는 무엇입니까?
점진적 현대화가 정말 불가능하여 재작성이 더 작은 위험이 되는 것은 언제입니까?
스튜어드십이 막다른 길이 아니라 존중받는 경력 경로가 되도록 유지 보수 일에 어떻게 자금을 대고 보상합니까?
마지막 전문가가 은퇴를 앞두고 겹침이 불가능할 때 암묵지를 보존하는 올바른 방법은 무엇입니까?
폐기된 시스템에 대한 질문에 답할 능력을 얼마나 오래 유지해야 하며, 누가 그 비용을 댑니까?
자산에서 안정성이 가치이고 참신함이 부채인 곳은 어디이며, 그 판단을 시간이 지나도 정직하게 유지하려면 어떻게 합니까?

핵심 요점

중요한 소프트웨어 대부분은 오래되고 오래 삽니다. 수십 년과 직원 세대에 걸쳐 지속하는 것은 일급 규율입니다.
모든 핵심 시스템에는 현재의 팀 수준 소유권이 필요합니다. 고아가 된 핵심 시스템은 잠재된 비상 사태입니다.
버스 팩터를 의도적으로 줄이고(어떤 핵심 작업도 정확히 한 사람만 할 수 있어서는 안 됩니다) 암묵지는 문서만이 아니라 겹침을 통해 이전하십시오.
오래 사는 시스템을 지속적이고 점진적으로 유지 보수하십시오. 동결하는 것과 전면 재작성에 거는 것은 둘 다 실패 모드입니다.
끝을 책임지는 완료가 있는 관리되는 프로젝트로 계획하고, 의무를 충족하도록 데이터와 기록을 보존하십시오.
시민과 고객을 대면하는 시스템에서는 지속적인 신뢰성과 공정성이 임무이며, 유지 보수는 잃을 수 없는 것에 대한 위험 관리입니다.

참고 문헌과 더 읽을거리

Michael Feathers, Working Effectively with Legacy Code
Titus Winters, Tom Manshreck, and Hyrum Wright, Software Engineering at Google
Frederick P. Brooks Jr., The Mythical Man-Month
Nat Pryce and Steve Freeman, Growing Object-Oriented Software, Guided by Tests
Sam Newman, Monolith to Microservices
Martin Fowler, Refactoring and writings on the Strangler Fig pattern
Betsy Beyer et al., Site Reliability Engineering and The Site Reliability Workbook (Google)
Diomidis Spinellis, Code Reading: The Open Source Perspective
U.S. Government Accountability Office, reports on federal legacy IT modernisation