리틀 빅 아웃테이크 |
Figma의 30개 이상 소규모 기능 업데이트는 처음 계획한 대로만 구현된 결과가 아니라, 개발 과정에서 발견한 엣지 케이스와 팀의 피드백을 반영해 완성됐다. 다중 선택 검색은 계층 구조를 시각화해 사용자의 혼란을 줄였고, 오버레이 블러는 위치 정보를 전달하는 방식으로 해결했으며, 캔버스 미리보기는 범위를 과감히 줄여 빠르게 출시했다. 이 글은 작은 기능도 실제 사용 맥락과 예외 상황을 깊이 검토할 때 훨씬 나은 사용자 경험으로 이어진다는 점을 보여준다. ## 엣지 케이스에서 출발한 다중 선택 검색 - 기능: 검색 결과에서 `Shift + Click` 또는 `Cmd`(Windows에서는 `Ctrl`)를 사용해 원하는 항목만 여러 개 선택하고 편집·교체할 수 있다. - 기존 Find and Replace 기능을 확장하면 비교적 간단할 것으로 예상했지만, 실제 구현 과정에서 복잡한 문제가 드러났다. - Figma에서는 프레임·컴포넌트·그룹 같은 부모 객체와 그 안의 자식 객체를 서로 독립적으로 선택하기 어렵다. - 검색 결과에 부모와 자식이 동시에 나타나면, 두 번째 항목을 선택하는 순간 의도하지 않은 하위 항목까지 함께 선택될 수 있었다. - 중첩 구조가 많은 파일에서는 어떤 객체가 실제로 선택되는지 파악하기 어려워, 기능은 작동하지만 사용자에게는 버그처럼 느껴졌다. - 해결책으로 검색 사이드바에 시각적 계층 구조를 도입했다. - 자식 항목이 어느 부모에 속하는지 표시 - `Command` 또는 `Shift`를 누른 상태에서 선택될 항목을 미리 강조 - 자동으로 포함되는 간접 선택 항목과 직접 선택한 자식 항목을 구분 - 이 사례에서 엣지 케이스는 부수적인 예외가 아니라, 다중 선택 기능의 핵심 설계를 결정하는 요소가 됐다. ## 팀 피드백으로 해결한 오버레이 블러 - 기능: 프로토타이핑에서 배경 블러가 적용된 오버레이가 실제로 뒤의 콘텐츠를 흐리게 표시한다. - 기존 렌더링 방식은 프레임 바로 아래에 있는 대상을 가져와 블러 처리하는 방식이었다. - 하지만 오버레이는 일반 프레임처럼 바로 아래에 대상이 존재하지 않기 때문에 블러가 안정적으로 렌더링되지 않았다. - 엔지니어 Brandon은 가능한 해결책과 예상되는 문제를 문서로 정리해 팀에 공유했다. - 팀은 오버레이의 위치 정보를 코드에 전달해 어느 영역을 블러 처리해야 하는지 정확히 판단하도록 제안했다. - 이후 오버레이와 해당 프레임의 관계를 명확히 연결하는 데이터를 추가했다. - 그 결과 여러 오버레이가 각자의 위치에 올바르게 그려지고, 서로 겹치는 레이어도 정확하게 합성될 수 있었다. - 이 과정은 특히 새로 합류한 구성원이 자신의 접근 방식을 팀의 검토와 피드백으로 검증하면서 자신감을 얻은 사례이기도 하다. ## 범위를 줄여 완성도를 높인 캔버스 미리보기 - 기능: 디자인 패널의 옵션 위에 마우스를 올리면 설정을 확정하기 전에 캔버스에서 결과를 미리 볼 수 있다. - 초기에는 블렌드 모드와 효과뿐 아니라 다음 기능까지 포함하려 했다. - Boolean 연산 - 컴포넌트 속성 - 폰트 선택기 - 그러나 모든 기능을 한 번에 지원하려 하면 구현 범위와 기술적 복잡도가 크게 증가했다. - 팀은 Figma 편집기에서 드롭다운으로 제공되는 속성을 전수 조사한 뒤, 구현 난이도와 사용자 가치에 따라 우선순위를 정했다. - 최종적으로는 기하 구조를 크게 변경하거나 캔버스 렌더링 방식을 대폭 수정하지 않아도 되는 기능을 우선 구현했다. - 처음에는 기능 수가 적으면 충분한 가치가 없을 수 있다는 우려가 있었지만, 제한된 범위만으로도 미리보기 경험은 충분히 강력하다는 결론에 도달했다. - 작은 기능을 빠르게 출시하려면 모든 경우를 다 지원하기보다, 사용자에게 즉시 가치를 주면서 기술적 위험이 낮은 영역부터 선택하는 것이 효과적이다. ## 작은 업데이트를 만드는 방식 - 30개 이상의 기능은 거대한 단일 프로젝트가 아니라 여러 팀의 작은 개선과 반복적인 의사결정으로 만들어졌다. - 초기 아이디어를 그대로 구현하기보다 실제 사용 상황에서 발생하는 혼란과 실패 가능성을 먼저 확인했다. - 설계와 엔지니어링이 긴밀하게 협업하며 시각적 피드백, 데이터 구조, 구현 범위를 함께 조정했다. - 문서화와 팀 리뷰는 특히 복잡한 문제를 구조화하고, 새로운 구성원이 해결책을 검증하는 데 중요한 역할을 했다. - 결과적으로 “작은 기능”도 사용자의 선택 방식, 렌더링 구조, 프로젝트 범위 같은 세부 사항을 깊이 고려해야 완성도 높은 기능이 된다. 실무적으로는 기능을 설계할 때 정상 동작만 확인하지 말고, 중첩 구조·동시 선택·레이어 순서 같은 엣지 케이스를 초기에 테스트하는 것이 좋다. 동시에 모든 기능을 한 번에 구현하려 하기보다, 사용자 가치가 크고 구조 변경이 적은 범위부터 출시한 뒤 점진적으로 확장하는 접근이 현실적이다.
원문 읽기(새 탭에서 열림)