Event driven and polling architecture: 인생이란

Event driven architecture(사건 처리식 구조): 사건이 발생하면 즉각 처리하는 시스템
Polling architecture (점검 처리식 구조): 사건이 발생했는지 확인하여 처리하는 시스템

두 개의 동작하는 유닛이 만날때, 하나는 대개 서버가 되고 하나는 클라이언트가 됩니다. 위 두가지 방법 중 일반적으로는 사건 처리식 구조(Event driven)가 일이 발생할 때마다 처리하므로 즉각적인 반응을 하므로 선호됩니다. 하지만, 사건의 발생이 일의 처리보다 더 빨리 일어나는 경우에는 좀 느슨하게 점검 처리식 구조(Polling)가 낫습니다. 대개 대용량의 데이터가 고속으로 들어올 때 그런일이 발생하게 됩니다.

그러나 일반적인 인터넷 서버나 윈도우의 GUI 프로그램은 사건(Event)이 발생할 때, 즉, 웹브라우져가 접근했다거나, 사용자가 마우스를 클릭한다든지의 일이 발생할 때, 특정한 일을 처리하게 됩니다.

아무 일도 없는데 괜히 웹브라우져가 접속했는지 확인한다거나 마우스가 눌렸는지를 확인하는 코드를 수행한다면, 점검하느라 시간만 허비하는 구조가 되기 십상입니다.

따라서, 사건 처리식 구조가 일반적인 프로그램의 모습입니다. 사건이 발생하는 최하단 (네트웍카드, 마우스)부터 최상위 어플리케이션까지 몇단계의 레이어를 거칠때, 과연 온전히 사건처리식으로 되었느냐에 따라, 최신 기술(Asynchronous I/O 등)이 사용되었다라고 말하기도 합니다.

여태까지 서두였고, 정작하고 싶은 말은 프로그래밍 설계가 아니라, 사람사는 얘기입니다.

사건이 발생할 때마다 신속하게 처리하는 것을 중심으로 thread, pre-fork, epoll, iocp, kevent 등등 많은 기법들이 소개되고 구현하면서, 서버 개발자들은 귀챠니즘에 빠져들어가는 습성을 체득하게 됩니다.

보다 정교하게 일을 처리하고 싶어집니다.
누군가 정확히 일을 시켜주길 바라게 됩니다.
마치 자신이 서버가 된 듯한 착각으로 세상을 바라보기 시작합니다.
자신의 주위에서 일어나는 일을 스케쥴 가능한 여유 상태로 두려합니다.
시간에 무감각해져서, 기한을 추정할 수 없는 일 조차, 가능할 것처럼 느껴집니다.
일을 할 때 빈 시간이 없으면 매우 민감하게 반응하여 잘*못*되*었*다라고 말합니다.

이런 당신은 이미 잘못된 습성에 빠져들었습니다.

유능한 사람은 event-driven이 아닌, polling으로 살아야합니다.

생각해보십시오, polling이 프로그램 설계상으로는 미련한 시간낭비를 하는 것처럼 보이지만, 인간의 일은 모든 일을 꼼꼼히 계속 확인하는 것 보다 더 정확한 습관은 없습니다.

프로그래머가 기계적으로 세상을 바라보게 되는 시점부터, 이미 무기력한 사람이 되어 있습니다. 조금 쉬려는 마음이 들 때, 혹시 서버 프로그램처럼, 윈도우 프로그램처럼 누군가가 나를 자극하기 전에는 꼼짝하지 않으려는 생각이 들지 않습니까? 프로그램 잘 만드시겠습니다. 계속 주욱 그렇게만 사십시오.

인생은 닫힌 체계가 아니라서, 이벤트의 종류도 가지가지거니와, polling 대상도 한두가지가 아닙니다. 자신만의 체계에서 뛰어나와 연결된 모든것을 polling 해봅시다.

P.S.
꼭, 제 자신에게 쓰는 말 같습니다.