고급 프로젝트: GlobalNomad

soo2051 — Fri, 21 Mar 2025 22:59:08 +0900

프로젝트 소개

프로젝트 인원 : 프론트엔드 5명
기간 : 25.01.17 - 25.02.26
프로젝트 : 사용자가 체험을 등록하고 예약할 수 있는 온라인 체험 예약 서비스
GitHub: https://github.com/codeitFE11-part4-team2/globalnomad
협업 : GitHub, Notion, Discord
기술 스택 : React, Next.js(App Route), Tailwind CSS

‍ 내 역할

페이지네이션 공통 컴포넌트 구현
체험 상세 페이지 구현

프로젝트 과정

API 연동 – Swagger 기반 백엔드 API 사용

이번 프로젝트에서는 코드잇 측에서 제공한 Swagger 문서를 기반으로 한 API를 사용했습니다. Swagger 문서는 명세가 잘 정리되어 있었기 때문에, 빠르게 데이터 구조를 파악하고 프론트엔드에서 필요한 요청을 구현할 수 있었습니다.

컴포넌트 구조와 역할 분담

프로젝트는 다음과 같은 페이지 단위로 구성되어 있었으며, 각각을 컴포넌트 중심으로 분할하여 개발했습니다.

메인 페이지
로그인/회원가입 페이지
체험 상세페이지
내 정보
후기 작성
예약 내역/관리
체험 등록/관리/수정
예약 현황

컴포넌트는 재사용성과 유지보수성을 고려하여 기능 단위로 나누었으며, 각 기능별 디렉토리 구조를 통해 파일 관리를 체계화했습니다.

문제 및 해결 과정

문제 (1) - 체험 예약 흐름 설계의 복잡성

1. 문제

체험 예약 기능을 구현하면서 다음과 같은 복합적인 요구사항을 만족시켜야 했습니다:

사용자가 날짜, 시간, 인원을 입력해야만 예약 가능하도록 구성
PC, 태블릿과 모바일 UI를 동시에 고려하여 UX를 설계
사용자가 이미 예약한 시간대는 예약 불가능해야 하며, 이를 사용자에게 명확히 안내할 수 있어야 함

특히 사용자의 예약 내역을 제외한 시간만을 보여주기 위해 백엔드에서 제공하는 두 API (전체 예약 가능 시간, 나의 예약 내역)를 비교하여 UI에 반영 가능한 시간만 필터링하는 과정이 필요했습니다. 그러나 이 비교 로직은 단순하지 않았습니다. 두 API는 별도로 제공되기 때문에 비동기 요청 간 타이밍 보장, 데이터 동기화, 그리고 형식이 다른 시간 정보 비교 로직을 직접 구현해야 했고, 그 과정에서 UI와 상태의 일치가 꼬이는 문제가 발생했습니다.

2. 해결방식

예약 기능을 구현하는 과정에서, getAvailableSchedules()로 전체 예약 가능 시간대를 가져오고, fetchMyReservations()를 통해 사용자의 기존 예약 내역도 함께 불러왔습니다. 이후 format과 filter를 활용하여 두 데이터를 비교하고, 중복되는 시간대를 제거한 뒤 실제로 예약 가능한 시간만 UI에 표시하려고 했습니다. 그러나 비동기 데이터 처리 순서 문제와 비교 로직의 복잡성으로 인해 필터링이 정상적으로 작동하지 않았고, 원하는 대로 UI에서 사전에 예약 불가 시간을 제거하는 데에는 실패했습니다. 이에 따라 사용자가 이미 신청한 시간대를 선택했을 경우, 예약 시도 시점에서 alert()을 통해 불가능하다는 안내 메시지를 출력하는 방식으로 대체했습니다.

기본적으로 다음과 같은 흐름으로 예약 가능 시간대를 필터링하려고 시도했습니다:

getAvailableSchedules()를 통해 전체 예약 가능 시간대를 받아오고, fetchMyReservations()를 통해 현재 사용자의 예약 내역을 받아왔습니다. 이후 두 데이터셋을 format()과 filter() 등을 사용해 날짜 및 시간 형식을 맞추고, 중복된 시간대를 제거한 리스트를 UI에 표시하려고 했습니다. 하지만 이 접근은 다음과 같은 문제점이 있었습니다

두 비동기 요청의 순서를 보장하지 않음: UI가 먼저 렌더링되거나, 하나의 데이터가 늦게 도착하면서 null, undefined, 혹은 빈 배열 상태로 잘못된 필터링이 일어남
형식 불일치와 비교 로직의 복잡성: 시간 정보가 단순 문자열이 아닌 startTime, endTime 쌍으로 제공되어, 두 리스트를 비교하는 로직이 단순히 format()이나 filter()만으로는 안정적으로 작동하지 않음

결과적으로 UI에서 예약 가능한 시간만 미리 제거하는 데 실패했으며, 대신 사용자가 이미 예약한 시간대를 선택할 경우 예약 시도 시점에서 alert()으로 안내하는 방식으로 제한을 걸어야 했습니다.

3. 결과

예약 흐름의 주요 부분은 대부분 정상적으로 동작했지만, 사용자 예약 내역과 전체 스케줄을 완전히 비교해 사전에 필터링하는 로직에는 실패했습니다. 대신 예약 단계에서 alert를 통해 예약 불가능 안내를 제공하는 방식으로 구현을 마무리했습니다.

→ 개선 방향

다음과 같은 구조로 개선하는 것이 바람직하다고 판단했습니다:

React Query의 비동기 흐름 관리 기능을 활용
useQuery를 사용하여 두 API(getAvailableSchedules, fetchMyReservations)를 각각 독립적으로 호출하되, 두 데이터가 모두 성공적으로 fetch되었을 때에만 렌더링 또는 필터링 로직을 실행하도록 구성합니다.
React Query의 캐싱 기능 활용
동일한 사용자 혹은 동일한 월 기준으로 반복해서 예약 정보를 요청하는 경우, React Query가 내부적으로 데이터를 캐싱하고 재요청을 방지하거나 최소화하여 불필요한 로딩과 중복 요청을 줄일 수 있도록 합니다.
두 데이터의 구조적 차이를 명확히 분석하고 비교 로직을 리팩토링
단순히 format()과 filter()로 비교하는 것이 아니라, 예약 가능 시간은 { date, times: [{ startTime, endTime }] } 구조, 내 예약 내역은 { date, startTime, endTime } 구조이므로 날짜 + 시간 조합을 기준으로 중첩 루프 혹은 해시맵 등으로 비교하는 방법을 사용해 보는 것도 좋을 것이라고 생각합니다. 중첩 루프는 두 배열을 각각 순회하면서 하나하나 직접 비교하는 방식이고, 해시맵은 비교 대상 데이터를 사전에 Map 형태로 정리해두고, 빠르게 조회하는 방식으로, 초기에는 중첩 루프도 괜찮지만, 조금 복잡하더라도 해시맵을 선택하여 리팩토링해 보는 것도 좋을 것 같습니다.
필터링된 데이터만 AvailableTimes 컴포넌트에 전달

문제 (2) - 후기 목록 로딩 성능 및 페이지네이션

1. 문제

후기가 많아질수록 모든 리뷰 데이터를 한 번에 렌더링하면 초기 로딩 시간이 길어지고, 사용자 입장에서 리스트 탐색이 불편해질 수 있었습니다. 또한 후기 평균 평점, 총 리뷰 수 등 메타 정보를 함께 제공해야 했기 때문에, 데이터 처리와 렌더링 흐름의 분리도 필요했습니다.

2. 해결방식

후기 목록은 ReviewList 컴포넌트에서 fetchReviews() API를 통해 현재 페이지 기준의 데이터만 가져오도록 분리하였으며, useState와 useEffect를 활용해 currentPage, totalPages, totalCount, averageRating 등의 상태를 개별적으로 관리하면서 후기 목록과 메타 정보를 함께 구성하였습니다. 또한, 사용자가 직접 페이지를 넘길 수 있도록 커스텀 Pagination 컴포넌트를 도입해 UX를 개선했고, 후기 개수가 3개 이하일 경우에는 Pagination이 렌더링되지 않도록 조건부 처리를 적용하여 불필요한 UI 노출을 방지하였습니다.

3. 결과

후기 데이터가 많아도 한 페이지에 3개씩만 렌더링되도록 구성하여 렌더링 성능과 사용자 가독성이 향상되었고, 페이지를 넘겨가며 후기를 자연스럽게 탐색할 수 있는 구조가 완성되었습니다. 또한 평균 평점과 총 후기 수를 상단에 노출함으로써 사용자 신뢰를 높이는 효과도 있었습니다.

문제 (3) - 이미지 렌더링 다양성 및 확대 기능

1. 문제

체험에 등록된 이미지가 1개 또는 여러 개인 경우 레이아웃이 깨지거나 사용자 경험이 일관되지 않을 수 있었습니다. 모바일에서는 슬라이더 방식, 데스크탑에서는 여러 이미지 배치가 필요했으며, 이미지 클릭 시 확대 기능도 요구됐습니다.

2. 해결방식

BannerImage 컴포넌트에서 이미지 개수에 따라 서로 다른 레이아웃으로 조건부 렌더링을 적용했고, 모바일에서는 react-slick 기반 슬라이더를 적용했습니다. 모든 이미지에는 클릭 시 확대되는 모달 기능을 추가하여 사용자 경험을 개선했습니다.

3. 결과

모바일과 데스크탑 모두에서 일관된 UI를 제공하면서 다양한 이미지 탐색이 가능해졌고, 사용자가 체험 정보를 더 깊이 이해할 수 있도록 시각적 정보 전달력을 높일 수 있었습니다.

→ 개선 방향 : 확대 모달의 접근성 향상(키보드 접근 가능 여부, 닫기 버튼 외 클릭 시 닫기 방지 처리 등)을 추가로 고려할 수 있음.

문제 (4) - 서브 이미지 배치 구조의 반복성과 비효율성

1. 문제

체험 상세 페이지에서 서브 이미지의 수(1~4장)에 따라 각기 다른 레이아웃을 적용해야 했습니다.

이미지가 1개일 땐 전체 영역에 단일 이미지, 2개일 땐 세로로 분할, 3개일 땐 상단 1 + 하단 2, 4개일 땐 2x2 형태의 정사각형 격자 레이아웃으로 구성되었습니다.

2. 해결방식

SubImageBanner 컴포넌트 내부에서 이미지 수를 기준으로 if-else 조건 분기를 사용하고, 각 케이스마다 div + Image 구성으로 다른 레이아웃을 수동 구현했습니다. 2장, 4장 케이스는 for 문으로 반복 렌더링을 구현했으며, 3장 케이스는 분할 방식이 더 복잡해 직접 배치 구조를 명시했습니다. 이 로직을 구현하는 과정에서 if 조건과 for 문을 각 케이스마다 반복적으로 사용하는 구조가 만들어졌고, 추후 이미지 배치가 변경될 경우 유지보수가 어렵다는 한계가 있었습니다.

3. 결과

기획된 모든 이미지 케이스를 정확히 구현했고, 사용자는 이미지 수에 따라 시각적으로 안정적인 콘텐츠 탐색이 가능했습니다. 특히 모바일/PC에서도 반응형으로 잘 작동했고, 클릭 시 확대 모달까지 제공하면서 전반적인 UX 완성도는 높았습니다.

하지만 코드 구조가 조건 분기와 반복 로직의 결합으로 복잡했고, 재사용이나 확장에 불리한 점이 있었습니다.

→ 개선 방향

단순히 구현을 넘어서 재사용성과 유지보수성, 코드 구조를 고려한 개선이 필요하다고 판단했습니다.

Grid 또는 Flex 기반으로 레이아웃 구성 단순화
- 이미지 수에 따라 Grid의 grid-template-areas 또는 grid-auto-flow 속성을 조정해 구현할 수 있을 것이라 생각합니다. 이를 통해 조건 분기 없이도 반복적 구조를 선언적으로 표현 가능합니다. 특히 2x2, 1+2 형태는 Grid에서 쉽게 처리가 가능합니다.
map 기반 반복 렌더링 적용
- 현재는 for 문과 하드코딩된 코드가 혼합되어 있는데, 이를 map으로 추상화하면 더 간결하고 확장 가능한 구조 가능합니다.

문제 (5) - 카카오 지도 구현과 리액트 버전 충돌

1. 문제

체험 상세 페이지에서 위치 정보를 시각적으로 제공하기 위해 카카오 지도 API를 적용하려 했으나, react-kakao-maps-sdk 라이브러리가 React 18 이상과 호환되지 않아 렌더링 오류와 타입 충돌이 발생했습니다.

2. 해결방식

라이브러리 사용 대신 스크립트를 동적으로 삽입해 카카오 지도 SDK를 로드하는 방식으로 전환했습니다. useEffect 내부에서 window.kakao.maps.load()를 사용해 지도 객체를 생성하고, 주소를 기반으로 좌표 변환 후 마커를 표시하는 방식으로 직접 구현했습니다.

3. 결과

React 버전 이슈를 해결하면서도 안정적인 지도 렌더링이 가능해졌고, 불필요한 라이브러리 의존성을 제거할 수 있었습니다. 사용자에게 체험 위치를 시각적으로 보여주며 정보 전달력을 높이는 데 기여했습니다.

배운 점/느낀 점

1. 예약 기능 흐름의 UX 설계와 상태 연결 경험

사용자가 날짜 → 시간 → 인원 수 → 예약까지 단계적으로 진행하는 흐름을 구현하면서, 각 상태 간의 연결성과 UI 반응 속도를 조율하는 것이 얼마나 중요한지를 실감했습니다. 사용자 경험을 고려해 조건부 렌더링 및 모달 컴포넌트 분리 등을 적용하며, UX 중심의 로직 구성 방식에 익숙해졌습니다.

2. React Query 실전 적용 경험

예약 가능 시간과 사용자 예약 내역을 병렬적으로 비동기 호출하고, 이를 기반으로 렌더링을 구성하는 과정에서 React Query의 캐싱 및 상태 관리 능력을 실감했습니다. 해당 흐름은 팀원의 도움을 받아 구현했으나, 이후 비동기 데이터 흐름의 설계 방법에 대해 큰 인사이트를 얻을 수 있었습니다.

3. 동적 지도 및 캘린더 구현을 통한 외부 도구 활용 능력 향상

체험 상세 페이지에서 사용자가 위치를 직관적으로 확인할 수 있도록 카카오 지도를 도입했는데, 기존 react-kakao-maps-sdk 사용 시 React 18과의 호환성 문제로 인해 직접 script 태그를 통해 SDK를 동적으로 로드하고 useEffect 내에서 안전하게 처리하는 방식으로 전환했습니다. 또한 예약 가능한 날짜를 표시하기 위해 react-calendar 라이브러리를 활용했고, 예약 가능 여부에 따라 날짜 선택 UI가 달라지도록 커스터마이징하여 실용적인 캘린더 UI를 구현했습니다. 외부 라이브러리의 장점과 한계를 모두 경험하면서, 상황에 따라 적절한 구현 방식을 선택하는 감각도 함께 익힐 수 있었습니다.

아쉬운 점

1. React Query에 대한 미숙함

상태 캐싱과 병렬 비동기 호출에 강력한 React Query의 장점을 체감했지만, 사용 경험이 부족해 직접 활용보다는 팀원의 구현을 참고하는 데에 그쳤습니다. 이후에는 스스로 상태 관리 흐름을 설계하고 React Query를 적극 활용해보고자 합니다.

2. 이미지 레이아웃 조건 처리의 아쉬움

서브 이미지가 1~4장일 경우 배치 방식이 달라지도록 조건 분기를 적용했지만, 이를 모두 for문과 분기 처리로 구성하면서 코드가 장황해졌습니다. 반복되는 조건 처리보다는 좀 더 선언적이고 유연한 방식으로 리팩터링할 여지가 있었고, 이후 유지보수 측면에서도 다소 복잡한 구조가 된 점이 아쉬웠습니다.

3. 예약 시간 필터링의 반영 실패

사용자가 이미 예약한 시간대를 사전에 제거하려고 했지만 실패했고 결국 예약 시도 시점에 alert로 안내하는 방식으로 구현했습니다. 초기 기획 단계에서 API 흐름과 데이터 구조를 더 명확히 파악했더라면 UI 단계에서 완성도 높은 결과를 구현할 수 있었을 것이라는 아쉬움이 남습니다.

4. 팀원 이탈로 인한 일정 지연

프로젝트 후반부, 한 팀원과의 연락이 갑자기 어려워져 해당 파트의 진행이 일시적으로 지연되었습니다. 구현 자체가 복잡한 부분은 아니었지만, 팀원의 복귀를 기다리는 동안 일정이 조금 늦춰졌지만, 다행히 잘 마무리 할 수 있었습니다. 사전에 흐름에 대한 공유가 어느 정도 이루어졌기 때문에 큰 문제 없이 마무리할 수 있었지만, 일정 리스크를 줄이기 위한 사전 공유와 백업 체계의 중요성을 체감할 수 있었습니다.

중급 프로젝트: Linkbrary

soo2051 — Fri, 21 Mar 2025 21:12:11 +0900

프로젝트 소개

프로젝트 인원 : 프론트엔드 4명
기간 : 24.12.13 - 25.01.02
프로젝트 : 원하는 링크를 저장, 검색, 공유 및 폴더로 관리할 수 있는 서비스
GitHub: https://github.com/codeit-fe11-part3-team4/linkbrary
협업 : GitHub, Notion, Discord
기술 스택 : React, Next.js(App Route), Typescript, Tailwind CSS

‍ 내 역할

파일 구조 및 tailwind 설정
헤더, 페이지네이션 공통 컴포넌트 구현
링크 카드 컴포넌트 구현 (링크 페이지, 즐겨찾기 페이지 공통)
즐겨찾기 페이지 구현
발표

프로젝트 과정

API 연동 – Swagger 기반 백엔드 API 사용

컴포넌트 구조와 역할 분담

프로젝트는 다음과 같은 페이지 단위로 구성되어 있었으며, 각각을 컴포넌트 중심으로 분할하여 개발했습니다.

메인 랜딩 페이지
로그인/회원가입 페이지
링크 페이지
즐겨찾기 페이지

컴포넌트는 재사용성과 유지보수성을 고려하여 기능 단위로 나누었으며, 각 기능별 디렉토리 구조를 통해 파일 관리를 체계화했습니다.

문제 및 해결 과정

문제 (1) - 링크 카드 컴포넌트 공통화 및 조건부 UI 렌더링

1. 문제

링크 페이지와 즐겨찾기 페이지 모두 링크 카드를 사용하는데, 각각의 페이지에서 별도 로직과 UI 구조로 중복 구현이 발생하고 있었습니다. 특히 케밥 버튼이나 즐겨찾기 버튼과 같은 기능은 페이지별로 노출 조건이 달랐지만 명확하게 분리되지 않았습니다.

2. 해결방식

Card 컴포넌트를 공통화하고, 내부에서 usePathname()을 통해 현재 페이지 경로(/links, /favorite)를 판별하여 boolean 값을 생성했습니다. 이를 기반으로 케밥 버튼, 즐겨찾기 버튼을 조건부로 렌더링했습니다. 또한 즐겨찾기 페이지에서는 해당 버튼들이 숨겨지고, 링크 페이지에서는 클릭 시 API를 호출해 즐겨찾기 상태를 토글하도록 구현했습니다.

3. 결과

동일한 UI 컴포넌트를 기반으로 페이지별 동작을 자연스럽게 분리할 수 있었고, props 없이도 페이지 구분이 가능해지며 컴포넌트 재사용성과 유지보수성이 향상되었습니다.

→ 개선 방향 : pathname 의존이 강해지면서 라우팅 변경 시 UI 로직 변경이 필요한 구조가 되었기 때문에, 추후에는 상태 기반 혹은 context 기반으로 구분하는 구조도 고려할 수 있음

문제 (2) - CardList 컴포넌트 도입 실패와 Card 내부 통합

1. 문제

초기 설계에서는 CardList 컴포넌트에서 전체 링크 데이터를 요청하고 상태를 관리한 뒤, 각각의 Card 컴포넌트로 props를 내려보내는 방식으로 구성하려 했습니다. 이 방식은 컴포넌트 간의 역할을 분리할 수 있는 구조였지만, 실제 구현 과정에서는 다음과 같은 문제가 발생했습니다:

props 깊이와 양이 많아져 컴포넌트 간의 연결이 점점 복잡해졌고, 중간에서 데이터를 가공하는 과정도 많아졌습니다.
페이지 전환, 즐겨찾기 상태, 검색 필터링, 폴더 아이디, 페이지 사이즈 등 다양한 상태의 흐름이 연동되면서, 상태 전달 구조가 꼬이기 시작했고, 그에 따라 특정 동작이 한 쪽 컴포넌트에서만 반영되거나 비동기 흐름이 어긋나는 경우도 있었습니다.

2. 해결방식

결국 CardList는 제거하고, 다음과 같은 이유로 Card 컴포넌트 내부에서 상태 요청과 관리, 렌더링을 통합적으로 처리하는 구조로 구현했습니다

useEffect로 pathname, folderId, searchQuery, currentPage, pageSize가 변경될 때마다 API를 호출해 데이터 요청을 직접 처리
putFavoriteLink API 요청 후 전체 링크 상태를 갱신하는 흐름도 컴포넌트 내부에서 통합 관리
searchQuery에 따라 filteredLinks 상태를 만들어 검색 필터링도 Card 내부에서 처리

3. 결과

props 전달이 복잡하게 얽혀있던 구조가 단순화되어 코드의 추적 가능성과 디버깅 편의성이 높아졌습니다.
내부 상태 기반 렌더링 흐름이 명확해졌고, 버튼 조건부 렌더링, 즐겨찾기 동작 등도 페이지 기준으로 잘 동작했습니다.
하지만 컴포넌트가 점점 커지면서 렌더링, 요청 처리, UI 제어 로직이 하나에 몰리게 되어 관심사의 분리가 부족한 구조가 되었습니다.

→ 개선 방향

현 구조는 빠른 구현에는 유리했지만, 장기적으로는 유지보수성과 확장성에 있어 구조적인 한계가 있었습니다.
현재는 Card 컴포넌트 내부에서 링크와 즐겨찾기 관련 API 요청, 상태 관리, 렌더링까지 모두 처리하고 있어 컴포넌트가 점점 무거워지고 있으며, 관심사의 분리 측면에서도 아쉬움이 있었습니다.

원래는 CardList에서 API 요청과 상태를 전역적으로 관리하고 Card에는 렌더링만 위임하려 했지만, props 전달 구조가 복잡해지고 비동기 흐름이 꼬이면서 실패했습니다. 그러나 이는 props 전달이 반드시 문제라는 것보다는, 역할과 흐름이 명확히 정의되지 않은 설계의 문제였습니다.

이에 따라 각 페이지에서 필요한 API 호출과 상태 관리를 담당하고, Card 컴포넌트는 UI 렌더링만 맡도록 관심사를 분리하는 방향이 적합할 수 있겠다는 생각을 하게 되었습니다. 페이지는 어떤 데이터를 가져올지 결정하고, Card는 그 데이터를 어떻게 보여줄지에만 집중하게 됨으로써 구조적 명확성과 테스트 용이성이 향상됩니다. 또한 페이지 단에서는 React Query, Suspense, 에러 핸들링 등 다양한 전략을 자유롭게 적용할 수 있고, 즐겨찾기 페이지와 링크 페이지처럼 데이터 소스가 명확히 다른 경우에는 페이지 단에서 API를 분기하는 것이 더 명료한 흐름을 만들어냅니다.

props가 많아지는 상황은 필연적일 수 있으나, 이는 반드시 안티패턴이 아니며 명확한 설계를 기반으로 하면 오히려 데이터 흐름을 더 쉽게 추적하고 통제할 수 있고, 불필요한 전역 상태 관리 도구의 도입을 방지할 수 있습니다. 반대로, 컴포넌트 간 데이터 공유가 실제로 필요한 경우에는 Context, Zustand와 같은 상태 관리 도구를 유연하게 도입하여 역할 분리를 유지하면서도 필요한 공유는 효율적으로 처리할 수 있습니다.

향후 리팩토링 시에는 컴포넌트의 책임 단위를 재정의하고, CardList → Card 구조를 재도입하되 상태 흐름을 페이지 또는 래퍼 컴포넌트에서 컨트롤하는 방향으로 개선해보려 합니다.

페이지: 어떤 데이터를 가져올지 결정 (API 호출, 필터링, 페이지네이션 등)
CardList: 반복 렌더링, key 및 layout 구성 등 목록 UI 책임
Card: 데이터 시각화와 유저 인터랙션 담당 (UI 중심)

문제 (3) - 반응형 페이지네이션을 위한 useViewport 훅 구현

1. 문제

초기에는 pageSize 값을 고정(하드코딩)하거나, 부모 컴포넌트에서 조건문으로 화면 크기를 판별해 props로 전달하는 방식으로 구현했습니다. 그러나 이 구조에서는 다음과 같은 문제가 발생했습니다:

window.innerWidth를 기반으로 한 조건 분기가 여러 곳에 흩어져 있어 로직 중복이 발생했고,
페이지 크기 변경 시 pageSize가 실시간으로 반영되지 않아,
화면 너비가 변경되어도 보여주는 카드 수가 동적으로 바뀌지 않았습니다.

또한 prop 전달 과정에서도 viewportWidth와 pageSize 간의 동기화가 꼬여 페이지네이션이 비정상적으로 작동하거나 초기화되지 않는 오류가 발생했습니다.

2. 해결방식

useViewport라는 커스텀 훅을 도입해 화면 크기와 페이지 크기를 통합적으로 관리했습니다. 내부에서 resize 이벤트를 감지하여 width, pageSize, 디바이스 구분 상태(isPC, isTablet, isMobile)를 함께 관리했으며, 컴포넌트에서는 이 훅만 호출하면, 현재 화면에 맞는 pageSize를 바로 사용할 수 있도록 구성했습니다.

3. 결과

기존에 발생하던 prop 전달 오류와 하드코딩 문제를 해결할 수 있었고, 브라우저 크기에 따라 페이지 카드 수가 자동으로 변경되면서 UX가 향상되었습니다.

→ 개선 방향 : 초기 상태가 window 객체에 의존하기 때문에, 서버 사이드 렌더링 환경(window는 에러 발생)에서 예외 처리를 위한 조건 분기를 보완할 필요가 있으며(useEffect 내부에서만 window 관련 작업하도록 구조화), 추후에는 상태 관리를 더 명확히 하기 위해 Context 기반 또는 상태 동기화를 위한 로직 최적화도 고려

배운 점/느낀 점

1. App Router 기반의 페이지 구조 설계 및 구현 경험

이번 프로젝트에서는 Next.js의 App Router 방식을 사용하여 파일 구조를 설계하고 직접 구현했습니다. 기존 Pages Router와는 다르게, App Router는 폴더 기반의 구조와 레이아웃, 클라이언트/서버 컴포넌트의 분리, 서버 액션 등 다양한 개념이 도입되어 있어 처음에는 낯설었지만, 프로젝트를 진행하면서 실제 적용 방식을 익히고 디렉토리 구조를 효율적으로 설계하는 법을 배울 수 있었습니다. 이 경험을 통해 Next.js의 최신 라우팅 방식을 더 깊이 이해하게 되었고, 구조적인 개발에 대한 감각도 높일 수 있었습니다.

2. Context를 활용한 전역 상태 관리 방식에 대한 실전 경험

로그인 상태 관리를 위해 Context API를 기반으로 한 AuthContext를 팀원이 구현하였고, 저는 해당 구조를 활용해 useAuth() 훅을 통해 사용자 정보를 사용하는 흐름을 이해하고 적용했습니다. 단순히 사용하는 것에서 그치지 않고 Context 내부의 흐름을 분석하면서 상태를 전역에서 어떻게 관리하는지를 파악할 수 있었고, 이를 통해 전역 상태 관리의 필요성과 장점을 체감할 수 있었습니다.

3. API 흐름과 백엔드 로직 파악의 중요성

카드 컴포넌트를 공통화하고 즐겨찾기 페이지에 적용하는 과정에서, 즐겨찾기 API 호출 흐름을 정확히 이해하지 못한 상태로 작업을 시작해 시간이 지체되는 문제가 있었습니다. 즐겨찾기된 링크를 불러오기 위해서는 먼저 즐겨찾기 폴더에 링크를 추가해야 한다는 전제 조건을 파악하지 못했기 때문에, 아무리 데이터를 호출해도 결과가 나타나지 않았습니다. 이후 팀원의 도움을 받아 API 사용 흐름을 다시 정리하고 나서야 문제를 해결할 수 있었습니다.
이 과정을 통해 단순히 화면 UI 구현뿐만 아니라, 기능 작동을 위해 필요한 백엔드 로직까지 정확히 이해한 뒤 작업에 들어가는 습관이 얼마나 중요한지를 깨달았습니다.

아쉬운 점

1. API 명세 확인 및 흐름 파악의 부족

즐겨찾기 페이지를 구현하면서, 즐겨찾기 링크를 불러오기 전에 별도의 API를 통해 해당 링크를 즐겨찾기 폴더에 등록해야 한다는 과정을 놓치고 작업을 시작했습니다. 이로 인해 아무 데이터도 받아오지 못하는 상태가 지속되었고, 문제 원인을 찾는 데 많은 시간이 소요되었습니다. 이후 팀원과의 소통을 통해 API 구조와 흐름을 재정비하면서 해결했지만, 개발 초기 단계에서 백엔드 로직까지 충분히 이해하고 흐름을 먼저 설계했더라면 더 수월하게 구현할 수 있었을 것이라는 아쉬움이 남았습니다.

2. Context 구조에 대한 사용 위주 접근

로그인 상태 관리를 위해 Context API를 사용하는 구조가 도입되었고, 저는 이를 활용하여 필요한 데이터에 접근할 수 있었지만, 직접 Context를 설계하고 구성하는 과정에는 참여하지 못했습니다. 해당 구조의 장점은 분명히 체감했지만, 단순히 제공된 구조를 사용하는 수준에 머무른 점이 아쉬웠습니다. 다음 프로젝트에서는 직접 Context나 전역 상태 관리 도구를 구현해보며, 상태 흐름을 설계하는 경험도 쌓고자 합니다.

3. 카드 컴포넌트와 리스트 컴포넌트 분리 실패

처음에는 링크 목록을 CardList와 Card 형태로 분리된 구조로 구현하고자 했지만, API 호출 흐름과 상태 관리가 엇갈리면서 예상보다 복잡한 구조가 되었고, 결국 Card 컴포넌트 하나에서 모든 로직을 처리하게 되었습니다. 이로 인해 컴포넌트가 무거워지고 관심사 분리 측면에서도 아쉬움이 남았습니다. 컴포넌트 간 데이터 흐름을 명확히 정의하지 않고 로직을 추가한 점이 원인이었으며, 이후에는 설계 단계에서 상태 관리 흐름과 컴포넌트 역할을 더 명확히 구분한 뒤 구현하는 방향으로 개선할 필요가 있다고 느꼈습니다.

기초 프로젝트: Fandom-k

soo2051 — Fri, 21 Mar 2025 20:07:28 +0900

프로젝트 소개

프로젝트 인원 : 프론트엔드 3명
기간 : 24.10.24 - 24.11.08
프로젝트 : 팬들이 좋아하는 아이돌에게 투표하고 후원할 수 있는 팬덤 플랫폼
GitHub: https://github.com/FandomKteam5/main
협업 : GitHub, Notion, Discord
기술 스택 : React, CSS

‍ 내 역할

이달의 차트
투표 모달 + 크레딧 부족 모달
발표 자료 제작

프로젝트 과정

API 연동 – Swagger 기반 백엔드 API 사용

컴포넌트 구조와 역할 분담

프로젝트는 다음과 같은 페이지 단위로 구성되어 있었으며, 각각을 컴포넌트 중심으로 분할하여 개발했습니다.

메인 랜딩 페이지
이달의 차트
후원하기
마이페이지

컴포넌트는 재사용성과 유지보수성을 고려하여 기능 단위로 나누었으며, 각 기능별 디렉토리 구조를 통해 파일 관리를 체계화했습니다.

문제 및 해결 과정

문제 (1) - 이달의 차트를 여자 아이돌 / 남자 아이돌로 분류하여 인기 순으로 정렬

1. 문제

차트는 남자/여자 아이돌로 분류되어야 했고, 인기 순으로 정렬된 리스트를 제공해야 했습니다. 또한 '더 보기' 버튼을 통해 리스트를 확장하는 UX를 구현해야 했습니다.

2. 해결방식

currentTab 상태를 활용해 ‘여자 아이돌’과 ‘남자 아이돌’ 탭을 구성하고, 선택된 탭에 따라 API에 gender 파라미터를 전달해 해당 그룹의 데이터를 필터링해 가져왔습니다.
응답받은 아이돌 리스트는 인기 순으로 정렬하여, 사용자에게 가장 관심도가 높은 아이돌이 상단에 노출되도록 구현했습니다.

3. 결과

성별에 따라 차트를 분리함으로써 UX 흐름이 명확해졌고, 사용자는 본인의 관심 그룹만 선택적으로 확인할 수 있어 탐색 속도가 향상되었습니다.

또한 '더 보기' 버튼을 통해 페이지네이션 없이 목록을 이어서 로드할 수 있도록 구성했지만, 항목 수가 10개 미만인 경우에도 버튼이 비활성화되지 않고 계속 표시되는 문제가 있었습니다.

→ 개선 방향 : 응답받은 데이터의 길이를 기준으로 더보기 버튼 노출 여부를 제어하거나, 서버 응답 내에 'hasMore' 플래그를 활용한 조건 분기 등을 통해 보다 안정적인 로딩 로직을 설계

문제 (2) - '차트 투표하기' 버튼 클릭 시 투표 모달창을 표시하여 사용자 참여 유도

1. 문제

투표 버튼 클릭 시 표시되는 모달(ChartModal)과, 크레딧이 부족할 경우 표시되는 모달(LackModal)이 연속적으로 열리는 구조에서 문제가 발생했습니다. 크레딧 부족 모달을 닫으면, 그보다 먼저 열렸던 투표 모달까지 함께 닫히는 현상이 있었고, 이는 모달의 상태 관리가 명확하게 분리되어 있지 않다는 점에서 사용자 경험에 혼란을 줄 수 있는 구조였습니다.

2. 해결방식

기존에는 크레딧 부족 시 closeModal()을 호출해 두 모달이 모두 닫혔지만, 이 부분을 수정해 모달 상태를 분리 관리하도록 했습니다.
isOpen(투표 모달), showLackModal(크레딧 모달) 두 상태를 독립적으로 설정하고, 조건부 렌더링 또한 해당 상태에 따라 개별적으로 제어함으로써 모달 간 제어 충돌을 방지했습니다.

3. 결과

투표 흐름에서 모달 제어가 안정적으로 이루어져 UX 혼란이 줄어들었고, 두 모달의 닫힘 이벤트가 명확히 분리되면서 사용자 경험이 개선되었습니다.

→ 개선 방향 : 현재도 두 모달이 같은 DOM 트리 내에서 중첩 렌더링되고 있기 때문에, 향후에는 전역 상태로 모달을 통합 제어하는 방식을 도입

문제 (3) - API 요청 로직 모듈화 및 오류 처리

1. 문제

모든 API 요청 로직을 기능별로 분리해 모듈화하고, 요청마다 fetch, try-catch, response.ok 기반으로 예외 처리를 적용하여 일관된 요청 구조를 구축했습니다. 또한 커스텀 훅 useLoad를 활용해 로딩 및 에러 상태를 함께 처리할 수 있도록 구성했습니다. 이처럼 기본적인 구조화는 이루어졌지만, 이러한 구조가 프로젝트 전반으로 확장되지는 못했습니다. 다른 일부 컴포넌트에서는 여전히 try-catch 방식으로 직접 API 호출을 처리하거나, 상태 관리를 별도로 하지 않아 전체 흐름에서 로딩/에러 처리 방식의 일관성 부족과 코드 중복이 발생하는 상황이 있었습니다. 또한 에러 발생 시 사용자에게 제공되는 피드백은 대부분 alert() 또는 콘솔 로그 수준에 그쳐, UX 향상 측면에서는 아쉬움이 남았습니다.

2. 해결방식

API 요청 코드는 전반적으로 RankApi.js에서 일관되게 모듈화하여 관리했고, useLoad 커스텀 훅을 활용해 로딩 및 에러 상태 처리, 요청 흐름 제어를 간결하게 구성했습니다. 컴포넌트 내부의 중복되는 상태 관리 코드를 줄이고, 조건부 렌더링과 데이터 흐름도 명확하게 분리했습니다.

3. 결과

API 요청 흐름은 정리되어 유지보수성과 가독성이 높아졌고, 일부 컴포넌트에서는 훅을 통한 재사용도 가능해졌습니다.

→ 개선 방향

try-catch
장점:
- 직관적인 흐름 제어: 에러 발생 시 자동으로 catch로 흐름이 이동
- 예상치 못한 오류 포착 가능: 네트워크 에러, JSON 파싱 오류 등
- async/await과 함께 사용 시 동기적처럼 코드를 작성할 수 있어 가독성 향상
단점:
- 흐름 제어의 유연성이 부족하고, 성공/실패 외 상태를 표현하기 어려움
- catch 내부가 복잡해지기 쉬움 (에러 분기 로직 추가 필요)
- 의도된 실패도 에러로 처리되므로, 오류의 의미가 불명확해질 수 있음

Result 객체 반환 방식
장점:
- 성공/실패 여부를 명시적으로 분기 가능
- 상태 코드 기반으로 다양한 상황에 맞는 UX 피드백 처리 용이
- 에러를 예외가 아닌 데이터로 다룸으로써 로직 예측 가능
- 컴포넌트에서 try-catch 없이 로직 분기 가능 (코드 간결)
단점:
- 모든 API 요청 함수가 동일한 형식을 반환해야 하므로 코드 통일성 필요
- 에러 추적 시 try-catch보다 디버깅이 어렵게 느껴질 수 있음
- 성공/실패 분기 코드가 반복적으로 작성되어 장황해질 수 있음

커스텀 훅
장점:
- 로딩/에러/성공 상태를 하나의 훅에서 통합 관리 가능
- 반복되는 상태 관리 로직을 재사용 가능
- 컴포넌트는 UI에만 집중하고, 데이터 로직은 훅에서 분리 가능 (관심사 분리)
단점:
- 훅 설계가 복잡할 수 있음 (의존성, 내부 흐름 등 설계 고민 필요)
- 작은 프로젝트에서는 도입 비용이 클 수 있음
- 비동기 로직이 훅 내부에 숨겨져 있어 흐름 추적이 어려워질 수 있음

React Query
장점:
- 캐싱, 상태 관리, 리페칭, 에러 처리까지 자동화
- isLoading, isError, data, error 등의 상태를 즉시 활용 가능
- refetch, onSuccess, onError, onSettled 등 비동기 흐름을 세밀하게 제어 가능
- 서버 상태 관리를 전역적으로 처리 가능
단점:
- 개념이 많아 러닝 커브가 있음 (QueryKey, QueryClient 등)
- 프로젝트 초기 단계에서는 과한 설정일 수 있음
- React Query 자체 동작과 충돌 시 디버깅 어려움이 있음

Fandom-K 프로젝트에서는 요청 흐름을 단순화하고 빠르게 구현하기 위해 fetch + try-catch + response.ok 기반의 구조를 사용했습니다. 이는 단기간의 소규모 팀 프로젝트라는 상황에서 빠른 개발과 직관적인 구현에는 적합했지만, 상태별 분기 처리의 유연성 부족과 재사용 가능한 구조 설계의 어려움이라는 한계를 느꼈습니다.

특히 단순한 프로젝트일수록 요청 성공 여부 외에도 400, 409와 같은 HTTP 상태에 따라 명확한 사용자 피드백(UI 분기)이 필요하므로, 단일 catch 블록에서 모든 에러를 처리하는 방식보다는 try-catch 구조 안에 Result 객체 패턴을 함께 활용해 상태별 분기 처리를 명확히 하는 개선이 필요하다고 판단했습니다.

앞으로는 axios, 인터셉터, 커스텀 훅, Result 객체 패턴 등으로 API 요청 로직을 구조화하고 전역적으로 일관된 에러 핸들링 체계를 구성하여, UX의 정교함과 유지보수성까지 확보할 수 있는 방향으로 발전시키고자 합니다.

문제 (4) - 투표 후 상태 반영을 위한 window.location.reload() 처리

1. 문제

투표를 완료하더라도 차트 데이터에 즉시 반영되지 않았기 때문에 사용자 입장에서 "정상적으로 투표가 되었는지" 확인이 어려웠습니다. 이는 피드백 부족으로 인한 UX 손실로 이어졌습니다.

2. 해결방식

투표 성공 시 window.location.reload()를 호출하여 페이지 전체 새로고침으로 데이터 갱신했습니다.

3. 결과

정상 반영 여부를 즉시 확인할 수 있도록 UX 흐름을 보완했지만, 페이지 전체 리로드는 비효율적이고 사용자 경험 측면에서도 제한적인 방식이었습니다.

→ 개선 방향 : 상태 기반으로 투표 성공 시 차트 데이터만 refetch하여 새로고침 없이 실시간 반영되도록 개선 필요

배운 점/느낀 점

1. 사용자 경험(UX)에 대한 고민의 중요성

단순히 기능을 구현하는 데서 끝나는 것이 아니라, 사용자가 어떤 흐름으로 화면을 사용할지, 투표를 할 때 어떤 정보를 보고 싶은지, 실패했을 때 어떤 안내가 필요한지 등 사용자 입장에서 고민하면서 개발하는 것이 얼마나 중요한지 느꼈습니다. 특히 '투표하기' 버튼 위치, 모달 구성, 크레딧 부족 알림 등은 직접 경험하고 테스트하면서 반복적으로 개선할 수밖에 없었습니다.

2. 상태 관리와 구조화의 필요성

이번 프로젝트에서는 try-catch를 사용하여 API 요청 중 발생할 수 있는 오류를 처리했습니다. 하지만 다음과 같은 문제들이 반복적으로 발생했습니다. API 호출 코드가 여러 곳에 흩어져 있어 중복 로직이 많고, 유지보수가 어려웠으며, 에러가 발생했을 때 상태에 따른 UI 분기 처리가 미흡했고 로딩 중 상태와 실패 상태를 구분하지 못해 흐름이 복잡해졌습니다. 또한 alert()이나 console.log()로만 에러를 확인하는 등 피드백 방식이 단순하고 한정적이었습니다.

예외 처리는 되었지만, 각 컴포넌트마다 개별적으로 API 호출과 에러 처리를 하다 보니 전체적인 코드 일관성이 부족했고, 특히 네트워크 지연이나 백엔드 오류가 발생했을 때 문제 해결이 어렵고 디버깅이 반복적으로 필요했습니다.

이러한 문제를 해결하기 위해 API 요청 로직을 기능 단위로 모듈화하여 /services/RankApi.js 파일에 따로 분리해 관리했습니다. 각 요청 함수는 fetch 기반으로 구성하고, response.ok를 통해 HTTP 상태를 체크한 뒤, try-catch로 예외를 처리하고 response.json()으로 파싱하는 구조로 통일했습니다. 이처럼 API 요청 코드를 한 곳에 모아두자 컴포넌트에서는 간단하게 함수만 호출하는 방식으로 구현할 수 있게 되었고, 코드의 재사용성과 유지보수성이 크게 향상되었습니다.

또한, 커스텀 훅을 사용한 경험은 제한적이었으며, 프로젝트 전체에서 공통적으로 사용한 커스텀 훅은 반응형 처리를 위한 useWindowSize 하나뿐이었습니다. 이 훅은 뷰포트 크기에 따라 페이지 상태(MOBILE, TABLET, DESKTOP)를 구분하는 용도로 사용되었으며, API 호출이나 상태 관리를 위한 구조화된 커스텀 훅은 도입하지 못했습니다.

이 경험을 통해 API 요청 흐름을 컴포넌트 바깥으로 분리하고 공통화하는 구조의 중요성을 크게 느꼈습니다. 다음 프로젝트에서는 API 요청을 axios 기반으로 전환하고 요청/응답 인터셉터를 활용하거나, 커스텀 훅을 통해 isLoading, error 상태를 한 곳에서 관리할 수 있는 구조를 설계해보고자 합니다. 이러한 구조화는 코드 개선을 넘어서 전체 애플리케이션의 안정성과 협업 효율성까지 높여줄 수 있는 중요한 개발 습관임을 체감했습니다.

3. 협업의 어려움과 책임감

기획 당시 역할을 나눠 진행했지만, 중도에 팀원이 빠지는 상황이 발생하면서 기대만큼 일이 진행되지 않는 상황에서도 유연하게 대처하는 능력의 중요성을 체감했습니다. 비록 직접 구현하지 않더라도, 팀원이 맡은 기능이 어떻게 동작하는지 구조를 이해하고 있어야 비상시에 빠르게 인계받고 대응할 수 있다는 걸 느꼈습니다.

아쉬운 점

1. 비즈니스 로직과 API 구조에 대한 사전 이해 부족

초기에는 Swagger 문서를 기반으로 기능을 구현했지만, 백엔드 API의 사용 방식이나 응답 구조를 명확히 이해하지 못한 채 개발을 시작해 초반에 시간이 많이 소요되었습니다. 앞으로는 개발 전 API 명세와 흐름에 대해 좀 더 깊게 이해하고 시작하는 습관이 필요하다고 느꼈습니다.

2. 투표 결과 실시간 반영 미흡

투표 후 차트에 반영되는 내용이 즉시 확인되지 않아, 페이지 전체를 새로고침하는 방식(window.location.reload)으로 처리했습니다. 이는 UX와 성능 모두에서 한계가 있는 방식이었고, 처음부터 상태 기반 리렌더링 구조로 설계했더라면 더 자연스럽고 효율적인 사용자 경험을 제공할 수 있었을 것입니다.

3. 테스트 및 QA가 부족했던 점

프로젝트 후반부에는 일정에 쫓겨 충분한 QA나 사용자 테스트를 거치지 못하고 배포된 부분이 있었습니다. 기능적으로는 구현되었지만, 다양한 브라우저나 모바일 화면에서의 테스트 부족으로 인해 UI가 깨지는 등의 문제가 있었고, 이후 수정이 필요가 있다고 느꼈습니다.
다음 프로젝트에서는 테스트 계획도 개발 초기부터 같이 세우고, 여유를 확보하는 방향으로 관리해야겠다고 느꼈습니다.

4. 커밋 및 코드 리뷰 습관 부족

첫 팀 프로젝트이다 보니, 커밋 메시지 관리나 PR(PR 요청)을 주기적으로 올리는 습관이 제대로 잡혀 있지 않았습니다. 각자 맡은 기능 구현에 집중하느라 코드 리뷰 문화도 잘 정착되지 못했고, 그 결과 코드 전반에 대한 팀원 간의 이해도가 부족해지는 상황도 발생했습니다.

특히 저는 작업에 몰입하느라 PR을 계획한 만큼 자주 올리지 못했고, 팀원들과 진행 상황을 충분히 공유하지 못한 점이 아쉬움으로 남았습니다. 앞으로는 작업을 일정한 단위로 나누어 PR을 더 자주 올리고, 주기적으로 진행 상황을 공유하는 습관을 들이려 합니다. 더 나은 협업을 위해 코드 리뷰 참여도 의식적으로 챙겨야 한다는 필요성을 강하게 느꼈습니다.

5. 성과 전달력 부족

다른 팀들의 발표를 보며, 단순히 기능을 잘 구현하는 것뿐만 아니라 과정과 문제 해결의 흐름을 명확하게 설명하고, 결과로 도출한 인사이트를 전달하는 능력도 중요하다는 걸 실감했습니다. 저희 팀은 기술적 구현에 치중하다 보니, 진행 과정이나 성과를 정리해 발표하는 데에는 다소 부족한 면이 있었습니다. 다음 프로젝트에서는 구현과정뿐만 아니라, 왜 이런 결정을 내렸는지, 어떤 문제를 어떻게 풀었는지를 정리하고 효과적으로 발표하는 훈련을 병행할 예정입니다.

6. 공통 컴포넌트 설계 부족

프로젝트를 진행하며 UI 요소나 기능이 중복되는 경우가 있었지만, 공통 컴포넌트로 추상화하지 않고 각자 개별적으로 구현하는 일이 많았습니다.

예를 들어 버튼, 카드, 리스트 항목 등은 구조와 스타일이 유사했지만 팀원마다 각자 새롭게 컴포넌트를 만들면서 중복 코드가 발생했고, 스타일도 일관되지 않았습니다. 이로 인해 수정이 필요한 경우 모든 컴포넌트를 개별적으로 고쳐야 하는 비효율과 UI 일관성 유지가 어렵다는 문제가 발생했습니다.

7. 팀 회의 참여 부족으로 인한 협업 어려움

프로젝트 진행 중 정기적인 팀 회의에 대부분의 팀원들이 잘 참여하지 않았고, 실제 회의에는 팀장과 저만 참석하는 경우가 많았습니다. 회의 참여도가 낮다 보니 기획이나 진행 상황을 함께 정리하고 공유하기가 어려웠고, 결정 또한 원활하게 이루어지지 않는 경우가 많았습니다.

특히, 중도에 한 명이 팀에서 하차했는데, 해당 팀원이 후반부에 하차 했음에도 어디까지 구현했는지 전혀 파악할 수 없는 상태였고, 다른 팀원도 프로젝트 후반까지 회의에 거의 참여하지 않아 코어데이(공동 작업일)에도 모습을 보이지 않았습니다. 이로 인해 최종적으로 작업물을 머지하는 과정에서 충돌을 방지하고 일관된 코드 흐름을 유지하는 데 어려움이 있었고, 협업으로서의 완성도를 높이는 데에도 제약이 있었습니다.

다음 협업 프로젝트에서는 초기부터 회의 참여율 관리와 역할 분담 명확화, 그리고 주기적인 작업 공유를 습관화하여 팀 전체가 하나의 방향으로 움직일 수 있도록 체계를 갖추는 데 더 신경 쓰고자 합니다.

[코드잇] 프론트엔드 11기 지원

soo2051 — Tue, 18 Mar 2025 13:19:49 +0900

지원동기

처음에는 여러 부트캠프를 비교하면서 어떤 과정이 나에게 가장 적합할지 고민했다. 그러던 중 코드잇 스프린트 프론트엔드 트랙을 알게 되었고, 몇 가지 이유로 지원을 결심하게 되었다.

실제 프로젝트 3개 진행 – 단순한 이론 수업이 아니라, 실전 프로젝트를 통해 배운 내용을 직접 적용할 수 있다는 점이 매력적이었다.
Next.js 학습 포함 – 최신 프레임워크인 Next.js를 배우고 싶었는데, 코드잇 과정에서는 이를 다루고 있어 큰 장점이었다.
주 6일 몰입 학습 – 짧은 시간 동안 집중적으로 배우면서 실력을 빠르게 키울 수 있는 환경이 나에게 잘 맞을 것 같았다.

지원과정

(1) 서류지원

코드잇 부트캠프의 서류 지원은 복잡하지 않았다. 공식 사이트에서 다음 두 가지 질문에 대한 답변을 작성하는 것이 전부였다.

① 지원동기 및 진로 선택 계기 (150자 이상)

"코드잇 스프린트 프론트엔드 트랙에 지원한 동기와, 프론트엔드 엔지니어에 관심을 가지게 된 계기를 작성해 주세요."

당시 작성했던 내용은 다음과 같다. (정확하진 않지만 이런 느낌으로 작성했다.)

웹 프론트엔드는 실행 결과가 직관적으로 보인다는 점에서 매력을 느꼈다. 작은 코드 변경만으로도 화면이 즉각적으로 바뀌는 경험이 흥미로웠고, 사용자 경험을 고려한 UI 개발에도 관심이 생겼다. 하지만 학교에서는 이론 위주의 수업이 많아 실습할 기회가 적었고, 직접 프로젝트를 해볼 경험이 부족했다. 특히, 4학년 때 진행해야 하는 캡스톤 프로젝트에 대한 걱정이 컸다. 부트캠프를 통해 실전 프로젝트를 경험하면서 실력을 쌓고, 졸업 전에 협업 경험을 만들어 두고 싶었다.

② 성실성 및 향후 계획 (150자 이상)

"지원자님의 경험을 바탕으로 6개월 간의 본 과정을 성공적으로 완주할 수 있다고 생각하는 이유와 수료 후 계획에 대해 구체적으로 작성해 주세요."

여기에서는 기존의 경험(특히 UI/UX 포트폴리오 과정 완주) + 성실함 + 향후 목표를 강조해서 작성했다.

지난여름 UI/UX 포트폴리오 과정을 완주한 경험이 있다. 당시 팀 프로젝트를 진행했는데, 팀원들이 중간에 그만두는 바람에 어려움이 있었지만, 끝까지 프로젝트를 마무리했다. 이 경험을 통해 혼자서도 주어진 목표를 끝까지 완수할 수 있는 끈기와 책임감이 있다는 걸 증명했다. 코드잇 부트캠프 또한 강도 높은 과정이지만, 기존의 경험을 바탕으로 끝까지 완주할 자신이 있다. 수료 후에는 협업 경험을 쌓고, 이를 포트폴리오로 정리하는 것이 목표다. 궁극적으로는 개발자로 취업하기 위해 실무 경험을 쌓고 싶다.

(2) 기초역량 테스트 (자바)

서류를 통과한 후, 기초역량 테스트를 보았다.

내용: 자바 기본 문법 + 알고리즘 문제
준비 방법: 코드잇에서 제공하는 사전 강의를 먼저 듣고, 기초 문법을 복습한 후 문제를 풀어보았다. 또한, 연습할 기회도 제공되어 실제 테스트 전에 미리 문제를 풀어볼 수 있었다.
난이도: 어려운 수준은 아니었지만, 기본적인 자료형, 조건문, 반복문, 배열 등을 확실히 알고 있어야 풀 수 있는 문제들이었다.

(3) 인터뷰

기초역량 테스트를 통과한 후에는 비대면 면접이 진행되었다.
면접을 보면서 느낀 점은, 개발 실력보다는 학습 의지와 성실성을 평가하려는 과정이라는 것이었다.

면접을 준비하면서, 내가 왜 개발을 배우고 싶은지, 그리고 부트캠프에서 이루고 싶은 목표를 명확하게 정리해두는 것이 중요했다.

(면접은 AI를 통해 시간 내에 답변을 한 뒤에 제출하는 방식이었다.)

전반적으로 복잡한 기술적인 내용보다는, 나의 학습 태도와 끝까지 해내겠다는 의지를 강조하는 것이 중요하다고 느꼈다

합격 후 느낀 점 및 목표

부트캠프 지원 과정은 길지 않았지만, 나 자신을 돌아보며 진짜 개발을 하고 싶은 이유를 다시 생각해보는 과정이었다.

돌이켜보면

서류 작성은 기술적인 내용보다 "성실함 + 학습 의지"를 강조하는 것이 중요했다.
기초역량 테스트는 자바 기본 문법을 충분히 복습하고 준비하면 크게 어렵지는 않았다.
면접에서는 정답을 말하는 것보다 나의 의지를 자연스럽게 표현하는 것이 더 중요했다.

다시 준비한다면

기초역량 테스트를 더 철저히 준비했을 것 같다.
면접에서 좀 더 구체적인 경험을 이야기했으면 좋았을 것 같다. 당황해서 아무말이나 한 것 같다...

⭐️ 목표 ⭐️

코드잇 부트캠프를 통해 단순한 기술 학습을 넘어, 실무에 가까운 경험을 쌓는 것이 목표아다. 특히, 팀원들과의 협업, 최신 프레임워크 실습, 포트폴리오 구축을 중점적으로 이루고 싶다.

협업 경험 강화: Git을 활용한 버전 관리, 코드 리뷰, 팀 프로젝트를 통해 실제 개발자들이 협업하는 방식을 익히고, 함께 성장하는 경험을 쌓고 싶다.
최신 기술 적용 및 실전 프로젝트 경험: 부트캠프 과정에서 Next.js와 같은 최신 프레임워크를 학습하고, 이를 활용한 프로젝트를 직접 진행하며 실무 감각을 익히는 것이 중요하다고 생각한다.
취업을 위한 포트폴리오 완성: 부트캠프 수료 후, 프로젝트 결과물을 정리하여 개발자로서 나만의 포트폴리오를 완성하는 것도 목표다.

[유데미X스나이퍼팩토리] UI/UX 포트폴리오 과정 6WEEK (실무 프로젝트 4WEEK)

soo2051 — Mon, 12 Aug 2024 20:36:06 +0900

실무 프로젝트 마지막 주에는 마지막 피드백(8.6(화))을 받은 후 추가 수정을 거친 후 마무리를 했다.

발표팀으로 선정되는 팀은 최종 성과 발표회 때 발표를 해야 하지만, 우리 팀은 발표팀으로 선정되지 못해 피드백 내용을 반영하는 것까지 한 후 마무리를 하기로 했다.

피드백

지난 피드백까지 좋지 않은 피드백을 들었기 때문에 많이 걱정하고 있었는데, 칭찬도 해주셔서 마무리를 잘 할 수 있었다.

1) 참여기업(웅진씽크빅, 유데미 큐레이션)
  - 프로젝트 기간이 끝난 후에도 아쉬운 부분을 꼭 만들어보고 개선해봤으면 좋겠다. 좋은 디자이너가 되기 위해 이번 프로젝트의 최종 결과물을 단순히 결과 보고서 제출용으로 사용하는 것이 아니라 멘토링 했던 내용을 꼭 가져갔으면 좋겠다.
  - 설득력이 가장 좋았던 내용이었으나 디자인적인 요소가 아쉬워 눈에 띄는 포인트가 없다. 멘토의 피드백 내용을 반영하여 본인들이 만족할 만큼 만들어봤으면 좋겠다.

2) 멘토
  - 우선 좋은 기획력에 대해 칭찬해주고 싶다. 화면 구조와 내용이 접근성이 좋으며 잘 정리되어 있다.
  - 그러나 디자인에 대한 능력을 키워보면 좋겠다. 강의를 보면서 연습하거나 핀터레스트의 포트폴리오들을 참고하면서 컬러 포인트를 찍어 똑같이 따라하는 디자인 연습이 필요하다.
  - 현재 포트폴리오의 디자인에 대해 조언하자면 배경은 블랙보다 다른 색상으로 하는 것이 좋으며, 불필요한 배경 색상은 넣지 않는 것이 좋다. 배경 색이 고민된다면 흰색이 오히려 깔끔하다. 과한 것보다는 깔끔하게 디자인 하는 것을 추천한다. 또한 중요한 내용이 돋보일 수 있도록 부수적인 요소들은 슬림하게 접근해라.

전공이 프로그래밍이기도 하고 웹 페이지의 경우(특히 온라인 강의 플랫폼)에는 많이 사용해 봤기 때문인지, 참여기업과 멘토 두 분 다 기획력과 내용에 대한 칭찬을 해주셨다. 여전히 디자인적 요소는 아쉽지만, 기획하는 부분에 대해서는 칭찬을 들어서 뿌듯했다. 디자인의 경우에는 이 프로그램을 수강하면서 시작하였기 때문에 많이 부족한 부분이 많았던 것 같다. 따라서 프로젝트 기간이 끝난 후에도 추가로 연습해볼 예정이다.

최종 장표

피드백을 기반으로 수정해보았다.

배경에 대한 수정을 요청 받았기 때문에 대부분의 배경을 흰색으로 바꿔주었고, 퍼소나의 아이콘은 굳이 사람일 필요는 없다는 것과 점선은 취소선이라는 피드백을 받아서 그것도 수정해주었다. 또한 문제점과 해결을 1:1 대응 방식으로 변경하였다.

와이어프레임에서는 중요한 정보가 중앙 쪽으로 더 오면 좋을 것 같다고 피드백을 들어 우측 내비게이션 메뉴를 슬림하게 접근하였다.

마치며,

사전 직무교육과 실무 프로젝트, UI/UX 포트폴리오 과정이 총 6주 동안 진행되었다.

사전 직무교육 기간인 2주 동안 매일 9시부터 18시까지 마곡으로 출퇴근하는 것을 쉽지 않았고, 프로젝트 연습 과정에서도 여러 어려움이 있었다. 특히 실무 프로젝트를 시작하기 전에 팀원 2명이 중도 하차하여, 단 두 명이서 프로젝트를 진행해야 했던 점이 쉽지 않았다. 전공자가 없는 비전공자 두 명이서 진행한 프로젝트였기 때문에 여러 면에서 도전이 있었다. 하지만 멘토와 운영진의 많은 도움이 있었고, 디자인과 기획 외에도 협력과 문제 해결 능력 등 다양한 기술을 배울 수 있었다. 또한 이 경험을 통해 프로젝트를 수행하는 것의 장점을 깊이 이해하게 되었다. 전 과정을 통해 디자이너로서, 그리고 취업을 준비하는 사람으로서 많은 것을 배웠다고 생각한다. 앞으로는 구매한 UI/UX 도서와 멘토링에서 받은 조언을 바탕으로 실제 포트폴리오를 참고하여 디자인 능력을 더욱 발전시킬 계획이다.

[유데미X스나이퍼팩토리] UI/UX 포트폴리오 과정 5WEEK (실무 프로젝트 3WEEK)

soo2051 — Mon, 5 Aug 2024 14:45:16 +0900

실무 프로젝트 3주차는 멘토의 피드백(7.30(화))을 기반으로 수정하고, UI와 장표를 완성시켰다.

피드백

2주차에 수정한 내용(표지, 목차, UX전략, 포지셔닝맵, 퍼소나, Painpoint와 Solution, 플로우차트)에 대하여 피드백을 받았다. 전반적으로 여전히 예쁘지 않고, 또한 동시에 너무 디자인에만 치중한 느낌이 든다고 피드백을 받았다.

피드백
1. 디자인이 예쁘지 않음
솔직히 어떤 부분이 예쁘지 않은지 정확히 모르겠다. 디자인의 경우 보는 사람의 선호도인 것 같은데, 그저 핀터레스트에서 포트폴리오 참고하라고만 해서 어떤 식으로 바꿔야할지 감이 잘 안잡힌다.
2. 글자 배치 수정하기
글자를 z자로 배치해서 읽기 편하도록, 너무 디자인에 치중된 느낌이라서 전체적인 패턴이 깨지는 느낌이 든다고 하셨다.
3. 와이어프레임 수정하기
굳이 홈화면 필요없고, 카테고리화와 검색 기능이 종료된 것만이 아니라 진행 중인 것에도 해당하는 것이 나을 것 같다고 하셨다. 또한 부트캠프 상세페이지에 내비게이션바를 만들었는데, 그것에 대한 구분이 확실해야 하고, 반복적인 요소에 대해 효율성을 고려하라고 피드백을 해주셨다.
4. 배경 검정색으로 하지 않기
포트폴리오를 출력하는 과정에서 잉크 소모가 심하므로 최대한 배경은 흰색이 좋다고 하셨다.

피드백을 참고하여 장표와 UI를 수정하였다.

퍼소나는 글자 수를 줄여 직관적으로 알아보게 하기 위해, 4명의 퍼소나를 정해 카드 형태로 여러개의 퍼소나를 needs만 적는 걸로 변경하였다. 4명의 퍼소나는 각각 비전공자 취준생, 컴공과 3학년, 이직희망자, 현업자로 다양한 인물을 설정하여, 다양한 의견을 내는 방향으로 만들었다.

포지셔닝 맵 또한 비교군을 줄이고, 맵도 2개가 아닌 하나로 줄였다. 프로젝트에 필요한 내용을 중점으로 소통과 접근성으로 기준을 정했다.

플로우차트를 차트 형식으로 만든 것이 오히려 파악하기 어렵다고 판단하여, 이벤트 페이지와 부트캠프 상세페이지에 대해 위와 같이 불필요한 부분은 빼고 간단하게 수정하였다.

문제 해결 또한 피드백 받은 대로 시선을 고려하여 재배치하였다.

스타일 가이드는 간단하게 메인 컬러, 컴포넌트, 폰트, 아이콘을 배치하여 만들었다. 메인컬러는 유데미 큐레이션의 색상을 이용하여 만들었고, 컴포넌트는 개선한 페이지 수가 적어서 사용할 기회가 많지 않았다.

이벤트 페이지의 경우 진행 중인 이벤트에 대해 이벤트가 많을 경우 몇 개 인지도 모르고 원하는 이벤트가 나올 때까지 넘겨봐야 하는 불편함이 존재할 수 있으므로, 카테고리화와 검색 기능이 필요할 것 같다는 피드백을 받았다. 따라서 기존의 UI에서 검색기능과 카테고리화를 진행 중인 이벤트 상단에 배치하여 진행 중과 진행 완료 이벤트 모두에게 적용되도록 하였고, 체크 번호를 통해 진행 중인 이벤트만 볼 수 있는 기능을 넣었다.

부트캠프 상세페이지의 경우 내비게이션바에 있는 라벨을 구분하기 위해 '01 모집요강'과 같이 넣어 구분 가능하게 하였고, 타임라인과 지원 절차를 추가하였다.

두 가지 페이지에 대해 UI을 설명하는 부분을 추가하여, 이벤트 페이지는 진행 중과 진행완료 구분 기능, 검색기능, 필터링 기능을 정리해 적어주었고, 부트캠프 상세페이지는 상단 내비게이션바, 우측 내비게이션바, 중요 정보 상단 배치, 타임라인, 신청 절차의 내용을 정리해 넣어주었다.

[유데미X스나이퍼팩토리] UI/UX 포트폴리오 과정 4WEEK (실무 프로젝트 2WEEK)

soo2051 — Mon, 29 Jul 2024 16:28:35 +0900

이번 주는 저번 주에 이어 1~2주차를 계속 수정하면서, 3~4주차에 할 와이어프레임 및 최종 UI의 제작을 시작하였다.

최종 산출물인 포트폴리오와 결과 보고서는 틈틈히 작성하고 있다.

피드백

1주차에 만든 포토폴리오( UX전략, 포지셔닝맵, 퍼소나, 고객여정맵, 플로우차트 )에 대해 피드백을 받았다. 사전직무교육을 참고하여 포트폴리오를 만들었지만, 내용이 너무 많고 예쁘지 않다는 피드백을 받았다. 그러면서 레퍼런스가 될만한 것을 하나 골라 참고하라고 하셨다.

피드백
1. 가독성 높이기
2. 해석 가능한 장표 만들기
3. 통일성 주기 (앞에 언급된 내용은 뒤에 꼭 나와야 함)
4. 디자인 - 다른 레퍼런스 참고
5. 가급적 한글 사용

피드백을 통해 개선할 점과 부족한 점에 대해 알 수 있었다. 특히 디자인적 요소는 고민하고 있는 부분이었기 때문에 많은 도움이 되었고, 잊고 있던 앞뒤 내용이 연결되어야 한다는 기본적인 부분도 깨닫게 되었다.

피드백을 참고하여 장표를 수정해보았다.

여러 레퍼런스를 참고하여 내용과 디자인적 요소를 수정하였다. 퍼소나와 고객여정맵은 넣지 않은 사람도 많았기에 일단 넣지 않고 표지, 목차, 전략, 포지셔닝맵, 문제&해결로 만들었다. 하지만 PainPoint와 Solution은 필요한 내용이라고 판단하여 따로 페이지를 추가하여 넣었다. 또한 가독성을 높이기 위해 글을 줄이고 영어보다는 한글을 사용하였다.

장표를 수정한 후에는 와이어프레임을 제작하였다.

크롬 개발자 모드 스크린샷을 사용하여, 웹페이지의 개선된 사항을 보여주기 위해 수정해야하거나 프로토타입이 적용될 부분만 와이어프레임으로 제작하였다.

UI를 수정하기 위해 먼저 어떤 부분을 개선할지 정리하였다.

이벤트 페이지에서는 진행 중/종료 + 카테고리화와 마감 날짜가 눈에 띄게 개선하고, 이벤트 상세페이지는 중요한 정보를 상단 부분에 두고 라벨을 상단에 고정하는 방향으로 개선하기로 하였다.

[유데미X스나이퍼팩토리] UI/UX 포트폴리오 과정 3WEEK (실무 프로젝트 1WEEK)

soo2051 — Mon, 22 Jul 2024 01:48:23 +0900

유데미 실무 프로젝트 시작하게 되었으나, 팀 구성원 중 2명이 개인사정으로 불참하게 되어 최종적으로 2명이서 프로젝트를 진행하게 되었다. 다른 팀은 최대 5명이서 하는 프로젝트를 2명이서 하게되어 걱정도 많이 되지만, 열심히 해보기로 하였다.

이번주는 1주차로 안내해준 코칭을 따라 진행할 예정이다. 하지만 우리 팀은 2명이기 때문에 최대한 빠르게 일정을 진행하기로 하였다.

프로젝트는
1. 유데미 큐레이션 이벤트 리스트 페이지 UI/UX 리뉴얼
2. 유데미 부트캠프 지원자 모집 상세페이지 개선

위 두 가지 주제를 가지고 진행해야 하며, 동시에 개선을 진행한다. 특히 이벤트 리스트 페이지는 고객 유입용으로 다양하게 사용될 수 있기 때문에 이번 프로젝트에서 가장 중요하다.

1주차
리서치 및 아이데이션
- Desk Research, User Research, User Journey, UX Strategy 등
- Target 분석 , 경쟁사 분석 , PoinPoint & insight

대면회의_07.18.목

첫 대면회의에서는 앞으로 진행할 방향에 대해서 의논했다.

이번주 내에 최대한 2주차 일정까지 마무리한 후 다음주부터 와이어프레임을 제작하기로 하였다. 또한 두번째 대면회의까지 유데미 + 경쟁사 분석을 위한 자료조사를 해가기로 하였다.

대면회의_07.19.금

두번째 대면회의에서는 조사한 자료를 바탕으로 UX Strategy를 정리하였다.

유데미, 그리고 유데미와 유사한 온라인 강의를 시청할 수 있는 유튜브, ebs, kmooc, 코드잇, 인프런, 스파르타코딩, 클래스101, 코드스테이츠, 구름 등 9가지 사이트에 대해 개요, 타깃, 장점, 약점을 조사하여 정리하였다.

UX 전략을 바탕으로 포지셔닝 맵을 제작하였다.

1. 접근성
2. 가격
3. 소통(질문 응답률)
4. 강의 질

4가지 기준으로 맵을 구성하였으며, 이 기준을 중심으로 유데미 큐레이션과 경쟁사를 비교하였다.

유데미 큐레이션은 강의 수준과 가격 면에서는 합리적으로 보이나, 글로벌 사이트의 특성상 질문에 대한 답을 얻기 어렵고 홍보가 부족하여 접근성이 떨어진다는 결과를 보여주었다.

유데미 큐레이션을 사용할 가상의 고객을 선정하여 퍼소나를 제작하였고, 퍼소나를 바탕으로 고객여정맵을 완성하였다.

퍼소나의 사용자는 IT분야로 이직을 준비 중인 사람으로 설정하고, 사용자가 플랫폼을 사용하면서 겪은 문제점을 Pain point, 그에 대한 개선점을 목표로 정하여 퍼소나를 완성하였다.

고객여정맵에는 퍼소나에서 적은 문제점과 목표를 상세하게 적어, 문제점과 개선된 프로세스를 확실하게 파악할 수 있도록 하였다.

개선된 사항에 대한 프로세스 단계를 정리하기 위해 플로우 차트를 만들었다. 불필요한 부분은 제외하고 개선할 부분을 위주로 개선된 플랫폼의 모습으로 플로우 차트를 구성하였다.

개선 전 모습을 As-is로, 개선 후 모습을 To-be로 하여, 현재의 진행 흐름을 이해하고 개선된 부분과 비교할 수 있었다.

1주차에는 플로우차트까지 진행했으며, 2주차에는 멘토에게 피드백을 받은 내용으로 1주차에 한 내용에 대해 완성도를 높일 것이다. 또한 와이어프레임을 만들어 개선할 UI를 구체화 하는 과정까지 진행할 수 있다면 좋을 것 같다.

유데미 큐레이션 이벤트 페이지는 강의, 부트캠프, 스터디 등에 대한 홍보와 유데미 자체 이벤트에 대한 홍보가 주된 내용이다. 하지만 현재 이벤트 페이지는 분류되지 않은 항목과 눈에 띄지 않는 중요한 정보 등으로 직관적인 파악이 어렵다.

유데미 큐레이션 이벤트 페이지의 항목들을 카테고라이징 하고, 진행 중인 항목과 진행 완료된 항목을 구분할 필요가 있다. 유데미가 글로벌 플랫폼인 만큼 그 장점을 이용하여 국내에서 높은 인지도를 이루도록 프로젝트를 진행해보고자 한다.

다른 팀과 비교하여 팀원이 적은 만큼 해야할 업무도 많고, 비전공자 두 명이서 하는 만큼 어렵고 막히는 부분이 많을 지도 모르지만 최대한 완성도 높은 결과물을 기간 내에 만들어내도록 최선을 다할 것이다.

[유데미X스나이퍼팩토리] UI/UX 포트폴리오 과정 2WEEK

soo2051 — Mon, 15 Jul 2024 13:19:38 +0900

2021.07.08 6일차 - 오토레이아웃

오토레이아웃의 기능은 자동으로 간격으로 주고 블록 단위로 조합할 수 있다는 것이다.

어디에 간격을 주고, 어디에 묶을지 고려해서 덩어리를 나눈다.

블록 단위 조합

마진

오토레이아웃의 중요한 개념은 허그와 컨테이너이다. 컨테이너는 상대적으로 밖에 있는 요소를

의미하고 상대적으로 안쪽에 있는 요소는 컨텐츠라고 한다. 허그는 컨텐츠를 안고 가는 개념이기 때문에 가장 안쪽에 있는 컨텐츠는 허그를 사용할 수 없다. 오토레이아웃 리사이징으로 허그를 통해 컨텐츠가 크기가 늘어남에 따라 함께 늘어난다.

2021.07.09 7일차 - 프로토타입

오른쪽에 있는 프로토타입을 선택하여 인터렉션을 추가하여 프레임, 요소 등에 Action을 준다. 주로 On click과 On drag를 사용했다.

On click : 클릭
On drag : 드래그, 스와이프
While hovering : 마우스가 올라가 있는 동안
While pressing : 마우스를 누르고 있는 동안
Mouse enter : 마우스가 올라갈 때
Mouse leave : 마우스가 나갈 때
Touch down : 누를 때
Touch up : 뗄 때

Flow starting piont : 재생 시 첫 지점
smart animate : 자연스러운 전환
Open overlay : 오버레이 열기
Move in/out : 나타나는 방향

2021.07.10 8일차 - 와이어프레임&프로토타입

개선해야 할 CGV 앱에 대한 와이어프레임을 제작하였다. 우리 팀이 개선해야 할 부분인 메인 홈, 영화예매, 팝콘 구매, 더보기 페이지와 그에 해당하는 상세페이지에 대한 와이어프레임을 제작했고, 이를 바탕으로 개선된 UI 디자인 제작을 진행했다.

2021.07.11 9일차 - 프로토타입&피피티

어제에 이어 개선될 UI 디자인을 제작했고 시연할 수 있도록 프로토타입을 제작하였고, 피그마에 발표에 사용할 프레젠테이션도 함께 제작하였다.

2021.07.12 10일차 - 발표&프로젝트 설명

같은 팀 팀원이 최종 발표자의 역할을 맡아 발표를 하였다. 어제 또 다른 한 팀원과 함께 발표 대본을 작성하였는데, 발표를 맡은 팀원 분이 어색하게 넘어가는 문장과 내용이 있어 당황했다는 말을 들었지만 잘 마무리하여 발표 중 표가 나지 않아서 다행이었다.

2주 간의 짧은 시간이었지만 잘 마무리하게 된 것 같아 안심이 되었고, 실무 프로젝트에 대한 사전 교육이 된 것 같아서 앞으로의 프로젝트에서 잘 할 수 있을 것이라고 생각한다.

웅진씽크빅 x 유데미 웹사이트 리뉴얼 프로젝트

나는 두 가지 프로젝트 중 웅진씽크빅에서 하는 유데미 웹사이트 리뉴얼 프로젝트 선택했다. 웹사이트 리뉴얼 프로젝트는 4주의 프로젝트 기간 동안 유데이 큐레이션 이벤트 리스트 페이지와 유데미 부트캠프 지원자 모집 상세페이지를 개선하는 과정 2가지 주제로 진행한다.
유데미를 사용해 본 것은 아니지만 타 사의 성인용 학습 플랫폼을 사용해 봤기 때문에, 기획 및 디자인 하는 사람 뿐만이 아니라 사용자라고 생각했기 때문에 그 결험을 잘 살릴 수 있을 것이라고 생각한다. 또한 기존에 있는 플랫폼을 개선하는 주제이기 때문에 현업의 경험을 느낄 수 있고 프로젝트 기획자의 역량을 키울 수 있을 것이다.

1. 이번주 수업에서 좋았던 점은?

오토레이아웃에 대한 어려움이 있었는데 블록 단위로 나눠서 묶어야 한다는 점과 허그의 개념을 통해 더 잘 다룰 수 있게 되어 좋았다.
개선안을 만들기 전 와이어프레임을 만들어서 개선안과 비교할 수 있어 좋았다.

2. 이번주에 새롭게 배운 점은?

프로토타입을 통해 피그마로 만든 UI를 시연할 수 있었다.

3. 배운 것에 관해서 내가 부족했던 부분은?

오토레이아웃, 그룹화, 컴포넌트 등 배웠던 것들을 사용하는 것보다 일일이 다 제작하여 중복되는 과정이 있었던 것 같다. 이를 잘 활용하여 효율적으로 제작할 수 있도록 해야겠다.

4. 앞으로 뭘 더 하면 좋을까?

이어서 실무 프로젝트를 진행해 나갈 예정인데, 지금까지 배웠던 내용과 배움 속에서 내가 잘 할 수 있는 부분을 이용하여 프로젝트를 잘 마무리할 것이다.
프로젝트를 하면서 제작할 포트폴리오를 잘 활용할 수 있도록 열심히 하고 잘 정리 해야겠다.

[유데미X스나이퍼팩토리] UI/UX 포트폴리오 과정 1WEEK

soo2051 — Sun, 7 Jul 2024 22:15:09 +0900

2024.07.01 1일차 - OT&팀 프로젝트 계획

1일차의 내용은 OT와 UX/UI이란 무엇이고 어떤 취업 경로가 있으며, 어떤 주제로 팀 프로젝트를 진행할 것인가였다.

UX/UI

UX/UI는 모바일, 브라우저 외에도 워치, 패드, 키오스크 등 모든 디바이스의 화면을 디자인 하는 것이다. UX/UI의 차이는 다음과 같다.

UX(User eXperience)
- 문제를 하결하기 위해 다양한 사회현상과 고객의 니즈를 분석하는 툴
- 서비스 편의성과 사용성이 중요

UI(User Interface)
- UX 분석 바탕으로 만든 기획안을 실제로 화면을 설계하여 가시적으로 구현해내는 작업을 의미

UX/UI의 차이로 가장 유명한 예시는 이 케찹인 것 같은데, 강사님도 이 사진을 예시로 보여주셨다.

둘의 차이는 기능성과 심미성의 차이이다. 이 두 지식의 균형이 잘 맞아야 좋은 디자인이라고 할 수 있는 것이다.

인하우스/에이전시

UX/UI의 일반적인 진로에는 인하우스와 에이전시 두 가지가 있다.

에이전시 입사 후 인하우스로 이직하는 경우가 많지만, 에이전시가 성향에 맞는 경우도 있으며 이 경우에는 프리랜서로 활동하거 재택근무 하는 경우도 많다고 한다.

⭐️ 비전공인데, 그래픽에 자신이 없어요. ⭐️
에이전시보다는 인하우스에 도전해, 디자인 포퍼먼스보다는 UX에 집중해 하나의 문제해결을 어떻게 풀어갔는지 맥락있는 포트폴리오 제작 필요
(나는 특히 여기에 집중)

2주동안의 목표

수업전체 목표 : 팀별 1개의 앱을 선정 분석하여, 1인당 1개의 문제해결 개선안 제안

UX : 사용자리서치방법론(5why, 장단점비교분석, 사용자인터뷰, UT), IA 등
UI : 컬러, 타이포그라피, 인터페이스, 디자인시스템 구현
피그마(툴) -> 피그마젬, 오토레이어 등등

1. 3개의 앱 장단점 비교
2. 하나의 앱의 하나의 기능 선택
3. 사용자 리서치새로운 개선안 제안

5조_도와조_2주간의 목표

여러가지 의견들이 나왔으나 모두의 동의 아래 "영화예매 어플"을 선택하였다.

> CGV, 롯데시네마, 메가박스

영화 어플은 조원 모두가 자주 사용하고 있는 어플들이고, 앱의 특성상 용도가 명확하기 때문에 영화 어플들의 사용자 경험과 디자인을 비교하여 개선하려고 한다.

2024.07.02 2일차 - Figma & 사용자 관찰 조사

Figma

오늘 처음으로 피그마를 사용해봤는데 하루 만에 기본적인 기능을 익힐 수 있었다. 오히려 포토샵이나 일러스트레이터보다 사용법이 직관적이고 단순하여 금방 익혀 제작할 수 있었다.

기본적인 사용법을 배우기 위해 실제 앱의 UI를 그대로 따라 만들었고, 강사님이 중간중간 기능 적용 방법을 알려주시는 방향으로 실습을 진행하였다.

폰트 다운받기

[구글폰트 | Google Fonts]

https://fonts.google.com/

Browse Fonts - Google Fonts

Making the web more beautiful, fast, and open through great typography

fonts.google.com

수업에 앞서 제일 먼저 한 것은 구글에서 제공해주는 폰트를 다운 받는 것이었다. 가장 기본적인 Noto Sans체와 Noto Serif체의 영어와 한글 폰트를 다운받았다.

이렇게 4가지를 다운

실습

1. 원하는 프레임 선택

먼저 왼쪽 위에 있는 frame 아이콘을 클릭하여 디스플레이 프레임을 화면에 띄워준다.
- Android small 혹은 Android large 사용

2. 오른쪽 Design을 사용하여 변경
- Frame에서 x, y를 이용하여 위치 조정
- Frame에서 r값 지정하여 모서리 라운드
- Fill에서 색 변경 + 그라데이션

- stroke에서 테두리 만들기

3. 참고할 레퍼런스 불러와서 예제 만들기

프레임 옆에 사진을 붙여넣어 참고하면서 따라한다.

피그마의 기능을 배우기 위해 최대한 일러스트레이터의 사용 없이 만들어 보았다 - ⭐️⭐️⭐️

단축키 및 추가 기능
k 누르고 줄인 후 v
command g = 그룹화
command sift g = 그룹화 풀기
모양에 맞게 겹치게 하기 : 대상체를 use a mask → 대상체 복제 → 요소 넣기
아이콘 색 채우기 : 아이콘 더블 클릭 → 기존 색상 - → fill 눌러 색 지정
union 개체 합체
라이브러리에서 컴포넌트 or 아이콘 사용

사용자 관찰 조사

프로젝트 주제와 관련하여 "영화예매 앱"에 대한 사용자 관찰 조사를 진행하였다. 상황에 따른 Task를 정리하고, CGV, 롯데시네마, 메가박스 앱을 사용하여 영화 예매를 진행한 후 간단한 보고서를 스프레드시트로 정리했다.

처음에는 일반적으로 영화를 예매하는 경우에 대해서 상황 설정한 후

영화가 보고싶어서 예매하려고 할 때

1. 현재 상영 중인 영화를 찾아본다.
2. 영화 정보, 평점등을 찾아본다.
3. 오늘 볼 영화를 고르고 원하는 영화관을 선택한다.
4. 시간과 좌석을 선택한다.
5. 할인 및 부가서비스를 확인한다.
6. 원하는 방식으로 결제를 완료한다.
7. 영화관에서 예매티켓을 확인한다.

순서로 정리지만, 강사님께서 우리에게 특수한 상황을 설정면 재미있는 인사이트가 나올 것 같다는 것과 영화를 볼 때 하는 행동들에 관하여 새로운 의견을 제시해주시는 등 우리가 생각하지 못한 부분에 대한 피드백을 해주셨다.

그래서 우리 조는 먼저 갑작스럽게 영화를 보려고 하는 상황으로 상황 설정을 변경하였다.

번개로 영화를 보려고 할 때 (+팝콘, 포토티켓)

1. 근처 영화관을 찾아본다.
2. 영화와 시간을 고른 후 인원과 좌석을 선택한다.
3. 할인 및 부가서비스를 확인한다.
4. 원하는 방식으로 결제를 완료한다.
5. 팝콘이나 음료를 사려고 한다.
6. 영화관에서 예매티켓을 확인한다.
7. 관람 후 포토티켓을 뽑는다.

상황 설정과 테스크를 변경하였지만 비교 분석과 개선 사항이 어떻게 나올지, 강사님의 피드백을 어떤 식으로 참고해야 할지 조금 더 생각해야 할 필요가 있어 보인다.

2024.07.03 3일차 - 스타일 라이브러리 & 사용자 관찰 조사

스타일 라이브러리

UI를 디자인할 때 같은 색상, 폰트, 글자 크기, 그림자 등을 설정하기 편하게 하는 도구이다.

더블 다이아몬드

사용자 관찰 조사 작성

과업 진행, 어려워한 부분, 타사 비교, 사용자 인터뷰 4가지로 관찰 조사 내용을 채워나갔다.

과업 진행

1. 근처 영화관을 찾아본다.
2. 영화와 시간을 고른 후 인원과 좌석을 선택한다.
3. 할인 및 부가서비스를 확인한다.
4. 원하는 방식으로 결제를 완료한다.
5. 팝콘이나 음료를 사려고 한다.
6. 영화관에서 예매티켓을 확인한다.
7. 관람 후 포토티켓을 뽑는다.

지난 시간에 작성한 과업 진행 과정을 순서로 관찰해 보고서를 작성하였다.

4명이라서 3가지 앱에 대해, 한 앱당 2명씩 나눠서 사용해서 각 2명의 의견을 모았다.

(CGV는 팀원 A,B가/롯데시네마는 팀원 C, D/메가박스는 팀원 A, C가 진행)

어려워한 부분

	CGV	롯데시네마	메가박스
근처 영화관을 찾아본다.	근처 영화관을 찾을 수 없음		영화관 검색이 안되어 원하는 영화관을 찾기 어려움 지역이 많은 경우 원하는 영화관을 찾으려면 스크롤을 많이 해야 함
영화와 시간을 고른 후 인원과 좌석을 선택한다.	관람평 수치화x 불필요하게 중복되는 과정 줌 고정x 좌석 위치 파악 어려움 따로 떨어진 자리를 선택못함	화면에 광고가 많고 정리되어있지 않아 사용하기 불편함 홈의 정보 찾기 어려움 수치화된 관람평 찾기 어려움	줌아웃이 안되서 전체적인 좌석의 의 위치를 파악하기 어려움
할인 및 부가서비스를 확인한다.	해당 할인을 알 수 없음 통신사 할인이 누락 미리 구매에서 단일 상품을 구매x	해당 할인을 알 수 없음 통신사 할인이 누락
원하는 방식으로 결제를 완료한다.	결제 버튼 너무 아래에 있어 불편
팝콘이나 음료를 사려고 한다.	지금 주문, 미리 구매 중 어떤 버튼을 눌러야 할지 헷갈림	결제 후 바로 픽업을 원하는 경우에는 두 단계를 거쳐야해서 번거로움
영화관에서 예매티켓을 확인한다.	예매한 티켓이 앱 상에서 눈에 잘 띄지x 예매 후 좌석을 쉽게 바꿀 수 없음	전화번호 혹은 예매번호로만 티켓을 출력	티켓을 환불받기를 찾기 어려움
관람 후 포토티켓을 뽑는다.		결제까지 가는 과정이(선택하는 것이 많다)복잡함	포토티켓을 미리 앱에서 결제못함

사용자 인터뷰

CGV

평론가들의 의견이 없다. 수치화된 평점이 없어 정보를 신뢰하기 어렵다.
지역별로 영화관이 구분되어있으나 영화관이 많은 경우 많이 스크롤해서 원하는 지점을 찾아야 한다. 영화관을 검색하는 기능이 있었으면 좋겠다.
좌석표를 보는 곳에 인원 선택 옵션도 있기 때문에 인원 선택과 좌석 선택을 굳이 안나누는 게 덜 번거롭겠다는 생각이 들었다.
불필요한 단계(인원선택)가 있어 과정이 복잡하다. 전체좌석 이미지를 줌아웃한 상태로 화면이 고정되지 않아 한눈에 보기 힘들고, 좌상단 미니맵은 너무 어둡고 작아 파악이 어려워 좌석 위치를 직관으로 알기 어렵게 되어있다.
좌석을 따로따로 한 자리씩 선택할 수 없다.
메인화면에서 예매티켓을 찾기가 어렵다.
통신사 할인 빼고는 할인 중 사용해본 적이 없어, 통신사 할인이 누락되어 있다는 점과 나에게 해당하는 할인을 찾기 어렵다는 점이 개선되었으면 좋겠다.
결제하기 버튼이 너무 바닥에 있어 잘 안 보인다.
촉박하게 자리를 예매했기 때문에 예매 이후에 더 좋은 좌석이 취소되어 해당 좌석으로 변경하고 싶을 때, 따로 결제 후 환불해야 한다. 좌석 변경 기능이 있다면 좋을 것 같다.

롯데시네마

홈에서 일관적이지 않은 디자인으로 정보를 찾기 어렵다.
옵션 라벨이 너무 많다.
관람평을 객관적으로 나타내는 지표가 관람평탭에서 안 보인다. 객관적으로 평점을 볼 수 없어 파악하기 어렵다.
가까운 영화관을 알 수 있고 몇km 거리에 위치하고 있는 지까지 알 수 있어 쉽게 영화관을 선택할 수 있었다.
한 좌석씩 선택할 수 있어 원하는 좌석 선택이 자유롭다는 점이 좋았다.
할인, 포인트가 한 화면안에 나타나 있어 찾기 쉬워 원하는 서비스를 찾는 것이 쉬웠다.
구매 후 제조 요청을 할 수 있다는 점이 좋았다.
'흔들면 티켓이' 버튼, 티켓 버튼이 상담에 노출되어 있어 티켓을 찾는데 쉬웠다.
영화 관람 전/후 포토티켓을 뽑을 시간이 없을 경우, 다른 영화관에서 뽑을 수도 있는데 그 가능성을 고려하지 않고 구매시 뽑을 영화관을 선택해야 한다는 점이 불편했다.

메가박스

홈화면에 원하는 정보를 찾기가 쉽게 깔끔한 레이아웃으로 정리되어 있어 정보를 보는데 불편함이 없었다.
타 극장과 비교하여 영화 정보도 깔끔하고 별점을 직관적으로 파악하기 쉬웠다.
줌 자체가 되지 않고 미니 맵도 유지되는 것이 아니라서 좌석의 위치와 스크린과의 거리감을 파악하는데 불편했다.
통신사 할인이 결제 단계 할인 목록에 있어 좋았다.
할인수단을 즐겨찾기 할 수 있어 결제 시간을 단축할 수 있다는 점에서 좋았다.
팝콘, 음료까지 미리 결제를 하고 싶지만 해당 옵션이 없다.(바로 구매만 가능)
티켓이 바로 확인이 불가능하고 두번의 단계를 걸쳐서 티켓 확인이 가능해서 바로 티켓이 떴으면 좋겠다는 생각이 들었다.
티켓을 홈화면에서 바로 볼 수 없고 한단계를 거쳐서 티켓을 볼 수 있어 급한 경우 찾기 어렵다. 환불하는 버튼을 찾기 어렵다.(티켓보는 곳에서 바로 환불이 안된다.)
포토티켓 출력 금액을 미리 알기 어렵고 결제 과정이 없어서 더 빠를 수 있지만 혼잡한 영화관에서는 더 번거로울 수 있다.

Figjam 사용하여 인사이트 도출

사용자 관찰 조사를 기반으로 하여 인사이트를 도출했다.

CGV, 롯데시네마, 메가박스에 대한 어려운 부분을 나열한 뒤 영화 탐색, 영화 예매, 부가서비스 세 가지로 나눠서 묶었다.

그 결과 평점 및 정보 파악, 영화관 및 좌석 파악, 옵션 라벨링 등에 대해 불편하다고 느낀다는 것을 알 수 있었다.

영화 정보, 영화 예매 과정의 직관적인 UI가 필요하고 영화관 찾기부터 팝콘구매까지를
손쉽게 해줄 수 있는 예매 서비스를 제공해야한다.

영화예매 앱에 대한 최종 인사이트를 한 문장으로 요약했으며, 이에 대한 프로젝트 정의를 5가지로 나타냈다.

2024.07.04 4일차 - 컴포넌트 & Persona 퍼소나

컴포넌트

컴포넌트란?

화면을 구성하는 모든 요소를 의미하며, 같은 속성의 요소를 사용하려고 할 때 만들어둔 요소를 컴포넌트로 저장하여 편리하게 사용할 수 있도록한다. 그룹화와 비슷하다고 느낄 수 있지만 단순히 요소들의 집합인 그룹화와 달리 컴포넌트는 각 구송 요소의 속성을 유지하며 원본을 수정할 경우 복제본도 함께 수정된다.

컴포넌트 제작

1. 만들어 놓은 요소를 컴포넌트로 만든다.

요소를 선택한 뒤 마름모 4개로 이루어진 아이콘을 선택하면 컴포넌트가 만들어진다.

2. 만들어진 컴포넌트의 복제본을 만들어준다.

opion + 마우스 드래그를 하거나 Assets에서 등록된 컴포넌트를 가져와 복제한다. 복제본의 텍스트는 변경할 수 있다.

채워진 마름모 4개 - 원본, 빈 마름모 - 복제본

퍼소나

영화예매 앱에 대하여 불편한 점을 이야기해야 하기 때문에 우리는 앱에 익숙하면서도 잘 사용하지 않는 사람을 설정하는 것이 좋을 것 같다고 판단했다. 그래서 평소 OTT를 즐겨보는 20대 후반의 인물이 앱을 통해 영화 티켓과 팝콘, 포토티켓을 구매하는 상황을 가정하여 퍼소나를 제작하였다.

2024.07.05 5일차 - 사용자 여정 지도 & 플로우 차트 & 오토 레이아웃

사용자 여정 지도

퍼소나를 바탕으로 제작하는 것으로, 발견에서 구매(및 그 이후)까지의 프로세스를 시각화한 것.

고객의 불만 사항이나 문제점을 식별하여 쇼핑 프로세스의 어떤 부분이 작동하지 않거나 고객을 혼란스럽게 하는지 파악하는 데 도움이 되므로 중요하다.

플로우 차트

개선된 사항에 대한 프로세스 단계를 정리하기 위해 피그마를 이용하여 플로우 차트를 만들었다. 불필요한 부분은 제외하고 개선할 부분을 위주로 개선된 앱의 모습으로 플로우 차트를 구성하였다.

레이아웃 그리드

오토 레이아웃

오토 레이아웃은 개체 간 간격 맞추기와 해시태그나 순위 등 동일한 디자인에 대하여 텍스트의 변화에 따라 동적으로 자연스럽게 조정하기가 가능하게 한다.

간격 맞추기

왼쪽 원본, 오른쪽 복제 후 텍스트 변경

오토 레이아웃의 기능이 없다면 레이어를 늘려줄 때마다 나머지 요소들도 함께 조정해줘야 한다. 하지만 오토 레이아웃의 기능으로 레이어 너비에 따라 자연스럽게 조정된다.

1. 이번주 수업에서 좋았던 점은?

비전공자의 입장에서 처음 배운 툴과 프로젝트 과정이었지만 강사님께서 정말 기초부터 알려주셨다.
도구만 배우는 수업이 아니라 프로젝트를 통한 과정이기 때문에 내가 어떤 식으로 문제 파악 및 진행을 해야 하는지 알 수 있었다.

2. 이번주에 새롭게 배운 점은?

사전에 UI/UX 차이에 대해 알아보고 왔지만 여전히 헷갈리는 부분이 있었다. 이 부분에 대해서 확실히 알 수 있었다.
피그마라는 툴에 대한 기본적인 사용법을 알 수 있었다.

3. 배운 것에 관해서 내가 부족했던 부분은?

UX 과정에서 내가 좀 더 깊게 사고 하면 좋겠다.
아직 피그마 사용이 서툴러 다른 사람들과 비교했을 때 너무 느린 것 같다.

4. 앞으로 뭘 더 하면 좋을까?

피그마 사용법에 익숙해진다.
UX 과정에 대해 깊게 이해하면 더욱 다양한 의견을 제시할 수 있을 것이다.

본 후기는 본 후기는 [유데미x스나이퍼팩토리] UI/UX 포트폴리오 과정(B-log) 리뷰로 작성 되었습니다.