태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

내가 개발에 집중할 수 없는 이유

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



우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다.
정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다.

그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다.

원래는 이렇게 개발자가 다해야 하는 상황은 One Man Company에서나 벌어지는 상황이어야 한다.
하지만 작은 벤처 기업이나 거대한 대기업이나 개발자가 수십명이나 또는 수백명 있어도 One Man Company에서 벌어지는 상황과 별반 다르지 않다.

그럼 왜 개발자는 개발에만 집중해야 하는가?
소프트웨어 개발이라는 것이 다른 일도 해가면서 적당히 해 나간다고 해서 잘할 수 있는 분야가 아니다. 개발만 10년, 20년을 집중해야 잘할 수 있는 분야다.
개발 외에 다른 일도 다 하면서 개발도 잘한다고? 그러면 정말 천재이거나, 자기 자신을 과대평가하거나, 지금은 그럭저럭 잘하기는 하지만 개발에 집중했으면 더 잘했을 경우 일 것이다. 

그럼 어떠한 일들이 개발자들이 개발에 집중하지 못하게 하는가?

첫째, 마케팅의 부재다.

우리나라에서는 대부분 제품 비전만 툭 던져 놓고 나머지는 다 개발자가 알아서 해야 한다.
개발할 제품이 딱 정해지면 Architecture 연구하고 Technology 공부하기 바쁜 개발자가, 고객 인터뷰도 해야 하고 경쟁회사 동향도 파악해야 하고, 회사에서 서로 다른 얘기하고 있는 사람들 다시 만나서 제품의 비전부터 다시 정해야 한다.
또, 마케팅은 온갖 요구사항 다 합쳐 놓은 Kitchen sink를 가져다주고 기획이라고 하는 경우가 많다. 결국 개발에 실패를 하기도 하고 개발을 했어도 가치가 없는 제품을 만들게 된다. 결국 고생은 개발자가 다하고 욕도 개발자가 다 먹는다.

둘째, 다음은 Technical support의 부재이다.

개발자가 가장 잘 안다는 이유로 개발자가 기술지원을 해야 한다.
가끔은 고객 사이트에서의 장애에 대한 사과를 하러 개발자가 직접 방문을 해야 한다. 이유는 고객이 화가 나서 개발자가 직접와서 사과를 하지 않으면 안된다고 영업이 주장하기 때문이다. 밖에서 발생한 모든 문제의 책임을 직접 개발자 돌리는 것이다. 코미디가 아닐 수 없다. 
영업은 이런 제스처를 취함으로써 모든 책임을 개발자에게 돌리는데 성공을 했다. 정상적인 영업이라면 이런 터무니 없는 요구는 애초에 막았어야 하는 것이다.
설령 개발자가 1차적인 책임이 있다고 하더라도 이런 일로 개발자가 사과를 한다는 것은 회사에게 훨씬 더 큰 손해를 끼치게 된다. 
이렇게 밖으로 내둘리는 개발자는 개발 실력보다는 남 비위 맞추는 실력이나 늘고, 소프트웨어 개발에 염증을 느끼게 된다.

셋째,  QA의 부재 또는 부족이다.
 
QA담당자가 없는 경우가 많고 제대로 된 기획, 스펙 없이 개발을 하다보니 제품의 기능을 개발자밖에 몰라서 개발자가 테스트를 하는 경우가 많다. 심지어는 팀장, 기획자 등 여러 관련자들이 다 테스트에 동참하는 경우가 있다. 이는 전문성을 무시하는 것이고 아주 작은 회사에서나 있을법한 일이다.

개발자는 개발하기도 바쁘고 할 일도 많다. 또한 마케팅, 기술지원, QA는 잘 하지도 못한다.
개발자는 개발에 집중해야 밥값을 하는 것이다. 다른 일을 하느라고 개발할 시간이 부족하다면 …

이럴 때 개발자는 경영자에게 꾸준히 주지 시켜야 한다. 대부분의 경영자는 소프트웨어에 대한 이해도가 낮아서 개발자가 왜 개발에 집중해야 하고 조직이 전문화 되어야 하는지 잘 모른다. 그러기 때문에 경영자가 알 수 있도록 설득해야 한다.
CTO가 있다면 이런 일은 벌어지지 않고 이런 일이 벌어진다고 해도 CTO가 다른 경영자를 설득하여 이를 해결해 줄 것이다.
그래서 개발자는 좋은 환경을 찾아가야 한다는 것이다. 연봉을 약간 많이 주더라도 제대로 일하고 성장할 수 없는 환경이라면 개발자에게 그리 좋은 직장은 아니다.   

즐겁게 개발하면서 개발자로 크게 성장하고 개발자로서 가치를 높이고 개발자로 은퇴하고 싶다면 개발자가 일할만한 직장에서 일해야 한다. 

우리나라에서는 이러한 회사를 찾는 것이 쉬운 일이 아니다. 물론 나의 미션 중의 하나가 좋은 소프트웨어를 만드는 것이고, 개발자가 일할만한 소프트웨어 회사가 점점 늘어날 것을 기대한다.

image by  SnoShuu

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

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/244 관련글 쓰기
  1. 개발 입장에서는 영업은 할줄도 모르는게 어디서 주워들은것만 많아서 입만 놀린다고 무시할수밖에 없고
    영업으로는 주워들은건 많아서 눈만 높아지고, 자기가 죄송하다고 하기에는 자기가 만든게 아니니 개발에게 떠넘기고.. 그게 가장 근본적인 문제가 아닐까 싶어요.

  2. 구차니님 오랫만입니다.

    이 모든 것을 한마디로 얘기하면 전문성 부족입니다. 어떻게 보면 개발자도 포함해서 말입니다. ^^

  3. Blog Icon
    김정열

    좋은 글... 매번 잘 읽고 있습니다.
    공감...

  4. 이제 막 개발계에 입문한 풋내기 신입니다.
    경력자 로써의 개발실력을 쌓기전에 뭔가 올바른 개념을 잡아가면서
    공부할수 있게 되는것같아 좋은글들 써주셔서 감사하게 생각합니다.

    아무리 시간없어도 하루에 한번씩 1개의포스팅을 읽을 예정입니다.
    앞으로도 잘 부탁드리겠습니다^^ 감사합니다.

  5. 안녕하세요. UYEONG님

    읽는 속도에 따라잡히지 않으려면 저도 하루에 하나씩 포스트를 해야 하는 것 아닌지 모르겠습니다. ^^

  6. Blog Icon
    신성욱

    공감 지수 100 입니다.

  7. Blog Icon
    숙취

    잘읽었습니다. 제품을 기획하고, 경쟁사 제품들을 리서치하여 공유하고...프로토타이핑 하여 내부 시연하고, 설계하고...개발(코딩)하고.. 통합테스트 여러번을 거치고.. 고객에게 데모 준비하려 밤새고.. 직접 데모하고.. PoC, BMT있으면 준비하며 밤새고..직접 수행하고..제안서 작성 도와야 되고...제품 팔리면 고객사에 볼모로 잡혀가고...욕먹고...버그리포팅 직접 등록하고 직접 해결 및 close처리하고...프로젝트 오픈에 맞춰서 같이 밤새주고..시간날때 코딩하고..

    이런 생활 5년 넘었습니다. ㅎㅎㅎ

우리에게 지금 필요한 것은? 바로 이것

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




우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은
"기초 체력"이다.

히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다.
그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내놔도 뒤지지 않을만큼 뛰어나지만 골결정력 등 섬세한 고급 기술들이 부족하다고 생각했었다.

하지만 히딩크는 이를 전면 부정하고 고등학교 축구팀처럼 기초 체력 훈련에 집중했다. 주변의 반대가 심했지만 강행했다.
그리고 월드컵에서 그 결과를 보았다. 경기 후반 다른 나라 선수들이 지쳤을 때 우리 선수들은 한발 더 뛸 수 있었고 승리로 이어졌다.

우리나라 개발자들은 개인기들은 뛰어나다. 즉, 코딩을 잘하는 개발자도 많고 온갖 지식도 많이 안다.
솔직히 이 정도로 많이 아는 개발자들은 전세계적으로 찾아보기 어렵다. 그럼에도 세계적인 소프트웨어 회사가 우리나라에 없고, 세계적인 제품을 찾아보기 어려운 것은 기초 체력이 부족하기 때문이다.

개발자들이 많이 아는 지식은 혼자서 배우고 익힐 수 있는 것들이다. 이것은 노력하는 개발자라면 누구나 다 잘 한다.
하지만 기초 체력은 혼자서는 절~대로 배울 수 없는 것들이다. 대부분 잘 갖춰진 개발문화를 가진 SW회사에서 몇년씩 일하면서 자연스럽게 배울 수 있는 것들이다. 그렇게 쌓은 기초 체력을 갖춘 개발자들이 버글버글 해야 그들이 뭉쳐서 좋은 소프트웨어도 만들고 그중에서 세계적인 소프트웨어도 나올 수 있다.

그런 좋은 환경에서 배울 수 있는 기초 체력코딩도 아니고 Domain 지식도 아니다.
아래와 같은 것들이다.
  • 소프트웨어 개발에 있어서의 개방의 문화
  • 리뷰 문화
  • 공유 문화
  • 협업 문화
  • 신뢰의 문화
  • 효율적인 개발 프로세스
  • 소스코드 관리 기법
  • 이슈 관리 기법
  • 빌드/릴리즈 기법
  • 테스트
이런 것들이 몸에 베어 있어야 한다. 몸에 베이지 않고 지식으로만 알고 있는 것은 막상 시행하려고 할 때 제대로 실행하기 어렵다. 엉뚱한 방향으로 흘러가서 이상하게 되어 버린다.

또 기초 체력에 해당하는 것들은 비싼 툴을 쓰고 정교한 세계 최고의 방법론, 프로세스를 도입한다고 해서 나아지지 않는다. 오히려 방해가 되는 경우가 많다.  그런 비싼 툴과 정교한 프로세스를 그것을 필요로 하는 곳이 따로 있는데 맞지도 않는 것을 쓰게 되면 반감만 커지게 된다.

툴은 꼭 필요하지만 환경에 맞게 필요한 툴과 적절한 프로세스가 필요한 것이다. 그 기반하에서 문화가 꾸준히 쌓이게 된다. 

이런 기초 체력이 뒷받침 되어야 다음과 같은 고급 역량이 생기기 마련이다.
  • 분석 역량
  • 설계 역량
  • 기술 전략 수립
단어만 놓고 보면 우리도 다 하는데라고 생각할지 모른다.
이는 태권도 10급이 태권도 9단에게 나도 태권도 할 줄 안다고 하는 것과 비슷하다.
Global 하게 경쟁 좀 하려면 4,5단은 되어야 하는데 우리나라에서 유단자 찾기 어려운 이유가 기초 체력을 먼저 갖추기 어려운 환경에서 일하기 때문에 이런 고급 기술은 닦을 시간도 없고 방법도 모르기 때문이다.

그래서 내가 중요하게 생각하는 것이 개발 환경을 먼저 바꿔 놓는 것이다.
기본적으로 이슈관리시스템, 소스코드관리시스템만 제대로 사용해도 반쯤은 바뀐 것이다.

이런 시스템들을 쓰면 우리가 눈치 채지 못하지만 여러가지 원칙, 프로세스를 저절로 배우게 된다. 수십년간 수많은 SW회사들의 성공하는 방법이 녹아 있는 것이 그런 시스템, 툴 들이다.

따라서 이들을 원칙 그대로 사용만 해도 많은 것을 얻게 된다. 기존의 방법과 다르다고 툴을 무시하고 또는 이상하게 변형하면 99.9% 잘못된 방향으로 가고 있는 것이다.

그리고 빌드, 테스트, 리뷰 등등을 하나씩 갖춰나가면 어느덧 꽤 효율적인 조직의 모습을 갖출 것이다.

이때 나타나는 조직의 모습은 다음과 같다.
  • 회사의 모든 개발 이슈가 투명하게 Open 된다.
  • 모든 업무의 커뮤니케이션이 원활하며 이런 것에 시간 낭비 하지 않는다.
  • 모든 소스코드는 공개가 되어 있고, 협업이 원할하다.
  • 숨어서 개발하는 개발자는 더이상 존재하지 않는다.
  • 경영자와 관리자는 개발 진행 상황을 한눈에 파악하고, 각 개발자들의 업무 진행 상황을 쉽게 파악한다.
대부분은 이쯤에서 만족할 수 있을지도 모르겠다.
하지만 여기까지는 진짜 "기초 체력"이다.

국내 대회에서는 꽤 상위권에 오를 수 있다. 하지만 월드컵에 나가면 한 골 넣기도 어렵다.
이제 "고급 역량"이 필요할 때다.

분석/설계/기술전략 등의 "고급 역량"은 단기간에 배울 수도 없다. 그렇다고 혼자 방법과 길을 알아서 익힐 수도 없다. 그렇게는 너무나 오래 걸려서 은퇴할 때가 될 것이다.
"고급 역량"은 이미 "고급 역량"을 갖춘 선배, 동료들과 진짜 프로젝트를 수행하면서 몸으로 익히는 것이다.
어느정도 방법과 길을 아는데는 몇개월 안걸리지만 진짜 역량이 높아지는데는 5년, 10년이 걸리고 20년이 지나면 또 역량이 올라간다.

우리나라 많은 개발자들이 관리 쪽을 기웃거리다가 또 유지보수에 시달리다가 20년 쯤 지나면 이도 저도 아닌 상태와는 많이 다르다.

기초 체력을 익히는 첫걸음은 기초 체력이 부족하다는 것을
인정하는 것이다. 스스로를 인정하지 않으면 바뀔 수 없다. 이렇게 환경부터 하나씩 고쳐나가야 한다. 

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

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/247 관련글 쓰기
  1. Blog Icon
    yanu27

    말씀하신 저런 회사를 정말 찾고 있고, 들어가고 싶은데 안 보이네요.
    또 저렇게 환경을 만들려고 노력하는 회사 찾기도 쉽지 않고요.
    저런 노력하는 사람이나 회사 정말 알고 싶습니다.

  2. Blog Icon
    아리수

    저희회사요.ㅎㅎ
    소스코드나 이슈관리는 하고 있는데
    리뷰에 대해서는 사람들이 아직 잘 못받아들이네요.
    "나를 못믿냐?" 뭐 그런 생각들이 있는듯...

  3. 전 좀 답답한게, 어휘력 때문에 고생합니다. 엣말에 콩떡처럼 얘기해도 찰떡처럼 알아 듣는다고... 그게 소통이 잘되고, 죽이 잘 맞고, 팀웍이 좋은 것처럼 착각하는게 일을 더 어렵게 만듭니다.
    말이나 글을 좀 더 정확하게, 의사전달을 명확하게 하는 노력을 계속 해 나가야 하는데...
    "개발자는 코드로 말한다" 라는 명제 때문인지, 의사전달의 정확성에 대한 노력은 별로 하지 않는 것 같아, 아쉽습니다.

  4. 안녕하세요. 디밥님

    정확한 의사전달은 가장 어려운 것 중 하나입니다. 그 어려운 정도는 상상을 초월합니다.

    그래서 스펙을 쓰는 것이 가장 어려운 일입니다.

  5. Blog Icon
    조인중

    기초 체력이 중요하다는 점에는 절대적으로 공감합니다.
    하지만 우리나라 소프트웨어 생태계가 심하게 오염된 탓에,
    개발자들이 그런 기초 체력을 쌓을 기회가 없다는 게 문제라고 생각합니다.

    경영 환경이 열악한 중소/벤처 기업들은 경력이 없는 개발자를 채용하여 문화를 만들고 기초 체력을 키워 줄 "회사의 체력"이 없습니다. 그리고 대기업들은 중소기업 빨아먹기에 여념이 없어서 개발자를 키울 생각조차 하지 않구요.

    결국, 지금 살아남은 소프트웨어 회사들이 그런 일을 해줘야 하는데,
    그런 회사들도 정말 쓸만한 고급 개발자가 별로 없어서, 결국 역량이 없는 경우가 대부분입니다.

    참 답답하지만, 여기서 할 수 있는 말은 하나밖에 없겠네요. (김형태 님이 하신 말씀입니다.)
    "남 탓, 시대 탓, 환경 탓하는 것만큼 구제불능의 바_보는 없습니다."

    결국 내가 그런 사람이 되어야 하는데, 그게 참 쉽지 않네요. :-)

  6. 안녕하세요. 조인중님 (내 후배 조인중인가?)

    그 책임의 대부분은 회사에 있죠. 개발자들은 피해자죠. 심한경우 성장의 기회는 없이 피나 빨리는 거죠. ^^

SW개발자 블랙홀

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




중소기업, 심지어는 중견 기업들도 SW개발자를 뽑기 정말 힘들다.


신입은 물론 경력직도 구하기 어렵다.

몇년전부터 소프트웨어 경쟁력이 이슈화되면서 대기업들이 SW개발자들을 블랙홀처럼 빨아드리고 있는 것이 그 중요한 원인 중 하나이다.

이러한 현상은 비단 중소기업 뿐만 아니라 장기적으로 보면 SW생태계에도 좋은 영향을 끼치지 못하고 SW개발자들에게도 별 도움이 안된다.

그 이유는 대기업들이 SW 경쟁력 확중을 인원 확충과 같은 것으로 착각하고 있기 때문이다. 심지어는 중소기업 밥그릇을 뺏기 위해서 중소기업들이 주력하던 분야에 진출해서 관련된 개발자들을 데려가서 중소기업을 고사시켜서 시장을 뺏어 오기도 한다. 

중소기업, 중견기업을 다니는 많은 개발자들은 어려운 근무여건과 불안한 미래 때문에 대기업으로 옮기기를 선호하는 경향이 많다. 또한 대기업에 가면 체계적인 프로세스와 뛰어난 방법론 등 SW 개발에 대해서 뭔가 더 배울 수 있지 않을까 착각들을 한다.

하지만 막상 대기업으로 자리를 옮겨보면 자신들의 기대는 큰 착각이었다는 것을 깨닫곤 한다. 대부분의 대기업 SW조직은 작은 회사가 여러개 있는 것과 별반 다르지 않고 SW공학적인 능력은 중소기업보다 뒤쳐지는 경우도 많다. 

따라서 제대로된 소프트웨어 회사에서 10명이면 할 수 있는 일을 100명이 하는 경우도 있다. 이렇듯 대기업은 많은 개발자들을 빨아들이지만 개발자들을 효과적으로 활용하지도 못하고 개발자들의 역량을 제대로 키워주지도 못하고 있다. 그렇다고 딱히 다시 돌아갈 작고 좋은 SW회사들이 많지도 않다.

SW산업에 있어서 좋은 생태계는 다음과 같은 것이라고 생각한다.

좋은 토양에서는 대기업에서 체계적인 개발 방법을 배우고 좋은 아이디어가 생기면 창업을 하던지 작은 기업으로 옮겨서 자신의 생각을 펼쳐 보는 것다. 이 과정에서 대기업과 중소기업이 서로 협력하고 전체 파이를 키워야 서로 상생할 수 있다.
  
몇몇 대기업들이 상생을 외치고 있지만 구호로만 끝날지는 지켜볼 일이다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by 
 thebadastronomer

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

전규현 소프트웨어이야기 대기업, 채용

Trackback Address: http://allofsoftware.net/trackback/237 관련글 쓰기
  1. 무턱대고 대기업으로 가는 건 비추입니다.
    NHN이나 삼성에서 많이 뽑지만 정원은 크게 변하지 않았다고 들었습니다. 그만큼 많은 인원이 회사를 떠납니다.
    위에 두 기업말고도 s/w사업으로 대기업이라 불릴만한 기업들 상황은 대강 비슷한 것 같습니다.

    규현님 말씀처럼 대기업이라고 프로세스가 굉장히 뛰어난 것은 아닙니다. 과거에 같이 일해보았던 CMMI 5레벨 인증했다는 국내 굴지의 SI기업도 분석/설계한 내용을 산출물로 만든다기 보다 문서따로 개발따로의 프로젝트를 하더군요. 모든 팀이 다 그렇지는 않겠지만 현실적으로 어느 팀으로 지원을 하냐에 따라 명암이 갈리는 것 같습니다.

  2. 안녕하세요. 김철진님

    그래도 우리나라에서는 안정적인 직장을 원하는 사람들이 많은 것 같습니다. 이직률을 감안하면 그렇게 안정적인 직장도 아니죠.

사업부의 한계

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



우리나라 많은 기업들이 선택하고 있는 사업부제는 단기적인 성과를 내기에는 유리하나 장기적인 관점으로 보면 문제가 많다.

물론 사업부제 자체의 문제를 말하는 것은 아니다. 우리나라에서 사업부가 어떻게 동작하는지를 보면 된다.

사업부는 사업부내에 모든 기능 조직을 포함하여 마치 하나의 회사처럼 동작을 하며 모든 전략, 매출 등을 책임지고 물론 그 성과에 대한 보상도 사업부가 누리는 것이다.

얼핏 들으면 아주 그럴듯 하지만 사업부의 이익과 회사의 이익이 상반되는 경우는 대단히 많다. 이런 경우 사업부에서는 회사 전체의 이익을 따르지 않는다.

그럼 소프트웨어 쪽으로 포커스를 해보자. 사업부제에서 소프트웨어 개발을 담당한 부서가 쪼개져서 각 사업부로 흩어지게 된다. 그러면서 전사적으로 소프트웨어 역량이 많이 떨어지게 된다.
  • 전사적으로 일관된 소프트웨어 전략을 구사할 수 없다.
  • 사업부간 소프트웨어 지식이 공유되지 않는다.
  • 사업부간 인력의 왕래가 자유롭지 않다.
  • 소프트웨어는 하드웨어의 부속물로 전락하는 경우가 많다. 특히 사업부의 장이 하드웨어 출신인경우이다.
  • 단기적인 이익에 급급해서 소프트웨어 아키텍처는 크게 신경쓰지 못한다.
  • 전사적인 큰 그림은 그리지 못한다.
이런 체제에서는 위에서 지시하면 뭘 빨리 만들어 내기는 하지만 흉내만 낼뿐 금방 밑천이 드러나게 된다.

사실 기업의 경영자들이 이러한 것을 모르는 것이 아니다. 그래서 기업의 조직 구조는 수시로 바뀌지만 인내심이 부족한 경영자들은 금방 다시 사업부제로 돌아온다. 그래도 그럴 것이 대기업의 최고 경영자들도 6개월, 1년안에 눈에 띄는 성과를 내지 못하면 자리를 보존하기 어려운 환경에서 그렇게 하기란 쉬운 일이 아니다.

많은 대기업들이 소프트웨어 역량을 향상하고 싶다면 소프트웨어 조직을 분리를 해야 한다. 사업부에서는 반대를 하겠지만 우선 가능한 부분부터 소프트웨어 조직을 통합하여 좀더 전문적이고 장기적인 관점으로 투자를 해야한다. 단기적인 성과에 집중하는 전략의 폐해는 이미 드러났다. 

이것이 변화가 가능한 중소, 중견 기업에 기대를 거는 이유이다. 

 * 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by 
Steven Vance
저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기

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

왜 소프트웨어에서 실패를 할까?

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




많은 회사들인 하드웨어보다는 소프트웨어에서 더 실패를 많이 한다. 사실 우리나라의 여러 산업분야에서 하드웨어는 이미 세계최고 수준에 이르렀다. 그런 회사들 조차 낙후된 소프트웨어 역량 때문에 경쟁력을 잃곤 한다.

그 이유는 무엇일까?

첫째, 하드웨어는 제대로 설계를 하면서도 소프트웨어 설계는 아예 없거나 엉성하기 그지 없다. 

소프트웨어는 인류가 만들어낸 모든 지식 산업 중에서 가장 복잡하다고 한다. 그럼에도 불구하고 우리나라에서는 소프트웨어 만큼 엉성하게 만드는 것도 없다. 
작은 집을 만들던, 빌딩을 만들던간에 설계 없이 만드는 것은 없다. 하다못해 작은 장난감도 잘 만들어진 설계가 필요하다. 그럼에도 소프트웨어는 설계없이 만드는 경우가 허다하다.

사실 하드웨어는 제대로 설계를 하지 않으면 아예 동작하지 않는다. 하지만 소프트웨어는 대단히 소프트하다는 착각에 대충 만들어서 통합이 안되거나 동작을 잘 안하면 조금씩 고쳐서 해결 할 수 있을 것으로 생각한다. 하지만 이는 대단한 착각이다. 하드웨어는 만들어 놓고 쓰다가 망가지면 버리면 되지만 소프트웨어는 한번 만들어 놓은 아키텍처가 생각보다 오래가고 나중에 발목을 잡게 된다.

또한, 하드웨어는 고객이 원하는대로 마음대로 변경해주지 않는다. 하지만 소프트웨어는 쉽게 바꿀 수 있다는 착각하에 고객마다 다른 제품을 만들어서 제공하는데, 이런 회사들은 대부분 미래에 유지보수를 감당하지 못하게 된다. 

공공 입찰의 경우 제대로된 스펙과 설계서를 요구하긴 하지만 대부분 페이지 수만 채운 형식적인 것이고 실제 개발에 제대로 쓰이지 않는다. 결국 개발자들이 머리 속으로 설계를 해서 개발하는 것이 일반적이다.

이렇게 해서는 당장 제대로 만드는 것을 떠나서 미래에 벌어지는 수많은 문제들을 점점 키우게 된다.

둘째, 소프트웨어는 완전히 다른 기업 문화를 요구한다.

하드웨어는 몇몇 천재가 기가막힌 물건을 만들어 낼 수 있다. 물론 하드웨어 분야도 수많은 사람들의 협업으로 돌아가지만 소프트웨어와는 사뭇 다르다.

소프트웨어 개발은 거의 모든 단계에서 대단한 협업이 필요하다. 또한 수평적인 조직 문화가 필요하다.

윗사람이 지시하고 이를 따르고 보고하고 통제하는 문화로는 절대로 소프트웨어를 제대로 개발할 수 없다.
자율적으로 판단하고 공유하고 리뷰하고 능동적으로 대처하는 문화가 필요하다. 관리자가 철저히 통제하고 관리하는 문화는 이를 저해하게 된다.

세째, 소프트웨어를 잘아는 경영자가 필요하다.

많은 사람들이 소프트웨어는 하드웨어를 동작하는데 도움을 주는 부수적인 부품으로 생각한다. 이런 하드웨어적인 마인드로는 소프트웨어를 절대로 잘 개발할 수 없다. 소프트웨어를 담당하고 있는 경영자라면 소프트웨어를 매우 잘 알고 제대로 된 소프트웨어 경험이 많아야 한다. 그래야 소프트웨어 전략을 수립할 수 있다. 

축구를 해본적도 없는 관중 수준의 사람에게 축구 감독을 맡길 수는 없다. 

안타까운 것은 우리나라는 소프트웨어 분야에 있어서는 너무나 갈길이 멀다는 것이다.
다행인 것은 많은 사람들이 소프트웨어에 관심을 가지기 시작했다는 것이다. 냄비처럼 확 끓었다가 식는 것이 반복하지만 않았으면 좋겠다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by 
pt
저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/233 관련글 쓰기
  1. 2011/08/21 22:22
    소프트웨어, 비관적이라고? 과연 그럴까? Tracked from Robbin의 퍼블리싱 이야기
  1. 세째, 소프트웨를 잘아는 경영자가 필요하다.

    소프트웨 -> 소프트웨어

  2. 감사합니다.

  3. 하드웨어도 버그가 있습니다.
    물론 소프트웨어 보다 벤더 및 종류가 적고 생산량이 큰 사업이기 때문에 그 영향이 작지만요.
    그러한 버그를 제품 드라이버와 OS가 감안하고 동작하고요.
    인텔 칩셋 드라이버 등에 그러한 내용들이 다수 포함되어 업데이트 됩니다.

    사람이 만든 건 100% 완벽할 수 없기에 갈고 닦는 건 SW건 HW건 필수인가 봅니다. ㅎㅎㅎ

    글 요지에 영향이 없는 부분이지만 댓글 달아봅니다. 언제나 좋은 포스팅 감사합니다.

  4. 안녕하세요. 김충환님

    맞습니다. 하드웨어를 하는 사람들은 더 설계를 잘하는 것이 하드웨어에 버그가 생겨서 교체를 해야 하는 경우는 비용이 엄청나게 들기 때문인 것 같습니다.

    그런데 소프트웨어는 버그가 있으면 나중에 쉽게 고쳐주면 된다고 생각합니다.

    또한 하드웨어 디자인 체계는 이미 오랜 시간 정립이 되어서 규약, 프로세스, 툴, 마인드 등 이미 상당 수준입니다.

    소프트웨어는 특히 우리나라는 하드웨어에 비하면 낙후되어 있습니다.

    소프트웨어를 하는 사람들도 하드웨어의 마인드를 좀 배워야할 것 같습니다.

  5. Blog Icon
    csj

    돈이라고 생각합니다
    우수한 인력이 왜 소프트웨어 개발을 하겠습니까 다 의전원 로스쿨 가죠..
    일이 힘들다 해도 그만큼 돈을 많이 주면 해결될 문제죠
    문제는 위에서 그럴 생각이 전혀 없다는거..

    결국 싸구려 인력으로 외국 유명한 프로그램을 흉내낸 싸구려 프로그램만 만들거고
    경쟁에서 뒤쳐져서 언젠가 훅 가겠죠
    모바일 OS만 봐도 개발 인력이 없다고 난리치는데, 누가 미쳤다고 돈 도 안되는 OS를 하고 있겠습니까
    이런 건 정부에서 미리미리 투자해서 키워야 하는데..

    최근 과제를 하는데 소프트웨어 우습게 보는데 참 짜증나더군요
    그거 얼마면 만들겠다 하는데 참..
    돈은 90%를 다 가져가면서 뭘 그리 기대하는지 -_-;;
    한 번 크게 당해봐야 정신 차릴겁니다.
    그때 가서 울면서 난리치겠죠

  6. 미국에서는 거의 매년 소프트웨어 개발자가 의사, 변호사를 제치고 소득 상위를 차지합니다.

    그만큼 경쟁력이 있고 돈이 돌기 때문에 연봉도 높습니다. 우리나라도 소프트웨어 경쟁력이 있고 돈이 되면 돈을 많이 주고라도 소프트웨어 개발자를 모셔올 겁니다.

    갈길이 멀죠.

  7. Blog Icon
    Phil

    다년간 미국생활을 통해 깨달은 점은 소프트웨어에 대한 시민의식 수준입니다.

    게임하나도 구매를 통해 플레이하는 문화랑 일단 다운로드받고 시작하는 문화, 미국에서 불법다운로드했다는 말은 하는 건 나 마리화나 핀다는 말보다 더 꺼내기 어렵죠.

    하나의 소프트웨어를 만들때 들어간 그 인력의 노력과 자본을 소중히 여길줄아는 문화가 먼저 형성이 된다면

    기업문화역시 항상그래왔듯이 금새 따라갈겁니다.

    그래서 교육이 중요한거죠.

  8. Blog Icon

    비밀댓글입니다

  9. 감사합니다. ^^

  10. 위에서 하신 말씀에 전적으로 동감합니다. ^^

    조금 더 의견을 덧붙이자면...

    분석/설계 과정에서 정확하게 요구사항을 도출하지 못하거나 잘못된 해결책을 선택하는 경우도 많아서
    개발이 한참 진행된 후에 문제가 붉어지는 것도 소프트웨어가 실패하는 원인 중에 하나인 것 같습니다.

    그리고 필요 이상으로 개발 기간을 당겨서 잡는 것도 한 몫하구요. ^^;;;
    (무리하게 일정을 당기면 품질에 문제가 있는 것을 매번 경험하면서도 반복하는 건...
    문제가 있다고 생각합니다)

    좋은 글 잘 읽고 갑니다. ^^

삼성이 M&A를 통해서 이번에는 소프트웨어 경쟁력을 갖출 수 있을까?

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



필자가 1년반쯤 전에 쓴 삼성의 소프트웨어 경쟁력에 대한 글을 보면 새삼 감회가 새롭니다. 요즘 한창 이슈가 되고 있는 M&A 등의 이슈를 다루고 있다. 단순한 상황 뿐만 아니라 방법도 제시를 하려고 했었다.
아래는 해당 글들이 있다.

2010/01/05 - [소프트웨어이야기] - 삼성은 왜 소프트웨어를 잘 만들지 못할까?
2010/01/23 - [소프트웨어이야기] - 삼성이 바다를 출시해서는 안되는 이유
2010/02/08 - [소프트웨어이야기] - 삼성이 앞으로도 소프트웨어를 잘 만들 수 없는 이유
2010/03/02 - [소프트웨어이야기] - 삼성이 소프트웨어 분야에서도 최고가 되려면?

삼성이 왜 소프트웨어 경쟁력이 부족하고 어떻게 소프트웨어 경쟁력을 갖출 수 있는지 나름대로 방법을 제시했었다. 특히 3/2 글에서는 좀더 실패를 해서 소프트웨어 중요성을 더 깨달아야 한다고 했었는데 좀더 실패를 경험한 모양이다.

그 때 제시를 했던 것이 크게 두가지였다.

첫째,
소프트웨어 회사 M&A이다. 물론 국내 소프트웨어 회사는 아니다. 국내의 다른 소프트웨어 회사와 비교하면 삼성의 소프트웨어 역량은 차라리 높은 편이다. Global한 경쟁이 안된다 뿐이지 국내에서는 잘하는 셈이다. 그도 그럴 것이 우수한 소프트웨어 인력 싹 쓸이 해갔고 그동안 효율적이지는 않지만 소프트웨어에 물질적으로 엄청난 투자를 해왔기 때문이다. 그럼에도 글로벌 Software회사와는 엄청난 차이를 보이고 있는 것은 어쩔 수 없다. 심지어는 몇명이 뭉쳐서 만든 실리콘밸리의 스타트업 회사보다 개발 문화나 역량 면에서 못한 것은 안타가운 일이다.

둘재,
소프트웨어를 잘아는 전문 경영인들을 확보해야 한다. 이들이 조직내에서 밀리지 않도록 꾸준한 지원도 필요하다. 그동안 소프트웨어 전문가들이 있었음에도 조직내에서 제 목소리를 내지 못하고 단기적인 비즈니스 논리에 밀려서 제대로 힘을 못써왔고 많이들 밀려나고 말았다.

그럼 이번에는 삼성이 제대로 소프트웨어 역량을 강화할 수 있을 것인가? 궁금하지 않을 수 없다. 

삼성이 이토록 소프트웨어 역량 강화에 관심을 가지는 이유는 살아남기 위해서이다. 진작부터 여런 산업 분야에서Hardware보다 Software 비중이 점점 높아지고 있었는데 공룡 조직의 느린 움직임으로는 이를 따라 잡지 못하고 있었다. 연일 신문에서는 소프트웨어를 떠들지만 사실 단어로서 의미 이상을 느끼고 있는지 모르겠다. Hardware 중심으로 마인드가 박힌 조직이 단시일내에 바뀌기란 불가능하다. 

최고 경영층에서 M&A를 강조하고 있기 때문에 뭔가 사기는 살 것이다. 하지만 M&A를 통해서 절대로 사올 수 없는 것이 있다. 바로
"Soft적인 기업 문화"이다. 소프트웨어 역량을 갖추기 위해서는 "Soft적인 기업 문화"가 필요한다. 삼성과는 너무나 거리가 멀다. 

지금 Hardware는 잘하고 있는데 Software가 부족해서 "사온다"의 의미로는 이미 너무나 부족해졌다.

필자는
"삼성의 상당한 조직은 완전히 Software적으로 재편되어야 한다"고 생각한다. 이는 삼성 뿐만이 아니다. 이제 상당히 많은 산업 분야가 Software가 중심이고 Hardware는 부가적인 것이 이미 되었고 점점 더 가속화가 되고 있다.

M&A를 통해서 핵심 기술과 특허를 사올 수는 있지만 이는 "공룡에 분칠"하는 정도일 것이다. 지금 필요한 것은 대대적인 조직문화 탈바꿈이고 이를 이끌 수 있는 "수혈"이 필요하다. 수혈은 소프트웨어 전문 경영인을 말한다. 물론 몇몇 우수한 소프트웨어 전문 경영인들이 있기는 하지만 조직에 비해서는 너무나도 적은 인원이고 더 큰 힘도 필요하다. 지금 바뀌지 않으면 기회가 없을지도 모른다.

안타까운 것은 이러한 시도가 너무나 무모해 보이기도 한다. 이러한 변화를 기존 조직의 기득권층이 과연 받아들이고 융합이 될 것인가? 필자는 어렵다고 본다. 따라서 전 조직이 아니라 소프트웨어 비중이 높은 조직부터 바뀌거나 아예 기존 조직과 거리를 두는 새로운 조직을 만드는 것이 차라리 가능성이 있어 보인다.

필자는 삼성이 Soft하게 바뀌는 것이 국내 소프트웨어 산업에도 많은 도움이 될 것으로 생각한다. Soft적인 마인드는 자연스러운 공생의 길을 가게 만들것이다.

미우나 고우나 삼성은 국내 소프트웨어 업계 뿐만아니라 전체 경제에 막대한 영향을 주고 있으므로 잘 되어야 한다. 

소프트웨어에 있어서는 과거처럼 안 된다는 것을 빨리 깨달아야 한다.
소프트웨어는 생각하는 것보다 1,000배쯤 어렵고 복잡한 것이다.
돈주고 쉽게 사올 수 있는 것도 아니다.
소프트웨어적인 역량이 있는 회사만이 좋은 회사를 사와도 도움이 되는 것이다.
지금의 마인드를 바꿀 수 없다면 점점 뒤쳐질 수 밖에 없을 것이다.


* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by keith.bellvay

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

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/232 관련글 쓰기
  1. Blog Icon

    비밀댓글입니다

  2. 감사합니다. ^^

개헤엄은 아무리 잘 해도 개헤엄

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



나의 경험에 의하면 우리나라 소프트웨어 회사들의 대부분은 Global 경쟁력을 거의 갖추고 있지 못하며 여전히 국내에서만 좀 통하는 주먹구구식 개발 방법에 의존하고 있다.

이런 회사들은 자신들도 모르는 사이에 슬금슬금 그 한계가 다가오게 된다. 이미 한계를 넘어버리면 복구하기는 정말 어려워진다.

지금의 방법으로는 한계에 다다르고 있다는 징후는 다음과 같은 것들이 있다.
  • 개발자 인원수는 과거보다 훨씬 많은데 개발 효율은 훨씬 떨어지고 프로젝트는 데드라인을 못 지킨다.
  • 매출은 많이 늘었는데 순이익은 급격히 나빠지고 있다.
  • 신입 개발자들을 계속 뽑고 있는데 실제 프로젝트에 도움이 잘 안된다. 밥값을 하려면 몇 개월씩 걸린다.
  • 회사의 핵심 개발자들이 퇴사를 하고 있다.
  • 신규 개발보다 유지보수에 비용이 점점 많이 들어가고 있다.
  • 회사내에서 지식의 공유가 안되고 커뮤니케이션이 안되고 있다.
  • 제품들의 버그가 과거보다 훨씬 많아지고 있는데 그 원인을 잘 모르겠다.  
  • 개발자들의 전체적인 사기가 과거만 못하다. 옛날에는 인원은 적지만 모든 개발자들이 한마음으로 똘똘 뭉쳐있었다.
  • 바쁜 개발자들은 항상 너무 바쁜데, 핑핑 노는 개발자들도 있는 것 같다. 하지만 누가 어떻게 놀고 있는지 잘 파악이 안된다.
이 중에서 2~3개라도 일치하면 한계에 다다르고 있다는 신호다.
소프트웨어 회사가 한계를 넘어가면 다음과 같은 길을 가게 되어 있다.
  • 더욱더 밀어 붙이다가 그대로 망하는 길로 달려간다. 
  • 상황이 악화됨에 따라서 구조조정으로 회사의 규모를 줄이고 목숨을 연명한다.
  • 개발 방법에 변화를 시도한다. Global 경쟁력을 갖추려고 노력한다. 
대부분의 회사는 망하는 길로 치닫는다. 그래서 우리나라에는 성공한 SW회사가 손에 꼽을 만큼밖에 되지 않는다. 또한 Global 경쟁력을 갖추고 세계 시장을 호령하는 회사는 더욱더 찾아보기가 어렵다.

가장 좋은 방법은 한계에 다다르기 전에 회사를 변화시키는 것이다. 제대로 된 길로 가는 것은 빠르면 빠를수록 좋지만 아직 주먹구구식 개발을 하고 있다면 지금이 가장 빠른 시기이다.

하지만 변화는 어렵다.

"변화는 개를 두발로 걷게 하는 것과 같다."라는 말이 있다. 두발로 열심히 걷던 개도 잠시 눈을 돌리면 어느새 네발로 걷게 된다. 즉, 변화는 자꾸 과거로 회귀하려는 성질이 있다. 그래서 기업에서의 대부분의 변화는 실패로 끝나게 된다.

개헤엄은 개헤엄을 뿐이다. 
개헤엄은 아무리 숙달되고 능숙해져도 개헤엄일뿐이다. 절대로 자유형을 이길 수 없다.

변화가 어렵고 개발자들이 자꾸 과거로 돌아가고 싶어하더라도 과거로 돌아가서는 이미 성장해버린 회사는 더 이상 과거의 방법이 통하지 않는다. 개헤엄을 이길려면 새로운 자유형을 배워야 한다.
그래야 경쟁도 할 수 있고 살아남을 수 있다. 

Global 경쟁력을 갖추는 방법은 프로세스, 조직, 시스템, 문화를 체계를 갖추고 변화시켜 나가는 것이다. 변화에 성공해야 개발자와 회사 모두가 행복해진다.


* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by 
Drewski2112
저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/226 관련글 쓰기
  1. 좋은 글 잘 읽었습니다. 개헤엄은 아무리 잘해도 개헤엄이라는 비유가 마음에 쏙 듭니다. :)

  2. gsong 님 감사합니다.

  3. 정말로 좋은 글입니다. ^^
    가슴에 와 답습니다.

  4. 감사합니다. ^^

  5. Blog Icon
    나그네

    그러면 자유형을 하려면 어떻게 해야하는건가요? rss등록하여 여기의 좋은 글들을 많이 보아왔지만,
    어떤 모습으로 어떻게 라는 의문이 항상 있었어요.
    프로세스,조직,시스템,문화을 어떤 모습으로 어떻게 변경을 해야하는 건가요?

  6. 안녕하세요. 나그네님
    자유형을 말로 설명하려면 피아노 잘치는 방법을 글로 설명하는 것과 비슷합니다. 이론은 존재하나 이론으로는 절대로 배울 수 없는 것입니다.
    실제 경험을 해야죠. 그래도 현실적인 이론은 제 책과 블로그에서 설명하고 있으나 현실에 적용하기는 쉽지 않다는 것을 잘 알고 있습니다. 그래도 꾸준히 적용해나가야 합니다.

  7. 왜 이렇게 공감가죠 ㅎ 정리 참 잘해주셨습니다 ^^
    무엇을 어떻게 변해가야 할 것인가는 기업 개개의 문제겠죠.
    물론 그걸 모른다면 나락으로 갈 수 밖에 없겠지요.

  8. 안녕하세요. 레몬에이드님
    실제로 컨설팅을 하면서 기업들의 상황을 보고 느끼는 것들이기 때문에 공감이 갈 겁니다. ^^ 하지만 어떻게 변화해야 하는지 스스로 알아내기는 어렵고 보통 시행착오를 많이 하다가 결국은 실패하는 경우가 대부분입니다. 그래서 저희 같이 경험이 있는 사람들이 교육이나 컨설팅을 통해서 돕죠.

  9. 결국은 사람이 중심이 되고
    사람이 원인/문제가 되는 것이기 때문에
    문제가 발생을 해도 바뀌는게 없는것 같은건
    인간 본질이기 때문인것 같기도 하고.. 아무튼 사람이 가장 어려운것 같습니다

개발자는 글을 잘 쓰지 못한다?

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



개발문서 작성은 항상 개발자를 따라다니면서 괴롭힌다.


체계적으로 개발을 하려면 개발문서를 적절하게 작성해야 한다고 다들 이론적으로는 알고 있다. 실제 그렇게 하지 않아도 이를 부정하는 개발자는 그렇게 많지 않다.

물론 핑계는 있다. 워낙 바빠서 문서를 만들 시간이 없다. 다 아는 내용이라서 문서를 작성하는 것은 시간 낭비다.

그럼에도 불구하고 회사에서 문서 작성을 강제로라도 시키면 개발자들은 MS Word를 열어 놓고 코딩할 때 처럼 진도가 나가지 않는다. 이때 주로 하는 얘기가 "머리 속에는 잔뜩 있는데 글을 잘 작성하지 못해서 문서를 작성하기 어렵다"라는 것이다.

이렇게 되다보니 문서만 작성하라고 하면 거부 반응을 보이게 된다.

하지만 이는 개발문서 작성을 피해보려는 핑계에 불과하다.
개발문서를 작성하는데 있어서 의외로 "글쓰는 재주"는 별로 필요하지 않다.

개발자들이 가장 흔히 작성하는 개발문서는
스펙과 설계 문서이다. 사용자 메뉴얼을 쓴다면 "글쓰는 재주"가 아주 많이 필요할 것이다. 하지만 스펙과 설계 문서를 작성하는데는 글쓰는 재주보다는 내용이 더 중요하다. 스펙과 설계 문서의 독자는 대부분 프로젝트 관련자와 개발자이기 때문에 잘 적힌 문장이 아니더라도 필요한 내용만 적히면 문제가 없다.

결론을 말하면 개발자들은 글쓰는 재주가 없어서 개발문서를 잘 작성하지 못하는 것이 아니고
분석을 못해서 "스펙"문서를 작성하지 못하고 설계를 못해서 "설계"문서를 잘 작성하지 못하는 것이다. 
 
문서는 분석과 설계의 결과물일 뿐이다. 스펙문서는 SRS Template을 보면 적어도 어떠한 내용이 적혀야 하는지 약간의 도움을 받을 수 있다. 설계문서는 Template이나 툴이 중요하다기 보다는 창의력을 발휘하여 설명할 수 있어야 한다.

문서가 잘 작성되었는지의 판가름은 문서작성자 외의 다른 개발자들이 이 문서를 받아서 일을 할 수 있나 보는 것이다. 물론 본인이 혼자서 분석, 설계, 구현을 하는 경우라도 상세도만 약간 줄이면 되며 내용은 빠짐없이 적어야 한다.

다른 사람이 보고 일을 하려면 화려하고 멋진 문장보다는 정확한 내용을 전달하기만 하면 된다. 기본적으로 주어, 목적어 등을 빼먹어서 애매하게 만드는 일은 없어야 한다. 또한 내용도 정량적으로 기술할 수 있어야 한다. 애매하게 "빨라야 한다"라든가 "편리해야 한다"등의 표현은 절절하지 않다. 이정도는 글쓰는 재주가 없어도 조금만 신경쓰면 되는 내용이다.

과거에 잘작성된 문서를 받아서 개발을 해본 경험이 몇번이라도 있으면 본인이 그러한 문서를 작성해서 다른 사람에게 넘기는 일은 어렵지 않을 것이다. 하지만 우리나라에서는 이러한 개발 문화가 없기 때문에 이런 경험을 가진 개발자를 보기란 정말 어렵다. 그래서 스스로 분석, 설계 방법을 터득해야 하는데 정말로 어려운 일이 아닐 수 없다. 간접적인 경험으로 인터넷의 글이나 책을 보곤하는데 이를 통해서는 너무 많은 정보를 접해서 핵심을 놓치고 오히려 방해가 되곤 한다.

결론은 원칙을 잘 생각하는 것이다. 자신이 작성한 문서를 다른 개발자가 보고 개발을 할 수 있게 해야 한다는 것을 잊지 말자 물론 개발뿐만 아니라 QA, Tech pub, Marketing, Sales 등 모든 부서가 일을 할 수 있어야 한다.

글재주가 없어서 문서를 잘 작성하지 못하는 것이 아니라는 것을 받아드리면 개발문서에 한단계 다가간 것이다. 일단 긍정적인 마음으로 시작하는 것이 중요하다. 그러면 메모 한장이라도 작성하는 것이 더 빠르게 개발하는 길이라는 것을 차츰 알게 될 것이다.


* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by photosteve101

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

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/223 관련글 쓰기
  1. 개발자 코드의 변수 선언을 보면 답이 나옵니다.
    영어를 잘해서 좋은 변수명을 선언하는 게 아니라, 내용을 잘 알면, 사전에서 찾으면 되겠지요.
    결국 내용을 모르면서 코딩도 하는 게 아닌가 싶습니다.
    그런데 심지어 문서라니요^^

    그래도 계속 연마하면 좋아지는데, 쉽게 포기하고들 말더군요... 가랑비에 옷 젖듯이... 일신우일신 해야 하는데...

  2. 디밥님 안녕하세요.

    동감입니다. "연마"... 꾸준히 해야 느는 법이죠.

  3. 글 잘 봤습니다.
    SE 공부하면서 가끔씩 느끼는 부분이었는데, 설명을 잘 해주셨네요 ^^
    하지만 본문에 언급한 "글쓰는 재주"가 논문 쓸 때 드러나게 마련이죠 ㅠㅠ

  4. 안녕하세요. dtoa님

    논문은 읽는 대상이 개발문서보다 비교가 안될 만큼 넓기 때문에 문서의 전체 구조나 문장도 좀더 잘 적어야 합니다. 이런 과장에서 잘 훈련된 엔지니어라면 개발문서를 좀더 잘 적을 수 있겠네요.

  5. Blog Icon

    비밀댓글입니다

  6. 감사합니다.

  7. 안녕하세요? 글쓴 내용과는 다른 답글이긴 한데.. 혹시 블로그에 페이스북 댓글 달 생각은 없으신가요? 몇군데 달아놓은 곳 보니(제 블로그 포함) 편하긴 편하더라구요. 누가 누군지 알기도 쉽고 :)

  8. 아래 달아 봤습니다. "좋아요" 버튼은 안생기네요. - -;

  9. 좋아요 버튼 다는건 또 따로 있어요. ㅎㅎㅎ

  10. 음.. 초보개발자들을 위해서 SRS Template 나
    개발개념서 라던가 이런것들을 공유해주시는건 어떨까요?

    한번 해보고는 싶지만 개략적인 틀도 없는 상황에서는 뜬구름 잡는 느낌이라서 말이죠 ^^;

  11. 안녕하세요. 구차니님
    Google에서 SRS Template으로 검색하면 수두룩하게 나옵니다. 샘플로 많이 나옵니다. 물론 영어로 되어 있습니다.
    하지만 별로 도움이 안됩니다.
    타이거우즈 스윙 동영상을 아무리 봐도 나의 스윙에는 별로 도움이 안되는 것과 비슷합니다. 스스로 연습을 많이 하고 코치의 코칭을 받아야 늘죠.
    샘플이나 Template를 보는 것보다 가이드 하는 책을 보고 직접 써보면서 프로젝트를 여러차례 직접 해보는 것이 중요합니다.
    SRS를 써서 다른 개발자에게 개발하라고 주면 개발할 수 있어야 제대로 작성한 겁니다. 그런 마음가짐으로 쓰시면 됩니다. 쉽지는 않습니다.

개발자는 회사의 부품일까 두뇌일까?

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



정말 오랫만에 글을 쓴다. 워낙 바빠서 시간을 내기 어렵다는 핑계를 대지만 블로그에 올릴 글이 50개 이상은 준비중이고 한두시간만 시간을 내서 정리해 올리면 되는데 바쁠때는 그것도 잘 안된다. 다시 마음을 잡고 글을 올린다.

여러 회사를 컨설팅하면서 각 회사에서의 개발자들의 가치를 비교해보게 된다.

흔히 프로세스가 아주 잘되어 있어서 개발자들가 퇴사해도 문제가 없는 회사에서는 개발자가 부품 취급 받을 것 같다.

반대로 몇몇 슈퍼 개발자들이 슈퍼 파워를 내서 단시간에 놀랄만한 성과를 내는 회사들에서 개발자들의 가치가 더 높아질 것으로 생각하는 경우가 많다.

하지만 그 반대인 경우가 더 많다.

개발자들에게 선택이 가능하다면 두가지 경우 중에서 어느 경우를 선택하겠냐고 물어보면 대부분 두번째 슈퍼 개발자를 선택할 것이다. 두번째 경우가 회사에서 없어서는 안될 중요한 인물이 되고 연봉도 더 높을 것으로 생각된다.

하지만 회사입장에서는 다른 선택을 하게 된다. 우리나라의 대부분의 소프트웨어 회사들은 두번째 경우이지만두번째 상황을 벗어나려고 발버둥치고 있다.

사실 슈퍼 개발자들이 단시간에 놀랄만한 성과를 내는 것은 별로 놀랄 일도 아니다. 주변에서 워낙 흔히 벌어지고 단지 단기간에 낸 성과의 댓가는 미래에 톡톡히 치르기 때문이다.(물론 이런 빠른 전술이 필요한 경우도 많고 이를 적절히 사용해야 한다.) 이런 환경에서 개발자는 더 가치가 있을 것 같지만 시간이 흐를수록 점점 그 가치는 떨어져 간다. 과거에 만들어 놓은 제품을 다른 사람이 유지보수 하기 어려워서 유지보수에만 매달리다가 점점 유지보수가 어려워지면 회사를 떠나곤 하고 남아있는 개발자들이 고생을 해야 한다. 이 과정에서 회사는 프로세스의 중요성에 눈을 뜨고, 남아 있는 개발자들은 피해의식만 커져간다. 

반대로 처음부터 적절한 프로세스를 갖추고 개발하는 회사는 당장은 조금 느려보이지만 문서를 만들고 서로 리뷰도 여러사람과 공유를 하며 프로세스를 따라서 개발을 한다. 여러사람과 공유를 하기 때문에 유지보수도 문제가 없고 이전 프로젝트의 족쇄 없이 새로운 프로젝트를 시작할 수도 있다. 또한 퇴사를 해도 회사에 큰 타격을 주지 않는다. 이런 회사에서는 개발자들이 특히 고참개발자들이 유지보수 등 잡일에 목메이지 않고 그런 일은 신참 개발자들에게 맡기고 회사의 두뇌다운 전략이나 로드맵, 아키텍쳐를 고민할 수 있게 해준다. 회사와 개발자간에 상호간에 Risk가 적으며 서로 발목을 잡지 않는다. 

이런 환경에서 성장한 개발자는 더 가치 있는 일의 경험이 쌓여서 이직시에도 더 높은 연봉을 받을 수 있다. 하지만 그렇지 못한 회사에서는 10년을 넘게 일을 해도 느는 것은 공력과 해당 Domain 지식밖에 없게 된다. 이런 회사에서는 회사와 개발자가 서로의 발목을 잡고 성장을 못하게 된다. 이직시에도 경쟁회사처럼 비슷한 일을 하는 회사로밖에 옮기지 못하고 이직후에도 비숫한 문제들을 또 일으키게 된다.

현재 자신의 회사가 어디에 해당하는지 아는 방법이 있다.

회사의 개발 일들이 특정인이 아니면 못하는 구조로 되어 있으면 문제가 있는 경우이다.
또한 특정인이 퇴사하면 과거에 해 놓은 프로젝트가 엉망이라면 고민을 해야 한다.
하지만 특정인이 퇴사하면 미래에 할 프로젝트에 피해가 간다면 개발자들이 진정한 회사의 두뇌로 생각되는 경우일 것이다. 물론 칼로 무를 자르듯이 경계가 명확한 것은 아니다.

개발자가 회사의 부품이 아니고 두뇌가 되는 길은 2,3명 회사이던 1000명 회사이던 적절한 프로세스를 통해서 개발자가 두뇌의 역할을 해줄 수 있는 환경을 조성하는 것이다. 여기서 "적절한" 것이 가장 어렵기는 하지만 그 필요성을 공감하는 것이 첫걸음이다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/222 관련글 쓰기
  1. 전자의 회사로 만들고 싶지만 항상 기존의 직원들의 반발이 심하고
    이러한 '인적 문제'가 항상 지치게 하네요 ㅠㅠ

  2. 구차니님 오랫만입니다.
    대부분 변화는 싫어하기 마련입니다.
    더 좋아지는 것을 알지만 현실적으로 그렇게 못한다고들 합니다. 그리고 이런 저런 핑계를 댑니다. 이런 개발자들은 자신들이 안다고 착각을 하는 겁니다.
    몇몇 개발자가 직원들의 반발을 무시하고 추진하면 왕따만 당하기 쉽상입니다.
    그래서 저희가 컨설팅을 하는 거죠. ^^

  3. Blog Icon
    조인중

    안녕하세요, 선배님.
    오랜만에 뵙습니다.

    가끔씩 블로그에 들러서 글 잘 읽고 있습니다.
    가려운 데를 잘 긁어주셔서 참 많은 생각을 하게 하네요.

    건강하게 잘 지내고 계시죠?
    종종 들러서 글도 읽고 안부도 여쭙고 하겠습니다.

    더운 여름 잘 준비하시기 바라겠습니다.

  4. 인중아, 오랫만이다.
    안랩은 잘 다니고 있지? 가을에 판교로 옮길때 따라오지? 판교에 오면 가끔 볼 수 있겠네... 내가 판교에서 컨설팅하는 회사가 있거든.
    날씨 더워지는데 건강관리 잘해라....

  5. Blog Icon
    조인중

    아. 하도 오랜만에 인사를 드려서 ^^;; 저 안철수 연구소 그만 둔 지 좀 됐어요.
    지금은 SK브로드밴드라는 ISP에서 일하고 있습니다.
    판교..는 집이 너무 멀어서 -_-;;; 판교로 옮기기 전에 냉큼 도망나왔죠.

  6. Blog Icon
    나장근

    블로그 잘 읽고 있습니다.

    개발자가 부품인 회사 : 개발자가 퇴사하면 현재 프로젝트가 문제가 생긴다.
    개발자가 두뇌인 회사 : 개발자가 퇴사하면 향후 프로젝트에 피해가 간다.

    명료한 판단 기준이네요.

  7. 나장근님 안녕하세요.

    회사를 이끄냐, 발목을 잡느냐의 차이로 볼 수 있습니다.
    개발자들은 자신이 어디에 속하는지 잘 생각해 볼 필요가 있습니다. 과거에 얽매여 있으면 지금이라도 미래 가치가 있는 쪽으로 노력할 필요가 있습니다.

  8. 글 잘 읽고 갑니다. :)

  9. 너무 잘 읽었습니다. 확실히 처음부터 어느정도의 프로세스를 가지고 가는것이 좋은것 같아요. 나중에 프로세스를 잡아가는 단계에서는 기존 개발자 분들의 반발도 있고해서 어렵네요

  10. 안녕하세요. ash84님

    기존의 타성에 젖은 사람들의 마인드를 바꾸는 것은 정말 어렵습니다. 내부에서 스스로 해결하지 못하는 경우가 많죠. 또 기존에 망쳐놓는데 일조한 사람들이 방해를 하기 때문에 추진이 더욱 어려운 경우가 많습니다.

경영자가 개발자의 거짓말에 현혹되지 않는 법

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


제대로 체계를 갖추기 못한 회사에서는 개발자가 경력이 늘어갈 수록 거짓말이 늘곤 한다.

비효율적인 것을 알지만 (혹은 모르기도 하고) 자신의 기득권을 지키기 위해서 거짓말로 경영자를 현혹하곤 한다. 고의적인지 아닌지 그 경계는 매우 모호하다. 

물론, 뛰어나고 훌륭한 고참 개발자들도 많다. 회사의 기술을 리드하고 후배들을 이끌며 귀감이 되는 개발자들도 많다는 것을 잘 알고 있다.

많은 개발자들이 이 글을 보고 반발할 수도 있음에게 이 글을 쓰는 이유는 자의든 아니든 경영자를 거짓말로 현혹하는 개발자들이 꽤 있기 때문이다. 경영자는 이러한 거짓말에 현혹되지 않기를 바라는 마음이다.

경력이 많은 개발자들에 비해서 경력이 부족한 신참 개발자들은 솔직한 편이다. 

신참 개발자들은 지켜야 할 기득권이 별로 없고, 아직 개발에 대한 열정이 남아 있고, 앞으로 개발해야 할 날이 많이 남아 있으므로 올바른 선택을 하려고 노력한다. 

고참 개발자들이 하는 대표적인 거짓말들은 다음과 같은 것들이 있다.

- 프로세스 무용론 : 프로세스란 대기업이나 필요한 것이다. 프로세스는 오히려 효율을 떨어뜨린다.

- 신입 무능론 : 요즘 신입은 실력이 부족해서 일 시키기가 어렵다. 개발도 느리고 버그도 많이 만든다.

- 나 밖에 못한다 : 이것은 복잡하고 어려워서 나 아니면 아무도 못한다. 그래서 뭐든 자기가 하려고 한다. 

- 문서는 개발을 더 늦게 만든다 : 우리 회사는 개발 일정이 너무 촉박해서 문서를 만들 수 없다.

경영자들은 주로 고참개발자들과 얘기를 하기 때문에 신참 개발자들의 솔직한 얘기를 듣기가 어렵다. 그래서 옛날 왕들처럼 가신들에 둘려 쌓여서 실정을 제대로 모르는 경영자가 된다. 이렇게 실정을 모르는 경영자들은 회사가 어려워져도 개발조직이 문제라는 것을 쉽게 알아차리지 못한다. 결국 망해가는 길 밖에 없다.

여기에 현혹되지 않는 가장 좋은 방법은 능력 있는 CTO를 두는 것이다. 능력과 경험이 있는 CTO에게는 개발자들이 하는 어떠한 거짓말도 통하지 않는다. 심지어는 몇 마디만 딱 들어도 왜 거짓말을 하고 실력이 어느 정도 인지 다 파악이 된다. SW개발이 아닌 다른 분야도 마찬가지 아닌가. SW도 똑같다.

경험과 능력 있는 CTO가 절대적으로 부족한 우리나라에서는 경영자가 신참개발자들과 자주 소통을 하는 것이 중요하다. 그러면 고참개발자들과 다른 얘기를 할 것이다. 그러면 둘 중 하나는 거짓말을 하고 있는 것이다. 물론 고참이 거짓말을 할 가능성이 더 높다.

CTO가 없다면 개발자들의 말만 듣지 말고 주변의 능력있는 CTO급 개발자에게 가끔 조언을 구하는 것이 좋다. 단 이해가 얽히지 않는 사람이어야 한다. 경영자가 절대로 알지 못하는 얘기를 해줄 것이다.

그러한 조언자도 없지만 회사의 여러 개발자들과 골고루 얘기를 해야 한다. 그렇지 않는다면 가신에 둘러싸인 왕 신세가 될 수도 있다.

이 글을 보고 발끈한 개발자들 중에는 본인이 여기에 해당하지 않나 생각해보기 바란다. 그렇지 않다면 회사의 진정한 기술 리더 일 것이다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.

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

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/218 관련글 쓰기
  1. Blog Icon
    J

    개발에는 사람대신 프로세스와 문서화를 주장하는데 해결책은 능력있는 CTO(사람)라면 모순아닌가요?

    해결책도 회사내 프로세스개선쪽으로 가야할 것 같습니다.
    회사내에 제대로된 평가 프로세스라도 있으면 거짓말의 상당부분은 막을 수 있을것 같습니다.
    이야기하신 신참하고 이야기한다거나 , 프로젝트가 끝나면 고생한사람 투표로 칭찬하기라던가... 뭐가 되던간에요.

    CTO는 경영자버전의 '프로세스는 비효율적이야 사람이 최고야'아닌가요?

  2. J님 안녕하세요.

    저도 동감입니다. 회사는 프로세스와 문서 위주로 돌아가야 합니다. 하지만 이렇게 변화하기도 전에 이런 일이 일어난다는 뜻입니다.

    그래서 그런 방향으로 이끌어 줄 사람이 필요하다는 뜻입니다. 휘둘리지 않을 사람이 있어야 프로세스 개선의 방향으로 갈 수 있습니다.

    프로세스가 효율적으로 제대로 정착된 회사에서는 사람의 역할이 더욱 빛나게 됩니다. 프로세스 중간 중간에 사람, 즉 전문가들의 판단이 더욱 중요한 역할을 하게 됩니다.

    프로세스가 잘 될 수록 사람이 더욱 중요해집니다. 이는 특정인이 아니고 전문가를 말합니다.

    가끔 경영자 중에는 프로세스가 공장 생산라인처럼 완전 기계화 자동화 될 수 있다고 생각하는 사람들이 있는데 이런 프로세스는 SW를 개발하는데 있어서 너무 간 겁니다.

    핵심적이고 Compact하고 효율적인 프로세스가 중요합니다.

  3. 글쎄요. 개발자의 거짓말일 수도 있겠지만 대부분의 위와 같은 경우는 진심이더군요. 물론 정말 그렇다는 것이 아니라 그런 경험밖에 못해봤기 때문 아닐까요.

  4. 안녕하세요. Jake님

    동감입니다. 진심인 경우가 더 많습니다. 글에도 있는데요...

    모르고 얘기하는 경우
    알고도 거짓말하는 경우

    이 글은 알고도 거짓말을 하는 경우도 많다는 얘기를 하는 겁니다. 물론 그 경계는 매우 모호합니다. 반쯤 알고 반쯤 모르지만 자리보존을 위해 어쩔 수 없이 비합리적인 것을 주장하기도 하고... 아무튼 복잡합니다.

    하지만 경영자들인 이런 것에 휘둘리기 쉽다는 얘기입니다. ^^

  5. 1. 정직과 성실이 업무에 제일 중요하다는 것이 제 기본적인 생각입니다. 그렇지 않으면, Win/Win이 안 되기 때문이죠. 다만 위(이 때는 교수님이셨습니다.)에서 자꾸 프로토타입 만들라 강요를 받을 때, 그대로 눈에 보이는 프로토 타입 만들어 드리면서, 해 달라는 것은 해 주게 되는데, 코드 내용은 완전히 사기(!)가 되어 버려서 마음속으로 많이 괴로웠던 기억이 있습니다.

    그 후에 왜 그런 일이 일어났을까 고민을 해 보게 되었는데, 결국은 개발에 대한 이해가 부족하기 때문이라고 결론을 내릴 수 있었습니다.

    교수님이 부족한 것이 아니라(조금은 부족했지만, 그러다 보니 지금은 교수님들도 100% 이해하지 못하는 소프트웨어 공학을 어찌 일반인이 100% 이해하리 하는 생각을 하며 삽니다.), 제가 더 부족해서 그런 일이 벌어졌던 것이더군요.

    2. 불필요한 것만 가득한 프로세스를 만든다면 분명효율이 떨어지겠지만, 잘 만들면 그만한 게 없고,

    신입을 잘못 뽑았다면 분명 개발이 느리고 버그를 많이 만들겠지만, 개발 능력이 있는 사람을 뽑았다면 그런 재산이 없을 테고,

    설계를 안 해 보면, 모든 것이 내가 해야 할 것처럼 느껴지지지만, 설계 해 보면 일을 어떻게 나눠야 할 지 보이고,

    문서가 코드를 따라가면, 재미없고 지루하고 시간만 끌지만, 코드가 문서를 따라가면 문서 만들기가 제일 재미있다는 것을 알면 좋은데,

    몰라서 문제이고, 경험하지 못해서 문제라고 생각합니다.


    3. 대학 마지막 학년을 보내면서 졸업 작품을 개발 중인데, 개발 능력이 비교적 부족한 두 명(팀은 총 저까지 4명입니다.)에게 약간 실력 있는 친구 한 명을 붙여, 짝 프로그래밍(Pair Programming)의 변형을 시도해 보려 합니다. 적절한 결정일까요?

  6. 졸업작품 프로젝트를 어떻게 모듈로 나눠서 개발하느냐 따라 다르겠지만..
    일반적으로는 본인과 약간 실력있는 친구가 한명씩 맡고 짝 프로그래밍을 하는것이 더 적절하지 않을까 합니다.

  7. 주의사신님 안녕하세요.

    정직과 신의는 SW뿐만 아니라 모든 업계의 공통 요구사항 같습니다.
    SW는 시스템과 프로세스에 의해서 투명하게 일해야 합니다.

    짝프로그래밍이 적절한지는 스스로 판단하셔야겠습니다.
    저 같으면 가장 실력이 뛰어난 개발자가 분석, 설계를 주도하고 다른 개발자들도 참여를 하면서 스펙과 아키텍쳐에 대해서 잘 습득한 이후에 각자 실력에 맞게 컴포넌트를 나눈 후 개발을 하겠습니다. 그리고 뛰어난 개발자들이 리뷰를 잘 해주면 좋겠지요.

    하지만 전체적으로 분석, 설계 능력이 부족하면 같이 짝프로그래밍을 하는 곳도 좋을 것 같습니다.

  8. Blog Icon
    청설모

    우리나라 CTO가 됐어야 할 분들은 치킨집에 계시다는 얘기가...
    (개발하다 막히면 치킨집 사장님에게 물어보라는 우스개 소리도 있죠 -.-)

  9. 청설모님 안녕하세요.

    이런 얘기 종종 듣습니다. 안타까운 현실이네요.

  10. 고참 개발자들의 거짓말의 원본 원인은
    기본적으로 극단적으로 짧게 결정되는 프로젝트 기간이 문제라고 봅니다.

    물론 이런 식의 프로젝트를 진행하지 않는게 좋겠지만
    회사입장에서 영업을 따오기 위해서 진행할 수 밖에 없는 상황은 언제든지 발생하게 마련입니다.
    (특히 우리나라에서는 비일비재합니다. )

    1. 프로세스는 생각할 겨를 없다.
    2. 신입을 가르칠 시간이 없음 , 고참 개발자라긴 하지만 자기가 맡은 코딩에 바쁘다
    3. 실제로 본인밖에 못할 경우도 많음 , 소스 리뷰 & 공유가 안되서
    4. 문서를 잘 만들어본 경험이 없어서 문서 얘기는 좀 애매하군요.

    위와 같은 문제는 결국 프로젝트 몇개를 포기하더라도 시간에 맞는 일정을 세우고 프로세스를 정립해 나가면서 개발을 할 의지가 있느냐의 문제인것 같습니다.

    이런 결정을 경영진이 아닌 고참 개발자가 할 수 있을지는 회사마다 분위기나 차이가 있겠지만
    대부분은 아무리 고참 개발자라고 하더라도 영업적인 문제가 걸려 있는 상황에서
    프로세스 정립, 신입교육, 소스 공유 등의 시간을 요청하기란 우리 나라 현실에서 쉽지가 않습니다.

  11. 안녕하세요. 이성열님

    이미 악순환의 고리에 빠져서 회사나 개발자나 역량이 부족한 경우 딱 이런 현상이 벌어집니다.

    정상적인 경우 프로세스와 문서가 프로젝트 일정이 단축되기 때문에 이것을 경험해보려면 변화가 필요합니다.

    작은 조직에서는 그럭저럭 해냈어도 조직이 조금만 커져도 악순환의 고리로 점점 들어가게 됩니다.

    그렇게 되면 신인교육, 소스공유가 저절도 해결 됩니다.

  12. 역설적으로 경영자가 개발을 알면되지
    왜 항상 개발자에게 경영을 알게하나 싶긴합니다.

    물론 개발자 입장에서는 차라리 모르는 경영자가
    어디서 주워들은것만 많은 경영자 보다는 속 편하긴 하지만 말이죠

  13. 구차니님 안녕하세요.

    어설프게 개발을 아는 경영자가 더 문제가 되는 경우를 많이 봤습니다. 서로 자신의 일에 전문이 되어야죠.
    개발자도 위로 올라갈수록 비즈니스를 잘알아야 하는 것은 당연합니다.

  14. Blog Icon
    MR.D

    흠 저는 고참 개발자가 한말은 실제로 대부분 거짓말이 아니라 대부분 진실일 확율이 더 높다는 쪽입니다. 다만 고참 개발자는 CEO에게 앞에 수식어를 잘 언급하지 않아서 그렇게 보일뿐입니다. 왜냐면 CEO는 듣기를 원하지 않는 수식어이기 때문이죠. 그 수식어는 다 아시는 걸 껍니다.
    "그 기간내에"/"그 비용 내에"/"그 계약자(갑)일 경우" /"그 인력으로"/"그 환경에서는"

    대부분 CEO는 논의된 내용과 관련된 시간과 비용을 지불할 용의가 없으며
    갑의 횡포(요구 변경등)로 부터 개발자를 보호할 의지가 없고
    또한 돈과 시간을 추가로 지불하여 더 낳은 인력을 키울 생각이나 정상적인 개발 환경 구축비용을
    지불할 의사가 없을 때가 많습니다.

    그럼 고참 개발자들은 다만 지쳐서 매번 반복한 앞에 의미 없는 수식어를 뺄 뿐인거죠. 현재 국내
    열악한 IT상황에서 CEO도 대부분 어쩔 수 없다는 것을 알 수준이니 까요

  15. 안녕하세요. MR.D님

    대다수의 고참개발자를 대상으로 하는 내용은 아닙니다. 일부가 그렇다는 얘기죠. ^^

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..

내가 개발에 집중할 수 없는 이유

우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..

Software Architect를 양성하는 나라

우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..

프로토타입이란?

프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..

우리 식대로
우리 식대로 2011/10/30

"우리 식대로" 마치 북한에서 하는 얘기 같지만, "우리 식대로"를 주장하는 소프트웨어 회사는 의외로 많다. 체계가 하나도 없이 완전 주먹구구 방식의 소프트웨어 회사가 있는가 하면 "우리 식대로"를 주장하여 정말 많은 일을..

문서는 얼마나 적어야 할지?

소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다. 다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다." 물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된..