역량강화스터디 1월 발표 피드백

발표 ppt 역량강화스터디_1월발표.pdf

대본 안녕하세요 역량강화스터디 발표를 시작하겠습니다. 저희 팀은 웹 전체를 아우르는 의견 공유 시스템이라는 아이디어를 가지고 강대명 멘토님이 지도해주시고, 안재욱, 윤승원, 정현진 멘티로 이루어져 있습니다.

저희 발표는 크게 세 주제로 구성되어 있습니다. 프로젝트 소개를 한 후, 전체 시스템이나 개발할 기능, 전략, 기술 등 설계에 대해 말씀드리고, 그 다음으로 추후 계획으로 진행되게 됩니다.

우선 저희 서비스를 간단하게 설명해 드리겠습니다. 저희는 사이트마다 커뮤니케이션 기능에 제한이 있어, 의견을 달 수 없다는 문제, 그리고 그렇게 의견을 남기려면 사이트마다 로그인을 하고, 자신이 남긴 의견에 대한 반응을 한곳에 모아서 확인하기 힘들다는 문제점을 느꼈습니다. 그래서 저희는 이 문제를 크롬 익스텐션의 형태로 어느 사이트에서나 저희 서비스를 이용한다면 사이트의 특정 위치에 의견을 남길 수 있고, 그것을 하나의 피드로 통합해서 한 곳에서 보여주고, 유저에게 도움이 될 것같은 피드는 추천을 통해 제공하고, 자신이 여러 곳에 의견을 남겼더라도 한 곳에서 모아서 그 반응을 확인할 수 있는 서비스를 구상하게 되었습니다.

다음으로 이런 서비스를 만들기 위해 어떤 시스템이 필요한지 설명해 드리겠습니다. 저희는 크롬 익스텐션과 웹사이트로 제공되는 개인화 홈, 그리고 이 둘에서 사용하는 API서버, 여러 데이터가 저장될 DB서버, 로그와 이미지같은 것들이 저장될 아마존 S3, 캐시 서버, 그리고 사용자들에게 적절한 피드를 추천하기 위한 학습 서버와 학습을 위해 필요한 학습 데이터 서버, 그리고 로킹과 모니터링을 할 수 있는 서버로 구성되어 있습니다.

저희 프로젝트에 대해 간단하게 설명해드렸는데, 과연 어떤 상황에서 저희 서비스가 필요할 지 간단한 시나리오를 통해 알려드리겠습니다. 먼저 프로그래밍에 관심이 있는 대학교 1학년 문과생 A씨가 있다고 가정합시다. A씨는 프로그래밍을 배워보려고 포털 사이트에 프로그래밍을 검색했지만, 학원 광고와 사전적 정의같은 정보들 뿐이라 A씨에게는 별로 도움이 되지 않았습니다. 그래서 A씨는 누군가 자신이 궁금한 것에 대해 소통을 하고 싶다는 생각을 했습니다. 그런 A씨는 저희 서비스를 알게 되어 크롬에 설치를 하고, 프로그래밍을 어떻게 배워야 하는지 의견을 남기고, 다른 사이트를 보고 있었습니다. 그리고 얼마 후 A씨가 남긴 의견에 누군가가 답글을 달았다는 알림이 와서, 새 탭을 열어보니 개인화 홈이 표시되어 의견에 대한 답글을 확인하고, 도움이 되어서 답글을 추천해 줬습니다. 그리고 다시 개인화 홈을 보니, 프로그래밍에 대한 또 다른 피드들이 자동으로 추천되어 있어서 A씨는 피드들을 둘러보며 자신이 모르던 여러 정보들을 알 수 있습니다. 이것은 저희 서비스를 사용할 수 있는 극히 일부 상황을 예를 들어서 써 본 것입니다. 이 다음으로 저희 프로젝트를 어떻게 설계했는지 소개해 주시겠습니다.

지금까지 이 서비스의 간단한 소개와 사용자 시나리오, 그리고 전체적인 시스템에 대해 간략하게 소개드렸습니다. 말씀드린 그러한 사용자 시나리오대로 서비스가 동작하게 하려면 위해 어떤 기능을 개발해야 할지, 어떤 정책을 수립할지에 대해 토의를 해봤습니다. 먼저 인터넷 브라우저의 익스텐션을 이용해, 사용자가 접속하는 모든 웹페이지에서 댓글을 남길 수 있는 UI를 개발할 계획이고, 남긴 댓글을 한눈에 확인할 수 있는 개인화 홈을 웹 서비스로 개발할 계획입니다. 이를 더욱 상세하게, 더 잘게 쪼개어 세부적인 기능들을 정리해 문서화하였고, 그 자세한 내용은 잠시 후에 소개드리겠습니다. 다음으로는 서비스 제공에 있어서 어떤 정책을 수립해야할지에 대해 이야기해봤습니다. 댓글이 달려있을 때 그 답글에 대해서 depth는 몇으로 할지, 답글에 대한 평가도 있어야 할지? 또 댓글에 대해 평가를 한다면 어떤 식으로 할지? 좋아요/싫어요로 할지 별점을 매길지 업다운 보팅을 할지 등에 대한 고민을 했습니다. 또 UI에 대해서, 입력창 숨기기 보이기를 어떻게 할지, 개인화 홈의 내용에서 다시보지않기 같은 것들을 넣을지 등에 대한 고민. 이처럼 다양한 상황을 생각해보며, 구체적으로 어떤 정책을 수립할지에 대한 고민을 했습니다. 토의한 이야기들은 구글 독스에서 다같이 문서화를 계속 하고 있습니다.

다음은 UI에 대한 내용입니다. 웹에서 의견 기능이 없는 사이트에서 의견을 남길 수 있는 기능을 제공하기 위해, 크롬 익스텐션을 이용할 것입니다. 크롬 익스텐션으로 UI를 만들어 제공할 구체적인 feature들을 정하기 위해, 다음과 같이 와이어프레임을 구성해보았습니다. 왼편에 보이는 개인화 홈 UI처럼, 웹 페이지 별로 그곳에 달린 의견들을 별점순 혹은 최신순으로 보일 것이고, 의견 평가도 가능하게 할 것입니다. 그리고 오른편에 보이는 브라우저 익스텐션 UI처럼, 사용자가 방문한 웹페이지의 맨 오른편에 사이드바가 있어서, 페이지의 어느 부분에 의견이 몇 개 달렷는지. 그리고 그 부분으로 스크롤을 내리면 페이지의 내용 중 어느 부분에 의견이 달렸는지 표시되고, 사이드바의 그 부분을 클릭하면 의견 내용 및 입력 박스가 표시됩니다. 이러한 모습으로 UI를 계획하였습니다.

개발 진행은 전반과 후반으로 나눴으며, 중간발표를 기점으로 합니다. 전반에는 웹 전체를 아우르는 의견 공유 시스템 자체를 구현할 것입니다. 핵심 기능인 개인화홈 서비스, 댓글 서비스를 위한 브라우저 익스텐션을 개발할 것이고, 이에 필요한 API와 DB를 설계하여 구성할 것입니다. 이를 통해 댓글을 남기고, 댓글을 평가하고, 웹페이지를 평가하는 기능을 통해 데이터를 모을 것입니다. 데이터는 저희 팀원들끼리 부지런하게 서비스를 쓰면서 모으고, 주변 사람들한테 부탁하든지 해서 최대한 모은 후에, 많이 모인 데이터를 기반으로 머신러닝을 함으로써, 사용자가 만족할만한 사이트 혹은 키워드를 추천해주는 부분을 후반에 개발할 계획입니다.

이 다음부터는 저희가 지금까지 계획한, 더욱 세부적인 내용에 대해 소개드리겠습니다.

<설계한 내용 - 개인화 홈 슬라이드>

설계를 시작하면서 3명의 팀원이 병렬적으로 작업하기 위해 컴포넌트를 명확히 분리할 필요성이 생겼습니다. 또한 개발 명세를 구체화하기 위해 먼저 개발 할 컴포넌트를 분리하는 작업을 진행 했습니다.
그래서 개발 요소인 크롬 익스텐션에 대해 아래 표와 같이 의견 리스트 보여주기, 의견 삭제하기와 같이 컴포넌트를 분리했습니다.
그리고 지금까지 개발 경험을 토대로 볼 때 혼자와 개발할 때와 달리 팀원들과 병렬적으로 개발을 진행할 때 서로 명세를 잘못 이해하고 개발하여 나중에 다시 코드를 다 지우고 다시 작성하는 것 같은 비효율적이였던 협업 경험이 있었습니다.
이렇게 명세를 잘못 이해하고 구현하는 것을 막기 위해 “로그인을 하지 않아도 의견 리스트 목록을 보여준다” 와 같이 세부사항 중 놓칠 수 있는 것을 아래 표와 같이 정리 했습니다.

<설계한 내용 - 개인화 홈 슬라이드>

마찬가지로 구현하게 될 개인화 홈에 대해서도 컴포넌트를 분리하고 구현하게 될 세부사항 중 놓칠 수 있는 것들을 정리했습니다.
이제 이렇게 분리된 컴포넌트와 구체화된 명세를 바탕으로 병렬적이고 미스커뮤니케이션이 없는 정확한 구현을 진행할 예정입니다.

<설계한 내용 - DB모델링>

이전에 개발해보면서 디비 모델링을 명확히 하지 않고 그 때 그 때 필요한 칼럼과 테이블을 추가하면서 개발하여 나중에 마이그레이션과 전체 설계에 심각한 문제가 되고 시간이 지연된 경험이 있습니다.
이 문제를 막기 위해 명세화한 컴포넌트에 대해서 어떤 테이블과 칼럼이 필요한지, 빼야할지 계속해서 토론을 거치면서 논리적 모델링을 아래와 구체화 하는 과정을 진행하고 있습니다.

<설계한 내용 - 웹서버 API 슬라이드 1,2>

서버와 클라이언트가 통신하는 API문서를 작성하기에 앞서 프로토콜의 전체 규칙을 정의했습니다.
모든 API의 결과를 담을 수 있는 response 형식을 정의했고 response 코드에 대한 구체적인 의미를 정의했습니다.
또 페이네이션을 어떻게 할 것인지, access token을 이용한 인증 규칙과 만료시각 request format을 정의했습니다
전체적인 프로토콜의 규칙을 정의한 후 구글 독스에 각각의 API가 어떤 request parameter를 가지는 지, response를 가지는지 정의하고 예시를 구체화 하는 과정을 거치고 있습니다.

<설계한 내용 - 추천>

서비스의 차별화 될 요소인 추천 기능을 구현하기 위해 factor를 수집하는 것이 매우 중요하고 서비스 초기 부터 수집을 준비하기 위해 미리 어떤 factor를 수집할지 정리하는 과정을 거쳤습니다.
또 TF/IDF, 단어 이미지 수와 같이 문서 분석 크롤링을 할 때 어떤 요소를 수집할 것인지 정리했습니다.
그리고 사용할 추천 기술로 collaborative filitering, regression를 계획했고 이전에 이 기술에 대한 잘몰랐기 때문에 코세라에서 강의를 보면서 어떤 원리로 작동하는지를 공부하고 응용 사례를 실습해보았습니다.

<기술스택 1, 2, 3 슬라이드>

이 프로젝트에서 목표하는 명세를 효과적으로 구현하기 위해 가장적절하다고 생각되는 기술 스택을 선택했습니다.
스택 그림을 보면서 왜 이 스택을 우리 프로젝트에 사용하기로 했는지 설명 함

<개발 일정>

마지막으로 개발 일정을 말씀드리겠습니다.
설계를 명확히 했을 때 바로 구현을 시작하는 것 보다 더 빠르게 프로젝트의 결과를 낼 수 있다고 생각합니다. 그래서 위 피피티에서 설명드렸던 빠진 내용에 대해 계속 토론을 거치면서 UI설계와 컴포넌트 별 명세를 구체화하고 데이터 베이스 모델링과 API 문서를 구체화는 과정을 2월 중순 까지 거칠 예정입니다.
그리고 2월 중순부터 4월 중순까지 설계된 문서를 바탕으로 실제 서비스와 API 서비스, 로그 모니터링을 구축하여 실제 서비스를 런칭할 것입니다.
서비스의 차별화 될 요소가 될 추천 기능인 크롤링을 통한 데이터 수집, 피드 추천 기능은 서비스 구현와 같이 병렬적으로 2월 중순 부터 6월 까지 함께 개발될 예정입니다.

soma7 / Mentoring

역량강화스터디 1월 발표 피드백 #10