MBC뉴스 온라인 서비스 개편
MBC NEWS
"MBC뉴스 온라인 서비스 개편" 프로젝트 내용을 정리한다.
2019년 2월에 시작하여 12월 서비스 오픈까지 10개월이 소요됐으며, 필자는 PM 역할로 참여했다. 개편의 일부 모듈(NOPSA : News Online Platform Statistics API)은 개발 리더로 기획, 분석/설계, 개발을 수행했다.
뉴스 온라인 서비스의 낡은 이미지를 개선하고 뉴스 콘텐츠 소비를 확대해서 장기적 관점에서 수익성을 강화하는 것이 프로젝트의 목표였다. CMS까지 모두 개편하면 더 좋았겠지만, 그러기엔 비용과 시간이 만만치 않았기 때문에 먼저 사용자 접점의 View Layer 프로젝트를 진행하고 CMS 개편은 다음 프로젝트에서 진행하기로 했다.
주요 개발 및 개선 내용은 다음과 같다.
노후화된 MBC뉴스 웹/앱 서비스 개편 및 신규 개발
PC 및 모바일 웹 서비스 개편 기획 및 개발
모바일 및 스마트워치 앱 신규 서비스 기획 및 개발
사용자 특성에 따른 개인화 및 콘텐츠 추천
동영상 플레이어 개발
사용성 개선
PC, 모바일 웹/앱 각각의 사용행태에 최적화된 UI/UX 적용
모바일 환경 로딩 속도, 라이브 스트리밍 안정성 등 개선
수익화
동영상 및 추천기사광고 적용
이직 이후에 꽤나 충격을 받았던 것 중 하나가, IT가 메인이 아닌 회사에서 IT 프로젝트를 진행하려면 일당백을 해야 한다는 사실이었다. 뭐, 어찌 보면 너무나 당연한 말이긴 한데... 업무가 세분화되어있는 SI 회사에서는 프로젝트에서 본인의 역할에 맞는 업무를 부여받고 전문성 보이면 그만이었는데, 그런 체계가 없는 곳에서는 결국 프로젝트를 진행하려는 사람이 ATOZ 해야 하더라. (관련해서 느낀 게 많았는데, 이건 별도의 글에서 정리해 보려 한다.)
프로젝트의 시작과 관리
무튼, 보도에서 프로젝트의 진행을 요청받아 RFP 작성 업무를 시작했다. 이후 지원한 개발업체의 제안서를 검토하여 선별된 업체들의 발표를 진행하고, 최종 선정에 이르렀다. 늘 그렇지만, 제안 내용과 비용 그리고 이력이 선택의 절대적 기준이 될 수 없음을 다시금 느낀다.
개발업체의 일정 관리 도구에 대한 고민을 하다가 이슈관리도 함께 하기 위해 Jira를 선택했다. 개인적으로는 MS Project를 선호하지만, 다수의 사용자와 함께 사용하기 위해 선택했다. 프로젝트 종단에 산출물 이슈가 발생했을 때, Confluence를 함께 사용하지 않은걸 꽤나 후회했더랬다.(늘, 그놈의 돈이 문제다 -_ -)
프로젝트 관리 도구다양한 플랫폼의 애플리케이션이 업체를 통해 개발되는 프로젝트다 보니, ALM이 보다 중요했다. 복수의 SVC를 사용해서 형상관리를 했고 Jenkins와 SornarQube를 연동한 품질관리를 진행했다. 단위/통합 테스트까지 진행하고 싶었지만, 현실과 이상의 괴리 앞에 눈물을 머금었다. -_ -;
Application Lifecycle Management개발
요구사항에 있었지만 개발업체에서 해결할 수 없는 부분은 자체 개발을 통해 결자해지(-0-;) 하기로 했다. NOPSA(News Online Platform Statistics API) 모듈이 바로 그것인데, 다양한 온라인 플랫폼(포털, SNS, 유튜브 등)을 통해 유통, 소비되고 있는 뉴스 콘텐츠의 통계분석 API를 개발하고자 했다. 개편된 서비스에서 NOPSA를 활용해서 뉴스 콘텐츠의 소비를 증대시키는 것이 최종 목표였다.
NOPSA ArchitectureNOPSA는 B2C 서비스에서, 그것도 첫 페이지에서 사용되는 만큼 문제가 발생할 경우 빠른 대응이 필요했다. 해서 추가로 실시간 모니터링이 가능한 서비스도 함께 개발했다.
NOPSA Monitoring Service프로젝트 개발 결과
플랫폼 별(PC 웹, 모바일 웹, 모바일 앱, 워치)
PC 웹 (개편 전 vs 개편 후)
모바일 웹(개편 전 vs 개편 후)
모바일 앱(안드로이드/iOS)
갤럭시 워치
애플 워치기능 별
수익화(동영상 프리롤, 추천기사광고)
동영상 플레이어(재생목록, 온에어)
개인화(북마크, 뉴스판, 큐레이션)
콘텐츠 추천
웹과 앱에서 "통계 기반 기사 추천"에 적용된 NOPSA프로젝트 소고
여느 프로젝트와 마찬가지로 우여곡절은 있었지만, 다행히 예정된 일정대로 서비스를 오픈했고 큰 문제없이 서비스가 안정화됐다. 꽤나 많은 플랫폼을 개발해야 하고 운영 중인 B2C 서비스라 부담이 됐지만 프로젝트 인원이 잘 협력(이라고 쓰고 인원을 갈아 넣.. 아니다.. -_ -)해서 프로젝트를 성공적으로 완료할 수 있었다.
PM 입장에서 몇 가지 느낀 점을 정리하면서 글을 마무리한다.
PM은 나침반
프로젝트 인원들은 PM을 바라보고 간다. 때문에 PM이 프로젝트를 이끌어 갈 수 있게 책임과 권한을 모두 부여받아야 한다. 책임만 주고 권한을 주지 않으면 관리가 산으로 가고, 개발업체도 누구 말을 들어야 할지 어수선해지기 마련이다.
개발업체의 선정 기준은 "책임감"
좋은 개발업체를 선정하는 것만큼 프로젝트에서 중요한 게 없다. 문제는 "좋은"의 정의가 어렵다는 거다. 해당 업체가 이전 프로젝트에서 끝까지 책임감 있게 행동했는지 레퍼런스 체크를 반드시 하자. 책임감 있는 업체가 기술과 경험이 뛰어난 업체보다 낫다.
기획과 개발이 싸운다면 기획과 깐부 해라
IT 프로젝트에서 기획과 개발의 힘겨루기는 일상이다. 10년 전에도 그랬고 20년 전에도 그랬다. 성공적으로 프로젝트를 이끌기 위해서는 적절한 선에서 둘을 융합하는 노하우가 필요하다.(말이 쉽지...) 일반화의 오류일 수 있지만, 기획이 개발의 방어기제에서 자유롭기란 쉽지 않기 때문에, 가급적이면 기획에 힘을 실어주는 게 좋다. 그래야 어느 정도 균형이 맞는다.
일에 대한 과욕이 수명을 갉아먹는다
PM을 하면서 그 안에서 별도의 작은 프로젝트를 진행하는 미친 짓은 절대 하지 말자. 생각보다 힘들다. 맡은 바 역할에 충실하자. 그것만 해도 충분하다. ^^:
