1 asked

0

안녕하세요! 좋은 질문 감사합니다.

답변을 드려보자면

1. 아마 회사마다 다른 체계들이 있을거라 정확히는 모르겠지만 검색하면 다앙한 기술블로그들에 소개되어 있습니다.

   1. https://tech.kakaoent.com/front-end/2022/220609-storybookwise-component-refactoring/

   2. https://techblog.woowahan.com/17081/

2. 저라면 프로젝트를 분리하고 나중에 필요하면 모노레포로 합칠 것 같습니다. 물론 공수가 크겠지만, 서비스가 커지지 않을 수도 있고, 중간에 사장될 수도 있고, 피벗할 수도 있고 등등 다양한 경우의 수가 있는데 미리 모노레포로 구현하는게 오히려 오버엔지니어링이 되거나 유지보수 측면에서 어려울 것 같아요.

   1. 다만 프로젝트의 규모가 예상이 되고 서비스의 성공이 어느정도(?) 보장된다면 바로 모노레포로 갈 수도 있을 것 같습니다. 뇌피셜이지만 아마도 메타가 쓰레드를 처음 출시할 때 인스타그램의 고객들이 넘어올거라고 판단해서 서비스 규모를 크게 잡으면서 모노레포의 형태를 취하지 않았을까 생각합니다.

   2. 조금 극단적인 예시긴 하지만, 위와같이 확실하게 서비스의 규모를 고려할 수 있는 상황이 아니라면 저는 작게 시작해서 확산하는 식으로 진행할 것 같아요. 엔지니어 측면에서도 모노레포를 init하는 것보다 모노레포로 변환해서 서비스를 운영하는 것이 더 깊은 소프트웨어 엔지니어링 경험이 될 것 같습니다.

0

안녕하세요, 인프런 AI 인턴입니다. dydgus0421님.

실무에서 Storybook을 어떻게 적용할지에 대한 질문이시군요. 다음과 같은 정보를 참고하시면 도움이 될 것입니다:

1. 규모가 큰 기업의 Storybook 관리 구조:
   큰 기업들은 보통 Storybook을 모노레포(Monorepo) 구조로 관리하는 경우가 많습니다. 이를 통해 여러 프로젝트에서 공통 컴포넌트를 관리하고 재사용성을 높일 수 있습니다. 모노레포를 사용하면 코드의 일관성과 재사용성을 유지하면서 여러 프로젝트의 라이브러리 또는 컴포넌트를 관리할 수 있습니다. 예시: Storybook의 모노레포 가이드에서는 여러 프로젝트에 걸쳐 효율적으로 Storybook을 관리하는 방법에 대해 설명하고 있습니다.

2. 소규모 팀의 Storybook 설정 전략:
   소규모 팀에서는 초기 비용을 절감하고자 “프로젝트 내부에 Storybook을 세팅 후 나중에 분리”하는 방법이 현실적일 수 있습니다. 이 접근법은 바로 사용 가능하기 때문에 초기 비용이 적게 듭니다. 그러나 프로젝트가 커지고, 공동으로 사용하는 컴포넌트가 많아지면 유지보수가 어려울 수 있습니다. 반면, 처음부터 모노레포로 설정하는 것은 초기 설정이 다소 복잡할 수 있지만, 장기적으로 볼 때 여러 프로젝트에서 효율적으로 컴포넌트를 공유하고 관리할 수 있는 장점이 있습니다.

각 팀의 규모와 필요에 따라 접근 방법이 달라질 수 있으며, 프로젝트의 목표 및 팀의 리소스를 고려하여 적합한 방법을 선택하는 것이 중요합니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.