python 3.8 -> python 3.11 업데이트 경험기

python 3.8 의 생명이 별로 남지않았다.

 

일전 다른 글에서 적었듯이 회사의 프로젝트 중 python 버전을 3.8로 사용하고 있었다.

그래서 해당 기간이 끝나기전에 버전을 올릴 필요가 있었다.

 

그러면 버전을 왜 올려야하나?

솔직히 말하면 지금 잘 돌아가는데 굳이 바꿀 필요가 없을수도 있다.

그런데 왜 바꿔야 하는건가? 라는 질문에 내 생각을 나타내면 아래와 같다.

 

1. 성능적인 이점

python 3.9, python 3.10 버전에 대해서는 따로 성능적인 업데이트에 대한 내용이 없다.

하지만 3.11 에서는 성능이 전작기준 대비 평균적으로 약 25% 상승이 있었다고 말한다.

그렇다면 일단 전체적으로 코드의 큰 변경없이 서비스의 속도가 향상되는 것을 기대할 수 있으니 큰 이점으로 다가온다.

 

2. 생산성 향상

나는 주로 python3.11 혹은 python3.12 를 사용해왔다(그전에는 주로 3.6....).

딱히 이유가 있어서가 아닌 그때 당시에 release가 되어진 버전을 사용했다고 보는게 맞는데 이러한 버전을 쓰다가

현재 회사프로젝트가 python3.8 을 사용하다보니 약간의 생산성이 떨어지는 부분이 생겼다.

 

사소하게는 typing 관련해서 예시를 들 수 있다.

#python 3.8 version
import typing

def test_typing(list_item: typing.List[str]):
	for item in list_item:
    	print(isinstance(str, item))
        

#python 3.11 version
def test_typing(list_item: list[str]):
	for item in list_item:
    	print(isinstance(str, item))

 

 

어떻게 보면 사소하다고 할 수 있는데 저러한 코드를 계속 작성하다보면 저 사소한게 의외로 크다.

 

주로 버전별로 업데이트 사항이 축약되어져서 나오기는 하는데 3.8에서 3.11 더 나아가 3.12까지 봤을 때

python 에서 type 관련으로 많은 업데이트가 있었다.

이러한 부분이 어떻게 보면 생산성 증대가 되어진 부분도 있다.

 

3. 라이브러리의 노후화 및 지원을 받지 못한다.

라이브러리도 결국은 지원하는 python 버전이 있고 대부분 지원 종료가 끝나 python version 의 경우에는 지원을 안하게 된다.

 

이유는 당연히 그 python 버전을 지원하기 위해서 따로 코드를 더 작성해줘야 하고 분기를 태워야하는데 그게 말로만 들어도 어려운데

실제로 하려고 하면 더 어렵다.

 

심지어 지원이 종료된 경우에는 또 찾지 못한 버그가 있을 수도 있는데 그것들로 인해서 악용이 되어질 수도 있다.

 

만약 본인이 쓰고있는 python version 이 지원이 종료가 되었다. 그렇다면 흔히 쓰는 클라우드 컴퓨팅 제공 업체에서 지원을 안하는 경우가 생길 수도 있다. 기본적인 방법이 아닌 작업의 공수가 커진다는 것을 의미한다.

 

결국 deprecated 가 되어진 버전으로만 작업을 해야하는 순간이 올 수도 있는것이다.

 

버전을 올리면서 겪은 이슈

1. pandas 설치 이슈

일단 이상하게도 버전을 업데이트하고 라이브러리를 새롭게 설치를 받았는데 너무나도 느렸던 경험이 있었다.

하지만 한번 설치한 이후에는 그거를 다시 설치를 하지않기에 몰랐는데

배포를 하는 경우에는 대부분 새롭게 설치를 하는 경우가 기본이기에 거기서 문제가 발생했다.

AWS의 EB를 통해서 배포를 하는데 배포가 완료되기까지 너무 시간이 오래걸리거나 혹은 안되는 경우가 발생을 하는 것이었다.

 

그래서 열심히 무엇이 문제일까 찾아보다가 log를 확인해보니 오래 걸리는 라이브러리를 찾을 수 있었고 pandas 에서 문제가 발생한다는 것을 알았다.

 

그래서 구글링을 해보니 python 버전마다 pandas의 버전이 잘 호환이 되어지는 버전이 존재하고 그 버전으로 라이브러리를 설치해야지 설치에 대한 이슈가 없다는 것이었다.

그래서 당시 python 3.8, pandas 1.4.3 -> python 3.11, pandas 2.2.2 로 올려서 설치를 하니 해당 이슈가 해결되었다.

 

2. python 3.11 에서 drf-yasg -> drf-spectacular 변경

회사 프로젝트에서 문서화 라이브러리를 drf-yasg를 사용하고 있었다.

그런데 해당 라이브러리가 python 3.11을 확실히 지원한다는 문구를 찾을 수도 없었고

또한 github 을 확인했을 때 최근 commit 내역이 없어서 이거는 변경의 필요성이 있다고 판단했다.

그래서 찾아보니 drf-spectacular 는 일단 commit 내역이 최근에도 있으며 지원을 한다고 명시가 되어있었다.

 

그리고 더불어 pydantic 외 여러가지 지원하는 요소가 많았기에 문서화 라이브러릴 바꿀 가치가 있다고 판단했다.

물론, 옮기는 것이 쉬운 작업은 아니었다. 너무 많은 API 가 있었기에 해당하는 부분을 하나하나씩 이전 문서를 보면서 바꾸는 것은 쉽지않았다.

 

3. Cache 관련 문제

라이브러리 업데이트 하면서 캐시 관련으로 쓰는 django-cacheops 와 redis 를 업데이트 했다.

 

그런데 이슈가 생긴 부분이 기존 django-cacheops 에서 사용하던 cacheops.redis.CacheopsRedis 가 redis.Redis 로 변경되어져서 사용해야 했고 그러다보니 기존에 설정해놓은 DegradeRedisClient 가 정상적으로 동작을 안하게 되는 경우가 생겼다.

 

원래 시나리오의 경우

redis 의 접속이 안되어진 경우 db를 통해서 데이터를 가져와야하는데 이 부분이 문제가 생겨서 redis 의 접속이 안되어진 경우 그냥 에러를 발생시키는 것이었다.

 

그래서 해당하는 부분을 수정할 필요성이 생겼다.

 

일단 처음에는 타임아웃이 0.5초 정도로 설정되어 있었고 이부분에서 간혈적으로 타임아웃 이슈가 발생하여 대응이 안되어지는 줄 알고

따로 Timeout 을 exception 처리를 했다.

하지만 이렇게 하더라도 문제가 발생하는 것이 timeout 외 이슈가 발생할 요지는 너무나도 다분했다. 잠깐이라도 운영상에서 cache 가 제대로 정상동작을 안하는 상황이 발생하면 전체적인 서비스 장애가 발생하니까 말이다.

 

그래서 최종적으로는 모든 부분에 exception 처리를 했고 redis 에서 버전을 체크하는 부분만 따로 작성해두어서 그 케이스만 통과하도록 변경했다.

 

class DegradeRedisClient(Redis):
    def execute_command(self, *args, **options):
        try:
            return super().execute_command(*args, **options)
        except Exception:
            if args[0] == "INFO" and args[1] == "server":
                return {"redis_version": "0.0"}
            return None

 

이렇게 된 경우 모든 exception 에 대해서 문제가 안생기고 따로 redis에서 예전 버전을 지원하기 위해 작성되 version 확인 스크립트는 연결이 되어지지 않은 상황에서도 문제 없이 넘어간다.

 

후기

약간 급하게 마무리 하는 감이 없지 않아있다.

그거는 이 버전업을 진행할 때 혼자 진행을 하다보니 모든 케이스에 대해서 알고는 있는데

너무 자잘하게 뭐가 deprecated 가 되었으니 이거 사용하세요 보다는 그냥 시간이 가장 많이 소요되었거나 중요도가 있는 부분을 다루다보니 그렇게 되었다.

 

일단 후기를 말하면 이렇게 업데이트를 하게 되면서 좋은 점은

 

해당 프로젝트에서 test code를 처음으로 작성했다는 것이다. 이전에는 test 라이브러리 및 코드조차가 없었다... 그러다보니 배포할 때마다 살이 떨렸는데 지금은 조금 괜찮아졌다.... 왜냐하면 전체 테스트를 작성하기에는 작업양이 어마무시하기에 엄두가 아직은 안난다.

 

두번째는 pydantic을 사용한다는 것이다. dataclass 가 나쁜 것은 아닌데 pydantic 이 여러모로 간편하기도 하고 AI 및 통계에서 말하는 성능에 대한 이점을 크게 높여야 하는 것이 아니면 dataclass 보다는 pydantic 을 사용하는 것이 생산성이 높다고 판단하기에 아주 좋았다. 기존에 python3.11 을 쓰다가 python 3.8을 쓸 때 이부분이 약간의 족쇄로 다가온 부분이 없지않아 있었다.

 

세번째는 성능이 확실히 좋아졌다. 이게 뭔가 지표적으로 보여줄 수는 없지만 현재에도 개선을 계속 진행을 하고 있다보니 기록은 있어도 불확실하다.

하지만 그때 당시 업데이트 하기 이전과 후를 비교했을 때 약 20% 정도는 빨라진 것으로 보였다. 그러다보니 사용자가 느끼는 편의성은 더 좋아지지 않았을까 생각한다.