[PROJECT] Aritaum 브랜드 사이트 개발 완료

9월 1일자로 Aritaum 브랜드 사이트 런칭이 되었다.

대체적으로 만족하는 사이트였다. 하지만 성공적인 런칭의 배경에는 다양한 요인이 있을 것이다.
팀워크, 리소스의 적절한 수급, 그리고 기간과 비용 그런 모든 것이 작용하여 이런 만족스러운 효과가 나타났다고 생각한다.

프로젝트를 하면서 좋았던 점과 아쉬웠던 점을 나열해 본다.
먼 훗날, 아니면 아주 가까운 다음 프로젝트에서도 이러한 내 경험의 기술이 많은 도움이 될 수 있었으면 좋겠다.

Good Case

1. 팀워크 :

초반기 프로젝트를 수행하면서, 인력 배분에 대한 문제가 많았지만, 2차 오픈 기간동안은 안정적인 팀워크를 수행할 수 있었던것 같다.
이러한 팀워크의 안정적인 수행에는 다음과 같은 요소가 작용되었던 것 같다.
A. 고객의 안정감 있는 지원 - 고객의 요구사항은 항상 변화 했다. 그러나 오픈시점에 심적 부담을 상당히 덜어주었던것 같다. 같이 나와서 테스트 해주고, 프로젝트 뿐만이 아닌 개인적인 이야기를 많이 했던것 같다. 참 편한 고객이었던것 같다.
B. 스킬과 능력이 있는 팀원 - 프로젝트에서 가장 중요한 것이 프로젝트를 수행하는 사람들의 능력이다. 초기에는 기대에 미치지 못하는 능력이 있었지만, 후반부에 스킬이 우수한 사람이 다시 영입됨으로 해서, 프로젝트의 부하를 분산 시켜주는 효과가 있었다.
C. 즐거운 분위기 - 프로젝트에서 즐거운 분위기의 조성은 정말 프로젝트 성패를 좌우하는 중요한 요건이었다. 프로젝트를 수행하는 도중 팀원들의 이해심과, 유머들이 작용하면서 분위기가 상당히 좋았던것 같다. 한가지 중요한 교훈은 프로젝트를 수행하면서 자신을 낮추고, 고상한척 하지 않는 마음가짐이 필요함일 것이다. 자신을 버리는 순간 팀의 분위기는 더욱 즐거운 방향으로 흐르게 된다는 것...

2. 개발 관련 툴

A. 공통 관리툴을 통한 개발 범위 축소 - 프로젝트를 수행할때, 절반의 공수는 프런트 개발이었고, 절반은 관리자의 개발이었다. 그러나 여기서는 공통화된 관리자 툴이 존재했었으며, 그러한 공통관리 툴은 관리자 개발 범위를 축소 시켜 주었다.
B. 개발 프레임워크와 환경의 일치 - 아리따움을 개발하면서 좋았던 점 가운데 하나가 개발 프레임워크와 환경이 일치한다는 것이다. 이러한 일치로 인해서 RAD라는 개발 툴을 이용하게 되었고, 이것은 추가적인 개발 환경 세팅의 범위를 줄여 주었으며, 실제 서버로 디플로이 할 때 고려해야하는 많은 작업을 제거해 주었다는 점이다.
C. 개발 프레임워크의 팀원간 이해 - 초기 개발자의 교육을 통해서 프레임워크와 개발 방향을 공유했다. 프레임워크와 개발 방향의 공유는 팀으로 하여금 팀워크의 증대와, 개발 전반에 대한 이해도의 증진에 도움이 되었다. 여기서 얻은 교훈은 개발 팀원의 적극적인 노력이 필요하다는 것이다. 초기 투입된 개발자의 경우 적극성이 떨어져서, 개발하는데 상당한 무리가 있었다, 그러나 후에 들어온 개발자의 노력과, 관심도 덕분에 다시 개발 방향의 공유를 이룰 수 있었다.

 Bad Case
1. 팀워크

A. 까칠한 고객 - 이번 프로젝트에서 고객을 지원하는 고객쪽 지원부서의 행동이 상당히 까칠했다. 초반 기세를 잡기위한 행동이었는지는 모르겠지만 그러한 행동으로 인해서 커뮤니케이션을 꺼리게 하는 요인으로 작용했다.
그리고 가능하면 우리 내부에서 일을 처리할 수 있도록 하고, 그들과 커뮤니케이션을 최대한 줄였다. 이는 프로젝트에서 경험에 의한 실수 빈도를 높이는 결과를 초래했다.
B. 팀원의 비 적극성과 낮은 기본기 - 프로젝트의 성패는 프로젝트 팀원의 스킬과 연관이 있다는 것은 자명한 사실이다. 짧은 기간에 적은 인원으로 프로젝트를 수행하기 위해서는 기본기가 튼튼한 팀원이 들어와야 무리없이 진행된다. 그러나 이번 프로젝트 초기에 팀원의 기본기가 너무 떨어졌으며, 이 팀원의 학습곡선 역시 일반적인 그래프를 그리지 못하는 상황이 되었다. 팀원의 기본기와 적극성이 너무 떨어졌었다. 교육을 통해서 이루어 질 수 있는 부분은 기본기 채우기였지만 적극성 고취는 할 수 없었다. 다행인 것은 새롭게 교체된 팀원의 스킬과 적극선이 우수해서 프로젝트의 많은 부분을 안정화 시킬 수 있었다.
C. 팀원 교체 - 프로젝트 진행중에 프로젝트 팀원 교체가 있었다. 그러나 이러한 교체에 대한 절차가 없었으며, 아무런 정보나 상의 없이 인원이 교체 되었다. 프로젝트 중간에 팀원의 교체는 프로젝트 상식에서도 매우 위험한 행동이다. 이러한 결과로 교체로 인한 초기 팀원의 산만함이 나타났으며, 교체 1주일 전부터, 교체되기까지 작업 진행을 전혀 못했다. 또한 새로온 팀원의 교육(프로젝트 범위, 프레임워크, 개발방향)으로 많은 시간을 허비하게 되었다. 여전히 남는 아쉬움 중에 가장큰 부분이 아닐까? 생각된다.
D. 집중과 통제의 문제 - 프로젝트 중간에 디자인파트와 개발 파트에 대한 통제가 되지 않았던것 같다. 디자인 파트에서는 2명이 수행해야 할 일을 한명이 본사 복귀를 했던 상황이었고, 프로젝트 중간에 전체적인 팀 일정에 대한 통제가 되지 않았다. 개발의 경우에는 프로젝트 인원 교체와 강제성의 결여로 개발 리더 혼자서 작업을 처리하는 상황까지 발생했다. 이러한 상황은 통제되고, 집중되어야 하는 문제로 아쉬움이 남는 부분이었다.

2.  개발 툴

A. 고객쪽에서 제공한 API의 문제 - 고객이 제공한 API는 사용방법과, 주의사항, 문제점에 대한 검증이 제대로 수행되지 않은 API였다. 첫번재 API는 설명서가 없는 상태에서 모든 메소드에 동일한 객체를 파라미터로 전달하고 있었다. 이러한 상황에서 객체에 설정해주는 값의 정보를 알 수 없어 코들를 직접 역 컴파일 해야하는 상황이 발행했다. 또한 검증되지 않은 API 메소드 부분들과 오류 로그의 부실함때문에 문제점이 발견해도 그것을 수정하거나 원인 분석을 위해서 문제 상황을 보고 해결하는 것이 아닌 소스를 분석해서 문제점을 파악하는 원시적인 방법을 사용해야 했었다.
B. API의 제한으로 인한 다양한 설계 불가 - API라는 것의 한계는 지정된 API만을 이용하여 작업을 해야하고, 그 렇게 작업을 하게 되면 다양한 요구사항을 수렴할 수없다는 문제점이 생긴다. 그러한 문제점이 많이 발생했고, 이를 해결하기 위해서 DB를 구성해야 했으나 DB역시 고객의 정책으로 인해 생성을 할 수 없었으며, 이로 인해 코드성 데이터를 파일처리해서 작업을 할 수 밖에 없었다.

엔데 굿, 알레스 굿이라고 했던가? 끝이 좋으면 다 좋다고, 프로젝트의 끝은 그나마 낳은 상황이었다.
좋은점도 있고, 아쉬운점도 있지만 다음에는 좀더 좋은 결과가 있길 기대한다.

결론적으로 내가 얻은 교훈은 커뮤니케이션이다. 도천지장법에서 가장 먼저 나오는 도, 즉, 커뮤니케이션이 활성화 되면 될수록 프로젝트의 성공률은 높아지고, 퀄리티 역시 좋아진다는 것이다.

이번 프로젝트에서 만족스럽지 못한 커뮤니케이션을 좀더 갈고 닦도록 노력해야겠다.