소프트웨어 개발 프로세스와 프로세스 자동화의 함정

개발 방식에 고민이 없다는 것은 현재의 방식이 완벽하다거나 아니면, 전혀 그렇지 않거나 개발 방식에 대해 관심없다는 의미일것이다. 만약 개발 방식에 대한 관심이 없다면 각 구성원은 자신의 개발 경험과 눈빛만 보아도 통하는 암묵적인 프로세스에 의존하여 개발을 진행을 할 것이다.


[무단복제금지-엄준일[(POWERUMC)]]5

개발 프로세스와 프로세스 자동화

애자일과 같은 가벼운 개발 방법 또는 프로세스는 소규모의 팀이나 구성원들에게 매우 긍정적인 영향을 끼쳤다. 암묵적인 프로세스는 명시적으로 도출이 되어야 한다는 것과 물 흐르듯 자연스러운 조직 내의 개발 프로세스는 소프트웨어 개발 전반적인 품질을 향상시키거나 현 위치를 올바르게 인지할 수 있다는 것도 알게 되었다.

그리고 여러 가지의 툴을 도입하면 개발 프로세스를 더욱 강력하고 정책화시킬 수 있다. '째깍 째깍' 돌아가는 아날로그 시계처럼, 매일 매일 체크인 된 코드를 검증하고, 빌드 그리고 테스트를 수행하게 된다. 조직에서 개발 프로세스에 툴이 결합하면 개발현황을 파악하고 개발 프로세스의 전반적인 부분을 시각화 할 수 있다.


[무단복제금지-엄준일[(POWERUMC)]]10

실제로 필자는 부하테스트에 대한 분야에서 기술적인 경험들 축약하여 부하테스트에 대한 부분을 자동화를 한 적이 있다. 부하테스트에 대한 부분에서 자세한 이야기는 기회가 되면 다음에 다시 다룰 예정이다. 어쨌든 이런 부하테스트를 일일 테스트(Daily Test), 주간 테스트(Weekly Test)로 적용하고 리포팅을 자동화하였을 때, 시간의 흐름에 따라 서버나 클라이언트 역할을 하는 지점의 변화와 데이터베이스에 데이터가 적재됨에 따라 성능적인 부분과 안정성 부분에서 시스템 전체적으로 그 어떤 방법보다 명확하게 인지하고 이해할 수 있다. 즉, 어떠한 프로세스는 시각화될 때 의미있고 이해할 수 있는 데이터가 될 수 있다.

하지만, 물 흐르듯한 개발 프로세스에서 하루 하루 유영을 하는 개발자 한명 한명을 관찰해보자. 소프트웨어 전반적인 품질이 좋아진다는 것은 개발자 한명 한명이 누릴 수 있는 어떤 혜택도 되지 않는다. 물론 시스템의 장애와 버그가 줄어든다고 해도 말이다. 오히려 개발자 한명 한명에게 개발 프로세스의 강제화나 정책화는 기존에 개발하는 방식의 일보다 더 많은 시간적인 리소스가 필요하다. 이메일과 메신저와 같은 단/양 방향의 커뮤니케이션 채널은 개발 프로세스를 움직이는 동력과 같은 시스템으로 접근하여 각 작업의 명확한 트래킹(Tracking)을 위해 철저하게 데이터베이스화 되어 관리된다.

개발 프로세스를 도입하고 이것을 자동화하였을 때, 팀이나 조직의 관리자에게 가장 편안함을 준다. 조작되지 않은 신뢰할 수 있는데이터를 앉아서 받아볼 수 있으니 말이다. (물론 조작은 얼마든지 가능하다.) 관리자는 현황을 파악하기 위해 더 이상 발품 팔듯이다닐 필요가 없어진 것이다. 하지만 개발 조직의 개발자는 작업 관리를 위한 시스템은 편리하기보다 불편하다고 느낄 때가 더 많다.

개발 프로세스에 의한 양극화 발생..

왜 그럴까? 개발 프로세스를 도입하고 개발 프로세스를 자동화함으로써 모두에게 효율성이 좋아져야 하는데 왜 양극화가 발생하는 것일까?

개발 프로세스의 자동화는 닦아 놓은 길을 똑바로 따라가지 않을 때, 즉시 이를 트래킹 할 수 있다. 관리자의 입장에서는 팀원 개개인의 퍼포먼스를 끌어 올리거나 업무 향상을 기대할 수 있겠지만, 모든 경우가(대부분의 경우가) 이렇게 아름다운 업무 환경으로이어지지 않는다. 이 부분은 독자들의 상상에 맡기겠다.

또 하나는 전체적인 프로세스가 개선이 되었지만, 개개인이 이 프로세스에 올라 타 개발 프로세스의 이점을 누리기가 힘들다.대한민국의 1인당 국민 소득이 증가한다고 반드시 나의 소득이 올라가지 않는다. 대한민국의 경제가 5% 성장한다고 반드시 나의 경제 여건이 5% 좋아지지 않는다. 개발자의 개개인의 개발 프로세스에 대한 성숙도는 전반적으로 개발 프로세스를 최적화시키고 툴과 시스템과 통합하여 개선되는 속도보다 더디다. 즉, 많은 팀이나 조직에서 "일단 도입부터..." 시작하는 곳이 많다.팀이나 조직의 개발 프로세스 성숙도는 높은데, 개개인의 성숙도는 낮다면 이건 무슨 시추레이션인가.

그렇다고 개개인의 개발과 개발 외적인 성숙도를 높이는 것도 매우 어려운 일이다. 개발자는 개발을 잘 하는 것이 기본 자격 요건이다. 개발을 잘 하지 못하는 아마추어는 많다. 당장 서점에 가서 책 한권을 사서 뚝딱 아이폰 앱을 만드는 사람은 널리고 널려있다. 하지만, 실제로 개발 현장에 나가보면 프로그래밍 언어의 딱 10가지 키워드와 10가지 클래스, 그리고 대부분 그 외의것들을 모르고 있는 개발자들이 너무 많다. 이들을 버릴 것인가? 끌고 갈 것인가? 라는 물음에서 결국 하향 평준화를 선택할 수밖에 없다.

필자는 여기에 굳이 답을 제시하지 않겠다. 관점의 차이도 있겠고, 정답이 있는 것도 아니기 때문이다. 어쨌든 개발 프로세스와프로세스 자동화에 집중을 하고 있었다면, 그 이면의 잘 보이지 않거나 어두운 부분을 재조명해 보는 것이 개발 프로세스를 최적화할 수 있는 방법이라는 것이다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요