제로보드 XE 관련 약간의 해명…

미투데이를 돌아다니다가 성민 장군님의 미투에서 ‘전 제로보드 XE를 잘 모릅니다!!! 말할때는 좀 생각을 하고 말해주세요.‘란 포스트을 보게 되었다. 위 포스트에는 Ever™님이 남기신 XE의 단점이 있다면??이란 글에 대한 해명글이었는데, 글 내용들을 읽다보니 내가 했던 얘기들과 약간의 연관이 있을 것 같다.

첫째, 우선 클래스와 관련된 얘기는 내가 했던 얘기와 분명히 연관이 있다.

사실 난 제로보드 XE의 코드를 본적이 없다. 그 이전의 제로보드5까지는 코드를 어느정도 구경해봤던 기억이 있는데, 그 날 내가 했던 얘기는 XE가 아닌 제로보드5의 코드에 대한 얘기였다. (사실 난 제로보드 XE가 제로보드5에서 이름이 바뀐 정도로 알고 있었다. 뭐 어쨌든!) 당시 제로보드5의 클래스는 다음과 같았다.

1. DB클래스
2. DB클래스를 상속한 ZeroBoard 클래스
3. 이를 상속한 또 하나의 클래스?

오래된 일이라 정확하게 기억나진 않고, 코드를 찾을 수가 없어서 더 자세하게는 얘기를 못하겠다. 어쨌거나 하고 싶은 얘기는 클래스의 사용이 나쁘다는 것이 아니라 필요없이 클래스를 상속하고, 쓸모없는 클래스들을 정의하고 있었다는 것이다.

클래스는 재사용을 위해 사용하는 것이다. 괜히 귀찮게 인터페이스를 만들고 내부 변수에 접근 못하도록 private, friend 같은 키워드를 걸어두는 게 아니란거다. 다른 클래스를 가져다 쓰고 있는데, 다른 클래스의 내부 구현이 변경되었다고 내 프로그램까지 문제가 생기면 안된다. 최악의 경우라도 새로 컴파일, 링크 하는 것 만으로 적용이 가능해야 한다.

그런 이유로 내부 변수에 직접 접근하도록 하는 것은 좋은 생각이 아니다. 내부에 있는 a라는 변수에 접근하도록 허용하기 보다는 getA(), setA(int var) 식의 인터페이스(자바에서는 ‘메쏘드’라는 이름을 사용한다.)를 제공하고, 내부 변수에는 접근할 수 없도록 private 등의 키워드를 걸어버리는 것이 좋다. 이 개념이 바로 인캡슐레이션이라 불리는 개념이다.

c의 변수에는 생성자(initializer)와 소멸자(destructor) 등이 없기 때문에 c style로 파일 단위 모듈화를 진행하게 되면 실제 그 모듈을 가져다 쓸 때 init_my_module() 같은 생성자를 호출하고, 그 모듈과 관련해서 더 이상 뭔가를 할 게 없으면 destruct_my_module() 같은 코드를 호출해줘야한다. 하지만 c++ 에서는 new 키워드를 통해 클래스를 만들게 되면 생성자가 호출되고 delete 키워드를 사용해서 클래스를 파괴해버리면 소멸자가 자동으로 호출된다. 그렇기 때문에 클래스를 가져다 쓸때는 복잡하게 해줄 일이 없다. 그저 header를 include하고, new 로 클래스를 초기화 시켜주는게 전부. c 로 짜여진 모듈을 가져다 사용할 때처럼 클래스를 사용해야한다면 이는 분명 잘못 설계된(남용된) 클래스다.

물론 인터페이스를 통해서만 접근하는 것은 내부 변수에 직접 접근할 때보다 느리다. 또한 생성자 소멸자, 그리고 함수 오버라이딩, 오버로딩 등을 지원하기 위해 성능을 희생해야할 지도 모른다. 하지만 코드의 재사용이라는 관점에서 클래스를 사용하는 것은 플러스 알파를 가져온다.

당시 제로보드에 사용되어진 클래스들은 재사용 등의 관점하고는 거리가 멀었다. 클래스를 사용하고는 있지만 실제 뭔가를 하려면 클래스를 사용하지 않을때와 별반 다르지 않은 코드를 작성해야하는 상황. 디비 클래스 정도만이 재사용이 가능한 정도였다고 기억한다. (다행히 XE의 코드는 그 때 코드와는 아주 달라보인다.)

뭐 어쨌거나 그 날 오프모임에서 내부 구현이 지저분하다라기보다 당시 제로보드의 클래스는 저랬다. 그 이후로는 안봐서 모르겠다란 얘기를 했었다. 지금와서 생각해보면 최근까지 제로보드를 지켜보고 있었던 것도 아니면서 경솔하게 얘기했었던 걸지도 모르겠다.

그리고 이건 지금도 적용되는 이야기!

그날 제로보드에 대해 비판했던 내용 중 패치 배포 방법에 대한 내용이 있었다. unix에는 diff, patch란 툴이 있다. 대강 어떤 식인지는 요 글을 보라!

http://mytears.org/resources/tmp/zb_patch/

위 url에 가보면 내 서버를 사용하고 있는 분들의 제로보드를 강제로 최신 버젼으로 올리기 위해 만들어놨던 제로보드 패치들을 볼 수 있다. 하여튼 diff를 이용하면 위와 같은 출력물이 나오고 patch 를 이용하면 구버젼의 제로보드에 패치와 관련된 코드를 아주 간단히 삽입할 수 있다. 이 툴들을 이용할 경우 코드의 패치를 배포하려 할 경우 패치가 완료된 파일을 배포하는 것이 아니라 수정된 사항만을 배포할 수 있다. 이 툴들은 매우 똑똑하기 때문에 사용자가 다른 부분을 수정하였더라도 내가 수정을 한 부분과 상관이 없으면 아무 문제 없이 이 변경 사항들을 적용시켜준다. 그렇기 때문에 만약 사용자들이 여기저기 수정을 해서 사용하는 시스템이라면 당연히 이런 툴들을 사용한 패치를 제공해야한다고 생각한다.

unix툴이라고 하니까 다 뭔가 대게 복잡할거 같다고 생각하지만 windiff, filemerge 등의 윈도우 GUI프로그램도 존재하고, 그 중에는 공개 소프트웨어도 있다. 사용하는데 그리 어렵지 않다는 얘기다. SVN 등의 버젼 관리 시스템을 이용한다면 이런 툴들의 존재를 모르진 않을텐데, ‘패치 방법: 어떤 파일을 덮어쓰시면 됩니다.’ 이런 공지가 아직까지 보이는 걸 보면 여전히 답답하다.

사실 문제가 되었던 글을 읽으면 그 때 뭔가 얘기가 많이 오간 듯한 분위기지만 사실 5분 내외의 아주 짤막한 내용이 전부였던 것 같은데, 하여튼 오프라인에서 술먹으면서 하는 얘기라도 말은 조금 조심해야겠다.

덧: 혹시나 관련 글들을 보고 기분이 상하셨던 분들이 계시다면 사과드리겠습니다. (_ _*) 꾸벅;

Published by

One thought on “제로보드 XE 관련 약간의 해명…”

  1. 안녕하세요 XE project haneul입니다. ^^;
    트랙백 남겨주셨길래 들려봅니다.

    다들 크게 신경쓰지 않고 있으니 상심할 것은 걱정하지 않으셔도 될꺼 같아요 ㅎㅎ;;;

    patch부분은 저희도 고민하고 있는 부분인데요
    혹 merge때문에 다른 문제들이 생기지 않을까 우려를 하는 분들이 있어서 어찌 할까 생각중이었습니다. (svn에서 conflict나는 것처럼요 ㅎㅎ)
    아마도 조만간 patch도 같이 배포하지 않을까 싶네요 ㅎㅎ
    좋은 지적 감사합니다.

    *. class부분은 XE에서는 재사용도 좀 하고 있고 그렇지만, 재사용성보다도 전체 구조를 모듈화하는 과정에 큰 도움이 되었다고 생각하고 있습니다 :) 장단점이 있겠지요 ^^

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">