"SI프로젝트의 성공"은 적절한 인력과 자원으로 계획된 일정을 모두 소화하여 고객이 원하는 결과 시스템을 구축해 내는 것이다.
하지만, 개발자 개인에게는 조금 다른 성공의 의미가 부여되어야만 한다.
고객사는 언제라도 업체와의 거래를 끊을 수 있다. 개발자도 언젠가 다니던 회사를 나오게 될 수 있다. 대부분이 그렇다. 개발자 입장에서의 "SI프로젝트의 성공"을 생각해 보아야 한다.
개발자에게 SI프로젝트 성공 기준의 첫번째는 "성취감"이다. 그 밖에, 좋은 사람들을 만나고, 많은 것을 배우고, 새로운 경험을 얻고, 강제에 의한 야근 같은 한심한 행동을 하지 않으며 지냈다면 그 프로젝트는 개발자에게 있어 성공적이었다고 말할 수 있다. 물론, 이런 모든 것을 한번에 얻을 수 있는 프로젝트는 거의 없다.
'사람들과 트러블이 많았지만, 내가 생각하는 모든 것을 했다.'
'매일 야근을 해야하는 상황이었지만, 좋은 사람들과 즐거웠다.'
라는 식으로, 성공의 지표 가운데 하나라도 얻을 수 있으면 그나마 다행인 상황이다.
개발 본연의 업무 외적인 부분에서 힘들어하는 개발자들이 자신의 주위를 둘러보고, 자기가 처한 위험과 팀이 처한 위험을 이해하여, 각자의 상황을 보다 나은 방향으로 이끌고, 자신을 지켜낼 수 있기를 바라며, 개발자로서의 지속가능성을 높힐 수 있기를 바라며, 모두가 위험률을 산정하기를 바란다. 처음에는 지나치게 높게 책정된 위험률도 있겠지만, 우리는 어차피 내일을 알지 못한다. 단지, 내일은 오늘보다 나은 모습이 되어 있어야 한다는 것을 다짐할 뿐이다.
이 글에서 표현하는 위험률은 "자원 확보율 대비 업무량"을 의미한다. 굳이 "위험률"이라는 표현으로 시선을 끌어보려는 이유는 프로젝트 기간 내내 위험률의 변화를 포괄적으로 지켜보지 않게 되는 경우 80%까지 원만하게 진행되던 프로젝트가 어느 순간 부터는 재자리 걸음을 하게 되는 상황이 벌어질 수 있다는 것에 대한 경각심을 고취 시키기 위함이다.
위험률은 경제 원리에 따라 최소의 비용으로 최대의 효과를 얻으려는 고객과 개발업체 간에 있어, 자신에게 좀 더 많은 이익이 되도록 하기위해, 계약을 체결하는 상황에서 처음으로 발생하게 된다. 많은 SI프로젝트가 모든 스펙이 정확하게 확정된 상태에서 계약이 이루어지지 않는다. 기능, 성능, UI, 동작 등에 있어 업무량은 줄어들수도 있고, 늘어나게 될수도 있다. 물론 기술적인 부분에 있어서 생산성과 예상 할 수 있는 성능 이슈를 최대한 해결하는 방법으로 업무량을 줄일수도 있다. 개발 업체의 입장에서는 기술적으로 실질적인 업무량을 줄이는 방법을 고려하지 않고 공수를 산정하여 이 때의 위험률을 100%으로 하여 계약을 하는 것이 바람직하다. 이러한 방식은 대체로 가시화 된 자료를 고객에게 제시할 수 있어, 대략적인 금액으로 견적을 보낸 경쟁 업체에 비해 신뢰도 면에서의 경쟁력을 얻기도 한다. 하지만, 신뢰도를 높혀도 금액이라는 경쟁력 확보의 필요성도 여전히 남아 있게 된다. 이 때 고객은 네고를 요구하게 된다. 이제 최대 20% 수준에서 네고가 진행된다. 물론, 고객은 차기 프로젝트, 지속적인 협력관계, 또는 공동 개발을 미끼로 더욱 많은 네고를 요구하게 된다. 이 때 개발업체가 당장의 계약에서 금전적인 이익을 확보하겠다고 결정을 내렸다면 20% 이상의 네고는 벌어지지 않는다. 하지만, 고객이 던진 미끼에 더 큰 가치 비중을 둔다면, 그 이상의 네고나 공동개발로 계약을 진행하게 된다.
40%의 네고를 하고도 개발업체가 금전적인 이익을 얻게되는 경우는 많이 있다. 문제는 그 과정에서 터무니 없이 부족한 인력 배치, 현실을 무시한 기간 단축이 요구된다는 것이다. 검증되지 않은 인력, 근거 없는 기간 단축은 프로젝트의 성패를 개발자의 노력으로 충당하려는 행위라 할 수 있다. 분석과 설계에 80%의 노력을 기울여야 하고, 개발에 80%의 기간을 할애해야 하는 바람직한 SI프로젝트의 모습은 이미 망가지고, 개발이 진행되며, 잘못된 분석은 추가적인 요구사항을 만들어내고, 잦은 설계 변경을 발생시키고, 이미 개발된 모듈을 변경된 설계에 맞춰 재개발하게 되는 일이 벌어지게 된다. 그러다 어떻게든 80%의 완성도를 보이는 시점엔 설계를 변경할수도, 요구사항을 수용할수도 없는 상황이 벌어지고, 이후의 프로젝트는 제자리를 맴돌게 된다.
분석, 설계 및 요구사항 정의를 위해 필요한 4명의 선임 개발자가 1개월 간 선행 작업을 진행하고, 이들을 포함한 총 8명의 개발자가 4개월 간 UI 및 프로세스를 개발해야 하는 프로젝트에서 40%의 네고가 발생하면 선임개발자 2명에 후임 개발자 4명이 프로젝트를 진행하게 된다. 기간은 총 5개월에서 4개월로 단축된다. 위험률은 160%가 되었고, 60%의 요구사항을 반려하지 못한다면 프로젝트는 산으로 갈 것이다. 분석, 설계 기간은 2주로 단축되고, 충분하지 않은 분석 자료에 의해 설계된 아키텍쳐를 가지고 UI와 프로세스 개발이 시작된다. 4M/M가 필요한 분석, 설계를 1M/M로 처리하려다 보니, 오후 8시에 잡히는 고객과의 비지니스 회의에는 지친 몸으로 참여하게 되고, 고객사 업무 담당자들도 퇴근 시간이 지나 참여한 회의에 무성의하게 참여하게 된다. 하지만, 고객이 제공한 정보에 무언가 부족한 정보가 있다고 해도 다시 회의를 소집할 시간은 만들어지지 않는다.
위와 같이 근거 없는 네고만이 아니라, 가능한한 많은 비용 절감을 바라는 회사의 입장은 계약과 무관하게 작용하기도 한다. 일부 SI업체는 필요한 공수를 산정하고 비용을 추정하여 계약과 무관하게 프로젝트 비용을 할당한다.
소요 예상 경비 총액 2억5천만원안에 프로젝트를 완수한다. 회사가 어떤 이익을 얻는지에 대해서는 프로젝트에서는 관심을 두지 않는다. 이 금액에서 예산이 남으면 리더의 기여도로 넣는 경우도 있고, 팀원들에게 인센티브가 지급되는 경우도 있지만, 이러한 제도에도 불합리한 부분이 있어 아무런 보상 없이 회사의 이익으로 남는 경우도 있다. 이러한 경우는 리더가 재량적으로 추가적인 업무를 진행하여 잔여 비용을 소진하는 경우도 있다.
하지만, 대부분의 SI프로젝트에서는 계약된 금액에 비하여 일정 비율을 프로젝트 비용으로 산정한다. 아니, 산정 자체가 없는 경우가 대부분이다. 추가 인력이 필요하다고 하면 안된다는 결론을 내린다. 그래서 프로젝트가 진행되지 않는다는 것을 보여주면 2주가 지난 후에 추가 인력을 배치하도록 허가가 나고, 또 한 주가 지나야 추가 인력이 투입된다. 회사는 3주의 시간 비용을 아꼈지만, 초반에 방향이 결정되는 프로젝트에 있어서는 3개월 이상의 비용을 낭비한 것이나 다름이 없다.
충분한 비용을 지불하고 역할을 일임하려는 노력보다는 최소의 비용으로 책임을 전가하려는 노력이 자본주의적 합리주의로 받아들여지는 사회에서 이는 우리가 헤쳐나가야 할 또 하나의 난관임에 틀림 없다.
물론, 위와 같은 상황이 아니더라도 위험률이 높은 프로젝트는 어디에나 있다.
레거시를 포함한 요구사항 분석의 어려움, 충분한 검증을 거치지 않은 기술 도입, 팀이라 부를 수 없는 프로젝트 팀의 조직문화, SI에 적합하지 않은 성향의 개발인력 배치, 프로젝트 관리 및 리더쉽의 부재로 인해 위험률이 높아지는 것은 우리가 언제나 고민하고 관심있게 지켜봐야 할 대상이다.
어떠한 이유로든 위험률이 변화되는 추이를 놓히지 말아야 한다. 150%에서 출발한 프로젝트를 100%수준으로 끌어내리며 마무리할수도 있고, 80%로 출발한 프로젝트가 200%까지 올라가며 Drop 직전에 참여한 몇몇 개발자에 의해 120%로 마무리 되며 20%의 잔여 업무를 유지보수로 넘기는 경우도 있다. 위험률이 80% 미만이면 리더를 포함한 팀원들의 마음이 해이해지거나 개발자 간에 경쟁이 생겨나는 경향이 있다. 자신의 컨디션을 관리하지 않는 팀원, 다른 팀원과 경쟁하는 팀원을 관심있게 지켜봐야 하는 상황이 벌어지는 것이다. 위험률이 120%를 넘으면 어떤 개발자는 자신에게 책임이 돌아오지 않게 노력하는 경향을 보이기도 한다. 위험률이 140%까지 높아질 동안 업무에 소극적이고, 모르쇠로 일관하던 팀원이 위험률이 110%로 낮아지자 그제서야 프로젝트에 적극적으로 참여하는 모습을 봐야 하는 것은 결코 즐거운 경험이 아니다.
이렇듯 위험률은 누구나가 알면서도 간과하는 경향이 뚜렷하다. 위험률이 100%을 넘지 않는 수준에서 조직문화를 바람직하게 이끌 수 있는 범위로 위험률을 관리한다면 SI프로젝트는 결코 어렵지 않다. 그러다 보면, 위험률이 150%인 프로젝트를 만나도 프로젝트 기간 내내 위험률을 조금씩 낮춰가는 성취감을 만끽하며 원만하게 프로젝트를 마무리 할 수 있는 때도 올 것이다.
이렇듯 위험률은 누구나가 알면서도 간과하는 경향이 뚜렷하다. 위험률이 100%을 넘지 않는 수준에서 조직문화를 바람직하게 이끌 수 있는 범위로 위험률을 관리한다면 SI프로젝트는 결코 어렵지 않다. 그러다 보면, 위험률이 150%인 프로젝트를 만나도 프로젝트 기간 내내 위험률을 조금씩 낮춰가는 성취감을 만끽하며 원만하게 프로젝트를 마무리 할 수 있는 때도 올 것이다.
감당할 수 있는 수준의 위험률을 유지시킬 수 있다면 고객과의 지속가능성은 물론, 팀의 지속가능성도 확보 할 수 있을 것이다. 위험률이 낮아지는 것을 고객이 알게 되면 보여주기 위한 야근도 하게 된다. 이 때 위험률을 높혀서라도 의미 없는 야근을 막지 못한다면 이후 위험률의 관리는 불가능하게 될수도 있다.
지나온 길을 돌아보아 나아갈 길을 예측하는 것이 지속가능성을 확보하기 위한 한가지 방법이 될 수 있다. SI프로젝트의 지표로서, 추상적으로라도 위험률 추이를 지켜보는 것이 우리의 지속가능성을 확보하는 방법이라는 것을 생각해 보아야 할 것이다.
개발자 개인으로서도 자신과 팀의 위험률을 살펴야 한다. 자신의 위험률이 지나치게 낮고, 동료 개발자의 위험률이 지나치게 높을 때 아무런 행동을 취하지 않는다는 것은 스스로의 지속가능성을 포기한 행동으로, 동료 개발자가 처한 어려움은 머지 않아 자신에게 닥칠 위험이라는 것을 알고 동료 개발자, 인접한 팀의 어려움을 함께 해결해 나가려는 모습이 필요하다.
2014년 3월 17일 월요일
2014년 3월 8일 토요일
R&D, SI, SM의 비교
모든 개발자들은 R&D, SI, SM으로 나눌 수 있다. 이것은 마치 그림이 그려지는 과정과도 비슷하다.
R&D에서 캔버스를 만들고, 붓과 물감을 만들면 SI에서는 이것들을 가져다가 고객이 요청한 그림을 그린다. 이를 SM에서는 액자를 바꾸고, 덧칠도 하게 된다.
이 러한 이유로 R&D는 전산을 위한 전산을 하게 된다. R&D가 제공하는 재료들은 또다른 R&D 개발자에 의해 보다 발전된 재료로 재탄생하기도 하지만, 결국 SI 개발자들에게 제공되는 목적이 분명하다. R&D에 속하는 조직은 Microsoft나 Oracle과 같은 Major 업체에서 부터 SI를 병행하는 일반 기업의 R&D 조직도 SI를 위한, 즉 전산을 위한 전산을 하고 있는 조직이다.
그들의 주된 관심사는 새로운 기술이며, 그러한 기술이 널리 사용되기를 바라는 것이다. 자신들의 조직이 아닌 다른 전산 조직을 주 고객으로 하는 R&D는 .Net이 Java와 경쟁하듯 수많은 3rd Party 제품들의 경쟁이 치열하다. Borland와 같은 기업들은 이러한 경쟁에서 뒤쳐졌다 할 수 있으며, 수많은 3rd Party 업체들은 경쟁에서 뒤쳐져도 개발자들에게 기억조차 되지 않는다.
R&D는 새로운 기술을 접목 하는 것을 숙명으로 받아들이고, SI에서 쉽게 접근 할 수 있도록 객체기반으로 구현하게 된다. 모든 객체는 재사용이 가능하지만, 일단 캡슐화 되어 있고, 가능한 한 SI에서 추가적인 객체를 정의해서 사용하는 일을 최소화 하는 것이 그들의 제품에 대한 평가로 이어지게 된다. 그리하지 않아 SI에게 선택받지 못하는 R&D는 결국 시장에서 사라지게 되며, Borland에 비해 규모가 작은 조직은 누구에게도 기억되지 못한다.
R&D에서 구성된 제품의 모듈을 가져다가 SI에서는 Process를 구현한다. 추가적인 객체를 정의하지는 않는다. 이미 있는 객체를 수도 없이 재사용해서 구조적인 개발을 진행하게 된다. R&D에서 정의되었어야 할 내용이 정의되지 않아 SI에서 이를 추진하는 경우가 있는데, 이러한 경우를 Field Test라 할 수 있다. R&D가 SI에서 요구되는 부분을 정확히 숙지하지 못해 SI에서 부족한 부분을 감안하고 진행하게 되는 경우이다.
이러한 경우로는 많은 Major 기업들이 사용하는 Beta Version 공개가 있고, 자체 SI조직이 있는 경우는 고객사와의 공동 개발이 있다. 심한 경우는 완성된 제품으로 판매하고 있으면서 고객들의 불만을 수시로 제품에 반영하는 Alpha Testing이 있다. 현명한 SI조직은 이러한 Alpha Testing에 참여하지 않지만, 현명한 R&D 조직은 이러한 Alpha Testing에 참여하게 된다.
R&D의 조직원과 SI의 조직원이 새로운 기술에 대해서 언급하는 것은 사실상 R&D에서 SI로의 기술이 공유되는 차원이다.
새로운 기술을 성급히 실무에 적용해서 혼란을 주거나 전산을 위한 현업의 업무 중단이 발생하도록 하는 것은 SI가 선택해서는 안되는 것이다.
이렇듯 R&D가 객체지향 기술을 지향하고, SI가 구조적 프로그래밍을 지향하는 이유는 각각, 쉽게 사용될 수 있도록 하려는 노력과 하나의 커다란 시스템을 구축하기 위한 노력에 맞는 선택이다.
하지만, SM은 이와는 다른 현실에 직면하게 된다. 기존 모듈은 기존 프로세스로 남기고, 새로운 모듈을 추가하는 기능이다. 하지만, 기존 코드에는 영향을 주지 말아야 한다. 이러한 경우에 가장 안전한 방법은 기존 모듈과 신규 모듈을 완전하게 구분하는 부분에서 분기를 시키고 90% 이상 동일한 두개의 코드가 만들어지게 된다.
해당 시스템과 Process와 요구사항을 충분히 이해하고 있는 개발자라면 위와 같은 방식으로 업무를 처리하지는 않는다. 하지만, 담당자가 교체되고, 시스템이 일관성 있게 유지보수 되지 않게 되는 시점이 한번 벌어지기 시작하면 위와 같은 작업행태가 진행된다. 이후로는 그 어떤 개발자가 유지보수를 하더라도, 이를 원복할 방법이 없다. 이러한 코드를 순차 프로그램이라 한다. 이제 추가적인 요구 사항은 분기문으로 처리하고, 기존 모듈에 대한 변경 요구 사항은 이렇게 분기된 모든 코드들을 찾아 수정해 주어야 하는 상황이 된다. 그렇게 순차 프로그래밍이 계속되면 유지보수가 불가능한 상황이 된다.
새로운 요구사항이 반영되지 않고, 반영되더라도, 시간과 비용이 만만치 않게 되는 시점에 시스템은 재개발에 들어가게 된다. 이 때 해당 시스템 개발 건이 SI 시장에 매물로 나오게 되는 것이다.
R&D는 SI가 자신을 선택해 주지 않는다고 탓을 한다. 자신들의 제품이 새로운 기술들을 적용 했고, 생산성이 높고, 보다 안정적이고, 코드 분량을 줄일 수 있으며 복잡한 디자인 요구사항을 쉽게 충족시킬 수 있다고 말한다.
"그러냐? 어떻게 하면 되냐?"고 SI가 R&D에게 물으면,
"그것도 모르냐?"고 묻는다. 그러면 SI는 해당 제품이나 기능을 사용하지 않는다. 그런데, 사용하지 말아야 할 상황에서도 계속 사용하게 되는 경우가 있다.
제 품에 대한 메뉴얼이 빈약하고, 서비스가 신속하게 이루어지지 않고, 끊임 없이 심각한 문제의 이슈가 발견되어도 해당 제품을 사용하게 되는 경우가 많이 있다. 버려야 할 것을 버리지 못하고 진행되는 SI프로젝트는 개발자들의 무덤이 되기 쉽다.
R&D 와 SI 사이에서 벌어지는 문제는 SI와 SM 사이에서도 유사하게 벌어진다. 하지만, SM은 SI를 절대 버리지 않는다. 물론 프로젝트가 Drop 되는 경우는 있지만, 그것이 SM에 의해 결정되는 경우는 결코 없다. 하지만, SM에 의해 SI의 결과물이 거부될수도 있는 것이 SI가 R&D를 거부 할 때의 논리로 거부 될 수 있어야 한다.
아키텍쳐의 부재, 일관성 없는 코드 패턴, 의미 없는 코드의 난발, 유지보수를 위해 충분하지 못한 메뉴얼, 정규화되지 않은 데이터베이스, 시도때도 없이 다운 되는 시스템이지만 SM은 그러한 결과물을 군말 없이 받아들인다. 인공위성이 처음 쏘아 올릴 때 궤도를 잡기 위해 지나치게 많은 연로를 사용하면 수명이 단축되기 마련이다. 이럴 경우를 대비해 보험을 들고, 보험회사에 손해에 대한 비용을 청구하고 인공위성을 버리게 된다. SI프로젝트도 이쯤되면 결과물이 버려져야 하지만, 버려지는 경우는 거의 없다. 미국의 SI프로젝트 성공률은 16%라고 한다. 물론 이 수치는 모든 계획된 일정이 원활하게 수행되었고 고객의 만족도를 포함한 수치로 보아야 할 것이다. 하지만, 그 수치에는 SM의 결과물 검수 및 거부가 포함된 수치라고 보아야 한다.
"이것은 유지보수가 불가능하다."는 것을 말할 수 있는 SM이 존재해야만 한다. 프로젝트 전반에 걸쳐 SM은 자신이 유지보수 하게 될 시스템의 이해를 높히기 위해 검수를 진행해야 한다. 그리고, 필요하다면, 결과물에 대한 거부의 의사도 표현할 수 있어야 한다.
R&D는 SI에게 제품을 제공하고, SI는 SM에게 시스템을 제공한다. 제공받는 쪽에서는 자신이 넘겨받은 결과물이 부족하다면 넘겨받지 말아야 한다.
R&D 는 사람을 상대하는 것보다 전산에 빠지고 싶어하는 사람에게 적합하고, SI는 사람을 만나는 것을 즐기는 사람들에게 적합하고, SM은 일상을 즐기는 사람들에게 적합하다. R&D 개발자는 SI개발자를 보며 "사람을 상대하는 것이 지치지 않을까?"라는 의문을 종종 갖는다. SI개발자는 SM개발자을 보며 "똑같은 일상에 지치지도 않을까?"라는 의문을 갖기도 한다.
처음부터 개발자의 성향에 맞는 전산 분야는 이렇듯 구분되어 있다. 자신에게 맞는 전산 분야가 R&D인지, SI인지, SM인지를 알고 나아갈 방향을 찾아야 한다. 자신에게 맞는 업무분야에서 개발 업무를 한다면 그리 힘들지도 않은데, R&D성향의 개발자가 SI프로젝트에 참여하며 프로젝트를 흔드는 경우가 상당히 많다. SM성향의 개발자가 SI를 하면서도 스스로의 일상에 힘겨워 하는 모습을 보이기도 한다. 업무분야를 잘못 잡았을 뿐 그들의 실력이 부족한 경우는 거의 드믈다고 보면 맞다.
자신에게 맞는 업무분야를 찾는 것이 개발자로서의 즐거움을 만끽하는 또 하나의 방법이라는 것을 기억하자.
("오래 보아야 아름답다. 너도 그렇다.")
R&D에서 캔버스를 만들고, 붓과 물감을 만들면 SI에서는 이것들을 가져다가 고객이 요청한 그림을 그린다. 이를 SM에서는 액자를 바꾸고, 덧칠도 하게 된다.
이 러한 이유로 R&D는 전산을 위한 전산을 하게 된다. R&D가 제공하는 재료들은 또다른 R&D 개발자에 의해 보다 발전된 재료로 재탄생하기도 하지만, 결국 SI 개발자들에게 제공되는 목적이 분명하다. R&D에 속하는 조직은 Microsoft나 Oracle과 같은 Major 업체에서 부터 SI를 병행하는 일반 기업의 R&D 조직도 SI를 위한, 즉 전산을 위한 전산을 하고 있는 조직이다.
그들의 주된 관심사는 새로운 기술이며, 그러한 기술이 널리 사용되기를 바라는 것이다. 자신들의 조직이 아닌 다른 전산 조직을 주 고객으로 하는 R&D는 .Net이 Java와 경쟁하듯 수많은 3rd Party 제품들의 경쟁이 치열하다. Borland와 같은 기업들은 이러한 경쟁에서 뒤쳐졌다 할 수 있으며, 수많은 3rd Party 업체들은 경쟁에서 뒤쳐져도 개발자들에게 기억조차 되지 않는다.
R&D는 새로운 기술을 접목 하는 것을 숙명으로 받아들이고, SI에서 쉽게 접근 할 수 있도록 객체기반으로 구현하게 된다. 모든 객체는 재사용이 가능하지만, 일단 캡슐화 되어 있고, 가능한 한 SI에서 추가적인 객체를 정의해서 사용하는 일을 최소화 하는 것이 그들의 제품에 대한 평가로 이어지게 된다. 그리하지 않아 SI에게 선택받지 못하는 R&D는 결국 시장에서 사라지게 되며, Borland에 비해 규모가 작은 조직은 누구에게도 기억되지 못한다.
R&D에서 구성된 제품의 모듈을 가져다가 SI에서는 Process를 구현한다. 추가적인 객체를 정의하지는 않는다. 이미 있는 객체를 수도 없이 재사용해서 구조적인 개발을 진행하게 된다. R&D에서 정의되었어야 할 내용이 정의되지 않아 SI에서 이를 추진하는 경우가 있는데, 이러한 경우를 Field Test라 할 수 있다. R&D가 SI에서 요구되는 부분을 정확히 숙지하지 못해 SI에서 부족한 부분을 감안하고 진행하게 되는 경우이다.
이러한 경우로는 많은 Major 기업들이 사용하는 Beta Version 공개가 있고, 자체 SI조직이 있는 경우는 고객사와의 공동 개발이 있다. 심한 경우는 완성된 제품으로 판매하고 있으면서 고객들의 불만을 수시로 제품에 반영하는 Alpha Testing이 있다. 현명한 SI조직은 이러한 Alpha Testing에 참여하지 않지만, 현명한 R&D 조직은 이러한 Alpha Testing에 참여하게 된다.
R&D의 조직원과 SI의 조직원이 새로운 기술에 대해서 언급하는 것은 사실상 R&D에서 SI로의 기술이 공유되는 차원이다.
새로운 기술을 성급히 실무에 적용해서 혼란을 주거나 전산을 위한 현업의 업무 중단이 발생하도록 하는 것은 SI가 선택해서는 안되는 것이다.
이렇듯 R&D가 객체지향 기술을 지향하고, SI가 구조적 프로그래밍을 지향하는 이유는 각각, 쉽게 사용될 수 있도록 하려는 노력과 하나의 커다란 시스템을 구축하기 위한 노력에 맞는 선택이다.
하지만, SM은 이와는 다른 현실에 직면하게 된다. 기존 모듈은 기존 프로세스로 남기고, 새로운 모듈을 추가하는 기능이다. 하지만, 기존 코드에는 영향을 주지 말아야 한다. 이러한 경우에 가장 안전한 방법은 기존 모듈과 신규 모듈을 완전하게 구분하는 부분에서 분기를 시키고 90% 이상 동일한 두개의 코드가 만들어지게 된다.
해당 시스템과 Process와 요구사항을 충분히 이해하고 있는 개발자라면 위와 같은 방식으로 업무를 처리하지는 않는다. 하지만, 담당자가 교체되고, 시스템이 일관성 있게 유지보수 되지 않게 되는 시점이 한번 벌어지기 시작하면 위와 같은 작업행태가 진행된다. 이후로는 그 어떤 개발자가 유지보수를 하더라도, 이를 원복할 방법이 없다. 이러한 코드를 순차 프로그램이라 한다. 이제 추가적인 요구 사항은 분기문으로 처리하고, 기존 모듈에 대한 변경 요구 사항은 이렇게 분기된 모든 코드들을 찾아 수정해 주어야 하는 상황이 된다. 그렇게 순차 프로그래밍이 계속되면 유지보수가 불가능한 상황이 된다.
새로운 요구사항이 반영되지 않고, 반영되더라도, 시간과 비용이 만만치 않게 되는 시점에 시스템은 재개발에 들어가게 된다. 이 때 해당 시스템 개발 건이 SI 시장에 매물로 나오게 되는 것이다.
R&D는 SI가 자신을 선택해 주지 않는다고 탓을 한다. 자신들의 제품이 새로운 기술들을 적용 했고, 생산성이 높고, 보다 안정적이고, 코드 분량을 줄일 수 있으며 복잡한 디자인 요구사항을 쉽게 충족시킬 수 있다고 말한다.
"그러냐? 어떻게 하면 되냐?"고 SI가 R&D에게 물으면,
"그것도 모르냐?"고 묻는다. 그러면 SI는 해당 제품이나 기능을 사용하지 않는다. 그런데, 사용하지 말아야 할 상황에서도 계속 사용하게 되는 경우가 있다.
제 품에 대한 메뉴얼이 빈약하고, 서비스가 신속하게 이루어지지 않고, 끊임 없이 심각한 문제의 이슈가 발견되어도 해당 제품을 사용하게 되는 경우가 많이 있다. 버려야 할 것을 버리지 못하고 진행되는 SI프로젝트는 개발자들의 무덤이 되기 쉽다.
R&D 와 SI 사이에서 벌어지는 문제는 SI와 SM 사이에서도 유사하게 벌어진다. 하지만, SM은 SI를 절대 버리지 않는다. 물론 프로젝트가 Drop 되는 경우는 있지만, 그것이 SM에 의해 결정되는 경우는 결코 없다. 하지만, SM에 의해 SI의 결과물이 거부될수도 있는 것이 SI가 R&D를 거부 할 때의 논리로 거부 될 수 있어야 한다.
아키텍쳐의 부재, 일관성 없는 코드 패턴, 의미 없는 코드의 난발, 유지보수를 위해 충분하지 못한 메뉴얼, 정규화되지 않은 데이터베이스, 시도때도 없이 다운 되는 시스템이지만 SM은 그러한 결과물을 군말 없이 받아들인다. 인공위성이 처음 쏘아 올릴 때 궤도를 잡기 위해 지나치게 많은 연로를 사용하면 수명이 단축되기 마련이다. 이럴 경우를 대비해 보험을 들고, 보험회사에 손해에 대한 비용을 청구하고 인공위성을 버리게 된다. SI프로젝트도 이쯤되면 결과물이 버려져야 하지만, 버려지는 경우는 거의 없다. 미국의 SI프로젝트 성공률은 16%라고 한다. 물론 이 수치는 모든 계획된 일정이 원활하게 수행되었고 고객의 만족도를 포함한 수치로 보아야 할 것이다. 하지만, 그 수치에는 SM의 결과물 검수 및 거부가 포함된 수치라고 보아야 한다.
"이것은 유지보수가 불가능하다."는 것을 말할 수 있는 SM이 존재해야만 한다. 프로젝트 전반에 걸쳐 SM은 자신이 유지보수 하게 될 시스템의 이해를 높히기 위해 검수를 진행해야 한다. 그리고, 필요하다면, 결과물에 대한 거부의 의사도 표현할 수 있어야 한다.
R&D는 SI에게 제품을 제공하고, SI는 SM에게 시스템을 제공한다. 제공받는 쪽에서는 자신이 넘겨받은 결과물이 부족하다면 넘겨받지 말아야 한다.
R&D 는 사람을 상대하는 것보다 전산에 빠지고 싶어하는 사람에게 적합하고, SI는 사람을 만나는 것을 즐기는 사람들에게 적합하고, SM은 일상을 즐기는 사람들에게 적합하다. R&D 개발자는 SI개발자를 보며 "사람을 상대하는 것이 지치지 않을까?"라는 의문을 종종 갖는다. SI개발자는 SM개발자을 보며 "똑같은 일상에 지치지도 않을까?"라는 의문을 갖기도 한다.
처음부터 개발자의 성향에 맞는 전산 분야는 이렇듯 구분되어 있다. 자신에게 맞는 전산 분야가 R&D인지, SI인지, SM인지를 알고 나아갈 방향을 찾아야 한다. 자신에게 맞는 업무분야에서 개발 업무를 한다면 그리 힘들지도 않은데, R&D성향의 개발자가 SI프로젝트에 참여하며 프로젝트를 흔드는 경우가 상당히 많다. SM성향의 개발자가 SI를 하면서도 스스로의 일상에 힘겨워 하는 모습을 보이기도 한다. 업무분야를 잘못 잡았을 뿐 그들의 실력이 부족한 경우는 거의 드믈다고 보면 맞다.
자신에게 맞는 업무분야를 찾는 것이 개발자로서의 즐거움을 만끽하는 또 하나의 방법이라는 것을 기억하자.
("오래 보아야 아름답다. 너도 그렇다.")
PL의 SI프로젝트 발기문
PL의 SI프로젝트 발기문
새로운 프로젝트를 앞으로 6개월간 함께 진행하게 된 것을 기쁘게 생각합니다.
우리에게 주어진 과제는, 고객들이 처리하는 업무에 있어 능률을 높이고, 누락되는 처리
에 대해 알람을 띄우고, 패턴화 된 업무에 대해 자동으로 업무가 진행 될 수 있도록 패
턴을 정의하고 진행되는 통계를 보여 추가적인 패턴 정의가 필요한 지를 쉽게 파악할 수
있도록 하는 일입니다.
현재로서 확보된 리소스는 70% 수준으로 판단되지만, 구성된 프레임웍과 정의된 패턴으로
실질적인 업무량을 줄일 수 있다고 생각됩니다. 하지만, 업무가 상세화되는 과정에서 리소
스가 추가적으로 필요하다고 판단되면 PM에게 전달해 추가적인 리소스를 확보하거나 개
발 업무를 축소하여 진행하게 될 것입니다.
PM은 제너럴리스트로서 프로젝트(사업)를 통해 이익을 창출하는 역할을 하게 될 것입니
다. 추가적인 자원과 진행 일정을 관리하고, 영업적으로 풀어나가야 할 프로젝트 내외의
다양한 문제들을 감당하게 됩니다.
PL은 스페셜리스트로서 프로젝트의 결과물을 목표로 하여 할당된 자원을 절약하기 위해
자원을 배치하고, 업무를 할당합니다. 주어진 자원으로의 할당된 업무의 처리가 불확실
한 상황으로 판된되면 신속한 판단을 통해 PM과 공유하여 업무를 처리할 방안을 모색하
여야 한다.
개발자분들께 당부드릴 말씀은 자신에게 주어진 업무를 처리함에 있어 자신을 관리하시
라는 것입니다.
회사가, 프로젝트가 여러분들께 급여를 지급하는 것은 주어진 업무를 처리하기 위함입니
다. 또한 우리는 혼자서 일하지 않습니다. 자신이 모르고 있는 것을 부끄러워 마시고,
동료 팀원에게 언제나 질문하십시오. 팀이 이미 확보한 지식을 "개인적으로" 확보하기
위해 메뉴얼과 인터넷을 뒤지며 공부하는 것은 허락하지 않습니다. 그러므로 자신이 알
고 있는 지식은 언제라도 다른 팀원이 활용할 수 있도록 공개하십시오.
인사와 청소를 잘 하면 동료 팀원으로서 충분한 자질을 갖추었다고 인정됩니다. For문과
If문을 사용할 줄 알면 동료 개발자로서 충분한 자질을 갖추었다고 인정됩니다. 상대적
으로 뛰어난 커뮤니케이션 능력을 갖춘 팀원과 상대적으로 뛰어난 개발 기술을 갖춘 팀
원에겐 이미 보다 많은 급여가 지급되도록 약속되었습니다. 하지만, 상대적으로 많은 급
여에도 불구하고 팀 내 커뮤니케이션이나 기술 공유에 소극적인 입장을 취한다면 합당한
이유를 설명해야만 할 것입니다. 반면 동료 팀원을 팀 내 자원으로서 활용하는 입장에서
도 무한자원으로 생각하는 것은 곤란합니다. PM과 PL이 자원을 아끼고 소중히 여기는 것
처럼 모든 팀원이 서로의 시간과 노력을 아끼고 소중히 생각해야만 합니다.
오늘부로 공식적인 야근은 금지합니다. 그동안 프로젝트에 필요한 기술이나 적절한 3rd
Party 제품들을 여러가지 확인하고, 개발 프레임웍의 문제점을 파악하고, 고객의 성향
파악과 우리의 업무 분장을 위해 간혹 늦게 퇴근하는 일이 있었지만, 이제 야근은 금지
합니다. 공부는 끝났습니다. 프로젝트는 공부하는 곳이 아닙니다. 이후로는 개인적인 공
부를 위해서도 야근을 하여 팀의 분위기를 야근으로 몰아가거나, 다음 날 아침 정상의
컨디션이 아닌 모습으로 자리를 지키고 있거나, 자리를 지키지도 못하는 상황이 되는 것
은 부족한 업무 태도로 받아들여지게 될 것입니다. 또한 야근으로 이뤄진 업무 성과는
다음날의 성과를 오늘자 성과에 기록한 것 이상으로 보지 않을 것이며, 다음날의 성과가
부족한 것 또한 부족한 업무 처리로 받아들이게 될 것입니다.
회사와 프로젝트는 여러분들께 약속된 처우를 제공할 것입니다. 여러분들 또한 약속된
업무와 팀원으로서의 행동에 충실해 주실 것을 요청합니다.
프로젝트는 PM과 PL이 책임집니다. 개발자 한 사람이 프로젝트를 망칠 수 있도록 방관하
는 것은 PM과 PL의 책임입니다. 물론, 모든 개발자 때문에 프로젝트가 망쳐졌다면, 그것
은 아무런 의심없이 PM과 PL의 책임입니다. PM과 PL이 예상할 수 없는 행동은 삼가해 주
십시오. 뻔하게 행동해 주십시오. 언제라도 PM과 PL이 자원을 관리하고, 업무를 재배치
하고, 필요한 정보를 제공할 수 있는 상태를 유지해 주십시오. 그렇게만 해 준다면 누구
도 개발자를 탓하지 않겠습니다.
개발자가 책임을 지게 되는 경우는 한가지로 표현될 수 있습니다. 프로젝트 룸에 폭탄을
던지지 마십시오. 자신이 감당하지 못하는 일을 끌어 안고 있거나, 문제를 발견하고도
자신의 책임이 아니라고 생각되면 덮어버리거나, 심하면 자신이 철수한 뒤 얼마 후에 문
제가 되도록 코드를 남겨 놓는다거나, 아무도 모르는 백도어를 남겨 놓는다거나, 지나치
게 동료 팀원을 탓하고 우리의 목표를 흔드는 경우가 아니라면 개발자분들께 책임을 묻
는 경우는 없을 것입니다.
지금도 몇가지 표면화되지 않고 남아있는 리스크를 처리하다보면 리소스로서의 개발자분
들의 각각의 상태를 파악하지 못하고 놓히는 경우가 발생할지도 모르겠습니다. 언제라도
발견되는 문제에 대해서 전달해주시고, 자주 허심탄회 하게 이야기 할 수 있는 자리를
마련해 보겠습니다.
어차피 사람이 하는 일에 감정이 개입되지 않기란 결코 쉬운일이 아닙니다. 하지만, 감
정이 없다면 기계가 되고 말 것입니다. 보다 즐겁게, 보다 힘차게 일을 진행해 가다보면
개발자로서의 인생에 오래 기억될 프로젝트로 남을 것입니다. 불협화음은 어디에나 있기
마련이고, 이러한 불협화음을 없애는 것이 관건이 아니라, 어떻게 대처하느냐가 관건이
되길 바랍니다. 즐겁게 싸우고, 즐거운 여행이 될 수 있으리라 확신합니다.
우리 모두의 행복을 위하여~ 건배~!
(본 글은 2005년 PL을 맡아 추진했던 프로젝트에서 초반에 개발자들과의 술좌석에서 내가 했던 말들을 포함하여 정리한 내용이다. 내가 경험한 두번째로 위험했던 프로젝트가 결국은 내가 기억하는 가장 완벽했던 프로젝트로 남게 된 것을 나는 자랑스럽게 생각한다.)
새로운 프로젝트를 앞으로 6개월간 함께 진행하게 된 것을 기쁘게 생각합니다.
우리에게 주어진 과제는, 고객들이 처리하는 업무에 있어 능률을 높이고, 누락되는 처리
에 대해 알람을 띄우고, 패턴화 된 업무에 대해 자동으로 업무가 진행 될 수 있도록 패
턴을 정의하고 진행되는 통계를 보여 추가적인 패턴 정의가 필요한 지를 쉽게 파악할 수
있도록 하는 일입니다.
현재로서 확보된 리소스는 70% 수준으로 판단되지만, 구성된 프레임웍과 정의된 패턴으로
실질적인 업무량을 줄일 수 있다고 생각됩니다. 하지만, 업무가 상세화되는 과정에서 리소
스가 추가적으로 필요하다고 판단되면 PM에게 전달해 추가적인 리소스를 확보하거나 개
발 업무를 축소하여 진행하게 될 것입니다.
PM은 제너럴리스트로서 프로젝트(사업)를 통해 이익을 창출하는 역할을 하게 될 것입니
다. 추가적인 자원과 진행 일정을 관리하고, 영업적으로 풀어나가야 할 프로젝트 내외의
다양한 문제들을 감당하게 됩니다.
PL은 스페셜리스트로서 프로젝트의 결과물을 목표로 하여 할당된 자원을 절약하기 위해
자원을 배치하고, 업무를 할당합니다. 주어진 자원으로의 할당된 업무의 처리가 불확실
한 상황으로 판된되면 신속한 판단을 통해 PM과 공유하여 업무를 처리할 방안을 모색하
여야 한다.
개발자분들께 당부드릴 말씀은 자신에게 주어진 업무를 처리함에 있어 자신을 관리하시
라는 것입니다.
회사가, 프로젝트가 여러분들께 급여를 지급하는 것은 주어진 업무를 처리하기 위함입니
다. 또한 우리는 혼자서 일하지 않습니다. 자신이 모르고 있는 것을 부끄러워 마시고,
동료 팀원에게 언제나 질문하십시오. 팀이 이미 확보한 지식을 "개인적으로" 확보하기
위해 메뉴얼과 인터넷을 뒤지며 공부하는 것은 허락하지 않습니다. 그러므로 자신이 알
고 있는 지식은 언제라도 다른 팀원이 활용할 수 있도록 공개하십시오.
인사와 청소를 잘 하면 동료 팀원으로서 충분한 자질을 갖추었다고 인정됩니다. For문과
If문을 사용할 줄 알면 동료 개발자로서 충분한 자질을 갖추었다고 인정됩니다. 상대적
으로 뛰어난 커뮤니케이션 능력을 갖춘 팀원과 상대적으로 뛰어난 개발 기술을 갖춘 팀
원에겐 이미 보다 많은 급여가 지급되도록 약속되었습니다. 하지만, 상대적으로 많은 급
여에도 불구하고 팀 내 커뮤니케이션이나 기술 공유에 소극적인 입장을 취한다면 합당한
이유를 설명해야만 할 것입니다. 반면 동료 팀원을 팀 내 자원으로서 활용하는 입장에서
도 무한자원으로 생각하는 것은 곤란합니다. PM과 PL이 자원을 아끼고 소중히 여기는 것
처럼 모든 팀원이 서로의 시간과 노력을 아끼고 소중히 생각해야만 합니다.
오늘부로 공식적인 야근은 금지합니다. 그동안 프로젝트에 필요한 기술이나 적절한 3rd
Party 제품들을 여러가지 확인하고, 개발 프레임웍의 문제점을 파악하고, 고객의 성향
파악과 우리의 업무 분장을 위해 간혹 늦게 퇴근하는 일이 있었지만, 이제 야근은 금지
합니다. 공부는 끝났습니다. 프로젝트는 공부하는 곳이 아닙니다. 이후로는 개인적인 공
부를 위해서도 야근을 하여 팀의 분위기를 야근으로 몰아가거나, 다음 날 아침 정상의
컨디션이 아닌 모습으로 자리를 지키고 있거나, 자리를 지키지도 못하는 상황이 되는 것
은 부족한 업무 태도로 받아들여지게 될 것입니다. 또한 야근으로 이뤄진 업무 성과는
다음날의 성과를 오늘자 성과에 기록한 것 이상으로 보지 않을 것이며, 다음날의 성과가
부족한 것 또한 부족한 업무 처리로 받아들이게 될 것입니다.
회사와 프로젝트는 여러분들께 약속된 처우를 제공할 것입니다. 여러분들 또한 약속된
업무와 팀원으로서의 행동에 충실해 주실 것을 요청합니다.
프로젝트는 PM과 PL이 책임집니다. 개발자 한 사람이 프로젝트를 망칠 수 있도록 방관하
는 것은 PM과 PL의 책임입니다. 물론, 모든 개발자 때문에 프로젝트가 망쳐졌다면, 그것
은 아무런 의심없이 PM과 PL의 책임입니다. PM과 PL이 예상할 수 없는 행동은 삼가해 주
십시오. 뻔하게 행동해 주십시오. 언제라도 PM과 PL이 자원을 관리하고, 업무를 재배치
하고, 필요한 정보를 제공할 수 있는 상태를 유지해 주십시오. 그렇게만 해 준다면 누구
도 개발자를 탓하지 않겠습니다.
개발자가 책임을 지게 되는 경우는 한가지로 표현될 수 있습니다. 프로젝트 룸에 폭탄을
던지지 마십시오. 자신이 감당하지 못하는 일을 끌어 안고 있거나, 문제를 발견하고도
자신의 책임이 아니라고 생각되면 덮어버리거나, 심하면 자신이 철수한 뒤 얼마 후에 문
제가 되도록 코드를 남겨 놓는다거나, 아무도 모르는 백도어를 남겨 놓는다거나, 지나치
게 동료 팀원을 탓하고 우리의 목표를 흔드는 경우가 아니라면 개발자분들께 책임을 묻
는 경우는 없을 것입니다.
지금도 몇가지 표면화되지 않고 남아있는 리스크를 처리하다보면 리소스로서의 개발자분
들의 각각의 상태를 파악하지 못하고 놓히는 경우가 발생할지도 모르겠습니다. 언제라도
발견되는 문제에 대해서 전달해주시고, 자주 허심탄회 하게 이야기 할 수 있는 자리를
마련해 보겠습니다.
어차피 사람이 하는 일에 감정이 개입되지 않기란 결코 쉬운일이 아닙니다. 하지만, 감
정이 없다면 기계가 되고 말 것입니다. 보다 즐겁게, 보다 힘차게 일을 진행해 가다보면
개발자로서의 인생에 오래 기억될 프로젝트로 남을 것입니다. 불협화음은 어디에나 있기
마련이고, 이러한 불협화음을 없애는 것이 관건이 아니라, 어떻게 대처하느냐가 관건이
되길 바랍니다. 즐겁게 싸우고, 즐거운 여행이 될 수 있으리라 확신합니다.
우리 모두의 행복을 위하여~ 건배~!
(본 글은 2005년 PL을 맡아 추진했던 프로젝트에서 초반에 개발자들과의 술좌석에서 내가 했던 말들을 포함하여 정리한 내용이다. 내가 경험한 두번째로 위험했던 프로젝트가 결국은 내가 기억하는 가장 완벽했던 프로젝트로 남게 된 것을 나는 자랑스럽게 생각한다.)
피드 구독하기:
글 (Atom)