이 포스팅은 H3 Developers Conference 2011 후기 #1에서 이어진 포스팅입니다.



개발자를 위한 고급 Git 활용전략 - 김상영
Git명령의 대부분은 File보다는 Commit 객체를 다룬다는 점을 알아야 하고 Git의 명령어를 이해하기 위해서는 HEAD와 브랜치가 단순한 포인터라는 것을 기억해야 합니다.


이 발표는 말로 정리하기는 어려운 부분이 있어서 Aj가 올려주신 발표자료를 첨부했으니 이 내용을 보시는게 이해하기가 훨씬 쉬울 것입니다. 처음 설명은 HEAD와 브랜치에 대한 설명이었습니다. Git의 커밋객체들이 자신의 부모 커밋들을 참고해서 링크드리스트처럼 연결되고 HEAD는 이에 대한 포인터로의 역할만 합니다. Branch도 마찬가지로 다른 커밋객체를 가리키는 새로운 포인터일 뿐입니다. 이를 자바스크립트의 객체에 비유해서 설명했는데 명확하게 이해하기가 쉬운 비교였습니다. 다만 자바스크립트로 비유할 때 커밋객체의 parent대신에 prev로 설명했는데 혹 git을 잘 모르는 사람은 prev라는 속성이 있는 것으로 오해할까 싶기도 했습니다.(머 그걸 오해한다고 큰 문제가 생기는 것은 아닙니다. ㅎ)

뒷부분은 Git저장소의 해부에 대한 내용입니다. git저장소를 만들면 .git폴더안에 많은 파일들이 생기고 git로 작업할 때마다 이 폴더안에 새로운 파일들이 생기게 되는데 이 구조에 대한 설명이었습니다. 커밋객체는 커밋할 때 생기지 않고 git add할 때 생기는데(git add할때 생기는건 블랍객체이고 커밋객체는 커밋할때 생깁니다.)  .git/objects안에 생기고 블랍파일입니다. git blob format는 헤더를 포함해서 zlib으로 압축을 합니다. git hash-object 명령어를 사용하면 파일에 대한 해쉬명을 알아낼 수 있고 해시화된 파일은 git cat-file로 그 내용을 알 수 있습니다.

왜 해쉬를 사용했는가 하면 중복이 나올 확률이 무척 적으며 육안으로 구별하기 어려운 간단한 차이도 해시에서는 쉽게 구별할 수 있습니다. 그래서 Git에는 4개의 객체가 있는데 모두 파일로 존재합니다.

• Blob : .git/objects안에 존재합니다.
• Tree : 폴더처럼 트리안에 트리가 존재하고 그안에 Blob가 존재할 수 있고 .git/objects안에 있습니다.
• Commit : 리스트입니다. 이전 커밋을 참조하는 Parent, tree, author, date등의 속성을 가지고 있고 .git/objects안에 있습니다.
• Tag : 커밋객체에 대한 포인터로 .git/refs/tags아래 있습니다.

Git에는 Working Area, Staging, Repo 3가지 스페이스가 있습니다. 각 명령어를 실행할 때마다 이 스페이스 사이에 리스트가 만들어지는 것이고 이 리스트를 통해서 비교가 됩니다. 그리고 리셋옵션은 리셋할 스페이스를 지정하는 것입니다. --soft는 Repo까지 --mixed는 Staging까지 --hard는 Working까지 리셋한다는 의미입니다.





UX에 대한 7가지 오해와 진실 - 김수영
이 세션을 저로써는 잘못 선택한 세션이었습니다. 저는 사실 UX자체에 대한 내용으로 생각하고 들어갔지만 실제로는 UX에 대한 얘기가 아니라 UX팀과 UX팀의 업무에 대한 얘기였습니다. 그래서인지 오후가 되어서인지 좀 집중하지 못하고 들었습니다.


많은 얘기가 있었지만 간단히 요약하면 위 사지의 7가지가 오해이고 아래 사진의 7가지가 그 진실입니다. 내용이 요약으로 하기는 좀 어려워서 사진으로 대체합니다. ㅡㅡ;;





파이썬으로 클라우드 하고 싶어요 - 하용호
이 세션의 주제는 파이썬으로 분산처리도 해보고 병렬처리도 해보고 클라우드도 써보자였습니다. 지금은 시대가 빅데이터와 분산처리를 필요로 하고 있습니다. 가장 간단한 것은 한 컴퓨터내의 멀티코어를 잘 사용하는 것이고 그 다음은 여러 머신을 사용하고 그 다음은 클라우드를 사용하는 것입니다. 하지만 분산프로그래밍은 어려운데 배우기도 어렵고 쓰기도 어렵고 실행하기도 어렵습니다. 이렇게 어려운 이유는 작성하는 것이 어렵고 라인수도 무척 길어집니다. 그리고 네트워크나 디스크가 병목점이 될 때가 많고 의외로 반복사용하기도 어렵습니다.

여기에 대한 해답이 파이썬이고 파이썬을 사용하면 생각의 속도로 코딩을 할 수 있습니다. 국내에서는 인기가 높지 않지만 파이썬도 쉽고 쉽게 쓸 수 있는 라이브러리도 많이 존재하고 파이썬이 느리기는 하지만 어차피 네트워크나 디스크로 인한 병목점이 많이 발생하기 때문에 파이썬의 속도는 크게 문제가 되지 않습니다.

멀티코어를 잘 사용하려면 쓰레드를 여러개 사용해야 합니다. 간단한 덧셈프로그램을 하나의 쓰래드로 했더니 3.5초가 걸렸는데 쓰레드를 2개로 늘렸더니 오히려 4.2초가 걸렸습니다. 파이썬도 파이썬 버츄얼머신상에서 동작하는데 이는 GIL(Global Interpreter Lock)때문에 발생하는 문제입니다. 보통 시스템이 락이 걸때 Coarse-grained락이라는 큰 락을 거는데 성능이 좋지 않고 작업당 락은 거는 Fine-Grained락은 작은 락이라 성능은 좋지만 만들기가 쉽지 않습니다. 파이썬은 전체를 락으로 거는 단 하나의 락을 사용합니다. 그래서 쓰레드를 여러개 사용하더라도 락이 하나이기 때문에 하나의 CPU가 일을 하면 다른 CPU는 놀고 있습니다.

GIL을 사용하면 인터프리터 구현이 쉽고 GC만들기도 좋습니다. 파이썬이 GIL을 도입했을 때는 1990년대였기 때문에 싱글CPU였지만 지금은 멀티코어가 일반화되었기 때문에 이부분이 오히려 장벽이 되었습니다. 그래서 쓰레드로 할 수 없으면 프로세스로 할 수 있습니다. GIL은 프로세스에서만 유효하기 때문에 CPU별로 프로세스를 구분해 주어 작성하면 앞의 덧셈프로그램을 프로세스 2개로 1.88초만에 계산할 수 있습니다. 사실 이건 꼼수가 아니라 분산프로그래밍에서는 오히려 정답입니다. 쓰레드라는 것은 하나의 PC내에 존재하는 것이지만 분산은 여러 머신에 걸처서 해야 하는 것입니다. 파이썬에는 Parallel Python이라는 라이브러가 존재하는데 여러 프로세스에 분산해 주는 역할을 합니다. 사용하기도 쉽고 잘 동작하는데 싱글머신의 멀티코어에도 사용할 수 있고 워커머신 자동찾기 기능도 있습니다.

이제 클라우드를 사용해 보겠습니다. 맵리듀스는 2004년 OSDI의 구글 발표에서 이야기 나온 것입니다. 맵리듀스는 사실 어려운게 아닌데 누구나 많은 양의 작업을 해야한다면 생각해 낼 만한 작업입니다. 예를 들어 책에 나오는 단어의 갯수를 세어보는 작업을 해야한다면 여러명에게 일을 나눠주고(map) 나눠준 결과를 다시 모으는 것도 힘들기 때문에 일정단위로 분단장을 뽑아서 종류별로 모으도록(reduce)하는 것입니다. 맵리듀스가 인기있는 이유는 하둡때문입니다.

하둡이 등장하기 이전의 분산처리는 어떻게 분배해야 하는지 프로그램을 어떻게 원격에 전송하고 나눈 작업을 어떻게 스케쥴링해야하는지에 대해서 고민해야 했지만 하둡의 등장으로 어떻게 Map을 작성하고 Reduce를 작성하는지만 고민하면 나머지는 하둡이 다 알아서 해줍니다. 그래서 슈퍼개발자가 아니러도 분산처리를 할 수 있게 되었고 분산이 유행하게 되었습니다. 하둡은 자바로 만들어졌지만 HadoopStreaming을 이요하면 어떤 언어에서도 사용할 수 있습니다. HadoopStreaming에 관심을 가진 업체는 Yelp인데 이 회사는 사장부터 파이썬 매니아라서 mrJob이라는 라이브러리를 만들었습니다. mrJob을 사용하면 하둡없이도 로컬에서 테스트할 수 있고 runner부분만 바꾸어 주면 하둡에서 동작하게 할 수 있습니다.

분산프로그래밍을 하려면 많은 머신이 필요한데 회사에 머싱이 많지 않다면 아마존의 ElasticMapReduce가 좋은 대안이 될 수 있습니다. 아마존이 OS와 하둡을 설치해 놓아서 비용만 지불하면 이용할 수 있습니다. 가격도 저렴해서 라지인스턴스 기준으로 7.5G 메모리에 4CPU 100대를 한시간 써도 6불만 지물하면 된다. ElasticMapReduce도 mrJob에서 지원하고 있어서 runner만 emr로 바꾸면 자동으로 ElasticMapReduce에서 실행한뒤에 결과를 S3로 전송해 줍니다.




Epilogue
개인적으로 너무나 흡족한 컨퍼런스였습니다. 처음하는 세미나라고 믿기 어려울 만큼 컨퍼런스가 좋아서 상당한 기간동안 열심히 준비했다는 것을 느낄 수 있었습니다.


H3에서 가장 인상깊었던 것은 바로 이 책입니다. 이 책은 (모든 세션은 아니지만) 발표자들이 세션의 내용을 글로 적은 내용을 책으로 묶은 것입니다. 단순히 발표자료를 프린트해서 한 것이 아닌 글을 자세히 새로 적었습니다. 이는 제가 생각하는 발표라는 방향과도 부합하는데 사실 발표자료는 발표를 돕는 역할이기 때문에 발표없이 발표자료만 보면 이해하기가 어려운게 사실이고 그냥도 볼 수 있는 발표자료를 만들려면 원래 의도에 제대로 맞출수 없습니다. 발표는 발표로 하고 자세한 내용을 읽어볼 수 있도록 이렇게 제공했다는 점에서 이번 컨퍼런스를 얼마나 열심히 준비했는지 알수 있습니다.

저는 컨퍼런스나 세미나는 한두가지 인사이트나 괜찮은 세션정도면 만족하는 편인데 H3에서는 대부분의 세션에 만족감을 느낄정도로 퀄리티가 좋았습니다. 이는 대부분 보안이라고 감추는 사내에서 직접 업무를 하면서 고민했던 부분과 개발한 부분을 그대로 공개했기 때문에 세션들이 무척 실용적이면서도 내용이 탄탄했습니다.

그리고 많은 사람들이 트위터에 H3의 만족감에 대한 트윗을 올라서 30일 타임라인에서 최대의 이슈였던것 같습니다. 그런 글 중에 많은 글에서 xguru님으로 인해 달라진 KTH에 대한 얘기가 많이 있었는데 제 생각은 약간 다릅니다. xguru님이 KTH에 오신 이후로 대외적으로 많이 알려진 것은 사실이지만 이번 컨퍼런스를 통해서 KTH가 겉으로 드러나는 부분만이 아닌 다양한 부분에서 오랫동안 탄탄히 준비한 것이 느껴졌습니다. 그리고 이 뒤에는 KTH 부사장인 박태웅님이 있다고 생각하고 있습니다. 지금 이 수많은 개발자들을 끌어들이며 KTH가 순신간에 영향력을 가지게 된 것은 박태웅님이 그 주역이라고 생각하고 사실 xguru님을 끌어들인것도 부사장님인걸로 알고 있습니다.

꽤전에 KTH에서 전사원들에게 엄청나게 열심히 기술을 전파하는 부사장님 얘기를 들은적이 있었지만 사실 그다지 신경쓰진 않았습니다. 실제로 어떤지는 제가 알 수 없었고 대부분의 윗분들은 기술을 잘 모르는데다가 사실 이해하려는 마음도 그다지 없이 주변에서 주위들은 기술지식만으로 섣부르게 몰아쳐서 피곤해지는 경우가 훨씬 많았기 때문입니다. 그러면서 트위터를 통해서 많은 얘기나 요즘은 직원분들과 얘기하는 것을 많이 보았는데 제가 아는 범위에서는 거의 유일할 정도로 비기술자이면서 기술에 대한 제대로된 관점을 가진 임원입니다. 기술자가 아님에도 기술자와 비슷한 관점을 가지고 있고 이제는 그 기술에 대한 판단을 제대로 해줄 능력있는 개발자들까지 갖추어진 상태입니다.(나중에 혹시 이력서를 쓸지도 모를 상황을 위해서 아부하려는 것은 아닙니다. ㅡㅡ;;)

암튼 H3컨퍼런스내내 상당히 즐거웠습니다. 최근 KTH가 유명한 개발자들을 많이 데려가면서 저는 이러한 최근행보를 아주 좋게 보고 있고 꼭 성공(?)하길 바라고 있습니다. 그래야 그런 분위기가 다른 곳으로도 퍼질 수 있을테니까요. 사실 과거에는 KTH는 IT에서 그다지 안중에도 없는 회사였지만 최근에는 NHN, Daum과 어깨를 견줄 수준까지 올라온듯 합니다. 컨퍼런스 얘기는 안하고 회사얘기만 한참 했네요. ㅎㅎ 오랜만에 좋은 컨퍼런스를 갔다왔더니 기분이 좋군요.