스타업? 돈 벌이, 단순한 대표 직함이 필요한건 아니겠지? dev story

창업? 그거 해서 뭐하게? 이런 질문을 하면 뭐라고 답변할건가? '회사 댕기기도 꼬우고, 차라리 회사 차리자.', ' 요즘 스타업해서 사람뽑으면 뭐든 되지 않을까?', '돈 벌어보자...'

최근에 읽은 "당신은 전략가 입니까?" 라는 책에서 다음과 같은 내용이 나온다.


_____ 는 세계의 모든 운동선수들에게 영감과 혁신을 가져다 준다.

_____ 는 점점 많아지고 있는 새로운 사이트에서 더욱 더 효율적인 방식으로 빠르고 훌륭하게 온라인 검색을 할 수 있는 방법을 모색한다.

_____ 그룹은 그룹 내 브랜드와 관련된 모든 세분화된 시장에서 최고의 수준과 뛰어난 품질에만 집중하는 유일한 자동차&오토바이 제조업체이다.

이는 기업의 목적을 말하는 것으로 그 기업의 독특한 가치를 설명할 수 있어야 한다. 비단 기업뿐만 아니라 조직, 팀등 그것이 왜 존재해야하는지에 대한 목적과 가치를 짧고 간결하게 설명할 수 있어야 한다는 것이다. 이것이 중요한 이유는 전략의 가슴 떨리는 핵심 부분으로 당신이 누구이고 당신이 왜 중요한지를 세상에 당당히 선언하는 것인데, 이러한 선언이 없다면 그 조직의 존재이유가 없는 것이고 그것은 곧 기업의 가치, 문화가 없는 것이다.

무슨 대기업이 되어야 이러한 선언을 가질까 생각할 수도 있지만 구멍가게여도 그 구멍가게를 내가 왜 하는지 정도는 알아야하지 않을까? 무엇을 목적으로 기업을 운영할지를 모르고서야 그건 그냥 월급쟁이를 벚어나 다른 이들을 월급쟁이로 활용해 돈을 버는 행위받게 않된다.

다들 페이스북, 구글, 텀블러 같은 기업들에 대해서 '와~~~~' 하지만 정작 그들이 어떻게하면서 앞으로 나가는지에 대해서는 별로 관심을 못가지는 모양이다. 한국에서는 '가치가 무슨 돈 벌어주나?', '기업은 영리목적이다.' 라는 말로 대체되지만 월급 두둑한 다니는 기업에 어떤 문화나 가치관이 있는지는 의문이다.


유능한 사람의 기준. dev story

나는 현재 IT직종에서 일하는 프로그래머다. 사실 프로그래머라고 말하고 싶다. 그런데, 하는 일은 현재 서버관리자이고 각종 스크립트로 자동화하는 것을 만들었고 지금은 DevOps 팀에 소속되어서 웹개발도 하고 서버단 작업도 하고 잡부같은 일을 하고 있다.

잡설은 집어 치우고, 지난번에 'IT직종에서 좋은 회사?' 라는 글을 쓴적이 있다. 종종 많은 문제에 부딪히는데, 이 문제를 어떤 방식으로 처리하는지를 잘 관찰하면 좋은 회사인지 아닌지를 판단할 수 있지 않을까 하는 요지의 글이 였다. 

여기서 핵심은 '일을 처리하는 방식' 인데, 이는 결국에는 사람이 그 문제를 어떻게 대하고 판단하고 처리하는지를 가르킨고 볼 수 있지 않을까? 얼마전에 한 신문(국내신문사에서) 구글의 인사담당자를 인터뷰한 내용을 본적이 있다. 기자는 단도진입적으로 구글은 어떤 기준으로 사람을 뽑느냐고 물었다. 구글 인사담당자는 다음과 같이 말했다. 

" 문제 해결 인지 능력이 있는지 없는지를 우선 봅니다."

구글이라면 세계 최대 IT 업체이고 난다 긴다하는 능력자들이 몰리는 업체다. 기술적으로도 세계 최고를 자부하는 이들에게 구글 인사담당자는 그런거는 둘째이고 문제가 발생했을때에 문제를 정확하게 인지하고 처리할줄 알아야 그 다음에 자신이 가진 기술을 가지고 처리를 할 수 있지 않겠냐는 것이다. 

기사를 읽고 가만 생각해보니, 매우 훌륭한 인사 평가 방법이란걸 깨달았다. 비단 IT뿐만 아니라 여러가지 생활, 사회, 경제, 정치에 전 분야에서 수 많은 문제들이 발생하는데 그것을 처리함에 있어서 우선시 되어야 하는 것이 '문제 해결 인지 능력' 이다. 그것도 '합리적인' 문제해결 인지 능력 말이다. 

구글 인사담당자의 말은 '위대한 기업은 다 어디로 갔을까?' 책을 읽어보면 왜 중요한지 여실히 나타난다. 수 많은 기업들이 나오는데, 그 중에 천재들만이 갈 수 있다고 하는 미 항공우주국(NASA) 이야기도 나온다.

미국은 갈수록 일반인들로부터 외면받고 있던 우주개발을 만회하고자 최초로 일반인을 공개 모집해 우주로 보내는 프로젝트를 시작한다. 한 교사가 이에 응모해 시험에 통과하고 1986년 1월에 우주왕복선 챌린지호에 탑승해 우주로 갈 계획이였다. 그런데, 그날따라 1월 겨울의 날씨는 매우 추웠다고 한다. 미 남부에 있는 우주왕복선 발사장의 기온은 영하 7도. 그 보다 더 추운날씨에도 발사를 해본적이 있었지만 한가지 고민되는 문제가 있었다.

로켓부스터의 이음새에 고무패킹인 오링이 추운날씨탓에 딱딱하게 굳어 제기능을 상실하고 끝어질수 있다는 것였다. 이 문제를 발사 하루전날에 로켓 부스터를 제작한 사람들과 NASA 발사 관계자들이 회의를 시작했다. 로켓 부스터를 제작한 관계자들은 오링이 제 기능을 못할 가능성이 높기 때문에 발사를 연기하는게 좋겠다는 의견을 제시했지만 그렇지 않아도 발사를 미루고 미뤘던 챌리저 호의 발사를 더 이상 미를수 없다는 생각에 빠진 NASA 관계자들은 다음과 같은 질문을 했다고 한다.

"발사가 안전하지 못하다는 걸 증명할 수 있는가?"

이 질문은 매우 비합리적인 것이였다. 왜냐하면 발사가 안전하지 못하다라는 건 수많은 부품 하나의 결함이 곧바로 발사에 심각한 문제를 야기시켜야 했지만, 실제로 발사후에 벌어지는 일들은 예측가능한 데이터를 벚어나는 일도 많았고(실제로 우주왕복선의 발사 궤적은 예측한 궤적을 절대로 그리지 않는다.) 일부 부품은 손상되 되었지만 발사는 무사하게 끝나는 경우도 많았기 때문이다. 로켓 부스터 관계자들은 다음과 같은 합리적인 질문에 대한 답을 할 수 없었기 때문에 연기를 권장했었다.

"발사가 안전한지 증명할 수 있는가?"

이 질문은 발사의 안전 측면에서 문제를 일으킬만한 것들을 골라낼 수 있게 된다. 오링은 이 질문에 부합했고, 이 문제를 해결해야만 발사가 안전하다는 것을 보증하게 된다. 

그런데, NASA 관계자들은 180도 질문의 방향을 바꾸어 버린 것이다. 비합리적인 물음에 답을 할수 없었던 로켓 부스터 관계자들은 발사 동의서에 싸인을 해주고 말았고 챌린저호는 발사 73초만에 공중폭발하는 참사를 맞고 만다.

발사당시 O-ring 이 제 역활을 못하자 연료가 새고 있다.

발사 73초만에 공중폭발.

이는 무엇을 말해주는가? 바로 '문재 해결 인지 능력' 이 NASA 관계자들에는 없었다. 기술이 아무리 뛰어난다고 하더라도 개발 인프라, 개발 프로세스가 아무리 잘 갖추어져 있다고 하더라도 '문제 해결 인지 능력' 이 부족한 사람들이 다수가 회사를 지배하고 있다면 그 회사는 머지않아 챌리저호 처럼 공중폭발하는 순간을 맞을 수 있다.

비단 조직뿐만이 아니라 개인들간의 대화를 하다보면 이렇게 비합리적인 문제인식을 보여주는 사람들이 있는데, 그렇다면 멀리하는게 나중에 나를 위해서 좋다. 바로 문제가 생기지는 않지만 그 사람이 한 일들은 결국 문제를 나중에 발생시키게 된다. 

문제 해결 인지 능력은 곧 '합리적 사고' 를 할 수 있냐는 것을 묻는 것이다. 개발을 하면서 혹은 시스템 관리를 하면서 수많은 문제에 직면하게 되는데, 이때에 '합리적 사고'를 기반으로 일을 처리하지 않는다면 그 순간은 넘길수는 있지만 언전게는 챌리져 호와 똑같은 운명을 맞이게 될 수도 있다. 단지 그것이 10년이 될지 20년이 될지 모르지만 회사의 문화, 분위기, 업무에는 곧바로 나타난다. 

한국에서는 '문제 해결 인지 능력'을 중요시 하기보다는 당장 회사에 그것도 매출에 도움이 될만한 기술이나 일을 한다면 그걸로 끝이니......  좋은 기업은 있기나 한걸까...



당신은 어떤 팀장을 꿈꾸는가? dev story

내가 어렸을 적에는 가장 기억남는 건 공상과학 영화, 드라마였다. 당시에 영화는 볼수 없어서 그져 TV에 의존했는데 설날이나 추석즘되면 TV에서 더빙한 영화를 틀어주곤 했다. '스타워즈', '전격 Z작전', '맥가이버' 등은 정말 TV에 빨려들어갈 만큼 집중해서 봤는데 조금 자라서 청소년즘에서 봤던 '스타트랙' 은 지금도 종종 보는 공상과학 영화중에 하나가 됐다.

스타트랙을 종종 보는 건 내용면에서도 다른 여타 공상과학의 선악 구도가 그렇게 아주 강하게 명확하지 않다. 뭐랄까 좀더 철학적인 내용들도 많이 담고 있는 그런 영화여서 가끔 보게 되게 된다.

이게 시리즈다 보니 볼때마다 느낌이 다른데, 나는 대머리 아저씨가 나오는 시리즈를 좋아한다.  그 대머리 아저씨의 극중 이름 '존 룩 피카드' 선장. 최근 엑스맨 이라는 영화에서 돌연변이 학교에 교장으로 나왔던 바로 그 사람이다.


어떤 일을 할때에 때로는 정확하고 신속하게 때로는 인간적인 일처리, 자신과 타인에게 엄격함, 불의에 타협하지 않는 강함, 승무원들을 생각하고 이끄는 리더십은 정말 멋져보였고 커서 '나도 저런 사람이 되고 싶다' 고 생각하게 됐다. (나 자신도 저런 함장이 되고 싶어하지만 강단은 없고 원채 소심해서.. ㅋㅋㅋ  ㅠㅠ)

몸만 커진 나는 지금도 저런 팀장 없나하고 두리번 거리고 산다. 그런데 현실은 그렇지 못한거 같다. 내가 몇년간 지내면서 본 팀장들은 팀을 이끄는 리더가 아니고 보스에 가까웠다. 이게 뭐가 다르냐고?


능력없는 팀장도 많았는데, 그런 사람들은 자신이 팀장이라는 것을 이용해서 '내가 너보다 능력이 좋아~' 를 강조하기만 했다. 정작 문제해결을 위한 인지능력도 없으면서 말이지...

팀장이라는 이유로 그것이 능력과 인간성을 초월한 어떤 계급임을 강조하는 사람들이 많이 보인다. 어떤 기술적인 결정을 할때에 객관적 자료가 아닌 팀장으로서 경험만으로 의사결정을 하는 회사도 많다. (내가 다니는 회사가 전형적인 예다) 그런 팀장들의 특징은 그냥 '돈만 버는 일'을 하기 위해서 능력좋은 사람을 '관리' 한다는데 있다. 쉽게 말해서 '사람 관리도 능력'.


스타트랙에 나오는 함장이 '사람 관리'하는 능력만 뛰어나서 영화속에서 그렇게 행동하는 것일까...  그냥 현실에서는 볼수 없는 영화 속에서의 장면일 뿐일까? 나도 저런 사람이 될 수 없을까...


 

[펌] 의사협회 홈페이지제작 과정의 쌩쑈. dev story

# 이 게시글은 OKJSP 싸이트에 올라온 글을 퍼온 것입니다. 
# 원글의 주소는 http://okjsp.pe.kr/seq/218395 입니다.

에효.. 
무슨 겨우 2300만원 짜리 갖고 세 업체가 컨소시엄을 하고.. 
프리랜서에게는 130만원 지급.. 
요구사항 분석은 전혀 안되어 있고.. 

캐안습.. 

http://www.facebook.com/hwankyu.roh/posts/495464163840297 

홈페이지 구축 관련 의협 임원의 횡령(?)의혹의 전모를 밝힙니다. 
제가 의협회장에 취임한 직후, 의협의 홈페이지가 개발한지 12년이 되어 큰 문제들을 안고 있다는 사실을 알게 되었습니다. 
홈페이지는 마치 집을 짓는 것과 같아서, 기능이 확장될수록 각종 데이터베이스가 늘어나며 덧붙여지는 것이 복잡한 구조가 됩니다. 즉 집을 이미 지어놓은 후에 확장을 한다면 배선과 배관설계가 꼬이는 것처럼 데이터베이스가 복잡해져서 재건축을 해야 하는 경우가 많이 생깁니다. 
의협의 홈페이지도 그런 상태여서 속도가 매우 느려 이용하는데 불편이 많고 협회에 필요한 다양한 기능을 수행하지 못하는 상황이었습니다. 
이러한 이유로 2012년 5월 제가 취임한 직후, 당시 박00 정보통신이사에게 홈페이지 개편을 지시했습니다. 

경기도의사회의 정보통신이사를 역임하면서 회무를 잘해낸 경험이 있어 추천을 받아 의협의 정보통신이사로 업무를 시작한 박00 이사는 ‘저렴한 비용’에 홈페이지 개발을 해야 한다는 생각에 몰두한 나머지, 다양한 커뮤니티를 지원하고 있는 의협의 복잡한 데이터베이스 구조 때문에 약 4천만원 이상의 금액이 소요(전문가들의 의견)되는 의협의 홈페이지 개편작업을 2천만원 이하의 저렴한 비용에 입찰을 진행했습니다. 그러나 업무량에 비해 금액이 지나치게 적어 지원자가 없었습니다. 업체들의 지원은 없고 저의 채근은 지속되자 마음이 다급해진 박이사는 평소 자신이 알고 지내던 조00을 불러 상의를 하였습니다. 조00은 자신이 알고 있던 S사를 비롯한 세 곳의 업체를 불러 콘소시엄을 만들었습니다. 박00 이사는 이 업체들의 컨소시엄(대표사는 S사)과 2,300만원이라는 금액으로 수의계약을 하고 개발을 진행하였습니다.(현재까지 1,782만원 지급) 

그런데 막상 개발을 시작하고 보니, 데이터베이스 구조가 복잡하고 의협의 요구조건들이 간단치가 않아 업체들은 개발에 난항을 겪게 되었습니다. 개발기간이 수개월 소요되었으나 개발은 지지부진했고 우여곡절 끝에 홈페이지가 오픈 되었지만 수개월 동안 커뮤니티 부분에서 버그가 발생했으며 의협의 요구사항들이 반영되지 않았습니다. 업체들은 더 이상 개발을 진행할 수 없다고 포기상태에 이르게 되었고, 그 사이 박00 이사는 이 문제와 무관한 다른 일로 사임하게 되었습니다. 

이후 팀장급의 IT전문가를 영입한 의협이 진상파악을 위해 S사를 불러 개발이 미진한 이유를 알아보니 S사는 처음에 콘소시엄을 구성한 조00씨가 자신들이 받은 1,782만원중 9백만원을 가져감으로 인해 나머지 금액으로는 개발이 어렵게 된 것이라고 주장했습니다. 그리고 그 중 일부가 박00 이사에게 입금된 것으로 알고 있다고 주장했습니다. 그런데 사실을 확인해보니 그 주장은 사실이 아니었습니다. 1,782만원을 받은 S사는 자신들이 682만원을 취하였고, Y사에게 660만원, 프리랜서 130만원을 지급하였고, 처음에 소개를 한 조00씨에게 310만원을 지급한 것이 전부였습니다. 조00씨는 자신이 PM(프로젝트 매니저)로 참여한 대가와 정보통신이사에게 인사를 해야 한다는 취지로 S사로부터 310만원을 받아갔으나 금액의 일부가 박00 전 정보통신이사에게 입금되었다는 주장도 사실이 아닌 것으로 확인되었습니다. 

의협은 홈페이지 개발에 차질을 빚고 물의를 일으킨 책임을 물어 S사와 조00으로부터 지급된 금액의 전액 환수를 요청했습니다. 조00씨는 이에 순순히 응하여 의협은 조00씨로부터 그가 취한 310만원 전액을 회수하였고 S사도 682만원 전액을 반납하겠다는 구두약속을 하였으나 최근 연락이 끊겨 아직 회수가 되지 않은 상태입니다. 이로 인해 결과적으로 지급된 1,782만원 중 310만원이 회수되어 의협 홈페이지 개편과 관련하여 총 1,472만원이 지급된 상태이고 이중 682만원이 회수 예정입니다. 

이번 사건과 관련한 이상의 상황에 대해 개괄적인 내용을 공지한 바 있으며, 특히 억울하게 횡령과 배임의 누명을 쓴 박00 전 정보통신이사가 이 사건과 전혀 무관함을 분명하게 밝힌 사실이 있습니다. 
그리고 조00씨에 대한 고발도 고려하였으나, 조00씨가 홈페이지 제작에 프로젝트 매니저로 참여하였으므로 형사처벌이 어려울 가능성이 높다는 법제이사의 의견과 지급된 금액을 회수하는 것이 의협의 이익을 위해 현명한 일이라는 이사진들의 판단에 따라 고발조치를 하지 않게 된 것입니다. 
그럼에도 불구하고, 모 의협회원이 박00 전 정보통신이사를 포함한 다수의 관련자들을 횡령과 배임으로 고발함으로 인해 또 한 번 박00 전 정보통신이사의 이름이 거론된 것은 유감스러운 일이 아닐 수 없습니다. 

이상 홈페이지 제작과 관련한 전말을 보고하였으며, 물의를 빚은 것에 대해 총 책임자로서 회원님들께 깊은 사과의 말씀을 드립니다. 저렴한 비용에 홈페이지를 제작하려는 과욕과 IT 전문영역에 대한 이해부족으로 발생한 사건으로 회원님들의 깊은 양해를 구합니다. 

PS. 만일 의사협회가 아니라 기업이었다면, 횡령이나 배임이 문제되는 것이 아니라 품질에 영향을 미치는 잘못된 입찰기준에 대한 책임이 더 문제가 되었을 것입니다. 책임을 떠나 이번 사건을 객관적으로 본다면 IT전문가 한 사람 없이 운영되어 오던 의협의 구조적인 문제에 기인한 사건이 아닌가 합니다. => 욕먹을 말씀인 줄 알면서도 드립니다

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

홈페이지 2300 만원짜리 만드는데 컨소시엄 구성? 날로 돈 빼먹을라고 난리 치는구나.. 과연 사기공화국 답다.

논리가 아니라 태도가 문제다? dev story

어제는 CTO 가 나를 불렀다. 

최근에 어떤 서비스를 오픈하기 위해서 관련팀과 일을 하던 중이였는데 언제나 그렇듯 일정이 빡빡하고 서로 신경이 곧두선 상태이다 보니 분쟁, 마찰이 있었다. 근데 쪽지를 하나 발송했는데 그것 문제가 된 것이다. 

""""""""
## xxxx 서비스 개발관련 환기.

이런 쪽지 보내는데에 대단히 유감스럽게 생각하며, 만나서 이야기 하지 못한점 죄송하게 
생각합니다. 현재 건강상태가 좋지 않은 관계로 양해 바랍니다.

1. 개요
  현재 xxxx 서비스 개발관련해서 문제가 되고 있는 통계 부분 관련 보고 있자니 
이래저리 말들이 다 다르고 잘못된 정보로 (구) x팀 및 y 팀만 쳐다보고 있는
상황에서 객관적 사실을 환기할 필요가 있어 관련자 모두에게 쪽지를 보냅니다.

2. 내용.
  통계부분은 현재 zzzz서바나 나 기타 서버에서 제공해주지 않으며,
현재까지 나온 상품들에서는 볼수 없었던 내용들로 그 구성은 다음과 같습니다.
  
  1) 파일별 전송량 및 조회수. 이를 날짜 대역을 넣고 조회가 가능해야 함.
  2) 각 디바이스별 전송량 및 조회수. 이것도 날짜 대력을 넣고 조회가 가능해야 함.
  3) 동영상 리스트를 전송량 및 조회수 별로 소팅해서 보여주기.
  4) 특정 기간내에 전송량과 조회수가 많은 순으로 소팅해서 보여주기.


위 관련 내용은 ㅇㅇㅇ님의 작업하고 회의했을 초창기에 보여줬던 내용들이며, 이러한 것들에
대해서 당시 내가 했던 의견은 

  - 프로그램으로 뭔들 못하겠나? 하지만 이건 힘들다. 비용이 많이 든다. 통계시스템을 따로 만들어야 한다. 

이였습니다. 이유는 간단한데, 저것을 위해서는 통계시스템이 필요하다는 것이였고 당시
기획을 담당했던 ㅇㅇㅇ님은 하신 말이 강하게 남는 것이

  - 못하는 건 아니죠?

4. CTO 에게 질문.

  1) 기획서에서 무언가를 적어놓으면 그것을 맡아서 담당하는 부서는 무조건 해야하는 겁니까?

      그때당시 인력이나 기술적 수준으로는 불가능하다라고 누차 이야기를 했음에도 '못하는 건 아니죠? ' 라는 말고 함께 회의를 거듭해도해도 '통계관리' 자체를 없애지는 않더군요. 오히려 가비아보다 능력없다는 소리를 대놓고 들어야 했습니다. 
  
  2) 만일, 제가 몸이 아프지 않았다면 3월 18일 오픈시에 통계관련까지 다 했어야 했었다고 말들이 있었다고 하는데 대체 누가 그런 소리를 하는건지요?

      분명히 기획초창기, 그리고 현 y팀 ㅁㅁㅁ팀장이 입사하고 나서 xxxx 서비스 개발 핸들링하기 시작하고 회의 참석하면서부터 내내 줄기차게 통계부분은 시간이 오래걸리며 오픈일에 하기 힘들다라고 줄기차게 말했는데, 오픈 얼마남지 않은 시점까지도 통계관리 라고 메뉴를 박아놨더군요. 그리고 몸 상태가 약간 호전된 상황에서 그래도 걱정스런 마음에
회사 몇일 나왔더니, 그럼 통계되는거냐 오픈날에 통계되는거냐는 시각을 가지신 분들이 있는거같던데, 분명히 말하지만 통계 애초에 않된다고 말했고 중간에는 현 y 팀장도 힘들다라고 분명히 주지시켰음에도 이렇게까지 말이 나오는데 대해서 의문이며 다음질문..

  3)  애초에 힘들다, 어렵다, 통계시스템을 만들어야 한다 라고 말했는데 왜 (구)x팀, 현 y 팀의 의견은 무시되었나?

     이 쪽지를 드리는 핵심은 이겁니다. 왜 개발자의 의견은 깡그리 무시되고 기획안에도 반영조차 않되는건지 둘둘 긴말하지 마시고 명확하게 답을 주셨으면 합니다. 

    '이랬던게 어디 하루이틀이냐?', '원래 니네팀 포지션은 그래~', '그럼 아싸리 말을 하지 말던가~' 라는 말은 집어치워주시고 지금 이렇게까지 된 근본적인 원인인 개발자의 의견 무시는 왜 발생된 겁니까?

     명확하게 답을 주십시오.

5. 기타
  이 쪽지와 관련해서 현 y 팀장에게 '얘 왜 이러냐?', '이런거 알고 있나?' 식으로 팀장에게 던지 않으셨으면 합니다. 답을 CTO 에게 구한거지 직속상관에게 구한게 아니니까요. 그리고 웃기게도 대화를 못한다, 성격까칠하다라는 잘못된 평가의 이미지로 이 쪽지를 않읽었으면 좋겠습니다. 

  개발자로서 그리고 개발자관련 총 책임을 지고 있는 CTO 로서 개발자의 의견이 무시되는 기획안그리고 그로인한 현 y 를 찍어누르는 압박들... 분명 잘못돌아가는 개발조직과 문화에 대해서 개발자에 모든것을 총괄하는 CTO 로서 두서없이 명확하게 답을 주셨으면 합니다. 

몇일내에 답변이없으면 들은걸로 하고 제 마음대로 생각하도록 하겠습니다.

ps, 죄송하게도 쪽지로 주셧으면 좋겠습니다. 회사 출근이 앞으로는 더 힘들지도 모르니...

""""""""

이 내용은 쪽지를 통해서 CTO 에게 던졌다. 그런데, 쪽지를 다른 사람에게 공개를 해버렸고 이 쪽지를 본 당사자들은 '저 새끼랑 일하기 싫다' 는 반응을 한 것이다.

CTO 가 날 부른 이유는 그 이유 때문이였다. 웃기게도, 순진하게도 나는 CTO 에게 개발자로서 답변을 듣고 싶었지만 그 CTO 는 쪽지 내용을 공개한 것이다. 쪽지를 공개로 인해서 졸지에 나는 사고친놈이 되었고 회사에 복귀 했을때에는 사람들이 '퇴사할 거다' 라는 소문이 돌았다고 한다. 퇴사한다는 말을 한적이 없는데도..

CTO 가 날 앉혀놓고 하는 소리가 '팀원들도 날 불편해하고 다른 팀 사람들도 일하기 힘들어한다. 님 말이 논리적으로 틀리다가 아니라 태도가 문제다. 사과해라'

이 무슨 개소리를...

그래서 나는 '나라고 불편하고 하지 않았게나?' 하니 CTO 는 '1:N 이다. 다수가 너를 불편해 한다. '

여기서 상황설명이 필요하다. 내가 일하는 팀에 대한 이야기다. 어찌된건지는 모르겠지만 이 회사에서 내가 있는 팀은 관련 부서가 많다. 시스템부터해서 기획팀까지 다른 어느 개발팀보다 많은 사람과 일해야한다. 이 말은 어느 팀보다 충돌, 분쟁 가능성이 높다는 것이다. 

원론적인 상황에서 CTO의 말은 맞다. 조직생활이란게 다수에 의해서 움직이고 있는 상황에서 ' 1:N ' 이 된다면 조직은 당연히 다수를 선택한다. 하지만 내가 일하는 팀의 상황은 항상 1:N 상황이다. 

더 웃긴건, 논리가 아니라 '태도' 라고 한다. 태도? 태도를 논리적으로 구분지을수 있나? 감정이 문제다. 내가 저 사람 기분나빠 하는 것이 어떤 일때문에 발생된 문제라면 그 일에서 무엇이 잘못되었는지를 먼저 보는게 순서이지만 단순하게 다수가 너랑 일하니까 태도가 문제가 있어서 일하기 싫다? 씨발~ 나는? 나는 무슨 니들 태도 좋았던걸로 보이냐?

거기다 팀원들도 불편해 한다고... 팀원들이 나로 인해서 불편해한다면 더 이상 내가 이 곳에 있을 이유가 없는 것이다. 

7년이다.

남들 눈치보며 않할라고 하는거 나서서 했고, 문제를 덮고 가는걸 그냥 못 넘기고 짚고 넘어가고자 했다. 개발이기에 개발자로 마인드를 지킬려고 노력했고 개발자로서 필요로하는 스킬, 커뮤니케이션등도 노력했다. 

웃기게다 회사는 날 보고 커뮤니케이션이 없다고 하는데, 과거에 인사팀장이 연봉협상할때에 나보고 '인상쓰는 얼굴이면 수술해서라도 웃는 얼굴로 만들어라' 했던 곳이 이곳이다. 

생각을 해보라. 언제 우리팀의 의견을 경청하는 자세를 보였었나? 기획자들은 '이런거는 뭐 개발자가 알아서 만들겠지?' 라는 마인드에 운영팀도 마찬가지 였다. '그건 그팀이 알아서 할일~' 

CTO 와 대화, 혹은 CEO 와의 대화 ? 이 회사는 그런거 없다. 

안타까운 현실이다. 현실은 냉혹한 법이다. 현실에서 감정은 모레알일 뿐이다. 파도에 휩쓸리는 모레알.

태도가 문제다? 나중에 그 태도가 좋아졌는지 나빠졌는지 감정의 문제를 타인에게 검사 받아야 하나? CTO 는 인간의 존엄성이라는 말을 알기나 한걸까?


IT 직종에서 좋은 회사? dev story

어떤 회사가 좋은 회사인가? 

이와 관련해서 많은 책과 많은 멘토들이 존재한다. 그런데, 다들 무슨 도덕교과서를 읽듯한 답변들이 대부분이였다. '착하게 살아라~' 누가 그걸 모르나? 자신이 하는 일에 열정을 가지고 꿈을 가지고 긍정적인 사고 매일 자신을 돌아보라. 누가 그걸 모르나? 

사회생활 10년이 다 되어 가면서 내가 느낀 현실적인 좋은 회사의 조건은 딱 한가지였다. 

"문제가 있다는 것을 인식하고, 중요하고 조심스럽게 문제를 해결하기 위해서 시간을 투자하는 회사"

간단한 예를 들어보자. 내 직업이 IT 이다 보니, 이 직종에서 벌어지는 일에 대해서 몇가지 예를 들어보겠다.

홈페이지를 운영중인데, 어느날부터 홈페이지가 안 열리는 현상이 발생했다. 트래픽도 얼마없었기 때문에 동접자 증가로 인한 문제는 아니였다. 무엇때문일까? 원인분석을 위해서 서버에서 접속하고 프로세스를 체크하고 웹서버로 쓰이는 아파치 로그를 보고 되었다.

아파치 에러로그에는 다음과 같은 메시지가 뿌려지고 있었다.

Out of Memory

APM(Apache + PHP + MySQL) 로 서빙을하는 웹페이지에서 Out of Memory 라는 사실과 함께 아파치 웹서버 한 프로세스당 메모리 사용용량이 1G가 넘어서고 있다는 걸 발견했다. 

Out of Memory 는 PHP의 MAX memory 값을 넘어서는 바람에 PHP에서 난 오류였고, 이 영향으로 아파치 프로세스의 메모리 소모량도 증가만 할뿐 반환을 하지 않는 이상한 사태가 벌어진 것이다. 

여기서 좋은 회사는 어떻게 대처할까?

우선 PHP 웹페이지를 프로파일링하게된다. Xdebug나 기타 많은 툴들을 이용해서 PHP 애플리케이션의 병목구간을 탐지하고 메모리 사용량도 체크해 PHP 애플리케이션의 문제점을 찾아내고 고치게 된다. 

Out of Memory 의 원인이 되었던 부분을 찾아내는고 PHP 소스를 고쳐서 메모리를 적게 소모하는 방향으로 버그 픽스를 하게된다. 

아파치 웹서버의 경우에 PHP의 Out of Memory 현상이 웹서버로 미쳤는지 다른 요인은 없는지에 대해서 프로파일링을 하고 대량접속 테스트를 통해서 같은 증상이 발생하지 않는지등 다양한 각도에서 문제점을 찾아내고 이를 해결하기위해서 소스 코드 분석등도 변행한다. 

두가지 방향에서 문제가 해결되었다면 대량접속 테스트를 통해서 동일한 문제나 혹은 다른문제가 발생되지 않는지등을 면밀히 검토한다. 아주 면밀히. 여기서 문제가 생겼다면 다시 문제해결을 위해서 시간을 투자한다. 

이런 방법을 문제를 해결하는 회사는 십중팔구 좋은 회사일 가능성이 있다. 언듯보기에 이 문제의 해결은 의외로 간단하지만 이 문제를 접근하는 시각에서부터 다른점이 있다. Out of Memory 의 문제를 PHP 애플리케이션의 잘못된 설계, 구현을 우선 지목해 그러한 문제 원인을 제거하기 위해서 힘쓴다는 것과 동일한 문제가 발생되지 않도록 테스팅을 거친다는 것이 그것이다. 이는 아시는분들은 아시겠지만 반복적인 작업이 연속이고 시간 졸라 많이 걸리는 작업이다. 

그런데, 이러한 문제해결에 시간을 투자하는 회사? 분명히 좋은 회사다.

반면에 그럼 않좋은 회사는?

Out of Memory 의 원인 PHP 애플리케이션 문제라는 사실은 인지했지만 다른 서버에서는 아무런 문제가 없었다고 주장, php.ini 파일에서 Max memory 사용량을 늘리면 해결되는 문제로 인해서 그렇게 Max memory 값을 수정한다.

그리고 아파치 웹서버의 경우 많은 메모리 사용량 문제는 웹서버의 한 프로세스당 사용하는 메모리사용량을 일정분단위로 체크해 그 이상 사용하고 있다면 웹서버를 재시작하는 걸로 해결한다.

'문제를 해결했다' 라는 결과론적인 관점에서는 둘의 차이는 별로 없어보인다. 오히려 후자의 방법이 시간이 덜 드는 방법으로서 효율성에서는 좋은 방법일지 모른다. 하지만 전세계 시스템 관리자 혹은 시스템 개발자에게 물어보라. 무엇이 제대로된 문제해결 방법인지.

'좋은 회사' 의 조건은 '문제 발생의 근본적인 원인을 해결하기 위해서 시간을 기꺼이 투자하는 개발조직 문화가 있는 회사' 다. 근본적인 원인해결을 위한 시각은 결국 사람의 정신상태에서 나오는 것이다. 따라서 좋은 회사의 개발조직 문화는 개발자 구성원의 마인드가 우수하다는 것을 반증하는 것이다.

dnspython 를 이용한 dig 예제. Publications

파이썬을 사용해서 dig  를 하고 싶다면 os.system 이나 subprocess 를 만들지 말고 dnspython 을 이용해 보자. 이 모듈을 이용하면 dig 같은 결과를 얻을 수 있다. 

import socket
import dns.resolver

# Basic query
for rdata in dns.resolver.query('www.yahoo.com', 'CNAME') :
print rdata.target

# Set the DNS Server
resolver = dns.resolver.Resolver()
resolver.nameservers=[socket.gethostbyname('ns1.cisco.com')]
for rdata in resolver.query('www.yahoo.com', 'CNAME') :
print rdata.target

# All retrieve DNS Info
resp= dns.resolver.query('www.yahoo.com')
print resp.response

여러 예제가 있지만 이렇게 하면 dig 와 같은 효과를 얻을 수 있다.


Strategy Pattern. 디자인 패턴

전략 패턴은 객체지향 프로그래밍에서 아주 기초가 되고 중요한 패턴입니다. 객체지향 프로그래밍의 핵심인 다형성을 이용한, 아니 이 패턴이 다형성일 정도로 중요 합니다. 

전략 패턴의 예제는 일상생활에서 매일 벌어 집니다. 집에서 회사로 출근을 합니다. '집에서 회사로 출근하다' 라는 말에는 방법이 없습니다. 단지 '출근하다' 라는 동작이 있을뿐 어떤 수단, 버스나 걷는거 혹은 자전거를 타는거, 등 아주 많습니다. 또, 농구 경기에서 선수들은 슛을 합니다. 그런데 슛에는 3점슛, 2점슛, 자유투등 방법은 가지가지 입니다. 

전략 패턴이 바로 이러한 것입니다. 어떤 행위의 목적은 모두 동일 하지만 그 방법이 모두 다를때에 이 방법을 객체화함으로써 객체의 확장성을 높여줍니다. 일단 전략 패턴을 설명하기 전에 농구 예제를 한번 구현해보겠습니다.


class BasketShooting
{
public function shooting($mark)
{
$res = '';
switch($mark)
{
case '2':
$res = '2점슛';
break;
case '3':
$res = '3점슛';
break;
default:
$res = '자유투';
break;
}

return $res;
}
}


슛을 하는 메소드를 만들고 거기에 Switch 문으로 그냥 간단하게 값을 리턴하도록 구현했습니다. 여기서 중요한 것을 상기해야 하는것은 이 슛예제에서 처리하는 Switch 은 아주 단순하게만 한것입니다. 만일 복잡한 로직을 채워넣는다고 상상을 해봅시다. 예를들면 각 슛에 대해서 예외처리를 해준다거나 뭔가를 더 처리를 해줘야 할 경우에 Switch 문을 잘 알아야 합니다. Switch 문을 알아야 한다지만 저 클래스 안에 메소드가 많이 있을 경우에 shooting 이라는 메소드를 찾아야 하고 그 않에 로직을 다시 체크해야 합니다. 

더 큰 문제는 외부 객체에서 이것을 사용해야 할 경우에는 문제가 될수 있습니다. 2점슛만 필요할 경우가 있을 수 있습니다. 그런데도 모든 로직을 다 가지고 가야 하고 이는 2점슛만을 필요로하는 객체에서는 모든 슛을 알수 있게 됩니다. 

이럴때에 다형성을 이용하면, 즉 전략 패턴을 이용하면 슛을 하는 행위와 그 행위의 방법을 분리하고 행위자체를 은닉할 수 있습니다. 전략 패턴은 목적은 같은데 방법을 객체로 분리하고싶을때 사용하는데, 여기서 목적은 모두 동일하기 때문에 이를 규격, 프로토콜로 모두 동일하게 해야하는데 이때 인터페이스를 사용합니다. 여기서는 슛이라는 것을 인터페이스화 합니다.

interface IShooting
{
public function shoot();
}

슛을 하는 방법을 객체화하기 위해서 클래스를 만듭니다. 여기서 인터페이스를 구현하는 클래스라는 점을 명심하십시오.


class Point2Shooting implements IShooting
{
public function shoot()
{
return '2점슛';
}
}


class Point3Shooting implements IShooting
{
public function shoot()
{
return '3점슛';
}
}


class PointFreeShooting implements IShooting
{
public function shoot()
{
return '자유투';
}
}


위의 클래스들은 전부 shoot 이라는 행위에 대한 클래스들입니다. IShooting 이라는 인터페이스를 사용해서 슛이라는 목적을 모두 구현한 것입니다. 이것을 다음과 같이 슛을 사용할 행위자를 만듭니다.

class BaseketBallPlayer
{
public function shoot(IShooting $shooting)
{
return $shooting->shoot();
}
}



실제 사용은 다음과 같이 합니다.

require_once '/Users/histlist/Sites/StrategyPattern/BasketBallPlayer.php';
require_once '/Users/histlist/Sites/StrategyPattern/IShooting.php';
require_once '/Users/histlist/Sites/StrategyPattern/Point2Shooting.php';
require_once '/Users/histlist/Sites/StrategyPattern/Point3Shooting.php';
require_once '/Users/histlist/Sites/StrategyPattern/PointFreeShoot.php';

class BasketBallPlayerTest extends PHPUnit_Framework_TestCase
{

public function testShooting()
{
$obj = new BasketBallPlayer();
$this->assertInstanceof('BasketBallPlayer', $obj);
$this->assertEquals('2점슛', $obj->shoot(new Point2Shooting()));
$this->assertEquals('3점슛', $obj->shoot(new Point3Shooting()));
}
}

플레이어 객체에 슛의 방법을 넘겨준다는 것에 주목하십시오. 만일 슛의 방법을 바꾸고자 한다면 객체를 넘겨주면 됩니다. 슛의 방법을 추가하고자 한다면 새로운 클래스를 만들고 객체를 생성해서 넘겨주면 됩니다. 이러한 슛의 방법은 플레이어 말고도 어디서든지 필요하면 가져다 쓸수 있습니다. 객체지향 프로그래밍의 재사용성을 높여줍니다.

전략패턴은 객체지향 프로그래밍에서 매우 중요하고 기본이 되는 패턴입니다.









CentOS 에서 Eclipe(Juno) PHP 개발 환경 구축하기. PHP 개발

이 문서는 CentOS 6.3 에서 Eclipe(Juno 버전) PHP 개발 환경 구축하는 방법을 설명합니다. 

Eclipse 를 이용한 PHP 개발을 하는 이유는 Eclipse 로 적어도 다음과 같은 것을 쉽게 할 수 있습니다.

  1. php coverage 
  2. php PHPUnit
  3. php CodeSniffer
  4. php Depend
  5. php Mess Detector
  6. php Copy/Paste Detector
  7. php Dead Code Detector

위와같은 것은 php pear 모듈들입니다. 모두 설치한들 Eclipse 에서 모두 사용하지는 않지만 나중에 Jenkins 를 이용해 '지속적인 통합'을 구축할 수 있게 됩니다. 또, Eclipse 에서는 PHPUnit 을 위한 플러그인을 설치해 TDD를 할 수 있습니다.

CentOS 를 데스크탑으로 사용하고 있어야 합니다. 그놈(GNOME)을 사용하던 KDE를 사용하던 그것은 아무 상관없습니다. 그리고 반드시 JDK가 설치되어 있어야 합니다.


Step1. PHP 설치하기.


PHP는 CentOS 6.3 의 패키지를 설치하면 됩니다. 
]# yum install php.x86_64 php-common.x86_64 php-pear.noarch php-xml.x86_64 php-mbstring.x86_64

이렇게 하면 PHP가 설치가 됩니다. 여기서 pear 패키지를 설치하는 일이 있는데 이것은 나중에 다시 설명하도록 하겠습니다.


Step2. Httpd 웹 서버 설치하기.


웹서버는 아파치 웹서버를 설치 합니다.
]# yum install httpd.x86_64 httpd-devel.x86_64 -y

이렇게 하면 설치가 됩니다. 이제 사용자 홈디렉토리를 설정해 주어야 하는데 환경은 다음과 같습니다.

  1. 접속 아이피: 192.168.111.11
  2. 홈디렉토리: /home/orion/site
'/home/orion' 의 시스템 계정이 먼저 있어야 합니다. 그리고 site 디렉토리를 생성합니다. 그리고 퍼미션을 다음과 같이 조정해 줍니다.
]# chmod 755 /home/orion
]# chmod 755 /home/orion/site

웹 서버에 설정 파일인 httpd.conf 파일을 다음과 같이 설정합니다.

 ]# vim /etc/httpd/conf/httpd.conf

ServerAdmin webmaster@192.168.111.11
DocumentRoot /home/orion/site
ServerName 192.168.111.11
ErrorLog logs/192.168.111.11-error_log
CustomLog logs/192.168.111.11-access_log common



Step3. Eclipse Juno 설치.


Eclipse Juno 의 설치는 PDT가 아직 없기 때문에 Classic 버전을 설치하고 여기에 PHP 개발 플러그인을 붙이는 방법으로 합니다. Eclipe Juno Classic  버전을 다운받아 설치합니다. 그리고 처음실행할때에 workspace 를 site 로 바꿉니다. 


그리고 OK.

Help -> Install New Software...  를 눌러서 'http://download.eclipse.org/releases/juno 사이트를 추가 합니다.


그리고 'Programming Languages -> PHP Development Tools (PDT) SDK Feature' 를 그리고 


'Web, XML, java EE and OSGi Enterprise Development -> Eclipse Web Developer Tools' 를 선택해서 다음을 눌러서 설치를 해줍니다.



Step4. Pear 모듈 설치.


pear 의 설치는 아주 중요합니다. Eclipse 는 도구이고 뒤에서는 pear 의 모듈을 모두 사용합니다. 따라서 매우 중요합니다. 먼저 pear 를 최신 버전으로 업데이트 해줍니다.

]# pear upgrade pear


PHPUnit 설치.

PHPUnit 은 Unitest 를 위한 pear 모듈입니다. 다음과 같이 해줍니다.
]# pear channel-discover pear.phpunit.de
]# pear channel-discover components.ez.no
]# pear channel-discover pear.symfony.com
]# pear install phpunit/PHPUnit
Did not download optional dependencies: phpunit/PHP_Invoker, use --alldeps to download automatically
phpunit/PHPUnit can optionally use package "phpunit/PHP_Invoker" (version >= 1.1.0)
phpunit/PHP_CodeCoverage can optionally use PHP extension "xdebug" (version >= 2.0.5)
phpunit/PHPUnit_MockObject can optionally use PHP extension "soap"
downloading PHPUnit-3.7.9.tgz ...
Starting to download PHPUnit-3.7.9.tgz (116,997 bytes)
.........................done: 116,997 bytes
downloading File_Iterator-1.3.3.tgz ...
Starting to download File_Iterator-1.3.3.tgz (5,152 bytes)
...done: 5,152 bytes
downloading Text_Template-1.1.4.tgz ...
Starting to download Text_Template-1.1.4.tgz (3,701 bytes)
...done: 3,701 bytes
downloading PHP_CodeCoverage-1.2.6.tgz ...
Starting to download PHP_CodeCoverage-1.2.6.tgz (155,960 bytes)
...done: 155,960 bytes
downloading PHP_Timer-1.0.4.tgz ...
Starting to download PHP_Timer-1.0.4.tgz (3,694 bytes)
...done: 3,694 bytes
downloading PHPUnit_MockObject-1.2.2.tgz ...
Starting to download PHPUnit_MockObject-1.2.2.tgz (20,347 bytes)
...done: 20,347 bytes
downloading Yaml-2.1.3.tgz ...
Starting to download Yaml-2.1.3.tgz (38,573 bytes)
...done: 38,573 bytes
downloading PHP_TokenStream-1.1.5.tgz ...
Starting to download PHP_TokenStream-1.1.5.tgz (9,859 bytes)
...done: 9,859 bytes
install ok: channel://pear.phpunit.de/File_Iterator-1.3.3
install ok: channel://pear.phpunit.de/Text_Template-1.1.4
install ok: channel://pear.phpunit.de/PHP_Timer-1.0.4
install ok: channel://pear.symfony.com/Yaml-2.1.3
install ok: channel://pear.phpunit.de/PHP_TokenStream-1.1.5
install ok: channel://pear.phpunit.de/PHP_CodeCoverage-1.2.6
install ok: channel://pear.phpunit.de/PHPUnit_MockObject-1.2.2
install ok: channel://pear.phpunit.de/PHPUnit-3.7.9


PHP CodeSniffer 설치.

CodeSniffer 는 Code Standard 를 맞춰줍니다. Code Standard 는 Code Style Guide 혹은 Code Covention 이라고 합니다. Zend, Pear 등 다양한 코딩 가이드를 맞춰줍니다.
]# pear install PHP_CodeSniffer
WARNING: channel "pear.php.net" has updated its protocols, use "pear channel-update pear.php.net" to update
downloading PHP_CodeSniffer-1.4.2.tgz ...
Starting to download PHP_CodeSniffer-1.4.2.tgz (368,879 bytes)
............................................................................done: 368,879 bytes
install ok: channel://pear.php.net/PHP_CodeSniffer-1.4.2


PHP Depend 설치.
]# pear channel-discover pear.pdepend.org
]# pear install pdepend/PHP_Depend


PHP Mess Detector 설치.
]# pear channel-discover pear.phpmd.org
]# pear channel-discover pear.pdepend.org
]# pear install --alldeps phpmd/PHP_PMD


PHP Copy/Paste Detector 설치.
]# pear channel-discover pear.phpunit.de
]# pear channel-discover components.ez.no
]# pear install phpunit/phpcpd


PHP Dead Code Detector 설치.
]# pear channel-discover pear.phpunit.de
]# pear channel-discover components.ez.no
]# pear install phpunit/phpdcd-beta

위와 같이 하면 Eclipse 를 이용한 PHP 개발 구축은 2/3 를 다 한 것이다.


Step5. PHPsrc Eclipse 플러그인.

PHPsrc  는 Eclipse 플로그인 이다. 이를 설치하면 PHPUnit 과 PHPdpend 등과 같은 많은 것을 Eclipse 에서 할 수 있게 된다. 다음과 같이 플로그인을 설치해 준다.


http://www.phpsrc.org/eclipse/pti 를 입력하고 위 그림과 같이 해서 설치해준다.



Step6. Eclipse PHP 환경 설정하기.

이제 PHP를 위한 환경을 설정해 준다. 'Windows -> Preferences' 창에서 PHP관련 설정을 해준다.


1) PHP Excutables 를 설정.


위 그림과 같이 설정을 해준다.

2) PHP Interpreter 설정.

설치된 php는 5.3 임으로 이에 맞춰준다.

3) PHP Servers 설정.


4) Pear Library 설정.


Pear Library 는 위 그림과 같이 Internal 이 아닌 CentOS 의 Pear 로 해줍니다.

5) PHP CodeSniffer.


위 그림과 같이 실행기와 라이브러리를 추가해주고 'print PHP output to console' 에 체크를 해줍니다.

5) PHP Copy/Paste Detector


위 그림과 같이 해줍니다.

6) PHP Depend 


7) PHPUnit


Step7. 테스트.

테스트를 한번 해보자. 다음과 같이 프로젝트를 생성해준다.


테스트를 하기위해서는 다음과 같이 테스트를 해봅니다.



Test Double 이란. PHP 개발

이 게시물은 http://blog.daum.net/aqua0405/5558319 여기서 가지고 온 것입니다.

Test Double
- 테스트를 수행하기 위해서 실제 컴포넌트 역할을 대체하는 기능을 가진 객체나 컴포넌트를 말한다.
 
Test Double 분류
1. Dummy Object : 가장 기본적인 유형으로, 매개 변수 값과 같이 작업을 수행하는 메소드가 없는, 값 전달만을 위한 객체를 말한다.
2. Test Stub : 아직 개발되지 않은 클래스나 메소드가 처리 후 리턴해야 하는 값을 전달해주는 역할을 한다. 대부분 그 값은 하드 코딩되어 있다.  
3. Test Spy : Stub과 비슷하지만, 어떤 작업을 수행했는지에 대한 이력을 남긴다는 점이 다르다. Stub과 같은 역할을 하는 척하지만 이름 그대로 스파이 같은 행동을 한다.
4. Mock Object : Dummy, Stub, Spy를 통합해 놓은 것과 비슷하다 볼 수 있다. 보통 라이브러리를 사용하여 동적으로 데이터를 처리해줄 부분을 생성한다. 즉, Stub기능에 검증(assertion) 기능을 추가한 형태라고 생각하면 된다.
5. Fake Object : 테스트에 직접적인 연관은 없지만, 테스트하고자 하는 시스템과 연계되는 시스템이 너무 느리거나, DB가 아직 구성되지 않았을 경우에 해당 부분이 실제 존재하는 것처럼 처리하는 부분을 말한다.

1 2 3 4 5 6