프로젝트를 하면 분석/설계 기간에는 고객과 신경전을 벌이고, 개발 기간에는 밤샘을 하며 일하고, 테스트 때에는 무수한 버그와 싸우고, 끝날 즈음에는 산출물 작성에 바쁜 작업이라고 떠올릴 것이다. 그래도 프로젝트를 진행하고 나면 개발자들에게는 이력서에 경력사항 한 줄 더 들어가고, 프로젝트에서 배운 다양한 경험과 인간 관계가 자산이 된다.
그러나 프로젝트를 아무리 잘 해도 맨날 제 자리 걸음이거나 오히려 오점을 남겨 본인에게 치명적인 상처가 될 수도 있다. 필자 또한 사표까지 내야할 정도로 안 좋은 상황으로 간 적도 있었다. 그러한 경험을 되살려 이번 글에서는 자신의 능력을 100% 이상 발휘하고 회사에서 더욱 인정받기 위해서 프로젝트를 진행할 때 신경써야할 것에 대해 살펴보겠다.
프로젝트를 통해 업그레이드하자
프로젝트를 경험한 사람과 그렇지 않은 사람의 차이가 큰 이유는 프로젝트에서 기술적으로나 기술 외적으로 배우는 것이 많기 때문이다. 프로젝트에 들어가면 내공(기술적 자원)과 외공(기술 외적 자원)의 두 가지를 업그레이드할 수 있다.
숲을 보는 시야로 시스템을 보자
자바 기본 특성, 유닉스 환경 적응, 코딩 및 디버깅 등 실무에서 자바 프로젝트를 진행할 때 필요한 기술들은 지난 호에서 설명했다. 여기서는 나무가 아닌 숲이나 산의 레벨에서 시스템을 구축하는 데 필요한 기술을 세 가지 관점에서 살펴보도록 하겠다.
[1] 구축 시스템에 관한 업무 지식
최상위 레벨로는 고객이 원하는 것이 무엇인지를 파악하는 업무 관련 지식이다. 개발자들이 업무 관련 지식이 없이 코딩을 하면 결국 테스트 단계에서 수정 요구 사항 및 에러 때문에 고생할 뿐만 아니라 설계자들이 시키는 대로 구현만 하는 단순 코더 업무를 벗어날 수가 없다.
[2] 업무를 구축하는 데 필요한 데이터베이스 구조
두 번째로는 업무 지식을 논리적?물리적으로 표현, 즉 설계된 데이터베이스 구조에 대한 이해이다. 실제로 고객이 요구하는 사항이 반영됐는지를 데이터베이스의 논리 및 물리 설계서를 검토함으로써 이뤄지고, 이를 토대로 애플리케이션이 작성되므로 이에 대한 이해는 필수적이다. 나아가서 데이터베이스 및 SQL 쿼리에 대한 이해도 매우 중요하다.
[3] 데이터베이스로부터 유저 인터페이스까지 데이터가 컨트롤되는 과정
세 번째로는 데이터베이스로부터 어떻게 유저 인터페이스로 데이터가 전달되고 다시 피드백이 되는지의 과정을 이해함으로써 더 우수한 성능과 정확한 기능을 발휘하는 코드를 만들어야 한다. 예를 들면 J2EE의 경우 JSP로부터 EJB를 호출하고 여기서 JDBC를 통해 DB에 액세스하는 기능을 알고 있어야 어느 부분에서 에러가 났고, 어떤 부분을 고쳐야 수정할 수 있는지를 알 수 있다.
 |
| <그림 1> 시스템을 보는 시각 |
자신이 모르는 걸 짚고 넘어가라
시스템에 문제가 발생했을 때 뭘 모르는 지도 모르고 무조건 두 손 들고 모른다고 말하면 진짜 모르는 것이다. 하지만 본인이 정확히 모르는 것을 인정하되 뭘 모르는 지는 분명히 알고 있다면 이는 문제를 정확히 파악하고 있는 것이며, 자문을 통해서 해당 문제를 쉽게 해결할 수도 있다.
필자가 뻔한(?) 퀴즈를 하나 내겠다. 관리자와 개발자 4명이 있다. 오전에 서버가 죽었는데 모두 원인을 파악하지 못하고 있는 상황이다. 과연 어떤 개발자의 답변이 그나마 문제 해결에 도움을 주겠는가?
Q. 관리자 : 오늘 아침에 서버가 죽었는데 어떻게 된 겁니까?
[1] 개발자 A : 서버가 언제 죽었대요?(상황 파악 전혀 못함)
[2] 개발자 B : 잘 모르겠는데요. 제가 안 죽였어요.(무조건적 책임 회피형)
[3] 개발자 C : 그거 서버가 맛이 간 거 아니에요? 전에도 뭐 좀 하려면 죽더니(보수형)
[4] 개발자 D : 로그를 보니깐 아침 9시 10분쯤 죽었던데, 에러 메시지가 'XXXX'라고 나오던데 무슨 의미인지 잘 모르겠습니다.
참고로 서버나 프로그램 에러가 나면 로그를 뒤지는 것은 프로그래머의 기본자세이다. 어쨌거나 자신이 이런 상황에 처하면 개발자 D와 같은 답변이 나올 수 있다고 확신하는가? 그런 확신이 들지 않다면 기본자세를 고민할 필요가 있다. 그렇지 않으면 문제 발생시 답을 정확히 구할 수 없게 된다.
그러면 문제 발생에 대한 답은 어떻게 찾아 나서야 할까? 일단 매뉴얼이 있다면 해당 문제와 관련된 부분을 찾아서 해결을 하는 것이 좋다. 다음은 문제 해결의 첫 번째 방법들이다.
[1] 주변 전문가
[2] 관련 매뉴얼
[3] 인터넷
- 해당 제품이나 기술의 사이트
- 검색엔진
- 해당 분야 커뮤니티 사이트 내 Q&A 코너
- 블로그 게시판
자문은 정성껏 구하라
앞의 해결 방법 중 많은 초보자들은 인터넷 게시판에 궁금증을 올려 해결하려고 한다. 필자가 하고 싶은 말은 인터넷 사이트에 질문을 올릴 때 단 몇 분만 더 투자해서 제대로 된 질문을 올리라는 것이다. 필자가 운영하는 사이트를 보면 매일 수십, 수백 건의 질문이 올라온다. 하지만 모호한 질문이 무척 많아 답변을 해주고 싶어도 못하는 경우가 종종 있다. 질문을 함에 있어서 그 글을 읽은 사람으로 하여금 답변을 하지 않으면 안 되게끔 정성껏 글을 써야 한다는 사실을 기억해야 한다. ‘그걸 누가 모르나’라고 말한다면 지금 게시판에 들어가 보라. 지금도 다음과 같은 질문이 쏟아지고 있다.
[1] Guest A : [제목]급합니다....!!!!
톰캣을 깔아서 보니 한글이 안 나와요. 아시는 분은 xxx@xxx로 메일주세요.
질문에서는 무엇을 모르는 것인지를 정확히 짚어주어야 하며, 특히 자신의 상황(프로그램적인 부분)을 정확히 설명해야 한다. 또한 자신의 바쁘고 급한 처지는 아무리 강조해봤자 소용이 없다. 특히 답변을 주면 사례하겠다는 등의 빈말은 더더욱 할 필요도 없다. 또한 처음부터 끝까지의 답변을 요구하는 너무나 포괄적인 질문도 자제해야 한다. 다음의 질문이면 만족스럽다.
[2] Guest B : [제목]톰캣5.0에서 한글이 깨집니다.
톰캣5.0을 설치하고서 xxx.jsp를 웹 브라우저에서 보니 한글이 깨져 나오네요. jsp의 html 태그에 있는 한글은 안 깨지는데, request.getParameter("xxx")로 받아오는 한글은 깨지는군요. 그렇다면 request.getParameter하는 부분을 다 고쳐야 하는 건지, 아니면 톰캣에서 한글이 안 깨지도록 설정할 수가 있나요?
정답만 알려주지 말고 컨설팅하라
누군가가 자신에게 질문을 해온다면 정답만 알려주지 말고 컨설팅을 하는 마음으로 알고 있는 것을 상세하게 설명할 필요가 있다. 물론 별도로 부연설명을 안 해도 충분히 알 것 같은 내용은 그럴 필요가 없겠지만 개발자 외에 관리자나 고객이 어떤 현상에 대해 질문을 했을 때에는 그 사람이 알아들을 수 있게 충분한 설명 및 현상에 대한 원인을 얘기해 주는 것이 좋다. 다음의 예를 보자.
◆ 질문 : 오늘 아침에 이번 달 매출액을 조회했더니 페이지가 안 나오던데 원인이 뭐 때문입니까?
[1] 개발자 A : 아침에 WAS가 죽어서 그랬어요.
[2] 개발자 B : DB나 웹 서버 등 다른 서버는 이상이 없었구요. WAS 로그를 보니깐, 그 시간대에 xxx.jsp를 수행을 하다가 서버가 다운된 것 같습니다. 그리고 xxx.jsp를 코드를 보니 DB 자원을 무리하게 많이 쓰는 코드가 있는데, 이 부분이 의심스럽고, 메모리가 모자라는 것 같으니 WAS의 힙 메모리 설정을 확인해봐야 할 것 같습니다.
코딩 외에 업무에 중요한 것들
개발자들에게 가장 중요한 것은 개발(코딩)이지만, 개발을 위해 필요한 다양한 활동에도 적극적인 자세로 움직일 필요가 있다. 이는 관리자 및 고객들이 개발자의 자질로 평가하는 중요한 항목으로 향후 프로젝트나 회사 내 인사에서 지대한 영향을 미친다. 특히 프로젝트 중간에 회의 때마다 작성하는 회의록이나 주간보고서 등은 그 사람이 얼마나 성실히 프로젝트에 임하고 있는지를 가늠하게 해준다. 그리고 이러한 문서는 나중에 프로젝트 관련한 진행의 기록되므로 고객이 불합리하게 요구하는 것을 막을 수 있다. 또한 회의 때 자신의 의견을 논리적으로 말하는 능력은 남들에게 자신 및 자신의 능력을 신뢰할 수 있도록 해준다.
[1]프로젝트 관련 문서 작성
회의 참석 전에는 자신이 의견을 낼 자료가 있다면 미리 출력하거나 메일로 회람하게 만들어서 다른 사람들이 미리 대비할 수 있도록 배려한다. 그리고 회의 참석시에는 참석일시, 참석자, 관련된 쟁점 및 논의 사항을 노트에 기록하고, 회의가 끝나면 회의록을 작성해 참석자들에게 확인받는 습관을 들인다. 주간보고서는 관리자로 하여금 그 사람이 어떤 일을 하고 있는지, 어떤 문제가 있는지, 다음 주의 계획이 무엇인지를 알 수 있도록 주중에 한번 정기적으로 보고하는 문서이다. 가장 중요하지만 실제로 개발자들은 별 생각 없이 간단히 쓰고 마는 경우가 있는데, 이렇게 되면 관리자는 그 사람이 일을 안 하고 있다고 생각할 게 뻔하다.
[2] 프리젠테이션 능력
개발자가 프로젝트에서 몇 번이나 발표를 할까 하는 의문이 들지도 모르는데, 회의를 하다보면 자신의 의견을 앉아서 말하기보다는 화이트보드나 프로젝션을 통해 의견을 말해야 효과적일 수가 있다. 이럴 때 자연스럽게 나와서 자신의 의견을 논리적으로 말하는 습관을 들이면 그 사람에 대한 기술적 신뢰가 두터워질 것이다.
의사소통의 원할함이 프로젝트를 좌우한다
프로젝트에서 사람간의 커뮤니케이션은 가장 중요하다. 왜냐하면 시스템은 결과적으로는 SW가 아니라 사람이 구축하는 것이기 때문이다. 사람간의 의사소통이 잘 되어야 원하는 모양의 시스템이 만들어질 수 있으며, 프로젝트의 규모가 클수록 더욱 그러하다. 그래서 막연히 우수한 성능의 SW, HW와 경험이 많은 사람들을 투입해서 프로젝트를 했다가도 실패하는 이유가 커뮤니케이션이 제대로 이루어지지 못해서인 경우가 많다.
프로젝트는 커뮤니케이션의 문제를 안고 시작한다
프로젝트에서 커뮤니케이션에 문제가 발생할 수밖에 없는 이유는 구축을 원하는 사람(고객), 구축을 진행?관리하는 사람(관리자), 실제 구축을 하는 사람(개발자)이 커뮤니케이션을 해야 하기 때문이다. 이 세 부류간의 커뮤니케이션 문제는 『화성에서 온 남자, 금성에서 온 여자』라는 책에서 다루는 남자와 여자간 대화의 근본적인 문제점에 비유될 수 있다. 즉 고객과 관리자, 개발자는 각기 시스템을 보는 시각이 다르고 시스템을 표현하는 방식이 다르다. 개발자는 개발하는 방법에 관심이 있는 반면에 관리자는 개발하는 과정에 관심이 있으며, 고객은 개발된 시스템 자체에 관심이 있다. 서로 상대방이 중요시하는 분야에는 관심이 없고, 자기의 시각에서 말을 한다는 데에 문제를 안고 있다. <그림 2>에 개발자, 관리자, 고객이 서로 시스템을 바라보는 시각을 나타내었다.
 |
| <그림 2> 시스템을 바라보는 시각 |
실제 프로젝트에서 서로 대화할 때는 이들 사이의 의사소통이 안 되어 양측 입장을 잘 아는 사람이 통역하는 모습도 본 적이 많다. 예를 들면 다음과 같다.
고객 : 초기화면에서 여기를 클릭하면 왜 다음 페이지로 안 넘어가나요?
개발자 : 그건 별거 아니구요. xxx.jsp에서 파라미터가 yyy.jsp로 안 넘어와서 그런 겁니다.
고객 : 아, 그러니깐 왜 안 되냐구요?
개발자와 고객사이 통역자 : 초기화면에 클릭하는 부분을 간단히 고쳐주면 다음 페이지로 넘어갈 수 있답니다.
고객 : 그럼 얼마나 걸리죠?
개발자 : 파라미터 세팅만 되면 되는데요.
관리자 : 그러니까 얼마나 걸리냐구요?
개발자와 관리자사이 통역자 : xxx.jsp에서 뭔가 문제가 있는데 이걸 해결해서 yyy.jsp를 보려면 얼마나 걸리나요?
개발자 : DB에 테스트 데이터도 들어가야 되고, 코드도 약간 수정만 하면 되는 데요.
관리자 : 얼마나 걸리는지를 얘기하라니깐요?
개발자와 관리자사이 통역자 : DB도 좀 고쳐야 하고, jsp도 수정해야 한다하니 오후쯤이면 가능하겠죠?
색안경으로 시스템을 바라본다?
프로젝트에 참여하는 사람을 역할에 따라 세분해서 분류해 보면 다음과 같다. 이외에도 SW 기술지원이나 PMO(프로젝트 관리 조직) 등이 있는데 이들은 프로젝트 구축에 있어 지원하는 조직이므로 제외하고 설명하겠다.
[1] 현업 : 현업은 SI 프로젝트에 있어 고객에 해당한다. 실제로 그 시스템을 사용하는 입장에서 기능적인 요구사항을 설계자 및 관리자에게 얘기해서 구현되도록 구축하는 사람이다.
[2] 시스템 운영자 : 고객사에서 시스템을 기술적으로 운영해주는 사람들로서 시스템 운영자는 현업과 소속이 같으면 프로젝트에서 현업에 준하는 영향을 준다.
[3] 프로젝트 관리자(PM) : 프로젝트의 시작부터 끝까지 책임지고 해당 기간 내에 시스템이 완성될 수 있도록 관리하는 사람이다.
[4] 컨설턴트 : 프로젝트가 구축되기 전에 고객에게 시스템의 청사진을 그려내어 시스템을 어떻게 구축하고 활용할 것인가의 전반적인 문제를 컨설팅해주는 사람이다.
[5] 영업 : SW나 HW 외에 개발자 인력 리소스를 공급해주는 사람으로 중소기업 협력업체 영업대표(조그만 회사의 경우 사장이나 이사)가 해당된다.
[6] 설계자 : 시스템의 기능을 논리?물리적으로 구현하기 위한 데이터베이스의 구조를 디자인하는 사람으로, 고객사의 업무에 대해 잘 알고 있는 사람들이 담당한다.
[7] 개발자 : 설계자에 의해 설계된 내용을 애플리케이션으로 구현하는 사람이다.
앞에 분류한 사람들은 프로젝트를 진행함에 있어 보는 시각이 틀림으로 인해 서로간의 마찰이 늘 발생한다. 어떤 관점에서 이런 문제가 일어나는지를 살펴보자.
[1]시스템 구축 범위에 따라서
◆ 많이 구축하기를 바라는 사람
현업 : 웬만하면 손 하나 까딱 안 하고도 자기가 수동으로 했던 일이 자동으로 되기를 바란다.
PM : 때에 따라선 적게 구축해서 제때 끝내주기를 바라는 사람도 있다. 적이었다가도 아군이었다가도 한다.
◆ 적게 구축하기를 바라는 사람
시스템 운영자 : 이것저것 시스템이 복잡하면 운영하기 힘들기 때문에 적게 구축되면서도 에러가 없기를 원한다.
설계자 : 문서나 설계 툴에 시스템이 논리적으로만 맞게 반영하면 되지만 이것도 귀찮아서 웬만하면 적게 구축하기를 바란다.
◆ 시스템 구축 범위와는 관계 없는 사람
컨설턴트 : 말 몇 마디로도 웬만한 시스템은 만들어 버리므로 고객이 가끔 현혹된다.
영업 : 고객 측에서 주로 프로젝트의 뭔가가 맘에 안 들 때 영업 측에게 불평을 함으로써 프로젝트 관리자나 팀원에게 간접적인 압력을 행사하는 데 이용된다.
[2]시스템 개발 기간에 따라서
◆ 빨리 끝내주길 원하는 사람
현업 : 시스템이 빨리 오픈을 해야 자기가 써먹을 수 있으므로 빨리 되기를 바란다.
PM : 개발 기간이 지체되면 막대한 돈이 나가므로 빨리 끝낼수록 자기 회사에 이익이 된다.
◆ 시간이 많았으면 하는 사람
시스템 운영자 : 시스템이 구축되는 동안은 기존 운영시스템만 관리하면 되므로 개발 기간이 길면 그만큼 널럴하다.
설계자 : 시간이 많을수록 여유 있게 많은 것들을 반영할 수가 있다.
개발자 : 프로젝트 진행 관리상 늘 개발 기간은 앞의 설계 단계에서 까먹으므로 그냥 바라기만 할 뿐이다.
◆ 제때에 끝내주길 바라는 사람
영업 : 개발이 제때에 끝나야 자기 회사 사람들을 다른 프로젝트에 투입할 수 있으므로 제때에 끝내고 나오기를 바란다.
컨설턴트 : 프로젝트 초기 단계에서 구축 기간에 대한 자신의 컨설팅 내용이 맞아야 하므로 프로젝트가 제때에 끝나기를 바란다.
[3] 프로젝트 구축 문서에 대한 입장에 따라
◆ 문서에 명시된 대로 되기를 바라는 사람
아무도 없다. 현업은 그 이상을 바라고 PM, 개발자 등은 그 이하를 바라기 때문이다.
◆ 문서에 명시된 대로 안 되기를 바라는 사람
아무도 없다. PM, 설계자, 개발자는 그래도 문서에 기술되어 있는 만큼 최대한 반영하려고 노력한다. 이는 문서가 시스템 구축에 어떤 영향을 미치는지 알 수 있는 대목이다. 대부분의 사람들이 자신의 입장에 따라 문서를 유리하게 해석하려고 하고, 첨삭하기도 한다. 한편으로는 문서가 있음으로써 서로 다른 이해 관계를 가진 사람들간의 조율이 가능하다. 예를 들면 현업의 경우 문서에 하기로 했는데 안 했으면 엄청 화를 낸다. 그리고 문서에 하지 않기로 되어 있지만 나중에 필요하면 어떻게 해서든지 하게 만든다.
[4] 프로젝트 산출물에 대한 입장에 따라
◆ 산출물이 많이 나오기를 바라는 사람
시스템운영자 : 운영자 매뉴얼은 실제로 운영할 때 참고해야 하므로 중요하게 여긴다.
PM : 프로젝트에 적용된 방법론에 따라 각 단계별로 산출물이 나와야 한다.
컨설턴트 : 프로젝트 산출물을 종합하여 다음 프로젝트 컨설팅에 써 먹어야 한다.
현업 : 일단은 많이 나와야 회사에 시스템 구축 결과를 보고하기에도 좋다.
◆ 산출물이 적게 나오기를 바라는 사람
설계자 : 설계 관련 산출물은 어떻게든 이름을 붙여 요구하면 끝이 없으므로 꼭 필요한 것만 남기려 한다.
개발자 : 개발하기도 바쁜데 산출물까지 작성하게 하면 짜증이 날 정도이다.
◆ 산출물과는 관계 없는 사람
영업 : 산출물이 많으나 적으나 잘 끝나기만을 바란다.
[5]소프트웨어 개발 과정에 대한 시각
◆ 시스템의 개략적인 부분만 알면 세부적인 것은 쉽게 된다고 생각하는 사람
현업 : 개발 계획서상에 목표와 구축 완료일자만 명시하면 된다고 생각하며, 세부적으로 안 된 부분은 추가할 수 있다고 생각함
컨설턴트 : 시스템의 구성도나 아키텍처의 논리적, 물리적인 흐름만 맞으면 세부적인 구현은 개발 단계에서 충분히 가능하다고 생각함
PM : 시스템 구축에 필요한 우수한 성능의 HW, SW를 투입하고, 개발자를 많이 투입하기보다는 하루에 보다 많이 일하게 만들면 빨리 구축된다고 생각함
설계자 : 현업의 요구사항에 따라 필요한 기능을 설계에 반영하고, 안 된 부분 및 세부적인 것은 구현 단계에서 개발자가 충분히 커버할 수 있다고 생각함
영업 : 시스템의 구현에 문제가 생겨 개발이 지연되면 더 많은 개발자를 투입하면 된다고 생각함
◆ 시스템의 개략적인 부분보다 세부적인 것 때문에 고민하는 사람
시스템 운영자 : 실제 운영할 때 필요한 기술적 요소가 중요하다고 생각함
개발자 : 설계 단계에서 가능하다고 했던 것을 실제로 구현하기 위해 온갖 수단을 동원해서 고민함
입장 바꿔 생각해봐!
이렇게 프로젝트에서 맡은 역할에 따라서 서로에 대한 관심사가 다르다. 어떤 부분에서는 친구가 되었다가도 어떤 부분에서는 원수가 따로 없는 일이 계속 발생한다. 그렇기 때문에 앞에서 살펴본 바와 같이 그 사람이 어떤 부분에 관심이 있다는 것을 인정해주고, 자신의 입장을 얘기하는 자세를 가져야 원활한 커뮤니케이션이 된다. 특히 개발자는 고객, PM, 설계자, 시스템 운영자, 영업 등 모든 사람과 개발 전체 기간에 걸쳐 부딪치게 되므로 같은 말이라도 어떻게 하느냐에 따라 상대방에게 다르게 들린다는 것을 명심하자. 특히 개발자들은 앞의 대화의 예에서 보았듯이 기술적인 얘기를 고객, 관리자 등 기술에 대해서 전혀 모르는 사람들에게 장황하게 얘기하는 경우가 많은데, 이런 부분은 지양해야 하겠다.
상대방이 관심 갖는 부분을 먼저 대답하라
누구나 질문을 하면 자기가 듣고 싶어 하는 대답이 있다. 프로젝트에서는 앞에서 얘기했듯이 관심이 서로 틀리기 때문에 자기가 중요시하는 부분을 먼저 얘기하고 싶어 한다. 그러나 똑같은 얘기라도 조금만 생각하면 정말 다르게 보일 것이다.
[1] 일반적인 프로젝트에서의 대화
고객 : 자동 메일링 기능도 구현해 주세요.
관리자 : 자동 메일링 기능 구현하려면 언제까지 되나요?
개발자 : 자동 메일링 기능을 구현하려면 메일 서버도 세팅해야 하구…
[2] 개발자가 상대방을 배려한 대화
고객에게 : 자동 메일링 기능 구현은 해드릴 수는 있습니다만 몇 가지 기술적 문제를 해결해야 하고 시스템에 기능 추가는 PM과 협의를 해서 결정을 내려주십시오.
관리자에게 : 자동 메일링 기능은 내일 오후까지 구현할 수 있습니다만 시스템 운영자한테 얘기해서 메일 서버 셋팅이랑 보안 설정 등의 협조를 구해야 합니다.
객관식으로 고객의 답변을 유도하라
고객은 일반적으로 시스템에 대한 그림이 명확하지 않고 눈에 보이면 그 때마다 자신의 편의에 따라 요구사항을 얘기한다. 그럴 때일수록 고객에게 깊은 생각을 요하는 질문을 던져서 오락가락하게 하기보다는 선택할 수 있도록 먼저 시스템의 그림을 제시해 진정으로 고객이 원하는 시스템에 접근해 나가야 한다. 다음은 간단한 예이다.
[1] 일반적인 프로젝트에서의 대화
고객 : 회원 현황을 조회하는 화면이 필요합니다.
개발자 : 회원 현황을 어떻게 보여드릴까요?
고객 : 일단은 날짜별로 이름이랑 주민번호 정도로 보여줘 보세요.
<며칠 후>
고객 : 전체 가입자 수를 먼저 보여주고 날짜별로 보여줘야 할 것 같구요.
[2] 객관식으로 고객의 답변을 유도하기
고객 : 회원 현황을 조회하는 화면이 필요합니다.
개발자 : 일반적으로 당일 가입인원을 보여줄 수도 있고 아니면 전체현황을 보여주고, 날짜별로 보여주는 방법이 있습니다. 어떤 방법으로 보겠습니까?
관리자에게는 일목요연한 보고서를 적어라
이는 관리자가 주간 보고서를 왜 받는지를 생각해보면 쉬울 것이다. 먼저 그 주 동안 뭘 했는지를 알고 싶어하고, 특별한 문제점은 없는지를 알고 싶어 한다. 그리고 다음 주에 뭘 해야하는 지를 알고 싶어 한다. 또한 관리자는 보고된 내용을 상세히 읽어보고 판단하는 것보다는 한눈에 보고 직관적으로 판단할 수 있는 보고서를 원한다. 즉 카운팅을 해야 하는 부분은 합계만 취합해서 적어주는 것이 낫다. 한편 문제점(이슈) 부분은 관리자가 소상히 알아야 하는 부분이므로 간략히 적지 말고 잘 풀어서 상세히 적어주어야 한다.
[1] 일반적인 보고서 내용 예
금주 실적 : 고객(a001.jsp, a002.jsp, a003.jsp), 매출(b001.jsp, b002.jsp)
문제점 : 서버가 너무 느림
| ||||||||||||
| ||||||||||||
|
[2] 관심 있어 하는 부분을 중심으로 작성한 보고서 내용 예
문제점 : DB 작업 증가 및 사용자 증가로 인해 개발을 할 수 없을 정도로 서버가 느려짐
프로젝트 뒷이야기들
프로젝트의 뒷이야기들에서는 프로젝트 구축 외에 프로젝트를 움직이는 여러 가지 요소들을 얘기하고자 한다. 주로 프로젝트에 참여하는 회사와 돈과 관련된 이야기들이니 연봉을 생각하는 사람들이 잘 읽고 판단하는 데 도움이 되기를 바란다.
프로젝트 참여 회사의 관계
갑을은 계약서에 나와 있는 고객과 고객에게 서비스를 제공하는 자를 의미한다. 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에서 슈퍼 보안관이란 만화를 본 적이 있다. 거기서 보안관은 ‘곰같은 힘’, ‘매의 눈’과 같은 동물들이 가진 초인적인 힘을 지니고 우주의 사건을 해결한다. 만화 같은 얘기처럼 들리지만 개발자들이 순수하게 ‘코딩’만 하는 단순 코더의 한계를 뛰어 넘어야만 자신의 능력을 마음껏 발휘해서 프로젝트에서 제대로 인정받을 수 있다.
무엇보다도 개발자는 일반적으로 다음의 능력이 부족하다.
[1] 컨설턴트의 논리적인 표현력과 시스템 아키텍처처럼 보는 시각
[2] 관리자의 리더십과 관리 스킬
이러한 능력이 부족할 수밖에 없는 이유는 개발자는 프로젝트에 들어가면 설계된 시스템과 시시각각으로 변하는 요구사항에 응하여 코딩하기 무척 바쁜 사람이기 때문이다. 그렇기 때문에 프로젝트에서 다른 역할을 하는 사람들에 비해 많이 부족할 수밖에 없다. 컨설팅 및 관리 능력을 갖춘 개발자가 되기 위해 부단히 노력하길 바란다. @
| ||||||
| ||||||
|
* 이 기사는 ZDNet Korea의 자매지인 마이크로소프트웨어에 게재된 내용입니다.
'Programming > JAVA' 카테고리의 다른 글
| mysql, oracle, mssql 드라이버 사용 (0) | 2008.04.28 |
|---|---|
| [펌] 메일 보내기 (0) | 2008.04.28 |
| [자바 프로젝트 성공 노하우] ② 성패를 가르는 핵심 요인 (0) | 2008.04.28 |
| [자바 프로젝트 성공 노하우] ① 프로세스 탐험기 (0) | 2008.04.28 |
| [세련된 자바 웹 프로그래머 되기] ③ 패턴·프레임워크·XP (0) | 2008.04.28 |