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