완성된 리액트 서비스에 다중탭 기능 넣으라는데, 설계를 잘못한 걸까요?

Question

안녕하세요. 실무 중 겪은 상황이 궁금해서 글 남깁니다.회사에서 서비스 중인 데이터 전처리 솔루션이 있는데,프론트는 리액트 기반 SPA방식으로 개발되어 있습니다.구조는 프로젝트 리스트 -> 프로젝트 상세 페이지로 진입해서해당 프로젝트 내에서 전처리를 진행하는 방식이에요.즉, 프로젝트 페이지 하나만 활성화되는 “단일 세션 구조”입니다.그런데 해당 솔루션의 기획 및 설계가 완료된 이후 들어오신 이사님께서최근에 솔루션 개발이 전부 완료되고 서비스중인 상태에서 저에게“프로젝트 페이지를 크롬 탭처럼 여러 개 띄워서 동시에 작업할 수 있게 해달라”라고 하시더군요.문제는, 기존 프로젝트 페이지가 이미 완성된 상태이고스토어를 여러 곳에서 공유하고, 전역 상태에 강하게 의존하며,페이지 규모도 크고 복잡합니다.우선 테스트로 해당 프로젝트 페이지를 간단하게 다중탭으로 띄워봤는데,앞서 말씀드린 것처럼 탭을 두개 이상 띄우고, 한 프로젝트에서 어떤 작업을 한 뒤다른 프로젝트 탭으로 들어가면 스토어 공유로 인해 다른 프로젝트 탭에도 똑같이 적용되고 있는 상황입니다.즉, 각 프로젝트 세션을 분리할 수 있는 구조가 전혀 아닙니다.그래서 현실적으로는 iframe을 쓰는 것 말고는 방법이 거의 없다고 판단했는데,이사님은“iframe은 안 된다. 애초부터 페이지별로 모듈화해서 개발했으면 이런 문제가 없었을 거다. 이건 설계를 잘못한 거다.”라고 하셨습니다.제가 보기엔 이건 요구사항이 나중에 변경된 경우라고 생각하거든요.초기 설계 단계에서 ‘다중탭’이란 기획 자체가 없었는데,지금 와서 그걸 모듈화 안 한 게 잘못이라고 하시니까 조금 답답합니다.이런 경우, 진짜 설계를 잘못했다고 볼 수 있을까요?다중탭 기능은 애초부터 기획/설계 단계에서 고려해야 하는 구조 아닌가요?현실적으로 iframe 말고 다른 접근이 있을까요?

몰랑토끼 · Answer

프로젝트 페이지를 크롬 탭처럼 여러 개 띄워서 동시에 작업할 수 있게 해달라이건 설계의 문제가 아닌데요 직급제회사들은 뭣도 모르고 말하는 경우가 많긴하죠

yeori · Answer

어, 그거 막판에 요구사항 던지고나서 합리화하려고 개발자한테 책임 뒤집어씌우는 전형적인 사례입니다.예를 들어서 모달창을 띄워서 특정 화면을 띄워달라고 요구해놓고, 나중에 가서는 모달창을 여러개 열어서 화면1, 화면2를 보여줄 수 있어야 한다고 추가하는 식이죠.그러다가 드래그해서 자유롭게 배치할 수 있어야한다고 한 번 더 던져봄.나중에는 접는 기능을 넣어야 한다고 계속 던짐.당연히 그랬어야 하는 게 어딨나요?막판에 요구사항 틀어버리면서 그 책임을 남한테 던져야 하니까 논리를 급조하는 겁니다.그 탭이란 게 등장하면 당연히 탭을 관리하는 엔티티가 필요하고, 아마 나중에 가서는 전체 탭의 상태를 저장하고 다시 로드하는 기능도 요구할테고 탭의 위치를 바꾸는 기능도 필요할 것이며, 닫은 탭을 다시 열어야 한다는 기능도 또 나옴. 실수로 닫았을 수도 있다, 뭐 이거죠.이 뿐만이 아님. 탭을 왼쪽에 배치, 오른쪽에 배치, 이것도 당연한 게 됨.그렇게 당연한거면 feature에 분명히 명시했어야했는데, 아마 나중에 가서야 어디선가 멀티탭 얘기가 나왔을 거고 부랴부랴 뛰어와서 탭 넣으라고 했을 거임.나중에 탭이 아니라 vscode 편집화면처럼 좌우 상하로 여러 개 배치하는 거 요구할지도 모르죠.화면단이야 원래 자잘한 요구사항이 넘쳐나기 마련인데 그런 걸 당연히 모듈화했어야 한다는 논리면 일이 끝이 없음.회사라는 곳을 다니면 그런 꼴 많이 겪습니다.

catcode · Answer

그냥 맘 편하게 이런 경험도 해보는구나 생각하고개발기간 늘어나는걸 알려주고 다음 버전에 추가한다고 하시죠 이런걸 고려 안했냐고 꼬투리 잡으면 기획 담당자에게 패스!

[object Object] · Answer

상태관리를 어떤걸로 하시는지는 모르겟지만 component key처럼 상태관리 객체 인자에 탭마다 구분자?를 넣어서 관리해보시는건 어떨까요. 이것도 공수가 좀 들긴하겠지만... 화이팅입니다 ㅠㅠ

캐티 · Answer

레이아웃을 건드리면 되겠쩌. 물론 경험이 없었다 하여서 망가뜨리는 여지가 있어서 다른데 거를 잘 알아보거나 계획을 세워보아요. 아이프레임으로 하는 거는 오히려 문서와 문서 사이에 인터페이스를 구현하여야 하여서 일이 많아지는데 이럼 망하겠쩌. 이사 분이 자신이 있느나 보아요.설계는 틀어지는 여지가 있는 거이고 잘못 되었다고 판단하는 거는 고치는데 돈이 지나치게 많이 들어가는 상황이면 잘못되었다고 하는 거여용. 예컨데 다 고치는데 1년이 걸릴거다 이럼 .. 설령 6개월이라 하여도 터지는 여지가 있었쩌. 사실 이렇다 하더라도 돈이 많았음 댔어요.

성실이 · Answer

이사님이 표현을 잘 못한 것 같네요. 설계 변경이 필요하다 정도로 말씀하셨으면 좋았을 텐데요.이건 사람, 팀, 회사의 성향에 따라 달라집니다. 만일 비머님께서 요건 변경에 저항력이 있는 구조를 고려하는 것을 선호하거나 회사에서 그간 발생했던 사례로 부터 패턴을 만들어놓았다면 그랬어야 겠죠. 전역 상태 의존성은 흔하게 격는 문제입니다. 저도 비슷한 경험을 한 이후에 팀내에 공통 아키텍쳐를 도입하고, 전역상태와 같은 외부 의존성은 Page라는 컴포넌트에서만 사용하도록 가이드를 마련했었습니다. 하여튼 이건 답이 없는 문제입니다.리팩토링 + AI 마이그레이션. 1년 정도 전에 vi copilot 플러그인을 뜯어 보고 매크로를 작성해서 30만 라인을 하루만에 변경한 적이 있습니다. 무엇을 고쳐야할지 빠짐없이 정확히 알고 있다면 단시간내에 가능합니다. 요즘에는 더 좋은 툴이 있으니 더 쉽게 가능할 것 같습니다.

Ganymede Ganymedian · Answer

zustandStore 는 Array 비슷한 스토어 관리도 가능합니다. 간단하게 { chatRooms, setChatRooms } 데이터 만으로 구성해 보겠습니다.탭의 상태가 영구적으로 보존될 수 있도록, 각 상태를 persist 로도 저장해줍니다.// chatRoomsStore.ts import { create } from 'zustand' import { persist, createJSONStorage } from 'zustand/middleware' export interface ChatRoom { id: string name: string } export interface ChatRoomsState { chatRooms: ChatRoom[] setChatRooms: (rooms: ChatRoom[]) => void addChatRoom: (room: ChatRoom) => void } // export const createChatRoomsStore = (tabId: string) => create( persist( (set) => ({ chatRooms: [], setChatRooms: (rooms) => set({ chatRooms: rooms }), addChatRoom: (room) => set((state) => ({ chatRooms: [...state.chatRooms, room] })), }), { name: `tabIndex-${tabId}`, storage: createJSONStorage(() => localStorage), } ) ) createStore 의 코드는 일반적인 zustand 훅과 다를 게 없습니다만, 마법은 프로바이더에서 일어납니다.상위 레이아웃에 프로바이더를 하나 추가하고, 예를 들어, TabIndexProvider...이 프로바이더에서, tabIndex 를 관리합니다. tabIndex 가 변경될 때마다, 새로운 zustandStore 인스턴스가 생성되거나, Ref 에 캐시된 인스턴스 중 하나가 리턴됩니다. Ref 보다는 localStorage 등 스토리지를 사용하는 쪽이 안정적일 것입니다.// TabIndexProvider.tsx 'use client' import React, { createContext, useContext, useMemo, useState } from 'react' import { createChatRoomsStore, ChatRoomsState } from './chatRoomsStore' import { useStore } from 'zustand' interface TabIndexProviderContextValue { tabIndex: number setTabIndex: (index: number) => void store: ReturnType } const TabIndexProviderContext = createContext(null) export const TabIndexProvider: React.FC<{ children: React.ReactNode }> = ({ children }) => { const [tabIndex, setTabIndex] = useState(0) // 각 탭의 store를 메모이제이션된 Map으로 관리 const storesRef = useRef>>(new Map()) // Function to get current store instance or create new one const getCurrentStore = () => { if (!storesRef.current.has(tabIndex)) { storesRef.current.set(tabIndex, createChatRoomsStore(`tab-${tabIndex}`)) } return storesRef.current.get(tabIndex)! } const store = getCurrentStore() // Provide : tabIndex, setTabIndex, store return ( {children} ) } export const useStoreSelector = () => { const ctx = useContext(TabIndexProviderContext) if (!ctx) throw new Error('useStoreSelector must be used within TabIndexProviderContext') return ctx } // Helper hook // zustand useStore 훅은, 이 헬퍼 펑션만으로도 완벽한 선택적 구독이 가능하게 해줍니다. export const useChatRooms = (selector: (state: ChatRoomsState) => T) => { const { store } = useStoreSelector() return useStore(store, selector) } 이제 tab 이 준비된 것 같습니다.// ChatRoomList.tsx 'use client' import React from 'react' import { useChatRooms, useStoreSelector } from './TabIndexProviderContext' export default function ChatRoomList() { const { tabIndex, setTabIndex } = useStoreSelector() // zustandStore data for selected tabIndex const chatRooms = useChatRooms((s) => s.chatRooms) const setChatRooms = useChatRooms((s) => s.setChatRooms) const handleAddRoom = () => { const newRoom: ChatRoom = { id: `${tabIndex}-${Date.now()}`, name: `Room ${chatRooms.length + 1} (Tab ${tabIndex})` } addChatRoom(newRoom) } return (

Current Tab: {tabIndex}

Chat Rooms ({chatRooms.length})

) } // ===== App.tsx ===== export default function App() { return ( ) } 이제, 각 탭 UI 를 구현하고, 탭 하위 컴포넌트에서 기존 UI 를 그려넣어주시되, 기존 Zustand Store 대신에 각 탭 전용 Zustand Store 를 사용하면 될 것 같습니다.chatRooms 에는 tabIndex 에 해당하는 데이터가, setChatRooms 에는 tabIndex 에 해당하는 setState 펑션이 할당됩니다. 각 탭에 해당하는 UI 를, 이를 바탕으로 그려넣어주면 되겠습니다.세줄요약:Zustand 는 Array 와 같은 효과의 Store 관리가 가능하다.루트레이아웃에 TabIndexProvider 를 추가해서 setTabIndex 가 가능하도록 하자. tabIndex 가 변경될 때마다 새로운 zustandStore 인스턴스가 추가 또는 변경된다.개별 탭 또는 탭 셀렉터 컴포넌트에서는, 헬퍼 훅에 의해, tabIndex 에 해당하는 zustandStore 가 바뀐다. 즉, tabIndex 에 따라 store 가 교체되는 구조가 된다.*. 기존 Zustand Store 또는 zustand store 를 제공하는 컴포넌트를 위 구조로 바꿔주는 게 가장 효율적일 것 같습니다.시간이 충분했으면 stackblitz 에 워킹데모를 만들어볼 수도 있었을 것 같습니다만, 시간이 그렇게는 안되겠습니다.이사님 덕분에 저도 좋은 시간 가졌습니다.**. 의견으로만 받아들이시고, A/S 는 못해드립니다.

HJOW · Answer

"프로젝트 세션을 분리할 수 있는 구조가 전혀 아닙니다."사실 할라면 할 수는 있습니다. 그 작업의 시작점만 잘 찾으면요.겉으로는 되게 어려워보일 수 있는데, 일단 그 부분만 찾으면 의외로 쉬울수도 있습니다."다중탭 기능은 애초부터 기획/설계 단계에서 고려해야 하는 구조 아닌가요?"물론 그렇습니다."페이지별로 모듈화해서 개발했으면 이런 문제가 없었을 거다."그 말하는 그분 꿈에서 만나면 이렇게 얘기해주세요."그럼 니가 플젝 완성되기 전에 미리 말해 주던가"(단, 실제로 말하면 책상 없어짐)여하튼세션에 의존도가 있다 치면세션도 키-값 구조이지 않습니까.키만 다르게 정할 수 있으면, 동일 구조의 데이터 여러 개를 다른 키로 담을 수 있겠죠.키 이름 설계만 잘 손대면요쌩노가다 작업이 꽤 많을텐데, 대소문자구분 체크해서 전체 프로젝트 텍스트 한방에 검색해서 일괄 바꿔치기 신공으로 꽤 커버가 될겁니다.

badRacoon · Answer

"그럴 줄 알고 준비했습니다" 같은 걸 바라는건가...

완성된 리액트 서비스에 다중탭 기능 넣으라는데, 설계를 잘못한 걸까요?

9개의 답변

Q&A 목록