Thoughts2011.06.29 09:25
클라우드 개발자가 각광받고 있다는군요. 연봉이 20%~30% 정도는 뛰었고 팀장급은 아예 '부르는 게 값'일 정도라는데. 그런데 대관절 '클라우드 개발자'는 뭘까요?

1. 클라우드와 연동하는 앱 개발자

'연동가능한' 클라우드는 대부분 API가 있습니다. 이런 API를 제공하는 클라우드와의 연동은 웹 매쉬업 서비스를 개발하는 거나 마찬가지 수준입니다. 개발경험이 time to market을 낮추는데 기여할 수 있다는 이해하겠는데 20~30%나 연봉이 뛰어야 할 뭔가가 있는 건지는 알쏭달쏭한 영역. 하지만 여기까지 경험이 있다면 어차피 개발자들 연봉은 낮은 상태이므로 당연히 올려줘야 한다는 생각이 들기도. ㅎ



2. 클라우드 상에서 돌아가는 computing software 개발자

가령 구글의 Map-Reduce 모델 같은걸 사용해서 클라우드 computing resource 위에서 뭔가 대규모 데이터처리 어플리케이션 같은걸 개발해 보는 분들이 이 영역에 속하겠습니다. 종전의 GRID 컴퓨팅 하던 분들이 대거 이쪽으로 옮겨가는 통에 최근 각광받고 있는 듯. 그런데 이런 부분의 경험이 있는 개발자들은 (1) 학교에 계시거나 (2) 데이터센터를 보유한 대형 포털에 주로 몰려 계실 듯. 이 정도면 20~30% 정도 이상의 연봉 상승은 당연할 것 같고, 더 올려줘도 상관은 없을 듯.



3. 클라우드 플랫폼 소프트웨어 개발자

야후의 Hadoop이나 아마존의 Dynamo (Cassandra) 같은 소프트웨어를 개발하시는 분들이 여기에 해당. 이런 분야의 경력자라면 사실 100% 상승 정도는 당연하다고 봐도 아깝지 않을 정도의 초 고급 개발자로, 돈을 얼마 준다고 해도 아깝지 않을 정도의 희귀 인력.

4. 기타 영역

  • HIVE 같은 프로젝트를 이용해서 NOSQL DBMS에 SQL 인터페이스를 붙여봤다거나
  • Cassandra 같은 NoSQL 데이터베이스를 깔아서 데이터 처리에 응용해봤다거나
  • Google App Engine을 통해서 서비스하는 웹 기반 응용을 완벽하게 한번 만들어 봤다거나
  • 클라우드 기반의 인프라 서비스를 활용해서 뭔가를 만들어 봤다거나

이런 기술에 대한 경험이 있다면 20~30% 이상의 연봉향상을 기대하는 것이 타당할지도 모르겠군요. 어차피 돈이라는 것은 수요에 따라 변동하게 마련이니까요. 관련분야에서 석박사학위를 취득했거나 자격증이 있으면 좀 더 나을 수도 있겠습니다. 그런 경우에는 20~30% 보다 더 올려서 받을 수도 있겠죠. Hadoop Training을 받아서 Cloudera Certification을 취득하는 분도 있던데, 관심 있는 개발자라면 한번 시도해 볼 수도 있겠습니다.

개발자에 대한 요구가 늘어나고 개발자의 연봉이 늘어나는 건 좋은 일이지만, 한편으로는 현재 IT 업체들이 '굉장히 근시안적으로 사람을 뽑는' 경향이 드러난 것 같아서 씁쓸합니다. 사람을 뽑아서 문제를 해결하려고 하면 언제까지나 돌려막기가 될 수 밖에 없습니다. 쓸만한 사람을 뽑아서 미래를 보고 내부적으로 키워 인재로 만드는 것이 아니라, 이미 검증된 사람을 뽑아 일단 급한불을 끄겠다는 식으로 뭔가를 하면 그런 일은 급조된 농구팀으로 우승을 해 보겠다는 식의 이야기밖에 되질 않는 것 같네요.

인재로 만들어 놓으니 다른 데로 가버린다구요? 그럼 그건 '인재'로서의 대우를 제대로 안해줬다는 이야기겠죠. '인간적인 면'에 너무 기대시면, 나중에 더 큰 리스크가 다가옵니다. 요즘 같은 세상에선요.

Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 댓글 보고 왔습니다. 사실 너무 놀랐습니다.

    열심히 사는 모습 살짝 엿보고 갑니다. 페이스북 친구와 블로그 북마크도 하고 갑니다.

    행복한 하루되세요. 저는 늘 똑같습니다. 세팍타크로 라이프 포에버~~~

    2011.06.29 21:40 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 재미있게 잘 보았습니다. 좋은 하루 되십시오.

    2011.06.30 10:48 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2009.09.22 10:28

얼마 전에 코드 공동 관리에 대한 재미있는 외국 사례를 하나 들었습니다.

코드를 관리하다보면 항상 골치가 아픈 부분 중에 하나가 코멘트(comment)입니다. 즉 주석 관리를 어떻게 하느냐 하는 것인데요.

이 회사 직원들은 개발을 몇 줄 혹은 얼마나 했느냐에 따라서도 포상을 받지만, 주석을 얼마나 정확히 달았느냐, 얼마나 많이 달았느냐에 따라서도 포상을 받습니다.

함수의 사용 방법을 적는 것은 물론이고, 함수를 호출하는 함수의 목록, 함수 호출 결과로 발생하는 side-effect의 목록, 함수 호출 시 발생할 수 있는 예외 상황, 그리고 함수에 전달되는 인자의 의미 등등을 전부 적습니다. 그러다 보면 주석문의 길이가 길어집니다. 이 회사 직원들은 주석도 평가와 포상의 대상이 된다는 사실을 알기 때문에, 아주 적은 양의 코드에도 아주 자세한 주석을 답니다.

그리고 주석과 실제 코드에 불일치를 발견한 사람에게는 가산점을 줍니다. 종종 주석이 제대로 업데이트 되지 않아 문제가 되는 경우를 많이 보게 되는데, 그런 문제를 포상체계를 통해 해소하고자 하는 것이죠.

주석을 포상과 직접적으로 연결한다는 아이디어는 얼핏 생각하면 좀 졸렬하기도 합니다만, 직원의 적극적인 참여를 이끌어 낼 수 있다는 점에서는 긍정적으로 생각됩니다.

이 이야기를 다른 사람들하고 좀 했더니, 주석 라인수를 생산성 기여도에 그렇게까지 많이 반영하는 것은 무리가 있지만, 가중치와 결합된 마일리지 체계를 도입해서 포상을 하면 긍정적일 수 있겠다는 데는 모두들 동의를 하더군요.

문서와 코드의 일치는, 언제나 문제가 되면서도 좀처럼 해결이 되지 않는 부분입니다. 이런 부분을 해결하기 위한 바람직한 방법을 항상 고민할 필요가 있다고 생각합니다.

Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 재밌네요. 혹시 정확한 출처를 알 수 있을까요?

    2009.09.22 13:53 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 정동인

    안녕하세요. 블로그 잘 보고 있습니다.
    주석을 잘 다는게 코드를 잘 짜는거라고 배웠다가, 또 어딘가에서는 (어디서였는지 기억은 안나네요)
    주석이 필요 없는 코드를 짜라 (의미가 분명한 코드를 짜라는 거겠죠?)고 해서
    그렇게 믿고 주석을 최대한 안달려고 애쓰고 있는데,
    주석을 최소한으로 다는 것과 최대한으로 다는 것은 이상과 현실의 차이일까요? 아니면 케이스에 따라 다르게 생각해야 하는 걸까요?
    항상 막연하게 궁금해 했던 문제인데, 포스트를 보고 질문드려 봅니다.

    2009.09.23 09:27 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 저는 어떻게 생각하냐면... 주석은 문서의 일부라고 생각합니다. 실제로 많은 분들이 주석에서 생성된 Javadoc을 보고 코딩하고 있구요. 문서와 코드 간의 불일치는 반드시 해소되어야 합니다. 그리고 문서는 코드의 현 상태를 반드시 반영해야 합니다. 저는 Java SE의 Javadoc 다큐먼트가 모든 프로젝트 결과물 문서가 갖추어야 할 이상적인 모습이라고 생각합니다. 특히 코드를 보여주면 안되면서도 그 사용자가 우아하게 통합할 수 있는 라이브러리를 디자인하는 경우에는요.

      협업을 통해 프로그램을 개발하는 경우에는 주석보다는 '의미가 분명한 코드'가 더 효과적일 수 있습니다. 하지만 개발 결과물을 배포하는 시점에서는 좀 다르게 생각해 봐야 한다는 뜻입니다.

      2009.09.23 10:30 신고 [ ADDR : EDIT/ DEL ]
  3. 정동인

    답변 고맙습니다^^

    2009.09.23 10:57 신고 [ ADDR : EDIT/ DEL : REPLY ]
  4. 주석이 중요하단점을 근례에 들어서 많이 느끼고 있습니다..
    예를들어 한참전에 만든 코드를 다시 확인하려는데 이해못하는경우와, 다른이의 코드를 분석하는데 주석이 없어서 이해하는데 시간이 걸리는경우...
    전자의 경우 이전에 자신이 직접 만들어서 스타일이 확바뀌지 않는이상 이해하는데 어려움은 없습니다만,
    후자는 예기가 달라지는거죠

    2009.12.21 12:38 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2009.06.16 17:42

개발자는 어떻게 성장하는 걸까요? 대략 주변에서 보고 들은 걸 종합해 보자면...

1. 프로그래밍 언어의 시기

프로그래밍 언어를 죽자고 배우는 시기. 아직 매뉴얼이나 참고서 없이는 한 줄의 코드 짜기가 버겁다.

2. 초보 개발자의 시기

프로그래밍 언어 한 두개를 능숙하게 쓸 줄 아는 시기. 매뉴얼이나 참고서도 구글로 대신하는 수준. 하지만 본인이 제대로 된 코드를 작성하고 있는지는 장담을 못한다

3. 중급 개발자의 시기

진정한 개발이 무엇인지를 고민하는 시기. 왜 프로젝트 막바지에 더 바쁜지를 고민한다거나, 어떻게 하면 버그의 수를 획기적으로 줄일 수 있을지를 고민한다거나, 가장 최적의 클래스 설계는 어떤 모습일지를 고민한다거나 하는 개발자가 이에 해당. 그에 따라 읽는 책도 많아진다. 어떤 한 가지 믿음에 경도되기 쉬운 시기이기도 하다. 이 시기의 개발자가 가장 꼬장꼬장하다. 하지만 아직도 performance profiling에는 게으르다.

4. 고급 개발자의 시기

남을 가르치거나 홀릴 줄 알게 된 시기. 문제가 주어지면 기존 해법을 Survey하고 좀 더 나은 해결책이 무엇일지를 고민할 줄 알게 된 시기. 필드에서 자주 발견하는 문제에 대해서는 꿰고 있는 해결책도 두어가지 되는 수준. 버그가 나타나면 디버거 대신 머리를 굴려 발견하는 경지이나, 정작 코딩을 하는 시간은 점점 줄어든다. 어떻게 하면 좀 더 적은 코드로 좀 더 많은 일을 할 수 있을지를 항상 고민한다. 테스트와 코딩, 그리고 결과물의 배치 문제 뿐 만 아니라 최적화의 문제에도 항상 관심을 갖는다. 프로그래밍 언어는 이제 더 이상 주된 관심사가 아니다. 가끔은 그토록 찾아 해메던 문제의 답을 먼지를 뒤집어쓴 대학 교재 안에서 발견하고는 절망하기도 한다. 그 책의 이름은...

5. 초고급 개발자의 시기 (추가)

이 쯤 되면 이 개발자는 (1) 자기 회사를 차렸거나 (2) 끝내주는 회사에 다니고 있거나 (3) 책을 썼거나 (4) 좋은 논문을 썼거나 (5) 멋진 공개 소프트웨어를 작성했거나... 어쨌든 '세상에 뭔가 보탬이 되는 일'을 하고 있다. 고급 개발자와 초고급 개발자를 나누는 가장 결정적인 기준은, 좀 어이 없긴 하지만, 바로 그것이다. '세상에 뭔가 보탬이 되는 일을 하고 있느냐' 하는 것. 고급 개발자들은 먹고 살기 위해 코딩을 하지만, 초고급 개발자들은 세상을 보다 낫게 바꾸기 위해 코딩을 한다. 그렇기 때문에 그들이 하는 코딩은 본질적으로 자발적이며, 그들 내면의 충동으로부터 발원하는 것이다. 이런 사람들이 모이는 회사라면 분명 끝내주는 회사일 것이고, 이런 사람이 차린 회사라면 설사 성공하진 못하더라도 끝내주는 회사일 것이다. 이런 사람들이 만드는 SW나 논문도, 분명 끝내 줄 것이다.

보통 우리는 이런 사람들의 의식 깊은 곳에 자리한, 그들의 개발을 추동하는 내적 원리를
'프로그래밍의 도'라고 부른다.

프로그래밍의 도를 깨칠수 없다고 할지라도 절망하지는 말자.
세상의 모든 도는 그 본류가 하나로 이어져 있다.
세상에 좋은 일을 할 수 있는 기회는 의외로 다양하다는 뜻.
프로그래밍이 버겁게 느껴지고 때로 망망대해같은 코드의 심연에서 외로움을 느낀다면,
지금 당장 자선단체의 번호를 눌러 단돈 만원이라도 기부를 하도록 하자.
그 작은 행위가 여러분의 프로그래밍에 기쁨을 되찾아 줄 것이다.

좋은 프로그래머가 되면, 초고급 개발자가 될 확률도 덩달아 높아진다.

- - -

몇 줄 요약:

개발자의 경력이 늘어가면 갈수록, 개발자는 코딩 그 자체에서는 자유로와진다.
정작 중요한 것은 코딩이 아니라 Domain Knowledge라는 사실을 깨닫는다.
그러면서 '자신을 키운 것은 99%가 삽질'이었다는 사실을 서서히 잊는다.
왜냐하면, 이미 그는 삽질과 하나가 되었기 때문이다.

여러분은 지금 어디에?

Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 재미있습니다 ^^

    2009.06.16 20:48 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 전 2번과 1번 중간 사이에 있는듯... 삽질좀 해봐야 아 코딩이란 이거구나! 하는거죠 ㅋㅋㅋ

    2009.06.18 16:50 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. SubiLee

    경지에 다다르셨기 때문에 글을 적으실 수 있으셨겠죠?? ^^ 전 언제 고급이 되려나 하하

    열심히 노력하고 있습니다!

    2009.06.19 10:48 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그런건 아닙니다. 프로그래밍을 하면 할 수록, '프로그래밍 전문가'가 되는 것이 애초의 제 목표는 아니지 않았을까 하는 생각이 들더군요.

      프로그래밍은 도구입니다. 사진기가 사진을 찍는 도구이듯, 프로그래밍은 SW를 만드는 도구입니다. 사진기가 몸에 익어 자기 수족처럼 부릴 수 있기 전에는 좋은 사진을 얻기가 어렵습니다. 프로그래밍에도 비슷한 구석이 있어서, 프로그래밍이 손에 익어 사고 체계의 일부분이 되기 전에는 기한 내에 좋은 SW를 만들어 내기 어렵습니다.

      제가 하고 싶은 이야기는, 삽질은 결국 도구를 몸에 익히는 과정이고, 우리가 지향해야 할 것은 삽질 너머에 있다는 이야기입니다.

      그래서 Domain Knowledge가 중요하다는 것이구요. ^^

      2009.06.19 21:57 신고 [ ADDR : EDIT/ DEL ]
  4. 삽질과 하나가 되었다. 멋진 말입니다. 나를 키운 건 팔할이 삽질이다.

    2009.06.19 11:05 신고 [ ADDR : EDIT/ DEL : REPLY ]
  5. 삽질과 하나된다는말이 참 와닿습니다 ㅎㅎㅎ

    2009.06.23 00:37 신고 [ ADDR : EDIT/ DEL : REPLY ]
  6. duru

    이 표현 쥑이네요..
    남을 홀릴 줄 알게 된 시기..

    이 표현대로라면 초고급 개발자는
    굳이 홀리려고 하지 않아도 많은 사람들이 굳이(?) 홀리는 시기...

    세상만사, any domain, 다 똑 같은 거 같습니다.
    연애를 이렇게 해봤으면,,, 갑자기 내 안의 새디스트지랄로지가 발작을...ㅋㅋ

    2009.07.14 16:25 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2008.10.28 17:15
퍼다 나르는건 별로 좋아하지 않습니다만, 다같이 생각해봤음 하는 문제를 잘 보여주는 것 같아서 올려봅니다. 데브피아에 올라온 글 전문입니다.

제목은 "서울특별시의회 전자회의시스템 프로젝트 프로그램 개발자 폭행사건"입니다.


이 글을 올리게 된것이 너무 힘들다...대한민국의 개발자들에게 알리고 싶댜.



사건일시: 2008년 10월 23일 12시10분경

사건내용

 

2008년 서울시의회 176회 2차 본회의가 있는 날이다. 이 글의 개발자는 폭행 당한 개발자 당사자이다.

개발자는 평소대로 개발실에서 대기하고 있었다. 12시경 전화가 울렸다. 김* 주임이 의사과장이 의장용 프로그램의 버튼 인식 방식을 변경하라고 했다는 것이다. 즉 버튼을 눌렸을 경우 바로 다음 시나리오로 진행하는 것과 시간을 조금 빨리 변경해 달라는 것이다. 프로그램을 수정하기엔 본회의가 열리기 2시간 전이라 위험하고 테스트 시간이 부족하였다. PM에게 전달하니. PM이 김* 주임에게 시간이 부족하고 위험하니 혹시 발생할 위험성에 대한 책임으로 문서로 처리하여 주면 프로그램을 수정하여 주겠다고 전했다. 이에 의사팀장이 PM을 잠깐 만나자는 연락이 왔었지만 PM이 자리에 없었다. PM이 자리에 와서 의사팀장이 만나자는 내용을 전달 했다. 이때 본회의장 시나리오 담당자에게 연락이 왔다. 잠깐 내려오라는 것이다. 개발자는 혹시 다른 지원할 것이 있는 것으로 인식하고 내려갔다. 본회의장에 내려가니 의사과장은 의장 프로그램을 보고 있고 의사과 직원들15명 이상이 의원석에 앉아 있었다. 시나리오 담당자는 예전에 얘기된 의장프로그램 폰트 사이즈 크기가 왜 수정되지 않은 지 의사과장에게 다시 설명 해 달라는 것이다. 순간 의사팀장이 들어 왔다.

누가 하지 말랬어? 하고 개발자에게 물었다. 개발자는 순간 아무런 얘기는 하지 못했다.

그때부터 폭행은 시작되었다.

구두발로 개발자의 무릎을 두번 차고 다음 복부를 발로 차고 옆구리를 돌려차기 하였다. 아무도 말리는 사람 없었다. 잠시 후 누군가가 와서 의사팀장을 말렸다.

개발자는 너무 황당하여 아무런 대항도 하지 않고 본회의장에서 나왔다.

의사과장은 그냥 지켜보고만 있었다. 개발자가 폭행은 당하고 있는 데로 당연하듯 쳐다보고만 있었다. 그 많은 의사과 직원들(남직원4명이상,여직원 10명이상)이 보고 있는 가운데 폭행을 당했다.

개발자는 바로 개발실로 올라가 PM에게 현재 상황을 전달하였다. PM은 어떻게 이런 경우가 있냐며 개발자를 본회의장으로 데려 갔다. 의사과장은 단상 앞에 있었다. PM이 얘기 했다. 어떻게 개발자를 폭행 할 수 있냐고, 이때 의사팀장이 나왔다. 싸우겠다는 태도처럼 PM앞으로 나오자 다른 직원 두 사람을 말렸다. 의사과장 왈 지시대로 했으면 이런 일은 없을 거냐며 얘기했다. 즉 이 모든 폭행사실을 보고 있었던 것이다.

본회의장을 나왔다. 다른 의사과 직원과 팀장들이 같이 나왔다. 참아달라고 했다. 너무 억울했다. 112에 신고 하였다. 경찰 2명이 왔다. 본회의장에 들어 가려고 하니. 의사과 * 팀장이 말렸다. 경찰이 못 들어 갈 일이 없다고 하였다. 3번 이상 경찰과 실갱이 벌였다. 경찰이 본회의장에 들어갔지만 폭행한 팀장이 없었다. 다른 팀장에게 사무실로 가자고 하였다.

폭행한 팀장은 사무실에 있었다. 다른 직원들은 점심시간이 되어 본회의가 열릴 때 시켜먹는 도시락을 먹고 있었다.

경찰이 팀장을 불러 사무실을 밖으로 나왔다. 이때 남직원들이 같이 나왔다. 경찰이 현행범으로 체포한다고 하자 옆에 팀장들이 오늘 본회의가 있으니 본회의 끝나고 진해하면 않되겠나며 얘기했다. 개발자는 어이없다. 그 많은 사람들 앞에서 맞은 것도 억울 한데.

경찰이 내 의사를 물었다. 일단 개발자는 양보했다. 본회의 끝나면 이 폭행사건을 고소하겠다고 했다. 경찰은 물러갔다.

개발실로 갔다. 너무 황당하고 당황스럽다.

 

여기까지 2008년 10월23일 서울시의회 프로그램 개발자 폭행사건의 내용이다.

글을 쓰고 있지만 아직도 다리와 복부쪽이 통증이 심하다.

신체적 아픔은 참을 수 있지만 정신적 충격은

 

개발경력 8년이상 지금과 같은 경우는 처음이다.

이에 이 비통한 사실을 IT강국이라는 대한민국 현실을 전 세계에 알리고 싶다.

 

현재 서울시의회에서 의원들이 사용하는 프로그램이 개발자의 땀과 노력이 아닌 폭행으로 흘려진 개발자의 피와 얼룩진 시퍼런 멍으로 만든 프로그램이란 것을 꼭 알리고 싶다

Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 지성공자

    그 색히 누구야?
    감히 개발자를 때려~~ ? 이게 미쳤나?

    2008.10.29 09:33 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 개발자를 때린게 문제라고 보긴 힘들구요. 갑의 관계에 있는 사람이 을의 관계에 있는 사람에게 신체적인 위해를 가했다는 게 문제인 것 같습니다. 계약상 갑의 관계에 있다는 것이 을에 속하는 사람들을 노예처럼 부려도 된다는 뜻은 아니거든요. 우리 정치판에 계신 분들이나, 적어도 정치판 주변에서 밥을 먹고 사는 사람들의 의식수준이 요정도임을 잘 보여주는 사례인듯 해서 퍼와 봤습니다.

      2008.10.29 11:19 신고 [ ADDR : EDIT/ DEL ]
  2. 아자!

    썅..내가 그래서 지금 복싱을 배우거 있는거다...
    걸리면 뒤졌어!!

    2011.08.31 13:23 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 내일의석

    의사과 세끼 어떤 쓰레기인지 얼굴 함 보고싶네요.. ㅋㅋ

    2012.07.26 12:50 신고 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/General2008.02.06 12:46
오늘 이 글을 보다가 든 생각입니다만, 좋은 개발자가 되려면, 아무래도 인간성이 좋아야 할 것 같아요. (사실 이 비슷한 생각을 한 지는 오래 되었습니다.) 왜 이런 말을 하냐 하면, 적어도 국내에서는 다음의 두 가지 가정이 유효하기 때문입니다.

1. 개발자에게 주어지는 환경이 아주 척박하다
2. 혼자서 모든 개발을 다 해내는 것은 어려운 일이다.

우리나라의 SW 개발 환경이 외국에 비해 그다지 좋지 못하다는 이야기는 나온지 꽤 오래된 이야기입니다. 대부분의 개발 프로젝트는 일정 중심적(date-driven)인 프로젝트이고, 개발을 진행하다보면 요구사항(requirements)도 시도 때도 없이 변화합니다. 다른 프로그래머들과 맞춰야 하는 인터페이스는 한두가지가 아니고, 그러다보면 가끔 굉장히 비생산적인 논쟁에 빠지게 되는 일도 허다합니다.

그런데 이런 비-프로그래머 중심적인 환경에서도 빛나는 프로그래머들이 있습니다. Guru는 아닐지라도, 다른 사람의 가치를 내 가치처럼 중요하게 여기고, 내 편의를 위해 다른 사람의 불편함을 강요하지 않으며, 섣불리 다른 사람의 능력을 폄하하지 않는, 그런 프로그래머들 말입니다.

통계적으로 보면 (어디까지나 제 주관적인 통계에 의한 것이긴 합니다만) 그런 프로그래머들일 수록 신기술을 습득하는 데 주저하지 않고, 맘에 들지 않는 기술이라고 해서 자기 잣대로 폄하하지 않으며, 다른 사람들과의 관계를 원만히 이끌어 갑니다. 남들이 귀찮아하는 TDD도 솔선수범하는 경향이 있고, 문제가 생기면 언제나 자기가 맡은 부분을 주저없이 의심하는 자세를 보여주죠.

하지만 개발 환경이 척박해질 수록, 이런 개발자들도 함께 드물어진다는 것은 서글픈 일입니다. 이런 개발자들이 점차로 드물어진다는 것은, 소프트웨어 기술자들을 계속하여 재생산해 낼 책무를 지는 개발집단들이 개발자들에게 바람직한 역할 모델을 보여주지 못한다는 뜻이기도 합니다.

그런 역할 모델을 보여주지 못하는 이유로는 여러가지가 있겠습니다만, 가장 큰 것으로는 "개발 집단의 상당수가 개발 방법론을 잘 모른다"는 것을 꼽을 수 있겠습니다.

startup 회사부터 좀 잘 나가는 회사까지 여러 회사를 접해보았습니다만, 폭포수적인 개발방법론이나마 꾸준히 적용해보려는 의지를 가진 회사도 드물었고, 일의 양을 정확하게 추정해 보려는 시도를 하는 회사는 더더욱 드물었습니다. 잘못된 추정으로 시작하더라도 중간 중간에 그것을 바로잡을 기회는 자주 주어집니다만, 그 기회를 제대로 이용하는 회사도 드물었어요.

보통은 "야근-대책없는 휴식-야근-대책없는 휴식-야근-대책없는 휴식..."을 소프트웨어를 릴리즈하는 그날까지 반복하죠. 회의시간은 보통 "지시사항 전달"로 변질되고, 개발자들은 요구사항을 내놓은 사람들과 대면하고 요구사항을 이해할 기회조차 갖지 못합니다. 결국 잘 만들어놓으면 "그게 아니었어..."가 되니까 다시 야근을 하게 되구요. 이런 상황에서라면 아무리 인간성이 좋은 개발자라도 종국에는 인간성이 더러워지지 않을까요?

소프트웨어 개발도 남과 더불어 하는 일이니까, 결국 사람과의 인간관계가 가장 중요하기 마련인데, 그 관계를 차단한 다음 닭장에 밀어넣어 놓고는 "니가 할 일만 잘 하면 돼!"라고 하는 꼴이죠. 결국은 나중에 가서 "왜 내 말을 제대로 이해하지 못한거야!"라고 할거면서 말이에요. :-P

이런 억지스러운 환경을 개선하려면 어떻게 해야 할까요? 저는 요즘 그 답을 찾기 위해 애쓰는 중입니다.




Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 자네도

    개발자가 잘못된게 아니라 중간관리자 및 경영진이 잘못하고 있습니다.
    더 골(The goal)이라는 소설만 읽어도 이정도는 아니겠다는 생각이 듭니다.

    2008.02.08 12:57 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 네. 개발자가 잘못되었다는 이야기는 한적이 없구요. ㅋㅋ 중간관리자 및 경영진을 포함하는 많은 사람들이 이런 상황을 개선하기 위해 공부를 좀 해야할것 같습니다.

      2008.02.08 17:31 신고 [ ADDR : EDIT/ DEL ]