에이전시 인턴 시절, 가장 두려웠던 피드백은 "디자인이 별로다"가 아니었습니다. "뭔가 느낌이 딱딱한데, 조금 더 감성적으로 둥글게 말아줄 수 없어?"라는 클라이언트의 추상적인 요구였습니다. 저는 그때마다 코너 라운드 값(Radius)을 4px에서 6px로, 8px로 무의미하게 수정하며 밤을 새웠습니다. 공대생 마인드를 가진 저에게 디자인이 '감'의 영역으로 치부되는 순간은 고역이었습니다. 하지만 iOS 7 업데이트 이후, 저는 디자인이 철저한 수학과 논리의 산물임을 깨달았습니다. 애플이 선보인 미묘하게 다른 둥근 모서리, 바로 '스쿼클(Squircle)'의 존재를 알게 된 순간부터입니다. 오늘은 우리가 무심코 사용하는 '둥근 모서리' 뒤에 숨겨진 치열한 공학적 사투와, 이를 통해 주니어 디자이너가 갖춰야 할 논리적인 태도에 대해 이야기하려 합니다.
단순한 라운드가 아닙니다: 곡률의 연속성
대부분의 주니어 디자이너나 개발자는 CSS의 border-radius 속성 하나면 모든 것이 해결된다고 생각합니다. 하지만 애플의 하드웨어나 인터페이스를 유심히 살펴본 적이 있다면, 우리가 대충 설정한 R값과는 무언가 다르다는 것을 느꼈을 것입니다. 일반적인 라운드 사각형(Rounded Rectangle)은 직선 구간과 곡선 구간이 만나는 지점에서 곡률이 급격하게 변합니다. 반면, 애플이 사용하는 스쿼클(Squircle)은 직선에서 곡선으로 넘어가는 과정이 점진적이고 유기적입니다. 이것은 단순한 심미성의 문제가 아닙니다. 산업 디자인에서는 이를 '곡률 연속성(Curvature Continuity)'이라고 부르며, 빛이 표면에 맺힐 때 하이라이트가 끊어지지 않고 매끄럽게 흐르도록 만드는 핵심 기술입니다.
피그마(Figma)의 엔지니어들은 이 미묘한 차이를 구현하기 위해 엄청난 삽질을 겪었습니다. 2013년 iOS 7이 발표되었을 때, 홈 화면의 아이콘은 단순한 라운드 사각형이 아니었습니다. 디자이너들은 이를 '슈퍼엘립스(Superellipse)'라는 수학적 개념으로 정의하려 노력했습니다. 이는 원과 사각형 사이 어딘가에 존재하는 형태로, n=5일 때 애플의 아이콘과 가장 유사한 형태를 띱니다. 중요한 것은 이 형태가 "예뻐서" 쓴 것이 아니라, 사용자가 화면을 볼 때 시각적인 거슬림을 최소화하고 마치 강가의 조약돌처럼 자연스러운 물체로 인식하게 만들기 위한 철저한 계산의 결과라는 점입니다. 우리가 단순히 "조금 더 부드럽게"라고 말할 때, 엔지니어들은 이 복잡한 베지에 곡선(Bézier curve)을 어떻게 렌더링할지 고민해야 합니다.
디자인은 제약을 관리하는 공학입니다
피그마 팀이 이 '스쿼클'을 툴에 적용하는 과정은 찰스 임스(Charles Eames)의 디자인 철학을 완벽하게 대변합니다. 임스는 디자인을 "특정 목적을 달성하기 위해 요소들을 배열하는 계획"이라고 정의했습니다. 피그마 엔지니어들은 애플의 폐쇄적인 공식과 싸우며, 완벽한 스쿼클을 구현하기 위해 베지에 곡선 데이터를 역추적하고 유전 알고리즘까지 동원했습니다. 주니어 디자이너인 우리가 여기서 배워야 할 점은 명확합니다. "느낌적인 느낌"으로 디자인하는 시대는 끝났다는 것입니다. 여러분이 1px의 곡선을 그릴 때, 그것이 개발 환경에서 border-radius로 구현될지, 아니면 SVG나 별도의 마스킹 처리가 필요한지, 혹은 피그마의 'Corner Smoothing' 기능을 60%로 설정했을 때(이것이 iOS의 스쿼클 값과 유사합니다) 개발자가 이를 코드로 어떻게 받아들일지 고민해야 합니다.
현업, 특히 리소스가 부족한 스타트업에서는 모든 모서리에 스쿼클을 적용할 수 없습니다. 연산 비용이 들고, CSS만으로는 완벽한 구현이 까다롭기 때문입니다. 그렇기에 디자이너는 "왜 이 버튼에 스쿼클이 필요한가?"에 대해 논리적으로 설득할 수 있어야 합니다. "그냥 애플 같아서요"가 아니라, "이 버튼은 사용자의 시선이 가장 오래 머무는 CTA(Call To Action)이므로, 시각적 피로도를 낮추고 유기적인 몰입감을 주기 위해 곡률 연속성이 필요합니다. 안드로이드와 웹에서는 퍼포먼스를 위해 일반 Radius를 쓰되, iOS 네이티브 앱에서는 이 값을 적용합시다"라고 말할 수 있어야 합니다. 이것이 바로 공대생의 논리로 무장한 디자이너가 개발자와 소통하는 방식입니다.
결국 디테일은 '왜'에서 나옵니다
피그마가 굳이 그 복잡한 수학 공식을 뚫고 'Corner Smoothing' 기능을 넣은 이유는, 도구를 사용하는 디자이너들이 그 차이를 인지하고 있기 때문입니다. 여러분이 만드는 UI도 마찬가지입니다. 화면을 구성하는 사각형 하나, 모서리 하나에도 이유가 있어야 합니다. 찰스 임스는 디자인의 핵심이 "가능한 한 많은 제약을 인식하고, 그 안에서 일하려는 의지"라고 했습니다. 개발 구현의 제약, 수학적 원리의 제약을 이해하지 못한 채 그저 그림만 그리는 디자이너는 결국 도태될 수밖에 없습니다. 오늘부터라도 여러분의 디자인 시스템에 있는 Radius 값을 다시 점검해 보십시오. 그리고 개발자에게 핸드오프(Handoff) 문서를 넘길 때, 단순히 수치만 적지 말고 그 수치가 나온 배경을 한 줄이라도 더 적어보세요. 그 작은 논리가 여러분을 '감 좋은 디자이너'가 아닌 '일 잘하는 동료'로 만들어 줄 것입니다.
