개발 이야기/개발 및 서비스

PyNest vs FastAPI

가온아 2025. 6. 13. 09:00

최근 고도화 프로젝트에 투입했는데  PyNest로 만든 프로젝트가 있어서 그대로 쓸까 새로 만들까 고민하면 찾아본 내용이라 공유합니다. :)  제 결론은 ... 

확장 가능한 API 개발을 위한 PyNest와 FastAPI 평가: 비교 분석

요약

본 보고서는 PyNest와 FastAPI(라우트-서비스 패턴 구현)를 비교 분석하여 아키텍처 접근 방식, 개발 경험, 유지보수성, 확장성 측면을 다룹니다. FastAPI는 API 구축을 위한 유연하고 고성능의 기반을 제공하는 반면, PyNest는 FastAPI 위에 NestJS에서 영감을 받은 보다 정형화된 구조를 제공하여 특히 데이터 중심 애플리케이션의 개발을 간소화하는 것을 목표로 합니다. 사용자가 PyNest의 업데이트 빈도에 대해 제기한 우려("업데이트도 거의 6개월 전 코드가 마지막이던데..")는 최근 릴리스(2024년 12월 19일 v0.3.2) 및 활발한 이슈 추적 활동으로 미루어 볼 때 대체로 근거가 없는 것으로 판단됩니다. 이 둘 중 선택은 아키텍처 강제성 대 유연성 중 어느 것을 선호하는지, 그리고 빠르게 진화하지만 아직 성숙 단계에 있는 추상화 계층에 대한 프로젝트의 장기적인 의존성에 따라 달라집니다.

1. 서론

현대 파이썬 API 개발 환경에서 프레임워크 선택은 매우 중요한 결정입니다. 장고(Django)와 같은 포괄적인 풀스택 솔루션부터 플라스크(Flask)와 같은 미니멀리스트 마이크로프레임워크, 그리고 FastAPI와 같은 현대적인 비동기 프레임워크에 이르기까지 다양한 선택지가 존재합니다. 프레임워크 선택은 개발 속도, 코드 유지보수성, 그리고 궁극적으로 애플리케이션의 확장성에 지대한 영향을 미칩니다.

현재 사용자는 PyNest를 계속 사용할지, 아니면 FastAPI를 사용하여 "라우트-서비스" 아키텍처 패턴을 직접 구현하는 방식으로 전환할지 고민하는 중요한 결정의 기로에 서 있습니다. 이러한 평가는 정형화되고 구조화된 프레임워크가 제공하는 이점과 기반 툴킷의 본질적인 유연성 및 광범위한 커뮤니티 지원을 신중하게 저울질해야 합니다. 특히 사용자는 PyNest의 업데이트 빈도에 대해 "업데이트도 거의 6개월 전 코드가 마지막이던데.."라고 언급하며 우려를 표명했습니다.

본 보고서는 사용자가 정보에 입각한 전략적인 기술 결정을 내릴 수 있도록 필요한 통찰력을 제공하는 것을 목표로 합니다. PyNest와 라우트-서비스 패턴을 구현한 FastAPI 애플리케이션의 아키텍처 패턴, 개발자 경험, 유지보수성 및 확장성에 대한 영향, 그리고 프레임워크의 성숙도 및 커뮤니티 지원에 대한 비판적인 평가에 중점을 둘 것입니다.

2. FastAPI: 고성능 기반

FastAPI는 현대적이고 고성능의 파이썬 웹 프레임워크로, 경량 ASGI(Asynchronous Server Gateway Interface) 프레임워크인 Starlette과 강력한 데이터 유효성 검사 라이브러리인 Pydantic을 기반으로 구축되었습니다. 이러한 강력한 기반 아키텍처 덕분에 FastAPI는 파이썬에서 가장 빠른 프레임워크 중 하나로 자리매김했으며, Node.js 애플리케이션과 유사한 성능을 제공합니다.  

 
  • 핵심 기능 및 장점:
    • 속도 및 성능: FastAPI는 뛰어난 성능을 위해 설계되었으며, 간단한 엔드포인트의 경우 유사한 하드웨어에서 초당 15,000~20,000개의 요청을 처리할 수 있음을 벤치마크에서 지속적으로 보여줍니다. 이러한 높은 처리량은 주로 파이썬의 async/await 구문을 통한 비동기 프로그래밍에 대한 기본 지원 덕분입니다. 이는 I/O 바운드 작업(예: 데이터베이스 쿼리, 외부 API 호출)을 효율적으로 처리하여 높은 동시성을 달성하는 데 필수적입니다.  
       
    • 자동 데이터 유효성 검사 및 타입 힌트: FastAPI는 파이썬의 타입 힌트와 Pydantic을 통합하여 개발을 크게 간소화합니다. 이 통합은 들어오는 요청 본문, 쿼리 매개변수, 경로 매개변수 및 헤더에 대한 자동 데이터 유효성 검사, 직렬화 및 역직렬화를 가능하게 합니다. 이 기능은 필요한 상용구 코드의 양을 줄이고, 유효성 검사가 라우트 정의에 직접 통합되므로 일반적인 데이터 관련 오류를 사전에 방지하는 데 도움이 됩니다. 타입 힌트는 유효성 검사, 문서화, 편집기 지원이라는 세 가지 역할을 수행하여 코드의 견고성과 개발자 경험을 향상시킵니다.  
       
    • 자동 API 문서화: FastAPI의 가장 높이 평가되는 기능 중 하나는 대화형 API 문서를 자동으로 생성하는 기능입니다. 일반적으로 /docs(Swagger UI) 및 /redoc(ReDoc)에서 액세스할 수 있는 이 문서는 애플리케이션 코드에서 직접 파생되며 OpenAPI 및 JSON Schema 표준을 준수합니다. 이 내장 기능은 API의 발견 가능성, 사용성 및 장기적인 유지보수성을 크게 향상시켜 문서가 항상 코드와 동기화되도록 보장합니다.  
       
    • 비동기 지원: FastAPI는 async/await 구문을 기본적으로 지원하도록 구축되어, 많은 동시 요청을 효율적으로 처리하고 I/O 바운드 작업을 관리할 수 있는 확장 가능한 API를 구축하는 데 도움이 됩니다.  
       
    • 운영 환경 준비 완료 기능: FastAPI는 CORS(Cross-Origin Resource Sharing), 요청/응답 파싱, 백그라운드 작업, WebSockets 등 실제 사용을 위한 기능을 제공합니다. 또한 Uvicorn과 같은 ASGI 서버를 사용하여 FastAPI로 생성된 API를 쉽게 운영 환경에 배포할 수 있습니다.  
       
  • 아키텍처 유연성: FastAPI는 풀스택 프레임워크라기보다는 "마이크로프레임워크" 철학을 핵심으로 합니다. 이는 최소한의 구조를 제공하면서도 높은 확장성을 허용하여 개발자가 엄격한 제약 없이 의도적인 아키텍처 선택을 할 수 있도록 합니다. FastAPI는 단일하고 엄격한 프로젝트 구조를 강제하지 않지만, APIRouter와 강력한 의존성 주입(Dependency Injection) 시스템과 같은 강력한 기본 요소를 제공하여 잘 조직되고 모듈화된 애플리케이션을 구축할 수 있도록 지원합니다. 이러한 유연성은 개발자가 프로젝트의 특정 요구 사항에 맞춰 라우트-서비스 패턴과 같은 다양한 아키텍처 패턴을 구현할 수 있도록 합니다.   FastAPI의 유연성은 강력하지만, 아키텍처 설계와 일관성을 유지하는 책임이 개발 팀에게 있다는 의미이기도 합니다. 이는 프레임워크가 미리 정의된 구조를 제공하는 PyNest와 같은 도구와는 대조적인 지점입니다. FastAPI는 파이썬의 타입 힌트와 Pydantic을 데이터 모델링 및 유효성 검사에 기본적으로 의존합니다. 이러한 의존성은 프레임워크 수준에서 특정 아키텍처 패턴을 명시적으로 강제하지 않더라도, 잘 작성된 FastAPI 코드가 자연스럽게 명확한 데이터 계약, 명시적인 입력/출력 정의 및 구조화된 의존성으로 향하도록 유도합니다. 즉, 타입 힌트가 함수 매개변수(입력) 및 반환 값(출력)에 일관되게 적용되고 Pydantic 모델이 데이터 구조에 사용되면, 애플리케이션의 다른 부분(예: 라우터와 서비스 함수, 서비스 함수와 데이터베이스 작업 간) 간의 "계약"이 명시적으로 정의됩니다. 이러한 명확성은 각 논리적 단위에 대한 명확한 입력과 출력을 고려하도록 개발자를 장려하므로, 자연스럽게 관심사의 구조화된 분리로 이어집니다. 결과적으로, 프레임워크가 서비스 클래를 명시적으로 강제하지 않더라도, FastAPI 애플리케이션을 구축하는 개발자는 비즈니스 로직에 대한 잘 정의된 인터페이스를 타입 힌트 및 유효성 검사 시스템이 권장하기 때문에 "서비스" 역할을 하는 함수나 클래스를 생성할 가능성이 높습니다. 이러한 특징은 언어 기능을 통한 아키텍처 지침의 강력한 형태이며, 엄격한 프레임워크 강제성보다는 유기적으로 조직화되고 유지보수 가능한 코드베이스를 조성합니다.  
  •  
  •  

3. FastAPI에서 라우트-서비스 패턴 구현

대규모의 복잡한 FastAPI 애플리케이션을 개발할 때, 코드를 별도의 모듈 또는 "패키지"로 구성하는 것이 널리 채택되고 강력히 권장되는 방식입니다. 이러한 모듈은 일반적으로 프로젝트 루트의 src/ 디렉토리 내에 위치합니다. 이러한 모듈식 접근 방식은 관심사의 명확한 분리를 촉진하고, 코드 가독성을 높이며, 장기적인 유지보수성을 크게 향상시키는 데 필수적입니다.  

 
  • 패턴 구현을 위한 프로젝트 구조 모범 사례: 이러한 모듈식 구조 내에서 각 도메인 또는 기능(예: users, products, auth)은 일반적으로 해당 도메인의 특정 측면을 담당하는 전용 디렉토리를 가집니다. 일반적인 구성은 다음과 같습니다:
    • router.py: 이 파일은 API 엔드포인트를 정의하고 모듈의 HTTP 요청 및 응답 수명 주기를 관리하는 데 전념합니다.  
       
    • schemas.py: Pydantic 모델을 정의하는 데 사용되는 파일입니다. 이 모델은 들어오는 데이터의 유효성 검사 및 변환에 중요합니다.  
       
    • models.py: 데이터베이스 모델(예: SQLAlchemy ORM 정의)을 위한 파일로, 지속성 계층에 저장된 데이터 구조를 나타냅니다.  
       
    • service.py: 이 중요한 파일은 모듈별 비즈니스 로직을 캡슐화합니다. 컨트롤러/라우터와 데이터 모델 간의 상호 작용을 관리하는 오케스트레이션 계층 역할을 합니다. 서비스 계층은 복잡한 작업을 실행하고, 비즈니스 규칙을 적용하며, 직접적인 데이터베이스 상호 작용을 처리합니다.  
       
    • dependencies.py: 재사용 가능한 의존성 함수를 정의하는 데 사용되는 파일입니다. 이러한 함수는 인증, 권한 부여 또는 일반적인 데이터 가져오기 작업과 같은 교차 관심사를 처리할 수 있으며, 코드 중복을 피하기 위해 라우트에 주입됩니다.  
       
    • constants.py(모듈별 상수), config.py(구성), utils.py(비즈니스 로직이 아닌 도우미 함수), exceptions.py(모듈별 사용자 정의 예외)와 같은 추가 파일은 잘 조직되고 자체 포함된 모듈을 만드는 데 기여합니다.  
       
  • 모듈화를 위한 APIRouter 활용: FastAPI의 APIRouter는 경로 작업을 개별적이고 재사용 가능한 모듈로 구조화하고 구성하는 데 없어서는 안 될 도구입니다. 각 APIRouter 인스턴스는 자체 URL 접두사, 문서화를 위한 태그 목록, 사용자 정의 응답 스키마, 심지어 해당 라우터에 정의된 모든 경로 작업에 적용될 의존성 세트로 구성할 수 있습니다. 이 강력한 기능은 명확한 관심사 분리를 가능하게 하여 단일하고 거대한 main.py 파일이 다루기 힘들게 되는 것을 방지합니다.  
  •  
  • 의존성 주입을 위한 Depends 활용: Depends 메커니즘은 FastAPI의 매우 효과적인 의존성 주입 시스템의 초석입니다. 이를 통해 모든 함수나 클래스가 필요한 의존성을 선언할 수 있으며, FastAPI는 런타임에 이를 자동으로 해결하고 제공합니다. 이는 향상된 테스트 용이성, 코드 재사용성 증가, 애플리케이션 전반에 걸쳐 데이터 및 논리의 명확하고 예측 가능한 흐름과 같은 여러 주요 소프트웨어 엔지니어링 원칙을 촉진합니다. 의존성은 다양한 세분성으로 적용될 수 있습니다: 주 FastAPI 애플리케이션 인스턴스에 전역적으로, APIRouter가 포함될 때 특정 APIRouter에, 또는 개별 경로 작업에 적용될 수 있습니다. FastAPI는 이러한 의존성에 대한 명확한 실행 순서를 유지하여 예측 가능한 동작을 보장합니다.  
  •  
  • 일반적인 FastAPI 라우트-서비스 흐름의 예시: 흐름은 일반적으로 router.py 파일 내에 정의된 엔드포인트가 들어오는 HTTP 요청을 수신할 때 시작됩니다. 이 엔드포인트 내에서 FastAPI의 Depends 시스템은 종종 service(일반적으로 service.py에 정의됨) 인스턴스를 주입하는 데 활용됩니다. 이 주입은 비즈니스 로직을 라우팅 계층에서 쉽게 사용할 수 있도록 합니다. 그런 다음 엔드포인트는 주입된 service 인스턴스의 메서드를 호출하여 필요한 비즈니스 로직을 실행합니다. 이 서비스 메서드는 차례로 models.py를 통해 데이터베이스와 상호 작용하여(예: SQLAlchemy와 같은 ORM 사용) 데이터를 검색, 저장 또는 조작할 수 있습니다. 이 과정 전반에 걸쳐 데이터는 schemas.py에 정의된 Pydantic 모델을 사용하여 들어오는 요청 데이터와 나가는 응답 데이터 모두에 대해 엄격하게 유효성 검사가 수행됩니다. 마지막으로, router는 서비스로부터 처리된 데이터를 수신하고 클라이언트에 다시 보낼 적절한 HTTP 응답을 구성합니다.
     
  • FastAPI 모범 사례에서 종종 권장되는 "SQL-first, Pydantic-second" 철학 은 특히 데이터 집약적인 API의 애플리케이션 성능을 위한 전략적 최적화를 나타냅니다. 복잡한 데이터 조작, 집계 및 조인을 SQL을 통해 데이터베이스 계층으로 의도적으로 푸시함으로써, 개발자는 데이터베이스 시스템의 본질적인 효율성을 활용할 수 있습니다. 데이터베이스 시스템은 일반적으로 이러한 작업에 대해 파이썬보다 훨씬 뛰어난 성능을 보입니다. 이는 단순히 구조적 지침이 아니라 애플리케이션의 응답성과 확장성에 상당한 영향을 미칠 수 있는 중요한 성능 중심의 아키텍처 결정이며, 특히 대규모 데이터 세트 또는 복잡한 쿼리를 처리할 때 더욱 그렇습니다.  

4. PyNest: FastAPI 기반의 정형화된 프레임워크

PyNest는 FastAPI 위에 구축된 파이썬 프레임워크로 , NestJS의 모듈식 아키텍처를 따릅니다. 이 프레임워크의 핵심 설계 철학은 API를 직관적이고 이해하기 쉬우며 즐거운 방식으로 구조화하여 확장 가능하고 유지보수 가능한 애플리케이션을 쉽게 구축할 수 있도록 돕는 것입니다. PyNest는 NestJS를 파이썬으로 직접 포팅한 것이 아니라, 파이썬 개발자, 특히 데이터 과학자, 데이터 분석가, 데이터 엔지니어를 위해 프레임워크를 "재해석"한 것입니다. 이는 이들이 데이터 애플리케이션을 위한 더 좋고 빠른 API를 구축하는 데 도움을 주는 것을 목표로 합니다.  

 
  • 핵심 기능:
    • 모듈식 아키텍처: PyNest는 NestJS의 모듈식 아키텍처를 엄격하게 따르며, 각 모듈은 컨트롤러, 서비스, 프로바이더와 같은 관련 구성 요소의 응집력 있는 컬렉션을 캡슐화하도록 설계되었습니다. 이러한 아키텍처 강제성은 관심사의 명확한 분리와 고도로 조직화된 코드베이스를 촉진하는 핵심 원칙입니다.  
       
    • 의존성 주입 (DI): 이 프레임워크는 의존성을 효과적으로 관리하고 고도로 테스트 가능한 코드를 작성하는 데 필수적인 의존성 주입에 대한 포괄적인 지원을 제공합니다. 데코레이터 기반 접근 방식을 사용하여 서비스와 프로바이더를 컨트롤러 및 기타 구성 요소에 원활하게 주입할 수 있습니다.  
       
    • 데코레이터: PyNest는 라우트, 미들웨어 및 기타 애플리케이션 구성 요소를 정의하는 주요 메커니즘으로 데코레이터(예: @Module, @Controller, @Injectable, @Get)를 광범위하게 사용합니다. 이러한 데코레이터 중심 접근 방식은 코드의 간결성과 가독성에 크게 기여합니다.  
       
    • 타입 힌트: 최신 파이썬 관행과 FastAPI에서 상속받은 PyNest는 파이썬의 타입 힌트를 완전히 활용합니다. 이는 더 나은 툴링 지원을 제공하고 코드 명확성을 향상시키며 강력한 타입 검사를 통해 일반적인 오류를 방지하여 코드베이스를 더욱 견고하게 만듭니다.  
       
    • 코드 생성: PyNest에는 모듈, 컨트롤러 및 기타 구성 요소에 대한 상용구 코드를 생성할 수 있는 명령줄 인터페이스(CLI) 도구가 포함되어 있습니다. 이 기능은 수동 설정 시간을 크게 줄여 개발자가 핵심 비즈니스 로직 작성에 더 집중할 수 있도록 합니다. CLI 명령의 예로는 새 애플리케이션을 생성하는 pynest generate application과 새 모듈을 생성하는 pynest generate resource가 있습니다.  
       
  • PyNest의 강제 라우트-서비스 구현: PyNest의 설계는 라우트-서비스 패턴을 구현하기 위한 특정하고 정형화된 구조를 본질적으로 강제합니다. 이 구조는 주로 Module, Controller, Service와 같은 핵심 구성 요소를 통해 강제되며, 이들은 모두 전용 데코레이터를 사용하여 정의됩니다.  
    • AppModule (src/app_module.py): 이는 애플리케이션의 루트 모듈 역할을 합니다. @Module 데코레이터를 사용하여 선언되며, 논리적으로 해당 모듈에 속하는 controllers와 providers(서비스)를 명시적으로 집계합니다. PyNestFactory.create() 함수는 이 루트 모듈을 기본 구성으로 사용하여 전체 PyNest 애플리케이션을 초기화하는 진입점입니다.  
       
    • AppService (src/app_service.py): 이 파일은 특정 도메인에 대한 핵심 비즈니스 로직 및 데이터 조작 작업을 포함하도록 지정됩니다. @Injectable 데코레이터로 표시되며, PyNest의 의존성 주입 시스템에 이 클래스가 애플리케이션의 다른 부분(예: 컨트롤러)에 인스턴스화되어 주입될 수 있음을 알립니다.  
       
    • AppController (src/app_controller.py): 이 구성 요소는 들어오는 HTTP 요청을 처리하고, 라우트를 정의하며, 응답을 준비하는 역할을 합니다. @Controller로 데코레이트되며, 해당 라우트의 기본 경로를 지정합니다. 생성자에서 의존성 주입을 통해 필요한 서비스 인스턴스(예: __init__(self, service: AppService))를 수신합니다. 엔드포인트는 @Get과 같은 HTTP 메서드별 데코레이터를 사용하여 정의됩니다.  
       
    • main.py: 이 파일은 PyNest 애플리케이션을 실행하기 위한 기본 진입점 역할을 합니다. 일반적으로 주 모듈에서 http_server 인스턴스를 가져와 Uvicorn과 같은 ASGI 서버를 사용하여 애플리케이션을 시작합니다.  
       
    PyNest의 명시적인 "재해석"은 파이썬 개발자, 특히 데이터 과학자, 데이터 분석가, 데이터 엔지니어를 대상으로 한다는 점에서 시장에서의 의도적인 전략적 포지셔닝을 시사합니다. 이는 프레임워크의 고도로 정형화된 구조와 코드 생성 기능이 데이터 과학이나 분석에는 깊은 전문 지식을 가지고 있지만, 견고한 API 아키텍처나 일반적인 소프트웨어 엔지니어링 모범 사례에는 경험이 부족할 수 있는 개발자에게 진입 장벽을 크게 낮추도록 설계되었음을 의미합니다. 구조화되고 유지보수 가능한 데이터 API를 구축하기 위한 명확하고 안내된 경로를 제공함으로써, PyNest는 이러한 전문가들이 웹 프레임워크 아키텍트가 될 필요 없이 데이터 모델이나 머신러닝 서비스를 신속하게 노출할 수 있도록 합니다.  
  •  
  •  

5. 비교 분석

기능PyNestFastAPI (라우트-서비스 패턴 구현)
기반 프레임워크 FastAPI Starlette, Pydantic
아키텍처 스타일 강제적 (모듈, 컨트롤러, 서비스, 프로바이더) 유연함 (APIRouter 및 팀 컨벤션/모범 사례를 통한 수동 구조화)
의존성 주입 명시적 (데코레이터, @Injectable, 모듈 프로바이더) 유연함 (Depends 함수, 함수형 접근 방식, 다양한 수준에 적용)
코드 생성 내장 CLI 도구 내장되지 않음 (Cookiecutter와 같은 외부 도구/템플릿 필요)
정형화 수준 높음 (NestJS에서 영감을 받은 컨벤션) 중간 (타입 힌트/Pydantic 중심, 유연한 전체 구조)
자동 API 문서 예 (FastAPI에서 상속) 예 (Swagger UI, ReDoc 내장)
비동기 지원 예 (FastAPI에서 상속) 예 (기본적이고 핵심 기능)
학습 곡선 FastAPI 기본 + PyNest 개념 (NestJS 익숙하면 도움) 비동기 개념, 효과적인 타입 힌트 사용

 

 
  • 아키텍처 정형화 및 구조:
    • PyNest: 이 프레임워크는 매우 정형화되어 있으며, NestJS 패러다임(모듈, 컨트롤러, 서비스)을 반영하는 특정 모듈식 아키텍처를 데코레이터와 팩토리 패턴을 광범위하게 사용하여 적극적으로 강제합니다. 이러한 강력한 강제성은 코드베이스 전반에 걸쳐 높은 수준의 일관성을 보장하는 명확한 가드레일을 제공하며, 이는 대규모 개발 팀이나 사전 정의된 아키텍처 패턴에 대한 엄격한 준수가 필요한 프로젝트에 특히 유리합니다. 코드 생성을 위한 CLI 도구의 포함은 이러한 강제된 구조를 더욱 공고히 하여 개발자를 처음부터 안내합니다.  
       
    • FastAPI (라우트-서비스 패턴 구현): 이와 대조적으로 FastAPI는 프레임워크 수준에서 덜 정형화되어 유연성을 우선시합니다. 강력한 도구를 제공하지만, 개발자는 모듈화를 위한 APIRouter와 의존성 주입을 위한 Depends를 사용하여 라우트-서비스 패턴을 명시적으로 정의하고 일관되게 준수해야 합니다. 이 접근 방식은 프로젝트를 구조화하기 위해 더 많은 규율과 수동 설정이 필요하지만, 그 대가로 개발자에게 애플리케이션 아키텍처에 대한 최대의 제어 및 사용자 정의 권한을 부여합니다.  
       
    두 프레임워크 간의 근본적인 선택은 궁극적으로 소프트웨어 개발에 대한 핵심적인 조직 철학을 반영합니다. 이는 팀이 개발자 자율성과 최대 유연성(FastAPI 설계에 내재된)을 위해 최적화할지, 아니면 강제된 일관성과 아키텍처 패턴 준수와 관련된 인지 부하 감소(PyNest의 강점)를 위해 최적화할지에 달려 있습니다. 소규모의 고도로 민첩한 팀이나 강력하고 확고한 설계 원칙을 가진 아키텍트가 이끄는 팀의 경우 FastAPI의 유연성이 선호되는 경로일 수 있습니다. 반대로, 대규모 조직이나 다양한 기술 수준과 경험을 가진 팀의 경우 PyNest의 정형화된 특성이 시간이 지남에 따라 아키텍처 이탈을 크게 줄이고 새로운 팀원의 온보딩 프로세스를 간소화할 수 있습니다.
  • 개발 경험:
    • 초기 설정 및 상용구: PyNest는 명령줄 인터페이스(CLI) 도구 덕분에 초기 프로젝트 설정에서 상당한 이점을 제공합니다. pynest generate application 및 pynest generate resource와 같은 명령은 새 프로젝트 또는 모듈을 신속하게 스캐폴드하여 일반적으로 필요한 수동 상용구 코드의 양을 크게 줄일 수 있습니다. 이는 초기 개발 단계를 가속화할 수 있습니다.  
       
    • 코드 가독성 및 간결성: 두 프레임워크 모두 파이썬의 기본 타입 힌트와 데코레이터의 신중한 사용을 통해 깔끔하고 읽기 쉬운 코드를 촉진하는 데 탁월합니다. 그러나 PyNest는 다양한 애플리케이션 구성 요소를 명시적으로 정의하기 위해 데코레이터를 더 광범위하게 사용하며, 이는 매우 선언적이고 간결한 코드베이스에 기여할 수 있습니다.  
       
    • 학습 곡선: FastAPI는 일반적으로 기본 API 개발에 대한 진입 장벽이 상대적으로 낮습니다. 그러나 비동기 프로그래밍(async/await) 및 정교한 의존성 주입 시스템에 대한 더 깊은 이해와 효과적인 활용은 이러한 개념에 익숙하지 않은 개발자에게 더 가파른 학습 곡선을 제공할 수 있습니다. PyNest는 추가적인 추상화 계층과 NestJS에서 영감을 받은 자체적인 데코레이터 및 규칙을 도입하여, 특히 NestJS 패러다임에 이미 익숙하지 않은 개발자에게는 추가적인 학습 곡선을 제시할 수 있습니다.  
       
    • 툴링: 두 프레임워크 모두 파이썬 타입 힌트에 대한 강력한 의존성 덕분에 뛰어난 편집기 지원과 강력한 정적 분석 기능을 본질적으로 활용합니다. PyNest는 통합 코드 생성 기능을 통해 툴링 경험을 더욱 향상시켜 반복적인 코딩 작업을 자동화하는 데 특정 이점을 제공합니다.  
       
  • 확장성 및 성능:
    • 기본적인 성능 이점 공유: PyNest와 FastAPI는 모두 기본 구성 요소인 Starlette, Uvicorn, Pydantic의 고성능 특성을 본질적으로 상속받습니다. FastAPI 자체는 뛰어난 성능을 위해 설계되었으며, 높은 동시성을 처리하고 현대 웹 API의 일반적인 I/O 바운드 작업을 효율적으로 관리하도록 설계되었습니다.  
       
    • 잠재적 추상화 오버헤드: PyNest의 추가 추상화 계층(예: 사용자 정의 데코레이터 처리, 특정 DI 구현의 해결 오버헤드)으로 인한 잠재적인 성능 오버헤드는 대부분의 일반적인 API 워크로드에서는 무시할 수 있을 정도로 작을 가능성이 높습니다. 대부분의 웹 애플리케이션에서 성능 병목 현상은 주로 I/O 바운드(예: 데이터베이스 쿼리, 외부 API 호출)이며, CPU 바운드 프레임워크 처리보다는 이쪽에 있습니다. 전체 애플리케이션 성능의 주요 결정 요인은 PyNest를 사용하든 순수 FastAPI를 사용하든 관계없이 비즈니스 로직 내에서 비동기 코드 관행을 효율적으로 구현하는 것입니다.
    PyNest는 FastAPI의 강력한 성능 기반을 본질적으로 활용하지만, 핵심 의존성 주입(DI) 메커니즘과 관련된 특정 공개 이슈(예: "서비스가 모듈에 제대로 범위가 지정되지 않음" )의 존재는 프레임워크의 안정성 및 고도로 복잡하거나 고부하 시나리오에서 리소스 활용 또는 전반적인 성능에 잠재적으로 영향을 미칠 수 있습니다. DI가 완벽하게 관리되지 않으면 의도하지 않은 객체 수명, 메모리 누수 또는 비효율적인 리소스 할당과 같은 문제가 발생할 수 있으며, 이는 직접적인 성능 저하는 아니지만 장기적인 확장성 및 높은 트래픽 하에서의 안정성에 상당한 위험 요소가 될 수 있습니다.  
  •  
  • 생태계 및 커뮤니티 지원:
    • FastAPI: 매우 크고 활기차며 성숙한 커뮤니티의 이점을 누립니다. 이러한 광범위한 생태계는 풍부하고 고품질의 문서, 수많은 튜토리얼, 방대한 타사 라이브러리, 그리고 일반적인 개발 문제에 대한 손쉬운 해결책으로 이어집니다. 결과적으로 문제 해결 및 관련 리소스 찾기가 일반적으로 간단하고 효율적입니다.
    • PyNest: 더 새롭고 전문화된 프레임워크이므로 현재 커뮤니티 규모가 훨씬 작습니다. 많은 기본 기능에 대해 더 넓은 파이썬 및 FastAPI 생태계를 본질적으로 활용하지만, PyNest의 특정 아키텍처 패턴과 사용자 정의 추상화는 개발자가 자체 전용 문서와 초기 커뮤니티가 제공하는 지원에 더 많이 의존해야 할 수 있음을 의미합니다.
    PyNest 문서에 언급된 "미래 계획" 에는 "모듈용 플러그인 마켓플레이스" 생성 및 "IOC 메커니즘 구현 및 모듈 데코레이터 도입"과 같은 야심찬 목표가 명시되어 있습니다. 이는 PyNest의 생태계가 핵심 기능을 구축하고 커뮤니티 기여를 촉진하는 데 중점을 두고 아직 초기 단계에 있음을 분명히 나타냅니다. 이는 광범위한 사전 구축 솔루션과 커뮤니티 기여 패키지가 이미 풍부하게 제공되는 FastAPI의 이미 성숙하고 광범위한 플러그인 및 미들웨어 생태계와는 극명한 대조를 이룹니다.  
  •  
  • 프레임워크 성숙도 및 유지보수:
    • FastAPI: 매우 성숙하고 널리 채택된 프레임워크로, 창시자인 Tiangolo가 주도하고 매우 활발하고 큰 커뮤니티가 지원하는 일관되고 강력한 유지보수의 이점을 누립니다. 일관된 업데이트와 안정적인 API가 특징이며, 운영 시스템에 대한 신뢰할 수 있는 선택입니다.
    • PyNest: 사용자가 PyNest의 업데이트 빈도에 대해 "업데이트도 거의 6개월 전 코드가 마지막이던데.."라고 언급한 우려는 프레임워크의 GitHub 릴리스 기록 에 의해 직접적으로 반박됩니다. PyNest는 지난 6개월 이내에 2024년 12월 19일의 v0.3.2, 2024년 9월 15일의 v0.3.1, 2024년 8월 6일의 v0.3.0을 포함하여 여러 릴리스를 통해 활발한 개발을 보여주었습니다. 또한, 최근 커밋은 저장소의 다양한 부분에서 확인되어 지속적이고 활발한 개발 및 유지보수를 나타냅니다.  
       
    • 그러나 PyNest의 GitHub 저장소에 있는 공개 이슈 목록 을 더 깊이 살펴보면 주의가 필요한 몇 가지 근본적인 문제가 드러납니다:  
       
      • 이슈 #82: "서비스가 모듈에 제대로 범위가 지정되지 않음" (2024년 10월 14일 개설) – 의존성 주입 및 모듈성을 크게 강조하는 프레임워크에 대한 중요한 문제입니다.
      • 이슈 #81: "AbstractService, init 호출되지 않음" (2024년 10월 10일 개설) – 의존성 주입 및 서비스 수명 주기 관리의 핵심 기능과 관련된 또 다른 중요한 문제입니다.
      • 이슈 #92: "인증 및 권한 부여에 대한 적절한 문서 필요" (2024년 12월 24일 개설) – 인증은 보편적인 요구 사항이므로, 안전하고 운영 환경에 적합한 API를 구축하는 데 있어 상당한 공백을 나타냅니다.
      • 이슈 #104: "Websockets에 대한 공식 문서가 있습니까?" (2025년 3월 13일 개설) – WebSockets에 대한 문서의 부재는 주요 현대 웹 통신 프로토콜에 대한 포괄적인 지원 부족을 나타냅니다.
      • 이슈 #74: "DI 프레임워크를 독립적인 모듈로 분리할 계획입니까?" (2024년 8월 2일 개설) – 이는 핵심 프레임워크 자체 내에서 진행 중인 아키텍처 진화 또는 잠재적인 재구성을 시사합니다.
    • 또한, 상세한 공개 풀 리퀘스트 활동 정보를 확인할 수 없어, 보고된 이슈 외에 커뮤니티 기여의 상태와 양을 완전히 평가하는 데 한계가 있습니다.  
       
    PyNest는 릴리스 및 이슈 추적 측면에서 활발한 활동을 보이고 있지만, 공개 이슈의 성격은 핵심 의존성 주입 메커니즘 및 일반적인 API 패턴(인증 및 WebSockets와 같은)과 관련하여 여전히 근본적인 아키텍처 안정성 및 포괄적인 기능 문서 제공에 어려움을 겪고 있음을 시사합니다. 이는 특히 복잡한 운영 시스템을 구축할 때 문서화되지 않은 동작, 핵심 프레임워크 로직에서 발생하는 예상치 못한 엣지 케이스 버그, 또는 불완전한 문서로 인해 소스 코드를 파고들어야 할 가능성이 더 높다는 것을 의미합니다. 이러한 문제는 FastAPI와 같은 더 성숙하고 안정적인 프레임워크를 사용하는 경우에 비해 개발 시간, 디버깅 노력 및 전반적인 프로젝트 위험을 증가시킬 수 있습니다.
  • 표 2: PyNest GitHub 활동 요약
지표값출처
최신 릴리스 버전 v0.3.2  
최신 릴리스 날짜 2024년 12월 19일  
핵심 코드 마지막 커밋 (예: nest/) 5개월 전 (조사일 기준)  
테스트 코드 마지막 커밋 (tests/) 6개월 전 (조사일 기준)  
가장 최근 개설된 이슈 2025년 3월 13일 (이슈 #104)  
총 공개 이슈 수 22  
총 공개 풀 리퀘스트 수 8  

 

 

PyNest의 장점:

  • 대규모 애플리케이션을 위한 구조화된 개발: PyNest의 강제된 모듈식 아키텍처(모듈, 컨트롤러, 서비스)는 코드를 구성하기 위한 명확한 청사진을 제공하며, 이는 크고 복잡한 애플리케이션 및 팀에 매우 유용합니다. 이는 아키텍처 설계의 인지 부하를 줄여줍니다.  
     
  • 상용구 감소 및 빠른 초기 설정: 내장된 코드 생성 CLI 도구는 표준 구성 요소 생성을 크게 자동화하여 초기 개발을 가속화하고 프로젝트 전반에 걸쳐 구조적 일관성을 보장합니다.  
     
  • NestJS 개발자를 위한 익숙함: NestJS(인기 있는 Node.js 프레임워크) 경험이 있는 개발자에게 PyNest는 매우 익숙하고 직관적인 개발 경험을 제공하며, 유사한 패턴과 데코레이터를 활용합니다. 이는 이러한 팀의 학습 곡선을 줄이고 생산성을 높일 수 있습니다.  
     
  • 정형화된 의존성 주입: @Injectable 및 모듈 기반 프로바이더 등록을 사용하는 PyNest의 명시적인 DI 시스템은 복잡한 애플리케이션의 의존성 관리를 간소화할 수 있으며, 서비스 의존성을 처리하는 명확하고 일관된 방법을 제공합니다.  
     

FastAPI (라우트-서비스 패턴 구현)의 장점:

  • 최대 제어 및 유연성: 라우트-서비스 패턴을 수동으로 적용하여 FastAPI를 직접 구현함으로써 개발자는 애플리케이션 아키텍처 및 설계 선택의 모든 측면에 대한 완전한 제어권을 유지합니다. 이를 통해 프레임워크가 부과하는 제약 없이 특정 프로젝트 요구 사항에 맞춰 고도로 사용자 정의된 솔루션을 만들 수 있습니다.  
     
  • 핵심 FastAPI 기능에 대한 직접 액세스: 개발자는 FastAPI의 강력한 기본 요소(APIRouter, Depends, Pydantic)와 직접 작업합니다. 이러한 직접적인 상호 작용은 기본 프레임워크에 대한 더 깊은 이해로 이어질 수 있으며, 추가 추상화 계층 없이 해당 기능을 보다 최적화되고 미묘하게 사용할 수 있도록 합니다.  
     
  • 더 크고 성숙한 커뮤니티 및 생태계: FastAPI는 방대하고 활발하며 성숙한 커뮤니티의 이점을 누립니다. 이는 광범위한 문서, 수많은 튜토리얼, 방대한 타사 라이브러리, 손쉬운 해결책, 그리고 문제 해결 및 학습을 위한 광범위한 커뮤니티 지원으로 이어집니다. 이러한 광범위한 생태계는 단일 프레임워크 유지보수자에 대한 의존도를 줄여줍니다.  
     
  • 추가 프레임워크 계층 의존성 없음: PyNest와 같은 추가 프레임워크 계층을 피하면 외부 의존성이 줄어들고, 잠재적으로 디버깅 경로가 단순해지며, 작고 덜 확립된 프로젝트의 유지보수 및 진화와 관련된 위험이 줄어듭니다.

결론 및 권고 사항

사용자의 질의에 대한 심층 분석을 통해 PyNest와 FastAPI(라우트-서비스 패턴 구현) 각각의 장점과 고려 사항이 명확히 드러났습니다. 두 프레임워크는 모두 파이썬 API 개발을 위한 강력한 기반을 제공하지만, 개발 철학, 구조화 방식, 그리고 커뮤니티 생태계에서 중요한 차이를 보입니다.

  • PyNest를 선택해야 하는 전략적 시점:
    • NestJS에 익숙한 팀: 개발 팀이 NestJS에 대한 상당한 경험을 가지고 있고 그 아키텍처 패턴을 선호한다면, PyNest는 파이썬 API로의 편안하고 생산적인 전환을 제공하여 기존 지식을 활용할 수 있습니다.  
       
    • 강력한 아키텍처 일관성이 필요한 프로젝트: 여러 모듈과 다양한 개발자에 의해 일관된 구조를 유지하는 것이 가장 중요한 대규모 프로젝트의 경우, PyNest의 강제된 규칙과 코드 생성 기능은 일관되고 유지보수 가능한 코드베이스를 보장하는 데 매우 유용합니다.  
       
    • 구조화된 프로젝트의 빠른 초기 설정 우선: 복잡하고 모듈화된 API를 최소한의 아키텍처 결정으로 신속하게 스캐폴드하는 것이 목표라면, PyNest의 CLI 및 정형화된 구조가 초기 개발 단계를 가속화할 수 있습니다.
    • 작은 생태계 인지: 복잡하거나 틈새 시장의 문제에 대해서는 PyNest의 핵심 문서와 유지보수자에 더 많이 의존해야 할 수 있으며, 커뮤니티 리소스가 적을 수 있음을 인지해야 합니다. 이는 더 높은 수준의 자립 또는 프로젝트에 기여하려는 의지가 필요할 수 있음을 의미합니다.  
       
  • FastAPI (라우트-서비스 패턴 구현)를 선호해야 하는 전략적 시점:
    • 최대 유연성과 제어를 선호하는 팀: 팀이 프레임워크가 부과하는 제약 없이 아키텍처를 설계하고 발전시키는 자유를 중요하게 생각한다면, FastAPI는 필요한 구성 요소를 제공합니다.  
       
    • 광범위한 생태계와 강력한 커뮤니티 지원이 필요한 프로젝트: 광범위한 라이브러리, 커뮤니티 솔루션, 그리고 장기적인 안정성이 중요한 미션 크리티컬 애플리케이션의 경우, FastAPI의 광범위한 생태계는 상당한 이점입니다.  
       
    • 강력한 내부 아키텍처 지침을 가진 팀: 팀이 파이썬 프로젝트를 구조화하기 위한 잘 정의된 모범 사례를 이미 가지고 있고 이를 일관되게 적용할 수 있다면 , FastAPI는 강력한 선택입니다.  
       
    • 최소한의 추상화 계층 선호: FastAPI의 핵심에 최대한 가깝게 작업하여 잠재적으로 디버깅을 단순화하고 외부 의존성을 줄이고자 할 때 유리합니다.
  • 유지보수 우려에 대한 직접적인 대응 및 장기적인 프로젝트 건전성에 대한 시사점: 사용자가 PyNest의 유지보수 활동에 대해 제기한 우려("업데이트도 거의 6개월 전 코드가 마지막이던데..")는 데이터에 기반하여 직접적으로 다루어져야 합니다. PyNest는 방치된 프로젝트가 아닙니다. 일부 핵심 파일의 커밋이 몇 달 전으로 거슬러 올라갈 수 있지만(예: nest/ 폴더 5개월 전, tests/ 6개월 전 ), 프로젝트의 릴리스 기록은 매우 최근의 일관된 업데이트를 보여줍니다. v0.3.2는 2024년 12월 19일에 릴리스되었으며, 이전 버전들도 2024년 내내 자주 릴리스되었습니다. 또한, 이슈 트래커는 2025년 3월 13일(조사 시점 기준 미래 날짜)과 같이 최근에 개설된 이슈들을 포함하여 지속적인 활동을 보여줍니다. 이는 프로젝트가 활발히 유지보수되고 있으며, 커뮤니티 참여 및 문제 보고가 계속되고 있음을 나타냅니다.   그러나 PyNest는 FastAPI와 같은 대규모 프레임워크에 비해 규모가 작은 프로젝트입니다. 이는 새로운 기능 개발 속도가 느리거나, 모호한 문제에 대한 버그 수정이 더딜 수 있으며, 지원을 받을 수 있는 커뮤니티가 더 작다는 것을 의미합니다. 또한, "서비스가 모듈에 제대로 범위가 지정되지 않음" 과 같은 핵심 의존성 주입 메커니즘과 관련된 공개 이슈의 존재는 프레임워크의 안정성 및 고부하 시나리오에서 리소스 활용 또는 전반적인 성능에 잠재적으로 영향을 미칠 수 있습니다. 이러한 문제는 직접적인 성능 저하는 아니지만, 장기적인 확장성 및 높은 트래픽 하에서의 안정성에 상당한 위험 요소가 될 수 있습니다.   결론: PyNest는 특정 사용 사례에 대해 실행 가능한 옵션이지만, 개발자는 현재 성숙도 단계와 더 확고한 FastAPI 생태계와 비교했을 때 관련된 장단점을 인지해야 합니다. 결정은 PyNest의 정형화된 구조의 이점과 순수 FastAPI의 광범위한 지원 및 유연성 사이의 균형을 고려해야 합니다.

 

기존 결과물을 다들 안좋아하기도 하고, 프레임워크를 쓰면 좋은 점도 있지만 종속되면 구조 변경이 힘들어지는 문제도 있어 FastAPI core에  Route - Service 패턴으로 가기로 결정했네요. :)

반응형
저작자표시 동일조건 (새창열림)