mir.pe (일반/밝은 화면)
최근 수정 시각 : 2024-11-19 18:29:28

Python

파이썬에서 넘어옴


파일:나무위키+유도.png  
파이썬은(는) 여기로 연결됩니다.
다른 뜻에 대한 내용은 파이선 문서
번 문단을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
참고하십시오.

[[컴퓨터공학|컴퓨터 과학 & 공학
Computer Science & Engineering
]]
[ 펼치기 · 접기 ]
||<tablebgcolor=#fff,#1c1d1f><tablecolor=#373a3c,#ddd><colbgcolor=#0066DC><colcolor=white> 기반 학문 || 수학( 해석학 · 이산수학 · 수리논리학 · 선형대수학 · 미적분학 · 미분방정식 · 대수학( 환론 · 범주론) · 정수론) · 이론 컴퓨터 과학 · 암호학 · 전자공학 · 언어학( 형태론 · 통사론 · 의미론 · 화용론 · 음운론) · 인지과학 ||
하드웨어 구성 SoC · CPU · GPU( 그래픽 카드 · GPGPU) · ROM · RAM · SSD · HDD · 참조: 틀:컴퓨터 부품
기술 기계어 · 어셈블리어 · C/ C++ · C# · Java · Python · BIOS · 절차적 프로그래밍 · 객체 지향 프로그래밍 · 해킹 · ROT13 · 일회용 비밀번호 · 사물인터넷 · 와이파이 · GPS · 임베디드 · 인공신경망 · OpenGL · EXIF · 마이크로아키텍처 · ACPI · UEFI · NERF · gRPC · 리버스 엔지니어링 · HCI · UI · UX · 대역폭 · DBMS · NoSQL · 해시( SHA · 브루트 포스 · 레인보우 테이블 · salt · 암호화폐) · RSA 암호화 · 하드웨어 가속
연구

기타
논리 회로( 보수기 · 가산기 · 논리 연산 · 불 대수 · 플립플롭) · 정보이론 · 임베디드 시스템 · 운영 체제 · 데이터베이스 · 프로그래밍 언어{ 컴파일러( 어셈블러 · JIT) · 인터프리터 · 유형 이론 · 파싱 · 링커 · 난해한 프로그래밍 언어} · 메타데이터 · 기계학습 · 빅데이터 · 폰노이만 구조 · 양자컴퓨터 · 행위자 모델 · 인코딩( 유니코드 · MBCS) · 네트워크 · 컴퓨터 보안 · OCR · 슈퍼컴퓨터 · 튜링 머신 · FPGA · 딥러닝 · 컴퓨터 구조론 · 컴퓨터 비전 · 컴퓨터 그래픽스 · 인공지능 · 시간 복잡도( 최적화) · 소프트웨어 개발 방법론 · 디자인 패턴 · 정보처리이론 · 재귀 이론 · 자연어 처리( 기계 번역 · 음성인식) · 버전 ( 버전 관리 시스템 · Git · GitHub)

프로그래밍 사이트 선정 프로그래밍 언어 순위 목록
{{{#!wiki style="margin: 0 -10px -5px; word-break: keep-all"
{{{#!wiki style="display: inline-table; min-width: 25%; min-height: 2em;"
{{{#!folding [ IEEE Spectrum 2024 ]
{{{#!wiki style="margin: -5px 0"
<rowcolor=#fff> 스펙트럼 부문 상위 10개 프로그래밍 언어 직업 부문 상위 10개 프로그래밍 언어
1 Python 1 SQL
2 Java 2 Python
3 JavaScript 3 Java
4 C++ 4 TypeScript
5 TypeScript 5 SAS
6 SQL 6 JavaScript
7 C# 7 C#
8 Go 8 HTML
9 C 9 Shell
10 HTML 10 C++
}}}
}}}
}}}
[ Stack Overflow 2024 ]
[ TIOBE 2024 ]
||<tablewidth=100%><width=9999><-4><bgcolor=deepskyblue><tablebgcolor=#fff,#222> 2024년 8월 기준 검색어 점유율 상위 20개 프로그래밍 언어 ||
1 Python 11 MATLAB
2 C++ 12 Delphi / Object Pascal
3 C 13 PHP
4 Java 14 Rust
5 C# 15 Ruby
6 JavaScript 16 Swift
7 SQL 17 Assembly language
8 Visual Basic 18 Kotlin
9 Go 19 R
10 Fortran 20 Scratch
{{{#!wiki style="margin: 0 -10px -5px; min-height: calc(1.5em + 5px);"
{{{#!folding [ 21위 ~ 50위 펼치기 · 접기 ]
{{{#!wiki style="margin: -5px -1px -11px"
21 COBOL 36 Scala
22 Classic Visual Basic 37 Transact-SQL
23 LISP 38 PL/SQL
24 Prolog 39 ABAP
25 Perl 40 Solidity
26 (Visual) FoxPro 41 GAMS
27 SAS 42 PowerShell
28 Haskell 43 TypeScript
29 Dart 44 Logo
30 Ada 45 Wolfram
31 D 46 Awk
32 Julia 47 RPG
33 Objective-C 48 ML
34 VBScript 49 Bash
35 Lua 50 Elixir
}}}}}}}}} ||
[ PYPL 2024 ]

}}} ||
프로그래밍 언어 목록 · 분류 · 문법

TIOBE 선정 올해의 프로그래밍 언어 / Python
{{{#!wiki style="margin:0 -10px -5px"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin:-6px -1px -11px"
2006년
Ruby
2007년
Python
2008년
C
2009년
Go
2010년
Python
2011년
Objective-C
2017년
C
2018년
Python
2019년
C
2019년
C
2020년
Python
2021년
Python
2020년
Python
2021년
Python
2022년
C++
}}}}}}}}} ||

파이썬
Python
파일:python-logo-generic.svg
<colbgcolor=#ffffff,#1c1d1f><colcolor=#356fa5> 개발 Python 소프트웨어 재단 (PSF)
라이선스 PSF 라이선스
최초 공개 1991년 2월 20일 ([age(1991-02-20)]년 전)
최신 버전 3.13.0 [1]
파일:홈페이지 아이콘.svg | 파일:GitHub 아이콘.svg 파일:GitHub 아이콘 화이트.svg | 파일:디스코드 아이콘.svg
1. 개요2. 디자인
2.1. 철학2.2. 들여쓰기 기반 코드 블록 처리2.3. 순수 객체 지향2.4. 변수 선언의 부재2.5. 느긋한 연산 (lazy evaluation)2.6. 컴프리헨션2.7. PEP
3. 장점
3.1. 신속한 개발 속도3.2. 과학 및 공학 친화성3.3. 거대한 생태계3.4. 쉬운 난이도 및 교육의 편의성
4. 단점
4.1. 낮은 진입장벽의 부작용4.2. 배포(distribution)상의 어려움 4.3. 속도와 메모리 용량
4.3.1. 속도 향상 방법
4.3.1.1. 반복문 피하기4.3.1.2. C 바인딩 된 외부 라이브러리 사용하기4.3.1.3. 비동기 IO 사용하기4.3.1.4. 다른 구현체 사용하기
4.4. GIL
5. 구현체 목록6. 개발 환경
6.1. 개발 도구6.2. 패키지 관리6.3. 가상 환경
7. 주요 패키지
7.1. 코드 퀄리티 관리7.2. 확장 모듈7.3. 외부 함수 인터페이스(FFI)7.4. 기타
8. 문법9. 설치10. 코드 스타일11. 학습
11.1. 공식 튜토리얼11.2. 유튜브11.3. 웹사이트11.4. 도서
12. 몬티 파이썬의 패러디13. 여담14. 관련 문서15. 외부 링크

[clearfix]

1. 개요

Life is short, you need Python.
인생은 짧기에, 당신에겐 파이썬이 필요하다.
파이썬은 1991년 귀도 반 로섬에 의해 만들어진 인터프리터 프로그래밍 언어이다. 직관적이고 쉬운 문법과 다양하고 풍부한 라이브러리들을 바탕으로 한 강력한 생태계를 가지고 있어 프로그래밍 교육, 인공지능, 데이터 분석 및 빅데이터, 백엔드, 프론트엔드, 웹 스크래핑 등 다양한 분야에서 사용되며, 이에 힘입어 2023 TIOBE 인덱스 기준 프로그래밍 언어 순위 1위이기도 하다.

파이썬 서문에 따르면 파이썬은 1989년 크리스마스에 귀도의 취미 프로젝트로 시작했다. 'Python'이라는 이름의 유래는 귀도가 즐겨 보던 영국의 6인조 코미디 그룹 몬티 파이썬에서 이름을 따왔다.

실행할 수 있는 의사 코드(Executable pseudocode)라고 불릴 정도로 문법이 단순하며 매우 미려하다. 학습 난이도 역시 초보자가 배우기 쉽기에 프로그래밍 입문용으로 많이 추천된다. 앱을 만드는 데는 부적합하지만 시스템 유틸리티나 자동화에는 적합하여 행정 시스템의 문서 정리 등 생산성 및 실무에서의 사용률도 높다. 범용성이 높다는 점은 C 자바스크립트와 유사하다.

2. 디자인

2.1. 철학

파이썬의 디자인 철학은 PEP 20에서 잘 나타나 있다.
1. 아름다운 것이 추한 것보다 낫다. (Beautiful is better than ugly.)
1. 명시적인 것이 암시적인 것보다 낫다. (Explicit is better than implicit.)
1. 간결한 것이 복합적인 것보다 낫다. (Simple is better than complex.)
1. 복합적인 것이 복잡한 것보다 낫다. (Complex is better than complicated.)
1. 들여쓰기를 적게 하는 것이 깊은 것보다 낫다. (Flat is better than nested.)
1. 듬성듬성한 것이 밀집한 것보다 낫다. (Sparse is better than dense.)
1. 가독성은 중요하다. (Readability counts.)
1. 특별한 경우는 규칙을 어길 정도로 특별하지 않다. (Special cases aren't special enough to break the rules.)
1. 하나 실용성은 순수성을 이긴다. (Although practicality beats purity.)
1. 오류는 절대로 조용히 지나가지 않아야 한다. (Errors should never pass silently.)
1. 명시적으로 지나가는 것이 아니라면. (Unless explicitly silenced.)
1. 모호함을 마주쳤을 때, 이를 추측하려는 유혹을 거부하라. (In the face of ambiguity, refuse the temptation to guess.)
1. 명확한, 그리고 가급적이면 유일한 명백한 방법이 있을 것이다. (There should be one-\- and preferably only one -\-obvious way to do it.)
1. 그 방법이 처음에는 명확해 보이지 않을 수 있다.[2]. (Although that way may not be obvious at first unless you're Dutch.)
1. 그러나, 지금 행동에 옮기는 것이 아예 안 하는 것보다는 낫다. (Now is better than never.)
1. 아예 안 하는 것이 지금 *당장* 하는 것보다 나을 때도 많다. (Although never is often better than *right* now.)
1. 그러나, 구현 결과를 설명하기 쉽지 않다면, 당장 하는 것은 좋지 않다. (If the implementation is hard to explain, it's a bad idea.)
1. 반대로, 구현 결과를 설명하기 쉽다면, 당장 하는 것은 좋을지도 모른다. (If the implementation is easy to explain, it may be a good idea.)
1. 네임스페이스를 사용하는 것은 완전 좋은 생각이다 -\- 더 많이 이용하자! (Namespaces are one honking great idea -- let's do more of those!)

특히 그중에서도 가장 유명한 것은 '명확한, 그리고 가급적이면 유일한 명백한 방법이 있을 것이다.'라는 문장인데, 외부에는 '가장 아름다운 하나의 답이 존재한다'라고 파이썬을 표현하는 문장으로 잘못 알려져 있기도 하다.

잘못 알려진 문구는 PEP 584[3]에 따르면 Perl 커뮤니티로부터의 모함에 불과하다고 한다. 실제로도 파이썬에는 한 가지를 여러 방법으로 처리하는 방법들이 있으며, PEP 584는 PEP 20에서 중요한 것은 obvious(명백한)라는 문구라고 해석한다. 즉, 같은 것을 하는 다른 방법이 있는지 여부 자체가 중요한 것이 아닌, 가장 명백한 방법이 존재한다면 파이썬의 정신에 위배되지 않는다는 것이다.[4]

파이썬의 디자인 철학에 맞는 코드를 짜는 것을 파이써닉(pythonic)이라고 부른다. 이는 단순히 스타일 가이드라인을 맞추는 것을 넘어, 파이썬의 파이썬에서 권장되는 다양한 클린 코드 기법을 통해 복잡하지 않고 의미가 명확하며, 명백하게 흐름이 보이는 PEP 20을 염두에 둔 코드를 작성하는 것을 말한다.

2.2. 들여쓰기 기반 코드 블록 처리

대부분의 다른 언어에서는 중괄호를 블록 단위로 사용하지만, 파이썬에서는 중괄호 대신 들여쓰기를 사용한다. 이 들여쓰기 문법은 시각적으로 파이썬과 다른 언어가 구분되는 특징이기도 하다. Lex Fridman과 진행된 귀도의 인터뷰에 따르면 공백은 가독성에 중요한 영향을 끼치며, 코드가 무슨 일을 하는지 알기 어렵게 되기 때문에 필수적이라고 하였다.

같은 인터뷰에서 귀도는 중괄호가 파이썬의 스타일이 될 수 있던 가능성이 있냐는 질문에 그렇다라고 답변하고 귀도는 오랫동안 들여쓰기 방식이 더 좋은 방식이라고 생각하고 지금도 문맥을 제외하면 들여쓰기 방식이 더 좋은 방식이라고 생각하지만 많은 다른 프로그래밍 언어들이 중괄호를 사용하는 지금의 상황에 비추어 보았을 때는 중괄호도 좋은 방법일 수 있다고 암시했다.

2.3. 순수 객체 지향

Python에는 원시 타입(primitive type)이 존재하지 않으며, 클래스, 함수를 비롯한 모든 것이 객체로 취급된다.

다만 이를 파이썬이 객체 지향만 지원한다고 오해하지는 않도록 유의해야 한다. 파이썬은 멀티 패러다임 언어로, 절차적 프로그래밍, 함수형 프로그래밍, 객체 지향 등 다양한 패러다임을 모두 지원하는 언어이다.

속도에서 약간의 희생되는 부분이 있었지만 덕분에 프로그래머는 더욱 편리하게 객체로서 정수를 비롯한 여러 타입들을 사용할 수 있다.

2.4. 변수 선언의 부재

파이썬은 여타 다른 언어들과 달리 변수 선언이 없다. 예를 들어 Rust는 다음과 같이 변수 선언을 해야 하지만
#!syntax rust
let mut hello = "world!";

파이썬의 경우에는 따로 선언을 하지 않는다.
#!syntax python
hello = "world!"

이는 초보자들이 파이썬을 쉽게 접근하는 데에 도움이 되고, 변수 선언과 관련된 오류를 피할 수 있어 도움이 된다.

변수 재할당 금지하는 방법 역시 제공하지 않고, 작명 규칙이나 타입 힌트와 같은 것으로 사용자에게 상수라는 정보를 전달한다.[5]
#!syntax python
from typing import Final

# 작명 규칙을 이용한 상수 표기
HELLO = "world!"
# 작명 규칙과 타입 힌트를 이용한 상수 표기
HELLO_WORLD: Final = "hello, world!"

# 상수 표기는 단순한 convention이기 때문에 재할당도 가능하다.
HELLO = 3

2.5. 느긋한 연산 (lazy evaluation)

느긋한 연산은 연산을 필요할 때까지 늦추고 필요할 때 계산이 되는 방식을 말한다. 파이썬에서는 range(), re.Match.finditer(), 제너레이터 함수 등의 이터러블이나 이터레이터에서 쓰이고 있다.

제너레이터 함수의 예시는 다음과 같다.
#!syntax python
# 제너레이터 함수
def get_multipe(number_to_muliply, limit=100):
    for multiple in range(1, limit + 1):
        yield number_to_muliply * multiple

multiple = get_multipe(2)
print(next(multiple))  # 결과: 2
print(next(multiple))  # 결과: 4
print(next(multiple))  # 결과: 6
...
print(next(multiple))  # 결과: 200

for multiple in get_multipe(3):
    print(multiple, end=', ')
# 3, 6, 9, ... 300, 으로 출력됨.

이터레이터는 next() 함수와 같은 문법들을 이용하여 순서대로 값을 호출할 수 있다. for ... in <이터러블>:과 같은 문법은 내부적으로 iter(<이터러블>)을 통해 이터레이터를 생성한 뒤 next(<이터레이터>)를 반복적으로 사용한다.

이터레이터나 이터러블은 전부 리스트로 변환한 뒤 사용하는 것보다 조금 느릴 수는 있지만 메모리 효율적이다. 예를 들어 list(range(100))은 0부터 99까지의 모든 숫자를 담은 리스트를 모두 메모리에 담아야 하지만 range(100)은 0부터 99까지 모든 숫자가 있다는 정보만 담고 있기에 메모리에 전체 리스트를 담을 필요가 없다.

파이썬 2까지는 이터레이터를 사용하지 않는 경우가 있었다. 예를 들어 range()는 리스트를 반환했고 대신해 xrange()를 사용해야 했었다. 파이썬 3부터는 range()를 이터러블로 변경하면서 range() 함수 안의 값이 얼마나 크든 간에 메모리 효율적으로 사용할 수 있게 되었다.

2.6. 컴프리헨션

컴프리헨션은 다른 통상적인 언어들과 파이썬을 구분하는 파이썬의 특징적이면서도 유용한 기능이다.

컴프리헨션은 많이 사용되고 형태가 정형적이기에 많은 최적화가 들어가 있어 빠르다.
#!syntax python
[f"{i:03d}" for i in range(100) if i % 3 == 0 or i % 2 == 0]

2.7. PEP

PEP(Python Enhancement Proposals, 파이썬 개선 제안서)란 파이썬 커뮤니티에 정보를 제공하거나, 파이썬이나 파이썬의 프로세스나 환경을 위한 새 기능을 설명하기 위한 내용을 담은 디자인 문서이다[6]. 모든 PEP 문서는 PEP 0에서 찾아볼 수 있고, 깃허브에서 소스 확인 가능하며, 각 문서의 끝에는 깃허브로 향하는 링크가 달려 있다.

PEP 8, PEP 20과 같이 자연수 번호를 붙이는데, 일반적으로는 글이 쓰여진 순서대로 붙지만, 파이썬 3와 관련된 글은 3000부터 순서대로 붙여지며, 거버넌스와 관련된 자료는 8000번부터 붙여지고, PEP 754 PEP 801처럼 특별한 이유로 순서를 무시하고 번호가 붙여진 경우도 있다.

3. 장점

3.1. 신속한 개발 속도

파일:xkcdpython.png
xkcd 353화 [7]

파이썬의 아이덴티티. 높은 생산성은 그 무엇과도 비교할 수 없는 파이썬만의 특징이다. 쉬우면서도 다양한 패키지 생태계를 통한 범용성까지 갖춘 프로그래밍 언어는 찾기 힘들다.

인터프리터 언어이고 우수한 자료형과 다양한 모듈 등을 기본으로 제공해 개발 기간이 단축되는 것이 특징.

파이썬은 다른 언어와 함께 잘 작동하며, 이와 같은 특성 때문에 glue language라고 불리기도 한다. 예를 들어 C++로 구현되어 있지만 파이썬에서 사용할 수 있는 OpenCV나 C C++로 구현된 NumPy 등 다른 언어로 구현된 후 파이썬으로 사용할 수 있도록 만들어진 라이브러리는 파이썬 생태계에서 중요한 축을 담당한다. 이러한 패키지들은 파이썬의 높은 생산성의 장점은 그대로 가지면서 동시에 높은 속도까지 가질 수 있어 장점이 많다.

Traceback도 개발 속도에 한몫한다. 예전에 파이썬과 많이 비교가 되던 Perl 은 스택트레이스를 보여주지 않았기 때문이다. 반면 파이썬은 코드를 실수로 잘못 짠 곳이 있다면, 어떤 어떤 파일의 어떤 줄에서 어떤 함수에서 어떤 종류의 문제가 발생했는지 자세하게 알려준다. 꽤 많은 양의 메시지를 한꺼번에 보여주기 때문에 초보자에게는 당황스러울 수 있지만, 디버깅 시에는 정말 편리하다. 파이썬 이후에 나온 인터프리터 언어들은 스택트레이스와 오류 줄을 표시한다.

빠른 아이디어 구현이 생명인 데이터 과학 분야나 간단한 스크립트 및 자동화 분야에서 각광을 받고 있다.

동적 타입 언어이기에 성능이나 유지 보수 면에서는 단점이 지적되고 있지만 대신 3.5버전부터 타입 힌트를 지원하며 유지 보수 문제는 많이 해결되게 되었다.

3.2. 과학 및 공학 친화성

파이썬은 과학과 공학 분야에서 필요한 여러 기능을 기본적으로 제공한다. 정수의 크기에 제한이 없으며[8], 또한 놀랍게도 복소수를 별도의 import까지도 필요 없는 기본 타입으로 지원하며, 표준 라이브러리의 decimal, fractions 모듈을 사용해 소수점과 유리수를 정밀하게 다룰 수 있다. 이러한 기능을 다루는 암호학과 통계 분야에서 쓰기에 알맞다.

파이썬 생태계 또한 공학 및 과학 분야를 다양하게 지원한다. 복잡한 수치와 큰 데이터를 다루는 연산에 알맞은 NumPy, SciPy, pandas, 데이터를 그래프로 시각화하는 Matplotlib, 코드와 데이터를 함께 다룰 수 있는 Jupyter Notebook 등의 강력한 패키지와 도구들을 무료로 사용할 수 있다. 이 점 때문에 막대한 라이선스 비용을 지불해야 하는 MATLAB과 기타 과학 프로그램들의 많은 사용자들이 파이썬으로 넘어오게 되었고, 이는 파이썬이 풍부한 개발자 풀을 지니게 되는 단초가 되기도 하였다.

언어 개발자들도 이러한 사실을 잘 알고 있기 때문에 언어 차원에서 관련 패키지를 위한 기능을 제공하기도 한다. 행렬 곱(@) 연산자가 대표적인 예인데, 파이썬 stdlib에서는 사용하지 않지만 NumPy 등에서 자주 사용된다는 이유로 추가될 수 있었다. 자세한 내용은 PEP 465에 잘 설명되어 있다. 해당 문서에 따르면 NumPy는 math 모듈보다도 1.5배가량 더 사용되고, 비트 연산자들에 비해 행렬 곱이 더 잘 사용된다고 설명한다.

3.3. 거대한 생태계

파이썬은 매우 거대한 생태계를 가지고 있기에 자신이 원하는 것이 있을 때 관련된 패키지나 코드를 찾기에 매우 용이하다.

수학, 공학 및 통계학부터 시작해서 자동화, 백엔드, 머신 러닝, 게임 등 다양한 목적의 패키지가 있다. 자세한 내용은 '주요 패키지' 항목 참고.

3.4. 쉬운 난이도 및 교육의 편의성

파이썬은 주요 언어 중 가장 초보자 친화적인 특성이 강하기 때문에, 교육용 프로그래밍 언어로 각광받고 있다. 현재 세계 유수의 대학교들은 프로그래밍 개론에서 쓰이는 언어를 C, C++나 Java에서 파이썬으로 바꾸었다.

대한민국의 대학교 중 서울대, KAIST, 충남대, 포항공대 고려대와 같은 곳에서도 파이썬을 사용해 프로그래밍을 가르치고 있다.

국내외를 막론하고 프로그래밍을 처음 시작하는 사람에게 주로 추천되는 언어이며, 2020년 이후 각종 분야에 적극적으로 활용되고 있는 AI 머신 러닝 부분에 상당한 지분을 가지고 있는 언어다보니 IT를 배우려는 사람들에게 동기가 되는 편이다.

4. 단점

4.1. 낮은 진입장벽의 부작용

파이썬은 분명 장점이 많고 효율적인 언어지만, 대한민국에서는 코딩과 AI 붐이 터진 이후 무조건 파이썬만 배우면 만사 오케이라는 식의 허위/과장광고를 국가 차원에서 하고 있기 때문에 파이썬에 대한 오해와 그로 인한 잘못된 진로선택 사례가 수도 없이 많은 실정이다.

문법이 간결하고 접근성이 좋으며 교육 자료가 많다는 점은 분명 장점이지만, 정말로 파이썬이 입문용으로 좋은지에 대해서는 개발자들에게는 의견이 갈리는 주제다. 정확히는 독학을 하거나 코딩 학원처럼 단편적인 기술만 가르쳐주는 곳에서 배울 때 파이썬은 함정이 되기 딱 좋다.

프로그래밍 자체를 배우기 위해서는 파이썬만으로는 부족하며, 정말 파이썬을 주력으로 스펙을 쌓고 싶다면 파이썬을 아주 깊게 파야 한다. 객체 지향은 최소 데코레이터를 알아야 하고, 제대로 쓰기 위해서는 메타클래스 개념까지 알아야 한다. 또 일반적인 얕은 복사와 깊은 복사를 구분하지 못하면 로우 레벨의 관점도 알 수 없다. 난이도가 쉽고 아무나 배우기 좋다는 점은 바꾸어 말하면 애매하게 잘해봤자 전문성이 없다는 의미이고[9], 일반적인 개발 수준에서는 파이썬이 할 수 있는건 다른 언어들도 다 할 수 있거나 오히려 더 효율적이다. 즉, 회사에서 아예 파이썬을 지정하는 경우가 아닌 이상 파이썬을 배웠다고 해서 다른 언어를 사용하는 개발자보다 특별히 더 뛰어난 무언가가 없다는 점이다.

파이썬이 다른 언어와 차별점을 둘 수 있는 분야는 통계나 데이터 마이닝 빅 데이터 분석 등의 데이터 사이언스 분야이고, 파이썬 관련 모듈이 다수 지원되는 머신 러닝이다. 다르게 말하면, 파이썬이 정말 유의미한 가치를 가지는 분야는 개발이 아니라 과학과 공학 분야라는 것이다. 당연히 이쪽에서 1인분을 하려면, 통계학 수학에 대한 교양이 기본으로 깔려 있는[10] 상태에서 파이썬으로 다양한 외부 모듈들을 끌어와 적재적소에 활용할 정도의 실력이어야 한다. 이런 쪽이 아니라 일반적으로 생각하는 개발 직군을 노린다면 Java, C++, JavaScript 등을 공부하는 게 포트폴리오와 개인 역량에 훨씬 도움이 된다.

파이썬으로 프로그래밍 첫발을 떼면 추후 다른 언어로 옮길 때 본인이 힘들고, 컴퓨터적 사고를 하기가 어렵다. 파이썬은 타입 체크가 느슨한 동적 언어이기에 차후 정적 언어로 넘어가기가 어렵고[11], 파이썬 특유의 들여쓰기 기반의 간결하고 압축성 높은 코드 스타일에 익숙해져 있으면 다른 언어를 배울 때 상당히 이질적이다. 게다가 '쉽고 간단하게'를 표방하는 언어인 만큼 많은 것들이 모듈화가 되어있는데, 별도의 구현 없이 바로바로 가져다 쓸 수 있다는 점은 그저 코드를 돌려서 결과만 뽑아내면 그만인 과학도나 연구자에게는 안성맞춤이겠지만 개발 공부를 하는 사람에게는 독이 된다. 연결 리스트, 이진 탐색, 정규 표현식, 다중 스레드 처리 등을 메소드 하나로 뚝딱 해결해 주는 것에 익숙해지면 이 복잡한 처리를 컴퓨터가 어떤 과정으로 하는지 등의 디테일한 이해를 하기가 어렵다.[12]

파이썬 입문론을 예찬하는 사람들이 '각종 대학에서도 파이썬을 가르친다'는 것을 뒷받침 근거로 내세우나, 대학은 그저 언어만 가르치는 게 아니라 자료 구조, 알고리즘, 컴퓨터 구조, 공학 수학 등 컴퓨터 전반의 전문적인 지식을 함께 병행해서 가르친다는 점을 간과한 1차원적인 주장이다. 대학 교수들이 과제까지 내가며 이런 요소를 하나하나 직접 구현해 보게 하는 데에는 다 이유가 있다. 무엇보다 일반적인 IT 대학은 언어를 최소 2~3개씩 가르치지 정말 졸업할 때까지 파이썬 하나만 주구장창 바라보는 커리큘럼은 없다. 비싼 등록금을 내고 2~4년의 시간을 할애해 대학을 다니는 대학생들은 바보가 아니다.

이러한 문제점들로 인해, 파이썬 자체가 코딩의 입문 또는 당장 필요한 기술을 익히기에는 좋지만 진지하게 진로를 생각하는 사람에게 프로그래밍 개념의 입문으로는 적절하지 않다는 비판이 상당히 많이 존재한다. 파이썬은 수많은 프로그래밍 언어 중 하나일 뿐이며, 프로그래머라면 언어는 도구로 사용되어야지 목표로 사용되어서는 안 되기 때문이다.

결론은 '파이썬을 배우지 말라'는 것이 아니다. 본인이 가고자 하는 진로에 정확히 어떤 언어와 어떤 공부가 필요한지를 파악하는 것이 좋다는 뜻이다.

4.2. 배포(distribution)상의 어려움 [13]

파이썬은 배포를 하는 과정이 복잡하고 파편화되어 있다. 파이썬의 경우 인터프리터 언어이기 때문에 실행하려면 무조건 파이썬이 설치된 환경을 만들어야 하고, 그 과정에서 환경 변수 설정이나 개발 환경 설치를 요구하기도 한다. 파이썬 설치 또한 쉽지 않은데, 운영 체제가 무엇인지에 따라 설치 방법이나 주의해야 할 점 등이 모두 다르다. 이러한 단점은 인터프리터가 필요한 언어들에서는 공통적으로 나타나는 특징이기는 하나[14], 파이썬의 경우 사용자층이 매우 다양하고 개발자가 아닌 경우도 매우 많기 때문에 이러한 문제들이 더욱 부각된다.

이러한 특성은 '파이썬 환경을 자신의 시스템에 구축한다' 라는 개발자(프로그래머)의 입장과 '프로그램의 구동 환경 구축 단계에는 관여하지 않고 기능 자체를 사용' 하기를 원하는 일반 사용자(최종이용자)의 두 입장 중에서 Python이 전자를 지원하고 발달되어 왔기 때문이다. 많은 패키지와 도구들이 '프로그래머가 곧 자기가 만든 프로그램의 이용자'를 가정하여 만들어졌으며, 그나마 'Python 프로그래머'들에게 'Python 프로그래머'가 배포를 하는 방식은 몇 가지가 있으나, '순수한 사용자'에게 'Python으로 만든 기능'을 전달하는 수단에 있어서는 비슷한 사용인구를 가지는 다른 언어들에 비해 상대적으로 많이 부족하다.[15] '프로그램을 만드는 환경'과 '프로그램을 돌리는 환경'이 사실상 구분되어 있지 않다. 이 때문에 'Python 프로그래밍 환경'은 존재하고 다운받아 설치할 수 있지만, '이걸 깔면 Python 프로그램을 돌릴 수 있습니다'라는 환경(런타임 라이브러리)은 별도로 존재하지 않는다. 그래서 프로그래머들이 자신이 개발했던 환경을 '알아서 잘'포장해서 전달해 줘야 하고, 이것이 Python 프로그램 배포의 가장 기본적인 원리다. 메이저 버전별로 업데이트가 따로 되기 때문에 버전이 다르다면 따로 받아야 하는 건 덤이다.

이 말은 두 가지를 의미한다. 첫째, 다른 시스템에서 프로그램을 돌리기 위해서는 (정석적으로는) 만들 때 갖췄던 환경(Python 및 패키지)을 모두 다 똑같이 설치해 줘야 한다는 것. 둘째, 그 '환경'을 설치하는 과정은 기본적으로(정석적으로)는 일반인이 아닌 프로그래머가 쓰는 것을 전제로 만들어져 있다는 것.

실제로 Stackoverflow 같은 개발자 포럼에도 'Python 사용할 때는 좋은데 이걸로 만든 프로그램을 남에게 전달할 때는 어떻게 하죠?'라는 질문에 가장 흔한 반응이 '그까이꺼 터미널 띄워서 Python 설치하고 pip 깔아서 패키지 잘 인스톨하라고 하세요. 쉽잖아요.'하는 식의, 전형적인 프로그래머 입장의 답변이 주를 이루고 있다.

대부분의 언어는 '프로그래머'가 '프로그래머가 아닌 사람'을 위하여 프로그램을 만들고, 그것을 받은 사람은 개발 도구 없이도 실행할 수 있는 것이 당연시되어 있다. 따라서 '프로그램을 만드는 도구'와 '프로그램을 실행할 수 있는 조건'은 분리되어 있다. '집을 사는 사람이 집과 함께 집을 짓는 과정에 필요한 시멘트, 포크레인, 덤프트럭, 크레인을 함께 인수받아야만 집에 입주할 수 있는 게 아닌 것과 같다'. 예를 들어, C/ C++와 같은 시스템 레벨에 가까운 언어는 기본적으로 OS와 함께 해당 언어로 만든 프로그램을 실행할 수 있는 환경이 갖춰져 오거나, 추가 기능이 필요한 경우에는 OS 제작사 등이 책임을 지고 최대한 불편하지 않게 설치할 수 있도록 만들어 놓는다. 예를 들어 게임 설치 프로그램이 자동으로 인스톨러와 연동[16]되는 등으로.

Java C#과 같은 '가상 실행 환경'을 통해 돌아가는 언어의 경우 해당 가상 환경이 얼마나 널리 보급되는지가 언어의 흥망을 좌우하는 매우 중요한 요소이므로, 해당 언어를 지원하는 단체나 기업에서 매우 공을 들여 최대한 쉽고 간단명료하게 설치할 수 있도록 최선을 다한다. Java의 경우 Java로 된 프로그램을 실행하기 위해서는 JRE[17]이라는, '자바 프로그램을 실행하기 위한 실행 환경'을 공식 사이트에서 쉽게 다운받아서 다른 응용 프로그램 설치하듯이 '30억 개 장치에서 Java 사용'이라는 광고 문구를 보며 한 큐에 설치하는 것으로 모든 준비가 끝난다.[18] C#의 경우 마찬가지로 .Net 이라는 이름으로 쉽게 최신 버전 환경을 설치하여 사용할 수 있게 만들어 놓았으며 Microsoft Windows와 C#이 같은 Microsoft에서 개발되기 때문에 윈도우 신버전에는 당시 최신 버전의 .Net 환경이 기본적으로 내장되어서 나오고 업데이트조차도 윈도우 업데이트에 통합되어서 제공된다.[19]

이런 설치 과정을 줄이는 방식 중 하나로 py2exe, Pyinstaller, cx_Freeze와 같이 파이썬 자체와 사용된 패키지 모두를 하나의 exe로 묶는 방식이 사용되고 있다. 하지만 표준화되어 있지 않은 아닌 써드 파티 패키지[20]이기 때문에 일부 패키지들과 호환되지 않거나 계속해서 업데이트가 되지 않는다면 장래적으로 호환성의 문제 발생할 수 있다는 약점이 있다. 특히 런타임을 이용하여 컴파일되는 다른 언어들에 비해 필연적으로 용량이 매우 커지는 문제가 있는데, 간단한 Hello, world! 프로그램을 C 언어를 이용해 exe 파일을 만들면 약 0.25 MB에 불과하지만, 파이썬과 Pyinstaller를 이용해 exe 파일을 만들면 약 5.8 MB 용량의 파일이 만들어진다. 이런 식으로 패키징된 프로그램 여러 개를 사용해야 한다면 각각의 프로그램마다 제각기 '자신용' Python 환경이 통째로 딸려오게 온다는 것 역시 낭비 요소가 된다.

프로그램 사용자뿐 아니라 개발자에게도 파이썬 배포는 골치 아픈 작업인데, 패키징이 파이썬과 같이 만들어진 것이 아닌, 중간에 개발된 것이기 때문에 애드혹이 많고 파편화되어 있다. 최근에는 pyproject.toml로 모든 설정을 몰고 Poetry와 같은 패키지를 사용하며 해결될 수 있지만 여전히 이전에 만든 튜토리얼들이 돌아다니고 초보 개발자가 하기에는 상당히 어려운 과정이다.

Python이 '입문하기 쉬운' 언어로 부상하고, 특히나 AI/수리과학/딥러닝 등에 많이 사용되면서 'Python 사용자'들 사이에서 프로그램을 교류하기 위한 궁리는 많이 진척되었다. 특히 Docker나 주피터 노트북 같은 솔루션은 '해당 환경을 갖추고 있는 사람에게는' 매우 쉽고 편하게 프로그램을 받아서 돌려볼 수 있는 도구이다. 그러나 역설적으로 '프로그래머가 되라고 권유하기 쉬운' 언어가 되어 가면서 '애초에 프로그래머가 아닌 사람을 위한 지원에는 관심이 거의 없는' 언어로 점차 발달하게 된 것이 아이러니하며 이러한 쉬운 교류 관점에 프로그래머적이 아니라며 비판을 가지는 사람들도 존재한다.

아이러니한 점은, 파이썬이 프로그래머들에게 쓰기 편하기 때문에 Make 등의 패키지/프로젝트 관리용 스크립트로도 많이 사용된다. 즉 파이썬 자체는 패키징 도구가 난잡한데, 정작 다른 프로그램을 패키징할 때는 파이썬이 유용한 도구로 많이 쓰인다는 것.

최근에는 아예 Python을 컴파일해서 네이티브 환경에서 실행 가능한 바이너리를 생성하는 별도의 프로젝트들 역시 주목받고 있다. 대표적으로 Nuitka, LPython, GraalPy과 같은 경우가 이런 시도들이다.

4.3. 속도와 메모리 용량

파이썬의 가장 큰 단점으로 꼽히는 것은 느린 속도, 높은 메모리 사용량 등 '하드웨어'상의 낮은 효율성이다. 한 논문에 따르면, CLBG에서 제시한 10개의 벤치마킹을 돌려본 결과 파이썬은 C에 비해 71.90배의 시간, 2.80배의 메모리, 75.88배의 에너지를 더 소모한다고 한다.

겉보기에는 큰 문제처럼 보이지만 생각보다 큰 문제가 되지 않는데, 파이썬의 직관적인 문법 덕분에 개발 속도가 매우 크게 단축이 되고, 극단적으로 1ms 돌아갈 프로그램이 100ms에 돌아간다고 해도 많은 경우 문제가 되지 않기 때문이다. 또한 NumPy나 C, C++, Rust 등 더 빠른 언어를 뒤에서 사용하는 라이브러리들의 경우 순수 파이썬 구현이 아니기 때문에 빠른 언어와 비교 시 실행 속도에 별다른 영향을 미치지 못한다.

머신 러닝 라이브러리들이 대표적인데, 머신 러닝 라이브러리인 TensorFlow나 PyTorch는 C++으로 제작되었고, GPU 가속을 이용할 경우에는 GPU의 속도에 영향을 받지 파이썬을 활용하지 않기에 파이썬의 속도와는 큰 관련이 없다.

그러나 다른 언어에 비해 많이 느린 것은 사실인지라, 프로그래밍 대회에서 실행 시간 제한 때문에 어려움을 겪기도 한다. 코딩 테스트에서는 일반적으로 외부 라이브러리를 사용하지 못하게 하지만 일부 코딩 테스트에서는 NumPy와 같은 외부 라이브러리를 사용할 수 있도록 한다. 예를 들어 LeetCode는 NumPy를 사용할 수 있도록 허용하지만 백준은 NumPy를 허용하지 않는다.

이는 병렬 처리를 통해 개선할 수 있지만 후술할 GIL 때문에 멀티스레딩의 경우 여전히 제약이 존재한다.

느린 속도를 체감할 수 있는 경우는 코딩 테스트 때나 많은 계산을 요구하는 경우이다. 반대로 네트워크를 사용하거나 파일 입출력이 많은 경우에는 파이썬과 다른 언어의 차이가 그리 크지 않다. 이를 io bounded task라고 부르는데, io를 사용하기 위해 기다리는 시간이 대부분이기 때문에 네트워크나 파일 입출력의 속도가 중요하지 파이썬의 성능이 크게 눈에 띄지는 않는다. 또한 많은 계산을 요구하는 경우 외부 라이브러리를 통해 상당한 폭으로 개선이 가능하다.

CPython 개발자들도 이를 인지하고 있으며 faster-cpython 프로젝트 등을 통해 속도를 크게 향상시키고 있다. 특히 CPython 개발자들과 함께 귀도가 재직 중인 마이크로소프트와 장고를 사용하고 있는 인스타그램 등의 회사에서 CPython 속도 향상에 많은 기여를 하고 있다. 이 프로젝트의 결과는 Python 3.11에서 가시화되었는데, 일반적으로 20%, 최대 60%까지의 성능 향상을 이루어 내었다. 대부분의 머신 러닝 라이브러리에서 3.11 버전을 지원하는 2024년 부터는 머신 러닝 계열에서 상당한 속도 향상이 기대된다.

4.3.1. 속도 향상 방법

이러한 파이썬의 느린 속도를 보완하기 위해 다음과 같은 여러 가지 방법이 사용된다.
4.3.1.1. 반복문 피하기
우선 파이썬의 기본 내장 모듈 중 일부는 로우 레벨로 구현되어 있고 만약 해당 모듈을 사용할 수 있다면 더욱 빨라질 수 있다는 점을 알아야 한다.
예를 들어 다음과 같은 코드는 비효율적이지만,
#!syntax python
# 비효율적인 프로그래밍의 예시

sum_result = 0
for i in range(1, 10001):
    sum_result += i

# 1부터 10000까지 모두 더한 값인 50005000이 나옴.
print(sum_result)

sum을 이용한 다음의 코드는 효율적이며, 더 깔끔하다. sum은 파이썬이 아닌 C언어로 구현되어 있기 때문이다.
#!syntax python
# 효율적인 프로그래밍의 예시

# 1부터 10000까지 모두 더한 값인 50005000이 나옴.
print(sum(range(1, 10001)))

4.3.1.2. C 바인딩 된 외부 라이브러리 사용하기
Numpy, Numba, TensorFlow 등의 라이브러리는 내부적으로 C나 C++로 개발되어 있고, 파이썬을 사용하는 것보다 더욱 빠른 속도를 기대할 수 있다. 예를 들어 NumPy을 사용하면 C에 필적하는 속도를 낼 수 있다.
4.3.1.3. 비동기 IO 사용하기
파이썬 3.4 버전부터는 F에서 영향을 받아 표준 라이브러리의 각종 파일 입출력, subprocess, socket 통신 등의 기능들을 비동기 패러다임으로 이용할 수 있는 asyncio 패키지가 포함되었다. 파이썬 3.5부터는 async, await 키워드가 포함되어 asyncio 라이브러리에 의존할 수밖에 없던 비동기 IO 기능을 다른 서드 파티 라이브러리도 보다 쉽게 지원할 수 있도록 바뀌고, 비동기 처리 내부에서의 예외 처리 과정이 개선되었다.
4.3.1.4. 다른 구현체 사용하기
CPython 외의 여러 다른 구현체들을 통해 이 문제를 해결할 수도 있다. JIT을 사용하는 PyPy, LLVM으로 컴파일되는 GraalPy, Codon, GIL이 없는 Jython, 혹은 구현체는 아니지만 LLVM 컴파일을 이용하는 Numba LPython, Nuitka 등을 사용할 수 있다.

파이썬의 슈퍼셋을 자처하지만 자체 문법은 전혀 딴판인 Mojo와는 달리 Nim은 문법은 파이썬과 매우 유사하지만 파이썬과 서로 모듈 호환은 되지 않는데, 그래도 익숙한 파이썬의 문법을 가지고 코딩을 할 수 있다는 장점이 있다.

4.4. GIL

GIL(Global Interpreter Lock)은 파이썬 인터프리터의 제어권을 단 하나의 스레드만이 가질 수 있도록 하는 뮤텍스(또는 잠금)이다.[21]

GIL은 파이썬의 성능에 대한 이야기를 할 때 빼놓을 수 없다.

CPython에서는 GIL을 이용해 여러 스레드를 만들더라도 GIL에 의해 동시에 한 바이트코드만 실행되도록 제한한다.

기본적으로 GIL이 구현된 이유는 reference counting 때문인데, 그 외에도 구현이 수월해지고 굉장히 이해하기 어려운 동시성 관련 버그가 일어나는 것을 막을 수 있으며 race condition을 효과적으로 방지하고, IO가 주가 되는 작업은 GIL의 유무에 따른 유의미한 성능 차이가 없다는 장점이 있었다. 또한 오히려 GIL이 없다면 싱글스레드 프로그램에서는 불필요한 스레드 관련 작업이 추가로 들어가야 하기에 더욱 속도가 느려진다는 점도 GIL을 계속해서 사용하는 이유가 되었다. 특히 파이썬이 멀티스레딩을 구현한 당시에는 멀티코어 CPU가 흔하지 않았다는 점도 중요한 이유였다.

하지만 다중 코어 CPU가 보편화된 지금에 이르러서는 다중 코어를 제대로 활용하지 못하게 되는 원인이 되면서 파이썬의 성능을 제한하는 가장 큰 원인으로 지적되고 있다.

파이썬 커뮤니티는 이 문제를 피하기 위해 다양한 방법을 사용해 왔다. 일부 C 라이브러리(Numpy, Scipy, Numba)는 GIL을 우회하는 방법을 제공하기에 관련 모듈을 사용하거나, 멀티프로세싱을 사용하거나, 계산량이 많은 부분은 C와 같은 성능이 좋은 언어로 구현하는 등 다양한 방법을 사용했다. Jython같은 일부 구현체는 GIL이 없기도 하다. 하지만 근본적인 해결책이 아닌 우회적인 방법이고, 매우 성가시다는 단점이 있다.

따라서 GIL을 없애자는 논의는 지속되어 왔고, 파이썬 3.13에서는 GIL을 선택적으로 만들고, 장기적으로는 GIL을 파이썬에서 완전히 제거하는 방향으로 결정되었다.[22] 따라서 미래에는 GIL과 관련된 성능적 제약 문제가 다수 해결될 것으로 보인다.

2024년 10월 7일에 파이썬 3.13.0이 릴리즈 되었다.[23] 3.13.0은 GIL 프리 모드가 적용된 최초 버전이다.[24]

5. 구현체 목록

파일:상세 내용 아이콘.svg   자세한 내용은 Python/구현체 문서
번 문단을
부분을
참고하십시오.

6. 개발 환경

6.1. 개발 도구


파이썬을 설치하면 'python', 'python3(POSIX 계열 한정)' 혹은 'py(윈도우 한정)'라는 명령을 통해 기본적으로 repl[25]을 사용할 수 있다. 이는 계산기로 사용하거나 한두 줄짜리 간단한 프로그래밍을 하기에는 적합할지 모르지만 서너 줄만 넘어가도 사용하기에 조금 불편하며 값이 저장되는 것이 아니기에 사용하기에 좋지는 않다.

저사양 노트북이라면 IDLE를 사용하는 것도 고려할 만하다. IDLE은 파이썬에 기본 탑재되는 코드 편집기로 REPL과 달리 .py 파일을 편집할 수 있도록 하는 기능도 있고 힌트 등도 지원한다. 하지만 아래에 소개될 다른 코드 편집기들에 비해서는 기능이 압도적으로 부족하기에 일반적으로는 다른 편집기를 추천하는 편이다.

IPython은 파이썬의 기본 REPL보다 진보된 REPL이다. 기본 REPL과 마찬가지로 결과가 저장되지 않고 간단한 계산에 이용하기 좋은 정도이지만 만약 REPL을 사용해야 할 일이 있다면 IPython을 이용하는 것이 더 좋다.

Jupyter Notebook은 REPL을 파일 형식으로 만든 것이라고 보면 좋다. 특이점은 웹 브라우저에서 실행된다는 점이다. %load_ext 명령어를 통해 다양한 확장 프로그램도 이용할 수 있다. PyCharm 유료 버전이나 VSCode에서도 사용할 수 있도록 지원해서 만약 VSCode나 PyCharm을 이미 사용하고 있다면 웹 브라우저에서 사용하는 대신 자신이 선호하는 IDE에서도 직접 사용이 가능하다. 온라인에서 파이썬 실행을 할 때 사용할 수 있는 Colab도 Jupyter 기반이다.

VSCode[26]와 PyCharm은 IDE(Integrated Development Environment)로, 터미널, 디버거, 확장(Extension), 코드 편집기 등 개발에 도움을 주는 각종 기능들이 담겨 있는 앱이다. IDE는 작업 중인 코드상의 문제를 추적해 주거나 스타일 수정을 해 주는 패키지와의 연동을 통해 GUI상에서 코드 퀄리티 관리를 자동으로 해 주는 편리한 기능도 제공한다.

PyCharm JetBrains 계열 IDE로 파이썬에 대한 IDE이다. 사유 소프트웨어이고 Jupyter Notebook 실행 등 일부 기능은 유료 버전에서만 사용 가능하기는 하지만 파이썬 분야에서 VSCode와 함께 가장 많이 사용되는 IDE이기도 하다.

VSCode는 자유 오픈 소스 소프트웨어이고 모든 기본 기능이 무료이며 다양한 확장 프로그램도 사용할 수 있다. 파이썬 외에도 여러 다른 언어들까지 확장 프로그램을 설치하면 한 에디터로 처리할 수 있다는 점도 장점으로 꼽힌다.

이 외에도 아나콘다에 기본 탑재된 Spyder Visual Studio, Sublime Text, Notepad++ 등 다양한 개발 도구로도 파이썬 개발이 가능하다.

6.2. 패키지 관리

파이썬의 라이브러리 개발 방식은 세월이 흐름에 따라 여러 차례 바뀌었다.

패키지 관리자라는 개념이 없어서 각자 프로그램의 소스 코드를 다운로드해 쓰던 시절에는 setup.py라는 설치 스크립트를 각자 만들어서 파이썬 프로그램과 함께 배포하는 것이 관행이었다. 복잡한 설치 스크립트가 필요한 이유는 여러 OS 간의 호환성 문제를 해결하기 위함도 있지만, C와 C++ 코드를 함께 사용한 라이브러리를 배포하기 위함이다. 이러한 언어는 해당 OS에 맞게 컴파일해야 하는데, 수많은 OS에 맞춰 컴파일하는 것은 문제가 있었다.

이를 언어 차원에서 지원하기 위해 파이썬 1.6부터는 distutils라는 빌드 도구를 기본 탑재하였다. 그런데 distutils는 의존성을 설치하지 못해서 직접 일일이 설치해야 한다는 치명적인 문제가 있었다. 이를 해결하기 위해 setuptools라는 도구가 등장하였다.

이후 setup.py를 만드는 기존의 방식의 단점이 부각되었다. setup.py를 실행하는 데 필요한 도구[27]가 있는지 확인하고, 없으면 자동으로 설치하거나 사용자에게 알려주는 기능이 없으며 임의의 파이썬 코드이기에 작성하기 때문에 패키지 이름이나 버전과 같은 메타데이터를 추출하는 것이 까다로우며 악의적인 코드를 심을 수 있고, setuptools를 직접 import하기 때문에 사용자가 다른 빌드 도구를 선택할 수 없다는 단점이 있었다.

이 때문에 setup.py를 작성하는 대신 pyproject.toml이라는 설정 파일을 사용하는 표준안인 PEP-518이 등장하였다. pip는 버전 10.0부터 pyproject.toml을 지원했고, 현재는 파이썬 표준 방식으로 자리 잡고 있다.

6.2.1. PyPI

파이썬의 공식 패키지 저장소로, Python package index의 줄임말이다. 2012년 파이썬 소프트웨어 재단에 의해 구축되었다. 2021년 11월 기준 34만여 개의 패키지를 제공한다. 아래와 같이 파이썬 패키지를 간단히 설치할 수 있다.
#!syntax sh
pip install package

그러나 PyPI의 기본 명령어인 pip를 사용할 경우, 기본적으로 패키지를 모두 한곳에 설치하기 때문에 시스템에 내장된 파이썬에 영향을 주며, 프로젝트를 여러 개 관리할 경우 호환성 문제가 생긴다. 따라서 일반적으로는 Poetry, Pipenv와 같이 가상 환경을 격리시켜 주는 도구와 함께 사용하는 것이 좋다.
#!syntax sh
poetry add package

PyPI는 유료로 패키지를 구매하거나 프로젝트 코드를 볼 수 없도록 하는 기능을 전혀 지원하지 않는다. 이 부분은 오픈소스 생태계에서 아주 유리하게 작용했는데, 누군가 만들다 중단된 프로젝트를 포크(Fork)해서 프로젝트를 이어가거나 기존 코드를 들여다보고서 그 패키지에 대한 확장 기능을 어렵지 않게 개발할 수 있었기 때문이다.

6.2.2. Anaconda

사설 패키지 저장소 겸 가상 환경 관리 프로그램으로, 공학/과학 응용 분야에서 매우 널리 사용되며 일반 사용자에게는 무료이다. 200인 이상 기업에게는 유료이다. [28] conda라는 명령줄 프로그램을 제공하며, 이는 별도의 가상 환경 생성 및 관리 기능을 가지고 있고 같은 명령어로 해당 가상 환경에 패키지를 설치할 수 있다. 파이썬 패키지만 지원하는 PyPI와 달리 blas, cuda, boost 등의 패키지 또한 등록되어 있어 anaconda에서 관리하는 가상 환경에 설치할 수 있다.

편리하고 공식적인 PyPI를 사용하지 왜 굳이 이런 사설 패키지 저장소를 사용하냐고 궁금해할 수도 있는데, 이는 의존성(dependency) 관리 때문이다. PyPI는 의존성 충족 여부를 단순히 패키지별로 확인하며, 두 패키지의 의존성이 충돌되는 경우를 막아주지 않는다. 그러나 conda의 경우 의존성 트리를 철저하게 확인하여 그러한 의존성 모순이 없도록 강제한다. 따라서 의존성 관계가 복잡한 경우 conda를 사용하여 관리하는 것이 편리하다.

또한 상술한 바와 같이 파이썬 패키지 외의 다른 언어로 작성된 패키지도 설치가 가능하며[29], 이들 또한 위의 의존성 관리에 포함된다. 따라서 시스템에 설치되어 있는 패키지의 버전이 설치하고자 하는 라이브러리와 호환되지 않거나, 보안상의 이유로 시스템에 패키지를 추가 설치하기 어려운 경우 사용할 수 있다.[30] 이와 같은 이유로 의존성이 복잡한 몇몇 패키지들은 anaconda를 사용하여 설치하는 것을 권장하는 경우가 있다.

수학/과학/공학 업무에 필요한 NumPy, SciPy, Jupyter Notebook 등의 수백 개의 패키지와 도구를 한 번에 깔아줄 뿐만 아니라 GUI도 제공하는 Anaconda와, 코어 기능인 패키지 매니저 및 가상 환경 관리자만을 제공하는 Miniconda가 있다. 다만 Anaconda는 설치에 시간이 오래 걸리고, 어차피 몇백 개나 되는 패키지를 다 쓸 일은 잘 없기 때문에 conda 사용에 숙련되면 Miniconda를 쓰는 것도 좋다. Miniconda는 패키지를 자신이 직접 찾아서 깔아야 하지만, 어차피 필요한 패키지를 설치하는 것은 install <패키지명> 몇 번만 두드려 보면 간단히 해결된다.
#!syntax sh
conda install package

각종 파이썬 라이브러리를 설치하고 관리하는 도구이다. 몇몇 파이썬 라이브러리는 리눅스의 패키지 관리자로도 설치할 수 있지만, 이는 시스템의 파이썬을 건드리므로 일반적으로는 권장되지 않는다. 쓸데없는 라이브러리들이 함께 설치되거나 패키지 의존 관계가 꼬이는 것을 막으려면 하나의 패키지 관리자만 이용하는 것이 좋다. 단, conda에는 등록되지 않아서 PyPI으로만 설치할 수 있는 패키지는 어쩔 수 없이 PyPI을 사용해야 한다. 그리고 PyPI로 설치할 수 없는 시스템 의존성(dependency)이 있으면 conda로 설치해야 한다.

리눅스와 같이 자체적으로 파이썬을 탑재한 운영 체제에서는 호환성 문제를 특히 신경 써야 한다. 시스템에 내장된 핵심 도구들이 기본적으로 설치된 파이썬 라이브러리를 사용하기 때문이다. 만약 패키지를 설치하다가 호환성 문제가 생기면 최악의 경우 OS를 재설치해야 할 수 있다. 따라서 이런 OS에서는 시스템 내장 파이썬에 패키지를 설치하면 안 되며, 대신 아래와 같은 명령어로 사용자별 기본 환경에 설치하거나 별도의 가상 환경을 만들어야 한다.
pip install --user

6.3. 가상 환경

한 컴퓨터 내에서 여러가지 프로젝트를 작업할 때, 필요한 버전이 다른 경우 프로젝트가 꼬일 가능성이 있는데, 이런 때를 위해 필요한 것이 바로 가상 환경이다. 가상 환경 디렉토리 이름은 사용자 마음대로 정할 수 있지만, .venv로 작명하는 것이 일반적이다.

VSCode 같은 일부 IDE에서는 가상 환경이 감지될 경우 폴더 내의 해당 가상 환경을 자동으로 잡아서 실행해 준다.
virtualenv my-venv
# 특정 파이썬 버전으로 된 환경을 구성하려는 경우에는...
virtualenv my-venv --python=<특정 버전>
}}} conda create --name my-venv
# 특정 파이썬 버전으로 된 환경을 구성하려는 경우에는...
conda create name my-venv python=<특정 버전>
}}}

7. 주요 패키지

패키지 중에서는 NumPy나 Pandas와 같이 파이썬과는 약간 다른 방식으로 코드를 운용해야 하는 경우가 있다. 파이썬을 접하고 배우다가 이런 패키지들을 처음 활용하게 될 때에는 살짝 어색하거나 어려울 수 있지만 계속해서 사용하다 보면 곧 익숙해질 수 있다.

7.1. 코드 퀄리티 관리

한 줄의 길이나 문자열을 감싸는 따옴표(""/'') 등 사람마다 스타일이 다를 수 있는 부분은 많다. 따라서 코딩 스타일을 통일하는 도구를 사용하면 여러 사람이 협업하면서 생기는 코드의 가독성이나 일관성 문제를 개선할 수 있다.

포매터는 짜여진 코드를 가독성이나 일관성에 합치되도록 수정해 주는 도구이다.

린터는 스타일 기준에 맞지 않는 스타일이나 바람직하지 않은 코드를 잡아낼 수 있는 편리한 기능을 제공하는 도구이다.

정적 타입 검사기는 동적 언어라서 변수의 자료형을 따로 체크하지 않는 파이썬을 위해, 코드를 직접 분석하여 변수를 올바른 용도로 사용하는지, 특정 함수에 올바른 값을 전달하는지와 같은 정보를 검사한다. 코드를 모두 분석한 후 컴파일하는 TypeScript와 달리 파이썬은 type hint가 있지만 정적 타입 검사에 실패하더라도 코드 실행은 된다

이 중 유명한 패키지들은 설치하고 나면 Visual Studio Code나 PyCharm과 같은 편집기에서 아예 에디터와의 연동을 통해 눈으로 코드의 상황을 볼 수 있도록 표시해 주는 기능을 사용할 수 있다.

7.2. 확장 모듈

영어로는 Extension Module이라고 한다. 확장 모듈은 C언어를 통해 파이썬의 실행 속도를 극적으로 향상시킬 수 있는 방법을 제공해 준다. CPython API (Python.h)를 통해 C로 작성되므로 CPython 구현체에 의존하는데, CPython은 C로 작성된 확장 모듈을 통해 파이썬에 내장된 함수나 객체처럼 사용할 수 있는 기능을 제공하기 때문이다. 구체적인 방법은 공식 문서에 나와 있다.

확장 모듈을 직접 작성하기 위해서는 C언어와 CPython API에 대한 상당한 지식이 요구된다. 그 예시가 궁굼하다면 numpy의 다차원 배열 소스 코드를 참고하자. 확장 모듈을 더 편하게 작성하기 위해서 아래에 서술된 패키지들을 사용할 수 있다.

다만 단순히 C로 작성된 라이브러리를 사용하는 것이 목적이라면 PyPy에서도 사용이 가능하고 호환성이 좋은 FFI를 사용하는 것이 더 바람직하다.

7.3. 외부 함수 인터페이스(FFI)

파이썬에서 C 언어와 같은 다른 언어로 작성된 함수를 호출할 수 있도록 한다. 영어로는 FFI(Foreign function interface)다.

하는 일은 CPython의 확장 모듈과 비슷하지만 완전히 다른 개념으로 몇 가지의 차이점들이 존재한다.
FFI를 이용하여 C 함수를 그대로 노출하는 것은 프로그램을 매우 난잡하게 만들 수 있으므로 C 타입으로 형 변환을 수행하는 Wrapper function이나 C의 포인터를 가지고 있는 Wrapper class를 작성하여 Pythonic한 코드를 작성하는 것이 중요하다.

아래는 FFI 라이브러리이다.

7.4. 기타

8. 문법

파일:상세 내용 아이콘.svg   자세한 내용은 Python/문법 문서
번 문단을
부분을
참고하십시오.

9. 설치

2024년 기준 데비안 계열(우분투 등)의 경우에는 터미널에서 아래와 같이 입력하면 파이썬을 설치할 수 있다. 그런데 대부분의 리눅스 배포판에서는 파이썬이 기본 설치 되어 있다.
sudo apt-get install python3

10. 코드 스타일

파이썬은 PEP 8[33]을 바탕으로 하는 통일적인 스타일 가이드라인을 제시하고 있어 대부분의 프로젝트에서 일관적인 스타일을 볼 수 있다.

파이썬에서는 작명 규칙이 실제 기능에 영향을 미치지는 않지만 PEP 8에 따른 작명 규칙을 지킴으로써 다른 사용자와 코드를 공유하거나 자신이 나중에 코드를 볼 때 동작을 헷갈리지 않도록 돕는 작명 규칙이 있다. 전체적으로 클래스[34]는 파스칼 케이스(PascalCase), 나머지 경우[35]에는 스네이크 케이스를, 상수에는 스크리밍 스네이크 케이스(SCREAMING_SNAKE_CASE)를 사용한다.

또한 파이썬은 내부 속성(private attribute)이라는 개념[36]이 없기 때문에 맨 앞에 밑줄(_)을 표기하는 경우 내부 변수로 간주하는 관례가 있다.

이 외에도 한 줄은 79글자 이하로 제한[37]하는 등 다양한 관례가 있다. 자세한 내용을 PEP 8를 참고하자.

작성한 코드가 PEP8 스타일 가이드를 지키는지 확인해 주는 Ruff, Pylint, Flake8, PyRight와 같은 패키지들과 자동으로 코드를 수정해 주는 Black, yapf와 같은 패키지들을 사용해 더욱 쉽게 파이썬의 권장 스타일을 지키며 파이썬 코드를 짤 수 있다.

11. 학습

파이썬은 인기 있는 주제이기에 관련된 공부 자료가 매우 많다. 이 부분에서 몇 가지 다양한 출처와 방법을 소개하고 있지만, 결국 자신에게 맞는 자료인지 직접 확인하는 것이 가장 중요하다.

11.1. 공식 튜토리얼

파이썬의 문서는 공식 튜토리얼 (영어) (한국어)을 제공하고 있다. 매우 자세하고 잘 쓰여 있으며 다운로드도 가능하기에 활용해 보는 것도 좋을 것이다.

11.2. 유튜브

11.3. 웹사이트

11.4. 도서

12. 몬티 파이썬의 패러디

역사에서 설명되었다시피 파이썬은 몬티 파이썬에서 이름을 따왔고, 파이썬 개발자들은 몬티 파이썬을 모르는 개발자들의 이해가 방해되지 않는 선에서 유쾌하게 관련 패러디를 사용한다.

CPython의 공식 GitHub 저장소를 보면 협업 보조용 봇 이름들이 the-knights-who-say-ni( 니라고 말하는 기사)나 bedevere( 베디비어)같이 몬티 파이튼의 성배의 배역들이다.

또한 일반적으로 임시로 사용하는 변수명에 foo와 bar를 사용하는 것과 달리 파이썬 커뮤니티나 교재에서는 spam, ham, eggs를 사용하는 경우가 있다. 이도 스팸(몬티 파이튼의 비행 서커스)에 나온 내용을 패러디한 것이다.

PyPI의 코드명인 Cheese Shop도 이와 관련이 있다.[38] 이 흔적은 PyPI의 404 페이지에서 스크롤을 내리면 나오는 숨겨진 이스터 에그에서 The Cheese Shop Sketch라는 이름의 유튜브 영상이 임베드되어 있는 것에서 찾을 수 있다.

파이썬에 기본으로 내장되어 있는 프로그램인 IDLE의 정식 약자는 Integrated Development and Learning Environment[39] IDE의 변형이지만, 실제로는 몬티 파이썬의 멤버인 Eric Idle의 이름을 딴 것이다.[40]

트위터에서 Eric Idle에게 Python의 이름의 유래를 알려주자 Idle은 "파이썬이 뭔지는 잘 이해하지 못하지만, 매우 고맙다고 생각한다. 참고로 스팸 메일의 유래가 어디서 나왔는지도 생각해 봅시다!"라고 트위터로 쓰자 귀도 반 로섬이 직접 리트윗을 하며 파이썬이 무엇인지 친절히 설명해 주면서 자신은 여전히 Idle의 팬이라고 답했다.[41]

13. 여담

14. 관련 문서

15. 외부 링크


[1] 새로운 버전을 매년 출시하고, 과거 버전에 대해서는 지원을 종료한다. [2] 원문에는 '네덜란드인이 아닌 이상'이라는 농담조의 조건이 붙는데, 아마도 파이썬의 창시자인 귀도 반 로섬을 두고 하는 얘기로 보인다. [3] PEP 584는 PEP 20과 직접적인 관련이 있는 것을 아니지만 새 문법에 대한 반대 여론에 대한 해명을 하며 관련된 이야기를 꺼냈다. [4] 예를 들어 정수 a, b에 대해 'a += b'와 'a = a + b'는 완전히 같은 코드이지만, '+='를 사용하는 'a += b'가 더 '명백한' 방법이니 이는 PEP 20에 위배되는 것이 아니라고 해석할 수 있다. [5] 파이썬에서는 금지하기보다는 작명 규칙이나 타입 힌트 등으로 사용자에게 규칙을 권장하는 경우가 많다. 작명 규칙(상수나 내부 attribute 등.), 타입 힌트가 대표적이다. [6] https://peps.python.org/pep-0001/ [7] 파이썬에서 이 만화와 관련된 재미있는 이스터 에그를 찾을 수 있다. 파이썬 터미널에서 import antigravity라고 치면 해당 만화의 링크를 웹 브라우저에서 연다. [8] 일반적인 프로그래밍 언어들은 정수의 크기를 32비트 혹은 64비트 등으로 제한을 하는 경우가 많은데, 파이썬의 경우에는 메모리가 버텨주는 한 무한한 크기의 정수를 만들 수 있다. [9] 외국어 중 영어와 같은 케이스라고 생각하면 된다. 아랍어, 러시아어 같은 언어는 어느 정도만 할 줄 알아도 대우를 받는 반면, 영어는 누구나 배우는 언어이기에 웬만큼 잘해서는 경쟁력조차 없다. [10] 여기서 말하는 교양이란 회귀 분석이나 최소 제곱법, 기계학습 등의 통계적 방법에 대한 이해, 그리고 수학 쪽으로는 행렬 집합, 선형 대수학 등에 대한 간단한 개념만 있으면 된다. 공부해 본 사람들은 알겠지만 이것들은 심화가 아니라 기본 중의 기본이다. [11] 이는 JavaScript도 같은 문제점을 공유한다. [12] 당연히 실무에서 리스트나 이진 트리를 하나하나 직접 구현할 일은 없으나 그 원리를 이해하는 상태에서 개발하는 것은 전혀 별개의 문제다. 가령 스레드가 꼬여 에러가 났을 때, 스레드가 무엇이고 내부적으로 어떻게 처리되는지를 이해하는 사람이라면 어디서 에러가 나는지 바로 유추하고 대응이 가능하지만, 이런 배경 없이 메소드만 쓸 줄 아는 사람은 에러 메세지를 읽는 것부터 난관이다. [13] 특히 비 개발자 대상으로 [14] 같은 인터프리터 언어인 Java나 C# 도 JRE,.NET 런타임이 미리 깔려야 하는 문제가 있지만 Java의 경우에는 오라클 측에서 배포하는 표준화된 JRE 하나만 깔아도 대부분의 자바 프로그램이 동작될 정도로 표준화되어 있으며 .NET은 MS가 OS를 깔 때 아예 같이 설치해 주기 때문에 유저는 설치 자체를 할 필요가 없는 경우가 많다. [15] 기본적으로 'Python을 설치하고 개발 환경을 구성한 사람이' '자기 컴퓨터나 자기가 관리하는 시스템 속에서 돌릴 프로그램을' '직접 만들어 쓰는' 것을 최대의 목적으로 발달해 왔기 때문에 [16] 'Visual C++ 20xx Redistributable'(vc_redist.exe) 등이 첨부된다 [17] Java Runtime Environment. 자바 런타임 환경 [18] 이마저도 JDK, JRE 등의 복잡한 구분 없이 그냥 Java를 설치한다고만 안내하는 등 설치를 까다롭거나 위협적으로 느끼기는커녕 지금 설치하는 게 정확히 JRE라는 점조차 몰라도 되도록 배려하고 있다. [19] 이 때문에 많은 사람들이 눈치채지 못하는 부가 효과가 있는데, 바로 이 윈도우 내장 .Net은 동시에 프로그램 개발 환경으로도 쓰일 수 있다는 점이다. 프레임워크가 깔릴때 SDK도 같이 깔리기 때문에 터미널로 SDK를 불러와 프로젝트 생성과 프로젝트 빌드까지 가능하다. [20] Java가 jlink라는 표준화된 방식을 제공하는 것과 대조적이다. [21] https://realpython.com/python-gil/ [22] https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474 [23] https://www.python.org/downloads/release/python-3130/ [24] https://x.com/pyblogsal/status/1843329493118964009 [25] read-evaluation-print loop라는 의미로, 코드를 치면 바로 값이 프린트되어 나오고 이것이 반복되는 환경을 의미한다. [26] Python 확장 설치 시 파이썬에 대한 IDE로 사용할 수 있다. [27] setuptools나 설치에 필요한 다른 기능. 또한 C/C++ 코드를 사용하는 경우에는 해당 시스템에 C/C++ 컴파일러도 설치되어 있어야 한다. [28] 2020년부터 정부 및 200인 이상 기업에게는 유료로 바뀌었다. [29] libjpg, bzip 등 시스템에서 자주 사용되는 패키지 다수가 포함됨 [30] 물론 필요에 따라 직접 빌드해서 설치하면 당연히 사용할 수 있지만, 매우 귀찮고 번거로우며 기술적 지식을 요구하므로.... [31] 심지어 C++도 사용할 수 있다. [32] 단지 헤더 파일을 복붙하는 것으로 작동한다. [33] PEP 8이 유일한 스타일 가이드라인은 아니다. 대표적인 다른 가이드라인으로는 구글 파이썬 스타일 가이드라인이 있다. 하지만 내용은 PEP 8과 대동소이하다. 사람마다 가장 차이가 심한 스타일로는 docstring 스타일이다. 주요 골자는 PEP 257에서 정의되고 있지만, 세부적인 방법은 sphinx, 구글 스타일 가이드라인 등 다양하다. [34] 예외나 경고를 포함한다. [35] 변수명, 함수명, 일부 내장 타입, 파일명, 패키지명 등. [36] 대신 맹글링(mangling)은 지원한다. 맨 앞에 밑줄이 두 개이고 매직 메소드가 아닌 경우 맹글링이 된다. [37] 구글 스타일 가이드는 80자로 제한하고, black는 88자가 기본값이다. [38] 출처 [39] 혹은 Integrated DeveLopment Environment # [40] https://stackoverflow.com/a/21581930 [41] https://x.com/gvanrossum/status/1355310333875773444 [42] 강남 코엑스에서 13~14일 아카마이에서 15일(튜토리얼). [43] CVE-2007-4559

분류