Needs driven
새로운 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가 사용자에게 어떤 가치를 주는가?”
- 예시:
- ❌
지도-사무실(무엇을 하는지 모호함) - ⭕
회의실-예약,직원-검색,근무지-변경(기능이 명확하게 드러남)
- ❌
@sergeysova: Feature는 해당 기능의 핵심 구현 코드만 포함해야 합니다.
관련 없는 코드는 과감히 제외하고, 이 Feature에 꼭 필요한 로직만 담는 것이 좋습니다.
4. 유지보수성
비즈니스 로직이 코드에 잘 드러나 있으면,
장기적인 유지보수성이 크게 향상됩니다.
새로운 팀원이 합류하더라도,
코드를 읽는 것만으로 “무엇을, 왜 구현했는지” 이해할 수 있게 됩니다.
(도메인 주도 설계에서 말하는 비즈니스 언어 개념과도 유사합니다.)
현실적 고려사항
비즈니스 프로세스와 설계가 처음부터 잘 정리되어 있다면,
구현 자체는 그리 어렵지 않습니다.
하지만 실제로는 충분한 설계 없이 Feature가 계속 추가되는 경우가 많습니다.
그 결과, 지금 당장 보기에는 적절해 보이던 Feature가
한 달 뒤 새로운 요구사항이 들어왔을 때 전체 구조를 뒤흔드는 원인이 되기도 합니다.
토론: 개발자는 보통 “2~3단계 앞”을 내다보며 설계를 하지만,
그 한계는 경험에 따라 달라집니다.
숙련된 개발자는 “최대 10단계 앞”까지 예상하여
Feature를 나누고 합치는 결정을 더 잘할 수 있습니다.그럼에도 불구하고, 때때로 경험으로도 해결하기 어려운 복잡한 상황이 생기며,
이때는 문제를 최소한의 크기로 쪼개는 것이 중요합니다.
방법론의 역할
이 방법론의 목적은 개발자가 사용자의 문제를 더 효과적으로 해결하도록 돕는 것입니다.
즉, 이 방법론은 단지 “코드를 어떻게 나눌 것인가”에 대한 규칙이 아니라,
사용자의 필요를 이해하고, 그것을 코드 구조에 반영하는 도구입니다.
방법론 요구 사항
Feature-Sliced Design은 최소한 다음 두 가지 요구를 충족해야 합니다.
1. Feature, Process, Entity를 구성하는 명확한 방법 제공
- 코드 분할 기준과 명명 규칙 정의
2. 변화하는 요구사항에 유연한 아키텍처 제공
참고 자료
- (포스트) 명확한 작업 정의 가이드 (+ 토론)
이 문서는 해당 토론을 기반으로 작성되었습니다.
자세한 내용은 원문 링크를 참고하세요. - (토론) Feature 분해 방법론
- (아티클) "효과적인 애플리케이션 구조화"