Direct2D 프로젝트 설정: 소스와 빌드 산출물 분리

폴더를 먼저 옮기기보다 설정부터 읽기

소스를 보관하는 Project 폴더와 실행 결과가 생성되는 Output 폴더를 나누면 개발 파일과 배포 대상을 구분하기 쉽습니다. 폴더 이름보다 중요한 것은 빌드 설정이 실제로 그 경로를 사용하게 하는 것입니다. 이미 만들어진 프로젝트 파일을 수동으로 옮기면 상대 경로가 깨질 수 있습니다. 새 연습 프로젝트라면 처음부터 원하는 구조로 만들고, 기존 프로젝트라면 버전 관리에 현재 상태를 남긴 뒤 출력·중간 경로부터 조정하는 편이 안전합니다.

솔루션은 여러 프로젝트를 묶는 단위이고, 프로젝트는 컴파일할 파일과 옵션 등을 정의합니다. Visual Studio의 필터 폴더가 디스크 폴더와 반드시 같지는 않다는 점도 확인합니다. 빌드가 성공했는데 실행 파일이 예상 위치에 없다면 탐색기의 모양보다 프로젝트 속성에 설정된 실제 경로를 먼저 보세요.

구성과 플랫폼을 경로에 포함하기

Debug와 Release, x64와 다른 플랫폼의 중간 파일이 같은 경로를 사용하면 오래된 결과가 섞여 진단하기 어려워집니다. 아래 값은 한 가지 예시입니다. 디렉터리 끝의 구분자를 유지하고, 모든 구성에 적용할 설정인지 현재 구성에만 적용할 설정인지 확인합니다. 게임 에셋 경로는 실행 파일의 위치와 디버거 작업 디렉터리의 차이에도 영향을 받습니다.

출력 디렉터리:
$(SolutionDir)Output\$(Platform)\$(Configuration)\

중간 디렉터리:
$(SolutionDir)Intermediate\$(ProjectName)\$(Platform)\$(Configuration)\

Direct2D 예제의 추가 종속성:
d2d1.lib;dwrite.lib;windowscodecs.lib;%(AdditionalDependencies)

Windows GUI 프로젝트:
링커 > 시스템 > 하위 시스템 = Windows

컴파일, 링크, 실행 오류를 나누어 찾기

헤더를 찾지 못하면 Windows SDK와 C++ 개발 도구 설치, include 설정을 확인합니다. 함수 선언은 보이는데 외부 기호를 찾지 못하면 링크 라이브러리와 구성·플랫폼을 봅니다. main 또는 wWinMain 관련 링크 오류라면 함수 이름을 마구 바꾸기보다 하위 시스템과 진입 함수의 형식이 맞는지 확인합니다. Direct2D를 배우는 예제에 불필요한 오래된 SDK를 무조건 추가하는 방식은 피합니다.

Debug는 개발 중 진단에 유리한 설정이고 Release는 배포를 염두에 둔 구성이지만, 이름만으로 최적화나 디버그 정보가 결정되는 것은 아닙니다. 실제 옵션을 확인해야 합니다. Output 폴더만 복사하면 반드시 실행된다고 보장할 수도 없습니다. 런타임 의존성, 리소스 파일, 라이선스와 대상 운영체제를 함께 점검해야 합니다.

1. x64 Debug를 빌드하여 출력 경로와 정상 종료를 확인합니다.
2. x64 Release를 별도로 빌드하고 Debug 결과에 의존하지 않는지 확인합니다.
3. 개발 디렉터리와 다른 테스트 폴더에서 필요한 파일만으로 실행해 봅니다.
4. 빌드 산출물은 소스 이력에 무심코 포함하지 않도록 제외 규칙을 확인합니다.