Next.js App Router 테스트 전략 가이드: RSC·Server Actions·관리자 화면 검증 구조 > 인사이트

본문 바로가기

인사이트

#React·Next.js

Next.js App Router 테스트 전략 가이드: RSC·Server Actions·관리자 화면 검증 구조

Next.js App Router 테스트 전략을 논의하는 SaaS 개발 워크스테이션
App Router 테스트는 화면 확인, 서버 변경, 권한, 캐시를 함께 보는 운영 구조다.

결론부터 말하면, Next.js App Router 테스트 전략은 ‘화면이 보이는지’만 확인하는 방식으로 끝나면 안 됩니다. App Router에서는 React Server Components가 서버에서 데이터를 읽고 UI를 만들며, Server Actions는 데이터 변경을 담당하고, Route Handler와 Proxy는 브라우저 UI 밖의 요청 흐름을 처리합니다. 랜딩 페이지라면 문의 폼과 SEO, SaaS라면 가입·결제·권한, 관리자 화면이라면 역할별 접근과 데이터 변경이 모두 운영 리스크가 됩니다.

따라서 실무 기준은 단순합니다. 순수 로직은 단위 테스트, 사용자 입력이 있는 Client Component는 컴포넌트 테스트, 서버 변경 지점은 함수·통합 테스트, 실제 App Router 렌더링과 권한 흐름은 E2E로 검증해야 합니다. 모든 것을 Playwright나 Cypress로 돌리면 느리고 취약해지고, 반대로 Jest·React Testing Library만 믿으면 RSC, Server Actions, 캐시 재검증, Proxy 리다이렉트 같은 App Router 고유 동작을 놓치게 됩니다.

테스트의 목적은 “테스트 수를 늘리는 것”이 아니라 배포 후 운영자가 겪을 장애를 출시 전에 발견하는 것입니다. 특히 관리자 화면은 버튼 클릭보다 ‘누가, 어떤 데이터에, 어떤 권한으로, 어떤 변경을 했는가’를 검증해야 합니다.

1. App Router 이후 테스트 기준이 바뀐 이유

Pages Router나 CSR 중심 React 앱에서는 브라우저 화면과 API 호출을 분리해서 생각하기 쉬웠습니다. App Router에서는 이 경계가 달라졌습니다. 기본적으로 page와 layout은 Server Component가 될 수 있고, 필요한 경우에만 'use client'를 붙여 상태, 이벤트 핸들러, 브라우저 API를 사용합니다. Server Component에서 가져온 값은 Client Component에 props로 전달될 수 있으므로, 테스트는 “클라이언트에 무엇이 보이는가”뿐 아니라 “서버에서 어떤 데이터가 조회되고, 어떤 필드만 내려가는가”까지 봐야 합니다.

Next.js 공식 테스트 문서는 async Server Components에 대해 일부 도구가 아직 완전히 지원하지 않으므로 단위 테스트보다 E2E 테스트를 권장합니다. 이것은 중요한 신호입니다. async Server Component를 억지로 Jest에서 렌더링하려 하기보다, 데이터 접근 함수와 권한 판단을 별도 모듈로 분리해 단위 테스트하고, 실제 route 렌더링은 프로덕션 빌드에 가까운 E2E로 확인하는 편이 운영에 맞습니다.

Server Actions도 마찬가지입니다. 폼에서 호출되더라도 결국 서버로 POST 요청이 들어가는 변경 지점입니다. UI에서 버튼을 숨겼다고 안전한 것이 아닙니다. 인증, 권한, 소유권, 입력 검증은 Server Action 내부나 Data Access Layer에서 다시 확인되어야 합니다. 이 구조가 없다면 테스트도 어디를 검증해야 할지 불명확해집니다. 권한 설계가 먼저 흔들리는 팀은 Next.js App Router 인증 권한 설계 가이드를 먼저 정리한 뒤 테스트 범위를 잡는 편이 좋습니다.

2. 기능별 테스트 책임을 먼저 나눠야 한다

App Router 프로젝트에서 테스트를 잘못 시작하는 팀은 보통 “무슨 도구를 쓸까”부터 묻습니다. 더 먼저 정해야 할 것은 “이 기능이 실패하면 어떤 운영 문제가 생기는가”입니다. 다음 표를 기준으로 범위를 나누면 테스트가 과하지도, 부족하지도 않습니다.

검증 대상대표 리스크권장 테스트합격 기준
가격 카드, CTA, FAQ 같은 랜딩 UI문구 누락, 링크 오류, 접근성 낮은 버튼React Testing Library 또는 E2E smoke주요 CTA가 role과 이름으로 탐색되고 올바른 URL로 이동
가입·문의·신청 폼필수값 누락, 서버 검증 부재, 오류 메시지 미노출Client Component 테스트 + Server Action 테스트 + E2E잘못된 입력은 저장되지 않고, 사용자가 이해할 오류가 표시됨
async Server Component 데이터 조회잘못된 테넌트 데이터 노출, 로딩·에러 분기 누락데이터 함수 단위 테스트 + route E2E권한별로 필요한 데이터만 렌더링되고 비인가 데이터는 보이지 않음
Server Actions권한 없는 변경, hidden input 조작, 재검증 누락FormData 기반 함수 테스트 + E2E 제출 흐름인증·권한·소유권·입력 검증 후에만 DB 변경, 성공 후 UI 갱신
Route Handlers잘못된 status code, 인증 누락, 외부 webhook 검증 실패Request 객체 기반 통합 테스트 + 일부 E2E401·403·405·성공 응답이 명확하고 JSON 스키마가 안정적
Proxy, 구 Middleware관리자 페이지 우회, 잘못된 리다이렉트, matcher 누락request-level 테스트 + 권한별 E2E비로그인·일반 사용자·관리자별 접근 결과가 일관됨
캐시·재검증수정 후 오래된 데이터 노출, HTML과 RSC payload 불일치mutation 후 E2E 확인 + revalidation 함수 테스트변경 직후 보여야 하는 데이터는 즉시 갱신, 지연 허용 데이터는 정책대로 갱신
관리자 화면역할 누락, 삭제·승인 오작동, 고객사 간 데이터 혼선권한 매트릭스 테스트 + 핵심 E2E역할·테넌트·상태별 허용 동작과 차단 동작이 모두 검증됨
App Router 테스트 피라미드와 검증 흐름을 정리한 회의 보드
기능 리스크별로 단위 테스트와 E2E 테스트의 책임을 나눠야 한다.

3. Jest·Vitest·RTL은 어디까지 맡길까

Jest와 Vitest는 여전히 필요합니다. 다만 App Router 전체를 이 도구로 검증하려고 하면 비용 대비 효과가 낮아집니다. 적합한 영역은 다음과 같습니다.

  • 순수 함수: 가격 계산, 날짜 포맷, 상태 전이, 권한 판정, feature flag 분기
  • Data Access Layer의 계약: 현재 사용자 기준으로 어떤 필드만 반환하는지, 다른 테넌트 데이터가 차단되는지
  • Client Component: 모달 열림, 탭 전환, 폼 필드 검증, 버튼 disabled, aria-live 오류 메시지
  • Server Action 내부 로직: 인증 mock, FormData 입력, 검증 실패, 권한 실패, DB 호출 여부, revalidation 함수 호출 여부

React Testing Library를 쓸 때는 CSS class나 DOM 깊이에 의존하지 말고, 사용자가 인식하는 role, label, button name 중심으로 찾는 것이 유지보수에 유리합니다. 예를 들어 관리자 승인 버튼은 getByRole('button', { name: /승인/ })처럼 기능 의미가 드러나야 합니다. 테스트가 이렇게 작성되면 접근성 기준도 함께 좋아집니다.

반대로 피해야 할 패턴도 있습니다. 관리자 대시보드 전체를 snapshot으로 고정하면 작은 문구 변경에도 테스트가 깨집니다. Server Component 내부 구현을 mock으로 과도하게 감싸면 실제 App Router의 streaming, hydration, cache 동작을 보지 못합니다. 단위 테스트는 빠른 피드백을 주는 층이지, 실제 배포 동작의 대체물이 아닙니다.

4. async Server Components와 Suspense는 E2E 중심으로 본다

RSC를 테스트할 때 가장 중요한 설계 원칙은 “컴포넌트 안의 일을 줄이는 것”입니다. Server Component 안에 DB query, 권한 판단, 데이터 가공, 화면 분기를 모두 넣으면 테스트도 어렵고 보안 리뷰도 어려워집니다. 실무에서는 다음처럼 나눕니다.

  1. 데이터 접근 함수: getAdminUsers(currentUser, tenantId)처럼 현재 사용자와 입력값을 받아 안전한 DTO를 반환
  2. 권한 판단 함수: admin, manager, viewer 같은 역할별 허용 동작을 순수 함수로 분리
  3. Server Component: 이미 검증된 함수를 호출하고, 필요한 Client Component에 최소 props만 전달
  4. E2E: 실제 URL 접근, 로그인 상태, loading fallback, 최종 화면, 비인가 데이터 미노출을 확인

특히 SaaS 관리자 화면은 “보이는 데이터”가 곧 보안입니다. 고객사 A 계정으로 로그인했을 때 고객사 B의 사용자, 주문, 결제 상태, 내부 메모가 렌더링되지 않는지 E2E로 확인해야 합니다. 단위 테스트에서 반환값을 검증하고, E2E에서 실제 route가 그 반환값만 화면에 노출하는지 확인하면 두 층이 서로 보완됩니다.

Suspense가 있는 화면은 loading 상태도 테스트 대상입니다. 단순히 최종 텍스트만 확인하면 느린 API, 권한 확인 지연, 빈 목록 상태에서의 사용자 경험을 놓칩니다. E2E에서는 fallback이 보이는지, 최종 데이터가 나타나는지, 오류 시 error boundary나 안내 문구가 보이는지까지 최소 한 번은 확인해야 합니다.

5. Server Actions 테스트는 ‘보안 테스트’에 가깝다

Server Actions는 폼 UX를 단순하게 만들어주지만, 테스트 관점에서는 공개 변경 지점입니다. 공식 문서도 Server Actions를 민감한 서버 작업으로 보고 인증과 권한을 확인하라고 안내합니다. 다음 항목은 관리자 기능에서 반드시 확인해야 합니다.

테스트 항목확인 질문예시
입력 검증클라이언트 검증을 우회해도 서버에서 거부되는가?이메일 형식, 금액 범위, 파일 크기, 필수 동의
인증세션이 없으면 변경이 일어나지 않는가?비로그인 상태의 초대, 삭제, 승인 요청
권한역할이 부족하면 DB update가 호출되지 않는가?viewer가 결제 상태를 변경하려는 경우
소유권다른 테넌트의 id를 넣어도 차단되는가?hidden input의 tenantId 조작
재검증변경 후 현재 화면이나 관련 목록이 정책대로 갱신되는가?승인 후 신청 목록 상태 변경
오류 UX실패 이유가 사용자에게 안전하고 이해 가능하게 표시되는가?서버 stack trace 대신 일반 오류 메시지

단위·통합 테스트에서는 Server Action을 직접 호출해 FormData를 넘기고, auth와 DB를 제어합니다. E2E에서는 실제 폼을 채우고 제출해서 pending 상태, 오류 표시, redirect, 화면 갱신을 확인합니다. 두 테스트의 목적이 다릅니다. 함수 테스트는 “저장되면 안 되는 값이 저장되지 않는가”를 보고, E2E는 “사용자가 같은 흐름에서 올바른 결과를 보는가”를 봅니다.

캐시 재검증은 기능 성격에 따라 달라집니다. 사용자가 글을 작성하고 곧바로 본인의 글을 봐야 한다면 즉시 갱신 성격이 강합니다. 반면 블로그 목록이나 상품 카탈로그처럼 약간의 지연이 허용되는 화면은 stale-while-revalidate 성격을 선택할 수 있습니다. 이 차이를 이해하지 못하고 무조건 path 전체를 재검증하면 성능과 일관성 모두 애매해집니다. 캐시 전략은 Next.js ISR·온디맨드 재검증 전략과 함께 설계하는 것이 좋습니다.

6. Route Handler와 Proxy는 브라우저 밖에서도 테스트한다

Route Handler는 Web Request와 Response를 다루므로, 브라우저를 띄우지 않고도 상당 부분을 테스트할 수 있습니다. 예를 들어 GET, POST, PATCH, DELETE별로 인증 실패, 권한 실패, 성공 응답, 잘못된 payload, unsupported method를 확인합니다. webhook이라면 서명 검증 실패와 재시도 가능 응답도 포함해야 합니다.

Proxy는 Next.js 16 문서에서 Middleware 대신 사용하는 명칭입니다. 기능 자체는 요청이 완료되기 전에 redirect, rewrite, header 조작 같은 일을 수행하는 계층입니다. 다만 Proxy는 전체 세션 관리나 최종 권한 검증을 대신하는 곳이 아닙니다. 빠른 리다이렉트와 요청 분기에는 유용하지만, Server Component의 데이터 조회, Server Action의 변경, Route Handler의 응답에서도 권한은 다시 확인되어야 합니다. 책임 경계가 헷갈린다면 Next.js Middleware·Proxy 설계 가이드의 기준을 함께 보세요.

관리자 화면에서는 최소한 다음 E2E 시나리오를 둡니다.

  • 비로그인 사용자가 /admin 접근 시 로그인 페이지로 이동
  • 일반 사용자가 /admin/users 접근 시 403 또는 권한 없음 화면 표시
  • 관리자가 접근하면 목록은 보이지만, super admin 전용 버튼은 보이지 않음
  • 권한 없는 사용자가 Server Action을 직접 유발해도 변경 실패
  • 다른 테넌트의 URL parameter를 입력해도 데이터 조회 실패

7. Playwright와 Cypress 선택 기준

Jest Vitest Playwright Cypress 테스트 도구 비교 화면
도구 선택은 유행보다 팀의 리스크와 운영 방식에 맞춰야 한다.

Next.js App Router 프로젝트에서 Playwright와 Cypress 중 무엇이 더 낫다고 단정하기는 어렵습니다. 더 중요한 것은 팀이 하나의 E2E 표준을 정하고, 실패 로그와 재현 방법을 운영할 수 있느냐입니다. 작은 팀이 두 도구를 동시에 도입하면 테스트 작성 규칙, fixture, CI 설정, 디버깅 방식이 중복됩니다.

도구잘 맞는 상황주의할 점
Playwright여러 브라우저, 병렬 실행, trace 기반 실패 분석, role 기반 locator 전략을 중시하는 팀테스트 데이터 seed와 인증 상태 저장 규칙을 초기에 정해야 함
Cypress브라우저에서 테스트 흐름을 보며 개발하고, 컴포넌트 테스트까지 같은 도구 경험으로 운영하려는 팀Next.js page 전체는 E2E로 보고, component test는 개별 Client Component 중심으로 제한하는 편이 안전함
Jest + RTL기존 Next.js 팀이 이미 Jest 기반 테스트와 mock 체계를 갖고 있는 경우async Server Component 전체를 단위 테스트하려고 무리하지 않아야 함
Vitest + RTL빠른 단위 테스트와 Vite 생태계 경험을 선호하는 팀Next.js 고유 빌드·라우팅 동작은 별도 E2E로 보완해야 함

Playwright를 쓰든 Cypress를 쓰든 locator는 사용자가 보는 기준으로 잡아야 합니다. 버튼 이름, label, role, heading, alt text를 우선 사용하고, 정말 필요한 경우에만 data-testid를 계약으로 둡니다. CSS class와 DOM 순서에 의존하는 테스트는 디자인 수정 때마다 깨져 팀이 테스트를 신뢰하지 않게 됩니다.

8. CI에서는 ‘모든 테스트 매번 실행’보다 단계가 중요하다

초기 SaaS나 정부지원사업 MVP에서는 테스트 예산과 시간이 제한적입니다. 그렇다고 배포 직전 수동 클릭만으로 운영 리스크를 감당하기는 어렵습니다. 권장 실행 단계는 다음과 같습니다.

단계실행 테스트목적
로컬 개발관련 단위 테스트, Client Component 테스트개발자가 빠르게 회귀를 확인
Pull Requesttypecheck, lint, 단위·통합 테스트, 핵심 smoke E2E명백한 오류와 주요 사용자 흐름 차단
스테이징 배포seed DB 기반 권한·가입·관리자 변경 E2E프로덕션 빌드와 가까운 환경 검증
야간 또는 릴리즈 전전체 E2E, 역할 매트릭스, 주요 브라우저, 외부 연동 mock시간이 오래 걸리는 회귀를 안정적으로 탐지
장애 수정 후재현 테스트를 먼저 추가한 뒤 수정같은 장애의 재발 방지

테스트 데이터도 운영 체계의 일부입니다. 관리자 계정, 일반 사용자, 승인 대기 사용자, 결제 실패 사용자, 고객사 A·B 같은 seed가 고정되어야 합니다. 매 테스트마다 난수 데이터만 만들면 실패 원인을 찾기 어렵고, 반대로 모든 테스트가 하나의 계정을 공유하면 순서 의존성이 생깁니다. E2E는 느리기 때문에 테스트 간 격리와 seed reset 전략이 중요합니다.

9. 외주 개발·마이그레이션에서 요청해야 할 산출물

App Router 테스트는 개발이 끝난 뒤 “테스트도 몇 개 넣어주세요”라고 요청하면 좋은 결과가 나오기 어렵습니다. 견적·일정·검수 기준에 다음 산출물이 포함되어야 합니다.

  • 테스트 범위 표: 랜딩, 가입, 관리자, 결제, 권한, 캐시 등 기능별 자동화 여부와 제외 사유
  • 권한 매트릭스: guest, user, manager, admin, super admin이 접근 가능한 page, action, API 목록
  • 테스트 실행 명령: pnpm test, pnpm test:e2e, CI workflow, 환경 변수 예시
  • seed 데이터와 테스트 계정: 역할·테넌트·상태별 계정과 초기화 방법
  • Server Actions 검증 목록: 입력 검증, 인증, 권한, 소유권, revalidation 호출 여부
  • Route Handler 검증 목록: status code, JSON schema, webhook signature, rate limit 또는 인증 실패 응답
  • 실패 분석 자료: Playwright trace, Cypress screenshot·video, 서버 로그 연결 방법
  • 의도적으로 자동화하지 않은 영역: 외부 PG 실결제, 관리자 수동 승인 정책 등 수동 검수 항목

AgentMit은 BizMit 같은 SaaS, 업무 자동화, 관리자 대시보드, 정부지원 MVP를 설계할 때 테스트를 부가 문서가 아니라 운영 아키텍처의 일부로 봅니다. 자체 팀에서 테스트 구조를 잡기 어렵다면, 외주 개발이나 리팩터링을 의뢰할 때 “테스트 코드 몇 개”보다 위 산출물 전체를 요청하는 편이 결과물을 인수받기 쉽습니다.

10. 출시 전 체크리스트

Next.js 관리자 화면 출시 전 테스트 체크리스트
출시 전에는 권한, 폼, 데이터 변경, 캐시, CI 실행법을 문서와 테스트로 남겨야 한다.
  • 주요 랜딩 CTA, 문의·가입 폼, 가격·약관 링크가 E2E smoke에 포함되어 있는가?
  • Server Action마다 인증, 권한, 소유권, 입력 검증 테스트가 있는가?
  • 관리자 화면의 page 접근, 버튼 노출, action 실행, Route Handler 응답을 역할별로 확인했는가?
  • 고객사별 데이터 분리 테스트가 적어도 하나 이상의 E2E 시나리오로 존재하는가?
  • 캐시를 쓰는 화면은 변경 후 즉시 갱신과 지연 갱신을 구분해 테스트했는가?
  • Proxy matcher가 보호해야 할 route를 빠뜨리지 않았는가?
  • 테스트 실패 시 trace, screenshot, server log를 어디서 보는지 문서화했는가?
  • 외부 API, 결제, 이메일, 파일 업로드는 mock과 실제 검수 범위가 분리되어 있는가?
  • 개발자가 새 기능을 추가할 때 참고할 테스트 예시가 가까운 폴더에 있는가?
  • 배포 전 수동 검수 항목과 자동 테스트 항목이 중복 없이 정리되어 있는가?

FAQ

Next.js App Router에서 async Server Component는 Jest로 테스트할 수 있나요?
공식 문서 기준으로 Jest와 Vitest는 async Server Components 단위 테스트를 완전하게 지원하지 않는다고 안내합니다. 데이터 조회 함수와 권한 로직은 단위 테스트하고, 실제 route 렌더링은 E2E로 확인하는 전략이 현실적입니다.
Server Actions는 단위 테스트만 해도 충분한가요?
충분하지 않습니다. 함수 수준에서는 입력·권한·DB 변경 여부를 보고, E2E에서는 폼 제출 후 pending 상태, 오류 메시지, redirect, 화면 갱신을 확인해야 합니다.
Playwright와 Cypress 중 무엇을 선택해야 하나요?
여러 브라우저와 trace 기반 디버깅을 중시하면 Playwright, 브라우저에서 테스트 흐름을 보며 component test까지 같은 도구로 운영하고 싶으면 Cypress가 맞을 수 있습니다. 작은 팀은 둘 중 하나만 표준으로 정하는 것이 좋습니다.
관리자 화면 권한 테스트는 Proxy만 확인하면 되나요?
아닙니다. Proxy는 빠른 리다이렉트에는 유용하지만 최종 권한 검증을 대신하지 않습니다. Server Component 데이터 조회, Server Action 변경, Route Handler 응답에서도 권한을 다시 검증해야 합니다.
정부지원사업 MVP도 테스트 자동화가 필요한가요?
모든 화면을 자동화할 필요는 없지만, 가입·신청 폼, 관리자 승인, 고객사별 데이터 분리, 결제 전후 상태, 핵심 캐시 갱신처럼 검수와 운영에 직접 연결되는 흐름은 자동화하는 것이 좋습니다.

참고한 공식 문서

이 글은 Next.js와 Playwright 등 공식 문서의 테스트 범위, Server Component 경계, Server Actions 보안, Route Handler, Proxy, 캐시 재검증 설명을 실무 의사결정 기준으로 재구성했습니다. 실제 프로젝트에는 사용하는 Next.js 버전, 배포 환경, 인증 라이브러리, 캐시 설정에 맞춰 세부 구성을 다시 확인해야 합니다.

자주 묻는 질문

Next.js App Router에서 async Server Component는 Jest로 테스트할 수 있나요?
공식 문서 기준으로 Jest와 Vitest는 async Server Components 단위 테스트를 완전하게 지원하지 않는다고 안내합니다. 실무에서는 데이터 조회 함수와 권한 로직은 별도 함수로 분리해 단위 테스트하고, 실제 async Server Component 렌더링·Suspense·캐시 동작은 Playwright나 Cypress E2E로 확인하는 방식이 안전합니다.
Server Actions는 단위 테스트만 해도 충분한가요?
아닙니다. Server Actions는 입력 검증, 인증, 권한, 소유권, 재검증 호출을 함수 수준에서 테스트해야 하고, 폼 제출 후 오류 메시지·pending 상태·redirect·화면 갱신은 E2E로 확인해야 합니다. 특히 관리자 변경, 결제, 초대, 삭제처럼 데이터가 바뀌는 기능은 두 층을 모두 권장합니다.
Next.js App Router E2E는 Playwright와 Cypress 중 무엇을 선택해야 하나요?
둘 다 사용할 수 있지만, 작은 팀은 하나만 표준으로 정하는 것이 좋습니다. 여러 브라우저, 병렬 실행, trace 기반 디버깅을 중시하면 Playwright가 잘 맞고, 개발자가 브라우저에서 테스트 흐름을 보며 컴포넌트 테스트까지 함께 운영하려면 Cypress가 익숙할 수 있습니다. 기존 팀의 경험과 CI 안정성이 선택 기준입니다.
관리자 화면 권한 테스트는 Proxy 또는 Middleware 리다이렉트만 확인하면 되나요?
부족합니다. Proxy는 빠른 리다이렉트나 optimistic check에는 유용하지만 전체 세션·권한 검증을 대신해서는 안 됩니다. 관리자 화면은 페이지 접근, 메뉴 노출, Server Action 실행, Route Handler 응답, 테넌트 데이터 접근을 각각 테스트해야 합니다.
정부지원사업 MVP나 초기 SaaS도 테스트 자동화가 필요한가요?
모든 화면을 자동화할 필요는 없습니다. 다만 회원가입, 문의·신청 폼, 관리자 승인, 결제 전후 상태, 고객사별 데이터 분리, 캐시 재검증처럼 사업 운영과 검수에 직접 연결되는 흐름은 최소 E2E와 함수 테스트를 남기는 편이 인수인계와 유지보수 비용을 줄입니다.
  • Company. 주식회사 에이전트밋
  • Addr.부산광역시 부산진구 서전로 8, 6층 101호(부전동) CEO. 윤성훈 Email. agentmit@naver.com
  • BR. 333-87-04232 TEL. 0507-1314-2790
Copyright © 2026 ~ 에이전트밋. All rights reserved.