전 사실, 대학에서 공학을 전공했습니다. 그것도, 산업공학이란 시스템을 다루는 공학을 전공했지요. 대학시절이 제게 남긴 가장 큰 가르침은 시스템에 대한 정의와 공학적 문제 해결 방법입니다. 시스템에 대한 정의는 언젠가 설계와 관련한 글을 쓸때 써먹게 될 것이고, 오늘 이야기할 디버깅은 공학적 문제 해결 방법을 써먹게 되겠네요.
일을 하면서 느끼는 것은 디버깅을 어렵게 느끼는 사람들이 많다는 점입니다. 어렵게 느끼는 사람들 혹은 어렵게 느끼는 상황을 곰곰히 생각해보면, 어려운 이유는 단 하나입니다. 막막하다는 것이지요. 보통, 막막함에 당황하고, 당황하니 더 막막한 악순환의 고리로 빠져드는 경우가 많습니다. 일단은 침착해야 합니다.
차분하게 공학적 문제 해결 방법을 따라서 생각해보는게 좋습니다.
- 문제를 탐색한다.
- 문제를 정의한다.
- 자료를 수집한다.
- 자료를 분석한다.
- 대안을 생성한다.
- 대안을 평가한다.
- 대안을 선정한다.
- 대안을 적용한다.
- 1번으로 돌아간다.
네. 사실 ‘당연한거 아냐?!’ 라고 생각하기 쉬운 당연하고 자명한 이야기입니다만, 당황하게 되면 의외로 잊기 쉬운 기본적인 것들입니다. 타석에 들어선 야구선수가 공을 끝까지 보고 스윙을 해야하듯이 디버깅도 항상 차분하게 공학적인 자세로 접근해야 하는거죠. 아무리 시스템이 복잡하다해도, 아무리 답이 안보이는 것 같은 문제라 할지라도, 차분하게 접근하면 대부분의 버그들은 찾아낼 수 있습니다. 차분한 마음가짐이 있다면, 비로소 여러 테크닉들을 적용할 수 있게 되니까요. 어려운 버그는 없습니다. 다만 복잡해서 막막한 버그일 뿐이지요. 모든 버그는 그냥 버그일 뿐입니다. 
Zero Configuration: Simple is best는 어렵다.에서 언급한 바와 같이, 현재 제작중인 소프트웨어의 모듈/시스템수는 엄청나게 증가해버렸다. 서로 연동해야하는 모듈이 많으니 이리저리 입력해야하는 네트워크 정보(각 노드의 IP와 Port)가 매우 많다. (제어UI에는 8개정도지만, 세밀하게 조정에 들어가면 셀수 없이 많다.) 이런 상황에서 각 노드들을 효율적으로 관리하려면 어찌해야 할까?
각 노드마다 설정을 전부 해야한다고 생각하면, 그 복잡도는 노드가 추가될 때마다 선형적으로 증가하며, 각 노드에서 필요한 기능-설정이 추가될 때 마다 기하급수적으로 증가한다. 언제까지 이런 설정을 반복하고 있을 수는 없다. 쉽게 생각할 수 있는 해결책은 중앙집중관리노드를 도입해서 실제로 기능을 수행하는 각 노드들이 중앙 노드를 바라보고 있는 Star형 토폴로지를 구현하는 것이다. 이러면, 문제가 해결될 것 같지만 크게 2가지 관점에서 결정적인 단점을 가지고 있다.
- 전체 시스템의 복잡도는 전혀 줄어들지 않으며, 다만 중앙 노드로 압축될 뿐이다.
- 중앙 노드에 장애가 발생할 경우, 전체 시스템이 동작하지 않는다.
이런 단점을 최소화하는 모델이라면, 전화번호부 모델이 있다. Java Jini나 Web Service에서 활용하는 Naming 서비스 혹은 Directory서비스가 대표적인 사례인데, 필요한 노드(서비스)의 위치를 관리하는 Naming 서비스를 도입하여, 각 노드간 통신을 위해 필요한 위치정보를 URL 혹은 그와 유사한 형태로 저장하여 서로 Lookup을 하게 하는 것이다. Respository나 Directory 서비스의 복잡도는 상대적으로 낮은 편이다. 권한이나 인증같은 부분을 제외하고 생각하면, 등록과 조회만 있으면 된다. TCP/IP네트워크에 익숙하다면, DNS를 생각하면 된다.
실제 데이터를 주고 받기 위한 통신 채널은 각 노드사이에서 형성되므로 Naming 서비스는 단지 ‘전화번호부’의 역할만을 수행한다. 각 노드들 역시 Naming 서비스의 위치만 설정해주면 되므로, 설정은 더더욱 간편해진다.
중앙 노드로 압축되는 복잡도의 문제는 어느정도 해소가 가능해졌지만, 중앙 노드의 장애에 대한 문제점은 아직 남아있다. Naming 서비스의 이중화로 해결할 수 있는 문제일 수도 있겠지만, Naming 서비스의 조회결과를 로컬에 캐쉬하는 방법도 있다. 노드들이 급격하게 위치를 변경하는 시스템이라면 독이 될 수 있지만, 위치가 그렇게 급격하게 변하지 않는 다소 정적인 시스템이라면 충분히 위력을 발휘할 것으로 생각된다.
멋져 보이지만, 마지막 결정타가 하나 남아있다. 이건 ‘Zero-Configuration’ 이 아니다. 여전히 사용자는 Naming 서비스의 위치를 ‘설정’해주어야 한다. TCP/IP에는 Broadcasting이라는 멋진 방법이 존재한다. 각 노드들에 Naming 서비스를 설정하지 않아도 Broadcasting으로 Naming 서비스를 찾아낼 수 있다. 물론, 수동 설정도 가능해야 하겠지만 말이다.
보통 TDD(Test-driven development)는 잘 짜여진 테스팅 케이스를 이용해 소프트웨어의 수행 결과를 점검하는 형태로 이루어진다. 문제는, 이 방식의 접근은 처음부터 TDD를 하지 않으면 적용하기 힘들다는 거다!
게다가 최근 TDD가 없이는 개발이 불가능한 상황에 봉착했다. 입력 데이터의 종류는 수없이 많고, 이 데이터의 조합에 따라 서로 Side-effect를 발생시키는 골머리아픈 상황이다. (소프트웨어 설계가 잘못된건 아니다. 애시당초 풀어야할 문제가 이렇게 꼬여있다.) 설상가상으로 데이터의 종류가 무엇인지 알지 못하는 상황에서 종류를 guessing하고 조합해서 문제를 풀어야 할 정도니 말 다했다. 그리고, 출력되는 결과물도 굉장히 다양하다. (그 입력만큼이나 복잡하다)
프로게이머도 아닌데 엄청난 키보드+마우스 컨트롤을 자랑하며 테스팅을 할 수는 없는 노릇이고 해서, 간단한 테스팅 프로그램을 도입해서 문제를 해결하기로 생각하였다. 입력데이터를 잘 준비해두면 생성된 결과물을 잘 검사하기만 하면 되는 일 아니겠는가?
이 정도만 되면, 문제를 해결하기는 쉬울 것이지만 검사해야 할 항목들이 자주 변한다는 사실을 깨달았다. 입력데이터별로 차이도 존재하고, 데이터 종류에 따라, 또 그 조합에 따라 항목은 계속 바뀌어야 한다. 이쯤되면, 간단한 스크립트 언어를 만들어서 검사항목을 쉽게 변경할 수 있게 하면 되리라는 생각이 든다. 어머나. 배보다 배꼽이 커져버렸다.
그래서, XML과 XPath를 도입하기로 했다. 수행결과를 XML로 남기고, 남겨진 XML파일이 가져야할 조건, 즉 정상적인 생성물의 조건을 XPath 표현식으로 작성하는 것이다. TDD의 용어로 말하면, XPath 표현식은 Test case가 된다.
시험적으로 전체 시스템의 일부에만 적용해 보았는데 아주 마음에 든다. 물론, 서로 의존관계에 있는 XPath 표현식을 계층적으로 처리해주는 작업을 해야하긴 하지만, 그건 천천히 해도 될 것 같다.
ps. 관련된 코드와 예제를 공개하고 싶지만, 작업하다보니 대외비 코드가 너무 많이 들어갔네요. T_T
Zero-configuration이란 말을 처음 접했던 건, 한국에서 널리 사용되는 자막 파일인 SMI에 대한 지원을 Mac OS X용 통합 코덱(?)인 Perian에 넣을 수 없다는 애플포럼의 한 쓰레드 때문이었다. 요지는, SMI를 지원하기 위해서 자막의 인코딩 셋업같은 별도의 세팅이 필요하기 마련인데, 이게 Zero-configuration에 위배되기 때문에 SMI에 대한 지원을 넣을 수 없다는 내용이었다. (물론 이유가 이것만 있는 것은 아니었다.)
Zero-configuration은 말 그대로 설치 이후 설정이 필요없는 소프트웨어의 특성을 의미한다. Read the rest of this entry »
어쩌다 이름이 XMLCC가 되었는지는 모릅니다. 그냥 손가락에서 저렇게 나왔어요. 신의 뜻이라 생각하고 넘어갑니다. 씨익-
사건의 발단은 회사에서 XML을 생성해서 서버에 전송해야 하는 일이 생겨서 std::stringstream을 이용해 XML을 생성하다 보니 코드가 너무 지저분해지는 겁니다. 후.. 이런저런 고민을 한 끝에 좀 깔끔하게 짤 수 있는 프로그램을 작성해보기로 했지요.
일단 만들 XML부터 봅시다.
XML:
-
<book title="XMLCC: XML Generator for C++">
-
<author>Crow, Lim</author>
-
<date year="2008" month="2" day="18"/>
-
</book>
저런 문서를 하나 만들기 위해, std::stringstream을 사용하게 되면 다음과 유사한 코드가 등장할겁니다.
C++:
-
std::stringstream ss;
-
-
void make_xml(std::stringstream& ss, std::string const& title, std::string const& author, ...(생략)...)
-
{
-
ss <<"<book title=\"" <<title <<"\">";
-
ss <<
"<author>" <<author <<
"</author>";
-
ss <<"<date year=\"" <<year<<"\" month=\"" <<month <<"\" day=\"" <<day <<"\""/>";
-
ss <<"</book>";
-
}
보기만 해도 끔찍하군요. 엄청난 escaping문자들.. 보기만해도 어지럽습니다. 만약 다음과 같이 작성할수 있다면 행복할텐데요.
C++:
-
void make_xml(std::stringstream& ss, std::string const& title, std::string const& author, ...(생략)...)
-
{
-
// 들여쓰기는 보기 편하라고 한 것 입니다.
-
element_start(ss, "book");
-
attribute(ss, "title", title);
-
-
element_start(ss, "author");
-
text(ss, author);
-
element_end(ss, "author");
-
-
element_start(ss, "date");
-
attribute(ss, "year", year);
-
attribute(ss, "month", month);
-
attribute(ss, "day", day);
-
element_end(ss, "date");
-
-
element_end(ss, "book");
-
}
아쉽게도 위와 같은 코드는 작동하지 못합니다. XML의 특성상 attribute는 element 시작태그 내에서 정의가 되어야 하기 때문이지요. 물론, 이를 해결하기 위해 element_start의 인수로 attribute의 list를 넘겨주는 방법도 있습니다만, 이 방법은 해당하는 리스트를 생성해야한다는 단점이 있습니다. 의미상 코드에서 정적으로 정의가 가능한 XML을 굳이 리스트를 생성하면서 만들 필요는 없지요.
이를 위해 element_start()의 리턴을 객체로 주는 방법을 사용했습니다. 그 객체에서 시작태그를 생성하고 attribute도 처리하는 거지요.
C++:
-
void make_xml(std::stringstream& ss, std::string const& title, std::string const& author, ...(생략)...)
-
{
-
// 들여쓰기는 보기 편하라고 한 것 입니다.
-
element_start(ss, "book")
-
.attribute("title", title);
-
-
element_start(ss, "author");
-
text(ss, author);
-
element_end(ss, "author");
-
-
element_start(ss, "date")
-
.attribute("year", year)
-
.attribute("month", month)
-
.attribute("day", day);
-
element_end(ss, "date");
-
-
element_end(ss, "book");
-
}
element_start()의 리턴객체에서 attribute를 호출합니다. 자세히 보시면 뒤에 세미콜론(;)이 없는 라인들이 있는데 사실 한 expression이란 겁니다. 일종의 호출 체인이랄까요?
xmlcc.h에 있는 주요 부분을 보면 다음과 같습니다.
C++:
-
struct element_start_tag
-
{
-
std::ostream& out_;
-
-
element_start_tag(std::ostream& out, std::string const& name)
-
: out_(out)
-
{
-
out_ <<"<" <<name;
-
};
-
-
element_start_tag(element_start_tag& tag)
-
: out_(tag.out_)
-
{
-
};
-
-
element_start_tag& attribute(std::string const& name, std::string const& value)
-
{
-
out_ <<" " <<name <<"=" <<"\"" <<value <<"\"";
-
return *this;
-
}
-
-
template<class Func>
-
element_start_tag& attribute_with_generator(std::string const& name, Func const& f)
-
{
-
out_ <<" " <<name <<"=" <<"\"";
-
f(out_);
-
out <<"\"";
-
return *this;
-
}
-
-
element_start_tag& operator()(std::string const& name, std::string const& value)
-
{
-
return attribute(name, value);
-
}
-
-
void close_now()
-
{
-
out_ <<"/";
-
}
-
-
~element_start_tag()
-
{
-
out_ <<">";
-
};
-
};
-
-
-
element_start_tag element_start(std::ostream& out, std::string const& name)
-
{
-
return element_start_tag(out, name);
-
}
보시면, 생성자에서는 시작태그의 요소이름까지만 출력을 하고, 소멸자에서 태그를 닫습니다. attribute를 사용하면 stream에 attribute를 출력해주지요. 또한, close_now()를 호출하면 "/"를 출력시켜줌으로써 스스로 닫는 element를 생성해줍니다. 그리고, element_start()는 이 element_start_tag를 생성해주는 도우미 역할을 하지요.
attribute메소드는 operator()를 이용해도 사용할 수 있습니다. 이 경우 코드가 훨씬 간단해지지요.
C++:
-
void make_xml(std::stringstream& ss, std::string const& title, std::string const& author, ...(생략)...)
-
{
-
// 들여쓰기는 보기 편하라고 한 것 입니다.
-
element_start(ss, "book")
-
("title", title);
-
-
element_start(ss, "author");
-
text(ss, author);
-
element_end(ss, "author");
-
-
element_start(ss, "date")
-
("year", year)
-
("month", month)
-
("day", day);
-
element_end(ss, "date");
-
-
element_end(ss, "book");
-
}
사실 XML생성에 있어서 다른 XML의 구성요소들은 크게 문제가 되지 않는데, 가장 머리 아픈 부분은 element의 시작태그와 그 안에 내포된 attribute인지라 이런 잔머리를 굴려봤습니다. 덕분에 소스코드는 escape문자 없이 깔끔해졌군요. 잇힝-
좀 더 삽질해서 DSL(Domain Specific Langauge)형태로 만들어 보려고 했는데, 시간도 없고 이정도면 쓸만한거 같아서 여기서 멈췄습니다.
xmlcc.h 다운로드