태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

티끌모아 태산 (개발 시간 절약하기)

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




성숙된 개발문화를 가지고 있는 회사는 개발 절차가 아주 효율적으로 진행된다.


하지만 그렇지 않은 회사들은 불필요하게 낭비하는 시간이 아주 많다. 10초에서 몇십분까지 자잘한 시간을 낭비해서 이것들을 합치면 어마어마한 시간이 낭비된다.


시간을 꼭 사용해야 할 중요한 곳에는 아끼지 말고 시간을 써야 한다. 하지만 자동화를 하거나 시스템이 커버를 할 수 있는데 사람이 반복적으로 하고 있거나 과도한 안전장치를 갖춘 프로세스로 인해서 비효율적으로 시간을 낭비하는 경우가 정말로 많다.


10초, 1분이라고 별것 아닐 것 같은 시간이 모이면 생산성은 10%, 20%, 50% 떨어지게 된다.


소프트웨어 개발은 워낙 복잡하기 때문에 이렇게 10초, 1분씩 낭비되는 시간을 최대한 제거해 나가면서 개발을 지속적으로 효율적으로 발전시켜나가는 노력이 필요하다.


회사마다 여건이 조금씩 다르지만 몇가지 예를 들어보겠다.


10초라도 낭비하면 아까운 시간들이다.


  • 빌드가 완전 자동화가 되어 있지 않아서 소스코드를 빌드할 때마다 약간이나마 중간에 수작업이 들어가는 시간 - 빌드는 완전 자동화를 구현해야 한다. 당연히 Command line으로 빌드가 되어야 하고 한번의 Enter로 최종 설치본까지 생성이 되어야 한다.
  • 이슈(버그)관리시스템을 잘 관리해보고자 너무 많은 커스텀필드를 넣어서 이슈(버그)를 등록할 때마다 몇초씩 더 걸리는 시간 - 적당한 커스트마이징은 필요하지만 과도함은 삼가해야 한다.
  • 이슈관리시스템이 있는데 보고나 관리를 위해서 별도의 자료를 만드는 시간 - 이슈관리시스템을 이용하면 원하는 View로 원하는 정보를 실시간으로 볼 수 있다. 관리자도 보고를 기다리지말고 직접 이슈관리시스템을 봐야 한다.
  • 여러벌의 Branch에 같이 존재하는 버그를 동시에 고치기 위해서 수작업을 할 때 - SCM의 Merge기능을 믿지 못하거나 기능을 활용할 줄 몰라서 수동으로 Merge를 하는 행위는 정말 시간 낭비이다. 제대로만 사용한다면 SCM의 Merge기능은 막강하고 99.9% 믿을만하다. 수작업이 아니고 최종적인 확인 정도만 해도 되는 경우가 대부분이다.
  • 개발자들의 주간 보고서 작성하기 - 이부분은 약간 논란의 이슈가 있다. 정말 간단한 주간보고서는 큰 무리가 없지만 부담스러울 정도의 주간보고서는 개발자들이 작성하지 않는 것이 좋다. 개발자들의 업무 기록은 이슈관리시스템 등에 다 남아 있다. 관리자는 개발자를 괴롭히지 말고 스스로 시스템을 보면 된다. 물론 기반시스템들이 잘 구축되어 있어야 한다.

이 외에도 코딩시 일반 업무시 절약할 수 있는 시간음 무궁무진하다. 이런 시간을 꾸준히 찾아서 제거해 나가는 노력이 필요하다.

image by  Big Swede Guy




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

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/302 관련글 쓰기
  1. Blog Icon
    이정훈

    좋은글 항상 고맙습니다. 글을 읽으면서, 이제까지 운좋게 아무문제 없이 개발해 왔었구나하고 안도하며 반성합니다.

  2. 좋은 글에 영향은 많이 받았습니다. 빌드 완전 자동화를 사내에서 추진 중에 있고, 덧붙여 어떻게 하면 빌드 속도를 빠르게 할 수 있을지 고민 중입니다.

재택근무가 가능한가?

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





우리 주변에는 비효율적인 개발 환경을 가지고 있는 회사들이 매우 많다. 상상외로 많다. 


스스로의 회사는 어떤가 생각해 보자. 나름대로 효율적인 개발문화를 가지려고 많은 노력을 해왔을 것이다. 그래서 과연 우리회사가 제대로 효율적인 개발문화와 환경을 가지고 있는지 궁금할 것이다.


이렇게 비교를 해보자. 당장 우리 회사의 개발자들이 모두 재택근무를 하면 어떻게 될까? 그리고 일주일에 딱 하루만 회사에 나와서 필요한 회의를 한다면...


대부분은 그렇게 해서는 회사가 돌아가지 않을 것이라고 생각할 것이다. 


그렇다면 아직 먼 것이다. 소프트웨어 회사가 효율적인 프로세스와 시스템을 갖추고 개발 역량과 성숙한 개발문화를 갖추고 있다면 얼굴보고 해야 할 일이 그렇게 많지가 않다. 일주일에 몇시간이면 충분하다.


일단 회의가 너무 많은가? 회의는 정말 비효율적이다. 꼭 필요한 회의가 아니면 대부분의 회의는 시간을 비효율적으로 사용하며 많은 인원의 시간을 한꺼번에 소비한다. 대분은 시스템으로 커버가 가능하다.


개발할 때마다 얼굴을 보고 설명을 해줘야 하는가? 주먹구구식 개발의 대표적인 현상이다. 효율적으로 작성된 SRS가 있다면 설명해줘야 하는 시간은 수십분의 일로 줄어든다. 줄어들어야 제대로 작성된 SRS이다.


수시로 물어봐야 해서 항상 자리에 붙어 있어야 하는가? 성숙한 개발 환경에서는 프로세스, 시스템, 문서등이 이를 대신한다. 


실제 이런 경험이 있는 않은 경우라면 즉, 기존의 적당한 주먹구구와 공력에 의해 개발을 했거나 비효율적인 프로세스를 적용해서 나쁜 기억만 가지고 있는 경우라면 이렇게 개발하는 것이 더 비효율적인 것이 아니냐고 반문을 하곤한다. 그렇게 하려면 문서를 너무 많이 적어야 하는 것이 아닌가? 프로세스나 시스템이 오히려 더 거추장스러운 것이 아닌가? 의문을 품을 수 있다.


책이나 인터넷을 보고 프로세스를 따라한 부작용이기도 하다. 태권도장에 가서 직접 태권도를 배우면 금방 되는 것이 책을 보고 배우면 대부분은 제대로 배우지 못하고 효율적이지 못한 것과 비슷하다.


프로세스, 시스템, 문서 모든 것은 개발을 빠르고 효율적으로 하기 위해서 존재하는 것이고 그보다 더 이상 이하여서도 안된다. 이는 제대로된 경험으로만 터득이 가능하다. 따라서 경험자나 전문가의 가이드가 필요한 것이다.


나름대로 개발 환경을 개선하기 위해서 열심히 노력한 경우라도 재택근무가 가능한 수준이 아니라면 아직 갈 길이 멀다는 것을 명심하자.


이제 효율적인 개발에 한발을 내딪였을 뿐이다.


image by  edgeplot

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

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/301 관련글 쓰기
  1. 회의라는 것을 4시간 30분 하다보니 뼈저리게 느껴져요. 헤헤헤 T_T

개발자, 회사의 과거인가 미래인가

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





개발자는 소프트웨어 회사의 가장 중요한 자산이면서 서로 상반된 2가지 가치를 가지고 있다.


첫 번째는 ‘과거의 가치’이고

두 번째는 ‘미래의 가치’이다.


나는 과거의 개발자일까? 미래의 개발자일까? 스스로 판단하기는 어려울 것이다. 동료나 경영진에게 내가 퇴사를 하면 어떻게 될까?라는 질문을 해보면 짐작할 수 있다.


내가 퇴사를 하면 과거에 개발해 놓은 제품들을 어떻게 하지?라는 생각이 가장 먼저 들면 ‘과거의 개발자’에 가깝다.


반대로 내가 퇴사를 하면 과거에 개발해 놓은 제품들은 문제가 없는데 미래에 개발할 제품은 누가 개발하지?라는 생각이 들면 ‘미래의 개발자’라고 볼 수 있다.


회사나 개발자 입장에서 권장되는 개발자 타입은 미래 가치를 많이 지닌 “미래의 개발자”이다. 미래의 개발자가 지금은 가치가 적은데 미래에 가치가 높다는 의미가 아니다. 미래에 가치가 더 있고 시간이 흐를수록 점점 가치가 높아진다는 의미다.


과거의 가치를 더 많이 가지고 있는 ‘과거의 개발자’는 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식이 머리 속에 있기 때문에 동료나 신입개발자와 지식을 공유하기 어렵다. 본인이 의도해서 그렇게 한 것은 아니지만 결과적으로 자신이 과거에 만들어 놓은 소프트웨어를 인질삼아 회사와 인질극을 벌이고 있는 것과 같다.


물론 이런 개발자가 퇴사를 한다고 회사가 망하는 것은 아니지만 적게든 많게든 타격을 입게 되고 심한 경우 회사는 퇴락의 길을 걷기도 한다. 따라서 회사는 이런 개발자에게 질질 끌려 다니곤 한다. 이런 상태의 개발자는 스스로도 상황의 피해자일 뿐이다.


미래의 가치를 가진 ‘미래의 개발자’는 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수를 수월하게 할 수 있도록 개발 과정에서 적절히 문서화를 해 놓았고, 아키텍처를 깨끗하게 만들었으며 모든 이슈는 이슈관리시스템에 기록으로 남겨 놓았다. 그리고 Peer review를 통해서 이미 많은 지식을 동료들과 공유를 한 상태다.


이런 합리적인 개발 과정을 통해서 본인은 분석, 설계 능력이 꾸준히 향상되어 왔으며, 회사도 성장에 걸맞게 프로세스와 개발문화가 발전되어 왔다. 유지보수에 허덕이지 않으므로 신기술에 대한 연구에 소홀하지 않아서 미래에는 과거 제품들보다 한 단계 수준 높은 제품을 만들어 낼 것이다.


언뜻 보기에는 과거의 엄청난 폭풍 코딩을 통해서 짧은 시간에 많은 제품을 만들어내는 성과를 낸 ‘과거의 개발자’가 영웅처럼 보이지만 미래의 가치를 지닌 ‘미래의 개발자’가 진정한 영웅이다.


필자는 대기업부터 작은 소기업까지 여러 소프트웨어 회사를 다니면서 개발자와 경영진을 대상으로 소프트웨어 개발에 대해서 강연이나 세미나를 많이 한다. 그럴 때 이런 질문을 하곤 한다.


“오늘 회사를 그만둬도 당장 큰 문제가 발생하지 않는 사람 손들어 보세요”.

“오늘 회사를 그만두면 회사가 당장 큰 일 나는 사람 손들어 보세요”.


이 두 가지 질문 중에서 두 번째 질문에 손을 드는 사람이 상당히 많다. 특히 주변에 특정인을 가리키며 손을 들라고 하는 경우가 많다. 이런 사람은 십중팔구 ‘과거의 개발자’이다.


과거에 엄청나게 많은 일을 해냈지만 대부분은 유지보수에 치여 본인도 발전 못하고 격무에 시달리고 있는 경우이다. 수많은 문제와 이슈는 본인만 알고 있어서 수시로 불려 다니고 정작 본인은 개발할 시간이 없고 발전도 어렵다.


물론 ‘과거의 개발자’양산이 개발자에게 책임이 있는 것은 아니다. 소프트웨어 개발 환경이 회사에서 제공하는 프로세스, 시스템이 열악한 상태에서 전적으로 개발자의 내공에 의존을 하기 때문에 개발자도 어쩔 수 없이 ‘과거의 개발자’가 되어 버리는 것이다.


‘과거의 개발자’가 주도하는 회사는 엄청난 개발자 Risk를 안고 있는 것이다. 뛰어난 개발자가 많지만 이들이 한두 명만 나가도 회사가 휘청대며, 유지보수에 발목을 잡혀서 앞으로 나가기 어려운 상태인 경우가 많다.


회사는 개발자가 개발에 전념할 수 있고 개발 과정에서 꾸준히 성장할 수 있도록 환경을 제공해야 한다. 개발자 경력을 보장하는 것은 물론이고 프로세스와 기반시스템을 제대로 갖추고 개발문화 구축에 제도적인 노력해야 한다. 그렇게 해서 개발자 내공에 의존하는 개발이 아닌 시스템에 의존한 개발이 되어야 한다. 그런 환경에서야 개발자가 최고의 활약을 할 수 있다.


그래야 개발자도 행복하게 개발을 할 수 있고 회사도 개발자 Risk가 줄어든다. 이런 환경에서 성장하는 개발자는 신참때는 주로 코딩을 하지만 고참이 되어 갈수록 설계, 분석에 집중하고 문서를 통한 협업에 능숙해진다. 이런 방법이 개발자와 회사 모두에게 좋은 방법이다.


여전히 개발자의 내공에 의존한 개발 환경을 가진 회사에서 유지보수에 허덕인다고 개발자를 탓하지는 말자. 지금이라도 ‘미래의 개발자’를 위한 환경에 대해서 고민해보자.


책에도 다 있고 이론은 많지만 현실에서 실천이 어려운 것이다. 이론으로는 배울 수 없고 경험에 의해서 밖에 배울 수 없기 때문이다. 책과 이론은 약간의 도움을 줄 뿐이다.



이 글은 Tech it에 기고한 글입니다.


image by CEThompson


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

전규현 사람과 기술

Trackback Address: http://allofsoftware.net/trackback/300 관련글 쓰기
  1. 이 글이 뜻 하는 바는 알겠지만, 논리?예시가 적절치 못 한 것 같아서 한 글자 남깁니다. 예시로 들었던, 적절한 문서와 좋은 아키텍처는 보는 사람 입장에 따라서 천차만별입니다. 동일한 문서와 아키텍처도 충분하다고 하는 사람이 있는 반면, 부족하다는 사람도 분명 있습니다. 그렇다고 그 개발자가 과거의 개발자 인가요? 예시가 비약적인 면이 있습니다. 그리고, 유지보수에 허덕되는 사람은 과거 개발자가 아니라, 여러가지 에러케이스에 대응하지 못 한 수준 낮은 개발자 일 뿐 이라고 생각이 듭니다. 글쓰신 분이 컨설턴트라, 개인의 능력 보다는 회사 개발 프로세스의 중요성에 대해 강조 하는데 글의 주안점이 있는 것 같습니다.

  2. 안녕하세요. 저는 컨설턴트이기 전에 소프트웨어 개발자입니다. 따라서 개인의 역량을 매우 중요한 요소로 보고 있습니다. ^^ 각 글마다 주안점이 다르므로 여러 글을 읽어보시고 종합적으로 생각하시면 좋겠습니다.

  3. 물론 개발 프로세스도 중요 합니다. 하지만 적절하지 못한 개발 프로세스는 업무의 가중이라는 점도 충분히 컨설턴트 해 주실 수 있는 부분이라고 보여지네요. 많은 이들이 보고, 겪은 것과 같이, 수 많은 제도와 프로세스 때문에 소프트웨어가 하향평준화 될 수 있는 위험도가 분명히 있습니다.

  4. 제 글중에 http://allofsoftware.net/entry/소프트웨어-관료화 가 있습니다.
    이글을 보면 적절치못한 프로세스로 인해서 효율성이 오히려 낮아지는 위험에 대해서 경고하고 있습니다. 참고하세요.

  5. 와... 이렇게 좋은 블로그를 이제서야 발견하게 되다니 ㅠㅠ
    요즘 개발자와 함께 일하는것 때문에 많은 고민인데,
    주옥같은 글 감사합니다. ^-^

전지전능한 슈퍼 개발자의 역설

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




필자는 여러 소프트웨어 회사에서 많은 개발자를 만난다. 그러면 보통 회사에 한두명씩 전지전능한 슈퍼 개발자가 있는 것을 보게 된다.


이들은 코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반관리, 전략 수립 등 엄청나게 많은 일을 한다. 직책은 대부분 팀장이다.


여러분의 회사에도 이런 개발자가 한두명씩은 있을 것이다. 이들이 여러분의 롤모델인가? “나도 그런 전지전능한 개발자가 되어야지”라는 다짐을 하는가? 아니면 혹시 여러분이 이런 전지전능한 개발자인가?


이렇게 많은 일을 하는 개발자가 One man company에만 있는 것이 아니다. 개발자가 수백명이 넘는 회사에서도 드물지 않게 만날 수 있다.


이런 회사에서는 모든 길이 로마로 통하듯이 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결이 된다. 이 전지전능한 개발자가 모든 기술과 정보를 꽤 뚫고 있어서 문제가 발생하면 즉시 해결해주고 회사는 그럭저럭 굴러간다. 이 개발자가 나가면 회사는 망할 것만 같다.


이런 현상이 좋아보이는 사람도 있을지 몰라도 회사는 인력적으로 큰 리스크를 안고 있는 것이고 뛰어난 개발자를 가장 가치 있는 일에 제대로 사용하지 못하는 손해를 입고 있는 것이다. 전지전능한 개발자는 본인이 선택을 해서 그런 위치가 된 것은 아니다.


회사가 성장과정에서 적당한 때 조직을 전문화하고 변화를 꾀했어야 하는데 그냥 달려만 오다보니 능력이 좋은 개발자가 이거 저거 다 떠 안게 되면서 이런 현상이 벌어지게 되었다. 좀더 잘할 수 있는 분야에 집중했다면 본인 역량 면으로도, 미래 가치면으로도 훨씬 좋은 결과를 가져왔겠지만, 지금은 회사의 맥가이버가 된 상황에 만족할 수 밖에 없다.


다른 회사로 가면 지금의 가치는 대부분 사라지고 만다. 개발자 본인에게도 안타까운 상황이다.


어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능하다. 아주 작은 회사에서나 그렇게 하는 것이다. 이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 한다. 모든 일을 잘한다는 것은 애초에 불가능하다. 특히 중요한 일은 주 업무인 개발을 할 시간이 확 줄어 든다는 것이다.


대부분의 이들은 예전에는 뛰어난 개발자였다. 하지만, 개발 이외 일들을 하나씩 떠 맡으면서 각 분야의 일들의 전문성이 점점 떨어지게 됐다. 그리고 각 일의 Switching cost가 만만치가 않다. 톰 디마르코는 몰입에는 15분의 시간이 필요하다고 했다. 전화한번만 받아도 15분은 그냥 추가로 까먹는거다.


심지어는 그런 개발자에게 테스트, 고객 응대, 기술 지원까지 하라는 것은 100원주고 20원짜리 일을 시키는 것과 같다. 비효율적일 뿐만 아니라 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못한다.


이런 슈퍼 개발자는 다른 소프트웨어 회사에 가면 가치가 확 떨어진다. 분야가 달라지면 Domain Knowledge 관련 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 된다. 관리자가 되어야 하나 고민이 많다. 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되는 경우도 있다.


회사는 이들에 대한 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 된다. 이들이 등돌리면 회사는 휘청거린다.


이것이 개발자 탓일까? 아니면 회사 탓일까? 회사 탓이다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야한다. 그런데 개발자가 맨땅에서 북치고 장구치고 다 하고, 회사에서는 이를 방치하다보니 이렇게 되는 것이다. 하지만 많은 경영자들은 개발자가 잘 하니 그냥 그렇게 개발자가 다 해야 하는 것으로 아는 경우가 매우 많다.


그럼 어떻게 해야 할까?


개발자가 개발에 전념할 수 있도록 항상 여건을 조성해줘야 한다. 회사가 아주 작아서 어쩔 수 없이 개발자가 여러가지 일을 겸해서 하고 있다고 하더라도 회사가 조금만 커져도 개발자의 일에서 개발업무가 아닌 일을 떼어낼 수 있도록 준비를 해야 한다.


조직이 조금 커지면 테스터를 뽑고, 기술지원인력을 보강하는 것이 좋다.


개발자 10명이 이거 저거 모든 일을 다하는 것보다. 개발자 7명에 테스터2명, 기술지원 인력 1명인 조직이 더 낫다. 개발자가 개발에 더 집중할 수 있고 개발자 10명이서 하는 일보다 더 많은 일을 할 수 있다. 물론 조직과 더불어 프로세스, 기반시스템, 개발문화도 뒷받침이 되어야 하지만 이는 기본으로 생각하자.


이렇게 조직이 분리되고 개발자가 개발에 전념을 할 수 있어야 개발이 좀더 체계적으로 진행된다. 다른 조직의 인력과 협업을 하기 위해 필요한 최소한의 문서도 만들어야 하고 프로세스도 자연스럽게 필요하게 된다. 커뮤니케이션을 위한 기반시스템도 잘 활용하게 된다.


조직이 더 커지면 분리해야 하는 역할이 점점 많아진다. 즉 조직이 세분화 된다. 이는 회사 규모에 따라서 다르니 이 일이 개발자가 해야 하는 일인지 잘 생각해보고 결정하면 된다.


여기서 개발자의 업무를 모두 나열할 수는 없지만 회사에서 개발자가 개발에 집중할 수 있도록 노력하는 일은 대단히 중요하다. 개발자가 잘 해낸다고 그냥 방치하면 안된다. 개발자는 개발을 잘할 때 회사의 보물이 되는 것이다. 다른 일들은 여건이 되는 대로 다른 전문가에게 맡기도록 하자.


이 글은 Tech it에 기고한 글입니다.



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

전규현 사람과 기술

Trackback Address: http://allofsoftware.net/trackback/299 관련글 쓰기
  1. "여건이 되는 대로"... 에 함정이 있는 것 같습니다. ㅎㅎㅎ

  2. 내 스스로를 평가하기는 그렇지만 왠지 저 일들 다하고 있는것 같다. 아직 대리인데..회사탓.... 이직해야하나..^^; 다른곳에 가면 저일들이 다 소용없어진다고...하~ 역쉬 우물안 개구리였나... 고민스럽네.. 후~~

지금은 바빠서 못한다.

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




지금은 바빠서 못하고 나중에 여유가 생기면 할 것이다.


비단 소프트웨어 개발이 아니더라도 우리는 이런 말을 달고 사는 사람들을 자주 본다. 이런 사람들이 특징은 시간적인 여유가 생겨도 거의 대부분 안하기는 마찬가지라는 것이다.


운동, 공부, 다이어트, 취미생활 등 이런 핑계를 대는 대상은 다양하다.


영어 속담에 이런 말이 있다.


"A stitch in time saves nine"


직역하면 "필요할 때 한땀이 아홉을 구한다." 


소프트웨어 회사도 마찬가지이다. 한땀이 필요한 결정적인 시기들이 수없이 닥친다. 하지만 그 결정적인 시기를 놓치면 10배, 100배의 비용을 지불한다.


코딩만 보더라도 처음에 제대로 해놓지 않으면 나중에 고치기에는 훨씬 많은 노력이 드는 경우가 많다. 소스코드를 너저분하게 어질러 놓거나 여기 저기 마구 복사를 해넣고 암호 같은 코드를 써 놓으면 나중에 고생을 한다. 


여기까지는 나중에 문제가 되어도 그렇게 심각하지는 않지만 회사는 결정적인 시기를 놓치면 영원히 복구를 못할 수 있다.


어떤 시기에 무엇을 해야 하는지는 워낙 광범위한 이슈라서 한마디로 얘기할 수는 없다. 하지만 많은 회사들이 변화를 두려워하거나 귀찮아해서, 또는 변화에 지불해야 하는 비용이 아까워서 그냥 버텨나가곤 한다. 그리고는 더이상 버티기 힘들다고 판단될 때는 너무 늦은 경우가 많다.


회사의 프로세스, 조직, 시스템, 문화 등 적절한 시긴에 준비하고 변화해야 할 부분은 많다.


비경영자 출신의 경영자는 몰라서 실기를 하기도 하고 개발자 출신의 경영자들도 자신의 경험의 테두리에 갇혀서 사태의 심각성을 깨닫지 못하는 경우가 많다. 가장 좋은 방법은 상황이 좋을 때 변화하는 것이다. 상황이 점점 안좋아지면 변화는 엄두도 못낸다. 일단 상황에 밀리기 시작하면 끝까지 밀려서 꼼짝달싹 못하기 쉽상이다. 


좋은 경영자라면 좋은 세월에 뭘 해야 할지 알아야 한다.


 

image by Sewing Daisies




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

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/298 관련글 쓰기
  1. 지금 한국사 교재를 만들고 있는데 처음에 뼈대를 잘 잡은 부분은 나중에 고치기도 수월한데
    그게 안되면 베트남 정글이 되더라구요.
    항상 이 글의 반 이상은 알아들을 수 없는 일자무식이지만
    이래저래 인간이 하는 일이니만큼 도움이 됩니다.
    오늘 글도 이 글이 작업을 하는 제게 도움이 되는군요.

내가 책임지고 해보겠습니다.

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



우리나라 경영자들은 "내가 책임지고 해보겠습니다."라는 말을 좋아한다. 물론 책임감을 가지고 일을 추진하는 것은 좋은 일이다. 하지만 많은 경우 엄밀히 말하면 제대로 책임을 지는 것이 아니다. 결과적으로 책임을 지겠다고 말만하는 꼴이 되는 경우가 많다. 그럼에도 무모하더라도 추진력있게 밀고 나갈 사람이 인기가 많다.


경영자들이 이런 돌격형 인재를 좋아하는 이유는 여러가지가 있다. 실제 좋은 성과를 내는 경우도 많지만 소프트웨어에서는 상황이 좀 다르다. 


경영자들이 소프트웨어 개발에 대해서 잘 모르기 때문에 그냥 알아서 개발을 해주기를 원하는 경우가 많다. 또한 이런 경우 무모한 시도가 되는 경우가 많다. 


열심히 하는 것은 좋지만 무모한 것과는 다르다. 대부분의 무모한 프로젝트는 일정이 제대로 예측이 안되는 상태로 밀어 붙인다. 일정이 촉박하다는 이유로 분석, 설계 생략하고 코딩부터 진행하고, 개발 막바지까지 현재 진행률을 파악하기가 어렵다.


비즈니스를 하기에는 이렇게 열심히 일하지만 예측 불가능한 프로젝트보다는 합리적인 일정제시와 제시된 일정에 결과가 제대로 나오는 프로젝트가 더 좋다. 그래야 비즈니스도 계획한 대로 움직일 수 있다.


이렇게 무모한 프로젝트를 진행하는 개발자들은 불투명한 프로젝트 진행을 선호한다. 투명하게 프로젝트를 진행하는 것이 더 효율적이라는 것을 몰라서 그렇게 하기도 하지만, 정보와 지식을 숨길 수록 자신들의 가치가 더 올라간다고 착각을 하기도 한다.


이런 환경에서는 경영자는 Detail은 잘 모르고 개발자들을 쪼기만(일정 압박) 하고, 개발자들은 매일 야근에 내몰리다가 프로젝트 막바지에는 이런 저런 핑계를 만들어 내기 급급해진다. 물론 가끔은 일정내에 프로젝트가 끝나기도 하지만 그 과정에서 마케팅, 영업, QA와 유기적으로 협력이 잘 안되고 혼자 달려가는 프로젝트가 되곤한다. 개발자가 개발을 끝내주면 그때부터 다른 부서는 일이 시작된다. 무엇을 개발하고 있는지 제대로 파악이 안되므로 미리미리 준비를 하기도 어렵다.


물론 개발자는 열싱히 일을 했다. 비난을 들으면 억울할만하다. 물론 나는 개발자를 비난하는 것은 아니다. 이런 일이 벌어지는 근본적인 이유는 경영자들의 무모한 개발자를 선호하고 너무 압박을 하기 때문이다. 이런 일이 반복되면 개발자는 지치고 프로젝트는 지연된다. 잘못된 방향으로 달려가던 프로젝트는 커다란 매몰비용(Sunken cost)를 치뤄야 하기도 한다. 이런 상황에서는 경영자도 개발자도 선택의 여지가 별로 없다. 아무리 손해를 보더라도 경영자는 이런 무모한 프로젝트에 계속 후원을 할 수 밖에 없다. 


이 모든 부작용은 개발 문화의 부재에서 오는 것이다. 제대로 된 스펙에 의해서 합리적인 일정을 제시하고 경영자는 이를 믿어줘야 한다. 처음에는 개발자들이 역량이 부족하여 나름대로 개발자들이 제시한 일정이 좀 틀릴 수도 있지만 개발자들은 최대한 합리적인 가능한 일정을 제시해야 한다. 그런 관계가 거듭되야 개발자도 역량이 향상되고 비즈니스 일정에 맞춰서 제품을 만들어 줄 수 있다.


혹자는 현실적으로 불가능한 일이라고 한다. 항상 일정이 너무 촉박하여 경영자는 절대로 개발자들이 제시한 일정을 따를 수 없다고 한다. 그래서 무모하게 짧은 일정을 제시한다고 한다. 경영자가 그렇게 하는 이유는 무지 때문이기도 하고 개발자들이 합리적으로 일정으 제시하지 못하기 때문이기도 하다. 가끔은 경영자와 개발자의 신뢰가 무너진 경우도 있다. 그렇게 해서는 평생을 가도 무모한 프로젝트만 진행하게 된다.


그 부작용은 개발자 사기저하, 비즈니스 일정이 꼬이고, 제품의 품질이 떨어진다.개발자들은 매일 야근에 고생을 하지만 일정 지연에 자주 내몰린다.


여기서 핵심은 경영자들의 이해이다. 그리고 개발자들도 제대로 된 분석, 설계 능력을 갖춰서 합리적인 개발 계획을 제시할 수 있어야 한다. 한번에 그렇게 될 수는 없지만, 경영자와의 신뢰 하에서 개발자에게 꾸준히 투자를 해줘야 개발자들도 그렇게 할 수 있는 역량이 올라가게 된다. 


image by A.K. Photography








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

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/292 관련글 쓰기
  1. 마치 데자뷰를 보는 듯.

  2. @booiljung 지금도 비슷한 현상이 여기 저기서 또 일어나고 있습니다. 경영자가 기술을 어느 정도 이해하던지, 믿어주든지 해야 합니다. 이도 저도 아니면 결정을 대신해줄 CTO가 필요합니다.

  3. @booiljung 나름 개발을 알고 있다고 생각하는 개발자 출신 오너도 마찬가지입니다. 자신이 마지막 개발했던 수준에 머물러 있는 경우가 많습니다. 이런 경우 더 문제 해결이 어렵습니다.

  4. Blog Icon

    비밀댓글입니다

  5. 제가 보기엔 이건 프로젝트 관리의 문제라고 생각합니다. 맨 마지막의 분석/설계 이야기는 왜 나오는지 조금 의문이 드네요

  6. 일반적인 경우 분석설계가 제대로 되지 않은 상황에서 프로젝트 관리는 할게 별로 없습니다. 일정 예측도 부정확하고 그냥 쪼는 수밖에 없습니다. 제대로된 프로젝트 관리는 스펙이 제대로 작성되어야 합니다. 프로토타입 방법론이나 점진적인 개발을 할 경우에도 짧은 주기로 똑같은 상황이 벌어집니다.

절대 코딩하지 마라

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




"코딩은 늦게 할수록 프로젝트가 빨리 끝난다."


대부분의 개발자들은 이 말을 제대로 이해하지 못한다. 그래서 프로젝트 일정이 촉박하면 무조건 코딩부터 시작하곤 한다. 코딩을 빨리 시작하면 프로젝트가 빨리 끝날 것으로 믿곤 한다. 말은 그렇게 하지 않더라도 일정이 부족하면 문서 작성할 시간도 없고 무조건 코딩부터 시작한다.


물론 프로젝트에 따라서 대충해도 되는 경우가 많다. 그런 프로젝트를 예로 들어서 모든 프로젝트에 확대 적용하지는 말자. 즉, 개집은 어떻게 만들어도 다 되는 것이다. 


코딩 시작은 빨리 시작할수록 재작업은 급속히 늘어난다. 코딩을 최대한 뒤로 늦춤으로써 재작업 가능성을 낮춘다. 물론 스펙이 완전히 끝나야 코딩을 시작할 수 있는 것은 아니다. 스펙을 합리적으로 작성하는 요령 중 하나가 미리 확정할 수 있는 라이브러리나 Sub system들은 인터페이스를 미리 확정하고 코딩을 먼저 시작할 수 있다.


보통 프로젝트에서 분석을 해보면 코딩부터 할 수 없다는 것을 알게 된다. 코딩부터 시작하는 경우는 무엇을 개발할지도 모르고 코딩을 시작하는 것이다. 그렇게 미리 작성된 코드는 스펙이 정해지면 버리고 다시 짜야 하는 경우가 많다. 아키텍처에 요구사항이 제대로 반영되지 않는다. 그럼에도 미리 코딩을 해 놓으면 코드를 버리기가 아까워서 그냥 사용하게 된다. 그러다보면 아키텍처는 엉망이 된다.


개발자들은 자신이 작성한 코드를 살리기 위해서 요구사항을 거부하기도 하고 코드에 꼼수를 부리기도 한다. 


가끔은 코딩만하기에도 정말 일정이 부족한 프로젝트들이 있다. 이런 경우도 코딩부터 한다고 프로젝트가 빨리 끝나는 것은 아니다. 무모한 시도를 하는 것이다. 스펙을 작성할 시간도 없는 프로젝트는 안하는 것이 낫다. 그렇다고 회사에서 프로젝트를 거부할 수는 없다. 최대한 빨리 스펙을 써서 합리적으로 가능한 일정와 범위를 제시하는 것이 더 좋은 방법이다.


일정이 촉박하다고 매번 코딩부터 시작하면 10년을 개발해도 별로 나아지는 것이 없을 것이다.









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

'프로젝트 > 구현' 카테고리의 다른 글

절대 코딩하지 마라  (11) 2012/10/29
주석을 달기 어려운 이유  (9) 2011/09/09
Copy & Paste의 종말  (12) 2009/07/31

전규현 프로젝트/구현

Trackback Address: http://allofsoftware.net/trackback/294 관련글 쓰기
  1. 좋은 글. 모든 일(Task)이 그렇듯이 고민을 충분히 해서 세를 짠 후에 한 번에 몰아붙여 끝내는 것이 효율적이라고 생각됩니다.

  2. @beomjinkim 블로그에 LiveRe 붙였어요. ^^ 좋죠?

  3. @beomjinkim 다 좋은데 Tistory 기존 댓글들을 포기할 수 없어서 지금은 기존 댓글과 중복해서 사용하게 되네요.

  4. 항상 손이 먼저나가서 문제
    참을수 없는 가벼움

  5. LiveRe 붙이고 좋아진 것 같긴 한데 LiKE 버튼이 없어졌네요! 아님 제가 못찾고 있는걸까요?

  6. 없어졌네요. - -; 다시 추가했습니다.

  7. 공감합니다. 저도 경력이 늘수록 코딩시작하는데 신중해지더군요. 나중에 고생하지 않으려고.
    비록 혼자 보게되더라도 간단하게 나마 문서작성해서 다 맞춰놓고 하는게 제일 좋더군요.

  8. 그렇다면 TDD 방법론에 대해서는 어떻게 생각하시나요?

  9. 안녕하세요. 윈플님

    개발적인 방법론을 보면 잘못된 것이 하나도 없습니다. TDD방법론도 마찬가지입니다. TDD방법론은 분석단계를 강화하는 아주 좋은 수단입니다. 그렇다고 모든 프로젝트에 TDD방법론을 쓰는 것이 좋은 것은 아닙니다.

    스펙을 적는 방법은 매우 다양합니다. 특히 기능을 적을 때는 어떤 형식으로 적으라는 규칙이 없습니다. TDD도 그 방법 중 하나입니다. 단계별로도 한번에 다 적을 수도 있고 차츰 발전시켜나갈 수도 있고 가장 효과적인 방법은 경험이 많은 개발자가 프로젝트의 성격에 맞게 판단하면 됩니다.

    무슨 방법은 옳고 뭐는 잘못됐다고 기법이나 방법을 가지고 얘기하는 것은 위험합니다.

    원칙 중 하나는 이 모든 고민은 소프트웨어를 어떻게 빨리 개발할지에서 출발하는 것이고 그러기 위해서는 대부분의 소프트웨어는 바로 코딩에 들어가는 것보다는 스펙을 적절하게 적는 것이 좋다는 겁니다. TDD도 그 한 방법입니다.

  10. 만족할때 까지 생각만 하면 아무것도 안되는 것 같고, 또 나름 고심했다고 막상 코딩하면 미처 고려치 못한 부분이 생기고, 설계와 코딩의 경계점을 잡기가 참 어려운것 같습니다.

  11. 내용을 보면 분석과 설계의 경계를 구분하기 어려운 것 같군요. 코딩은 분석, 설계 어느 단계라도 필요한 부분은 미리 해 놓을 수도 있습니다. 분석은 충분히 다 되었다고 확신하는 것도 어렵고, 필요한 만큼 적당히 해야 하는데 적당히가 가장 어렵습니다.

    그래서 설계는 예술이라는 말이 나오나 봅니다.

스타트업에서 SW 개발에 꼭 필요한 시스템

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





소프트웨어를 개발하는데 꼭 필요한 시스템들이 있다. 이것을 기반시스템, 영어로는 Infrastructure system이라고 한다. 기반 시스템은 수십 가지 종류가 있지만 회사 규모나 성격에 따라 꼭 필요한 것이 다르다. 꼭 필요한 기반시스템을 사용하지 않거나 규모에 맞지 않게 많이 사용하는 것 모두 문제다. 그리고 제대로 사용해야 효과를 극대화할 수 있다.


회사 규모가 크면 좀더 많은 기반시스템을 사용할 필요가 있지만 스타트업에서는 꼭 필요한 몇 가지만 있으면 된다. 그럼 스타트업에서 꼭 사용해야할 기반 시스템에는 어떠한 것들이 있는지 알아보자.


1. 소스코드관리시스템

필요성: ★★★★★

추천 형태: 호스팅

추천 서비스: Bitbucket, Github

추천 시스템: Git, SVN


소스코드관리시스템이 없이 소프트웨어를 개발한다는 것은 상식적으로는 도저히 불가능하다. 자체적으로 구축하는 것도 가능하지만 호스팅을 권장한다. 소스코드관리시스템을 직접 구축하여 운영하려면 하드웨어 구매 비용, 관리 비용 등 만만치 않은 비용이 들어간다. 하지만 호스팅을 이용할 경우 그 수십 분의 일의 비용으로 해결할 수 있다.


호스팅으로 SVN을 이용할 경우 네트워크 속도가 느릴 경우 불편함이 있지만 DVCS(분산버전관리시스템)인 Git를 사용할 경우 문제가 많이 해결된다. Git는 SVN 사용자가 쉽게 사용할 수 있도록 거의 비슷한 명령어 체계도 갖고 있다. 요즘은 Git도 편리한 GUI Client가 많아 SVN만큼 편하게 쓸 수 있다.Git는 기능이 너무 많아 어려워하는 개발자들도 있는데 SVN을 사용하던 방식과 거의 유사하게 사용할 수도 있으므로 시도해보기 바란다.


Git 호스팅 서비스인 Bitbucket.org를 이용하면 5명까지는 무료로 10명은 월 $10, 100명은 월 $100를 내면 된다. 100명 정도까지는 호스팅을 이용하는 것이 훨씬 비용적으로 유리하다고 할 수 있다.


2. 이슈관리시스템 (버그추적시스템)

필요성: ★★★★★

추천 형태: 호스팅

추천 서비스: Atlassian Jira OnDemand

추천 시스템: Jira, Redmine


요즘은 소스코드관리시스템을 아예 사용하지 않는 소프트웨어 회사가 거의 없지만 의외로 아직 이슈관리시스템을 사용하지 않는 회사는 많다. 엑셀이나 위키를 이용하거나 Email로 처리하는 회사도 있다. 그렇게 해서는 방대한 소프트웨어 개발 이슈를 효과적으로 처리할 수도 없고 많은 커뮤니케이션 비용이 들어간다. 수십 년 동안 진화를 거듭해온 이슈관리시스템들은 제대로 사용하기만 해도 회사 개발문화가 상당히 성숙하게 바뀔 수 있다. 아직 이슈관리시스템을 사용하고 있지 않다면 당장 도입하기 바란다.


과거에는 Trac, Mantis 등이 많이 사용되었다. 여전히 좋은 시스템들이지만 모든 것을 비교해보면 요즘은 Jira와 Redmine을 추천한다. 이슈관리시스템도 비용적인 측면에서 호스팅을 권장하고 Atlassian의 Jira OnDemand을 추천한다. 10명까지는 월 $10, 25명은 월 $100면 된다. OnDemand 스타트업을 위한 저렴한 비용을 제시하고 있다. 회사가 커지면 나중에 직접 구축하고 그 동안 쌓아 놓은 데이터는 마이그레이션이 가능하다.


3. 빌드시스템

필요성: ★★★☆☆

추천 형태: 자체 구축

추천 시스템: 자동화된 빌드 스크립트 자체 제작, Jenkins (구 Hudson)


위에서부터 점점 내려올수록 사용하고 있는 비율이 줄어든다. 빌드시스템은 소프트웨어 개발에 꼭 필요한 시스템이다. 많은 회사가 개발자 PC에서 Eclipse나 Visual Studio의 IDE창에서 버튼을 눌러 빌드한 소프트웨어를 그냥 출시하곤 한다. 소프트웨어 개발에서 개발자 PC는 “더러운 환경”이라고 지칭한다. 테스트를 하거나 출시를 위한 소프트웨어는 깨끗한 빌드 전용 “빌드시스템”에서 빌드해야 한다. 또 자동화된 빌드 스크립트를 제작해서 One-step으로 모든 빌드가 끝나야 한다.


적어도 하루에 한번은 자동으로 빌드를 실행하여 소스코드가 항상 빌드가 가능한 상태로도 유지해야 한다. 이를 Daily Build라고 부른다. 소수가 개발하면 이런 것 신경 안 써도 어쨌든 개발이 되기 때문에 소홀하기 쉽다. 하지만 “더러운 환경”에서 대충 개발하는 것은 대단히 위험한 일이고 Daily Build를 하지 않는 것은 협업의 기본을 모르는 행위다. 빌드시스템은 자체적으로 구축해야 한다면 Daily build나 CI(지속적인 통합)을 위해 Jenkins등의 CI툴을 이용하면 좋다.


4. Wiki

필요성: ★★☆☆☆

추천 형태: 호스팅

추천 시스템: Confluence OnDemand


꼭 사용해야 하는 시스템도 아니고 특별히 추천을 하고 싶은 서비스도 없지만 Atlassian의 호스팅 서비스를 이용하면 연동이 쉬운 같은 서비스를 이용하는 것이 좋겠다. 비용도 Jira OnDemand와 같다.


Jira를 이용해도 상당히 많은 정보가 공유되지만, Wiki는 흩어져 있는 지식과 정보를 한군데로 모으는데 효과적이다. 하지만 Wiki는 결국 Tool이기 때문에 문서를 대신 작성해주지는 않는다. 그렇다고 Wiki를 사용하기 위해서 강제로 문서화를 시도하다가는 Wiki가 방치되기 십상이다.


스펙도 작성할 능력이 좀 되고 문서화에 거부감이 없다면 Wiki를 도입하는 것도 괜찮다. 모든 문서를 Wiki가 대신할 수 없지만 많은 지식을 체계적으로 정리할 수 있는데는 유용하다. 훌륭한 회사 자산도 될 수 있고 효율적인 소프트웨어 개발에 많은 도움을 준다.


5. 프로젝트관리시스템

필요성: ☆☆☆☆☆

추천 시스템: 시스템보다는 엑셀 파일 이용


시스템을 잘못 사용하면 배보다 배꼽이 더 큰 경우다. 좋은 프로젝트관리시스템이 많기는 하지만 대부분 스타트업이 사용하기 무거운 제품들이다. 프로젝트가 지연되는 것은 프로젝트관리시스템을 사용하지 않아서가 아니다. 스펙을 제대로 작성하지 않아서 지연되는 경우가 대부분이다. 스펙이 잘 작성되어야 개발범위가 명확해지고 상세한 개발일정 수립이 가능하다.


일 단위의 개발일정이 수립되면 엑셀에 작성을 해서 관리해도 충분하다. 오히려 웬만한 프로젝트관리시스템들보다 엑셀이 더 편리하다. 회사가 좀더 커져서 수많은 프로젝트와 인력을 동시에 관리해야 할 때 프로젝트관리시스템 도입을 검토해보는 것이 좋겠다.


기반시스템은 도입하는 것보다 제대로 사용하는 것이 더 중요하다. 각 기반시스템을 사용하는데 꼭 지켜야 할 규칙을 몇 가지 제시한다.


소스코드관리시스템

1. 회사의 모든 소스코드 및 개발문서는 빠짐없이 등록해야 한다.

2. 커밋 메시지 규칙, 리뷰 규칙 등 회사의 규칙을 모든 직원이 철저히 따라야 한다.

3. 공식적인 빌드는 항상 Tag(베이스라인)를 남겨야 한다.

4. 협업을 위한 코딩 습관을 가져야 한다. 즉, 머지(Merge)가 원활하게 되게 해야 한다. 소스트리를 견고하게 가져가야 하며 개발자가 함부로 파일의 이름을 바꾸거나 이동하면 안 된다. 소스코드 내에서도 함수를 이리 저리 옮기면 안 된다. 이외에도 지켜야 할 수많은 습관들이 있는데 협업을 하면서 차츰 익히면 된다.


이슈관리시스템

1. 전 직원이 모든 이슈를 이슈관리시스템에 직접 등록해야 한다. 대리 등록은 사양한다.

2. Email, 구두, 전화, 메신저 등 다른 경로를 통한 요청은 없애나가야 한다.

3. 스스로 능동적으로 이슈관리시스템을 모니터링 해야 한다. 사장이라도 필요한 정보는 보고를 요청하지 말고 이슈관리시스템을 통해서 확인하면 된다.

4. 모든 이슈는 전 직원에 오픈한다.


지금까지 스타트업에 필요한 기반시스템과 기본적인 사용규칙에 대해서 설명했다. 기반시스템을 사용하는 것만으로 회사 역량이 세계적인 수준이 되는 것은 아니다. 그야말로 기초 중에 기초일 뿐이다. 하지만 그러한 기초도 안되어 있다면 엄청나게 비효율적으로 개발을 하고 있는 것이다.


기반시스템은 일단 경험을 해보고 제대로 사용하기 시작하면 절대로 과거로 돌아가지 못한다. 때때로 과거에는 이런 좋은 시스템도 없이 왜 그렇게 고생을 했을까 회상하기도 한다. 물론 그때는 비효율적이라는 것을 몰랐었다.


소프트웨어 회사라면 이런 기본적인 것을 잘 갖춰야 진정한 역량인 분석, 설계 등의 역량을 향상시킬 수 있다. 아직 기반시스템을 제대로 갖추고 있지 않은 회사는 저렴한 호스팅 서비스부터 당장 갖추기 바란다. 시작이 반이다. 제대로 사용하기는 어렵지만 차츰 실력이 붙을 것이다. 혹시 어려움이 있거나 궁금한 것이 있다면 나에게 문의하기 바란다.


이글은 Techit에 기고한 글입니다.


image by plewicki



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

전규현 기반시스템

Trackback Address: http://allofsoftware.net/trackback/297 관련글 쓰기
  1. 좋은 글!

  2. bitbucket이나 github를 쓰면 소스관리+이슈트래킹+위키+코드리뷰까지 패키지로 사용가능하지 않나요?
    나중에 옮겨 간다면 마이그레이션 문제가 있긴하지만..한참 커졌을 때 이야기고..
    스타트업이라면 bitbucket이나 github정도면 대부분 해결가능해 보입니다.

  3. bitbucket은 간이 이슈관리와 Wiki가 포함되어 있습니다. 하지만 간이는 간이죠. Jira와 Confluence와도 쉽게 연동됩니다. github도 이슈관리, 코드리뷰, wiki를 모두 제공하고 작은 회사에서 쓰기에는 충분해 보입니다.

  4. Blog Icon

    먼저 소프트웨어 개발의 모든것 책 너무 잘 읽었습니다.
    빌드시스템은 자체구축을 위해서는 H/W가 필요하잖아요?
    그럴때 사용하면 괜찮을 SOHO용 서버 컴퓨터로 사용할 만한 제품이 궁금합니다.
    NAS처럼 이미 많은 기능이 기본 탑재된 시스템을 사용하는 것이 좋을까요?
    커스터마이즈가 자유로운 리눅스 등을 탑재해 서버시스템을 구축하는 것이 좋을까요?

    클라이언트 개발자 포함 5~6명가량 되고 전체 프로젝트 인원 10명정도 되는 소규모 그룹에서 말이죠...^^

  5. 안녕하세요. TJ님

    우선 적은 인원이면 Hosting을 사용하길 권장합니다.
    그래도 자체 구축하실 것이라면 굳이 비싼 장비를 쓰실 필요는 없고 백업을 잘 받으시는 것이 더 중요합니다.

    OS는 관리에 용이한 OS를 선택하면 좋겠습니다. Linux를 잘 아시면 Linux가 좋겠죠.

한국에서 외국인 개발자가 일하기 어려운 이유

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




소프트웨어 회사의 경영자는 항상 개발자 수급을 고민한다. 우수한 인재를 싸게 쓰고 싶지만 좋은 개발자를 찾기도 어렵고 인건비가 여간 비싼 것이 아니라고 생각한다. 물론 개발자 입장에서는 많지 않지만 경영자는 반대 입장이다.


그러다 보면 저렴하고 우수한 외국인 개발자를 쓰고 싶은 욕구가 생겨난다. 중국이나 인도 개발자들은 평균적으로 인건비가 국내 개발자보다 저렴하고 실력도 뛰어나다. 그래서 실제로 많은 회사들은 외국인 개발자 채용이나 현지 개발센터를 설립하는 일들을 그동안 많이 해왔다.


경우에 따라서는 인건비 이슈가 아닐 수도 있다. 외국인 개발자를 활용하는 것이 국내 개발자에게 들어가는 비용보다 더 많이 들어가기도 한다. 그럼에도 불구하고 개발 인력 수급 문제 해결과 조직의 Global 문화 흡수 등 여러가지 이유로 외국인 개발자 활용 전략을 추진해 왔다. 


나름 성과를 내고 있는 회사도 있으나 대부분은 실망이 큰 것이 사실이다. S사 같은 경우는 그룹차원에서 현지 개발자를 채용하여 각 계열사로 정책적으로 외국인 개발자를 배치하고 있으나 경영진의 바람과 외국인 개발자와 같이 일하는 국내 개발자와 평가는 차이가 꽤 크다. 뛰어난 개발자를 데려다가 단순 코더로 전락 시키기도 하고 문화적인 충돌로 인해서 거의 활용을 못하는 경우가 허다하다.


그럼 미국 실리콘밸리에서 일하는 인도, 중국 개발자들도 똑같은 상황일까? 전혀 그렇지 않다. 유독 우리나라에서 외국인 개발자들과 같이 제대로 일을 못하는 이유는 언어 장벽외에도 여러가지가 있다. 이것을 잘 생각해 보면 바로 우리들이 가지고 있는 문제를 고스란히 보여주기도 한다. 


우리는 왜 외국인 개발자와 제대로 같이 일을 하지 못할까?

 

1. 언어의 장벽


요즘은 영어를 잘하는 직원들이 많지만 소프트웨어 개발자들 중에는 영어를 잘하는 비율이 좀 낮은 것 같다. 생활영어 정도를 할 줄 안다고 해도 외국인 개발자와 회의나 리뷰를 제대로 하기 어렵다. 대화가 가능해도 훨씬 많은 노력을 들여야 하기 때문에 부담이 커진다. 특히 인도 영어는 더욱 알아 듣기 힘들다. 


2. 문서


외국인 개발자와 같이 일하려면 문서를 기반으로 일해야 한다. 대부분은 프로세스, 스펙 등에 익숙하기 때문에 우리나라와 같이 대충 말로 때우거나 지시하는 환경에 익숙하지 않다. 의사 소통도 쉽지 않은데 매번 말로 지시하고 확인하는 일이 쉽지 않다. 


3. 번역


외국인 개발자와 같이 일하려면 문서를 영어로 작성해야 한다. 모든 문서를 영어로 작성하면 우리나라 개발자가들이 힘들기 때문에 영어로만 작성하기도 어렵다. 한국어로 작성하고 영어로 번역을 해도 보통 어려운 일이 아니다. 최신 문서를 유지하기도 어렵고 싱크가 맞지 않는다. 보통 일이 아니다. 스펙을 제대로 작성했으면 한번만 번역을 하면 되는데 스펙을 제대로 작성하는 경우도 많지 않고 쉽게 바뀌는 일이 흔하기 때문에 매번 번역에 어려움이 있다.


4. 문화


외국인 개발자들이 한국에서 개발을 하면 문화적인 충격이 만만치 않다. 회사와 가정이 똑같이 소중한 외국인 개발자에게 무조건적인 헌신을 요구하는 경우가 많은데 상당히 어려움을 겪는다. 특히 야근 강요와 무리한 일정 요구는 많은 트러블을 일으킨다. 가끔은 후진국 사람이라고 무시하는 경향도 있다.


5. 전문가


우리나라 개발환경은 전문가가 제대로 일하기 어려운 환경이다. 보안 전문가를 데려다가 제대로 활용하지 못하기도 한다. 전문가들이 우리나라에 오면 그냥 똑같은 개발자가 되는 경우가 흔하다. 전문가가 제대로 역할을 하려면 스펙도 제대로 작성되어야 하고 합리적인 개발문화가 있어야 한다.


결론 


이러한 현상은 외국에 외주를 줄 때도 비슷하다. 외국에 외주를 주거나 개발센터 설립등이 쉽지 않은 이유이다.  스펙을 제대로 작성하고 수평적인 조직구조 등 제대로된 개발문화를 가지고만 있다면 이 또한 해결될 수 있다.


 image by niyam bhushan


 


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

전규현 사람과 기술

Trackback Address: http://allofsoftware.net/trackback/293 관련글 쓰기
  1. 경험상...말씀하신 내용에 100% 공감합니다.
    특히 4번에서 언급하신 문화의 경우 더더욱 공감이 갑니다. 서로가 서로를 이해하기 힘들죠.^^

    예전에 같이 일했던 인도 개발자는 엄청나게 야근을 요구하는 일정에 한국은 Crazy라는 표현과 함께 중도 포기하고 귀국해버렸던 기억이 나네요.. 그 때 저를 포함한 우리 나라 개발자들은 거의 16~18시간씩 일했었거든요.ㅠㅠ

스타트업을 위한 조직론

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



스타트업의 젊은 경영자 중에는 관리 경험이 부족하여 조직관리에 취약한 사람이 많다. 반대로 관리 경험이 많거나 특히 조직관리가 아주 철저한 대기업 출신들은 종종 스타트업에 걸맞지 않은 부담스런 관리 기법을 적용하여 효율성을 떨어뜨리곤 한다.

그럼 스타트업은 어떤 조직관리가 적합할까?

일반 기업에 적합한 조직관리 기법은 소프트웨어 회사와 맞지 않는다. 특히 작은 조직에는 적합하지 않다. 반대로 취미생활 하듯 조직을 관리하면 평생 구멍가게를 못 벗어난다. 전혀 준비가 안된 상태에서 비즈니스가 잘되면 조직은 커지고 회사가 급속도로 비효율적으로 변하게 마련이다. 비즈니스는 잘 되는데 이런 문제로 어려워진 회사를 많이들 알고 있을 것이다.

일반적인 소프트웨어 조직도 마찬가지지만 효율적인 소프트웨어 개발을 위해서는 특히 스타트업이라면 외형적인 조직관리는 Zero에 가까워야 한다. 대신에 몇 가지 필요한 요소가 있다.


첫째 기반시스템 활용


소프트웨어 회사에 필수적인 기반 시스템 두 가지는 SCM(소스코드관리시스템)과 ITS(이슈트랙시스템 또는 버그관리시스템)이다. 추가로 Wiki를 쓰기도 한다. 일반관리를 제외한 거의 모든 관리 부담은 기반시스템이 다 흡수를 한다.

이를 통해 별도 지시, 보고서 작성, 보고에 들어가는 품을 대폭 줄일 수 있다. 잘만 활용하면 10분의 1까지 줄일 수 있다. One-man 컴퍼니라면 시스템 대신 공책이나 엑셀을 쓰기도 하는데 회사가 커지면 문제가 된다. 혼자 일해도 기반시스템을 활용하는 것이 더 효율적이다. 시스템을 구축하는 비용과 관리부담을 걱정하곤 하는데 호스팅을 이용하면 된다.

Atlassian에서는 이슈트랙시스템인 Jira를 10명까지는 한 달에 만원이면 이용할 수 있다. Git나 Murcurial을 5명까지는 무료로 10명이면 한 달에 만원으로 무제한 용량을 사용할 수 있다. Wiki도 마찬가지다. Github를 이용할 수도 있다. 여기에 관한 자세한 내용은 추후 다시 다루겠다.

회사가 웬만큼 성장할 때까지는 이런 저렴한 호스팅을 사용하는 것이 효과적이다. 추후에 Migration도 문제없다. 보안문제를 걱정하곤 하는데 이는 기우이다.


둘째 문서다.


흔히 혼자서 또는 2,3명이 개발을 하면 문서가 필요 없다고 생각한다. 이는 사실이 아니다. 문서를 잘 작성하지 못하거나 제대로 작성해본 경험이 없거나 작성하기 싫어서 대는 핑계일 뿐이다. 문서를 작성하면서 개발을 하는 것이 더 빠르고 효율적이다.

좀더 정확하게 말하면 상황에 맞게 적절하게 작성해야 한다. 스펙을 작성할 때도 정말 간단하게 적을 수도 있고 Unit test가 일부를 대신하기도 하고 설계는 종이에 해도 된다. 또한 상당부분을 기반시스템이 보완하므로 정작 필요한 문서 양은 많지 않다. 조직이 적다고 변변한 문서도 없이 개발을 한다면 그 자체로 비효율적이고 조직이 커질수록 커뮤니케이션 비용이 급속도로 늘어나고 커뮤니케이션 오류로 인한 재작업 비용이 크게 증가한다.


셋째 역할구분이다.


스타트업에서는 개발자 한 명이 많은 역할을 한다. 기본적으로 기획, 분석/설계, 구현, 테스트, 디자인(종종), 기술영업, 기술지원 등 이루 말할 수 없는 많은 일을 한다. 그렇게 준비 없이 회사가 성장하면 개발자 인원수는 몇십배로 늘었는데 하는 일을 별반 다르지 않은 경우가 허다하다. 디자인과 테스트를 분리하기도 하지만 제대로 분리가 안되고 나머지 일들은 그대로 수행하는 경우가 많다.

이유는 개발자의 역할을 정확하게 정의를 하지 못해서 발생한다. 많은 경영자들은 이 모든 일들이 개발자가 원래 해야 할 일이라고 착각한다. 이를 방지하려면 조직의 전문성에 대한 이해가 먼저 필요하다.

혼자 일을 해도 기획, 개발, 테스트를 구분해서 일해야 한다. 필요한 문서도 만들어야 한다. 혼자 일해도 그렇게 일하는 것이 더 효율적이다. 그러다가 회사가 커지면 개발자만 N배로 늘리는 것이 아니고 적절한 비율로 전문적인 역할을 분리하고 프로세스를 만들어나가면 된다. 전문적인 조직으로 분리하는 순서와 비율은 회사마다 다르지만 보통의 순서는 테스트, UI디자인, 마케팅, 기술지원, 기술영업 등이다.

혼자 일해도 역할이 잘 구분되면 부족한 부분을 외주로 돌릴 수도 있다. 한두명이 일한다고 역할을 섞어서 일하면 다른 사람이 효과적으로 도와주기도 어려워진다.


지금까지 얘기한 방식은 스타트업에도 해당하지만 일반적인 소프트웨어 회사도 별반 다르지 않다. 처음부터 이런 조직관리를 준비해야 회사가 커져도 효율성을 계속 유지할 수 있다. 일반적인 회사는 인원이 20명, 50명, 100명, 300명을 넘어갈 때 큰 위기를 한번씩 맞는다.

관리 패러다임이 바뀌고 이때마다 여러 가지 관리기법을 추가한다. 이러한 방법은 소프트웨어 회사에는 잘 적용되지 않는다. 오히려 일반적인 회사의 관리 패러다임을 소프트웨어 회사에 적용하면 효율이 더 떨어진다. 소프트웨어 회사에는 소프트웨어 회사에 알맞은 관리가 필요하다.


이글은 Tech it에 기고한 글입니다.


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

전규현 개발조직 스타트업, 조직

Trackback Address: http://allofsoftware.net/trackback/296 관련글 쓰기
  1. 저 앞의 서두는 이쪽은 아니지만 지금 눈앞에서 벌어지는 일이기도 해서 남얘기 같지 않군요.
    정규군엔 정규군다운, 게릴라전에는 게릴라 전에 맞는 인적 구성과 자원활용법, 전술 등이 다른데
    몸에 안맞게 옥죄는 느낌이랄까요...

  2. 안녕하세요. 기반시스템의 활용도를 높여서 관리부담을 좀 줄여보세요. ^^

  3. 으아~ 유익하다..ㅠㅠ

美 SW 힘은 평등한 호칭 문화에서 생겼다

필자는 지금까지 소프트웨어 조직에는 수평적이고 자율적인 문화가 필요하다고 했다. 하지만 수직적이고 상명하복 식 조직문화를 없애고 평등한 토론에서 오는 창의적이고 효율적인 개발문화를 만들고 싶어도 넘기 힘든 큰 장애물이 있다...

여자 개발자가 희망이다

소프트웨어 회사를 포함해서 많은 기업들이 개발자가 부족하다고 아우성이다. 이렇게 개발자가 부족하게 된 이유는 열악한 개발 환경에 따른 뛰어난 개발자들의 이탈과 저급개발자 양산 등 여러 환경, 정책적인 문제가 있지만 여자 개발..

외주 SW 개발의 비극

열악한 소프트웨어 외주 개발 문제는 우리나라에서 소프트웨어가 3D 취급을 받는 주요한 원인 중 하나다. '갑을병'으로 이어지는 외주도 모자라 '갑을병정무'까지 3,4단계 외주를 주기도 한다. 하청에 재하청이 이어질수록 열악한..

SW를 '을'로 취급하는 하드웨어의 무지

필자는 펌웨어를 개발하는 등 하드웨어 팀과 같이 일하는 소프트웨어 개발자를 자주 만난다. 그런데 많은 개발자들이 하드웨어 팀과 일하기 힘들다고 하소연한다. 회사에서 하드웨어에 더 집중하고 투자하며 소프트웨어는 보조로 생각한다..

한국 SW가 해외에서 힘 못쓰는 이유

01/02/03은 몇년 몇월 며칠일까? 우리나라 사람들은 2001년 2월 3일로 읽지만 미국사람들은 2003년 1월 2일로 읽는다. 이것이 다 일까? 호주사람들은 2003년 2월 1일로 읽는다. 이렇듯 나라마다 날짜를 쓰는..

고객이 SW를 망친다

우리나라는 고객이 소프트웨어와 개발사를 망치는 경우가 많다. 외국 소프트웨어 회사와는 다른 잣대로 우리 소프트웨어 회사를 대하는 이중성 때문에 우리나라 소프트웨어 회사는 더욱 어려움을 겪는다. 물론 이런 현상이 꼭 고객 탓만..

자신의 코드에 발목 잡힌 개발자들

필자는 국내외 다양한 소프트웨어 회사에 다니는 여러 개발자를 만날 기회가 자주 있고 각 회사의 개발 이야기를 종종 듣는다. 그 중에서 3가지를 소개할까 한다. 우리나라 개발자들이 다양한 일을 하지 못하고 하던 일만 계속하게..

CMMI는 회사를 망칠 수도 있다

필자는 최근 소프트웨어와 시스템 공학 역량의 성숙도를 평가하는 CMMI(Capability Maturity Model Integration)를 적용하여 오히려 어려워진 H사 직원 S씨를 만났다. 그동안 SI회사 등 여러 곳에..

실리콘밸리 개발자 눈에 비친 한국 SW회사

얼마 전 실리콘밸리의 한 개발자 B씨를 만나서 소프트웨어 개발에 대해 많은 얘기를 나눴다. 과거에 같이 일했던 친구인데 미국에서 태어난 중국인으로 미국 대학을 나와 실리콘밸리에서 20여년간 개발자로 일을 했으며 10여년간은..

개발 프로세스 관료화의 함정

소프트웨어를 효율적으로 개발하는 비법 아닌 비법은 개발 프로세스와 개발 문화의 적절한 균형에 있다. 김치를 담그는 레시피처럼 확실한 비율을 정하기는 어렵다. 개발 프로세스는 양날의 칼이다. 적절히 사용하면 개발 효율은 올라가..