SWDeveloperStory201502

2015/09/12 10:16 http://blog.naver.com/knix008/220479148652
[ 나의 경쟁력은 어디에? ][ 나의 경쟁력은 어디에? ]
지난 낙서장-02지난 낙서장-02
익숙함은 안정을 부르고, 안정감은 지속하려는 성질이 있다. 하지만, 그런 느낌은 시간이 흘러 언제까지나 지속되지 않는
다. 특히 기술의 진화는 빠르게 진행되지만, 사람의 능력은 그것에 맞게 발전하지 못한다. 결국에는 더 이상 따라가기를 포
기하고, 이미 익혀온 것등를 가지고 대신하려고 한다. 새로운 것들은 하루를 멀다하고 계속 등장하며, 어떤 것들은 얼마가
지 못하고 사라진다. 어던 것을 선택하는 것이 자신의 불안해 보이는 미래를 보장해 줄 수 있을지는 아무도 모른다. 따라
서, 우린 그냥 그런 빠름에서 잠시 이탈하고 싶어지는 것이다. 지쳤다는 것이 오히려 더 맞는 말이다. 하지만, 자신의 시간
을 조금이라도 투자할 수 있는 여유가 전혀 없는 사람이 있을까? 아마 그런 사람은 이미 자신의 현재 자리에 있어선 안될
사람일 것이다. 나아가기가 두렵다면 취미생활 차원에서 조금씩 시작해보는 것도 좋을 것이다. 무엇을 익혀야 할지를 모른
다면, 가장 편하게 선택할 수 있는 새로운 프로그래밍 언어를 시작해보는 것도 좋을 것이다. 어떤 언어가 유망한지 보다는
지금까지 알던 언어와는 다른 차원의 언어를 익히는 것이 좋다. 새로운 개념을 그 언어를 통해서 익힐 수 있다면, 지금 사
용하고 있는 언어에 대한 이해도 더 높일 수 있기 때문이다. 물론, 한꺼번에 너무 많은 것을 알려고는 하지 말자. 중요한 것
은 역시 꾸준함이다.
경쟁은 남과하는 것이 아니라, 자신과 해야할 순간이 찾아온다. 오히려, 지금까지 우리는 모든 경쟁을 자신과 했을지도 모
른다. 대학입시의 경쟁률은 단지 숫자일 뿐이며, 결국 그 숫자를 극복할 수 있는 유일한 방법은 자신과의 경쟁에서 승리하
는 길 뿐이다. 하지만, 자신과 경쟁하는 것은 많은 인내력을 필요로 하다고 말한다. 과연 그럴까? 우리가 무언가를 참고 새
로운 것을 해야한다는 마음을 가지면, 결국 하나를 잃고 다른 하나를 선택하는 것 밖에는 되지 않는다. 오히려, 즐겁게 자
신의 마음을 움직일 수 있다면 더 좋지 않을까? 그렇다고 대단한 결심이 필요한 것도 아니다. 단순히 습관을 만드는 일부
터 시작하는 것이 중요하다. 하루에 30분씩이라도 새로운 것을 꾸준히 한다면, 마음도 몸도 같이 움직일 수 있도록 만들
수 있다. 생존하기 위해서 하는 일이 아니라, 즐거움에서 하는 일이어야 한다. 따라서, 고통스럽게 해선 안되고 즐겁게 할
수 있는 것을 선택하자. 자신만의 목표가 있다면, 그것을 이루는 것이 경쟁에서 승리하는 길이다. 누구를 위해서 하기 보다
는 자신만을 위해서 해야한다. 자신을 위한 시간이 필요하고, 그것을 통해서 뭔가를 만들어 나가는 것이 중요하다. 대단한
목표보다는 작은 목표를 만들어고, 그것을 꾸준하게 조금씩 실천하면 된다. 나이가 들어가면 점점 그렇게 할 수 있는 시간
이 많지 않다는 것을 누군나 안다. 이런 저런 일들로 자신의 이미지를 잊어가고, 결국 갑작스럽게 "왜 이러고 살지?"하는
질문을 스스로에게 던진다. 우린 그렇게 살려고 태어난 것은 아니다.
1 · [ 소프트웨어 개발자 이야기 ]

나의 경쟁력의 핵심은 내가 원하는 일을 할 수 있는 충분한 역량을 갖추는 것이다. 지금하고 있는 일이 자신이 원하는 일일
수도 있고, 아니면 앞으로 10년뒤에 새롭게 할 수 있는 일이 될 수도 있다. 그렇다면, 그때가서 생각하기 보다는 지금부터
시작하는 것이 옳지 않을까? 뭔가를 대비하지 않고 잘하는 사람은 극히 드물다. 지금 경쟁력이 없다고 나중까지 그렇게 살
수는 없다. 따라서, 지금이 뭔가를 시작할 가장 좋은 순간인 것이다. 지식에는 크게 두가지가 있다고 생각된다. 즉, 사물에
내재된 특징에 대한 것과, 그것을 사용하기 위한 방법이다. 만약 우리가 새로운 프로그램을 개발하고 있다고 한다면, 문제
를 이해하는 것이 첫 번째로 갖추어야할 지식이고, 그것을 실제 사용자들이 원하는 방법으로 풀어나가는 것이 두 번째가
될 것이다. 즉, 안다고만 그쳐서는 안되고, 실제로 그것을 직접 해봐야 한다는 것이다. 배운 것을 정리하는 것도 줗다. 하지
만, 될 수 있으면 배운 것을 직접 사용하고, 남에게 보여주는 것이 필요하다. 어떤 일을 할 수 있는 역량이란 결국 지식과
행동이 같이해야 이뤄질 수 있다. 머리속으로만 익힌 것으로 남들과 경쟁하는 것은, 도장에서 연습해서 고수가 될 수 있다
고 생각하는 것과 다르지 않다. 고수는 많은 실전 경험을 통해서 배운 기술을 더 다듬고 상황에 맞게 사용하는 것을 배운
다. 프로그램 개발은 단순히 언어를 배우는 것으로 끝내지 말고, 실제로 뭔가를 만들어서 보여주어야 한다. 이렇게 만들어
진 것들을 공개하고 다른 사람들의 솔직한 의견을 들을 수 있다면, 한 단계 더 나아갈 수 있는 시각을 가지게 될 것이다. 자
신만의 눈으로 바라보아서는 사물을 완전히 다 파악하기 어렵다. 다른 사람들은 나를 객관적으로 바라볼 수 있게 만들어
준다.
연차는 경쟁력을 대변하지 않는다. 한 분야에서 오래동안 일했다고해서 그 분야의 전문가가 되는 것은 아니다. 매일 같은
일만 반복적으로 한다면, 3년 정도만 발전이 가능할 뿐이다. 그나머지의 시간은 각종 팁들을 익히는데 사용되는 시간이다.
물론, 경험은 쉽게 쌓이지도 않으며 쉽게 사라지지도 않는다. 하지만, 경험했던 것들을 글로 남긴다면 이야기는 달라진다.
글을 쓰는 순간 경험은 중요한 자산으로 변한다. 따라서, 글쓰기는 자신의 경쟁력을 향상시키는 한가지 방법으로 활용할
수 있다. 글쓰기를 어려워 하는 대부분의 공대 출신들은 왜 문서를 만들어야 하는지 불평을 많이 늘어놓는다. 문서는 남을
위해서도 작성해야 하지만, 사실은 자신을 위한 기록이다. 업무 문서, 보고서, 발표자료, 각종 데이터들을 체계적으로 작성

하는 것은 정말 대단한 능력이다. 프로그램을 만드는 것도 사실은 글쓰기의 일부라고 볼 수 있다. 사용자의 언어로 문제를
기술하고, 그것을 코드에 담아서 해결책을 찾는 것이기 때문이다. 컴퓨터는 그렇게 작성된 코드를 실행할 뿐이지, 문제를
해석해서 코드를 만들어주지는 못하기 때문에, 문제를 분석하고 기술하는 능력은 인간만이 할 수 있는 것이다. 따라서, 글
을 많이 쓰게되면, 자연스럽게 코딩도 개선된다. 논리를 전개하는 과정에서 이해를 돕기위해서 복잡한 것을 감추는 추상화
를 사용하게 되며, 그 토대위에서 다시 새로운 지식체계를 키워나간다. 따라서, 경쟁력을 갖추기 위해선 자신이 경쟁력이
있다는 것을 글로 적어보는 것이 효과적일 것이다. 그 글은 물론 공개될 수 있다면 좋은 피드백을 받을 수 있다. 특히, 블로
그나 혹은 뉴스그룹과 같은 곳에서 의견을 교환할 수 있는 것은 많은 도움이 될 것이다. 아는 것을 적극 공유하는 것은 독
단에 빠질 가능성을 낮춤과 동시에, 말 그대로 전문가와 대화를 통해서 자신의 경쟁력을 상승시킬 수 있기 때문이다.
- 경쟁은 없다. 경험이 필요할 뿐... -

[ 사람을 뽑는다면... ][ 사람을 뽑는다면... ]
회사에서 경력이 조금 쌓이면 새로운 사람을 뽑기 위해서 불려다니는 일이 많아진다. 인사 부서는 사실상 어떤 사람을 뽑
을 것인가에 대해서 객관적인 자료 이상으로 알지 못하기에, 실제로 일하게 될 부서의 사람들이 면접에 호출되는 것이다.
작은 회사들은 대체로 좋은 인력을 뽑기가 쉽지 않다(그렇다고, 인력의 질이 처진다는 뜻은 아니다.). 작지만 견실한 회사
라면 좋은 인력이 지원할지도 모르지만, 대부분의 회사들은 실력이 있고, 평판도 좋은 인력을 뽑는데 힘들어 하는 것은 사
실이다. 큰 회사는 많은 인력이 몰리기에, 그 중에서 정말 실력과 인성을 다 갖춘 인력을 뽑는 것도 쉽지 않은 일이다. 어떤
상황이건 간에 사람을 뽑는다는 문제는 항상 힘들기 마련이다. 하지만, 정말 중요한 것은 반드시 좋은 사람을 뽑아야 한다
는 점은 동일하다. 결국 회사는 사람들이 모여서 이루어지는 조직이며, 그 사람들이 능력을 갖추지 않는다면 경쟁에서 살
아남지 못하기 때문이다. 하지만, 우린 대체로 어떻게 사람을 뽑아야 할지를 잘 모른다. 지원자를 충분히 검토할 수 있는
시간도 부족하며, 그들에게 어떤 질문을 해야할지도 막연하기만 하다. 준비안된 면접관의 신분으로 들어가서, 준비안된 면
접자를 만나고, 불확실한 미래에 경쟁력을 유지할 수 있다고 생각있다. 사람을 뽑는 것이 정말 중요한 일이라면, 오히려 일
하는 시간보다 사람을 뽑는데 더 집중하는 것이 올바른 행동이 아닐까?
면접에서 주로 보는 부분은 "지식", "사고능력", "경험", "인성"이라고 볼 수 있다. 별다른 대답을 하지 못하고, "열심히"
시키는 일을 하겠다고 하는 사람들은 떨어진다. "지식"은 해당 분야에서 적정 수준의 지식을 가지고 있는지를 몇가지 질문
으로 대답하도록 하지만, 실제로 그 사람이 정말 지식을 가지고 있는지는 해답을 적어야하지 알 수 있다. 특히, 코딩을 정
말 할 수 있는지를 확인하는 유일한 길은 코딩을 시켜보는 것이다. "사고능력"은 문제를 풀어나가는 것이 논리적인지 확인
하려는 것이지만, 문제를 파악하는 능력도 중요하다. 즉, 주어진 문제의 상황을 살피고, 그 속에서 문제를 논리적으로 해결
해 나가는 것을 본다. "인성"은 같이 일하기 위해서 가장 필요한 부분이다. 어떤 사람과도 같이 어울릴 수 있을 정도의 유
머를 가지고 있는 사람이라면, 어디서건 환영 받을 수 있을 것이다. 그리고, 가장 좋아하는 것에 대해서 열정을 가지고 이
야기하는지, 가장 힘들어 했던 일은 무엇인지를 스스로 이야가 할 수 있다면, 열정과 긍정적인 자신의 이미지를 가지고 있
는 사람일 것이다. 판에 박힌 말을 줄줄이 외워서 면접에 오는 사람들은 성공적이지 못할 것이다. 왜냐면, 그런 말들은 그
사람만 하는 것이 아니라, 아마 이미 몇명의 면접자들이 했을 것이 분명다. 그런 것으로는 면접관을 움직일 수 없다. 아마
도 이중에서 가장 중요한 것은 "열정"이라고 생각한다. 자신이 즐거워하는 것이 있고, 그것에 자신의 모든 것을 걸 수 있다
면, 어떤 일이라도 할 수 있는 자세가 되어있을 것이 분명하다. 하지만, 열정은 단순히 "열심히"보다는 "꾸준하고 깊이있는
것"을 필요로 한다.

팀을 구성하는데 권한을 주는 관리자들은 없다. 물론, 자신의 권한으로 팀을 구성할 수 있는 사람도 별로 없다. 다만 팀의
통솔자 정도는 지정할 수 있을지라도, 그 통솔자가 원하는 사람들을 다른 팀에서 마음껏 데려올 수는 없다. 그리고, 그렇게
사람을 데려오기 위해서는 일할 사람의 마음도 얻어야 하기에, 어쨌든 거의 불가능에 가깝다. 팀장들은 자신과 같이 일하
는 사람들이 다른 곳으로 이동하는 것에 대해서 민감하다. 마치, 사람이 줄어드면 자신의 권한도 줄어든다고 생각하는 것
같다. 물론, 그것도 맞는 말이다. 하지만, 결국 이것 또한 불안함의 증거라고 볼 수 밖에 없다. 사람의 마음을 붙잡아 둘 수
있을 정도의 재미나고 발전적인 일을 팀원들에게 줄 수 있다면, 결국 자신의 팀으로 더 많은 사람이 몰려들 것이다. 팀원들
과 같이 일한다고 그들 모두가 나의 소유는 아니라는 것은 잘알고 있을 것이다. 따라서, 그들의 의견을 최대한 존중하는 것
은 당연하다. 하지만, 많은 관리자들은 자신의 행동과 말에 조심하지 않는다. 쉽게 상처주는 말을하고, 마치 그들의 자신을
위해서 일하는 것으로 착각하고 산다. 미안하지만, 그런 팀장이라면 이제 경력을 마감할 때가 된 것이다. 자신의 발전은 고
사하고, 남들의 발전까지도 가로막는 존재가 되어, 회사의 경쟁력을 감소시키게 된다. 경쟁력은 제품에서 나오지만, 그 제
품을 만드는 개발자의 의지가 반영된다. 그 의지를 꺾는다면, 시장에서 제품을 팔아 이익을 남기는 것이 가능할까? 제대로
만들지 않은 제품이 성공할 가능성은 없다(단기적으로는 좀 팔릴지도 모르지만, 충성심이 강한 소비자는 못찾는다.). 뛰어
난 사람들은 그런 팀장 밑에서 일하지 않고, 자신의 머리가 충분히 굵어졌다고 생각하면, 더 좋은 조건을 제시하는 곳으로
쉽게 가버린다. 우린 그런 사람을 "의리"가 없다(혹은, 배신했다)고 생각할지 모르지만, 이미 신뢰가 무너진 상황에서는 무
의미한 말이다. 사람을 남기는 장사가 아니라, 사람을 파는 장사가 되어버리고 만다.
사람을 뽑을 때는 기준이 높아야 한다. 가능하면 시간을 충분히 두고, 천천히 고르는 것이 좋다. 비어있는 자리라고 아무나
뽑아서는 안된다. 한번 뽑은 사람은 내치기도 어렵고, 다른 사람들에게도 많은 영향을 주기 때문이다. 뽑고 싶지 않은 사람
을 윗사람의 압력으로 뽑아야 하는 상황도 있을 수 있지만, 가능한 그럴 경우에는 자신의 이름으로 판단하지는 않았다는
근거를 남겨야 한다(예를들어, "다른 사람의 의견이 더 필요함"과 같이 면접 결과를 적어놓는다.). 나중에 혹시라도 생길지
모르는 "책임 소재"에 대해서, 자신은 관련이 없다는 것을 명확히 해야한다. 이런 일을 흔히 있을 수 있기에 조심하는 것이
좋다. 그렇다고 무턱대로 윗 사람의 의견에 반대만을 할 수도 없다. 인사 청탁을 배재하고자 한다면, 특정한 사람이 평가를
조작하지 못하도록, 여러 사람이 최종적으로 결정할 수 있는 위원회와 같은 것을 만드는 것도 좋다. 뽑아야 할 사람을 추천
하거나 면접한 사람들을 배제하고, 객관적인 자료를 통해서 해당 인력을 평가할 수 있도록 해야한다. 만약 면접자들이 좋

은 점수를 주었다면, 그렇게 준 근거를 명확히 객관적으로 증명할 수 있도록 요청해야 한다. 아마 이렇게 한다면, 상당 부
분 많은 노력이 인력 충원에 들어가야 할 것이다. 하지만, 이것은 장기적으로 봤을 때 이익이 되는 행동이지 절대 오버헤드
가 아니다. 회사에서 한 사람을 제대로 일을 시키기 위해서 들어가는 비용은 생각보다 크며, 그 사람이 나갈 경우 물질적으
로나 시간적으로 그 피해가 상당하기 때문이다. 따라서, 뽑을 때 제대로 뽑아야 한다. 인사 부서에서는 사람의 역량을 항상
판단하기를 원하지만, 요즘같은 학력과 학점이 고 평준화 된 상황에서는 가려내기가 어려운게 사실이다. 어떤 기술을 가지
고 있는 인력을 뽑아야 할지도 막막하다. 전공분야가 같다고 하더라도 회사에와서 다시 교육을 받아야 할 경우도 많다. 학
교에서 배운 기술이 실무에서 바로 활용할 수 있는 수준까지는 되지 못하기 때문이다. 게다가 기술자가 자신의 전공보다
영어를 더 잘하는 시대에서는, 기술이 가지고 있는 의미마저도 흐려진다. 하지만, 좋은 인력은 어쨌든 표가 나기 마련이며,
그 보석을 찾는 역량은 회사의 역량과 동일하다는 것은 장담할 수 있다.
- 좋은 사람은 주변에 좋은 사람들이 있다.-

[ Style을 익혀야 한다. ][ Style을 익혀야 한다. ]
훌륭한 개발자는 좋은 프로그래밍 습관을 가지고 있다. 이들의 코드를 읽는 것은 다른 사람에게 도움을 주게되며, 한번은
따라해보고 싶은 마음이 생기도록 만든다. 글을 쓰게되면 글쓴 사람이 누구인지를 알려주는 특별한 "맛"을 주는 부분이 있
으며, 이런 것들은 대부분 글을 읽는 사람에게 명확하게 떠오르는 이미지를 만들어준다. 즉, 글을 좀 더 재미나게, 혹은 명
확하게 이해시켜준다. 형식의 파괴라는 것도 등장하지만, 그러한 것들도 글의 문맥을 모호하게 만들지 않으며, 독자에게
의미를 정확하게 전달한다. 프로그래밍도 일종의 언어를 사용하는 것이라고 한다면, 좋은 글쓰기와 다를 바가 없다. 물론,
글을 읽는 대상이 컴퓨터도 포함된다는 점을 제외하면, 프로그래밍 작업은 언어를 가지고 자신의 의도를 설명하는 것이라
볼 수 있다. 따라서, 프로그래머라고 한다면, 명확한 의도를 전달할 수 있는 코드를 만들어주는 스타일(Style)에 익숙해져
야 할 것이다. 하지만, 실제 업무에서 만나는 코드들은 이렇지 못한 경우가 많다. 이유는 다양하겠지만, 결국 프로그래머가
제대로 의도를 표현하는 방법을 모른다는 것으로 밖에는 설명되지 않는다. 일정이 급해서, 일이 많아서, 다른 업무와 겹쳐
서, 빨리하기 위해서, 성능이 문제라서 등등 다양한 이유를 가져다 붙이지만, 결국 프로그램을 제대로 못짰다는 소리로 밖
에는 들리지 않는다. 이제 변명은 그쯤하고, 정말 좋은 코드를 만드는 방법을 배우는데 시간을 쓰는게, 오히려 더 나은 삶
을 살아가는데 필요한 행동이다. 빨리 가고자 한다면 둘러서 가야할 때도 있다.
남이 작성한 코드를 읽는 것은 모든 소프트웨어 개발자가 가장 싫어하는 일 중에 하나이다. 하지만, 항상 다른 사람의 코드
를 보는 것도 소프트웨어 개발자다. 유지보수라는 활동이 특정한 사람들에게만 한정된 것이 아니라, 사실상 실행되는 코드
한줄이 완성된 이후의 모든 추가되는 코딩 활동은 일종의 유지보수라고 볼 수 있다. 즉, 코드를 추가하거나 새로운 기능을
개발하는 것과 같은 활동은, 기존의 코드를 이해하고, 이를 수정하는 것이기 때문이다. 따라서, 다른 사람의 코드를 보는
것을 싫어하는 것과 다른 사람의 코드를 봐야하는 아이러니한 상황에서 개발자들은 매일 일하고 있는 것이다. 자신이 작성
한 코드에 대한 자부심을 가지는 것도 일반적인 개발자의 성향이다. 다른 사람이 자신이 작성한 코드를 마음대로 수정하는
것을 극도로 싫어한다. 마치 자신이 개발한 코드를 자신의 일부와 같다고 생각하며, 코드에 대한 비판을 들었을 때, 자존심
에 금이 간다고 생각하는 것이다. 한편으로는 자신이 작성한 코드에 대한 자부심(혹은, 자만심)을 가진다는 점에서 긍정적
인 효과도 있지만, 고집과 아집을 구별하지 못하는 것으로 볼 수도 있다. 다른 사람이 코드를 읽었을 때 잘 만들어진 코드
라면, 자신의 이름이 다른 사람의 입에서 좋은 단어들과 같이 들릴 것이다. 그렇지 않다면, 당연히 "개선", "수정"등의 단
어와 각종 버그 및 수치들과 같은 연장선 상에서 보일 것이다(혹은, 들릴 것이다). 글쎄? 정말 코드와 자신을 동일시하는
것이 필요할까? 코드가 만일 자기의 분신이라면, 코드를 업그레이드 하는 것을 선택하는 것은 부끄러운 일이 절대 아니다.

프로그램 언어가 지원하는 것을 최대한 잘 활용하는 것도 좋지만, 지나치게 어려운 프로그램을 만들려고 노력하는 사람들
이 있다. 성능이나 코드의 크기로 고민하면서 이런 일들을 하게 되는데, 사실 그렇게 좋은 효과를 거두기는 어렵다. 오히려
코드를 난해하게 해서 고치기 어렵게 만들 뿐이다. 명료한 코드는 짧은 코드와는 다르다. 한 문장에 여러가지를 구겨서 넣
는다고해서, 그것이 컴파일 과정에서 기계어로 어떻게 번역될 지는 직접 코드를 보기전에는 확인하기 어렵다. 오히려 명료
하게 작성된 코드가 컴파일러의 최적화를 이용해서 더 작은 코드와 성능을 가질 수도 있을 것이다. 따라서, 코드를 작성할
때는 "이해(Understanding)"에 초점을 맞춰야지, 최적화된 코드를 만드는 것에 집중해서는 안된다. 물론, 몇 가지 방벙을
사용하는 것도 좋은 효과를 거둘 수 있다. 예를 들어, 모든 파라미터나 복귀 값을 사용하는 CPU에서 제공하는 기본 단위
의 형(Type)으로 정해주는 것은 나중에 변환에 관련된 기계어를 절약할 수 있어서 도움이 될 수 있다. 불필요한 Floating
Point 연산을 없애는 것은 소프트웨어 Emulator를 이용한 Floating Point 연산을 제외할 수 있기(ARM과 같은 경우)에
더 작은 코드와 실행속도를 높일 수 있다. 이런 것들은 사실 사용자의 이해를 개선하지도 저하시키지도 않기에, 프로그램
의 가독성을 낮추는 것은 아니다. 따라서, 이런 팁(Tip)들을 기억해서 사용하는 것도 도움이 될 수 있을 것이다. 어쨌든 중
요한 것은 사람이 작성하는 모든 코드는 사람을 위한 것이지, 컴퓨터를 위한 것이 아니라는 것을 반드시 알아야 한다.
코드의 이해도를 높이는 것은 전체적인 비용 절감이 가장 큰 활동이다. 지식산업의 특성상 고임금의 노동력이 창조적인 일
에 더 많은 시간을 들이는 것이, 생산성을 높여서 전체적인 비용을 줄이는 방법이다. 결국 소프트웨어는 구현되어 동작해
야지만 가치를 가질 수 있다. 그런 코드를 만들기 위해서 많은 시간을 코드를 이해하는데 보낸다면, 개발 생산성은 결국 낮
아질 수 밖에 없다. 실제로 평균적으로 하루에 작성되는 코드의 양은 10라인이 안되는 것도 흔하다. 이유는 테스트와 디버
깅에 지나치게 많은 시간을 투입해서, 전체적인 과제의 입장에서 일정지연의 대부분을 코드를 이해하는 시간으로 보내기
때문이다. 유지보수의 속도는 제품의 개선으로 바로 연결되며, 적절한 시장의 요구를 끊임없이 빠르게 대응하지 못한다면
결국 경쟁력은 상실하고 만다. 물론, 현실적으로 이런 것들을 잘하자고 이야기면 개발자들은 마치 자신과는 상관없거나,
자기의 코드에는 문제가 없다고 무관심하기 마련이다. 스타일은 개인의 문제가 아니라 팀과 회사의 문제이며, 경험으로 증
명된 일관된 스타일은 서로에게 상승효과를 줄 수 있다. 좋은 코드를 만드는 것이 습관화 된 것이 스타일이며, 그런 스타일

이 자연스럽게 흘러나오는 코딩이라면, 자신이 일하는 조직은 당연히 우수할 것이 틀림없다. 우수한 팀에서 함께 일한다는
것만으로도 회사 생활은 달라질 것이다. 무언가 배울 수 있는 조직이라면, 새로운 문화를 만들어나가기도 훨씬 수월할 것
이다.
- 명확성(Clarity)은 "짧게 만드는 것"과 같은 의미가 아니라, 다른 사람을 돕는 일이다. 도움을 주는 사람의 입장이 아니
라, 받는 사람에게 가치가 있어야 한다.-

[ 강요받는 동의 vs. 자유로운 거부 ][ 강요받는 동의 vs. 자유로운 거부 ]
개발자나 관리자 모두 우린 어떤 일에 대해서 책임을 가지기를 요구받는다. 그 책임을 거부할 경우, 책임감이 부족하거나
자신감이 없다는 자존심을 건드리는 말들을 듣게된다. 우린 인격적으로 나무라는 말을 듣는 것을 극히 싫어하기에 대체로
동의하는 것으로 대화를 마무리 짓지만, 그것이 옳다고는 생각하지 않는다. 당연히 옳지않다는 것을 안다면, 자신이 책임
질 이유도 없다고 판단할 것이다. 물론, 그것은 혼자만의 생각이다. 명령을 내린 사람은 자신이 충분히 의사를 전달했으며,
동의를 얻었다고 믿을 것이기 때문이다. 이러한 명령권자의 생각도 따지고보면 혼자만의 생각일 뿐이다. 우린 서로 대화를
하고 있지만, 소통하지는 못하고 있는 것이다. 강요는 다양한 형태로 주어진다. 회의석상에서의 지시와 암묵적인 동의를
강요받거나, 회식자리에서 거부하지 않았다는 이유로 동의했다고 판단해서 축하주를 마시는것, 과제 협의때 공공연한 일
정 발표등등 거부할 수 없도록 만든다. 아니, 거부한다면 그 즉시 이유와 설명할 근거를 만들어 오라거나, 난처한 질문으로
묵살해버리기 일쑤다. 거부할 수 있는 권한이 없다고 하는 것이 더 옳을 것이다. 마지못해서 "생각해보고 알려드리겠습니
다."라는 대답을 했지만, 이미 결정난듯이 행동하고는, 나중에 "안되겠습니다"라는 말을 하러가면 왜 이제와서 반기를 드
냐고 따져 묻는다. 우린 솔직해야 한다는 미덕(혹은 용기)을 버리고, 가식적이고 비굴한 동의를 하고만다. 여기서 끝이라
면 좋겠지만, 자신의 경력중에서 가장 어려운 시기는 그런 "강요된 동의"후에 발생하는 일들이 될 것이다.
과제 일정에 대한 "강요된 동의"는 약속이 아니라 거짓말이다. 하지 못하는 것을 할 수 있다고 이야기하는 것은 책임을 가
진 능동적인 사람이 할 수 있는 말이 아니다. 더 정확히 말한다면, 아무 생각이 없고 책임감도 없는 헛된 대답일 뿐이다. 책
임감이란 말 그대로 행위를 결정할 수 있는 능동적인 존재에게서 나온다. 무책임한 태도란 능동이 결여된 사람에게 할 말
이 아니다. 굳이 책임을 묻는다면, "거부하지 못한 태도"밖에는 없을 것이다. 그마저도 생존이 걸린 문제라면, 자기방어로
서 나온 말이기에 "법적인 책임"을 물어서는 안된다. 오히려, 그런 분위기를 만들고, 강요한 사람들에게 "범죄(혹은, 거짓
을)를 사주한 죄"를 물어야 한다. 다 아는 이야기지만, 그런 사람들은 대부분 책임은 다른 사람에게 씌우고, 트로피는 자신
에게 안겨주는데 익숙한 사람들이다. 그런 사람이 주위에 있다면, 힘든 조직생활이 될 것은 눈에 안봐도 뻔하다. 물론, 세
상에는 그런 사람도 있고, 그렇지 않은 사람들도 많다. 잠시 소나기를 피하면 맑은 하늘이 날 것으로 기대할 것이다. 하지
만, 그런 사람들의 영향력은 오래간다. 최소한 명령을 듣는 사람은 자신도 모르게 속옷까지 점차 젖어가기 때문이다. 오래
동안 그런 환경에 노출된다면, 자신도 모르게 다른 사람에게 그렇게 하고있는 스스로의 모습을 보게될 것이다. 우린 환경
에 적응하기 위해서 스스로를 변화시킬 수 있는 동물이기에, 노출된 환경이 무엇이냐에 따라 스스로를 더 방어적으로, 혹
은 좀더 주도적으로 행동한다. 방어적인 사람은 공격적으로 변화될 것이고, 공격적인 사람은 적극저인 거부를 행사할 것이
다. 어떤 생각을 가지고 있든, 그런 상황은 결코 유쾌하다고는 볼 수 없다. 최선은 결국 그런 상황이 발생하지 않도록 미연
에 막는 것일 수 밖에 없다.

미연에 방지하기 위해서는 서로간에 "신뢰"를 만드는 일을 먼저 해야한다. 신뢰감은 한번에 생성되는 것이 아니며, 꾸준한
작은 일에 대한 약속을 지키는 것으로 만들어진다. 지금까지 자신이 어떻게 일해왔는지를 보라. 약속한 것들을 제대로 지
켜본 적이 있던가? 만약 그렇다면, 그때는 어떻게 그 약속을 지킬 수 있었던가? 과제를 보도록 하자. 과제의 일정을 제대로
지켜낸 적이 있었는가? 어떻게 그것을 지킬 수 있었는가? 아마도 초보 과제 담당자가 아니라면 적어도 하나 정도의 작은
과제라도 성공한 기억이 있을 것이다. 그런 경험들과 꾸준한 지시사항에 대한 피드백이 관리자에게 실무자로 부터 전달되
었다면, 당연히 관리자도 일정부분 "신뢰"감을 키워왔을 것이 분명하다. 그런 것들이 없는 상황이라면, 둘 다 서로간의 이
해관계만이 있었을 뿐이며 친분을 쌓는것을 극히 두려워 한다고 볼 수 밖에 없다. 신뢰하지 못하는 관계라면 어떡하든 결
과를 만들어내고자 할 때, 당신이라면 어떤 방법을 쓰겠는가? 아마도 똑같지 않을까? 뭔가를 일찍 확인해보고 싶어하는
욕구가 생길 것이다. 혹은, 자신만의 생각으로 상대방의 감정이나 생각은 무시하려고 할 것이다. 신뢰하지 않는다면 시켜
서도 안된다. 일단 일을 시키면 그 사람이 말하는 것을 믿어야 한다. 설령 거짓말을 하더라도 일단은 믿어야 한다(물론, 항
상 거짓말로 사람을 속이는 과제 담당자도 있다. 특히, 승진이나 다른 목적이 있을 경우에는 그런 것이 더 심하다. 심지어
다른 사람이 한 성과도 자신이 했다고 할 수 있다). 강요된 동의를 요청받는다면, 일단은 한걸음 물러서서 언제까지는 답변
을 주겠다고 확인하도록 한다. 그리고, 될 수 있으면 할 수 있는 방법을 찾되(보통 이런 과제는 반드시 할 수 밖에 없는 경
우가 많다.), 협상안을 준비하는 것이 좋다. 얻을 수 있거나 줄일 수 있는 것을 최대한 해야한다. 그냥 막무가내로 해야만
하는 불가능한 일이라면 못한다고 이야기하고, 최악의 경우를 각오하는 것이 좋을 것이다.
물론, 우리나라 같은 개발 분위기에서는 일을 못하겠다고 하더라도 짤리는 경우는 거의 없다. 다만 성가실 뿐이다. 자신에
대한 선입견이 사람들에게 생길 것이고, 연봉이 깎일 것이며, 회의에서 소외될 가능성이 높다. 그리고, 자신의 팀이 사라지
고, 엉뚱한 부서로 이동도 해야할 수 있다. 하지만, 거짓말로 동의하는 것보다는 자신에게 떳떳할 수 있다. 더 중요한 것은
회사에서 "아니다"라고 말할 수 있다는 것을 사람들의 마음에 심어줄수 있다는 점이다. 자신이 없다면 그냥 모르겠다는 애
매한 태도로 일관하는 것도 한가지 방법이다. 확신이 없는 일에 매달리는 것은 어리석다고 생각되기도 하지만, 사실 확실
한 일만하는 것은 별로 자신의 역량을 높이지 못하고 성과도 크지 않다. 일에는 항상 어느 정도의 리스크는 있는 법이다.
특히 도전적인 일이라면 더 리스크가 클 수 있다. 여기서 이런 리스크를 감당하고도 일할 수 있는 분위기를 가진 회사라면
당연히 좋은 회사일 것이다. 리스크가 크지 않은 일만 골라서 하면서 승진을 바라는 것은 소위 말해서 일종의 담합과 같다

(같은 라인에서 서로 끌어주고 밀어주는). 그렇다고 무조건 큰 리스크의 일을 아무런 대책도 없이 할 수는 없다. 리스크가
있다는 것을 모두에게 인지시키고, 그래도 그것을 한다는 것을 알려야 한다. 적어도 강요된 동의는 아니지만, 자발적으로
인지된 리스크에 대한 적극적인 감소 노력을하게 될 것이며, 실패가 생기더라도 홀로 판단하지 않은 것이라는 점을 강조해
책임을 분산시킬 수 있기 때문이다. 혼자 실패의 책임을 다 떠안는 것은, 왠지 억울하다. 일을 시작하게되면 처음부터 실패
할 것이라는 것을 가정해서는 안된다. 그리고, 항상 진행 상황을 전체 관련자들과 공유해야 한다. 언제든지 실패할 것이라
고 생각되면(혹은 만들어봐야 별로 가치가 없다면) 그 즉시 중단할 수 있도록 해야한다. 지금까지 투자한 것이 아까워서 계
속가는 것은 더 많은 비용을 낭비할 뿐이다.
- 한번 하겠다고 한 것은 반드시 해야하고, 그렇지 않다면 거부하라(그전에, 반드시 실력을 갖추고 어디로 갈지도 정하기
를). -

[ 직관을 믿으라 ][ 직관을 믿으라 ]
경험이 많은 전문가들은 어떤 문제를 해결할 때, 자신의 경험과 지식을 기초로 데이터를 보지않고도 대략적인 추정이나 해
답을 만들어낼 수 있다. 이 사람들은 이미 어느 정도 수준에 올랐기 때문에, 일의 범위를 대략적으로 예측하고, 그에 대해
서 추정과 계획을 세울 수가 있다. 예를 들어, 개발자들이 90%이상 구현이 완료되었다는 말을 듣는다면, 이제는 지금까
지 보낸 시간 만큼 더 시간이 필요하겠다는 것을 거의 본능적으로 깨닫는다. 그들은 개발자들이 몇% 구현되었다는 말이,
말 그대로 코딩만 했을 뿐이며, 검증되지 않은 결과물만 만들었다는 것을 알기 때문이다. 아마 개발자들이 만들어야 할 기
능이 몇 가지고, 그중에 어떤 어떤 기능들이 구현되었으며, 테스트를 얼마나 통과했는지를 이야기 한다면, 더 정확한 추정
을 만들어낼 수도 있을 것이다. 직관은 아키텍처를 만들때도 사용된다. 즉, 문제의 유형을 보고, 그것을 위한 전체 시스템
의 모습을 머리속에 그리게 되며, 많은 모델을 만들었다가 부수는 과정을 반복적으로 실험해 볼 것이다. 그들의 고민은 가
능한 모든 오류 상황을 검토했을 것이고, 성능에 대한 우려도 어느 정도 해결할 수 있는 구조를 채택했을 것이다. 따라서,
전문가의 주관이 다분히 많이 들어간 구조 설계는 사실 굳이 상세히 검토하지 않아도 정확한 해답일 수 있다.
가장 어려운 것은 역시 관리자들을 설득하는 일이다. 그들은 정확한 데이터를 기반으로 문제에 대한 해답을 만들기를 원한
다. 하지만, 소프트웨어 개발은 쌓아놓은 데이터가 없는 상황이 많으며(대부분 제대로 소프트웨어를 개발해 보겠다는 의
욕을 막 가지기 시작한 회사들의 경우), 당연히 판단할 근거도 없다. 이런 상황에서는 나름대로 가장 좋다고 생각하는 추정
을 아무런 근거도 없이 내리게 된다. 이것은 과제를 해본 전문가의 직관이 아니라, 비 전문가가 전문가인체 하면서 내리는
단정이다. 이런 단정을 근거로 만든 일정 계획이나 비용 예산등은 절대 제대로 지켜질리가 없다. 문제를 해결하기 위해서
끊어진 단계만 생각하는 사람들은 모든 나누어진 단계들이 실제로는 한 몸통으로 굴러가야 한다는 것을 깨닫지 못한다. 무
엇인가를 하기 위해서는 입력이 있고, 가공 활동이 들어가며, 출력된 산출물이 있어야 한다는 사실만 기억한다. 당연히 그
런 산출물을 만들어내는 것으로 단계가 완료된다고 생각한다. 하지만, 안타깝게도 그렇게 끊어진 단계의 산출물들은 활용
되지 않고, 시스템의 한쪽 귀퉁이에서 저장 공간만 잡아먹는 경우가 많다. 이는 소프트웨어 개발자들이 보여주려고 생각하
면 얼마든지 가짜를 만들어서 일이 진행되고 있는 것 처럼 만들 수 있다는 말이다. 차라리 비 전문가라고 한다면, 정말 잘
하는 전문가를 고용해서 그 사람에게 맡기는 편이 훨씬 더 좋은 결과를 만들 수 있을 것이다. 그들의 직관이 가리키는 끝점
이 과제를 끝낼 수 있는 진짜 완료일이기 때문이다.

직관은 앞에서도 설명했듯이, 많은 경험이 쌓여서 만들어지는 결과물이다. 따라서, 전문가라고 한다면 해당 분야의 지식과
실제 구현을 몇 차례이상 반복해서 해본 사람을 말한다. 그는 내부적인 기술의 깊이도 있지만, 전체적인 시스템의 모습을
머리속에 그리고 있으며, 어디로 가야할지 방향성도 지시할 수 있는 사람이다. 시장의 트렌도 알면서, 세부적인 구현 기술
들을 모두 머리속에 지니고 다니기에, 마치 뜬 구름잡는 이야기를 하는 것 처럼 들리지만, 고수는 고수를 알아보기 마련이
다. 그 사람의 능력이 의심스럽다면, 다른 자신이 알고 있는 전문가에게 의견을 구해보면 쉽게 파악할 수 있을 것이다. 그
들에게 책임을 묻기 위해서는 그들의 권한을 확실히 보장해 주어야 한다. 그들은 자신이 생각하는 바를 만들기 위해서 존
재하는 사람들이지, 남들의 지시로 만들어지는 것에 손놓고 기다리는 사람들이 아니다. 그들이 결정할 수 없는 문제가 있
다면, 그것은 과제와 외적인 요소들일 것이다. 그런 부분들은 물론 누군가가 나서서 도움을 줘야한다. 그외에 사소한 것 하
나 하나씩을 전부 따지고 들어가면, 그들은 일을 할 의욕을 상실하게 되며, 자신의 역할이 없다는 것을 알게된다. 역할이
없이 돈만 축내는 사람은 어떤 개발자도 되고 싶어하지 않는다. 기본적으로 사람은 일하려는 의지를 가지고 있으며, 그 의
지를 실행에 옮길 수 있는 것을 찾아낸다면, 쉽게 생산적인 사람으로 바뀔 수 있다. 그것의 동기를 마련하는 것이 바로 "자
율"이며, 개인의 차이를 인정하는 회사의 분위기다. 모두다 일률적으로 똑 같은 행동과 생각을 강요받는다면, 그것은 동기
없는 일이 될 뿐이다.
동기가 없이 일하면, 그 결과물의 품질을 당연히 만족과는 차이가 클 것이다. 움직이려고 하지 않는데 억지로 밀어봐야 힘
만 낭비할 뿐이다. 사람을 다루는 방법이 서툰 사람들은 대체로 말을 많이 하는 편이다. 이는 그 만큼 사람이 잘 따라오지
않기 때문에, 계속 지켜보면서 이런 저런 사소한 것까지 전부다 관여하게 되기 때문이다. 직관을 믿는다면, 사람이 가진 잠
재력도 믿어야 한다. 일을 하는 사람들은 최소한 관리자보다 자신이 하는 일에 대해서는 더 잘 알고 있는 것이 분명하기 때
문이다. 그리고, 일을 직접하는 사람들은 일이 잘못 되기를 바라는 것이 아니라, 제대로 일을 하기를 원한다. 따라서, 사람
을 정말 잘 다루는 사람들은 사람들의 "마음"을 관리하게 된다. 관찰력을 가지고 있지만, 사소한 행동보다는 그 사람의 내
면에 있는 생각을 읽으려고 애쓴다. 물을 먹게 만들려면 갈증을 느끼게 해야하고, 옷을 벗게 만들려면, 따스한 햇살이 난
곳을 땀흘리며 돌아다녀야 한다. 따라서, 일을 제대로 열심히 하게 만들려면, 될 수 있으면 말을 아껴야 한다. 같은 말이라

도 누가하면 잔소리가 되지만, 다른 사람이 하면 "충고"가 될 수 있는 것은, 언제 말을 할 것인가에 달려있다. 직관은 여기
서도 중요한 역할을 한다. 누군가 어려움이 있는지는 알기 위해서는, 그 사람과 꾸준한 관계를 맺으며(아무리 사소한 말이
라도 주고 받으며) 꾸준히 관찰해야 한다. 그리고, 무언가 잘 안되고 있다는 느낌을 받을 경우에 나서는 것이 가장 효과적
이다. 그때 얻게되는 말 한마디는 그 사람에게는 정말 필요한 진실한 답은 아닐지라도, 그 답을 유추하는데 필요한 시발점
은 될 수 있을 것이다. 그 순간을 너무 자주 만들려는 의도는 오히려 거짓된 답변만을 듣게 될 것이다.
- 나를 알 수 없는 것은 스스로의 직관으로는 자신을 판단할 수 없기 때문이다. 하지만, 남을 통해서 나를 보는 것은 가능하
다.-

[ 객체지향 개념 ][ 객체지향 개념 ]
객체란 무엇일까? 만약 이런 질문을 대학생들에게 한다면, 오브젝트, 클래스, 정보 은닉, 상속과 같은 자신들도 잘 모르는
개념들을 이야기 할 것이다. 면접에서 객체지향이 무엇이냐는 질문에 대부분 제대로 대답하지 못한다. 그들은 프로그래밍
이 가지고 있는 근본적인 문제가 무엇인지를 이해하지 못하는 상태에서 객체지향 언어를 사용해서 코딩을 배웠기 때문에
그렇다. 최근에는 자바나 파이선, 각종 스크립트 언어들이 많이 사용되고는 있지만, 근본적으로 프로그래밍이 해결하려는
문제는 복잡함을 다루는 기술에 있다. 코드가 짧을 때는 유지보수 비용이나 수정 비용등이 적게 들고 잘 보이지 않는 것처
럼 생각되지만, 조금만 코드량이 늘어나면 복잡성은 쉽게 눈에 보이게 된다. 코드들은 난잡하게 서로가 서로를 의지하는
구조로 바뀌고, 제대로 된 역할의 구분이나 책임의 범위도 모호해 진다. 이런 상황에 더해서 잘못된 스타일을 익힌 상태로
상업적인 코딩에 들어가게 되면, 그야말로 야근과 특근의 아비귀환으로 빠져드는 회사 생활이 되어간다. 그런 문제는 누가
만들었으며, 누가 해결해야 하는가? 당연히 소프트웨어 개발자 스스로가 해결하지 않으면 아무도 도와주지 않는다. 따라
서, 객체지향이 어떻게 문제를 해결해가는지, 그 해결 방법이 왜 중요한지를 충분히 이해한 후에 코딩을 해야한다. 그렇지
않다면, 단순히 영어 문법만 잘 알고, 제대로 대화하지 못하는 영어 실력자만 양산하게 될 것이다.
객체지향의 문제 해결은 자신의 역할과 책임 범위를 정하는 것으로 시작된다. 즉, 자신이 구현할 모듈이 어떤 역할을 할 것
이며, 어디까지가 책임의 범위인지를 명확히 하는 것이다. 내부에는 다시 더 작은 것들이 역할과 책임을 나누어 가질 것이
다. 단일 객체는 한가지 역할과 책임 범위를 가진다. 따라서, 자신의 역할이 아닌 것은 다른 객체에게 의뢰해서 처리하도록
요청한다. 객체간에는 상속과 포함 및 합성, 연관 등의 관계가 있으며, 그 관계는 일을 처리하는 과정에서 보이는 문제 도
메인에서 유추될 수 있다. 상속이 길어지면 객체들 간의 의존성이 강해지기에 될 수 있으면 상속보다는 인터페이스를 통한
계약(Contract)를 유지하는 것을 선호하며, 하나의 객체가 변한다고 다른 객체에게까지도 영향을 주지 않도록 인터페이
스와 구현을 분리하는 것을 사용한다. 복잡함을 다루는 핵심은 추상화에 있기에, 추상화의 핵심인 추상데이터 타입
(Abstract Data Type)을 사용자가 확장해서 만들 수 있는 클래스 개념을 지원하고 있으며, 이를 이용해서 실제 문제 도메
인에서의 계층적인 추상화 개념을 표현해 낼 수 있다. 즉, 프로그래밍이 문제의 분석과 데이터 및 제어의 흐름을 모방하고,
이를 맡아서 처리할 객체의 추상 데이터 타입을 정의하는 것으로 시스템의 중요 구성요소들을 확인(Identify)할 수 있다는
것이다. 확인된 객체들이 어떤 관계를 맺어야 하는지를 정해서 이를 구조화시켜 시스템의 뼈대를 만들고, 변화가 가능한
부분들에 대한 계약을 만들어두는 것도 잊지 않는다. 따라서, 객체지향에서의 문제 해법은 객체들간의 소통을 통해서 각자
의 역할을 충실히 수행하는 것이 된다.

따라서, 객체지향으로 코딩하려면 순차적인 처리보다는 객체들의 관계 및 그들간의 역할과 책임을 활용한 문제 해결법을
익혀야 한다. 어디서 시작해서 어떤 순서로 해야지만 해답을 구하는 것이 아니라, 시스템을 구성하는 요소들을 식별하고
(도메인에서), 그것들이 어떻게 역할을 분담하고 있는지를 모델을 통해서 밝혀야 한다. 객체라는 의미는 특성과 행위를 가
진다는 말로서 주체적인 입장에서 문제를 해결하는데 참여할 수 있다는 뜻이다. 따라서, 순차적으로 문제를 해결하는 방식
에서 객체간의 협력으로 바뀌게 된 것이다. 객체는 특성으로 자신이 담고 있는 정보를 표현하고, 자신에 대한 의뢰를 행위
를 통해서 받게된다. 대부분의 특성은 외부에 직접적으로 공개되지 않아야 객체내부의 변경이 외부에 미치는 영향을 최소
화 할 수 있으며, 정해진 통로를 통해서 전달된 메시지만을 처리하기에 계약을 강화시킬 수 있는 방법을 가진것이다. 따라
서, 그외의 객체에 대한 접근은 엄격히 제한된 구조를 가진다. 객체들간의 관계는 동등한 관계, 종속된 관계(포함 관계), 상
하 관계, 동일한 메시지에 호출을 받는 관계등으로 구분될 수 있으며, 이를 관계들을 표현하는 내용은 시스템에서 동적으
로 생성되어 관리되게 된다. 특히, 객체간에 포함 관계를 가지고 있다면, 부분과 그 부분들의 합으로 특정 객체를 집합적인
개념으로 생각해 볼 수 있도록 하며, 마치 객체를 이루는 부분들의 상세함을 따지지 않고도, 해당 객체에 일을 위임해서 처
리하도록 요청할 수 있다. 추상화로 따지면, 더 상위의 개념을 가진 객체가 하위 객체들을 이용해서 자신이 요청받은 일을
하위의 객체들이 처리하도록 만든다는 것이다. 따라서, 시스템적인 사고란 추상화를 구체화로, 다시 구체화를 추상화로 묶
어 더 높은 수준에서 문제를 바라볼 수 있도록 하는 것이다.
객체를 나누기 위해서는 제어의 흐름을 추적하는 것보다 데이터의 흐름을 추적하는 것이 좋다. 데이터가 있는 곳에, 그 데
이터의 처리 역할을 맡은 객체가 있기 마련이다. 물론, 제어적인 측면에서 그 주체가 누가 되는지를 알아야 한다. 특성과
행위를 가지고 있다는 말은 자신이 처리할 데이터를 특성으로 만들고, 그것을 처리하도록 요청하는 메시지를 행위로 정의
하기 때문이다. 하지만, 데이터만을 가지는 객체도 가능하며, 행위만을 정의하는 객체도 물론 가능하다. 이때, 객체를 테스
트를 쉽게 만들기 위해서는 내부에서 정보를 생성하도록 만들기 보다는 외부에서 의존적인 정보를 삽입할 수 있는 방법으
로 만들어주면 도움을 얻을 수 있다. 이런 방법이 의존성 삽입(Dependency Injection)이라는 것으로, 객체 내부에서 일
어나는 변화를 외부에서 확인하기 위한 것이다. 즉, 객체의 내부에 객체가 의존적인 정보를 가지는 경우, 외부에서 확인할

수 있는 방법이 없기 때문에, 외부에서 의존성을 삽입해 주는 방법이다. 삽입되는 정보는 객체가 의존하는 다른 객체나 데
이터 등이 될 수 있다. 물론, 객체지향에서만 사용되는 기술은 아니지만, 정보의 은닉이 중요한 객체지향 언어에서는 효과
적인 테스트 방법이라고 볼 수 있다. 객체들은 자신의 역할 범위를 넘어서거나, 자신에 종속적인 객체들이 해야할 일은 직
접처리하지 않고 위임(Delegation)을 사용한다. 위임으로 인해서 메시지 처리를 위한 경로가 길어지기는 하겠지만, 이는
구체적인 일을 메시지 형태로 지시하는 것을 추상적인 의미를 가지도록 한단계를 높여서 메시지를 전달할 수 있기에, 객체
에 처리를 의뢰하는 입장에서는 좀더 문제를 도메인에 적합한 언어로 표현할 수 있는 가능성을 열어놓는다. 따라서, 객체
는 자신의 추상화 수준에서만 문제를 처리하고, 더 구체적인 처리를 요할 때는, 자신보다 더 구체적인 객체들에 메시지를
전달하는 위임을 사용하게 된다. 객체지향은 문제를 바라보는 시간과 사용하는 용어에 대해서 이처럼 다양한 해법을 구축
할 수 있는 좋은 사고 방법을 제공한다.
- 객체라는 말이 머리속에 그려진다면, 이미 객체지향으로 생각하고 있다는 뜻이다. -

[ 관리란 무엇일까? ][ 관리란 무엇일까? ]
관리자들은 관리자 교육을 받지 않고 관리지가 된다. 그리고, 관리자를 하면서 타고난 관리자가 되거나, 관리라는 이름으
로 비 관리적인 태도를 보이게 된다. 열심히 일만 하던 사람들이 관리자가 되면, 모든 업무가 자신의 머리속에 들어오지 않
으면 불안감을 가진다. 그리고, 일일이 모든 일에 대해서 꼼꼼하게 관찰하고 지시하게 된다. 자신이 직접 보지 않거나 검토
하지 않은 것은 자신의 권한 밖에 있는 부서로는 전달되지 못하게 하며, 아무리 사소한 것이라도 반드시 자신의 허락을 받
으라고 요구한다. 따라서, 그 사람의 밑에서 각각의 파트를 담당하고 있는 중간 관리자들은 권한은 없고, 책임만 있는 존재
로 변하게 된다. 책임과 권한이 분리된 상태라면, 어떤 일을 해서도 안되고 안해서도 안된다. 책임을 만들 일을 하는 것은
회사 생활이 괴롭게 되고, 그렇다고 아무 일도 하지 않으면 고과가 나쁠 것이기 때문이다. 이런 상태라면 위험(Risk)가 있
는 일은 절대 시도하려고 하지 않을 것이다. 가능하면 쉬운 일, 문제가 잘 발생하지 않는 일, 남이 책임을 지는 일들을 찾아
다닐 것이고, 조금이라도 책임질 자리에 올라가지 않으려고 할 것이다. 나름 좋은 점도 있다. 왜냐면, 그런 사람일수록 다
른 조직과의 대화에서는 강수를 뚜는 경우가 있기 때문이다. 문제를 밖으로 표현하지도 않지만, 자신이 관리하는 영역에
대해서는 남들의 간섭도 받기 싫어하기에, 일종의 우산 역할을 자청하는 것이다. 하지만, 자신의 조직에서 문제가 생기면,
적극적으로 그 문제의 당사자와 자신을 분리하려고 한다. 자신은 완벽한 사람이어야 하기에, 절대 문제가 없는 사람이어야
한다는 것을 알게 모르게 자신에게 강요하면서 살아온 인생이기 때문이다.
모든 관리란 사람에게 집중된 일이다. 즉, 사람을 관리하는 것이 가장 핵심이다. 하지만, 사람은 관리하는 것 자체가 가장
힘들고 까다로운 존재다. 원하는 것도 많고, 불평도 많이하며, 심한 압박을 받으면 반발하는 존재이기 때문이다. 무조건 명
령을 해서 움직이도록 만든다고, 그 사람이 일을 잘하리라는 보장도 없다. 그냥 모나지 않을 정도로(문제가 생기지 않을 만
큼만, 중간 정도의 등수에 들면 된다는 생각으로)만 일한다. 따라서, 이런 사람들을 관리하는 것은 하나에서 열까지 일일이
지시해야 하는 일이 되어서는 안된다. 물론, 그런 것을 좋아하는 사람들도 있다. 소위 말하는 "마이크로 메니지먼트"를 표
방하는 사람들은 작은것 하나 하나를 놓치지 않고 계속 지시한다. 그 사람들은 항상 바쁘다. 하나 하나 전부 지시해야하고
확인해야 하기에 바쁘다. 모든 결정을 자신만이 할 수 있기에, 그 사람에게 보고하는 대기열을 항상 길어지게 마련이다. 업
무의 병목은 다른 사람도 아닌, 결정권을 손에 쥔 사람이 되어버린다. 그 사람이 지시하지 않거나 동의하지 않은 일들은 아
무런 진척이 없게된다. 자기는 나름 열심히 회사에서 일하고 있다고 생각할지도 모르지만, 회사는 점점더 의사 결정이 느
려지며 제대로 되는 일도 없어진다. 당연히 똑똑하고 창의적인 사람들은 그런 회사에 남아있기를 싫어하고, 다른 좋은 조
건의 직장에 자리가 생기면 즉시 퇴직원을 내고만다. 관리의 측면에서 가장 큰 손실은 사람을 잃는 것인데, 더군다나 똑똑
하고 창의적인 개발자를 잃게 되는 것은 그 몇 배의 손실을 회사에 입히는 것이 된다. 예전에 알던 사람이 진급하면 성공적
으로 자신의 역할으 수행하는 사람과 실패하는 사람이 있다고 이야기 한 적이 있었다. 하지만, 그는 정말 큰 실패는 똑똑하
고 멋진 개발자를 잃는 것이라는 것은 알려주지 않았다. 그 사람은 사람이 소중한 존재라는 것을 알지 못했던 것이다.

사람은 자원이 아니다. 사람을 자원(Resource)로 취급하는 것은 잘못된 생각이다. 만약 자원이라고 생각한다면, 군대의
양성소에서 나오는 신병으로 대해서는 절대 안된다. 노련한 지위관이 많은 병사를 소모하면서 고지를 점령하면 훈장을 따
는 싸움을 회사에서 하고자 한다면, 회사는 오래가지 않고 망할 것이다. 사람은 대체가 불가능한 자원이며, 다른 사람으로
대체하기 위해서는 일정 지연과 품질 저하를 한동안 겪은 후에야 가능해 진다. 그리고, 좀 심한 경우에는 완전히 대체 불가
능한 인력들도 있다. 물론, 그렇게 대체 불가능한 존재들을 회사에서 많이 가지고 있다고 좋은 회사는 아니다. 언젠가는 그
들이 없이도 굴러갈 수 있는 체계를 구축한 회사가 궁극적으로 사업을 이어갈 것이다. 사람은 자원이 아닌 환경이어야 한
다. 뛰어난 인력이 머무는 자리에는 좋은 사람들이 모이기 마련이다. 그리고, 옆에 있는 사람들도 그 사람에게 동화되도록
만든다. 그리고, 좋은 개발환경을 제공하는 회는 회사로 좋은 사람들은 모이기 마련이다. 환경에서 돈이 차지하는 부분은
기본적인 생존 조건정도 밖에 되지 않는다. 중요하지 않다는 것이 아니라, 그것만으로는 좋은 사람을 끌어들이지 못한다는
것이다. 그들이 원하는것은 자신이 하고 싶어하는 일에 자신을 맡기는 것이다. 재미없는 일이나 따분한 일을 명령을 받아
가면서 하고 싶은 뛰어난 개발자는 없다. 그들은 이미 뛰어나다는 것을 아는 더 좋은 회사로 갈 수 있는 역량이 충분하다.
그런 사람들을 관리하는 이름아래 억지로 일을 시키고, 대체 가능하다는 명목으로 아무렇게나 업무를 할당한다면, 결국 그
것은 가장 소중한 자원을 관리하는 것이 아니라 낭비하는 것일 뿐이다. 대체 가능한 자원들만 있는 회사는 이미 회사가 아
닌 전쟁터일 것이다(물론, 회사를 전쟁터로 비유하는 사람들이 있긴하지만, 그들은 절대 목숨은 내놓지 않는다.).
관리자들이 실패하는 것은 너무 많은 일을 혼자서 하려하기 때문이다. 관리는 남을 부리는 것이지, 자신이 부림을 당하는
것이 아니다. 남에게 일을 시키고, 그 결과가 나올 때까지 기다릴 줄 알야야 한다. 일을 시킨다는 것은 그 일을 맡긴 사람에
게 권한도 부여한다는 것이며, 그 사람이 일하는데 막힘이 있을 경우메만 나서야 한다는 점이다. 자신이 모든 것을 다하겠
다고 나서면, 중간 관리자의 역할이 없어지게 된다. M:N;1로 만들어야 할 것을, M:0:1로 만들어서는 아무일도 제대로 진
행될 수 없다. 혼자서 모든 것을 다하려고 한다면, 결국 일을 더디게 만드는 것은 실무자들이 아니라 관리자가 된다. 현장
에서 일하는 실무자가 가장 많은 정보와 지식을 가지고 있으며, 행동의 결정을 내리는 것은 그들이 직접 판단한 것이 올바
르다. 마치 전문 UI개발자가 만든 것을 관리자가 보고 마음에 안든다고 바꾸라고 이야기 한다면, 그것이 올바른 결정인 이
유가 있을까? 그건 그냥 자신이 최고로 잘났다는 뜻 밖에는 되지 않는다. 만약 다음에도 그런 일을 의뢰 받는다면, UI개발

자는 사용자가 아닌 관리자의 취향을 고려해서 만들것이 분명하다. 관리자는 회사의 물건을 사는 사람이 아니라, 회사로부
터 돈을 타가는 사람이다. 그것도 일반 구성원보다 훨씬더 많이 가져간다. 그들이 판단해야할 것은 그런 사소한 것들이 아
니라, 좀더 고차원적인 전략이나 방향성에 통찰력일 것이다. 버그의 갯수가 몇 개이고, 테스트 케이스가 몇 개인지를 중요
하다고 이야기하기 보다는, 버그를 줄이기 위한 방법론을 잘아는 사람들 고용하는 편이 훨씬 더 효과적일 것이다. 결국 일
은 전문가들이 하는 것이고, 그 일이 되도록 만들어주는 것이 관리자가 할 일이다. 정보가 있는 곳에서 판단이 있어야 하
며, 현장 경영이란 현장에서 내리는 관리자의 결정이 아니라, 현장 사람들이 내리는 결정을 관리자가 관철시키도록 돕는
것이다.
- 전문가가 왜 필요한지... 관리자들은 스스로 자신에게 물어야 한다.-

[ 결정할 수 없다면 미뤄라. ][ 결정할 수 없다면 미뤄라. ]
어떤 것을 결정해야할 순간이 왔다는 것은 어떻게 할 수 있을까? 판단할 수 있는 자료가 없는 상태에서는 제대로된 결정을
할 수 없다. 따라서, 결정하기 위해서는 가능한 최대한 많은 정보를 갖추어야 한다. 하지만, 정보가 많다고 결정을 제대로
한다는 보장은 없다. 너무 많은 정보는 결정을 더욱 난감하게 만들기도 한다. 하지만, 결정은 언젠가는 해야한다. 더 늦어
지면 그것으로 인한 피해가 발생할 것이기 때문이다. 따라서, 결정의 순간이란 결국 더 미룬다면 피해가 발생하게 되는 시
점을 이야기한다. 근거없는 결정은 재작업이라는 피해를 남기게 되며, 판단의 잘못은 책임자가 온전히 자신의 것으로 받아
들여야 한다. 강요되는 결정은 결정의 근거가 될 수 없다. 설령 그렇게 결정해서 좋은 결과를 낳았다고 해도, 결정이 근거
가 없었다는 점에 대해서는 비난을 받을 수 있다. 결정을 할 수 없다면, 최대한 모을 수 있는 데이터를 수집하고, 이를 논리
적으로 분석해야 한다. 비 논리적인 분석은 데이터가 아무리 많아도 좋은 결정이라고 받아들이기는 힘들다. 단적인 예만
들어서 만든 결정도 역시 근거가 희박하기는 마찬가지다. 예를 들어, 몇몇의 경우에만 적용되는 것을 대부분의 경우로 확
대 해석할 경우, 그로 인해서 발생되는 문제들은 해결되지 않은 상태로 남게되고, 결과적으로는 안하는 것만 못한 상태가
될 수 있다. 행위를 결정하는 것은 그만큼 힘든 일이며, 특히 많은 위험이 내포된 경우에는 더 판단을 내리기 어렵다.
결정을 내리지 못하는 상황은 미래를 예측할 수 없기 때문이다. 그로 인해서 발생할 재작업과 일정 지연, 그리고, 새롭게
발생하는 리스크등등을 모두다 고려해야 한다.가장 값싼 방법은 작은 프로토 타입을 만드는 것이 하나의 해결책이 될 수
있다. 너무 많은 변수를 가지고 있는 경우에는 간단한 모델을 이용해서 중요도가 적은 변수들은 제거를 하고 돌려볼 수 있
다. 이를 통해서 더 많은 데이터를 축적한다면, 일단은 비용대비 효과는 있다고 볼 수 있다. 설계의 관점에서는 잘 모르는
문제를 해결하는 방법들에 대해서 어느정도 패턴(Pattern)이 있음을 밝혀냈다. 아키텍처적인 관점에서의 패턴은 파이프-
필터, 블랙보드, 서버-클라이언트 등등, 지금까지 문제를 풀기 위해서 효과적으로 사용했던 것들이 있다. 그것을 이용해서
해결할 수 있다면, 충분한 근거를 가진 결정이라고 할 수 있다. 세부적인 구현에 "디자인 패턴"과 같은 것을 적용할 수도
있다. 하지만, 패턴을 무작정 적용하는 것보다, 그 패턴을 적용하는 이유가 타당해야 한다. 예를들어, 단순히 전역 변수를
객체지향이라는 관점에서 감추기 위해서 싱글턴(Singleton) 패턴을 사용하는 것은 올바른 사용이 아니다. 싱글턴은 시스
템의 유일하게 존재해야할 필요가 있을 경우에 사용하는 것이지, 전역 자료로 만들어서 어디서나 사용하기 위한 것은 아니
다. 작은 단위의 설계에서는 디자인 패턴이 효과가 있으며, 큰 단위의 설계에서는 아키텍처 패턴이 도움이 될 것이다. 하지
만, 모든 패턴이 그렇듯이 반드시 충분한 생각을 필요로 한다. 확장성이나 변경 용이성과 같은 목적이 구현되어야 할 부분
들에 대해서 패턴은 좋은 해결책이 될 수 있다.

미룬다고 나쁜 것은 아니다. 빨리해야 할 것들은 통합이나 구현된 개별 모듈에 대한 테스트이며, 요구사항 수집이나 검증
등이 될 수 있다. 물론, 아키텍처의 설계도 구현을 위해서는 선행되어야 한다. 하지만, 아키텍처란 시스템의 구조에 지대한
영향을 주기에 쉽게 결정하지 못할 수도 있다. 이를 위해서는 어느 정도의 변경 가능성을 열어둔 아키텍처를 만들어야 한
다. 더 중요한 것은 그 아키텍처에 영향을 주는 시스템의 요구사항을 정확히 파악하는 것이 더 중요하다. 사용자들도 어떤
것이 정말 원하는 일이었는지를 알지못하는 경우가 있기에, 요구사항을 더 파악하기 어렵게 한다. 그리고, 사용자들이 쓰
는 용어와 개발자의 언어가 다르기에 이 차이점을 극복해야 하며, 설계를 진행하기 위해서 결정해야할 세부적인 사항들에
대해서, 사용자들이 알려주지 않을수도 있다. 개발이 진행되어감에 따라 점차 개발해야할 시스템에 대한 지식이 쌓이기에,
너무 많은 것을 과제의 앞 부분에서 결정하는 것은 위험 부담이 큰 일이다. 만약, 그런 결정들이 되돌릴 수 없는 구조를 정
의했다면, 완전히 새로운 구조를 과제의 후반부에 새롭게 구현하고 있을지도 모른다. 결정할 수 없다면 정의만 하라. 여기
서 말하는 정의란 변경 가능성을 말한다. 즉, 어떤 결정의 전제로 사용할 수 있는 것들이 필요하기에(인터페이스와 같은
것), 그것에 의존적인 정의를 할 수 밖에 없다. 나머지는 그 정의가 변화가 있더라도 변경이 발생하지 않도록 만드는 것이
다. 예를 들어, 객체 기반의 언어를 사용한다면, 인터페이스를 정의하고 나중에 실제 클래스의 구현에 그것을 맞추는 방법
을 선택할 수 있다. 하지만, 구조적인 변경에 대해서는 요구사항을 만족시키는지에 대한 가능성은 반드시 살펴보아야 한
다. 단순히 인터페이스의 변경만이 있다면 큰 문제는 없겠지만, 구조적인 변경이 동반된다면, 이것은 과제 지연의 중대한
요소로 작용할 것이 분명하다.
과제를 해야할 지 안해야할 지 판단할 수 없는 상황에서는 과제를 작게 구분하라. 예를 들어, 얼마나 분량이 모를 경우에는
과제를 크게 2부분으로 진행할 수 있도록 해야할 것이다. 먼저 분석하는 단계가 하나의 과제로 만들 수 있을 것이다. 그리
고, 그 과제의 결과물은 나중에 할 과제의 입력으로 사용할 수 있다. 즉, 과제의 크기가 얼마인지를 모르는 상황에서 섣불
리 추정하는 것은 위험하기에, 추정을 위한 과제를 진행할 필요가 있다는 것을 설득해야 한다. 무턱대고 아무런 근거도 없
이 몇 개월이 걸린다고 이야기 하는 것은 말 그대로 망하는 지름길이다. 우린 아무도 미래에서 온 사람들이 아니기 때문이

다. 그리고, 우리가 다루는 문제는 불확실성과 복잡성이 기본적인 성질로 내재된 것으로 개인차가 존재하는 사람이 만드는
것이기 때문이다. 이런 상황에서 최적으로 대답할 수 있는 것은 대략적인 기간의 범위밖에 없다. 그 정확도도 경험이 없다
면, 거의 16배의 차이를 보일 수 있다(0.25 ~ 4배). 더 좋은 방법은 그런 불확실성이 있다는 것을 이해하는 고객과 같이
일할 수 있는 방법을 찾는 것이다. 고객이 갑이지만 그냥 갑은 아니다. 고객이 원하는 것을 얻어야지 쌍방이 이익을 얻기
때문이다. 따라서, 고객에게는 정확한 판단을 내린 근거를 제시해야할 것이고, 고객은 그러한 판단이 올바른 것인지를 알
아야할 의무가 있다. 설득력이 있으려면, 과제에 대한 결과물을 지속적으로 고객에게 보여주는 것이다. 고객은 자신이 원
하는 것들을 빨리 개발에 전달해서, 좀더 요구사항을 구체화 시키는데 협조를 해야한다. 개발과 고객이 분리된 상황에서는
이런 것들이 불가능하다. 그리고, 경쟁이 치열한 경우에도 마찬가지로 고객은 고자세를 취할 가능성이 높다. 개발의 비용
이 문제가 될 경우에는 그 비용을 누구의 주머니 속에서 꺼내올 것인지가 문제가 되며, 결국 고객도 공급자도 서로 간에 윈
윈관계를 만드는 것이 최적의 해결책이 되리라는 것은 명확하다. 누구의 주머니를 비워야 할지를 일방이 피해를 입는 구조
라고 한다면, 누구도 책임지지 않는 일정과 결과물만이 남을 것이기 때문이다.
- 약속은 반드시 지켜야할 것들을 정하는 것이다. 지키지 못할 약속을 하는 것은, 그 책임에서 자유로울 수 없다.-

[ 지금할 수 있는 중요한 일을 하라. ][ 지금할 수 있는 중요한 일을 하라. ]
사람들은 일반적으로 급한 일만하다가 시간을 다 보낸다. 급한 일들은 언제나 발생할 수 밖에 없다. 하지만, 그것을 하는
동안 간과했던 중요한 일들이 나중에는 다시 급한 일이되어 다가오게 된다. 그때는 이미 늦어서 임시적인 땜방으로 일을
처리하게 되고, 다시 그것으로 인해서 다양한 급한 일들을 만들게 된다. 이런 반복적인 행동의 오류가 발생하지 않도록 만
들기 위해서는, 하루의 일정 부분은 반드시 중요한 일에 투자를 해야한다. 예를들어, 오전 시간은 고스란히 중요한 일에 투
자를 하고, 나머지 급한 일들을 오후에 처리하도록 하는 것도 좋은 방법이다. 오전은 특히나 집중력이 좋은 시간으로, 될
수 있으면 급한 일보다는 중요한 일에 투자하는 것이 능률을 올릴 수 있다. 그리고, 급한 일이 발생하지 못하도록 미연에
방지하는 것도 좋은 태도다. 문제는 발생했을 때 처리하는 것이 가장 비용이 싸다. 특히, 품질에 관련된 문제는 발견 즉시
처리해야 한다. 그런 것들은 쌓아두게 되면 반드시 더 큰 댓가를 치루기 때문이다. 사실 소프트웨어 개발에서 가장 잘못하
는 것이 바로 이런 부분이다. 자신이 코딩한 프로그램을 즉시 테스트를 해야하지만, 완성도가 미비하거나 상대방이 아직
준비가 안된 상황에서는 테스트를 미루게 되며, 그런 것들이 나중에 디버깅과 테스트 시간을 상당부분 차지하게 만든다.
과제 지연은 과제 초기부터 조금씩 쌓여나가는 이런 부분들의 총합보다 많이 차지하게 된다. 즉, 품질의 미비는 부피가 커
감에 따라, 지수적으로 재작업 비용을 증가시키는 경향이 있다는 것이다. 이것도 일종의 시너지 효과일 것이다. 버그를 일
으키는 전체는 버그를 만든 부분의 합보다 항상 크다.
코딩에서 가장 중요한 활동은 무엇인가? 사실 이것은 어떤 일을 해도 마찬가지겠지만, 일을 가능하면 줄이는 것이다. 같은
일을 하더라도 한번만 하는 것이다. 즉, 재활용을 많이하고, 중복을 줄이는게 핵심이다. 그리고, 반복적으로 해야하거나,
실수가 많이 생기는 일은 자동화 하는 것이다. 물론, 자동화하는 일은 창조적이기 보다는 단순한 일이될 것이 분명하다. 컴
퓨터나 각종 툴들은 이런 것을 하기 만들어졌기 때문에, 가능하면 그런 것들은 전부 자동화 시켜야 한다. 중요한 일을 하기
위해서, 중요하지 않은 것들은 사람이 하면 안된다. 중복은 모두 제거하는 것이 기본이다. 개발자들은 편의상 "CTRL-C,
CTRL-V"를 자주하게 되는데, 이는 중복을 낳는 지름길이다. 최소한 코드 파일내에서는 해선 안된다. 그리고, 한가지 더 중
요한 것을 추가한다면, 아마도 미학적으로 아름다운 코드르 만들려는 노력이 될 수 있을 것이다. 궁극적으로 모든 코드는
사람이 읽는다는 점에서 이해하기 쉬워야 한다. 한번 잘 못 만든 코드는 잘못된 경험을 독자에게 줄 수 있기 때문에, 항상
코드를 아름답게 다듬는 일이 필요하다. 정확하게 의도를 전달할 수 있는 코드를 만드는 것이 훌륭한 프로그래머와 그렇지
못한 프로그래머를 나누는 기준이기 때문이다. 가능한 변화가 있을 때마다 테스트를 해보는 것이 좋다. 이상적으로는 한
라인이라도 변경(혹은 추가)이 있었다면, 테스트를 해야한다. 테스트를 위해서는 간단히 테스트 할 수 있는 코드를 만들
고, 반드시 실행해봐야 한다. 사람이 눈으로 읽어서 문제를 진단하는 것도 좋지만, 항상 실수는 있기 마련이다. 따라서, 반
드시 실행해 봐야한다. 하나의 입력으로 하나의 출력을 만드는 검사는 코드를 다 검증할 수는 없다. 따라서, 입력의 집합과
출력의 집합이 필요하며, 유효한 입력값의 범위를 벗어난 값도 가정해야 한다. 오류가 발생했을 때 처리가 어떻게 될 것인

가를 알기 위해서는 인위적인 오류도 필요하다.
대부분의 제품음 만드는 과정보다는 평가 및 유지보수에 많은 비용을 사용한다. 따라서, 평가와 유지보수를 줄이는 것이
소프트웨어 개발에서은 가장 핵심적인 비용 절감대책이다. 개발 시간을 경쟁적으로 더 단축하는 것이 의미하는 바는, 평가
와 유지보수에 들어가는 노력을 줄이는 것이라고 볼 수 있다. 소프트웨어 재사용이란 관점에서 재사용할 수 있는 모듈이나
컴포넌트를 확보하는 것도 중요하다. 또한, 대부분의 제품이 기능적으로 크게 달라지는 경우는 없기에, 개선할 수 있는 아
키텍처를 설계하고, 재활용 가능한 플랫폼을 확보하는 것도 중요한 일이다. 따라서, 플랫폼은 어떤 가치를 더 하는 활동이
최소의 비용으로 가능하도록 만들어야 한다. 물론, 기능을 더하는 것과 같이 빼는 것, 새로운 환경에 적응시키는 것도 중요
하다. 이런 것들이 가능하기 위해서는 계층적인 구조를 만들고, 변화가 미치는 영향을 각각의 계층에서 흡수할 수 있도록
해야한다. 이는 설계에서 코딩으로 이어지는 활동에 대해서, 관리와 리뷰가 부족할 경우 발생하는 불일치 문제를 해결하려
는 노력이 필요하다는 것을 의미한다. 즉, 설계는 그럴듯한 모듈화와 계층화를 만들었다고는 하지만, 실제 코딩에서는 이
것이 무시해서, 성능상의 이유로 직접적인 모듈간의 통신을 허락하게 된다. 이는 근본적인 설계목적을 위반하기 때문에,
설계가 제대로 코딩에 반영되었다고 볼 수 없다. 반영되지 않는 설계는 결국 재작업 비용과 유지보수 비용의 근원이 된다.
그리고, 그 비용은 생각보다 더 클 것이 분명하다. 스파게티 코드가 만들어지는 이유는 설계에서 정한 각각의 역할과 책임
을 제대로 코딩에서 지키지 않기 때문이다. 일을 직접 하려고하지 말고, 그 역할과 책임을 가진 모듈에게 시켜야 하는 것이
원칙이다. 그 역할과 책임까지 스스로 가져가지 않는다면, 이것은 당연한 것이다. 조직도 마찬가지다 그 역할을 가지고 있
는 사람에게 책임이 주어져야 한다.
중요한 일을 하고자 한다면, 자신이 하고 있는 일의 원리를 잘 이해하고 있어야 한다. 단순히 코딩을 많이 한다고 코딩을
잘 한다고 볼 수는 없듯이, 원리를 이해 해야만 중요한 일이 눈에 보이게 된다. 중요한 것을 파악하는 능력은 더 나은 것이

무엇인지를 탐구하는 것이다. 선택의 근본적인 원인과 결과를 이해하고, 그것을 떠 받치고 있는 이유를 찾는 것이다. 더 나
은 방식으로 할 수 있는 것이 있다면, 그것을 직접 자신이 하는 일에 도입해서 시도하는 것도 좋다. 실패하지 않은 사람은
대단한 성공도 할 수 없다. 리스크가 없는 성공은 얻을 수 있는 가치도 작은 성공이기 때문이다. 또한, 자신이 생각하는 중
요한 일이 회사나 팀의 목표와 다를 수도 있다. 하지만, 이런 상태가 오래 지속되는 것은 개인과 조직 모두에 좋은 영향을
주기는 어렵다. 따라서, 될 수 있으면 개인이 생각하는 중요한 일이, 조직이 궁극적으로 가야하는 방향과 일치하면 좋을 것
이다. 조직은 생산성이 높고 가치가 있는 일을 선호한다. 따라서, 개인의 생산성을 높일 수 있는 일과 가치가 있는 일을 찾
아서 중요한 개인의 일로 만들 수 있어야 할 것이다. 가장 쉬운 방법은 생활의 주변에서 다양하고 번잡한 일들 중에서 중요
한 일을 찾는 것이다. 중요하지 않은 일들은 일단 버리자. 급하고 중요한 일을 어쩔 수 없이 해야한다. 그 외의 급한 일들은
그냥 미뤄두어도 크게 어려움을 겪지 않을 것이다. 문제는 급하고 중요한 일과 급하지만 중요하지 않은 일을 어떻게 구별
할 것인가이다. 이때는, 한 가지만 스스로에게 질문하도록 하자. 내일, 일주일, 한 달, 일 년 후에도 그것이 중요한 일인지
를 묻자. 만약 그렇다면, 그것은 반드시 해야할 일이다. 그렇지 않다면, 다른 중요한 일을 찾아서 하는 것이 더 가치있는 일
일 것이다. 물론, 가장 중요한 것은 당신의 건강과 가족의 사랑임은 잊어서는 안된다. 모든 일은 그 근본 속에 사람에 대한
관심과 애정이 있어야 할 것이다.
- 중요한 일을 해야만 당신과 당신을 둘러싼 모든 것이 가치를 지니게 된다.-

[ 불안한가? 자신감이 당신의 유일한 무기 ][ 불안한가? 자신감이 당신의 유일한 무기 ]
개발 현장에서의 비난과 호통은 불안감의 표현이다. 더 정확히 말한다면, 공포심의 또 다른 말일 수도 있다. 자신의 불안감
을 감추기 위햇거, 회사에서 유일하게 허가되는 것이 비난이기 때문이다. 폭력과 폭언을 하는 것은 요즘의 회사 분위기에
서는 아무리 관리자라고 해도 징계를 당하기 쉽다. 따라서, 이용할 수 있는 것은 자신의 아랫 사람에 대해서 마치 공적인
일인양 비난하는 것이다. 하지만, 그래봐야 스스로가 위험한 상황에 있거나 스트레스를 많이 받고 있다는 것만 알려줄 뿐,
팀의 운영에 대해서는 아무런 도움이 되지 않는다. 하려거든 차라리 하루 휴가를 내고 어디 머리라도 식히러 떠나라. 아침
출근길에 갑작스럽게 드는 자유에 대한 생각을 그냥 한번 지르는 것이 오히려 당신의 일에 도움이 될 것이다. 물론, 돌아오
는 길이 불편하겠지만, 그래도 오래간만에 아무 눈치도 안보고 하고 싶은 일을 했다는 뿌듯한 마음은 간직할 수 있다. 높으
신 분들은 자신의 불안감을 남에게까지 전달하는 좋지 못한 버릇을 가진 사람들이 많으며, 그런 사람들의 한결같은 특징은
유머와 여유가 없다는 것이다. 자신이 불안해하면 그들의 명령을 수행하는 사람들은 제대로 일에 집중하지 못하게 된다.
자신감 많이 유일한 자신의 방어막이자 무기라는 사실을 잊어선 안된다.
무모한 자신감을 가지라는 것은 아니다. 보장이 안되는 일정과 기능을 남발하는 것은 실패의 지름길이다. 윗사람의 비위를
맞추기 위해서 공수표를 날린다면, 결국 그 책임은 고스란히 그와 그의 팀의 몫이 될 것이기 때문이다. 자신감은 사실을 사
실대로 말하는 것에서 시작된다. 감추기 위해서 거짓말을 한다면, 그것으로 인해서 더 큰 거짓말을 해야한다는 것은 이미
유치원에서 충분히 배웠을 것이다. 하지만, 우리의 과제 책임자들은 너무나도 흔하게 "별 문제 없습니다"라고 이야기 하는
것에 익숙하다. 그런 이야기가 자주 나온다면 당연히 윗사람은 의심의 눈초리로 과제를 더 세밀하게 관찰해야 한다. 아무
문제가 없다는 것은 무엇이 문제인지도 모른다는 말과 같기 때문이다. 문제를 인식하는 것은 문제를 푸는 첫 단추를 제대
로 끼우는 것이다. 문제가 있다는 것을 감출 필요는 없다. 문제가 없는과제는 있을 수 없기 때문이다. 그리고, 듣는 사람들
도 문제가 있다는 말을 들었을 때 지나치게 민감하게 반응한다면, 나중에는 문제가 있어도 곪아서 터지기 전에는 절대 문
제가 있다는 말을 들을 수 없을 것이다. 도무지 대책이 없는 상황에서 듣는 폭탄 선언은 돌이킬 수 없는 결과를 낳을 뿐이
다. 문제가 있다는 것을 미리 안다면, 그 나마도 대응할 수 있는 최소한의 여유는 가질 수 있다. 불안감은 문제를 감추는데
익숙해 지도록 강요를 낳을 뿐이다.

두렵지 않은 사람은 없다. 두렵기 때문에 우리는 계속 확인하는 것이다. 그리고, 계속하는 가장 확실한 수단은 직접 구현된
기능을 실행하는 것이다. 그것 이외의 몇 %가 완료되었다는 말은 믿을 것이 못된다. 95%가 완료되어도 과제 기간이 지
속적으로 지연되는 과제들이 흔하기 때문이다. 몇 %가 구현되었다는 이야기를 한다면, 무엇이 기준인지를 확인해야 한
다. 만약, 구현(코딩에 한정)만 95%정되 되어다고 이야기 한다면, 지금까지 개발하는데 걸린 시간만큼 더 가야할 길이 남
았다는 것을 알아야 한다. 구현을 아무리 많이해도 검증되지 않은 코드는 아무런 보험이 되지 못한다. 오히려 구현되지 않
은 코드가 더 안심이 되는 것도 이때문이다. 한번 만든 것은 고치기가 어렵지만, 만들어지지 않은 것은 제대로 구현할 수
있는 기회가 아직 남은 것이다. 따라서, 불안감을 없애기 위해서는 반드시 구현된 기능들이 어떻게 동작하고 있는지를 확
인해야 하며, 구현되었다는 말의 정확한 정의가 어떻게 되는지를 투명하게 관찰해야 한다. 두려움이 급습할 때는 확실한
것만 보아야 한다. 불확실한 것에 기대어 낙관적인 기대를 품는 것은 금물이다. 예를들어, 최적의 일정을 만들라고 담당자
들에게 요청한다면, 그들이 가져온 일정은 절대 지켜질리가 없는 계획이 될 것이다. 그나마 정확도가 조금이라도 있는 계
획을 알고자 한다면, 당당자들이 솔직하게 이야기하는 일정을 보아야 한다. 단순하지만 솔직한 개발자들은 절대 속이지 않
는 일정을 가져올 것이다. 단, 당신이 그 사람들을 정말 신뢰한다면.
자신감을 만들기 위해서는 확실한 근거를 조금씩 만들어가야 한다. 가장 확실한 방법은 작은 단위로 과제를 나누어서 결과
를 확인하는 방법이다. 짧으면 일주일 단위의 계획을 세우고, 주말이 되기전에 배포된 코드를 이용해서 데모를 하는 것이
다. 물론, 자동화 테스트를 과제 초기부터 실행할 수 있는 것도 좋다. 중요한 것은 눈에 보이지 않는 소프트웨어 개발과정
을 눈으로 확인할 수 있는 것이 핵심이다. 누가 보더라도 의심하지 않는 결과는 동작하는 프로그램을 보는 것이 유일한 방
법이기 때문이다. 높으신 분들은 눈으로 확인하길 좋아하며, 꾸준한 진척이 있다는 것을 알게 되면, 불안감을 조금이라도
감추게 될 것이다. 당연히 당신의 자신감을 높이는 것도 시간문제다. 만약, 눈으로 보여줘도 보기를 거부하는 높으신 어른
들이 있다면, 그들은 그냥 무시하기 바란다. 그들의 눈에는 아무리 좋은 것을 보여줘도, 자신의 욕심이외에는 다른 것들은
보이지 않기 때문이다. 당신의 철학이나 품질에 대한 집중적인 노력같은 것들은 그들에게는 아무것도 아닌 것으로 보일 뿐
이다. 그들의 불안감을 잠재울 수 있는 것은 세상에서 찾을 수 없다. 그들을 위해서 당신의 안까운 시간을 인생을 낭비하지
말고, 그들은 그냥 그렇게 살도록 내버려두라. 물론, 잠시동안 힘든 시간이 될 수도 있고, 귀찮은 숙제를 많이 해야할지도

모른다. 하지만, 결국 그들이 강요하는 불안감과 공포는 당신을 전염시키지 못할 것익고, 더 중요한 당신의 팀원들에게는
아무런 영향도 주지 못할 것이다. 그런 자신감 넘치는 팀원들이 있다면, 당신은 그 윗사람들보다 더 오래동안 행복한 화사
생활을 할 확률이 더 많을 것이다. 물론, 100% 확신은 없다.
- 두려움은 불투명한 미래에 대한 당연한 태도다. 그것을 인정하는 순간 희망이라는 이름의 기회가 될 수 있다.-

[ 소프트웨어 설계 ][ 소프트웨어 설계 ]
소프트웨어를 만들기 위해서는 무엇을 어떻게 만들지를 정해야 한다. 즉, 문제에 대한 해결책을 만들기 위해서, 어떤 역할
들이 필요한 지를 정하고, 각각의 역할들이 어떤 방식으로 연결될 지를 정하게 된다. 이런 과정을 통해서 만들어지는 밑 그
림이 설계의 산출물이 될 것이다. 설계란 결국 문제를 정의하고, 해결책으로 매핑(Mapping)하는 과정이며, 설계가 완료
되기 위해서는 구현하기 위한 충분한 정보가 생성되어야 한다. 문제를 전체적으로 해결하는 것을 시스템의 범위로 생각하
면, 시스템의 중요 부분들은 잘 정의된 역할을 가지는 서브시스템으로 나누어진다. 다시 서브시스템은 세부적인 역할을 담
당하는 모듈들로 구분되고, 더 작은 단위는 여러가지 함수나 클래스등으로 구성될 것이다. 이런 구성 요소들을 정의하고,
그들간의 관계(상하, 혹은 호출)를 설정하게 되면, 그것이 정말 올바른 해결책이 될 수 있는지 모델을 통해서 검증하게 되
며, 이때 연결 방식이나 구성 요소의 변경이 있다면 모델도 달라질 수 있다. 즉, 대안으로 선택될 수 있는 여러가지 모델들
을 생각해서 그들간의 평가를 통해서 최선의 선택을 할 수 있도록 노력한다. 설계 도중에 코딩이 가능할 수 있지만, 이때는
구조에 대한 것이 아니라, 기술적인 가능성을 보는 수준에서 진행되는 코딩이다. 구조에 반영될 코딩은 설계가 이루어지고
난 후에 진행되어야 한다. 구조를 만들어 버리면, 이것이 설계에 반영되어 버리기에, 결과적으로 코딩이 설계 및 조직 전반
에 미리 자리를 잡게된다. 이때는 최적의 설계보다는 사람의 구성에 맞춰진 설계가 만들어지고 만다.
많은 사람이 설계에 참여하는 것은 다양한 의견과 공동의 이해를 만들어 갈 수 있도록 한다. 하지만, 많은 의견이 있다는
것은 그 만큼 결과물을 만들기 위해서 의사 결정과정과 같은 길고 말 많은 길을 걸어야 한다는 뜻이다. 따라서, 더 오랜 시
간이 걸리고, 그 깊이도 예측하기 힘들다. 더군다나, 구체적인 결정을 내리기 위해서는 많은 충돌이 있기에, 대부분의 설계
결정 사항들은 모호함을 가질 것이 분명하다. 따라서, 설계는 소수의 인원이 하는 것이 가장 효과적이고 빨리 진행될 수 있
는 과정이라고 생각된다. 따라서, 과제 시작과 동시에 대규모의 인력이 투입되는 것은 설계와 코딩의 분리를 일으키게 만
든다. 즉, 설계에 많은 인력을 투자하기 어렵기에, 설계이외의 남은 업무에 대다수의 인력이 투입되고, 결과적으로 설계와
무관한 코딩이 진행되어 버린다. 나중에 만들어진 설계서는 코딩과는 이미 많은 차이가 있기에, 대부분 형식적인 프로세스
산출물로 과제관리 시스템에 등록되고, 실제 설계는 코드를 보라고 새로운 개발자들에게 전달된다. 물론, 그렇게 만들어진
코드가 제대로 구조적 될리도 없을 것이다. 설계없이 구현된 새로운 코드를 하나 더 만들었을 뿐, 지난번 과제와 달라진 부
분이 없다는 것을 모든 개발자는 다 알것이다. 그리고, 그것이 조직의 문서화되지 않은 프로세스로 남겨지게 된다. 우린 이
단순한 것을 바꾸는데 상당한 댓가를 나중에 치르게 되며, 그것으로 인해서 발생하는 미래의 비용또한, 끝없이 뒷다리를
잡아댈 것이다. 나아가고자 하는 힘은 초기에 설계를 하는 노력과 이후에 발생하는 비용을 다 합친 것보다 더 클 것이다.
설계와 코드를 병행하는 것도 한가지 방법이라고 볼 수 있지만, 이때의 설계는 만들고자 하는 시스템 뼈대를 이루는 것들
에 대해서 검증을 동반해야 한다.

설계를 검증하기 위해서는 모델을 이용하는 방법이 좋겠지만, 가장 좋은 확인 방법은 역시 실제로 코드를 만들어서 실행시
켜 보는 것이다. 물론, 이런 방법은 잘 모르는 도메인에 대해서 탐색적으로 살펴보기 위한 것이다. 만약, 해당 도메인에 대
해서 잘 안다면, 실제로 코드를 만드는 것보다는 제대로 설계를 하는데 더 집중하는 것이 필요할 것이다. 문제는 언제 설계
가 완료될 것인가를 정하는 것이다. 코드로 만들 수 있을 정도의 수준까지 설계를 한다는 것이 일반적으로 이야기하는 기
준이지만, 그렇게까지 설계를 진행하는 것은 많은 사람을 불안하게 만든다. 특히, 그렇게 설계하는 것을 보는 관리자들은
불안감을 감추지 못하고, 코딩을 독려할 것이다. 물론, 그렇게 하는 것이 그때는 최선의 선택처럼 보일 것이다. 조금이라도
진도를 그렇게 나가두면, 나중에 할 일이 줄어들 것이라는 일반 상식에 근거해서 그렇게 명령할 것이다. 하지만, 그런 코드
는 나중에 수정될 가능성이 훨씬 높다. 재작업의 비용은 새로 개발하는 비용보다 더 많이 들수 있다는 것은 그들의 머리속
에 들어있지 않다. 그리고, 그렇게 만들어지는 코드들은 대부분 인터페이스 문제와 제대도 검증되지 않는 코드를 만들어
낼 가능성이 높다. 빨리 코딩할수록 더 많은 재작업 비용이 들어가는 것이 진리다. 즉, 판단해야할 가장 마지막 순간까지
결정을 미루는 것이 소프트웨어의 재작업 비용을 줄이는 최선이다. 그것이 불안하다면 변경 가능성이 것의 없는 것들을 대
상으로 코딩을 진행하거나, 새롭게 적용할 기술을 공부하는데 시간을 보내는 것이 훨씬 더 효과적일 것이다.
설계는 선택의 문제다. 어떤 선택을 하게되면, 나머지는 선택들은 제외된다. 대안들은 평가되어야 하며, 그런 대안들에 대
한 평가 기준도 공정해야한다. 물론, 그런 평가 기준들이 팀의 역량측면에서 가능해야 한다. 아키텍처는 시스템의 대략적
인 모습을 그릴 수 있다면, 설계는 그것을 포함해서 좀 더 낮은 수준까지 이어지는 활동이다. 즉, 시스템을 부분으로 나누
고, 그 부분들을 다시 더 작은 부분들로 나누면서 모듈의 수준에서 인터페이스를 정해나가는 활동으로 이어질 것이다. 나
누어진 부분들 간에는 최소한의 연결만이 존재하는 것이 좋으며, 모듈의 내부는 한가지 역할에만 충실할 수 있는 것들로
가득차야 한다. 결국, 설계 활동은 시스템을 책임과 역할로 나누는 행위라고 생각해 볼 수 있다. 나누어진 역할에 대해서
명확한 책임 범위가 주어지며, 그 책임 범위를 충실히 수행하도록 인력이 할당된다. 나누어진 책임의 경계는 모두의 책임
이다. 즉, 그것을 검증하는 것은 모두가 함께 해야하는 일이다. 미리 코딩을 진행하는 것이 위험이 내포된 활동이라면, 차
라리 나누어진 책임을 연결할 인터페이스들에 대한 테스트를 먼저 만드는 것은 어떨까? 만약 그런 테스트들이 작성된다

면, 설계 이후의 행위는 그 테스트들이 통과하는 것을 검증하는 활동이 될 것이다. 바로 그것이 구현(Implementation) 활
동이 되어야만, 설계의 연장선 상에서 작업이 이어질 수 있다. 물론, 그 이후의 테스트 과정은 이론적으로는 생략이 가능하
지만, 대부분의 경우 시스템 테스트와 인수 테스트는 개발자의 손을 떠나서 진행되기 마련이다. 따라서, 개발범위의 활동
은 설계와 구현, 테스트(단위, 통합)는 함께 진행되며, 설계가 명확할 수록 구현과 테스트 과정은 더 명확해 지기 마련이다.
명확한 것을 구현하는 것이다. 구현의 창조성을 강조하는 것보다는, 설계 과정의 깊이를 더하는데 더 힘을 쓰는것이 창조
의 또 다른 표현이 될 것이다.
- 조직이 구조를 결정해선 안된다. 구조가 조직에 반영되어야 한다.-

[ 데드라인 ][ 데드라인 ]
소프트웨어 개발은 많은 추정과 에측을 동반한 활동이다. 불확실한 정보와 가정, 어떤 일이 미래에 있을지 모르는 상황에
서 결정을 해야한다. 아니 결정을 내리도록 강요 받는다. 리스크가 클수록 얻는 것도 많다고 하지만, 불가능을 가능으로 만
들만큼 능력이 대단한 과제 담당자는 없다. 과감하게 일정을 줄이는 명령을 내리는 사람들은 얼마나 확신이 있기에 그런
일을 할 수 있는걸까? 문제는 그런 결정을 한 사람들은 자신의 책임은 없고, 그것을 지키지 못한 사람들만 비난 받게 만든
다. 스스로 과제를 하는 사람들과의 책임 분리에는 성공할지 모르지만, 팀워크는 그들에게는 아무 의미가 없는 말일 것이
다. 그들이 그런 결정을 내리는 근거는 "기회"라는 것이다. 그 기회는 시장에 출시해서 일정 시간동안 벌어들이는 돈으로
측정된다. 만약 출시가 늦어지면 그 만큼 벌어들일 돈의 양이 줄어든다는 것이다. 그리고, 경쟁사 이야기를 한다. 경쟁사는
벌써 그런 제품을 가지고 있으며, 시장에서 성공을 거두고 있다고 한다. 우리가 빨리 그 제품을 만들지 못하면 결국 그 만
큼 더 시장에서 제 값을 받을 수 있는 시간은 줄어든다는 것이다. 결정권을 가지고 있는 사람들은 될 수 있으면 보고되는
개발일정의 절반 정도를 줄이기를 원한다. 개발자들은 그것을 예상해서 두배의 개발기간을 잡는것이, 소위 말하는 영리한
개발 일정이라고 본다. 뭔가 이상하지 않은가? 줄이려는 사람과 늘리려는 사람. 그들 모두 정확한 정보는 없으며, 그냥 자
신들의 추측을 사용할 뿐이며 시스템 적인 사고는 하지 않는다.
과제를 관리하는 것은 과제의 비전을 만들고, 구현할 인력을 구하고, 일정 계획을 작성하는 것으로 시작한다. 하지만, 사실
그렇게 시작했다면 이미 과제를 해야한다는 당위성은 증명할 이유가 없다. 하라고 명령이 떨어진 것이기 때문이다. 상품화
과제의 경우에는 개발자의 의도와는 상관없이 마케팅이나 상품기획에서 과제를 시작하기 3에서 6개월전에 이미 정해져
있다. 마케팅이나 상품기회의 입장에서는 고객의 요구사항과 시장전망에 따라, 최대 수익을 거둘 수 있도록 고민한 일정을
개발에 제시한다. 그리고, 개발은 할 수 있다고 생각되는 일정을 이야기하고, 서로간에 여러번의 협의가 이어진다. 몇가지
제시된 과제 중에서 시간과 시장성이 큰 것을 기준으로 선택하게 되고, 개발은 그것을 할 수 있는 방법을 고민해서 동의하
게 된다. 리스크는 고려되어야 하지만, 모든 리스크를 다 파악할 수없다는 점과, 가장 중요한 개발 역량이 있는지에 대해서
는 의문을 남기게 된다. 계획을 실행하기 위해서는 내부의 역량이 충분해야하며, 부족하다면 그것을 해결할 수 있는 방안
도 같이 마련되어야 한다. 물론, 이것은 항상 희망적인 예측일 가능성이 높다. 하지만, 여기서 만들어지는 일정들은 아직
과제에 대한 데드라인은 되지 않는다. 과제가 시작할 시기가 되어오면, 구체적인 계획을 만들게 된다. 이때가 데드라인의
설정이 모습을 보이게 되는 순간이다. 개발과제를 담당하는 최고 책임자는 개발팀들과 협의를 하게 되지만, 과제 담당자들
이 제시하는 일정이 마케팅과 상품기획에서 요구하는 것과는 많은 차이가 있다는 것을 안다. 따라서, 뭔가 대책이 필요하
다는 것을 직감적으로 느끼게 되는 것이다.

SWDeveloperStory201502

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to SWDeveloperStory201502

Similar to SWDeveloperStory201502 (20)

SWDeveloperStory201502