성능(performance) 최적화는 많은 개발자들이 관심갖고 이를 위해 다양한 방법을 시도한다.
성능은 구체적인 코드가 아닌 추상적인 결과물이다. 코드 + 알고리즘 + 하드웨어 + 인프라의 구성 방식 + 다양한 설정(configure) 및 환경에 따라 셀 수 없이 많은 변수가 생긴다.
소프트웨어 공학자들은 알고리즘을 통해 서버 관리자는 인프라 또는 DB 모델링, 하드웨어 등을 통해서 시도할 수 있다.
완벽이란 있을 수 없지만 그래도 개발자들은 지속적으로 최적화를 위해 노력한다.
기본적으로 어떤 언어를 사용하느냐에 따라서도 성능의 차이가 생긴다. 웹이라면 node 서버 또는 django나 기타 다른 프레임 웍 등 다양한 선택지가 있고 성능과 개발 시간은 보통 반대로 간다고 보면된다.
일반적인 수치로 성능을 비교할 때 유의미한 차이가 있다 보여져도 실제로 서비스 시에 이런 성능의 체감을 느끼기 힘들 정도일 수도 있다.
실제로 django와 같은 프레임워크는 python을 사용하기에 느릴거라 생각되지만 그렇지 않다. 물론 어떤 서비스냐에 따라 결과는 달라질 수 있겠으나 우리가 생각하는 것 이상으로 cpu 집약적인 작업을 많이 하지 않고 cpu는 일반적으로 생각하는 것 보다 훨씬 빠르다.
가끔 성능을 위해서 python에 cython 또는 다른 언어를 glue 시키려고 할 수도 있겠다.
구글 검색을 해봐도 django pypi 또는 django에서 cython이나 C, C++를 glue해서 사용하려는 시도도 간간히 있다.
많은 시도가 아니므로 안정성 면에서 장담하지는 못한다.
문제는 데이터다. python의 데이터는 기본적으로 껍질이 많다. 속도가 아무리 빠른 언어라 하더라도 python 에서 C로 C에서 python으로 데이터가 캐스팅되는 데 걸리는 시간은 우리가 생각하는 것 이상 오래 걸린다.
얼마나 CPU 집약적인 작업을 오래하느냐에 따라서 이런 작업이 유의미할 수 있겠으나, 일반적인 경우 무의미 또는 마이너스가 된다.
데이터의 크기는 메모리의 양이나 데이터를 어떻게 모델링 하느냐에 따라서 최대한 축소하는 것이 좋고 하나의 작업단위에 여러 언어를 혼합해서 사용하는 것은 가능하면 하지 않는 것이 좋다는 생각이다.
컴퓨터는 우리가 생각한 것 이상으로 빠르다. 그래서 우리가 비 효율적인 코드를 작성했더라도 큰 차이를 느끼지 못할 수도 있다. 그럼에도 성능이 악화되었다면 분명 기본적인 코드, 알고리즘, 인프라 중에 문제가 생긴 것이다.
결국 질 좋고 성능 좋은 서비스를 위해서는 기본에 충실해야 한다는 생각이다. 그 이상의 성능을 위한 작업은 그 다음 생각해도 좋다.
그리고 web assembly라는 말을 자주 듣는다. rust,C가 javascript를 대체하여 웹에서 동작할 수 있도록 생태계가 바뀌고 있다. 이러한 생태가 온다면 웹이라는 무대가 우리가 상상하는 것 이상으로 커질 것이다.
쉽게 말해서 현재의 웹브라우저가 '말'이라면 web assembly를 사용하면 브라우저가 '제트기'가 되는 것이다. 분명 현재의 웹은 성능의 포화상태다. 개발자들의 무궁무진한 아이디어가 성능에 발목잡혀 시도되지 못하고 있다 생각된다. 그리고 분명 웹의 생태계는 껍질을 탈피할 것이다. 발빠른 개발자들은 그 때를 미리 대비해야할 것이다.