실용주의이야기(Pragmatic Story)

개발자가 될것인가 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 대한민국 라이선스에 따라 이용하실 수 있습니다.

『야근제로 업무기술』

k16wire — Mon, 01 Mar 2010 23:25:42 +0900

연휴를 맞아서 오랜만에 서점에 갔습니다. 평소 읽고 싶은 책을 아이폰에 적어놓는 덕분에 이제는 서점가서 무슨 책을 볼지/살지 고민할 필요가 없습니다.

일본의 실용서 답게 책도 얇고 읽기 좋게 구성되어 있습니다. 개인적으로 일본 번역서는 깊이가 얇다는 생각이 들어서 가끔 실용서만 보는 편입니다.

이 책 야근제로 업무 기술은 저자인 요시코시 고이치로 사장이 10년간 자신의 회사에서 어떻게 야근을 근절해 나갔는지를 정리해 놓은 책입니다. 이 책에서 말하는 야근의 가장 큰 폐혜는 바로 이겁니다.

야근의 가장 큰 폐혜는 문제를 가시화해서 개선할 수 있는 기회를 빼앗는 다는데 있다.

문제의 본질을 해결하려 하기 보다는 농업적 근면성으로 꾸역꾸역 해결해 나가는 겁니다.(어디서 많이 들어본 이야기 같네요.) 일본과 우리나라는 근무 강도가 높기로 유명합니다. 평균 근무시간이 서구권에 비하면 상상을 초월합니다. 그렇기 때문에 아시아 기업이 발전해 나가는게 과연 맞는 걸까요?

같은 조건으로 싸워서 이겨야 진짜 이기는 것이다.

책에서 이야기 하는 야근제로를 위한 여러 방법을 7개 팁으로 정리해 봤습니다.

팁1: 마감시한으로 스피드와 집중도를 높인다.
팁2: 문제해결에 집중하라.
팁3: 마감 관리상자
팁4: 아침회의
팁5: 야근에 대한 반성의 시간을 갖자.
팁6: 업무를 개인단위로 세분화 하라.
팁7: 야근 금지 데이 깃발을 도입하라.

각 방법들을 읽어보면서 애자일에서 말하는 기법과 유사하다는 생각이 많이 들었습니다.
팁3: 마감 관리 상자는 GTD나 백로그에서 남은 작업시간을 관리하는 것과 유사해 보입니다.
팁4: 아침회의는 그냥 아침에 회의를 하는게 아닙니다.
        - 업무를 작게 쪼개고
        - 한개 안건을 처리하는데 걸리는 시간을 2분으로 제한하며
        - 회의를 정보 공유의 장으로 봅니다.

업무시작전에 하는거나 타임박싱을 이용하는것, 정보공유 측면에서 본다면 '일일 스크럼 미팅'과 비유할 수 있습니다.
팁2, 팁5는 과거를 반성하고 더 나은 방안을 찾아간다는 면에서 '회고'와 유사합니다.
팁6: 업무를 개인단위로 세분화하라는 의미는 중간에 인터럽트가 걸리면 업무효율이 떨어지니 미리 개인별로 업무를 잘 할당하라는 의미 입니다. 어느정도로? 다른 사람과 떨어져서 각자 자기방에서 일해도 업무가 가능할 정도로 해야 합니다. 백로그를 통해 각자 할일을 잘 정의해서 나누는 것과 유사하지 않나요.

굳히 연결고리를 찾으려 노력한건 아닙니다만 자연스레 그런게 보인걸 보면 애자일의 기법이나 원칙이 결국 일을 잘하고자 하는 고민에서 나왔기 때문이 아닐까 하는 생각을 해봤습니다.

야근을 없애기 위해서는 최고 경영자의 의지와 직원의 역량강화가 필요합니다. 무조건 야근을 하지말라고 한다고 되는게 아닙니다. 근무시간내에 업무를 끝낼 수 있는 환경이 조성되야 합니다. 과거 저희 회사가 7/4제를 도입했을때 갑자기 불을끄고 모두 나가라고 하니 나갔다가 나중에 다시 들어와서 일했다고 하던데요. 비슷한 일화가 책에도 나오네요.

끝으로 이 책은 이런 질문을 던집니다.

일하기 위해서 사는가, 살기 위해서 일하는가
(Life for work or Work for life)

고기도 먹어본 사람이 먹는다고 인생도 즐기기 위해서는 준비가 필요합니다. 즐거운 인생을 살기 위해 일하는 사람이 되어야 겠습니다.

사내에서 애자일을 통한 야근제로 운동이라도 벌여볼까 합니다. 그냥 하는것 보다 좀 더 먹히지 않을까요. 트위터에 #Yagndang 리스트가 있던데 #YagnZero 리스트 어떠세요? ^^

야근제로 업무기술
카테고리	자기계발
지은이	요시코시 고이치로 (프런티어, 2010년)
상세보기

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

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

모델링도 애자일로 해보자

k16wire — Fri, 26 Feb 2010 11:02:23 +0900

애자일쪽 이야기를 많이 하면서도 정작 설계에 대해서는 크게 고민 안했던거 같습니다. 그래서 이번에는 애자일 모델링에 대해 생각해 보려 합니다.

애자일 모델링 하면 나오는 첫번째 레퍼런스가 스캇 앰블러(Scott W. Ambler)가 쓴 agile modeling입니다. 대머리여서 발표할때 반짝반짝 빛나던(?) 모습의 스캇 앰블러가 생각납니다. Agile2009 마지막 날에 CSM의 유효성을 꼬집는 그의 세션을 들은 적 있습니다.

애자일 모델링의 근본을 이루는 원칙에는 다음과 같은 것들을 들 수 있습니다.

모델이 단순해지도록 합니다.
변화를 기꺼이 받아들입니다.
조금씩 추가해 나갑니다.
빠른 피드백을 받습니다.
모델은 목적이 있어야 합니다.
필요하면 여러개의 모델을 유지합니다.

이런 원칙에서 가장 중요한 것은 모델을 어떻게 표현하느냐 보다는 어떤 내용을 표현할 것인가(content is more important than representation)에 집중해야 한다는 것입니다.

아래 그림은 위 원칙을 기반으로 어떻게 애자일 모델링을 해야하는지 애자일 모델링의 전체 프로세스를 상위 수준에서 보여줍니다.

[AMDD, Agile Model Driven Development]

프로세스가 있으면 이 프로세스에 따라 실제 모델링 작업을 진행합니다. 이때 사용할 수 있는 기법들 입니다.

애자일 모델링에서는 여러 모델을 동시에 작업하면서 점진적으로 조금씩 키워 나갑니다. 그러면서 여러사람의 피드백을 받아서 확신을 가져야 합니다. 모델은 코드가 아니기 때문에 이 모델이 정말 맞는지 확신을 갖기 어렵습니다. 실제 코드를 짜보기 전까지는...

시간을 두고 공부해 볼 주제인거 같습니다.

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

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