태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

같이 일하려면 적어라.

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




"협업은 말로 하는 것이 아니라 문서로 하는 것이다."

동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다.

우리나라 개발자들은 그 정도가 훨씬 심하다.

우리나라에서는 회사가 크던 작던 상관없이 대부분 5년, 10년 개발한 제품도 변변한 문서가 하나 없는 것이 현실이다. 이것만 보더라도 협업의 수준이 얼마나 낮은지 알 수 있다.

협업이란
1. 여러 사람들이 가지고 있는 지식과 경험의 도움을 받고
2. 서로 머리를 더해서 더 좋은 생각을 이끌어내 내고
3. 일을 서로 나눠서 하는 것을 말한다.

이런 협업을 하는데 있어서 Template은 중요하지 않다. 협업이 필요한 내용이 공유를 할 수 있을 만큼만 적히면 된다. 적힌 것이 있어야 서로 공유를 하고 도움을 받을 수 있다. 만약 적히지 않고 머리 속에 있는 내용을 공유하려면 매번 말로 설명하는 수밖에 없다. 얼마나 피곤한 일인가. 또한 본인도 기억하지 못하는 사태가 벌어진다.

대표적으로 스펙과 설계는 협업이 매우 중요하다.
스펙과 설계를 제대로 적지 않고 리뷰를 하면서 계속 발전시켜나갈 수 없다. 한사람의 머리속으로 기억을 하면서 말로 공유를 하면 일을 서로 나눠서 개발하기도 어렵다.

하지만... 우리나라에서는 소프트웨어 개발을 할 때 변변한 문서도 없이 여러명이서 나눠서 개발을 잘도 한다. 물론 효율적으로 협업이 되지 않는다. 스펙과 설계가 불명확하여 개발자들이 코딩할 때 다 알아서 하고 나중에 통합도 잘 안된다. 스펙과 설계를 적기가 어려워서 최근에는 Agile 방법론이 인기를 끌고 있지만, 이것도 하나의 방법일 뿐이다. 

뭔가 적어야 할 때 Template을 꺼내놓고 틀에 맞춰서 적으려고 고민하기 보다는 서로 협의하고 확인을 받아야 하고 도움을 받아야 할 내용들을 적어서 수시로 리뷰를 하면서 진행을 해보라. Text 에디터로 Plain text로 적어도 아무 상관이 없다. 이렇게 효과적으로 적고 협업을 자주 하다보면 스펙과 설계를 어떻게 적어야 효과적으로 프로젝트가 진행이 될지 조금씸 감을 잡을 수 있을 것이다.

Image by Norman Lear Center



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

'개발문화' 카테고리의 다른 글

같이 일하려면 적어라.  (6) 2011/11/01
우리 식대로  (1) 2011/10/30
우리나라 소프트웨어 회사에는 ???이 없다.  (4) 2011/07/30
주먹구구를 더 좋아 하는 이유  (11) 2011/07/17
나쁜 습관  (2) 2011/06/19
내가 소스코드를 몰래 고치는 이유  (13) 2011/02/01

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/240 관련글 쓰기
  1. 회의 소집 했더니, 필기도구도 안가지고, 맨 몸으로 옵니다...
    아이디어를 글로 적어보라고 하면, 못합니다...
    말로만 떠듭니다...
    그걸 그림으로라도 대강 그려보라고 하고, 다시 말해보라고 합니다... 전혀 다릅니다...

    그래도 계속 강제로 글 쓰게끔 합니다. 언젠가는 늘겠죠.

  2. 디밥님 안녕하세요.

    제가 자주 하는 말입니다. "지금 말한걸 그대로 적으세요.", "제가 그대로 적어 드릴까요?"

    말한 것을 그대로 적는 것도 쉽지 않은 것 같습니다.

    회의록을 작성하고 follow up 하는 것을 당연히 여기는 문화는 또 그렇게 흔하지 않더군요. 이 부분은 대기업이 조금 더 낫더군요.

  3. 개발자들은 원래 말보다 코드로 설명하는걸 좋아하거든요 ㅋㅋ
    단지 표현 수단으로서 인간의 언어/말 대신 프로그래밍 언어/코드로 표현을 하는 것일 뿐이에요

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

    Psudo 코드 같은 것을 적는 것도 좋은 방법입니다. ^^

  5. 옳으신 말씀. 특히 인수 인계때 필기도구 안가지고 오는 용감한 분들은 이해가 안갑니다. 그런분들이 꼭 매뉴얼 안보고 자기 머리로 소스코드만 보더라구요. 자기머리로 어쩔라구. 항상 좋은 글 잘보고 있습니다. ㅋㅋ

  6. 미물님 안녕하세요.
    혹시 한번 들으면 모든 것을 기억하는 천재가 아닐까요? 그렇다고 하더라도 다른 사람들을 위해서 적어야겠죠?

우리 식대로

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



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

이 "우리 식대로"라는 것이 표준적이고 일반적인 방법과는 사뭇 달라서 어떻게 보면 기발하기도 한 것들을 많이 이룩해 놓은 경우가 있다.
 
소스코드 관리, 버그관리, 빌드, 분석, 설계, 테스트 등 전반에 걸쳐서 아주 독특하고 비효율적인 방법들은 너무나도 많이들 만들어 놓았다.

결론부터 말하면 주먹구구인 회사보다 "우리 식대로" 회사가 문제가 더 크다. 주먹구구인 회사는 백지와 같아서 하나씩 배워나가고 바꿔나가면 되는데, "우리 식대로" 회사는 바뀌기가 더욱 어렵다. 

"우리 식대로"는 충분한 경험과 통찰력 없이 나름대로의 방식으로 만들어 놓은 것들이라서 잘 적응해서 사용하고는 있지만, 효율이 높지도 않을 뿐더라 프로젝트의 규모가 커지거나, 개발 분야가 확대 되거나 Global한 Business를 할 때 꼭 문제가 발생한다.
 
이렇게 문제가 발생해도 "우리 식대로"에 익숙해진 사람들은
  • 기존 방식이 익숙해져서
  • 새로운 방식이 더 좋다고 믿을 수가 없어서
  • 그 동안 투자한 것(Sunken cost)이 아까와서
  • "우리 식대로"를 구축한 사람들이 정치적으로 방해해서
  • 제대로된 새로운 방식 도입에 상당히 어려움을 겪게 된다.
그래서 나름대로 방식으로 뭘 해보려고 하면 나는 "하지 말라"고 한다. 소프트웨어를 개발하는 기본적인 원리와 체계는 대부분 표준적인 방법이 있고, 이를 먼저 익히고 경험한 후에야 "나름 대로 방식"으로 응용이 가능하다. 그러기 위해서는 남들은 또 외국에서는 어떻게 하는지 항상 관심을 가지고 있어야 한다.

요상망측한 툴들을 만들어 놓고 뿌듯해 하지 말자. 나중에 발목 잡힌다.
 
Image by Don Pableras
저작자 표시 비영리 변경 금지

'개발문화' 카테고리의 다른 글

같이 일하려면 적어라.  (6) 2011/11/01
우리 식대로  (1) 2011/10/30
우리나라 소프트웨어 회사에는 ???이 없다.  (4) 2011/07/30
주먹구구를 더 좋아 하는 이유  (11) 2011/07/17
나쁜 습관  (2) 2011/06/19
내가 소스코드를 몰래 고치는 이유  (13) 2011/02/01

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/243 관련글 쓰기
  1. Blog Icon
    슬픈멍멍

    지극히 공감합니다.
    개발환경만이 아니라 개발자체도 그렇다고 생각합니다.

우리나라 소프트웨어 회사에는 ???이 없다.

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



우리나라 소프트웨어 회사에는 없는 것이 참 많다.

물론 있는 것도 많다. 머리 좋고 충성심 높은 개발자도 있고, 기반시스템도 갖추고 있는 경우도 종종 있다. 또한 뛰어난 요소기술을 갖추고 있는 경우도 많다.

프로세스와 시스템은 갖추려고 상당히 노력을 하고 있어서 효과를 보는 경우도 간혹 있지만 이 또한 거의 대부분 수박 겉핧기 식에 머무른다. 아주 초보적인 기능만 쓰거나 잘못 사용하는 경우가 많다. 

하지만 대부분의 회사가 거의 갖추고 있지 못한 것들이 있다. 이런 것들을 넘지 못하면 글로벌 소프트웨어 회사로 가는 길은 멀게만 느껴진다.


1. 개발문화가 없다.

소프트웨어 개발을 정해진 프로세스대로 딱딱 진행해서 잘되면 참 좋겠다. 하지만 절대로 그렇게 되지 않는다. 물론 프로세스를 따르지만 프로세스에 모든 것을 다 담을 수는 없다. 모든 절차를 프로세스화 하면 오히려 효율이 떨어진다. 아니 개발을 거의 못할 것이다. 
프로세스는 최소화하고 나머지는 개발 문화로 커버를 하는 것이다. 
개발문화 중에서 가장 중요한 것은 공유와 협업의 문화이다. 물론 많은 개발자들이 공유와 협업을 하고 있다고 생각할지도 모르겠다. 하지만 그 수준에서는 정말 많은 차이가 난다. 
또한 회사내에서 정말 자리잡기 어려운 문화이다. 개발자들 하나하나가 습관을 바꿔야 하는 어려운 난관이 가로막고 있다. 처음에는 강제화를 해야 하는데 무엇을 강제화 해야 하는 지가 문제이다.
공유와 협업 관련된 키워드를 몇가지를 들면 다음과 같은 것들이 있다.

SRS review, SRS sign, Architecture review, Code review, Coding convension, Doxygen, Component, Interface, Wiki, Bug track, Engineering Onepager, Broken tree, Common library

공유와 협업의 문화가 자리를 잡으면 위에 언급한 모든 것들이 확연하게 바뀌게 된다. 하나하나가 엄청난 항목이므로 자세한 설명은 생략한다.


2. 개발자들의 롤모델이 없다.
 
소프트웨어 개발자들은 3,4년만 지나도 위가 잘 안 보인다. 개발자로서 계속 일을 할 수 있을지 확신이 안 선다. 개발을 계속 하고 싶기는 한데 20년이 지나도 개발을 계속 하고 있는 고참을 본 적이 없어서 그 모습이 잘 그려지지 않는다. 사실 아주 드물게 관리직을 포기하고 개발직에 머물고 있는 고참들이 있지만 그 모습이 그렇게 우러러 보이지 않는다.
그래서 개발자 10년에 관리는 전혀 안하고 개발에만 매진하는 개발자를 찾기는 매우 어렵다. 그렇게 관리와 개발 양다리에서 헤매다가 대부분은 관리로 넘어가던가 업계를 떠나게 된다.
하지만 소프트웨어 개발자라는 자리는 코딩만 놓고 보면 5년짜리 개발자나 20년짜리 개발자나 타이핑 속도가 별반 차이가 나지 않는다. 하지만 아키텍처나 회사의 전략을 바라보는 시각은 엄청난 차이가 난다. 하지만 우리나라에서는 그런 개발자를 키워내지 못하기 때문에 롤모델도 없고 개발자는 방황하고 하는 악순환이 계속되고 있다.


3. CTO가 없다. 

소프트웨어 회사의 꽃은 CTO다. 하지만 거의 모은 우리나라 소프트웨어 회사에는 CTO가 없다. 가끔 직함이 CTO인 경우는 있지만 거의 대부분 진짜 CTO는 아니다. 다른 일을 하는데 직함만 CTO인 경우이다.
CTO가 없다면 회사의 중요한 기술적인 결정을 할 수 있는 최고 책임자가 없다는 뜻이다. 따라서 중요한 기술적인 결정이 영업적인 입장에서 결정되는 경우가 많아진다. 고참 개발자들이 가끔 저항을 해보기도 하지만 우리나라에서는 직급에서 눌리는 것을 극복하기는 쉽지 않다.
또한 CTO급이 아니라면 고참 개발자들의 시각도 최고 수준에는 못 미치기 때문에 제대로 결정을 못하고 설득력도 떨어지게 된다. 
소프트웨어 업계에서 20년 이상은 개발자로 꾸준히 제대로 성장해야 CTO급이라고 할 수 있는데 우리나라에는 그런 개발자가 거의 없는 것도 한 이유이다.
당분간은 좋은 CTO를 구하고 싶어도 쉽게 구하지 못할 것이다.


4. 마케팅이 없다.
 
대부분은 치밀한 계획보다는 번뜩이는 아이디어로 시작을 해서 초기에 성공을 거두었기 때문에 마케팅에 대해서는 거의 모르고 오로지 개발자들의 마법에 의존해서 소프트웨어를 개발하곤 한다. 
어느 정도 커지기 시작하면 마케팅에도 관심을 가져야 하는데 대부분의 소프트웨어 회사에는 개발과 영업만 존재하게 된다.
마케팅도 경험을 가진 마케팅 전문가가 부족하기 때문에 왠만한 대기업을 제외하고는 마케터를 구경하기 어렵다. 마케팅에 관심이 있는 회사 주먹구구 방법밖에 모르기 때문에 별효과를 못 보거나 개발자가 알아서 개발해 줄 때보다 못한 경우도 많다.

하나하나가 워낙 갈길이 멀고 무거운 주제들이라서 마음이 무겁지만 천천히 고쳐나가야 할 것들이다.

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

'개발문화' 카테고리의 다른 글

같이 일하려면 적어라.  (6) 2011/11/01
우리 식대로  (1) 2011/10/30
우리나라 소프트웨어 회사에는 ???이 없다.  (4) 2011/07/30
주먹구구를 더 좋아 하는 이유  (11) 2011/07/17
나쁜 습관  (2) 2011/06/19
내가 소스코드를 몰래 고치는 이유  (13) 2011/02/01

전규현 개발문화 공유, 문화, 협업

Trackback Address: http://allofsoftware.net/trackback/230 관련글 쓰기
  1. Blog Icon
    정현철

    진짜 좋은 글 인거 같습니다.
    주위에 다른 개발자 분들한테도 알려 봐야겠네요

    경력은 얼마 안됬지만 왠지 개발문화가 없다는것에 진짜 공감이 갑니다. ^^

  2. 정말 슬픈 현실이네요. 이런 것을 공감하는 세대, 나 자신이 결국은 이런 현실을 개선 할 수 있겠지요. 열심히 해야 겠습니다.

  3. 1. 항목에 대해 강한 공감을 표현하고 싶습니다. 최근에 조인한 스타트업에서 공유에 기반한 개발과 더불어 코드 리뷰를 수행하려고 했으나, 수많은 마찰 끝에 각자 개발하는 영역을 나누기로 했습니다. 습관을 바꾼다는 것이 얼마나 힘든 일인지, 무엇보다 본인 스스로 변화하고자 하는 의지가 없이는 불가능하다는 것을 깨달았습니다.

  4. 안녕하세요. gsong님

    현재 결정의 비용은 미래에 10배, 100배로 치르게 되어 있습니다. 습관을 바꾸기 어렵기 때문에 처음에는 강제화가 필요합니다. 하지만 대부분의 경영자들은 개발자들의 그럴듯한 핑계를 꺽기가 어렵습니다.

    조금씩이라도 변화해보는 것이 좋겠습니다.

주먹구구를 더 좋아 하는 이유

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



이론과 실제는 다르다.

모두들 착하게 살아야 한다는 것을 알지만 많은 사람들이 착하게 살지 않고, 운동을 해야 하는 것을 알지만 대부분의 사람들은 운동을 하지 않는다. 이유는 다 있다.

착하게 살고 꾸준히 운동을 하는 사람들은 꾸준히 하다보니 특별한 목적보다도 그 자체가 좋아하고 자연스러운 행동이 된다.

소프트웨어 회사도 주먹구구식으로 개발하면 안되고 체계적으로 개발해야 한다는 것을 이론적으로는 알아도 그 구성원들은 막상 체계적으로 변화를 하려고 하면 완전히 적응되기 전까지는 크고 작은 거부감과 저항이 있게 된다.

그래서 주먹구구로 회기하려는 힘이 강하게 작용하게 된다.

많은 회사들은 자신의 회사는 주먹구구가 아니라고 생각할 것이다. 물론 Black and White로 구분할 수는 없지만 나의 경험에 의하면 우리 나라 소프트웨어 회사의 90% 이상이 주먹구구에 가깝게 개발을 하고 있고 나머지의 대부분은 체계적인 개발을 하려고 노력하고 있으나 너무 과해서 더 효율성이 떨어지거나 회사에 알맞는 체계를 갖추고 있지 못하다. 정말 극소수의 몇개의 회사들이 효율성 높은 체계를 가지고 있고 문화적으로 자리를 잡고 있다.

여기서는 주먹구구에서 벗어나기 어려운 장애 요인은 무엇이 있나 알아보자. 시간이 흐르고 자리를 잡으면 별거 아닌 것들이지만 변화에 대한 거부감들은 의외로 매우 강한 경우가 많다.

주먹구구로 계속 개발을 하다보면 초창기에는 특공대처럼 놀랄만큼 좋은 성과를 내지만 인원이 많아지고 프로젝트의 규모가 커지면서 프로젝트는 점점 늦어지고 문서는 여전히 거의 없고 정보는 공유가 안되고 회사가 도대체 어떻게 굴러가고 있는지 잘 파악이 안된다. 제품이 버그는 점점 많아지면서 고객의 신뢰를 점점 잃어가는 위기를 겪게 된다.

이를 극복하기 위해서 소프트웨어 회사가 체계를 제대로 갖춰가면
개발 프로세스를 정립하고
프로젝트를 수행하면서 문서를 만들고 
조직을 전문화하고
기반 시스템을 구축하고
공유 등 개발 문화를 정착시키기 위해서 애쓴다.

단어적으로 보면 아무도 거부할 것이 없지만 실제로 많은 저항에 부딛히게 된다.
제대로 정착하면 장점으로 가득차 있지만 오로지 단기적인 시각으로 단점만 보면 다음과 같은 것들이 있다.

 개발자

개별 개발자들이 과거에는 파워라고 생각했던 것들이 많이 줄어들게 된다.
과거에는 제품, 기술에 관련된 것들은 모두 개발자에게 물어 봐야 하고 개발자의 은총을 받아야만 일들이 진행이 되었다.
심지어는 프로젝트가 언제 끝나는지도 아무도 모르지만 개발자가 열심히 해서 끝내주기만 기다리곤 했다.
하지만 이제는 문서화를 통해서 제품의 스펙도 이미 다 공유가 되어 있고 개발자에게 물어볼 일들이 점점 줄어 들게 되었다. 개발자들은 이렇게 할 수 있도록 스펙(SRS)을 작성하는 일이 짜증나는 일이 됬다.
나중에 마음에 내키는 대로 개발도 할 수 없게 된다.
과거에는 개발자에게 요청할 것이 있으면 직접 와서 부탁을 해야 했지만 이제는 시스템에 모두 등록이 되어서 개발자들이 이슈 처리를 잘하고 있는지 못하고 있는지 만천하에 드러나게 되었다.
소스코드를 수정한 것도 한줄한줄 완전히 투명하게 공개가 된다.
프로젝트를 진행할 때도 일정이 너무 상세하게 관리되어서 압박이 심하다.
개발자가 한두명이 퇴사를 해도 회사는 잘 굴러갈 것 같은 체계로 가고 있는 것들이 개발자는 불안해지고 파워를 점점 잃는 것을 거부하게 된다.

 영업

과거에는 프로젝트를 할 때 별로 할 일이 없었다. 
개발자들이 SW를 만들어 주면 알아서 팔기만 하면 되었는데 이제는 스펙이라고 작성해와서 몇백페이지나 되는 문서를 꼼꼼히 읽어보고 사인을 하라고 한다. 그리고 나중에 잘못된 내용이 있으면 책임 지라고 한다.
개발이 힘들고 돌아다니는 것이 좋아서 영업을 하는데 공부는 개발자만큼 해야 하나보다.
고객의 요청도 개발자에게 가서 무조건 우기면 제품에 반영해주고 했는데 이슈관리시스템에 자세히 적어야 하고 내용이 만천하에 드러나므로 무조건 우길 수도 없게 되었다. 

 경영진

옛날에는 내용을 파악하려면 담당자에게 와서 보고하라고 하면 되는데 이제는 시스템에서 확인해야 한다. 이게 더 좋다고 하지만 나는 영 불편하다.
프로젝트를 진행할 때 무조건 야근과 주말작업을 강요했는데 체계화 되면서 그러기 어려운 분위기가 되어가고 있다.

 마케팅

옛날에는 제품 기능 목록 주욱 적어주면 개발자가 개발하고 이렇게 간단했는데 제품 기획을 제대로 하느라고 힘들다. 모든 내용이 문서화되고 시스템에 남기 때문에 나중에 딴 소리를 할 수 없다. 

 결론

물론 모든 구성원이 이런 저항감을 가지는 것은 아니다. 변화의 필요성을 잘 알고 적극적으로 변화를 이끄는 많은 사람들이 있다. 이런 구성원이 많다면 회사는 계속 번창해 나갈 것이다. 회사의 분위기와 상황에 따라서 매우 다르다.

하지만 많은 회사들이 이런 이유들 때문에 많은 저항에 부딪혀서 적당한 정치적인 타협으로 기형적인 구조가 되어서 망하는 길로 들어서게 된다. 이러한 저항은 특이한 현상도 아니고 아주 자연스런 현상이다. 이러한 조직 구성원은 잘못된 생각을 가지고 있는 것이 아니고 인간의 자연스러운 본성에 가깝다. 따라서 이를 비난할 수는 없고 이들을 계속 이끄는 것은 회사의 책입니다.

이 고비를 넘어가면 회사의 모든 구성원들에게 그 혜택이 돌아가고 과거에는 어떻게 그렇게 일했는지 모르겠다고 회상하는 때가 온다. 그 중에서도 개발자에게 돌아가는 혜택이 가장 크다고 할 수 있다. 개발자에게 돌아가는 가장 큰 혜택의 개발자의 몸값을 높여준다는 것이다.

나는 주먹구구 식으로 밖에 개발을 하지 못하는 개발자에게는 20년 이상의 경력이 있어도 연봉 5천도 아깝다. 하지만 체계적인 개발이 몸에 베어서 스펙도 잘 쓰고 설계도 잘하며 공유, 리뷰 문화에 익숙한 개발자는 연봉 1~2억도 아깝지 않다.

체계적으로 바꿔갈려면 감당할 만큼씩 단계적으로 변화를 해야 한다. 보통의 중소기업이 이렇게 단계적으로 변화를 하려면 2~3년 정도의 시간이 걸리고 대기업은 훨씬 더 오래 걸린다. 
또한 그 과정에서 뻔히 보이는 저항에는 굴복하지 말고 슬기롭게 헤쳐나가야 한다. 여기서 가장 중요한 것은 최고경영자의 통찰력과 의지이다. 그래서 최고경영자의 책임은 더욱 무겁다.

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

'개발문화' 카테고리의 다른 글

우리 식대로  (1) 2011/10/30
우리나라 소프트웨어 회사에는 ???이 없다.  (4) 2011/07/30
주먹구구를 더 좋아 하는 이유  (11) 2011/07/17
나쁜 습관  (2) 2011/06/19
내가 소스코드를 몰래 고치는 이유  (13) 2011/02/01
평가를 어떻게 해야 할까?  (4) 2011/01/18

전규현 개발문화 개발문화

Trackback Address: http://allofsoftware.net/trackback/227 관련글 쓰기
  1. 참... 언제나 읽으면서 느끼는건데 여기 포스트의 대부분은 책임을 하위 직원들에게 지우는 묘한 뉘앙스가 들어있네요...
    야근야근을 면치 못하는 IT회사가 거의 대부분인게 우리나라입니다.
    이게 뭘 뜻하는지 아실텐데요..
    애초에 기본적인 문제조차도 해결되지 않은 나라에서 각 파트의 구성원들이 또 손해를 감수하고 내부 구조를 바꾸도록 노력한다?
    주먹구구식밖에 못배운 배테랑 개발자의 책임이 본인에게 한정되는걸까요?

    어떤개발자도 주먹구구식을 좋아하지 않습니다 대게는 자신들이 힘들어진다는걸 개발자들은 알아요.
    그럼에도 그런 분위기가 유지되는게 가발자탓일까요 경영진 탓일까요?

  2. 안녕하세요. black_H님
    제 블로그를 많이 읽어보시면 그 책임은 회사에 대부분 있다는 말들을 많이 볼 것입니다.
    이 글은 또다른 측면을 보는 겁니다.
    누구의 책임이냐는 것이 아니고 자꾸 과거로 회기하려는 속성을 말하는 것이고 실제로 많이 존재합니다.
    우리나라에는 피해의식을 가지고 있는 개발자들이 많습니다. 그만큼 회사에서 해준것이 별로 없는 경우가 많기 때문입니다.
    또한 개발자가 변화에 거부감을 가지고 있는 것도 자연스러운 현상입니다. 하지만 이러한 거부감에 밀려서 변화를 포기하는 것 또한 회사의 책입니다.

  3. 전체의 문제인데, 그 전체 구성원 중 하위직원이 많다면, 각 개인의 문제는 %가 다르겠지요.
    전 항상 느끼는 것이지만, 전체 구성원이 모두 이해하고, 같이 잘하기 위해 노력해야 한다고 이해됩니다.

    현실 세상에서 아래로 책임을 미루는 그런 조직도 있는 반면에, 제대로 해보려해도, 방법을 몰라 헤메는 그런 조직이 더 많다고 봅니다.

    그리고 근본적으로 책임은 회사와 대표이사가 집니다.
    물론 악독 사주도 있지만...

  4. 음, 제가 보기에는 처음에는 개개인의 능력(특히 개발자의 능력)이 중요시돠다가 회사가 커짐에 따라 시스템, 제도, 어떠한 프로세스를 만들게 될 수 밖에 없고, 이에 따라야 한다는 얘기를 하시는 것 같은데요. 개발 같은 경우를 보더라도 초기 개발에서는 코딩 규칙이나 함수 명명법, 유닛 분할법등에 대한 방법론이 없지만, 시간이 가면 갈 수록 cowork이 중요시하게 되고 이러한 제도(규격)를 만들어 가게 되죠.

    저 또한 source code version 관리도 하지 않았던 예전과 비교해서 요즘에는 그나마 이런 저런 프로세스를 스스로나마 구축해 가고 있답니다. 어찌 보면 일종의 구속이죠. ^^

  5. 이경문님 안녕하세요.
    이경문님 회사같이 감당할 만큼의 변화를 해가는 것도 좋은 방법입니다. 하지만 어떤 회사는 급격한 변화를 해야할 수 밖에 없는 경우도 있습니다. 특히 대기업이 이런 방법을 많이 쓰는데 대부분 잘 적응을 못합니다.
    또 어떤 경우는 너무 천천히 변화를 해서 결국에는 어정쩡한 상태가 되기도 합니다.
    결국 가능하면 처음부터 제대로 된 체계를 갖추고 시작하는 것이 좋고 그렇지 않으면 현재 회사에 맞는 속도와 방법이 필요합니다.

  6. Blog Icon
    아리스토

    문제는 '개발을 즐길 준비가 되어 있냐?'인지 모르겠네요.
    스트레스를 받아가며 새로운 것을 수용하기는 힘들지 모릅니다. 내가 즐기기 위해서 좋은 버릇을 만들어야 한다로 보면 어찌보면 쉬운지 모릅니다. 현재 우리가 생명유지를 위해 물질적 만족을 위해 원하지 않는 개발자로 살고 있는지 먼저 생각 해 봐야 할지 모릅니다. 그리고 나면 내가 현재 만족하고 있느냐가 될거고 그리고 나서 수용하는 것을 두려워 하지 않겠죠. 원인은 스트레스이고 그 스트레스의 원인은 자기 정체성인지 모릅니다. 하고 싶은 것을 위해서 과감히 자신을 바꾸는자 생각을 하는 사람이 많지 않는 것이 현실인지 모릅니다. 거꾸로 자신을 바꿀 수 있는 테스트에서 시작하면 자신의 꿈을 찾고 도전하는 기회가 될지 모르겠네요.

  7. 개발자가 편해지려면 체계를 갖추는 것이 좋지만
    다르게 말하자면 개발자들이 너무나 많은 부분을 감당하고 있고
    급여 이상의 일을 하고 있다는 의미도 되지 않을까 생각을 합니다.


    결론은 개발자들도 자기 할일만 하고 대신 권력을 약간 포기하면 편해지려나요? ㅋ

  8. 구차니님 안녕하세요.
    아시다시피 개발을 제대로하려면 개발자는 개발에만 집중해야 합니다. 권력, 관리나 다른 잡일에 신경써가면서도 개발도 잘할 수 있을 만큼 개발이 만만하지 않습니다.
    개발자의 경쟁력은 개발 실력이기 때문에 그리고 개발을 잘하는 개발자가 더 좋은 대접을 받아야 합니다.
    지금은 어찌보면 과도기인데 점차 인식이 바뀌어 갈 것으로 생각합니다.

  9. Blog Icon
    설성운

    제 1 의 목적은
    결국엔 좋은말로는 한사람에게 권한이 집중되지 않게 하겠다는,
    경영진의 의도겠지요. 정치의 가장기본인 힘의균형을 유지하는 것이겟지요.

    의도는 좋을지 몰라도
    나쁘게 말하자면 기술자, 개발자는 언제든지 갈아 엎을수 있는 환경을 만드는 것이기도 하고요.
    저게안되면 최소한 단가라도 깍을수 있는 환경을 만들수도 있고요.


    요즘 뿐만 아니라 우리나라는 대체로 기술을 천시하는 경향이 있어서, 이런 이론이 찬사를 받을 소지가 다분합니다.

    통제에만 집중되있죠.


    일명 빅 3라는곳에서 시작된 통제로인한 프리랜서 개발의 패해가 요즘 은행사태나,
    교육시스템인 neis 에서 고스란히 드러나는건 아닌가합니다.


    잘못된 방향으로 관리가 되어진다는 의미지요.
    영어공부만 하는 사람들이 개발관리가 재대로 된까요?
    갑이니깐 가능한겁니다.

    기술천시현상의 고착화로 인해 요즘은 쓸만한 개발자들이 줄어들고 있습니다.


    그러나 여기 대부분 포스트들의 이론대로라면, 프로세스가 잘잡혀있으면
    개발자는 언제 든지 갈아 엎을수 있고, 대처될수 있겠지요.

    기술회사에게 있어서 기술이 제 1 번째 요소임을 잊어서는 안 될 것입니다.
    개발을 모르는 사람이 관리를 한다?

    과연 재대로 된 개발자 통제가 될까요?
    과연 저게 프로세스가 좋아서 현재 관리가 되고 있을가요?
    솔직히 말해서 빅3가 외주업체 관리는 되겟죠.
    왜냐면 갑이니깐요.
    프로세스라는 명목하에 희생되고 있는 수많은 개발자들의 피와땀을 잊어서는 안될것입니다.

    같은회사에서 위의 환경같이 개발을 전혀 모르는 사람이 기획하고, 일정산출하고, 개발자에게 지시하고
    솔루션을 개발한다면 관리가 될까요?

    여기글들에 해당하는건 솔직히 우리나라 빅3에게서만 해당되는 이론같습니다.

    외국을 보세요 한결같이 성공한 기업들은 기술력이 뒷받침 되는 회사들입니다.

    우리나라 IT>? 죄다 SI입니다.
    갑을 구조를 이용한 인력장사지요.

    그러니 프로세스가 중요하죠.
    모르는 분야의 기술자를 통제해야하니깐요.

    우리나라식의 개발 프로세스가 잘되어 있다는것은 다른말로하면 창의력의 말살입니다.
    현재 그문제점이 고스란히 모바일 쪽에서 드러나고 있죠.

    그래도 아직까지는 통제로 재미를 보아왓기에, 그습성을 못버리고 언론통제라는 것만 해대고 있죠 아직도.

    어느정도 까지 개발자 이탈현상이 진행될지 모르나, 그 책임은 전적으로 현 구조를 만든 빅3의 책임이라는것이 제 개인적인 생각입니다.

    얘기가 좀 삼천포로 빠진 경향도 있는데.

    무조건적인 프로세스 맹신또한 위험하다는게 제 생각입니다.
    더군다나 창의력을 요하는 작업에서는요.

  10. 좋은 글 잘 읽었습니다. 글에서 보이는 통찰력을 통해 많이 배웁니다. 문화는 곧 습관의 문제라고 이해가 됩니다. top down 으로는 회사 경영진등이 좋은 개발 문화에 대한 이해를 하고 지원을 해줘야 될 것 같고, bottom-up 으로 생각을 해보면 개발자 개개인이 변화를 위해 노력해야 될 것 같아요. 이런 변화를 어떻게 이끌어 내야 하는지 무척 궁금합니다.

  11. gsong님 안녕하세요.

    경영진이 할 일은 교육 등을 통해서 마인드를 바꾸게 해주는 일을 먼저 해야 합니다. 그리고 당근과 채찍을 통해서 강제화도 하고 포상도 해서 자연스럽게 자리잡도록 해야 합니다. 시간도 2~3년은 투자를 해야 바뀐 모습이 느껴집니다.

나쁜 습관

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





소프트웨어 회사가 프로세스를 제대로 정립하고 좋은 툴을 도입하고 개발문서도 잘 써보려고 노력하고 코딩 실력이 뛰어난 개발자들을 보유하고 있어도 넘기 힘든 벽이 있다.

우리나라 개발자들이 코딩 실력이 좋다는 것은 부정하고 싶지 않다. 처음에는 주먹구구식으로 시작을 했다가 회사가 커지고 고객이 많아지면서 문제가 있음을 깨닫고 프로세스도 만들고 기반시스템도 도입하지만 좋아지기는 하지만 기대만큼 큰 효과를 못보는 경우가 많다. 

그 이유는 개발자들의 몸에 베인 나쁜 습관들은 쉽게 고쳐지지 않기 때문이다. 나쁜 습관이 몸에 베인 개발자들도 교과서적으로는 그렇게 하면 안된다는 것을 알고 있어도 한번 몸에 베인 습관은 쉽게 고쳐지지 않는다.

나쁜 습관에 몸에 베인 것도 개발자들 탓은 아니다. 개발자들도 좋은 개발문화를 가진 회사에서 처음부터 일했다면 그런 나쁜 습관들은 경험해보지도 못했을 것이다. 

여기서 가장 중요한 개발문화는 바로 "협업"의 문화이다. "협업"을 생각하지 못하고 행동하는 하나하나가 모두 나쁜 습관들이다. 우리나라 개발자들은 협업을 해볼 기회가 별로 없다. 개발자들 스스로는 몇명씩 팀을 이뤄서 개발들을 해봤으니 "협업"을 해봤고 지금도 "협업"을 하고 있다고 말할 것이다. 하지만 그건 대부분 또하나의 주먹구구식의 일종일 뿐이다. 따라서 그런 팀은 4~5명이 한계이고 그보다 더 커지면 커지나 마나 하고 오히려 효율성이 더 떨어지는 경우도 많다.

그럼 협업의 핵심은 무엇일까요?

 첫째, 문서를 통한 협업이다.

우리는 대부분 여럿이 모여서 서로 의논하면서 개발을 하면 협업을 하는 줄 안다. 하지만 그렇게 해서는 커뮤니케이션 비용이 너무 많이 들어간다. 90%는 문서로 말하고 문서로 안되는 나머지 10% 정도만 말로 설명하면 된다. 하지만 대부분 그 반대다. 문서로 10%, 말로 90%를 커버한다. 
여기서 말하는 문서는 "SRS"(스펙문서), "설계문서", "코드"를 모두 포함한다. 또한 이슈관리시스템과 같은 시스템도 포함된다. 
스펙문서를 보고 문서 작성자 외에 다른 개발자들이 설계를 하고 구현을 할 수 없다면 아직 갈 길이 먼 것이다. 
설계문서를 보고 여러 개발자들이 일을 나줘서 흩어져서 일을 할 수 없다면 부족한 설계문서다.
코드에는 Doxygen등의 주석이 달려 있어서 해당 함수나 Class를 사용하는 동료들이 주석만 보고 사용할 수 있어야 한다. 또한 Doxygen등을 통해서 체계적으로 함수나 Class를 검색할 수 있어야 한다.
코드에 의미를 알 수 없는 숫자나 널려 있고 Public 함수들이 수시로 바뀐다면 협업을 제대로 하고 있다고 볼 수 없다. 
잘 설계가 되어서 Public interface들이 한번 정해지면 이에 대한 설명이 잘 달리고 끝까지 바뀌면 안된다.
이러한 것들이 남의 나라 얘기처럼 생각되면 아직 협업은 갈길이 멀다. 

 둘째, Peer review이다.

 Peer review를 빼고는 소프트웨어 개발을 얘기할 수 없다. Peer review하면 흔히 코드리뷰를 떠올리는데 코드리뷰는 그 중 일부이다.
Peer review에서 가장 중요한 것은 SRS(스펙) 리뷰이다. 스펙이 있어야 설계가 있고 그래야 코드리뷰도 의미가 있다.
SRS(스펙)는 프로젝트 모든 관련자가 참여하고 리뷰를 하여 완성해 나간다. SRS에는 프로젝트에 관련된 모든 내용이 들어가기 때문에 혼자서는 완성할 수 없고 리뷰를 거쳐서 모든 관련자가 검토를 해야 한다. 그리고 나면 이렇게 잘 완성된 SRS를 가지고 각자 흩어져셔 일을 할 수 있게 된다.
설계는 혼자서 하는 것보다는 여러 개발자와 리뷰를 하면서 좀더 좋은 아키텍쳐를 찾아낼 수가 있다. 개발자 개인이 가지고 있는 지식은 한계가 있어서 여러 사람과 머리를 맞대야 한다.
설계 시 다른 사람들의 다양한 의견을 받아들일 준비가 되어 있지 않다면 아직 리뷰 문화에 익숙하지 않은 것이다. SRS와 설계는 리뷰를 통해서만 완성도 있게 작성된다.
그리고 코드리뷰이다. 
이렇게 리뷰를 잘 해야만 제품의 버그나 재작업을 획기적으로 줄일 수 있다. 또한 리뷰를 통해서 서로의 지식과 경험이 공유가 되고 각 개발자들이 훨씬 빠르게 성장한다.

협업 문화가 잘 되어 있는 회사는 다른 분야의 개발자들이 입사를 해도 빠른 시간 안에 적응해서 같이 일할 수 있다.
또한 개발자 한두명이 퇴사를 해도 회사가 망할 정도로 휘청이지는 않는다. 
결정적으로 프로젝트를 더 빨리 끝낼 수 있다.

사실 문화라는 것을 말로 설명하는 것은 어렵다. 또한 말로는 다 알 것 같지만 몸에 베이지 않으면 아는 것도 아니요. 모르는 것도 아닌 어중간한 상태가 된다. 그럴 때는 회사에서 중요한 것들을 강제로 시행하는 제도도 필요하다. 물론 핵심을 모르고 무조건 강제로 하면 부작용이 더 클 수 있으므로 현재 가능하고 중요한 것부터 차근차근 해나가야 한다.

확실한 것은 이런 협업의 문화가 없이는 소프트웨어 회사가 즐겁게 일하면서 오래 살아남지 못한다는 것이다.

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

전규현 개발문화 공유, 리뷰, 협업

Trackback Address: http://allofsoftware.net/trackback/224 관련글 쓰기
  1. 어떻게 보면 알박기 개발자들이 있어서 이러한 문화가 더 정착이 안되는게 아닐가도 생각을 해봅니다

    이런 문서작업을 해서 명확하게 하면
    자신의 실력이 다 드러나고, 밑천이 바닥난다고 생각을 해서 오히려 안하고 자기만 꼬옥 껴안고 있다 보니
    이런문제가 더 발생하는 걸지두요

  2. 안녕하세요. 구차니님
    알박기 개발자라... 멋진 표현입니다. ^^

내가 소스코드를 몰래 고치는 이유

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



여러 소프트웨어 회사를 분석해보면 소스코드를 공유하는 정도에서 정말 많은 차이가 난다.
여기서 소프트웨어 회사란 소프트웨어를 개발하고 있는 회사로서 흔히 얘기하는 팩키지 소프트웨어 회사가 아니다.

SI회사, 가전회사, 산업로봇회사, 반도체장비회사, 인터넷회사, 게임회사, 금융회사 등의 다양한 회사를 모두 말한다.

이들 회사 중에서는 개발자가 소스코드를 몰래 고치고 공유도 하지 않는 회사들이 의외로 많다.

개발자가 소스코드를 몰래 고치는 이유에는 이건 것들이 있다.

 내 소스코드는 나만 알아야 회사에서 나의 파워가 유지된다.

일부 일리가 있는 이론이다. 내가 없으면 내가 작성한 소스코드를 이해하지도 고치지도 못하면 나는 절대로 짤릴 수가 없다. 문제가 있을 때마다 나에게 달려와서 이것 좀 고쳐달라고 하면 내가 좀 대단한 사람이 된 것 같은 생각도 든다. (이전에 블로그에 포스트한 글 참고)

실제로 실력이 있는 개발자들이 이런 행동을 하기도 한다. 하지만 이런 행동은 본인의 성장에 방해가 된다. 더 어렵고 가치있는 해야 할 사람이 과거의 소스코드에 발목잡혀서 휴가도 마음대로 못가게 된다. 개발자의 파워 및 가치는 과거에 있는 것이 아니고 미래에 회사에 필요한 가치에 있다는 것을 알아야 한다. 그것이 회사와 개발자의 상생의 기초이다.

 내가 작성한 소스코드의 품질이 형편없어서 보여주기 창피하다.

어떤 천재 개발자도 공유하지 않고 혼자 개발을 해서는 좋은 코드를 작성하기 어렵다. 꾸준히 공유를 하면서 다른 사람들과 의견 교환을 통해서 점점 나아진다. 혼자 개발한 코드는 이상한 코드로 가득차 있기 마련이다. 

세 사람이 걸어가면 그 중에는 꼭 스승이 있듯이 신입사원과 코드 리뷰를 해도 배울 것이 나오게 된다.

소스코드를 보여주는 것을 창피해 할 것이 아니라 자꾸 보여주고 교류를 해야 나아진다.

 엄청 어려운 것을 개발하고 있는 것처럼 행동했는데 소스코드를 보면 별 것 아니라는 것이 들통날 것 같다.

종종 접하는 문제다. 심지어는 오픈소스코드를 가져다가 동료들에게는 자기가 개발한 것 같이 자랑하는 경우도 있다. 이것은 회사입장에서 더 큰 문제가 될 수도 있다. 오픈소스 라이센스 규정을 어겨서 소송을 당할 수도 있다.

스펙을 적절하게 작성하고 설계를 하는 과정들에서 서로 리뷰를 적절하게 한다면 서로 어떤 컴포넌트를 어떤 Technology를 이용해서 개발하는지 다들 알게 된다. 어떤 것은 어렵고 어떤 모듈은 신입사원이 구현해도 될 만큼 쉬운 것인지 모두 알게 된다. 

SRS를 제대로 작성하게 된다면 모든 프로젝트 관련자가 프로젝트가 어떻게 구성되어 있고 어떻게 진행되고 있는지 훤히 할게 된다.

 너무 바빠서 공유할 시간도 없다. 

이미 불끄기 모드로 들어간 회사는 단기적인 해결책이 없다. 이런 회사에서는 서로 자기일 하기 바빠서 점점 서로 더 단절되게 된다. 또 다시 악순환이 진행된다.

시간이 좀 걸리겠지만 악순환의 고리를 끊어야 한다.

 공유를 해봤자 관심도 없다. 다들 바쁜데...

공유문화가 정착되지 않은 회사이다. 이런 회사에서 코드리뷰는 별 의미도 없다. 
시도를 해봤자 시간 낭비일 것이다. 내용을 모르는데 코드리뷰를 해도 기껏해야 Syntax 검사밖에 못할 것이다.
SRS리뷰를 먼저 시작하는 것이 좋다. SRS가 리뷰를 해야 할 것도 더 많고 SRS가 제대로 작성되어야 다음 단계인 설계, 구현이 제대로 진행되며 리뷰를 해도 내용을 알고 리뷰를 할 수 있게 된다.

이렇게 되면 "바쁜데..."라는 핑계가 조금씩 줄어들만큼 시간을 절약할 수 있게 된다.

 결론

개발자가 작성하는 모든 소스코드는 기록이 남아야 하고 남게 된다. 물론 분석, 설계도 마찬가지이다.

Baseline에 포함되는 소스코드와 문서들은 소스코드 관리시스템에 들어갈 때 설명을 적절하고 충실하게 달아야 한다. 이때 이 소스코드를 누가 리뷰했는지 기록을 남기기를 권장한다. 리뷰를 했다는 의미는 소스코드 작성자와 같이 이 소스코드에 대해서 공동책임을 진다는 의미이기도 하다. 이것이 부담스러워서 리뷰를 하지 않는다면 아무도 리뷰를 하지 않을 것이다. 서로 리뷰를 해주는 것은 모두에게 도움이 되는 것이다. 이것은 규칙으로 강요를 해서는 효과가 없고 분위기가 조성되어서 오랫동안 시행을 하여 문화로 자리를 잡아야 한다.

소스코드관리시스템에 소스코드를 올릴때는 버그ID(이슈ID)가 꼭 있어야 한다. 개발자가 원한다고 아무때나 마음대로 소스코드를 고치면 안된다. 개발자가 스스로 발견한 버그를 고칠 때도 버그관리시스템에 등록을 하고 고쳐야 한다.

이렇게 개발자가 생성한 모든 소스코드는 투명하게 모두가 볼 수 있게 한다면 이 혜택은 회사 뿐만 아니라 모든 개발자 그리고 본인에게도 돌아한다.

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

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

전규현 개발문화 SRS, 공유, 리뷰

Trackback Address: http://allofsoftware.net/trackback/211 관련글 쓰기
  1. 비슷한 얘기가 생각나네요. 두 청년이 바둑의 명인이 되기위해 산으로 가서 바둑에만 전념한지 10년째, 자신감에 찬 두 청년은 산을 내려와서 다른사람들과의 대전을했는데, 매번 졌다는 얘기에요;;

    여쭙고 싶은게, 포스팅에 대부분 SRS을 강조하셔서 제 나름대로 개발진행하면서 기능과 이렇게 개발한 이유같은걸 문서로 만듭니다. 근데 혼자하다보니 이게 과연 잘 진행되는건지 의심이 가는건 어쩔수없네요.

    SRS 세미나 혹은 교육같은게 있나요? SRS의 개념을 익히고싶습니다.
    새해복 많이받으세요~

  2. 오산돌구님 안녕하세요.

    개발하면서 기능과 그 이유를 적는다고 한 것으로 봐서 문서를 개발하고 나서 적는 다는 의미 같습니다.

    문서는 원래 개발을 하기 위해서 더 빨리 개발하기 위해서 만드는 것입니다. 지금은 문서가 나중에 필요할 것 같아서 만드시는 거죠? 이런 문서는 용도가 많이 떨어집니다.

    SRS세미나나 교육이 있기는 하지만 SRS를 익히려면 직접 SRS를 직접 쓰고 프로젝트를 진행해 보는 것을 몇년 해봐야 합니다. 그러기 위해서 처음에는 좀 배워야 하는 과정이 필요합니다.

    제 책에 보면 SRS를 배우는 방법에 대해서도 소개가 되어 있습니다.

  3. Blog Icon
    bluemonk

    책을 읽어봤는데 그렇게 하면 되겠구나 라고 하는 느낌까지는 들지 않았습니다.

  4. 안녕하세요. bluemonk님

    그것이 책의 한계인 것 같습니다. 비디오 보고 골프를 배울 수 없듯이 직접 해보면서 경험하지 않으면 알 수 없는 것이 소프트웨어 공학입니다.

  5. Blog Icon
    별의파편

    지금은 좀 덜 하지만 저 같은 경우는 몰래 고치는 게 재미있어서 그런 적도 많아요. 새로운 패턴이나 프레임워크 보면 이전 소스를 고쳐보고 싶은...
    좋게 말하면 리팩토링인데 사실 코드 갖고 놀기....회사 자산 갖고....ㅡ.ㅡ;

  6. 안녕하세요. 별의파편님
    작은 회사에서는 흔히 있는 일이죠.
    회사의 소스코드의 아키텍쳐를 바꾸는 일이라면 여러 개발자와 리뷰를 많이 하면서 더 좋은 방법들을 계속 찾는 작업이 필요할 겁니다.
    소스코드가 변경되면 테스트가 많이 필요하고 코딩 작업 외에도 많은 작업이 필요합니다. 따라서 개인이 혼자서 마음대로 변경하는 것은 나중에 문제가 될 수도 있습니다.
    작은 회사 또는 작은 팀이라서 가능한 걸 겁니다.

  7. SRS가 뭔가요?

  8. 안녕하세요. 중원님
    스펙문서를 말합니다. 제 블로그에서 SRS로 검색을 해보시며 많이 나옵니다.

  9. Blog Icon

    비밀댓글입니다

  10. 감사합니다. ^^

  11. Blog Icon
    ymir

    협업에 관련된 포스트를 읽다가 이 포스트로 넘어왔네요.
    소스를 팀의 산출물로 협업을 통해 관리하는 경우에는 생각보다 투명하게 일이 진행됩니다.
    그러나 중소규모의 회사일수록 그런 경우는 많지 않으며..
    오히려 소수의 인원이 거대 모듈들을 작업하는 경우가 많고, 협업을 하는 케이스가 적습니다.
    그러다 보니.. 소스에 대한 관리 책임이 순전히 개인에게 넘어가버립니다.
    이런 경우 버그가 발생하면 결국 개인의 능력과 실력을 의심당하게 되고..
    회사에 피해를 끼치는 식으로 인식되어 버립니다.
    소위 욕먹고 깨지고 페이에도 문제가 생길수 밖에 없는 구조가 되어 버리죠.
    결국은 책임 회피를 위한 나몰라, 거짓말, 몰래 체크인, 다른 이의 계정으로 체크인 등...
    시스템과 프로세스를 무력화 시킬 수 있는 온갖 방법들이 동원되기도 합니다.
    코드를 대하는 마인드가 변하지 않는 한, 소위 이 '나쁜 습관'들은 쉽게 고쳐지지 않을 것 같습니다.

  12. 안녕하세요. ymir님
    다른 사람 계정으로 체크인은 좀 심하네요. ^^

  13. Blog Icon
    ymir

    다행(?)히도 그런 사례는 서너개의 회사를 거치는 동안 딱 한 번 봤습니다. =)

평가를 어떻게 해야 할까?

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


개발자 여러분 평가철이 다가왔습니다. 이미 평가를 끝낸 회사도 있을 것이고 한창 평가를 하고 있는 회사도 있을 것입니다.

평가가 항상 만족스럽고 공정하다고 생각하나요? 그렇지 않은 분들이 더 많을 겁니다.

평가 시에 자주 보는 것은 개발자들 순위 매기기 입니다. 흔히 "나래비" 세운다고 하죠. (일본말에서 유래)
대부분의 개발자들은 이런 순위매기기의 결과가 공정하지 않다고 생각하고 팀워크를 깨기 일쑤입니다.

A평가를 받은 개발자와 D평가를 받은 개발자의 차이가 크지 않은 경우가 많습니다.  심지어는 더 잘한 개발자가 더 낮은 평가를 받는 경우가 흔합니다. 그런데 평가시스템에서 A는 10%, B는 50%, C는 30%, D는 30%를 할당 받아서 무조건 나눠야 하는 경우가 있습니다. 개발자가 5명밖에 안된다면 나누기도 어렵습니다. 기계적인 평가시스템 적용이 1년 동안 고생한 개발자들을 한순간에 힘을 잃게 할 수도 있다.

물론 D 평가를 받아야 할 개발자도 있을 수 있으나 열심히 일했고 성과도 꽤 잘 냈음에도 불구하고 D평가를 받는 개발자들도 있습니다. 그렇다고 평가를 관리자 마음대로 하라고 할 수도 없습니다. 그럼 더 엉망이 될 것입니다. 

평가는 불공평할 수밖에 없지만 불공평하다는 의식이 너무 팽배해지면 개발자들이 진정으로 열심히 하려고 하지 않을 것입니다. 평가를 잘 받기 위한 편법이 난무할 수 있습니다.

이렇게 평가가 공정하지 못하다는 인식은 평가의 기준이 애매하거나 없기 때문인 경우가 많습니다. 팀장 또는 관리자가 맘에 내키는 대로 평가를 하면 무슨 기준으로 평가를 했는지 알 수 없는 개발자들은 평가 결과를 납득하기가 어렵습니다.

그렇다고 너무 구체적인 평가 기준(KPI)도 문제가 됩니다. 몇가지 예를 보죠.

  • 개발 일정을 맞추면 평가를 잘 주겠다. 
    코드는 엉망으로 만들어서 유지보수를 어렵게 만들지만 일단 일정은 지킵니다. 하지만 나중에 유지보수 개발자들이 엄청난 고생을 하게 됩니다.

  • 버그를 많이 찾으면 평가를 잘 주겠다. 
    테스터는 스펙, 설계단계의 검토를 소홀히 하여 버그가 더 많이 발생하도록 합니다. 전체적으로 프로젝트 기간이 늘어나고 비용도 증가합니다.

  • 버그를 적게 만들면 평가를 잘 주겠다.
    개발자는 최대한 일을 적게 하려고 하게 됩니다. 약간의 리스크가 있는 시도도 두려워하게 되며 새로운 기술도 연구하지 않게 됩니다.

이쯤 되면 개발자는 공장의 생산직 직원처럼 평가가 불가능하다는 것을 눈치채셨을 겁니다. 개발자들은 원래 돈에 그렇게 좌지우지 되지 않는데 공정하지 않은 평가를 몇번 받게 되면 기분이 나빠서라도 평가를 잘 받기 위해서 편법을 동원할 수 있게 됩니다.

흔히 하는 실수 중의 하나가 평가가 이렇게 부정확한데도 불구하고 평가에 의해서 A와 D 등급의 개발자를 엄청난 연봉 인상의 차이를 두면 개발자들이 더욱 열심히 일할 것이라고 생각하는 것입니다. 이는 착각이며 자칫하면 평가만 잘 받기 위한 편법이 난무하게 되며 평가의 결과는 불공정하다는 불만만 팽배하게 됩니다.

공정한 평가는 필요하지만 100% 공정하기는 불가능합니다. 그렇다고 평가를 하지 않을 수 없습니다. 평가는 잘못 휘두르면 안 한 만도 못하게 되고 그렇다고 안 할 수도 없는 균형잡기 어려운 줄타기입니다. 그리고 다음과 같은 기준은 세울 수 있습니다.

  • 평가 기준은 회사의 비전과 일치해야 한다.
  • 평가 기준은 평가자나 피평가자 모두가 납득해야 한다.
  • 평가 기준은 연초에 미리 정해야 한다. 
  • 평가 기준은 객관적이어야 한다. 즉 평가 가능해야 한다.
  • 평가 결과를 너무 믿지 말아야 한다. 적당히 활용해야 한다.
평가의 목적은 결과를 보고 상과 벌을 주기 위한 것이 아닙니다. 평가기준이 회사의 비전을 절묘하게 잘 반영하여 하나의 목표를 가지고 매진할 수 있도록 하기 위한 것입니다. 잘 만들어진 평가 기준은 평가 결과를 가지고 벌을 주지 않아도 이미 목표를 달성한 것입니다.

A를 받은 개발자는 기분이 좋고 C나 D를 받아도 별로 기분이 나쁘지 않은 그런 평가 어디 없을까요?

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

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

전규현 개발문화 평가

Trackback Address: http://allofsoftware.net/trackback/207 관련글 쓰기
  1. 2011/01/19 00:13
    업무 평가 하기 Tracked from 세상을 놀라게 하자!
  1. Blog Icon
    csj

    야구에서도 에러, 즉 수비 실수를 줄이는 방법은 간단합니다.
    공이 날라올 때 뛰지말고 천천히 걸어가는거죠 ^_^
    그러면 수비 할 상황 자체가 안되기 때문에, 에러로 기록되지 않습니다.

    여하튼 평가라는게 기준 정하기가 참 힘들더군요.
    사실 저야 겨우 대학원 프로젝트 팀장인지라 평가 기준이 그다지 필요하지는 않습니다만,
    후배를 평가해야 할 일 이 있으면, 가능한 장점을 위주로 평가하려고 노력 합니다.
    물론 단점을 고려해야 겠지만, 그 단점을 매워주기 위해 팀원들이 있는거고..

    하지만 회사를 가게 되면,누군가 월급을 더 주어야 하고,
    회사 사정이 안 좋으면 누군가 잘라야 하고..
    평가라는게 서로의 장점을 파악해 시너지 효과를 내기 보다는,
    부정적인 용도로 사용될 것 같기도 하네요 -_-;;

  2. 안녕하세요. csj님
    우리나라 회사들은 평가에서 실패하는 경우가 매우 많습니다. 주먹구구식 개발을 하다보니 평가도 주먹구구로 하는 경우가 많더군요.

  3. Blog Icon
    초마

    우리 회사를 보는듯 하네요.. 기준을 알 수 없는 평가를 하고 그 평가를 기준으로 인센티브나 연봉인상을 정하는.. 이러면 안되는데 하면서도 의욕이 자꾸 저하되고.. 참 암담하네요^^;

  4. 안녕하세요. 초마님
    평가는 개발자가 회사를 어떻게 해볼 수 없는 부분이네요. 높은 자리에 있으시면 정책에 영향을 좀 주겠지만, 그렇지 않으신 것 같네요.

기존 소프트웨어를 버리고 언제 새로 만들어야 할까?

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


Windows Vista가 나온지 얼마 되지도 않은 시점에서 Windows7이 나온다고 하더나 이제는 Windows8이 출시될 것이라는 얘기가 떠돌고 있습니다.
아이폰4도 출시된지 알마 안된 시점에서 아이폰5가 출시될 것이란 얘기가 나왔습니다. 어쩔 때는 이것이 진짜인지 그냥 루머인지 구분이 안되기도 합니다.

소프트웨어 개발을 제대로 이해하고 있는 사람들이라면 Windows7이 출시됨과 동시에 또는 이미 그 이전에 Windows8은 시작이 되었다는 것을 알 수 있습니다.

소프트웨어는 끊이 없이 업그레이드가 되어야 합니다. 그러다보면 새로운 요구를 더이상 담을 수 없는 시점이 오게 됩니다. 그래서 소프트웨어의 아키텍쳐도 끊이 없이 발전하게 됩니다. 

지금의 소프트웨어가 새로운 요구를 더이상 담을 수 없는 그릇이 되게 되면 이미 상당히 늦었다고 볼 수 있습니다.
미래에 생길 요구사항을 미리 예상하여 그 구조를 만드는 것이 소프트웨어 아키텍쳐링입니다. 물론 예언자처럼 미래의 모든 상황을 예측할 수는 없지만 상당부분 예측을 해야 하며 여기서 성공을 하느냐, 실패를 하느냐에 따라서 비즈니스의 성공이 달려있습니다.

그런데 현실에서 보면 소프트웨어 아키텍쳐를 바꿔야할 시점을 놓친 회사들이 매우 많습니다. 이런 회사의 특징은 다음과 같습니다.
  • 소프트웨어에 기능을 추가하거나 버그를 수정하려고 해도 기존의 소스코드가 워낙 복잡해서 분석도 어렵고 고치는데 시간이 많이 들어간다.
  • 버그를 수정해도 이전에 없었던 문제가 자꾸 다시 생겨난다.
  • 유지보수에 바빠서 신규 제품 개발은 꿈도 못 꾼다.
  • 기존 제품을 잘 알고 경험이 많은 개발자들은 유지보수하느라고 바빠서 새로운 아키텍쳐를 연구할 시간이 없다. 그래서 신규 개발자를 투입했는데 진도가 안나간다.
뻔히 다 알다시피 우리나라 대부분의 소프트웨어 회사들은 초창기에 뛰어난 몇몇 개발자들이 주먹구구식으로 상당히 좋은 소프트웨어를 개발해서 좋은 평가를 받으면서 성장해왔습니다. 그런데 회사가 커지고 소프트웨어가 커지면서 작은 조직일 때는 드러나지 않은 주먹구구 방식 때문에 효율성이 급격히 떨어지게 됩니다. 그러다보니 항상 유지보수에만 매달리고 신규 개발에는 투자를 못하게 됩니다. 대부분의 경우 소프트웨어 아키텍쳐가 4~5년 넘어가게 되면 더이상 버티기 어려운 상황에 닥치게 됩니다.

이미 마지막 기회를 놓친 회사들은 끊임 없는 유지보수에 매달리면서 회사의 쇠락을 지켜볼 수 밖에 없습니다. 수많은 회사들이 지금이 마지막 기회라는 것을 인지하지 못하고 지나쳐 버리는 것을 보면 안타깝습니다. 그나마 영업이 잘되는 회사는 막대한 인원과 자금을 투입하여 점점더 되돌아 오기 어려운 길로 가버리기 때문에 회생하기 더 어려워 집니다. 이렇게 침몰하는 거대한 여객선 같은 소프트웨어 회사들이 상당히 많고 경영진들이 이를 알지 못하는 경우도 매우 많습니다. 경영진들은 개발에서 구멍이 났다는 것을 알아도 그 구멍을 어떻게 매워야 하는지 정확하게 모르는 경우가 대부분입니다. 그래서 이런 저런 시도를 하다가 침몰만 가속화 시키곤 합니다. 그래도 시도를 안할 수는 없겠죠.

그럼, "언제 다시 만들어야 하는지?" 질문으로 돌와와 보죠. 
회사마다 제품의 성격과 규모마다 다르지만 대부분은 첫번째 제품이 개발되면서 이미 두번째 제품의 기획도 시작이 되어야 합니다. 또한 두번째 제품을 누가 개발을 할지 언제 개발을 할지 계획을 미리 가지고 있어야 합니다.
첫번째 제품은 개발 후에 유지보수는 어떻게 진행을 하고, 누구는 두번째 제품에 투입이 되어야 하는지 등의 계획을 미리 가지고 있어야 한다는 뜻입니다.
이 얘기는 무슨 뜻이냐면 처음부터 개발을 체계적으로 하면 된다는 뜻입니다. 분석이 제대로 되고 설계가 제대로 되어야 해결이 된다는 얘기 입니다.

그럼 이미 첫번째 제품을 주먹구구식으로 개발을 한 회사는 어떻게 해야 할까요? 지금이라도 두번째 제품을 체계적으로 다시 기획을 해야겠죠. 주먹구구의 결과로 필요한 상당히 많은 자료는 개발자들의 머리속에 들어 있습니다. 이것들을 끌어내서 문서화 하면서 두번째 제품을 기획하고 분석을 해내야 합니다. 개발자들은 이미 기본의 제품이 가지고 있는 문제점과 개선점을 아주 잘 알고 있습니다. 문제는 이것들이 문서화가 되어 있지 않고 리뷰가 안되었다는 겁니다. 이것들을 문서로 끌어내는 것만으로도 두번째 제품의 상당한 스펙이 됩니다. 또한 업계 동향과 신기술도 끊임 없이 조사를 해야 합니다.

그럼 이미 두번째 제품을 만들 마지막 기회를 놓친 회사들은 어떻게 해야 할까요? 
늦었다고 생각할 때가 가장 빠른 때입니다. 쉽지는 않겠지만, 큰 고통이 따른 변화가 필요합니다. 기존의 영업의 손실을 감수하고라도 유지보수 정책의 전면적인 변화가 필요하며 새로 투자를 더 해야 할 수도 있습니다. 회사의 조직과 프로세스의 전면적인 개혁도 필요할 것입니다. 즉, 다시 원칙에 충실해야 한는 거죠. 이 과정에서 개발자나 회사 모두 고통이 따르겠지만 이렇게 해서 성공할 것 같으면 시도를 할 수도 있고 그런 확신이 없다면 그냥 지켜보는 수 밖에 없을 겁니다. 

귀사의 소프트웨어는 어느 시점에 와 있나요? 곰곰히 생각해보시기 바랍니다.

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

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/206 관련글 쓰기
  1. Blog Icon
    별의파편

    흠... 가만 보니 저희 회사가 주먹구구로 시작해서 나름 잘 됐는데 두번째 개선에서 죽 쑤는 중이네요.
    거기다 소통도 안되고 뒷방에서 뭔가 왔다갔다 하니까.. 걱정이네요.

  2. 안녕하세요. 별의파편님
    이런 증상은 매우 흔합니다. 일반적인 과정입니다.
    두번째는 방법이 달라져야 합니다. 더이상 구먹구구는 안됩니다. 그런데 과거의 성공에 대한 환상을 가지고 있는 경연진은 몇몇 개발자들을 특공대처럼 구성해서 만들려고 합니다.
    하지만 이미 회사는 이전의 규모가 아니고 시장의 요구도 몇배 커졌기 때문에 십중팔구 실패를 맛보게 됩니다.

  3. Blog Icon
    soma

    제가 속한 회사도 이제 한 제품을 끝내려 합니다.
    한동안 정신없이 날밤 새다가 요새 정시 퇴근하며 기력을 되찾고 있습니다. 그렇지만 어딘가 허전한데 원인을 통 몰라 혼자 헤매고 있던 와중에 귀가 번쩍 뜨이는군요. 정말 감사합니다. 문서 기타 등을 정리하려면 막 끝낸 시점만큼 좋은 때가 없죠. ^^ 다른 팀원은 쉰다고 하더라도 저는 첨부터 끝까지 차분히 리뷰/정리해봐야겠습니다. ^^

  4. 안녕하세요. soma님
    더이상 시장이 없어서 단종을 하시는 것인지? 다음제품 또는 대체 제품을 만들고 이전 버전을 단종하는 것인지 궁금하군요.
    이전 제품을 차분히 분석해서 lesson learned 를 파악하는 것도 좋습니다. 하지만 끝나고 몰아서 정리를 해보는 것은 누락된 것이 엄청나게 만을 겁니다.
    평소에 wiki나 이슈관리시스템을 이용해서 전 개발자들이 모든 이슈를 정리하는 습관을 가지는 것이 좋습니다.
    이것들은 추후 중요한 스펙이 됩니다.

  5. Blog Icon
    soma

    늦게 달게 됐군요.^^;
    단종/대체가 아니고 신규 제품을 처음 서비스하게 됐습니다.
    저야 개발자 입장에서 서비스 들어가니 이제 개발이 어느정도 끝났다고 생각하지만 뭐.. 현실도 그렇진 않지요. ^^; 다만 지금 제품의 다음 버전은 막 서비스하기 시작하는 지금 시점부터 준비하는게 가장 확실하다고 본문을 읽고 느끼게 됐습니다.

  6. 끝낸다는 것이 프로젝트가 끝난다는 뜻이었군요.

  7. Blog Icon

    주먹구구가 되는 가장 큰 이유는 돈 문제죠.

    조직이 되었던.. 개발 프로세스를 관리 해줄 솔루션이든.

    만들어내고 도입을 할려면 자금이 들어가야 되고.

    더군다나 초기에는 주먹구구식이 비용이나 생산성에서 더 효율적입니다.

    적절하게 조직을 만들고, 프로세스 관리를 도입하는게 경영진의 몫이겠죠.

    개발자에게 관리까지 떠 넘기는건 문제가 있습니다.

    그런데 초기 핵심 개발자들이 진급하면서 관리롤이나 영업롤을 맡는 경우가 상당수라서..

    여기서 병목현상이 벌어지기도 합니다.


    개발자는 개발만 시키고..

    제품 라이프 사이클에 맞춰서 경영진이 현명한 판단을 해야곘죠.

  8. Blog Icon

    비판은 아니고요.. 의견입니다.

    주먹구구식으로 하는 개발 비용 vs 체계적인 설계를 해서 개발하는 비용
    두 비용은 비슷하다고 봅니다..

    초기비용은 전자가 덜 들겠지만 어차피 Q/A를 할 때 비용이 더 많이 들어가리라고 봅니다.

    핵심개발자가 진급하면 영업롤을 맡기는 회사라면 회사 자체에 좀 문제가 있지 않을까 합니다.

  9. 안녕하세요. 쩝님
    개발자에게 관리를 맡기는 것은 저도 항상 반대를 합니다.
    대부분의 회사가 주먹구구로 개발을 하는 이유는 주먹구구밖에 방법을 모르기 때문이라고 생각하고 있습니다. 실제로 많은 소프트웨어 회사를 접한 저는 충분히 많은 사례을 가지고 있습니다.
    시간과 돈만 있으면 우리도 문서를 잘 만들고 체계적으로 개발할 수 있다고 하는 사람도 많지만 시간과 돈이 있어도 제대로 못합니다.
    또한 혼자 개발을 해도 체계적으로 개발하는 것이 더 빠릅니다.
    이것이 소프트웨어 공학에서 가장 이해하기 어려운 부분입니다. 이것을 이해하고 있다면 소프트웨어 공학을 이미 다 이해한 것입니다.
    체계적으로 개발하는 방법을 모르는 개발자나 회사는 오로지 주먹구구식으로 개발하는 방법밖에는 모릅니다.
    이 경우 프로젝트의 규모가 작다면 주먹구구식으로 개발을 해도 프로젝트를 성공할 가능성이 있습니다. 그래서 주먹구구에 대한 환상을 가지고 있는 경영자들도 많습니다.
    그리고나서 몇번 실패를 맛봐도 실패의 탓을 주먹구구 방식으로 돌리지 않고 개별 개발자나 다른 이유를 찾기도 합니다.
    경영자가 현명해져야 합니다.

  10. 안녕하세요. 몽님
    몽님도 대체로 소프트웨어 공학을 이해하고 계신 것 같군요.
    하지만 조금더 이해를 하면 체계적으로 개발하는 것이 주먹구구 방식보다 비용이 적게 들고 프로젝트 시간도 절약된다는 것을 아시게 될 겁니다.
    여기서 "체계적"이라는 용어에 대해서 서로 오해를 합니다. 형식적인 프로세스밖에 경험하지 못한 개발자들은 "체계적"이라는 것을 천편일률적으로 생각하고 매우 거북한 것으로 생각합니다.
    "체계적"이라는 단어를 "효율적"으로 바꾸면 더 이해하기가 쉬울 겁니다. 설계를 하더라도 필요한 만큼 효율적으로 한다고 보면 됩니다. 이를 판단하기 위해서는 경험이 많이 필요합니다.
    그리고 유지보수 할 때는 말할 나위도 없죠. ^^

  11. Blog Icon
    스피드

    좋은 정보가 많네요.
    "효율적"인 프로세스 도입이 좋은것은 자명하겠지만 현실적으로 그렇게 되지 않는데는 이유가 있겠지요.
    구성원들이 그 효율성에 대한 개념을 이해하기 위해서는 능력과 경력의 동반이 반드시 필요한 것 같습니다.
    게다가 현실적으로 몇 몇 뛰어난 개발자 및 경영자는 그런 프로세스 무시하고도 성공을 하는모습을보여주니
    대부분의 소규모 소프트웨어 개발회사들이 어떤 방법을 택할지 선택을 못하는 경우도 있습니다.
    우리나라 소프트웨어산업 발전 및 종사자들의 처우 개선을 위해서는 현실에 맞는 소프트웨어 공학의 발전이 우선되어야 하는건 아닌가 하는 생각도 듭니다.

  12. 스피드님 안녕하세요.
    맞습니다. 평생 그렇게 해서는 구멍가게 밖에 못하죠. 또한 그런 프로그래밍영웅들은 주먹구구식으로 밖에 개발을 못해서 그런거죠.
    사실 프로그래밍영웅 개발자도 할말은 있습니다. 자신들도 제대로 배울 기회가 없었기 때문이죠.
    그래도 Open mind만 있고 소통이 중요하다는 것을 깨달으면 계속 주먹구구 방식을 고집하지는 않겠죠.

  13. 1. 이 블로그에 오면, 글도 글이지만, 댓글에서도 많은 것을 배우고 갑니다. 항상 좋은 글 올려주셔서 감사합니다.

    2. 그 때 칭찬해 주신 Mercurial 관련 글을 http://sainthkh.codex.kr/lec/Mercurial/mercurial.html 에 모아 두었습니다. 현재 서버 만드는 법에 대한 것이 좀 빠져서 아쉬운데 나중에 공부해서 꼭 올려보겠습니다.

    3. 나중에는 Mercurial 강좌 스타일로, 명세서 작성법에 대한 이야기가 하고 싶기는 한데, 언제가 될는지 모르겠습니다. 저조차 명세서 작성에 대한 글을 쓰기에는 너무 많이 부족하다는 생각을 해서요. 5페이지 정도 작성했던 GUI 관련 명세가 부실하다는 것을 깨닫고, 명세서 Refactoring을 시작했습니다.


    4. 지금 가르쳐주시는 많은 것들을 학교에서 가르쳐 주면 참 좋겠다는 생각을 합니다. 전에 한 번 동기들에게 Subversion 강의하면서 돌아다녔던 기억이 나네요... 교수님들도 이것들이 왜 필요한지 이해하지 못하시는 분들도 많은 것 같습니다.

  14. 안녕하세요. 주의사신님
    제 블로그에서도 명세(스펙, SRS)관련된 글이 많고 책에서도 가장 많이 강조를 하지만 소프트웨어를 개발하는데 있어서 가장 중요하고도 어려운 분야이기 때문에 글로 설명하기 쉽지 않을 겁니다.
    글을 올려주시면 같이 의논해볼 좋은 기회가 될 것 같습니다.
    소프트웨어 공학을 대학에서 가르치는 곳도 있었습니다. KAIST에서는 대학원 과정으로도 있습니다. 하지만 일부 대학 교수님 중에는 이론에 치중해서 실전에는 약한 분들도 있기는 합니다.
    단, 소프트웨어 공학은 학교에서 배웠다고 하더라도 실전에서 경험하지 않으면 진짜 배운 것이라고 하기 어렵습니다. 즉, 경험이 가장 중요하다는 말입니다.

  15. 확실히 개발중인 모듈을 언제 포기하고 다시 재설계해서 만들어 낼지를 결정하는 것도
    상당히 힘든 선택이고, 이러한 결정 자체도 점점 두려워지더라구요.

    그래도 그 이전의 버전을 설계/개발하면서 가진 노하우가 있으니 금세 보완하고 더욱 좋게 만들수는 있지만 말이죠 ^^

  16. 구차니님 안녕하세요.
    노하우는 축적되나 개발 방법에서는 별 진전이 없는 경우가 많습니다. 그래서 기술은 더 좋아졌으나 프로젝트에 실패하는 경우가 많습니다. 즉 시작은 더 오래 걸리고 품질도 떨어지곤 합니다. 또한 기존에 축적된 노하우만 추가하다보니 미래의 요구사항을 반영하지 못해서 금방 또 고쳐야 하는 요구가 생기곤 합니다.
    개발자가 골고루 실력이 향상될 수 있어야 하는데, 코딩 실력만 늘기 쉬운 것이 문제입니다.

왜 나만의 방법이 실패하는지? (NIH 신드롬)

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


NIH(Not invented here) 신드롬이란?
카츠와 알렌(Katz & Allen)은 기업연구에서 “선진 기업의 연구조직은 흔히 자신들이 직접 개발하지 않은 기술이나 연구 성과에 대해 배타적 성향으로 보인다”고 주장하며 이러한 현상을 NIH 신드롬이라고 정의했다.

소프트웨어를 개발하는데 있어서도 NIH신드롬과 유사한 현상이 많이 발생합니다.
개발하는데 필요한 라이브러리나 개발 방법, 개발툴들을 모두 입맛에 맞게 직접 만들어서 쓰는 경우를 말하는 겁니다.

우리나라의 개발자들이나 소프트웨어 회사들은 특히나 더 자신만의 방법들을 선호하는 경향이 있는 것으로 생각됩니다. 여러가지가 이유가 있겠지만 몇가지만 나열해보면 다음과 같습니다.
  • 라이브러리를 구매하는 비용을 비싸다고 생각한다. 특히나 회사에서 개발에 필요한 라이브러리는 잘 안사준다.
  • 더 좋은 방법이나 라이브러리, 툴이 있을 수도 있지만 이것들을 찾을 시간이 없이 바쁘거나 귀찮다.
  • 관련 자료들이 대부분 영어로 되어 있는데 영어가 딸려서 영어로 된 자료는 꺼려한다.
  • 외부의 기술이나 방법은 자신이나 회사의 상황에 맞지 않는다고 생각한다.
  • 자신의 기술과 실력이 더 우월하다고 생각한다.
  • 주변에 경험이 많은 선배들이 적어서 자문을 구하기가 어렵다.
이러한 현상은 집을 만들어야 하는 사람이 나에게 알맞은 망치는 내가 더 잘 만든다고 생각하고 망치도 직접 만드는 것과 비교할만 합니다.

 상용 라이브러리는 비싸다.

흔히들 상용라이브러리는 너무 비싸다고 생각하고 직접 만들어 쓰는 경향들이 있습니다. 하지만 직접 만들어 쓸 때 발생하는 유지보수 비용은 미처 생각하지 못하고 이런 결정을 하는 경우들이 많습니다. 아니 이런것들을 고려하는 것은 커녕 개발자들이 무슨 라이브러리를 만들었는지 회사에서는 또는 동료들은 잘 모르는 경우도 있습니다.
물론 세상에 이전에는 없었던 라이브러리던가 진짜 그 회사만의 독특한 상황을 반영한 라이브러리나 툴이 없는 경우는 예외일 것입니다. 경계할 것은 이런 경우는 그렇게 흔하지 않기 때문에 착각하면 안될 것입니다.

일단 직접 만들고 나면 유지보수 비용이 상용 라이브러리를 썼을 때보다 비용이 몇배 더 드는 경우가 아주 흔합니다. 이때 직접 개발한 것이 훨씬 비싸다는 것을 깨달았어도 이쯤되면 다시 되돌리기가 매우 어렵습니다. 앞으로도 비용이 계속 더 들 것이지만 이를 되돌리는데도 너무 비용이 많이 들기 때문에 그냥 계속 가는 수밖에 없는 경우가 많습니다.

요즘은 오픈 소스 라이브러리가 매우 많으므로 선택의 폭이 매우 넓습니다. 이때 오픈 소스를 수정해서 쓰게 되면 나중에 오픈 소스가 업그레이드 되었을 때 머지(Merge)하는 것이 어려울 수 있으므로 이에 따른 비용도 감안해서 검토해야 합니다.

 직접 만들 시간은 있어도 남이 만든 좋은 것을 찾을 시간은 없다.

사실 대한민국의 개발자들은 항상 바쁜 것처럼 보입니다. 그래서 차분하게 검토할 여유가 없습니다. 이는 매우 안타깝게 생각합니다. 또한 뭔가 계속 코딩을 해야 일한 것 같은 분위기는 검토하는데 시간을 쏟는 것을 어렵게 만듭니다.

라이브러리를 무작정 직접 만들기보다는 쓰기 적합한 좋은 상용라이브러리가 없는지 미리 검토하는데 시간과 노력을 투자하는 것이 대충 만들어 놓고 나중에 후회하는 것보다는 훨씬 효율적입니다. 물론 모든 검토 결과 직접 만들어 쓰거나 오픈 소스를 수정해서 사용하는 것이 더 좋다는 결론이 날 수도 있습니다. 하지만 이런 결정을 하기 위해서 쏟은 노력과 시간은 그렇게 아깝지 않습니다.

 영어자료는 꺼려진다.

이 부분에 대해서는 할 말이 별로 없습니다. 영어는 소프트웨어 개발자를 평생 따라다닙니다. 꾸준히 공부하는 수 밖에 없을 겁니다.

 이건 우리에게는 맞지 않다.

"우리회사는 다르다."라고 생각하는 것은 착각입니다. 우리에게 필요한 것의 99.99%는 이미 다 나와 있다고 생각하면 됩니다. 즉, 있을 것은 다 있고 문제는 가격, 배우는 비용 등입니다. 
그리고 프로세스나 툴을 보면 특히나 자신의 회사가 독특하다고 생각하는 사람들이 많습니다. 물론 이 세상에 똑같은 회사는 하나도 없습니다. 하지만 소프트웨어를 개발하는 방법은 거의 모든 회사가 별로 다르지 않습니다. 유명한 툴이나 흔히 사용하는 프로세스가 자신의 회사와는 맞지 않다면 자신의 회사에 딱 알맞은 것을 무조건 만들기보다는 회사의 프로세스가 잘못된 것이 아닌가 먼저 검토해보는 것이 좋습니다. 회사의 프로세스가 잘못된 경우가 99%입니다.
거꾸로 말하면 세계적인 툴이나 프로세스를 쓰면서 이에 적응해 가는 것이 개발을 더욱 효율적으로 만드는데 도움이 될 수 있습니다.

 내가 더 잘한다.

지금 내가 가지고 있는 지식은 99%이상 선각자들이 이룩해 놓은 것들입니다. 모짜르트도 제대로된 방법으로 훈련을 받지 못했으면 지금같이 위대한 작곡가가 되지 못했을 겁니다. 
99%의 것을 배우는데 노력하고 거기에 내가 1%를 더하는 것이 올바른 방법일 겁니다. 

물론 특정 분야에서 이전의 모든 선각자보다 뛰어난 사람이 있을 수 있습니다. 이렇게 뛰어난 개발자라면 그 실력을 망치를 만드는데 쓰기 보다는 빌딩을 만드는데 쓴다면 더 뛰어난 빌딩이 만들어 질 겁니다.
물론 망치를 제일 잘만드는 사람은 망치를 만들어서 팔면 될 것입니다.

 물어보고 싶은데 물어볼 사람이 없다.

이 부분도 안타깝습니다. 대분의 개발자들의 경험담을 들어보면 회사에 입사에서 별로 배우지 못했다고 합니다. 회사를 입사해서 스스로 거의 모든 것을 만들어야 했고 선배들이 별로 없는 경우가 많았고, 회사가 커진 다음에 입사를 한 경우에도 선배들도 유지보수에 바빠서 각자 개발하느라고 정신이 없어서 선배들에게 별로 배울 기회가 없었다고들 합니다.
다행이라면 요즘은 인터넷을 통한 소셜 커뮤니티가 발달해서 정보를 공유하기 훨씬 수월해졌습니다. 이런 다양한 외부 자원들을 활용하는 것도 좋은 방법입니다.

 결론

소프트웨어를 개발하면서 내가 겪는 거의 모든 상황은 이전에도 있었습니다. 그것도 매우 여러번 발생했었고 그에 대한 해결책도 이미 다 나와있습니다. 라이브러리, 툴, 프로세스 거의 모든 것이 이미 나와있고 이중에서 꼭 필요한 것을 제대로 찾아서 사용하는 것이 매우 중요하며 쉽지 않은 일입니다. 
뭔가 툴이나 라이브러리를 만들고 싶으시면 한번 더 생각해봅시다.

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

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

전규현 개발문화 NIH

Trackback Address: http://allofsoftware.net/trackback/205 관련글 쓰기
  1. 회사에서 필요한기능은 A인데 라이브러리에 포함된 기능은 A,B,C 일때 웬지 부하는 걸리지않을까 라는 걱정이 생기는것도 한몫 하지않을까요?
    여러 라이브러리를 아는것도 실력인것같습니다~~재밌는글 잘봤습니다

  2. 오산돌구님 안녕하세요.
    좋은 지적이십니다.
    실제로 외부 라이브러리를 선택할 때 이런 종류의 이슈들을 많이 접하게 됩니다.
    우선 말씀하신 것처럼 내가 쓰지 않는 기능도 많이 포함되어 있을 경우.
    또, General하게 만들다보니 성능이 느린 경우.
    64bit나 unicode를 지원하지 않는 경우.
    i18n이 적용되지 않은 경우.
    이런 경우 조사나 공부를 더 해보면 해결 되는 경우도 있고, 결국에는 해결책이 없어서 직접 만들거나 수정해서 쓸 수도 있습니다.
    또는 라이브러리를 만드는 회사에 변경 요청을 하는 경우가 있습니다. 이런 과정을 거치면서 더 많은 지식을 쌓게 되고 결론이 어떻게 나든 그 과정이 가치 있게 되곤 합니다.

  3. 예전 회사에서 엔진채용을 심각하게 고민했는데 엔진을 적응하는데 걸리는 시간에 차라리 필요한 기능을 만드는게 더 빨라서 새로운 라이브러리를 꺼리게 되는 경우도 생기더라고요...
    적응되면 사온 엔진이 편하겠지만서도 엔진 사면 프로젝트 끝나는줄 아는 경영진들이 많아서 말이죠....

  4. 안녕하세요. black_H님
    "엔진을 사는 것보다 매우는 것이 더 빠르다"....
    아주 좋은 경험담입니다. 저도 실제로 이런 경험담을 매우 자주 듣습니다. 단기적으로는 대단히 맞는 말입니다.
    하지만 몇달 장사하다 말것이 아니면 이런 판단이 문제가 생기는 경우가 많습니다.
    나중에 계속 업그레이드를 하다보면 사오려고 했던 엔진의 속에 숨어있는 엄청난 기능들을 계속 발견하게 되고 우리 엔진에 기능을 계속 추가하고 버그잡고 유지보수하다 보면 사오는 비용보다 훨씬 커지는 경우가 많습니다.
    경영층에게도 엔진이 제품에서 차지하는 위치나 역할을 잘 보여줘야 하는데 변변한 문서도 없다면 경영층이 오해를 할 수도 있습니다. 엔진을 사오는 이유는 제품을 만든는데 집중하기 위해서인데 엔진만 사오면 제품의 거의 다 끝난 것으로 착각한다면 문제입니다.
    아무리 좋은 엔진과 라이브러리를 많이 사와도 제품을 하나 만들려면 엄청남게 많고 또 귀찮은 일들이 남아 있죠. 이런 것들은 사실 재미도 없는 부분이 많거든요. 그래서 재미있고 도전의식에 불을 댕기는 엔진이나 라이브러리쪽으로 끌리는 것인지도 모르겠습니다.

  5. 안녕하세요, 전규현 님,
    책도 잘보고, 블로그도 즐겁게 보고 있습니다.
    저희 팀도 이 부분에 대해서 많은 도전과 실수를 반복하고 있는데
    조언해주신대로 이미 만들어진 Library를 적용하는 방향으로 선회하는 중입니다.
    그러면서 드는 질문은 그러면 import 하는 것과 inhouse의 비율 혹은 무엇을 스스로 만들고, 어떤 것을 이미 개발 된 것을 적용할까 하는 질문이 듭니다.
    이번 글은 이미 만들어 진 것을 사용하는 것에 대한 장점이라면,
    스스로 만들어야 하는 것들의 장점, 혹은 이런 것은 반드시 스스로 만들어야 한다 하는 내용을 글을 한번 써주시면 어떨런지요. (혹은 link) 그 부분을 이해하면 그 부분 빼고는 가져다 혹은 사서 쓰는 것이 좋은거구나 하고 이해할 수 있을 것 같아서요.
    고맙습니다.

  6. 안녕하세요. 제임스님
    제 책과 블로그를 즐겁게 보고 계시다니 고맙습니다.
    네 말씀하신 것과 같이 inhouse를 완전히 피할 수는 없겠죠. 사례를 중심으로 이 주제에 대해서도 글을 써도 좋겠네요.
    감사합니다.

  7. 조엘 온 소프트웨어의 글이 떠오릅니다.

    http://www.joelonsoftware.com/articles/fog0000000007.html

    아마도 자기 회사의 핵심 역량은 직접 만들되, 핵심이 아닌 것은 사서 쓴다가 정답인 것 같습니다.

  8. 안녕하세요. 주의사신님
    좋은 얘기하는 사람은 많은데 그걸 보고 바뀌기는 대단히 어렵습니다. 그래도 아주 약간씩은 바뀌어 가겠죠.
    저는 실제 겪는 경험을 위주로 쉽게 풀어서 써보려고 노력하고 있습니다.

  9. 사용하려는 모듈이 프로젝트와 맞지 않거나
    수정이 과도하게 들어가야 하므로 직접 개발하는게 편해 보이기도 하는데

    문제는 하다보면 그게 바로 시궁창으로 빠지는 길이기도 하죠 ^^;
    오픈소스 특성상 누군가에게 책임을 물수 없다는 것도
    개발자들이 직접 모듈을 개발할 수 밖에 없는 함정에 빠지는 이유가 아닐까 생각이 됩니다.

  10. 안녕하세요. 구차니님
    사실 이런 이유로 직접 개발해야 하는 경우도 있습니다.
    그런데 개발이 특히 분석과 설계가 제대로 되지 않기 때문에 그런 경우가 많습니다.
    분석과 설계가 제대로 진행이 된다면 설계단계 이전에 분석단계에서 어떤 라이브러리를 써야 하는지 미리 검토가 됩니다.
    심지어는 이 때문에 기능이 바뀔 수도 있습니다. 기능을 조금 바꾸는 것이 라이브러리를 직접 만드는 것보다 더 효과적인 때가 많기 때문이죠.
    대충 코딩부터 시작하고 필요한 라이브러를 찾는다면 세상에 입맛에 딱 맞는 것은 별로 없을 겁니다.
    결국, 기본에 충실하면 다 해결되는 것입니다.

    요즘, 경계해야 할 것 중의 하나가 오픈소스가져다가 수정하는 것인데 꼭 필요하면 그렇게 해야겠지만 대부분 추후 발생할 문제를 생각하지 않고 일단 저지르고 보는 것입니다. 만들 때는 뭔가 근사한 것 만든 것 같고 뿌듯하지만 몇년 후 심지어는 몇개월후에 본인이나 후배들이 엄청나고 고생하고 회사는 손해를 입을 수 있습니다. 하지말라는 것은 아니고 이것을 모두 감안하고 결정을 해야 한다는 것입니다.

    오픈소스는 라이센스 위반하지 않는 것도 잊지 말고요. :)

  11. Blog Icon
    스피드

    우리나라현실에서 솔직히 딱 까놓고 얘기하자면
    세상의 널리 퍼진 유용한 정보에 관심이 없고
    주위로 부터 조금 인정받는다고 자존심 센 어정쩡한 개발자들이 그러는 게 젤 많은 경우가 아닌가요?
    다른곳으로부터 정보를 얻는것도 자기개발의 중요한 수단과 필수요소일텐데...
    정말 피곤해...

  12. 스피드님 안녕하세요.
    저도 동감입니다. 자신이 아는 지식과 경험의 카테고리에 갇혀서 그 외에는 배척하려고 하는 개발자도 많습니다.

매일 불난 호떡집 같은 회사 (중요한 일 vs. 시급한 일)

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



필자가 컨설팅을 진행했던 수많은 회사들 중에서 80% 이상은 불난 호떡집처럼 매일 불끄느라고 정신이 없습니다.
  • 너무 바빠서 새로운 기술을 연구할 시간도 없다고 한다.
  • 프로젝트를 진행할 때도 가장 빠른 방법으로 문서도 작성하지 않고 가장 뛰어난 개발자가 바로 코딩부터 한다고 한다.
  • 고객들은 기다려주지 않기 때문에 요구하자마자 바로 며칠 안에 제품에 기능을 반영해야 한다고 한다.
  • 제품에 버그가 발견되면 하루 이틀 안에 버그를 수정해줘야 한다. 그렇지 않으면 고객들이 엄청나게 컴플레인을 한다.
  • 사소한 버그 수정도 빨리 해야 하기 때문에 신입 개발자들에게는 시킬 수가 없다. 고참 개발자가 2시간이면 고칠 것을 신입 개발자를 시키면 2일이 걸릴 뿐더러 고참 개발자가 신입 개발자에게 일을 시키고 검토해주는데 2시간이 넘게 걸린다.
  • 제품의 아키텍처가 취약해서 기능을 추가할 때 아주 애를 먹는다. 언제 시간을 내서 아키텍처를 깨끗하게 새로 만들고 싶지만, 유지보수에 바빠서 도저히 그럴 시간이 나지 않는다.
  • 이러다 보니 수시로 야근이다. 
  • 운동할 시간도 없어서 몸이 점점 망가진다.
  • 영어공부도 하고 싶은데 시간이 없다.

이런 회사의 미래는 누구나 짐작할 수 있습니다. 
설령 제품이 고객들 입맛에 맞고 영업도 잘되어서 큰 성공을 이뤘다고 하더라도 시간이 흐를 수록 채산성은 악화되고 개발자들의 사기는 떨어지고 있을 겁니다. 자꾸 옛날에 개발이 더 잘되었다고 회상할 것입니다.

매일 불끄기 모드로는 회사가 성장할 수 없습니다.

회사에서 해야 할 일은 4가지로 구분할 수 있습니다.

 구분 중요한 일  중요하지 않은 일  
 시급한 일  A  B
 시급하지 않은 일  C  D

A. 중요하고 시급한 일
중요한 계약을 따기 위해서 급하게 해결해야 하는 일

B. 중요하지 않으나 시급한 일
일상적으로 제품에 버그를 잡는 일
고객들의 기능 추가 요청을 들어주는 일

C. 시급하지는 않으나 중요한 일
새로운 기술을 연구하는 일
회사의 개발 프로세스를 꾸준히 발전시켜 나가는 일
새로운 아키텍처를 연구하는 일
차세대 제품을 개발하는 일
회사의 개발 문화를 발전시키는 일

D. 중요하지도 않고 시급하지도 않은 일
이런 일은 영원히 미뤄도 된다. 나중에 중요해지거나 시급해질 때 해도 된다.


이 중에서 회사의 미래를 결정짓는 일들은 "C. 시급하지는 않으나 중요한 일"들입니다.
어치파 "A중요하고 시급한 일"은 누구나 열심히 하게 되어 있습니다. 하지만 "B. 중요하지 않으나 시급한 일"을 처리하느라 "C. 시급하지는 않으나 중요한 일"을 처리 하지 않으면 미래는 없습니다.

제가 만난 수많은 회사들 중 대부분은 C에는 거의 신경을 못쓰고 있습니다. B를 조금이라도 소홀히 하면 회사가 당장 망할 것 같은 생각을 하면서 C는 전혀 손을 못댑니다. 거의 99:1인 경우도 많습니다. 하지만 회사를 망하게 하는 것은 C를 소홀히 하는 것이 장기간 지속되는 경우입니다. 평상시에 B와 C에 균형을 가지고 투자를 해야 합니다. 20%~30%는 C에 꾸준히 투자를 해야 합니다. 꾸준히 투자를 하지 않으면 어느날 갑자기 투자를 할 수 없습니다. 지금은 너무 바빠서 중요한 것을 알지만 지금은 투자를 할 수 없다고 말한다면 영원히 중요한 일에 투자를 할 시간은 생기지 않을 겁니다.

"C. 시급하지는 않으나 중요한 일"에 투자를 하는 방법은 여러가지가 있지만 가장 좋은 방법 중에 하나는 조직을 나누는 것입니다. 일부 조직은 항상 중요한 일을 할 수 있도록 하는 겁니다. 또한 개발자들에게도 중요한 일을 소홀히 하지 않도록 항상 상기를 시켜주는 것이 좋습니다.

당장 어렵다면 해야할 일들을 A, B, C, D로 나누기를 먼저 해보시기 바랍니다.

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

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

전규현 개발문화 개발문화

Trackback Address: http://allofsoftware.net/trackback/204 관련글 쓰기
  1. 회사를 개인(나)로 바꾸니....
    저의 조급한 같은 문제도 어느정도 답이 나오는거 같아요..
    잘 읽었습니다~

  2. 레알님 안녕하세요.
    세상사 원리는 다 비슷한가 봅니다.

  3. "성공하는 사람들의 7가지 습관" 인가요. :D

  4. 우울한 딱다구리님 오랫만입니다.
    제가 그 책을 못읽어봐서... 기본적으로 사람이나 회사나 비슷한 측면이 많아 보입니다.
    저는 실제로 컨설팅 현장에서 직접적으로 많이 겪는 내용을 통해서 현상들을 파악하고 있습니다.

  5. 문제는 기업을 경영하는 사람들에게 있어서 C는 사원들이 알아서 해야할일 ... 이라고 생각하죠.
    애초에 A가 얼마나 로드가 걸리는지 모르는 경영진이 태반입니다.
    저 4개를 나눠봤자 A는 역시 바쁘기 때문에 C를 알아서 해라.. 라고 하고 하부에 로드를 더 걸어버리는 수가 생기죠.
    그래서 애초에 경영자의 마인드가 글러먹으면 아무리 좋은 방법론이 나와도 결국은 사용하지 않게 되버립니다. 안타까운 현실이죠.

  6. black_H님 안녕하세요.
    C는 당장 수익이 보이지 않는 투자이기 때문에 경영자의 지원이 없이는 직원들이 알아서 하기 매우 어렵습니다.
    즉, 소프트웨어 회사가 장기적으로 성장하는데 가장 중요한 키는 경영자가 가지고 있다는 것입니다. 뛰어난 개발자가 있어도 경영자가 환경을 조성해줘야 하죠.

  7. Blog Icon
    Jake

    전규현님께서도 말씀하셨지만 이런 회사들이 대부분이죠. 그런데 그런 회사들로 소프트웨어 산업이 계속 굴러가는 걸 보면 참 신기합니다.

  8. 안녕하세요. Jake님
    그래서 어느 한계를 넘어서는 회사가 별로 없다고 생각합니다.
    Global 소프트웨어 회사와 어깨를 나란히 하기는 어렵죠.
    생기고 없어지고, 반복을 하고 잘 망하지 않는 큰 회사들도 소프트웨어 경쟁력보다는 영업력이나 또는 직원들을 쥐어 짜서 내부적으로 엉망인 경쟁력으로 버티는 회사들도 많습니다.
    이 굴레를 벗어나야 할텐데 말입니다.

  9. Blog Icon
    thankee

    그런데 과연 우리나라 개발환경이 C를 위해 A와 B를 희생할 수 있는 환경인가요..? 우리나라 중소기업들의 대부분이 2~3명인분의 일을 한명이서 처리하고 있지요.. 이는 대표자가 돈좀 아낄려고 그러는 회사 뿐만아니라 사원들을에게 베풀고 경쟁력을 키워주고 싶어하는 회사에서도 마찬가지라고 생각합니다.. 대부분의 경우에 경제적으로 여유가 부족한 경우가 많기 때문에 그럴 수 밖에 없는 경우가 아닌가 생각됩니다.. 대부분의 회사들이 제살깎아내기 식으로 경쟁하고 있는데.. 어떻게 A와 B를 줄이고 C에 투자를 할 수 있을지.. 혹시 알려주실 분 없나요..?

  10. 안녕하세요. thankee님
    B:C의 비율을 99:1이 아닌 80:20 정도는 해야 합니다.
    당장 B를 99만큼 하지 않으면 큰일 날 것처럼 생각하는 경우가 있는데 그렇지 않은 경우가 많습니다. 99를 80으로 내리기 위해서는 해야 할 것들이 몇가지 있습니다.
    개발 프로세스와 기반시스템이 잘 갖춰져 있어야 줄일 수 있습니다. 모든 개발자들이 일당백으로 으쌰으쌰 하는 것 만으로는 어렵습니다.
    구체적인 방법은 한마디로 설명하기 어려우니 제가 쓴 책과 블로그의 여러가지 글들을 참조하시는 것이 좋겠습니다.

    그렇다고 하더라도 여전히 어려운 문제인 것은 동감합니다.

  11. Blog Icon

    비밀댓글입니다

  12. 생각해볼만한 주제네요. 감사합니다.

  13. 확실히 오래가는 회사일수록 유지보수(버그잡고 고객대응하고) 비용이 많이 들어가는게 보이는것 같아요.
    그런 이유로 새로운 라인업으로 갈아태우면서 단종시키는게 아닐까 싶긴 하지만 말이죠 ^^;

  14. 구차니님
    저도 동감합니다. 그래서 여전히 팔리는 제품도 유지보수 비용을 감안해서 적절할 때 단종시키기도 합니다.
    제품 라인업을 단순하게 가져가려고 노력하는 것도 중요합니다.
    제품을 개발하기 이전에 향후 유지보수를 고려하는 것이 필요합니다.

관리자가 이런 일까지?

우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..

과거의 성공이 발목을 잡을 때

수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..

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

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

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

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

설계가 필요할까?

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

Software Architect를 양성하는 나라

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

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

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

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

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

프로토타입이란?

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

같이 일하려면 적어라.

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