Python의 특징과 장단점

그간 Python을 쓰면서 느낀 점들을 정리해본 글이다.

당연하지만 주요 구현체인 CPython이 기준이 될 것이다.

기본 특성

Python은 인터프리터 위에서 동작하는 스크립트 언어다.
인터프리터 언어답게 동적 타이핑을 지원하며, 낮은 성능으로 유명하다.

많이 쓰이는만큼 많은 사람들에게 여러모로 애증의 존재이기도 하다.

평생의 라이벌로는 Ruby가 있다. 거의 모든 장점과 단점을 공유하는 대적자다.

장점

매우 방대한 라이브러리 환경

파이썬만큼 넓은 영역에 대한 라이브러리들을 잘 제공하는 언어는 드물다.
무언가를 구현해야한다면, 높은 확률로 파이썬에는 그걸 위한 라이브러리/프레임워크 환경이 풍부하게 존재한다.
특히 "돈이 되는" 영역에 대해서는 더 그렇다.

물론 그렇다고 그것들이 "좋은 라이브러리"냐 하면, 그건 아니다. 질적인 수준은 다른 언어보다 떨어질 수 있다.

학습 난이도가 낮다

파이썬은 간결한 문법과 단순한 제약사항으로 가드레일이 낮은 언어에 속한다.
그래서 흔히 입문자용 언어로 취급되며, 요즘은 전공 학부에서도 그렇게 다룬다.

생산성이 높다

파이썬은 빠르게 코드를 쳐내기 좋은 언어에 속한다.
개발자를 귀찮게 하는 타입도 (엄밀하게는) 없으며, 실행 전에 귀찮은 검증 과정을 거치지 않고 일단은 실행되게 해주는 언어이기 때문이다.

이건 단점과도 바로 연결되는데 "그냥 코드"를 빠르게 치기 좋은거지, "좋은 코드"를 만들기 좋은 언어는 절대 아니란 것이다. 상세한 것은 후술한다.

단점

최적화 수준이 낮은 언어

Python은 객관적으로 느린 언어가 맞다. 일반적인 연산 성능의 고점이 정상적인 언어에 비해 수십배는 떨어진다.
명령어가 머신코드로 바로 해석되는 것이 아니라 인터프리터를 거쳐 실행되기 때문에, 근본적으로 성능 한계가 존재한다. 요즘에는 최적화한다고 JIT도 만들어서 넣어보고 있는데, 지지부진하다.

애초에 파이썬은 처음부터 진지하게 만든 언어가 아니었으며, 진지하게 성능/아키텍쳐에 대한 고민을 시작한 것도 최근 얼마 전부터 시작한 일이다.
요즘에는 느린 성능을 개선해보겠다고 계속 최적화를 열심히 시도해보고 있는데, 관련 벤치마크 결과들을 보면 오픈소스 팀의 최적화 역량도 썩 좋지 못한 것 같다. 특히 Java 같은 잘난 후배들과 비교하면 더욱...

그래서 파이썬을 쓸 때도 진짜 성능이 필요한 영역에 대해서는 C/C++/Rust로 만들어진 라이브러리를 가져다 쓰는 것이 일반적인 사용 방법이다.
이미지 처리, 영상처리, 머신서닝, 데이터 집계 등의 고성능이 필요한 부분들은 100% 다른 언어로 만들어진 모듈을 쓴다. 이럴 때의 파이썬은 껍데기밖에 없다.

지저분하고 불편한 종속성 관리

파이썬은 기본 패키지 매니저(pip)의 기능 수준이 최악이다.
진짜 아무 생각없이 만들어놔서 버전관리가 개판이며, 속도도 말도 안될 정도로 느리고, 종속성을 설치하는 방식 자체도 매우 끔찍했다.
요즘에는 uv라는 백마 탄 초인이 나타나서 그나마 좀 나아진 상황이다.

그리고 패키지 매니저와 별개로, 오픈소스 레지스트리(Pypi)에 오픈소스 모듈을 게시하는 것 자체도 지저분하고 불편하게 되어있다. 오픈소스 게시가 활발한 npm/go/rust 등과 비교하면 매우 초라하다.

라이브러리의 수준이 낮음

라이브러리 자체는 꽤 많고 뭐가 다양한데, 라이브러리들의 품질은 조악한게 많다.

• 크로스플랫폼 지원이 열악하거나 불완전한 라이브러리가 적지 않고

• 비이성적일 정도로 성능이 떨어지기도 하고

• 프로젝트 자체의 호환성 관리 수준도 좋지 않다

나는 이게 약간 Python 사용자나 모듈시스템 특성이 반영된 결과물이라고 본다.
Python은 라이브러리 사용자는 많은 반면 라이브러리를 구현하는 기여자의 비율이 기형적으로 적은 편이다. npm/go/rust 환경에서 기여자와 사용자가 모두 많은 것과 대조된다.

게다가 모듈을 배포하는 것 자체도 불편하게 되어있는 편이다보니, 그런 면이 더 부각되는 것 같기도 하다.
npm 다루다가 Pypi에 모듈 올리려고 보면 눈이 썩을거같다.

동시성 지원 수준이 낮다 (개선중)

파이썬은 멀티스레드를 제대로 지원하지 않는 언어였다. 최근 들어서 스레드를 넣는 모험을 시도하고 있지만, 아직 안정화 단계는 아니다.
프로덕션에서는 아직 쓰지 못할 수준이므로, 여기에서는 스레드 미지원 상태를 기준으로 설명하겠다.

아무튼 멀티스레드가 안정화되기 전까지는 병렬처리를 하기 위해서 멀티프로세스를 사용해야만 한다.
프로그램 내에서 스레드를 여러개 돌리는 것이 아니라, 독립적인 파이썬 프로세스를 여러개 실행하는 형태로 말이다.

이 방식에는 단점이 많다. 단일 프로그램의 멀티스레드만큼 성능이나 리소스 효율성이 좋지 못하기 때문이다.
프로세스가 각각 모듈이나 독립적인 컨텍스트를 갖고 있어서 리소스 낭비가 심하다.

언어의 호환성 수준이 낮다

파이썬 메인테이너들은 호환성에 대한 인식 수준이 예전부터 낮았던 것 같다.

Python 2 => 3 격변을 제하더라도, 마이너 업데이트들을 보면 본인들이 사소하다고 생각하는 부분은 그냥 하위호환성 무시하고 막 지르는 것들이 많이 보인다. 가장 최근 업데이트 내역만 봐도 그렇다.

그래서 실제로 파이썬 모듈들은 버전 올리면 어이없게 깨지는 경우가 종종 연출된다.

타입이 없다

파이썬에는 제대로 된 타입이 없는 동적 타입 언어다.
이건 제약을 줄여서 코드를 생각없이 빠르게 짜기 좋게 해주지만, 그만큼 코드의 저점을 끝없이 낮추는 요인이 되기도 한다. 사방이 잠재적인 지뢰받이 된다.

근래에 문법에 타입 힌트 기능이 추가되기는 했지만, 타입 체크가 아니고 자동완성을 위한 도구로만 기능한다. 게다가 이마저도 안쓰는 경우가 허다하다.
파이썬에서 진짜 타입 체크를 하려면 별도의 서드파티 도구를 사용해야 한다.

낮은 가독성과 코드 작성 문화

파이썬의 가독성은... 여러모로 한숨을 쉬게 한다.
언어 자체의 문법 설계부터 언어 사용자에 이르는 총제적 난국이다.

Python은 여러모로 나사빠진 언어 수준 설계를 갖고 있었다. 한가지 목표를 이루는데 한가지 방법만 있으면 된다는 자기들만의 철학이 있었기 때문이다. 물론 요즘에는 이 원칙도 던지고 하고싶은대로 하긴 하던데...

구문 판별 조간이 들여쓰기라서 코드의 영역이 명확하게 잘 구분되지 않고, 다중 분기문 같은 기본적인 sugar 구문도 얼마 전까지는 없었다. 삼항연산자나 list comprehension 같은 문법에는 자연어 문법요소를 애매하게 섞어놔서 다른 언어들과 크게 괴리된다.

문법도 느슨한데다, 사용자들의 느슨한 마인드까지 섞여서 파이썬의 코드는 매우 "Pythonic"하게 만들어질 확률이 매우 높다. 나름 이름 있는 오픈소스를 까봐도 한숨만 나오는 경우가 많다.
PHP보다는 낫긴 한데, 내가 봤을때는 고만고만하다.

Python의 적절한 사용처

머신 러닝, AI 분야

• AI 분야는 모든 개발 환경, 에코시스템이 파이썬으로 되어있기 때문에 파이썬을 써야만 하는 드문 경우다.

물론 AI에서도 Python 100%를 쓰는 경우는 존재하지 않고, 성능이 필요한 부분은 전부 코어 구현이 C/C++이다. 여기서 파이썬이 해주는 역할은 이걸 좀 편하고 쉽게 돌리게 해주는 것이다.

• 대표적으로 Tensorflow, Pytorch 등의 핵심 AI 프레임워크들이 파이썬을 기본 인터페이스로 제공한다.

크로스플랫폼 스크립트

• 시스템을 운영하다보면, 설치 스크립트라든지, 시스템 세팅이라든지 하는 작업에 대한 스크립트 코드를 작성해야하는 경우가 드물게 않게 생긴다.

근데 문제는, bash 등의 스크립트는 특정 OS/터미널 환경에 종속적이라 이식성이 없다는 것이다. 게다가 코드를 작성하기 편하지도 않다.

• 파이썬은 이런 부분에 꽤 잘 맞는 언어다. 어차피 이런 쪽은 성능이 그닥 중요하지 않고, 빠르게 짤 수 있는 것이 더 중요하기 때문이다.

애매한 사용처

API 서버

• 근래에는 django, FastAPI 등을 써서 서버를 띄워 쓰는 경우가 드물지 않게 보인다.

• 근데 내가 봤을 때는 유지보수성도 끔찍하고 성능 리스크도 명확해서 별로 추천하고 싶은 조합은 아니다.

• 특히 취약한 부분은 병렬처리와 비정상적인 수준의 메모리 사용량이다. 현 시점에서 서버를 병렬처리하려면 멀티프로세스로 서버를 띄워야 하는데, 그러면 개별 프로세스가 모듈을 각각 로드해서 메모리 사용량도 상당히 뻥튀기된다. 이러면 메모리를 200MB 먹는 모듈만 하나 추가해도 프로세스가 5개면 1GB나 쳐먹는 것이다. 파이썬에는 저렇게 뚱뚱하고 못생긴 라이브러리가 실제로 꽤 많다...

데이터 분석

• 대형 데이터를 분석할 때는 pandas 같은걸 쓰는 경우가 많은데, 난 이거 당위성을 잘 모르겠더라.

pandas는 막상 써보면 별로 빠르지도 않다. 빨랐다면 pandas가 빠른게 아니라 고성능 서버에 띄워서 돌리니까 빠른거다. 다른 정상적인 언어나 환경에서 돌리면 그거보다 빠르다.

• 이건 그냥 파이썬이 익숙해서 있는걸로 쓰는거지, 그렇게 이성적인 이유가 있어 보이지는 않았다.

차라리 요즘은 DuckDB나 clickhouse 같은게 더 괜찮아보이더라.

데스크톱 GUI 프로그램

• GUI는 파이썬에 쓸만한 프레임워크들이 좀 있긴 한데, 다른 것들을 제치고 쓸 정도인지는 좀 애매하다. Qt Python이 꽤 쓸만하긴 하지만, 대체재가 너무 많다.

• 요즘은 웹뷰 기반 프레임워크들이 너무 강력해서 파이썬은 그렇게 선호되지는 않는 것 같다.

적절하지 못한 경우

파이썬은 높은 성능/적은 메모리 사용량이 필요하거나, 하드웨어 한계 등이 존재하는 시스템에서는 사용이 불가능하다고 보면 된다. 혹은 그냥 파이썬 환경이 부실한 분야도 있다.
다음과 같은 분야들은 그런 이유에서 파이썬이 접근할 수 없는 금단의 영역에 속한다.

데이터베이스, OS 등의 기반시스템

• 데이터베이스와 OS 등의 시스템은 적은 리소스 사용량, 빠른 성능이 필수적이다. 파이썬으로는 최적화에 한계가 존재한다.

• 이런 기반시스템은 저수준 제어가 필요해지는 경우가 많다. 파이썬으로는 이런 것을 행하기 어렵다.

임베디드 시스템

• 대부분의 임베디드 시스템은 단가 문제로 하드웨어 한계가 명확한 환경에서 구동된다. 메모리가 KB 단위고 실행파일 크기에도 제약이 존재하는 경우가 빈번한데, 파이썬은 어림도 없다.

• 임베디드 분야 중에서도 하드웨어 성능이 충분한 경우에는 드물게 파이썬이 쓰이긴 한다. 로봇 같은 분야가 여기에 속한다. 이런건 기본 단가가 높아서 그런지 성능 좋은 컴퓨터를 곧잘 내장하는 것 같더라.

모바일 애플리케이션

• 모바일앱을 개발하는 부분에는 못써먹는다. 마땅한 환경이 없다.

• 억지로 하려면 할 수는 있는데, 그냥 다트나 JS 쓰는게 낫다.

웹 프론트엔드 애플리케이션

• 웹 프론트용 프레임워크도 파이썬에 딱히 완성도 있는 물건이 없다.

• 이건 그냥 JS 쪽 환경 쓰는게 맞다.