서버 액션(Server Action)과 FSD 구조를 결합하는 이유
Next.js의 Server Action은
폼 데이터나 인터랙션을 서버에서 직접 처리할 수 있게 해줍니다.

덕분에 API 라우터를 따로 만들 필요 없이,
UI에서 발생한 이벤트를 곧바로 DB 변경과 연결할 수 있죠.
개발 경험과 성능 모두 좋아집니다.

그런데 문제는 여기서 발생합니다.
“어떤 코드가 읽기 전용이고, 어떤 코드가 쓰기 전용인지”
점점 구분이 흐려지기 시작하는 겁니다.

저는 그래서 Server Action을 사용할 때
Clean FSD 구조를 적용합니다.

Entities(읽기 전용)
→ Server Component 중심, 데이터 조회 전용
Features(쓰기 전용)
→ Server Action으로만 DB를 변경

이렇게 하면 경계가 명확해집니다.
“이건 Entities니까 절대 데이터를 바꾸지 않는다.”
“이건 Features니까 반드시 이벤트와 함께 동작한다.”

설계 의도가 코드 구조에 그대로 남으니,
팀원뿐 아니라 AI에게도 일관된 제약을 줄 수 있습니다.

Server Action은 빠른 구현을,
Clean FSD 구조는 설계 안정성을 줍니다.

이 둘을 적절하게 함께 가져가면
AI 시대에 흔들리지 않는 아키텍처가 완성됩니다.

혹시 여러분의 프로젝트에서는
Server Action을 어떤 기준으로 관리하고 계신가요?