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는 다른 프레임워크에 비해 구체적인 해결책을 제시하지 않는다는 점이 문제입니다.