GN⁺: 기술 부채: 내 Rust 라이브러리, 이제 CDO로 전환

기술 부채: 내 Rust 라이브러리는 이제 CDO가 되었다

• 기술 부채에 대한 유머로, 기술 부채가 있다면 그 부채를 다루기 위한 파생상품도 있어야 한다는 농담이 있음.
• Rust 생태계는 기술 부채를 담보화하는 것처럼 보이는 해결책을 만들어냄.
• 예를 들어, 어떤 라이브러리 stuff가 다른 라이브러리 learned-rust-this-way에 의존하는데, learned-rust-this-way의 저자가 관심을 잃고 문제들이 쌓이기 시작함.

기술 부채의 실체

• learned-rust-this-way는 기술 부채로 간주되며, 이는 직접적인 문제를 일으키지 않지만, 그럼에도 불구하고 부채임.
• 어느 시점에 누군가가 learned-rust-this-way가 부채라는 것을 깨닫고, 원래 저자에게 연락이 닿지 않으면서 RUSTSEC 데이터베이스에 추가됨.
• RUSTSEC은 평가 기관으로서 해당 부채를 쓰레기로 평가하고, 이로 인해 많은 사람들의 CI(지속적 통합)가 실패하기 시작함.

부채 해결 방법

• stuff의 유지보수자로서, 사용자들이 learned-rust-this-way 사용에 대해 문제를 제기하면 스트레스가 증가하고, 부채를 처리하기 위한 조치를 요구받음.
• 대안으로 이동하는 것이 하나의 옵션이지만, 이 경우에는 모든 대안들이 매력적이지 않음.
• learned-rust-this-way를 포크하면 동일한 요구에 직면하게 되며, 이는 임시적인 해결책일 뿐 문제를 해결하지는 못함.

실제로 효과가 있는 해결책

• 자신의 라이브러리에 해당 코드를 병합하면, 이제 그 쓰레기 기술 부채가 갑자기 ‘AAA’ 등급으로 평가됨.
• 코드를 더 이상 건드리지 않고, 병합 사실을 숨기며, 이전처럼 라이브러리를 유지 관리하면 세상은 계속 돌아감.
• yaml-rust를 insta에 벤더링하여 병합함으로써, insta 코드와 yaml-rust의 결합체가 되었고, 이를 통해 AAA 등급으로 기술 부채를 업그레이드함.

GN⁺의 의견

• 이 기사는 기술 부채를 금융 파생상품에 비유하여, 소프트웨어 개발에서 발생하는 문제를 재치 있게 설명함.
• 기술 부채는 소프트웨어 개발에서 흔히 마주치는 문제이며, 이 기사는 개발자들에게 부채를 관리하는 창의적인 방법을 제시함.
• Rust 생태계의 RUSTSEC 같은 평가 시스템은 개발자들이 라이브러리의 안정성을 평가하는 데 도움을 줄 수 있으나, 동시에 불필요한 스트레스를 유발할 수도 있음.
• 기술 부채를 해결하는 방법으로 코드를 병합하는 것은 임시적인 해결책일 수 있으며, 장기적으로는 지속 가능한 유지보수 전략이 필요함.
• 이러한 상황에서는 커뮤니티 주도의 유지보수, 오픈소스 프로젝트의 공동 유지보수, 또는 라이브러리의 대체 버전을 찾는 것과 같은 다양한 해결책을 고려해야 함.

[neo]

Hacker News 의견

• 가장 인기 있는 YAML 파서의 저자가 갑작스럽게 프로젝트를 포기하고, 이를 사용하지 않음(deprecated) 및 유지보수하지 않음(unmaintained)으로 표시함. 경고나 다른 유지보수자 지정 없이 이루어진 일로, 패키지는 여전히 기능적이지만 4000개 이상의 다른 크레이트에서 사용되고 있어, 감사 및 자동 업데이트 도구에서 유지보수되지 않는 크레이트 사용에 대해 경고할 것임.
• CDO라는 약어에 혼란을 느낀 사람들을 위해, 이는 'collateralized debt obligation'을 의미함을 추측함. 여러 번 'collateralized'라는 단어가 사용되었기 때문임.
• 코드가 취약한 경로가 외부 라이브러리에서 실행되거나 접근할 수 없다면, 그것은 안전한 코드 경로가 됨. 라이브러리를 가져오는(vendoring) 것은 코드를 공격하는 도구를 제공하며, 자체 라이브러리에 대한 테스트 커버리지가 충분하다면, 가져온 라이브러리에 대한 코드 커버리지 도구를 실행할 수 있음. 가져온 라이브러리를 수정하는 것은 도전적일 수 있지만, 필요하지 않은 부분을 삭제하는 것은 상대적으로 쉬울 수 있음. 물론, 가져온 라이브러리의 구조에 따라 다름.
• 전직 양적 분석가이자 현재 경제학자는 저자가 'Collateralized Debt Obligation'이라는 용어를 올바르게 사용한 것을 칭찬함. '기술적 부채'에 대한 기사를 쓰고 싶은데, '부채'라는 비유는 그 개념에 적합하지 않다고 생각함. '고점도 코드'라는 표현이 더 나을 수 있음. 코드를 새로운 기능에 맞게 쉽게 변경할 수 없어서 마치 높은 유도성을 가진 것처럼 느껴짐.
• 'junk tech debt'가 갑자기 'AAA' 등급으로 평가받는다는 것에 대해, 저자는 코드가 가져오기(vendoring) 되기 전과 후에 같은 코드가 더 나은 부채 등급을 가질 수 없다는 것을 의미하는 것 같음. 하지만 이것은 코드 자체의 가치만을 보는 것으로, 전체 가치 제안의 가장 중요한 부분을 놓치고 있음. 코드를 가져오는 유지보수자는 이제 그 코드를 소유하게 되며, 죽은 프로젝트에서 코드를 가져온 활동적인 유지보수자는 이슈에 대응하고, 풀 리퀘스트를 검토하며, 버그를 수정할 수 있는 인간이 있기 때문에 코드의 가치를 높임.
• JS npm 생태계에서도 같은 패턴을 보았음. Npm audit은 주로 보안 문제에 대해 과장되게 경고하며, 라이선스가 허용하는 한, 사용자로부터 받는 터무니없는 문제들로부터 벗어나는 가장 신뢰할 수 있는 방법 중 하나임.
• yaml-rust를 포크하고 순수 Rust로 다시 작성하여 yaml-rust2를 만든 것은 운이 좋았음. 이 포크는 YAML 테스트 스위트를 완전히 통과하며 벤치마크에서도 더 나은 성능을 보임. 마이그레이션도 간단해 보임. 결국 문제는 여전히 남아 있으며, 우리는 현재 무료로 노동을 제공하는 다른 사람들에게 의존하고 있지만, 그들이 영원히 그렇게 할 것이라는 보장은 없음.
• 소스 기반 패키지 매니저가 레지스트리가 발행된 패키지의 유지보수를 강제로 인수할 법적 권리를 강제하지 않는다면, 무시무시한 문제에 직면할 것임: 방치, 악의적인 변경, 악의적인 제거, 사칭 등... 커뮤니티에 충분히 중요하다고 판단되는 패키지의 경우, 원래 소유자의 손에서 레지스트리 항목을 빼앗아 포크로 바꾸는 방법이 필요함.
• 코드가 작동하고 수년간 그래왔다면, 유지보수되지 않는다고 해서 무슨 상관이 있을까? 수정할 필요가 없고 그 한계와 능력을 알고 있다면 문제가 되지 않음. 코드는 스스로 나빠지지 않음. 수십 년 전 코드를 여러 번 빌려오거나 통합하는 데 아무 문제가 없었음.
• 의존성을 가져오는 것(vendoring)이 해결책임. 20년 동안 '완성'되어 개발 및 유지보수가 느려진 거의 모든 의존성에 대해 이를 수행함.