Background Image
나머지...
2019.09.30 23:29

Doxygen으로 소스코드 문서화 해보기

조회 수 11992 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부

오픈소스 프로젝트를 이용해서 개발을 해보신 분들은 소스코드를 문서화한 레퍼런스 문서(또는 개발자 매뉴얼)을 참고해서 개발해 본 경험이 있을 것 같습니다. 개발자를 위한 이러한 문서는 기본적으로 프로젝트 빌드 방법, 주요 아키텍쳐 설명 등의 내용들을 담기도 하고 소스코드에서 정의한 변수나 구조체와 함수 같은 것들이 소스 파일을 직접 열어서 찾아보지 않아도 보기 좋게 정리하거나 변수나 함수 간의 관계를 정리해서 보여주기도 합니다.

다음과 같은 프로젝트의 문서를 예시로 참고해 볼 수 있겠네요.

공개 되어있는 코드를 한줄한줄 따라가보며 파악할 수도 있지만 프로젝트의 규모가 커지고, 코드의 복잡도가 증가할수록 개발자를 위한 문서는 중요해집니다. 왜냐하면 문서를 읽으면 소스코드를 훨씬 빠르게 파악할 수 있기 때문입니다. 이러한 문서 덕분에 다른 개발자가 조금 더 쉽게 내 프로젝트에 기여할 수 있게 된다면 내 프로젝트에 참여하고 기여해주는 사람들이 더 많아질 수 있는 좋은 선순환의 시작점이 될 수 있을 것입니다.

하지만 문서를 작성하는 것도 큰 비용입니다. 아무리 설계와 개발을 하면서 문서를 만들더라도 점점 덩치가 커지는 소스코드의 모든 변수와 함수를 문서화 하려고 한줄 두줄 옮겨 적어가는 것은 매우 비효율적이겠죠. 게다가 소스코드는 계속해서 바뀌기 때문에 최신화하는 비용도 만만치 않을것입니다.

 

그러면 조금 더 효율적으로 소스코드를 문서화 할 수 있는 방법은 무엇이 있을까요?

 

Doxygen - 소스코드 문서화 도구

소스코드를 문서화하기 위한 대표적인 도구로 Doxygen를 소개합니다. Doxygen은 코드를 기반으로 문서를 생성하여 작성되므로 비교적 최신 상태로 유지하기가 쉽습니다. 특히 문서와 코드를 상호 참조 할 수 있어 실제 코드를 쉽게 참조 할 수 있다는 장점이 있습니다.

아직 큐브리드에서는 공식적으로 소스코드 레퍼런스 메뉴얼을 지원하지는 않습니다. 공식 홈페이지에서 제공하는 유저 매뉴얼이 잘 설명되어 있긴 하지만, 오픈소스 프로젝트인 큐브리드의 소스코드를 읽어보고 기여해보고 싶은 개발자의 입장에서는 아쉬움이 큰 것이 사실입니다. 이 글에서 소개하는 도구를 시작으로, 이러한 문서를 만들어나가다보면 큐브리드 프로젝트에 무언가 기여해보고 싶어하는 개발자가 많아질 수 있을거라 기대합니다.

이제부터 큐브리드 소스코드를 기반으로 문서를 생성해보도록 하겠습니다.

다음 섹션부터 단계별로 진행할 명령어는 큐브리드의 빌드환경인 CentOS 7을 기준으로 작성하였습니다. 설치하는 도구는 다양한 운영체제를 지원하기 때문에 각 환경에 맞게 설치 후 명령어 도구로 진행하면 됩니다.

문서를 생성 할 코드 가져오기

큐브리드의 소스코드는 github 저장소에서 관리되고 있습니다. 경로는 다음과 같습니다.

다음의 git clone 명령어로 github의 큐브리드 소스코드를 복사해오는 명령어를 실행합니다. 꼭 git을 사용해서 코드를 가져올 필요 없이, 소스코드가 준비된 폴더 안에서 따라해보셔도 됩니다.

yum -y install git
git clone https://github.com/cubrid/cubrid
cd cubrid

 

Doxygen 설치하기

다음으로 Doxygen을 설치해보도록 하겠습니다. Doxygen에서 변수와 함수의 관계 그래프를 그리기 위해 graphviz라는 도구도 함께 설치합니다. 다른 운영체제의 경우 http://www.doxygen.nl/download.html를 참조하시면 됩니다.

yum -y install doxygen graphviz

 

Doxyfile 생성하고 설정하기

Doxyfile은 Doxygen으로 생성할 문서에 대한 설정 파일입니다. 다음 명령어로 Doxyfile을 생성할 수 있습니다.

doxygen -g my_conf 

 

이제 폴더 내에 my_conf라는 파일이 만들어진 것을 확인할 수 있습니다. my_conf 외에 다른 이름으로 지정하는 것도 가능합니다. 만들어진 파일 (my_conf)를 텍스트 에디터로 열어보면, 굉장히 복잡해 보이는 파일이 하나 생성된 것을 확인할 수 있습니다. 하지만 대부분 기본 값으로 채워져 있는 일종의 템플릿이고 주석에서 각 설정에 대해 자세히 설명되어 있는 것을 ㅂ 볼 수 있습니다. 따라서 모든 설정을 여기서 소개하긴 힘들어 몇 가지 주요한 설정을 소개하고 넘어가도록 하겠습니다.

 

이제부터 설명하는 설정을 한번 그대로 설정해보며 문서를 만들어보려고 합니다.

먼저 프로젝트 이름부터 설정해보겠습니다. 텍스트 에디터에서 PROJECT_NAME을 찾아 기본 값으로 "My Project"라고 설정되어 있는 부분을 원하는 이름을 입력합니다. 

저는 "CUBRID DOC"으로 입력해 보겠습니다.

PROJECT_NAME           = "CUBRID DOC"

 

다음으로 INPUT을 찾아 = 이후에 src/compat를 입력합니다. INPUT으로 입력할 파일 또는 폴더를 설정합니다. 큐브리드는 큰 프로젝트라 생성이 오래 걸리기 때문에 이 예제에서는 큐브리드의 src/compat 폴더 내의 소스 파일에 대해서만 생성하려고 합니다.

INPUT                  = src/compat

 

이제 어떻게 Doxyfile 문서를 수정하는지 조금씩 감이 오실 것 같습니다. 간단한 설명과 함께 계속 따라해보겠습니다.

# 입력하려는 파일의 확장자를 지정할 수 있습니다.
FILE_PATTERNS          = *.c \
                         *.cc \
                         *.cxx \
                         *.cpp \
                         *.c++ \
                         *.h \
                         *.hh \
                         *.hxx \
                         *.hpp \
                         *.h++

# 문서가 생성될 경로를 지정합니다.
OUTPUT_DIRECTORY       = build_doc

# HTML로 된 문서만을 생성합니다.
GENERATE_HTML          = YES
GENERATE_LATEX         = NO

# 소스코드의 모든 요소를 문서화 대상으로 합니다.
EXTRACT_ALL            = YES

 

이제는 소스코드로부터 다음의 그림과 같은 Caller 그래프를 그리기 위한 설정입니다.

caller_graph.PNG

CALLER_GRAPH는 어떤 함수를 호출하는 다른 함수에 대한 관계를 그려주는 그래프입니다. 이 설정 외에도 CALLER_GRAPH와 같은 섹션에 있는 다른 설정들을 이용해서 여러가지 그래프를 그려 볼 수 있습니다.

CALLER_GRAPH           = YES

 

위에서 설명한 설정 외에도 수 많은 설정이 있습니다. Doxyfile에서 모두 기본값으로 설정되어 있으니 나중에 자신의 프로젝트에 맞게 여러가지 설정을 바꾸어보며 테스트 해보시면 됩니다.

 

설정한 Doxyfile을 사용해서 소스코드 레퍼런스 문서 생성

이제 doxygen 명령으로 doxyfile에서 설정한대로 문서를 생성할 수 있습니다. 쉽게 다음 명령어로 생성해봅시다.

doxygen my_conf 

 

명령어를 입력하면 Parsing ...과 Generating .... 으로 시작하는 로그를 보실 수 있습니다. 문서 생성 과정이 끝나면 OUTPUT_DIRECTORY에서 입력한 build_doc 폴더내의 html를 들어가보면 index.html 파일이 있습니다. 이 파일을 열어보면 다음 그림과 같은 화면을 볼 수 있습니다.

cub_doxy.PNG

 

상단의 Classes을 눌러보면 소스코드에서 정의된 구조체 또는 클래스를 확인할 수 있습니다.

cub_struct.PNG

 

구조체의 이름을 눌러 들어가보면 (e.g. db_domain_info) 다른 구조체와의 관계 그래프도 표시하고 있는 것을 확인할 수 있습니다.

doxy_st.PNG

cub_domain.PNG

 

마찬가지로 상단의 Files 탭을 클릭하면 파일의 목록을 볼 수 있습니다.

cub_files.PNG

 

파일 이름을 클릭해보면 다음과 같은 그림을 볼 수 있습니다. 이 파일이 어떤 다른 헤더를 include 하는지 그려주기도 하고 어떤 변수와 함수를 정의하고 있는지 문서화하여 보여줍니다.

cub_doc.PNG

cub_fun.PNG

마무리

여기까지 Doxygen을 이용해서 큐브리드 소스코드의 레퍼런스 문서를 만들어보았습니다. 간단히 Doxygen에 대해 소개하기 위한 목적으로 작성했기 때문에 이 강력한 도구를 충분히 설명하기엔 부족합니다. 이 글에서 Doxygen가 가진 기능을 모두 다루어보지는 못하였지만, Doxygen 매뉴얼을 참고하여 조금만 사용해보면 여러분이 지금 수행하고 있는 프로젝트의 소스코드를 문서화할 때 하나의 좋은 옵션이 될 수 있을 것으로 기대합니다.

 

마무리를 하려니 무언가 찝찝함이 남습니다. 서론에서 "소스코드는 계속해서 바뀌기 때문에 최신화하는 비용도 만만치 않다"고 언급했었습니다. 소스코드가 바뀔때마다 doxygen으로 생성하고, 생성된 문서를 배포하는 과정도 비용입니다. 이 부분에 대해서는 다음 글에서 Travis CI와 Github pages를 이용해서 최신화된 코드에 대해 Doxygen으로 문서를 배포하는 방법에 대해 소개할 예정입니다.

 

긴 글 읽어주셔서 감사합니다.

 

참고 자료


  1. CUBRID vs. Oracle 총소유비용(TCO) 비교

    작년 말 CIO BIZ+ 기사를 통해 오라클이 서버용 SW 라이선스 정책을 수정했다는 내용을 확인하게 되었습니다.   내년부터 HP서버용 오라클 SW 가격 ‘2배’...썬은 50%↓   기사 내용의 요지는 스팍 프로세서의 라이선스 팩터(코어에 대한 라이선스 가중치)를 0.75에서 0.5로 내리고, HP 아이테니엄 프로세서(팩터 0.5)와 IBM 파워 프로세서(팩터 0.75)에 대한 팩터는 1로 조정을 함으로써 HP/IBM 서버 기반으로 Oracle DBMS를 구축할 경우 라이선스 비용이 증가하게 되었다는 것입니다(Oracle for HP는 100%, Oracle for IBM은 33% 가격 인상 효과). 반대로 SUN 서버 + Oracle 조합으로 구매하는 사용자는 DBMS 라이선스에 대한 비용을 절감할 수 있고요.   IBM이야 자체적으로 DBMS 제품(DB2)을 보유하고 있기 때문에 상대적으로 영향을 덜 받겠지만, HP는 상황이 달라지는 것 같습니다. 최근 코리아크레딧뷰로(KCB)가 유닉스 서버 가상화 및 통합 사업을 진행하면서 기존 HP 서버를 IBM 서버로 전면 교체하기로 결정을 했다고 합니다(관련 기사: HP 유닉스서버, 오라클 가격인상 직격탄 맞다). 반면 MS와의 협력을 강화하여 어플라이언스 4종을 발표하는 행보를 보이고 있고요(...
    Date2011.01.29 Category라이선스 고찰 By정병주 Views44635 Votes0
    Read More
  2. CUBRID 서비스 계약에 대한 이해 – 독립 소프트웨어 벤더(ISV)

    지난 달에 최종사용자(End-user)를 위한 CUBRID 서비스 계약에 대해 간략하게 살펴보았습니다. 금번에는 독립 소프트웨어 벤더(ISV: Independent Software Vendor)들이 CUBRID 기반으로 응용 소프트웨어(애플리케이션)를 개발/포팅하여 판매하는 경우에 대해서 설명을 드리도록 하겠습니다.   우선, CUBRID는 오픈소스 DBMS이고, DBMS 엔진은 GPL v2 or higher, 인터페이스는 “BSD 라이선스”를 적용하고 있다는 것은 잘 알고 계실 것입니다. 여기서 인터페이스 함은 JDBC, PHP, ODBC, OLEDB, CCI (C Client Interface) 등을 의미하며, 일반적으로 DBMS 기반의 애플리케이션을 개발할 때 주로 사용합니다. 따라서, CUBRID는 ISV들이 애플리케이션 개발/포팅을 완료한 후 최종사용자를 대상으로 비즈니스를 전개할 때 애플리케이션 소스코드를 공개할 필요가 없으며, 이와 관련된 상세한 내용은 “차별화된 라이선스 정책, 큐브리드 OSS 라이선스 가이드”를 참고하시기 바랍니다.      첫번째 모델은 ISV가 큐브리드사 기술지원 서비스 계약 없이 자체적으로 애플리케이션을 개발하여 판매하는 방식입니다. 주로 소규모의 애플리케이션에 적합하며, 최종사용자에 대한 CUBRID 기술...
    Date2010.11.16 Category라이선스 고찰 By정병주 Views33505 Votes0
    Read More
  3. CUBRID 서비스 계약에 대한 이해 – 최종사용자

    CUBRID는 오픈소스 라이선스를 채택하고 있습니다. DBMS 엔진은 GPL v2 or higher, 인터페이스는 BSD 라이선스를 적용하고 있으며, 소프트웨어 사용에 아무런 제약조건이 없습니다. 따라서 상용 소프트웨어와 같이 소프트웨어 라이선스(사용권)를 얻기 위해 비용을 지불할 필요가 없습니다. (참고: CUBRID 라이선스 및 서비스 정책에 대한 고찰)     CUBRID는 별도의 라이선스 비용 없이 서비스 비용만 지불하면 되며, 고객들을 만날 때 자주 질문 받는 내용 중 하나인 서비스 정책과 계약 방법에 대해 살펴 보도록 하겠습니다.   CUBRID의 서비스 정책은 크게 프로페셔널 서비스와 서포트 서비스로 나뉘어집니다.      프로페셔널 서비스는 개발 단계에서 제공되는 서비스로서 DB 설계 지원, 스키마 리뷰, 질의 리뷰, 데이터 변환 및 성능 튜닝 서비스 등이 포함되어 있습니다. 비용은 시간당 9만원(VAT 별도)이며, 지원 받고자 하는 시간만큼 계약을 체결하고 서비스를 제공 받으시면 됩니다.   응용 개발이 끝나면 일반적으로 운영 단계로 넘어갑니다. 운영 단계에서는 정기적인 예방점검(PM: Preventive Maintenance)을 통해 문제 발생을 선제적으로 방지하고, 각종 온라인...
    Date2010.10.12 Category라이선스 고찰 By정병주 Views36014 Votes0
    Read More
  4. CUBRID 라이선스 및 서비스 정책에 대한 고찰

    작년 11월 CUBRID가 오픈소스 DBMS로 전환하면서 라이선스 정책도 새롭게 발표되었습니다. DBMS 엔진은 GPL v2, 인터페이스는 BSD 라이선스. 엔진과 인터페이스를 구분하여 서로 다른 라이선스를 채택하였는데, 자세한 내용은 ‘차별화된 라이선스 정책, 큐브리드 OSS 라이선스 가이드’를 참고하시기 바랍니다. CUBRID가 라이선스 정책을 구분하여 적용한 배경이 궁금해지실 텐데요, 우선 GPL 라이선스는 소스 코드의 수정 및 배포가 자유로운 반면, 2차 저작물에 대한 재공개 의무가 있습니다. 즉, 수정된 소스 코드는 GPL 라이선스 하에 모두 공개되어 다른 개발자와 사용자들에게 공유되어야 하며, CUBRID가 엔진 소스 코드에 대한 라이선스를 GPL로 결정한 것도 동일한 컨텍스트(context)에서 이해해 주시면 될 것 같습니다. 반면, CUBRID 인터페이스는 BSD 라이선스를 채택하였는데, BSD 라이선스는 2차 저작물에 대한 재공개 의무가 없고, 독점 소프트웨어와의 결합이 가능합니다. 따라서, DBMS 기반의 응용 개발자나 독립소프트웨어벤더(ISV) 입장에서 자신 혹은 자사가 개발한 애플리케이션의 소스 코드를 공개하고 싶지 않은 경우에도 사용 상 특별한 제약...
    Date2009.05.27 Category라이선스 고찰 By정병주 Views51379 Votes0
    Read More
Board Pagination Prev 1 Next
/ 1

Contact Cubrid

대표전화 070-4077-2110 / 기술문의 070-4077-2113 / 영업문의 070-4077-2112 / Email. contact_at_cubrid.com
Contact Sales