주요 콘텐츠로 건너뛰기

Needs driven

TL;DR

새로운 Feature의 목표가 불분명하거나 작업 정의가 모호한가요? 이 방법론의 핵심은 작업과 목표를 명확히 정의하는 데 있습니다.

프로젝트 구조는 항상 변합니다. 요구사항과 Feature는 계속 바뀌고, 코드는 점점 복잡해집니다. 좋은 아키텍처는 변화에 쉽게 적응할 수 있어야 합니다.

왜 이런 접근이 필요한가?​

각 Entity의 이름과 구조를 명확히 하려면, 그 코드가 해결하려는 목적을 정확히 이해해야 합니다.

@sergeysova: 개발할 때 Entity와 함수 이름에는 반드시 그 의도를 반영하려고 합니다.

작업이 불명확하면 테스트 작성이 어렵고, 에러 처리가 비효율적이며, 결국 사용자 경험이 저하됩니다.

우리가 말하는 작업이란?​

프론트엔드는 사용자의 문제를 해결하고 요구를 충족하는 인터페이스를 제공합니다.
사용자는 서비스에서 자신의 필요를 해결하거나 목표를 달성하려 합니다.

관리자와 분석가는 이를 명확히 정의하고, 개발자는 네트워크 지연, 에러, 사용자 실수 같은 환경을 고려하여 구현합니다.

즉, 사용자의 목표가 곧 개발자의 작업입니다.

Feature-Sliced Design의 핵심 철학 중 하나는 — 프로젝트의 전체 작업을 더 작은 목표 단위로 나누는 것입니다.

개발에 어떤 영향을 주는가?​

작업 분해​

개발자는 유지보수성을 위해 작업을 점진적으로 분해합니다.

  • 최상위 Entity로 나누기
  • 더 작은 단위로 세분화하기
  • 각 Entity에 명확한 이름 부여하기

모든 Entity는 사용자의 문제 해결에 직접 기여해야 합니다.

작업의 본질 이해​

Entity의 이름을 정하려면 그 목적과 역할을 충분히 이해해야 합니다.

  • 구체적인 사용 목적
  • 구현하는 사용자 작업의 범위
  • 다른 작업과의 연관성

결론적으로, 이름을 고민하는 과정에서 불명확한 작업을 미리 발견할 수 있습니다.

Entity의 이름을 정의하려면, 먼저 그 Entity가 해결할 작업을 명확히 이해해야 합니다.

어떻게 정의할 것인가?​

Feature가 해결할 작업을 정의하려면, 그 본질을 파악해야 합니다.
이는 주로 프로젝트 관리자와 분석가의 역할입니다.

방법론은 단순히 개발자에게 방향을 제시합니다.

@sergeysova: 프론트엔드는 단순히 무엇을 보여준다가 아니라, “왜 이것을 보여줘야 하는가?”를 통해 사용자의 실제 필요를 이해해야 합니다. 사용자의 필요를 이해하면, 제품이 목표 달성을 어떻게 돕는지 구체화할 수 있습니다.
모든 새로운 작업은 비즈니스와 사용자의 문제를 함께 해결해야 하며, 분명한 목적을 가져야 합니다.

개발자는 맡은 작업의 목표를 분명히 이해해야 합니다. 비록 완벽한 프로세스가 없더라도, 관리, 기획 담당자와의 소통을 통해 목표를 파악하고 효과적으로 구현할 수 있어야 합니다.

이점​

전체 Process를 통해 얻을 수 있는 이점을 살펴보겠습니다.

1. 사용자 작업 이해​

사용자 문제와 비즈니스 요구를 이해하면, 기술적 제약 내에서도 더 나은 솔루션을 제안할 수 있습니다.

이 모든 것은 개발자가 자신의 역할과 목표에 적극적으로 관심을 가질 때만 가능합니다.
그렇지 않다면, 어떤 방법론도 큰 의미를 가지지 못합니다.

2. 구조화와 체계화​

작업을 이해하면 사고 과정과 코드가 자연스럽게 정리되고 구조화됩니다.

3. 기능과 그 구성 요소 이해​

Feature는 사용자에게 명확한 가치를 제공해야 합니다.

  • 여러 기능이 섞이면 경계 위반

  • Feature는 분리와 확장이 가능해야 함

  • 핵심 질문: 이 Feature가 사용자에게 어떤 가치를 주는가?

  • 예시:

    • ❌ 지도-사무실 (모호함)
    • ⭕ 회의실-예약, 직원-검색, 근무지-변경 (명확함)

_@sergeysova: Feature는 핵심 구현 코드만 포함해야 합니다.

관련 없는 코드는 제외하고, 해당 Feature의 핵심 로직만 담아야 합니다.

4. 유지보수성​

비즈니스 로직을 코드에 명확히 반영하면, 장기적인 유지보수성이 높아집니다.

새로운 팀원이 합류해도 코드만 읽으면 무엇을, 왜 구현했는지 이해할 수 있습니다

(도메인 주도 설계에서 말하는 비즈니스 언어 개념과 유사)

현실적 고려사항​

비즈니스 프로세스와 설계가 명확하다면 구현은 쉽습니다.
그러나 현실에서는 충분한 설계 없이 Feature가 반복적으로 추가되는 경우가 많습니다.

결과적으로 지금 당장은 적절해 보이던 Feature가 한 달 뒤 확장에서 전체 구조를 흔들 수 있습니다.

토론: 개발자는 보통 2~3단계 앞을 예측하려 하지만, 경험에 따라 그 한계가 달라집니다.
숙련된 개발자는 최대 10단계 앞까지 내다보고 Feature 분할과 통합을 더 잘합니다.
그러나 때로는 경험으로도 해결하기 어려운 복잡한 상황이 발생하며, 이때는 문제를 최소한으로 쪼개는 것이 중요합니다.

방법론의 역할​

이 방법론의 목적은 개발자가 사용자의 문제를 효과적으로 해결하도록 돕는 것입니다.

즉, 방법론은 단순히 코드를 위한 규칙이 아니라,
사용자의 필요를 이해하고 반영하기 위한 도구입니다.

방법론 요구 사항​

Feature-Sliced Design이 충족해야 할 두 가지:

  1. Feature, Process, Entity를 구성하는 명확한 방법 제공

    • 코드 분할 기준, 명명 규칙 정의

  2. 변화하는 요구사항에 유연한 아키텍처 제공

참고 자료​