문자발송을 위한 전략패턴 활용

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Findividual-corner-radius%2Fe46960fb-feb3-44e7-ad67-4f0d0287e1c7.png?alt=media&token=6bf9b411-362c-45aa-a5db-1953d9bf07e5","id":"e46960fb-feb3-44e7-ad67-4f0d0287e1c7","width":1920,"height":1920,"filename":"Adjust corner radius settings independently.png","type":"image/png","caption":"","border":false}]}
```

---

## TL;DR

* Situation: 제품 디자인에서 각기 다른 모서리 곡률을 표현해야 하는 고객들의 니즈가 지속적으로 증가하고 있었습니다.

* Task: Web, iOS, AOS 각 플랫폼에서 일관된 사용자 경험을 제공하면서도, 각 꼭짓점의 곡률을 개별적으로 제어할 수 있는 기능을 개발해야 했습니다.

* Action: W3C CSS border-radius 스펙을 기반으로 요구사항을 구체화하여 SVG Path를 활용하여 구현하였습니다.

* Result: Studio 5.4 버전을 통해 Individual Corner Radius 기능을 성공적으로 출시했으며, 제품의 고객인 디자이너들이 다채로운 디자인 작업을 할 수 있게 되었습니다.

* Reflection: 기하학적 원리와 SVG를 활용한 그래픽 처리 과정을 통해, 일반적인 레이아웃 구현을 넘어 전혀 다른 방식으로의 데이터 표현을 경험해볼 수 있어서 시야가 확장될 수 있었습니다.

## 구현배경

올해 초 Individual Corner Radius 즉 도형의 각 꼭짓점별로 테두리를 둥글게 설정할 수 있도록 하는 Feature를 개발했었다. 사용자에게 radius를 입력받았을 때 그에 맞추어 SVG를 그려주는 과정에 대한 내용을 정리해보려고 한다. ([Property Panel](https://www.protopie.io/learn/docs/ko/basic-features/layers)에서 사용자에게 값을 입력받을 수 있도록 구현하는 과정이나 Migration에 대한 내용은 Individual Corner Radius 보다는 프로젝트 관련 특수성이 강해서 생략하였다.)

해당 Feature를 구현하게 된 배경은 무엇일까? 기존에는 도형의 모든 꼭짓점에 동일한 Radius만 부여할 수 있었는데, Individual Corner Radius에 대한 [고객의 요청사항](https://protopie.canny.io/feature-requests/p/change-radius-of-individual-corners)이 있었다. 또한 디자인을 다루는 Tool이라면 당연히 가지고 있는 기능이기 때문이기도 했다. 자동차, 슬리퍼, 에어팟 프로 케이스 등 꼭짓점 별로 다른 형태를 가질 수 있는 경우는 현실에서도 다양하고 디지털 프로덕트에서도 마찬가지일 것이다.

Individual Corner Radius Feature는 Studio 5.4 버전을 통해 배포된 후 다음과 같이 고객에게 홍보되었다.

[What's New in ProtoPie? Individual Corner Radius | ProtoPie Blog](https://www.protopie.io/blog/individual-corner-radius)

Individual Corner Radius와 같이 사용자에게 보여지는 Feature가 추가될 경우 이 글에서 다룰 Studio 뿐만 아니라 Engine (Web, iOS, Android) 에서도 동시에 지원되어야 하므로 미리 스펙을 합의할 필요가 있다. 일반적으로 웹엔진을 기준으로 스펙을 정하고 모바일에서 지원가능한지 기술검토하는 방식으로 진행되기에 Individual Corner Radius의 경우 CSS 스펙을 기준으로 진행하기로 정했다.

Corner Radius에 대한 CSS에서의 정의, 그에 따라 SVG로 어떻게 구현할 수 있었는지 등을 다루기에 앞서서, CSS 스펙을 기준으로 구현하기로 했을 때 style을 CSS를 통해 부여할 수 있다면 적어도 웹은 매우 쉽게 구현할 수 있지 않겠냐는 생각을 해볼 수 있다. 그러나 SVG에 CSS를 통해 border-radius를 부여할 수는 없어서 직접 그려주어야 한다. [Styling SVG content using CSS](https://www.w3.org/TR/SVG/styling.html)

---

## 스펙결정

우선 Corner Radius란 무엇일까? radius는 반지름을 뜻하는데 꼭짓점과 어떤 상관이 있을까? MDN CSS [border-radius](https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius) 문서를 먼저 확인해보면, 아래와 같은 첫 문장을 볼 수 있다.

> The border-radius CSS property rounds the corners of an element's outer border edge.

border-radius에 따라 꼭짓점을 둥글게 만들 수 있다는 것은 알겠지만 위 문장만으로는 입력받은 px에 따라 얼마나 둥글게 만들어야 할지 알 수 없다. 그래서 W3C [문서](https://www.w3.org/TR/css-backgrounds-3/#corners)를 찾아보았다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Findividual-corner-radius%2F077bb22c-3402-4d4c-891a-92d839ff0f68.png?alt=media&token=84bc4161-1fc6-4cad-8202-918d473889c5","id":"077bb22c-3402-4d4c-891a-92d839ff0f68","width":837,"height":426,"filename":"individual-corner-radius-w3.png","type":"image/png","caption":"","border":false}]}
```

덕분에 border-radius에 대한 정의를 파악할 수 있었다. 각 꼭짓점별로 내접하는 원에 맞추어 수정해주었던 것이고, 내접하는 원의 반지름이 border-radius 값이었다.

CSS에는 [Corner Shaping](https://www.w3.org/TR/css-backgrounds-3/#corner-shaping), [Corner Clipping](https://www.w3.org/TR/css-backgrounds-3/#corner-clipping), [Color and Style Transitions](https://www.w3.org/TR/css-backgrounds-3/#corner-transitions) 와 같이 여러 가지 세부적인 스펙들이 존재한다. 또한 Figma의 경우 CSS 스펙과 별도로 [Corner smoothing](https://help.figma.com/hc/en-us/articles/360050986854-Adjust-corner-radius-and-smoothing#Corner_smoothing_for_squircles) 같은 스펙이 존재한다. 그러나 우리가 해당 버전을 위해 계획한 Feature의 범위를 넘어서기에 모두 생략하였다. 그럼에도 엣지 케이스에 대한 처리는 이루어져야 한다. 바로 도형의 크기에 비해 큰 수치를 사용자가 radius 값으로 입력하는 경우이다. 해당 내용은 [Overlapping Curves](https://www.w3.org/TR/css-backgrounds-3/#corner-overlap) 항목에서 확인할 수 있다.

> Corner curves must not overlap: When the sum of any two adjacent border radii exceeds the size of the border box, UAs must proportionally reduce the used values of all border radii until none of them overlap.
>
> The algorithm for reducing radii is as follows: Let f = min(Li/Si), where i ∈ {top, right, bottom, left}, Si is the sum of the two corresponding radii of the corners on side i, and Ltop = Lbottom = the width of the box, and Lleft = Lright = the height of the box. If f < 1, then all corner radii are reduced by multiplying them by f.

위 문장 이후에 예시도 제공해주었다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Findividual-corner-radius%2Fad782281-b887-483e-8212-08c6ff6ce3b0.png?alt=media&token=5b0558ee-a960-4dcd-8a95-360d7da7be03","id":"ad782281-b887-483e-8212-08c6ff6ce3b0","width":803,"height":186,"filename":"Overlapping Curves.png","type":"image/png","caption":"","border":false}]}
```

즉 사용자의 입력값이 허용할 수 있는 radius 즉 인접한 두 border-radius의 합이 도형의 너비 또는 높이 이하 를 초과하면, 비율에 맞게 낮춰서 적용하라는 의미이다. border-radius에 네 가지 숫자를 넘겨줄 경우 top-left | top-right | bottom-right | bottom-left 순으로 적용될텐데 border-top-right-radius가 이미 허용 가능한 최대치인 2em이다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Findividual-corner-radius%2Fa139c277-1931-4e1c-9f21-1988e8c01833.png?alt=media&token=68a35259-b09f-4160-8985-65340a3159e4","id":"a139c277-1931-4e1c-9f21-1988e8c01833","width":192,"height":64,"filename":"top-right-corner-radius.png","type":"image/png","caption":"border-top-right-radius: 2em;","border":false}]}
```

인접한 border-top-left-radius 또는 border-bottom-right-radius와의 합이 2em보다 적어야만 하므로 가장 큰 합이 2em보다 낮을 수 있도록 숫자를 축소시켜야 한다.

---

## 구현과정

여기까지의 스펙에 대한 이해를 바탕으로 결과 코드를 먼저 보고 싶으신 분들을 위해 CodePen을 공유드린다.

[CodePen](https://codepen.io/jeewhan/pen/gORKrRx)

앞에서 설명해준 축소 규칙을 코드로 표현하면 다음과 같다. ratio가 1이 아니라면 각각의 radius에 곱해주어야만 원하는 그림을 그릴 수 있다.

```javascript
const top = (topLeft + topRight) === 0 ? 1 : width / (topLeft + topRight);

const right = (topRight + bottomRight) === 0 ? 1 : height / (topRight + bottomRight);

const bottom = (bottomLeft + bottomRight) === 0 ? 1 : width / (bottomLeft + bottomRight);

const left = (topLeft + bottomLeft) === 0 ? 1 : height / (topLeft + bottomLeft);

const ratio = Math.min(1, top, right, bottom, left);
```

위 과정을 통해 얻게 된 수치들로 SVG를 통해 Rectangle을 그린다면 아래와 같은 코드가 필요할 것이다. SVG를 써본 적이 없다면 잘 이해되지 않을 수 있지만 글에서 이어지는 예시들을 통해 이해할 수 있을 것이다.

```javascript
const d = `
M ${0} ${topLeft}
a ${topLeft} ${topLeft} 0 0 1 ${topLeft} ${-topLeft}
h ${width - (topLeft + topRight)}
a ${topRight} ${topRight} 0 0 1 ${topRight} ${topRight}
v ${height - (topRight + bottomRight)}
a ${bottomRight} ${bottomRight} 0 0 1 ${-bottomRight} ${bottomRight}
H ${bottomLeft}
a ${bottomLeft} ${bottomLeft} 0 0 1 ${-bottomLeft} ${-bottomLeft}
Z
`;
```

네 꼭짓점의 radius가 무조건 동일하다면 SVG의 [<rect>](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/rect) 로 그리는 것이 더 편할 수도 있겠지만 individual corner radius를 가정하면 [<path>](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/path) 를 써야만 한다.

width 300 height 300 corner radius 25라고 가정하면 HTML 입장에서는 아래와 같은 형태일 것이다.

```markup
<svg height="300" width="300">
<path d="M 0 25
       a 25 25 0 0 1 25 -25
       h 250
       a 25 25 0 0 1 25 25
       v 250
       a 25 25 0 0 1 -25 25
       H 25
       a 25 25 0 0 1 -25 -25
       Z" />
</svg>
```

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Findividual-corner-radius%2F5140724a-53f1-4250-b3b9-1f0ac495cd53.png?alt=media&token=fdce24fd-73b8-4e01-9549-bcbb6c5d6a8a","id":"5140724a-53f1-4250-b3b9-1f0ac495cd53","width":637,"height":653,"filename":"example.png","type":"image/png","caption":"","border":false}]}
```

각 알파벳은 해당 명령이 실행되었을 때의 위치이며, 순서는 M부터 시계방향이며 Z는 M으로 이어주는 명령이다.

SVG path 또는 canvas 모두 한붓그리기 같은 느낌으로 선을 이어 그릴 수 있는데 대문자는 절대좌표 소문자는 상대좌표를 지정하는 것이다. 따라서 M은 시작점의 위치를 절대좌표로 지정한 것이며 M 0 tl 은 rectangle의 좌측 상단 모서리에서 border-radius-top-left만큼 아래로 이동한 위치를 뜻한다. 위 이미지에서 M의 위치를 확인할 수 있다.

SVG를 써본 적이 없다면 [좌표체계](https://www.w3.org/TR/SVG/coords.html#InitialCoordinateSystem)에 대해서 설명이 필요할 것 같다. SVG 좌표체계는 아래 이미지와 같은 방식을 따른다. (y축이 아래를 향한다.) 그래서 M 0 100일 때는 좌측 하단의 빨간 점에서 출발한다는 의미가 된다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Findividual-corner-radius%2Fac4e8884-15d2-4433-9544-a8ada0b78031.png?alt=media&token=6df18abf-9e05-4c3a-bf1b-e0c0f11f8dde","id":"ac4e8884-15d2-4433-9544-a8ada0b78031","width":300,"height":100,"filename":"InitialCoordinateSystem.png","type":"image/png","caption":"https://www.w3.org/TR/SVG/coords.html#InitialCoordinateSystem","border":false}]}
```

a는 SVG path로 호를 그리는 방식인데 \[MDN\](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/d#elliptical\_arc\_curve)에 아래와 같이 나와있다.

`a rx ry angle large-arc-flag sweep-flag dx dy`

`a ${topLeft} ${topLeft} 0 0 1 ${topLeft} ${-topLeft}`

rx, ry는 각각 x축과 y축에 대한 radius를 의미하는데 지금은 ellipse가 아닌 circle을 그릴 것이므로 rx와 ry는 같은 값 즉 top left 의 값을 받게 된다. 타원이 아니므로 angle도 0이면 충분하다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Findividual-corner-radius%2Fe2179d1e-1e61-4f34-865c-09029884ec97.png?alt=media&token=6d541491-1374-44e6-98e6-a85a4de3d8c1","id":"e2179d1e-1e61-4f34-865c-09029884ec97","width":501,"height":222,"filename":"elliptical_arc_curve.png","type":"image/png","caption":"https://developer.mozilla.org/ko/docs/Web/SVG/Attribute/d#elliptical_arc_curve","border":false}]}
```

large-arc-flag는 큰 호가 1 작은 호가 0을 뜻한다.

sweep-flag는 시작점에서 끝점으로 시계 방향으로 돌아가면 1, 반시계 방향이면 0이 된다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Findividual-corner-radius%2F733110d5-3a88-4bb4-b3b8-70d5e5214e99.png?alt=media&token=d399a4be-e5ae-4b40-bd1b-77777e395b41","id":"733110d5-3a88-4bb4-b3b8-70d5e5214e99","width":325,"height":325,"filename":"arcs.png","type":"image/png","caption":"https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths#arcs","border":false}]}
```

```markup
<svg width="325" height="325" xmlns="http://www.w3.org/2000/svg">
<path d="M 80 80
      A 45 45, 0, 0, 0, 125 125
      L 125 80 Z" fill="green"/>
<path d="M 230 80
      A 45 45, 0, 1, 0, 275 125
      L 275 80 Z" fill="red"/>
<path d="M 80 230
      A 45 45, 0, 0, 1, 125 275
      L 125 230 Z" fill="purple"/>
<path d="M 230 230
      A 45 45, 0, 1, 1, 275 275
      L 275 230 Z" fill="blue"/>
</svg>
```

지점과 지점 사이를 잇는 호는 위와 같이 네 종류가 있을 수 있고 지금은 위 이미지 중 보라색에 해당하는 조합을 그리고 있기 때문에 0과 1이 필요하다.

dx dy는 출발점으로부터 상대좌표로 이동하는 것을 뜻하기에 위 이미지의 보라색 케이스를 예를 들면 45, 45로부터 출발해서 125, 125로 이동하는 것이다. (원의 좌측에서 하단으로) 또한 이 점이 다음 명령의 출발점이 된다.

h와 v는 각각 x축과 y축에 대해 입력받은 만큼 이동하는 명령이다.

`h ${width - (topLeft + topRight)}` 좌측의 값이 dx일 때, x + dx, y로 이동

`v ${height - (topRight + bottomRight)}` 좌측의 값이 dy일 때  x, y + dy로 이동

반면 앞에서도 말했듯이 H는 절대좌표일 것이므로 `H ${bottomLeft}` 는 현재 점의 y를 유지한 상태로 x좌표가 bottomLeft인 곳으로 선이 그려진다는 의미이다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Findividual-corner-radius%2Ff7daccec-1533-4c67-a5e2-68b7185d30d1.png?alt=media&token=fe30ba71-81f4-4b09-ad88-26e3d96314fe","id":"f7daccec-1533-4c67-a5e2-68b7185d30d1","width":1049,"height":675,"filename":"lineto_path_commands.png","type":"image/png","caption":"https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/d#lineto_path_commands","border":false}]}
```

마지막으로 Z는 현재 위치와 출발점을 이어준다.

결과적으로 아래 이미지에 나오는 검은색 Rectangle을 그릴 수 있게 된다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Findividual-corner-radius%2F29f93da5-b3b4-4353-ab5d-81e491786912.png?alt=media&token=c0f32fd9-af43-4a23-a92f-d1bb9f457d20","id":"29f93da5-b3b4-4353-ab5d-81e491786912","width":600,"height":600,"filename":"black.png","type":"image/png","caption":"width 300, height 300, radius 25","border":false}]}
```

이제 앞에서 나왔던 코드를 다시 살펴보았을 때, 조금 더 이해하기 쉬워졌기를 바란다.

```markup
<svg height="300" width="300">
<path d="M 0 25
      a 25 25 0 0 1 25 -25
      h 250
      a 25 25 0 0 1 25 25
      v 250
      a 25 25 0 0 1 -25 25
      H 25
      a 25 25 0 0 1 -25 -25
      Z" />
</svg>
```

```javascript
const d = `
M ${0} ${topLeft}
a ${topLeft} ${topLeft} 0 0 1 ${topLeft} ${-topLeft}
h ${width - (topLeft + topRight)}
a ${topRight} ${topRight} 0 0 1 ${topRight} ${topRight}
v ${height - (topRight + bottomRight)}
a ${bottomRight} ${bottomRight} 0 0 1 ${-bottomRight} ${bottomRight}
H ${bottomLeft}
a ${bottmLeft} ${bottomLeft} 0 0 1 ${-bottomLeft} ${-bottomLeft}
Z
`;
```

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Findividual-corner-radius%2Fc4608e50-1a5f-4bec-9c17-dd86c70123a8.png?alt=media&token=3d0a545d-21da-4b21-afab-523d4576d7f0","id":"c4608e50-1a5f-4bec-9c17-dd86c70123a8","width":637,"height":653,"filename":"final.png","type":"image/png","caption":"","border":false}]}
```

각 알파벳은 해당 명령이 실행되었을 때의 위치이며, 순서는 M부터 시계방향이며 Z는 M으로 이어주는 명령이다.

Individual Corner Radius with CSS, SVG

Canvas 기반 게임 개발: 에디터 개발 경험 회고

저희가 만들고자 하는 디자인 시스템의 목표는 아래와 같습니다.

### 개별 컴포넌트가 프로덕트 어디 어디에서 쓰이고 있는지를 알려주고, 컴포넌트의 시각적 변화를 위한 엔지니어링 비용을 최소화하여, 디자이너가 시각적 변화에 대한 자유도를 가질 수 있도록 한다.

12월 28일 20시에 회의를 하면서 후술할 사용자 인터뷰 내용들을 공유한 뒤 위의 목표를 수립하고 아래와 같은 플로우를 그려보게 되었습니다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Fdesign-system-research%2Fe131fafc-79b3-4f6f-a66c-7ee643229412.png?alt=media&token=b333adb2-b947-4f2b-a5d6-51547435164a","id":"e131fafc-79b3-4f6f-a66c-7ee643229412","width":3961,"height":2088,"filename":"210085108-f5ca1636-396c-4a3b-b1a6-a554232e483c.png","type":"image/png","caption":"","border":false}]}
```

원래는 각 컴포넌트 별로 쓰이고 있는 프로덕트 위치를 알려주고, 컴포넌트가 쓰이고 있는 Figma 시안과의 연결을 해주는 것을 1순위로 고려했었지만 그것이 디자이너들의 Figma 사용패턴상 어렵다고 판단하게 되어, 구현 난이도 등을 고려했을 때 2순위로 생각했었지만 사용자 인터뷰 내용상 더 효과적이라고 파악하게 된, Figma의 변화를 바탕으로 컴포넌트를 수정해주는 것에 초점을 맞추게 되었습니다.

그러기 위해 OO님께선 Webpack Plugin을 통해 컴포넌트의 사용처 외에도 보여줄 수 있는 데이터들을 알아보고, Nx로 Monorepo를 구현하고, Storybook으로 컴포넌트를 보여주는 등의 접근을 진행해주시고, 그 사이에 저는 Button이라는 Figma에서의 컴포넌트에서 시각적 변화가 있을 때 그것이 컴포넌트 라이브러리의 Button의 스타일 변화로 이어질 수 있게 하는 MVP를 다음 세션 전까지 구현하기로 하고 그 과정을 중간중간 공유를 드리기로 하였습니다.

\---

인터뷰 대상자는 프로덕트 디자이너 세 분, 플랫폼 엔지니어 한 분이었습니다.

인터뷰를 하기 전에 가지고 있었던 궁금증들은 아래와 같습니다.

1\. 정말로 디자이너가 디자인시스템을 통해 알고 싶어하는 (기존에는 몰랐던) 정보는 무엇일까? Good to have가 아닌 없어서 정말로 불편한 것이 무엇인가? 디자이너가 생각하는 이상적 플로우는 무엇일까?

2\. Figma에선 Component Instance에서 Main Component로는 갈 수 있는데, Main Component에서 Component Instance로는 가지 못한다. 이것이 불편하지 않은가? (혹시 Instance Finder라는 Figma Plugin을 사용하고 있는가?) Main Component의 Instance를 모른다면 Main Component를 수정했을 때의 여파를 가늠할 수가 없다. 이 부분을 해결되면 이익이 큰가?

\---

1\. 디자이너 A(음성 인터뷰)

인터뷰를 하면서 디자이너별로 Figma 숙련도가 굉장히 많이 차이난다는 것을 느꼈습니다.

생산성 측면에서 당연히 사용되어야 한다고 느껴지는 Tokens나 Component 등의 Figma 기능을 쓰지 않고, 기능의 사용 여부에 대해 취향의 영역으로 이야기하는 것을 보고 솔직하게 충격을 정말 많이 받았습니다.

흔히들 말하는 '디자인 시스템은 규모가 어느 정도 있는 팀에서만 할 수 있고 해야 한다'는 인식에 대해선 어느 정도 동의할 수 있지만, Figma에서 이미 제공되는 기능들을 사용하지 않는 것에는 동의하기 어려웠습니다.

물론 디자이너의 디자인 툴 사용 능력은 문제 해결을 위해 사용하는 여러 층위에서 가장 바깥에 있고 부차적인 것일테지만, 그럼에도 아예 중요하지 않은 것은 아니라고 생각해보게 되었습니다. 게다가 디자이너에게 Figma는 엔지니어의 에디터보다는 언어에 가깝다고 느껴집니다. 그 이유는 엔지니어의 에디터는 결과물에 영향을 미치지 않지만 디자이너의 Figma는 협업을 위한 시안의 변화 대응력에 직접적으로 영향을 끼친다고 느껴서입니다. Figma 기능을 쓰지 않게 되면, 마치 엔지니어가 함수를 쓰지 않는 것과 비슷하다고 느껴졌습니다.

잘하는 엔지니어에겐 특정 언어에 대한 경험이 크게 중요하진 않겠지만, 그럼에도 어느 하나의 언어를 깊이있게 다뤄본 적이 있어야 그것을 바탕으로 스노우볼링을 굴려서 다른 언어도 잘 할 수 있을 것 같다고 생각합니다. 마찬가지로 디자이너도 툴에 대해 적어도 한 가지는 깊이있게 다루는 능력이 필요할 것 같습니다.

그리고 위에서 말한 것처럼 이미 도구를 잘 사용할 수 있는게 디자인 시스템 구축/유지/활용과도 연결될 것이라 생각되어, 디자인 시스템의 고객이자 생산자가 될 수 있는 디자이너의 전제과도 이어질 것 같습니다.

\---

2\. 디자이너 B(대면 인터뷰)

빠른 구현을 거듭해야 하는 상황에서 대략적으로 어떤 플로우로 작업하는지 들어볼 수 있었습니다. 디자인 팀 내에선 파운데이션과 컴포넌트가 갖춰져있어서 그것들을 가져와서 활용하고 필요시 디자인시스템팀 디자이너 분들에게 문의해서 구현하는 흐름이었습니다.

Figma에서 Main Component에서 Component Instance로는 갈 수 없다는 점에 대해서 모르고 계셨습니다. 그래서 그것을 파악해야 할 때는 어떻게 하는지 물어보니 엔지니어에게 문의한다는 답변을 받았습니다. 엔지니어 측에선 Figma와 달리 해당 컴포넌트가 어디서 쓰이고 있는지 바로 참조할 수 있다는 사실은 모르고 계셨지만, 엔지니어에게 물어보면 어디서 쓰이고 있는지를 파악할 수 있다는 점은 알고 있었고, 제 설명을 듣고 나서야 왜 엔지니어들이 금방 찾을 수 있는지를 이해하셨습니다.

또한 디자이너 A와 달리 디자인 시안에서 AS-IS는 남겨두지 않는 스타일이었습니다. 또한 자신이 담당하고 있는 페이지에 대한 최신화된 전체 시안을 따로 관리하지는 않았고 매 Feature마다 관련된 플로우에 대한 TO-BE를 작성하여 엔지니어에게 제공하는 형식이었습니다. (디자이너 D와의 인터뷰까지 해보면서, 디자이너마다 페이지 구분 등의 Figma 활용 방식이 많이 다르다는 점을 알 수 있었고, 그런 부분들을 통일해야 하는 니즈 등이 낮다는 점을 파악한 뒤 디자이너 행동의 변화를 통해서만 가능한 디자인 시스템적 요소는 최후순위로 미뤄야겠다는 판단을 내리게 되었습니다. 디자이너 D와의 인터뷰까지 읽어보시면 이해가 더 잘 되실 듯 합니다.)

자신의 일이 급한 경우가 너무나 많기 때문에 디자인 시스템에 대한 기대감은 특별히 없었지만 회사의 디자인 시스템 관련해서 어려움을 파악해보았을 때는 디자이너 측 디자인 시스템이 엔지니어 측과 연계되어있지 않아서 개별 목적조직의 엔지니어마다 따로 따로 대응해주고 있는 느낌을 말씀해주셨습니다. 그래서 자신이 시안을 넘겨준 뒤의 과정에서 뭔가 원활하고 빠르게 진행되고 있지는 않는 것으로 느끼고 계셨는데, 할 일이 너무 많아 미처 그 부분이 무엇인지까지는 자세히 파악하고 있지 못하고 있다고 말씀해주셨습니다.

\---

3\. 엔지니어 C(텍스트 기반 인터뷰)

현재 회사에서 디자인 시스템을 만드는 팀에 소속되어 일하고 계신 분입니다. 당연히 디자이너와는 바라보는 시각이 많이 달랐고, 지금의 디자인 시스템을 만들기 시작한지 오래 되지 않았기에 디자인 시스템의 목표와 관련해서 현재는 디자이너들에게 무엇이 필요할지보다는, 엔지니어링 측의 생산성에 집중하고 있다는 점을 알 수 있었습니다. 그래서 디자이너에 관한 인사이트보다는 사내 디자인 시스템에서 어떤 부분들을 참고하며 진행하고 있는지, 이후에 어떤 것들을 구현하고 싶어하시는지 등에 대해 들을 수 있었습니다.

\---

4\. 디자이너 D(화상 인터뷰)

다른 디자이너들과 나눈 이야기에 대해 간략히 설명하고 역시나 아래 질문에 대한 답을 찾고자 했습니다.

\- 디자이너에게 유의미한 디자인 시스템이 되려면 무엇이 필요한가?

\- 파운데이션과 컴포넌트의 사용처를 알려주면 되는가? 피그마에서 어떤 정보를 얻어서 보여주어야 의미있는가?

이 인터뷰이는 여러 가지로 디자이너의 작업 흐름에 대해 설명을 굉장히 잘 해주어, 디자이너에 대해 이전보다는 조금 더 깊이있게 이해할 수 있게 되었다고 느꼈습니다.

후술할 인터뷰 주제들과 별개로 재미있었던 포인트 중 하나는 맡고 있는 페이지 또는 프로덕트의 성격에 따라서 사용하는 컴포넌트도 굉장히 달라진다는 점이었습니다. 인터뷰이는 depth가 없는 탭을 맡고 있어서 checkbox나 radio처럼 분기를 제어하는 등의 컴포넌트는 쓸 일이 없고, 그렇기 때문에 일반적으로 디자인 시스템 컴포넌트로 되어있는 것을 활용하는 빈도가 다른 프로덕트 디자이너들에 비해 낮고 오히려 새로운 UI 요소를 만들어서 실험해보고 괜찮으면 그것이 디자인 시스템의 컴포넌트로도 반영되는 흐름으로 일하고 있다는 말을 들었습니다. 엔지니어도 맡고 있는 프로덕트과 파트마다 평소 하는 고민과 흐름이 많이 달라지듯이 디자이너는 또 다른 의미로 다양한 방식과 시점으로 일한다는 점이 어떻게 보면 당연하지만 제겐 매우 신선했습니다.

인터뷰 내용을 통해 우선 디자이너의 니즈도 플랫폼 디자이너와 프로덕트 디자이너에 따라 크게 다를 수 있다는 점을 알게 되었습니다.

중요한 전제는 프로덕트 디자이너는 최종을 구현하는 과정에서 굉장히 많은 화면을 만들게 되고 그것들을 일일이 정리하지 않으며 내가 임의로 지정한 최최최종에 대한 버전관리만 신경쓴다는 점이 굉장히 중요한 포인트였습니다. 상대적으로 엔지니어링은 하나의 현재본으로 귀결되는데 비해 Figma에선 과정작들과 최종작들이 혼재되어있고, 담당 프로덕트 디자이너는 그것을 구별할 수 있지만 Figma 자체에서는 그것들이 모두 동일한 각각의 화면을 존재할 것입니다. 일반적으로 프로덕트 디자이너들의 작업 흐름이 그렇다고 한다면, 디자인 시스템의 특정 목적을 달성하기 위해서 모두의 행동 변화를 통해서만 가능한 방식으로는 달성이 어려울 것이라 봤습니다.

Figma 에서 Component Instance 위치를 파악해서 Main Component를 수정했을 때 생길 프로덕트에서의 여파를 알고자 하는 니즈는 플랫폼 디자이너에겐 크게 있을 것으로 추측되지만, 그것을 Figma 관련 자동화로 해내기 어려울 것이라 판단하게 된 이유는 앞에서 말한 것처럼 Figma에선 너무 모든 것이 혼재되어있기 때문이었습니다. 물론 디자이너들도 draft, graveyard 등을 구분하면 좋기야 하겠지만 그렇게 잘 하지 않고, 그렇게 바꾸긴 어려울 것 같다고 인터뷰이와 인터뷰어 모두 공감대를 형성했습니다. (Figma에서 이걸 쉽게 하도록 유도하는 기능이 생긴다면 조금 달라질 수도 있을 것.)

실제로는 플랫폼 디자이너들이 특정 컴포넌트들이 쓰이고 있는 곳이 어딘지를 프로덕트 디자이너들에게 수소문하고, 그걸 또 프로덕트 디자이너들은 필요할 때는 엔지니어에게 도움을 청해서 파악하는 형태의 비효율이 반복되고 있고 그것이 생각보다 정리되기 쉬운 형태로 지금 Figma가 관리되고 있지 않다고 추측했습니다.

설령 플랫폼 디자이너가 디자인 시스템을 업데이트했을 때 프로덕트 디자이너의 시안에서 깨지더라도 이미 구현이 끝난 화면들이라면 그것들의 업데이트까진 프로덕트 디자이너가 굳이 신경쓰지 않는다고 했습니다. 또한 플랫폼 디자이너가 Team Library를 업데이트했지만 changelog 상에서 프로덕트 디자이너들에게 아직은 업데이트하지 말아달라고 하는 경우도 많고, 그것은 아직 플랫폼 디자이너들이 변경의 여파에 대해 충분히 파악하지 못한 시점인 것 같다는 말을 들었습니다.

엔지니어링에서도 구현을 위한 과정이 프로덕트 코드 내에도 살아있는 경우가 있긴 하지만, 사용자에겐 그것이 노출되지 않을 것이기도 하고, git을 활용해서 프로덕트 전체가 버전관리 대상이라고 여겨지는 것에 비해, 디자이너들은 자신이 임의로 생각하는 특정 페이지 등에 분산되어있는 특정 결과물들만을 버전관리의 대상이라고 여기는 경향이 있는 것 같아 Figma 전체 대상으로 하는 무엇의 자동화는 실효성이 많이 떨어질 것이라는 판단을 하게 되었습니다. (디자인 시스템 특정 요소에 대해선 이게 큰 장애물이 될 수도 있을 것 같습니다.)

또한 지금의 비효율 중 하나는 디자인 팀 내 디자인 시스템과 엔지니어링 측과 유기적으로 연결되어있지 않기 때문에 디자인시스템팀 플랫폼 디자이너가 목적조직 프로덕트 디자이너에게 디자인 시스템 컴포넌트의 변화를 알려주면 프로덕트 디자이너는 그것의 변화를 알고 업데이트한 뒤에 프로덕트 엔지니어에게 그걸 알려주어 업데이트를 할텐데, 이 과정을 목적조직마다 모두 하고 있을 것이라는 점이었습니다.

그래서 관련하여 혹시 컴포넌트의 기능이 아닌 모양만의 변화를 하는 경우도 많은지에 대해서 질문했더니 자신을 포함한 디자이너들에겐 그런 니즈가 많을 것 같다는 답변을 들었습니다. (기능의 변화는 어쩔 수 없이 엔지니어링적 비용도 발생할 수 밖에 없을 것이므로 모양의 변화 즉 엔지니어링 비용을 거의 들이지 않아도 될 것 같은 영역에 대한 필요성이 있는지 궁금했습니다.)

현재는 디자인 시스템이 충분한 성숙도를 갖추지 못해서 어떤 공통의 변화가 있을 때 그 변화가 반영되어야 하는 모든 화면을 담당하는 개별 엔지니어들을 모두 설득해서 그 변화를 반영시켜야 하고 그렇기 때문에 그게 잘 이루어지기도 힘들고, 그런 종류의 변화는 굉장히 우선순위가 밀릴 수 밖에 없다는 사실을 알기 때문에 디자이너들도 룩 앤 필에 대한 변화를 전혀 엄두를 내고 있지 못하다고 했습니다. 소소한 변화들이 모이면 화면의 톤 앤 매너를 바꿀 수 있지만 앞에서 말한 이유로 지금은 시각적 부채를 해소하기가 매우 힘들다고 했습니다. 지금도 플랫폼 디자이너들이 전체적인 무드에 대한 업데이트도 적극적으로 하고 싶어하기 때문에 프로덕트 디자이너들이 그런 요청을 하면 호의적일 것이므로, 구현 과정에서의 엔지니어링적 비용이 많이 드는 것만 아니라면 시각적 개선을 훨씬 더 적극적으로 많이 할 수 있을 것 같다고 말해주셨습니다.

그래서 제가 이해한 아래의 플로우를 말로 설명해주었고 대략적으로 원하는 바와 일치하는지 물어보았을 때 맞다는 회신을 받았습니다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Fdesign-system-research%2F5b959703-c5aa-4c44-b77a-2c5c925bb16e.png?alt=media&token=7f7cf339-17d4-49b0-9efb-b168193bef91","id":"5b959703-c5aa-4c44-b77a-2c5c925bb16e","width":2880,"height":932,"filename":"210080949-f2eadf48-a445-4a1a-8ee4-2d3a06d1e292.png","type":"image/png","caption":"","border":false}]}
```

지금 조직 내에서 토큰화해서 관리하는 컬러, 타이포그래피 그리고 자주 변경되는 마진 정도의 요소 등의 우선순위로 시각적 변화가 수월하게 반영되길 바라는 니즈를 확인하였습니다. 그래서 우선 시각적 요소의 업데이트를 쉽게 해주는 것을 목표로 MVP를 구현하고 다시 인터뷰를 갖기로 하고 인터뷰를 마쳤습니다.

인터뷰 때 인터뷰이에겐 언급하지 않았지만 최근에 페이스북에서 접했던 아래의 글을 떠올리면서 질문을 했었습니다. 시각적 요소 또한 비용에 대한 걱정없이 시도할 수 있게 하는게 프로덕트에 매우 유의미할 수 있다고 생각해보았습니다.

\> 끊임없이 자동화해야합니다.

자동화는 10분 걸리는 일을 1초로 바꿉니다. 이러한 노력의 댓가는 “시간을 10분 아낀다” 정도로 가볍지 않습니다. 업무를 자동화 함에 따라 얻는 댓가는 “10분 동안 더 깊고 생산적인 고민을 한다”입니다.

예를 들어, A팀은 API 요청과 응답의 JSON 인터페이스를 서버와 클라이언트 개발자가 일일히 손으로 맞춘다고 가정해봅시다. A팀에서 인터페이스를 바꾸는 일은 동료에게 리소스를 요구하는 것이기 때문에 소통 비용이 높습니다. 따라서 혹시 인터페이스에 문제가 있더라도 누구든 함부로 기존 인터페이스를 바꾸자는 이야기를 꺼내지 못합니다. (비가역적)

반대로, B팀은 스키마\*를 통해 서버, 클라이언트 코드를 자동 생성한다고 합시다. 이 팀은 인터페이스를 바꾸는 것은 CLI 호출 1초면 됩니다. B팀은 인터페이스 변경이 너무나도 쉽기 때문에, 소통 비용에 대한 걱정 없이 더 많은 시도를 할 수 있습니다. (“이렇게 바꿔보면 어떨까요?”라는 질문을 신규입사자도 꺼낼 수 있습니다) 결론적으로 인터페이스 자체에 대한 더 깊은 고민을 할 수 있게 됩니다. (가역적)

A팀과 B팀은 당장은 10분의 차이만 있습니다. 하지만 결과적으로 B팀은 더 지속가능하고 확장성있는 API 설계를 통해 10분보다 훨씬 더 많은 시간을 아꼈을 것입니다.

\*스키마: OpenAPI Specification(JSON Schema), GraphQL, Protobuf 등

디자인 시스템 목표 수립을 위해 진행한 사용자 인터뷰 요약

## 개요

개발자 글쓰기 커뮤니티(회원수 640여명)의 운영진으로서, 커뮤니티 내 챌린지형 채널들의 참여 현황을 효과적으로 관리하기 위한 해결 방안을 제안 및 구현하였습니다. 매일 50여명이 참여하는 두 개의 인증채널(다진마늘=할일 / 책읽어또=독서)에서 해당 채널의 운영진이 수작업으로 진행하던 출석체크를 자동화하고자 하였습니다.

## 프로젝트 목적

1. 불필요한 운영 리소스를 절감하여 본래의 목적인 커뮤니티 활성화에 집중할 수 있게 하고자 하였습니다.

2. 채널별로 상이한 인증 형식(업무목록/독서기록 등)을 처리하고 이후에도 다른 채널에 대해 구현할 수 있도록 추상 클래스 기반의 확장 가능한 구조를 설계하고자 했습니다.

## 기술 선택

* Slack SDK, Google SpreadSheet, TypeScript -> Python

출석체크 결과를 다른 분들에게 쉽게 공유할 수도 있어야 하며, 필요시 각종 함수들도 쉽게 활용할 수 있으므로 데이터의 적재는 Google SpreadSheet에 하기로 결정하였습니다. 더불어 기존에 만들어져있는 슬랙앱에서 통합관리하기 위해 Python으로 구현되어야 할 필요가 있었습니다.

다만 Python이 익숙하지 않아 고민되는 부분도 있었고, 아직 원하는 규칙대로 파싱하기 위해 구체적으로 어떤 부분들이 구현해야 하는지를 아직 모르는 시점이었습니다. 그때 아래의 문구가 떠올랐고, 그에 따라 문제를 두 단계로 나누어, TypeScript로 먼저 필요한 로직을 구현한 뒤에 Python으로 포팅하는 형태로 불확실성을 해결해보기로 결정했습니다.

**[더 많은 일을 하면서 더 빨리 하기](https://web.archive.org/web/20230330024213/http://agile.egloos.com/1762301) /** [Telescope Rule](https://wiki.c2.com/?TelescopeRule)

> **It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror.**

## 구현과정

맨 처음에 분석했던 것은 '두 채널에서 수집한 정보들이 어떻게 저장되어야 하는가'였습니다. 채널 운영자 분들에게 질문을 통해 파악할 수 있었고, 그것을 바탕으로 sheet header를 만들어서 피드백을 받아 데이터셋을 확정할 수 있었습니다. 그래서 timestamp 와 user가 공통되고 나머지는 다른 방식으로 가져와야 한다는 사실을 알 수 있었습니다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Fcheck-attendance%2F4c5dd04e-e599-4c78-8b94-313beb6f6b52.png?alt=media&token=851b7e2f-1c52-49b1-9b75-9c29b8dd1426","id":"4c5dd04e-e599-4c78-8b94-313beb6f6b52","width":1568,"height":1244,"filename":"2024-12-14-1529.png","type":"image/png","caption":"","border":false}]}
```

또한 두 채널 모두 결과적으로는 slack 과 sheet 에 대한 접근을 해야만 했기에, 공통적으로 두 가지에 대한 의존성을 가지고 있을 것이라는 점을 알 수 있었습니다.

그리고 전체적인 과정이 어떻게 되어야 하는가에 대해 고민해본 결과 아래와 같은 흐름이 되어야 한다는 1차적 결론을 내릴 수 있었습니다. (중간 중간에 이 기능에 더 자세히 알게 되면서, 그때마다 비즈니스 로직의 배치는 달라졌지만, 해야 하는 요구사항의 흐름은 아래 상태에서 유지되었습니다.)

1. 해당 채널 관련한 시트로부터 기존 메시지 데이터 가져오기

2. 슬랙으로부터 채널의 전체 메시지 가져오기

3. 둘 간의 중복 제거(채널 전체 메시지 - 시트 메시지)

4. 슬랙 메시지들을 시간 순으로 정렬

5. 메시지들을 채널별로 정해진 포맷에 맞게 정리

6. 해당 채널의 시트에 메시지들 기록

또한 시트에 없던 새로운 참여자가 생겼는지를 확인하기 위해, 메시지 작성자가 기존 시트에 기록되지 않았던 사람일 경우 사용자의 이름을 기록하는 로직을 덧붙였습니다.

그리고 슬랙에서 메시지를 가져올 때 이전에 가져오지 않았던 구간만 가져오면 되는데 전체 메시지를 가져오는 형태로 구현한 까닭은 도입을 하는 과정에서 엣지 케이스를 알게 되는 등의 상황이 있을 수 있을 수 있다라고 생각해서였고, 실제로도 몇 번의 조정을 하는 과정에서 전체를 가져오는게 유용했습니다. 여담이지만 예전 팀장님께서 우리가 구현해야 할 기능에 대해 제대로 이해하게 되는 시점은 구현이 완료된 시점이기 마련이라는 이야기를 하셨던 기억이 있는데, 참 맞는 말이라고 생각하고 🤣 그래서 처음 가지고 있는 이해가 부족할 수 있다는 가정 하에 전체 흐름을 빠르고 가볍게 완성한 뒤 점진적으로 fidelity를 높여가는게 좋은 전략인 것 같습니다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Fcheck-attendance%2F79823e5c-8d09-4e19-bede-03f24167de84.png?alt=media&token=faa6b5ee-e0c3-4333-ac3d-668fddb44768","id":"79823e5c-8d09-4e19-bede-03f24167de84","width":4156,"height":4442,"filename":"20241222-uml.png","type":"image/png","caption":"","border":false}]}
```

간략하게 UML로 표현해보자면 위와 같습니다. 이후에 다른 누군가(또는 미래의 제 자신)가 새로운 채널에 대해 케이스를 추가해야 할 때를 생각하면서 채널이 달라도 전체적인 구조와 흐름은 비슷하다는 느낌을 주고자 하는 의도로 구현해보았습니다. 현재는 요구사항을 충족하는 수준으로 완성하였지만, 이후에 다른 채널들이 추가되면 좀 더 개선과 조정이 이루어질 수 있을 것이라 기대하고 있습니다.

자세한 전체 코드가 궁금하신 분들께서는 [글팽이 Repository](https://github.com/nayoung0/geulpaeng/) 로 방문하시면 확인하실 수 있습니다.

끝으로 제작 과정에서 소중한 피드백들을 주셨던 @강나영님, @김은찬님, @박건희님, @정해원님, @변성윤님 께 진심으로 감사드립니다.

슬랙앱을 통한 채널별 출석체크 자동화

일관된 검색조건 관리를 위한 구조

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Fukdn2gPQzHuuUaOJrZZF%2Fccb36fc8-2fb9-4e4a-ad15-24e2791f1978.png?alt=media&token=8d063ef0-701c-4e18-8f84-b460b457e764","id":"ccb36fc8-2fb9-4e4a-ad15-24e2791f1978","width":493,"height":181,"filename":"polygon-and-star.png","type":"image/png","caption":"","border":false}]}
```

### 구현배경

이전에는 제공되는 Shape이 Rectangle, Oval만 있었다. 이 도형들만으로는 표현력이 부족할 때가 많아 관련하여 [고객의 요청사항](https://protopie.canny.io/feature-requests/p/more-built-in-vector-shapes)이 있었다. Figma의 경우 Rectangle, Ellipse 외에 Line, Arrow, Polygon, Star 를 제공한다. 스펙 검토를 해본 결과 Line, Arrow는 유의미한 기능을 제공하기 위해선 꼭짓점에 대한 조작도 할 수 있어야 하는데, 구현해야 하는 복잡도가 높아서 제외하고 6.0 버전에는 우선 Polygon, Star 라도 제공하기로 결정했다.

### 스펙이해

Polygon은 count를 조절하는 것을 통해 count에 대응하는 정다각형으로 변화할 수 있어야 한다. 아래 이미지의 좌측은 count가 3, 우측은 count가 8일 때이다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Fukdn2gPQzHuuUaOJrZZF%2Fa37dbdec-077e-4baf-8633-d125b7525413.png?alt=media&token=59a83a36-36de-4951-b354-b64f3b5e859f","id":"a37dbdec-077e-4baf-8633-d125b7525413","width":461,"height":200,"filename":"polygon-and-star-1.png","type":"image/png","caption":"","border":false}]}
```

Star는 count와 더불어 ratio의 조정을 통해 모양에도 변화를 줄 수 있어야 한다. 아래 이미지의 좌측은 ratio가 20%, 우측은 50%일 때이다. Star의 count는 ratio의 적용대상이 아닌 꼭짓점의 개수를 뜻한다. 만약 count가 3이고 ratio가 100%일 경우 Polygon의 count 6과 동일한 모양이 된다.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FwPS6LbiCusXjqSOOW68Z7en8jIr2%2Fukdn2gPQzHuuUaOJrZZF%2F9060337d-c124-4205-b17d-4d0ae0b046b5.png?alt=media&token=32917971-ca0e-4430-b188-f8ae15270fa2","id":"9060337d-c124-4205-b17d-4d0ae0b046b5","width":488,"height":181,"filename":"polygon-and-star-2.png","type":"image/png","caption":"","border":false}]}
```

### 구현과정

다각형을 그리기 위해서는 필요한 count, ratio에 맞추어 꼭짓점의 위치를 구할 수 있어야 한다. 이때 필요한 것이 삼각함수이다. 우선 결과코드를 공유하고 구현과정에 대해 설명하겠다. PolygonPathGenerator#getSVGPath 를 통해 만들어낸 결과물은 SVG의 <path>의 [d](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/d) (= denifition) 으로 쓰인다. SVG <path>에 대한 설명은 [이전 글](https://www.jeewhan.com/14558231-35da-4817-a3fc-aff192a0771d)에서 볼 수 있다.

```typescript
interface IPoint {
  x: number;
  y: number;
}

export const PolygonPathGenerator = new class {
    private _count = 3;
    private _ratio = 0.38;

    public getSVGPath(count: number, ratio: number): string {
        if (count < 3 || ratio < 0 || ratio > 1) {
            throw new Error();
        }

        this._count = count;
        this._ratio = ratio;

        return this._getSVGPath();
    }

    private _getSVGPath(): string {
        const vertices = this._getVertices();
        const start = vertices.shift()!;
        const routes = vertices.map(({x, y}) => `L ${x},${y}`).join('\n');

        return `M ${start.x},${start.y}\n${routes}\nZ`;
    }

    private _getVertices(): IPoint[] {
        const radian = 2 * Math.PI / this._count;
        const range = [...Array(this._count).keys()];

        return range.map(index => {
            const point = getPointOnCircle(radian * index);

            return (index % 2 === 0) ? point : {x: point.x * this._ratio, y: point.y * this._ratio};
        });
    }
};

const getPointOnCircle = (radian: number): IPoint => {
    return {x: Math.cos(radian - Math.PI / 2), y: Math.sin(radian - Math.PI / 2)};
};

// PolygonPathGenerator.getSVGPath(count, ratio)
// Star 일 경우 count를 2배로 해주어야 하고, Polygon 일 경우 ratio가 1이어야 한다.
```

getPointOnCircle부터 살펴보면 Math.cos와 Math.sin을 확인할 수 있다. 자바스크립트의 삼각함수는 모두 degree가 아니라 radian을 입력받도록 되어있다. degree를 변환하여 도(°) 라는 단위를 없애서 실수로 연산하기 위함일 것이다. degree와 radian 간의 변환에 대해 아래와 같은 유틸 함수를 만들어 사용할 수도 있다.

`const toRadian = degree => degree * Math.PI / 180;`

`const toDegree = radian => radian * 180 / Math.PI;`

```typescript
function getPointOnCircle(radian: number): IPoint {
    return {x: Math.cos(radian - Math.PI / 2), y: Math.sin(radian - Math.PI / 2)};
};
```

현재 그리고자 하는 것이 정다각형이기 때문에, radian 값을 알고 있다면 그에 해당하는 원 위의 x, y 좌표를 삼각함수를 통해 구할 수 있다. Math.PI / 2 즉 90도를 빼주는 까닭은 0도의 기준이 y = 0 즉 x축이기 때문에 그대로 그리면 우측으로 눕혀진 형태로 그려지기 때문에 원하는 모양을 그리기 위해선 기준이 y축일 될 수 있도록 되도록 바꿔주기 위한 것이다.

```typescript
private _getVertices(): IPoint[] {
    const radian = 2 * Math.PI / this._count;
    const range = [...Array(this._count).keys()];

    return range.map(index => {
        const point = getPointOnCircle(radian * index);

        return (index % 2 === 0) ? point : {x: point.x * this._ratio, y: point.y * this._ratio};
    });
}
```

위와 같은 방식으로 꼭짓점을 구하면 Polygon, Star 이라는 타입을 구분하지 않고 count와 ratio에 맞춰서 정다각형에 해당하는 x, y 좌표를 모두 구할 수 있다. 다만 Star 일 경우 count를 2배로 해주어야 하고, Polygon 일 경우 ratio가 1이어야 하는데 Polygon, Star 각각을 위한 method를 별도로 만들면서 제약 사항을 두는 것과 비교했을 때 일장일단이 있다고 생각된다.

```typescript
private _getSVGPath(): string {
    const vertices = this._getVertices();
    const start = vertices.shift()!;
    const routes = vertices.map(({x, y}) => `L ${x},${y}`).join('\n');

    return `M ${start.x},${start.y}\n${routes}\nZ`;
}
```

L은 쉽게 예상되듯이 절대좌표를 바탕으로 line을 그리기 위한 것이고, M은 시작점, Z는 마지막 점과 시작점을 이어주는 역할을 한다. shift 뒤에 !을 붙여주는 것을 통해 start가 undefined가 아니라는 것을 타입스크립트 컴파일러에게 알려줄 수 있다.