알짜게시판

Delphi 프로젝트 구조와 dproj 설정 역할

Delphi 프로젝트를 유지보수하면서 기존에는 IDE가 자동으로 메인 폼을 열어주는 흐름에 크게 신경 쓰지 않았다. 기본적으로 .dproj 파일은 빌드 설정이나 컴파일 옵션 정도만 담고 있다고 인식하고 있었고, 실제 UI 구성은 .pas와 .dfm 파일이 담당한다고 이해했다. 이 구조에서는 IDE가 프로젝트를 로드할 때 어떤 유닛이 폼인지 자동으로 판단한다고 생각하기 쉽다.

하지만 최근 프로젝트를 정리하면서 일부 유닛을 이동하고 참조를 재구성하는 과정에서 동작 방식이 달라졌다. 동일한 코드 구조를 유지하고 있음에도 메인 폼이 자동으로 열리지 않는 상황이 발생했다. 기존에는 프로젝트 로드 시 바로 디자인 화면이 표시되던 흐름이었는데, 변경 이후에는 코드만 열리고 UI가 보이지 않았다.

이 시점에서 .dproj 파일이 단순 설정 파일이 아니라 IDE 동작에 직접 관여한다는 점을 확인하게 됐다. 특히 <ItemGroup> 내부의 <DCCReference> 항목이 단순 참조가 아니라 메타데이터 역할을 한다는 점이 핵심이었다.

Delphi IDE 메인 폼 안열림 증상과 조건 변화

프로젝트를 다시 열었을 때 나타난 동작은 일정한 패턴을 보였다. Main.pas는 정상적으로 열리지만 디자인 탭이 생성되지 않고, “View as Form” 메뉴를 선택해도 아무 반응이 없거나 빈 화면만 나타났다. 이 상태에서는 런타임 실행은 문제없이 진행되지만 IDE 내에서 폼을 수정할 수 없는 상태가 된다.

이 변화는 특정 IDE 버전 변경이나 컴포넌트 문제와는 무관했다. 동일한 IDE 환경에서 기존 프로젝트는 정상적으로 폼이 열렸고, 문제는 특정 프로젝트에서만 재현되었다. 따라서 원인을 환경이 아닌 프로젝트 구성으로 좁힐 수 있었다.

특히 .dproj 파일을 Git으로 관리하는 과정에서 일부 항목이 누락되거나 단순화된 것이 확인됐다. 기존에는 자동 생성된 설정이 유지됐지만, 수동 정리 과정에서 <Form> 관련 정보가 제거된 상태였다.

dproj 파일 내 Form 메타데이터 누락 원인 분석

Delphi IDE는 .pas 파일 내부만으로 해당 유닛이 폼인지 판단하지 않는다. 대신 .dproj 파일의 <DCCReference> 항목을 기준으로 폼 여부를 식별한다. 이 과정은 다음과 같은 흐름으로 동작한다.

입력: 프로젝트 로드 시 .dproj 파일 읽기
조건 판단: <DCCReference> 항목 내 <Form> 존재 여부 확인
처리 방식 선택: <Form>이 있으면 폼 유닛으로 인식, 없으면 일반 코드로 처리
실행: 폼 유닛일 경우 .dfm과 연결하여 디자인 로드
결과: IDE에서 자동으로 폼 표시 여부 결정

문제가 된 구조는 다음과 같았다.

<DCCReference Include="Main.pas"/>

이 상태에서는 IDE가 Main.pas를 일반 유닛으로 인식한다. 실제 코드에는 TForm이 정의되어 있고 {$R *.dfm}도 포함되어 있지만, .dproj 기준으로는 UI 메타정보가 없는 상태다. 따라서 디자인 뷰를 자동으로 연결하지 않는다.

Delphi 메인 폼 자동 표시를 위한 설정 과정

문제를 해결하기 위해 .dproj 파일을 직접 수정했다. 수정 과정은 총 3단계로 정리할 수 있다.

첫 번째 단계는 메인 폼 유닛을 찾는 것이다. 보통 Application.CreateForm에서 사용되는 유닛이 기준이 된다. 이 프로젝트에서는 Main.pas가 해당했다.

두 번째 단계는 <DCCReference> 항목에 폼 정보를 추가하는 것이다. 수정된 구조는 다음과 같다.

<DCCReference Include="Main.pas">
    <Form>Form1</Form>
    <FormType>dfm</FormType>
</DCCReference>

여기서 <Form>은 폼 변수명이며, 코드 내에서 선언된 인스턴스 이름과 일치해야 한다. <FormType>은 리소스 형식으로, VCL 환경에서는 dfm을 사용한다.

세 번째 단계는 IDE 재시작 후 프로젝트를 다시 로드하는 것이다. 이 과정을 거치면 IDE는 .dfm과 .pas를 연결하여 자동으로 디자인 화면을 생성한다.

이 설정 적용까지 걸린 시간은 약 10분 정도였고, 별도의 빌드 과정 없이 즉시 반영됐다.

TFrame 유닛과 Form 설정 차이 비교

프로젝트에는 TForm 외에도 여러 TFrame 유닛이 포함되어 있었다. 이 경우 동일한 방식으로 <Form> 설정이 필요한지 확인이 필요했다.

결론적으로 TFrame은 별도 설정 없이도 디자인 뷰가 정상적으로 열렸다. 예를 들어 다음과 같은 구조는 문제가 없었다.

<DCCReference Include="FrameOption.pas"/>
<DCCReference Include="FrameInfo.pas"/>

이 차이는 내부 처리 방식에서 발생한다. TFrame은 {$R *.dfm} 지시문을 통해 IDE가 직접 리소스를 연결할 수 있기 때문에 .dproj의 <Form> 정보가 필수는 아니다. 반면 TForm은 프로젝트 진입 시점에서 어떤 폼을 먼저 로드할지 결정해야 하므로 .dproj 기반 메타데이터가 필요하다.

따라서 선택 기준은 다음과 같이 정리할 수 있다.
메인 UI 진입점 역할을 하는 폼은 <Form> 설정 필요
재사용 UI 구성 요소인 프레임은 설정 없이 유지

이 기준을 적용하면 불필요한 설정을 줄이면서도 IDE 동작을 유지할 수 있다.

dproj 구조 정리 시 적용 기준과 활용 범위

.dproj 파일을 정리할 때는 단순히 항목을 줄이는 것이 아니라 IDE 동작 기준을 유지하는 것이 중요하다. 특히 메인 폼이 하나인 프로젝트에서는 해당 유닛에만 <Form> 정보를 유지하고 나머지는 제거하는 방식이 관리에 적합하다.

이 설정은 다음과 같은 상황에서 유효하다.
프로젝트 구조를 단순화하거나 Git 충돌을 줄이려는 경우
여러 개발자가 동시에 .dproj를 수정하는 환경
폼과 프레임이 혼합된 구조에서 역할을 명확히 구분해야 하는 경우

반대로 모든 유닛에 <Form>을 추가하는 방식은 관리 비용만 증가하고 실제 동작에는 영향을 주지 않는다. IDE는 필요한 정보만 참조하기 때문에 최소한의 메타데이터 유지가 적절하다.

이 방식은 VCL 기반 프로젝트뿐 아니라 FMX 프로젝트에서도 동일하게 적용된다. 다만 <FormType> 값은 환경에 따라 달라질 수 있으므로 해당 프레임워크에 맞게 설정해야 한다.