안녕하세요~ 장선진입니다.

조금 일찍 찾아온 추위 덕분에 주변 산들이 울긋불긋한 단풍으로 아름답게 물들어가고 있습니다.
참고로 일교차가 많이 날수록 단풍의 색이 곱게 물들어 간다고 하네요~ 모든 일에는 동전의 양면처럼 장점과 단점이 모두 존재하는 것 같습니다.

최근 우리나라 소프트웨어 개발자의 노동시간에 관한 문제가 많이 부각되고 있는 것 같습니다.

안타까운 현실입니다. 사실 회사를 이끌고 있는 입장에 Start-up 기업인 저희 Software in Life 식구들 역시 많은 시간을 회사에서 보내고 있습니다. 조금 더 풍요로운 일상을 선물해주고 싶지만 아직 많은 부분이 갖추어있지 않은 회사라서 그렇지 못하네요~

다만 다른 기업에서는 할 수 없는 다양한 경험들을 하고 있습니다.
다들 상도 하나씩 받을 예정입니다. 재미있게 다양한 활동들을 하기에 이런 상도 하나씩 받게 되는 것 같습니다.

최근 개발자의 노동시간에 대한 이야기들이 많이 나오고 있는 것 같습니다.
저 역시 아내에게 많은 잔소리를 들어가며, 월화수목금금금 회사에서 개발을 해왔던 터라 그 고민이 무엇인지 잘 알고 있습니다.

다만 바라보는 시각의 차이가 많다는 생각을 하고 있습니다.

예전에 제가 대학교를 다닐때 방학때마다 공장에서 아르바이트를 하곤 하였습니다. 다른 일자리보다 많은 급여를 주었기 때문이죠~ 보통 인력파견업체를 통해서 일을 하곤 했는데, 학기중에도 급하면 저에게 연락을 하여 대타로 야간근무를 하곤 하였습니다.

가장 힘들게 일했던 것은 공장에서 프레스 머신으로 일정 간격으로 알류미늄 막대를 절단하는 작업도 해보았습니다.
프레스 머신이란게 까딱 잘못하면 손가락 절단과 같은 큰 사고가 일어날 수 있는 일이었는데, 같이 간 친구중에 하려고하는 친구가 없는 관계로 제가 했었습니다.

그때 정말 노동이란것이 얼마나 힘들다는 것을 많이 체험했습니다.
여러가지 위험을 감수하고 한시간에 딱 10분 휴식해가면서 프레스 앞에서 아무생각없이... 아니 손가락이 절단되지 않으려고 주의를 기울이면서 작업량을 채우기 위하여 열심히 프레스를 눌렀습니다.

노동자에게 노동시간이란것이 정말 보장되어야한다는 것도 많이 느꼈습니다.
공장이란 환경이 아무리 좋아도 여러분의 책상 주변보다 좋지는 않거든요.. 그런 여건 속에서 묵묵히 자신이 채워야 할 작업량을 채우고 있는 것은 정말 어려운 일입니다.

그렇기 때문에 잔업을 하면 당연히 작업 수당이란것도 나와야하고 특근을 하면 특근 수당이 나와야 합니다.
그리고 공장에서 느낀 것 중에 하나는 공장과 같은 작업 절차가 명확한 하드웨어적인 일을 하는 경우, 즉 노동의 경우 정말 투입한 시간만큼 산출물이 나온다는 것입니다.


우리가 하는 개발 등의 일을 생각해보겠습니다.

다행이도 우리는 공장의 근로자분들처럼 키보드에 손이 절단될 수 있다는 고민은 하지 않습니다. 그리고 주변의 환경적인 여건이 공장보다는 좋을 것입니다. 주변에서 누가 찾아와도 편하에 앉아서 커피한잔 마실 수 있는 여유를 즐기실 수 있으실 것입니다.

아울러 늘 바쁜 개발업무때문에 야근을 해도 야근수당이 나오지 않는 곳이 많긴 한 것 같습니다. 사실 저희 회사 역시 마찬가지 입니다.
앞으로도 나름의 이유가 있어 저희 Software in Life에는 야근 수당이란 개념을 두지 않을 예정입니다. 대신 인센티브를 주려고 합니다.


만약 여러분들이 공장의 노동자와 같은 환경에서 노동자 처럼 일하신다고 생각하신다면, 저는 여러분들이 투입한 시간만큼 공장의 노동자처럼 산출물이 나와야한다고 생각합니다.

프레스 머신을 한시간 돌렸을때 나오는 산출물이 있습니다. 마찬가지로 여러분들이 개발 IDE로 개발을 한시간 하신다면 나와야하는 코드의 라인이 일정하게 나와야합니다. 그게 노동자가 일하고 일금을 받는 근본적인 이유입니다.

작업한 시간만큼 상응하는 산출물을 우리는 노동의 결과라고 보는 것이며, 노동의 결과에 상응하는 대가를 받는 것입니다.
제조업처럼 작업 절차가 세분화되어 있고 하드웨어적인 결과물을 만드는 일에는 이러한 개념을 바탕으로 노동의 대가를 산정하는 것이 바르다고 생각합니다.


그렇다면 우리가 개발하는 소프트웨어를 생각해보겠습니다.
여러분들이 한시간 코딩을하시면 무조건 일정량 이상의 코드가 산출되는지요?

여러분이 소프트웨어 개발을 노동으로 생각하는 노동자라면 당연히 일정량 이상의 코드가 산출되어야하고 일정량 이상의 소프트웨어 컴포넌트가 작성되어야 하며 일정량 이상의 소프트웨어가 개발되어야 합니다.
하지만, 소프트웨어 개발이란것이 프레스 머신으로 알류미늄을 절단하듯 그렇게 딱딱 맞추어서 개발이 되지 않습니다.

어떤 부분은 10분에도 몇백라인이 나갈 수 있고, 어떤 부분은 한시간 내내 한 라인도 짜기 힘듭니다.
즉 여러분이 투입한 시간만큼 결과물이 명확하게 나오지 않는 것이 소프트웨어 개발이라고 생각합니다.

어떨때는 구글 신과 함께 인터넷의 자료만 찾느라고 하루가 다 갈때가 있습니다. 그리고 어떨 때는 단위 테스트만 하느라고 하루가 갈때가 있습니다.


이러한 비슷한 일이 어떤 일이 어떤 일이 있을까요?
과학자 분들이 이런 비슷한 일을 하시는 것 같습니다.

과학자분들은 연구(Research)를 열심히 하시고 개발(Development)를 하고 수없이 많은 실험(Test)를 합니다.

재미있는 사실은 과학자 분들에게 있어 실패는 실험이라고 생각한다는 것입니다.
그래서 더 좋은 결과물을 얻기 위하여 다양한 실험을 하고 그 결과물이 타당하다는 것을 입증하여 연구 성과물을 만들어 냅니다.


과학자적인 측면에서 소프트웨어 개발을 생각해본다면 여러분들이 구글신과 열심히 새로운 지식을 찾고 익히는 시간은 연구하는 시간이며, 개발하여 테스트하는 시간은 실험하는 시간이라고 생각합니다.

근데, 과학자 분들에게 야근이란 개념은 존재하지 않는 다는 사실을 아십니까?
물론 기관에서 일하시는 과학자 분들에게 야근 수당이란것이 존재할지라도, 원래 과학자 분들은 자신이 좋아하는 연구를 위하여, 그리고 더 좋은 성과를 만들어 내가 위하여 밤을 새워서 다양한 실험을 하고 자신이 만들어내는 결과물을 지속적으로 진보시킵니다.

즉, 과학자로서 다양한 실험과 연구를 위하여 쏟는 시간이기 때문에 야근 이라고 생각하지도 않을 뿐만 아니라 그 연구 성과물을 더욱 좋게 만들기 위한 과정이므로 자연스럽게 연구 시간이 늘어나서 밤에도 일한다는 것입니다.

그리고 그 연구결과물을 평가하고 그 평가에따라 상도 받으시고, 다양한 금전적인 혜택도 보십니다.
대표적인 예가 특허이며, 발명품입니다. 에디슨의 전구가 대표적인 예이지요.


물론 소프트웨어 개발이 완벽하게 과학자 분들처럼 연구하는 활동은 아니지만, 저는 상당히 많은 부분이 소프트웨어 개발업무과 과학자분들의 연구개발 업무가 매우 유사하다고 생각합니다.

이런 일을 시간으로 측정하고 시간으로 측정당한다는 것 자체가 어불 성설입니다.

정말 어렵고 획기적인 알고리즘을 만들어 내기 위하여 1년이란 시간을 쏟을 수 도 있는 것입니다. 반대로 천재적인 분이라면 하루에도 만들 수 있겠지요.
즉, 알고리즘 자체를 평가해야 좋은 것이지 알고리즘을 만들어내기 위한 시간만을 평가한다면 과연 1년이란 시간을 쏟아서 만든 분과 하루만에 만든 분과 어떤 평가를 내려야 하는지 생각해봐야 합니다.


소프트웨어 개발을 노동으로 본다면 1년이란 시간을 쏟아서 만들어 내는 것이 타당한 결과를 보상받을 수 있을 것입니다.
반대로 과학자적인 측면에서 바라본다면 하루만에 만들어내는 분에게 결과에 따라 타당한 보상을 하는 것이 좋을 것입니다.


저는 과학자적인 입장에서 보상을 하는 것을 선호합니다.
같은 소프트웨어 개발은 많은 부분 연구를 통한 결과물을 만들어 내는 경우가 많으며, 더 좋은 결과물을 만들어 내는 분들에게 그 노력의 보상을 할 수 있기 때문입니다.

그저 똑같은 코드를 똑같은 로직으로 변한것 없이 고민 없이 아무런 노력없이 해왔던 대로 개발하고 시간을 때우는 분들보다는 더 좋은 소프트웨어를 만들기 위하여 다양한 연구를 하고 다양한 노력을 해서 더 좋은 결과물을 만들어 내는 분들에게 타당한 보상을 하는 것이 소프트웨어 개발에 더 좋은 평가 및 보상 방안이라고 생각합니다. 

오랜 기간 소프트웨어 업계에서 일하면서 예전과 같은... 노력을 기울이지 않으면서... 말로만 소프트웨어 개발을 해오시는 분들을 봐왔던 터라 말로 시간을 때우면서 자기 개발을 하지 않으면서 열정도 없이 더 좋은 소프트웨어를 만들려고 노력하지 않는 분들을 많이 보아왔습니다.

그리고 모두는 아니지만 이런 분들이 소프트웨어 업계의 단점만 나열하고 이야기하시는 경우를 많이 보아 왔습니다.
반대로 열정적으로 자신이 만드는 소프트웨어를 개발하시는 분들은 이런 이야기보다는 어떻게 하면 더 좋은 소프트웨어를 만들까하는 고민의 이야기들을 나누곤 하였습니다.


자, 우리나라의 개발 여건이 좋지 않다는 것은 잘 인식하고 있지만, 우리가 과연 노동자처럼 일하는 것이 맞는지는... 그리고 노동자와 같은 대우를 바라는 것이 맞는지를 생각해볼 필요는 있다고 생각합니다. 물론 모든 노동 여건이 제가 경험한 공장과 같지는 않겠지만, 노동자와 같은 측면에서 정말 야근 수당을 바란다면 우리가 소프트웨어를 개발을 정말 노동의 수준으로 해야 한다고 생각합니다.

그래야 노동한 시간만큼의 대가를 정당하게 요구할 수 있다고 생각합니다.

반대로 소프트웨어 개발을 과학의 일환으로 바라본다면, 우리는 연구를 하고 있는 것이며, 다양한 실험을 하는 것입니다. 그래서 더 좋은 소프트웨어를 만들어 내기에 당연히 인센티브를 받을 수 있는 권리가 있다고 생각합니다.

그래서 저는 결과물에 따른 인센티브를 드리려고 생각하고 있습니다.
아마 앞으로도 이러한 저의 생각에는 변화가 없을 것 같습니다. 그래서 제가 저희 회사 분들에게 과학자적인 측면에서 더 많은 창의력과 다양한 지식활동을 요구하고 있습니다.

아직 부족하지만 연구개발을 할 수 있도록 잘 지원하는 회사가 될 수 있도록 앞으로 더 노력하겠습니다.


많은 이슈가 있는 글이지만, 제 나름의 생각을 공유하는 것이 좋다고 생각되어 올립니다.
나름의 참고가 되셨으면 좋겠습니다. 감사합니다. :-)


PS: 원문에 몆자 덧붙여서 말씀드립니다.
만약 여러분들이 야근하지 않는 회사를 다니고 있는데 회사에 많은 이익이 발생하였습니다. 그럼 여러분들에게 어떻게 보상하는게 맞을까요?
분명히 야근하지 않았어도 여러분들이 노력해서 좋은 소프트웨어를 만들었기에 회사에 많은 이익이 발생한 것일텐데요.
야근을 권장해야 하나요? 성과에 따른 분배를 인센티브 말고 어떤 것으로 하는게 좋을까요?

추운 일교차가 빛고운 단풍을 만들어 내듯이 한쪽만 바라보지 마시고 양쪽을 모두 바라보셨으면 좋겠습니다.
저작자 표시 비영리
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글  29개가 달렸습니다.
  1. 이전 댓글 더보기
  2. "개발자" 라는 단어에는 작성자 분이 생각하시는거 이상으로 많은 분들이 대상으로 포함된다는것을 감안하시고 작성해 주셧으면 더 좋왓을뻔 햇네요..

    실제 개발 단가를 작업기간과 투입인원으로 후려치는 영세업체들이 상당히 많이 존재 합니다. 이러한 업체에 다니는 개발자는 어쩔수 없이 항상 야근을 하게 됩니다. 물론 대부분 촉박한 시간으로 인해 작성자분이 원하시는데로 항상 신기술을 연구하고 새로운 시도를 할수는 없겠죠. 시간에 쫏기고 일에 치여 아마 힝상 거의 해왔던 방식으로 작업을 하게 될것입니다.
    그렇다면 이러한 분들에게 "결과문에 따른 인센티브"는 어떠한 형식으로 지급을 하실건가요? 야근은 이분들의 탓인가요?

    이러한 분들 외에도 IT업체들의 특성상 '갑,을.병.정' 이러한 식으로 엮이게 되는 일들이 많기 때문에 자의보다는 타의에 의해서 야근을 하게 되는 많은 경우가 발생하게 됩니다. 이러한 경우엔 어떠한 형식으로 인센티브를 지급할수 있게 되나요?


    개발자 중에 작성자 분이 말씀하시는 것 처럼 새로운 기술에 대한 연구들을 하시는 분들도 계시지만 전체의 많은 수의 개발자들은 기술자 입니다. 그들이 하는 일은 정신 노동을 통해 자신의 기술을 파는 것이지 공장에서 프레스 찍는것과 같이 코딩 줄수로 결과를 낼수 있는 일이 아닙니다.

    만약 작성자분이 말씀하신데로 작업 성과에 따른 인센티브 제라면 어떠한 형태로 작업 성과와 연구의 결과를 산출 할수 있을지를 먼저 제시하실수 있으셔야 하지 않을까요?

    물론 대상은 "연구를 하는 특정 개발자"가 아닌 "정신 노동을 하는 대부분의 개발자"입니다.
  3. 에휴~
  4. 개발자가 무슨 벼슬이야?
    그냥 급여 받는 지식노동자잖아.

    야근 수당 안 줄꺼면 야근 시키지 말고...

    월화수목금금금
    하는 제일 큰 이유가 설계/분석 하는 PM이나 그런 사람들이
    개판 쳐서 그런거 아냐?
  5. 말의 의도를 아실만한 분인데 이해를 못하신건지 일부로 그러신지는 모르겟지만

    대부분의 프로젝트에서 일정이 줄어드는건 '사람이 하는일 이라서' 라는 이유와는 별로 관련이 없습니다.

    갑과 을 이라는 관계에서 을은 갑의 요구사항을 수용할수밖에 없는 입장이고 이 상황에서 을 업체는 자기들이 갑에게 받은 부당한 요구(요구사항 증가, 프로세스 변경, 일정 축소 요구등) 를 개발자에게 전가합니다.
    개발 이라는게 그때그때 발휘되는 능력이 차이가 있지만 어느기간동안에 어느정도는 가능하다는 범위가 있습니다.
    처음 일정을 잡을때는 나름대로 (9-6) 의 범위 안에서 합리적으로 잡혔던 일정들 이라도 갑의 무리한 요구와 을의 수락으로
    도저히 업무시간안에 해결할수없는 스케쥴로 변해갑니다.(물론 처음부터 야근, 주말까지 범위에 놓고 일정이 잡히는게 대부분입니다)

    밤 12시, 새벽 두시에 퇴근하면서 '먼저가보겟습니다' 라고 말하고 퇴근하는 개발자가 상당수 존재하는 한국에서
    시간에 따른 정확한 아웃풋 검증이 안되니 야근수당을 줄수 없다는 논리는 가진자의 횡포라고밖에 생각이 안되네요.
  6. 제가 가진 것은 짧은 경력이지만, 많은 부분 공감이 됩니다. 물론, "연구"라는 관점에서라면 야근 수당이 나오지 않아도, 스스로 만족하고 열심히 하는 것 같습니다.

    하지만, 대부분의 작은 기업들이 그렇듯이, "연구"라기 보단 "노가다 작업"이 많은 것 같습니다. 정말 프레스 기계가 알루미늄을 자르듯이, 아무 생각 없이 코드를 작성하는 작업이 더 많았던 것 같습니다.

    특히 야근을 하게 되는 경우는, 연구보단 노가다성 작업을 하게 되므로 그런 불만들이 나오게 되는 것 같습니다.
    정말 관리자, CEO 분들이 개발자를 "코드를 찍어내는 기계"가 아닌, "과학자"로 생각을 해주신다면 많은 분들의 불만이 누그러들지 않을까 생각해봅니다.

    개발을 천직으로 생각하는 사람이 지나가는 길에 글 남겨봅니다. 좋은 글 잘 읽었습니다. :)
  7. 지나가는객 2010.10.29 17:15 신고
    "정말 야근 수당을 바란다면 우리가 소프트웨어를 개발을 정말 노동의 수준으로 해야 한다고 생각합니다.
    그래야 노동한 시간만큼의 대가를 정당하게 요구할 수 있다고 생각합니다"

    ==

    "편의점에 물건사러온 사람이 없었으면 매출이 없었으니 해당 시간에 대해서는 수당을 줄 수 없다고 생각합니다."
  8. 벌써 많은 논란이 되었네요. ^^
    이렇게 서로 의견을 나누는것도 어쩌면 우리가 더 좋은 환경에서 일하기 위해서가 아닐까 생각해봅니다.
    우리나라 개발자 화이팅! 회장님 화이팅!
    내일 스터디에는 나오시나요? ^^
  9. 과학자는 경력되고 나이먹으면 월700은 기본이고

    연봉 1억은 우습죠...

    게다가 말잘듣는 대학원 수십명 노예처럼 거느리고 멋있게 사시구요..


    같은 나이대 개발자들은 통닭집이나 김밥집?호프집 파려 굶어죽지 않으면 그나마 다행인??????

    40~60대 과학자들과 같은 나이대 개발자들 연봉 복지 랑 차이가 너무 나죠..ㅋ.
  10. 그냥 편하게... 2010.10.30 11:22 신고
    인력업체 사장되서 개발자 초중고 10명만 확보하면 1인당 월 100만원만 잡아도 *10하면 월 1000이상 벌죠

    그렇게 몇년만 빠짝 장사해서 돈도벌고 집도 살고 노후도 편하게...사시는게 좋아요

    과학자? 개발자? 야근? 인센티브? 그런거 필요없습니다. 당장 월 수천만원 들어와 그걸로 풍족하게 먹고살고

    노는게 쵝오입니다.
  11. 궁금한 점이 있습니다.

    위에 "지나가는 객"님의 댓글에서 답변하신 내용중에

    "편의점에 물건을 사러온 사람이 없어도 당연히 수당을 지급해야 하구요, 편의점에 물건을 사러온 사람이 넘쳐서 초과근무를 할때는 그에 상응하는 수당을 지급해야 한다고 생각합니다.
    그 수당을 인센티브라는 것으로 드리려고 생각하고 있습니다.
    그럼 인센티브는 나올 수 도 있고 나오지 않을 수도 있는것 아닌가라고 묻는 다면 사실 맞습니다."

    라고 하셨습니다.

    편의점 아르바이트하는 사람이 야근수당을 포기하고, 퇴근을 할 수 있는 것처럼 말씀하신 "인센티브를 포기한다는 약속"을 한다면 야근을 하지 않아도 허용하시는지 궁금합니다.

    즉, 야근과 인센티브에 대한 선택권이 "기업주"에게 있는 것인가 아니면 "개발자" 스스로에게 선택권이 주어지는 것인가에 대한 점이 궁금하다는 것입니다. "개발자" 스스로에게 있다면 문제가 없지만 선택권 자체가 "기업주"에게 있다면 개발자의 선택권보다 기업주의 선택권이 우선시 된다는 것이고, 이는 홈페이지 가장 위쪽에 있는 "이 세상 그 무엇보다 사람이 가장 소중합니다."라는 좋은 구절의 의미가 왜곡되지 않을까 합니다. 기업주에게 야근과 인센티브에 대한 선택권이 있다는 것은 사람보다 기업이 중요하다는 것이 되니까요.

    또한 인센티브는 나올수도 있고 나오지 않을수도 있다는 것에 동의한 것으로 이해하고 있습니다.(잘못 이해했다면 말씀을 부탁드리겠습니다.) 이는 편의점 아르바이트에게 초과근무에 대한 수당을 줄수도 있고, 안줄수도 있다고 한다면 어떤 편의점 아르바이트생이 초과근무를 하겠습니까?
  12. 대부분의 글에 공감이 갑니다. 무엇보다 발생한 이익에 대하여 공유하고자 하시는 마음 그것으로 개발자들은 더욱 열정을 갖을 수 있을겁니다.
    그런데 최근 상황만을 본다면 과학자의 연구와는 다른 것같습니다. 과학자는 언제나 진실을 추구하며 거짓이나 적당한 타협을 하지않을것입니다. 그러나 소프트웨어 공학은 현실과 적당한 타협을 해야하는것 같습니다. 자사 개발 프로젝트라면 보다 연구하는 자세를 갖을 수 있겠으나 SI개발프로젝트에 원리와 원칙을 제시하면 집중포화를 받고 결정에 대한 책임을 묻게 됩니다.
    안타깝지만 그것이 현실이므로 어느정도의 타협이필요하며 급진적 개혁보단 중도개혁이 필요한것 같습니다.
    저 개인은 과학자의 연구와 같이 진실을 추구하고 더 좋은 소프트웨어를 만들수 있었으면 좋겠습니다. ㅎㅎ 그러나 그러기엔 기업은 이윤을 추구해야하기 때문에 항상 실패하는 프로젝트를 해서도 안되고 대중이 원하고 고객이 원하는 결과를 만들어 내야 합니다. 다소 불합리하더라도 종합적으로 판단하여 결정해야 할것입니다.
  13. 얼마전 <장인>이라는 책을 읽었습니다.
    노동자라고도 과학자라고도 할 수 없는 이들이었고,
    유럽의 산업혁명 시기에 몰락해가던 이들이 꿈꾸던 하나의 삶의 형태이었던 장인...

    노동자와 과학자라는 구분을 하시니 저도 그냥 장인이라는 말이 떠오르더군요.
    전 노동자와 과학자가 하나되는 세상을 소망해봅니다.

    덧붙이는 말)
    1. 좋은 글 잘 읽었습니다. 뒷북이네요-_-
    2. 노동자와 개발자라는 구분은 뜻하신 내용을 전달하기 위해서 필요하셨을 것 같기는 합니다.
    3. 개인적으로 인센티브는 반대합니다. 이유는 음...너무 길어서(사실은 정리가 안되어서) 생략-_-
  14. 제 생각은 다음과 같습니다.

    일반적으로 야근과 인센티브는 동일한 개념으로 보기 힘듭니다. 이유는 인센티브는 말씀하신대로 성과에 대한 보상이고, 이는 회사 정책의 문제이지 반드시 지급해야 하는 부분은 아닙니다. 그리고 야근은 "성과가 아닌 시간에 대한 보상"입니다.

    이럴 경우 야근비 및 인센티브에 대해서 지급하는 형태는 다음과 같습니다.

    1. 야근비 있음, 회사정책상 인센티브 없음
    2. 야근비 있음. 회사정책상 인센티브 있음

    1번의 경우 회사정책상 인센티브가 없기 때문에 말씀하신대로 직원분들의 자발적인 동의가 있다면 야근비를 인센티브 형태로 지급해도 무난할 듯 합니다.

    문제는 2번의 경우입니다. 2번의 경우는 자칫 야근비를 인센티브로 전환할 경우 "사실상 야근비가 없어지는 것과 마찬가지"입니다. 이유는 "야근비 없음, 인센티브 있음"과 차이가 없기 때문이죠. 물론 경영자 입장에서는 나가는 금액이 다르다라고 말씀하실 수 있지만 직원들의 입장에서는 이 둘을 구분하기가 힘듭니다.

    제가 이해하기에는 장선진님께서 말씀하시는 정책이 "야근비 있음(인센티브형태), 별도의 인센티브 제도도 있음" 이것으로 이해하였습니다. 만약 제가 이해한 것이 맞다면 야근비는 없는 것과 다르기 때문이죠. 다시 한번 말씀드리지만 "야근비는 시간에 대한 보상이지 성과에 대한 보상체계가 아닙니다." 차라리 야근비는 없고, 인센티브만 있다고 말씀하시는게 오해의 여지를 줄일 수 있는 방법이 아닌가 합니다.

    편의점에서 장사가 잘되서 점장님께서 알바생에게 "인센티브"를 준다고 했을 경우 이는 지급해도 되고, 지급하지 않아도 문제가 안됩니다. 인센티브는 "성과에 대한 보상"이기 때문이고, 회사(편의점) 정책 맘대로 이기 때문이죠.

    하지만 야근비의 경우 "시간에 대한 보상"이기 때문에 편의점이 장사가 잘되든, 못되든 일했으면 무조건 줘야하는 것입니다. 이는 법적으로도 그렇게 되어있죠. 이를 인센티브 형태로 바꾼다는 것은 "시간에 대한 보상"을 "성과에 대한 보상"체계로 바꾸겠다는 말씀이고, 이럴 경우 직원에게는 굉장히 불리한 조건이 됩니다. 이를 인지를 하고, 직원이 자발적으로 승인을 했다면 괜찮겠지만 이 방법 자체가 올바른 방법이라고 할 수 없습니다.

    말씀하시는 방법이 회사에서 융통성을 발휘하게끔 하는 대안을 될 수 있겠지만 블로그처럼 회사 외부분들이 보시기에는 받아드리기 힘든 방법이라고 생각됩니다.
  15. 추가적으로 포데브님의 글에 대한 답변중에

    "결국 야근비라는 것이 결코 인센티브보다 작을텐데.. 야근비를 드린다면 야근을 권장하는 꼴이 되고, 야근비를 드리지 않고 인센티브를 드린다고 하면 믿을 수 없다는 말씀들을 하시니.."

    라는 부분이 있습니다.

    일부 선진국의 경우, 야근 허용시간을 법적으로 제한을 두고 있습니다. 우리나라는 그런 법규가 있는지는 모르겠지만, 만약 없다고 하더라도 사규로 정하면 될 듯 합니다.

    "하루 또는 주간 x시간 이상 야근금지, 야근시 사유를 반드시 작성"

    이렇게 했는데도 문제가 발생한다면 다음과 같은 이유입니다.
    1. 작업이 한사람에게 과도하게 몰렸다
    2. 작업에 걸리는 예상시간에 대한 추정이 잘못되었다. (이는 누구나 할 수 있는 실수입니다.)
    3. 그 사람이 능력이 떨어지거나 근무시간에 놀았다.
    4. 그 사람이 업무에 집중하려고 했으나, 주업무 이외의 잡무가 많아 집중할 수 있는 환경을 회사가 마련해주지 못했다.

    그 외에도 사유는 있을 것입니다. 이를 잘 판단하는 것은 회사를 운영하는 경영자 또는 관리자들의 일입니다. 물론 3번의 경우라고 판단되면 인사고과에 불이익이 가는 것이 당연하다고 봅니다.

    혹시 현 정책을 만드실때(인센티브 형태 지급) 제가 말씀드린 이런 상황을 고려하셨는지, 만약 하셨다면 어떠한 이유에서 이와 유사한 정책을 포기하셨는지에 대한 경험을 공유해주신다면 많은 경영자 또는 관리자분들께서 도움이 되고, 개발자들도 공감을 하지 않을까 합니다.

    매번 친절한 답변 감사드리며, 좋은 답변 부탁드리겠습니다. 감사합니다.
  16. 어잌쿠 참 자랑스럽게 말씀하시네요 ^^
    이러니 IT를 때려치죵
  17. 글을 보고 리플들을 보면서 참 씁쓸하네요
    밤을 새면서 연구와 자기개발을 하는건 과학자 본인의 의사인데
    그걸 전체적인 시스템에 맞춰서 '해야하는게 당연한' 논조로 얘기하시니
    '이래서 우리나라 IT는 아직 멀었구나'라는 생각밖에 안듭니다.

    개발자도 노동자고 사람으로서 받아야할 권리가 있는것인데
    그 권리를 '(개발,일,야근)좋아서 하는 사람들' 이기 때문에 안줘도 된다라는 주변 사장님들을 좀 봐와서
    이 글도 비슷한 맥락인거 같아서 영 기분이 찝찝하네요
  18. 우선 이 블로그에 이렇게 많은 댓글이 달리는 것도 오랜만에 보네요.
    장선진님을 위한 변명을 좀 하자면...제가 실제로(스터디에서) 만나본 장선진님은 그렇게 나쁜분(?)이 아닙니다.
    재미있으신 분입니다. 여긴 뭐 안티카페라도 생길 기세네요.

    우선 개인적으로도 야근은 싫다는걸 먼저 적어둡니다. 사실 진짜 필요한 야근이 아니면 좋아할 사람이 있을까요?
    단지 이 글에서 말하고자 하는 것은 현재 사정과 상황은 이러이러하고, 되도록 야근은 안하려고 하지만,
    어쩔수 없이 야근을 하게될때에는 회사의 입장상 과정론적보다는 결과론적으로 봐야하니 이해해달라... 이렇게 보이네요.
    솔직히 우리나라의 많은 개발자들이 MIT나 옥스퍼드 나와서 구글이나 애플 들어갈만큼의 실력이나
    아이폰같은 아웃풋을 뽑아내는 것은 아니니, 어떻게보면 장선진님의 말이 맞기도 합니다.
    그렇다고 그만큼의 아웃풋이 안되니 야근은 당연하다? 그것 또한 우리같은 보통 개발자 입장에서 말이 안되는 것이지요.
    결국 회사와 개발자의 적절한 조절을 통해 그것을 맞춰나가야 겠죠.
    하지만 또 이런 회사는 유감스럽게도 많지 않겠죠.

    결국 여기 리플을 적으신 개발자분들은 자신과 자신의 회사 입장에서 적으신거고,
    장선진님은 장선진님의 회사의 입장에서 적으신건데 오해가 커졌네요.
    결론을 말하자면, Software in Life안에서 자체적으로 회사와 직원간에 조절이 있었을것인데,
    이 글에 그에대한 자세한 언급도 없기도 해서
    많은 사람들이 장선진님을 '야근시키는 전형적인 IT기업사장'으로 보는 것 같네요.

    사실 이 리플도 오해로 번질까 조심스럽긴 합니다. 제 블로그 주소 적기도 뻘쭘하네요.
    • 사실은 저도 scheme 이랑 clojure 를 많이 좋아했던 사람입니다만.
      그거랑 이거는 전혀 관련 없지요. 아니 더 기분 상하는 일이지요.

      말씀하신 말 중에 진짜 필요한 야근이라는 말이 나오는데, 1년중 몇번 없는 그런 야근의 개념이라면 회사측에서 야근수당을 못 줄 이유가 없잖아요? 대부분의 회사들이 허울좋은 말로 정당화하지만 겪어보면 야근을 하도 쩔게해서 야근수당을 지급 못하는 경우가 대부분이잖아요? 게다가 실력이 안되니까 야근하는 것이 당연하다? 죄송하지만 야근수당 없이 야근을 시키는 행위는 명백하게 노동법을 어기는 행위입니다. 아무리 현실이라지만 법을 어겨가며 하는 어거지 협상이 뭐가 그리 떳떳해서 이렇게 적으셨는지 모르겠네요.

      혹시.. IT관련해서는 노동법이 다르게 적용되거나 그런게 있나요?
      참고하시라고 IT노조의 글을 링크하고 전 물러갑니다

      http://it.nodong.net/zbxe/?document_srl=217314
    • 먼저 그거랑 이거는 전혀 관련 없다는 리플에 대해...
      전 scheme과 clojure를 말한게 아니라, 리플들이 너무 않 좋은 분위기로 몰아가길래 한마디 했던겁니다.

      그러고 보니 노동법을 생각 못했네요. 그 부분은 참고하겠습니다. 이 부분은 분명 제가 잘못 생각한게 맞네요. 저도 다시 생각해보겠습니다.
      그리고 제가 분명 실력이 안되니까 야근하는게 당연하다? 라는 부분에서 말도 안된다고 써놨구요. 잘못 이해하신거 같네요.

      역시 의견교환 같은 것들은 저에게 몇가지 깨달음을 주네요. 단, 이 블로그에서의 악플러들의 일방적인 배설적 리플들이 맘에들지 않네요.
      그리고 이제 막 피어나는 회사에 주저리주저리 쓰고 싶지 않아서 더 이상의 의견은 달지 않겠습니다. 누가 되었다면 죄송합니다.
  19. 과학자같은 개발자 2011.03.14 00:44 신고
    와우~ 과학자와 개발자를 비유해놓으셨다니 정말 좋은 비유입니다 ^-^

    사실 저도 프로그래밍이라는 일을 매우 신성하게 생각하거든요. 연구하는 것도 재미있구요~!

    뭐랄까 논리를 코드로 녹여내는 미학이랄까..?? ㅋㅋ 어쨌든 사회생활 1년 정도 되었지만 이런 생각이 듭니다 :)

    그리고 한 말씀 드리자면 회사에서 중요하게 해야 할일이 몇가지 있는 것같더라구요.

    1. 연구개발에 대한 마인드가 풍족한 사람을 뽑는다.

    - 이런 사람들을 뽑지않으면 주변 사람들이 피곤해집니다. 즉, 돈 벌기위해 일하는 프로그래머는 뽑지 않는게 좋다는거에요.

    2. 성과에 따른 보상책

    - 성과가 나는 사람에게는 확실하게 날개를 달아줘야 합니다. 많은 성과를 내는데 보상이 그만큼 없다면 아무리 열의가 넘쳐도
    김 새죠. 저는 이왕이면 이런 성과같은게 가시적으로 보여졌으면 합니다. 그래야 평가할 때도 말도 없겠구요, 좋은 성과를 내기 위해 노력도 하겠죠.

    저도 개인적으로 야근수당이나 주말 수당은, 정말 그 일을 주말에도 할만한 것인가?를 판단할 수 있는 기준이 명확치 않은 경우에는 없어야 된다고 생각합니다. 실제로 회사에서 주말 수당을 없앴더니 그 바쁘다던 사람들이 나오지를 않더군요

    대충 웹질이나 하다가 가는 사람들도 많고요. 그거보다 인센티브를 많이 준다면 그쪽이 훨씬 낫다는 생각이 드네요.(물론 성과에 따라..)

    휴~ 어려운 주제죠 ㅋㅋ
  20. 대학에서 과학자가 연구를 해서 논문을 쓰고 특허를 내면 그에따라 발생하는 수익은 과학자 본인이 가져가죠. 대학은 이러한 성과를 교수 등의 평가에 적용하여 장려하고, 이런 뛰어난 교수에게 배우고 싶은 학생들에게 학비와 기부금 등을 받아 수익을 창출 합니다. 이러한 과학자는 흡사 스타트업 기업 같은 형태로 유지 되지요. 하지만 기업에 고용된 과학자의 경우는 어떨까요? 외국의 경우와는 조금 차이가 있지만 국내에서는 고용관계로 인해 특허권과 이익을 회사에서 가져가는 경우가 대부분이죠. 이로인한 소송 등은 또 다른 논란거리이지만 저는 여기서 두 조직의 이윤창출 방식에 기인한 고용목적을 이야기하고 싶습니다.

    우리 업계로 돌아와서 과학자 스타일의 뛰어난 개발자가 야근을 해서 뛰어난 소프트웨어 혹은 산출물을 만들어 낸다면 그 이익은 누가 가져갈까요? 이 또한 해당 개발자의 고용목적에 따라 다릅니다. 사업체가 본인 혹은 본인을 포함한 동업자로 이루어 져 있는 상황이라면 전자의 과학자 처럼 해당 산출물로 생성되는 이익을 본인이 직접적으로 배당받게 되겠지요. 하지만 동업자가 아닌 고용주와 고용계약에 의해 업무를 수행하는 개발자는 어떨까요? 그들이 정말로 스타트업의 창업주 혹은 동업자와 같이 그의 열정에 대한 보상을 균등하게 분배받을까요? 그렇지 않습니다. 피고용자는 고용자에 비해 저리스크 저수익을 전제로 고용된 사람이기에 동등한 분배를 한다는 것 자체가 역으로 불평등을 초래하는 일이 될테니까요. 이러한 이유로 직원은 사장님에게 '제가 좀 더 개발을 잘하는거 같은데 월급을 저한테 더 많이 주시죠' 같은 발언를 하지 않습니다. (물론 이 또한 외국의 경우에는 다른 경우도 종종 있다고 알고 있습니다.)
    글쓴이 께서는 개발자 출신으로 아마도 부하직원들을 단순한 피고용인이 아니라 같은 이상을 보고 걸어가는 동업자 혹은 동반자로 생각하고 이러한 생각을 키워오신게 아닐까 조심스레 생각해 봅니다. 우리 업계에서는 실력과 철학을 겸비한 몇몇분들께서 나태한 일부 개발자들에 대해 일침을 가하고 또한 뛰어난 후배들을 아끼는 마음에서 이러한 생각을 표현하시는 걸 본 적이 있기에 그렇습니다.
    하지만 서두에 말씀드린 고용목적과 그에대한 보상은 일치 되어야 하는게 아닐까 생각 됩니다. 창업주와 동업자에게 발생한 수익에 대해 균등하게 분배하지 않으면 문제가 되듯이, 고용계약에 따른 임금을 받는 피고용자에게 창업자와 동업자 수준의 협조와 헌신을 바라는것은 합리적이지 못한 요구이지 않을까요? (인센티브 또한 창업자가 받는 수익과 피고용인이 받게되는 인센티브는 차원이 다를 것입니다. 투자 리스크의 수준이 다르니까요) 동업자에게 기대할 수준의 헌신을 요구하시려면 그에 걸맞는 보상을 해 주는게 맞는 일일겁니다. 단순한 일회성 금전보상이 아닌 주식의 개념으로 말이지요.

    어쩌면 글쓴이 께서는 동업자와 피고용자 중간쯤에 위치한 새로운 고용형태를 생각하시는 것 같습다. 글쓴이께서는 노동자라고 표현하신 단순한 피고용자 보다 많은 헌신과 시간적심적투자를 더 많이 하는 직원 말이지요. 더 많은 헌신을 요구하려면 더 많은 보상을 주는 것이 합리적일 것 입니다. 이는 기존과 다른 형태의 고용이니 기존의 보상방식은 맞지않아! 라는 취지로 야근수당은 적합하지 않고 인센티브를 지급하겠다 라는 형태의 발언로 나타나게 되었겠지요. 이경우에도 반드시 모든 인센티브가 기존의 단순 피고용자 보다 더욱 많은 보상을 지급해야 할 것입니다. 그 규모의 마지노선은 인센티브를 최소로 받는 사람이 반드시 기존의 야근수당을 받았을때 이상의 보상을 받는 형태가 되어야 합니다. 이 새로운 형태의 고용은 기존의 단순 노동자 보다 더 놓은 헌신과 품질을 요구받게 되기 때문이지요.
    글쓴이의 글에 부정적인 덧글이 많이 달린 것은 모두들 직관과 그간의 경험으로 이러한 사고를 하셨기 때문이 아닐까 하는 생각이 들어 장문의 글을 남기게 되었습니다.

    끝으로 글쓴이께 감히 여쭙겠습니다. 글쓴이 께서는 본인의 피고용자들에게 새로운 형태의 더 높은 헌신과 노력을 요구하면서 최소한 기존 노동자들의 수당보다 훨씬 더 좋은 보상을 모든 과학자형 개발자들에게 제공할 준비가 되셨습니까?
    아니면 많은분들이 댓글로 우려를 남기신 바 처럼 전체 수당은 균일하게 유지한 채 나태한 피고용자 들에게 돌아갈 수당을 빼앗아 과학자형 개발자에게 지급하는 단순한 트릭으로 고용 결과물의 수준을 높이실 생각이십니까? 이경우 그들의 헌신으로 늘어난 수익 대다수 주주의 주머니에 들어가는 것은 아닙니까?
    확실한 분배를 전제한다면 정말 멋있는 말씀을 하신 것인데, 평소 생각해오신 그러한 분배에 대한 내용이 본문에는 그만 누락되어 많은 오해를 낳은것이라 생각하도록 하겠습니다.

    덧1. 근무환경 이야기 하셨는데 개발자들처럼 디스크 각종질환 노총각 노처녀 양산 등 직업병으로 안고 살고 사는 직군이 또 있습니까? 술자리 농담중에 새벽4시넘어 술 안취하고 퇴근하면 it하는 사람이냐고 택시기사가 물어본다고 하지요. 그렇습니다. 심지어 택시기사님들도 우리네 근무가 열악하다는건 알고계십니다.
    • 안녕하세요 장선진입니다.

      저 또한 이 글에 댓글을 다는 것이 몇년만인지 모르겠습니다.

      이 글은 제가 창업 초기에 적은 글이며, 신뢰를 바탕으로 서로 노력하며 발전하는 이상적인 회사 모습을 그리면서 작성한 글이 맞습니다.

      이 글이 많은 논란의 대상이 되었지만, 저에게는 많은 깨우침과 현실과 이상과의 차이에서 여러분들의 의견을 잘 알 수 있는 글이었으므로 논란이 대상이 되었으며, 제가 많은 오해와 비판을 받았음에도 불구하고 지속적으로 공개하고 있는 글입니다. 즉, 앞으로도 계속 공개할 예정입니다.

      우선 야근에 대한 생각과 우리나라의 현실이 매우 안좋다는 것에 동의합니다.

      이에 따라 부족하지만, 저희 회사에서는 야근을 가급적이면 시키지 않고 있습니다. 참고로 업무 시간에 R&D를 하는 것을 권장하고 있으며, 필요시 업무시간에 스터디 시간을 가지도록 하는 것을 권장하고 있습니다. 항상 변화하는 기술과 트렌드 이를 기술과 아이디어로 발전시켜나가는 일련의 과정이 모두 연구이자 일이라고 생각합니다.

      즉, 이 글을 적을때나 지금이나 야근은 자신이 좋아서 하는 경우를 가정하고 있습니다. 물론 우리나라에서 그런 환경을 갖추고 있는 회사나 이를 이해하는 경영진이 부족하다는 것을 알고 있습니다.

      저의 경우에는 부족하지만, 야근을 가급적이면 임직원 모두 하지 않도록 하려고 노력하고 있으며, 앞으로도 그럴 것입니다. 참고로 창업한 회사에서 야근을 가장 많이 하는 사람은 저와 일부 임원분입니다.

      모든 일이 앞에서부터 정리가 되지 않아서 야근을 한다고 생각하기에 정리하는데 시간을 부족할 경우 임원진이 야근을 하고 있습니다.
      저의 경우에는 아직 부족한 점이 많아 앞으로도 야근을 많이 해야 할 듯 합니다.

      IT에서 무언가 연구한 성과에 대한 가장 큰 보람과 보상은 연구를 진행하는 본인에게 있다는 생각에는 변함이 없습니다. 더 새로운 기술을 적용하고 쌓은 경험은 누가 뭐래도 이를 연구한 본인에게 가장 큰 보람이자 돈으로 환산되지 않을 경험이 될 것입니다.

      이러한 면에서 본인의 발전과 회사의 발전을 위하여 노력하시는 분들에게 더 큰 보상을 드리고 싶은 마음에서 인센티브를 이야기 드린 것입니다.
      물론 이야기 한대로 회사에서 일하는 것을 피고용인과 고용인과의 관계로 보는 것이 일반적인 회사를 바라보는 시각이나, 제가 창업한 회사는 아직 벤처이고 앞으로도 벤처일듯 합니다.
      이러한 벤처에서 함께 노력해 간다면 만족할 수준이 아니더라도 최소한의 보상을 더 해드리고 싶은 마음은 늘 같습니다.

      확실한 분배의 기준에 대해서는 적용 및 실천해가면서 정리하고자 합니다.
      이 부분은 수익 모델을 구체화하고 적용하면서 말씀드리겠습니다. 참고로 바이럴 페이(http://www.venturesquare.net/531972)같은 모델을 생각하고 있습니다.

      개발자들 만큼 자유롭고 창의적인 직업이 없다고 생각합니다.
      해커톤도 나가고 다른 개발자들과 스터디도 즐기고 오픈 소스 활동에도 참여하면서 그 경험을 도서 등으로 정리하여 집필하고 하는 활동 모두가 저는 회사에서 할 수 있는 일이라고 생각합니다. 그렇게 듣고 익힌 것들을 회사 프로젝트에 다시 환원해주시면 됩니다.

      저는 이를 뒷받침할 수 있는 근무 환경을 추구하고자 합니다.
      다만, 제가 이러한 환경이 조성될 수 있도록 이끌겠지만, 지나서 보니 함께 참여하시는 분들 역시 이러한 환경을 좋아하고 즐길 수 있는 분들이어야 하는 것 같습니다. 이 부분은 아직 저에게도 숙제입니다. 함께 이러한 환경을 만들어 보는 것도 좋겠지요.

      마지막으로 이 댓글이 또 다른 논란을 일으킬 것 같아 걱정입니다.

      다만, 다시 한번 말씀드리지만, 야근을 좋아하지 않으며 권장하고 있지 않습니다.
      IT의 일이란 자기가 재미있으면 것이 누워서도 코딩을 하고 기획을하고 디자인을 하는 것이기에 야근을 권장하는 것이 얼마나 비 효율적인 것인가를 잘 알고 있습니다.

      항상 생각하는 것을 좋아하고 더 깊은 연구개발과 실천을 하시는 분들에게 다양한 방법으로 더 좋은 환경과 보상을 제공해드리고 싶은 취지에서 쓴 글이니, 여러분이 현재 처하고 있는 환경에 대한 답답함이나 불만의 연장선에서 본 글을 보지 않으셨으면 좋겠습니다.

      두리뭉실한 답변을 몇년만에 적는군요~
      서로 시간이 되신다면 커피한잔 하면서 이야기한다면 더 좋은 이야기를 나눌 것 같습니다.

      참고로 Facebook ID는 jangsunjin(https://www.facebook.com/jangsunjin) 입니다.
      감사합니다.
  21. 회사를 운영하고 계십니까
    회사를 다니고 계십니까

    야근비없이 라는 발상은 어디서 하신건지
secret
항상 고민했던 부분이 소프트웨어(Software)란 무었인가?라는 물음이었습니다. 정말 어려운 이 문제에 관심을 가지는 이유는 제가 소프트웨어를 좋아하고 좋은 소프트웨어를 만들어 내고 싶기 때문입니다.

출처: http://www.gnu.org/philosophy/compromise.html


즉 소프트웨어에 대한 제 자신만의 생각을 명확하게 가지고 있어야, 삶을 위한 소프트웨어에 대한 구체적인 생각을 정리할 수 있다고 생각하고 있기 때문입니다.

따라서 저는 항상 소프트웨어란 무었인가?(What is the software?)란 질문을 스스로에게 던지곤 하였습니다.

많은 문헌들과 인터넷에서도 수 많은 소프트웨어의 정의가 있습니다. 하지만 대부분 소프트웨어의 분류를 정하고 각 분류별로 소프트웨어의 특징을 설명하여 정의하거나, 아니면 소프트웨어 개발 방법론 차원에서 소프트웨어를 바라보고 있습니다.

물론 이러한 정의 역시 틀린 것은 아닙니다.

하지만 소프트웨어는 그렇게 쉽게 정의할 수 있는 것이 아니란느 생각이 많이 듭니다.


여러분들은 소프트웨어가 무었이라고 생각하시나요 :-)


한때는 소프트웨어를 생명체과 같다고 생각하기도 하였습니다. 마치 살아있는 동물과 같은 생명체 말이죠 ;-)
현재 저와 여러분들은 모두 소프트웨어를 통하여 제가 쓴 글을 보고 계십니다. 마치 생명체가 다른 생명체에게 이야기를 하듯이요~

제가 쓴 글은 웹 어플리케이션 서버(WAS)라는 생명체에게 전달되고 이 글은 다시 DBMS라는 생명체에 전달됩니다. 그리고 DBMS는 제 글을 잘 보관하고 있다가 웹 브라우져란 생명체가 네트워크란 신경망을 통하여 WAS에 제 글을 요청하고 WAS는 다시 DBMS에 요청하여 HTML이란 넘을 재빠르게 만들어서 맛있는 쿠키(Cookie)까지 넣어서 보내주면, 웹 브라우져는 다시 OS를 통하여 여러분들이 보고 있는 모니터를 통하여 빛으로 출력시킵니다.

마치 하나의 에코 시스템(Eco System)과 같은 이러한 일련의 과정은 마치 생명체가 서로 유기적으로 얽혀있으면서 살아가는 과정과 매우 비슷하다는 생각을 하곤 하였습니다.

하지만 생명체는 원래 스스로 존재하여야 하는데, 소프트웨어는 스스로 존재하지 못하며, 스스로 진화하지 못하는 문제점이 있습니다. 이에따라 소프트웨어는 생명체와 비슷하지만 생명체는 아니다라는 결론에 도달하였습니다.

그럼에도 불구하고 소프트웨어는 진화하고 있으며, 매일 매일 인간이 산소를 먹고 이산화탄소를 배출하듯이, 소프트웨어도 전기를 먹으면서 전기를 통하여 소통하고 전기를 소모하여 인간하고 비슷하게 이산화탄소를 배출하고 있습니다.

그리고 우리가 사용하는 소프트웨어는 매일 매일 진화하고 있습니다. 이러한 진화를 소프트웨어가 스스로 만들어내지는 않지만, 인간의 도움을 받아 이제 소프트웨어와 소프트웨어간의 자유롭게 통신하여 서로 필요로하는 정보를 주고 받고 있습니다.

따라서 어느 정도 진화하고 있다고 볼 수 있습니다. 다만 진화를 스스로 하지 못하는 것은 현실입니다. 하지만 누가 아나요~


I, Robot의 VIKI (Virtual Interactive Kinetic Intelligence)Matrix의 Oracle과 같이 스스로 생각하는 소프트웨어가 나올지 모릅니다. :-)



여튼 아직도 소프트웨어를 생명체로 보기엔 무리가 많이 따릅니다.

그럼 소프트웨어를 무었이라고 봐야 할까요?
어림 짐작하기에도 소프트웨어는 펌웨어(Firmware)부터 미들웨어(Middleware) 및 시스템 소프트웨어(System Software) 및 게임, 그리고 사무용 소프트웨어 등등... 정말 많은 분류를 가지고 있습니다.

최근에는 iPhone의 돌풍으로 인하여 핸드폰에 탑재되는 수 많은 소프트웨어들이 각광을 받고 있습니다.
정말 iPhone 위에서 실행되는 소프트웨어는 무궁무진한데 그 중에는 오카리나를 불 수 있는 소프트웨어까지 있습니다. 제가 iPhone을 사고 싶은 가장 큰 이유가 바로 이 오카리나 소프트웨어 때문이었죠 :-)


이렇게 다양하고 많은 분야에서 활용되는 소프트웨어를 정의한다는 것은 정말 어려운 일 가운데 하나라고 생각합니다.


하지만 최근 저는 소프트웨어는 서비스이다.(Software is a Service.)라고 정의해가고 있습니다.
마치 SaaS(Software as a Service)의 짝퉁같은 이 정의는 SaaS를 접하기 이전부터 약간씩 가지고 있던 생각이지만, 사실 SaaS라는 패러다임을 접하면서 더욱 강하게 구체화해 나가고 있습니다.

생각해보면 서비스는 사람을 위하여 존재합니다.

거의 모든 서비스는 사람과 직접 관계되어 있거나 궁극적으로 사람을 위하여 존재하는 경우가 대부분입니다. 식당에서 식사를 하기 위해 웨이터에게 서비스를 받는 것은 결국 사람을 위한 서비스이며, 마찬가지로 제 글을 웹 브라우져란 넘이 여러분에게 보여주는 것 또한 웹 서핑이란 서비스를 웹 브라우져란 친절한 웨이터의 서비스입니다.

우리가 가장 많이 사용하는 웹 어플리케이션들은 대부분 어플리케이션이라고 생각이 들지 않습니다. 언제 포털 사이트나 검색 사이트를 이용하기 위하여 뭔가를 여러분의 컴퓨터에 설치한 적이 있으신가요? 아 웹 브라우져를 설치하셨군요 :-) 하지만, 꼭 어느 특정 포털 사이트나 검색 사이트를 이용하기 위해서 설치하신 것은 아니죠.

즉, 웹 어플리케이션이란 소프트웨어가 어려분에게 수 없이 많은 정보와 기능을 제공하고 있음에도 불구하고 여러분들은 웹 어플리케이션을 소프트웨어로 바라보지 않고 포털의 서비스, 검색 사이트의 서비스로 인식하고 있다는 것입니다.

마찬가지로 최근 패키지형 소프트웨어 역시 이와 유사한 행보를 보이고 있습니다. 즉 자동 업데이트 기능인데요, 언제 내가 요청하지도 않았음에도 불구하고 자동으로 업데이트를 하여 더욱 좋은 기능을 사용할 수 있도록 지원하거나 결함이 있는 기능을 수정해줍니다.


즉, 서비스가 강화된 것입니다. 소프트웨어에 서비스가 강화되다니!!이게 무슨 말이랍니까?


개발자 입장에서 소프트웨어의 개발은 정말 서비스 정신을 가지고 할 수 없는 작업중에 하나입니다. ^^;;
"내가 무슨 커피숍의 바리스타도 아니고 어떻게 서비스 정신을 가지고 소프트웨어를 만들어 냅니까?" 라고 이야기하실 수도 있지만, 소프트웨어를 사용하는 여러분 자신도 더 좋은 서비스를 제공하는 소프트웨어를 선호할 것입니다.

왜냐하면 더 좋은 서비스를 제공하는 소프트웨어가 당근 더 좋기 때문입니다.

개인적으로 웹 브라우져를 거의 무조건 화이어 폭스를 사용합니다. 우선 인터넷 익스플로러가 느리기도 하지만 질 좋은 무료 플러그인들 덕에 웹 서핑을 정말 편하게 하고 있기 때문입니다. 이 플러그인들이 없다면 제 웹 서핑은 정말 최악일 것입니다.

이런 제가 화이어 폭스를 선택한 것은 당근 화이어 폭스가 인터넷 익스플로러보다 서비스가 좋기 때문입니다.

아울러 서비스는 진화합니다. 누구를 위해서 진화합니까? 바로 여러분들을 위해서 서비스는 진화합니다.
마찬가지로 소프트웨어도 진화합니다. 바로 여러분들을 위해서 진화하는데, 사실 여러분들에게 더 좋은 기능, 즉 더 좋은 서비스를 제공하기 위해서 진화합니다.

소프트웨어 진화의 이유가 분명해졌습니다. 바로 여러분들에게 더 좋은 서비스를 제공하기 위해서 소프트웨어는 진화한다는 것이 제 생각입니다.
아울러 서비스는 결국 사람이 사람을 위해서 제공하는 것입니다.

따라서 생명체로는 풀리지 않았던 진화를 시켜주는 주체가 바로 우리 자신이며, 우리가 우리들에게 더 좋은 서비스를 제공할 수 있는 소프트웨어를 만드는 과정이 바로 소프트웨어의 진화이다. 라고 정의할 수 있습니다.

이러한 소프트웨어의 진화는 우리가 소프트웨어로부터 제공받는 서비스의 질이 만족스러울때까지 진화할 것입니다. 즉, 소프트웨어의 진화와 발전은 결국 사람을 향한다는 것입니다.

사람을 향한 질 높은 서비스를 제공할 수 있는 소프트웨어를 만드는 과정이 소프트웨어의 진화 과정이라고 볼 수 있습니다.
현재 iPhone의 돌풍으로 모바일 어플리케이션 분야에서 이러한 소프트웨어의 진화가 급격하게 진행되고 있습니다.



이에따라 오랜 저의 숙제였던 그럼 삶을 위한 소프트웨어는 무었인가? 라는 제 자신의 질문에 이제 답 할 수 있습니다.

사람들의 삶의 질을 높일 수 있는 서비스를 제공하는 소프트웨어가 바로 삶을 위한 소프트웨어라고 정의하였습니다.

이 문제로 지난 몇년간 고민해 왔었습니다만, 이제 이러한 정의를 바탕으로 더욱 삶을 위한 소프트웨어를 가열차게 만들어 가겠습니다. ^^~
감사합니다~
저작자 표시 비영리
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글  2개가 달렸습니다.
  1. 네,객체 지향이다 고객지향이다 용어는 다양한데 님의 글을 '이용자지향'으로 이해하면 될까요?
    개발자들이 이런 깊은 생각을 하면서 소프트웨어를 개발하면 더 좋겠어요. 이미 그런 분들 있겠지만서도요.
  2. 잘 봤습니다~~ 멋져요!! ㅋㅋ
secret
언제부터인지 가장 정겨운 소리 중에 하나가 구세군의 청명한 종소리인것 같습니다.
지하철에서.. 길에서 우리에게 우리 주변의 어려운 사람들을 다시한번 생각하게 하는 구세군의 종소리..

이 종소리가 없었다면 우리는 아마도 다른 어려운 이웃들을 생각하지 못하고 지나치게 될 것 같습니다.

저는 구세군의 청명한 종소리야 말로 우리에게 가장 필요한 소리라고 생각합니다.
마찬가지로 제 블로그가 여러분들에게 구세군의 청명한 종소리와 같은 블로그가 되었으면 좋겠습니다.

여러분들에게 가끔 지친 일상에 다른 것들을 찬찬히 살펴보고 생각하게 할 수 있는 블로그가 되었으면 좋겠습니다.

그리고 한가지 더 붙인다면 자선냄비와 같은 소프트웨어를 만들고 싶습니다.
정말 옛날에는 집에 쓰던 냄비에 빨간색 페인트를 발라서 사용했었을 것 만 같은 자선냄비는 우리의 마음을 녹여내 맛있는 음식을 만들어내는 진정한 냄비인것 같습니다.

우리에게도 이런 자선냄비와 같은 소프트웨어가 필요하지 않을까 생각합니다.
올해 저는 "Software in Life"란 팀을 통하여 삶을 위한 소프트웨어를 하나 만들었었습니다.

바로 "Vision Software in Life"입니다.
사람들의 삶에서 가장 소중한 비전(Vision)을 관리하는 소프트웨어였지요~

이 소프트웨어는 아직 많이 다음어져야 하고 많이 개발되어야하지만, 이 소프트웨어에는 모든 사람들이 자신이 이루고 싶은 비전을 달성할 수 있도록 도와주려는 마음이 담겨져 있습니다.

내년에는 "Vision Software in Life"를 더욱 발전시켜서 정말 자신의 비전을 실현하고 싶은 분들에게 도움을 드리고 싶습니다.
그 외에도 많은 다른 소프트웨어를 만들어서 소프트웨어의 자선냄비를 만들고 싶습니다.

올 한해동안 저의 부족한 블로그를 애독해주신 모든 분들에게 진심으로 감사드립니다.
아울러 변함없이 내년에도 더 청명한 이야기와 자선냄비와 같은 소프트웨어를 만들겠습니다.

2010년에는 모두 소망하시는 것들이 꼭 이루어지는 한해가 되시길 진심으로 기원드립니다.
감사합니다. :-)

출처: http://www.innoworks.co.kr/community/happyhours.html?mode=read&id=197&kw_name=&kw=&page=1&kindcheck=&kc=

저작자 표시 비영리
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글이 없습니다.
secret
상상력에 관한 좋은 격언이 있습니다.

상상력은 지식보다 더 중요하다.


만약 아인슈타인이 상상력이 없는 사람이었다면,  E=MC2이란 유명한 공식은 탄생하지 않았을 것이며, 우리는 블랙홀의 존재를 알 수 없었을 것이며, 빛을 통한 여행이란 것이 무었인지 알 수 없었을 것입니다.

이 모든 것은 상상력에서 시작되었습니다.

무었인가를 상상한다는 것은 정말 즐거운 일이라고 생각합니다.
하지만 정신없이 일하다보면 상상하는 것을 잊어버릴때가 있습니다.

내 앞에 닥친 이넘의 버그를 잡아야... 이 문서를 완성해야.. 이 비즈니스 로직을 완성해야.. 이 프로그램을 완성해야.. 이 소프트웨어를 완성해야.. 이렇게 바로 앞에 있는 수 많은 일때문에 즐거운 상상을 하지 못할때가 많습니다.

하지만, 가끔 이 소프트웨어에 이런 기능이 더 부가된다면.. 이 소프트웨어를 사용하는 사람 중에 이런 사람도 있다면.. 이 소프트웨어가 이렇게 발전할 수 있다면.. 이렇게 멍때리듯이 상상을 해본다면 분명히 어려분들의 소프트웨어는 더욱 풍요로워질 것이라고 생각합니다.

개인적으로 직장이 집에서 먼관계로.. 거의 두시간 가까이 걸리는 관계로 소위 멍때리는 시간이 많습니다.
이때 이런 저런 상상을 합니다.

그냥, 스쳐가는 바깥 풍경을 바라보면서, 내가 지금 만들고 있는 소프트웨어에 대한 이런 저런 상상을 합니다.

제가 만드는 소프트웨어가 가장 훌륭한 기능을 제공할 수 있다면.. 제가 만드는 소프트웨어의 UI가 사용자가 정말 쓰고 싶은 UI라면.. 제가 만드는 소프트웨어의 가치가 더 높아진다면... 이렇게 상상을 하다보면, 아 우선 이렇게 하면 되겠구나! 이런 기능이 추가되면 좋겠구나! 이렇게 함께 만들면 더 재미있겠는걸~ 등등의 생각을 하게 됩니다.

그리고 그러한 생각을 하나씩 하나씩 동료들과 나눕니다. 그리고 소프트웨어는 점점 개선되어 가고, 더욱 좋은 소프트웨어가 되어 가고 있다는 느끼고 있습니다. 물론 앞으로 가야할 길은 많이 많이 남았지만, 이러한 상상을 하나 하나씩 현실로 변화시키면서 저는 즐거움을 느끼고 있습니다.

그래서 전 소프트웨어가 가장 큰 원동력은 상상력이라고 생각합니다.
소프트웨어 개발자들의 경우 상상력이 풍부하여야 한다고 생각합니다. 주어진 비즈니스 로직대로.. 주어진 설계서대로.. 주어진 개발 방식대로.. 주어진 프레임웍대로.. 아무런 의심과 상상없이 개발한다는 것은 사실 아주 따분한 일입니다.

내 상상력이 묻어나는 소프트웨어를 만든다는 것, 그리고 그것을 함께 만들어 간다는 것, 거기에 다른 사람의 상상력까지 함께 보탠다면, 아마도 세상에서 가장 훌륭한 소프트웨어가 만들어지지 않을까요?

한번 상상해보세요 :-)
물론 시간은 걸릴지 모르겠지만, 여러분들이 만들고 꿈꾸는 것들을 상상해보세요~ 그리고 너무 큰것부터 상상하기 보다는 바로 앞에 있는 소프트웨어에 대한 상상부터 시작해보신다면, 쉽게 그리고 빠르기 여러분들의 상상을 현실로 바꿀 수 있을 것입니다.

저 역시 오늘도 오고 가는 지하철에서 그리고 차안에서 삶을 위한 소프트웨어에 대한 상상을 마음껏 하렵니다.
감사합니다. ;-)
저작자 표시
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글 하나 달렸습니다.
  1. 선진님 오랜만에 놀러왔습니다. 그 동안 너무 바빠서 ... 사실 술 마시느라 ^^ 못 놀러왔네요 ...
    현실에 치여 즐거운 상상하는 시간이 점점 줄어드는듯 하네요 ㅡㅡ;; 즐거운 상상 -> 멋진 소프트웨어 ~~ ㅎㅎ
secret
최근 나만의 80/20 법칙 만들기란 책을 읽으면서 80/20 법칙에 많은 관심을 가지고 있습니다.
이에따라 일명 파레토 법칙이라고도 하는 80/20 법칙이 소프트웨어에 어떤 영향을 주었는지 알아보고자 합니다.

간단하게 80/20 법칙에 대하여 설명하고자 합니다.

80/20 법칙은 100여년전 이탈리아의 경제학자인 빌프레도 파레토(Vilfredo Pareto)가 처음 주장한 이후 파레토의 법칙, 파레토의 원리, 80/20 규칙, 최소 노력의 원리, 불균형의 원리 등 수많은 명칭으로 불리우는 법칙입니다.

출처: http://www.searchenginepeople.com/blog/search-and-the-pareto-principle.html

출처: http://www.searchenginepeople.com/blog/search-and-the-pareto-principle.html



그림과 같이 핵심적인 20%의 노력으로 80%의 결과를 얻을 수 있다는 것이 이 법칙의 내용입니다.

따라서 가장 핵심이 되는 20%에 집중해야 하며, 어떻게 핵심적인 20%에 집중할 수 있는지에 관한 것이 80/20 법칙의 핵심입니다.


1950년과 1990년 사이에 일어난 "품질 혁명"은 소비재 상품은 물론 그 밖의 제품의 품질과 가치를 크게 변화시켰습니다.

사실 품질 혁명의 창시자는 루마니아 출신의 미국인인 조지프 주란(Joseph Moses Juran, 당시 전기기사)과 에드워드 데밍(Edward Deming, 당시 통계학자)이었습니다. 이 두 사람은 제2차 세계대전 이후 비슷한 시기에 자신의 이론을 각각 전개하였으나 고품질을 추구하는 미국 대기업의 흥미를 끄는 데 실패하였습니다.



하지만 아니러니하게도 일본 기업들이 주란이 출판한 "품질 관리 핸드북"이란 책에 많은 관심을 보여 1950년대 초 이 두 사람은 일본으로 건너가 당시 조잡한 품질의 물건만 생산해내던 일본 기업들에게 고품질과 높은 생산을 할 수 있는 품질 혁명을 일으키게 된 것입니다.

출처: http://www.amazon.com/Quality-Handbook-McGraw-Hill-International-Editions/dp/0071165398/ref=sr_1_1?ie=UTF8&s=books&qid=1228867990&sr=1-1

출처: http://www.amazon.com/Quality-Handbook-McGraw-Hill-International-Editions/dp/0071165398/ref=sr_1_1?ie=UTF8&s=books&qid=1228867990&sr=1-1



현재의 주란이라 데밍의 품질 혁명을 적극적으로 실천한 도요타나 일본의 전자 및 가전업체 모두 세계적인 일류기업이 될 수 있었던 것입니다.

이러한 분들은 품질에 관해서는 아키텍트와 같은 분들이십니다. 품질이란 분야는 소프트웨어에서도 마찬가지로 매우 중요한 분야입니다. 나중에 한번 꼭 읽어보고 싶은 책입니다. :-)

출처: http://www.amazon.com/Architect-Quality-Autobiography-Joseph-Juran/dp/0071426108

출처: http://www.amazon.com/Architect-Quality-Autobiography-Joseph-Juran/dp/0071426108



많은 각광을 받고 있는 식스 시그마(Six Sigma)의 기본적인 철학은 모두 주란과 데밍에게서 영향을 받았다고 생각됩니다.


Six Sigma의 프로세스에 포함된 각 단계를 어느 방법론에선가 보신것 같지 않으십니까?
최근 각광받고 있는 SOA의 방법론등과 매우 유사한 단계를 가지고 있는 것 같습니다. 과연 뿌리는 어디일까요?


중요한 점은 이 품질 혁명의 바탕이 된 것이 바로 80/20 법칙이라는 점입니다.

조지프 주란은 "파레토 법칙" 혹은 "절대 소수의 법칙"을 신봉하였은데, 그의 책인 "품질 관리 핸드북"에서 제품의 불량 발생요인에 관한 분석시 파레토의 법칙을 인용하였습니다.

"불량품의 분포는 매우 불균형해서, 결함의 대부분은 극히 일부 품질의 특성으로 인하여 일어난다"라고 말하며 균일하지 않은 부의 분포는 품질 결함에도 적용할 수 있다라고 덧붙였습니다.

특히 80/20 법칙을 통계적 품질 관리에 응용했는데요, 결함을 일으키는 원인을 중요도 순서로 나열하여 대부분의 결함을 일으키는 소수의 원인을 찾아내도록 권고하였습니다.

즉 모든 문제를 다 해결하려고 하기 보다는 "결정적인 몇 가지 문제"를 찾아서 그것을 해결해야 한다는 것입니다.

20%의 핵심적인 문제를 해결하면, 80%의 중요하지 않은 문제들도 자연스럽게 해결된다는 의미입니다.

스프레드시트 부분에 자료를 입력하거나 가져오십시오. 그리고 원하는 부분을 블록으로 설정한 후 메뉴에서 6가지 그래프 모양 중 원하는 모양을 선택하여 주십시오. 막대 그래프 관리도, 런차트, 산포도, 원 그래프 및 파레토 그래프 중 원하는 유형의 도표를 한번의 클릭으로 작성하실 수 있습니다.

파레토 그래프는 80/20 법칙이 적용되어 있어서, 예를 들어 천가지 소비자 불만 사항 중 약 800가지는 원인의 20%만 없애면 해소할 수 있다는 점을 보여줍니다.

-ABC Data Analyzer 설명 메뉴얼 중에서


이러한 80/20 법칙을 품질관리 뿐만 아니라 문제도 많고 버그도 많은 소프트웨어에 적용한다면 어떻게 될까요?

흔히들 소프트웨어는 자동차와 같이 모든 기어들이 착착 맞아서 일사분란하게 움직여 완벽한 처리를 할 것이라고 생각하는데, 실제 소프트웨어를 사용하다보면 예기치 않은 문제나 버그를 만나는 경우가 무척 많습니다.

저의 경우 엔터프라이즈용 소프트웨어를 개발하는 경우 다양한 고객의 요구사항에 맞도록 구축하다보면 소프트웨어 자체의 결함이라기 보다 고객 관점이 잘못되어 있거나 해당 조직의 비 논리적인 관행 등으로 인하여 프로세스 자체가 잘못되어 있는 경우가 많습니다.

이렇게 프로세스가 잘못되어 있는 경우에는 프로세스를 바로 잡지 못하면, 어쩔 수 없이 소프트웨어의 결함이 유발되어 사용자들에게 좋은 서비스를 제공할 수 없게 됩니다. 그리고 정확하게 추산해보지는 않았지만 이러한 문제로 발생하는 버그가 전체 버그의 대부분을 차지한다는 점입니다.

즉 20%의 잘못된 프로세스만 고치면, 80% 넘는 버그를 제거할 수 있다는 것입니다.
이미 이런 관점에서 소프트웨어 개발이 이루어 지고 있습니다.


1960년대 시작된 정보 혁명은 비즈니스의 많은 분야에서 작업 습관과 효율성을 크게 바꾸어 놓았습니다.
정보 혁명을 뒤에서 추진하는 컴퓨터와 소프트웨어 전문가드은 품질 운동을 가까이에서 접한 사람들이기 때문에 일반적으로 80/20 법칙에 대하여 잘 알고 있으며 이를 광범위하게 적용하였습니다.


사례를 살펴보면 다음과 같습니다.

RISC는 80/20 법칙이 적용된 사례라고 할 수 있습니다.

RISC는 변형된 80/20 법칙을 토대로 개발되었다.
즉 대부분의 소프트웨어가 실행시간의 80%를 전체기능의 20%만을 사용하는데 쓰인다는 것이다.

RISC 프로세서는 그 중요한 20%를 최대한 활용하고, 나머지 80%를 제거함으로써 칩 사이즈와 비용을 크게 낮추었다.


소프트웨어를 사용하는 사람들의 소프트웨어 사용빈도는 80/20 법칙을 따르고 있습니다.
1994년 MacWeek에 다음과 같은 내용이 있다고 합니다.

비즈니스 세계는 오랫동안 80/20 법칙을 따라왔다.

소프트에어의 경우, 제품 사용시간의 80%가 전체기능의 20%에만 집중되어 있다는 점에서 특히 그렇다.

이는 사용자가 필요로 하지 않고 원하지도 않는 부분에 돈을 낭비하고 있다는 것을 의미한다. 소프트웨어 개발자들은 드디어 이 사실을 깨닫고 이 문제를 모듈화된 응용 프로그램으로 해결하려고 하고 있다.

지금보다 10년 이전인 1994년에도 지금과 비슷한 생각을 했네요 ;-)
아직도 이 문제는 별로 해결된 것이 없나 봅니다. ㅎㅎ

다른 예를 한번 살펴보겠습니다.

워드퍼펙트(WordPerfect)나 다른 소프트웨어 개발자들은 어떻게 이 문제를 해결하는가?
먼저 개발자들은 사용자들이 가장 원하는 것이 무엇이고 그것을 어떻게 사용하고 싶어하는지를 파악한다.

이것이 80/20 법칙이다.

사람들은 프로그램 사용 시간의 80%를 기능의 20%만 사용하며 보낸다.
따라서 우수한 소프트웨어 개발자들은 자주 쓰이는 기능들을 가장 단순화하고 자동화하여 쓰기 쉽도록 한다.

사실 이 예가 저에게도 해당되는데요~ 거의 모든 소프트웨어를 사용하는 경우 아마 거의 20% 정도의 기능만 중점적으로 사용합니다. 따라서 가끔 수 많은 메뉴와 기능 리스트를 볼 때 과연 저 속에 내가 원하는 것은 무었일까? 라고 생각하게 됩니다.

그래서 출현한 것이 마이크로소프트사의 리본 메뉴(리본 형식의 메뉴)입니다.



마이크로소프트의 오피스 2007을 사용하는 사용자를 어리둥절하게 만들었던 리본이란 새로운 메뉴 스타일도 결국 수 많은 기능중에 사용자가 가장 많이 사용하는 기능에 초점을 둔 사용자 인터페이스(UI) 형식입니다.

사실 이 새로운 메뉴 형식은 아직도 논란이 많습니다.
특히 "사람의 뇌의 구조상 계층화하여 표현하는 것이 가장 효과적이다."라고 주장하는 쪽에서는 리본 메뉴는 체계도 없고 기준도 없는 엉터리 UI라고 혹평하고 있습니다.

사실 저도 기존 메뉴나 툴바 형태가 더 편하지 않았나 생각됩니다. 하지만 어느새 리본에 익숙해져가고 있네요..-.-
기존 툴바 및 메뉴 형식의 UI 역시 단점은 있어서 이렇게 될 수 있다는 점입니다.


거의 이렇게 사용하시는 분은 없으시죠 ;-)

이처럼 소프트웨어 분야에서는 활발하게 80/20 법칙을 적용하려고 노력하고 있습니다.

따라서 여러분들이 소프트웨어 개발자라면 지금 만들고 있는 소프트웨어의 핵심 기능이 무었인지 식별하여야 합니다. 그리고 식별된 가장 중요한 20%의 기능을 최대한 잘 만들기 위하여 노력하여야 합니다.


하지만 과연 소프트웨어 분야에서 80/20 법칙을 적용하는것이 말처럼 쉬울까요?

마이크로소프트 역시 리본 메뉴를 만들때 핵심 20%의 기능을 더욱 쉽고 편리하게 사용할 수 있도록 배려하기 위하여 만들었을 것입니다.

하지만 여기에 함정이 있습니다.

"과연 20%의 사용자란 누구를 지칭하는 것인가?" 라는 문제입니다.
만약 여러분이 MS처럼 소프트웨어를 만들고 있는 입장이라면 20%의 사용자를 어떻게 볼까요?

MS 워드 기준으로 살펴볼 때 MS 워드는 전 세계에 수 많은 사용자가 있습니다. 이것이 하나의 문제가 될 수 있는데요~ 동양권에서는 표를 자주 사용하지만 서양권의 문서에서는 거의 표를 사용하지 않습니다. 동양권에서는 이태릭체를 좀처럼 사용하지 않지만, 서양권에서는 많이 사용합니다.

이런 문화적인 차이를 생각해볼 때 과연 리본메뉴에 표 관련 기능은 어떻게 배치하는게 좋을까요?


이것이 20%의 함정입니다.
모든 사용자를 너무 일반화한다면 정작 중요한 사용자를 위한 기능을 놓칠 수 있습니다. 제가 읽은 나만의 80/20 법칙 만들기란 책에서도 이러한 일반화된 오류에 대하여 언급하고 있습니다.


약간 다른 이야기를 하면 최근에는 오픈소스 소프트웨어의 약진으로 인하여 소프트웨어 간의 기능상의 명확한 우위성을 확보하기가 어려지고 있습니다.

만약 MS Office가 없더라도 Open Office에 MS Office가 지원하는 기능의 거의 모든 것들을 제공하고 있으므로 크게 걱정하지는 않습니다. 다만 서로 호환문제 때문에 킬러 어플리케이션인 MS Office를 사용하고 있을 뿐입니다.

이미 경쟁 소프트웨어간 가장 중요한 20%의 기능은 대부분 수준이 비슷하다는 것입니다.

워드의 경우 표그리기, 스타일 정의하기, 폰트 지정하기 등등이 기본적인 20%의 기능은 제가 볼때 Open Office나 MS Office 모두 별 차이가 없습니다. 이미 20%의 핵심 기능은 모든 경쟁 소프트웨어가 충분히 갖추어져 있다는 것입니다.


이러한 문제에 관해서 우리에게 좋은 시사점을 던져주는 조엘 아저씨의 Strategy Letter IV: Bloatware and the 80/20 Myth란 글을 참고해 보시기 바랍니다.

간략하게 소개하면 다음과 같습니다.
만약 워드프로세서를 만드는데 20%에만 집중하여 개발하였다고 하자.

훌륭하게 동작하는 20%의 기능이 완성되어 이 워드프로세서를 판매하려고 하는데 한 작가가 "이 워드프로세서는 단어수를 셀 수 있나요?"라고 물었다.

당연히 20%의 기능에 없는 기능으로 워드프로세서에는 구현되어 있지 않았다. 하지만 작가 입장에서는 기고할 원고의 분량을 체크하기 위하여 반드시 단어수를 셀 수 있는 기능이 필요하였다.

과연 이 작가가 요구하는 기능이 20%의 핵심기능일까? 이 작가는 20%의 핵심적인 사용자일까?

여하튼 결론은 이 워드프로세서는 작가의 혹평을 받으며 팔 수 없었다는 것이다.

이것이 조엘이 이야기하는 80/20 법칙의 신화입니다.

소프트웨어에 있어 기능 관점에서 80/20 법칙을 적용시키기에는 무리가 따릅니다.

하지만 단위 테스트 관점에서 80/20 법칙을 적용시킨다면 많은 의미가 있을 것 같습니다. 경험상으로 가장 근본이 되는 에러를 해결하면 자연스럽게 나머지 에러가 해결되는 경우가 많았습니다.
단위 테스트에 대한 실제적인 사례나 통계를 한번 알아봐야겠습니다.


결론적으로 말씀드리면 80/20 법칙은 소프트웨어의 기능을 정의하고자 할 때 핵심적인 기능에 집중할 수 있는 논리적인 근거를 제공합니다.

하지만 현재의 소프트웨어 환경에서는 핵심적인 20%의 핵심 기능만 제공하기에는 무리가 따릅니다.

따라서 핵심적인 20%의 기능과 함께 80%의 특화된 기능을 제공하여 소프트웨어의 경쟁력을 높여야 할 때라고 생각됩니다.

그런 의미에서 롱테일 법칙도 좋은 논리적인 기반을 제공하여 준다고 생각됩니다. 나중에 한번 롱테일 법칙을 기준으로 소프트웨어를 바라보겠습니다.

80/20 법칙을 기본으로 소프트웨어를 개발하면서 80%로 자연스럽게 확장할 수 있는 방안을 마련한다면 매우 유익한 소프트웨어를 개발할 수 있을 것 같습니다.

이상입니다~ 감사합니다. ;-)

나만의 80/20 법칙 만들기란 책에서 많은 부분 참고하였습니다.
신고

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글  6개가 달렸습니다.
  1. 오.. 멋진글... 잘 읽었습니다.
    • 안녕하세요~ 짱가님~

      평소 조금씩 써나가다가 겨우 정리를 마쳤습니다. ^^;;

      잘 읽어주셔서 감사드리구요~ 오늘도 좋은 하루 보내세요~
  2. 잘 참고해서 좋은 소프트웨어 만들어 보겠습니다 ^^
  3. 재미있는글 잘 읽었습니다.
    제가 아는 파레토 법칙은 자연의 법칙을 발견한 것으로 알고 있습니다. 20%의 부자가 80%의 부를 가지거나, 원숭이가 타이핑을 하면 20%의 문자가 80%찍힌다거나, 산들의 높이, 낙엽의 색깔 등 자연적인 것은 8:2 법칙이 적용된다고 하더군요. 버그도 20%의 버그가 80%빈도로 나타나니 20% 버그만 잡아도 80%의 문제는 해결이 되는 것이겠지요. 그 상위 20%를 알아내는 것은 어렵지만요.
    • 네 맞습니다. 레이님 :)

      파레토란 분이 영국의 부의 축적에 관한 연구를 하면서 영국 뿐만아니라 거의 모든 유럽국가에서 부의 축적 비율이 20%의 사람들이 80%의 부를 축적하고 있다는 것을 확인하면서 파레토 법칙이 시작되었습니다.

      근데 중요한건 이 비율이 역사적으로도 계속 80/20 이었다는 것입니다. 옛날에도 그랬고 지금고 부의 축적은 80/20인것 같습니다.

      그래서 사람들이 부자가 되기 위하여 20%의 사람들이 어떻게 80%의 부를 축적하게 되었는지 관심을 가지게 된것 같습니다. :)

      소프트웨어도 마찬가지인것 같습니다. 아니 어떻게 보면 더 심하지 않나 싶습니다.

      전체 사용자의 80% 넘는 사용자가 20%도 안되는 소프트웨어만 사용하고 있는 것 같습니다.

      예를 들어 원도우 사용자가 전 세계 사용자의 80%가 넘는 것 처럼요~ :)

      좋은 글 남겨주셔서~ 감사합니다.
secret