Motivation
Feature-Sliced Design은 여러 개발자들의 연구와 경험을 결합해
복잡하고 점점 더 커지는 프로젝트를 더 단순하게 개발하고, 비용을 줄이려는 아이디어에서 출발했습니다.
물론 이 방법론이 모든 문제를 해결하는 만능 열쇠는 아니며, 적용상의 한계도 분명히 존재합니다.
그럼에도 불구하고, 이 방법론이 제공하는 실질적인 효용성 때문에 많은 개발자들이 관심을 갖고 있습니다.
자세한 논의 내용은 토론 게시글에서 확인하실 수 있습니다.
기존 솔루션만으로 부족한 이유
일반적으로 다음과 같은 반문들이 제기됩니다:
- "이미
SOLID,KISS,YAGNI,DDD,GRASP,DRY같은 확립된 원칙들이 있는데, 왜 또 다른 방법론이 필요한가?"- "문서화, 테스트, 구조화된 프로세스로 충분히 해결할 수 있지 않은가?"
- "모든 개발자가 위의 원칙을 제대로 따른다면 문제가 생기지 않았을 것이다."
- "이미 필요한 건 다 발명되었고, 당신이 잘 활용하지 못할 뿐이다."
- "프레임워크 X를 쓰면 된다. 거기에 다 들어있다."
원칙만으로는 충분하지 않다
좋은 아키텍처를 위해 “원칙이 존재한다”는 사실만으로는 충분하지 않습니다.
- 모든 개발자가 이러한 원칙을 깊이 이해하고, 상황에 맞게 올바르게 적용하는 것은 쉽지 않습니다.
- 설계 원칙은 어디까지나 일반적인 지침일 뿐,
“확장 가능하고 유연한 애플리케이션 구조를 구체적으로 어떻게 설계할 것인가” 에 대한 답은 직접 찾아야 합니다.
프로세스가 항상 작동하지는 않는다
문서화, 테스트, 프로세스 관리가 중요한 것은 맞지만,
여기에 많은 비용을 들인다고 해서 아키텍처 문제나 신규 인력 온보딩 문제가 자동으로 해결되는 것은 아닙니다.
- 문서가 방대해지거나 오래되면, 새로운 개발자가 프로젝트에 빠르게 적응하는 데 큰 도움이 되지 않을 수 있습니다.
- 모든 구성원이 동일한 아키텍처 이해를 유지하고 있는지 계속 확인하려면, 그 자체로도 많은 리소스가 필요합니다.
- bus-factor 역시 잊지 말아야 할 중요한 리스크입니다.
기존 프레임워크를 모든 상황에 적용할 수는 없다
- 많은 솔루션은 진입 장벽이 높아, 새로운 개발자를 프로젝트에 투입하기가 어렵습니다.
- 대부분의 경우 프로젝트 초기 단계에 기술 스택이 이미 정해지기 때문에,
특정 기술에 종속되지 않고, 주어진 조건 안에서 유연하게 일할 수 있어야 합니다.
Q: 내 프로젝트에서
React/Vue/Redux/Effector/Mobx/{당신의_기술}을 사용할 때,
entities 구조와 관계를 어떻게 하면 더 잘 설계할 수 있을까요?
결과적으로
각 프로젝트는 시간이 많이 들고, 다른 곳에 그대로 재사용하기도 힘든
눈송이처럼 독특한 구조로 남기 쉬운 상황이 됩니다.
@sergeysova: 이것이 지금 프론트엔드 개발이 겪고 있는 문제입니다.
각 리드는 제각각의 아키텍처와 구조를 만들지만,
그것이 시간이 지나도 유지될지에 대해서는 보장할 수 없습니다.
결국 소수의 개발자만 프로젝트를 유지할 수 있고,
새로운 팀원이 합류할 때마다 긴 적응 기간이 필요해집니다.
개발자에게 왜 필요한가?
아키텍처 고민을 줄이고 비즈니스 기능에 집중
이 방법론은 아키텍처 설계에 쏟는 고민을 줄여,
개발자가 비즈니스 로직 구현에 더 집중할 수 있도록 도와줍니다.
또한 구조를 일정한 규칙 아래 표준화함으로써,
서로 다른 프로젝트 간에도 일관된 구조를 유지할 수 있게 합니다.
커뮤니티에서 신뢰를 얻으려면, 다른 개발자들이 이 방법론을 빠르게 익히고
실제 프로젝트의 문제를 해결하는 데 활용할 수 있어야 합니다.
경험으로 입증된 솔루션 제공
이 방법론은 복잡한 비즈니스 로직을 다루면서 쌓인 경험 기반의 해법을 제공합니다.
또한 실제 사례와 best practices를 모아 놓은 집합체이기도 하므로,
개발자에게 “이런 상황에서는 이렇게 해도 된다”는 실질적인 가이드를 제공합니다.
프로젝트의 장기적 건강성 유지
이 방법론을 사용하면, 많은 리소스를 들이지 않고도
기술 부채와 구조적 문제를 미리 감지하고 해결할 수 있습니다.
기술 부채는 시간이 지날수록 누적되며,
이를 관리하는 책임은 리드뿐 아니라 팀 전체에 있습니다.
비즈니스에 왜 필요한가?
빠른 온보딩
이 방법론에 익숙한 개발자를 프로젝트에 투입하면,
추가 교육 없이도 빠르게 구조를 이해하고 작업을 시작할 수 있습니다.
그 결과:
- 프로젝트 투입 속도가 빨라지고
- 인력 교체나 확장에도 유연하게 대응할 수 있습니다.
검증된 솔루션 제공
이 방법론은 비즈니스가 직면하는 시스템 개발상의 문제에 대해
검증된 형태의 해결책을 제공합니다.
대부분의 비즈니스는 개발 과정에서 발생하는 문제를 해결할 수 있는
프레임워크나 아키텍처 솔루션을 필요로 합니다.
이 방법론은 그 중 하나의 선택지가 될 수 있습니다.
프로젝트 전 단계에 적용 가능
이 방법론은 운영, 유지보수 단계뿐 아니라 MVP 단계에서도 도움이 됩니다.
MVP의 직접적인 목표는 “장기 아키텍처”가 아니라 실제 기능 제공이지만,
방법론의 best practices를 일부라도 적용하면, 제한된 시간 안에서도
나중에 완전히 갈아엎지 않아도 되는 구조에 가까운 타협점을 찾을 수 있습니다.
테스팅에도 비슷한 원리가 적용됩니다.
방법론이 필요하지 않은 경우
다음과 같은 경우에는 이 방법론이 꼭 필요하지 않을 수 있습니다.
- 프로젝트 수명이 짧은 경우
- 지속적인 아키텍처 관리가 필요 없는 경우
- 비즈니스가 “코드 품질과 전달 속도 사이의 연관성”을 중요하게 보지 않는 경우
- 사후 지원보다 빠른 납품이 더 우선인 경우
비즈니스 규모
- 소규모 → 지금 당장 사용할 수 있는 빠른 솔루션이 중요합니다.
시간이 지나 성장하면서, 품질과 안정성에 대한 투자의 필요성을 점차 인식하게 됩니다. - 중간 규모 → 기능 경쟁 속에서도 품질 개선, 리팩토링, 테스트 등에 투자하며
장기적으로 확장 가능한 아키텍처를 중요하게 생각합니다. - 대규모 → 이미 자체적인 아키텍처 접근 방식을 가지고 있을 가능성이 크며,
외부 방법론을 새로 도입할 가능성은 상대적으로 낮습니다.
계획
이 방법론의 주요 목표는 여기에 정의되어 있으며,
앞으로 이 방법론이 어떤 방향으로 발전해야 할지에 대해서도 함께 고민하고 있습니다.
경험 결합
현재 우리는 core-team의 다양한 경험을 모아
더 단단한 방법론을 만드는 작업을 진행 중입니다.
물론 그 결과가 어쩌면 Angular 3.0처럼 평가될 수도 있습니다.
하지만 중요한 것은, 복잡한 아키텍처 설계 문제를 진지하게 탐구하는 과정 자체입니다.
커뮤니티 경험 또한 적극적으로 반영해,
최대한 많은 사람들이 납득할 수 있는 최적의 합의점을 찾는 것이 목표입니다.
사양을 넘어선 생명력
모든 것이 계획대로 진행된다면, 이 방법론은 단순히
“사양과 툴킷” 수준에 머무르지 않을 것입니다.
- 관련 발표나 보고서, 기사
- 다른 기술 스택으로 마이그레이션할 수 있는 CODE_MODE
- 대규모 솔루션을 유지보수하는 개발자들에게 적용할 기회
- 특히 React는 다른 프레임워크에 비해 구체적인 해결책을 거의 제공하지 않는다는 점이 문제입니다.