번역일: 2026-06-22 KST
오늘 선별 기준:
선별 글:
Persona.js는 React, Vue, Svelte 같은 특정 프레임워크에 묶이지 않고 웹 페이지에 agent UI를 붙이기 위한 Vanilla JS 라이브러리다. 핵심 메시지는 단순하다. 이미 운영 중인 사이트, CMS, 이커머스, 레거시 프론트엔드에 AI assistant 기능을 넣으려면 새 React 앱을 통째로 끼워 넣는 방식이 과할 수 있고, 이때 작은 JS 위젯이 더 현실적인 선택지가 될 수 있다는 것이다.
라이브러리는 npm 패키지나 script tag로 설치할 수 있고, SSE 기반 backend와 연결된다. OpenAI Agents, Vercel AI SDK, LangGraph.js, Hono, Express, SvelteKit 같은 예제도 제공한다. 즉 프론트엔드 위젯은 가볍게 유지하고, 서버 쪽은 팀이 이미 쓰는 agent stack에 맞춰 붙이는 구조다.
실무적으로 눈에 띄는 부분은 Shadow DOM 격리다. 외부 사이트에 삽입되는 채팅 UI는 기존 CSS와 쉽게 충돌한다. Persona는 Shadow DOM과 prefix된 CSS를 사용해 host page의 스타일이 widget 안으로 새거나, widget 스타일이 페이지 전체를 오염시키는 문제를 줄인다. 브랜드에 맞춘 테마 토큰도 제공하므로, 단순 iframe보다 통합감 있는 UI를 만들 수 있다.
또 하나의 중요한 방향은 WebMCP 지원이다. 페이지가 search, cart, booking, form 같은 기능을 document.modelContext tool로 노출하면 agent UI가 이를 발견하고, 사용자 승인 후 호출할 수 있다. 프론트엔드 관점에서는 "챗봇이 별도 API를 새로 들고 있는 구조"보다 "페이지가 이미 가진 기능을 agent가 또 다른 입력 방식으로 쓰는 구조"에 가깝다.
오늘 읽을 포인트는 agent UI를 제품에 붙이는 방식이 점점 widget, page tool, approval UX, streaming transport 조합으로 표준화되고 있다는 점이다. AI 기능을 넣는다는 이유만으로 앱 구조 전체를 바꾸기보다, 기존 화면이 가진 action을 명확히 노출하고 작은 UI layer를 붙이는 접근이 더 실용적일 수 있다.
Pure Effect는 JavaScript와 TypeScript용 작은 effect library다. 문제의식은 비즈니스 로직과 I/O가 섞이면 테스트와 장애 재현이 어려워진다는 것이다. 예를 들어 registerUser 안에서 곧바로 await db.findUser(email)을 호출하면, 로직을 검증하려면 실제 I/O, mock, fake, container 중 하나가 필요하다. 프로덕션에서 실패해도 "어떤 I/O가 어떤 순서로 호출됐는지"를 재생하기 어렵다.
Pure Effect의 접근은 함수가 I/O를 바로 실행하지 않고, 실행하고 싶은 I/O를 plain object로 반환하게 만드는 것이다. 로직은 Success, Failure, Command, Ask, Retry, Parallel 같은 작은 primitive로 구성된 tree를 반환하고, 실제 실행은 system boundary의 interpreter가 맡는다. 테스트에서는 tree를 읽어 "이 입력이면 cmdFindUser를 호출하려 한다"처럼 구조를 검증할 수 있다.
이 방식의 장점은 테스트뿐 아니라 운영 디버깅에도 있다. production run에서 각 command의 결과를 기록해두면, 로컬에서 같은 tree에 기록된 결과를 다시 주입해 같은 경로를 밟을 수 있다. DB나 외부 API를 붙이지 않고도 실패 경로를 재현하는 셈이다.
Retry도 data로 표현된다. Retry(effect, { attempts: 3, delay: 200, backoff: 2 }) 같은 설정은 실행 전에도 검사할 수 있으므로, timer를 실제로 기다리는 flaky test를 줄일 수 있다. Ask는 request id, tenant, config 같은 context를 로직 signature 곳곳에 전달하지 않고 interpreter context에서 읽게 해준다.
프론트엔드 실무에서는 form submit, checkout, onboarding, 권한 변경처럼 side effect가 많은 flow에서 생각해볼 만하다. 모든 팀이 effect system을 도입할 필요는 없지만, "비즈니스 결정을 내리는 코드"와 "그 결정을 실제 I/O로 실행하는 코드"를 분리하면 테스트와 observability가 좋아진다는 메시지는 그대로 유효하다.
이 글은 Linear가 빠르게 느껴지는 이유를 기술적으로 해부한다. 핵심은 "UI 반응성을 network latency에 묶지 않는다"는 원칙이다. 일반적인 CRUD 앱은 사용자가 클릭하면 브라우저가 HTTP 요청을 보내고, 서버가 DB를 조회하고, 응답이 온 뒤 UI를 갱신한다. 이 과정은 수백 ms의 spinner나 skeleton을 만든다.
Linear는 UI가 읽는 주 데이터베이스를 브라우저 안에 둔다. IndexedDB와 in-memory observable graph가 먼저 갱신되고, server sync는 뒤에서 비동기로 처리된다. 사용자가 issue title을 바꾸면 화면은 즉시 바뀌고, 저장 transaction은 queue에 들어간다. 서버는 delta를 받고 다른 client로 broadcast한다. 사용자가 느끼는 속도는 서버 응답 시간이 아니라 로컬 상태 갱신 시간에 가까워진다.
글은 Linear가 React, TypeScript, MobX, Postgres, CDN 같은 비교적 익숙한 stack을 쓴다고 설명한다. 중요한 것은 최신 framework buzzword가 아니라 sync engine과 local-first 사고방식이다. "빠른 앱"은 edge database나 RSC 같은 단일 기술로 만들어지는 것이 아니라, 처음부터 network wait를 사용자 흐름에서 제거하도록 설계해야 한다는 주장이다.
모든 서비스가 Linear 수준의 custom sync engine을 만들 필요는 없다. 하지만 TanStack Query나 SWR의 optimistic update만 제대로 써도 많은 웹앱은 훨씬 빠르게 느껴진다. 사용자가 수정한 값은 즉시 local cache에 반영하고, 서버 검증은 background에서 처리하며, 실패할 때만 rollback한다.
실무 적용 포인트는 명확하다. spinner를 예쁘게 만드는 데 시간을 쓰기 전에, 그 spinner가 필요한지부터 줄여야 한다. mutation 성공 가능성이 높고 rollback 전략이 명확한 곳은 optimistic update를 기본값으로 검토할 가치가 있다.
이 글은 웹 페이지의 animation과 audio를 함께 녹화하려다 Screen Capture API를 사용하게 된 과정을 설명한다. 출발점은 Lego 사이트의 age picker animation이었다. 정적인 screenshot으로는 부족했고, QuickTime screen recording은 소리를 담지 못했다.
두 번째 시도는 Playwright video recording이었다. Playwright는 browser context에 record_video_dir를 설정하면 테스트 중 화면을 영상으로 저장할 수 있다. 실패한 테스트를 영상으로 남기는 데 유용하지만, 글쓴이가 원한 tab audio recording에는 맞지 않았다. 또 고해상도 화면에서 1x pixel density로 녹화되어 결과가 흐릿해지는 문제도 있었다.
세 번째 선택지가 browser의 Screen Capture API다. navigator.mediaDevices.getDisplayMedia()를 호출하면 tab, window, screen 중 하나를 MediaStream으로 받을 수 있다. 옵션으로 video displaySurface를 browser로 제한하고, audio: true를 지정하면 현재 tab의 소리까지 포함할 수 있다.
그 다음은 MediaRecorder API로 stream을 받아 Blob으로 모으고, 녹화 종료 후 파일로 다운로드하면 된다. 이 조합은 production feature로 쓰기엔 browser support와 permission UX를 세심하게 봐야 하지만, 내부 도구, QA evidence, bug reproduction, product demo capture에는 꽤 강력하다.
프론트엔드 팀에 중요한 포인트는 브라우저가 이미 많은 media workflow를 처리할 수 있다는 점이다. "화면 녹화는 native app이나 외부 도구가 필요하다"는 가정이 항상 맞지 않다. 단, 사용자의 명시적 허가, 녹화 대상 제한, audio 포함 여부, browser compatibility는 반드시 제품 요구사항으로 다뤄야 한다.
GeekNews에 오늘 재소개된 이 글은 Zoom의 localhost web server 취약점을 통해 CORS 오해가 어떤 보안 문제를 만드는지 설명한다. Zoom은 사용자의 컴퓨터에 localhost:19421 서버를 띄우고, 웹사이트에서 이 로컬 서버와 통신해 native Zoom 앱을 실행했다.
문제는 구현 방식이었다. 일반 AJAX 요청이 아니라 image load와 image size를 이용해 상태 코드를 전달하는 식으로 CORS를 우회했다. 이는 "localhost는 CORS가 적용되지 않는다"는 식의 오해와 연결되기 쉽지만, Chrome은 localhost server의 CORS header도 존중한다. Create React App frontend와 backend API가 서로 다른 localhost port에 있을 때도 교차 출처 요청은 정상적으로 CORS 규칙을 따른다.
더 안전한 설계는 localhost server가 REST API를 제공하고 Access-Control-Allow-Origin을 zoom.us로 제한하는 것이다. 그러면 zoom.us에서 실행되는 JavaScript만 로컬 서버에 접근할 수 있다. 반대로 CORS를 우회하면 인터넷의 임의 웹사이트가 사용자의 로컬 권한을 가진 서버를 건드릴 수 있다.
프론트엔드 실무에서 중요한 교훈은 "동작하게 만들기"와 "브라우저 보안 모델 안에서 동작하게 만들기"가 다르다는 점이다. CORS error를 없애려고 Access-Control-Allow-Origin: *를 붙이거나, image/script tag 같은 우회로를 쓰는 순간 보안 경계가 흐려질 수 있다.
특히 Electron, native bridge, localhost helper, browser extension, desktop companion app을 붙이는 제품은 이 글을 다시 읽을 가치가 있다. 로컬에서만 떠 있는 서버라도 웹 페이지에서 접근 가능하다면 인터넷 전체를 threat model에 넣어야 한다.
오늘 GeekNews에 다시 올라온 Sandi Metz의 고전 글이다. 핵심 문장은 "잘못된 추상화보다 중복이 훨씬 싸다"이다. 처음에는 중복 제거가 합리적으로 보인다. 비슷한 코드 두세 곳을 보고 method나 class로 뽑아내면 코드가 깨끗해진 것처럼 느껴진다.
문제는 요구사항이 조금씩 달라질 때 생긴다. 새 요구사항은 기존 추상화와 거의 맞지만 완전히 같지는 않다. 그래서 parameter가 하나 추가되고, 조건문이 들어가고, 호출부별 예외가 생긴다. 시간이 지나면 원래 단순했던 공통 함수는 여러 개념을 동시에 떠안은 절차 코드가 된다.
이때 흔한 실수는 기존 추상화를 지키려고 계속 더 많은 option과 branch를 추가하는 것이다. 이미 들인 노력이 아까워서 코드를 버리지 못하는 매몰비용 오류도 작동한다. 하지만 글의 조언은 반대다. 추상화가 잘못됐다는 신호가 보이면, 그 코드를 호출부로 다시 inline하고 중복을 의도적으로 되돌려야 한다.
inline 후에는 각 호출부에서 실제로 필요한 코드만 남긴다. 그러면 "겉으로는 같은 추상화를 쓰는 것처럼 보였지만 실제로는 요구사항이 꽤 달랐다"는 사실이 드러난다. 이전 추상화를 제거한 뒤에야 현재 요구사항에 맞는 새 공통점을 다시 관찰할 수 있다.
프론트엔드 코드베이스에서는 공용 component, form helper, table abstraction, API client wrapper에서 특히 자주 보이는 문제다. prop이 계속 늘고 boolean flag가 여러 개 붙는다면, 그것은 유연한 component가 아니라 잘못된 추상화일 가능성이 있다. 그럴 때는 과감히 복제를 허용하고 다시 관찰하는 편이 더 빠를 수 있다.