Next.js API와 함께 별도의 로직을 관리하기 위한 lib/action 폴더를 구성하는 방식은 꽤 자주 사용되는 구조지만, 명확한 장점만큼이나 실제 개발 및 운영 시 고려해야 할 단점과 한계점도 있습니다.
3번을 가장 치명적인 문제로 보고 있습니다. 그래도 Fluid Computing등 기술 개발을 통해 문제 해결을 위해 노력하고 있습니다.
📌 1. 명확한 경계 설정의 어려움 (Boundary의 모호성)
Next.js의 API Routes는 HTTP 요청을 처리하는 역할을 하며, 보통은 pages/api 혹은 app/api 디렉터리에 분리되어 있습니다. 반면, lib/action은 일반적으로 데이터베이스 조회, 비즈니스 로직, 또는 외부 API 호출 같은 다양한 역할을 담당합니다.
이렇게 API Routes와 Action을 나누다 보면, 로직의 경계를 명확하게 설정하기 어려워지는 경우가 자주 발생합니다.
-
API Route에 데이터 검증 및 간단한 로직을 넣어야 할지, Action에서 전부 처리할지 명확히 결정하기 어려워질 수 있습니다.
-
프로젝트가 커질수록 Action 내의 책임 범위가 흐려져 유지보수가 어려워질 수 있습니다.
📌 2. Next.js의 내장 미들웨어 기능 미활용으로 인한 한계
Next.js는 기본적으로 Middleware 기능을 통해 인증, 권한 확인, 지역화(Localization) 같은 크로스-커팅(cross-cutting) 기능을 쉽게 적용할 수 있는 환경을 제공합니다. 그러나 API Route와 Action 방식만 활용하면 다음과 같은 제한이 발생합니다.
-
공통 처리 로직(예: 인증, 권한 검사 등)을 매번 각 API Route에서 수동으로 호출해야 하는 경우가 생길 수 있습니다.
-
Middleware를 제대로 활용하지 않고 Action에서만 로직을 처리하면 불필요한 코드 중복과 관리 포인트가 증가합니다.
📌 3. 서버리스(Serverless) 환경 특성으로 인한 한계점
Next.js의 API Route는 기본적으로 Serverless 형태로 동작하기 때문에 함수의 콜드 스타트(Cold Start)나 제한된 실행 시간(Time Limit)과 같은 서버리스 환경의 단점이 그대로 존재합니다.
-
Action 내부에서 매우 긴 시간이 소요되는 작업이나 무거운 작업(예: 많은 데이터 처리를 동반한 복잡한 비즈니스 로직)을 수행하는 경우, 성능 저하나 Timeout 이슈가 빈번하게 발생할 수 있습니다.
-
무거운 로직을 수행하기엔 Next.js의 API Routes 자체가 최적의 환경이 아닐 수 있습니다.
📌 4. 폴더 구조 관리의 복잡성 증가
API와 Action을 나누어 관리하면 폴더 구조가 점차 복잡해지고 관리가 어려워질 수 있습니다.
폴더 구조가 이렇게 복잡해질 때 까지 Next Server 하나를 유지하고 있다면 문제가 있어보입니다. 폴더 구조 관리 복잡성이 느껴질 때 MSA 진행을 권장 드립니다.
-
Action 폴더가 너무 커지면 파일이 증가하여 구조가 복잡해지고 탐색이 어려워집니다. (여기까지 갔으면 문제가 있어보입니다.)
✅ 최종 의견 및 결론
사실 작은 규모의 프로젝트나 명확한 역할 분리를 위한 초기 프로젝트에서 매우 유용한 기능들입니다. 하지만 프로젝트가 커지거나 복잡한 비즈니스 로직을 처리해야 하는 상황까지 왔다면 Next 서버의 한계를 느끼기 때문에 더 적합한 별도의 서버 환경을 도입하는 등의 추가적 고려가 필요합니다.