본문 바로가기

전체 글232

[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.
[실시간 통신] 1. WebSocket, STOMP, Polling을 먼저 이해해보자 채팅 만들려면 소켓 써야 한다고? 근데 폴링으로도 되던데? 프로젝트에서 채팅을 구현할 때 "WebSocket이랑 STOMP 써야 해"라고 해서 썼다. 근데 소켓이 자꾸 끊기고, 됐다 안 됐다 하고, STOMP가 뭔 역할을 하는지도 잘 모르겠고, 오히려 불안정한 서비스가 됐다. 지금은 회사에서 기존 서비스에 채팅을 추가하는 작업을 하고 있는데, 웹뷰 환경이라 보수적으로 가야 해서 폴링으로 하고 있다. 안정적이다. 잘 된다. 근데 "이게 맞나? 소켓 써야 하는 거 아냐?" 하는 고민이 계속 있다. 이 시리즈는 그 고민을 정리하면서 쓴다. 먼저 이번 글에서는 각 기술이 정확히 뭔지부터 제대로 짚고 간다. 이걸 명확히 알아야 "뭘 써야 하는가"를 판단할 수 있다.📝 자료조사만 AI를 사용하였으며, 본인의 이해.. 2026. 4. 7.
[Browser] 메인 스레드 점유 최소화 — 내 앱이 버벅인다면 알아야 한다 "코드가 맞는데 왜 버벅이지?" 대부분 메인 스레드 문제다. 프론트 개발을 하다 보면 "로직은 맞는데 화면이 끊긴다", "스크롤이 뚝뚝 끊긴다", "입력이 씹힌다" 같은 현상을 만난다. React 최적화도 했고, 리렌더링도 줄였는데 여전히 느리다. 이때 의심해야 하는 게 메인 스레드 점유다. useRef 글에서 리렌더링 비용을 다뤘고, Web Worker 글에서 메인 스레드가 싱글 스레드라는 걸 다뤘는데, 이번에는 메인 스레드를 점유하는 작업들이 뭔지, 어떻게 최소화하는지를 구체적으로 정리해본다. 📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다. 메인 스레드가 하는 일브라우저의 메인 스레드는 하나다. 이 하나의 스레드가 다음을 전부 처리한다.[메인 스레드가 하는 일].. 2026. 4. 6.
[Monorepo] 모노레포 반년 후기 — 좋다는데 나는 왜 이렇게 힘들었을까 공용 컴포넌트 만들어놓고 결국 안 쓰게 되는 그 현상, 나만 겪은 건가? 모노레포(Monorepo)가 요즘 트렌드라고 한다. 여러 프로젝트를 하나의 저장소에서 관리하면 코드 공유도 쉽고, 배포도 편하고, 일관성도 유지된다고 당시 팀장님 강요가 있어서 써봤다. 결론부터 말하면 생각보다 힘들었다. 특히 서비스 페이지 + 관리자 페이지를 모노레포로 관리하는 구조에서 시행착오가 많았다. 공용 컴포넌트를 만들어놓고 막상 잘 안 쓰게 되고, 디자인 시스템 구축은 번거롭고, 공용화 과정은 시간이 오래 걸리고. "이거 그냥 레포 따로 파는 게 낫지 않나?" 싶은 순간이 여러 번 왔다. 그래서 모노레포가 뭔지, 언제 좋고 언제 별로인지, 삽질하면서 느낀 것들을 정리해본다.📝 자료조사만 AI를 사용하였으며, 본인의 이해.. 2026. 4. 5.
[Redis] 프로젝트마다 "이거 Redis 써야 해?" 고민이 된다면 읽어보세용 캐싱하면 Redis, 세션이면 Redis, 실시간이면 Redis. 근데 진짜 다 Redis가 맞는 건가?프로젝트를 하다 보면 Redis가 계속 등장한다. 이전에 프로젝트에서도 Auth Service에서 JWT Refresh Token 저장, 세션 관리에 Redis를 썼다. 예전에는 "백엔드가 Redis 쓴다니까 쓰는 거겠지" 했는데, 점점 "이거 왜 DB 안 쓰고 Redis를 쓰는 거야?", "이건 Redis가 맞아? localStorage로 하면 안 돼?" 같은 의문이 생겼다.그래서 Redis가 뭔지, 언제 쓰는 게 맞고 언제 안 써도 되는지, 쓸 때 뭘 주의해야 하는지 정리해봤다.📝 자료조사만 AI를 사용하였으며, 본인의 이해를 위해 글은 직접 작성하였습니다.Redis가 뭔데한 줄로: 메모리에 데이.. 2026. 4. 4.

티스토리툴바