hello

Streamlit 포트가 갑자기 8502로 뜰 때 — 좀비 프로세스 추적 및 해결 방법

Streamlit으로 OAuth 기반 데모 앱을 테스트하다 보면, 의도치 않게 서버가 8501 대신 8502 포트에서 실행되는 상황을 겪은 분들이 많을 것입니다.

저 역시 GitHub OAuth 리디렉션 URI를 8501로 설정해 두었기에 반드시 8501에서 실행해야 했습니다. 그런데 명령을 다시 실행해도 Streamlit은 고집스럽게 8502 포트를 선택했습니다.

처음엔 “이미 8501 포트를 사용 중인 프로세스가 있나?” 하고 IDE, 터미널, PowerShell 등을 살펴봤지만 아무 흔적도 찾지 못했습니다. 결국 깨달은 것은 하나였습니다.

아… 이건 좀비(zombie) 프로세스구나.

아래에서는 원인 진단 → 추적 → 특정 프로세스만 골라 제거하는 과정을 정리했습니다. 비슷한 상황에 처한 분들께 도움이 되길 바랍니다.


1️⃣ 8501 포트를 점유 중인 프로세스 찾기

누가 8501 포트를 잡고 있는지 확인합니다.

netstat -ano | findstr :8501

출력에는 해당 포트를 사용 중인 프로세스의 PID가 표시됩니다.

예)

TCP  0.0.0.0:8501   ...   LISTENING   58808

이제 포트를 점유한 프로세스가 PID 58808임을 알았지만, 무작정 죽일 수는 없습니다. 중요한 프로세스일 수도 있기 때문입니다.


2️⃣ 프로세스 정체 파악하기

✔️ 어떤 프로그램인지 확인

tasklist /fi "PID eq 58808"

예상대로 python.exe가 나오지만, 어떤 가상환경인지, 어떤 프로젝트와 연결돼 있는지는 알 수 없습니다.

✔️ 실행 파일 경로 확인

wmic process where "ProcessId=58808" get ExecutablePath

Python 실행 파일이 어느 경로에 있는지 확인할 수 있습니다(venv의 python인지, 시스템 python인지 등).

✔️ 전체 실행 커맨드 확인

wmic process where "ProcessId=58808" get CommandLine

이제 Streamlit이 어떤 파일을 실행하고 있는지 정확히 알 수 있습니다.

예)

streamlit run "C:\...\oauth_demo.py"

이 프로세스가 정상적인 프로세스가 아닌, Streamlit의 좀비 세션임을 확신할 수 있습니다.


3️⃣ 특정 프로세스만 정확하게 종료하기

안심하고 해당 프로세스를 종료합니다.

taskkill /f /pid 58808
⚠️ /im이 아니라 /pid를 사용해야 합니다.
taskkill /f /im 58808은 잘못된 명령이며, /im은 이미지 이름(예: python.exe)을 의미합니다.

정상적으로 종료되면 Streamlit이 다시 8501 포트에서 실행될 수 있습니다.


4️⃣ Streamlit 재실행

streamlit run oauth_demo.py

이제 8501 포트에서 웹앱이 정상적으로 뜨는 것을 확인할 수 있습니다. 🎉


📝 마무리

포트 충돌은 개발 중 흔히 마주하는 문제지만, 눈에 보이지 않는 ‘좀비 프로세스’ 때문에 원인 파악이 어려울 때가 있습니다. 이번 글에서는 다음 순서로 문제를 해결했습니다.

  1. 포트를 점유한 프로세스 찾기
  2. 프로세스 정체를 정확히 파악하기
  3. 필요한 프로세스만 안전하게 종료하기
  4. Streamlit을 재실행해 정상 포트 확보하기

포트 충돌로 고민 중이라면 위 과정을 따라해 보세요. 확실하고 안전하게 문제를 해결할 수 있습니다.

Read more

TCP 공부하기

TCP(전송 제어 프로토콜) 개요 TCP는 불안정한 네트워크 환경에서도 신뢰성 있고 순서가 보장된 데이터 전송을 가능하게 하는 핵심 인터넷 프로토콜이다. IP가 호스트 간 패킷 전달만을 담당한다면, TCP는 포트 기반 프로세스 간 통신, 오류 복구, 재전송, 순서 제어를 제공한다. 흐름 제어와 혼잡 제어를 통해 TCP는 수신 버퍼와 네트워크 대역폭의 고갈을 방지한다.

By JHL

GitLab에서 제작한 GitOps 초보자 가이드

소개 소프트웨어 애플리케이션의 복잡도가 증가함에 따라 인프라에 대한 요구도도 함께 증가하고 있습니다. 인프라 팀은 다양한 서비스를 빠르고 안정적으로 제공해야 하지만, 인프라 구축은 여전히 수동 프로세스에 의존하는 경우가 많습니다. 이 문제를 해결하기 위한 핵심 접근 방식이 인프라 자동화이며, 그중 하나가 GitOps입니다. 1. 인프라 자동화의 필요성 * 애플리케이션 개발은 CI/CD로 자동화되었지만 인프라

By JHL

Builder.AI 의 몰락

한때 15억 달러의 가치를 인정받으며 AI 혁신의 선두주자로 불렸던 영국 스타트업 Builder.ai가 충격적인 진실과 함께 파산 위기에 직면했습니다. 마이크로소프트와 소프트뱅크 같은 거대 기업들로부터 4억 4,500만 달러라는 천문학적 투자를 받았던 이 회사가 어떻게 이런 상황에 이르게 되었는지, 그리고 그 뒤에 숨겨진 충격적인 진실을 파헤쳐보겠습니다. 화려했던 시작: "AI가 모든

By JHL

Dify 소개

DEMO Link Dify란? Dify는 오픈소스 기반의 LLM 애플리케이션 개발 플랫폼으로, 생성형 AI 서비스를 구축하는 데 필요한 다양한 기능을 제공합니다. 주요 특징은 다음과 같습니다 노코드/로우코드 개발: 직관적인 웹 UI를 통해 복잡한 코드 작성 없이도 AI 애플리케이션을 개발할 수 있습니다. 필요시 API를 활용한 커스터마이징도 가능합니다 . 다양한 LLM 지원: OpenAI의 GPT 시리즈,

By JHL