머가필요해

     - 위와 같이 설정을 했다면 이제 실행하자.





3, execute

     - 이제 분산 빌드가 필요한 어떤 소스코드를 빌드를 해보자.


     - 이렇게 하면 끝이다.
     - 그냥 자기가 알아서 적당히 분산해서 빌드해주고 결과를 만들어준다.

     - make j 옵션의 숫자를 좀 크게 적어주면 된다.
     - 여기에서는 로컬 PC의 core 갯수가 기준이 아니다. 분산으로 쪼개서 빌드를 수행할 기준이다.

     - 지금 어떻게 빌드가 되고 있는지 보고 싶다면...


     - 텍스트로 보는 것 보다는 예쁜 화면으로 보는 것이 보기 좋다.

     - 어떻게 분산되어서 빌드가 되는지를 막대기로 보여주는데...
     - 빨간색으로 표시된 부분은 분산을 해서 빌드를 하려고 했는데,
       에러가 나서 그냥 로컬에서 다시 빌드를 수행한다는 의미이다.
     - 즉, 분산 시도가 에러가 나면 그냥 로컬에서 빌드룰 수행함으로써 결과물에는 지장이 없도록 해준다.



4. error

     - 사정이 여의치 않아서 발생하는 error 들에 대해서 집중적으로 파고들지는 못했다.

     - 우선, 빌드가 수행되다 보면, 아래와 같은 메시지가 나온다.


     - [ .distcc ] 파일을 생성해야하는데, 권한 문제가 발생해서 제대로 하지 못했다는 것인데...
     - distcc는 자신의 실행 권한을 위해서 [ distccd ]라는 계정을 만들어서 활용한다.

     - 계정도 빌드 실행 계정과 distcc 계정 간의 관계도 있고 뭐 복잡하고 하니 그냥 막 권한을 풀어주면 될 것 같은데,
     - 권한 문제를 풀어줘도 다른 문제가 발생하는 등 여러 이슈가 있다.

     - [ zeroconf ] 문제도 이어서 발생하는데, 이걸 사용하지 않는다라고 환경 설정을 해도 여전히 발생하곤 한다.

     - 이게 ubuntu에 포함된 패키지의 버그인지 검증해보기 위해서 소스 설치해서 진행해보고....해야하는데...
     - 귀차니즘이.... 그냥 막....

     - 위에 명시한 에러가 발생을 해도 분산 빌드가 잘 실행이 된다.

     - 나중에 직접 분산빌드를 수행할 일이 생기면, 이 부분에 대해서 추가로 검증을 해보기로 하고...
     - 지금 이번에는 그냥 무시~~~!!!




5. 잡소리

     - 회사에서 빌드가 약 500~600분 정도 소요되는 것이 있어서 빌드시간을 단축하고자 distcc를 적용해보았다.
     - 그랬더니 약 40% 이상의 시간을 단축할 수 있었다!!!! 와우~!!!
     - 그 외에도 몇 건의 빌드에 적용 검증을 해보았는데, 40~60% 정도의 이득을 볼 수 있었다.

     - ccache의 경우에는 탁월한 빌드 시간 단축이 가능하지만,
     - 최초 빌드 시에는 1~2% 정도의 시간이 오히려 증가한다라는 단점이 있다.

     - 그래서, 자료들을 찾아보면 ccache와 distcc를 동시에 적용해서 사용하는 것을 추천하곤 한다.


     - QT Library 빌드도 필요해서 distcc를 적용해보았는데, 많은 문제가 있어서 결국 제외를 했다.
     - QMake 라는 것을 사용하기 때문에 발생하는 문제로 보이기는 하지만.... 심도있는 분석은 다음 기회에...
     - QT의 경우에는 distcc의 pump mode라는 것을 적용하면 쓸만하다는 이야기가 있지만... 잘 안되었다.



     - distcc가 최근 집중하는 것은 pump mode인 것 같다.
     - 하지만, 개인적으로 아직은 안정적이지는 않은 것으로 보인다.
     - pump 관련하여서는 추가적으로 검증 작업을 진행 후에 적용할 계획이다.

     - 기본 mode에 비해서 엄청 많이 빠르다고 하는데.... 꼭 검증해봐서 적용할 수 있으면 좋겠다.

Full 3D로 제작된 SF 애니메이션이라 하여, 스크린샷에 혹~해서 봐버린 작품

좀 올드한 느낌은 있지만, 그래도 Full 3D로 그려진 것은 맞아보였다.

알고봤더니 이 애니메이션이 유명한 이유는 Full 3D라기보다는
"아와즈 준 (Jun Awazu)"이라는 사람이 혼자서 작업을 했다고 해서였다.

'아와즈 준'은
2005년도에 "혹성대괴수 네가돈"이라는 애니메이션을
1인 체제로 만들어서 도쿄 국제 판타스틱 영화제에 사영을 했는데
뜨거운 반응이었다고 한다.

1인 체제로 만들었다고 하여 정말 혼자서 북치고 장구치고
CG 영상까지도 전부 혼자한 것으로 알고있었는데,
그래서 정말 이 사람 괴물이구나!!!했는데,
CG 영상은 별도의 공방에서 제작했단다.


플란젯 역시 1인 체계로 제작된 애니메이션이라고 한다.
정말 완벽히 혼자 만든 것은 아니지만,
원작, 각본, 감독 전부 '아와즈 준'이 담당하였다.

정말 대단한 것은 맞지만 이로 인하여
작품의 질이 떨어진 것이 용서받지는 못한다!!!


이 작품의 CG는 나쁘지 않다. 아니, 좋다.
메카 디자인도 좋다.
그런데, 분위기가 왠지 게임 동영상과 같은 느낌이다.
그리고 어둡다. 왠지 칙칙한 느낌도 난다.

정말 큰 문제는 스토리다.
이건 왠지 CG 전공 학생들이 졸업작품을 만든 것 같다.

그래픽 질은 높은데, 사람들이 많이 나오지 않는다.
제한된 사람만 나오는 것.... 많은 사람들을 그리기 힘들어서?!

스토리상 제한된 인원만 나오도 된다면 모르겠는데,
아무런 이유없이 제한된 인원만 등장하고 있다.

얼마 나오지 않는 등장인물들의 개성은?!
없다!
말도 안되는 성격...지나치게 전형적인 캐릭터 수준이다.
그리고 현실성 없는 행동만 보이고 있다.

그렇다고 해서 스토리 라인이 좋은가?!
정말 그냥 말 그대로 CG 전공자의 졸업작품 수준이다.

설정은 독특한가?!
전혀 아니다!!!
그냥 처들어와서 지구 망하게 하려다가
주인공이 우연히 얻게 되는
절대 막강 로봇때문에
외계인 뻥~!!!

그리고 끝~




킬링타임용으로 쓸만한가 ?
사실 별로 추천하고 싶지 않다.

정말 볼 것 없는 상황에서,
SF 애니메이션을 보고 싶으면
고르다 고르다 정 없을 때에...
그 때에나 한 번 봐보시길...



IMDb   평점 : 5.10
네이버 평점 : 4.56
나만의 평점 : 4.45


Naver
http://movie.naver.com/movie/bi/mi/basic.nhn?code=76764
Wikipedia
http://en.wikipedia.org/wiki/Planzet
IMDb - Internet Movie Database
http://www.imdb.com/title/tt1645129/

[출처]
* 포스터 및 스크린샷은 (http://myanimelist.net/anime/8297/Planzet/pic&pid=26563),
위키피디아에서 퍼왔음을 밝힙니다.
(영화 관련 저작권 괴담은 무서워요~)
[ 주의 사항 ]
어디까지나 개인적인 영화평을 적는 공간이니만큼,
개인의 취향은 존중해주시면 감사하겠습니다.
건전한 비판이나 조언은 언제든 환영입니다!!!

Git의 발음

   - 기트
   - 깃
   - 지트
   - 짓


이와 관련된 공식입장이 있는데,
현재 사이트 접속이 안되어 확인이 안된다(예전에 봤는데 기억이 가물가물).
   - http://git.wiki.kernel.org/index.php/GitFaq#Why_the_.27git.27_name.3F
그런데, 위 위키 페이지는 사라졌다. 이런...


보통 일반적으로 "깃"이라고 발음하고 있다.
나도 그렇게 발음하고 있고,
현업에서 근무하고 있는 주위의 다른 사람들도 그렇게 발음하고 있다.
KLDP에서도 그렇게 의견이 수렴되었다.


최근에 결정적인 증거(?)도 찾았다!!
리누즈 토발즈 아저씨도 깃으로 발음을 하고 있다.

   - http://www.youtube.com/watch?v=4XpnKHJAok8


결론! "깃"이라고 발음하면 된다.

[ 참고 ]
http://kldp.org/node/113721

Git에 대해서 소개하는 글 중에서 가장 와닿는 내용이 있다.

'Linux Kernel'의 형상관리를 위해서 사용하는 도구이며
'리누스 투르발스(Linus Benedict Torvalds)'가 직접 만들고 있는 도구


그런데, 여기에서 궁금증이 생겼다.

Git의 역사가 Kernel에 비해서 훨씬 짧은데,
그 이전에는 뭘 사용했었지!?

CVS?! Subversion?!


그래서 알아봤는데,
다른 도구들과는 달리 이에 대해서
공식적인 입장은 물론이고
다양한 이야기를 확인할 수 있었다.


1999년도에 Linux Power PC에서 사용하기 시작한 'BitKeeper'는
리누스가 "Best Tool For The Job"라며
2002년도부터 Kernel의 mainline에 적용하였다.

2002년도 이후 Kernel 개발 속도가
엄청 증가한 배경에
BitKeeper가 기여했다는 점은
아무도 반론할 수 없을 것이다.

BitKeeper는 상용 제품이다.
다만, Linux Kernel을 위해서(도움도 받았으니)
Free 버전을 계속 개발 해주고 있었다.

하지만, 오픈소스 진영의 대표주자격인 Kernel에서
상용 제품을 사용하는 것에 대한 비판이 많았던 것 같다.

하지만, 분산 개발을 제대로 지원하는
Linux Kernel 개발에 적합한 다른 대안 도구가
없었기에 그대로 사용할 수 밖에 없었다.

그러던 중, BitKeeper에 대한 Reverse-Engineer 시도가 있었고
경고를 했음에도 두 번 더 발각(?) 되면서
BitKeeper의 무료 버전 개발이 중단 되게 된다.

이 부분에 대해서 많은 이야기가 오가는데...
결론적으로

BitKeeper의 입장에서는
매년 $50,000 정도씩을 투자해서
Free로 제공해주고 있는데
그런 우리의 제품을 reverse engineer를 해서
기술을 빼가다니 너네 괘씸해!
이제 안줘!!!

오픈소스 커뮤니티 입장에서는
Free로 풀린거면 자유롭게 쓸 수 있는거지
왜 시비야~!!

하지만, BitKeeper 입장에서는
돈 안받고 쓸 수 있게 해준거지,
너네 맘대로 손대라고 한 것이 아니야~!!!

뭐 이렇게 정리가 되는 것 같다.



이렇게 되어 BitKeeper가 아닌
대안을 찾아야 하는 상황이 되었는데..

마땅한 대안이 없자,
직접 만들어 버리게 된다.

그것이 바로 Git 이다!!!



그것도 '리누스'아저씨가 주도하여
개발을 하다니...



그 유명한 '리누스' 아저씨가 개발을 하고,
운영체제의 양대 산맥 중 하나인
리눅스 커널을 개발하는데 사용중인 도구이며,

최근 모바일의 가장 뜨거운 핫이슈인
구글의 안드로이드도 사용하는 도구!!!

바로,
"GIt"
이다.


[ 참고 ]
http://en.wikipedia.org/wiki/Git_(software)
http://kerneltrap.org/node/4966
http://www.pcworld.idg.com.au/article/129776/after_controversy_torvalds_begins_work_git_/

'Git'이라는 '버전 관리 도구'를 언급하면 바로 따라오는 말이 있다.

다른 것들은 다음에 기회가 있으면 이야기하도록 하고,
여기에서는 '분산 버전 관리 시스템'에 대해서만 이야기를 해보고자 한다.



소프트웨어 형상관리의 흐름을 살펴보면,

로컬에서 파일시스템 기반으로 형상관리를 하다가,
네트워크 기반의 중앙집중식으로 관리를 하고,
최근에는 분산형 관리가 유행이다.



도구로 따지면,
'버전 관리 도구'의 고전작품인 'CVS'
'버전 관리 도구'의 대중화를 이끈 'Subversion'

이들과 'Git'이 차별점을 보여주는 부분이 바로 '분산 (Distribute)'이다.





컴퓨터 세상은 우리가 살아가는 사람들의 세상과 밀접하다.

C++을 통해서 우리에게 알려진 객체지향(Object-Oriented)이라는 것도
컴퓨터 언어에만 있는 것이 아니라
세상을 바라보는 관점에 대한 철학의 산물인 것처럼

분산 처리라는 것도 신경망 모델 중 하나로 개념화되어
일반적으로 부하가 걸리는 것을 해결하기 위한 방안으로
나누어 처리하는 것을 의미하는 아주 대중화된 방법이다.

말단 처리 장치의 능력이 좋아지고
네트워크가 잘 이루어진 상황에서는
당연한 수순으로 집중처리에서 분산처리로 변화하게 되는 것이다.





'CVS'와 'Subversion'과 같은 기존의 '중앙 집중식 버전 관리 도구'는
'서버-클라이언트 (Server-Client)' 구조를 따른다.

'서버'를 구축해 놓고 사용자는 '클라이언트'로 붙어서 작업을 하는 방식이다.

이러한 구조에서 발생하는 문제 중에서 가장 큰 것은
'서버'가 없으면 '클라이언트'는 작업을 할 수 없다는 점이다.

다른 문제로는 '중앙 집중식 버전 관리 도구'의 장점이자 단점인데,
시스템을 구성하는데 단순하고 쉽게 할 수 있는 반면에
다양한 '워크 플로우(Work Flow)'를 구현하는데에 한계가 있을 수 밖에 없다.

실제 현업에서 이러한 '중앙 집중식 버전 관리 시스템'을 사용할 때
피부에 와닿는 문제는 협업을 할 때에 있었다.
특히 해외 연구소들... 더욱 더 특히 인도와 같이 느린 네트웍...




'중앙 집중식 버전 관리 시스템'의 경우를 예를 들어보자,
서버를 구축하는 것도 쉽고 시스템을 구성하는 것도 쉽고
한 곳에 모여서 열심히 작업을 할 때에는 아무런 문제도 없다.

그러던 중 해외의 연구소와 협업을 하게 되면서 문제가 발생한다.

그냥 기존과 같이 새로 계정 발급해주고 국내 서버에 붙어서
협업을 하게 하는데 해외쪽의 네트웍 속도가 느려서
제대로 check-out/in이 되지 않는 경우가 발생하는 것이다.

즉, 소스를 다운 받는데 네트웍이 느리다보니 종종 실패를 하게 되고,
더 큰 문제는 작업한 내용을 서버로 올릴 때 실패를 하는 경우이다.

실패를 하는 것은 그나마 나은 경우이고,
에러가 없었는데 파일 일부를 누락하게 되면 정말 괴롭게 된다.

이 모든 원인은 느린 네트웍 속도.

특히 관리하는 소스 코드의 용량이 클 경우에는
추가적인 더더욱 심각한 문제가 발생하게 된다.


이를 극복하기 위한 흔한 방법은
'프록시 서버(Proxy Server)'를 원격지 가까운 곳에 두는 것이다.

그리고는 메인 서버와 '동기화(Synchronization)'를 하도록 하면 된다.

보통은 이와 같은 방법으로 이와 같은 상황을 해결하지만,
동기화 과정에서 많은 문제가 발생하는 것을 완전히 피할 수는 없다.



이러한 것을 극복하기 위한 것이 바로
"분산 버전 관리"이다!

서버에서 check-out을 하게 되면
서버와 똑같은 내용을 전부 클라이언트가 갖게 된다.
즉, 클라이언트가 서버가 될 수 있는 것이다.

'로컬(local)'에 서버 복사본을 구축해버리면,
서버와 연결되지 않아도 혼자서 commit을 할 수 있다.

필요할 때에 필요한 내용만 서버로 보낼 수가 있다.

'프록시 서버'와 유사하면서도 또 다른 구성이다.

"Git"과 같은 "분산 버전 관리 도구"에서
기본적으로 손쉽게 '복사본(clone)'을 구축할 수 있게 함으로써
정말 다양한 '워크 플로우'를 구축할 수 있게 되었다.

정말 유연한 시스템을 구축할 수 있도록 도와주는 것인데,
이러한 유연성이 부담스러울 경우에는
기존 방식과 같은 타이트한 워크 플로우를 구성할 수도 있다.

비록 "Git"이 지향하는 '분산 버전 관리'의 모습은
'병렬 분산 처리 (Parallel Distributed Processing, PDP)'이지만,
사용자가 원하는 워크 플로우를 구성할 수 있다는 점이 중요하다.




'Git'의 명령어들을 공부하는 것도 중요하지만,
더욱 중요한 것은 'Git'을 이용하여 어떻게 작업을 할 것인지에 대해서이다.

'C언어'를 공부하는 것과 마찬가지인 것이다.
문법을 모두 공부했다고 해서 끝나는 것이 아니고
어떻게 프로그램을 만들 것인지에 대해서 공부해야하는 것처럼 말이다.


실제로 'Git'으로 이를 어떻게 사용할 수 있는지는
앞으로 차차 살펴보도록 하자.



[ 참조 ]
리누스 투르발스 - http://ko.wikipedia.org/wiki/%EB%A6%AC%EB%88%84%EC%8A%A4_%ED%86%A0%EB%B0%9C%EC%A6%88
분산 버전 관리 - http://ko.wikipedia.org/wiki/%EB%B6%84%EC%82%B0_%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC_%EC%8B%9C%EC%8A%A4%ED%85%9C
인지과학 - http://terms.naver.com/entry.nhn?docId=8403
분산 버전 제어 시스템 소개 - http://www.ibm.com/developerworks/kr/library/au-dist_ver_control/
Reversion Control System - http://en.wikipedia.org/wiki/Revision_control_software

[ 한글 ]
형상 관리 (소프트웨어 형상 관리)
버전 관리 (소프트웨어 버전 관리)
소스 관리 (소스 코드 관리)


[ 영어 ]
Version Control
Revision Control
Source Control
Source Code Management (SCM)
Software Version Management
Software Configuration Management (SCM)




Subversion, Git, ClearCase 등과 같은 도구를 통해서 (또는 도구가 없더라도)
소스 코드, 문서, 결과물 등을 번호(버전)를 사용하여
관리하는 것을 무엇이라고 지칭해야 할까?



소프트웨어 공학(Software Engineering)이라는 학문은
개인적으로 '공학계의 인문학'이라고 여겨진다.

바꿔말하면 무엇을 정의하는 것이 어려우며,
정답이 없는 경우가 대부분이라는 말이다.



최근 아이폰이나 안드로이드로 인하여
대중화 되어버린 "플랫폼(Platform)"이라는 것을 보아도
분야마다 사람마다 그 정의가 전부 다를 수밖에 없다.

시험 문제로 "플랫폼의 정의를 쓰시오"라고
나오면 정말 당황스러울 것 같다.



이번의 경우는 조금은 색다른 경우인데,
이것을 지칭하는 용어가 너무 많아서 문제가 된다.

같은 것을 지칭하면서
다들 다른 용어를 사용하고 있는 것이다.



일반적으로는
Subversion, Git 과 같은 것을 지칭할 때에는
"버전 관리 도구 (Version Control Tool)"
라고 한다.

그러한 버전 관리 도구를 사용하여 구축한 시스템은
"버전 관리 시스템 (Version Control System, VCS)"
이라고 부르곤 한다.



소프트웨어 공학을 공부하다 보면
상당 부분의 개념이 산업 공학 특히 생산 공학에
그 기반을 두고 있는 것을 알 수 있다.

그로 인하여, 버전 관리를 포괄하는 다른 용어가 나오는데
"형상 관리 (Configuration Management)"
가 그것이다.


그 중에서 소프트웨어 분야에 대해서는
"소프트웨어 형상 관리 (Software Configuration Management, SCM)"
라고 부르고 있다.



'소프트웨어 형상 관리'는
'버전 관리'를 포함하는 더 크게 포괄하는 의미다.

'소프트웨어 생명 주기 (Software Life Cycle)' 전반에 걸쳐서
개발 환경을 비롯한 전반적인 모든  형상물들에 대한
'변경 관리'를 위한 모든 활동을 의미한다.


형상 식별, 버전 제어, 변경 제어, 형상 감사, 형상 상태 보고 등
어려운 말로 소프트웨어 형상 관리에 대한 정의들이 있긴 하다.



어려운 이야기를 계속 하고자 하는 것은 아니다.

다만, '소프트웨어 형상 관리'라는 것이
곧 '소프트웨어 버전 관리'를 의미하는 것은 아니라는
말을 하고 싶은 것이다.

'소프트웨어 형상 관리'의 범주 안에
'소프트웨어 버전 관리'가 포함이 되어 있을 뿐이다.



문제는 이러한 것을 실무자들도 분명히 알고 있으면서도
아니, 최소한 어렴풋하게 알고 있으면서도
이 두 가지 용어를 그냥 동의어로 사용하고 있다.

또 사실 동의어로 사용해버린다고 하여
꼭 틀렸다고 할 수 없는 것도 사실이다.
( 우기면 뭐 그렇다고 할 수 밖에 없는 것이 현실! )


단순히 소스 코드에 대해서만 관리한다고 하면
"버전 관리"
소스 코드를 비롯하여 개발 환경, 빌드, 기타 등등까지라면
"형상 관리"
라고 지칭하기로 하자.


우리가 앞으로 계속 살펴볼 "Git"은
기본적으로 "버전 관리 도구"이다!


하지만, Git을 기반으로 하여 소프트웨어를 관리하는 시스템을 만든다면
그것은
"소프트웨어 형상 관리 시스템"
이라고 부르기로 하자.


[ 참고 ]
http://ko.wikipedia.org/wiki/%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC
http://ko.wikipedia.org/wiki/%ED%98%95%EC%83%81_%EA%B4%80%EB%A6%AC
정보통신단체 표준, TTA.IE-828, 소프트웨어 형상 관리 계획 표준