Techlist.io - 한국 테크 블로그 큐레이터

figma3분 읽기큐레이션 요약

서버 측 샌드박싱

컨테이너와 seccomp는 가상 머신보다 가볍게 서버 측 작업을 격리할 수 있지만, 기본 설정만으로 안전한 샌드박스가 되는 것은 아니다. 컨테이너 탈출 위험은 런타임 구현, 운영체제 커널 기능, 런타임 설정에 좌우되며, 침해된 컨테이너가 호스트나 다른 시스템에 미치는 영향까지 함께 제한해야 한다. Figma는 컨테이너의 OS 수준 격리 기능과 seccomp를 활용해 성능과 보안 사이의 균형을 맞추고 있다. ## 컨테이너와 가상 머신의 차이 - 가상 머신은 하이퍼바이저를 통해 운영체제 수준에서 격리한다. - 컨테이너는 호스트 OS의 커널 기능을 공유하며, 다음과 같은 기능을 이용해 격리한다. - Linux namespaces - cgroups - 권한 강등(privilege dropping) - seccomp - SELinux, AppArmor 같은 필수 접근 제어(MAC) - 컨테이너는 VM보다 가볍고 효율적이지만, 격리 수준을 사용자가 직접 세밀하게 설정해야 한다. - 설정 자유도가 높은 만큼 잘못된 구성으로 인해 보안 취약점이 발생할 가능성도 크다. ## 샌드박싱이 필요한 이유 - 이미지 처리와 데이터 파싱처럼 애플리케이션에 필수적인 기능은 외부 입력을 다루므로 취약점 위험을 포함한다. - 모든 보안 취약점을 사전에 제거하는 것은 비용이 많이 들고 현실적으로 어렵다. - 따라서 취약한 작업이 실행되더라도 호스트와 다른 시스템으로 피해가 확산되지 않도록 서버 측 샌드박싱, 즉 workload isolation을 적용한다. - 격리 설계에서는 두 가지 질문을 중심으로 보안성을 평가한다. - 악성 작업이 컨테이너에서 탈출해 호스트를 변경하거나 장악할 수 있는가? - 컨테이너를 탈출하지 못하더라도 컨테이너 권한으로 다른 시스템에 접근하거나 피해를 줄 수 있는가? ## 컨테이너에서 호스트로 이어지는 공격 표면 컨테이너 탈출 가능성은 컨테이너 자체보다 여러 구성 요소의 조합에 의해 결정된다. - 주요 공격 표면은 다음 세 가지다. - 컨테이너 런타임 구현의 버그 - 런타임이 사용하는 운영체제 커널 기능과 인터페이스 - 런타임 보안 설정 및 구성 오류 - Linux 환경에서 Docker는 일반적으로 runC 런타임을 사용한다. - runC와 Docker는 namespaces, cgroups, 권한 강등, seccomp, SELinux, AppArmor 등을 조합해 격리를 제공한다. - 커널 취약점이나 런타임 구현 오류, 잘못된 설정이 있으면 악성 작업이 다음과 같은 행위를 할 수 있다. - 호스트 파일 수정 - 호스트에서 코드 실행 - 컨테이너 탈출 - 컨테이너의 기본 설정이 과거보다 안전해졌더라도, 특정 샌드박싱 용도에 충분한지는 사용자가 직접 검증해야 한다. ## 침해된 컨테이너의 피해 제한 컨테이너 내부에서 작업이 침해되었다고 가정하고, 호스트뿐 아니라 주변 시스템에 대한 접근도 차단해야 한다. - 컨테이너 설정을 강화해 호스트 장악을 방지해야 한다. - 컨테이너에 다음 자원을 불필요하게 제공하지 않는 것이 중요하다. - 네트워크 장치 - 인증 자격 증명 - 다른 작업의 데이터 - 컨테이너를 별도의 격리된 네트워크에 배치할 수 있다. - 오케스트레이션 시스템을 사용해 입력은 통제된 채널로 전달하고, 출력도 검증·제한된 방식으로 수집한다. - 핵심은 “컨테이너가 침해되지 않을 것”이 아니라 “침해되더라도 피해 범위를 제한할 것”이라는 방어적 설계다. ## seccomp의 역할 - seccomp(secure computing mode)는 프로그램이 호출할 수 있는 시스템 콜을 제한하는 Linux 기능이다. - 시스템 콜을 허용 목록 또는 제한 정책으로 관리하면, 컨테이너 프로세스가 커널과 상호작용할 수 있는 범위를 줄일 수 있다. - 컨테이너 격리는 런타임, 커널 기능, 설정의 결합으로 구현되므로 seccomp 역시 다른 보안 기능과 함께 사용해야 한다. - 제공된 글 내용은 seccomp 보안 모델을 소개하는 부분에서 중단되어 있어, 이후 Figma의 구체적인 nsjail 구성과 운영 방식은 확인할 수 없다. 컨테이너를 서버 측 샌드박스로 사용할 때는 기본 설정을 그대로 신뢰하지 말고, 최소 권한·제한된 시스템 콜·격리된 네트워크·자격 증명 차단을 함께 적용하는 것이 좋다. 특히 컨테이너 탈출 방지와 침해 이후 피해 제한을 별개의 보안 목표로 보고 설계해야 한다.

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

FedRAMP를 향한 (새 탭에서 열림)

피그마(Figma)는 미국 연방 정부의 보안 인증 제도인 FedRAMP(Federal Risk and Authorization Management Program) 'Moderate' 등급의 인증 절차를 본격적으로 시작하며 공공 부문으로의 확장을 공식화했습니다. 이번 인증 추진은 공공 부문의 디지털 전환과 사용자 경험 개선을 지원하기 위한 핵심 단계로, 이를 통해 정부 기관은 피그마의 협업 기능을 안전하게 활용하여 더 나은 공공 서비스를 설계할 수 있게 됩니다. 피그마는 전담 팀을 구성하고 보안 표준을 강화함으로써 공공 분야에서도 민간 수준의 혁신적인 디자인 협업 환경을 구축하는 것을 최종 목표로 하고 있습니다. ### FedRAMP 인증 추진 배경과 의미 * 미국 정부 데이터를 다루는 애플리케이션에 필수적인 보안 인증인 FedRAMP 'Moderate' 등급 획득을 위한 '진행 중(in process)' 상태로 Marketplace에 등재되었습니다. * 이는 피그마가 연방 정부의 엄격한 보안 및 개인정보 보호 표준을 준수하기 위한 기술 감사를 거쳤으며, 최종 인증을 위한 마지막 단계에 진입했음을 의미합니다. * 팬데믹 이후 가속화된 공공 부문의 원격·하이브리드 근무 환경에서, 보안이 담보된 클라우드 기반 협업 도구에 대한 수요를 충족시키기 위한 결정입니다. ### 공공 부문에 제공하는 기술적 가치 * 정부 기관, 계약업체 및 공공 프로젝트 수행자들이 피그마 내에서 직접 소프트웨어를 설계하고 신속하게 프로토타입을 테스트할 수 있는 환경을 제공합니다. * 플랫폼에 구애받지 않는 브라우저 기반 협업 특성을 통해, 기술 도입이 늦었던 정부 조직 내에서도 부서 간 장벽을 허물고 디자인 반복 주기를 단축할 수 있습니다. * 더 접근성 높고 포용적인 디자인을 가능하게 함으로써, 궁극적으로 정부 애플리케이션의 UI/UX를 개선하고 대국민 서비스의 신뢰도를 높이는 데 기여합니다. ### 조직 역량 강화 및 향후 전략 * Zscaler, Datadog 등에서 공공 분야 경험을 쌓은 전문가를 영입하여 민간 부문의 성공 사례를 공공 부문의 요구사항에 맞춰 이식하는 0 to 1 전략을 실행 중입니다. * 내부적으로 상업용 팀과 정부 전담 팀 간의 양방향 지식 공유 체계를 구축하여, 서로 다른 규제 환경에서도 최적의 사용자 경험을 제공할 수 있도록 역량을 결집하고 있습니다. * 인증 완료 이후에는 연방 정부 규모의 대규모 데이터를 안전하게 호스팅하고, 복잡한 이해관계자들이 참여하는 공공 프로젝트의 효율성을 극대화할 예정입니다. 피그마의 이번 행보는 보안이 최우선인 공공 영역에서도 현대적인 협업 디자인 도구가 필수적임을 시사합니다. 공공 서비스 관련 프로젝트를 운영하거나 준비 중인 조직이라면, 피그마의 FedRAMP 인증 완료 이후 제공될 고수준의 보안 환경을 활용해 정부 표준에 부합하는 디지털 혁신을 계획해 볼 수 있습니다.

figma3분 읽기큐레이션 요약

시시르 메로트라가

좋은 팀은 고객을 위한 제품뿐 아니라 팀의 협업 방식과 문화를 함께 설계한다. 특히 회의는 목적에 따라 구분하고, 반복 가능한 의식과 템플릿으로 운영해야 조직의 목표 달성과 구성원의 몰입을 높일 수 있다. 이 글은 Shishir Mehrotra가 1,000명 이상을 인터뷰하며 정리한 팀 회의 운영 원칙 중 일부를 소개한다. ## 팀 문화는 반복되는 의식으로 만들어진다 - 조직의 문화를 실제 업무에서 설명할 때 구성원들은 결국 회사의 **회의, 행동 규범, 업무 방식**을 이야기하게 된다. - 좋은 팀의 “황금 의식”은 다음 세 가지 특징을 갖는다. - 이름이 붙어 있다. - 입사 후 첫 주 안에 모든 직원이 알게 된다. - 누구나 활용할 수 있도록 템플릿화되어 있다. - 팀의 업무 방식을 처음부터 새로 만들기보다, 다른 훌륭한 팀의 검증된 의식과 프레임워크를 참고하는 것이 효과적이다. ## 고객 제품과 팀 제품을 함께 만들어야 한다 - 기업이 만드는 제품은 고객을 위한 제품만이 아니다. - 구성원이 일하고 협업하며 성장하는 경험도 하나의 “직원 제품”으로 봐야 한다. - 이 직원 제품은 추상적인 문화보다 다음과 같은 구체적인 의식으로 드러난다. - 정기 회의 - 의사결정 절차 - 피드백 방식 - 정보 공유 규칙 - 팀 간 협업 ritual - 따라서 제품을 설계하듯 팀의 업무 방식에도 목적, 구조, 사용자 경험을 세심하게 설계해야 한다. ## 회의는 목적에 따라 세 가지로 나뉜다 ### 1. 진행 회의(Cadence meetings) - 스태프 회의, 스탠드업, 프로젝트 싱크 등이 해당한다. - 같은 사람들이 정기적으로 만나 목표를 설정하고, 실행 상황을 점검하며, 결과를 회고한다. - 핵심 질문은 **“우리가 세운 목표대로 진행되고 있는가?”**이다. - 반복성과 지속성이 중요하므로 일정한 주기와 포맷을 유지하는 것이 좋다. ### 2. 촉진 회의(Catalyst meetings) - 의사결정 회의, 제품 리뷰, 디자인 비평 등이 해당한다. - 논의나 피드백을 통해 프로젝트의 방향을 바꾸고 진전을 만들어낸다. - 핵심 질문은 **“우리의 질문에 대한 답을 얻었는가?”**이다. - 방향 전환과 결정을 빠르게 만들 수 있지만, 지나치게 많으면 구성원의 피로와 소진을 유발한다. ### 3. 맥락 공유 회의(Context meetings) - 전사 회의, 오프사이트, 신입사원 오리엔테이션, 일대일 면담 등이 해당한다. - 정보와 통찰을 공유하고, 구성원 간 연결을 형성하며, 업무에 필요한 배경을 제공한다. - 핵심 질문은 **“이 회의 후 우리가 업무를 더 잘 수행할 수 있게 되었는가?”**이다. - 참석자와 결과의 범위가 넓기 때문에 단순한 진행 상황 보고보다 이해와 연결 형성에 초점을 둬야 한다. ## 장기 목표는 꾸준한 회의 리듬으로 달성한다 - 존 F. 케네디는 1960년대 안에 달에 사람을 보내겠다는 목표를 제시하고, NASA 책임자와 매주 회의를 진행했다. - 이는 장기 목표를 정기적인 점검과 실행으로 연결한 전형적인 진행 회의다. - 반복 회의는 장기 프로젝트를 계속 움직이게 하지만, 그 자체로는 영감을 주기 어렵다. - 많은 구성원은 진행 회의를 다음과 같이 느낀다고 답했다. - 지루하다. - 의무적으로 참석해야 하는 일처럼 느껴진다. - 비인간적이고 번거롭다. - 뛰어난 팀은 정기 회의에 고유한 의식과 참여 방식을 추가해 단순한 상태 보고를 넘어 몰입과 소속감을 만든다. - 회의의 목적에 맞는 템플릿과 의식을 활용하면 반복성을 유지하면서도 회의 경험을 개선할 수 있다. ## 실무 적용을 위한 추천 - 모든 회의를 진행·촉진·맥락 공유 중 하나로 분류한다. - 회의 초대장에 목적과 성공 기준을 명시한다. - 진행 회의: 목표 대비 진행 상황 확인 - 촉진 회의: 특정 질문에 대한 결정 도출 - 맥락 회의: 정보 공유와 업무 이해도 향상 - 반복 회의에는 고유한 이름, 고정된 진행 순서, 문서 템플릿을 부여한다. - 단순 보고만 반복되고 결정을 만들지 못하는 회의는 주기나 참석자를 줄이거나 비동기 방식으로 전환한다. - 제공된 글은 Rule #4 초반에서 끝나므로, 이후 원칙의 전체 내용은 포함되어 있지 않다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

가치 있는 디자인 커리어를 위한

Dan Mall은 25년간 디자이너, 창업가, 교육자, 작가로 활동하며 얻은 경험을 바탕으로 지속 가능한 디자인 커리어의 원칙을 제시한다. 글의 중심 메시지는 모든 선택을 하나의 ‘베팅’으로 보고, 가치 있는 목표를 설정한 뒤 자신의 강점을 활용해 실행하라는 것이다. 또한 시작하기 전에 원하는 최종 결과를 분명히 해야 복잡한 커리어 결정을 효과적으로 이끌 수 있다고 강조한다. ## 다양한 역할을 통한 지속적인 성장 - Mall은 1998년 교회 웹사이트를 만들며 디자인을 시작한 뒤 에이전시, 스타트업, 교육, 저술 등 여러 영역을 경험했다. - 직접 에이전시를 운영하고 두 개의 스타트업을 공동 창업했으며, 견습 프로그램을 운영하고 수천 명의 학생을 가르쳤다. - 이러한 경험을 통해 디자인 역량은 최신 도구나 트렌드를 따라가는 것만이 아니라, 문제를 새롭게 해결하고 지속적으로 성장하는 과정에서 확장된다고 설명한다. - 디자인 시스템 교육 기관인 Design System University를 통해 대규모 조직이 디자인을 체계적으로 운영하도록 돕고 있다. ## 가치 있는 목표를 선택하기 - 새로운 일을 시작하기 전, 다음과 같은 질문을 던진다. - 이 일의 최종 목적은 무엇인가? - 결과적으로 지금보다 더 나은 상태에 도달할 수 있는가? - 목표는 흥미롭고, 중요하며, 동시에 도전적이어야 한다는 Michael Bungay Stanier의 기준을 소개한다. - Mall은 특히 ‘흥미로운가’를 중요하게 여긴다. 자신을 움직일 만큼 설레지 않는 일은 대체로 추진하지 않는다. - 가족과 더 많은 시간을 보내기 위해 기존의 꿈의 직장을 떠나 자신의 에이전시를 만든 사례를 들며, 개인의 가치와 목표가 커리어 선택의 출발점이 될 수 있다고 설명한다. ## 자신의 불공정한 강점에 베팅하기 - 모든 의사결정은 다른 선택지를 포기한다는 점에서 일종의 베팅이다. - 직업 선택, 이직과 이주, 계약과 영업, 주택 구매 같은 결정뿐 아니라 일상적인 선택도 기회비용을 수반한다. - 성공 가능성을 높이려면 누구나 가진 일반적인 조건이 아니라 자신만의 ‘불공정한 강점’을 활용해야 한다. - 전문 지식과 경험 - 업계 평판과 네트워크 - 자금과 자원 - 특정 분야에 대한 독특한 통찰 - 유리한 위치나 교육 배경 - Mall은 이러한 요소를 MILES 프레임워크로 정리한다. - **Money**: 자금 - **Intelligence & Insight**: 지능과 통찰 - **Location & Luck**: 위치와 운 - **Education & Expertise**: 교육과 전문성 - **Status**: 평판과 지위 - 자신의 에이전시를 시작할 때 이미 보유한 에이전시 경험, 좋은 평판, 안정적인 고객 흐름이 성공 확률을 높이는 강점으로 작용했다. - Design System University 역시 10년간 디자인 시스템과 대규모 디자인을 다뤄온 경험, 해당 분야의 문제와 패턴에 대한 깊은 이해가 기반이 되었다. - 강점은 성공을 보장하지 않지만, 같은 목표를 향한 베팅의 확률을 높여준다. ## 최종 결과를 먼저 정하고 시작하기 - Stephen Covey의 원칙인 “끝을 염두에 두고 시작하라”를 커리어와 프로젝트에 적용한다. - 시작 전에 명확하고 달성 가능한 최종 목표를 정하면 어떤 활동에 집중할지 판단하기 쉬워진다. - Mall은 컨퍼런스 발표를 시작할 때, 자신이 존경하던 웹 디자인 행사인 An Event Apart의 연사가 되는 것을 장기 목표로 삼았다. - 목표를 구체적으로 설정하면 막연한 희망이 아니라 필요한 역량, 평판, 작업물을 역산해 준비할 수 있다. - 따라서 프로젝트나 커리어 결정을 내릴 때 “무엇을 하고 싶은가”뿐 아니라 “어떤 결과에 도달하고 싶은가”를 먼저 정의하는 것이 중요하다. ## 실용적인 적용 새로운 커리어 기회를 검토할 때는 먼저 그 목표가 자신에게 흥미롭고 중요한지 확인하고, 현재 가진 전문성·네트워크·평판이 어떻게 성공 가능성을 높이는지 점검하는 것이 좋다. 이후 원하는 최종 상태를 구체적으로 정한 뒤, 그 결과에서 거꾸로 필요한 경험과 실행 단계를 설계하면 더 현실적이고 지속 가능한 선택을 할 수 있다.

원문 읽기(새 탭에서 열림)
figma4분 읽기큐레이션 요약

피그마의 오픈 캔버

Figma의 오픈 캔버스와 같은 시각적 협업 도구는 학생마다 다른 학습 방식·능력·정서적 상황을 존중하는 포용적 교실을 만드는 데 도움을 준다. 글은 성적과 정해진 절차에 맞춘 획일적 교육만으로는 현재의 교육 위기와 학생들의 다양한 요구를 해결할 수 없으며, 학생에게 선택권과 학습 주도권을 줘야 한다고 주장한다. 이를 위해 UDL과 5E 모델 같은 학습 프레임워크, 그리고 협업형 디지털 도구의 활용을 제안한다. ### 획일적 교육이 만든 ‘로봇 학생’의 한계 - Lisa Highfill은 교직 초기의 학생들이 지시받은 대로만 행동하고, 과제 점수와 마감일에만 관심을 보였다고 회고한다. - 정해진 수업안과 엄격한 표준 중심 교육은 교사의 수업 설계 자율성과 학생의 학습 참여를 제한했다. - 성적과 체크리스트에 집중하는 방식은 학생이 자신의 방식으로 건강하게 학습하고 동기를 형성하는 데 방해가 된다. - 표준화 시험에 대한 지출은 증가했지만, 학생들의 학업 성취와 정신건강 문제가 자동으로 개선되지는 않았다. ### 미국 교육이 겪는 복합적 위기 - 2023년 NAEP에서 미국 13세 학생들의 수학·읽기 성적이 역사적으로 낮은 수준을 기록했다. - 교사 부족의 원인으로 낮은 사기와 보수, 안전 문제, 번아웃 등이 제시된다. - 장애를 가진 학생 수가 지난 20년 동안 증가했으며, 18세 미만 자녀를 둔 부모의 40%가 자녀의 정신건강을 주요 걱정거리로 꼽았다. - 이러한 문제는 코로나19로 악화됐지만, 교육 재정 감소와 학업 성취 압박 등 코로나 이전부터 존재했다. - 따라서 모든 학생에게 같은 방식과 기준을 적용하는 ‘one-size-fits-all’ 접근은 더 이상 효과적이지 않다. ### 학생의 선택권과 학습 주도권 - Lisa는 수업을 목적에 맞게 설계하면 학생에게 학습 방법을 선택하게 하고 주도권을 키울 수 있다고 본다. - 그녀는 교사가 단순히 정해진 교재를 전달하는 사람이 아니라, 학습 경험을 설계하는 디자이너가 되어야 한다고 주장한다. - 2016년에는 탐구 중심 학습을 위한 디지털 수업 자료인 ‘Hyperdocs’를 만들었다. - Hyperdocs는 5E 모델에서 발전한 ‘탐색-설명-적용’ 학습 순환을 기반으로 한다. - 코로나19로 원격·하이브리드 수업이 확산되자, 불안과 우울을 겪는 학생들의 연결감과 참여를 높일 도구에 대한 교사들의 수요가 커졌다. ### 보편적 학습설계(UDL) - UDL은 다양한 학생이 같은 교실에서 학습 목표에 접근할 수 있도록 설계하는 교육 프레임워크다. - 학생의 차이를 고려해 다음 세 가지를 다양화한다. - **표현 방식**: 정보를 글, 이미지, 영상 등 여러 방식으로 제공 - **학습 결과를 표현하는 방식**: 글쓰기, 발표, 시각 자료 제작 등 여러 선택지 제공 - **참여 방식**: 학생의 관심과 능력, 정서적 상태에 맞는 참여 기회 마련 - 장애 학생뿐 아니라 학습 스타일과 배경이 다른 모든 학생에게 도움이 되는 접근이다. - 포용적 교실은 특별한 지원이 필요한 학생뿐 아니라 전체 학생의 학습에도 긍정적인 영향을 줄 수 있다. ### 5E 학습 모델과 순환적 탐구 - 5E 모델은 개념의 사실만 외우는 것이 아니라, 사실 간의 관계와 실제 적용까지 이해해야 한다는 연구에서 출발했다. - 다섯 단계는 다음과 같다. - **Engage**: 주제에 관심을 갖고 참여하기 - **Explore**: 직접 탐색하고 질문하기 - **Explain**: 개념과 발견 내용을 설명하기 - **Elaborate**: 새로운 상황에 적용하고 확장하기 - **Evaluate**: 이해도와 학습 과정을 평가하기 - 이 과정은 직선형 절차라기보다 필요에 따라 반복되는 순환 구조다. - Lisa가 활용한 ‘탐색-설명-적용’ 방식도 이 모델에서 파생된 학생 주도형 접근이다. ### 오픈 캔버스와 포용적 협업 - 시각적 협업 도구는 학생이 자신의 생각을 글뿐 아니라 이미지, 도형, 구조화된 보드 등 다양한 방식으로 표현하게 한다. - 하나의 공유 공간에서 교사와 학생이 함께 아이디어를 만들고 수정하며 피드백을 주고받을 수 있다. - 원격·하이브리드 수업에서도 학생의 참여와 소속감을 높이는 데 활용할 수 있다. - 학생마다 다른 배경, 능력, 학습 방식, 정서적 상태를 수용하면서도 공동의 학습 목표를 유지할 수 있다는 점이 핵심이다. 교사는 정답과 절차를 일방적으로 전달하기보다, 학생이 탐색하고 표현하고 선택할 수 있는 학습 환경을 설계해야 한다. Figma 같은 협업형 오픈 캔버스는 UDL과 5E 모델을 실제 수업에 적용하고, 더 유연하고 포용적인 학습 경험을 만드는 실용적 도구가 될 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

피그마와 구글: 일본

일본의 K-12 학생들이 개인용 Chromebook에서 업계 표준 디자인 도구를 사용할 수 있도록 Figma가 Google for Education과 협력을 확대했다. 일본 학교는 Google 관리자 콘솔을 통해 Figma Enterprise 라이선스를 무료로 배포·관리할 수 있으며, 이를 통해 학생들의 디자인, 협업, 문제 해결 역량을 키울 수 있다. 이 사업은 일본의 1인 1기기 정책인 GIGA 스쿨 프로그램과 결합해 디지털 디자인 교육의 접근성을 높이는 데 목적이 있다. ## 일본 K-12 학교에 Figma·FigJam 제공 - Figma는 Google for Education과 협력해 일본의 초·중·고등학교에 Figma와 FigJam을 제공한다. - 학생들이 학교에서 가장 널리 사용하는 개인용 기기인 Chromebook으로 디자인 도구에 접근할 수 있다. - 학교 및 교육구는 Google Workspace for Education과 Google 관리자 콘솔을 이용해 Figma Enterprise 라이선스를 무료로 배포하고 관리할 수 있다. - 기존에는 디지털 디자인 소프트웨어를 컴퓨터실이나 특정 교실에서만 사용할 수 있는 경우가 많았지만, 이번 협력으로 학생 개인 기기에서 지속적으로 사용할 수 있게 된다. - 교육구는 Figma의 일본 교육 프로그램을 통해 교실 도입을 신청할 수 있다. ## 디자인 교육이 필요한 이유 - 디자인은 더 이상 전문 디자이너만의 기술이 아니라 모든 직업에서 요구되는 역량으로 확장되고 있다. - Figma는 디자인 학습이 다음과 같은 능력을 기르는 데 도움이 된다고 설명한다. - 복잡한 문제를 구조화하고 해결하는 능력 - 시각적 의사소통 능력 - 팀 협업 능력 - 창의적 표현과 아이디어 구체화 - Figma CEO Dylan Field는 특정 학위나 배경을 가진 사람만 디자인·소프트웨어 관련 기회를 얻는 것이 아니라, 모든 학생이 이러한 기회에 접근할 수 있어야 한다고 강조한다. - McKinsey 연구에 따르면 디자인 중심 기업은 업계 평균보다 5년간 매출 성장률이 32%포인트, 주주수익률이 56%포인트 더 높았다. - 비디자이너 직군에서도 디자인을 이해하고 활용하는 ‘디자인 리터러시’가 중요해지고 있다. ## FigJam을 활용한 참여형 수업 - FigJam은 온라인 화이트보드이자 협업 도구로 활용된다. - 교사와 학생이 함께 다음 활동을 수행할 수 있다. - 수업 계획 작성 - 그룹 프로젝트 진행 - 학습 자료와 스터디 가이드 제작 - 아이디어 브레인스토밍 - 디자인 콘셉트와 앱 프로토타입 개발 - 미국에서 진행된 초기 베타 프로그램에서는 50개 주의 학생과 교사가 Chromebook으로 Figma 제품을 사용했다. - 학생들은 비영리단체를 위한 디자인, 지역 행정 서비스를 개선하는 앱 프로토타입 등 실제 문제와 연결된 프로젝트를 진행했다. - 교사들은 FigJam을 활용해 기존의 일방적인 수업을 공동 창작과 상호작용 중심의 수업으로 바꿀 수 있었다. ## 일본의 교육 환경과 디지털 전환 - 일본은 가구의 90% 이상이 인터넷을 이용하고, 고등학교 졸업률이 95%를 넘는 등 교육 접근성과 형평성을 중시해 왔다. - 반면 교실에서 컴퓨터를 활용하는 속도는 다른 교육 선진국에 비해 상대적으로 느렸다. - 일본 문부과학성은 현대화된 노동시장에 대비하기 위해 2019년 GIGA 스쿨 프로그램을 시작했다. - GIGA 스쿨은 모든 학생에게 기기 한 대와 학교 내 고속 네트워크를 제공하는 1인 1기기 정책이다. - Figma의 웹 기반 도구는 별도 설치나 고사양 컴퓨터 없이 Chromebook에서 사용할 수 있어, 이 디지털 교육 인프라를 디자인 학습으로 확장한다. ## 일본의 차세대 디자인 인재 육성 - 일본은 대량생산 노트북, 휴대용 음악 플레이어, 신칸센 등 세계 기술 발전을 이끈 혁신 사례를 보유하고 있다. - Figma와 Google은 일본 학생들이 이러한 창의적·기술적 전통을 이어갈 수 있도록 조기에 디자인 경험을 제공하려 한다. - 개인 기기에서 디자인 도구를 사용할 수 있으면 학생들은 교실 안팎에서 지속적으로 아이디어를 실험하고 협업할 수 있다. - 결과적으로 이번 협력은 단순한 소프트웨어 보급을 넘어, 학생들이 미래의 업무에 필요한 창의성·협업·시각적 사고를 습득하도록 돕는 교육 접근성 확대 정책으로 볼 수 있다. 학교나 교육기관은 Chromebook과 Google Workspace를 기반으로 Figma를 도입해, 수업 자료 제작부터 팀 프로젝트와 프로토타이핑까지 학생 중심의 실습형 학습 환경을 구축하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Figma 및 FigJam 파일용

Figma는 유럽 고객의 데이터 보호와 규제 준수를 지원하기 위해 Figma·FigJam 파일을 EU 내에 호스팅하는 선택권을 제공하기 시작했습니다. 파일 데이터의 주 저장 위치는 독일 프랑크푸르트, 백업 위치는 아일랜드 더블린이며 AWS 인프라를 사용합니다. 다만 모든 데이터가 EU에 저장되는 것은 아니며, 이 기능은 Figma Enterprise 고객에게만 제공됩니다. ## EU 데이터 호스팅 도입 배경 - 유럽 조직은 GDPR을 비롯한 데이터 보호·개인정보 규제를 중요하게 고려하고 있습니다. - Figma는 EU Cloud Code of Conduct 준수 마크를 획득했으며, 기존 보안·개인정보 보호 체계를 강화하는 차원에서 EU 데이터 레지던시를 도입했습니다. - Volkswagen Group도 설계 도구의 데이터가 EU 내에 저장되는 기능을 데이터 보호 측면에서 중요한 요구사항으로 평가했습니다. - EU 호스팅을 이용하면 클라우드 기반 플랫폼의 확장성과 효율성을 유지하면서 데이터 저장 위치를 보다 세밀하게 통제할 수 있습니다. ## EU에 저장되는 데이터 - 초기 대상은 Figma 및 FigJam 파일의 문서 콘텐츠입니다. - 지원되는 파일 유형과 저장 범위는 Figma의 별도 도움말 문서에서 확인해야 합니다. - 파일 데이터의 실제 저장 위치는 다음과 같습니다. - 주 저장소: 독일 프랑크푸르트 - 백업 저장소: 아일랜드 더블린 - 인프라는 기존 클라우드 제공업체인 AWS를 사용합니다. ## EU에 포함되지 않는 데이터 - 사용자 메타데이터와 로그인 데이터는 EU 내에 호스팅되지 않습니다. - 데이터 전송 과정에서 생성되는 일부 데이터는 제한된 기간 동안 EU 외부에 임시 저장될 수 있습니다. - 따라서 “EU 호스팅”은 모든 Figma 관련 데이터가 EU 국경 밖으로 나가지 않는다는 의미가 아니라, 특정 파일 콘텐츠의 저장 위치를 EU로 제한하는 기능입니다. - 조직은 도입 전에 파일 유형별 EU 저장 가능 여부와 제외되는 데이터 범위를 확인해야 합니다. ## 이용 대상과 기존 파일 마이그레이션 - EU 데이터 호스팅은 Figma Enterprise 요금제 고객에게만 제공됩니다. - 기존 고객도 Enterprise로 이용 중이거나 Enterprise로 업그레이드하면 미국에서 EU로 기존 파일을 이전할 수 있습니다. - 마이그레이션 일정은 Figma 계정 관리자가 고객과 조율합니다. - Enterprise 업그레이드 후 데이터 이전 대기 목록에 등록할 수 있습니다. - 다른 요금제 고객은 Enterprise 데모나 상담을 신청해야 합니다. ## 보안 및 규제 준수 체계 EU 데이터 레지던시는 Figma의 기존 보안 인증과 함께 제공됩니다. - SOC 2 Type II 보고서 - ISO 27018 및 ISO 27001 인증 - EU Cloud Code of Conduct Level 2 준수 ## 도입 시 고려할 점 EU 내 파일 저장이 법적·조직적 요구사항에 부합하는지 검토하려면 저장 대상 데이터, EU 외부에 남는 메타데이터, 전송 중 임시 저장 가능성, 마이그레이션 범위를 함께 확인해야 합니다. EU 데이터 주권과 파일 위치 통제가 중요한 대기업이라면 Enterprise 요금제와 공식 파일 유형별 저장 정책을 기준으로 도입 여부를 판단하는 것이 적절합니다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

코드 생성이 (진짜)

코드 생성(codegen)은 디자인-개발 과정을 완전히 자동화하기보다, 개발자가 더 빠르고 정확하게 작업하도록 돕는 확장 도구로 활용할 때 가장 효과적이다. 특히 AI 코드 생성 결과는 정확성과 유용성에 한계가 있으므로, 개발자를 대체하기보다 적절한 컴포넌트·속성·코드 패턴을 제안해 초기 작업을 앞당기는 방향이 현실적이다. Figma는 이를 “0에서 1”이 아닌 “0에서 0.5”로 빠르게 이동시키는 도구로 설명한다. ### 코드 생성의 범위와 현실 - 코드 생성은 정해진 규칙이나 명세를 바탕으로 코드를 자동 생성하는 과정이다. - 범위가 넓으며 다음과 같은 형태를 포함한다. - IDE의 자동 완성 기능 - 반복적인 코드 패턴을 위한 스니펫과 템플릿 - Bubble 같은 비주얼 프로그래밍·노코드 도구 - GitHub Copilot, Replit Ghostwriter 같은 AI 기반 코드 생성 도구 - Stack Overflow 2023 조사에서 개발자의 82%가 AI 도구를 사용해 코드를 작성한다고 답했다. - 반면 AI 도구의 정확성을 매우 신뢰한다고 답한 비율은 3%에 불과했다. - 따라서 코드가 생성된다는 사실보다, 실제 프로젝트의 프레임워크와 코드베이스에 맞고 개발자가 유용하게 사용할 수 있는지가 더 중요하다. ### 디자인을 코드로 그대로 변환하기 어려운 이유 - Figma는 Dev Mode를 처음 개발할 때 디자인을 코드로 자동 변환하는 것을 목표로 했다. - 초기 결과는 가능성을 보였지만, 다양한 개발자의 요구와 프레임워크를 모두 만족하는 코드를 만들기는 어려웠다. - 자동 생성된 코드가 문법적으로 맞더라도 팀의 컴포넌트 구조, 네이밍 규칙, 상태 관리 방식과 맞지 않으면 실무에서는 유용하지 않을 수 있다. - 이에 따라 Figma는 디자인을 코드로 직역하는 방식보다, 디자인과 개발 사이의 해석과 협업을 보조하는 방식으로 방향을 전환했다. ### 개발자를 대체하는 도구가 아닌 지능 증폭 도구 - 코드 생성은 개발자를 대신하는 자동화 시스템보다 개발자의 능력을 확장하는 도구로 보는 편이 적절하다. - 글은 이를 **지능 증폭(Intelligence Amplification, IA)**으로 설명한다. - 복잡한 문제를 이해하고 - 필요한 정보를 빠르게 찾으며 - 해결책을 도출하는 인간의 능력을 강화하는 접근이다. - AI가 기술이 주도하는 미래를 상징한다면, IA는 사람이 주도권을 유지한 채 기술의 도움을 받는 방식이다. - 개발자는 최종 구조와 구현 방식을 결정하고, codegen은 탐색·반복·초기 작성에 드는 시간을 줄인다. ### “0에서 0.5”까지 빠르게 이동하기 - 디자인 시스템과 컴포넌트 라이브러리를 사용하는 제품에서는 codegen이 핸드오프 과정의 추측을 줄일 수 있다. - 디자인 요소에 대응하는 컴포넌트 이름이나 속성 값을 제안해 개발자가 어떤 도구를 사용할지 빠르게 판단하도록 돕는다. - 디자인 시스템을 공구 상자에 비유하면, codegen은 상황에 맞는 공구와 사용법을 추천하는 역할을 한다. - 완성된 코드를 제공하기보다는 빈 화면에서 작업을 시작할 수 있는 출발점을 만들어 준다. - 즉, “0에서 1”까지 완성하는 자동화보다 “0에서 0.5”까지 빠르게 진입하게 하는 보조 기능에 더 큰 가치가 있다. ### 팀과 코드베이스에 맞춘 구체적인 활용 - codegen의 효과는 일반적인 자동화 도구보다 특정 팀·회사·워크플로에 맞게 적용할 때 커진다. - 디자인 시스템과 컴포넌트 라이브러리가 이미 Figma에 있다면 별도의 완전 자동화 디자인-코드 변환 앱이 반드시 필요하지 않다. - 대신 다음 기능을 활용하는 편이 실용적이다. - 디자인 토큰과 변수 참조 - 컴포넌트 및 속성 문서 확인 - 팀 전용 codegen 플러그인 구축 - 프로젝트 규칙에 맞춘 사용자 정의 코드 스니펫 생성 - 이러한 정보와 힌트는 개발자가 디자인을 빠르게 해석하고 직접 코드를 작성하도록 돕는다. ### 실용적인 결론 codegen은 생성된 코드를 그대로 채택하는 자동화 수단이 아니라, 팀의 디자인 시스템과 개발 규칙을 이해한 상태에서 적절한 컴포넌트와 구현 방향을 제안하는 보조 수단으로 사용하는 것이 좋다. 특히 토큰, 문서, 컴포넌트 메타데이터, 사용자 정의 스니펫을 코드베이스와 연결하면 개발자의 판단을 유지하면서 반복 작업과 초기 탐색 시간을 크게 줄일 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

핵심 요약:

AI 시대의 인간적 성장과 혁신은 기존의 역할·효율성·생산성 기준에서 벗어날 때 가능하다는 내용이다. 글은 비선형적 사고와 창의적 도약, 새로운 진로를 개척하는 용기, 직무 간 경계를 허무는 협업의 가치를 여러 사례로 보여준다. 결국 더 나은 결과를 위해서는 정해진 틀과 측정 방식에 의문을 제기하고, 인간의 고유한 판단력과 상상력을 적극 활용해야 한다. ## AI 시대의 ‘오르막 사고’ - 존 마에다는 인간을 대체하기 어려운 이유가 비효율적으로 보이는 비선형적 사고에 있다고 설명한다. - AI는 지름길과 최적화에 강하지만, 인간은 우회하고 실수하며 예상 밖의 연결을 만들어낸다. - 이러한 “오르막 사고(uphill thinking)”는 더 큰 위험을 수반하지만, 동시에 진정한 창의적 도약과 혁신을 낳을 수 있다. - 디자이너가 AI와 협업하기 위해 기계의 언어를 배워야 하는 시대일수록, 인간만의 독창적인 사고가 더욱 중요해진다. ## 경계를 넘어선 새로운 진로 - 캘리포니아의 비영리단체 CROP는 출소자의 사회 복귀를 지원하며 UX 디자인 교육을 제공한다. - 27년간 복역한 론 스콧은 CROP의 교육을 통해 UX 디자이너라는 새로운 진로에 도전했다. - 제품의 외관과 작동 방식이 누군가의 결정으로 만들어진다는 점을 깨닫고, 자신도 그 결정 과정에 참여하고 싶다고 말한다. - UX 디자인은 기존 경력이나 사회적 배경과 관계없이 새로운 기회를 만들 수 있는 대안적 직업 경로로 제시된다. - 디자인 교육은 단순한 기술 습득을 넘어, 제품과 사회에 목소리를 낼 수 있는 권한을 제공한다. ## 직무의 틀을 깨는 리더십 - 에어비앤비의 브라이언 체스키는 회사를 위기에서 구하는 과정에서 디자인 중심의 리더십을 강조했다. - 그가 제품 관리 기능을 없애고 디자인을 중심에 둔 사례는 디자이너와 PM의 역할 관계에 대한 논쟁을 일으켰다. - 글은 이를 디자이너와 PM 중 누가 우위에 서야 하는지의 문제라기보다, 기존 직무 구분을 재검토하는 계기로 바라본다. - 넷플릭스 디자인 부사장 스티브 존슨은 모든 구성원이 같은 목표를 추구한다는 전제 아래, 낡은 직무 명칭과 경계를 새롭게 정의할 필요가 있다고 말한다. - 조직은 역할의 이름보다 문제 해결과 공동 목표 달성에 초점을 맞출 때 더 유연하게 움직일 수 있다. ## 생산성을 숫자로만 판단할 때의 한계 - 엔지니어의 업무를 측정 가능한 결과만으로 평가하는 방식은 창의적이고 복잡한 개발 업무를 지나치게 단순화할 수 있다. - 생산성 지표가 코드량, 작업량, 가시적인 산출물에 집중하면 문제 해결 과정, 장기적 설계, 동료 지원처럼 쉽게 측정되지 않는 기여를 놓치게 된다. - 동료가 “일을 하지 않는 것처럼” 보이는 이유가 실제 태만이 아니라, 조직의 성공 기준이 지나치게 좁기 때문일 수도 있다. - 성과를 평가할 때는 단기 결과뿐 아니라 문제의 난이도, 영향 범위, 협업, 기술적 판단과 같은 맥락도 함께 고려해야 한다. ## 프레임 밖에서 바라보기 - 글은 생산성 논쟁 외에도 이야기의 구도와 관점에 관한 사례를 소개한다. - 영화감독 왕가위의 작품을 통해, 같은 현실도 무엇을 화면 안에 담고 무엇을 제외하느냐에 따라 전혀 다르게 전달될 수 있음을 보여준다. - 이는 제품 디자인과 업무에도 적용된다. 무엇을 문제로 정의하고 어떤 정보를 강조하는지가 결과와 해석을 좌우한다. - 익숙한 프레임을 그대로 받아들이기보다, 문제의 범위와 관점을 다시 설정하는 것이 새로운 해법의 출발점이 된다. ## 대화형 AI와 아이디어의 공간 - Figma 디자이너 아오셩 란은 ChatGPT와의 상호작용이 채팅 박스 안에 갇혀 있다고 지적한다. - 텍스트 입력과 응답만으로는 아이디어를 자유롭게 펼치고 시각적으로 조합하는 데 한계가 있다. - AI를 더 효과적으로 활용하려면 단순한 대화형 인터페이스를 넘어, 생각을 넓히고 연결하며 함께 탐색할 수 있는 작업 공간이 필요하다. 정해진 직무와 생산성 지표를 그대로 따르기보다, AI가 잘하지 못하는 비선형적 사고와 관점 전환을 의도적으로 연습하는 것이 좋다. 또한 조직에서는 직함보다 공동 목표와 실제 기여를 중심으로 협업 구조와 평가 기준을 재설계할 필요가 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

변화하는 일의 방식, 우리가

팬데믹 이후 분산 근무와 디지털 협업은 일시적 현상이 아니라 업무의 기본 방식으로 자리 잡았다. 그러나 제품 개발에는 더 많은 사람이 참여하고, 팀은 물리적으로 분산되었으며, 동시에 진행되는 업무도 늘어나면서 정렬 부족·의사결정 지연·개발 주기 장기화가 심해졌다. 글은 이런 혼란을 줄이고 성과를 내는 팀의 차별점으로 투명성, 공유된 이해, 의도적인 연결을 제시한다. ## 분산 근무의 정착 - 유럽과 아시아 디자이너 대상 Figma 조사에서 **75%가 팬데믹 이전보다 재택근무를 더 자주 한다**고 답했다. - 미국의 재택근무 일수는 2019년보다 **약 5배 증가**했다. - 사무실 점유율과 대중교통 이용률 등은 팬데믹 이전으로 완전히 돌아가지 않았으며, 분산 근무는 장기적으로 지속될 가능성이 크다. - 협업은 회의실 중심에서 파일·문서·프레젠테이션에 커서와 아바타가 함께 나타나는 **‘멀티플레이어 업무’** 방식으로 확장되었다. ## 제품 개발을 어렵게 만드는 세 가지 변화 ### 더 많은 사람의 참여 - 과거에는 주로 디자이너와 엔지니어가 제품 개발을 이끌었다. - 현재는 데이터, 보안, 콘텐츠, 마케팅, 제품관리, 경영진 등 다양한 직무가 같은 프로젝트와 파일에 참여한다. - 참여자가 늘면서 전문성을 결합할 수 있다는 장점이 생겼지만, 이해관계 조정과 의사결정은 더 복잡해졌다. - 디지털 제품이 사업에서 차지하는 중요성이 커질수록 관련 역할과 검토 절차도 증가한다. ### 더 분산된 업무 - 지리적 장벽이 낮아져 세계 각지의 인재가 협업할 수 있게 되었다. - 반면 물리적 거리는 팀 사이의 정서적 거리로 이어질 수 있으며, 신뢰 형성이 어려워진다. - 과거의 “돌아다니며 관리하기”처럼 자연스럽게 상황을 파악하고 관계를 쌓는 방식이 Zoom, Teams, Slack만으로는 쉽게 대체되지 않는다. - 실시간 공동 편집과 단일 정보 출처는 효율적이지만, 알림·댓글·변경사항이 지나치게 많아지면 협업이 ‘협력적 혼란’으로 변할 수 있다. ### 더 많은 진행 중인 업무 - 웹사이트, 앱, 디지털 제품을 더 자주 업데이트해야 한다는 기대가 커졌다. - 여러 프로젝트와 버전이 동시에 진행되면서 팀의 주의력과 조정 비용이 증가한다. - 빠른 출시를 잘 활용하는 팀도 있지만, 일부 팀은 업무량과 복잡성 때문에 심각한 좌절을 겪는다. ## 제품 개발 과정의 주요 장애물 - Forrester Consulting 조사에서 **응답자 10명 중 9명**이 제품 개발 과정에서 어떤 형태로든 장애를 경험했다. - 특히 다음 세 가지 문제가 두드러졌다. - 팀 간 정렬 부족 - 의사결정의 어려움 - 긴 개발 주기 - 응답자 10명 중 6명은 이 세 가지 문제 중 하나 이상을 경험했다. - 이러한 문제는 새롭게 생긴 것이라기보다, 참여자 증가·분산 근무·동시 진행 업무 증가로 기존 문제가 증폭된 결과다. ## 성과가 높은 팀을 만드는 조건 - 혼란스러운 협업과 높은 성과를 가르는 요소는 다음 세 가지다. - **높은 수준의 투명성** - **팀 전체의 공유된 이해** - **의도적으로 설계된 연결과 관계 형성** - 모든 사람이 같은 파일에 접근하는 것만으로는 충분하지 않다. - 구성원들이 프로젝트의 맥락, 결정 이유, 현재 상태를 이해하고 서로 신뢰할 수 있어야 협업 도구의 효과가 나타난다. - 글은 이후 섹션에서 성공적인 제품·디자인 팀이 투명성을 어떻게 실천하는지 구체적으로 설명하려 한다. ## 실용적인 결론 분산된 환경에서는 협업 도구를 도입하는 것보다 **정보를 투명하게 공유하고, 결정의 맥락을 기록하며, 팀 간 공통 이해와 신뢰를 의도적으로 만드는 운영 방식**이 더 중요하다. 참여자가 많고 업무가 동시에 진행될수록 알림과 산출물을 늘리기보다, 누구나 현재 상태와 다음 결정을 명확히 파악할 수 있는 구조를 마련해야 한다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

UX 디자인 커리어를 위해 출소

CROP는 출소자의 재사회화와 재범률 감소를 위해 UX 디자인 교육과 생활 지원을 결합한 비영리 프로그램이다. 1년 과정인 Ready 4 Life는 개인 성장, 직업 교육, 취업 지원, 안정적인 주거를 함께 제공하며, 참가자들이 기술 역량과 자신감을 갖고 새로운 삶을 설계하도록 돕는다. 이 프로그램은 출소자에게 필요한 것은 기회와 도구, 지속적인 지원이라는 점을 보여준다. ## 출소자의 재진입을 돕는 CROP의 탄생 - CROP의 공동 창립자들은 총 100년 이상의 수감 경험을 바탕으로 기존 재진입 지원 체계의 문제를 직접 경험했다. - 기존 서비스는 취업, 주거, 상담이 서로 분리되어 있어 참가자가 여러 기관을 오가야 하는 구조였다. - CROP는 이러한 단절을 해결하기 위해 개인의 삶을 전반적으로 지원하는 “통합적이고 포괄적인 지원” 모델을 구상했다. - 프로그램의 목표는 출소자가 사회와 노동시장에 안정적으로 복귀하고, 재범의 악순환에서 벗어나도록 돕는 것이다. ## Ready 4 Life의 네 가지 축 - **개인 성장** - 자기 이해, 회복, 목표 설정 등 새로운 삶을 준비하는 과정을 지원한다. - **직업 교육** - Figma를 활용한 UX 디자인을 포함해 실제 취업으로 이어질 수 있는 기술을 가르친다. - **취업 지원** - 직무 역량 개발뿐 아니라 취업 기회와 노동시장 진입을 돕는다. - **안정적인 주거** - 참가자들이 교육과 회복에 집중할 수 있도록 웨스트 오클랜드의 주거·교육 캠퍼스에서 아파트를 제공한다. - 12명의 펠로는 개인 코치와 월별 생활비 지원도 받는다. ## UX 디자인을 통한 새로운 진로 - CROP는 출소자들이 이미 갖고 있는 문제 해결 능력, 스토리텔링, 사람들과 연결하는 능력을 기술 교육과 결합하려 한다. - UX 디자인은 사용자의 경험과 문제를 이해하고 해결책을 설계하는 분야이므로, 참가자들의 삶의 경험과 관찰력이 강점으로 활용될 수 있다. - UX 트랙 강사 Alexis Bustos는 참가자들에게 부족한 것은 잠재력보다 기술적 교육과 도구에 대한 접근성이라고 설명한다. - Figma 워크숍을 통해 참가자들은 디자인 프로세스와 협업 도구를 익히며 테크 업계 진입을 준비한다. ## 사회적 낙인과 재사회화의 장벽 - 출소자는 형기를 마친 뒤에도 취업과 주거, 사회적 관계 형성에서 차별과 불신을 경험할 수 있다. - CROP는 단순히 직업 기술만 제공하지 않고 코칭, 주거, 생활비를 함께 지원해 재진입 과정에서 발생하는 현실적인 장벽을 줄인다. - 프로그램은 참가자를 과거의 범죄 기록으로만 판단하지 않고, 변화하고 성장할 수 있는 사람으로 대한다. - 참가자들이 자신의 경험을 새로운 관점에서 해석하고 미래를 직접 설계하도록 돕는 것이 중요한 요소다. ## 재활 투자와 비용 효율성 - 캘리포니아에서는 수감자 1인당 연간 약 10만 6천 달러가 소요되며, 그중 재활에 배정되는 비율은 약 3.4%에 그친다. - CROP는 참가자 1인당 프로그램 비용이 수감 비용의 대략 절반 수준이라고 설명한다. - 캘리포니아의 재범률이 약 50%에 이르는 상황에서, 주거·교육·취업을 결합한 장기 지원은 재범을 줄이기 위한 대안이 될 수 있다. - CROP는 캘리포니아 주정부와 3년간 2,850만 달러 규모의 파트너십을 맺고 프로그램을 확장하고 있다. ## 프로그램이 제시하는 가능성 - CROP의 사례는 사회적 약자를 위한 교육이 단순한 기술 훈련을 넘어 생활 기반과 심리적 안정까지 포함해야 효과적이라는 점을 보여준다. - 참가자들의 과거 경험은 약점만이 아니라 사용자 공감과 문제 해결에 활용할 수 있는 자산이 될 수 있다. - 취업 가능성을 높이려면 교육 과정, 실무 도구, 멘토링, 주거와 경제적 지원이 함께 제공되어야 한다. - 기술 업계 역시 다양한 삶의 경험을 가진 인재를 받아들일 때 더 폭넓은 사용자 관점을 얻을 수 있다. 출소자의 재사회화를 지원하는 프로그램을 설계할 때는 단기 교육보다 장기적이고 통합적인 접근이 효과적이다. 특히 실무 기술 교육을 안정적인 주거, 코칭, 취업 지원과 결합하면 개인의 역량뿐 아니라 실제 사회 복귀 가능성도 높일 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

스포티파이의 디자인

Spotify는 45개 플랫폼과 2,000종 이상의 기기에서 일관된 브랜드 경험을 제공하기 위해 디자인 시스템 Encore를 플랫폼별 체계에서 크로스플랫폼 체계로 확장했다. 초기에는 모바일과 웹 시스템이 분리되어 유연성을 얻었지만, 시간이 지나며 컴포넌트의 불일치와 중복이 커졌다. 이에 공통 기반과 재사용 가능한 중간 계층을 마련하고, 컴포넌트를 처음부터 여러 플랫폼이 함께 설계하는 방식으로 전환했다. ## 일관된 경험이 필요해진 배경 - Spotify는 TV, 자동차, 모바일, 컴퓨터 등 다양한 환경에서 오디오 콘텐츠를 제공하게 됐다. - 2019년 기준 45개 플랫폼, 2000종 이상의 기기, 200개 브랜드에 걸쳐 서비스를 제공해야 했다. - 목표는 모든 플랫폼을 단순히 지원하는 것이 아니라, 어떤 기기에서도 사용자가 “Spotify답다”고 느끼는 일관된 경험을 만드는 것이었다. - 디자인 시스템의 컴포넌트가 플랫폼 간 경험을 통합하는 핵심 수단으로 강조됐다. ## Encore의 초기 구조와 한계 - Encore는 2019년 두 개의 하위 시스템으로 출발했다. - **Encore Consumer Mobile**: 모바일 중심 경험을 위한 유연한 UI 컴포넌트 카탈로그 - **Encore Web**: 다양한 웹 제품을 위한 시스템 - 색상과 타이포그래피 같은 기본 디자인 결정에는 디자인 토큰을 사용했다. - 그러나 각 하위 시스템이 독립적으로 발전하면서 버튼의 크기, 타이포그래피, 상태 표현 등에서 차이가 생겼다. - 제품팀의 요구가 커지면서 컴포넌트가 지나치게 유연해졌고, 플랫폼 간 공통성이 약해졌다. ## 공통 기반과 재사용 계층의 도입 - 2022년 Spotify는 유연성에 치우친 구조를 재조정할 필요가 있다고 판단했다. - Encore Mobile을 위한 재사용 가능한 컴포넌트 제작 전담 팀을 구성했다. - 이 새로운 계층은 공통 기반과 Consumer Mobile 사이에 위치했다. - 이를 통해: - Consumer Mobile이 모든 컴포넌트를 직접 제공해야 하는 부담을 줄이고 - Web과 Mobile 사이의 플랫폼 대응성을 높이며 - 제품별로 중복 구현되는 컴포넌트를 줄일 수 있었다. - Web 팀과 협력해 크로스플랫폼 컴포넌트를 나중에 맞추는 대신, 처음부터 함께 개발하기 시작했다. ## 크로스플랫폼 컴포넌트 설계 방식 - 기존처럼 사용자 조사, 디자인, 개발로 이어지는 과정 자체는 유지했다. - 가장 큰 변화는 디자인 단계에서 특정 플랫폼 하나만을 대상으로 하지 않는 것이었다. - iOS, Android, Web 팀이 함께 각 플랫폼의 요구사항과 특성을 조사하고, 공통 경험을 조율했다. - 플랫폼별 고유성을 없애는 것이 아니라, 공통된 구조와 시각적 언어를 유지하면서 각 환경에 맞게 적용하는 것이 목표였다. - 웹, 모바일, TV는 입력 방식과 화면 크기 등 사용 맥락이 다르므로, 동일한 컴포넌트를 그대로 복제하기보다 플랫폼의 장점을 보존해야 했다. - 이를 위해 각 플랫폼 전문가가 협업하는 구조가 중요했다. 웹과 모바일 양쪽 모두에 정통한 디자이너는 드물기 때문에, 여러 분야의 전문성을 한 과정 안에서 결합해야 했다. Spotify의 사례는 디자인 시스템을 플랫폼별 컴포넌트 모음으로 관리하기보다, 공통 기반·재사용 계층·플랫폼별 특화를 연결하는 구조로 설계해야 한다는 점을 보여준다. 실무에서는 플랫폼 팀을 초기 설계 단계부터 참여시키고, 공통 토큰과 컴포넌트의 범위를 명확히 정하는 방식이 효과적이다.

원문 읽기(새 탭에서 열림)
figma4분 읽기큐레이션 요약

Figma를 빠르게 유지하기

Figma는 2018년 한 대의 MacBook으로 운영하던 성능 테스트 체계가 제품과 조직의 성장으로 한계에 이르자 전면적인 개편을 추진했습니다. 플러그인, FigJam, Dev Mode 등 기능이 늘고 코드베이스가 복잡해지면서 기존의 소수 대형 파일 테스트만으로는 성능 회귀를 조기에 발견하기 어려워졌습니다. 이에 Figma는 모든 코드 변경을 대상으로 실제 하드웨어에서 병렬 성능 테스트를 실행하고, 10분 이내에 결과를 제공하는 확장 가능한 시스템을 목표로 삼았습니다. ## 한 대의 MacBook으로 시작한 성능 테스트 - 2018년 Figma는 한 대의 MacBook에서 동일한 테스트 시나리오를 반복 실행했습니다. - 테스트 결과와 실행 시간은 약 한 시간 간격으로 공유 대시보드에 기록됐습니다. - 당시에는 소수의 대형 디자인 파일만으로도 주요 성능 문제를 확인할 수 있었습니다. - 문서 렌더러 구조를 개선하고 WebAssembly 관련 버그를 해결하면서 Figma의 성능을 약 3배 향상시킨 사례도 있었습니다. - 작은 조직에서 단일 컴퓨터로 테스트하는 방식은 단순하고 비용이 낮다는 장점이 있었습니다. ## 제품과 조직의 성장으로 드러난 한계 - 5년 동안 코드베이스가 커지고 다음과 같은 기능이 추가됐습니다. - 플러그인 - Community 기능 - FigJam - Dev Mode - 수많은 제품 업데이트 - 기존에 사용하던 몇 개의 대형 디자인 파일은 늘어나는 기능과 예외 상황을 충분히 대표하지 못했습니다. - 기능별로 세밀한 성능 테스트를 작성하는 것이 이상적이었지만, 엔지니어와 매니저가 400명 이상으로 늘면서 모든 변경 사항을 한 사람이 추적하기 어려워졌습니다. - 성능 테스트 대상과 코드 변경이 많아지면서 단일 노트북만으로는 출시 전 성능 회귀를 안정적으로 발견할 수 없었습니다. - 원격 근무가 시작된 뒤에도 사무실에 있던 MacBook은 계속 테스트를 실행했고, 결국 2020년 10월 과열됐습니다. - 다른 노트북으로 같은 환경을 재현하려 했지만 테스트가 원활하게 실행되지 않아 새로운 시스템이 필요해졌습니다. ## 세밀한 성능 테스트의 필요성 - **세밀한 성능 테스트(granular performance test)**는 특정 기능이나 사용 패턴을 대규모 조건에서 검증하는 테스트입니다. - 예를 들어 Figma는 다음과 같은 상황을 시뮬레이션할 수 있습니다. - 100명의 협업 편집자가 동시에 파일을 편집 - 여러 사용자가 레이어를 이동 - 동시에 새로운 텍스트 입력 - 사용자가 빠르게 화면을 패닝 - 이런 테스트는 특정 기능의 성능 영향을 정확하게 파악하는 데 유용합니다. - 하지만 기능 수와 엣지 케이스가 계속 증가하면 모든 기능을 수동으로 테스트하는 방식은 조직 규모에 맞게 확장되지 않습니다. ## 새 성능 테스트 시스템의 목표 - Figma는 시스템을 처음부터 다시 설계하며 세 가지 문제를 해결하려 했습니다. - 성능에 영향을 줄 수 있는 기능의 증가 - 테스트 하드웨어 운영의 어려움 - 신뢰할 수 있는 성능 지표의 부족 - 메인 모노레포에 제출되는 **모든 코드 변경**을 테스트해 성능 회귀를 개발 초기에 발견하는 것을 목표로 삼았습니다. - 사용자가 버그를 보고한 뒤 대응하는 대신, 기능이 배포되기 전에 성능 문제를 예방하려 했습니다. - Figma 사용자는 하루에도 여러 시간 제품을 사용하기 때문에 작은 지연도 작업 흐름에 큰 영향을 줄 수 있다고 판단했습니다. - 성능을 기능 개발 이후의 사후 대응이 아니라 개발 과정에 포함되는 품질 기준으로 다루려 했습니다. ## 병렬 실행과 10분 성능 가드레일 - 테스트 대기 시간을 줄이기 위해 여러 테스트를 동시에 실행하는 **병렬 실행(parallel runs)**을 핵심 전략으로 채택했습니다. - 기존 CI에서도 클라우드 러너를 이용한 병렬 테스트를 이미 활용하고 있었습니다. - 성능 테스트 역시 수십 개의 스트레스 시나리오를 동시에 실행해야 목표 시간을 달성할 수 있었습니다. - 성능 가드레일 검사는 개발 흐름을 방해하지 않도록 **10분 이내**에 완료되어야 한다는 기준을 세웠습니다. - 모든 풀 리퀘스트를 실제 하드웨어에서 테스트하려면 피크 시점에 동일한 성능의 테스트 러너 약 100대가 필요했습니다. - 따라서 새로운 체계는 단순히 테스트 수를 늘리는 것이 아니라, 하드웨어를 효율적으로 운영하고 결과를 빠르게 수집하는 구조여야 했습니다. ## 실용적인 결론 성능 테스트는 제품과 조직이 작을 때는 단일 장비와 소수의 대표 시나리오만으로도 충분할 수 있지만, 기능·코드·팀 규모가 커지면 자동화와 병렬화가 필수입니다. 특히 사용자 경험에 직접 영향을 주는 성능은 출시 후 모니터링하는 것보다 모든 코드 변경 단계에서 회귀를 차단하는 가드레일로 운영하는 편이 효과적입니다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Jambot으로 아이디어

Jambot은 ChatGPT의 생성 능력을 FigJam의 멀티플레이어 캔버스에 결합한 위젯이다. Figma 팀은 선형적인 채팅 인터페이스만으로는 아이디어를 분기하고 연결하거나 여러 사람이 함께 발전시키기 어렵다고 보고, 시각적이고 공간적인 AI 상호작용 방식을 만들었다. 이를 통해 FigJam에서 아이디어를 발산하고, 요약하며, 대화를 확장할 수 있도록 했다. ## 선형 채팅 인터페이스의 한계 - ChatGPT는 아이디어를 주고받으며 즉흥적으로 발전시키는 데 강점이 있다. - 그러나 대화가 한 줄로 이어지는 구조라 여러 선택지를 동시에 비교하거나 주제를 분기하기 어렵다. - 이전에 제시된 다른 선택지로 돌아가려면 대화 기록을 위로 스크롤하고 질문을 반복해야 한다. - 서로 다른 아이디어 간의 관계를 시각적으로 파악하거나, 여러 방향을 병렬로 실험하기에도 적합하지 않다. ## 네트워크형 사고와 시각적 AI - Jambot의 초기 아이디어는 Figma의 AI 해커톤에서 “시각적 버전의 ChatGPT”라는 형태로 제안됐다. - Roam Research와 Logseq 같은 네트워크형 사고 도구에서 영감을 얻었다. - 페이지를 서로 연결할 수 있다. - 아이디어를 조직하고 추적할 수 있다. - 하나의 주제에서 관련 주제로 자연스럽게 이동할 수 있다. - Albus처럼 AI와의 상호작용을 시각적으로 구성하는 도구도 디자인 방향에 영향을 주었다. - 핵심은 채팅 기록을 순서대로 읽는 대신, 아이디어를 캔버스 위에 배치하고 연결하며 확장하는 것이다. ## FigJam과 ChatGPT의 결합 - Jambot은 FigJam 파일 안에서 ChatGPT의 생성 기능을 사용할 수 있게 한다. - 사용자는 다음과 같은 작업을 수행할 수 있다. - 새로운 아이디어 발상 - 아이디어나 회의 내용 요약 - 기존 생각을 다른 방향으로 확장 - AI와 함께 가볍게 브레인스토밍하고 실험 - FigJam의 협업 캔버스 위에서 작동하므로, AI와의 상호작용 결과를 팀원들과 함께 보고 수정할 수 있다. - 개인용 챗봇을 넘어 여러 사람이 함께 사용하는 “멀티플레이어 ChatGPT”를 지향한다. ## 코딩 도구가 아닌 시각적 구성 도구 - Sam Dixon은 LangChain처럼 의미론적·객체지향적인 방식으로 AI를 다루는 도구에서 영감을 받았다. - LangChain은 강력하지만 활용하려면 프로그래밍 지식이 필요하다. - Jambot은 이러한 개념을 코드 대신 시각적이고 직관적인 방식으로 제공하려는 시도다. - 사용자가 AI 시스템의 내부 구조를 직접 프로그래밍하지 않아도, 캔버스에서 결과를 보고 조작하며 아이디어를 발전시킬 수 있도록 한다. ## AI 인터페이스를 다시 설계하기 - Aosheng Ran은 현재의 AI 서비스가 지나치게 채팅창에 의존한다고 지적한다. - ChatGPT는 감정이나 정체성을 가진 것처럼 대화하지만, 실제로는 맥락과 역할을 충분히 드러내지 못하는 경우가 있다. - 과거의 GUI는 커서, 창, 화면 같은 요소를 통해 컴퓨터를 더 쉽게 사용할 수 있게 만들었다. - 반면 현재의 LLM 인터페이스는 초기 운영체제나 명령줄 환경처럼, 대부분 텍스트 입력과 출력에 머물러 있다. - Jambot은 AI와 상호작용하는 새로운 GUI 요소를 탐색하며, AI를 더 공간적이고 협업적인 환경으로 옮기려는 사례다. ## 실용적인 의미 Jambot의 핵심 가치는 AI가 답을 제공하는 데서 끝나지 않고, 팀이 아이디어를 함께 배치하고 비교하며 발전시키도록 돕는 데 있다. 복잡한 브레인스토밍이나 회의에서는 선형 채팅보다 캔버스 기반 AI가 더 적합할 수 있으므로, 여러 방향의 아이디어를 동시에 탐색해야 하는 작업에 유용한 접근이다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Dev Mode 후속 업데이트:

Figma는 Dev Mode 오픈 베타 2개월 동안 사용자 피드백 5,000건 이상을 반영해 200개가 넘는 기능과 수정 사항을 배포했다. 이번 업데이트의 핵심은 디자인 파일을 개발자가 더 쉽게 탐색·검수하고, 코드 생성 결과를 실제 개발 환경에 가깝게 만드는 것이다. 상태 라벨, 버전 비교, 향상된 코드 스니펫, VS Code 연동 등으로 디자이너와 개발자 간 협업 효율을 높였다. ## Dev Mode에 새로 추가된 기능 - 컴포넌트, 인스턴스, 프레임, 섹션에 개발 준비 상태를 나타내는 **상태 라벨**을 추가할 수 있다. - Design Mode에서 제공되던 **레이아웃 그리드, 룰러, 아웃라인 모드**를 View 메뉴와 기존 단축키로 사용할 수 있다. - 분리(detached)된 컴포넌트를 원본 메인 컴포넌트와 비교해 변경 사항을 확인할 수 있다. - 코드 옵션으로 **Android XML과 iOS UIKit**이 다시 제공된다. - 색상 형식에서 `UIColor`를 선택할 수 있다. - 파일 이름을 클릭하면 **버전 기록의 여러 디자인 버전**을 열어 검사할 수 있다. ## 사용성 및 성능 개선 - 외부 라이브러리에서 가져온 디자인 시스템 컴포넌트의 라이브러리 이름을 표시한다. - 컴포넌트 플레이그라운드에서 중첩된 컴포넌트 속성과 컴포넌트 모드를 확인하고 실험할 수 있다. - 텍스트 속성에는 `rem` 단위를 사용하면서, 다른 속성은 픽셀 단위로 유지할 수 있다. - 캔버스에서 여러 객체를 `Shift` 클릭으로 선택하고 한 번에 내보낼 수 있다. - Figma 파일과 알림을 **VS Code 내부에서 확인**할 수 있다. - 타이포그래피 미리보기에서 스타일 이름, 글자 크기, 줄 높이 같은 속성을 확인하고 복사할 수 있다. - 텍스트의 특정 부분만 선택해 개별 속성을 검사할 수 있다. - 왼쪽 레이어 패널의 높이를 드래그로 조절할 수 있다. - 원시 값과 일치 가능성이 높은 디자인 시스템 변수를 자동으로 제안한다. - 코드 스니펫뿐 아니라 Figma 속성 형식으로도 값을 확인할 수 있다. - 디자인에 포함된 이미지 등의 소스 파일을 다운로드할 수 있다. - 대체 단위 설정을 일반 환경설정 메뉴에서 쉽게 찾을 수 있다. - 섹션을 선택하면 프레임별 링크를 모아서 확인할 수 있다. ## 코드 생성 개선 - `Shift` 키를 누른 채 모든 코드 스니펫을 한 번에 복사할 수 있다. - 하나의 패딩 값만 설정된 경우에도 CSS에서 `padding-top`, `padding-bottom`, `padding-left`, `padding-right`를 생성한다. - 코드에 `font-style`, `line-height`, `font-weight`를 항상 표시한다. - `line-height`를 백분율과 픽셀 값으로 함께 제공한다. - CSS 코드 생성에서 다음 OpenType 기능을 지원한다. - `font-feature-settings` - `font-variant-numeric` - `font-kerning` - 오토 레이아웃의 `min-width`, `max-width`, `min-height`, `max-height`와 줄바꿈 레이아웃의 세로 간격에 변수를 사용할 수 있다. - 여러 문단이나 서로 다른 텍스트 스타일이 섞인 텍스트 레이어는 스타일별 CSS 코드를 개별적으로 표시한다. - 커뮤니티에는 Tailwind, React, Vue 등을 위한 약 80개의 코드 생성 플러그인이 제공된다. ## 버그 수정 및 탐색 개선 - 탭 키 내비게이션으로 Design Mode와 Dev Mode 사이를 전환할 수 있다. - 힌트와 툴팁 전반에서 대체 단위를 올바르게 표시한다. - 텍스트 그라디언트 표시를 개선하는 등 시각적 품질 문제를 수정했다. 이번 업데이트는 Dev Mode를 단순한 디자인 검사 도구가 아니라, 디자인 시스템 확인·코드 생성·파일 관리·개발 환경 연동을 아우르는 협업 작업 공간으로 발전시키는 데 초점을 맞췄다. 팀에서는 상태 라벨과 버전 기록을 개발 핸드오프 과정에 적극 활용하고, 생성된 CSS나 플랫폼 코드는 실제 프로젝트 규칙과 비교해 검토하는 것이 좋다.

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