기본 콘텐츠로 건너뛰기

개발언어 파이슨(Python) 의 장단점 및 2, 3의 큰 변화, 구조에 관련된 이야기

파이슨 관련 이야기가 나왔다.
난 지금도 asp를 쓰고 있고, wmi, shell만으로도 모든게 가능해서 다른 언어는 뭐라도 상관없다. 필요한 기능 호출만 가능하다면..

그런데 왜이렇게 한국 사람들은 파이슨을 신격화 시키는지..
게다가 물어보면 그냥 좋대더라..
개발자가 논리력이 이렇게 없어서야..

파이슨을 모르는 내가
파이슨에 대해서 논해보겠다.
기술적인 태클은 언제든 환영이지만 인신공격은 무조건 삭제함.

파이슨은 C를 이용해서 원래 언어를 만드는 사람이 아닌 개발자가 만든 언어이기 때문에 랭기지로서는 아직도 발전해야 할 것이 많다.

하지만 개발자 Guido van Rossum은 Google 및 FOSDEM, ACM, NLUUG 등 유명한 소프트웨어 관련 경험이 있었고, Python역시 ABC에서 따서 만들었기 때문에 구조는 크게 나쁘지 않았다.

Python은 다음의 특징을 가진다.(DARPA에 제출한 투자제안서에 기입한 내용)

- 쉽고 직관적인 언어.
- 메이저 개발언어와 동급의 성능
- 오픈소스
- 쉬운 코드
- 일상적인 태스크에 적합하고 쉽게 개발되는 언어

위와 같은 특징에서인지 초보자들용 으로 많이 불리고 있다.
하지만 오픈소스이기 때문에 많은 사람들이 많은 라이브러리를 만들어 FORTRAN계열과 같은 수학에 특화된 언어처럼 바뀌어졌다는게 내 생각이다.

때문에 지금도 ML중심의 언어로 많이 쓰이고 있지만,
웹 언어로는 아직도 쉽게 접근하기 힘든 것이 바로 Django같은 MW의 어려움 때문에 바로 시작하기에는 PHP나 ASP가 더 쉬운 언어같다. (그럼 PHP나 ASP가 웹은 초심자용? ^^;;)

쉬운 언어 = 초심자용 언어 = 능력이 떨어짐

이라는 선입관이 너무 팽배한지,
쉽다는 표현, 초보자용이라는 표현에 거부감이 많은 것 같다.
하지만, 그건 자괴감이 아닐까?
난 아직도 VB script베이스인 ASP로 모든 것을 해결하는데 부족함이 없다.
그럼 난 20년 넘은 초보 개발자?


하지만 많은 벤치마크에서도 이야기 했듯이,
Python Interpreter engine의 이슈로 성능은 메이저 개발 언어에 미치지 못하고 있다.
그리고 처음부터 웹 소스 분석용으로 만들었기 때문에 프론트 언어보다는 서버 스크립트 언어로서 더 어울리는 코드들이 보인다.
아직도 ML같은데서 많이 쓰이면서 웹언어는 PHP로 가거나 하는 경향이 있는 이유가 바로 여기 때문이 아닐까?

그리고 Python2와 Python3은 동일한 코드 체계를 가지는 듯 하지만 너무 많은 사양 변경으로 Python2를 Python3에서 인계받지 못하였다. 이를 "후방호환성이 무너졌다"고 표현하는데, 언어가 멈춰버릴 수 있을 정도의 중대한 문제임에도 불구하고 어쩔 수 없이 이전 버전의 기능들을 포기할 수 밖에 없었다.

가장 중요한 Python의 철학인 "문장" 과 "식" 을 구분짓는 형태에서 초기 버전2에서 너무 많이 무너져 있었기 때문에 3에서는 과감하게 철학을 유지하기 위해 기존에 무너진 형식을 많이 버리게 되었다.

때문에 2용으로 많은 많은 라이브러리가 3에서 채택되지 못하는 상황이 발생하였고, 오픈소스다보니 라이브러리를 만든 사람들이 3으로 포팅을 하지 않는 바람에 아직도 2에서밖에 못쓰는 라이브러리가 많아 2인채로 사용해야만 하는 경우가 빈번하다.

이 때문에 pyenv등의 버전을 스위칭하는 툴들이 추가로 개발되고 더욱 복잡성을 향해 달려가고 있다.

MS에서도 .net Framework 4.0이 나오면서 3.5를 완전히 버리면서 발생한 문제와 거의 같지 않을까 싶다.
MS와의 다른점은 MS는 3.5와 4.0을 동시에 설치하고 사용할 수 있도록 그나마 Architecture가 탄탄하게 되어 있으나, Pythone은 2와 3을 동시에 사용할 수 없게 되어 큰 불편함을 겪었다. 지금은 python2, python3이라는 link로 같이 사용할 수 있는 방법등이 나와서 큰 문제는 사라지고 있다.

위에서 언급한 Python의 기저 철학인 "문장"과 "식"에 대하여 언급하자면

"평가식", "함수나 메소드를 호출하는 방법", "오브젝트의 표기", "리스트내의 따옴표"등이 식이라고 불리고 이는 한 줄에 모두 모아서 쓸 수가 있다.  파이슨이 짧은 줄에 다른 언어에 비해서 많은 처리를 할 수 있는 핵심이라고 할 수 있다.

반면 if, for, try ~ except, import 등등은 문장이라고 하여 문장은 1줄에 여러 문장을 쓸 수 없다.

이 역시 처음 DARPA에 제출했던 "누구나 쉽게" 만들 수 있는 가독성을 위한 철학이다.
이러한 철학을 가장 많이 부수었던 것이 바로 print문이다.

print는 "문장"으로서 써야 하는데 형식이 전혀 달랐는데,
Python3에서 print는 문장이 아니고 함수로 만들어 이를 완전히 초기의 철학에 맞추기 위해 형식을 완전히 바꾸어버렸다.

Python2에서의 Print문은

print >>f, "Print out to monitor"

라고 한다면 python3에서는

print("Print out to monitor", file=f)

같은 식으로 해야만 한다.

두 번째의 큰 변화는 기본 8비트 문자형이었던 언어코드를 기본이 유니코드로 변경되었다. 설치된 OS의 언어에 따라 깨지는 현상이 없어진 것이다. 이 부분은 Python3에서 추가된 형으로 기존 Python2에서의 모든 형은 그대로 사용 가능하다. 그 외에도 codecs, EUC, UTF-8등 다양한 변환이 가능해졌다.
그리고 새로운 문자형인 byte형이 추가 되었다.

이러한 문자형의 추가는 메모리 이용의 효율화에 목적이 있어, 타입을 쉽게 변경할 수 없도록 설계되어 있다. python2의 문자형과 python3의 byte형 등은 모두 변경불가능한 데이터 형태이다.

python3에서는 타입을 바꿀 수 있는 bytearray형 등이 추가 되어 jpeg화상을 byte형으로 읽은 다음에 exif정보를 bytearray형으로 넣으면 변경등이 가능해진다.

그밖에 int형의 변화와 interate, view에서도 변화가 있는데..
너무 길어서 생략.. ㅠㅡㅠ

이런 식으로 개발 철학을 일관되게 하기 위해 많은 것을 포기하였으나, 이게 이후 어떠한 영향이 있을지는 모르겠다. 단지, 아무나 만든 언어는 아니고, 쉽게 쓸 수 있도록 만든 것은 분명하다.

하지만, 그동안 나왔던 언어들도 그렇듯, 대세란 없다. 그냥 그 타이밍에 가장 적합한 언어를 채택하는 것이고, 그 시대의 트렌드 때문에 조금 더 쓰일 수는 있을 뿐이다. 파이슨이 쉽고 ML용 라이브러리가 많다고 해서 방송 송출 예약 시스템의 Sequential script를 위해 아직도 쓰고 있는 COBOL을 제낄 이유는 전혀 없는 것이다.
설마 10%대의 점유율을 대세 라고 부르고 싶은 것은 아닌지?



Do not login your server any more!
Free server management tool!
https://giipasp.azurewebsites.net/


댓글

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...