소프트웨어 설계와 공학

좋은 소프트웨어 설계의 핵심은 "고치기 쉽고 다시 쓰기 쉬운 구조"다. 소프트웨어 공학은 이를 정해진 비용과 일정 안에서 믿을 만한 품질로 해내는 방법을 다룬다. 무엇을 만들지 정하는 요구공학, 어떻게 나눌지 정하는 분석·설계, 제대로 만들었는지 확인하는 테스트, 그리고 이 모두를 굴리는 프로젝트 관리와 형상 관리가 큰 축이다. 시험에서는 개발 과정의 틀(생명주기 모델, 방법론), 모듈 독립성, 디자인 패턴, 모델링 도구, 관리 기법(비용 산정, 형상 관리)으로 나눠 묻는다. 비용 산정·일정·위험 관리는 프로젝트 관리 노트에 있다.

개발 프로세스와 생명주기

프로세스는 고객 요구를 만족하는 제품을 만들려고 절차·방법, 도구·장비, 인력을 하나로 묶는 접착제다. "제품의 품질은 그것을 만드는 프로세스의 품질이 정한다"(Watts Humphrey)는 원칙 때문에, 계획을 세운다는 것은 곧 프로세스를 정의한다는 뜻이 된다. 단계마다 착수 기준(Entry), 할 일(Task), 검증 기준(Verification), 완료 기준(eXit)을 적어 프로세스를 정의하는 방법을 ETVX라고 한다.

어느 모델을 고르든 거치는 활동은 비슷하다. 모델은 이 활동을 한 번에 순서대로 밟느냐, 작게 여러 번 돌리느냐가 다를 뿐이다.

의사소통 → 요구사항 수집 → 타당성 분석 → 시스템 분석 → 설계 → 구현 → 테스트 → 통합 → 설치·배포 → 운영·유지보수

타당성 분석(feasibility study) 은 요구를 대략 모은 직후, 이 프로젝트를 할 가치가 있는지 판정하는 단계다. 기술적 타당성(지금 기술·인력으로 만들 수 있나), 경제적 타당성(비용 대비 이익이 남나), 운영적 타당성(만든 뒤 조직이 실제로 쓰고 유지할 수 있나)을 보고, 일정·법적 제약을 더하기도 한다. 여기서 아니라고 나오면 설계에 들어가기 전에 멈춘다.

생명주기 모델

접근 방식은 둘로 나뉜다. 빅뱅(Big Bang) 방식은 요구사항부터 테스트까지 한 번에 순서대로 밟고 끝에 한 번 배포한다. 진화적(Evolutionary) 방식은 요구·설계·구현·테스트를 작은 주기로 여러 번 돌린다. 영어권 교재에서 "빅뱅 모델"은 이 분류가 아니라 계획 없이 인력과 돈을 코딩에 몰아넣고 결과를 기대하는 모델을 가리키기도 한다. 요구가 불분명한 학습·실험용 작은 프로젝트에나 맞고, 아래 주먹구구식과 같은 부류다.

방법론: UP와 애자일

UP(Unified Process) 는 Jacobson·Booch·Rumbaugh가 만든 객체지향 방법론이다. 유스케이스로 요구를 분석하고, 아키텍처를 중심에 두며, 위험 관리를 중시하고, 반복적·점진적으로 개발한다. 시간 순서로 네 단계를 거치되 각 단계 안에서 요구·설계·구현·테스트가 모두 조금씩 일어난다는 점이 폭포수와 다르다.

애자일(Agile) 은 변경을 받아들이고 빠른 배포를 강조하는 반복적·점진적 방법이다. 2001년 애자일 선언문은 프로세스·도구보다 개인과 상호작용을, 포괄적 문서보다 동작하는 소프트웨어를, 계약 협상보다 고객 협력을, 계획 준수보다 변화 대응을 더 중시한다. 대표 방법론은 XP, 스크럼, FDD, 린, AUP이고, 공통 실천은 짧은 반복, 데일리 스탠드업, 유저 스토리, 페어 프로그래밍, 리팩토링, 지속적 통합, TDD, 회고다. 스크럼의 스프린트 회고는 주기가 끝날 때 무엇을 개선할지 돌아보고 기록하는 활동이다. 폭포수와 애자일을 고르는 기준은 애자일과 스프린트에 있다.

리팩토링은 동작은 바꾸지 않고 코드 구조를 개선하는 것이다. 중복 코드, 방대한 클래스, 장황한 메서드 같은 코드 스멜이 대상이다(리팩터링 원칙).

요구공학

요구사항은 문제를 풀기 위해 제품이 갖춰야 할 기능과 지켜야 할 제약이다. 기능적 요구사항은 시스템이 제공할 기능·서비스, 비기능적 요구사항은 성능·보안·신뢰성 같은 제약과 품질 속성이다. 설계는 요구사항(무엇을)을 어떻게 만들지 정하는 일이고, 테스트는 만든 것이 요구사항을 지키는지 확인하는 일이라, 요구사항이 흔들리면 뒤의 모든 산출물이 같이 흔들린다. 잘못된 요구사항을 운영 단계에서 고치는 비용은 분석 단계에서 고치는 비용의 수십 배 이상으로 불어난다.

고객 요구사항 하나가 제품 요구사항 여러 개로 갈라지는 것이 보통이다. 이 변환을 체계적으로 하는 공학적 방법이 요구공학이다.

flowchart LR
  subgraph dev["요구사항 개발"]
    direction LR
    el["추출<br>(후보)"] --> an["분석<br>(합의)"] --> sp["명세<br>(공식 문서)"] --> vf["검증<br>(일관성 확인)"]
  end
  subgraph mgmt["요구사항 관리"]
    direction TB
    cm["변경 관리"] ~~~ tr["추적 관리"]
  end
  dev --> bl["베이스라인"] --> mgmt

개발 쪽은 요구사항을 만드는 일이고, 관리 쪽은 합의한 요구사항이 프로젝트 끝까지 유지되게 하는 일이다.

요구사항 추출

1. 비즈니스 이해: 시장 동향과 현재 업무의 문제를 보고 개발 범위를 정한다.
2. 이해관계자 식별: 사용자, 발주 고객, 운영자뿐 아니라 경쟁사, 협력 업체, 관련 법규·표준도 이해관계자다.
3. 기대사항 수집: 인터뷰, 설문, 브레인스토밍, 마인드맵, 벤치마킹, 워크숍 중 기간·비용에 맞는 방법을 고른다.

이해관계자는 자기가 원하는 것을 정확히 말하지 못하는 경우가 많다. 한 가지 방법에 기대지 말고 여러 방법을 섞어 빈틈을 메운다. 사용자 조사 방법은 사용자 리서치에 있다.

요구사항 분석

• 전제 조건 식별: 고객이 이미 정해 둔 조건. 출시 시점, 대상 시장, 지켜야 할 법규, 기존 대비 개선 목표 같은 것들이다.
• 운용 시나리오 분석: 어떤 환경(오프라인, 저사양 단말, 야외)에서 어떤 모드(평상시, 점검 중, 장애 시)로 쓰이는지 정리한다.
• 기능·비기능 요구사항 분석: 시스템이 무엇을 하는지와 얼마나 잘 하는지를 나눈다.

모은 요구사항에는 우선순위를 붙인다. 흔히 쓰는 MoSCoW 분류는 Must have(없으면 출시할 수 없다), Should have(중요하지만 미뤄도 동작한다), Could have(있으면 좋다), Won't have this time(이번 범위에서 뺀다)이다. Must는 반드시 구현하고, Should는 이해관계자와 협상하며, Could와 Won't는 다음 배포로 넘긴다.

비기능 요구사항은 숫자로 쓴다. "빠르게 응답한다"는 검증할 수 없고, "사용자 요청의 95%를 2초 안에 응답한다"는 검증할 수 있다. 분석 방법은 데이터 흐름을 따라 하향식으로 쪼개는 구조적 분석과, 사용자 시나리오에서 출발하는 객체지향 분석(유스케이스)으로 나뉜다(아래 「소프트웨어 설계」).

요구사항 명세

분석 결과를 소프트웨어 요구사항 명세서(SRS) 로 정리한다. SRS의 목차는 IEEE 830(현재는 ISO/IEC/IEEE 29148이 대체)이 대표적이다. 외부 인터페이스(사용자·하드웨어·소프트웨어·통신), 기능 요구사항(정보 흐름, 프로세스 설명, 데이터 사전), 비기능 요구사항 순으로 구성한다. 표기법은 정형화 정도에 따라 셋으로 나뉜다.

자연어 명세의 모호함을 줄이는 간단한 방법이 EARS(Easy Approach to Requirements Syntax)다. 문장을 몇 가지 정해진 틀에 맞춰 쓴다.

틀에 맞추면 트리거, 조건, 기대 동작이 문장마다 드러나서 그대로 테스트 케이스가 된다.

요구사항 검증

요구사항 단계에는 아직 코드가 없으니 리뷰로 검증한다. 막연히 읽지 말고 기준별 체크리스트를 쓴다.

변경 관리와 추적

검증을 마친 요구사항은 베이스라인으로 확정하고(아래 「형상 관리」의 베이스라인과 같은 개념), 그 뒤의 변경은 반드시 절차를 거친다. 베이스라인 전의 수정은 아직 개발 중인 것이라 변경 관리 대상이 아니다.

flowchart LR
  rq["변경 요청<br>(고객·개발자)"] --> ia["영향 분석"] --> rv{"변경 심사"}
  rv -->|"승인"| ex["변경 실시"] --> ck["변경 확인"]
  rv -->|"반려"| rj["요청자에게 사유 회신"]

심사 때 보는 것은 변경의 난이도, 이미 만든 산출물(설계·코드·테스트)에 미치는 영향, 일정과 비용 안에서 가능한지다. "요구한 대로 만들었는데 고객은 다른 것을 기대했다"는 상황이 되풀이되면, 변경 요청을 대화로 처리하지 말고 이 흐름에 올린다.

추적 관리는 요구사항과 다른 산출물 사이의 연결을 기록해서, 하나가 바뀌면 영향을 받는 곳을 바로 찾게 한다. 수직 추적은 요구사항 → 설계 → 코드처럼 개발 단계를 따라 내려가고, 수평 추적은 V-모델의 같은 높이끼리(고객 요구사항 ↔ 인수 테스트, 요구사항 분석 ↔ 시스템 테스트) 잇는다. 보통 추적 매트릭스로 관리한다.

테스트가 없는 요구사항, 요구사항이 없는 코드가 매트릭스의 빈칸으로 드러난다.

공공SW 사업의 요구사항 분류

국내 공공 SW 사업의 제안요청서(RFP)는 요구사항을 정해진 유형과 코드로 나눠 쓴다. 「공공SW사업 제안요청서 작성을 위한 요구사항 상세화 실무 가이드라인」의 분류는 다음과 같다.

RFP를 읽거나 쓸 때 "SFR-012"처럼 붙은 ID가 이 코드다. 기능 요구사항만 사업마다 내용이 완전히 달라서 공통 항목 없이 상세화 수준을 정해 쓰고, 나머지 유형은 작성 항목이 어느 정도 정해져 있다. 기획서를 태스크로 쪼개는 실무 방식은 BDD·SDD로 기획서를 태스크로 나누기에 있다.

소프트웨어 설계

설계는 소프트웨어를 이루는 요소와 그 구조를 정하는 활동이고, 수준에 따라 둘로 나뉜다.

세 단계로 나누는 교재도 있다. 이때는 시스템을 상호작용하는 구성 요소로 보는 아키텍처 설계, 그것을 하위 시스템과 모듈, 모듈 간 상호작용으로 풀어 내는 상위(high-level) 설계, 모듈 내부의 논리 구조와 인터페이스를 정하는 상세 설계 순이다. 설계 산출물(설계서, 의사 코드, 논리 다이어그램)은 구현에 들어가기 전에 설계 리뷰나 정형 검증 도구로 확인한다. 설계 결함은 늦게 발견할수록 고치는 비용이 커진다.

아키텍처는 건물의 청사진 역할을 한다. 이해관계자 사이의 공통 의사소통 수단이 되고, 개발 조직의 구조와 일정·비용 예측에 영향을 주고, 변경이 생겼을 때 원인을 찾게 해 주고, 재사용할 구성 요소를 확보하는 수단이 된다. 무엇보다 비기능 요구(품질 속성)를 반영하는 자리다. 같은 기능이라도 모니터링 모듈을 따로 두느냐에 따라 신뢰성이 달라진다. 품질 속성의 표준 분류는 ISO/IEC 25010에, 아키텍처 스타일은 소프트웨어 아키텍처 패턴에 있다.

설계 원리

좋은 모듈은 정보 은닉, 높은 응집도, 낮은 결합도를 갖는다(아래 「모듈과 모듈 독립성」).

시스템을 나눠 가는 방향은 둘이다.

실제로는 어느 한쪽만 쓰지 않고 섞는다. 테스트에서 같은 두 방향으로 모듈을 붙여 가는 통합 순서는 통합 테스트에 있다.

구조적 방법과 객체지향 방법

객체지향 쪽 흐름은 아래 「UML로 하는 객체지향 분석·설계」에 있다. 함수 지향 설계는 DFD로 데이터 흐름을 그리고 그 위의 처리를 함수로 나누므로, 상태가 중요하지 않고 입력을 출력으로 바꾸는 시스템에 잘 맞는다. 함수가 전역 상태를 바꾸면 다른 모듈이 영향을 받는다는 약점이 있어서, 상태가 중요한 도메인은 상태와 동작을 객체로 묶는 객체지향 설계가 낫다.

사용자 인터페이스 설계

사용자에게 시스템은 곧 화면이다. 기능이 맞아도 쓰기 어려우면 받아들여지지 않으므로, 인터페이스 요구(쉬운 탐색, 일관된 요소, 빠른 응답, 피드백, 도움말, 합리적인 기본값)도 요구사항으로 다룬다. 설계 원칙으로 가장 많이 인용되는 것이 Ben Shneiderman의 인터페이스 설계 8가지 황금률이다.

화면을 평가할 때 쓰는 닐슨의 10가지 휴리스틱과 사용성 테스트는 사용자 리서치에 있다.

구조적 분석과 설계

구조적 방법론은 데이터가 어디서 들어와 어떻게 바뀌어 어디로 나가는지를 기준으로 시스템을 위에서 아래로 쪼갠다.

아래에서는 주차장 차단기 제어 소프트웨어를 예로 단계를 따라간다.

시스템 문맥도: 경계를 긋는다

만들 소프트웨어 전체를 프로세스 하나(번호 0) 로 두고, 주고받는 외부 개체(터미네이터)와 정보 흐름만 그린다. 목적은 범위 확정이다.

flowchart LR
  sensor["차량 감지 센서"] -->|"차량 진입"| p0(("차단기 제어 0"))
  cam["번호판 카메라"] -->|"번호판 정보"| p0
  timer["타이머"] ==>|"주기 신호"| p0
  p0 -->|"개폐 명령"| motor["차단기 모터"]
  p0 -->|"안내 문구"| board["전광판"]

정보 흐름은 값이 중요한 데이터 흐름(번호판 문자열)과, 언제 일어났는지가 중요한 제어 흐름(타이머 인터럽트, 차량 진입 신호)으로 나뉜다. 문맥도 옆에는 흐름마다 의미와 값의 형태, 주기를 표로 적는다(예: "차량 진입: True/False, 센서 인터럽트로 입력").

데이터 흐름도: 개발자가 이해할 때까지 쪼갠다

문맥도의 프로세스 0을 1, 2, 3으로, 다시 1.1, 1.2로 나눈다. 기호는 데이터 프로세스, 제어 프로세스, 데이터 흐름, 제어 흐름, 데이터 저장소다. 한 프로세스가 출력을 여러 개 내보내면 아직 덜 쪼갠 것으로 보고 더 나눈다.

flowchart LR
  in1["번호판 정보"] --> p11(("1.1 번호판 인식"))
  in2["차량 진입"] --> p12(("1.2 센서 입력"))
  p11 -->|"차량 번호"| p13(("1.3 출입 판정"))
  p12 -->|"진입 여부"| p13
  p13 -->|"개폐"| p21(("2.1 모터 제어"))
  p13 --- ds[("등록 차량 목록<br>(데이터 저장소)")]

최하위 프로세스에는 역할 유형과 실행 유형을 붙인다.

데이터 사전과 프로세스 명세

데이터 사전은 DFD에 나온 데이터의 이름, 설명, 값의 범위를 정의한다.

프로세스 명세는 최하위 프로세스마다 쓴다. 데이터 프로세스는 자연어로, 제어 프로세스는 상태 머신으로 쓴다.

프로세스 ID  1.2 센서 입력
유형        Periodic Device
입력        센서 값, 타이머 신호
출력        진입 여부 (→ 1.3 출입 판정)
처리        1. 10ms마다 센서 값을 읽는다.
            2. 세 번 연속 감지되면 진입 여부를 True로 보낸다.

상태 머신의 전이는 이벤트(파라미터) [조건] / 행위로 쓴다.

stateDiagram-v2
  direction LR
  state "닫힘" as closed
  state "열림" as opened
  closed --> opened : 판정(결과) [결과 = 허가] / "모터 열기"
  opened --> closed : 진입 여부(값) [값 = False] / "모터 닫기"

태스크 모델과 모듈 구조

태스크는 운영체제가 따로 스케줄하는 실행 단위(스레드)다. DFD의 프로세스를 그대로 태스크로 만들면 너무 많아지므로 세 단계로 줄인다.

1. 태스크 후보 식별: 혼자 돌아야 하는 프로세스(Asynchronous, Periodic, Control)를 후보로 뽑는다.
2. 잔여 프로세스 할당: 후보가 되지 못한 프로세스(Synchronous, Function)를 앞뒤로 이어 실행되는(절차적 응집) 후보에 붙인다.
3. 태스크 통합: 시간 제약을 어기지 않는 선에서, 같은 타이머로 깨어나는 태스크끼리(시간적 응집) 합친다.

입력이 연달아 들어와도 잃으면 안 되는 태스크 사이에는 비동기 메시지(큐) 를 쓴다. 각 태스크가 어느 프로세스를 품고 있는지는 추적 관계로 남겨 둔다.

모듈은 구현 단위다. C라면 .c/.h 파일 하나이거나 그 묶음인 디렉터리다. 태스크를 모듈로 옮기고, 여러 모듈이 같이 쓰는 기능은 라이브러리 모듈로 뽑고, 함수 호출 관계로 모듈 간 의존을 그린 뒤, 모듈마다 ID·이름·설명·인터페이스를 적는다.

모듈 ID   PK_001        모듈명  출입 판정
설명      번호판과 센서 입력을 종합해 출입 허가 여부를 정한다
인터페이스 Decide_Entry(): 허가 여부를 반환한다

공통 기능을 라이브러리로 뽑으면 재사용은 좋아지지만 의존하는 모듈이 늘어 결합도가 올라갈 수 있다. 어느 쪽이 나은지는 매번 저울질한다.

구조 차트

구조 차트는 모듈 안의 함수 호출 관계와 파라미터 이동을 계층으로 그린다. 위의 상자가 아래 상자를 호출하고, 화살표 옆에 넘기는 데이터를 적는다. 일반 호출, 비동기 호출, 반복, 조건 같은 기호가 있다.

flowchart TD
  de["Decide_Entry()"] -->|"차량 번호"| rp["Read_Plate()"]
  de -->|"진입 여부"| rs["Read_Sensor()"]
  rp --> np["Normalize_Plate()"]
  rs --> db["Debounce_Signal()"]

모듈 구조를 바탕으로 DFD의 흐름을 호출 구조로 옮긴 초기 구조 차트를 그리고, 기능을 더 쪼개고 공통 기능을 뽑아 최종본으로 다듬는다. 여기까지 오면 함수 이름과 시그니처가 거의 정해져서 바로 코딩으로 넘어갈 수 있다.

모듈과 모듈 독립성

모듈은 성능 향상과 수정·재사용 편의를 위해 기능 단위로 나눈 부분이다. 모듈 독립성은 결합도는 약하게, 응집도는 강하게, 크기는 작게 할수록 높아진다.

결합도와 응집도

• 결합도(Coupling): 모듈 간 의존 정도, 약할수록 좋다. 약한 순서로 자료 → 스탬프 → 제어 → 외부 → 공통 → 내용. 단계별 설명은 결합도를 낮추는 전략에 있다.
• 응집도(Cohesion): 모듈 내부 요소의 관련 정도, 강할수록 좋다. 강한 순서로 기능적 → 순차적 → 교환적 → 절차적 → 시간적 → 논리적 → 우연적. 단계별 설명은 응집도를 높이는 전략에 있다.

Fan-in / Fan-out

Fan-in은 어떤 모듈을 호출하는 상위 모듈 수(높으면 재사용성이 좋다), Fan-out은 어떤 모듈이 호출하는 하위 모듈 수다.

복잡도 척도

"측정할 수 없으면 통제할 수 없다"(Tom DeMarco). 소프트웨어 척도(metric)는 규모(LOC, 기능 점수), 복잡도, 품질(단계별 결함 수, 출시 후 고객이 보고한 결함 수), 프로세스, 자원(공수, 시간)을 수치로 나타낸다. 모듈의 복잡도를 재는 대표 척도는 둘이다.

McCabe 순환 복잡도(Cyclomatic Complexity, 1976) 는 제어 흐름 그래프에서 선형 독립 경로의 수를 센다. 판단문(if, while, for, case, &&·||)이 많을수록 커진다.

V(G) = E - N + 2      E: 간선 수, N: 노드 수 (연결된 그래프 하나)
V(G) = P + 1          P: 판단 노드(분기 조건) 수
V(G) = 닫힌 영역 수 + 1   평면 그래프로 그렸을 때

간선 10개, 노드 8개면 10 - 8 + 2 = 4다. 이 값은 모든 독립 경로를 한 번씩 지나는 데 필요한 테스트 케이스 수의 상한이 되어, 화이트박스 테스트의 기본 경로 수로 쓰인다. 모듈당 10 이하가 흔한 권장 기준(McCabe)이고, 넘으면 함수를 나눈다. 정적 분석 도구와 린터(ESLint complexity, SonarQube)가 자동으로 잰다.

Halstead 척도(1977) 는 프로그램을 연산자와 피연산자 토큰의 나열로 보고 소스 코드에서 정적으로 계산한다.

같은 기능을 짧은 어휘로 표현할수록 부피와 노력이 작다. 두 척도 모두 "읽기 어려운 코드"를 숫자로 찾아내는 신호일 뿐, 숫자를 맞추려고 코드를 쪼개는 것이 목적이 되면 안 된다.

계층과 API

함수가 수십만 개로 늘면 함수 단위로도 관리가 안 된다. 관련 함수와 변수를 객체로 묶고, 객체 안에 다시 객체를 넣어 계층을 만든다. 자동차 소프트웨어라면 Car 안에 Engine, 그 안에 CruiseControl·IgnitionControl이 들어가고, 호출은 car.engine.cruiseControl.setSpeed(55)처럼 바깥에서 안으로 내려간다. 팀도 이 경계를 따라 나눈다.

다른 팀이 만든 모듈을 쓸 때 기댈 것은 문서와 API(Application Programming Interface) 다. API는 모듈이 밖에 공개하는 함수와 데이터의 목록이다. IgnitionControl은 setRPM()을 public으로 열어 크루즈 컨트롤이 부를 수 있게 하고, 점화 플러그를 직접 점화하는 함수는 private으로 닫아 자기 안에서만 부른다. 필요한 것만 골라 공개하는 것이 정보 은닉이다. 내부를 바꿔도 API가 같으면 쓰는 쪽은 고칠 것이 없으므로, 정보 은닉은 결합도를 낮추는 실제 수단이 된다.

디자인 패턴 (GoF)

GoF 패턴 23개는 목적에 따라 생성(객체를 만드는 방식: Singleton, Factory Method, Builder 등), 구조(객체를 조합하는 방식: Adapter, Decorator, Proxy 등), 행위(객체가 협력하고 책임을 나누는 방식: Observer, Strategy, Template Method 등)로 나뉜다. 패턴별 비유·푸는 문제와 헷갈리는 짝은 GoF 디자인 패턴에 있다.

객체지향

• 구성 요소: 객체(데이터 + 메서드), 클래스(공통 속성·연산을 가진 객체의 틀, 객체는 클래스의 인스턴스), 메시지(객체 간 상호작용 수단)
• 기본 원칙: 캡슐화, 정보 은닉, 상속, 추상화, 다형성
• 럼바우(OMT) 분석 기법: 객체 → 동적 → 기능 모델링 순서
  • 객체(정보) 모델링: 객체 다이어그램, ERD. 구조를 나타낸다
  • 동적 모델링: 상태 다이어그램. 시간에 따른 변화를 나타낸다
  • 기능 모델링: 자료 흐름도(DFD). 입력이 출력으로 바뀌는 과정을 나타낸다

UML

UML(Unified Modeling Language)은 객체지향 분석·설계의 결과를 그림으로 기록하는 표준 표기다. UML의 그림은 객체지향 개념을 옮긴 것이므로 객체지향 개념을 먼저 알아야 읽힌다.

현재 표준은 다이어그램 14종을 정의한다. 구조 7종(클래스, 객체, 패키지, 컴포넌트, 복합체 구조, 배치, 프로파일)과 행위 7종(유스케이스, 활동, 시퀀스, 상태, 커뮤니케이션, 상호작용 개요, 타이밍)이다. 다이어그램은 정적인 구조와 동적인 행위로 나뉜다. 유스케이스 다이어그램 작성법과 유스케이스 명세는 유스케이스 다이어그램에 있다.

구조 다이어그램

행위 다이어그램

관계

관계 기호는 결국 코드 모양의 차이다.

class Post {
  private comments: Comment[] = [];          // 연관 (Post 1 ── 0..* Comment)
}
 
class Comment {
  private meta = new CommentMeta();          // 합성: 직접 생성
  constructor(private author: Member) {}     // 집합: 밖에서 받은 Member를 공유
}
 
class CommentCtrl {
  register(form: CommentForm) { /* ... */ }  // 의존: 파라미터로만 사용
}

클래스 다이어그램 표기

클래스 다이어그램은 업계 전반에서 설계를 공유할 때 널리 쓰는 UML이다. 관계 표기는 위 표와 같고, 나머지 구성 요소는 다음과 같다.

연관은 기본이 양방향이다. 두 클래스가 서로의 존재와 관계를 안다. 한쪽만 상대를 알면 단방향 연관이고, 아는 쪽에서 모르는 쪽으로 화살표를 그린다. 항공 예약 시스템으로 보면 다음과 같다.

클래스 다이어그램은 객체지향 언어로 바로 옮겨지는 유일한 UML이라 가장 널리 쓴다. 쓰임은 애플리케이션의 정적 구조 분석·설계, 시스템 책임 기술, 컴포넌트·배치 다이어그램의 기반, 코드 생성(순공학)과 코드에서 다이어그램 복원(역공학)이다. 면접 사례에 적용한 예는 객체 지향 설계 면접에 있다.

GoF 패턴 대부분이 클래스 다이어그램으로 설명된다(GoF 디자인 패턴).

UML로 하는 객체지향 분석·설계

다이어그램을 어떤 순서로, 무엇에서 무엇을 뽑아 그리는지가 실제 설계 과정이다.

flowchart LR
  uc["유스케이스 다이어그램·명세<br>(요구사항 분석)"] --> cls["클래스 다이어그램<br>(구조 설계)"] --> beh["시퀀스·활동·상태 머신<br>(동작 설계)"]
  cls --> cmp["컴포넌트·패키지·배치<br>(묶음과 물리 구성)"]

화살표는 한 방향이 아니다. 시퀀스 다이어그램을 그리다 클래스에 없던 메서드가 나오면 클래스 다이어그램으로 돌아가 고친다. 모든 단계가 반복하며 정제하는 과정이다. 아래 예는 블로그의 「댓글 작성」 유스케이스다(명세는 유스케이스 명세).

1. 클래스 식별: 명사 추출. 명세에서 명사를 모두 뽑고(회원, 댓글, 입력창, 내용, 스팸, 목록, 이미지…), 시스템 경계 밖(회원, 스팸 필터 서비스는 액터), 중복(내용은 댓글의 일부), 너무 추상적인 것을 걸러 낸다. 남은 후보를 역할에 따라 세 스테레오타입으로 나눈다.

명세에 직접 나오지 않아도 화면과 데이터 사이에서 로직을 맡을 제어 클래스는 새로 만들어 넣는 경우가 많다. 이 구분은 MVC나 계층형 아키텍처의 뼈대와 거의 같다. 책임을 나누는 기준은 책임 주도 설계에 있다.

2. 속성과 행위: 명사와 동사. 속성은 클래스에 남은 명사에서(Comment는 내용, 작성자, 작성 시각), 행위는 명세의 동사에서 뽑는다("입력창을 펼친다"는 CommentUI, "스팸 여부를 확인한다"는 CommentCtrl). 메시지 내용만 다른 같은 동작은 하나로 합친다. "오류 문구를 보여 준다"와 "안내 문구를 보여 준다"는 showMessage(text) 하나다.

3. 시퀀스 다이어그램: 메시지의 시간 순서. 참여 객체(생명선)를 가로로 놓고, 위에서 아래로 시간이 흐르며 주고받는 메시지를 그린다. 객체가 일하는 구간은 긴 사각형(활성화)으로 표시하고, 메시지는 동기(채운 화살촉), 비동기(열린 화살촉), 반환(점선)으로 나뉜다.

sequenceDiagram
  actor M as 회원
  participant UI as :CommentUI
  participant C as :CommentCtrl
  participant S as :SpamFilterClient
  participant D as :Comment
  M->>UI: 등록 클릭
  UI->>C: register(form)
  C->>S: check(body)
  S-->>C: ok
  C->>D: save()
  C-->>UI: 목록

조건과 반복은 결합 단편(combined fragment) 상자로 감싼다. opt는 if, alt는 if / else, loop는 for·while, break는 조건이 참이면 나머지를 건너뛰고 빠져나가기, par는 동시 실행, strict는 적힌 순서 강제다. 그리다 보면 "스팸이면?" 같은 빠진 흐름과 새 메서드가 나오고, 이것을 클래스 다이어그램에 돌려 반영한다.

4. 활동 다이어그램: 실행 흐름. 업무 프로세스, 유스케이스 흐름, 메서드의 알고리즘을 순서도처럼 그린다.

결정·병합은 "둘 중 하나", 분기·결합은 "둘 다 동시에"다. 이 차이를 헷갈리면 병렬 처리를 순차로 그리게 된다.

활동 다이어그램과 시퀀스 다이어그램은 둘 다 흐름을 그리지만 보는 것이 다르다.

5. 상태 머신 다이어그램: 한 객체의 일생. 상태가 복잡하게 바뀌는 대상(주문, 결제, 장비)을 골라 상태와 전이를 그린다. 전이 라벨은 구조적 방법의 상태 머신과 같은 이벤트(파라미터) [조건] / 행위이고, 조건에 따라 여러 전이 중 하나를 고르는 지점은 선택(choice) 노드로 그린다.

stateDiagram-v2
  direction LR
  state "작성 중" as draft
  state "게시됨" as posted
  state "숨겨짐" as hidden
  state "삭제됨" as deleted
  [*] --> draft
  draft --> posted : 등록(body) [body ≠ ""] / 저장
  posted --> hidden : 신고(n) [n ≥ 5] / 숨김 처리
  hidden --> deleted : 삭제() / 기록

6. 묶음과 물리 구성.

프로젝트 관리

프로젝트는 유일한 결과물을 만드는 일시적인 활동이고, 프로젝트 관리는 품질·비용·일정 목표를 지키려고 범위를 WBS로 쪼개고, 비용을 산정하고, 일정을 잡고, 진척을 수치로 통제하고, 위험을 미리 다루는 일이다. 참고 틀(PMBOK, ISO/IEC/IEEE 12207)과 CMMI 성숙도 5단계, 비용 산정 기법(델파이, LOC, COCOMO 모드별 계수, Putnam, 기능 점수 가중치와 보정 공식), PERT 주 경로 계산, EVM 지표, 위험의 식별·분석·대응(회피·완화·전가·수용)은 소프트웨어 프로젝트 관리: 비용 산정·일정·위험에 따로 정리했다.

유지보수와 재공학

소프트웨어는 배포 뒤에도 환경·법규·사용자 요구가 바뀌어 계속 고쳐야 한다. 여러 조사에서 유지보수 비용은 생명주기 전체 비용의 절반 이상(조사에 따라 60~70%대)으로 나온다. 오래된 하드웨어·언어에 묶인 구조, 기록되지 않은 변경, 땜질식 수정이 이 비용을 키운다.

유지보수의 네 유형

유지보수 작업도 작은 개발 주기다. ISO/IEC/IEEE 14764(옛 IEEE 1219)는 변경 요청 식별·분류 → 영향·비용 분석 → 설계 → 구현(단위 테스트 병행) → 시스템 테스트(회귀 테스트 포함) → 인수 테스트 → 배포 순서를 두고, 전 과정을 형상 관리로 묶는다.

Lehman의 소프트웨어 진화 법칙

Lehman은 소프트웨어를 셋으로 나눴다.

대부분의 업무 시스템인 E형에 대해 여덟 가지 법칙을 제시했다. 자주 인용되는 것은 다음 다섯이다.

나머지는 자기 조절(진화 과정의 측정치가 일정한 분포를 따른다), 조직 안정성(평균 작업률이 수명 내내 비슷하다), 피드백 시스템(다단계 피드백 시스템으로 다뤄야 한다)이다. 「복잡도 증가」가 예방 유지보수와 리팩터링이 필요한 이유이고(소프트웨어 복잡성), 「친숙성 유지」가 큰 변경을 작게 나눠 배포하는 이유다.

재공학과 역공학

기능은 그대로인데 기술이 낡아 유지보수가 어려워진 레거시 시스템은 재공학(re-engineering) 으로 되살린다. 어셈블리로 짠 Unix를 C로 다시 쓴 것이 고전적인 예다.

대상 결정 → 역공학(코드에서 설계·명세 복원) → 프로그램 재구조화 → 데이터 재구조화 → 순공학(복원한 명세로 새 시스템 구현)

재공학의 다른 축은 재사용이다. 응집도가 높고 결합도가 낮은 컴포넌트는 애플리케이션 전체, 하위 시스템, 모듈 수준에서 다시 쓸 수 있고, 이를 체계화한 것이 컴포넌트 기반 소프트웨어 공학(CBSE)이다. 요구사항 명세 → 설계 → 컴포넌트 명세 → 저장소에서 맞는 컴포넌트 검색 → 조립 순으로 진행하며, 맞는 컴포넌트가 없으면 요구를 컴포넌트에 맞추거나 컴포넌트를 고친다.

형상 관리 (SCM)

형상(configuration) 은 요구사항 명세서, 설계서, 소스 코드, 테스트 명세서처럼 개발 과정에서 나온 산출물들의 구성이다. 형상 관리는 이 산출물(형상 항목)을 식별하고 변경을 통제하며 처리 상태를 지켜보는 활동이고, 목표는 산출물의 무결성(승인된 것만 들어 있다)과 추적성(누가 언제 왜 바꿨는지 안다)이다. 형상 관리가 없으면 실수로 덮어쓴 작업을 되살리기 어렵고, 복사본 중 무엇이 최신인지, 버그가 어느 버전에 있는지, 고객이 어떤 수정이 들어간 버전을 가졌는지 알 수 없다.

베이스라인

베이스라인(baseline, 기준선) 은 공식 검토와 합의를 거쳐 개발의 기초가 된 상태로, 이후에는 형상 통제 절차로만 바꿀 수 있다. 보통 개발 단계나 마일스톤마다 잡는다. 요구 분석이 끝나면 요구사항 명세서가, 설계가 끝나면 아키텍처·상세 설계서가 더해지는 식으로 단계마다 베이스라인에 들어가는 항목이 늘어난다.

형상 관리 활동

정보처리기사는 여기에 버전 제어(여러 버전의 형상 항목 관리)를 따로 세고, 상태 보고를 형상 기록(식별·통제·감사 결과를 기록·보고)이라고 부르기도 한다. 변경 요청부터 확인까지의 흐름은 위 「변경 관리와 추적」의 요구사항 변경 절차와 같다. 실무에서는 Git·SVN 저장소로 항목과 버전을, Jira·Redmine 같은 이슈 시스템으로 변경 요청과 심사를 관리한다(Git 기초).

버전 관리의 기본 동작

동시 수정을 다루는 방식은 둘이다. 옛 중앙 집중식 도구는 파일을 체크아웃한 사람만 고치도록 잠근다(lock-modify-unlock). Git과 SVN의 기본 방식은 각자 고친 뒤 병합한다(copy-modify-merge). 어느 쪽이든 공유하는 주 브랜치는 늘 빌드되고 돌아가야 하므로 깨진 코드를 커밋하지 않는다.

CASE 도구

CASE(Computer-Aided Software Engineering) 는 생명주기 활동을 자동화하는 도구다. 산출물을 한곳에 모으는 중앙 저장소(명세, 다이어그램, 보고서, 데이터 사전)를 중심에 두고, 어느 단계를 돕느냐로 나눈다.

용도별로는 다이어그램, 프로세스 모델링, 프로젝트 관리(일정·공수·자원), 문서화(Doxygen 같은 API 문서 생성기), 분석(다이어그램의 불일치·누락 검사), 형상·변경 관리(Git), 프로그래밍(IDE), 프로토타이핑, 웹 개발, 품질 보증 도구가 있다. 도구가 단계 사이의 일관성을 검사해 결함을 다음 단계로 넘기기 전에 잡는 것이 핵심 이점이고, 도입·교육 비용과 도구에 프로세스가 묶이는 것이 비용이다. RAD 모델이 짧은 주기를 낼 수 있는 것도 이런 도구 덕분이다.

정리

• 생명주기 모델은 빅뱅(폭포수·V)과 진화적(반복적·원형·나선형·RAD·UP·애자일)으로 나뉜다. 시작 전에 기술·경제·운영 타당성을 본다.
• 요구공학은 추출 → 분석 → 명세 → 검증으로 만들고, 베이스라인 이후의 변경은 영향 분석과 심사, 추적 매트릭스로 지킨다. 비기능 요구는 숫자로, 자연어 명세는 EARS 틀로 쓴다.
• 구조적 방법은 문맥도 → DFD → 태스크·모듈 → 구조 차트로, 객체지향 방법은 유스케이스 명세 → 클래스(명사·동사, 경계·제어·실체) → 시퀀스·활동·상태 머신으로 내려간다.
• 모듈은 결합도를 낮추고 응집도를 높이며, 정보 은닉이 그 수단이다. 복잡도는 McCabe 순환 복잡도(E - N + 2, 10 이하 권장)와 Halstead 척도로 잰다.
• 인터페이스는 일관성, 피드백, 오류 방지, 되돌리기, 기억 부담 줄이기 같은 황금률로 설계한다.
• 프로젝트 관리는 WBS로 쪼개고 COCOMO·FP로 산정하고 PERT·EVM으로 일정과 비용을 통제하는 일이다. 계산법은 소프트웨어 프로젝트 관리에 있다.
• 유지보수는 수정·적응·완전화·예방으로 나뉘고 생명주기 비용의 절반 이상을 차지한다. E형 소프트웨어는 계속 변하고 복잡해지므로(Lehman), 낡은 시스템은 역공학 → 재구조화 → 순공학으로 재공학한다.

관련 노트: 소프트웨어 프로젝트 관리: 비용 산정·일정·위험, 추상 클래스와 인터페이스, 객체 지향의 본질: 메시징, 소프트웨어 테스트, 유스케이스 다이어그램, 객체 지향 설계 면접, 소프트웨어 안전, 소프트웨어 복잡성, 새 서비스 개발 프로젝트 진행 순서, Git 기초