동적 데이터셋 테이블, 어디까지 만들어봤니행/열/값을 사용자가 마음대로 끌어다 놓으면 알아서 피벗되고, 소계·합계·총계까지 끼워 넣는 테이블을 React로 만들면서 정리한 기록.1. 들어가며 — 단순해 보였던 요구사항"엑셀 피벗 같은 거 화면에서 보여주면 돼요."처음 받은 한 줄. 가볍게 시작했는데, 막상 펴 보니 정적 테이블과는 완전히 다른 영역이었다. 사용자는 같은 데이터셋을 가지고 어떨 땐 단순 목록으로 보고 싶고, 어떨 땐 부서×월로 묶어서 보고, 또 어떨 땐 거기에 소계와 총계까지 끼워서 보고 싶어 한다. 그리고 모든 모드가 같은 컴포넌트에서 매끄럽게 전환돼야 한다.이 글은 그 요구사항을 풀면서 만든 컴포넌트와 useCreateTableV2 훅의 설계·구현을 정리한 회고다. 일부 헬퍼는 재귀가..

LLM 이 뭘하고 있는지 사용자는 궁금해한다챗봇 기반 문서편집 AI 서비스를 개발하다 보면 LLM이 문서 및 자료를 분석하고, 사고 과정(thinking)을 거치고, 편집 명령을 생성하고, 최종 메시지를 작성하기까지 평균 10~30초가 걸린다. 그때 사용자가 원하는 건 단순한 로딩바가 아닌 "지금 AI가 뭘 하고 있는지" 아는 것이였다. 문서를 검색하는 중인지, 생각하는 중인지, 편집을 시작했는지. 그 과정이 실시간으로 보여야 했다.폴링 vs WebSocket vs SSE 비교폴링(Polling): 가장 단순하지만, LLM 응답의 특성과 맞지 않았다. 토큰 단위로 생성되는 텍스트를 0.5초마다 긁어오면 불필요한 요청이 대량 발생하고, 실시간 느낌도 살릴 수 없다.WebSocket: 양방향 통신이 가능하다..

AI 코딩의 역설요즘 개발 현장에서 AI 코딩 도구를 안 쓰는 곳을 찾기 어렵다. GitHub Copilot, Claude, ChatGPT 등 AI에게 "이런 기능 만들어줘"라고 말하면 순식간에 코드가 완성된다.그러다보니 예전에는 개발 공수 때문에 신중하게 결정했던 것들이 이제는 "일단 만들어보고 바꾸죠"가 되어버렸다.결과는? 기획 변경이 잦아지고, UI/UX 수정이 늘어나고, 스펙이 수시로 바뀐다.빠른 변경이 가능해진 건 좋다. 하지만 빠른 변경 ≠ 안전한 변경이다. AI가 아무리 빨리 코드를 짜줘도, 그 코드가 기존 기능을 망가뜨리지 않았는지는 인간이 확인해야 한다.여기서 TDD의 새로운 가치가 드러난다.SDD(Spec-Driven Development)란?SDD는 Spec-Driven Develop..

// ProductDetail.jsxconst handleAddToCart = async (product) => { await cartAPI.add(product); eventBus.emit('cart:item-added', { product, timestamp: Date.now() });};// CartIcon.jsxuseEffect(() => { const handleItemAdded = ({ product }) => { showToast(`${product.name} 담김!`); // 또는 refetch cart count }; eventBus.on('cart:item-added', handleItemAdded); return () => eventBus.off('cart:i..

프론트엔드 프로젝트가 일정 규모를 넘기 시작하면, 기능보다 먼저 문제가 되는 것은 상태(state)다. UI 버그, 불필요한 리렌더링, 어디서 바뀌는지 알 수 없는 값들. 대부분 “상태를 어디서, 어떻게 관리할지”에 대한 기준 부재에서 시작된다 이 글에서는 실제로 자주 마주치는 문제 상황을 기준으로어떤 상태를 로컬로 두고, 언제 전역으로 끌어올리며, Context와 Recoil은 어디서 갈라지는지, URLSearchParams 은 언제 사용하면 좋은지를 단계적으로 정리한다.문제 상황 1: “분명 값은 바뀌었는데 UI가 안 바뀐다”증상API 응답은 정상콘솔 로그에는 최신 값그런데 화면은 이전 상태 그대로원인 분석React는 상태 변화 → 리렌더링이라는 단순한 규칙 위에서 동작한다. 문제는 다음 중 하나다...

1. electron-builder 설치 npm i -D electron-builder yarn add -D electron-builder 2. package.json 에 build config 추가 { ....., "main": "dist/main.js", // webpack 후 main 의 경로를 적어준다 "homepage": "./", "build": { "appId": "{your-app-id}", // 앱 아이디를 적어준다 exe 파일의 이름이 됨 "productName": "{your-app-name}", //설치 되고 나서 표시되는 앱의 이름 // 아웃풋 디렉토리를 설정해주지 않으면 dist 폴더로 지정된다. //나같은 경우 webpack을 돌리면 dist 폴더가 생기기 때문에 따로 분리해줌..

1. DeadLock 이란 1) DeadLock 은 각자의 프로세스가 자원을 점유하고 있으면서 다른 프로세스가 점유한 자원을 기다리며 block 된 교착 상태를 말한다. 2) Resource(자원) 하드웨어, 소프트웨어 등을 포함하는 개념 ex) I/O device, CPU cycle, memory space, semaphore 등 프로세스가 자원을 사용하는 절차 Request(요청) → Allocate(할당) → Use(사용) → Release(방출) ※ Resource-Allocation Gragh (자원 할당 그래프) - 프로세스와 자원의 요청 및 할당 관계를 표시한 그래프다 => 순환 대기 조건을 발견하기 위한 목적으로 사용한다 2. DeadLock 의 발생 조건(=이유) 1. Mutual Exc..

1. Race Condition 과 Critical Section 이란 Race Condition = 경쟁 상태 - 두 개 이상의 프로세스가 공용 자원을 병행적으로 읽거나 쓰는 작업을 하는 상태 -> 공통 데이터에 대한 접근이 어떤 순서에 따라 이루어졌는지에 따라 그 실행 결과가 달라진다 Critical Section = Race Condition 이 발생할 수 있는 부분 - 프로그래밍 코드 상에서 공유 데이터를 접근하는 부분을 뜻한다. 여기에서 문제점들이 발생함. -> 이 영역에 한번에 한 프로세스만 들어올 수 있도록 해야함 = 동기화의 필요성 => 모든 프로세스가 읽을 수 있는 공유 변수(Synchronization variable)를 놓고 알고리즘을 설계하기 시작 **프로세스는 크게 4가지 구역으로..