이 기종 언어로 작성된 프로그램 사이의 통신 수단은 어떤게 괜찮은가요?

요즘은 웹 서비스가 대세죠. 대세가 꼭 좋은 건 아니지만 호환성, 편의성 등을 따지면 웹 서비스가 괜찮은 선택입니다. 대부분의 언어에 이미 오픈된 라이브러리들이 있기도 하구요.

머, 웹서비스가 TCP/IP 레이어를 직접 사용하는 것에 비하면 당근 느리겠지만 덩치가 거대하다는 말은 좀 오버인 것 같습니다. 라이브러리 자체도 거대하지 않거니와 실제로 엔터프라이즈에서 높은 scalability를 요하는 환경에서도 널리 쓰이고 있으므로 속도 문제도 별로 크지 않다고 할 수 있죠. 아파치 정도의 퍼포먼스는 충분히 보장 받을 수 있습니다.

사실 이런 선택은 요구사항에 따라 좌우됩니다. 만약 게임처럼 작은 데이터가 쉴새 없이 왔다갔다 해야하는 경우라면 웹 서비스는 적합하지 않습니다. 한 번에 오가는 데이터가 적다면 상대적으로 웹서비스를 위한 부가 데이터들이 큰 오버헤드가 되니까요. 하지만 엔터프라이즈 애플리케이션이라면 여러모로 웹서비스가 좋습니다. 데이터의 구조가 복잡할수록, 많은 애플리케이션이 엮일수록 웹서비스가 좋다고 할 수 있겠습니다.

소켓 통신을 생각할 수 있는 상황이라면 시리얼 통신이나 UART는 고려하지 않아도 될 것 같군요.

웹서비스는 정의하는 사람에 따라 달라지기도 하지만 쉽게 이해하려면 SOAP를 이용한 XML 메시지 통신이라고 보시면 됩니다. API 입장에서는 원격 메소드를 호출하는 것과 유사하게 통신을 할 수 있기 때문에 소켓 통신처럼 자체적으로 프로토콜 정의하고 문자열 처리하는 수고를 할 필요가 없죠.

http://ws.apache.org/

여기 가시면 오픈소스 구현체들을 볼 수 있습니다.

메이저 Java IDE에서 웹 서비스 자동화는 아주 잘 지원하고 있지만 MQ를 제대로 지원하는 경우는 그리 많이 못 봤습니다. 올초의 자바 컨퍼런스, 썬 테크 데이에서도 웹 서비스는 중요한 화두 중 하나였지만 MQ는 한 번 정도 나왔구요. 서점에 가도 웹 서비스 책 숫자가 MQ 책 숫자의 다섯 배는 넘을 겁니다. 이클립스 플러그인도 Web Service는 별도의 카테고리로 27개의 플러그인이 있지만 MQ는 하나 있는지도 잘 모르겠습니다. 구글 검색 결과도 웹서비스가 압도적으로 많고 여러 IT 관련 사이트에서도 웹서비스 관련 기사는 수도 없이 찾을 수 있는 반면 MQ 관련 기사는 찾기 쉽지 않습니다.

구체적인 사례를 봐도 정부 부문 SI에서는 웹서비스가 상당히 일반화되어서 SI 개발자를 괴롭히는 "연동"문제는 요즘 웹서비스로 풀고 있는 추세입니다.

MQ 쪽에는 어떤 근거들이 있나요?

사실 제가 좀 삐딱하게 나간 것 같은데 제가 바라는 것은 통계적 근거가 필요한 내용에 대해 자신의 경험 안에서 판단한 내용을 주장하지 말았으면 좋겠다는 것입니다. 웹서비스가 더 일반적으로 쓰이느냐 MQ가 더 일반적으로 쓰이느냐에 대한 결론은 오직 통계자료만이 내려줄 수 있는 문제인데 atie님이 제시하신 근거들은 MQ가 널리 쓰인다를 어느 정도 뒷받침할 수 있을지는 몰라도 "웹서비스보다 널리 쓰임"을 뒷받침할 수는 없습니다.

물론 제가 제시한 근거들도 확정 근거는 아닙니다. 통계자료 없이 확정 근거는 불가능하므로 증거쌓기를 통해 신뢰성을 높이고자 한 거이죠. 책 숫자, 구글 검색, 지원 도구의 숫자 등은 레퍼런스 사이트 통계만큼 확정 근거는 아니지만 여러 개가 쌓임으로써 확정 근거에 근접할 수 있죠. 하지만 atie님의 근거는 단편적인 사례에 불과합니다. 게다가 그 단편적인 사례도 설득력을 얻기 힘든 것이 말씀하신 기업들의 웹사이트에 가도 웹서비스 관련 문서가 훨씬 많고 웹서비스 관련 제품군을 더 많이 광고하고 있습니다.

사실 이처럼 정량적, 혹은 통계적인 근거가 필요한 주장을 하면서 그런 근거가 필요하다는 사실을 깨닫지 못하고 단편적인 근거만을 제시하는 일이 kldp에서 의외로 많이 나옵니다. atie님 정도 되는 분이면 그런 실수는 충분히 피해갈 수 있지 않을까요.

한 가지 더 첨언하자면 MQ는 웹서비스와 용도가 좀 다르죠. 웹서비스의 용도는 딱 이 글의 주제처럼 다양한 구성의 애플리케이션 사이의 통신이라면 MQ는 신뢰성 높은 transaction 처리죠. MQ는 작업이 좀더 heavy load이면서 즉각적인 응답의 필요성이 적은 경우에 쓰입니다. 웹서비스는 HTTP와 비슷한 응답시간이면 충분하구요. 이보다 더 응답시간이 빨라야 하는 경우는 역시 소켓 통신으로 가겠죠.

MQ가 웹서비스보다 "더 널리" 쓰인다는 주장을 뒷받침하려면 당연히 MQ에 관한 통계와 웹서비스에 대한 통계의 비교가 이루어져야 하는 것 아닌가요? 한쪽에 대한 이야기, 그것도 통계는 전혀 없이 몇몇 기업에서 지원하고 있다는 언급만 한다면 단편적인 근거죠. MQ를 IBM, MS 등이 지원하고 있다는 말이 MQ가 웹서비스보다 널리 쓰인다는 말을 뒷받침할 수 있다고 생각하시나요?

말씀하신 WAS들 역시 마찬가지입니다. MQ 뿐 아니라 웹서비스도 같이 잘 지원하고 있는 것들이죠. 마찬가지로 MQ가 웹서비스보다 더 널리 쓰인다는 근거는 되지 못합니다.

지금 상황을 비유를 들어보자면 이렇습니다.
A : 한국 사람은 짜장면을 짬뽕보다 더 좋아해!
B : 근거를 대봐!
A : 중국집1도 짜장면을 팔고 중국집2도 짜장면을 팔아.
B : 중국집1은 짬뽕도 같이 팔잖아. 오히려 짬뽕을 더 많이 미는 거 같던데? 중국집1에서 짜장면 짬뽕 매출 비율이 어떤지 알아?
A : 중국집1은 10년 전부터 짜장면 팔았어.
B : 그리고 세상에 중국집이 중국집1, 2밖에 없냐?
A : 앞으로 5년 후면 대부분 면요리를 많이 먹을 꺼래.

좀 과격하게 느끼실지 모르겠지만 atie님의 주장을 1:1로 대응시킬 수 있는 비유라고 생각해서 들었습니다. 혹시 적절치 않은 부분이 있다면 지적해주시기 바랍니다.

하나 더 첨언하자면, 혹시 MQ의 유용성을 말하고 싶은 거라면 전 거기에 전혀 이의를 제기할 생각이 없습니다. 전 JMS implementation 개발에도 참여해보았고 MQ를 이용한 애플리케이션도 개발해본 경험이 있어 MQ의 유용성에 대해서라면 충분히 공감합니다. 하지만 웹서비스보다 MQ가 널리 쓰인다는 주장이 가능하려면 최소한 하나라도 비교할 수 있는 근거가 필요하다는 얘깁니다. 그런 의미에서 비교 없이 한쪽에 대한 사례만 제시한 atie님의 근거가 단편적이라고 한 것이구요.

그리고, 제가 다음의 인용을 모르고 있다고 생각하시는 것은 아니겠죠?

짜장면, 짬뽕 건은 제가 그렇게 이야기 한 적이 없으니 언급을 하지 않겠습니다. 저는 "엔터프라이즈 어플리케이션"이라는 단서를 위에 달았고, 기업의 폐쇄적인 환경을 보호하는 기술적 추세는 웹서비스를 포함하거나 또는 웹서비스가 없이 SOA 구축하자는 것이 업계의 주장입니다.

저는 이 글타래에서는 여기까지만 하겠습니다. creativeidler님이 관련된 다른 주제로 글을 여시면 거기에는 참여를 해 보겠습니다.

제 분야가 공장자동화쪽이라서 인지는 몰라도,
제 기준엔 웹서비스는 충분히 거대합니다.

4M Flash 하드를 가진 16M 메모리를 가진 임베디드에서 돌아가는 통신을
구축해야하는 경우도 비일비재하니깐요...
더 열악한 경우도 많죠...

저에게 있어서
"물리적으로 다른 기계에서 돌고 있고, 또 다른 종류의 프로그래밍 언어로 작성된 프로그램들이 있다고 가정합니다. 이 둘사이에 통신을 해야 할 때, 괜찮은 수단은 뭐가 있나요? "의 기준으로 볼때,
마이콤이나, PLC가 주류인 저희쪽 입장에선 TCP/IP도 덩치가 큰편인데,
XML파싱이 필요하는 웹서비스는 매우(? 어쩌면 가장) 사치스럽고 덩치가 크게 보입니다. :wink:

자바 컨퍼런스, 썬 테크 데이에서 JMS 관련 얘기가 얼마나 있었는지, 그리고 웹 서비스 이야기가 얼마나 있었는지 비교해 보시기 바랍니다. 웹서비스가 압도적으로 많다는 것을 아시게 될 겁니다.

MQ에 대한 책자를 해당사의 웹사이트에서 찾을 수 있다면 전세계에 출판된 웹서비스 책 숫자와 MQ의 책 숫자로 비교를 해봐도 좋습니다. MQ 책 숫자가 웹서비스책 숫자 반이라도 될지 의문입니다. 물론 JMS책, MQ책 합쳐서 세도 좋습니다.

IBM 메세지 브로커, MS의 비즈토크 이야기는 역시나 웹서비스도 같이 지원하는 제품이기에 역시나 비교에는 도움이 안됩니다.
구글에서 MQ 또는 JMS로 검색한 결과를 합친 것보다 "Web Service" 하나로 검색한 결과가 두 배 정도 된답니다.

여전히 짜장면이 짬뽕보다 많이 팔린다는 근거로 중국집1에서도 짜장면 팔고 중국집2에서도 짜장면 판다는 얘기들을 하고 있으십니다. 비유가 맘에 안 드시더라도 찬찬히 대응시켜보면 논리적 비약이 어딘지는 아실 수 있을 꺼라 생각합니다만...

질문자의 환경이 어떤지 역시 읽는 사람의 느낌의 차이가 아닌가요?

원문에 분명 PC나 호스트가 아닌 "기계"라는
표현을 사용했기 때문에,
저로서는 충분히 그렇게 생각할 수 있다고 봅니다만...

엄밀히 말해서 질문자의 질문의 내용에서
어떤 환경을 유추하는 것은 무리라고 봅니다.

"물리적으로 다른 기계에서 돌고 있고,
또 다른 종류의 프로그래밍 언어로 작성된 프로그램들이 있다고 가정합니다.
이 둘사이에 통신을 해야 할 때, 괜찮은 수단은 뭐가 있나요?"

저는 윗글에서 제가 개발경험을 가진 통신환경을 모두 나열했고,
단연코 프로토콜 중에서는 웹서비스가 가장 무거운 편에
속하는 것은 사실이죠.

그리고 전혀 유추할 수 없는 것은 아니었죠. 적어도 두 가지 힌트는 있었으니까요. 제 추리가 맞을지 아닐지는 아직 모르지만요.

저는 soap 보다는 rest 쪽이 더 유망하다고 생각합니다. 소위 web 2.0이라고 불리는 서비스에서 rest에 더 친화적이거든요.

그리고 근거없는 편견인지 모르겠지만 soap보다는 rest가 더 가벼운 것 같습니다.