태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

 

 

 

 
분류 전체.. (1308)
마이크로소.. (132)
민수네 가족 (17)
호랭이 사.. (141)
열이아빠의.. (7)
PlayPhone (98)
NetworkON (1)
ratharn의.. (10)
큐브 해법 (10)
사람들 (6)
개발 이야기 (94)
아이티 이.. (539)
영어 이야기 (2)
좋은책 이.. (8)
대기중인.. (1)
발명 이야기 (2)
건강하게.. (15)
마소  마이크로소프트  구글  블로그  호랭이  아이폰  LG전자  삼성전자  개발자  마이크로소프트웨어 
 free offers
└>free offers
 online pharma..
└>online pharma..
 Go here
└>Go here
 visit my webp..
└>visit my webp..
 Go Source
└>Go Source
«   2018/11   »
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
+ ITViewpoint
+ 도이모이
+ with okgosu
+ 학주니닷컴
+ 열이아빠의 RI..
+ Gsong.s Blog
+ 비주얼스튜디..
+ 광파리의 글로..
+ LovedWeb
+ 블루오션의 터..
+ 울지 않는 벌새
+ PC 지존
+ 디지털통
+ 아크비스타
+ 고독한 프로그..
+ Total : 2,081,747
+ Today : 5
+ Yesterday : 19
  

 

 

 

방법론 _해당되는 글 3건
2010.01.19   소프트웨어 개발 생산성 팍팍 올리기 
2009.11.27   소프트웨어 개발 방법론의 함정 
2009.10.07   스크럼(Scrum) 기반의 프로젝트 관리 

 

소프트웨어 개발 생산성 팍팍 올리기
+   [마이크로소프트웨어]   |  2010.01.19 05:51  


모든 일에는 몇 가지 법칙이 있습니다. 사장으로서 할 말은 아니지만 뭐 대략 정리해 보면 이렇습니다. "열심히 일한다고 월급 빨리 오르는 거 아니다" "무슨 일이든 입사할 때의 연봉이 중요하다(암만 시간 지나봐라 두 배, 세 배는 꿈도 꾸지마라. 회사는 늘 어렵고 심지어 시간이 지날 수록 연봉이 줄어들 수도 있다)" 그리고 마지막으로 아주아주 중요한 법칙이 바로 "일은 처리하는 속도보다 쌓이는 속도가 훨씬 빠르다"입니다.

그게 가장 큰 핵심 포인트입니다!

출처: 덧글짤방 - Google 이미지

그것 참 희안한 일입니다. 아무리 바지런을 떨어도 도무지 이놈의 일은 추리해 내는 것보다 쌓이는 게 점점 더 많아지니 말입니다.

돈이 이렇게 쓰는 속도보다 쌓이는 속도가 훨씬 빠르다면 차암 행복하겠지만, 현실에선 희안하게도 일만 죽어라 쌓입니다.

이건 소프트웨어 개발에서도 예외가 아닌데요.

소프트웨어의 개발 생산성을 높이기 위해 필요한 주요 포인트들을 다룬 기고 내용이 있어 옮겨봅니다.

이 글을 읽는 분이 개발자가 아니라면 또 나름 자신의 상황에 맞춰 이해하시면 업무를 효과적으로 처리하는데 도움이 될 듯합니다.


생산성 높은 소프트웨어 개발

제조업의 경우 생산 현장의 생산성을 높이기 위해 인력을 추가하고 생산시설을 확충하면 그 만큼의 생산성은 향상된다. 그러나 소프트웨어 개발에서는 개발 지연이 되어 개발자를 더 투입하면 개발 일정이 더 길어져 소프트웨어 인력 충원에 따른 생산성 향상을 기대하기 힘들다. 그 이유는 결과물인 소프트웨어는 개발자의 지적 활동이 많은 부분을 차지하기 때문이다. 그러므로 프로세스를 통해 통제해 보려고 하지만 쉽게 통제되지 않는다. 생산성 향상을 위해 통제가 아닌 소프트웨어 개발에 필요한 몇 가지 중요한 점을 이야기해 보고자 한다.

김성 sung21.kim@samsung.com|삼성소프트웨어멤버십 회원으로 활동한 바 있고, 현재는 삼성전자에서 근무하고 있다.  Enterprise Architecture 개발과 관련된 실무 경험을 갖고 있으며 소프트웨어 공학 분야에 관심이 많다.

팀을 만들 때 자신의 의견을 강하게 주장하는 유능한 팀원으로만 구성된 팀과 유능하지는 않지만 경청하고 소통하는 팀원만으로 구성된 팀 중 어느 팀이 프로젝트를 성공할 확률이 높을까?

의사소통

정답은 후자이다. 전자의 경우 팀원 개개인의 능력은 우수하지만 서로 자신의 의견을 굽히지 않고 협업하지 않아 팀원 간의 불협화음이 일어나고 결국 의사소통 단절로 이어진다.

자신들의 의견이 의사결정에 반영될 수 있도록 자신의 목소리를 높이다 보니 의사결정이 되지 않고 계속 지연되는 일이 발생하고 의사 결정에 자신의 의견이 반영되지 않으면 팀에 대한 부정적인 입장으로 프로젝트에 참여하게 된다.

후자의 경우는 문제에 대해 서로 협의하고 해결점을 찾는 과정에서 의사결정이 이뤄지며, 이 과정에서 서로의 신뢰와 업무능력 향상이 함께 이뤄진다.

서로의 의견에 대해 계속적인 피드백을 서로에게 주며 모든 팀원이 공감하고 합의하는 결과에 도달해 서로간의 관계는 더욱 두터워져 의사소통이 원활하게 이뤄진다.

그러므로 결과에 대해 누구도 불만을 품지 않으며 모두 적극적인 자세로 프로젝트에 임하게 된다. 이처럼 프로젝트의 성패는 개개인의 능력이 아니라 원활한 의사소통을 통한 협업에 있음을 기억해야 한다.

정확한 의사소통이 이뤄지지 않으면 Integration되는 소프트웨어의 많은 부분에서 오류가 발생하고 이를 해결하기 위해 많은 시간이 소요된다.

이는 다시 말해 의사소통의 중요성을 의미하지만 다른 각도에서 생각해보면 의사소통에 어려움 있다는 의미다.

의사소통의 어려움을 줄이기 위해 최대한 개발하는 모듈에 대한 연관성을 줄인다면 생산성을 더 높일 수 있을 것이다.

소프트웨어 설계 시 Feature 단위의 정의로 소프트웨어 모듈간의 의존성을 낮추고 계층구조의 소프트웨어를 만들어 최소한의 인터페이스 규약만을 정확히 정의한다면 의사소통의 불협화음을 최소화할 수 있을 것이다.

코드 리뷰

Pair 프로그래밍을 해본 경험이 있는가?

Pair 프로그래밍은 하나의 모니터 앞에 두 사람이 앉아 한 사람은 코드를 작성하고 한 사람은 코드를 보면서 함께 고민하는 방식으로 이뤄진다.

장기에서 훈수를 할 때 장기판의 말이 잘 보이는 것과 같이 코드를 지켜보는 사람은 코딩하는 사람의 오류를 잘 찾아낼 수 있다는 장점이 있고 자동적으로 백업된다.

그래서 처음에는 두 사람이 하나의 작업을 같이 하므로 생산성이 떨어지는 것 같이 느끼지만 품질 향상을 통해 프로젝트 후반부에서는 생산성이 좋아진다.

그러나 효율적인 Pair 프로그래밍을 하기 위해서는 몇 가지 조건이 만족되어야 한다.

첫째, 작업을 함께 할 수 있는 시간적, 환경적 배려가 필요하다.

개발자는 현재 프로젝트의 개발만을 하지 않는다.

자신에게 할당된 여러 가지 업무가 있으며, 그 업무를 모두 처리하기 위해 자신만의 스케줄로 업무를 진행해 나간다. 개인이 맡은 업무가 서로 상이하고 공통된 업무의 범위가 작으면 서로 만날 수 있는 시간조차 없다.

그리고 좁은 작업 공간에서 그리고 작은 모니터에서 두 사람이 앉아서 개발하는 것도 함께 개발하는 것을 힘들게 한다.

미국 유타대에서 문서 편집 등의 작업을 할 때 모니터 크기가 바뀌면 생산성이 어떻게 달라지는지 측정하는 연구를 했다.

24인치 모니터를 쓰는 사람이 18인치 모니터를 쓰는 사람보다 52% 빠르게 작업을 끝마쳤고, 20인치 듀얼 모니터를 쓰는 사람이 18인치 모니터 한 개만을 쓰는 사람보다 44% 빠르게 업무를 끝냈다고 한다.

이러한 연구 결과와 같이 개발환경 문제는 생산성에 영향을 주므로 생산성을 높일 수 있는 환경을 마련하는 것 또한 중요한 일중의 하나이다.

둘째, 서로 친해야 한다. 개발자는 자신의 코드에 대해 제3자가 비판하는 것을 아주 싫어한다.

그러므로 함께 일하는 사람이 친해서 소스 코드의 잘못된 점 등을 부담 없이 이야기할 수 있고 받아들일 수 있어야 한다.

그렇지 않아도 보기 싫은데 같이 앉아서 작업하라고 한다면 서로 입을 다물고 아무런 대화가 없어 함께 작업하는 의미가 사라진다.

셋째, 개인의 능력 차를 고려해야 한다.

개인의 능력 차가 너무 많이 나면 능력이 낮은 사람은 무조건 배우는 자세로 임하게 되고 어떠한 지적이나 조언을 할 수 없게 된다.

넷째, 개발 인력이 충분해야 한다. 프로젝트가 작아 개발자가 한 두 명이 개발하는 소프트웨어도 많다. 그럴 경우는 Pair 프로그램이 불가능하다.

이러한 제약사항들이 있으니 현 상황을 잘 파악해 적용 유무를 결정해야 한다.

서로 백업되고 소프트웨어 품질을 향상시켜 생산성을 높인다는 목적을 달성하기 위해서는 코드 리뷰도 좋은 방법이다.

코드 리뷰를 통해 서로의 코드를 공유하고 선임자에 의해 코드의 잘못된 부분의 지적과 조언을 할 수 있어 소프트웨어 품질을 향상시킬 수 있다.

또한 다 작성된 코드로 코드 리뷰하는 것은 시간적으로도 많이 절약된다.

또한 혼자 개발하는 경우에도 자신이 작성한 코드를 직접 리뷰하는 방법으로 진행할 수 있으며 이 방법으로 자신이 작성한 코드의 오류를 미리 발견해 수정하는 것이 가능하다.

상황이 여의치 않아 Pair 프로그래밍을 할 수 없더라도 코드 리뷰를 한다면 충분히 생산성 향상을 가져올 수 있다.

교육

수행 능력은 개인에 따라 3배에서 10배까지 차이가 날 수 있다고 하듯이 소프트웨어 개발에서의 개인 생산성은 많은 차이를 보이고 있다.

그러나 이러한 수행능력을 판단하기가 어렵다는 게 문제이다.

그 결과, 정확한 수행능력치를 기준으로 일정에 반영하기가 어렵다.  

똑같은 일을 A라는 사람은 1시간 만에 해결하는데 반해 B라는 사람은 5시간이 걸려야 처리할 수 있다.

그렇다고 해서 A라는 사람이 무조건 수행능력이 낮다고 할 수는 없다.

각 사람마다 잘하는 분야가 있기 때문에 다른 일에 대해서는 더 나은 성과를 보일 수 있기 때문이다.

이러한 개개인의 능력을 잘 파악하고 적재적소에 인력을 잘 할당하는 것은 개인의 생산성을 최대한 높일 수 있는 방법이다.

그러기 위해서 개인의 능력을 향상시키기 위한 교육이 지속적으로 이뤄져서 교육을 통해 얻은 지식을 업무에 활용해 더욱 높은 성과를 얻도록 해야 한다.

그러나 교육도 무조건 진행하는 것이 아니라 개인마다의 업무에 필요한 전문 분야를 선택하도록 하고 전문 분야에 대한 지속적인 교육과 업무를 통해 전문가로 양성해 가야 한다.

방향 없는 교육은 단순히 자신의 지식을 늘릴 뿐 업무에 도움은 되지 않으며 시간이 지나면 모두 잊어버리게 된다.

업무의 테두리 안에서 전문 분야를 선정하고 전문 분야의 담당자에 대한 지속적인 교육이 이뤄질 때 개발자에 대한 생산성 향상으로 개발자와 기업 모두가 윈-윈 할 수 있다.

리더의 자세

팀을 이끌기 위해서는 리더의 역할이 무엇보다도 중요하다.

팀의 리더는 조직 구성원의 능력을 최대한 끌어 낼 수 있어야 한다.

지시나 통제가 아닌 조언하고 지원하는 자세로 팀을 이끌어야 한다.

지식사회가 되면서 이제는 수직적인 조직에서 수평적인 조직으로 되어가고 있다.

이는 업무가 전문화되어 감에 따라 업무담당자가 맡은 일에 대해 가장 많이 알고 잘 할 수 있기 때문이다.

이는 점점 지시와 통제를 통해 조직을 이끌어 가기 힘들다는 뜻이 된다.

이제 진정한 리더는 지시와 통제로 팀을 이끄는 것이 아니라 mento와 Supporter로서 조언하고 지원하는 자세로 바뀌어야 할 것이다.

그러나 아직 수직적인 조직체계 뿐만 아니라 강한 리더십을 위해 더욱 강한 지시와 통제를 가하는 경향이 있고, 그렇다고 개발자가 쉽게 지시와 통제에 따르지도 않는다.

그러므로 개발자에게 책임과 권한을 적절하게 부여함으로써 개발자의 주인의식을 높여 능동적 자세를 이끌어 내는 것이 더 중요하다.

또한 리더는 비전 제시자가 되어야 한다. 무조건 ‘나를 따르라’는 시대는 지났다.

팀원에게 정확한 비전을 제시하고 비전을 공유해 그 비전이 팀원 개개인에 맞을 수 있도록 조정하며 비전을 향해 한 방향으로 힘이 결집될 수 있도록 해야 할 것이다.

비전을 공유하고, 비전을 바라보고, 팀이 한 방향으로 한 몸같이 움직일 때 진정한 팀의 파워가 생겨나게 된다.

또한 중요한 것 중의 하나는 경청이다. 담당자는 해당 업무에 관해 많은 고민을 하고 시행착오를 겪으면서 많은 것을 경험하며 현장의 소리를 가장 가까이에서 들을 수 있다.

그래서 그 의견은 보석보다도 더 귀히 여겨져야 하지만 의사결정자는 자신의 의견과 맞지 않을 때 바로 무시하게 된다.

반복적으로 의견이 무시되면 팀원은 수동적인 태도로 바뀌게 되고, 결국에는 개선과 혁신에 대한 생각도 행동도 하지 않게 된다.

팀원이 마음껏 생각하고 마음껏 뛰어 놀 수 있게 만들어 주는 것이 진정한 리더의 임무가 아닐까 생각해 본다.

재사용

소프트웨어의 생산성과 품질을 향상시키기 위해 모듈화, 유연하고 확장 가능한 구조로 개발하려는 노력이 계속되어 왔으며, 최근에는 소프트웨어 재사용을 위한 노력 또한 활발하게 진행되고 있다.

소프트웨어 재사용은 최종 산출물에 대한 재사용이므로 요구사항 분석에서부터 테스트에 이르기까지 모든 결과물에 대한 재사용을 의미한다.

모든 결과물에 대한 재사용은 생산성 및 품질 향상에 많은 영향을 미치게 된다. 재사용 가능 컴포넌트와 변경 가능 컴포넌트를 분류해 설계하고, 아울러 추가나 수정에 의해 최소한의 영향만을 받도록 컴포넌트를 설계해야 한다.

보통 재사용을 위해 자신이 필요한 소스 코드를 이른바 ‘Copy & Paste’해서 다시 사용하는데, 이를 재사용이라고 보기에는 무리가 있다.

‘Copy & Paste’는 단순 일부 소스만을 재사용할 뿐이고 추가되는 소스에 맞게 수정이 이뤄지는 경우가 많다. 그러므로 요구사항 분석부터 테스트에 이르는 모든 결과물에 대한 재사용이 될 수 없다.

소프트웨어에서 공통적으로 많이 사용되는 부분이 재사용되는 대상이 된다.

그러므로 재사용하기 위해 모듈화하게 되는데, 모듈화는 공통적으로 사용하는 모듈과 시스템에 가변적으로 사용하는 부분으로 나눠 정의해야 한다.

공통적으로 사용하는 모듈의 경우는 사용자의 요구사항 변화에 많은 영향을 받지 않으므로 재사용 대상으로 선정해 모듈화하고 재사용할 수 있도록 한다.

데이터를 송신하고 수신하는 기능을 재사용하겠다고 해서 Sender와 Receiver 모듈을 재사용한다면 Sender와 Receiver는 다른 모듈과의 의존성을 가질 수 있으며, 이에 대한 정보를 알아야 사용이 가능하게 된다.

따라서 이러한 의존성이 관리되어야 하므로 오픈되어야 한다. 그러나 이를 하나의 프레임워크 단위로 만들고 재사용한다면 이러한 의존성을 사용하는 측에서는 고려할 필요가 없으므로 더욱 추상화시킬 수 있다.

모듈화된 컴포넌트를 다른 연동 시스템에서 사용한다면 소프트웨어 재사용으로 인해 개발시간을 단축시킬 뿐만 아니라 재사용하는 코드는 재사용 컴포넌트가 갖는 품질의 수준을 그대로 얻을 수 있게 된다.

소프트웨어 재사용은 소프트웨어를 조립 가능하게 하는 것이다. 메인 프레임워크를 만들고 메인 프레임워크에 추가되는 기능을 소스의 수정 없이 플러그인 형태로 꼽아서 쓸 수 있도록 설계되고 개발되어야 한다. 메일 프레임워크에 기능이 추가될 때마다 기능 단위 모듈을 꼽아 Integration되어야 하는데, Integration은 configuration file 내에 명령과 호출되어야 할 컴포넌트의 매핑을 통해 가능하다.

재사용되는 모듈은 내부 또는 외부에서 활용 가능하므로 재사용 모듈에 대한 정확한 설명과 인터페이스 정의가 필요하며 이에 대한 매뉴얼이 필요하다. 재사용 모듈을 효율적으로 관리하기 위해서는 모든 구성원이 공유할 수 있는 저장소를 만들어 재사용 모듈에 대한 정보와 함께 관리하고 쉽게 검색해 사용할 수 있도록 하는 것 또한 중요하다

Complexity

소프트웨어 복잡성(Complexity)을 갖게 하는 것에는 무엇이 있을까?

Complexity는 다양한 각도에서 생각해 볼 수 있다. 소프트웨어의 복잡성이 높아지면 개발 단계뿐만 아니라 유지보수 단계에서 많은 비효율성을 갖게 된다. 소프트웨어 복잡성을 높이는 이유로 다음 몇 가지를 들 수 있다.

첫째, 조건문의 증가이다. 조건에 따른 서로 다른 처리를 위해 조건문을 사용한다.

처음에는 한 두가지 조건에서 시작한다. 그러나 시간이 갈수록 기능이 추가되고, 그에 따른 조건문도 추가된다.

조건의 항목이 추가되면서 계속적으로 추가하다 보면 어느새 조건문이 많아진다.  이는 소프트웨어의 복잡성을 높이는 것이며, 이로 인해 시스템의 성능을 떨어뜨리는 원인이 된다.

계속해서 추가할 수밖에 없다고 생각할 수 있지만 이는 분명 여러 개의 조건문으로 분리할 수 있다.

불필요한 조건문을 최소화하고 분리해 간단한 구조를 만들어야 한다.

한 클래스 안에 수많은 조건문의 반복을 없애야 한다. 하나의 모듈 내에 조건문이 많다는 것은 모듈 안에 서로 분리 가능한 기능이 함께 있을 가능성이 높다는 것이고, 이는 기능 분리를 통해 모듈로 분리한다면 자연스럽게 조건문이 분리된다.

소프트웨어 개발 중 반복적인 추가와 변경을 통해 모듈이 비대해지고 복잡해지면서 여러 기능이 혼합되고 추가되어 조건문이 많아지고 복잡해진다. 기능별 모듈을 적정하게 분리해 가면서 추가해 나간다면 소프트웨어 복잡성이 높아지는 일은 미리 막을 수 있다.

둘째, depth의 증가 및 역 참조 구조이다.

오래전 소프트웨어 개발 시 한 시대를 풍미했던 GOTO 문을 기억하는가?

GOTO 문의 편리함으로 많이 사용되었지만 GOTO 문의 사용이 많을 경우 호출이 복잡해져서 소스의 복잡성이 가중된다는 큰 단점이 있었으며, 이로 인해 GOTO 문은 사라진 지 오래이다.

소프트웨어의 소스 코드는 프레임워크에서 지원하는 함수와 개발자 자신이 필요에 의해 만든 수많은 함수를 호출하는 코드로 이뤄져 있다.

소프트웨어의 call depth가 증가한다는 것은 호출된 함수에서 또 다시 다른 함수로, 그리고 또 다시 다른 함수로 계속적으로 호출하는 것을 의미한다.

이러한 복잡한 호출은 GOTO 문을 쓰는 것과 다를 바 없다. 소스 코드 분석을 위해 추적해 보면 느끼겠지만 이렇게 되면 상당히 복잡하고 소스를 읽기 어렵게 된다.

또한 단위 테스트 시에도 오류가 어느 지점에서 발생했는지 확인하기 어려우며, 확인을 위해서는 호출되는 마지막 함수부터 추적해야만 문제를 찾을 수 있게 된다. 이렇듯 call depth의 증가는 소스를 복잡하게 해 읽기 어렵게 할 뿐만 아니라 테스트 코드를 만들기 힘들며 디버깅도 힘들게 한다.

소프트웨어 계층별로 Layer를 나누어 개발하는 Layered Architecture는 계층 간의 의존성을 최소화해 변경에 유연하게 대응하고자 하는 목적이 있다. 계층에서의 참조는 같은 계층 간 또는 하위 계층으로의 참조로만 이뤄져야 한다. I3에서 M2를 참조하는 것과 같이 하위 계층에서 상위 계층으로의 역참조가 일어나서는 안 된다. I2에서 I3으로 같은 계층에서의 참조는 문제가 되지 않는다.

상위 계층으로 갈수록 추가 및 변경이 자주 일어나며 하위 계층은 다른 모듈에 의해 여러 참조를 갖기 때문이다. 역참조가 일어날 경우 상위 계층이 바뀌면 역 참조를 한 하위 계층이 바뀌게 되며 이를 참조한 다른 계층의 모듈까지 연쇄적으로 변경되어야 한다. 이는 유연성을 떨어뜨리며 복잡성을 가중시킨다.

셋째, Unused 코드 증가이다. 개발된 코드를 받고 분석했던 경험이 다 있을 것이다. 코드를 보다 보면 이걸 사용하는지 사용하지 않는지 모를 때가 많다. 심지어는 자신이 작성한 코드 또한 사용하는지 사용하지 않는지 모를 때가 많다. 코드를 한참 따라가며 분석하다 보면 어느 순간 사용하지 않는 코드임을 알게 된다. 그래서 사용하지 않는 소스로 인해 많은 복잡함을 느낄 수 있다. 개발하면서 사용하지 않는 코드가 있더라고 왠지 지우면 무슨 일이 벌어질 것 같고, 다음에 또 사용할 수도 있을 것 같으며 ‘굳이 지울 필요가 있을까’라는 이유로 사용하지 않는 코드를 그대로 방치하게 된다. 이렇게 사용하지 않는 코드는 레거시 코드를 분석하다 보면 상당히 많은 것을 확인할 수 있다. 사용하지 않는 코드를 방치해 소프트웨어의 복잡성을 높이지 말고 사용하지 않는 코드는 과감히 삭제한다든지 전체를 주석 처리해 사용하지 않는다는 것을 확실히 표시함으로써 소프트웨어 복잡성을 낮출 수 있다. 코드 분석 툴을 사용해 사용하지 않는 코드를 주기적으로 분석하고 관리해 Unused 코드의 비율을 낮추어야 한다.

넷째, 소스의 크기와 소스간의 의존성이다. 소스의 크기가 작을수록 단순해 보일 뿐 아니라 유연성이 높고 변경하기 쉬워진다. 소스의 크기가 크면 복잡해 보이는 것이 사실이다. 그러나 소스 크기만을 가지고 복잡성이 높고 낮음을 얘기할 수는 없다. 소스의 크기가 작더라도 소스간의 의존성이 높다면 하나의 기능을 추가하거나 변경하는 것이 여러 개의 소스에 걸쳐 영향을 주어 추적해가며 수정이나 변경이 이뤄진다. 그리고 패키징과 릴리즈하는 컴포넌트의 수가 많아져 이 또한 복잡성을 가중시키게 된다. 소스의 크기가 크더라도 의존성을 갖지 않고 내부적으로 잘 분리되어 있다면 수정이나 변경이 용이할 수 있고 패키징과 릴리즈를 할 때 하나의 컴포넌트만 하면 되므로 복잡성이 줄어들게 된다. 소스 크기를 무조건 줄이려고 하는 것이 아니라 소스간의 의존성을 최대한 줄이면서 소스의 크기를 줄여나갈 때 복잡성을 낮출 수 있게 된다.

다섯째, 예상하지 않은 코드의 증가이다. 예상하지 않은 기능의 추가와 예상하지 않은 기능의 변경은 기존 설계 및 구현된 소스에 변경을 가져온다. 예상치 않은 요구사항을 반영하기 위해 소프트웨어 변경이 불가피하게 되고, 이러한 상황에서는 일정 또한 급박하게 돌아간다.  그렇게 되면 다급해진 개발자는 기존 소스에 끼워 넣기 식으로 개발을 진행하게 된다.  Feature별로 구분해 개발했는데 적합한 Feature도 없으니 아무 것이나 적당한 Feature를 선택해 추가하기 시작한다. 이렇게 추가된 소스는 기존의 잘 정리된 소스를 복잡하게 만들게 된다. 소프트웨어를 설계하는 데 있어서 모듈을 나누고 소프트웨어 의존성을 낮추는 등의 설계는 변화에 유연하게 대응할 수 있어 수정 시 드는 비용을 낮추기 위한 방안이지 실제적으로 변화에 대응하기 위한 방법은 아니다. 변화에 대응하기 위해서는 요구사항의 변화 시 소프트웨어 수정의 최소화에 초점이 맞춰져야 하고 변경 가능성 있는 부분을 미리 고려해 소스 수정을 최소화하면서 확장 가능해야 한다.

그럼 소프트웨어 변경 유형에는 무엇이 있을까? 기능의 추가, 기능의 삭제, 기능의 변경, 설계 미흡이 있는데, 기능의 추가나 삭제는 기존의 소스 구조의 변경 없이 가능하지만 기능의 변경은 많은 문제를 유발한다. 그리고 기능의 추가가 독립된 기능 추가가 아닌 기존의 기능에 더해지는 경우에 문제가 될 수 있다.

기능의 변경과 기존 기능에 기능이 더해지는 경우의 예는 처리 로직의 Rule을 변경하는 것에서 많이 찾아볼 수 있다. 이러한 Rule의 변화가 소프트웨어 변경의 원인이 되므로 요구사항 분석 및 설계 시점에 Rule에 대한 정확한 정의가 필요하고 Rule의 변경이 발생하더라도 쉽게 소스 코드를 변경하거나 변경을 수용할 수 있는 구조로 만들어야 한다. 그럼 Rule의 변경은 왜 발생하는 것일까? Rule은 요구사항으로부터 나오고 요구사항으로부터 변경되는 만큼 요구사항 분석 시 충분한 리뷰를 통해 요구사항이 정확하게 반영된 Rule을 정의하고 이해당사자 모두와 공유해야 한다.

참고자료
1. Addison Wesley, UML Distilled Third Edition, 2003
2. Addison Wesley, Designing Software Product Lines With UML, 2004
3. WILEY, Architecting Enterprise Solutions, 2004
4. 영진닷컴, 객체지향 CBD 개발 방법론, 2004
5. 위키북스, 똑똑하고 100배 일 잘하는 개발자 모시기, 2007
6. 인사이트, 익스트림 프로그래밍 2판, 2006





     개발, 개발자, 노하우, 방법론, 블로그, 생산성, 소프트웨어
     1   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

소프트웨어 개발 방법론의 함정
+   [마이크로소프트웨어]   |  2009.11.27 10:36  


소프트웨어 개발 프로젝트에서는 최신 유행하는 헤어스타일이나 옷을 입는다고 나 자신이 유명 연예인처럼 보일 수 없는 것 만큼이나 당연한 법칙이있다. 아무리 유명하고 좋다는 소프트웨어 개발 방법론을 적용해 보아도 성공적인 도입이나 효과를 보기가 어렵다는 사실이다. 그렇다면 개발 방법론따위는 신경쓰지 않는 편이 옳은걸까? 헤어 스타일이나 옷을 입는데에도 본인과 적당한 코디를 해야 자신을 돋보이게 할 수 있는 것처럼, 개발 방법론도 자신이나 팀의 상황에 맞춰 잘 코디하면 더욱 좋은 효과를 거둘 수 있는 건 아닐까? 여기 자신의 오랜 컨설팅 경험을 통해 쌓은 노하우를 한 큐에 알려주겠다는 이가있다. 개발 방법론의 도입과 적용에 대한 고민을 하고 있는 개발자들에게 도움이 되길 바란다.

아이마소 | www.imaso.co.kr

체계화된 프로세스와 산출물들로 무장한 개발방법론은 회사에 필요한 이상적인 무기를 제공해줄 것 같지만, 개발방법론을 도입해 크게 효과를 본 회사를 찾기는 쉽지 않다. 개발방법론이 개발을 더 지연시키고 개발자들을 번거롭고 힘들게 한다고 하기도 하고 개발방법론을 도입해서 사용하다가 포기하고 다른 방법들을 기웃거리기도 한다. 왜 이렇게 성공적으로 개발방법론을 도입하는 것이 어렵고, 개발방법론을 효과적으로 소프트웨어 개발에 적용하기 위해서는 어떻게 해야 하는지 알아보자.

전규현 gracegyu@gmail.com|데스크톱, 네트워크, 시큐리티 등 다양한 소프트웨어 개발 분야에서 15년 이상의 경험을 쌓았다. 한글과컴퓨터, 안철수연구소 등에서 소프트웨어엔지니어 및 프로젝트관리자로 지냈다. 현재는 소프트웨어 경영/개발 컨설턴트로서 많은 소프트웨어 회사들에게 소프트웨어의 효율적인 개발 방법을 전파하고 있다. 직접 운영하고 있는 소프트웨어 공학 블로그(http://allofsoftware.net)를 통해 효과적이고 실전적인 소프트웨어 공학 경험을 블로거들에게 공유하고 있으며, 저서로 『소프트웨어 개발의 모든 것(페가수스, 2008)』이 있다.

독자들 중에서도 개발방법론들을 경험해 본 사람들이 꽤 있을 것이다. 실제로 개발방법론을 경험해 봤다면 그 개발방법론이 실제 소프트웨어를 개발하는 데 얼마나 도움이 되었는지 묻고 싶다. 즉, 이전에 나름대로의 방법으로 알아서 개발하던 때와 비교하면 얼마나 나아졌는지 묻고 싶다. 진짜 개발이 더 빨라지고 생산성이 높아졌는지? 아니면 개발은 오히려 느려졌고 과거보다 번거로울 뿐이지만 그래도 문서를 남겨야 나중에 정보 공유가 가능하니까 따르는 것인지 묻고 싶다.
필자는 소프트웨어 개발 컨설턴트로서 여러 개발자들이 이러한 질문에 답변하는 내용을 들을 기회가 많다. 그 중에 개발방법론은 고객이 요구하기 때문에 어쩔 수 없이 적용한 경우가 많았고, 실제로 개발하는 데는 필요도 없는 문서를 많이 만들어야 했으며, 그로 인해 개발에 더 많은 시간이 소요되었다는 얘기를 종종 듣게 된다. 하지만 회사에서 시키기 때문에 억지로 하곤 한다고 말한다. 시중에 개발방법론은 넘쳐나는데 왜 개발방법론을 적용해 큰 효과를 봤고 개발 생산성이 크게 향상되었던 경험을 접하기가 어려운 것일까?

개발방법론은 필요하다

회사가 작을 때는 소프트웨어를 개발하는 데 있어서 대부분 확실한 개발 체계 없이 시작한다. 대부분의 경우 이렇게 주먹구구식으로 또는 가내수공업 형태로 소프트웨어 개발을 시작해도 별 문제가 없다. 체계가 없다는 것은 소프트웨어를 개발하는 데 문서를 제대로 만들지도 않고, 정형화된 프로세스 없이 개발자들의 경험에 의해 주먹구구식의 절차를 통해 별도의 개발 시스템 없이 순전히 개발자들의 기억력과 약간의 기록만 가지고 개발하는 것을 의미한다. 그렇게 개발하더라도 대부분 큰 문제에 봉착하지 않는다. 대부분의 정보라는 것도 그리 방대하지도 않아서 개발자들의 머릿속에 잘 저장되어 있고, 시스템도 그리 복잡하지 않아서 몇몇 소수의 개발자들이 머리를 맞대고 개발해도 별 문제가 없다. 또 충성심 가득한 개발자들은 회사에 언제까지나 있을 것 같고, 문제가 발생하면 특공대처럼 문제를 빠르게 해결한다.

이러한 시기에는 오히려 주먹구구 방식이 훨씬 빠르고 비용이 적게 든다고 생각할 수 있다. 실제로 이런 개발 방법이 여타 개발방법론을 적용한 개발 방법보다 효율이 더 높은 경우도 있다. 소수의 개발자에게 너무 많은 부분을 의존하고 있는 이런 방식은 장점인 것처럼 보이지만, 사실은 대단히 큰 위협요소가 된다.

성장하는 회사는 조직이나 소프트웨어의 규모가 점점 커지고, 개발해야 하는 제품의 수와 개발자는 점점 늘어가고, 더 이상 주먹구구식으로는 개발이 어려워진다. 회사는 점점 성장하는데 여전히 주먹구구식으로 개발하고 있다면 개발 과정은 점점 혼란스러워지고 설상가상으로 대부분의 정보를 머릿속에 담고 있는 개발자가 퇴사를 하기도 한다.

개발방법론은 이렇게 소수의 개발자에 편중되어 있는 대부분의 리스크를 시스템적으로 커버할 수 있도록 한다. 문서도 만들어야 하고, 프로세스도 따라야 하기 때문에 당장에는 기존의 주먹구구식의 방식보다는 시간도 많이 들어가고 비용도 많이 들어가는 것처럼 보이지만, 그 대가로 리스크를 줄일 수 있다.

모험심이 가득한 벤처 회사라면 얼마든지 리스크를 감수할 수 있겠지만, 회사가 점점 커지면 리스크보다는 비용을 선택하게 되어 있다. 따라서 주먹구구식으로 시작한 소프트웨어 회사라도 규모가 커지면 자연스럽게 개발방법론에 눈을 돌리게 된다.

이렇게 개발방법론을 시도해보기 위해 개발방법론 도입을 도와주는 컨설팅회사에 의뢰를 하기도 하지만, 대부분은 인터넷이나 책을 통해 개발방법론을 배워보려고 시도한다.

개발방법론을 공짜로 배울 수 있을까?

개발자들은 인터넷에서 수많은 소스 코드 샘플을 보고 개발에 활용해 왔듯이, 개발방법론도 인터넷에서 특정 개발방법론의 템플릿과 샘플 그리고 프로세스를 가져와서 따라하면 개발방법론을 그럴싸하게 흉내 낼 수 있을 것으로 생각하기도 한다. 하지만 실제로 따라해보면 생각만큼 잘 되지 않는 것이 사실이다. 일단 기존에 주먹구구식으로 개발하던 개발자들은 개발방법론에서 제시하는 템플릿을 보게 되면 생전 처음 보는 내용도 많을 뿐더러 왜 그러한 것이 필요한지 진짜 의미를 이해하기 어렵고, 어떻게 작성해야 하는 것인지 파악이 잘 안 되는 것이 일반적이다. 그리고 이것이 정말로 자신의 회사에서 필요한 것인지 또는 필요 없는 것인지 판단이 안 되기도 한다.

그래서 일단 이것저것 시도를 해보고 효과가 신통치 않으면 나중에 “그거 해봤는데 별로더라”라는 자신만의 편협한 평가를 내리기도 한다. 이러한 서투른 시도는 개발방법론에 대한 나쁜 인식만 키워주기 때문에 아니 한 만 못하다.

여러 개발방법론에서 제시한 문서들이 작성하기 부담스럽다고 문서를 적게 작성해도 된다는 XP, 애자일(Agile) 등에 쉽게 눈을 돌리곤 하는데, 이 또한 너무 쉽게 접근해 실패하는 경우도 많다. XP 방법론이 모든 종류의 소프트웨어를 커버하는 것은 아니지만, 나름대로 적절하게 쓰이면 훌륭한 개발방법론인 것은 사실이다. 하지만, 왠지 간편해 보인다고 만만하게 접근하다간 큰 코 다칠 수 있다. 소프트웨어를 개발하는 데 있어서 가장 어려운 것 중에 하나가 무엇을 만드는지 결정하는 일이다. XP 방법론에서는 이러한 스펙 작성의 어려움을 덜고자 다른 접근을 하는데, 이것이 마치 스펙을 작성하지 않아도 되고, 문서를 적게 만들어도 되기 때문에 개발자들에게는 최고의 개발방법론인 것처럼 생각할 수도 있지만, 그리 만만한 것은 아니다. 스펙 대신 테스트를 이용하고 있지만, 이 또한 공짜로 되는 것은 아니다. 기존에 이미 분석 능력을 가지고 있고, 유닛 테스트(Unit test)에 능통한 경우라면 무리 없이 받아들일 수 있지만, 주먹구구 방식에 익숙한 경우라면 이 또한 어려운 도전이 될 수 있다.

즉, 그냥 쉽게 배우고 프로세스, 템플릿을 좀 익혀서 개발방법론을 제대로 적용해 보기는 어렵다. 공짜로 배워보기에는 개발방법론은 그리 만만하지 않다.

몸에 맞지 않은 개발방법론이 문제

그렇다고 컨설팅을 통해 개발방법론을 도입하는 경우도 그렇게 쉬운 것은 아니다. 여기에는 몇 가지 함정들이 도사리고 있다. 자칫하면 이론에 치우치기 쉽고 회사의 역량이나 규모에 걸맞지 않은 무거운 개발방법론을 도입하게 되기도 한다. 개발방법론을 도입하려는 회사는 어떤 개발방법론이 자신의 회사에 알맞은지 직접 판단하기 어려우므로 외부의 전문가의 판단에 의존하는데 외부의 전문가가 실전 경험이 부족한 경우 회사의 특징과 역량 수준을 고려하지 않고 거대 개발방법론을 기계적으로 도입할 수 있다. 이 경우 큰 Learning Curve를 겪게 되고 결국 이를 극복하지 못하고 실패할 가능성이 높다. 따라서 자신의 회사에 알맞은 수준의 개발방법론을 선택해야 하는데, 이렇게 몸에 딱 맞는 개발방법론을 선택하는 것도 쉬운 일은 아니다.

또, 개발방법론을 하나 정해 놓고 회사의 모든 프로젝트에서 그 개발방법론을 무조건 따르게 하는 것도 문제다. 모든 프로젝트는 그 성격이 다른데, 하나의 개발방법론을 무조건 따르게 되면 간단한 프로젝트에서도 과도한 비용을 지불해야 한다. 이는 개발방법론이 자칫 관료화되는 것을 조심해야 한다는 뜻이다. 애초에 개발방법론을 도입한 이유를 망각하고 관리자나 프로세스 부서에서는 무조건적인 강요로 효율성을 떨어뜨리는데, 애초에 개발방법론을 도입할 때 유연하게 적용을 할 수 있는 여지를 남겨 둬야 할 것이다.

방법론의 목적은 효과적인 개발

소프트웨어 개발방법론의 근본 목적은 소프트웨어를 빠른 시간 안에 적은 비용을 들여 요구되는 품질의 소프트웨어를 만들어내는 것이다. 이런 과정에서 개발자들이 혹사되어서는 안 되며 개발자들은 자연스럽게 소프트웨어 전문가로서의 능력이 향상되어야 한다. 즉 프로젝트도 성공하고 개발자에게도 도움이 되어야 진정한 방법론인 것이다. 그렇지 않고 단순히 절차를 지키기 위한 방법론, 개발자는 희생하면서 프로젝트만 어떻게든 성공하기 위한 방법론은 반쪽짜리일 뿐이다. 그럼에 불구하고 개발방법론은 왠지 무겁고 형식적이고 소프트웨어를 개발하는 데 진짜 도움은 되지 않는다는 생각들은 개발방법론 시도 실패에 대한 반작용으로 생겨난 경험담들 때문이다.

국내 현실은 도 아니면 모
국내 대부분의 소프트웨어 회사는 소프트웨어를 개발하는 방법에 있어서 아래 세 가지의 부류로 나눌 수 있다.

첫째, 주먹구구식으로 소프트웨어를 개발하는 회사. 특별한 프로세스 없이 개발자들의 경험에 의존해 자체적으로 약간의 문서를 만들면서 소프트웨어를 개발하고 있는 회사. 주로 작은 회사들이며 개발자가 100명 이상인 중견 기업들도 상당히 많은 회사들이 이 단계에 머물러 있다.

둘째, 거대 방법론을 도입해서 흉내 내는 회사. 이 경우도 상당수가 내부적으로는 주먹구구이나 형식적으로는 방법론을 따라하고 있다. 주로 대기업에 해당하며 이들 기업은 개발 효율성보다 리스크 감소에 더 관심이 많으며 개발자들보다 회사의 힘이 압도적으로 크므로 추진력 강하게 이러한 개발방법론을 도입할 수 있고, 이러한 무리한 도입 과정에서 벌어지는 비효율성은 개발자들이 요령껏 편법을 이용해 피해가는 경우가 많다. 즉, 내용보다는 형식에 치우친 경우라고 할 수 있다. 이 경우 리스크는 줄어드나 개발 효율성도 따라서 줄어들어 일정 수준 이상을 넘을 수가 없다.

셋째, 거대 방법론이 회사에 맞지 않음을 깨닫고, 다시 주먹구구 개발방법으로 되돌아 온 회사. 그러면서 다른 방법이 없을까 고민하고 있는 회사들이다. 이런 실패의 경험이 반복될수록 내부에 불신이 쌓여가므로 쉽게 새로운 시도를 못하고 주먹구구와 개발방법론 사이를 떠도는 경우이다.

물론 이 세 부류에 속하지 않은 회사들도 있다. 그런 회사들은 스스로를 잘 알고 있으므로 별도로 언급할 필요가 없을 것이다. 그리고 그런 회사는 그리 많지 않다. 첫째와 셋째는 ‘도’에 해당하고 둘째는 ‘모’에 해당하는 경우이다. ‘도’도 바람직하지 않고 ‘모’도 소프트웨어를 개발하는 데 비효율적이다. 가장 좋은 경우는 ‘개’나 ‘걸’처럼 회사의 규모와 개발자들의 역량이 같이 성장해 나가면서 그 단계에서 딱 필요한 것들을 차근차근 하나씩 도입해 나가면서 내재화시켜 나가는 것이다.

뭐든지 단계가 있는 법
뭐든지 배우려면 그 단계가 있고, 차근차근 배우고 익혀나가야 한다. 예를 들어서 골프를 배우고 싶다면 어떻게 될까? 소프트웨어를 취미로 개발하고 있는 것은 아니므로 골프로 프로 선수가 되는 것을 목표로 삼는 경우를 예로 들어보자.

골프를 처음 배워나가면서 타이거 우즈가 공을 치는 방법이 가장 완벽하다고 해서 그 방법을 그대로 따라하기란 불가능하다. 타이거 우즈가 그렇게 공을 치기까지는 십 수 년의 훈련이 필요했고, 타이거 우즈에 가장 알맞은 방법으로 진화해 온 것이다. 그런데 타이거 우즈가 그 방법으로 세계에서 가장 골프를 잘 치는 사람이 되었다고 그것을 그대로 흉내 내는 것은 어리석은 짓이다. 사실 그대로 흉내 내는 것 자체도 불가능하다. 타이거 우즈와 똑같이 치는 방법을 책을 쓰면 책 한 권은 넘을 것이다.

하지만 타이거 우즈는 그 방법을 일일이 생각하면서 공을 치지 않는다. 그 방법이 몸에 익었을 뿐이다. 그냥 공을 치면 저절로 되는 것이다. 이를 ‘내재화’가 되었다고 한다. 그 최고의 방법을 모델로 놓고 그대로 따라하고 훈련한다고 해서 그 방법을 익힐 수 있는 것은 아니다. 그러한 단계로 가기 위해서는 기초부터 배워나가는 방법이 따로 있을 것이다. 또 우리 몸에 맞는 모델은 타이거 우즈의 방법이 아닐 수도 있다. 그런데 최고의 방법이 타이거 우즈의 방법이라고 따라하는 것은 무리한 시도이며 대부분 포기하게 될 것이다.

진짜 프로골퍼를 목표로 하고 골프를 배우고 있다면 타이거 우즈가 골프를 치는 것을 그대로 따라하는 것이 좋은 방법이 아님을 누구나 알 수 있을 것이다. 재미로 마구 골프를 쳐보다가는 평생 프로선수가 되지 못할 것이다. 누구나 상식적으로 생각해도 아주 기초부터 차근차근 훈련을 받아나가야 한다는 것을 알 수 있을 것이다.

그런데 소프트웨어 세상에서는 이런 섣부른 시도들이 종종 발생한다. 개발자들의 역량은 아직 기초 수준인데 세계 최고의 방법론들을 도입해서 시도하면 개발자들도 저절로 세계 최고의 역량을 갖출 수 있을 것으로 착각하는 것 같다.

개발방법론이 가르쳐주지 않는 것
개발방법론은 소프트웨어 회사라면 당연히 갖추고 있어야 하는 것은 가르쳐주지 않는다. 즉, 소스 코드를 어떻게 관리하고, 버그는 어떻게 추적할 것이며, 빌드/릴리즈는 어떻게 할지는 크게 상관하지 않는다.

하지만, 이러한 것들이 아직 체계적으로 갖춰지지 않는 회사가 개발방법론을 도입한다고 하면 따라가기만 하는 것도 벅차고 성공적으로 내재화되기는 어려울 것이다. 축구팀이 기초 체력은 갖추지도 못하고 기본적인 드리블이나 슛 실력이 부족한 상태에서, 다양한 전술과 전략을 익혀봤자 말짱 허사일 것이다. 여기서 말하는 기초 역량은 개발자에게 있어서 설계, 코딩 능력을 말하는 것은 아니다. 우리나라 개발자들의 코딩 능력은 전 세계 어디 내놔도 손색이 없을 만큼 뛰어나다. 여기서 말하는 기초 역량은 소프트웨어 회사라만 기본적으로 갖춰야 할 요소들과 설계, 코딩을 제외한 소프트웨어 전문영역의 다양한 지식들을 말한다. 이러한 것들은 워낙 당연한 것들이기 때문에 개발방법론을 만든 사람들은 소프트웨어 회사라만 당연히 보유하고 있어야 하는 것으로 생각한다.

방법론에서는 그러한 것들은 너무나 당연한 것이라 어떤 방법을 사용하든 별 개의치 않는 경우가 많기 때문에, 그러한 기초조차 제대로 갖추고 있지 않은 소프트웨어 회사라면 현재의 수준을 자각하지 못하고 자칫 그럴듯하게 포장된 방법론만 눈에 들어올지도 모른다. 이런 경우 방법론은 공염불이 되기 십상이다. 방법론을 고민하기보다는 기초부터 다져야 하는 경우이다.

개발자들의 역량

기초란 회사에만 적용되는 것은 아니다. 개발자들도 개발방법론을 따라 개발하기 위해서는 필요한 역량이 있다. 가장 먼저 방법론 하면 산출물이 떠오르는데 대부분의 개발자들은 문서를 작성하는 데 익숙하지도 않고 그보다 먼저 문서 작성을 싫어한다. 이러한 상황에서 템플릿만 잔뜩 제공하고 이를 만들어내라고 하면 보통 괴로운 일이 아니다.

그럼 이쯤에서 의문이 생긴다. 과연 개발자가 문서를 잘 작성한다는 것은 무엇을 말하는 것인가? 개발자들 스스로도 본인이 문서를 잘 작성하고 또 잘 작성할 능력이 있는지 알지 못하는 경우도 많다. 개발자들의 문서 작성 능력을 한번에 알아내기는 어렵지만, 아래와 같은 질문을 해보고 싶다.

소프트웨어를 개발하면서 문서를 만드는 이유가 무엇이라고 생각하는가?

1. 고객이 원해서
2. 나중에 유지보수를 위해서
3. 개발 시간과 비용을 단축하려고

이 중에서 1이나 2라고 답하는 사람들은 아직 문서를 제대로 작성할 능력이 낮을 가능성이 높다. 그 동안 문서를 형식적으로 작성해 왔거나, 문서 작성을 거의 하지 않고 개발을 해오면서 문서는 거추장스러운 것이라고 생각하고 있는 경우가 많을 것이다. 이런 상태라면 개발방법론은 정말 거추장스러운 방해밖에 될 수 없다. 3번이라고 자신 있게 답할 수 있는 사람들은 개발하면서 문서들도 진정 필요한 시점에서 필요한 내용으로 작성했을 것이고, 그렇게 오랜 시간 훈련이 되어 필요한 문서 작성에 능숙할 것이다. 하지만 이렇게 3번이라고 자신 있게 답할 수 있는 개발자들이 많지 않은 것이 현실이다.

방법론에서 만들어내는 수많은 문서들은 문서 자체가 목적이 아니다. 모든 문서들은 다음 작업을 진행하는 데 필요하기 때문에 만드는 것이다. 따라서 다른 개발자들이 내가 만들어 놓은 문서들을 보고 그 다음 작업을 진행할 수 있어야 한다. 즉, 내가 작성한 스펙문서를 보고 설계를 담당한 개발자는 설계를 할 수 있어야 한다. 또 테스트팀은 테스트 계획과 테스트 케이스를 만들어낼 수 있어야 한다. 그리고 기술문서팀(Techpub)에서는 스펙문서만 보고도 매뉴얼을 작성할 수 있어야 한다. 또한 빌드/릴리즈팀에서는 빌드 준비를 할 수 있어야 한다. 하지만, 분석 역량이 부족한 개발자에게 템플릿만 제공해 스펙문서를 만들어 낸들 제대로 설계가 가능하고 테스트 케이스를 만들어 낼 수 없다.

그리고 방법론을 도입하고 약간의 교육으로 그런 수준까지 역량을 끌어올리기는 어렵다. 오히려 거대한 방법은 역량을 차근차근 끌어올리기에는 거추장스러운 옷처럼 방해 요소가 될 수 있다. 차라리 방법론 전체보다는 각 회사에 필요한 기초적인 부분을 추출해 조금씩 적용하는 것이 좋을 것이다. 그러한 과정을 거치면서 개발자들의 역량도 같이 키워나가야 한다. 여기서 필요한 것은 분석, 설계, 프로세스, 형상관리, 테스트 등 개발에 필요한 다양한 것들이다. 이러한 지식과 경험은 하루 아침에 배운다고 익힐 수 있는 것이 아니고, 회사에서 일하면서 조금씩 쌓아 나가는 것들이다. 또한 개발자 혼자서 스스로 익힐 수 있는 것도 아니고, 회사와 같이 개발 업무를 해나가면서 계속 배우고 익혀나가야 하는 것들이다.

잘못 사용되는 개발방법론

개발방법론을 사용하는 이유가 고객이 해당 개발방법론을 적용하기를 원해서인 경우가 종종 있다. 이러한 경우 고객들도 목적이 개발방법론은 아니지만, 소프트웨어 개발에 대한 전문지식이 모자라므로 회사의 규정에 의해서든 여러 연유로 인해 개발방법론 적용을 요구하게 된다. 이 과정에서 개발방법론을 효과적으로 추려내서 적용하지 못하고 전체를 그대로 적용해 달라고 요청하는 일이 발생한다.

고객은 개발방법론 교과서에 나온 대로 기계적으로 산출물과 프로세스를 요구하고 소프트웨어 개발사는 비효율적인 것을 알아도 고객이 원하므로 울며 겨자 먹기 식으로 무조건 따라야 하는 경우가 많다. 하지만 우리나라 개발자들이 어떤 개발자인가. 모든 난관은 헤쳐 나가는 방법이 있다. 방법론에서 요구하는 문서는 어쨌든 만들어내고 있다. 다양한 편법을 통해 문서를 만들어 내고 있고, 대부분의 경우 문서들이 실제 소프트웨어를 개발하는 데 도움이 되지 않더라도 고객이 요구하는 문서는 충족하고 있다. 이렇다 보니 문서 작업은 소프트웨어를 개발하는 데 도움이 되기는커녕 시간만 축내는 낭비요소가 되곤 한다. 하지만 고객의 요구사항이기 때문에 따르는 수밖에 없다.

그 결과, 이렇게 만들어 낸 산출물은 고객에게도 실제로는 아무런 쓸모없이 책꽂이만 차지하는 경우가 허다하고 개발자들은 방법론에 대한 부정적인 생각만 키워나가게 된다. 이렇게 잔뜩 만들어낸 산출물은 유지보수 시 매우 유용하게 사용될 것으로 홍보하지만, 막상 유지보수 때는 개발에 참여했던 개발자를 찾게 되고 문서보다도 소스 코드를 가지고 유지보수를 하게 된다. 이런 것들이 반복되면 개발자들은 개발방법론이란 형식적이고 실제 소프트웨어를 개발하는 데는 별 도움이 안 된다고 생각하게 되고 진짜 제대로 된 방법을 더욱 더 배우기 어렵게 만든다.

고객의 무리한 개발방법론 적용 요구

개발 회사는 아무리 개발방법론을 효과적으로 적용하려고 해도 이렇게 고객이 기계적으로 또는 규정에 의해 무리하게 개발방법론을 요구하는 경우에는 어쩔 도리가 없다. 실제로 고객이 개발방법론을 콕 찍어서  **CBD 또는**OOP 방법론을 요구하기도 하는데, 고객을 잘못 만나면 30~40종류 이상의 산출물을 에누리 없이 만들어 내야 하는 경우도 있다. 또 마일스톤마다 산출물을 검사하기도 하기 때문에 프로젝트가 끝나고 밤샘해서 산출물을 만들어 낼 수도 없는 노릇이다.
이러한 경우에는 진짜로 소프트웨어를 잘 개발하기 위해 필요한 문서와 고객의 요구 때문에 어쩔 수 없이 만들어야 하는 문서를 구별할 필요가 있다. 사실 웬만한 규모의 소프트웨어까지는 주요 문서 2, 3개로 충분히 프로젝트를 진행할 수 있고, 그 외의 문서들은 가능하면 최소한의 노력으로 고객의 요구를 만족시켜주는 수준으로만 만들어주는 것이 가장 효율적일 것이다.

이러한 상황에서 진짜 개발에 필요한 문서와 고객의 요구 때문에 어쩔 수 없이 만드는 문서의 구별이 없다면 자칫 모든 문서가 형식적으로 작성될 수도 있다. 이 과정에서 개발자들은 모든 문서에 대한 거부감만 커지고, 방법론을 제대로 적용한 것 같지만 실제 개발은 주먹구구와 다름없게 될 수도 있다. 아니 오히려 주먹구구에다가 문서를 잔뜩 만들어야 하므로 주먹구구만도 못한 경우가 될 수도 있다.

방법이 목적인 개발방법론
이쯤 되면 개발방법론이 진짜 필요한 것인지 오히려 개발을 방해하는 것인지 헷갈리기도 한다. 하지만 서두에서 말했다시피 개발방법론의 목적은 소프트웨어를 적은 비용으로 짧은 시간에 효과적으로 개발하는 데 있다. 하지만 개발방법론을 만든 사람들의 진짜 목적은 돈을 버는 것이다. 방법론을 팔아서 돈을 버는 회사들은 자신들의 개발방법론을 비싸게 많이 팔아야 한다. 그리고 누구나 쉽게 흉내 낼 수 없게 만들어야 한다.

그래서 자신들의 개발방법론을 다른 방법론들과 차별화하기 위해 노력하고 점점 복잡하게 만들게 된다. 그래야 아무나 따라할 수 없게 되고 또 더욱 비싼 값에 팔 수 있다. 이러다 보니 소프트웨어 업계에는 소프트웨어를 개발하는 수많은 개발방법론들이 넘쳐나고 점점 복잡해지고 있다. 그 반작용으로 간단하다고 어필하고 있는 개발방법론이 출현하기도 한다.

이렇게 되니 대부분의 개발방법론 자체가 잘못된 것은 아닐지라도 우리 회사에 알맞은 개발방법론을 찾기란 쉬운 일이 아니게 돼 버렸다. 오히려 잘못된 함정에 빠지기 쉬운 상황이 된 셈이다.

특히 이전에 어느 정도 경험과 기초가 되어 있는 회사들은 개발방법론을 바라볼 때 어느 정도의 판단 능력을 가지고 자신의 회사에 필요한지 그렇지 않은지 판단할 수 있겠지만, 주먹구구에서 시작한 대부분의 소프트웨어 회사들은 그저 혼란스럽기만 할 것이다.

어떻게 해야 하나?

필자의 경험에 의하면 국내의 많은 소프트웨어 회사들은 거대 개발방법론을 당장 도입하기에는 아직 적당한 상황이 아니다. 개발방법론을 거론하기 이전에 소프트웨어 회사라면 필수적으로 갖춰야 할 조직과 시스템을 먼저 갖추고 회사에 필수적인 프로세스를 만들어가면서 회사와 개발자 모두 필수 역량을 갖출 때쯤 그리고 회사가 좀 더 크고 복잡해지면 방법론을 생각해보는 것이 좋겠다.

또, ‘자전거’를 만드는 회사에서 ‘우주선’을 만드는 방법론을 사용해서는 안 된다. ‘자전거’ 정도의 소프트웨어를 만드는 수많은 국내 소프트웨어 회사들은 거대 개발방법론이 필요하지 않다. 고객이 요구해서 방법론을 꼭 적용해야 하는 경우가 아니고 자체적으로 소프트웨어를 잘 개발하는 것이 목적이라면, 회사에 알맞은 작고 가벼운 개발방법론이면 충분할 것이다.

럼 소프트웨어 회사가 갖춰야 할 필수 역량에는 무엇이 있는가? 가장 먼저 소스 코드 관리시스템, 버그 관리시스템, 빌드 자동화 등 기본적인 인프라스트럭처 시스템들은 갖춰야 한다. 물론 이것이 그렇게 쉬운 것은 아니다. 실제로 이들을 사용하는 많은 회사들이 기본적인 기능만 사용하고 있음에도, 전혀 이런 시스템들의 도움을 받지 않고 소프트웨어를 개발하고 있는 회사들보다는 훨씬 나은 형편이다. 이런 시스템들을 사용해 개발하다 보면 자연스레 그러한 시스템들에 묻어 있는 소프트웨어 개발 철학을 익히게 되고 기본적인 개발 프로세스도 배울 수 있게 된다.

또, 조직적인 측면으로는 소프트웨어 개발에 필수적인 전문 조직이 기본적으로 필요하다. 대부분의 소프트웨어 회사는 처음 시작하게 되면 개발자들이 전문성을 가리지 않고 온갖 일들을 다하게 된다. 개발도 하고 테스트도 하고 고객지원도 하고, 심지어는 영업을 하기도 한다. 하지만 회사의 규모가 커져 가는데 소수의 개발자들이 개발하던 방식과 똑같이 개발하고 있다면 효율성은 점점 떨어져 간다. 이럴 때는 꼭 필요한 부분부터 전문화된 팀으로 구분하고 전담자를 둬서 해당 분야의 전문성을 높이고 개발자는 개발에 집중할 수 있도록 해줘야 한다. 이러한 대표적인 분야는 테스트와 빌드/릴리즈다. 아직도 테스트를 전적으로 개발자들이 담당하고 있는 회사들이 많다. 개발자 10명만 있는 조직보다는 개발자 7명과 테스터 3명이 있는 조직이 더 효율적인 경우가 많다. 개발자들은 자신이 개발한 소프트웨어를 잘 테스트하지도 못하는데, 해당 소프트웨어의 스펙을 상세히 아는 사람이 개발자 밖에 없고 별도의 테스터를 뽑아도 개발자만큼 제품을 알아서 테스트하기 어렵다고 개발자에게 테스트를 계속 맡기는 것은 잘 하지도 못하는 일을 비싼 인건비를 주고 계속 맡기는 것과 같다.

테스트를 별도의 조직에 맡기는 것이 제품의 품질을 더 높여주고 비용 효율적이며 개발자는 개발에 더 집중할 수 있게 한다. 또 이와 더불어 빌드/릴리즈팀은 빌드/릴리즈 과정을 자동화하고 효율을 높임으로써 그 동안 보이지 않지만 많은 비용을 차지하던 것을 절약하면서도 개발을 더 원활하게 진행하도록 지원한다.
이런 회사의 기본 역량 확보와 더불어 개발자들은 문서를 작성하는 능력, 리뷰하는 능력, 분석 능력, 설계 능력 등 개발자들이 갖춰야 할 코딩 능력 외의 필수 능력들을 쌓아 나가야 한다. 이들은 학교에서 배울 수도 없고, 실무를 통해 오랜 시간에 걸쳐서 차근차근 쌓아 나가야 하는 것들이다.

이렇게 기본적인 조직, 프로세스, 시스템을 갖춰나가면 소프트웨어 회사가 내적으로나 외적으로 기본적인 역량을 갖추게 된다. 이쯤 되면 어떤 개발방법론을 접하더라도 이전보다는 조금 더 잘 이해할 수 있게 된다. <그림 1>과 같이 개발방법론을 성공적으로 도입하기 위해서는 소프트웨어 회사와 개발자들이 기초 역량을 갖추고 있어야 한다. 회사가 어느 정도 역량을 갖추고 판단력이 생기면 무작정 좋다고 하는 개발방법론을 도입하기보다는 회사의 수준에 알맞은 방법들을 취사선택해서 조금씩 받아들이는 방법을 택하게 될 것이다.

결국 개발방법론의 목적인 소프트웨어를 빠른 시간 내에 적은 비용으로 효율적으로 개발한다는 것에 좀 더 가까워질 수 있다.





     개발, 개발자, 구글, 마소, 마이크로소프트, 마이크로소프트웨어, 방법론, 블로그, 소프트웨어, 아이마소, 컨설팅, 호랭이
     0   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

스크럼(Scrum) 기반의 프로젝트 관리
+   [마이크로소프트웨어]   |  2009.10.07 21:26  


ALM 모듈에서 가장 쉽게 적용할 수 있으나, 가장 큰 효과를 볼 수 있는 것 중의 하나가 코드 리뷰이다. 소프트웨어의 품질을 보장하기 위한 활동은 테스팅, 일일 빌드, 프레임워크의 사용, 개발 패턴 등과 같이 수 없이 많은 방법들이 있다. 그 중에서 개인적으로 생각하건데, 코드 리뷰만큼 적은 투자로 큰 효과를 얻을 수 있는 기법은 없는 것 같다. 이 글에서는 코드 리뷰에 대한 몇 가지 기법을 정리하고, 더불어 그 적용 방법을 소개하기로 한다.

조대협 bwcho75@gmail.com, http://bcho.tistory.com|자바스터디 운영자이며 한국 자바 개발자 협회(JCO)의 초대 부회장. 자바 개발자 사이트(http://www.javastudy.co.kr)의 초대 시삽을 맡았으며 현재 BEA Systems Korea를 거쳐 Oracle Korea Consulting에서 Principal Consultant로 근무하고 있다. 주요 분야는 SOA, EAI, EP와 같은 Enterprise Architecture와 TP Monitor, J2EE WAS와 같은 미들웨어이며, 이 글에서 소개되는 ALM과 같은 소프트웨어 개발 프로세스에 대한 컨설팅도 수행하고 있다.

코드 리뷰의 시초는 Fagan에 의해 소개된 코드 인스펙션에서 기인한다. 소프트웨어의 개발이 끝난 후에, 전문 인스펙션 팀이 정해진 프로세스와 패턴에 따라서 코드를 검증하고 Defect를 찾는 프로세스를 코드 인스펙션이라고 한다.

코드 리뷰란 ‘코드를 실행하지 않고 사람이 검토하는 과정을 통해 코드 상에 숨어있는 잠재적인 결함(Defect)을 찾아내고 이를 개선하는 일련의 과정’으로 정의한다. 테스팅의 범주에서는 정적인 분석에 속한다. Formal한 코드 리뷰 기법일수록 결함의 발견에 집중하고 소프트웨어 개발 주기의 후반에 위치하지만, Lightweight한 코드 리뷰 기법은 결함의 발견뿐만 아니라, 같은 로직을 여러 관점에서 생각하는 아이디어 회의나 주니어 개발자에게로의 지식 전달 등의 부가적인 목적들도 함께 가지고 있다.

코드 리뷰 스펙트럼

코드 리뷰 기법을 나누는 방법은 크게 얼마나 정석적이고 프로세스적(정형성)이냐에 따라서 Formal/Lightweight 방법으로 나눌 수 있고, 오프라인(Offline)에서 직접 커뮤니케이션을 하는지 또는 메신저, 이메일이나 기타 자동화된 코드 리뷰 도구를 사용하는지에 따라 온라인 리뷰와 오프라인 리뷰로 나눌 수 있다.

먼저 정형성에 따라서 대표적인 리뷰 방법을 나열해보면 다음과 같다(코드 리뷰 기법 중에는 Pair Programming이 종종 언급되곤 하지만, 본인의 개인적인 견해 상 엔터프라이즈 애플리케이션 개발에서 Pair Programming을 실제로 적용하는 것은 매우 어렵다고 판단되므로, 코드 리뷰 스펙트럼에서는 제외한다).

코드 인스펙션

코드 인스펙션(Code Inspection)은 코드 리뷰 기법 중에서 가장 정형화된 패턴의 기법이다. 전문화된 코드 리뷰팀이 시스템이 어느 정도 구현된 단계에서 일정한 패턴을 가지고 코드를 분석한다. 인스펙션 팀은 크게 네 가지 역할을 가지고 구성된다.

[인스펙션의 역할]
● Moderator
Moderator는 인스펙션 팀의 실제적인 매니저로 생각하면 된다. 인스펙션 팀과 그 대상이 되는 코드를 작성한 개발팀간의 인터페이스를 담당하고 필요한 리소스와 인프라를 확보하는 작업을 한다. 또한 인스펙션에 대한 프로세스 정의와 산출물의 정리를 담당한다. 예를 들면, 인스펙션 팀이 계정 업무를 인스펙션을 하다가 업무에 대한 지식이나 코드가 왜 이렇게 짜여져 있는지에 대한 자료가 필요하다면 Moderator가 요청해서 담당 개발자를 섭외하거나 소프트웨어 설계 문서 등을 받아다가 인스펙션 팀에 전달한다.

또는 인스펙션된 결과에 대해 테스트가 필요할 때, 테스팅 환경을 확보하고 인원(DBA나 벤더 엔지니어)을 섭외하는 것도 Moderator의 역할이다. 필요하다면 고객이나 개발자와 함께 인스펙션 미팅을 주선하고 주최하는 역할도 가진다. 가장 중요한 역할 중의 하나는 인스펙션이 언제 끝날 것인지(Exit Criteria)를 정의하는 것이다.

● Reader
Reader는 각종 산출물들을 읽고, 인터뷰 등을 통해 전체 시스템을 이해해 인스펙션 팀이 어떤 흐름으로 인스펙션을 진행할지에 대한 방향을 지시하며, 시스템에 대해 팀 내에서 가장 많은 도메인 지식을 갖는 사람이다. Reader는 시스템의 큰 흐름과 구조를 잘 이해하고 있어야 하고, 상황에 따라 문제가 발생할 수 있는 지점을 미리 예측해낼 수 있어야 한다. 실제 인스펙션은 이 Reader의 방향성에 따라 인스펙션을 진행하게 된다.

● Designer/Coder
Designer나 Coder는 Reader가 지시한 방향에 따라 코드를 검증하고 잠재적인 결점의 발견 및 권장 수정 방안을 만들어 낸다.

● Tester
Tester는 인스펙션이 진행 중인 모듈에 대해 테스트를 수행하고 결점을 찾아내는 역할을 수행하며, 이외에 Designer나 Coder가 권장한 수정 코드 안에 대한 검증을 비롯해 실제 업무 개발자가 수정해 온 코드에 대한 검증 작업을 수행한다.

이처럼 인스펙션 팀은 위의 네 가지 역할을 가지고 있으며    <그림 2>와 같이 6단계로 진행된다. 그럼 그 각각의 단계를 살펴보자.

[인스펙션 6단계]
● Planning
전체 코드 인스펙션에 대한 계획을 수립한다. 기간, 대상, 종료 조건(금액 기준, 목표 TPS를 성취하는지, 시간에 따른 종료 조건 등). 그리고 인스펙션 팀이 이때 셋업(SET UP)된다.

● Overview
이 단계에서는 인스펙션 팀에 시스템과 구성 제품 등에 대한 교육이 이뤄지고, 팀원 간의 역할이 정의된다.

● Preparation
인스펙션을 하기 위한 사전 준비 단계로 각자의 역할별로 필요한 문서를 습득해서 이해하고 필요하다면 인터뷰도 진행한다. 또 이 단계에서는 필요에 따라서 툴(테스팅 툴이나 profiler, Application Performance Monitoring 도구)과 환경(독립된 테스트가 요구되는 경우 테스트 환경을 구축)이 마련된다.

● Meeting(Inspection)
각자의 역할에 따라서 인스펙션을 수행한다. 인스펙션을 통해 결함을 발견하고, 모든 결함은 기록된다. 기록된 결함은 실 업무 개발자에게 전달되어 FIX되도록 하고 필요에 따라서는 권장 수정안을 전달하기도 한다.

● Rework
보고된 결함을 수정한다.

● Follow-up
보고된 모든 결함이 수정되었는지 확인한다.

팀 리뷰

팀 리뷰는 코드 인스펙션보다 좀 덜 정형화되었지만 그래도 일정한 계획과 프로세스를 따른다. 코드 인스펙션 프로세스의 단계(Planning, Overview, Preparation 등의 사전 준비 단계는 생략) 역할은 중복되거나 생략될 수 있는데, 발표자(Author)와 Moderator는 필수적으로 구성된다. 리뷰 시간에는 발표자(코드를 만든 사람)가 코드에 대해 설명하고 팀원은 결함이나 개선안을 찾는다.

Moderator는 리뷰의 주제를 선정해 리뷰를 진행하고, 리뷰에서 나온 의견을 정리해서 Action Item으로 기록한다. 이 Action Item들은 프로젝트 관리자가 실제 프로젝트 Task로 관리해야 한다(일정에 반영되어야 함). Moderator는 프로젝트 관리자(PM이나 PL)가 될 수도 있으나, 팀 내에서 기술적인 실력이 가장 좋은 시니어 개발자가 그 역할을 맡는 것을 권장한다. 일주일에 한 번 정도 팀 리뷰를 수행하는 것이 좋으며, 특정 모듈이나 기능이 완료되는 시점(Short Release)에 수행하거나, 테스트 결과를 가지고 리뷰하는 것도 좋은 방법이 된다.

필자의 경우 프로젝트를 수행할 때, 일주일에 한 번 정도 팀 리뷰를 진행했으며 Short Release에 의해 완성된 부분이나 Risk가 비교적 큰 부분이라고 판단하는 부분에 대해 팀 리뷰를 진행하도록 개발자에게 지시했다. 리뷰 과정에서 나온 의견은 팀 Wiki 페이지에 ‘코드 리뷰 결과’라는 분류를 따로 만들어서 관리했고, 각 의견은 TASK로 생성되어 스케줄에 포함되었다.


 
웍쓰루(Walkthrough)

웍쓰루는 단체로 하는 코드 리뷰 기법 중에서 가장 비정형적인 방법 중에 하나이다. 발표자가 리뷰의 주제와 시간을 정해 발표하고 동료들로부터 의견이나 아이디어를 듣는 시간을 갖는다.

주로 사례에 대한 정보 공유나 아이디어 수집을 위해 사용될 수 있다. 개발을 위한 프로세스에서보다는 ‘Bug 사례에 대한 회의’와 같은 정보 공유 성격에 유리하다. 유일하게 발표자만이 리뷰를 주관하고 발표하는 역할을 가지며, 다른 참여 인원들은 아무런 책임이나 역할을 가지지 않고 자유롭게 의견을 개진한다. 웍쓰루는 정기적으로(주일에 한번) 진행할 수도 있으며, 또는 정보 공유나 아이디어 수집이 필요할 경우 비정기적으로도 진행할 수 있다(정기적으로 진행하는 것이 참여율이나 집중도가 더 높다).
 
Peer Review or Over the shoulder review

피어리뷰나 Over the shoulder Review는 2~3명(주로 2명)이 진행하는 코드 리뷰의 형태이다. 코드의 작성자가 모니터를 보면서 코드를 설명하고 다른 한 사람이 설명을 들으면서 아이디어를 제안하거나 결함을 발견하는 방법이다. 사전 준비 등이 거의 필요 없고, 필요할 때마다 자주 사용할 수 있는 리뷰 방법이다.

주로 시니어 개발자(사수)가 주니어 개발자를 멘토링할 때 사용할 수 있으며, 주니어 개발자에 대한 교육과 함께 주니어 개발자가 양산한 코드에 대한 품질을 관리할 수 있다. 그러나 이 기법은 시니어 개발자의 리뷰 역량에 따라서 결과물의 품질이 달라질 수 있고, 시니어 개발자의 시간 투여량이 많은 만큼 시니어 개발자의 참여도가 떨어질 수 있다(형식적으로 될 수 있다). 그래서 프로젝트 관리 관점에서 Peer Review에 대해서도 프로젝트 스케줄 상의 Task로 잡아주고, 하나의 독립된 업무로서 시간과 노력을 투자할 수 있도록 해야 한다.

실제로 예전 프로젝트에서 신입 사원에게 비교적 난이도가 높은 모듈의 개발을 맡겨야 할 상황이 있었고, 그때 이 Peer Review를 진행하도록 했다. 결과적으로 만족할 만한 품질을 얻었다. 하지만, 시니어 개발자에게 리뷰에 대해 Task를 지정하고 스케줄링을 했음에도 불구하고, 시니어 개발자에게는 결코 적지 않은 워크로드가 되었던 경험이 있었다. 그러므로 팀원 간의 실력 편차와 난이도에 따른 시간 배분과 함께 경험적인 작업량 측정이 필요하다(3~4일 해보면 실제 작업량에 대한 예측이 좀 더 정교해진다).

Passaround
코드 리뷰 스펙트럼에는 포함시키지 않았지만 사용되는 경우가 있어서 소개한다. Passaround는 번역하자면 돌려보기이다. 온라인보다는 오프라인 위주로 진행되는 리뷰인데, 작성자가 리뷰를 할 부분을 메일이나 시스템을 통해 등록하면, 참석자들이 메일을 통해서 각자의 의견을 개진하는 방식이다. 특정 장소에 모여서 같은 시간에 진행해야 하는 기존의 리뷰 방식과는 달리 시간과 장소에 구애받지 않는 방식으로, 리모트에서 작업하는 팀의 경우 유리한 리뷰 방식이지만 반대로 소유권(Ownership)이 애매해서 원하는 결과가 나오지 않는 경우가 많다. 또한 실시간이 아닌 비동기적인 커뮤니케이션으로 인해 커뮤니케이션 속도가 매우 느리다는 단점도 가지고 있다.

이를 방지하기 위해서는 참석자들의 업무 역할에 코드 리뷰라는 역할이 명시적으로 지정되어야 한다. 필자가 일했던 글로벌 회사의 경우에는 버그 수정이나 제품 기능 개선의 경우 개발팀에서 버그 수정과 개선만을 맡는 개발자가 개발팀에 속해 있었기 때문에 원활한 Passaround 리뷰가 가능했고 이슈(버그) 트랙킹 시스템(Atlassian사의 JIRA와 같은)과 소스 코드 Viewing system(Atlassian사의 Fisheye)이 많은 도움이 되었다.

지금까지 간단하게나마 코드 리뷰의 기법에 대해 살펴봤다. Formal한 리뷰(코드 인스펙션) 등에 대한 설명이 많은 것은 꼭 Formal한 리뷰가 좋아서라기보다는 정형화되어 있기 때문에 그만큼 프로세스에 대한 설명이 많이 필요하기 때문이다. 회사의 성격(SI, 게임, 임베디드, 인하우스 개발, 오픈소스 등)이나 팀의 구조나 성숙도에 따라서 리뷰의 기법은 변형되어 적용되어야 한다.

언제 어떤 코드 리뷰 기법을 사용해야 하는가?
그러면 이런 많은 코드 리뷰 기법 중에서 어떤 기법을 사용해야 할까?

코드 인스펙션

코드 인스펙션의 전제는 전문성을 가지고 있는 인스펙션 팀이 일정한 프로세스와 패턴에 따라 개선안을 찾는 작업이다. 즉, 고도로 훈련됨 팀과 기간이 필요하고 어느 정도 개발이 완료되어 있는 인스펙션 대상(시스템)이 있는 것을 전제로 한다. 인스펙션의 시기는 시스템이 개발되어 있는 시점인 릴리즈가 유용하다.

필자는 두 번의 인스펙션을 권장하는데, 개발 초기에 비기능적인 구현을 끝낸 경우 1차 인스펙션을, 그리고 개발이 끝난 후 시스템 테스트(성능, 확장성, 안정성 등)를 수행하는 것이다.

1차 릴리즈는 주로 비기능적이고 Risk가 높은 부분을 구현하는 단계인데, 이 구현체는 전체 시스템 아키텍처의 큰 틀이 되며, 추후 개발에도 이 아키텍처는 크게 변경되지 않는다(1차 릴리즈 다음에 변경하려면 후반으로 갈수록 많은 리소스가 소요된다). 그래서 1차 릴리즈 후에 정밀 인스펙션을 해서 아키텍처의 안정성을 검증할 필요가 있다.

개발 후반의 시스템 테스트는 주로 비기능적인 요건(성능, 안정성 등)에 대한 성능 테스트가 이뤄지는 단계이므로 테스트 시나리오가 미리 잡혀 있고 테스터와 테스트 시나리오가 명확하게 정의되어 있다. 그러므로 인스펙션을 수행하기 용이하며 최종 점검이라는 관점에서 매우 유용하다.

그럼 인스펙션을 수행하는 주체는 누가 좋을까? 전문 SI사 Task Force를 운영해 프로젝트를 돌아다니면서 인스펙션을 수행할 수 있고, 여러 개의 솔루션을 인하우스 개발하는 업체들은 QA 조직내에 자체적으로 인스펙션 팀을 운영하는 것을 권장한다. 그 외의 일반 업체(갑)나 기업의 경우 인스펙션 팀을 운영하기보다는 인스펙션 프로세스를 전체 개발 프로세스와 프로젝트 비용 산정에 포함하고 SI나 벤더 컨설팅을 활용하는 것을 권장한다.

인스펙션의 결정 주체는 주로 PMO(Project Management Office)와 AA(Application Architect)가 되는 것이 좋다. 대체로 개발 주체 조직 외부에서 인력을 데려 오고, 여러 팀이 함께 인스펙션에 참여해야 하며 일정에 대한 조정과 인스펙션 결과에 대한 반영이 필요하기 때문에 프로젝트 관리 조직 측면에서 접근하는 것이 바람직하다.

팀 리뷰
팀 리뷰는 각 개발 유닛에서 활용하기 좋은 기법이다. PL (Project Leader)의 역량 아래 수행할 수 있으며, 팀원이 리뷰어가 되기 때문에 팀 단위에서 활용하기가 매우 좋다. 일주일에 한 번 정도, 한 시간 정도 리뷰를 정기적으로 수행하도록 하며, 시니어 개발자나 PL이 리뷰 대상 모듈을 선정하고 개발자에게 리뷰를 준비하도록 한다. 리뷰는 발표자가 리드하도록 하고, 리뷰에서 나온 의견을 Action Item으로 잡아서 PL이 발표자의 스케줄로 조정해주는 작업이 필수적으로 따라야 한다.

팀 리뷰에서 권장하고 싶은 사항은 위에서도 잠깐 언급했지만 위키와 같은 문서 공유 시스템을 이용해 반드시 리뷰의 결과를 남기도록 하고, 리뷰의 결과는 Task Management의 Task로 연결되어야 한다. 리뷰되고 반영된 내용은 그냥 넘어가지 않도록 하고, 재 테스트를 통해 반영 내용을 반드시 검증하도록 한다.

웍쓰루(WalkThrough)
일종의 아이디어 회의 정도로 보면 되며, 비정기적으로 언제나 개최할 수 있다. 팀 리뷰처럼 PL이나 시니어 개발자가 중재하지 않기 때문에 구성원들의 의욕이 낮을 경우 효과가 매우 낮다. 개발팀보다는 QA나 운영팀에서 장애 사례나 버그 수정 사례 등의 정보 교환 목적으로 사용하는 것이 좋다.

Peer Review
신입 개발자 교육이나, 해당 제품 또는 기술에 전문적인 지식이 없는 경우에 Knowledge Transfer(지식 공유)와 품질 유지를 위해 유용하다. 대신 리뷰어의 Task 부담이 가중되기 때문에(예상하는 것보다 많이, 심하게는 50%에 육박할 경우도 있음) 리뷰어에 대한 스케줄 배려가 필요하다.

요약

본인의 경험에 비춰보면 팀 리뷰가 가장 효과가 높다. Peer Review는 팀원 간의 실력 편차가 클 때 탄력적으로 운영했고, 엔터프라이즈 시스템(Enterprise System)과 같이 난이도가 높은 시스템의 경우 인스펙션의 효과가 비교적 크다. 비록 비용이 소요되지만 잘못된 아키텍처로 인해 전체 품질이 떨어져서 비즈니스에서 손해를 보거나 쓸 데 없이 하드웨어 증설을 통한 비용을 생각하면 훨씬 낮은 금액이 아닌가 싶다.

효과적인 코드 리뷰를 막는 요인들

코드 리뷰에서 가장 힘든 점은 한마디로 내가 만든 코드를 남이 잘못되었다고 이야기하는 순간이다. 리뷰의 주요 목적은 결함의 발견과 개선 방안 강구이다. 흔히 농담 삼아서 이 과정을 ‘창던지기’라고 이야기하는데, 발표자는 리뷰어로부터 많은 질문과 공격을 당하기 때문이다. 그래서 실제로 인스펙션을 해보면 개발자는 인터뷰를 당하는 것에 대해 마치 취조 당하는 느낌을 가지게 될 수도 있고 그로 인해 방어적으로 행동할 수도 있다.

그래서인지 팀 리뷰의 경우 감정 싸움으로 번지는 경우가 허다하다. 팀 리뷰나 인스펙션의 경우 리뷰를 중재하는 사람이 있기 때문에, 리뷰어가 아이디어나 결함에 대한 의견을 자유롭게 개진할 수 있도록 해야 하며, 반대로 발표자가 인신공격을 받지 않도록 중재하는 기능도 필요하다. 이건 어떤 프로세스나 시스템으로 될 수 있는 일이 아니라 ‘사람 사이의 관계’에서 발생되는 일이기 때문에 ‘문화’의 변화가 필수적이다.

또한 위에 언급한 대부분의 리뷰 기법들은 리뷰와 그에 대한 후속 처리에 시간과 사람이 필요한 일이기 때문에 프로젝트 운영 관점에서 시간과 리소스에 대한 배려가 이뤄져야 한다.

경험상으로 팀 리뷰가 팀에 자리 잡기 위해서는 좋은 리더가 있다 하더라도 최소한 한 달 정도(통상 2개월)의 기간이 필요하다. 다시 말해 이는 급하게 할 일은 아니라는 것이다.

출처 | 아이마소





     Microsoft, 개발자, 마소, 마이크로소프트, 마이크로소프트웨어, 방법론, 블로그, 스크럼, 프로젝트관리, 호랭이
     2   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

<<이전 | 1 | 다음>>

마소호랭이's Blog is powered by Daum