태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

QA팀이 필요없다고?

2013/08/22 20:06 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




최근에 평가 자리에서 만난 유망하다는 스타트업의 대표의 이야기이다.


회사의 조직구조를 보니 테스트를 하는 팀이 보이지 않았다. 그래서 "QA팀이 없는냐"고 물어보니 "우리회사의 개발자들은 실력이 뛰어나서 테스트가 필요없는 프로그램을 만든다"라는 답변을 들었다. 그리고 본인(CEO)은 개발자들을 믿는다고 한다. (다른 회사는 믿음이 부족해서 버그가 생기나? ^^)


좀더 자세히 물어보니 내부에는 테스트인력이 없고 테스트를 고객이 해주는 것이었다. 삼성등의 대기업이 주 고객인데 패치도 자주 나갈뿐더러 고객이 테스트담당자가 있어서 패치가 나올때마다 꼼꼼하게 테스트를 해준다는 것이다.


사실 이런 얘기 하나만 들어도 회사가 얼마나 형편없는지 알 수 있다. 당장은 동작하는 소프트웨어를 만들어 낼 수는 있지만 그 이상은 택도 없을 것이다.


겉으로는 유망한 스타트업이고 Global Service를 준비중이며, 대규모 IR을 진행하고 있다고 한다. 그래도 꽤 유망하다는 스타트업이 이런 정도의 수준이라니 실망스럽기 짝이 없다.


회사의 품질관리를 고객에게 맡긴다는 것도 우습고 고객이 비용을 들여서 테스트를 해준다는 것도 우습다. 고객은 확인하는 정도의 Acceptance Test라면 말이 되지만 이렇게 같이 개발하는 형태의 개발은 세계적으로 유래를 찾아보기 어려울 것 같다.


이런 형태가 가능한 것이 스펙도 불확실한 상태에서 개발을 하다보니 고객과 개발사가 같이 으쌰으쌰하면서 개발을 한다. 주먹구구의 대표적인 행태이다. 이러다 보니 제대로 기획된 제품이 만들어지기 보다는 고객 담당자 취향대로 개발이 되곤 한다.


필자의 경험에 의하면 많은 회사들이 이 회사와 크게 다르지 않다. 또한번 갈길이 멀고 넘어야 할 산이 많다는 것을 느낀다.



저작자 표시 비영리 변경 금지

'프로젝트 > 품질관리' 카테고리의 다른 글

QA팀이 필요없다고?  (2) 2013/08/22
거의 다 만들었어요.  (8) 2013/02/27
고쳤으니 테스트 해주세요.  (4) 2013/02/18
우리는 개발자가 테스트해요.  (8) 2009/01/28

전규현 프로젝트/품질관리

Trackback Address: http://allofsoftware.net/trackback/319 관련글 쓰기
  1. "우리회사의 개발자들은 실력이 뛰어나서 테스트가 필요없는 프로그램을 만든다"
    뭔가 있어보이는 전형적인 개소리네요. ㅎㅎ
    고객이 테스트를 해준다니 조금 이해가 가지만, 고객이 할 테스트와 연구소내에서 할 테스트는 좀 구분이 되어야 겠죠.
    근데 저도 그런 형편없는 회사에 다니는 1인 이네요 ㅜ.ㅜ

  2. 그래서 우리 회사도 QA 뽑고 있습니다.. 좋은 글 감사 하하 :)

초등학생 코딩 교육을 보는 기대와 불안

2013/08/20 21:44 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



“초등학교 4학년부터 재미있고 쉬운 컴퓨터 코딩 교육을 받는다면 청년이 되어 코딩에 능숙한 전문가들이 늘어날 것이고, 그 중에는 스티브잡스와 같은 인재들이 나타날 수 있을 것이다.”

미래창조과학부에서 나온 말이다. 여기에 대해 “소프트웨어 개발에 대해서 알고나 하는 소리냐?”, “스트브잡스가 코딩 잘해서 성공했냐?”라고 따지고 싶은 생각은 없다. 예들 들다 보니 스티브잡스를 그냥 갖다 붙인 것이 아닌가 생각된다. 많은 사람들이 이 정책을 비난하고 있지만 나는 기본적으로 초등학생에게 코딩 교육의 기회를 주는 것을 찬성을 한다. 하지만 찬성하는 마음 못지 않게  어떤 식으로 왜곡돼서 진행될지 매우 걱정스럽다.


나는 초등학생 코딩 교육이 코딩 전문가를 늘리기 위한 것이 아니어야 한다고 생각한다. 선천적으로 뛰어난 논리력을 타고난 아이들을 찾아내고 컴퓨터와 소프트웨어에 대한 흥미를 유발하고 아이들의 창의력을 더욱 향상 시키는 것이 목적이 아닌가 생각한다. 김연아가 어렸을 때 스케이트를 타보지 않았다면 지금의 김연아가 없듯이 코딩 교육의 기회는 소질을 타고난 아이들을 찾는데 도움이 될 것이다.


정부에서 새로운 교육정책을 들고 나오면 먼저 불안감이 든다. 그 동안 신중하지 못하고 준비가 덜 된 교육 정책으로 여러 부작용을 야기해 왔기 때문에 이번에도 또 많은 문제가 생기지 않을까 우려하는 목소리가 크다.  이 정책을 통해서 아이들에게 컴퓨터와 소프트웨어에 대한 흥미를 유발하고 창의력이나 논리력을 키우는데 집중해야 하는데, 또 시험을 통과해야 하고 목표 점수를 얻고 등급을 높이는 방법으로 빠져들어 사교육만 배를 불리고 선행교육이 판을 칠 수 있다.


충분한 시간을 두고 우리나라 초등학생에게 알맞은 교육 도구가 개발된 후에 진행해야 하는데 또 날림공사 식으로 진행될까 걱정된다.


그럼 초등학생 코딩교육의 목적에 대해서 생각해보자.


초등학교 교육은 미래에 전문적인 교육을 받기 위한 기초가 된다. 그리고 기본적으로 사회를 건강하게 만드는 기반이기도 하다. 많은 사람들이 학교 다닐 때 과학과 수학을 어렵게 공부했는데 사회에 나와서는 하나도 써먹지 않아 시간 낭비 했다고 하는데 사실은 그렇지 않다. 어렸을 때의 교육은 지식을 익히는 것뿐만 아니라 논리적인 사고와 합리적인 생각을 하게 해준다.


미분, 적분은 직접 써먹을 기회가 없을 수도 있지만 자신에게 닥친 문제를 합리적이고 논리적으로 해결할 수 있도록 해준다. 비과학과 비논리의 오류에 빠져서 돈과 시간을 낭비하는 일을 줄여준다. 우리가 지금 너무 자연스럽게 생각하고 있는 것은 어렸을 때부터 받았던 교육과 경험의 결과이다.그럼 코딩교육은 어떨까?


100년 전에는 수학, 과학 교육이 거의 필요 없이 살 수 있는 세상이었다. 그럼 30년 후에는 어떨까? SF영화에도 종종 나오기도 하지만 상상하기는 쉽지 않다. 확실한 것은 컴퓨터가 지금보다 10배, 100배는 많이 쓰이는 세상이 될 것이다. 그런 세상에 합리적으로 살아가기 위해서 기본적으로 컴퓨터에 대한 이해와 논리력이 더 필요할 것이다. 교육은 시대의 흐름을 예측하고 대비해야 한다.


많은 초등학생이 잘 준비된 코딩 교육 기회를 접한다면 미래에 많은 소프트웨어 개발자가 생겨날 수도 있을 것이다. 그런데 그렇게 쉽게 기대하기에는 현재 우리나라 소프트웨어 업계는 너무나 매력이 없다. 소프트웨어 업계는 3D 취급을 받고 있고, Dreamless를 포함해서 4D라고 하기도 한다. 이런 바닥에 뛰어난 인재가 더 많이 지원할 리가 없다. 최근 10~20년간 소프트웨어 업계의 인기는 계속 추락해왔다. 대학의 소프트웨어 관련학과도 마찬가지이다.


소프트웨어 개발 일은 툭하면 야근에 부당한 대우에 사회적 인식은 바닥을 유지하고 있다. 좀 똑똑하다는 학생 중에서 미래에 개발자가 되고 싶다는 학생은 그리 많지 않다. 대부분 의사, 변호사가 되고 싶어한다. 코딩 선행 교육이 이런 문제를 해결해주지 않는다. 이런 와중에 소프트웨어 개발의 소질을 발견한들 소프트웨어 업계로 오겠는가? 근본적인 문제는 심하게 왜곡되고 뒤틀어진 소프트웨어 개발 환경이고 이를 개선해야 한다. 소프트웨어 업계가 일할만한 곳이란 비전이 보인다면 많은 인재가 지원을 할 것이다.


스티브잡스와 같은 인재가 탄생하기를 원하고 미래에 소프트웨어 인력이 많이 필요하다면 초등학생 코딩 교육보다 먼저 소프트웨어 업계를 정상화하기 위한 제도와 지원이 필요하다.


초등학교 코딩 교육은 어른들이 배우는 것을 흉내 낼 것이 아니라 논리력과 창의력을 키우는데 집중하고 재미있게 배울 수 있는 교육 도구들을 꾸준히 개발해야 할 것이다. 섣불리 어른이 배우는 것을 비슷하게 배운다면 흥미는커녕 오히려 지겨워할지도 모른다.


초등학교 코딩 교육 정책은 제대로 준비되고 꾸준히 투자가 이루어 진다면 30년 후에 우리나라의 중요한 국가 동력의 핵심이 될 수도 있을 것이다.


이 글은 제가 CNet Korea에 기고한 칼럼입니다. (http://www.cnet.co.kr)



저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/318 관련글 쓰기
  1. 코딩 교육 보다 더 확실한 해결책이 하나 있죠.

    개발자들 급여 능력만큼만 제대로 쳐주면... 능력 있는 인재들 많이들 몰려들 겁니다.

    물론... 개발뿐만 아니라 모든 분야가 그렇겠지만요.
    ㅋㅋ

    항상 좋은글 감사히 잘 보고 있습니다.

  2. 10살때 학원에서 c 배우고 너무 어려워서 트라우마가 생겼는데...
    대학와서 그거 극복하기 어찌나 힘들었는지..
    똘똘한 아이면 괜찮을까?
    그냥 보여주기 행정이 아닐까합니다.

  3. Blog Icon

    너무도 공감되는 글을 조리있고 읽기좋게 써주셨네요. 잘 읽고 갑니다.

인기없는 10년차 개발자

2013/08/14 15:28 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



우리나라에서는 나이 많은 개발자가 별로 인기가 없다. 10년~20년차 개발자들은 그들을 찾아주는 회사가 그렇게 많지 않아서 이직이나 진로에 대해서 항상 고민이 아닐 수 없다.


아직 경험이 적은 개발자들이 불만도 적고, 시키면 시키는대로 일하고, 매일 야근을 해도 버틸 수 있는 체력이 남아 있고, 돌봐야 할 가정을 아직 꾸리지 않은 개발자들이 인기가 많다. 이 개발자들도 곧 체력이 바닥나겠지만, 아직 남아 있는 체력을 쥐어짤 것은 남아 있다.


필자는 개발자가 제대로 아키텍트가 되고 제대로 실력을 발휘하려면 10년 이상은 개발을 해야 한다고 생각한다. 그래서 기술도 두루 셥렵하고 소프트웨어 공학에 대한 경험도 꽤 쌓고, 비즈니스와 경영도 이해하게 된다. 이렇게 제대로 성장한 10년차 개발자라면 일반 프로그래며 10명 이상의 가치가 있다.


하지만 우리나라의 많은 회사에서는 그런 아키텍트가 제대로 일할 수 없는 환경이거나 그들의 가치를 알아보지 못한다. 물론 좋은 회사도 있지만 그리 많지는 않다.


제대로 성장했을 경우 10년차 정도면 실력도 뛰어나고 체력도 남아있고, 아직 꿈도 있고 스타트업에 참여하여 모험을 해볼만하고, 큰 조직에서는 개발 조직의 중추적인 역할을 할 수 있다.


문제 중 하나는 이런 10년차 개발자 중에서 아키텍트라고 부를 수 있는 개발자도 현실적으로 그렇게 많지 않다는 것이다. 또한 그들이 아키텍트로 성장할 수 있는 환경이 아니라는 것이 더 문제다.


매일 불끄기와 야근에 시달리다보면 성장은 커녕 일에 치이고 해놓은 일들이 자신을 발목을 잡고 바쁘기는 하지만 매일 가치없는 일에 매달리고 앞으로 나아가기가 어렵다. 이런 챗바퀴가 우리나라 많은 고참 개발자들의 생활이다.


그 악순환의 고리를 하나씩 끊어가야 한다.




저작자 표시 비영리 변경 금지

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/317 관련글 쓰기
  1. 고리 끊고 싶습니다.

성숙한 개발문화 정착이 어려운 이유

2013/08/07 19:52 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





우리나라가 소프트웨어 개발을 잘하기 위해서 꼭 필요한 것 중에서 가장 먼저 성숙한 개발문화를 꼽는다. 그런데 간단해 보이는 것 하나도 정착하기가 보통 어려운 것이 아니다. 도대체, 개발문화가 왜 그렇게 정착하기 어려운지 그 이유를 생각해보자.

첫째, 문화란 혼자 바뀐다고 전체가 따라서 바뀌는 것이 아니다. 

문화란 집단의 공통된 행동 양식인데, 혼자서 전체를 바꾸기란 거의 불가능하다. 서로 이익이 된다면 자연스럽게 바뀌어 나가겠지만 대부분의 성숙한 개발 문화라는 것이 다같이 따를 때는 모두에게 이익을 가져다 주지만 혼자 제대로 하면 혼자 손해를 보기 마련이다. 정보를 공유하자고 해서 혼자 열심히 공유를 하고 다른 사람은 꼼짝을 안하면 혼자서 손해를 보는 것이다. 따라서 모두에게 이익이 되며 현재 수준에서 할 수 있는 것들로 조금씩 바꿔가지 않으면 거의 바뀌지 않는다.

둘째, 문화는 책으로 배우기 어렵다.

우리는 흔히 실리콘밸리의 개발문화를 전해 듣는다. 나이에 상관없이 소프트웨어 개발을 계속 할 수 있고, 나이 어린 팀장과 일할 수 있고, 공유와 리뷰가 활발하며, 이직이 활발하며 그래도 회사는 문제 없이 돌아가며, 개발팀의 기술적인 결정을 영업에서 함부로 뒤집지 않는다. 아키텍처를 고려한 장기적인 시간에서의 결정을 근시안적으로 뒤집지 않고 CTO가 CEO만큼 힘이 있다. 이런 얘기를 맨날 들어봐도 어떻게 해야 그렇게 되는지 알기는 어렵다. 결과만 보이지 상세한 행동 양식은 잘 보이지 않는다. 그래서 따라하려고 해도 따라하기 힘들다. 또한 쫓아 한다고 우리 의식 속에 깊이 자리잡은 우리의 문화를 무시하기도 어렵다.

셋째, 문화란 바뀌는데 오랜 시간이 걸린다.

문화는 짧게는 5년, 10년 이상 걸려야 바뀌는 것이 눈에 보인다. 그런데 우리나라에서는 아직 그정도의 인내심을 가지고 꾸준히 성숙한 문화를 정착하려고 노력해서 성공한 회사가 그렇게 많지는 않다. 중간 중간에 수많은 시행착오로 인해서 옆길로 빠지거나 포기하기 일쑤이다.

넷째, 단독으로 문화만 배울 수는 없다.

각 나라의 문화는 기후, 자원, 자연 등과 깊이 관련이 있다. 소프트웨어 개발 문화도 여러가지와 연관이 있다. 제도, 교육 상황, 산업 규모 등 수많은 것과 연관이 있다. 달랑 한 문화의 단면만 따라한다고 쉽게 되지는 않는다. 항상 기록을 남기는 방식으로 개발문화를 바꾸고 싶어도 기록을 남기는 것에 대해서 너무 훈련이 안된 개발자가 많다. 아키텍처를 중요시 하고 싶어도 뿌리깊은 영업 드라이브 문화는 쉽게 바뀌지 않는다. 따라서 우리의 현실을 무시한 성숙한 문화란 공염불에 그치곤 한다.

결론은 간단하지만 쉽지는 않다. 우리에게 알맞는 개발 문화를 찾아야 한다. 원칙을 거의 같지만 모습은 약간씩 다를 것이다. 그리고 혼자, 한 회사만 바뀌어서 될 일은 아니다. 업계 전체적으로 바뀌도록 노력해야 한다. 또한 5,년, 10년이상 꾸준히 노력해야 한다. 그래서 노력하는 사람이 대다수가 되면 이미 우리도 우리에게 알맞는 성숙한 개발문화를 가지게 될 것이다. 물론 10년안에 그렇게 바뀐다면 행운이고 30년이 걸릴지도 모르겠다.

image by Dawn Endico



저작자 표시 비영리 변경 금지

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/316 관련글 쓰기
  1. 슬쩍 링크를 겁니다.
    오늘 글은 명사 몇 개만 바꾸면 역사글이 될 수도 있네요.

공짜 점심이 개발자를 행복하게 할까?

2013/07/31 15:02 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



이글은 제가 씨넷코리아에 게재한 칼럼입니다. 새로 시작하는 씨넷코리아에 많은 관심 바랍니다.



최근에 국내 유수의 소프트웨어 회사들의 구조조정 회오리를 보면 착찹한 생각이 든다. 척박한 우리나라 소프트웨어 환경에서 참신한 개발문화를 도입하고 새로운 모습을 보여주려고 했던 회사들이어서 더욱 안타깝다.


필자는 이런 현상의 결과와 겉모습만 말고 다른 시각에서 좀 더 근본적인 원인을 살펴보고자 한다.


3D 취급을 받고 있는 국내 소프트웨어 개발자들은 잘나가는 실리콘밸리의 소프트웨어 회사들과 높은 연봉을 받는 소프트웨어 개발자들이 부럽지 않을 수 없다. 종종 그런 회사들의 끝내주는 개발 환경이 부러움을 사곤 한다.


공짜 점심, 자유 출퇴근 제도, 공짜 커피, 편안한 사무실, 환상적인 휴게실/오락실/수영장, 선택 가능한 재택근무 등이 그것이다. 물론 회사마다 다르기는 하다.


우리도 개발자들에게 이런 공짜 점심 등의 혜택과 환경을 제공하면 개발자가 행복해질까? 회사는 더욱 성과를 낼 수 있을까? 뛰어난 개발자들이 모여들까? 





단순히 겉모습만 따라 하는 것은 단기적으로 효과가 있을지 모르지만 장기적이고 근본적으로는 해결책이 아니다.


여기서 우리는 착각하는 것이 있다. 그들이 제공하는 끝내주는 개발환경은 공짜가 아니다. 개발자가 예뻐서 주는 것이 아니다. 그들의 환경, 개발 문화, 개발 프로세스에 맞게 가장 성과를 잘 낼 수 있는 환경을 제공하고 있는 것이다. 


사무실 주변에 식당이 널려 있는 우리나라와는 다르게 실리콘밸리에서는 차를 타고 점심을 먹으러 가거나 샌드위치를 사다 먹어야 한다. 매번 차를 타고 점심을 먹으러 가는 것은 엄청난 시간 낭비이기 때문에 회사에서 공짜 점심을 제공하는 것이 회사에 더 이익이다. 실리콘밸리 회사들은 공유의 문화를 기반으로 수많은 리뷰가 있고 얼굴을 보지 않고도 효율적으로 일할 수 있는 프로세스와 시스템이 갖춰져 있다. 재택근무와 자유 출퇴근을 통해서 뛰어난 개발자를 효율적으로 활용할 수 있다. 이런 끝내주는 환경은 개발문화와 프로세스가 맞물려 나온 결과물이지 목적은 아니다. 


우리나라에서는 환경은 전혀 그렇지 않은데 그 결과나 겉모습만 따라 하면 회사가 잘 되기는커녕 자칫 악화를 초래할 수도 있다.


내가 생각하는 개발자가 진정으로 행복하게 일할 수 있는 환경은 좀 다르다. 개발자가 합리적으로 일할 수 있는 환경이 행복한 개발자가 될 수 있는 환경이라고 생각한다.


합리적인 커뮤니케이션이 가능하고, 개발자의 기술적인 의견이 존중되고, 적절한 개발 일정이 믿어지고 보장되며, 필요한 적절한 리소스가 제공되며, 빈번한 요구사항 변경으로 수많은 야근과 아키텍처가 산으로 가는 일이 없고, 개발자의 노력에 대한 적절한 보상이 이루어지고, 개발자 경력이 보장되는 환경이다. 물론 개발자도 그렇게 할 수 있는 역량이 있어야 한다.


좋은 복지 조건은 뛰어난 개발자를 유치하는데 도움이 되지만 아무리 뛰어난 개발자가 있다고 하더라도 비합리적인 환경에서 일한다면 효율적으로 개발이 되지 않을뿐더러 회사가 어려워 지면 좋은 복지가 오히려 회사의 발목을 잡는다.


나는 공짜 점심을 주는 것보다 경영진이 소프트웨어에 대해 좀더 이해를 하고 아무 때나 함부로 요구사항을 바꾸지 않고 합리적인 개발일정이 받아들여지면 좋겠다. 나는 공짜 커피보다 더 빠른 PC와 개발에 꼭 필요한 기반시스템에 투자를 해줬으면 좋겠다. 그것이 개발자인 나를 더 행복하게 만든다.


실리콘밸리 회사를 따라 가려면 겉모습보다는 그들의 개발 문화를 먼저 따라 하자. 공짜 점심은 약간의 돈만 있으면 쉽게 제공할 수 있지만 개발 문화를 따라 하는 것은 그보다 10배 100배 더 어렵다. 결실을 보는데 시간도 훨씬 오래 걸린다. 개발 문화를 따라 하는 방법은 책을 보고 배우기 어렵기 때문에 제대로 하더라도 5년, 10년 이상 걸릴 일이다. 그들이 50~60년 걸쳐서 쌓아온 문화를 단시간에 따라 잡기는 어렵다.


많은 회사들이 중요한 개발 문화 중 하나인 공유 문화를 따라 하려고 했지만 대부분은 겉모습 흉내만 내다가 정착에 실패를 했다. 또한 문화의 핵심은 모른 채 겉으로 드러나는 기법들만 쫓다가 회의에 빠져들기도 한다. 이렇게 실패한 경우에는 시도하지 아니한 만 못한 경우도 많다. 이도 저도 아니고 어중간해서 더 혼란스럽게 된다.


나름대로 깨어 있다는 개발자들도 의욕은 넘치지만 자수성가로 성장한 탓에 동료들을 이끌어서 효율적인 개발문화를 정착시키기에 한계를 느끼고 좌절하기 일쑤다.


제발 겉멋들어서 겉모습과 기법만 따라 하지 말고 진짜로 개발자가 행복해 할 수 있는 환경을 만들어 보자. 그것이 처음에는 힘들고 더 오래 걸리더라도 제대로 될 길일 것이다.


가끔 왜 두루뭉술하게 얘기를 하고 구체적인 방법을 알려 주지 않냐고 하는 사람들이 있다. 이런 짧은 글로는 방법을 구체적으로 알려주는 것은 불가능하다. 태권도를 글로 알려줄 수 없듯이 개발문화도 실전 경험을 많이 한 선배들의 코칭을 받아 직접 몸으로 부딪혀 보고 경험해 봐야 하는 것이다.



image by mcdonalds.com


저작자 표시 비영리 변경 금지

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/315 관련글 쓰기

‘한국의 저커버그’가 양성되기 위한 조건

2013/07/29 09:05 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




교육기관이나 양성기관에서 배출할 수 있는 한계는 코더 또는 프로그래머이다. 굳이 정부 주도로 한국의 빌게이츠나 저커버그를 양성하지 않아도 한국의 소프트웨어 환경이 충분히 매력적이라면 머리 좋고 도전정신이 뛰어난 인재들이 뛰어들 것이고 그 중에서 빌게이츠나 저커버그 같은 사람도 탄생할 것이다.


이글은 제가 씨넷코리아에 게재한 칼럼입니다. 새로 시작하는 씨넷코리아에 많은 관심 바랍니다.


예전에는 한국의 빌 게이츠를 키워야 한다고 하더니 요즘은 스티브 잡스를 거쳐서 마크 저커버그를 키워야 한다는 목소리가 높다.  정부 주도의 한국판 저커버그 양성 프로젝트가 생기는가 하면 기업이 주도하는 시도들도 있다.  이런 시도들이 나쁜 것은 아니다.


프로그래머 인력을 키울 수는 있을 것이다. 하지만 빌게이츠나 저커버그 같은 사람이 탄생하는 데는 별 도움이 안될 것 같다. 과연 특수한 교육기관이나 양성 기관에서 그런 인물을 양성할 수 있을까?


그럼 한국의 빌게이츠, 저커버그를 양성하기 위해서 그들이 어떤 역량을 가지고 있는지 살펴보자. 물론 “인생 운칠기삼”이라는 말이 있듯 역량이 뛰어나기 때문에 빌 게이츠나 저커버그가 성공한 것은 아닐 것이다.


또한 그런 역량이 있는 사람이 무조건 성공하는 것은 아니다. 하지만 그런 역량을 가진 사람이 많이 배출될 수 있는 환경이 있다면 우리나라도 빌게이츠 같은 사람을 배출할 가능성이 높아질 것이다.


필자는 소프트웨어 개발자가 가져야 하는 역량 또는 소양을 8가지로 구분하여 비교를 해보았다. 비교 대상은 주변에서 흔히 볼 수 있는 일반적인 코더 또는 프로그래머, 경험이 많고 뛰어난 아키텍트 그리고 마지막으로 청년 시절의 빌 게이츠다.


비교 수치는 지극히 필자의 개인적인 의견이기 때문에 실제와는 차이가 있을 수 있으며 전체 맥락을 설명하기 위한 것이니 수치의 정확성을 가지고 논하지는 말자.


각 항목은 뛰어난 개발자 또는 아키텍트가 되기 위해서 필요한 역량과도 상당히 비슷하니 개발자라면 관심을 가져보자. 그럼 각 항목을 살펴보자


1. 창의력

남들이 생각하지 못하는 새로운 생각을 해내고, 문제에 봉착했을 때 참신하고 뛰어난 해결책을 찾아가는 능력이다. 단시간의 교육으로 배울 수 없으며 소프트웨어에 대한 지식뿐만 아니라 다양한 인문학도 창의력과 연관이 있다.


2. 논리력

소프트웨어 개발자에게 필수적으로 필요한 역량이다. 수학 교육과 다양한 논리 교육으로 향상 될 수 있으며 선천적인 지능에 크게 좌우된다. 이를 향상하기 위해서는 어렸을 때부터 오랫동안 꾸준한 교육이 필요하다.


3. 커뮤니케이션 능력

일반 코더에게는 그렇게 높은 수준이 커뮤니케이션 능력이 요구되지 않지만 뛰어난 아키텍트가 되려면 상당히 중요한 능력이다. 대화능력, 듣기능력, 토론기술, 대인기술, 설득능력, 인내력 등이 필요하다. 이런 능력은 암기식 교육환경에서는 키워지기 어렵다.  어렸을 때부터 토론식 교육 환경이 필요하며 능력을 키우기 위해서 시간이 매우 오래 걸린다.


4. 문서 작성 능력

가독성이 뛰어난 문서를 작성하는 기술이다. 일반적인 쓰기 능력, 정보 조직화 기술 등이 필요하며 일반 코더들이 가장 부족한 능력 중 하나이다. 십 수년의 학교 교육을 통해서 기초를 다져야 하며 실전 개발을 통해서도 오랫동안 단련해야 향상되는 능력이다.


5. 컴퓨터, 소프트웨어 지식

소프트웨어 동작원리, 자료구조, 알고리즘, 개발언어 등 개발의 기초 지식이다. 대학의 소프트웨어 관련학과에서 주로 가르치는 것이고 단시간에 기초를 닦을 수 있고 독학도 가능하며 실전 개발을 통해서 꾸준히 습득하는 지식이다. 단기적이고 집중적인 학습이 가능하다.


6. 코딩 능력

누구나 아는 코딩 파워다. 일반 코더의 능력을 구분하는 기준이며 그 능력차이는 코더마다 천지차이다. 다른 부분에 비해서 상대적으로 단기적인 교육의 효과가 있다.  우리나라 프로그래머들이 별로 떨어지지 않는 능력이다.


7. 소프트웨어 공학 경험

소프트웨어를 빠르게 개발하기 위한 공학적인 지식과 경험이다. 소프트웨어 분석, 설계, 소스코드관리, 이슈관리, 테스트, 프로세스, 툴, 개발문화 등 광범위한 영역의 경험이 필요하다. 학교에서는 배우기가 거의 불가능하며 제대로 된 개발환경에서 실전 개발을 통해 배워야 하며 매우 오랜 시간이 걸린다.


8. 도전정신

소프트웨어 개발자에게 꼭 필요한 역량은 아니지만 빌게이츠나 저커버그를 양성한다고 하면 필요한 정신이다. 타고난 유전자가 큰 영향을 미치며 주변 환경에 영향을 받을 수 있다. 단기적인 교육으로 향상하기는 어렵다.


이 중에서 교육기관이나 양성기관에서 단기적으로 키워서 효과를 볼 수 있는 분야는 소프트웨어 지식이나 코딩 정도이다. 나머지는 어렸을 때부터 꾸준히 키워야 하거나 실전 개발을 통해서 배워야 하는 것이다. 인위적이고 단기적인 교육으로 빌게이츠나 저커버그를 만들어낼 수 없다는 것은 자명하다. 인문학을 조금 더 가르치는 것도 새발의 피일 뿐이다.


교육기관이나 양성기관에서 배출할 수 있는 한계는 코더 또는 프로그래머이다. 굳이 정부 주도로 한국의 빌게이츠나 저커버그를 양성하지 않아도 한국의 소프트웨어 환경이 충분히 매력적이라면 머리 좋고 도전정신이 뛰어난 인재들이 뛰어들 것이고 그 중에서 빌게이츠나 저커버그 같은 사람도 탄생할 것이다.


직업훈련소 같은 학원을 세울 것이 아니고 불합리한 소프트웨어 업계를 바로잡는 제도와 법률을 손보고 도전하는 청년 창업자를 지원하는 것이 좋겠다. 그렇게 소프트웨어 생태계를 건강하고 매력적으로 만들어야 우수한 인재들이 모여들고 소프트웨어 환경은 더욱 좋아질 것이다.



저작자 표시 비영리 변경 금지

전규현 사람과 기술

Trackback Address: http://allofsoftware.net/trackback/314 관련글 쓰기

결국 최고 걸림돌은 경영진이다.

2013/06/19 16:17 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




소프트웨어 회사가 제대로 개발 역량을 갖추는데 최고의 걸림돌은 소프트웨어에 대한 이해가 부족한 경영진이다.


일반 경영자들이 소프트웨어를 이해할 수 없기 때문에 CTO가 존재한다. 하지만 우리나라 대부분의 소프트웨어 회사에는 CTO가 없거나 있다고 하더라도 CTO역할을 하지 않고 있다.


흔히 벌어지는 심각한 문제는 프로젝트 기간 아무때나 요구사항을 변경하고 심지어는 소프트웨어 기획의 방향을 완전히 뒤엎곤 한다. 이로 인해서 소프트웨어 개발에는 어떠한 일들이 벌어지는지 모르는 듯하다.


알파 버전이 출시된 이후에 아키텍쳐를 뒤흔들만한 기능을 추가하도록 하는 경우도 있다.


자동차를 개발하면서 양산 직전에 휘발유차를 디젤차로 바꾸자는 소리를 하는 사람은 아무도 없을 것이다. 그런데 소프트웨어 회사에서는 경영진의 개인적인 주관으로 이런 요구를 하곤 한다.


관리적인 측면에서도 문제가 생긴다. 관리자와 개발자의 차이를 구분하지 못하고 고참 개발자는 무조건 관리를 해야 하는 것으로 생각한다. 전문 개발자는 30년이 지나도 관리는 전혀하지 않고 개발만 하는 것이다. 그러나 이렇게 개발 경력이 보장이 되는 소프트웨어 회사를 우리나라에서 찾는 것은 그렇게 쉬운 일이 아니다. 아무리 개발이 하고 싶고 관리는 적성에 맞지 않아도 우리나라에서 개발을 하는 이상 관리 업무에 대한 압박은 떠나지를 않는다.


또한 합리적인 관리를 할 수 없으니 무조건 일정을 쪼는 일 밖에는 하지를 않는다. 그러다 보면 아키텍쳐는 형편 없어지고 개발 문화는 뒤쳐질 수 밖에 없다.


몇몇 경영자는 이러한 현상이 개발자들이 제대로 못해서 그렇다라고 핑계를 댈 수는 있다. 닭이 먼저냐 달걀이 먼저냐의 이슈 같아 보이지만 강자인 경영자가 바뀌는 것이 우선이다.


이러한 문제점의 고리를 끊을 수 있는 사람은 개발자가 아니라 경영자이다.

문제의 핵심도 경영자이고 이를 해결할 수 있고 해결 해야 하는 사람도 경영자이다.



image by Zolli07



저작자 표시 비영리 변경 금지

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/313 관련글 쓰기

SRS를 개발 후에 연습하는 차원으로 적어보면 도움이 되지 않을까?

2013/06/03 23:37 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것은 SRS(Software Requirements Specification) 즉, 스펙을 잘 작성하는 것이다. 


그럼 SRS 작성법을 배우고 싶은데 어떻게 해야 할까?

남이 작성한 SRS를 보면 도움이 될까? 

가상으로 한번 써보면 도움이 될까? 

케이스별로 얼마나 도움이 될지 알아보자.


1%


스펙을 작성하는 방법을 배우기 위해서 남이 작성한 SRS를 보는 것은 얼마나 도움이 될까?

1%정도 밖에 도움이 안된다.

남이 치는 피아노, 골프를 보고 얼마나 도움이 될지 생각해보면 된다. 작성한 SRS의 내용이 그러게 도출되는 과정을 겪지 않고 결과만 보는 것은 1%밖에 보이지 않는다.


10%


그럼 실제 프로젝트에 적용하기는 어려우니 가상의 프로젝트를 생각해서 작성하면 어떻게 될까? 10% 정도는 도움이 될 수 있다. SRS에 포함된 수많은 내용 중에는 실제 상황이 아니면 도저히 생각해 낼 수 없는 부분들이 많다. 이런 부분은 가상의 프로젝트에서는 배우기 어렵다.


30%


이미 끝난 프로젝트의 SRS를 적어보는 것은 어떨까? 나중에 혹시 유지보수에 도움이 되지 않을까? 별 도움이 되지 않는다. 

SRS는 원래 개발하기 전에 개발을 빠르게 하기 위해서 적는 것이다. 이미 종료된 프로젝트라면 적을 수 없는 부분이 많다. 또한 꼼꼼하게 적지도 않게 된다. 미리 적는 SRS처럼은 절대로 적을 수가 없다.

이미 코딩까지 끝났기 때문에 창의적인 생각이 필요한 Interface 등은 제대로 적기 어렵다. 현재 상태를 Reverse Engineering으로 적는다고 해도 깨끗하게 적을 수 없을 뿐더러 뒤죽박죽이라서 적어봐야 아무 의미 없는 경우가 대부분이다. 또는 SRS를 작성하면서 필요한 커뮤니케이션 스킬, 분석 능력, 인터뷰 능력 등은 전혀 익힐 수가 없다. 이러한 것을 빼고 내용만 일부 Dump하는 것은 Template을 익히는 것밖에 기대하기 어렵다.


100%


SRS 작성하는 법, 스펙을 작성하는 법, 요구사항을 분석하는 법을 제대로 배우려면 크던, 작던 실제 프로젝트에서 SRS를 적어봐야 한다. 어떠한 프로젝트도 SRS의 모든 챕터를 다 커버하는 것은 없다. 따라서 하나의 프로젝트에서의 경험은 상당히 제한적이다. 오랜 기간동안 여러 프로젝트의 SRS를 작성해봐야 배울 수 있다.


따라서 일단 실제 프로젝트에서 작성해보는 것이 가장 좋은 방법이다. 물론 피아노를 코치없이 배울 수 없듯이 경험이 많은 선배나 전문가의 도움을 받는 것은 꼭 필요하다.


image by Nuwandalice

저작자 표시 비영리 변경 금지

전규현 프로젝트/요구사항분석

Trackback Address: http://allofsoftware.net/trackback/312 관련글 쓰기
  1. 개발 경력을 꽤 되는데 SRS 는 적어 본 적이 없는 SRS 초보자입니다.

    지난 번 SRS 강의를 들으며 나름대로 이해(or 오해 ^^) 한 바가 있는데요.

    SRS 는 템플릿이 아니고 "글을 잘 써야 한다" 는 말씀에서 느끼는 바가 있어서요.

    요즈음은 "나는 기술자가 아니라 소설가이다" 라는 자기 최면을 걸어 놓고 '나름 SRS(?)' 쓰는 걸 시도하고 있습니다.

    맥락을 전혀 모르는 독자들에게 내가 고민 했던 것, 하고 싶은 말을 충실히 적는 글짓기 연습부터 하고 있는 셈이지요.

    문장력이 좀 생기면 그때 가서 템플릿에 맞추어 볼 생각입니다.

    우리 회사 개발자들은 제 '나름 SRS'에 시큰둥 하고요.

    마케팅/기획 쪽 분들은 아주 좋아 하시더군요. ^^

내가 없어도 회사가 잘 돌아가면 왠지 불안하다.

2013/05/28 23:59 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





그동안 이래저래 바쁘다는 핑계로 블로그에 글을 못올리고 있다. 앞으로 짧막하게라도 글을 올리려고 한다.


내가 만약 일주일동안 회사를 안나오면 회사가 잘 돌아갈까?

그럼 한달동안 안나오면 어떻게 될까?


대부분의 소프트웨어 회사는 한달동안 심지어는 일주일만 직원 몇명이 안나오면 심각한 문제를 일으키곤 한다.


이러한 종속성은 회사에게는 큰 위험이고 개발자에게는 양날의 검이다.


개발자는 본인이 없으면 회사가 잘 안돌아가는 상황을 선호하곤 한다. 실제로 우리나라에서는 개발자들이 자리를 지키기 위한 좋은 수단이 되기도 한다.  하지만 개발자가 좀더 중요하고 새로운 일을 하는데 발목을 잡히곤 한다.

물론 내가 없어도 회사가 쌩쌩 잘 돌아가는 상황이 매우 불안한 사람도 있을 것이다. 또한 그렇게 합리적으로 돌아가지 않는 회사도 있으니 잘 판단해야 한다.


개발자 뿐만 아니라 Operating에서도 문제는 벌어진다. 특정 직원이 없으면, 빌드나 팩키징을 못하거나 라이센스 발급이 안되는 경우도 있다. 업무는 특정인만 아는 형태로 진행되어서는 안되고 메뉴얼이 필요하고 백업이 가능해야 한다.


회사 입장에서는 리스크일 뿐만 아니라 이런 현상이 벌어지고 있다는 것 하나만 봐도 소프트웨어 개발 전반에 많은 문제가 있다는 것을 짐작할 수 있다.


첫째, 많은 정보, 지식이 특정인 머리 속에 들어 있고 시스템화 되어 있지 않다는 것을 알 수 있다. 또한 리뷰를 통한 공유가 잘되어 있지 않은 것이다.


둘째, 스펙이 제대로 작성되어 있지 않은 것이다.


세째, 개발 프로세스가 제대로 구축되어 있지 않은 것이다. 그 외에도 문제가 많다.


회사는 어떠한 개발자라도 한달 동안 또는 영원히 사라져도 문제 없이 돌아가는 상황이 되어야 한다. 이렇게 하기 위해서 프로세스, 스펙/설계, 기반시스템, 개발 문화를 제대로 구축하는 것이 부담이 된다고 생각하는 경우도 있다. 이는 무조건 주먹구구가 더 빠르고 효율적이라고 주장하는 것과 같다. 초 단기적으로는 주먹구구가 더 나을 수는 있지만 이런 상황은 오래 지속되지 않는다.


특정 개발자가 없어도 잘 돌아가는 환경은 개발자에게도 유리하다. 그래야 개발자는 과거의 일에 발목을 잡히지 않고 합리적으로 일할 수 있는 환경이 된다.


이를 검증하기 위해서는 개발자에게 휴가를 한달씩 줘 보면 된다. 개발자에게 한달짜리 휴가를 줄 수 있는 회사가 되어보자.


image by  Kenzoka







 

저작자 표시 비영리 변경 금지

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/311 관련글 쓰기
  1. 전규현님께서 쓰신 글의 맥락하고는 좀 벗어나는 것 같긴 한데요.

    이 묘한 현상의 근본적인 원인이 무얼까 생각해 보면 일종의 "권력의 문제"가 아닐까 싶습니다.

    그리고 "권력의 문제" 보다 더 깊은 심층에는 '화이트 칼라' vs '블루 칼라' 의 정체성 혼란이 아닌가 생각했던 적이 있습니다.


    일반적인 회사에서 화이트 칼라 커리어 패스를 타는 사람들은 관리자로 성공할 사람들이라서 자신이 실무에서 벗어나는 것을 너무 당연하게 생각합니다.

    반면 블루 칼라 커리어 패스를 타는 사람들은 노동조합의 보호를 받기 때문에 한 달간 휴가를 보내주면 "땡큐~" 하고 갔다 오겠지요.


    그런데 한국의 개발자들은 화이트 칼라인지 블루 칼라인지 애매합니다.

    일은 블루 칼라처럼 일하는데, 화이트 칼라와 같은 사무실에 앉아서 일하며 관리자 자리를 놓고 화이트 칼라와 경쟁을 하는 처지에 있지요.

    당연히 이 경쟁은 게임이 되지 않을 것이기에 개발자가 취하는 선택은 '나 나가면 회사 망해 !' 라는 벼랑 끝 전술이 되는게 아닌가 합니다.


    화이트 칼라도 아니고 블루 칼라도 아닌 개발자들의 생존을 위한 본능이라고나 할까요 ?

  2. 좋은 의견입니다. 우리나라 상황에서는 이러한 현상을 이해해야 겠군요.

    개발자는 지식노동자로서 Technical career path가 보장되어야 합니다. 일반 블루칼라와는 약간 다른 것 같습니다. 우리나라에서는 거의 블루칼라 취급되는 곳이 많은 것 같습니다.

    회사가 어려워지면 관리자를 짤라도 개발자 특히 아키텍트는 절대로 자르지 않죠. 먼나라 얘기.

    그런데 여기에 정치가 개입되면 완전히 얘기가 달라지는 군요.

    우리나라 개발자들은 정치도 배워야 하는 것이 안타깝습니다.

  3. Blog Icon

    비밀댓글입니다

넣는 것 보다 빼는 것이 더 어렵다.

2013/05/14 23:29 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





초창기에 좋은 소프트웨어로 성공하는 업체들이 지속적으로 성장하지 못하고 고전을 면치 못하는 이유는 여러가지가 있다. 그중 하나가 제품이 점점 과도하게 비대해지는 것을 꼽을 수 있다.


성공하는 회사들의 초기 제품은 간략하고 핵심적인 기능으로 사용자들의 요구를 만족시켰다. 하지만 시간이 흐를 수록 경쟁상대가 많아지고 선두를 유지하거나 따라잡기 위해서 제품은 기능은 경쟁 제품들의 모든 기능을 다 포함하기 시작하곤 한다.


고객이 많아질수록 고객들의 요구사항도 다양해지고 하나의 고객도 놓치기 싫어서 가능하면 모든 요구사항을 신제품에 다 우겨 넣으려곤 하다.


이렇게 온갖 기능이 다 포함된 제품을 우리는 "Kitchen Sink"라고 한다. 설거지통에 닦아야 할 그릇들이 잔뜩 쌓여 있는 모습을 상상해보라.


기본적으로 영업은 한명의 고객도 놓치기 싫어서 무조건 고객의 요구사항을 다 들어달라고 요청을 한다.


이것을 조정해서 새로운 제품의 전략을 수립하는 부서는 마케팅부서이다. 하지만 내 경험에 의하면 우리나라의 많은 소프트웨어 회사들은 마케팅보다 영업에 가깝다. 소프트웨어 제품 전략에서 중요한 것은 많은 기능을 넣는 것보다 얼마나 적은 기능으로 최대한의 고객을 만족시키느냐이다. 경쟁제품을 모두 조사해서 슈퍼세트의 제품을 기획하는 일은 쉽다. 어려운 일은 기능을 빼는 것이다.


기능을 빼는 과정에서 기존의 고객을 잃을 수도 있다. 하지만 이것이 두려워서 "Kitchen Sink" Software를 만든다면 더 큰 것을 잃을 수도 있다. 


하지만 많은 사람들이 기능을 빼는데는 익숙하지 않다. 영업, 마케팅은 물론이고 마음씨 좋은 개발자들이 기능을 빼는 것을 주저하기도 한다. 그러면 제품의 아키텍처는 점점 복잡해지고 회생 불가능한 상태가 되곤한다.


스펙을 적을 때도 지원할 기능 외에 뺄 기능도 잘 기술해야 한다. 스펙에 지원하지 않을 기능을 적는 것은 지원할 기능을 적는것보다 더 중요할 때가 많다. 물론 모든 미지원 기능을 적는 것이 아니고 기존에 있던 기능을 빼거나 누구나 능히 포함될 것으로 생각하는 기능을 뺄때는 꼼꼼히 적어줘야 한다.


그래서 마케팅팀의 역할이 더욱 중요하다고 할 수 있다.


1%의 사용자도 쓰지 않는 수많은 기능을 개발하느라고 개발 비용은 훨씬 많이 들어가고 프로젝트가 망가져가는 것을 흔히 볼 수 있다. 중요한 것은 넣은 것이 아니고 빼는 것이다.


image by Kingfox





저작자 표시 비영리 변경 금지

전규현 프로젝트/요구사항분석

Trackback Address: http://allofsoftware.net/trackback/310 관련글 쓰기
  1. 저는 하위버전 호환성을 유지하는 것이 매우 중요하다고 생각합니다.

    고객사에서 제품을 상위버전으로 업그레이드 했을 때 서비스가 안되는 부분이 생긴다면 이는 재앙에 가깝습니다.

    조엘이 쓴 책에서도 MS 가 하위버전 호환을 유지하기 위해 얼마나 노력을 많이 했는지 언급되었던 것으로 기억합니다.

    새버전 출시 시 마케팅 자료나 영업자료에서 그 기능을 삭제하는 것은 가능하지만 제품에서 물리적으로 삭제가 되는 것은 아니라고 생각합니다.

  2. 공감합니다.

    소프트웨어 업그레이드 시 하위호환을 유지하기 위해서 많은 노력을 들이게 됩니다. 정말 잘 설계를 해서 꾸준히 하위 호환성을 유지하기도 하고 Migration 기능을 제공하기도 합니다.

    여기서 지적하는 것은 기존의 기능을 무작성 빼자는 것이 아니고 전략적인 생각없이 경쟁 회사들의 기능과 특정 고객이 원하는 기능을 잔뜩 포함해서 키친씽크를 만들지 말자는 얘기입니다.

    하위호환성을 유지하면서도 기존 기능을 없애거나 새로운 형태로 진화시키는 일은 종종 있습니다. 결국 기획팀에서 전략을 제대로 수립해야 겠죠.

21C 韓 SW개발자는 16C 조선 陶工 처지

나의 취미 중 하나는 도예 즉, 도자기 만들기다. 우연한 기회에 시작해서 10년을 넘게 도자기를 만들었으며 도자기 역사나 도자기 기술에 대해서도 많은 공부를 하게 되었다. 그런데 요즘 우리나라의 소프트웨어 산업 환경이 조선..

외국 개발자들이 보기에 군대 같은 한국 회사

“A기업은 좀비월드 같다. 직원들이 아무 생각 없이 회사를 떠돈다.” “B기업 직원들은 불만을 말하지 않는다. 근무 내내 감옥에 있는 느낌이다.” “C기업은 군대다. 상사가 말하면 무조건 따라야 한다. 이유를 묻거나 질문할..

쓸데없는 회의를 줄이는 방법

'회의가 많은 회사는 곧 망한다'는 속설이 있다. 다른 분야에서도 마찬가지지만 개발자도 회의에 많은 시간을 빼앗기면 개발에 집중하기 어렵고 이는 개발 생산성 저하로 이어진다. 꼭 필요한 회의는 해야 하지만 과도한 회의는 줄여..

한국의 개발자는 쓸데없이 바쁘다

한국의 개발자들은 항상 바쁘다. 소프트웨어 개발을 하느라고 바쁜 것이 아니라 쓸데없는 일에 바쁜 것이 문제다. 회사마다 차이는 있지만 많은 회사에서 개발자들은 본연의 개발 업무보다 불필요한 다른 일에 바빠서 정작 본연의 임무..

구멍가게 될텐가? 글로벌 SW기업 될텐가?

나는 소프트웨어 스타트업 및 중소기업 관계자를 자주 만난다. 주로 소프트웨어 개발이나 마케팅 전략에 대해서 얘기를 한다. 최근에도 몇몇 기업의 대표를 만났다. 대부분의 기업들은 국내 시장에만 머무르지 않고 해외로 진출해서 글..

나는 한달 동안 휴가를 갈 수 있을까?

내가 만약 한달 동안 휴가를 간다면 회사에서는 무슨 일이 벌어질까? 각자 한번 상상을 해보자. 내가 있던 없던 상관없이 회사는 잘 돌아갈까? 아니면 내가 관련된 일들이 진행되지 않아서 회사가 마비가 될까? 내가 없으면 회사가..

편한 개발환경이 가져온 부작용

필자는 개발자를 채용할 때 인터뷰 시 칠판을 이용한 코딩 테스트를 꼭 실시한다. 아무리 화려한 이력을 가지고 있다고 하더라도 코딩 테스트를 통과하지 못하면 채용하지 않는다. 코딩 테스트 문제는 정말 간단하다. 숫자를 문자로..

인원 늘면 꼬이는 SW개발문화의 현주소

꽤 오래 전 TV에서 혼자서 무인 자동차를 개발하고 있는 한 대학 교수의 이야기를 본 적이 있다. 20년째 혼자서 연구를 하고 있었고 조금씩 개량해서 그 당시 한적한 국도를 혼자서 달릴 수 있는 수준이었지만 복잡한 도로에서는..

SW교육, 프로그래밍이 핵심 아니다

메르세데스벤츠의 CEO 디터는“이제 자동차는 기름이 아닌 소프트웨어로 달린다”고 말했다. 앞으로의 산업에서 소프트웨어가 차지하는 중요도를 단적으로 나타내는 말이다. 과거 전세계 제조업시장에서 1등자리를내주었던 미국이 세계 최..

개발 경쟁력과 실속없는 화려한 보고서

몇 년 전 A사에서 있었던 일이다. A사가 그동안 진행했던 프로젝트를 경영진에게 보고하기 위해서 직원들이 보고서를 만들 때였다. 그런데 직원들 보고서가 최소 1주일 전에 완성 되어야 한다는 것이다. 경영진이 보고서를 매우 까..