product-development

27 개의 포스트

figma3분 읽기큐레이션 요약

리니어 방식: 주

Linear는 모든 사용자가 각자 업무 방식을 설계하도록 방치하기보다, 특정 목적에 최적화된 “의견이 분명한 소프트웨어”를 제공해야 한다고 주장한다. 명확한 기본값과 단순한 개념으로 사용자의 학습 부담을 줄이고, 프로세스 논쟁보다 실제 제품 개발에 집중하게 만드는 것이 목표다. 다만 모든 결정을 고정하는 것은 아니며, 작은 단위에는 강한 원칙을 적용하고 큰 구조에는 고객 피드백을 반영하면서 의견을 계속 발전시킨다. ## 의견이 분명한 소프트웨어란 무엇인가 - 특정 사용 사례를 위해 설계된 소프트웨어로, 여러 분야에 두루 적용되는 범용 도구와 구별된다. - Linear의 목적은 팀이 더 나은 제품을 만들도록 돕는 협업형 이슈 추적·프로젝트 관리다. - 사용자가 각자 워크플로를 만들도록 유연성만 제공하면 조직이 성장할수록 방식이 제각각이 되어 혼란이 생길 수 있다. - 따라서 “무엇이든 가능한 도구”보다 “가장 좋은 기본 방식”을 제시하는 것을 중시한다. ## 원자적 단위에서 강한 기본값 만들기 - 프로젝트, 팀처럼 누구나 이해할 수 있는 일반적인 용어를 사용해 학습 곡선과 전문 용어 부담을 낮춘다. - 사용자가 매뉴얼을 읽지 않아도 바로 시작할 수 있도록 설계한다. - 반드시 하나의 정답만 강제하는 것이 아니라, 사용자가 자연스럽게 따를 수 있는 기본값을 제공한다. - 라벨과 마감일을 이슈의 속성으로 두는 것처럼, 세부적인 기능·구조에서는 강한 제품 의견을 적용한다. - 반면 프로젝트와 같은 상위 개념은 회사마다 조직 구조가 다르므로 고객 피드백을 더 적극적으로 반영한다. - 핵심 목표는 프로세스의 세부 사항을 끝없이 조정하는 시간을 줄이고, 실제 구축 작업에 빨리 진입하게 하는 것이다. ## 제품 부채를 전략적으로 감수하기 - 제품 부채는 단순히 잘못 작성된 코드인 기술 부채와 다르다. - 기능 범위나 완성도를 의도적으로 줄여 단기 목표를 달성하고, 나중에 사용자 피드백이나 추가 리소스라는 비용을 치르는 선택으로 본다. - 모든 기능을 처음부터 완벽하게 만들기보다, 사용자 경험에 미치는 영향과 “이자율”을 따져 부채를 선택적으로 감수한다. - Linear의 설정 화면은 기능, 환경설정, 섹션을 계속 추가해 왔지만 전체 경험을 재설계하지는 않은 사례다. - 설정 화면은 핵심 업무 흐름을 좌우하는 영역이 아니므로, 당장 전면 개편하지 않아도 비용이 비교적 낮다고 판단했다. - 여기서 말하는 지름길은 품질을 무조건 낮추는 것이 아니라, 초기 구현의 범위를 줄이는 방식에 가깝다. ## 강한 원칙도 계속 발전시키기 - 스타트업의 제품 개발은 고정된 레시피를 따르는 일이 아니라 실험과 반복의 과정이다. - 사용자의 반발이 두려워 기존 경험을 영원히 유지하면 제품이 변화할 수 없게 된다. - 사용자의 업무 흐름에 큰 영향을 주는 변경은 신중해야 하지만, 모든 기능을 절대 바꿀 수 없도록 만드는 것은 바람직하지 않다. - 강한 의견은 처음부터 완벽한 규칙으로 고정하는 것이 아니라, 실제 사용과 피드백을 통해 수정할 수 있어야 한다. - 즉, 원칙은 강하게 유지하되 구현과 사용자 경험은 필요에 따라 실험하고 바꿀 수 있어야 한다. 팀이 제품을 설계할 때는 모든 것을 자유롭게 설정하게 하기보다, 핵심 사용 사례에 맞는 명확한 기본값을 먼저 제공하는 것이 효과적이다. 다만 세부 기능에는 일관된 의견을 적용하되 조직 구조나 업무 방식처럼 회사마다 다른 영역은 고객 피드백에 열어 두고, 감수한 제품 부채는 장기적으로 상환할 계획을 함께 세우는 것이 좋다.

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

Figma와 Jira로 디

제품 개발의 속도와 품질을 높이려면 디자이너와 개발자가 같은 맥락을 공유하며 협업할 수 있는 도구·프로세스·의식이 필요하다. 특히 하이파이 인터랙티브 프로토타입과 Figma-Jira 연동은 디자인 의도를 코드로 옮기는 과정의 오해와 단절을 줄이고, 대면·비동기 협업 모두에서 팀의 ‘플로우’를 유지하도록 돕는다. 규모가 커지고 하이브리드 근무가 일반화될수록 지속적인 정렬과 명확한 정보 공유가 중요해진다. ## 제품 개발에서 ‘플로우’가 중요한 이유 - 플로우는 구성원이 특정 활동에 깊이 몰입해 효율적으로 작업하는 상태다. - 제품 속도는 올바른 기능을 빠르게 출시하는 능력이지만, 조직이 커질수록 유지하기 어렵다. - 속도는 저절로 생기지 않으며, 다음과 같은 기반이 필요하다. - 협업 도구 - 작업 프로세스 - 팀의 정기적인 커뮤니케이션과 의식 - 폴 그레이엄의 ‘메이커의 일정과 매니저의 일정’처럼 디자이너와 개발자는 짧은 단위의 잦은 회의보다 방해받지 않는 긴 작업 시간이 필요하다. - 하이브리드 환경에서는 알림, 일정, 변화하는 요구사항 때문에 개인과 팀 모두 플로우를 잃기 쉬우므로 협업 기반을 먼저 정비해야 한다. ## 고해상도 프로토타입으로 디자인과 개발의 언어 통일 - 회사가 커질수록 팀과 업무가 사일로로 분리되고, 원격·하이브리드 근무로 구성원 간 맥락 공유가 어려워진다. - 같은 용어도 디자이너와 개발자가 서로 다르게 이해할 수 있지만, 실제로 작동하는 프로토타입을 보면 의도를 더 정확히 공유할 수 있다. - One.com은 덴마크의 디자인 팀과 인도의 개발 팀이 정기적으로 요구사항, 장애물, 잠재적 문제를 논의한다. - 새로운 텍스트 기능을 논의할 때 Figma의 하이파이 프로토타입을 사용해 개발자들이 인터랙션 상태를 직접 확인했다. - 정적·로우파이 프로토타입이 전체적인 디자인 방향을 보여준다면, 인터랙티브 하이파이 프로토타입은 다음과 같은 구현 세부사항을 전달한다. - 사용자 플로우가 어떻게 진행되는지 - 창이나 모달이 언제 나타나는지 - 드롭다운이 어떻게 동작하는지 - 최종 제품에서 각 상태가 어떻게 연결되는지 - 여러 페이지를 복잡하게 연결해야 했던 기존 방식과 달리, 하나의 Figma 파일 안에서 전체 경험을 확인하고 검토할 수 있다는 점이 장점이다. ## 회의 이후에도 유지되는 비동기 협업 맥락 - 프로토타입은 회의 중 합의만 돕는 것이 아니라, 회의에 참석하지 못한 구성원에게도 결정의 맥락을 보존한다. - 원격·비동기 환경에서는 회의에서 무엇을 확인하고 결정했는지가 이후 작업의 효율을 좌우한다. - Condé Nast의 제품 개발 팀은 매일 스탠드업을 진행해 다음을 공유한다. - 현재 진행 상황 - 우선순위 - 예상되는 장애물 - 팀이 확인해야 할 질문 - 이러한 정기적인 정렬은 팀이 서로 다른 방향으로 작업하는 것을 방지하고, 문제를 조기에 드러내도록 한다. ## Figma와 Jira를 통한 디자인-개발 연결 - 디자인이 코드로 전환되는 과정에서는 디자인 파일, 개발 작업, 요구사항이 서로 다른 위치에 흩어지기 쉽다. - Figma for Jira는 Jira 작업 항목에 디자인 맥락을 연결해 개발자가 구현 시 필요한 정보를 더 쉽게 확인하도록 지원한다. - 글은 업데이트된 Figma for Jira 앱을 소개하면서, 제품 개발팀이 디자인과 개발 워크플로를 더 가깝게 연결하는 방법을 설명한다. - 핵심 목적은 단순히 디자인 링크를 첨부하는 것이 아니라, 개발자가 디자인의 배경과 동작 방식을 함께 이해하도록 하는 데 있다. ## 실천을 위한 시사점 - 기능 구현 전에 정적 화면보다 실제 인터랙션을 포함한 프로토타입으로 논의한다. - 디자인 리뷰에는 개발자를 참여시켜 상태 변화와 예외 흐름까지 함께 확인한다. - 회의에서 결정한 내용은 프로토타입과 작업 티켓에 남겨 비동기 작업에서도 맥락이 유지되게 한다. - Figma와 Jira를 연결해 디자인 의도, 요구사항, 개발 진행 상황을 하나의 흐름으로 관리한다.

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

프로토타이핑 문화를 조성

프로토타이핑은 더 이상 개발 직전의 선택적 작업이 아니라, 제품 개발 전반에 통합해야 할 핵심 활동이다. 인터랙티브한 프로토타입은 정적 디자인에서 놓치기 쉬운 내비게이션과 사용자 경험 문제를 조기에 발견하고, 개발 전에 아이디어의 가치를 검증하게 한다. 조직 전체가 프로토타이핑을 일상적인 업무 방식으로 받아들이면 실험과 의사결정이 빨라지고 더 나은 제품을 만들 수 있다. ## 프로토타이핑의 역할과 가치 - 프로토타입은 제품의 형태와 동작을 미리 보여주는 모형 또는 데모다. - 인터랙션과 경험을 충분히 높은 완성도로 재현해, 실제 개발에 들어가기 전에 아이디어를 평가할 수 있다. - 정적 화면만으로는 발견하기 어려운 내비게이션 문제, 사용성 장애, 사용자 테스트상의 문제를 조기에 드러낸다. - 개발 전에 문제를 수정하므로 엔지니어링 시간과 불필요한 개발 사이클을 줄인다. - 디자인을 단순한 시각 결과물이 아니라 실제 제품 경험으로 전환한다. ## 빠른 실험과 아이디어 검증 - 여러 아이디어를 개발 리소스를 추가로 투입하지 않고 빠르게 만들고 검증할 수 있다. - 초기에는 다양한 방향으로 폭넓게 탐색한 뒤, 가능성이 높은 해법으로 좁혀 갈 수 있다. - 이러한 과정은 더 창의적이고 기존 방식에서 벗어난 사용자 경험을 만드는 데 도움이 된다. - 프로토타입은 아이디어를 상위 의사결정자에게 구체적으로 보여주는 증거가 되어, 프로젝트 승인과 설득을 앞당긴다. - 디자이너는 인터랙티브한 결과물로 자신의 의도를 효과적으로 전달하고 제품 및 비즈니스 의사결정에 영향력을 행사할 수 있다. ## 프로토타이핑 문화의 확산 - 프로토타이핑 문화는 과거 디자인 시스템이 발전한 과정과 비슷하게 확산되고 있다. - 도구 접근성이 높아지고 교육 프로그램이 생기면서 더 많은 팀이 프로토타이핑을 업무에 활용할 수 있게 됐다. - Lyft는 정적 디자인을 넘어 동영상, GIF, 인터랙티브 프로토타입을 활용하고, 사용자 피드백을 제품 리뷰에 빠르게 반영하는 사례로 소개된다. - 프로토타이핑을 중시하는 조직은 혁신과 디자인을 중요하게 여긴다는 신호를 제공하며, 우수한 디자인 인재를 끌어들이는 데도 도움이 된다. ## 조직 차원의 정착 조건 - 프로토타이핑을 익히고 실천할 수 있도록 시간과 리소스를 공식적으로 배정해야 한다. - 이를 최종 단계의 선택 사항이 아니라 디자인 프로세스에 자연스럽게 포함된 필수 단계로 바꿔야 한다. - 실무자는 프로토타이핑 역량을 발전시키고, 리더십은 효율성과 의사결정 개선에 미치는 가치를 인정해야 한다. - 리더는 팀이 프로토타이핑을 프로세스에 포함하도록 명시적으로 요구하고, 실제로 작업할 시간과 환경을 제공해야 한다. - 관심 있는 직원들을 위한 전문 프로그램을 운영하고, 습득한 지식을 교육·개발 체계와 주요 리뷰 과정에 확장할 수 있다. - 실무자와 리더 중 한쪽만 동의하면 문화로 정착하기 어렵기 때문에 조직 전반의 공감대가 필요하다. ## 제품 개발 프로세스의 변화 - 프로토타이핑을 앞단에 배치하면 제품 개발은 기존의 선형적인 순서에서 더 반복적이고 탐색적인 과정으로 바뀐다. - 잠재적 장애물을 빠르게 발견하고 여러 대안을 평가할 수 있어, 이미 알려진 문제를 피하면서 해결책에 집중할 수 있다. - 프로토타이핑 문화는 디자이너의 역할뿐 아니라 제품·엔지니어링·리더십 간 협업 방식과 의사결정 구조 전체를 변화시킨다. - 결과적으로 개발 착수 후 수정하는 비용보다, 개발 전 실험하고 학습하는 비용을 우선하게 된다. 실무적으로는 모든 기능에 높은 완성도의 프로토타입을 만들기보다, 위험이 큰 인터랙션과 사용자 경험부터 짧게 실험하는 것이 효과적이다. 이를 정기 리뷰와 교육 과정에 포함하고 리더가 시간을 보장해야 프로토타이핑이 일회성 산출물이 아니라 조직의 기본 업무 방식으로 자리 잡을 수 있다.

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

기대를 현실로: AI 기능을 시장

AI 기능은 유행을 따라 추가할 것이 아니라, 사용자가 실제로 겪는 문제에서 출발해야 한다. Figma·Asana·Duolingo·LinkedIn의 제품 리더들은 AI의 적합성, 오류 허용 수준, 명확한 사용자 가치와 구체적인 문제 정의가 성공적인 출시의 핵심이라고 강조한다. 특히 AI는 기존 경험을 대체하기보다 시간을 절약하고 업무를 개선하는 방식으로 활용될 때 신뢰와 ROI를 얻을 수 있다. ## 사용자 문제에서 출발하기 - AI가 새로운 기능을 만들 수 있다는 이유만으로 도입해서는 안 된다. - 먼저 사용자가 겪는 문제를 파악한 뒤, AI가 최선의 해결 방법인지 검토해야 한다. - Figma의 Conor Woods는 “AI라는 망치로 모든 문제를 해결하려는” 접근을 경계한다. - AI 도입 여부를 판단할 때 다음 세 가지 질문을 제시한다. - **기존의 대규모 데이터셋을 활용할 수 있는 문제인가?** - GPT-4 같은 LLM은 이미 존재하는 정보를 정리하거나 요약하는 데 강하다. - 반면 완전히 새로운 경험을 창조하는 일은 프롬프트 설계만으로 해결하기 어렵다. - **일정 수준의 오류를 허용할 수 있는가?** - 현재 LLM은 부정확한 답변이나 사실과 다른 정보를 생성할 수 있다. - 따라서 100% 정확성이 필요한 의료·법률·규정 준수 등의 문제에는 신중해야 한다. - **나쁜 UX를 AI로 덮으려는 것은 아닌가?** - 근본적인 정보 구조나 제품 설계가 잘못된 상태에서 AI 검색·비서를 추가해도 문제 자체는 해결되지 않는다. - Asana는 더 단순하게 “AI가 사용자의 시간을 줄여주는가?”를 기준으로 삼는다. - Asana의 **Smart Status**는 사용자가 상태 업데이트 초안을 몇 초 만에 작성하도록 돕는다. - 기존에는 주당 약 20분이 걸리던 작업을 2분 정도로 줄일 수 있다. - 사용자가 체감하는 투자 대비 효과가 명확하다는 점이 핵심이다. ## 문제를 구체적으로 정의하기 - 생성형 AI 기능은 여러 요구를 동시에 충족할 수 있기 때문에, 기능 정의가 모호해지기 쉽다. - “텍스트를 요약한다”처럼 기능을 추상적인 문장으로만 설명하면 팀원마다 서로 다른 결과를 상상하게 된다. - 요약 기능만 해도 실제 목적은 다양할 수 있다. - 문서의 전체 내용을 빠르게 파악하기 - 실행해야 할 작업을 식별하기 - 핵심 결정 사항이나 논쟁점을 찾기 - 따라서 AI 기능을 기획할 때는 단순히 모델의 능력을 설명하기보다 다음을 구체화해야 한다. - 사용자는 누구인가? - 어떤 상황에서 이 기능을 사용하는가? - 사용자가 해결하려는 실제 과업은 무엇인가? - AI가 생성해야 하는 결과물은 어떤 형태인가? - 결과가 틀렸을 때 사용자가 감수할 수 있는 위험은 어느 정도인가? - 문제를 구체적으로 정의할수록 제품 요구사항, 사용자 인터페이스, 평가 기준을 일관되게 설계할 수 있다. ## 실용적인 적용 방향 - “AI를 어디에 넣을까?”보다 “사용자의 어떤 반복 작업을 줄일 수 있을까?”에서 시작한다. - AI를 적용하기 전 기존 UX의 구조적 문제를 먼저 해결한다. - 오류가 허용되는 영역인지 확인하고, 사용자 검토·수정 과정을 제품에 포함한다. - 기능 설명을 모델의 기술적 능력이 아니라 사용자의 구체적인 과업과 기대 결과 중심으로 작성한다. - 출시 전에는 시간 절약, 작업 완료율, 수정 횟수, 사용자 신뢰도처럼 측정 가능한 기준을 정해 AI 기능의 실제 가치를 검증한다.

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

시시르 메로트라가

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

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

새로운 진을 통해 놀이의

놀이와 호기심은 디자인 과정에서 새로운 아이디어와 해결 경로를 발견하게 하는 중요한 원동력이다. Figma와 It’s Nice That는 이러한 가치를 탐구하기 위해 디자인 에세이, 시각 작품, 참여형 활동을 담은 인쇄 잡지 **《The Playbook》**을 공동 제작했다. 이 잡지는 Config 2023에서 공개되어 반복, 협업, 실험적 사고를 실제로 경험하도록 구성되었다. ## 놀이를 디자인 과정에 활용하기 - 놀이(play)는 전시, 서체, 앱 등 다양한 디자인 작업에서 기존 접근법을 벗어나 새로운 가능성을 탐색하게 한다. - 정답을 빠르게 찾기보다 우연한 시도와 호기심을 통해 다음 아이디어로 이어지는 경로를 만든다. - Figma는 놀이를 학습과 연결하고, 협업 과정에서 서로 다른 생각을 연결해 새로운 아이디어를 얻는 방식으로 바라본다. ## 《The Playbook》의 구성 - 여러 편의 에세이와 시각 커미션을 묶어 놀이의 가치를 다양한 관점에서 보여준다. - Figma 최고제품책임자 Yuhki Yamashita는 끝없이 변화하는 작업 상태를 받아들이고 반복을 즐기는 방법을 다룬다. - 최고기술책임자 Kris Rasmussen은 엔지니어가 역할과 코드 경계를 넘어 협업하는 방식을 설명한다. - 창작자들의 인터뷰와 조언을 통해 무한한 가능성 속에서 “만약 이렇게 해보면 어떨까?”라는 질문을 시작점으로 삼는 방법을 제안한다. - 디자이너 Paula Scher는 오랜 경력을 바탕으로 스케치, 영향, 창작 습관 등에 관한 ‘놀이의 10가지 규칙’을 공유한다. ## 독자가 직접 참여하는 활동 - 잡지 자체에 독자로서 ‘온보딩’하는 활동이 포함되어 있다. - 퀴즈를 통해 자신의 회의 진행 스타일을 알아볼 수 있다. - “How might we?”라는 문구를 바탕으로 한 디자인 과제를 수행할 수 있다. - Shawna X는 ‘번뜩이는 아이디어’를 시각화했고, 해당 작품은 리소그래프 인쇄물로 제작되었다. - Manshen Lo는 Bruno Munari의 12단계 디자인 방법론을 자신만의 방식으로 해석했다. ## 인쇄물과 협업 방식 - 《The Playbook》은 A5 크기의 진(zine) 형태로 인쇄되었으며, 퇴비화 가능한 셀로판으로 포장되었다. - Yuhki Yamashita와 Kris Rasmussen의 글은 서로 마주 보는 A6 크기의 별도 진으로 구성되었다. - 디지털 콘텐츠가 아니라 물리적 인쇄물과 활동지를 결합해 독자가 직접 읽고, 보고, 기록하고, 실험하도록 설계했다. - Config 2023 참가자들은 행사 입장 시 잡지를 받아 현장에서 내용을 살펴볼 수 있었다. ## 실용적인 시사점 디자인 작업에서는 완성도와 효율만 추구하기보다 의도적인 실험과 반복의 시간을 확보하는 것이 좋다. 회의나 워크숍에 짧은 퀴즈, 제약이 있는 스케치, “How might we?” 질문 같은 놀이 요소를 도입하면 팀의 호기심과 협업을 촉진할 수 있다.

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

역할이 규칙이 아닌 이유

제품 개발이 협업 중심으로 바뀌면서 엔지니어의 역할은 정해진 요구사항을 구현하는 데서 벗어나, 무엇을 만들지까지 함께 결정하는 방향으로 확장되고 있다. 하지만 협업과 피드백을 항상 늘리는 것이 정답은 아니며, 다양한 의견을 탐색하는 단계와 결정을 내리고 추진하는 단계 사이의 균형이 중요하다. Figma는 역할을 고정된 규칙으로 보지 않고, 초기부터 폭넓게 협업하되 마일스톤을 통해 적절한 시점에 수렴하는 방식을 택한다. ## 엔지니어 역할의 확장 - 웹 기술의 발전과 Google Docs 같은 협업 도구의 확산, 원격·하이브리드 근무의 증가로 제품은 점점 “멀티플레이어 기본값”이 되었다. - 제품 개발은 더 이상 디자인에서 시작해 엔지니어링으로 끝나는 선형적인 과정이 아니다. - 엔지니어는 단순히 구현 방법(how)을 결정하는 사람이 아니라, 고객 피드백과 제품·디자인 동료의 의견을 바탕으로 만들 대상(what)도 함께 정의한다. - 따라서 직무의 경계를 엄격한 규칙으로 보기보다, 필요한 순간 서로의 영역을 넘나드는 협업 방식이 요구된다. ## 협업과 독립성 사이의 균형 - 다른 사람의 지식을 활용하는 것과, 방향 없이 계속 논의만 반복하는 것은 다르다. - 모든 작업에서 항상 최대한 많은 사람의 피드백을 받으면 품질이 높아질 것 같지만, 오히려 결정이 늦어지고 프로젝트가 제자리걸음할 수 있다. - 독립적으로 집중해야 하는 시기와 적극적으로 다른 팀을 끌어들여야 하는 시기는 작업마다 다르다. - 적절한 균형은 조직 문화, 제품의 특성, 팀이 최적화하려는 목표에 따라 달라진다. ## 초기 아이디어를 공개하는 방식 - 새로운 업무를 시작할 때는 가능한 한 이른 시점부터 다양한 관점을 반영한다. - 엔지니어는 완성된 설계가 아니라 초기의 생각과 가설을 문서로 작성해야 한다. - 문서는 “완성 후 검토”를 위한 산출물이 아니라, 작업 중인 상태에서 피드백을 받기 위한 협업 도구다. - 대부분의 프로젝트에 초기 생각을 기록하는 문서가 존재하지만, 각 팀이 바쁜 상황에서도 빠르게 피드백을 주고받을 수 있는 구조가 필요하다. ## 엔지니어링 크리트: 승인보다 피드백 - Figma는 디자인·엔지니어링 조직 간 정기적인 엔지니어링 크리트(crit)를 운영한다. - 크리트의 목적은 다음과 같다. - 기술 설계를 초기에 공유한다. - 다른 팀으로부터 자주 피드백을 받는다. - 전문적인 기술 지원과 문제 제기를 얻는다. - 크리트는 승인 회의가 아니다. - 회의에서 최종 결정을 내리거나 작업을 확정하지 않는다. - 작업 중인 상태(WIP)를 전제로 문제를 지적한다. - 설계 자체가 충분히 발전해 별도의 승인을 필요로 하지 않도록 돕는다. - Figma는 FigJam을 사용해 실시간으로 참여하고 의견을 시각적으로 공유한다. ## 너무 많은 의견이 만드는 정체 - 다양한 의견은 유용하지만, 입력이 지나치게 많거나 서로 충돌하면 프로젝트가 방향을 잃을 수 있다. - 특히 가격 정책처럼 불확실성과 중요한 트레이드오프가 많은 문제에서는 아이디어가 계속 추가되면서 결정을 내리지 못할 위험이 크다. - 탐색적이고 생성적인 논의만 계속하면 프로젝트가 앞으로 나아가지 못한다. - 협업의 목표는 모든 의견을 반영하는 것이 아니라, 더 나은 결정을 내릴 수 있을 만큼 설계를 발전시키는 데 있다. ## 마일스톤을 통한 수렴 - Figma는 프로젝트를 여러 마일스톤으로 나누어 탐색과 실행의 시점을 구분한다. - 마일스톤을 명확히 정의하고 공유하면 다음과 같은 효과가 있다. - 이해관계자의 기대치를 관리할 수 있다. - 현재 단계에서 무엇을 결정해야 하는지 분명해진다. - 계속 확장하기보다 수렴해야 할 시점을 알 수 있다. - 프로젝트가 진전되려면 다양한 가능성을 열어두는 단계와, 하나의 방향을 선택해 추진하는 단계가 모두 필요하다. - 추진력(momentum)이 유지되면 목표에 가까워지고 있다는 감각을 얻지만, 추진력을 잃으면 프로젝트의 방향과 목적 자체를 다시 의심하게 된다. ## 실용적인 적용 - 초기 설계와 가설을 완성되기 전에 문서로 공유한다. - 피드백 회의는 승인 절차가 아니라 문제를 조기에 발견하는 자리로 운영한다. - 모든 의견을 반영하려 하지 말고, 마일스톤마다 탐색을 멈추고 결정을 내릴 시점을 명확히 한다. - 역할과 책임을 고정된 경계로 보지 않되, 최종적으로는 누가 어떤 결정을 내리고 실행할지 분명히 해야 한다.

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

FigJam의 테이블 기능: 기준 (새 탭에서 열림)

FigJam은 팀원들이 정보를 더 효과적으로 구조화하고 로드맵을 작성할 수 있도록 새로운 '테이블' 기능을 도입했습니다. 복잡한 데이터 연산보다는 시각적 가독성과 직관적인 편집 경험에 집중하여, 디자이너뿐만 아니라 비전문가도 쉽게 협업 도구로 활용할 수 있도록 설계된 것이 특징입니다. 특히 멀티플레이어 환경에서의 데이터 충돌을 해결하고 사용자의 줌(Zoom) 수준에 따른 최적화된 UI를 제공함으로써 FigJam만의 독특한 사용성을 완성했습니다. ## FigJam 테이블의 지향점: 단순함과 시각적 전달 * 엑셀이나 구글 스프레드시트 같은 복잡한 데이터 조작보다는 정보를 시각적으로 명확하게 전달하는 데 우선순위를 두었습니다. * 사용자들이 기존에 스티키 노트나 도형을 조합해 수동으로 표를 만들던 불편함을 해소하고, 네이티브 기능을 통해 성능과 사용성을 동시에 개선했습니다. * 기획서(PRD) 작성, 프로젝트 진행 상황 추적, 브레인스토밍 결과 정리 등 협업 과정에서 발생하는 다양한 시나리오를 지원합니다. ## 제작자와 사용자 모두를 고려한 디자인 시스템 * 툴바 클릭 한 번으로 미리 정의된 스타일의 테이블을 생성할 수 있어, 사용자가 폰트나 간격을 일일이 조정하는 번거로움을 줄였습니다. * 새로운 행이나 열을 추가할 때 이전 셀의 스타일(색상, 속성 등)을 자동으로 상속받아 시각적 일관성을 유지합니다. * 테이블 전체 색상을 변경하면 내부 텍스트 색상이 배경에 맞춰 자동으로 반전되거나 조정되어 최적의 가독성을 보장합니다. ## 멀티플레이어 환경을 위한 엔지니어링 * 여러 사용자가 동시에 서로 다른 셀을 편집하거나 같은 위치에 데이터를 입력할 때, 단순한 '덮어쓰기'가 아닌 데이터가 적절히 병합(Merge)되도록 정교한 로직을 구현했습니다. * 개발 시간의 50% 이상을 멀티플레이어 관련 버그 수정과 예외 상황 처리에 투입하여 실시간 협업의 안정성을 확보했습니다. * 다수의 사용자가 동시에 작업할 때 UI가 화면을 가리거나 혼란을 주는 것을 방지하기 위해, 편집 도구가 마우스 커서를 따라다니는 '호버(Hover)' 방식을 채택했습니다. ## 컨텍스트에 반응하는 스마트 인터렉션 * 사용자의 화면 확대/축소(Zoom) 비율에 따라 인터페이스가 유동적으로 변합니다. * 화면을 멀리서 볼 때는 테이블 이동 및 전체 구조 재배치 기능에 집중하고, 화면을 가까이 확대하면 셀 세부 편집이나 행/열 추가 버튼이 활성화되어 화면의 혼잡도를 낮췄습니다. * 이를 통해 사용자는 작업의 맥락에 맞는 기능만 직관적으로 노출받으며 작업 효율을 높일 수 있습니다. **결론 및 추천** FigJam 테이블은 강력한 기능보다 사용자의 '자연스러운 협업 흐름'을 중시한 결과물입니다. 복잡한 수식이나 데이터 분석보다는 팀원 간의 아이디어 공유, 일정 관리, 회의록 정리 등 정보의 시각화가 필요한 팀에게 강력히 추천합니다.

figma2분 읽기큐레이션 요약

Figma의 시리즈 E

Figma는 Durable Capital Partners가 주도하고 Morgan Stanley의 Counterpoint Global 등 신규 투자자가 참여한 Series E 투자를 유치했으며, 기업 가치는 약 100억 달러로 평가받았다. 딜런 필드는 이번 투자를 디자인을 모든 사람에게 개방하고, 협업과 디자인 중심의 제품 개발을 확장하기 위한 출발점으로 설명했다. 또한 기존 투자자들의 재참여와 직원·커뮤니티에 대한 감사를 전했다. ## Series E 투자 유치 - Durable Capital Partners가 이번 투자를 주도했다. - Morgan Stanley의 Counterpoint Global이 신규 투자자로 참여했다. - Index, Greylock, Kleiner Perkins, Sequoia, a16z 등 기존 투자자들도 투자 라운드에 다시 참여했다. - 2021년 6월 기준 Figma의 기업 가치는 약 100억 달러로 알려졌다. ## 디자인 접근성 확대 - Figma의 장기적인 비전은 “디자인을 모두에게 접근 가능하게 만드는 것”이다. - 전문 디자이너만이 아니라 학생부터 최고경영진까지 더 넓은 디자인 커뮤니티에 참여시키려 한다. - 제품 개발에 관여하는 모든 직군이 디자인 중심으로 생각하고, 느끼고, 협업할 수 있는 환경을 목표로 한다. - 장기적으로는 다양한 직군의 사람들이 창의적으로 협업할 수 있도록 더 많은 시각적 제품을 제공하려 한다. ## 멀티플레이어 협업의 의미 - Figma는 여러 사람이 동시에 작업하는 멀티플레이어 협업 방식이 일하고 제품을 만드는 방법을 바꾼다고 강조한다. - 디자이너를 위한 전문 도구를 발전시키는 동시에, 기획·개발·경영 등 다른 역할의 구성원도 제품 개발 과정에 참여할 수 있도록 하려 한다. - 브라우저 기반 협업을 통해 디자인을 특정 전문가의 영역이 아니라 팀 전체의 활동으로 확장하려는 방향이다. ## 커뮤니티와 구성원에 대한 책임 - Figma의 성장에는 그동안 서비스를 사용하고 발전시킨 디자이너 커뮤니티의 기여가 있었다. - 회사는 성장할수록 기존 디자이너 커뮤니티를 지원하고 새로운 사용자를 포용할 책임이 있다고 밝혔다. - 코로나19 팬데믹으로 어려웠던 16개월 동안 함께 일하고 성장한 직원들에게 감사를 전했다. ## 실용적인 시사점 Figma의 Series E 발표는 단순한 투자 유치 소식이라기보다, 디자인 도구를 전문가용 소프트웨어에서 전사적 협업 플랫폼으로 확장하겠다는 전략을 보여준다. 제품 개발 조직은 디자인을 디자이너만의 업무로 한정하기보다, 다양한 직군이 초기 단계부터 시각적으로 협업하는 방식으로 활용할 수 있다.

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

Config 2021

Config 2021의 핵심 메시지는 제품 개발에서 실패, 지연, 갈등 같은 “엉킨 순간”을 피하기보다 성장의 재료로 받아들여야 한다는 것이다. 프로젝트가 중단되거나 팀 내 마찰이 생겨도 이를 개인적 실패로 해석하지 말고, 기록·대화·성찰을 통해 다음 작업과 더 나은 협업으로 전환해야 한다. ## 실패와 좌절을 새로운 관점에서 바라보기 Shopify의 Shanique Shields는 1년 반 동안 진행한 기능이 롤백된 경험을 소개한다. 처음에는 자신의 실패라고 느꼈지만, 프로젝트에서 잠시 거리를 둔 뒤 이를 학습의 기회로 재해석할 수 있었다. - **실패를 개인적인 평가로 받아들이지 않기** - 피드백이나 기능 변경은 작업자의 능력보다 이해관계자와 고객의 관점 차이에서 비롯될 수 있다. - **과정을 문서화하기** - 출시되지 않은 작업이라도 디자인 의도, 의사결정 과정, Figma 댓글과 메모를 보존한다. - 기록은 다음 프로젝트에서 개선점을 찾게 하고, 다른 디자이너가 참고할 수 있는 작업 아카이브가 된다. - **프로젝트에서 얻을 것을 의식하기** - 새로운 기술, 사업 영역에 대한 이해, 다른 직군과의 협업 경험 등 프로젝트를 통해 얻는 성장을 명확히 파악한다. - **다음 작업을 새로운 출발점으로 삼기** - 실패감에 머무르기보다 다음 업무의 공동 목표를 세우고 팀의 동기를 다시 끌어올린다. ## 솔직한 대화와 주의 깊은 경청 Headspace의 Frank Bach는 팀의 갈등을 방치하지 말고 투명한 대화로 해결해야 한다고 강조한다. 강한 팀 문화와 프로세스가 있어도 의사소통이 끊기면 문제가 쌓일 수 있기 때문이다. - 갈등 상황에서 자신의 입장을 최대한 투명하게 설명한다. - 상대방의 말을 실제로 이해하려는 태도로 듣는다. - 어려운 대화라도 객관적이고 솔직하게 시작해야 한다. - 마찰을 무시하면 문제가 해결되지 않고 더 커지므로, 용기를 내어 직접 다룬다. - 일이 잘 풀렸을 때는 동료, 팀, 디자이너로서의 기회에 감사하는 태도도 중요하다. ## 지속 가능한 팀 문화를 만드는 태도 Config 2021에서는 팀 문화 전환과 확장 가능한 프로세스도 다뤘지만, 실제 업무에서는 예상치 못한 장애와 인간적인 갈등이 언제든 발생한다는 점을 전제로 한다. - 완벽하게 정리된 프로세스만으로 모든 문제를 예방할 수는 없다. - 실패와 충돌을 숨기기보다 학습 가능한 경험으로 공개적으로 다룬다. - 개인의 감정적 회복과 팀 차원의 목표 재정렬을 함께 진행한다. - 기록과 솔직한 대화를 통해 어려운 경험을 조직의 지식으로 전환한다. 실무에서는 프로젝트가 중단되거나 갈등이 생겼을 때 즉시 자책하거나 회피하기보다, 잠시 거리를 두고 과정을 기록한 뒤 당사자들과 사실 중심으로 대화하는 것이 좋다. 그렇게 하면 실패한 결과도 개인과 팀의 성장 자산으로 남길 수 있다.

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

렙솔(Repsol) (새 탭에서 열림)

스페인 최대 에너지 기업인 렙솔(Repsol)은 2050년 탄소 중립 달성을 목표로, 난해한 에너지 개념을 소비자가 친숙하게 느낄 수 있도록 디자인 중심의 디지털 전환을 추진하고 있습니다. 이를 위해 렙솔은 디자인 에이전시 및 피그마(Figma)와 협력하여 전사 통합 디자인 시스템인 '옥시젠(Oxygen)'을 구축하고 분산되어 있던 사용자 경험을 하나로 통합했습니다. 결과적으로 디자인은 단순한 시각적 개선을 넘어 제품 구현에 필요한 리소스를 30% 절감하고, 기업의 비즈니스 가치를 측정 가능한 수치로 증명하는 핵심 전략으로 자리 잡았습니다. **에너지 경험의 재정의와 시각화** * **인간 중심의 에너지:** 에너지를 '필요악'이 아닌 사용자가 주도적으로 관리할 수 있는 대상으로 변화시키기 위해 디자인을 활용합니다. * **실시간 가시성 제공:** 단순히 요금 고지서를 발행하는 것에 그치지 않고, 현재 날씨에 맞춰 실시간으로 가동되는 태양광 패널이나 풍력 발전기의 정보를 앱 내에서 시각적으로 보여줌으로써 에너지 사용에 대한 실감을 높였습니다. * **행동 변화 유도:** 전기차 공유 서비스 앱을 통해 주행 중 에너지 소비량을 보여주고 효율성에 따른 등급을 부여하여, 사용자가 더 효율적으로 에너지를 소비하도록 독려합니다. **Oxygen 디자인 시스템을 통한 통합** * **일관된 상호작용 언어:** 과거 10개의 제품이 각기 다른 방식으로 사용자와 소통하던 문제를 해결하기 위해, 모든 디지털 제품에 적용되는 공통의 패턴, 컴포넌트, 가이드를 구축했습니다. * **커뮤니케이션 허브로서의 피그마:** 피그마를 중심 도구로 채택하여 실무 디자이너부터 경영진까지 실시간으로 의견을 공유하고 아이디어를 반복 수정할 수 있는 환경을 조성했습니다. * **워크플로우 최적화:** 기존에 사용하던 Sketch, Invision, PowerPoint 등의 도구를 피그마 하나로 대체하여 15개 이상의 프로젝트를 동시에 일관성 있게 관리할 수 있게 되었습니다. **디자인 성과 측정과 효율성 증대** * **전용 플러그인 활용:** 피그메트릭스(Figmetrics)와 MSVM 플러그인을 개발하여 컴포넌트 활용도와 팀 간 정렬 상태를 추적하고 디자인의 투자 대비 효율(ROI)을 데이터로 입증했습니다. * **운영 효율성 개선:** 새로운 디자인 시스템 도입 이후 제품 구현에 드는 작업량을 기존 대비 30% 절감하는 성과를 거두었습니다. * **단일 진실 공급원(Single Source of Truth):** 디자인, 제품 관리, 비즈니스, 기술 팀이 동일한 기준 아래 협업함으로써 의사결정 프로세스를 단순화했습니다. 에너지 산업과 같이 복잡하고 보이지 않는 가치를 다루는 기업일수록 디자인 시스템은 단순한 도구를 넘어 비즈니스의 효율성과 사용자 신뢰를 구축하는 강력한 기반이 됩니다. 렙솔의 사례처럼 디자인 시스템을 통해 확보한 여유 자원을 기업의 본질적인 미션인 탄소 중립과 혁신에 재투자하는 선순환 구조를 구축할 것을 권장합니다.

figma3분 읽기큐레이션 요약

피그마 내부 이야기: 신입

Josh Shi는 대학 졸업 후 Figma에 입사한 경험을 바탕으로, 취업을 “좋은 회사의 조건을 체크하는 일”이 아니라 자신과 일의 관계를 탐구하는 과정으로 바라보자고 말한다. 특히 일과 삶을 서로 상쇄되는 두 영역으로 보지 말고, 함께 삶을 구성하며 서로 영향을 주는 요소로 이해해야 한다고 강조한다. 신입 엔지니어에게는 회사의 명성보다 자신의 관심사·성장 방식·가치관이 실제 업무 환경과 맞는지를 질문하라고 조언한다. ## 정답이 아닌 질문으로 취업을 바라보기 - 저자는 대학 졸업 당시 Figma를 선택한 이유를 완벽하게 설명할 수 없었다고 고백한다. - 면접에서 만난 사람들이 친절하고 사려 깊으며, 자신을 한 사람으로 이해하려는 태도를 보였던 점이 인상적이었다. - “흥미로운 문제”, “똑똑한 동료”, “좋은 문화” 같은 일반적인 평가 기준만으로는 개인에게 의미 있는 직장을 판단하기 어렵다. - 회사 선택에서 중요한 것은 정해진 체크리스트보다 다음과 같은 자기 성찰이다. - 어떤 종류의 일에 관심이 있는가? - 회사가 그 관심사를 발전시킬 기회를 제공하는가? - 관심사가 바뀌었을 때 업무나 역할도 변화할 수 있는가? - 어떤 기술과 전문성을 쌓을 수 있는가? - 일이 직장 밖의 다른 관심사와 삶의 방향에도 어떤 영향을 주는가? ## ‘일과 삶의 균형’이라는 단순한 프레임의 한계 - 일과 삶을 시소의 양쪽처럼 보는 전통적인 “work-life balance” 개념은 지나치게 단순하다. - 일과 비업무 시간은 서로 독립된 영역이 아니라, 합쳐져 한 사람의 삶을 구성한다. - 업무 만족도는 개인 생활의 만족도에 영향을 주고, 반대로 삶의 상태도 업무 경험에 영향을 준다. - 단순히 근무 시간을 줄이거나 일정한 시간 비율을 맞춘다고 해서 올바른 균형이 만들어지는 것은 아니다. - 사람마다 일에 자신의 정체성을 얼마나 연결할지는 다르며, 어느 한 방식이 정답은 아니다. - 저자는 일과 삶을 어떻게 배치해야 자신이 원하는 방식으로 살 수 있는지 질문해야 한다고 말한다. - 다만 모든 사람이 업무 환경을 자유롭게 선택할 수 있는 것은 아니다. 생계와 고용 안정성이 우선인 상황에서는 일을 커리어의 일부로 바라볼 여유가 제한될 수 있다. ## 신입으로서 얻은 기술적·실무적 성장 - Figma에서 새로운 기술 경험을 쌓았다. - 풀스택 개발을 경험했다. - 웹 환경에서 C++를 사용하는 업무를 접했다. - 단순히 코드를 작성하는 것을 넘어 기능을 실제로 소유하고 제품 개발 과정에 참여했다. - 다음과 같은 제품 개발 역량을 배웠다. - 기능과 제품의 범위를 현실적으로 정하기 - 모호한 목표를 구체화하기 - 아이디어를 처음부터 출시까지 발전시키기 - 제품을 신중하게 설계하고 구현하기 - 신입 개발자에게 기술 스택보다 중요한 성장 요소는 기능의 전체 생명주기를 경험하고 결과에 책임지는 것이라고 볼 수 있다. ## 멘토와 조직 환경의 영향 - 저자의 성장에는 주변 동료들의 지원과 지도가 결정적인 역할을 했다. - 동료들은 의도적으로 멘토 역할을 하지 않았더라도, 도전할 기회와 업무 소유권을 제공하며 성장을 도왔다. - 면접 당시 함께 식사했던 동료들 중 상당수가 계속 Figma에 남아 있었고, 저자는 그들의 경험과 관대함으로부터 지속적으로 도움을 받았다. - 신입이 회사를 평가할 때는 공식적인 복지나 문화 설명뿐 아니라 다음 요소도 살펴볼 필요가 있다. - 질문하고 도움을 요청하기 쉬운가 - 신입에게 실제 책임과 소유권을 주는가 - 동료들이 지식을 공유하는가 - 새로운 역할이나 기술을 시도할 수 있는가 ## 회사와 역할은 계속 변한다 - 저자가 입사한 뒤 Figma는 회사와 제품 모두 크게 성장했다. - 입사 당시와 현재의 조직 환경은 달라졌으며, 회사는 하이브리드 모델로 전환하기 시작했다. - 따라서 취업 선택은 고정된 조건을 고르는 일이 아니라, 변화하는 회사 안에서 자신의 관심과 역할이 어떻게 발전할 수 있는지를 판단하는 일이다. - 좋은 직장은 처음부터 모든 조건이 완벽한 곳이라기보다, 개인의 성장과 변화에 맞춰 역할을 확장하거나 조정할 수 있는 환경일 수 있다. 취업을 준비하는 신입 개발자는 회사의 유명세나 기술 목록만 비교하기보다, 자신이 배우고 싶은 방식과 일의 의미를 먼저 정리하는 것이 좋다. 면접에서는 업무 내용뿐 아니라 멘토링, 기능 소유권, 역할 변화 가능성, 조직의 성장 방향을 구체적으로 질문하는 것이 실용적이다.

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