뭐 저는 SI쪽 개발도 하지만 SI만 전문적으로 하는 개발자는 아닌데...
SI가 아닌 분야에서 폼이 백개 가까운 수준의 프로젝트는 해봤구요.

SI에서는 하나의 프로젝트에 보통 수백, 수천개 단위의 폼이 들어갑니다.
지금도 C++빌더로 3000개 수준의 SI 프로젝트를 준비하고 있구요.
델파이로는 폼 수천개 단위의 프로젝트는 몇번 해봤습니다.

관건은 두가지인데, 첫번째는 말씀하신대로 서큘러 참조를 가급적 피하는 겁니다.
C++의 특성상 서큘러 참조가 많으면 당연히 컴파일속도가 극악으로 떨어집니다.
(델파이등 다른 언어에서도 마찬가지지만 C++은 더 심하지요)

서큘러 참조 때문에 컴파일 속도가 느려진다는 느낌이 드신다면 모듈 설계가 꽤 잘못되었다고 생각되네요.
단지 컴파일 속도의 문제 뿐 아니라, 컴파일 속도가 빠른 델파이에서도 모듈간 의존성은 최대한 낮추어야
합니다.

두번째 관건은 프로젝트를 최대한 쪼개는 것입니다.
실무에서 폼 갯수가 100여개가 넘어가는 프로젝트는 보통 하나의 실행파일로 만들지 않습니다.
그리고 수백개 단위가 넘어가면 하나의 실행파일로 만드는 것은 미친짓입니다.

이것은 C++빌더 뿐만 아니라 델파이나 파워빌더, 비주얼 베이직이라도 마찬가지 문제입니다.
컴파일 시간도 많이 걸리지만, 의존성 때문에 개발단계에서도 작업이 효율적이지 못하고 또 유지보수도
어려워지는 등 여러 다른 문제들도 생깁니다.
델파이의 경우에도 단일 프로젝트 파일에 폼이 1000개 정도 들어가면 빌드에 10분 이상 걸립니다.

하지만 이렇게 프로젝트를 쪼개려고 해도 모듈간 의존성이 높으면 거의 불가능합니다.
그리고 지금은 컴파일 속도가 걱정스럽겠지만 프로젝트가 더 커지면 지금은 느끼지 못하시는 다른 문제들이
발목을 잡게 됩니다.

결과적으로, 프로젝트가 더 커질 가능성이 보인다면, 컴파일 시간을 낮추는 눈앞의 문제에 골몰하실 것이
아니라 모듈간 의존성을 최대한 낮추는 것이 급선무입니다.
공통 부분을 최대한 빼내고, 그리고 그 공통 부분도 몇가지 목적별로 각각의 부분으로 빼야 합니다.

또 폼끼리 서로 멤버를 이리저리 참조하는 식의 방식은 위험합니다.
프로젝트 전체에 있어 폼끼리 정보를 전달하는 방식을 정해놓고 그 방식을 벗어나는 꽁수는 급해도
쓰지 말아야 합니다.


나엑스 님이 쓰신 글 :
: 의문이 듭니다.
: 폼 5개 이상되고 폼끼리 circular 링크 시켜 컴파일 하면 프리 컴파일도 무용지물이 됩니다.
: 지금 폼이 10개이고 펜3에 램256이면 빌더6 개발 당시 충분히 받쳐주는 사양인데
: 전체 빌드가 아니고 make가 1분이 넘어갑니다.
: 팁란에 올리신거로 프리컴파일을 이용해보았는데 놀라울 정도로 빨라집니다. 잠시 기뻤습니다.
: 그렇나 circular 형태로 링크되면 이 것도 무용지물이 되는 군요.
: 윈도 프로그래밍 처음 시작했을 때 API노가다를 빌더가 해결해줘서 그 후로 쭉 빌더만 쓰는데
: 가끔 바꾸고 싶어집니다.T.T
: