<div id="readability-page-1" class="page"><div>DataColon 개발 후기
<ul>
<li><a href="http://flowkater.io/project/datacolonio-review-1/">1. 들어가며</a> (현재 글)</li>
<li>
<ol start="2">
<li>백엔드 편</li>
</ol>
</li>
<li>
<ol start="3">
<li>프론트엔드 편</li>
</ol>
</li>
<li>
<ol start="4">
<li>개발 외 이야기</li>
</ol>
</li>
</ul>
 
<hr>

드디어(?).. 한달여에 걸쳐서 릴리즈를 하게 되었습니다. 첫 커밋이 찍힌 날짜를 보니 1월 26일이니 한달을 훌쩍 넘겼네요.
기존에 Slack 채널과 Notion 을 이용하여 스터디 노트를 전달해드렸는데, 드디어 자체 웹페이지를 만들게 되었습니다.
일단 결과물부터 보시죠.
<a href="https://www.datacolon.io/" target="_blank">https://www.datacolon.io/</a>
(코스나 렉쳐 노트를 보시려면 가입을 하셔야 합니다. ㅎㅎ)
 
<h3 id="1-동기"><a href="#1-%EB%8F%99%EA%B8%B0" aria-label="1 동기 permalink"></a>1. 동기</h3>
사실 처음에는 컨텐츠가 주가 되는 서비스이기 때문에 자체 개발보다는 강의 플랫폼을 제공해주는 서비스들을 활용해보려고 했습니다. 대표적으로 teachable 같은 서비스가 국내에서 많이 사용되고 있는 것 같고 그 외에도 구글링을 해보면 꽤 많은 강의 플랫폼 서비스들이 존재합니다.
항상 서비스의 핵심(컨텐츠)이 중요하고 개발에 많은 시간을 쏟기 보다는 실제 가치를 발생시킬 수 있는 컨텐츠 제작에 집중해야 하는 건 사업을 해보지 않은 바보도 알만한 사실이었습니다.
그런데.. 이러한 서비스들의 공통적인 문제점이 있었는데 제가 내세우는 학습 가치인 Coverage -&gt; Practice -&gt; Insight 의 핵심이 되는 퀴즈나 문제 시스템이 굉장히 초보적인 수준에서 지원되거나 열악한 시스템을 가지고 있었습니다. 월에 몇십만원까지 하는 서비스도 선결제를 해서 사용해봤는데 모두 다 영상 강의 컨텐츠에 맞추어져 있다보니 제가 원하는 수준으로 구현할 수가 없었습니다. (물론 이 시스템은 아직 프로덕션에 반영되지 않았습니다. 하지만 이제 준비가 되었고 열심히 개발 중입니다.)
또한 결제 시스템 문제가 있는데 제 서비스는 국내 고객들을 타겟팅하는 서비스인데 해외 비자 카드만 지원된다거나 국내 결제로 인한 멤버십 연동 지원이 대부분 안되는 것들이 보통이었습니다.
그리고 데이터 과학 컨텐츠 특성상 수식이 많이 입력되는데 기본적으로 Tex 렌더링을 해주는 강의 플랫폼은 전무했고 차라리 그냥 기존에 Slack 채널과 Notion 을 이용하는게 훨씬 합리적이었습니다. (Notion이 좀 불편하고 불완전한 부분은 있어도 대부분 포맷은 지원하므로..)
또 하나 결정적인 문제점이 있었는데 Slack과 Notion등을 조합한 서비스의 초반 러닝 커브 문제였습니다. IT 업계나 스타트업에서 일하면서 Slack은 카카오톡의 업무 버전으로 쉽게 치환하여 사용하는 우리와는 다르게 대부분 처음 접하는 사람에게는 이 툴 자체가 굉장히 어렵고 힘든 서비스 중 하나라는 걸 뼈저리게 깨달았습니다. Slack 사용의 어려움을 겪어 스터디 신청 하루만에 환불 요청 사례가 나오고 나서부터는 비전공자나 입문자들을 앞으로도 많이 받아야하는 입장에서는 큰 커브 중 하나였죠. Notion도 마찬가지인게.. 사실 그냥 노트앱에 하나이고 굉장히 훌륭한 프로덕트이지만 스터디를 등록한 멤버 입장에서는 뭔가 또하나 깔고 가입하고 공부해야하는 툴에 불과한 러닝 커브라는 것도 알게 되었습니다.
정리를 하자면,
기존 강의 플랫폼들은,
<ol>
<li>퀴즈-Feedback 시스템의 부재</li>
<li>국내 결제 미지원</li>
<li>Tex 렌더링 미지원</li>
</ol>
이런 문제들이 있었고, 기존에 활용하던 Slack과 Notino은 입문자들에게는 그것조차 하나의 배워야하는 큰 공포라는 것을 뼈저리게 깨닫게 되면서 자체 플랫폼 개발의 당위성(?)을 찾고 (라고 쓰고 자기합리화라고 읽는다..) 결국 개발에 착수하게 됩니다.
물론 기존에 선형대수학과 통계학 코스가 몇 십명의 스터디원을 거치며 검증이 되기도 했고 단순 강의 제공이 아니라 풍부하게 연습할 수 있는 퀴즈를 통해서 학습의 최적 사이클인 Coverage -&gt; Practice -&gt; Insight이 충분히 가치가 있다는 나름의 확신도.. 잠깐 컨텐츠를 내려놓고 개발을 집중하는데 큰 힘이 되었습니다.
 
<h3 id="2-배경"><a href="#2-%EB%B0%B0%EA%B2%BD" aria-label="2 배경 permalink"></a>2. 배경</h3>
데이터 분석을 위해 사용하는 Python과 서버 개발을 위한 Python은 그 궤과 다릅니다. 모델 서빙이나 간단한 서버리스 처리를 위해 Flask (Zappa)를 이용하여 심플한 API를 개발했었고 회사 자체 CMS나 백오피스 시스템으로 활용할때 간단히 이용한 것 외에는 경험이 없었습니다. 물론 과거에 Rails로 백엔드 개발하기도 했고 소프트웨어 마에스트로 최종 인증하고 처음 앱을 런칭할때도 Rails로 다 먹고 살았지만 그마저도 투자를 받고 팀이 커지면서 서버 개발자가 들어오고 나서부터는 아예 손을 똈었죠.
특히, Rails 프레임워크를 몇 년 쓰면서 풀프레임웤에 대한 질림(?) 때문에 그 뒤로는 간단히 개발할때 Flask, Express 등의 경량 웹프레임워크만 선호했었고 개발팀에게도 그것을 추천했었습니다.
하지만 결국 Flask 등의 경량 웹프레임워크로 프론트엔드까지 서비스의 다양한 부분을 혼자서 개발하기엔 어렵다는 판단을 내렸고 결국 Django를 선택하게 됩니다. 그리고 다시 풀프레임웤의 고마움(?)을 많이 느꼈네요.
프론트엔드는 원래 Django를 선택하면서 Template을 쓰려고 했으나 Template 또한 하나의 시스템이고 그걸 위에 배워야하는 규칙이 꽤 존재한다는 것을 깨닫고 바로 접고 React로 프론트엔드를 선택합니다. 이전에 운영하던 앱 서비스의 내부 어드민, 대쉬보드 패널, 백오피스 프론트엔드 등을 자주 리액트로 만들었기 때문에 선택을 했습니다.
결국 Django로 백엔드를 React로 프론트엔드를 개발하게 되었는데.. 가장 중요한 프로토콜을 기존 API 시스템으로 할지 GraphQL로 할지 5초간 고민하다가 바로 GraphQL을 선택하게 되었습니다. 사실 Django도 처음이고 Django에서 GraphQL을 어떻게 구현해야하는지 전혀 몰랐지만 React에서 Apollo의 강력함을 맛보고 초기 입문시절때 React + Typescript + Redux + Saga 조합으로 Redux 타입 지옥에 빠져서 너무 괴로웠던 기억이 있었고 React Hook의 강력함과 Apollo가 결합되어 엄청난 생산성과 심플한 코딩 작업을 경험한 터라서 망설이지 않고 선택을 했습니다.
여튼 이렇게 스택을 정하는 과정이 여차 저차에서 약 1주일 정도 걸렸던 것 같네요.
정리를 하자면,
<ul>
<li>백엔드: Django + Grpahene (Python GraphQL Schema 지원)</li>
<li>프론트: React + Typescript + Apollo</li>
</ul>
서버 인프라는 AWS, 배포를 위해서 Elastic Beanstalk을, RDS는 MySQL로, CDN은 Cloud Front (+S3)를 이용하되 프론트 배포 자체는 이 블로그와 같이 netlify를 이용해보았습니다. S3를 안쓰고 netlify를 쓴 이유는 무엇보다 배포의 편리함이 압도적이였고 불가피하게 성능에 영향을 주는 큰 Asset 들은 대부분 AWS CDN 처리를 했습니다.
<h3 id="3-들어가며"><a href="#3-%EB%93%A4%EC%96%B4%EA%B0%80%EB%A9%B0" aria-label="3 들어가며 permalink"></a>3. 들어가며</h3>
비개발자인 디자이너 분과 개발자인 저 혼자서 한달여간 삽질해가면서 프로덕션 단계의 프로젝트를 진행해나가는게 쉽지는 않았고 거의 막바지 2주동안은 새벽 4시 퇴근이었던 것 같습니다. 블로그도 작년 하반기에 만들어놓고 거의 손놓고 있었고 일주일 3회는 하던 운동도 막바지 2주동안은 한번 밖에 못갔었네요. 이 글을 쓰면서 한번 정리를 하고 다시 바이오리듬도 맞추고 프로세스를 정비하고 다시 일을 해볼려고 합니다. (과연..?)
다음 두 편은 조금 더 구체적인 개발 스택 얘기를 적도록 하겠습니다. 아마 백엔드 편과 프론트엔드 편이 될 것 같네요. 아직 현 시점(2020년 3월)에서는 국내에서 GraphQL을 많이 도입하지는 않은 상황이라 구글링을 하다가 발견한 누군가의 큰 도움이 되길 바라며 다음 편도 빠르게 작성해서 올리겠습니다.</div></div>

flowkater's data;

flowkater

DataColon 개발 후기
1. 들어가며 (현재 글)
백엔드 편
프론트엔드 편
개발 외 이야기
드디어(?).. 한달여에 걸쳐서 릴리즈를 하게 되었습니다. 첫 커밋이 찍힌 날짜를 보니 1월 26일이니 한달을 훌쩍 넘겼네요.
기존에 Slack 채널과 Notion 을 이용하여 스터디 노트를 전달해드렸는데, 드디어 자체 웹페이지를 만들게 되었습니다.
일단 결과물부터 보시죠.
https://www.datacolon.io/
(코스나 렉쳐 노트를 보시려면 가입을 하셔야 합니다. ㅎㅎ)
1. 동기
사실 처음에는 컨텐츠가 주가 되는 서비스이기 때문에 자체 개발보다는 강의 플랫폼을 제공해주는 서비스들을 활용해보려고 했습니다. 대표적으로 teachable 같은 서비스가 국내에서 많이 사용되고 있는 것 같고 그 외에도 구글링을 해보면 꽤 많은 강의 플랫폼 서비스들이 존재합니다.
항상 서비스의 핵심(컨텐츠)이 중요하고 개발에 많은 시간을 쏟기 보다는 실제 가치를 발생시킬 수 있는 컨텐츠 제작에 집중해야 하는 건 사업을 해보지 않은 바보도 알만한 사실이었습니다.
그런데.. 이러한 서비스들의 공통적인 문제점이 있었는데 제가 내세우는 학습 가치인 Coverage -> Practice -> Insight 의 핵심이 되는 퀴즈나 문제 시스템이 굉장히 초보적인 수준에서 지원되거나 열악한 시스템을 가지고 있었습니다. 월에 몇십만원까지 하는 서비스도 선결제를 해서 사용해봤는데 모두 다 영상 강의 컨텐츠에 맞추어져 있다보니 제가 원하는 수준으로 구현할 수가 없었습니다. (물론 이 시스템은 아직 프로덕션에 반영되지 않았습니다. 하지만 이제 준비가 되었고 열심히 개발 중입니다.)
또한 결제 시스템 문제가 있는데 제 서비스는 국내 고객들을 타겟팅하는 서비스인데 해외 비자 카드만 지원된다거나 국내 결제로 인한 멤버십 연동 지원이 대부분 안되는 것들이 보통이었습니다.
그리고 데이터 과학 컨텐츠 특성상 수식이 많이 입력되는데 기본적으로 Tex 렌더링을 해주는 강의 플랫폼은 전무했고 차라리 그냥 기존에 Slack 채널과 Notion 을 이용하는게 훨씬 합리적이었습니다. (Notion이 좀 불편하고 불완전한 부분은 있어도 대부분 포맷은 지원하므로..)
또 하나 결정적인 문제점이 있었는데 Slack과 Notion등을 조합한 서비스의 초반 러닝 커브 문제였습니다. IT 업계나 스타트업에서 일하면서 Slack은 카카오톡의 업무 버전으로 쉽게 치환하여 사용하는 우리와는 다르게 대부분 처음 접하는 사람에게는 이 툴 자체가 굉장히 어렵고 힘든 서비스 중 하나라는 걸 뼈저리게 깨달았습니다. Slack 사용의 어려움을 겪어 스터디 신청 하루만에 환불 요청 사례가 나오고 나서부터는 비전공자나 입문자들을 앞으로도 많이 받아야하는 입장에서는 큰 커브 중 하나였죠. Notion도 마찬가지인게.. 사실 그냥 노트앱에 하나이고 굉장히 훌륭한 프로덕트이지만 스터디를 등록한 멤버 입장에서는 뭔가 또하나 깔고 가입하고 공부해야하는 툴에 불과한 러닝 커브라는 것도 알게 되었습니다.
정리를 하자면,
기존 강의 플랫폼들은,
퀴즈-Feedback 시스템의 부재
국내 결제 미지원
Tex 렌더링 미지원
이런 문제들이 있었고, 기존에 활용하던 Slack과 Notino은 입문자들에게는 그것조차 하나의 배워야하는 큰 공포라는 것을 뼈저리게 깨닫게 되면서 자체 플랫폼 개발의 당위성(?)을 찾고 (라고 쓰고 자기합리화라고 읽는다..) 결국 개발에 착수하게 됩니다.
물론 기존에 선형대수학과 통계학 코스가 몇 십명의 스터디원을 거치며 검증이 되기도 했고 단순 강의 제공이 아니라 풍부하게 연습할 수 있는 퀴즈를 통해서 학습의 최적 사이클인 Coverage -> Practice -> Insight이 충분히 가치가 있다는 나름의 확신도.. 잠깐 컨텐츠를 내려놓고 개발을 집중하는데 큰 힘이 되었습니다.
2. 배경
데이터 분석을 위해 사용하는 Python과 서버 개발을 위한 Python은 그 궤과 다릅니다. 모델 서빙이나 간단한 서버리스 처리를 위해 Flask (Zappa)를 이용하여 심플한 API를 개발했었고 회사 자체 CMS나 백오피스 시스템으로 활용할때 간단히 이용한 것 외에는 경험이 없었습니다. 물론 과거에 Rails로 백엔드 개발하기도 했고 소프트웨어 마에스트로 최종 인증하고 처음 앱을 런칭할때도 Rails로 다 먹고 살았지만 그마저도 투자를 받고 팀이 커지면서 서버 개발자가 들어오고 나서부터는 아예 손을 똈었죠.
특히, Rails 프레임워크를 몇 년 쓰면서 풀프레임웤에 대한 질림(?) 때문에 그 뒤로는 간단히 개발할때 Flask, Express 등의 경량 웹프레임워크만 선호했었고 개발팀에게도 그것을 추천했었습니다.
하지만 결국 Flask 등의 경량 웹프레임워크로 프론트엔드까지 서비스의 다양한 부분을 혼자서 개발하기엔 어렵다는 판단을 내렸고 결국 Django를 선택하게 됩니다. 그리고 다시 풀프레임웤의 고마움(?)을 많이 느꼈네요.
프론트엔드는 원래 Django를 선택하면서 Template을 쓰려고 했으나 Template 또한 하나의 시스템이고 그걸 위에 배워야하는 규칙이 꽤 존재한다는 것을 깨닫고 바로 접고 React로 프론트엔드를 선택합니다. 이전에 운영하던 앱 서비스의 내부 어드민, 대쉬보드 패널, 백오피스 프론트엔드 등을 자주 리액트로 만들었기 때문에 선택을 했습니다.
결국 Django로 백엔드를 React로 프론트엔드를 개발하게 되었는데.. 가장 중요한 프로토콜을 기존 API 시스템으로 할지 GraphQL로 할지 5초간 고민하다가 바로 GraphQL을 선택하게 되었습니다. 사실 Django도 처음이고 Django에서 GraphQL을 어떻게 구현해야하는지 전혀 몰랐지만 React에서 Apollo의 강력함을 맛보고 초기 입문시절때 React + Typescript + Redux + Saga 조합으로 Redux 타입 지옥에 빠져서 너무 괴로웠던 기억이 있었고 React Hook의 강력함과 Apollo가 결합되어 엄청난 생산성과 심플한 코딩 작업을 경험한 터라서 망설이지 않고 선택을 했습니다.
여튼 이렇게 스택을 정하는 과정이 여차 저차에서 약 1주일 정도 걸렸던 것 같네요.
정리를 하자면,
백엔드: Django + Grpahene (Python GraphQL Schema 지원)
프론트: React + Typescript + Apollo
서버 인프라는 AWS, 배포를 위해서 Elastic Beanstalk을, RDS는 MySQL로, CDN은 Cloud Front (+S3)를 이용하되 프론트 배포 자체는 이 블로그와 같이 netlify를 이용해보았습니다. S3를 안쓰고 netlify를 쓴 이유는 무엇보다 배포의 편리함이 압도적이였고 불가피하게 성능에 영향을 주는 큰 Asset 들은 대부분 AWS CDN 처리를 했습니다.
3. 들어가며
비개발자인 디자이너 분과 개발자인 저 혼자서 한달여간 삽질해가면서 프로덕션 단계의 프로젝트를 진행해나가는게 쉽지는 않았고 거의 막바지 2주동안은 새벽 4시 퇴근이었던 것 같습니다. 블로그도 작년 하반기에 만들어놓고 거의 손놓고 있었고 일주일 3회는 하던 운동도 막바지 2주동안은 한번 밖에 못갔었네요. 이 글을 쓰면서 한번 정리를 하고 다시 바이오리듬도 맞추고 프로세스를 정비하고 다시 일을 해볼려고 합니다. (과연..?)
다음 두 편은 조금 더 구체적인 개발 스택 얘기를 적도록 하겠습니다. 아마 백엔드 편과 프론트엔드 편이 될 것 같네요. 아직 현 시점(2020년 3월)에서는 국내에서 GraphQL을 많이 도입하지는 않은 상황이라 구글링을 하다가 발견한 누군가의 큰 도움이 되길 바라며 다음 편도 빠르게 작성해서 올리겠습니다.

<DataColon 개발 후기> - 1. 들어가며

댓글