hello

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

Share

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

LLM 시대, 프롬프트 엔지니어링보다 '도메인 전문성'이 더 강력한 무기인 이유

최근 AI 도구들이 비약적으로 발전하면서 '프롬프트 엔지니어링'이라는 기술적 기법에 많은 관심이 쏠렸습니다. 하지만 실제 현업에서 LLM을 극한으로 활용해 고도의 결과물을 만들어내는 사람들의 공통점은 정교한 프롬프트 템플릿을 쓰는 능력이 아니라, 해당 분야에 대한 깊은 '도메인 전문성'을 갖추고 있다는 점입니다. 많은 이들이 LLM이 지식의 격차를 줄여준다고

By JHL

AI 코딩 에이전트 도입 시 고려해야 할 보안 제어 프레임워크: 속도와 안전의 균형 잡기

최근 Claude Code나 Kiro와 같은 AI 코딩 에이전트들이 단순한 코드 완성을 넘어, 자연어 프롬프트 하나로 수십 개의 PR을 생성하고 인프라를 수정하는 수준까지 발전했습니다. 하지만 이러한 생산성 향상은 '기계적 속도'라는 트레이드오프를 동반합니다. AI 에이전트는 조직의 보안 리스크나 컴플라이언스를 이해하지 못한 채 오직 '작업 완료'에만 최적화되어

By JHL

AI 벤치마크의 '포화 상태'와 평가 지표의 유효기간: 우리는 무엇을 믿어야 하는가

최근 LLM의 성능이 비약적으로 상승하면서, 역설적으로 우리가 모델의 성능을 측정하는 '자' 자체가 무용지물이 되는 현상이 가속화되고 있습니다. arXiv에 게재된 "When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation" 연구는 우리가 흔히 신뢰하는 벤치마크 점수가 왜 더 이상 모델 간의 변별력을 제공하지 못하는지, 그리고 이른바 '

By JHL

AI 에이전트 시대의 엔드포인트 보안: 실행 권한을 넘어 '행위 거버넌스'로

DevOps.com을 통해 Airlock Digital이 발표한 'Agentic AI Control & Governance' 솔루션 소식을 접했습니다. 이번 발표의 핵심은 단순히 '어떤 AI 소프트웨어를 실행할 것인가'라는 기존의 화이트리스트 방식(Application Control)을 넘어, 실행 중인 AI 에이전트가 '실제로 어떤 명령을 내리고 어떻게 행동하는가'를 실시간으로 제어하겠다는

By JHL