rein’s world

삼성 SDS에서 개발한 인캅스(IPCOPS)라는 툴이 있다. 사내 보안용 솔루션의 탈을 쓰고 있지만 설명하는 기능 중 대부분(그것도 가장 중요한 것들)은 사실 상 의미가 없다. 그리고 시스템 사용자에겐 성능, 시스템 관리, 프로그램 개발 차원에서 여러가지 불이익을 안겨주는 프로그램이다. 그런 차원에서 간단히(?) 리뷰를 진행해보겠다.

문제점

많은 수의 개발툴들이 인캅스와 충돌한다. 주위에 이 솔루션(인캅스)를 도입한 회사에 다니는 사람이 있다면 좀 물어봐라. 내가 경험한, 혹은 알고 있는 것들은 이런 것들이다 (그렇지만 아직 해당 회사에 남아있거나 하는 사람이 있으니 직접적인 출처는 여기엔 안 쓰겠다)

• 64bit Windows는 지원되지 않는다. 심지어 도입 초기엔 32bit Vista도 지원안되서 말이 많았다.
  
• IncrediBuild와 충돌한다. 지금은 해결되었는지 모르겠지만 IncrediBuild를 통한 빌드 작업 자체가 진행이 되지 않는 문제를 들었다.
• 빌드 자체가 깨지는 문제가 있다. S 모 전자 — SDS의 최대 고객(?)인 — 를 이미 퇴사한 l모씨(l은 이름 가운데 글자다 :p)의 설명에 따르면 전날 멀쩡히 빌드되던게 다음날 출근해보니 (인캅스가 조용히 업데이트 되어있고) 빌드가 깨지는 현상을 목격. …이런 경우의 디버깅은 말 그대로 공포다.
• USB 암호화 기능을 사용하는데 이게 웃기는게 붓팅된 후에 한 번도 암호화를 해본적이 없으면 복호화도 안된다(…). 조엘의 표현을 빌자면 “코드 한 줄만 수정하면 고쳐지는 버그” 일 것이다.
• 모든 프로세스에 특정 DLL들을 로드해서 붙여놓는다. 무슨 일이 생기냐고? 부하 테스트 용 머신에 프로세스를 3000개 정도 띄울 수 있었는데, 인캅스가 적용되고 나니 1200개 정도가 뜨더라. 당연히 모든 윈도우 서비스들에도 잘 붙어있기 때문에, 시스템이 기본적으로 사용하는 메모리도 늘어나고, 전체적으로 성능도 떨어지게 된다.

이게 “간단한” 문제들이다. 더 무서운 것은 다음 단락.

지원한다는 기능의 헛점

삼성 SDS에서 강조하는 기능들은 크게,

• 등록된 IP를 통해 외부 접속을 로깅한다
• USB 를 통한 파일 쓰기/읽기를 통제한다
• 프린트 서버를 통제해서 인쇄되는 모든 문서에 워터마크를 추가한다

인데, 이 중 마지막 기능을 빼고는 모두 아주 간단한 방법으로 뚫을 수 있다.

계속 읽기: “막장 SW 리뷰: 삼성 SDS의 인캅스” »

전에 작성한 레몬펜 플러그인(LemonPen-Footer) 포스팅에 이런 레몬펜 쪽지가 달렸다.

“single page 일때만 보여주는 이유가 있나요?”

라는 것인데. 플러그인을 제작할 당시만 해도 paging되고있는 페이지 (예를 들어 http://rein.upnl.org/wordpress/page/2)에서와 그냥 직접 포스팅을 접근한 거랑 레몬펜이 구분하질 못했다. 그래서 그냥 한 개의 포스팅이 나올 때만 레몬펜을 사용할 수 있게 설정했었다.

그 이후 오픈마루 스튜디오의 추가적인 작업으로 레몬펜 기능이 강화되었기 때문에, 서로 다른 URI에서 접근해도 같은 내용의 페이지를 인식하게 만들 수 있는 방법이 존재한다. 그런 의미에서(?) 한 개의 포스팅만 나올 때 이외에도 출력할 페이지를 고를 수 있는 옵션 페이지를 추가했다.

옵션 페이지에서 선택할 수 있는 것들은 “개별 포스팅”, “시작 페이지”, “페이지” 를 고를 수 있고, 검색결과로 나오는 웹 페이지(검색 페이지)나 날짜나 월, 년도를 골라서 표시되는 페이지(모두 합쳐서 Archive로 지칭)에서 레몬펜을 사용할지 여부를 결정할 수 있게 했다.

아직 정식으로 릴리즈가 안된 — 그렇지만 3월 중에 릴리즈 될 예정인 — 2.5 버젼의 관리자 모드 CSS를 사용했기 때문에 현재 2.3.x를 쓰는 분들은 좀 안 이쁘게 보일지도 모른다. 그렇지만 곧 저런 모양의 UI로 쓸 수 있게 되니 기다려줍시다

Download : http://rein.upnl.org/archive/lemonpen-footer.zip

(LemonPen-Footer 0.2.0)

ps. 버그 신고나 이런 기능이 있었으면 좋겠다하는 것이 있으시면 댓글로 남겨주세요 ~_~
(사실 위에서 설명한 것 말고도 몇 가지 옵션이 더 가능하지만 추가는 안했습니다. 카테고리나 태그 페이지, 특정 서브페이지(…) 등등 여러가지 조건이 가능합니다)

계속해서 VisualUnitTest++을 사용 중. (이하 VUTPP라고 부르겠음)

내가 이해하는 작동 구조가,

1. Compiler.Preprocessor.Definition 에 특정 값(VUTPP_UNITTEST++)이 있는지 확인하고 있으면,
2. 해당 프로젝트의 파일들을 해석해서 SUITE( ), TEST() 매크로가 있나 확인하고,
3. 전체 테스트를 실행하거나, 선택한 테스트를 실행하면,
4. (빌드가 필요하면 빌드를 하고) VS AddIn으로 떠있던 VUTPP에서 DLL 파일을 링크 & 실행
5. 실행 중에 적절한 callback을 호출해서 결과값을 받음
6. 최종적으로 결과값(성공/실패여부 등등) 표시

인데, 4에 약간의 문제?가 있는 것 같다.

테스트되는 코드가 native C++이라 생기는 어쩔 수 없는 문제에 가까운 것인데.

• VUTPP는 VS AddIn이니 VisualStudio의 프로세스 공간에서 동작한다
• 테스트는 DLL파일을 링크해서 실행되는데 이 것은 VUTPP가 실행하는 것이다
• 테스트되는 DLL안에서 잘못된 메모리를 참조한다거나 하면 VUTPP 사망 → VisualStudio 사망 으로 연쇄 반응(?)

이라는 것. .Net managed code나 python, Java같은 언어에서라면 exception을 처리하는 것만으로 충분할텐데, 실패하면 OS가 직접처리(보통은 프로그램 사망으로 결론)하는 C++은 괴롭구나 Orz
아마 이것 때문에 VUTPP 제작자인 쑥갓님도 “VS자체가 죽을 수 있습니다”라고 써놓으신 것 같은데…

어제 테스트하던 라이브러리에서 지운 메모리를 참조하는 버그가 있어서 좀 괴로웠다(…). UnitTest 돌릴 때마다 VS가 사망…

아마 이런 해결책이 가능하지 않을까싶다. 문제가 되는게 VS AddIn과 믿을 수 없는 테스트될 DLL이 강하게 결합되어 있다라는 것. 이걸 좀 더 약한 결합으로 바꿀 수 있지 않을까?

• 별도의 “실행기”를 만들고, 이걸 command line으로 호출한다. 결과값은 문자열같은 걸로 받아서 VUTPP가 재해석
• 별도의 “실행기”를 만들고, 이걸 socket으로 연결한다(일종의 RPC?). 그리고 결과값을 소켓 통신으로 받아서 VUTPP가 재해석

즉, “별도의 실행기”와 VUTPP를 분리하고 이를 약한 결합인 command line + text나 socket 통신으로 연결해보자는 것

주말에 시간나면 짜볼까? (시간나면보다는 “엄한 일로 시간을 낭비하지 않으면”에 가깝긴하지만…)

오늘 MS 히어로즈 블로그 세미나엘 갔다가 만난 최치선님이 “테스트 주도 개발”을 가져왔길래 잠시 들여다봤다.

예전에 “Test–Driven Development: By Examples”를 읽었던 기억으론 Java를 중심으로 사용하고 JUnit도 나오고 그랬던 것 같다. 근데 왠걸 한국어판 나온 것을보니 Python 예제 코드가 보이더라. (물론 주 언어는 Java고, 책 후반부 패턴 다루기 직전 부분정도부터…)

누구 뭔가 아시는 분? 내가 가지고 있는 책이 2002년에 10월에 출판된 물건이던데. 혹시 이 책이 2판이 있고 그게 번역된건가? ipkn의 제보를 받고 다시 내용을 확인해보니 파이썬 예제가 있는게 맞다. 흠 내가 그 때 이런걸 봤는데 왜 기억을 못할까  Orz 반성 좀 해야겠다 ㅠㅠ

ps. 알라딘에 있는 목차와 비교해보니 목차는 일치한다. (심지어 부록 부분도…) 근데 이거 각 장 제목들이 영어의 동음이의어를 사용한 유머?가 있는데 — 예를 들어 23장의 “얼마나 달콤한지”는 원문에서 “How Suite It is”다 — 이런 부분은 좀 재미가 덜하겠네 -_-a

다시 읽어도 책 자체는 간결한게 보기가 좋긴하다. 내용이 완벽?한거랑은 좀 거리가 있는데…

어제 저녁에 다시 HEAD 리비젼으로 빌드해 본 후에 RC2상태인(첫번째 아파치 릴리즈가 준비 중) log4cxx 0.10 RC2를 빌드해봤다. (뭐 사실상 같다)

대충 이전 버젼이랑 VC8 project (VisualStudio.Net2005) 를 만들 때의 차이를 말하자면, (단순히 빌드할 때랑의 차이도 있다)

• DLL 빌드만 된다 — 이전 버젼에선 static lib으로도 빌드가 되었던 것 같은데 흠 -_-; 지금은 일단 ant build 로만 lib 파일을 생성하는 중(아니면 프로젝트 설정을 뜯어고쳐야)
• include / lib path가 상대 경로로 생성된다 — 이전 버젼은 절대경로로 생성되서 일일이 수정해주거나 스크립트를 짜야해서 귀찮아졌다
• 새 버젼 의 cpptask가 필요하다 — 이건 바로 받을 수 있는게 아니라서 좀 짜증나더라. 그렇지만 RC2 -> 0.10 release가 나올때 쯤은 정식으로 나온다하니 어찌 되긴하겠지;
  
• 몇 개의 UnitTest가 실패한다 — 이건 원인을 좀 분석해봐야겠는데 언제하지?
  
• apr, apr-util이 포함되지 않은 상태로 배포된다 — 이전 버젼은 자동 다운로드. 새로 추가되거나 할지도? 뭐 이건 큰 변화가 아니다. 귀찮을 뿐이지..

요약하자면,

• VisualStudio 2005 사용자 관점에서 귀찮았던 점(path 관련) 수정
• 빌드 툴에서 요구하는 라이브러리/툴의 버젼 변화

정도. 뭐 RC2가 끝나고 정식으로 릴리즈되면 (VOTE 과정이 끝나야하겠지만) 그 때가서 다시 테스트 해봐야겠다.

rein이 사용 중인 C++ 용 logging 라이브러리인 log4cxx에 대해 예전에 포스팅한 글에 질문이 붙어서 간만에 메일링을 좀 뒤졌다.

2008년 2월 23일자 메일링에 이런게 있다.

log4cxx 0.10.0 RC2 is now available for review for release on the unofficial builds area. This release candidate is strictly provided for consideration for release, may be withdrawn and will be removed from the publication location at the conclusion of the voting period. RC2 is currently available at: …

0.9.7 인 상태로 굉장히 긴 기간 (대충 2년?)을 보내고 0.10 (첫번째 apache release)가 나오게 된다. 그 동안 개발자 수도 상대적으로 적은 프로젝트였고 (java기반이고 log4cxx의 코드베이스이기도한 log4j에 비하면 정말로 적다), svn 접근만 오래했던지라 약간 불안(?)한 점도 있었는데 곧 나올 수 있게 되었다니 기쁘기도 하다

최종적으로 RC 딱지를 떼고 정식 릴리즈되는 것은 CPPTask의 code-freeze랑도 연관이 있고, 빠르면 다음주 중순에는 볼 수 있을듯도 하다. 조만간 이쪽도 다시 손을 대야(?)하는데 타이밍이 적당히 맞아주는 것도 즐거운듯.

ps. 덤으로 이전 포스팅에 달린 댓글에서 나온 문제 와 해결책

BUILD FAILED
d:\work\log4cxx\log4cxx-trunk\build.xml:348: The following error occurred while
executing this line:
d:\work\log4cxx\log4cxx-trunk\src\ant\apr-build.xml:111: project doesn't support
the nested "comment" element.

문제의 원인 :  ant에서 C++ 코드를 컴파일하는데 사용하는  CCTask의 버젼이 낮아서 발생하는 문제

해결책 :

1. http://ant-contrib.svn.sourceforge.net/svnroot/ant-contrib/ 에서 antcontrib의 HEAD rev. 을 받는다
2. cpptask trunk를 찾아서 ant로 cpptask를 빌드
3. 빌드된 cpptasks.jar를 ant의 lib 디렉토리 밑에 복사하거나 CLASS_PATH 설정
4. log4cxx를 빌드한다

주말에 포스팅했던 UnitTest++의 VS2005  애드인을 회사에 적용해보고 있다.

내가 지금 메인으로 작업하고 있는 것의 경우 VisualStudio 2005 솔루션을 다음과 같이 세 개의 Solution Folder 로 분리해놓은 상태다.

• Common Library — 몇 개의 공통 코드 베이스에 해당하는 프로젝트들
• Test — 테스트를 위한 mock–object, UnitTest++, 테스트 코드들.
• 메인 코드 베이스

VisualUnitTest++을 여기에 적용하려고 했더니 Test 라는 이름의 Solution Folder 밑에 있는 것을 찾질 못하더라 -_-;; (원인 찾는데 1시간 날렸다 Orz). VisualStudio AddIn을 모르니 고칠 수도 없고 난감한 상황.

일단 solution folder에서 테스트 있는 프로젝트들만 루트로 빼내서 실행은 가능해진 상태. 그래도 JUnit같은 녀석을 VS.Net에서 보게되니 좋긴 좋구만

하나의 CPU에 다 수의 코어가 있는 제품들이 보편화되면서,

이 프로그램은 듀얼 코어/쿼드 코어를 지원합니다

하는 광고(?)멘트들이 난무하게 되었다. 이게 어떤 의미일까?

우리가 흔히 사용하는 많은 프로그램들은 기본적으로/전통적으로 “싱글 스레드”라고 부르는 한 번에 한 가지일만 처리하는 구조로 만들어져 있다. 그래서 CPU에 코어가 몇 개 있더라도 1개의 코어만 사용해서 실행된다. 이런 프로그램들의 경우 멀티 코어 CPU에서 더 빨라지진 않는다. 즉 CPU자체가 향상되는 부분만큼만 속도가 빨라지지 CPU 수가 늘어나는데서는 이익을 못본다. 

물론 여러개의 응용 프로그램을 동시에 돌릴 때는 이익을 볼 수 있다. 각각의 프로그램에서 서로 다른 코어를 사용하면 되는 문제니까. 예전이라면 게임을 켜놓고 동영상을 보면서 웹 브라우징을 한다는 건 좀 괴로운 일에 속했는데, CPU  코어가 3개 이상이고(쿼드 코어라거나) — 그리고 각각이 싱글 스레드라면 — 메모리가 모자라지 않는다면 별 부담없이 할 수 있는 일이 된다.

반면에 요즘 나오기 시작한 프로그램들은 제한적인 의미에서 여러 개의 코어를 쓸 수 있는 경우가 있다. 즉 “여러 개의 스레드”를 동시에 사용해서 코어를 스레드 수 만큼까지는 쓸 수 있다는 것이다. 사실 이미 몇 가지 프로그램들에서는 제한적으로 이런 기능을 쓰고 있다. 예를 들어,

• 미디어 플레이어인 foobar 2000에서 MP3 포맷을 바꾸면 동시에 CPU 코어 수만큼 변환이 일어난다. 이렇게 동시에 해도 되는 작업을 코어 수만큼 실행하는 프로그램들은 많다.
• 많은 수의 워드프로세서에서는 스펠링 검사나 검색용 인덱스 생성을 조용히 뒷단에서 별도의 코어를 활용해서 수행한다.
• 요즘 나오는 게임들은 게임 화면을 표시하는 부분 / 게임 자체의 로직이나 물리 연산 / 데이터를 읽어들이는 부분을 서로 다른 스레드에서 동작하게 해서 여러 개의 코어를 동시에 사용한다.

같은 것들이 있다. 즉 이런 프로그램들의 경우 멀티 코어를 지원한다고 말하는 것인데, 약간의 성능향상이 있긴하다.

즉, 광고는 이렇게 받아들여라.

• 멀티 코어를 지원한다 = 남는 CPU 코어가 있으면 좀 더 활용해서 빨라질 수도 있다
• 멀티 코어를 지원한다 ≠ 모든 코어를 활용한다 => 기껏해야 만든 스레드 수 만큼밖에 못쓰니 지금 4코어를 쓰는 프로그램이 16코어 CPU에서 더 빨라지는 것은 아니다.
• 멀티 코어를 지원하지 않는다 — 멀티 코어 CPU에서 동작하지 않는다는 얘기가 절대로 아니다. 단지 코어 수만큼 빨라지진 않을 거란 의미.
• 멀티 코어를 지원하지 않아도 여러 개의 프로그램을 동시에 쓰는 경우가 많다면 멀티 코어 CPU 는 충분히 매력적인 무언가다.

뭐 그런 의미다. 앞으로의 미래는 CPU 클럭이 올라가는 것보다는 멀티 코어에서 코어 수가 증가하는 방향이 될테니(적어도 향후 5년 이상은), 멀티 코어를 위한 프로그램들도 증가하긴 할 것이고, 크게 신경 쓸 문제는 아니다. 그러니 저런 광고에 낚이지도 말고, 지원하지 않는다는 말에 좌절하지도 말자