박종명의 아름다운 개발 since 2010.06

모든 분야의 엔지니어링 원리는 다음과 같이 단계적인 발전 과정을 거치게 된다

공학의 ACE라 하는데, 각 단계는 다음과 같은 의미를 가지고 있다

Art: 개인의 재주에 의존하는 단계

Craft: 차츰 과학적 원리가 도입된 숙련공이 일반화 되는 단계

Engineering: 공학적 원리가 적용되는 단계

소프트웨어 공학 서적에 나오는 내용으로 소프트웨어 역시 다른 엔지니어링 분야의 단계와 같은 발전 과정을 거친다는 것이다. 타 산업분야에 비할바는 아니지만, 소프트웨어 공학이라는 개념이 탄생한지도 50년이 다 되어가니 적지 않은 세월이 흐른 셈이다.

소프트웨어 산업의 중심에 있는 우리 프로그래머들은 과연 이러한 체계적인 공학 원리에 충실하고 있는지 생각해 봐야 할 문제이다. 국내 환경이 공학적 접근 노력을 시도할 수도 없을 만큼 스펙타클하게 운영되고 았는 현실인지라 힘에 겨운 것도 있지만, 그렇다고 환경만을 탓하고 있기엔 우린 너무 빨리 늙어 버린다. ㅎㅎ

소프트웨어 공학이라는 개념이 탄생하고 뛰어나신 분들이 연구에 연구를 거듭하는 것은 결국 소프트웨어의 품질과 생산성이라는 두 마리 토끼를 어떻게 쉬이 잡을 것이냐를 위한 것인데 프로그래머들의 현실적인 생산성 문제로 공학적 접근을 하지 못한다는 것은 뭔가 앞뒤가 맞지 않다

소프트웨어 공학이 프로그래밍 코드보다는 개발 공정에 초점이 맞춰져 있어 내일 당장 동작하는 코드를 내뱉어야 하는 프로그래머들에게는 (뭔가.. 그럴싸 하다는 건 알겠으나...) 체감되지 않기도 한다

역사가 깊은 건축 공학의 많은 개념이 소프트웨어 공학에도 접목되는데, 예를 들어 빌딩을 지으면서 공학적 접근을 하지 않을 수는 없을 것이다. 그럼 아파트 혹은 빌라라면?? 아니면 집에서 키우는 개를 위한 개집을 짓는다면??

산업의 발전을 그렇다치고, 우리 개인의 발전 과정과 현 상태는 어떤가?

A와 C단계를 겨우겨우 오르락 내리락 하지 않는지, 자문해 볼 일이다.

작은 슈퍼를 운영하더라도 경영 마인드가 있어야 한다는 예기가 있다

비슷하게 풀어보면,

개집을 지어도 빌딩 건축업자 마인드가 있어야 있어야 하지 않을까?

오버거나 말거나...

프로그램 코드의 주석은 코드 이해와 유지보수성을 좋게 하는 중요한 요소이다.

그러나 실무 환경에서는 잘 지켜지지 않는 경향이 있다. 개발 규칙이 철저하게 지켜지는 환경이라면 몰라도 그렇지 않을 경우 종종 무시되곤 한다.

코드에 주석을 다는 것이 중요하다는 것은 두말이 필요 없을 것이며, 더 나아가 주석에 어떤 내용을 담을 것인가도 매우 중요하다 하겠다. 특히 다른 사람이 작성한 방대한 코드를 분석하게 될 경우 주석의 퀄리티(?)는 분석을 얼마나 빨리 정확하게 하는가의 주요한 잣대가 된다.

주석의 퀄리티는 주석에 담긴 내용으로 평가할 수 있다. 개인적으로 주석의 내용은 다음과 같은 순으로 작성하는 것을 권장.. 아니 필수라고 하고 싶다.

지금 자신의 주석 습관을 되새겨 보자. 대체로 What 을 설명하고 있지 않는가?

제일 중요한 것은 Why이다. 즉 해당 코드가 왜 이렇게 작성되었는가?에 대한 대답이다. 특히 오랜 시간 유지보수되어온 코드라면 Why는 더욱 중요해진다. 대부분의 프로그램은 시간이 감에 따라 수정/보완이 되고, 요구사항/환경의 변화와 시스템의 제약사항 등으로 처음 보는 사람이 쉽게 납득하지 못하는 형태로 변모되기 일쑤다.

다시 말해 코드 자체가 이해 되지 않는 경우보다는 왜 코드를 이렇게 작성해야 했는가?... 에 대한 대답이 필요하게 되는 것이다. 이것은 코드를 잘 작성했고 못했고의 문제가 아니다. 코드의 히스토리에 대한 의문이다.

필자는 실제로 방대한 시스템을 인수받을 일이 있었다. 그 시스템은 오랜 시간 운영 되어온 시스템으로 주석이 잘 작성되어 있지 않았을 뿐더러 있는 주석의 경우에도 대부분 What를 설명하고 있었다. 따라서 코드 분석에 가장 많은 시간을 할애한 부분이 바로 Why에 대한 대답을 찾는 것이었다.

사실 코드를 읽을 수 있는 프로그래머라면 What과 How는 어렵지 않게 파악이 가능하다. 그러나 Why의 경우 쉽지 않다. 특히 코드 자체가 아니라 시스템의 제약사항이나 요구사항의 특수성을 반영한 코드를 Why 없이 분석한다는 것은 참으로! 쓸데 없는 에너지가 낭비되는 것이다.

(참고로 개발자 들이여... 남의 코드를 보고 무조건 까지 말자. 그에게 말 못할(?) Why가 있었을지도 모른다)

결론! What과 How도 간단하게 명시하는 것이 좋지만 귀찮다면 Why 라도 남기도록 하자.

혹시 '누구 좋으라고' 라는 의문이 드는가? 그렇다면 당신은 지친 개발자!

아침 출근길에 애매한 신호등과 마주쳤다.

빨간불이었다가, 갑자기 빨간등과 녹색등이 같이 들어와 버린 상황. 순간 정지해 있던 차량들의 주춤거리는 모습. 다행히 차량 통행이 많지 않고 복잡한 도로가 아니라서 큰 혼란은 발생하지 않았지만, 문득 머리속에 스친 생각은 프로젝트 관리도 이와 다르지 않다는 것이었다.

(당신이 이 신호등과 마주쳤다면 어떻게 하겠는가?)

프로젝트 관리자는 여러 애매한 상황에 놓인다. 특히 시스템이 방대하고 이해관계 마저 복잡한 경우에는 더욱 그러하다. 따라서 프로젝트 관리자는 애매한 상황을 정리하는데 노력을 기울여야 하며, 프로젝트 구성원들이 정확한 노선으로 일을 진행할 수 있도록 도와야 한다.

프로젝트 관리자가 어떤 결정을 내릴 때, 스스로 애매함을 정리하기 힘든 상황이라면 다음 두 가지 요령이 필요하다.

애매함 보다는 차라리 고집이 낫다

애매함을 오랜 시간 방치하기 보다는 차라리 고집을 부리는 것이 낫다. 오랜 시간 방치한 애매함은 프로젝트의 진행을 더디게 만들고 구성원들을 지치게 한다. 차라리 결정을 하고 독단적이라는 비난을 두려워 하지 말고 고집을 부리는 편이 낫다. 단, 고집을 부릴만큼 본인이 많은 고민을 해야 한다. 한면이라도 고집의 근거와 타당성이 있어야 한다는 말이다.

애매함 보다는 위임을 활용하라

고집을 부리기 싫거나 한면이라도 타당성을 찾기 힘든 상태, 아니면 그 어떤 이유로든 고집을 부리기 힘든 상황이라면 차라리 그 결정을 위임하는 것이 좋다. 이것은 책임을 회피하기 위해 일을 떠넘기는 개념과는 다르다. 결정도 정확히 내리지 않고 누군가가 결정하도록 위임도 하지 않는다면 모두가 실패하는 결과를 맞을 것이다. 수 많은 결정들 가운데 일부는 그들의 능력을 전적으로 활용하라는 것이다.

물론 고집과 위임이 애매함의 유일한 해결책은 아니다. 이것은 애매함을 순조롭게 풀기 힘든 상황에 꺼낼 수 있는 카드라고 하는 것이 맞겠다.

소프트웨어 기반 프로젝트의 성공에 매우 밀접하게 작용하는 요소가 바로... 사람이다.

인적자원관리라는 용어가 사용되는데, 인적자원의 획득과 역할과 책임, 양적/질적 관리와 교육/평가/보상 등을 관리하는데, 뭐니뭐니 해도 동기 부여를 어떻게 하느냐가 핵심이라 할 수 있다.

각 개인마다 서로 다른 내적 동기요소를 파악하여 프로젝트 혹은 회사의 궁극적 비전과 일치 시키는 것이 이상적이라 하겠다. 그러나 문제는 이게 말 처럼 그렇게 쉽지 않다는 것이다.

조직의 비전은 간혹 어떤 사람들에게는 '그들만의 비전'으로 치부되기도 한다.

조직의 비전, 개인의 가치.. 이 둘의 함수관계에 따른 공헌도 조사가 흥미롭다.

아래 글에 따르면, 이 두 가지 가치의 조화가 가장 이상적이지만, 차선책은 개인의 가치 확립에 무게 중심을 둬야 한다는 시사점을 제공한다.

결국 조직의 비전을 확고히 하고 이를 공유,공감시키는 활동과 더불어 이와는 별개로 개인의 가치 확립에도 노력과 비용을 들이는 것이 궁극적인 프로젝트 성공에 열쇠가 될 수 있다는 점이다.

개인적 가치의 확립은 헌신과 솔선수범에 이르는 길이 된다.

한 조사기관에서 사람들에게 이런 가치 확립과 특별한 성과를 얻기 위한 노력 간의 함수관계에 대해 질문했더니, 집단이나 조직의 가치가 불분명하고 개인의 가치도 확립되지 않았을 경우에 평균 공헌도는 7점 만점에 4.9점이 나왔다. 또 집단의 가치가 명확하고 개인의 가치가 불분명할 경우에도 역시 평균 공헌도는 낮았다. 그에 반해 집단의 가치가 명확하지 않지만 개인의 가치가 확립되어 있을 때는 7점 만점에 6.12점이 나왔고, 개인의 가치와 집단의 가치가 모두 확실하고 이 두 가지가 조화를 이룰 때는 평균 공헌도가 7점 만점에 6.26점으로 가장 높았다. 이런 수치로 미우러 볼 때, 자신의 개인적 가치를 알고 있다는 것은 집단의 가치를 공유하는 것보다 더 중요하다는 사실을 알 수 있다.

- +9(플러스 나인), 로버트 K. 쿠퍼 저

현재 팀에서 사용하고 있는 소스 형상관리 툴은 TFS와 SVN 이다.

DB 스크립트나 일반 문서만을 다루는 사람들을 위한 소스 관리 환경이 필요했다.

즉 Visual Studio를 사용하지 않는 사람들만을 위한 환경이 필요한 것인데...

언뜻, SVN이 적합하다는 생각이 들었다.

다만 윈도우 탐색기로 소스 관리하는 것과 더불어,

이들이 주로 사용하는 툴인 SSMS(SQL Server Management Studio)와 연결해서 좀 더 편한 관리를 할 수 있는 방법이 없나 하면서 TFS 관련된 플러그인 들을 찾아 봤다.

먼저. 아래 플러그인을 설치 하면 SSMS에서 TFS로 연결할 수 있게 된다.

http://www.techtree.co.uk/sql-server/management-studio-ssms/use-team-foundation-server-tfs-as-your-source-control-in-ssms/

툴을 설치하고 SSMS의 옵션에 아래 그림과 같이 소스 제어 플러그인을 설정할 수 있다.

그리고 이후 프로젝트 생성하고 TFS서버에 연결해서 관리하면 된다.

그리고 TFS도 (SVN 클라이언트 처럼)윈도우 탐색기를 통해서 소스 관리가 가능하다는 아래 글을 보고 설치 해 봤다.

http://support.microsoft.com/kb/2699161/ko

http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f

음.. 그런데 기대 했던 것 보다 불편하다.

2번째 툴을 설치하고 탐색기를 보니, 일단 글과 다르게 아이콘 모양이 표시되지 않는다.

그러나 TFS와 연결된 폴더의 컨텍스트 메뉴를 보면 아래 그림과 같이 TFS 로 관리할 수 있다.

단 아쉬운 것은 TFS와 미리 연결되어 있는 폴더라야만 해당 메뉴가 나타난다.

SVN과는 달리 일반 폴더에 TFS 연결 부터 하고 싶을 경우는 지원하지 않나 보다.

Visual Studio를 같이 사용하지 않는 이상, 이런 방식의 TFS 사용은 별로다.

이것저것 대략 살펴보다, 빠른 결론 내린다.

SSMS의 SVN 클라이언트 플러그인을 설치하기로 한다.. ㅎㅎㅎ

http://www.zeusedit.com/agent/ssms/ms_ssms.html

경험은 돈으로도 살 수 없는 매우 소중한 재산입니다

공부를 많이 한 사람보다 경험을 많이 한 사람에게 실제적 지식을 얻을 수 있습니다.

프로젝트를 진행하고 시스템을 운영하다 보면, 참으로 다양한 경험을 합니다.

그 중에서 어떤 문제를 해결한 경험의 가치는 이루 말할 수 없이 값진 거란 생각이 듭니다.

특히 개발자들은 늘 버그를 수정하고 삽니다.

배운대로 개발을 하더라도, 잘 개발된 시스템일지라도.. 다양한 이유로 버그는 발생할 수 밖에 없지요.

이럴때면 개발자들은 문제점의 원인을 분석하고 여러 기법을 동원해 문제를 해결해 나갑니다.

이러한 고도의 지적 활동 경험은 매우 가치있는 지식입니다.

안타까운것은 이 중요한 지식이 담당 개발자의 머리속에만 저장되어 있다는 겁니다.

더 슬픈건, 담당 개발자의 머리속에서도 언젠가는 지워질게게 분명하다는 점입니다.

그래서 경험 지식을 관리하고 싶어 졌습니다.

6하원칙이면 좋겠네요

- 언제

- 어디서

- 무엇이

- 왜

- 어떻게

- 누가

언제 어떤 문제가 어디서 발생했으며 왜 그러한 문제가 나타났는지, 그래서 누가, 어떻게 해결했는지입니다.

개발자의 경험 지식을 DB화하여 체계적으로 관리하면 좋은 점이 많습니다.

- 그 자체가 새로운 지식입니다.

- 인수인계를 받거나 신규 직원이 들어왔을 때 해당 시스템을 보다 빨리 습득할 수 있습니다.

- 유사한 형태의 개발을 진행할 때, 버그를 수정할 때  참고하면 버그 발생률을 현저히 저하시킬 수 있습니다.

- 잊어버렸던 과거 지식을 필요할 때 언제든 다시 불러올 수 있습니다.

KMS라는 거창한 솔루션이 필요한게 아닙니다. 그냥 카테고리화 할 수 있고 검색할수 있고 약간의 템플릿을 구성할 수 있는 게시판이면 족합니다.

외부 시스템을 인수 받아서 운영을 해야 할 경우, 전달 받아야 할 산출물을 생각해 봤다.

유스케이스 명세서, 기능 차트, 제품 백로그와 같은 실제 구체적 산출물은 개발 방법론 혹은 프로세스에 따라 달라지기 때문에 필요한 항목과 설명을 우선하고 예시로 산출물을 제시한다.

또한 자체 개발일 경우 개발 과정에서 산출되어지는 산출물은 배제되었다.

산출물 예시는 아래와 같다. 좀 과한 느낌? 필수와 옵션으로 나누면 될터이다.

마지막으로.. 이런 건 정답 없다!

그 자리를 대신 할 사람은 많지만, 그 사람을 대신 할 사람은 없다

프로젝트를 관리하다 보면, 제일 어렵고도 중요한 것이 사람이라는 생각이 듭니다.

유용한 많은 기법과 방법론들, 자동화된 각종 도구들이 많은 업무를 깔끔하게 처리해 주지만

'결국 일은 사람이 하는 거다' 라는 말 처럼 사람이 근간이지요.

모든 프로젝트 팀이 혹은 모든 팀의 구성원이 높은 열정을 지속하기 힘든 게 현실입니다.

업무의 비전, 당면한 처우, 상대적 박탈감과 같은 다양한 사건들이 항상 우리의 열정을 끌어 내리려 합니다.

문득 책일 읽다가 좋은 표현을 봤습니다.

'그 자리를 대신 할 사람은 많지만, 그 사람을 대신 할 사람은 없다'

말 장난 같은 이 말을 가만히 들여다 보면, 참 감동되는 말입니다.

'자네 아니라도 그 일 할 사람 많어!!!' 라는 일침을 가하기 전에 생각해 보아야 할 문제입니다.

실제로 그 일 할 사람은 많을지 모릅니다. 그게 현실이다 보니 직업 불안정성은 언제, 어디나 있죠.

(죄송합니다. 저도 가끔 이와 유사한 말을 내뱉은 적이 있습니다)

그런데 좀 더 본연으로 들어가 보고 싶습니다.

업무가 아닌 사람을 먼저 보고 싶습니다(음.. 대선 후보 같은 말이네요...)

그 사람 만이 가진 능력, 개성은 아무도 대체할 수 없습니다.

박애주의냐구요?... 아닙니다.

저는.. 성과지향, 경쟁을 통한 쟁취, 현실적.. 이런 단어들과 친숙한 사람입니다.

다만,

사람에 대한 이해와 공감을 선행하고 그 사람만의 개성과 능력을 발휘할 수 있도록 도움을 주는 것이 관리자가 갖추어야 할 덕목이라는 말을 하고 싶은 겁니다.

노력 해야죠.

'아무나 하면 된다'에 아무나가 과연 누구일까?

프로젝트를 진행하다 보면 특정 그룹에 업무를 부여할 때가 있다.

근데 그 그룹에 특정 1인을 지목하기가 애매한 경우 그룹 전체에 부여하게 된다.

그러나 그 일은 한 사람이 맡아서 하면 될만한 일일 경우 간혹 다음 공식으로 귀결되는 경우가 있다

"아무나 = 아무도"

즉 아무나 하면 된다는 것은 아무도 하지 않는다는 씁쓸한 결과이다.

초등학교때 교과서에 이런 글이 기억날 것이다.

어느 화목한 가정에서 아버지가 가족이 모두 모인 저녁 시간에 바지 밑단을 좀 잘라 줬으면 하고 부탁했다. 그날 밤 엄마는 물론이고 자식들도 스스로 자신이 솔선수범하여 그 일(바지 밑단을 자르는 일)을 해 버리는 바람에 아침에 아버지는 반바지가 되어 버린 바지를 입어야 했다. 이 일을 자랑스럽게 여긴 아버지는 옆집 아저씨한테 이 말을 하자 그 옆집 아저씨도 자기도 한번 가족을 테스트(?) 해보 싶어졌다.

 

옆집 아저씨도 가족이 다 모인 저녁에 바지 밑단을 잘라 줬으면 하고 부탁했다.

다음날 아침, 설레이는(?) 맘으로 바지를 입어 봤더니 바지는 여전히 길게 축~ 늘어져 있던게 아닌가. 옆집 가족은 일종의 화목하지 않은 가정의 사례로 '누군가 하겠지' 하고는 다른사람에게 떠 넘긴 것이다.

이 이야기는 가족의 화목이라는 주제를 다룬 것이지만 여기서도 '아무나=아무도' 현상이 보이는 것이다.

프로젝트를 진행하다 보면 모든 팀이 한 가족처럼 화목(?)하지는 않다. 화목하지 않은 근원 이유를 제거하는 것이 가장 좋지만 여기서는 그러한 원론적인 해결을 논하려 하는 것이 아니다.

'아무나' 라는 애매한 설정이 결국 아무도 하지 않는 현상에 초점을 맞추려 한다.

심리학에 보면 '다수의 무지'라는 것이 있다.

수십명의 목격자가 지켜보는 가운데 처참하게 살해된 살인 사건에서의 교훈으로 '모두의 책임은 아무의 책임도 아닌 상태'가 되어버린다는 것이다. 그래서 위험한 상황이 발생하면 그냥 '도와 주세요'가 아닌 '그기 누구 나 좀 도와주쇼!'가 되어야 한다는 것이다.

특정 그룹이지만 특정인이 하면 되는 일은 그 일을 할 사람을 분명하게 지목해 주는 것이 좋다.

물론 위의 화목한 가정처럼 "아무나 = 전부다"의 공식이 성립하는 분위기라면 (바지 밑단이 과도하게 잘린 사소한 실수를 제외하고는) 더할 나위 없이 좋겠지만 우리네 프로젝트 환경이 꼭 그렇지는 않다는 것이다.

누구를 탓하기 이전에 좀더 정확하고 명확한 업무 부여가 필요하며 나아가 프로젝트에 참여하는 모든 구성원이 스스로 솔선수범하여 일을 척척 해 나가는 것이 중요하다.

그것이 프로젝트의 재미이지 않겠는가...