프로젝트에 필요한 인력

웹 서비스 프로젝트를 진행하기 위해서 개발자만 필요한 것은 아니다. 프로젝트 전체를 관리하는 사람, 각 파트별로 개발 일정을 관리하는 사람, 개발의 흐름을 관리하는 사람, 개발된 소스를 확인하기 위한 서버를 관리하는 사람, 테스트하는 사람 등 개발자외에 관리영역에 해당하는 사람도 다수 있어야 한다.

---

프로젝트 전체를 관리하는 사람을 PM (Project Manager) 라고 부른다. 일정이나, 인력 수급, 개발자의 편의, 개발 방향이 산으로 가지 않게 조절하거나, 발주사와 커뮤니케이션 또는 회의를 진행하는 역할을 한다. 프로젝트 팀 관점에서 발주사는 고객이기 때문에 이후 발주사를 고객으로 통일하겠다.

 

PM의 역할은 앞서 이야기 한것 처럼 중요한 위치이다. PM 성향이 고객 위주이면 개발자들이 힘든건 불을 보듯 뻔하다. 고객의 요구사항을 대부분 받아오기 때문에 고객에게는 좋은 사람, 괜찮은 사람, 일 잘하는 사람으로 보인다. 지금까지의 경험으로 고객 위주의 PM은 개발자들에게는 홀대하거나 소홀해진다. 당연, 개발자들에게는 불만이 쌓일 수밖에 없고, 개발이 원활하게 진행될리가 없다. 

 

고객 성향이 심한 PM의 경우에는 고객에게만 잘 보이기 위해, 고객이 추가로 요구한 사항을 그대로 다 받고 나서 개발자들에게는 공유하지 않고, 뭉개는 경우도 있다. 고객에게는 잘 진행되고 있다고 안정을 주면서 뭉개고 있는 것이다. 개발 막판에 와서야 왜 안했냐고 도리어 PM이 개발자들에게 화내는 경우도 있다. 이런 경우는 최악의 경우이다. 모든 책임을 개발자들에게 전가시키는 행위이다. 그런데 고객은 이미 PM편이기 때문에, PM을 옹호하고, 같이 했던 개발자는 실력이 없다고 판단해 버리는 경우도 있다. 

 

반면, 개발자 위주의 PM도 있다. 이분들은 고객과 싸움이 즐비하다. 대신 개발자들과는 사이가 좋다. 힘든 PM을 위로하듯 더 세심하게 개발에 임한다. 가끔 이런 PM을 만만하게 보는 개발자들도 있다. 일정에 맞추지 못하면 온갖 핑계로 무마한다. 너무 사이가 좋다보면 개발자들이 헤이해질 수도 있다. 결근이 잦아지고, 공과사를 구분하지 못하고 제 멋대로 행동하는 경우도 생긴다. 

 

발주사는 PM의 성향을 먼저 파악해야 한다. 

 

자신의 요구를 다 들어준다고해서 결코 좋은 PM은 아니다라는 것이다. 하도급법에 의해 발주사가 직접 개발자들을 컨텍하거나 일을 시켜서는 안되지만, 중간 결과물을 가지고 PM의 역량을 평가해야 한다. 

 

프로젝트의 성공 여부는 개발자의 실력을 떠나서 PM의 관리능력에 좌우된다. 

 

축구나 야구 경기에서 팀 성적이 낮으면 선수를 탓하기 보다는 감독의 역량을 탓하는 것과 같다. 그만큼 PM은 프로젝트를 리드 하는 중요한 역할이기에 나중에 개발자들이 실력이 없어서 성공하지 못했다는 건 자신이 실력이 없다라고 대놓고 이야기하는 것과 같다. 

 

PM은 중도가 필요하다. 

 

한쪽으로 치우치지 않고, 오로지 프로잭트에 집중해야한다. 아쉽게도 이런 사람을 만나기는 쉽지 않다. 기계가 아니기 때문에 인간관계를 무시할 수 없다. 

---

PM이 전체 프로젝트를 혼자서 관리할 수 없기 때문에 파트별로 관리하는 사람이 필요하다. 이 위치의 사람을 

PL (Project Leader) 라고 부른다. PL은 자신의 파트 개발자들에게 업무를 할당하고, 일정을 관리한다. 물론 PL자신도 개발에 참여해야한다. 

 

PL의 역할은 일정 관리도 있지만, 프로그램 품질 관리도 중요하다. 개발자들에게 프로그램 가이드와 개발 후 소스에 대한 품질도 체크해야 한다. 로그인을 하는데 1,2분 이상이 걸리면 소스 품질에 문제가 있는 것이다. 

 

PM은 관리 능력이 중요하기 때문에 개발자일 필요는 없지만, PL은 반드시 개발능력이 좋은 개발자여야 한다. 대부분 경력이 10년이상인 개발자가 담당하지만 개발능력이 좋고, 리딩할 수 있으면 중급정도도 담당하는 경우가 있다. - 솔직히 10년이상의 개발자라고 해도 능력이 없거나, 리딩이 안되는 사람도 허다하다. -

---

PM, PL이 프로젝트 전체를 관리하는 영역이라면, 프로그램 관점에서 관리하는 영역도 있다. 

 

프로그램은 집을 짓는 것과 비슷하다. 집을 짓기 위해서는 먼저 집을 어떻게 지을지 설계를 하고 도면을 작성해야한다. 설계와 도면 없이 짓게 되면 어떤 집이 나올지도 모르고, 짓는다해도 부실하게 될 가능성이 높다. 기획자가 도면을 작성하고, 디자이너가 집의 외관을 디자인을 한다면, 도면과 디자인이 집을 짓기에 가능한지, 어떤 재료를 사용해야 하는지, 어떤 건축도법을 적용해야하는지 등 튼튼한 집을 짓기 위해 재료의 선정이나, 방법을 선정하고, 기초 시공으로 튼튼한 뼈대를 만들어야 한다.

 

이런 재료 선정, 방법, 표준화, 공통 업무 개발 등 기초 공사를 튼튼하게 설계하고 만드는 사람을 AA ( Application Architect)라고 부른다. 영문으로 보듯이 어플리케이션(응용 프로그램) 건축가라는 의미이다. 초기 건축 설계가 잘못 되면 시공시 변경되는 부분도 잦아지고, 비용과 시간이 많이 들어가게 된다. 

 

문을 남쪽으로 만들었는데, 북쪽으로 변경하려면 도면부터 바꾸어야 하고, 디자인 또한 수정이 되어야 한다. 도면과 디자인이 수정되면 당연히 이미 만들어져 있던 문과 벽을 허물고 다시 만들어야 한다. 프로그램도 마찬가지다. 기획이 바뀌면 설계도 변경되야 하고, 설계가 변경되면 그동안 애써 만든 코드를 다시 만들어야 한다. 

 

AA역할이 중요한 반면, 이 역할을 간과하는 경우가 많다. 기간이 촉박하거나 소규모 프로젝트 경우에는 기획서가 나오면 간단한 설계 이후에 바로 개발이 들어가기 때문이다. 또는 미리 만들어 놓은 템플릿으로 디자인만 바꾸는 경우가 많다. 이런 경우는 턱없이 낮은 개발 비용으로 1달만에 또는 단 몇주만에 사이트를 만들어 준다는 광고가 대부분이다.

---

AA가 집을 짓기 위한 설계와 기초 공사를 하기 전에 집을 지을 땅을 매우고, 튼튼한 지반을 만들 토목 공사와 집으로 접근할 수 있는 도로를 만드는 등 집에 필요한 외부 환경을 설계해야 한다. 프로그램도 마찬가지로, 프로그램이 잘 수행할 수 있는 환경과, 프로그램으로 일반 사용자가 잘 접근할 수 있도록 선을 연결해야한다. 이러한 역할을 TA (Technical Architect)라고 부른다. 

 

도로도 없는 산속 골짜기 냇가 모래사장에 집을 짓는다면 냇가의 물이 조금만 불어나도 지반이 무너질 위험이 크고, 홍수라도 나면 흔적도 없이 사라진다. 도로도 없는 산골이라 사람이 찾아오기도 힘들 뿐더러, 집주인도 외부와는 완전 단절 된 채 지내야한다. 이런 집을 살기좋고, 좋은 집이라고 말하는 사람은 없을 듯 하다. 

 

프로그램도 마찬가지다. 프로그램이 잘 수행할 수 있도록 하드웨어가 튼튼해야 한다. 프로그램 2,3개 돌아갔다고 컴퓨터가 다운되버리면 아무짝에도 쓸모 없다. 또한 단순한 계산을 하는데 몇초나 걸린다면 컴퓨터로서의 의미가 없다. 게임을 하는데 버벅버벅 거리면 즐기기보다는 스트레스가 더 쌓인다. 이처럼 웹 서비스가 수행되는 컴퓨터도 사양이 좋아야 한다. 

 

또한 외부에서 10명 미만의 사람이 접속했다고 네트워크가 죽어버리면 이 또한 스트레스다. 유투브 영상을 보는데 5초마다 버퍼링걸리면 안보는 만도 못하다. TA는 네트워크 속도와 접속자 수까지 고려해서 컴퓨터와 네트워크 회선을 설계하고 설치해야한다. 

---

토지가 튼튼해지고, 충분한 도로도 연결되었고, 집도 튼튼하게 기초 공사 설계가 완료 되었다면, 내부에 방위 위치와 화장실의 위치 등을 고려해야한다. 현관으로 들어와서 거실이 있고, 방이 몇개에 어디에 위치해 있으며, 주방은과 화장실은 어디에 있는 것이 좋은지 동선과 각 방의 특징을 살려 배치해야 한다. 뜬금없이 화장실을 통해야 방이 연결될 수는 없다. 또한 수납할 수 있는 공간도 충분히 고려해야 한다. 화장실에 붙박이장이 있는 것도 이상하고, 방에 화장실용 수납공간이 있는 것도 이상하다. 거실에 옷을 수납하는 붙박이장도 이상하다. 공간에 맞게 수납할 수 있도록 설계하고 배치해야한다. 

 

프로그램에서는 이러한 배치와 수납공간을 DB (DataBase)가 담당한다. DB에는 Table(테이블) - 수납공간-을 만들고 잘 찾을 수 있도록 Column(컬럼) 또는 Field(필드)로 정리한다. 엑셀과 같은 형태라고 보면 이해가 쉽다. 엑셀의 시트(Sheet)가 Table(테이블)이고, A,B,C,D..이 되어 있는 열(Column)이 Column 또는 Field이다. 엑셀의 행(Row)도 마찬자기로 DB에서도 Row(행) 또는 Record(레코드)라고 부른다.

 

다시 돌아와서 이러한 수납할 수 있는 DB를 설계하고, 배치하고, 관리하는 사람을 DBA (DataBase Administration) 이라고 부른다.

---

튼튼한 토지에 집의 기초 공사를 하고, 도면에서 각 방의 배치와 용도를 설정하고, 수납할 수 있는 공간을 배치했으면, 이제 집을 짓는 일만 남았다. 실질적으로 집을 짓는 사람들은 개발자이다. 설계된 자료와 도면에 맞게 PL의 리드대로 개발이 진행된다. 

 

개발이 완료되면 바로 짠!하고 오픈하는 것이 아니다. 집을 다 짓고 나서 바로 주인이 들어와 살아도 되지만, 잘 지어졌는지 확인하는 절차가 있어야 한다. 도면 대로되어 있지 않다면 수정해야하고, 수정할 수 없으면 다른 방안을 찾고, 고쳐야 한다. 

 

이런 확인하는 절차를 담당하는 인원을 QA (Quality Assurance) 품질 보증이라고 부른다. 완료된 프로그램을 여러번 테스트하고 기획서와 다른 부분이나, 버그, 오류를 찾아내 프로그램의 품질을 올리는 절차이다. 프로젝트 막판에는 제일 중요한 인력이고, 충분한 테스트가 되지 않은 채 오픈하게 되면 수많은 오류와 버그가 발생하여, 신뢰도에도 문제가 생긴다.

 

웹서비스 프로젝트 하나를 만들기 위해서는 PM, PL, AA, TA, DBA, QA, 개발자 등 여러명이 투입되어 진행된다. 대규모 프로젝트 경우에는 PM도 여러명이 있고, PM을 관리하는 총괄책임자가 있다. PM이 여러명있는 대규모의 경우 PMO(Project Management Operate) 그룹을 만들어 진행된다. 

 

---