downcast overloading.에서 언급했던 downcast overloading 테크닉?을 유틸리티처럼 빼서 구현해보았습니다.
더 보기 “downcast_overloader 코드. :)”
[월:] 2006년 09월
Skype를 믿으십니까?
Skype의 위험성에 관해.
네트워크 프로토콜 분석을 업으로 삼아 살아가고 있는 터라, 보통 1년에 10~15개정도의 프로토콜을 분석하는 편입니다. (물론 이거 말고도, 제품 엔진 작업이나 기타 여러 작업이 있는터라 프로토콜 분석쪽에 전념하고 있는 것은 아니지요.)
다양하고도 많은 프로토콜을 접하게 되는지라, 여러 프로토콜을 보고 있노라면 참 많은 생각이 듭니다. 정말 무식하게 짠 프로토콜도 있고, 감동을 먹을정도로 멋진 프로토콜도 있지요. 물론, 감사할 정도로 쉬운 녀석도 있는가하면, 진절머리가 날 정도로 복잡하고 어려운 프로토콜도 있답니다. (빌어먹을 오라클, MSN)
네트워크 프로토콜은 의외로 과도한 보안이 보안을 해치는 경우가 있습니다. 네트워크 솔루션은 그 통신내역에 의해 어느정도 투명성을 보장받지요. 솔루션 자체가 비밀정보나 프라이버시를 외부로 빼돌릴수 있으며, 이 가능성은 해당 네트워크 솔루션이 어떤 내용의 통신을 하고 있는지를 보면 어느정도 판단이 가능합니다. 리버스 엔지니어링에 의한 솔루션의 Clearness 보장이지요. 물론, 통신내역을 볼 수 있다는 것 자체가 개인정보의 유출 가능성을 항상 내재하고 있는 것이긴 합니다만, 솔루션 자체에 의한 정보유출 역시 무시할 수 없습니다. (Sony에서 발매된 CD에 들어있는 백도어를 생각해보면…)
더 보기 “Skype를 믿으십니까?”
development as a war
프로로서 프로그래밍을 한다는 것 -즉, 돈을 받고 프로그래밍을 한다는 것-은 돈을 매개로 싸우는 전쟁터에 나간다는 의미이다.
결국은, 비용과의 전쟁이다. 하드웨어 비용과의 전쟁. 소스코드 유지비용과의 전쟁. 프로그래머의 임금과의 전쟁. 고객사 지출비용과의 전쟁. 고장난 하드웨어 기판 수리비용과의 전쟁.
이런 전쟁에서 프로그래머가 싸우는 필드는 자신의 컴퓨터와 마우스, 키보드가 아니라 팀원들과 공유하는 작업실 공간이다. 이런 전장에서 필요한 타입의 병력(?)이 존재한다.
지금 일하고 있는 팀을 이야기할때 종종 사용되는 비유가 있다. 기마병, 보병, 병참 및 작전.
기마병은 적진의 한가운데를 돌파하여 적진을 혼란에 빠지게 하면서, 돌파구를 찾는 역할이다. 프로그래머라면 전에 언급되었던 람보개발자일 것이다. 난제를 풀어 나가며, 길을 뚫어놓는 역할. 기마병이 없다면 팀은 앞으로 나아갈 수 없다.
보병은 기마병이 혼란에 휩싸이게한 적진을 압박해나가며, 점령지를 늘리는 역할이다. 람보개발자가 뚫어놓은 돌파구를 다져가며, 안정성을 확보하고 제품을 제품답게 만드는 건축가개발자라고 볼 수 있다. 팀을 뒤로 가지 않게 하는 것, 지속적으로 돌파구를 뚫어낼 수 있는 기반을 확보하는 것, 이 일이 없다면, 제품은 제품이 아니라 아이디어일 뿐이다.
그런가 하면, 병참과 작전도 매우 중요하다. 다른 부서와의 인터페이스, 스케쥴의 조정, 방향성의 설정등의 전체를 조망하며 팀의 결속을 강화하고 팀을 유지시키는 것. 이것이 없다면, 람보개발자도, 건축가개발자도 일을 할 수 없을 것이다.
팀의 역량과 상황에 맞추어 저 역할들은 유동적으로 agile하게 변해야한다. 기마대가 너무 난리를 피우고 다니면, 보병이 뒷수습하기가 너무 힘들어진다. 역으로 보병이 뒷수습을 못해주면, 기마대는 전멸하게 되어있다. 이런 상황을 제어하지 못할 경우는 말할 나위도 없다. 때로는 기마대가 말에서 내려 보병이 되어야하고, 돌파가 힘들면 보병이 말에 타고 돌격을 해야한다.
프로그래머가 공부를 해야하는 이유는 바로 저 유동성에 있다. 언제라도 상황에 맞추어 작업할 수 있는 능력. 때로는 기마대가 되어 돌파를 하고, 때로는 보병이 되어 뒷수습을 하고, 병참과 작전을 도맡아 상황을 제어하기도 해야하니 말이다.
만약, 저 세 가지를 한번에 요구하는 경우가 생긴다면, 조직을 바꾸도록 노력을 해봐야한다. 해도 안된다면 이직을 고려하라. 🙂