디렉터리 구조에 관한 실용적 고찰

2006-07-27 신영진

처음 혼자서 배우면서 프로그래밍을 할 때에는 그다지 큰 문제가 되지 않지만 회사에서 프로젝트를 하게 되면 디렉터리 구조에 대해서 생각하게 된다. 그 이유는 한 프로젝트에 여러 개의 프로젝트가 포함되기도 하고, 같은 프로젝트 파일에서 다른 바이너리를 생성해 내야 하는 일도 생기기 때문이다. 즉, 쉽게 이야기 하자면 프로젝트의 크기가 커지기 때문에 그러한 것이 관해서 고민하게 된다고 할 수 있다. 이 문서는 그러한 문제에 대해서 중간 크기 정도의 프로젝트에 적합한 실용적인 디렉터리 구조와 왜 실용적인지를 설명한다.

일반적인 VC++의 디렉터리 구조

solution_name
    + 솔루션 파일
    +- module_name
        +- Debug
            + 디버그 중간 파일및 실행 파일
        +- Release
            + 릴리즈 중간 파일및 실행 파일
        + 소스및 프로젝트 파일

    +- module_name2
        +- Debug
        +- Release
        + 소스및 프로젝트 파일

일반적으로 VC++ .NET 2003이상의 버전에서 기본적으로 생성되는 디렉터리 구조는 위와 같다. 이 디렉터리 구조는 여러 가지 문제를 가지고 있다. 일단 가장 큰 문제는 실행 결과가 합쳐지지 않는다는 점이다. 모듈이 dll과 exe라고 생각해 보자. 이 경우 exe가 dll을 필요로 한다고 생각하면 위의 구조와 같은 환경에서는 빌드된 dll을 exe가 있는 곳으로 직접 복사해야 한다. 둘재는 소스와 프로젝트 파일이 분리되지 않는다는 점이다. 동일한 소스를 다른 환경으로 빌드하기 위해서 소스만 뽑아 내기가 굉장히 번거롭다. vcproj 파일 및 다른 파일만 제외하고 복사를 해야 하는데 이는 상당히 번거로운 작업이다. 또한 다른 매체로 백업을 해야 하는 경우에 중간 파일의 제거가 되지 않기 때문에 별로 합리적인 구조가 아니다. 또한 cvs등의 버전 관리 툴을 사용하는 경우에도 Debug, Release등을 별도로 제거해 주어야 하는 단점이 있다.

위의 구조를 발전시킨 디렉터리 구조

project_name
    + bin
        +- checked
        +- free

    + common
        +- inc
        +- lib

    + app
        +- module_name
            +- Debug
            +- Release

    + activeX
        +- module_name
            +- Debug
            +- Release

필자가 근무했던 한 회사에서는 위와 같은 디렉터리 구조를 사용했었다.  이 구조는 기본적인 구조 보다는 한 단계 발전 했다고 볼 수 있다. 출력 디렉터리(bin)를 통일 했으며, 공용 헤더와 라이브러리를 저장할 수 있는(common) 디렉터리가 존재한다. 하지만 여기도 몇 가지 단점이 존재한다. app, activeX, dll, driver등으로 모듈 형태별로 폴더를 나눌 필요가 없다는 점이다. 대부분의 중소 규모의 개발에서는 모듈 이름만으로도 해당 모듈이 어떤 모듈인지를 바로 알 수 있다. 이런 것을 굳이 폴더를 나누어 구분할 필요가 없는 것이다. 그리고 중간 빌드 파일이 모이는 Deub, Release와 checked, free 사이에 용어 불일치가 존재한다. 또한 이 디렉터리 구조 역시 첫 번째에서 지적했던 소스 파일의 분리 및 중간 파일 제거가 어렵다는 문제는 극복하지 못하고 있다.

좀 더 복잡한 디렉터리 구조

project_name
    +- bin
    +- src
    +- doc

$2에서 소개한 것보다 더 복잡한 단계가 위 단계라고 할 수 있다. src 폴더 밑에는 $2나 $1에서 소개한 구조가 그대로 나타난다고 생각하면 된다. 이 경우는 doc 폴더를 추가해서 프로젝트와 관련된 문서를 저장할 수 있는 공간을 확보했다는 것을 장점으로 들 수 있다. 하지만 $1, $2의 디렉터리 구조를 그대로 사용하기 때문에 그 구조가 가지는 단점을 극복할 수 없다. 또한 디렉터리 구조가 상당히 복잡해 지면서 상대 경로를 구성할 때에도 ..을 몇 개를 구성해야 루트까지 가는지 알기 힘들다는 문제까지 가지고 있다.

실용적인 구조

company
    +- bin
        +- Debug
        +- Release
        +- Objs
            +- module_name
                +- Debug
                +- Release
    +- common
        +- 공용 헤더및 라이브러리

    +- module_name
        +- docs
            + 문서들
        +- projects
            + 솔루션및 프로젝트 파일
        + distribute
            + 배포시에 같이 있어야 하는 파일
        + 소스들
     +- module_name2
        + ...

위 구조는 필자가 생각해본 중,소 규모 프로젝트에 실용적인 구조다. 일단 이 구조의 경우 가장 큰 특징은 소스, 프로젝트 파일, 중간 파일, 결과 파일의 분리가 확실하다. 소스는 company/module_name에 저장된다. 프로젝트 파일은 company/module_name/projects에 저장된다. 중간 파일은 company/bin/Objs/module_name/configuration_name에 저장되고, 결과 파일은 company/bin/debug내지는 reelase에 저장된다. 이렇게 함으로써 위에서 제기한 거의 대부분의 문제가 해결된다. 폴더 구조도 company 밑에 module_name이 바로 나오기 때문에 복잡해 지지 않는다. docs 폴더의 경우 module별로 필요하지 않다고 생각된다면 외부로 빼버리면 된다.

하지만 이 구조를 효율적으로 사용하기 위해서는 몇 가지 알아야 할 점이 있다. 우선, sln 파일과 vcproj 파일을 수동으로 다룰줄 알아야 한다. 왜냐하면 이 파일들을 projects밑에 모두 생성해야 하는데 IDE를 통해서는 그 작업이 쉽지 않기 때문이다. 필자의 경우 프로젝트 유형별로 템플릿 프로젝트 파일들을 만들어 두고 그것을 복사해서 사용한다. 이 경우 새로운 프로젝트를 만들때 수정해야 할 부분은 vcproj 파일의 GUID와 프로젝트 이름이 전부다. 또한 각 프로젝트 별로 아래와 같이 폴더를 지정해 주어야 한다.