ACE 쓸만 하신가요?

ixevexi의 이미지
ixevexi의 이미지

몇일전 거금을 털어 책을 몇권샀는데
C++을 좋아하다 보니 ACE에대한 극찬??이 많이 들려
유명한 " C++ network programming (ACE를 이용한~~)"을
사게되었습니다.

의외로 쉽게 읽히더라구요. 지금껏 제가 사보았던 C++책들은
항상 먼가 challenge하게 만드는 마력-_-;;이 있었는데
소켓프로그래밍에 대한 경험때문인지 난이도는 높지 않았습니다.

하지만 이와는 별개로 책을 보면 볼 수록 이것이 과연 쓸만한 프레임
워크인가에 대해서는 의문점이 나더군요. ACE쪽에서는 다음과 같은
이유를 들어 ACE의 장점을 설명합니다.

1. 객체지향?적인 관점으로 기존의 사용자의 실수를 줄인다
2. 대부분의 OS(RTOS를 포함)로 소스코드 호환이 가능하다

저게 경험이 적고 ACE에 대한 이해가 부족하여 그런지 저는
위의 두 개의 장점에 대해 큰 흥미를 못느끼고 있습니다.

첫번째로 사용자의 실수를 줄이는 부분은 분명 그러한 부분이 있기 마련입니다.
그러나 그것때문에 사용자가 ACE api를 익히는 것은 부족합니다.
또한 제가 볼때는 ACE를 쓴다하더라도 실수할 여지가 다분히
많은 코드역시 ACE는 가지고 있다고 생각합니다.
(코드를 많이 보지 못해 확신하지 못하지만 적어도 책의 예제에서 조차 제가 볼때 어? 라고 생각되는 부분들이 있습니다.)
과연 ACE의 이런 컴파일타임 체크에 대한 이점이 어느정도나 될지 궁금합니다.

두번째로 ACE의 포터빌리티에 관한 것인데
이 포터빌리티는 분명한 장점입니다. 그러나 과연 이를 이유로 인해
자칫 무거워 질 수 있는(이것에 대한 것은 확신이 들지 않지만
적어도 ACE자체가 거대. 하다고 생각하므로 이런 표현을 썼습니다)
ACE를 여러가지 OS로 포팅할 만한 장점이 되느냐 입니다.

왜 이런 이야기를 쓰냐면 보통 포터빌리티에서 PC급에서 쓰이는
*nix계열은 posix를 나름대로 준수하고있다고 생각합니다.
(제가 주로 linux에서 작업을 해서 정확히는 모릅니다 )
이런 이식성이 문제가 되는것은 주로 열악한 라이브러리를 가지는
소형 임베이디드용 RTOS등이 문제가 될 듯 한데,
소형에는 안맞는 덩치큰 ACE가 될지 않을까 생각해서 입니다.
Win32와의 호환을 생각한다면 매력적이긴 합니다.

세번째로 래퍼함수이기 때문에 성능의 문제가 걸리지 않나 생각하는데요
아무리 inline화 하고 여러가지 테크닉을 써도 어느정도 숙력된!
사용자가 아니라면 그냥 api를 부르는것 보다는 성능의 하략이
없을 수 없다고 생각합니다. 특히 성능에 critical한 임베이디드용
장비 (예를 들어 VPN이나 방화벽..)에 미들웨어로써 들어가게 될때
그만한 성능의 하략이 얼마나 되는지 사실 궁금하기도 하고
하략이 있다 하더라고 적용할 가치가 있는지 더욱 궁금합니다.

사실 C++을 사용하는 사람으로써 ACE가 분명한 장점을 가지고 있습니다.
그러나 그러한 장점이 POSIX API를 버리고 갈만큼인지는 잘 모르겠습니다.
특히 MFC만 봐도 windows api를 모르고 쓰는게 위헙?하다고
생각되는 저로써는 ACE만을 익히고 socket api를 모른다는 것
역시 말이 되지 않다고 생각됩니다. 그렇다면 두개를 다 익혀야하는데
(ACE의 난이도를 떠나) ACE에 투자할(배우고 익숙해질때까지)
가치가 있을까요?

PS 저는 C++을 좋아하지만, 작업한 것도 별로 없고
작업 했더라도 지금껏 C로만 작업을 하게된 터라
C++의 객체지향을 어떻게 적용하나 하는 마음에 두근거리며
ACE를 보았지만 그냥 facade 패턴만을 구현해놓았다고
생각하면 제가 오해한 걸까요? 아니면 그것만으로도 충분히
C++을 살린거다라고 생각해야 할까요?

C++, 그리고 C++....
죽어도 C++

M.W.Park의 이미지

프로젝트에 적용해본 적은 없지만, 한때 조금 공부했었는데요.

어디에서 ACE를 쓰고 있는지 살펴보면 대충 어떻겠다는 것이 짐작되지 않을까요?

http://www.cs.wustl.edu/~schmidt/ACE-users.html

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

happyjun의 이미지

논외로 그 책 정말 마음에 안듭니다. 처음부터 끝까지 올바른 디자인을 했다 하면서 facade 패턴이란 말 밖에 안나옵니다.

솔직히 ACE 프레임워크 자체도 그렇습니다. 이식성이란 이유로 템플릿을 사용하지 않고 있습니다. 매크로도 많이 사용하고 STL, Boost 등도 사용하지 않고 단독적으로 만들어서 사용하고 있습니다.

----------------------------------------
http://moim.at
http://mkhq.co.kr

ixevexi의 이미지

happyjun wrote:
논외로 그 책 정말 마음에 안듭니다. 처음부터 끝까지 올바른 디자인을 했다 하면서 facade 패턴이란 말 밖에 안나옵니다.

솔직히 ACE 프레임워크 자체도 그렇습니다. 이식성이란 이유로 템플릿을 사용하지 않고 있습니다. 매크로도 많이 사용하고 STL, Boost 등도 사용하지 않고 단독적으로 만들어서 사용하고 있습니다.

책이 안좋은 것인가요?
그리고 한글판 보고 있는데
번역이 나쁜건 아니지만 결코 좋은 쪽도 아니더라구요
내장된 OS, 쓰레드가 굶어죽는다... 라는 표현들 -_-;;

C++, 그리고 C++....
죽어도 C++

kihlle의 이미지

발제자님의 첫번째 주제에 대해서 마찬가지 생각입니다.

두번째에 대해서는 최소한 posix표준의 유닉스들끼리의 개발환경은 기본적으로 ACE만큼이나 포터블리티를 갖추고 있다고 생각됩니다.

성능이슈에 대해서는 ACE에서 제공하는 함수개개의 문제라기보다는 ACE를 사용하여 개발하는 패턴 자체가 효율성과는 거리가 먼 패턴으로 접근하게 된다는것이 문제라고 생각됩니다. 게다가 보통 생성되는 동적라이브러리가 10M씩이나 되기 때문에 사실상 사용하기에 무거운 환경들도 존재합니다.

국내의 이동통신사 프로젝트나 서비스업계에서도 ACE는 실무에서 사용하기도 합니다. 어떤분께서 언급하신것처럼 Win32 API에 무지하면서 MFC를 사용하는것만큼이나, posix 표준에 무지하면서 ACE를 사용하는 것은 바람직하지않습니다.

Quote:
솔직히 ACE 프레임워크 자체도 그렇습니다. 이식성이란 이유로 템플릿을 사용하지 않고 있습니다. 매크로도 많이 사용하고 STL, Boost 등도 사용하지 않고 단독적으로 만들어서 사용하고 있습니다.

매크로를 사용하는 것은 별로 욕먹을 이슈는 아니구요.
Firebird 같은 유명한 오픈소스 패키지들을 살펴보시면 vector같은 자료구조를 스스로 구현하며 시스템의 stl에 의존하지 않습니다. 빌드되는 시스템이 stl을 갖고있다거나 그 stl이 (stl의 표준규격같은 것이 있나요?) 제대로 동작할것이라고 확신할수 없습니다.

라이브러리가 템플릿을 사용하지 않는것도 당연한 것입니다.
템플릿 라이브러리는 통상 헤더파일의 형태로만 제공되며, cfront형식 여부와 떠나서 바이너리로 빌드하지 않기 때문입니다. (물론 ACE 내부에서는 사용합니다만)

homeless

doldori의 이미지

kihlle wrote:
stl의 표준규격같은 것이 있나요?

물론이죠. STL은 Standard Template Library의 약자입니다.
C++ 표준에 정의되어 있습니다.
namo의 이미지

STL이 성능 보장에 대한에 대한 준수사항은 있어도 구현에 대한 표준은 없지 않나요?
예로 성능이 O(n)을 보장해야 한다라는 규정은 있어도
'R-B 트리로 구현해야 한다'와 같은 것은 구현자에게 맡기었다라는 것이죠.

모지리의 이미지

남한테 물어 보는거보다는 직접 해보는수밖에 없죠. 그게 정도인것 같습니다. 이거 좋을까요.? 보다는 이부분이 어떨까요라는 질문이 훨씬 근접할수 있을거 같습니다. 이거 좋을까요.? 당그니죠.... 하지만 저는 ACE는 전혀 쓸모없는 프레임웍이다에 투표했습니다.

ACE를 처음 접해본것은 90년대 말에 TOPS와 GLOBEX라는 선물 거래소 시스템을 만들때 처음 접해보았습니다. 당시에는 그것이 ACE에 기반한 시스템이었는데 그 당시에 거래소에서는 여러 시스템에 이식성을 위해 ACE를 채택했는데 얼마 있다가 다른 시스템으로 대체 되었습니다.

제가 본 ACE는 괜한일 한거는 아닌가 하는 생각도 참 많이 했습니다. 실상 ACE에서 이루어지는 많은 일들이 대부분 구현되어 있거나 오픈되어 있는 상태입니다. 지금 싯점에서의 미들웨어도 기술이라기 보다는 비즈니스 로직을 얼마나 많이 포함하고 있는냐가 관건인것 같습니다.

"요즈음에는 시스템들이 하도 빨라저서.." 하는 가정은 사실 예전이나 지금이나 별반 다를거 없어 보입니다. 시스템은 예전에도 빨랐고 지금도 빨라 보입니다. 그리고 미션 크리티컬한 제품이라는 경계도 이젠 별로 없어진것 같습니다. 죄다 미션 크리티컬한것 같습니다.

특히나 방화벽 VPN쪽은 유저 스페이스에서 개발할 부분은 별로 없습니다. 주요한 기능들은 커널쪽에서 핸들이 되고 유저 스페이스는 인터페이스를 하던지 암호화나 뭐 다른 일들을 하지 실상은 커널쪽에서 많이 일어나고 있습니다. 따라서 ACE를 쓴다는거는 별 유효성이 없을듯 싶고 다른 애플리케이션을 개발하는데 있어서도 ACE를 할만한 시간이면 ACE를 설계할수도 있을듯 싶어 보입니다.

제 생각에는 실무에서는 그리 큰 잇점을 발견하기 힘들것 같아 보입니다. 요즈음에는 어떤 라이브러리라는것이 기술을 판매한다기 보다는 비즈니스 로직을 판매 한다고 보는게 더 좋을듯 보입니다.

그리고 저는 매크로를 경멸하기 때문에 매크로 소스를 아주 싫어 합니다. 예나 지금이나 편리성 보다는 남보기 어려운 소스 정도로 치부합니다.

통신 모 그까이꺼 모 있겠습니까.. 걍 열심히 파다 보면 돌이 나오든 물이 나오든 나오겠죠. 특히 지금 싯점에서는 통신 WRAPPER류는 별로.....

똥이네의 이미지

ACE를 사용해서 프로젝트를 진행하는 시점에 첫번째 C++ network programming 나와서는 유일한 레퍼랜스로 활용하였습니다.
책의 구성이 단순의 Doxygen으로 구성된 Document를 번역하는 수준이라
만족스럽지는 않았습니다.

ACE활용부분...
디자인패턴에 대해 나름대로 가지고 있는 노하우가 있어야 사용하는데 있어 아 하는 부분이 있지않나 합니다. 물론 패턴과 친하지 않다고 해도 얻는 부분은 있지만 활용하는데 있어서는 orz이지 않을까 싶습니다. ACE를 사용하는데 있어 비슷한 기능을 수행하는 많은 객체가 구성되어 있고 매크로도 많은데 이는 어떤 패턴으로 시스템을 구성하는냐에 따라 사용할 객체를 선택해야 하는 기로에 서게 됩니다. 즉 패턴에 대한 이해등이 선행되지 않으면 최선의 선택이였는지 수 많은 고민에 쌓이게 됩니다.
너무 폭 넓어 효용성이 의심되기도 하지만 넓기 때문에 효율적으로 사용할 수도 있겠지요.

cronex의 이미지

STL을 직접 구현해서 사용하는 것이 나쁜 것만은 아닙니다.
각 시스템마다 요구하는 성능이 있을 겁니다.
하지만 기본적인 STL은 대부분의 자료구조를 R-B Tree로 구현한 걸로 알고 있습니다. R-B Tree는 대부분의 경우에 대해서 안정적인 속도를 보장해주지만 특정한 상황에 대해서 요구하는 성능이 다를 수도 있습니다.
어떤 경우에는 검색을 엄청나게 많이 해야 하는 경우도 있고 어느 경우에는 자료를 계속 집어넣거나 빼는 작업을 반복적으로 많이 해야 하는 경우도 있을 수도 있죠. 어떤 경우에는 두개의 자료구조를 합치는 작업을 자주 해야 하는 경우도 있습니다. 이러한 특수한 경우에 R-B Tree말고 다른 자료구조를 사용해서 STL을 구현해서 사용하는게 꼭 필요한 경우가 있을 수 있습니다.

(물론 STL 구현을 표준 STL과 다르게 구현하면 문제가 생길 수도 있겠습니다만....;;)
------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!

------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!

in1n4의 이미지

프로젝트 진행시 여러가지 경향을 지닌 프로그래머가 있습니다

1. 지금까지 프로젝트를 진행하면서 쌓아온 자신만의 라이브러리를 만들어서 사용하시는 분
2. 프로젝트마다 노가다(?)로 만들거나 시스템에서 제공하는 클래스를 사용하시는 분

ACE 책에서는 계속 반복적인 이야기만 합니다만 랩음악 듣는다고 생각하시면 됩니다 ㅎㅎ

개발 기간은 정해져있고 견고한 프로그램을 짜고 싶은 건 프로그래머 욕심이지만

맘대로 안되는게 현실이죠..

저의 개인적인 견해로는

socket API를 직접 사용하는건 폰노이만 형님이 주장하는 기계어 수준(?)으로 개발하는 상황이라 보입니다

포트란이 나올 당시 획기적인 내용보다는 그저 단순한 변환기라고 생각했겠죠

socket API 사용한다는게 뭔가 세밀한 세팅으로 인해 대단한 컨트롤을 한다고 생각하실 줄 모르시겠지만

같은 개념으로 본다면 그저 기계어로 프로그램짜는게 정답이겠죠?

랩핑한 클래스가 왜 존재할까? 책까지 왜 나올까? 생각해보시면 간단합니다

전 실무 프로젝트하면서도 절대 개인이 만든 네트웍라이브러리를 신임하지 않습니다

그만큼 견고하게 못짰다는거죠.

socket을 개인마다 라이브러리를 만들 정도로 하위 레벨이라면 그것을 편하게 사용하거나 뭔가 사람의 개념에 맞도록 바꾸기 위해

얼마나 많은 시간과 노력을 했겠습니까?

OS의 socket API는 최소한의 기능 제공이며 그것을 더 좋게 만든 것을 사용하는 것은 프로그래머 몫입니다

개인 적인 견해로는 STL을 사용하듯이 ACE를 사용하면서 좀 더 하위 레벨로 고민하는 시간보다는 전반적인 흐름(로직)에 노력을 더 기울여 보는게 현명하고 생각됩니다

potato53의 이미지

C++는 실무 엔지니어를 위한 생산적인 언어라고 생각합니다.

아마 윗 분들께서 객체지향적인 프로그래밍을 잘모르기 때문에 생긴 오해란 생각이 듭니다.

jejeje8의 이미지

실무에 서보시면 겪게 되실수도 있고, 아닐수도 있는데요.

여러플랫폼에서 동작해야되는 하나의 솔루션을 작성해야 될 때가 발생합니다.

이때 각 플랫폼마다 소스를 작성하고, 유지보수를 하는것은 매우 힘든일입니다.

하면 할수는 있지만 비용(인력, 시간 등)이 많이 발생한다는 뜻입니다.

ACE 를 쓰게되면 하나의 소스를 작성 및 유지보수하면 각 고객사( 다양한 플랫폼)에 하나로 납품할 수 있게됩니다.

즉 비용의 절감이 많이 발생하게 되는거죠... 회사입장에서는 사용할 수 밖에 없습니다.

그리고 socket API 와 ACE 를 둘다 익혀야 되는게 불합리 하다고 하신것 같은데요.

제 생각은 다릅니다.. 내부가 어떻게 구현되어있는지 알고싶은건 이해되지만..

상세구현을 알 필요없이, 쓸수있는게 C++ 장점 아닌가요 ㅎㅎ (ACE 내부구현은 완벽하다고 가정합니다.)

ACE 를 잘 이해하게되면, 코드 생산성이 상당히 높아질 겁니다.

이것 또한 비용절감에 관계가 되겠네요..

그래서 쓰게되는겁니다. ACE 를요..ㅋㅋ 제 짧은 견해였습니다.

ps. 참고로 ACE 내부엔 socket API 만 들어있는건 아닙니다~ IPC, sync/async, 스레드 등 더 들어있어요.

New Generation