[230429 - TIL] 컴포넌트 관리와 공유를 위한 방법과 개선방향, 회고

Dongwoo Kim·2023년 4월 29일
0

TIL / WIL

목록 보기
102/113

1. 개요

약 2주전부터 대시보드 페이즈를 만드는 작업을 진행했다. 이미 angular로 구성되어있는 프로젝트에 필요한 페이지를 추가로 만들면 되는 것이었다. 그전까지는 이런 시스템이 없어서 해당 화면에 필요한 요소를 그때그때 만들어서 사용하고 있었다. 때문에 같은 select박스나 타이틀이나 색상도 화면에 따라 조금씩 다른 경우가 많았다. 하지만 이번에는 새로운 디자이너님이 화면의 디자인을 시스템화 해서 여러 화면에서 동일하게 사용하길 원했다. 때문에 각각의 요소들을 컴포넌트화 하는 작업을 동시에 작업했으며 내가 만든 컴포넌트들을 동료 개발자들도 사용할 수 있도록 문서화하는 작업을 진행했다. 그리고 아예 다른 프로덕트 팀의 대시보드작업에도 내 컴포넌트를 그대로 가져다가 사용하기로했다. 이번 글에서는 그 과정과 어떻게 문서화했는지에 대해 이야기하고자 한다.


2. 컴포넌트, 어떻게 만들까?

컴포넌트를 만들 때 고려해야하는 것 중 하나가 '그래서 어디서 어디까지를 컴포넌트로 만들 것인가?'이다. 물론 디자이너님이 정해준 시스템 단위가 있고 그 단위로 컴포넌트를 만드는 것도 좋겠지만 코드로 구현하는데 있어서는 다른 관점으로도 생각해볼 필요가 있다생각했다.

우선 가장 먼저 생각한 것은 컴포넌트, 왜 사용해야하는가?

0) 컴포넌트, 무조건 사용하는게 좋을까?

그렇다면 무조건 모든 요소를 컴포넌트로 만드는 것이 좋을까? 컴포넌트를 사용하는데 있어서 장단점이 있다면 뭘까? 이는 생각보다 쉬웠다. 우리가 코드를 작성하는데 클래스와 함수를 사용하는 이유가 뭘까?

1) 컴포넌트, 왜 사용해야하는가?

우리가 클래스, 함수를 작성하는 이유는 구조가 복잡해지고 코드는 늘어나겠지만, 여러 곳에서 동일하게 사용할 수 있기 때문이다. 컴포넌트도 마찬가지라고 생각한다. 화면에 동일하게 보여주기 위해서, 관리하기 편하기 위해서 등등 여러이유가 있겠지만 개발자적으로 생각했을 때 가장 큰 이유는 재사용성 을 위해서가 아닐까 생각한다. 즉, 내가 앞으로 작업해야하는 코드를 다른 곳에서도 쓸까? 항상 생각하며 이걸 컴포넌트로 만들어야하는지, 아님 이 화면에서만 따로 구성할지 생각했다.

가령 해당 페이지에만 사용해야하는 특수한 요소는 굳이 컴포넌트로 만드는 리소스를 들일 필요가 없을 것이다.

: 다른 곳에서 사용될일 없던 커스텀요소. 이런 것들은 컴포넌트로 만들지 않았다.

2) 컴포넌트, 어디서 만들까?

위 고민을 통해 특정요소를 컴포넌트로 만들기로 맘을 먹었다면 그 다음 고민은 어디서 그 컴포넌트를 정의해야할지다. 모든 곳에서 사용할 수 있는 공통적인 컴포넌트가 있을 수도 있지만 반대로 해당 화면에서만 반복적으로 사용되는 요소만 있을수도 있다. 따라서 해당 컴포넌트의 사용범위를 생각해서 적절한 곳에 정의하고 관리할 수 있어야한다.

위 화면에서 왼쪽의 checkbox 버튼, raido 버튼은 다른 곳에서도 사용되는 요소, 즉 공통 컴포넌트로 분리했다. 왼쪽의 미리보기 버튼은 해당 페이지에서 여러번 사용되기 때문에 컴포넌트화를 했지만, 다른 페이지에서는 사용되지않기 때문에 서브 컴포넌트로 분리해서 다른 곳에서는 신경쓸 필요없도록 관리했다.


3. 컴포넌트, 어떻게 관리하고 공유할까?

사실 가장 중요한 것은 그래서 컴포넌트를 어떻게 관리하고 공유할 것인가 라고 생각한다. 내가 쓴 코드는 나만을 위한 것이 아니다. 옆의 동료들과 전혀모르는 개발자가 봐도 쉽게 알아보고 지속적으로 관리하며 사용할 수 있어야 의미가 있을 것이다. 따라서 내가 이렇게 만든 컴포넌트들을 앞으로 어떻게 관리할 것이며 어떻게 사용법을 알려줄지 고민해보았다.

1. 문서화, 디자인가이드 페이지 만들기

api를 만들면 api문서를 만들듯이 컴포넌트도 컴포넌트 문서를 만들면 되지않을까? 생각하며 문서를 만들어보았다.

그리고 본문에는 api문서의 request parameter와 같이 각 컴포넌트에 들어가는 파라미터들도 정리했다.

그런데 문제가 하나 있었다. api는 문서를 보고 그대로 요청해서 response를 데이터로 받으면 되는 것이었지만 컴포넌트는 그래서 어떻게 화면에 보여지는지 알려줘야할 필요가 있던 것이다. 그래서 따로 슈퍼관리자페이지에 개발자들만 볼 수 있는 디자인가이드 페이지를 만들었다.

2. 문제점

이렇게 관리를 하다보니 한참 문서화를 진행할 때는 몰랐는데 어느정도 마무리되는 시점에 문득 유지보수하기 너무 힘들겠다라는 생각이 들었다. 그리고 분명히 컴포넌트를 문서화해주는 도구가 있을 것이라는 생각이 들었고 당연히 쉽게 찾아볼 수 있었다. 내가 여지껏 수작업으로 컴포넌트 작성, 문서화, 디자인가이드페이지를 만들던 것을 한번에 할 수 있던 것이다!


4. 컴포넌트, 앞으로 어떻게 할까?

앞서 말했던 것처럼 지금과 같은 방법으로는 컴포넌트를 수정하거나 새로 만들 때마다 관련 문서와 디자인가이드를 만드는데 많은 리소스를 써야하기 때문에 비효율적이라고 생각이 든다.

따라서 angular와 우리 회사의 현재 환경을 고려했을 때 적절한 방법을 찾아야할 것이다. 그것이 문서화툴을 사용하는 것이라면 사용해아할 것이고, 그렇게까지 가진않더라도 기존의 방식을 간략화해서 내부적인 규칙이나 컨벤션을 정해서 진행할수도 있을 것이다. 중요한 것은 현재 우리에게 필요한 방법을 찾는 것! 이 아닐까.


5. 회고) 왜 이런 문제가 발생했는가?

사실 문서화 작업을 진행하기 전에 대표님에게 storybook에 대해서 알아보라고 조언을 들 었었다. 그리고 실제로 찾아보기까지 했었다. 하지만 그때는 단순히 문서화 작업(내가 만든 컴포넌트가 뭐다라고 설명하는 식으로)만 하면 될 것이라고 생각해서 '굳이 이런 새로운 툴을 적용해서 일을 키워야하나?' 라는 생각에 사용하지 않는 걸로 판단했다. 하지만 결론적으론 사용하는 것이 맞았고 지금와서는 사용해야할 필요성을 느끼고 있다. 왜 이런 문제가 발생한 것일까?

1) 처음이라서?

가장 넘어가기 쉬운 핑계다. 사실 front 개발을 제대로 배워봤다고할 것도 없고 angular에 대해서도 회사에 와서 온보딩시절해 사용해본 것이 전부였기 때문에 컴포넌트에 대한 작성 개념이나 관리 개념이 안잡혀있었던 것도 사실이다. 하지만 그렇다고 하더라고 문제를 사전에 방지하거나 중간에 알아챌 기회는 있었다. 그리고 언제나 제대로 배웠을 때만 잘할 것인가? 그건 아닌 것 같다. 앞으로도 새로운 기술과 도구들은 얼마든지 사용할 수 있어야 할 것이다.

2) 고정관념? 틀?

내가 생각하기에 가장 큰 이유는 이 부분인 것 같다. 문서화를 진행하고 디자인페이지를 만들면서 중간중간 '아 이거 너무 번거로운데, 굳이 이렇게까지 해야하나?' 같은 생각이 들 때마다 난 '그래도 해야한다' 라는 생각에 유혹을 뿌리치듯 우직하게 하려고만 했던 것 같다. 한번쯤 의심을 가지고 더 좋은 방법을 생각해볼수 있지 않았을까. 결과론적이긴 하지만 내가 잘 몰랐던 분야, 즉 새롭게 배우는 분야에 대해서는 항상 열린 생각을 가져야할 것 같다.

물론 '더 좋은 방법이 없을까?' 라는 생각이 지금 내가 하는 일이 맘에 들지 않아서 들 때도 있다. 하지만 그 전제조건은 내가 맘에 들지않는다는 판단을 할 수 있을 정도로 어느정도 그 분야에 경험이 있을 경우다. api를 만들고 데이터를 가져오는데 일단 그렇게 해야한다고 생각이든다면 '더 좋은 방법이 없을까?' 생각하면서도 그대로 진행할 수 있을 것이다. 내가 몰랐던 분야(인프라가 될 수 도 있을 것이고, DB가 될 수 도 있을 것이고, 심지어 백엔드부분에 대해서 모르는 경우가 대부분일 것이다. 이번 경우에는 front)에 대해서는 그런 생각을 판단할 수 있는 기준이 부족한 것이다.

항상 열린 마음으로 틀 깨기!

3) 열심히 했다는 보상심리

이 부분은 일을 더 열심히? 하게 만드는 동기부여가 되기도 하지만 이번 경우에는 독이 된 케이스다. 사실 일단 이 일을 잘했고 못했고를 따지기 전에, 내가 열심히 만든 컴포넌트들을 보기좋게 문서화해서 목록을 쫙 만들고 보니 '이야- 일 좀 했는데?' 생각이 들고 내심 뿌듯했던 것 같다. 지금와서는 정말 부끄러운 일이다..ㅋㅋ

4) 그럼 앞으로는 어떻게 할까

그럼 이제부터는 어떤 마음가짐으로 일을 해야할까?

  • 좀 더 겸손 해지자
    내가 알고있는 것이 전부가 아니다. 내 생각에 이건 이렇게 할 수 밖에 없다고 생각이 들어도 다시 한번 생각해보자.
  • 내가 생각한 것은 다른 사람도 생각해보았다!
    이 부분이 가장 크게 다시 깨달은 점인데, 내가 겪은 불편함과 생각들은 이미 다른 사람들이 다 겪고 생각했던 것들이다. 따라서 내가 불편한 것이 있으면 똑같이 불편함을 느꼈던 사람들이 어떻게 해결했는지에 대해 알아보면 된다! 구글에 '컴포넌트 문서화' 라고 검색만해도 정보가 쏟아지지않는가.
profile
kimphysicsman

0개의 댓글