스마트스코어

스마트스코어

개발팀 리뷰

위 내용은 스마트스코어 전 • 현 재직자의 응답 결과입니다.

기술 스택

기술 스택 정보가 없어요.

재직자가 작성한 글

profile picture

김태언

프론트엔드 개발자

디자인 시스템 과 중요성

주니어 프론트엔드 개발자로써 요새 디자인 시스템에 대한 고찰과 중요성을 느끼고 어떻게 적용해 가는지 공유하면 좋겠다고 생각했습니다 STEP 1. 디자인 시스템이란 무엇인가? 2. 왜 디자인 시스템을 사용하게 되었나? TL;DR 디자인 시스템은 일관성과 통일된 디자인 컴포넌트 집합체이다. 디자인 시스템은 오직 디자이너를 위한게 아니다. 조직 전체 구성원을 대상으로 '제품을 만드는 방법'을 다룬다. 개발자로써 리액트 컴포넌트 atom design으로 최대한 재사용성을 위해 확고한 디자인 시스템 및 운영이 필요하다. 나는 사실 디자인 시스템이 디자이너를 위한 하나의 에셋처럼 모아놓고 쓰는거라고 생각했고 주니어 개발자로써는 '아 저런식의 일관된 브랜딩된 디자인을 쓰고 무슨 색과 폰트를 쓰는구나'로 그저 참고용으로 생각했다. 실질적으로 와닿지도 않았고 여러 디자이너와의 협업을 했다고 하더라도 짧은 기간내에 이뤄졌기때문에 디자인 시스템을 확립하거나 활용하지않고 그저 Figma에 올라온 디자인된 이미지, 폰트 등을 저장하거나 속성만 보고 대입해서 사용하였다. 왜 디자인 시스템을 사용하게 되었나? 그런데 실무에서 한 프로젝트를 계속해서 작업하면서 분량이 커지고 수정될 부분도 많아짐에 따라, 랜덤하게 그때그때의 font, color, background 등을 typing 하면서 작업하는게 너무 시간적으로 비효율적이라고도 느꼈고, 이렇게 작업하기위해선 피그마를 쳐다보고 확인하고 코드를 짜고 또 확인하는 피곤한 절차가 이뤄질뿐만 아니라 수정사항이 생기거나 다른 팀원이 코드를 본다면 정신없이 긴 코드안의 style을 본다면 이해도 안가고 더많은 에너지와 시간을 투자하게 된다고 판단하게 되었다. 따라서 현재 tailwindCSS 와 styled-components를 사용하기때문에 미리 tailwind.config.js 와 theme.js에 해당 디자인 시스템을 셋팅해놨다. 그런데 스케쥴에 대한 업무처리도 물론 많았기때문에 실질적으로 이를 활용하거나 사용한적은 color를 제외하곤 사용하지 않고있었다. 이때까지만해도 필요성도 못느꼈기 때문이다. 이미 내가 프로젝트 개발을 들어가기전에 디자이너분께서 디자인 시스템과 가이드라인을 만들어놓긴 했지만 실질적으로 사용하는 사람이나 그거에 대한 피드백을 주는 프로세싱이 없었던 히스토리를 느꼈고, 그로인해서 디자이너분께서도 새로운 페이지나 작업이 생길때 디자인 시스템에 사용되는 typography를 쓰긴했지만 Figma에서 작업시 line-height 값을 Auto로 줘야 2줄이상의 글들이 있을때 자연스러워 지기때문에 크게 고려하지않고 작업했던거 같다. 이렇게 되면 기존의 typography로 정의된 font들을 사용하지 못했고 정의된 문장, 안내문을 Figma를 통해서 볼때 어떤 typography를 쓰는지 주석으로 보여지지도 않고 그때그때 계속해서 다른 font의 type이 생기게 되고 나는 계속해서 이게 디자인 시스템에 있는 건가 확인하는 절차, 아니라면 일일이 타입해서 sync를 마추는 코딩 절차를 밟게 되는데 매우 피곤한 작업이였고 코드가 통일되거나 일정하지않고 지저분하게 되는게 느껴졌다. 이건 아니다 싶었고 리액트의 장점이 어쨌든 ui 컴포넌트를 최대한 재활용하여 쓰도록 고안되고 이에 특화된 styled-components를 쓰면서도 단일 최소 컴포넌트들을 만들어놓지 않으면 안될거 같다고 생각했고 이 기회에 정의된 디자인 시스템에 대해서 확고하게 정하고 random하게 바뀌는 디자인을 만들지 않도록 해야겠다고 생각해서 바로 디자이너분에게 이야기를 했던거 같다. 당연히 디자이너께서 어떠한 이유가 있었고 왜 그랬는지 설명을 했고 만약 디자인 시스템을 제대로 구축하고 그걸 토대로 Figma에 정의하여 넘겨준다면 프로그래밍상에선 어떻게 활용되는지 궁금해 하셨다. 실질적으로 개발자가 어떻게 쓰는지 느낀게 없으니 궁금했던거 같다. 나는 예시로 빠르게 어떤식으로 구축하여 사용할수 있고 그에 따른 장점을 설명드렸다. 또한 일관되지 않게 된다면 어쨌든 디자인으로써도 통일되지 않기때문에 개발자가 sync를 100%마추지 못한다면 디자이너로써도 결과물에 대한 만족도도 떨어지게 되기 때문에 필수적으로 필요한 절차였다. 약 30분정도 미팅을 가진결과 한줄, 또는 단어를 위한 typography 부분과 두줄 이상 문장이 필요한 부분에 사용할 typography에 대해서 나눠 구축하기로 결정이 되었다. 이름은 short, long이라는 컨벤션을 갖는다. 그래서 잘 사용하고 있는가? 협의된게 지난주였고 디자인 시스템 작업이 완전히 끝난게 아니라 얼마나 활용되었는지는 다음주부터 느낄거 같은데, 이렇게 미팅을 맞추고 어떻게 활용할지 상상을 해보니 너무 두근거릴 정도였고, 집에서 미리 텍스트에 대한 재사용성 atom 컴포넌트를 만들었다. 왜냐하면 이건 개발자로써 생산 속도, 코드의 간결성도 매우 좋아지고 재사용에 대한 응용도 폭 넓어지는 이유도 있었지만, 내가 더 두근거렸던건 이러한 과정을 디자이너분과 확립했고 어떻게 스타트를 하는지 서로 협업을 하여 맞추고 기반을 만들었다는게 지금 한번더 성장했다 라고 느꼈기 때문의 이유가 더 컸다. 또, 더 성장하고 있구나 라고 느끼고 두근되었던 이유는 안그래도 요새는 협업, 재사용성, 최적화에 제대로 꽂혔고 왜 중요한지를 느끼는 시기였다. 그래서 로직 재사용성, 간결성, 활용을 위해 Custom Hook도 최대한 사용할려고 공부 중이 였고 memoization 관련된 Hooks를 통한 최적화 활용도 고심하고 있다. 그런데 이젠 디자인적인 부분까지 최적화 시키고 있다라는게 3방면의 능력치 state를 ++ 되는게 느껴졌기 때문도 있다. 2주정도 후에 프론트엔드 인턴 한분도 오기때문에 프로젝트를 설명하거나 코드리뷰도 조금 해줘야할거 생각하면 너무 뿌듯한 작업이고 자랑스럽게 느껴지기 때문이다!! 다음 STEP은? 당연히 프로젝트에 제대로 응용해서 활용해서 적용할려는 단계를 가질 것이다. 디자인, 로직, 최적화를 모두 적용하는 단계일 것이고, 아는사람은 당연히 알고 있겠지만 아토믹 디자인 패턴, Atomic Design Pattern 단계를 제대로 구축해 나갈거 같다. 지금은 Atom 단계 이고 또 쓰다보면 위의 이유처럼 atom 컴포넌트를 모아서 재사용하고나 할것이고 이렇게 Molecule, Orgnism, Template, Page 로 쭉쭉 올라가지 않을까 싶다.

profile picture

김태언

프론트엔드 개발자

리액트 성능최적화

리액트의 성능 최적화에 사용되는 react.memo, useCallback, useMemo에 대하여 공유하고자 합니다. 어떤 상황에 써야하는지 왜 쓰게 되었는지 등을 자세히 설명하고 왜 모든 컴포넌트에 적용하지 않은지에 대한 이유도 설명하였습니다