[JAVA] Address already in use 에러 원인과 해결 방법

Spring Boot 실행 중 갑자기 “Address already in use” 에러를 만나면, 처음에는 포트만 바꾸면 되는 문제처럼 보입니다. 하지만 실제로는 원인을 제대로 이해하지 않으면 같은 문제가 반복되는 경우가 많습니다.

Java Address already in use 에러란 무엇인가

Java에서 Address already in use 에러는 특정 포트가 이미 다른 프로세스에 의해 사용 중일 때 발생합니다. 대표적으로 Spring Boot 애플리케이션을 실행할 때 자주 보게 됩니다.

운영체제 입장에서는 하나의 포트를 동시에 여러 프로세스가 바인딩할 수 없기 때문에, 이미 사용 중인 포트를 다시 열려고 하면 이 에러가 발생합니다.

java.net.BindException: Address already in use: bind

메시지 자체는 단순하지만, 실제 원인은 몇 가지 패턴으로 나뉘는 경우가 많습니다.

Address already in use 에러가 발생하는 주요 원인

1. 이전 프로세스가 종료되지 않은 경우

가장 흔한 원인입니다. 서버를 종료했다고 생각했지만, 실제로는 백그라운드에서 프로세스가 살아있는 경우입니다.

특히 IDE에서 강제 종료하거나, Docker 컨테이너를 제대로 내리지 않았을 때 자주 발생합니다.

2. 동일한 포트를 사용하는 다른 애플리케이션

예를 들어 Spring Boot 기본 포트인 8080을 이미 다른 서비스가 사용 중인 상황입니다.

로컬 개발 환경에서는 여러 프로젝트를 동시에 실행하다 보면 자연스럽게 겹치는 경우가 많습니다.

3. TIME_WAIT 상태로 포트가 남아있는 경우

이 부분은 처음 보면 이해가 어려운 케이스입니다. 프로세스는 종료됐지만, OS 레벨에서 소켓이 완전히 해제되지 않은 상태입니다.

짧은 시간 안에 재시작을 반복하면 이 상태 때문에 같은 포트를 다시 사용할 수 없는 경우가 있습니다.

문제 해결 방법

1. 포트를 사용 중인 프로세스 확인

먼저 어떤 프로세스가 포트를 점유하고 있는지 확인하는 것이 우선입니다.

lsof -i :8080

출력 결과에서 PID를 확인한 뒤 해당 프로세스를 종료합니다.

kill -9 [PID]

실무에서는 단순히 kill 하기 전에 어떤 프로세스인지 확인하는 습관을 들이는 것이 좋습니다. 의도치 않게 중요한 프로세스를 종료할 수 있기 때문입니다.

2. 포트 변경

개발 환경이라면 가장 빠른 해결 방법은 포트를 변경하는 것입니다.

server.port=8081

application.properties 또는 application.yml에서 설정할 수 있습니다.

다만 이 방법은 임시 대응에 가깝습니다. 동일한 문제가 반복된다면 근본 원인을 확인하는 것이 더 중요합니다.

3. 애플리케이션 종료 방식 점검

IDE에서 실행 중인 애플리케이션을 종료할 때 강제 종료를 반복하면 프로세스가 정상적으로 정리되지 않는 경우가 있습니다.

특히 Spring Boot DevTools를 사용할 때 재시작 로직이 꼬이면서 포트 점유가 남는 경우도 있습니다.

이 경우에는 실행/종료 흐름을 한 번 정리하는 것이 좋습니다.

4. TIME_WAIT 문제 대응

짧은 시간 내 재시작이 반복되는 환경이라면 OS의 소켓 상태를 고려해야 합니다.

일반적인 개발 환경에서는 잠시 기다리면 해결되는 경우가 많지만, 자동 재시작 스크립트를 사용하는 경우에는 문제가 반복될 수 있습니다.

이 경우에는 포트를 고정하지 않고 동적으로 할당하는 방식도 고려해볼 수 있습니다.

포인트

이 에러를 단순히 “포트 충돌”로만 이해하면 반복적으로 같은 문제를 겪게 됩니다.

실제로는 다음 두 가지를 구분해서 보는 것이 중요합니다.

• 프로세스가 살아있는 상태인지
• OS 레벨에서 소켓이 남아있는 상태인지

특히 로컬 개발 환경에서는 첫 번째가 대부분이고, 자동화된 환경에서는 두 번째 케이스가 더 자주 보입니다.

이 차이를 알고 접근하면 디버깅 시간이 훨씬 줄어듭니다.

정리

Address already in use 에러는 단순한 포트 충돌 문제로 보이지만, 실제로는 프로세스 상태와 네트워크 소켓 상태를 함께 이해해야 정확하게 대응할 수 있습니다.

개발 단계에서는 포트 변경으로 빠르게 우회할 수 있지만, 반복된다면 프로세스 관리 방식이나 실행 흐름을 점검하는 것이 더 효과적입니다.

결국 이 에러는 환경을 어떻게 운영하고 있는지를 보여주는 신호에 가깝고 한 번 정리해두면 이후에는 빠르게 대응할 수 있습니다.