[패스트캠퍼스] 김민태의 프론트엔드 데브캠프 2기 토이프로젝트1

7 분 소요

아흔 세 번째 포스팅

안녕하세요! 아흔 세 번째 포스팅으로 찾아뵙게 되어 반갑습니다!♥ 벌써 아흔💫

오늘의 포스팅 내용은 [패스트캠퍼스] 김민태의 프론트엔드 데브캠프 2기 토이프로젝트1에 관한 내용입니다.
자세한 내용을 알아보러 갑시다❗️

[Boongranii] Here We Go 🔥

1️⃣ 토이 프로젝트 시작

온보딩 프로젝트에 이은 첫 번째 토이 프로젝트가 시작했다.

프로젝트명은 인트라넷 서비스 개발이다. 나는 대학생으로 아직 인트라넷을 경험해보지 못했다. 군대에서 군인트라넷에 들어간 것이 전부일 뿐.

강사님께서 이 프로젝트의 목적과 개요, 진행 방법에 대해서 안내를 받았다. Vanilla JS와 Vanilla CSS를 사용하여 프로젝트를 진행하는 것이었다. 그리고 약 3주도 되지 않는 기간 내에 개발을 해서 최종발표까지 진행하는 것이다. 추후 리팩토링 기간이 있긴하지만 발표를 위해서 완성본을 내놔야 하는 상황이었다.

3주라는 짧은 기간에 과연 이걸 해낼 수 있을까. 정말 막막했다. 하면 해.

2️⃣ 프로젝트 요구 사항

필수 요구 사항은 GitHub Branch와 Issue를 사용하여 협업을 진행하는 것이었다. 아무래도 깃과 깃허브와 친해지기 위해서는 형상 관리 도구를 잘 사용하는 것이 중요한 것 같다.

모든 산출물은 README.md 파일 내, 프로젝트와 관련된 상세한 설명이 담긴 문서 작성 필수입니다.
관리자용 페이지
1. CSS 스타일이 적용된 직원 프로필 페이지 개발
  - 사진을 등록, 수정, 삭제가 가능하도록 개발
2. 스크롤이 가능한 형태로 직원 리스팅 페이지 개발
3. 페이지네이션(Pagination) 기능 개발
4. CSS 의 상대 수치를 활용하여 디바이스별 자연스러운 화면 구현
5. JavaScript DOM event 조작
  - querySelector, getElementsByClassName, createElement, appendChild, removeChild 등 사용
사용자용 페이지
1. 마이 페이지 구현
  - 연차/반차/시간 조정 등 부재 신청 창 구현
  - 부재 신청 내역 확인 창 구현
  - 부재 항목에 따른 필터링 기능 구현
  - 사진, 직무, 이름이 표기된 프로필 구현
    - 시간 관리 기능 개발
    - 현 시각을 표시하는 시계 (타이머) 구현
      - 토글 형태의 근무 시작 / 종료 스위치 구현
    - 모달을 활용한 근무 시작 / 종료 확인 창 구현
2. 기업 공지 모음 갤러리 구현

위와 같이 필수 기능 요구 사항도 명시 되어 있었다.

이 요구사항이 다 끝난다면 팀끼리의 선택적인 요구사항을 추가해도 됐다.

3️⃣ 제약 사항

⛔️ HTML, CSS, JavaScript만을 사용하고 UI프레임워크나 CSS 전처리기의 사용을 금지한다.

나는 바닐라 자바스크립트와 바닐라 CSS를 통해 프로젝트를 진행해본 적이 없다. 이걸 과연 내가 잘 해낼 수 있을까? (~~못하는 게 어딨어. 해내는거지.~~)

항상 TailwindCSS와 React라는 프레임워크를 통해 작업을 하다보니 어떻게 작업할지 감이 오질 않았다.

근데? 하면 해.

4️⃣ 조 편성

프로젝트 조가 편성되고나서 각 소회의실에서 피어 세션이 이루어졌다.

우리팀은 나를 포함한 총 5명으로 구성되었다. 자기소개 폼을 작성하고 발표하며 아이스브레이킹 시간을 가졌다. (~~정말 어색했다~~)

다행인건 우리팀에 전공자가 꽤나 많아서 좋았다. 다들 개발 경험이 있는 상태로 시작하니 조금 편리할 것이라고 생각했다.

그리고 팀명을 정했다. 다른 팀의 팀명을 보니 정말 트렌디한 것 같아서 우리팀도 트렌드에 쳐지지 않기 위해서 구글에 2024 트렌드 밈을 검색해서 여러 개를 탐색했다. 2024 트렌드도 잘 모르는 나는 나이가 든걸까.

여튼, 내가 찾은 도파밍이 팀명이 됐다. 이름도 귀엽고 입에 잘 붙어서 아주 마음에 들었다.

5️⃣ 문서 작성

📃 요구사항 명세서

피어세션이 종료되고 우리 팀은 노션을 만들어 작업을 시작했다.

프로젝트 시작하기에 앞서 요구사항 명세서를 잘 써두는 것이 중요하다고 생각했기 때문이다. 필수 요구사항이 있었지만 모호한 부분이 많았기 때문에 그 점까지 마모해서 작성하였다.

명세서를 작성하다보니 우리만의 컨셉이 도드라지기 시작했다. 공지사항 관리나 목록에서 현재 우리 부트캠프의 출결 관리 및 슬랙과 같은 시스템의 불편한 점을 생각하며 이를 우리가 만들 프로젝트에 대입해보기로 했다.

우리의 컨셉은 부트캠프 인트라넷인것이다. 그렇기에 네비게이션바의 이름, 커리큘럼, 출결 관리 등이 추가되어 빌드업을 시작했다. 막연한 요구사항보다는 이러한 스토리를 프로젝트에 투영시키면 더 좋은 결과물이 나올 것이라고 생각했다.

요구사항 정의서를 작성하는 데에는 꽤나 오랜 시간이 걸렸다. ~~쓸수록 계속 기능이 늘어나는 느낌..~~

이런식으로 각 요구사항에 대해서 명세를 작성했다.

마무리가 된 우리의 페이지는 정말 많았다.

관리자
- 메인 페이지
- 직원 관리 페이지
- 직원 상세 페이지
- 직원 업로드 페이지
- 휴가/공가 관리 페이지
- 공지 관리 페이지
- 공지 업로드 폼
사용자
- 메인 페이지
- 출근/퇴근 상세 페이지
- 내 정보 수정 페이지
- 공지 목록 페이지
- 공지 상세 페이지
- 휴가/공가 페이지
- 부재 신청 페이지
- 수강생 목록 페이지
- 교육 프로그램 커리큘럼 페이지
- 공지 목록 페이지

정말 많은 페이지로 결론이 났다. 이걸 과연 다 구현할 수 있을까. 하면 해.

📃 우리의 컨벤션

우리팀은 컨벤션을 정확하게 설정해서 작업하기로 했다.

🍞 데일리 스크럼

먼저 데일리 스크럼이다. 개발 기간에 개발만 하는 것이 아닌 데일리 스크럼을 통해 각자 진행사항을 보고하고 어떤 작업을 진행할 지 스크럼을 진행하는 시간을 정했다.

원래는 월수금만 하기로 했는데 항상 줌에 들어와 있다 보니 궁금한 점이 생길 때는 질문을 던져 답변을 받는다.

🍞 린트 설정

우리팀은 중요하게 생각했던 것 중 하나가 바로 코드의 일관성이다. PR을 올리고 코드 리뷰를 거쳐 머지하는 과정에서, 코드 스타일이 제각각이면 리뷰하기도 어렵고 유지보수도 힘들어질 것이라고 생각했다.

그래서 우리는 Prettier, ESLint, husky를 활용해 관리하기로 했다.

🍦 Prettier-코드 스타일 통일

{
  "singleQuote": true,
  "semi": true,
  "tabWidth": 2,
  "printWidth": 80,
  "singleQuote": true,
  "useTabs": false
  "arrowParens": "avoid", // 화살표 함수에서 매개변수 하나면 괄호 생략
  "bracketSpacing": true, // 객체 리터럴에서 중괄호 내부에 공백 e.g.const obj = { foo: 'bar' };
  "trailingComma": "all", // 여러 줄로 구성된 객체나 배열의 마지막 요소에도 항상 콤마를 붙임
}

🍦 ESLint-코드 품질 관리

{
  "root": true,
  "env": {
    "browser": true,
    "es2021": true,
    "node": true
  },
  "extends": ["eslint:recommended", "plugin:prettier/recommended"],
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "plugins": ["eslint-plugin-prettier"],
  "rules": {
    "prettier/prettier": "error",
    "eqeqeq": "error", // if (x === null) (o) / if (x == null) (x)
    "dot-notation": "warn", // const name = object.name; (o) / const name = object['name']; (x)
    "no-unused-vars": "error"
  }
}

eqeqeq는 타입 강제 변환으로 인한 예기치 않은 버그를 방지하기 위해 채택했다.
dot-notation은 더 읽기 쉽고 간결한 코드를 위해 채택했다.
no-unused-vars는 불필요한 메모리 사용을 방지하고 코드의 가독성을 높이기 위해 채택했다.

🍦 Husky-Git Hooks 자동화

husky를 도입했다. lint-staged를 통해서 변경된 파일만 린트를 검사하여 커밋 전에 자동 검사를 해주고 미리 설정한 커밋 메시지 컨벤션을 준수하고 있는지도 자동으로 체크를 해준다.

이를 사용함으로써 모든 팀원이 동일한 규칙을 따르도록 강제하고 실수로 인해 품질 저하되는 문제를 방지하고자 도입했다.

🍞 Commit Convention

feat: 새로운 기능 추가
style: css 수정 및 코드의 의미에 영향을 미치지 않는 변경사항
fix: 버그 수정
refactor: 리팩토링, 기능 변화 없이 코드 구조 개선
chore: 코드 수정 외 잡다한 작업 (빌드 과정이나 설정 변경 등)
docs: 문서 변경
test: 테스트 코드 추가 또는 수정
revert: 이전 커밋을 되돌림

규칙이 귀찮게 느껴질 수 있지만, 프로젝트를 진행하면서 이러한 규칙들의 가치를 경험할 수 있을 것이라고 생각한다.

🍞 코드 컨벤션

[토스트 UI]라는 사이트의 코드 컨벤션이 잘 설명 되어 있어서 여기에 있는 코드 컨벤션을 숙지해서 사용하기로 했다.

코드 컨벤션 과정에서 초기에는 클래스형 컴포넌트를 사용하기로 결정했다. 새로운 것을 배워보자는 마인드로 시작했지만 프로젝트를 진행하면서 이 결정을 재고하게 됐다.

프로젝트 초반에 린트 설정, 커밋 컨벤션 등 개발 환경 구축하는 데 예상보다 많은 시간이 소요됐고, 팀원 모두가 클래스형 컴포넌트를 사용해본 경험이 없다는 것을 고려하면 ‘배우며 진행하기’에는 남은 시간이 부족하다고 판단됐다.

그래서 비교적 능숙하게 사용했던 함수형 컴포넌트로 바꾸기로 결정했다. 단순히 편한 길을 택한 것이 아닌 잔여 일정을 고려한 현명하고 현실적인 판단이라고 생각한다.

🍞 브랜치 전략

main ─── develop ─── feat/login
                 └── feat/admin-login

우리팀은 효율적이고 안정적인 코드 관리를 위해서 위와 같은 브랜치 전략을 채택했다.

main 브랜치
- develop 브랜치에서만 머지 가능
- 모든 기능이 다 개발된 후 최종 머지
develop 브랜치
- 개발 중심 브랜치
- 모든 기능 구현을 여기에서 진행
- 각 기능 개발이 완료된 브랜치는 이 곳에 머지
- 개발이 모두 종료되면 main 브랜치로 머지
기능 브랜치
- 기능, 리팩토링, 버그 등 기능에 따라 컨벤션/ 사용
- 각각의 기능 개발을 위한 브랜치
- 기능 개발 후 develop으로 머지
- 브랜치명은 기능을 명확하게 명시

이 외에도 폴더 구조, CSS 스타일 컨벤션 등을 설정하였다.

6️⃣ firebase에서 정적 데이터로

처음에는 별도의 Node.js 서버를 구축하는 대신 Backend as a Service(BaaS)인 Firebase를 활용하기로 결정했다. 서버 구축 및 관리에 대한 부담을 줄이고, 실시간 데이터베이스 기능을 활용하여 CRUD 작업을 보다 간편하게 구현할 수 있다는 장점이 있었기 때문이다.

하지만 프로젝트를 진행하면서, API 명세서 작성 단계에 이르렀을 때 중요한 결정을 내려야 했다. 최종 발표 일정이 가까워지는 상황에서, UI/UX 구현의 완성도를 우선적으로 확보해야 한다는 의견이 제기되었다.

팀 내 논의 결과, Firebase 사용은 추후 리팩토링 단계에서 진행하기로 결정했다.

현재는 미리 준비된 JSON 파일을 데이터 저장소로 활용하여 읽기(Read) 작업 위주로 기능을 구현하고 있다.
UI 퍼블리싱 작업이 완료된 이후에는 리팩토링을 통해 Firebase 연동을 구현하고, 전체 CRUD 기능을 추가할 예정이다.

이러한 단계적 접근을 통해 제한된 시간 내에 프로젝트의 핵심 기능을 안정적으로 구현하고, 추후 확장 가능한 구조를 마련할 수 있을 것으로 기대해본다.

7️⃣ 마무리

현재 프로젝트 개발이 한창 진행 중이다. 초기에는 헤더와 사이드바 레이아웃을 설정하는 데 예상보다 많은 시간과 노력이 필요했다.

하지만 이러한 시행착오 끝에 기본 레이아웃을 성공적으로 구현했고, 현재는 그 안에 필요한 컴포넌트만 삽입하면 자동으로 렌더링되는 효율적인 구조를 갖추게 되었다.

평소 React를 사용하다가 바닐라 자바스크립트만으로 개발을 진행하니, 프레임워크가 제공하는 다양한 기능들의 진정한 가치를 체감했다.

컴포넌트 관리, 상태 관리, 라우팅 등 React에서 당연하게 사용하던 기능들을 직접 구현하면서 프레임워크의 필요성을 깊이 이해하게 되었다. 다만, 이러한 바닐라 자바스크립트 개발 경험이 오히려 프레임워크의 동작 원리와 내부 구조를 이해하는 데 큰 도움이 될 것이라 생각한다❗️

현재 팀원 모두가 순수 자바스크립트만으로 개발을 해본 경험이 많지 않아 퍼블리싱 작업에 어려움을 겪고 있다. 그럼에도 불구하고 최종 발표까지 Firebase 연동을 완료하여 완벽한 CRUD 기능을 구현하는 것을 목표로 열심히 개발을 진행하고 있다.

우리팀 도파밍 화이팅❗️😊

Twitter Facebook LinkedIn

Boongranii