[REST API 연동 React 앱] 오상현 제출합니다 by ohsanghy09 · Pull Request #25 · Dev-MAMOKEY/1th-frontend-study

ohsanghy09 · 2026-05-29T05:21:57Z

과제명

REST API 연동 React 앱

💡 작업 내용

키워드 입력 검색, 영화 리스트 카드 UI, 로딩 상태 처리, 에러 처리
TMDB API 연동(axios)
.env 파일 생성 및 .gitignore 설정

🔗 참고 링크

인기 영화 목록 관련 API 문서 : https://developer.themoviedb.org/reference/movie-popular-list
영화 검색 관련 API 문서 : https://developer.themoviedb.org/reference/search-movie
이미지 관련 설정 문서 : https://developer.themoviedb.org/docs/image-basics

https://chatgpt.com/

🤔 느낀 점 / 어려웠던 점

React에서 .env 파일설정과 .gitignore의 사용법을 알 수 있었고, 이번 과제를 통해서 요청 받은 객체에 대한 정보를 공식 문서로 볼 수 있지만 콘솔에 출력해서 데이터 구성이 어떻게 되어 있는지 직접 확인해 보는 것도 좋다고 생각했습니다..!

📤 제출 방법

Vercel 배포 링크 : https://react-api-sigma-coral.vercel.app/
사용한 API : TMDB, https://www.themoviedb.org/

📝 기타 사항

현재 과제에 대한 작업 내용은 프로젝트 폴더 내의 README.md에 존재하므로, 전체 과제 내용과 관련된 README.md 파일은 제거했습니다.

wzrabbit

@ohsanghy09 👋🏻
안녕하세요 상현님! 제가 한 주차 쉬고 오니까, 어느새 React 애플리케이션 관리는 물론 API를 사용하시는 단계까지 오셨군요
API 문서와 친해지는 계기가 되었으면 합니다 💪🏻

리뷰는 코멘트를 제외했을 때 크게 세 가지를 짚었습니다.

1️⃣ 미사용 코드 제거

이번 단계에서 미사용 코드를 정리하는 연습을 더 적극적으로 해 보셨으면 하는 바램입니다. 💪🏻
React 입문 당시에는 미사용 코드를 제거하는 것은 각 파일들의 역할을 이해하는 측면이 강했다면, 이번에는 실제로 미사용 코드가 그대로 프로젝트 수면 위로 올라와 기능에 영향을 준 상황이 되었어서 그렇습니다.

_2026_06_01_18_00_04_322.mp4

영상을 보시면, 운영체제에서 테마를 다크 테마로 했을 때 상현님 프로젝트의 일부 UI가 반응하여 색상이 밝아지는 것을 보실 수 있어요. 그런데 상현님의 프로젝트는 다크 모드를 처음부터 설계하고 만들어진 것이 아니라고 보아요. 그러면 이 색상이 밝아지는 현상은 의도가 아닐 거에요.

남아 있던 미사용 코드가 실제로 작동하여 이 문제를 일으키고 있어요. 이제는 가볍게 여기지 않고 점검에 돌입하셔야 할 것 같습니다.

추가로, 지워지는 README.md 파일이 있는데 의도상 지워지면 안 되는 파일처럼 보이는데, 혹시 react-api/README.md를 삭제하려 하신 건가요? 이 부분도 확인해 주시면 좋겠어요

2️⃣ 예외처리에 대해

API 사용 시 응답 결과를 정확하게 보여주는 것만큼이나 중요한 것이 예외 처리라 할 수 있죠.

전반적으로 탄탄하게 여러 상황을 생각하고 처리하시려 하는 모습이 코드에 보여서 좋았어요. 네트워크 에러를 대응해 오류가 발생했다고 화면에 보여주는 것까지는 일반적인 범주라 생각하는데, 그 외에도 포스터가 없는 경우와 포스터에 대한 설명이 없는 경우도 생각하셔서 각각 UI로 대처를 하셨더라고요. 👍🏻

여기에 개선되면 좋을 만한 점 하나 얹어 보자면, 사용자가 검색어를 넣어 검색을 하는 상황에서 검색 결과가 없는 상황에서도 안내 메시지나 UI 등이 보여져서, 사용자가 명확하게 이것이 오류가 아니라 검색 결과가 없다는 사실을 알 수 있으면 좋겠다는 생각이 들었습니다. 두 가지 고민 지점도 있겠네요:

검색 결과가 없는 상황은 API 서버에서 오류로 간주할까요, 아니면 정상 응답(200)으로 간주할까요?
검색 결과가 없는 경우와 오류가 발생하여 결과가 빈 경우를 어떻게 구분할 수 있을까요?

3️⃣ `.env`의 작성 방법을 동료에게 알려주는 방법과 유출에 대해

첫 번째로 .env의 작성 방법 알려주기에요.

예전에 따로 저와 질문을 주고받을 때 .env가 필요한 프로젝트라면 충분한 설명을 할 것을 조언드렸었어요. 우선은 이 부분이 이루어지지 않은 점은 아쉬웠어요. .env는 아무래도 PR에 올리거나 공개적으로 공유하면 안 되는 값들이 있을 수 있기 때문에 리뷰어가 따로 마련해야 할 거에요. 이 경우 어떤 키 값을 채워야 프로젝트를 구동시킬 수 있는지 알아야 원활한 리뷰로 이어질 수 있을 것이라 생각해요.

마침 README.md 이야기가 1번에서 나왔으니, README.md에 이러한 내용 관련해서 채우기는 어떨까 생각합니다!

그리고, 좀 더 알아보았는데 .env.example 과 같은 파일을 두고, 거기에 env 파일의 형식을 알려주는 사례도 많은 것 같아보였어요. 이 방식이 마음에 드시면 이 방식도 써볼 만해보입니다

.env.example

VITE_TMDB_BASE_URL=https://api.themoviedb.org/3
VITE_TMDB_ACCESS_TOKEN=your_api_key_here
VITE_TMDB_IMAGE_BASE_URL=https://image.tmdb.org/t/p/w500

두 번째로 .env 파일에 적힌 액세스 토큰의 유출 건이에요.

상현님의 프로젝트에서는 불행히도 이 토큰이 유출되었어요. .env 파일은 보안에 대한 중요성을 인지하시고 Github에 올리지 않으셨어요 -- 잘 하셨어요.

다만 예상 밖의 영역에서 이 일이 일어났어요. VITE_* 형식의 환경변수 값은 빌드 시 번들에 포함되고, 이후 웹사이트에서 API 서버에 요청을 하면, 개발자 도구의 네트워크 기록에서 토큰이 노출되게 돼요. 브라우저/클라이언트에서의 요청 기록은 아무래도 공개적이니까요. VITE_*를 뗀다? 그러면 빌드 시 번들에 포함되지 않고, 아예 프로젝트에서 해당 키를 사용하지 못하니 기능이 작동하지 않겠죠.

그래서 이 환경에서는 요청을 직접 API 서버로 하는 과정이 브라우저 단에서 일어나는 한 노출을 막을 수는 없어요.

해결책은 바로 서버리스 서버를 두는 거에요. 브라우저에서 요청은 공개적이지만, 서버 내에서 또 다른 서버로 요청하는 것은 공개적이지 않아요. 서버리스 서버를 두어 해결하는 방법은 아래와 같아요.

클라이언트는 서버리스 서버에만 정보를 요청해요. 클라이언트는 토큰과 같은 중요한 정보를 들지 않아요.
서버리스 서버가 토큰과 같은 중요한 정보를 들고 있어요. 그리고 이 토큰은 밖으로 유출하지 않아요.
서버리스 서버가 클라이언트를 통해 요청을 받으면, 받은 요청에서 토큰만 추가한 다음, 그대로 API 서버에 요청을 해요.
API 서버는 서버리스 서버에 정보를 응답해요.
서버리스 서버가 클라이언트에 정보를 응답해요.

결론적으로 토큰과 같은 유출되어서는 안 되는 정보를 서버리스 서버에 은닉하고, 기능은 평소처럼 작동하도록 만들 수 있어요. 다만 여기부터는 과제의 범위에서 벗어날 수도 있다 생각하므로, 지금은 "아, 이런 방법으로 유출될 수 있구나" "아, 이런 방법이 있구나" 정도로만 생각해 보셔도 충분하다 생각합니다. 강제하지 않을게요.

아래 글도 참고해 보시면 좋을 것 같아요.

서버리스 서버를 도입하실 계획이 없다면 배포하신 페이지는 다시 내려주실 것을 요청드릴게요! 필수 요구사항에 배포가 있는데 지키지 않으셔도 괜찮습니다 (제가 책임질게요 😓 )

그럼, 이번 과제도 화이팅입니다!

wzrabbit · 2026-06-01T09:36:05Z

@@ -0,0 +1,23 @@
+import axios from "axios";


axios를 사용해주신 이유는 무엇인가요?

axios를 사용한 이유는 이전에 Vue 프로젝트에서 사용해본 경험이 있어서 익숙해서였어요.

물론 fetch도 찾아봤는데, response 데이터를 직접 json으로 변환해야 하고, 400번대나 500번대 응답이 axios처럼 자동으로 catch로 넘어가지 않아 response.ok를 직접 확인해야 하는 등의 귀찮음이 있어서 이번 과제에도 axios를 사용했습니다.

axios는 공통 설정 코드가 간결하고, 응답 데이터 처리, 에러 처리가 fetch보다 편리하다고 생각해서 앞으로도 계속 사용할 것 같아요!!

Vue에서 경험이 있으셨군요! 지금은 익숙한 도구를 자유롭게 골라주셔도 될 것 같습니다. 언제 공식 문서 한 번 보시는 것도 좋을 것 같아요. 할 수 있는 목록이 쫘라락 나오고, fetch와 비교되는 특징이나 장점이 보일 수도 있습니다.

말씀해주신 대로 axios를 사용해 주실 때에는 fetch와 다른 동작들이 여럿 있는데, 그 중 하나가 axios는 4xx/5xx번대 response status를 명시적으로 reject해준다는 것에 있어요

이 동작 차이는 axios를 좋아하는 개발자들은 장점으로 보기도 하고, 장단점이 아닌 특징 차이 정도로 생각하시는 개발자분들도 계시는 등 의견은 좀 갈리는 영역인 것 같아요

wzrabbit · 2026-06-01T09:37:31Z

+  headers: {
+
+    // Authorization은 인증 정보를 담는 것, 인증 방식이 Bearer
+    Authorization: `Bearer ${import.meta.env.VITE_TMDB_ACCESS_TOKEN}`,
+  },
+
+  // 한국어로 응답값 받아오기 위한 설정
+  params: {
+    language: "ko-KR",
+  },


headers와 params는 각각 어떤 의미를 지니는 친구들일까요? 두 값 모두 서버로 넘어가는 값인 것 자체는 동일해보이는데요

headers와 params 모두 서버로 값을 전달하는 것은 맞지만, 역할이 다르다고 알고 있어요.

headers는 요청 자체에 대한 정보나 인증 정보를 전달하는 역할, params는 API 요청에 필요한 조회 조건을 전달하는 역할로 사용했어요.

이번 과제에서는 headers에 Authorization으로 Access Token을 담아 TMDB API를 사용할 권한을 확인했고, params는 language: "ko-KR"를 넣어 응답 데이터를 한국어로 받아오기 위한 조건으로 사용했습니다!

headers는 메타데이터/인증 정보, params(쿼리 파라미터)는 필터링/조회 조건. 깔끔하네요 👍🏻

wzrabbit · 2026-06-01T09:44:28Z

+              {movie.poster_path ? (
+
+                // src를 통해 해당 포스터 그림을 참조하여 화면에 띄움, alt를 사용하여 나오지 렌더링 실패 시 타이틀이름만 나오게.
+                <img
+                  src={`${import.meta.env.VITE_TMDB_IMAGE_BASE_URL}${movie.poster_path}`}
+                  alt={movie.title}
+                />
+
+
+                // 만약 포스터 패스가 존재하지 않으면 div 태그 나오게 함.
+              ) : (
+                <div className="no-image">이미지 없음</div>
+              )}


👍🏻 API상 poster_path가 null로 올 수 있습니다. 잘 관찰하고 대처해주셨어요
그 아래의 줄거리가 없는 경우도 잘 대처해주신 것 같아요

넵 감사합니다!!

wzrabbit · 2026-06-01T09:51:08Z

전체적으로 App.jsx가 꽤 다양한 책임을 지고 있다는 생각이 듭니다. 데이터 호출 / 상태 / 화면 모두를 맡고 있어요.
함수를 나누듯이, 컴포넌트도 마찬가지로 덩치가 커지거나, 일부 UI가 재사용 가능한 형태가 될 수 있거나, 짊어지는 책임이 너무 많거나 하는 등의 이유가 있어 분리하는 것이 더 득이 크다면 나눌 수 있다고 생각합니다.

하지만 이 정도의 규모라면 충분히 나누지 않을 이유도 있을 수 있습니다. 압도될 정도의 규모가 아니고요. 그래서 상현님께 생각을 여쭤보고자 합니다.

저는 이 컴포넌트가 "데이터 호출 / 상태 / 화면 모두" 에 대한 책임을 구체적으로 지고 있다는 점에서 분리를 고려할 만하다고 생각합니다. 상현님은 어떻게 생각하시나요?

의천님이 말씀해주신 것처럼 현재 App.jsx에서 데이터 호출, 상태 관리, 화면 렌더링을 모두 담당하고 있지만, 이번 과제는 화면이 한 페이지로 구성되어 있고, 상태도 keyword, movies, loading, errorMessage 정도로 있어서 App.jsx 안에서 관리해도 흐름을 파악하기 어렵지 않다고 판단했습니다.

또한 데이터 호출 부분도 인기 영화 목록 조회와 영화 검색 요청 두 개라서, 컴포넌트로 분리했을 때 파일 구조가 더 복잡해질 수 있다고 생각했어요.

특히 데이터 호출 부분은 본 컴포넌트가 갖고 있는 게 맞다고 생각하는데, 이유는 본 컴포넌트의 화면에서 데이터 호출이 별로 없고, 데이터를 다른 컴포넌트에서 호출해 가져오면 데이터 관리면에서 복잡해져 힘들다고 생각하기 때문이에요.

데이터 호출 / 상태 / 화면 부분은 로직이 더욱 복잡해지면 분리하는 게 좋다고 생각합니다..!

분리해야 하는 조건이 꼭 라인 수는 아니겠죠, 화면이 한 페이지로 구성되어 있다, 상태 또한 이해하기에 감당 가능한 영역에 있다 -- 말씀하신 대로 꼭 당장 분리하지는 않아도 되는 신호라고도 충분히 생각해요.

대신 이 부분에 대해서는 다른 방법으로 분리하는 방법도 충분히 있을 것 같습니다

특히 데이터 호출 부분은 본 컴포넌트가 갖고 있는 게 맞다고 생각하는데, 이유는 본 컴포넌트의 화면에서 데이터 호출이 별로 없고, 데이터를 다른 컴포넌트에서 호출해 가져오면 데이터 관리면에서 복잡해져 힘들다고 생각하기 때문이에요.

말씀하신 대로 데이터가 매우 복잡하지 않은 상황인데 굳이 데이터를 파편화하려 한다면 오히려 관리가 복잡할 수 있다는 점에 동의합니다. 이 경우에는 데이터를 분리하지 않으면서 다른 로직들을 떼어내는 수법을 많이 쓰기도 하는 것 같아요.

반복되는 요소나 분리 가능한 요소를 찾아 분리하여 컴포넌트로 만들기. 데이터는 여전히 부모가 가진 채로 화면을 담당하는 친구들만 빼내니 데이터 면에서 혼란이 없습니다.

커스텀 훅으로 빼 보기. 반복되는 로직이나 분리하고 싶은 로직이 있는데 이 로직이 React 상태를 품고 있어서 단순 도메인 함수로 빼기 어려울 때가 있습니다. 이 때에 써먹기 좋은 친구가 바로 커스텀 훅입니다. 심지어 컴포넌트를 하나만 쓰고 재사용도 하지 않더라도, 상태를 다루는 부분과 UI를 다루는 부분을 분리하여 운용할 때 빛을 발하기도 합니다.

종합적으로 분리는 네, 여기서는 말씀하신 대로 유지해도 되어 보입니다. 대신 꼭 데이터를 분리해야만 분리할 수 있는 것은 아니니 방법 자체는 더 고민해보셔도 좋을 것 같습니다 💪🏻

wzrabbit · 2026-06-01T09:51:25Z

 *.local

+# Environment variables
+.env


감사합니다!!

wzrabbit · 2026-06-01T09:56:59Z

<html lang="ko">

이 사이트는 API에 요청할 때도 한국어 파라미터를 넣어서 한국어 결과로 가져오려 하는 등 명확하게 한국어 이용자를 위한 사이트로 보입니다. 따라서 이 수정을 제안합니다.

여기까지만 보면 한 줄 변경인데다 눈에 보이는 변경점도 없어 보입니다. 그래서 "굳이?" 로 생각하실 수 있다고 생각합니다
이번에는 별 설명을 하지 않을테니, 상현님께서 이 변경사항을 제안하는 제 의도를 추측해보실래요?

이번 과제는 한국어를 기준으로 구성되어 있고, TMDB API 요청도 language: "ko-KR"로 설정되어 있기 때문에 의천 님의 의견처럼 HTML 문서의 기본 언어도 한국어로 지정하는 것이 의미상 더 적절하다고 생각합니다!

이번 리뷰를 작성하면서 스크린 리더라는 것을 처음 접해 알아봤는데, 시각장애인이나 저시력 사용자가 웹페이지 내용을 음성으로 들을 때 사용하는 보조 도구라고 하더라구요. 스크린 리더는 한국어를 <html lang="ko">로 수정하면 영어로 설정했을 때보다 자연스럽게 읽을 수 있다고 하는데 이 점이 인상 깊게 느껴졌습니다!!

감사합니다!!

네, 접근성 이야기를 좀 꺼내보고 싶었고, 잘 알아내 주신 것 같습니다
저 언어 설정 하나로 스크린 리더가 읽어주는 단어의 뉘앙스와 방식이 완전히 달라집니다.

아래 자료 추천해봅니다.

[10분 테코톡] 해온, 첵스의 웹접근성 & 웹표준

특히, 5:07 부터 들으시면 스크린 리더가 어떤 방식으로 사용자에게 정보를 전달하는지 직접 들어보실 수 있습니다

wzrabbit · 2026-06-01T11:24:19Z

+          {movies.map((movie) => (
+
+            // article : 하나의 독립적인 콘텐츠 묶음, 영화 카드 목록 하나
+            <article key={movie.id} className="movie-card">


React에서 key가 필요한 이유가 무엇일까요? 사실 이 프로젝트에서 key를 당장 제거한다 하더라도 눈에 띄는 차이점이 보이지 않는걸요. key가 없어도 아무 문제도 발생하지 않는다면 사실 없어도 되지 않을까요? 🤔

React의 key로 movie.id를 제시해주셨는데, 이 값은 key로 사용하기에 적합한 값이라고 생각하시나요?

의천님이 주신 의견처럼 key가 없어도 아무 문제 없다고 생각하고, 지난 과제를 할 때 이걸 렌더링해서 브라우저의 콘솔을 봤는데 React에서 key를 지정하라고 경고문을 출력하더라구요.

그 계기로 이유를 찾아봤었는데, key가 없어도 화면 렌더링에서는 문제가 없을 수 있지만 리스트 추가, 삭제, 변경될 때 React가 어떤 항목이 변경되었는지 정확히 판단하기 어려워질 수 있기 때문에, map()으로 렌더링하는 요소에는 key를 넣는 것이 적절하다는 것을 알았어요.

그리고 현재 사용한 movie.id는 TMDB API에서 제공하는 영화별 고유 id 값이기 때문에, 각 영화 카드를 구분하는 key로 사용하기에 적절하다고 판단했습니다!

네, 이 부분이 핵심이라 생각합니다

React가 어떤 항목이 변경되었는지 정확히 판단하기 어려워질 수 있기 때문에

말그대로 React가 리스트에서 어떤 항목이 바뀌었는지 추적하기 위한 식별자 라고 생각합니다. 리스트가 바뀌어 리렌더링이 되더라도, 이 식별자 역할을 하는 key를 올바르게 이용한다면, React는 기존과 동일한 식별자를 지닌 요소를 인식하고 마운팅을 다시 해야 하는 등의 비싼 작업을 생략할 수 있고, 항목이 정말로 새롭게 생성된 것인지 아니면 이동만 한 것인지도 명확하게 알 수 있게 됩니다.

그리고,

key가 없어도 화면 렌더링에서는 문제가 없을 수 있지만

놀랍게도 실제로 버그가 생길 수 있습니다.
key값을 제대로 제공하지 않거나 잘못된 값을 제공하는 경우 최적화 면에서 문제가 생긴다는 점은 잘 알려져 있는데, 정말로 버그가 발생할 수 있다는 건 은근 블로그들에도 안 적혀 있는 경우가 많더라고요.

React의 key 값은 요소를 식별하는 식별자라고 이야기했었습니다. 그 식별자가 다른 요소에 잘못 붙는다면 어떻게 될까요? React는 실제로는 아예 다른 요소를 예전의 그 항목이라 착각하고 원래 조작해야 했던 항목 대신 그 항목을 조작하는 문제가 생길 수 있습니다. 눈에 보이는 버그는 이 시점에서 생길 수 있어요.

저도 이게 궁금해서 한때 삽질을 좀 해 보기도 했습니다.

최적화 면에서 문제가 생기는가: 동료가 대신 적었던 블로그 글 을 보여드려요, 이 때 요소를 막 5만 개씩 만들어보고 별 짓거리를 다 했었네요 😵

버그가 실제로 발생할 수 있는가: 제가 index를 키 값으로 사용할 때 잘못된 UI 변화가 생길 수 있는 상황을 코멘트로 정리 했는데, 이걸 공유해드릴게요

wzrabbit · 2026-06-01T11:33:08Z

    "eslint-plugin-react-refresh": "^0.5.2",
    "globals": "^17.6.0",
    "vite": "^8.0.12"
  }


이건 맞고 틀리고를 따지려는 게 아니라, package.json도 한번 관심을 가지셨으면 해서 적어보는 질문이에요, 둘 다 의존성인데 굳이 나뉘어 있는 게 신기하지 않으세요? 합치면 안 되나 싶기도 하고요 🙂
얘네 둘은 각각 어떤 의미이고 왜 나눠져 있을까요?

package.json에서 의존성이 dependencies와 devDependencies로 나누어지는 이유는 패키지가 사용되는 역할이 다르기 때문이라고 알고 있습니다!

dependencies는 앱이 실제로 실행될 때 필요한 패키지이고, devDependencies는 개발 과정에서만 필요한 패키지인데, 이를 구분하기 위해 두 영역으로 나눴다고 생각합니다!!

wzrabbit

수고하셨습니다 👍🏻

wzrabbit · 2026-06-09T14:42:10Z

네~ 이런 초안 좋네요 👍🏻
앞으로도 자연어로 된 문서도 필요 시 지금처럼 추가해 보시면 좋을 것 같습니다!

코드를 읽게 될 사람은 물론이고 AI에게도 더 빠르게 맥락을 찾는 데 도움을 줄 거라 생각해요
특히 README.md만큼 훌륭한 이정표는 없다고 생각하거든요

wzrabbit · 2026-06-09T14:47:16Z

@@ -0,0 +1,23 @@
+import axios from "axios";


Vue에서 경험이 있으셨군요! 지금은 익숙한 도구를 자유롭게 골라주셔도 될 것 같습니다. 언제 공식 문서 한 번 보시는 것도 좋을 것 같아요. 할 수 있는 목록이 쫘라락 나오고, fetch와 비교되는 특징이나 장점이 보일 수도 있습니다.

말씀해주신 대로 axios를 사용해 주실 때에는 fetch와 다른 동작들이 여럿 있는데, 그 중 하나가 axios는 4xx/5xx번대 response status를 명시적으로 reject해준다는 것에 있어요

이 동작 차이는 axios를 좋아하는 개발자들은 장점으로 보기도 하고, 장단점이 아닌 특징 차이 정도로 생각하시는 개발자분들도 계시는 등 의견은 좀 갈리는 영역인 것 같아요

wzrabbit · 2026-06-09T14:53:21Z

+  headers: {
+
+    // Authorization은 인증 정보를 담는 것, 인증 방식이 Bearer
+    Authorization: `Bearer ${import.meta.env.VITE_TMDB_ACCESS_TOKEN}`,
+  },
+
+  // 한국어로 응답값 받아오기 위한 설정
+  params: {
+    language: "ko-KR",
+  },


headers는 메타데이터/인증 정보, params(쿼리 파라미터)는 필터링/조회 조건. 깔끔하네요 👍🏻

wzrabbit · 2026-06-09T14:58:44Z

네, 접근성 이야기를 좀 꺼내보고 싶었고, 잘 알아내 주신 것 같습니다
저 언어 설정 하나로 스크린 리더가 읽어주는 단어의 뉘앙스와 방식이 완전히 달라집니다.

아래 자료 추천해봅니다.

[10분 테코톡] 해온, 첵스의 웹접근성 & 웹표준

특히, 5:07 부터 들으시면 스크린 리더가 어떤 방식으로 사용자에게 정보를 전달하는지 직접 들어보실 수 있습니다

wzrabbit · 2026-06-09T15:09:18Z

+          {movies.map((movie) => (
+
+            // article : 하나의 독립적인 콘텐츠 묶음, 영화 카드 목록 하나
+            <article key={movie.id} className="movie-card">


네, 이 부분이 핵심이라 생각합니다

React가 어떤 항목이 변경되었는지 정확히 판단하기 어려워질 수 있기 때문에

말그대로 React가 리스트에서 어떤 항목이 바뀌었는지 추적하기 위한 식별자 라고 생각합니다. 리스트가 바뀌어 리렌더링이 되더라도, 이 식별자 역할을 하는 key를 올바르게 이용한다면, React는 기존과 동일한 식별자를 지닌 요소를 인식하고 마운팅을 다시 해야 하는 등의 비싼 작업을 생략할 수 있고, 항목이 정말로 새롭게 생성된 것인지 아니면 이동만 한 것인지도 명확하게 알 수 있게 됩니다.

그리고,

key가 없어도 화면 렌더링에서는 문제가 없을 수 있지만

놀랍게도 실제로 버그가 생길 수 있습니다.
key값을 제대로 제공하지 않거나 잘못된 값을 제공하는 경우 최적화 면에서 문제가 생긴다는 점은 잘 알려져 있는데, 정말로 버그가 발생할 수 있다는 건 은근 블로그들에도 안 적혀 있는 경우가 많더라고요.

React의 key 값은 요소를 식별하는 식별자라고 이야기했었습니다. 그 식별자가 다른 요소에 잘못 붙는다면 어떻게 될까요? React는 실제로는 아예 다른 요소를 예전의 그 항목이라 착각하고 원래 조작해야 했던 항목 대신 그 항목을 조작하는 문제가 생길 수 있습니다. 눈에 보이는 버그는 이 시점에서 생길 수 있어요.

저도 이게 궁금해서 한때 삽질을 좀 해 보기도 했습니다.

최적화 면에서 문제가 생기는가: 동료가 대신 적었던 블로그 글 을 보여드려요, 이 때 요소를 막 5만 개씩 만들어보고 별 짓거리를 다 했었네요 😵

버그가 실제로 발생할 수 있는가: 제가 index를 키 값으로 사용할 때 잘못된 UI 변화가 생길 수 있는 상황을 코멘트로 정리 했는데, 이걸 공유해드릴게요

wzrabbit · 2026-06-09T15:16:31Z

분리해야 하는 조건이 꼭 라인 수는 아니겠죠, 화면이 한 페이지로 구성되어 있다, 상태 또한 이해하기에 감당 가능한 영역에 있다 -- 말씀하신 대로 꼭 당장 분리하지는 않아도 되는 신호라고도 충분히 생각해요.

대신 이 부분에 대해서는 다른 방법으로 분리하는 방법도 충분히 있을 것 같습니다

특히 데이터 호출 부분은 본 컴포넌트가 갖고 있는 게 맞다고 생각하는데, 이유는 본 컴포넌트의 화면에서 데이터 호출이 별로 없고, 데이터를 다른 컴포넌트에서 호출해 가져오면 데이터 관리면에서 복잡해져 힘들다고 생각하기 때문이에요.

말씀하신 대로 데이터가 매우 복잡하지 않은 상황인데 굳이 데이터를 파편화하려 한다면 오히려 관리가 복잡할 수 있다는 점에 동의합니다. 이 경우에는 데이터를 분리하지 않으면서 다른 로직들을 떼어내는 수법을 많이 쓰기도 하는 것 같아요.

반복되는 요소나 분리 가능한 요소를 찾아 분리하여 컴포넌트로 만들기. 데이터는 여전히 부모가 가진 채로 화면을 담당하는 친구들만 빼내니 데이터 면에서 혼란이 없습니다.

커스텀 훅으로 빼 보기. 반복되는 로직이나 분리하고 싶은 로직이 있는데 이 로직이 React 상태를 품고 있어서 단순 도메인 함수로 빼기 어려울 때가 있습니다. 이 때에 써먹기 좋은 친구가 바로 커스텀 훅입니다. 심지어 컴포넌트를 하나만 쓰고 재사용도 하지 않더라도, 상태를 다루는 부분과 UI를 다루는 부분을 분리하여 운용할 때 빛을 발하기도 합니다.

종합적으로 분리는 네, 여기서는 말씀하신 대로 유지해도 되어 보입니다. 대신 꼭 데이터를 분리해야만 분리할 수 있는 것은 아니니 방법 자체는 더 고민해보셔도 좋을 것 같습니다 💪🏻

ohsanghy09 added 4 commits May 23, 2026 21:26

feat: TMDB API 통신 환경 설정 및 테스트 코드 추가

403205f

feat : 인기 영화 페이지 가져오기 구현

cdb1863

feat : 키워드 영화 검색 기능 구현

5c0cfed

feat : console.log 제거

76a34fc

ohsanghy09 self-assigned this May 29, 2026

feat : StrictMode 추가

85cc902

dohun0310 requested a review from wzrabbit May 30, 2026 06:56

wzrabbit requested changes Jun 1, 2026

View reviewed changes

ohsanghy09 added 4 commits June 5, 2026 13:09

feat : 다크모드 CSS 적용

d2f15b4

feat : 검색 영화 유무 처리 추가

282991d

feat : .env.example 파일 생성 및 README.md에 내용 반영

5276f1c

feat : html lang=ko 변경

7fc61a5

wzrabbit self-requested a review June 7, 2026 09:07

wzrabbit approved these changes Jun 9, 2026

View reviewed changes

wzrabbit merged commit 12bfec3 into ohsanghy09 Jun 9, 2026

Conversation

ohsanghy09 commented May 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

과제명

💡 작업 내용

🔗 참고 링크

🤔 느낀 점 / 어려웠던 점

📤 제출 방법

📝 기타 사항

Uh oh!

wzrabbit left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

1️⃣ 미사용 코드 제거

2️⃣ 예외처리에 대해

3️⃣ .env의 작성 방법을 동료에게 알려주는 방법과 유출에 대해

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ohsanghy09 Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ohsanghy09 Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wzrabbit left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

ohsanghy09 commented May 29, 2026 •

edited

Loading

wzrabbit left a comment •

edited

Loading

3️⃣ `.env`의 작성 방법을 동료에게 알려주는 방법과 유출에 대해

ohsanghy09 Jun 5, 2026 •

edited

Loading

ohsanghy09 Jun 5, 2026 •

edited

Loading