sosa0sa.com

자신의 S/W 블럭이 죽은 후

• A 블럭이 엉뚱한 메시지를 잘못 줬어요
• A 블럭이 보낸 메시지에서 이 필드에 이런 값이 있으면 안되요.

약속된 인터페이스대로 동작하지 않은 상대방 블럭의 책임도 있지만 그렇다도 예상하지 않은 값을 받았다고 죽어버리는 블럭을 작성한 개발자도 50%의 책임이 있다. 항상 외부와의 인터페이스에는 message length check, value range check를 수행해서 죽지 않도록 해야 한다.

일 = 경영. 한정된 자원과 시간을 가지고 최대의 결과를 창출하기 위해 실행전략을 구사하는 것.

단순히 주어진 일을 하는 것이 아니라 가장 적은 비용과 시간을 들여 자신의 영역에서 가장 최적의 결과물을 만들어 낼 것.

바꿀 수 없는 것에는 에너지를 쏟지 않는 것이 좋다.

스스로에 대한 동기부여는 오직 자신만이 할 수 있다.

역량

성과를 위해서는 지금 당장 가지고 있는 ‘능력’보다는 잠재적인 문제해결을 가능케 하는 ‘역량‘이 중요하다.

지속적인 성과를 보증하는 ‘일의 핵심’에 접근하려면, 본질을 꿰뚫어볼 수 있는 역량을 키워야 한다. 화려한 장식이 아니라, 그 이면에 있는 알맹이, 성과와 직결되는 해법을 꼬집어낼 수 있는 힘.

‘역량’이란 구체적인 성과로 연결시키는 능력이다. 다분히 경제적이고 전략적인 의미에서 차별화가 되는 특징이자 행동으로 반드시 들어나야 하는 ‘결과 지향적인’ 개념이다. 한두 번 우연히 이루어지는 것이 아니라 반복적으로, 습관처럼 자리잡게 되어야 비로소 ‘역량’이라고 할 수 있다.

눈앞의 일처리에 급급하기 보다는 결과치에 가장 영향을 미치는 핵심적인 문제해결에 집중하는 사람, 자신의 역량 즉 성과와 직결되는 탁월한 업무 능력을 키우는 데 집중하는 사람이 앞으로 핵심인재가 될 것이다. 바로 High performer이다.

실천이 따르지 않는 비전은 단순한 꿈에 불과하다.

비전이 없는 실천은 단순히 시간을 허비하게 할 뿐이다. 세상을 변화시키는 것은 실천이 따르는 비전이다.

자신의 시장가치는 자기 스스로가 만들어가는 것이다. 우리는 모두 자존심을 가지고 무한경쟁의 시장에 놓여진 상품이다. 그러니 나는 남들과 무엇이 다른가, 왜 같은 분야의 숱한 여러 명 중 나를 뽑아야 하는 하는 가 하는 차별화되는 강점, 전문성을 키워야 하는 것이다.

마케팅

마케팅의 초점은 ‘판매’가 아니라 ‘고객인 상대방이 무엇을 원하는 가’에 가장 먼저 초점을 맞추는 것이다. 그 상대방이 원하는 것을 가장 적은 비용으로 가장 빠른 시간 안에 가장 효과적으로 제공하는 것이 마케팅이다.

• 나의 고객은 누구이고, 나는 그 고객과 어떤 관계를 맺을 것인가?

• 나의 고객은 무엇을 원하는 가? 그렇다면 나는 무엇으로 그 니즈를 만족시킬 것인가?

• 나는 고객이 원하는 바를 어떻게 하면 적은 비용과 자원을 들여 적재적소에 제공하여 가장 효율적으로 만족시킬 것인가?

‘제대로 듣지 않는 직원’. ‘묻지 않는다’. 본인이 확신이 없어도 묻지 않고, 정확히 이해하지 못하고도 묻지 않는다.

조직문화

• 팀이 결정한 것에 대해서는 어떠한 경우에도 따라야 한다. 반대의견, 개선사항, 혹은 전혀 다른 시각을 제시하려거든 ‘의사결정’이 이루어지기 전에 충분히 해야 한다.

• 어떠한 경우에도 대안 없는 부정적인 피드백을 서로에게 주지 말아야 한다.

• 자신이 먼저 즐거움으로 무장하고, 그것이 주변 사람들에게 전염될 수 있도록 구체적인 실천방안을 만들어야 한다- 서로에게 같이 일하는 것만으로도 즐겁고 존경스럽고 배우고 싶은 존재가 되기 위해 노력해야 한다.

나는 어떠한가????

이번에는 혜승엄마가 핸드폰을 잃어버렸다. 쩝. 분명히 출근길에 가지고 갔다고 하는데 찾을 수가 없단다. 며칠 동안 전화를 했는데 딱 6번만 신호가 가고 그냥 음성사서함으로 넘어가버린다. 쩝.

전화기보다는 전화기에 남겨있는 전화번호부나 문자메시지등이 더 소중한 자료인데 아깝다.

새 전화기를 구입해야 겠는데 혜승엄마도 나 처럼 쉽게 핸드폰을 아무 거나 살 수 있는 처지가 아니다. 전화요금의 30%를 할인받는 혜택을 받고 있는데 현재 이통사가 아닌 다른 이통사로 옮기거나 혹은 현재 이통사도 신규로 가입하면 그 혜택이 더 이상 제공되지 않는다.

결국 할 수 있는 방법은 기기변경이나 내가 지금 쓰고 있는 2G 폰을 넘겨주고 내가 3G로 가는 방법.

2G 기기 변경이나  3G로의 전환신규나 어떤 경우든 이통사 입장에서는 이미 잡아놓은 물고기가 파닥거리는 걸로 보이기때문에 거의 혜택이 없다. -_-

마침 회사에서 사용하는 info-mobile서비스가 3G도 지원하게 되어서 전화기를 무료로 바꿔주는 행사가 있던데 전화기 모델이 W3300이다. 예쁘게 생겼지만 스펙이나 마무리는 대략 난감인 전화기. 아쉽게도 정말싼티 나는 전화기라 선뜻 손이 가질 않는다. -_-

은근히 이거 골치 아프다.

그냥 중고 전화기를 하나 살까?

내가 공대를 간 이유 

내가공대를 지망한 것은 어린 마음에 막연히 컴퓨터가 좋아서였다(근데왜 전산을 전공하지 않았을까???)

당시 내 성적이면 그래도 맘만 먹는다면 일류대는 아니더라도 의대는 갈 수준이었지만 “피”를 무서워하고 사람 대하는 데 도통 자신이 없는 터라 사람이 아닌 “기계”를 대하는 공대가 적성에 맞다고 생각했다.

10년.

입사한 지도 10년이 지났다. 주변머리가 없어 다른 길을 보지도 않고 그냥 한 길로만 왔다.

철없던 어린 시절에는 나에게 주어진 일, 내가 맡은 블럭만 신경써서 (당연히 타 블럭과의 연동 포함) 문제 없이 동작하는 게 전부 인 줄 알았다.

그리고 이제서야 깨달은 것은

결국 S/W 개발도 사람을 관리하는 게 핵심이구나.

얼마전에 만난 친구 녀석. 이젠 현역(?)이 아니라 8명의 부하직원을 둔 매니저가 되었단다. 첫 마디가

“말도 어지간히 안 듣는다”

후배들

함께 일하는 후배나  동료를 본다.

그들 중에 얼마나 많은 이가

S/W quality, 문서화, 자발적인 코드 리뷰, 타인에 대한 배려, 방어적인 프로그래밍, 정보 공유, productivity, unit test, block test, test automation…

이런 것들에 대해 고민하는 가 생각해 봤다. 몇 명의 얼굴이 떠올랐지만 그들은 손가락으로 꼽을 만한 수였다.그것도 왼손만.

Process

자꾸만 process를 복잡하게 한다. 패치하나를 내려고 하면 이런 저런 문서를 몇 가지를 함께 제출해야 한다. 당연히(?) 개발자들은 힘들어 한다.

그런데 어찌 보면 당연한 작업이다. 그동안 하지 않았을 뿐. 코드를 수정해서 패치를 내면 당연히 뭘 고쳤는지, 왜 고쳤는지등을 설명해야 할 것이고, 수정된 코드로 인해 기존에 잘(?) 동작하던 것들에 영향을 미칠 수 있으므로 regress test결과를 제출해야 할 것이다. 그래야 잘못된 패치로 인해 발생할 수 있는 부작용을 줄일 수 있는 것이다.

블럭 독점주의

블럭 담당자가 자기가 맡은 블럭이 뭘 해야 하는 지 모르는 경우도 많다. 누구말대로 “블럭 담당자”가 쉽게 딸 수 없는 타이틀이라는 것이라고 알게 해야 할 정도다. 이런 저런 잡일을 하다가 나름 실력을 인정받은 경우에만 “블럭”을 할당해서 자부심을 갖게해야 할 지도 모르겠다. 하지만 지금은 자신이 맡은 블럭은 남들은 전혀 신경도 안 쓰고, 신경도 못쓰게 자신만의 블럭으로 생각한다.

All I have to know is the programming language 

코딩을 위해 당연히 언어는 기본이고(모르면 필요하면 책을 보거나 reference code를 보면 된다) 코드 관리나 unit test, block test, documentation 등 다양한 내용을 알아야 한다. 하지만 오직 설계 문서도 없고(문서가 아니더라도 어떤 형태던지 설계에 대한 내용을 알 수 있는 기록) 코드에는 코멘트도 없고, test case도 정리하지 않고, 타 블럭과의 연동은 항상 직접 붙어야 한다고 생각하는 자세.

결국 사람이 문제다.

개발자의 능력이 문제고, 그 보다는 개발자의 자세/자질의 문제다. 동시에 입사한 신입사원을 보더라도 정말 흔한 말로 “열정”을 가지고 노력하는 모습이 보이는 사람과 그렇지 않은 사람은 확연하게 구분이 된다. 비록 지금은 별 차이가 없을 지라도 불과 1-2년만 지나면 그 두 사람에 대한 대우가 달라진다. 금전적인 것이 아니라 동료 혹은 선배들이 바라보는 시선이 달라진다.

잔소리

매일 아침마다 하라고 하는 이야기가 있다. 하지만 한 명도 안한다. 왜 안하는 걸까?

하기 싫어서? 하기 귀찮아서? 힘들어서?

이유가 뭘까? 정말 이유가 뭘까?

큰소리

왜 회의때마다 그 사람이 그렇게 언성을 높이는 지  가끔은 이해가 된다.  “왜 내가 시킨 걸 안했어” 도 있겠지만 “왜 너희들은 나만큼 관심을 갖지 않는 거야”라고 이해가 될 때도 있다. 나도 나이가 들어서 그런 것일까?

Management

사람이 싫어 공학을 했지만 가끔은 사람을 관리하고 싶다는 생각을 한다. 나라면 조금 다르게 해 보지 않을까? 나라면 좀 더 인간적으로 대할텐데. 지금 내 위의 관리자들은 “사람”을 “사람”으로 대하지 않고그저 “블럭 담당자”로 보는 듯해서 무척 아쉽다. 그렇게 해서는 품질 개선을 위한 지시 사항은 모두 “숙제”로 느껴질 뿐일 것같다. 사람들의 “공감”을 얻는 노력이 필요한데 그게 없다.

이러한 문제는 Ego가 강한 한 개인의 문제라기보다는, 팀 문화의 문제라고 생각한다. 어떤 잘못이 있을 때 원인과 해결 방법에 집중해서 논의가 일어나기 보다는 그 사람의 성격 탓으로 돌리는 행위나 감정을 자극하는 언행들이 팀원 하나하나로부터 조금씩 보이면서 팀의 문화로 형성되는 경향이 있는 듯하다. egoless programming

그래서 뭐~

그냥 그렇다고. 나중을 대비해서 열심히 효과적인  S/W project management나 심리학등을 공부해야 겠다.

• The Psychology of Computer Programming: Silver Anniversary Edition (Paperback)

회사에서 사용하고 있는 키보드는 펜타그래프 방식중에 가장 좋은 제품중의 하나라는 매컬리 키보드였다.

근데 언젠가부터 손가락에 지나치게 힘을 주고 있다는 것을 느꼈다. 그래서 조금만 타이핑을 해도 손가락이(특히 새끼 손가락)이 아프다.

당장은 예전에 쓰던 로지텍 멘브레인 키보드를 사용하고 있는데 이 녀석도 누를 때 꽤 힘을 줘야 하는 녀석이라 빨리 손에 편한 키보드를 구해야겠다.

가장 좋은 것은 집에서 사용하고 있는 맥미니 키보드이다. 타이핑할때도 경쾌감이란 정말~

하지만 집에서 키보드를 별로 쓰지는 않지만 이걸 회사에 가져오면 집에서는 뭘 써야할 지가 문제되기때문에 고민이다. 그래서 하나 추가로 구입하려고 했는데 국내 수입이 안되는 지라 구하기가 어렵다.

그러다 찾은 것은 바로 필코 마제스터치 104 키. 외국회사에서 만든 키보드라 내가 전혀 사용하지 않는 한/영 키가 없다. 덕분에 스페이스바는 충분히 길고, 기계식이라 손에 부담도 적다.

다만 문제는 기계식이라 시끄럽다는 점. 이번에 필코 키보드를 알아보다 공부한 내용이 바로 체리 키캡인데

• 청축 : 흔히 말하는 기계식. 경쾌하고, 키를 누를 때 중간쯤 걸리는 느낌이 있고, 딸깍 소리가 난다(흔히 클릭 이라고 불림)
• 갈축 : 청축에서 소리를 없앤 모델(흔히 넌클릭이라고 불림)
• 흑축 : 갈축에서 중간에 걸리는 느낌도 없앤 모델(흔히 리니어 라고 불림)

웹에 올라와 있는 소리 관련된 동영상을 봐도잘 감이안 온다. 이걸 사무실에서 사용할수 있을지 아닌지.

예전에 회사 사람이 사용하던 HHKpro2는 소리는 확실히 크기 않아서 사무실에서 사용하기에 문제는 없었는데 지나치게 비싼값(물론 모니터, 마우스, 키보드와 같은 사람이 사용하는 부품은 좋을걸 써야 한다는 것이내 지론이지만…) 그리고 결정적으로 방향키가 없다. -_-

vi에서야 방향키가 없어도 되지만 어디 맨날 vi만 쓰는 거도 아니고. -_-

고민스럽다.

VDT 증후군이 오기 전에 얼른 대비해야 할 텐데…

그리고 추가로 체리 백색 키보드(G80-3000)

Scott Guthrie 와의 대담 중에 이런 내용이 있다.

- 개발자의 관리자로서의 스캇 모든 매니저가 그렇지만, 개발자들의 관리자로서 팀원들이 성장하게 돕는 것이 가장 중요한 역할이라고 생각한다. 또한 고객 중심적인 마인드를 개발자들이 갖게 하려고 노력한다. 큰 글로벌 기업의 개발자들이 잊기 쉬운 점이 바로 고객의 입장에서 생각하고 고객들과 소통하는 것이다. 또한 목표한 바는 결과로 반드시 만들어 내는 것도 중요하다고 본다. 개발자들을 코드로 보상을 받는 것이라고 생각한다. ‘개발 작업’을 하는 것이 아닌 ‘좋은 제품’을 만들어 내는 것이 중요.

“고객 중심”  이란 말은 정말 지겹게 들은 이야기지만 정말 내게 “고객”이 누굴까 하는 생각을해 본다.

• 나는 제품을 만드는 개발자이므로 내가 만든 제품을 구입하는 사람이 1차 고객일 것이다.
• 하지만 그 외에 내가 만든 S/W를 시험하는 사람이나 내 블럭의 정보를 이용해서 디버깅하는 사람(검증 담당자나 내 블럭과 관련된 동료 개발자)도 2차 고객이다.

1차 고객도 중요하지만 2차 고객도 그에 못지 않게 중요하다. 2차 고객이 쉽게 일을 할 수 있어야 1차 고객에게 제품을 제공하기 전에  제품의 완성도를 보다 높일수 있기 때문이다.

그러므로 고객에게 제공하는 “기능 설명서”나 “운용 설명서”외에도 나 혹은 동료 개발자 고객을 위한 “디버깅 설명서”에도 신경을 써야겠다.

“The practice of an Agile developer”를 보면 Architect가 설계만 하면 안된다고 했다. 전적으로 동감하는 말이다. 회사에서 일을 하다면 “현실”을 알지 못하고 이론만 아는 설계팀과 충돌할 때가 많다.

책에서 보면, 다른 회사의 feature를 보면 그리고 혼자서 생각을 하면 A라는 기능은 이 제품에 꼭 필요한 기능이다. 그래서 말한다. “A라는 기능이 없는 제품은 본 적이 없다고”

그럴 때 S/W 개발자는 말한다. “와서 만들어 놓고 가라” 어찌보면 개발자 입장에서 “못한다”라고 말하는 것은 무척 자존심 상하는 일이다. 왜냐하면 S/W 개발자가 못한다고 하는 것은 다른 이유가 아니라 실력/능력이 부족해서 못한다고 생각하는 사람이 대부분이기 때문이다.

하지만 S/W 개발자에게 자원들이 무한정 주어진 것이 아니다. CPU power 그리고 메모리등. 한정된 자원을 주고 게다가 한정된 개발 시간을 주면서 모든 일을 하라고 하니 어떤 일을 할 수 있는 것도 있고, 또 어떤 일을 할 수 없게 되는 것이다.

그리고 Agile에서는 S/W에서 요구사항의 변경은 피할 수 없는 것이므로 어쩔 수 없는 그 상황에도 잘 대처할 수 있도록 하라고 한다. 하나의 water fall 구조가 아니라 잦은 iteration을 이용하라는. 아쉽지만 현실이 그렇지 못할때가 많다. 여러 사람이 함께 개발을 하다 보면 블럭간의 인터페이스를 함께 바꿔야 하는데 이때는 아쉬지만 기술적인 이슈보다는 정치적인 이슈가 개입될때가 많다 -_- (Agile 책을 보면 큰 프로젝트일 수록 water fall이 실패한다고 했는데 정말로 Agile 방법론을 사용할 수가 있는 걸까 늘 궁금하다. 이해 당사자가 무척 많을 텐데)

그래서 대개 설계인력은 S/W나 H/W 개발 경력이 최소한 얼마정도는 있는 사람으로 구성하기 나름이다(물론 늘 그런 것은 아니다. 박사인력인 경우 대부분 S/W 개발보다는 바로 설계 업무를 배정하는 경우가 대부분이다. 누군가 말한 것처럼 박사과정이 하나의 토픽에 대해 전문성을 갖는 것보다 문제를 풀어가는 방법을 배우는 과정을 배운 것이 더 의미가 있다고 하는 것처럼 대부분 실무적인 S/W 개발 경험이 없더라도 잘 하는 경우가 많다(혹은 석/박사과정에서 산학 협력등의 경험을 한 경우도 많고)

다만 그렇지 못한 고급인력(박사로 한정하는 것은 아니다)들이 다른 사람을 힘들게 하는 것이다. 머리는 똑똑하고 나름대로 정보 습득 능력은 높기때문에 보고 들은 것은 많은 데 그것을 자기가 가진(자기가 속한 회사가 만드는) 제품군에 무조건적으로 적용하려다 보니 실무자인 개발자와 충돌하는 경우가 많다.

갑자기 이런 글을 적는 이유는 아침에(토요일이니 새벽이군) 블로그 뉴스를 보다 보니 이런 내용이 있어서이다.

그는 알만한 이들만 아는 회사인 ‘마이크로소프트’라는 회사에 근무하고 있고, 하는 일은 마이크로소프트 개발자 사업부 총괄책임자(전무)다. 소프트웨어를 만들 때 사용하는 개발 툴인 비주얼 스튜디오(Visual Studio) 제품과 닷넷(.Net) 프레임워크 기술 개발을 책임지고 있다. 그가 이끄는 팀은 총 620명. 그는 개발자 사업부 총괄 책임자지만 여전히 매일 서너시간은 코딩을 한다. 그가 하는 코딩은 이미 제품화 된 것보다는 대부분 새로운 아이디어를 시도하는 프로토타입으로 그치는 경우가 많지만 끊임없이 새로운 시도를 추구하고 있다.

와우. 정말 말로만 듣던 코딩하는(프로토타입이라는데 당연히 그래야 하는 것 아닌가? 620명을 총괄하는 살마이 문제점 해결하겠다고 코드 리뷰하는 것도 우스운 일이니-우리 회사엔 그런 사람이 있다고 하는데) Architect(심지어는 project manager) 아닌가. 난 주변에서 코딩한다는 architect를 본적도, 있다는 소문을 들은 적도 없다. 대부분의 사람들이 모두 엑셀이나 파워포인트만 다루고 있다.

너무나도 다른 사람, 회사 분위기가 놀라울 따름이다.

그 외에도 기억하고 싶은 글은

그는 국내 개발자들과의 대화에서 ‘초기 평개발자로서 새로운 시도가 쉽지 않았지 않았느냐’는 질문에 “마이크로소프트에서는 ‘Code wins’라는 말이 있습니다. 개발자라면 직급이 아니라 코드를 통해 해결책을 내놓는 것으로 인정받는다는 것입니다“라고 밝혔다. 그는 또 “ASP.NET도 처음에 나 혼자 프로토타입을 개발하고 나서 그 이후 3-4명의 작은 팀이 생겼습니다. 서버를 통해 코드를 관리하는 것이 효율적이라는 것을 스스로 믿고 강하게 주변 사람들을 설득하는 것이 중요했습니다”라고 조언을 아끼지 않았다. “목표한 바는 결과로 반드시 만들어 내는 것도 중요합니다. 개발자들은 코드로 보상을 받는 것이라고 생각합니다. ‘개발 작업’을 하는 것이 아닌 ‘좋은 제품’을 만들어 내는 것이 중요합니다”라고 관리자로서의 개발자 역할도 강조했다. 스콧 구슬리는 “블로깅은 4년여 전에 시작했는데, 약 2년 전부터 심층적 기술문서들을 올리면서 많은 개발자들이 조회하고 참고하는 정보소스가 됐습니다. 한 달에 보통 10-15회 문서를 올립니다. 이 과정을 통해 우리 기술팀이 개발한 기능들을 더 잘 이해하게 되기도 합니다”라고 밝혔다 스콧 구슬리 전무는 “항상 고객을 염두에 두는 개발자가 되십시오”라는 말로 이번 방한을 마무리 했다

그의 블로그 주소는 http://weblogs.asp.net/Scottgu 이다

꼬랑지) 당연한 이야기지만 설계인력이 늘 현실을 무시하고 과하게 요구하고, 늘 S/W 개발자가 맞는 말만 하는 것은 아니다. 또 많은 경우에는 S/W 개발자의 능력 부족이나 게으름, 혹은 잘못된 태도때문에 타당한 요구사항을 수용하지 못하겠다고 거부한다. 결국 답은 서로가 서로를 좀 더 이해(알기도 하고, 배려/인정도 하고) 서로 지식을 공유하고 많은 대화를 가져야 한다. 누구나 아는 답이 아닐까? 누구나가 다 하는 것이 아니기때문에 문제지만.