Archive for the ‘유지보수’ tag
소프트웨어 공학의 사실과 오해 8 – 유지보수
http://www.yes24.com/24/goods/1418676
유지보수
유지보수는 보통 소프트웨어 비용의 40~80%(평균 60%)를 차지한다. 따라서 유지보수는 소프트웨어 생명주기 중 가장 중요한 단계일 것이다.
p.209
몇 년 전에 신입사원을 가르치면서, “이렇게 하면 나중에 수정하기가 어려우니까 저렇게 하는게 좋다.”라는 식으로 얘기를 했더니 “팀장님은 나중에 수정하는 것을 굉장히 신경쓰시는 것 같아요.”라는 반응을 보였다. 내가 너무 당연하다고 생각하던 걸 신기하다는 듯이 얘기해서 어리둥절 했었는데, 그 때 이런 통계 자료가 있었다면 좋았을 걸.. 이라는 생각이 든다.
소프트웨 유지보수 비용에서 약 60%는 개선 작업에 쓰이는 비용이다. 오류 정정은 약 17% 정도다. 따라서, 소프트웨어 유지보수는 기존 소프트웨어를 보수만 하는 것이 아니라 새로운 기능을 추가할 때도 많다.
p.213
자, 60+17=77%다. 유지보수 비용의 나머지는 어디로 갔나? 18%는 환경이 변하더라도 소프트웨어가 계속 작동할 수 있도록 하는 적응성 유지보수(adaptive maintenance)라 불리는 것에 들어간다. -중략- 그런데 유지보수 비용의 나머지 5%는 뭘까? 이럴 때 항상 나오는 ‘기타’다. 여기에는 소프트웨어를 더욱 유지보수하기 편하게 만드는 작업도 포함된다. 이런 작업을 예전엔 예방적 유지보수(preventive maintenance)라 했고 최근에는 이런 활동을 표현하는데 리팩토링(Refactoring, Fowler 1999)이란 용어가 쓰인다.
p.214, 215
유지보수는 문제가 아니라 해결책이다. -중략- 유지보수는 “우리는 이런 것을 구축했지만 지금 보니 약간 다른 것을 구축했어야 한다.”와 같은 문제를 해결할 수 있는 유일한 방법이다.
p.217
유지보수는 귀찮은 문제를 해결하는 업무이고 그래서 안할수록 좋다라는 느낌이 있었는데, 사실은 신규 개발과 거의 차이가 없는 솔루션 개발 업무라는 것을 배웠다.
소프트웨어 유지보수 생명주기의 각 단계는 개발 생명주기와 거의 같다. 문제에 대한 요구사항을 분석하고, 수정 또는 개선 작업을 한다. 기존 시스템의 설계 컨텍스트 안에서 솔루션을 설계한다. 솔루션을 코딩하고 기존 시스템에 맞춰 넣는다. 코딩된 솔루션을 테스트하면서, 새로 변경한 것이 제대로 동작하는지, 예전에 제대로 작동하던 것들에 영향을 끼쳐 문제를 일으키지는 않는지 확인하다. 그리고 나서, 개선된 부분을 기존 시스템에 반영하고 계속 유지보수한다.
p.219
점진적인 개발 방식을 사용하면 지속적으로 작은 릴리즈를 하고 사용자의 피드백을 받아 개선하게 되니까, 점진적인 유지보수라고 부를 수도 있지 않을까? 처음에 돌고래 스몰토크를 써봤을 때 받은 인상도 비슷한데, 보통의 개발은 아무것도 없는 상태에서 기능을 생성해나가는 느낌이라면, 돌고래 스몰토크에서는 이미 잘 돌아가는 시스템을 리펙토링 해서 기능을 추가해나가는 느낌이었다.
하지만 유지보수 단계에서 “기존 시스템의 설계 컨텍스트 안에서 솔루션을 설계한다.”라는 것이 가장 큰 차이점인데 이는 생각보다 훨씬 어려운 작업이라고 한다. 그 이유는,
설계로 전환하는 시점에서 요구사항의 폭발적 증가, 대부분의 문제에서 설계 솔루션이 하나만 있는 것은 아니라는 사실, 설계는 복잡하고 반복적인 과정이라는 사실, 문제의 복잡성이 25% 증가하면 솔루션의 복잡성은 100% 증가한다는 사실. 이 모든 사실을 조합하면, 설계는 어렵고, 지적이며, 창조적인 작업이란 것을 알 수 있다. 여기서 말하려는 것은 역설계(undesign, 이미 구축된 시스템의 설계를 역공학으로 알아내는 것)라 부를만한 것으로, 이는 최소한 원래의 설계 작업만큼 복잡하다.
p.220
유지보수를 귀찮은 문제를 고치는 하찮은 작업으로 보기 쉽지만, 위의 증거들을 통해서 중요한 솔루션 개발 작업이며, 신규 개발에 필요한 것 이상의 높은 기술을 요구하는 작업이란 사실을 알 수 있다.
하지만 현실에서는 유지보수를 하찮은 작업으로 보는 경우가 많으므로 (담당자 스스로도!) 신입사원이나 경력이 적은 개발자에게 유지보수 업무를 맡기고, 실력이 좋은 개발자는 신규 개발에 투입되는 일이 흔하다. 그렇다보니 초기의 설계를 충분히 이해하지 못한 상태에서 코드의 수정이 이루어지고, 코드는 점점 더 엉망이 되어간다. 그러면 다시 새로운 시스템의 신규 개발이 시작되고 실력있는 사람들은 이 일에 투입된다. 기존에 유지보수를 하던 인력은 이 “실력있는 사람”들이 만든 또 다른 시스템을 유지보수 하게 된다. 불행하게도 여태까지의 내 경험과 일치하는 내용이다.
더 좋은 소프트웨어 공학 기술로 개발하면 더 많은(더 적은 게 아니라) 유지보수가 필요하다. -중략- 이런 시스템은 더 많은 수정이 가해지기 때문에 다른 시스템보다 더 오래 유지된다. 그리고 이런 잘 구축된 시스템은 개선하기가 쉽기 때문에 더 많은 수정이 가해진다.
p.226
이 사실은 “유지보수는 문제가 아니라 해결책이다.”라는 사실에 대한 흥미로운 예다. 유지보수 활동을 솔루션으로 본다면, 더 많은 작업을 할수록 좋다고 생각할 수 있다. 그러나 유지보수를 문제로 보는 시각에 묶여 있으면, 유지보수 활동이 늘어나는 것을 좋게 볼 수 있는 방법이 없다.
p.227