원리는 간단하게, 1분에 한번씩 다음 배치파일을 실행하는 것입니다. D:\ProjectHelper\CommitSound\check.cmd 라고 합시다. 이 것의 중심 원리는 svn 으로 project의 상태를 계속 모니터링 하다가 1분전과 달라지면, 백그라운드로 wav 파일을 연주하는 것에 있습니다. sndrec32 /embedding 이라는 옵션이 훌륭하게 수행해 주지요.
@echo off REM Use echo "SUBVERSION CHECK" svn info --username=XXXX --password=YYYY https://svn.repository.com/project/trunk > last.info.tmp fc last.info last.info.tmp 2> NUL >NUL if %errorlevel%. == 0. ( echo PASS del last.info.tmp ) else ( del last.info ren last.info.tmp last.info echo PLAY commit sndrec32 /embedding /play commit.wav )
이 파일을 linux의 cron 처럼 ms-windows에서 1분에 한 번씩 실행시키도록 하는 명령은 schtasks 명령입니다.
구성원이 일이 많아 피곤한 조직에서 나타나는 일차 징후는 프로세스를 굉장히 챙기는 것이다. 프로세스를 챙기는 일이 대기업 같은 곳에서 일어나는 것이 아닌 것 같다. 한 회사내에서도 프로세스를 굉장히 따져서 핑퐁을 주무기로 삼는 조직이 있을 수 있는가하면, 어떤 조직은 일당백으로 처리한다.
물론 구성원의 성향이 영향을 미치겠지만, 기본적으로 얼마나 많은 일이 몰려 오느냐와 그 일을 업무적인 성실함만으로 해결하기에는 공식적으로 회피할 수 있는 가장 좋은 말이 "프로세스는 이러하다..."는 말이다.
프로세스를 챙기되, 구성원이 놀고 있지 않고 있다면, 변화를 줘야한다. 조직을 늘이든, 병목과 밀접하게 일할 수 있도록 조직체계를 바꾸든...
범용이라는 편에 MVC 프레임웍인 CakePHP를 놓아보겠다. CakePHP에서 제공하는 Schema 기능은 SQL 표준적인 것 위주로 다루어져있다. 예를 들면, MySQL의 integer type의 필드에 unsigned 속성을 줄 수 있는데, CakePHP의 Schema에서는 그것을 표현하지 못한다.
CakePHP에서 unsigned로 검색되는 글 중 하나에서도 범용적이지 못하다는 이유로 그러한 것이 채택되지 않는 것을 볼 수 있는데, mysql 함수인 crc32 를 저장하기 위해서는 적어도 int(10) unsigned 형식을 사용해야한다.
signed int32 버전의 CRC32를 사용한다거나 CakePHP가 unsigned 를 지원하게 한다거나로 해결해 보려고 MySQL의 CAST, CONVERT 함수를 알아 봤고, CakePHP의 Schema Class의 패치도 생각해 보았으나, 모두 현실적인 시간 낭비라는 생각으로 결론을 내리게 되었다.
이러저러한 이유로, 만일 MySQL 특유의 튜닝이 들어가는 field 값이나 index 들이 존재하게 된다면, CakePHP가 지원하는 매끄러운 Schema 버전 관리기능은 포기해야하는 상황이 생길 수 있다. (내부적으로 cake schema 류를 console을 재작성해야 할 정도로 포기했다).
범용 프레임웍을 사용하는 것은 다른 무엇보다 빠른 구현에 목적이 있다. 그 프레임웍이 제공하는 괜찮은 라이브러리들, 그 프레임웍을 지지하는 많은 3rd party 컴포넌트들, 효과들... 이런 것들이 한 번 도입하여 익숙해지면 비슷한 개발에서는 쉽게 개발할 수 있는 장점이 된다.
하지만, 프로젝트의 어느 한 부분에서는 선택한 DB, 언어의 버전에 따른 특유의 장점을 살려야할 때가 있다. 어떤 일을 할때에도 그 종말이 이런 범용과 특수의 긴장상태에서의 선택이 되는 것은 늘 개발자에게 지리할 정도로 끊임없이 다가온다. 노련해지려면, 이런 상황에서 분위기를 맡고, 의연하게 다음과 같이 되뇌어야한다.
완벽해, 모습을 완벽하게 바꾸어 다시 나한테 왔어, 감쪽같이 속았잖아. 이 상황까지 나를 몰고 온 네 노력이 가상하다. 좋은 시나리오야, 좋아.
그리고는 아무 일 없었다는듯이 범용 라이브러리가 모든 것을 일반화 시키는 유혹(?)을 간단하게 물리쳐버리고, 범용이 미치지 못하는 틈새는 그냥 임시 방편, 땜빵으로 넘기고, 시간 낭비했다는 자괴감 따위는 느끼지 않는 자세가 더 중요하다.
Windows XP를 쓰는 VirtualBox의 메인 파티션이 10GB였는데, 곧 용량이 차서 늘여야할 판이 되었다. 그러나, 보안 속성등을 유지하면서 넓은 파티션으로 이동하는게 잘 안될것 같아 궁리하다가 해본 절차를 공유하자면, (VMWare나 VirtualPC에서도 쓸 수 있는 방법이 될 것 같다)
1. 다른 하드디스크를 하나 더 40GB 정도로 만든다. 2. 다른 VirtualBox에 두 하드 디스크를 연결한다. 3. 부팅한 다음, diskmgmt.msc 유틸리티를 이용하여 40GB를 F: 에 연결한다. (10GB는 E:에 연결되었다고 가정) 4. 오른쪽 버튼을 눌러 40GB를 "파티션을 활성화로 표시"해 둔다. 5. Windows XP Support Tools 을 설치한다. 6. cmd 창을 열어, Support tool로 이동한다음, robocopy라는 프로그램으로 E: 드라이브를 F:에 다음과 같이 복사한다.
오래동안 프로그래머라는 일을 하다보니 경력이 작은 사람들에게 옛날 이야기를 들려줄 때가 종종 있습니다. 아마, 10년 넘게 일한 사람들은 이런 경험이 많으리라 생각됩니다. 게다가 아직도 설계나 구현에 직접 참여할 기회를 가지고 있는 현역에서 뛰고 있는 "IT 중년"들이라면 더더욱 할 얘기가 많을 것입니다.
저도 그런 부류에 들어 있는 사람으로서, 게다가 80년대 초반(제가 초등학교시절)부터 어떻게든 프로그래밍을 계속 해온 사람으로서 그 역사속에서 다양한 설계 기법들이 명망을 거듭한 것을 종합하다보면, 한 때의 유행으로 취급한다거나 말만 그럴듯하게 포장되었다고 쉽게 간과하는 경향이 생기는 것 같습니다.
몇가지 예를 들어서 80,90,00년대를 변해온 환경을 되돌아 보겠습니다.
메모리가 없던 시절에는 메모리를 소중하게 생각하는 기법들이 많았습니다. 그러다가 메모리가 풍부해지니 넉넉히 설계해서 메모리 처리에 대한 신경을 그 전보다는 많이 안쓰게 되었습니다. 그러다가 임베디드 환경이 널리 보급되다보니 메모리에 대한 신경을 다시 쓰게 되었습니다. 언젠가는 또 반복되지 않을까요? 그것은 일반 프로그래머의 영역이 PC환경에서부터 초소형 환경까지 넓어졌기 때문입니다.
당시에 상용메모리, Extended memory, Expanded memory, High Memory 이름만 들어도 현기증 납니다. 메모리 관련된 개념들은 프로그래머가 아니라 게임하는 사람들이 더 잘 알았을 정도였습니다.
CPU의 성능이 올라가면서 메모리와의 성능 격차가 심해지는것과 중간에 캐시를 두는 것, 그리고 CPU의 코어 개수가 늘어나면서 캐시의 단계도 달라지다가, 심지어 메모리를 CPU 별로 물리적으로 직접 할당하는 NUMA환경이 되기까지 많은 아키텍쳐의 변화가 있어 왔습니다. 그러나 NUMA라는 기술또한 처음 나온 것이 최근일이 아니라, 과거 CPU와 메모리 및 시스템 버스에 대한 설계들이 빅뱅상태의 초기상태일때부터 있던 일입니다. 당시에는 CPU 카드들이 따로 있었고, 메모리도 그에 따라 다르게 설정이 가능하던 시절이었습니다. 한 20년 거의 하나의 아키텍쳐로 평준화되고 나니 그다지 이슈가 되지 않던 것이 그 한계에 도달하게 되고나면 이전 아키텍쳐들의 중요 개념들이 다시 들어오는 것입니다.
Remote Procedure Call 에 대한 것도 그렇습니다. 서비스를 구현하기 위해 실제 실행은 원격지에서 돌리고 이쪽에서는 호출하는 껍데기만을 가진다는 개념인데, 개체 지향적인 요소들이 추가되어 확장을 하였습니다. RPC가 보안상 문제가 있어 왔던적이 있어서 한동안은 RPC 용 서비스가 없던 시절에는 RPC용 데몬을 꺼둘것을 권고하는 시절도 있었습니다. RPC는 각종 언어에 포팅되어 호출될 수 있는 잠재력있는 기능이었습니다. XML이 입출력을 데이터를 표현하는 방법으로 바뀌기도 하였고, Javascript Object Notation을 사용한다든지, 도메인이 다른 스크립트간의 데이터 교환이라든지하는 기법들이 사용되는 것을 보고 나면, RPC라는 개념이 사라져 없어지는 것이 아님을 알 수 있습니다.
한동안 C-style의 언어 pascal, java, c++ 등 형선언이 비교적 강력하고, 절차형 언어에서 10년 정도 개체 지향적인 접근이 주류를 이루게 되었습니다. 이런 상황에 반해서 나온듯한 함수형 언어의 도약은 오히려 개체 지향적인 접근에 대해 무색하게 만드는 흐름처럼 보입니다. 함수형 언어(haskel, lisp, erlang) 혹은 함수형 언어적 성격(iterator, map, fold, generator, closure) 의 수용은 최근 몇년사이에 일어나는 경향입니다. 아마도 세대가 바뀌어서 개체 지향적인 접근이 우위를 점했듯이 함수형 언어적 특성들을 적극이용하는 것이 주류가 되려면 세대가 바뀌어야 가능할 것 같습니다. 아뭏든간에 이런 언어의 근간을 이루는 것도 이미 70,80년대에 모두 완성되었으며, 특수한 도메인에서만 사용되는듯하다가 이제 주류로 조금씩 나오는 상황입니다.
네트워크의 속도와 보조기억장치의 속도에 대한 것도 억지로 맞추자면 그러합니다. 네트워크로 OS를 부팅하는 이유도 경제적인 이유나 관리상의 이유에 의해 존재했습니다. 보조기억장치가 비싸던 시절에는 한 곳에 OS를 설치하고 네트워크로 부팅해주면 좋았던 시절이 있었습니다. 또한 동시에 수천대를 관리해야하는 서버실이라면, OS의 업그레이드를 굳이 일일이 하는 것보다 한 곳에 두어 하는 것이 편리하다는 장점이 있을 수 있습니다.
어쩌면, CPU, 메모리, 노드간 접속, 하드디스크, 버스를 머리속에 그려놓고, 이들의 속도에 대한 생각, 연결 방식에 대한 생각들이 고착화될 시점에 항상 그것을 부수는 방향이 그 다음 세대에 주효한 흐름으로 자리잡고 있습니다.
프로그래머는 공부를 많이 해야한다고 알려져 있습니다. 한가지 기술을 배워서는 몇년 못써먹는다고 하지요. 공부할 양이 많긴하지만, 너무 가장 보편적인 기술만을 공부해놓고서 몇년 못써먹는 기술이라 생각하는 것은 아닐까요?
알고리즘은 변한게 없고, 어떤 물리적인 구조의 성능을 극대화하기 위한 설계는 늘 변한게 없었습니다. 다만 물리적인 구조라는 것이, 수요가 많이 발생하여 변해왔다거나 대량생산에 의해 관심사가 달라졌다거나 기술적인 한계에 도달하여 도입한 패치가 이루어졌거나 하는 것일 뿐입니다.
배울때, 보편적인 기술의 인터페이스만 배우는 것은 좋은 기회를 놓치는 것입니다. 주위에 있는 사람들에게 종종하는 말은, 따로 공부하지 말고 주어진 일에 대한 공부가 필요할 때, 매우 깊이 파라고 합니다. 하나의 주요한 라이브러리나 언어적인 특성, 알고리즘을 공부해야할때, 그것과 연관된 근원까지 공부해두면, 언젠가는 한바퀴돌아서 다시 만나게 됩니다.
한가지 더, 그렇게 반복되는 듯한 모습이라면, 진보는 없다는 것으로 오해될 것 같습니다. 매우 중요한 개념의 확장이 있어왔습니다. GUI 환경이 그랬고, 인터넷이 그래왔고, 웹관련 기술이 그래왔으며, 이제 가상화나 분산처리기술들이 그러할 것입니다. 이런 기술들은 몇년을 두고 천천히 해도 늦지 않습니다. 이런 기술들이 주류로 편입되기에는 바뀌어야할 환경들이 많기 때문입니다. 하지만, 그것이 주류가 되기전에 그 기술적 배경들 속에 과거부터 있어온 것과 정말 그 기술이 새로이 도입한 것들을 가려낼 수 있다면 그다지 어렵지 않게 따라 잡을 수 있으리라 생각됩니다. 오히려 그런 기술들을 공부하는 것은 그 기술과 연관된 환경을 관찰하는 관광요소들이 많아서 지적으로 도움이 됩니다.
언젠가는 쉬는 날이 오겠지요. 그때까지는 달리렵니다.
