토이 프로젝트
첫번째 커밋을 보니 3월 3일이다. 대충 한달 정도 걸린거 같다. 평균적으로 하루에 30분에서 2시간 정도 투자를 했다.
집에서는 두 아기 때문에 작업이 거의 불가능하므로 회사에서 점심 시간 혹은 퇴근 무렵에 주로 코딩을 했다. 긴 시간을 투자하면 좋겠지만 여건이 안되기 때문에 이런 제약이 생겨버렸는데 의외로 좋은 점이 있었다. 어려운 문제 혹은 설계상의 문제를 만났을 경우 머릿속으로만 생각을 해야 하는데 노트북 앞에서 손만 바쁘게 움직이는 것보다 효과적인 경우가 많았다.
나는 회사에서는 주로 스프링/자바로 개발을 하고 프론트작업도 병행 하고 있다. 사실 나에게 주어진 업무는 정해져 있기 때문에(개발자 이전에 회사원인건 어쩔수 없다.) 사용하는 기술이 잘 바뀌지도 않고 꼭 알아야 할 필요가 없다.
2년전 프로젝트 진행 중에 선택한 AngularJS를 여전히 잘 사용하고 있으며 Angularjs2, Reactjs 등등의 새로운 프레임워크가 나오긴 했지만 버스 갈아타듯이 쉽게 갈아탈 수 있는 것이 못된다.
이번 토이 프로젝트를 시작하게 된 동기는 프론트 관련 기술을 이것저것 찾아보고 있었는데 도무지 뭐가 뭔지 감을 잡을 수가 없었다.
http://seokjun.kr/front-end-dev-stack-2017/
http://d2.naver.com/helloworld/3618177
https://www.codementor.io/learn-programming/javascript-trends-skills-developers-should-learn
이런 (약간의 자괴감이 느껴지는) 글들이 넘쳐 난다.
토이프로젝트의 주제는 '채팅 사이트'로 정했다.
가장 먼저 소켓 라이브러리를 사용해서 메시지 주고 받는걸 구현해야 한다. 그 다음은 그렇게 만든 채팅 기능을 올려놓을 웹어플리케이션이 필요하다.
찾아보니 SocketIO와 SockJS가 있었는데 SockJS를 선택했다. 특별한 이유는 없었다. SockJS가 먼저 눈에 들어왔고 github에 사용법이 잘 정리가 되어 있었을 뿐이고(?!) 예제를 따라해보니 잘 되길래 선택했다. 이 코드를 기반으로 조금씩 개발하였는데 기능적으로 좀 아쉬운 부분이 있긴 했지만 당장 문제될 것은 없었다.
그 다음으로 웹프레임워크를 선택해야 했는데 이건 별다른 고민없이 express를 선택했다. meteor를 몇년전에 토이프로젝트에 사용해본적이 있어서 지금은 어떻게 바뀌었을까 궁금하긴 했지만 지금 구현 하려는 것과는 맞지 않을거 같아서 접었다. 처음부터 자바스크립트로 개발할 생각이었기 때문에 다른 언어의 프레임워크는 생각해보지 않았다.
그렇게 처음 며칠동안 sockjs와 express를 가지고 채팅사이트를 구현했다. 브라우저 두 개 띄워두고 메시지 주고 받는 아주 기본적인 기능이었는데 사실 여기까지는 어려울게 없다.
기본적인 채팅 기능 이외에 두가지 기능을 추가하고 싶었다.
1. 채팅방을 만드는 사람은 타임아웃을 반드시 설정해야 하고 그 시간이 지나면 채팅이 자동 종료
2. 채팅방마다 고유 URL을 할당 받으며 그 URL을 통해서 접속하는 사람은 곧바로 채팅방에 참여시킴
사용자가 커넥션을 요청하면 커넥션을 메모리에 저장했는데 메모리에만 커넥션 정보를 가지고 있으니 몇가지 문제가 발생했다. 첫째, 소켓 서버와 웹서버의 채팅 정보 동기화 문제가 있고, 둘째, 서버 재시작시 커넥션 정보가 사라지는 문제, 셋째, 코딩 자체가 복잡해지는 문제 등이 있었다.
결국 DB가 필요하다는 결론에 이르렀고 Redis를 선택했다. key-value 구조이면 충분하였고 무엇보다 설치와 사용이 간편했다.
아래는 채팅사이트를 개발하면서 사용된 프레임워크 및 라이브러리를 선택할 때 했던 생각들이다.
1.
express를 사용해서 프로젝트를 생성하니 jade가 기본적으로 설정이 되어 있었다. jade를 사용할지 아니면 익숙한 html을 사용할지 고민이 되었다. 이왕 할거 새로운거 해보자 싶어서 jade로 템플릿 개발을 시작했는데 처음에는 꽤나 낯설었다. 그리고 문제는 화면 레이아웃 프레임워크를 bulma.io를 선택했는데 예제들이 전부 html로 되어 있어서 bulma.io 의 샘플을 옮겨 올려면 일일이 jade로 변환해줘야 했다. 안그래도 jade 문법이 낯선데 html이었으면 copy&paste로 될일을 일일이 타이핑 해서 옮겨야하니 꽤나 번거로웠다. (온라인 컨버터가 있긴 하지만 몇번 해보고 의미 없다는걸 깨달았다.)
결론적으로 이제 와서 돌이켜보면 jade를 선택한건 잘 할일이었다. 익숙해지는데 몇일 걸리긴 했지만 결코 어렵지는 않았고 이제 와서 다시 html로 개발하라고 하면 못하지 싶다. 타이핑이 일단 절반 이상으로 줄어 들고 들여쓰기가 곧 문법이기 때문에 소스 자체가 깔끔해진다. 그리고 bulma에 있는 html 예제를 옮겨 적는것도 몇번해보니 할만한 작업이었다.
2.
스타일시트는 less를 쓰기로 했다. sass도 있지만 솔직히 뭐가 더 좋은지 모르겠고 차이도 모르겠다. 도큐먼트가 깔끔하게 정리되어 있었고 sass에 비해 쉬워 보였다(주관적임)는게 나름의 이유라면 이유다.
less를 사용 할 수만 있다면 css 보다 백번 낫다고 생각한다. 지금 회사에서는 마크업(이라고 표현한다)을 전부 타팀에서 해주기 때문에 less를 쓸수 없다는게 아쉽다. 하나의 css 파일에 블럭 카피한 코드가 얼마나 많던가.
3.
스크립트는 처음에는 coffeescript를 쓰려고 했었다. 그런데 다른 개발자가 지나가면서 typescript 좋다고 해서 typescript로 결정했다. 개인적으로 coffeescript는 내가 하고 싶은 언어 스타일이라면 typescript는 왠지 좀 익숙한 언어랄까.
나중에 내가 개발한 typescript 소스를 보면서 든 생각은 이럴꺼면 내가 왜 typescript를 선택했을까였다. 파라미터는 대부분이 string 이고 함수의 리턴값은 대부분 void 였다. 상속 따윈 쓸일도 없었다.
그나마 typescript로 개발하면서 좋았던 점은 컴파일 할때 에러가 떨어지면 뭔가 얘네가 걸러주는게 있긴 하구나 하는 딱 그정도였다. 결론적으로 typescript는 내 능력에 비해 너무 고급이었다.
4.
빌드는 webpack으로 했다. 이거저거 보다가 그냥 webpack이 대세라길래 대세를 따랐다. browserify는 느리고 어쩌고 그런 말들이 있던데 안해봐서 패쓰. 무엇을 쓰던간에 빌드만 잘되면 되는거 아닌가.
5.
채팅방에 시간제한 기능이 있어서 moment를 사용했다. moment를 쓰면서 java 버전이 있었으면 좋겠다라는 생각이 들었다. (jodatime이 있긴 하지만..)
6.
프로젝트를 처음 시작했을 때 vuejs를 꼭한번 써봐야지라는 생각이 있었는데 설정하다가 포기했다. typescript가 문제인지 뭐가 문제인지 모르겠는데 아무튼 뭐가 잘 안맞았다. 안그래도 처음해보는거 투성이인데 vuejs에서 삽질을 하고 있자니 끝이 안보일거 같았다. 그래서 그냥 익숙한 jquery로 한땀한땀 개발했다. 요건 나중에 다른 프로젝트에서 다시 한번 써봐야겠다. (이래 놓고 react 쓰고 있겠지. react가 대세니까~)
7. deploy는 heroku의 도움을 받았다. 프로젝트 중간에 Redis를 도입했을때는 클라우드 같은건 생각을 안하고 있었다. 나중에 heroku에 셋팅을 하려고 보니 redis가 플러그인으로 제공되고 있었는데 redis를 선택하길 잘 했다는 생각이 이때 들었다. 다만 heroku가 좀 느려서 https://zeit.co/now 로 옮길까 생각 중이다.
사이트
https://vanilla-server.herokuapp.com/
소스
https://github.com/ekcode/vanilla
집에서는 두 아기 때문에 작업이 거의 불가능하므로 회사에서 점심 시간 혹은 퇴근 무렵에 주로 코딩을 했다. 긴 시간을 투자하면 좋겠지만 여건이 안되기 때문에 이런 제약이 생겨버렸는데 의외로 좋은 점이 있었다. 어려운 문제 혹은 설계상의 문제를 만났을 경우 머릿속으로만 생각을 해야 하는데 노트북 앞에서 손만 바쁘게 움직이는 것보다 효과적인 경우가 많았다.
나는 회사에서는 주로 스프링/자바로 개발을 하고 프론트작업도 병행 하고 있다. 사실 나에게 주어진 업무는 정해져 있기 때문에(개발자 이전에 회사원인건 어쩔수 없다.) 사용하는 기술이 잘 바뀌지도 않고 꼭 알아야 할 필요가 없다.
2년전 프로젝트 진행 중에 선택한 AngularJS를 여전히 잘 사용하고 있으며 Angularjs2, Reactjs 등등의 새로운 프레임워크가 나오긴 했지만 버스 갈아타듯이 쉽게 갈아탈 수 있는 것이 못된다.
이번 토이 프로젝트를 시작하게 된 동기는 프론트 관련 기술을 이것저것 찾아보고 있었는데 도무지 뭐가 뭔지 감을 잡을 수가 없었다.
http://seokjun.kr/front-end-dev-stack-2017/
http://d2.naver.com/helloworld/3618177
https://www.codementor.io/learn-programming/javascript-trends-skills-developers-should-learn
이런 (약간의 자괴감이 느껴지는) 글들이 넘쳐 난다.
토이프로젝트의 주제는 '채팅 사이트'로 정했다.
가장 먼저 소켓 라이브러리를 사용해서 메시지 주고 받는걸 구현해야 한다. 그 다음은 그렇게 만든 채팅 기능을 올려놓을 웹어플리케이션이 필요하다.
찾아보니 SocketIO와 SockJS가 있었는데 SockJS를 선택했다. 특별한 이유는 없었다. SockJS가 먼저 눈에 들어왔고 github에 사용법이 잘 정리가 되어 있었을 뿐이고(?!) 예제를 따라해보니 잘 되길래 선택했다. 이 코드를 기반으로 조금씩 개발하였는데 기능적으로 좀 아쉬운 부분이 있긴 했지만 당장 문제될 것은 없었다.
그 다음으로 웹프레임워크를 선택해야 했는데 이건 별다른 고민없이 express를 선택했다. meteor를 몇년전에 토이프로젝트에 사용해본적이 있어서 지금은 어떻게 바뀌었을까 궁금하긴 했지만 지금 구현 하려는 것과는 맞지 않을거 같아서 접었다. 처음부터 자바스크립트로 개발할 생각이었기 때문에 다른 언어의 프레임워크는 생각해보지 않았다.
그렇게 처음 며칠동안 sockjs와 express를 가지고 채팅사이트를 구현했다. 브라우저 두 개 띄워두고 메시지 주고 받는 아주 기본적인 기능이었는데 사실 여기까지는 어려울게 없다.
기본적인 채팅 기능 이외에 두가지 기능을 추가하고 싶었다.
1. 채팅방을 만드는 사람은 타임아웃을 반드시 설정해야 하고 그 시간이 지나면 채팅이 자동 종료
2. 채팅방마다 고유 URL을 할당 받으며 그 URL을 통해서 접속하는 사람은 곧바로 채팅방에 참여시킴
사용자가 커넥션을 요청하면 커넥션을 메모리에 저장했는데 메모리에만 커넥션 정보를 가지고 있으니 몇가지 문제가 발생했다. 첫째, 소켓 서버와 웹서버의 채팅 정보 동기화 문제가 있고, 둘째, 서버 재시작시 커넥션 정보가 사라지는 문제, 셋째, 코딩 자체가 복잡해지는 문제 등이 있었다.
결국 DB가 필요하다는 결론에 이르렀고 Redis를 선택했다. key-value 구조이면 충분하였고 무엇보다 설치와 사용이 간편했다.
아래는 채팅사이트를 개발하면서 사용된 프레임워크 및 라이브러리를 선택할 때 했던 생각들이다.
1.
express를 사용해서 프로젝트를 생성하니 jade가 기본적으로 설정이 되어 있었다. jade를 사용할지 아니면 익숙한 html을 사용할지 고민이 되었다. 이왕 할거 새로운거 해보자 싶어서 jade로 템플릿 개발을 시작했는데 처음에는 꽤나 낯설었다. 그리고 문제는 화면 레이아웃 프레임워크를 bulma.io를 선택했는데 예제들이 전부 html로 되어 있어서 bulma.io 의 샘플을 옮겨 올려면 일일이 jade로 변환해줘야 했다. 안그래도 jade 문법이 낯선데 html이었으면 copy&paste로 될일을 일일이 타이핑 해서 옮겨야하니 꽤나 번거로웠다. (온라인 컨버터가 있긴 하지만 몇번 해보고 의미 없다는걸 깨달았다.)
결론적으로 이제 와서 돌이켜보면 jade를 선택한건 잘 할일이었다. 익숙해지는데 몇일 걸리긴 했지만 결코 어렵지는 않았고 이제 와서 다시 html로 개발하라고 하면 못하지 싶다. 타이핑이 일단 절반 이상으로 줄어 들고 들여쓰기가 곧 문법이기 때문에 소스 자체가 깔끔해진다. 그리고 bulma에 있는 html 예제를 옮겨 적는것도 몇번해보니 할만한 작업이었다.
2.
스타일시트는 less를 쓰기로 했다. sass도 있지만 솔직히 뭐가 더 좋은지 모르겠고 차이도 모르겠다. 도큐먼트가 깔끔하게 정리되어 있었고 sass에 비해 쉬워 보였다(주관적임)는게 나름의 이유라면 이유다.
less를 사용 할 수만 있다면 css 보다 백번 낫다고 생각한다. 지금 회사에서는 마크업(이라고 표현한다)을 전부 타팀에서 해주기 때문에 less를 쓸수 없다는게 아쉽다. 하나의 css 파일에 블럭 카피한 코드가 얼마나 많던가.
3.
스크립트는 처음에는 coffeescript를 쓰려고 했었다. 그런데 다른 개발자가 지나가면서 typescript 좋다고 해서 typescript로 결정했다. 개인적으로 coffeescript는 내가 하고 싶은 언어 스타일이라면 typescript는 왠지 좀 익숙한 언어랄까.
나중에 내가 개발한 typescript 소스를 보면서 든 생각은 이럴꺼면 내가 왜 typescript를 선택했을까였다. 파라미터는 대부분이 string 이고 함수의 리턴값은 대부분 void 였다. 상속 따윈 쓸일도 없었다.
그나마 typescript로 개발하면서 좋았던 점은 컴파일 할때 에러가 떨어지면 뭔가 얘네가 걸러주는게 있긴 하구나 하는 딱 그정도였다. 결론적으로 typescript는 내 능력에 비해 너무 고급이었다.
4.
빌드는 webpack으로 했다. 이거저거 보다가 그냥 webpack이 대세라길래 대세를 따랐다. browserify는 느리고 어쩌고 그런 말들이 있던데 안해봐서 패쓰. 무엇을 쓰던간에 빌드만 잘되면 되는거 아닌가.
5.
채팅방에 시간제한 기능이 있어서 moment를 사용했다. moment를 쓰면서 java 버전이 있었으면 좋겠다라는 생각이 들었다. (jodatime이 있긴 하지만..)
6.
프로젝트를 처음 시작했을 때 vuejs를 꼭한번 써봐야지라는 생각이 있었는데 설정하다가 포기했다. typescript가 문제인지 뭐가 문제인지 모르겠는데 아무튼 뭐가 잘 안맞았다. 안그래도 처음해보는거 투성이인데 vuejs에서 삽질을 하고 있자니 끝이 안보일거 같았다. 그래서 그냥 익숙한 jquery로 한땀한땀 개발했다. 요건 나중에 다른 프로젝트에서 다시 한번 써봐야겠다. (이래 놓고 react 쓰고 있겠지. react가 대세니까~)
7. deploy는 heroku의 도움을 받았다. 프로젝트 중간에 Redis를 도입했을때는 클라우드 같은건 생각을 안하고 있었다. 나중에 heroku에 셋팅을 하려고 보니 redis가 플러그인으로 제공되고 있었는데 redis를 선택하길 잘 했다는 생각이 이때 들었다. 다만 heroku가 좀 느려서 https://zeit.co/now 로 옮길까 생각 중이다.
사이트
https://vanilla-server.herokuapp.com/
소스
https://github.com/ekcode/vanilla
댓글
댓글 쓰기