웹 개발 공부에서 남은 연결고리
JavaScript의 변수와 타입부터 Next.js, React Native, Electron, 데이터 변환 성능까지 흩어진 기술 메모를 개념의 연결 중심으로 정리했습니다.
- 작성일
- 업데이트일
이 글은 2016년부터 2024년까지 작성한 웹 개발 메모를 다시 엮은 기록입니다. 오래된 프레임워크 사용법을 최신 튜토리얼처럼 제시하지 않고, 시간이 지나도 연결해서 볼 만한 개념과 문제 해결 과정을 중심으로 남깁니다.
변수 선언에서 시작한 언어 이해
처음 let과 const를 공부할 때 눈에 들어온 차이는 블록 스코프였습니다. 함수 단위로 동작하는 var와 달리 두 선언은 블록 안에서 범위를 만들고, 선언 전에 접근하면 temporal dead zone 때문에 오류가 납니다.
const는 값 전체를 얼리는 키워드가 아니라 같은 변수에 다시 할당하지 못하게 하는 선언입니다. 객체 내부를 불변으로 만들고 싶다면 별도의 설계가 필요해요. 당시 글에는 브라우저 지원 여부가 큰 관심사였지만, 지금 남길 핵심은 지원표보다 범위와 변경 가능성을 의도에 맞게 표현하는 일입니다.
정적 타입과 동적 타입을 나누는 질문
타입을 언제 확인하는가를 기준으로 보면 차이가 선명해집니다.
| 관점 | 정적 타입 | 동적 타입 |
|---|---|---|
| 주된 확인 시점 | 실행 전 분석 단계 | 실행 중 |
| 장점 | 일부 오류를 더 일찍 발견하고 도구가 추론하기 쉬움 | 빠르게 형태를 바꾸며 실험하기 쉬움 |
| 주의점 | 타입 모델을 설계하고 유지해야 함 | 입력 경계와 테스트가 약하면 오류가 늦게 드러남 |
어느 쪽이 절대적으로 낫다는 결론보다, 데이터가 들어오고 나가는 경계에서 무엇을 검증할지 정하는 것이 중요했습니다. 컴파일 방식과 타입 체계를 같은 개념으로 섞지 않는 것도 이때 다시 확인했어요.
HTML은 모양보다 의미를 남긴다
예전에는 처음 보는 태그를 목록으로 모았습니다. 다시 정리하면 del은 삭제된 내용, blockquote는 긴 인용, cite는 창작물 제목이나 출처를 나타냅니다. 태그 이름을 많이 외우는 것보다 문서에서 그 내용이 맡는 역할을 먼저 묻는 편이 좋습니다.
시맨틱한 제목 구조와 언어 속성, 이미지 대체 텍스트, 메타데이터는 검색엔진만을 위한 장식이 아닙니다. 키보드와 보조 기술을 포함해 서로 다른 독자가 문서의 구조를 이해하게 만드는 기반입니다.
Next.js 학습에서 본 렌더링의 선택
2020년 Next.js 학습 메모는 정적 생성, 서버 렌더링, 데이터 가져오기와 동적 경로에 집중했습니다. 당시 API 이름과 디렉터리 규칙은 지금과 다를 수 있지만 선택의 질문은 남아 있습니다.
- 모든 방문자에게 같은 결과를 미리 만들 수 있는가?
- 요청마다 달라지는 정보가 있는가?
- 경로 목록을 빌드 시점에 알 수 있는가?
- 데이터가 바뀌었을 때 어느 시점에 다시 생성해야 하는가?
라우팅이나 viewport 문제를 만났을 때도 먼저 프레임워크의 현재 렌더링 단계와 메타데이터 처리 방식을 확인해야 합니다. 2024년 메모에는 클라이언트 효과로 viewport 값을 바꾼 임시 해결이 적혀 있었지만, 재사용할 해결책으로 남기기보다 “문서 head와 클라이언트 DOM 변경을 섞기 전에 공식 메타데이터 경로를 확인한다”는 진단 원칙만 보존합니다.
같은 시기의 모바일 채팅 화면에서는 키보드가 열릴 때 전체 높이와 입력창 여백이 흔들렸습니다. 이 문제는 문서의 viewport 메타데이터와 별개로, 레이아웃 viewport와 visualViewport가 키보드에 반응하는 차이를 관찰해야 합니다. iOS·Android 브라우저, 포커스 이동과 안전 영역을 함께 테스트해야 한다는 조사 단서까지 통합했습니다.
React의 모델을 다른 플랫폼으로 옮길 때
React Native를 처음 볼 때는 React 경험이 그대로 모바일 개발 경험이 되는지 궁금했습니다. 컴포넌트와 상태를 다루는 사고방식은 이어지지만, DOM이 없고 내비게이션·입력·권한·레이아웃·배포 환경이 달라집니다. Electron도 웹 기술을 데스크톱에서 사용하지만, 브라우저 화면과 운영체제 권한을 같은 층으로 취급하면 안 됩니다.
| 플랫폼 | 익숙하게 가져갈 것 | 새로 배울 경계 |
|---|---|---|
| 웹 | 컴포넌트, 상태, 브라우저 API | 접근성, 네트워크, 렌더링 방식 |
| React Native | React의 컴포넌트 모델 | 네이티브 UI, 권한, 기기별 동작 |
| Electron | HTML·CSS·JavaScript UI | main/renderer 분리, preload와 IPC, 서명·패키징 |
Electron 발표 메모에서 가장 중요한 내용은 프로세스 경계였습니다. renderer는 화면을 그리는 웹 환경에 가깝고, main은 창과 애플리케이션 수명 주기처럼 운영체제에 가까운 일을 맡습니다. 둘 사이에는 필요한 기능만 제한적으로 노출하는 통로가 필요합니다.
큰 JSON의 키 변환에서 배운 것
서버의 snake_case와 클라이언트의 camelCase를 맞추려고 응답 전체를 재귀 순회했더니, 큰 JSON에서 변환 비용이 눈에 띄었습니다. 캐시도 시도했지만 병목이 전체 순회라면 키 이름을 캐시하는 것만으로는 해결되지 않았어요.
당시에는 Object.defineProperty의 getter를 이용해 접근할 때 하위 객체를 변환하는 지연 방식도 실험했습니다. 아이디어는 흥미로웠지만 숨은 getter, 열거 가능성, 직렬화, 디버깅, 속성 기술자 규칙 같은 복잡성이 생깁니다. 지금 다시 남기는 해결 순서는 다음과 같습니다.
- 실제 프로파일로 변환이 병목인지 확인합니다.
- 서버와 클라이언트가 이름 규칙을 통일할 수 있는지 먼저 협의합니다.
- 필요한 필드만 경계에서 명시적으로 매핑합니다.
- 범용 변환이 꼭 필요하면 데이터 크기와 중첩 깊이를 기준으로 벤치마크합니다.
- 지연 접근을 택하면 열거·복사·직렬화 동작을 테스트로 고정합니다.
최적화는 기발한 코드보다 비용이 발생하는 위치를 정확히 찾는 데서 시작한다는 점이 가장 오래 남았습니다.
퍼블리싱 채널은 목적부터 확인한다
2021년에는 Facebook Instant Articles 적용 방법을 알아보다 제목과 목차만 남기고 중단했습니다. 특정 플랫폼에 글을 맞춰 배포하는 기능은 도입 절차보다 먼저 확인할 것이 있습니다.
- 원문과 복제본 중 어느 주소를 기준 문서로 삼을지
- 플랫폼이 지원하는 마크업과 분석 기능의 범위
- 정책이나 서비스가 바뀌었을 때 콘텐츠를 회수할 수 있는지
- 추가 채널이 실제 독자에게 닿는지 확인할 지표
내용 없이 설치 절차만 남은 옛 글은 튜토리얼로 유지하지 않았습니다. 대신 배포 채널을 늘리기 전에 소유권, 중복 콘텐츠와 유지 비용을 확인한다는 기준으로 통합했습니다.
여러 기술을 관통한 기준
새 기술을 배울 때 API 목록부터 외우기보다 경계를 찾는 편이 도움이 됐습니다. 변수의 범위, 타입을 확인하는 시점, 렌더링 시점, 웹과 운영체제의 권한, 서버와 클라이언트의 데이터 형식처럼요. 경계가 보이면 어떤 책임을 어디에 둘지 질문할 수 있고, 오래된 기술 메모도 지금의 문제에 연결할 수 있습니다.
이어 읽기
- 《You Don’t Know JS》 스터디를 마치며 — 타입, 스코프, 객체와 성능을 언어 수준에서 더 깊게 살펴봅니다.
- 함수형 프로그래밍을 이해하기 위한 첫 질문 — 이벤트와 상태를 예측 가능한 데이터 흐름으로 다루는 관점으로 이어집니다.
- 프론트엔드 멘토링 진행 노트 — 이 글의 HTML·CSS·Git·접근성 기준을 입문 학습 흐름으로 다시 구성했습니다.