Software Engineer'Story 2017 Part II.

1. 2017/06/28 08:30 http://blog.naver.com/knix008/221039170497
[ 바뀌는 것은 사람이지 일이 아니다. ][ 바뀌는 것은 사람이지 일이 아니다. ]
낙서장(2017)낙서장(2017)
일은 바뀌지 않고 그 일을 하는 사람만 바뀔 뿐이다. 일을 수행하는 방법을 바뀌기 위해서는 그 일을 직접적으로 하게되는
사람을 바꾸는 것이 가장 쉬운 방법이다. 일 자체를 바꾸는 것은 경험이나 지식이 큰 폭으로 변경 되기에, 새로운 사람으로
하는 것이나 거의 마찬가지다. 하지만, 일은 그냥 두고 방법을 바꾸는 것은 사람의 생각과 경험에 충격을 준다. 따라서, 첫
대응 방법은 "저항"의 형태로 갈 수 밖에 없다. 아무리 일을 잘하는 사람이라도 자신이 하고 있던 방식에 변화를 주려고 하
면, 일단은 그 방법의 좋고 나쁨을 떠나 거부 반응을 보이는 것이 일반적이다. 만약, 그 방법이 이해가 되지 않고 정당한 이
유가 없거나 위로 부터의 강압적인 분위기가 생성되면, 마지 못해 따르는 척은 한다. 하지만, 그 일에 대한 책임이나 내용
의 충실함은 없어지게 되며, 가장 간단하게 상황을 모면할 수 있는 부분만을 고려할 것이다. 근본적인 변화는 일이 아니고,
일을 하는 방법을 제대로 수행할 수 있는 사람을 변화시키는 것이다. 그리고, 사람에게 변화를 일으키는 것이 어쩌면 가장
힘든 부분일지도 모른다. 일은 바뀌지 않더라도 그 일을 수행하는 사람이 바뀌면 결과는 당연히 다를 수 밖에 없는 것이다.
변화는 사람이 만든다. 따라서, 어떤 일의 결과가 좋지 않았다면, 변화를 주어야 할 부분은 사람의 행동 양식에서 찾아야
할 것이다. 아무리 좋은 체계를 구축하고 있더라도 그것을 따르지 않으면 그만이다. 실수를 방지하고 싶다면 사람이 흔히
하는 실수의 형태를 보고, 그것을 예방할 수 있는 방법을 설계해야 한다. 지속적인 과제 지연이 발생하고 있다면, 이것 역
시 사람에게서 원인을 찾아야 한다. 물론, 개발자에 한정된 말은 아니다. 조직을 관리하는 사람의 지나친 욕심이거나, 개발
자의 잘못된 판단도 원인이 있을 수 있다. 잘못된 방법론을 지속적으로 사용한다면, 잘못된 결과만이 나올 뿐이다. 물론,
한번에 그 모든 것을 변화시키는 것이 불가능할 수도 있다. 따라서, 작은 행동의 변화를 유도하는 것 부터 시작하는 것이
좋다. 예를 들어, 반드시 일한 결과에 대한 검토 회의를 짧게라도 가질 수 있다면, "완료(Done)"라고 하기전에 한번쯤은
다시 생각해 볼 수 있다. 일을 하는 방식을 조금 바꾸면 생각이 바뀔수도 있다. 즉, 경험이 바뀌기에 시도 자체를 안하는 것
보다는 좋다. 사람은 경험한 부분에 대해서는 익숙하다고 생각하지만, 그렇지 않은 부분에 대해서는 시도 자체를 두려워하
기 때문이다. 마치 실패란 자신의 사전에서는 정의되지 않는 단어인양 행동한다. 하지만, 우린 이미 아주 많은 실패의 유산
위에서 살아가고 있을 뿐이다.
1 · [ 프로페셔널 프로그래머 ]

2. 변화를 일으키기 위해서는 측정과 분석이 필요하다. 측정하지 못하면 무엇이 얼마나 잘못되었는지 모르며, 개선한 이후에
도 얼마나 좋아졌는 지를 알 수 없다. 물론, 잘못된 지표를 가지고 측정하는 것은 옳은 방법이 아니다. 하지만, 그렇게라도
측정을 시작했다는 것은 중요한 발전이라고 생각할 수 있다. 변화와 그것에 영향을 받은 변수들의 움직임을 알 수 있다면,
어떤 식으로 더 변화를 일으켜야 하는지 알 수 있게된다. 완전한 측정이 불가능하다면 일단은 측정할 수 있는 것들이라도
시작해야 한다. 사람은 데이터를 보다는 자신의 느낌을 더 믿는 편이지만, 개선의 시작은 정확한 위치와 근거가 필요하다.
즉, 막연히 감을 가지고 이야기 한다면 감정적인 골이 깊어질 수 있지만, 객관화된 데이터를 참고하면 신뢰를 높일 수 있
다. 믿음이 간다고 생각되면 사람은 행동을 변화시킬 수 있는 충분한 동기를 얻게된다. 타당한 이야기를 무시할 수 있는 사
람은 없다. 논리가 없는 비약을 통해서 일하던 사람들도 정확한 데이터 분석과 그에 맞는 개선 예상 결과를 받아든다면, 행
동을 변화시킬 수 있는 충분한 조건은 가지게 되는 것이다. 따라서, 분석과 측정을 하더라도 결국 그 결과를 해석하고 행동
으로 만들기 위해서는 사람을 이해시켜야 한다. 막연한 감에 의존하기 보다는 논리적인 근거가 설득에 유리하며, 설득이
가능한 사람이라면 행동 변화는 당연히 따라오는 결과일 뿐이다. 문제는 설득보다는 주먹의 논리를 앞세우는 현실론자들
의 의견이다.
어떤 일이 지속적으로 문제를 겪고 있다면, 현실은 그 문제의 원인보다는 증상을 완화하는데 치우치기 쉽다. 일정이 짧아
서 일을 못하는 것이 아니라, 일을 하더라도 품질 수준을 못맞추는 형태로 진행하게 된다. 당연히 다음번 과제를 하더라도
품질 수준은 높아지지 않는다. 급하게 만든 해결책은 당분간의 면책을 줄지는 모르지만, 장기적인 관점에서는 부담으로 작
용할 뿐이다. 사람을 바꾸기 위해서는 원인에 치중하는 것이 더 좋은 결과를 낳는다. 증상의 완화를 중요시하면 우회하는
방법만 강조하게 된다. 따라서, 언제든 문제는 다시 재발할 위험을 가지고 있는 것이다. 조금만 변화를 주더라도 문제가 다
발로 나오는 경우가 그 예다. 원인을 찾기 어렵다면, 아예 그 상황을 만나지 않도록 만들수도 있다. 하지만, 거기까지 가는
길을 찾는 것도 어려운 경우가 많다. 따라서, 시간이 조금 더 걸리더라도 될 수 있으면 원인에 치중한 방안을 만들어야 내
야하며, 그것이 주어진 상황에서 하기 어려운 경우에는 일단은 완화를 목적으로 해야 할 것이다. 하지만, 절대 그 문제를
2 · [ 프로페셔널 프로그래머 ]

3. 잊어서는 안된다. 부족한 시간이라도 원인을 지속적으로 파악하려고 노력해야 한다. 사람의 변화를 만들기 위해서는 "왜
(Why)"라는 질문을 던질 줄 알아야 하며, 그것을 통해서 더 많은 사실을 밝혀내고 깨닫는 과정이 필요하다. 원인이란 결국
동기를 만들기 위한 조건이며, 그것을 알 수 있어야 행동의 변화로 이어지게 된다. 그냥 하라고 시키면 하는 것이 아니라,
"왜 그렇게 해야하지?"라는 질문에 대한 답을 찾아야 한다.
- 결과를 만들고 싶다면 사람을 보라.-
3 · [ 프로페셔널 프로그래머 ]

4. 2017/06/29 08:29 http://blog.naver.com/knix008/221039974080
[ 설계는 왜하지? ][ 설계는 왜하지? ]
낙서장(2017)낙서장(2017)
무엇을 만들 때 우리는 그것을 어떻게 만들지를 먼저 고민하게 된다. 어떤 모양과 크기, 색깔을 가져야하고, 어떤 재료를
사용해서 만들지도 결정하게 된다. 결정에 영향을 주는 것은 만들 재료의 값도 있고, 사용하는 목적에 맞도록 만드는 것도
중요하게 생각할 것이고, 당연히 필요한 시기에 만들어 내기 위해서 일정 계획도 수립할 것이다. 물론, 그렇다고 모든 것을
그런 식으로 만들지는 않겠지만, 적어도 개인이 혼자서 사용하는 이상의 가치를 가지도록 만들기 위해서는 다양한 부분들
을 고려해야 한다. 종이 접기를 하더라도 누군가가 이미 만들어 놓은 것을 참고하거나, 설계와 같은 것을 머리속에 떠올려
보고 시작할 것이다. 손에 익숙하면 거침없이 그냥 접기를 시작하겠지만, 그 정도 수준이 되기까지 필요했던 시행 착오와
경험이 손발을 움직이게 만들어 줄 것이다. 하지만, 이때도 중요한 것은 과정이며, 그 과정이 제대로 완료되었다는 것을 확
인하지 않으면 다음 과정으로는 넘어가지 않는다. 그것이 제대로 되었다는 것은 머리 속에 있는 그림(Image)와 비교해서
검증되는 것이다. 따라서, 설계란 대부분의 일에 앞서 진행되어야 할 "큰 그림"과 같다고 생각해 볼 수 있다. 물론, 자세한
그림은 다음 단계에서 조금씩 더 추가될 것이지만, 대략적으로 만들어야 할 시스템에 대한 구성 요소와 그들간의 관계, 그
리고 속성들을 정의할 수준은 되어야 한다.
설계의 목적은 주요 결정에 대한 근거를 제공한다. 즉, 설계는 앞으로 구현에서 나올 수 있는 각종 물음에 대한 답을 찾는
과정이다. 따라서, 상세 디자인이나 구현, 테스트 등에 대해서 "이유"를 설명할 수 있게 되는 것이다. 개집을 만들 때는 설
계가 필요하지 않은 경우도 있다. 이는 설계 과정이 없는 것이 아니라, 마음 속에 이미 완전한 개집의 도안이 있기 때문이
다. 따라서, 누가 만들더라도 적어도 주어진 재료에 따라 차이는 있겠지만, 거의 비슷한 형태의 개집을 만들게 된다. 하지
만, 이때도 각종 수치나 부품들이 어떻게 결합되어야 하는지에 대한 관계는 있을 수 있다. 또한, 각각의 부품이 가져야 할
재질과 다른 부품과의 연결 고리는 정해져 있는 것이다. 소프트웨어 개발이 적어도 개집을 만드는 것보다는 복잡하다는 것
은 다 이해할 것이다. 개집을 만드는데로 다양한 설계 활동들(마음속 이미지 만들기, 재료 구하기, 수치 정하기, 부품 가공
방법, 부품 결합, 검사 방법 정하기 등등)이 있다면, 소프트웨어를 만드는 과정에는 그 이상의 활동들이 필요하다는 것을
이해할 수 있을 것이다. 설계 결정이 변경되는 경우도 있다. 가능한 설계 변경을 줄이기 위해서는 다양한 시뮬레이션을 수
행해야 하고, 대안을 만들어서 각각을 평가해야 한다. 이런 과정들을 거치지 않는다면, 결정에 대한 근거가 희박해지며, 결
과적으로 설계와 상세 디자인, 구현, 테스트 등등이 분리된 활동으로만 인식될 것이다. 사실 이런 모든 활동들은 설계를 구
체화 시켜나가는 과정이며, 만약 오류가 있다고 생각된다면, 다시 설계를 수정하고 결정의 근거를 탄탄하게 만들수 있는
"빠른 실패"전략을 도입해야 할 것이다.
4 · [ 프로페셔널 프로그래머 ]

5. 소프트웨어 설계의 주요 내용은 "구성요소의 식별, 관계 설정, 내부 속성 파악"으로 요약해 볼 수 있다. 즉, 만들고자 하는
시스템을 구성하는 요소들에는 무엇이 있으며, 각각은 어떤 역할을 해야하고, 책임 범위는 어디까지 할 것인지를 정하는
것이다. 문제는 어떤 요소들이 필요한지를 정하는 부분이다. 이는 설계의 주요 입력인 "요구사항 분석 결과"로 부터 나오
게 된다. 즉, 무엇을 만들어야 하는지 파악한 이후에 그것을 만족시키기 위해서 필요한 구성요소들이 도출될 수 있는 것이
다. 예를 들어, "시스템은 인터넷을 이용해서 사용자 데이터를 전송한다"라고 했을 때(구체적이지는 않지만), 인터넷 연결
을 위한 구성 요소, 사용자 데이터를 다루는 구성요소 등이 파악될 수 있으며, 좀 더 세밀하게 들어가면, 사용자 입력을 위
한 부분, 인터넷 연결을 위한 소켓 구조와 함수들, 다양한 연결을 가정한 각종 드라이버 인터페이스들이 필요하다는 것을
알 수 있을 것이다. 이들 간의 관계를 표현해서 무엇이 무엇을 이용하고, 무엇이 무엇을 서비스 해주는가를 정하면 된다.
내부 속성은 그들이 가져야 할 값들을 의미하며, 역할을 수행함에 있어서 필요한 자료구조나 인터페이스를 말한다. 인터페
이스는 외부에서 부품을 사용하기 위해서 제공되어야 할 부분이며, 자료구조는 내부에서 이용하기 위해서 유지되는 값이
다. 나누는 일을 할 때 주의해야 하는 부분은 역할을 너무 폭넓게 정하거나, 혹은 너무 상세하게 정하는 것이다. 설계 수준
이 깊어지면 구현 수준에 도달하게 되며, 잦은 반복을 통해서 조금씩 더 상세하게(Detail) 깊이 들어가는 것이 좋다. 역할
과 책임은 항상 중요한 나누기 방법의 기준이며, 계층화는 의존성을 줄이고 변화를 수용하기 위한 기초다.
제대로 일하려면 설계는 반드시 해야한다. 설계 활동 자체는 만들기 전에 밝혀 낼 수 있는 것들에 대한 판단(결정) 근거를
제공함과 더불어, 재작업 가능성을 줄일 수 있는 토대를 제공한다. 설계 없이 상세 디자인을 하거나 구현으로 들어가면, 각
종 결정에 대한 근거가 부족하게 될 수 밖에 없다. 따라서, 아무리 많은 코드를 작성한다고 해서 그것이 시스템이 원하는
5 · [ 프로페셔널 프로그래머 ]

6. 목적을 수행하는데 도움을 줄 수 있다고 판단할 수 없다. 재작업 자체는 낭비이며 가능한 줄이는 것이 과제에는 도움이 된
다. 일정이 부족해서 설계를 할 수 없다고 이야기 한다면, "우물에서 숭늉 찾기"와 같은 일을 할 수 밖에 없다. 재작업 할 시
간은 물론 항상 주어지지만, 그로 인해서 발생하는 많은 비용들(과제 지연도 포함해서)은 과제 일정에 더 많은 영향을 주게
된다. 개집을 만든 후에 잘못된 부분을 발견한다면 다시 뜯어서 고칠 수 있지만, 아파트를 지은 후에 구조적인 결함을 발견
한다면 그 곳에서 살게되는 주민들의 불편은 누가 책임질 것인가? 다시 다 뜯어서 고치는 것은 가능하겠지만, 건설 업체에
대한 평판은 나빠지게 된다. 설계는 반드시 필요한 과정이며, 설계의 정도는 달라질 수 있을지 모르지만, 적어도 무엇이 시
스템을 이루고 있고, 어떤 관계를 가져야 원하는 목적을 달성할 수 있는지를 파악할 수는 있어야 한다. 우리가 만드는 제품
이 사용자의 목적에 맞게 만들어지고 있는지를 확인하지 않고서 만든다면, 당연히 제품의 경쟁력은 약해질 수 밖에 없다.
그런 제품은 아무리 많이 만들어봐야 시장에서 팔리지 않는다(혹은, 낮은 가격을 생성할 뿐이다). 이런 일이 반복적으로
이루어 진다면, 일은 많은데 정작 손에 쥐게되는 돈은 줄어들 것이 분명하다. 어떤 일을 하더라도 설계는 필요한 과정이며,
제 때 실행하는 것이 조금이라도 비용을 줄여 준다.
- 설계 없이 구현하는 것은 종이 접기 보다 못한 선택이다.-
6 · [ 프로페셔널 프로그래머 ]

7. 2017/07/01 09:49 http://blog.naver.com/knix008/221041562066
[ 언제까지 프로그램하고 살지? ][ 언제까지 프로그램하고 살지? ]
낙서장(2017)낙서장(2017)
개발자로 코딩하는 기간은 얼마나 될까? 대부분의 개발자는 나이가 들면 코딩보다는 관리업무로 전환하는 경우가 많다.
우리나라에서는 개발자가 코딩만 하고 살수 있는 상황이 못된다. 과제를 관리하는 것과 개발자로 일하는 것을 병행하도록
강요받다가, 코딩을 멈추고 관리자로 일하는 단계로 변해간다. 몇 몇 회사의 경우에는 개발과 관리 업무를 나누고 있지만,
다른 회사들은 개발자과 관리자가 되는 것이 일반적인 현상이다. 따라서, 대략 40대 정도가 되면 개발자의 삶은 끝나고 관
리자로 일하게 된다. 물론, 이것을 좋아하지 않거나 체질적으로 싫어하는 사람들도 있다. 남 앞에 나서거나 관리적으로 해
야하는 업무에 대한 거부감을 가지고 있는 사람들은 의외로 많다. 따라서, 그런 사람들을 위한 기회 부여는 현실적으로 힘
든 경우가 많으며, 기술을 모르는 관리자를 두기도 어렵다. 관리자 역할을 맡은 사람과 개발 경험이 많은 사람이 같이 어울
리기는 힘들다는 것이다. 역할의 차이일 뿐이지만 같이 일하는 상황에서는 힘겨루기 형태가 될 수 있기 때문이다. 이는 팀
에 역할이 존재하는 것이 아니라 직위가 더 우선시 되기 때문이다. 예를 들어, 회사의 장래를 위해서는 특정 지식을 가진
경험이 많은 사람이 필요하지만, 그 사람을 뽑아서 생기는 각종 승진이나 평가, 팀 구성의 변경등에 대해서 거부감을 가진
관리자가 있을 수 있다. 이런 상황에서는 회사보다는 자신의 조직입장이 우선시 고려되며, 결과적으로 회사에는 도움이 되
지않는 경정이 내려지기도 한다. 역할과 책임의 혼재는 개발자로서 살고자 하더라도, 관리자로 넘어갈 수 밖에 없는 현실
을 만들고 있는 것이다.
프로그래머는 코딩을 할 수 있어야 한다. 비록 관리자가 되어 코딩에서 손이 멀어지더라도 항상 코드와 가까이에 있어야
한다. 한번 멀어지고 손을 놓게 되면 다시 하는 것은 쉽지 않다. 시간이 없어서 코딩을 못한다는 말은 하지 않아야 한다. 적
어도 개발자 백그라운드를 가지고 있다면, 시간이 없어서 코드를 멀리해선 안된다. 짧은 시간이라도 꾸준히 코드를 입력하
고 실행할 수 있는 능력을 갖추고 있어야 한다. 최신 기술을 익히는 것이 어려울지도 모르지만, 하루에 적어도 한 시간 정
도는 코드를 직접 하는 것이 중요하다. 자신이 다니는 회사가 언제 문닫을 지도 모르고, 다른 더 좋은 기회가 다가올 수도
있다. 물론, 나이든 개발자를 뽑는 곳은 그렇게 많지 않을지도 모른다. 하지만, 하려는 마음이 있다면 그런 것은 문제가 되
지 않는다. 외국계 회사를 갈 수도 있고, 자신만의 취미 생활을 창업의 기회로 활용할 수도 있다. 세상에 나오는 모든 새로
운 언어를 배우기 보다는 우산처럼 넓혀 나갈 수 있는 언어를 배우는 것이 유리하다. 다양한 언어와의 결합이 가능하고, 이
미 만들어진 기반을 활용할 수 있는 언어라면 좋을 것이다. 특정 시류에 같이 떠내려 가다가는 배우는 동안 새로운 흐름이
만들어진다. 어쨌든 중요한 것은 코드를 손에서 놓지 않는 것이며, 개발자의 변화되는 환경에 대해서 꾸준히 익히는 것이
관리자를 하는데도 도움이 된다. 개발과 동떨어진 과제 관리란 없으며, 기술을 이해하지 못하고 어떻게 구현하는 지를 알
지 못한다면, 엉뚱한 곳에서 뛰어난 후배들의 뒷다리를 잡을지도 모르기 때문이다.
7 · [ 프로페셔널 프로그래머 ]

8. 나이가 들어서 코딩하는 것은 젊었을 때와는 달라져야 한다. 적어도 코드를 빨리 만들기 보다 제대로 만든데 집중할 수 있
어야 한다. "제대로 코딩하기"가 다양한 의견으로 나뉠수는 있지만, 일반적으로 올바르다고 생각되는 것들은 존재한다. 그
것을 기준으로 자신의 코드를 객관적으로 바라볼 수 있어야 한다. 언제까지 코딩할 수 있을지는 모르지만, 그래도 할 수 있
는 기회가 주어지기를 기다리기 보다는 찾아서 해야 할 것이다. 물론, 과제에서 직접 코딩을 담당할 수도 있겠지만, 관리자
역할을 한다면 일단은 중요한 코드는 만지려고 해선 안된다. 오히려 코드를 읽으면서 좋은 방향을 제시할 수 있는 역할이
더 중요할 수도 있다. 코드를 직접 작성하는 것도 좋지만, 다른 사람의 코드를 자주 보고 코칭해 주는 것도 코딩 만큼이나
중요한 활동이다. 적어도 코드를 이해하고 생각을 코드화 시키는 방법에 대해서는 경험이 많은 사람이 더 유리할 수 밖에
없다. 신입 개발자들이 제대로 가르침을 받지 못하게 되면, 직위가 올라가도 발전하지 않는다. 물론, 혼자서 익힐 수도 있
지만 한계가 있을 수 밖에 없다. 따라서, 선배로서 코딩에 대한 경험을 나누어주는 것은 일의 영속성을 위해서도 중요하며,
결국 관리자 자리에서 얻을 수 있는 성과를 높이는데도 좋은 방법이 된다. 관리자는 자신이 직접 일을 해서 얻는 성과를 가
져가는 것이 아니라, 남들을 시켜서 일하게 만들 수 밖에 없다. 따라서, 성과는 남을 통해서 이루는 것이지, 자신이 직접 만
들지 못한다. 좋은 관리자라면 적어도 행정적인 관리(회의, 보고서 작성, 일정관리, 면담, 술자리 등등)만을 하지는 않을 것
이다. 개발자와 가장 가까이 있기 위해서는 코드를 통해서 대화를 나눌 수 있어야만 한다.
프로그래밍에 나이 제한은 없다. 지속적인 향상이 있을 뿐이지 멈춤은 없다. 관리자의 길로 빠져들이 코드에서 멀어지면,
나중에 다시 돌아오는 길은 길고 외로울 것이다. 물론, "말빨"로 살아남아 퇴직을 할 때까지 일할 수도 있을 것이다. 하지
만, 실무 개발자들과 생각을 나누는데는 한계가 생기게 되며, 겉으로만 이해하는 길을 가게 될 것이다. 시간이 없어서 코딩
하지 못하는 것이 아니라, 마음에서 멀어졌기에 손을 놓을 뿐이다. 최신의 개발 흐름을 이해하지 못하면 예전의 사고 방식
으로 현실을 바라보게 되며, 새로운 것 보다는 지켜야할 것들로 눈을 돌리게 된다. 새로운 것은 두려움의 실체이며, 과거란
항상 만족감의 원천으로 작용할 것이다. 두고온 것이 많은 사람은 새로운 것을 잡을 손이 없다. 버려야 새로운 것을 움겨
쥘 수 있다. 새로운 언어를 배우고 새로운 개념을 익히는 것도 중요하지만, 기존에 알던 지식들을 더 체계적으로 가꾸려고
8 · [ 프로페셔널 프로그래머 ]

9. 노력해야 한다. 빨리하기 보다는 바르게 하기로 옮겨가야 하며, 남들이 하니까 따라하기 보다는 이유를 알려고 노력해야
한다. 이런 것들이 자신이 해야하는 일이 아니라고 생각한다면, 더 이상 개발자에게 자신의 생각을 강요해선 안된다. 오히
려 개발자들이 자신의 생각을 펼칠 수 있도록 도움을 주는 일에 집중해야 할 것이다. 어떤 일에 대한 결론을 성급하게 내리
도록 만들 것이 아니라, 개발자들이 더 좋은 환경에서 일할 수 있도록 만들어 주어야 할 것이다. 관리자가 되고 싶은 개발
자라면 적어도 개발에서 겪는 어려움 들을 해결할 수 있는 방법을 찾아야 하며 그것이 진정한 관리다. 말로 일하고 파워포
인트나 워드로 코딩하는 사람이 관리자는 아니다. 모든 사람이 개발자로 남지 않듯이, 모든 사람이 관리자가 되지도 않는
다. 각각은 마주 바라보는 곳에서 서로에게 도움을 주고 받는 사이가 되어야 하는 것이다.
- 내 직위보다 능력을 더 믿어주는 사람을 찾는 것이 전체를 위해서는 더 좋을 결과를 만든다. -
9 · [ 프로페셔널 프로그래머 ]

10. 2017/07/02 11:14 http://blog.naver.com/knix008/221042144979
[ 객체지향은 생각을 정리하는 한가지 방법이다. ][ 객체지향은 생각을 정리하는 한가지 방법이다. ]
낙서장(2017)낙서장(2017)
사물이나 현실을 바라보는 방법에는 여러가지가 있을 수 있다. 이는 근본적으로 인간이 가지는 한계를 나타내며, 내면의
진리를 보지 못하는 것에 기인한다. 따라서, 어떤 사물이나 현실을 알기 위해서는 다양한 방법으로 관찰할 수 밖에 없으며,
그렇다고 해도 내재된 특성의 일부만을 파악할 수 있을 뿐이다. 마치 "장님 코끼리 만지기"처럼 다양한 경험을 하고, 그 모
든 경험을 합쳐서 지금까지 관찰한 사물이나 현상에 대한 정의를 내리는 것이다. 물론, 이것도 완전한 것은 아니다. 모든
측면에서 관찰하는 것은 사실상 불가능하기 때문이다. 절차지향이나 객체지향도 마찬가지다. 그것들 역시 우리가 해결하
고자 하는 문제를 바라보는 하나의 시각일 뿐이다. 무엇이 옳고 무엇이 그렇지 않은가를 따지는 것이 아니라, 단순히 시각
이 다를 뿐이다. 그리고, 새로운 관찰 방법은 기존의 방법을 개선해서 더 효과적인 것을 만들어 내기 위한 과도기에 해당하
며, 끝없이 개선되어 나갈 것이 분명하다. 언제나가는 그런 모든 관찰 방법을 합친 새로운 관찰법이 나올지도 모른다. 그리
고, 그것 역시도 완전한 형태는 아닐 것이 분명하다. 하지만, 이때도 분명한 사실은 존재한다. 즉, 조금씩이지만 우리의 생
각이 지속적으로 진보하고 있다는 것이며, 결과적으로 진실을 보는 눈도 점점더 정교해지고 있다는 것이다. 목적지가 어디
에 있는지는 알지 못하지만, 꾸준히 나아가고 있다는 것은 확실하다.
객체지향은 객체들간의 소통으로 문제를 해결한다. 절차지향은 일을 실행하는 순서를 나열하는 방법이며, 필요한 단계에
필요한 자료구조와 실행되어야 할 함수의 나열로 만들어진다. 객체도 물론 실행되는 순서는 있으며, 생성과 소멸시에 자동
으로(혹은, 수동으로) 실행되는 부분도 존재한다. 하지만, 객체지향은 일을 하는 순서에 초점을 두고 코딩하는 것이 아니
라, 누가 무슨 역할을 수행해야 하는가에 중점을 두고 있다. 즉, 그 일이 어떻게 처리 될지는 구체적으로 알지 못하지만, 그
일을 할 수 있는 다른 객체의 존재는 알고 있다. 시스템을 구성하는 요소를 크게 구분해서 모듈이나 서브 시스템, 혹은 컴
포넌트로 나눈다면, 그것 자체가 큰 객체라고 생각해 볼 수도 있다. 내부에는 다시 작은 객체들로 구성된 서브 모듈이나,
서브 컴포넌트 등이 존재할 것이고, 다시 더 작게 나누어지는 상위에서 하위로 계층적인 구조를 가질 수 있을 것이다. 즉,
객체는 자신이 특정 역할을 수행하기 위해서 필요한 완결된 존재로 남아야 한다. 내부의 상태를 기록할 수 있어야 하며, 외
부와 통신할 수 있는 방법 및 내부에서 사용할 수 있는 행위들을 가지고 있다. 객체들간의 관계는 사용, 소유, 일반화, 특수
화, 내포, 합성등의 관계를 가질 수 있으며, 이는 객체를 더 작게 나누거나 관계를 만들어주기 위해서 사용한다. 이때 중요
한 점은 자신에게 할당된 역할이 아니라면, 다른 객체를 찾아서 권한을 위임해 주어야 한다는 것이다. 위임은 소통의 한 방
법이며, 권한과 책임을 확인하는 과정인 것이다.
10 · [ 프로페셔널 프로그래머 ]

11. 객체지향은 재사용을 위해서 만들었지만, 세상을 묘사하기에 더 적당한 모델이다. 물론, 재사용이 중요하지 않다는 것은
아니다. 하지만, 세상은 객체들의 모임이며, 서로 주고 받는 것을 통해서 생태를 만들고 있는 것이다. 그렇다고 실체를 가
진 것 만이 객체로 존재할 수 있는 것은 아니다. 우리는 추상적인 개념도 마치 객체로 다룰 수 있는 능력을 가진 사람이기
때문이다. 필요한 부분만을 끄집어내고 그렇지 않은 부분들을 과감하게 생략할 수 있는 능력도 사람은 즐겨 사용한다. 모
델이란 그런 과정을 통해서 만들어지며, 추상화란 구체적인 사실을 하나씩 다루기 보다는 한번에 묶어서 개념화 시킬 수
있는 방법을 제공한다. 따라서, 세상을 추상적으로 바라보며 서로 연결된 객체들이 문제를 해결하기 위해서 협력하는 모델
로 다룰 수 있게 된다. 객체들의 공통된 특성을 뽑아내서 다른 객체를 생성하는데 재사용하기 위한 방법으로 클래스가 만
들어 졌으며, 클래스는 객체를 위한 틀을 제공하기 위해서 속성과 행위를 정의할 수 있다. 물론, 그런 정의를 반드시 필요
로 하지 않는 경우도 있으며, 이는 그냥 단순히 무엇이 공통적인 것인가만 표현하기 위한 방법이다. 즉, 추상적으로 객체들
의 공통 특성을 묶어 주기 위해서도 클래스는 정의할 수 있다. 클래스와 클래스의 관계는 그 클래스를 틀로 사용하는 객체
들의 관계를 만들기 위해서 활용될 수 있으며, 같은 클래스에 속하는 객체들은 같은 방법으로 사용할 수 있도록 공통된 행
위를 계약으로 만들기도 한다. 따라서, 우리는 클래스를 생각하기에 앞서 먼저 객체를 생각해야 하고, 그 객체를 만들어내
기 위해서 클래스를 선언하는 것을 선택하게 되는 것이다. 물론, 코딩은 클래스를 먼저 만들기를 원하지만, 설계는 객체에
서 시작해서 클래스로 올라가야 할 것이다.
객체는 존재를 구분짓는 방법이며 인식의 기반을 제공한다. 존재는 반드시 사물일 필요는 없으며, 개념을 인식해서 다룰
수 있는 수준이면 충분하다. 우린 이미 이런 것들을 많이 고안해 냈으며, 전혀 새로운 일을 컴퓨터 프로그래밍에 도입하려
고 시도한 것은 아니다. 일의 처리를 순차적인 처리의 연결로 본 것은, 시간에 따라 일이 조작되어 상태가 변한다는 것을
표현하는 방법일 뿐이다. 즉, 입력으로 주어지는 것들이 있고, 이것을 주어진 자원과 역량을 이용해서 최종 결과물을 만들
어내는 것을 다룬 것이다. 마치 공장에서 만들어지고 있는 물건들이 이동하듯 생산되는 흐름을 표현한 것이다. 객체지향은
일의 주체를 객체로 정의하고 그들이 일의 흐름을 자유롭게 다룰 수 있도록 허락하는 방법이며, 각각의 객체는 스스로의
11 · [ 프로페셔널 프로그래머 ]

12. 책임과 역할을 만족시킬 뿐 그 이상은 다루지 않는다. 따라서, 객체들이 만족할 결과물을 만들어낼 때까지 스스로 판단할
수 밖에 없으며, 자신의 역할과 책임을 벗어난 일에 대해서는 다른 객체에 의존하는 것을 어렵지 않게 생각한다. 세상은 도
움을 주고 받을 수 있는 많은 관계들이 존재하며, 그것을 단순히 이용해서 원하는 일을 수행할 뿐이다. 즉, 자신의 역할에
만 충실 하기만 하면 일은 저절로 될 것이라는 것을 보장하는 것이다. 객체지향은 이미 우리 일상에 놓여있는 많은 것들에
내재된 특성이며, 사회 구조를 이루는 핵심도 독립된 객체들에 의한 협업으로 이루어져 있다. 따라서, 문제를 바라볼 때 순
서적인 것만을 고려하는 것이 나쁜 것은 아니지면, 조금 더 현실에 가깝게 다루기 위해서는 객체지향적인 사고를 가지는
것도 필요하다. 새로운 방법으로 사물을 바라본다고 해서 그 사물의 본질 자체는 변하지 않지만, 적어도 우리가 그 사물의
근본에는 조금 더 다가 섰다는 것을 느낄 수 있는, 충분한 근거를 만들어 낼 수 있을 것이다.
- 선택한 방법이 옳고 그름이 아니라, 적절한 지를 먼저 물어야 한다. -
12 · [ 프로페셔널 프로그래머 ]

13. 2017/07/03 08:22 http://blog.naver.com/knix008/221042661565
[ 객체는 행위의 주체가 되어야 한다. ][ 객체는 행위의 주체가 되어야 한다. ]
낙서장(2017)낙서장(2017)
객체는 속성(Attribute)과 행위(Behavior)를 가진다. 속성은 내부적으로 유지해야 할 상태를 말하며, 행위란 그 상태에서
할 수 있는 일을 지정한다. 다른 객체의 입장에서는 행위를 위탁하는 것으로 해당 객체가 가지고 있는 주체적으로 해야할
일을 실행하라는 요청(Request)을 보내게 된다. 보낸다는 의미에서 일종의 메시지(Message)라고 생각해 볼 수도 있으
며, 그 외의 다른 것으로는 해당 객쳬와 대화를 나눌 수 없기에 공개된(Public) 계약(Contract)라고도 할 수 있다. 즉, 해당
객체의 입장에서는 자신이 해주기로 약속한 일만 충실하게 수행하면 된다. 따라서, 객체가 가지는 행위의 계약이 너무 많
아지게 되면, 객체 자체가 커지게 되는 현상이 발생하며, 이는 객체의 역할이 모호하거나 다양한 역할을 한번에 가지게 되
는 원인이 될 수 있다. 따라서, 객체는 자신이 지켜야 할 계약에 대해서는 완전히 수행해야 하지만, 너무 큰 역할을 담당해
서는 곤란한 상황이 된다. 객체가 가지는 속성와 행위는 객체가 자신이 맡아서 해야할 일에 대한 주도권을 가지고 있을 때
만 온전할 수 있다. 물론, 내부에 자신이 관리하는 다른 객체를 가지더라도 외부에서는 그것을 알지 못하고 의뢰를 하게 되
는 것이다. 행위가 객체들의 묶음에 의해서 결정될 수도 있으며, 혹은 그 객체와 관련을 맺고 있는 다른 객체에 의해서 수
행되기도 하는 이유가 그 때문이다.
객체는 속성에 따른 행위를 반드시 가져야 한다. 단순히 데이터의 조합 만으로는 객체로서는 부족하다. 따라서, 이런 경우
가 발생한다면, 그 객체의 속성을 주로 사용하는 객체의 속성으로 옮겨주어야 할 것이다. 물론, 이런 과정을 통해서 옮겨진
객체가 커지거나 역할이 늘어날 수도 있다. 이때는 다시 옮겨진 객체를 나누어 더 작은 전문화된 객체로 만들어 주어야 한
다. 결국 객체는 자신이 유지해야 하는 상태와 그 상태에 해당하는 행위를 정의할 수 있어야. 한다. 즉, 객체 지향이란 서로
주체적인 입장에서 상대 객체와 대화(메시징)를 나누게 되며, 대화의 방법이나 순서, 혹은 내용 등을 정해서 주어진 문제
를 해결하는 과정을 설명하는 것이다. 객체가 행동의 주체가 된다는 것은 행위를 가진다는 뜻이 되며, 그 행위의 대상은 내
부의 속성이나 관련을 맺고 있는 다른 객체도 포함한다. 또한, 행위를 통해서만 객체는 상태를 변경할 수 있기에, 직접적인
외부 객체로 부터의 내부 속성 변경은 허락하지 않아야 할 것이다. 속성을 바꾸기 위한 직접적인 행위를 외부로 보여주기
보다는 다른 방식을 선호하는 것도 좋은 선택이다. 가능한 외부의 객체에서는 내부를 들여다보지 못하도록 제약을 강화시
키는 것이 객체들간의 독립성에 중요한 영향을 줄 수 있다. 참고로 상속도 일종의 제약이라고 볼 수 있지만, 상속을 통하게
되면 상속되는 선에 속한 객체들은 함께 영향을 받는 경향이 있기에 객체의 독립성에 악영향을 줄 수 있다.
13 · [ 프로페셔널 프로그래머 ]

14. 객체는 자신이 할 수 있는 일과 해야할 일을 명확히 정의해야 한다. 따라서, 그 외의 것을 하려고 시도하는 것은 옳지 않다.
이떄는 그 일에 해당하는 역할을 담당하는 다른 객체에게 요청을 보내야 할 것이다. 물론, 그 중간에서 조정하는 기능
(Adapter)이나, 혹은 대리자(Proxy)역할을 담당할 수는 있지만, 일 자체를 처리하는 것은 전문화된 객체에 의뢰하는 형식
이 된다. 자신이 잘 정의된 역할과 책임 범위를 가진다면, 적어도 어떤 일을 해야하는 지에 대해서는 명확한 계약을 만들어
낼 수 있다. 그렇지 못한 경우에는 모호하거나 혹은 너무 많은 수의 서로 관련이 떨어지는 계약들로 붐비게 된다. 잘 정의
된 역할을 만드는 것은 코딩보다는 설계에 가까우며, 미리 정의하지 않으면 구현에서는 혼선이 발생하게 된다. 그렇다고
그 상황을 개선하는 것이 불가능한 것은 아니지만, 코딩이란 가능한 빨리 완성하려는 속성을 가지기에, 좋은 구조를 선택
하는데신에 역할의 중복이나 확장을 손쉽게 선택한다. 이런 식의 구현이 지속되면 객체는 자신이 해야하는 일에 대한 범위
를 착각하게 되며, 자신의 역할과 관련이 없는 것 까지도 처리하려고 달려드는 상황이 된다. 물론, 이게 뭐가 나쁘냐고 이
야기 할지는 르겠지만, 그렇다고 올바른 상황이 아님은 명확하다. 즉, 변화의 이유에 대해서 한 곳에서만 수정되어야 할 코
드들이 여러 개의 객체로 나누어지거나, 혹은 너무 비대해 버린 객체만 시스템에 덩그러니 남게된다. 나중에 다시 수정하
려고 하면, 코드는 이미 너무 복잡해져 있어서 고치는 비용이 많이 들거나, 이해하기 어려운 상황에 직면하게 될 것이다.
객체는 시스템의 최소 구성요소이며 실행의 주체가 된다. 물론, 제어적인 측면에서 본다면, 모든 객체가 "프로세스
(Process)"가 되는 것은 아니다. 실행의 주체라는 측면은 논리적인 관점에서 이야기 하는 것이며, 제어는 프로그램이 실행
되는 스케줄링(Scheduling)의 최소 단위와 밀접한 관련을 가진다. 각각이 주체적으로 자신의 속성과 행위를 가지고 동작
하는 상황에서는 주어진 일을 처리하기 위해서 "협업"의 형태로 생각하는 것이 필수적이며, 절차의 의미로 해석하면 능동
14 · [ 프로페셔널 프로그래머 ]

15. 적인 부분은 "프로세스"와 같은 행위자만 남게 된다. 이는 언듯보면 이해하기는 쉬울지 몰라도, 객체지향적인 사고와는 어
울리지 않는다. 특정 언어를 통해서만 객체를 구현하는 것은 아니며, 어떤 언어를 사용하더라도 객체를 바라보는 관점이
과제의 코드 전반에 동일하게 유지되어야 한다. 설계는 이를 반영해서 구성요소들을 식별할 수 있어야 하며, 관계를 맺는
그림은 일을 처리하는 주체가 누구인가에 맞추어 연결을 만들어야 할 것이다. 단순히 객체지향 언어를 사용한다고 객체지
향 코드를 만드는 것은 아니며, 그 내면에 녹아 있는 "행위의 주체"를 이해 할 수 있어야 제대로 된 "객체지향적인 코드"가
만들어지는 것이다. 디자인 패턴은 중복을 제거하고 변경의 폭을 줄이기 위해서 사용하는 기술이지, 그 자체가 행위의 주
체를 만들어내는 것은 아니다. 또한, 동일한 문제 형태에 대한 일반적인 해결책을 제시하는 것이지, 그것이 객체지향 기술
의 전부는 아니다. 따라서, 객체라는 말을 정확히 이해하기 위해서는 "누가 무엇을 해야 할 것인가?"에 대한 관점에서 역
할과 책임을 한정된 부분으로 세밀하게 묶어야 제대로 된 구조를 발견할 수 있게되는 것이다.
- 객체는 자신이 맡은 역할에 대해서만 충실하면 된다. 욕심부릴 필요가 없다는 뜻이다. -
15 · [ 프로페셔널 프로그래머 ]

16. 2017/07/04 10:20 http://blog.naver.com/knix008/221043551673
[ 프로젝트를 절대 실패하지 않는 방법(?) ][ 프로젝트를 절대 실패하지 않는 방법(?) ]
낙서장(2017)낙서장(2017)
프로젝트를 절대 실패하지 않고 수행할 수 있는 방법은 모든 개발자들이 원하는 것이다. 그렇지만 아마도 대부분의 개발자
는 한번도 생각해 본 적이 없을 것이다. 간단히 말하면 과제를 기능 단위로 잘게 나누어서 하나의 기능 구현을 하나의 프로
젝트와 같이 실행 하라는 것이다. 따라서, "하나의 기능 구현이 완료 되었다는 것"에 대해서 높은 수준의 품질을 유지할 수
있는 방법을 찾아내는 것이 핵심이다. 각각의 구현된 기능들이 높은 수준의 품질을 만족시킬 수 있다면, 그 전체 합은 당연
히 높은 수준에 도달해 있을 것이다. 물론, 이렇게 말하면 거의 실패할 프로젝트들이 없다고 생각되지만, 실무에서는 이런
방법을 잘 사용하지 않는다. 왜일까? 그것은 아마도 일보다는 사람의 효율을 높이는데 초점을 맞추고 있다고 생각되며, 성
급한 실적내기를 원하고 있는 개발자의 불안감이 작용하기 때문이라고 보인다. 하지만, 정작 중요한 것은 결과물 자체이지
일을 완료 했다고 주어지는 성과가 아니다. 불안감은 기간내에 모든 기능을 개발해야 한다는 압박감의 표현일 뿐이지, 그
구현된 기능들이 제대로 사용된다고 보장해 주는 것은 아니다. 따라서, "실패하지 않는 개발"이란 우선 순위가 높은 기능
단위로 쪼개진 소규모 프로젝트의 반복된 완성이라고 정의할 수 있을 것이다.
프로젝트를 실패하는 이유는 한꺼번에 너무 많은 것을 하려고 욕심내기 때문이다. 한꺼번에 모든 기능을 구현하기 위해서
작게 나눈 모듈단위로 사람들에게 일을 할당하고, 각각이 구현된 모듈 들을 조금씩 이어 붙여가면서 과제를 진행하는 것이
일반적이다. 문제는 작게 나누어진 모듈 들이 각각의 사람을 통해서 구현되고 통합 되면서 꾸준히 문제를 일으킨다는 점이
다. 초기 및 잦은 통합을 전제로 개발 하더라도 중간에 발생하는 문제들을 해결하기 위해서는 어쩔 수 없는 오버헤드가 들
어가기 마련이다. 물론, 이정도의 오버헤드도 없이 개발되는 제품은 없을 것이다. 더 큰 문제는 통합이 되어 기능이 활성화
되기 전까지는 해당 기능에 대한 검증이 불가능하다는 것이다. 따라서, 개별 모듈 들이 완전히 구현되어 상위에서 하위까
지 통합된 상황이 아니면, 테스트는 과제의 후반으로 밀릴 수 밖에 없다. 그때가서 제대로 동작하지 않거나 버그가 있다는
이야기를 듣게되면, 어쩔 수 없이 근무강도를 높이는 방법으로 밖에는 해결할 수 없는 상황이 된다. 그리고, 그때 쯤 이면,
이미 충분히 열심히(?) 일하고 있는 상황이라 높일 수 있는 압박은 한계를 가질 수 밖에 없다. 수정되는 코드도 문제를 일
으키게 되며, 좋은 구조는 이미 물건너 간 상황이 되고마는 것이다. 따라서, 한번에 모든 기능을 구현해서 통합하려는 생각
을 멈춰야 과제가 실패하지 않는다.
프로젝트는 수평적으로 개발하는 것이 아니라, 수직적으로 개발되어야 한다. 즉, 초기부터 상위에서 하위까지 필요한 코드
들이 추가될 수 있도록 해야한다. 어떤 모듈의 전체 구현이 필요한 것이 아니라, 특정 기능을 구현할 수 있을 정도의 코드
만 있으면 된다. 예를 들어, 특정 기능을 구현하기 위해서 필요한 수직으로 나열된 모듈들이 있을 경우, 각각의 모듈들을
100%구현할 것이 아니라 그 기능에 필요한 부분만 구현하는 것이다. 물론, 각각의 구현은 내부적으로 개발자가 "단위 테
스트"나 "통합 테스트"를 통해서 일차적인 검증을 해야한다. 이때의 단위는 주로 "함수나 클래스"정도의 수준에서 검증될
것이며, 기능에 필요한 함수나 클래스 정도만 단위 검증을 해도 좋다. 모든 팀원들이 기능 단위로 작업을 하게 된다면, 상
16 · [ 프로페셔널 프로그래머 ]

17. 위 모듈에서 하위 모듈까지 필요한 부분만을 나누어서 구현하게 된다. 그렇게 구현된 기능들은 실제 기능이 동작하는 지를
기준으로 일의 완료 정의(DOD:Definition of Done)을 내릴 수 있게 되며, 자동화된 테스트를 이용할 경우에는 각종 커버
리지(Coverage) 데이터도 뽑아낼 수 있게 된다. 다음 기능을 위해서 미리 필요한 부분을 코딩할 필요는 없으며, 필요한 기
능이 있을 경우에만 코드로 만들어내는 것이 현명한 선택이다. 이것을 위해서는 주기적으로 커버리지 데이터를 분석할 필
요가 있을 것이다.
프로젝트는 작은 프로젝트로 만들어질 수록 성공 가능성이 높아진다. 가장 작은 프로젝트는 "논리적으로 분리되어 실행될
수 있는 단위"가 될 수 있다. 물론, 이때의 단위(Unit)이란 함수나 클래스가 그 대상이 될 것이다. 프로젝트 단위로는 작다
고 보지만, 개인이 수행하는 일의 단위로는 가장 최소 단위가 될 수 있기 때문이다. 따라서, "단위 수준에서의 일에 대한 완
료 정의"가 필요하게 되며, 단위 테스트는 그 한가지 방법이다. 이외에도 코딩 룰이나 코드 리뷰, 복잡도 분석, 중복 코드
검사, 자동화 여부, LoC(Line of Code), 파라미터 갯수 등의 측정치를 이용해서 외적인 품질 잣대를 정할 수도 있다. 즉,
정해진 기준을 마쳤을 때만 "구현(Implementation)"되었다고 보는 것이다. 작은 프로젝트는 일반적으로 성공 가능성이
높다는 것이 알려진 사실이며, 큰 프로젝트를 작게 여러개로 나누어서 실행하지 못할 이유는 전혀 없다. 큰 프로젝트 일 수
록 한번에 모든 것을 다 하는 것은 실패 가능성만 키울 뿐이다. 작은 프로젝트는 실패도 작으며(가장 작은 함수나 클래스
구현의 오류), 그것을 회복하는 시간도 빠르다. 큰 과제는 검증 피드백의 인터벌이 길어지기에, 실패하면 그대로 일정 지연
으로 연결될 가능성이 작은 프로젝트에 비해서 상대적으로 클 수 밖에 없다. 따라서, 일정 계획에 실패하지 않기 위해서라
도 과제는 작게 나누어져서 관리되는 것이 훨씬 더 유리하다.
프로젝트는 작을수록 더 관리하기 쉽다. 물론, 전체 프로젝트의 크기는 아주 클 수도 있지만, 오랜 시간을 할당해서 결과물
을 확인하기 위해서는 기다리는 시간도 길어지게 된다. 작은 프로젝트로 만들어서 일부 인력만 투입한다면, 주기적으로 결
과물을 쉽게 확인할 수 있다. 그렇다고 절대적으로 일에 필요한 시간을 줄이려고 노력하지 못한다는 것은 아니다. 예를 들
어, 10명이 1년동안 할 일을 30명이 반년내에 할 수는 있을 것이다. 하지만, 그렇다고 30명의 인력이 과제 초반부터 허락
17 · [ 프로페셔널 프로그래머 ]

18. 받을 수 있는 상황이 아닐수도 있다. 따라서, 초기에 어느 정도의 성과를 이루기 위해서는 작게 프로젝트를 만들어서 진행
할 수 밖에 없다. 나중에 투입되는 인력이 반드시 과제를 빨리 끝낼 수 있다고 보장하지는 않겠지만, 학습의 시간이 지나면
조금씩 성과를 보이는 것도 사실이다. 따라서, 작게 나누어진 프로젝트는 꾸준한 피드백과 순차적인 자원의 투입이 가능하
도록 만든데도 중요한 역할을 하게된다. 수평적으로 구현되고 통합되는 모델에 따라 과제를 진행하고 있다면, 새로운 인력
을 투입 했을때 지금까지 구현된 내용들을 파악하는데 만도 시간이 꽤 걸리는 일이된다. 기능 단위로 구현하는 작은 프로
젝트의 경우에는 항상 새로운 기능을 넣기 위해서는 새로운 코드를 구현하는 것이 더 많을 것이다.(물론, 기존의 코드를 공
용으로 사용할 수도 있지만). 결과를 확인하는데 기다리는 시간이 짧을수록 과제는 더 성공적으로 완료될 가능성이 커진
다고 볼 수 있다.
프로젝트는 크기가 클수록 실패할 가능성도 늘어나게 된다. 어떤 크기이하로 만들어야 프로젝트가 성공할 것인가는 처한
상황에 따라 다르겠지만, "7+-2"라는 법칙을 이용할 경우 최대 9명이 한달 동안 구현할 수 있을 정도의 크기로 구현해야
할 기능들을 나누는 것이 좋을 것이다. 이렇게 나누어진 기능들은 우선 순위가 높은 것을 먼저 구현해야 하며, 반드시 완료
조건을 높이 잡아야 한다. 개인 별로는 자신이 구현한 코드의 함수나 클래스의 완료 조건에 대해서 명시적인 값을 보여줄
수 있어야 하며, 단위 테스트나 기타 분석툴을 이용한 시각화는 좋은 완료조건을 제공해 줄 수 있을 것이다. 여기서 한가지
더 중요한 것은 과제의 성공을 단순히 "All or Nothing"으로 보지 않는 것이다. 즉, 성공과 실패로 나누어진 이진(Binary)
적인 사고가 아니라, 아날로그 값과 같이 연속적인 과정으로 바라보아야 한다. 구현된 기능의 가치를 놓고 생각해보면, 그
기능이 벌어다주는 이익이 얼마인지를 따져야만 가능하다. 물론, 그렇게 측정하는 것은 거의 불가능할 수도 있다. 하지만,
이는 절대적인 수치를 요구하는 것이 아니라 상대적인 값어치로도 표현이 가능하다. 따라서, "과제의 성공이란 구현된 기
능의 가치"를 측정한 연속적인 값으로 표현하는 것이 바람직하다. 모든 것이 구현된 "100%"의 완전한 제품이란 존재하
지 않기에, 큰 과제는 작게 나누고, 작은 과제는 더 작은 개인별 구현 항목으로 이어져, 기능별로 반복을 통해서 제품의 완
성도를 높여야 한다.
- 실패하지 않으려면 실패하지 않는 방법을 찾아야 한다. 100%가 아닌 80%를 만족시킬 수 있는 것도 성공의 새로운 정
의다.-
18 · [ 프로페셔널 프로그래머 ]

19. 2017/07/05 08:31 http://blog.naver.com/knix008/221044297277
[ 해야할 일 vs. 하지 말아야 할 일 ][ 해야할 일 vs. 하지 말아야 할 일 ]
낙서장(2017)낙서장(2017)
우리는 회사에서 많은 일을 하고 있다. 연간 계획으로 확정된 일을 하는 와중에도 다양한 TF(Task Force)나 회의, 자료 작
성, 세미나, 교육 참석, 각종 발표회 및 산학과제 관련 협의, 동료가 힘들어 하는 일도 돕고, 윗 사람의 지시사항도 챙겨서
진행하고 있을 것이다. 물론, 이런 모든 일들은 해야할 것들이다. 누군가 시키지 않아도 상시적으로 하는 일도 있을 것이
고, 스스로 팀이나 회사에 필요한 일을 찾아서 하는 사람들도 있을 것이다. 여기서 문제는 "하지 말아야 할 일을 적극적으
로 하지 않는 것"이다. 사실 누군가의 지시사항이 왜 필요하진도 모르고 하는 경우도 있다. 또한, 이미 시스템으로 구축되
어 있는 상황에서도 확인이 귀찮다는 이유로 다시 서면으로 보고서를 작성해야 하는 경우도 있다. 즉, 같은 일을 반복해서
하는 경우가 생기게 되는데, 이런 일들은 대부분 하지 않아야 하거나, 혹은 시스템 자체를 변경해야하는 상황에 와 있다는
것을 의미한다. 아무런 부가가치를 생산해 내지 못하는 일들은 "적극적으로 없애야 하는 일"이라는 것이다. 코딩도 마찬가
지다. 같은 코드를 여러번 수정하거나 혹은 재작업하는 일이 자주 발생한다면, 그 만큼의 시간동안 "정말 해야 하는 일"에
대해서는 소홀해 질 수 밖에 없다.
해야 할 일과 하지 말아야 할 일은 명확히 구분되지 않을 수 있다. 즉, 하지 말아야 할 일을 찾는 것이 쉽지 않다는 것이다.
마치 정말 필요한 것 처럼 보이지만, 실제로는 별로 도움이 되지 않거나 생각보다 효과가 거의 없을 수도 있다. 예를 들어,
테스트를 여러번 많이 하는 것은 좋다고 생각하지만, 그것으로 인해서 개발자가 테스트를 게을리하는 것은 옳지 않다. 따
라서, 테스트가 있는 것은 가치를 높이는 활동이지만, 그것이 있다고 개발자가 해야할 일이 줄어들지는 않는다. 이유는 개
발자가 하는 테스트와 테스터가 하는 테스트가 다르기 때문이며, 찾아낼 수 있는 버그의 종류도 다를 수 있기 때문이다. 특
정 회의를 위해서 문서를 작성하는 것은 필요하지만, 이미 작성된 문서를 파워포인트를 이용해서 다시 작성할 필요는 없
다. 반대로 파워 포인트로 작성해서는 안되는 문서를 이용해서 다른 결과물을 대체하는 것도 올바른 방법은 아니다. 이 경
우는 중복된 일이 발생하기에 둘 중에 하나를 선택해서 그것을 양식으로 정할 필요가 있을 것이다. 필요한 회의도 있지만,
그렇지 않은 회의도 많다. 목적이 무엇인지 알 수 없는 모호한 회의도 있으며, 결론이 나지 않고 다음번 회의로 미뤄지는
경우도 있다. 이런 경우에는 오히려 충분한 시간을 두고 목적을 찾는 것이 더 낫다. 구분이 모호하다면 목적이 없는 것들을
제외시켜 나가야 할 것이다.
일일보고, 주간보고, 월간보고, 분기보고, 연간보고 등등 다양한 보고서들이 만들어지고 버려진다. 이런 것들은 전부 시한
이 정해진 것들이다. 즉, 어떤 특정 시점이 지나고나면 의미가 없는 자료로 남는다. 물론, 그런 자료들이 남아 있어야 결정
의 근거를 찾을 수 있는 경우도 있지만, 대부분의 보고서는 작성한 사람에게만 남거나, 회의를 참석한 사람들에게만 전달
될 뿐이다. 그리고, 그런 문서들은 정말 다시 찾기가 힘들다. 이런 경우라면 차라리 문서를 전문적으로 관리하는 서버를 설
치해서 운영하는 것이 낫다. 예를 들어, "Wiki"와 같은 것을 사용하면 효과적으로 문서들을 공유하고 관리할 수 있을 것이
다. 검색 기능도 있으니 찾기도 편하다. 과제를 진행하는 경우에도 이런 것들은 중요하다. 즉, 공유를 통해서 최대한 의사
19 · [ 프로페셔널 프로그래머 ]

20. 소통을 할 수 있도록 만들어주는 것이다. 문서를 작성해서 보내고 받고, 편집하고, 다시 수정하는 등등의 일은 사실상 크게
의미가 없다. 물론, 효과적으로 전달하는 것이니 의미가 있다고 이야기 할 수도 있다. 하지만, 가공시에 발생하는 "의도적
인 취사선택"을 막을 방법은 없다. 따라서, 차라리 모든 사람이 공유하는 곳에서 직접 대화를 나누는 것이 오히려 직접적인
의사 전달 방법이 될 수 있다. 이런 것에 익숙하지 않은 관리자들은 항상 출력된 결과물과 일정한 포맷을 요구하지만, 그런
것들은 낭비일 뿐이며, 그 어떤 부가가치도 만들지 못하고 버려지는 것들이다. 따라서, 공유가 필요한 것들은 시스템을 구
축해서 대화하는 것이 더 좋은 선택이다.
일의 진척사항을 파악하는 것은 조치만, 보고서만 쓰라고 하는 것은 아닌지 주의해야 한다. 사실 중간급 관리자의 대부분
의 업무는 파워포인트로 끝난다. 우스개 소리로 "중급 개발자의 개발도구는 파워포인트"라는 말이 있을 정도다. 보고서를
쓰기보다는 시스템에 등록된 내용을 보고 파악할 수 있도록 해야한다. 버그의 갯수만 볼 것이 아니라 유형을 표현할 수 있
는 시각화로 나타낸다면, 한번만 제대로 만들면 오래동안 보고서를 작성할 이유가 없어진다. 자주 반복적으로 해야하는 일
은 사람의 실수가 들어가기에, 객관적인 시각화 도구를 활용해서자동화 시킬 수 있는 방안을 찾는 것이 좋다. 요즘은
"Python"과 같은 스크립트 형태의 언어를 사용한 시각화 기법들이 많이 존재하기에, 예전보다는 더 쉽게 이런 일들을 처
리할 수 있을 것이다. 궁금한 모든 것을 보고서로 남기기를 원하는 사람은 일을 모르는 관리자 한 사람 밖에 없지만, 그 사
람으로 인해서 다수의 인력들이 시간을 낭비하는 결과를 초래해서는 안된다. 당연히 개발자의 도구는 파워포인트도 포함
할 수 있지만, 개발 환경상에 필요한 것들이 더 위주가 되어야 한다. 글을 쓰는 것 자체는 문제가 아니며, 일을 정리하기 위
해서 설명 자료를 만드는 것도 생산적인 일이다. 하지만, 단순히 몇 사람의 즐거움을 위해서 문서를 만드는 것은 옳지 않
다. 그 대상이 고객이라면 이야기는 달라지겠지만, 내부의 일부 사람들에게만 어필할 수 있는 자료는 "정치"와 다를 것이
없는 것이다(물론, 정치도 필요한 일이겠지만).
해야 하는 일은 "계획과 검증"에 속한다. 즉, 어떤 일을 어떻게 할 것인가를 계획하고, 그것이 제대로 이루어 졌는지를 확
인하는 것이다. 예를 들어, 설계를 했다면 설계에 대한 리뷰를 해야하고, 코딩을 했다면 코드 리뷰가 당연히 진행되어야 한
다. 테스트를 했다면 테스트 한 결과에 대한 검토 작업이 뒤따르는 것이 당연하다. 여기에 추가되는 문서화는 개발자가 가
장 귀찮아 하는 부분이다. 즉, 일을 하지만 문서는 작성하기 싫어한다. 이런 상황이라면 각종 결과들에 대해서 출력을 자동
화 시켜 특정 양식에 맞도록 만들어 줄 수 있다. 코딩에서는 "Doxygen"과 같은 코멘트 양식을 사용해서 코드를 설명하는
문서를 만들어낼 수 있으며, 리뷰의 로그를 이용해서 어떤 코드들이 어떻게 리뷰가 이루어졌는지 증빙자료를 남길 수 있
다. 테스트는 당연히 커버리지에 대한 결과를 출력으로 볼 수 있어야하며, 이것 역시 자동화할 수 있는 부분이다. 문서를
쓰기 싫다면 가능한 자동화 시킬 수 있는지 시도해봐야 한다. 완전히 자동화가 불가능한 경우에도 문서의 상당부분은 자동
화된 출력에 의존하도록 만들 수 있다. 계획, 전략, 설계, 디자인 등등은 창의력으로 해결해야 하는 지적인 과정이다. 따라
20 · [ 프로페셔널 프로그래머 ]

21. 서, 여기에 필요한 문서를 작성하는 것은 사람만이 제대로 할 수 있다. 물론 각종 툴의 도움을 받을 수는 있겠지만, 그것 만
큼은 아직 사람에게 남은 고유의 영역이다. 즉, 이 부분에 대해서는 문서화는 "해야할 일"에 속한다.
해야 할 일은 해야하고, 하지 말아야 하는 일은 적극적으로 제거하거나 자동화 시켜야 한다. 그렇지 않다면, 결국 우리는
해야할 일을 하지말아야 하는 일로 대체하게 되며, 업무의 생산성을 따지기 보다는 "의자에 앉아 있는 시간"으로 역량을
평가받게 된다. 하지 말아야 할 일은 누군가의 손에만 맡겨서 처리할 수 있는 것이 아니며, 전체 조직이 다 나서서 찾아 없
애야 한다. 불필요한 회의를 줄이고, 불필요한 문서를 쓰지 않으며, 불필요한 꾸미기도 하지 않는 것이다. 또한, 불필요한
지시사항도 없애야 한다. 우선순위를 정할 수 없고, 언제까지 해야할지 모르는, 무엇을 해야할지도 정하지 않은 것들은 해
서는 안되는 일이다. 급하다고 모든 일이 우선순위가 가장 높은 것도 아니다. 정말 중요한 것은 해야할 일을 적절한 순간에
실행하는 것이며, 그 일의 결과를 모두가 공유하는 것이다. 필요없는 문서도 있지만, 필요한 문서는 반드시 작성해야 하며,
반복적이고 지루한 일은 자동화로 해결할 수 있도록 "프로그래밍"해야 한다. 소프트웨어 개발자가 잘하는 것이 "코딩"이
기에, 자동화는 그렇게 어려운 일이 아니다. 물론, 그렇게 만들어진 시스템을 제대로 사용하는 것이 "관리자"의 덕목이며,
그 시스템의 출력물만 따지기 보다는, 그 시스템 자체를 잘 활용할 수 있는 개인 시간의 투자도 필요하다. 직급이 높다고
아랫 사람을 부릴 생각을 하지말고, 어떻게 하면 더 일에 집중할 수 있도록 만들 수 있는가에 초점을 맞춰야 한다. 생산성
이란 "놀고(Idle) 있는 사람"이 문제가 되는 것이 아니라, ?해서는 안되는 일을 하는 낭비"를 줄여야 높일 수 있다.
- "적극적으로 하지 않기" 위해서는 반항이 아닌 공감이 필요하다.-
21 · [ 프로페셔널 프로그래머 ]

22. 2017/07/06 08:49 http://blog.naver.com/knix008/221045105241
[ 추적성(Traceability)을 가지고 일하라. ][ 추적성(Traceability)을 가지고 일하라. ]
낙서장(2017)낙서장(2017)
어떤 일을 하게 될 때, 그 일이 제대로 수행 되었다는 것을 객관적으로 증명할 수 있는 방법이 있는가? 만약, 그렇게 일하
고 있다면 정말 제대로된 개발자라고 할 수 있겠다. 하지만, 대부분의 개발자는 자신의 일(코딩)에 대해서는 열정적으로
임하지만, 정작 그것이 갖추어야 할 다양한 부분에 대해서 신경쓰지 않는다. 예를 들어, 특정 요구사항이 아키텍처 설계,
디자인, 구현, 테스트 등의 과정을 통해서 어떻게 만들어지고 있는지 관리하지 않는 것이 일반적이다. 요구사항만 해도 사
용자가 주는 "사용자 요구사항"을 분석없이 그대로 시스템 요구사항으로 사용하고 있는 것이 현실이다. 요구사항을 분석
하고 관리하는 것(물론, 실제로는 까다로운 일이지만)이 모든 과제의 시작이지만, 그와 관련된 활동에 대해서 무심한 것이
개발 현장에서 자주 발생한다.
자신이 이미 가지고 있는 지식이 충분하다고 생각하면, 대략적인 사용자의 요구사항을 이해한 후에 곧바로 설계로 돌입하
게 된다. 그리고, 사용자 요구사항을 테스트와 연계시키는 것도 부족하게 된다. 사용자 요구사항의 항목들은 검증되어야
할 부분이며, 그것들을 검증하기 위한 테스트 케이스들과 검증 결과를 관리하지 않는다는 것이다. 추적성이 중요한 이유는
사용자의 요구사항이 정확히 구현되고 있는지를 알기 위해서 이며, 또한 요구사항이나 중간 과정에서 생기는 다양한 요인
으로 인한 변경(Change)이 어떤 영향을 주는지에 대한 분석 때문이다. 하지만, 결과적으로 추적성을 관리하지 않기에 이
런 활동들이 제대로 수행되는 것은 "개인의 역량에 의존"하는 수 밖에 없다. 그리고, 객관적인 증명은 당연히 불가능한(혹
은 부족한) 일이 된다.
추적성은 양방향(Bidirectional)으로 이루어진다. 즉, 어떤 일을 하기위해서 필요한 요소가 식별(Identify)되면, 그것을 검
증하기 위한(혹은, 그것에서 유래한) 요소도 식별될 수 있어야 하며, 반대 방향으로도 식별할 수 있는 방법이 필요하다. 따
라서, 어떤 요소의 변화가 다른 어떤 요소들에 영향을 주는지 파악할 수 있어야 하며, 검증된 결과(혹은, 결과물)가 어디에
서 유래 했는지도 파악할 수 있어야 한다. 물론, 그렇다고 매핑(Mapping)이 "1:1"로만 되어야 한다는 것은 아니다.
"1:N"이나 "N:1"이 될 수도 있다. 하지만, 될 수 있으면 "1:N"의 관계는 좋지만, "N:1"의 관계는 효과 측면에서 좋지 못할
수 있다. 즉, 여러 식별된 요소가 다른 하나의 요소에만 영향을 주고 있다는 것은, 시스템의 분할이 제대로 이루어지 않았
거나, 세밀한 검증을 하고 있지 못하다는 뜻이 되기 때문이다.
22 · [ 프로페셔널 프로그래머 ]

23. 추적성의 결핍은 연속적인 일의 흐름을 방해하게 된다. 일의 각 공정(Process)가 나누어져 담당자들이 정해져 있는 경우,
이는 심각한 영향을 미칠 수 있다. 담당자들간에 서로 협업이 안된다는 뜻이기 때문이다. 부서도 마찬가지다. 이를 "사일
로(Silo)"라는 비유로 표현하기도 하는데, 하나의 일이 마치고 그 다음 공정으로 넘어갈 때, 완전히 새로운 일로 받아들여
지게 되며, 앞단에서 요청한 검증이 뒷단의 설계나 구현, 테스트 등등에 반영이 되지 않는다. 따라서, 당연히 만들고자 한
제품과 실제로 사용자가 손에 받아든 제품은 차이가 날 수 밖에 없다. 표준화된 스펙을 가지고 작업해도 마찬가지다. 그것
만을 기준으로 해서 제품을 만드는 것은 아니다. 예를 들어, SATA나 PCIe등과 같은 표준 스펙이 있다고 하더라도, 그것은
최소한의 호환성을 만족하기 위한 제약 사항일 뿐이다. 제품이 응용되는 분야에 따라 다른 요구가 있을 수 있다. 따라서,
추적을 유지해서 일의 연속적인 흐름을 유지할 수 있도록 만드는 것은 제품 개발의 핵심인 것이다.
추적성이란 식별할 수 있는 번호로 관리할 수 있어야 한다. 사용자 요구사항의 ID가 주어진다면, 그것이 설계의 어디에 반
영되었는지 번호(여기서 부터는 설계의 각 항목에 부여한 장(Chapter) 번호나 절(Clause)가 될 수도 있다)로 기입되어야
한다. 또한, 설계는 다시 상세 디자인의 어디에 해당하는지 번호로 연결되어야 하며, 상세 설계는 구현의 어느 모듈에 해당
하는지 표현되어야 한다. 각각의 수준에 맞게 모듈은 단위 테스트들을 가져야 하고, 상세 설계는 통합 수준의 테스트 케이
23 · [ 프로페셔널 프로그래머 ]

24. 스들과, 아키텍처 설계도 시스템 수준의 테스트 케이들과, 각각의 요구사항들은 사용자 인수 테스트 케이스와 연계되어야
한다. 또한, 사용자 요구사항과 상세 설계, 모듈 구현 등과 같은 것들은 일관성(Consistency)를 유지할 필요가 있으며, 이
역시도 추적성의 일부로 관리되어야 한다.
추적성은 단순히 번호를 매기는 것만이 아니라, 논리적인 일의 전개 과정과 유래 및 검증과 결과까지도 포함하고 있는 것
이다. 번호를 만들어서 추적성을 관리하는 이유는 그것이 편리하기 때문이며, 웹을 이용하는 경우에는 링크(Link)를 이용
해서도 관리할 수 있다. 또한, 변경의 영향도를 보기 위해서는 링크를 추적하며 영향 받는 부분들에 대한 적절한 시각적인
피드백도 주어지는 것이 좋다. 추적성은 꼭 필요한 일은 반드시 한다는 것을 보장하기 위한 방법이며, 검증과 연결된 의도
적인 확인 절차다. 개발자들이 이를 만들기 어려워하는 이유는 그것을 할 만큼 충분한 시간이 주어지지 않는다는 현실(?)
때문이다. 물론, 이것도 하나의 핑게에 불과할지도 모르지만, 삶은 그렇게 여유있지 못하다. 우린 언제나 시간이 부족하고,
언제나 그 시간동안 해야 할 일은 넘친다. 그리고, 그 결과로 지연이 발생하더라도 누구도 그것에 대해서 책임감은 느끼지
않는다. 하지만, 시간이 없다고 바늘을 허리에 매고 옷을 누비는 일은 없어야 할 것이다.
- 이유와 근거를 파고들면 원리를 알게된다.-
24 · [ 프로페셔널 프로그래머 ]

25. 2017/07/06 13:17 http://blog.naver.com/knix008/221045302189
[ 이상과 현실의 괴리 ][ 이상과 현실의 괴리 ]
낙서장(2017)낙서장(2017)
항상 부딪히는 일이지만, 프로그래머로 일할 때 이상적으로 생각하는 상태와 현실의 상황은 차이가 있을 수 밖에 없다. 이
상적으로는 다양한 상류(Upstream) 활동을 완료해야 하류(Downstream)에서 오버헤드가 커지지 않는다고 이야기 하지
만, 실제로는 그런 활동들을 할 시간은 충분히 주어지지 않거나, 혹은 다른 일과 겹쳐 우선 순위가 낮은 일로 취급된다. 따
라서, 항상 무엇인가를 해야할 단계라고 보이지만, 그 활동이 충분히 이루어지지 않은 상황에서 다음로 넘어가 버리는기
일쑤다. 물론, 그 일은 나중에 다시 할 수 없는 일이 되어 버리고 만다. 그리고, 결과적으로는 "의도하지 않은 재작업"의 긴
고통의 터널을 몸으로 때우면서 지내고 만다. 무엇을 개선하고 싶지만, 어디서 부터 시작해야 할지도 모르고, 누가 해야할
지도 모르는 상황이 연속되는 것이다. 이상은 책에서 배운 것이지만, 현실은 몸으로 깨닫는 것이다. 중요한 것은 이상 상태
에 대한 "끈"을 놓지 않고 지속적으로 유지하는 것이며, 꾸준히 조금씩이라도 변화를 추구하는 것이다. 그렇지 않다면, 오
랜 시간의 개발자 생활도 큰 만족을 주지 못하고 마감할지도 모른다. 목표없는 삶이란 나침반 없이 떠나는 여행과 같다. 어
디로 가야할지, 무엇을 해야할지 아무것도 정해진 것이 없이 그냥 나이만 들어갈 뿐이다.
현실만을 내세우면 개선은 없다. 항상 우리는 바쁘고, 항상 요구사항에 대한 분석은 생략하고, 항상 설계는 대략적으로 아
는 것만하고, 항상 세부 설계는 생략한 다음에 그냥 구현으로 들어가고 만다. 당연히 단위 테스트 보다는 빨리 만들어서 테
스터에 전달하는 것이 진도는 빨리 나가는 것 처럼 느껴질 것이다. 시간이 없기 때문에 제대로 구현하지 못하고, 시간이 없
어서 항상 버그를 잡는다고 야근과 특근을 밥먹듯이 하는 것이다. 형식을 갖춘 코드 리뷰가 아무리 많은 버그를 사전에 차
단할 수 있다고 알려져 있더라도, 그것은 여유 있는 사람들만의 전유물이다. 단위 테스트는 코딩량만 늘리고 제대로 어떻
게 해야할 지도 모르기에, 그냥 빨리 최적화 코드를 만든데만 집중하게 된다. 무엇이 이상적인 모습인지는 마음속에 다들
가지고 있지만, 정말 그렇게 하려고 노력하는 것은 언제나 외국의 유명한 IT기업에서나 가능한 일이라고 치부해 버리고 만
다. 정말 그럴까? 우리라고 못할 이유가 있을까? 그들도 과제 일정에 압박을 받으며 일하고, 과제가 나가떨어지면 직장에
서 해고되는 것이 일반적이다. 하지만, 적어도 우리는 과제가 드롭(Drop)되었다고 회사에서 나가라는 소리는 하지 않는
다. 어쩌면 우리가 더 그들보다 나은 환경에서 코딩하고 있는지도 모르는 것이다.
25 · [ 프로페셔널 프로그래머 ]

26. 나쁜 관리자 밑에 훌륭한 개발자는 살아남지 못한다. 그렇다고 관리자가 나쁘다는 생각에 자신이 훌륭한 개발자라고 믿지
는 말라. 정말 훌륭한 개발자라면 관리자와 좋은 관계를 유지할 수 있도록 노력할 것이다. 하지만, 정말 힘들다면 다른 일
을 찾아보는 것도 개인적(건강에도 도움이 되는)으로 좋은 선택이다. 어떤 선택을 하더라도 잊어서는 안되는 것은 "무엇이
정상이며 제대로 하는 것인가?"에 대한 자신만의 해답이다. 그 해답이 많은 사람의 동의를 얻지 못하는 경우는 있겠지만,
그 마저도 없다면 스스로에게 정당한 이유를 만들지 못한다. 이상은 높지만 현실이 안된다는 말로 술안주를 삼는 것은 좋
지만, 그렇다고 아무런 변화도 없이 매일 매일 살아가는 것이 옳지는 않다. 뭔가 잘못되었다는 말은 누구나 할 수 있지만,
그것을 어떻게 하면 더 나아지게 할지를 고민하는 사람은 드물다. 그리고, 그것을 행동으로 옮기는 사람은 더 찾기 힘들다.
"모난 돌이 정 맞는다"라는 속담을 신봉한다면 그냥 참고 견디는게 답이다. 하지만, 세상이 둥글게 보여야 할 이유가 있을
까? 자신이 생각이 옳다면 최소한 자기 자신만 이라도 시도는 해봐야 한다. 혼자서 하는 실험에 누가 뭐라고 할 사람은 없
다. 사실 약간 진도가 느리게 나가는 것 처럼 보일지라도 "정도"를 가는 것이 더 빨리가는 지름길이다. 처음에는 느리게 보
일지라도 결국에는 더 빨리 목표에 도달할 수 있다.
이상은 자신이 자신을 바라보는 것으로 하고, 현실은 자신이 남을 바라보는 태도를 가지면 이기적인 삶이 되고 만다. 자신
만이 옳고 남들은 틀린 생각을 가지고 있다는 뜻이되기 때문이다. 따라서, 이상을 마음에 담기 위해서는 무엇이 정말 옳은
가를 충분히 공부해야 한다. 현실이 아무리 엉망진창이라고 해도, 그것이 영원히 반복되지는 않는다. 사실 다른 곳으로 고
개만 돌리더라도 완전히 새로운 세상이 열리는 것을 느낄 수 있다. 자신의 자리에만 연연하고, 주변의 상황에만 정신이 팔
려있기 때문에 정말 중요한 것을 놓치고 있는지도 모른다. 세상이 힘들다고 이야기는 하지만, 정말 힘들어하는 사람들을
못본체 지나치는 것도 어쩔 수 없는 우리들의 자화상이다. 상상의 거울속에 비친 자신 모습이 마음에 든다면, 그렇게 되기
위해서 꾸준히 노력해 나가야 한다. 댓가없이는 얻는 것도 없듯이, 노력없이는 아무 것도 변화시키지 못한다. 정말 제대로
하는 방법을 알고 있다면 주저할 필요없이 그냥 하면 된다. 팀은 아무런 생각이 없는데 자기 혼자만 그렇게 하는 것이 부담
26 · [ 프로페셔널 프로그래머 ]

27. 스럽다면 숨어서라도 끝까지 해보라. 어차피 기존의 방법으로 해봐야 달라질 것이 없다면, 나라도 시험해 보는 것이 최선
이다. 같은 방법으로 반복적으로 실패한다면, 바꾸어서 실패한다고 누가 뭐라고 할 사람은 없다. 실패는 이상을 잊어버린
일상에 길들여진 모습이며, 하루 하루 어제와 같은 고민으로 내일을 맞이하는 삶인 것이다.
- 현실이 개똥밭 이라도 이상향에 대한 그리움은 멈추지 않아야 한다.-
27 · [ 프로페셔널 프로그래머 ]

28. 2017/07/07 08:36 http://blog.naver.com/knix008/221045889862
[ 대화가 필요해... ][ 대화가 필요해... ]
낙서장(2017)낙서장(2017)
모든 일은 대화가 필요하다. 특히, 한 사람이 하는 일이 아니라면, 같이 일하는 사람들과는 편하게 이야기 할 수 있는 분위
가 있어야 한다. 대화가 부족하면 가족관계에서도 문제가 발생하듯, 가족보다 더 오랜 시간을 같이 보내는 회사 동료들과
의 대화는 특히 중요한 부분이다. 일명 "또 하나의 가족"과는 항상 열린 대화를 할 수 있어야 하지만, 실제로 회사 내에서
할 수 있는 대화는 한정적이기 마련이다. 물론, 개인의 친분이나 역할 때문에 더 깊은 대화를 나눌 수 있는 가능성도 있지
만, 개인이 가진 모든 문제에 대한 해결책을 찾을수는 없다. 하지만, 적어도 일을 하는데 있어서 꼭 필요한 대화 정도는 언
제 어디서라도 할 수 있어야 한다. 성과가 좋은 팀의 특성 중에서도 "동등한 대화의 기회"는 중요하다고 한다(구글에서 연
구한 결과가 그렇다고). 즉, 기계적이라도 모든 사람이 동등한 발언 시간을 가질 수 있다면, 팀의 성과는 비교적 다른 팀에
비해서 높이 나타난다고 한다. 대화는 일의 시작과 과정, 그리고 힘든 문제에 부닺혔을 때 해결할 수 있는 능력을 모든 팀
원이 키워나갈 수 있는 바탕이며, 대화 없이는 팀의 유지 자체가 형식에 불과할 뿐이다.
대화의 시작은 상호간의 존중이다. 존중하지 않는다면 상대방을 바라보는 태도가 대화에도 영향을 준다. 좋은 말이 나올리
가 없는 것이다. 거짓으로 존중 하라는 것이 아니라 진정으로 존중해야 한다. 잠시는 속일 수 있지만 시간이 지나면 본질은
드러나기 마련이다. 잘못했다고 생각한다면 즉각 사과하라. 시간을 놓치면 사과의 의미도 사라진다. 하지만, 자신을 존중
해 주지 않는 사람에게 까지도 굽히라는 것은 아니다. 대화할 수 있는 대상에서 잠시 따로 놓아두면 된다. 서로를 더 알 수
있는 시간이 필요하기 때문이다. 대화에는 동등한 입장에서 이야기 할 수 있도록 분위기를 만들어야 한다. 서로 주고 받는
것이 대화다. 일방적으로 의사가 전달되는 것은 대화가 아닌 명령일 뿐이다. 만약, 누군가의 의견을 솔직하게 듣고 싶다면,
분위기를 조성하는 과정도 중요하다. 단순히 입에 발린 소리를 듣고자 한다면 아무렇게나 설문 조사와 같이 해도 상관없
다. 하지만, 뼈에 새길 수 있는 조언은 그런 말들이 아니다. 오히려 너무 친해도 이런 의견을 주기는 쉽지 않다. 친한 사람
일 수록 지켜야 할 예의도 있다. 어느 한계 선을 넘어서면 우리는 돌이킬 수 없는 상황으로 대화를 이끌어가게 된다. 이런
것을 방지하기 위해서는 서로 존중하는 마음은 항상 바탕에 깔려 있어야 할 것이다.
28 · [ 프로페셔널 프로그래머 ]

29. 소프트웨어 개발의 대부분은 대화다. 코딩도 대화다. 누군가 코드를 읽는 것 자체가 의미를 전달하는 과정이며, 고객의 요
구사항을 분석하는 것도 대화의 일부다. 설계는 시스템을 구축하는 원칙에 대한 대화의 기록이며, 상세 디자인은 앞으로
어떻게 구현할 것인가를 고민한 결과물일 뿐이다. 즉, 이런 모든 활동의 기반은 대화를 통해서 구축된다는 점이다. 따라서,
소프트웨어 개발 활동의 핵심은 대화에 달려있다고 해도 무방하다. 당연히 생산성이 높은 팀은 대화를 잘하고 있는 팀이
다. 팀과 팀, 팀내의 개인과 개인, 팀과 관리자, 개발팀과 고객 등등 다양한 대화의 형태가 이루어져야 성공적인 제품을 만
들 수 있다. 특히, 개발팀은 내부 고객도 중요하게 생각해야 한다. 단순히 외부에 있는 고객의 의견만 중요하게 생각하면,
사업에 대한 영속성을 잃어버릴 수 있는 잘못된 판단을 할 수 있기 떄문이다. 또한, 코드를 생산하기 쉽게, 읽기 쉽게, 설치
하기 쉽게 등등 다양한 부분들을 고려해서 만들어야 한다. 이런 것들도 누군가가 입력을 주었기 때문에 고려의 대상이 될
수 있는 것이다. 만드는 것만이 최선이 아니라, 어떻게 검증할 것인가도 고려해야 한다. 당연히 테스터의 입장도 충분히 대
화를 나누어야 알 수 있다. 제품의 완성도를 높이는 것은 단순히 내가 할 수 있는 것만 최선을 다하는 것이 아니라, 남들이
원하는 부분도 충분히 반영해 주어야 가능하다. 그리고, 제품은 혼자 만드는 것이 결코 아니라는 점도 기억해야 할 것이다.
풀리지 않는 문제는 대화로 시작해야 한다. 다양한 사람들이 모여서 다양한 시각을 공유할 때만 문제를 풀어낼 수 있는 경
우가 많다. 이른바, MDT(Multi-Disciplinary Team)을 구성해서 문제를 풀어야 하는 경우가 해당된다. 제품의 개발에 다
양한 과정과 사람들이 포함되어 있는 경우에는 단편적인 지식만으로는 문제를 해결하기 힘들다. 따라서, 이런 경우라면 동
등한 입장에서 자신의 관점을 이야기 할 수 있는 기회가 주어져야 문제의 해결책에 조금이라도 가까이 다가갈 수 있다. 자
신의 입장만 고려하는 것은 아마추어다. 프로는 다양한 사람들의 의견을 조율해서 완벽한 해결책은 아니지만, 실행 가능한
방안을 만들어 낸다. 대화는 그 시작을 알림과 동시에, 마무리도 대화가 맺어준다. 코딩은 컴퓨터가 이해하는 언어지만 그
언어를 이해하는 사람들간의 대화 도구가 될 수 있으며, 다양한 시각을 가진 사람들이 다양한 의견을 제시할 수 있다. 반드
시 코드로 작성해야만 대화가 가능한 것은 아니며, 원활한 대화를 위해서는 각종 문서도 필요하다. 그리고,가장 중요한 것
29 · [ 프로페셔널 프로그래머 ]

30. 은 직접 대화의 대상을 만나서 이야기를 나누는 것이다. 서로 존중하지 않는다면, 제대로 된 의견을 듣기 어려우며, 현실의
문제를 푸는 것은 단편적인 해결밖에 제시하지 못한다. 따라서, 진정으로 문제를 풀기를 원한다면, 상대에게 내가 원하는
것만을 이야기 할 것이 아니라, 상대가 이야기 할 수 있도록 만들어야 한다. 말하는 것은 쉬우나 듣기는 어려운 이유가 여
기에 있다.
- 먼저 대화를 시작하라. 그러면 모든 사람이 자신의 목소리를 낼 것이다.-
30 · [ 프로페셔널 프로그래머 ]

31. 2017/07/26 08:32 http://blog.naver.com/knix008/221059878782
[ 차이를 만드는 것은 노력의 질이다. ][ 차이를 만드는 것은 노력의 질이다. ]
낙서장(2017)낙서장(2017)
무조건 노력을 한다고 뛰어난 제품이 만들어지는 것은 아니다. 같은 1만 시간을 투자 하더라도 누군가는 최고의 전문가가
되고, 누군가는 그저 그런 전문가로 남는다(물론, 둘다 전문가가 되기는 하겠지만 수준의 차이는 존재한다.). 즉, 차이를 만
드는 것은 시간의 절대적인 양이 아니라, 그 시간을 어떻게 보내느냐에 달려있다는 것이다. 무작정 자리에 오래 남아 있으
면서 열심히 코딩과 테스트를 한다고 전문가가 되는 것은 아니다. 그랬다면 이미 세상에는 최고 수준의 전문가가 흘러넘칠
것이 분명하다. 대부분의 개발자는 하루 4시간 이상은 일하고 있고, 1년이면 1,000시간을, 10년이면 1만 시간, 20년이면
2만 시간을 충분히 일하고 있다. 따라서, 소프트웨어 개발자라는 이름으로 어느정도 일했다는 생각이 들면, 그들은 자기
분야의 최고 전문가가 되어 있어야 마땅하다. 하지만, 스스로에게 물었을 때 자신이 최고의 전문가 수준에 도달했다고 확
실히 대답할 수 있는 사람이 있을까? 정말 그런 대답을 할 수 있을 정도가 되었다면, 적어도 무엇이 그런 차이를 만드는 가
에 대한 설명 정도는 할 수 있어야 할 것이다.
같은 방식으로 아무리 노력해도 개선이 되지 않는다면, 방법을 바꾸는 것을 생각해야 한다. 사실 열심히 하지 않아서 실패
하는 과제는 없다. 그렇다고 모든 과제가 성공하는 것도 아니다. 반복적으로 계속 실패를 거듭함에도 불구하고 기존의 방
법을 고수하는 것은 옳지 않다. 예를 들어, 6 시그마(Sigma)와 같은 것을 차용해서 과제를 성공적으로 이끄는 중요한
(Vital) 인자들을 찾아내고, 그것들을 적절히 제어해서 최대의 성과를 낼 수 있는 적정치로 설정하는 것이다. 이때 중요한
것은 과제를 보는 시각이다. 즉, 기존의 방법을 바꾸어 체계적인 관리 방법을 찾아내고, 그것을 실헙적으로 적용해 성공적
인 설정 값을 찾아내는 것이다. 그냥 무턱대고 오래 동안 일하라고 사람들에게 지시하는 것보다, 무엇이 정말 성과와 관련
이 있는지 체계적으로 찾는 것이 핵심이다. 한번에 모든 것을 바꾸기 보다는 하나씩만 골라서 적용해보는 것이 좋다. 마치
관성의 법칙처럼 움직이지 않는 물체는 처음 움직이도록 만들기는 어렵지만, 일단 움직이기 시작한 물체는 조금만 힘을 주
어도 쉽게 가속이 붙는다. 따라서, 처음 움직일 수 있는 미리 선택된 작은 실행 방법부터 시작하는 것이 좋다.
다름을 인정해야 하지만, 그렇다고 그것이 모든 이유가 되어서는 안된다. 하는 일이 다르고, 사람이 다르고, 도구와 상황이
다를수는 있다. 하지만, 그렇다고 이상적인 방향이나 목표와 같은 것들이 달라지는 것은 아니다. 즉, 풀어야 하는 문제가
다르고, 그것을 해결해야 하는 사람이 다르지만, 문제를 해결하는 올바른 방법은 존재할 것이 분명하다. 문제의 해답은 다
를지 모르지만, 문제를 풀어가는 방식은 언제나 비슷한 과정을 취할 수 있다. 예를 들어, 좋은 소프트웨어가 가져야 할 특
징이 도메인이 달라진다고 차이가 날까? 무엇을 더 선호하는가에 대한 것은 도메인 별로 차이가 있을 수 있지만, 바람직한
소프트웨어라면 적어도 테스트가 가능해야 하고, 사람이 읽기가 쉬워야 한다 정도는 충분히 만족되어야 한다. 만드는 방법
은 시대를 통해서 발전적으로 바뀔 수 있으며, 과거의 "폭포수(Waterfall) 모델"에서 현재는 "Agile"방식을 주로 사용하고
있다. 하지만, 코드 자체에 대한 검토(Review)가 중요하고, 단위 테스트, 통합 테스트 등등을 조합하면 더 좋은 품질의 코
드를 만들 수 있다는 점은 동일하다. 달라지는 것은 그것을 해석하는 사람이지, 코드 자체는 아니라는 것이다.
31 · [ 프로페셔널 프로그래머 ]

32. 노력의 질을 높이기 위해서는 "충분한 가르침", "도전적인 문제 해결 방법의 고안", "혼자하는 노력", "피드백"이 핵심이
다. 즉, 이런 과정들이 제대로 보장되어야 노력으로 만들 수 있는 결과물이 차이가 난다. 소프트웨어 개발자들은 "혼자하
는 노력"에 중점을 두려는 경향이 강하지만, 누군간의 코칭이나 피드백이 없다면 노력의 시간은 더 오래 걸릴 수 밖에 없
다. 같은 노력을 하더라도 차이가 나는 것은 "제대로 배울 기회"가 없었다는 공통점도 있다. 배울만한 선배가 없거나, 혹은
배워서는 안되는 선배를 배우는 경우도 있다. 직장 생활의 시작은 매우 중요한 순간이며, 그 때 배우는 방법들이 전체 직장
인 생활을 결정하게 될지도 모른다. 문제가 늘상 보던 것이라면 해결 방향은 거의 동일하거나, 혹은 그전의 것을 그냥 복사
한 형태일 뿐이다. 물론, 항상 변화를 주는 것이 좋다는 것은 아니다. 하지만, 동일한 문제라도 다른 방법으로 풀 수 있는지
는 확인해야 한다. 혼자하는 시간도 중요하다. 배운 것을 실천할 수 있는 시간이 바로 이때다. 코딩에 연습이 따로 있는 것
은 아니지만, 혼자 노력하는 과정이 대부분일 것이다. 따라서, 이때는 새롭게 배운 것을 충분히 실전으로 증명해야 한다.
피드백은 일을 어떻게 했냐에 대한 객관적인 의견을 듣는 과정이다. 이것이 없다면 혼자 잘난 맛에 인생을 살게된다. 당연
히 발전은 없다.
오래동안 자리에 엉덩이를 붙이고 있어야 능률이 오르는 사람이 있고, 이런 저런 생각의 시간을 가져야 좋은 아이디어를
떠올리는 사람도 있다. 모든 사람이 같은 방식으로 일 할 수 있는 것은 아니며, 저마다 최고의 능률을 가지고 일할 수 있는
방법은 다를 수 있다. 이를 인지하는 것 자체가 쉽지 않은 일이지만, 그런 차이를 인정하는 것이 좀 더 효과적으로 변화를
모색하는 길이다. 변화란 현재 상황에 대한 정확한 인식을 바탕으로 하며, 단순히 반복해서 나아질 것이라고 생각해서는
안된다. 반복해서 좋아지는 것은 그 일을 하는데 필요한 노력이 줄어드는 것 밖에 없다. 같은 질을 만족하기 위해서 필요한
노력이 줄어든다면, 남은 노력으로는 무엇을 해야할까? 필요한 것은 질적인 차이를 만들 수 있는 방법을 찾는 것이다. 반
복이 중요하지 않은 것이 아니라, 반복으로 질적인 수준 차이를 만들기 위해서는 지속적인 개선 노력이 더해져야 한다는
32 · [ 프로페셔널 프로그래머 ]

33. 것이다. 방법의 개선 없이 막연히 좋은 품질을 기대하는 것은 "최고 전문가"가 해야 할 일이 아니다. 필요한 것은 좋은 품
질을 만들어내는 방법을 적용해 보는 것이다. 사실 이미 이런 방법들은 충분할 만큼 인터넷이나 서점에 나돌고 있는 것이
사실이다. 다만 아쉬운 부분은 그것이 현실을 무시한 개발이라고 생각하는 개발자의 태도다. 물론, 그런 태도 역시 개발자
혼자만의 문제는 아니다. 개발자를 그런 생각을 가지도록 만든 "상황"이 더 큰 문제인 것이다. 차이를 만들고 싶다면 "그럼
에도 불구하고"라는 단어를 흔히 쓰는 "노력"에만 한정해서는 안될 것이다.
열심히 하는 것이 성과로 이어지기 위해서는 방법의 선택도 중요하다. 소프트웨어 개발은 버그의 발생을 가능한 줄이면서
사용자가 원하는 기능을 구현하는 것이다. 따라서, 버그 발생을 억제하기 위한 좋은 방법들을 충분히 조합해서 사용하는
것을 "열심히" 해야 한다. 무엇인가 직접적인 버그의 원인이 되지 않는다고 무시한다면, 결국 그것이 버그로 나타날 때는
찾기 어려운 것이 될 가능성이 높다. 버그의 발생원인은 개발자의 의도하지 않은 실수이지, 버그를 만들려고 일부러 노력
하는 사람은 없다. 모든 개발자가 높은 수준이라고 하더라도 결국 버그는 발생하는 것이 당연한 결과다. 모든 프로그램은
버그를 가지고 있으며, 사용자가 인식할 수 있을 정도로 심각한 버그라면 그것을 수정하는 비용도 클 것이다. 그렇지만, 보
이지 않는 버그를 유발할 수 있을 가능성이 높은 코드를 짜는 것이 더 심각한 문제다. 잠재적인 버그는 실질적으로 위협은
되지 않지만, 개발 속도를 늦추고 지속적인 사람의 노력을 필요로 한다. 즉, 그로 인해서 더 생산적인 개발자로 거듭날 수
있는 기회를 잠식해 나가기 때문에 더 나쁜 버그라고 보는 것이다. 구조적인 복잡함(긴 코드, 중첩이 심한 조건 및 반복
등), 이해되지 않는 코드, 계층을 무시한 의존성, 지나치게 많은 기능의 집중화, 테스트 되지 않은(한번도 실행되지) 코드
의 존재 여부, 컴파일러 옵션으로 처리되거나 코멘트 처리된 코드 등등 버그의 유발 가능성을 높이는 것들은 항상 존재한
다. 이런 부분들에 대한 개선 방법을 찾는 것만이라도 "노력의 질적 차이"를 만들어내기에 충분한 선택이 될 수 있을 것이
다.
- 무엇을 하건 차이를 만드는 것은 결국 시간을 보내는 "질"에 달려있다.-
33 · [ 프로페셔널 프로그래머 ]

34. 2017/07/21 08:35 http://blog.naver.com/knix008/221056293324
[ 야근을 해야하는 정당한 이유(?) ][ 야근을 해야하는 정당한 이유(?) ]
낙서장(2017)낙서장(2017)
일을 하는 시간과 일의 "질(Quality)"은 관계가 있을까? 물론 있을 수 있다. 급하게 작성한 코드를 다듬거나, 새로운 코드
에 대한 자동화된 테스트를 추가하는 것과 같은 경우에는 의미가 있는 시간이 될 수 있다. 하지만, 자리에 단순히 엉덩이를
붙이고 있는 시간이 늘어난다고 해서 결과물에 대한 품질을 높여주지는 못한다. 따라서, 의미있는 야근이나 주말 특근 시
간이 되기 위해서는 제품에 대한 가치를 높이거나, 들어가야 하는 노력(Effort)을 줄이는 생산성에 관련된 것이어야 한다.
회사는 같은 돈을 들이더라도 더 많은 결과물을 원한다. 따라서, 야근의 생산성을 높이기 위해서는 투자되는 비용에 대해
더 품질이 높은 결과물을 만들어 내거나, 향후 추가될 수 있는 비용이나 재작업 시간을 줄이는데 그 시간이 활용되어야 한
다. 그렇지 못한 "시간 보내기"와 같은 자리지키기는 눈치를 보거나, 혹은 용돈벌기 밖에 되지 못한다. 물론, 그렇다고 자
신의 추가 근무시간에 대해서 이런 비판을 받고자 하는 사람은 없다. 그리고, 자신이 하는 모든 일에 의미를 부여하려고하
는 것도 인지상정이다. 하지만, 정말 중요한 것은 그것이 회사의 이익에 기여하는 것이 있는지를 살피는 것이다.
놀고 있는 사람은 눈에 쉽게 들어오지만, 놀고 있는 일은 보이지 않는다. 보통의 경우 관리자들은 놀고 있는 "꼴"을 못본
다. 사람이 놀고 있냐는 것은 쉽게 인지하지만, 정작 중요한 일이 제대로 진행되지 못하는 것은 그냥 넘겨버린다. 사람이
최대의 효율을 발휘하도록 만들기 위해서 두 세가지 일을 동시에 시키지만, 조금이라도 여유가 있다고 생각하면 더 많은
일은 할당하려고 일을 만들기도 한다. 야근은 그런 일들을 위해서 존재하는 시간이 아니다. 야근이나 주말 근무도 회사에
는 비용이며, 같은 비용을 지불하더라도 조금이라도 더 많은 일을 시키려는 것이 당연할 지도 모른다. 하지만, 근무 시간이
늘어나면 근무 강도는 낮아진다. 즉, 늘어난 근무시간이 지속되면 생산성도 낮아진다. 최대 2주를 넘어버리는 높은 근무
강도는 급한 일을 처리 했을 때 새로운 일에 대한 생산성을 높이는데 부정적인 영향을 준다. 물론, 하루에 한 두시간 정도
더 일하게 만들고, 잔업비 보다 교통비로 싸게 지불 하려는게 일반적인 회사들의 태도다. 하지만, 그런 작은 보상(?)은 오
히려 낮 시간 동안에 충분히 마칠 수 있는 일들에 대해서 지연시켜 버린다. 주말에 당연히 출근하는 사람은 절대 금요일까
지 일을 끝내지 않는다.
소프트웨어 개발의 생산성이란 "기능을 빨리 구현하는 것"이 아니다. 물론, "구현(Implementation)"에 검증
(Verification)까지 포함한다면, 그것이 생산성에 반영될 수는 있을 것이다. 그냥 단순히 코딩을 많이 하는 것이 생산성은
아니라는 것이다. 그리고, 급한 불끄기와 같이 트정 상황에서 근무 강도를 높이는 것은 어쩔 수 없는 선택이다. 하지만, 그
기간이 길어지거나 개발자가 느끼기에 무의미한 일을 하고 있다는 생각이 든다면, 그것도 결국 낭비일 뿐이다. 밤 11시가
되어야 퇴근하는 사람은 그 다음날 오전을 제대로 활용하지 못하며, 낮에는 이런 저런 회의나 보고서 작성등으로 시간을
보내고, 저녁이 되어서야 온전히 자신이 해야할 일을 진행할 것이다. 차라리, 정해진 시간을 더 효과적으로 보낼 수 있는
방법을 찾는 것이 현명한 선택이다. 물론, 정시 퇴근하는 사람을 관리자들이 "고운 눈길"로 처다보지 않을지도 모른다. 하
지만, 중요한 것은 일의 완료 상태에 대한 "품질"이며, 제대로 주어진 시간에 높은 수준의 품질을 만족시킨다면, 관리자들
34 · [ 프로페셔널 프로그래머 ]

35. 도 충분히 이해하는 상황을 만들 수 있다. 최근의 회사 분위기는 야근이나 주말 근무를 줄여가며, 규정된 업무 시간에 효율
을 높이는 방향으로 흐르고 있다는 점에서는 고무적이다. 하지만, 아직 일선의 관리자들은 그런 것들보다는 자신만의 기준
을 먼저 따진다. 특히, 고과에 대한 객관적인 기준이 없으면, 항상 가까이에서 찾을 수 있는 사람에게 "친절한 점수"를 주
게된다.
야근을 해야하는 정당한 이유는 "더 하고 싶은 동기"에서 찾아야 한다. 품질, 자신감, 실력, 협업, 공동 분담, 효율 등등 좋
은 것들은 이미 다 알고 있을 것이다. 하지만, 그런 것들이 오히려 규정된 근무시간에 할 수 있도록 만드는 것이 선행되어
야 한다. 그래도 부족하다면 야근이나 주말 특근이 필요하다. 배포 날짜가 얼마 남지않은 상황에서 버그를 수정하고 좀 더
좋은 코드를 만들기 위해서 노력하는 것은 당연하다. 하지만, 상시적으로 야근을 강요하는 것은 올바르지 않다. 또한, 일의
성격도 고려해서 근무 강도를 높여야 한다. 과제 초반부터 야근을 밥먹듯이 하면, 절반쯤 지난 후에는 다들 지쳐버리고 만
다. 오히려 조금씩 근무 강도를 높여가는 것이 효과를 볼 수 있을 것이다. 앞에서 나열한 정당한 이유들은 제품의 가치를
높이거나 재작업을 줄이는 활동들이다. 즉, 제품의 가치를 높여 회사의 이익을 얻거나, 사람의 공수를 줄여 더 빨리 제품을
출시하기 위한 것이다. 생산성에 관련없는 회의나, 의무적으로 남아서 일하는 분위기는 비용만 증가시킬 뿐이다. 정당한
이유를 댈 수 없이 막연히 근무 기록 만을 따지고 든다면, 노는 사람을 볼 뿐 정말 가치있는 일이 무엇인지는 놓치고 만다.
그리고, 정당한 동기가 있어야만 사람은 움직이기 때문이다.
반복적이고 지루한 일은 사람이 해선 안된다. 장기적으로 볼 때, 이런 일들은 전부 자동화 시켜야 한다. 사람의 인건비는
소프트웨어 개발의 대부분을 차지하기에, 효율을 높이기 위해서는 당연히 자동화를 꾸준히 늘려갈 수 밖에 없다. 대기업은
연구직의 잔업비를 인정하지 않는다. 아무리 국가 정책이 뭐라고 하더라도, 내부에서는 인건비를 줄이면서 일을 많이 시키
35 · [ 프로페셔널 프로그래머 ]