[PyCon Korea 2026] "FastAPI로 그게 됩니까?" — 됩니다 부제: 엔터프라이즈 백엔드를 지탱하는 모듈러 모놀리스 1년 회고 - 윤상현

“Isn’t FastAPI only useful when you need to build a small API quickly?” Many of you have probably heard—or asked—this question before. Large systems with dozens of domains and multiple architectural layers are commonly assumed to require Spring or NestJS. I believed the same thing and originally built our main backend with NestJS.

This talk is a record of one year spent answering that question with measurements rather than assumptions. As a solo CTO, I had been operating a polyglot MSA built with NestJS and FastAPI, consisting of six repositories, nine deployment units, and four databases. I then migrated the entire system to a FastAPI modular monolith built on a uv workspace, comprising 25 packages, 102 tables, and approximately 100,000 lines of code, and operated it in production.

The session covers the following topics:

Translating NestJS into Python — Using comparisons from real production code, I will show how Spring-style concepts such as @Module, dependency-injection containers, class-validator, and TypeORM map to Python imports, Depends, Pydantic, and SQLAlchemy 2.0. We will begin with a “translation dictionary,” so no prior NestJS experience is required.

Anatomy of a modular monolith — We will examine how uv workspaces define module boundaries, how domain and application packages are separated, and how request-scoped transactions and OpenAPI contracts—including CI drift gates and frontend code generation—turn collaboration rules into machine-verifiable checks.

Every figure and code example in this talk comes from a production codebase. By the end, I hope to demonstrate that the Python ecosystem of 2026—including uv, the Python 3.12 type system, FastAPI, and Pydantic v2—can support the full vocabulary of enterprise architecture. In other words, building a large system with Python no longer has to be intimidating.

This talk will be particularly useful for people considering a large Python system, evaluating a migration from Spring or NestJS to Python, or carrying the weight of architecture alone on a small team.

---

"FastAPI는 API 하나 빠르게 만들 때나 쓰는 것 아닌가요?" — 아마 많은 분들이 한 번쯤 들어보셨거나, 스스로 해보셨을 질문입니다. 수십 개의 도메인과 여러 계층을 가진 대규모 시스템은 Spring이나 NestJS로 짓는 것이 정설처럼 여겨져 왔고, 저 역시 그 정설을 믿고 메인 백엔드를 NestJS로 지었던 사람입니다.

이 발표는 그 질문에 통념이 아니라 실측으로 답해 본 1년의 기록입니다. NestJS와 FastAPI가 섞인 폴리글랏 MSA(저장소 6개, 배포 유닛 9개, 데이터베이스 4개)를 혼자 운영하던 1인 CTO가, uv workspace 기반의 FastAPI 모듈러 모놀리스(패키지 25개, 테이블 102개, 총 10만여 줄)로 시스템 전체를 이전하고 프로덕션에서 운영해 온 과정을 다룹니다.

다음과 같은 내용을 나눕니다.

NestJS를 파이썬으로 번역하기 — @Module과 DI 컨테이너, class-validator, TypeORM 같은 Spring 스타일 개념들이 파이썬의 import, Depends, Pydantic, SQLAlchemy 2.0으로 각각 어떻게 옮겨지는지, 실제 프로덕션 코드 비교로 보여드립니다. NestJS를 모르셔도 따라올 수 있도록 '번역 사전'부터 시작합니다.
모듈러 모놀리스의 해부 — uv workspace로 모듈 경계를 긋고, 도메인 패키지와 앱 패키지를 분리하고, 요청 단위 트랜잭션과 OpenAPI 계약(CI 드리프트 게이트 + 프론트엔드 codegen)으로 협업을 기계 검증으로 바꾼 구조를 해부합니다.
모든 수치와 코드는 실제 운영 중인 코드베이스에서 실측한 것입니다. 발표의 끝에서는 2026년의 파이썬 생태계 — uv, Python 3.12의 타입 시스템, FastAPI와 Pydantic v2 — 가 엔터프라이즈 설계의 어휘를 전부 받아낼 수 있게 되었다는 것, 그러니 이제 겁먹지 않으셔도 된다는 이야기를 드리려 합니다.

파이썬으로 큰 시스템을 짓는 것을 고민 중인 분, Spring/NestJS에서 파이썬으로의 이전을 검토 중인 분, 그리고 작은 팀에서 아키텍처의 무게를 혼자 감당하고 계신 분께 특히 도움이 될 것입니다.

---

sxngt

I am the CTO of Yeirin Social Cooperative and CEO of Yeirin Co., Ltd. Under the mission “Reimagining Care Through Technology,” I lead the development organization responsible for designing and operating the backend of a care platform for children from underserved communities.

I migrated a system that began as a NestJS-based MSA to a FastAPI modular monolith, exploring how a small organization can manage a large architecture. I consider “peace of mind on a Friday night” a more meaningful measure of architectural quality than performance metrics alone. I work at the intersection of development and research and enjoy documenting the hard lessons learned along the way.

---

윤상현 (sxngt)

예이린 사회적협동조합 CTO이자 (주)예이린 대표이사. "기술로 돌봄을 새롭게"라는 미션 아래, 취약계층 아동을 위한 돌봄 플랫폼의 백엔드를 설계하고 운영하는 개발 조직의 기술 책임자입니다.

NestJS 기반 MSA로 시작한 시스템을 FastAPI 모듈러 모놀리스로 이전하며, 작은 조직이 큰 아키텍처를 감당하는 법에 대해 고민해 왔습니다. 성능 지표보다 "금요일 밤의 평온"을 아키텍처 품질의 척도로 삼습니다. 개발과 연구의 경계에서 일하며, 겪은 삽질을 기록으로 남기는 일을 좋아합니다.