블로그 이미지
소프트웨어 개발 경험을 공유하고 싶은 재밌게 사는 소프트웨어 엔지니어입니다^^

카테고리

Chungha Story (45)
Agile Experience (22)
My Family (4)
Life Style (8)
Programming (8)
Android (2)
Total165,664
Today7
Yesterday21

어느날 아침에 한 영업실의 실장님과 간단한 대화를 나누었다. 그때 실장님은 귀에 거슬리는 말씀을 하셨다.
맨날 구조 바꾸고 갈아 엎는다고만 하지 말고 생각 좀 해서 개발해봐! 버그만 심지 말고..
이전에(애자일 마인드를 갖기 전) 이 말씀을 들었다면 매우 부정적으로 "니가 개발을 알아?" 라고 마음속으로 콧방귀를 꼈을 것이다. 하지만 오늘 나는 개발자로써 반성문을 써보고 무엇이 문제인지 밝혀보고자 한다.

영업부서와 개발부서와의 미팅에서 개발자들이 시간적으로나 기능적으로 불합리한 요구사항에 대처하는 핑계중에 하나는 아마 다음과 같을 것이다.
현재 우리 구조에는 적용하기 어렵습니다. 적용하더라도 시간이 걸릴것 같으며, 추후에는 전체적으로 뒤집어 엎어야 합니다.
실제로 내가 다니고 있는 회사의 모습만 봐도 구조 및 설계 개선 등의 이유로 전체 시스템 소스코드를 뒤집어 엎는 경우(전역 리팩토링)가 매우 많다. 우리팀도 작년부터 이전 플래폼을 개선한다는 이유로 2.0이라는 이름을 달고 1년이 넘게 팀의 리소스 중 많은 부분을 플래폼 구조 개선 작업에 투입하였다.

문제는 이러한 작업의 결과가 비지니스적인 가치로 창출되는 경우는 매우 드물다는 것이다. 오히려 새로운 소스코드에 대한 검증 및 안정화 작업으로 인한 업무 오버헤드가 더 증가할 수 있다. 물론 추후 생길수 있는 요구사항을 손쉽게 적용할 수 있을 수도 있다. 그러나 이것은 XP를 인용해보자면 쓸데없는 짓이다. "사용자 스토리"라는 책을 보면 스토리(요구사항)는 투자되는 리소스 대비 비지니스적인 가치가 높은 것의 우선순위를 높게 책정하도록 권장하고 있다. 지금 현재 다른 업무가 거의 없지 않은 이상 전체를 뒤집어 엎는 스토리의 우선순위는 높아질 수 없는것이 자명하다.

그렇다면, 무엇이 문제일까? 개발을 잘 못한 개발자들만의 잘못일까? 이와 같은 일이 벌어지는 이유를 내 경험을 통해 정리해 보겠다. (현재 재직중인 회사만의 현상일 수 있으나, 한국의 개발회사는 크게 차이 없을 것으로 생각된다.)
  1. 개발자마다 "개발완료"의 의미가 다르다.
    어떤 개발자는 코딩 및 컴파일 완료를 개발 완료라고 생각한다.
    어떤 개발자는 기능 테스트(화이트 박스 테스트) 완료를 개발 완료라고 생각한다.
    어떤 개발자는 리팩토링까지 완료해야 개발 완료라고 생각한다.
    불행히도 많은 경우에 두번째의 경우를 개발 완료라고 생각한다.
  2. 개발 기간이 너무 촉박하다.
    영업부서에서 전달하는 요구사항 대비 주어지는 개발 기간이 매우 적은 경우가 많다.
    이럴 경우 핵심적인 기능(비지니스적인 가치가 높은)을 선별적으로 개발해야 하나, 대부분의 협의는 모든 기능 구현으로 종결된다.
    즉, 개발자는 기능 구현에만 집착하게 되며, 리팩토링은 신경쓸 수 없게 된다.
  3. 과도한 업무로 보상 심리가 강해진다.
    개발양은 많고 개발 기간이 촉박해지면, 잦은 야근, 밤샘 작업 및 주말 작업은 일상생활이 된다.
    이로 인해, 프로젝트가 일단락 되어 여유 시간이 생기더라도 보상 심리로 인해 리팩토링 작업은 미뤄지게 된다.
  4. 리팩토링에 대한 교육이 없다.
    리팩토링 뿐만이 아니겠지만, 리팩토링을 강조하고 무엇을, 어떻게 해야하지는 알려주지 않는다.
  5. 깨진 자동차 유리 
    "실용주의 프로그래머"라는 책에 소개된 깨진 자동차 유리 실험처럼, 지속적인 리팩토링이 이루어지지 않은 코드의 중복성은 기하 급수적으로 증가하게 된다.

이유를 적다보니 개발자의 책임이 큰것을 알 수 있었다ㅠㅠ. 
물론 영업부서의 유연하지 못한 요구사항도 큰 문제이다.

나의 결론은 간단하다. 목표는 전체적으로 뒤집어 엎어야 하는 경우를 줄이는 것이다. 
다음과 같은 원칙을 가지고 개발한다면 어느정도 도움이 될 것이다.
  • 항상 중복을 제거한다. [리팩토링]
  • 코딩 전에 테스트를 작성한다. [TDD , 어렵다면 어떻게 테스트를 할지 미리 결정해야 한다.]
  • 설계와 구현은 동시에 진행한다. [XP, 점진적인 설계]
  • 코드 공유 및 리뷰를 수행한다. [XP, Pair Programming]

하지만, 시간이 촉박한 프로젝트의 경우에 해답을 찾기란 쉽지 않다.
결국은 영업 부서와 개발 부서가 한팀이 되어 긴밀한 협업을 하는 것이 중요한 관건이다.
협업이 원활이 이루어 진다면 영업 부서는 비지니스 적인 가치를 극대화 할수 있으며, 개발팀은 핵심 기능에 집중하여 더욱 신뢰성 높일 수 있을 것이다. 고객과의 협업까지 이루어 진다면 금상첨화가 아닐수 없다.
영업 부서와의 협업 방법으로 사용자 스토리스크럼을 추천한다.^^

사용자 스토리와 스크럼에 대한 내용은 다음 책을 참고하면 좋다.
사용자 스토리
고객 중심의 요구사항 기법
마이크 콘, 심우곤 역
인사이트
스크럼과 XP
애자일 최전선에서 일군 성공 무용담
헨릭 크닉버그
인사이트
Posted by 윤청하

댓글을 달아 주세요

  1. 2009.11.05 14:09 신고 윤청하  댓글주소  수정/삭제  댓글쓰기

    스스로 피드백~ (아무도 안줘서..ㅋㅋ)
    거의 동일한 기능을 가지는 새로운 제품을 만들때(설계/구조 개선등의 목적) 생기는 또하나의 단점은
    만약 새로운 제품이 기 제품이 납품된 싸이트에 적용(migration) 될 수 없다면 개발팀으로써는 거의 동일한 두가지 제품을 follow-up 및 유지보수 해야 하는 것이다. 이는 혹떼러 갔다가 혹 더붙이는 꼴이 될 수 있다.
    (특히 상용에서 정상적으로 서비스 중인 제품을 검증되지 않은 새 제품으로 migration 하는 작업을 달가워할 고객은 별로 없을 것이다. - 설득의 문제)

  2. 2009.11.05 14:11 신고 윤청하  댓글주소  수정/삭제  댓글쓰기

    최근 옆팀에서 기존 제품에서 설계/구조 개선을 목적으로 새로 제품을 개발하는 작업을 시작하였다.
    이 팀의 경우 신규 팀원들의 능력 및 업무 만족도 향상이 이 작업의 목적중 하나라고 하였다.
    새로 만드는 것만이 교육적으로 의미가 있고 업무 만족도를 향상 시킬수 있다는 것은 생각해 볼 문제이다.^^

  3. 2009.11.12 18:01 신고 neokido  댓글주소  수정/삭제  댓글쓰기

    좋은 내용 참 잘 읽었습니다. ^^

    제가 TDD와 리팩토링 관련 컨퍼런스에 갔었는데. 그때는 초창기라 TDD와 리팩토링에 대한 관심이 대단했던것 같습니다. 그런데 거기 발표자의 발표 내용에서 제가 느낀것은 그 발표자가 말하는 TDD와 리팩토링의 목표가 정확히 무엇인지 알수 없는 말들을 늘어놓았다는 것입니다. (그분은 그냥 TDD를 이용하고, 이렇게 리팩토링을 하면 소스가 이렇게 짧아지고, .. 틈만나면 리팩토링을 해서 좀더 멋지게 잘 돌아가는 코드를 만든다.. 어쩌고.. 저쩌고..)

    과연 TDD와 리팩토링의 목적은 무엇인가? 에 대한 나름대로의 답을 가지고 있을거라 생각합니다.
    하지만 그 나름대로의 생각이, 회사의 이익으로 나타나지 않는다면 그것은 의미가 없을것입니다.

    단지 개발자 자신이 좋아서 하는 리팩토링,
    내가 만든 코드가 상당히 간결하니 내것을 쓰는게 좋을꺼야.. 자 ~ 써.~..
    남들이 TDD랑 리팩토링은 좋은 것이고, 꼭 해야한다고 생각해서
    기타 등등..

    이런 생각의 개발은 프로젝트중에서 또하나의 구멍을 뚫어서 자원을 낭비하는 거나 다름 없는 것이라 생각합니다.
    이제는 개발자가, 사용자와 니즈에 대한 적극적인 자세와 마인드로 개발을 해야할 시대인듯 합니다.
    좀더 Business적인 관점의 개발 마인드를 가지고, 그러한 Business needs 를 구현하기 위해서, TDD나 리팩토링은 좀더 Agile하게 개발을 쉽고, 명확하게 할수 있는 아주 좋은 툴이 될것같네요.

    님의 항상 연구하고, 적용하고자 하는 모습에 저도 다시한번 자극을 받게 되네요 ^^

    자주와서 좋은정보 공유하고 싶습니다. ^^

    • 2009.11.13 10:40 신고 윤청하  댓글주소  수정/삭제

      크나큰 관심과 엄청난 피드백 감사드립니다.^----^
      저는 고객의 비즈니스 가치는 개발자에게 매우 큰 동기 부여라고 생각합니다. 개발자는 자신이 개발하는 기능이 고객의 어떤 환경에서 어떻게 동작하고 어떤 이로움을 주는지 명확하게 알아야 한다고 생각합니다.
      그래서 저는 개발자의 시야가 좀더 넓어질수 있는 '기능개발팀' 혹은 '교차기능팀'을 구성하는 것을 회사에 제안하고 싶지만..
      아쉽게도 아직은 어렵네요.. 기술적 배경으로 성장한 회사라 그런지 기술적 성장에 더 관심이 많은것 같습니다.^^

      TDD는 고객에게 꼭 필요한 기능들을 명확하게 개발하고 품질을 보장할 수 있는 좋은 방법중에 하나라고 생각합니다.~

      다시한번 좋은 말씀 감사드리구요~ 피드백은 언제나 환영입니다.^^

  4. 2010.04.21 11:01 신고 ryoo  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다..
    영업부와 항상 피해의식만 생겼었는데 이 글을 보니 개발자도 달라져야겠다는 생각이 드네요.
    개발자의 책임이 큰만큼 먼저 반성하고 주도적으로 이끌수 있는 프로젝트를 역량을 갖춰야겠습니다.