글 링크: https://tinyurl.com/3wavfhv6

소개

브라우저가 발전하면서, 예전에는 지원이 부족해 라이브러리에 맡겨야 했던 기능들이 이제 브라우저 엔진에 직접 탑재되어 있는데요.

이 글은 개발자들이 많이 쓰는 라이브러리를 브라우저 내장 기능으로 대체하는 방법을 다룹니다. 바꾸면 좋을 라이브러리와 실제 사례를 비슷한 것끼리 묶어서 소개하고, 교체할 때 주의할 점도 함께 짚어줍니다.

앞으로 AI가 발전할수록 이런 최적화는 더 중요해질 것 같습니다. 한번 읽어보시고 여러분의 프로젝트도 점검해보면 좋겠네요!

팀원들의 의견

개인적으로는 외부 종속성이 단순히 용량 문제뿐만 아니라, 최근 공급망 공격 사례가 늘어나면서 점점 더 내재화할 필요가 있지 않을까 하는 생각이 듭니다.

다만 한편으로는 굳이 바퀴를 다시 발명하는 것이 맞는지에 대한 고민도 있네요.

혹시 다른 분들도 회사나 팀에서 외부 종속성을 걷어내고 직접 내재화한 사례가 있으신가요?

내재화를 결정하셨다면 어떤 이유와 기준으로 판단하셨는지, 그리고 실제로 어떤 것들을 내재화하셨는지 궁금합니다.

💬. 의견 1

최근에 React나 Next.js 등 신뢰할 만한(?) 라이브러리&프레임워크에서도 보안 이슈가 발생했던 적이 있어서 저희도 팀 내에서 고민을 많이 하기는 했었는데요. 아직까지는 보안적인 목적으로 기존의 의존성을 걷어내고 내재화를 한 케이스는 없는 것 같습니다. 아직 제품이 크지 않아서 그런 것 같기도 하네요.

보안 이슈가 발견되면 버전 패치를 하는 등의 방식으로 대응하고, 신뢰할 만한 검증된 도구들을 쓰는 쪽으로 팀 내에서는 기조를 운영하고 있다고 생각합니다.

💬. 의견 2

저희 팀도 유지보수가 중단됐거나 아직 성숙하지 않은 라이브러리는 적절한 대안이 없다면 직접 구현해 사용하기도 합니다. 반면 충분히 검증된 라이브러리는 굳이 내재화하지 않고, minimumReleaseAge이나 주기적인 취약점 점검 등을 통해 관리하며 사용하고 있습니다.

다만 글에서 소개한 Widely available 기능처럼 브라우저가 안정적으로 지원하는 영역이 늘어나면서, 비교적 간단한 라이브러리는 웹 표준으로 대체하거나 내재화하는 방안도 충분히 고려해 볼 만하다고 느꼈습니다. 결국 팀의 리소스 상황에 따라 유지보수 비용과 기능 범위, 브라우저 지원 수준을 함께 고려하여 판단하는 것이 중요할 것 같습니다.

💬. 의견 3

저희 팀에서는 생태계가 크고 검증이 많이 되었다고 판단되거나, 생태계가 크기 때문에 문제가 발생했을 때 빠르게 패치되는 라이브러리는 외부에 맡겨 사용하는 편인것 같습니다. 특정 분야에 특화되어 있어 내부에서 같은 수준으로 구현하려면 많은 시간과 전문성이 필요한 라이브러리도 마찬가지고요.
반면 라이브러리를 사용하다가 실제로 필요한 기능이 일부에 불과하고, 그 정도라면 내부에서도 충분히 구현하고 유지할 수 있다고 판단되면 내재화를 고려하는 것 같습니다. 유지보수가 중단되었거나 라이브러리 규모에 비해 활용하는 기능이 적을 때도 내재화할 이유가 되는 것 같아요.
결국엔 외부 생태계에 유지보수를 맡겼을 때 얻는 이점과 직접 구현한 코드를 팀에서 계속 책임져야 하는 비용을 비교해서 결정하는 것 같습니다.

💬. 의견 4

아직 외부 종속성을 직접 내재화해본 경험은 없는 것 같습니다. 다만 이전에 Moment.js가 신규 개발이 중단되었고 번들 사이즈도 커서 다른 라이브러리로 교체했던 경험은 있습니다.
당시에도 이 기능을 꼭 외부 라이브러리에 의존해야 하는지, 직접 구현했을 때 유지보수 비용은 어떨지, 더 가벼운 대안은 없는지 등을 비슷하게 고민했던 것 같습니다.

💬. 의견 5

비슷하게, 저도 의존성을 완전히 제거하기보다 서비스 고유 정책을 공통 레이어로 감싸는 방향을 선호합니다. 특히 웹뷰와 앱 브리지처럼 실행 환경별 차이가 있는 경우, 인증/에러 처리/토큰 갱신 같은 규칙이 각 화면에 퍼지면 유지보수 비용이 커지더라고요.

다만 HTTP 요청이나 유틸리티를 전부 직접 구현하기보다는, 실제 사용하는 기능을 먼저 확인한 뒤 플랫폼 API로 충분한 부분만 치환하고 나머지는 라이브러리를 유지하는 식으로 판단했습니다. 글에서 말한 것처럼 fetch 전환도 인터셉터, 재시도, 업로드 진행률 등 기존 라이브러리 기능을 쓰는지 확인하는 과정이 핵심인 것 같습니다.

목차

• “베이스라인”이 실제로 뜻하는 것

• 무언가를 지우기 전에 필요한 판단 기준

• 묶음 1. 국제화

• 묶음 2. HTTP 클라이언트

• 묶음 3. UI 프리미티브

• 묶음 4. Lodash 유틸리티

• 묶음 5. Temporal

• 내 `package.json`으로 점검 돌리기

• 마무리하며

글 링크: https://handhand.tistory.com/entry/what-agent-native-means-for-the-whole-team

소개

개발자는 에이전트에게 저장소를 맡기고 버그를 고치게 할 수 있지만, 마케터나 PM은 같은 AI를 쓰고도 여전히 맥락을 일일이 챙기고 결과물을 손으로 옮겨야 합니다. 이 글은 그 차이가 사람의 활용 능력이 아니라, AI가 일할 수 있는 "공유된 워크플로우"가 있느냐 없느냐에서 온다고 말합니다. AI 에이전트를 도입했는데도 조직 간 업무 효율이 기대만큼 오르지 않아 고민이라면, 어디서부터 그 간극을 좁혀야 할지 힌트를 얻을 수 있는 글이라 소개합니다.

팀원들의 의견

결국 개발자 뿐만 아니라 조직 차원에서 AI-Native 하게 일하기 위해서는 공유할 수 있는 지식 저장소가 필요하다는 점을 시사한다고 볼 수 있는데요, 현재 팀 내에서 LLM Wiki 나 RAG 시스템을 구축해서 사용하고 계신지, 운용하면서 아쉬웠던 부분이나 좋았던 점은 무엇이 있을까요?

💬. 의견 1

현재 컨플루언스 위키와 코드베이스를 기반으로 한 RAG형 사내 지식 챗봇을 구축해 사용하고 있습니다. 주기적으로 최신 내용을 반영해야 하지만, n8n으로 업데이트 과정을 자동화해 큰 부담없이 운영하고 있습니다. 이를 통해 프런트엔드에서 백엔드 코드 변경과 관련된 내용을 미리 파악할 수 있고, 기획자도 새로운 기획의 영향도나 과거 기획 내용을 확인하는 데 유용하게 활용하고 있습니다. 다만 문서가 최신화되어 있지 않거나 내용이 충분하지 않으면 제대로 된 답변을 제공하기 어렵기 때문에, 문서 품질과 최신화 관리가 중요하다고 느꼈습니다.

💬. 의견 2

사내에서는 내부 문서와 Slack을 기반으로 한 RAG 챗봇을 구축해 사용하고 있고, 저희 파트에서도 코드 외부의 도메인 지식을 관리하기 위한 LLM Wiki를 구성해두었습니다.
파트에서 담당하는 업무의 범위가 넓다 보니, 다른 구성원이 주로 담당하던 영역을 제가 확인해야 하는 경우가 종종 있습니다. 이전에는 담당자에게 직접 물어보거나 Slack과 문서를 하나씩 찾아보며 맥락을 파악해야 했지만, LLM Wiki를 통해 관련 정책과 결정 배경, 변경 히스토리를 비교적 빠르게 확인할 수 있게 된 점이 좋았습니다.
아무래도 어려운 부분은 문서의 최신성을 관리하는 일이라고 생각합니다. 오래된 문서를 AI가 현재 정책처럼 참조할 수 있기 때문에, 담당자와 마지막 검토일, 원본 링크, 현재 적용 여부와 같은 정보가 함께 관리되어야 한다고 느꼈습니다. 일정 기간 검토되지 않은 문서는 stale 상태로 분류하고 답변에서 주의가 필요한 정보임을 표시하는 방식도 고민하고 있습니다. 결국 지식을 저장하는 것뿐만 아니라, 새로운 결정이 계속 반영되고 검토되는 흐름까지 갖춰져야 실질적인 유효한 워크플로가 될 수 있다고 생각합니다.

💬. 의견 3

저희 회사에서는 사내에서 LLM Wiki를 관리하고 있지는 않은데요. 사내 정책 때문에 메신저 기반의 내용을 LLM을 통해 수집해서 프로세스를 적용할 수 없는 환경에 처해있기도 합니다.
하지만 생각보다 수많은 사업과 정책을 개발하고 관리해야하는 부서 특성상 stale한 정보를 최대한 빠르게 인지하는 것이 중요하더라구요. 때문에 팀내에서 노션과 위키를 가져와 자동화하여 통합 검색 시스템을 아티팩트로 팀에서 공유하고 있습니다. 같은 팀이지만 서로 다른 서비스를 운영 및 기술을 사용하고 있어 검색 시스템을 통해서 사전 정보를 습득한뒤 논의하는 속도가 빨라지더군요. 이처럼 LLM을 사내 생산성을 위해 별도로 사용할 수 없는 환경에서는 LLM Wiki나 RAG 시스템을 별도로 구축하는게 어려운 회사에서는 최대한 사용할 수 있는 범위 내에서 적용해 볼 수도 있다고 생각합니다.

목차

• AI가 여전히 일거리처럼 느껴지는 이유

• 코드에는 이미 에이전트가 일할 자리가 있었습니다

• 앱이야말로 일이 벌어지는 곳입니다

  • 생성된 문구에서 실제로 동작하는 페이지로

• 팀은 배운 것을 계속 간직하게 됩니다

• 목표는 더 많은 손질이 아니라 더 적은 손질입니다

• 궤도를 벗어나지 않으면서 워크플로우를 바꾸기

• 업무가 계속 바뀌어도 오래가는 워크플로우 만들기

글 링크: https://imnotadevleoper.tistory.com/390

소개

AI가 코드를 작성하는 속도는 놀라울 정도로 빨라졌습니다. 그렇다면 AI는 소프트웨어 개발의 복잡성까지 해결해 줄 수 있을까요? 이 글은 프레드 브룩스(Fred Brooks)의 유명한 에세이 「No Silver Bullet」을 AI 시대의 관점에서 다시 살펴봅니다.

브룩스는 소프트웨어 개발의 어려움을 도구로 개선할 수 있는 우발적 복잡성(Accidental Complexity)과 문제 자체에서 비롯되는 본질적 복잡성(Essential Complexity)으로 구분했습니다. AI는 코드 작성이나 반복 작업처럼 우발적 복잡성을 크게 줄여주고 있지만, 무엇을 만들어야 하는지 결정하고 요구사항을 이해하며 적절한 설계를 선택하는 일까지 사라지지는 않습니다.

AI가 개발 방식을 빠르게 변화시키고 있는 지금, 소프트웨어 개발에서 정말 어려운 일은 무엇인지, 그리고 개발자의 역할은 앞으로 어떻게 달라질지를 생각해 볼 수 있는 글입니다.

팀원들의 의견

저자의 주장에 공감하시는지 궁금하고, AI 시대에서 일을 할 때 모든 것을 AI에 맡기지 않고 의식적으로 사람이 작업하는 영역을 두신 지점들이 있다면 무엇인지 궁금합니다!

💬. 의견 1

결국에는 AI를 잘 활용할 수 있는 설계자가 되어야 한다는 저자의 의견에 동의합니다. 같은 모델을 사용하더라도 누가, 어떻게 활용하느냐에 따라 결과물과 활용 방식이 달라지는 모습은 주변에서도 쉽게 볼 수 있는 것 같아요.

제가 의식적으로 사람의 영역으로 남겨두는 부분은 크게 세 가지 인것 같습니다. 문제를 구체화하는 일, AI가 작업하는 과정에서 제가 생각한 방향으로 가고 있는지 확인하는 일, 그리고 최종 결과물이 실제 문제를 해결하는 방향으로 잘 나왔는지 검증하고 해당 결과물의 개선을 반복하는 일입니다.

근데 AI 발전속도를 보면 이와같은 일도 AI가 하는게 더 나을 세상이 금방 올 수도 있을거같긴 하네요 ㅎㅎ

💬. 의견 2

잘 읽었습니다!

저 같은 경우에는 프로젝트의 전체 구조와 도메인 지식들, 공통 함수와 컴포넌트들을 초반에 직접 설계하는 것을 선호하는 편입니다. 프로젝트 특성 상 일정한 형태로 다수의 서비스가 배포되는 형태인 것들이 있어서 기반이 잘 만들어진 상태라면 새로운 서비스를 더 빠르게 시작하기 용이해서요.

저자의 의견처럼 모든 것을 AI에게 위임하는 것이 아니라 역할을 나눠서 사용하는게 좋을 것 같다고 생각합니다

💬. 의견 3

요즘 구현 자체는 AI agent에게 맡기는 경우가 대부분이다보니 확실히 설계자로서의 역할이 중요해진 것 같습니다.

제가 의식적으로 신경쓰는 부분은 기존 컨벤션이나 네이밍처럼, 팀이 오랫동안 쌓아온 맥락과 잘 이어지는지?인 것 같아요. 아직은 AI가 이런 방대한 컨텍스트를 종합적으로 파악하는 데는 한계가 있는 것 같아서, 아직 사람의 감각이 필요한 영역인 것 같습니다 ㅎㅎ

목차

• 본질과 부소적 요소

• 그는 1986년에 이미 AI도 검토했습니다

• 거울

• “코드는 결코 어려운 부분이 아니었습니다”

• 본질의 격차

• 프롬프터가 아니라 설계자를 키우세요

글 링크: https://tinyurl.com/yx5twwjy

소개

JSON.parse(JSON.stringify(value))를 객체를 복제할 때 사용하고 있나요? 큰 정수·undefined·Date·NaN·객체 순서·클래스 인스턴스가 직렬화 경계에서 조용히 변형되거나 사라지는 과정이 궁금하시진 않나요? 이 글에서는 파편화된 여러 JSON을 자바스크립트 환경에서 사용할 때 주의해야 하는 많은 내용을 한 번에 다루고 있습니다. 이 글을 통해 내가 알고 있었던 내용은 무엇이였는지, 새롭게 알게 된 내용은 무엇인지 한 번 정리해보시는건 어떤가요?

팀원들의 의견

파편화된 지식을 정리 하는데 큰 도움이 된 글이었는데요. 이 글을 읽으면서 새롭게 알게 된 부분이 있었나요? 아니면 글에서 다룬 내용 중에 예전에 실제로 문제를 겪어보신 적 있는 부분이 있었나요? 또는 이 글에는 없지만 여러분이 강조하고 싶은 내용이 있다면 자유롭게 남겨주시면 감사하겠습니다.

💬. 의견 1

절반쯤은 새롭게 알게 된 부분인 것 같네요. 실제로 문제를 겪어 본 적은 없고요. 이유는 이 글에서 말하는 스키마 라이브러리들을 넘 잘쓰고 있기도 했고, 그것들을 쓰면 이 글에서 말하는 '명시적인 표현 부여하기' 를 알아서(?) 적용해주었기 때문에... 그래도 글 덕분에 좀 더 자세히 이해할 수 있었습니다. 아무래도 다른 포맷인 만큼 조심해서 다뤄야겠단 생각이 드네요.

💬. 의견 2

직렬화 부분은 이전에 로깅 라이브러리를 만들면서 사용해 본 경험이 있어서 눈에 익은데, 그 외에 새롭게 알게 된 내용들이 많이 있네요! 특히 저자의 실전 규칙 가이드가 유용한 꿀팁이 많아서 실무에서 잘 활용하기 좋아 보이네요.

목차

• 이렇게 된 배경

• JSON이 보기도 전에 숫자는 이미 틀릴 수 있습니다

• undefined는 여러 가지를 의미할 수 있습니다

• 객체 순서는 경계를 넘기 전까지만 살아남습니다

• JSON은 타입을 지웁니다

• 직렬화는 코드를 실행합니다

• 여정을 떠날 수조차 없는 객체도 있습니다

• 파싱은 안전하지만, 그다음에 하는 일은 안전하지 않을 수 있습니다

• 리바이버가 타입을 자동으로 복원해주지는 않습니다

• JSON 경계를 위한 실전 규칙

• 마치며

글 링크: https://www.yeongseo-blog.site/blog/earning-taste-and-judgment

소개

이 글은 AI 에이전트가 반복적인 개발 작업을 대신하는 시대에, 주니어 개발자가 어떻게 취향과 판단력을 길러야 하는지를 이야기합니다.

과거에는 보일러플레이트 작성, 버그 수정, 문제 해결을 수없이 반복하면서 자연스럽게 경험과 판단력이 쌓였습니다. 하지만 AI가 이런 반복을 대신하면서 주니어 개발자가 시니어로 성장하던 기존의 경로도 달라지고 있습니다.

저자는 앞으로도 오래 가치를 지닐 능력은 정답이 있는 문제를 빠르게 푸는 기술이 아니라, 무엇을 만들지 선택하고 결과물이 좋은지 판단하며 마지막 완성도를 책임지는 능력이라고 말합니다.

이를 위해 AI가 만든 코드를 더 많이 읽고, 에이전트의 실수를 기록하며, 일부 작업은 의도적으로 직접 해볼 것을 권합니다. 또한 명세와 검증을 분리하고, 실패 비용에 따라 AI의 자율성을 조절하면서 자신만의 품질 기준을 만들어야 한다고 강조합니다.

팀원들의 의견

요즘 AI가 많은 작업을 대신해 주면서, 주니어 개발자인 저는 어떤 경험을 통해 성장해야 할지 고민이 많습니다. 여러분은 AI 덕분에 반복적인 작업에서 벗어나 더 중요한 문제에 집중하며 성장했다고 느낀 경험이 있으신가요? 그런 경험이 있다면 이야기를 들어보고 싶습니다!

💬. 의견 1

사실 글에 정말 공감을 많이 했는데요. 저 같은 경우는 주변 선배들의 이야기, 읽는 책, 그리고 직접 부딪힌 경험들을 통해 제 나름의 취향과 관점을 만들어 왔다고 생각합니다. 특히 어려운 일을 맡아서 그걸 해결하려고 끙끙대던 시간들, 그 안에서 항상 많이 성장했었습니다. 대부분 처음 고민해 보는 일들이었을 겁니다.

AI를 처음 활발하게 활용하던 시기는 어느 정도 업무가 익숙했던 시기였는데, “AI가 이걸 다 하는데 나는 대체되는 거 아닌가”, “지루하다” 같은 생각이 들었던 것 같습니다. 늘 하는 이야기가 있는데, AI 때문에 역치가 낮아진 것이지 본질이 달라진 건 아니라고 봅니다. 글에서도 공감했던 대목인데, AI에게 ‘내가 이미 아는 부분’만 위임하는 것에 그치면 안 된다는 점입니다.

연차가 쌓이고 최근 이직을 하면서 AI로 온보딩을 해봤는데, 예전 같으면 알아내기 힘들었던 부분들을 파악하는 속도가 확실히 빨라졌습니다. 도메인 관점의 맥락에도 훨씬 빠르게 접근할 수 있었고요.

제가 계속 발전하려면, 오히려 더 어렵고 더 도전적인 일로 시야를 넓히고, 그런 주제들을 AI와 깊이 파고들며 대화해 봐야 한다고 생각합니다. 그러면 이전보다 훨씬 빠르게 성장할 수 있을 거예요. AI가 진입 장벽을 낮춰준 만큼, 나를 일부러 더 어려운 환경에 두고 끊임없이 고민하고 읽으며 배우는 쪽으로 나를 밀어 넣어야 한다고 생각합니다. 그런 의미에서 지금은 배우기에 정말 좋은 시기라고 생각합니다.

💬. 의견 2
저는 AI가 코드를 작성하는 것 자체는 압도적인 속도로 해 주다 보니 만들려는 기능이 꼭 필요한지와 어떻게 만들 것인지에 대한 고민을 더 할 수 있게 된 것 같아요. 어떻게 만들 것인지에 대해서 잘 설계해 두면 그 방향으로 구현하는 것은 AI가 충분히 잘하다 보니 좋은 인터페이스에 대한 고민을 더 많이 할 수 있었던 것 같고, 이에 따라 자연스럽게 생각하는 힘을 기를 수 있는 시간이 많아져서 좋았어요.

목차

• 신입 일자리의 기반이 약해지고 있습니다

• 에이전트를 감독하는 일

• 취향과 판단력을 기르는 일곱 가지

• 에이전트를 만드는 사람들은 주니어에게 뭐라고 말할까요?

• 오래가는 가치는 어디에 몰릴까요?

글 링크 : https://velog.io/@sehyunny/rust-is-eating-js

소개

Webpack, Babel, Prettier, ESLint처럼 우리가 매일 사용하는 자바스크립트 개발 도구들이 어느 순간부터 Rust 기반으로 빠르게 바뀌고 있습니다.

이 글은 왜 자바스크립트 툴체인이 Rust로 이동하기 시작했는지, SWC부터 Turbopack, Rolldown, Oxc, Biome까지 그 흐름을 짚어봅니다. 특히 2021년에 작성된 글을 2026년에 다시 업데이트하면서, 당시의 예측이 실제로 어떻게 현실이 되었는지도 보여줍니다.

평소 당연하게 사용하던 프론트엔드 도구들이 왜 Rust로 이동하고 있는지, 그 배경과 흐름을 살펴보기에 좋은 글입니다.

팀원들의 의견

Q1. Rspack이나 Oxlint 같은 Rust 기반 도구를 실제로 써보신 적 있으신가요? 써보셨다면 기존 도구(webpack, ESLint 등)랑 비교했을 때 가장 크게 체감된 차이가 뭐였는지 궁금합니다!

💬. 의견 1

요즘은 번들러 자체가 워낙 잘돼있어서 Rust라서 특별히 이득 봤다는 느낌은 크지 않아요. 다만 초기 Turbopack이 Rust 기반 SWC 컴파일러를 내장하면서 확실히 덕을 본 케이스라고 봐요. 로우레벨 도구가 계속 늘어나는 걸 보면 생태계는 앞으로도 커질 것 같아서, 신규 프로젝트에는 Rspack이나 Oxlint를 적극 써보고 싶습니다.

💬. 의견 2

저희 회사에 최근 Oxlint가 도입돼서 써보고 있는데, 아직 며칠 안 돼서 속도 체감은 크게 못했어요. 오히려 저는 속도보다 기존 ESLint 규칙과 설정을 얼마나 안정적으로 대체할 수 있느냐가 더 궁금하더라고요. 아무리 빨라도 팀이 써온 방식이 흔들리면 오히려 비용이 커질 수 있으니, 호환성이랑 유지보수성을 좀 더 지켜보려고 합니다.

Q2. Rust 기반 도구들이 속도 면에서는 확실히 장점이 있는데, 반대로 플러그인 생태계가 아직 기존 도구만큼 성숙하지 않거나, 문제가 생겼을 때 Rust를 모르면 디버깅이 어려워지는 부분도 있을 것 같아요. 이런 트레이드오프에 대해 어떻게 생각하시나요?

💬. 의견 1

말씀하신 대로 플러그인 생태계가 아직 덜 성숙했다면 기존 도구를 완전히 대체하기는 어려울 것 같아요. 다만 빌드나 린트가 병목인 프로젝트라면 일부 기능부터 도입해볼 가치는 충분하다고 봅니다. 그리고 요즘은 AI를 잘 활용할 수 있는 환경이라, Rust를 직접 몰라도 디버깅이 예전만큼 어렵지는 않을 것 같아요.

💬. 의견 2

올해 Rust로 작업을 좀 해봤는데, 언어를 모르는 것 자체는 에이전트 도움으로 어느 정도 커버가 되더라고요. 오히려 힘들었던 건 언어가 아니라 JS만큼 디버깅 환경이나 플러그인, 참고할 만한 문제 해결 사례가 아직 충분하지 않다는 점이었어요. 그래서 저는 성능이 중요하고 자주 안 바뀌는 코어는 Rust로, 설정이나 플러그인처럼 사용자가 직접 만지는 부분은 JS로 열어두는 구조가 현실적인 절충안이 아닐까 싶습니다.

목차

• Rust란?

• 도입 현황

• 자바스크립트에서 Rust로

  • SWC

  • Deno

  • esbuild

  • Rome

  • NAPI

• Rust + WebAssembly

• Rust를 쓰지 말아야 할 이유

• 자바스크립트 툴링의 미래

• 업데이트: 2023년

• 업데이트: 2026년

글 링크: https://imnotadevleoper.tistory.com/389

소개

프런트엔드 애플리케이션이 복잡해질수록 상태 관리 역시 자연스럽게 어려워집니다. 새로운 상태 관리 라이브러리를 도입하는 것만으로 이러한 문제가 해결되지는 않습니다. 오히려 중요한 것은 어떤 상태를 어디에 두어야 하는지, 그리고 그 상태가 정말 전역으로 관리되어야 하는지를 판단하는 것입니다.

이 글은 특정 상태 관리 라이브러리의 사용법을 소개하기보다, 상태 관리 문제를 바라보는 관점과 원칙에 집중합니다. 애플리케이션의 상태를 어떻게 분류하고 소유권을 결정할 것인지, 상태를 필요한 곳 가까이에 두는 것이 왜 중요한지 등 우리가 익숙하게 사용해 온 상태 관리 방식에 대해 다시 생각해 볼 만한 질문들을 던집니다.

Redux, Zustand, React Query처럼 다양한 선택지가 존재하는 지금, 중요한 것은 어떤 도구가 가장 좋은지를 결정하는 것이 아니라 현재 다루고 있는 상태의 성격을 이해하고 그에 적합한 해결책을 선택하는 것입니다. 상태 관리에 대한 자신만의 기준을 한 번쯤 정리해 보고 싶은 프런트엔드 개발자라면 읽어볼 만한 글입니다.

팀원들의 의견

• 여러분은 React나 Zustand를 ‘상태 관리’ 도구라고 생각하시나요? 또, Redux, Zustand, React Query를 모두 ‘상태 관리 라이브러리’라고 부르는 것이 맞을까요?

• ‘상태 관리’와 ‘상태 전파’를 구분하는 저자의 주장에 공감하시나요?

💬. 의견 1

React 에서 기본적으로 상태를 관리할 수 있다는 점도 동의하는 부분이고, Tanstack Query, Zustand, Jotai 등의 라이브러리 에서도 ‘상태 관리’ 라는 관심사를 처리해준다는 점에서 충분히 상태 관리 도구라고 부를 수 있지 않나 싶습니다.

저자가 생각하는 상태 관리 라이브러리에 대한 기준이 일반적인 웹 애플리케이션에서 필요로하는 기준과는 거리가 좀 있다고 생각되어서.. PUB/SUB 패턴일 뿐이다 라고 하는건 개인적으로는 동의하기 어려운 부분이 있네요.

💬. 의견 2

저자가 말하고자 하는 바가 무엇인지는 알겠습니다. 전통적인 '상태 관리'의 개념을 흐리지 말고 제대로 이해해서 쓰자... 정도로 이해했는데요. UI 개발이건 뭐건 결국 프로그래밍이니 저자의 주장에는 어느정도 공감이 됩니다. 하지만 웹 프런트엔드 생태계에서 특히나 리액트가 주류인 현 상황에서 Redux, Zustand, React Query를 ‘상태 관리 라이브러리’라고 부르냐 아니냐가 얼마나 생산적인 논의일지에 대해서는 회의감이 드네요 ㅎㅎ

목차

• 그때, 지금, 그리고 앞으로

• 진지하게 바라보기

글 링크: https://emewjin.github.io/linear/

소개

웹 프런드엔드 개발자로서 사용자가 체감하는 속도를 최적화할 방안을 고민한 경험, 누구나 있으실 겁니다. 그런 점에서 Linear는 우수한 참고 사례가 될 수 있는 제품인데요, 이 글을 통해 어떻게 빠른 사용감을 구현할 수 있었는지 살펴보시는 건 어떨까요? 자체 동기화 엔진을 만들지 않더라도 현업에 적용할 수 있는 개선점과 아키텍처의 트레이드오프도 함께 살펴볼 수 있어 추천드립니다.

팀원들의 의견

Q. 프런트엔드 개발자라면 누구나 사용자에게 더 빨리 제품을 서빙하기 위해 노력할 테고 관심 많겠지요. 그런 측면에서 리니어의 사례는 배울 점도 많고, 부러운 점도 많은거 같아요 (특히 최신 브라우저만 지원하기로 한 결정같은 게요 ㅎㅎ) 여러분들의 경험중에도 특이했던 사례나 ‘이렇게까지 해봤다’하는 사례가 있었는지 궁금해요!

💬. 의견 1

대규모 목록 화면을 최적화하면서 비슷한 고민을 해본 적이 있습니다. 데이터를 미리 가져오고 캐시하며, 수정 결과를 UI에 먼저 반영하는 낙관적 업데이트를 적용했습니다. 목록 가상화와 상태 분리를 통해 값 하나가 변경될 때 전체 목록이 다시 렌더링되는 것도 줄였습니다.

가장 효과가 컸던 것은 복잡한 최적화보다 초기 화면에서 필요하지 않은 기능을 지연 로딩하고, 지원할 브라우저 범위를 줄인 일이었습니다. 다만 Linear처럼 IndexedDB와 동기화 엔진까지 구축하는 것은 유지보수 비용이 크기 때문에, 제품 특성에 따라 캐싱이나 프리페치 정도만 적용하는 것이 더 합리적일 수 있다고 생각합니다.

💬. 의견 2

Linear의 속도가 특정 기술 하나가 아니라, 로컬 퍼스트부터 번들 분할과 프리로드까지 작은 설계 결정들이 쌓인 결과라는 점이 인상적이었습니다. 비슷한 규모의 로컬 퍼스트 구조를 구현해본 경험은 없지만, 번들 최적화와 데이터 prefetch, 목록 가상화처럼 사용자의 대기 시간을 줄이는 방식은 적용해봤습니다.
조금 특이했던 사례라면, 최근 사이드 프로젝트에서 DOM 요소가 계속 누적되는 것을 피하기 위해 많은 요소는 Canvas로 그리고 직접 조작이 필요한 일부만 DOM으로 렌더링한 경험이 있습니다. 성능 문제가 생긴 뒤 최적화하기보다, 데이터가 늘어날 상황을 고려해 처음부터 렌더링 구조를 나눠 설계했다는 점에서 기억에 남습니다.

목차

• 다룰 내용

• 브라우저 안의 데이터베이스

  • Linear의 기술 스택 들여다보기

• 첫 로딩을 즉각적으로 느끼게 만들기

  • Linear 번들러의 여정: Parcel, Rollup, Vite, Rolldown

  • 첫 로딩 후 미리 불러오기

  • 속도와 오프라인 기능을 한층 끌어올리는 서비스 워커

  • 벤더 번들 구성

  • 대용량 폰트 파일 불러오기

  • 인라인 앱 셸

  • 먼저 렌더링하고 나중에 인증하기

• 동기화 엔진

  • 1. 데이터가 이미 존재합니다

  • 2. 변경 작업이 네트워크를 기다리지 않습니다

  • 3. 변경 하나, 셀 하나

  • 세 가지가 맞물려야 하는 이유

• 속도를 고려한 설계

  • 모든 작업에 단축키가 있습니다

  • 명령 팔레트는 언제나 키 하나면 열립니다

• 애니메이션

  • 애니메이션을 적용할 프로퍼티는 몇 가지뿐입니다

  • 절제할 때를 알아야 합니다

  • 지속 시간은 짧고 경쾌하게

• Linear가 이렇게 빠른 이유

글 링크: https://devowen.com/544

소개

이 글은 JPEG, PNG, WebP, AVIF, JPEG XL 등 주요 이미지 형식이 다운로드 도중 이미지를 점진적으로 표시하는 방식을 비교합니다.

현재는 프로그레시브 JPEG가 비교적 안정적이지만, WebP·AVIF·JPEG XL은 브라우저별 지원 차이와 디코딩 성능 등의 한계가 있습니다.

다만 최신 이미지의 파일 크기가 이미 충분히 작고 네트워크 데이터도 끊어져 도착할 수 있어, 프로그레시브 렌더링의 실제 효과는 제한적일 수 있다고 설명합니다.

향후에는 AVIF 파일 앞부분에 작고 흐릿한 미리보기 이미지를 넣어 빠르게 보여주는 방식이 현실적인 개선안으로 제안됩니다

팀원들의 의견

Q. JPEG, WebP, AVIF 등 다양한 이미지 포맷이 있는데, 실무에서 이미지 포맷을 선택할 때 어떤 기준으로 결정하시나요? 혹은 프로그레시브 렌더링처럼 사용자 경험을 개선하기 위해 이미지 최적화에 신경 써본 경험이 있으시면 공유해 주세요!

💬. 의견 1

이전에는 브라우저 지원 범위를 확인하고서 용량이 작은 WebP나 AVIF 확장자의 이미지를 주로 쓰는 편이었는데, 지금은 이미지/아이콘과 같은 리소스를 관리해주는 제품이 있어서 딱히 고민하지 않고 그대로 쓰는 편이었던 것 같아요! 최적화를 위해서는 이미지에 placeholder를 적용하거나 lazy loading을 적용해봤어요!

💬. 의견 2

대부분은 서버측에서 지원하는 스펙에 따르고, 제약이 없다면 png, WebP 를 주로 사용하고 있습니다.
최적화는 일반적으로 lazy loading을 적용했는데, 메신저 서비스의 경우 로딩이 적절한 타이밍에 되지 않거나 로딩 되면서 레이아웃 시프트가 크게 일어나면 사용자 경험이 크게 떨어지기 때문에 신경을 많이 썼던 기억이 나네요.
이외에 이미지 관련해서는 이미지 리사이즈나 APNG 애니메이션 제어 같은 작업을 종종 했었습니다.

목차

• 브라우저의 프로그레시브 이미지 렌더링 현황

• 프로그레시브 렌더링이 정말 도움이 될까?

• 반응형 이미지 대신 프로그레시브 렌더링은 어떨까?

글 링크: https://devowen.com/543

소개

이 글은 Fetch API의 스트림 기능이 데이터를 청크 단위로 받아 즉시 처리하는 데는 유용하지만, 업로드·다운로드 진행률을 측정하는 용도로는 정확하지 않다는 점을 설명합니다.

다운로드에서는 Content-Length가 gzip·Brotli 등으로 압축된 데이터의 크기를 나타내는 반면, 스트림에서 읽는 청크는 압축 해제된 데이터일 수 있어 진행률이 100%를 넘는 등 오차가 발생할 수 있습니다.

업로드에서도 스트림의 청크가 Fetch에 전달된 시점만 알 수 있을 뿐, 그 데이터가 실제로 네트워크를 통해 서버에 전송된 시점은 알 수 없기 때문에 신뢰할 만한 진행률을 계산하기 어렵습니다.

따라서 현재 정확한 업로드·다운로드 진행 상황이 필요하다면 XMLHttpRequest의 progress 이벤트를 사용하는 것이 적절하며, 앞으로는 Fetch 자체에 진행률 이벤트를 추가하는 API가 대안으로 제안되고 있습니다.

팀원들의 의견

큰 데이터를 주고 받는데는 시간이 오래 걸리고 이걸 기다리는 경험을 좋아하는 사용자는 없습니다. 큰 데이터 주고 받을 때 프론트엔드 개발자의 관점에서 사용자 경험을 좋게 하거나, 기술적으로 나은 방향을 고민해 본 적이 있으신가요?

💬. 의견 1

큰 데이터를 주고 받는 경우에 타임아웃 에러가 발생하는 경우가 종종 있었는데요. 이 경우에 일반적인 에러와 다른 에러 문구를 보여주고 최대한 에러 범위를 격리하는 작업을 했던 적이 있었어요.
또 서버에서 처리가 오래 걸리는 경우는 비동기 API나 SSE를 통해서 작업이 완료된 것을 확인하는 방식으로 작업하기도 했었어요!

목차

• 응답 스트림

• 요청 스트림

• 업로드 진행 상황 측정 방법

글 링크: https://handhand.tistory.com/entry/how-to-evaluate-an-npm-package-2026-edition

소개

프로젝트를 진행하며 무심코 설치하는 수많은 npm 패키지, 과연 얼마나 안전할까요?
블랙박스와 같은 외부 코드는 우리 시스템에 접근해 민감한 데이터를 유출하거나 악의적인 요청을 수행할 위험을 안고 있습니다. 단순히 주간 다운로드 수나 스타 수에 의존하는 대신, 어떻게 하면 진짜 신뢰할 수 있는 패키지를 선별할 수 있을까요?
저자는 의존성 필요성 검토부터 출처 증명(Provenance), 유지보수 상태, CI 및 보안 대응체계에 이르는 5단계 실전 평가 프로세스를 제시합니다.
오픈소스 공급망 공격 및 슬롭스쿼팅 위험 속에서 내 프로젝트를 안전하게 지키고 싶은 개발자분들이라면 읽어보시는 것을 추천드립니다.

팀원들의 의견

1. 필요한 npm 패키지를 선택할 때 본인만의 기준이 있으실까요?

2. AI에게 함께 작업하면서 직접 필요한 기능만 구현하는게 외부 의존성을 추가하는 방향보다 가볍고 안정적인 경우도 있을 것 같은데요, 이 부분에 대한 경험이나 의견도 궁금합니다!

💬. 의견 1

필요한 npm 패키지를 선택할 때 본인만의 기준이 있으실까요?

글에서의 내용과 유사한 것 같아요!
필요한 기능을 모두 제공하는지, 그리고 그 외의 기능이 우리 프로젝트에 들어올 때 너무 과한점은 없는지 같은것도 검토하구요. 오픈소스 관점에서 기여에 열려있다면 더 선택하는데 도움이 되는것 같아요.
회사에서 사용한다면 라이선스도 중요하구요. 최대한 많은 것들을 체크해서 가장 가벼운 것을 골라 사용합니다.

AI에게 함께 작업하면서 직접 필요한 기능만 구현하는게 외부 의존성을 추가하는 방향보다 가볍고 안정적인 경우도 있을 것 같은데요, 이 부분에 대한 경험이나 의견도 궁금합니다!

해당 의존이 어떤 성격이냐에 따라 다를것 같은데요. 커스터마이징이 많이 필요하거나, 잘 운영되는 적합한 패키지들이 없거나 할 때는 직접 구현을 검토하는 것 같아요. 대신, ‘바퀴를 다시 발명하지마라’라는 말처럼 신뢰를 이미 받고 있는 라이브러리가 있다면 (그리고 우리 프로젝트에 문제가 되지 않을 정도로 충분히 작다면) 저는 직접 구현보다 만들어져 있는 것들을 사용하는 편인거 같아요!

💬. 의견 2

필요한 npm 패키지를 선택할 때 본인만의 기준이 있으실까요?

tanstack, date-fns, ky와 같이 많은 사람들이 사용하는 패키지인지, 꾸준히 유지보수가 되는 패키지인지, 비슷한 패키지가 많다면 어떤 패키지가 우리가 풀려는 문제와 가장 적합한지 등을 보는 것 같아요. react/next.js와 같은 패키지에서 문제가 발생했던 것 처럼 유명한 패키지라고 괜찮은 것은 아니다보니 패키지를 안전하게 설치하는 방법에 대해 고민하는 것이 필요하다고 느꼈어요.

AI에게 함께 작업하면서 직접 필요한 기능만 구현하는게 외부 의존성을 추가하는 방향보다 가볍고 안정적인 경우도 있을 것 같은데요, 이 부분에 대한 경험이나 의견도 궁금합니다!

AI로 코드를 생산하는 비용이 낮아졌고, 더더욱 특정 도메인에서 필요한 기능이 아니라 프로그래밍의 일반적인 문제를 푸는 것은 AI가 충분히 잘 한다고 생각하긴 하는데요. 그럼에도 불구하고 일반적인 문제를 해결하는 경우에는 잘 만들어진 패키지를 사용하는 것이 유지보수하거나 불필요한 고민을 덜 하기에 좋다고 생각하는 것 같아요. 그래서 해결하려고 하는 문제중에 일반적인 문제이고 이 문제를 잘 해결하고 있는 패키지가 있다고 하면 외부 의존성을 추가하는 편입니다!

목차

• 정말로 이 패키지가 필요한가요?

• 활발하게 유지보수되고 있나요?

• npm에 실제로 게시된 것을 신뢰할 수 있나요?

• CI 파이프라인이 실재하나요, 아니면 장식인가요?

• 코드 품질이 눈에 보이나요?

• 무언가 잘못되면 어떻게 되나요?

• 체크리스트

글 링크: https://tinyurl.com/44juduzp

소개

요즘은 채용 과제, 오픈소스 라이브러리, npm 패키지처럼 “당연히 실행해 보는” 코드가 곧 공격 경로가 됩니다. 이 글은 겉보기엔 멀쩡히 돌아가는 프로젝트가 국기 이미지 뒤에 악성코드를 숨긴 채 배포됐고, 정적 분석과 백신을 모두 우회한 사례를 이야기합니다. 남이 준 코드를 로컬에서 npm run dev 한 번 돌리는 순간 사내 자격 증명·SSH 키·크립토 지갑까지 유출되고 그게 조직 전체를 겨냥한 공급망 공격의 첫 발판이 되는데요. 누구든 낯선 코드를 실행하기 전 한 번 더 의심하는 습관이 필요하게 된 시대인 것 같습니다. 🤨

팀원들의 의견

이 글을 보면 결국 외주나 프리랜서 개발자를 구한다는 미끼로 사람을 모아서 코딩 테스트 형태로 악성코드를 심는 패턴인데요. 혹시 비슷한 채용 사칭이나 미심쩍은 외주 제안을 받아보신 경험이나, 관련해서 들어보신 사례가 있으신가요? 없으시다면 앞으로 이런 식의 제안을 받았을 때 어떤 부분을 유심히 보면 좋을지도 같이 얘기해보고 싶어요. 사실 기업의 채용 테스트를 진행할때도 충분히 문제가 될 수 있는 패턴인 것 같아서요!

💬. 의견 1

오.. 요즘 이런 식의 공격 패턴이 있군요.
직접 겪어본 적은 없지만, 링크드인 같은 검증된 플랫폼을 통해 온 제안인지 파악하고 출처가 불분명하다면 일단 실행 안 해 보는 습관이 필요할 것 같아요. AI가 발전하면서 공격 수법도 다양해진 것 같아 걱정입니다. 😭

💬. 의견 2

개인 간의 파일 공유 시에 악성코드 정적 분석 과정이 필수로 필요해지는 시점이 오는 것인가 하는 생각이 드는군요. 😒 외부 파일이 내부로 들어오더라도 네트워크 레벨에서 차단을 해준다면 1차적인 방어는 가능하지 않않을까 합니다

목차

• 핵심 요약

• Elastic이 이 악성코드 캠페인을 발견한 경위

• 실행 경로

• DPRK 배후 추정 근거, Contagious Interview와의 연관성

• OTTERCOOKIE와 BEAVERTAIL이 보안 리서치에서 겹치는 이유

• 악성코드 분석

  • obfuscator.io가 악성코드를 숨기는 방식

  • 브라우저 자격 증명 및 크립토 지갑 탈취기 모듈의 동작 방식

  • 이 악성코드가 개발자 머신에서 훔치는 파일

  • Socket.IO 기반 RAT

  • 클립보드 탈취기와 윈도우 페이로드 드로퍼

• 결론

• Contagious Interview 악성코드의 MITRE ATT&CK 전술 및 기법

  • 전술

  • 기법

• Contagious Interview 악성코드 캠페인 탐지 및 예방 방법

  • 탐지 및 예방 규칙

  • 관측값

• 참고 자료

• 부록: 표적이 된 크립토 지갑 확장 프로그램 ID

글 링크: https://emewjin.github.io/introduce-safari-mcp/

소개

프런트엔드 개발자라면 Safari에서만 발생하는 독특한 이슈로 고생해 본 경험이 한 번은 있으리라 생각됩니다. 최근 Safari에서 공식 MCP를 발표하여 화제가 되었는데요. 어떤 도구들을 사용할 수 있고 어떻게 MCP를 활용하기를 기대하는지에 대한 내용이 담겨 있어 소개해드립니다. 🚀

팀원들의 의견

저한테 사파리는 폐쇄적인 성향이 강한 인상이 있어서, mcp가 나왔을 때 좀 놀라웠는데요 ㅎㅎ (이 시대에 이들도 어쩔 수 없나보다 싶기도 하고요) 크롬에서도 스킬을 발표하는 등 브라우저들도 여러모로 많은 노력을 기울이는 거 같아요. 사파리/크롬 특화된 스킬이나 mcp 사용해보신 경험이 있으신지, 어떠셨는지 궁금해요.

💬. 최근에 poke 앱을 사용하고 있는데, "AI 에이전트"를 자기 메시지 영역에 처음 들인 사례인데 저는 요런거 보면서 점점 개방적인 정책을 펴는 회사라고 느꼈던 것 같아요. 다른 회사들에 비하면 아직 멀었지만 ㅎㅎ 최근에는 성능 관련해서 웹을 많이 보고 있는데, Chrome Devtools mcp같은 것들을 활용을 정말 많이 하는 것 같아요. 브라우저 내부 동작 제어나 성능 분석 등에 너무 쉽게 접근할 수 있다보니까 효용성을 많이 느끼고 있습니다. 사실 이전에 분석하던 때를 생각하면 눈빠져라 원인을 찾고 맞는지 아닌지 테스트 해보고 했던 것 같거든요.

목차

• 사용 사례

• 도구

• 시작하는 방법

• 만든 이유

글 링크: https://ykss.netlify.app/translation/2026/how-an-underrated-refactor-saved-90-percent-memory-usage/

소개

대규모 데이터를 다루는 화면에서 복잡한 테이블은 언제나 성능 최적화의 큰 숙제입니다. 특히 수천 개의 행을 정렬하고 필터링하는 과정에서 자바스크립트 힙 메모리가 해제되지 않고 쌓이는 메모리 누수(Memory Leak) 문제는 서비스의 유저 경험을 서서히 갉아먹는 주범이 되곤 합니다.

이번 글은 TanStack Table이 v9으로 고도화되며 어떻게 메모리 성능을 극적으로 개선했는지 내부 아키텍처 관점에서 다룹니다. 가비지 컬렉터가 참조를 추적하지 못하던 문제를 해결하기 위해 내부 캐싱 메커니즘을 전면 리팩토링한 엔지니어링 접근법이 꽤 인상적입니다. 대규모 데이터 상태 관리와 메모리 누수를 방어하는 실무적인 인사이트를 얻기 좋아 한 번쯤 읽어보시길 추천드립니다. 🚀

팀원들의 의견

이 글에서는 객체마다 메서드를 생성하지 않고 공유 프로토타입을 사용해 메모리 사용량을 크게 줄였는데, 이런 패턴이 라이브러리처럼 대량의 객체를 생성하는 코드 뿐만 아니라 일반 애플리케이션 코드에서도 의식적으로 적용할 만한 상황이나 경험이 있으실까요? 또 테이블 성능을 볼 때 렌더링 비용뿐 아니라 데이터 처리 비용까지 함께 고려할때 어떤 지표들을 보시는지 궁금합니다!

💬. 프로토타입을 이용해서 메모리 사용량을 효과적으로 줄인 사례가 인상적이네요. 아직까지는 이정도 대규모의 데이터 모델을 적용해본 경험은 없습니다만 시계열 관련 모델을 다루는 상황에서 최적화가 필요할 때 고려해볼만하지 않을까 싶습니다.

💬. 프로토타입을 잘 사용하지 않았었는데 이런 방식으로 최적화를 하는 걸 보니 관심이 가네요. 대규모의 데이터를 다룰 때 보통 데이터 자체가 문제가 되기보다는(아무래도 페이지네이션해서 호출하는 경우가 많기도 했었고..) 렌더링이 문제가 됐던 경험이 더 많았던 것 같아요. 그래서 가상화로 주로 해결했었는데, 이런 접근도 신선하네요! 대규모 데이터를 위한 지표를 따로 만들어서 보진 않고 목 데이터로 데이터셋을 왕창 넣어서 벤치마킹해봤던 경험은 있습니다! 그래도 이 정도의 데이터를 다뤄보지 않았던 것 같습니다.

목차

• 결과

• 메모리 사용량을 측정한 방법

• 리팩터링

  • Table V8이 하던 방식

  • Table V9이 대신 하는 방식

  • 자바스크립트 클래스를 쓰지 않은 이유

  • Table V8에서 이 방식을 쓰지 않은 이유

• 마무리 생각

글 링크: https://tinyurl.com/3245nc9n

소개

리액트는 흔한 웹 취약점을 기본으로 막아주지만, 서버 컴포넌트/서버 함수가 늘어나면서 프런트엔드 개발자도 전통적으로 백엔드가 맡던 보안 문제까지 고민해야 하는 상황이 됐습니다. 이 글은 XSS 방어의 원리와 한계부터 짚어봅니다. dangerouslySetInnerHTML이 왜 위험한지, 인증 토큰을 localStorage에 저장하면 안 되는 이유는 무엇인지 등을 원인부터 설명하는 식이라, 이미 알고 계신 분들도 기본기를 한 번 점검한다는 마음으로 가볍게 읽어보시면 좋을 것 같습니다.

팀원들의 의견

Q1. 내부적으로 보안 사항 준수 여부를 체크하기 위한 스킬이나 리뷰 프로세스를 활용하시나요?
Q2. RSC/서버 액션 도입하면서 새로 신경 쓰게 된 보안 이슈가 있으신가요?

💬. 의견 1

1. 저희는 스킬은 따로 없고 리뷰 프로세스에서 AI 리뷰를 통해서 이런 요소도 체크가 가능하게끔 하려고 하는데요! 한편으로 조직 관점에서는 이렇게 보안에 영향을 줄만한 작업들은 플랫폼 엔지니어라던지 특정 직군의 동료들이 맡아서 하다보니 전문성이 있어서 큰 문제없이 돌아가고 있는 것 같아요!

2. 아직 RSC나 서버 액션 모두 도입하지 않아서 따로 신경을 써본 적은 없었습니다!

💬. 의견 2

1. 특정 기술들을 쓸 때는 리뷰 단계에서 서로 좀 더 신경 써서 보는 편입니다. AI를 활용한 리뷰도 같이 쓰는데, 보안이 워낙 중요한 부분이다 보니까 특별한 컨텍스트를 주입하지 않아도 해당 이슈를 좀 더 잘 잡아내는 것 같더라고요. 글에서 소개한 내용을 잘 정리해서 리뷰 컨텍스트로 넣어두면 더 좋을 것 같다는 생각도 드는 것 같습니다!

2. 사실 그 부분은 따로 도입을 생각하고 있진 않아서, 그래서 크게 새로 신경 쓰게 된 보안 이슈는 없었던 것 같아요. 다만 요즘은 공급망 공격이 워낙 많다 보니까, 외부 라이브러리 검수라든가 minimumReleaseAge 같은 쪽으로는 확실히 더 신경 쓰게 되는 것 같아요.

목차

• 리액트의 기본 XSS 보호 기능

  • dangerouslySetInnerHTML

• 안전한 인증과 CSRF

  • 토큰 저장

  • 안전한 쿠키 속성

  • CSRF 방어

• 서버 측 입력 검증

• 콘텐츠 보안 정책

  • 인라인 스크립트를 위한 논스(Nonces)

  • 정책 테스트하기

• 마치며

• 참고 자료

글 링크 : https://velog.io/@sehyunny/why-taste-is-the-new-moast

소개

해자(moat)라는 말을 들어보셨나요? 원래는 적의 침입을 막으려고 성 둘레에 깊게 파놓은 도랑을 뜻하는 말인데요, 요즘은 경쟁사가 쉽게 따라올 수 없는 진입장벽이나 경쟁 우위를 비유할 때 많이 쓰입니다. 워렌 버핏이 좋은 기업을 고르는 기준으로 이 표현을 즐겨 쓰면서 비즈니스 용어로 널리 퍼졌다고 하죠.

이 글은 AI로 코드와 앱 생산이 무한하고 저렴해진 지금, 전통적인 해자(속도, 자본, 기술력)는 힘을 잃었고 대신 무엇을 만들지 않을지 판단하는 ‘취향(taste)’이 유일한 해자가 되었다고 주장합니다.

취향이 스펙보다 중요해지는 시대, 이 의견에 공감하시나요? 이 글을 읽어보시면서 한 번쯤 곰곰이 생각해보시면 좋을 것 같습니다.

팀원들의 의견

Q1. 저자는 AI 시대에 더 많이, 더 빠르게 만드는 건 더 이상 의미가 없고, 오히려 ‘뭘 빼고 뭘 남길지’ 판단하는 취향이 진정한 경쟁 요소라고 주장합니다. 개발자 입장에서 이 주장에 공감 가실까요? 아니면 현실에서는 좀 다르다고 느끼시나요?

💬. 의견 1

매우 공감합니다. 근데 이게 AI 때문에 갑자기 생긴 흐름은 아니라고 생각해요. 예전에 2024 트렌드 노트를 볼 때도 개인화·취향 소비 얘기가 나왔던 게 기억나는데, 그 흐름이 원래 있었고 AI가 기폭제 역할을 한 것 같습니다. 그래서 지금은 취향 없는 상품은 선택을 받기 힘든 시대가 된 것 같습니다.

💬. 의견 2

저도 기능 추가보다 뭘 뺄지 고민하는 게 더 중요하다고 생각해서 공감이 되는 것 같아요. 있으면 좋은 비타민 같은 제품 말고, 꼭 필요한 진통제💊 같은 제품을 만들려면 불필요한 걸 걷어내고 문제를 명확하게 정의하는 게 중요한 것 같습니다.

Q2. 혹시 개발 하시면서 기술적인 고도화 외에도 취향을 기반으로 한 느낌이나 디테일 쪽에 시간 더 쏟은 적 있으신지, 있다면 그게 결과적으로 어떠한 차이를 만들었는지 궁금합니다!

💬. 의견 1

아쉽게도 외부 사용자 취향이나 디테일에 집중해서 만들어본 경험은 아직 부족한 것 같아요. 대신 요즘엔 "내가 쓰기 편한 것, 내가 보고 싶은 정보"를 중심에 두고 기능을 만들어보려고 하는데, 개발자 본인이 사용자가 돼서 자기 취향을 서비스에 반영해보는 것도 결국 비슷한 경험이 아닐까 싶습니다~~

💬. 의견 2

평소에 특정 도메인만 계속 개발하다 보니 제품이 사용자한테 일관된 느낌을 주는지 잘 못 느낄 때가 있더라고요. 각 팀이 기능을 계속 추가하다 보면 시간 지나면서 느낌이 달라지기도 하고요. 그래서 그런 걸 점검하는 느낌으로 매주 한두 번씩 제품 기능을 다 한번씩 써보고, 이질감 느껴지면 팀에 공유해서 개선했던 경험이 있어요. 지표로 확인은 못 했지만 사용자한테는 좋은 경험이 되지 않았을까 생각했습니다!

목차

1. 희소성의 붕괴: 소프트웨어가 저렴해질 때

2. 취향의 정의: 창업자의 숨겨진 초능력

3. 신뢰 인프라로서의 디자인

4. 미적 해자: 느낌이 기능이 될 때

5. 취향 경제의 부상

6. 편집자로서의 창업자: 절제로 이끌기

7. 속도 대신 신뢰를 위한 디자인

8. 다음 해자는 의미입니다

글 링크: https://tinyurl.com/p6d4csp3

소개

올해도 돌아온 “2026 리액트 라이브러리” 정리글입니다. 프로젝트 세팅부터 상태 관리, 데이터 페칭, 스타일링, UI, 폼, 인증, 배포까지 리액트로 앱 하나 만들 때 거쳐 가는 모든 단계에서 지금 뭐가 표준이고 뭐가 떠오르는 대안인지를 카테고리별로 훑어줍니다. 지난 1년 사이 실제로 바뀐 지점들이 같이 짚여 있어서 흐름 읽기에 좋습니다.

이 글을 읽으면서, “지금 내 스택이 여전히 합리적인 선택인가”를 한 번에 점검해보셔도 좋을 것 같고, 카테고리마다 인기/대안/레거시가 깔끔하게 나뉘어 있으니 비슷한 기술 스택 선택에 고민을 하고 계신분에게도 도움이 될 것 같아 공유드립니다. 😉

팀원들의 의견

최근 탈-Vercel 움직임이 많이 관찰되는데요. 이 관점에서 TanStack Start가 빠르게 주목과 지배력을 갖춰가는 것 같아 개인적으로도 관심이 많이 갑니다. Remix가 React Router v7로 합쳐진 지금, 옛 Remix 사용자라면 그대로 RR7로 갈지 아니면 TanStack Start로 갈아탈지도 궁금하고요. Next.js / TanStack Start / React Router v7 (프레임워크 모드) 셋을 지금 다시 비교한다면, 각각 어떤 장단점이 가장 눈에 들어오고 선택을 가를 것 같나요?

💬. 의견 1

개인적으로는 Vercel 플랫폼이 워낙 강력하고, Next.js도 활발하게 유지보수되고 있어서 사이드 프로젝트에서는 자주 사용하게 되는 것 같습니다.

다만 회사에서 Vercel이 아닌 자체 인프라를 구성해 운영하는 경우라면 이야기가 조금 달라진다고 생각하는데요. Next.js와 인프라 궁합이 애매하다는 얘기가 많이 들리고, 팀 규모가 커질수록 비용 부담도 커지며, 잦은 버전업 과정에서 호환성 이슈를 겪은 적도 있었습니다.

이런 환경에서 SSR을 고려한다면 TanStack Start도 좋은 대안이 될 수 있다고 봅니다. 최근 GEO 지원 같은 패치도 활발하고, 기존에 많이 사용하는 TanStack Query와의 궁합도 자연스럽다는 점이 매력적입니다. 특히 최근 TanStack Router를 사용하면서 개발 경험이 꽤 좋았고, TanStack Start로 전환한 사람들의 후기도 전반적으로 만족도가 높은 후기도 많이 봤습니다. 그래서 다음 프로젝트에서는 TanStack Start를 적극적으로 사용해 볼 생각입니다.

💬. 의견 2

저는 아직 TanStack Start는 사용 경험이 적고, TanStack Router만 사용해 본 상태라 조심스럽긴 합니다. 그래도 TanStack Router를 쓰면서 느낀 타입 안전한 라우팅 경험과 개발자 경험이 꽤 좋아서, Start도 자연스럽게 관심이 가는 것 같네요!

Next.js 쪽은 여전히 생태계나 레퍼런스 면에서 가장 안정적인 선택지지만, 요즘은 점점 너무 많은 것을 품고 있는 무거운 프레임워크처럼 느껴질 때가 많고 Vercel 바깥에서 운영할 때의 부담까지 생각하면 예전만큼 선뜻 고르게 되지는 않는 것 같습니다.

새 프로젝트라면 TanStack Start도 꽤 진지하게 검토해 볼 것 같습니다. 특히 TanStack Query나 Router를 이미 잘 쓰고 있는 팀이라면 전체 개발 경험이 하나의 생태계 안에서 잘 맞물릴 것 같다는 기대가 있습니다.

결국 선택을 가르는 기준은 안정성과 생태계를 우선할지, 더 가볍고 타입 안전한 개발 경험을 우선할지일 것 같습니다. 지금의 저는 Next.js를 기본값으로 두기보다는, 요구사항을 먼저 보고 React Router v7이나 TanStack Start 같은 대안을 더 적극적으로 비교해 볼 것 같습니다!

목차

• 새 리액트 프로젝트 시작하기

• 리액트 패키지 매니저

• 리액트 상태 관리

• 리액트 데이터 페칭

• React Router로 라우팅하기

• 리액트의 CSS 스타일링

• 리액트 UI 라이브러리

• 리액트 애니메이션 라이브러리

• 리액트의 시각화 및 차트 라이브러리

• 리액트의 폼 라이브러리

• 리액트의 코드 구조

• 리액트 인증

• 리액트 백엔드

• 리액트 데이터베이스

• 리액트 호스팅

• 리액트 테스트

• 리액트와 불변 데이터 구조

• 리액트 국제화

• 리액트의 리치 텍스트 에디터

• 리액트의 결제

• 리액트의 시간 처리

• 리액트 데스크톱 애플리케이션

• 리액트의 파일 업로드

• 리액트의 메일

• 드래그 앤 드롭

• 리액트로 모바일 개발하기

• 리액트 VR/AR

• 리액트를 위한 디자인 프로토타이핑

• 리액트 컴포넌트 문서화

글 링크: https://velog.io/@superlipbalm/why-are-we-not-using-service-workers

소개

브라우저가 서비스 워커를 지원한 지 벌써 8년이나 흘렀습니다. 구글이나 슬랙 같은 대기업들은 이를 활용해 사용자 경험을 극적으로 끌어올리고 있지만, 대다수 기업의 개발자들은 여전히 도입을 망설이곤 합니다.

이 글은 서비스 워커의 기본 동작 원리부터 시작해, 웹 앱의 초기 로딩 속도를 어디까지 개선할 수 있는지 슬랙의 유스케이스를 통해 상세히 다룹니다.

단순히 스펙만 나열에 그치지 않고, 웜 부트(warm boot)' 개념을 통해 네트워크 변동성에 의한 성능 저하를 완화하는 실질적인 방법을 제시합니다. 특히 하루에도 수없이 배포되는 프로덕션 환경에서 가장 까다로운 '캐시 버전 관리'와 '백엔드 데이터 동기화' 문제를 슬랙(Slack) 팀이 어떻게 3가지 레이어로 우아하게 해결했는지 구체적인 솔루션을 공유합니다.

도입이 까다롭다는 편견 때문에 서비스 워커를 사용하지 않고 계셨거나, 성능 최적화를 고민하고 있다면 읽어보시길 권합니다.

팀원들의 의견

실제로 서비스를 개발할 때 서비스 워커를 사용해본 적이 있으신가요? 사용해본적이 있다면 무엇을 해결하기 위해 사용했는지 그리고 문제점은 없었는지 궁금합니다. 또 검토는 해보앗으나 사용하지 않기로 결정했다면 그 이유를 알고 싶어요!

💬. 의견 1

뭔가 예전에 최적화를 끝까지 땡길때나 PWA 같은 알람같은 기능을 추가할때 서비스 워커를 간혹 쓰긴 했는데요.

최근 몇년간은 써 본적 없긴합니다. 부끄러운 말이지만 돌아가는 원리에 대해서 정확히 파악하진 못했고, 저뿐만 아니라 팀원분들도 큰 필요성을 못느낀거같긴해요.

근데 글에 나와 있는 내용을 보니깐 현재 프로덕트에서도 잘 쓸 수 있는 여러 사례들이 보여서 좀 더 사례공부를 깊게 해볼 수 있을거같습니다!

💬. 의견 2

주로 사이드 프로젝트를 진행할 때 홈 화면 설치나 푸시 알림처럼 앱과 비슷한 경험을 제공하기 위해 PWA를 적극적으로 사용하는 편인데, 그 목적 안에서만 서비스 워커를 활용했던 것 같습니다. 제가 겪은 범위에서는 큰 문제는 없었지만, 실제 현업에서도 동일하게 PWA가 필요할 때를 제외하고는 일반적인 웹 앱이나 어드민성 서비스에 서비스 워커를 활용해본 적은 거의 없었네요!

이 글에 나온 사례들을 보니 서비스 워커를 PWA뿐만 아니라 배포 후 구버전 에셋 서빙이나 초기 로딩 성능 개선에도 활용해볼 수 있겠다는 생각이 들었습니다. 다만 캐시 전략을 잘못 잡으면 문제가 오래 지속될 수 있으니, 도입한다면 정적 에셋 캐싱이나 배포 안정성처럼 범위가 명확한 문제부터 조심스럽게 적용해봐야 할 것 같네요.

목차

• 서비스 워커란 정확히 무엇일까요?

• 유스케이스 1: 초기 로딩 성능 및 오프라인 지원

• 유스케이스 2: 무엇이든 수정할 수 있는 프록시

• 필자의 유스케이스: 배포만 하면 깨지던 지연 로딩(Lazy-loaded) 라우트

• 그런데 왜 아무도 서비스 워커를 안 쓸까요?

• 서비스 워커 개발은 어렵습니다

• 참고 자료

글 링크: https://imnotadevleoper.tistory.com/386

소개

AI 코딩 도구는 단순히 코드를 더 빨리 작성해주는 수준을 넘어, 소프트웨어를 만드는 방식 자체를 바꾸고 있습니다. 이 글은 자동완성에서 시작해 자율 에이전트까지 이어지는 변화를 정리하며, 앞으로 개발자의 역할이 ‘코드를 작성하는 사람’에서 여러 AI 에이전트가 일하는 공장을 설계하고 운영하는 사람으로 변화하고 있다는 관점을 소개합니다.

흥미로운 점은, 변한 것은 구현 방식이지 소프트웨어 엔지니어링의 본질은 아니라는 것입니다. 오히려 명확한 요구사항, 좋은 아키텍처, 테스트, 시스템 사고, 리뷰와 같은 기본기는 AI 시대에 더욱 큰 레버리지를 만들어내는 역량이 됩니다. 앞으로 AI를 어떻게 사용할 것인가보다, AI가 가장 잘 일할 수 있는 환경을 어떻게 설계할 것인가를 고민해보고 싶은 분들께 특히 추천드리는 글입니다.

팀원들의 의견

AI 시대에 개발자로서 어떤 역량을 향상시키는 데 집중하고 계신지 궁금합니다! (AI를 잘 사용하기 위한 것에 비중이 높은지, 프론트엔드 외에도 기획/디자인/백엔드 등의 영역까지 넓히고 있는지, 그 외의 영역을 공부하고 있다던지 등등)

💬. 최근엔 AI가 발전하면서 저는 아래와 같은 방향으로 집중을 하고 있습니다.

1. AI를 활용해서 토큰을 최적화하거나 더 좋은 품질의 서비스를 내는것

2. 평소 팀이 겪는 이슈나 내가 겪는 이슈를 해결하기 위한 도구를 만드는것

3. 개발 팀 뿐만아니라 팀 전체의 효율을 올릴 수 있는 AI 스킬 탐구 및 비개발자 분들 AI 활용교육

약간 이것저것 좀 잡다한 느낌도 나는데요. 요약하자면 기존 하는 일을 더 빨리 잘할 수 있게하고 그로 인해 남는 시간을 다른 문제를 해결한다던가 팀 전체의 효율을 올릴 수 있는 방법을 고민하는것 같습니다!

💬. 요즘 AI에게 어떤 일을 맡길지 잘 정의하는 역량이 더 중요해지고 있다는 생각이 많이 들었습니다. 최근에는 요구사항을 명확하게 정리하거나 작업을 적절한 단위로 나누는 쪽에 더 신경 쓰게 되는 것 같아요.

프론트엔드 외 영역도 조금씩 넓혀야겠다는 생각을 하고 있습니다. 백엔드나 인프라를 깊게 전문적으로 다루지는 않더라도, API 설계나 데이터 흐름, 인증/권한 같은 부분을 이해하고 있어야 AI가 만든 결과물을 제대로 검토할 수 있더라고요.

추가적으로 가능한 빠르게 뭐든지 개선하고 시도해보려고 노력하고 있습니다! 이젠 생각에서 머물게 두기보다 금방 만들 수 있기 때문에 빠르게 시도하고 검증하는 방향을 추구하는거 같아요. 🚀

💬. AI를 사용하기 시작한 초반에는 AI를 잘 사용해서 생산성을 높이는 것에 집중했었는데요. 근래에는 AI를 더 잘 쓰기 위한 노력과 더불어 “모든 개발이 AI로 이뤄지는 세상에서 여전히 내가 해결해야 하는 것은 무엇일까?”를 고민하고 있어요. 구현에 필요한 시간과 비용이 극적으로 낮아진 만큼, 기존의 프론트엔드 개발 직무 경계를 넘어서서 더 앞단의 (기획/디자인/BE) 업무나 더 뒷단의 (검증/데이터 분석) 업무로의 확장이 필요한 순간들도 종종 마주하고 있구요.

나아가 어떻게 하면 나와 내 동료가 업무에서 가지고 있는 비효율을 AI를 통해 제거할 수 있을까 하는 고민들도 전에 비해서 많이 하게 되는것 같습니다. 이를 위해 메타적으로 내 하루 일과를 바라보고 이를 프로세스화 하는 것을 시도해보고 있어요.

💬. 다른 분들도 비슷하네요. 저 또한 AI가 등장한 이유로 생산성 극대화를 위해 많은 관심을 기울였는데요. 기존에 인간이 반복적으로 검토하던일, 배포 과정을 수동으로 하나하나 수행하던일, 테스트를 위해 개발바가 직접 옆에서 시나리오를 설명하고 사용법을 알려주는 일 등 많은 비효율적인 업무들을 단계를 줄이거나 개발자의 도움이 필요하지 않은 환경을 만들도록 하고 있어요.

sdk 테스트와 서비스 버전 업데이트시 전수 테스트하는 환경을 구축하여 모두가 테스트 하는 환경을 구축하고, 신규 LLM 모델 등장 또는 기능 업데이트시 성능 검사를 확인할 수 있도록 검증 시스템을 구축하거나, 원클릭 테스트 검증 플러그인 개발 등 다양한 방법으로 AI를 사내 생산성 시스템으로 적용하고 있어요!

목차

• 추상화의 역사

• AI 코딩 도구의 3세대

• 팩토리라는 사고방식

• 신입 개발자 온보딩과 닮은 점

• 명세가 곧 레버리지다

• 변하지 않은 것들

• 왜 테스트가 그 어느 때보다 중요해졌는가

• 아직 해결되지 않은 문제는 생성이 아니라 검증이다

• 높은 레버리지를 만드는 엔지니어링의 새로운 모습

• 더 큰 그림은 무엇일까?

글 링크: https://ykss.netlify.app/translation/2026/declarative-partial-updates/

소개

화면의 일부분만 동적으로 갱신하거나 스트리밍해야 하는 요구사항이 늘어나면서, 우리는 종종 무거운 프레임워크나 복잡한 상태 관리 라이브러리부터 떠올리곤 합니다. 하지만 단순한 동적 UI를 구현하기 위해 수많은 자바스크립트 코드를 내려받고 실행하는 방식은 프로젝트의 복잡도를 높일 뿐만 아니라, 성능과 유지보수 측면에서도 부담이 될 수 있습니다.

이번 글에서는 외부 라이브러리 없이 웹 표준 기술만으로 동적 화면을 구현하는 브라우저 네이티브 기술, 선언적 부분 업데이트(Declarative Partial Updates) 를 소개합니다. 특히 복잡한 하이드레이션 과정이나 직접적인 DOM 조작 없이도 브라우저가 HTML 일부를 스트리밍하고 갱신할 수 있도록 하는 <template> 기반 API는 꽤 인상적입니다. 프레임워크가 제공하던 편리한 기능들이 점차 웹 플랫폼 자체로 흡수되고 있는 지금, 웹의 미래가 어떤 방향으로 나아가고 있는지 가볍게 살펴보기 좋은 글이라 생각되어 한 번쯤 읽어보시길 추천드립니다. 🚀

팀원들의 의견

이 제안이 실제로 표준화된다면, 우리가 지금 프레임워크에 기대고 있는 역할 중 어디까지 브라우저 플랫폼으로 내려갈 수 있다고 보시나요? 그리고 “프레임워크가 해결하던 문제를 플랫폼이 흡수한다”는 흐름이 프런트엔드 개발자의 역할을 어떻게 바꿀 거라고 생각하시는지도 궁금합니다!

💬. 개인적으로 SSR, Streaming과 같이 렌더링에 관련된 기능은 브라우저에 충분히 흡수 가능하다고 생각합니다. 다만, 현재 프레임워크가 담당하는 상태 관리나 비즈니스 로직까지 브라우저에서 담당하기는 어렵지 않을까 싶네요..! 그래서 이러한 흐름이 이어진다면 FE 개발자의 역할도 점점 UI 렌더링보단 도메인 로직 설계에 집중하는 방향으로 변화하지 않을까 싶습니다.

💬. 부분 업데이트 기능이 표준으로 자리잡히더라도 프론트엔드 애플리케이션의 복잡한 상태관리나 비즈니스 로직의 존재 및 개발 생산성이라는 이점을 고려하면 기존 프레임워크를 완전히 대체하긴 어렵지 않을까 합니다. 다만 개발자가 접하는 앞단의 인터페이스는 유지되면서 프레임워크가 처리해주는 관심사에 변화가 생기는 방향이 되지 않을까요?

목차

• 비순서 스트리밍

• 새로운 HTML 삽입 및 스트리밍 메서드

• 이 두 가지를 함께 사용하기