요즘 고민하고 있는 문제인데, 보안상의 이유로 비유적으로 설명해보겠다. (실제로 이런 일을 하고 있는 건 아니다 -_-)

이글아이처럼 우리 국정원에서도, 1분 정도의 음성 통화를 대충 100K 로 압축할 수 있는 압축 알고리즘을 기반으로 하는 휴대폰 통화 감청 시스템을 구축한다고 가정하자.  하루에 10 테라바이트 씩 쌓이긴 하지만, 당연히 각 통화 데이터 끼리의 연관성은 없고, 오직 2개의 송신/수신 전화번호의 키값으로 구분될 뿐이다.

모든 데이터들은 프라이버시 보호보다는 HDD 부족으로 2주 정도만 지속되며, 오직 리만브라더즈 2명만 들을 수 있다. 물론 둘 다 바빠서 아무도 듣지 않을 수도 있지만, 그래도 무조건 남기긴 남겨야 하는 이 프로젝트를 당신이 맡게 되었다. (아싸 비유를 만들어내는 게 더 리얼하구나~)

문제는, 연기금을 모두 주가 부양에 써버린 나머지 PC 조립 서버 몇 대만으로 최대한 싸게 구현해야 한다면, 어떤 솔루션을 선택해야 할까? (한줄로 요약하면, 자잘한 BLOB 들이 산더미처럼 만들어질 때의 안정적인 관리 및 검색의 문제인데 검색의 비중이 상당히 낮은 케이스라고 할 수 있다.)

1. 파일 시스템 : 분산 컴퓨터들의 RAID로 보호되는 파일 시스템에 남기고, 검색은 그냥 폴더명으로.. 백업이 없어서 좀 무섭다.
2. 파일 시스템 + 복제 : 안전을 위해 남기는 넘과 읽는 넘을 분리. 안 읽는 넘도 복제해야 한다는게 좀 아깝지만.
3. 분산 데이터베이스 : blob insert 는 좀 힘들지만 어쨌든 검색은 쿼리다.
4. 분산 데이터베이스 + 복제 : 역시 불필요한 복제의 딜레마는 마찬가지.
5. 분산 파일 시스템 + 데이터베이스 : 검색은 파일 시스템, DB는 2차 백업으로… (이건 오버인가;;)
6. 기가비트 이더넷 + HTTP : 분산 컴퓨터들을 기가비트 이더넷으로 묶고, HTTP 서버가 공유 폴더로 인식, Rest 방식으로 다운로드
7. in-memory 테이블이나 데이터베이스: 어차피 용량의 한계로 안될 듯!

Changes in a system can be made in two primary ways. I like to call them Edit And Pray and Cover and Modify. Unfortunately, Edit and Pray is pretty much the industry standard.

–Michael C. Feathers

TDD를 쓰지 않는 대부분의 프로그래머들은 Edit &Continue 보다는 Edit & Pray 를 더 사랑한다. 물론 나도 컴파일러와 윈도우 커널와 쓰레드들에게 자주 빌기도 하지만, 언젠가부터 테스트 없이 일을 진행하면 아무리 실행이 잘되어도 마음 한구석이 편치 않게 되는 경우가 많아졌다. 테스트 통과 후 커밋할 때의 쾌감에 중독되었기 때문인데, 사소한 것까지 테스트한다고 잔소리를 들은 후에야 겨우 벗어날 수 있었다. 그래서 요즘에는 라이브러리 학습이나 개인적인 프로젝트에서만 테스트를 활용하고 있다. 

최근, 새 프로젝트에서 한정된 시간안에 핵심적인 로직을 제외한 나머지 - 플랫폼, 데이터베이스, 네트워크 프레임워크 외 다수- 들을 마이그레이션하면서 성능과 안정성을 동시에 만족시켜야 하는, 그야말로 도전적인 과제를 맡았다. 이 세마리 토끼를 한방에 잡아주는 은총알이 없는 거야 당연하지만, 그렇다고 점진적으로 리팩토링해나가면서 지켜보는 것도 불가능한 상황이다. 비유적으로 말하자면, 새로 논밭을 사서 농사를 대충 짓다가 적당히 직불금을 받아먹은 후 양도세를 면제받은 후(응?), 기존의 집을 그대로 들어 올려서 새 토지에 얹어 놓고, 인테리어를 막판에 갈아 엎는 대공사를 할 수 밖에 없을 것 같다. 물론 기도를 빠뜨리면 안되겠지만.

어쨌거나 기회가 되면 google test를 써보고 싶은데, 이 대운하에 버금가는 공사에서 가능할 것인지 나도 참 궁금하다. 쉬귀군이 밥먹다가 말한 것처럼 삽질이 되면 안되는데… 후덜덜.

80:20의 법칙이라는 이름으로 더욱 잘 알려진 파레토의 법칙을 게임 개발에 적용한 가장 좋은 예는, “20%의 코드가 80%의 부하를 차지하므로 섣부른 최적화는 피하라”는 격언일 것이다. 그리고, 20%의 개발자가 80%의 업무를 처리한다는 일명 개미와 베짱이의 법칙도 유명하다. 그런데 라이프해커님의 최근 글에서 발견한 또다른 재미있는 예가 있는데,

20%에 불과한 사람들이 회사의 80%의 트러블을 만들어내며 당신과 기타 사람들은  부득불 80%의 시간을 내서 그 문제들을 처리해야 한다. 

라는 내용이었다. 이 글을 보고 그저 고개를 끄덕일 수 없었던 이유는, 최근까지도 이런 문제들로 고생을 해봤기 때문이다. 다만 이번에 큰 조직으로 옮긴 후부터, 20%에 해당하는 개미 부류의 개발자들을 한 명씩 발견하게 되어 과거의 상처가 서서히 아물어가고 있지만, 이 불타는 분노는 최소 10년동안은 지워지지 않을 것 같다. 덕분에 조직의 암적인 존재들은 조기에 제거해야 한다는 좋은 교훈을 배웠다. 그리고, 그들을 보다 빨리 인식하기 위한 눈썰미를 키워야 한다는 다짐도.

ps. 그렇다고 또 본인은 지금까지 한번도 트러블이 되어본 적이 없었다고 말하기도 뭣하다는게 조금 가슴 아프기도 하다.