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

소개

리액트 컴파일러가 공개 베타 이후 18개월 동안 어떤 변화를 만들어냈을까요?

Next.js, Expo, TanStack Start 등 주요 프레임워크의 통합부터 실제 프로덕션 도입 사례, 마이그레이션 전략, 그리고 여전히 진행 중인 논쟁까지 정리했습니다.

특히 “컴파일러는 무엇을 해결하고 무엇은 해결하지 못하는가”, “기존 프로젝트는 어떻게 도입해야 하는가”, “왜 useMemo와 useCallback의 시대가 저물고 있는가”에 관심이 있다면 흥미롭게 읽어보실 수 있습니다.

팀원들의 의견

리액트 컴파일러를 사용하고 있다면

• 도입하는 과정에서 어려움이나 러닝이 있었는지 궁금합니다!

• 컴파일러를 사용한 이후에 더 좋아졌다고 느끼는 지점들이 궁금합니다! (퍼포먼스, DX 등등)

리액트 컴파일러를 사용하지 않는다면

• 그 이유가 궁금합니다!

💬. 의견 1

현재 프로덕션에서 사용 중인데, 생각보다 성능 향상보다는 DX 개선 효과를 더 크게 느끼고 있습니다. 예전에는 useMemo, useCallback, React.memo를 어디에 적용해야 할지 고민하거나 코드 리뷰에서 관련 피드백이 자주 나왔는데, 컴파일러 도입 이후에는 그런 논의가 거의 사라졌습니다. 도입 과정에서는 ESLint 규칙을 활성화하면서 기존 코드베이스에 숨어 있던 React 규칙 위반들을 정리하는 작업이 가장 오래 걸렸고요. 아직 모든 성능 문제가 해결되는 건 아니지만, 최소한 메모이제이션 실수로 인한 리렌더링 문제는 많이 줄어들어서 만족하면서 사용하고 있습니다.

💬. 의견 2

리액트 컴파일러를 사용하지 않고 있는데요! 사용하지 않는 이유가 명시적으로 있다기보다는, “강력하게 사용해야 할 이유를 찾지 못했다” 쪽에 더 가까운 것 같아요. React Compiler이 주는 가치가 분명히 있으나, 이미 오랜 시간을 거쳐 기술적으로 성숙한 큰 코드베이스를 가지고 있다보니 마이그레이션 비용에 비해 얻는 효용이 크지 못하다고 느꼈습니다. (아직은)

글 링크 : https://velog.io/@sehyunny/harness-design-long-running-apps

소개

최근 Anthropic Engineering 블로그에 올라온 이 글은, 장시간 실행되는 AI 코딩 에이전트의 성능이 단순히 모델 자체의 능력보다도 하네스 설계에 크게 영향을 받는다는 점을 다룹니다.

저자는 Planner, Generator, Evaluator로 역할을 나눈 멀티 에이전트 구조를 통해 실제 애플리케이션을 개발하고 평가한 경험을 공유합니다. 특히 컨텍스트 관리, 에이전트 간 역할 분리, 반복적인 피드백 루프가 결과물의 품질을 어떻게 개선하는지 구체적인 사례와 함께 설명합니다.

최근 AI 코딩 에이전트와 하네스 엔지니어링에 대한 관심이 높아지고 있는데요. 관련 분야에 관심이 있거나 에이전트 워크플로우를 직접 설계해보고 있다면, 한 번쯤 읽어보면 도움이 될 만한 글이라 생각합니다 :)

팀원들의 의견

Q1. AI 에이전트를 여러 개 엮어서 쓰거나, 직접 하네스를 구축해본 경험 있는지, 또는 구축된 하네스를 사용해본 경험이 있으신지 궁금합니다!

💬. 의견 1

책임을 나눠 여러 에이전트를 써보기도 하고, 다른 분들이 구축해둔 하네스도 사용해봤는데 대체로 토큰 소비나 작업 시간이 늘어난 것에 비해 결과는 기대만큼 만족스럽지 않았던 것 같습니다🥲 그래서 요즘은 처음부터 복잡하게 구성하기보다는 필요할 때마다 조금씩 추가하고 다듬어서 사용하는 편입니다. Claude Code나 Codex도 꾸준히 좋아지고 있다 보니 예전보다 하네스에 덜 신경쓰게 된 것 같기도 하네요ㅎㅎ

💬. 의견 2

저는 사실 AI를 잘 활용하는 편은 아니라서 직접 구축해보거나 많은 경험이 있는 건 아닌데요! 사내 AI 관련 팀에서 구축해놓은 하네스가 있어서 필요할 때 사용해본 적은 있습니다. 개인적으로는 사용 경험이 꽤 만족스러웠고, 실제 업무에도 도움이 되었던 것 같아요.

💬. 의견 3

저희 팀은 단발성 작업을 넘어 팀 내 업무들을 하나의 연속적인 워크플로우로 엮어보는 시도를 하고 있는데요. 다만 동시에 너무 많은 스킬화가 진행되다 보니, 불필요한 AI 산출물들이 쏟아지는 과도기적 시행착오도 함께 겪고 있습니다.

이 과정을 통해 느낀 건 AI를 잘 쓰기 위해 새로운 아이디어를 무리하게 만들어내기보다, 우리가 원래 잘하던 방식을 제대로 구조화하고 자동화하는 게 더 중요하다는 점이었습니다. 또 AI 에이전트 도입의 본질은 결국 ‘평가’에 있다고 생각하는데요. “대충 잘 되는 것 같다”가 아니라 명확한 기준으로 평가하고 개선하는 루프를 만드는 게 중요하다는 점에서 이번 글이 특히 인상 깊었습니다.

목차

• 단순한 구현이 부족한 이유

• 프런트엔드 디자인: 주관적 품질을 채점 가능하게 만들기

• 풀스택 코딩으로 확장

  • 아키텍처

  • 하네스 실행

  • 하네스 반복 개선

  • 스프린트 구조 제거

  • 업데이트된 하네스의 결과

• 앞으로의 방향

• 감사의 말

글 링크: https://tinyurl.com/2snhzyhb

소개

대학교에서 프로그래밍을 처음 배울 때, 신규 입사자로 처음 회사일을 배워갈 때 가장 선배들이 많이 해주는 말은 ‘바퀴를 다시 발명하지 마라’ 였던 것 같습니다.

우리는 디자인·기획 요구에 떠밀려 어쩔 수 없이 새 UI를 직접 구현하게 되는 경우가 많은데, 사실 그 상당수는 브라우저 표준이 이미 검증해 둔 동작입니다. 암호학에서 검증된 표준 라이브러리를 쓰듯, 웹 UI에서도 "표준 위에서 만든다"는 관점이 곧 접근성·일관성·유지보수를 공짜로 얻는 길이라는 점을 다시 생각하게 해주는 가벼운 글입니다. 표준을 덮어쓰기 전에 "이게 정말 표준을 깨뜨릴 만큼 중요한가"를 한 번 더 묻고 이야기 해보면 좋을 것 같습니다.

팀원들의 의견

프런트엔드 개발을 하다 보면 ‘바퀴의 재발명’ 많이 경험해보셨으리라 생각합니다. 디자인 요구사항, 크로스 브라우징, 키보드 포커싱, 스크린 리더 지원 등 단계에서 지옥을 맛보는 경우가 많았을 것 같은데요. 경험기를 들려주세요!

💬. 의견 1

글 잘 읽었습니다!

FE 개발을 하면서 처음에는 디자인 요구사항을 맞추기 위해 네이티브 요소를 커스텀하는 일을 꽤 자연스럽게 생각했던 것 같습니다. 화면상으로는 원하는 UI가 나와도, 막상 키보드 포커스나 접근성, 모바일 동작까지 챙기려고 하면 생각보다 고려할 게 훨씬 많더라고요.

제 경우에는 커스텀 드롭다운, 모달 같은 컴포넌트를 만들 때 단순히 동작하는 것은 간단한데, 키보드로 이동할 때 포커스가 어디에 있어야 하는지, ESC로 닫혔을 때 다시 어느 요소로 돌아가야 하는지, 스크린 리더에서는 현재 선택된 값이 어떻게 읽혀야 하는지까지 생각하면 구현 난이도가 확 올라갔던 것 같네요..! 브라우저나 라이브러리가 당연하게 해주던 것들을 직접 구현하려니 그제서야 기본 동작의 가치가 느껴졌습니다.

그래서 요즘은 저도 shadcn/ui처럼 접근성 처리가 어느 정도 검증된 기반을 활용하는 편입니다. 기본적인 접근성 동작은 가져가면서도 코드와 스타일을 프로젝트에 맞게 커스텀할 수 있어 적당한 균형점이 있다고 느꼈습니다.

결국 바퀴를 재발명하는 게 항상 나쁜 건 아니지만, 사용자가 이미 익숙하게 기대하는 브라우저 기본 동작을 건드리는 일은 꽤 신중해야겠다는 생각이 들었습니다. 보기 좋은 UI를 만드는 것보다, 사용자가 의식하지 않아도 자연스럽게 쓸 수 있는 UI를 유지하는 게 더 어려운 일이었던 것 같네요. 🤔

💬. 의견 2

글 내용과는 조금 거리가 있을 수 있지만, 제가 바퀴를 재발명했던 경험을 얘기해보자면, 아마 많은 프론트엔드 업계에서 디자인 시스템이 한창 주목받던 시기에 디자인 시스템을 처음부터 직접 구축해보며 여러 시행착오를 겪었을 때 같습니다.

직접 구현할 때는 완성도 높게 뽑기 위해서 신경 쓸 것도 많고, UI 자체는 문제없이 보이더라도 접근성 이슈가 발생하거나, 크로스 브라우징 문제로 예상치 못한 어려움을 겪곤 했습니다.

그러던 중 블로그에서 Chakra UI를 기반으로 커스터마이징하여 디자인 시스템을 구축하는 사례를 접하게 되었고, 이를 참고해 개발을 진행했는데요. 이후에는 shadcn/ui를 기반으로 디자인 시스템을 구축하면서 처음부터 모든 것을 직접 만들 때 발생하던 시행착오를 크게 줄일 수 있었습니다. 좋은 사례였어요.

결과적으로 더 빠르고 확장성 있는 디자인 시스템을 구축할 수 있었고, 디자인 시스템 자체보다는 서비스 도메인과 비즈니스 문제 해결에 더욱 집중할 수 있게 되었습니다.

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

소개

대규모 타입스크립트 모노레포에서 에디터와 타입 검사 성능이 급격히 느려진 문제를 tsc --extendedDiagnostics, --generateTrace, @typescript/analyze-trace로 추적해 해결한 사례를 소개합니다.
핵심 원인은 Kysely 기반 헬퍼 함수와 복잡한 타입 추론이 특정 파일의 타입 검사 병목을 만들고 있었던 점이었고, 이를 인라인 처리와 의존성·타입 정리로 개선했습니다.
그 결과 타입 검사 시간은 226초에서 38초로, 전체 빌드 시간은 374초에서 79초로 줄어들며 타입스크립트 성능 튜닝의 실전 접근법을 보여줍니다.

팀원들의 의견

타입스크립트를 사용하시면서 성능 문제를 겪으신 적이 있으신지, 있다면 어떤 방식으로 해결을 하셨는지 궁금합니다.

💬. 의견 1

실제로 큰 성능 문제를 직접 경험해본 적은 없지만, 평소 빌드와 타입 검사의 역할을 명확히 분리하고 순환 참조나 미사용 타입을 엄격하게 검증하며 코드베이스를 가볍게 유지하는 데 신경 쓰고 있습니다.
오늘 글처럼 대규모 프로젝트에서는 복잡한 제네릭과 과도한 타입 추론이 상상 이상으로 심각한 컴파일 속도 저하를 유발할 수 있음을 지표상으로 보니 깜짝 놀랐는데요. 만약 향후 지연 문제가 발생한다면 이 글을 참고해서 구조를 단순화하는 방식으로 해결해보겠습니다.

💬. 의견 2

거대한 모노레포에서 작업하다보니 항상 그런 것은 아니지만 가끔씩 에디터가 너무나도 느려지고 아무리 기다려도 타입 추론이 되지 않는 경우가 가끔씩 있는데요! 우선은 IDE에서 Tsserver의 Max Memory를 늘리는 방식으로 대응했었는데, 글의 내용을 참고해서 한번 점검해봐야 할 것 같네요!

목차

• 문제 진단하기

• 근본 원인 찾기

• 해결 방법

• 결과

글 링크: https://velog.io/@surim014/npm-supply-chain-compromise-postmortem

소개

요즘 AI로 개발하면서 추천받은 패키지를 설치하거나 자동으로 생성된 워크플로우를 그대로 돌리는 일이 부쩍 많아졌는데요, 그만큼 공급망을 노린 보안 사고 소식도 자주 들려오는 것 같습니다.

이 글은 지난 달에 발생한 TanStack의 npm 패키지 42개가 한꺼번에 악성 코드로 게시됐던 사고를 TanStack 팀이 직접 정리한 포스트모템입니다. pull_request_target 패턴, GitHub Actions 캐시 포이즈닝, 러너 메모리에서의 OIDC 토큰 추출이라는 세 가지 취약점이 어떻게 연쇄적으로 엮여 패키지 게시 권한까지 넘어갔는지를 타임라인과 함께 구체적으로 보여줍니다.

특히 공격자가 위조한 커밋 신원이 하필 claude였고, 사용된 기법들도 새로 만든 게 아니라 이미 공개된 연구를 재조합한 것이었다는 점이 인상적이었는데요. AI 시대에 공격이 얼마나 쉽게 조합되고 빨라질 수 있는지 실감하게 되었던 것 같습니다.

특정 라이브러리만의 문제가 아니라 누구에게나 일어날 수 있는 일이라, 사고가 실제로 어떻게 벌어지는지 알아두고 싶은 분들에게 추천드립니다!

팀원들의 의견

Q1. Tanstack도 보안 이슈를 제3자를 통해 처음 알게 되다니 신기하네요..!
요새 하도 보안이슈가 많이 터져서 그런지 보안에 대한 민감도가 낮아지는 것 같아요 😵‍💫

다들 이런 보안 이슈로부터 레포를 어떻게 관리하시는지 궁금합니다!

💬. 의견 1

저희도 외부적으로 의존해서 사용하는 라이브러리에 보안 이슈가 생기면 누군가가 해당 소식을 공유해 줘서 알게 되고, 그 때 맞춰서 대응하는 식으로 관리합니다. 그리고 저희 쪽에서 시스템적으로 기본적인 보안 정책들 (e.g. 민감한 값을 github에 올리면 안된다라든지) 을 탐지하고 있어서 예전에 한 번 웹훅 URL을 그대로 git에 올렸는데 보안팀에서 바로 지라 티켓과 함께 수정 요청 메일이 온 적이 있어서 놀랐던 기억이 있습니다.

💬. 의견 2

레포 내에서는 dependabot이나 snyk, sonarqube 등을 CI/CD에 연동해서 보안 취약점 등을 탐지하는 편인 것 같고, 레포 외적으로는 사내 오픈 소스팀에 검수를 요청하거나, 좀 볼륨이 큰 기능의 경우 보안팀에 설계 검토 & 코드 검토를 함께 요청하고 있습니다!

목차

• TL;DR

• 영향

• 타임라인

• 근본 원인

• 감지

• 배운 점

• 미해결 질문

• 참고 자료

• 부록 A - 영향받은 버전

글 링크: https://shorturl.at/Jp8qy

소개

AI로 개발하시는 많은 분들이 토큰 사용량을 초과해서 더 이상 작업을 진행 못했던 경험이 다들 한번쯤은 있었을 것 같습니다.

저 역시 최근 작업할 일이 많아지면서 사내 토큰 사용 한도를 초과해 작업이 중간에 멈춘 적이 여러 번 있었는데요. 한 번 이런 경험을 하고 나니, 자연스럽게 토큰을 조금이라도 아껴 쓰는 방법을 찾아보게 되었습니다.

그러다 발견한 글이 바로 이 글입니다. 이 글에서는 여러 스킬, 플러그인, 훅, 오픈소스 도구 등을 활용해 총 5개의 레이어를 구성하고, 이를 통해 기존 토큰 사용량을 줄이고 세션 유지 시간을 크게 늘린 사례를 소개하고 있습니다.

물론 개인적으로 이렇게 여러 도구를 덧붙이면 오히려 AI의 성능이나 응답 품질이 떨어지지 않을까 걱정되는 부분이 있어 선호하지는 않는데요. 그래도 토큰을 효율적으로 사용하기 위한 다양한 시도를 참고하기에는 꽤 좋은 글이라고 생각합니다.

팀원들의 의견

Q1. 이런 글들을 보다 보면 MCP나 스킬, 여러 툴을 연동해서 클로드 코드를 더 효율적으로 써야 하나 싶다가도, 한편으로는 설정이 많아질수록 오히려 클로드 코드의 성능이나 응답 품질을 떨어뜨리는 건 아닐까 하는 생각이 들어서 선뜻 세팅하기가 망설여지더라고요.

다른 분들은 어떻게 생각하시나요?

최근 클로드 코드에 연동해서 사용해본 MCP, 스킬, 툴 중에 실제로 만족스러운 경험을 하신 게 있다면 공유해주실 수 있을까요?

💬. 의견 1

이런 글들을 보다 보면 MCP나 스킬, 여러 툴을 연동해서 클로드 코드를 더 효율적으로 써야 하나 싶다가도, 한편으로는 설정이 많아질수록 오히려 클로드 코드의 성능이나 응답 품질을 떨어뜨리는 건 아닐까 하는 생각이 들어서 선뜻 세팅하기가 망설여지더라고요.

저도 말씀하신 내용에 공감합니다! 여러 마켓플레이스를 이것처것 많이 설치했었는데, 결국 그걸 다 쓰는가 오히려 토큰을 많이 잡아먹는게 아닌가? 이런 생각을 많이 했던 것 같아요.

사실 사이드 프로젝트를 최근엔 별로 많이 안하고있어서, 회사에서 일하는 시간에 많이 쓰는데 그럴수록 회사의 워크플로우를 도와주는 스킬이나 MCP가 유용하더라구요.
지라/위키/깃헙을 잘 쓰기 위한 MCP나 스킬(ex. 스펙 분석, 티켓 따기, pr 올리기, pr 리뷰 등)을 가장 많이 쓰는 것 같아요 아무래도!

그런데 최근 센트리 MCP를 좀 많이 쓰고 있는데, 이것도 여러 이벤트/이슈를 잘 분석해주고 2주동안 대시보드 넣으면 추이나 데이터를 잘 뽑아줘서 좋았던 것 같아요.

그리고 마켓플레이스 만들어서 팀 내 스킬을 같이 만들어서 커맨드 형태로 쓰는게 최근엔 가장 많이 썼던 방식 같습니다...만 이것도 좀 낡은 방식이라는 얘기를 들었어요 ㅜ_ㅜ

목차

• TL; DR;

• 60초 안에 보는 치트시트

• 레이어 1. Codebase Memory MCP (코드 탐색에서 99% 토큰 절감)

• 레이어 2. context-mode (큰 출력에서 98% 토큰 절감)

• 레이어 3. RTK — Rust Token Killer (셸 출력에서 60–90% 절감)

• 레이어 4. Headroom (API에 도달하는 모든 것에서 47–92% 절감)

• 레이어 5. Caveman 플러그인 (Claude 자신의 출력에서 50–75% 절감)

• 자동 핸드오프. 상태를 잃지 않고 컴팩션 살아남기

• 보너스 훅. bash-ban-raw-tools

• 전체 settings.json

• 각 환경 변수의 역할

• 이 모든 것을 돌아가게 만드는 CLAUDE.md

• 언어별 룰 파일

• 보너스. 이 환경이 열어 주는 워크플로우

• 그 외 효과 컸던 것들

• 마무리

글 링크: https://velog.io/@tap_kim/moving-away-from-tailwind-and-learning-to-structure-my-css-

소개

Tailwind의 빠른 개발 경험 뒤에서, CSS 구조를 어떻게 더 깊이 이해하고 설계할 수 있을지 고민해본 글입니다. 유틸리티 클래스 중심의 방식에서 벗어나며 마주한 한계와, 더 읽기 쉽고 유지보수하기 좋은 스타일링 방법을 함께 다룹니다.

단순히 “무엇이 더 좋다”를 말하기보다, 왜 CSS 구조화가 중요한지 실무적인 관점에서 풀어냅니다. Tailwind를 쓰고 있거나, 점점 복잡해지는 스타일 관리에 고민이 있다면 흥미롭게 읽을 수 있는 아티클입니다.

팀원들의 의견

저자는 Tailwind의 회의감과 부정적인 스탠스라기 보다는 오히려 CSS가 더 좋게 느끼고 더 잘 알게 되었다는 의견과 함께 어떤 한계가 있었는지를 말하고자 하는 것 같습니다.

Q1. 개인적으로는 LLM으로 쏟아내는 Tailwind CSS를 제어하기가 버겁게 느껴졌는데요. 다들 어떻게 본인 스타일에 맞게 유도하고 스타일 작업을 수행하게 하는지 궁금합니다.

Q2. 저자처럼 오히려 Tailwind를 사용하면서 한계를 경험해서 기존 CSS(또는 다른 스타일 라이브러리)를 더 잘 사용하게된 경우가 있으신가요?

💬. 의견 1

A1. 제어하기 버겁다는 것에 공감해서 (도움을 주는 많은 익스텐션이 있는건 알지만, 일반적이지 않은 패턴 등 가독성 문제가 가장 크게 느껴져서요) 어드민에만 사용하고 있습니다. 애초에 한 번 정의된 스타일로 생각하고 있기에 뭔가 추가적인 스타일을 녹이려 하지 않고 시스템처럼 사용하려고 합니다. 그리고 LLM이 쏟아낸 똥은 LLM이 치워야 한다가 제 주의이기는 해서...... 어드민이기도 하고 스타일이 이상하다 싶으면 classname을 싹 지우고 다시 만들도록 시키고 있기는 합니다.

💬. 의견 2

A1. 저희 팀은 scss module 방식을 사용해서 스타일링을 해 오고 있습니다. 팀에서 디자인 시스템으로 폰트, 사이즈, 컬러 등의 토큰 값을 이미 만들어놓고 그걸 가지고 피그마 컨텍스트를 읽어서 LLM이 작업을 해 주고 있어서 디자인 시안만 토큰 값대로 잘 만들어져 있다면 문제 없이 스타일링을 할 수 있어서 tailwind를 써보아야 겠다는 생각은 따로 안 했던 것 같아요. 그리고 개인적으로 JSX 파일 안에 스타일 요소까지 있으면 너무 파일이 복잡해져서 tailwind를 선호하지 않는 편이긴 합니다.

A2. 저도 이전 회사에서는 tailwind를 사용했는데, 완전 새로운 프로젝트를 시작하거나 비교적 구조가 단순한(e.g. 어드민) 웹에는 적합한 부분이 있지만, 디자이너가 커스텀한 스타일링을 많이 요구하는 경우에는 한계를 좀 느꼈던 것 같아요. 그래서 직접 CSS 파일을 수정해 주는 방식이 저에게는 더 잘 맞는 방식이라고 생각합니다.

💬. 의견 3

A1. 저희팀은 마크업 개발자가 따로 있어서 제가 직접적으로 tailwind를 제어하는 경우는 많지 않았던 것 같은데요, 아무래도 tailwind CSS에 대한 경험이 많지 않다보니 LLM으로 스타일링을 요구할때도 제가 이해 가능할 정도의 최소한으로만 부탁하는 것 같습니다.

목차

• 알고 보니 Tailwind는 저에게 많은 것을 가르쳐 주었다

• 이 글에서 다룰 시스템들

  • 1. 리셋

  • 2. 컴포넌트

  • 3. 색상

  • 4. 폰트 크기

  • 5. 유틸리티

  • 6. 베이스

  • 7. 간격

  • 8. 반응형 디자인 — 그리드를 더 많이 쓰자!

  • 9. 빌드 시스템 — esbuild

• 왜 Tailwind에서 벗어나려고 하는가?

• 궁금한 CSS 기능들

• Tailwind에서 벗어난 마지막 이유

글 링크: https://handhand.tistory.com/entry/debugging-session-with-claude

소개

디버깅 과정에서 AI와 함께 가설을 세우고, 빗나가고, 다시 세우길 반복하며 진짜 원인에 닿기까지. 저자는 Claude와 주고받은 대화를 따라가며 어떻게 문제를 파악하고 의도를 전달해야 하는지, 그리고 그 과정에서 얻은 교훈은 무엇인지 풀어냅니다. AI와 함께 효율적으로 문제를 풀어가는 방향을 엿보고 싶다면, 이 글이 좋은 길잡이가 되어줄 거예요.

팀원들의 의견

AI와 함께 프론트엔드 애플리케이션의 버그를 추적하시면서 각자 활용하시는 디버깅 꿀팁이나 유용한 도구(mcp, skills 등) 혹은 경험들은 어떤게 있을까요?

💬. 의견 1

저도 AI에게 위임하기보다는 같이 페어프로그래밍을 하는 동료처럼 생각하고 활용하는 것 같은데요! 요즘은 디버깅도 동일하고 어떤 문제를 풀 때 의식적으로 문제 이해 - 계획 수립 - 계획 실행 - 피드백 단계를 거치는데 각 단계마다 AI와 같이 고민을 하면서 정리해보는 편이에요!

💬. 의견 2

저는 작업을 시킬때 기본적인 정보 습득에는 Context7 MCP를 활용하고, 그 외에는 비슷한 문제를 겪은 사례를 찾는 웹서치를 자주 활용하는 편입니다. 디버깅 자체는 결국 로그 기반으로 접근하게 되는 것 같습니다. 로그를 잘 남기고 추적 가능한 지점을 확보하는 게 우선이고, 요즘은 cmux를 쓰면서 에이전트와 내장 브라우저를 함께 띄워두고 AI가 직접 화면을 참고하면서 문제를 찾도록 하고 있습니다. 프런트엔드는 결국 화면과 연관된 문제가 많다 보니 이 방식이 꽤 유효한 것 같습니다.
또 가설이 생기면 해당 시나리오를 테스트 코드로 먼저 구현해두고, 그 테스트가 통과하도록 만드는 방식으로 접근하기도 합니다. 요런 접근은 AI가 빠르게 사용하고 버리는 방식으로 유효한것 같더라구요!

💬. 의견 3

저는 요즘 스펙 문서를 먼저 만들어두고 어느정도 안전장치를 문서화한 후에 클로드로 돌려보고 있어요
그래도 허점이 많아서 iteration의 연속입니다 ㅎㅎ
가끔 더블체크를 위해서 비슷한 context 를 쌓지 않은 곳에서 다시 질문해요!

목차

• 실시간 디버깅 여정

  • 첫 번째 가설: 양식의 비활성화 상태

  • 두 번째 가설: 화면을 막고 있는 로딩 스크린

  • 세 번째 가설: 닫히지 않는 모달

  • 네 번째 가설: 모달 언마운트 이슈 + Claude의 첫 수정안

  • 해결

• Claude와 디버깅하면서 든 느낌

• 장단점

• 마치며

글 링크: https://shorturl.at/g4Tjo

소개

빅테크 기업들이 AI 도입률과 토큰 사용량을 생산성 지표로 측정하기 시작하면서, 사내에서 'AI 네이티브'로 살아남기 위해 피로감을 느끼는 엔지니어들이 늘고 있습니다. 이 글은 인사평가에서 불이익을 받지 않으려고 의미 없는 프롬프트를 날리고 에이전트를 돌려대며 토큰을 억지로 태우는, 이른바 ‘토큰맥싱(Tokenmaxxing)’이라는 실리콘밸리의 기이한 생존 게임을 고발합니다. 매일 AI 도구를 곁에 두고 코드를 짜는 개발자로서, 과거의 '코드 라인 수 채우기' 악습이 AI 시대에 어떻게 변질되어 나타나고 있는지 함께 고민해보면 어떨까요?

팀원들의 의견

개인적으로 토큰 사용량은 AI 적극 도입을 희망하는 회사에서 충분히 관찰할만한 지표라고 생각하는데요. 다만, 이걸 가지고 성과를 측정하는 것은 다른 이야기라고 생각하는데, 이 글에서처럼 회사에서 토큰 사용량을 측정하고 팀원들이 볼 수 있도록 공유하고 있나요? 이런 현상을 어떻게 보고 있나요?

💬. 의견 1

저희는 토큰 증설과 사용량을 관리하는 사내 대시보드가 존재하여 팀원들 간에는 사용량을 공유하고 있지만 이를 전사 오픈하고 있지는 않습니다. 해당 대시보드에서 가장 최근 N건의 프롬프트와 AI 사용 패턴을 기반으로 현재 어떤 부분을 잘 사용하고 있는지,혹은 개선이 필요한지 피드백해주는 기능이 같이 제공되고 있어서 토큰 사용량 개선 방향을 제안받을 수 있는 형태입니다.

토큰 소비량은 입력 프롬프트, 작업의 복잡도 및 맥락 파악비용, 잦고 비효율적인 MCP 호출 등 요인이 많기 때문에 많은 토큰을 사용한다고 해서 그게 꼭 성과지표랑 이어지기는 어렵지 않을까 생각하여 저도 회의적인 입장입니다.

그래도 AI로 ‘무엇인가 시도해보려는’ 동기부여 만큼은 중요하다고 생각해요.
선형적이지는 않지만, 사용량이 많고 사용 패턴이 긍정적이라면 AI를 업무환경에 적극적으로 도입해서 변화를 꾀하려는 움직임이 있다고 해석할 수 있지 않을까합니다.

💬. 의견 2

일단 저희 팀은 토큰 사용량에 대해서 따로 수치화하고 있거나 모니터링 하고 있지는 않습니다.

근데 회사 입장에서는 평소에 잘 안 쓰는 사람들 독려하는 계기가 되거나 잘 쓰는 사람들의 패턴을 분석해서 다른 사람들도 더 잘 쓰게 하는 인사이트를 찾을 수 있는 방법도 될 수 있을거같긴 하네요 ㅎㅎ

이게 평가지표에 영향을 주고 장기적으로 운용하게 되면은 악용사례도 꽤나 나올 수 있을거 같긴하지만 단기적으로는 꽤나 재밌고 괜찮을거 같긴 합니다.

국내 기업들 중에선 컬리가 비슷한 모델로 쓰는거같구 최근에 컬리에서 AI 사용량 1등 하신분의 후기도 재밌게 읽어서 글 공유드려요! → 링크

💬. 의견 3

저희 동아리에서도 토큰맥싱이라는 단어가 자주 보인다면서 글 공유해주셨더라구요!

Engineer’s Codex

Tokenmaxxing, Promomaxxing, and Misaligned Incentives in Tech

Engineer’s Codex is a publication about real-world software engineering…

Read more

a month ago · 47 likes · 4 comments · Engineer's Codex

요 글이 말씀해주신 내용을 잘 담고 있는 것 같습니다! 측정 지표가 인센티브로 굳어질 때 어떻게 망가지는지 🥲

목차

• 마이크로소프트: 전면적인 토큰맥싱

• 세일즈포스: “최소”와 “이상” 목표를 채우려고 토큰을 태우다

• 쇼피파이: 토큰맥싱을 피하는 좋은 사례

• 토큰맥싱: AI 벤더에게는 좋고, 그 외 모두에게는 나쁘다

글 링크: https://emewjin.github.io/parse-dont-validate-typescript

소개

타입스크립트를 다루며 끝없이 이어지는 if 검증 코드와 불안정한 타입 추론에 피로를 느끼신 적 있나요? 이 글은 일회성으로 버려지는 ‘검증’ 대신, 확인된 데이터의 안전성을 타입 시스템에 영구적으로 각인시키는 ‘파싱’을 제안합니다. 외부 데이터를 일상적으로 처리하는 프런트엔드 개발자로서, 가볍게 읽어보시면 어떨까요?

팀원들의 의견

다들 ‘검증하지 말고 파싱하라’ 실무에서 많이 쓰시는 편인가요? 저는 클라이언트에서는 폼 정도가 아니면 잘 안 썼던거 같아요. 종종 간단한 타입가드 정도로 해결보는거 같고요. 서버에서는 리모트에서 넘어온 데이터 정의할 때, 그리고 레이어마다(특히 서비스 단에서) 반환값 만들 때 zod나 typebox같은 거 쓰고 있네요. io-ts는 이 글에서 첨 접했고요. 클코는 별도 지시가 없으면 파서고 타입가드고 나발이고 타입단언 떡칠해놓긴 하더라구요 ㅠ_ㅠ

💬. 의견 1

저는 가끔 branded type을 쓰긴 하는데 ㅎㅎ 보통은 분기합니다..

💬. 의견 2

이 원칙을 실제로 적용했을 때 가장 효과적이었던 건, 외부 통신과 내부 도메인 사이에 명시적인 파서 레이어를 두는 구조였습니다. 클린 아키텍처나 헥사고날 아키텍처에서 말하는 것처럼, 외부에서 들어오는 값은 반드시 그 경계를 통과하게 만들고, 통과한 값만 내부에서 신뢰하는 방식으로 운영했습니다. 그랬더니 타입스크립트가 지금처럼 여러 기능들을 제공하지 않았음에도 글에서 말하는 장점들을 실제로 누릴 수 있었습니다.

다만 운영하다 보면 파서가 점점 비대해지고, 글에서도 언급되는 타입 캐스팅이 여기저기 스며드는 지점이 생기면서 반쪽짜리 구조가 되는 경험도 했습니다. 괜한 복잡도만 높아지고 오히려 관리 포인트가 늘어나는 아이러니가 생겼는데.. 개념 자체는 늘 유효하고 도입할 가치가 있다고 생각합니다. 결국 관건은 이 레이어를 얼마나 잘 운영하느냐인 것 같습니다.

💬. 의견 3

저는 외부 세계에서 우리 서비스 내부로 들어오는 데이터(서버 api 응답, url query, 유저 인풋, 브라우저 스토리지등)의 경우에는 파싱을 적극적으로 쓰려고 하는 편인데요!

이 글에서도 얘기하듯이 현실적으로 모든 지점에서 적용할 수는 없지만 계속해서 검증기(validation)을 사용해야 하는 경우라면 분기가 많아지고 코드를 읽기가 어려워서 맨 앞단에서 파싱을 해주는데요. 이후에는 분기가 간단해지거나 사라져서 여러 케이스를 고려할 필요 없이 비즈니스 로직에 집중할 수 있어서 좋은 것 같아요!

목차

• 우리 모두가 작성해 본 검증기

• 우리가 실제로 원하는 것

• 브랜디드 타입, 또는 구조적 타입 시스템에 일부러 거짓말하기

• 타입스크립트가 당신과 싸우는 지점

• Zod는 어떤가요?

• 더 작은 원칙

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

소개

리액트가 “기술적으로 항상 최선이라서”가 아니라 “다들 쓰니까” 선택되는 관성을 돌아보게 해주는 글이라 소개할 만합니다. Svelte, Solid, Qwik 같은 대안들이 성능·복잡도·아키텍처 측면에서 어떤 다른 가능성을 여는지 비교해볼 수 있습니다. 새 프로젝트에서 프레임워크를 고를 때 익숙함보다 제약 조건, 팀 역량, 유지 비용을 기준으로 판단하자는 실용적인 문제의식을 던집니다.

팀원들의 의견

1. (리액트를 기본 라이브러리로 쓰시는 분들께) 리액트를 사용하시는 이유가 무엇인가요? 리액트를 사용하면서 불편한 점은 무엇인가요?

2. (리액트를 기본 라이브러리로 쓰시지 않는 분들께) 리액트를 언젠가 배워야 한다고 느끼시나요?

3. 리액트 외의 다른 라이브러리를 도입해 본 경험과 후기가 있다면 알려주세요.

💬. 의견 1

제가 리액트를 사용하는 이유는 글에 등장하는 이유와 정확하게 매칭되는 것 같습니다. FE를 처음 공부한 게 벌써 10년 가까이 됐는데, 그때 스프링만 고집하는 걸 보며 FE와 비교하곤 했던 기억이 납니다. 지금은 오히려 FE가 더하면 더했지 덜하지 않다고 느낍니다.

그렇다고 FE가 무조건 나쁘게 나아가고 있다는 것을 이야기 하고 싶은 건 아닙니다. 결국 우리는 돈을 벌어야 하는 서비스를 만드는 엔지니어고, 그래서 늘 회사 관점에서 보수적인 선택을 점점 하게 되는 것 같습니다. 새로운 라이브러리들이 기존의 문제를 해결해주더라도, 그걸 지탱하는 생태계 전체를 대체하는 건 글에서 이야기하는 것보다 훨씬 어려운 문제라고 생각합니다.

사실 이런 주제에 대한 글이 굉장히 유행했던 시기가 있었습니다. 3~4년 전부터 FE 진영에서 꽤 크게 문제 제기가 있었고, 그런 비판적인 글들 덕분에 리액트도 새로운 훅들과 패치를 내놓으며 반응했습니다. 그런데 AI가 등장하면서 그런 건강한 긴장감이 점점 잦아드는 것 같아 아쉽습니다. 패러다임이 바뀌는 혼란한 시기일수록, 기술 선택에 대한 질문을 멈추지 않고 나부터라도 다른 선택지를 실제로 써보는 시도를 해보면 좋겠다고 생각합니다.

💬. 의견 2

(리액트를 기본 라이브러리로 쓰시는 분들께) 리액트를 사용하시는 이유가 무엇인가요? 리액트를 사용하면서 불편한 점은 무엇인가요?
-> 저는 리액트보다는 Next에 굉장히 불편함을 느끼고 있는데요... Next와 vercel에 종속적으로 만들고, 자신들의 규칙을 생태계의 규칙인 것처럼 보이게 만드는 게 좀 싫더라구요. 특정 버전에서 메모리 누수 이슈들도 계속 발견됐었고, 보안 취약점도... ㅜ_ㅜ 여러모로 좀 까다롭습니다. 리액트는 컴파일러 나오고 나서 제가 갖고있던 불만이 살짝 내려갔어요 (정확한 성능측정은 아직 많이 안해봤지만!)

(리액트를 기본 라이브러리로 쓰시지 않는 분들께) 리액트를 언젠가 배워야 한다고 느끼시나요?
-> 저는 개발경력의 초반을 vue를 쓰면서 보냈는데요~! 사실 아주 직관적이고 읽기 쉬운 코드라고 생각했어요 리액트에 비해 ㅎㅎ 그래서 Vue가 다른 직군에도 선호되었던게 아닌가..라는 생각을 했고, 생각보다 성능도 괜찮게 나왔었어요. 알아야 될 것도 상대적으로 적고(프레임워크 단에서 많이 해주어서)!
그런데 그 당시, 아직은 뷰를 쓰고 있는 곳도 있었음에도 채용시장에서 뷰를 쓰는 개발자를 참 비선호하더라구요. 그래서 리액트로 갈아타고 마음의 평안을 찾았었습니다........ 그래도 뷰에 대해 항상 좋은 인상은 남아있어요. 넘어와서 큰 생태계를 맛보며 다신 돌아가진 않았지만 ㅎㅎ

리액트 외의 다른 라이브러리를 도입해 본 경험과 후기가 있다면 알려주세요.
-> 경력 초반 이후로는 없지만 최근 저는 Tanstack start를 써보고 싶다는 생각을 하고는 있어요. 회사 내에 다른 팀 몇몇 분들이 쓰시는데, 성능이 좀 더 확실히 잘 나오는 것 같고 코드도 깔끔해보이는 느낌이....
그리고 앵귤러를 잠깐 써봤는데(마이그레이션하느라) 신입 때 앵귤러로 시작하면 타입스크립트를 잘 배울수있겠다~, 코드 양이 많다~ 라는 느낌을 받았습니당.

목차

• 혁신의 천장

• 우리 모두가 짊어지고 있는 기술 부채

• 숨이 막혀가는 프레임워크들

• 네트워크 효과의 감옥

• 네트워크 효과 탈출하기

• 프레임워크 평가 체크리스트

• 흔한 반론들

• 더 넓은 생태계에 끼치는 해악

• 우리가 가꿀 수 있는 정원

글 링크: https://velog.io/@typo/80-problem-in-agentic-coding

소개

AI 에이전트가 코드의 대부분을 작성하는 시대, 개발자의 역할은 어떻게 바뀌고 있을까요? 이 글은 “생산성 향상” 그 이면에 숨은 이해 부채와 리뷰 병목, 그리고 “오케스트레이터”로 변해가는 엔지니어의 역할을 다룹니다. 최근 에이전트 코딩을 쓰면서 한 번쯤 느껴봤을 감각들을 꽤 현실적으로 잘 풀어낸 글이었는데요. 한 번씩 가볍게 읽어보시면 좋을 것 같습니다 🧑‍💻

목차

• 실수의 형태가 바뀌었습니다

• 이해 부채 - 우리가 따로 세지 않는 숨은 비용

• 생산성 역설 - 더 많은 코드, 비슷한 처리량

• 8:2 비율이 통하는 경우

• 서로 다른 두 집단

• 명령형에서 선언형으로 - 진짜 레버리지

• 슬로파칼립스는 올 것인가

• 실제로 통하는 실전 패턴

• 불편한 진실 - 스킬 개발에 대하여

• 우리는 지금 어디에 서 있는가

• 회의론자에게(회의적인 건 맞다)

글 링크: https://velog.io/@typo/name-your-effects

소개

React 개발자라면 useEffect는 너무(x101) 익숙한 함수입니다. 하지만 useEffect 함수에 이름을 붙여 본 개발자의 비율은 얼마나 될까요? 생각해보면 effect에 이름을 못 붙일 것도 없는데 우리는 너무 자연스럽게 익명함수를 사용하고 있습니다. 그런 코드를 바탕으로 학습되다보니 에이전트도 당연하게 익명함수로 effect 코드를 생성하고 있네요! 이 글은 저자가 effect 함수에 이름을 붙인 후 느꼈던 변화를 공유합니다.

팀원들의 의견

이 글을 보고 회사 팀원들에게 공유했었는데요. 자율적으로 해보자는 의견이 나와서 저도 조금씩 추가해보고 있습니다. 이름을 붙일 때의 장점이 많은 것 같은데 왜 당연하게 안했을까요 ? ㅎㅎ 다들 어떻게 작업하시나요?

💬 알고는 있었지만 저는 실무에서는 관성적으로 익명 함수를 사용해왔던 것 같습니다. 협업과 코드 리뷰의 관점에서 본다면, useEffect 내 함수에 이름을 붙이는 행위 자체가 코드 리뷰시에도 꽤나 도움이 될 것 같네요! 특히 AI가 짠 코드의 맥락을 빠르게 파악해야 하는 요즘 상황에서 더욱 의미 있는 제안인 것 같고, AI와 협업 관점에서도 기명 함수가 AI에게 좀 더 의도를 전달할 수 있을 것 같아서 결과에서도 유의미한 차이를 만들 수 있지 않을까 싶네요 🤔

💬 useEffect… 안쓰고 싶지만… 어쩔 수 없이 하나라도 사용하게 되면 확실히 데이터 흐름이 너무 복잡해져서 기명 함수 괜찮은 것 같아요

💬 저는 커스텀 훅으로 분리할 정도의 복잡도나 책임은 아닌데 컴포넌트에서 그대로 읽기에는 조금 복잡하다 싶은 이 애매한 영역에 있을 때 기명함수로 쓰는 편이에요!

목차

• 익명 이펙트 함수의 문제

• 이름을 붙이면 과도한 책임이 보입니다

• 필요 없는 이펙트는 이름에서부터 알 수 있습니다

• 이름 붙이기 vs 커스텀 훅

• 이펙트 5개가 3개가 됐습니다

• 참고 자료

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

소개

자바스크립트에서 시간을 다뤄 보셨다면 시간대로 인해 골치 아팠던 경험이 한 번쯤은 있으셨을 것입니다. 특히 글로벌 서비스를 다루는 제품을 만드신다면 더욱 그럴 것 같은데요. Temporal의 등장으로 여러분들의 시간 관련 기능 구현에 도움이 되기를 바라며 이 글을 번역하게 되었습니다.

목차

• 문제

• 시간과 시간대

• 항상 UTC를 사용하세요

• Temporal을 소개합니다

• 시간대를 주의하세요

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

소개

startTransition은 이름은 많이 들어봤지만, 막상 “언제 써야 하는가?”를 명확하게 설명하기는 쉽지 않은 API입니다. 이번 글은 setState가 호출된 뒤 리액트가 어떤 과정을 거쳐 렌더링을 수행하는지부터 시작해, startTransition이 실제로 어떤 역할을 하는지 차근차근 풀어냅니다.

핵심은 모든 상태 업데이트가 같은 우선순위를 가지지 않는다는 점입니다. 사용자의 입력처럼 즉시 반응해야 하는 업데이트와, 대규모 리스트 렌더링처럼 잠시 미뤄도 되는 업데이트를 구분하면 UI의 반응성을 훨씬 자연스럽게 유지할 수 있습니다. startTransition은 바로 이 “조금 늦어도 되는 작업”을 리액트에게 알려주는 방법입니다.

AI 스트리밍, 검색 필터링, 무거운 탭 전환, SPA 라우팅처럼 실제로 체감 성능에 큰 영향을 주는 사례를 통해 startTransition이 왜 필요한지 이해할 수 있습니다. 디바운스, requestIdleCallback과의 차이까지 함께 정리되어 있어, 막연하게 알고 있던 개념을 실전 감각으로 연결해볼 수 있는 글입니다.

팀원들의 의견

리액트로 개발할 때 startTransition 또는 useTransition을 사용하시는 편인지 궁금해요!

💬. 저는 디자인 시스템 개발 과정에서 입력 필드와 리스트 를 함께 보여주는 검색 영역 개발에서 사용했었어요! 대용량 데이터 리스트를 필터링이 가능한 컴포넌트에 사용되었습니다. 사전 fetch 후 저장된 원본 리스트를 필터링하는 기능이었는데요. useTranstition을 사용해서 업데이트를 지연해서 렌더링 부하를 막은 적이 있었고, UX를 고려해서 useTransition의 첫 번째 응답값으로 pending 상태 값을 사용해 필터링 중 로딩 스피너 처리 경험이 있어요. 그 외에도 상태를 동시다발적으로 업데이트 되어야하는 케이스에서도 부분 지연 처리해서 사용했던 경험도 있었습니다. 생각보다 흔하게 사용되는 훅은 아니었지만 경우에 따라서는 훅하나로 간단한 성능 최적화가 가능하다보니 유용하게 사용하는 편이에요🙇‍♂️

💬. 제 경우에는 startTransition과 같은 기능들을 알면서도, 습관적인 패턴들 때문에 실제 적용하는 사례는 많지 않았던 것 같네요 😢

목차

• 소개

• startTransition 없이 리액트가 렌더링하는 방식

• startTransition의 실제 역할

• 리액트가 렌더링을 중단해야 할 시점을 어떻게 알까

• 실제로 필요한 사용 사례

  • AI 스트리밍

• 대규모 리스트 필터링 또는 검색

• 대용량 콘텐츠가 포함된 탭 전환

• 단일 페이지 애플리케이션(SPA)에서의 탐색

• startTransition이 필요하지 않은 경우

• startTransition vs 디바운싱

• startTransition vs requestIdleCallback

• 한 문장으로 요약하면

글 링크: https://siosio3103.medium.com/번역-claude-code-memory-md-알아야-할-모든-것과-시작하는-법-144ce3ce166c

소개

Claude Code를 쓰다 보면 이전 대화 세션의 맥락을 기억해야 하는 경우가 있습니다. 다들 이런 문제를 해결하기 위해 claude code의 resume 기능을 사용하거나, docs 폴더에 문서화를 하기도 하고 claude-mem 같은 프로젝트의 도움을 받기도 합니다.

이번 글에서는 이와 같은 문제를 해결하기 위해 Claude Code에 새롭게 도입된 MEMORY.md 기반 자동 메모리 기능을 살펴봅니다. 이 기능이 기존 CLAUDE.md와 어떻게 다른지, Claude가 어떤 정보를 기억하고 어디에 저장하는지, 그리고 실제 작업 흐름에서 세션 간 컨텍스트를 얼마나 자연스럽게 이어주는지 중심으로 정리해보겠습니다.

이번 글은 특히 번역글도 좋지만, 저희 번역 팀원들의 의견도 꼭 한번 참고하시는 것도 좋을거같네요

팀원들의 의견

개인적으로는 세션간 히스토리를 기억하기 위해서 요 프로젝트를 사용을 했는데요. 이걸 번역하면서 작은 규모의 프로젝트는 memory.md로 충분하다는 생각도 들고 그러네요.

번역하면서 드는 질문이 두가지가 있는데

1. 여러분들은 클로드 세션간의 정보를 기억하기 위해 어떤 방법을 사용하나요? (claude resume ?, claude-mem?, docs 문서화?, MEMORY 기능?)

2. MEMORY.md는 팀단위로 공유하는게 좋을가요? 아니면 gitignore에 해놓고 각자 개인이 관리하는게 나을가요?

💬.
1번 질문에 대한 응답
저는 기존에는 제가 작업한 plan 문서를 git에서 관리하는 방식으로 주로 다뤘었는데, 이 글을 읽고 자동 메모리 기능을 써보아야겠다는 생각이 들었습니다.

2번 질문에 대한 응답
팀의 상황마다 다를 것 같아요. 공통된 작업을 여러 명이 하는 경우라면 MEMORY.md를 공유하는 편이 좋을 것 같으면서도, 각자 개별적으로 작업을 하는 상황이라면 굳이 공유할 필요는 없을 것 같습니다. 저는 현재 후자의 방식을 취하고 있습니다.

💬.
1번 질문에 대한 응답
저는 CC의 memory와 claude-mem을 활용해보고 있는데, 사실 memory가 꼭 필요하다고 느끼는 순간이 많지 않았습니다. 세션 컨텍스트를 유지하기 위한 용도라고 하지만, 오히려 컨텍스트가 넘치지 않도록 세션 자체를 길게 유지하지 않는 방향으로 관리하는 편입니다.

2번 질문에 대한 응답
MEMORY.md의 팀 공유 여부에 대해서는 마침 어제 팀에서 이야기를 나눴었는데요. 개인적으로는 메모리는 팀 단위로 관리할 필요가 없고, 오히려 회사에서 코딩할 때는 로컬에서도 꺼두고 작업하는 게 낫다고 생각합니다. 개인의 습관이나 지시들이 AI의 판단으로 메모리에 쌓이다 보면, 나도 모르게 팀의 컨벤션과 규칙을 따르지 않는 블랙박스가 생길 수 있다고 봅니다. 각 규칙들에 우선순위가 있더라도 컨텍스트에 들어갔을때 영향을 주는 부분을 찾기 어려운건 동일하다 생각하거든요.

결국 우리는 AI로 코드를 자동 생성하는 방향으로 나아가고 있고, 린트 룰과 포맷터 규칙을 만들었던 것처럼 생성되는 코드가 마치 한 사람이 작성한 것처럼 일관되길 바랍니다. 그 방향을 방해하는 요소는 과감히 쓰지 않는 게 좋다고 생각합니다.

💬.
1번 질문에 대한 응답
저는 handoff를 쓰거나 resume정도만 쓰고있었어요! 필요한 내용은 스킬로 만들어두고 쓰고있었습니당 따로 메모리 관리를 잘 하진 않았던 것 같아요~!

2번 질문에 대한 응답
개인적으로 중앙 모델이 아주 빠르게 좋아지고 있는 상황에 제가 제 방식을 (팀 내 컨벤션, 스킬 등 제외) 계속 컨텍스트로 넣는게 맞는것인가.. 라는 고민을 계속 하고있어요! 저희는 .claude 내의 내용들은 각자 개인이 관리하도록 일단은 하고있습니당!


💬.
1번 질문에 대한 응답
저는 주로 claude resume 과 claude-mem 을 사용하고 있습니다. 그리고 세션이 길어지면 길어질수록 응답 품질이 떨어지는 경향이 있더라구요. 그래서 세션자체를 길게 유지하지는 않는 편입니다.

2번 질문에 대한 응답
MEMORY.md 를 형상관리에 포함시킬 경우 다른 분들의 작업 내용과 관계된 컨텍스트까지 포함될 것으로 보아 따로 git에 올리기 보다는 개인용 작업 메모리로 사용하는 편이 괜찮지 않을까 하는 의견입니다!

💬.
1번 질문에 대한응답
저는 기존에 claude resume만 주로 사용하고 꼭 필요한 컨텍스트만 따로 적어두는 식으로 사용했는데, 아무래도 resume은 단기 이어쓰기용이라 한계가 있으니 auto memory 기능을 기본으로 켜두고 중요한 컨텍스트만 따로 CLAUDE.md나 claude-mem 등으로 관리하는게 좋겠다는 생각이 드네영

2번 질문에 대한 응답
MEMORY.md에는 아무래도 개인적인 경험이나 실험등이 섞일 것 같아서 우선은 .gitignore에 두고, 검증된 내용들에 한해서 CLAUDE.md 등에 기입해두는게 좋을 것 같다는 생각입니다!

목차

• Claude Code의 자동 메모리는 어떻게 동작할까?

• 자동 메모리는 어디에 저장될까?

• 200줄 제한 이해하기

• CLAUDE.md와 MEMORY.md의 차이는 무엇일까

• Claude Code 메모리 계층 구조 이해하기

• Claude는 세션 시작 시 무엇을 로드할까?

• Claude Code 자동 메모리 실전

• Claude 자동 메모리 제어하기

글 링크: https://ykss.netlify.app/translation/2026/what-to-know-in-js-2026/

소개

새로운 기능을 구현할 때 별다른 고민 없이 npm install부터 실행하는 경우가 많습니다. 하지만 우리가 의존하는 수많은 외부 패키지들은 관리의 복잡성을 높일 뿐만 아니라, 때로는 프로젝트의 성능과 유지보수에 예상치 못한 걸림돌이 되기도 합니다.

오늘 소개할 글은 2026년 현재, 자바스크립트 생태계에서 라이브러리 없이도 충분히 구현 가능한 “모던 자바스크립트 로드맵”을 다루고 있습니다. 특히 복잡한 날짜 계산을 네이티브로 처리하는 Temporal API나, 리액트 19의 Actions 패턴 등은 추가적인 패키지 설치 없이도 코드의 순수성을 유지하며 성능을 높일 수 있다는 점에서 꽤 인상적입니다.

거창한 솔루션을 고민하기 전에, 우리 프로젝트를 좀 더 가볍고 탄탄하게 다져볼 수 있는 실무적인 가이드로 가볍게 읽어보시면 좋을 것 같아 공유드립니다!

팀원들의 의견

이번 아티클에서 다룬 Temporal API, Actions, 그리고 새로운 네이티브 메서드(Set, groupBy) 등 자바스크립트 생태계의 변화들 중 실무에서 이미 유용하게 체감하고 계시거나, 혹은 AI와 협업하며 의도적으로 도입해 보신 패턴이 있으신가요? 특히 기존 라이브러리를 대체할 만큼 강력하다고 느끼신 부분이 있으신지 궁금합니다!

💬. 최근 유닛 테스트를 작성하며 Node.js 내장 node:test 모듈을 도입해 보았습니다. 기존 테스트 러너와 사용법이 크게 다르지 않으면서도, 불필요한 의존성과 설정을 획기적으로 줄일 수 있어 만족스러웠습니다. 최근 외부 라이브러리에 의존하던 기능들이 내장 모듈로 빠르게 전환되는 추세인데, 이는 유지보수와 보안성 측면에서 매우 바람직한 방향이라고 생각합니다.

💬. 저는 Temporal API의 등장이 가장 반가웠습니다. 기존 dayjs를 사용할 때는 매번 utc 플러그인을 확장(extend)하거나, 비슷해 보이는 문법들의 미묘한 의미 차이 때문에 혼란을 겪을 때가 많았습니다. 그렇다고 네이티브 Date 객체를 쓰기엔 로직이 너무 장황해져 고민이었는데, Temporal API가 표준으로 안착한다면 복잡한 설정 없이도 깔끔하게 날짜 로직을 구현할 수 있을 것 같아 적극적으로 도입해 볼 계획입니다.

목차

• 언어의 새로운 기능

• 프레임워크의 새로운 기능

• 자바스크립트 런타임

• 빌드 도구

• TypeScript

• 테스팅

• 메타 프레임워크

• npm

• 무엇을 배워야 할까?

글 링크: https://bit.ly/4d5VJ9Z

소개

외부 패키지를 설치할 때 별다른 의심 없이 npm install을 실행하는 경우가 많은데요. 하지만 올해 3월, axios가 침해되어 악성 버전이 npm에 배포되었고 4시간 동안 수많은 개발자들에게 노출되었습니다. 화려한 보안 도구 없이도 이를 막을 수 있는 방법이 있었다면 어떨까요?

오늘 소개할 글은 패키지 매니저 설정에 단 한 줄을 추가하는 것만으로 공급망 공격의 상당수를 차단할 수 있다는 “최소 릴리스 기간(Minimum Release Age)” 전략을 다루고 있습니다. 조사된 21건의 주요 공급망 침해 사례 중 절반 이상이 이 설정 하나로 막을 수 있었을 것이라는 분석은 꽤 인상적입니다.

최근 들어 공급망 보안 사고가 부쩍 잦아지는 가운데, 이처럼 진입 장벽 없이 바로 시도해볼 수 있는 방어 수단이 있다는 게 반가웠습니다. 기업용 솔루션이나 복잡한 파이프라인 구성 없이도, 지금 당장 팀의 보안 태세를 한 단계 높일 수 있는 방법으로 좋은 것 같아 공유드립니다.😄

팀원들의 의견

최근 Axios 사태로 바쁜 하루를 보내셨나요? 혹시 주의깊게 신경쓰는 버전, 보안 정책이 있나요?

💬. 저희 팀은 다행히 올해 초부터 아티클에 소개된 최소 릴리스 기간 기능을 활용해 패키지 설치 유예 기간을 두고 있어서 직접적인 영향 없이 넘어갈 수 있었습니다. 다만 최근에는 AI Agent 활용 비율이 높아지면서 MCP 서버나 프롬프트를 통한 악성 프롬프트 인젝션 같은 공격 양상도 등장하고 있고, 점점 사람이 개발 과정의 모든 단계를 직접 확인하지 않는 방향으로 나아가고 있느니만큼 패키지 보안뿐 아니라 AI 도구 체인 전반에 대한 경각심도 함께 가져야겠다는 생각이 듭니다.

💬. Axios 취약점 이후 버전 고정과 audit을 통한 주기적인 체크를 병행해 왔지만, 실시간으로 변하는 의존성 생태계에서 버전을 완전 통제하는 것은 어려울것 같다고 느끼고 있었습니다. 이번에 알게 된 minimumReleaseAge 를 적용하면 취약한 버전에 대해 어느 정도는 선제적으로 대응할 수 있다고 생각되어 바로 적용할 예정입니다! 🚀

목차

• 실제로 얼마나 효과적일까요?

• 방법론에 대한 참고 사항

• 왜 이렇게 효과적일까요?

• 언제 효과적이고, 언제 불편할까요?

• 그럼 어떻게 설정하나요?

• 자바스크립트 이외의 생태계

• 의존성 봇도 잊지 마세요

• 이 방법으로 잡을 수 없는 것들

• 생태계의 절반은 여전히 무방비 상태

• 이름이라도 통일할 수 있을까요?

• 왜 기본값이 아닐까요?

글 링크: https://velog.io/@superlipbalm/goodbye-innerhtml-hello-sethtml-stronger-xss-protection-in-firefox-148

소개

웹 개발을 하면서 사용자가 입력한 콘텐츠를 DOM에 주입할 때 innerHTML을 사용해 보신 적이 있으실 겁니다. 가장 직관적이고 간편한 방법이지만, 의도치 않은 자바스크립트나 악성 HTML이 실행될 수 있는 XSS(교차 사이트 스크립팅) 공격에 무방비하게 노출된다는 치명적인 단점이 있었습니다.

오늘 소개할 글은 이러한 프론트엔드 개발자들의 오랜 고민을 해결해 줄 새로운 웹 표준인 Sanitizer API와, 이를 브라우저 최초로 탑재한 Firefox 148의 소식을 다루고 있습니다.

이제는 별도의 무거운 서드파티 라이브러리나 복잡한 정책 설정 없이, 최소한의 코드 변경만으로 XSS 공격을 방어할 수 있게 되었는데요. 조만간 다른 주요 브라우저들로도 확대될 이 새로운 기능을 미리 살펴보는 것은 어떨까요?

글 링크 : https://ykss.netlify.app/translation/2026/use-sync-external-store/

소개

이 글은 리액트의 useSyncExternalStore가 해결하고자 하는 핵심 과제, 즉 외부 상태와 리액트 렌더링 사이클 사이의 데이터 정합성을 깊이 있게 다룹니다. 단순히 API 사용법을 넘어, 왜 기존의 useEffect 방식이 복잡한 상태 관리에서 ‘Tearing(화면 찢어짐)’ 현상을 유발할 수밖에 없는지 그 기술적 근본 원인을 명확히 짚어줍니다.

특히 데이터 일관성을 유지하기 위한 리액트의 엄격한 설계를 이해하는 것은 예측 가능한 UI를 만드는 데 필수적입니다. 라이브러리 제작자부터 전역 상태 관리를 고민하는 개발자까지, 리액트의 동기화 철학을 체득하여 애플리케이션의 ’상태 주권’을 어떻게 확보할 수 있는지 확인해 보시길 추천드립니다. ⚛️

목차

• useSyncExternalStore는 왜 존재하나요? “테어링(tearing)” 문제

• API 살펴보기

• 예시: 온라인 상태 추적 (브라우저 API)

• 자주 하는 실수, 주의 사항, 그리고 올바른 사용법

• 보너스: 재사용 가능한 useMediaQuery 훅

• 트러블슈팅 체크리스트

• 마무리