Server Actions

📌 Brief Summary

Server Actions는 React Server Components(RSC) 아키텍처 환경에서 데이터를 변경(mutate)하기 위해 도입된 기능이다 [1]. 코드 상단에 "use server" 지시어를 선언하여 서버에서 실행되는 함수를 정의하며, 클라이언트 컴포넌트에서는 이를 일반적인 바닐라 함수처럼 간편하게 호출할 수 있다 [2, 3]. 단일 폼(Form) 제출과 같은 상호작용 시 클라이언트와 서버 간의 단일 왕복(one round trip)만으로 데이터 처리 및 화면 갱신이 가능하여 뛰어난 효율성을 제공한다 [4, 5].

📖 Core Content

동작 원리 및 선언 방식 Server Actions는 함수에 "use server" 프래그마(pragma)를 선언하여 생성한다 [2]. 클라이언트 컴포넌트는 이 함수를 가져와 버튼 클릭 등의 이벤트 핸들러에서 직접 호출할 수 있으며, 개발자에게는 단순한 함수 호출처럼 보이지만 내부적으로는 프레임워크가 자동으로 생성한 엔드포인트로 네트워크 POST 요청을 보내어 서버에서 코드를 실행한다 [2, 3].
상태 갱신 메커니즘 서버 액션 내에서 데이터베이스 연산(예: SQLite UPDATE)을 수행한 후 revalidateTag와 같은 함수를 호출하면, 연관된 데이터의 캐시가 무효화된다 [2, 4]. 이로 인해 변경된 데이터를 기반으로 RSC가 다시 실행되고 업데이트된 마크업이 클라이언트로 전달되며, 이 모든 렌더링 및 통신 과정이 서버와의 단일 왕복(one round trip) 내에서 완료된다 [3, 4].
최적의 사용 사례 Server Actions는 폼(form) 요소와 매우 잘 호환되며, 폼의 action 속성에 서버 액션을 직접 설정할 수도 있다 [5]. 복잡한 데이터 소스 없이 단일 폼과 제출 버튼이 있는 페이지 구조에서 가장 뛰어난 성능과 효과를 발휘한다 [5, 6].

⚖️ Trade-offs & Caveats

전체 컴포넌트 트리 재렌더링의 비효율성 서버 액션 실행 후 revalidateTag를 호출하면 업데이트된 특정 데이터만 갱신되는 것이 아니라, 캐시에서 해당 태그를 방출함에 따라 현재 페이지의 전체 컴포넌트 트리가 다시 렌더링되며 모든 데이터를 다시 요청하게 된다 [4, 7]. 만약 서버 측에 적절한 캐싱 처리가 되어있지 않다면, 서버 액션을 통한 한 번의 왕복 통신이 오히려 react-query를 사용한 두 번의 왕복 처리보다 더 오래 걸리는 성능 저하를 초래할 수 있다 [7, 8].
직렬 실행(Serial Execution) 제약 서버 액션은 한 번에 하나씩만 실행될 수 있다는 치명적인 한계를 가진다 [9]. 여러 개의 서버 액션을 동시에 시도할 경우 요청이 대기열(Queue)에 쌓이게 되며, 네트워크가 느리거나 불안정한 환경에서는 매우 심각한 성능 지연을 발생시킨다 [9]. 따라서 데이터 소스나 폼이 여러 개 존재하는 복잡한 화면에는 도입하기 적합하지 않다 [6].
심각한 보안 취약점 노출 위험 및 유효성 검사 필수 "use server"로 선언된 서버 액션 함수는 로컬 내부 함수처럼 보이지만, 실제로는 인터넷상의 누구나 접근하여 POST 요청을 보낼 수 있는 퍼블릭 HTTP 엔드포인트로 동작한다 [10]. 개발자가 이를 내부 함수로 착각하여 입력값 유효성 검사를 누락할 경우, 조작된 악성 요청에 의해 인증 없이 원격 코드가 실행되는 'React2Shell (CVE-2025-55182)'과 같은 치명적인 보안 취약점에 노출될 수 있다 [10, 11]. 따라서 기존 Express 라우트 핸들러나 API 엔드포인트를 다룰 때와 동일한 수준의 엄격한 데이터 검증과 살균(Sanitization) 작업이 반드시 수반되어야 한다 [10].

Last updated: 2026-05-03

4.2 KiB Raw Blame History

Server Actions

📌 Brief Summary

📖 Core Content

⚖️ Trade-offs & Caveats

4.2 KiB

Raw Blame History