프로젝트에서 보기 →

프론트엔드에서 가장 중요한데 가장 안하는거

태그
기타 개발자 취업 코딩
시작일
종료일
수정일

https://www.youtube.com/watch?v=_8deUuO0iJ8

# 1. 이건 꼭 알아야 한다[^1]

[? 질문] 프론트엔드 개발에서 “가장 중요한데 가장 안 하는 것”은 무엇인가[^1]
[= 답] **정상 환경(최신폰/빠른 인터넷/큰 모니터/일반적인 조작)**만 기준으로 만들지 않고, 실제 사용자에게서 발생하는 각종 **예외 상황(저사양 기기, 느린 네트워크, 로딩 지연, 브라우저 기본 기능/단축키, 접근성)**을 미리 가정하고 테스트·대응하는 것이다.[^1][^2]

[? 질문] 왜 프론트엔드에서는 예외 상황이 특히 더 많이/다양하게 생기는가[^1]
[= 답] 유저 환경이 기기 성능, 화면 크기/배율, 네트워크 품질, 브라우저 동작(뒤로가기/단축키), 신체적 제약 등으로 극단적으로 다양하고, 그 다양성이 그대로 성능 저하·레이아웃 붕괴·조작 불가·UX 오류로 드러나기 때문이다.[^1][^15][^22]

[? 질문] 이런 예외 상황을 개발자가 현실적으로 어떻게 “체감”하고 검증할 수 있는가[^9]
[= 답] 크롬 개발자도구에서 CPU throttling(저사양 기기 시뮬레이션)과 **네트워크 throttling(3G 등)**을 켜서 서민(?) 환경을 재현해 보고, 느린 요청은 타임아웃/취소(AbortController), 로딩 지연은 로딩 UI/서스펜스 폴백, 실패는 에러 바운더리, 화면/입력은 반응형·배율·키보드 조작·접근성 검사 등으로 대비한다.[^9][^21][^28]

# 2. 큰 그림[^1]

이 콘텐츠는 프론트엔드 개발자가 흔히 놓치는 “예외 상황 대비”를 주제로, 실제 사례(CSS 애니메이션 성능 문제, 느린 인터넷, SPA 뒤로가기 버그, 화면 크기/배율, 접근성)를 통해 왜 중요하고 무엇을 점검해야 하는지 설명한다.[^1][^5] 특히 개발자가 최신 기기·좋은 네트워크 환경을 기준으로 개발할 때 저사양/열악한 환경 사용자에게 UX 문제가 발생하는 과정을 보여주고, 크롬 도구와 구현 전략으로 이를 예방하는 방법을 제시한다.[^9][^21]

  • 개발은 “정상 케이스”보다 예외 케이스에서 품질이 갈린다: 저사양 기기·느린 인터넷·특이한 입력/브라우저 동작·접근성은 실제로 자주 발생한다.[^1][^16]
  • 성능 문제는 구현 디테일에서 터진다: 예를 들어 CSS 애니메이션에서 **레이아웃 변경 속성(margin/left/top/width 등)**을 대량 요소에 적용하면 렌더링 부담이 커지고, transform으로 바꾸면 개선될 수 있다.[^18][^19]
  • 검증은 “돈/환경”이 아니라 도구로 가능하다: 크롬에서 CPU 속도 저하, 3G 제한, 그리고 접근성 검사 도구 등을 통해 실제 사용자 환경을 시뮬레이션할 수 있다.[^9][^25][^32]

# 3. 하나씩 살펴보기[^1]

## 3.1 프론트엔드에는 예외 상황이 원래 많다: 유저 탓/서버 탓 + 프론트 특수 케이스[^1]

화자는 프론트엔드에서 코드를 짤 때 “당연히 예외적인 상황이 많이 발생”한다고 전제한다.[^1] 예외 상황의 원인은 크게:

  • 유저 탓으로 생기는 상황(사용 방식, 환경, 입력 등)[^2]
  • 서버 탓으로 생기는 상황(응답 지연, 실패 등)[^3]

같은 뻔한 범주가 있지만, 화자는 여기서 더 나아가 프론트엔드에 특수한 예외 상황이 많다고 강조한다.[^4] 즉, 프론트는 사용자 단말·브라우저·네트워크·입력 방식 같은 “바깥 변수”가 많아서, 개발자가 통제하기 어려운 문제들이 쉽게 발생한다는 문제의식을 깔고 간다.[^1][^4]

## 3.2 CSS 애니메이션 사례: “2D로 3D처럼 속이기”는 성공했지만, 모바일 저사양에서 버벅임 발생[^4]

화자는 최근에 심심해서 CSS 애니메이션을 만든 경험을 예시로 든다.[^4] 상황은 다음 흐름으로 전개된다.

  1. 만들고 싶었던 것: 이미지들을 3D처럼 보이게 “샤랄라” 애니메이션을 넣고 싶었다.[^4][^7]
  2. 현실적 제약: “진짜 3D 모델을 집어 넣기엔 너무 무거울 것 같아서” 다른 선택을 한다.[^6]
  3. 해결 아이디어(트릭): 3D 모델 대신 2D 이미지로 사기 치기.[^6]
    • 이미지 두 개를 합쳐서 아이소메트릭(isometric) 디자인 느낌으로 3D처럼 보이게 만든다.[^7]
    • 위에 조명 레이어 같은 것도 깐다.[^8]
  4. 결과: 애니메이션 자체는 잘 되는 것처럼 보였다.[^9]
  5. 사소하지만 치명적인 문제 발견: 모바일에서 테스트하니 최신 폰에서는 정상인데, 본인 기기인 갤럭시 A34에서는 “매우 버벅”였다.[^10]

여기서 요지는 “내 환경에서는 잘 되는데 특정 환경에서는 망가지는” 프론트엔드식 예외가 실제로 쉽게 발생한다는 점을 구체 사례로 보여주는 것이다.[^9][^10]

## 3.3 개발자는 최신 기기 기준으로 만들기 쉽다: 그 결과 보급형 사용자에게 성능 문제가 터진다[^11]

화자는 일반적으로 개발자들이 최신형 기기를 좋아하니, 코드도 “거기에 맞춰서” 짜기 쉽다고 말한다.[^11] 그런데 그렇게 되면:

  • 보급형 기기를 쓰는 유저는 사이트가 버벅일 수 있다.[^12]

이 대목에서 화자는 본인이 보급형 폰(갤럭시 A34)을 쓰는 경험을 섞어 농담조로 표현하지만, 메시지는 명확하다: 시장에는 최신 플래그십만 있는 게 아니며, 실제 판매량/보급량 측면에서 보급형이 훨씬 많을 수 있다는 것이다.[^13][^14]

  • 삼성은 S보다 A 시리즈가 더 많이 팔린다는 자료가 있다고 언급하며, “보급형 사용자가 적지 않다”는 근거로 든다.[^14]

즉, “내가 최신 기기라서 못 느끼는 문제”를 사용자들이 실제로 겪을 수 있으니, 개발자는 의식적으로 이런 예외를 고려해야 한다는 주장이다.[^11][^14]

## 3.4 돈이 없어서(?) 보급형을 못 만져봤다면: 크롬 CPU 저하로 저사양 체험하기[^15]

화자는 만약 부자(?)라서 보급형 폰을 만져본 적이 없다면, 크롬에서 “서민 체험”을 할 수 있다고 설명한다.[^15] 방법은:

  • 크롬 개발자도구 Performance 탭에서
  • CPU 속도를 낮춰 사이트를 시뮬레이션할 수 있다.[^16]
  • 대략 6배 정도 느리게 해두면 저사양 기기처럼 이용해볼 수 있다고 안내한다.[^17]
  • 만약 본인 CPU가 “괴물 CPU”면 20배 같은 더 큰 저하를 선택해 보라고도 한다.[^18]

여기서의 핵심은 “사용자 환경 다양성”을 단순히 상상으로 때우지 말고, 브라우저가 제공하는 기능으로 재현 가능한 테스트를 하라는 실무적 조언이다.[^16][^17]

[!TIP] 저사양 기기 성능 문제는 “재현”이 절반이다
크롬 개발자도구에서 CPU throttling을 걸면, 최신 PC/폰에서 개발하더라도 저사양 환경의 끊김/프레임 드랍을 체감하며 수정 포인트를 찾을 수 있다.[^16][^17]

## 3.5 애니메이션이 느렸던 진짜 이유: 레이아웃 변경 애니메이션을 “다수 요소(21개)”에 동시에 적용했기 때문[^19]

화자는 본인이 만든 애니메이션이 느렸던 이유를 설명한다.[^19]

  • margin, left, top, width 같은 레이아웃에 영향을 주는 속성을 애니메이션으로 조절하면, 브라우저가 렌더링을 “되게 힘들어”한다고 말한다.[^19]
  • 단, “개체가 몇 개 없으면” 이런 속성을 써도 상관없을 수 있다.[^20]
  • 하지만 본인 케이스는 동시에 21개의 개체에 대해 레이아웃 변경 애니메이션을 줬기 때문에 문제가 커졌다는 것이다.[^20]

즉, “무슨 속성을 애니메이션으로 움직이느냐”와 “그걸 몇 개 요소에 동시에 적용하느냐”가 결합되어 저사양에서 성능 문제가 폭발할 수 있다는 설명이다.[^19][^20]

## 3.6 해결: 레이아웃 변경 대신 transform으로 애니메이션을 주면 렌더링이 더 빠르다[^21]

해결책은 다음과 같다.

  • 레이아웃을 변경하지 않고 transform 같은 속성으로 애니메이션을 주면
  • 렌더링이 훨씬 빨라지기 때문에
  • 그런 식으로 변경해 성능 문제를 해결했다.[^21]

여기서 화자는 “그래서 transform으로 바꿨더니 성능이 해결됐다”라는 형태로, 프론트엔드 성능 튜닝의 대표적인 실무 규칙(레이아웃/리플로우 유발 애니메이션 지양)을 사례 기반으로 전달한다.[^19][^21]

[!IMPORTANT] 애니메이션 성능 점검 포인트
margin/left/top/width 등 레이아웃 변경 애니메이션은 부담이 크고, 특히 다수 요소 동시 적용 시 저사양에서 버벅일 수 있다. 가능하면 transform 기반으로 바꿔 성능을 확보한다.[^19][^20][^21]

## 3.7 애니메이션만 문제가 아니다: React(virtual DOM) + HTML이 많을 때 렌더링/프레임 문제가 생길 수 있다[^22]

화자는 “굳이 애니메이션 말고도” 요즘 많이 쓰는 리액트에서도 성능 예외가 생길 수 있다고 확장한다.[^22]

  • 리액트는 원래 버추얼 돔 때문에 무거워서 성능 문제가 일어나는 경우들이 있다고 말한다.[^23]
  • 페이지 안에 HTML이 너무 많으면:
    • 처음 로드할 때
    • 또는 재렌더링 할 때
    • 프레임이 잘 안 나오는 경우가 있을 수 있다고 경고한다.[^24]

그래서 결론적으로 “(저사양) 똥폰에 한번 확인해 보는 것도 필수”라는 취지로 말한다.[^24]

즉, 최신 개발 스택(React)을 쓴다고 해서 자동으로 모든 환경에서 성능이 보장되는 게 아니며, DOM 규모/렌더링 비용이 커지면 저사양에서 문제가 표면화될 수 있다는 예외 상황을 추가로 제시한다.[^22][^24]

## 3.8 요즘도 인터넷 속도 문제는 다시 발생한다: 수도권/지역, 5G 불안정으로 3G급 체감이 나온다[^25]

화자는 “요즘 인터넷 속도 문제가 다시 발생하고 있다”고 말한다.[^25] 이유를 “오지”라고 표현하며(도시/중심지 밖), 개발자의 생활권(서울)과 실제 사용자 환경(경기도 구석 등)의 차이를 지적한다.[^26]

  • 개발자 대부분이 서울에 살아서 체감 못 할 수 있지만[^27]
  • 경기도 구석만 가도 5G가 잘 안 잡혀서
  • 3G 속도로 갑자기 웹브라우징하게 되는 경우가 많다고 한다.[^27]

따라서 아직도 인터넷 속도 때문에 예외 상황이 많이 발생한다는 결론으로 이어진다.[^28]

여기서는 “네트워크는 이미 충분히 빠르다”라는 개발자 착각을 깨고, 실제로는 지역/상황에 따라 느린 속도가 현실적인 제약이며, 그로 인해 UX/기능 오류가 생긴다는 논지를 세운다.[^25][^28]

## 3.9 느린 통신을 전제로 UI를 설계하라: 로딩 UI, 구라 로딩바, Suspense fallback, Error Boundary[^29]

느린 인터넷 환경에서 프론트엔드가 해야 할 대응으로 화자는 여러 가지를 제시한다.[^29]

  • 서버와 통신하는 경우가 많으니, 로딩 중 UI를 꼭 넣는 것이 좋다.[^29]
  • 시간이 오래 걸리는 업로드 작업 같은 것에는 “구라 로딩바” 같은 것을 만들어 두는 것도 괜찮다고 한다.[^30]
  • React를 쓰면:
    • Suspense fallback 같은 태그를 쓸 수 있고[^31]
    • Error Boundary도 만들어 사용할 수 있다고 언급한다.[^32]

이 파트의 핵심은 “요청이 즉시 끝난다”를 가정하면 느린 환경에서 사용자는 멈춘 화면/깨진 흐름을 경험하게 되므로, 로딩/실패 상태를 UI와 코드 레벨에서 명시적으로 다루라는 것이다.[^29][^32]

[!TIP] 로딩/에러 상태는 ‘부가 기능’이 아니라 필수 UI 상태
느린 네트워크에서는 로딩 상태가 평소보다 훨씬 자주/길게 나타난다. 로딩 UI, 업로드 진행 UI, Suspense fallback, Error Boundary 같은 장치를 준비해 사용자 불안을 줄이고 실패를 통제한다.[^29][^30][^31][^32]

## 3.10 빠른 인터넷 쓰는 사람은 체감 못 한다: 크롬에서 3G 제한(흑수저 모드)으로 네트워크 체험[^33]

화자는 기가급 인터넷을 쓰는 사람은 느린 환경을 체감 못 할 수 있다고 말한다.[^33] 그럴 때 역시 크롬에서 시뮬레이션을 권한다.

  • 크롬에서 “흑수저 모드”를 켜면[^34]
  • 인터넷 속도를 3G급으로 제한해 볼 수 있다.[^35]

즉 CPU와 마찬가지로 네트워크도 개발자도구에서 제한을 걸어, 느린 통신에서 UI/로직이 어떻게 망가지는지 미리 보는 것을 강조한다.[^34][^35]

## 3.11 타임아웃/요청 취소도 예외 대비다: 오래 걸리면 자동 취소, AbortController로 쉽게 구현[^36]

느린 네트워크에서 중요한 또 다른 예외는 “요청이 너무 오래 걸리는” 상황이다.[^36] 화자는 여기에 대해:

  • 타임아웃 기능을 넣어주면 좋다고 한다.[^36]
  • 특정 HTTP 요청이 너무 오래 걸리면 자동으로 취소되게 만드는 것이다.[^37]

구현 방법도 비교한다.

  • 예전에는 Promise + setTimeout으로 직접 구현했는데[^38]
  • 요즘은 AbortController로 “되게 쉽게 구현”할 수 있다고 말한다.[^39]

요지는 사용자가 무한 대기하거나, 오래 걸리는 요청이 UI/상태를 꼬이게 만들기 전에 “중단”이라는 제어 장치를 두라는 것이다.[^36][^39]

## 3.12 느린 로딩은 화면을 “이상하게” 만든다: 이미지/CSS/JS 지연 로딩과 레이아웃/표시 깨짐[^40]

화자는 인터넷이 느리면 단순히 “기다림”만 문제가 아니라, 리소스 로딩이 늦어져 사이트가 이상해질 수 있다고 말한다.[^40]

  • 인터넷이 느리면 이미지, CSS, JS 파일 로딩이 느려지고[^40]
  • 예를 들어 이미지 로딩이 느리면 화면이 “이렇게 이상해질 수도” 있다고 한다(구체적으로 화면이 깨지는 상황을 시연/상정).[^41]

즉, 로딩 순서/지연을 고려하지 않으면 이미지가 없을 때 레이아웃이 무너진다든지, 스타일/스크립트가 늦게 적용되어 UI가 튀는 등의 예외가 발생할 수 있다는 경고다.[^40][^41]

## 3.13 스크립트가 많으면 로드가 막힌다: defer로 페이지 로드 블로킹 예방[^42]

또 다른 예외는 JS 로딩이 페이지 로드를 막는 경우다.[^42]

  • 스크립트 태그가 많은 사이트에서
  • 사이즈가 큰 JS 파일들이
  • 페이지 로드를 블로킹할 수 있다고 말한다.[^42]

예방책으로:

  • script에 defer 같은 키워드를 붙여서 예방할 수 있다고 제안한다.[^43]

즉, “빠른 환경에서는 티가 안 나지만” 느린 환경/큰 번들/스크립트 다수 상황에서 초기 로딩이 심각하게 지연되는 예외를 방지하라는 내용이다.[^42][^43]

## 3.14 화면 크기/배율도 예외다: 큰 모니터 기준 레이아웃 실수, 320px 사용자, 확대 사용자의 존재[^44]

화자는 웹개발 초기에 흔히 하는 실수로, 본인이 큰 모니터를 쓰기 때문에 거기에 맞춰 기본 레이아웃을 짜는 경우를 든다.[^44]

하지만 현실에는:

  • 아직도 320px 화면 사이즈로 접속하는 사람도 있고[^45]
  • 눈이 안 좋아서 화면 배율을 키워서 쓰는 사람도 있다고 말한다(본인도 그렇게 쓴다고 언급).[^46]

따라서 그런 상황에서도 사이트가 잘 보이는지 체크하는 것이 좋다고 권한다.[^47]

이 파트는 반응형/접근성의 출발점이 “모두가 내 화면처럼 본다”는 가정을 버리는 것임을 강조한다.[^44][^47]

## 3.15 브라우저 기본 버튼/단축키도 예외다: SPA에서 뒤로가기 동작이 꼬이는 실제 사례(네이버 메일)[^48]

화자는 “요즘은 브라우저 기본 버튼들”을 누를 때도 이상한 상황이 발생할 수 있다고 말한다.[^48] 그리고 “그런 경우가 어디 있냐”라는 질문을 던진 뒤, 구체 사례로 네이버 메일을 든다.[^49]

  • 네이버 메일이 최근 리액트 느낌의 SPA 사이트로 바뀐 것 같고 디자인도 예뻐졌다고 평가한다.[^49]
  • 그러나 버그가 몇 가지 있다고 한다.[^50]

화자가 설명하는 버그 시나리오는:

  1. 아래의 페이지 버튼 1 2 3 4 5를 차례로 누른다.[^51]
  2. 그 다음 뒤로 가기를 누르면, 직관적으로는 4로 가야 할 것 같지만 바로 3페이지로 가버린다.[^52]
  3. 그 시점부터는 뒤로가기를 눌러도 아무 반응이 없다.[^53]

원인 추정/해석으로 화자는:

  • “리액트 같은 거 써서 그런 거 같다”고 말한다.[^54]
  • 리액트 같은 걸 써서 사이트를 만들면 페이지 이동을 과거와 다르게(특이하게) 처리하기 때문에,
  • 사람들이 이런 식으로 뒤로가기 버튼을 누른다는 걸 가끔 까먹고 코드를 짜는 경우가 많은 것 같다고 한다.[^55]

즉, SPA 라우팅/히스토리 처리에서 브라우저 기본 동작(뒤로/앞으로)의 기대를 만족시키지 못하면 실제 서비스에서도 UX 결함/버그로 이어질 수 있다는 “프론트 특수 예외”를 실제 대형 서비스 사례로 설명한 것이다.[^49][^55]

## 3.16 컨트롤 클릭 같은 단축키/기본 상호작용도 테스트 대상이다[^56]

화자는 브라우저에서 많이 쓰는 단축키도 언급한다.[^56]

  • 예: 컨트롤 클릭 같은 걸 좋아하는 사람이 많다.[^56]
  • 그런데 가끔 UI가 그런 동작을 막아버려서 하고 싶어도 안 되는 경우가 있다.[^57]

그래서 이런 것들이 잘 되는지 테스트해 보는 것도 좋다고 한다.[^57]

요지는 단순히 “클릭 되면 됨”이 아니라, 사용자들이 실제로 사용하는 브라우저/OS 레벨의 상호작용(새 탭 열기, 키보드 조작 등)을 방해하지 않는지까지 점검하라는 것이다.[^56][^57]

## 3.17 (뻔하지만 가장 중요한) 접근성도 예외 상황이다: 시각/청각, 키보드·마우스 사용 불가 사용자[^58]

마지막으로 화자는 “뻔한 얘기”라고 전제하면서도 접근성을 예외 상황으로 포함한다.[^58]

  • 시각/청각이 불편한 사람들도 있고[^58]
  • 키보드랑 마우스를 이용 못 하는 사람들도 있는데[^59]
  • 이런 경우도 예외 상황이라고 볼 수 있다고 한다.[^59]

그리고 이런 분들을 위해 “이런 것들 해 두면 좋을 것”이라고 말하며(구체 항목은 영상 맥락상 접근성 대응 전반을 의미),[^60]

  • 크롬 안에 accessibility checker가 있으니 한번 돌려보라고 제안한다.[^61]

끝으로 화자는 이런 식으로 코드를 짜는 게 “쓸데없어 보이긴” 해도, 이런 것 하나하나가 더 견고한 프로그램을 만든다고 결론낸다.[^62] 그리고 AI는 아직 공감 능력이 부족하니, 나중에 이런 걸 어필해서 개발자 밥그릇을 챙기면 될 것 같다는 농담으로 마무리한다.[^63]

즉, 접근성은 “선의”만의 문제가 아니라, 사용자 다양성이라는 예외를 받아들이는 실무 품질의 일부이며, 그 자체가 견고함을 만든다는 메시지다.[^59][^62]

# 4. 핵심 통찰[^1]

  1. 프론트엔드 품질은 “정상 동작”이 아니라 예외 상황에서의 견고함으로 드러난다.[^1][^62]
  • 저사양, 느린 통신, 작은 화면/큰 배율, 브라우저 기본 동작, 접근성은 모두 실제 사용자에게 일어나는 정상적인 현실이다.[^14][^27][^45][^59]
  1. 개발자 본인의 환경(최신 기기/기가 인터넷/큰 모니터)은 사용자 평균을 대표하지 않는다.[^11][^33][^44]
  • 보급형 기기가 더 많이 팔릴 수 있고, 지역에서는 5G가 3G처럼 느려질 수 있다.[^14][^27]
  1. 성능 문제는 “기술 선택”보다 구현 방식에서 터진다.[^19][^21]
  • 레이아웃 변경 애니메이션을 다수 요소에 적용하면 저사양에서 망가지고, transform 등으로 바꾸면 개선될 수 있다.[^20][^21]
  1. 느린 네트워크는 로딩 UI/에러 처리/요청 취소 등 상태 설계를 요구한다.[^29][^36]
  • 로딩 UI, 업로드 진행(구라 로딩바 포함), Suspense fallback, Error Boundary, 타임아웃/AbortController 같은 장치는 “있으면 좋은 것”이 아니라 느린 환경에서 필수 안전장치다.[^30][^31][^39]
  1. SPA는 브라우저 기본 UX(뒤로가기/단축키)와 충돌하기 쉬우며, 이를 테스트하지 않으면 실제 서비스에서도 버그가 난다.[^55][^57]

실행 항목(콘텐츠가 제안한 방향대로 구체화):

    • 크롬 DevTools에서 **CPU throttling(6x~20x)**로 저사양 성능을 체감 테스트한다.[^17][^18]
    • 크롬에서 Network 3G 제한으로 느린 통신에서 로딩/깨짐을 점검한다.[^35][^41]
    • CSS 애니메이션에서 margin/left/top/width 등 레이아웃 변경을 남발하지 않고, 가능하면 transform 중심으로 설계한다.[^19][^21]
    • 통신 기능에는 로딩 UI, 업로드 진행 UI, React의 Suspense fallback/에러 바운더리 적용을 검토한다.[^29][^31][^32]
    • 요청이 오래 걸릴 때를 대비해 AbortController 기반 타임아웃/취소를 넣는다.[^36][^39]
    • 작은 화면(320px)과 화면 확대 배율에서도 레이아웃이 유지되는지 확인한다.[^45][^46]
    • 뒤로가기/앞으로가기, 컨트롤 클릭 등 브라우저 기본 상호작용이 자연스럽게 동작하는지 테스트한다.[^52][^56]
    • 크롬 접근성 검사 도구로 최소한의 접근성 이슈를 점검한다.[^61]

# 5. 헷갈리는 용어 정리[^22]

  • 아이소메트릭(isometric) 디자인: 2D 요소를 특정 각도/배치로 구성해 3D처럼 보이게 만드는 시각적 표현 방식(화자는 이미지 두 개를 합쳐 3D 느낌을 내는 예로 사용).[^7]
  • CPU throttling: 개발자도구에서 CPU 속도를 인위적으로 낮춰 저사양 기기처럼 성능을 시뮬레이션하는 기능.[^16][^17]
  • Network throttling(3G 제한): 네트워크 속도를 3G 등으로 제한해 느린 통신 환경을 재현하는 기능.[^35]
  • 레이아웃 변경 애니메이션: margin/left/top/width 등 레이아웃 계산에 영향을 주는 속성의 변화로 애니메이션을 만드는 방식(브라우저 렌더링 부담이 커질 수 있다고 언급).[^19]
  • transform 애니메이션: transform 속성으로 위치/크기/회전 등을 바꿔 애니메이션을 만드는 방식(레이아웃 변경 없이 더 빠를 수 있다고 언급).[^21]
  • SPA: 페이지 전환이 전통적인 방식과 다르게 동작하는 웹 앱 형태로, 뒤로가기 같은 브라우저 기본 동작과 충돌할 수 있음을 사례로 설명.[^49][^55]
  • Suspense fallback: React에서 로딩 상태에 보여줄 대체 UI를 지정하는 개념/태그로 언급.[^31]
  • Error Boundary: React에서 렌더링 중 에러를 잡아 대체 UI를 보여주는 에러 처리 패턴/컴포넌트로 언급.[^32]
  • AbortController: 요청이 오래 걸릴 때 취소/중단을 쉽게 구현하는 최신 방식으로 언급.[^39]
  • defer: 큰 JS 파일이 페이지 로드를 블로킹하는 것을 예방하기 위해 script에 붙이는 키워드로 언급.[^43]
  • Accessibility checker: 접근성 문제를 점검하는 크롬 도구로 언급.[^61]

참고(콘텐츠 정보)

  • 제목: 프론트엔드에서 가장 중요한데 가장 안하는거[^1]
  • 채널: 코딩애플[^1]
  • 길이: 5분 37초[^1]
  • 링크: https://www.youtube.com/watch?v=_8deUuO0iJ8[^1]
  • 키워드(제공): 개발자, 취업, 코딩, 프로그래밍, 자바스크립트, 개발, 프론트엔드, 백엔드, exception, 예외[^1]

[^1]: @[00:00] “프론트엔드에서 코드 짤 때도 당연히 예외적인 상황이 많이 발생할 수 있습니다” + 사용자가 제공한 메타데이터(제목/채널/길이/링크/키워드). [^2]: @[00:04] “뭐 유저 탓으로 발생하는 상황도 있고요” [^3]: @[00:08] “아니면 서버 탓으로 발생하는 상황도 있습니다” [^4]: @[00:13] “프론트 엔드에 좀 더 특수한 예외 상황들도 많이 발생하는데…” [^5]: @[00:19] “최근에… css 애니메이션 하나를 만든 적이 있습니다” [^6]: @[00:19] “진짜 3D 모델을 집어 넣기엔 너무거울 것 같아서 2D 이미지로 사기 치기로 했습니다” [^7]: @[00:24] “이미지 두 개를 합쳐 놓으면 아이소메트릭 디자인 느낌으로… 3D 같아 보이니까요” [^8]: @[00:30] “위에 조명 레이어 같은 것도 이렇게 깔아 봤고요” [^9]: @[00:35] “그다음에 요런 애니메이션을 집어넣어 봤는데 자 잘 되는데…” [^10]: @[00:42] “모바일에서 테스트… 최신 폰들에… 근데… 갤럭시 a34 이선 매우 버벅이는 거예요” [^11]: @[00:56] “개발자들은… 최신형 기기들을 좋아하기 때문에 코드도 거기 맞춰서…” [^12]: @[00:56] “보급형 기기를 쓰는… 유저들에게는… 버벅이고…” [^13]: @[01:00] “그런 보급형… 제가 쓴다요” [^14]: @[01:08] “삼성… S 다 a 시리즈가 훨씬 많이 팔린다는 자료…” [^15]: @[01:13] “부자라서… 만져 본 적이 없다면… 크롬에서 언제나 서민 체험…” [^16]: @[01:17] “퍼포먼스 탭… CPU 속도를 낮춰서요” [^17]: @[01:22] “한 여섯 배 정도… 저사양 기기처럼…” [^18]: @[01:26] “괴물 CPU… 20배 정도…” [^19]: @[01:37] “마진… 레프트 탑… 위드스… 애니메이션… 브라우저가 렌더링을 되게 힘들어합니다” [^20]: @[01:44] “저는 동시에 21개의 개체에 레이아웃을 변경하는 애니메이션…” [^21]: @[01:53] “트랜스폼… 속성으로 애니메이션… 훨씬 렌더링이 빨라지기 때문에… 해결” [^22]: @[02:00] “요즘에 리액트를 많이…” [^23]: @[02:07] “리액트… 버추얼 돔 때문에 무거워서…” [^24]: @[02:07] “html이 너무 많으면… 로드… 렌더링… 프레임이 잘 안 나오는… 똥 포해 한번 확인…” [^25]: @[02:14] “요즘 인터넷 속도 문제가 다시 발생하고 있습니다” [^26]: @[02:28] “이유는 오지구요” [^27]: @[02:33] “개발자 대부분은 서울… 경기도 구석… 5G 잘 안 잡히기 때문에 3G 속도로…” [^28]: @[02:37] “아직도 인터넷 속도 때문에 예외 상황들이…” [^29]: @[02:42] “통신하는 경우… 로딩 중 UI 같은 거 꼭 넣어 주는…” [^30]: @[02:48] “업로드 작업… 구라 로딩바…” [^31]: @[02:54] “리액트… 서스펜스 폴백…” [^32]: @[02:57] “에러 바운더리…” [^33]: @[03:00] “돈이 많아서… 기가급 인터넷… 체감을 못…” [^34]: @[03:03] “크롬에서 흑수저 모드…” [^35]: @[03:09] “인터넷 속도를 3G 급으로 제안해 볼 수도…” [^36]: @[03:12] “타임아웃 기능도 넣어 주시면 좋은데” [^37]: @[03:12] “요청이 너무 오래 걸리면 자동으로 취소…” [^38]: @[03:19] “예전에 프로미스 셋 타임아웃으로 직접 구현…” [^39]: @[03:19] “요즘은 어보트 컨트롤러로 되게 쉽게…” [^40]: @[03:26] “인터넷 속도가 느리면 이미지 css 자바스크립트 파일 로딩이 느려져서 사이트가 이상해지기…” [^41]: @[03:26] “예를 들어서 이미지 로딩이 느리면 이렇게 이상해질 수도…” [^42]: @[03:33] “스크립트 태그가 많은… 큰 JS 파일들이 페이지 로드를 블로킹…” [^43]: @[03:42] “디퍼… 키워드를 붙여서… 예방…” [^44]: @[03:46] “흔히 하는 실수… 모니터를 크게… 그거에 맞춰서 기본 레이아웃…” [^45]: @[03:50] “아직도 320픽셀 화면 사이즈로 접속…” [^46]: @[03:54] “눈이 안 좋아서 화면 배율을… 키워서…” [^47]: @[03:59] “그런 상황에서도 사이트가 잘 보이는지 체크…” [^48]: @[04:03] “브라우저 기본 버튼들… 누를 때도 이상한 상황…” [^49]: @[04:15] “네이버 메일… 리액트 느낌의 spa…” [^50]: @[04:18] “근데 버그들이 몇 가지가 있습니다” [^51]: @[04:22] “밑에 1 2 3 4 5 버튼들을…” [^52]: @[04:26] “뒤로 가기… 4로… 같지만… 3페이지로…” [^53]: @[04:35] “이때부터는 뒤로 가기… 아무 반응이 없어요” [^54]: @[04:37] “왜냐면 리액트 같은 거 써서 그런 거 같고요” [^55]: @[04:40] “리액트… 페이지 이동… 다르게… 사람들이… 뒤로 가기 버튼… 까먹고…” [^56]: @[04:49] “브라우저… 단축키… 컨트롤 클릭…” [^57]: @[04:49] “가끔 그런게 안 되는 UI… 테스트…” [^58]: @[04:58] “뻔한 얘기지만… 시각 청각이 불편한…” [^59]: @[05:13] “키보드랑 마우스를 이용 못 하는… 이런 경우도 예외…” [^60]: @[05:18] “그런 분들을 위해서… 이런 것들 해 두면…” [^61]: @[05:23] “액세스빌리티 체커… 크롬 안에…” [^62]: @[05:27] “쓸데없어 보이긴… 이런 거 하나하나가 더 견고한 프로그램…” [^63]: @[05:32] “AI… 공감 능력… 나중에… 어필해서… 개발자 밥그릇…”

← 프로젝트에서 보기