2017. 1. 27. 14:29 BlahBlah

블로그 이전

Tistory에서 github pages로 블로그 이전 했습니다. 티스토리 백업 중지는 폐쇄 전 움직임 같아 보여 안심할 수가 없네요.


이전한 블로그 주소는 다음과 같습니다!

RSS Feed 주소 - https://elky84.github.io/


앞으로는 이쪽에서 블로깅을 하게 됐으니~~ 새로 RSS 구독 신청 부탁드립니다!



Posted by 엘키 엘키

댓글을 달아 주세요

오늘은 많은 서버 개발자 분들이 (그리고 더 많은 다른 파트 개발자 분들이) 알고 계신데 막상 개발 플랜에 누락되는 일이 비일비재한 것들에 대해 이야기 해보고자 합니다.

많은 팀이 겪게되는 가상 시나리오를 그려보겠습니다.


--------------------------------------------------------------------------------------------

프로토타이핑이 성공적이었습니다!

개발팀이 세팅 됩니다.


개발 언어, 플랫폼, 엔진 (or 프레임워크)등을 정하게 되죠.


베이스 작업 기간으로 한달 정도 잡습니다.


컨텐츠별로 1주~2주 사이를 잡습니다.

그리고 각 컨텐츠가 다 완성되고 폴리싱 작업으로 한달 잡네요.


네. 좋습니다.


대략 컨텐츠가 8개 정도 되네요.


평이한 컨텐츠가 다수라 8주라 예상해봅시다.



베이스 작업+컨텐츠해서 3달 나왔네요.

폴리싱까지 4달이었죠?


여유 기간 포함해서 5달 질러봅니다.

오오!! 승인됐네요.


자~ 작업에 들어갑니다.

베이스 작업은 예상대로 잘 됩니다. 오히려 시간이 조금 남았네요?


작은 오차들과 예상외 변수가 있었지만 그럭저럭 개발 기간을 맞췄군요!


기능도 오류가 좀 있지만, 폴리싱 기간에 집중하면 될거 같은 양입니다.

출시 문제 없겠네요. 하하하~


… 헌데… 예상치 못한 일들이 끼어들어오기 시작합니다.

GM툴과 사용법을 달라고 하시는군요.


… 헐...꼭 해줘야할까…? 고민도 되고 반려도 하고 싶지만, 서비스를 위해 꼭 필요한 기능이죠.

갑자기 머리가 아파집니다.


우선 GM툴이 만들어질때까지, DB쿼리를 만들어 테스트를 지원합니다.


자...다른 일정을 몇개 양보받고, 시간을 쪼개고 쪼개서 GM툴을 만들어 제공합니다.


이전보다 원활한 테스트가 진행되는군요.

자 이제 출시 준비를 하려는데… 통계툴을 요청받습니다.


….-_- 더 시간을 확보할 방법도 없는데…

최소한의 기능만 볼 수 있게 끼워 넣습니다…

남기고 있는 로그가 추출하기 적절한 로그가 아니라, 로그 기록 작업을 하느라 더 시간 소모가 컸군요.



어라? 당연히 필요한 결제 기능이 없었군요?

지원 해야 될 스토어가 세종류네요…

스토어별로 처리 방식이 달라, 세번 다 따로 구현해야 되겠군요...


자 어떻게든 선택과 집중을 통해 몇몇 기능과 퀄리티를 양보하며, 필요한 백엔드 작업을  그럭저럭 마친 것 같습니다.


게임을 출시합니다.


가아아아암동~ 몇달간의 노력이 드디어 빛을 발할 때 입니다.

유저가 몰립니다. 우오오오오~~


서버를 증설합니다!

이제 서버가 50대로 구성됐습니다.

이제 점검을 할 때마다 50대에 배포 해야 되네요…

한대당 2분 잡아도 패치만 100분이군요.

다행히 우린 서버 프로그래머가 2명이니 50분 정도면 될까요?


부족한 운영툴의 기능으로, 서버 데이터 패치로 이벤트를 진행합니다.


밤이 되었습니다.

유저는 여전히 많네요. 불안불안합니다.

새벽 3시가 됐음에도 유저는 별로 줄어들지 않네요.


혹시 몰라 서버 50대를 순회하며, 오류 로그를 모니터링합니다.


헐…! 사고가 났네요. 복구 및 보상을 해줘야겠습니다.


… 점검시점에서 모든 유저에게 보상을 주자니 너무 많네요.

로그인시 아이템을 지급하는 보상 시스템을 구현합니다…


…하… 복구를 하려했더니 백업된 데이터가 부족하네요. 백업/복구 시스템을 못갖춰놨었습니다.


이대로 롤백해야 되는걸까요…?

--------------------------------------------------------------------------------------------



자… 이쯤 되면 감이 오시나요?

서버라는 포지션 자체는 당연하게도 서비스를 위해 존재합니다.


비지니스 로직이 아닌 작업이 이렇게나 많이 필요하고, 당연히 많은 시간이 필요합니다.



물론 제가 나열한 작업 중에 여러 작업이 지원 부서가 있는 회사. 혹은 퍼블리셔에서 제공되는 기능들도 많습니다.


하지만 의외로 원하는 기능들 중 빠졌거나, 기능은 제공되지만 세부적인 기능이 달라 사용할 수 없는 일도 비일 비재합니다.


혹은 원하는 기능이 모두 있는 서비스는 비용이 비싸서 사용하기 부담스러운 경우도 생기지요.



가장 큰 문제는 이런 백엔드 작업들이 개발 초기 단계부터 일정 산정에 고려 대상이 아닐 때가 많다는 입니다.


개발 담당자가 직접 어필하지 않으면, 백엔드 작업은 프로젝트 전체 일정 산정에 고려되지 않을 공산이 큽니다.


개발 초기 서비스 일정을 산정하셔야 되는 분들이라면, 이 글을 읽으시고 하나라도 더 떠올리시어 백엔드 작업 일정과 작업 계획도 수립하시길 바라며 마치겠습니다.



-----------------------------------------------------

컨텐츠 제외 필요 작업 요약

-----------------------------------------------------

GM툴

통계툴

로그 기록 작업

결제 기능

배포

이벤트

모니터링

보상 시스템

백업/복구 시스템

Posted by 엘키 엘키

댓글을 달아 주세요

내가 가장 자신 있는 언어는 C++이다.

가장 오랜 시간을 사용해왔고, 가장 많은 코드 작성을, 분석을, 테스트를, 서비스를 해왔던 언어기 때문이다.


다음으로 익숙한 언어는 ruby다.

ruby를 통한 scripting, rails를 기반으로 한 web_service 등 C++ 다음으로 익숙하다고 볼 수 있다.


그 다음 언어는 C#.

unity에서도 c#, 간단한 툴 작업이나 TCP client, server 작업 등 몇 가지 작업들을 진행했다.


이외에도 이전부터 간단하게 사용 가능하던 언어는 몇 가지 있다.


php : 너무 오래전에 사용했다. 특히나 다른 분이 작업해두신 GM툴 기능 유지보수와, 게시판 하나 만들어본 정도였고, 최근 발전 방향을 보면 기대해봄직은 하지만...


perl : 써본지도 너무 오래… 특히 ruby를 익히고 난 이후는… 이제와서 perl의 학습을 하는건, 포트란, 파스칼, 코볼 같은 녀석을 놓지 못했던 익숙한 언어에 대한 미련처럼 비추어 질 수도 있단 생각도 든다.

어떤 측면으로 봐도 ruby와 python이 너무 잘 대체했으니 말이다.


erlang : 함수형 언어의 개념과 이해도를 위한 학습 정도?

조금 더 깊게 파고 들고자 할 땐 erlang보다 go lang이나 elixir를 사용해보고 싶다.


java script : 그래도 꽤 많이 사용한 편이다. WScript라는 스크립트 파싱 엔진을 통해 윈도우에서 batch script를 병행해 사용 해왔고, 실제 프로젝트에 적용했었으니… node.js를 통해서도 사용해보았으나, java script의 장점을 잘 모르겠다.


java script 처럼 자유도가 높은 언어를 서버 사이드에서 사용할 때에는, 분명히 보완재 (unit test 강제) 등이 필요 할텐데... 콜백 지옥을 탈출하는 방법도 많이 있고, typescript처럼 타입 자유도를 극복하는 방법도 있지만, 이런 많은 우려를 딛고 극복해야 할만큼 매력있는 언어인지는 잘 모르겠다.



이런 경험 들을 기반으로 가장 관심이 간 언어는… Go다.

정적 언어의 효율성과 동적 언어의 쉬운 적용이 장점이라고 하더라.


Go 프로그래밍 위키

https://ko.wikipedia.org/wiki/Go_(%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D_%EC%96%B8%EC%96%B4)


Go는 정적 타입 컴파일 언어의 효율성과 동적 언어처럼 쉬운 프로그래밍을 할 수 있도록 하는 것을 목표로 한다. 또다른 목적은:

  • 안전성 : 타입 안전성과 메모리 안전성

  • 병행성과 통신을 위한 훌륭한 지원

  • 효과적인 가비지 컬렉션

  • 빠른 컴파일


위와 같은 장점을 가지고 있다고 한다.

한번 웹 서버로 작업하면서, 어떤 장단점이 있는지 좀 더 느껴보고 싶다.


또 관심이 가는 언어가 있는데, 바로 scala다.

java api와 손쉽게 연동이 되며, 객체 지향 프로그래밍과, 함수형 프로그래밍의 장점을 잘 섞었다고 평가 받는 scala도 써보고 평가하고 싶다.


https://ko.wikipedia.org/wiki/%EC%8A%A4%EC%B9%BC%EB%9D%BC_(%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D_%EC%96%B8%EC%96%B4)#cite_note-singleton-8


대부분의 스칼라 관련 문서들에서 스칼라와 자바의 연관성을 '너무 바빠서 다른 언어를 따로 배울 시간이 없는 자바 프로그래머를 위한'[5] 이라는 표현을 사용하여 나타낼 정도로 비슷한 부분이 많이 나타난다.


문제는 아직 내가 java를 능숙하게 사용하지 못한다는 점이다. 그렇다면 왜 스칼라? 바로…! ruby와 유사한 코딩이 가능하기 때문이다.

실제로 루비의 영향을 받았고 (위키 참조), 타입이 없는 언어이기도 하다. 또한 모든 것은 객체이기도 하다는 말은 스칼라에서도 통용된다.


루비의 단점은 성능 문제라거나, 비동기 작업의 리스크를 줄여줄 수 있는 언어란 생각이 든다.


현재의 두 언어를 살펴보는 이유는, rails의 성능 적인 이슈를 해결하려는 시도가 두 언어 위주로 이루어졌기 때문이다.


나 역시 rails의 장단점을 겪어본 입장에서, 크게 공감 되는 문제기도 하고.


과연… ruby의 뒤를 잇는 내 주력 언어가 이 두 언어 중에서 나오게 될까?

Posted by 엘키 엘키

댓글을 달아 주세요

2015. 12. 9. 18:43 BlahBlah

업무 일지 쓰는 법

저는 불행인지 다행인지, 업무 일지를 강제하는 회사를 다녀본 경험이 없습니다.


대부분의 회사에서의 업무 관리는 redmine이나, 구두로 전달되어온 스케쥴에 의존했죠.


이렇다보니, 개인적으로 업무일지를 작성하기 시작했습니다. 왜냐하면 (다들 아시다시피) 기억력에 의존해서 업무를 진행하기란 한계가 있으며, redmine과 같은 업무 관리 도구로 모든 업무를 관리하고 트랙킹하기란 쉽지 않기 때문이죠.


특히나, redmine과 같은 도구에 (여러가지 이유로)개인적인 감상을 적기 어렵다는 점도 한몫합니다.



결국은 온전한 업무 기록은 개인적으로 따로 관리해야 한다는 건데, 그러다보니 자율적으로 업무 일지를 써왔습니다.


업무 일지의 목적은 히스토리.


업무가 많다보면 자연스레 기록을 필요로 합니다. 이 과정에서, 기록되는 주 공간은 text, 연습장, 메모앱 등등이 되겠죠?



그런 기록의 공간을 업무 일지 기록소 [개인적으로 note류 앱 중, one note, evernote, google docs 모두 사용해보았는데, 장단이 있습니다. 굳이 특정 앱을 사용할 필요는 없습니다.]로 옮겨간다라고 생각하면 편합니다.



업무 일지 요령은, 하루 동안 업무에 관련되어 겪은 일들을 정리하는 과정이라고 보시면 됩니다.


어떤 업무를 진행하는 데에 있어서의 과정을 최대한 많이 기록한다라고 보시면 되요.


특히 과정 [디버깅이건, 타 파트 업무 지원이건, 네트워크 장애건, PC 오류건, 개인 용무건 뭐든간에]을 기록해 업무에 방해되는 요소를 알 수 있습니다.


또는 내가 일을 굉장히 잘하는지 못하는지에 대한 계측 도구로도 사용가능하죠.



업무 일지는 많은 분들이 쓰시는데, 그 중 제가 사용하고 있는 방식에 대해 간략히 보충 설명 할게요.


1. 월간, 분기간, 연간 리뷰.

  • 리뷰를 하며, 기록한 업무 일지를 재정리 합니다.


2. 큰 작업별 업무 기록 분리.

  • 해당 업무의 예상 기간과, 실제 진행 기간간에 분리합니다.
    • 주단위를 넘어가는 큰 개발 일정이 연간 생각보다 그다지 많지 않습니다. [많더라도 정리합시다]
  • 작업별로 재정리된 예상 소요시간과, 실제 소요시간의 갭, 오차의 원인등을 같이 남겨서 아카이브합니다.


3. 병목 지점 파악

  • 회사별로, 동료별로 나의 업무에 영향을 주는 방식,정도가 다릅니다.
    • 이를 파악하는 지표로 분석해야 합니다.
  • 그게 장비나 툴의 문제라면 더더욱 개선해야 합니다.
    • 예를 들어 빌드 내서 테스트 해야되는 작업인데, APK로만 테스트하느라 빌드 시간 10분*20해서, 3시간동안을 빌드에만 사용해서 디버깅 및 테스트를 진행했다라고 하면, 몇가지 접근이 나옵니다.
      • APK 빌드 시간을 단축.
      • 테스트할 기능만 담은 새 프로젝트를 기반으로 테스트해 시간 단축.
      • 자동화 테스트 스크립트 작성
    • 이렇듯 시간을 아낄 수 있는 방법을 통해 생산성을 높여야, 잉여 시간을 만들 수 있습니다.
      • 잉여 시간을 자기 개발 + 업무 개선을 반복함으로써 짱짱맨이 되시길...!


이상 간략한 업무 일지 및 정리 방법 요약이었습니다.


Posted by 엘키 엘키

댓글을 달아 주세요

기계식 키보드 지름 완료! 집에선 청축으로 마음껏 소리내며 코딩하다가, 회사 키보드가 기계식이 아니니 아쉬워 꽤나 길게 고민하던 차에... 위메프에 기계식 키보드가 싸게 올라왔다.

http://wemakeprice.com/deal/adeal/108977

CM STORM QUICK FIRE TK WHITE | 적축
키는 검은색, 보드는 흰색!
거기다 흰색 LED!!!

나온지도 얼마 안된 제품이라 눈여겨 보고 있었는데 후다닥 질렀다.

지금 1명 구매로 뜬게 나임.

기계식 키보드 관심있는분 지르세요!! 지금이 기회!!!



Posted by 엘키 엘키

댓글을 달아 주세요

내가 처음 접한 프로그래밍 언어는 Basic이 아닌, C였다.


그리고 Turbo-C 2.0이 첫 컴파일러였다.


내가 처음 샀던 C언어 서적이 터보 C 2.0을 알려주는 주황색 서적이었는데, 뭔가 시리즈 였던 기억이 난다.


그 책이 너무 설명이 어려워, 다음에 샀던 책이 바로, Turbo-C 2.0 길라잡이다.

http://books.google.co.kr/books/about/%ED%84%B0%EB%B3%B4_C_2_0_%EA%B8%B8%EB%9D%BC%EC%9E%A1%EC%9D%B4_S_W%ED%8F%AC%ED%95%A8.html?id=9MZ3MgAACAAJ&redir_esc=y


내 기억에 이 책의 표지는 초록색이었는데, 사진도 목차도 안나와있어서이책이 맞는지는 모르겠다



여튼 당시 내가 봤던 서적에서의 "Hello, World!"는 다음과 같다.


#include < stdio.h >
void main()
{
    printf("Hello, World!\n");
}




뭐....당시엔 대다수 국내 C언어 서적이 저랬을려나...?

ANSI C Programming의 번역서만이.


#include < stdio.h >
int main(int argc, char* argv[])
{
    printf("Hello, World!\n");
    return 0;
}

였던걸로 기억한다.


고작 이게 뭐 그리 중요하냐고?

이 별거 아닌 차이가, 유닉스 문화와 윈도우 문화를 가르는 발단이 되었기 때문이다.


GCC에서는 애초에 void main()이 허용되지 않는다.


유닉스에서는 명령행 프로그램 사이의 연동에 인자(int argc, char* argv[])를, 넘기고 그 결과로 exit 코드 (main의 int 리턴 타입)를 이용한다.

그래서 프로그램간의 연동이 쉽게 가능하며, 명령행 프로그램 위에 UI를 붙이는 과정이 이런 전제하에 있다. (물론, 파이프 통신이나 소켓 통신등으로 IPC를 하기도 하지만)



여러 포스팅을 보면, void mai()과 int main(int argc, char* argv[])의 차이에 대해 표준에 대한 이유를 언급하곤 하는데, 이 표준의 전제에는 프로그램 간의 상호 작용을 매끄럽게 하기 위해서라 할 수 있다.


터보-C와 MSC라 불리우는 Visual C++이 void main() 을 허용하다보니, 그렇게 만들어진 프로그램의 exit코드는 신용할 수 없다.

물론 리눅스 환경에서 개발됐고, ANSI C 표준을 따른 프로그램이라해도, 목표로한 동작을 완료하지 못했음에도 exit코드를 0이 아닌 값을 반환하는 상황도 있을 수 있으나, 대부분의 규칙을 잘 따른 프로그램들은 정상 수행에 0을 반환한다는 것을 목표로 삼고 있다.


이 반환값을 기반으로 도는 프로그램은 수없이 많다.


나는 철저히 윈도우 프로그래머였다. 그것도 클라이언트 온리 게임만 만들던 동인 게임 개발자였고.


애초에 프로그램간의 연동이 목표가 아니라, 그저 내 프로그램 하나가 수많은 기능을 담고 싶어했던, 바퀴를 다시 발명하는 것을 즐겼던(?) 그저 흔한 프로그래머였음은 물론이고. 심지어 게임 개발할 때마다 전용 툴까지도 만들었던...흑역사를 품고 있다.


내가 윈도우 쉘 연동으로 생산성을 높이게됐던 계기는, 서버 개발자가 된 후 라이브팀 업무때가 주로 그랬다. 나에게 주어진 시간은 그다지 많지 않았고, 컨텐츠를 개발하는 일 이외의 시간은 사실 잘 주어지지 않았다. 그렇다보니 자연스레 바퀴를 재발명하는건 시간이 부족하다보니 여의치않아졌다.


가능하면 기존에 있는 기능들을 잘 묶고, 명령행 프로그램 여러개의 기능을 엮는 자동화에 대한 의지가 늘게된 시기였다. 


물론 이전에도 난 게으르기 때문에, 게을러 지기 위한 기반 작업. 자동화에 대한 의지가 있었으나 그 자동화를 C++ 코드위에서 하곤 했다. FTP고, HTTP고 WIN32 API를 통해 다시 만들어, 내 프로그램 위에 얹었다.


잘 만들어져 있는 명령행 프로그램들을 엮는 일이, 얼마나 내 생산성을 높아지게 했는지 뼈저리게 느꼈다.

그와 함께 기존에 안좋았던 습관들이 조금씩 사라지게 된 계기가 됐고.


그런 깨닳음을 얻어가던 중 내가 만든 여러 프로그램들을 돌이켜봤다.



어째서 내 프로그램은 어찌 하나같이, GUI 기반으로만 동작하는가?!?

GUI기반으로 동작하는건 좋다 이거야. 헌데, 다른 프로그램과 엮기 왜 이렇게 힘든거지?


내가 짠 프로그램들은 하나같이 main함수에서 return 0으로 프로그램을 종료시키고 있었다.

원하는 목표를 달성했는지 여부와는 전혀 상관없이 말이다.


기능을 재사용하는건 , 라이브러리화 해둔 코드를 재사용하는 것에 의존했을 뿐이었고.




별거 아닌거 같으면서, 큰 깨닳음을 얻고, 자동화와 각종 보조 업무등을 위해 다른 사람들이 만든 프로그램들을 엮는 작업이 늘어가면서 내가 만든 프로그램들도 그 사이에 엮을 수 있게끔  맞춰가고 있다.



아직 많이 미숙하지만 리눅스 환경에서 ROR을 운영하며 리눅스에서의 기능 재사용, 프로그램 사이의 연동의 문화, 흔히 리눅스 문화라 불리는 것들을 잘 느낄 수 있었다. 


윈도우 환경 위에서 만들어진 수 많은 메이저 프로그램이 명령행 기능을 지원하지 않는다. 


특정 프로그램에서 95%가 만족스러운데, 살짝 아쉬운 한두가지 요소 때문에, 다른 프로그램을 찾아 다녀야했던 일이 리눅스 문화라고 없는건 아니지만, 명령행 위에 UI를 얹은 많은 프로그램들은 이런 고민을 해결해준다.



이런 깨닳음이 늦게 온 원인이 윈도우 환경 위에서 프로그래밍을 해왔기 때문이라고 핑계대고 싶진 않다.

다만 GUI 환경의 문화가 프로그램 사이의 연동을 어렵게 만드는 요인이라는 생각을 갖게 됐다.


아직 능숙해지려면 멀었지만 리눅스 환경에 조금씩 적응될수록 여러가지 생각이 드는데, 그 중 명령행 프로그램에 대한 이야기는 꼭 한번 하고 싶었다.


앞으로도 윈도우 환경에 대한 감사함을 얼마나 느끼게 될지, 리눅스 환경에 대한 감탄을 얼마나 하게 될지는 잘 모르겠지만 윈도우'만' 써왔다고 할 수 있는 프로그래머가, 리눅스 환경에 적응해가며 드는 감상을 적어보겠다. 

Posted by 엘키 엘키

댓글을 달아 주세요

ruby를 포터블 버전으로 패키징해서 관리해오고 있었음.


새로 추가된 wxruby-ruby19가 직접 gem을 install 한 pc가 아니면 미동작함.


뭐가 문제일지 계속 고민했으나, 증상은 gem을 install한 pc에서만 동작. SVN으로 check-out 받거나, export된 파일을 실행한 경우에는 정상 동작 하지 않음.


뭔가 이상해서 gem install한 pc에서 동작하는 폴더를 통째로 압축하고, ruby가 전혀 설치되지 않은 pc에서 실행해도 제대로 동작.


알고봤더니, so파일이 커밋이 되지 않아 오류 발생.


so 파일은 SVN 기본 ignore 파일.


아...내 아까운 시간... ㅠ_ㅠ


말도 안되는 상황이라 여겼는데, Redmine이나 ROR도 Portable 버전이 많이 돌아다니는데 그런 애들은 잘 돌아갔기 때문에...!!


역시나 루비 문제가 아니었고, SVN으로 패키징 파일을 공유하는 데에서 온 문제였음.


따지고 보면 이런 것도 디버깅이라 봐야겠지? -_-;

Posted by 엘키 엘키

댓글을 달아 주세요

음... 작년 말부터 올해 초반 블로그 방문자가 폭증(?) 했던 것은 좋았는데, 좀 허수가 섞인거 같기도하고... 

뭐때문에 방문하셨는지 구분도 잘 안가더군요.


또 제가 자료 찾을 때에도 좀 번잡하기도해서 블로그를 분리했습니다.

주제가 잡다하다보니 RSS로 구독하시는 분들께도 죄송하기도 하고 말이죠.


분류는 세종류 블로그로 나눴습니다.


엘키의 주절주절

http://elky.tistory.com 


개인사와, 프로그래밍에 관한 이야기를 합니다.

역시나 주는 프로그래밍 이야기겠지요~


엘키의 게임 이야기

http://game-story.tistory.com 


제목처럼 게임 이야기만 다룹니다. 

어린 시절 즐겼던 게임부터, 최근 즐기고 있는 게임 등에 대한 이야기를 쓸 예정입니다.

주로 리뷰나, 사담을 쓸까합니다. 오픈 케이스는 아마 요새 저도 스팀이나 오리진, 플레이 스토어 등지에서 구입하는지라 업데이트가 잘 되지 않겠지만 말이죠.


아무래도 업계인인 만큼 필터링을 안거치긴 어려울거 같네요.


외국 게임이나 고전게임은 가차없이 까거나 칭찬하도록 노력해볼게요. 옛날에 운영했던 홈페이지들 처럼 말이죠.


엘키의 잡다 리뷰

http://elky-review.tistory.com/


이것도 제목처럼 리뷰 위주로 씁니다.

프로그래밍 서적 서평 / 게임 리뷰만 제외하고요.


주로 문화생활 했던 것들에 대한 사담이나, 축구, 사용기등을 올릴 예정입니다.


진짜 걍 아무거나 대충 쓸 생각입니다.


여긴 안오셔도 됨.




걍... 그렇다구요 -_-

Posted by 엘키 엘키

댓글을 달아 주세요

이전버튼 1 2 3 4 5 이전버튼

블로그 이미지
Software Engineer
엘키

공지사항

Yesterday31
Today27
Total1,605,481

달력

 « |  » 2020.8
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

글 보관함