멀티 코어 활용 할 방법 이 정말 멀티스레딩 뿐 이 라고 ? – rein ' s world 
 멀티 코어 활용 할 방법 이 정말 멀티스레딩 뿐 이 라고 ? 
 Posted byJinuk Kim 	 2011 - 06 - 07 2011 - 06 - 07 35 Comments on 멀티 코어 활용 할 방법 이 정말 멀티스레딩 뿐 이 라고 ? 
 예전 에 ` Multicore 의 concurrency 를 위해선 멀티스레딩 뿐 인가 ? ” 라는 글 을 썼 다 . 
 OpenMP 나 tbb , 혹은 MS 의 Parallel Patterns Library 모두 일 을 더 쉽 게 만들 어 주 는 게 아니 다 . 그 네 들 은 병렬 프로그래밍 을 쉽 게 해 주 는 기능 을 제공 해 주 긴 한다 . 하지만 당연히 싱글 스레드 프로그래밍 보다 어렵 다 . 
 즉 , 원래 목표 여야 하 는 “ 병렬 하드웨어 활용 을 쉽 게 해 주 는 것 ” 이 아니 다 . 이 툴 들 의 목적 은 현재 단일 스레드 로 작성 한 프로그램 을 , 어떻게 멀티 스레드 프로그램 으로 수정 하 면 병렬 하드웨어 를 좀 더 잘 쓸 수 있 을까 하 는 경우 를 해결 하 는 것 이 다 . 
 이거 랑 멀티 코어 CPU 를 잘 쓰 는 일 은 동일 한 게 아니 다 . 
 쉬운 길 은 이미 “ 많 은 프로그램 들 이 잘 하 고 있 는 일 ” 이 다 . 간단 하 게 , 하드웨어 가 병렬 화 가 되 면 ` 할 일 을 더 주 면 된다 ’. ( Gustafson ’ s Law ) 
 웹 서버 나 , hadoop 처럼 부하 가 늘어나 면 작업 단위 를 처리 하 는 ` 프로세스 를 더 많이 띄우 면 된다 ’. 복수 의 프로세스 ( 스레드 ) 가 특정 상태 를 공유 하 면서 / 업데이트 하 지 않 는 이상 , 이 방법 은 
 작성 하 기 익숙 하 고 ( 익숙 한 싱글 스레드 프로그램 이 다 ! ) 
 디버깅 하 기 쉽 고 ( 멀티 스레드 프로그램 은 비결정론 적 이 다 ) 
 기존 코드 를 거의 변경 하 지 않 아도 된다 
 라는 엄청난 장점 이 있 다 . 
 서버 프로그래밍 의 — 특히 게임 서버 프로그래밍 — 목적 은 , 지연 시간 을 일정 이하 로 유지 하 는 수준 에서 최대 처리 량 ( throughput ) 을 얻 는 것 에 있 다고 생각 한다 . 즉 , 개별 서버 프로세스 가 비슷 한 일 — 프로세스 마다 1 개 채널 의 로비 를 처리 한다거나 — 을 처리 해서 부하 를 적당히 쪼개 고 , 싱글 스레드 에서 처리 가능 한 수준 [ 1 ] 의 부하 를 담당 한다면 , 굳이 이걸 omp / tbb / ppl 같 은 걸 써서 복잡 하 게 짤 이유 는 없 지 않 은가 ? 
 물론 공유 상태 가 많 으면 MT 로 짤 수 는 있 겠 지만 , 그 경우 에 도 비슷 한 원칙 을 유지 한다 . 
 싱글 스레드 화 되 는 부분 — 동기 화 처리 부분 — 은 메시지 교환 등 으로 우회 하 거나 , 최소 화 하 고 
 같 은 일 을 하 는 프로세스 … 대신 스레드 를 여럿 둔다 
 그리고 이 스레드 의 수 만 늘린다 
 즉 , 본질 적 으로 는 일부분 을 제외 하 고 는 싱글 스레드 프로그래밍 을 하 고 , 이 부분 을 늘려서 주 어 진 병렬 하드웨어 를 잘 쓰 자 라는 것 . 
 그러니까 , 싱글 스레드 성능 향상 이 목적 이 아니 라면 , omp / ppl / tbb 다 그렇게 영양가 높 은 얘기 는 아니 다 라는 게 내 생각 이 다 . [ 2 ] 오히려 , 전체 구조 를 잘 생각 하 고 똑같 은 게 여러 개 돌 부분 을 찾 고 , 이 부분 을 여럿 띄울 생각 을 하 는 게 — 예 를 들 자면 마비노기 영웅전 의 micro - kernel 틱 한 구조 에서 개별 서비스 를 여러 개 띄우 는 것 처럼 — 생산 적 인 게 아닐까 ? 
 그 이전 에 ( … ) 서버 자체 는 많 은 경우 애초 부터 멀티 스레드 로 짜 고 , 독립 적 으로 할 수 있 는 부분 도 많 기 때문 에 tbb 같 은 게 적합 할 태 스 크 패 러 럴 , 혹은 데이터 패 러 럴한 워크 로드 가 아닌 것 도 좀 … 코어 를 다 차지 할 만큼 의 스레드 들 이 있 는데 , 굳이 단일 스레드 프로그래밍 에서 CPU 코어 여러 개 쓰 기 위한 방법 을 가져다 쓸 이유 가 있 을까 ? 
 내 가 리뷰 안 쓰 는 무언가 때문 에 이런 글 을 썼 다고 느끼 면 “ 그게 다 기분 탓 ” 입니다 . 
 그러니까 엄한 지연 시간 이 나오 지 않 는 [ ↩] 
 물론 일부분 , 예 를 들 어 tbb scalable allocator 라거나 concurrent container 류 는 그 자체 만 으로 쓸모있 는 라이브러리 이 기 때문 에 여기저기 쓸 곳 이 많 다 . 그렇지만 parallel _ for , parallel _ reduce 같 은 게 정말 필요 한가 ? [ ↩] 
 Posted byJinuk Kim 2011 - 06 - 07 2011 - 06 - 07 Posted inComputerTags : Programming , 멀티스레딩 
 그래프 가지 고 장난치 지 말 자 
 2011 - 06 - 08 at 2 : 59 am 
 개인 적 으로 도 병렬 프로그래밍 연구자 들 이 지나치 게 ( ? ) computational , algorithmic 하 게 토픽 에 접근 하 는 게 좀 불만 이 었 습니다 . 사실 병렬 프로그래밍 이 라는 건 스케일 큰 일부 scientific computing 이슈 들 빼 면 어떻게 하 면 알 아서 잘 수행 하 도록 구조 를 잘 만들 고 로직 을 구성 하 느냐 가 가장 큰 문제 라고 생각 하 거든요 . 
 저 같 은 경우 는 병렬 프로그래밍 문제 의 본질 은 거의 대부분 상태 에 대한 순서 의존 성 – 객체 의 처리 순서 , 함수 호출 순서 , 락 이 걸리 는 순서 등등 – 에 기인 한다고 보 기 때문 에 이걸 exploit 하 려는 알고리즘 적 인 접근 은 실효 성 이 거의 없 다고 봅니다 . 실제 로직 에 는 이걸 최대한 감추 는 방향 으로 가 야 된다고 생각 … 물론 저게 논문 쓰 는 데 는 좋 겠 지만 ( … ) 
 2011 - 06 - 08 at 8 : 16 am 
 연구자 들 이야 기존 에 만들 어 진 프로그램 거의 대부분 이 스레드 를 염두 에 두 지 않 고 만들 었 으니 , 그 자체 를 잘 조작 ( ? ) 해서 병렬 화 하 는 데 관심 이 가 는 건 어떤 의미 로 는 당연 한 듯 합니다 . 
 하지만 직업 프로그래머 가 , 
 “ 이런 것 도 있 어요 . 이걸 써 보 시 면 좋 겠 네요 ” 
 에 머무르 고 , 
 “ 우리 는 이런 상황 에 적용 해 봤 는데 pros & cons 는 어떻 다 ” 
 라고 말 할 수 없 는 건 , 혹은 말 하 지 않 는 건 좀 문제 라고 봅니다 . 요 며칠 간 그런 말 하 는 걸 몇 개 봤 더니 좀 그렇 더라고요 ( … ) . 
 디 밥 says : 
 2011 - 06 - 09 at 8 : 24 am 
 TPL 의 경우 에 는 비동기 방식 도 손쉽 게 지원 합니다 . 이 부분 이 병렬 프로그래밍 부분 과 같 은 비중 으로 중요 하 다고 생각 됩니다 . 
 공부 하 면서 도 병렬 프로그래밍 만 본다면 , 거시 적 으로 프로세스 를 여러 개 사용 하 는 것 이 더 효과 적 일 수 있 다고 생각 했 지만 , 비동기 방식 지원 에 대해 공부 까지 해 보 니 , TPL 의 경우 는 병렬 도 손쉽 게 사용 할 수 있 어 좋 지만 ( 초 중급 에게 교육 시키 고 , 보급 시키 기 도 좋 습니다 ) 그 보다 더 좋 은 점 이 비동기 방식 의 프로그래밍 을 아주 쉽 게 적용 가능 하 다는 거 라고 생각 됩니다 . C # 5 . 0 에 는 Async 가 기본 으로 제공 된다고 하 니 기대 해 볼 만 합니다 . 
 2011 - 06 - 09 at 8 : 50 am 
 이 글 의 논지 는 그런 쪽 이 아닙니다 . 제 가 얘기 하 고자 하 는 바 는 , 
 1 . 정말로 멀티 코어 하드웨어 쓰 겠 다고 비동기 / 병렬 프로그래밍 을 해야 하 는가 ? 
 2 . 상호 동 립 적 인 비슷 한 일 ( 구스타프슨 법칙 을 생각 하 면 … ) 이 많 다면 그냥 복수 의 동일 한 프로세스 를 실행 하 는 식 으로 피해갈 수 있 겠 다 
 즉 , 정말로 병렬 처리 가 필요 한 상황 이 아니 면 — 보통 은 병렬 처리 가 아니 라 병행 프로그래밍 ( concurrent programming ) 이 겠 지만 — 굳이 안 해도 되 며 , 위 에서 언급 한 제약 사항 대로 설계 수준 에서 피해 가 자라 는 게 주 입니다 . 
 2011 - 06 - 09 at 10 : 06 am 
 멀티 코어 - 병렬 프로그래밍 은 매칭 이 되 지만 , 비동기 프로그래밍 은 꼭 멀티 코어 와 는 상관없 습니다 . 당연 Computed Bound 비동기 프로그래밍 은 멀티스레딩 이 고 , 멀티 코어 에서 더 좋 은 환경 이 되 겠 지요 . 
 제 말 도 비슷 한데 … 
 1 . 굳이 쓸 데 없이 병렬 프로그래밍 을 적용 하 려고 애쓸 필요 는 없 다 . 
 2 . 단 비동기 방식 은 되 도록 사용 하 자 . 그게 IO - Bounded 라면 무조건 ! !! Computed - Bounded 라면 절제 해서 … 
 사실 모든 코딩 상황 이 병렬 처리 가 필요 한 상황 인지 예측 하 기 도 힘 듬 니다 . 그렇 다고 현실 적 으로 개발자 들 이 병렬 프로그램 에 대해 거부 감 만 가지 고 , 학습 조차 하 지 않 으려는 그런 상황 에서 저 는 병렬 프로그래밍 으로 적용 해 보 기 를 추천 합니다 . 그런 후 장단점 분석 을 해 보 니 아니 다라면 그 때 기존 방식 을 사용 해도 늦 지 않 다는 얘기 입니다 . 
 2 . 상호 독립 적 인 일 에 대해서 는 뭘로 하 던 상관없 지만 … 같 은 프로세스 에서 움직여야 하 는 제약 사항 이 있 는 Client Application 인 경우 에 는 비동기 / 병렬 프로그래밍 이 필수 입니다 . 
 전 굳이 피해갈 필요 없 다고 생각 합니다 ^^ ( 아직 배우 지 도 못한 사람 들 이 핑계 를 너무 대 거든요 ) 
 2011 - 06 - 09 at 10 : 30 am 
 제 얘기 는 병렬 프로그래밍 은 어차피 쉽 지 않 으니 피해갈 수 있 는 만큼 피해 가 잔 는 얘기 입니다 . 
 회사 에서 하 는 일 도 explicit threading 으로 서버 프로그램 을 작성 하 는 일 이 지만 , 비동기 메시징 을 이용 해서 멀티 코어 를 모두 활용 은 하 고 — 물론 충분 한 수 의 스레드 가 돌 고 있 는 환경 — 전체 프로그램 구조 자체 는 아주 일부분 을 제외 하 면 싱글 스레드 처럼 만듭니다 . ( 오히려 코어 수 가 늘어날 수록 이쪽 처럼 최대한 동기 화 연산 을 피해 가 게 만든 성능 이 더 잘 나오 는 편 이 기 도 하 고요 ) . 
 시스템 프로그래머 적 인 관점 에서 본다면 , 해야 할 일 은 “ 대부분 의 응용 프로그램 작성자 가 쉽 게 코어 활용 을 하 게 해 주 는 일 ” 이 지 “ 멀티 스레드 프로그래밍 을 가르친다 ” 가 아니 거든요 … 
 2011 - 06 - 09 at 9 : 45 am 
 병렬 프로그래밍 을 가지 고 삽질 하 고 있 지만 병렬 프로그래밍 혹은 멀티 스레드 , 또는 병행 프로그래밍 의 첫 번 째 원칙 은 “ 필요 없 으면 하 지 말자 ” 라고 생각 해요 ㅎㅎㅎ 주장 하 시 는 바 를 요약 하 면 멀티 스레드 + 단일 프로세스 보다 단일 스레드 + 멀티 프로세스 로 하 자는데 그게 가능 하 다면 당연히 그렇게 해야죠 . 멀티 프로세스 구조 는 안정 성 에 도 도움 이 되 고요 . 물론 좀 오버헤드 가 따르 겠 지만 그게 상쇄 가능 할 정도 라면 그게 편하 다고 봅니다 . 
 그리고 보통 OpenMP 나 TBB 는 ( TPL 은 안 써 봐서 모르 겠 는데 비슷 할 듯 ) 대부분 이 embarrassingly parallel 한 작업 에 약간 의 동기 화 ( barrier / mutex 정도 ) 에 적합 합니다 . 저걸로 복잡 한 스레드 제어 는 좀 어렵 죠 . 아예 제대로 디자인 된 패러 럴 프로그래밍 언어 인 X 10 / Habanero Java 는 잘 추상 화 된 동기 화 연산 이 있 지만 … 
 강연 듣 다가 누가 “ 멀티 스레드 로 가 야 한다 ! ” 라고 주장 한 걸 들 었 나요 ? 뭐 든 필요 할 때 쓰 는 것 이 중요 . 마치 안티 패턴 을 보 는 것 같 군요 . 
 한 머신 에서 버티컬 스케일링 을 극대 화 하 겠 다 , 그것 도 커플링 이 심한 경우 에 … 를 빼 고 는 사실 멀티스레딩 하 면 안 된다고 생각 하 빈다 . 
 근데 최근 에 들 은 강연 몇 개 에서 그런 얘기 를 듣 고 나 니 좀 입맛 이 쓰 더라고요 . 
 2011 - 06 - 09 at 10 : 13 am 
 현실 에서 웹 프로그래밍 개발자 만 가득 한 상황 에서 , Client Application 이나 백그라운드 서비스 모듈 을 만드 는 고급 개발 과정 으로 진입 하 기 위해서 는 멀티스레딩 프로그래밍 은 필수 입니다 . 거기 에 비동기 프로그래밍 도 필수 이 구요 ( 네트 웍 , 큐 방식 ) . 거기 에 병렬 프로그래밍 까지 할 수 있 다면 더 좋 겠 죠 . 
 현실 적 으로 후배 개발자 들 에게 기술 전수 를 하 려고 할 때 , 제 가 애 로 점 을 느끼 는 것 은 
 첫째 . 웹 프로그래밍 경험 만 으로 다른 기술 에 대한 필요 성 을 느끼 지 못한다는 점 
 둘째 . 스레드 에 대한 개념 이 없 다 . ( 물론 OS , DB , WAS 의 기초 적 인 구조 도 모르 는 경우 도 허다 합니다 ) 
 세째 . 문제 해결 을 위한 적용 방 안 에 대한 장 / 단점 분석 이 객관 적 이 지 않 고 , 자신 이 알 고 있 는 수준 에서 결정 한다는 것 입니다 . ( 예 를 들 어 , 비동기 방식 프로그래밍 을 모른다면 , 절대로 비동기 방식 프로그래밍 을 채택 하 지 않 습니다 ) 
 뭐 현실 적 으로 이런 문제 때문 에 아침 에 비몽사몽 얘기 했 습니다 . 
 CGI 는 멀티 프로세스 이 고 , IIS 는 멀티 스레드 방식 이 죠 . 제대로 사용 한다면 저 는 IIS 가 더 좋 은 방식 이 라 생각 됩니다 . 
 IIS 를 제대로 활용 못 하 고 , 잘못 사용 하 는 개발자 가 문제 지요 . 
 2011 - 06 - 09 at 10 : 36 am 
 제 가 비동기 프로그래밍 을 비판 하 는 입장 은 아닙니다 . 멀티 스레드 프로그래밍 이 만능 의 칼 은 아니 라는 거 죠 . 말씀 하 신 바 처럼 싱글 스레드 프로그래밍 에 만 익숙 한 ‘ 많 은 수 의 개발자 ’ 에게 적합 한 구조 ’ 를 만들 어야 한다는 얘깁니다 . 
 너무 개발자 들 을 몇 가지 스테레오 타입 으로 나누 려고 하 시 는 듯 한데 , 
 1 . 웹 프로그래밍 이 라고 해도 크 게 프런트 엔드 와 백 엔드 프로그래머 로 나눈다면 , 백 엔드 프로그래머 들 은 ( 어차피 이전 에 도 ) 멀티 스레드 / 멀티 프로세스 프로그래밍 을 해 왔 습니다 . ( 간단 한 예 로 는 제 가 참가 하 고 있 는 프리웨어 멀티 스레드 웹 서버 인 Berryz WebShare 부터 , 훨씬 복잡 한 메시지 큐 구현 체 나 웹 서버 , 혹은 웹 서비스 컨테이너 작성자 들 이 있 겠 습니다 ) 
 2 . 스레드 에 대한 개념 은 학부 OS 수준 만 알 아도 , 실제로 많이 경험 하 게 될 일 은 ( 적어도 제 가 생각 하 기 엔 ) 태 스 크 병렬 작업 들 이 거나 , 전체 병렬 화 작업 이 잘 정의 된 과학 연산 들 일 꺼라 큰 문제 없 어 보입니다 . 
 3 . 이런 문제 분석 은 좀 더 높 은 추상 화 수준 에서 일어나 야 하 고 , 경험 적 은 개발자 가 그걸 다 하 진 않 을 거 같 은데요 . 
 부언 하 자면 , CGI 는 ‘ 프로토콜 ’ 이 고 IIS 는 MS 의 웹 서버 입니다 . 약간 비교 가 이상 하 네요 . 예 를 들 어 CGI 인터페이스 의 프로그램 이 Apache MPM 의 개별 워커 프로세스 ( 설정 에 따라선 스레드 ) 위 에서 돈다면 이건 다른 의미 로 멀티스레딩 이 죠 . 그리고 단일 CGI 프로그램 이 라 할지라도 그 내부 구현 을 단일 스레드 로 제한 하 지 는 않 습니다 . 
 2011 - 06 - 09 at 10 : 54 am 
 CGI 와 ASP . NET 이 되 겠 죠 . . 
 저 랑 은 현실 적 으로 많이 다른 곳 에 있 는 듯 합니다 . 아마 Business Web Application 프로젝트 에서 90 % 이상 이 스레드 에 대해 모릅니다 . 
 학부 요 ? 요즘 웹 개발 환경 에서 말 이 죠 전산 이외 의 과 가 더 많 고 , 전산 과 출신 이 라 하 더라도 스레드 에 대해 전혀 사용 해 보 지 못한 그런 사람 들 이 더 많 더군요 … 이런 사람 들 이 언젠가 는 중급 , 고급 개발자 로 커야 하 는데 , 그렇게 되 기 위해서 는 꼭 멀티 스레드 에 대해 공부 해야 한다는 점 입니다 . 
 2011 - 06 - 09 at 7 : 31 pm 
 말씀 드렸 듯이 , CGI 인터페이스 를 써도 얼마 든지 그 위 에서 도 는 프로그램 은 MT 일 수 있 습니다 . CGI 래 봐야 환경 변수 , stdin / stdout 에 대한 조건 밖 에 없 으니까요 . 
 그리고 웹 개발 로 더 한정 해서 얘기 하 자면 , 대체 웹 서버 나 캐 싱 레이어 , 웹 응용 프로그램 컨테이너 말 고 MT 에 대해 생각 할 이유 가 있 나요 ? 웹 자체 의 스케일링 은 주로 버티컬 한 MT 기반 의 스케일링 이 아니 라 , 단일 서버 내 의 복수 프로세스 ( 혹은 복수 웹 응용 프로그램 스레드 ) , 혹은 복수 서버 군 에서 의 다중 프로세스 + 캐 싱 + 리버스 프록 싱 + 로드 밸 런 싱 … 등 으로 이뤄질 거 라 생각 합니다 . 
 대다수 의 개발자 가 이 를 위한 인프라 ( 웹 서버 자체 , 캐 싱 서버 자체 , 데이터 베이스 엔진 자체 , … ) 를 작성 하 는 게 아니 라면 굳이 비동기 / 병렬 프로그래밍 을 해야 할까요 ? 현재 유효 한 하드웨어 자원 들 은 인프라 자체 에서 활용 하 는 형태 로 가 는 건데 말 이 죠 … 
 그런 의미 에서 중급 / 고급 개발자 로 크 려면 이런 큰 그림 을 이해 하 고 , 어디 가 정말 성능 문제 를 일으키 는지 파악 하 고 , 해당 부분 을 극복 할 수 있 는 구조 를 설계 할 수 있 어야 할 것 같 습니다 . 
 달리 나 음 says : 
 2011 - 06 - 11 at 10 : 22 am 
 오프 토픽 이 지만 현대 적 인 웹 프로그래밍 모델 이 아니 신 것 같 습니다 . 단일 프로세스 의 멀티 스레드 로 얼마나 많 은 요청 을 커버 할 수 있 을까요 ? 하나 의 프로세스 가 생성 할 수 있 는 쓰레드 의 양 은 제한 적 입니다 . 웹 서버 가 reverse proxy 가 되 는 현대 적 인 웹 프로그래밍 에서 는 다중 프로세스 를 선택 하 는 것 이 일반 적 입니다 . 그리고 요청 의 상당수 를 백 엔드 의 메시지 큐 와 같 은 외부 세계 에 의존 하 고요 . 지금 의 웹 프로그래밍 은 예전 의 더 많 은 요구사항 을 더 강력 하 게 수행 하 면서 도 더 이해 하 기 쉬운 모델 을 가지 고 있 습니다 . 
 2011 - 06 - 12 at 3 : 43 pm 
 왜 단일 프로세스 라 한정 하 지요 ? 왜 모 아니 면 도 입니까 ? 두 분 말씀 자체 가 우선 순위 의 애기 라면 , 당연히 비용 이 저렴 한 단일 프로세스 의 멀티 스레드 방식 부터 시작 해서 , 더 많 은 확장 성 을 위해서 멀티 프로세스 의 멀티 스레드 로 가 야 지요 . 왜 제 말 이 단일 프로세스 에 한정 한다고 들 생각 하 는지 이해 가 안 되 네요 . HA 구성 도 효율 및 효과 를 생각 한다면 당연히 멀티 스레드 특히 ThreadPool 을 잘 사용 해야 한다고 봅니다 . 
 지금 모델 과 구 모델 을 뭘 말씀 하 시 는지 ? 
 . NET Framework 의 경우 , CPU 당 WorkerThread 수 를 25 -> 100 으로 늘렸 습니다 . 그래도 프론트 쪽 에서 잘못 구현 하 면 요청 큐 가 꽉 찰 수 있 습니다 . 
 H / W 로 뭔가 하 는 것 은 프로그래머 가 잘 이용 하 는 것 밖 에 는 안 되 는 것 이 고 , 그 것 으로 도 부족 할 때 에 는 결국 S / W 적 으로 해결 해야 만 합니다 . 
 전 S / W 방식 으로 해결 방법 이 있 는데도 , H / W 에 미루 는 게 더 이상 하 다고 생각 합니다 . 
 2011 - 06 - 12 at 4 : 15 pm 
 일단 원본 블로그 글 을 다 읽 고 글 을 써 주 시 면 좋 겠 네요 . 
 우선 순위 문제 라면 당연히 가장 쉬운 단일 스레드 의 복수 프로세스 그리고 복수 머신 으로 가 야 지요 . 이게 불 가능 해서 다중 스레드 프로그래밍 으로 버티컬 스케일링 을 하 려는 게 아니 면 요 . 게다가 HA 를 단일 머신 에서 한다는 건 잘 이해 가 안 가 는군요 . 겨우 스레드 풀로 HA 를 한다는 건 SW 버그 나 하드웨어 오동작 은 신경 도 안 쓰 겠 다는 건가요 ? 
 지금 디 밥 님 이 얘기 하 는 모든 문맥 이 전부 구 모델 입니다 . 단일 머신 의 성능 을 올려서 부하 를 견디 는 게 예전 방식 인 거 죠 . 
 왜 프런트 웹 서버 와 응용 프로그램 컨테이너 가 하나 인 IIS + . net 으로 얘기 를 한정 하 는 건지 설명 좀 해 주 시 면 좋 겠 군요 . 
 여기 서 하 고자 하 는 얘기 는 실제로 부하 가 걸리 는 웹 응용 프로그램 과 프런트 엔드 를 분리 하 고 해당 부분 을 복수 로 여러 코어 여러 머신 에 뜨 워 서 부하 를 견디 고 다중 코어 도 잘 쓰 잖 거 죠 . 왜 겨우 단일 머신 단일 웹 서버 얘기 인지 모르 겠 네요 . 
 2011 - 06 - 12 at 6 : 56 pm 
 그게 아닙니다 . 순서 가 바뀌 지 않 았 느냐는 것 입니다 . HA 를 누가 단일 머신 으로 구성 합니까 ? 당연히 여러 머신 으로 묶 는 것 이 지요 . 제 얘기 는 HA 구성 전이 라 하 더라도 Local Optimization 이 선행 되 어야 한다는 요지 이 고 , HA 를 구성 한다 하 더라도 결국 확장 성 면 에서 좀 더 좋 아 졌 을 뿐 단일 요청 에 대한 처리 는 결국 한 머신 에서 이루어집니다 . 그러 니 ‘ 비동기 ’ 가 됐 던 , Thread Pool 이 되 었 건 좀 더 나 은 throughput 을 내 기 위한 방안 을 찾 아야 한다는 것 이 지요 . 
 제 가 글 을 잘 못 쓰 나요 ? HA 하 면 당연히 멀티 머신 이 라 얘기 한 건데 , 문맥 상 뛰어넘 은 부분 이 있 나 보 군요 . 
 2011 - 06 - 13 at 9 : 07 am 
 왜 local - optimum 을 찾아가 는 ‘ 헛 수고 ’ 를 해야 하 는 거 죠 ? 대부분 의 경우 “ 전체 시스템 ” 에서 최 적점 을 찾 으면 local - optimum 을 찾 는 데 들어간 수고 중 상당 부분 은 ‘ 헛 수고 ’ 로 끝납니다 . 
 복수 의 머신 , 복수 의 코어 , 이 모든 걸 활용 하 기 위한 구조 를 짜내 면 버그 내 기 도 쉽 고 , 대부분 의 프로그래머 에게 그다지 일상 적 이 지 않 을 다중 스레드 프로그래밍 을 강요 할 이유 가 없 습니다 . 
 달리 나 음 님 이 말씀 하 신 것 처럼 왜 IIS + . net thread pool 이 라는 기괴 한 구조 에 집착 하 시 는 건지요 ? 
 현존 하 는 대부분 의 horizotal - scaling 하 는 아키 텍 쳐 는 , 
 * 직접 연결 을 받 는 가벼운 웹 서버 ( 프런트 엔드 웹 서버 ) 
 * 어떤 의미 있 는 연산 을 하 는 웹 응용 프로그램 과 , 그 응용 프로그램 을 실행 하 는 웹 응용 프로그램 컨테이너 ( IIS 는 그 무게 때문 에 역할 은 이 기능 이상 을 할 수 가 없 습니다 ) 
 * 이 사이 의 연결 을 처리 하 는 로드 밸 런 서 와 리버스 프락시 들 
 * 전체 시스템 에서 메시지 교환 을 위한 메시지 큐 ( MQ ) 혹은 인 메모리 자료 구조 ( Redis ? ) 
 * 이 시스템 에서 사용 하 는 데이터 가 유지 되 는 데이터베이스 와 이 데이터베이스 들 의 샤드 , 밸 런 서 , 슬레이브 머신 들 … 
 이렇게 계층 적 이 고 / 잘 분리 된 인터페이스 를 사용 합니다 . 그런데 왜 겨우 응용 프로그램 컨테이너 하나 에 집착 해서 스레드 풀 , 비동기 처리 , 다중 스레드 프로그래밍 을 해야 할까요 ? 
 2011 - 06 - 13 at 12 : 41 pm 
 멀티 프로세스 로 horizontal scaling 할 수 있 는 구조 라면 멀티 쓰레드 를 이용 한 최적화 를 해 준다고 한들 그 로 인한 성능 이득 은 상수 수준 에 그친다고 봐야 할 겁니다 . 특히 나 지금 같이 개별 머신 에 올라가 는 코어 숫자 가 한 자리 인 상태 에서 는 요 . 이 정도 는 머신 을 더 들이 면 되 는 일 인 거 고 , 개인 적 으로 병렬 프로그래밍 에 통달 한 개발자 를 구인 하 는 데 드 는 비용 보단 이 비용 이 더 저렴 할 것 은 확실 하 다고 보 고 있 습니다 . 
 2011 - 06 - 13 at 8 : 47 am 
 윈도우즈 를 제외 한 운영 체제 라면 프로세스 생성 비용 과 쓰레드 생성 비용 이 극단 적 인 차이 를 보이 지 않 습니다 . ( 이미 아 시 겠 지만 ) 윈도우즈 는 프로세스 생성 이 느린 운영 체제 중 하나 지요 . 그리고 쓰레드 당 사용 할 수 있 는 메모리 양 의 제약 때문 에 하나 의 쓰레드 가 할 수 있 는 일 은 단순 한 모양 을 가지 게 되 고요 . 쓰레드 를 이용 한 프로그래밍 은 일반 적 으로 훨씬 어렵 습니다 . 또 다중 머신 으로 확장 할 때 개념 적 으로 일관 성 을 가지 기 어렵 고요 . 멀티 프로세스 만 생각 하 는 게 비용 의 차이 가 크 지 않 고 , 더 유연 하 고 , 더 쉽 다면 왜 멀티 쓰레드 를 고집 해야 할까요 ? ASP . NET 밖 의 세상 에서 는 멀티 쓰레드 를 쓰 지 않 으면서 몇 년 전 보다 더 높 은 응답 을 보여 주 고 있 습니다 . 멀티 프로세스 로 구축 을 하 고 멀티 하드웨어 로 나가 는 게 답 이 라고 봅니다 . 
 2011 - 06 - 13 at 3 : 37 pm 
 네 난이도 에 대한 의견 과 비용 에 대한 의견 에 는 동의 합니다 . 전체 적 인 방향 도 동의 하 지 않 는 바 가 아닙니다 . ASP . NET 을 예 를 들 었 다고 그것 밖에 세상 이 없 는 건 아니 죠 . ASP . NET 조 차 도 한 머신 에서 멀티 프로세스 로 움직일 수 있 습니다 . 더 좋 은 성능 을 보여 줍니다 . 다만 Cache 와 같 은 부분 은 따로 빼 야 합니다 . 근데 , 그런 부분 에 대한 이해 나 비용 발생 없이 단순히 H / W 투입 만 으로 해결 되 지 는 않 는다는 뜻 입니다 . 
 계속 멀티 프로세스 에 대해 읽 다 보 니 차라리 GRID 가 가장 좋 은 해법 이 라고 생각 되 네요 … 
 2011 - 06 - 13 at 3 : 41 pm 
 local - optimazation 말 을 했 을 때 예상 했 습니다 . 총비용 이 요 ? 누가 지불 합니까 ? 지불 할 사람 이 지불 할 용의 가 있 는지요 ? 실현 가능 한 지요 ? 
 1 . 최적 의 해 가 바로 앞 에 있 지만 , 절대 손 에 쥐 지 못하 는 경우 도 있 습니다 . 
 2 . 그 경우 에 만 최적 의 해 라고 한다면 요 ? 
 3 . 그 경우 의 최적 의 해 를 다른 사람 들 이 오용 해서 다른 경우 에 적용 하 려고 할 때 에 는 요 ? 
 그래서 멀티 프로세스 도 중요 하 지만 , local - optimization 이 라기 보다 기본기 차원 에서 멀티 스레드 나 비동기 프로그래밍 은 해 줘야 한다는 것 입니다 . 
 그래야 여러 해법 중 에 선택 을 할 수 있 죠 . 
 2011 - 06 - 13 at 7 : 26 pm 
 이 글 의 논지 는 “ 멀티 스레드 프로그래밍 을 하 지 말 아라 ” 가 아니 라 다중 코어 활용 을 위한 방법 은 여러 가지 가 있 고 , 현재 많이 사용 되 고 , 그 안정 성 / 활용 도 가 높이 평가 되 는 방법 에 대해 “ 알리 는 것 ” 입니다 . 
 대체 왜 계속 다중 스레드 프로그래밍 에 관한 얘기 를 하 시 는지요 ? 그리고 다중 프로세스 프로그램 은 해당 프로세스 간 통신 을 처리 하 기 위해서 “ 당연히 비동기 프로그래밍 ” 입니다 . 
 그리고 뭔가 “ 다중 스레드 프로그래밍 의 비용 ” 에 대해 매우 간과 하 고 있 는 거 같 은데 , 다중 스레드 프로그래밍 의 유지 / 관리 비용 은 매우 높 습니다 . 
 그나마 쉽 게 쓰 라고 만들 어 놓 은 intel tbb 나 Microsoft ppl 혹은 tpl , 아니 면 omp 같 은 데 서 왜 “ 디버깅 이 힘드 니 싱글 스레드 에서 도나 부터 확인 해라 ” 같 은 얘길할까요 ? 
 업계 에서 수위 에 드 는 엔지니어 들 이 만든 프로젝트 도 , 라이브 서비스 몇 년 씩 지나 도 가끔 레이스 컨디션 등 으로 인해 해묵 은 버그 가 드러나 곤 합니다 . 심지어 일부 경우 를 제외 하 고 는 regression test 를 만들 수 도 없 는 버그 들 이 죠 . 이런 문제 들 은 다 생각 하 고 그 “ 총비용 ” 을 계산 하 면 다중 스레드 프로그래밍 이 더 나 은 해법 인 경우 는 꽤 나 한정 적 일 겁니다 . 
 2011 - 06 - 11 at 5 : 08 pm 
 2011 - 06 - 12 at 3 : 44 pm 
 좀 더 직설 적 으로 얘기 한다면 업계 에서 말 하 는 “ 무식 하 면서 도 간단 한 ” 방법 을 말 하 는 건가요 ? 
 그렇 다면 더 이상 논의 할 게 없 네요 ^^ 
 2011 - 06 - 12 at 6 : 03 pm 
 업계 에서 말 하 는 건 , 그리고 소프트웨어 공학 에서 말 하 는 건 적재적소 겠 죠 . 
 모든 곳 에서 , 그리고 대부분 의 프로그래머 가 병렬 프로그래밍 을 배울 필요 는 없 겠 죠 . 오히려 현재 의 복수 머신 을 쓰 는 환경 을 생각 하 면 분산 프로그래밍 을 알 면 좋 기야 하 겠 군요 . 
 겨우 단일 머신 스케일링 만 논하 시 려는 거 같 으니 확실히 더 얘기 할 게 없 긴 하 겠 군요 . 
 2011 - 06 - 12 at 7 : 02 pm 
 네 모든 개발자 가 멀티 코어 자체 도 이해 할 필요 는 없 겠 죠 . 다만 좀 더 나 은 개발자 가 되 고자 한다면 , 적재적소 – 최적 의 해법 또는 공학 적 타협 – 라 하 더라도 , 큰 개념 에서 이 고 , 
 제 가 이 글 을 반대 하 거나 따 지 하 는 게 아니 라 , 어떤 사람 ( 저 가 개발자 를 색안경 끼 고 보 는 것 처럼 느끼 셨 죠 ? ) 같 은 경우 , “ 최적 해법 ” 을 핑계 삼 아 , 모자라 는 부분 을 채우 지 않 는 부분 을 경계 하 고자 하 는 뜻 이 있 었 습니다 . 
 그리고 H / W 로 해결 하 는 방안 이 야 말 로 Architecture 가 정하 고 , 많 은 비용 이 수반 되 는 결정 사항 이 므로 , 개발자 로서 는 제어 할 수 없 는 부분 이 니 , 개발자 들 은 자신 들 이 제어 할 수 있 는 부분 에서 더 많 은 효과 와 효율 을 찾 을 수 있 는 방안 을 찾 자 . 그게 현재 는 비동기 / 병렬 프로그래밍 이 아닌가 ? 하 는 얘기 입니다 . 
 2011 - 06 - 13 at 9 : 09 am 
 지금 디 밥 님 이 지속 적 으로 주장 하 는 내용 은 , 
 “ 많 은 개발자 들 이 최적 해법 이 아니 란 이유 로 다중 스레드 프로그래밍 등 모자라 는 부분 을 채우 지 않 는다 ” 
 라는 것 같 습니다 . 
 그렇지만 제 가 보 기 에 는 디 밥 님 이 
 “ 큰 그림 을 보 고 , 그 에 따라 프로그래머 들 이 쉽 고 생산 성 높 게 일 할 수 있 게 하 라 ” 
 라는 소프트웨어 공학 의 관점 을 무시 하 는 걸로 밖 에 안 보입니다 . 
 2011 - 06 - 13 at 3 : 29 pm 
 제 본 뜻 은 “ 모든 문제 가 하나 의 해법 으로 해결 되 지 않 는다 ” , 그리고 여러 가지 변수 에 의해 옳 다고 생각 했 던 해법 또한 변할 수 있 다 라고 생각 합니다 . 
 rein 님 이 총비용 으로 전체 적 인 최적화 를 멀티 프로세스 로 해결 볼 수 있 다고 했 지만 , 그것 도 제한 된 경우 가 아니 냐는 겁니다 . 
 일례 로 Shopfloor Controller 의 경우 많 은 처리 량 을 수용 하 기 위해 필수 적 으로 멀티 스레드 와 비동기 기법 이 필요 합니다 . 
 특정 case 에 대해 이런 해법 이 있 다 . 좋 습니다 . 그런데 , 그 case 에 맞 지 도 않 는데 , 그 해법 을 드리 미 는 사람 들 이 있 다는 얘기 입니다 . 
 즉 제 논지 의 핵심 은 “ 해법 의 오용 ” 에 있 다는 것 입니다 . 
 모든 개발자 가 Architecture 는 아니 죠 . 이건 인건비 ( MM ) 를 제외 한 비용 ( 고객 이 피 같이 아끼 는 ) 에 대한 결정 권한 이 개발자 에게 없 다는 뜻 입니다 . 
 2011 - 06 - 13 at 7 : 24 pm 
 위 에 도 써 뒀 듯이 . 이 글 을 다시 읽 어 주 시 기 바랍니다 . 
 다중 코어 활용 을 위해 다중 스레드 만 주장 하 면 안 된다 라는 요지 를 읽 어 주 시 기 바랍니다 . 
 그리고 당연히 일부 개발자 는 아키 텍 쳐 입니다 . 
 그리고 계속 논지 를 “ 다중 스레드 프로그래밍 을 배워야 한다 ” 라고 만 가지 고 가 시 는데 , 이 글 의 논지 와 ‘ 무관 ’ 합니다 . 그 논지 로 더 이상 여기 에 댓글 안 다셨 으면 합니다 . 
 조명현 says : 
 2011 - 06 - 14 at 6 : 11 pm 
 글쓴이 께서 방점 을 찍 기 를 원하 시 는 글 에 댓글 을 남겨서 죄송 하 게 생각 하 지만 , 두 분 의 의견 이 모두 유용 한 의견 임 에 도 불구 하 고 사소 한 토론 상 의 오류 로 인해 오해 만 남기 고 끝나 는 것 같 아 실례 를 무릅쓰 고 한 마디 적 겠 습니다 . 
 글쓴이 께서 댓글 에 이 글 의 논지 로 정리 해 주 신 다음 사항 중 
 1 . 멀티 코어 하드웨어 를 활용 하 기 위해 반드시 비동기 / 병렬 프로그래밍 을 해야 하 는가 ? 
 2 . 상호 독립 적 인 비슷 한 일 이 많 다면 복수 의 독립 적 인 프로세스 를 실행 하 는 것 이 더 좋 다 . 
 2 번 은 제 가 생각 할 때 오해 의 소지 가 전혀 없 는 옳 은 말씀 으로 쓰레드 에서 도 아무 이견 이 없 는 것 같 습니다 . 
 문제 는 1 번 인 것 같 은데 , “ 반드시 ” 라는 데 초점 을 맞춰 한마디 로 대답 을 한다면 No 입니다 . 2 번 이 맞 는 얘기 이 니까요 . 
 하지만 법률 문서 를 다루 듯 토씨 하나하나 에 맞춰서 비평 을 비판 할 필요 또한 없 을 것 같 습니다 . 디 밥 님 께서 말씀 하 고 싶 으셨던 것 은 멀티 쓰레 딩 이 ‘ 반드시 ’ 필요 한 것 은 아니 지만 , “ 필요 한 경우 가 분명 존재 한다 ” 는 것 입니다 . 그런 경우 가 많 으냐 적 으냐 라는 부분 에 있 어서 는 개인 적 인 경험 과 의견 에 의해 입장 이 크 게 달라지 겠 습니다만 . 
 글쓴이 께서 이 “ 필요 한 경우 가 분명 존재 한다 ” 라는 것 을 충분히 인지 하 고 계시 다는 것 은 , 글 을 유심히 읽 어 보 면 충분히 알 수 있 습니다 . 그렇 기 때문 에 어쩌면 디 밥 님 께서 그런 댓글 을 다시 는 것 이 글쓴이 의 의도 를 충분히 파악 하 지 못한 일 이 라고 할 수 도 있 을 것 입니다 . 특히 , ‘ 멀티 쓰레 딩 이 익숙 하 지 않 기 때문 에 멀티 쓰레 딩 을 사용 하 지 않 는 것 은 문제 ’ 라는 부분 은 , 실제로 이 글 의 논지 와 동떨어진 감 이 있 고 , 특히 이런 맥락 의 글 을 쓰 신 글쓴이 를 정당 한 근거 없이 직접 적 으로 비판 하 는 것 으로 비춰질 수 도 있 다고 봅니다 . 
 하지만 , 글쓴이 께서 도 디 밥 님 의 댓글 의 의도 를 좀 더 넓 은 시야 에서 파악 할 수 도 있 는 것 같 습니다 . 올려 주 신 글 을 “ 엄밀히 ” 따져 보 면 글쓴이 께서 특정 한 경우 에 멀티 쓰레 딩 이 필요 하 다는 것 에 동의 하 는 것 을 알 수 있 지만 , 솔직히 말씀 드려 제 가 글 을 다 읽 고 난 뒤 에 남 는 ‘ 뉘앙스 ’ 는 멀티 쓰레 딩 은 쓸모없 다 라는 극단 적 인 쪽 에 가까운 것 같 았 습니다 . 물론 글 을 자세히 읽 어 보 면 그런 뜻 이 아니 시 라는 것 을 알 수 있 지만 , 디 밥 님 께서 글쓴이 께 드리 는 말씀 이 아니 라 이 글 을 읽 는 다른 독자 들 을 위해서 라도 멀티 쓰레 딩 이 필요 한 경우 가 있 다는 말 을 남겨 두 고 싶 으셨던 것 도 이해 가 갑니다 . 댓글 이 설령 글쓴이 에게 전달 되 기 엔 적절 치 않 더라고 , 글 을 읽 는 다른 독자 들 에게 어떤 도움 이 된다면 인터넷 상 에서 글 자체 의 가치 를 높이 는 데 에 도 더 도움 이 되 지 않 을까 생각 해 봅니다 . 
 실로 주제넘 은 댓글 을 남기 는 것 에 대하 여 두 분 께 모두 사과드리 고 , 제 가 오해 하 거나 잘못 생각 한 부분 이 있 다면 꼭 알려 주 시 면 겸허히 받아들이 겠 습니다 . 
 2011 - 06 - 14 at 8 : 10 pm 
 좋 은 마무리 라고 생각 합니다 . 
 황동 성 says : 
 2011 - 06 - 29 at 7 : 09 pm 
 서버 프로그램 입장 에서 는 필장 의 의견 에 적극 동의 합니다 . 
 하지만 클라이언트 프로그램 은 사정 이 다릅니다 . 
 가령 넥서스 S 로 네이버 에 들어가 면 데스크 탑 보다 3 배 이상 오래 걸립니다 . 
 네트워크 속도 는 여전히 기하급수 적 으로 빨라 지 지만 싱글 코어 의 스피드 는 따라 주 지 않 으면서 점차 클라이언트 프로그램 은 CPU 바운드 에 병목 이 걸리 는 방향 으로 가 고 있 습니다 . 
 하지만 브라우저 나 게임 엔진 등 의 클라이언트 프로그램 은 정형 화 된 테스 크 가 없 어 멀티 코어 를 최대한 활용 하 게 프로그래밍 을 하 는 것 이 너무나 어렵 습니다 . 
 OMP , TBB , PPP , OpenCL 등 의 최근 뜨 고 있 는 싱글 스 래드 프로그램 을 병렬 화 시키 는 방법 들 은 클라이언트 프로그램 때문 일 것 입니다 . 
 2011 - 06 - 29 at 8 : 22 pm 
 네 클라이언트 프로그램 은 사정 이 많이 다르 죠 . 서버 는 많 은 경우 “ 잘 정의 된 반복 단위 ” 가 있 어서 상대 적 으로 최근 뜨 고 있 는 트렌드 가 빗겨 갑니다 ( 슬프 게 도 ) . 
 OMP / TBB / PPL / OpenCL / Cilk / … 등 최근 나온 혹은 각광 받 는 방법 들 이 클라이언트 프로그램 에 요긴 하 게 사용 될 곳 이 많 다는 점 에 는 저 도 적극 동의 합니다 . 더 쉽 고 활용 하 기 편한 방법 도 많이 기대 하 고 있 고요 . 
 우주 괴물 says : 
 2011 - 07 - 21 at 3 : 34 pm 
 저 도 TBB 를 Core 활용 을 높이 는데 보 다는 Thread Programming 을 쉽 고 코드 를 단순 하 게 하 는 데 쓰 고 있 습니다 . 
 솔직히 잘못 짜여진 쓰레드 프로그램 은 싱글 보다 훨씬 느리 고 디버깅 도 힘듭니다 . 
 lock / unlock 이 심해 지 고 컨 텐션 이 발생 하 는 부분 이 라면 single thread 로 바꾸 고 프로세스 여러 개 띄우 는 게 더 좋 을 수 있 습니다 . 
 2011 - 08 - 03 at 11 : 15 pm 
 넵 저 도 그렇 습니다 . TBB 의 워커 모델 을 살리 기 엔 이미 병렬 프로그램 인 녀석 들 은 좀 무리 지요 . 물론 할 당자 나 컨테이너 들 은 즐겁 게 쓰 오 있 습니다 : ) 
 싱글 스레드 에서 디버깅 불 가능 한 녀석 들 은 멀티 스레드 에선 ( … ) 인걸 생각 하 면 … ( … )