본문 바로가기
반응형

전체 글237

아무도 누르지 않는 화면은 전체화면이 될 수 없다 아무도 누르지 않는 화면은 전체화면이 될 수 없다 requestFullscreen()을 불렀다. 아무 일도 일어나지 않았다. 에러도 없었다. 요구사항은 한 문장이었다.전원을 켜면 안내 화면이 전체화면으로 떠 있을 것. 매장 구석에 놓인 미니 PC였고, 옆에 사람이 없었다. 누가 브라우저를 열어주지도, F11을 눌러주지도 않는다. 전원만 들어오면 알아서 되어야 했다. 웹으로 만든 화면이었으니 당연히 JS로 처리하려 했다. 그게 첫 실수였다.📝 자료조사와 글정리만 AI를 사용하였으며, 본인의 이해를 위해 초안은 경험 기반으로 직접 작성하였습니다.왜 전체화면이 안 되는가useEffect(() => { document.documentElement.requestFullscreen(); // 아무 일도 안 일.. 2026. 8. 28.
CDN을 쓸 수 없는 웹앱 — 무인 단말에서 깨진 전제들 CDN을 쓸 수 없는 웹앱 — 무인 단말에서 깨진 전제들부팅 직후 화면에 "연결에 실패했습니다"가 떴다. 그런데 그건 실패가 아니라 정상이었다. 웹 개발을 하면서 의심해본 적 없는 전제가 몇 개 있다.인터넷은 된다CDN은 살아 있다페이지가 열렸다는 건 네트워크가 붙었다는 뜻이다평소엔 다 맞는 말이다. 그런데 매장 구석에 놓인 미니 PC에서 전원을 켜면 자동으로 뜨는 전체화면 안내 패널을 만들면서 이 셋이 전부 깨졌다. 아무도 옆에 없고, 아무도 새로고침을 눌러주지 않는 환경이었다. 이 글은 그 과정에서 무엇을 잘못 가정했고 어떻게 고쳤는지에 대한 기록이다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.환경 — 무엇이 다른가일반 웹앱무인 단말사용자가 브라우저를 연다전원을.. 2026. 8. 27.
[TypeScript] ② 타입을 믿을 수 없을 때 — 구조적 타이핑의 구멍과 런타임 검증 string이면 다 같은 string인가? 그리고 as User는 대체 뭘 보장하는가?이전 편 — ① 왜 쓰는 건지, 컴파일러와 tsconfig 제대로 이해하기 ①에서 두 가지를 던져놓고 넘어갔다.TypeScript의 타입은 컴파일 후 전부 사라진다 (타입 이레이저)TypeScript는 이름이 아니라 구조로 타입을 비교한다 (구조적 타이핑)각각은 그냥 특성이다. 그런데 이 둘이 겹치는 지점에서 실무 버그가 나온다. 타입 검사는 통과했는데 런타임에서 터지는 코드, 그게 이번 편의 주제다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.문제 1. string은 너무 많은 걸 의미한다실제로 이렇게 터진다function transfer(fromAccountId: string, .. 2026. 8. 26.
카카오톡 인앱브라우저에서 이미지 저장이 안 되는 이유 — blob URL과 WebView 다운로드 위임 "몇 년째 잘 되던 이미지 저장이 갑자기 안 된대요"코드는 그대로인데 버그 리포트가 올라왔다. 그럼 바뀐 건 코드가 아니라 환경이다.레거시로 굴러가던 화면이 하나 있었다. 화면을 이미지로 캡처해서 저장하는, 어디에나 있는 그 기능이다. html2canvas로 DOM을 캔버스에 그리고, 로 내려받는다. 수년째 아무 문제 없었다.그러다 저장이 안 된다는 제보가 들어왔다. 재현을 시도했는데 내 크롬에서는 멀쩡히 저장된다. 제보자 환경을 물어보니 카카오톡에서 링크를 열었다고 했다.여기서부터가 이 글이다. 결론부터 말하면 blob: URL과 WebView의 다운로드 위임 구조 문제였고, "인앱브라우저에서는 download 속성이 무시된다"는 흔한 설명은 절반만 맞는 말이었다.📝 자료조사에만 AI를 사용했으며, .. 2026. 8. 25.
[TypeScript] ① 왜 쓰는 건지, 컴파일러와 tsconfig 제대로 이해하기 "타입 쓰면 코드가 길어지잖아. 왜 써야 하는 건데?" 에 대한 진짜 답. TypeScript를 처음 접했을 때는 "JavaScript에 타입만 붙인 거 아냐?"였다. : string 붙이고, interface 만들고, 빨간 줄 나오면 as any 때리고. 그게 TypeScript인 줄 알았다. 근데 실무에서 코드베이스가 커지면서 "타입이 없었으면 이거 어떻게 유지보수했을까" 싶은 순간이 계속 왔다. 리팩토링할 때 타입 에러가 가이드 역할을 하고, API 응답 타입을 정의하면 프론트-백 계약이 되고, 에디터 자동완성이 문서 역할을 한다. 📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.TypeScript는 왜 만들어졌는가JavaScript의 태생적 문제JavaScript.. 2026. 4. 23.
[Framework] 꼭 리액트여야 할까? — 프레임워크 선택에 대한 솔직한 정리 "리액트 말고 뷰는? 스벨트는? SSR 안 쓰는데 Next.js 써도 돼? 넥스트 네스트 넉스트 너무 많은데 뭐가 뭔지 모르겠어." 이 질문을 주변에서 정말 많이 받는다. 부트캠프 수강생, 주니어 개발자, 심지어 경력자도 "이대로 리액트만 계속 해도 되는 건가?" 고민을 한다. 그리고 이런 질문도 온다. "백엔드 부트캠프에서는 왜 Vue를 가르치고, 프론트 부트캠프에서는 왜 React를 가르쳐?", "한국에서 React가 Java 같은 포지션인 건가?", "Vue의 양방향 바인딩이 편하던데 React는 왜 안 해?... 아 이제 된다고?" 이런 고민들에 대한 솔직한 정리를 해본다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.먼저 이름 정리 — 넥스트 네스트 넉스트가 .. 2026. 4. 22.
[PackageManager] npm, pnpm, yarn, Yarn Berry 뭘 써야 하는 건지 "나는 npm 쓰는데 팀원은 yarn이래. 다른 사람은 pnpm이 좋다고 해. 뭘 써야 해?" 패키지 매니저가 너무 많다. npm, yarn, pnpm, Yarn Berry(yarn 2+). 프로젝트마다 다르고, 팀마다 다르고, 유행도 바뀐다. 2~3년 전에는 yarn이 대세였다가 지금은 pnpm이 뜨고 있고, Yarn Berry를 쓰는 곳도 있다. "그냥 npm 쓰면 안 돼?" 싶기도 하고, "pnpm이 좋다던데?" 싶기도 하다. 근데 뭐가 어떻게 다른 건지, 왜 이렇게 많은 건지, 어떤 걸 쓰는 게 맞는지를 제대로 정리해본 적이 없어서 이번에 한번 파봤다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.패키지 매니저가 뭘 하는 건데한 줄로: 외부 라이브러리를 설치하고.. 2026. 4. 21.
[CSS] 잘 쓰는 법 — 선택지가 너무 많은데 뭘 써야 하는 건지 CSS가 제일 쉬운 줄 알았다. 근데 제일 등한시하고, 제일 난장판이 되기 쉬운 것도 CSS다. 프론트 개발에서 CSS는 "누구나 할 수 있지만, 잘하는 사람은 드문" 영역이다. JavaScript는 에러가 나면 콘솔에 빨갛게 뜨니까 수정하게 되는데, CSS는 "좀 이상하게 보이는데... 일단 넘어가자"가 되기 쉽다. 그리고 선택지가 너무 많다. 순수 CSS, SCSS, CSS Modules, Tailwind, styled-components, Emotion, CSS-in-JS, MUI, Panda CSS, Vanilla Extract... 프로젝트 시작할 때마다 "뭘 쓰지?"가 고민이다. 이 글에서는 각 선택지가 뭐가 다른지, 요즘 추세는 어떤지, 그리고 어떤 걸 쓰든 통하는 CSS를 잘 쓰는 팁들을 .. 2026. 4. 20.
[Claude Code] 잘 쓰는 법 — 세팅부터 에이전트까지 실무에서 쓰는 패턴 그냥 "이거 만들어줘" 하면 50점짜리가 나온다. 세팅을 잡으면 90점이 나온다. Claude Code를 처음 쓸 때는 터미널에서 claude치고 프롬프트만 잘 쓰면 되는 줄 알았다. 근데 써보니까 CLAUDE.md 세팅, Hooks, 커스텀 커맨드, 에이전트 같은 것들을 잡아놓으면 결과물 퀄리티가 확 달라졌다.특히 에이전트 시스템은 게임 체인저다. 반복 작업을 자동화하고, 대규모 리팩토링을 병렬로 처리하고, 코드 리뷰를 전문 에이전트한테 맡길 수 있다.이 글에서는 실무에서 쓰면서 효과가 좋았던 세팅과 패턴들을 정리한다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.1. CLAUDE.md — 프로젝트의 "두뇌"프로젝트 루트에 CLAUDE.md를 두면 Claude가 매 .. 2026. 4. 19.
Node.js 시리즈 ③ — Node.js로 어디까지 할 수 있는가, Deno와 Bun의 도전 Node.js가 "서버도 JS로 만든다"였던 시절은 지났다. 이제는 거의 모든 곳에 있다. 1편에서 내부 동작 원리, 2편에서 버전별 변화와 Java 비교를 다뤘다.마지막 편에서는 Node.js의 활용 범위, 경쟁자(Deno, Bun)와의 비교, 실무 패턴을 다룬다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.Node.js로 할 수 있는 것들Node.js가 처음 나왔을 때는 "서버 사이드 JavaScript"가 핵심이었다. 지금은 범위가 훨씬 넓어졌다.1. 웹 서버 / API 서버가장 기본적인 용도.Express → 가장 많이 쓰이는 웹 프레임워크. 미니멀Fastify → 성능 중심. Express보다 빠름NestJS → TypeScript 기반 구.. 2026. 4. 18.
Node.js 시리즈 ② — 18, 20, 22 뭐가 다른지 + Java 생태계와 비교 Node 18 쓰다가 20으로 올리래서 올렸다. 뭐가 바뀐 건지는 모르겠다.1편에서 Node.js의 내부 동작 원리를 다뤘다. 이번에는 버전별로 뭐가 바뀌었는지, 그리고 Java 생태계와 어떻게 다른지를 정리한다.Node.js는 짝수 버전이 LTS(Long Term Support)다. 18, 20, 22가 LTS이고, 홀수(19, 21, 23)는 Current(최신 기능 먼저 탑재, 짧은 지원)다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.Node.js 릴리스 주기[릴리스 타임라인]Node.js 18: 2022년 4월 출시 → LTS 2022년 10월 → EOL 2025년 4월Node.js 20: 2023년 4월 출시 → LTS 2023년 10월 → EOL 2026.. 2026. 4. 17.
Node.js 시리즈 ① — 그냥 설치해서 쓰는 거 아니었어? 내부 동작 원리 npm install 하고 node index.js 치면 돌아간다. 근데 이게 어떻게 돌아가는 건지?프론트 개발자한테 Node.js는 "npm 쓰려면 설치하는 것", "로컬 서버 돌리는 것", "백엔드도 JavaScript로 할 수 있게 해주는 것" 정도였다. 설치하고 쓰면 되니까 원리를 깊게 파볼 생각이 없었다.근데 "왜 Node.js는 싱글 스레드인데 빠른 건지", "이벤트 루프가 뭔지", "V8 엔진이 뭔지" 같은 질문에 제대로 대답할 수 없었다. Web Worker 글에서 브라우저의 싱글 스레드를 다뤘는데, Node.js도 싱글 스레드라고 한다. 그러면 동시에 요청이 수천 개 오면 어떻게 처리하는 건지?이번 시리즈에서는 Node.js가 내부적으로 어떻게 동작하는지, 버전별로 뭐가 바뀌었는지, 어디.. 2026. 4. 16.
[Three.js] ④ GLB가 느린 이유와 경량화, 3D 성능 최적화 건물 GLB 파일이 50MB다. 로딩에 10초 걸린다. 이걸 어떻게 줄이는가. 3편까지 관제 시스템 구현 패턴을 다뤘다. 마지막 편은 성능이다. 3D 관제 시스템에서 가장 큰 병목은 GLB 파일 크기와 렌더링 성능이다. 건물 모델링 파일이 수십 MB이면 모바일에서 로딩하다가 메모리 부족으로 크래시가 나기도 한다. 렌더링할 오브젝트가 수천 개이면 프레임이 떨어진다.어떻게 경량화하고, 어떻게 렌더링 성능을 관리하는지 정리한다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.GLB 파일이 왜 큰가GLB 안에는 여러 종류의 데이터가 들어있다. 각각이 크기를 차지한다.[50MB GLB 파일의 구성 (예시)]텍스처 이미지: 35MB (70%) ← 가장 큰 비중메쉬 데이터: .. 2026. 4. 15.
[Three.js] ③ 관제 시스템 만들기: 모델 로딩부터 실시간 연동까지 GLB 파일 로딩하고, 층별 가시화하고, POI 배치하고, API에 맞춰 움직이게 하는 실제 작업. 1편에서 기본 개념, 2편에서 R3F와 생태계를 다뤘다. 이번에는 실제 관제 시스템을 만드는 패턴을 정리한다.3D 모델링 파일(GLB)을 로드하고, hierarchy를 탐색해서 층별로 분리하고, 그 위에 POI를 배치하고, Path를 그려서 장비가 이동하는 애니메이션을 만들고, 기계 관제 API 응답에 따라 실시간으로 상태를 반영하는 작업들이다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.GLB/GLTF 파일 로딩GLTF 포맷이 뭔데GLTF(GL Transmission Format) 는 3D 모델의 "JPEG"이라고 불린다. 웹에서 3D 모델을 전달하기 위한 표준 포맷.. 2026. 4. 14.
[Three.js] ② React Three Fiber와 생태계, 자체 엔진에서 왜 넘어갔는가 회사에서 WebGL 엔진을 쓰다가 React Three Fiber로 전환했다. 뭐가 달라졌는지 정리한다. 1편에서 WebGL과 Three.js의 기본 개념을 다뤘다. 이번에는 Three.js를 둘러싼 생태계를 정리한다.회사에서는 처음에 Three.js 기반의 자체 WebGL 엔진을 만들어서 쓰고 있었다. 근데 점점 React Three Fiber(R3F)로 전환하게 됐는데, 그 이유와 차이점, 그리고 R3F 주변의 라이브러리들이 각각 뭘 하는지 정리해본다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.자체 엔진 vs 라이브러리자체 엔진이란Three.js를 직접 사용해서 렌더링 시스템, 씬 관리, 이벤트 처리, 카메라 컨트롤 등을 직접 구축한 것이다. Three.js의 .. 2026. 4. 13.
[Three.js] ① WebGL이 뭐고, Three.js는 왜 쓰는 건지 회사에서 3D 관제 시스템을 만들었다. 건물 모델링 위에 기계 상태를 실시간으로 띄우는 작업. Three.js를 처음 접한 건 회사에서였다. 3D 모델링 파일을 브라우저에 띄우고, 그 위에 POI(Point of Interest)를 배치하고, 층별로 가시화하고, 기계 관제 API 응답에 맞춰 3D 오브젝트가 움직이도록 만드는 작업이었다. 처음에는 WebGL 기반의 자체 엔진을 썼는데, 회사에서 WebGL 엔진은 점점 사양 산업으로 빠졌고 결국 React Three Fiber로 전환하게 됐다. 그 과정에서 WebGL, Three.js, React Three Fiber, 각종 라이브러리들의 관계가 궁금해졌고, 꽤 많이 배웠다. 이 시리즈에서는 그 경험을 바탕으로, 3D 웹 개발에 필요한 것들을 하나씩 정리해.. 2026. 4. 12.
[Kafka] 2. 도입 전에 고민해야 할 것들, 그리고 Kafka 없는 대안 Kafka가 좋은 건 알겠다. 근데 우리 프로젝트에서 진짜 필요한 건가? 1편에서 Kafka가 뭔지, 왜 필수처럼 됐는지, Redis Pub/Sub과의 차이를 다뤘다. 이번에는 좀 더 현실적인 얘기를 한다. 모든 프로젝트에서 Kafka를 쓰는 것 같지만, 사실 Kafka 없이도 잘 돌아가는 서비스가 더 많다. Kafka를 도입하면 해결되는 것도 있지만, 새로 생기는 복잡성도 있다. 이 트레이드오프를 따져봐야 한다. 그리고 프론트 개발자 입장에서 Kafka가 있으면 뭐가 달라지는지도 정리해본다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.Kafka 도입 시 새로 생기는 복잡성Kafka가 해결하는 문제는 1편에서 다뤘다. 근데 해결하면서 새로 생기는 문제도 있다.1. 운.. 2026. 4. 11.
[Kafka] 1. 카프카가 대체 뭘 하는 애인지, 왜 필수가 됐는지 톺아보자 요즘 백엔드 프로젝트 열면 Kafka가 거의 다 있다. 근데 이게 정확히 뭘 하는 건지? 백엔드 부트캠프에서 처음 Kafka를 접했을 때는 ZooKeeper도 같이 설치해야 했다. "메시지 큐"라고만 이해했고, "비동기 처리할 때 쓴다"는 정도였다. 최근에 진행한 프로젝트에서 서비스 간 비동기 통신에 Kafka를 썼는데, 이번에는 Kafka 자체를 깊게 파본다. 왜 모든 프로젝트에서 Kafka를 쓰는 것 같은지, Redis Pub/Sub이랑 뭐가 다른지, 최근에 ZooKeeper 없이 되는 건 뭔지, 서버 비용은 더 나가는 건지. 이런 고민들을 정리해본다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.Kafka가 뭔데한 줄로: 분산 이벤트 스트리밍 플랫폼. 좀 더 풀어.. 2026. 4. 10.
[실시간 통신] 3. 소켓을 쓰기로 했다면, 이렇게 해야 안 터진다 프로젝트에서 실패했던 원인을 하나씩 해결한다. 1편에서 각 기술이 뭔지 정리하고, 2편에서 왜 폴링을 선택했는지와 소켓 도입 판단 기준을 다뤘다. 이번 마지막 편에서는 소켓을 쓰기로 결정했을 때 어떻게 제대로 쓰는지를 다룬다. 프로젝트에서 소켓이 불안정했던 이유가 명확하다. 재연결 로직이 없었고, 하트비트가 없었고, 메시지 유실 처리가 없었고, 연결 상태 관리가 없었다. 소켓 자체가 문제가 아니라 소켓 주변을 안 챙긴 게 문제였다. 이번에는 그 "주변"을 전부 다룬다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.소켓 연결은 끊긴다 — 이걸 전제로 설계해야 한다WebSocket 연결이 안 끊길 거라고 가정하면 안 된다. 끊기는 게 정상이다.원인설명네트워크 변경WiFi .. 2026. 4. 9.
[실시간 통신] 2. 소켓으로 삽질한 이야기, 폴링으로 돌아간 이유 WebSocket + STOMP로 채팅을 만들었다. 불안정했다. 폴링으로 바꿨다. 안정적이다. 근데 이게 맞나? 1편에서 각 기술이 뭔지 정리했다. 이번에는 실제 경험 얘기다. 프로젝트에서 "채팅이면 당연히 소켓이지"라는 판단으로 WebSocket + STOMP를 도입했는데, 결과적으로 불안정한 서비스가 됐다. 지금 회사에서는 웹뷰 환경에서 기존 서비스에 채팅을 추가하는 작업을 하고 있는데, 보수적으로 폴링을 선택했다. 잘 된다. 그러면 폴링이 정답인가? 그것도 아닌 것 같다. 이 고민을 정리해본다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.프로젝트에서 WebSocket + STOMP로 겪은 문제들문제 1: 연결이 자꾸 끊겼다이게 가장 고통스러웠다. 소켓이 5분, .. 2026. 4. 8.
반응형

티스토리툴바