ai-prototyping

4 개의 포스트

figma3분 읽기큐레이션 요약

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는 새로운 구조·기능·상호작용처럼 직접 구현하기 복잡한 작업에 사용하는 방식이 크레딧과 시간을 모두 절약한다.

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

말하기보다 보여주기: 업무

Figma는 Figma Make 프로토타입을 Figma Design, FigJam, Figma Slides에 직접 삽입할 수 있는 기능을 출시했다. 이를 통해 아이디어를 스크린샷이나 설명으로 전달하는 대신 실제로 작동하는 경험을 함께 확인하며 피드백과 의사결정을 진행할 수 있다. 또한 텍스트·요소 편집, 요소 삭제, 모델 작업 과정 검토 등 정교한 수정 기능이 추가되어 프로토타입을 더 빠르게 개선할 수 있다. ## 작업 공간 어디서나 프로토타입 공유 - Figma Make 프로토타입을 Figma Design, FigJam, Figma Slides에 삽입할 수 있다. - 아이디어 탐색부터 디자인 리뷰, 이해관계자 프레젠테이션까지 동일한 인터랙티브 프로토타입을 활용한다. - 팀원들이 변화하는 아이디어를 하나의 실제 경험으로 확인하므로 피드백과 방향성 정렬이 쉬워진다. ## FigJam에서 초기 아이디어 정렬 - FigJam 보드에 Figma Make 프로토타입을 직접 삽입해 논의의 중심으로 사용할 수 있다. - 스크린샷이나 추상적인 설명 대신 실제 화면을 클릭하며 기능과 사용자 여정을 검토한다. - 대화 과정에서 우선순위를 현실적으로 정하고, 사용자 경험의 누락된 부분을 조기에 발견할 수 있다. ## Figma Design에서 인터랙션 리뷰 - 디자인 리뷰 단계에서 UI, 문구, 인터랙션이 실제로 어떻게 동작하는지 확인할 수 있다. - 여러 디자인 버전을 나란히 비교해 실사용 상황에서 더 나은 안을 판단할 수 있다. - 구체적인 피드백을 Figma Make로 바로 되돌려 보내고, 추측 없이 수정할 수 있다. ## Figma Slides에서 사용자 경험 기반 발표 - 프레젠테이션 안에 프로토타입을 삽입해 이해관계자가 사용자 관점에서 콘셉트를 경험하도록 한다. - Figma Slides의 투표 기능으로 참석자의 의견을 빠르게 수집할 수 있다. - 논의가 진행되는 동안 얻은 피드백을 Figma Make에 반영해 즉시 업데이트할 수 있다. ## 텍스트와 요소를 직접 수정 - 프로토타입 내부의 텍스트를 직접 편집해 다양한 콘텐츠와 문구를 빠르게 시험할 수 있다. - 이해관계자 피드백에 따라 카피를 즉시 다듬을 수 있다. - **Point and edit** 도구를 사용하면 프로토타입 안에서 색상, 간격, 텍스트 스타일을 세밀하게 조정할 수 있다. - 특정 노드를 삭제하면서 나머지 구조는 유지할 수 있다. - 삭제한 요소는 `Command+Z`로 되돌릴 수 있다. ## 모델의 작업 방식 검토와 수정 - 프로토타입이 복잡해질수록 모델이 어떻게 결과를 구성했는지 확인하는 것이 중요해진다. - Figma Make는 모델의 구축 과정을 파악하고 필요할 때 방향을 수정할 수 있도록 가시성을 제공한다. - 사용자는 모델의 결과를 그대로 받아들이기보다, 아이디어와 피드백에 맞게 생성 과정을 조정하며 프로토타입을 발전시킬 수 있다. ## 실용적인 활용 - 초기 아이디어는 FigJam에서 실제 프로토타입으로 검증한다. - 디자인 리뷰에서는 여러 버전을 비교하고 구체적인 UI·문구·인터랙션 피드백을 수집한다. - 발표 단계에서는 Figma Slides의 삽입 및 투표 기능으로 합의를 이끈다. - 반복적인 수정이 필요한 경우 직접 편집, Point and edit, 노드 삭제, 실행 취소 기능을 활용하면 Figma Make 작업 속도를 높일 수 있다.

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

AI TOP 100이 우리에게 남긴 것들 (새 탭에서 열림)

카카오의 'AI Native 전략 팀'은 단 2주라는 물리적으로 불가능해 보이는 일정 속에서 AI를 극한으로 활용해 'AI TOP 100' 경진대회 시스템을 성공적으로 구축했습니다. 이번 프로젝트는 단순한 도구 도입을 넘어 기획서를 AI 프로토타입으로 대체하고 개발의 99%를 AI에게 위임하는 등 소프트웨어 개발 패러다임의 근본적인 전환을 증명했습니다. 결국 AI는 개발자를 대체하는 것이 아니라, 개발자가 더 높은 차원의 의사결정과 설계에 집중할 수 있도록 능력을 확장하는 강력한 파트너임을 확인시켜 주었습니다. **전통적 방법론을 탈피한 AI 네이티브 전략** * **물리적 한계 돌파:** 기획부터 배포까지 통상 수개월이 걸리는 공정을 예선과 본선 각각 2주라는 초단기 일정으로 단축하기 위해 AI 정면 돌파를 선택했습니다. * **기획서 없는 개발:** 상세 기획서나 화면 설계서 대신, 멤버 전원이 AI로 실제 작동하는 프로토타입을 제작하여 이를 바탕으로 요구사항을 확정하는 '초고속 프로토타이핑' 방식을 도입했습니다. * **PoC 중심의 애자일:** 추상적인 컨셉을 AI에게 던져 즉시 작동 가능한 PoC(Proof of Concept) 코드를 생성하고, 이를 검증하며 기능을 확정하는 '구현-피드백-전환' 사이클을 극단적으로 짧게 가져갔습니다. **AI와 개발자의 협업 모델 변화** * **99%의 코드 위임:** Cursor와 Claude Code 등을 활용하여 전체 코드의 대부분을 AI가 작성하게 했으며, 개발자는 직접 타이핑하는 대신 AI에게 의도를 설명하고 결과물을 검토하는 역할에 집중했습니다. * **압도적인 생산성:** 한 명의 개발자가 예선과 본선의 모든 프론트엔드 화면을 전담하거나, 하루에 2억 개의 토큰을 소모하며 시스템을 구축하는 등 기존 개발 방식으로는 불가능한 퍼포먼스를 기록했습니다. * **직무 경계의 확장:** 데이터 엔지니어가 백엔드 개발을 수행하고, 비개발자가 AI로 복잡한 알고리즘 문제를 해결하는 등 AI를 통해 개인의 기술적 한계를 넘어선 역할 수행이 가능해졌습니다. **기술적 난제와 인간의 역할(The Last Mile)** * **모델 간 논리 충돌:** AI가 제시하는 논리가 매우 탄탄하여 구성원 간 의견이 대립할 때, 최종적인 유지보수성과 시스템의 방향성을 고려해 최적의 답을 선택하는 것은 결국 시니어 개발자의 '경험'이었습니다. * **최종 의사결정의 주체:** AI는 수많은 해결책과 초안을 제시할 수 있지만, 해당 서비스의 특수성과 미래 가치를 판단하여 방향키를 쥐는 것은 여전히 사람의 몫임을 재확인했습니다. * **새로운 개발 표준의 정립:** AI 페어 프로그래밍이 일상화되면서, 개발자의 사고 흐름이 '선형적 구현'에서 'AI와 실시간 아이디에이션 및 즉각적 검증'으로 재편되었습니다. **실용적인 결론 및 제언** 미래의 개발 경쟁력은 AI를 단순한 보조 도구로 쓰는 것을 넘어, 업무 프로세스 전체를 AI 중심으로 재설계하는 'AI 네이티브' 역량에 달려 있습니다. 이제 개발자는 바닥부터 코드를 짜는 시간보다 AI가 생성한 결과물의 적합성을 판단하고 아키텍처 관점에서 통합하는 능력을 키워야 합니다. 'PoC 중심 개발'을 통해 불확실성을 속도로 돌파하는 경험을 쌓는 것이 새로운 개발 표준에 적응하는 핵심이 될 것입니다.

figma3분 읽기큐레이션 요약

회복 탄력성 있는 디자인 팀

빠르게 변하는 기술 환경과 AI의 확산 속에서 회복탄력적인 디자인 팀을 만들려면 팀의 심리적 안전과 건강을 먼저 확보해야 한다. 동시에 실험과 역할 확장을 장려하고, 디자인 완성도를 경쟁력으로 삼아 변화에 적응하면서도 높은 품질을 유지해야 한다. 글은 Figma, Twitter, 37signals에서의 경험을 바탕으로 리더가 고정된 해법보다 원칙에 기반해 팀을 운영해야 한다고 강조한다. ## 팀의 건강과 심리적 안전을 우선하기 - 스트레스, 과로, 번아웃, 발언에 대한 두려움이 있으면 구성원은 역량을 충분히 발휘하기 어렵다. - 서로 신뢰하고 공동의 목표를 공유하는 환경이 창의적인 협업의 기반이 된다. - 다양한 의견이 반영되도록 실시간 회의뿐 아니라 비동기 채널도 운영해야 한다. 그래야 회의에서 가장 목소리가 큰 사람만 의사결정을 주도하지 않는다. - 프로젝트의 초기 스케치부터 최종 디자인까지 모든 단계의 결과물을 자유롭게 공유하도록 장려한다. - 1:1 미팅, 커리어 대화, 팀 설문을 정기적으로 진행해 문제가 커지기 전에 팀의 상태를 파악한다. - 실제 가용 시간과 업무량을 고려해 과도한 약속을 피해야 한다. - 리더가 모르는 점이나 어려움을 솔직하게 드러내면 구성원도 취약함과 의견을 안전하게 공유할 수 있다. ## 실험과 역할의 유연성 장려하기 - 디자이너마다 강점과 성장 영역이 다르므로, 서로 보완적인 역량을 가진 사람들을 함께 배치하면 팀의 균형과 학습 효과가 커진다. - 리서치, 디자인, 제품, 엔지니어링의 경계가 점점 흐려지는 만큼 전통적인 직무 범위에만 머물지 않도록 해야 한다. - 디자이너가 실제 구현과 가까워지도록 AI 프로토타이핑이나 코드 실험을 장려한다. - 실제 작동하는 결과물을 빠르게 평가하면 더 나은 디자인 결정을 내릴 수 있고, 결과적으로 생산성이 높아지는 선순환이 생긴다. - 실험 결과와 학습 내용을 공유할 공간을 마련한다. Figma의 `#design-wip` 채널처럼 미완성 아이디어, 스케치, 작동하는 프로토타입도 공유할 수 있어야 한다. - 디자인 크리틱에 제품·엔지니어링 등 협업 직군을 참여시켜 새로운 관점과 포용적인 작업 방식을 만든다. - 현재 제품을 계속 출시하는 실행과 미래의 작업 방식을 탐색하는 발명을 동시에 진행해야 한다. ## 완성도를 차별화 요소로 삼기 - 경쟁이 치열한 시장에서는 유용하고 잘 실행된 제품이 사용자 충성도와 추천을 높이고 성장을 이끈다. - 특히 엔터프라이즈 소프트웨어에서는 디자인 완성도가 뒤로 밀리는 경우가 많기 때문에 세심한 품질 관리가 차별점이 될 수 있다. - 완성도 높은 결과물을 만들려면 시각적 일관성, 인터페이스의 명확성, 세부적인 사용자 경험에 주의를 기울여야 한다. - 빠른 출시와 품질 사이에는 trade-off가 발생할 수 있으며, 때로는 새 기능 추가보다 UX 개선을 우선해야 한다. - 속도를 중시하는 상황에서도 품질을 자동으로 희생하지 않도록 팀 차원의 기준과 우선순위를 명확히 해야 한다. 결국 리더는 안전하게 의견을 낼 수 있는 문화를 만들고, 실험과 직무 간 협업을 지원하며, 속도와 품질 사이의 균형을 관리해야 한다. 정기적인 팀 상태 점검과 현실적인 업무량 조정, 작게라도 지속적인 프로토타이핑이 회복탄력적인 디자인 팀을 만드는 실용적인 출발점이다.

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