[IT 기술] 선행 조건(1)

[IT 기술] 선행 조건(1)

*이 내용은 CODE COMPLETE2 에 대한 내용을 정리 및 제 생각을 더해 쓴 글입니다.*

안녕하세요. 이번에 알려드릴 거는 선행 조건에 대해 알려드리겠습니다.

여러분은 코드를 작성하기 전에 하는 것이 있나요? 그냥 구현하기 전 어떻게 구현을 할 것 인지에 대한 생각? 아니면 구현을 어디서부터 할 것 인지에 대한 고민?

 

일반적으로 소프트웨어를 만들기 위한 과정이 존재합니다. 

• 문제 정의
• 요구사항 개발
• 구현 계획 수립
• 소프트웨어 아키텍처 또는 고급 수준 설계
• 상세 설계
• 코드 작성 및 디버깅
• 단위 테스트
• 통합 테스트
• 통합
• 시스템 테스트
• 유지보수

크게 설명을 한다면 설계 => 구현 => 테스트 => 유지보수 입니다.

 

하지만 일반적으로 모든 프로젝트들이 이러한 절차를 FM로 진행을 하지 않죠(비용도 들고 시간도 들기 때문이겠죠) 특히 사이드 프로젝트와 같은 사적인 프로젝트 같은 경우에는 더욱 그렇죠. 소프트웨어를 다른 거에 비유하자면 하나의 집을 짓는 거와 같습니다. 공사를 시작하기 전 기초 공사가 잘 되지 않았거나 계획을 잘못 수립을 했을 때 구현 과정에서 할 수 있는 최선의 행동은 손해를 최소화하는 것입니다. 목수들 사이에서 전해지는 "두 번 측정하고 한 번 잘라라"

이 말은 소프트웨어 개발에서 보면 전체 프로젝트 비용의 65% 정도를 차지하는 구현 작업과 상당히 연관성이 있습니다. 비용이 제일 많이 드는 작업을 두 번 세 번을 해서는 최악의 소프트웨어라고 할 수 밖에 없습니다. 

 

선행 조건의 중요성

프로젝트의 마무리 단계에서 품질을 강조하는 경우에는 시스템 테스트에 중점을 둡니다. 하지만 테스트는 전체 품질 보증 전략의 일부분일 뿐 지금 현재 진행하고 있는 소프트웨어가 잘못된 방법으로 개발하는 것과 같은 문제점을 발견할 수는 없다. 그러한 문제점은 반드시 테스트하기 전, 즉 구현을 시작하기 전에 수행을 해야 합니다.

프로젝트의 시작 단계에 경우에는 고급 제품을 계획, 요구사항을 수집하고 설계합니다. 처음 설계를 아반떼로 작업을 시작했다면 원하는 모든 것을 테스트를 하더라도 아반떼는 결국 제네시스가 되지는 않습니다. 최고의 성능인 아반떼는 만들수는 있겠지만 아반떼가 제네시스로는 될수는 없습니다. 결과가 제네시스를 원한다면 처음부터 다시 계획을 세워야 합니다. 구현 작업은 소프트웨어 프로젝트의 중간 단계로서 구현 작업을 할 때는 이미 소프트웨어의 성패에 영향을 미치는 기초 작업이 어느 정도 진행된 상태입니다. 하지만 구현하는 동안 적어도 현재 상황이 어떤지 판단을 할 수 있어야 하며 잘못된 것을 느낀다면 작업을 되돌려야 합니다. 

 

선행 조건이 최신 소프트웨어에도 적용이 될까?

 

아키텍처와 설계, 프로젝트 계획 수립 같은 선행 작업이 최신 소프트웨어 프로젝트에는 도움이 되지 않는다고 주장하는 사람들이 있습니다. 하지만 이들의 주장은 요즘 수행되고 있는 연구에서도 타당성을 갖지 못합니다. 1970년대 이후로 나온 자료를 보면 본격적으로 구현을 시작하기 전에 적절한 준비 작업을 수행했을 경우 프로젝트를 가장 훌륭하게 진행할 수 있다는 점을 알 수 있습니다. 준비 작업의 가장 중요한 목표는 위험을 축소하는 것입니다. 소프트웨어 개발에서 가장 흔히 발생하는 위험 요소는 불충분한 요구사항과 잘못된 프로젝트 계획입니다. 따라서 선행 조건도 요구사항과 프로젝트 계획을 향상시키는 데 중점을 두는 경향이 있습니다. 하지만 여런분이나 저나 다른 개발자들도 마찬가지로 준비 작업의 중요성에 대해서는 알고 있습니다. 

 

불완전한 준비의 원인

 

1. 투입되는 개발자가 자신의 작업을 수행할 수 있을 정도의 전문가적인 지식을 갖고 있지 않다는 점

2. 프로젝트를 계획하고 강력한 경영 사례를 만들고 포괄적이고 정확한 요구사항을 개발하고 훌륭한 아키텍처를 만드는데에 대한 기술을 교육 받은 적이 없다. 

 

이러한 문제가 있는데 개발자들에게 "선행 작업을 더 많이 수행해라"고 권하는 것은 말이 안됩니다. 

 

하지만 아이러니 하게도 선행 작업을 수행하는 방법은 알고 있지만 코드를 작성하는데 급급해 준비 작업을 하지 않는 개발자가 대다수 입니다. 이렇게 개발을 하는 분들에게 자신이 겪었던 문제를 한번 생각해보시기를 바랍니다. 작은 프로젝트 같은경우는 수정을 하더라도 비용이 적고 시간이 덜 들어서 괜찮지만 커다란 프로젝트 같은 경우에는 비용이 높고 수행 시간도 높습니다. 

 

또는 선행 조건에 대해 문서 형식화 유틸리티 작업을 하고 있는데 관리자가 이에 대해 못마땅하게 보고 있고 빨리 코드와 결과물을 보고 싶어하는 경우 입니다. 이러한 현상을 WISCA(Why Isn't Coding Anything?) 또는 WIMP(Why Isn't Mary Programming?) 신드롬이라고 합니다. 이러한 문제에 해결책으로는 그냥 "알게습니다." 하고 넘어가거나 다른 코드를 띄어 회피하는 방법이 있지만 상사한테 프로젝트의 미묘한 차이에 대해 가르쳐주면 세상에 깨우친 관리자의 수가 늘어난다는 훌륭한 접근 방법이 있습니다.

 

논리적 설득

 

프로젝트를 시작하기 전에는 당연히 프로젝트를 계획해야 합니다. 관리 측면에서 볼 때 계획 수립은 프로젝트에 필요한 시간과 인력, 장비의 수를 결정하는 작업입니다. 기술적인 측면에서는 잘못된 작업으로 인해 돈을 낭비하는 일이 없도록 자신이 만들고자 하는 것이 무엇인지 정확하게 이해하는 것입니다. 

 

비유적 설득

 

소프트웨어 먹이 사슬과 자연의 먹이 사슬을 한번 비교해 봅시다. 생태학적으로 정상적인 환경에서는 갈매기는 신선한 연어를 먹고 연어는 청어를 먹고 청어는 신선한 물속에 사는 곤충을 먹습니다. 그 결과 건강한 먹이 사슬이 유지됩니다.

소프트웨어에서는 아키텍트는 요구사항을 먹고 설계자는 아키텍처를 먹고 코더는 설계를 먹습니다. 프로그래밍에서도 먹이 사슬의 각 단계가 건강하면 결과적으로 개발자도 행복해지고 그들이 작성한 코드의 질도 높아 질 것입니다.  만약에 청어가 물속 곤충에 포함되어있는 PCB 핵폐기물도 함께 먹는다면? 프로그래밍에서도 요구 사항이 오염되면 아키텍처가 오염되고 결과적으로 구현도 오염이 됩니다. 결과적으로 오염된 소프트웨어가 탄생하는 거죠.

반복적인 프로젝트를 계획하고 있다면 구현을 시작하기 전에 구현해야 하는 각 부분에 적용할 핵심 요구사항과 아키텍처 요소를 규명해야 합니다. 건축가가 집을 짓기 전 모든 집의 세부 사항에 대해서는 알 필요는 없습니다. 하지만 건축부지를 조사하고 하수도와 전선을 배치하는 것과 같은 작업은 해야 할 것입니다. 

 

데이터에 근거한 설득

 

지난 25년간의 연구 결과에서 확실하게 증명된 사실은 처음부터 작업을 제대로 수행해야 한다는 것입니다. 

휴랫팩커드, 휴즈 항공, 글로벌 자동차 부품 기업들을 비롯해 여러 기관의 연구원들은 구현 초기 단계에서 결함을 제거하면 제품을 배포한 후나 시스템 테스트 단계에서 제거하는 것보다 10분의 1에서 100분의 1정도까지 비용이 덜 든다는 사실을 알아 냈습니다. 일반적인 원칙은 결함은 가능한 빠른 시일 내에 발견하는 것입니다. 결함이 소프트웨어 먹이 사슬에 오래 머물면서 사슬 아래로 내려갈수록 피해가 점점 커집니다. 요구사항 수집이 가장 먼저 수행되는 작업이기 때문에 요구사항에서의 결함은 시스템에 가장 오래 남아있게 되어 광범위한 피해를 입힐 가능성이 있습니다. 

 

가령 아키텍처 상에서의 결함을 해결하는데 100만원의 비용이 든다면 이 결함을 시스템 단계에서 해결하는 데는 1500만원이 듭니다. 대부분의 프로젝트는 선행 조건 단계보다 추후 단계에 결함을 수정하려고 애씁니다. 많은 회사가 프로젝트 초기에 결함을 고치기 위해서 노력한다면 개발 비용과 일정을 두 배 이상 줄일 수 있다는 사실을 알아 냈습니다.

이는 가능한 빨리 문제를 찾고 해결하는 것이 좋다는 주장을 뒷받침합니다.