프로젝트를 하면 분석/설계 기간에는 고객과 신경전을 벌이고, 개발 기간에는 밤샘을 하며 일하고, 테스트 때에는 무수한 버그와 싸우고, 끝날 즈음에는 산출물 작성에 바쁜 작업이라고 떠올릴 것이다. 그래도 프로젝트를 진행하고 나면 개발자들에게는 이력서에 경력사항 한 줄 더 들어가고, 프로젝트에서 배운 다양한 경험과 인간 관계가 자산이 된다.

​

그러나 프로젝트를 아무리 잘 해도 맨날 제 자리 걸음이거나 오히려 오점을 남겨 본인에게 치명적인 상처가 될 수도 있다. 필자 또한 사표까지 내야할 정도로 안 좋은 상황으로 간 적도 있었다. 그러한 경험을 되살려 이번 글에서는 자신의 능력을 100% 이상 발휘하고 회사에서 더욱 인정받기 위해서 프로젝트를 진행할 때 신경써야할 것에 대해 살펴보겠다.

​

프로젝트를 통해 업그레이드하자
프로젝트를 경험한 사람과 그렇지 않은 사람의 차이가 큰 이유는 프로젝트에서 기술적으로나 기술 외적으로 배우는 것이 많기 때문이다. 프로젝트에 들어가면 내공(기술적 자원)과 외공(기술 외적 자원)의 두 가지를 업그레이드할 수 있다.

​

숲을 보는 시야로 시스템을 보자
자바 기본 특성, 유닉스 환경 적응, 코딩 및 디버깅 등 실무에서 자바 프로젝트를 진행할 때 필요한 기술들은 지난 호에서 설명했다. 여기서는 나무가 아닌 숲이나 산의 레벨에서 시스템을 구축하는 데 필요한 기술을 세 가지 관점에서 살펴보도록 하겠다.

​

필자가 뻔한(?) 퀴즈를 하나 내겠다. 관리자와 개발자 4명이 있다. 오전에 서버가 죽었는데 모두 원인을 파악하지 못하고 있는 상황이다. 과연 어떤 개발자의 답변이 그나마 문제 해결에 도움을 주겠는가?

​

그러면 문제 발생에 대한 답은 어떻게 찾아 나서야 할까? 일단 매뉴얼이 있다면 해당 문제와 관련된 부분을 찾아서 해결을 하는 것이 좋다. 다음은 문제 해결의 첫 번째 방법들이다.

​

[1]시스템 구축 범위에 따라서
◆ 많이 구축하기를 바라는 사람
현업 : 웬만하면 손 하나 까딱 안 하고도 자기가 수동으로 했던 일이 자동으로 되기를 바란다.
PM : 때에 따라선 적게 구축해서 제때 끝내주기를 바라는 사람도 있다. 적이었다가도 아군이었다가도 한다.
◆ 적게 구축하기를 바라는 사람
시스템 운영자 : 이것저것 시스템이 복잡하면 운영하기 힘들기 때문에 적게 구축되면서도 에러가 없기를 원한다.
설계자 : 문서나 설계 툴에 시스템이 논리적으로만 맞게 반영하면 되지만 이것도 귀찮아서 웬만하면 적게 구축하기를 바란다.
◆ 시스템 구축 범위와는 관계 없는 사람
컨설턴트 : 말 몇 마디로도 웬만한 시스템은 만들어 버리므로 고객이 가끔 현혹된다.
영업 : 고객 측에서 주로 프로젝트의 뭔가가 맘에 안 들 때 영업 측에게 불평을 함으로써 프로젝트 관리자나 팀원에게 간접적인 압력을 행사하는 데 이용된다.

​

[2]시스템 개발 기간에 따라서
◆ 빨리 끝내주길 원하는 사람
현업 : 시스템이 빨리 오픈을 해야 자기가 써먹을 수 있으므로 빨리 되기를 바란다.
PM : 개발 기간이 지체되면 막대한 돈이 나가므로 빨리 끝낼수록 자기 회사에 이익이 된다.
◆ 시간이 많았으면 하는 사람
시스템 운영자 : 시스템이 구축되는 동안은 기존 운영시스템만 관리하면 되므로 개발 기간이 길면 그만큼 널럴하다.
설계자 : 시간이 많을수록 여유 있게 많은 것들을 반영할 수가 있다.
개발자 : 프로젝트 진행 관리상 늘 개발 기간은 앞의 설계 단계에서 까먹으므로 그냥 바라기만 할 뿐이다.
◆ 제때에 끝내주길 바라는 사람
영업 : 개발이 제때에 끝나야 자기 회사 사람들을 다른 프로젝트에 투입할 수 있으므로 제때에 끝내고 나오기를 바란다.
컨설턴트 : 프로젝트 초기 단계에서 구축 기간에 대한 자신의 컨설팅 내용이 맞아야 하므로 프로젝트가 제때에 끝나기를 바란다.

​

[3] 프로젝트 구축 문서에 대한 입장에 따라
◆ 문서에 명시된 대로 되기를 바라는 사람
아무도 없다. 현업은 그 이상을 바라고 PM, 개발자 등은 그 이하를 바라기 때문이다.
◆ 문서에 명시된 대로 안 되기를 바라는 사람
아무도 없다. PM, 설계자, 개발자는 그래도 문서에 기술되어 있는 만큼 최대한 반영하려고 노력한다. 이는 문서가 시스템 구축에 어떤 영향을 미치는지 알 수 있는 대목이다. 대부분의 사람들이 자신의 입장에 따라 문서를 유리하게 해석하려고 하고, 첨삭하기도 한다. 한편으로는 문서가 있음으로써 서로 다른 이해 관계를 가진 사람들간의 조율이 가능하다. 예를 들면 현업의 경우 문서에 하기로 했는데 안 했으면 엄청 화를 낸다. 그리고 문서에 하지 않기로 되어 있지만 나중에 필요하면 어떻게 해서든지 하게 만든다.

​

[4] 프로젝트 산출물에 대한 입장에 따라
◆ 산출물이 많이 나오기를 바라는 사람
시스템운영자 : 운영자 매뉴얼은 실제로 운영할 때 참고해야 하므로 중요하게 여긴다.
PM : 프로젝트에 적용된 방법론에 따라 각 단계별로 산출물이 나와야 한다.
컨설턴트 : 프로젝트 산출물을 종합하여 다음 프로젝트 컨설팅에 써 먹어야 한다.
현업 : 일단은 많이 나와야 회사에 시스템 구축 결과를 보고하기에도 좋다.
◆ 산출물이 적게 나오기를 바라는 사람
설계자 : 설계 관련 산출물은 어떻게든 이름을 붙여 요구하면 끝이 없으므로 꼭 필요한 것만 남기려 한다.
개발자 : 개발하기도 바쁜데 산출물까지 작성하게 하면 짜증이 날 정도이다.
◆ 산출물과는 관계 없는 사람
영업 : 산출물이 많으나 적으나 잘 끝나기만을 바란다.

​

[5]소프트웨어 개발 과정에 대한 시각
◆ 시스템의 개략적인 부분만 알면 세부적인 것은 쉽게 된다고 생각하는 사람
현업 : 개발 계획서상에 목표와 구축 완료일자만 명시하면 된다고 생각하며, 세부적으로 안 된 부분은 추가할 수 있다고 생각함
컨설턴트 : 시스템의 구성도나 아키텍처의 논리적, 물리적인 흐름만 맞으면 세부적인 구현은 개발 단계에서 충분히 가능하다고 생각함
PM : 시스템 구축에 필요한 우수한 성능의 HW, SW를 투입하고, 개발자를 많이 투입하기보다는 하루에 보다 많이 일하게 만들면 빨리 구축된다고 생각함
설계자 : 현업의 요구사항에 따라 필요한 기능을 설계에 반영하고, 안 된 부분 및 세부적인 것은 구현 단계에서 개발자가 충분히 커버할 수 있다고 생각함
영업 : 시스템의 구현에 문제가 생겨 개발이 지연되면 더 많은 개발자를 투입하면 된다고 생각함
◆ 시스템의 개략적인 부분보다 세부적인 것 때문에 고민하는 사람
시스템 운영자 : 실제 운영할 때 필요한 기술적 요소가 중요하다고 생각함
개발자 : 설계 단계에서 가능하다고 했던 것을 실제로 구현하기 위해 온갖 수단을 동원해서 고민함

​

입장 바꿔 생각해봐!
이렇게 프로젝트에서 맡은 역할에 따라서 서로에 대한 관심사가 다르다. 어떤 부분에서는 친구가 되었다가도 어떤 부분에서는 원수가 따로 없는 일이 계속 발생한다. 그렇기 때문에 앞에서 살펴본 바와 같이 그 사람이 어떤 부분에 관심이 있다는 것을 인정해주고, 자신의 입장을 얘기하는 자세를 가져야 원활한 커뮤니케이션이 된다. 특히 개발자는 고객, PM, 설계자, 시스템 운영자, 영업 등 모든 사람과 개발 전체 기간에 걸쳐 부딪치게 되므로 같은 말이라도 어떻게 하느냐에 따라 상대방에게 다르게 들린다는 것을 명심하자. 특히 개발자들은 앞의 대화의 예에서 보았듯이 기술적인 얘기를 고객, 관리자 등 기술에 대해서 전혀 모르는 사람들에게 장황하게 얘기하는 경우가 많은데, 이런 부분은 지양해야 하겠다.

​

상대방이 관심 갖는 부분을 먼저 대답하라
누구나 질문을 하면 자기가 듣고 싶어 하는 대답이 있다. 프로젝트에서는 앞에서 얘기했듯이 관심이 서로 틀리기 때문에 자기가 중요시하는 부분을 먼저 얘기하고 싶어 한다. 그러나 똑같은 얘기라도 조금만 생각하면 정말 다르게 보일 것이다.

​

[1] 일반적인 프로젝트에서의 대화
고객 : 회원 현황을 조회하는 화면이 필요합니다.
개발자 : 회원 현황을 어떻게 보여드릴까요?
고객 : 일단은 날짜별로 이름이랑 주민번호 정도로 보여줘 보세요.
<며칠 후>
고객 : 전체 가입자 수를 먼저 보여주고 날짜별로 보여줘야 할 것 같구요.

​

[2] 객관식으로 고객의 답변을 유도하기
고객 : 회원 현황을 조회하는 화면이 필요합니다.
개발자 : 일반적으로 당일 가입인원을 보여줄 수도 있고 아니면 전체현황을 보여주고, 날짜별로 보여주는 방법이 있습니다. 어떤 방법으로 보겠습니까?

​

관리자에게는 일목요연한 보고서를 적어라
이는 관리자가 주간 보고서를 왜 받는지를 생각해보면 쉬울 것이다. 먼저 그 주 동안 뭘 했는지를 알고 싶어하고, 특별한 문제점은 없는지를 알고 싶어 한다. 그리고 다음 주에 뭘 해야하는 지를 알고 싶어 한다. 또한 관리자는 보고된 내용을 상세히 읽어보고 판단하는 것보다는 한눈에 보고 직관적으로 판단할 수 있는 보고서를 원한다. 즉 카운팅을 해야 하는 부분은 합계만 취합해서 적어주는 것이 낫다. 한편 문제점(이슈) 부분은 관리자가 소상히 알아야 하는 부분이므로 간략히 적지 말고 잘 풀어서 상세히 적어주어야 한다.

​

프로젝트 참여 회사의 관계
갑을은 계약서에 나와 있는 고객과 고객에게 서비스를 제공하는 자를 의미한다. SI 프로젝트를 하는 회사간의 관계로 풀어서 얘기하면 갑은 고객사가 되고, 을은 고객사에 시스템 구축을 해주는 회사, 즉 대부분 대기업이 을이 된다. 보통 대기업은 관리 차원에서 SI 프로젝트에 필요한 모든 인력을 보유하고 있지 않고 필요한 인력은 외주업체를 통해 충당해 쓴다. 이를 아웃소싱이라고 하며 이때 대기업과 외주업체와의 관계 또한 갑과 을의 관계로 아웃소싱 계약이 체결된다. 그리고 최초의 고객사 입장에서 보면 갑(고객사) - 을(대기업) - 병(1차 외주업체)의 관계가 성립된다. 여기서 병에 해당하는 외주업체에서 구하지 못한 인력은 또다시 외주업체 또는 프리랜서와 계약을 체결하게 되고 이는 병-정으로 이어지는 관계가 된다.

​

여기서 금전적인 문제를 보면 갑에서 주는 돈은 을-병-정으로 내려갈수록 줄어들게 되는 것은 뻔한 이치이고, 일의 양은 더 많아진다. 프리랜서의 경우 아웃소싱 업체를 거치지 않고 을과 직접 계약을 체결함으로써 계약금액을 더 많이 받을 수가 있다. 어쨌든 갑을의 관계가 이러한 생리라면 어떤 위치에 있는 회사를 가야 낫다는 것은 따로 설명할 필요가 없으리라 생각한다. 이를 시장에서의 수요공급의 원리를 예로 들면 자바가 초창기에 나왔을 때 EJB기반의 ERP를 구축할 수 있는 사람이 월 2000만원을 받았지만 지금은 1/4도 안 된다. 아마도 SI 인력 구조도 이런 현상이 지속되다 보면 갑-을-병-정으로 갈수록 인원이 점점 줄어들어 IT 인력을 구하기 힘든 지경에 이르게 되고 대우가 점점 좋아지게 될 것을 기대하고 있다.

​

금액 책정은 월별 인원으로
프로젝트의 비용을 산출할 때 월별로 몇 사람을 투입하고, 그 사람마다 얼마씩 줄 것인지를 계산하게 된다. 한 사람에 대해서 몇 달 동안 일을 하게 할 것인가는 M/M(맨먼쓰 : Man/Month)로 나타낸다. 1M/M는 한 사람이 한 달 동안 투입된다는 것이고, 0.5M/M는 한달의 반, 즉 하루 걸러 나와서 일을 하거나 15일간만 일을 한다는 것이다.

​

M/M이 나오면, 그 사람에 대해서 계약을 할 때 매달 얼마씩 줄 것인지를 명시한다. 이때 따지는 것이 경력이 되며, 경력은 경력 기간, 자격증 유무, 학력 등에 따라 초급, 중급, 고급, 특급으로 분류된다. 대졸자를 기준으로 할 때 초급과 중급은 6년에서 나뉜다(여기서 필자는 그 사람이 정보처리기사 자격을 가지고 있다면 4년이 되면 중급 기술자가 된다는 것에 유념하길 바란다). 그리고 정보처리기사를 따고서 4년이면 정보처리기술사 응시의 자격이 주어진다. 정보처리기술사의 자격이 있으면 특급 기술자가 된다. SW 기술자 등급별 노임단가표에서는 특급기술사랑 기술사를 따로 분류하고 있지만 SI에서는 특급으로 쳐주고 있다. 자세한 내용은 한국소프트웨어산업협회 홈페이지를 참조하길 바란다.

​

연봉은 회사에다 벌어주는 만큼 올라간다
연봉은 바꾸어 말하면 자기가 회사에다가 얼마나 돈을 벌어주는지를 가늠할 수 있게 해주는 금액이다. 많이 벌어다 주면 그 만큼 많이 받기 마련이고 연봉대비 수익 비율이 클수록 연봉을 올릴 수 있는 여지가 많다. 또한 인력시장의 수요공급의 법칙에 의해 인력측면에 있어서 해당분야의 인력이 희귀할수록 그 만큼 대우도 좋고 연봉이 세어진다. 그리고 대부분의 직장인들은 자신의 연봉에 그리 만족하지 못한다. 그래서 늘 많이 받기를 원하는 게 현실이고, 회사측은 어떻게 해서든지 적게 주면서 회사에 붙들어 놓고 싶어 한다.

​

연봉은 무엇보다도 본인의 자질이 가장 중요하다. 자신의 몸값을 올리기 위해서는 인간성 및 기술력이 무엇보다도 뛰어나야 한다. 하지만 SI 프로젝트에서는 회사간의 관계, 프로젝트 인력 단가가 어느 정도 제한적인 요소로 작용한다는 것이다.

​

필자가 SI 업종을 택한 이유 중에 하나는 실력만 뛰어나면 고액 연봉과 스톡옵션을 받을 수 있을 것이라는 생각이었다. 그리고 당시에 벤처붐이 일어나 억대 연봉을 받는 사람이 많았다는 것이 더욱 그러한 생각을 하게 했다. 그러나 벤처붐의 거품이 빠지기 시작하고 실제로 이쪽에 몸을 담아 월급을 받아보니 꼭 그렇지는 않았다. 이는 자기가 아무리 뛰어나더라도 회사에서 줄 수 있는 돈의 한계는 정해져 있을 수밖에 없다는 얘기다. 바꿔 말하면 자기가 회사에 벌어다 주는 수익의 이내에서 연봉이 결정된다는 것이다. 이는 프로젝트에서 한 달에 회사에 가져다주는 금액에 따르며 이는 갑과 을로서 맺어지는 회사간 계약에 명시가 된다.

​

그래서 연봉협상은 먼저 회사와 자신이 얼마나 능력이 되는지를 알고 시도해야 한다. 일단은 자신이 얼마나 회사에 가져다 줄 수 있는지를 어느 정도는 파악해야 한다. 이는 앞에서 얘기한 내용을 이해하면 얼마나 될지가 어느 정도 파악이 될 것이다. 그리고 회사가 얼마나 자신을 활용해서 수익을 올릴 수 있는지도 가늠해야 한다.

​

괜찮은 회사 고르기 
회사 선택에 대한 기준은 취업 사이트에도 많이 있을 것이다. 그러나 여기에서는 그런 것은 제외하고 SI쪽 회사에서 고려해야 할 것들을 중심으로 얘기하겠다.

​

[1] 식당의 메뉴가 다양하게 많으면 딱히 맛있는 음식도 없다. 
중소기업의 경우 해당 사업 분야가 다양하면 그만큼 기술에 대한 전문성이 약해진다. 물론 대기업 쪽이야 사업부가 매우 많고 인력이 많아서 다양한 분야의 기술을 커버하지만 중소기업인데 사업 분야가 많고, 더군다나 각 분야 사이의 연관성이 떨어지는 사업을 하고 있다면 더욱 의심할 필요가 있다. 이는 마치 식당에 음식을 사먹으러 갔는데 그 집이 육고기 요리랑 물고기 요리를 모두 메뉴로 내놓으면서 전문인 것처럼 간판을 걸고 장사하는 격이다. 그래서 그 회사 하면 어떤 분야의 전문이란 것을 분명한 색깔을 가지는 곳이 좋다.

​

[2] 책상이 썰렁하면 하는 일이 별로 없다.
사무실의 책상만 보면 대충 어떤 일을 하는 회사인지, 어떤 것에 관심이 많은지를 알 수가 있다. 이는 면접시 살짝 파악하기 바란다. 책상 위에 전화기만 딸랑 있다면 영업에 주력한다는 것이다. 서적이 있다면 해당 분야에 관심을 많이 둔다는 것이다.

​

[3] 중소기업은 관리 부서가 커버할 수 있는 인력 규모 이내여야 한다.
필자는 중소기업에 근무하고 있으며 현재 4번째 회사인데, 대부분 20～30명 인력규모의 한계를 넘어서질 못했다. 중소기업의 경우 인원이 많아지면 그만큼 인력에 대한 관리가 느슨해진다. 필자가 아는 주변의 회사를 보면 무리하게 인원을 3자리수로 늘렸다가 나중에 영업 및 관리가 되지 않아 결국에는 정리해고 수순을 밟은 회사를 숱하게 봤다. 대부분의 중소기업의 관리부서 인원은 5명 이내이고 이들이 가장 효율적으로 관리할 수 있는 인원은 관리부서 인원의 4～5배수이므로 20～30명 이내 규모가 된다. 


관리 능력을 갖춘 개발자가 되길 바라며
예전에 TV에서 슈퍼 보안관이란 만화를 본 적이 있다. 거기서 보안관은 ‘곰같은 힘’, ‘매의 눈’과 같은 동물들이 가진 초인적인 힘을 지니고 우주의 사건을 해결한다. 만화 같은 얘기처럼 들리지만 개발자들이 순수하게 ‘코딩’만 하는 단순 코더의 한계를 뛰어 넘어야만 자신의 능력을 마음껏 발휘해서 프로젝트에서 제대로 인정받을 수 있다.
무엇보다도 개발자는 일반적으로 다음의 능력이 부족하다.