#djangomeetup 1회 후기
강남 토즈에서 파이썬 사용자 모임 2015년 11월 모임, 웹 개발자 BoF 모임이 있었습니다.
PyCon, Deview 등의 행사는 많이 참가해봤지만 이런 모임은 처음이라 이걸 꼭 가야 하나, 가서 뭔가 배워올 수 있을까 하는 생각으로 참석했습니다. (...)
참가신청은 위에 있는 온오프믹스 페이지를 통해 받았고 최종 신청자 수는 41명? 이었던 것에 비해 절반도 참석하지 않으셔서 첫 타임에는 이게 제대로 될까 하는 걱정으로.. 간단하게 이 모임의 목적을 소개하고 각자 자기소개를 한 후 여러 토픽을 꺼내면서 모임이 진행됐습니다. 중간중간에 침묵이 흐르기도 하고 열띤 토론을 하기도 했는데 예상보다 적은 인원이 모였음에도 모임 자체는 나름대로 성공적으로 개최된 것 같아 다음에는 더 많은 분들이 참석해서 좋은 정보를 서로 나누고 각자의 의견을 공유할 수 있으면 좋을 것 같습니다.
아래는 자리에서 여러 주제별로 내용을 요약한 자료인데 생각보다 모르는 것들이 많이 나와서 다 적지는 못했습니다. 그냥 이런 토픽이 오고갔다 정도로 보시면 될 것 같습니다.
- 배포(deploy)
사실 저는 CentOS 자체를 쓸 일이 아예 없어서 이쪽 사정을 몰랐었는데.. CentOS 6.x의 경우 Python 2.6이 기본이라고 하며, 대부분 Python 2.7을 사용함에 따라 virtualenv를 따로 구성해줘야 하는데 여기서 CentOS 자체에서 제공하는 SCL(Software Collections)을 이용해 환경을 구축하는 이야기가 오갔습니다.
이어서 배포라고 하면 꼭 나오는 가상화 컨테이너인 docker 이야기가 나왔는데 이에 관련해서는 다른 정리가 잘 된 글이 너무 많아 따로 적지는 않았습니다. - 로깅(logging)
많은 이야기가 오갈 줄 알았는데 의외로 적은 내용이 오고간? 토픽인 것 같습니다. 뭐 소규모라면 + 혼자서 쓰는 거라면 /var/log 단 아래에 로그를 놓고 보는 경우가 대다수일 거고 굳이 시간을 들여 복잡한 환경을 구축할 필요는 없으니까요. 로깅 부분에서는 아무래도 역시나 센트리(sentry) 이야기가 제일 많이 나왔습니다. 뉴레릭(new relic)이라는 소프트웨어를 사용하시는 분의 이야기도 있었지만 뉴레릭에 대한 지식이 없어서.. (ㅠㅠ) 사실 센트리는 모든 로그를 로깅하는 로거보다는 이벤트 로거에 가까운데, 기본적으로는 어떤 앱이 돌다가 오류가 발생했을 때 로그를 기록하도록 되어있고 그 외에 개발자가 직접 로그를 남길 수도 있게 되어있습니다. 한 가지 문제(?)라면 오래된 버전과 최신 버전 사이의 갭이 큰 상태에서 최신 버전으로 업데이트하고 마이그레이션을 하면 데이터가 온전히 보존되지 않을 수도 있다는 것인데.. 이게 저만 그랬던 게 아니었네요. ㅠㅠ 뭐 이런 이벤트 로거는 딱히 최신 버전에 대한 필요가 크지 않기 때문에, 또한 이 오류가 발생하는 게 유저 책임일 수도 있기 때문에 확실하다고 보기는 어렵습니다. 음 그러니까. 저는 로거가 필요하다는 분들에게는 센트리를 강력히 추천드립니다. - uwsgi, gunicorn, mod_wsgi
웹 애플리케이션 배포를 무엇을 통해 하느냐에 따라 크게 위 3개로 구분할 수 있는데 간단히 uwsgi는 WSGI 프로토콜을 이용해 앱과 서버 사이에서 통신할 수 있게 해주는 서버이고, gunicorn은 uwsgi와 마찬가지로 WSGI 프로토콜을 사용하는 서버이고, mod_wsgi는 Apache 웹 서버에 사용할 때 가장 추천되는 모듈입니다. 그냥 쉽게 Apache를 쓴다면 mod_wsgi, Nginx를 쓴다면 uwsgi인데.. 뭐 그냥 이렇게 알고만 써와서 uwsgi만의 특별한(?) 부분을 알지는 못했는데 이에 관련해서 배권한님께서 ditto님이 쓰신 좋은 글을 소개해주셨습니다. - ORM + (a)DB
음 토픽으로 나오긴 했었는데 별다른 내용 없이 지나갔습니다. 아주 쉽게 요약된 내용은 장고 ORM은 구리고, SQLAlchemy + alembic은 훌륭하다 정도.. 장고 migration과는 다르게 alembic에서는 branch를 따로 따서 작업을 할 수 있다고 들었는데 아무래도 경험 + 지식이 짧아 개인적으로는 "저런 것도 있구나"라며 넘어갔네요. ㅠㅠ - 크롤러 & 파이썬 버전 문제
새로 배우는 분이라면 3.x, 과거에 이미 짜둔 게 있다면 2.7인데 3.x를 쓰면서 큰 불편함이 없다는 분도 계셨고 아무래도 유니코드 문자열 처리에서는 3.x가 더 편하다 보니, 과거보다는 Python 3.x에 대한 인식이 많이 좋아진 것 같습니다. (저는 과거에 짜둔 코드는 어쩔 수 없고 새로 짜는 코드는 전부 3.x로 짜고 있습니다.)
한 분이 어떤 크롤러를 사용하냐는 질문을 하셨었는데 저같은 경우 requests(session)/mechanize + beautifulsoup 조합만을 고집했었고 Scrapy같은 경우 사용해봤었다가 그 특유의 방식이 별로 맘에 들지 않아 꺼려했었는데 생각보다 많은 분들이 Scrapy를 사용하고 계셨습니다. Scrapy의 장점은 한 번에 여러 페이지를 불러오기 수월하다던가 scrapyd, scrapinghub 등 여러 부가적인 요소들이 많다는 점이 꼽힌 것 같은데 가장 인상적인 것은 scrapinghub 였습니다. scrapy 코드를 작성해서 올려두면 걸리지 않게(...) IP나 UA 등을 바꿔가며 크롤링을 할 수 있게 지원해준다는 것과 데이터를 쉽게 수집하고 로깅도 지원한다는 점이었는데. 음 홍보는 아니고 가격도 생각보다 저렴합니다. 광고 수익 정도로 저 요금을 지불할 수 있는 수준이라면 진지하게 scrapinghub 사용을 고려해볼 수 있을 것 같습니다.
scrapy가 장점만 있는 것은 아닙니다. twisted에 의존하다 보니 Python 2에서만 사용할 수 있다는 점인데 Python 3.3부터 asyncio가 지원되어 twisted, gevent와 같은 라이브러리가 굳이 Python 3을 위해 재작성/수정될 것 같지는 않다는 이야기가 나왔습니다. 즉, scrapy 자체가 twisted 대신 asyncio를 사용하는 코드로 재작성되기 전까지 Python 3을 지원할 수 없다는 부분인데 이미 누군가가 작성한 코드가 있다거나 하면 댓글로 알려주시면 많은 분들에게 도움이 될 것 같습니다. - CSRF + API에 대한 이야기
큰 내용은 아닙니다. 굳이 CSRF 인증이 필요한가?에 대한 내용이 나왔는데 (1) 조금이라도 해커를 귀찮게 하기 위해(...) (2) XSS 등의 상황에서 발생할 수 있는 보안 문제를 막기 위해 필요하긴 하다는 내용 정도..
API의 경우 인증(authentication)을 어떻게 처리하는지에 대한 이야기가 나왔는데 (1) 세션 (2) HTTP Basic Auth (3) JWT, 크게 3개로 나뉘었습니다. JWT는 알고만 있고 직접 써본 경험은 없어서 간단히 PyJWT라는 것이 있다는 것 정도로 남겨둡니다. - 결제 시스템 + PHP
아마 많은 파이썬 웹 개발자분들의 걱정이 아닐까 싶습니다. 대부분의 PG사에서 Python 모듈을 제공해주지 않고 있으며 이에 따라 많은 개발자들이 ASP/PHP를 섞어서 해결한다던가, PHP를 서브프로세스(subprocess)로 띄워서 처리한다던가.. 하고 있죠. iamport라는 서비스가 소개되었는데 아직 안정적이지는 않은 것 같습니다. 이 부분은 딱히 답이 정해진 게 없는 게 소규모 서비스가 아닌 이상 공식적인 Python 방법이 존재하지 않아 하이 리스크(high-risk)를 동반하기 때문이죠. 세션을 공유해서 PHP에서 장고 세션을 읽어 처리하는 방법이나 반대로 장고에서 PHP 세션을 응용하는 방법에 대한 이야기도 나왔는데 역시 이 또한 모험이기에.. 이 문제는 국내에 Python 사용자가 많이 늘어나 빨리 해결되었으면 좋겠습니다. - Celery, Wand
Python 내에서 다른 대안이 없는 유일한 독보적인 존재입니다. 조금이라도 오래 걸리는, 프로세스에 부하를 줄 수 있는 작업이라면 당연히 Celery를 써야 하고 Django, Flask를 가리지 않고 가장 광범위하게 사용되는 패키지이기 때문입니다. 전에 PyConKR 2015에서 Celery에 대한 세션이 있었는데 역시나 Broker로는 RabbitMQ가 제 격이라는 것을 다시 한 번 확인했고, 외에 Celery를 어느쪽에 활용할 수 있는지에 대한 이야기도 나왔습니다.
이미지 섬네일 처리에 대해 이야기하며 어느 라이브러리를 사용하는지도 물어보셨는데 역시 이건 wand가 답이었네요. - Git 애플리케이션
SourceTree, Git Tower, GitKraken. 그리고 4-way merger(P4Merge). - 프론트엔드
가장 뜨거운 주제가 아니었나.. 합니다. AngularJS, React에 대한 이야기도 나왔고 역시 많은 분들이 React를 선호하셨던 것 같습니다. AngularJS 자체는 사용하기에 부담스러울 정도로 그 규모가 너무 큰데다가 무겁기까지 해서 점차 선호도가 떨어지는 거랄까.. React는 공식 홈페이지에 "A JAVASCRIPT LIBRARY FOR BUILDING USER INTERFACES"라고 나와있듯 각 컴포넌트 단위로 개발을 할 수 있고 jQuery 사용을 별로 권장하지 않는 AngularJS와는 다르게 사용에 대한 그 어떠한 제약이나 사항을 두고 있지 않기 때문에 양쪽을 모르는 개발자가 AngujarJS보다는 접근하기가 더 쉽지 않나 싶습니다.
이러한 다른 프레임워크나 라이브러리를 쓰려면 기존의 Django 형태와는 약간 다르게 개발을 해야 하는데 이 과정에서 장고에 REST만 얹어서 장고는 API 서버 역할만 하고 React 등을 사용한 개별의 페이지를 만들어 개발한다는 분도 계셨습니다. 이 방법의 경우 예전부터 고민해왔던 방법이긴 한데 아무래도 djangotic(?)이라 해야 하나 - 굳이 이러면 왜 장고를 쓸까 - 라는 생각 때문에 적용해본 적은 없는데.. 실제로 그렇게 적용한 분의 이야기를 들으며 한 번 해보면 나쁘지는 않을 것 같다는 생각을 했습니다.
이외의 assets 관리(django-pipeline, django-bower 등)에 대한 이야기가 나왔습니다. 여러가지 섞어서 보면 그냥 "프론트엔드는 아직까지 정해진 답이 없다."가 되겠네요.
많은 고수님들이 계셨고 몰랐던 것을 많이 알아와서 정말로 알찬 시간을 보냈던 것 같습니다. 신청한 인원에 비해 적은 인원이 모였는데 다음 모임부터는 더 많은 분들이 오셔서 각자의 생각을 나누고 좋은 정보를 공유할 수 있으면 좋겠습니다!