3. 레거시 소프트웨어 때문에 힘드네요.

J님이 생각하고 있던 문제의 경우는 기존 서비스에서 필요한 부분을 추출하여 신규 서비스에 적용하여 활용할지가 초기에 공유한 고민이었다. 신규로 서비스 제공하려고 하는 것은 국내의 경우 판매 사이트가 없어 영업부서 분들이 Excel, 이메일, 전화를 할용하여 진행되던 것을 서비스화 하여 이를 기존 서비스와 연동하고 또한 이를 제품으로서도 판매하려고 하는 것이었다.

이야기를 나누다 보니 결국 신규로 확장 구현하시는 모듈과 기존의 시스템을 어떻게 연계할 것인가에 대한 고민이 크셨던 것 같다. 특히, 기존 시스템은 회사에서 활용하고 계신 시스템이라 크게 변동이 일어나지 않기를 바라시는 것으로 파악되었다. 그러면서도 신규로 개발되는 시스템과의 효과적인 연동에서 수정이 많이 발생될 것으로 파악하시면서 결국 가장 중요하게 생각하시는 수정 용이성(modifiability)에 집중하시는 것이 중요하다고 생각이 되었다.

논의하면서 J님이 얻는 아키텍처적 결정은 Flux 혹은 MVVM 모델로 가져가는 것이었다. 이는 J님도 알고 계셨던 MVC에서 로직 처리의 흐름을 한방향으로 가져가게 한다는 추가 아이디어를 공유함으로서 많은 에너지를 얻으신 것 처럼 보였다. 기존 서비스와 추가 서비스의 구조와 시나리오를 보았을 때에는 MVC와 같은 구조에 빗대어 보는 것이 이해가 쉬웠다. 신규로 서비스를 추가하려는 것이 기존 서비스를 View가 되고,  신규로 추가하려는 서비스가 Model과 Controller 역할을 하는 것으로 파악되었다. 그렇다면, 기존 서비스는 고정하고 우리 서비스는 계속 변하더라도 영향이 덜 받는 구조로 만들어야 한다고 함께 판단하게 되였다.

Legacy System. 저희 회사에서도 종종 기존의 시스템으로 다루기 어려운 것이라는 느낌이 강하지만, 결국은 담당하고 있는 저희들은 Asset이기도 하다. 하지만, 여기에 숨겨진 Debt가 어떤 것인지 몰라 두려움을 느끼게 하기도 하는 것 같다. 결국은 우리가 집중해야 할 곳이 어디인지 찾고, 그 부분에 대해서 어떻게 대응할 것인지 판단하는 것이 Legacy System을 Asset으로 만드는 방법이라고 아닐까 생각한다.