learn

RUP (Rational Unified Process)란 무엇인가

RUP (Rational Unified Process)란 무엇인가

RUP는 Rational Software Corporation이 개발한 상업용 소프트웨어 개발 프로세스다. "Rational"이라는 이름은 회사명에서 왔지만, 우연히도 "합리적인"이라는 영어 단어와 일치하여 이중적인 의미를 갖게 되었다.

"Rational"이 붙은 이유

회사 이름

Rational Software Corporation이라는 회사가 개발한 프로세스이기 때문에 "Rational"이 붙었다.

  • 회사 설립: 1981년
  • 설립자: Paul Levy, Mike Devlin
  • 회사명의 의미: "합리적인, 이성적인" - 소프트웨어 개발을 더 과학적이고 체계적으로 만들겠다는 철학
  • 2003년 IBM에 인수되어 현재는 IBM Rational 브랜드로 존재

이중적 의미

  • 1차 의미: 회사 이름 (Rational Software)
  • 2차 의미: "Rational" = "합리적인, 이성적인"
  • 결과: "합리적인 통합 프로세스"라는 해석도 가능
  • 이 이중성은 우연이었지만, Rational Software의 브랜딩에 매우 효과적이었다

역사적 배경

Three Amigos의 등장

1990년대 중반, 객체지향 방법론 분야에서 세 명의 거장이 있었다:

  1. Grady Booch - Booch Method 개발자
  2. James Rumbaugh - OMT (Object Modeling Technique) 개발자
  3. Ivar Jacobson - OOSE (Object-Oriented Software Engineering) 개발자, Use Case 개념의 창시자

이들은 원래 서로 경쟁 관계였으나, 1995년 모두 Rational Software에 합류했다.

UML의 탄생 (1997)

Three Amigos가 함께 작업한 첫 번째 결과물:

  • Booch의 표기법 + Rumbaugh의 OMT + Jacobson의 Use Case
  • → UML (Unified Modeling Language)
  • "Unified"의 의미: 여러 방법론을 통합했다

RUP의 탄생 (1998)

UML을 만든 후, "이 모델링 언어를 어떻게 사용할 것인가?"에 대한 프로세스가 필요했다:

  • Jacobson의 Objectory Process를 기반으로
  • Booch와 Rumbaugh의 경험을 통합
  • → UP (Unified Process)
  • → Rational이 상업화하면서 RUP (Rational Unified Process)
Timeline:
1981: Rational Software 설립
1995: Three Amigos 합류
1997: UML 1.0 발표
1998: RUP 1.0 출시
2003: IBM이 Rational 인수

UP vs RUP

UP (Unified Process)

  • 공개 프로세스 프레임워크
  • 개념적 틀로서의 프로세스
  • 누구나 사용 가능
  • 핵심 아이디어와 원칙 제공
  • Larman 책에서 주로 다루는 것

RUP (Rational Unified Process)

  • Rational Software의 상업용 제품
  • UP를 구체화하고 확장한 버전
  • 수천 페이지의 상세한 문서, 가이드라인, 템플릿
  • 전용 도구와 통합 (Rational Rose, RequisitePro 등)
  • 라이선스 필요

비유

  • UP = Linux Kernel (개념과 기본 구조)
  • RUP = Red Hat Enterprise Linux (상용 제품)

UP는 기본 아이디어를 제공하고, RUP는 그것을 실제로 적용할 수 있는 구체적인 제품으로 만든 것이다.

RUP의 핵심 특징

1. 6가지 Best Practices

RUP가 강조하는 여섯 가지 모범 사례:

  1. Iterative Development (반복적 개발)

    • 한 번에 다 만들지 않고 점진적으로

  2. Manage Requirements (요구사항 관리)

    • 요구사항 추적과 변경 관리

  3. Component-Based Architecture (컴포넌트 기반 아키텍처)

    • 재사용 가능한 컴포넌트로 시스템 구성

  4. Visual Modeling (시각적 모델링)

    • UML을 통한 시각화

  5. Verify Quality (품질 검증)

    • 지속적인 테스팅과 품질 관리

  6. Control Changes (변경 통제)

    • 체계적인 변경 관리

2. 4차원 구조

RUP는 프로세스를 4가지 관점으로 정의한다:

  • 누가 (Who): 역할 (Role)

    • 예: Architect, Developer, Tester, Project Manager

  • 무엇을 (What): 산출물 (Artifact)

    • 예: Vision Document, Design Model, Source Code

  • 어떻게 (How): 활동 (Activity)

    • 예: Find Use Cases, Design Architecture, Implement Component

  • 언제 (When): 단계와 반복 (Phase & Iteration)

    • 예: Elaboration의 두 번째 iteration

이 네 가지를 매우 상세하게 정의하여 프로세스의 모든 측면을 커버한다.

3. 프로세스 자산

RUP는 다음을 포함한다:

  • Process Description: 수천 페이지의 프로세스 설명
  • Templates: 각종 문서 템플릿
  • Guidelines: 작업 수행 지침
  • Tool Mentors: 도구 사용 가이드
  • Examples: 샘플 프로젝트

Rational의 생태계 전략

Rational Software는 RUP만 판매한 것이 아니라 통합 도구 생태계를 구축했다:

주요 도구들

  1. Rational Rose

    • UML 모델링 도구
    • 코드 생성 및 리버스 엔지니어링

  2. Rational RequisitePro

    • 요구사항 관리 도구
    • Use Case 추적

  3. Rational ClearCase

    • 버전 관리 시스템
    • 대규모 팀 협업 지원

  4. Rational ClearQuest

    • 이슈 트래킹 및 변경 요청 관리

비즈니스 모델

방법론 (RUP) → 도구 필요성 → 도구 판매 → 컨설팅 → 교육

전형적인 엔터프라이즈 소프트웨어 생태계 전략이었다.

RUP의 장단점

장점

  1. 체계성

    • 모든 것이 명확하게 정의됨
    • 대규모 프로젝트에서 혼란 방지

  2. Best Practices 집약

    • 수십 년의 경험이 녹아있음
    • 검증된 접근법

  3. 도구 지원

    • 전용 도구로 프로세스 자동화
    • 추적성(Traceability) 확보

  4. 리스크 관리

    • 반복적 접근으로 리스크 조기 발견
    • unified-process-phases의 Elaboration에서 핵심 리스크 해결

단점

  1. 방대함

    • 너무 많은 문서와 산출물
    • 중소 프로젝트에는 과함
    • "Process Heavy"

  2. 복잡성

    • 학습 곡선이 가파름
    • 모든 역할과 활동을 이해하기 어려움

  3. 오해의 여지

    • "모든 것을 다 해야 한다"로 오해받기 쉬움
    • Rational의 의도: "필요한 것만 골라서 쓰세요 (Tailoring)"
    • 현실: "이거 다 해야 해?"

  4. 도구 종속성

    • Rational 도구에 Lock-in
    • 라이선스 비용 부담

RUP의 쇠퇴와 현재

2000년대: Agile의 부상

  • 2001: Agile Manifesto 발표
  • Scrum, XP 같은 경량 방법론 인기
  • RUP는 "너무 무겁다" (Heavy Process)는 비판

Agile vs RUP

| 측면 | RUP | Agile | |------|-----|-------| | 문서 | 방대함 | 최소한 | | 계획 | 상세한 사전 계획 | 적응적 계획 | | 프로세스 | 정형화 | 가벼움 | | 적합 규모 | 대규모 | 중소규모 |

현재 상황

  • IBM Rational 브랜드로 존재
  • 주로 대규모 엔터프라이즈, 정부, 국방 분야에서 사용
  • Agile과의 하이브리드 형태로 진화
  • "Disciplined Agile Delivery" 같은 후속 프레임워크로 발전

Larman 책과의 관계

Craig Larman은 RUP 공식 문서를 작성한 사람 중 하나다. 하지만 그의 책 "Applying UML and Patterns"에서는:

Larman의 접근

  • RUP의 핵심만 추출: 방대한 RUP를 실용적으로 축약
  • UP라는 용어 선호: 상업적 색채를 제거
  • 원리 중심: 구체적 도구보다는 핵심 아이디어
  • 실전 예제: 이론보다는 적용

Larman 책 = "RUP Lite"?

Larman의 책은:

  • RUP의 철학과 핵심 아이디어: O
  • RUP의 모든 문서와 프로세스: X
  • 실용적으로 적용 가능한 부분: O
  • 도구 독립적: O

핵심 정리

RUP의 발전 과정:

1981: Rational Software 설립
      ↓
1995: Three Amigos 영입
      ↓
1997: UML 통합 (Unified Modeling Language)
      ↓
1998: UP 개발 → RUP 상업화
      ↓
2003: IBM 인수
      ↓
현재: 대규모 엔터프라이즈에서 제한적 사용

"Rational"의 의미:

  1. 1차 의미: 회사 이름 (Rational Software Corporation)
  2. 2차 의미: "합리적인, 이성적인"이라는 영어 뜻
  3. 둘 다 맞는 해석이며, 이 이중성은 효과적인 브랜딩이 되었다

RUP의 유산:

  • 방법론 자체는 쇠퇴했지만
  • 반복적 개발, 아키텍처 중심, 리스크 주도 같은 핵심 아이디어는 여전히 유효
  • 현대 Agile 프랙티스에도 RUP의 DNA가 녹아있음
← learn 목록으로홈으로