프로그램이나 개발 서버를 실행할 때 다음과 비슷한 오류를 만날 수 있습니다.
Port 8080 is already in use
Address already in use
Failed to bind to port 8080
표현은 프로그램마다 다르지만 핵심은 비슷합니다.
실행하려는 프로그램이 8080 포트를 사용해야 하는데 이미 다른 프로세스가 해당 포트를 사용하고 있다는 의미입니다.
이럴 때 무작정 컴퓨터를 재부팅하면 문제가 해결될 수도 있습니다. 하지만 어떤 프로그램이 8080 포트를 사용하고 있었는지 확인하지 못하기 때문에 같은 문제가 다시 발생했을 때 원인을 찾기 어렵습니다.
Windows에서는 CMD의 netstat, tasklist, taskkill을 이용해 포트를 사용 중인 프로세스를 직접 추적할 수 있습니다.
이번 글에서는 명령어 사용법만 설명하지 않고 실제 Windows PC에서 Python HTTP 서버를 8080 포트로 실행해 포트를 점유한 다음, CMD에서 PID를 찾고 프로세스를 확인한 뒤 종료하여 8080 포트가 실제로 해제되는 과정까지 직접 테스트했습니다.
실제 테스트 흐름은 다음과 같습니다.
8080 포트 사용 여부 확인
↓
Python 서버로 8080 포트 실제 점유
↓
netstat로 8080 포트 PID 확인
↓
tasklist로 PID의 프로그램 확인
↓
taskkill로 해당 프로세스 종료
↓
netstat로 8080 포트가 해제됐는지 재확인
8080 포트가 사용 중이라는 것은 무슨 의미일까?
하나의 포트에서 특정 주소 조합을 이미 다른 프로세스가 사용하고 있는 상태에서는 새 프로그램이 같은 방식으로 해당 포트에 바인딩하려 할 때 충돌이 발생할 수 있습니다.
개발 환경에서는 8080 포트를 자주 사용합니다.
예를 들어 로컬 웹 서버나 개발 서버를 실행했는데 이전에 실행했던 프로세스가 종료되지 않고 남아 있다면 새 서버가 8080 포트를 사용하지 못할 수 있습니다.
이때 중요한 것은 바로 프로세스를 종료하는 것이 아닙니다.
먼저:
“현재 8080 포트를 실제로 누가 사용하고 있는가?”
를 확인해야 합니다.
테스트 1. 8080 포트가 비어 있는 상태 확인
먼저 실제 Windows CMD에서 다음 명령어를 실행했습니다.
netstat -ano | findstr :8080
netstat -ano는 현재 네트워크 연결 및 수신 대기 상태와 관련된 정보를 PID와 함께 확인할 때 사용할 수 있습니다.
여기에:
| findstr :8080
을 붙여 출력 결과 중 :8080이 포함된 줄을 찾았습니다.
테스트를 처음 시작했을 때는 명령어 아래에 아무 결과도 나타나지 않았습니다.
CMVEXA Windows 테스트 환경에서 8080 포트 사용 여부를 확인한 초기 결과.
이 결과에서는 해당 조회 조건에 일치하는 8080 관련 항목이 발견되지 않았습니다.
즉 테스트를 시작하기 좋은 상태였습니다.
이제 실제로 8080 포트를 사용하는 프로세스를 만들어 결과가 어떻게 달라지는지 확인했습니다.
테스트 2. Python으로 8080 포트를 직접 사용해보기
테스트를 위해 Python의 간단한 HTTP 서버 기능을 사용했습니다.
CMD에서 다음 명령어를 실행했습니다.
python -m http.server 8080
실제 테스트에서는 다음과 같이 8080 포트에서 HTTP 서버가 실행되고 있다는 메시지가 표시됐습니다.
Serving HTTP on :: port 8080 ...
테스트를 위해 Python HTTP 서버를 8080 포트에서 직접 실행한 모습.
이 CMD 창은 서버가 실행 중이기 때문에 일반적인 명령 입력 상태로 바로 돌아오지 않습니다.
이번 테스트에서는 이 창을 그대로 유지하고 두 번째 CMD 창을 열어 8080 포트 상태를 확인했습니다.
※ 이 과정은 테스트 환경을 만들기 위한 것입니다. 실제 포트 충돌 문제를 해결하기 위해 Python을 설치할 필요는 없습니다. 실제 문제 상황에서는 이미 다른 프로그램이 해당 포트를 점유하고 있으므로 netstat부터 확인하면 됩니다.
테스트 3. netstat로 8080 포트를 다시 확인
Python HTTP 서버를 실행한 상태에서 새 CMD를 열고 다시 다음 명령어를 실행했습니다.
netstat -ano | findstr :8080
이번에는 처음과 결과가 달라졌습니다.
실제 테스트 화면에서 8080 포트가:
LISTENING
상태로 나타났고 오른쪽 끝에는 PID가 표시됐습니다.
테스트 과정에서 확인한 PID 중 하나는:
22124
였습니다.
Python 서버 실행 후 8080 포트가 LISTENING 상태로 나타난 실제 netstat 결과.
여기서 중요한 것은 맨 오른쪽에 표시되는 PID입니다.
PID는 Process ID를 의미하며 Windows에서 실행 중인 프로세스를 구분하기 위한 번호입니다.
즉:
8080 포트 사용 중
이라는 사실만 확인하는 것이 아니라:
8080 → PID 22124
처럼 해당 포트를 사용하고 있는 프로세스까지 추적할 수 있습니다.
0.0.0.0:8080과 [::]:8080이 같이 보이는 이유
테스트 결과에서는 다음과 비슷한 항목이 함께 나타났습니다.
0.0.0.0:8080
[::]:8080
0.0.0.0은 IPv4 주소에서 여러 인터페이스를 대상으로 수신 대기하는 형태와 관련되어 있고, [::]는 IPv6 쪽 수신 대기와 관련된 형태로 볼 수 있습니다.
따라서 같은 PID가 두 줄에 표시된다고 해서 무조건 서로 다른 두 프로그램이 8080 포트를 사용하고 있다는 의미는 아닙니다.
실제 테스트에서도 같은 PID가 IPv4와 IPv6 항목에 각각 나타나는 것을 확인할 수 있었습니다.
따라서 줄 개수만 세지 말고 맨 오른쪽 PID를 함께 확인하는 것이 중요합니다.
테스트 4. PID 22124가 어떤 프로그램인지 확인
이제 8080 포트를 사용하고 있는 PID가 22124라는 것을 확인했습니다.
하지만 PID 숫자만 보고 프로세스를 종료하면 안 됩니다.
먼저 그 PID가 실제로 어떤 프로그램인지 확인해야 합니다.
다음 명령어를 실행했습니다.
tasklist /FI "PID eq 22124"
실제 테스트 결과:
python.exe
가 표시됐습니다.
8080 포트를 사용하던 PID 22124가 python.exe인지 직접 확인한 결과.
우리가 테스트를 위해 실행한 프로그램이 Python HTTP 서버였기 때문에 예상했던 결과와 일치합니다.
즉 실제로:
8080 포트
↓
PID 22124
↓
python.exe
순서로 추적하는 데 성공했습니다.
이 과정이 중요한 이유는 taskkill을 사용하기 전에 종료하려는 PID가 어떤 프로그램인지 확인해야 하기 때문입니다.
PID를 확인하지 않고 바로 종료하면 안 되는 이유
인터넷에서 포트 충돌 해결법을 찾으면 다음과 같은 명령어를 바로 실행하라는 설명을 볼 수 있습니다.
taskkill /PID 숫자 /F
하지만 PID만 확인하고 프로세스 이름을 확인하지 않은 상태에서 바로 종료하는 것은 권장하기 어렵습니다.
그 PID가:
현재 작업 중인 프로그램
다른 개발 서버
Windows 관련 프로세스
사용 중인 프로그램
등일 가능성이 있기 때문입니다.
따라서 가능하면 다음 순서를 지키는 것이 좋습니다.
1. 포트 확인
2. PID 확인
맨 오른쪽 PID 확인
3. 프로세스 이름 확인
4. 종료해도 되는 프로세스인지 판단
5. 필요한 경우에만 종료
이번 테스트에서도 이 순서대로 진행했습니다.
테스트 5. taskkill로 8080 포트 사용 프로세스 종료
PID와 프로그램을 확인한 다음 테스트용 Python 프로세스를 종료했습니다.
실행한 명령어는 다음과 같습니다.
실제 Windows CMD에서는 해당 PID의 프로세스가 종료됐다는 성공 메시지가 표시됐습니다.
/PID 뒤에는 종료하려는 프로세스의 실제 PID를 입력합니다.
/F는 프로세스를 강제로 종료하는 옵션입니다.
따라서 실제 업무 환경에서는 /F를 무조건 사용하기보다 해당 프로그램을 정상적으로 종료할 수 있는지 먼저 확인하는 것이 좋습니다.
프로그램이 저장되지 않은 작업을 가지고 있다면 강제 종료 과정에서 데이터가 손실될 수도 있습니다.
그런데 8080 포트가 아직 남아 있었다
이번 직접 테스트에서 재미있는 상황도 발생했습니다.
PID 22124를 정상적으로 종료한 뒤:
netstat -ano | findstr :8080
을 다시 실행했습니다.
그런데 8080 포트가 완전히 사라지지 않았습니다.
대신 다른 PID:
22688
이 LISTENING 상태로 나타났습니다.
첫 번째 프로세스를 종료했지만 다른 PID가 여전히 8080 포트를 사용하고 있었던 실제 테스트 결과.
이 결과는 실제 포트 충돌 문제를 해결할 때 상당히 중요한 사례입니다.
프로세스 하나를 종료했다고 해서 해당 포트가 반드시 즉시 완전히 해제되는 것은 아닙니다.
같은 포트와 관련된 다른 프로세스가 존재할 수도 있고, 테스트 과정처럼 여러 서버 프로세스가 실행되어 있을 수도 있습니다.
따라서 taskkill에서 성공 메시지가 나왔다고 바로 문제 해결을 끝내지 말고 반드시:
netstat -ano | findstr :8080
을 다시 실행해서 확인하는 것이 좋습니다.
테스트 6. 남아 있는 PID 22688 확인
8080 포트를 계속 사용하고 있던 PID는:
22688
이었습니다.
이번에도 바로 종료하지 않고 먼저 프로그램을 확인했습니다.
tasklist /FI "PID eq 22688"
실제 결과에서는 다시:
python.exe
가 확인됐습니다.
따라서 테스트 과정에서 실행되어 남아 있던 또 다른 Python 프로세스라는 것을 확인할 수 있었습니다.
이제 종료 대상이 테스트용 Python 프로세스라는 것을 확인했으므로 다음 명령어를 실행했습니다.
taskkill /PID 22688 /F
Windows에서는 PID 22688 프로세스가 종료됐다는 성공 메시지가 표시됐습니다.
테스트 7. 8080 포트가 정말 해제됐는지 최종 확인
마지막 단계입니다.
프로세스를 종료했다고 끝내지 않고 다시:
netstat -ano | findstr :8080
을 실행했습니다.
이번에는 명령어 아래에 아무 결과도 나타나지 않았습니다.
남아 있던 Python 프로세스를 종료한 뒤 8080 관련 결과가 더 이상 나타나지 않는 것을 확인한 최종 테스트.
처음 테스트를 시작했을 때와 같은 상태로 돌아온 것입니다.
이번 직접 테스트에서는:
8080 포트 점유
↓
PID 확인
↓
프로세스 확인
↓
프로세스 종료
↓
8080 포트 재조회
↓
결과 없음
까지 확인했습니다.
따라서 단순히 taskkill 성공 메시지만 본 것이 아니라 8080 포트가 실제로 더 이상 조회되지 않는 것까지 확인한 것입니다.
실제 8080 Port Already in Use 오류가 발생했다면
실제 프로그램에서:
Port 8080 is already in use
같은 오류가 발생했다면 Python 서버를 실행할 필요는 없습니다.
이번 글에서 Python은 8080 포트 충돌 상황을 직접 재현하기 위한 테스트 도구로만 사용했습니다.
실제 문제 상황에서는 바로 다음 명령어부터 시작하면 됩니다.
netstat -ano | findstr :8080
결과가 예를 들어 다음과 비슷하다고 가정하겠습니다.
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 12345
그러면 PID는:
12345
입니다.
다음으로:
tasklist /FI "PID eq 12345"
를 실행합니다.
프로세스 이름을 확인한 뒤 종료해도 되는 프로그램이라는 것을 확인했을 때만 정상 종료 또는 필요한 경우 taskkill을 사용합니다.
강제 종료가 필요하다면:
taskkill /PID 12345 /F
처럼 사용할 수 있습니다.
그리고 마지막에는 반드시:
netstat -ano | findstr :8080
을 다시 실행합니다.
아무 결과도 없다면 해당 조회 기준에서 8080을 사용하는 항목이 더 이상 나타나지 않는 것을 확인할 수 있습니다.
PID 번호는 컴퓨터마다 다르다
이번 직접 테스트에서는:
22124
와:
22688
이라는 PID가 등장했습니다.
하지만 이 숫자를 그대로 따라 입력하면 안 됩니다.
PID는 실행 중인 프로세스에 Windows가 부여하는 식별 번호이므로 실행할 때마다 달라질 수 있습니다.
따라서 실제 문제를 해결할 때는 반드시 자신의 컴퓨터에서:
netstat -ano | findstr :8080
을 실행하고 현재 표시되는 PID를 사용해야 합니다.
예를 들어 자신의 결과가:
LISTENING 5432
라면 확인 명령어는:
tasklist /FI "PID eq 5432"
가 됩니다.
이번 글의 22124, 22688은 실제 테스트에서 나온 값일 뿐 고정된 번호가 아닙니다.
LISTENING이 의미하는 것은?
netstat 결과에서:
LISTENING
은 해당 로컬 주소와 포트에서 연결 요청을 받을 준비가 된 상태와 관련됩니다.
따라서 8080을 사용하려는 서버 프로그램이:
Port already in use
오류를 표시하고, netstat에서도 :8080이 LISTENING으로 나타난다면 이미 다른 프로세스가 해당 포트에서 수신 대기하고 있는지 확인해볼 수 있습니다.
다만 findstr :8080은 단순 문자열 필터이므로 결과를 볼 때 로컬 주소, 상태, PID를 함께 확인해야 합니다.
8080 포트를 사용하는 프로그램을 무조건 종료해야 할까?
아닙니다.
이것도 중요합니다.
8080을 사용 중인 프로세스가 정상적으로 필요한 프로그램이라면 종료하면 안 됩니다.
예를 들어 기존 웹 서버가 의도적으로 8080을 사용하고 있다면 새 프로그램의 포트를:
8081
8888
등 다른 사용 가능한 포트로 변경하는 방법도 있습니다.
즉 해결 방법은 항상:
기존 프로세스 강제 종료
하나뿐인 것이 아닙니다.
상황에 따라:
기존 프로그램 정상 종료
새 프로그램의 포트 변경
기존 서버 설정 변경
중복 실행된 프로세스 정리
등을 선택할 수 있습니다.
taskkill /F 사용 시 주의사항
/F는 강제 종료 옵션이므로 편리하지만 주의해야 합니다.
종료하려는 프로그램에서 저장하지 않은 데이터가 있다면 손실될 수 있습니다.
또한 프로세스의 역할을 모르는 상태에서 시스템 관련 프로세스를 강제로 종료하면 Windows나 실행 중인 프로그램에 문제가 발생할 수 있습니다.
따라서 다음 순서를 권장합니다.
netstat
↓
PID 확인
↓
tasklist
↓
프로세스 이름 확인
↓
정상 종료 가능한지 확인
↓
필요한 경우에만 taskkill
특히 단순히 “8080을 쓰고 있다”는 이유만으로 프로세스를 제거해서는 안 됩니다.
taskkill에서 액세스가 거부될 때
프로세스에 따라 일반 권한의 CMD에서는 종료되지 않을 수 있습니다.
이 경우 관리자 권한이 필요한 상황이 있을 수 있습니다.
하지만 관리자 CMD를 열기 전에 그 프로세스를 정말 종료해도 되는지 먼저 확인하는 것이 중요합니다.
관리자 권한은 종료 대상이 안전하다는 것을 보장해주는 기능이 아닙니다.
오히려 더 높은 권한으로 중요한 프로세스를 종료할 수 있으므로 주의해야 합니다.
8080이 아니라 다른 포트도 같은 방식으로 찾을 수 있을까?
가능합니다.
예를 들어 3000 포트를 확인하려면:
netstat -ano | findstr :3000
5000 포트:
netstat -ano | findstr :5000
8000 포트:
netstat -ano | findstr :8000
8081 포트:
netstat -ano | findstr :8081
처럼 검색할 수 있습니다.
핵심은:
netstat -ano | findstr :포트번호
형태입니다.
다만 출력에서 해당 숫자가 어떤 열에 나타난 것인지 확인하고, 실제 로컬 포트와 상태 및 PID를 함께 보는 것이 좋습니다.
재부팅하면 해결되는데 굳이 PID를 찾는 이유
PC를 재부팅하면 사용 중이던 프로세스가 종료되면서 포트 충돌이 사라지는 경우가 있습니다.
하지만 재부팅만 반복하면:
어떤 프로그램이 포트를 사용했는지
왜 중복 실행됐는지
다시 발생했을 때 무엇을 종료해야 하는지
알기 어렵습니다.
반면:
netstat → PID → tasklist
순서로 확인하면 실제 점유 프로세스를 추적할 수 있습니다.
개발 서버나 로컬 테스트 환경에서 포트 충돌이 반복된다면 이 방법을 알아두는 편이 효율적입니다.
이번 실제 테스트에서 예상과 달랐던 부분
이번 테스트에서 특히 확인할 가치가 있었던 부분은 첫 번째 Python 프로세스를 종료한 뒤에도 8080 포트가 남아 있었다는 것입니다.
처음에는 PID 22124가 8080을 사용하고 있었고:
taskkill /PID 22124 /F
로 종료했습니다.
하지만 재확인 결과 PID 22688이 다시 8080을 LISTENING하고 있었습니다.
그래서:
tasklist /FI "PID eq 22688"
을 실행해 python.exe라는 것을 다시 확인하고:
taskkill /PID 22688 /F
로 종료했습니다.
그 이후에야:
netstat -ano | findstr :8080
결과가 완전히 사라졌습니다.
이 실제 테스트를 통해 확인할 수 있었던 것은 간단합니다.
프로세스 하나를 종료한 뒤에도 반드시 포트를 다시 조회해야 합니다.
성공 메시지만 보고 끝내면 다른 프로세스가 같은 포트를 계속 사용하고 있는 상황을 놓칠 수 있습니다.
8080 포트 충돌 해결 순서 요약
1단계: 8080 사용 여부 확인
netstat -ano | findstr :8080
2단계: 맨 오른쪽 PID 확인
예:
22124
3단계: PID의 프로그램 확인
tasklist /FI "PID eq 22124"
4단계: 종료 가능한 프로그램인지 판단
프로세스 이름과 현재 사용 여부를 확인합니다.
5단계: 필요한 경우 프로세스 종료
taskkill /PID 22124 /F
6단계: 8080 포트 재확인
netstat -ano | findstr :8080
7단계: 다른 PID가 남았다면 다시 확인
tasklist /FI "PID eq 새PID"
8단계: 모든 관련 프로세스 처리 후 최종 확인
netstat -ano | findstr :8080
결과가 더 이상 나타나지 않는지 확인합니다.
이번 테스트 결과 정리
이번 글에서는 Windows CMD에서 8080 포트 충돌 상황을 직접 만들고 해결했습니다.
처음:
netstat -ano | findstr :8080
→ 결과 없음
Python HTTP 서버 실행:
python -m http.server 8080
→ 8080 포트 실제 사용
다시 netstat 실행:
netstat -ano | findstr :8080
→ LISTENING 확인
→ PID 22124 확인
프로세스 확인:
tasklist /FI "PID eq 22124"
→ python.exe 확인
프로세스 종료:
taskkill /PID 22124 /F
→ 종료 성공
재확인:
netstat -ano | findstr :8080
→ 다른 PID 22688 확인
다시 프로세스 확인:
tasklist /FI "PID eq 22688"
→ python.exe 확인
두 번째 프로세스 종료:
taskkill /PID 22688 /F
→ 종료 성공
최종 확인:
netstat -ano | findstr :8080
→ 결과 없음
즉 이번 테스트에서는 포트 점유부터 PID 추적, 프로세스 확인, 종료, 포트 해제까지 전체 과정을 실제 Windows 환경에서 직접 확인했습니다.
마무리
Windows에서 Port 8080 is already in use와 같은 오류가 발생했다면 무조건 PC부터 재부팅할 필요는 없습니다.
먼저:
netstat -ano | findstr :8080
을 실행해 8080 포트가 실제로 사용 중인지 확인합니다.
LISTENING 상태의 항목이 발견되면 맨 오른쪽 PID를 확인합니다.
그다음:
tasklist /FI "PID eq PID번호"
를 이용해 어떤 프로그램인지 확인합니다.
종료해도 되는 프로세스라는 것을 확인한 뒤 필요한 경우 정상 종료하거나:
taskkill /PID PID번호 /F
를 사용할 수 있습니다.
그리고 가장 중요한 마지막 단계가 있습니다.
프로세스 종료 후 반드시:
netstat -ano | findstr :8080
을 다시 실행하는 것입니다.
이번 실제 테스트에서도 첫 번째 PID를 종료한 뒤 다른 Python 프로세스가 8080 포트를 계속 사용하고 있었습니다.
두 번째 프로세스까지 확인하고 종료한 뒤에야 마지막 netstat 결과가 비어 있는 것을 확인할 수 있었습니다.
따라서 포트 충돌 문제를 해결할 때는:
포트 확인 → PID 확인 → 프로그램 확인 → 안전한 종료 → 포트 재확인
순서로 접근하는 것이 좋습니다.
단순히 명령어를 외우는 것보다 어떤 프로세스가 포트를 사용하고 있는지 직접 확인하고, 종료 후 실제로 포트가 해제됐는지 검증하는 것이 핵심입니다.