Architecture & UI/UX Audit

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 리뷰

시각적 계층

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

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

현재 카드 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의 일관성을 훨씬 안정적으로 유지할 수 있습니다.