조선의 제일가는 문장가로 불리기에 손색이 없는 박지원의 책 '그렇다면 도로 눈을 감고 가시오'와 서얼출신으로 한평생 청빈한 가운데에서도 책읽기를 즐겨하였던 이덕무의 '청장관전서'에서 짜집기한 책 '깨끗한 매미처럼 향기로운 귤처럼', 청언소품집 '한서 이불과 논어병풍'이 그것인데, 하나같이 시대를 넘어 주옥같은 명문과 청빈하면서도 맑은 정신, 벗과 함께 풍류를 논하며 더 나은 세상을 꿈꾸는 그들의 모습에서 조선의 르네상스를 만들 뻔하였던 그때의 희망을 보는 듯 하였다.
허나 그들 북학파 선비들이 바라본 세상을 지금의 눈으로 바라본다면 답답한 마음이 한둘이 아니다. 우선 사회가 너무나 옛것의 권위에 눌려있다보니 그들 역시도 그들의 생각과 말과 행동을 옛 것, 더 정확히 말하면 주자학의 테두리에서 벗어날 수가 없었던 것. 이러한 답답함은 박지원의 글을 읽는 내내 느껴야했다. 더더욱이나 답답했던 것은 이덕무의 청빈한 삶을 애찬하는 글을 읽을 때였다. 세상에 아무리 책을 좋아하는 선비라지만 자기 가족이 굶고 있는데 대체 책만 가득 채워놓는다면, 그런 선비를 대체 어디에 쓸 것인가? 수신제가치국평천하라는데 수신만 하지 제가는 하지도 못하는 그런 선비가 벼슬길에 오르니 그런 찌질한 선비들로 가득한 국가기관이 제대로 돌아갈 리 없다.
과연 우리의 옛것은 모두가 옳을까? 그들의 정신을 온전히 지금의 우리에게 가져온 들 그것이 그렇게 가치가 있는 것일까? 때로는 그들의 청빈하면서도 맑은 정신에 감탄하고 흥겨워하지만 그것은 온전히 지금의 것이 아닌 옛것일 뿐, 우리가 가져가야할 것은 아니라는 점에 안타까움을 느끼면서도 내가 혹시 제대로 건져내지 못한 옛것의 아름다움은 없는 지, 나의 짧은 안목이 아쉽다.
어제인가 위자드닷컴이란 곳에서 추천 블로그들을 엄청 많이 발표했길래 이게 왠 떡(정보)이냐 싶어 무지 많은 시간을 들여서 정말 하나씩 하나씩 들어가보았다. 괜찮은 블로그라면 당연히 RSS 목록에 추가해야지 하는 마음으로.
결론은.. 일단 그래도 추천 블로그들이라 그런지 건질만한 블로그도 많았지만 대부분 개인적으로는 실망스러운 블로그가 대다수였다.
나는 블로그는 미니홈피처럼 사생활이나 지인들에게나 소통할만한 꺼리들을 이야기해서는 안된다고 생각한다. 미니홈피는 1촌이라는 대상 중심의 개인 서비스다보니 사생활이라던지 신변잡기를 노출하더라도 어느 정도 이해가 되고 또 그런게 미니홈피의 매력이다. 하지만 블로그는 1촌대상 서비스가 아니라 통성명 한번 해본 적 없는 대중들을 상대로 하는 서비스가 아닌가? 미니홈피랑은 다르게 한번 글을 블로그에 쓰면 왠만해서는 삭제할 수가 없다. 블로그에선 삭제해도 여전히 검색엔진에는 남아있다는 게 문제다.
오늘 외로웠다든지, 인라인 스케이트를 시청에서 탔다든지, 누구나 그 정도는 커피마시며 잡담했을법한 뻔한 최진실 자살이야기라던지, 뉴스에도 뻔히 나오는 기사를 그저 아무 감상없이 올린다든지, 여친이랑 헤어졌다든지, 애기가 아파서 그동안 블로깅을 못했다던지
대체 어쩌라고?
물론 그 사람의 삶이 너무나 아름답고 훌륭해서 박수라도 치고 눈물흘리지 않으면 안될 거 같은 스토리면야 엄청 고마운 블로그지만 여친없어 외롭거나 프리라인 스케이트를 어디에서 타고 놀았다는 얘기를 나는 왜 읽고 있어야하는 지를 모르겠다.
최근 GS칼텍스의 1100만명의 고객 정보가 외부로 유출 및 거래되어 사회적으로 큰 파장을 일으킨 사건이 있었다. 결국 돈을 노린 내부직원의 소행인 것으로 밝혀졌고 여전히 집단소송에 휘말려 GS칼텍스는 안팎으로 심란한 상황인 듯 싶다. 비단 GS칼텍스 뿐만 아니라 얼마 전 포스데이타의 경우 전현직 연구원이 외국에 와이브로 기술을 빼돌리려하다가 적발된 사건도 있고보면 보안의 이슈중에서도 내부자가 일으키는 것은 그 파장이 다른 것들에 비해 기업 입장에서 훨씬 큰 것으로 보인다. 아무리 보안요원이 외부인 출입을 철저하게 관리한다한들 믿었던 직원의 클릭 한방이면 말짱 도루묵인 것이다.
외국의 보안기업인 Cyber-ark는 최근 유럽에서 열린 Infosecurity 2008 행사에서 300명의 시스템 관리자를 대상으로 설문조사한 결과를 발표하였는데 그 내용이 매우 심각하면서도 의미있다.
약 88%의 IT관련 부서 담당자들은 만약 그들이 해고를 당한다면 그들이 가지고 있던 보안자료와 원격 접속 권한 정보등을 고스란히 들고 가져가겠다고 답변하였다.[기사내용] 더욱이 1/3의 응답자는 회사의 비밀번호 리스트를 몽땅 가져가겠노라고 버젓이 대답하였다는 것이다.
보안기업에서 직접 실시한 통계이니 기업들의 보안강화를 위한 의도된 설문이었을 수 있지만 그래도 88%는 솔직히 심각한 숫자가 아닐 수 없다. 10%가 그렇게 응답을 했어도 부도덕한 몇몇의 관리자의 문제라고 생각하며 법적인 조치를 강화하는 것으로 결론내릴 수 있겠으나 대다수의 응답자가 미래의 스파이일 수 있다는 것은 문제의 해결을 근본적인 관점에서 풀어야할 것이다.
기사에서는 주기적인 비밀번호 변경과 적절한 사내 권한 시스템 확립등을 제안하고 있으나 과연 사람이 하는 일에 그 정도의 시스템만으로 보안이 완벽할 것이라 안심할 수는 없을 것이다. 철저한 보안정책이 모든 IT활동에 뿌리내려야만 할 것이다.
그럼에도 불구하고 강력한 보안정책이 오히려 IT부서의 효율성을 심각하게 저해하는 것 역시 사실이다. 비밀번호 하나 변경하거나 port를 하나 열거나 ip를 하나 받아내는 데 이틀 사흘이 걸린다면 대체 무엇을 위한 IT인가를 다시 묻고싶어질 때가 있다.
기사의 내용대로라면 직원이 해고되었을 때 그 때를 조심하라는 것인지. 앞으로는 해고를 당해도 곱게 당하지 않는 미래가 올지도 모르겠다.
1.개발자는 사업상에 실질적으로 필요한 것을 생각하지 않는다: 기술을 뽐내기만 하지 실제적으로 필요한 것을 가장 빠른 시간 내에 할 생각을 하지 않는다.
2. 개발자는 고객 관점에서 생각하는 습관이 없다
3. 개발자는 제품에 어떻게든 깜짝 놀란만한 것을 넣어보려고 한다: CIO가 원하는 것은 안정적인, 표준화된 무언가이다. 최신 기술을 좋아하는 개발자는 상황을 언젠가는 불안하게 만든다.
4. 개발자는 ROI, TCO 혹은 다른 비즈니스 우선순위를 전혀 생각지 않는다.
5. 개발자는 IT가치 전달에 소극적이다.
6. 개발자는 조직에 대한 기술이 부족하다.
7. 개발자는 협업하여 사고하는 능력이 부족하다.
8. 개발자는 매니저를 이해하지 못한다. : 때로는 조직의 인력감축과 해외 아웃소싱은 불가피한 것이다.
나 역시 개발자출신이고 지금도 반은 엔지니어의 일을 하고 있지만 가끔 현장을 돌아다니거나 주위의 사람들의 이야기를 듣다보면 심하다 싶게 엔지니어주의가 오히려 비즈니스에 역행하는 경우를 접하게 된다.
개발자는 문제를 해결하기 위해 너무나 고상한 길을 가려한다. 사실 고객이 원하는 것은 단순하고 간단한 것인데 개발자는 그것을 위해 자신의 기술을 뽐내기를 주저하지 않는다.
모전자에서 연구원으로 있는 한 친구의 이야기이다. 연구소에서 6개월짜리 프로젝트를 하느라 자바를 잘하는 업체를 외주로 같이 참여하게 되었다. 웹서비스로 여러 서비스를 연결하는 프로젝트였지만 사실 그렇게 난이도가 높거나 복잡한 것은 아니었다. 문제는 이 외주 업체의 개발자들이 멋진 아키텍처의 오픈소스 프레임워크 신봉자였던 것. 어차피 연구소 입장에서는 연구결과 발표하면 끝이고 변화가능성 및 유지보수에 대한 문제에 대해 고민할 필요가 없는 프로젝트인데도 불구하고 외주업체 개발자는 예리한 칼로 레이어를 나눠대기 시작하고 복잡도를 스스로 증가시켜 버렸다.
너무 훌륭한 개발자는 때로는 제품화에 걸림돌이 되는 경우도 있다. 소규모 IT벤처를 이끌고 있는 어느 사장은 그 회사의 제품을 개발해나가는 과정에서 최근 많은 어려움을 겪고 있다. 문제는 어느 훌륭한 개발자 때문이었다. 사장입장에서는 회사에 돈이 매우 부족하기 때문에 제품의 질은 좀 떨어지더라도 빨리 개발에 성공하여 핵심 아이디어로 무장한 제품화를 통해 시장의 반응을 보고 그 반응에 따라 회사 전략을 세우고자한다. 이를테면 펀딩을 받거나 영업을 강화하거나 제품 개발에 더 투자하거나 함으로써 자금 사정이 좋지 않은 현재의 상황을 빨리 반전시키기를 원한다. 그런데 그 훌륭한 개발자는 너무 완벽한 제품을 처음부터 만드려는 통에 다양한 기반 아키텍처를 만들었다가 부수기를 반복하고 정작 중요한 빠른 제품 완성 일자를 요원하게 만들었던 것이다.
훌륭한 개발자일수록 자기만의 고집에 사로잡혀있는 경우가 많다. 몇년 전에 나는 모 은행에서 진행 중인 프로젝트에 잠깐 참여한 적이 있었다. 내가 참여한 이유는 현재 개발중인 사이트에 장애가 발생하고 심각한 성능저하 현상이 있었기 때문이었다. 내가 JVM 상태를 분석해보니 이것은 운영상황을 고려하지 않은 개발자의 소스코드 때문이었다(사실 거의 대부분의 문제는 개발자의 잘못 짠 소스코드인 경우이다). 하지만 수석 개발자는 핏대를 세워가며 절대로 자기의 잘못일 리가 없다며 호응을 하지 않았다. 우여곡절 끝에 문제의 원인을 스스로 인정할 수 밖에 없게 만들었지만 그때를 생각하면 개발자의 고집이란 게 얼마나 무서운가 다시 한번 생각하게 한다. 사실 이러한 훌륭한 개발자의 고집을 접하는 것은 나의 경우 매우 드문 편이다. 개발자가 아무리 훌륭해도 그들이 보지 못하는 이면은 얼마든지 다양하고 귀를 열어둘 필요가 있다.
여기서 언급하고 있는 개발자들은 멍청한 개발자를 말하는 것은 아니다. 나름대로 개발자의 길에 자긍심을 갖고 있으며 장인정신을 가지고 있는 이들을 말하는 것이다. 이러한 훌륭한 개발자가 멍청한 개발자 10명보다 훨씬 기업에 좋은 이득을 주는 것은 부인할 수 없다. 하지만 그럼에도 불구하고 그들이 CIO나 매니저에게 인정받지 못하는 이유는 무엇인지, 그것에 대해 고민해볼 수 있을 것 같다.
너무 개발자 핀잔만 늘어놓은 것 같아서 멍청한 CIO 및 매니저로 인해 고생하는 개발자들을 위한 재밌는 동영상 하나 올린다.
최근 덧글