천객만래 [千客萬來] (It has an interminable succession of visitors)

IT 프로젝트의 현실
 
출처: 불분명
 
출처는 분명하지 않지만 인터넷에서 한참 유행했던 IT 프로젝트가 수행되는 현실을 극명하게 보여주는 그림을 하나 소개한다. 나는 이 삽화가 우리가 처한 프로젝트의 현실을 함축적으로 잘 표현하고 있다고 생각한다. 삽화의 의미를 내 관심에서 되새겨 보았다. 


(맨 위 왼쪽부터 설명해보면)

 

1 : 고객은 요구사항을 프로젝트 팀에게 간략하게만 설명한다. 자신의 요구사항을 다 이야기해주는 친절한 고객은 없다. 알아서 잘 해주기를 바라는 고객이 대부분이다.

 

2 : 프로젝트 리더(PL)는 고객이 말한 것을 자세히 파악하지 못하고 일부분만 어렴풋이 이해한다.(선반이 3개에서 1개로 줄었고 나무에 매다는 방식도 나뭇가지 양쪽에 각각 매다는 것으로 이해한다.)

 

3 : 업무를 분석하고 설계한 결과는 전혀 연관성이 없고 실제 구현되기 어렵게 디자인되어 있다. (나뭇가지가 땅에서 나오고 나무는 둘로 잘라져 있다.)

 

4 : 프로그래머가 짠 코드는 응집력이 떨어지고 나무에 매달 수 없을 정도로 축 늘어져 있다. 쓸데없는 코드로 가득하다.

 

5 : 영업은 고객에게 실현될 수 없는 장미빛 공약을 남발하여 프로젝트를 더 힘들게 한다. (세상에 대한민국에 안되는 게 어디 있냐마는 럭셔리한 의자를 가느다란 나뭇가지에 매달 수 있다고 허풍을 치다니.)

 

6 : 프로젝트 산출물은 납기준수라는 미명하에 거의 흔적을 찾아볼 수 없다.(흔적은 그림자만 남아 있어서 이해하기는 거의 불가능)

 

7 : 실제 구현되어 사용할 수 있는 프로그램은 거의 없고, 있어도 업무에는 별 도움이 안되는 프로그램들이다.(끈만 매달았으니 진척은 100%지만 실제 구현은 절반도 채 안된다.)

 

8 : 고객에게 청구하는 금액은 정확한 기준이 없이 들쭉날쭉하다. (마치 롤러코스트를 타는 것처럼 어쩔 때는 거의 공짜로 해주겠다고 하다가 만만한 고객을 만나면 과당청구하기도 한다.) 

 

9 : 회사에서 지원받은 건 전혀 없다. 어떤 문제가 발생하더라도 프로젝트에서 알아서 잘 해결하라는 미션 임파서블이 프로젝트의 목표이다.(지원을 받으면 오히려 나무를 자르게 되는 역효과가 크다.)

 

10 : 고객이 정말 필요한 것은> 아뿔싸, 고무 타이어가 튼튼하게 매달린 그네였다. 그렇다면 프로젝트의 운명은? 재개발 아니면 클레임이다.

 

정확한 현실 ->.,<-



Posted by SB패밀리
당신이 개발자라면 한 번 이상 생각해보자.
가능한 결론이 날 때까지...
나는 개발자로서 어떤 위치에 있고 사회는 어떤 위치를 원하고 있는지!



SI/SM 의 세계에서 개발자는 Coder < Programmer < Engineer < Architect < Consultant 로 성장하게 된다.

    물론 반드시 그렇지는 않지만, 의미적인 부분을 말하고자 하는 것이니 그것을 이해해주었으면 한다. 분류가 칼로 무 자르듯이 딱 떨어지지 않는 것은 당연한 것이다. 어떤 경우는 Engineer, Architect, Consultant 역할을 동시에 수행해야 하는 경우도 있다.

 

    1. Coder 란 코딩된 소스를 잘 이해하지 못하고 오려붙이기 하면서 단순히 소스를 만드는 사람을 의미한다. 어떠한 요구사항에 의해 프로그램을 만드는 것인지 알지 못하면 Coder 에 해당한다고 보면 된다.

   단순 작업에 해당하며, 고급 개발자도 때로는 이런 단순작업을 하기도 한다.

   Coder 는 고객을 만나지 않으며, PL 로부터 요청된 개발로직에 대해 Coding 업무를 수행한다.

 

    2. Programmer 란 기술적인 요구사항에 대해 스스로 그것을 처리할 수 있는 로직을 만들 수 있는 사람을 의미한다.

    프로그래머는 다양한 언어스킬을 가지고 있어야 하며, 때로는 소스 및 어플리케이션의 효율성을 높이기 위해 몇 개의 언어를 조합하여 사용할 수도 있어야 한다.

    또한, 프로그래머는 라이브러리 등 소스 수준의 것들을 조합하여 원하는 기능을 만들어내기도 한다. 프로그래머는 고객을 만나지 않으며, 기술적이지 않은 용어를 사용한 대화에 대해 익숙하지 않기 때문에 만난다고 하더라도 고객의 요구사항을 이해하지 못한다.

    또한, 자신의 의견을 고객에게 잘 인식시키지 못한다.

    단지, Coder 보다는 좀 더 쉽게 일을 줄 수 있고, 더 좋은 품질의 일은 하지만, 때때로 사람의 특성에 따라 반드시 Output 을 챙겨줘야 하는 경우가 있다.

 

    3. Engineer 는 프로그래밍에 대한 경험 뿐 아니라, 어플리케이션에 관계된 제반 제품(Product)에 대한 해박한 지식이 있어, 보다 완벽한 시스템을 구축하기 위해 이를 활용할 수 있는 사람을 의미한다.

    이 단계의 사람은 "Trouble Shooting"을 할 수 있다. 즉, 어플리케이션이 오작동하거나 에러를 낼 때, 오라클을 튜닝해야 할 지, 서버(H/W)를 튜닝해야 할 지, 웹로직을 튜닝해야 할 지를 알고 대처할 수 있는 사람들이다.

    엔지니어는 시스템의 전체적인 퍼포먼스와 조합을 위하여 부분적인 기능과 성능을 어떻게 해야할 지를 잘 아는 사람이다. 이는 프로그램에 대한 경험과 이해가 없으면 잘 해낼 수 없다.

   통상적으로 엔지니어란 전체적인 조화를 위해 시스템의 필수기능 이 외의 것을 튜닝하는 일을 한다.

   이 직능군의 사람이 없으면, 시스템 개발이 완료가 되더라도 부조화에 의해 시스템이 기존 Legacy 로부터 배척되는 현상이 발생된다.

   엔지니어는 고객 수준의 용어로 쉽게 대화할 수 있으며, 고객의 막연한 불만이 기술적으로는 어떻게 매칭될 수 있는지에 대한 경험을 가지고 있다.

   즉, 그들은 고객이 "웹이 이상해요." 라고 말하면, 어떻게 이상한지 잘 유도해서 묻고, DB나 소스, 아파치 등을 뒤져서 그 이상한 현상이 해결되도록 한다.

 

    4. Architect 란 하드웨어 제품군, 소프트웨어 제품군, 미들웨어 제품군, 데이터베이스 제품군까지에 대한 전반적인 이해를 바탕으로 업무특성에 맞게 어플리케이션을 중심으로 제품군을 배열할 수 있는 그림을 그릴 수 있는 사람을 말한다.

   이 사람들은 인터넷뱅킹처럼 실시간 트랜잭션 처리형(OLTP) 업무를 구현하는데 서버 한 두대를 넣는 구성을 절대 그리지 않는다.

   아키텍트는 고객과 잘 대화하는 수준을 넘어 고객의 사업 및 실무를 잘 이해한다. 즉, 업무가 월말에 한꺼번에 처리되는지, 일정산이 반드시 필요한지 등에 대한 이해를 바탕으로 시스템을 구축한다.

   고객의 업무를 듣고 트래픽 패턴을 분석하고, 소프트웨어 아키텍쳐,어플리케이션 아키텍쳐, 하드웨어 아키텍쳐를 결정하고 구현한다.

   이 직능군의 사람이 없으면, 시스템이 월초마다 이유없이 다운되기도 하거나, HW 증설을 해도 트래픽이 소화되지 않은 현상들이 일어난다. 또한, 용량확장 시 쉽게 이를 구현할 수 없다.

 

    5. Consultant 란 고객이 상상하는 비즈니스 모델을 현실화하기 위해 업무프로세스에서부터 시스템까지 모든 그림을 그려주고 이를 실행시켜주는 사람을 말한다.

    IT 와 함께 고려된 업무프로세스는 전통적인 산업기반에서는 존재하지 않는 것이어서, 언제나 새로 만들어지거나 업그레이드 되어야 하는데, 그들은 고객의 사업을 잘 이해하여 그 사업의 틀에서 서비스를 구현해주는 사람이다.

 만일 당신이 소규모의 온라인 쇼핑몰을 운영하고 싶다면, 컨설턴트는 회계관리에서부터 납품관리 및 홈페이지관리 등 모든 것을 상담하고 거기에 필요한 시스템을 납품하며, 잘 운영하고 있는지 사후관리도 해준다.

   컨설턴트는 "돈이 있는 사람들"을 위해 꿈을 현실로 만들어주는 사람들이다.

   비록 사업 결과에 대해서 책임지지는 않지만, 사업가가 성공할 수 있도록 파트너로서의 역할을 충실히 수행해 낸다. 컨설턴트가 없으면 고객은 처음부터 끝까지 스스로 알아서 해야 하며, 위험한 시기에도 쉽게 외부의 도움을 얻을 수 없다.

Posted by SB패밀리