이 글은 제가 최근 진행한 사이드 프로젝트 비티뮬레이트 (https://bitimulate.com) 개발을 하면서 생각했던 점들, 그리고 프로젝트 구조, 후기 등에 대하여 작성한 포스트입니다. 이 프로젝트는 오픈소스로 깃헙에 공개 되어있습니다 – Github Repo
개발 계기
직장인으로서의 사이드 프로젝트
직장생활을 하면서 개인 개발을 하는건, 힘들다. 회사도 꽤 바쁘긴 했지만,, 그 와중에 직장 외에도 오프라인 강의, 책 집필 같은 것 처럼 따로 개인적으로 하는일이 또 있어서, 개인적인 개발 할 시간이 정말 부족했다. (지금은 거의 다 끝나가서 조만간 시간적으로 조금 여유가 있는 상태가 될 것 같다)
퇴근 이후 시간, 그리고 주말에도 따로 하는 일이 있다보니, 어느새 정작 내 자신에게 투자하는 시간이 줄어들었다는것을 깨달았다. 사실 나는 취미가 개발이라 프로젝트 만드는걸 진짜 많이 즐기는데, 꽤 오랫동안 안했다보니, 한동안 뭔가 삶의 한 공간이 텅 빈 듯한 느낌이 들었다.
그렇다고 옛날처럼 개발을 하자니,,, 현실적으로 여유가 없고 해서 프로젝트를 시작하고 있질 못했다. 진짜 객관적으로 “바쁨”에도 불구하고 나도 인간인지라, 당연히, 가끔씩은 시간낭비를 할 때도 있었다. 유튜브에서 동영상을 본다던지…
결국, 내가 바빠서 개인 프로젝트를 못한다는건 핑계였다는 것을 깨달았다. 그래서, 내 자신과 한가지 약속을 했다.
“매일 12시마다 한시간씩만 투자해서 사이드 프로젝트를 진행하자!”
이 약속을 지키기 위해서, 매일 매일 개발 하는걸, 유튜브에서 라이브 스트리밍을 해서 기록을 남기기로 했다. (이 기록은 유튜브 재생목록 에서 열람 할 수 있다.)
라이브 코딩
진짜, 130일이 넘도록, 하루도 빠짐없이, 12시에 와서 사이드 프로젝트 진행을 했다. 이 부분은 정말.. 내 자신이 대견하다! 한번은 너무 피곤했는지, 퇴근하고 알람맞추고 잤는데, 그냥 그대로 쭉- 자버려서, 회사 대표님께서 전화로 깨워주신적도 있었다. (감사!) 덕분에 하루도 빠짐없이 개발을 했다! 후후…. 앞으로도 계속 진행 할 예정이다.
라이브 코딩을 하다보니, 뭔가 나의 팬 (?) 도 생겼다. 비록 많지는 않지만, 방송할 때 마다 매일매일 와주시는 고마운 분들이 계신다. 라이브 코딩은, 정말 재밌다. 시청자 분들이 실제로, 내가 개발을 하면서 고민을 하게 될 때 정말 큰 도움이 된다. 같이 고민하고, 좋은 테스터가 되주기도 하고, 개발 자체를 더욱 즐겁게 해준다.
그리고 또, 만약에 방송을 안키고 개발한다면, 개발 하다가도, 분명히 헛 짓 할 것임이 뻔한데 (예를들어.. 유튜브를 본다던지.. 페이스북을 본다던지… 프로젝트랑 별로 관련되지 않은 기술 공부를 한다던지..) 방송을 하고 있으니까, 뭔가 나를 지켜보고 있는 사람들이 있다는 생각에 살짝 부담을 가지고 하다보니 자연스레 헛짓은 잘 안하게된다 – 물론 가끔식 방송하다가 재밌는 동영상이 생각나면 방송하면서 시청자들이랑 같이 보기도 한다. 막, “김두한의 4달라!” 이런 동영상들…
시청자 분들 중에서 중국인 개발자가 한명 계셨는데, 한국말을 다 이해하신다. 그리고 그분 회사 동료도 가끔 오시는데, 그분도 한국말 잘하신다.. 채팅에선 영어로 말씀을 하시는데, 난 초반엔 영어로 대답하다갘ㅋㅋ 한국말을 잘 알아듣는것을 알고 아예 요즘은 한국어로 답한다. 아는 사람한테 그 시청자 신기하다고, 중국 개발자인데 한국어도 잘한다고! 얘기 했었는데 돌아온 말이 “그 반대가 바로 너야” . 생각해보니 별로 신기한건 아니었다. 내가 중국어를 할 줄 아는 한국 개발자였으니까..
여하튼 12시마다 와서 나와 개발시간을 함께 보내주는 사람들이 있어서 너무 고마웠다. 버그 리포팅도 해주고 정말 좋은사람들.
내가 그 사람들에게 도움을 받는 만큼, 나도 그 사람들에게 도움이 되기도 했다 (내 프로젝트와 개발 방식을 유용하게 배워가는 사람들이 꽤 있었다.)
가상화폐 시장
사이드 프로젝트 개발을 시작 할 때 쯤, 사이드 프로젝트로 무엇을 할 까 고민하던 도중, 그 시기가 7월 말이었는데, 가상화폐 시장이 옛날보다 더 뜨거워지고 있었다. 과연 좋은건지는 모르겠지만.
나 같은 경우는, 6월쯤에 잠깐 시험삼아 비트코인 / 이더리움을 사놓고 어느정도는 장기 투자로 묵혀놓고, 소량을 가지고 알트코인들을 거래해봤었다. 뭔가 이론상으로는, 싸게 사서 더 비싼 가격에 사면 이득이 나는거니까, 쉽게 돈 벌 수 있을 것 같았지만 그럴리가…. ㅋㅋㅋㅋ 없지.
많이 되는 액수는 아니였지만, 아무래도 가상화폐를 들고 있다 보니까 트위터랑 디씨인사이드 갤러리랑, 레딧, 기타 등등 사이트들을 살펴가면서 동향 살펴보고 그랬었는데, 그 시간이 너무 아까웠다.
올해 중순쯤에 되게 회사일도 바쁘고 개인적으로 하는 일도 바빠서, 주로 그냥 저녁시간에 잠자기 전에만 차트보고 커뮤니티 글 보고 그랬었는데, 그러다보면, 나의 귀중한 새벽의 1시간이 쓸대없이 낭비되는 것이 불쾌했다. 이 시간에 더 생산적인 일을 하는게 나에게 도움이 되기 때문에, 들고있던 가상화폐들은 처분했다. 그때 정말 처분하길 잘했다는 생각이 들었는데, 처분하고 얼마 안돼서 비트코인이랑 이더리움 가격이 엄청 떨어졌었다. 근데 나는 다행히 일찍 나와서 손해는 보지 않고 치킨 한 40번 먹을만한 소소한 ? 수익을 만들고 끝냈다. 물론, 그때 모든걸 비트코인으로 전환해놓고 지금쯤이였다면 치킨이 300번 먹을 정도이겠지만…. 뭐 그때는 비트코인이 이렇게 올라 갈 줄 몰랐으니까! (물론, 언젠가 떨어지겠지만, 그랬다가 또 올라가겠지만.. 알다가도 모르겠는 가상화폐 시장)
여하튼,, 그 시절에 디씨인사이드 보면서 상당히 재밌는 글들이 많았는데. 자주 보이는 글 패턴들이
- 내가 사면 떨어짐
- 내가 팔면 올라감
- 아. .한강 온도는?
그리고 진짜 중요한 돈을가지고 투기를 하고나서 손해보고 똥망~~~ 하는 사람들이 굉장히 많은가 하면, 수익을 엄청 많이 내서 부러움을 사는 사람들도 있었다. 아무래도 손해 본 사람이 있으니 수익을 보는 사람도 있는거겠지. 손해보는 사람들이 수익내는 사람들을 보면서 나도 저렇게 되겠거니 하는 믿음으로 이 투기를 계속해서 진행하는 것 같았다.
개인적으로, 여기저기 동향 살펴가면서, 차트 분석해가면서 가상화폐로 돈 버는 것 보다는, 그냥 원화를 버는게 비록 가상화폐로 대박내기! 보단 못 하겠지만 훨씬 안정적이고 더 쉽다고 생각한다…
확실한건, 길가는 아줌마 아저씨들도 비트코인과 가상화폐에 대하여 알 정도로, 많은 사람들이 이 시장에 관심이 있는 것 같다. 그리고 그 중 일부는, 자신이 수익을 낼 수있을 거란 생각에 가상화폐를 사게 될 것이고, 그 중 일부는 바래왔던 것 처럼 이득을 볼것이고 누군가는 똥망을 할 것이다.
그렇게, 똥망 할 사람들을 위하여, 모의거래소 서비스를 만들면 어떨까? 라는 생각이 들었다. 그래서 이 프로젝트를 만들게 되었다.
사용해보고 싶었던 기술 – ARc
사이드 프로젝트를 시작한 주 원인은, 바로 ARc 였다. 사용해보고 싶었던 기술.. 이라기 보단, 프로젝트 구조였는데, 프로젝트를 시작 할 시점에 리액트 컴포넌트 구조 중 하나인 ARc 를 알게 되었다. 이 컴포넌트 구조가 되게 신기한데, 컴포넌트를 분류 할 때, 뭐 라우트별로 하거나 기능별로 분리하거나 그런게 아니라, 단순히 이름이 그러하듯, 원자(Atom) / 분자(Molecule) / 생물(Organism) 단위로 분류해서 컴포넌트들을 나눈다.
대충, 하나의 자그마한 컴포넌트 (버튼, 인풋 등)은 원자로 분류하고, 인풋과 버튼이 하나씩 있는 컴포넌트라면 분자로 분류하고, 또 어쩌다가 분자와 원자 컴포넌트들이 이리저리 섞여서 하나의 큰 기능을 맡게 된다면, 이를 생물 로 분류한다. 그리고, 개발을 좀 더 원활하게 하기 위해서, Page 와 Template 으로 분류되는 컴포넌트들도 있다.
그 컴포넌트 분류 별로, 각각 다른 디렉토리에 저장하게 되는데, 이렇게 컴포넌트들을 분리 한다면, 어떤 컴포넌트가 어디에 있는지 헷갈리는게 당연 할 것이다. 내가 인풋버튼을 molecule 에 넣었나? organism 에 넣었나? 헷갈릴법한데, 사실상 개발하면서 컴포넌트의 규모에 따라 잘 분리를 시켰기에 어디에 넣은지는 왠만해선 감으로 알 수 있다. 그런데, 까먹어도 된다. 왜냐하면, IDE 컴포넌트를 불러올때 디렉토리 명을 안쓰기 때문! 추가적으로, molecule 이던게 어쩌다보니 organism 규모가 될 때도있는데, 이를 organism 디렉토리를 이동시키게 된다면, 해당 컴포넌트를 불러와서 사용하는 컴포넌트를 일괄적으로 수정해줄 필요도 없다.
왜냐? 컴포넌트가 atom 이던 molecule 이던 간에, 컴포넌트를 불러 올 땐 다음과 같이 불러오기 때문:
import { Button, InputButton } from 'components';그럼 이쯤되면, components 의 index.js 에서 import 문을 엄청나게 작성하는건가? 싶을 수도 있겠지만, 그렇지 않다. ARc 의 예제 코드를 가져와서 보자면, 다음과 같다:
// src/components/index.js
// https://github.com/diegohaz/arc/wiki/Atomic-Design#do-not-worry
const req = require.context('.', true, /\.\/[^/]+\/[^/]+\/index\.js$/)
req.keys().forEach((key) => {
const componentName = key.replace(/^.+\/([^/]+)\/index\.js/, '$1')
module.exports[componentName] = req(key).default
})컴포넌트와 경로를 를 일일히 하나하나 적어서 불러오는것이 아니라, 그냥 webpack 이 가지고 있는 기능 중 하나인 require.context 를 사용하여 정규식을 가지고 다음과 같은 파일들을 불러와서: src/components/atoms/Button.js, src/components/molecules/InputButton.js 각 컴포넌트 이름을 사용해여 내보내준다.
따라서, 기존에 atom 이던게 molecule 이 되면, 그냥 디렉토리만 옮겨주면 된다. 어짜피 불러오는 경로는 동일하기 때문에 해당 컴포넌트를 의존하는 다른 컴포넌트에서 딱히 수정해줄 필요가 없다.
ARc 를 사용함으로서, 컴포넌트의 구조에 대해선, 고민거리가 줄어들어서 개발하는데에 있어서 매우 쾌적했다.
그리고, 특정 부분에서만 사용되도록 지정한 컴포넌트가 아니기 때문에, 컴포넌트를 만들게 될 때, 조금 더 여러가지 속성을 받게 하고 뭔가 의무적으로 컴포넌트 재사용률을 높이게 되는 장점이있다.
굉장히, 매력적이였기에 회사 프로젝트에 적용을 하고 싶었으나, 구조를 바꾼다는건.. 워낙 커다란 일이여서 회사에서 적용하기 전에 한번 다른 프로젝트에 적용해보고, 그 실용성과 유용성을 검증해보고 싶었다. 물론, 회사에서 웹 프론트엔드 쪽은 내가 혼자 맡고 있기 때문에 내가 적용하려고 맘 먹으면 바로 적용 할 수 있긴 하겠지만, 아무래도 프로젝트가 회사단위가 되면, 이러한 선택은 매우 신중해져야 한다고 생각했다.
그리고, 난 사전 검증하길 정말 잘 했다고 생각한다. 좋기만 해보이던 구조에서, 단점들을 찾았기 때문.
좋기만 할 수는 없겠지
ARc, 편하긴 한데 당연히 단점이 존재한다.
1. 코드 스플리팅이 어렵다.
components/index.js 에서 모두 불러오고 내보내기 때문에, 아무리 라우트를 단위로 프로젝트를 쪼개도 빌드를 하고 나면 모든 컴포넌트들이 각 청크에 들어있다.
이 문제 때문에, 그렇게 길게 연구해본 것 까진 아니고 한 1시간동안 좀 알아봤는데, 딱히 엄청난 해결 방법은 없었다. 해결하려면 결국 정규식을 사용하여 모든 컴포넌트를 한 파일에서 불러와서 내보내는 작업을 포기해야 하기 때문에, 다음과 같은 형식으로 입력해야만 한다.
import AtomComponent from 'components/atoms/AtomComponent';
import MoleculeComponent from 'components/molecules/MoleculeComponent';이렇게 하는것은.. 결국 ARc 의 핵심 장점을 져버리는 것 이기 때문에… 이렇게 하느니 그냥 도메인 형식으로 파일들을 구조화하는것이 좋겠다고 생각한다.
내가 생각하기에, 이를 해결하는 유일하고 적절한 방법은, babel 플러그인을 만들어서 사용하는 것 이라고 생각한다. 이미 시도 한 사람이 있을지는 모르겠지만, 플러그인에 프로젝트 코드의 디렉토리를 설정으로 넣어주면, 직접 디렉토리들을 조사하여, import { AtomComponent } from 'components' 를 import AtomComponent from 'components/atoms/AtomComponent' 형식으로 변환해줄 플러그인이 필요하다.
이 방안이 가장 현실적인 것 같다. 하지만, 현재 프로젝트에서 코드 스플리팅이 그렇게 시급하진 않기 때문에 그냥 내비두려고 한다. 나중에 정말 필요하게 되면 바벨 플러그인을 만들게 되지 않을까? – 일단 바벨 플러그인을 애초에 만들어 본 적이 없다. 금방 할 수 있긴 하겠지만,, 뭔가 새로 공부 해야 하므로 은근히 공수가 있을 것 같다는 생각이 든다.
2. IDE 활용을 충분히 못함
이건 꽤 치명적이다. 프로젝트를 진행하다보면, 특정 컴포넌트를 커맨드 키를 누르고 컴포넌트 코드를 누르면, 컴포넌트 파일이 열리는것이 일반적이다. 근데, 이 프로젝트에서는 정규식과 require 를 사용해서 컴포넌트를 불러와서인지 이게 제대로 작동하지 않는다. 나는 VS Code 를 사용하는데, 적어도 여기서는 안된다. 다른 에디터에서는 어떤지는 잘 모르겠다.
그래도 큰 문제는 안됐던게, 그냥 커맨드키 + P 를 눌러서 파일 명으로 파일을 열었다. 이를 가능케 하기 위해선, 모든 컴포넌트의 이름을 유니크하게 해주어야 한다. (페이스북도 이렇게 한다지) 그래서 특정 컴포넌트를 건너 건너 타서 열려면, 보통 파일명으로 열기때문에 엄청나게 힘든 것은 아니지만, 커맨드 클릭보다는 솔직히 불편하다고 생각한다.
이러한 이슈가 있는것으로 봐서, 아직 잘은 모르겠지만, 이 구조에서 Flow 나 Typescript 를 사용하게 됐을 시, 컴포넌트 부분에선 제대로 사용하지 못하게 되지 않을까? 라는 추측이 든다.
3. 컴포넌트 찾기
프로젝트에서, 코드상에 보여지는 컴포넌트를 찾으려면, 파일 명으로 빠르게 열면 되기 때문에 큰 상관은 없지만, 예를들어 브라우저에서 보고있는 컴포넌트를 수정하려고 파일을 열려고 하면, 파일 이름이 생각나지 않을 수도 있기 때문에 조금 번거로울 수도 있다. 뭐 물론, React 개발자 도구를 사용하여 특정 부분이 어떤 컴포넌트인지 확인 가능하긴 하겠지만, 그걸 하려면 약 20초정도 낭비 될 것같다.
이번 프로젝트는, 나 혼자 만들었기에 당연히 어떤 컴포넌트가 어디에 있고 어떤 역할인지 알기 때문에 전혀 문제가 되지 않았지만, 만약에 두명 이상 작업한다면… 조금 힘들었지 않았을까 싶다.
프로젝트를 시작할 시점에 Storybook 을 사용하다가 다시 접었는데, 만약에 Storybook 을 했더라면 이러한 문제점에서 자유롭지 않았을까 싶다. 각 컴포넌트들이 어떻게 생겼는지, 어떤 컴포넌트들이 있는지 쉽게 확인을 할 수 있기 때문이다.
혼자 개발하고 있기에, 내가 모든 컴포넌트들을 파악 할 수 있을 것 이기에, 그리고 개발 시간에 제한이 있기에, 나는 스토리북을 사용하다가, 계속 사용하는 것을 포기했다. 왜냐하면, 스토리북 사용은 개발을 좀 더 느리게 만들기 때문이었다.
하지만, 컴포넌트가 컨테이너, 페이지, 일반 컴포넌트들을 포함하여 100 개에 가까워지니까.. 스토리북을 할걸 그랬다는 생각이 든다.
ARc 에서 스토리북 관련 파일들을 불러올때도 require 과 정규식을 사용한다. 파일명에 .storybook.js 이렇게 하면 되는것으로 기억하고있다. 나중에 스토리북을 다른 프로젝트에서 사용한다면 이러한 구조를 사용해야겠다.
단점 정리
2번과 3번의 경우엔 편법들을 사용해서 어느정도 완화 될 수있는 문제들이지만, 1번의 경우엔 바벨플러그인을 자체개발 하지 않는 이상 해결 할 수없는 치명적인 문제이다. 일단은, 이번 프로젝트에선 큰 문제는 없었다. 그 이유는, 프로젝트가 번들링된 JS 사이즈가 473KB 정도이고, AWS 의 Cloudfront CDN 을 적용해서 엄청 빨리 받아오기 때문 (우리 집 가정용 인터넷 기준 140ms)
물론, 코드스플리팅을 하면 두자릿수 수준으로 더 빨라질 수는 있겠지만….. 그건 사람이 감지하기 힘든 수치이므로, 괜찮다.
결론적으로는, 난 이걸 회사에선 사용하지 않기로 결정했다. 그러나, 앞으로 소규모의 프로젝트를 만들 때에는 계속 사용 할 것 같기는 하다. (내가 정의하는 소규모 프로젝트는, 1주일 안에 만들 수 있는 것들)
프로젝트 개발기
난 솔직히 이 프로젝트를, 금방 만들 수 있을 줄 알았다. 130일이면.. 거의 반년인데, 내가 반년동안 이걸 개발하게 될 줄이야. 그런데, 뭐… 말이 반년이지, 평균적으로 하루에 한시간20분? 정도 했을테니, 방송 시작 및 마무리 시간을 고려하면, 평균 1시간이라고 봐도 될 것 같다.
그러면, 대충 130시간이면.. 대충 하루에 풀타임으로 개발을 한다면 8~9시간 하게될테니, 거의 16일동안 만든 것이나 다름이 없다.
그런거 치곤,,, 그렇게 오래걸린건 아닌 것 같기도.
여튼… 작은 프로젝트로, 미니 프로젝트로, 재미삼아 만드는 프로젝트로 시작했었는데, 개발을 하면 할 수록 규모가 커졌고, 난이도도 높아졌다. 그러다보니, 내가 대충하려던걸 지금까지 투자 한 시간이 아까워서 더욱 공수를 더 들여서 열심히 개발하게 됐었다.
프로젝트 스택
프로젝트의 스택은 다음과 같다:
- Client:
- react
- react-router
- redux, Immutable
- redux-pender
- echart
- CSS Module + Sass
- ARc
- Websocket
- Server:
- AWS EC2, Loadbalancer
- AWS S3
- AWS Cloudfront
- Node.js
- Koa
- MongoDB, mongoose
- pm2
- Websocket
- Redis
배운 것들
이번 프로젝트를 통하여, 배운 것 중에서 가장 의미 있는 것을 꼽자면, AWS 의 활용도인것 같다. 기존의 나는, 보통 EC2 인스턴스를 만들어서 서버 하나에서 모든걸 다루는 작업을 해왔었다. 예를 들어서, 정적 파일들도 EC2 에서 제공하도록 하고.
이번에 S3 에서 정적 페이지를 제공하도록 하고, 이를 Cloudfront 를 통해서 CDN에 올린다음에 도메인 연결을 해주고, API 서버의 경우엔 api.bitimulate.com 이런식으로 따로 분리를 시켜줬는데, 매우 유용했다!
추가적으로, Websocket을 사용하게 될 때, 클라이언트-서버단의 pubsub 구조를 직접 개발하게 되면서, Websocket 에 이전보다 훨씬 익숙해졌다. 이전에는, 대충 채팅 메시지나, 새 데이터 발생했을때 이를 클라이언트에게 넣어주는 용도로만 사용했더라면, 지금은 다양한 상황속에서 적은 공수로 데이터를 소켓을 통해 쉽게 주고 받을 수 있게 되었다.
개인적으로, Websocket 은 작은 프로젝트에서만 써보고, 프로덕션 레벨에선 잘 사용을 안해봐서, 활용력이 좀 떨어졌는데, 이번에 실시간 데이터 전달이 중요한 모의 거래소 페이지를 만들면서, 훨씬 익숙해졌다.
그리고 뭐, 이론 상으론, ARc 를 적용하면, ARc 는 개발 할 때 매우 유용하다는 것과, 이 구조의 단점도 파악 할 수있게 되어서 정말 의미 있었다.
회사 프로젝트 외에는, 커다란 프로젝트를 개발/운영해본 경험이 그렇게 많지 않아서, 이번 중규모.. 정도 되는 프로젝트를 만들면서 전체적으로, 내 자신이 많이 성장했다고 느꼈다. 계속해서 이렇게 끝없이 성장 할 수 있을까? 지나번에 WhoTalk 라는 미니프로젝트를 만들었을때도 (실용성이 없어서 그냥 Github 에만 박아놓고 있긴 하지만), 많이 배웠다! 많이 성장했다! 라는 느낌이 들었는데, 이번에도 동일한 느낌이 든다.
개발자로서, 자기 자신을 성장하는것은, 이렇게 사이드 프로젝트를 진행하는 것이 가장 효과적이라고 생각한다. 물론, 회사프로젝트도 내 자신을 매우 많이 성장 시켜주긴 하지만, 어느정도 제한이 있다. 회사 규모가 되면, 기술 선택에 있어서 어느정도 제약이 있을 수 있기도 하고, 개발 일정 또한 중요하기 때문에, 가끔씩은 이상적인 코드가 아닌 현실적인 코드를 작성해야 될 때도 있기 때문이다 – 언젠간, 그 “현실적인” 코드를 이상적인 코드로 개선을 시켜주긴 하겠지만 ㅎㅎ
서비스적인 측면
이 프로젝트를 만들때에 있어서, 내가 가장 많이 추구했던건, ‘재미’이다. 뭔가 재미있는 프로젝트를 만들어보고 싶었다. 근데, 이 프로젝트의 개발자가 아닌 일반 유저로서 이 사이트를 들어온다면, 이런 상황이 벌어질 것 같다.
- 어? 이거 뭐지
- ㅇㅎ 잘만들었네
- 오호 신기하네
- 거래 시도 거래 시도
- 수익내는게 쉬운건 아니군 / 오 수익을 냈다!
- ㅋ 이거 버근가?
- 이런 서비스구나….
- 내일이면 잊혀짐
유저들 입장에선, 어짜피 모의 거래이고, 진짜 돈이 아니기 때문에 별 감흥이 없을 것 같다. 한번 써보고 그렇게 끝날 서비스…. 그 이상 그 이하도 아니다.
나한테는 프로젝트 만들면서 이것저것 배우고 성장을 이뤄내고 했으니 충분히 의미있긴 했지만, 사용률이 없다면.. 조금 아쉬울 것같다는 생각을 해서 이걸 어떻게 살릴 수 있는 방법이 없을까? 란 생각을 했다.
이런건 어떨까?
나는 페이지에 구글 애드센스 광고를 삽입하고, 이 광고 수익을 매달 랭킹 1위에게 지급하는 시스템을 구현해볼까 한다. 어쨌든, 서버 비용을 충당해야 하긴 하니까. (학생이였으면 도저히 생각 할 수 없는 일이긴 하지만, 지금은 돈을 벌고 있으니까… 그냥 계속 내 돈 태워서 서버 유지를 할 의향도 있긴하다. 그래도, 광고비를 통하여 충당할 수 있으면 개이득이지.)
물론, 초반에는 광고비가 0 일테니, 첫 달의 상금은 내 돈을 태워야 한다. 내가 일해서 벌은 돈을 태우기엔 좀 아까우니까, 옛날에 가상화폐로 벌은 돈의 일부를 여기에 태워볼까 한다. 광고비가 충분히 들어온다면, 난 개이득인거고, 광고비가 저조하다면 뭐…. 어쩔 수 없지 이 모델은 실패한거다.
이 프로젝트에 후원하기 기능도 추가할까 한다. 후원비는 서버비용 / 상금으로 사용되고…
모의거래를 통한 보상이 있으면, 목적이 생기는거니까 사용률이 높아질거고, 이에 따라 광고비도 나오지 않을까? 라는 예상을 하고 있는데, 물론 이 예상은 빗나갈 수도 있다.
이 모델이 실패한다고 해서 그렇게 낙심하지는 않을 것 같다. 애초에 이걸 목적으로 만든 것 도 아니고 나중에 와서 생각 난 것 이기에, 기대하지도 않는다. 그래도 사용률이 높았으면 좋겠다.
근데 사실,,,, 사용률이 높아지면, 서버 로드 밸런싱 작업도 거쳐야할텐데, 그러려면 서버머신의 수를 3개정도로 늘려야 할 듯 싶다: MongoDB, Redis, 크롤링 및 거래체결 서버 / 웹서버A / 웹서버B
이러한 작업을 할 수 있게 된다면… 물론 귀찮긴 하겠지만, 난 행복 할 것 같다 ㅋㅋㅋㅋ 실제 트래픽을 감당하고 다양한 케이스를 접하는것은,,,, 혼자서 어떻게 배울 수 있는것이 아니기 때문. 개인적으로 훌륭한 서버개발자라면, 단순히 서버코드를 잘 작성하는 것 뿐만 아니라, 커다란 트래픽을 잘 소화하면서, 비용도 아낄수있으면서 만약에 크래쉬가나면 최대한 빨리 해결 할 수있는, 그런 개발자라고 생각한다.
프론트엔드는 어찌,, 계속 개발하다보면 실력이 계속 늘긴 하지만, 백엔드 개발의 경우 이러한 것들은 혼자서 아무리 노력해도 쉽게 얻을 수 없는, 경험적인 차원인 것이여서.. 비티뮬레이트를 통하여 그걸 얻을 수 있다면 정말 멋질 것 같다.
다국어 지원
위 모델이 어느정도 작동을 한다면 (최소, 서버비용 / 상금 감안했을 때 손해가 안난다면) 서비스에 다국어 지원도 넣고 이걸 해외에 퍼뜨릴 생각이다. 다국어 지원의 공수는, 한 7시간정도면 다 할 수 있을 것 같다. 애초에 페이지의 수가 그렇게 많은 것은 아니고, 또 다국어 지원은 익숙하기 때문에…
내가 이 프로젝트를 처음부터 다시 만든다면?
- ARc 폐기
- Poloniex 말고 다른 거래소 API 사용 (Bitfinex 혹은 Bitrex)
- 차트는 직접 크롤링 안하고, Tradingview 에만 의존
(유사한 서비스를 만들게된다면,, 2번과 3번은 꼭! 참고하길 바랍니다)
Poloniex API 는 느리고, 불편하다. 추가적으로, 차트 라이브러리는, 직접 D3를 사용하여 처음부터 개발하는게 아닌이상, 쉽게 접할 수 있는 라이브러리 중에서 Candlestick 차트를 제대로 지원하는 것 이 없다. 만약에 있다면, 유료일 것이다… 그 중에서 echart는 은근 잘 되어있긴 하지만, 너무 제한이 많기도 하고, 문서화도 잘 안되어있어서 비추다. ㅠㅠ 어쩔수없이 쓰긴 했지만!
그!런!데! 나중에서야 발견한 Tradingview 란 서비스는 진리다.. 무료로 라이브러리 제공도 해주고 (이건, 무슨 계약서 같은거 스캔해서 보내야되긴 하다) 게다가, 데이터도 자체적으로 지원해줘서 위젯형태로 embed 할 수 있게 해준다 (이 부분이 정말 멋지다 -_- 처음부터 알았으면 이걸로 할 걸)
이제와서 차트를 바꾸기엔 좀 늦은것 같아서 (귀찮기도 하고) 보류하고있다.
하지만, 서비스에 사용자가 좀 있다면 나중에 개선하게 될 것 같다. 트레이딩뷰 차트가 질이 훨씬 좋은 것은 사실이니까.
만약에 이걸 도입하게 된다면, 폴로닉스를 굳이 쓸 필요도 없이 (차트 데이터를 쉽게쉽게 API 로 내주는곳은 Poloniex 와 Bitfinex 뿐이다. 다른 것 도 있는진 모르겠지만, 내가 알고 있는 바로는 그러하다) 차트는 트레이딩뷰에서 데이터와 함께 주어지는 위젯을 넣으면.. 좋을 것 같다.
앞으로의 계획
이번 비티뮬레이트 프로젝트는, 라이브코딩 시즌 1 로서 마무리를 하고, 이어질 시즌 2 에서는, 새로운 프로젝트를 진행 해볼까 한다. 비티뮬레이트를 개발하기 전에, develoxy 라는 프로젝트를 진행했었다. 개발자들을 위한 블로그 플랫폼이였는데… 시간이 없어서 개발중단 됐다.
시즌 2 에서 어떤 프로젝트를 할 지 많이 고민을 했었는데,,, 그 때 만들다 만 프로젝트를 이어서 하기로 결정했다! 다만, 그때의 프로젝트 구조와 이름이 맘에 안들어서 프로젝트 자체는 새로운 이름으로 다시 만들 예정이다.
다음 프로젝트의 이름은: velog
개발자들의 블로그… 벨로그!
별.. 별론가? ㅋㅋㅋ 이 프로젝트는, 일단 현재 내 블로그를 이사시킬 새로운 공간으로 만들 예정이다. 워드프레스는 꽤 편했지만, 커스터마이징 측면에 있어서 맘에 들지 않기 때문에, 직접 만들어볼까 한다. 코드하이라이팅, 마크다운 등을 지원하는 에디터를 만들고, 해쉬태그를 통하여 관심있는 기술 글을 모아볼수있는… 그런 무언가를 만들어볼 계획이다.
핵심은, 나 자신만이 사용하는 것이 아닌, 다른사람들 글도 같이 볼 수있는 일종의 커뮤니티같은 블로그이다.
어쩌면, 내가 좋아하는 서비스중 하나인, vobour.com 와 유사한 프로젝트가 될 것 같기도한데… 저기는 살짝 아쉬운점이, Markdown 미지원, 코드 하이라이팅 미지원…
사실, 저기서 마크다운이랑 코드하이라이팅이랑 이런걸 지원해주면, 난 이 프로젝트를 개발 할 이유가 없다 -_- 보버 관리자님한테 이메일 한번 보내봐야겠다. 마크다운이랑 코드하이라이팅 지원할 생각 있으시냐고.. (그런데 지원을 한다고 해도 사실상 내가 저기서 글을 쓸 꺼란 보장은 못하겠다. 괜찮은 서비스이긴 하지만, 디자인, UX 구조 측면에서 내가 추구하는 바와 좀 다르기 때문에..ㅠ)
bitimulate 의 경우엔 ARc 의 검증을 위하여 개발을 진행했다면, 이번 프로젝트의 중점은 요즘 내가 관심이 가는 서버리스 아키텍쳐에 중점을 둘 생각이다.
이 프로젝트의 프론트엔드 부분에선 당연히 내가 사랑하는 리액트를 사용 할 것이고, (사랑해요 리액트!!) 구조는 Bitimulate 와 매우 유사하겠지만 Flow 와 Storybook 을 적용 할 예정이다. (Storybook은 그때 가서 다시 고민해볼 것 같긴 하지만, Flow 는 확실히 사용 할 것이다. 최근에 사용해 보니 좋았다)
ㅋㅋㅋ 그리고 이 프로젝트에서 서버리스 서버사이드 렌더링! 도 구현해볼 생각인데, 과연 내가 라프텔에 서버리스 서버사이드 렌더링을 먼저 지원할지, 이 프로젝트에서 먼저 구현하게 될 지는 모르겠다.
아무래도…….. 후자가 더 좋을 것 같다. 서버리스 서버사이드 렌더링을 한번 삽질하고, 이게 별로면 회사에서는 지금 상태로 유지하거나 정말 좋다면 회사에도 적용하거나 할 수 있으니까. (아직까지는, 서버사이드 렌더링을 할 때 서버가 그렇게 자원을 많이 사용하는 정도는 아니기 때문에 괜찮긴 하지만, 트래픽이 지금에서 한 10배 정도로 뛰면… 서버리스 서버사이드 렌더링이 비용적인 측면에서 좋아 질 것 같다는 생각이 든다)
개인적으로, 회사에서 기술 적용 할 때에는, 해본 것을 하는 것이 매우 중요하다고 생각한다. 회사 프로젝트가 아니더라도, 중요한 프로젝트에 새로운 기술을 도입 할 때는, 공부와 적용을 동시에 진행하는것은 절대! 좋지 않은 선택이라고 생각한다. 그 대신에, 엄청 작은 프로젝트를 만들어서 먼저 다른 곳에서 사용해보는 작업이 선행되어야 한다고 생각한다 (물론, 어떤 기술이냐, 어떤 방식으로 배우느냐에 따라서 큰 차이가 있긴 할 것이다). 대부분의 경우 나는, 특정 기술을 배우게 될 때, 대부분 첫번째 프로젝트를 만들기 전과 후의 해당 기술의 이해에 대한 차이가 엄청났다. 첫번째 프로젝트를 만들고나면, 기존 코드를 뒤엎고 싶을 정도다. 내가 왜 이렇게 했지.. 하고.. 개인 프로젝트면 리팩토링을 하면 좋은거고, 바쁘면 버리면 되지만, 회사 프로젝트이거나, 혹은 다른 중요한 프로젝트인경우엔,,, 리팩토링을 해야 될 터이니… 버릴 순 없지 아니한가!
그렇기 때문에, 이렇게 사이드프로젝트를 진행하는건 정말 중요하다. 프로젝트 만들어가면서 배운 좋은것들만 콕콕 골라서 회사에 들고가면 되니까.
결론
개인 프로젝트를 진행하고 있지 않다면, 하나 정도는 키우도록 하자. 자기 자신에게 도움이 된다.
사이드 프로젝트로 시작해서, 사이드 프로젝트로 끝난 포스트였습니다. 일기를 쓰듯이, 의식의 흐름대로 쓴 글이여서, 어찌 재밌게 봤을지는.. 모르겠네요! Bitimulate 프로젝트는 이제 마무리가 되어 아주 가끔씩 유지보수/개선 작업을 진행하게 될 것 같고, 앞으로 3~4일 정도는 Bitimulate 관련 작업 하다가, 그 다음부턴 다음 프로젝트로 넘어가서 매일 밤 12:00 에 Velog 프로젝트를 진행 할 예정입니다. 관심이 있으시다면, 유튜브 Minjun Kim 채널을 구독하시고, 가끔 놀러와서 구경하고 가세요 🙂