4. TEAM 프로젝트: 역할 분담 및 기능 단위 선정

우리는 해당 프로젝트에 의의에 맞게 개발자 협업 도구에 맞는 프로그램을 개발하려고 했다. 이에 반드시 필요한 것은 다음과 같았다.

각각 개발 단위를 나누는 기준은 자신이 안해본 기능, 그리고 흥미있는 것으로 정했다.

관리 기능은 세부적으로 분석하면 다양한 기능이 있어야하고, 에디터는 에디터 자체를 만드는 과정이 쉽지 않다.

나는 개인 포트폴리오에서 에디터를 제작해봤기 때문에 큰 흥미가 없었고, 멤버 관리는 이후 진행할 프로젝트에서 필연적으로 진행해야만 했다.

이에 따라, 팀원들의 동의를 구하고 스케줄러에 대한 개발에 진입하였다.

나하고 같이 개발을 하게된 팀원은 M이라는 친구였는데, 알고리즘을 짜고 문제를 탐색하는데 탁월한 능력을 가진 친구이다.

덕분에 든든한 전력을 얻은 기분으로 개발에 진입할 수 있었다.

캘린더 기능은 일반적으로 FULL Calendar라는 라이브러리를 사용하고 구현한다. 문제는 이 라이브러리는 서버 통신이나 관리에 일정 비율의 금액이 발생한다는 것이었다.

뼈해장국 한 그릇에도 벌벌떠는 나의 재정상태로는 이 라이브러리에 필요한 금액을 지불하는 것은 어려웠고, 실제 우리는 우리의 서버와 서블렛을 사용하여 기능을 구현해야 했다.

그룹 별로 스케줄을 확인할 수 있어야 한다는 기능적인 문제도 있어, 해당 라이브러리를 사용하는 것은 어렵다고 판단하였다.

이에 따라, 나는 모든 기능, 마크업, 디자인을 직접 진행하자고 생각했다.

물론 나의 실력이 미흡할 수 있지만, 언젠가 내가 기업에 취직하여 내 몫을 한다면, 직접 프로그램의 기능 단위를 개발하고 기획할 수 있어야 한다고 생각했다.

물론 이러한 선택이 Team에 이득이 되는지는 더 면밀히 따져봐야 했다. 캘린더의 디버그 및 정렬 기능에 대한 개선점을 반영하느라 5일 정도 시간을 더 할애했기 때문이다.

캘린더에는 크게 3가지의 영역으로 기능을 구분할 수 있다.

문제는 캘린더를 자체 자체하면서 기능만이 아니라 모양, 달련의 날짜 계산을 모두 구현해야 한다는 것이었다.

이에 따라 우선 내가 설정한 목표는 다음과 같다.

여기서 또한 요구사항에 대한 명확한 정의가 없이 기능에 대한 데이터를 대략적으로 정했다.

이러한 문제로 인해 순차적으로 개발이 진행되면서 UI 구성 및 디자인에 필요한 시간이 더 필요함을 인지했어도 시간을 조정하거나 더 빠르게 개발하는 것이 불가능했다.

결국 개발자로서 일을 하면 일의 기한에 맞춰서 개발이 진행될 것인데, 내 개인 역량의 파악과 이를 진행하는 내 컨디션 조절이 얼마나 중요한지를 알게 되엇다.

Hyun's Developer Note