업데이트에서 배우는것 — SQLAlchemy 2.0
저는 업데이트를 좋아합니다. 프로젝트에서 사용하는 라이브러리의 새 버전이 나오면 업데이트할 생각에 설레는 편이죠.
하지만 동시에 라이브러리 업데이트는 매우 고되고 성가신 작업이기도 합니다. 특히나 프로젝트의 핵심이 되는 코어 라이브러리를 업데이트하는건 더더욱 어렵고 위험하죠.
이번엔 사내 프로젝트에서 SQLAlchemy 버전을 2.0으로 업데이트 했습니다. 이전 버전에서 제공하던 호환성 API를 통해 개발해왔기 때문에 생각만큼 큰 일은 아니었지만 저에게는 특히나 의미있는 경험이었습니다.
SQLAlchemy는 2012년에 처음 접하고 올해로 11년을 사용한 라이브러리입니다. 언어 불문 SQL toolkit 및 ORM 라이브러리중 State of the art라고 생각하는 도구입니다. SQLAlchemy 없는 Python 웹개발은 상상도 할 수 없고, SQLAlchemy가 없으면 Python으로 웹개발을 할 이유도 없다고 생각할 정도였지요.
하지만 역설적이게도 저는 SQLAlchemy의 완벽함 때문에 Python으로 하는 웹개발에 대한 회의감을 가지게 되었습니다.
저는 Python 커뮤니티에서 웹개발 생태계 발전을 위해넘어야할 두가지 큰 산이 있다고 생각합니다. 첫번째는 정적 타이핑, 그리고 두번째는 마법(magic)이 없는 비동기 네트워킹입니다.
물론 Python 커뮤니티는 두가지 산을 잘 오르고 있었습니다. PEP 484와 mypy는 실용적인 정적 타이핑을 production 레벨로 끌어올렸고, asyncio와 코루틴은 gevent의 흑마법에서 벗어나 정직한 비동기 네트워킹을 이뤄내고 있죠.
그렇지만 이전의 SQLAlchemy는 두가지 산에서 모두 쥐약이었습니다. 아름다운 metaclass를 이용해 생성된 class는 완벽한 type hint를 줄 수 없을것만 같았고, 객체가 데이터 로드를 책임지는 ORM에서는 비동기 네트워킹이 개념적으로 불가능했습니다.
기존 Python 생태계에서는 아무 문제 없으며, 단단하고 아름다운 구현을 가지 라이브러리였기에 이런 새로운 개념을 받아들이려면 밑바닥부터 체질이 바뀌어야 할 상황이었습니다. 그렇기에 SQLAlchemy의 거대한 변화를 기대하는것 보다 Python 웹개발에서 떠나는것이 더 현명하다고 생각하고 있었죠.
하지만 SQLAlchemy 2.0의 출시는 제 생각이 어리석고 부족했다는 것을 보여주었습니다.
ORM Mapped Class는 새로운 매핑 전략을 제시함으로써 표준 typing을 완벽하게 지원하기 시작했습니다. 기존에 ORM 모델 클래스에 의존성을 역전하는 부가적인 action을 넣지 않았다면 손쉽게 전환할수도 있죠.
새로운 쿼리 전략은 asyncio 친화적이며, 훨씬 직관적이고 context 없이 쿼리하기에 비동기 네트워킹에서 불가능한 lazy load를 피할 수 있습니다.
이러한 변화는 새로운 라이브러리가 출시해야 가능한 변화일 것 이라고 생각했고 SQLAlchemy에서는 기대하지 않고 있었기에 더더욱 감명깊었습니다.
개인적으로 저는소프트웨어 엔지니어링에서 가장 중요하게 생각하는 덕목중 하나를
이상적인 구조로의 현실적인 전환
이라고 이야기합니다.
이상적인 구조를 이야기 하는 것은 쉽습니다. “도메인 주도 개발을 위해 이러한 구조를 만들어야한다”, “테스트 주도 개발을 해서 Shift-Left를 이뤄내야한다” 라는 말은 책 한두권 읽고 엔지니어링에 대한 선망으로 주장할 수 있는 내용이죠.
하지만 이를 실제로 이뤄 내는것은 전혀 다른 문제입니다. 본인이 생각하는 이상적인 구조가 있다면 그것을 이뤄내는것이 진정으로 훌륭한 소프트웨어 엔지니어입니다.
팀의 이상향이 정해지면 우리 프로젝트에서 그 방향으로 가기 위해 어디서부터 시작하는게 현실적인지, 어떤 경로를 통해 그 목표에 다다를지 고민하는게 진짜 능력이죠.
SQLAlchemy팀은 이를 멋지게 해냈습니다. 커다란 목표를 정해 결국 이뤄냈고, 우리 앞에 내놓았습니다. 그들의 능력에 경의를 표합니다.
ref. https://www.sqlalchemy.org/blog/2023/01/26/sqlalchemy-2.0.0-released/
