몇 년만인가. 대학 졸업할 때쯤부터니까 7년 정도 되려나.

친구가 행시에 합겼했다. 오늘 발표 났단다. 한 번은 3차 면접에서 떨어지고, 중간에 군대도 다녀오고, 요새는 선생질한다고 빨빨거리고 돌아다니더만. 붙었구만.

워낙 성실한 녀석이고, 열심히 하고, 잘 하는 녀석이니까 결국 붙을 거라고는 생각하고 있었지만 그래도 그간 고생하는 걸 보면서 걱정도 많이 했다. 제대로 놀기를 하나, 맘편히 쉬기를 하나, 생활은 갑갑하고, 시간은 흘러만 가고. 될듯 말듯 피를 말리는 게지.

방금 전 그 친구랑 통화를 했다. 위닝하고 있단다. 내가 다 눈물이 날라 그러네.

축하한다.

나도 드디어 유닛 테스트의 세계에 발을 들여놓았다.

여기에는 테스트 같이 사치스러운 일은 존재하지 않았고 앞으로도 존재하기 힘들다. 그동안 귀찮아서 눈 감고 있었는데, 괴로워지는 건 결국 나다. 뭘로 할까하고 고민만 하다가 boost에 유닛 테스트 라이브러리가 있길래 옳타꾸나하고 붙였다. 그런데 boost는 매뉴얼이 부실해서 뭘 어쩌라는 건지 한참 헤맸다.

쓰는 방법은 간단하다. 테스트 메인을 선언하고 매크로를 이용해 테스트 케이스를 추가하면 된다.

테스트 프로세스를 어떻게 꾸밀까 몇가지 생각해봤는데 아래처럼 쓰는 게 좋을 것 같다. 가능한 기존 컴파일 환경을 공유하면서, 테스트 코드와 실제 실행 코드를 분리하고, 테스트에 실패하면 프로그램이 아예 컴파일 되지 않는다.

1. 테스트 메인을 만든다.

1-1. main.cc를 main.test.cc로 복사한다.

1-2. main.test.cc에서 main 함수를 지운다.

1-3. main.test.cc에 대신 다음을 추가한다.

#define BOOST_TEST_MAIN

#include <boost/test/included/unit_test_framework.hpp>

2. 테스트 케이스를 만든다.

2-1. 테스트할 소스가 src.cc에 있으면, src.test.cc를 만들고 아래와 같이 테스트 케이스를 작성한다.

#include <boost/test/unit_test.hpp>

BOOST_AUTO_TEST_CASE( func )

{
    BOOST_CHECK_EQUAL( ... );

}

3. 테스트가 실패하면 프로그램이 컴파일되지 않도록 Makefile을 수정한다.

3-1. 테스트용 프로그램이 먼저 만들어지도록 한다.

$(TARGET): $(TARGET).test ...

3-2. main.cc를 main.test.cc로 대체하고, 테스트 케이스가 있는 파일을 추가해 컴파일한다.

3-3. 테스트 프로그램을 실행한다. (테스트에 실패하면 여기서 멈추기 때문에 자연스럽게 최종 프로그램이 만들어지지 않는다.)

$(TARGET).test: ...

    ...

    $(TARGET).test

p.s: 유닛 테스트를 처음 적용해보는 거고, boost test 라이브러리도 처음 써보기 때문에 깔끔하지 못한 부분이 있을 겁니다. 좋은 사용법을 알려주시면 감사하겠습니다.

농담으로 하던 소린데

진짜 시급 5,000원짜리 인생이었네. ㅋㅋ

책임 2 + 선임 1 + 사원 1

책임 3 + 선임 2 + 사원 1

수석 1 + 책임 3 + 사원 1

어쩌라고?

회사 내에서 열리는 세미나는 아무거나 간다고 말만 하고 갔다 오란다. 세상 참 많이 좋아졌다.

지난 2년간 교육에 참석한 적 없다. 무슨 교육 받아도 되겠냐고 물어보면 돌아오는 첫 마디. “업무 연관성은?”. 썩을. 이따위 업무랑 연관있는 교육이 어딨냐. 짜증이 나서 그 다음부터는 가고 싶다는 말 안하고 그 좋아하시는 일만 죽어라 했다. 그런데 아무거나 가라고? 원래 그랬던 것처럼 아무렇지 않게 말하는 것도 좀 짜증난다.

그래도 역시 윗대가리가 쪼으니까 바꾸는 척이라도 한다. “니들 공부는 하고 있냐?”라는 연구소장님의 알흠다운 한마디에 바로 책임급이상은 의무적으로 세미나(라고 쓰고 업무 발표회라고 읽는다)를 해야 하고, 다른 사람들은 의무적으로 몇시간 이상 세미나에 참석해야 하게 되었다. 갑자기 교육 권하는 사회가 되었다.

형식적이고 행정적이지만 그래도 안하는 것보단 낫다. 이용할 수 있는 틈새가 생기니까. 하지만 너무 늦었다. 나에게는.

이번 주 업무 보고서 파일을 자동으로 만드는 스크립트를 작성했다. 주간 보고서를 개별 파일로 관리하는데, 매주 업무 보고서를 작성할 때마다 지난 주 업무 보고서를 복사해서 앞에 붙은 사본 표시 지우고, 날짜를 맞게 고치는 일이 별거 아니지만 은근히 귀찮다. 그래서 새로운 이름으로 파일을 복사하는 AutoIt v3 스크립트를 만들었다.

#cs ----------------------------------------------------------------------------

 AutoIt Version: 3.3.0.0
 Author:         myName

 Script Function:
 Template AutoIt script.

#ce ----------------------------------------------------------------------------

; Script Start - Add your code below here

Dim $dst
Dim $pattern = "(.*)서상원_(..)주차_(......)_(.)주-취합용.gul"
$path = StringRegExpReplace($CmdLine[1], $pattern, "\1")
$yweek = StringRegExpReplace($CmdLine[1], $pattern, "\2")
$ym = StringRegExpReplace($CmdLine[1], $pattern, "\3")
$mweek = StringRegExpReplace($CmdLine[1], $pattern, "\4")
$dst = $path & "서상원_" & $yweek + 1 & "주차_" & $ym & "_" & $mweek + 1 & "주-취합용.gul"
;MsgBox(0, "test", $dst)
FileCopy($CmdLine[1], $dst)

위 스크립트를 컴파일해서 파일에 연결시켜두고, 실행하면 새 파일이 생긴다.

하는 일은 아주 간단하다. 다른 이름으로 파일을 복사하는 것 뿐이다. 그리고 완전히 자동화된 버전도 아니다. 한 달이 끝나면 주차를 다시 처음으로 돌려줘야 하는데, 언제 달이 끝나는지 몰라서 그 때는 전처럼 수동으로 복사해야 한다.

반쯤은 연습삼아 만든거지만, 잡무는 최대한 자동화해야 인생이 편하다.

N-dimensional array position = (P0, n[N], delta[N][N])

사회 생활을 하다보면 하기 싫은 일을 해야 할 때가 있다. 어쩌면 하고 싶은 일을 하는 시간보다 하기 싫은 일을 하는 시간이 길 수도 있다. 하기 싫은 일은 안 하면서 살 수 있을까. 집에 돈이 넘쳐흘러 손가락 까딱 안해도 먹고 살 수 있다면 그럴 수 있을지도 모르겠다. 하지만 보통은 그렇지 못 하다.

“하기 싫은 일은 도대체 언제 해야 할까“라는 질문의 답은 뭘까. 이 질문에 답하려면 사실 질문을 약간 손봐야 한다. 저 질문에는 “하기 싫은 일 = 중요하지 않은 일”이라는 가정이 숨어있다. 즉, “중요하지 않은 일은 도대체 언제 해야 할까”로 바꿔야 하고 그에 대한 내 결론은 “할 필요없다”이다.

그냥 듣기 좋으라고 하는 소리 같은가? 세상물정 모르는 철없는 소리 같은가? 그럴지도 모른다. 하지만 한 번 생각해보자. 보통 회사에서 일반 직원이 화장실 청소를 해야 한다거나 경비 정산을 직접 해야 한다거나 건물 경비를 해야 한다고 생각하지 않는다. 그런 업무를 맡기기 위한 직원을 따로 뽑거나 용역을 맡긴다. 왜 그럴까. 일반 직원은 원래 그런 걸 할 줄 모르기 때문에? 그 편이 더 싸게 먹히기 때문에? 남들이 그렇게 하니까 따라서 나도 그냥? 아니다. 일반 직원에게는 그런 부수적인 업무보다 “더 가치있는, 더 돈벌이가 되는” 일을 해주길 바라기 때문이다. 업무에 있어서도 똑같은 잣대가 사용된다.

새벽부터 밤늦게까지, 쉼없이, 성실하고, 아주 깔끔하게 잡무를 처리해도 설렁설렁 다니며, 적당하게 중요 업무를 처리한 사람보다 인정받지 못 한다. 아무리 깔끔하게 처리해도 잡일은 잡일이고, 어설프게 했을 망정 중요한 일은 중요한 일이다. 호박에 줄 긋는다고 수박되지 않는다.

하고 있는, 할 수 있는 일 중에 가장 중요하고, 하고 싶은 일을 하라. 당신이 그보다 가치 있는 일을 하고 있는 동안에는 별 쓸모없는 일을 망쳤다고 해서 그대를 비난하지 못 한다. 오히려 당신이 잡동사니를 치우는데 적합하지 않다는 것을 보여줄수록 하찮은 것들은 당신으로부터 멀어질 것이다.

요새 너무 스트레스를 받아 참다참다참다 못 참겠어서 책을 지르려는데… 비싸다! OTL 세계 책의 날 행사라는대도 5만원이 넘는다. 쿠폰을 챙겨봐도 3천원이 최대. 그동안 쌓아놓은 마일리지를 탁탁 다 털어쓴대도 아직 4만원 정도가 남는다. 으음~ 고민고민. 여기에 살을 좀 붙이면 다시 5만원대로 올라갈텐데… 하면서 그냥 이것저것 뒤적이고 있는데 이상한 것들이 눈에 띄었다. 예치금이니 정액권이니. 평소라면 무시하고 지나갔을텐데 책이 정말 사고 싶었는지, 혹시 할인 좀 되려나 싶어서 계속 뒤적였다. 그러다가 상품권 충전하기라는 버튼을 눌러봤는데…

도서문화상품권/도서생활권 충전을 선택하니 북앤라이프 캐시로 전환해야 다시 교보문고에서 쓸 수 있도록 전환할 수 있댄다. 북앤라이프라는 사이트는 도서상품권을 사이버 캐시로 전환한 다음에 각종 사이트에서 다시 전환해서 쓸 수 있는 서비스를 제공하는 사이트더라. 그런데 나의 날카로운 눈을 벗어나지 못 한 것이 있으니, 바로바로 “무료충전소”!!

공짜라면 자다가도 일어나는 내가 방앗간을 그냥 지나칠 수야 없지. 매력적인 건 북앤라이프에서 충전한 캐시를 바로 교보문고 예치금으로 전환해서 책 구매에 쓸 수 있다는 거다. 이게 왠 떡. 오늘 하루 무료충전소에서 열심히 클릭질을 해댄 결과 4,900원의 예치금을 획득했다. 앉은 자리에서 5천원을 번거다. 이거 꽤 쏠쏠한데? ㅎ

무료충전소를 이용할 때 주의할 것이 있는데 개인정보를 제공해야 한다는 점이다. 대부분이 회원가입이나 이벤트 참여를 통한 캐시 적립이기 때문에 온라인으로 개인정보를 제공하는 걸 꺼리는 사람은 이용하기 어렵다. 난 그다지 신경쓰지 않는 편이지만 그래도 무료충전소를 이용할 때 내가 고려하는 것은 다음과 같다.

DO

1. 무료 회원가입, 이벤트 응모 위주로 참여한다. 특히 보험사 같은 곳에서 하는 이벤트를 선호한다. 가입절차 없이 간단히 정보만 입력하고 클릭하면 되니까. 나중에 걸어오는 상품 권유 전화는 적당히 응대하고 끊으면 된다.

DON’T

1. 유료 회원가입, 유료 서비스 결제는 피한다.

2. 무료 서비스 체험도 피한다. 무료 서비스 체험은 대부분 체험 기간이 지나면 자동으로 유료 결제로 전환된다. 신경써서 체크하지 않는다면 모르는 사이에 돈이 세어나갈 수 있다. 혹 떼려다 혹 붙이는 경우.

3. 너무 허접해 보이는 사이트는 회원가입을 피한다. 사이트를 겉보기만으로 판단해서는 안되겠지만 개인정보 유출이 우려되는 허접한 사이트는 회피기동으로 적당히 피해주는 센스.

p.s: 이 글은 교보문고 이용을 가정하고 있다.

C++에는 *_cast 형태의 여러 형변환 함수가 있다. 가능한 형변환이 없는 코드를 짜는 게 좋다고 하지만 불가피한 경우들이 있다. 형변환 함수가 많다보니 언제 어떤 형변환 함수를 써야하는지 혼동스러울 수 있다. 각 형변환에 대해 간단히 정리해보자.

C++에는 네 개의 형변환 함수가 있다. static_cast, dynamic_cast, reinterpret_cast, const_cast가 그것이다. 이 중 static_cast와 dynamic_cast를 가장 많이 사용하고, const_cast를 어느 정도, reinterpret_cast는 거의 쓰지 않는다.

클래스 포인터를 형변환할 때 기본적으로 dynamic_cast를 사용하고 dynamic_cast를 쓸 수 없는 경우에 static_cast를 사용한다. dynamic_cast는 실행 시간에 객체의 타입 정보를 참조하여 형변환하기 때문에 다형성(polymorphic)을 가지지 않은 객체는 변환할 수 없다. 가상 멤버를 가진 클래스에는 dynamic_cast를, 가상 멤버가 없는 클래스에는 static_cast를 사용하자. 가상 멤버를 가지고 있는 경우에도 static_cast를 사용할 수 있지만 안전하지 않으므로 안쓰는 게 좋다. 그리고 dynamic_cast는 형변환에 실패하면 0을 리턴하기 때문에 실행 중에 체크할 수 있다.

const 객체의 const 특성을 없애고 싶을 때는 const_cast를 사용한다. 하지만 객체를 최초로 생성할 때 const 특성을 부여한 경우에는 const_cast의 동작을 보장할 수 없다. 쓰지 말아라.

reinterpret_cast는 전혀 관계 없는 형간의 변환에 쓰인다. 예를 들어 char* p = reinterpret_cast<char*>(0xEF000000)과 같은 식으로 임의의 값을 주소로 바꿀 때 쓴다. 이는 임베디드 프로그래밍에서 하드웨어 주소를 변수에 맵핑해서 다루는 방식이다. 일반 응용 프로그램에서는 거의 쓸 일이 없을 것이다.

참고 문헌

Stroustrup, The C++ Programming Language, special edition, Addison Wesley, 2000