서비스 개발후기 - 1. 들어가면서

장장 6개월 동안 몸 담고 있었던 웹 서비스가 하나 베타 론치되었고 개발 후기겸 해서 포스팅을 해 볼까 합니다. 기본적으로 오픈 소스를 이용했기 때문에 개발 후기 또한 외부에 공개되어도 무방하리라고 생각합니다. 그러나 회사 보안상 실 URL은 직접 언급하지는 않겠고 다만 제가 몸담고 있는 회사의 광고주를 위한 플랫폼이라는 정도로 이해해 주시면 좋겠습니다.

1. 이전 개발 방식 - 극단적 워터폴(waterfall)

제가 이전과 그 후에 계속 해 왔던 프로젝트는 주로 다음과 같은 순서로 진행되어 왔습니다. 사업을 해야 된다는 결정은 기획부서에서 주로 내려지고 상위 기획까지 만들어지면 개발/디자인/QA와 같은 생산부서를 모아서 설명회를 하고 리소스 요청을 하게 됩니다.  소프트웨어 생산(?)은 정확히 아래와 같은 흐름으로 이어지고 매단계 산출물을 모아 기획팀 주관으로 생산물 리뷰 회의를 하게 됩니다. 이런 개발 방식의 가장 큰 문제는 협업부서가 너무 많아서 전체 기간이 아주 아주 많이 걸린다는 점입니다. 프로젝트 중간으로 가면 커뮤니케이션 오버헤드로 많은 사람들이 힘들어 합니다. 여기에 부서 이기주의가 보통 들어가고 부서간 정치까지 들어가면 당연히 프로젝트는 산으로 가게 됩니다. 실무자들보다 각 팀의 관리자들의 입김이 더 세지는(산출물을 컨펌하기 때문) 현상도 부산물이죠.

사업기획(기획팀) -> 상위 기획(기획팀) -> 상세 기획(UX팀) -> 디자인(디자인팀) -> 마크업(디자인팀) -> 코딩(개발팀) -> QA(QA팀) -> 배포(개발팀) -> 운영(개발팀, 운영팀)

2. 이번에 채용한 개발 철학

중요한 개발 철학은 네가지입니다.

- 프로토타이핑을 포함한 빠른 기능 추가

말로 하기 보다는 프로토타이핑으로 보여주는 것을 원칙으로 합니다.

- 생산의 많은 단계는 개발자가 처리

상세 기획, 디자인/마크업, 코딩, QA의 가능한 많은 단계를 개발에서 가져갑니다. 부서간 커뮤니케이션을 최대한 줄여서 개발 속도를 높이는 측면이 있으며 진행의 일관성을 가져다 주는 장점이 있습니다. 

- YAGNI

섵부른 일반화, 앞선 개발을 최대한 피하고 가급적 작은 기능으로 개발

서비스 기능은 고객에서부터 만들어지는 것이지 담당자의 추측에 의해서 만들어지는 것이 아님을 유의했습니다.

- 공통 개발 범위의 확대(full stack engineer)

시스템이 고도화되면 개발자가 특정 일에 전념하는 것이 더 효율이 좋을 때가 있습니다. 예를 들어 machine learning 분야, search & indexing, big data analysis 와 같은 분야가 있습니다.  그러나 서비스 개발 초기, 그리고 일반적인 웹 개발에서는 분야를 나누지 않는 것이 오히려 도움이 된다고 믿습니다. front-end와 back-end를 나눈다든지, database sql만 개발한다던지. 이렇게 세분화할 필요가 없는 부분을 세분화하게 되면 특정 분야의 전문성에서 오는 효율보다 개발자의 의존 관계에서  오는 비효율이 더 부각되게 됩니다. 

front-end, back-end, database 정도는 한 개발자가 처리하는 기본적인 개발자의 범위로 정의하고 들어갔습니다. 이것을 full stack engineer라고 하죠. 그래서 한 기능은 온전히 한명의 개발자가 홀로 처리할 수 있도록 했고 이는 최대의 개발 효율로 이어졌다고 생각합니다. 

3. 이번에 채용한 개발방식

사업기획(기획팀) -> 상위 기획, 상세 기획, 디자인, 마크업, 코딩 (개발팀) -> QA(QA팀) -> 배포(개발팀) -> 운영(개발팀, 운영팀)

이 개발방식에서는 개발자의 범위가 극단적으로 넓어졌고 능동적이지 않으면 살아 남지 못하는 구조가 되어 버렸습니다.  전통적인 개발자의 범위인 분석, 설계, 개발, 리뷰, 테스트를 벗어나서 기획, 디자인, 마크업까지 확대를 한 것입니다.

상세 기획은 서비스를 가장 잘 이해하는 사람이 하는 것이 좋습니다. 저는 주로 balsamiq이라는 마크업 툴로 wireframing을 잡는 정도로에서 상세 기획을 했습니다.모든 ux 디테일까지 상세 기획에 넣을 필요는 없다고 보입니다. 어차피 70%이상은 바뀌기 때문이죠. 

요즘 디자인 프레임워크가 많이 있어서 아주 고 퀄리티를 원하지 않는다면 타협가능한 선이 많이 있습니다 . 기본 베이스 디자인 프레임워크로 bootstrap을 채택했고 관리도구의 경우 flatify(bootstrap theme)을, 아이콘의 경우 font-awesome을 채용해서 그대로 사용했습니다. 유일하게 전문 디자이너에게 의뢰한 것은 로그인 화면의 배경 이미지였습니다. 저희 회사의 규모상 서비스 화면의 theme은 개발자가 직접 하였지만 인력이 부족한 스타트업의 경우라면 unify와 같은 service theme을 그대로 채택을 해도 무방하지 않을까 생각합니다.

마크업은 많이 해 보는 수밖에는 없습니다. 한가지 분명한 사실은 마크업 기술을 갖지 못하는 웹 개발자는 파일럿을 진행할 수가 없기 때문에 다른 전문성 있는 분야를 갖지 않는 한 살아 남기 힘듭니다. 

상세 기획 -> 디자인 -> 마크업 -> 코딩 -> 리뷰 의 프로세스는 기능마다 반복이 되었다는 점이 중요합니다. 매번 상세 기획을 가져갈 필요는 없고 기능이 기존 기능과 유사하거나 많은 변화가 있지 않다면 생략가능합니다. 

다음에는 좀 더 상세한 진행 과정의 일들을 공유해 보도록 하겠습니다.