학습 계기

없음

배경

파이썬이 해결하고자 한 문제들

C 언어는 너무 어렵고, 쉘 스크립트는 너무 약해

1989년, 귀도 반 로섬(Guido van Rossum)은 크리스마스 연휴에 심심풀이로 파이썬을 만들기 시작했다

• 불편함: 당시 시스템 관리 도구를 만들려면 복잡한 C 언어로 한 땀 한 땀 코딩하거나, 기능이 턱없이 부족한 쉘 스크립트를 써야 했다. 즉 중간 지점이 없었던 것이다
• 해결책: 사람이 읽기 편한 문법을 가졌으면서도, 시스템의 복잡한 기능을 다룰 수 있는 언어를 만들기로 했다
• 결과: 코드 가독성이 극대화 된 언어가 탄생. 파이썬의 철학인 "The Zen of Python" 은 '단순함이 복잡함보다 낫다'는 원칙을 정립했다

Batteries Included: 라이브러리 찾아 삼만리는 이제 그만

파이썬이 초기에 폭발적으로 성장한 이유는 '라이브러리'에 대한 철학 덕분이었다

• 불편함: C나 C++은 아주 기초적인 기능(문자열 처리, 네트워크 통신 등)조차 외부 라이브러리를 직접 설치하고 연결하는 과정이 고통스러웠다
• 해결책 (Standard Library): "필요한 건 내가 다 넣어둘게" 즉, 파이썬은 설치만 하면 이메일 전송, 압축, 웹 서버 구축 등 웬만한 기능은 바로 쓸 수 있게 설계했다
• 결과: 개발자는 도구를 고치는 시간보다 '진짜 문제'를 해결하는 데 시간을 더 쓰게 되었다

Web Framework (Django/Flask): 웹 개발의 노가다를 자동화하라

인터넷 시대가 열리자 파이썬은 웹 서비스 분야로 구체화되었다

• 불편함: 로그인 처리, 데이터베이스 연결, 페이지 라우팅 등 웹 서비스마다 반복되는 코드가 너무 많았다
• 해결책:
  • Django: "완성된 관리자 페이지까지 다 줄게" (풀스택 프레임워크)
  • Flask: "가장 가벼운 뼈대만 줄 테니 네 마음대로 조립해" (마이크로 프레임워크)
• 결과: 인스타그램(Instagram) 같은 대형 서비스가 파이썬 기반으로 빠르게 만들어질 수 있는 토대가 되었다

Data Science & AI: 느린 파이썬에 C 언어의 근육을 달아주자

파이썬의 최대 약점은 '속도' 였다. 하지만 데이터 분석과 AI 시대가 오면서 반전이 일어났다

• 불편함: 복잡한 수학 연산을 파이썬으로만 돌리면 너무 느렸다. 그렇다고 수학자들이 어려운 C++로 딥러닝 코드를 짤 수는 없었다
• 해결책 (C-Extensions): "계산은 C 언어로 만든 엔진이 하고, 사람은 파이썬으로 명령만 내리자!"
• 결과: NumPy, Pandas, TensorFlow, PyTorch 같은 강력한 도구들이 탄생했다. 오늘날 AI 분야에서 파이썬이 대체 불가능한 언어가 된 결정적 이유가 되었다

Asyncio & FastAPI: 파이썬도 실시간 통신을 잘하고 싶어

현대의 웹은 수만 명의 접속자를 동시에 처리해야 하는 고도의 비동기 기술을 요구한다

• 불편함: 파이썬은 한 번에 하나의 일만 처리하는 구조(GIL) 때문에 동시 접속자가 많아지면 효율이 떨어졌다
• 해결책 (FastAPI): 자바스크립트(Node.js)의 비동기 방식을 벤치마킹하여, 아주 적은 자원으로도 수만 개의 요청을 동시에 처리하는 기술을 도입했다
• 결과: 고성능 API 서버 분야에서도 파이썬은 다시 한번 자신의 영역을 확장했다

1단계: 추상적 이해

컴퓨터와 나누는 친절한 대화

• 비유: 파이썬은 '복잡한 기계 설명서'보다 친구에게 적어주는 '쉬운 요리 레시피'에 가깝다
• 핵심: 파이썬의 가장 큰 목적은 "사람이 읽기 편하게 만들자"는 것. 자바처럼 복잡한 형식을 따지기보다, 우리가 쓰는 영어 문장과 비슷하게 코드를 짤 수 있게 설계되었다
• 이유: 코드를 쓰는 시간보다 읽고 이해하는 시간을 줄여서, 누구나 쉽고 빠르게 아이디어를 현실로 만들기 위함이다

2단계: 실질적 이해

실시간으로 통역해주는 '통역사(Interpreter)'

• 개념: 외국인 친구와 대화할 때, 미리 편지를 다 번역해두는 게 아니라 옆에서 바로바로 말을 전해주는 '동시 통역사'가 있는 셈이다
• 작동 방식: 자바는 컴파일러가 미리 설계도(.class)를 완벽히 만들어야 하지만, 파이썬은 코드를 한 줄씩 읽으면서 그 자리에서 바로 기계가 알아듣는 바이트코드로 바꿔서 실행한다
• PVM (Python Virtual Machine): 파이썬만의 가상 엔진이 이 '번역'과 '실행'을 동시에 담당한다. 그래서 코드를 수정하고 바로 확인하기가 아주 편하다

3단계: 심층적 이해

모든 것을 담는 '똑똑한 상자(Object)'

• 개념: 파이썬은 메모리에 데이터를 담을 때, 그냥 담지 않고 '이건 숫자야', '이건 글자야'라는 이름표를 붙인 커다란 상자에 담는다
• 동적 타이핑(Dynamic Typing): 자바스크립트는 변수를 선언할 때 "넌 숫자만 담아!"라고 미리 정해야 하지만 파이썬은 그렇지 않아도 된다. 메모리 공간이 실행 중에 알아서 늘어나고 줄어들며 데이터를 받아내기 때문이다
• 쓰레기 수집가 (Garbage Collector): 메모리 방이 꽉 차지 않게, 아무도 안 쓰는 상자들을 알아서 치워주는 '청소 로봇'이 시스템 내부에서 계속 돌아가고 있다

4단계: 물리적 이해

조금 더 바쁘게 움직이는 트랜지스터

• 개념: 미리 다 짜인 길을 달리는 자동차보다, 그때그때 지도를 보며 길을 찾는 자동차의 엔진이 더 바쁘게 돌아가는 것과 같다
• 물리적 흐름:
  1. CPU의 ALU(산술논리장치) 는 단순히 계산만 하는 게 아니라, 파이썬 엔진의 '번역 로직'을 처리하는 데도 많은 전기를 쓴다
  2. 한 줄씩 번역하며 실행해야 하니, CPU 내부의 프로그램 카운터(PC) 와 레지스터가 자바 같은 언어보다 훨씬 자주, 복잡하게 움직여야 한다
  3. 그래서 똑같은 계산을 해도 파이썬은 CPU의 '전기 신호'가 더 많이 발생하고, 속도는 상대적으로 조금 느릴 수밖에 없는 물리적 구조를 가지고 있다

참고자료

기술지도

상위개념

Layer1(역사/맥락)

• [[Global interpreter lock]]
• [[Performance bottleneck(Numerical)]]
• [[Web infrastructure complexity]]

Layer2(아키텍처/구조)

• [[Numpy]] | C-extention 융합 | 파이썬의 느린 연산 속도
• [[Pandas]] | C-extention 융합 | 파이썬의 느린 연산 속도
• [[Flask]] | 웹개발 생산성 | 반복적인 웹 인프라 코딩
• [[Django]] | 웹개발 생산성 | 반복적인 웹 인프라 코딩
• [[FastAPI]] | 비동기 처리 | 대규모 동시 접속 처리의 한계
• [[Asynchronous I/O]]
• [[Airflow]]
• [[Dagster]]

Layer3(철학/추상화)

• [[Zen of Python(PEP 20)]]
• [[Type hinting(PEP 484)]]
• [[Asynchronous programming(async/await)]]

하위개념

Layer1(역사/맥락)

• [[C언어]]
• [[Shell script]]
• [[ABC Language]]

Layer2(아키텍처/구조)

• [[CPython Implementation]] | 가독성 높은 문법 | C언어의 난해함과 낮은 생산성 해결
• [[Python virtual machine]] & [[Bytecode]]
• [[Standard C library]] | Batteries included | 라이브러리 설정 지옥

Layer3(철학/추상화)

• [[Dynamic typint(Duck typing)]]
• [[Garbage collection(GC)]]