소프트웨어 개발자란 매우 유머 넘치는 존재입니다. 여타 공돌이와 전혀 다르죠. 전국의 어느 컴퓨터 공학과를 가든, 이성 친구 없는 학생을 찾기 어려울 정도입니다. 이는 소위 말하는
['개발자 유머']를 살펴 보면 더욱 분명해집니다.
개발자 세상에는
['RFC'](request for comments; 비평을 기다리는 문서)라는 이름의 전자 출판물이 있습니다. 굳이 고급스럽게 번역하자면 '댓글 좀...'이 될까요. 캐주얼한 이름과는 다르게, 굵직굵직한 인터넷 표준을 다수 배출한 저명한 출판물이죠. 그 유명한
['HTTP 표준']도 여기서 만들어지고 있습니다.
RFC는 매년 만우절마다 개발자 유머를 담은 문서를 한두 개씩 출판하는 것으로 유명한데, 대부분은 기존 기술에 대한 패러디라서 배경 지식 없이는 이해하기 어렵습니다. 하지만 가끔 그나마 일반인에게 설명하기 쉬운 것들이 등장하기도 합니다. 예를 들어,
* 네트워크에 대한 12가지 진실(RFC 1925): "첫 번째 법칙: 이게 안 될 리가 없는데..." 어디나 그렇지만 머피의 법칙은 진리죠.
http://tools.ietf.org/html/rfc1925
* 컴퓨터 이름 짓기(RFC 2100): 컴퓨터 이름을 짓는 게 얼마나 어려운지에 대한 '시'입니다. 이건 진짜 대공감. 저는 주로 온갖 작품에서 여캐 이름을 끌어 오는데, 가장 최근에 지은 컴퓨터의 이름은
['asseylum']이군요... 덕분에 어떤 캐릭터가 로마자로 철자가 어떻게 되는지 잘 알 수 있습니다.
http://tools.ietf.org/html/rfc2100
* Y10K 문제(RFC 2550): 1999년에서 2000년으로 넘어 올 때, 사람들은 Y2K 문제를 걱정했죠. 그렇다면
[Y10K 문제]는 어떤가요? 9999년에서 10000년으로 바뀔 때 심각한 문제가 발생할 수 있습니다. 이 문서는 이에 대한 다양한 해결책을 소개합니다. 그밖에 10만 년 문제, 10^30년 문제, 10^56년 문제, 10^732년, 10^18308년 문제 등도 다룹니다.
http://tools.ietf.org/html/rfc2550
* 무한 원숭이 테스트 도구(RFC 2795): 원숭이가 무한한 시간 동안 타자기를 치다 보면 언젠가는 셰익스피어의 작품이 튀어 나온다는 얘기가 있죠. 그렇다면 이걸 어떻게 검증할 수 있을까요? 이 문서는 원숭이들의 저작물을 수집하고 실제로 셰익스피어의 작품이 맞는지 확인하는 통신 및 제어 프로토콜을 제안합니다.
http://tools.ietf.org/html/rfc2795
그리고 오늘 소개할,
['조류 운반자를 이용한 인터넷 패킷 전송 표준']이 있습니다.
우선, 이 문서의 서문을 보면,
----
개요 및 필요성
조류 운반자는 높은 딜레이, 낮은 처리량, 그리고
[낮은 고도]의 서비스를 제공합니다. 각 운반자는 이쪽 지점에서 저쪽 지점으로의 단일 경로로 연결할 수밖에 없지만, 이른 봄을 제외하면 큰 간섭을 일으키지 않고 많은 운반자를 동시에 사용할 수 있습니다. 이는 운반자에게 허용된
[3차원 공간] 덕분에 가능하며, 기존 인터넷 표준이 사용하는 1차원 공간(역주: 랜선을 말함)과 대조됩니다. 운반자는
[고유의 충돌 방지 시스템]을 가지고 있어서 가용성(availability)이 향상됩니다. 전파 같은 몇몇 네트워크 기술과 다르게, 이 통신 방법은
[가시 거리를 넘어서는 장소]로도 전달이 가능합니다.
----
즉, 무슨 말이냐면... 인터넷 패킷을 실어 나르는 데
[비둘기]를 쓰겠다는 것입니다! 유서 깊은 전서구를 이용하는 것이죠.
구체적으로는, 패킷을 종이에 16진수로 인쇄한 후, 비둘기의 한쪽 다리에 매답니다. 패킷을 안전하게 보관하기 위해 테이프로 감쌉니다. 대역폭은 다리 길이로 제한됩니다. 한 번에 담을 수 있는 패킷 크기는 가변적이지만, 일반적으로 비둘기의 나이에 비례합니다.
송신 측에서는, 테이프를 제거한 후 종이를 스캔해서 전자적인 형태로 변환합니다. 이걸 OCR 돌려서 컴퓨터 데이터로 복원하면 됩니다.
이 문서가 처음 쓰인 것은 1990년이었고, 그 후 몇 차례 개정도 되었습니다. 그리고 마침내 2001년, 실제 구현이 만들어지기에 이르렀습니다.
[패킷을 16진수로 인쇄해서...]
[비둘기에...]
[매답니다!]
[안녕!]
[그리고 수신된 패킷을 받아서...]
[내용물을 확인한 후...]
[스캐너에 넣고 OCR 돌리면 끝!]
[작업에 참여한 동지들. 무척 즐거워 보입니다.]
그렇다면 결과는 어땠을까요?
당시 하늘에 비둘기 떼가 날고 있었기 때문에, 우리의 비둘기도 거기에 휩쓸려서(..) 같이 날아다니는 문제가 발생했다고 합니다. 행사 주최자는 "누가 비둘기들을 탓할 수 있겠습니까, 며칠 만에 햇볕이 쨍하니 날씨가 참 좋았는데요"라고 말했죠. 하지만 마침내 본능이 승리하여, 비둘기들은 한 시간 가량 즐긴 후 무사히 목적지에 도착했습니다. 9마리 중 6마리가 돌아왔고, 수신측에서 비둘기장을 닫는 걸 깜빡했기 때문에(..) 비둘기 중 두 마리에는 종이가 달려 있지 않았습니다. 그리하여 패킷 9개 중 4개가 전송에 성공한 것입니다. 따라서 패킷 손실률은 55%를 기록했습니다.
이 '구현'이라는 것은 단순히 오프라인 시연에만 의미가 있는 게 아니었습니다. 실제로 컴퓨터에서 소프트웨어적으로 만들어지기까지 했죠. 개발자들은 인터넷상에서 상대 컴퓨터가 살아 있는지 여부를 확인하는 명령인 'ping'을 사용해서 자신들의 성공을 기록했습니다.
[ping 명령의 결과는 보통 0-300밀리초 딜레이에 0% 손실이 나옵니다.]
그렇다면 비둘기들이 수행한 결과는?
----
vegard@gyversalen:~$ ping -i 900 10.0.3.1
PING 10.0.3.1 (10.0.3.1): 56 data bytes
64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=
[6165731.1 ms]
64 bytes from 10.0.3.1: icmp_seq=4 ttl=255 time=
[3211900.8 ms]
64 bytes from 10.0.3.1: icmp_seq=2 ttl=255 time=
[5124922.8 ms]
64 bytes from 10.0.3.1: icmp_seq=1 ttl=255 time=
[6388671.9 ms]
--- 10.0.3.1 ping statistics ---
[9 packets transmitted, 4 packets received, 55% packet loss]
round-trip min/avg/max = 3211900.8/5222806.6/6388671.9 ms
----
보시면 알겠지만, 대략 3000초에서 6000초(..)라는 시간을 소요하여 패킷이 도달한 것을 알 수 있습니다. 이것이 밖에서 실컷 놀다 온 비둘기의 비행 시간이죠.
어쨌든, 이것으로 실험 성공!
http://www.blug.linux.no/rfc1149/
ps: 컴퓨터 세계에서 비둘기 드립은 역사가 깊습니다. 구글 또한 만우절 장난으로
['사실 구글 검색 결과는 비둘기가 만들어 내는 것이다']라고 주장하기도 했습니다.
http://www.google.com/technology/pigeonrank.html