주제 5.3 — 공공부문 소프트웨어 공학과 플랫폼

공공가치에서 이것이 중요한 이유

오늘날 시민이 접하는 거의 모든 공공 서비스, 곧 출생 신고, 급여 신청, 세금 납부, 법원 일정 예약은 창구나 화면 뒤 어딘가의 소프트웨어 위에서 돌아간다. 그 소프트웨어는 일회성 구매인 경우가 드물다. 그것은 국가의 영구적 기반 시설의 일부가 되며, 흔히 그것을 위탁한 행정부, 그것을 만든 공급업체, 그 엔지니어들이 훈련받은 프로그래밍 언어보다 오래 간다. 공공 기관은 소프트웨어를 건물이나 도로처럼 자산의 상태가 눈에 보이는 방식으로 경험하지 않는다. 소프트웨어는 눈에 보이지 않게 저하되며, 그 부패의 청구서는 몇 해 뒤 비상사태로 도착한다.

이 주제를 이끄는 긴장은 구조적이다. 소프트웨어는 본질적으로 반복적이다. 요구 사항은 사용자가 작동하는 시스템과 상호작용함에 따라 더 분명해지며, 최선의 공학 실무는 작은 것을 만들고, 배우고, 적응하는 것이다. 반면 공공 조달과 책임성 주기(주제 3.7 — 공공조달과 위탁 참조)는 자본 공사와 국방 계약을 위해 만들어졌다. 고정된 명세, 단일한 큰 수여, 단계별 지급, 전달이 시작되기 몇 해 전에 결재된 비즈니스 케이스다. 입법부나 감사관이 고정 가격, 고정 범위의 계약을 기대하는데 공학 팀이 첫 출시 후 방향을 바꿔야 할 때, 그 불일치는 범위 확대, 예산 초과, 또는 2019년에는 올바르게 명세되었지만 출시될 때쯤에는 낡은 시스템으로 나타난다.

이 주제의 공학 실무가 구축하려고 존재하는 플랫폼, 곧 공유 신원 시스템, 결제망, 부서 간 재사용되는 사례 관리 도구는 주제 5.1의 대상이다(주제 5.1 — 디지털 정부와 디지털 전환 참조). 이 주제는 그러한 어떤 플랫폼이나 어떤 단일 서비스든 신뢰할 수 있고, 교체 가능하며, 처음에 그것을 쓴 공급업체가 아니라 그것에 의존하는 공공 기관이 소유하게 만드는 소프트웨어를 구축하고 구매하는 규율에 관한 것이다.

핵심 개념

만들지 살지의 결정은 한 조직의 필요를 위해 쓴 맞춤 소프트웨어를 위탁할지, 비슷한 구매자들의 시장을 위해 이미 만들어진 설정 가능한 상용 소프트웨어를 채택할지의 선택이다. 구매는 대개 진정으로 독특하지 않은 필요, 곧 급여, 이메일, 표준 사례 관리에는 더 저렴하고 위험이 낮으며, 만드는 것은 설정 가능한 제품이 맞지 않을 만큼 요구 사항이 다르거나, 그 역량이 조직이 소유하고 발전시켜야 하는 전략적 자산인 경우에만 정당화된다.

기술 부채는 소프트웨어 엔지니어 워드 커닝햄(Ward Cunningham)이 1992년에 만든 은유로, 더 오래 걸렸을 더 철저한 방법 대신 지금 소프트웨어를 출시하는 편의적 방법을 택한 것의 누적 비용이다. 기술 부채는 재무 부채처럼 본질적으로 지는 것이 틀린 것이 아니다. 작동하는 코드를 빠르게 출시하고 나중에 리팩터링하는 것이 옳은 선택일 수 있다는 것이 커닝햄 자신의 요점이었다. 그러나 갚지 않는 부채는 더 느린 전달, 더 많은 결함, 커지는 위험으로 이자가 붙으며, 자신의 부채를 볼 수 없는 공공 기관은 그것을 갚을지 복리로 불어나게 둘지 결정할 수 없다.

레거시 시스템은 낡았는데도 활발히 쓰이는 오래된 기술, 응용 프로그램, 또는 플랫폼으로, 교체하는 데 비용이 많이 들거나 조직에 남은 누구도 그것이 무엇을 하는지 완전히 이해하지 못하기 때문인 경우가 많다. 레거시 시스템은 정부에서 특히 끈질기다. 수십 년 전에 1960년에 행정 컴퓨팅을 위해 설계된 공통 업무 지향 언어(Common Business-Oriented Language)인 코볼(COBOL) 같은 언어로 쓰인 핵심 조세, 급여, 사회보험 시스템은 여전히 수백만 시민의 거래를 처리한다. 시스템이 작동하고, 그것을 안전하게 폐기하는 데 필요한 제도적 지식이 흔히 먼저 은퇴했기 때문이다.

소프트웨어 현대화는 레거시 시스템을 현재의 아키텍처, 언어, 또는 플랫폼으로 변환하거나, 다시 쓰거나, 이전하는 일반 용어다. 소프트웨어 현대화는 전면 재작성에서 같은 코드를 현대적 기반 시설에 다시 호스팅하는 것 같은 더 보수적인 선택지에 이르는 스펙트럼에 걸쳐 있으며, 둘 사이의 선택은 기술적 결정만큼이나 위험 관리 결정이다.

교살자 무화과 패턴(strangler fig pattern)은 숙주 나무를 둘러싸고 자라 점차 그것을 대체하는 덩굴의 이름을 딴 점증적 현대화 접근으로, 전체 시스템을 단일 전환으로 대체하는 대신 새 기능이 레거시 시스템과 나란히 구축되고 트래픽이 조각조각 그리로 돌려진다. 교살자 무화과 패턴이 중요한 이유는 각 증분이 전체 서비스를 중단시키지 않고 시험되고, 되돌려지고, 일시 중지될 수 있기 때문이다. 이는 옛 시스템을 끄고 새것을 한순간에 켜며 무언가 잘못되어도 돌아갈 길이 없는 일괄 전환 방식의 반대다.

공급업체 종속(vendor lock-in)은 고객이 한 공급자의 독점 기술, 데이터 형식, 또는 계약 조건에 너무 의존하게 되어 다른 공급자로 바꾸는 데 엄두를 못 낼 비용이나 위험이 따르는 경우에 일어난다. 공급업체 종속은 구매자가 핵심 서비스를 운영하는 시스템에서 떠날 실질적 능력이 제한된 반복 고객이기 때문에 공공 부문 소프트웨어에서 특히 위험하며, 이는 이후의 모든 갱신에서 협상 입지를 약화시킨다.

자유 및 오픈소스 소프트웨어는 사용자에게 소스 코드를 사용하고, 연구하고, 수정하고, 재배포할 자유를 주는 라이선스로 배포되는 소프트웨어다. 자유 및 오픈소스 소프트웨어는 오픈소스 기본 정책의 바탕이 되며, 이에 따라 공공 기관은 보안 민감성이나 제3자 권리 같은 특정 이유가 보류를 정당화하지 않는 한 위탁한 소스 코드를 공표하는 것을 기본값으로 삼는다. 그 근거는 대개 '공공의 돈, 공공의 코드'로 요약된다. 공공 재원으로 한 번 비용을 치른 소프트웨어는 같은 문제를 푸는 다른 관할권의 다른 공공 기관이 다시 비용을 치를 필요가 없어야 한다는 것이다.

디지털 공공재(digital public good)는 상업적 수익을 내기보다 공공 개발이나 거버넌스 목표를 충족하는 데 도움이 되도록 설계되어, 개방형 라이선스로 공개된 오픈 소프트웨어, 데이터, 또는 콘텐츠다. 디지털 공공재는 한 정부의 오픈소스 공개를 단지 내부 투명성 몸짓이 아니라 다른 정부와 시민사회 조직이 직접 끌어다 쓸 수 있는 더 넓은 공유 기반 시설의 일부로 재규정한다.

애자일 소프트웨어 개발은 사전에 합의한 고정 계획을 따르는 것보다 작동하는 소프트웨어, 잦은 전달, 변화에 대한 대응을 선호하는 소프트웨어 구축의 반복적 접근을 아우르는 포괄 용어다. 애자일 소프트웨어 개발은 요구 사항, 설계, 구축, 시험이 각각 다음이 시작되기 전에 완전히 끝나는 순차적 접근인 폭포수 모형과 대조된다. 폭포수가 공공 기관에 갖는 매력은 늘 그 이정표가 고정 가격 계약과 연간 예산 주기에 깔끔하게 대응한다는 것이었으며, 이것이 전달이 진정으로 애자일인 곳에서도 그토록 많은 조달법이 여전히 이를 가정하는 이유다.

최소 실행 가능 제품(minimum viable product)은 실제 이용자에게 출시되어 그것이 작동하는지 시험하고 다음에 무엇을 만들지 배울 수 있는 서비스의 가장 작은 판본이다. 공공 부문 디지털 서비스 지침서에 맞게 변용된 최소 실행 가능 제품 개념은 반복적 팀에게, 전체 범위가 완성되기 한참 전에 재원 제공자나 감사관에게 실제로 작동하는 무언가를 보여 줄 방어 가능한 방법을 주며, 이는 책임성 과정이 진정으로 최소인 출시를 다른 이름 아래 완성된 제품으로 취급하는 대신 받아들일 때에 한한다.

모범 사례

차별화되지 않은 필요에는 구매를 기본으로 하고, 만드는 것은 진정으로 독특한 것에 남겨 두라. 급여, 이메일, 일반 사례 관리 필요는 맞춤 소프트웨어를 정당화할 만큼 다른 조직의 필요와 다른 경우가 드물다. 요구 사항, 규모, 또는 수십 년에 걸쳐 역량을 소유하고 발전시킬 필요가 시장이 제공하는 것과 진정으로 다른 곳에서만 만들어라.
얼마나 지고 갈지 결정하기 전에 기술 부채를 눈에 보이게 하라. 운영 중인 모든 시스템에 대해 알려진 지름길, 미루어진 수정, 지원되지 않는 의존성의 등록부를 유지하고 고정된 주기로 검토하여, 부채를 1년 더 지고 가는 것이 아무도 보지 않아서가 아니라 의도적인 상충 관계가 되게 하라.
핵심 레거시 시스템에서 벗어나는 유일한 경로로 단일하고 되돌릴 수 없는 전환을 결코 계획하지 마라. 각 조각이 시험되고, 되돌려지고, 점차 도입될 수 있는 교살자 무화과 패턴 같은 점증적 접근을 선호하라. 수백만이 의존하는 시스템의 일괄 대체는 몇 해의 위험을 무언가 실패해도 돌아갈 길이 없는 단 한 번의 주말에 집중시킨다.
조직이 비용을 치러 쓴 소스 코드를 빌려 쓰는 서비스가 아니라 소유한 자산으로 다뤄라. 분쟁이 시작된 뒤가 아니라 계약 시점에 소스 코드 에스크로나 완전한 소유권을 협상하라. 핵심 서비스의 코드의 유일한 사본을 쥔 공급자는 설계에 의한 공급업체 종속이기 때문이다.
소스 코드를 기본적으로 공개로 공표하고, 보류하려면 구체적 정당화를 요구하라. 일관되게 적용된 오픈소스 기본 정책은 모든 부서의 맞춤 구축 소프트웨어를 일회성 비용이 아니라 공유된 정부 횡단 자산으로 바꾸며, 외부 전문가가 내부 팀만으로는 놓칠 보안 결함을 찾게 해 준다.
소프트웨어 계약을 기술적으로 가능한 데 그치지 않고 법적으로 반복적 전달을 가능하게 쓰라. 서명 시점에 합의한 고정 명세에 대해서만 대가를 지급하는 계약은 팀에게 정직한 애자일 실무와 계약상 준수 사이에서 선택하도록 강요한다. 끝의 단일 이정표 대신 작동하는 소프트웨어의 입증과 연결된 단계별 재원 관문을 써라.
현대화를 일회성 자본 프로젝트가 아니라 지속적 프로그램으로 재원을 마련하라. 한 번 현대화되고 20년 동안 방치된 레거시 시스템은 출발했을 때와 같은 위험을 쌓는다. 한 세대에 한 번의 대대적 교체가 아니라 도로 당국이 재포장에 예산을 배정하는 방식으로 지속적이고 점증적인 갱신에 예산을 배정하라.
상용 소프트웨어를 구매하는 경우에도 개방형 표준과 이식 가능한 데이터 형식을 택하라. 공급자의 시스템이 데이터를 개방적이고 문서화된 형식으로 저장하고 내보내도록 요구하면 소프트웨어 자체가 독점적이더라도 전환 비용이 낮게 유지되며, 모든 시스템이 오픈소스여야 한다고 고집하는 것보다 공급업체 종속에 대한 더 달성 가능한 단기 안전장치인 경우가 많다.
전체 범위를 약속하기 전에 최소 실행 가능 제품을 만들어 실제 이용자에게 보여라. 진정으로 최소인 판본을 출시한 뒤 배운 것에 따라 반복하면, 잘못된 가정이 그것에 맞춰 전체 규모의 시스템이 구축된 뒤가 아니라 아직 저렴하게 고칠 수 있을 때 잡힌다.
전달을 외주하는 경우에도 지능적인 구매자가 되기에 충분한 내부 공학 역량을 유지하라. 기술 전문성을 속 빈 것으로 만든 공공 기관은 공급자의 제안을 평가하고, 곤란에 빠진 프로젝트의 초기 경고 신호를 알아채고, 종속에서 협상으로 벗어날 수 없다. 서류상 조달 규칙이 무엇이라 하든 그렇다.
레거시 시스템의 사용자 인터페이스보다 위험 프로필을 먼저 해소하라. 지원되지 않는 언어, 패치되지 않은 기반 시설, 문서화되지 않은 통합, 곧 중단과 침해를 일으키는 실패를 운영상 위험이 훨씬 적은 시각적 현대화보다 앞서 교체하는 것을 우선하라.
전달의 건전성을 예산 및 일정 편차만이 아니라 공학 지표로 측정하라. 배포 빈도, 결함율, 가장 오래된 미해결 기술 부채 항목의 연령은 프로그램이 현재 예산에 맞는지, 대개 마지막으로 움직이는 지표인 그것보다 거버넌스 이사회에 프로그램이 성공할지에 대해 더 많이 알려 준다.

팀과 논의할 질문

우리가 지고 있는 기술 부채가 얼마인지 시스템별로 실제로 알고 있는가? 대부분의 공공 기관은 그해의 자본 예산은 댈 수 있지만, 소프트웨어 자산의 얼마가 지원되지 않는 구성 요소, 문서화되지 않은 논리, 남은 직원 누구도 완전히 이해하지 못하는 코드 위에서 돌아가는지는 어떤 확신을 갖고도 댈 수 없다. 이 질문을 활용해 방의 각 시스템 책임자에게 자신의 팀이 가장 핵심적인 시스템을 아무도 예상하지 못한 무언가를 깨뜨리지 않고 안전하게 바꿀 수 있다고 얼마나 확신하는지 솔직하게 추정하라고 요청하라. 그 추정을 핵심 엔지니어가 떠날 때 함께 떠나는 암묵지가 아니라 고정된 주기로 검토되는 실제 등록부로 바꾸려면 무엇이 필요한지 논의하라. 현재 얼마의 부채를 지고 가도 되는지를 누가 결정하는지, 그 결정이 의도적인지 기본값인지도 고려하라.

가장 핵심적인 레거시 시스템을 오늘부터 교체해야 한다면, 우리는 일괄 전환을 계획하겠는가 점증적 이전을 계획하겠는가, 그리고 왜 그런가? 옛 시스템을 한꺼번에 교체하려는 본능은 기술적 필요보다 예산 주기와 프로그램 관리의 편의가 이끄는 경우가 많으며, 막대한 위험을 단 한 순간에 집중시킨다. 이 질문을 활용해 가장 핵심적인 레거시 시스템의 교살자 무화과 방식의 점증적 이전이 실제로 조각조각 어떤 모습일지 구체적으로 따라가 보라. 오늘 그 경로를 택하지 못하게 막는 것이 무엇인지 논의하라. 단일 가동일을 중심으로 구조화된 재원, 하나의 깔끔한 이정표를 원하는 거버넌스 과정, 이 시스템에서 점증적 이전을 불가능하게 하는 진정한 기술적 제약 가운데 어느 것인가.

우리 조직이 비용을 치르고 만든 소프트웨어의 소스 코드는 실제로 누가 소유하며, 우리는 그것을 입증할 수 있는가? 많은 공공 기관이 공급자와의 관계가 틀어질 때에야 계약이 핵심 서비스가 의존하는 코드의 명확한 소유권이나 에스크로를 확보한 적이 없음을 발견한다. 이 질문을 활용해 가장 중요한 세 맞춤 시스템의 계약을 꺼내, 각각이 코드 소유권, 에스크로, 코드를 다른 공급자에게 가져갈 권리에 대해 구체적으로 무엇을 말하는지 점검하라. 그 세 시스템 가운데 어느 것의 주 공급자든 내일 폐업하거나 관계를 계속하기를 거부한다면 무슨 일이 생길지 논의하라.

오픈소스 기본 접근이 우리에게 똑같이 또는 더 잘 봉사할 곳에서 우리는 어디서 습관적으로 폐쇄형 독점 소프트웨어를 기본값으로 삼고 있는가? 오픈소스 기본 정책은 바로 대부분의 공공 기관이 겹치는 문제를 독립적으로 풀면서 각자 다른 공공 기관이 이미 만들었고 공유할 수 있었던 소프트웨어의 전체 비용을 치르기 때문에 존재한다. 이 질문을 활용해 현재 구축되거나 명세되고 있는 시스템 하나를 찾아, 정부의 다른 곳에 오픈소스 소프트웨어로서 동등한 것이 이미 있는지, 아니면 지금 만드는 것이 다른 이들이 재사용하도록 유용하게 공개될 수 있는지 물어라. 이 곳에는 해당하지 않는다고 가정하는 대신, 그 재사용을 실제로 막는 구체적 장벽, 곧 보안 우려, 조달 습관, 분명한 정책의 부재가 무엇인지 논의하라.

우리의 조달 및 책임성 과정은 정직한 애자일 전달을 실제로 허용하는가, 아니면 폭포수 이정표를 스프린트로 이름만 바꾼 것인가? 팀이 명목상 애자일 의식을 운영하면서도 계약 서명 때 합의한 고정 명세에 대해 여전히 재원을 받고, 거버넌스되고, 보고하는 일은 흔하며, 이는 애자일 딱지 아래서 모든 폭포수의 실패 유형을 재현한다. 이 질문을 활용해 운영 중인 디지털 프로그램 하나를 비즈니스 케이스에서 현재의 거버넌스 보고까지 따라가, 재원 구조가 진정한 초기 출시가 가르친 것에 따라 프로그램이 방향을 바꾸는 것을 용인할지 물어라. 반복적 전달이 겉치레가 아니라 실제가 되려면 프로그램이 재원을 받고 보고하는 방식에서 무엇이 바뀌어야 하는지 논의하라(주제 3.7 — 공공조달과 위탁 참조).

우리가 가장 크게 의존하는 시스템의 지능적 구매자가 되기에 충분한 내부 공학 역량이 있는가? 전달 역량만이 아니라 기술적 판단 전체를 외주한 조직은, 공급자의 제안이 건전한지, 프로젝트가 조용히 문제를 향해 가고 있는지, 그 일의 공정한 가격이 얼마인지 알 수 없다. 이 질문을 활용해 조직에서 가장 중요한 시스템의 기술 아키텍처 제안서를 믿을 만하게 검토할 수 있는 사람이 몇 명인지, 그 수가 지난 5년 사이에 어떻게 변했는지 물어라. 그 역량이 침식된 곳에서 다시 쌓으려면 무엇이 필요한지, 그것 없이 보내는 해마다 조직이 전달 위험만큼이나 협상 입지에서 잃는 것이 무엇인지 논의하라.

실제 사례: 공공가치 사례

가상의 지역 정부는, 예시일 뿐이며 어떤 실제 관할권에 대한 기술이 아닌데, 실업급여 청구를 30년도 더 전에 처음 쓰인 시스템으로 처리했으며, 그 원래 프로그래밍 언어를 이해하는 줄어드는 소수의 엔지니어가 유지했다. 청구량은 시스템의 설계자들이 예상한 것을 훨씬 넘어 늘었고, 야간 처리 작업은 아침 거래가 시작되기 전에 점점 더 완료되지 못했으며, 기관의 기술 지도부는 급여 지급에 영향을 미치는 계획되지 않은 중단이 이제 일어날지의 문제가 아니라 언제 일어날지의 문제라고 경고했다.

기관의 첫 본능은 긴급하게 느껴지는 문제에 대한 전통적 대응이었다. 전체 시스템을 처음부터 완전히 명세하고, 끝의 단일 전환 주말과 함께 고정된 2년 일정에 맞춰 전달하는 현대적 플랫폼으로 교체하는 단일한 큰 계약을 위탁하는 것이었다. 기관의 감사 위원회가 의뢰한 사전 이행 검토는 계약이 서명되기 전에 어려운 질문을 던졌다. 새 시스템이 전면 가동 첫 주에 발견되지 않은 결함이 있고, 옛 시스템은 이미 폐기되어 돌아갈 길이 없다면 수십만 청구인의 급여 지급에 무슨 일이 생기는가.

기관은 방향을 바꿨다. 레거시 시스템을 기록 시스템으로 계속 돌리면서 교살자 무화과 방식으로 그것과 나란히 새 청구 접수 및 자격 평가 기능을 구축했다. 각 새 모듈은 먼저 신규 청구의 작은 비율에 출시되어, 옛 시스템의 병행 산출에 비추어 검증되고, 결과가 일치할 때에만 확대되었다. 18개월 안에 신규 청구의 대부분이 현대적 구성 요소를 통해 처리되고 원래 시스템은 줄어드는 잔여 사례군을 처리했으며, 무언가 잘못 보이면 어느 한 사례든 옛 경로로 돌려보낼 수 있었다. 기관은 또한 이 작업을 위해 발급하는 모든 신규 계약에 소스 코드를 기관이 소유하고 보안 검토가 끝나면 오픈소스로 공표하도록 요구하여, 같은 노후 메인프레임 문제에 직면한 다른 지역 정부가 처음부터 같은 구축을 반복하는 대신 구성 요소를 변용할 수 있게 했다.

레거시 시스템의 마지막 잔여 기능의 완전한 교체에는 거의 4년이 걸렸으며, 서류상으로는 원래의 2년 일괄 전환 계획이 약속한 것보다 길었다. 그러나 전환 동안 어떤 청구인도 계획되지 않은 중단을 겪지 않았고, 각 증분은 결함이 발견되었을 때 몇 시간 안에 되돌릴 수 있을 만큼 작았으며, 이웃한 두 지역 정부가 그 공개 후 첫해 안에 기관이 공표한 자격 평가 코드를 자신의 시스템에 맞게 변용하기 시작했다.

네 가지 부문 관점

지방정부

지방정부는 대개 소수의 국가 규모 플랫폼이 아니라 작고 단절된 많은 시스템을 운영하며, 이는 기술 부채가 하나의 눈에 띄는 대표 시스템이 아니라 따로 조달되고 따로 유지되는 많은 응용 프로그램에 걸쳐 쌓임을 뜻한다. 지방 당국은 대개 정부 계층 가운데 내부 공학 역량이 가장 적으며, 이는 맞춤 구축보다 설정 가능한 상용 소프트웨어를 구매하는 논거를 특히 강하게 하고, 주제 5.1의 대상인 공유 광역 또는 국가 플랫폼(주제 5.1 — 디지털 정부와 디지털 전환 참조)을 각 당국이 같은 역량을 따로 다시 구축하는 것을 피하는 특히 가치 높은 경로로 만든다.

중앙정부

중앙정부는 가장 오래되고 가장 결과가 큰 레거시 시스템, 곧 핵심 조세, 사회보험, 급여 행정이 놓인 곳인 경우가 많다. 이들은 흔히 정부의 첫 대규모 전산화 노력 가운데 하나였고 이제 어떤 현대화 실패에든 가장 큰 이해관계를 지니기 때문이다. 중앙정부는 대개 진정으로 점증적인 현대화 프로그램을 운영하고 계약에 실질적인 코드 소유권을 협상해 넣을 전문적 상업 및 공학 역량을 가지며, 정부 횡단 재사용이 실제로 일어나도록 하기에 충분한 규모를 뒷받침으로 오픈소스 기본 정책을 정하기에 대개 가장 좋은 위치에 있는 정부 수준이다.

사회 부문과 비영리

비영리조직과 자선단체는 대규모 맞춤 플랫폼을 스스로 구축하는 경우가 드물지만, 정부 재원 제공자가 위탁하거나 의무화한 소프트웨어, 곧 보고 포털, 보조금이나 계약이 쓰도록 요구하는 사례 관리 시스템의 수령 측에 있는 경우가 흔하며, 그 설계, 기술 부채, 공급업체에 대한 영향력은 거의 없다. 정부가 의무화한 시스템에 의존하는 사회 부문 조직은 그 시스템의 실패 유형을 물려받으면서 그것을 고칠 지렛대는 전혀 물려받지 못하며, 이는 성과 기반 재원 관계가 성과 척도 자체만이 아니라 의무화된 기술의 운영 부담도 고려해야 하는 또 하나의 이유다(주제 3.7 — 공공조달과 위탁 참조).

다자 및 국제기구

다자기구와 개발 기관은 한 나라의 공공 행정을 위해 만든 소프트웨어를, 각 정부가 민간 공급자에게 전체 비용으로 동등한 시스템을 위탁하는 대신 다른 나라가 변용할 수 있는 재사용 가능한 디지털 공공재로 점점 더 장려한다. 여기서의 고유한 위험은 한 나라의 법적, 행정적 맥락을 위해 만든 디지털 공공재가 너무 적은 적응으로 다른 곳에 채택되어, 신원, 자격, 절차에 대한 실제로는 이전되지 않는 가정을 들여올 수 있다는 점이다. 공유된 개방형 기반 시설의 약속은 실재하지만, 진정한 지역 적응 역량이 코드와 함께할 때에만 그렇다.

흔한 실패 유형

가동 시점에 실패하는 일괄 전환. 핵심 레거시 시스템이 실제 운영 노출 없이 몇 년 개발된 뒤 단일하고 되돌릴 수 없는 전환으로 교체되며, 실제 규모에서나 아무도 시험하지 않은 예외 사례에서만 나타나는 결함이 전면 가동 첫날 불거지고, 옛 시스템이 이미 폐기되었기 때문에 되돌릴 방법이 없다. 비용은 놓친 급여, 거부된 서비스, 또는 시스템이 서비스하려고 존재하는 바로 그 시민에게 영향을 미치는 중단으로 측정되며, 모두가 교체가 작동하기를 의지하던 가장 나쁜 순간에 발생한다.

조용한 기술 부채의 누적. 마감 압박이 알려진 지름길을 고칠 시간에 대한 논쟁에서 거듭 이기며, 각 미루기는 개별적으로 방어 가능하지만, 누적된 부채가 작은 변경조차 불균형하게 비싸고 위험하게 만들 때까지 이어진다. 비용은 몇 해 뒤 아무도 안전하게 수정할 수 없는 시스템, 가장 긴급한 패치 외에는 시도하는 것을 조용히 멈춘 인력, 지속적이고 더 작은 갱신이 들었을 것보다 훨씬 더 크고 비싼 결국의 현대화 프로그램으로 나타난다.

안정으로 오인된 공급업체 종속. 공공 기관이 바꾸는 것이 너무 교란적으로 보여서 같은 공급자의 계약을 거듭 갱신하며, 진정한 전환 비용이 얼마일지 시험하거나 그 비용을 관리 가능하게 유지할 코드 소유권과 개방형 데이터 형식을 협상한 적이 없다. 비용은 가격과 조건에 대한 영구히 약화된 협상 입지이며, 공급자의 서비스 품질이 떨어지거나 가격이 오르고 공공 기관이 믿을 만한 대안이 없음을 발견할 때에야 드러난다.

겉치레 애자일. 전달 팀이 스탠드업, 스프린트, 백로그 같은 애자일 의식을 채택하면서, 근저의 계약, 재원, 거버넌스 구조는 여전히 고정된 명세와 단일한 진행/중단 이정표를 가정하여, 팀이 스프린트 속도를 보고하면서 실제로는 그 밑의 폭포수 계획에 대해 전달한다. 비용은 애자일의 진정한 이점, 곧 방향을 바꾸는 초기 사용자 피드백, 일찍 드러나는 위험이 하나도 실현되지 않으면서, 현대적 실무의 외양이 근저의 경직성을 감독 기구가 보고 도전하기 더 어렵게 만든다는 것이다.

지속 계획 없는 오픈소스 정책. 공공 기관이 오픈소스 기본 정책을 충족하기 위해 소스 코드를 공표하지만 이를 일회성 준법 단계로 다루며, 외부 기여를 검토하고, 취약점을 패치하고, 문서를 유지하는 데 자원을 배정하지 않는다. 비용은 열려 있는 것처럼 보이지만 유지되지 않는 막다른 길로 기능하는 공개된 저장소이며, 이는 아예 공표하지 않았을 때보다 더 넓은 오픈소스 기본 프로그램에 대한 신뢰를 해친다.

성숙도 모델

하위 차원	착수	개발	표준화	관리	통합 운영
기술 부채가 눈에 보이고 관리된다	부채가 문서화되지 않았고 개별 엔지니어만 비공식적으로 안다	일부 시스템에 대한 부분 목록이 있으나 고정된 주기로 검토되지 않는다	부채 등록부가 모든 핵심 시스템을 포괄하고 문서화된 주기로 검토된다	부채 감축에 재원이 배정되고 측정 가능한 목표에 비추어 추적된다	부채 자료가 현대화 투자의 우선순위를 정하기 위해 조직의 전체 자산에 걸쳐 공유된다
레거시 현대화가 일괄 전환의 위험을 피한다	교체가 단일 전면 재작성과 전환을 뜻하는 것으로 가정된다	점증적 접근이 일관된 방법 없이 가끔 쓰인다	교살자 무화과 방식의 점증적 이전이 핵심 시스템의 문서화된 기본값이다	이전 진척과 되돌림 준비 상태가 능동적으로 측정되고 보고된다	현대화 방법과 도구가 동료 공공 기관 사이에서 공유되고 개선된다
만들지 살지의 결정이 의도적이다	만들지 살지가 평가 없이 습관이나 공급자 관계로 선택된다	주요 소프트웨어 결정 전에 일부 평가가 일관되지 않게 이루어진다	문서화된 결정 틀이 모든 중요한 만들지 살지 선택에 적용된다	만들지 살지의 성과가 시간에 따라 원래의 정당화에 비추어 추적된다	만들지 살지의 역량과 교훈이 같은 선택에 직면한 다른 공공 기관과 공유된다
소스 코드와 데이터가 기본적으로 공개된다	폐쇄형 독점 전달이 의문이 제기되지 않는 기본값이다	오픈소스 공개가 개별 팀이 이끌어 가끔 이루어진다	오픈소스 기본 정책이 문서화되고 일관되게 적용된다	공표된 코드가 외부 기여에 대한 자원 배정과 함께 능동적으로 유지된다	공표된 코드가 정부 전반과 다른 관할권에서 재사용되며 재사용이 편익으로 추적된다
전달 방법이 책임성 구조에 맞는다	전달이 실제로 이루어지는 방식과 상관없이 계약과 거버넌스가 폭포수를 가정한다	애자일 의식이 쓰이나 재원과 거버넌스는 여전히 고정된 명세를 관문으로 삼는다	계약과 재원 관문이 작동하는 소프트웨어의 입증을 중심으로 구조화된다	전달의 건전성이 예산 및 일정 편차만이 아니라 공학 지표로 측정된다	조달과 책임성 규칙이 증거에 따라 반복적 전달에 맞게 능동적으로 조정된다

체크리스트

모든 핵심 시스템의 기술 부채를 목록으로 만들고 고정된 주기로 등록부를 검토한다.
어떤 중요한 신규 소프트웨어든 약속하기 전에 문서화된 만들지 살지의 틀을 적용한다.
어떤 레거시 시스템 교체든 점증적 이전 방법을 기본으로 하고 일괄 전환에는 명시적 정당화를 요구한다.
서명 전에 모든 소프트웨어 계약에서 소스 코드 소유권이나 에스크로 조건을 확인한다.
문서화된 예외 과정과 함께 오픈소스 기본 정책에 따라 소스 코드를 공표한다.
그 정책에 따라 공표된 모든 저장소에 최초 공개만이 아니라 지속적 유지에 자원을 배정한다.
근저의 소프트웨어가 독점적인 경우에도 개방적이고 문서화된 데이터 형식을 요구한다.
재원 관문을 단일한 고정 명세 이정표가 아니라 작동하는 소프트웨어의 입증을 중심으로 구조화한다.
전체 범위를 약속하기 전에 실제 이용자와 최소 실행 가능 제품을 만들고 시험한다.
배포 빈도, 결함율, 미해결 기술 부채를 상설 거버넌스 지표로 추적한다.
지능적인 구매자가 되는 데 필요한 것에 비추어 내부 공학 역량을 평가하고 파악된 간극을 메운다.
지원되지 않는 기반 시설과 문서화되지 않은 통합을 겉치레 현대화보다 앞서 우선한다.

주요 출처

GOV.UK Service Standard, Government Digital Service, 영국 — 공공 서비스에 대한 반복적이고 사용자 중심의 전달과 개방형 표준을 요구하는 국가 디지털 서비스 표준.
관리예산처(Office of Management and Budget), Federal Source Code Policy (M-16-21), 미국 — 기관이 맞춤 개발한 정부 소프트웨어에 대해 재사용과 오픈소스 공개를 고려하도록 요구하는 연방 정책.
Free Software Foundation Europe, Public Money, Public Code 캠페인 — 유럽 청중을 위해 개발된, 공공 재원으로 만든 소프트웨어의 소스 코드를 자유 및 오픈소스 라이선스로 공개하는 근거.
Ward Cunningham, 'The WyCash Portfolio Management System' (OOPSLA 1992 경험 보고) — 기술 부채 은유의 원래 진술.
Digital Public Goods Alliance — 공공 개발 목표에 봉사하도록 설계된 오픈 소프트웨어, 데이터, 콘텐츠를 위한 기준과 등록부를 유지하는 다자 이해관계자 이니셔티브.

참고문헌

Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
'The WyCash Portfolio Management System' (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
Digital Public Goods Alliance — https://digitalpublicgoods.net/