정적 분석 시작

LAH는 사내 서비스에 대해서 E2E 테스트를 진행해 왔습니다.
그러다 Next.js로 전환하고 개발 환경이 많이 바뀌게 되었습니다. E2E 테스트는 실제 사용자의 시나리오에 맞춰 테스트를 할 수 있다는 장점이 있지만, 이렇게 개발 환경이 바뀌면 사실상 새로 모든 테스트를 작성해야 합니다.

기술 스택이 변경되지 않았더라도, LAH의 서비스는 아직은 사용자의 사용 패턴에 따라 크고 작은 피보팅이 계속되고 있습니다.
게다가 이 과정이 꽤 빠르게 진행되어야 합니다.
결국 어렵게 운영해 오던 E2E 테스트를 잠시 중단하기로 했었습니다.

사실 E2E 테스트보다 유닛 테스트의 중요성을 강조하는 사람이 많지만, 개인적으로 E2E가 더 안정적이라고 생각했지만,
이렇게 환경이 빠르게 변할 줄은 몰랐습니다. 덕분에 유닛 테스트가 매우 협소한 상황이 되었습니다.

개발팀에서 회의를 거쳐, QA 과정에서 발생한 이슈에 대한 테스트 코드를 시작으로 테스트 코드를 쌓아가기로 정했습니다.
이렇게 정책을 정하고 나니 테스트 코드는 급한 불은 껐습니다.

그렇게, 시간이 흐르면서 앱 서비스도 나오고, 다른 개발 언어를 경험하게 되었습니다. LAH 포스팅에도 종종 올라왔었죠.
Flutter의 경우 기본적으로 non-nullable 언어이면서 Typed 언어입니다. 물론 null safety도 제공하죠.
그렇기 때문에 파이썬으로 개발할 땐 보기 힘든 타입 오류를 보면서 개발했습니다.

그렇게 Flutter 개발이 끝나고, 다시 백엔드인 파이썬 언어로 돌아왔는데 문득 아쉽다는 생각이 들었습니다.
파이썬을 Typed 언어처럼 쓸 수는 없을까..?

당연히 Typed로 쓰기 위한 PEP가 오래전에 있었고, 사용할 수 있습니다. 다만 현재 백엔드는 django 프레임워크를 사용하고 있는데, 프레임워크를 지원하지 않으면 Typed의 장점을 제대로 활용할 수 없다 보니 막연히 미뤄두었었는데, 우연히 글을 봤습니다.
django-stubs 라는 프로젝트가 있었습니다. typeddjango 라는 그룹에 여러 프로젝트들을 운영하고 있었습니다.
심지어 djangorestframework-stubs 라는 프로젝트로 DRF를 지원하는 프로젝트도 있었습니다.

그렇게 Typed를 활성화하고 mypy를 도입하기로 했습니다.

사소한(?) 문제가 있다면, 이미 프로젝트의 코드가 3만 줄이 넘었다는 것입니다. 이 코드 줄 수만큼 서비스도 커졌지만, 부채도 차곡차곡 잘 쌓였습니다.
그래도 기존 코드에 타입을 명시하는 것은 단순 작업이라 금방 진행하고 있습니다.

그동안 휴업하던 Jenkins 할아버지가 이제 다시 열심히 일할 때가 왔습니다.

---