Congroo

  • Google Analytics로 GitHub 페이지 분석하기

    Mar 2, 2017 •

    Google Analytics?

    Google에서는 Analytics 라는 강력한 무료 방문자 분석 서비스를 제공한다. 멋진 웹 그래프도 확인할 수 있고, 적용법도 JS 코드만 집어넣으면 되니 아주 간단하다. 복잡할 것 없는 포스트이니 빠르게 따라오면 될 것 같다.

    사전 준비

    위 Analytics 서비스 웹사이트로 들어가 초기 세팅을 해둔다. 누구나 하나쯤 있는 Google 계정으로 로그인한 후, 추적할 대상 (Analytics는 웹사이트 뿐만 아니라 Admob 광고나 Android 앱 등 여러가지 대상 추적을 지원한다.)을 선택하는 등 시키는대로 해주면 된다. 마지막에 JS로 작성된 추적 코드를 주는데, 그걸 복사하고 잘 가지고 있자. 물론 지금 복사하지 않아도 나중에 언제든지 Analytics 대시보드에 들어와 복사할 수 있다.

    추적 코드 집어넣기

    여기가 핵심이다. Analytics 웹사이트에는 추적할 모든 페이지에 추적 코드를 삽입하라고 겁준다. 여기서 쫄면 안된다. 정말 “모든” 웹사이트에 코드를 넣을 일은 없다. GitHub 페이지에 테마를 설치한 적이 있다면 아마 _includes라는 폴더가 존재할 것이다. 여기에 google_analytics.html이라는 파일을 하나 만들어 준다. 그리고 아래처럼 코드를 집어넣어 보자

        <!-- Google Analytics -->
    <script>
      (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
      (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
      m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
      })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

      ga('create', '내 추적 ID', 'auto');
      ga('send', 'pageview');

    </script>

    이제 같은 폴더 안의 head.html에서 호출만 하면 된다. Jekyll은 표준 Liquid 문법을 모두 지원원하니 head.html 파일의 <head> 태그 안 어디나 include google_analytics.html 블록 (코드에 블록 처리는 해줘야 한다. 원본 코드를 그대로 글에 넣으니 Markdown이 그걸 읽어버려서 죽어도 정상적인 출력이 안된다. 방법을 알아내면 수정하겠다. 당장 이해가 안된다면 여기 참조.)을 집어넣어주면 작업 끝.

    이제 GitHub에 Push하고 며칠 뒤 다시 Google Analytics를 확인해보자. 방문자 통계가 제대로 찍혀 있을 거다. 혹시 Analytics가 제대로 작동하는 것 같지 않다면 Google Tag Assistant 를 사용해보자. 간단한 Chrome 에드온인데 내 사이트에서 Analytics가 제대로 작동 중인지 실시간으로 확인할 수 있는 듯 하다.

  • 공짜 라즈베리 파이가 생겼다

    Mar 2, 2017 •

    freerpi

    라즈베리 파이가 처음 세상에 발표됬을 때부터 언젠가 한번 구매해서 사용해보자는 생각은 있었지만, 명확한 사용 용도가 없었기에 정작 지갑은 열지 못하고 있었다. 임베디드나 IoT쪽에 관심은 있지만, 직접 보드를 사서까지 구현할 아이디어가 있는 것도 아니였기에 더더욱 필요가 없었다고 할까.

    그런데 어떤 제품이던 공짜가 된다면 상황이 완전히 달라진다. 어제 친한 지인에게서 “남는” 라즈베리 파이 모델 3를 얻어오자마자 필요가 생길 것만 같은 느낌이다. 파이의 하드웨어도 관심이 없던 사이 많이 발전한 것 같다. 램도 무려 1GB나 들어가고 내장 Wi-Fi와 Bluetooth 모듈도 내장하고 있다. 사실상 라이트한 작업 대부분을 처리할 수 있는 PC로 기동해도 손색이 없을 수준이라는 소리다.

    그런 점을 살려서 예전에 잠깐 구상하다 잊어버린 프로젝트를 파이를 위해 끌어올까 한다. Piranoid 라는 거창한 이름까지 생각해뒀는데, 이것 관련해서는 조금 진행이 된다면 따로 페이지를 만들어서 자세히 기록해 두겠다.

  • GitHub에 개인 페이지 만들기

    Mar 1, 2017 •

    jekyllwithoctocat

    이전부터 GitHub에서 페이지 형태의 웹사이트를 만들 수 있다는 것은 알고 있었다. 아무래도 GitHub 측에서도 워낙 잘 밀어주기도 했고, 가끔가다 구글에 잡히는 사이트 중 github.io 도메인을 달고 있는 곳들이 있었으니까. 그래서 뭔가 기록할 페이지를 만들때 어떤 서비스를 사용할지 고민이 없었다. 전통적인 네이버 블로그나 티스토리 같은 것도 있고, 양질의 글이 많이 올라와 요즘 종종 눈팅하는 브런치도 물론 괜찮겠지만 역시 “Geek”스러움이 떨어지는 것은 어쩔 수 없었나보다.

    Jekyll(지킬)?

    처음 “Jekyll”이라는 이름을 보고 이걸 어떻게 읽어야 하나 잠깐 난감했었는데 찾아보니 지킬과 하이든 할때 그 지킬이란다. 공식 한국어 홈페이지 에서는 “심플하고 블로그 지향적인 정적(Static) 사이트 생성기” 라고 스스로를 정의하고 있다. 간단한 Markdown 문법이나 HTML 등으로 글을 쓰면 Liquid 렌더러를 통해 자동으로 가공하고 완성된 웹페이지를 보여주는 훌륭한 도구인 것 같다.

    당연히 여기서의 핵심은 Jekyll로 웹사이트를 만들면 GitHub에 무료로 사이트를 올릴 수 있다는 점. 멋있는 github.io 도메인은 덤이다.

    그래서, 페이지는 언제 만드나요?

    지금부터 만들 거다. 오래 걸리지 않으니 서두르지 마라. GitHub에서는 크게 개인/팀 페이지와 프로젝트 페이지. 2가지 종류의 웹사이트를 호스팅할 수 있다. 여기서는 개인 페이지를 기준으로 설명할 것이다. 더 자세한 정보나 프로젝트 페이지를 만들고 싶은 분들은 GitHub Pages 사이트를 방문하면 된다.

    잠깐 새 창에 GitHub를 띄우고, username.github.io 형태의 새로운 저장소(repo)를 만들어보자. username이 내 GitHub 유저네임과 완전히 같이 않으면 사이트가 작동하지 않으니 주의. 저장소가 만들어졌으면, git clone으로 끌어와 보자. 나는 터미널에서 git을 사용하니 명령어 위주로 서술하겠다.

      git clone https://github.com/username/username.github.io

    터미널에서 clone받은 저장소 폴더로 들어간 후, index.html 파일에 “Hello World”를 박아 보자.

      cd username.github.io

  echo "Hello World" > index.html

    이제 다시 GitHub로 올려 제대로 작동하는지 확인할 차례다. git push 명령어로 올려 보자.

      git add --all

  git commit -m "변경점 기록"

  git push -u origin master

    이제 브라우저에 username.github.io 주소를 넣어보자. 정상적으로 “Hello World”가 출력되면 잘 진행된 거다.

    사이트 생성에 조금 시간이 걸릴 수도 있으니, 당장 잘 뜨지 않는다고 하더라도 몇분 더 기다려보자.

    Jekyll 사이트 생성하기

    잠깐 브라우저 창을 닫고 터미널을 띄우자. 잠깐 위에 링크를 달아둔 Jekyll의 공식 웹페이지를 둘러봤다면 이것이 Ruby를 기반으로 만들어졌다는 것을 알 것이다. 고맙게도 Ruby도 마치 데비안의 apt-get 같은 gem 이라는 분산 패키지 시스템이 존재한다. Ruby를 다뤄본 경험이 없다고 해도 전혀 걱정할 것 없다. 그건 필자도 마찬가지다.

    당황하지 말고 gem install jekyll bundler 명령어로 Jekyll 번들을 다운받자. 최신 macOS와 Linux 배포판에는 이미 Ruby가 설치되어 있으니 별 문제 없을 것이다.

    사실 Jekyll에는 jekyll new 사이트이름 이라는 명령어로 바로 사이트를 생성할 수 있는 기능이 있지만, 이렇게 하면 기본 테마가 바로 설치되어버려 나중에 귀찮아지는 단점이 있다. 최신 Jekyll에서는 기본 테마 사용을 권장하지 않는다. 사용에 필요한 _layouts 같은 폴더들이 기본 테마로 설치하면 생성되지 않게 된다.

    필자의 페이지는 whiteglass 테마를 사용한다. 자유롭게 사용 가능한 많은 테마들이 Jekyll Themes 에서 기다리지 한번 살펴보길 추천한다. 테마 적용에는 별 것 없다. 다운받은 테마 폴더가 그대로 사이트를 구성하는 전부가 된다. 터미널에서 해당 폴더로 이동 후, jekyll serve 라는 명령어로 로컬 서버를 구동해보자. 브라우저에서 localhost:4000으로 접근해보면 정상적으로 사이트가 출력될 것이다. 그게 전부다. 이제 가지고 놀면 된다.

    상단 경로에 config.yml이라는 파일이 있을 건데, 들어가면 사이트를 구성하는 title이나 author정보 같은 것들을 수정할 수 있다. 나에게 맞게 고쳐주자. _posts 폴더에 Markdown 문법으로 작성한 글을 넣어주거나 이것저것 테마에 맞는 설정들을 해주자. 사실 상당히 직관적으로 구성되어 있어서 별도의 메뉴얼 없이 대부분의 세탕이 가능할 정도다. 자세한 정보를 원한다면 여길 쭉 읽어보길 권한다.

    이제 무엇을 해야 하나요?

    일단 어느정도 페이지 구실을 하는 물건이 완성되었다면, GitHub에 푸시하고 username.github.io 주소로 접근해 보자. 로컬 서버에서 보는 것과 온라인에 올라간 페이지를 보는 느낌이 또 다를 것이다.

    이제 나머지는 여러분의 자유다. 이것저것 하고싶은 이야기를 Markdown으로 잔뜩 작성해 올려도 좋고, 오픈소스 테마들을 이것저것 맛보면서 공유경제가 무엇인지 피부로 느껴도 좋다.

    새로 페이지를 오픈하는 모든 분들에게 도움이 되었으면 하는 바람이다.

  • RDO로 간편하게 OpenStack 설치하기

    Feb 28, 2017 •

    시작하며

    RDO-Project(또는 PackStack)는 CentOS (레드헷 기반 대부분의 배포판)에 OpenStack 플랫폼을 얹을 수 있는 가장 쉽고 빠른 방법이다. 현대의 시스템 엔지니어링은 그 규모와 복잡함이 날로 커져감에 따라 가능한 모든 부분을 자동화하는 것이 점점 더 중요해지고 있다. RDO는 OpenStack 기반 테스트를 진행하거나, 또는 상용 인프라를 구축할 때 좋은 선택이 될 수 있을 것이다.

    작성 기준 환경은 아래와 같다.

    * Controller Node (Compute를 제외한 모든 서비스 구동) 1대 - 192.168.0.1
* Compute Node 2대 - `192.168.1.2`, `192.168.1.3`
* CentOS 7.2

    설치하기

    테스트 서버라면 상관 없지만, 혹시 상용 서비스를 위해 구축하는 시스템이라면 퍼포먼스와 안정성을 위해 사전에 꼭 디스크 RAID 설정을 권장한다. 꼭 비싼 하드웨어 RAID 컨트롤러를 구매할 필요는 없고. OS를 설치할 때 소프트웨어 레이드를 설정하면 충분하다. SSD 디스크를 사용할 경우 오히려 어중간한 하드웨어 RAID 컨트롤러보다 훨씬 안정적이고 속도도 잘 나온다고 하니 알아보길 권한다. 추후 필요가 있으면 이 부분 관련하여 따로 포스트를 작성하겠다.

    일단 필요한 준비물들이 모두 Good-to-Go 상태라면, 아래 과정을 따라와보자.

    sudo systemctl disable firewalld
sudo systemctl stop firewalld
sudo systemctl disable NetworkManager
sudo systemctl stop NetworkManager
sudo systemctl enable network
sudo systemctl start network

    위 명령어는 Controller와 Compute노드 구분 없이 모든 서버에 사전 입력해준다. 읽어보면 단번에 알겠지만, 설치 중 문제가 생길 수 있는 요인들을 제거하는 거다. 클러스터링에 방해가 될 수 있는 firewalld를 정지하고, 서버용 CentOS 7까지 들어와 기껏 만져둔 네트워크 설정들을 다 뒤집어버리는 NetworkManager도 죽인다. 마지막으로 혹시 네트워크 기능이 재부팅 때마다 정지될 경우 아래 두 줄을 입력해 언제나 네트워크를 활성화 상태로 둔다.

    이제 본격적으로 인스톨 과정에 들어가 보자. Controller에서 아래 명령어들로 인스톨 패키지를 단번에 다운로드할 수 있다. 다른 서버들은 그냥 놔두면 된다. 작성일 기준, 최신 OpenStack 릴리즈는 ocata지만, 안정성과 커뮤니지 지원 등을 생각해 2세대 전 버전인 mitaka를 사용하겠다. OpenStack은 6개월 단위로 신버전 릴리즈가 진행되고 있어, 정상적인 사용을 위해서는 1~2세대 전 버전을 선택해주는 편이 좋다. 1세대 전 버전인 newton도 얼마 전 테스트 결과 여러가지 버그들이 남아있어 거르겠다.

    sudo yum install -y https://rdoproject.org/repos/rdo-release.rpm

sudo yum install -y centos-release-openstack-mitaka

sudo yum update -y

sudo yum install -y openstack-packstack

    위 과정이 끝났다면 이제 인스톨러를 가동시킬 수 있다. 그런데 아무 설정 없이 바로 가동하면 당연히 우리가 원하는대로 구성이 불가능하다. 다행히 RDO는 자유롭게 설치 정보를 지정할 수 있는 스크립트를 읽어들일 수 있다. 바로 하나 생성해보기 전에, 혹시 root 계정 사용이 자유로운 환경이라면 앞으로의 과정은 root로 진행하는 것을 추천한다. 물론 보안 문제의 위험성은 잘 알고 있지만, 일반 계정에서 가끔 sudo 를 통해 진행했을 시 권한 문제가 발생해 꼬여버리는 경우가 있었다. 정확한 문제 요인을 발견하면 포스트를 수정하도록 하겠다. 일단 아래 명령어를 통해 스크립트를 하나 생성해보자.

    sudo packstack --gen-answer-file=스크립트이름.txt

    방금 생성한 스크립트 파일에 들어가, 아래 값들을 편집해 준다.

      CONFIG_KEYSTONE_API_VERSION=v3 // v2.0을 사용해도 되나, 추후 여러가지 범용성을 위해 v3 선택.

  CONFIG_PROVISION_DEMO=n

  CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=extnet:br-ex

  CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-ex:네트워크 인터페이스 이름

  CONFIG_NEUTRON_ML2_TYPE_DRIVERS=vxlan,flat

  CONFIG_CONTROLLER_HOST=192.168.1.1 // Controller의 관리 네트워크 IP

  CONFIG_COMPUTE_HOSTS=192.168.1.2, 192.168.1.3 // Compute 노드들의 관리 네트워크 IP

  CONFIG_NETWORK_HOSTS=192.168.1.1 // 상황에 따라 별도의 Network 노드를 둘 수도 있다. 여기서는 Controller 노드와 통합하겠다.

    스크립트를 실행하기 전, 이곳을 참고해 각 서버간 ssh 키를 공유해주는 것을 강력 권장한다. RDO는 ssh를 통해 OpenStack의 구성원이 될 노드들에 설치를 진행하는데, 사전에 키를 공유해두지 않으면 설치 과정 내내 각 서버들의 비밀번호를 계속 물어볼 것이다. 스크립트 돌리고 커피라도 한잔 마시고 오고 싶다면 꼭 이 과정을 미리 거쳐둬라. 키를 미리 공유해두면 추후 Compute 노드간 인스턴스(VM)의 실시간 마이그레이션도 별도의 설정 없이 가능해지니 더더욱 해둬라.

    준비가 완전히 끝났다면, sudo packstack --answer-file=내 파일 이름.txt 명령어로 스크립트를 실행한다. 이제 커피 한전 마시고 와도 좋다. 시간이 조금 걸릴 것이다. 아직 완전히 끝난 것은 아니니 이 웹페이지는 닫지 말고 잠깐 숨 돌리고 와라. 설치가 끝난 후 뵙겠다.

    한숨 돌리고 왔고 스크립트가 다 돌아갔다면, 아래 과정으로 기본적인 네트워크 설정을 잡아주자. 원본 메뉴얼은 이 곳을 확인하면 된다.

    Controller 에서 /etc/sysconfig/network-scripts/ifcfg-br-ex 파일을 들여다보면, 아까 스크립트에 지정한 br-ex 브릿지의 정보가 보일 것이다. 혹시 뭔가 익숙하다고 느껴지면 당신의 감이 좋은 것이다. IP 주소를 비롯해 여러 설정 정보들이 br-ex와 연결한 네트워크 어댑터의 그것으로 바뀌지 않았는가? 이제 이전의 네트워크 어댑터는 br-ex의 짐꾼이 되었다. 앞으로의 설정은 여기서 만져주면 된다. 혹시 스크립트를 돌리기 전에 네트워크 어댑터에 설정을 입력하지 않아 br-ex도 공허하다면, 이제 만져주면 된다. 아래 예시 설정값을 참고해 만져주자.

    DEVICE=br-ex // 브릿지 이름

DEVICETYPE=ovs // OpenStack에서 사용하는 브릿지는 OpenVSwitch(ovs)라는 기술을 사용한다.

TYPE=OVSBridge // 이곳도 위와 같은 의미.

BOOTPROTO=static // 서버의 IP가 막 바뀌면 사용할 수 없다. static(고정)으로 박아두자

IPADDR=192.168.0.1 // 브릿지의 (네트워크 어댑터의) IP

NETMASK=255.255.255.0 // IP의 서브넷 마스크

GATEWAY=192.168.122.1 // 브릿지의 (네트워크 어댑터의) 게이트웨이

DNS1=192.168.122.1  // 별도의 DNS를 굴리고 있지 않다면 8.8.8.8(Google DNS)나 사용하는 통신사의 것을 입력하자.

ONBOOT=yes // 부팅할 때 자동으로 브릿지도 작동

    혹시 브릿지의 노예가 되어버린 기존의 네트워크 인터페이스는 어떻게 되었는지 궁금한가? /etc/sysconfig/network-scripts/ifcfg-네트워크 인터페이스 이름 에 들어가보자. 아마 아래같이 되어 있을 것이다. 불쌍한 녀석.

    DEVICE=네트워크 인터페이스 이름

TYPE=OVSPort

DEVICETYPE=ovs

OVS_BRIDGE=br-ex

ONBOOT=yes

    여기까지 확인했으면, sudo systemctl restart network 명령어로 네트워크를 재시작한다. 만약 위 과정에서 편집한 내용이 있다면 재시작되며 적용될 것이다.

    이제 openstackclient에 접근해 기본적인 네트워크를 구성해줄 차례다. “내가 주인장이다” 라는 권한을 입증해주는 OpenStack RC파일은 RDO가 미리 생성해 두었다. 우리는 그걸 사용하기만 하면 된다. 기본 경로에 있다면, . keystonerc_admin 명령어로 client를 실행해 보자. 입력창에 무언가 변화가 있는가? 정상적인 것이다. 아래 과정을 계속 따라와보자.

    neutron net-create external_network --provider:network_type flat --provider:physical_network extnet  --router:external

    위 명령어는 OpenStack에서 네트워크를 관리하는 neutron에 external_network라는 외부로 연결할 flat(우리가 일상적으로 생각하는 가장 기본적인 네트워크 형태) 네트워크를 생성하라는 지시를 내린다.

    neutron subnet-create --name public_subnet --enable_dhcp=False --allocation-pool=start=192.168.2.2,end=192.168.2.254 \
                        --gateway=192.168.2.1 external_network 192.168.2.1/24

    명령어를 보고 대충 감이 왔겠지만, public_subnet이라는 external_network과 연결될 네트워크를 생성해 IP 범위를 지정해 주는 것이다. external_network와 연결될 것이니 당연히 네트워크 인터페이스가 접근할 수 있는 IP 범위를 지정해줘야 한다. 당연히 IP가 수시로 바뀔 수 있는 dhcp는 비활성화. 이 네트워크의 IP 범위는 192.168.2,2에서부터 192.168.2.254까지다. 서브넷 마스크는 /24.

    neutron router-create router1

neutron router-gateway-set router1 external_network

    가상의 router1이라는 라우터를 만들어서 아까 생성한 external_network와 연결시켰다. 이 작업을 하면서 external_network라는 네트워크와 연결되는 랜선을 router1이라는 유선공유기의 WAN 포트에 꼽았다라는 상상을 하면 더 직관적으로 이해될 것이다. WAN 포트에 선을 꼽았다면 이제 LAN 포트에도 꼽을 것이 필요하다. 일반적인 공유기에서 WAN에 인터넷 선을 꼽고, LAN에는 그 인터넷을 분배받을 장비 (컴퓨터)를 연결한다. 이것도 같은 개념이다. 다만 공유기에서는 LAN의 IP 범위를 기기 자체에서 지정해주지만, 이건 그런 기능이 없는 단순 라우터다. LAN의 IP 범위부터 연결까지 직접 해보도록 하자.

    neutron net-create private_network

neutron subnet-create --name private_subnet private_network 192.168.3.0/24

    private_network라는 LAN 네트워크를 만들어서 192.168.3.1 ~ 192.168.3.254까지의 IP 범위를 지정해줬다. 네트워크를 만들었으니 선을 꼽는 과정만 남았다.

    neutron router-interface-add router1 private_subnet

    자, 선도 제대로 꼽았다. 소프트웨어로 정의되는 네트워크의 가장 좋은 점은 선을 밟고 넘어지거나 헐렁하게 꼽혀 스트레스 상승에 기여하지 않는다는 점이다. 이걸로 기본적인 네트워크 설정까지 모두 끝났다.

    브라우저에서 컨트롤러의 IP를 입력하고 접속해보자. 정상적으로 OpenStack 대시보드 (Horizon)이 반겨주고 로그인까지 문제가 없다면, 정상적으로 설치가 완료된 것이다. 기쁨을 만끽하며 이것저것 만져보자. 인스턴스를 생성해보고, 여러가지 마음이 가는대로 쑤셔보고 다녀도 좋다.

    새로운 유저 (Project) 만들기

    이제 유저를 하나 만들어보자. 계속 admin 계정으로만 가지고 놀 수도 없는 노릇이니까.

    openstack project create --enable internal

openstack user create --project internal --password foo --email bar@corp.com --enable internal

    아무래도 Private 클라우드 목적으로 디자인된 OpenStack에서는 그 목적에 충실하게 project라는 단위를 사용한다. 겁먹지 말고 일단은 유저명이라고 생각하자. 우리는 internal이라는 project에 foo라는 비밀번호와 bar@corp.com이라는 더미 이메일 주소를 주고 생성과 동시에 활성화시켰다.

    export OS_USERNAME=internal

export OS_TENANT_NAME=internal

export OS_PASSWORD=foo

    위 명령어를 치면 터미널에서 우리가 방금 생성한 internal 유저로 로그인한 것과 같아진다. 이 상태로 원래는 위와 같이 internal만의 새로운 라우터나 네트워크를 생성하고 연결시킬 수 있어야 하는데, keystone v3부터 어딘가 변경점이 있는지 유저 입장에서 새로운 네트워크 생성이 안된다. 이 부분은 최대한 빨리 확인해서 포스트를 갱신해 두겠다. 터미널 권한을 다시 admin으로 바꿀려면 위 export명령어의 값들을 admin의 그것으로 바꿔 입력해주면 된다.

  • GitHub 페이지를 오픈한 이유

    Feb 28, 2017 •

    평소 불특정 다수가 볼 수 있는 무언가를 만드는 것은 가끔 나에게 껄끄럽게 받아들여지기도 한다. 인터넷 프라이버시의 경우도 마찬가지다. 종종 필자는 클로즈드 소스 OS에 제조사가 유지/보수 목적으로 심어뒀을 지 모르는 백도어에 대해서도 걱정한다. 정작 다루는 데이터는 별 볼일 없는데 말이다.

    그런 버릇 때문에 지금까지 내가 진행해온 모든 일들에 대한 정리가 없다. 파편적인 기록들과 머릿속의 기억만 남아있을 뿐이다. 별 문제 없나 생각할수도 있지만, 시간이 지나면서 내가 이전에 무엇을 했는지 기억이 잘 나지 않을 때도 있다. 분명히 내가 거쳐온 일인데 입 밖으로 설명을 꺼낼 수가 없어진다. 이 페이지는 지금부터라도 그런 일을 방지하기 위해 만들어졌다. 내가 공부하고, 구상하고, 구축하고, 또 운영할 대부분의 것들이 여기에 기록될 것이다. 물론 나만의 개인 공간에 페이지를 만들 수도 있겠지만, 내가 정리한 내용이 겸사겸사 다른 사람들에게 도움이 될 수 있고 또 구직 등의 이벤트에서 일종의 포토폴리오로도 사용이 가능하기에 GitHub 페이지를 선택했다. 먹고는 살아야지 않겠나.

    아직 어디서부터 페이지에 내용을 채워넣어야 할지도 잘 모르겠고 마크다운 문법도 영 익숙하지 않지만, 어떻게든 될것 같다. 아마…?