프론트엔드 UI/UX 감사 프롬프트

Next.js App Router 프로젝트 정보를 넣으면 폴더 구조, UI 구현, 컴포넌트 재사용, 디자인 시스템, 레이아웃 구조를 코드 없이 검토합니다.

분류	디자인 › 화면·제품 설계
태그	분석검토개발자

프롬프트 (영어 본문 · 답은 한국어로 옵니다)

Act as a senior frontend engineer and product-focused UI/UX reviewer with experience building scalable web applications.

Your task is NOT to write code yet.

First, carefully analyze the project based on:

1. Folder structure (Next.js App Router architecture, route groups, component organization)
2. UI implementation (layout, spacing, typography, hierarchy, consistency)
3. Component reuse and design system consistency
4. Separation of concerns (layout vs pages vs components)
5. Scalability and maintainability of the current structure

Context:
This is a modern Next.js (App Router) project for a developer community platform (similar to Reddit/StackOverflow hybrid).

Instructions:

* Start by analyzing the folder structure and explain what is good and what is problematic
* Identify architectural issues or anti-patterns
* Analyze the UI visually (hierarchy, spacing, consistency, usability)
* Point out inconsistencies in design (cards, buttons, typography, spacing, colors)
* Evaluate whether the layout system (root layout vs app layout) is correctly implemented
* Suggest improvements ONLY at a conceptual level (no code yet)
* Prioritize suggestions (high impact vs low impact)
* Be critical but constructive, like a senior reviewing a real product

Output format:

1. Overall assessment (brief)
2. Folder structure review
3. UI/UX review
4. Design system issues
5. Top 5 high-impact improvements

Do NOT generate code yet.
Focus only on analysis and recommendations.

어떤 프롬프트인가

개발자 커뮤니티 플랫폼을 전제로 아키텍처와 UI/UX를 비판적으로 리뷰하는 프롬프트다. 코드 작성은 금지하고 개념적 개선안과 상위 5개 영향도 높은 항목을 요구한다.

모델 비교

ChatGPT가 형식·정확성·균형에서 가장 우수하다. Claude는 가장 구체적이나 장황하고, Gemini는 선명하지만 과도한 단정이 있다.

ChatGPT종합 1위

46/ 50

＋ 근거와 제안을 균형 있게 구성해 가장 안정적이다.

－ 반응형·데이터 계층 논의가 다소 길고 추정적이다.

Claude

43/ 50

＋ 제공된 구조와 UI 문제를 촘촘히 연결해 진단했다.

－ 요구보다 길고 일부 미확인 영역까지 과도하게 확장했다.

Gemini

42/ 50

＋ 핵심 부채와 개선 우선순위를 선명하게 제시했다.

－ 99% 단정과 8pt 처방 등 근거 없는 확신이 섞였다.

기준	ChatGPT	Claude	Gemini	앞선 모델
지시 준수	10	9	9	ChatGPT +11%
정확성	9	9	7	동점
구체성	9	10	9	Claude +11%
구성·가독성	10	9	9	ChatGPT +11%
분량 적정성	8	6	8	동점

gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-24). 측정값이 아니라 AI 심사 결과입니다.

답 전문 보기

같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.

넣은 입력

[붙여 넣은 자료]
프로젝트: DevTalk (개발자 커뮤니티 플랫폼, Next.js 14 App Router + TypeScript + Tailwind)

폴더 구조:
app/
  (auth)/
    login/page.tsx
    signup/page.tsx
  (main)/
    layout.tsx
    page.tsx
    posts/
      [id]/page.tsx
      write/page.tsx
    profile/[username]/page.tsx
  layout.tsx
  globals.css
components/
  Button.tsx
  Card.tsx
  PostCard.tsx
  Header.tsx
  Sidebar.tsx
  ui/
    Modal.tsx
    Badge.tsx
lib/
  supabase.ts
  utils.ts

UI 현황:
- 게시글 카드마다 padding 값이 12px, 16px, 20px로 제각각이라 리스트가 들쭉날쭉해 보임
- 버튼 컴포넌트가 Button.tsx와 ui/ 안에 중복 존재, 스타일도 다름(모서리 radius 4px vs 8px)
- 헤더는 루트 layout.tsx에, 사이드바는 (main)/layout.tsx에 각각 다른 방식으로 선언됨
- 다크모드는 피드 페이지만 적용되고 글쓰기 페이지는 라이트모드 고정
- h1~h3 제목에 Tailwind 임의값(text-[22px], text-[19px])을 직접 써서 타이포 스케일이 없음

이 구조와 UI 상태를 기준으로 분석해 주세요.

gpt-5.6-luna (codex CLI · 에이전트 하네스) · 실행일 2026-09-24

1. 전체 평가

현재 구조는 Next.js App Router의 기본 방향을 잘 따르고 있으며, 기능 확장도 가능한 출발점입니다. 특히 (auth)와 (main) route group을 분리한 점은 좋습니다.

다만 현재는 레이아웃 책임, UI 컴포넌트 위치, 디자인 토큰이 충분히 정리되지 않아 페이지가 늘어날수록 다음 문제가 커질 가능성이 높습니다.

인증 페이지와 메인 서비스 UI의 레이아웃 경계가 불명확함
동일한 역할의 컴포넌트가 중복됨
페이지별 스타일 편차가 커지고 있음
다크모드와 타이포그래피가 일관되지 않음
디자인 시스템 없이 Tailwind 임의값에 의존하고 있음

현재 상태는 “작동 가능한 초기 제품”에는 적합하지만, 커뮤니티 규모와 기능이 커지기 전 구조적 정리가 필요합니다.

2. 폴더 구조 리뷰

잘된 점

(auth)와 (main) route group을 사용해 URL에는 영향을 주지 않으면서 레이아웃을 분리한 점은 적절합니다.
게시글 상세, 작성, 프로필이 기능 단위로 자연스럽게 배치되어 있습니다.
공통 컴포넌트를 components로 분리한 점은 페이지 컴포넌트의 책임을 줄이는 데 도움이 됩니다.
lib에 Supabase와 유틸리티를 둔 것은 외부 서비스 및 공통 로직을 페이지에서 분리하려는 방향으로 적절합니다.
app/globals.css를 전역 스타일 진입점으로 둔 것도 Next.js App Router 구조에 맞습니다.

주요 문제

루트 레이아웃의 책임이 과도함

app/layout.tsx는 일반적으로 다음 역할에 집중하는 것이 안정적입니다.

html, body 구조
전역 CSS
전역 폰트
메타데이터
전역 Provider
테마 Provider

현재 헤더가 루트 레이아웃에 선언되어 있다면 로그인과 회원가입 페이지에도 메인 서비스 헤더가 노출될 가능성이 있습니다. 인증 화면과 메인 화면의 사용자 흐름이 다르기 때문에, 헤더를 루트 레이아웃에 두는 것은 레이아웃 경계를 흐리게 만듭니다.

헤더와 사이드바는 (main)/layout.tsx에서 함께 관리하는 편이 더 자연스럽습니다. (auth)에는 인증 화면에 맞는 별도 레이아웃이 필요할 수 있습니다.

메인 레이아웃의 쉘 책임이 명확하지 않음

현재 사이드바만 (main)/layout.tsx에 있고 헤더는 루트에 있습니다. 이 구조는 메인 화면의 공통 UI가 서로 다른 계층에 분산된 상태입니다.

메인 서비스의 공통 쉘은 다음 요소를 하나의 레이아웃 책임으로 보는 것이 좋습니다.

헤더
사이드바 또는 모바일 네비게이션
콘텐츠 최대 너비
페이지 간 공통 여백
테마 적용 범위

이렇게 해야 피드, 게시글 상세, 글쓰기, 프로필 간 시각적 구조가 일관됩니다.

컴포넌트 분류 기준이 불명확함

Button.tsx, Card.tsx, PostCard.tsx, Header.tsx, Sidebar.tsx가 모두 같은 레벨에 있고 ui/에는 Modal.tsx, Badge.tsx가 있습니다. 현재 구조만 보면 다음 구분이 혼재되어 있습니다.

범용 UI 컴포넌트
도메인 컴포넌트
페이지 또는 레이아웃 컴포넌트

예를 들어 Button, Card, Badge, Modal은 범용 UI에 가깝고, PostCard는 DevTalk 도메인 컴포넌트입니다. 두 종류를 같은 기준 없이 배치하면 컴포넌트 수가 늘어날수록 찾기 어렵고 의존 관계가 복잡해집니다.

데이터 접근 계층이 확장에 취약할 수 있음

lib/supabase.ts 하나에 클라이언트, 서버, 관리자 권한 접근이 모두 섞이면 인증 및 데이터 접근 문제가 발생하기 쉽습니다.

특히 App Router에서는 다음 경계를 명확히 해야 합니다.

브라우저용 Supabase 클라이언트
서버 컴포넌트용 클라이언트
Route Handler 또는 Server Action용 접근
인증 세션 확인 로직
게시글/댓글/프로필 도메인 쿼리

현재 폴더 구조만으로는 이 책임들이 분리되어 있는지 확인하기 어렵고, 규모가 커질 경우 먼저 문제가 될 가능성이 높습니다.

3. UI/UX 리뷰

시각적 계층

개발자 커뮤니티 플랫폼에서는 다음 계층이 명확해야 합니다.

전역 탐색과 사용자 상태
페이지 제목과 주요 액션
게시글 목록 또는 상세 콘텐츠
메타데이터와 보조 정보
댓글, 태그, 반응 등 부가 인터랙션

현재 카드 padding이 12px, 16px, 20px로 섞여 있으면 콘텐츠 밀도와 중요도가 의도와 다르게 보입니다. 같은 유형의 게시글 카드라면 동일한 내부 여백과 제목-본문-메타 정보 간 간격을 공유해야 합니다.

레이아웃과 여백

피드형 UI에서는 반복되는 카드 사이의 간격, 카드 내부 padding, 페이지 좌우 여백이 제품의 완성도를 크게 좌우합니다. 현재처럼 카드마다 여백이 다르면 다음과 같은 인상을 줍니다.

콘텐츠가 불안정하게 배치됨
어떤 카드가 더 중요한지 기준이 불분명함
모바일에서 밀도가 예측되지 않음
컴포넌트 재사용이 제대로 되지 않는 느낌을 줌

페이지 컨테이너의 최대 너비, 좌우 여백, 섹션 간 간격, 카드 간 간격을 체계적으로 정의해야 합니다.

헤더와 사이드바

헤더와 사이드바가 서로 다른 레이아웃 계층에서 선언되면 콘텐츠 시작 위치와 반응형 동작이 어긋날 수 있습니다.

특히 확인해야 할 부분은 다음과 같습니다.

헤더 높이와 사이드바 상단 기준선의 일치 여부
콘텐츠 영역의 좌우 여백
사이드바가 고정인지 스크롤되는지
모바일에서 사이드바가 어떻게 대체되는지
현재 위치를 나타내는 네비게이션 상태
글쓰기와 로그인 같은 주요 액션의 노출 위치

메인 쉘은 데스크톱과 모바일 모두에서 동일한 정보 구조를 유지해야 합니다.

다크모드

피드 페이지만 다크모드를 지원하고 글쓰기 페이지가 라이트모드로 고정된 것은 단순한 스타일 문제가 아니라 사용자 경험의 단절입니다.

사용자는 페이지 이동 시 다음 요소가 유지되기를 기대합니다.

테마
배경색
텍스트 대비
카드 표면 색상
입력 필드 스타일
버튼 상태

테마는 페이지 단위가 아니라 애플리케이션 또는 메인 레이아웃 단위에서 일관되게 적용되어야 합니다. 특히 글쓰기 화면은 장시간 머무르는 화면이므로 다크모드 누락의 불편이 큽니다.

타이포그래피

text-[22px], text-[19px] 같은 임의값을 직접 사용하는 방식은 초기에는 빠르지만 제품 전체의 계층을 무너뜨립니다.

현재는 다음 기준이 필요합니다.

페이지 제목
섹션 제목
게시글 제목
본문
메타 정보
라벨과 보조 텍스트
버튼 텍스트

h1~h3가 페이지마다 다른 크기와 굵기를 가지면 사용자는 화면 구조를 일관되게 파악하기 어렵습니다. 특히 게시글 제목과 페이지 제목의 상대적 크기가 명확해야 합니다.

4. 디자인 시스템 이슈

컴포넌트 중복

Button.tsx와 ui/ 내부의 버튼이 중복되고 모서리 반지름도 4px와 8px로 다르다면, 앞으로 버튼 스타일이 계속 분기될 가능성이 큽니다.

버튼은 최소한 다음 기준을 통합해야 합니다.

기본 형태
크기
주요/보조/위험 액션
로딩 상태
비활성 상태
아이콘 포함 여부
radius
focus 상태

카드 스타일 불일치

게시글 카드, 일반 카드, 상세 콘텐츠 카드가 서로 다른 padding과 radius를 사용하면 페이지 간 시각적 문법이 달라집니다.

카드 컴포넌트에는 적어도 다음 토큰이 필요합니다.

표면 배경
테두리
그림자
radius
내부 padding
hover 상태
다크모드 표면 색상

색상 토큰 부족

다크모드가 일부 페이지에만 적용되는 것은 색상 체계가 컴포넌트별로 직접 작성되어 있을 가능성을 보여줍니다. 배경색, 텍스트색, muted 색상, border 색상, accent 색상을 역할 기반으로 관리해야 합니다.

색상을 페이지별로 직접 선택하면 다음 문제가 생깁니다.

같은 의미의 색상이 조금씩 달라짐
다크모드 변환이 어려움
접근성 대비 검토가 어려움
브랜드 색상 변경 비용이 커짐

간격 토큰 부족

현재 카드 padding 편차는 spacing 토큰 부재의 명확한 신호입니다. 최소한 페이지 여백, 섹션 간격, 카드 간격, 콘텐츠 내부 간격에 공통 기준이 필요합니다.

반응형 기준 불명확

현재 구조 설명에서는 모바일에서 다음 요소가 어떻게 변하는지 확인되지 않습니다.

사이드바
헤더 액션
게시글 카드
글쓰기 입력 영역
프로필 레이아웃

개발자 커뮤니티는 모바일 이용 비중도 높기 때문에 데스크톱 레이아웃을 축소하는 방식이 아니라, 모바일에서 우선순위가 재배치되는 반응형 설계가 필요합니다.

5. 우선순위가 높은 개선 5가지

1. 레이아웃 책임 재정의 — 최우선

루트 레이아웃은 전역 기반만 담당하고, 헤더·사이드바·메인 콘텐츠 쉘은 (main)/layout.tsx로 통합하는 것이 좋습니다. (auth)에는 인증 전용 레이아웃을 둬 메인 UI가 로그인과 회원가입 화면에 섞이지 않게 해야 합니다.

2. 버튼, 카드, 타이포그래피를 단일 디자인 시스템으로 통합

중복 Button을 하나로 정리하고 카드의 padding, radius, border, 상태를 표준화해야 합니다. 동시에 h1~h3와 본문, 메타 텍스트에 일관된 타입 스케일을 적용해야 합니다.

3. 테마 적용 범위를 애플리케이션 전체로 확장

피드뿐 아니라 글쓰기, 게시글 상세, 프로필, 인증 화면까지 테마 정책을 명확히 해야 합니다. 사용자의 테마 선택이 라우트 이동 시 유지되는지와 입력 요소까지 동일하게 적용되는지를 우선 확인해야 합니다.

4. 공통 UI와 도메인 UI를 분리

Button, Card, Modal, Badge 같은 범용 UI와 PostCard, Header, Sidebar 같은 도메인·레이아웃 컴포넌트의 분류 기준을 통일해야 합니다. 이 작업은 단순한 폴더 이동보다 컴포넌트 책임과 의존 방향을 정리하는 것이 핵심입니다.

5. 데이터 접근과 인증 경계를 명확히 설계

Supabase 접근 로직을 서버/브라우저/인증/도메인 쿼리 기준으로 나누고, 페이지가 직접 데이터베이스 세부 구현을 알지 않도록 해야 합니다. 이후 댓글, 투표, 알림, 검색 기능이 추가될 때 유지보수 비용을 크게 줄일 수 있습니다.

종합하면, 가장 먼저 손봐야 할 부분은 시각적 디테일보다 “레이아웃 경계와 공통 디자인 규칙”입니다. 이 두 가지가 정리되면 카드, 버튼, 다크모드, 반응형 UI의 일관성을 훨씬 안정적으로 유지할 수 있습니다.

같은 분류의 프롬프트

7대7 축구 팀 앱 설계 프롬프트
접근성 감사자 역할을 맡기는 프롬프트
접근성 감사자 역할 프롬프트
접근성 전문가 역할 프롬프트
접근성 테스트 워크플로 프롬프트

많이 찾는 것

분류