방법론팀에 배정받은 나는 자연스럽게 엔지니어링 업무가 짙었던 형상관리 툴 관련 업무를 맡게 되었다. 당시에 나와 함께 배정받은 동기녀석도 같은 업무 였는데, 나는 주로 SI(System Integration)쪽을 맡았고, 그 친구는 SM(System Maintenance) 쪽을 맡았다. 군대도 줄을 잘 서야 한다는 데, 이는 향후 둘의 커리어의 방향과 직결되는 것이였다는 것을 뒤늦게 알게 되었다. 결과적으로 보았을 땐, 난 성향 자체가 SI 사업이 맞았고, 처음에는 케어(?)를 잘 받지 못 했지만, 내가 원하는 방향으로 커리어를 쌓아 갈 수 있었다.
우리 방법론이 사용하던 형상관리 툴은 Serena사의 Dimensions 라는 제품이였다. 아마, 일반 개발자들에게는 다소 생소하지 않을 까 싶다. 그 당시만 하더라도 CVS, PVCS등이 주로 쓰여지고 있었고, Subversion도 사용이 많이 되고 있던 시점이였다. 헌데 듣보잡 디멘전이라니.. 해당 툴은 다른 소스 형상관리 툴과는 다르게, 이슈 관리/트래킹이 한 제품으로 되는 솔루션이였다. 아무래도, 방법론과 함께 엮다 보니, 소스 리비전과 이슈가 관계를 맺어야 하기 때문에 이 제품이 선택 된 걸로 생각된다. 하지만, 해당 기능은 짧은 기간내에 수많은 리비전이 만들어지고 커밋/롤백이 난무한 SI 플젝에서는 그닥 어울리는 제품이 아니였다. 하지만, SM기반의 유지보수가 주인 현장에서는 자그마한 커밋도 쉽게 허용이 되지 않아야 하고, 안전성을 최우선으로 두는 경향이 짙기 때문에, 현재도 사내포탈과 연계하여 커스터마이징 한 버전이 사용되고 있다.
앞에서 언급했듯이 난 주로 대내외 SI 프로젝트를 돌아디나면서, 형상관리 툴을 세팅해주고, 개발자들을 교육시키는 일을 주로 했었다. 먼넘의 툴이 설치가 이리도 복잡하던지, 메타 데이터를 오라클 디비에 넣고, 라이센스 서버, 웹 서버 등을 따로 다 설치하고, 버전 업그레이드 되면 동일 작업을 반복하고.. 하여간 손 가는 작업이 무척 많았다. 그리고, Pessimistic Locking 정책에 따라, 소스를 수정하기 위해서 반드시 Check Out을 하여 Lock을 확보해야만 사용 가능 한것이 default 설정이였고, 많은 개발자들이 이런 부분들을 불편해 했다. 솔직히, 형상관리 툴을 교육 하는 것 자체에 대해 무슨 필요성이 있는 지 모르겠다는 개발자들이 대부분이였지만, 일반 형상관리 툴과는 다르게, 사용법이 복잡했고, 이슈까지 연계까 되다보니, 본의아니게 욕(?)을 많이 먹었던 걸로 기억한다.
프로젝트 상주기간은 case by case 였었다. 2~3일이면 끝나는 곳도 있었고, 길면 3개월씩 상주하기도 하였다. 행자부, 교육부, 법무부 등의 공공 프로젝트, 금융권 증권/보험사 프로젝트, 삼성 그룹사 SI 프로젝트, 군 프로젝트 등 전국방방곡곡을 돌아다녔던 걸로 기억한다.
사람 만나기 좋아하고, 돌아다니기 좋아했던 나에게는 새로운 환경에 적응하면서 내가 가진 기술을 알리는 작업이 즐겁기는 하였으나, 개발에 항상 목 말라 했던 나는 항상 무언가 부족함을 느끼곤 하였다. 이런 나의 솔직한 마음을 선배 및 팀장님에게 기회가 될 때 마다 이야기 하였고, 개발 거리를 찾던 중, 형상관리 솔루션과 연계하여 자그마한 자체 프로젝트를 하게 되었다.
컨셉은 간단했다. 그 당시의 개발 프로세스의 대한 상태를 그래프화하여 현실성 있는 개발 진척도를 가시화하고, 이를 플젝 전체에 공유하여 동기부여 수단으로 사용하고, 투명화하겠다는 개념이였다. 가령, 개발자가 Task를 할당 받으면 상태는 '개발중' 이고, 개발이 완료되면 소스 최종 커밋 이후 연결되어 있는 Task의 상태를 'PL검토중'으로 변경하면서 담당 PL에게 전달한다. PL은 단위테스트 완료 유무 및 자체 테스트를 통해 개발이 완료되었다고 판단이 되면 '개발완료' 로 변경하고, 그렇지 않다면 '개발중'으로 변경하여 다시 개발자에게 전달한다. 이런 과정을 실시간으로 시각화 하는 개념으로 보면 되겠다.
소스 관리 및 이슈(태스크) 관리가 디멘전 하나로 관리가 되고 있었고, 모든 메타 정보는 오라클 DB에 들어 있었으며, 친절하게도 데이터 핸들링이 가능한 Api가 있었으나, 무척 불편하고 배우기도 어려웠기에, DB의 테이블 구조를 일일히 그려나가면서 개발해 나가기 시작했다. 이미, 이런 식의 개발은 해본 경험이 있었기 때문에, 어렵지 않게 구현할 수 있었다. 단순 JSP형태로 개발한 걸로 기억한다. 껍대기는 어디서 템플릿화 되어 있는 걸 가져왔었고, WAS는 Tomcat.. 크리티컬한 시스템은 아니였기 때문에, HA구성까지는 할 필요가 없었다. 헌데, 만드는 것 까지는 쉬었는데, 해당 화면을 보는 주요 의사 결정권자들이 너무 많았던 것이 탈이였다. 처음에는 내 소속 PL의 요청에 따라 개발을 완료하고 나니, TM(Test Manager)가 다른 의견을 보여주고, 그래서 변경하면 PM(Project Manager)가 한 마디 하고, 나중에 프로젝트에 공개하니, 각 모듈 담당 PL(Project Leader)들이 또 다른 요구사항을 내기 시작하고.. 그 당시 한 달 정도면 개발 및 테스트, 배포까지 마무리할 생각으로 투입되었던 여의도 모 증권사 차세대 프로젝트에서 3개월 이상 머물렀던 걸로 기억 한다. 그리 달갑지 않은 기억이였지만, 요구공학에 대한 필요성과 정제 작업, 데이터 수집 및 효과적인 시각화 등에 대해 깊이 고민하게 해주었던 플젝이였다.
어느 정도 형상관리쪽이 익숙해지니 다른 툴에도 관심을 가지게 되었다. 그 당시 방법론을 지원하는 툴셋을 통합개발플랫폼 이라고 칭하였고, 결국 나의 업무는 '통합개발플랫폼 개선 및 확산'으로 2년 정도 수행하였다. 형상관리툴에 더해서, EA나 ERWin과 같은 설계 툴, Eclipse 같은 개발IDE(Integrated Development Environment), CI(Continuous Integration)을 위한 Ant, Maven, Hudson 등.. 개발을 위해서 필요한 대부분의 모든 툴에 대해서 경험을 하게 되었고, 서로 연계 하는 작업에도 동참하게 되었다. 정기적으로 진행했던 방법론 교육과정의 실습 환경 구성을 하기도 하였고, 후반에는 전체 툴에 대한 엔지니어링 및 기술 지원 등을 수행하였었다. 이는 SA로 성장하게 되는 좋은 밑거름이 되어주었다.
하지만, 처음부터 Framework 개발을 하고 싶었던 나에게, 솔루션을 배워서 하는 것 보다는 직접 개발에 뛰어 들어서, 대형 SI 프로젝트를 하고 싶었던 욕구가 무척 강했던 걸로 기억한다. 그리고 2년차때 소속 팀장이 이러한 내 성향을 잘 이해하고 있던 상황이였었다. 이게 개인 평가에는 도움이 되지 않았지만, 부서를 옮기는 데에는 기여를 하게 된다.
그 당시 회사에서는 엔터프라이즈급 상용 비즈니스 Framework를 개발 하겠다는 계획이 진행되고 있었고, TFT가 추진되고 있었다. 1년차때 알던 선배 한분이 해당 TFT에 있었고, 우연히 2년차 여름쯤에 진행되었던, 각 센터/TFT 추진현황 공유시 해당 TFT에서 내부인력 대상으로 인력을 모집하고 있다는 것을 보게 되었다. 내부인력이 대상인 이유는 보안상 이슈 및 내부 역량 강화가 원인이였을 것으로 본다. 그 날, 발표를 마친 선배를 지체없이 쫓아가 농담 한 마디 건넸다.
"선배님, TFT가서 저 불러주신다고 하시더니, 연락이 없으시네요? ㅋ. 잘 지내시죠?"
선배 왈, "오, 인석씨. 오랜만이에요. 안 그래도 하고 싶은 얘기가 있는데 시간 괜찮아요?"
갑자기 하늘에서 종이 울리는 기분이였다. 난, 선배와 커피숍에서 한 시간 정도 이야기를 나누었고, 선배는 같은 본부에 옆 센터에 있던 나를 후보로 선정해주었다. 이는 비공식적으로 TFT장에게 올라갔으나, 결국 공식적으로 내 이름 석자가 내부인력 충원 대상 후보 인력으로 거론되기 시작했고, 내 소속 팀장이 동의 해주면서 난 팀을 옮기게 되었다.
실은, 입사 1,2년차 된 사원이 지금 내가 하는 일은 재미가 없으니, 딴 일을 시켜달라고 하는 경우는 거의 없다고 볼 수 있겠다. 보통, 본인들이 하고 있는 일이 무엇인지 잘 모를때가 많고, 조직적으로 보았을 때는 개인 평가에 좋지 않은 영향을 끼칠 수 있기 때문이다. 하지만, 나는 다른 사원들보다 2년이라는 개발 경험을 가지고 있었으며, 하고 싶은 일에 대한 의견 개진을 주저 없이 했기 때문에, 내가 원하는 부서로 전배 갈 수 있었다. 물론, SDS에는 본인이 원한다면 TO가 있는 부서로 팀장 협의 없이 일단 시스템을 통해 신청하여 옮길 수 있는 훌륭한 제도가 있지만, 난 그런 방식은 원하지 않았다. 회사 입장에서 보았을 때, 개인이 가장 하고 싶고 잘 할 수 있는 일에 배치를 하는 것이 회사에서도, 개인에게도 득이 된다고 보기 때문이다.
많은 인력들이 입사 초년에 적응에 실패하고 회사를 떠난다. 힘든 것도 있을 것이고, 생각 했던 것과 너무나도 다른일들이 본인에게 닥치기 때문인 듯 하다. 우리나라 대기업 문화 상, 신입사원으로 뽑힌 인력이 명확히 무슨일을 해야 될지를 입사 전 부터 제시하고 지켜나가는 경우는 극히 드물다고 봐야 한다. 그리고, 갓 졸업한 대학생들 역시, 본인들이 하고 싶은 일이 무엇인지, 아니면 최소한 본인 잘 하는 일이 무엇인지 잘 알지 못 하는 경우가 허다하다.(한국식 교육이 만든 결과라고 생각한다.)
하지만, 이걸 반대로 해석한다면, 회사가 원하는 인재상은 특별한 기술을 가진 사람이 아니라, 회사에 잘 맞는 사람을 뽑는 다는 것.. 그리고 그 사람에게 많은 돈을 투자하여 키운 다는 것, 그리고 입사 이후에 본인에게 맞는 일이 주어질 수도 있고, 그렇지 않더라도 할 수 있는 일이 무지 많다는 것 등은 장점으로 적용 될 수 있지 않을 까 싶다..
다음 포스트에서는 그렇게도 원하던 프레임워크 팀으로 이동하여, 진행했던 두 개의 대형 프로젝트에 대해 얘기 해보고자 한다. 지금 생각 해도, 증말 재미있던 플젝들이다.
To be continued..
>_
관련 기술 : Dimensions CM, Subversion, ERwin, EA, Eclipse, Jenkins, JSP, Java, Oracle, Tomcat, SQL 등
-- My Story ---------------------------------------
---------------------------------------------------
관련 기술 : Dimensions CM, Subversion, ERwin, EA, Eclipse, Jenkins, JSP, Java, Oracle, Tomcat, SQL 등
댓글 없음 :
댓글 쓰기