이클립스 빌드가 유독 느릴 때, Contacting Software Sites와 XML 검증 최적

이클립스 빌드가 느린데, 왜 하필 XML에서 멈출까

이클립스에서 워크스페이스 빌드를 돌리다가 유독 XML 구간에서 멈춘 듯 느려지는 경험, 한 번쯤은 겪습니다. 실제로는 XML이 무거워서라기보다, 이클립스가 XML을 다룰 때 뒤에서 하는 일이 많아서 시간이 길어지는 경우가 더 흔합니다. 특히 Contacting Software Sites 창이 함께 보이거나, 진행 상태가 “Validating…”에 오래 머물면 네트워크와 검증 설정이 동시에 얽혀 있을 가능성이 큽니다.

겉으로는 “빌드가 느리다”처럼 보이지만, 속을 뜯어보면 업데이트 사이트 접속 시도, 외부 DTD/XSD 확인, Maven 의존성 해석과 다운로드가 묶여서 시간을 잡아먹는 경우가 많습니다.

방화벽이나 프록시가 있는 환경에서는 이 과정이 더 길어지고, 타임아웃이 반복되면 체감상 거의 멈춘 것처럼 보이기도 합니다.

Contacting Software Sites가 빌드 중에 끼어드는 진짜 이유

Contacting Software Sites는 단순히 “업데이트를 확인한다”는 뜻만은 아닙니다.

먼저 플러그인 업데이트 확인이 자동으로 켜져 있거나, 설치된 기능들이 시작/빌드 타이밍에 외부 저장소 상태를 확인하도록 되어 있으면 빌드 흐름 중간에 네트워크 작업이 섞일 수 있습니다.

사내망처럼 외부 접속이 제한된 환경에서는 접속 시도 자체가 지연으로 이어지고, 결국 빌드 체감 속도가 급격히 떨어집니다.

이 현상은 CPU나 디스크 사용량이 높지 않은데도 시간이 오래 걸리는 특징이 있습니다. “컴퓨터가 바빠서 느린 게 아니라, 기다리는 시간이 긴” 전형적인 패턴입니다. 이 경우에는 업데이트 자동 확인을 꺼두는 것만으로도 빌드 중 끼어드는 멈칫 현상이 크게 줄어드는 편입니다.

업데이트 관련 지연이 자주 만드는 증상

빌드를 눌렀는데 어느 순간 진행이 멈춘 것처럼 보이고, 조금 뒤에 Contacting Software Sites 창이 떠서 한참을 기다리게 됩니다.

또는 이클립스를 실행할 때도 동일한 창이 반복적으로 보이며, 그 뒤에야 작업이 정상적으로 이어집니다. 이럴 때는 빌드 성능 개선을 고민하기 전에, 업데이트/네트워크 확인이 언제 어떻게 실행되는지부터 정리하는 편이 빠릅니다.

XML이 느려지는 핵심은 외부 DTD/XSD 확인이 발동하는 순간

XML 파일 상단에 DOCTYPE 선언이나 schemaLocation이 들어가면, 이클립스가 문서의 문법과 구조를 확인하기 위해 외부 리소스를 따라가려는 경우가 있습니다.

예를 들어 DTD나 XSD가 http/https 주소로 연결되어 있으면, 이클립스는 빌드나 저장 타이밍에 해당 주소로 접근을 시도할 수 있습니다. 방화벽이 막거나 프록시가 필요하면 여기서 대기 시간이 길어지고, 타임아웃이 쌓이면 XML 한 파일이 아니라 워크스페이스 전체가 느려집니다.

즉, XML 자체가 느린 게 아니라 XML을 검증하기 위해 외부로 나가려는 시도가 느린 겁니다. 특히 “저장할 때도 느리고, 빌드할 때는 더 느린” 패턴이라면 이 가능성이 높습니다.

빌드가 느려지는 포인트를 한눈에 정리

구간	화면/로그에서 보이는 힌트	느려지는 이유	개선 방향
업데이트 확인	Contacting Software Sites	업데이트 사이트 접속 시도, 방화벽/프록시 지연	자동 업데이트 확인 정리, 소프트웨어 사이트 정돈
XML 검증	Validating…, 저장/빌드 시 멈칫	외부 DTD/XSD를 따라가려는 시도, 타임아웃 반복	검증 옵션 조정, XML Catalog로 로컬 매핑
Maven 해석/다운로드	Maven Project Builder, dependency 관련 처리	의존성 해석, 사내망에서 리포지토리 접근 지연	사내 미러(Nexus/Artifactory), 로컬 repo 최적화

설정에서 체감이 확 달라지는 지점들

이클립스는 기본적으로 “정확하게 확인하고 넘어가자”는 성향이 강합니다. 문제는 네트워크가 느리거나 막혀 있는 환경에서 그 성향이 그대로 빌드 지연으로 나타난다는 점입니다. 그래서 여기서 중요한 건 “무조건 끄기”가 아니라, 빌드 때 꼭 필요한 검증만 남기고 나머지는 필요한 순간에만 확인하도록 정리하는 쪽입니다.

Validation 설정이 체감에 미치는 영향

워커 스레드에서 돌아가는 검증이 아니라, 워크스페이스 전체 흐름을 묶어버리는 검증이 섞이면 저장 한 번에도 작업이 끊기는 느낌이 납니다. 이럴 때는 XML Validator가 빌드 타이밍에 항상 동작하는지, 저장할 때마다 외부 리소스를 확인하는지부터 점검하는 편이 좋습니다. 필요한 경우에는 워크스페이스 빌드에서는 검증을 약하게 두고, 릴리즈 직전이나 변경 범위가 큰 날에만 수동 검증을 하는 방식이 현실적인 균형점입니다.

XML Catalog를 쓰면 “외부로 나가려는 습관” 자체를 끊을 수 있다

가끔은 검증을 완전히 끄는 게 불안할 때가 있습니다. 그럴 때 효과적인 방식이 XML Catalog입니다. 외부 DTD/XSD URL을 로컬 파일로 연결해두면, 이클립스는 인터넷을 찾지 않고 로컬로 해결합니다. 방화벽 환경에서 느려지던 원인을 아예 제거하는 방식이라, 프로젝트 특성상 XML이 많을수록 효과가 크게 느껴집니다.

Maven dependencies가 섞이면 “XML이 느린 것처럼” 보이는 이유

pom.xml도 XML이라서 그렇습니다. 워크스페이스 빌드 시점에 m2e가 POM 변경을 감지하면 의존성을 다시 계산하고, 필요한 경우 다운로드나 메타데이터 갱신을 시도합니다. 네트워크가 느리면 이 지연이 XML 구간처럼 보이고, 반대로 로컬 디스크가 느리거나 보안 프로그램이 .m2를 강하게 검사해도 비슷한 체감이 생깁니다.

이미 .m2 repository를 D드라이브로 옮겨둔 상태라면 방향은 좋습니다. 다만 D드라이브라고 무조건 빨라지는 건 아니고, 보안 프로그램이 해당 경로를 실시간 검사 대상으로 두고 있으면 파일을 열고 닫는 과정이 늘어져서 Maven 처리 시간이 길어질 수 있습니다. 의존성 개수가 많고 작은 파일이 수만 개 쌓이는 Maven 구조 특성상, 이 차이는 꽤 크게 느껴집니다.

빌드 지연이 “다운로드 문제인지, 로컬 IO 문제인지” 구분하는 감

빌드할 때 네트워크가 잠깐씩 튀거나, 진행 표시가 멈추는 구간이 일정하게 반복되면 다운로드나 메타데이터 갱신이 얽혔을 가능성이 높습니다. 반면 디스크 LED가 계속 반짝이고 CPU는 낮은데 시간이 오래 걸린다면, 로컬 저장소 접근 자체가 느려진 케이스일 수 있습니다. 여기에서 사내 리포지토리 미러를 쓰면 네트워크 쪽 지연이 줄고, 로컬 저장소 경로를 정리하면 IO 쪽 체감이 줄어드는 편입니다.

추가로 여기까지 손을 보면 “빌드 자체는 빠른데 특정 상황에서 갑자기 느려지는” 패턴이 많이 사라집니다.

그래도 워크스페이스가 커지고 프로젝트 수가 늘어나면, 작은 설정 차이가 다시 체감으로 돌아옵니다. 그때는 이클립스가 무엇을 하느라 기다리는지, 그 대상을 줄이거나 로컬에서 해결되게 만드는 쪽이 효과적입니다.

업데이트 사이트 목록이 많으면, 확인 시도 자체가 잦아진다

소프트웨어 사이트가 잔뜩 등록되어 있으면, 이클립스는 필요할 때마다 더 많은 대상을 확인하려고 합니다.

쓰지 않는 사이트가 남아 있거나, 더 이상 접근할 수 없는 주소가 섞여 있으면, 그 주소에서 타임아웃이 발생하는 순간 전체 체감이 무너집니다. 실제로는 한두 개만 정리해도 멈칫이 확 줄어드는 경우가 많습니다.

프록시가 필요한 환경에서는 “Native”가 의외로 발목을 잡는다

운영체제 프록시 설정을 자동으로 따라가는 방식이 항상 정답은 아닙니다. 사내망에서 인증 프록시나 예외 규칙이 복잡하면, 이클립스가 기대한 방식으로 연결을 잡지 못해 느려질 수 있습니다. 이럴 때는 이클립스 네트워크 설정을 명확하게 맞춰 두는 편이 안정적입니다. Contacting Software Sites가 자주 보이는 환경이라면, 네트워크 설정을 정리해두는 것만으로도 작업 흐름이 부드러워질 때가 많습니다.

워크스페이스가 무거워졌다면, “항상 검사”보다 “필요할 때 확인”이 편하다

모든 변경에 대해 즉시 검증하고 즉시 빌드를 돌리는 방식은 작은 프로젝트에는 편하지만, 규모가 커지면 개발 리듬을 끊기 쉽습니다. XML, XSD, WTP 관련 검증까지 늘어나면 저장 한 번에도 체감이 커집니다. 이 시점에서는 빌드 때 필수인 것과, 나중에 확인해도 되는 것을 분리해두는 편이 결과적으로 품질도 유지되고 속도도 얻는 쪽으로 이어집니다.

자주 묻는 질문

Contacting Software Sites가 뜨면 무조건 업데이트 문제인가요?

대부분은 업데이트 확인과 관련이 있지만, “업데이트 확인”이라는 이름으로 플러그인 저장소 접속을 시도하는 모든 상황을 묶어서 보여주는 경우가 많습니다. 자동 확인이 켜져 있거나, 소프트웨어 사이트 목록이 많거나, 접근이 불가능한 주소가 섞여 있으면 빌드 중에도 창이 튀어나올 수 있습니다.

XML Validation을 끄면 문제는 없나요?

XML 문서의 구조 오류를 빨리 잡아주는 장점이 사라질 수는 있습니다. 다만 빌드 때마다 전체를 과하게 확인하는 방식이 부담이라면, 빌드에서는 검증 강도를 낮추고 필요할 때 수동 검증을 활용하는 방식이 현실적인 타협점이 됩니다. XML이 많은 프로젝트라면 외부 DTD/XSD를 로컬로 연결해두는 편이 안정적입니다.

외부 DTD/XSD 때문에 느린지 빠르게 확인하는 방법이 있나요?

느려지는 XML 파일 상단을 보면 DOCTYPE이나 schemaLocation에 외부 URL이 들어가 있는 경우가 많습니다. 저장할 때도 느리고, 특히 네트워크가 제한된 환경에서만 느려진다면 외부 리소스 확인이 개입했을 가능성이 큽니다.

.m2 repository를 D드라이브로 옮겼는데도 Maven이 느린데요?

D드라이브로 옮기는 건 도움이 되지만, 보안 프로그램이 해당 경로를 실시간으로 검사하면 작은 파일을 반복적으로 읽는 Maven 특성상 체감이 크게 떨어질 수 있습니다. 또 사내망에서 외부 리포지토리로 나가려는 시도가 남아 있으면 다운로드 지연이 계속됩니다. 이 경우에는 사내 미러를 사용하는 쪽이 효과가 큽니다.

워크스페이스 빌드만 느리고, 개별 프로젝트 빌드는 괜찮은데 왜 그런가요?

워크스페이스 빌드는 프로젝트 전체를 훑으면서 검증과 빌더가 광범위하게 동작할 수 있습니다. XML 검증 대상이 넓게 잡혀 있거나, 업데이트 확인이 섞이거나, Maven 구성이 재해석되는 순간이 있으면 전체 빌드에서만 유독 느리게 느껴질 수 있습니다.

프록시 설정을 했는데도 Contacting Software Sites가 오래 걸려요

프록시 자체는 맞는데 예외 규칙이나 인증 과정 때문에 지연되는 경우가 있습니다. 또 접근 불가능한 소프트웨어 사이트가 남아 있으면 그 주소에서 타임아웃이 반복될 수 있습니다. 이럴 때는 사이트 목록 정리가 체감에 더 직접적으로 먹히는 경우가 많습니다.

XML Catalog는 꼭 필요한가요?

XML이 많고 외부 스키마를 참조하는 프로젝트라면, Catalog를 한 번 정리해두는 것만으로도 “느려질 수밖에 없는 구조”를 제거할 수 있습니다. 검증을 유지하면서도 속도를 얻을 수 있는 방법이라, 단순히 검증을 끄는 것보다 마음이 편한 편입니다.

Eclipse를 켤 때부터 느린 경우도 같은 원리인가요?

비슷합니다. 시작 시점에 업데이트 확인이 켜져 있거나, 플러그인이 저장소 확인을 수행하면 Contacting Software Sites가 뜨면서 느려질 수 있습니다. 워크스페이스 로딩 과정에서 검증이 개입하는 환경이라면, 시작부터 체감이 늘어질 수도 있습니다.

이클립스 빌드 지연을 “컴퓨터 성능 문제”로만 보면 답이 안 나올 때가 많습니다. 특히 Contacting Software Sites와 XML Validation이 엮이면, CPU나 디스크가 한가해 보여도 시간이 계속 새는 느낌이 생깁니다. 외부 리소스 확인이 어디서 발생하는지, 업데이트 사이트 접속 시도가 언제 끼어드는지만 정리해도 워크스페이스 빌드 체감은 꽤 달라집니다.

결국 포인트는 단순합니다. 빌드할 때 꼭 필요한 확인만 남기고, 네트워크가 필요한 확인은 로컬로 돌리거나 필요한 순간에만 하도록 정리하면, 작업 리듬이 부드러워지고 “갑자기 멈춘 느낌”이 사라집니다.