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

이런 증상이 있지 않나요? 데브옵스를 처방해 드리겠습니다.

------------------------------------------------------------------------

우찌.. 이런..

이리도 이그젝틀리 한지..

IT 전문 매거진에 실린 '개발자가 저지르기 쉬운 7가지 나쁜 습관'의 내용이다.

오늘자 전자신문에 실린 '정보통신산업진흥원 SW공학센터장(이상은)'의 컬럼 내용을 옮겨온다.

자칫 나태해지기 쉬운 개발업무를 돌아볼만 하다.

1. 욕심에 의한 엔지니어링의 남용

- 책에서 제시된 방식들이 항상 효과가 좋은 것은 아니어서 원래 사용했던 방법을 효과적으로 사용하는 것이 더 좋은 방법일 수 있다. 프로그래밍의 대가들은 "새로운 기법을 활용하는 것보다 더 중요한 것은 기능의 효과적 구현이다"라고 말하고 있다.

2. 계속 기능만 추가하고 개발했던 내용을 리팩토링하지 않는 것

- 이미 개발된 코드는 완전하지도 않으며 추가되는 기능이 점점 늘어 갈수록 복잡해지고 뒤엉켜 버리기 때문에 기존 코드의 품질과 유지보수성을 평가해 코드에 대한 신뢰성을 확보하는 것이 중요하다.

3. 개발자 사이의 경쟁

- 팀 간에 프로젝트가 비공개적으로 진행되면 다른 팀이 이미 구현한 라이브러리를 중복적으로 개발하게 된다. 개발의 최우선 과제 중 하나는 각자가 어떤 작업을 하고 있는지 서로에게 알리는 것이고, 모든 팀들이 공통의 목표를 갖고 정보를 공유하는 것이다.

4. 입력값의 유효성 검증에 실패하는 나태함

- 개발하면서 사소한 실수는 빈번히 일어자지만 잘못된 입력값을 받아들이는 개발 실수는 매우 치명적이어서 신중해야 한다.

5. 소스코드에 코멘트를 달지 않는 것

- 일단 개발된 소스코드는 보관되었다가 나중에 유지보수를 위해 다른 사람이 작업을 하게 되는 것이 보통이다. 이때 코멘트가 없다면 해당 코드가 무엇을 의미하는지 이해하기 어렵고 시간도 오래 걸린다. 따라서 최소한 힌트를 남겨둬야 한다.

6. 버전관리를 하지 않는 것

- 요즘엔 강력하고도 효과적인 버전관리 도구를 무료로 손쉽게 구할 수 있다. 심지어 분산 프로젝트를 관리할 정도의 도구도 최소 비용으로 구할 수 있다. 따라서 다른 문제가 없다면 가장 기본이 되는 버전관리시스템은 반드시 만들어둬야 한다.

7. 단위테스트를 하지 않는 것

- 개발된 프로그램이 좋은 평가를 받는 것은 개발자로서 영광스러운 일이다. 하지만 결함을 가진 코드가 출시된다면 그 뒤처리를 감당하기 어렵게 된다. 코드를 출시하기 전에 단위 테스트를 철저히 할수록 나중에 감당해야 하는 피해를 최소화할 수 있다.

그 규모의 크기에 상관없이, 리더는 책임감을 가지고 자신의 리딩 업무를 수시로 점검해야 할 것이다.

리더에게 주어진 것은 명령을 할 수 있는 권한이 아니다.

리더에게 부여된 권한은 책임에 수반되는 수단일 뿐이다.

따라서 책임이 없는 리더의 권한은 봉건사회 계급구조상의 비루한 권력과 다를바 없다.

프로젝트팀을 관리하는 리더의 책임은 무었일까? 리더가 구성원들의 모든 잘못에 책임을 져야 하는가?

여기서 언급하는 책임은 이러한 1차원적인 문제가 아니다.

제일 중요한 리더의 책임은 바로 '비전' 제시이다. 그 흔하디 흔한 말... '비전'이다.

식상할 정도로 자주 언급되는 이 말은 역설적으로 그 실체를 찾기 힘들 정도로 귀하디 귀하다.

흔히 어떤 일을 구체화 시킬 때 6하원칙에 입각하여 서술하곤 한다.

리더의 책임이라는 관점에서 가중 중요한 원칙은 바로 "왜(why)" 이다.

구성원들이 하는 '그일'에는 이유가 있어야 한다는 것이다. 이유도 모른채 혹은 이유가 공감되지 않은채 하는 일은 초등학생도 싫어하는데 하물며 성인이래야...

'왜(why)'가 뚜렷하다면, '무엇(what)'은 저절로 성립된다.

반면, 평범한 리더(리더라 부를 수 있을지 모르겠지만...)는 '어떻게(how)'에 집중한다.

구성원들에게 '이건 이렇게, 저건 저렇게...' 어떻게 하는지 알려 주고 싶어서 안달이다.

키 플레이어가 좋은 리더가 되기 힘든 대표적인 사례라 하겠다.

더 최악은 '누가, 언제, 어디서'에만 집중하는 리더이다. 사실 이런 부류는 리더라 부르면 안된다.

야근의 횟수로 역량의 척도로 판단하는 전형적인 예를 들 수 있겠다.

6하 원칙은 모두 중요하다.

하지만 훌륭한 리더가 되기 위해서는 '왜(why)'와 그에 맞는 '무엇을(what)'에 우선 집중해야 한다.

'어떻게(how)'는 그 다음이다.

조직의 핵심 가치에 공감한 구성원들이 그들의 열정과 호기심을 프로젝트에 불싸지르도록 하는 중요한 기준임을 명심하자!!!

스스로 반성해 볼 일이다.

요청 수가 꽤 되는 미들웨어 시스템이 있다. 그리고 이 시스템은 매번 호출 될 때마다 상세한 호출 로그를 남긴다.  마치 SQL Server의 프로파일러 마냥...

중요한 건 특별한 상황이 아니면 이 로그는 거의 볼 일이 없다는 것이다.

시스템이 오픈 된 초반에는 많이 참고하지만, 어느정도 안정성이 확보된 이후에는 특별히 사고나 나지 않는 이상 들여다 볼일이 거의 없다.

문득... 보지도 않는 이 많은 로그를 저장하는게 비효율적이라는 생각이 들었다.

그래서 보통 다른 산업에서 적용하고 있는 '표본조사'가 떠올랐다.

어느 제품을 생산하는 라인에서 매번 높은 수준의 전수 조사를 하게 되면 효과에 비해 비용이 너무 많이 들게 된다. 그래서 생산품 중 일부를 표본적으로 조사하는 방식이 이용되는데 로그저장도 이와 같은 개념을 접목시키면 좋겠다는 생각이 들었다.

즉, 매 50번째 마다 호출로그 남기기!!!

물론 이런 산업에서는 생산과정이 항상 일관되고 특별한 외부 요인이 개입되지 않는 환경 즉, 생산의 표준화가 보장된 상태여야 하는 전제조건이 있긴 하다.

따라서 표본적으로 로그 수집을 하는 경우에도 오류로그는 매번 발생할 때마다 남기는 것이 권장될 것이다.

결론적으로, 일반적인 로그는 표본로그로 오류 로그는 전수로그로 남기는 것이 핵심!!!

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

공학의 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. 쿠퍼 저