2017년 2월 11일 토요일

개발 프로세스가 개발 문화를 이기기 어려운 이유

우리나라의 많은 기업들은 SW 개발에 실패를 했다.
그뒤 선진 소프트웨어 개발 방법을 배우고자 노력을 많이 했고, 그 결과 개발 방법론, 프로세스를 도입하였다.

하지만 그 결과 SW개발은 더욱 비효율적으로 바뀌게 되었다. 그 이유는 무엇일까?

SW 개발에 있어서 정교한 프로세스를 정하면 프로세스에 매몰되고 프로세스가 점점 복잡해져 간다.
완벽한 프로세스는 없는 것이 당연하고 문제는 계속 생긴다. 이때마다 이를 해결하기 위한 프로세스를 계속 만들어가면 괴물 프로세스가 탄생하게 된다.

SW를 가장 효과적으로 개발하는 방법은 프로세스에 상관없이 가장 적절한 과정으로 개발하는 것이다. 그 적절한 과정은 성숙한 개발 문화 속에 있다.

하지만 많은 회사들은 애매하고 어려운 개발 문화보다는 명백하고 따라하기 쉬운 개발 프로세스에 집중해왔다. 그 결과 주먹구구식을 개발할 때보다 개발 효율성은 더 떨어졌다.

프로세스를 통해서 효율적인 개발 과정을 제대로 정의하기 어려운 이유는 아래 대화를 보자. 최고의 소프트웨어 실전 전문가에게 질문을 하면 아래와 같이 답을 할 것이다.
 
Q. 모든 소스코드는 코드리뷰를 다 해야 하나요?
A. 아니요, 그때 그때 달라요.

Q. 코드리뷰에 꼭 포함해야 하는 필수 리뷰어는 누구 인가요?
A. 그때 그때 달라요.

Q. 스펙은 꼭 작성해야 합니까?
A. 그때 그때 달라요.

Q. 스펙을 작성할 때 가장 중요한 부분은 어디 인가요?
A. 그때 그때 달라요.

Q. 설계서는 꼭 작성해야 하나요?
A. 그때 그때 달라요.

Q. 효율적으로 설계서를 작성하는 방법은 무엇인가요?
A. 그때 그때 달라요?

Q. 매번 경우마다 다른데 개발 프로세스는 어떻게 정하죠?
A. 그래서 프로세스를 너무 자세히 정하면 안됩니다. 최소한으로 정하고 개발자들의 판단력을 믿어야 합니다.

Q. 대기업은 그래서 프로세스 테일러링을 통해서 프로젝트마다 적절히 프로세스를 간소화해서 산출물도 줄이는 등 개발 프로세스를 효율적으로 적용하려고 노력하고 있습니다.
A. 이 또한 하다하다 안되니까 형식적으로 진행하는 겁니다. 심지어는 개발도 잘 모르는 사람들이 테일러링을 합니다.

Q. 알아서 하라고 하면 과거처럼 스펙도 없고, 공유도 안하고 주먹구구식으로 하지 않을까요?
A. 그렇기 때문에 역량과 문화가 중요합니다. 문화가 아무리 좋아도 역량이 안되면 공염불입니다.

프로세스는 복잡할수록 손해다. 문제만 없다면 프로세스가 없는 것이 제일 좋다. 문제가 있기 때문에 최소한의 제약을 가하는 것이다. 프로세스가 간단할수록 성숙도가 높다. 물론 주먹구구라서 프로세스가 없거나 간단한 회사는 예외다.

하라고 해서 억지로 하는 상황이라면 효과를 기대하기는 어렵다.

문화라고 하는 것은 "왜"가 아니고 "그냥 그렇게" 하는 거다.

그냥 스펙을 적절히 작성하는 것이고, 그냥 필요한 만큼 설계를 하며, 그냥 코드 리뷰를 한다.
모든 직원이 그냥 그렇게 할 수 있을 때 문화로 정착되었다고 할 수 있다.

그렇게 되면 과거로 돌아가자고 해도 모두 반대한다.

프로세스는 절대로 문화를 이기기 어렵다. 효율성이 몇배 차이가 난다. 10배 이상 차이가 날 때도 있다.

프로세스 보다는 SW 개발의 원리를 깨우쳐야 한다. 각 분야에 전문가들이 최소의 프로세스 하에서 최선의 판단을 해서 진행하면 된다.

잘 안된다고 프로세스를 점점 복잡하게 하고 너무 과하게 적용한다면 문제는 점점 커질 것이다.

개발 문화가 점점 성숙해 질수록 프로세스는 만들었다가 간소화 시켰다가 없앴다가를 반복하게 될 것이다. 그래도 신입직원을 위해서 읽을만한 프로세스 문서는 존재하게 된다. 하지만 기존 직원들은 숨쉬는 것처럼 익숙해지고 원리를 깨우쳤기 때문에 프로세스 문서를 계속 보거나 프로세스를 따라하기 위해서 억지로 행하지는 않게 된다.

이쯤되면 SW를 좀 개발할 수 있게 됐다고 자신 있게 말할 수 있다.