프로젝트: 야채랑(관통 프로젝트) 역할: Frontend (전반 디자인 + 프론트 기능 구현) 집중 포인트: 로그인 상태 기반 접근 제어(인증/인가) + 예외처리 + UX 안정화
1. 프로젝트 한 줄 소개
야채랑 프로젝트에서 프론트를 맡아 화면 전반의 디자인과 기능을 구현했다.
특히 이번 프로젝트에서는 로그인 여부에 따라 접근 가능한 기능/페이지가 달라지는 구조를 프론트에서 안정적으로 처리하는 데 집중했다.
단순히 “페이지가 보이게 만드는 것”이 아니라, 비로그인 상태/세션 만료/권한 없음 등 다양한 상황에서도 흐름이 끊기지 않도록 예외처리와 안내를 강화하는 것이 핵심이었다.
2. 내가 맡은 역할
2.1 전반적인 디자인(UI/UX)
페이지 전반의 레이아웃/간격/컴포넌트 톤 통일
사용자 흐름을 기준으로 버튼/입력/정보 배치 정리
“다음 행동”이 자연스럽게 이어지도록 동선 개선
2.2 프론트 기능 구현
로그인/로그아웃 상태에 따른 화면 분기
페이지 이동(라우팅)과 API 연동 시 상태 처리
폼 입력/검증 및 요청 결과 반영
2.3 이번 프로젝트에서 가장 집중한 것: 로그인 기반 접근 제어 + 예외처리
로그인 상태일 때만 접근 가능한 페이지/기능 분리
비로그인 사용자가 접근 시도 시의 처리를 명확히 설계
로그인 만료/토큰 오류/권한 없음 등의 케이스에서 UI가 깨지지 않게 방어
3. 로그인 기반 접근 제어를 다루며 했던 고민
프로젝트를 진행하면서 가장 신경 쓴 부분은 “사용자가 어떤 상태인지에 따라, 가능한 행동과 접근 범위를 명확하게 제한하는 것”이었다. 프론트에서는 클릭/이동 같은 사용자의 행동이 먼저 발생하고, 이후에 API 응답이나 인증 여부가 판별되는 경우가 많아서 아래 상황을 계속 고려해야 했다.
비로그인 상태에서 로그인 전용 페이지 URL로 직접 접근
로그인 사용자에게만 보이는 버튼/기능이 비로그인 화면에 노출되는 문제
로그인 상태가 풀린 상태에서 요청이 발생했을 때(예: 401/403)
새로고침으로 상태가 초기화되며 잠깐 “로그인처럼 보였다가 아닌 상태”로 바뀌는 순간
이걸 제대로 잡지 않으면 사용자는 “왜 안 되지?”만 남고 화면은 깨질 수 있다. 그래서 이번 프로젝트에서는 접근 제어 자체를 하나의 기능으로 보고 설계/구현했다.
4. 구현/개선 포인트 (로그인 중심)
4.1 라우트(페이지) 접근 제어
문제: 로그인 전용 페이지를 비로그인 사용자가 직접 접근할 수 있는 가능성
대응:
보호가 필요한 페이지는 인증 상태를 확인한 뒤 접근 허용
비로그인 접근 시 로그인 페이지로 이동 + 안내 메시지 제공
효과: “페이지는 열리는데 기능이 안 됨” 같은 어색한 UX를 줄이고 접근 흐름이 깔끔해졌다.
4.2 UI 요소 노출 제어(버튼/메뉴/액션)
문제: 로그인 사용자에게만 제공되어야 할 버튼이 비로그인 화면에도 보이면 혼란이 생김
대응:
로그인 상태에 따라 버튼/메뉴를 분기 렌더링
클릭 시점에 한 번 더 인증 상태를 확인해 방어
효과: 사용자는 “가능한 행동만” 보게 되고 쓸데없는 클릭/에러를 줄였다.
4.3 인증 만료/권한 오류 예외처리
문제: 토큰 만료나 권한 없음이 발생하면 화면이 멈추거나 데이터가 비어도 이유를 모름
대응:
API 실패 응답에서 인증 관련 에러를 분기 처리
“로그인이 필요합니다 / 다시 로그인 해주세요” 안내 + 복구 경로 제공(로그인 이동, 재시도)
효과: 실패 상황에서도 사용자가 다음 행동을 할 수 있게 됐다.
4.4 새로고침/초기 로딩 타이밍 이슈
문제: 새로고침 시 인증 상태 확인 전 UI가 순간적으로 잘못 보일 수 있음
대응:
인증 상태 확인 전에는 로딩 상태를 보여주거나 보호 라우팅을 보류
인증 확인 이후에만 화면을 렌더링하도록 흐름 정리
효과: 깜빡이거나 갑자기 튕기는 듯한 UX를 줄였다.
5. 트러블슈팅 정리 (Frontend)
프로젝트를 진행하면서 단순히 “기능이 동작한다”에서 끝나지 않고, 데이터/성능/상태/확장성 관점에서 화면이 흔들리는 지점을 계속 마주했다. 아래 4가지는 실제로 개발 중 반복적으로 문제로 드러났고, 해결 과정에서 프론트 구조를 한 단계 정리하게 만든 핵심 이슈였다.
5.1 데이터 형태·품질이 불안정한 상황에서의 UI 예외 처리 문제
상황
API 응답의 데이터가 항상 동일한 형태로 오지 않거나, 특정 필드가 누락/빈 값인 상태로 내려오는 케이스가 있었다. 초반에는 정상 케이스를 기준으로 UI를 구성해서, 일부 상황에서 화면이 깨지거나 의도하지 않은 UI가 노출되는 문제가 발생했다.
원인
“항상 완전한 데이터가 온다”는 전제를 기반으로 렌더링 로직을 작성
타입/스키마가 불명확하거나, nullable 필드를 안전하게 처리하지 않음
빈 상태(Empty), 부분 데이터(Partial), 실패(Error) 상태를 UI 상태로 분리하지 않음
해결
예외 상황을 고려한 UI 기준 재정의
데이터는 기본적으로 불완전할 수 있다는 전제로 렌더링 기준을 설계
값이 없을 때의 대체 UI(placeholder, empty state)를 명확히 구성
렌더링 전 안전 처리(널 가드, optional chaining, 기본값) 적용
결과
특정 데이터 누락/빈 값 상황에서도 화면이 깨지지 않고,
사용자가 “왜 이런 화면이 뜨는지” 이해할 수 있는 안내 흐름이 생겼다.
5.2 많은 데이터를 동시에 다루는 화면에서의 성능 문제
상황
데이터가 많은 화면에서 렌더링이 느려지거나, 필터/탐색/페이지 이동 시 체감 성능이 떨어지는 문제가 발생했다. 특히 동일한 데이터 요청이 반복되거나, 화면 이동 후 돌아왔을 때 다시 로딩이 발생해 UX가 끊기는 경우가 있었다.
원인
불필요한 재요청(동일 API 반복 호출)
화면 전환 시 상태가 매번 초기화되어 “다시 불러오기”가 자주 발생
리스트 렌더링에서 불필요한 리렌더(키 관리/메모이제이션 부족 등)
해결
캐싱과 상태 관리를 통한 성능·UX 개선
데이터 요청 비용을 줄이기 위해 캐싱 전략을 도입/강화
화면 흐름을 고려해 “재사용할 데이터”는 유지, “새로 불러올 데이터”는 명확히 분리
요청/렌더링 단계를 정리해서 로딩 체감 최소화(로딩 UI, 점진적 렌더링)
결과
같은 화면을 다시 방문할 때 불필요한 로딩이 줄고, 데이터가 많은 화면에서도 인터랙션이 훨씬 부드러워졌다.
5.3 상태 유지가 필요한 화면과 초기화가 필요한 화면의 충돌
상황
어떤 화면은 사용자가 이전 입력/필터/스크롤 위치 등을 유지한 채로 돌아오길 원하지만, 반대로 어떤 화면은 들어갈 때마다 초기 상태로 시작해야 UX가 자연스러웠다. 이 요구가 섞이면서 특정 화면에서는 “상태가 남아있어서 혼란” 또는 “상태가 날아가서 불편” 문제가 동시에 발생했다.
원인
상태의 생명주기(scope)를 명확히 구분하지 않고, 동일 방식으로 관리
라우팅/컴포넌트 언마운트 시점에 어떤 상태가 유지/초기화되어야 하는지 기준 부재
전역 상태와 로컬 상태의 역할 분리 미흡
해결
화면을 두 타입으로 분리해서 기준을 세움
유지형 화면: 사용자가 돌아왔을 때 맥락을 이어야 하는 화면(필터/검색/리스트 등)
초기화형 화면: 항상 새 작업을 시작해야 하는 화면(작성/등록 폼 등)
UX 규칙을 먼저 정하고, 그 규칙에 맞춰 상태 범위를 설계
유지해야 할 상태는 상위/전역에서 관리하거나 캐싱
초기화해야 할 상태는 진입 시점/이탈 시점에 명시적으로 reset
결과
“유지해야 하는 건 남고, 초기화해야 하는 건 초기화되는” 일관된 흐름이 생겨
화면 이동 후 사용자 혼란이 크게 줄었다.
5.4 기능 확장에 따른 UI/UX 일관성 관리 문제
상황
기능이 추가되면서 화면과 컴포넌트가 늘어났고, 팀 작업/수정이 반복되면서 UI가 점점 제각각이 되는 문제가 생겼다. 버튼 크기, 메시지 톤, empty/error 처리 방식, 마진/패딩 등이 화면마다 달라질 위험이 있었다.
원인
UI 요소를 화면마다 개별 구현하면서 규칙이 분산됨
공통 컴포넌트/디자인 규칙이 느슨하거나, 적용이 강제되지 않음
예외 상황 처리(에러/빈 값/로딩) 방식이 컴포넌트마다 달라짐
해결
공통 컴포넌트와 UX 규칙 통합
버튼/인풋/모달/알림/에러/빈 상태 등을 공통 컴포넌트로 표준화
“로딩/에러/빈 상태” 표현 규칙을 팀/프로젝트 레벨에서 통일
UI 요소는 개별 구현이 아니라 공통 규칙으로 관리하도록 구조화
결과
기능이 확장되어도 UI 톤과 동작이 흔들리지 않았고,
유지보수(수정/추가)가 훨씬 쉬워졌다.
5.5 해결 전략 요약 (Solution)
공통 컴포넌트와 UX 규칙 통합 UI 요소를 개별 구현이 아닌 공통 규칙과 컴포넌트로 관리
캐싱과 상태 관리를 통한 성능·UX 개선 데이터 요청 비용과 사용자 흐름을 함께 고려한 구조 설계
예외 상황을 고려한 UI 기준 재정의 모든 데이터를 “정상 케이스”로 가정하지 않고 예외를 기본 전제로 UI 기준을 설계
6. 잘한 점(Keep)
전반적인 UI를 통일감 있게 구성하려고 노력했다.
기능 구현을 사용자 흐름 관점에서 점검했다.
로그인 기반 접근 제어를 중심으로 예외처리를 끝까지 챙겼다.
제출용 기능 구현을 넘어, 실제로 “쓸 수 있는 화면”에 가깝게 마무리했다.
7. 아쉬운 점(Problem)
초반에 전체 구조/흐름 파악이 늦어 우선순위가 흔들린 적이 있었다.
예외처리를 후반에 몰아서 처리하게 되어 안정화 시간이 촉박했다.
8. 한 줄 회고
야채랑 프로젝트에서 나는 프론트로서 디자인과 기능을 담당했고, 특히 로그인 기반 접근 제어와 예외처리를 중심으로 완성도를 끝까지 끌어올렸다.
