SW개발자가 선택할 수 있는 미래의 직군

SW개발자는 업무의 특성상 관계된 사람들이 많다. 아니 돌봐주는 사람이 많다고 봐야 할까? 제대로 된 개발자를 육성하거나 성공적인 프로젝트를 수행하기 위해서는 다양한 전문 인력들과의 관계를 잘 형성해야 하는데 작은 기업이나 SW에 대한 이해도, 개발업무환경이 열악한 곳일수록 이러한 지원 인력들은 많지 않다.

개발자의 캐리어관리를 해주는 HR관리자, 시장출시를 위한 제품개발에 참여한 마케팅 관리자, SW개발에 참여한 로직 관리자, 개발자간 소통을 지원하는 커뮤니케이션 관리자, 시스템이나 정보 보안을 위한 보안 관리자, 안정성 확보를 위한 세이프티관리자, 프로젝트를 책임지는 프로젝트 총괄 관리자, 품질확보를 위한 QA/QC 관리자, 개발지원을 위한 프로젝트 개발 관리자, 사회적 관계형성을 지원하는 공공관계협력 관리자 등 여러 관리자들이 필요하다.

SW개발자 스스로도 자신의 전문성확보를 위해 노력해야 하는 것은 물론 전사차원에서도 전문인력을 육성하기 위해 많은 투자를 해야 한다는 것이다.

아래 표는 소프트웨어 개발 경험이 풍부한 전문가의 시각에서 바라본 SW 개발자의 미래 직군으로 참고로 제시한다.

SW 유지보수를 위한 재공학과 역공학

재공학은 SW를 새형태(form)로 재구성하기 위한 SW의 시험(examination) 및 변경(alteration)으로 정의되며, 뒤로 이어지는 새 형태의 구현 역시 포함하고 있다. 재공학은 가장 급진적(그리고 비싼)인 변경이지만, 소규모 변경에도 수행되기도. 재공학은 유지보수성 향상이 아니라 노후된 기존(legacy) SW를 교체하기 위해 종종 사용되기도 한다.

역공학은 SW의 컴포넌트와 이들간 상호관계 식별 및 또 다른 형태 또는 더 높은 추상 수준에 대한 표현물에 대한 생산을 위한 SW 분석 공정이다. 역공학은 수동적 속성을 지녀, SW를 변경하거나 새로운 SW를 만드는 활동이 아니다. 역공학은 제품 소스코드의 호출 그래프와 제어 흐름도의 생산에 초점이 맞춰져 있다.

역공학의 종류로는 재문서화(redocumentation) 및 설계 복구가 있으며, 리팩토링(refactoring)은 SW행동 변경을 배재한 상태에서 프로그램에 대한 재조직화를 통한 변형(transformation)으로, 프로그램 구조 향상을 위한 역공학의 한 형태다. 데이터 역공학은 최근 몇 년간 주목을 받아왔는데, 이는 물리 데이터베이스에서 논리 스키마를 복구하는 활동을 의미한다.

소프트웨어 유지보수

유지보수는 SW생명주기의 주요활동임에도 불구하고 대부분의 조직에서 타활동에 비해 덜 중요시 되었지만 이제는 SW개발에 투자하기 보다는 기운용되는 SW를 최대한 유지하려는
기조에 맞춰 주목받고 있는 상황이다. 과거 Y2K 문제는 SW유지보수에 좀 더 관심을 갖게 하였고 오픈소스 패러다임은 타인에 의해 개발된 산출물에 대한 유지보수의 필요성을 더욱 부각시켰다.

SW생명주기의 유지보수 단계는 보증기간 또는 인수의 후 구현 단계를 따라 시작되지만 유지보수 활동은 좀 더 일찍 시작된다. 유지보수는 사용자 요구사항을 지속적으로 만족시키기 위해 필요하며, 시스템은 수정적(corrective) 및 비 수정적 SW 행동으로 인해 변경된다. 유지보수의 목적은 결함 교정(correct), 설계 향상, 구현 향상, 타 시스템과의 연동(interface), 타 HW, SW, 시스템의 기능사용을 위한 프로그램 적용, 기존(legacy) SW 이전(migrate), SW 폐기 등이 있다.

유지보수자의 활동은 네 개의 주요 활동으로 요약될 수 있는데 SW의 일일 기능에 대한 제어 유지보수, SW 수정에 대한 제어 유지보수, 기존 기능의 완전화(perfecting), SW 성능의 수용 불가한 수준으로 낮아짐에 대한 방지로 나눌 수 있다.

유지보수는 제한된 이해와 테스팅, 영향분석, 유지보수성 등 기술적 이슈와 조직 목표로의 정렬, 유지보수자 형성, 프로세스, 조직적 측면, 외주 등 관리적 이슈, 유지보수 비용추정 이슈, SW유지보수 측정에 대한 이슈가 존재한다.

유지보수를 해결하기 위한 기법은 프로그램의 이해(Program Comprehension), 재공학(Reengineering), 역공학(Reverse Engineering)이 있다. 프로그래머는 변경 사항을 구현하기 위해 프로그램 읽기 및 이해에 적지 않은 시간을 보내는데, 코드 브라우저(browsers)는 프로그램 이해를 위한 핵심도구다. 명료하고 간결한 문서 역시 프로그램 이해에 많은 도움이 된다.

프로젝트 위험관리의 핵심과 기법

위험관리의 핵심은 아직 발생하지 않은 위험을 어떻게 관리할 것이냐가 중요하다. 현장에선 이를 위해 발생하기 전에 발생을 예고하는 조짐을 관찰하고 통제해야 한다. 위험이 발현될 것임을 알려주는 신호를 위험전이 경계지표(Trigger) 라고 한다. 즉 경계지표는 위험이 현실화되는 촉발점인 것이다.

프로젝트에서 도출되는 산출물중 변하지 않는 산출물은 없고, 불확실성도 제거할 수 없다. 변경을 통제하는 것보다 변경의 종류/규모/빈도를 예측하는게 훨씬 효과적일수도 있다. 세상에 같은 프로젝트는 존재하지 않으며 정확한 일정계획과 비용계획은 수립할 수 없다. 대부분의 프로젝트는 일정과 비용, 품질을 모두 만족시키기 어려운 조건으로 진행되기 때문에 위험관리는 필요한 것이다.

< SW개발 프로젝트의 위험관리 프로세스 >

위험은 불확실성으로 인한 잠재적 문제점이 된다. 따라서 위험은 확률모델로 정량화해야 한다. 이때 활용할 수 있는 도구가‘Risk Rating Matrix Analysis’다. 이 활동이 정량화 분석처럼 보이긴 하지만 사실은 정성적 분석이다. 이것을 통해 영향력을 예상할 수 있으며 각 위험의 우선순위를 파악할 수 있게 되는 것이다.

< 요구사항의 유연성과 위험관리 가이드(예시) >

위험관리의 정의도 중요하고 분석도 중요하지만 위험관리의 핵심은 리스크 다이어그램이다. 특정항목에 대한 불확실성을 확률기반 다이어그램으로 표시하는 것이다. 이러한 리스크 다이어그램은 몬테카를로 시뮬레이션을 통해 도출할 수 있다.

< 리스크 다이어그램(예시)과 도구를 사용한 산출물 >

< 몬테카를로 시뮬레이션(예시) >

리스크 다이어그램의 불확정 구간의 크기는 개발프로세스에 얼마나 많은 노이즈(불필요성 등)가 포함되어 있는지에 따라 결정된다. 프로세스 노이즈는 과거의 위험이 프로젝트에 미친 영향을 정량화 하여 표시한 결과다. 과거의 경험이 불확정 구간의 크기를 결정하는 것이다. 바로 어제의 문제가 오늘의 위험(Risk)인 것이다. 위험은 불확실성으로 인한 잠재적 문제점이라는 것을 명확히 인지해야 한다. 따라서 위험을 말할 때는 반드시 확률과 리스크 다이어그램을 참조해야 한다. 많은 사람들이 이슈(issue), 제약(constraint), 위험(risk)을 혼동하여 위험관리를 제대로 못하고 있는 현실에서 아직까지 위험관리를 하고 있다고 말하고 표현하면서 확률모델을 사용하고 있지 않다면 위험관리를 하지 않고 있다고 볼 수도 있다.

프로젝트 위험과 이슈에 대한 개념

SW개발 프로젝트의 수행에 있어서 위험요소는 지금까지 수행된 모든 프로젝트에 내제 되어 있음에도 불구하고 위험요소가 지닌 불확실성(발생가능성, 영향도, 대안의 적합성 등)으로 인하여 위험요소들을 추적하고 관리하는 것은 매우 어려운 현실이다.

SW개발이 단순 패키지가 아닌 통합시스템이라는 부분까지 확장되는 현실에서 프로젝트 수행의 규모와 복잡성이 점점 커지고 있다. 대규모 개발조직이 장기간에 걸쳐 다양한 구성요소들을 개발, 통합하게 되면서 각각의 위험요소들이 기하급수적으로 증가하게 되고 프로젝트 수행시 효과적인 위험관리가 프로젝트 성공의 핵심요인으로 부상하게 된 것이다.

프로젝트 관리자가 뛰어난 사람인지 아닌지를 판단할 수 있는 방법은 여러 가지가 있다. 그중 하나가 위험관리에 대한 부분이다. 위험에 대한 정의가 명확한 편인데도 불구하고 현장에서는 위험(Risk)과 이슈(Issue)에 대한 구분이 어려운 상황이다.

< 위험과 이슈 >

위험은 아직 발생하지 않은 확률적 사건이고 이슈는 발생해서 프로젝트의 발목을 잡고 있는 문제점이다. 결국 위험이 발견되면 이슈가 된다고 볼수 있다. 이것이 위험관리와 이슈관리를 혼동하는 주요 이유이기도 하다. 이러한 위험은 관리되어야 한다. 위험이 추상적인 상태에서는 문제로 되기전(이슈화 되기 전)에 대응책을 생각해 내는 과정인 것이다.

새로운 프로젝트 일정관리 소개

일정관리는 프로젝트를 납기일 이내에 완료하기 위한 계획수립과 통제활동을 의미한다. 모든 활동의 시작일과 종료일이 정의된 것을 일정이라고 부른다. 또한 일정은 달력에 표시할 수 있어야 한다가 전제다.

프로젝트 실패의 요인 중 하나인 납기를 통제하고 프로젝트 갈등과 품질, 비용, 일정의 상관관계를 고려했을 때 가장 통제하기 어려운 자원중 하나이며 기간 산정의 불확실성, 자원의 제한성으로 인해 잘못된 가정을 수립할 확률이 높은 분야다.

SW개발 프로젝트의 일정관리는 프로젝트 관리에서 가장 기초적이고 관리적 요소가 가장 많이 들어가는 부분이다. 현장에서의 일정관리는 도구 또는 파일을 통해 진척사항을 관리하고 있지만 세부 태스크별 활동까지는 연계하고 있지 못하고 있다. 그렇기 때문에 현장에서 가장 이슈가 되고 있는 것은 일정관리의 진척율 또는 진행상황이 객관적이지 못하고 주관적으로 표기되는 것이다.

현장에서 사용하는 일정관리는 대부분 아래의 그림처럼 나타내어 질 것이다. 일정관리의 대표적인 도구는 마이크로소프트사의 MSPROJECT로 도구를 사용하던 엑셀을 활용하던 대부분의 표현방식은 아래와 같다.

< 현장에서 사용하는 일정관리 시트(예시) >

하나의 총괄시트에 WBS나 활동들을 기준으로 나열하는 방식으로 전체적인 일정관리가 쉽지 않다. 도구에 따라서 해당 활동을 누르면 자원과 담당자들이 기술되기도 하지만 도구를 활용한다는 측면에서 한눈에 보고 관리하기가 쉽지 않다. 특히나 보여주기식 관리 시트라 실제 프로젝트에서 활용한다기보다는 발주자나 관리자에게 보고하기에 적합하게 구성되어 있다.

완벽한 형태의 일정관리라기 보다는 기존의 방식에서 조금더 개선된 방식이라고 보면 될 것 같다. 새로운 방식을 이용해 보고 싶거나 이러한 스케줄링 방식을 활용하고 싶은 엔지니어들은 edwardtufte.com을 통해 확인할 수 있다.



일정관리에 있어서 가장 좋은 방법은 유사사례에 대한 벤치마킹과 일정관리 SW공학도구의 적절한 활용이 프로젝트 성공의 열쇠라고 말할 수 있다.

SW개발 비용의 산정

현장에서의 비용산정은 아직도 공수 아니 M/M 방식의 투입인력 카운트에 의지하여 진행되고 있다. 미래창조과학부(구. 정보통신부)의 권고에 따라 기능점수 방식을 활용한 것이 벌써 9년(’04년 2월, 구. 정보통신부 고시 제 2004-8호)이 지났다. ’12년 2월 SW사업 비용산정을 기능점수로 산정하라는 권고가 ‘SW사업대가의 기준 일몰제’에 의해 고시 폐지되고 민간이양 되었지만 기획재정부의 예산편성지침에 매년 SW사업 예산편성시 기능점수를 권고하고 있어 공공부문에서는 기능점수 사용권고가 아직 유효한 상태다.

과거 제 살 깎기 경쟁에 내몰린 SW업계의 애로 해소차원에서 사업대가기준 산정 주체를 정부에서 민간으로 바꾸었지만 개선(안)을 제시하지 못해 업계혼란이 가중되고 있다. SW사업대가기준이 민간으로 이양되어 신뢰성이 떨어져 발주기관과 사업자간의 비용산정시 갈등만 더 커졌다는 것이 업계의 주장이다.

그럼에 불구하고 비용산정을 수행해야 하는 현장에선 어떻게 반응하고 있을까? 일부의 경우긴 하겠지만 사업대가기준이 없어졌다는 것을 빌미로 발주자에게 그들이 사용하고 있는 투입인력방식을 제시하고 있는 실정이다. 투입인력 방식이 나쁜 것은 아니다. 투입인력 방식을 도출하는 과정에 문제가 있기 때문에 기능점수방식을 권고한 것이다.


현장에서의 투입인력방식은 단순 인력 카운트만을 수행하고 투입인력별 노력(effort)을 산정하지 않는데 문제가있다. 'effort'를측정하는단위가바로기능점수인것이다. effort를측정하는 단위는 본수, 스텝수, 코드라인, 기능점수 등으로 분류되는데 본수와 스텝수 방식은 주관적인 요소가 포함되고, 코드라인방식은 개발자 스타일에 따라 차이가 나게 되므로 국제 표준인 기능점수를 권고하게 된 것이다.

비용산정 모델의 측면에서 보면 인력수는 결과이지 과정일수 없다. SW개발 비용의 산정은 규모파악을 통한 소요공수와 투입자원 및 소요기간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 것이다. 발주자가 프로젝트 발주시 예정가격의 산정과 개발업자가
수주한 개발용역에 대하여 적정한 대가를 산정할 수 있는 기준으로 단위작업공수(비용)를 통한 총공수(총비용)를 산정하게 되는 것이다.

SW개발비를 산정할 때는 문제의 복잡도, 시스템의 크기, 신뢰도에 따라 프로젝트 요소를 고려하고 인적자원과 하드웨어자원에 대한 자원요소, 개발자 능력과 방법론에 따른 생산성 요소들도 고려하여야 한다.

< SW비용산정 모델시 고려요소 >

SW개발비용의 산정은 하향식 산정방법과 상향식 산정방법으로 나뉜다. 현장에서 가장 선호하는 방법은 하향식 산정방법으로 경험과 전문지식이 많은 개발자들이 참여한 회의나 토론을 통해 산정하는 방식이다. 하향식 산정방법은 전문가의 판단(expert judgment)과 델파이(Delphi)식 산정방법이 있지만 도출된 결과를 객관화하거나 정량화하기 힘들어 SW개발에서는 대략의 비용 사이즈를 도출할 때 많이 사용한다.

상향식 산정방법은 하향식 산정방법의 비과학성을 보완하기 위하여 개발할 시스템을 WBS 등으로 정의하고 각 구성요소에 대한 산정을 독립적으로 수행한 후 이를 합산하는 방식을 의미하며, 국내에서 가장 많이 활용되었던 SW사업대가기준에서 제시하고 있는 코드라인, 스텝수, 본수, 기능점수(FP) 등이 대표적인 방법이다.