파이썬이 실행될 때 ‘pycache’는 왜 생길까? 파이썬 가상환경(Python Vevn) 설정 4편

pycache의 정체 이미지

パイソン 환경 설정 공부를 하다가 프로젝트 폴더를 열었는데, 어느 날 갑자기 __pycache__, *.pyc 이런 게 생깁니다.

처음 보면 이게 느낌이 좀 그래요.
“어? 내가 뭘 설치했나?” “바이러스인가?” “이거 지우면 안 되나?” 같은 생각이 들죠.

결론부터 말하면

정상입니다. 파이썬이 ‘더 빨리 실행하려고’ 남겨두는 흔적です。

오늘 편은 “이걸 이해하면 좋지만, 몰라도 개발은 가능”한 선택 편입니다.
다만, 한 번 이해해두면 이후에 에러 메시지나 환경 문제를 볼 때 멘탈이 훨씬 안정됩니다.

__pycache__ 관련 오늘 목표(가볍게 3개)

  1. .py가 실행될 때 무슨 일이 벌어지는지 큰 흐름 잡기
  2. __pycache__ / .pyc가 생기는 이유 이해하기
  3. “컴파일러 언어 vs 인터프리터 언어”를 현실적으로 구분하기

1) 파이썬은 “바로” 머신 코드로 바꾸지 않습니다

예를 들어 hello_world.py라는 파일이 있고, 안에 이런 코드가 있다고 해볼게요.

print("Hello World")

우리가 이 파일을 실행하려면 터미널에서 어떻게 하는지 기억나시나요?
다음과 같이 하면 되죠?

  • Mac: python3 hello_world.py
  • Windowsです： py hello_world.py

이때 파이썬은 바로 CPU가 이해하는 머신 코드로 번역하지 않습니다.
대신 한 번 중간 단계를 거쳐요.

2) 1단계: 소스를 “바이트코드(bytecode)”로 만든다 (.pyc)

파이썬은 먼저 소스 전체를 읽고, 내부적으로 바이트코드라는 중간 형태로 변환합니다.

  • 이 결과물이 .pyc 파일로 저장되거나
  • 보통 __pycache__ 폴더 아래에 생성됩니다.

여기서 포인트는 두 가지예요.

(1) 문법이 틀리면 여기서 바로 막힌다

문법 오류가 있으면 바이트코드가 만들어지지 않습니다.
그래서 “SyntaxError”류 오류는 실행 초반에 바로 터지는 거죠.

(2) 바이트코드는 ‘머신 코드’가 아니다

.pyc는 “CPU가 바로 실행 가능한 exe” 같은 게 아니고,
파이썬이 다음 단계에서 읽기 좋은 중간 결과물です。

bytecode image

3) 2단계: 파이썬 가상 머신(PVM)이 바이트코드를 한 줄씩 실행한다

그 다음 등장하는 게 “파이썬 가상 머신(Python Virtual Machine, PVM)”입니다.

이 녀석은 바이트코드를 한 줄씩 읽으며, 내부적으로 실행을 이어갑니다.
그래서 파이썬은 “번역(translate)”이라기보다는 “통역(interpret)”에 가까운 느낌을 가지게 돼요.

여기서 감각만 잡으면 됩니다.

파이썬은 (1) 중간 코드(바이트코드) 만들고 → (2) 그걸 한 줄씩 해석해서 실행한다.

4) 바이트코드 예시: 사람이 읽을 수 있게 풀어놓으면 이렇게 보여요

아래 예시를 그대로 감각적으로만 해석해볼게요.

0 LOAD_NAME        0 (print)
2 LOAD_CONST       0 ('Hello World')
4 CALL_FUNCTION    1
6 POP_TOP
8 LOAD_CONST       1 (None)
10 RETURN_VALUE

여기서 중요한 건 “완벽히 이해”가 아니라, 이런 식으로 생각하면 충분해요.

  • LOAD_NAME (print) : print를 준비하고
  • LOAD_CONST ('Hello World') : 문자열을 준비하고
  • CALL_FUNCTION : print에 넣어 실행하고
  • 마지막에 return 하고 끝낸다

즉, 우리가 쓴 한 줄짜리 파이썬 코드도 내부에서는 “명령들의 묶음”으로 바뀌어 실행됩니다.

5) 그래서 __pycache__가 왜 생기냐면요

매번 실행할 때마다 소스를 읽고 바이트코드를 다시 만드는 건 꽤 비효율적입니다.

그래서 파이썬은 “이 파일은 예전에 컴파일(바이트코드 생성)해봤는데, 소스가 안 바뀌었네?” 하면
기존 .pyc를 재사용해서 실행을 조금 더 빠르게 합니다.

그 결과가 __pycache__폴더입니다.

정리하면

  • __pycache__ = 파이썬이 성능을 위해 남겨둔 캐시 폴더
  • 지워도 보통 괜찮음(다시 실행하면 또 생김)
  • 문제는 아니고 정상 동작

6) 컴파일러 언어 vs 인터프리터 언어, 현실적인 구분

여기서 “근데 파이썬도 컴파일 한다면서요?”라는 질문이 나옵니다. 맞아요.

  • C/C++ 같은 컴파일러 언어:
    소스를 머신 코드로 번역해서 실행 파일을 미리 만들어두고, 그걸 실행
  • 파이썬 같은 인터프리터 언어:
    소스를 (바이트코드로 한 번 바꾸긴 하지만) 최종 실행은 인터프리터가 통역하듯 수행

파이썬은 엄밀히 말하면 “둘의 성격을 조금씩 가진” 형태에 가깝고,
우리가 체감하는 실행 방식은 한 번에 실행되는 인터프리터 언어 느낌이 강합니다.

(초보자 시점 Q&A) 그래서 이걸 알아서 뭐가 좋아요?

Q1. __pycache__は Git에 올려야 하나요?

대부분의 경우 올리지 않습니다.(캐시니까요)
그래서 보통 .gitignore에 넣습니다.

Q2. .pyc 지우면 파이썬이 망가져요?

아니요. 보통은 다음 실행 때 다시 만들어집니다.
다만, 어떤 특수한 배포 환경에서는 정책이 다를 수 있지만 초보자 단계에선 “캐시”로 이해해도 충분합니다.

Q3. 그럼 파이썬이 느린 이유가 이 구조 때문인가요?

부분적으로는 맞습니다.
컴파일러 언어처럼 “완전한 머신 코드”로 미리 빌드해두는 방식보다 오버헤드가 생길 수 있죠.
하지만 실제 성능은 라이브러리(NumPy 같은 C 기반) 사용 여부, 알고리즘, I/O, 환경에 따라 크게 달라집니다.

오늘의 체크리스트(선택 편이니까 가볍게)

  • __pycache__가 정상이라는 걸 알았다
  • .py → .pyc(바이트코드) → PVM 실행 흐름을 감각적으로 이해했다
  • “파이썬은 통역 느낌이 강하다”를 기억했다

마무리: 이제 ‘환경’은 도구가 아니라 감각이 됩니다

여기까지 오면, 파이썬이 뭔가 이상한 짓을 해도 덜 무섭습니다.
__pycache__가 생겨도 “아, 캐시구나” 하고 넘어갈 수 있죠.

다음 포스트 내용은 다시 실전으로 돌아갑니다.
파이썬 버전 읽는 법(major/minor/micro)そして PEP / What’s New 페이지로 업데이트를 확인하는 습관을 정리해드릴게요.

類似の投稿