2. 한 물리 노드 내의 구현 문제…를 논의하는게 더 정당하지 않냐고 하시면 제가 할 말이 좀 없긴한데(이글 논지에선 특히),
이건 약간 다른 주제라고 생각합니다. 방법론적인 측면이 아니라 개별 도메인/응용에 따라 OS나 프로그래밍 언어 수준에서 제공해줄 수 있는 IPC 방법 혹은 동기화, 분산 트랜잭션 등등에 대한 요구사하잉 다를테니까요; 일단은 아주 간략하게 봤을 때의 얘기로 생각해주시면 좋겠습니다. (플레임 워를 원하는게 아니라 “이런 길도 있으니 한 방향만 보지 맙시다”니까요 )

그리고 이게 서비스하는 입장이 되면 좀 더 괴랄한 구조도 가능하기 때문에 논하기엔 덧글은 좀 짧은 거 같긴 합니다만(…). 제가 있는 곳 얘기는 아니지만 라이브 서비스 입장에선 더 재밌는 구조도 나옵니다.서버군 N개를 물리서버 M대 위에 올리는 구조에서,

* 서버를 논리적인 단위 M(m_0, m_1, …, m_{M-1})개로 쪼개고,
* 각각의 논리 단위를 하나의 프로세스로 표현하고,
* 이걸 M개 머신 위에 띄우고,
* 이걸 N개 서버 군이 머신 M개를 공유해서 동시에 진행 (다만 같은 인덱스의 m_이 뜨지 않도록…)

같은 방식도 있습니다. 즉, 거대한 단일 서비스가 아니라 똑같은 서비스 인스턴스가 복수로 있는 거면 다른 구현이 나오고 할테니까요(…).

여하튼(…), 멀티스레딩 한 방식 말고 좀 쉽게쉽게도 (적어도 잘 알려진 몇 가지 도메인에선) 별 무리없이 다중프로세스로 잘 가볼 수 있다라는 얘기죠(…).

어차피 태스크 사이에 공유할 것이 거의 없다면 싱글스레드-멀티프로세스나 멀티스레드-싱글/멀티프로세스나 별로 차이가 없겠죠. 아시다시피 웹서버 팜과 같은 경우에는 stateless하게 만드는 프랙티스가 오래전부터 정착되어왔기 때문에 어느 쪽도 널리 쓰이고 있습니다. (Apache MPMs, Tomcat, …) 더군다나 싱글스레드가 가장 단순하리라는 사실을 부인할 사람은 아마..아무도 없겠죠.
글에서도 논하셨지만, 문제는 이러한 태스크 사이에 공유할 것 = 통신할 것 생기면서 생기기 시작합니다. 공유할 것의 정도나 통신의 복잡도 (e.g. 웹서버의 세션 스토리지 vs. IRC network)는 도메인/응용에 따라 차이가 많이 나겠죠. 이런 응용 의존적인 거시적인 아키텍쳐 요소를 단순히 3가지 모델로 설명하는 부분에서 좀 무리가 있지 않나 싶습니다.

분산시스템의 통신 구조는 physical boundary를 넘어설 때 어떻게 해야하나라고 할 때 (점점 싸지고 있지만) 비용을 감수하고 당연히 취할 수 밖에 없는 선택지인 것이고, 만약 싱글스레드와 멀티스레드의 진정한 flame war 를 하나의 글 내에서 구현하시려면 하나의 physical entity 내 (이를테면 GFS node 내의 구현, Mysql/MongoDB/Redis Shard 내의 구현)에서의 선택 사항들을 논해야 정당하지 않을까요?

특정 응용에서는 싱글 스레드가 월등히 나은 (성능 얘기가 아니라 편의성, 프로그래밍 시간, 복잡도, 관리 편의성 등 자원 총합의 얘기) 경우가 생기지.

뭐 잘 골라내고, 잘 만들어내는게 엔지니어의 일이겠지