파이썬은 데이터 사이언스에 적합한 언어가 아니다

• 데이터 분석·시각화·요약 같은 비-딥러닝 데이터 작업에서 Python은 기능은 충분하지만 사용 경험이 복잡하고 비효율적으로 흐르기 쉬움
• 연구실 사례 전반에서 R보다 Python이 단순한 그래프 변환·통계 계산에도 더 많은 코드와 시간을 요구하는 경향이 반복적으로 확인됨
• pandas·matplotlib·NumPy 등을 쓰더라도 문법·인덱싱·괄호·메서드 체인 구조 때문에 로직보다 구현 세부(Logistics) 에 사로잡히는 경우가 잦음
• 반대로 R의 tidyverse는 데이터 처리 흐름을 자연어 수준으로 표현해 작업 로직을 그대로 코드로 옮기기 쉬움
• Python은 데이터 과학 언어로서 논리와 로지스틱스 분리에 구조적 한계가 있으며, 이는 언어·생태계 설계에 기인한 문제

---

Python과 R의 실제 사용 경험 비교

• 연구실 구성원들은 언어를 자유롭게 선택하지만 Python 사용자가 많고, 이들이 간단한 추가 분석 요청을 빠르게 처리하지 못하는 패턴이 일관되게 나타남
  • 박스플롯→바이올린플롯, 히스토그램→밀도그래프, 선그래프→히트맵 같은 시각화 전환도 즉시 수행이 어려움
  • R에서는 몇 줄로 끝나는 작업이 Python에서는 “자리로 돌아가서 다시 코딩해야 할” 정도의 부담으로 느껴짐
• Python 전문가와 공동 수업을 진행할 때도 필요한 코드 길이와 복잡도에서 R과 큰 차이가 드러남
  • “왜 이렇게까지 복잡해야 하지?”라는 반응이 여러 상황에서 반복적으로 나타나며, 이는 개인 실력이 아닌 언어·라이브러리 아키텍처상의 구조적 차이로 보임
  • 동일 로직이라도 Python에서는 인덱싱·데이터 분리·재조립·여러 메서드 결합이 필요해 구조가 장황해짐
  • R tidyverse는 filter → group_by → summarize 같은 자연스러운 체인으로 직접적 표현이 가능함

Python이 널리 쓰이는 이유와 그 한계

• Python의 데이터 과학 지위는 고유한 적합성보다는 역사적 확산·범용성·생태계 크기에 기반함
  • 딥러닝 분야는 PyTorch·AI 생태계 덕분에 확실히 Python 중심
  • 그러나 데이터 정제·탐색·시각화·통계 모델링에서는 여전히 불편함이 많음
• “역사적 사고(historical accident)에 가까운 인기”이며, R 대비 언어 구조의 무거움이 여러 예시를 통해 반복적으로 드러남

좋은 데이터 과학 언어의 조건

• 데이터 탐색·요약·모델 적합·시각화 중심의 작업에는 상호작용 환경, 낮은 설정 비용, 빠른 반복이 가장 중요함
  • 컴파일 언어보다 스크립트형 인터프리터 언어가 적합
  • 성능보다는 코드 단순성·오류 위험 감소·사고 부담 최소화가 우선
  • 필요하다면 전체가 아니라 일부 연산만 고성능 언어(Rust 등)로 재작성하면 충분함
• 현실적으로 고려할 수 있는 언어는 R과 Python
  • Matlab, Mathematica 등은 상용이거나 생태계가 제한적
  • Julia는 종종 언급되지만, 저자는 충분히 다뤄보지 않아 평가를 유보함

“논리 vs 로지스틱스” 문제

• 데이터 분석 언어는 무엇을 계산할지(논리) 와 어떻게 계산할지(로지스틱스) 를 분리해야 함
  • 데이터 타입·인덱스·루프·수동 조립을 신경 써야 한다면 이미 로지스틱스에 얽매인 상태
• Palmer Penguins 예제에서 R의 tidyverse는 자연어에 가까운 흐름으로 평균·표준편차 계산을 표현
  • 데이터 흐름을 해체했다 다시 조립하는 과정이 필요 없음
• pandas는 유사한 기능을 제공하지만 문자열 지정·괄호·메서드 체인·reset_index 등 부수 작업이 많아 가독성과 단순함이 떨어짐
• 순수 Python만으로 동일 작업을 구현할 경우
  • 루프 구성 → 그룹 키 생성 → 분할 → 평균 계산 → 분산 계산 → 표준편차 계산 → 재조립 → 정렬 등
  • 전부 수동으로 처리해야 하며 로지스틱스 코드가 로직을 압도하는 전형적 사례가 됨

결론 및 이후 내용 예고

• Python은 데이터 분석에서 로직보다 구현 세부에 집중하게 만드는 구조적 문제를 반복적으로 드러냄
  • 이는 언어 자체의 특성·라이브러리 설계 한계·생태계 전반의 관습이 결합된 결과로 보임
• 후속 글에서는 Python이 R보다 데이터 분석을 어렵게 만드는 구체적 기술적 원인을 다룰 예정

추가 논의·비교 관점(독자 피드백 포함)

• tidyverse는 기본 R보다 장황할 수 있으나 표현력·일관성·데이터 처리 추상화 면에서 강력하다는 의견도 있음
• 반면 R은 모듈화·테스트·CLI 구현 등 소프트웨어 개발 측면에서 불편함이 크다는 반론도 제시됨
• Python은 로깅·가상환경·패키징·클래스 구조 등 개발자 경험이 우수하나,
  • matplotlib는 비직관적 설계,
  • pandas는 비일관적 문법,
  • scikit-learn은 설계상의 문제가 자주 거론됨
• 일부 의견에서는 Python을 “불안정하고 품질 낮은 코드를 빠르게 양산하는 언어”로 보며,
  지속 가능한 개발에는 정적 타입 언어가 낫다고 언급

[kaydash]

데이터 복잡도와 양이 증가하여 단계별 분할처리가 필요하면서 비정형데이터와 정형모델,LLM을 통한 가공까지 필요하다면 use case가 많기도하니 가장적합한 언어가아닐까.

[GN⁺]

Hacker News 의견

• boxplot을 violin plot으로 바꾸거나, line plot을 heatmap으로 바꾸는 등 다양한 변환 예시를 들었음
  이런 논의는 사실 Python보다는 matplotlib에 관한 이야기임
  ggplot의 디자인을 Python에서 원한다면 plotnine을 쓰면 됨
  R 코드가 더 간결해 보이는 이유는 R의 비표준 평가(non-standard evaluation) 덕분임
  Python은 언어 차원에서 이런 확장을 허용하지 않음
  관련 내용은 Computing on the language 참고

  • 결국 이건 Python 대 R의 차이 이야기임
    비표준 평가가 대화형 환경에서는 편리하지만, 복잡한 분석 코드를 작성할 때는 오히려 단점이 됨
    단순한 작업도 돌아서 해야 하는 경우가 생김
  • R 코드에서 파이프를 문장 끝에 두는 건 보기 힘듦
    Elixir처럼 앞쪽에 파이프 연산자를 두는 게 더 낫다고 생각함
    Python도 getattr 같은 트릭으로 비슷한 문법을 흉내낼 수 있지만, 결국 이건 언어보다는 라이브러리 API 설계 문제임
  • “라이브러리 없이 로지스틱 작업을 R로 한다면?” 상상만 해도 끔찍함
    R은 라이브러리와 레시피가 있을 때만 쉬움, 없으면 정말 어렵고, 대부분은 그냥 안 함
  • 이런 목적이라면 seaborn이 적합함
    matplotlib의 불편함을 추상화하면서도 풍부한 기능을 제공함
    Seaborn 튜토리얼
  • 결국 핵심은 Python이 아니라, R이 할 수 있고 Python이 못 하는 걸 이야기하는 것 같음

• 왜 프로그래밍 언어에서 테이블이 일급 객체가 아닌지 의문임
  대부분의 언어는 테이블을 다루기 위해 pandas나 polars 같은 별도 API를 배워야 함
  R은 data.frame이 일급 객체에 가깝지만, 실제로는 dplyr의 tibble을 더 많이 씀
  아직 표 데이터를 다루는 표현 언어가 표준화되지 않았음
  Polars와 dplyr이 비슷한 철학을 공유하지만, 결국 SQL이 유일한 공통 기반처럼 보임
  Python도 완벽하지 않지만 R도 마찬가지라고 생각함

  • 언어 차원에서 빠진 구조가 많다고 느낌
    테이블, 행렬, 그래프, 상태 머신 같은 구조가 언어 수준에서 지원되지 않아 활용이 제한됨
    언어에 기본으로 포함된 도구가 그 언어의 “예쁜 길”을 결정함
    예전엔 key-value store도 외부 라이브러리였지만, 지금은 표준처럼 됨
  • Q, Rye, Lil 같은 언어는 테이블을 진짜 일급 데이터 타입으로 다룸
    언젠가는 주류 언어들도 이런 표 기반 프로그래밍을 흡수할 것이라 예상함
    Q 언어, Rye 비교 글, Lil 실험 도구
  • tibble과 data.table은 data.frame을 상속하므로, R의 기본 함수들이 그대로 작동함
    세 객체 간 변환도 매우 간단함
  • 테이블 크기가 1백만, 10억, 1조 행으로 커질수록 문제의 성격이 완전히 달라짐
    이런 규모 차이를 우아하게 처리할 수 있는 표준 API를 설계하는 건 쉽지 않음
  • R의 data.table은 훌륭함
    다만 dplyr이 문서화와 온보딩에서 승리해 산업계 채택을 얻었음

• 글의 요지는 괜찮지만, 저자가 주장 근거를 너무 빨리 공개한 게 아쉬움
  R은 데이터프레임 처리에는 강하지만, 파일 관리나 유지보수에는 약함
  이런 작업을 많이 하면 Python이 더 낫고, 속도까지 중요하면 Julia 쪽으로 기울게 됨
  각 언어는 우선순위에 따라 선택이 달라짐
  학생들이 pandas로 그래프 같은 비표형 문제를 해결하려는 걸 자주 보는데, 그럴 땐 도구 선택을 다시 생각해야 함

  • Python의 예시 코드가 부적절함
    numpy를 쓰면 평균과 분산 계산은 이미 내장되어 있음
    Python과 R 모두 학습 난이도는 비슷하지만, Python은 다른 애플리케이션과의 통합성이 강점임
  • 글의 두 번째 파트는 여기에서 볼 수 있음
  • 나도 Python과 R을 반반씩 씀
    대용량 파일을 처리할 땐 Python, 요약 데이터를 분석할 땐 R이 효율적임
    각 언어는 적재적소의 도구로 쓰는 게 맞음

• Python 프로그래머로서 R도 써봤는데, Python은 “모든 걸 꽤 잘하지만 완벽하진 않은 언어”임
  하루 종일 데이터 분석을 한다면 R을 배우는 게 맞음
  R은 통계학자의 사고방식에 맞춰 설계된 언어임
  처음엔 낯설지만, 그 사고 전환이 오히려 도움이 됨
  그래도 나는 대부분 Python에서 일함

• pandas로 데이터 과학을 하는 건 가능하지만 투박하고 복잡했음
  polars로 약간 나아졌지만, duckdb를 쓰면서 완전히 달라졌음
  SQL 쿼리를 직접 notebook에서 실행하고 parquet 파일로 분석함
  SQL 셀과 Python 셀을 섞어 쓰면 코드가 깔끔해짐
  글의 마지막 Python vs R 비교를 보며 “이건 SQL로 쓰면 훨씬 낫지 않나?”라는 생각이 들었음

  • 나는 SQL보다 데이터프레임 중심으로, 언어 안에서 끝내는 걸 선호함
  • 자주 polars를 쓰는데, duckdb도 한 번 써봐야겠음

• 마지막 Python 예시는 불필요하게 장황함
  defaultdict와 statistics.stddev를 쓰면 훨씬 간결해짐

  • Bessel 보정을 직접 넣은 건 흥미로움
    보정이 의미 있는지 고려하지 않고 구현하는 경우가 많음
    이건 사실 sample_std_dev라고 불러야 정확함
  • itertools.groupby도 쓸 수 있음
    코드가 짧진 않지만 의도를 명확히 표현할 수 있음
  • 원래 코드가 더 읽기 쉬움
    짧게 쓰려다 가독성을 희생하는 건 좋지 않음

• Julia의 TidierData.jl로 같은 예시를 구현해봤는데, R 버전과 거의 동일하게 나옴
  @chain, @group_by, @summarize 같은 매크로 문법이 R의 tidyverse와 유사함

• 글쓴이의 불만이 잘 이해되지 않음
  Python이 데이터 과학에 최적화되지 않았다는 건 당연한 사실임
  Python은 DSL이 아니고, MATLAB조차도 과학 계산용으로 설계됐지만 인기 없는 언어임
  좋은 언어는 완벽한 날씨보다 살기 좋은 도시 같은 것임
  Python은 “날씨는 별로지만 번성하는 북유럽 도시” 같음
  글 주제는 다소 클릭 유도형이라 생산적인 논의는 아니라고 생각함

• Julia가 더 많이 쓰였으면 좋겠음
  예전에 심리측정학 논문용 알고리즘을 Julia로 다시 구현했는데, MATLAB보다 세 배 빠르게 실행됐음
  관련 논문 링크

  • 그 40분의 실행 시간 절약이 논문 작성 전체 일정에 얼마나 중요했는지 궁금함

• 마지막 예시는 현실적인 Python 코드라기보다 반(反) Python 풍자처럼 보임
  표준편차를 직접 구현하는 건 학부 과제 수준임
  실제로는 R과 Python 모두 내부적으로 이런 루프를 돌고 있음

  • 글이 연구실 맥락에 초점을 둔 건 이해됨
    하지만 실제 산업 환경에서는 Python이 엔지니어링 팀과 협업하기 훨씬 쉬움
    R 코드를 프로덕션에 배포한 적이 있는데, 매우 불안정했음
    R은 탐색적 분석(EDA)에는 훌륭하지만, 대규모 소프트웨어 개발에는 부적합함