FSD 관점에서 본질을 찾아가는 개발 문화

1. 자명한 추상화 vs 성급한 추상화 2. 중복 허용 전략 3. 릴리즈 자유도 보장 💡 제안: Release 브랜치 기반 배포 전략 마무리하며

최근 진행한 프로젝트 사례를 돌아보며, 한 페이지의 특정 영역을 담당했던 경험을 공유합니다. 해당 프로젝트는 이해관계자가 많았고, 일정상 기존 다른 프로젝트의 코드베이스를 그대로 가져와 쓰는 경우가 잦았습니다.

이 과정에서 몇 가지 문제점이 눈에 띄었습니다.

레거시 코드에 남아 있던 안티패턴

겉모습만 FSD 구조였고, 실제로는 중앙집중형(shared component) 의존성이 높은 구조

여기에 이해관계자가 많고 승인 절차가 까다로운 상황이 맞물리면서 생산성이 떨어지는 프로세스가 만들어졌습니다.

예를 들어 다음과 같은 상황입니다.

A: 공통 컴포넌트를 개선하려 함

B: 아직 테스트 프로세스가 정착되지 않은 프로젝트라, 모든 이해관계자가 변경사항을 파악할 수 있도록 병합을 미루자고 함

A 입장에서는 자신의 업무를 멈추고 모두의 승인을 받아야 할지 고민하게 되고, 이 과정에서 갈등이 발생합니다.

이때 문득, “넷플릭스와 같은 빅테크 조직에서는 이런 문제를 어떻게 풀까?“라는 의문이 들었습니다.

그리고 이 상황을 FSD(Feature-Sliced Design) 관점에서 재해석해 보았습니다.

1. 자명한 추상화 vs 성급한 추상화

레거시의 많은 문제는 성급한 추상화에서 비롯됩니다.

이번 사례에서 A는 기존 shared 단위의 컴포넌트가 새로운 기획에 맞지 않자, 더 큰 범위의 HTTP 통신 라이브러리 사용성에 제약을 두려 했습니다.

하지만 이는 문제 해결과 직접적인 관련이 없는 제약이었고, 추후 유지보수 비용을 높이는 선택이었습니다.

히스토리를 모르는 개발자가 해당 제약을 간과하고 코드를 작성하면, 결국 같은 문제가 반복됩니다.

저는 A에게 이렇게 제안했습니다.

이 문제는 HTTP 통신 라이브러리와 직접적인 관련이 없다.

행동을 제한하는 대신 문제의 본질을 해결하는 다른 방법을 찾아보자.

함께 고민한 끝에, 본질은 HTTP 통신 제약이 아니라 권한 레이어 분리임을 확인했습니다.

즉, 권한에 따라 API 요청 여부를 결정하면 문제를 깔끔하게 풀 수 있었던 것입니다.

이렇게 문제의 본질을 정확히 파악한 추상화는, 불필요한 제약 없이 깔끔하게 해결책을 제공합니다.

반대로 성급한 추상화는 히스토리를 모르면 유지보수가 어려워지고, 장기적으로는 조직 전체의 생산성을 저해합니다.

2. 중복 허용 전략

FSD는 어느 정도 중복을 허용해 생산성을 높이는 구조입니다.

각 슬라이스(slices)는 보통 다음과 같이 반복되는 구조를 가집니다.

전통적인 중앙집중형 구조는 다음과 같습니다.

중앙집중형은 공통 단위의 수정이 모든 팀에 영향을 주기 때문에 승인 프로세스가 길어집니다.

특히 하나의 페이지에서만 필요한 변경도 전사 공통 컴포넌트를 건드려야 한다면, 모든 팀의 동의를 받아야 하는 상황이 발생합니다.

FSD에서는 이런 상황에서 과감히 중복을 허용합니다.

공통화 비용 > 유지보수 이득이면 중복 허용

예: 각 슬라이스에 비슷한 DatePicker가 있어도, 커스터마이징이 많으면 slice별 유지

실험적인 컴포넌트는 UI Playground에서 검증 후 성공 시에만 공통화

실패하거나 특화된 건 slice에 그대로 둠 (Dead Code Cleanup 주기 실행)

즉, 성급한 공통화를 지양하고, 기획 변화에 빠르게 대응할 수 있는 구조를 유지합니다.

3. 릴리즈 자유도 보장

모노레포 + FSD + MFE 환경에서 가장 큰 배포 고민은 병렬 스프린트입니다.

예를 들어 10명이 동시에 작업 중이라면, main에 머지된 모든 수정이 다음 배포자에게 부담이 됩니다.

배포 전 모든 팀에 배포 가능 여부 확인 필요

애매한 변경은 release 브랜치 생성 후 cherry-pick 배포

trunk(main)와 release 브랜치 간 간극 심화 → 기술 부채 발생

💡 제안: Release 브랜치 기반 배포 전략

이미 간극이 벌어진 상황이라면, release 브랜치를 배포 기준으로 삼고,

이전 배포 태그에서 release 브랜치를 새로 생성 → 수정 → main에 병합하는 흐름을 유지합니다.

프로세스

이전 배포 태그에서 release 브랜치 생성

배포 대상 변경만 반영

배포 후 main으로 병합

다음 배포 시에도 반복

장점

main이 불안정해도 안정 배포 가능

팀별 병목 완화

trunk와 release 간 간극 최소화

마무리하며

이 글은 완벽한 해답을 제시하기보다, 문제의 본질을 찾아가는 과정에 초점을 두었습니다.

기술의 목적은 결국 사용자에게 가치를 전달하는 것이며, 개발자의 역할은 그 가치를 프로덕트에 온전히 녹여내는 일입니다.

FSD를 적용하며 깨달은 점은, 구조나 패턴 그 자체보다 성급한 추상화를 피하고, 자명한 추상화를 선택하는 판단력이 훨씬 중요하다는 것입니다.

때로는 과감하게 중복을 허용해 변화하는 기획에 기민하게 대응하고, 배포의 자유도를 확보하는 것이 장기적인 생산성을 담보합니다.

더불어 AI를 통해 개인이 접근할 수 있는 지식의 폭이 크게 넓어진 지금, 수많은 대안 중에서 무엇이 본질적인 해결인지 가려내는 능력이 그 어느 때보다 중요해졌습니다. AI는 다양한 방향과 가능성을 제시해 줄 수 있지만, 그중에서 진정한 해결책을 선택하고 구현하는 일은 결국 사람의 몫입니다.