태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

개발자에게 필요한 중요한 습관, “중복 없애기”

2015/02/03 19:54 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


셋째, 개발의 중복이다.


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


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


넷째, 문서의 중복이다.


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


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


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


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



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



저작자 표시 비영리 변경 금지

전규현 개발프로세스

Trackback Address: http://allofsoftware.net/trackback/361 관련글 쓰기
  1. Blog Icon
    김성엽

    좋은 내용 잘 읽었습니다.

  2. Blog Icon

    비밀댓글입니다

개발자에게 필요한 중요한 습관, “중복 없애기”

대기업이나 중견 기업들은 소프트웨어 개발 문제를 해결하기 위해서 복잡한 프로세스를 도입하곤 한다. 이 때 “중복”의 함정에 쉽게 빠진다. 문서를 비롯해서 소스코드까지 동일하거나 비슷한 내용이 여기저기 중복해서 작성되게 된다...

혼자만 알고 있는 개발자들

많은 회사 개발자를 만나면서 느끼는 우리나라 소프트웨어 회사들의 가장 큰 문제 중 하나는 개발자간에 정보와 지식의 공유가 잘 안 되는 것이다. 회사가 크던 작던 거의 모든 회사가 동맥경화에 걸린 것처럼 정보와 지식이 공유되고..

21C 韓 SW개발자는 16C 조선 陶工 처지

나의 취미 중 하나는 도예 즉, 도자기 만들기다. 우연한 기회에 시작해서 10년을 넘게 도자기를 만들었으며 도자기 역사나 도자기 기술에 대해서도 많은 공부를 하게 되었다. 그런데 요즘 우리나라의 소프트웨어 산업 환경이 조선..

외국 개발자들이 보기에 군대 같은 한국 회사

“A기업은 좀비월드 같다. 직원들이 아무 생각 없이 회사를 떠돈다.” “B기업 직원들은 불만을 말하지 않는다. 근무 내내 감옥에 있는 느낌이다.” “C기업은 군대다. 상사가 말하면 무조건 따라야 한다. 이유를 묻거나 질문할..

쓸데없는 회의를 줄이는 방법

'회의가 많은 회사는 곧 망한다'는 속설이 있다. 다른 분야에서도 마찬가지지만 개발자도 회의에 많은 시간을 빼앗기면 개발에 집중하기 어렵고 이는 개발 생산성 저하로 이어진다. 꼭 필요한 회의는 해야 하지만 과도한 회의는 줄여..

한국의 개발자는 쓸데없이 바쁘다

한국의 개발자들은 항상 바쁘다. 소프트웨어 개발을 하느라고 바쁜 것이 아니라 쓸데없는 일에 바쁜 것이 문제다. 회사마다 차이는 있지만 많은 회사에서 개발자들은 본연의 개발 업무보다 불필요한 다른 일에 바빠서 정작 본연의 임무..

구멍가게 될텐가? 글로벌 SW기업 될텐가?

나는 소프트웨어 스타트업 및 중소기업 관계자를 자주 만난다. 주로 소프트웨어 개발이나 마케팅 전략에 대해서 얘기를 한다. 최근에도 몇몇 기업의 대표를 만났다. 대부분의 기업들은 국내 시장에만 머무르지 않고 해외로 진출해서 글..

나는 한달 동안 휴가를 갈 수 있을까?

내가 만약 한달 동안 휴가를 간다면 회사에서는 무슨 일이 벌어질까? 각자 한번 상상을 해보자. 내가 있던 없던 상관없이 회사는 잘 돌아갈까? 아니면 내가 관련된 일들이 진행되지 않아서 회사가 마비가 될까? 내가 없으면 회사가..

편한 개발환경이 가져온 부작용

필자는 개발자를 채용할 때 인터뷰 시 칠판을 이용한 코딩 테스트를 꼭 실시한다. 아무리 화려한 이력을 가지고 있다고 하더라도 코딩 테스트를 통과하지 못하면 채용하지 않는다. 코딩 테스트 문제는 정말 간단하다. 숫자를 문자로..

인원 늘면 꼬이는 SW개발문화의 현주소

꽤 오래 전 TV에서 혼자서 무인 자동차를 개발하고 있는 한 대학 교수의 이야기를 본 적이 있다. 20년째 혼자서 연구를 하고 있었고 조금씩 개량해서 그 당시 한적한 국도를 혼자서 달릴 수 있는 수준이었지만 복잡한 도로에서는..