2007년 06월 12일
아프리카의 IT 업무
IT 코리아의 일그러진 진실
써야지 써야지 하고 있던 글인데 위의 글 읽고 씁니다.
저는 남아공 요하네스버그에서 개발쪽 일 시작해서 지금은 QA 로 옮겨갔지만 가끔 제가 일하던 프로젝트 유지 보수해야 하면 개발일도 가끔 합니다. 주 언어는 perl, 웹 프로그래밍+ SyBase 입니다. 직원은 서른 명이고 인사/세일즈 담당은 그 중 다섯 명입니다. 나머지는 다 기술직입니다.
우선 프로젝트를 하기로 결정하면 저희 쪽에서 (견적이라고 하나요? quote) 를 뽑습니다. 거기에 문서화 작업이 포함됩니다. 만약 회사 A 가 저희 회사에게 프로젝트를 맡기고 싶다면 먼저 한화로 500-1000 만원 정도의 문서화 비용을 내야 합니다. 그러면 저희 회사에서는 프로젝트 규모에 따라 최소한 2주, 길게는 6주 정도 Requirement Analysis (요구분석?) 을 합니다. 그리고 저희가 개발해야 할 프로그램을 와이어프레임까지 (만들 스크린 설계) 포함해서 제출합니다. 가장 최근에 했던 프로젝트는 다섯명의 개발자가 네 달 동안 일해야 하는 양이었으므로 RA 역시 300 페이지 정도 되었던 걸로 기억합니다.
RA 의 중요성은 절대적입니다. 우선 어떤 시스템을 만들 것인지 세부사항까지 정리해야 정확한 견적이 나올 수 있고, 사인하는 사람 입장에서도 미리미리 체크를 할 수 있지요. 시스템 만들 사람들이 제대로 이해 했는지 아닌지 확인하는 것도 그 쪽 책임이 되고요. 법적으로 이 문서가 제일 중요합니다. 그 문서 안에 있는 항목은 다 만들어 준다는 조건으로 이만큼 돈을 요구합니다, 그런 거니까 나중에 개발 다 되었는데 이거 바꿔주세요, 이거 당신네들이 잘못 이해했어요 이렇게 헛소리 하는 거 미리 차단할 수 있습니다.
RA 사인 받으면 그 때부터 또 문서화 작업 들어갑니다. RA 를 바탕으로 technical specification 을 헤드 아키텍트와 그 밑의 고급 개발자들이 만들어 아래 개발자들에게 넘깁니다. 아래 개발자들은 그 문서만 보고도 별 문제 없이 작업할 수 있어야 합니다. 그냥 문서화 없이 무작정 시키면 처음엔 편하지만 결국은 시니어들이 개고생한다는 걸 겪었기 때문에 object 하나, method 하나까지 다 적고 데이터베이스 설계도 만들고, 데이터 타입과 status 다이어그램까지 다 만들어 넘깁니다. 예를 들어 유저란 object (객체?) 인터페이스를 만들어야 한다면 유저 properties, methods, status diagrams, store procedure structures, screen layouts, database specifications 다 명시해야 합니다. '그럴 시간에 그냥 개발하겠다' 하시겠지요. 그렇지만 이 문서화 작업은 초보 개발자에게 일 시키기 쉽다는 거 이외에도 그 시스템의 자세한 도면도를 남겨둔다는 의미로 보면 나중에 시스템 유지할 때 정말 필요합니다. 그러므로 tech spec 하는 데에 개발 시간 만큼 든다고 해도 그럴 가치가 있지요. 이직률이 높은 IT 업계에서는 특히 더 그렇죠. 그 시스템 개발에 참여했던 사람이 1년, 2년 후에도 남아 있을 거란 보장이 없잖아요.
RA 사인 받고, 아키텍트가 tech spec 하는 동안 프로젝트 매니저 팀에서는 시간 계산에 들어갑니다. 저희 회사에서는 인력 한 시간에 8만원 청구하거든요. 그렇게 생각하면 개발자들 열 명이 한 시간 놀면 80만원입니다. 남아공 물가 쌉니다. 80만원이면 웬만한 초보 개발자 한 달 월급입니다. 그리고 하루 개발 시간은 평균 6.5 시간으로 계산합니다. 근무 시간은 여덟시간 이지만 한 가지 일만 계속 하는 거 아니고, 여러 가지 일 하다 보면 또 다시 집중하고 그래야 하니까 효과적인 개발 시간은 6.5 시간입니다. 이거 잘못해서 프로젝트 늦어지면 이건 프로젝트 매니저팀 잘못입니다. 기술적인 문제로 늦어진다면 RA 처음 문서작업 했던 헤드 아키텍트 잘못이고요.
저번 프로젝트가 이런 저런 문제로 열흘 정도 늦어졌습니다. 개발자 둘, 주말에 근무해야 했습니다. 토요일과 일요일에 출근해서 네 시간 이상 일하면 연차로 지급받습니다. 입사 첫해에 연차가 15일이니까 주말에 5일 일했다면 연차 그 해에 20일 되네요. 인력 은근히 비싸다고요? 네, 비쌉니다. 그런 거 없이 어차피 인건비 싸니까 막 시키고 돈 좀 더 주면 되지 않느냐고요? 네, 그런 회사도 있습니다. 그런데 그렇게 해서 오래 못 가거든요. 개발일, 머리 쓰는 일입니다. 기분 거지같고 착취당하는 것 같고 하면 제대로 할 일도 대충대충 하고 넘어가고, 그렇게 넘어간 일은 두고두고 문제됩니다. 그리고 매니저가 시간 계산 잘못 한 거, 아키텍트가 시스템 견적 잘못 뽑은 거 아랫 사람한테 책임 넘기면 직무유기입니다. 아랫 사람들이 오래 일해서 해결되는 게 아니죠.
자, RA 에서 우리가 하겠다는 일은 다 끝냈습니다. 그 쪽에서 아무리 이거 해달라 어째달라 해도 생깔 때입니다. 니네가 사인한 거 해 줬다는 거 확실히 하고, 그 다음부터 바꿔달라는 거 바꿔줍니다. 시간당 8만원으로요. 그것 역시 그 쪽에서 바꿔달라는 거 잘 듣고, 문서화 해서 사인 받고, 그 다음에 작업 시작합니다. 문서화해 놓지 않으면 나중에 그 쪽에서 아, 우리가 원한 건 이런 거 아니었다 이딴 헛소리 하면 결국 일 해준 사람이 손해거든요.
한국에서 정말 열심히 일하신다는 분들 얘기 들어보면 그래서 한국 경제가 발전했을까 하는 생각 합니다. 남아공, 아프리카 국가죠. 아직 갈 길 엄청 멀었죠. 한국에 비해 무지하게 후진국이고 사실 비교하기조차 쪽팔리지요. 땅 파 먹고 사는게 전부인데요 뭘. 그렇지만 조금 속도를 늦추더라도, 일하는 사람들이 좀 더 행복하면 그것도 괜찮지 않을까요. 마음 편한 개발자들이 좋은 시스템을 개발할 것 같은데요. IT 강국 코리아라고 하는데 사실 세계 기업에서 사용하는 그런 시스템은 별로 없지 않나요. 영어 공부고 뭐고 일에 치인 개발자분들에게 세계화, 글로벌화 강요하는 것도 의미가 없고, 그렇게 힘들게 일하시는 분들에게 세계적으로 경쟁력 있는 수퍼 시스템 만들어 내라는 요구도 좀. (그래도 한국 IT 분들 근무 조건 이야기를 들은 저희 회사 사장은 눈 번득이면서 '당장 수입하자'고 하더라만은 -_-; '노동법 드러워서 장사 못하겠다'란 말씀도. 세계 어디가나 비즈니스 하시는 분들은 비슷한 건가요.)
써야지 써야지 하고 있던 글인데 위의 글 읽고 씁니다.
저는 남아공 요하네스버그에서 개발쪽 일 시작해서 지금은 QA 로 옮겨갔지만 가끔 제가 일하던 프로젝트 유지 보수해야 하면 개발일도 가끔 합니다. 주 언어는 perl, 웹 프로그래밍+ SyBase 입니다. 직원은 서른 명이고 인사/세일즈 담당은 그 중 다섯 명입니다. 나머지는 다 기술직입니다.
우선 프로젝트를 하기로 결정하면 저희 쪽에서 (견적이라고 하나요? quote) 를 뽑습니다. 거기에 문서화 작업이 포함됩니다. 만약 회사 A 가 저희 회사에게 프로젝트를 맡기고 싶다면 먼저 한화로 500-1000 만원 정도의 문서화 비용을 내야 합니다. 그러면 저희 회사에서는 프로젝트 규모에 따라 최소한 2주, 길게는 6주 정도 Requirement Analysis (요구분석?) 을 합니다. 그리고 저희가 개발해야 할 프로그램을 와이어프레임까지 (만들 스크린 설계) 포함해서 제출합니다. 가장 최근에 했던 프로젝트는 다섯명의 개발자가 네 달 동안 일해야 하는 양이었으므로 RA 역시 300 페이지 정도 되었던 걸로 기억합니다.
RA 의 중요성은 절대적입니다. 우선 어떤 시스템을 만들 것인지 세부사항까지 정리해야 정확한 견적이 나올 수 있고, 사인하는 사람 입장에서도 미리미리 체크를 할 수 있지요. 시스템 만들 사람들이 제대로 이해 했는지 아닌지 확인하는 것도 그 쪽 책임이 되고요. 법적으로 이 문서가 제일 중요합니다. 그 문서 안에 있는 항목은 다 만들어 준다는 조건으로 이만큼 돈을 요구합니다, 그런 거니까 나중에 개발 다 되었는데 이거 바꿔주세요, 이거 당신네들이 잘못 이해했어요 이렇게 헛소리 하는 거 미리 차단할 수 있습니다.
RA 사인 받으면 그 때부터 또 문서화 작업 들어갑니다. RA 를 바탕으로 technical specification 을 헤드 아키텍트와 그 밑의 고급 개발자들이 만들어 아래 개발자들에게 넘깁니다. 아래 개발자들은 그 문서만 보고도 별 문제 없이 작업할 수 있어야 합니다. 그냥 문서화 없이 무작정 시키면 처음엔 편하지만 결국은 시니어들이 개고생한다는 걸 겪었기 때문에 object 하나, method 하나까지 다 적고 데이터베이스 설계도 만들고, 데이터 타입과 status 다이어그램까지 다 만들어 넘깁니다. 예를 들어 유저란 object (객체?) 인터페이스를 만들어야 한다면 유저 properties, methods, status diagrams, store procedure structures, screen layouts, database specifications 다 명시해야 합니다. '그럴 시간에 그냥 개발하겠다' 하시겠지요. 그렇지만 이 문서화 작업은 초보 개발자에게 일 시키기 쉽다는 거 이외에도 그 시스템의 자세한 도면도를 남겨둔다는 의미로 보면 나중에 시스템 유지할 때 정말 필요합니다. 그러므로 tech spec 하는 데에 개발 시간 만큼 든다고 해도 그럴 가치가 있지요. 이직률이 높은 IT 업계에서는 특히 더 그렇죠. 그 시스템 개발에 참여했던 사람이 1년, 2년 후에도 남아 있을 거란 보장이 없잖아요.
RA 사인 받고, 아키텍트가 tech spec 하는 동안 프로젝트 매니저 팀에서는 시간 계산에 들어갑니다. 저희 회사에서는 인력 한 시간에 8만원 청구하거든요. 그렇게 생각하면 개발자들 열 명이 한 시간 놀면 80만원입니다. 남아공 물가 쌉니다. 80만원이면 웬만한 초보 개발자 한 달 월급입니다. 그리고 하루 개발 시간은 평균 6.5 시간으로 계산합니다. 근무 시간은 여덟시간 이지만 한 가지 일만 계속 하는 거 아니고, 여러 가지 일 하다 보면 또 다시 집중하고 그래야 하니까 효과적인 개발 시간은 6.5 시간입니다. 이거 잘못해서 프로젝트 늦어지면 이건 프로젝트 매니저팀 잘못입니다. 기술적인 문제로 늦어진다면 RA 처음 문서작업 했던 헤드 아키텍트 잘못이고요.
저번 프로젝트가 이런 저런 문제로 열흘 정도 늦어졌습니다. 개발자 둘, 주말에 근무해야 했습니다. 토요일과 일요일에 출근해서 네 시간 이상 일하면 연차로 지급받습니다. 입사 첫해에 연차가 15일이니까 주말에 5일 일했다면 연차 그 해에 20일 되네요. 인력 은근히 비싸다고요? 네, 비쌉니다. 그런 거 없이 어차피 인건비 싸니까 막 시키고 돈 좀 더 주면 되지 않느냐고요? 네, 그런 회사도 있습니다. 그런데 그렇게 해서 오래 못 가거든요. 개발일, 머리 쓰는 일입니다. 기분 거지같고 착취당하는 것 같고 하면 제대로 할 일도 대충대충 하고 넘어가고, 그렇게 넘어간 일은 두고두고 문제됩니다. 그리고 매니저가 시간 계산 잘못 한 거, 아키텍트가 시스템 견적 잘못 뽑은 거 아랫 사람한테 책임 넘기면 직무유기입니다. 아랫 사람들이 오래 일해서 해결되는 게 아니죠.
자, RA 에서 우리가 하겠다는 일은 다 끝냈습니다. 그 쪽에서 아무리 이거 해달라 어째달라 해도 생깔 때입니다. 니네가 사인한 거 해 줬다는 거 확실히 하고, 그 다음부터 바꿔달라는 거 바꿔줍니다. 시간당 8만원으로요. 그것 역시 그 쪽에서 바꿔달라는 거 잘 듣고, 문서화 해서 사인 받고, 그 다음에 작업 시작합니다. 문서화해 놓지 않으면 나중에 그 쪽에서 아, 우리가 원한 건 이런 거 아니었다 이딴 헛소리 하면 결국 일 해준 사람이 손해거든요.
한국에서 정말 열심히 일하신다는 분들 얘기 들어보면 그래서 한국 경제가 발전했을까 하는 생각 합니다. 남아공, 아프리카 국가죠. 아직 갈 길 엄청 멀었죠. 한국에 비해 무지하게 후진국이고 사실 비교하기조차 쪽팔리지요. 땅 파 먹고 사는게 전부인데요 뭘. 그렇지만 조금 속도를 늦추더라도, 일하는 사람들이 좀 더 행복하면 그것도 괜찮지 않을까요. 마음 편한 개발자들이 좋은 시스템을 개발할 것 같은데요. IT 강국 코리아라고 하는데 사실 세계 기업에서 사용하는 그런 시스템은 별로 없지 않나요. 영어 공부고 뭐고 일에 치인 개발자분들에게 세계화, 글로벌화 강요하는 것도 의미가 없고, 그렇게 힘들게 일하시는 분들에게 세계적으로 경쟁력 있는 수퍼 시스템 만들어 내라는 요구도 좀. (그래도 한국 IT 분들 근무 조건 이야기를 들은 저희 회사 사장은 눈 번득이면서 '당장 수입하자'고 하더라만은 -_-; '노동법 드러워서 장사 못하겠다'란 말씀도. 세계 어디가나 비즈니스 하시는 분들은 비슷한 건가요.)
# by | 2007/06/12 20:43 | work - IT | 트랙백 | 핑백(2) | 덧글(13)




☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
... 오랜 인연인 아이린(군인남) 을 초대했습니다. 거친 환영 부탁 드립니다. 오후 12시 34분'이런 거 싫어하는 남자도 있나요?' - 연결하시겠습니까? 오후 3시 17분아프리카 IT의 현실과 IT 코리아. 오후 4시 32분열심히 달리다가 4시 30분부터 갑작스레 의욕 상실. 하루에 쓸 수 있는 집중력을 다 쓴 건가? 오후 5시 21분야후 코리아가 플리커 ... more
... 로 없을까? 프로그래머 서열 프로그래머 콤플렉스 PHP / 펄 프로그래머에 대한 편견 IT + 생활패턴 리눅스 vs 윈도우 아프리카의 IT 업무결혼생활 이야기 모음입니다 - 양파는 국제결혼했습니다부부만담 - 치타는 바람둥이 왜 결혼했어? 외국 남자와 살기, 장점 vs 단점. 행복한 결혼생활의 비결 ... more
저게 어느정도는 익숙하군요...
예. 한국에 외국계 기업이었습니다. 뭐 거기도 만만 찮긴하지만. 어느정도로 위의 프로세스를 따라 갔더랩니다.
본문과 덧글 둘 다 잘 읽었습니다. ^^
그래도 잘 마무리가 됐나봐요 하시는 얘기가 다 과거형인걸 보니. 축하. 좀 쉬셔야.
ziozzang+소마// =)
서영호// 헉! 그런 거였어요? 진짜 꼭 놀러가야겠네. (쥐어 패 줄 SyBase 사람들이 몇 있는데 -_-)
마르슬랭// 눈물나오.
스트롱베리// 오셈 (퍽!)
monaca// 생각해 봤는데요.
RA 에 있는 요구 사항을 다 끝냈는데도 입금 안 하면 불법이죠. 그렇지만 사회 전체에서 그게 '불법이다'란 인식이 없으면 처리하기 힘들지도. 그러니까 monaca 님 말이 맞는 거 같아요. 전체가 체계적으로 표준을 따라야.
산출물 관련된 문서작업만 했었고요. (경력 2년차, 경력이 짧아서 경험이 없을지도)
문서 작업에 문서만 봐도 짜증 ... 솔직히 다음에 보지도 않을 문서를 도대체 왜 만들고 시간을 들여야 하는 것인지 이해가 안되었거든요.
RA ... 저렇게 체계적으로 진행되는 상황이고, 책임 소재 및 범위가 명확하게 되는 것이라면, 필수일 것이고, 또한 즐겁게 문서 작업을, 한편으로 엄청난 책임감으로 중무장해서 문서를 만들 것 같습니다.