개발자들이 남긴 기록..

1. API 캐시 문제와 크롬 캐시 설정 이슈

동일한 코드와 API 요청인데도, PC마다 크롬 브라우저가 디스크 캐시 사용 여부가 다름.
상황: React의 useEffect에서 페이지 진입 시 API 호출 발생.
F5 새로고침 시엔 모두 API 호출이 발생하지만, React Router를 통한 페이지 이동 시 캐시를 사용하는 경우와 재호출 하는 경우가 PC별로 다름.
크롬 개발자 도구 네트워크 탭의 "Disable cache" 옵션이 양 PC 모두 비활성화 상태지만 결과가 다름.
크롬 캐시 설정은 겉으로 동일하지만 내부 설정이나 이전 사용 기록(재설치 후에도 영향 가능성)이 다를 수 있음.
캐시 제어 헤더 설정이 코드는 없으며, CORS 문제 해결 때문에 코드로 직접 캐시 조작은 피하려고 함.
초보자를 위한 설명:
- 브라우저 캐시는 API 응답을 저장해서 불필요한 네트워크 요청을 줄이는 기능임.
- 크롬은 내부적으로 응답을 저장하는 캐시 정책이 다소 복잡하며, 네트워크 상태, 요청 헤더, 브라우저 설정, 이전 캐시 기록 등이 영향을 줄 수 있음.
- 개발시 캐시 문제를 디버깅하려면 크롬 개발자 도구에서 캐시 비활성화 옵션을 켜고, 관련 HTTP 헤더(Cache-Control, ETag 등)를 주의 깊게 확인하는 것이 좋음.

코드 A) let data = await response.json() as MyAPIData
코드 B) let data: MyAPIData = await response.json();
의견:
- 타입 단언(as MyAPIData)은 기존 값의 타입을 강제로 지정하는 것으로, 실제 데이터와 타입이 다르더라도 오류를 막아버릴 수 있어 주의 필요.
- 타입 선언(let data: MyAPIData)은 변수가 해당 타입을 가지도록 명시하면서 타입 체크 단계에서 오류를 발견하기 쉬움.
초보자 팁:
- 타입 단언은 실제 데이터 구조가 확실할 때만 제한적으로 쓸 것.
- 타입 선언으로 먼저 타입을 설계하고, 데이터 검증을 철저히 하면서 사용하는 것이 좋음.

주로 사용하는 스타일링 방법:
- styled-components (CSS-in-JS 라이브러리)
- tailwindcss (유틸리티 퍼스트 CSS 프레임워크)
- module.css (CSS 모듈로 클래스명 충돌 방지)
- vanilla-extract (타입스크립트 기반 CSS-in-JS)
- SCSS (Sass 전처리기)
의견 교환:
- styled-components는 태그 이름이 지저분해지는 단점이 있지만 여전히 많이 사용됨.
- tailwindcss는 점점 인기가 많아지고 있으며, 프로젝트마다 SCSS와 병행 사용하기도 함.
- bootstrap은 전통적이지만 클래스가 많고, 기본 태그 스타일까지 침범한다는 이유로 비선호하는 사람이 많음.
초보개발자에게:
- 프로젝트 성격에 맞게 스타일링 방법을 선택하되, tailwindcss와 styled-components가 현재 트렌드임.
- CSS 모듈은 비교적 가볍고 쉽게 적용 가능해 입문자에게 적합함.

백엔드에서 500 내부 서버 에러가 발생하는 문제를 겪음.
초보자들이 많이 마주치는 에러 중 하나로, 데이터가 DB에 정상적으로 들어가도 서버에서 에러가 발생하는 경우가 있어 원인 분석과 디버깅이 필요함.
초보개발자에게:
- 로그와 서버 응답 메시지를 꼼꼼히 확인하고, API 요청과 DB 상태를 차근차근 점검하는 습관이 중요함.

Next.js 13 버전에서 page 디렉터리와 동적 라우팅을 사용 중 404 에러 경험.
원인은 rewrites 설정 문제였으며, 라우팅 관련 설정이 분산돼 있어 관리가 어려움.
Next.js는 라우트 설정이 폴더 구조와 여러 설정 파일에 나눠져 있어 초보자에게 복잡함.
팁:
- 라우팅 설정을 체계적으로 문서화하며 관리하면 디버깅이 쉬워짐.
- Next.js 13의 새로운 기능과 기존 방식을 혼용할 땐 주의가 필요.