<div id="readability-page-1" class="page"><div><p id="9049">여기 Type A라는 한 컴포넌트가 있다.</p><p id="a71a">이 컴포넌트 안에는 또 다른 컴포넌트인 Star가 있으며 Star의 상호작용을 처리하기 위해 Type A 컴포넌트는 외부로부터 <code>onStarClick</code> prop을 전달받는 상황이었다.</p><p id="7b39">어느 날, 누군가가 Type A 컴포넌트에서 Star 컴포넌트를 숨길 수 있는 기능이 있는지에 대한 질문을 했다. Star 컴포넌트가 숨겨질 것을 예상하진 못했으나, Type A의 내부 구조는 Radix UI와 같은 컴파운드 패턴의 블록 컴포넌트들을 조립하여 사용하는 방식이었기에 다음과 같이 질문에 답을 하였다:</p><p id="3d44">“현재로서는 Type A 컴포넌트에서 Star 컴포넌트를 숨길 수 있는 기능은 없으나 필요하다면 기존 Type A 컴포넌트를 참고하여 Star가 없는 재조립된 컴포넌트를 만들어 사용해 볼 수 있을 것 같습니다.”</p><p id="0e61">그리고 이에 추가로 몇 가지 질문을 덧붙였다.</p><ul><li id="3338">해당 기능을 얼마나 자주 사용하게 될지 알려주실 수 있나요?</li><li id="fb55">Star 컴포넌트를 제외한 다른 변경 사항은 없는지?</li><li id="b8dc">이번에 진행하는 개발 기간은 어느 정도인가요?</li></ul><h2 id="63e2">해당 기능을 얼마나 자주 사용하게 될지</h2><p id="98a3">최근에 디자인 시스템 공부를 하면서 읽었던 스토리북의 “<a href="https://storybook.js.org/tutorials/design-systems-for-developers/react/ko/architecture/" rel="noopener ugc nofollow" target="_blank">Design Systems for Developers</a>” 튜토리얼에서는 재사용되지 않는 일회성 컴포넌트를 생략하고, 코드를 깔끔하게 유지하기 위해 불필요한 코드를 최소화하는 것이 중요하다고 강조하고 있었다.</p><p id="d645">그렇기에 처음에는 해당 요구사항이 얼마나 필요한지 파악하고자 했던 것 같다.</p><p id="4418">만약 요구사항이 하나의 지면에서만 사용하고 Star를 숨기는 기능에 대한 중요성이 크게 없다면, 기존 Type A 컴포넌트를 그대로 사용하는 것이 더 나을 수 있을 것 같다고 생각했기 때문이다.</p><p id="8f24">물론 이 경우에는 당장 기능 검토가 이뤄지지 않더라도 문의를 백로그에서 추가해 계속해서 챙기는 것도 중요하다고 생각한다.</p><h2 id="165d">Star 컴포넌트를 제외한 다른 변경 사항은 없는지</h2><p id="aa4f">기존 Type A 컴포넌트에는 <code>onStarClick</code> 외에도 중요한 기능으로 <code>onClick</code>이라는 기능이 함께 제공되고 있었다.</p><p id="1c91">만약 다른 변경 사항이 없다면, <code>showStar</code>와 같은 prop을 추가하여 Star 컴포넌트의 노출 여부를 제어할 수 있을 것이고, 또는 <code>onStarClick</code> prop을 받을 때만 Star 컴포넌트를 노출하는 방향으로 기존 구조를 변경할 수도 있을 것이다.</p><p id="0b2d">그러나 만약 <code>onClick</code>처럼 중요한 기능이 함께 변경된다면, 이는 처음 질문에 답을 했던 새로운 Type B 컴포넌트를 만드는 것이 오히려 더 나은 선택이 될 수도 있다. Type A와 B 사이의 구분이 명확해지고, 코드를 보다 체계적으로 관리할 수 있을 것이기 때문이다.</p><p id="e026">체계적인 관리를 간단한 예로, 만약 코드를 분리하지 않았다면 타입스크립트에서 prop을 선언적으로 제어하기 위해 union 형태로 타입을 받을 것이고 (showStar가 <code>true</code>인 경우에만 <code>onStarClick</code> 타입이 활성화 된다든지), 나아가 Generic을 활용해 복잡한 타입 처리가 필요하게 될 수도 있다. 하지만 컴포넌트 코드를 분리하면 이러한 어려움이 조금은 줄어들게 된다.</p><p id="8b85">코드 분리의 단점으로는 코드양이 1:1 느낌으로 늘어나게 되다 보니 이러한 부분에서 오는 문제점들이 있을 순 있다. (가령 번들 사이즈 라던지)</p><h2 id="1d05">개발 기간은 어느 정도 인지</h2><p id="4882">만약 당장 내일까지 기능을 만들어야 한다고 하면 우리는 어떻게 요구사항을 해결할 수 있을까? 아마 가장 처음 얘기했던 Type A 코드를 복사 붙여 넣기 하여 Star 부분만 제거하고 사용하는 것으로 진행될 가능성이 높다고 생각한다.</p><p id="e8d8">하지만 약간의 검토 가능한 시간이 주어진다면 위에서 얘기했던 방법 외에도 더 나은 방법을 찾게 될 수도 있을 것이다.</p><h2 id="ce0d">언제나 정답에 가까운 유사한 해결책을 찾아야 한다</h2><p id="8385">결국 우리는 언제나 위와 같은 상황처럼 완벽한 정답을 찾을 순 없지만, 가능한 정답에 근접한 유사한 해결책을 찾기 위해 요구사항을 정확하게 파악하고 그것에 맞게 노력해야 한다. 물론 언제나 이런 과정은 쉽지 않지만, 결국 이런 경험들이 쌓여 성장했다는 표현을 쓸 수 있는 게 아닐까.</p></div></div>

Stories by Jusung Hwang on Medium

여기 Type A라는 한 컴포넌트가 있다.
이 컴포넌트 안에는 또 다른 컴포넌트인 Star가 있으며 Star의 상호작용을 처리하기 위해 Type A 컴포넌트는 외부로부터 onStarClick prop을 전달받는 상황이었다.
어느 날, 누군가가 Type A 컴포넌트에서 Star 컴포넌트를 숨길 수 있는 기능이 있는지에 대한 질문을 했다. Star 컴포넌트가 숨겨질 것을 예상하진 못했으나, Type A의 내부 구조는 Radix UI와 같은 컴파운드 패턴의 블록 컴포넌트들을 조립하여 사용하는 방식이었기에 다음과 같이 질문에 답을 하였다:
“현재로서는 Type A 컴포넌트에서 Star 컴포넌트를 숨길 수 있는 기능은 없으나 필요하다면 기존 Type A 컴포넌트를 참고하여 Star가 없는 재조립된 컴포넌트를 만들어 사용해 볼 수 있을 것 같습니다.”
그리고 이에 추가로 몇 가지 질문을 덧붙였다.
해당 기능을 얼마나 자주 사용하게 될지 알려주실 수 있나요?
Star 컴포넌트를 제외한 다른 변경 사항은 없는지?
이번에 진행하는 개발 기간은 어느 정도인가요?
해당 기능을 얼마나 자주 사용하게 될지
최근에 디자인 시스템 공부를 하면서 읽었던 스토리북의 “Design Systems for Developers” 튜토리얼에서는 재사용되지 않는 일회성 컴포넌트를 생략하고, 코드를 깔끔하게 유지하기 위해 불필요한 코드를 최소화하는 것이 중요하다고 강조하고 있었다.
그렇기에 처음에는 해당 요구사항이 얼마나 필요한지 파악하고자 했던 것 같다.
만약 요구사항이 하나의 지면에서만 사용하고 Star를 숨기는 기능에 대한 중요성이 크게 없다면, 기존 Type A 컴포넌트를 그대로 사용하는 것이 더 나을 수 있을 것 같다고 생각했기 때문이다.
물론 이 경우에는 당장 기능 검토가 이뤄지지 않더라도 문의를 백로그에서 추가해 계속해서 챙기는 것도 중요하다고 생각한다.
Star 컴포넌트를 제외한 다른 변경 사항은 없는지
기존 Type A 컴포넌트에는 onStarClick 외에도 중요한 기능으로 onClick이라는 기능이 함께 제공되고 있었다.
만약 다른 변경 사항이 없다면, showStar와 같은 prop을 추가하여 Star 컴포넌트의 노출 여부를 제어할 수 있을 것이고, 또는 onStarClick prop을 받을 때만 Star 컴포넌트를 노출하는 방향으로 기존 구조를 변경할 수도 있을 것이다.
그러나 만약 onClick처럼 중요한 기능이 함께 변경된다면, 이는 처음 질문에 답을 했던 새로운 Type B 컴포넌트를 만드는 것이 오히려 더 나은 선택이 될 수도 있다. Type A와 B 사이의 구분이 명확해지고, 코드를 보다 체계적으로 관리할 수 있을 것이기 때문이다.
체계적인 관리를 간단한 예로, 만약 코드를 분리하지 않았다면 타입스크립트에서 prop을 선언적으로 제어하기 위해 union 형태로 타입을 받을 것이고 (showStar가 true인 경우에만 onStarClick 타입이 활성화 된다든지), 나아가 Generic을 활용해 복잡한 타입 처리가 필요하게 될 수도 있다. 하지만 컴포넌트 코드를 분리하면 이러한 어려움이 조금은 줄어들게 된다.
코드 분리의 단점으로는 코드양이 1:1 느낌으로 늘어나게 되다 보니 이러한 부분에서 오는 문제점들이 있을 순 있다. (가령 번들 사이즈 라던지)
개발 기간은 어느 정도 인지
만약 당장 내일까지 기능을 만들어야 한다고 하면 우리는 어떻게 요구사항을 해결할 수 있을까? 아마 가장 처음 얘기했던 Type A 코드를 복사 붙여 넣기 하여 Star 부분만 제거하고 사용하는 것으로 진행될 가능성이 높다고 생각한다.
하지만 약간의 검토 가능한 시간이 주어진다면 위에서 얘기했던 방법 외에도 더 나은 방법을 찾게 될 수도 있을 것이다.
언제나 정답에 가까운 유사한 해결책을 찾아야 한다
결국 우리는 언제나 위와 같은 상황처럼 완벽한 정답을 찾을 순 없지만, 가능한 정답에 근접한 유사한 해결책을 찾기 위해 요구사항을 정확하게 파악하고 그것에 맞게 노력해야 한다. 물론 언제나 이런 과정은 쉽지 않지만, 결국 이런 경험들이 쌓여 성장했다는 표현을 쓸 수 있는 게 아닐까.

Type A 컴포넌트

댓글