실용주의 소프트웨어 개발

실용주의 소프트웨어 개발 - 현장에서 길어올린 소프트웨어 개발 베스트 프랙티스(Best Practices)
오병곤 지음 / 로드북 / 2017년 4월

오병곤 저자님의 책은 오랜만에 읽어본듯 하다. 

대한민국 개발자 희망보고서 라는 책을 예전에 읽었었고..

월화수목금금금 에 상당히 공감했었다.

IT 의 힘든 상황에서 기술사 자격증을 땃다는 것에 놀랐고 참 대단함을 느꼈었다. 

개인적으로는 아직도 그정도의 열정을 쏟지는 못하고 있는듯 하다. 

이 책은 프로젝트를 성공적으로 마치기 위해서 

실용적으로 어떻게 소프트웨어 개발을 진행할지에 대한 내용을 담고 있다. 

넓게는 프로젝트 개발하면서 우리가 흔히 접하게 되는 개발단계의 단계별 과정을 다루면서

해당 단계의 문제점과 대안 그리고 우수사례를 다루고 있다. 

간접적으로 프로젝트의 진행이 어떻게 이루어지는지 나 해당 과정에서 어떠한 문제가 발생을 하는지 

그러한 문제가 발생하지 않기 위해서 어떠한 방법을 쓰고 어떠한 우수사례가 있는지를 접할 수 있어서 좋은 듯 하다. 

그전에도 우리나라 특유의 빨리빨리 가 it 도 예외는 아니어서 

외국보다 더 짧은기간에 개발을 했었지만 

점점 경기가 안좋아져서 그런지

이제는 그 기간마저도 더 줄이고 개발자도 더 줄여서 개발을 진행하는 경우가 많다. 

책에서 얘기하는 것처럼 프로젝트는 분석,설계,개발,단위테스트,통합테스트 등의 단계의 과정을 거치며

개발을 해나간다. 

그런데 요새는 앞의 분석,설계을 없애거나 개발에 합치고 개발기간은 줄이고 

단위테스트도 개발에 합쳐버리는 개발,통합테스트 의 과정으로 가는 경우도 많다.

더구나 개발자는 전보다 축소하고 기간도 축소를 해서 프로젝트를 한다. 

예전에 3년정도의 기간을 잡고 하던 프로젝트를 요새는 1년을 넘기는 경우가 거의 없다. 

개발자들은 기계가 아니다. 

프로그램 개발은 기계적으로 키보드를 두드려서 완성하는것이 아닌데

기본적으로 무엇인가를 개발하기 위해서는 개발전에 어쩌면 개발보다 더 긴 시간을 생각을 하며 구상을 해야 한다. 

책에서도 말하는 것처럼 개발자들에게 그러한 생각할 시간이 필요한데..

요새 현실은 그러한 생각의 시간조차도 없애려고 하고 있다. 

그냥 자리에 앉아있는걸 더 중요하게 여기는 경우도 많다. 

책에서 말하는 것처럼 우리는 최선을 다하고 있다는 보여주기식, 면책용 등의 방법으로 

개발자들의 시간을 이용하는 경우가 많다.  

it 에는 많은 방법론이 나와있다. 해당 방법론들은 모든 프로젝트에 적합한것이 아니다.

책에서도 얘기하고 있지만 해당 프로젝트마다의 상황에 맞추어 그에 맞는 적절한 프로세스를 정의해야 하는데..

그러한 부분이 아직까지 잘 이루어지지 않는거 같아 좀 아쉽다.

내가 겪은 프로젝트들은 그때 트렌드에 따라 이 개발방법론을 쓰면

개발기간이 단축이 되고 비용도 단축시킬수 있다면서 무슨 마술인것마냥 쓰는 경우가 많다. 

개발방법론이라는게 해당 프로젝트의 개발기간을 단축시키거나 비용을 단축시키기 위해서 사용하는건 아니라고 생각한다.

개발을 진행하면서 시행착오로 개발기간의 연장과 그에 따른 추가 비용 및 요구사항 변경들에 따른 추가리스크, 추후 유지관리 등에 대한 리스크를 

최소하 하기 위한 것이라고 생각한다. 

실제 그 프로젝트에 들어가는 실공수가 줄어드는 것은 아니라고 생각하는데.. 

이상하게 이 방법론을 쓰면 실공수가 이렇게 줄어요.. 와 같은 식의 프로젝트를 많이 겪게 된다. 

결국은 프로젝트를 성공시키기 위해서 개발자들은 월화수목금금금 상황을 계속 할 수 밖에 없게된다.

정작 그렇게 만든 관리자들은 책임을 안지는데 실제 개발하는 개발자들이 책임을 지는 상황인것이다. 

책에서 언급한 고객의 인식도 가장 바뀌어야 할 부분중 하나이다. 

눈으로 보이는 것은 쉽게 요구를 변경하지 않는다. 

책에서 찰흙을 예를 들었지만 만들어 이미 굳어버린 찰흙으로 다른걸 만들어 달라고 요구를 하진 않을것이다.

그런데 소프트웨어 개발에서는 고객이 아무때나 그냥 수정할 수 있다고 생각한다.

소프트웨에의 개발도 찰흙처럼 굳으면 다시 변형하기가 힘들다는 인식을 가지는게 참 중요하다고 생각한다. 

시스템 오픈이 내일인데.

오늘 요구사항을 변경하면서 수정해달라는 경우도 허다하다.

갑질 이라는 단어가 요새 많이 사용되는데

기존에 작성한 요구사항정의서 든 해당 요구에 대해서 이렇게 협의했다는 사인을 했든

분명 이렇게 해달라고 하지 않았냐는 회의록 녹취 든.. 소용이 없다. 

고객의 입장은 그렇다. 우리가 필요하다는데... 

개발자가 안된다고 하면 관리자에게 얘기해서 통과시키기에.. 

이러한 요구사항 변경에 대한 고객의 인식의 변화가 중요하다고 생각한다. 

짝프로그래밍은 우리나라의 특성상 할수가 있을까 하는 생각을 아직도 가지고 있지만 

그 비슷한 방식은 실무에서는 종종 하는 경우가 있다.  

나과장은 A 라는 업무를 하고 있고 윤과장은 B 라는 업무를 하고 있는데

윤과장의 B 업무중 어떤 프로그램의 개발에 문제가 생겨서 윤과장이 나과장에게 도움을 요청하면

둘이 같이 의논을 하면서 개발하는 경우는 종종 있다. 

이건 프로젝트의 정책으로 하는게 아닌 

두 개발자의 유대관계가 좋을때 위처럼 서로 도와가며 헤쳐가는 경우가 있다. 

해당 업무를 하고 있던 개발자는 계속 보고 있던 소스이기에 거기에 국한된 시야가 생기는 경우가 있다.

그럴때 그러한 제한된 시야를 가지지 않는 개발자가 같이 보게 될 경우 의외의 해결책이나 버그가 쉽게 발견되는 경우가 많다. 

이러한 제한된 시야가 생기는 걸 없애기 위해서도 책에서 말하는 것처럼 

개발자들에게 생각할 시간을 주는게 프로젝트의 리스크를 줄이는 좋은 방법이 아닐까 생각한다. 

책에서도 언급하고 있지만

프로젝트의 공수산정을 제대로 하는게 가장 첫번째 과제일 것이다. 

이 부분도 문제는 소프트웨어 개발은 아무래도 눈에 보이는게 아니기에 그러한 공수산정 자체가 많이 힘들기도 해서

재대로 공수산정이 안되는 경우도 많지만 

더 큰 문제는 그렇게 제대로 산정이 안된 공수산정 조차 고객의 요구에 의해 심하게는 절반으로 줄인다는 것이다.

그 기간자체가 비용이므로 고객은 좀더 저렴한 비용으로 프로젝트를 하려고 한다. 

우리나라의 모든 IT 분야가 그런건 아니지만 

개인적으로 겪었던 IT 프로젝트를 생각하다보니 답답해서 사설이 길었던듯 하다. 

IT 프로젝트에 대해서 발생하는 단계마다의 문제점과 그에 따른 우수사례 등을 간접적으로 접할 수 있어 

IT 에 관심있는 분들이 읽으면 좋을듯 하다. 

개인적으로는 관리자나 고객 처럼 실제 칼자루를 쥐고 있는 분들이 읽고 

인식이 좀 많이 바뀌었으면 좋겠다는 생각을 한다.