FastAPI에서 사용할 수 있는 ORM(객체-관계 매퍼) 도구는 다양하지만, 그 중 가장 많이 사용되고 권장되는 3가지를 꼽자면 다음과 같습니다. 각 ORM마다 1인 개발자의 사용 편의성, 고성능을 위한 설정 난이도, 안정성과 유지보수 현황 등을 고려하여 분석하고, 작은 개인 프로젝트에서 중소형 웹 앱으로 확장할 때 어떤 ORM이 적합한지 추천하겠습니다. 참고로 FastAPI에서 주로 사용하는 데이터베이스는 관계형 DB (개발 단계에서는 SQLite, 프로덕션에서는 PostgreSQL이나 MySQL 등)가 많다는 전제하에 설명하겠습니다.
1. SQLAlchemy (및 SQLModel) – 가장 널리 쓰이는 표준 ORM
SQLAlchemy는 파이썬에서 가장 유명하고 오랫동안 쓰여 온 ORM입니다. FastAPI 공식 문서에서도 예제로 SQLAlchemy를 사용하고 있을 정도로, FastAPI 사용자들 사이에서도 기본 선택지로 널리 활용됩니다
. 특히 Flask 등 기존 파이썬 웹프레임워크에서 SQLAlchemy를 사용해본 개발자라면 FastAPI에서도 자연스럽게 채택하는 경우가 많습니다. 실제로 SQLAlchemy는 *“파이썬에서 가장 인기 있는 ORM”*으로 꼽히며, Stack Overflow에 관련 질문이 17,000개 이상 올라와 있을 정도로 많은 개발자들이 사용하고 있습니다
.
개발자 선호도 측면: SQLAlchemy는 풍부한 기능과 유연성으로 유명하지만, 그만큼 학습 곡선이 가파르고 초기 설정이 번거로울 수 있습니다. 모델(Base 및 클래스 정의) 선언, 세션(Session) 생성 등 보일러플레이트 코드가 꽤 있고 문법이 다소 장황(Verbose) 합니다
. 1인 개발자의 입장에선 처음 설정할 때 다소 부담이 될 수 있지만, 커뮤니티에 자료가 풍부하여 참고할 예제가 많고 문제 발생 시 해결 정보를 찾기 쉽다는 장점이 있습니다
. 일단 구조를 잡아놓으면 이후에는 큰 불편 없이 사용할 수 있고, 사용자가 많은 만큼 *“사실상 표준”*으로서의 신뢰도도 높습니다.
성능 및 안정성: SQLAlchemy는 엔터프라이즈급 성능을 내도록 설계되었고, 다양한 DB 최적화 기능과 패턴(아이덴티티 맵, Unit of Work 등)을 제공합니다
. 복잡한 쿼리나 다대다 관계 처리 등 고급 기능 지원이 가장 완벽하며, 필요하면 SQL 본문을 직접 실행하거나 저수준 DBAPI에 접근할 수도 있어 확장성이 뛰어납니다. 기본적으로 동기식 ORM이지만, 최근 1.4 버전부터 공식적으로 비동기(Async) 지원을 추가했고 2.0에서도 Async ORM을 완전히 지원하게 되어 FastAPI와도 더 잘 맞게 되었습니다
. 따라서 고성능이 요구되는 경우에도 별도 복잡한 설정 없이 SQLAlchemy 자체로 충분한 성능을 낼 수 있습니다.
유지보수와 장기 사용: SQLAlchemy는 2006년 최초 릴리스 이후 꾸준한 업데이트와 방대한 사용자층을 갖춘 매우 성숙한 프로젝트입니다. 현재 GitHub 스타 수가 10k를 넘고 활발한 개발이 이뤄지고 있어 장기적인 유지보수에 대한 신뢰도가 최고입니다
. 또한 Alembic과 같은 공식 마이그레이션 도구와도 연동이 잘 되어 있어, 스키마 변경이나 버전 관리도 체계적으로 할 수 있습니다. 다양한 데이터베이스 지원도 탁월해서 SQLite, PostgreSQL, MySQL 등 대부분의 관계형 DB를 호환하므로, 작은 프로젝트에서 SQLite로 시작해도 나중에 쉽게 PostgreSQL 등으로 확장할 수 있습니다.
▶ SQLModel – SQLAlchemy를 쉽게 활용: FastAPI의 창시자인 Sebastián Ramírez가 만든 SQLModel은 SQLAlchemy와 Pydantic을 결합한 라이브러리로, FastAPI에 최적화된 ORM 사용 경험을 제공하기 위해 등장했습니다
. SQLModel을 사용하면 중복 코드를 최소화하고 하나의 클래스 모델을 API 스키마와 DB 테이블 정의로 함께 활용할 수 있어 개발이 훨씬 간결해집니다
. 예를 들어 Pydantic 모델처럼 보이는 클래스에 table=True 등을 설정하면 곧바로 DB 테이블 모델로 동작합니다. 내부적으로는 SQLAlchemy ORM을 사용하므로 성능과 신뢰성은 SQLAlchemy에 기반하고, Pydantic 검증 덕분에 API 데이터 검증도 자연스럽게 가능합니다. FastAPI 공식에서도 SQLModel을 권장하고 있을 정도로 FastAPI와 궁합이 좋아 장기적으로 전망이 밝습니다
. 다만 SQLModel 자체는 아직 초기 버전(0.x대)이라 간혹 최신 SQLAlchemy 버전과 호환성 문제가 제기되지만(단일 개발자인 FastAPI 저자가 관리하고 있어 업데이트 주기가 완전히 빠르진 않습니다
), 기본 개념이 SQLAlchemy이기에 비교적 안정적으로 사용할 수 있습니다. 1인 개발자 입장에서도 SQLAlchemy의 복잡도를 많이 숨겨주므로 설정이 간편하고, 학습 부담을 크게 낮춰주는 선택지입니다. 결국 SQLAlchemy (또는 SQLModel)을 선택하면 검증된 안정성과 폭넓은 기능을 얻으면서, SQLModel로 인해 개발 편의성도 확보할 수 있습니다.
2. Tortoise ORM – 비동기를 위한 경량 ORM (Django 스타일)
Tortoise ORM은 FastAPI의 비동기 생태계에서 많이 언급되는 ORM으로, 처음부터 asyncio 기반으로 설계된 비교적 신생 ORM입니다. Django ORM과 유사한 문법을 채택하여, Django 경험이 있는 개발자라면 매우 친숙하게 느낄 수 있습니다
. 예를 들어 모델 정의나 쿼리 API가 Django와 닮아있어 직관적이고 짧은 코드로 DB 작업이 가능합니다
. FastAPI는 기본적으로 비동기 웹 프레임워크이므로, Tortoise ORM을 쓰면 쿼리도 비동기로 처리하여 event loop를 막지 않고 높은 동시성 성능을 얻을 수 있다는 장점이 있습니다.
개발자 선호도 측면: Tortoise ORM은 설정과 사용법이 비교적 간단하여 1인 개발자가 쓰기에도 큰 부담이 없습니다. 비동기 ORM이지만 register_tortoise 등의 유틸리티를 제공해 FastAPI 앱에 쉽게 통합할 수 있고, Django처럼 모델 클래스만 정의하면 자동으로 스키마 생성도 가능해 초기 설정이 수월합니다. 문서화도 잘 되어 있고, Django 문법을 차용했기에 학습 곡선이 낮은 편이라 많은 개발자들이 “사용하기 쉽다”는 평가를 합니다
. 특히 Django ORM의 장점을 살리면서도 asyncio에 맞게 설계되었기 때문에, 기존 Django 사용자나 ORM 초보자도 금방 익숙해질 수 있습니다.
성능 및 안정성: Tortoise ORM은 비동기로 구현되었기 때문에 높은 동시 처리 성능을 발휘합니다. 내부적으로 효율적인 쿼리 빌더와 커넥션 풀을 사용하여 대부분의 ORM 연산에서 추가 오버헤드 없이 안정적 속도를 냅니다. 프로젝트 측의 공식 벤치마크에 따르면 읽기/쓰기 성능에서 Python의 다른 ORM들과 비교해 상위권을 차지할 만큼 성능도 우수합니다 (특히 빠른 ORM으로 알려진 Pony ORM과 비슷한 수준으로 겨룰 정도라고 합니다)
. 복잡한 설정 없이도 기본 사용만으로 충분히 빠르며, 비동기 특성을 살려 성능을 끌어올릴 수 있다는 것이 장점입니다. 다만 아직 젊은 프로젝트이기 때문에 일부 고급 기능은 부족할 수 있습니다
. 예를 들어, SQLAlchemy만큼 복잡한 쿼리 조합이나 서브쿼리, 대규모 트랜잭션 처리에 대한 풍부한 옵션은 상대적으로 적을 수 있습니다. 그러나 일반적인 CRUD와 관계 정의, JOIN, 집계 등은 대부분 지원하므로 일반적인 웹 애플리케이션에는 충분합니다.
유지보수와 커뮤니티: Tortoise ORM은 최근 몇 년 사이 빠르게 발전하고 있으며, GitHub 스타 수 약 4~5천 개 수준으로 인지도도 높아졌습니다
. *“깨지는 변경(breaking changes)이 있을 수 있다”*고 문서에 명시되어 있듯이
, 아직 API가 완전히 안정화된 것은 아니지만, 변경 시 Changelog에 안내를 잘 하고 있어서 따라가기 어렵지는 않습니다. 또한 마이그레이션 도구로 Aerich를 제공하여 Django의 migrate처럼 스키마 버전 관리를 지원하고, 지속적으로 개선되고 있습니다. 활발한 유지보수(최근까지 커밋 활발)로 신뢰할 만하지만, 장기간(수년간) SQLAlchemy 만큼 검증된 것은 아니므로 장기 지원 측면에서는 약간의 주의가 필요할 수 있습니다. 그래도 FastAPI 사용자 중 완전한 비동기 환경을 선호하는 개발자들은 Tortoise ORM을 많이 추천하고 있으며
, *“만약 특별한 DB 기능을 쓰지 않는 일반적인 프로젝트라면 Tortoise가 최선의 선택”*이라는 평가도 있습니다
. 실제로 작은 개인 프로젝트에서 시작해서 후에 규모가 커지더라도, Tortoise는 SQLite, PostgreSQL, MySQL 등 여러 DB 백엔드를 지원하므로 확장에 문제없고
, 성능과 사용 편의성의 밸런스가 좋아 충분히 고려할 만한 ORM입니다.
3. Ormar – FastAPI 친화적 신생 ORM (경량 async + Pydantic)
Ormar는 비교적 최신 ORM으로, “FastAPI를 염두에 두고 만들어진” 비동기 ORM입니다
. Ormar의 가장 큰 특징은 Pydantic 모델과 ORM 모델을 하나로 통합했다는 점입니다. 다시 말해, 하나의 모델 클래스 정의로 API 데이터 검증용 스키마와 DB 매핑을 모두 처리할 수 있기 때문에 개발자가 두 번 일할 필요가 없습니다
. FastAPI에서는 보통 Pydantic 모델과 ORM 모델을 따로 정의하고 변환하는 작업이 필요한데, Ormar를 쓰면 그 과정이 자연스럽게 단순화되어 생산성이 높아집니다. 1인 개발자에게 이러한 이점은 매우 크며, 코드 중복 감소와 유지보수 용이성 측면에서 환영받고 있습니다
.
개발자 선호도 측면: Ormar는 문법이 직관적이고 경량이라 소규모 프로젝트에 잘 맞습니다. 모델을 정의할 때 Pydantic의 타입 힌트와 필드 유효성 검사를 그대로 활용하면서, behind the scenes에서는 SQLAlchemy Core를 통해 쿼리를 구성합니다
. 설정도 비교적 간단해서, 데이터베이스 URL과 metadata 등을 지정한 ModelMeta를 상속받고 몇 가지 필드 타입을 Ormar에서 제공하는 것으로 선언하면 끝입니다
. 이러한 간편함 때문에 **“번거롭지 않다”**는 평을 듣고, FastAPI와 함께 사용할 때 개발 속도를 높여주는 도구로 선호됩니다. 또한 Ormar는 Alembic으로 마이그레이션을 지원합니다 (내부적으로 SQLAlchemy를 사용하므로 Alembic 연동이 가능)
. 다만 Ormar 자체가 비교적 새로운 ORM이어서 커뮤니티 규모나 자료는 아직 한정적입니다. 주요 기여자도 많지는 않아 버그 대응 속도가 대형 프로젝트만큼 빠르진 않을 수 있지만, FastAPI 생태계의 일부로 여겨져 관련 라이브러리(FastAPI Users, CRUDRouter 등)에서 Ormar를 지원하려는 움직임도 있습니다
. 유지보수도 꾸준히 이뤄지고 있으며, 2021년 공개 이후 현재까지 업데이트가 이어지고 있어 장기 사용에 큰 문제가 없도록 개선되고 있습니다.
성능 및 특징: Ormar는 비동기 ORM으로서, 내부적으로 SQLAlchemy의 Core를 사용해 SQL문을 구성하고 encode/databases 패키지를 통해 비동기 DB 연산을 수행합니다
. 덕분에 지원하는 DB도 SQLite, PostgreSQL, MySQL 등 주요 RDB들을 커버하고 있으며
, 동시성 성능도 SQLAlchemy Core의 검증된 최적화 덕분에 꽤 안정적입니다. 고성능을 위해 특별히 튜닝할 사항도 거의 없고 기본 설정으로도 충분히 빠르게 동작합니다. Ormar가 목표로 하는 바가 “간단하면서도 실용적인 ORM”이기 때문에 기능 면에서는 매우 복잡한 쿼리보다는 일반적인 사용에 필요한 기능에 집중되어 있습니다. 예를 들어 대부분의 CRUD, 관계 설정(일대다, 다대다), JOIN, Pydantic 모델 자동 생성 등의 기능은 쉽게 사용할 수 있으나, 복잡한 다중 서브쿼리나 커스텀 SQL 작성은 SQLAlchemy에 비해 직접 지원이 부족할 수 있습니다. 하지만 이러한 부분도 ORM 모델에서 .queryset 등을 통해 SQLAlchemy나 SQL 표현식을 직접 사용할 수 있기 때문에 어느 정도 보완이 가능합니다.
개인 프로젝트에서 확장성: Ormar는 작은 프로젝트에서 빠른 개발 사이클을 가능케 해주고, 프로젝트가 커질 때도 무리 없이 확장할 수 있다는 점에서 주목받습니다. 처음에는 SQLite 파일 DB로 시작했다가도, 나중에 설정만 바꾸면 PostgreSQL 등으로 이전할 수 있고 Ormar 자체가 SQLAlchemy 기반이라 ORM 교체 없이 DB 교체가 용이합니다. 다만 정말 대규모 프로젝트로 발전하게 되면, Ormar의 한계(예: 복잡한 트랜잭션 로직이나 대량 데이터 마이그레이션 시 최적화 부족 등)가 있을 수 있으므로, 그 단계에서는 SQLAlchemy로의 전환도 비교적 수월하다는 점을 알고 있어야 합니다. (실제로 Ormar 깃허브에는 SQLAlchemy 모델을 Ormar 모델로 변환해주는 도구까지 제공되어 있어 상호 이동을 돕고 있습니다
.) 전반적으로 Ormar에 대한 개발자들의 평은 *“FastAPI와 잘 맞고 사용하기 편하다”*는 긍정적인 반응이 많으며, 1인 개발자가 빠르게 API + DB를 구성하려고 할 때 유용한 ORM으로 자리잡고 있습니다.
※ 기타: 이 밖에도 Peewee ORM을 사용하는 경우도 있습니다. Peewee는 10년 넘게 유지되어 온 경량 ORM으로, SQLite/PostgreSQL 등 주요 DB를 지원하고 API가 매우 단순해 소규모 프로젝트에서 사랑받아 왔습니다. 실제 GitHub 스타도 1만 이상으로 SQLAlchemy 못지않게 많을 정도로 인기가 있는 ORM입니다
. 1인 개발자에게 특히 친숙한 ORM인데, 설정도 거의 필요 없고 Python 객체지향 문법으로 쉽게 쿼리를 작성할 수 있습니다. 다만 Peewee는 기본적으로 동기식 ORM이므로 FastAPI의 async 함수 내에서 직접 사용하면 이벤트 루프를 블로킹하게 됩니다. 이를 해결하려면 peewee_aio 같은 서드파티로 비동기 패치를 하거나, 또는 FastAPI의 BackgroundTask나 별도 스레드 풀로 Peewee 연산을 처리해야 하는데, 이러한 점 때문에 FastAPI와 100% 어울린다고 보기는 어렵습니다
. Peewee의 메인 개발자도 Python의 asyncio 방식을 선호하지 않아 공식 async 지원은 하지 않는 입장이라(이와 관련한 개선 요청도 거절된 바 있습니다
), FastAPI의 고성능 async 철학과 맞지 않을 수 있습니다. 따라서 정말 간단한 개인 프로젝트(동시 접속이 많지 않고 DB I/O가 병목이 아닌 경우)에서는 Peewee도 고려 가능하지만, 향후 서비스를 확장할 계획이 있다면 앞서 언급한 SQLAlchemy/SQLModel, Tortoise, Ormar 같은 현대적인 ORM을 쓰는 편이 좋습니다.
작은 프로젝트부터 중소형 웹앱까지 – 가장 적합한 ORM은?
요약하면, SQLAlchemy (또는 SQLModel), Tortoise ORM, Ormar 세 가지가 FastAPI 환경에서 많이 쓰이고 권장되는 ORM입니다. 각각 장단점이 있지만, 가장 적합한 ORM을 한 가지 추천해야 한다면 SQLAlchemy/SQLModel 조합을 꼽을 수 있습니다. 그 이유는 다음과 같습니다:
- 넓은 적용 사례와 신뢰성: SQLAlchemy는 검증된 ORM으로 작은 앱부터 대규모 서비스까지 활용 사례가 풍부합니다. 덕분에 문제 해결 정보나 레퍼런스가 많고, 장기적으로 봐도 유지보수나 커뮤니티 지원이 가장 탄탄합니다. 혼자 개발할 때도 막히는 부분을 구글링하면 해답을 얻을 가능성이 높습니다.
- jianshu.com
- 확장성과 기능성: 프로젝트가 커지면서 복잡한 요구사항이 생길 경우, SQLAlchemy만큼 그 요구에 유연하게 대응해줄 ORM은 없습니다. 고급 쿼리, 최적화, 복잡한 관계 맵핑, 트랜잭션 제어 등 뭐 하나 부족함 없이 갖춰져 있어 미래의 요구사항까지 대비할 수 있습니다. 초기엔 단순하게 쓰다가도, 필요하면 세부 튜닝이나 기능 활용을 할 수 있는 여지가 많습니다.
- 성능과 안정: 앞서 언급했듯 SQLAlchemy는 고성능을 낼 수 있도록 설계되었고, 최신 버전에서는 Async 지원까지 공식화되었으므로 FastAPI의 비동기 성능도 활용할 수 있습니다. 또한 수년간 다듬어진 프로젝트라 버그나 예외 케이스도 많이 정리되어 안정적으로 동작합니다. 메모리 관리나 DB 세션 관리 등에서도 최적화가 잘 되어 있어 규모가 커져도 무난히 견딜 수 있습니다.
- pedaldrivenprogramming.com
- SQLModel의 사용 편의성: 1인 개발자의 생산성 측면에서, SQLAlchemy 단독으로 쓰는 것이 어렵게 느껴진다면 SQLModel을 적극 활용하면 됩니다. SQLModel 덕분에 설정이 간편해지고, Pydantic 기반으로 한 층 추상화가 이루어지므로 다른 경량 ORM 못지않게 개발 속도를 높일 수 있습니다 . 즉, SQLAlchemy의 강력함을 누리면서도 Ormar처럼 하나의 모델로 API와 DB를 모두 다룰 수 있는 편의를 가져갈 수 있습니다. 실제로 FastAPI 공식 튜토리얼에서도 점차 SQLModel 사용 예제가 늘고 있어, 향후 사실상의 기본 ORM처럼 자리잡을 가능성도 있습니다.
- github.com
반면 Tortoise ORM은 완전한 비동기 환경을 선호하고 Django 스타일을 좋아하는 경우 좋은 선택입니다. 초반 개발 속도와 심플함은 SQLAlchemy보다 나을 수 있으며
, 일반적인 요구사항에서는 문제없이 동작합니다. Ormar 역시 작은 프로젝트에 최적화되어 시작이 쉽고 Pydantic 연계가 강력하여, 만약 SQLModel보다 더 가벼운 대안을 찾는다면 고려할 만합니다. 다만 두 ORM 모두 프로젝트 규모가 커질수록 SQLAlchemy만큼의 범용성에서 한계를 느낄 수 있으므로, 장기적인 안정성까지 생각하면 결국 SQLAlchemy로의 회귀 가능성이 있습니다. 따라서 작은 개인 프로젝트에서 출발하지만 중소형, 더 나아가 대형으로 확장될 여지를 염두에 둔다면, **가장 무난하고 검증된 SQLAlchemy (SQLModel과 함께)**를 사용하는 것을 추천합니다. FastAPI 제작자도 해당 조합을 강력히 밀고 있고, 커뮤니티에서도 표준으로 여기고 있기 때문에 학습해둘 가치가 충분합니다
.
결론: FastAPI + SQLAlchemy(SQLModel) 조합은 설정의 편리함, 높은 성능, 안정적인 동작과 활발한 유지보수 측면에서 균형 잡힌 선택입니다. 1인 개발자가 다루기에도 SQLModel 덕분에 수월하고, 추후 서비스를 확장해도 ORM을 갈아엎을 필요 없이 대응할 수 있을 것입니다. 필요에 따라 Tortoise ORM이나 Ormar 같은 대안도 상황에 맞게 활용할 수 있겠지만, 장기적으로 안심하고 쓸 수 있는 1순위 ORM은 여전히 SQLAlchemy 계열이라고 정리할 수 있습니다.
'AI 제품개발' 카테고리의 다른 글
| 1인 개발의 꿈을 이루는 AI 코딩 도구 비교: Cursor vs. Windsurf (0) | 2025.03.12 |
|---|---|
| AI코딩도구 비교해보기(cursor, windsurf, bolt.new, v0.dev) (0) | 2025.03.12 |
| 프롬프트 엔지니어링, 어떻게 하는 건데 (0) | 2024.06.10 |
| 개발자를 위한 ChatGPT 프롬프트 엔지니어링 - 1편 (0) | 2023.05.02 |
댓글