python 언어의 간결함

python을 사용하는 건 대부분 딥러닝을 포함한 분석 때문이긴 하지만 언어의 간결성 때문에 프로토타입 소프트웨어를 만들 때에도 매우 편리하다.
flask 웹 서버가 매우 확장성이 좋은데 template 지원 기능이 기존의 JSP, ASP와는 전혀 다른 방식으로 간편하다.
게다가 matplotlib으로 만든 차트를 웹에서 d3 기반으로 embed하는 것(mpld3)도 가능하다.

데이터 -> python -> 웹까지 쉽게 연결되는 셈이다.

최근 빅데이터 처리를 위해 JVM 기반인 Spark 위에서 python 프로세스를 fork/exec 시키는 PySpark를 왜 쓰나 분석해보기도 했는데 (데이터 전달과 serialize 오버헤드에도 불구하고) 역시 python이 갖고 있는 Java나 Scala가 주지 못하는 데이터 처리 능력 때문인 것 같다.

시스템적인 측면에서 보면 python을 웹 서버나 분산 미들웨어로 쓰는 건 매우 어리석은 일이라고 볼 수 있어서 (multithread 기반의 concurrency가 global interpreter lock 때문에 몹쓸 놈이 되기 때문) python 기반의 openstack을 toy 시스템 외에 production으로 쓰려는 건 바보같은 짓이라고 생각하는데

Google이 십여년 전에 Google AppEngine이라는 PaaS 서비스를 오픈하면서 python 언어로 먼저 제공하고 그 다음에 Java 언어를 지원했던 이유를 알 것 같다. (클라우드 서비스에서 스케일링은 미들웨어가 아닌 컨테이너와 같은 OS 가상화를 통해 지원하면 되니... process pooling을 사용하거나 중요한 백그라운드 잡을 c/c++로 개발했을 수도...)

JVM으로 python을 fork하는 PySpark도 어쨌든 시스템 미들웨어로서 python을 쓰는 것은 무리이지만 데이터 분석은 python으로 하고 싶은 요구사항에서 나온 거라고 생각된다.
데이터 오버헤드 관점에서는 정말 말이 안되는 것 같은데 그래도 이렇게 요구사항을 맞추다보니 여러 가지 아이디어가 붙어서 나름 PySpark도 오버헤드를 많이 줄이긴 했다. (RDD 개념의 데이터는 JVM 메모리 상에 있는데 python에서 user defined function으로 작성하여 실행하면 실제 데이터 연산은 컬럼 기반으로 메모리에 저장된 JVM 위의 RDD에서 컬럼별로 배치로 가져와 처리하도록 하는 기능이 강화되었다. 통신 오버헤드는 양적으로는 그대로이지만, 통신 횟수가 극적으로 줄어든다. 온라인 처리이면 어이없는 짓이지만 배치 처리이기 때문에 말이 된다. Apache Arrow 참고)

데이터를 다루는 일을 python만큼 범용적으로 잘하기는 쉽지 않을 것 같다. 그리고 시스템적인 측면은 취약하지만 규모가 작거나 배치적 성격이 강하다면 한계를 알고 비켜서 사용하면 많은 경우는 문제가 되지 않을 것이다.

Flask의 템플릿 기능은 정말 단순하면서도 python의 힘을 잘 보여주는 것 같다. (python을 사용하는 사람에게는 학습 비용이 매우 작다)

Flask를 micro-framework이라고 부르는데 Java에서도 Blade 같은 게 등장하긴 했다.