실용주의이야기(Pragmatic Story)

경쟁력은 회사 크기가 아니라 직원 수준에서 나온다.

k16wire — Sat, 13 Mar 2010 10:17:48 +0900

얼마전 전규현님의 블로그에서 삼성이 소프트웨어 분야에서 최고가 되려면이라는 글을 읽었습니다. 이 글은 아이폰이 등장하면서 불거진 옴니아폰의 소프트웨어 품질 문제에서 시작했습니다. 삼성이 소프트웨어 경쟁력을 살리는 길은 외국 소프트웨어 업체를 인수해서 지금과 다른 방식으로 관리하는 길 뿐이다라는게 글의 주요 논지입니다. 이 논리를 인정하지만, 해당기업 개발자라면 참 자존심 상하는 이야기 입니다.

모바일이 요즘 대세입니다. 하지만 SI(System Integration)도 한국 소프트웨어 산업구조의 많은 부분을 차지합니다. SI 현실 참 열악합니다. 과도한 야근때문에 몸이 상해서 건강을 잃어버린 어느 IT 근로자의 절규가 인터넷을 떠돌지만 이분이 산재로 인정받을 수 있을까요.

SI를 하는 기업에서는 개발자가 개발자답게 살 수 없는 걸까요?

현재 상황에서 개발자들이 좋은 소프트웨어를 만들수 있게 하는 방법을 고민해 봤습니다.

첫째, 개발자를 존중해야 합니다. 얼마전 Harvard Business Review에서 How to Keep Good Employees in Bad company라는 글을 읽었습니다. 좋은 소프트웨어가 나오려면 좋은 엔지니어들이 많아야 합니다. 그럴려면 위 글에서 말하는 것처럼 개발자들을 존중하는 것부터 시작해야 합니다. 높은 기술역량과 좋은 문화를 가진 소프트웨어 기업을 하루 아침에 만들 수 없습니다. 고액 연봉과 좋은 조건이 전부가 아닙니다.

둘째, 교육이나 학습을 통해 역량을 키울수 있는 기회를 줘야 합니다. 개발자들은 야근때문에 공부할 시간 아니 딴 생각 할 시간도 없습니다. (딴 생각할 시간준면 개발자 안할까봐 그런지도 모르겠습니다. ^^) 프로젝트 들어가면 교육이나 휴가는 꿈도 못꿉니다. 하지만 전 정말 알면서도 신기한게 어떻게 몇달씩 진행되는 프로젝트에서 개발자가 일주일 교육간다고 진행이 안될수 있나요. 교육 못간 개발자는 불만만 쌓일텐데..차라리 화끈하게 보내주고, 교육 받고 오면 같이 열심히 해보자고 말할 수는 없는걸까요. 고객이 못가게 한다고 하는데..그런것도 논리적으로 설득 못하면서 관리자는 왜 있는건지 모르겠습니다.

저는 이 두 가지에서부터 시작해야 한다고 생각합니다. 기존 개발자를 우대하고 수준높은 교육을 체계적으로 진행하면서 문화를 바꿔 간다면 경쟁력 있는 소프트웨어는 자연스럽게 나올거라 생각합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

독도는 대한민국 40년 통한의 역사

k16wire — Thu, 11 Mar 2010 09:43:16 +0900

도아님의 블로그에서 보고 너무나 감동을 받아서 옮겨 봅니다. 독도에 대한 우리의 대응이 이렇게만 되면 여한이 없을것 같습니다. 영작 잘하시는 분은 영어자막 넣어주심 어떨까 합니다.
(제가 하고 싶지만 명연설 망칠까봐..쩝..)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

개발자가 될것인가 vs 월급도둑이 될것인가

k16wire — Wed, 10 Mar 2010 23:36:50 +0900

3월은 바야흐로 연봉계약의 시즌입니다. 국내 다른 대기업처럼 제가 적을 두고 있는 회사도 연봉제를 시행하고 있습니다. 연봉싸인을 앞두고 팀장님과 면담을 하면서 문득 이런 생각이 들었습니다.

나는 왜 이 회사를 다니고 있는가?

저는 이 질문에 이렇게 답을 하곤 했습니다. '이 회사에는 아직 배울게 많이 남아있다.' 시간이 흐르면서 이 대답이 의미를 잃어가는것 같습니다.

몇년전의 일을 떠올려 봤습니다. 회사라는 울타리를 벗어나 외부 사람들과 만나기 시작하면서 버릇처럼 회사 이름을 이야기 하지 않았습니다. 회사가 창피했던건 아니었지만 회사이름을 밝히면 이구동성으로 나오는 말이 '왜 거기 계세요? 거기 계실분 같지 않아 보이는데.' ^^;

대기업 10년차 개발자 쯤 되면 파워포인트와 엑셀을 개발도구처럼 자유자재로 다루게 됩니다. 저는 이런 상황을 '필요악'이라고 부릅니다. 중간 관리자로서 윗사람의 시각에 맞춰서 엔지니어링의 가치를 보여주자면 문서작업은 어쩔 수 없습니다. 이런 상황을 인정은 하면서 매번 회의가 드는 건 어쩔 수 없습니다.

나는 개발자인가? 엔지니어인가?

포스코에서 2010년에는 신입사원을 모두 인턴으로 뽑겠다고 발표했습니다. 이 기사를 보면서 동료 책임님이 했던 말이 생각났습니다. "신입사원 연봉이 OO이어서 불만이면 나가서 다시 입사해서 들어와라. 들어올 자신 있냐? 없지 않냐" 입사이후 1,2년차는 연봉이 신입사원과 그리 차이가 많이 안나는것을 두고 했던 말입니다.

연봉액수나 고가평가가 회사를 다니는데 큰 의미가 되지 않은지 오래입니다. 많이 받으면 당연히 좋지만 그게 이 회사에 있는 주요 이유인가 하고 반문해 본다면 아닙니다.

어느 회사에 있는가는 중요하지 않다. 어떤 일을 하는가가 중요하다.

예 저는 제가 지금 하고 있는 일이 좋아서 회사에 남아 있습니다. 일을 하다보면 힘들때도 있고 스트레스를 받을 때도 있지만 그런 어려움 보다는 제가 진행하는 일에서 보람을 느끼는 순간이 아직은 더 많습니다. 그런 일에 좀 더 희망을 걸어 보려 합니다. 더 이상 그러지 못하고 생활에 안주하면서 월급도둑이 되면 그때가 회사를 나가야할 순간일거 같습니다.

~~저처럼 대기업에서~~ 개발자로 살아가면서 저와 같은 고민을 하시는 분들..연락주세요. 한잔하시죠. ^^;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

프로젝트가 망하기 전에 나타나는 징후

k16wire — Thu, 04 Mar 2010 12:39:28 +0900

흔히 이야기 하길 사람이 병에 걸리기 전까지 몸은 100가지 징후를 보인다고 합니다. 하지만 대부분 모르고 지나친다는게 문제입니다. 프로젝트도 망하기 전에 여러가지 징후를 보입니다.

서로 돕지 않습니다. 일이 많아서 바쁘다고 하면서도 6시가 좀 넘으면 퇴근 하는 사람들이 많이 보입니다. 사실 정시 퇴근이 잘못된건 아니죠 문제는 자기 할일이 끝났다고 그냥 가버리는 거죠.
업무를 제대로 배분할 줄 모릅니다. 신입사원에게 엄청 어려운 화면을 맡기고, 잘하는 사람에게 오히려 쉬운 화면을 맡깁니다. 이유는 있습니다. 잘하는 사람이 많은 화면을 개발하게 해야 한다. 일명 물량뽑기죠.
다른 사람 말에 귀를 기울이지 않습니다. 외부에서 도우러 와도 거들떠 보지 않습니다. 어떤 부분이 위험하다고 이야기 해도 듣지 않고, 회의중에도 나가 버립니다.
특정 개발자에게 일이 몰립니다. 진도가 나가지 않은 개발자의 일까지 모두 개발 잘하는 사람에게 몰아버립니다. 우직하게 열심히 개발하는 사람은 끝없이 일을 맡게 됩니다. 결국 오픈 후 발생하는 결함 수정도 모두 그사람의 일입니다. 아무리 사람이 많아도 그 사람 없으면 일이 안됩니다.
결국 개발하는 사람은 얼마 안됩니다. 프로젝트에 사람은 많은데도 대부분은 개발의 개자도 모르는 관리자 뿐이고 개발자는 얼마 안됩니다. 나중에 장애가 터지면 개발자에게 와서 하는 말은 똑같습니다. "다됐냐?" 뭘 어떻게 하라는 말은 못합니다.
어려운 일인지, 쉬운 일인지 판단을 못합니다. 어려운 기능인지 쉬운 기능인지 판단할 줄 아는 능력이 부족합니다. 한 화면에서 다루는 테이블이 20개가 넘고 입력 필드가 250개 가까이 되어도 PL은 한본으로 칠 뿐입니다.
업무를 적절한 사람에게 맡길줄 모릅니다. 데이터를 이행하는 업무를 맡기면서 업무설명은 하지 않습니다. 일하는 사람은 자기가 하는일이 제대로 한건지 아닌지 판단할 수 있는 능력이 없습니다.
알고 있는것도 안다고 말하지 않습니다. 괜히 말해봐야 자기 일만 늘어난다는 걸 알고 있습니다. 이슈가 생겨도 나서려고 하지 않고 해결책을 안다고 말하지 않습니다.
무용한 분석/설계 산출물을 만드느라 시간을 허비합니다. 분석/설계는 합니다. 하지만 무엇하나 확정된 것은 없습니다. 화면 하나 결정하지 못해 개발을 진행하면서도 계속 바꾸기 일쑤입니다.
개발자들이 개발하기 불편한 환경이란걸 인지 못합니다. 개발자들이 불편하다고 하는건 불편한 겁니다. 이런 말에 귀를 기울이지 않습니다. 그저 표준인지 관리하기 좋은지만 생각할 뿐..

꾸며낸 이야기라 생각하세요. 믿거나 말거나..:-)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Agile 2010 Conference에 도전하세요.

k16wire — Tue, 02 Mar 2010 12:30:26 +0900

애자일 관련 컨퍼런스는 크게 두개가 유명합니다. 그중 하나인 Agile 2010 컨퍼런스가 미국 내슈빌에서 열릴 예정입니다. 또 어떤 컨퍼런스가 있는지 궁금하신 분은 이전글을 참고하세요.

제가 이 컨퍼런스를 좋아하는 이유가 몇 가지 있는데, 그 중 하나가 바로 컨퍼런스 발표자를 선정하는 시스템입니다.

년초부터 일단 발표를 원하는 사람들로부터 Submission을 받습니다. 누구나 Submission을 제출할 수 있으며 다른 사람이 제출한 Submission은 어떤것이 있는지 열람도 가능합니다.
서로 코멘트를 할 수 있습니다. 이를 통해 의견을 주고 받고, 충고도 할 수 있습니다. 인기 있는 강연자의 Submission에는 '꼭 듣고 싶다.'등의 의견도 달립니다. (완전 부럽죠. ^^)
신청을 마감하고 나면 사전에 선정된 리뷰어들이 각 Submission별로 '리뷰'를 달아 줍니다. 개중에는 리뷰가 없는것도 나옵니다. (악플이 무플보다 낫다는게 실감나는 상황입니다.^^)
최종으로 각 Submission의 영역,유형 등이 선정됩니다. 이때 누구를 대상으로 하는 발표인지 정의된 참가자 페르소나에 맞춰 연관을 맺습니다.

발표자로 선정되면 여러가지 혜택이 있습니다. 발표시간에 따라 등록비 면제, 강연료 등이 지원되는데 최소 60분 이상 발표를 해야 이런 혜택이 있지 그 이하는 자비로 가야 합니다. :-)

컨퍼런스는 8월에 열립니다만 Submission은 2/28일자로 벌써 마감됐습니다. 900개 넘는 Proposal이 접수됐다고 합니다. 대단하네요.

작년에 저도 신청했다가 보기좋게 떨어졌죠. "다른 사람과 너의 발표가 무슨 차이가 있는지 모르겠다." 는 코멘트 하나 달랑 달리고 리뷰도 못받은채로..T_T 이번 해에도 신청은 했는데 잘 될지 모르겠습니다.

이런 결심을 하는데 첫번째 장벽은 영어입니다. 예 저도 영어 잘 못합니다. 그래도 하는 이유는 정말 중요한건 내용이지 형식이나 언어가 아니다라고 생각하기 때문입니다.

제가 이런 컨퍼런스에 발표자로 시도하는 이유는 제대로 된 커뮤니케이션을 해보고 싶어서 입니다. 사실 내돈내고 들으러 가는것은 누구나 할 수 있습니다. 하지만 많은 사람들이 모이는 이런 자리에 별다른 경력 없는 저같은 사람은 가봐야 뻘줌합니다. 네트워킹 이런거 잘 안됩니다. 영어도 짧고 말주변도 없고, 게다가 남자 사람아닙니까. ^^

하지만 어느세션에서 무슨 발표를 한다고 하면 다시 돌아봐 줍니다. 질문하면 받아주고 성실히 답변도 해줍니다. 그래봤냐구요? 외국 사람들이 그러는걸 봤죠. :-)

많은 분들이 이런 컨퍼런스에 도전했으면 하는 마음에서 정리해 봤습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.