SI프로젝트 빅뱅 오픈 왜 이렇게 항상 힘드나

SI프로젝트 빅뱅 오픈 왜 이렇게 항상 힘드나

거의 1년을 달려온 프로젝트가 저번주 금요일을 기점으로 오픈하면서 안정화 단계에 접어들고 있다.

덕분에 요 몇달간 블로그며 스터디며 개인생활이건 또 뒷전이 되버리는 상황이 벌어지고 말았다.

SI생활을 15년 가까이 해오면서 프로젝트 규모가 커지면 커질수록 오픈이 가까와지면 가까와 질수록 야근도 많아지고 , 먹는 욕도 많아지고.. 운동은 열심히 한다고는 하는데 체력도 예전 같지 않은지 몸도 마음도 더욱더 지쳐 만 간다.

해를 더해 갈수록 왜 오픈은 더 힘들어 만 지는걸까.. 개선의 여지는 진짜 없는것인가?

프로젝트 막바지 도대체 왜 이렇게 힘든걸까

![딴산](/content/images/2016/08/blog-1156232365.jpg)

그간 내가 직접 수행하거나 지켜봐왔던 프로젝트를 돌이켜보면, 정말 막판에 개발자들끼리 아름다운 Double욕이 오고가는 비참한 프로젝트부터 목표 했던 고지는 한라산인데 달나라까지 가야하는 수 없이 실패되거나, 맥빠지는 프로젝트들, 모두 광인이 되어 마치 영화 매드맥스의 광활한 사막에서 서로 죽고 죽이기를 반복하며 누가 악이며 누가 선인지는 중요하지 않는 네버 엔딩의 미친 프로젝트 들까지 수 없이 많은 프로젝트를 지켜봐 왔지만.. (물론 내가 수행한 프로젝트는 이정도 급은 아니었다 ^^;)

이러한 실패된 프로젝트 들의 대표적인 실패 요인을 개인적으로 분석해 보면 다음과 같다고 생각 된다.

  • 처음부터 잘못된 만남(계약)
  • 요구사항의 끊임 없는 변경
  • 개발방법론 선정의 문제
  • 내부 갈등, 리더쉽의 부재
  • 제대로된 아키텍처, 개발스킬의 부재
  • 고객과의 관계(정치)
  • 외부요인 (법이나 제약, 규제 등의 변경)
  • ...

여기에 무엇보다 이 여러가지 문제점 들에서 공통적으로 엮여 있는 가장 큰 문제점은 바로 ==제대로된 커뮤니케이션의 부재==가 아닐까 한다.

처음부터 잘못된 만남(계약), 요구사항의 끊임 없는 변경

그렇다! 난 너와 만나지 말아야 했어... 망하는 프로젝트의 전형은 아마 시작부터 잘못된 프로젝트 일 것이다.

공공SI사업의 경우에는 FP(Function Point, 기능점수)를 기반으로하는 나름 명확한 요구사항을 RFP에 담고 시작한다.

FP가 정답은 아닐지언정 어느 정도는 프로젝트 비용 산정에는 무리는 없을 수도 있다. 하지만 문제는 RFP 작성 당시 그 매우 짧은 시간에 50~100억 규모의 프로젝트의 전체 기능을 산정하기도 힘들 뿐더러 발주까지 한달 안에 그 규모를 파악하기도 매우 힘겨운건 명백한 사실이다.

발주 이후 사업자야 RFP 내용만 믿고 시작했지만, 고객의 한마디 한마디에 광인이 되어 가는 것이다.

사실 이건 내가 생각한 기능이 아냐 - 최모 고객

요구사항을 내는 부서가 IT를 잘 몰라서 그랬어 - 권모 고객

위에서 그건 아니래 - 김모 고객

다음 사업 하기 싫어? - Double욕 나오는 고객

내일이 오픈이니까 이건 해줘야지 - 와.. x발..

요구사항은 변경 될 수 있는 것이 당연하다. 하지만 문제는 변경의 규모는 책정된 비용 안에서 소화할 수 있느냐 없느냐가 판단되어야 한다.

요구사항 변경은 적절한 절차와 승인을 거쳐 변경 관리 되야 하는 것은 누구나 아는 사실이지만, 현실을 그렇지 않은 경우가 허다하다.

고객 입장에서는 "책임"의 소지가 있기 때문에 매우 애매모호한(이건 해야되는건지 안해야되는건지 판단 불가) 요구사항을 내기 일쑤고, 오픈이 내일인데 자기 입지를 위해 무리한 요구사항을 남발한다거나, IT를 진짜 잘 몰라서 구글이나 네이버 같은 사이트를 만들어내라는 요구사항을 아주 쉽게 던지는 경우도 많다.

회사 입장에서는 신규 고객 사이트의 발굴을 위해 무리한 입찰과 함께 다음 사업의 발판을 위한 프로세일즈랍시고 과도한 요구사항 변경과 추가 요구사항에도 도덕경에서 말하는 대원경지(大圓境智)를 이루어 모든 것을 다 받아 들이는 자비심을 무한히 베푸는 경우도 비일비재하다.

프로젝트 관리 방법론!?

SI현장에서는 아직도 수많은 프로젝트들이 전통적 폭포수 방법론을 기반으로한 변형된 방법론을 사용하고 있다. 최근에는 애자일 프로세스를 도입한 프로젝트들도 나오긴 하는 것 같긴한데 여전히 규모가 큰 프로젝트들은 폭포수 방법론을 기반으로 하는 방법론을 대부분을 사용하고 있다.

폭포수 방법론의 가장 큰 단점은 프로젝트 초기에 모든 요구사항과 일정, 자원에 대한 정의가 이루어지기 때문에 단계가 끝나고 다음 단계로 이전될 때 변경사항에 대해 능동적으로 대처하기 매우 힘들다는 것이다.

내가 생각하는 폭포수 방법론의 가장 큰 단점은 바로

개발에 들어가기 시작한다면 모든 변경사항은 위협이 되버리고 만다.

거기에 개발이 끝나갈 무렵에 요구사항 변경은 생각만 해도 왕짜증이 밀려올 정도로 스트레스가 되는 것이 현실이다.

제대로된 아키텍처, 개발스킬의 부재

뼈대가 훌륭하게 이루어져 있는 항공모함은 비바람이 몰아 쳐도 먼바다에서 묵묵히 임무를 수행해낸다. 프로젝트도 마찬가지 프로젝트 초기부터 견고한 아키텍처 설계에 힘쓰고, 변경에 능동적으로 대처해야 한다.

하지만 SI프로젝트의 현실은 그렇지 않다. 대규모 레거시 시스템의 유지/보수 사업이라던지 전사업의 남기고간 찌꺼기들 때문에 영롱하고 견고한 새로운 아키텍처를 설계하고 유지하기란 정말 쉽지 않다.

만들어내는 서비스나 프러덕트가 제대로 동작하는 것에는 관심 밖인 사업의 PM이나 관리자의 입장에서는 무엇보다 안전하게 프로젝트를 마치는 것이 지상 최대의 과제이기 때문에 더더욱 아키텍처의 변경은 힘들다.

머릿수 채우기에 급급한 외주 개발자들의 투입과 투입 된 개발자들 또한 이전 세대의 기술로만 계속 개발해 와서 새로운 개발 패러다임의 변화에 적응하지 못하고 갖혀 있는 경우가 허다하고, 계속되는 야근에 "더 이상 이 길이 나의 길인가" 혹은 "이 생활이 원래 이렇지"라는 고민만 깊어져 가는 것이다.

그래서 결국 사람..사람..그리고 사람..

프로젝트가 산으로 가는 이유에 대해서 주저리 주저리 말이 많았지만, 결국엔

프로젝트도 결국은 사람이 만드는 것이다.

우리 모두 슈퍼히어로는 아니기 때문에 아니 설령 아이언맨이나 캡틴 아메리카도 외계인의 침공엔 혼자서는 역부족이지 않을까.

요구사항 협상 실패, 고객에게 맥 없이 끌려다니기, 개발자들의 원성, 프로젝트 관리 실패...

이 모든 문제는 결국 커뮤니케이션 의 부재라고 생각된다.

어떻게 하면 문제를 해결 할 수 있을까? 치열하게 고민하고 또 고민하고 솔루션을 만들어 내는 고통스러운 작업들이 결국 프로젝트의 성공을 이끌어 내지 않나 싶다.

제대로된 RFP의 작성, 요구사항의 관리, 고객과의 협상, 견고한 아키텍처 설계, 내부 갈등 기타 등등 모든 문제는 상황에 맞는 적절한 대화로 해결이 가능하다고 생각되고, 그 대화라는 것에 집중하고 나가야할 목표에 프로젝트 구성원 모두가 같은 그림을 그릴 수 있는 리더쉽.. 그것이야 말로 프로젝트를 산으로 보내지 않는 키가 아닐까 생각한다.

그렇다면 개선의 여지는 없나?

AA팀 팀장을 하기 이전에는 개발자부터 개발PL까지 십수년간 프로젝트를 계속 해오고 겪어왔지만 한사람 개인의 힘으로는 어려운 상황을 이겨내기 쉽지 않는 것이 사실이다.

그래서 필요한 것이 개발 프로세스고 개발 문화라고 생각한다.

적절한 방법론의 선택

한번 성공한 프로젝트의 방법론이 다음 프로젝트의 성공을 100% 이끌어내진 못한다. 프로젝트마다 고유한 성격을 가지고 있기 때문에 그 프로젝트에 맞는 방법론을 고민해야봐야 한다.

애자일 방법론이 만병 통치약은 아니지만 적극적으로 Best Practice들을 도입해보고 실행해 보는 것도 방법이 될 수도 있을 것 같다.

개발 문화의 정착

효율적인 개발 문화라는건 사실 회사가 만들어 주는건 아니다. 구성원들 스스로가 자각하고 협심하여 만들어내는 것이다.

그러한 행동들을 발현할 수 있도록 만들어주는 장치들을 고민해야 한다.

사실 요새 스타트업들이 이런 무기(개발 문화)로 개발자들 많이 끌어모으고 있는 것 같은데 좋은 아이디어는 살짝 채용 해 보는 것도 방법일 것 같다.

무엇보다 공통의 목표로 이끌 수 있는 리더쉽

위에서 말한 그 무엇보다 프로젝트 구성원을 하나의 목표로 이끌 수 있는 리더쉽 능력 향상이 가장 필요할 것 같다.

나는 사이먼 시넥의 TED 강연(위대한 리더들이 행동을 이끌어 내는 법)을 예전에 보면서 깊은 감명까진 아니지만, 나부터 변화가 필요하다고 느꼈고, 그런 느낌을 주위에 전파하는 것에 주력했던 것 같다.

마무리

주저리 주저리 말이 많았지만 결론은 SI는 이제 그만둬야 하나??? 그럼 난 뭐 먹고 살 수 있을까?? ㅎㅎㅎㅎㅎㅎ

저 좀 데려가주실 분 없으신가요?

Read more

나의 프로그래밍 폰트 사용 일대기

나의 프로그래밍 폰트 사용 일대기

시작은 2003년 이제 막 프로그래머로써 첫발을 내딛을 때부터 나는 프로그래밍 폰트에 대해서 관심이 많은 편이었다. 화면 붙잡고 매일 글자들과 씨름하는 직업이다보니 당연하게도 좀더 눈에 잘 보이고, 보기에 좀더 미려하고 조화스러운 폰트를 찾는 것이 어찌보면 약간 본능(?)적으로 관심을 가졌던게 아닌가 싶기도 하고 말이다. 최근까지도 이 주체할 수 없는 본능에 따라

By Kevin H. Kwon
Istio 를 통한 path(url) 기반 Local Rate Limit 적용

Istio 를 통한 path(url) 기반 Local Rate Limit 적용

몇 년 전인지는 기억나진 않지만 Rate Limit 적용은 항상 애플리케이션 쪽에서 처리하는 것이 당연하다는 것이 주된 의견이었다. 그래서 그때 당시 Bucket4J 를 통해서 Spring 쪽에서 처리하고 했던 기억이 있다. 이제는 당연하게도 Istio와 같은 Service Mesh쪽에서 처리하는 것이 응당 맞다고 생각되는 것이 개발 세상이 이제 점점 더 클라우드향으로 이동된다는 느낌이다. 강력한

By Kevin H. Kwon
Istio를 통한 header기반 API 라우팅/호출 시 cors preflight request 이슈 트러블슈팅 기록

Istio를 통한 header기반 API 라우팅/호출 시 cors preflight request 이슈 트러블슈팅 기록

현재 개발하고 있는 일부 컨테이너 기반의 서비스들을 Istio를 통해 서비스들을 구성하고 트래픽을 관리하고 있다. 이때 컨테이너 서비스가 같은 규격이 여러개가 같은 url과 port를 할당 받아서 사용해야는 애로 사항이 있어 Istio에서 header 기반으로 특별한 헤더가 있는 경우에만 라우팅이 될 수 있도록 구성하고 테스트를 진행했었다. Istio Request Routing 예제와 같이 header

By Kevin H. Kwon