태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

외주 SW 개발의 비극

2014.03.16 23:18 by 전규현


잠시 후 Google blogger로 이동됩니다.





열악한 소프트웨어 외주 개발 문제는 우리나라에서 소프트웨어가 3D 취급을 받는 주요한 원인 중 하나다. 

 

'갑을병'으로 이어지는 외주도 모자라 '갑을병정무'까지 3,4단계 외주를 주기도 한다. 하청에 재하청이 이어질수록 열악한 댓가와 무리한 일정 그리고 부정확한 요구사항은 외주 개발을 점점 구렁텅이로 내몰고 있다.
소프트웨어 외주 개발 문제를 얘기하면 할 말이 많은 사람들이 꽤 있을 것이다. 필자는 그 중에서 접해 본 사례를 중심으로 소프트웨어 공학과개발 문화적으로 문제점을 지적해보고자 한다.

 

A사는 새로운 서비스를 시작하면서 서비스 개발을 야심차게 인도에 외주를 줬다가 큰 낭패를 봤다. 

 

지금도 왜 인도에 외주를 줬는지 궁금하지만 추측컨데 실리콘밸리 외주 형태를 흉내를 낸 것이 아닌가 생각한다. 그런데 인도 개발사는 개발 완료 후 L사에서 기대한 것과 전혀 다른 것을 전달해왔다. 프로토콜도 완전히 다른 것이고 도저히 서비스에 사용할 수 있는 상황이 아니었다. 

 

이런 일이 벌어진 가장 큰 이유는 스펙을 제대로 전달하지 않았기 때문이다. 인도 개발사에 전달된 스펙은 간단한 기획서 수준이었고 프로토콜도 제대로 언급하지 않았다. 게다가 인도 개발사가 소프트웨어를 완성해서 전달할 때까지 중간에 제대로 점검을 하지 않았다. 

 

한국 업체 같으면 억지를 부려서 잔금을 안주면서 다시 개발을 강요 했겠지만 인도 개발사는 계약대로 개발을 했고 억지는 통하지 않았다. 잔금을 안줄 수는 없었다. 결국 인도 개발사가 개발한 소프트웨어는 모두 버리고 다급하게 한국업체를 통해서 다시 개발을 했다. 돈은 돈대로 더 들고 서비스도 뒤죽박죽이 되었다. 

 

B사는 1년이 넘는 꽤 긴 프로젝트를 제대로 된 스펙도 없이 외주를 주고 고치기를 반복한다. 

 

외주 개발사에는 핵심 기능을 정리한 한 두 페이지 정도의 요구 사항 문서가 전달된다. 외주 개발사는 전체 프로젝트 기간 중 20~30% 정도 기간 안에 소프트웨어를 만들어 보여줘야 한다. 남은 70~80% 기간은 B사의 요구대로 거의 매일 소프트웨어를 수정하고 보여주기를 반복해야 한다.

 

외주 개발사는 해당 분야의 전문 회사라 이런 부정확한 요구사항으로도 대충 B사가 원하는 것을 이해해 개발할 수 있었다. 개발사의 PM은 수시로 고객사에 불려가 요구사항 변경 회의를 해야 했고 소프트웨어를 계속 고쳐나가기 때문에 아키텍처를 제대로 유지하기가 어려웠다. 

 

심지어 막판에 요구사항이 크게 바뀌어서 다 버리고 다시 만드는 일도 발생했다. 외주 개발사는 비용도 과도하게 투입해야 하고 프로젝트 관리를 제대로 하기도 어렵다. 하지만 B사가 가장 큰 고객이므로 시키는 대로 할 수 밖에 없었다. B사는 이런 식으로 프로젝트를 진행하는 것을 아직도 당연하게 생각한다.

 

C사와 D사는 소프트웨어 개발 외주가 제대로 진행이 안돼 외주사 개발자를 회사 내부에 앉혀 놓고 같이 개발하는 형태로 개발을 한다. 

 

외주 프로젝트지만 옆에서 같이 개발하지 않으면 제대로 개발이 안되기 때문에 같이 일해야 한다. 옆에 앉혀 놓고 개발한다 뿐이지 개발 방식은 다른 외주와 별반 다를 바가 없다. 요구사항은 계속 변하고 애써 작성한 코드를 버리고 고치기를 반복해야 한다. 

 

외주사도 이런 방식이 비효율적이라서 원하지 않지만 고객사의 우월한 지위를 꺽을 수가 없고 이렇게 일하다 보니 외주 개발 내용 외에 그냥 직원처럼 부림을 당하는 경우가 많이 발생한다. 

 

D사는 외주를 줬다가 소스코드가 없어져서 소프트웨어를 버려야 했다. 

 

D사는 소스코드를 받을 수 없는 외주 계약으로 개발을 했다. 처음 몇 년은 유지보수를 잘 했지만 몇 년 후 외주 개발사는 망해서 없어졌다. 그 과정에서 소스코드가 D사로 제대로 전달되지 않아서 최신 소스코드를 찾을 수 없는 상황이 되었다. 결국 외주 개발한 소프트웨어는 모두 버리고 다시 개발해야 하는 상황이 되었다.

 

E사는 개발자가 해야 할 개발자 테스트를 외주업체에 맡긴다.

 

개발자는 열심히 코딩만 하고 옆에 앉아서 외주개발자가 기본적인 개발자 테스트를 해준다. 속된 말로 '따까리'라는 말이 적합하다. 비싼 자사 개발자가 너무 바쁘기 때문에 그렇게 한다고는 하지만 자칫하면 잘못된 개발 습관이 쌓일 수 있다. 

 

또한 이렇게 해서는 코드 품질을 보장하기 어렵다. 완벽한 로직의 코드인지는 개발자 본인이 가장 잘 확인 할 수 있는데 대충 만들고 발견된 문제만 해결하는 방식이 습관화 될 수도 있다. 개발자는 완벽한 소스코드를 적는데 최선을 다해야 하는데 이런 개발자의 의무를 망각하면 프로그래밍은 기초부터 흔들리게 된다. 

 

위에서 살펴 볼 수 있듯 외주 문제의 주된 원인은 부실한 스펙이다. 모호한 요구사항 정도로 계약을 하게 되니 중간에 요구사항이 계속 바뀌어도 어쩔 수 없고 프로젝트 종료 기준도 모호하여 담당자 맘에 안들면 잔금을 받기도 어렵다. 소송도 종종 일어나지만 시간도 오래 걸리고 소송을 해도 해결하기 쉽지 않다. 고객이 대기업인 경우 소송을 하기도 쉽지 않다. 스펙을 제대로 적는 것은 소프트웨어를 개발하는데 있어서 가장 어려운 일이기 때문에 한마디로 설명할 수는 없다. 

 

소프트웨어를 직접 개발하지 않고 외주 개발을 하는 주된 이유는 다음과 같다. 직접 개발할 수는 있는데 내부 인력이 부족할 때와 특정 요소기술을 내부에서 보유하고 있지 않을 경우다. 내부에서 개발할 수 없을 만큼 잘 모를 때는 외주를 주기도 어렵다. 모르는 상태에서 대충 외주를 주면 원하는 결과를 얻기도 어렵고 분쟁이 일어나기 쉽다. 

 

기술력이 뛰어나거나 전문 기술을 가지고 있는 외주 개발사와 협업을 잘하는 것은 소프트웨어 생태계를 만드는데 아주 중요하다. 제대로 외주를 주기 위해서는 고객도 스펙을 제대로 적을 수 있을 만큼 잘 알아야 한다. 

 

부품 업체 다 망하고 나면 자동차 회사도 망하듯이 수많은 전문 소프트웨어 회사들이 망하고 나면 우리나라 소프트웨어 업계도 망하는 것이당연한 수순이다. 대만이 자전거 산업에서 세계를 호령하는 이유는 자전거 부품회사와 꾸준히 상생을 해와서 대만에는 뛰어난 자전거 부품회사가 많기 때문이다. 그에 비해서 생산비 절감에만 몰두한 우리나라 자전거 산업은 전세계 자전거 산업에서 명함도 못 내밀고 있다. 이미 많은 중소 소프트웨어 회사들이 사라졌거나 고사 상태인 지금 자전거 산업과 비슷한 미래가 예상되는 것은 안타까운 일이 아닐 수 없다. 

 

이제 와서 말로만 베풀듯이 상생이라고 외치는 것은 들을 때마다 거북하고 막상 그 내용도 해결책의 핵심은 아니다. 우리나라에서 소프트웨어 개발이 3D라는 인식에서 벗어나라면 이런 열악한 외주 환경이 바뀌지 않으면 안된다. 


이글은 ZDNet Korea에 기고한 칼럼입니다.


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

전규현 소프트웨어이야기 분석, 외주

고객이 전문가

2012.09.10 06:00 by 전규현


잠시 후 Google blogger로 이동됩니다.





우리나라의 소프트웨어 환경의 문제점 중 하나가 고객이 잘 모른다는 것이다.


예를 들어 공공 SI 프로젝트의 경우 발주처인 공공기관의 담당자가 SI회사의 개발자들보다 업무를 잘 모르는 경우가 종종 있다. 공무원들은 몇년만다 한번씩 자리를 옮기기 때문에 자신의 업무를 빠삭하게 알지 못하고 SI회사에 많이 의지하게 된다. SI회사에서는 해당 분야의 업무만 오랫동안 개발해온 개발자들이 있어서 현업 담당자보다 더 잘 알곤 한다. 외국의 경우 몇십년씩 한자리에서 공무원이 최고의 전문가가 되는 경우와는 사뭇 다르다.


그래서 공공프로젝트를 진행할 때 SI회사가 많이 주도를 한다. 심지어는 발주처에서 해야 할 일도 다 SI회사가 해주곤 한다. 어떻게 보면 SI회사에 좋기도 하지만 문제도 많다. 요구사항 분석 때 충분한 정보를 주지 않아 나중에 요구사항이 많이 바뀌기가 일쑤이고 그로 인해서 프로젝트에서 손해도 많이 난다.


비단 공공분야만이 아니다. 소프트웨어 선진국에서는 기업이 소프트웨어 외주를 줄 때 해당 기업에서 충분히 분석, 설계 역량이 있고 스펙을 제대로 작성해서 외주를 주곤한다. 즉, 직접 개발할 역량도 충분히 있는데 비용이나 시간 상 외주를 주는 것이다.


그런데 우리나라에서 외주를 주는 형태를 보면 고객이 잘 모르기 때문에 대충 외주를 주고 개발 업체가 이거저거 정말 알아서 다 해줘야 할 때가 많다. 그러다 보니 계약도 불분명하고 다툼도 많다. 법정까지 가는 다툼도 많이 발생하지만 엉성한 계약서를 가지고 누구의 자잘못인지 따지기도 어렵다.


개발업체에서 스펙을 제대로 작성하기 위해서 고객 인터뷰를 하고 요구사항 분석을 해도 협조가 잘 되지 않는다. 정확한 인터뷰 대상 선정도 쉽지 않다. 업체에서 나름대로 최대한 노력해서 스펙을 작성해도 고객이 스펙을 충분히 검토해서 확인을 해주는 일도 드물다. 


일단 고객이 스펙을 충분히 잘 검토할 수 있는 실력이 부족한 경우가 많다. 그래서 스펙을 봐도 잘 모르기 때문에 잘 보지 않으려고 한다. 또, 개발해 놓으면 언제든지 바꿔달라고 하면 되는 것으로 착각을 해서 개발 전에 스펙을 잘 보지 않아도 된다고 생각한다. 심지어는 스펙을 잘 검토해서 확인을 해주면 나중에 바꿔달라고 못할지도 모른다는 생각도 한다.


이런 비전문가적인 고객들은 개발업체를 엄청 괴롭히지만 프로젝트에도 긍정적이지 않다. 이런 환경에서 좋은 아키텍처의 소프트웨어가 나오기 어렵다. 개발업체도 제대로 개발하고 싶겠지만 그냥 어떻게 검수만 나도 된다는 식으로 개발하기 쉽다. 서로에게 모두 손해가 되는 것이다.


외주, 즉 아웃소싱이 제대로 되려면 고객이 전문가가 되어야 하는 것이다.


image by net_efekt


* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.

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

전규현 소프트웨어이야기 분석, 아웃소싱, 외주

  1. 원인모를 힘듬에 명확한 원인을 깨닫고 갑니다.
    고객을 선택할 기회가 생긴다면, 반드시 참고하고픈 내용입니다 ^^

7명이 할 수 있는 일을 70명이 하고 있는 이유

2012.08.15 23:10 by 전규현


잠시 후 Google blogger로 이동됩니다.





최근에 한 글로벌 소프트웨어 회사(Y사, 가칭)의 한국 지사 관계자에게 들은 이야기이다.

비단 Y사 얘기만은 아니다. 세계적인 소프트웨어 회사의 한국지사에서 종종 벌이지는 일이다.


Y사의 본사에서는 처음에 한국지사를 만들었을 때 한국에서도 미국의 개발 프로세스를 따를 것을 종용했다고 한다. 하지만 한국에서 채용된 개발자들은 미국의 개발 프로세스는 너무 무겁다고 한국 방식으로 개발했다고 주장을 했다. 그리고는 미국의 개발 주문에 대해서 믿을 수 없는 속도로 해결을 해나가기 시작했고, 미국 본사는 이런 경이로운 결과를 보고는 한국식 개발을 묵인할 수 밖에 없었다.


그뒤 몇 년이 지난 지금은 어떻게 되었을까? 미국 본사의 개발 프로세스를 착실히 따른 호주 지사와 엄청난 차이를 보이고 있다고 한다. 똑같은 일을 호주 지사에서는 7명이 처리를 하고 있고 한국 지사에서는 70명이 야근까지 해야 간신히 처리를 하고 있다고 한다. 


그렇게 된 이유가 분석/설계도 없이 빨리빨리 개발을 하다보니 아키텍처가 엉망이고 개발자들이 많이 바뀌었는데 내용을 아는 사람도 별로 없다고 한다. 뭐 하나 고치려고 해도 보통 어려운 것이 아니라고 한다.


전해 들은 얘기라서 과장이 있다고 해도 문제가 심각하고 이미 많이 망쳐 놓은 것은 사실이다.


글로벌 소프트웨어 회사라고 하더라도 한국에 와서 착각하는 것들이 있다. 놀라운 속도를 보여주는 한국식 개발방식을 신기해 하지만 그 문제점을 피부로 심각하게 알지 못한다.  스펙도 제대로 작성하지 않고 분석/설계/구현을 섞어서 빠르게 개발하는 것이 신기해 하지만 얼마나 큰 문제가 있는지 실리콘밸리 회사들도 잘 모른다. 그런 식으로 개발해 본적이 없기 때문이다.


그렇다고 글로벌 소프트웨어 회사가 본사의 개발 프로세스를 강제화 한다고 잘 적용되는 것은 아니다. 한국에서 잔뼈가 굵은 개발자들은 몸에 밴 개발 방식 때문에 적응하기가 매우 어렵다. 차라리 신입사원들을 뽑아서 교육시키면서 개발을 하는 것이 더 빠를지도 모른다.


이는 한국의 소프트웨어 회사 내부에서도 그대로 적용된다. 글로벌 소프트웨어 회사의 개발 프로세스가 아무리 좋다고 하더라도 한국의 소프트웨어 회사에는 바로 적용이 안된다. 대부분은 무리한 시도이고 실패한다.


변화를 감당할 수 있을만큼씩 조금씩 바꿔나가야 한다.


image by  ChristopherA


* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 

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

전규현 소프트웨어이야기 분석, 설계

개발자의 취향

2012.08.02 06:24 by 전규현


잠시 후 Google blogger로 이동됩니다.





소프트웨어 프로젝트를 진행할 때 합리적인 결정보다는 개발자의 취향대로 진행되는 경우가 많다.


이 경우 Architecture상의 심각한 문제점을 내포하게 된다.


제대로된 분석과 설계를 통해서 Architecture가 결정되어야 하는데 개발자 취향에 맞는 개발언어를 선택하고 검증이 안된 기술을 선택하면 그 Risk는 고스란히 프로젝트가 떠안아야 한다.


Architecture를 결정할 때 고려해야 하는 요소는 개발자의 취향이 아니다. 회사의 미래 비즈니스 전략을 고려해야 하고, 현재 개발자들의 구성과 역량, 제품의 성격과 로드맵이 중요한 고려사항이다. 


이러한 전략없이 특정기술을 맹신하거나 거부하기도 하고 무조건 새로운 기술을 채용하기도 한다.

그러다보면 각 제품마다 중구난방으로 여러 기술이 쓰이고, 유지보수에 심각한 문제를 초래하기도 한다.


그럼 어떻게 하면 이런 잘못된 결정을 막을 수 있을까? 답은 의외로 간단하다. 분석을 제대로 하는 것이다. 제대로된 스펙문서에는 최종 결론 뿐만 아니라 그런 결정에 이르게 된 근거와 의논 과정도 적어야 한다. 그래야 스펙을 읽는 사람들이 의문가 이의를 제기하지 않는다.


예를 들면 다음과 같은 것들이 있다.

  • 현재는 Windows만 지원하지만 3년안에 Mac을 지원할 가능성이 90%라서 엔진은 ANSI-C로 개발을 하고 UI를 QT Framework를 이용한다.
  • Java와 C로 모두 개발이 가능하고, 프로젝트 리더가 C언어를 더 좋아하지만, 기존 제품들이  Java로 되어 있고 회사에 Java개발자가 대부분이므로 Java를 선택한다.
  • 회사에 자연어 처리 전문가가 있지만 자연어 처리 엔진의 직접 개발 비용과 상용라이브러리를 구매했을 때를 비교했다. 10년 후까지의 유지보수 비용을 고려하여 자체 개발보다는 상용라이브러리 구매를 선택했다.
  • 현재 프로젝트는 아이폰/아이패드 용으로만 계획을 세웠지만, 영업부서와 논의결과 안드로이드를 지원할 가능성이 있어서 제품의 난이도가 그렇게 높지 않아서 Adobe Air를 사용하기로 했다.
이러한 결정 과정은 프로젝트를 진행하면 수십가지 또는 수백 번 진행이 된다. 스펙문서에는 이러한 결정과정까지 적어야 정확한 내용이 된다. 또한 중간에 상황이 변경되면 신속하게 영향평가를 할 수 있고 스펙을 변경할 수 있다.

소프트웨어 프로젝트는 개발자의 취향대로 진행되는 것이고 합리적인 근거를 바탕으로한 Architecture 결정에 따라 진행되어야 한다.

Image by kevin dooley



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

전규현 프로젝트/요구사항분석 분석, 설계

한 SI회사의 프로세스에 대한 오해

2012.07.16 09:45 by 전규현


잠시 후 Google blogger로 이동됩니다.







필자는 업계의 여러 사람과 얘기할 기회가 많다.


최근에 한 대형 SI회사의 한 PM과 얘기를 한 적이 있는데 프로세스 상의 큰 문제가 있었고, 실제 프로젝트팀에서는 잘못된 프로세스로 인해서 어려움을 겪고 있었다.


SI회사의 오랜 바람 중의 하나가 "공정분리"이다. 즉, 분석/설계/구현을 분리해서 프로젝트를 진행하는 것이다.

"공정분리"가 되지 않은 상태에서는 분석/설계/구현이 뒤엉켜서 개발을 진행한다.


"공정분리"는 분석을 잘해서 설계자에게 넘겨주면, 설계자는 설계를 잘해서 개발자에게 넘겨주고 개발자들은 설계서 그대로 코딩만 하면 되도록 하려는 것이다.


최근 해외 프로젝트가 증가하면서 분석/설계/구현을 뒤엉켜서 진행할 경우 코딩하는 개발자까지 해외 파견을 해야 한다. 그래서 공정분리는 점점 필수가 되었다.


그래서 진행한 것이 해외에서 "분석/설계"를 잘 해서 넘겨주면 국내에서는 개발자들은 그대로 "구현"만 하면 되도록 하는 프로세스를 만든 것이다.


실제로 이 프로세스는 잘 작동하지 않고 있다고 한다. 그동안 해오던 방법과 역량이 분석/설계를 해도 "구현"은 이와 상관없이 알아서 진행하고 모르면 분석가에게 물어가면서 코딩하던 수준이었다. 이런 상황에서 이 프로세스가 잘 작동할리가 만무하다.


이렇게 공정을 분리하려면 "분석/설계" vs "구현" 보다는 "분석" vs "설계/구현"이 더 낫다.


설계가 구현에 좀더 가깝고, 잘된 분석서를 가지고 충분히 "설계/구현"을 할 수 있기 때문이다.


여기서 또 오해가 있는 것이 설계를 잘해서 넘겨주면 그대로 코딩만 하면 될 줄 아는 것이다. 현실에서는 이렇게 잘 진행되지 않는다. 이렇게 하기 위해서는 설계를 너무 자세히 적어야 하고 실제 구현시 많은 문제를 발견하게 된다.


더 좋은 방법은 설계는 꼭 필요한 만큼만하고 구현에 적당한 자유도를 주는 것이다. 


이렇게 제대로 "공정분리"를 하기 위해서 대전제가 하나 있다. 


바로 "분석"역량이 뛰어나야 한다는 것이다. 뛰어난 분석가를 많이 보유하고 있어야 한다.

현재의 분석역량은 기껏해야 "기능"분석과 약간의 "비기능"을 분석하는데 그치고 있다. 분석이 무엇인지 짧은 글에 일일이 설명하기는 어렵지만 분석은 이보다 훨씬 크고 어려운 일이다. 비즈니스전략도 포함해야 하고, 설계도 일부 포함한다. 


필자의 생각으로는 이 SI회사는 당분간 프로세스의 시행착오를 좀더 겪을 것으로 생각된다. 잘못된 프로세스를 바로 잡는데 시간이 걸릴 것이고, 분석역량을 끌어 올리는 일에 시간이 좀더 걸릴 것이다.


시행착오를 겪는 시간은 짧을수록 좋다.


image by Greg McMullin 




 

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

전규현 개발프로세스 SI회사, 분석, 설계, 프로세스

  1. 요즘 써주신 글 중에서 가장 좋은 글인 것 같습니다. ^^
    보석 같은 키워드들이 많네요. - 자유도, 분석의 중요성 등
    분석이 참 중요하죠.
    초기 방향을 잘못 잡으면, 팀원이 아무리 열심히 해도 엉뚱한 방향으로 가는구나 하는 느낌이 듭니다.
    그나저나 SI는 워낙 넓은 분야를 커버하다 보니,
    깊이 있는 분석이란 참 뛰어난 분들의 영역인 것 같고요~

    고맙습니다.

  2. 제임스님 안녕하세요.

    SI회사의 분석가들은 분석역량보다는 도메인지식이 뛰어난 사람이 많습니다. 고객의 업무를 고객보다 잘 아는 경우가 많지만 업무지식을 쌓아가는 방식으로 성장하다보니 분석 역량이 떨어져서 고객의 요구사항 파악이 부족하고 스펙관리가 떨어지고 설계/개발자에게 스펙 전달이 잘 안됩니다. 결국에 분석가가 구현단계까지 도움을 많이 줘야 하는 경우가 많습니다.

    이러다보니 세계적인 방법론을 도입해서 문서만 수십가지를 만들어도 별로 나아지는 것은 없이 문서를 많이 만들려고 고생만 합니다.

    세계적인 방법론보다는 제대로된 분석 역량을 익히는 것이 더 중요합니다. 결론은 전문가에게 배우는 거죠. ^^

  3. Blog Icon
    LInE.

    설계자와 개발자의 롤이 명확한(철저히 분리된..) 프로젝트를 한 적이 있는데, 설계단계 진행시 설계자 설득하느라 바쁘고 개발단계 진행 시 개발자와 설계자 커뮤니케이션 문제 때문에 아주 골머리 썩었었습니다.-_ㅜ

    개발자들은 투입되자마자 설계문서를 파악하고 코딩에 들어가야 하는데, 작성가이드를 해 준 설계문서의 항목이 너무 많고 자세하다고 설계자들이 반발.. 하지만 아무리 생각해 봐도 그정도의 설계항목이 본문에 말씀하신 "꼭 필요한 만큼" 이라고 생각이 되어 개발자들이 코딩하려면 그정도는 설계를 해 줘야 코딩들어갈 수 있다고 설득하느라 한참 시간 보내고,

    또 막상 개발자들이 코딩 들어가니 왠걸 진짜 "설계문서에 있는 기능만" 구현을 해 놓더라구요. 예를 들면 단위테스트 진행 시 기본적인 유효성검사도 되어 있지 않아 개발자에게 말을하면 "설계문서에 없었다."... 설계자들은 어떻게 그런것 까지 문서화 하냐, 필수입력이라고 해 놓았으면 당연히 유효성체크 해놔야 하는거 아니냐고 서로 싸우고...

    본문의 내용이 너무나도 공감가서 한마디 적고 갑니다...

    좋은 글 항상 잘보고 있습니다. 항상 감사합니다. ^^

  4. 안녕하세요. LInE. 님

    항상 시행착오를 통해서 배우지만, 시행착오를 가장 적게 겪는 것이 중요한 것 같습니다. 시행착오를 겪다가 너무 오랜 시간이 지나기도 하죠. ^^

  5. Blog Icon
    manwal

    제가 고민하던 내용을 정확하게 짚어 정리해주시니 너무 공감됩니다. 이런 경험들을 기록해두는 것이 매우 중요하다는 생각이 듭니다.

  6. 감사합니다. Manwal님

  7. Blog Icon
    GF

    최근 다른 회사와 프로젝트를 진행하게 되었는데, 그 회사에서는 약 3년을 끌어온 개발건이 있었습니다. 전규현님의 글들에 늘 나오는 대로 스펙과 설계 등의 문서는 아예 없고, 개발팀장이 교체될때마다 주먹구구식으로 진행이 되어왔기에 1년을 예상하고 시작한 프로젝트가 3년이 되어도 완결이 안되고 있더군요.
    이러한 상황에서, SI회사 혹은 컨설턴트를 통해 분석/설계 부터 다시해서 새로 시작하는 것이 나을지요?
    내부에 개발자를 채용해서 진행을 하는 것은 많이 지친듯 보입니다. 사람도 요새는 더 뽑기도 어렵구요...

  8. 안녕하세요. GF님

    이미 망쳐 놓은 경우가 가장 어려운 경우입니다.
    제가 SI회사도 컨설팅을 하고 교육을 하기 때문에 꽤 아는데 SI회사도 분석/설계 역량이 별로 없습니다.

    일단 이대로 진행해서 어떻게든 마무리 하는 방법과 다시 분석/설계를 진행하는 방법을 비교해 봐야 하는데 현재 진행상황이 어느 정도 인지 파악을 먼저 해야 합니다.

    분석/설계를 다시 진행하려면 직접 하시던지, 저희회사에 의뢰를 하는 것이 좋을 것 같습니다. 직접 하시면 시행착오를 겪을 수는 있지만 그래도 내용을 잘 아실 것이기 때문에 가능할 수도 있습니다.

    혹시 진행하시다가 궁금한 점이 있으면 메일로 문의해주세요. 진짜 답답하시면 제 사무실로 한번 찾아오시면 자세히 설명 드리겠습니다. ^^

SRS에 대한 인식의 변화

2009.11.13 23:46 by 전규현


잠시 후 Google blogger로 이동됩니다.




 
그 동안 본 블로그를 통해서 소프트웨어 개발에서 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 - [개발프로세스] - 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은?
2009/01/29 - [소프트웨어이야기] - Head First Software Development 리뷰
2009/01/21 - [프로젝트/요구사항분석] - UI Mock-up
2009/01/20 - [프로젝트/요구사항분석] - 샘플만 보여주세요.
2009/01/19 - [프로젝트/요구사항분석] - 그냥 쓸 수 있겠네요.
2008/11/19 - [프로젝트/요구사항분석] - SRS(Software Requirements Specification)의 중요성
2008/11/03 - [소프트웨어이야기] - 프로젝트 산출물을 프로젝트 종료 후에 만들고 있나요?

지금까지는 SRS라는 용어조차 한번도 들어본 적이 없는 소프트웨어 개발자나 관련자들이 많았었습니다. 하지만 이제는 조금씩 SRS라는 용어에 대해서 알기 시작하는 것 같습니다. 또 소프트웨어 개발에서 있어서 요구분석이 왜 중요한지에 대해서 조금씩 인식해가는 것 같습니다.

그 예로 최근에는 정부에서도 소프트웨어 기업들의 경쟁력 강화, 특히 해외 시장 진출 시 경쟁력 확보를 위해서SRS 작성을 중요한 요소로 보고 정부 지원 과제에 포함을 하고 있습니다.
이러한 과제에 평가위원으로 참석을 해보니 아직은 많은 소프트웨어 회사들이 분석능력을 제대로 갖추고 있고, SRS를 잘 쓸 수 있는 역량을 갖췄다고 보기는 어렵습니다. 하지만 제대로 된 소프트웨어를 짧은 시간에 개발하기 위해서는 분석을 제대로 하여 SRS를 작성하고 SDP를 만들어야 한다는 것을 인지한 것만으로도 큰 변화라고 볼 수 있습니다. 필요성을 인식하는 것이야 말로 변화가 가능하게 하는 원동력입니다.

다만, 문제는 분석을 잘해야 한다는 것, 즉 SRS를 잘 써야 한다는 것을 인식하고도 SRS를 잘 적는 방법을 배울 곳이 없다는 것입니다. Software 선진국에서는 수십년 간 개발자들이 SRS를 써 왔기 때문에 서로 Template는 조금씩 달라도 개발자로서 일을 하는 동안에 계속 접해 왔고, 써왔기 때문에 따로 배우고 말 것도 없이 SRS를 쓸 줄 알게 되었습니다. 물론 모든 개발자가 SRS를 다 제대로 쓸 줄 아는 것도 아니고 그럴 필요도 없지만, 소프트웨어 프로젝트를 시작할 때 누군가가 SRS를 작성하고 관련자들과 리뷰를 하는데 전혀 문제가 없습니다. 

하지만 이제 시작인 우리나라는 배울 곳도 없고, 스스로 연구하고 공부해서 작성하기에는 요구분석이라는 분야 자체가 너무 어렵습니다. 그 동안 여러 회사에서 스스로 작성했다고 하는 SRS를 분석해보면 합격점을 줄 수 있는 것은 거의 전무했다고 해도 과언이 아닙니다. 그렇다고 미국 회사에 가서 몇 년 배우고 오기도 어려운 실정입니다. 또, 국내에서는 학교나 학원에서 배울 수 있는 환경도 되지 않습니다. 그렇게 배운다고 해도 몇몇 기법만 배우고 핵심은 파악하지도 못하게 됩니다. 그 이유가 대부분의 교수나 강사가 소프트웨어 프로젝트에서 실제로 SRS를 써본적이 거의 없이 이론적으로 배운 정도이기 때문입니다. 실제 프로젝트에서 SRS를 제대로 써본 경험을 많이 가지고 있는 경험자와 같이 SRS를 써보면서 꾸준히 배워 나가는 것이 가장 적절한 방법입니다.

물론 몇몇 개발 방법론에서는 SRS를 작성하지 않습니다. 하지만 이러한 방법론에서도 스펙이 필요 없다고 하는 것은 아닙니다. 다만 스펙을 바라보는 관점과 적는 방법이 다를 뿐입니다. 따라서 스펙의 개념을 정확하게 알고 SRS를 잘 작성할 줄 아는 개발자들이라면 스펙의 형태가 테스트케이스가 되든 어떤 다른 형태가 되든 문제는 없습니다. 즉, 소프트웨어 분석역량이 문제입니다. 

분석역량의 부족은 부실한 스펙문서를 만들게 되고 이는 설계, 구현 기간에 많은 혼란과 재작업을 초래하고 출시 후에도 유지보수 비용을 크게 증가시킵니다. 그 동안 우물 안 개구리처럼 내수시장에서 소수의 개발자를 데리고 고객이 원하는 대로 뚝딱 만들어서 장사를 했는데, 소프트웨어 볼륨이 커지고 해외 시장에 진출을 하려니까 딱 벽에 부딪히는 겁니다. 이 과정에서 무리하게 해외 진출을 추진하다가 유명을 달리한 회사들이 상당히 많습니다. 그렇다고 세계 시장의 1%밖에 안되는 국내 SW시장에서만 놀기에는 국내 시장은 너무나 작습니다. 왠만큼 성장한 회사라면 해외 시장 진출의 유혹을 떨처버리기 어렵습니다.  

물론 SRS, 스펙, 분석능력이 이 모든 것을 해결해주지는 않습니다. 하지만, 가장 중요하고 핵심적인 요소라 확신합니다. 이는 저만의 주장이 아니고 제가 존경하는 수많은 실전 소프트웨어 전문가들의 주장이기도 합니다. 그러한 맥락으로 앞으로 SRS, 스펙, 분석역량 향상에 대한 글을 종종 올려보려고 합니다. 블로그를 통한 지식전달이 얼마나 효과가 있겠는지 의문은 들지만, 필요성에 대한 인식만 생기더라도 글을 올린 보람을 있을 것으로 생각됩니다.

이와 관련된 궁금증, 의견, 경험, 고민거리, 정보, 아이디어 등 어떤 것이라도 같이 교환하고 싶습니다. 댓글이나 방명록, 메일로 얼마든지 보내주세요. 제가 해결해드릴 수 있는 것은 해결해드리죠.
그리고 교육을 받고 싶으신 개발자나 회사라면 연락 주시기 바랍니다. 제가 여건이 되는 한도내에서는 많은 소프트웨어 개발자들에게 전달하고 싶습니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.

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

전규현 프로젝트/요구사항분석 SRS, 분석, 스펙, 요구분석, 정부과제

  1. 최근 프로젝트 진행하면서, 요건정의서 / 주요화면 정의서만 가지고 프로젝트를 수행했었습니다. 유사 경험이 있으니 잘 되겠지라구 약간은 자만하면서요..

    하지만 관련 분야 업무를 처음 해보는 사람들과의 협업/구현하면서 문제가 하나둘씩 생겨나기 시작하고, 주기능 보다는 당연히 될거라고 생각했던 부기능에서의 생각의 차가 너무 컸고, 결국 Rework을 하게 되더군요.
    확실히 일은 정석대로 해야한다고 SRS 로 시작했으면 좋았겠다는 후회가 나중에 들더라구요...

    좀 부끄러운 경험담이지만.. SRS 중요성/초기 설계의 중요성을 깨닿게 했던 중요한 교훈이었던 것 같습니다.
    전규현 수석님.. 블로그글 잘 공감하고 있습니다. 감사합니다.

  2. Peter님 안녕하세요.
    실제로 제가 다른 개발자들이 작성한 여러 SRS를 검토해보면 비기능요구사항이 주로 부실하게 작성되어 있더군요. 하지만 비기능요구사항이 SRS에서 더 중요하다는 것을 잘 인식하지 못합니다. 기능이 하나 잘못적힌 것은 일반적으로 해당 모듈만 수정하면 되지만, 비기능요구사항 하나 누락되거나 잘못 적힌 것은 시스템 전체를 다 뜯어 고쳐야할 정도로 큰 사건일 수 있습니다. 앞으로 블로그에서 이와 관련된 다양한 내용들을 다룰 계획입니다.

  3. 개발자들도 이러한 개발의 효율을 위한 절차를 받아 들여야 하지만
    그에 못지 않게 개발을 위탁하는 사람도 개발에 대한 이해가 널리 퍼졌으면 좋겠다는 생각이 듭니다.

    이러한 프로세스 없이, 중간에 계속 수정을 요구하고 이에 따른 추가기간을 정산하지 않으면
    개발자 역시 무상으로 계속 지치게 되니 말이죠. 물론 인간이라 처음부터 완벽하게 SRS를 만들어내서
    한번에 만들수는 없기에 어느정도 변경사항이 생기겠지만, 디자인이 마음에 안들어요 이렇게 바꾸어 주세요
    라고 하는건 개발 위탁하는 사람역시 이러한 개발의 과정중 하나로 넣어 교육을 시켜야 하지 않을까?
    라는 생각마저 들게 합니다.

  4. 구차니님 안녕하세요.
    말씀 하신 것처럼 처음부터 스펙을 완벽하게 다 정하고 프로젝트 끝날 때 까지 절대 바꾸지 않을 수는 없습니다. 그래서 어차피 바뀌니 대충 시작하는 것은 더 문제가 크죠.
    개발자나 고객이나 모두 스펙에 대한 이식의 변화가 필요하겠죠. 또한 교육, 훈련과 경험 모두가 필요하고 1,2년에 해결될 문제는 아니라고 봅니다.

  5. Blog Icon
    김경록

    좋은 글 잘 읽고 갑니다.
    ^^

  6. 김경록님 오랫만입니다.
    댓글 남겨주셔서 감사합니다. 항상 건강하세요.

  7. IT 관련 무엇인가를 찾다보면 이 블로그로 들어오게 되는 듯 합니다. ^^; 새로운 프로젝트를 하는데 아무래도 불가능에 도전해보아야 할 것 같습니다. 갈수록 괜찮은 SRS가 나오겠지요. 혹시 괜찮은 Template 있으시면 하나 던져주시면 고이 잘 받아먹겠습니다. 굽신굽신~

  8. Google에서 Software Requirements Specification으로 검색을 하면 여러 Template를 찾을 수 있을 겁니다. 하지민 Template 만 보고 제대로 적는 다는 것은 불가능합니다. 타이거우즈 골프채만 보고 타이거우즈처럼 골프치는 것을 흉내내려는 것과 같습니다.
    소프트웨어에서 가장 어렵고도 중요한 것이 바로 무엇을 개발할지(스펙)을 적는 것이지요.

  9. 좋은 글 잘 읽고 갑니다 ^^ 현재 컴퓨터공학 전공하는 3학년 학생입니다~
    소트프웨어 공학 과목을 공부하면서 요구사항 분석 부분에 어려움이 있어
    관련 자료를 찾다가 방문하게 되었네요!
    종종 들러서 좋은 글 자주 읽도록 노력하겠습니다.

  10. 안녕하세요. 임수빈님
    소프트웨어 공학은 배울수 없다고들 합니다. 즉 경험을 통해서 익힐 수 밖에 없다는 뜻. 하지만 배우는 것은 나중에 경험을 할 때 큰 도움이 됩니다.
    그중에서도 가장 어려운 분야가 요구사항 분석입니다.
    이론적인 것 만 가지고 실제 프로젝트에서 제대로 적기는 정말 어렵습니다.
    열심히 배우시고 실전에 적용하시기 바랍니다.

  11. Blog Icon
    이해승

    안녕하세요. SI 분야에서 일한지 15년이 넘어가면서 제대로 된 SRS 작성해 본 기억이 별로 없습니다.
    어디서 배워야 할지도 모르겠구요...소프트웨어 공학, 다양한 프로젝트 관리 기법 등등 안해 본 경험이
    별로 없음에도 불구하고 여전히 제대로 된 SRS 작성하는 것에 목 말라 하고 있습니다.
    어떻게 시작해야 좋을까요?

  12. 이해승님 안녕하세요.

    가장 어려운 질문 중 하나입니다. "어떻게하면 SRS를 잘 쓰는 법을 배울 수 있을까?" 어떻게 하면 SW를 잘 개발할 수 있을까와 거의 동격의 질문이기도 합니다.
    또는 어떻게 피아노를 배울 수 있을까?와 비견되기도 합니다.
    오랫동안 SW를 개발해왔던 개발자라고 하더라도 SRS를 작성하는 것, 즉 스펙을 작성하는 것은 여전히 어려운 과제입니다.

    제일 좋은 것은 스펙을 잘 작성하고 있는 회사에 가서 일하면서 자연스럽게 배우는 것입니다. 우리나라에는 그런 회사가 별로 없으니 실리콘밸리로 가야합니다. 현실성은 없죠.

    다른 방법으로는 전문가나 경험자에게 배우고 직접 작성을 해보고 리뷰받고 이런 과정을 반복하면서 배우는 방법입니다.

    그렇지 않고 책을 보고 스스로 해보는 방법은 시행착오를 많이 겪어야 하고 영원히 제대로 작성하믄 방법은 못배울 가능성이 거의 100%입니다.

    가장 좋은 방법은 회사에서 전문가를 데려와 주는 것이겠죠.

    우선은 제가 쓴 "소프트웨어 개발의 모든 것"이라는 책을 먼저 보세요. 이해를 돕기 위한 설명이 좀 되어 있습니다.

이건 기능이 아닌데

2009.08.03 23:14 by 전규현


잠시 후 Google blogger로 이동됩니다.




의례 스펙, 기능요구사항 등을 정리한 문서를 보면 기능만 잔뜩 나열되어 있는 것은 매우 흔한 일입니다.
소프트웨어를 만든다고 하면 구현해야 할 기능만 알면 제대로 잘 만들 수 있을 것으로 생각하기 십상입니다. 상식적으로 생각해도 기능면 제대로 구현하면 되겠지요. 여기에 UI는 살짝 추가하고요.

하지만, 분석을 할 때 기능보다 더 중요한 것이 비기능 요구사항입니다. 즉, 기능은 아닌데, 요구사항 즉, 스펙인 겁니다. 기능이 중요하기는 하지만, 기능 하나가 잘못되면 이를 고치는 것은 그렇게 어렵지 않습니다. 그런데 비기능에서 잘못되면 소프트웨어를 완전히 뒤엎어야 하는 일이 발생할 수도 있습니다. 

이렇듯 비기능이 기능보다도 더 중요한 측면이 있는데, 눈에 바로 보이지 않는 다는 이유로 간과되기 쉽습니다. 그럼 이렇게 중요한 비기능 요구사항에는 어떤 것들이 있는지 몇 가지만 알아 보겠습니다.

첫째 성능입니다. 소프트웨어가 얼마나 빨리 반응을 보이며 단위 시간당 얼마나 많은 데이터를 처리해야 하는지 정의해야 합니다. 또한 이를 검증하기 위한 기준도 마련이 되어야 합니다.

둘째 안정성입니다. Database와 위젯 시계는 요구되는 그 안정성이 다릅니다. Database는 시스템이 정전이 되어도 데이트가 파손이 되어서는 안됩니다. 그러한 안정성을 보장하기 위한 요구사항도 자세히 기술이 되어야 합니다.

셋째 보안입니다. 데이터는 암호화 되어서 저장이 되어야 하는지? 암호키는 어떻게 보관을 하는지? 프로토콜은 암호화 되어야 하는지? 시스템은 인증을 거쳐서 접근해야 하는지? 등등의 보안 요구사항은 각 소프트웨어마다 다른 요구사항을 가지고 있습니다.

그 외에도 많은 비기능 요구사항은 있습니다. 가용성은 시스템이 24시간 동작하는 것인지 MS-Word처럼 필요할 때 사용하고 종료하는 것인지 기술합니다. 또, 이식성은 현재 지원해야 하는 것이 아니고 향후 미래에 Porting을 하기 용이하도록 만들기 위한 요구사항입니다. 미래에 Windows에서 Linux로 포팅을 할 수도 있고, 여러 언어를 지원하도록 확장할 수도 있습니다. 또 64bit를 지원할 수도 있고, Unicode를 지원하게 될 수도 있습니다. 따라서 미래에 어떻게 할지 계획이 아무것도 없다면 이식성을 정의할 수가 없습니다. 다국어, 개발표준, 메모리 사용제한, 소스코드 재사용성, 유지보수 편의성 등 많은 비기능 요구사항이 있습니다.

딱 보시면 아시겠지만, 하나하나가 잘못 적히면 완전히 소프트웨어 전체를 뒤집어야 하는 것들입니다. 이런 것들이 눈에 보이지 않는다고 기능만 보고 제품을 만들었다가는 앞은 안보고 땅만 보고 달리는 자동차와 같습니다. 조금만 고개를 들면 보이는 막다른 골목으로 가고 있을지도 모릅니다.

기능 신경쓰기도 바쁜데 이러한 수많은 비기능까지 어떻게 신경을 써서 만드냐고요?
그럼, 신경 안쓰고 그냥 만들면 그 요구사항이 사라지나요? 무시된겁니다. 요구사항을 고스란히 남아 있고 나중에 비용을 수십,수백,수천배를 치러야 합니다.

비기능 요구사항을 잘 적는 방법은 그러한 비기능 요구사항에 대하여 경험이 있을 수 있도록 소프트웨어를 개발한 상당한 경력이 필요하고, 적는 방법에 대하여 배우거나 학습이 필요합니다. 또, 이런 과정을 통해서 과거에 간과된 비기능 요구사항이 현재 얼마나 많은 손해를 끼치는 깨우치면서 배워나가게 됩니다. 하지만 이런 과정을 거쳐야 시행착오가 최소화 되지, 비기능 요구사항을 고려하지도 않는다면 항상 바쁘고 앞으로 잘 나아가지 못하는 굴레를 벗어나기 어려울 겁니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석 기능, 보안, 분석, 비기능, 성능, 스펙, 안정성

  1. 비기능이라고 해서 무슨 개념인가 했는데
    정말 기능보다 더 중요한 내용들이군요.

    그나저나.. 멀티플랫폼은 개발자의 악몽이죠 ㅋ

  2. 구차니님 안녕하세요.
    멀티플랫폼 개발을 하고 있다면 중요시 되는 비기능들이 더욱 많죠. 멀티플랫폼은 개발, 빌드, 테스트에 더 많은 시간은 들어가지만 익숙해지면 크게 문제 없지 않나요? 개발자에게는 좋은 경험이죠.

  3. 기능제공을 잘 하는 것도 중요하지만 RFP를 잘 분석하고 클라이언트와 미팅을 잘해서 리스크가 될만한 것들을 모두 정리한 다음에 명확하게 계약서와 SoW를 작성해서 '사인 받는게' 중요한 것 같습니다.

    그러지 않으면 끝없이 이어지는 고객의 추가요구사항을 감당해 낼 수가 없지요.

    특히 개발자들이 약한 부분이 클라이언트와의 미팅 후 회의결과 정리 및 쌍호간 확인싸인 하기, 이거 정말 중요합니다.

  4. 우울한딱따구리님 안녕하세요.
    우리나라 고객들은 왠만하면 사인을 잘 안하려고 하지만, 그래도 회의록 작성하고 사인하고 사인하지 않더라도 배포만 하는 것도 나름 효과는 있죠. 계약할 때 SRS와 ATP를 첨부하는 외국과는 아직 거리는 멀죠.

고객이 요구사항을 너무 자주 바꿔요.

2009.07.30 23:48 by 전규현


잠시 후 Google blogger로 이동됩니다.



우리나라 소프트웨어 시장을 너무 비관적으로 과대평가하는 경우를 종종 봅니다.

예를 들면 전세계 유래가 없는 까다로운 고객 요구 수준, 시도 때도 없이 바뀌는 요구사항, 엄청나게 낮은 금액, 제품의 Output과는 상관없이 작업 시간을 통제하는 관행

일부는 공감을 하기도 하지만, 어느 나라를 가던지 각 나라만의 특징이 있다는 측면으로 바라보고 싶습니다. 우리나라 고객은 요구사항을 정말로 외국에 비해서 더 자주 바꾸는 것인지는 생각해 볼 필요가 있습니다. 어딜 가던지 고객은 요구사항을 항상 바꾸기 마련이고, 그것이 고객의 습성이라고 볼 수 있습니다. 그런데, 외국에서는 관행적으로 문화적으로 스펙을 근거로 계약을 하고, 분석 능력이 뛰어난 엔지니어들도 많이 있습니다. 하지만 그런 저변이 상대적으로 부족한 우리는 개발을 하는 쪽이나 고객이나, 일단 대충으로 요구사항으로 개발을 하고 나중에 서로 맞춰나가는 것이 상당 부분 관행화된 측면이 있습니다.

개발회사와 개발자가 요구사항을 분석하고 통제하는데 능력을 갖추고 있다면 100%는 아니지만, 고객의 요구사항 변경을 상당부분 통제 가능한 범위 안으로 가져올 수도 있습니다. 

스스로가 주먹구구 식으로 개발을 하면서 고객에게만 덤터기를 씌우는 것은 스스로에게 이득이 될 것이 없습니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석 개발자, 변경, 분석, 소프트웨어, 요구사항

  1. 포스팅 잘 읽었습니다. CMMI에서도 요구사항에 대해서 요구사항을 먼저 "개발" 하고 그 다음 레벨이 요구사항 "관리"입니다. 지속적으로 요구사항이 바뀌기 때문이지요. 본문의 내용과 비슷한 맥락이라 허접 답변 남기고 갑니다. ^^

  2. hoya님 안녕하세요.
    CMMI도 결국 소프트웨어를 잘 개발하기 위한 것이 목적이므로 근본 원리는 같습니다.

  3. 어쩌면 가장 중요한 차이점은,
    요구사항이 변경되고 나서 재계산되는 시간, 비용의 차이가 아닐까 생각이 됩니다.
    한국에서는 변경되도 마감일이나 비용이 변하지 않으니 말이죠..

  4. 구차니님 안녕하세요.
    요구사항이 변경되면 그에 따른 영향평가가 따라야 하고, 계약이 변경되어야 하는데, 우리나라에서는 스펙따로 계약 따로이기 때문에 요구사항이 2배로 늘어도 계약은 변하지 않는 문제가 있죠.

과거의 개발자 vs. 미래의 개발자

2009.04.28 11:16 by 전규현


잠시 후 Google blogger로 이동됩니다.



개발자는 2가지의 상반된 가치를 가지고 있습니다.

하나는 과거의 가치
또 하나는 미래의 가치입니다.

"이 사람들 나가면 과거에 개발해 놓은 것 어떡하지?"라는 생각이 들면 과거의 가치를 가진 개발자이고
"이 사람들 나가면 미래에 개발은 누가 하지?"라는 생각이 들면 미래의 가치를 가진 개발자입니다.

과거의 가치를 가진 개발자들은 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식은 머리 속에 있기 때문에 자신이 과거에 만들어 놓은 소프트웨어를 인질 삼아서 회사와 인질극을 벌이고 있는 것과 같습니다. 이렇게 된 원인이 상당부분 회사에 있다고 하더라도, 개발자의 가치는 인질범과 별반 다를 바가 없습니다. 기존 소프트웨어를 망칠까봐 대우해줄 수 밖에 없습니다.

미래의 가치를 가진 개발자들은 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수 할 수 있도록 충분히 문서화를 해 놓았고, Peer review를 통해서 이미 많은 지식이 전달된 상태입니다. 이러한 개발과정을 거쳐서 본인은 분석, 설계 능력을 더욱 향상시켰고, 신기술들에 대한 연구에 집중하여 미래에는 과거의 제품들 보다 한 단계 높은 수준의 제품들을 만들어 낼 것입니다. 이러한 개발자들이 진정한 영웅이라고 할 수 있습니다.

인질범이 되겠습니까? 영웅이 되겠습니까? 이는 본인의 의지에 달려있습니다.

안타까운 것은 고참 소프트웨어 개발자 중에는 영웅보다 인질범이 더 많다는 겁니다. 물론 이 개발자가 인질범과 다를바가 없다는 것을 본인도 모르고 회사도 모르는 경우가 태반이지만 말입니다.



* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 
저작자 표시 비영리 변경 금지
신고

전규현 사람과 기술 Peer Review, 가치, 개발자, 과거, 문서화, 미래, 분석, 설계, 영웅, 인질범, 지식, 후배

  1. 그러고 보니.. 전 이제 2년 경력이긴 하지만, 인질범이었다는 생각이 드는군요 ㅠ.ㅠ
    조금 더 알아보기 쉽게 작성하고 문서도 남기는 버릇을 들이도록 해야겠습니다.

  2. 구차니님 안녕하세요.
    필요성을 느끼는 것이 첫걸음이고, 다음은 배워야죠. 대부분 선배들에게 배우지를 못하니 배우는데, 어려움이 있습니다.

  3. Blog Icon

    동감합니다. 남을 위해 코드를 개발하다 보면 실력향상에도 도움이 된다고 생각합니다. ^^

  4. A2님 안녕하세요.
    협업은 기본인데, 그렇지 않게 생각하는 경우가 너무나 많습니다.

  5. 그러게요. 개인의 문제이기 이전에 조직의 문제라고 생각해요.
    개인이 고민하기 이전에 회사가 조직적으로 만들어가야 하는 부분 아닐까 합니다.
    물런 영세하고 사람도 부족해서 어쩔수 없긴 하지만 말입니다.

  6. hangum님 안녕하세요.
    사실 이런 경우 회사의 책임이 더 크다고 할 수 있죠. 그래도 결국 개발자와 회사 둘다 피해를 입죠.

  7. 아주 멋진 표현이었습니다.
    저놈이 나가면 제가 만든 코드 어쩌지? 라는 생각만 들면
    이미 과거의 개발자이네요.. ^^

  8. zeous님 안녕하세요.
    반갑습니다.

  9. Blog Icon
    momo

    그런데 말이죠.. 제 주변에도 영웅들을 몇몇 봐왔지만 회사에서 못알아 보는건지 인질범과 별반 다를바 없이 대하더군요. 오히려 인질범에게 더 잘해준다는 느낌이 듭니다.

  10. 안녕하세요. Momo님
    회사는 어쩔 수 없이 그렇게 되는 것이지요. 하지만 그렇게 반복되면 회사고 개인이고 둘다 미래가 없다는 거....

  11. 인질범이 되지 않으려고 발버둥 쳤지만, 결국 떠나는 이시점에..
    전 인질범이 었다는 결론이 내려지네요..

  12. 안녕하세요.
    본의 아니게 그렇게 된 경우도 많습니다.

  13. Blog Icon
    장성호

    공감가는 글이네요
    그동안 몇번 직장옮기면서... 매번 강력이 계속남아주기를 요청받았는데..
    미래를 위한 부분도 있었지만, 과거를 위한 부분도 상당한듯 하네요.

    미래가치가 큰 개발자가 되도록 더욱 노력해야 겠습니다.

  14. 안녕하세요. 장성호님
    과거의 가치가 더 높은 개발자들은 자칫하면 그것이 자신의 뒷다리를 잡고 있다는 것을 망각하기 쉽습니다.

  15. Blog Icon
    농부

    유전무죄 무전유죄 입니다.

    누가 프로그래머를 인질범으로 내몰았습니까?

    어처구니없는 일정과 꽉막힌 현업 그리고 끊임없는 요구사항변경...

    어느누가 인질범이 되고 싶었겠습니까?

    프로그래머는 지금도 충분히 어렵고 힘듭니다.

    너무 ~해야한다 자꾸 그러지 좀 마세요.

    몸도 마음도 점점 지쳐가네요..ㅠㅠ

  16. 안녕하세요. 농부님...
    닭이 먼저냐 달걀이 먼저냐? 이슈네요. 개발자들이 일하기 열악한 환경인것은 사실입니다. 조금 더 나은 환경을 만들기 위해서 노력하려고 합니다. 힘내세요.

  17. Blog Icon
    대한민국 개발자

    외국에서는
    DBA, 네트웍 담당자, 서버 담당자, 서버개발자, 클라이언트 개발자, 컨설턴트
    데이터 베이스 설계자 , 업무 담당자, 운영유지 보수 담당자
    이렇게 협업해서 개발하는데

    우리나라는 개발자혼자 다 처리해야 하죠 이런 상황에서 어떻게 문서화가 가능
    하겠습니까 개발 일정도 외국의 절반인데

  18. 안녕하세요. 대한민국 개발자님...
    물론 외국도 One man company는 혼자서 이런 걸 다하죠. 하지만 우리나라에서는 개발자가 수천명이어도 똑같이 이것들을 해야 한다는 것이 문제죠.
    어떻게 협업을 해야 하는지 모르고 훈련도 안되어 있는 겁니다.
    협업을 하기 위해서는 문서화, 프로세스, 시스템, 문화가 뒷받침이 되어야 하는데, 여기저기 구멍이 숭숭 뚤려서 제대로 하기 어려운 것이 현실입니다.
    대기업들은 이것을 돈을 들여 프로세스와 시스템으로 해결하려고 하기도 하는데 문화가 뒷받침이 안되어서 어렵습니다.
    이를 해결하려면 시간도 오래 걸리고 고난의 작업이 될 겁니다.

개발자들이 바글바글한 외딴섬에 떨어진다면

2009.04.22 10:01 by 전규현


잠시 후 Google blogger로 이동됩니다.



개발자들이 바글바글한 외딴섬에 떨어졌는데 서로 뒤죽박죽으로 개발을 하고 있고,이들을 3개월 안에 훈련시켜서 정예 개발자로 만들어 한다는 미션이 떨어졌다면 무엇을 하시겠습니까?

Language 기초를 다시 가르칠까요?
UML을 가르칠까요?
문서 작성법을 훈련 시킬까요?
개발방법론을 가르칠까요?
팀워크를 키워줄까요?
OOP를 가르칠까요?

어떻게 하시겠습니까?

나는 스펙을 작성하는 방법을 가르치고 3개월간 훈련을 시킬 겁니다. 
즉 Requirement engineering을 익히게 하겠다는 뜻입니다. 그만큼 스펙은 현재 소프트웨어 개발현장에서 가장 많은 실패의 원인이 되고 있고, 배우기도 가장 어려운 분야입니다. 나는 수많은 개발자들이 작성한 스펙문서(다양한 이름의 문서)를 봐 왔지만, Requirement engineering을 제대로 알고 잘 작성한 스펙문서는 별로 접해보지 못했습니다. 또한 그로 인해서 프로젝트나 제품에서는 수많은 문제들이 야기되고 있었습니다.

물론 스펙을 제대로 쓰기만 한다고 소프트웨어를 잘 개발할 수 있는 모든 준비가 된 것은 아닙니다. 스펙을 쓰는 것은 이제 소프트웨어 제대로 된 소프트웨어 개발에 한 걸음 내디딘 것 뿐입니다. 거꾸로 스펙도 쓰지 않고 소프트웨어를 어떻게 개발하냐고 반문할 수 있습니다. 즉, 무엇을 개발할지도 모르고 여럿이서 소프트웨어를 어떻게 개발하냐는 것입니다. 또 영업이나 고객은 정확하게 무슨 제품이 나올지도 모르고 기다리냐는 것입니다.

하지만, 이에 대한 반론을 얘기하는 사람도 꽤 됩니다. 기존에 제대로 된 스펙 없이도 훌륭한 제품을 많이 탄생했고, 성공한 제품도 꽤 된다고 얘기합니다.  물론 예외는 항상 있습니다. 저도 몇몇 그런 사례를 알고 있습니다.
정확하게 따지면, 그렇게 성공한 제품은 별로 많지는 않습니다. 그리고 초창기에 제품의 크기가 작거나 고객 수가 작을 때는 멋진 제품이었으나 매출이 늘고, 소프트웨어 규모가 커지면서 망가진 제품도 꽤 많습니다. 즉, 스펙의 부실로 혼동에 빠져서 실패한 제품이 꽤 됩니다.

제대로 된 스펙도 없는 제품이 성공할 확률은 잘 작성된 스펙을 토대로 개발하고 유지보수 되는 제품의 성공확률의 1/10도 안될 겁니다. 

소프트웨어 개발자라면 스펙이 왜 중요하고, 스펙을 잘 적기 위해서 배우고 많은 노력을 기울여야 한다는 것을 알아야겠습니다.

PS) 가끔 우리나라가 소프트웨어 업계에서는 섬처럼 느껴지곤 합니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 

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

전규현 프로젝트/요구사항분석 개발자, 분석, 스펙, 요구사항

  1. Blog Icon

    비밀댓글입니다

  2. 스펙의 정의와 범위는 막연하지 않습니다. 구체적이지요. ISO나 IEEE에서도 정의가 되어 있습니다. 하지만, 소프트웨어나 프로젝트의 성격에 따라서 중요한 부분이 다르고 적당한 표현방식이 다르기 때문에 Template이 Sample을 보는 것은 도움이 된다기보다는 생각의 폭을 좁히고 사고를 고정시키기 때문에 도움이 안된다고 생각합니다. 또한 NDA에도 어긋나고요. 시간이 되면 저를 한번 방문하셔서 토론할 기회를 가지면 좋을 것 같습니다. 그런 기회는 언제든지 환영입니다.

    오히려 설계가 제품마다 상당히 많이 달라서 더 정형화 시키기 어렵죠.

  3. 흠.. 그런 의미의 스펙을 말씀하신 거군요.
    저는 고객의 요구사항에 따라 만들어지는 제품에 대한 스펙을 말씀하시는 줄 알았습니다. 제가 생각했던 부분은 어찌보면 설계서를 생각했었는데 그 상위 레벨 혹은 단계를 말씀하신 것으로 이해가 됩니다. 그렇다면 말씀하신 대로 문제가 발생이 되겠네요. 좋은 말씀 감사합니다.

  4. 조금은 정형화된 예제의 문서가 있을까요? 물론 프로젝트, 솔루션 마다 틀리겠지만요. 어느정도 예제를 삼을만한 문서가 있으면 좋겠네요. 이런문서들도 각업체별로 틀리겠지만 이런문서들도 약간의 틀을 가진 문서가 있으면 좀 공통적으로 적용해서 모든 개발자들이 이해하고 독해할수 있었으면 좋겠다는 생각이 듭니다.

  5. 곰아리님 안녕하세요. 스펙문서는 소프트웨어 개발방법론마다 다 Template이 있으니 Google에서 찾아보는 것은 그리 어렵지 않습니다. 하지만, 복잡한 개발방법론은 스펙과 연관된 문서가 너무 많고 복잡한 것이 문제입니다. 또한 Template을 보더라도 그 내용을 어떻게 채우는지 아는 것은 더 어렵습니다. 경험도 많이 필요합니다. 그래도 Template를 보고 싶다면, ISO나 IEEE에서 정의한 SRS문서를 보면 참조가 됩니다. Template만 보고 작성된 SRS를 보면 잘못된 내용을 적는 경우가 많더군요.

  6. Blog Icon
    [1002]

    스펙은 누가 만드나요?

  7. 스펙을 쓰는 사람은 프로젝트마다 다를 수 있습니다. 스펙을 쓰려면, 고객의 요구사항을 잘 분석할 수 있어야 하고, 기술도 잘 알아야 합니다. 선임 개발자가 쓰기도 하고, 소프트웨어 분석가가 따로 있는 경우도 있고, 다양합니다.

  8. Blog Icon
    .

    개발자들이 바글바글한 섬이라면 스스로 필요한 소프트웨어를 만들어 낼 것이니 교육이 필요없을 듯 합니다. 개발자는 별로 없고 자신이 뭘 원하는지 모르는 고객이 바글바글한 섬이라면 고객들에게 일단 스스로 필요한 것이 "진짜" 뭔지를 알아내는 교육을 하면 의미는 있겠네요.

  9. 일리가 있는 얘기네요. 문제는 스펙을 적는 방법을 잘모르고 경험이 부족한 것이겠지요. 하지만, 개발자들이 자신들이 쓸 소프트웨어를 스스로 만든다면, 그 필요성이 줄어들겠네요. 여태 그렇게 잘 만들어서 써왔고요.

  10. 멋진 반전이네요.

  11. 잘보고 갑니다~일리가 있는얘기 입니다, 프로젝트 단위에서 규모가가 커지면 커질수록
    중요성이 강조 되는것 같아요.
    여담이지만서도...
    개발자에게 회의시간에 웃으며,고집안부리고 커뮤니케이션 하는 방법 가르키는건 어떨까요..

  12. sheon님 안녕하세요. 그것도 좋은 방법이네요. ^^ 왠지 개발자들에게는 공통된 인식이 있는듯 하네요.

  13. 저는 우선 팀웍을 가르칠것 같습니다. 주어진 환경이 아주 좋고 능력이 있는 개발자만 모여 있다 하더라도 협업이 되지 않아 실패하는 경우를 많이 보아 왔거든요. 개발 방법론은 모르더라도 같이 일하는 조직에서 협업이 잘 된다면 그 조직에 맞는 개발방식이 수립이 됩니다. 다들 좋다는 방법론 보다 그 조직에 최적화 되어있는 개발 방법이 가장 효과적인 방법론이라고 생각하거든요. 그런 경우는 뭐같은 요구사항이 나오더라도 찰떡같은 작품이 나오기도 합니다.

  14. C-Thinker님 안녕하세요. 팀웍을 중요하게 생각하는 분이 좀 되는 것 같네요.

  15. Blog Icon
    popopome

    님의 글을 보면서 제가 봤던 아래 블로그에 Scott이 남긴 커멘트가 생각났습니다.
    http://www.gaborcselle.com/blog/2009/04/what-specs-are-good-for.html

    저도 C-Thinker님 말대로 팀웤에 한표를 던지겠습니다.
    Communication is matter to be success or failed!.

  16. popopome님 안녕하세요.
    스펙은 항상 소프트웨어 개발에 있어서 가장 중요하지만 어렵고, 스펙작성은 개발자들의 역량 중에서 가장 우선시 되곤하나 또한 익히기 어렵다고 알려져 있습니다. Scott의 커멘트를 보니 그사람의 경험과 생각을 미뤄 짐작해볼 수 있습니다. 그래서 절대적인 비교는 되지 않죠. 그러기에는 우리나라 개발환경은 기초가 많이 부족하거든요.

  17. Blog Icon
    카페모카

    글 잘읽고 갑니다.

    핵심인재 한명 빼고, 전부 코더로 만드는건 어떨까요?
    중앙집권..불가능하겠죠? ^^

  18. 카페모카님 안녕하세요.
    그렇게 할 수만 있다면 좋은 생각이죠. 가장 적은 비용으로 가장 좋은 제품이 나올 수도 있겠죠. 그리고 그 코더들도 시간이 흐르면 설계도 할고, 더 비싼일을 할 수 있겠죠.

  19. 초보 개발자인 저에게 너무나 와닫는 내용들이 가득한 블로그네요
    RSS 등록하고 자주 오도록 하겠습니다 ^^

  20. 감사합니다.

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..