figma·2026년 8월 13일·3분 읽기큐레이션 요약

올바른 방향으로 빠르게 나아가는 방법 | Figma 블로그

AI는 소프트웨어 제작 속도를 크게 높였지만, 빠른 실행이 곧 올바른 제품을 의미하지는 않는다. AI가 만든 결과물을 그대로 받아들이면 기술 부채가 늘고, 평균적인 디자인과 기능에 머물 수 있다. 따라서 좋은 팀은 먼저 무엇을 만들지 충분히 고민하고, 명확한 맥락과 시스템을 제공한 뒤, 자신만의 관점으로 결과물을 다듬어야 한다. ## AI는 실행을 가속하지만 판단을 대신하지 못한다 - AI는 짧은 프롬프트만으로도 완성도 높아 보이는 프로토타입과 코드를 만들어낸다. - 그러나 겉보기의 완성도는 내부 구조, 제약 조건, 시스템 동작 방식까지 올바르다는 뜻이 아니다. - 과거에는 결과물의 세련됨 뒤에 전문가의 의사결정과 트레이드오프가 있었지만, 이제는 AI가 그 빈틈을 임의로 채울 수 있다. - **인지적 항복(cognitive surrender)**은 AI의 출력을 검토 없이 자신의 판단처럼 받아들이는 현상이다. - 첫 번째 결과물이 그럴듯하다는 이유로 바로 출시하지 말고, 문제의 본질과 실제로 만들 가치가 있는 것을 먼저 정의해야 한다. 글에서는 이를 **고려의 의무(consideration imperative)**로 표현한다. ## 맥락과 의도를 먼저 제공해야 한다 - 에이전틱 엔지니어링에서는 개발자의 역할이 코드를 직접 작성하는 것에서 **의도를 명확히 표현하고 검증하는 것**으로 이동한다. - Google의 관련 백서는 다음 요소를 중요한 기반으로 제시한다. - **결정론적 계층**: 테스트, 타입 검사, 검증처럼 매번 동일하게 실행되며 AI의 오류를 잡는 장치 - **고신호 맥락**: 명세, 문서화된 컴포넌트, 설계 원칙 등 에이전트가 의도를 정확히 이해하도록 돕는 정보 - **명확한 인터페이스**: 시스템 각 부분이 어떻게 연결되는지 에이전트가 추측하지 않도록 정의한 계약 - 디자인에서 코드로 전환할 때도 에이전트가 실제 프로덕션 컴포넌트의 구조를 모르면 픽셀을 보고 임의로 재구성할 가능성이 높다. - Figma MCP의 Code Connect처럼 실제 컴포넌트의 코드, props, variants를 제공하면 에이전트가 기존 시스템에 맞는 결과를 만들 수 있다. - 강력한 디자인 시스템은 결정 사항을 재사용 가능한 어휘와 가드레일로 codify해 결과물의 일관성을 높이고 코드와 기술 부채를 줄인다. - 초기에는 명세와 시스템을 준비하는 데 더 많은 시간이 들지만, 장기적으로 유지보수 비용을 낮춘다. ## “괜찮은 결과”는 쉽게 평균이 된다 - AI 모델은 방대한 기존 데이터를 학습했기 때문에 이미 널리 사용된 패턴과 스타일, 즉 **분포 안의 평균적인 결과**를 생성하는 경향이 있다. - 예를 들면 다음과 같은 결과가 반복될 수 있다. - 로고: 단순한 기하학적 형태와 그라디언트 - 발표 자료: 흔한 산세리프 글꼴과 익숙한 레이아웃 - React 컴포넌트: 둥근 모서리의 전형적인 카드 UI - 이런 결과는 틀리지는 않지만 차별성이 부족하다. - AI가 만든 “충분히 좋은” 결과를 반복해서 받아들이면 사용자의 판단 기준이 좁아지고, “무엇이어야 하는가?”보다 “덜 나쁜 선택은 무엇인가?”를 고르게 된다. - AI의 품질이 향상될수록 개인이 과거보다 나은 결과를 만들 수 있지만, 동시에 다른 AI 생성물과 비슷해질 위험도 커진다. ## 제품의 관점은 사람이 결정해야 한다 - AI는 실행과 변형을 빠르게 수행할 수 있지만, 제품의 목적과 차별화된 방향까지 자동으로 결정하게 두어서는 안 된다. - 명확한 의도와 평가 기준이 없으면 모델이 기본값과 평균적인 패턴을 대신 선택한다. - 팀은 AI가 제시한 결과를 출발점으로 활용하되, 왜 이 기능과 디자인이 필요한지, 누구를 위한 것인지, 무엇이 달라야 하는지를 직접 판단해야 한다. - 결국 속도의 핵심은 첫 결과물을 빨리 내는 것이 아니라, 명확한 맥락과 검증 장치를 통해 **올바른 방향으로 빠르게 반복하는 것**이다. AI를 활용할 때는 프롬프트 작성보다 먼저 목표, 제약 조건, 성공 기준을 문서화하는 것이 좋다. 테스트·타입 검사·디자인 시스템·명확한 인터페이스를 갖추고, AI 결과물을 반드시 사람의 관점과 제품 기준으로 검토해야 평균적인 결과와 기술 부채를 피할 수 있다.

원문 읽기(새 탭에서 열림)

ReactAI디자인 시스템대규모 언어 모델+3

toss·2026년 8월 10일·5분 읽기큐레이션 요약

모노리포 희망편, 절망의 리포가 희망의 리포로 부활하기까지 걸린 1년

토스는 100명 이상의 프론트엔드 엔지니어가 여러 제품을 개발하면서도 React 19, Next.js 15 등 동일한 개발환경을 유지하기 위해 모노리포와 의존성 카탈로그를 활용하고 있습니다. 단순히 모노리포를 사용하는 것만으로는 서비스별 의존성 버전 파편화와 느린 설치 속도 문제를 해결할 수 없었기 때문에, 핵심 라이브러리 버전을 표준화하는 카탈로그 전략을 도입했습니다. 그 결과 의존성 규모와 설치 시간이 크게 줄었고, 플랫폼 변경과 최신 기술 도입도 더 안전하고 빠르게 진행할 수 있게 되었습니다. ## 모노리포가 제공한 개발 일관성 - 토스의 모바일 제품 코드는 하나의 모노리포로 통합되어 있습니다. - 모든 서비스가 React, Next.js, TypeScript, 번들러, Linter 등 유사한 버전을 사용하도록 관리되었습니다. - 이를 통해: - React Concurrent Mode, React Server Components 같은 최신 기능을 여러 서비스에서 활용할 수 있습니다. - 서비스 간 공통 코드와 플랫폼 라이브러리를 쉽게 공유할 수 있습니다. - 플랫폼 변경사항을 전체 서비스에 일관되게 전파할 수 있습니다. - 제품이 많아도 동일한 개발환경을 유지해 사용자 경험과 개발자 경험을 함께 개선하는 것이 목표였습니다. ## 모노리포만으로 해결되지 않은 문제 - 서비스마다 React와 각종 라이브러리의 버전이 달라 의존성 트리가 복잡했습니다. - 오래된 서비스는 낡은 개발환경을 계속 사용하게 되어 개발 서버 속도와 API 사용성에서 큰 차이가 났습니다. - 의존성 종류와 버전이 많아 설치에 캐시가 있어도 1분 이상 걸리는 경우가 있었습니다. - 플랫폼 팀은 다양한 React 및 라이브러리 조합을 모두 테스트해야 했기 때문에 공통 라이브러리 변경이 어려웠습니다. - 서비스 개발자도 업데이트 후 문제가 발생할 가능성을 우려해 플랫폼 라이브러리 업데이트를 기피했습니다. - 결과적으로 오래된 의존성이 고착되고, 서비스와 플랫폼 양쪽의 유지보수 비용이 커졌습니다. ## 폴리리포의 한계 - 모노리포를 여러 개의 독립적인 리포지토리로 나누면 각 저장소의 의존성과 설치 부담은 줄어듭니다. - 그러나 다음 문제는 오히려 남거나 심해질 수 있습니다. - 서비스별 개발환경 파편화 - 공통 코드 공유와 업데이트 비용 증가 - 서비스마다 다른 개발 경험 - 플랫폼 변경사항의 일관된 전파 어려움 - 토스는 지속적으로 플랫폼을 유지보수하고 최신화해야 하므로, 폴리리포보다는 기존 모노리포의 의존성 문제를 해결하는 방향을 선택했습니다. ## 핵심 해결책: 의존성 버전 표준화 - 가장 근본적인 문제를 “서비스마다 핵심 의존성 버전이 모두 다르다”는 점으로 정의했습니다. - React, 컴포넌트 라이브러리(TDS), 상태 관리 라이브러리(Jotai), TypeScript, ESLint 등 약 10~20개의 주요 라이브러리를 표준화 대상으로 삼았습니다. - 핵심 의존성 버전을 통일하면: - 설치해야 할 의존성의 종류와 개수가 줄어듭니다. - 모든 서비스에서 비슷한 개발 경험을 제공합니다. - 플랫폼 라이브러리의 테스트 환경이 단순해집니다. - Breaking change에 대응하는 코드 변환 스크립트나 호환성 레이어를 만들기 쉬워집니다. - 서비스 개발자가 검증된 최신 라이브러리로 업데이트할 유인이 커집니다. - 대부분의 개발자는 “React가 필요하다”고 결정할 뿐 특정 버전을 직접 선택할 필요는 없다는 점도 표준화의 근거가 되었습니다. ## 카탈로그를 통한 버전 관리 - 토스는 서비스에서 권장하는 표준 라이브러리 버전 집합을 **카탈로그(Catalog)**라고 정의했습니다. - pnpm이나 Yarn의 카탈로그 기능을 사용해 모노리포의 공통 버전을 선언합니다. ```yaml catalog: react: ^18.2.0 jotai: ^2.18.1 ``` - 각 서비스는 `catalog:` 프로토콜로 버전을 참조합니다. ```json { "dependencies": { "react": "catalog:", "jotai": "catalog:" } } ``` - 안정 버전과 실험 버전을 별도 카탈로그로 관리할 수도 있습니다. ```yaml catalogs: stable: react: ^18.2.0 jotai: ^2.18.1 beta: react: ^19.1.0 jotai: ^2.20.1 ``` - 이후 서비스는 `catalog:stable`처럼 특정 카탈로그를 선택할 수 있습니다. - React, Next.js, TypeScript, TDS, 토스 앱 SDK 등 핵심 개발 라이브러리부터 카탈로그에 편입했습니다. ## 카탈로그 도입과 운영 방식 - 카탈로그 패키지는 릴리즈 전에 주요 사용 사례를 테스트 페이지로 검증했습니다. - 신규 서비스는 최신 카탈로그를 자동으로 참조하도록 스캐폴딩했습니다. - 개발자가 `yarn add`로 직접 패키지를 추가해도 카탈로그 버전을 사용하도록 했습니다. - 실수로 카탈로그를 사용하지 않는 경우를 CI에서 자동 검출했습니다. - 기존 서비스는 코드 오너와 함께 의존성을 카탈로그 참조 방식으로 일괄 마이그레이션했습니다. - 카탈로그 버전을 변경할 때는 기존 카탈로그를 직접 수정하지 않고 새 버전을 발행했습니다. - 일부 서비스에서 먼저 검증 - 안정성 확인 - 전체 서비스가 새 카탈로그로 수동 마이그레이션 - 업그레이드 비용을 낮추기 위해 코드 수정 스크립트와 AI Skill도 제공했습니다. ## 카탈로그 적용 후의 성과 - 서비스별 의존성 버전이 통일되면서 전체 의존성 규모가 크게 감소했습니다. - Yarn PnP의 `.pnp.cjs` 파일 크기: - 96MB → 15MB - 약 84% 감소 - 개발 서버 실행 시간: - 26.7초 → 20.3초 - 약 23% 개선 - 전체 의존성 설치 시간: - 528.4초 → 249.9초 - 약 52% 감소 ## 검증된 의존성과 구조적 개선 - 카탈로그에 포함된 패키지는 최소 한 개 이상의 서비스에서 동작을 검증해야 하므로 사용 신뢰도가 높아졌습니다. - 패키지 간 의존성도 엄격하게 관리할 수 있게 되었습니다. - 예를 들어 A 패키지가 B의 v1에 의존하는데 서비스가 B의 v2를 사용하는 식의 불일치를 예방할 수 있습니다. - 어떤 서비스가 어떤 버전을 사용하는지 파악하기 쉬워져 패키지 개발자가 대규모 구조 개선을 추진하기 수월해졌습니다. - 그 결과 RSC, TypeScript 7, Rspack, E2E 테스트 같은 급진적인 기술 개선도 비교적 빠르고 안정적으로 도입할 수 있었습니다. - 플랫폼 패키지의 개선사항이 서비스에 전달되는 경로가 표준화되어, 서비스가 최신 플랫폼의 혜택을 더 빠르게 받을 수 있는 기반도 마련되었습니다. ## 실용적인 결론 모노리포의 효과를 극대화하려면 저장소를 하나로 합치는 것만으로는 부족합니다. 핵심 의존성의 버전을 카탈로그로 표준화하고, CI 검증·자동 마이그레이션·단계적 릴리즈를 함께 운영해야 서비스 간 일관성, 설치 성능, 플랫폼 업데이트 속도를 동시에 개선할 수 있습니다.

원문 읽기(새 탭에서 열림)

ReactTypeScriptmonorepodependency-management+3

figma·2026년 8월 5일·3분 읽기큐레이션 요약

더 나은 코드, 더 적은 토큰: MCP에서 Code Connect의 이점 | Figma 블로그

코딩 에이전트가 디자인을 코드로 변환할 때 Code Connect를 사용하면 실제 프로덕션 컴포넌트와 디자인 시스템을 더 정확히 활용할 수 있다. Figma MCP와 Code Connect를 함께 사용한 실험에서 작업 시간은 19.6%, 토큰 사용량은 29.5% 감소했고, 코드 품질은 1~4점 척도에서 1점 향상됐다. 즉, 시각적으로 비슷한 코드를 새로 만드는 대신 기존 컴포넌트를 직접 연결하면 더 빠르고 일관된 결과를 얻을 수 있다. ## 코딩 에이전트가 디자인 시스템을 잘못 구현하는 이유 - Figma MCP의 `get_design_context`는 캔버스의 디자인을 React 코드 형태로 설명한다. - Code Connect가 없으면 에이전트는 다음과 같은 문제를 겪을 수 있다. - 기존 컴포넌트 대신 새로운 컴포넌트를 직접 생성한다. - 디자인 시스템에서 잘못된 컴포넌트를 선택한다. - 올바른 컴포넌트를 찾더라도 검색과 수정에 불필요한 토큰과 시간을 사용한다. - 결과물은 시각적으로는 맞아 보여도 프로젝트의 실제 코드 구조나 디자인 시스템 규칙과 어긋날 수 있다. ## Code Connect가 MCP 응답을 보강하는 방식 - Code Connect는 Figma 컴포넌트와 코드베이스의 실제 컴포넌트를 연결한다. - 설정이 완료되면 MCP 응답에 일반적인 React 표현 대신 프로덕션 코드에 가까운 코드 스니펫이 포함된다. - 에이전트는 다음 정보를 직접 전달받는다. - 사용해야 할 컴포넌트의 import 경로 - 컴포넌트에 전달할 정확한 속성값 - 디자인 요소와 코드 컴포넌트 간의 대응 관계 - 예를 들어 Code Connect가 없으면 탭 UI를 여러 `<button>` 요소와 CSS 클래스로 재구성할 수 있다. - Code Connect를 사용하면 다음처럼 기존 디자인 시스템 컴포넌트를 바로 사용한다. ```tsx <SegmentedControl value="design" options={["Design", "Code"]} /> ``` ## Coinbase 사례 - Coinbase Design Systems 팀은 일관된 UI를 위해 핵심 컴포넌트, 디자인 토큰, 인프라를 관리한다. - 에이전트 기반 개발을 도입하면서 Code Connect를 적용해 에이전트가 CDS 컴포넌트를 재사용하도록 했다. - Code Connect가 없을 때는 에이전트가 스테퍼를 프로그레스 바 조합으로 임의 구현하는 등 컴포넌트를 잘못 추측할 수 있었다. - Code Connect를 사용하면 정확한 코드 표현과 실제 CDS 컴포넌트의 import 문을 확인할 수 있어 코드 품질이 향상되고 토큰도 절약됐다. ## Code Connect의 효과를 측정한 실험 - 동일한 디자인, 프롬프트, 모델을 사용해 Code Connect 적용 여부만 달리한 디자인-투-코드 작업을 비교했다. - 총 27개 테스트 케이스에서 다음 항목을 측정했다. - 코드 품질 - 토큰 사용량 - 작업 소요 시간 - React 기반 디자인 시스템 두 가지를 대상으로 했다. - Figma의 예제 디자인 시스템인 Simple Design System(SDS) - 더 규모가 크고 복잡한 내부 시스템인 Figma Pattern Library(FPL) - Code Connect 적용 결과: - 작업 시간 중앙값 19.6% 감소 - 토큰 사용량 중앙값 29.5% 감소 - 코드 품질 1~4점 Likert 척도에서 1점 향상 ## 실용적인 적용 방향 - 디자인 시스템의 핵심 컴포넌트에 Code Connect 템플릿을 우선 설정하는 것이 효과적이다. - 에이전트가 직접 HTML과 스타일을 조합하게 하기보다 실제 컴포넌트와 import 정보를 제공해야 한다. - 디자인 시스템을 사용하는 팀이라면 Code Connect를 단순한 인간 개발자용 문서화 도구가 아니라 에이전트의 코드 생성 품질과 비용을 개선하는 컨텍스트 계층으로 활용할 수 있다.

원문 읽기(새 탭에서 열림)

React디자인 시스템TypeScriptcode-connect+2

github·2026년 7월 30일·3분 읽기큐레이션 요약

GitHub Copilot 앱에서 세션과 풀 리퀘스트 쌓기

10년 넘은 React 15·Less·구버전 react-bootstrap 기반 프로젝트를 GitHub Copilot 앱으로 현대화한 경험을 소개합니다. 한 번에 전체를 바꾸려 하지 않고, 기존 작업을 세션과 브랜치별로 나누어 순차적으로 진행하는 “스택 세션” 방식이 핵심입니다. AI가 계획 수립, 코드 변경, PR 생성, 브랜치 전환까지 지원하면서 오래된 프로젝트의 대규모 유지보수를 현실적으로 수행할 수 있었다는 결론입니다. ## 오래된 프런트엔드 현대화의 어려움 - 개인용 대시보드 애플리케이션을 2014년경부터 운영해 왔습니다. - React 15, Less, 구버전 `react-bootstrap` 등 의존성이 수년간 업데이트되지 않았습니다. - 애플리케이션 규모가 아주 크지는 않지만, 구조가 충분히 복잡해 수작업으로 정리하려면 수주가 걸릴 상황이었습니다. - 과거에도 현대화를 시도했지만 호환성 문제 때문에 중단한 경험이 있었습니다. ## 첫 시도: 전체 현대화를 한 번에 진행하기 - Copilot의 Plan 모드에서 다음 작업을 요청했습니다. - Tailwind와 vanilla CSS 중 적절한 방식 검토 - Less 제거 - 접근성 및 반응형 개선 - 의존성 현대화 - React 기능의 점진적 정리와 통합 - 링크의 hover/focus 스타일 개선 - 입력 필드의 테두리 반경 축소와 라벨 정리 - 컨테이너 최대 너비와 적절한 줄바꿈 적용 - Claude Opus 4.8과 GPT-5.5의 검토를 거쳐 계획을 다듬은 뒤 실제 변경을 시작했습니다. - 그러나 처음부터 `main` 브랜치를 기준으로 작업한 것이 문제였습니다. AI가 충분히 좋은 계획을 세웠더라도, 현재 운영 중인 코드의 실제 기준 브랜치를 잘못 선택하면 결과가 실행되지 않을 수 있었습니다. ## 기존 `dev` 브랜치와의 충돌 발견 - 과거에 중단한 줄 알았던 현대화 작업이 실제로는 `dev` 브랜치에 일부 남아 있었습니다. - 현재 배포 환경은 `main`이 아니라 부분적으로 업데이트된 `dev` 브랜치를 사용하고 있었습니다. - 따라서 새 작업을 `main`에서 시작하면 기존 기능과 설정이 누락될 수 있었습니다. - 변경 규모가 커서 `dev`의 내용을 `main`으로 병합하기보다, 기존 PR을 닫고 `dev`에서 새 작업을 시작하는 편이 안전했습니다. - Copilot은 사용자의 지시에 따라: - 기존 세션의 PR을 닫고 - `dev`에서 새 브랜치를 만들고 - 기존 스타일·접근성 개선안을 새 기준에 맞게 다시 적용했습니다. ## 테스트 중 발견한 오래된 의존성 문제 - 스타일 변경 후 테스트하는 과정에서 `findDOMNode`, `componentWillReceiveProps` 관련 경고가 나타났습니다. - 문제의 상당 부분은 애플리케이션 코드가 아니라 오래된 `react-bootstrap`에 있었습니다. - Copilot의 Plan 모드에 다음 두 가지 선택지를 검토하게 했습니다. - `react-bootstrap`을 업그레이드해 기존 컴포넌트를 마이그레이션하기 - 라이브러리를 완전히 제거하고 현대적인 대체 구현으로 교체하기 - 분석 결과, 기존 라이브러리를 유지하기보다 전체 교체하는 방향이 권장되었습니다. ## 스택 세션과 분리된 pull request - `react-bootstrap` 교체는 기존 스타일·접근성 작업과 관련이 있지만, 범위가 크게 늘어나는 별도 작업이었습니다. - AI를 활용하면 구현 비용이 낮아 보여 여러 문제를 한 번에 해결하고 싶어지지만, 결과적으로 1만 줄 규모의 거대한 PR이 될 수 있습니다. - 이를 방지하기 위해 작업을 다음처럼 나눴습니다. - 먼저 현재 스타일·접근성 작업을 하나의 PR로 제출 - 해당 작업을 기반으로 새 세션과 브랜치를 생성 - 새 세션에서 `react-bootstrap` 교체를 별도 PR로 진행 - 첫 번째 PR을 `dev`에 병합한 뒤 두 번째 PR을 병합 - 이렇게 각 세션이 이전 세션의 결과 위에 쌓이도록 구성하면 작업 간 의존성은 유지하면서도 변경 범위와 검토 단위를 작게 만들 수 있습니다. ## 실용적인 결론 - AI에게 전체 프로젝트를 한 번에 현대화하게 하기보다, 기준 브랜치와 작업 범위를 먼저 확인하는 것이 중요합니다. - 스타일 개선, 의존성 교체, 기능 리팩터링을 각각 독립적인 세션과 PR로 나누면 테스트와 롤백이 쉬워집니다. - 특히 오래된 저장소에서는 현재 배포 브랜치가 무엇인지 확인한 뒤, 그 브랜치에서 새 세션을 시작하는 방식을 추천합니다.

원문 읽기(새 탭에서 열림)

React접근성TypeScriptgithub-copilot+4

line·2026년 7월 2일·4분 읽기큐레이션 요약

AI로 웹 엔지니어 없이 LINE 앱 안에서 그룹 영상 통화 서비스 만들기

LINE OA와 LIFF, LINE Planet SDK를 결합하면 별도 앱 설치 없이 LINE 안에서 그룹 영상 통화 서비스를 구현할 수 있다. 글에서는 LINE Planet 팀의 PM과 Android 엔지니어가 웹 엔지니어 없이 만든 사례를 바탕으로, LIFF 웹 앱과 액세스 토큰 발급용 앱 서버만 직접 개발하면 된다는 구조를 설명한다. LINE의 인증·WebRTC·글로벌 네트워크 인프라를 활용하므로 핵심은 각 컴포넌트를 연결하고 통화 흐름을 구현하는 것이다. ## LINE OA와 LIFF의 역할 - **LINE OA** - 사용자와 소통하는 접점이자 서비스 진입 채널이다. - 상담, 교육, 라이브 방송, 게임 음성 채팅 등 다양한 서비스를 제공할 수 있다. - **LIFF** - LINE 앱 내부 웹뷰에서 실행되는 웹 애플리케이션이다. - LINE 로그인 정보인 `userId`, `displayName` 등을 전달하므로 별도 인증 서버 없이 사용자를 식별할 수 있다. - **LINE Planet** - WebRTC 기반의 음성·영상 통화와 미디어 처리를 담당한다. - 글로벌 네트워크 인프라를 제공해 개발자가 통화 인프라를 직접 구축하지 않아도 된다. ## 구현해야 하는 전체 구조 - 직접 개발할 부분은 크게 두 가지다. - LIFF에서 실행되는 그룹 영상 통화 웹 앱 - LINE Planet 액세스 토큰을 발급하는 앱 서버 - 앱 서버는 Firebase Cloud Functions로 구성하면 별도의 서버 인프라 설정을 줄일 수 있다. - LINE OA와 LIFF가 사용자 인증을, LINE Planet이 미디어 통신을 처리하므로 개발자는 서비스 화면과 연결 로직에 집중할 수 있다. - 실제 구현 대상은 웹 앱 레이어와 서버 레이어의 앱 서버이며, LINE OA·LIFF·LINE Planet의 기반 기능은 외부 플랫폼을 활용한다. ## 적용 가능한 서비스 사례 - **전문 상담** - 변호사, 재무 설계사, 심리 상담사와의 1:1 화상 상담 - 별도 앱 설치 없이 LINE 앱에서 상담방 입장 - **원격 교육** - 수업 예약과 화상 수업을 LINE OA에서 제공 - 여러 강사가 동시에 독립적인 통화방 운영 가능 - 화면 공유를 이용한 문서·문제 풀이 지원 - **실시간 소통 방송** - 기본 500명에서 최대 1만 명까지 동시 참여 가능 - 팬미팅, 라이브 이벤트, 진행자와 청중이 대화하는 양방향 방송 구현 - **게임 음성 채팅** - LINE 친구와 게임 중 별도 앱 전환 없이 실시간 음성 대화 ## 개발 전 준비 사항 - **개발 환경** - Node.js 20 LTS 이상 - npm 기반 프로젝트 - LIFF 특성상 HTTPS 배포 필요 - 로컬 개발에서는 ngrok 같은 HTTPS 터널링 도구 사용 가능 - **LINE Developers 설정** - Business ID로 개발자 계정 등록 - Provider 생성 - LINE OA 생성 후 Messaging API 활성화 - 같은 Provider에 LINE Login 채널 생성 - LINE Login 채널의 LIFF 탭에서 LIFF 앱 등록 - **주의할 설정** - 발급된 LIFF ID를 이후 모든 초기화 과정에서 사용하므로 별도 보관해야 한다. - 친구 초대 기능인 `shareTargetPicker`를 사용하려면 LINE Login 채널이 `Published` 상태여야 한다. - **LINE Planet 준비** - LINE Planet Console 계정과 서비스 ID가 필요하다. - 해당 정보는 LINE Planet 팀에 요청해 발급받는다. ## 통화방 ID 설계 - 사용자가 통화에 입장하기 전에 방 ID를 생성하거나 URL에서 복원한다. - 데모에서는 `crypto.randomUUID()`에서 하이픈을 제거한 뒤 앞 16자리를 사용해 랜덤 방 ID를 만든다. - 초대 링크에 `roomId`가 포함되어 있으면 query string에서 해당 값을 읽어 같은 방에 입장한다. - 서비스 목적에 따라 다음과 같이 확장할 수 있다. - 관심사별 고정 방 - 사용자 그룹별 자동 방 생성 - 예약된 수업이나 상담 일정에 연결된 방 - 방 ID 자체만으로 권한을 판단하지 말고, 실제 서비스에서는 서버에서 접근 권한과 만료 여부를 검증해야 한다. ## `MediaStreamManager`를 활용한 미리보기 - 일반적인 웹 구현의 `getUserMedia` 대신 PlanetKit의 `MediaStreamManager`를 사용한다. - 미리보기 화면에서 생성한 MSM 인스턴스를 통화방 입장 후에도 재사용할 수 있다. - 이 방식의 장점은 다음과 같다. - 페이지 전환 시 카메라와 마이크 권한을 다시 요청하지 않음 - 모바일 웹뷰에서 권한 프롬프트가 반복적으로 노출되는 문제 완화 - 기존 미디어 스트림을 통화 연결 과정까지 유지 - 구현 흐름은 다음과 같다. - 컴포넌트 마운트 시 `MediaStreamManager`를 한 번 생성 - 비디오가 켜져 있으면 `createMediaStream()`으로 미디어 스트림 생성 - 이미 스트림이 있으면 `changeVideoInputDevice()`로 비디오 입력 장치만 교체 - 스트림을 HTML `<video>` 요소의 `srcObject`에 연결 - 마이크 끄기/켜기는 권한을 다시 요청하지 않고 오디오 트랙의 `enabled` 속성만 변경한다. ## 모바일 카메라 전환 처리 - 모바일 기기에서는 전면·후면 카메라 전환 기능을 제공할 수 있다. - `useIsMobileDevice`로 모바일 환경을 판별하고, 모바일에서만 전환 버튼을 노출한다. - `resolveFacingModeDeviceId`를 통해 `front` 또는 `back` 방향에 해당하는 카메라 장치 ID를 찾는다. - 카메라가 꺼진 상태에서는 전환 버튼을 비활성화해 불필요한 장치 변경을 막는다. - 데스크톱에서는 기본 장치를 사용하고, 모바일에서는 방향 기반 장치 선택을 적용한다. ## 데모 코드의 범위와 주의점 - 글의 코드는 핵심 흐름을 보여주는 데모 코드다. - 통화 셋업, 미리보기, 통화 화면의 세부 UI와 전체 사용자 경험은 직접 구현해야 한다. - 프로덕션 적용 전 다음 항목을 추가 검토해야 한다. - 액세스 토큰 및 방 접근 권한 보안 - 네트워크 오류와 권한 거부 처리 - 통화 종료 및 리소스 정리 - 모바일 브라우저별 호환성 - 성능 최적화와 사용자 상태 동기화 - 앱 서버에서는 LINE Planet 액세스 토큰을 안전하게 발급하고 클라이언트에 비밀 키가 노출되지 않도록 해야 한다. ## 실용적인 결론 LINE OA를 이미 운영 중이라면 LIFF와 LINE Planet을 조합해 상담·교육·방송 같은 실시간 서비스를 빠르게 확장할 수 있다. 초기 구현은 랜덤 방 ID, `MediaStreamManager` 기반 미리보기, Firebase Cloud Functions 기반 토큰 서버로 단순화할 수 있지만, 실제 출시 단계에서는 방 권한 검증과 토큰 보안, 모바일 환경의 예외 처리를 반드시 보강해야 한다.

원문 읽기(새 탭에서 열림)

ReactTypeScriptnode.jswebrtc+4

figma·2026년 7월 1일·4분 읽기큐레이션 요약

Canvas 기반 제품에 접근성 구축하기 | Figma 블로그

Figma는 캔버스 렌더링으로 무한 줌과 실시간 협업 같은 성능을 얻었지만, 브라우저의 기본 접근성 기능을 사용할 수 없게 되었다. 이를 해결하기 위해 디자인의 scenegraph를 기반으로 접근성 정보를 담은 내부 트리와 이를 반영하는 Mirror DOM을 구축했다. 그 결과 스크린 리더 사용자는 Figma 파일을 탐색·편집하고, 캔버스 선택 상태와 키보드 탐색을 연동하며, 비시각적 변경 사항도 안내받을 수 있다. ## 캔버스 기반 제품의 접근성 문제 - Figma 캔버스는 일반 HTML/DOM 대신 자체 렌더링 시스템을 사용한다. - 이 방식은 전통적인 웹 앱보다 높은 성능을 제공한다. - 무한 줌 - 실시간 멀티플레이어 협업 - 게임과 유사한 고성능 그래픽 처리 - 반면 브라우저가 자동으로 생성하는 접근성 트리를 활용할 수 없다. - 실제 캔버스에는 여러 디자인 레이어가 있어도 포커스를 유지하는 `<input>` 요소 하나만 존재하므로, 스크린 리더가 인식할 구조가 거의 없었다. ## 접근성 트리 합성 - 브라우저의 접근성 트리는 DOM, 시맨틱 HTML, ARIA 속성, 계산된 상태를 바탕으로 생성된다. - Figma는 이 기능을 되살리기 위해 실제 캔버스와 별도로 접근성용 DOM 요소를 합성했다. - 이 구조를 통해 스크린 리더가 Figma 파일의 레이어를 탐색하고 편집할 수 있게 했다. - 시각적 렌더링과 접근성 정보를 분리해, 캔버스의 성능을 유지하면서 브라우저의 보조 기술과 연동한다. ## 네 가지 핵심 시스템 Figma의 접근성 구현은 다음 시스템들이 협력하는 구조다. - **내부 접근성 트리** - 각 디자인 레이어의 접근성 정보를 캐시한다. - 변경이 발생할 때 전체를 다시 만들지 않고 필요한 부분만 갱신한다. - **Mirror DOM React 컴포넌트** - 내부 접근성 트리를 참조해 실제 DOM 요소를 생성한다. - 각 레이어에 대응하는 접근성 요소를 재귀적으로 렌더링한다. - **양방향 선택 동기화** - 캔버스에서 노드를 선택하면 대응하는 DOM 요소에 포커스를 이동한다. - 스크린 리더나 키보드로 DOM 요소를 탐색하면 캔버스 선택 상태도 갱신한다. - **공지 시스템** - 탐색 외의 변경 사항을 사용자에게 알린다. - 예를 들어 객체 이동, 도구 전환 등 시각 사용자에게는 명확하지만 스크린 리더 사용자는 놓칠 수 있는 변화를 안내한다. ## 문맥에 따른 접근성 요약 - 각 디자인 레이어마다 스크린 리더가 읽을 수 있는 **접근성 요약(accessible summary)** 을 생성한다. - 같은 디자인이라도 사용 중인 애플리케이션 문맥에 따라 요약 방식이 달라진다. - 프로토타입을 보는 상황에서는: - 편집 관련 기능을 대부분 제외한다. - 텍스트 필드의 내용이나 클릭 동작이 있는 요소의 버튼 역할처럼 최종 사용자에게 필요한 정보만 제공한다. - 문서를 편집하는 상황에서는: - 오토레이아웃 프레임처럼 편집에 필요한 구조도 접근성 트리에 포함한다. - 레이어별 요약을 만든 뒤 트리를 위에서 아래로 순회하며, 접근성에서 제외된 노드는 제거하고 하위 노드를 상위 구조에 병합한다. - 문서 최초 로딩 시에는 전체 접근성 트리를 구성하지만, 이후에는 편집된 부분만 수술적으로 갱신해 비용을 줄인다. ## Mirror DOM의 재귀적 렌더링 - React 기반 `Mirror DOM` 컴포넌트가 접근성 트리의 각 레이어를 DOM으로 변환한다. - 각 컴포넌트는 특정 레이어의 접근성 요약을 구독한다. - 요약에서 다음 정보를 가져와 DOM 요소를 생성한다. - `label`: 스크린 리더가 읽을 이름 - `role`: 버튼, 입력 필드 등 요소의 의미 - `children`: 하위 레이어 - 하위 레이어는 같은 컴포넌트를 재귀적으로 호출해 DOM 트리를 구성한다. - 내부 접근성 트리를 최소 단위로 갱신하면 React가 실제 DOM 변경도 최소화할 수 있다. ## 시각적 콘텐츠와 접근성 콘텐츠의 분리 - Mirror DOM은 화면에 보이지 않지만 보조 기술이 해석할 수 있는 구조를 제공한다. - 일반적인 visually hidden 스타일을 사용하지 않는 점이 특징이다. - 캔버스 기반 제품에서는 접근성용 DOM이 페이지 레이아웃이나 캔버스 렌더링에 영향을 주지 않도록 별도의 방식으로 관리해야 한다. - 핵심은 시각적 UI를 억지로 HTML로 대체하는 것이 아니라, 보조 기술이 필요로 하는 의미 구조를 별도로 합성하는 것이다. 캔버스 기반 제품에 접근성을 추가할 때는 브라우저가 자동으로 제공하던 기능을 직접 재구축해야 한다. 특히 내부 접근성 트리, 점진적 갱신, 시각 UI와 DOM의 양방향 상태 동기화를 함께 설계하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

React접근성screen-readersdom+3

figma·2026년 6월 29일·4분 읽기큐레이션 요약

어디서든 시작하세요, Figma가 만든 매거진 | Figma 블로그

새로운 도구와 재료의 등장으로 디자인은 더 이상 정해진 출발점에서 시작할 필요가 없으며, 누구나 아이디어에 맞는 방식으로 작업을 시작할 수 있다. Figma의 2026년 Config 매거진은 모션, 코드, AI를 디자인 캔버스 안으로 통합하면서 디자인의 표현력과 협업 방식을 확장하는 흐름을 조명한다. 핵심은 도구가 쉬워질수록 기본 원리와 호기심, 지속적인 탐구가 더욱 중요해진다는 것이다. ## 디자인은 어디에서든 시작할 수 있다 - Figma는 Config 2026을 맞아 디자인의 현재를 보여주는 인쇄 매거진을 제작했다. - 매년 주제와 기고자, 디자인은 달라지지만, “지금 디자인이 어떤 모습인가”를 아름다운 인쇄물로 표현한다는 목표는 유지된다. - 빠르게 변하는 제품과 기술 환경에서는 글이 출간될 때 이미 새로운 버전이 나올 수 있다. - 이런 변화 속에서도 오래 남는 것은 다음과 같은 태도다. - 무엇을 하는지 설명하기 전에 그것이 무엇인지 이해하려는 자세 - 새로운 도구의 가능성을 성급히 단정하지 않는 인내심 - 서로 다른 도구와 재료가 어떻게 연결될지 탐구하는 호기심 - 매거진은 초보자, 숙련된 실무자, 단순히 좋은 결과물을 빠르게 만들고 싶은 사람 모두를 독자로 삼는다. - 세 가지 표지는 각각 다른 질문과 출발점을 제시하지만, 결국 같은 주제를 향해 계속 탐구하도록 유도한다. ## 모션이 캔버스에 들어오다 - Figma Motion은 타임라인을 Figma 캔버스 안에 제공한다. - 모션 작업이 기존 컴포넌트, 변수, 팀 협업 환경과 같은 파일 안에서 이루어질 수 있다. - 디자이너는 제품이 완성된 뒤 애니메이션을 추가하는 것이 아니라, 초기 단계부터 시간과 움직임을 설계할 수 있다. - 모션 디자인에서는 도구 사용이 쉬워져도 기본 원리가 중요하다. - 움직임의 속도와 타이밍 - 시각적 전환이 전달하는 의미 - 움직임을 통해 사용자 경험을 조직하는 방식 - Figma는 Brand Studio의 모션 디자이너들과 함께, “시간을 디자인한다”는 것이 무엇인지 설명한다. ## 코드와 디자인의 경계가 좁아지다 - 코드는 오래전부터 디자인 과정의 재료였지만, 기존에는 디자인 도구와 분리된 환경에 놓여 있었다. - Figma는 코드 레이어를 디자인 캔버스에 도입해 코드와 시각적 디자인을 같은 멀티플레이어 공간에서 다룰 수 있도록 한다. - 팀은 여러 코드 기반 방향을 나란히 탐색하고 비교할 수 있다. - 디자인에서 코드로 일방향 전달하는 방식보다, 코드와 캔버스 사이를 반복적으로 오가는 작업 흐름이 가능해진다. - 이러한 변화는 디자인과 개발의 역할을 단순히 합치는 것이 아니라, 아이디어를 시험하고 발전시키는 경로를 늘린다. ## 디자인-코드 순환이 만드는 새로운 가능성 - 코드와 캔버스 사이의 이동이 자연스러워지면서 디자인과 개발 워크플로가 서로 수렴한다. - Figma 소프트웨어 엔지니어 Alex Kern과 AI 디자인 디렉터 Gui Seiz는 연결된 작업 방식이 무엇을 가능하게 하는지 논의한다. - 디자인 결과물을 코드로 넘기는 마지막 단계만 자동화하는 것이 아니라, 아이디어 구상과 구현 과정 전체가 연결된다. - 이를 통해 팀은 다음을 더 빠르게 반복할 수 있다. - 여러 제품 방향의 실험 - 디자인과 실제 구현의 비교 - 팀원 간 피드백과 수정 - 아이디어를 프로덕션에 가까운 형태로 검증 ## AI가 아이디어에서 제품까지의 과정을 바꾸다 - AI 도구는 팀이 제품을 시작하는 지점뿐 아니라, 아이디어가 실제 제품으로 이어지는 방식까지 바꾸고 있다. - 변화는 특정 도구 하나의 도입보다 전체 프로세스의 재구성에 가깝다. - 매거진은 네 조직의 사례를 통해 AI를 활용해 아이디어를 제품으로 발전시키는 새로운 접근법을 소개한다. - AI는 초기 아이디어 생성, 방향 탐색, 프로토타이핑, 제작 단계 간의 연결을 강화할 수 있다. - 다만 AI가 디자인 판단을 대신한다기보다, 사람이 더 많은 가능성을 빠르게 탐색하고 선택하도록 돕는 역할에 초점이 맞춰져 있다. ## 인간과 AI의 미래적 상호작용 - 매거진의 “Future states” 섹션은 기계 지능과 인간 지능의 간극이 좁아졌을 때의 가능성을 상상한다. - 커뮤니티 구성원들은 AI가 소프트웨어를 더 인간적인 방식으로 만들 수 있다고 제안한다. - 예시로 다음과 같은 방향이 제시된다. - 사용자의 감정이나 상태를 이해하는 인터페이스 - 사용자의 선택이 어떤 결과로 이어질지 예측하는 시스템 - 인간의 맥락과 의도를 더 깊이 파악하는 소프트웨어 - 이는 AI를 단순한 자동화 도구가 아니라, 인간의 의사결정과 상호작용을 보조하는 새로운 인터페이스 재료로 바라보는 관점이다. 새로운 도구를 익히는 가장 좋은 방법은 완벽한 출발점을 기다리기보다 작은 아이디어에서 바로 시작해 보는 것이다. 모션, 코드, AI를 기존 디자인 과정에 단계적으로 결합하되, 도구보다 디자인 원리와 사용자 경험에 대한 판단을 중심에 두는 것이 바람직하다.

원문 읽기(새 탭에서 열림)

ReactFigmaAIdesign-to-code+1

line·2026년 6월 26일·4분 읽기큐레이션 요약

프롬프팅에서 워크플로로, AI로 프런트엔드 개발 생산성 끌어올리기

코딩 속도보다 더 큰 병목은 Jira, Figma, Confluence, Slack, Git 등에 흩어진 정보를 모으고 조정하는 비용입니다. 글은 LLM을 단발성 프롬프트 도구가 아니라 반복 가능한 개발 워크플로의 실행 엔진으로 활용해야 한다고 주장합니다. 이를 통해 구현 전 요구 사항을 통합하고, 불확실성을 드러내며, 구현 후 검증까지 자동화하는 오케스트레이션 중심의 프런트엔드 개발이 가능해집니다. ## 프런트엔드 개발의 병목 변화 - 하나의 기능을 구현하려면 여러 시스템을 오가야 합니다. - 요구 사항: Jira - 디자인: Figma - 기술·정책 문서: Confluence - 의사결정과 논의: Slack - 구현과 검증: Git - 프런트엔드 개발자는 이 정보를 통합해 실제 사용 가능한 결과물로 조립하는 역할을 담당합니다. - 주요 부담은 코드를 작성하는 일보다 다음과 같은 컨텍스트 작업에 있습니다. - 티켓과 디자인 분석 - 에지 케이스 확인 - 제품·백엔드 팀과의 동기화 - 기존 코드와 재사용 가능한 구성 요소 탐색 ## 프롬프트에서 반복 가능한 워크플로로 - 단발성 프롬프트는 한 번의 작업에는 유용하지만, 반복성과 누적 효과가 부족합니다. - 워크플로는 입력부터 출력까지의 표준화된 경로입니다. - 여러 시스템에서 관련 컨텍스트 수집 - 요구 사항 요약 - 모호하거나 충돌하는 내용 식별 - 구현 계획과 파일 목록 제안 - 사람이 검토한 뒤 코드 수정 진행 - 이 구조에서 LLM은 단순히 코드를 생성하는 도구가 아니라 워크플로를 실행하는 엔진입니다. - 한 번 구축한 워크플로는 티켓의 내용이 달라져도 동일한 패턴으로 적용할 수 있어 확장성이 높습니다. ## 연결된 개발 컨텍스트와 Noah MCP - LY Corporation의 Noah MCP는 Jira, Confluence, Slack, GitHub 같은 내부 도구를 연결합니다. - AI 에이전트가 사람이 복사해 붙여넣은 정보가 아니라 실제 업무 시스템에 존재하는 컨텍스트를 직접 읽고 추론할 수 있게 합니다. - 이를 통해 개발자는 각 시스템을 수동으로 방문하고 정보를 노트에 조합하는 작업을 줄일 수 있습니다. - 핵심은 AI를 별도의 도구로 사용하는 것이 아니라 기존 업무 흐름 안에 배치하는 것입니다. ## 구현 전 요구 사항 통합 예시 기능은 검색·필터·정렬과 역할 기반 필터 표시가 있는 목록 페이지입니다. 기존 방식에서는 개발자가 Jira, Figma, Confluence, Slack, 코드베이스를 직접 확인한 뒤 계획을 작성합니다. 워크플로 기반 방식에서는 에이전트에게 다음을 요청합니다. - Jira 티켓 분석 - 관련 Confluence 문서 검색 - Slack의 최근 의사결정 확인 - 유사한 코드 구현 탐색 - 코드 수정 없이 다음 결과 반환 - 요구 사항 요약 - 프런트엔드 영향 범위 - 관련 파일 - 구현 체크리스트 - 테스트 체크리스트 - 미해결 질문 에이전트가 도출한 계획에는 다음과 같은 구체적인 정보가 포함됩니다. - `FeatureListPage.tsx`, `FeatureList.tsx` 등 신규 파일 - 기존 `useTableFilters`, `useUrlState` 훅의 재사용 - `GET /api/<feature>`의 기존 페이지네이션 API 활용 - 역할별 필터 표시 - viewer: 검색, 상태 필터, 날짜 범위 - editor: owner 필터 추가 - admin: 내부 전용 플래그 추가 - 필터·정렬·페이지 상태를 URL 파라미터와 동기화 - 로딩, 빈 결과, 검색 결과 없음 상태 구현 ## 숨겨진 요구 사항과 재작업 방지 - Slack 논의에서 필터 상태를 `localStorage`가 아니라 URL에 저장해야 한다는 결정이 발견됩니다. - URL 공유가 가능해지고 - 새로고침 후에도 상태가 유지되며 - 다른 사용자가 동일한 화면을 재현할 수 있습니다. - 코드베이스 검색을 통해 이미 존재하는 훅을 재사용할 수 있습니다. - 불필요한 중복 구현 방지 - 기존 동작과의 일관성 유지 - 개발 시간 단축 - 구현 전에 다음과 같은 미해결 사항도 드러납니다. - 필터·정렬 상태를 URL에 저장할지 여부 - 빈 상태에서 “필터 초기화” 버튼을 제공할지 여부 - 이런 문제를 PR 리뷰 단계가 아니라 구현 전에 발견하면 재작업 가능성을 줄일 수 있습니다. ## 코딩 이후의 폐쇄 루프 검증 워크플로는 코드 생성에서 끝나지 않고 검증 단계까지 포함해야 합니다. - 구현 후 원래 계획과 실제 변경 사항을 대조합니다. - 자동 검증 항목을 실행합니다. - 타입 검사 - 린트 - 관련 단위 테스트 - 스모크 테스트 또는 로컬 검증 흐름 - 에이전트는 다음 결과를 보고합니다. - 통과한 검사 - 실패 후 수정한 문제 - 자동화하지 못한 검증 - UI 상태별 스크린샷이나 확인 메모 - PR 전 남은 위험 요소 - 이 폐쇄 루프를 통해 계획, 구현, 검증이 하나의 연속된 개발 사이클이 됩니다. ## 실용적인 적용 방향 프런트엔드 팀은 먼저 Jira·문서·메신저·코드 검색을 묶은 “구현 전 분석 워크플로”부터 도입하는 것이 좋습니다. 이후 구현 계획 승인, 코드 수정, 자동 테스트, PR 전 검증을 단계적으로 연결하면 단순한 코드 생성보다 재작업 감소와 품질 향상이라는 더 큰 효과를 얻을 수 있습니다.

원문 읽기(새 탭에서 열림)

React대규모 언어 모델모델 컨텍스트 프로토콜TypeScript+4

figma·2026년 6월 24일·3분 읽기큐레이션 요약

Config 2026: 새로운 소재, 새로운 도구, 더욱 표현력 있는 캔버스 | Figma 블로그

Figma Config 2026의 핵심 방향은 캔버스를 단순한 디자인 작업 공간이 아니라 코드·모션·셰이더·생성형 플러그인 등을 함께 다루는 창작 환경으로 확장하는 것이다. Figma는 AI가 작업의 진입장벽은 낮췄지만 창작의 한계를 넓히는 것은 결국 디자이너와 크리에이터의 몫이라고 강조한다. 이를 위해 디자인과 코드의 경계를 없애고, 더 풍부한 표현과 협업을 캔버스 안에서 가능하게 하려 한다. ## 디자인 캔버스의 확장 - Figma는 이미지, 벡터, 디자인 레이어뿐 아니라 코드와 모션도 디자인 재료로 취급하려 한다. - 코드·모션·셰이더·생성형 플러그인·Weave 도구를 하나의 캔버스에서 조합하는 것이 이번 Config의 주요 방향이다. - 캔버스는 결과물이 저장되는 장소를 넘어, 아이디어를 연결하고 동료와 함께 반복적으로 발전시키는 협업 공간으로 정의된다. - AI가 창작의 진입장벽을 낮췄다면, 더 높은 수준의 창의성과 과감한 시도는 사용자가 만들어야 한다는 관점을 제시한다. ## 코드 레이어로 디자인과 개발 통합 - 기존의 “디자인 대 코드”라는 구분은 인위적인 논쟁이며, 코드는 이미지나 벡터와 같은 디자인 재료라는 것이 Figma의 주장이다. - Figma Design의 모든 디자인 레이어를 클릭 한 번 또는 프롬프트로 인터랙티브한 코드 레이어로 변환할 수 있다. - 코드 레이어를 복제해 여러 구현 방향을 나란히 비교하고 탐색할 수 있다. - 일반적인 Figma 캔버스처럼 팀원이 같은 파일에서 코드를 수정하고, 의견을 남기고, 반복 작업을 진행할 수 있다. - 코드로 만든 결과물을 다시 편집 가능한 디자인 레이어로 추출할 수 있다. - 디자인 레이어를 수정한 뒤에는 한 번의 클릭으로 변경 사항을 코드 레이어에 반영할 수 있어 디자인과 구현 사이를 양방향으로 오갈 수 있다. - 코드 레이어의 얼리 액세스는 7월부터 시작될 예정이며, 베타 대기자 등록을 통해 참여할 수 있다. ## Figma Motion으로 디자인에 움직임 추가 - Figma Design 안에 타임라인 기반의 모션 제작 기능이 추가된다. - 키프레임과 프리셋을 사용해 처음부터 애니메이션을 만들거나, 기존 디자인에 모션을 덧입힐 수 있다. - Figma agent를 이용해 애니메이션의 초기 시안을 생성할 수도 있다. - 모션 디자이너에게는 반복적인 작업을 줄이고, 창의적인 표현에 더 집중할 수 있는 환경을 제공한다. - 애니메이션을 컴포넌트에 한 번 정의하면 여러 화면과 협업자의 파일에서 디자인 시스템의 일부처럼 재사용할 수 있다. ## 모션과 개발 도구의 연결 - Dev Mode에서는 전체 타임라인을 확인하고 검사할 수 있다. - 각 키프레임, 타이밍 값, 이징 곡선을 별도의 해석 없이 읽을 수 있다. - 애니메이션 코드를 CSS, JSON 또는 React 프레임워크용 코드로 직접 복사할 수 있다. - MCP와 호환되므로 애니메이션이 적용된 프레임을 코딩 에이전트로 전달해 구현할 수 있다. - 결과물은 MP4, WebM, Animated SVG, GIF 등으로 내보낼 수 있으며, 향후 더 많은 포맷이 추가될 예정이다. Figma Config 2026은 디자인·개발·모션을 별도 도구로 분리하기보다 하나의 협업 캔버스에서 연결하려는 흐름을 보여준다. 특히 코드 레이어와 Figma Motion은 디자이너가 구현 가능성을 즉시 실험하고, 개발자는 디자인 의도와 애니메이션 세부 정보를 정확히 확인하도록 돕는 기능으로 볼 수 있다.

원문 읽기(새 탭에서 열림)

ReactFigma생성형 AI모델 컨텍스트 프로토콜+3

figma·2026년 6월 24일·3분 읽기큐레이션 요약

피그마 캔버스에서 코딩하기 | 피그마 블로그

Figma는 코드 레이어를 통해 실행 가능한 코드를 디자인 캔버스 안에서 생성·비교·수정할 수 있도록 한다. 디자이너와 개발자는 코드와 디자인을 오가는 대신 같은 Figma 파일에서 아이디어를 함께 탐색하고, 팀의 피드백을 반영하며, 최종 코드를 저장소에 반영할 수 있다. 코드 레이어는 디자인과 개발의 경계를 좁혀 협업 중심의 프로토타이핑을 가능하게 하는 기능이다. ## 캔버스에서 코드 시작하기 - Figma Design의 툴바에서 코드 레이어를 추가하거나, 기존 프레임을 코드로 변환할 수 있다. - Figma Agent에게 원하는 결과를 설명해 코드를 생성할 수도 있다. - 템플릿에서 시작하거나 직접 만들고 싶은 내용을 프롬프트로 입력할 수 있다. - GitHub 저장소를 가져오거나 로컬 폴더를 업로드해 기존 코드베이스를 불러올 수 있다. - Figma Make에서 생성·수정한 코드도 캔버스의 코드 레이어로 가져와 팀과 공유할 수 있다. ## 여러 대안을 나란히 비교하기 - 기존 프레임을 복제해 여러 디자인 방향을 시험하듯 코드 레이어도 복제해 대안을 만들 수 있다. - 실제로 작동하는 화면을 캔버스에서 비교하므로 정적인 시안만 볼 때보다 사용 경험을 구체적으로 평가할 수 있다. - 요소를 이동·조정·리사이즈하면 코드에 즉시 반영된다. - 프롬프트로 새 버전을 생성하면서도 기존 버전은 보존할 수 있다. - 팀원은 공유 파일 안에서 댓글을 남기거나 동일한 코드 레이어를 대상으로 Agent에 추가 작업을 요청할 수 있다. ## 코드와 디자인 레이어 오가기 - `Extract designs` 기능을 사용하면 코드의 현재 상태를 편집 가능한 Figma 레이어로 변환할 수 있다. - 전체 화면뿐 아니라 특정 화면, 상태, 사용자 플로우만 선택해 캔버스로 가져올 수 있다. - 코드로 구현된 인터랙션과 상태를 시각적으로 분석하고, 일반적인 Figma 디자인 요소처럼 편집할 수 있다. - 캔버스에서 수정한 내용은 한 번의 클릭으로 코드 레이어에 업데이트할 수 있어 디자인과 구현 사이의 반복 작업이 짧아진다. ## 코드 편집과 저장소 반영 - 코드 에디터에서 원하는 변경 사항을 주석이나 설명으로 작성하고 Agent에게 수정을 요청할 수 있다. - 필요하면 개발자가 직접 코드를 편집할 수도 있다. - 수정 결과를 다시 코드 레이어로 변환해 팀에 공유할 수 있다. - 최종적으로 확정한 변경 사항은 저장소에 push해 실제 소스 코드에 반영할 수 있다. - 따라서 Figma 캔버스는 단순한 시각화 공간이 아니라, 아이디어 탐색부터 코드 변경 및 공유까지 이어지는 협업 환경이 된다. ## 출시 계획 - 코드 레이어는 2026년 6월 기준 향후 몇 주 동안 비공개 베타로 제공될 예정이다. - 초기 접근 권한은 Figma의 베타 신청 페이지를 통해 요청할 수 있다. - 기능 세부 사항과 Config에서 발표된 다른 업데이트는 Figma Help Center와 Figma Learn에서 확인할 수 있다. 실무에서는 코드 레이어를 최종 구현을 자동화하는 도구라기보다, 디자인·개발팀이 여러 구현안을 빠르게 실험하고 합의하는 공동 프로토타이핑 환경으로 활용하는 것이 적합하다. 특히 기존 코드베이스를 불러와 실제 동작을 검토한 뒤 디자인과 코드를 반복적으로 조정하는 워크플로에 유용하다.

원문 읽기(새 탭에서 열림)

ReactFigmaAI 에이전트github+2

figma·2026년 5월 22일·3분 읽기큐레이션 요약

Figma Make 크레딧을 더 효율적으로 사용하는 7가지 팁 | Figma 블로그

Figma Make에서 크레딧을 효율적으로 사용하려면 긴 프롬프트를 반복하기보다 초기 설계와 변경 범위를 명확히 해야 한다. 첫 프롬프트에 프로젝트의 목표·맥락·제약·완료 기준을 충분히 담고, 이후에는 필요한 부분만 구체적으로 수정하는 방식이 효과적이다. 단순한 시각 변경이나 데이터 수정은 AI에 다시 요청하기보다 Edit 도구나 소스 코드 직접 편집을 활용하는 것이 좋다. ## 초기 프롬프트에 프로젝트의 기준점 담기 - 첫 프롬프트는 단순한 요청이 아니라 프로젝트의 전체 브리프처럼 작성한다. - 다음 내용을 구체적으로 포함한다. - 프로젝트의 목표 - 사용 맥락 - 필요한 UI 요소와 동작 - 기술적·기능적 제약 - 최종적으로 “완료”라고 판단할 기준 - 초기 구조가 탄탄할수록 이후에 잘못된 구현을 되돌리는 비용과 크레딧 사용량이 줄어든다. - 대규모 프로젝트는 다음 순서로 나누는 것이 효과적이다. 1. 화면과 컴포넌트의 전체 구조 설계 2. 기능과 상호작용 구현 3. 콘텐츠 입력 및 시각적 세부 조정 - 구조는 프로젝트가 진행될수록 변경하기 어려우므로 가장 먼저 확정하는 것이 좋다. ## 후속 프롬프트는 변경 범위를 좁혀 작성하기 - 첫 프롬프트 이후의 요청은 전체 프로젝트를 다시 설명하는 것이 아니라 변경 사항(delta)을 전달하는 방식으로 작성한다. - 좋은 후속 프롬프트는 다음 세 가지를 포함한다. - 무엇을 바꿀지 - 어떻게 바꿀지 - 무엇은 그대로 유지할지 - “다시 해줘”, “뭔가 이상해”처럼 모호한 요청보다 다음처럼 대상과 위치를 명시한다. - “캘린더 컴포넌트를 수정해줘” - “이 화면에 새로운 상태를 추가해줘” - “`tokens.ts` 파일을 수정해줘” - 서로 관련된 수정이 같은 컴포넌트나 로직에 집중되어 있다면 한 번에 묶는 편이 효율적이다. - 반대로 관련 없는 변경을 하나의 프롬프트에 섞으면 Make가 의도를 해석하는 비용이 커지고 결과도 불안정해질 수 있다. - 특정 파일, 컴포넌트, 상태를 지정하면 Make가 탐색해야 할 범위가 줄어들어 크레딧을 절약할 수 있다. ## 작은 시각 변경은 Edit 도구로 처리하기 - 간격 조정, 요소 삭제, 텍스트 변경처럼 결과가 거의 완성된 상태에서의 작은 수정은 AI 프롬프트보다 Edit 도구가 빠르다. - 이런 작업을 매번 프롬프트로 요청하면 새로운 설계 문제를 해결하는 것이 아니라 기존 결과를 조금씩 조정하는 데 크레딧을 소비하게 된다. - 직접 편집이 적합한 예시는 다음과 같다. - 여백이나 간격 변경 - 특정 UI 요소 제거 - 문구 수정 - 이미 구현된 컴포넌트의 단순한 스타일 조정 ## 소스 코드에서 동적 콘텐츠 수정하기 - 미리보기 화면에서 직접 수정하기 어려운 동적 콘텐츠는 소스 코드에서 값을 변경하는 편이 효율적이다. - `Go to source`를 사용해 관련 코드로 이동한 뒤 실제 데이터가 정의된 부분을 수정한다. - 반복 컴포넌트 안의 텍스트나 같은 폴더의 목록에서 가져오는 데이터 변경에 특히 유용하다. - **⌘F** 단축키로 코드를 검색해 특정 태그나 콘텐츠를 빠르게 찾을 수 있다. - 우선 `App.tsx`를 확인하고, 해당 코드가 없다면 컴포넌트 폴더의 다른 `.tsx` 파일을 살펴보면 된다. ## 실용적인 작업 원칙 처음에는 프로젝트 구조와 제약을 충분히 설명하고, 이후 요청은 한 번에 하나의 명확한 변경에 집중하는 것이 좋다. 단순한 수정은 Edit 도구나 소스 코드에서 직접 처리하고, AI는 새로운 구조·기능·상호작용처럼 직접 구현하기 복잡한 작업에 사용하는 방식이 크레딧과 시간을 모두 절약한다.

원문 읽기(새 탭에서 열림)

React사용자 경험TypeScriptfigma-make+3

figma·2026년 5월 12일·3분 읽기큐레이션 요약

디자인-코드 루프가 열어 주는 가능성 | Figma 블로그

AI는 디자인과 코드 사이의 장벽을 낮춰 두 영역을 하나의 연속적인 작업 흐름으로 만들고 있다. 이제 디자이너는 정적인 시안을 반복 제작하는 대신 기능하는 프로토타입을 코드로 만들고, 이를 다시 Figma 캔버스에서 편집하며 방향을 재탐색할 수 있다. 중요한 변화는 단순한 코드 생성 속도가 아니라, 디자인과 코드 간 변환이 기계적 번역에서 의미 중심의 협업으로 바뀐다는 점이다. ## 디자인과 코드의 경계가 사라지는 흐름 - 과거에는 코드가 복잡하고 수정 비용이 높아 디자인 단계에서 여러 정적 시안을 먼저 탐색하는 방식이 일반적이었다. - AI를 활용하면 기능하는 와이어프레임을 빠르게 만들고, 레이아웃뿐 아니라 상호작용과 동작까지 직접 실험할 수 있다. - 코드에서 Figma 캔버스로 이동하면 이미 구현한 방향에 고정되지 않고 새로운 구조와 시각적 대안을 다시 탐색할 수 있다. - Figma의 Alex Kern은 핵심 변화가 “코드를 더 빠르게 생성하는 것”이 아니라 디자인과 코드 사이의 변환을 더 의미론적이고 덜 기계적으로 만드는 것이라고 설명한다. ## 양방향 디자인-코드 루프 - 기존 개발 환경은 코드베이스에 이미 존재하는 구조와 패턴을 중심으로 한 방향으로 작업하기 쉽다. - AI 모델 역시 기존 코드의 관성에 영향을 받아 완전히 다른 제품 방향을 제안하는 데 한계가 있을 수 있다. - Figma 캔버스에서는 코드에서 구현한 결과를 다시 시각적으로 검토하고, 전혀 다른 방향으로 되돌아가 탐색할 수 있다. - 이처럼 `코드 → 캔버스 → 코드`를 반복하는 루프가 디자인과 엔지니어링의 협업 범위를 넓힌다. ## 협업 참여자의 확대 - 과거에는 “디자이너가 코딩을 배워야 하는가”가 주요 논점이었다면, 이제는 “디자이너가 AI에게 코드를 요청할 수 있는가”가 더 현실적인 질문이 되었다. - AI는 디자인 시스템이나 내부 개발 환경에 직접 접근하지 못하는 사람도 실제 제품을 Figma의 편집 가능한 프레임으로 가져와 작업할 수 있게 한다. - 결과적으로 특정 도구, 전문 지식, 조직 내 접근 권한이 협업의 진입장벽이 되는 문제가 줄어든다. - 디자인과 개발이 일부 전문가만의 영역이 아니라 더 많은 팀원이 참여할 수 있는 공동 작업 공간으로 변화한다. ## 학습 곡선에서 학습 램프로 - AI는 초보자의 출발점을 높여 복잡한 프레임워크와 개발 환경을 처음부터 모두 익히지 않아도 작업을 시작하게 한다. - 작업 중인 실제 맥락에서 “이 코드가 무엇을 하는지”, “React 라우팅이 어떻게 동작하는지”를 질문할 수 있어 추상적인 교육보다 이해가 쉽다. - 디자이너는 자신의 제품과 문제를 기반으로 학습하면서 점진적으로 전문성을 쌓을 수 있다. - Gui Seiz는 AI를 통해 셰이더, 3D, 자체 제작 도구처럼 과거에는 기술적 지식 부족으로 시도하지 않았던 영역까지 탐색하게 되었다고 말한다. ## 도구보다 중요한 호기심과 취향 - AI 도구 자체는 점점 많은 사람에게 동일하게 제공되므로 도구 접근성만으로는 차별화하기 어려워진다. - 앞으로는 무엇을 만들지 판단하는 취향과, 새로운 가능성을 계속 시험하는 호기심이 중요한 경쟁력이 된다. - AI는 문법, 프레임워크, 개발 환경을 설명해 주는 인내심 있는 튜터 역할을 할 수 있다. - 따라서 AI 시대에는 기존 전문성을 유지하는 것뿐 아니라 새로운 방식으로 배우고 실험하는 태도가 중요하다. ## 실용적인 결론 디자이너와 개발자는 디자인과 코드를 분리된 인수인계 단계로 보기보다, 서로 오가며 반복 개선하는 하나의 루프로 운영하는 것이 유리하다. AI를 최종 결과물을 자동 생성하는 도구로만 사용하기보다, 기능 프로토타이핑·코드 이해·대안 탐색·협업 진입장벽 완화에 활용할 때 가장 큰 효과를 얻을 수 있다.

원문 읽기(새 탭에서 열림)

ReactFigma디자인 시스템생성형 AI+2

cloudflare·2026년 4월 17일원문

기억하는 에이전트: 에이전트 메모리를 소개합니다 (새 탭에서 열림)

AI 에이전트가 방대한 컨텍스트 윈도우를 사용할 때 발생하는 정보 과부하와 품질 저하(Context Rot) 문제를 해결하기 위해, Cloudflare는 관리형 영구 기억 서비스인 'Agent Memory'를 출시했습니다. 이 서비스는 대화 내용에서 핵심 정보를 자동으로 추출하고 필요할 때만 검색하여 제공함으로써, 컨텍스트를 채우지 않고도 에이전트가 과거의 경험을 기억하고 시간이 지남에 따라 더 똑똑해지도록 돕습니다. 이를 통해 개발자는 긴 시간 동안 실행되는 복잡한 워크로드에서도 비용 효율적이고 고성능인 추론 환경을 구축할 수 있습니다. ### 기존 에이전트 메모리의 한계와 차별점 * **컨텍스트 부패(Context Rot) 해결**: 컨텍스트 윈도우가 100만 토큰 이상으로 커져도 정보를 모두 담으면 모델의 추론 품질이 떨어지고, 반대로 정보를 삭제하면 나중에 필요한 데이터를 잃게 되는 딜레마를 해결합니다. * **검색 기반 아키텍처**: 에이전트에게 파일 시스템에 대한 직접적인 접근 권한을 주는 대신, 최적화된 API를 통한 검색 기반 방식을 채택하여 보안과 성능을 높였습니다. * **복잡한 추론 지원**: 단순 저장을 넘어 시간 논리(temporal logic), 정보의 최신성 유지(supersession), 지시 사항 준수와 같은 운영 환경의 복잡한 요구사항을 처리할 수 있는 토대를 제공합니다. ### 주요 기능 및 API 동작 방식 * **프로필(Profile) 단위 관리**: 메모리는 '프로필'이라는 독립된 저장소에 이름별로 관리되며, 여러 세션이나 사용자, 에이전트 간에 공유될 수 있습니다. * **핵심 오퍼레이션**: * **Ingest**: 대화 이력을 분석하여 중요한 정보를 추출합니다. 보통 컨텍스트를 압축해야 하는 시점에 호출됩니다. * **Remember**: 에이전트가 도구 사용(Tool Use)을 통해 특정 사실을 즉시 명시적으로 저장합니다. * **Recall**: 전체 메모리 파이프라인을 실행하여 질문에 최적화된 합성된 답변(Synthesized answer)을 반환합니다. * **유연한 연결성**: Cloudflare Workers 내에서 직접 바인딩하여 사용하거나, REST API를 통해 외부 프레임워크(Claude Code, Anthropic Managed Agents 등)와 연동할 수 있습니다. ### 활용 가능한 에이전트 아키텍처 * **개별 및 자율 에이전트**: 코딩 에이전트나 백그라운드에서 실행되는 자율형 에이전트가 세션 재시작 후에도 이전 작업 내용을 기억하도록 구현할 수 있습니다. * **에이전트 간 지식 공유**: 팀 단위로 메모리 프로필을 공유하여, 한 엔지니어의 코딩 에이전트가 학습한 코딩 컨벤션이나 아키텍처 결정 사항을 팀 내 다른 에이전트와 도구가 즉시 활용하게 할 수 있습니다. * **비용 및 성능 최적화**: 모든 데이터를 컨텍스트에 넣는 대신 필요한 정보만 호출함으로써 추론당 비용을 낮추고 응답 속도를 향상시킵니다. Agent Memory는 단순한 데이터 저장을 넘어 에이전트가 장기적으로 학습하고 협업할 수 있는 기반을 제공합니다. 특히 긴 호흡의 프로젝트를 수행하거나 복잡한 운영 업무를 자동화하려는 개발자들에게 컨텍스트 관리 부담을 줄여주는 실용적인 해결책이 될 것입니다.

ReactTypeScriptCloudflare WorkersAPI 설계+3

github·2026년 4월 15일·3분 읽기큐레이션 요약

GitHub Copilot CLI로 개인용 정리 커맨드 센터 구축하기

여러 앱에 흩어진 업무 정보를 하나로 모으기 위해, GitHub 엔지니어 Brittany Ellich가 개인용 조직 관리 커맨드 센터를 만들었다. 이 프로젝트는 일상적인 디지털 파편화 문제를 해결하는 데 초점을 맞췄으며, GitHub Copilot을 기획과 구현 전반에 활용해 하루 만에 v1을 완성했다. 글은 작은 개인적 불편에서 출발해 AI 도구로 실제 생산성 도구를 만드는 과정을 소개한다. ## 디지털 파편화를 해결하는 개인용 커맨드 센터 - 여러 앱을 오가며 발생하는 컨텍스트 전환과 정보 분산을 해결하기 위해 중앙 집중형 작업 공간을 구축했다. - 사용자가 정보를 시각적으로 파악하고 사고하는 방식에 맞춘 “차분하고 시각적인 홈 화면”을 목표로 했다. - 캘린더, 업무 정보, 음성 비서 등 다양한 기능을 한곳에서 사용할 수 있도록 설계했다. ## 기획 후 구현하는 AI 협업 방식 - Brittany는 먼저 요구사항을 정리한 뒤 구현하는 `plan-then-implement` 방식을 사용한다. - 기획 단계에서 Copilot이 질문을 연속적으로 던지도록 해 다음 사항을 구체화했다. - 애플리케이션이 어떻게 동작해야 하는지 - 사용자가 어떤 흐름으로 기능을 이용하는지 - 구현에 필요한 요구사항과 우선순위 - 충분히 구체화된 계획을 Copilot에 전달하고, 이를 기반으로 실제 구현을 진행했다. - 이 방식 덕분에 다른 업무를 병행하면서도 아이디어에서 작동하는 v1까지 하루 만에 도달할 수 있었다. ## 동기·비동기 에이전트 활용 - 동기식 개발에는 VS Code의 Agent Mode를 사용한다. - 서로 충돌하지 않는 작업은 최대 2개의 에이전트 워크플로로 동시에 진행한다. - 감독이 필요한 작업은 VS Code에서 직접 처리하고, 다음과 같은 범위가 명확한 작업은 Copilot Cloud Agent에 맡긴다. - 버그 수정 - 기술 부채 정리 - 비동기적으로 처리 가능한 소규모 변경 - 이를 통해 집중적인 개발과 백그라운드 작업을 병렬화한다. ## 기술 스택과 프로젝트 공개 - 애플리케이션은 다음 기술로 구성됐다. - **Electron**: 크로스 플랫폼 데스크톱 애플리케이션 프레임워크 - **React**: UI 컴포넌트와 상태 관리 - **Vite**: 빠른 개발 서버와 Hot Module Replacement를 제공하는 빌드 도구 - **Tailwind CSS**: 유틸리티 기반 CSS 프레임워크 - **WorkIQ MCP**: Microsoft 365 데이터에 접근하기 위한 MCP 서버와 CLI - 초기 구현 대부분을 Agent Mode로 진행했기 때문에 Electron 자체를 깊이 학습하지는 않았다고 설명한다. - 다만 공개 저장소로 정리하는 과정에서는 직접 코드를 읽고 불필요한 코드를 제거했다. - 에이전트는 코드를 추가하는 데는 능숙하지만, 불필요한 코드를 삭제하고 저장소를 단순화하는 작업에는 상대적으로 소극적이라는 경험도 공유한다. - 프로젝트는 `brittanyellich/command-center-lite` 저장소에서 확인할 수 있다. ## 실행에 필요한 환경 - 직접 프로젝트를 실행하려면 다음 조건이 필요하다. - Node.js 18 이상 - WorkIQ 설정을 위한 GitHub Copilot CLI - 캘린더 동기화를 위한 Microsoft 365 계정 - 음성 비서 기능을 위한 ElevenLabs 계정 - 구체적인 설치 및 실행 절차는 프로젝트의 README에 정리되어 있다. ## 작은 불편에서 시작하는 개발 - 가장 유용한 프로젝트는 거대한 아이디어보다 일상적인 불편을 해결하려는 시도에서 시작될 수 있다. - 기술 스택을 완벽히 이해한 뒤 시작하기보다, AI 도구의 도움을 받아 새로운 프레임워크와 서비스를 빠르게 조합할 수 있다. - Brittany의 조언은 간단하다. 직접 무언가를 만들어 보면서 새로운 AI 도구를 사용하는 방법을 익히라는 것이다. 개인 업무에서 반복적으로 앱을 전환하거나 정보를 수동으로 모으고 있다면, 먼저 해결할 불편을 하나 정한 뒤 Copilot으로 요구사항을 인터뷰하고 작은 v1을 만들어보는 접근이 실용적이다.

원문 읽기(새 탭에서 열림)

React모델 컨텍스트 프로토콜github-copilot-clinode.js+3

cloudflare·2026년 4월 15일원문

에이전트에 음성 추가하기 (새 탭에서 열림)

Cloudflare는 기존 Agents SDK에 실시간 음성 기능을 통합할 수 있는 실험적 라이브러리인 `@cloudflare/voice`를 공개했습니다. 이 도구를 사용하면 별도의 음성 전용 프레임워크로 옮길 필요 없이, 기존의 Durable Object 아키텍처와 WebSocket 연결 모델을 그대로 유지하면서 에이전트에 음성 인터페이스를 추가할 수 있습니다. 이를 통해 개발자는 텍스트와 음성 입력을 동일한 상태 공간에서 처리하고 SQLite를 통해 대화 이력을 영속적으로 관리하는 고도화된 음성 에이전트를 구축할 수 있게 됩니다. **@cloudflare/voice의 주요 구성 요소 및 기능** * **고차 에이전트 함수**: 전체 음성 대화를 지원하는 `withVoice(Agent)`와 음성을 텍스트로 변환하는 기능만 제공하는 `withVoiceInput(Agent)`을 통해 용도에 맞는 에이전트를 설계할 수 있습니다. * **React 및 클라이언트 지원**: React 앱에서 음성 상태와 전사 내용을 쉽게 관리할 수 있는 `useVoiceAgent`, `useVoiceInput` 훅과 프레임워크에 구애받지 않는 `VoiceClient`를 제공합니다. * **내장 Workers AI 제공자**: 외부 API 키 설정 없이도 즉시 시작할 수 있도록 Deepgram Flux 및 Nova 3(실시간 STT), Deepgram Aura(TTS) 등 Cloudflare Workers AI 기반의 엔진을 기본 지원합니다. * **개방형 인터페이스**: 특정 기술 스택에 종속되지 않도록 인터페이스를 작게 설계하여, 개발자가 필요에 따라 다양한 음성, 통신, 전송 계층 제공자를 선택하고 조합할 수 있습니다. **서버 및 클라이언트 구현 방식** * **서버 측 로직**: `Agent` 클래스를 `withVoice`로 감싸고, `onTurn()` 메서드 내에서 사용자 발화에 대한 응답 로직을 작성합니다. 이때 전사기(Transcriber)와 TTS 인스턴스를 설정에 추가하는 것만으로 음성 에이전트 서버가 완성됩니다. * **클라이언트 측 연결**: 단일 WebSocket을 통해 16kHz 모노 PCM 오디오 데이터를 스트리밍하며, 클라이언트 라이브러리는 통화 상태(status), 실시간 전사(transcript), 음소거(mute) 기능 등을 자동으로 관리합니다. * **통합 아키텍처**: 음성 기능이 추가되어도 동일한 Durable Object 인스턴스와 SQLite 기반의 대화 기록을 공유하므로, 기존 텍스트 기반 에이전트의 지식과 맥락을 그대로 활용할 수 있습니다. **실시간 음성 파이프라인의 작동 원리** * **지속적 전사 및 턴 감지**: 통화가 시작되면 에이전트는 지속적인 전사 세션을 생성하며, STT 모델이 사용자의 발화 종료 시점을 스스로 판단하여 안정적인 텍스트 결과(Turn)를 앱 로직에 전달합니다. * **문장 단위 스트리밍**: `onTurn()` 메서드가 텍스트 스트림을 반환하면, 파이프라인이 이를 문장 단위로 분할(Chunking)하여 각 문장이 준비되는 즉시 실시간으로 음성을 합성해 클라이언트로 전송합니다. * **데이터 영속성**: 모든 사용자 메시지와 에이전트의 응답은 SQLite 데이터베이스에 자동으로 기록되어, 네트워크 연결이 끊기거나 서버가 재배포되어도 끊김 없는 대화 경험을 보장합니다. 이 라이브러리는 음성 기능을 복잡한 별도의 서비스로 분리하지 않고 에이전트의 라이프사이클 내에 자연스럽게 통합했다는 점에서 매우 실용적입니다. 기존 Cloudflare Agents SDK를 사용 중인 개발자라면 추가적인 인프라 구축 없이 Workers AI의 성능을 활용해 지연 시간이 낮은 실시간 대화형 AI를 구축할 수 있으므로, 단순 텍스트 인터페이스를 넘어선 다중 모달(Multi-modal) 환경으로의 확장을 적극 고려해 보길 추천합니다.

React데이터베이스 설계sqlitespeech-to-text+3