실생활에 유용한 Angular 아키텍처

대부분의 Angular 아키텍처 과정에서는 이론을 가르칩니다. 이건 아니야.

여기서는 실제 문제를 감지하고, 상황에 맞는 결정을 내리고, 팀이 성장하고 제품이 변경되고 시간이 지나도 지속되는 시스템을 구축하는 방법을 배웁니다.

20개의 모듈. 실천 지향적입니다. 패딩이 없습니다.

---

INDEX — 실생활을 위한 실용적인 Angular 아키텍처

---

모듈 0 - 시스템 베이스

포인트 0은 콘텐츠 모듈이 아닙니다. 로드맵 전반에 걸쳐 사용하게 될 것으로 보는 방법입니다.

Angular의 특정 문제에 대해 이야기하기 전에 다음 질문에 답해야 합니다.

모르는 앱을 보고 좋은지 나쁜지 어떻게 판단하시나요?

이를 위한 4가지 기본 스킬이 있습니다.

---

1. 코드를 건드리지 않고 앱을 분석해보세요

앱의 첫 번째 읽기는 편집기에서 이루어지지 않습니다. 구조에 있습니다. 단일 파일을 열기 전에 정보를 추출할 수 있습니다.

• 폴더는 무엇이라고 부르나요? 이름이 그들이 하는 일을 말해주는가?
• 다른 것보다 무게가 더 나가는 shared 폴더가 있나요?
• 구조에는 몇 개의 중첩 수준이 있습니까?
• 모듈이나 기능에 도메인 이름이나 기술 이름이 있습니까?
• 서비스는 어디에 있나요? 느슨하거나 기능 내에 있습니까?

이것은 이미 앱을 만든 사람이 비즈니스 측면에서 생각했는지 아니면 기술 측면에서 생각했는지에 대해 많은 것을 알려줍니다.

---

2. 실용적인 방식으로 아키텍처를 검토합니다.

리뷰는 코드를 위에서 아래로 읽는 것이 아닙니다. 다음과 같은 기준으로 질문하고 있습니다.

• 비즈니스 로직은 어디에 있습니까?
• 각 레이어에 무엇이 있는지 누가 알겠어요?
• 새로운 기능을 추가하려면 몇 개의 사이트를 변경해야 합니까?
• 잘못된 방향으로 가는 종속성이 있습니까?

수석 아키텍트는 가장 복잡한 구성 요소부터 시작하지 않습니다. 공유 서비스, 전역 상태, 데이터 액세스 계층 등 위험이 가장 높은 지점부터 시작하세요.

---

3. 프로그래밍하기 전에 문제를 감지하세요

대부분의 아키텍처 손상은 관련성이 없어 보이는 초기 결정에서 발생합니다.

• "지금은 공유 서비스에 올려 놓겠습니다."
• "상위 구성 요소가 이 상태를 처리한 다음 이동합니다."
• "우리는 모든 것에 NgRx를 사용하므로 일관성이 있습니다."

이러한 결정은 몇 달 후에 실질적인 결과를 가져옵니다. 아키텍처 기준은 각 결정이 무엇을 구매하고 어떤 부채를 초래하는지 아는 것입니다.

---

4. 이론을 실제 체크리스트로 전환

이 로드맵에서 보게 될 각 개념(스마트/멍청한 구성 요소, 상태 배치, 신 서비스 등)은 실제 코드를 검토하는 동안 스스로에게 물어볼 수 있는 질문으로 끝나야 합니다.

• 이 구성 요소는 데이터의 출처를 알고 있습니까?
• 이 서비스를 변경해야 할 이유가 두 가지 이상입니까?
• 이 상태가 서로 다른 두 곳에 존재합니까?

개념을 검토 질문으로 전환할 수 없다면 아직 내부화하지 않은 것입니다.

---

모듈 1 — 코드를 건드리지 않고 Angular 앱을 분석하는 방법

첫 번째 아키텍처 검토는 편집기를 열기 전에 발생합니다. 폴더 구조와 파일 이름만으로도 이미 명확한 품질 신호를 추출할 수 있습니다. 이것이 수석 설계자가 알 수 없는 앱을 사용하여 처음 10분 동안 수행하는 작업입니다.

왜 중요합니까?

• 아키텍처 문제를 감지하는 데 오랜 시간이 걸리면 이를 수정하는 데 드는 비용이 기하급수적으로 늘어납니다.
• 처음부터 잘못 설계된 구조는 몇 달 후 팀을 가로막는 기술적 부채가 됩니다.
• 신속한 시각적 판단을 개발하면 코드 한 줄을 작성하기 전에 더 나은 결정을 내릴 수 있습니다.

1단계 - 폴더 구조를 맵으로 읽기

폴더 구조는 가장 먼저 눈에 띄는 아키텍처 결정입니다. 팀이 정신 세계를 어떻게 구성했는지 알려줍니다. 기술 측면에서 생각합니까 아니면 비즈니스 측면에서 생각합니까?

기능이란 무엇입니까?

기능은 완전한 비즈니스 기능입니다. 파일 형식이 아닙니다. 기술 계층이 아닙니다.

전자상거래 앱을 생각해 보세요. 기능은 다음과 같습니다:

• 제품 카탈로그
• 장바구니
• 결제 과정
• 사용자 프로필
• 주문관리

이들 각각은 그 자체로 의미가 있는 사업입니다. 사용자가 들어가고, 카탈로그를 찾아보고, 장바구니에 추가하고, 체크아웃합니다. 그것들은 특징입니다.

모델 1 — 기술 계층별 구성(규모에 따라 문제가 있음)

이것은 깔끔해 보이기 때문에 거의 모든 사람들이 시작할 때 하는 일입니다.

src/app/
  components/
    product-card.component.ts
    product-list.component.ts
    cart-item.component.ts
    checkout-form.component.ts
    user-profile.component.ts
  services/
    product.service.ts
    cart.service.ts
    checkout.service.ts
    user.service.ts
  models/
    product.model.ts
    cart.model.ts
    user.model.ts

진짜 문제는 결제 흐름을 수정해야 한다는 것입니다. 관련된 내용을 이해하려면 세 가지 다른 폴더 사이를 탐색합니다. components/에서 구성 요소를 찾고, services/에서 서비스를, models/에서 모델을 찾습니다. 특정 체크아웃 파이프가 있는 경우 다른 기능의 파이프와 혼합된 pipes/에 있습니다.

단일 기능을 변경하려면 전체 앱을 탐색합니다. 그것은 구조에 의한 결합입니다. 팀이 성장하면 서로 다른 기능을 작업하는 두 사람이 동일한 폴더를 지속적으로 만지므로 git에서 충돌이 발생하여 누가 무엇을 소유하는지 알기가 어렵습니다.

모델 2 — 기능별 구성(규모)

src/app/
  features/
    catalog/
      components/
        product-card.component.ts
        product-list.component.ts
      services/
        product.service.ts
      models/
        product.model.ts
      catalog.routes.ts
    cart/
      components/
        cart-item.component.ts
        cart-summary.component.ts
      services/
        cart.service.ts
      cart.routes.ts
    checkout/
      components/
        checkout-form.component.ts
        order-confirmation.component.ts
      services/
        checkout.service.ts
      checkout.routes.ts
  shared/
  core/

작동 이유: 결제를 탭하면 결제에 포함된 모든 항목이 함께 표시됩니다. 새로운 개발자는 어디를 봐야 할지 정확히 알고 있습니다. 한 사람이 전체 기능을 소유할 수 있습니다. 해당 폴더만 삭제하여 전체 기능을 삭제할 수 있습니다. 다양한 기능 간의 Git 충돌이 거의 완전히 사라집니다.

경험상 핵심 규칙: 기능을 삭제하는 경우 다른 항목을 건드리지 않고 전체 폴더를 삭제할 수 있습니까? 대답이 '예'이면 기능이 잘 격리된 것입니다. 앱 전체에서 조각을 찾아야 한다면 그렇지 않습니다.

2단계 - 이름 읽기

이름은 문서입니다. 나쁜 이름은 의도를 숨기고 코드를 읽는 각 사람에게 인지 부하를 가중시킵니다.

shared/ — 포함해야 할 것과 포함하지 말아야 할 것

shared/은(는) 여러 기능이 사용하고 자체 비즈니스 로직이 없는 항목을 위한 것입니다.

shared/에서 수정됨:

shared/
  components/
    button/
    modal/
    spinner/
    avatar/
  pipes/
    date-format.pipe.ts
    truncate.pipe.ts
  directives/
    click-outside.directive.ts
  validators/
    email-validator.ts

재사용 가능한 UI 조각 또는 순수 유틸리티입니다. 그들은 사업에 대해 아무것도 모릅니다. ButtonComponent은(는) 결제 버튼인지 사용자 프로필 버튼인지 알 수 없습니다. 그는 버튼이 되는 법만 알고 있어요.

shared/에서 올바르지 않음:

shared/
  services/
    cart.service.ts           ← lógica de negocio aquí
    user-auth.service.ts      ← pertenece a auth/core
    product-filter.service.ts ← pertenece a catalog
    report-generator.service.ts ← pertenece a reporting

shared/ 내부에 비즈니스 로직이 포함된 서비스가 있다는 것은 누군가가 이를 어디에 배치하고 배치해야 할지 몰랐다는 의미입니다. 시간이 지남에 따라 shared/은(는) 모든 앱을 포괄하는 앱이 됩니다.

core/ — 그것이 무엇인지, 무엇이 아닌지

core/은 전체 앱이 한 번만 필요한 싱글톤 인프라용입니다.

core/에서 수정됨:

core/
  services/
    auth.service.ts
    logger.service.ts
    error-handler.service.ts
  interceptors/
    auth.interceptor.ts
    error.interceptor.ts
  guards/
    auth.guard.ts
  models/
    user-session.model.ts

core/에서 올바르지 않음:

core/
  components/
    dashboard.component.ts  ← eso es una feature
    home.component.ts       ← igual
  services/
    product.service.ts      ← pertenece a catalog
    report-generator.service.ts ← pertenece a reporting

이는 한 번 인스턴스화되어 전체 앱에 영향을 미치는 것입니다. 인증 인터셉터는 전체 앱에 대한 모든 HTTP 요청을 가로채기 때문에 core/에 있습니다.

모호한 이름 — 위험 신호

모호한 이름은 연기된 결정입니다. 누군가 data.service.ts을(를) 만들 때 해당 서비스가 말하는 데이터가 무엇인지 결정하지 않았습니다.

당신이 보는 것	무엇을 의미할 수 있나요?
shared/ 매우 크다	다른 곳에는 맞지 않는 모든 것. 혼합백이 됩니다.
common/	shared/과 동일하지만 이름이 더 나쁩니다. 무엇이 들어가는지에 대한 기준 없이.
utils/ 서비스 포함	유틸리티로 위장한 비즈니스 로직. 심각한 위험 신호입니다.
helpers/	utils/과 동일합니다. 이름은 책임에 대해 아무 것도 말하지 않습니다.
루트의 components/	도메인별 조직이 없습니다. 모든 구성 요소가 함께 제공됩니다.
core/(40개 파일 포함)	잘못 정의된 핵심. shared/이 두 번째로 사용되었습니다.
app.service.ts	성장을 기다리는 신의 봉사. 최대 경보 신호.
data.service.ts	무엇에 관한 데이터인가요? 이름부터 무한책임.
helper.service.ts	결국 관련없는 메소드를 가진 서비스가 됩니다.
main.component.ts	"메인"이란 무엇입니까? 실제 책임을 숨기는 일반적인 이름입니다.

이름 규칙: 파일 이름이 정확히 무슨 일을 하는지 알려주지 않는다면 파일의 기능이 너무 많거나 위치가 잘못된 것일 수 있습니다.

모호한 이름과 그 이름이 숨기는 내용의 구체적인 예:

• 800줄의 utils/format.ts: 날짜 형식 + 양식 유효성 검사 + API 변환이 혼합되어 있습니다.
• helper.service.ts: 결국 관련 없는 방법으로 신을 섬기게 됩니다.
• app.service.ts: 전체 앱을 담당하는 전체 앱이라는 서비스입니다.

3단계 - 파일을 열지 않고 계산 및 측정

코드를 읽기 전에 구조에서 직접 다음 사항을 관찰할 수 있습니다.

기호로서의 구성 요소 크기

징후	그것은 무엇을 나타냅니까?
하나의 구성 요소에 +300-400 라인	당신은 거의 항상 너무 많은 일을 하고 있습니다. 절대적인 규칙은 아니지만 조사해 볼 가치가 있습니다.
+10개의 입력 및 출력	API가 너무 복잡합니다. 후보는 여러 구성 요소로 나누어집니다.
구성 요소의 직접 HTTP 호출	프레젠테이션과 데이터 액세스를 혼합하세요. 서비스 계층이 누락되었습니다.
기능당 구성요소 1~2개	그들은 아마도 너무 많은 일을 하고 있는 것 같습니다. 내부분열이 부족합니다.
+20개 글로벌 제공업체	상태가 너무 많고 논리가 중앙 집중화되어 있습니다. 모든 것이 글로벌할 필요는 없습니다.

글로벌 서비스 — providedIn: 'root'의 위험

글로벌 서비스는 모든 기능의 모든 구성 요소가 이를 주입하고 사용할 수 있음을 의미합니다. 이는 독립적이어야 하는 기능 간에 보이지 않는 종속성을 생성합니다.

// Servicio que DEBERÍA ser local a la feature de catalog:
@Injectable({ providedIn: 'root' })  // ← señal de problema
export class ProductFilterService { ... }

// Ahora cualquier componente de cualquier feature puede usarlo.
// Si catalog cambia su lógica de filtrado, puede romper
// algo en una feature aparentemente no relacionada.

4단계 — app.module.ts 또는 app.config.ts: 찾아야 할 항목

모듈이 있는 앱(Angular < 17 또는 레거시)

@NgModule({
  imports: [
    BrowserModule,
    HttpClientModule,
    RouterModule,
    AuthModule,       // ← bien, infraestructura singleton

    ProductModule,    // ← señal de problema
    CartModule,       // ← señal de problema
    CheckoutModule,   // ← señal de problema
    UserModule,       // ← señal de problema
    DashboardModule,  // ← señal de problema
    // Si hay 15+ módulos de features aquí,
    // el lazy loading no está funcionando.
  ],
  providers: [
    ProductService,   // ← si hay 20+ providers aquí,
    CartService,      // hay demasiada centralización
    UserService,
    AuthService,
  ]
})

기능 모듈은 루트 모듈로 직접 가져오지 않고 지연(요청 시) 로드되어야 합니다. 여기에 모두 있으면 사용자에게 전혀 필요하지 않더라도 시작 시 모두 로드됩니다.

독립형 앱(Angular 17+)

// app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withLazyLoading()),   // ← correcto
    provideHttpClient(withInterceptors([authInterceptor])),
    provideAnimations(),

    ProductService,   // ← esto NO debería estar aquí
    CartService,      // ← pertenece a la feature de cart
  ]
}

전역 구성 규칙: 전역 구성에는 지연 로딩이 있는 라우터, 전역 인터셉터가 있는 HttpClient, 애니메이션, 인프라 싱글턴 서비스(인증, 로거, 오류 처리기) 등 전체 앱에 영향을 미치는 인프라만 있어야 합니다. 전역 구성에 기능 서비스가 표시되면 누군가가 필요가 아닌 편의를 위해 전역적으로 항목을 등록하고 있는 것입니다.

전체 체크리스트 — Angular 앱의 첫 번째 읽기

구조

• 구조가 기능(비즈니스 도메인)별로 구성되어 있습니까, 아니면 기술 계층별로 구성되어 있습니까?
• 다른 항목을 건드리지 않고 폴더만 삭제하여 전체 기능을 삭제할 수 있나요?
• 기능에 비즈니스 도메인 이름(checkout, catalog) 또는 기술 이름(list, form, detail)이 있습니까?
• 모호한 이름을 가진 폴더가 있습니까: utils, helpers, common, misc, data?

shared/ 및 core/

• shared/에는 비즈니스 로직 없이 UI 구성요소와 유틸리티만 포함되어 있습니까?
• core/에는 싱글톤 인프라(인터셉터, 가드, 인증 서비스)만 포함되어 있습니까?
• shared/ 내에 비즈니스 로직이 포함된 서비스가 있나요?
• core/에 기능 구성 요소나 도메인 서비스가 있습니까?

서비스 및 제공업체

• 비즈니스 서비스가 귀하의 기능 내에 있습니까, 아니면 전 세계적으로 느슨합니까?
• 글로벌 제공업체가 20개 이상입니까?
• 루트 모듈 또는 app.config.ts이 기능 모듈을 직접(지연 없이) 가져오나요?
• 기능에 대해 로컬이어야 하는 providedIn: 'root' 서비스가 있습니까?

이름

• 파일 이름이 해당 파일의 기능을 정확히 말합니까?
• 앱의 어떤 부분에도 이름이 적용될 수 있는 파일이 있나요?
• app.service.ts, data.service.ts 또는 helper.service.ts이라는 파일이 있습니까?
• shared/은 개별 기능보다 더 중요합니까?

운동

GitHub에서 공개 Angular 프로젝트를 검색하세요. 자체 프로젝트이거나 오픈 소스 프로젝트일 수 있습니다. 파일을 열지 않고 폴더 구조와 이름만 보면 됩니다.

1. 기능 또는 기술 계층 중 어떤 조직 모델을 사용합니까?
2. 의심이나 의혹을 불러일으키는 이름은 무엇입니까?
3. 비즈니스 로직이 어디에 있다고 생각하시나요?
4. 어떤 폴더에 가장 많은 책임이 있다고 생각하시나요?
5. 다른 것을 건드리지 않고 기능을 삭제할 수 있나요?

세션에서 관찰한 내용을 공유하고 수석 건축가처럼 함께 검토해 보세요.

---

프롬프트: 4가지 포인트로 프로젝트를 분석하세요.

이 프롬프트를 복사하여 프로젝트의 폴더 트리에 전달하는 AI(ChatGPT, Claude, Copilot)와 함께 사용하세요.

---

Pillar 1의 이 4가지 포인트를 적용하여 프로젝트 아키텍처를 분석하고 보고서를 생성합니다.

POINT 1 — 폴더 구조

apps/ 및 libs/을 분석하고 답하세요.

• 조직은 기능별(비즈니스 도메인)별인가요, 아니면 기술 계층별인가요?
• 해당 폴더만 삭제하면 전체 기능을 삭제할 수 있나요?
• 기능에 도메인 이름(checkout, catalog) 또는 기술 이름(list, form, detail)이 있습니까?
• utils, helpers, common, misc, data와 같이 이름이 모호한 폴더가 있습니까?
• 발견한 실제 폴더 트리를 표시합니다.

POINT 2 — 파일 및 폴더 이름

전체 프로젝트 및 목록 검색:

• 이름이 모호한 파일: 내부 서비스가 포함된 data.service.ts, helper.service.ts, app.service.ts, main.component.ts, utils.
• shared/ 내의 비즈니스 로직을 갖춘 서비스.
• core/ 내의 구성요소 또는 도메인 서비스.
• shared/은 개별 기능보다 더 중요합니까? 파일 수.

포인트 3 — 글로벌 서비스

전체 프로젝트 검색:

• providedIn: 'root'이 있는 모든 서비스 — 서비스가 무엇인지, 기능에 대해 로컬이어야 하는지 여부를 나열합니다.
• 글로벌 공급자가 총 몇 명인지 계산합니다.
• 기능 내에 있어야 하는 경우 전역적으로 등록된 비즈니스 서비스를 식별합니다.
• libs/services/에서 특정 도메인에 분명히 속하는 서비스를 검색합니다.

포인트 4 — 전역 구성(app.config.ts 또는 app.module.ts)

각 앱의 루트 구성 파일을 찾아 분석합니다.

• 전 세계적으로 등록되어서는 안되는 것은 무엇입니까?
• 기능 모듈이 지연 로딩으로 로드됩니까, 아니면 직접 가져오나요?
• 글로벌 구성에 비즈니스 서비스가 있나요?
• 전 세계적으로 등록된 공급자는 총 몇 명입니까?

보고서 형식

각 점에 대해 다음과 같은 정확한 구조를 사용하십시오.

✅ 뭐가 좋은데?

(실제 코드 예제가 포함된 구체적인 목록)

⚠️ 확인해야 할 징후

(파일 경로와 그것이 기호인 이유가 포함된 구체적인 목록)

❌ 문제 해결

(파일 경로, 문제 및 실제 영향이 포함된 구체적인 목록)

결국에는 다음이 포함됩니다.

요약

4포인트, 상태 이모티콘(✅ ⚠️ ❌) 및 포인트별 결론 라인이 포함된 표입니다.

우선순위가 높은 다음 단계

터치할 파일 또는 폴더의 정확한 경로와 함께 영향에 따라 정렬된 최대 5개의 특정 작업 목록입니다.

직접적으로 말하세요. 특징이나 이론이 무엇인지 설명하지 마십시오. 이 특정 프로젝트를 분석하고 실제 결과를 제공하십시오.