연구 분야 소프트웨어 유지보수

Konrad Hinsen 이 작성한 연구 분야의 소프트웨어 유지보수, 2014 년 2 월 26 일 게시 소프트웨어 유지보수는 과학용 소프트웨어 개발자들이 정기적으로 직면하는 어려움 중 하나입니다. 이는 중요한 활동이지만 많은 시간이 소요되며, 현재의 평가 체계에서는 거의 인정받지 못합니다. 또한 대규모 소프트웨어 프로젝트를 관리할 경우 유지보수 비용을 확보하는 것도 대개 어렵습니다. 소프트웨어 유지보수가 어렵고 본질적으로 과학적 흥미를 끄는 주제가 아님을 고려할 때, 왜 이것이 필요한지, 그리고 유지보수 필요성을 줄일 수 있는 방법은 없는지 스스로에게 물어봐야 합니다. 먼저 소프트웨어 유지보수란 무엇일까요? 메리엄 - 웹스터 사전은 동사”유지보수 (maintain)“를 수리하고 문제를 수정하는 등으로 무언가를 양호한 상태로 계속 유지하는 것으로 정의합니다. 이는 기계적 마모 등으로 시간이 지남에 따라 성능이 저하되는 기술 장비에는 타당한 설명입니다. 하지만 소프트웨어는 노후화되지 않으므로, 소프트웨어에 적용될 때의 유지보수는 다른 의미를 가져야 합니다. 합의된 정의가 있는 것은 아니므로 여기서는 제 나름의 정의를 제시하겠습니다: 소프트웨어 유지보수는 다음 두 가지 이유 중 하나로 소프트웨어를 수정하는 것을 의미합니다: 버그 수정. 진화하는 컴퓨팅 환경에서 소프트웨어를 계속 사용할 수 있도록 유지. 어떤 이들은 여기에 기능 향상을 추가하기도 하지만, 이는 어떤 의미에서든 진정한 유지보수가 아니라 개선에 해당합니다. 특히 새로운 기능이 곧 새로운 과학을 의미하는 과학용 소프트웨어의 경우에는 더욱 그렇습니다. 첫째, 버그 문제입니다. 다른 소프트웨어와 마찬가지로 과학용 소프트웨어에서도 더 나은 결과를 얻기 위해 버그를 수정하기를 원합니다. 그러나 이미 발표된 과학적 연구에 사용된 버전이라면 버그가 있는 버전도 그대로 보존해야 합니다. 이는 단순히 정직성의 문제이자 과학적 기록 보존의 문제입니다. 연구 결과에 소프트웨어 버그가 영향을 미쳤을 가능성이 있다면, 그 연구를 검토하는 사람들은 이를 확인할 수 있어야 합니다. 그들은 오늘날 개선된 후속 버전이 아니라 원래 사용된 정확히 동일한 소프트웨어에 접근할 수 있어야 합니다. 이러한 이유로 버그를 수정하는 것보다 연구에 사용된 코드를 보존하는 것이 실제로 더 중요합니다.

ActivePapers 는 바로 이 목표를 염두에 두고 설계되었습니다. ActivePaper 내의 모든 계산된 데이터 항목은 이를 생성한 소프트웨어와 연결됩니다. 게다가 ActivePapers 는 전자 형태의 논문 사본처럼 발행되고 DOI 를 통해 인용되므로, 일단 발행되면 이 연결은 절대 변경할 수 없습니다. 발행 전에 사기를 목적으로 ActivePaper 를 수정함으로써 부정행위를 할 수는 있습니다. ActivePapers 는 그러한 행위를 지원하지는 않지만, 사기를 방지하기 위한 특별한 조치도 취하지는 않습니다. 출처 정보를 해시로 보호하는 등의 기능을 추가할 수는 있겠지만, 그러할 필요가 없기를 바랍니다. 두 번째 문제인 진화하는 컴퓨팅 환경은 더 미묘한 사항입니다. 컴퓨터 세계의 모든 것 (컴퓨터, 운영체제, 컴파일러, 언어 정의, 라이브러리 등) 이 빠르게 변화한다는 것은 삶의 사실이며, 그 결과 특정 소스 코드는 몇 년 후에는 그대로 작동하지 않을 가능성이 높습니다. 이는 두 가지 이유 때문입니다.

(1) 기술 발전으로 사람들과 원하는 더 나은 컴퓨터와 소프트웨어가 지속적으로 등장하며, (2) 컴퓨팅 플랫폼의 안정성에 이해관계를 가지고 이를 실현할 권한을 가진 사람이 아무도 없기 때문입니다. 하드웨어 공급업체와 상용 소프트웨어 제공업체에게 빠른 변화는 고객이 새 기계를 구매하고 라이선스를 정기적으로 업데이트하도록 유도하는 최선의 방법입니다. 물론 컴퓨팅 플랫폼의 안정성에 이해관계를 가진 적어도 하나의 공동체는 존재합니다. 바로 전산과학 커뮤니티입니다. 만약 우리가 20 년 후에 소프트웨어를 수정 없이 실행하여 동일한 결과를 얻을 수 있다면 얼마나 좋을까요. 우리는 소프트웨어 유지보수를 하고 싶지 않으며, 대부분 자신의 연구를 위해 개발한 소프트웨어를 개인의 즉각적인 필요 이상으로 합리적으로 유지보수할 수 없습니다. 다른 사람의 소프트웨어, 예를 들어 이제 산업계로 진출한 대학원생이 남겨둔 소프트웨어를 누군가가 유지보수하기를 기대하는 것은 더욱 비현실적입니다. 실제로 널리 사용되는 커뮤니티 소프트웨어만이 충분히 장기간 유지보수됩니다. 그러나 널리 사용되고 유지보수되는 패키지를 사용하는 연구 프로젝트조차도 최소한 몇 개의 셸 스크립트 정도는 프로젝트 고유 소프트웨어를 필요로 합니다. 이것이 계산 연구의 재현성이 매우 낮은 이유 중 하나입니다. 과학 커뮤니티가 이에 대해何か 할 수 있을까요? 가능하다고 믿지만, 가까운 시일 내에 행동에 나설 것이라고 낙관하지는 않습니다. 과학자들은 과학 계산을 위해 범용 하드웨어를 계속 사용할 가능성이 높으며,这意味着 그들이 통제할 수 없는 하드웨어 및 관련 시스템 소프트웨어의 진화를 받아들여야 함을 의미합니다. 그러나 최소한 순수 계산 작업 부분에 한정해서는 이렇게 끊임없이 진화하는 기반 위에 안정적인 플랫폼을 구축할 수는 있습니다. 근본적으로 소프트웨어를 위한 튜링 완전 표기법은 모두 동등하며 서로 변환 가능합니다. 실제로는 성능상의 이유로 코드 변환에 한계가 있지만, 여전히 다양한 하부 하드웨어 및 시스템 소프트웨어로 효율적으로 번역될 수 있는 코드 표현 방식을 정의하여 안정성을 유지하는 것은 가능합니다. 실제 사례로는 JVM 바이트코드와 LLVM 의 중간 표현 형식 이 있습니다.

쇼핑하는 경우: DataCamp — 브라우저에서 직접 코딩하는 대화형 Python 및 데이터 과학 과정.

JVM 바이트코드는 20 년 동안 존재해 왔으며 극도로 안정적임이 입증되었습니다. LLVM 의 중간 표현 형식은 안정성을 목표로 하지 않는데, 이는 LLVM 개발자들이 안정적인 표현 방식에 구속됨으로써 미래의 선택지를 제한하기를 원하지 않기 때문입니다. 구글의 PNaCl 프로젝트는 이런 경고를 무시하고 LLVM 코드를 안정적인 상태에서만 의미가 있는 방식으로 사용하려고 시도합니다. 이것이 어떻게 될지는 시간이 알려줄 것입니다. 과학 커뮤니티는 기존 접근법에 대한 경험을 바탕으로 자체 중간 코드 표현 방식을 정의하고 과학 응용에 최적화된 플랫폼을 구축할 수 있습니다. 그러나 앞서 말했듯이 이것이 실현될 것이라고 낙관하지는 않습니다. 이를 위해서는 여러 대형 연구 기관과 자금 지원 조직이 수십 년 동안 이 플랫폼을 유지보수하겠다는 장기적인 약속이 필요합니다. 저는 이것이 경제적으로 합리적이라고 확신합니다. 하나의 플랫폼을 유지보수하는 것이 수많은 과학 소프트웨어 패키지를 유지보수하거나 유지보수되지 않은 패키지들을 끊임없이 다시 작성하는 것보다 저렴하기 때문입니다. 하지만 이는 과학계에서 드문 수준의 합의와 헌신을 요구하며, CERN 과 같은 거대 시설 몇 곳에서만 이루어진 전례가 있을 뿐입니다. 안정적인 플랫폼이 제공하는 중요한 이점이 바로 첫 번째 ActivePapers 에디션이 JVM 을 중심으로 설계된 이유입니다. 불행히도 JVM 은 과학 컴퓨팅 분야에서 그다지 인기가 없습니다. 이는 종종 성능 부족 때문이라고 설명되지만, 그런 주장은 예전만큼 타당하지 않습니다. 특히 부동소수점 연산과 관련하여 몇 가지 설계상의 문제도 있지만, 이는 과학자들이 사용을 꺼리지 않는 인기 언어인 C 나 C++ 에서도 마찬가집니다. 실용적으로 더 유용한 ActivePapers 의 Python 에디션은 Scientific Python 생태계 (특히 Python, NumPy 및 h5py) 에 의해 정의된 플랫폼을 기반으로 구축되었습니다. 이 플랫폼은 과거에 적당히 안정적이었으며, Python 3 로의 전환이 주요 불안정 사건이었습니다. 과학적

추가 읽기 자료

• SciPy — 위키백과