대기업이나 중견 기업들은 소프트웨어 개발 문제를 해결하기 위해서 복잡한 프로세스를 도입하곤 한다. 이 때 “중복”의 함정에 쉽게 빠진다. 문서를 비롯해서 소스코드까지 동일하거나 비슷한 내용이 여기저기 중복해서 작성되게 된다. 처음에는 이런 중복이 별 문제 없어 보이지만 시간이 흐를수록 생산성은 기하급수적으로 떨어지게 된다.

비효율적임에도 중복이 필요한 곳은 원자력 발전소나 우주선을 개발할 때다. 나사 하나만 바뀌어도 여러 문서를 확인하고 문제가 없는지 완벽하게 교체해야 하기 때문이다. 하지만 대부분의 소프트웨어는 적은 비용으로 빨리 개발하는 것이 목적이다.

그러기 위해서 소프트웨어 개발자가 가져야 할 중요한 습관 중 하나는 “중복 없애기”다. 이는 개발자뿐만 아니라 다른 직종에서도 필요하지만 소프트웨어 개발에서는 더욱 더 필요하다. 무분별한 중복이 가져오는 비효율성은 업무 생산성을 2배, 3배, 심지어는 10배이상 떨어뜨린다. 10배가 과장은 아니다.

필자는 과거 글로벌 기업의 호주 지사는 7명이 할 수 있는 일을 한국지사에서는 70명이 야근을 하면 힘겹게 일을 하는 사례를 소개한 적이 있다. 초기에는 한국지사가 세계에서 가장 빠른 개발 속도를 보였지만, 몇 년 만에 속도가 10배로 느려진 사례였다. 그 이유에는 여러 가지가 있지만 “중복의 지옥”도 중요한 이유 중 하나다.

“중복 없애기”는 소프트웨어 개발의 생산성을 높이는 매우 중요한 습관이며 그냥 개발자 각자의 습관에 맡겨 놓을 수는 없는 중요한 활동이다. 회사 차원으로 관심과 의지를 가지고 정착을 해나가야 하는 중요한 문화다.

그럼 소프트웨어를 개발할 때 어떠한 중복이 있는지 알아보자.

첫째, 소스코드 내의 중복이다.

적게는 한 단어, 한 줄부터 또는 몇 줄을 복사해서 반복적으로 사용하거나 많게는 함수 하나를 통째로 복사해서 조금 고쳐서 쓰는 경우다. 누구나 그렇게 하면 안된다고 알고 있지만 가장 흔히 벌어지는 현상이다.

비슷비슷한 내용을 개발할 때는 비슷한 코드들이 반복되는데 이를 추상화해서 별도의 모듈로 만들면 좋지만 시간과 노력이 들어간다. 당장 시간에 쫓기는 개발자들은 가장 빠른 방법인 Copy & Paste를 선택하곤 한다. Copy & Paste의 남발은 지옥문으로 스스로 걸어 들어가는 꼴이다. 당장은 개발이 빠르지만 시간이 흐를수록 기하급수적으로 생산성이 떨어진다.

소스코드에 의미를 알기 힘든 숫자들이 가득한 경우도 마찬가지다. 그 숫자의 의미는 개발자가 코딩할 당시는 정확하게 알고 있었어도 시간이 흐르면 본인도 남도 의미를 모르게 되는 경우가 많다. 게다가 해당 값을 일괄 변경해야 할 경우에는 불가능해지기 도 한다. 소스코드에는 숫자가 0 또는 1을 제외하고는 보여서는 안된다. 알아보기 쉬운 이름으로 정의를 해서 사용해야 한다.

소스코드 중복을 최소화하는 좋은 방법은 코드 리뷰다. 이미 호떡집에 불 난 것 같은 상황에서 매일 바쁘게 개발을 하고 있다면 무슨 방법도 소용이 없지만 코드 리뷰를 통해서 코드의 중복을 찾아내고 바로 고치는 것이 좋다. 물론 리뷰 전 코딩 시에 개발자 모두가 중복의 폐해를 명심하고 중복을 없애기 위해서 노력하는 것이 가장 좋은 방법이다.

둘째, 소스코드 파일의 중복이다.

과거 하루가 멀다하고 피쳐폰이 쏟어져 나올 때 피쳐폰을 가장 빠르게 개발하는 방법은 가장 비슷한 피쳐폰의 소스코드를 통째로 가져다가 조금 고쳐서 개발하는 것이었다. 그런 전략으로 피쳐폰 하나의 모델을 3개월만에 만들어내는 기적을 행하였었다. 물론 복사된 소스코드가 넘쳐나면 버그가 하나 발견되면 수십, 수백개의 모델에서 동시에 고쳐야 하지만 해당 모델을 빨리 단종시켜버리는 전략으로 대응이 가능했다. 고객의 불만은 친절한 서비스로 보답하면 된다.

그렇게 해서 비즈니스는 성공했을지 몰라도 개발문화에는 엄청난 폐해를 가져왔다. 그런 식으로 개발하는 것이 몸에 익어서 한번 익숙해진 습관은 쉽게 바꾸기 어려워지게 되었다.

나중에 스마트폰을 개발하는 과정에서도 그러한 습관은 불쑥 불쑥 튀어나오게 되었다. 이러한 습관이 팽배한 상황에서는 전사적으로 같이 사용할 공통 프레임워크를 만드는 일은 쉬운 일이 아니다.

CTO나 Chief Architect가 이끄는 그룹에서 회사의 현재의 기술적인 요구뿐만 아니라 미래의 비즈니스 전략을 고려하려 향후 몇 년을 사용할 수 있는 공통 프레임워크를 설계하고 만들고 유지시켜 나가야 한다. 이런 와중에도 성질 급한 영업 위주의 경영자들의 수많은 방해와 도전을 막아 낸다는 것도 쉽지 않다. 전사적으로 몸에 베어버린 습관은 버리기 어렵기 때문이다.

셋째, 개발의 중복이다.

다른 팀에서 서로 비슷한 것들 개발하는 것이다. 두 번째와 비슷하지만 이번에는 각 팀에서 서로 모르고 개발을 하는 것이다. 그러다 보면 비슷한 것들을 여러 팀에서 개발하게 된다. 이는 회사차원에서 대단히 낭비 일뿐만 아니라 부서간에 개발 정보나 노하우가 공유되지 않는다는 증거이다.

고급개발자가 될수록 자신의 팀의 개발뿐만 아니라 다른 팀의 개발 프로젝트도 두루 두루 관여를 해야 한다. 설계 리뷰에도 참여를 하고 코드리뷰에도 참여를 해야 한다. 이러한 문화는 중복을 줄여줄 뿐만 아니라 개발자의 개발 역량을 향상하는데도 도움이 된다.

넷째, 문서의 중복이다.

흔히 하는 착각 중에 개발 문서를 정말 많이 꼼꼼하게 적으면 개발이 잘 될 것으로 생각하는 것이 있다. 개발문서가 아예 없는 것도 문제지만 문서가 정말 많은 것은 더 문제가 된다.

웬만한 규모의 소프트웨어를 개발할 때 문서는 SRS(Software Requirements Specification)를 포함해서 한두 개면 된다. 이것도 딱 필요한 만큼 가능하면 적게 적어야 한다. 그런데 프로세스를 강화한 회사들은 개발문서만 수십 개를 적는 경우가 있다. 이러면 필수적으로 같은 내용이 여러 문서에 적히게 된다. 처음 작성할 때는 복사를 해서 작성을 하면 되지만 프로젝트의 내용은 계속 바뀌게 되어 있다. 그런데 이렇게 여러 문서에 많이 적어 놓게 되면 나중에 고칠 때 어렵거나 불가능하게 된다. 결국 쓰레기만 쌓이게 된다.

이런 문서들에는 서로 다른 내용이 남아 있게 되고 나중에는 어느 것이 맞는 내용인지 알 수 없게 된다. 이런 경험을 가진 개발자들은 개발 프로세스, 방법론 다 필요 없다고 생각하게 된다. 나쁜 경험이 가져오는 폐해다.

제일 나쁜 것은 미련한데 부지런 한 것이다. 부지런하게 잔뜩 중복 소스코드, 문서를 만들어 놓은 상황이라면 어찌할 도리가 없다. 처음부터 중복을 없애는 노력을 문화적으로 프로세스적으로 실천해야 한다. 어려운 것은 가장 알맞은 정도의 수준으로 정하는 것이다. 교과서에서 필요한 만큼이 이만큼이라고 설명할 수는 없다. 경험을 통해서 배워야 한다.

이글은 ZDNet Korea에 기고한 칼럼입니다.