분석 썸네일형 리스트형 외주 SW 개발의 비극 열악한 소프트웨어 외주 개발 문제는 우리나라에서 소프트웨어가 3D 취급을 받는 주요한 원인 중 하나다. '갑을병'으로 이어지는 외주도 모자라 '갑을병정무'까지 3,4단계 외주를 주기도 한다. 하청에 재하청이 이어질수록 열악한 댓가와 무리한 일정 그리고 부정확한 요구사항은 외주 개발을 점점 구렁텅이로 내몰고 있다. 소프트웨어 외주 개발 문제를 얘기하면 할 말이 많은 사람들이 꽤 있을 것이다. 필자는 그 중에서 접해 본 사례를 중심으로 소프트웨어 공학과개발 문화적으로 문제점을 지적해보고자 한다. A사는 새로운 서비스를 시작하면서 서비스 개발을 야심차게 인도에 외주를 줬다가 큰 낭패를 봤다. 지금도 왜 인도에 외주를 줬는지 궁금하지만 추측컨데 실리콘밸리 외주 형태를 흉내를 낸 것이 아닌가 생각한다. 그런데 인.. 더보기 고객이 전문가 우리나라의 소프트웨어 환경의 문제점 중 하나가 고객이 잘 모른다는 것이다. 예를 들어 공공 SI 프로젝트의 경우 발주처인 공공기관의 담당자가 SI회사의 개발자들보다 업무를 잘 모르는 경우가 종종 있다. 공무원들은 몇년만다 한번씩 자리를 옮기기 때문에 자신의 업무를 빠삭하게 알지 못하고 SI회사에 많이 의지하게 된다. SI회사에서는 해당 분야의 업무만 오랫동안 개발해온 개발자들이 있어서 현업 담당자보다 더 잘 알곤 한다. 외국의 경우 몇십년씩 한자리에서 공무원이 최고의 전문가가 되는 경우와는 사뭇 다르다. 그래서 공공프로젝트를 진행할 때 SI회사가 많이 주도를 한다. 심지어는 발주처에서 해야 할 일도 다 SI회사가 해주곤 한다. 어떻게 보면 SI회사에 좋기도 하지만 문제도 많다. 요구사항 분석 때 충분한 .. 더보기 7명이 할 수 있는 일을 70명이 하고 있는 이유 최근에 한 글로벌 소프트웨어 회사(Y사, 가칭)의 한국 지사 관계자에게 들은 이야기이다.비단 Y사 얘기만은 아니다. 세계적인 소프트웨어 회사의 한국지사에서 종종 벌이지는 일이다. Y사의 본사에서는 처음에 한국지사를 만들었을 때 한국에서도 미국의 개발 프로세스를 따를 것을 종용했다고 한다. 하지만 한국에서 채용된 개발자들은 미국의 개발 프로세스는 너무 무겁다고 한국 방식으로 개발했다고 주장을 했다. 그리고는 미국의 개발 주문에 대해서 믿을 수 없는 속도로 해결을 해나가기 시작했고, 미국 본사는 이런 경이로운 결과를 보고는 한국식 개발을 묵인할 수 밖에 없었다. 그뒤 몇 년이 지난 지금은 어떻게 되었을까? 미국 본사의 개발 프로세스를 착실히 따른 호주 지사와 엄청난 차이를 보이고 있다고 한다. 똑같은 일을 .. 더보기 개발자의 취향 소프트웨어 프로젝트를 진행할 때 합리적인 결정보다는 개발자의 취향대로 진행되는 경우가 많다. 이 경우 Architecture상의 심각한 문제점을 내포하게 된다. 제대로된 분석과 설계를 통해서 Architecture가 결정되어야 하는데 개발자 취향에 맞는 개발언어를 선택하고 검증이 안된 기술을 선택하면 그 Risk는 고스란히 프로젝트가 떠안아야 한다. Architecture를 결정할 때 고려해야 하는 요소는 개발자의 취향이 아니다. 회사의 미래 비즈니스 전략을 고려해야 하고, 현재 개발자들의 구성과 역량, 제품의 성격과 로드맵이 중요한 고려사항이다. 이러한 전략없이 특정기술을 맹신하거나 거부하기도 하고 무조건 새로운 기술을 채용하기도 한다.그러다보면 각 제품마다 중구난방으로 여러 기술이 쓰이고, 유지보수에.. 더보기 한 SI회사의 프로세스에 대한 오해 필자는 업계의 여러 사람과 얘기할 기회가 많다. 최근에 한 대형 SI회사의 한 PM과 얘기를 한 적이 있는데 프로세스 상의 큰 문제가 있었고, 실제 프로젝트팀에서는 잘못된 프로세스로 인해서 어려움을 겪고 있었다. SI회사의 오랜 바람 중의 하나가 "공정분리"이다. 즉, 분석/설계/구현을 분리해서 프로젝트를 진행하는 것이다."공정분리"가 되지 않은 상태에서는 분석/설계/구현이 뒤엉켜서 개발을 진행한다. "공정분리"는 분석을 잘해서 설계자에게 넘겨주면, 설계자는 설계를 잘해서 개발자에게 넘겨주고 개발자들은 설계서 그대로 코딩만 하면 되도록 하려는 것이다. 최근 해외 프로젝트가 증가하면서 분석/설계/구현을 뒤엉켜서 진행할 경우 코딩하는 개발자까지 해외 파견을 해야 한다. 그래서 공정분리는 점점 필수가 되었다... 더보기 SRS에 대한 인식의 변화 그 동안 본 블로그를 통해서 소프트웨어 개발에서 SRS(Software Requirements Specification)가 얼마나 중요한 역할을 하는지에 대해서 수 차례 역설한 적이 있습니다. 2009/08/03 - [프로젝트/요구사항분석] - 이건 기능이 아닌데 2009/07/30 - [프로젝트/요구사항분석] - 고객이 요구사항을 너무 자주 바꿔요. 2009/05/04 - [프로젝트/요구사항분석] - Track me, if you can 2009/04/22 - [프로젝트/요구사항분석] - 개발자들이 바글바글한 외딴섬에 떨어진다면 2009/02/12 - [프로젝트/요구사항분석] - 요구사항 분석의 출발점 2009/02/04 - [개발프로세스] - 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은? .. 더보기 이건 기능이 아닌데 의례 스펙, 기능요구사항 등을 정리한 문서를 보면 기능만 잔뜩 나열되어 있는 것은 매우 흔한 일입니다. 소프트웨어를 만든다고 하면 구현해야 할 기능만 알면 제대로 잘 만들 수 있을 것으로 생각하기 십상입니다. 상식적으로 생각해도 기능면 제대로 구현하면 되겠지요. 여기에 UI는 살짝 추가하고요. 하지만, 분석을 할 때 기능보다 더 중요한 것이 비기능 요구사항입니다. 즉, 기능은 아닌데, 요구사항 즉, 스펙인 겁니다. 기능이 중요하기는 하지만, 기능 하나가 잘못되면 이를 고치는 것은 그렇게 어렵지 않습니다. 그런데 비기능에서 잘못되면 소프트웨어를 완전히 뒤엎어야 하는 일이 발생할 수도 있습니다. 이렇듯 비기능이 기능보다도 더 중요한 측면이 있는데, 눈에 바로 보이지 않는 다는 이유로 간과되기 쉽습니다. 그럼.. 더보기 고객이 요구사항을 너무 자주 바꿔요. 우리나라 소프트웨어 시장을 너무 비관적으로 과대평가하는 경우를 종종 봅니다. 예를 들면 전세계 유래가 없는 까다로운 고객 요구 수준, 시도 때도 없이 바뀌는 요구사항, 엄청나게 낮은 금액, 제품의 Output과는 상관없이 작업 시간을 통제하는 관행 일부는 공감을 하기도 하지만, 어느 나라를 가던지 각 나라만의 특징이 있다는 측면으로 바라보고 싶습니다. 우리나라 고객은 요구사항을 정말로 외국에 비해서 더 자주 바꾸는 것인지는 생각해 볼 필요가 있습니다. 어딜 가던지 고객은 요구사항을 항상 바꾸기 마련이고, 그것이 고객의 습성이라고 볼 수 있습니다. 그런데, 외국에서는 관행적으로 문화적으로 스펙을 근거로 계약을 하고, 분석 능력이 뛰어난 엔지니어들도 많이 있습니다. 하지만 그런 저변이 상대적으로 부족한 우리.. 더보기 과거의 개발자 vs. 미래의 개발자 개발자는 2가지의 상반된 가치를 가지고 있습니다. 하나는 과거의 가치 또 하나는 미래의 가치입니다. "이 사람들 나가면 과거에 개발해 놓은 것 어떡하지?"라는 생각이 들면 과거의 가치를 가진 개발자이고 "이 사람들 나가면 미래에 개발은 누가 하지?"라는 생각이 들면 미래의 가치를 가진 개발자입니다. 과거의 가치를 가진 개발자들은 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식은 머리 속에 있기 때문에 자신이 과거에 만들어 놓은 소프트웨어를 인질 삼아서 회사와 인질극을 벌이고 있는 것과 같습니다. 이렇게 된 원인이 상당부분 회사에 있다고 하더라도, 개발자의 가치는 인질범과 별반 다를 바가 없습니다. 기존 소프트웨어를 망칠까봐 대우해줄 수 밖에 없습니다. 미래의 가치를 가진 개발자.. 더보기 개발자들이 바글바글한 외딴섬에 떨어진다면 개발자들이 바글바글한 외딴섬에 떨어졌는데 서로 뒤죽박죽으로 개발을 하고 있고,이들을 3개월 안에 훈련시켜서 정예 개발자로 만들어 한다는 미션이 떨어졌다면 무엇을 하시겠습니까? Language 기초를 다시 가르칠까요? UML을 가르칠까요? 문서 작성법을 훈련 시킬까요? 개발방법론을 가르칠까요? 팀워크를 키워줄까요? OOP를 가르칠까요? 어떻게 하시겠습니까? 나는 스펙을 작성하는 방법을 가르치고 3개월간 훈련을 시킬 겁니다. 즉 Requirement engineering을 익히게 하겠다는 뜻입니다. 그만큼 스펙은 현재 소프트웨어 개발현장에서 가장 많은 실패의 원인이 되고 있고, 배우기도 가장 어려운 분야입니다. 나는 수많은 개발자들이 작성한 스펙문서(다양한 이름의 문서)를 봐 왔지만, Requirement .. 더보기 이전 1 다음
