블로그를 다시 오픈했다.
기존에 만들었던 블로그와 개발하면서 집중하고있는 바가 다르다.
기존에 만들었던. Hello World 1.0 과 Hello World 2.0 은
도메인 만료로 구글계정 로그인을 못해서 글을 못쓰다가,
vm의 vhd를 백업하던중 실수로 파일을 삭제하여, 통째로 전부 날라갔다.
복구툴로 복구하여 보려하였으나 실패하였고, 결국 사라지게 되었다.
이것은 Hello World 3.0이라 할수 있는, bruce.pllip.com ...
포커스하고 있는바가 기존과는 좀 다르다.
그 다름에 대해서 정리하여 보고자 한다.


1.소통

이전에 나는 싸이월드에서 근무하고 있었다.
그때에는 SNS에 관심이 많았고 소통에 관심이 많았다.
그래서 블로그에 글을쓰면 트위터,페이스북,미니홈피등 SNS에 작성한 글들이 전파가 되고
각 타인들이 전파된 글들에 각각의 SNS에서 작성한 댓글들을 블로그에서 모두 보일수 있고, 각각의 SNS의 계정을 이용해 블로그에서 직접 댓글을 작성할수 있었다.
하지만 작성하는 컨텐츠의 질이 그렇게 좋지않고
(보통 개발 이야기나 불평, 또는 배고프다 같은 아주 쓸모없는 일반이야기)
이었고 내가 직접 작성한 댓글 말고는 거의 소통이 없었다.
그래서 이번 블로그는 소통에 대해서 제외한다.
제외할기능은
"SNS전파, SNS댓글수집, 트랙백" 정도 될듯하다.
(트위터에 대한 전파는 아직 생각중이다. 이제 트위터는 SNS 보다는 새소식이있다를 알리는 미디어 정도로 보이기 때문에)


2.성능

또 성능에 대한 걱정이 많았다.
싸이월드가 하락해가고 있는 서비스이기는 했지만, 어느정도 많은 트래픽이 있었고,
미니홈피에 보이는 "아이템 추천영역"같은경우 어플리케이션 메모리에 올리지 않은체로 서비스하면 아이템샵 서비스에 장애가 나기도 하였었다.
때문에
어떻게 DB에 한번이라도 덜 접근할까?
어떻게 스테틱 리소스에 한번이라도 덜 접근할까?
어떻게 빠르게 서비스 할수 있을까?
에 많은 생각이 있었다.
그래서 single page architecture에 DB 캐싱, 서버 로컬 메모리 캐싱, 클라이언트 localStorage 캐싱, 클라이언트 앱캐싱 등 모든 단에 캐시가 있었고,
결과적으로 접근했던 페이지는 오프라인에서도 봐지는 수준까지 캐싱을 하였다.
하지만 아까 말했듯 컨텐츠가 좋지 못하다보니 많은 유입이 없었고,
그러다보니 웹서버 DB서버가 모두 전역할때 샀던 노트북에서 돌려도 CPU가 펑펑 놀 정도로 아주 한적 하였다.
또 클라이언트 캐시를 관리하는 스크립트 코드에 버그가 있었을때 접근했던 사용자는 스스로 캐시를 비우기 전에는 어떻게 처리를 하지도 못했다.
그래서 이번에는 아무것도 없다.
그런 복잡도는 접근하는 사용자가 많아지면 그때 다시 고민하겠다.

3. 개발 방법

전 직장의 성향 때문일까? 사용되는 많은 코드들이 직접 작성되었다.
페이지를 슬라이드 형태로 네비게이션 하는 SPA형 Javascript 모듈도 직접 작성하였고,
(jquery는 사용하였지만)
UI도 bootstrap없이 직접,
프론트는 .Net MVC 로 구현 하였었지만, Ruby on rails 를 흉내낸 Asset Managing 하는 모듈은 직접 작성하였고
Node.js로 구현되었던 API서버는 express나 mongoose 없이 자체 구현 라이브러리를 통해 구현하였었다.
물론 많은 공부가 되었지만, 관리도 쉽지않고 여기에 그렇게 까지 투자하고 싶지도 않고...
(날라가 버린 아쉬움일까?)
대부분 오픈소스에 UI도 오픈된 템플릿을 사용하여 만들었다.

지금까지 제외된 기능들에 대하여 적었다.
오늘은 여기까지 하고, 다음에는 포기하지 못한, 계속 가지고갈 계획인 것들에 대해서 적어볼까 한다.