Software Isolation During the Software Refactoring

최근 3~4년간 시간들을 돌이켜보면 소프트웨어 관련 기술들을 실무에 적용하기 위해 상당한 시간을 들였던 것으로 기억합니다. 소프트웨어를 개발하는 조직에서 소프트웨어 엔지니어로 살기 위해 여러 케이스를 고려한 나름의 노력이었는데, 안타깝지만 성과는 크지 않았던 것이 현실이었습니다.

이런 무성과? 저성과?의 이유를 생각해 보면, 결국 조직적 이슈였던거 같은데 지속적으로 소프트웨어를 개발하고 유지보수하는 업무를 단순화 그리고 효율화하기 위한 노력이 왜 조직적 이슈로 인해 무산(?) 되었을까.. 그리고 무엇이 이러한 조직적 이슈를 야기시키고 있는 것일까 생각해 봅니다. 

결국 생각해보면, "소프트웨어에 새로운 기능이 요구되고, 시간이 지남에 따라 복잡해지고 (예를 들어 불필요한 종속성, 중복되거나 강하게 결합된 기능, 지나치게 복잡하거나 얽혀있는 구현 등) 개발자들로 하여금 혼란을 야기시키게 될텐데, 이러한 혼란스러운 소프트웨어는 개발자의 시간과 조직의 신속한 환경 변화 대응 능력 면에서 비용 및 노력을 발생시키는 요인이 된다"는 면에서 조직적 지원은 반드시 필수적이었다는 점은 부정할 수 없을듯 합니다.

실제 소프트웨어를 개선하고 발전 시키는데는 단순히 몇일 정도가 소요되는 것이 아니라, 장기적(몇개월 또는 몇년) 기간이 요구될 수 있습니다. 그리고 소프트웨어 개선 효율을 높이기 위해 소프트웨어 Isolation이 요구될 수 있습니다. 이는 특정 목표를 달성하고 유지보수를 용이하게 하기 위해 소프트웨어 기능을 독립적으로 분리하는 것을 의미합니다. 하지만 이러한 소프트웨어 Isolation은 노동 집약적 활동으로 신속하게 진행할 수 있는 도구의 도움을 받는 것은 쉽지 않습니다. 

이런 상황이 본인 개인의 상황으로만 한정된다고 생각했는데, 본의 아니게 재밌는 포스팅을 하나 발견하여 요약/정리 해 봅니다.

---

The Importance of Software Isolation

오늘날 빠르게 변화하는 환경에서 소프트웨어 개발 조직은 개발팀에게 정해진 일정과 예산 내에 소프트웨어를 개발/배포하도록 압박을 받고 있습니다. 그러나 변화하는 환경은 얘기치 않은 사용 사례와 새로운 요구 사항이 개발 계획에 변경을 강요할 수 있으며, 이러한 번경은 소프트웨어 복잡성에 더해 소프트웨어 리팩토링을 가속화하는 계기가 되기도 합니다.

소프트웨어 리팩토링을 위해서는 리팩토링을 위한 노력을 계획하고, 새로운 플랫폼, 프레임워크 또는 도구를 사용하는 방법을 배워야 하는 개발자를 프로젝트에 할당하고, 새로운 변경사항을 적용할 전략을 고안하며, 주요 변경으로 인한 기타 문제를 해결하는데 필요한 많은 단계를 수반하게 되며, 이러한 과정에서 소프트웨어 목적에 따라 기능들을 Isolation 해야 한다는 공통점을 발견할 수 있습니다.

소프트웨어 리팩토링의 조직적 과제

실제로 조직은 리팩토링이 명확한 투자 수익을 제공하지 않기 때문에 기존 소프트웨어 위에 기능을 추가하는 방법을 자주 선택합니다. 리팩토링은 잠재적으로 위험을 도입하고, 비용이 많이 들며, 새로운 기능을 제공하는 데 사용할 수 있는 귀중한 개발자 시간을 차지합니다. SEI가 실시한 설문 조사에 따르면, 응답자의 71%가 “대규모 리팩토링을 수행하고 싶었지만 하지 않았다”고 응답했습니다. 가장 일반적인 이유는 “새로운 기능이 리팩토링보다 우선시되었다”(60% 이상)와 “예상 비용이 너무 높았다”(50% 이상)였습니다.

이러한 결정은 새로운 기능이 지속적으로 추가되고 리팩토링이 우선시되는 일이 반복되면서 소프트웨어의 수명 동안 반복되고 복합됩니다. 몇 년 또는 수십 년 후, 그 결과는 목적에 맞지 않거나 심지어 이해되지 않거나 알려지지 않은 아키텍처를 가진 취약한 제품이 됩니다. 기능 추가가 어려워지고, 개발 및 테스트 시간이 증가하며, 버그가 예상치 않게 나타나고, 업데이트가 지연됩니다. 소프트웨어는 이해하기 어렵고 작업하기 어려워집니다. 조직은 개발 팀의 누구도 제품을 변경하고 싶어하지 않거나 특정 영역에서 변경을 할 수 있는 사람(또는 감히 변경할 수 있는 사람)이 한 명뿐일 때 이러한 상황에 도달했음을 인식합니다. 이는 가장 잘 계획된 소프트웨어 시스템에서도 발생할 수 있습니다.

이 시점에서 조직은 고통이 임계점에 도달했음을 인식하고, 마침내 소프트웨어에 대한 대규모 리팩토링을 수행하기로 결정합니다. 현재의 운영 전략을 변경해야 하는 필요성(예: 클라우드로 이동하여 사설 인프라 유지 비용을 줄이는 등)도 이러한 결정을 촉발할 수 있습니다. 어느 쪽이든, 조직은 관련성을 유지하기 위해 대규모 리팩토링을 수행해야 할 필요성을 인식합니다. 여기서 소프트웨어 격리가 필요합니다.

---

What is Software Isolation?

소프트웨어 격리(Software Isolation)는 기존 코드에서 기능을 분리하는 작업을 말하며, 대규모 리팩토링의 단계 중 하나입니다. 개발자는 특정 목표를 염두에 두고 시작합니다. 예를 들어, 기존 기능을 추출하여 독립 실행형 서비스로 전환하거나, 모놀리식 애플리케이션을 일련의 마이크로서비스로 나누려 할 수 있습니다. 이러한 모든 작업이 소프트웨어 격리 활동입니다. 소프트웨어 격리는 여러 가지 목적을 수행할 수 있습니다:

1. 독립 실행형 서비스로 코드 격리: 특정 기능의 실행 인스턴스를 복제하여 소프트웨어를 확장하는 기술입니다. 예를 들어, 이메일 애플리케이션을 분리하여 독립 실행형 서비스로 만들어 복제할 수 있습니다. 다음 그림에서 보는바와 같이 복잡하게 얽혀있는 소프트웨어와 통합 데이터베이스 구조를 갖는 소프트웨어 아키텍처를 독립된 기능 또는 서비스로 분리하고, 개별 데이터베이스에 할당하는 형태로 소프트웨어 격리를 실시 할 수 있습니다. 이는 소프트웨어 리팩토링 목표를 달성하기 위한 대표적인 방법론으로 간주 할 수 있습니다. (물론 모든 리팩토링 상황에서 소프트웨어 격리를 수반하는 것은 아니다.) 

2. 새로운 플랫폼으로의 코드 마이그레이션을 위한 격리: 클라우드 플랫폼으로 서비스를 마이그레이션하여 관리 비용을 절감하는 데 도움이 됩니다. 예를 들어, 특정 기능을 클라우드 네이티브 서비스로 호스팅할 수 있습니다.

3. 오래되거나 원치 않거나 최적이 아닌 코드 격리: 시간이 지나면서 외부 종속성이 구식이 되거나 보안 취약점을 가질 수 있습니다. 이러한 기능을 분리하여 대체하기 쉽게 만듭니다.

4. 재사용을 위한 코드 격리: 이미 개발된 기능을 재사용하여 소프트웨어 품질을 높이고 개발 시간을 단축할 수 있습니다. 예를 들어, 물류 추적 소프트웨어나 항공기 내비게이션 소프트웨어의 핵심 기능을 재사용할 수 있습니다.

5. 독립적인 팀 개발을 위한 코드 격리: 조직이 성장함에 따라 소프트웨어를 분리하여 각 팀이 독립적으로 개발 및 유지보수할 수 있도록 합니다.

 

소프트웨어 격리가 어려운 이유

소프트웨어 격리는 팀이 필요한 코드 변경 사항을 식별하고, 수행하고, 검증해야 합니다. 첫 번째 변경 사항은 팀의 전문성에 의존하며, 마지막은 테스트 자동화의 이점을 누립니다. 그러나 코드를 변경하는 것은 여전히 개발자에게 큰 노력을 요구합니다. 예를 들어, 격리되는 기능의 일부인 클래스를 식별하고, 이 클래스가 코드의 다른 부분과 가지는 종속성을 파악해야 합니다.

상황을 더 악화시키는 것은 이 분야에서 도구의 지원이 상대적으로 적다는 것입니다. 개발자는 통합 개발 환경의 빨간 밑줄이나 컴파일러 오류에 의존하여 수동으로 이 모든 작업을 수행하며, 계속해서 코드를 다시 컴파일하여 해결해야 할 종속성을 식별하려고 합니다. 대규모 코드베이스에서는 이 작업이 가장 경험 많은 개발자에게도 압도적일 수 있습니다.

개발자는 리팩토링 작업을 두려워해서는 안 됩니다. 마찬가지로, 조직은 새로운 기능 제공 노력을 방해할 것이라는 두려움 없이 대규모 리팩토링 활동에 참여할 수 있어야 합니다. 소프트웨어 격리의 도전은 기술적 결정에만 국한되지 않습니다. 조직의 전략, 필요, 자원 및 마감일도 고려해야 합니다. 그러나 코드 변경 작업은 여전히 크고 대규모 프로젝트에서는 피할 수 없습니다. 새로운 기능을 신속하게 제공하거나 새로운 기술을 활용할 수 있도록 조직을 도울 수 있는 더 나은 대규모 리팩토링 도구가 분명히 필요합니다.

[출처] https://insights.sei.cmu.edu/blog/software-isolation-why-it-matters-to-software-evolution-and-why-everybody-puts-it-off/

---

사실 처음에는 소프트웨어 리팩토링을 통해 엄청난 변화를 기대했었습니다. 그러나 쉽지 않은 여건으로 다시 한번 절치부심하는 여유가 필요하다고 생각해 봤습니다.