- 뭘 좀 잘못해도 쉽게 눈에 안띄고,
- 문제가 되어도 딱히 누가 잘못한지도 잘 모르겠고,
- 맘 먹고 동료들이나 경영자를 속이고 있어도 쉽게 알아차리기 힘들고,
- 자신의 실력보다 과대포장을 해도 눈치채기 어렵습니다.
- 또 하루종일 일을 하고 있어도 정말 열심히 하는 것인지 노는 것인지 알아내기 어렵고,
이러한 소프트웨어 개발자들이 빌딩을 만들거나 비행기를 만든다면 빌딩이 무너지거나 비행기가 추락하겠죠. 하지만 소프트웨어 필드에서는 그러한 오류가 종종 숨겨지고, 원인을 밝히기 어려운 경우가 태반입니다.
결국 소프트웨어 개발자들은 스스로의 발전을 위해서도 윤리의식을 가지고 있어야 합니다. 이러한 자세는 개발자 스스로에게도 도움이 된다는 것을 강조하고 싶습니다.
이렇게 개발자들이 지켜야할 윤리의식에 대한 저의 생각을 나열해봤습니다.
|
이 외에도 개발자들이 지켜야 할 윤리의식에 대한 의견 있으신 분들은 댓글 남겨 주세요.
공감합니다.
답글삭제관리자 입장에서 개발자에게 '다됐냐?'하고 물어보면 "거의 다 됐어요"라는 대답을 듣는 경우가 많습니다. 문제는 "다 됐어요"가 "됐어요"로 바뀌는데 한달이 걸리기도하고, 두달이 걸리기도 한다는 점이 문제이지요. 그래서 이런 항목도 추가하면 좋겠습니다.
- 내가 맡은 업무의 진척상황을 정확하고 객관적으로 보고/공유한다.
절대 공감입니다...
답글삭제저도 헝그리맨님 댓글처럼 "나의 일을 자주 홍보하라"는 항목을 추가하고 싶네요...
그나마 개발자였던 관리자라면 다행이지만 그렇지 않은 경우에는 더 심하거든요. 관리자가 부하사원이 도대체 뭫 하고 있는지 파악이 안되죠... 설명을 해도 안되는 경우가 있으니 더욱 홍보한다는 생각으로 내가 하는 일을 지속적으로 알려야 한다고 생각합니다.
문서화야 말로 관건이라고 생각합니다.
답글삭제일부는 공감이 가나, 몇몇 팀에서의 시스템 차원으로 해결되어야 할 문제들이 개인의 윤리 영역으로 가야 하는지는 잘 모르겠습니다.
답글삭제* Peer Review 의 경우, 개인 단위 시간을 쪼개서 하기 보다는, 소스 커밋 전/후의 팀 프로세스로 두는 것을 더 자주 보곤 합니다. 아에 짝 프로그래밍을 하던지요.
* 지식의 공유에 대하여 - 공유하기 쉬운 시스템이나 공유를 장려할 시스템. 예전에 블로그나 커뮤니티 기획하시는 분들 보면 '정보 생산자들이 정보를 생산하기 용이하게끔 할 끌개'와 '소비자로서 정보 생산자들에게 이익을 줄 방법' 에 대해 고민합니다. KMS 까진 아니더라도 팀 위키나, 개발 로그 작성 등의 방법 등이 있습니다.
* 유지보수를 생각하는 개발 - 이건 철학의 차이가 있을 듯 하고 같은 용어 대비 사람들의 행동들은 다 다를 것 같습니다. 하지만 역시 리뷰나 유닛 테스트 작성, 품질 매트릭(static analysis tool 도입이라던지..) 등의 구체적인 Practice 도입이 없으면 그냥 '외침'일 뿐이라 생각합니다.
개인적으로 굳이 '윤리' 를 두겠다면.. 몇몇개는 시스템으로 해결하고 '드러난 문제점에 대해서 팀 멤버들과 침묵의 담합을 하지 않고 맞서겠다' 는 어떨까 하는 생각도 하지만.. 이 또한 '윤리문제' 이기 보다는 '용기'의 문제이고 다시 또 '사람들이 용기를 낼 수 없는 시스템'의 문제일지도 모릅니다.
헝그리맨님 안녕하세요.
답글삭제99%에서 1%더 직척하는데 오래 걸린다는 얘기가 있죠. 항상 거의 다 되었다는 말은 흔한 얘기죠.
개발일정 관리를 개발자에게 전적으로 맡기는 것는 문제입니다. 일정 예측도 중요하고 세분화된 일정으로 관리를 해야죠. 말씀해주신 진척상황공유도 개발자들이 꼭 해야 하는 일 중 하나같습니다. 나중에 개발 일정관리 기법에 대해서도 글을 써볼 예정입니다.
[1002]님 안녕하세요.
답글삭제좋은 의견 감사합니다. 제가 앞서 작성한 글들도 읽으시면 좋겠네요. 말씀하시고 계시는 기반시스템은 소프트웨어를 개발하는데 있어서는 필수적으로 꼭 필요한 것들입니다. 그런 것들이 없이 소프트웨어를 개발하고 있다는 것은 기적입니다. 이 블로그의 많은 글들은 그러한 시스템을 사용하는 것에 관한 것들입니다.
그럼에도 불구하고 개발자들의 자세는 매우 중요하다는 것을 글에서 말하고 있는 것입니다. 즉 시스템은 두번째 문제이고 개발자들의 의식이 먼저 필요하다는 것을 강조하고 있는 글입니다.
김성동님 안녕하세요.
답글삭제저도 동감입니다. 특히 경력이 많은 개발자일수록 그런 소양이 부족해서는 안되겠지요.
hoya님 안녕하세요.
답글삭제요구공학에 관심이 많으신 분을 만나서 반갑습니다.
* 기반시스템으로 소개하신 글들은 다 읽었습니다.
답글삭제* 아마 제가 '윤리 - xxx 로서 마땅히 지켜야 할 도리'라는 단어에 민감함과 거부감이 아주아주 커서 그런가 봅니다. 실제로 저 항목들 중 일부는 실제로 의미가 있으려면 형용사들('적당한', '잘된' 혹은 '올바른', '아주 잘된'. 하지만 사람들마다 관점은 다 다른..) 이 붙어야 하기도 하고요.
* 제가 그 특수성을 띄고 있는 '개발자'라 보니 저런 상황과 주관에 따라 안지켜지기 쉬운 일에 대해 '윤리적 비난'을 받기도, 다른 개발자들을 비난하기도 싫습니다. ;) 약한 혹은 강한 강제성을 언급하고 싶다면 '팀 차원의 시스템' 이 언급되면 된다고 생각하다보니 좀 어울리지 않은 댓글이 달렸습니다.
[1002]님 안녕하세요.
답글삭제부언하면 제가 윤리라고 말하고 있는 이유는 이를 지키지 않았다고 비난하기 어렵기 때문이기도 합니다. 대부분은 알아차리기도 어렵고 스스로 그러한 마인드를 가져야 하는 것이지, 누가 이런 것을 가지고 비난할 수 있는 내용도 아니라고 생각합니다. 또 강제화하기도 어렵고 그래서는 효과도 없구요. 그래서 "윤리"라고 생각합니다.
글 잘 읽었습니다. Peer Review는 실리콘벨리에서도 많은 엔지니어들이 정말로 귀찮아 하는 부분이죠. 뭐 작은거 하나 고쳐도 집어넣으려면 리뷰받고 리뷰한 사람 써 넣어야 putback 할수 있게끔 빌드를 하니 많이들 귀찮아하죠. 그래도 반항 않하고 다들 따라주더군요.
답글삭제한국이나 미국이나 엔지니어들이 짧은 스케줄 잡는건 다 똑같네요. 하다 보면 일이 많아지니... 그래서 feature을 세분화하는 문서 작성이 필요한것 같아요. 그런데 개발 경험이나 그 비슷한 경험이 전혀 없는 관리자가 개발 스케줄을 관리하는것도 좀 문제가 있겠네요 :)
다 맞는 말씀 하셨어요 :).
Hi, Soo. How are you.
답글삭제전세계 소프트웨어 회사 어디나 시간이 없는 건 마찬가지 같아요. 한국의 소프트웨어 회사들은 실리콘벨리의 회사들보다 좀더 열악합니다. 이 블로그를 읽으시는 많은 분들은 이런 여러가지 소프트웨어 공학적인 개발을 꽤 많이 이해하고 실행하고 있지만, 그외의 대부분의 소프트웨어 회사들은 아직도 많이 주먹구구식으로 개발을 하고 있습니다. 갈길이 멉니다.
좋은 내용입니다. 근데 요즘처럼 개발자라는 직업이 천대받고 막장이라고 인식되는 시기에,
답글삭제개발자의 윤리보다는 개발자들이 가진 권리가 무엇무엇이 있을지 더 궁금합니다.
개발자의 권리장전을 작성해보는 것도 재미(?)있을 듯합니다.
권리장전 1항은 아마도 '우리도 남들 잘 때 잘 수 있다' ??? .... ^^;;
서영아빠님 안녕하세요.
답글삭제개발자의 권리도 재미있겠네요.
경영자의 의무, 고객의 의무에 대해서도 종종 생각해 보고 있는데, 이것도 정리를 하면 좋겠네요.