・워터폴의 각 프로세스에 대해
그렇다면 이제 순서에 따른 프로세스들의
세부적인 내용에 대해 알아보자.
위에서 살펴본 기본형과 사이클을 다시 한번 가져와 보면,
아래와 같다.
 |
| 워터폴(WaterFall) 기본형 모델 |
①요구 분석(Analysis) → ②설계(Design) → ③개발(Implementation) →
④테스트(Test & Integration) → ⑤유지・보수(Maintenance)
요구 분석(Analysis)부터 시작해 세부적으로 살펴보자.
사실 프로젝트에서 이런 프로세스가 있지만,
일반 사람들이 인식하고 있는 것은 개발,
단 한 프로세스이다.
이 단계에서 실제로
개발자들이 프로그래밍을 통해 구현하게 된다.
그리고 대부분의 주니어들은
아마 자신이 이런 개발 단계만 하리라,
그리고 실제 실무를 하면 거기에 투입되리라 생각하겠지만,
그렇지 않다.
그런 생각을 가지고 업계에 들어온 주니어들에게는
희망적이지도, 달가워하지 않을 이야기일지도 모르겠지만,
특히 주니어라면 더더욱
개발을 맡기지 않는다.
주니어에게 개발 프로세스의 일을 맞기게 되는 상황이라면,
매우 좋지 않은 상황이며,
정상적인 개발 프로세스가 수행되고 있다고 보기 힘들다.
그렇다 하더라도,
개발만이 개발자의 일은 아니며,
다른 프로세스보다 개발 프로세스가 더욱 중요한 것은 아니다.
이 프로세스에서 중요하지 않은 프로세스는 없다.
간혹 개발자들 중에
특히 테스트를 역할을 맡는 팀을 우습게 보고
이들을 무시하는 경향이 있는데,
어느 프로세스의 역할을 하건 간에
프로젝트 안에서 수직적인 위 아래는 없으며,
그런 하에 프로젝트의 인원들은 모두 동료다.
그렇지 않다면,
우리들의 프로젝트는 원활히 돌아가지 못할 것이다.
따라서 만약 그런 선배들이 보인다면
그런 사람들을 보고 배우지 않았으면 하는
작은 바램이있다.
어쨋든
이 중 하나의 프로세스라도 정상적으로 수행되지 않는다면,
프로젝트는 제대로 완수했다고 볼 수 없다.
그렇기 때문에
개발 일을 하고 싶어서 왔다 하더라도,
아무리 개발 능력이 뛰어나더라도,
주니어에게 개발 일을 맡기는 상황은 매우 드물다.
모든 일은 때와 순서가 있는 법이다.
어쨋든,
여기서 살펴볼 점은 요구 분석에 대한
학문적 개념이 아닌 실무에 더 가까울 것이다.
학문적 지식이 필요하다면
구글링을 통해 알아보길 권하지만
읽어도 딱히 도움될것 같다는 생각은 들지 않을 것이다.
① 요구・분석(Analysis)
요구 분석 단계에서는
클라이언트가 원하는 것은 무엇인지를
듣고 분석하는 것을 말한다.
여기서 말하는 클라이언트는
프로젝트가 누구를 위해 진행되느냐에 따라 다를 수 있다.
회사 내부에서 진행되는 프로젝트라면 회사이고,
회사 외부라면 그 외부 회사가 클라이언트가 될 것이다.
그리고 이런 클라이언트들은
대개 이런 프로세스가 있는지 조차 모르며,
프로그래밍에 대해 전혀 모르고 있는 사람들이다.
여기서 어떤 사람은 조금 이상한 것을 느끼고
무언가 답답함을 느낄 것이다.
'클라이언트의 요구만 들으면 되는거 아닌가?
그리고 그걸 굳이 분석할 필요가 있나?'
주니어가 위와 같은 생각이 든다면
당연한 것이다.
왜냐하면 프로젝트를 어느정도 경험해봤다면,
분석을 해야 하는 것은 당연하다고
생각할 수 밖에 없기 때문이다.
개발자들 사이에서 우스겟소리로 하는 말이 있다.
'클라이언트들은 자신이 원하는 것을 모른다.'
대개 클라이언트의 요구 사항들은
구체적이지 않으며,
추상적인데다가,
말을 바꾸기 십상이다.
따라서 그들의 말대로
프로젝트를 완수했지만,
그들이 원했던 것이 아니라는 둥
이런 기능이 아니였다는 둥
이런 기능을 추가시켜줬으면 좋겠다는 둥의
이야기가 나온다.
그렇기 때문에
우리는 그들의 요구를 듣고, 분석한 다음
클라이언트가 정말 원하는 것이 그것 인지에 대해 묻고
필요하다면 제안도 해야 된다.
그래서 이 단계를 제대로 수행하냐,
수행하지 않냐에 따라,
우리들의 프로젝트를 한번에 완수할 수 있느냐
여러 번 해야만 하느냐가 갈린다.
따라서 이 역할을 맡는 사람의
커뮤니케이션 능력에 따라,
실제 프로젝트를 진행하는 구성원의 일의 강도가
사실상 결정된다고 볼 수 있다.
또한 일의 강도가 문제가 아니라,
경우에 따라서는 프로젝트를 엎고
처음부터 다시 진행해야 될 수도 있다.
그렇기 때문에 이 프로세스가
제대로 수행되지 않는다면,
그 프로젝트의 결말은
우리가 보지 않더라도 알 수 있다.
높은 확률로 프로젝트를
처음부터 다시 시작해야할 것이다.
최악의 경우 프로젝트가 중지될 수도 있다.
그 경우,
개발자의 커리어에 좋지 않은 영향을 줄 것이다.
② 설계(Design)
요구 분석 단계 못지 않게 설계(Design)도 매우 중요하다.
이 단계에서는 여러가지가 수행 될 수 있는데,
요구 분석의 문서를 기반으로
어떤 언어를 , 어떤 DB를, 어떤 서버를 사용할지 등의
전체적인 시스템 아키텍쳐를 설계하고
점점 세부화 작업를 거쳐,
최종적으로
개발 단계의 설계서인 상세 설계를 작성하게 될 것이다.
그리고 UI를 비롯한 디자인의 설계도 여기에 포함된다.
아마 개발자로서 관련있는 부분은
함수나 클래스들의 설계인
상세 설계가 가장 관련이 깊을 것이다.
실제 함수 이름, 대략적인 알고리즘, 변수 이름 등이
설계되어 있는 이 상세 설계를 보고,
개발 단계에서의 프로세스가 수행된다.
특히 상세 설계가 잘못되어 있으면,
개발자로서 매우 골치 아파지는데,
잘못된 상세 설계서를 보고 개발을 하게 되면
버그가 생겨, 오류가 발생할 가능성이 크기 때문이다.
당장 문제가 없다 하더라도,
시스템을 돌려볼 때
특정 하나의 모듈의 버그로 인해
시스템이 다운되는 경우도 부지기수이기 때문에
상세 설계를 누가 하느냐에 따라
개발 프로세스의 수행 속도가 결정될 것이다.
또한 상세 설계를 비롯한 이런 설계서들은
프로젝트 도중에 합류한 개발자들이
시스템에 대해 이해하기 위한 서류로도
많이 활용되는데,
제대로 작성되어있지 않다면,
새로 합류한 개발자가 시스템에 대한 이해 속도가 떨어져
개발 일정에 차질이 생길 것이다.
여러면에서 보나
이 설계 단계가 매우 중요하다는 것은
개발자들에게 있어서 너무나도 자명한 사실이다.
설계가 중요하지 않다고 생각하는 개발자들은
대개 개발자로서 자질이 부족하거나,
경험이 부족한 사람들이다.
그들의 말을 귀를 기울일 필요는 없다.
③ 개발(Implementation)
개발 프로세스는 말 그대로 개발을 하는 프로세스이다.
흔히 일반 사람들이 알고 있는
개발자가 하는 일에 대한 인식이
이 개발 프로세스에서 업무를 하는 사람들이라고 할 수 있다.
개발자라면,
정해진 프로그래밍 언어로,
설계되어 있는 상세 설계서를 보며
프로그래밍을 함으로써 개발을 하게 되는 프로세스이다.
물론 경우에 따라서는 매우 안타깝게도
상세 설계서가 없을 수도 있다.
나도 이 부분에 대해서는 매우 안타깝게 생각하고 있다.
하지만 이는 어쩔 수 없다.
프로젝트에는 제한된 비용과
제한된 시간이 있기 때문에
상세 설계를 할 시간이 없을 지도,
상세 설계를 할 인원이 모자를 지도
혹은 상세 설계를 할 능력이 되는 사람이 없을지도 모른다.
따라서 개발 프로세스에 업무를 하는 개발자들은
이에 대해 인지하고 있어야 하며,
인정할 수 밖에 없는 부분이다.
만약 개발 프로세스의 개발자가
상세 설계를 할 수 있다면,
가급적 상세 설계를 하는 것이 좋을 것이다.
여유치 않으면,
상세 설계 없이 개발해야하는 상황이 있을 지도 모른다.
하지만,
이 경우는 매우 리스크가 크며,
많은 버그를 남길 수 있는 여지를 준다.
버그를 완벽하게 막는것은 사실상 불가능하기 때문에
가능한 버그를 남길 수 있는 여지를 줄이는 것이 가장 좋다.
이 부분에 대해서는 정확히 인지하고 있어야 한다.
인생도 그렇지만
항상 우리에게 최고의 상황만이 주어지는 것은 아니다.
④ 테스트(Test ＆ Integration)
한국에서는 QA라고 불리기도 한다.
테스트에는 블랙박스 테스트 라던가,
화이트박스 테스트라던가
학문적으로 여러가지 개념이 존재하지만,
이런 개념들과 이름 자체는 크게 중요하지 않다.
여러 번 언급하지만,
이런 학문적 지식들은 실무에서 크게 중요하지 않다.
우리들은 직감만 얻으면 된다.
혹시 필요하게 된다면,
그때 구글링해서 잠깐 보기만하는 것으로 충분하다.
이런 학문적 지식들을
모두 외운다는 것은 쉽지 않으며
할 수 있다고 하더라도
실무에서 그렇게 유용하지도,
시간적으로도 효율적이지 못하다.
어쨋든 테스트의 종류로서 언급될 수 있는 것들은
모듈 테스트 포함한 여러가지 있을 수는 있겠지만,
프로세스로서의 테스트를 크게 본다면
'우리가 개발한 시스템이 제대로 동작하는가'를 테스트 하는 것이다.
프로그래밍을 하면서 하는 디버깅도 테스트라고 할 수 있다.
가능하다면,
이런 테스트 전담하는 팀이 있는 것이 좋다.
개발 프로세스를 수행하는
사람들의 능률이 올라갈 수 있다.
하지만 여유롭지 못한다면,
이 단계는 개발 프로세스를 수행하는 인원들이 하게 될 확률이 높다.
그렇게 된다면,
아마 주니어들이 이런 일을 하게 될 것이다.
⑤ 유지・보수(Maintenance)
유지・보수 프로세스에서는
테스트 과정에서 나온 문서들을 기반으로
수정하는 프로세스를 말한다.
보통 주니어들이 투입되는 곳이
이 유지・보수 프로세스 프로세스이다.
왜냐하면,
대개 시니어들은 설계나, 개발 프로세스에
투입되기 때문이기도 하지만
주니어들은 대개
워터폴과 같은 업무 프로세스나,
다른 개발자들의 코드를 보는 능력이 떨어지기 때문에
버그가 있는 코드를 찾고 수정함으로써
프로그래밍 실력 향상은 물론이며
다른 개발자들의 코드를 보는 능력을 향상시키고,
시니어 개발자들과 협업하면서 업무 프로세스를 익힐 수 있다.
때문에 개발 프로세스에 투입되지 않는다고 하더라도
너무 억울해하지는 않았으면 한다.
위에서 말했듯이
모든 일에는 때와 순서가 있는 법이다.
어쨋든 이렇게 유지 보수를 완수한다면,
그 다음 부터는 워터폴을
어떻게 다시 수행할 것인가에 대해
다시 한번 프로젝트 구성원들과 논의를 해봐야 한다.
--------------------------------------------------------------------------------------------------
2020.05.29 워터폴 ①, ②, ③로 나눔, 개행 및 내용 수정
