소프트웨어 유지보수도 중요하다.

유지보수라는 것은 구축된 시스템을 운영 및 관리해주는 것이다. 사실 이미 구축된 시스템이라면 많은 일손이 안들수도 있다. 잘 돌아가기만 하면 될 것이다. 물론 B2C 서비스의 경우 상황은 다를 수 있다. 앞서 얘기한 것도 있지만, 린 개발방법론이라든가 DevOps를 한다면 유지보수라는 측면보다는 지속 개발이라는 것이 맞을 것이다. 계속된 요구가 있고, 개선 사항이 있을 것이다. 운영 중에도 개발을 많이 한다. 기존 시스템들은 대개 1.0, 2.0 이런식의 버전을 구분하고, 고도화 프로젝트등을 진행해서 기존 시스템을 사용하다가 어느 순간에 개편 내지 대체를 한다. 하지만 이런 서비스라든가 최근 시스템들은 지속적인 기능 업그레이드 내지는 개발을 한다.

기존과 같은 유지보수이든 지속 개발 관점의 유지보수이든 매우 중요하다. 다리나 건축물이라고 생각해보자. 또는 엘리베이터나 차량이라고 생각해보자. 이런 것들이 잘 만들어지는 것이야 두말할 것이 없이 중요하지만, 사람들이 이용할 때 이 위험성에 대한 관리가 되지 않으면 매우 심각한 사고가 벌어질 수 있다. 매우 잘 관리되어야 한다. 중간 중간 위험성에 대한 관리가 되어야 하고, 소모된 자재들은 교체를 해줘야 한다.

소프트웨어도 유지보수가 필요하다. 특히 소프트웨어는 하드웨어라는 자원 위에서 동작되기 때문에 자원 상태도 매순간 체크가 되어야 한다. 유지보수를 한다는 것이 단순히 하자를 수정하는 것도 있겠지만, 이런식으로 운영 관점에서 영속성을 계속되게 하기 위한 노력인 측면이 있다. 그리고 유지보수에는 프로세스가 필요하다. 왜냐면 유지보수라는 것은 기본적으로 동작되고 있는 것이 더 나아지거나 개선되거나 고쳐지게 하는 것이다. 개발때에는 다시 개발을 할 수 있는 여지가 있다. 개발 후에 테스트 기간도 별도로 있고, 수정할 수 있는 시간도 가진다. 유지보수 시는 운영 시점이다. 유지보수 후에 바로 다시 정상 동작이 되어야 한다. 하나도 틀림 없이 정교하게 동작이 되어야 하고, 데이터 베이스의 데이터들도 정합성이 맞아야 한다. 그래서 유지보수 시에 개발이라든가 개선 작업은 사전 영향도 파악, 개발 시 연관 모듈 영향도, 그리고 사후 모니터링이 반드시 필요하다. 그래서 개발 시 보다 수정에 대해서 매우 신중해야 하며 기간도 충분히 잡고 검토를 해야 한다. 프로세스도 엄격해야 한다. 사전 영향도 파악, 유관 부서 협의 일정에 대한 사전 공지, 작업 시점에 중단에 대한 알림, 이후 서비스 재개 시 유의사항 변경점들에 대해서도 고지를 해야 한다. 그래서 이를 프로세스화 하고 단계별로 담당자 그리고 협의하고 합의자가 필요하다. 유지보수 프로세스가 단순한 형식적인 절차를 복잡하게 많이 두는 것 자체는 의미가 없을지 모른다. 하지만 이런 의미를 가지기에 단계별로 철저하게 진행을 하는 것은 반드시 필요하다.

 책처럼 전체를 보기를 원하시면 아래 링크를 클릭하시고 북마크 하셔서 보시면 편리합니다. 

https://wikidocs.net/22348