필요 중심
— 새로운 Feature의 목표가 불분명하거나 작업 자체가 명확히 정의되지 않았나요? 이 방법론의 핵심은 작업과 목표를 명확히 정의하는 데 있습니다.
— 프로젝트는 정적인 것이 아닙니다. 요구 사항과 Feature는 계속해서 변화하며, 시간이 지남에 따라 코드는 점점 복잡해지고 관리가 어려워집니다. 우수한 아키텍처는 이러한 변화에 유연하게 적응할 수 있어야 합니다.
왜 이런 접근이 필요할까요?
각 Entity의 이름과 구성을 명확히 하려면, 해당 코드의 목적을 정확히 이해해야 합니다.
@sergeysova: 개발할 때 각 Entity와 함수의 의도를 이름에 명확히 반영하려고 노력합니다.
명확하지 않은 작업은 테스트 작성을 어렵게 만들고, 오류 처리가 비효율적이 되어 사용자 경험을 저하시킬 수 있습니다.
우리가 말하는 작업이란?
프론트엔드는 사용자의 문제를 해결하고 요구사항을 충족하는 인터페이스를 제공합니다.
사용자는 서비스 사용 시 자신의 문제를 해결하거나 필요를 충족하려 합니다.
관리자와 분석가는 이러한 요구사항을 명확히 정의하고, 개발자가 웹의 특성(네트워크 지연, 오류, 사용자 실수 등)을 고려하여 구현할 수 있도록 지원합니다.
사용자의 목표가 곧 개발자의 작업입니다.
Feature-Sliced Design의 핵심 철학 중 하나는 — 프로젝트의 전체 작업을 더 작은 목표 단위로 나누는 것입니다.
이것이 개발에 어떤 영향을 미치는가?
작업 분해
개발자는 코드의 유지보수성을 위해 작업을 단계적으로 분해합니다:
- 최상위 Entity로 분할
- 더 작은 단위로 세분화
- 각 Entity에 명확한 이름 부여
개발자는 코드가 해결하는 작업의 본질을 반영하도록 각 Entity와 구성 요소에 명확한 이름을 부여합니다. 이 과정에서 모든 작업이 사용자의 문제 해결에 기여해야 함을 항상 고려합니다.
작업의 본질 이해
Entity에 명확한 이름을 부여하려면 개발자가 해당 Entity의 목적과 역할을 충분히 이해해야 합니다:
- Entity의 구체적인 사용 목적
- 구현하는 사용자 작업의 범위
- 다른 작업과의 연관성
결론적으로, 개발자가 Entity의 이름을 고민하는 과정에서 불명확한 작업을 미리 발견할 수 있습니다.
Entity의 이름을 정의하려면 해당 Entity가 해결할 작업을 정확히 이해해야 합니다.
어떻게 정의할 것인가?
Feature가 해결할 작업을 정의하려면 그 본질을 이해해야 합니다. 이는 주로 프로젝트 관리자와 분석가의 역할입니다.
방법론은 개발자에게 작업의 방향성을 제시할 뿐입니다.
@sergeysova: 프론트엔드는 정보 표시에 초점을 맞추지만, 단순히 "무엇을 보여준다"는 것은 충분한 가치를 가지지 못합니다. "왜 이것을 보여줘야 하는가?"라는 질문을 통해 사용자의 실제 필요를 이해해야 합니다.
이는 프론트엔드의 기술적 측면을 넘어서, 사용자의 문제와 필요를 정확히 이해할 때까지 지속적으로 탐구해야 하는 과정입니다.
사용자의 필요를 이해한 후에는 제품이 어떻게 사용자의 목표 달성을 도울 수 있는지 구체화할 수 있습니다.
모든 새로운 작업은 비즈니스와 사용자의 문제를 동시에 해결하는 것을 목표로 합니다. 각 작업은 명시적이지 않더라도 분명한 목적을 가집니다.
개발자는 작업의 목표를 명확히 이해해야 합니다. 완벽한 프로세스가 없더라도, 관리자와의 소통을 통해 이를 파악하고 효과적으로 구현할 수 있어야 합니다.
이점
전체 Process를 통해 얻을 수 있는 이점을 살펴보겠습니다.
1. 사용자 작업 이해
개발자가 사용자의 문제와 비즈니스 해결방안을 이해하면, 기술적 제약 내에서도 더 나은 솔루션을 제안할 수 있습니다.
이는 개발자가 자신의 역할과 목표에 관심을 가질 때만 가능합니다. 그렇지 않다면, 방법론 자체가 의미를 잃습니다.
2. 구조화 및 정리
작업을 이해하면 사고 과정, 작업, 코드가 자연스럽게 체계화됩니다.
3. 기능과 그 구성 요소 이해
하나의 Feature는 사용자에게 명확한 가치를 제공해야 합니다.
- 여러 기능이 섞이면 경계 위반입니다
- Feature는 분리와 확장이 가능합니다. 이는 자연스러운 것입니다
- 핵심은 "이 Feature가 사용자에게 제공하는 가치가 무엇인가?" 입니다
- 예시:
- ❌ "지도-사무실" (모호한 Feature)
- ⭕
회의실-예약,직원-검색,근무지-변경(명확한 Feature)
_@sergeysova: Feature는 핵심 구현 코드만 포함해야 합니다.
관련 없는 코드는 제외하고, 해당 Feature의 핵심 로직만 담아야 합니다._
4. 유지보수성
비즈니스 방향은 쉽게 바뀌지 않습니다. 따라서 비즈니스 로직을 코드에 명확히 반영하면 장기적인 이점이 있습니다.
그 결과, 새로운 팀원이 합류할 때마다 코드가 무엇을 하고, 왜 추가되었는지 따로 설명할 필요가 없습니다. 코드 자체에 반영된 비즈니스 작업을 통해 모든 것이 설명될 것입니다.
현실적 고려사항
비즈니스 Process가 명확하고 설계가 잘 되었다면, 이를 코드로 구현하는 것은 비교적 쉽습니다.
하지만 현실에서는, 작업과 Feature가 충분한 설계 시간 없이 반복적으로 처리되는 경우가 많습니다.
결과적으로, 현재는 적절해 보이는 Feature가 한 달 후 확장 과정에서 전체 프로젝트 구조를 변경해야 할 수도 있습니다.
토론에서: 개발자는 보통 2~3단계 앞의 요구사항을 예측하려 노력하며, 이는 경험에 크게 좌우됩니다.
숙련된 개발자는 약 10단계 앞까지 예측할 수 있어서, Feature의 분할 지점과 통합 방식을 더 잘 이해합니다.
그러나 때로는 경험으로도 해결하기 어려운 복잡한 상황이 발생하며, 이때는 피해를 최소화하면서 문제를 적절히 분해하기가 매우 어렵습니다.
방법론의 역할
방법론은 개발자가 사용자의 문제를 더 효과적으로 해결할 수 있도록 돕는 것이 목적입니다.
방법론은 단순히 개발자를 위한 것이 아닙니다.
개발자가 좋은 결과를 내려면, 사용자의 문제와 요구사항을 정확히 이해해야 합니다. 사용자의 문제를 모르면 좋은 해결책을 만들 수 없습니다.
방법론 요구 사항
Feature-Sliced Design이 충족해야 할 두 가지 요구사항:
-
Feature, Process, Entity를 구성하는 명확한 방법 제시
- 코드 분할 기준과 명명 규칙을 구체적으로 정의
참고 자료
- (포스트) 명확한 작업 정의 가이드 (+ 토론)
이 문서는 해당 토론을 바탕으로 작성되었습니다. 원문은 링크를 참고하세요.
- (토론) Feature 분해 방법론
- (아티클) "효과적인 애플리케이션 구조화"