강신규
[항해 플러스 프론트엔드 코스 5기] 1주차 회고 본문

안녕하세요! 개발자 강신규입니다
모바일 앱에서 WebView를 통해 앱과 웹 간의 통신이 가능하다는 경험을 통해 웹에 대한 관심이 커졌고
다른 분들이 웹에 대해 어떻게 공부하고 성장했는지 궁금했습니다.
프론트엔드 개발자로서 성장하기 위해서는 사용자 경험 개선을 필요로 한다고 생각하지만, 아직 이 부분에서 부족함을 느끼고 있습니다.
마침 항해에서 이러한 부분을 메꿀 수 있다고 생각하여 지원하게 되었습니다.
과제 체크포인트
배포 링크
https://singyukang.github.io/front_5th_chapter1-1/
항해플러스 SNS
singyukang.github.io
기본과제
1) 라우팅 구현:
- History API를 사용하여 SPA 라우터 구현
- '/' (홈 페이지)
- '/login' (로그인 페이지)
- '/profile' (프로필 페이지)
- 각 라우트에 해당하는 컴포넌트 렌더링 함수 작성
- 네비게이션 이벤트 처리 (링크 클릭 시 페이지 전환)
- 주소가 변경되어도 새로고침이 발생하지 않아야 한다.
2) 사용자 관리 기능:
- LocalStorage를 사용한 간단한 사용자 데이터 관리
- 사용자 정보 저장 (이름, 간단한 소개)
- 로그인 상태 관리 (로그인/로그아웃 토글)
- 로그인 폼 구현
- 사용자 이름 입력 및 검증
- 로그인 버튼 클릭 시 LocalStorage에 사용자 정보 저장
- 로그아웃 기능 구현
- 로그아웃 버튼 클릭 시 LocalStorage에서 사용자 정보 제거
3) 프로필 페이지 구현:
- 현재 로그인한 사용자의 정보 표시
- 사용자 이름
- 간단한 소개
- 프로필 수정 기능
- 사용자 소개 텍스트 수정 가능
- 수정된 정보 LocalStorage에 저장
4) 컴포넌트 기반 구조 설계:
- 재사용 가능한 컴포넌트 작성
- Header 컴포넌트
- Footer 컴포넌트
- 페이지별 컴포넌트 작성
- HomePage 컴포넌트
- ProfilePage 컴포넌트
- NotFoundPage 컴포넌트
5) 상태 관리 초기 구현:
- 간단한 상태 관리 시스템 설계
- 전역 상태 객체 생성 (예: 현재 로그인한 사용자 정보)
- 상태 변경 함수 구현
- 상태 업데이트 시 관련 컴포넌트 리렌더링
6) 이벤트 처리 및 DOM 조작:
- 사용자 입력 처리 (로그인 폼, 프로필 수정 등)
- 동적 컨텐츠 렌더링 (사용자 정보 표시, 페이지 전환 등)
7) 라우팅 예외 처리:
- 잘못된 라우트 접근 시 404 페이지 표시
심화과제
1) 해시 라우터 구현
- location.hash를 이용하여 SPA 라우터 구현
- '/#/' (홈 페이지)
- '/#/login' (로그인 페이지)
- '/#/profile' (프로필 페이지)
2) 라우트 가드 구현
- 로그인 상태에 따른 접근 제어
- 비로그인 사용자의 특정 페이지 접근 시 로그인 페이지로 리다이렉션
3) 이벤트 위임
- 이벤트 위임 방식으로 이벤트를 관리하고 있다.
과제 셀프회고
기술적 성장
1. SPA(Single Page Application) 페이지 전환 방식 이해
과제 요구사항을 보며 가장 눈에 띄었던 것은 주소가 변경되어도 새로고침이 발생하지 않아야 한다는 점이었습니다.
처음에는 단순히 URL 이동할 때마다 HTML을 다시 받아오면 되는 것 아닌가? 라는 생각을 했습니다.
하지만 조사를 진행하면서 SPA에서 새로고침이 발생하면 여러 가지 문제가 생긴다는 것을 알게 되었습니다.
🚨 새로고침 시 발생하는 주요 문제
- 기존 상태 초기화
- Recoil, Redux와 같은 상태 관리 라이브러리를 사용할 때도 같은 문제가 발생합니다.
- SPA에서는 JavaScript가 메모리에 데이터를 보관하고 있지만, 새로고침하면 메모리가 초기화되면서 모든 상태가 사라집니다.
- 반면, 새로고침 없이 URL만 변경하면 개발자가 의도한 상태를 유지할 수 있습니다.
- 서버 요청 증가
- SPA는 한 번 로드된 페이지에서 동작하는 것이 핵심입니다.
- 하지만 새로고침하면 URL을 다시 요청하면서 서버에서 모든 리소스를 다시 받아와야 합니다.
- 결과적으로 서버 부하 증가 + 페이지 로딩 속도 저하가 발생할 수 있습니다.
- 사용자 경험(UX) 저하
- SPA는 부드러운 전환을 목표로 하지만, 새로고침하면 화면이 깜빡이며 로딩 시간이 길어집니다.
- 이로 인해 사용자가 불편함을 느낄 수 있습니다.
이러한 문제를 해결하기 위해 SPA에서는 History API를 활용하여 URL을 변경하면서도 새로고침 없이 컴포넌트만 교체하는 방식을 사용해야합니다.
2. 브라우저 라우터 vs 해시 라우터
🟢 브라우저 라우터 (Browser Router)
History API를 활용하여 URL을 변경하지만, 실제 페이지 이동 없이 JavaScript가 렌더링을 처리 하는 방식입니다.- 예를 들어
/profile로 이동하면 index.html이 유지되면서 컴포넌트만 변경 됩니다. - 하지만
/profile에서 새로고침하면 문제가 발생합니다.- 브라우저는
/profileURL을 서버에 요청함 - 서버에
/profile경로가 없으면 404 에러 발생
- 브라우저는
- 해결 방법: 서버에서
index.html을 반환하도록 설정해야 합니다.
window.history.pushState({}, "", "/profile"); // URL 변경
window.addEventListener("popstate", () => renderPage()); // 뒤로가기 처리
🔹 해시 라우터 (Hash Router)
- URL에
#(해시)를 포함해 페이지 이동을 관리하는 방식. #뒤의 값은 서버로 전송되지 않기 때문에 새로고침을 해도 404 오류가 발생하지 않음.- 클라이언트에서만 URL을 변경하고 페이지를 렌더링하므로 서버 설정이 필요 없음.
- 하지만 URL이 깔끔하지 않고 일부 검색 엔진에서 불리할 수 있음.
코드 품질
- 기본 및 심화 구현: 브라우저 라우팅과 해시 라우팅을 바닐라 자바스크립트만으로 구현 한 점이 인상적임.
- 가독성 향상: 기능별로 함수를 모아 코드의 가독성을 높인 점이 만족스러움.
- 라우팅 방식 분기 처리:
- 현재
navigate함수 안에서 해시 라우터와 브라우저 라우터를 분기 처리하는데,
이를 보다 효율적으로 처리하는 방법에 대해 고민이 필요함.
- 현재
실무 적용 가능성 : 테스트 코드
- 실제 프로젝트에서 E2E 및 단위 테스트를 적용하여 테스트를 진행해보고 싶습니다
- UI 테스트를 시각적으로 확인하면서 디버깅이 가능 -> 어느 지점에서 어떤 문제가 발생했는지
리뷰 받고 싶은 내용
1. utils/navigation.js의 라우터 분기 처리 개선 방법
현재 utils/navigation.js에서 해시 라우터와 브라우저 라우터의 분기 처리가 되어 있습니다. 이 구조를 개선하려고 하는데, 다음과 같은 접근 방식 중 어떤 것이 더 나을지 고민하고 있습니다.
main.js에서 클래스로 라우터를 선언하여 관리하는 방식이 더 적절한지- 기존
navigate함수 내부에서 라우터 분기를 처리하는 것이 나은지 - 또는 이보다 더 좋은 구조가 있는지 궁금합니다.
2. 상태 관리 라이브러리 사용 시 새로고침 후 데이터 유지 문제
Redux, Recoil과 같은 상태 관리 라이브러리를 사용할 때, 새로고침 시 데이터가 사라지는 문제가 발생합니다.
- 일반적으로 프론트엔드에서는 이를 어떻게 해결하나요?
recoil-persist를 활용하여localStorage또는sessionStorage에 데이터를 저장할 수 있지만, 개인정보 보호 문제로 인해 이를 보관할 수 없는 경우가 있습니다.- 하지만 새로고침 후에도 유지해야 하는 중요한 정보가 있을 때, 어떤 방식으로 상태를 관리하는 것이 가장 적절할까요?
3. 재사용성이 높은 컴포넌트의 설계 원칙
재사용성이 높은 컴포넌트를 만들라는 요구를 받았지만, 어떤 컴포넌트가 재사용성이 높은지 감이 잘 오지 않습니다.
- 일반적으로 어떤 방식으로 설계하는 것이 좋을까요?
- 재사용성을 높이기 위한 주요 원칙이 있다면 알고 싶습니다.
4. Next.js에서 클라이언트 컴포넌트와 서버 컴포넌트의 적절한 사용 사례
Next.js에서는 클라이언트 컴포넌트와 서버 컴포넌트가 분리되어 있습니다.
- 어떤 경우에 서버 컴포넌트를 사용하여 HTML을 받아오는 것이 유리한가요?
- 어떤 경우에 클라이언트 컴포넌트(SPA 방식)를 사용하는 것이 더 적절할까요?
- 각각의 장점과 활용 사례에 대한 의견이 궁금합니다.
utils/navigation.js의 라우터 분기 처리 개선 방법
대개 hashRouter와 HistoryRouter의 경우 둘다 동작하게 하기 보다는 내부 엔진을 선택적으로 하는 옵션방식으로 제공을 합니다. 그래서 main.js 에서 Router를 등록할때 옵션을 설정하면 향후 navigate방식을 mode에 따라 분기를 하는 방식이죠.
이때 지금 구현한것처럼 매번 mode에 따라서 분기를 하기 보다는 처음 Router를 생성할때 엔진에 따라 각자 엔진에서 navigate함수를 반환하여 사용하는 방식을 사용하여 동일한 인터페이스를 사용하지만 다른 엔진을 사용할 수 있습니다.
function createHistoryRouter() {
return {...}
}
function createHashRouter() {
return {...}
}
function createRouter(routes, mode) {
if (mode === "hash") return createHashRouter(routes)
return createHistoryRouter(routes)
}
상태 관리 라이브러리 사용 시 새로고침 후 데이터 유지 문제
원래 브라우저에는 태생이 데이터를 저장하지 못했고 서버에서 DB에다가 대부분 데이터를 보관을 합니다.
현대에 들어서 브라우저 로컬에도 데이터를 보관할 수 있고 localStorage나 sessionStorage등을 사용하곤 합니다.
더 큰 용량이나 검색을 하기 위해서는 IndexedDB 등도 사용할 수 있습니다. url의 hash나 getString등으로도 보관이 가능하구요
로컬에 보관하면 그 특성상 보안에 취약할 수 밖에 없습니다. 민감하지 않은 정보만 필터링해서 보관하고 나머지 정보들은 서버에서 가져올 수 있겠죠. 아니면 로컬에 암호화를 해서 보관을 하는 방법도 있습니다. 이때에 키가 코드상에 있다면 난독화를 통해 접근은 어렵게 해도 어떻게든 뚫릴수는 있으므로 암호화키를 서버에 보관하는 방식으로도 가능하겠네요.
재사용성이 높은 컴포넌트의 설계 원칙
재사용이 높다는 얘기는 같은 코드를 다른 범용적인 용도로도 사용이 가능하다는 의미이며 그러기 위해서는 OCP원칙, 즉 확장에 열려있고 변경에 닫혀있도록 만드는게 중요합니다. Router와 같이 기능은 동일하지만 사용자에게는 꼭 필요한 최소한의 설정만 제공할 수 있도록 해서 어떤 코드에서든 사용하기 쉽게 제공하지만 내부 코드를 보지 않아도 되고 몰라도 되도록 감춰둠으로써 안정적인 코드를 쓸 수 있도록 해줄 수 있습니다.
재사용이 높은 코드가 되기 위해서는 구현부와 사용부가 완전히 분리되어야 하며 사용하는 곳에서는 범용적으로 사용할 수 있도록 다양한 옵션을 열어주면서도 많은 규칙을 몰라도 사용할 수 있도록 만들어주는 것이 중요합니다.
코드를 어떻게 구현할지를 넘어서 이 코드를 다른 사람들이 어떻게 사용할지를 고민하면서 편리하고 좋은 인터페이스를 먼저 만들고 구현을 해보는 것을 추천합니다.
Next.js에서 클라이언트 컴포넌트와 서버 컴포넌트의 적절한 사용 사례
한번밖에 렌더링만 하면 되는 코드, API를 호출하지 않아도 되는 코드, 보안상 노출하고 싶지 않은 로직이 포함된 코드, 로그인 정보등 서버의 API를 여러개를 주고 받아야 하는 로직 등이 있다면 서버컴포넌트를 쓰는 것이 좋습니다.
SPA는 첫번째 렌더링때 주요 정보를 담고 있지 않기에 검색이나 API 방식으로 조회할때 주요 데이터를 노출하지 못한다는 단점이 있습니다. 그래도 상관없는 웹 어플리케이션이나 대시보드류의 서비스는 SPA로 만들게 되면 개발하기에 용이합니다. 개발 환경은 SPA가 훨씬 더 편리하고 신경써야 하는 것이 적으니까요.
도움이 되는 답변이길 바라며 무엇보다 직접 경험해보는것이 제일 중요합니다. 일단 새로운 것이 있으면 그냥 한번 도전해보고 해보니 좋구나 별로구나를 몸으로 깨달아보는 것을 추천합니다. 화이팅입니다!
'항해 플러스 프론트엔드 5기' 카테고리의 다른 글
| [항해 플러스 프론트엔드 코스 5기] 6주차 회고 (0) | 2025.05.30 |
|---|---|
| [항해 플러스 프론트엔드 코스 5기] 5주차 회고 (0) | 2025.05.30 |
| [항해 플러스 프론트엔드 코스 5기] 4주차 회고 (2) | 2025.05.30 |
| [항해 플러스 프론트엔드 코스 5기] 3주차 회고 (0) | 2025.05.30 |
| [항해 플러스 프론트엔드 코스 5기] 2주차 회고 (0) | 2025.05.30 |