대한민국에는 소프트웨어가 없다 를 읽고..
글쓴이: kksir / 작성시간: 화, 2006/05/23 - 9:27오전
안녕하세요.
초판이 2003년에 출판되었으니 나온지 좀 된 책이네요 ; (
이제야 이 책을 읽게 되었습니다.
저는 대학교4학년으로 곧 취업을 해야 할텐데.
지금까지는 나름대로 좋은 커리어를 가지고 있다고 생각하여
취업은 문제 없다라고 생각했습니다.
그런데 이 책을 읽고나니 이왕이면 좋은 개발프로세스를 가지
고 있는 회사에 취직했으면 좋겠다고 생각이 듭니다.
국내에서 그러한 개발프로세스로 개발되는 곳이 있기는 한지
마저 의심이 가는데.
혹시 개발프로세스가 잘 되어 있는 회사에 대해 얘기해 보는
것은 어떨까요?
아니면 개인적으로 연락주시면 너무 좋겠습니다.
제가 알기론 다음(daum cor)의 경우는 개발프로세스를 상당
히 개선하려 노력한다고 알고 있는데..
흠.. 고민되네요. ^^;
Forums:
하하..
그런 질문했을때 얼마전 선배얘기가 생각납니다.
'우리나라에서 그런 회사 찾으려면 차라리 붕어빵에 붕어를 찾는데 빠르다'..
저도 이제서야 겨우 경력 2년차지만..
1년간 사수하나 없이 무조건 혼자서 신입을 삽질만 시키다가..
대체 그동안 결과물이 뭐냐며 갈구며 나가라 했던 현실이 떠오르네요..
저는 지금 경찰/소방공무원 시험 준비중입니다..
그런 회사는 없고, 그런 회사를 만드심이...
개발 프로세스는 아직도 개발자들과 관리자들의 화두인듯 합니다.
유명하다는 사람들은 자기만의 개발 프로세스가 좋다고 하지만, 정답은 없죠.
톰 디마르코의 말대로, 소프트웨어는 햄버거가 아니니까요...
제가보기에도 우리나라에는 정말로 개발자들이 동의하는 개발 프로세스가 확립된 회사는 없는거 같습니다.
저도 팀내에서 그런 프로세스를 만들기위해 노력하지만, 쉽지가 않네요...
(앗, 혹시 누가 알고 계신가요? 그런회사,,, 있으면 알려주세요. ^^)
제가 추천하는 방법은 조엘 테스트해서 가장 점수가 높은 회사에 취직하신 후,
팀장이나 PM까지 올라가서 개발 프로세스를 확립하는게 가장 빠를듯 싶습니다.
조엘 테스트에서 높은 점수가 나온다는건 꽤 가능성은 있다는 뜻일테니까요.
그럼, 각 회사의 조엘 테스트를 어떻게 할것이냐???
그건, 발품을 좀 팔아야겠죠.....^^;;;
보통 관리자들이
보통 관리자들이 개발자들의 소스를보고 자기가 보고 이해하기 힘들면 어렵다하여 다시짜라혹은 표준에 맞추라.. 하는..
----------------------------------------------------------------------------
아.. 설마 정말로
아.. 설마 정말로 없는건가요? 제가 모른다고 믿고 싶습니다.
그래도. 그나마 나은 회사를 알고 계시면 슬쩍 말씀해 보심이..
candinate 님.. 비전을 볼 수 있는 말씀을 해 주세요..
저 이제 사회나가는 사람인데 ㅜ.ㅜ ㅎㅎ
안타깝습니다.. 일본의 경우는 어떠한가요? ㅡㅡ^
::::::::::: Easy come, Different go.
::::::::: Http://www.geekstep.org
::::::::::: Easy come, Different go.
::::::::: Http://www.geekstep.org
몇곳 알고는 있습니다.
대규모는 아니고, 직원 십여명에서 수십명 정도의 대기업은 아닌 회사들 중 그런 곳을 몇곳 알고 있습니다.
코드 페스트 등에 참여하는 인물들의 면면을 살펴 보시면 꾸준히 참석하시는 몇몇 분들이 계시는 회사가 있습니다.
프로그래밍에서 손뗀 제가 알고 있을 정도이니 ... 실제로는 한참 더 될 것입니다.
회사명을 말하면 간접/직접 광고가 될 터이니 ... 이름을 말하기는 좀 그렇지만, M 모사, U 모사 등등이 있습니다.
---------
즐겁게 놀아보자.
http://akpil.egloos.com
---------
트롤 출현시 대처요령 (phpBB 용)
불여우 1.5.x ;
http://www.extensionsmirror.nl/index.php?showtopic=4814&st=0&p=16579&#entry16579
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
와서
와서 직접느껴보심이...ㅎㅎ
----------------------------------------------------------------------------
개발프로세스라...
일단 대학 학부과정에서 "소프트웨어 공학" 과정이 있는 학교가
몇개나 있는가 부터 시작을 해야싶군요.
제가 학교다닐때는 정말 손꼽을 정도였는데
이쪽 분야가 활기를 띠면서 과목도 많이 개설되었고
연구도 많이 시작되었죠.
대개 이런 연구비용은 업체에서 부담하게되는데
소프트웨어 공학 연구가 활성화됨은
업체들이 많이 관심을 갖고 있다는 반증이겠죠.
이미 90년대 후반부터 학계와 연구소, 기업들에서 관심있는 사람들이
한국 소프트웨어 심사원 협회 (가칭 kspice)를 만들어서
프로세스를 장려 및 개선해 왔고,
ETRI에서는 여러차례 개발프로세스를 공개, 발표해서 정부차원에서
사용을 장려해왔고,
소프트웨어 진흥원에서는 2000년대 초반에 CMM 바람을 일으켜서
정부돈(!)으로 프로세스개선 에대한 관심을 고조시켰지요.
반면에 (개발)프로세스는 배부른 업체들의 전유물처럼 여겨져
밤샘 작업에 시달리는 개발자들은 오히려 거부감을 보여온 것도 사실이죠.
많은 경우 프로세스는 일반적인 개발자들을
어떻게 효율적으로 관리(!)할 것인가에 중점을 두고 있는데
우리처럼 수퍼 개발자에 대한 환상을 갖고 있는 경우에는
발목을 잡는 행정절차로만 여겨질 수도 있습니다.
어쩔때는 개발자는 이런저런 절차를 갖고 싶고 테스트도 제대로 해보고 싶지만
일정에 쫒기고 마케팅에 치이고...일요일날도 회사에 나가야 하는데
워드 작업이나 하고있으려면 짜증도 나는게 현실이죠.
하지만, 우리네 수준이 절대로 안타까운 경우는 아닙니다.
조금만 관심을 갖고 보시면 어느 정도 규모의 회사들은
전부 자체적으로 프로세스를 갖고 있습니다.
많은 경우 SI업체들은 그럴수밖에 없는 구조이기도 하지요.
(입찰을 받고, 외주를 주려면 관리 방법이 필요할 수 밖에 없지요.)
또, 제가 본 국내 통신업체들도 모두 훌륭한 개발프로세스(!)를
지니고 있었습니다. 중소기업에서는 핸디소프트웨어라는 모범적인 회사도 있지요.
제자신도 학교에 있을때는 이런저런 프로세스는
교과서에나 있는거라고 여기고 새벽별보면서 코딩하는걸 낙으로 살았지요.
하지만 관심을 갖고 주위를 둘러 보니 이건 단지 핑계에 지나지
않았다는 생각입니다. 하려면 할 수 있는데 굳이 안해도 되는 핑계거리가
더 많았다는 것이지요.
"대한민국에는 소프트웨어가 없다"는 책은 kksir님의 글을 보고 첨 알았는데
목차를 보니 저자의 (미국 회사에서의) 경험이 많이 반영된 듯 하군요.
아마 이분도 미국의 시스템에 많이 충격을 받으셔서 후학을 위해서 적은 신것 같은데,
재미있을 것 같습니다. 혹시 읽으신 분 있으시면 리뷰좀 달아 주세요.
"전부 자체적으로
"전부 자체적으로 프로세스.."
개발이 20배이상 지연되는 그.. 프로세스...말씀이군요..
----------------------------------------------------------------------------
설마...
어짜피 프로세스는 자체 프로세스이지요.
저는 좀
저는 좀 혼란스럽네요.
예전에 이곳에서 'S/W 개발은 창조 활동이라서 진척이 일정하지 않은데, 일정을 두고 관리되는 것을 못 참겠다'는 요지의 글과 거기에 동감하시는 많은 분들의 글들을 보고(지금 찾지는 못하겠네요) 놀랐던 기억이 있는데, 또 한편으로 대한민국에는 제대로 된 프로세스를 가진 곳이 없다는 의견도 제기되어서요.
여러 업체에서 (대외적인 홍보용일지언정) CMM, SPICE 등을 적용하고 있는 것으로 알고 있습니다. 조직에서의 제도도 제도지만, 구성원으로서 처음에는 번거롭고 의미없게 보일 수도 있는 그러한 프로세스들의 절차들을 인내하며 수행할 수 있을지(예를 들면 개발이 공정표에 의해 진척관리가 되고, 업무의 반이 문서화 작업이라고 해도 감당하며, 많은 시간을 회의로 보낼 수 있을지 등)도 생각해 보아야 할 것 같습니다.
케케케~
글쎄요.
우선 오해를 줄이기 위해서 미리 밝히면.
저는 학교에서 소프트웨어 공학을 전공했고.
제 경험은 외국계 업체의 한국 지사 시절에 얻은 것이고.
spice 심사원 교육을 받았고.
한국내 프로세스 개선 회의를 몇 번 참가한 경험에서 적었던 것입니다.
저역시 학교에서 SE공부할때
이런것은 말장난일꺼야에서 시작해서
문서작업은 정말 싫어를 남발했었지만,
미국지사라다보니 본사쪽 개발프로세스를 따라야만 코드를 submit할 수 있고
그러다보니 본의아니게 프로세스를 공부하게 되었습니다.
그때 느낀점은 SE책에서 보던 것들이 탁상공론이 아니고
실제로 현장에서 진행되고 있었다는 것이죠.
그러면 이런 외국계 회사들만 그런가?
전공이 전공인지라 국내업체 현황을 알아보기 위해
심사원 협회에서 진행하는 교육이나 세미나를 들으러 갔는데,
삼성계열사들, LG계열사들, 포스데이타, KT, 핸디소프트 등
사례발표를 들어보면 실제로 각 회사에 맞는 프로세스를
확립하기 위하여 많은 노력들을 기울이고 있었습니다.
그러니 비현실적이란 말은 아니란거죠.
그리고, 위글에대한 나름대로의 변명은...^_^
- 개발이 20배이상 지연되는
아마도 그럴수도 있을 것입니다. 그런데, 이미 20배이상 지연된다라는 근거를
제시할 수 있는 개발자라면 이미 나름의 프로세스를 가지고 있어야 합니다.
(비교 대상이 없다면 몇 배이상이라는 말을 쓰기 어렵겠죠)
그러면 개발이 20배이상 지연되는 프로세스와 충돌이 난 것으로 봐야하고
둘 중의 하나는 폐기처분되어야겠지요.
20배 이상 지연되게 만드는 프로세스를 갖고 있다는 느낌이 든다면
아마도 그걸 운영하는 담당자가 교육을 게을리 했거나
제대로 운영을 하고 있지 못하다는 생각이듭니다.
대부분 복잡하고 많은 문서화를 요하는 경우는
장기간 운용되고 많은 유지보수가 요구되는 시스템인 경우며
각 시스템 영역마다 나름대로의 융통성이 발휘되어야 겠지요.
- 구성원으로서 인내하며 수행할 수 있을지
일단 업무의 반이 문서화 작업이다. 제 경험을 보면 사실이었습니다.
처음에 입사해서 그런 말을 들었을때는 비효율이란 단어가 생각났지만,
실제로 익숙해지면 그렇게 힘들지 않습니다. (물론 제 생각입니다.)
어차피 템플릿 다있으니까 내가 실제로 하는 일을 기록하는 정도입니다.
당연히 저에게도 도움이 되는 일이지요.
- 일정을 두고 관리
제 경우에 관련된 프로세스를 예를 들어보면,
(저는 통신시스템에 부가 기능을 추가하는 작업을 주로 했습니다.)
* 일정 계획 - PM과 일정 상의후 계획을 짭니다. 대개 2-3달 일정이고 급하면 1달.
이때 다음 과정들에 대한 일정이 대강 나오게 됩니다.
* design review - 설계 및 구현의 대강을 기록하고 어떻게 시험할지 계획 작성해서
담당자들과 회의를 합니다.
* code review - 실제 코드를 작성하고 문서화하거나 diff등을 통해서
어떤 부분이 변경되었는지를 관계자(!)들과 회의합니다.
* submit
이러는 동안 테스터분은 제가 구현할 부가 기능을 어떻게 시험할 것인지 계획하고,
시험하고 결과보고하는 회의를 갖을 수 있고, 저는 거기에 참석해야 하고요,
다른 개발자들의 review 회의에도 가끔 참석하고요...
이런 것들이 서로 충돌없이 진행되게 도와주는 것이 PM의 일정관리였습니다.
- 그럼 진짜 발목잡는 일이 없냐?
사람이 하는 일인데 완전한게 어디에 있겠습니까?
쉽게쉽게 하면 될 것같은데 이런저런 제약사항이 많아서
(3줄 고치면 되는데 한달 걸린다면...--)
진도가 안나갈때는 저도 비효율스런 프로세스에 짜증스럽기도 했지만,
결국은 이게 안전망과도 비슷한 것이란 생각이 들었습니다.
"급커브길에 사고가 많이 생기니 천천히 가세요"란 팻말처럼 말입니다.
한편, 혹시나 있을 비효율스런 프로세스를 개선하는 일도
개발자가 참여해야할 중요한 책임중의 하나일것입니다.
- 그래도 의구심이 드신다면
요즘 아는 선배통해서 "The Art of Project Management"를 읽게 되었는데,
이 저자는 MS에서 PM으로 일했다고 합니다.
MS정도의 규모니까 가능할 거야란 생각도 있겠지만,
위의 혼란을 느끼시는 개발자분들에게
PM입장(이 사람도 초보 PM때는 역시 혼란스러웠다고 말하고 있습니다)의
이 책을 읽어보시라고 권하고 싶습니다.
단순히 개발뿐만이
단순히 개발뿐만이 아니라 모든 일을 함에 있어서의 프로세스 자체는 항상 문제가 되고 고민을 하게 되는 부분이 아닐까 합니다.
사실 업무 특성이 달라진다고 해도 실제로 프로세스 자체는 그렇게 크게 달라지지 않는것이 있구요.
같은 분야가 아니라고 해도, 다른 분야의 프로세스들을 살펴보고 좋은 부분이 있으면 받아들이는것이 좋지 않을까 합니다.
업무를 진행하면서 업무 사이클을 파악하고 각 사이클 단위별로 필요한 업무를 정리하고, 이 각 업무 단위별로 필요한 작업내용과
문서들을 정리하고 이에 따른 문서 양식을 준비하고, 작업 내역을 표준화 하고..실제로 업무 프로세스를 만들어내는 작업 자체는 언제나 한결같다는 생각입니다.
단지 문제가 되는건 우선 이런 초기 작업들을 생각하고 만들어낼 시간이 주어지는가, 이를 실제 업무 시스템에 적용할만큼의 초기 여유가 주어지는가..
관리자와 실무자가 이에 대한 필요성을 절감하고 있는가, 그리고 이런 관리 프로세스나 업무 프로세스등에 대해서 얼마만큼의 개념을 가지고 있고
어느 정도까지 접근이 가능하느냐 등이 실제로 문제가 될 듯 합니다.
화이팅입니다.
위의 댓글들을 읽어보기 참 재미있군요.
저는 뭐 "대한민국에는 소프트웨어가 없다" 라는 책을 안봐서 모르겠고요.
우리나라에도 정착된 방법론을 가진 회사들이 많습니다. 너무 걱정하지 마시고요.
팀장이 되서 프로세스를 정립하겠다라는것은 어불성설이 됩니다.
(프로젝트 관리체계를 갖추는 것과 프로세스를 정립하는것에는 확연한 차이가 있으니까요.)
윗님의 소프트웨어 프로세스 개선분야에서의 문제제기도 전적으로 동감합니다만,
프로세스도 일종의 방법론으로써 SPI가 아니더라도 여러가지 많습니다.
회사들마다의 테일러링에 따라 다른법이고... 분명히 주먹구구식의 회사가 많지만,
걱정하시는 것만큼 적지는 않습니다.
그리고 SI는 비추입니다. 개발 프로세스 없습니다.
또 웹으로 장사하는 회사도 비추입니다. 프로젝트 기간이 짧아서 프로세스 돌릴 시간도 안됩니다.
(국내에는 구글같은 회사가 없으니까요.)
소프트웨어 만을 전문적으로 하는 회사도 피하시는게 좋을것입니다. 시스템을 모두 다루는 회사가 좋습니다.
일본은 비교적 프로세스 잘 갖추어져 있습니다. 거의 모든 프로세스나 방법론은 일본의 벤치마킹입니다.
하지만 비추입니다. 개발로 가도 않좋고 상위로 가도 않좋습니다. 분명한 차별이 있습니다.
답이 됬으면 좋겠네요.