[소프트웨어 개발 컨설턴트의 일상] IBM에서 첫 정식 프로젝트를 마치고

1년 9개월간 진행된 IBM에서의 첫 정식 프로젝트를 마치고

IBM Canada에 정식 사원으로 입사하고 첫 프로젝트를 마쳤다. 첫 프로젝트는 인턴 때 알던 매니저의 추천으로 쉽게 구할 수 있었다. 보통은 알아서 인맥을 통해서 구하거나, 공개적으로 포스팅된 프로젝트 포지션을 찾아서 인터뷰를 보며 구해야 한다. 이 과정에 대해서도 다음에 적어보겠다.
 

프로젝트 개요

나의 첫 프로젝트는 캐나다에서 제일 큰 은행 Top 5 안에 드는 은행에서의 프로젝트엿다. 캐나다 IBM의 주 클라이언트는 금융, 통신 그리고 항공사 계열이다. 캐나다에서 제일 큰 기업들이 있는 계열이다. 이번 프로젝트에서는 모기지(mortgage)를 해당 은행 웹사이트에서 신청해서 승인을 미리 받는 기능 (pre-approval)을 구현 하는 것이었다. Mortgage는 은행에서 대출해주는 집 마련 대출이라고 보면 된다. 보통 모기지 대출 값은 억 원대이다. 승인을 미리 받으면 웹사이트에서 표시된 모기지 금리를 가지고 은행 지점에서 바로 대출을 받을 수 있는 기능이다.
 
대출 승인을 해주기 위해서 고객의 정보를 입력하는 페이지들을 만들고, 그 정보들을 안전하게 은행 back-end로 보내는 웹 사이트를 만들었다. 승인을 할지 안 할지 logic은 이미 구현돼 있어서 정보를 모으고 보내기만 하면 됐다. 하지만 프런트 엔드 개발은 말만큼 간단하지만은 않다. 기본적으로 수많은 입력 유효성 검사 (input validation)가 필요하고, 고객 정보 보안 및 관리, 웹 접근성, 유닛 테스트등등 많은 것들을 고려해야 한다. 하지만 그중에서도 제일 어려운 것은 클라이언트가 이미 사용하고 있는 시스템 내에서 이 모든 것을 해내야 하는 것이다. 이미 큰 은행이기 때문에 IT부서도 따로 있고 수많은 자사 개발자들 사이에서 같이 일하는 것은 생각보다 쉬운 일은 아니다. 
 

팀 구성

 
일단 이미 존재하는 웹사이트는 Angular를 사용하고 있었기 때문에 이 프로젝트도 Angular를 이용해서 만들게 되었다. 사용하고 있는 앵귤러 버전은 5엿다. (최신 버전은 앵귤러 9) 이 프로젝트는 기존에 존재하지 않는 기능이었기 때문에 처음부터 만들어야 했다. 그렇기 때문에 오히려 편한 점이 많기도 했다. 일단 처음 시작할 때는 BA(business analyst) 1명, PO (project owner) 1명, 개발자 2명, QA 1명, 디자이너 1명으로 총 6명으로 시작 했다. 내가 이 중에 개발자 1명이었다. 
 
어쨌든 점점 웹사이트를  만들기 시작하면서 팀은 성장하기 시작했다. 팀이 제일 컸을 때는 총 16명까지도 있었다. 팀 멤버는 중간중간 필요에 의해서 계속 교체된다. 계약직도 많고 정규직원들도 팀끼리 돌려 쓰기 때문이다. 나는 처음부터 있던 멤버로서 개발을 리드했기 때문에 처음부터 끝까지 남아 있게 됐다. (중간에 IBM 내에서 승진도 했다). 개발자 구성에는 프런트엔드와 백엔드 개발자는 거의 2:1 비율로 나누어졌다. 프런트엔드 일이 더 많기 때문이다. 하지만 자기가 맡은 일이 있어도 서로 배우고 가르치면서 같이 성장하는 분위기 이기 때문에 프런트엔드 개발자가 백엔드를 만지고 그 반대로도 백엔드가 프런트엔드를 만지는 경우도 가끔 있었다.
 

팀 내 분위기/ 개발 방식

일단 지금까지 가장 오랫동안 일했던 팀이기 때문에 그만큼 친해졌고 정도 들었다. 보통 컨설팅 일을 하면 프로젝트 기간이 보통 4달 에서 1년 사이이기 때문에 이번 프로젝트는 나름 장기 프로젝트라고 할 수 있다. 팀 내에서 계급 조직 같은 건 없었고 모두 자기가 맡은 바 일을 해내는 분위기로 흘러갔다. 일단 프로젝트 진행은 애자일 (Agile) 방식으로 진행 됬다. 애자일이란, 소프트웨어 개발 방식이다. 기본적으로 애자일 방식은 빠른 개발과 출시를 중점으로 둔 최신 개발 방식이다. 예전 방식과의 차이점이라면 프로젝트 완성 중점보다는 기능 (feature) 중점이다.
 
그래서 한가지 기능을 개발을 할 때 한 개의 스프린트(sprint) 내로 개발 하는것을 중요시한다. 스프린트는 개발 사이클이라고 보면 되는데 이 사이클은 팀마다 다르게 설정한다. 우리는 2주를 한 스프린트로 정의했고 한 기능을 개발할 때는 2주 내로 개발할 수 있도록 쪼개서 개발했다. 그래서 만약 그 스프린트 내에 개발된 기능을 바로 출시해도 문제없을 정도로 개발하는 것이 포인트이다. 
 
애자일은 기본적으로 투명성(transparency)을 기반으로 진행된다. 이는 모든 팀원이 다른 팀원들이 무슨 일을 하고 있고 진행 상태를 투명하게 알도록 하는것이다. 그래서 매일매일 스크럼 (scrum)이라는 미팅을 진행하는데, 팀원 모두가 돌아가면서 1~2분 내로 자신이 진행하고 있는 일을 발표하는 것이다. 이 미팅의 가장 큰 포인트는 누군가가 막힌 점이 없는지 파악하고 서로를 빠르게 도울 수 있도록 하는 것이다. 
 
*재밌는 점은 이 방식을 진행하는 사람을 Scrum master (스크럼 마스터)라고 부르고, 스크럼 마스터는 점점 수요가 높아지고 있다.
 
애자일 개발 방식에 대해서는 더 자세히 또 써보도록 해야겠다
 

프로젝트 진행

일단 새로운 프로젝트가 시작되면 business requirement들이 정의된다. 이 앱의 기능들, 필요한 것들을 다 적어 놓는다. 그러는 동시에 디자이너는 스크린을 디자인한다. InVision을 통해서 디자인한 스크린들을 공유해준다. 일단 모바일과 데스크톱 두 가지 버전이 필요했다. 반응형 웹으로 만들자는 의견을 많이 냈지만, 은행 측에서는 기술적 제한이라던가 복잡함이라던가 디자인에 맞지 않는다는 이유 등으로 두 가지 버전을 준비하라고 했다. 이 중에서 가장 큰 이유로는 모바일과 데스크탑에서 사용자가 겪는 경험이 차이가 나기 때문에 따로 만들자고 결정했다. 나로서는 어떤 방향을 선택하든 상관없었다. 개발자로서 반응형 웹이든 버전이 두 개인 웹을 만들던지 복잡함은 비슷하다. (나중에는 두가지 버전이 더 복잡해지긴 한 거 같다) 처음에는 모바일 웹 개발부터 시작했다. (Mobile first가 대세이다)
 
점점 프로젝트가 진행이 되면서 비즈니스 쪽에서는 계속해서 새로운 기능을 추가하고 보완하면서 일을 만들어 낸다. 그러면 그러한 기능들을 어떻게 실현하고 만들지는 나의 몸이다. 보통 새로운 기능의 요구 사항을 비즈니스가 만들어서 오면 개발팀은 그 기능을 만들 때 얼마나 걸릴 지에 대한 예측을 해야 한다. 예측할 때 빠뜨린 점이 없는지, 모든 요구 사항이 명확 한지, 이 기능을 만들 기술이 있는지 등등 모든 준비가 완료되어야 지만 개발을 시작한다. 이렇게 1년 9개월을 개발한 결과, 모바일과 데스크톱 웹을 각각 성공적으로 만들고 원하는 요구사항이 모두 충족되었다. 앞으로는 보완하고 더 개선하는 기능들을 추가하기 위한 팀원들을 빼고는 팀원 감축이 진행 됬다.
 
그렇게 나의 계약도 끝나게 됐다.

배운 점

1. 이 프로젝트를 통해 가장 큰 배운 점은 모든 팀원들은 각자 중요한 역할이 있다는 것이다. 모두들 쉴 틈 없이 일하는 것은 아니지만 각자가 맡은 일을 함으로써 우리 팀은 매우 효율적이었다. 서로 의사소통도 매우 원활했고 각자 일을 해낼 것이라는 믿음이 있었다.
 
2. 컨설턴트로서 자신감을 가져라. IBM에서 보내는 컨설턴트는 매우 비싸다. 다른 계약직이나 정규직보다도 비싸기 때문에 클라이언트는 무척 신뢰하고 의지한다. 나도 배워가면서 진행하는 프로젝 트였지만 요구되는 것들은 매우 많았고 책임감도 컸다. 하지만 그만큼 신뢰도 쌓았다.
 
3. 앵귤러에 대해서 매우 많이 배웠다. 프로젝트를 처음부터 끝까지 진행하는 상황이었기 때문에 규모가 작을 때부터 클 때까지 모두 봤기 때문에 앵귤러 구성, 기능 등 많은 것을 배웠다. 만약 지금 새로운 앵귤러 프로젝트를 시작하라면 눈감고 할 수 있을 정도이다.
 

어려웠던 점

개발자로서 어려웠던 점은 웹 접근성이었다. 접근성은 나에게 생소한 주제일 뿐만 아니라 생각보다 복잡하다. 특히 모바일과 데스크톱을 모두 충족하기란 매우 어려웠다. 모바일에는 아이폰, 안드로이드에서 모두 스크린리더에 문제가 없어야 했고, 데스크톱에서는 크롬, IE, 파이어팍스, 사파리에서 문제가 없어야 했다. 스크린리더는 플랫폼이나 브라우저에 따라서 다르게 행동하는 경우가 많았기 때문에 곤란했다. 하지만 제한도 많다는 것을 깨달았고, 실현 불가능한 것은 안된다고 말하는 법도 배웠다.
 
클라이언트의 큰 회사 시스템은 처음에 큰 골칫거리였다. 일단 회사 컴퓨터를 받고 로그인 권한을 받는데만 처음에 2달 가까이 걸렸다. 그만큼 일 처리를 진행하는 속도가 매우 느렸다. 은행의 규모가 큰만큼 거처야 하는한 승인 과정이 길기 때문이다. 어쨌든 첫 두 달 동안은 그냥 가서 눈치껏 앉아 있다가 집에 온 경험이 생각난다. 아무것도 안 한 건 아니지만 딱히 프로젝트를 시작할 수도 없던 기간이기 때문에 힘들었다.