삼위일체/Team3 UI Project

삼위일체

一體三位

< 삼위일체 />

열정 <情> • 실력 <力> • 팀워크 <和>

안녕하세요. 멋쟁이사자처럼 14기 UI Project 3팀 삼위일체 입니다. 저희 팀은 나이키 웹사이트를 클론코딩하며, 지금껏 배워왔던 내용들을 120%이상 발휘 하려 노력 하였습니다. 작업 전반에 걸쳐 팀원 간의 소통과 협업을 가장 중요한 가치로 삼았고, 각자 주도적으로 의견을 제시하고 조율해가며 함께 성장하는 소중한 시간을 보냈습니다. 짧은 시간이었지만 모든 팀원이 최선을 다해 만든 결과물인 만큼, 저희의 노력을 예쁘게 봐주시면 감사하겠습니다!

나이키 페이지 방문하기

< 팀원 소개 />

오人오色, 그러나 하나의 목표

장영주 Team Leader 담당 페이지 : ItemList, CS-Service, FindStore, Header GitHub 바로가기

신남일 Team Member 담당 페이지 : WishList GitHub 바로가기

이범원 Team Member 담당 페이지 : Main GitHub 바로가기

성정은 Team Member 담당 페이지 : ProductDetail, Footer GitHub 바로가기

조선현 담당 페이지 : SignIn, SignUp GitHub 바로가기

< 프로젝트 규칙 />

오人오色, 하나의 약속

커밋 컨벤션

'[타입] 페이지 or 컴포넌트 / 내용'으로 작성한다.
-로 각 항목을 구분 한다.

커밋 컨벤션 타입과 설명
type	description
[Feat]	새로운 기능 추가
[BugFix]	버그 수정
[Docs]	문서의 수정
[Modify]	코드 변경
[Refactor]	리팩토링
[Design]	CSS 등 사용자 UI 디자인 변경
[Comment]	필요한 주석 추가 및 변경
[Style]	코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
[Test]	테스트(테스트 코드 추가, 수정, 삭제, 비즈니스 로직에 변경이 없는 경우)
[Chore]	빌드 수정, 패키지 매니저 설정, 운영 코드 변경이 없는 경우(assets image, 패키지 매니저 등)
[Init]	프로젝트 초기 생성
[Rename]	파일 혹은 폴더명 수정하거나 옮기는 경우
[Remove]	파일을 삭제하는 작업만 수행하는 경우
[Merge]	Pull 과정 중 현재 commit과 자동 병합이 일어날 때
[Build]	새로운 라이브러리 혹은 패키지

코딩 컨벤션

코딩 컨벤션을 사용해야하는 이유?

누구나 쉽게 코드를 이해할 수 있어서 협업하기 편해지며 여러 사람이 작업해도 한 사람이 짠 것처럼 일관성 있게 코드를 작성할 수 있다. 규칙을 지키면 실수나 혼동을 줄이고, 디버깅이 쉬워진다. 시간이 지나도 코드를 고치거나 개선하기가 쉬워지며, Prettier나 formatting 같은 툴이 잘 작동해서 생산성이 올라간다. 한 프로젝트의 코딩 컨벤션은 업무 효율을 높이는 데 결정적인 역할을 하며, 마크업 코드는 같은 코딩 컨벤션에 따라 작성해야 한다.

css 기본정의

★ 기본규칙

모든 속성은 영문 소문자로만 작성한다.
```
.my-class {color:#ffffff;}
```
폰트의 선언, 배경 url, filter, content에 작은 따옴표(‘ ’)를 사용합니다. 그 외의 경우는 사용하지 않는다.
```
.my-class {background-image:url(‘image.jpg’)}
```
마지막 선언된 속성에도 세미콜론(;)을 사용해도 된다.
```
.my-class {color:red;font-size:16px;line-height:20px;}
```
공백 : 선택자간, 중괄호 간 한 칸의 공백을 사용한다.
```
.my-class {color:red;font-size:18px;}
```
중첩 태그 사용시 3단계 권장한다.
사용단위는 rem을 권장한다.

논리속성 사용한다.

header {
  inline-size:100%; (O) width:100%; (X)
  padding-inline-start: 1rem; (O) padding-left: 1rem; (X)
}

★ CSS 네이밍 규칙

이름은 kebab-case 규칙을 따르며, 영문 소문자, 숫자, 하이픈(-)로 작성하며, 영문 소문자로만 시작한다.
```
잘못된 예 : Btn, 2btn, _btn, btn_, sectionList, product-3list
올바른 예 : btn, btn2, btn, btn, section-list, procude-list3
```

★ id, class 규칙

id는 문서 전체의 고유 식별자이므로 한 문서에서 동일한 id를 여러 번 사용하지 않는다.
레이아웃을 제외한 id는 스타일을 지정하지 않는다.
class는 문서에서 여러 번 사용할 수 있다.

★ 주석문 규칙

css는 코드 위에 간단히 설명정도 적고, 슬래시-별표로 시작하고, 별표-슬래시로 끝내며, 줄 바꿈 가능 하다. (/* 내용 */) 단, 중첩 주석은 불가하다. (/* 주석 안에 /* 또 주석 */)

★ 들여쓰기&줄바꿈

CSS는 들여쓰기를 허용하지 않는다.

★ 이미지 네이밍 규칙

같은 분류의 이미지가 두 개 이상이면 파일 이름 마지막에 숫자를 추가하여 구분한다 (올바른 예 : bu-dot1.gif, bu-dot2.jpg, bu-dot3.png)
형태-의미-상태 순서로 조합한다. (올바른 예 : btn-search-on.jpg)
임의로 축약하지 않는다.
영문 소문자를 사용한다.
숫자로 시작하지 않는다.

html 기본정의

★ 기본규칙(표준문법 사용)

DTD를 제외한 모든 요소와 애트리뷰트는 소문자로 작성한다.

잘못된 예 : <SPAN Class="desc">간단한 설명</SPAN>
올바른 예 : <span class="desc">간단한 설명</span>

DTD 선언 앞에 주석, 공백, 줄바꿈, 문자 등의 내용이 없어야 한다.

잘못된 예 :
<!-- Made by 3 -->
<!DOCTYPE html>
올바른 예 :
<!DOCTYPE html>
<!-- Made by 3 -->

<p> 태그 안에는 <p>, <div>, <ul> 등 다른 블록 요소가 들어갈 수 없다. (display : inline 속성을 적용해도 소용없음)
<p> 태그는 문단을 구분하는 용도로만 사용하고 영역을 구분하는 용도로 사용할 수 없다.
<a> 태그 안에는 <a> 태그가 들어갈 수 없다.
<form> 태그 안에는 <form> 태그가 들어갈 수 없다.
<label> 태그 안에는 <label> 태그가 들어갈 수 없다.
<button> 태그 안에는 <input>, <select>, <textarea>, <label>, <button>, <form>, <fieldset> 태그가 들어갈 수 없다.

태그의 중첩에 유의한다.

잘못된 예 : <em><strong>내용</em></strong>
올바른 예 : <em><strong>내용</strong></em>

<input>, <select>, <textarea>에 <label> 을 작성할 수 없을 경우 title을 작성해야 한다. (웹 접근성 관련 지침)
종료 태그가 필요한 요소는 반드시 종료 태그를 선언한다.
태그 사용 등 관련 오류의 체크를 위해 반드시 페이지 완료 전에 체크해야 한다.

★ 들여쓰기

앞은 탭(1탭=2스페이스)으로 들여쓰고 그 이외 부분은 1 스페이스로 한다.

★ 반응형 규칙

반응형 작업은 ‘모바일(first) → 태블릿 → 웹’ 순서로 작업한다.

반응형 breakpoint

/* BreakPoint 중단점 정의 */
모바일 : ~ 640px, 테블릿 : 641px ~ 1024px, 데스크탑 : 1025px ~ 
/* BreakPoint 사용자 속성 정의*/
--breakpoint-sm: 40rem;
--breakpoint-lg: 64rem;
--breakpoint-xl: 80rem;

폴더 구조

폴더 구조 정의

public 정적 파일
```
- fonts 폴더
- favicon 폴더
```

src 동적 파일

- assets 폴더 -> 이미지 파일
- components 폴더 -> 컴포넌트
- pages 폴더 -> 페이지

폴더 구조 규칙

컴포넌트 파일은 src/components 폴더 하위에 각 페이지의 컴포넌트 폴더 생성한다.
페이지 파일은 src/pages 폴더 하위에 생성하며 페이지명으로 네이밍한다.

                UI-PROJECT-TEAM3

                ├─  public

                │    ├─  favicon

                │    └─  font

                |           ├─  woff2

                │          └─ 📋 pretendardvariable.css

                └─  src

                     ├─  assets

                     │    └─  images

                     ├─  common

                     │    ├─ 📋 a11y.css

                     │    ├─ 📋 base.css

                     │    ├─ 📋 index.css

                     │    ├─ 📋 reset.css

                     │    └─ 📋 theme.css

                     ├─  components

                     │    ├─  common

                     │    ├─  CustomerService

                     │    ├─  findstore

                     │    ├─  itemlist

                     │    ├─  login

                     │    ├─  product-detail

                     │    └─  ...

                     └─  page

                            ├─  js

                            ├─  style

                            ├─ ...

                            └─ 📋 main.html

< 페이지 소개 />

다섯 명이 머리 맞댄 결과

Common Components

˙ 버튼 컴포넌트: 버튼 컴포넌트 바로가기
˙ 아코디언 컴포넌트: 아코디언 컴포넌트 바로가기
˙ input 컴포넌트: input 컴포넌트 바로가기
˙ 상품 컴포넌트: 상품 컴포넌트 바로가기

Page Components

˙ 메인 컴포넌트: 메인 컴포넌트 바로가기
˙ 상품 리스트 컴포넌트: - 상품 리스트 헤더 컴포넌트 바로가기 - 상품 리스트 필터 컴포넌트 바로가기
˙ 상품 상세 컴포넌트: 상품 상세 컴포넌트 바로가기
˙ 위시리스트 컴포넌트: 위시리스트 컴포넌트 바로가기
˙ 로그인 / 회원가입 컴포넌트: 로그인 / 회원가입 컴포넌트 바로가기
˙ 고객센터 컴포넌트: 고객센터 컴포넌트 바로가기
˙ 매장찾기 컴포넌트: - 매장찾기 지도 컴포넌트 바로가기 - 매장찾기 입력서식 컴포넌트 바로가기

< 개선 사항 />

다음엔 더 잘할게요… 아마도!

입력서식 input 구조 단순화

수정 전

입력서식 컴포넌트에서 div 요소를 불필요하게 사용

수정 후

입력서식 컴포넌트에서 불필요하세 사용되던 div요소를 제거하고 구조를 단순화시킴.

반응형 웹 그리드 재배치

수정 전

레이아웃을 flex로 배치

수정 후

반응형에 유연한 grid로 재배치

적합한 시멘틱 태그로 구현

수정 전

이미지 요소를 단순한 박스 레이아웃으로 잡아 시각적으로만 구분되며 의미전달이 부족함

수정 후

이미지 요소에 적합한 시멘틱 태그 figure, figcaption을 이용하여 콘텐츠의 구조적 가독성과 접근성을 높여 의미있는 콘텐츠라는 걸 표현함

< 회고록 />

기억하고 싶은 여정

성정은

이번 프로젝트를 통해 다시 한 번 느낀 건, 결과물의 완성도는 결국 내가 얼마나 집중하고, 어느 정도까지 밀어붙이느냐에 달려 있다는 점이었습니다. 지식과 경험이 쌓일수록 문제를 바라보는 시야도 확연히 달라지고, ‘아는 만큼 보인다’는 말은 언제나 유효했습니다.

협업 과정은 어딜가나 나혼자 잘해서는 안된다라는 걸 느낍니다. 각자의 역량도 중요하지만, 그걸 하나의 방향으로 조율하고 납득시키는 과정, 즉, 슬비쌤께서 강조하셨던 ‘설득의 힘’이야말로 실무에서 가장 필요한 역량 중 하나라는 걸 다시 한번 느끼게 됩니다.

이번 프로젝트에서는 리더십의 무게 또한 분명히 체감할 수 있었습니다. 작업자에게는 말뿐만 아니라 실행력이, 리더에게는 책임과 균형 감각이 요구됩니다. 누구나 말은 할 수 있지만, 실제로 노력하고 행동으로 옮기는 사람이 진정한 작업자의 자세를 가진 사람이라고 생각합니다. 리더는 단순한 역할이 아니라, 팀의 방향성, 정확한 업무분담, 일정 관리등 에너지를 결정짓는 중심축이라는 사실을 다시 확인하게 되었습니다.

전체적으로 이번 경험은 단순한 결과물이 아니라, 협업의 본질과 리더십의 실제적인 무게를 체감한 프로젝트였습니다. 실무에서 필요한 사고 방식과 태도를 점검하고, 한 단계 더 성숙할 수 있었던 기회였습니다.

신남일

이번 프로젝트를 하면서 단기간에 많이 성장했다고 느꼈습니다. CSS 파트에서 복습을 많이 못 했기 때문에 아는 내용이 너무 적어서 "내가 맡은 페이지를 잘 만들 수 있을까?"라는 생각이 프로젝트 기간 내내 떠나지 않았습니다.

다행히 컴포넌트를 만드는 데까지는 별 문제 없었고 중간중간 pr을 올리면 다른 조원 분이 코드를 확인해서 "이런이런 부분은 변경해달라"고 피드백을 열심히 해 주신 덕에 몰랐거나 까먹었던 내용도 알게 돼서 너무 좋았습니다. 코드도 많이 망쳐보고, AI한테 물어봐서 속성에 대해 공부까지 하게되니 지금보면 그렇게 오래걸릴 작업이 아니었지만 생각보다 시간을 많이 쏟아서 페이지 완성이 늦어지는 바람에 회고록을 쓰는 지금까지도 조원들에게 미안한 마음이 듭니다.

앞에서 많이 성장했다고 이야기하긴 했으나 아직도 깃을 완벽하게 다루지도, 다른 컴포넌트를 잘 만들 지도 못하지만 이번 프로젝트가 저에겐 새로운 영감과 폭발적인 성장을 이뤄준 것 같아 만족스럽습니다.

끝까지 기다려준 조원분들에게 감사의 인사를 전하며 회고록을 마무리 짓습니다.

이범원

이번 프론트-UI 프로젝트는 HTML·CSS조차 서툰 상태에서 컴포넌트화, 반응형 레이아웃, 접근성까지 챙기며 시행착오를 거듭한 경험의 연속이었습니다.

일본 일정으로 뒷 부분의 중요한 수업을 놓친 뒤 프로젝트에 참여하려다 보니 더 힘들었고, 시간이 빠듯했습니다.

초반에는 “시간이 없더라도 AI 없이 해 보자”는 고집으로 Flexbox와 Grid 문서를 뒤적이며 시간을 허비하며 초안은 완성했지만, 마지막엔 시간을 맞추기 위해 팀원들과 GPT의 도움을 받아 부족한 부분을 채우며 완성했습니다.

커밋 메시지와 브랜치 네이밍이 팀 전체의 약속임을 실감하며 협업 커뮤니케이션의 중요성을 깨달았고, 팀원들이 합심해서 일을 나누니 늦을 것 같던 일정도 맞출 수 있게 되었습니다. 특히 부족한 저를 끝까지 챙겨 주신 팀원들의 배려와 실질적인 도움 덕분에 프로젝트를 무사히 마칠 수 있었기에 감사드립니다.

장영주

이번 UI프로젝트는 개인이 아닌 팀원들과 협업을 진행하는 프로젝트 였기에 기대도 됐었고 다른 팀원들에게 민폐만 끼치지 말자는 생각으로 시작하였으며 함께 성장해보고 싶은 의지도 컸습니다.

하지만 프로젝트 첫날 팀 회의 과정에서 PM을 맡게되어 프로젝트가 끝 날 때까지 큰 부담감을 느낀거 같습니다.

협업 프로젝트는 처음이라 Branch 관리, 업무 분담, 일정 조율등 전반적으로 PM의 역할을 충분히 수행 하지 못한 것 같아 아쉬움이 큰 것 같습니다. 특히 협업 툴을 능숙하게 다루지 못한 점, 팀원들의 업무 진행 상황, 문서 정리, 일정이 마무리 되어가는 시점에는 의사소통 문제 등 부족한 부분이 많았던 것 같습니다.

그럼에도 끝까지 프로젝트를 완수할 수 있도록 도와주신 팀원분들께 감사의 말씀을 전하고 싶습니다. 이번 경험을 통해 협업에 있어 소통과 역할 분담의 중요성을 느낄 수 있었고, 아쉬움이 컸던 만큼 다음 프로젝트에서는 더 나은 모습으로 임할 수 있을거라 생각합니다.

조선현

UI 프로젝트를 시작하면서, 사실 기대보다는 "내가 잘할 수 있을까?" 하는 걱정이 더 컸습니다. 저는 비전공자이고 이 부트캠프에서 처음으로 코딩을 배우기 시작했기 때문에, "적어도 팀의 발목을 잡지 말자. 실수하지 말자."라는 마음으로 시작했습니다.

팀원이 정해지고 첫 회의를 할 때, 무엇을 어떻게 해야 할지 몰라 굉장히 긴장됐고, 감도 잘 잡히지 않았습니다. 그런데 경험이 있는 팀원 분들께서 분위기를 잘 이끌어주셨고, 그 덕분에 저도 용기를 내어 **“로그인과 회원가입 페이지를 하고 싶습니다.”**라고 말할 수 있었습니다. 그때부터 나이키의 로그인 및 회원가입 페이지를 맡게 되었고, "누군가가 나를 믿고 페이지를 맡겨준다"는 감각은 더 이상 무섭지 않고, 오히려 두근거리고 설레는 일이라는 걸 알게 되었습니다.

작업을 진행하면서 가장 크게 느낀 점은, 기술적으로 잘 만드는 것만큼이나 협업이 정말 중요하다는 것이었습니다. UI나 기술적인 부분은 강사님이나 책, 혹은 AI(ChatGPT)에게도 배울 수 있지만, "협업"은 이런 팀 프로젝트 안에서만 제대로 겪어보고 배울 수 있는 소중한 실습이라는 걸 알게 되었습니다.

서로의 코드를 확인해주고, 브랜치 충돌이 날 때 알려주고 도와주는 과정 자체가 저에겐 아주 좋은 경험이었고, “혼자 하는 개발”이 아닌 “같이 만드는 결과물”이라는 걸 실감할 수 있었습니다