IEEE 표준 결함 유형과 통합 테스팅의 타겟

IEEE Standard Classification(1993)에 따르면 소프트웨어 결함은 여러 가지로 분류되는데, 테스트 단계별로 타겟팅하는 결함이 다르다.

1. 단위 테스팅(Unit Testing)의 타겟

주로 화이트박스 및 데이터 흐름 테스팅을 통해 내부 로직 결함(Logic Faults), 계산 결함(Computation Faults), 데이터 결함(Data Faults) 등을 잡아냅니다.

2. 통합 테스팅(Integration Testing)의 타겟

모듈들이 결합될 때 발생하는 '인터페이스 결함(Interface Faults)'을 찾아내는 데 집중한다.

인터페이스 결함의 구체적 종류

• 타이밍 오류 (I/O timing)
• 잘못된 프로시저 호출 (Call to wrong procedure)
• 존재하지 않는 프로시저 호출 (Call to nonexistent procedure)
• 파라미터 불일치 (Parameter mismatch (type, number))
• 호환되지 않는 타입 (Incompatible types).

Interface testing

Interface testing의 목적은 모듈 간 인터페이스의 직접적인 오류나, 인터페이스에 대한 잘못된 가정(Invalid assumptions)으로 인해 발생하는 결함을 감지하는 것이다.

1) Interface misuse (인터페이스 오용 / 잘못된 사용)

호출하는 컴포넌트(Calling component)가 다른 컴포넌트를 호출할 때 인터페이스 사용에 물리적/구문적 실수를 하는 경우를 말한다.

주로 시스템이 정해둔 규칙을 개발자가 코딩 과정에서 단순하게 틀리게 작성한 경우를 말한다. 가장 흔한 예시로 파라미터(매개변수)의 순서를 뒤바꿔서 전달하거나, 정수(int)를 넣어야 할 자리에 문자열(string)을 넣는 등의 실수가 여기에 해당한다.

2) Interface misunderstanding (인터페이스 오해 / 잘못된 이해)

호출하는 컴포넌트가 호출받는 컴포넌트의 동작 방식에 대해 부정확하고 잘못된 가정(Assumptions)을 내포하고 있는 경우를 말한다.

파라미터의 타입이나 순서는 맞아서 프로그램 자체는 에러 없이 돌아가지만, 그 안의 '의미(논리)'를 서로 다르게 해석하여 발생하는 문제를 생각해볼 수 있다.

대표적인 사례로 NASA의 화성 기후 궤도선 폭발 사고(Mars Climate Orbiter Accident)가 있다. 이 사고는 록히드 마틴은 '파운드' 단위로 데이터를 넘겼는데, NASA는 이를 '미터법(뉴턴)' 단위일 것이라고 '잘못된 가정'을 한 채로 모듈을 결합했다가 우주선이 폭발해버린 사례이다.

3) Timing errors (타이밍 오류)

호출하는 컴포넌트와 호출받는 컴포넌트의 작동 속도(Speed)가 달라서, 오래된(Out-of-date) 정보에 접근하게 되는 문제를 말한다.

두 개 이상의 모듈이 동시에 실행되는 환경(특히 실시간 시스템이나 병렬 처리 시스템)에서 주로 발생한다. 예를 들어, 모듈 A가 새로운 센서 값을 아직 데이터베이스에 업데이트(저장)하지도 않았는데, 모듈 B가 한발 앞서서 데이터베이스를 읽어버려 과거의 낡은 값을 바탕으로 잘못된 제어 명령을 내리는 동기화 문제가 이에 해당한다.

4) 사례 : 화성 기후 궤도선 사고 (Mars Climate Orbiter Accident)

1998년 12월에 발사된 338kg의 로봇 우주 탐사선이 41주 동안 4억 1,600만 마일을 날아간 후 1999년 9월에 완전히 실종(파괴)되었다.

사고 원인 (의사소통 및 인터페이스 오류)

스템을 공동 개발한 NASA와 록히드 마틴(Lockheed) 간의 의사소통 오해 때문에 발생했으며, 한쪽(록히드 마틴)은 파운드(Pound Unit) 단위를 사용하여 추력 데이터를 계산해 넘겼고 다른 한쪽(NASA)은 이를 뉴턴(Newton Metric Unit) 미터법 단위로 착각하여 받아들였다.

즉, 개별 모듈(단위)은 완벽하게 작동했을지라도, 모듈 간 데이터를 주고받는 인터페이스 단계에서 단위(Type)에 대한 잘못된 가정을 테스트로 걸러내지 못해 막대한 비용이 투입된 우주선이 폭발해버린 통합 결함의 대표적 사례이다.

Integration Testing(통합 테스팅)

개별 모듈들이 결합되었을 때 모듈 간의 상호작용(Interactions among modules)이 올바르게 일어나는지에 초점을 맞춘다. 통합 테스팅은 명세서(Specification)를 바탕으로 테스트 케이스를 도출하는 블랙박스 테스팅(Black-box testing)으로 수행되어야 한다.

결함이 발생했을 때 오류의 정확한 위치를 파악(Localising errors)하는 것이 어려움으로 작용하고 이를 해결하는 방법으로는 점진적 통합 테스팅(Incremental integration testing) 이 존재한다. 이는 모든 모듈을 한 번에 결합하지 않고 점진적으로 추가하는 방식이다.

통합 테스팅은 아래의 네가지 접근법을 가진다.

1. Big Bang (빅뱅 통합) 2. Decomposition-based integration (분해 기반 통합) 3. Call Graph-based integration (호출 그래프 기반 통합) 4. Path-based integration (경로 기반 통합)

점진적 통합 테스팅 (Incremental Integration Testing)

한 번에 모듈을 다 합치는 것이 아니라 단계별로 묶어서(Sequence) 테스트하는 방식으로, 자료의 다이어그램(A, B, C, D 모듈 결합)을 통해 이를 명확히 보여준다.

총 3가지의 Test Sequence로 나눠서 테스트를 수행하는 것을 예시로 설명하자면, Test Sequence 1 모듈 A와 B를 결합하여 먼저 테스트(T1, T2, T3)를 수행한다. Test Sequence 2 앞서 결합된 A, B 시스템에 모듈 C를 추가 결합하여 테스트(T1, T2, T3, T4)를 수행한다. Test Sequence 3 마지막으로 모듈 D까지 전부 결합하여 테스트(T1, T2, T3, T4, T5)를 수행한다.

결과적으로 오류가 나더라도 새로 추가된 모듈과의 연결 부위를 의심하면 되므로 디버깅이 매우 쉬워지는 효과를 얻을 수 있다.

분해 기반 통합 (Decomposition-based Integration)

시스템을 기능적으로 분해한 구조(트리 형태)를 바탕으로 결합하는 방식이며, 방향에 따라 3가지로 나뉜다.

1) Top-down testing (하향식 테스팅)

최상위(High-level) 시스템부터 시작하여 위에서 아래로(Top-down) 점진적으로 통합하는 방식을 말하고, 아직 개발되지 않은 하위 컴포넌트의 자리는 임시 가짜 모듈인 '스텁(Stubs)'으로 교체(replacing)하여 테스트하는 방식을 말한다.

Level 1을 먼저 테스트하고, 하위 계층은 Level 2 stubs, Level 3 stubs로 대체하여 진행하는 것이다.

2) Bottom-up testing (상향식 테스팅)

최하위의 개별 컴포넌트부터 시작하여 아래에서 위로(Bottom-up) 점진적으로 결합해 완전한 시스템을 만든다. 하위 모듈을 호출해 줄 상위 모듈이 아직 없으므로, 이를 대신해 하위 모듈에 명령을 내리는 '테스트 드라이버(Test drivers)'가 필요하다.

Level N, Level N-1 모듈들을 최상단의 Test drivers가 제어하며 테스트한다.

3) Sandwich integration (샌드위치 통합)

하향식(Top-down)과 상향식(Bottom-up) 통합 방식을 혼합(Combination)한 방식이다.

실습: Calendar Program Example (기능 분해 구조)

달력 프로그램의 통합 테스팅 실습을 위해 시스템을 다음과 같은 기능 트리(Functional decomposition)로 분해한다. 최상위 루트는 Calendar (Main) 이고, 하위 서브 모듈들은 아래의 리스트와 같다.

하위 서브 모듈들:

• isLeap: 윤년 판별
• weekDay: 해당 날짜의 요일 계산 (Mon, Tue 등)
• getDate: 날짜 정보 가져오기 (하위에 isValidDate $\rightarrow$ lastDayOfMonth $\rightarrow$ dateToDaynum 과 getDigits를 가짐)
• Zodiac: 해당 날짜의 별자리 기호(Zodiac sign) 판별
• nextDate: 다음 날짜(NextDate) 계산
• Friday13th: 가장 최근의 13일의 금요일 찾기
• Memorial day: 5월 27일에 기념일이 열린 가장 최근 연도 찾기

Calendar Program을 통한 3가지 통합 테스팅 적용

앞서 나눈 달력 프로그램 구조를 하향식, 상향식, 샌드위치 방식으로 어떻게 테스트하는지 구체적으로 보여준다.

① Top-down (하향식)

최상단의 Calendar (Main) 모듈을 테스트하기 위해 하위 모듈인 zodiac 함수가 아직 완성되지 않았다고 가정한다.

이때 하위 모듈을 대체할 Test Stub(테스트 스텁) 을 작성하는데, 자료에서는 구체적으로 다음과 같은 C언어 스타일의 스텁 코드를 예시로 보여준다.

② Bottom-up (상향식)

최하위 모듈인 zodiac을 테스트하기 위해, 이를 호출해 줄 Test driver(테스트 드라이버) 인 Calendar (driver)를 임시로 만든다.

여기서 핵심 포인트는 "Test drivers are more complex than test stubs (테스트 드라이버가 스텁보다 만들기 훨씬 복잡하다)" 는 점이다.

예를 들어, 별자리(zodiac)를 완벽히 테스트하려면 드라이버에서 총 36개의 테스트 케이스(Call zodiac : 36 TC (before, 0, after)) 를 일일이 세팅하고 호출해 주어야 한다.

③ Sandwich (샌드위치)

이 방식은 서브 트리(sub-tree) 단위로 빅뱅 통합(Doing big bang integration) 을 수행하는 것과 유사하다. 드라이버나 스텁 없이, 트리의 루트(root)부터 리프(leaves)까지 이어지는 전체 경로(A full path)를 한 번에 묶어서 테스트한다.

모듈을 크게 묶어버렸기 때문에 오류가 발생했을 때 어느 모듈에서 문제가 생겼는지 격리하기가 매우 어렵다(It is difficult to isolate faults)는 치명적인 단점이 있다.

호출 그래프 기반 통합 (Call Graph-based integration)

앞서 전반부에서 다룬 분해 기반(하향식, 상향식, 샌드위치) 통합 테스팅에 이어, 모듈 간의 호출 관계도(Call Graph)를 바탕으로 통합 테스팅을 진행하는 4가지 접근법 중 하나이다.

System Testing

1. 시나리오 기반 테스팅 (Scenario-based Testing)

시스템 테스팅은 전체 시스템의 실제 요구사항이 잘 동작하는지 확인하는 단계로, '시나리오 기반 테스팅'이 주로 활용된다.

1) 유스케이스 다이어그램 (Use Case Diagram)

사용자의 요구사항을 식별하여 Use Case Diagram을 작성한다.

예시로 나온 '유명 미술품 딜러(오스버트)를 위한 관리 시스템'에서는 오스버트, 판매자(Seller), 구매자(Buyer)라는 액터가 등장하며, '그림 구매', '그림 판매', '보고서 생성' 등의 유스케이스를 도출한다.

2) 유스케이스 명세 및 시나리오

'명작 구매(Buy a Masterpiece)' 시나리오를 보면, 설명 입력 → 경매 기록 스캔 → 유사 작품의 과거 낙찰가 기준 연 8.5% 복리를 가산하여 최대 구매가 산정 → 판매자 정보 입력과 같은 구체적인 흐름을 정의한다.

3) 시퀀스 다이어그램 (Sequence Diagram)

해당 유스케이스가 내부적으로 어떻게 동작하는지 명세한다.

판매자와 오스버트 사이에서 UI 클래스, 가격 계산 클래스, 경매 기록 데이터 클래스 등이 어떤 순서로 메시지(예: 가격 계산, 데이터 전송 등)를 주고받는지 시간의 흐름에 따라 나타낸다.

2. GUI 테스팅 (GUI Testing)

현대 애플리케이션의 핵심인 그래픽 사용자 인터페이스(GUI)를 테스트하는 것은 매우 중요하면서도 까다로운 작업이다.

1) GUI(웹) 애플리케이션의 3계층 구조

총 3개의 계층으로 구성되고, 각각 프레젠테이션 계층, 애플리케이션 계층, 데이터 계층으로 나뉜다.

• 프레젠테이션 계층 (Front-end): HTML5, JavaScript, CSS로 구성되며, 사용자에게 직접 보여지는 인터페이스를 관리한다.
• 애플리케이션 계층 (Back-end): Java, .NET, Python 등으로 구현되며, 프론트엔드의 요청에 응답하여 실제 고객의 요청을 처리하는 비즈니스 로직을 담당한다.
• 데이터 계층 (Data Layer): MySQL, Oracle 등 데이터베이스 및 파일 서버를 통해 안정적인 데이터 관리를 수행한다. .

  2) GUI 테스팅의 본질적인 한계와 이슈

  단순한 명령줄(CLI) 기반 시스템과 달리 조작 경우의 수가 기하급수적으로 많아진다. 예를 들어 마이크로소프트 워드패드 같은 소형 프로그램조차 325개의 GUI 조작 경우의 수가 존재한다.

특정 기능을 수행하기 위해 이벤트의 연속성(Sequence of GUI events) 이 필요하다. 예를 들어 파일을 열려면 '파일 메뉴 클릭 → 열기 선택 → 대화상자에 파일명 입력 → 새 창으로 포커스 이동'이라는 일련의 과정을 거쳐야 하므로 순서 조합 문제가 폭발적으로 증가한다.

3) GUI 테스팅 수행 기법 4가지

어떻게 테스트 케이스를 만들고 이벤트를 입력하며 결과를 확인할 것인지에 따라 4가지로 나뉜다.

A. 수동 테스팅 (Manual Testing)

비즈니스 요구사항 문서에 명시된 내용에 따라 테스터가 직접 마우스와 키보드를 조작하여 화면이 맞게 동작하는지 확인한다.

B. 모델 기반 테스팅 (Model-based Testing)

시스템의 동작을 그래픽 모델로 변환하여 작동 방식을 예측한다.

시스템 요구사항을 바탕으로 효율적인 테스트 케이스를 생성하며, 특히 GUI가 절대 도달해서는 안 되는 '원치 않는 상태(undesirable state)'를 식별해 내는 데 장점을 가진다.

C. 레코드 및 리플레이 (Record & Replay)

도구가 사용자의 마우스 움직임, 키보드 입력 등의 모든 상호작용을 스크립트로 캡처(기록)해 두었다가, 정확히 동일한 상호작용 세션을 자동으로 재실행(Playback)하는 방식이다.

OS와 디바이스 드라이버 단의 이벤트를 낚아채어 작동한다.

D. 스크립팅 테스팅 (Scripting Testing)

프로그래밍 언어를 사용하여 테스트 스크립트를 작성한다.

실행 중 발생하는 인간의 실수를 원천적으로 제거할 수 있으며, 코드를 약간 수정하여 회귀 테스트(Regression Testing)에 지속적으로 재사용할 수 있다.

3. 주요 자동화 테스팅 도구

GUI 테스팅을 효율적으로 수행하기 위한 대표적인 자동화 도구들이다.

1. TestComplete

코딩 지식이 없는 팀도 사용하기 좋은 스크립트리스(Scriptless) 레코드 및 리플레이 도구다.

데스크톱, 모바일, 웹 환경을 모두 지원하며, AI 기반 객체 인식 엔진을 탑재하여 스마트한 테스트 보고서를 제공하는 것이 특징이다.

2. Selenium (셀레늄)

웹 애플리케이션 검증에 가장 널리 쓰이는 무료 오픈소스 프레임워크이다.

Java, Python, C# 등 다양한 프로그래밍 언어로 스크립트를 짤 수 있으며, WebDriver API를 사용하여 브라우저의 동작을 훨씬 더 현대적이고 안정적인 방식으로 자동 제어한다.

3. GUITAR

네이버(Naver)에서 제공하는 GUI 기반의 테스트 자동화 프레임워크이며, 사용자의 작업 정보로 생성된 테스트 스크립트를 직접 또는 원격으로 실행(Agent 활용)하여 반복적인 테스트를 수행한다.

테스트 시나리오를 한국어로 작성할 수 있다는 편의성이 있고, 로그인과 같이 여러 ID와 비밀번호 입력이 반복적으로 요구되는 시나리오를 효과적으로 자동화할 수 있다.

4. Apache Maven (마븐)

Java 프로젝트의 빌드(Build) 및 외부 라이브러리 의존성(Dependency)을 관리하는 핵심 도구이다.

프로젝트의 구조와 라이브러리를 표준화하여 관리하며, 설정에는 XML 기반의 pom.xml 파일을 사용한다.

5. 그 외

크로스 플랫폼 테스팅을 위한 OpenText Functional Testing (VBScript 사용)과 IBM DevOps Test UI 등이 존재한다.

4. CI/CD 기반 UI 테스트 자동화 (Selenium + JUnit + Maven)

코드 작성 $\rightarrow$ 빌드 $\rightarrow$ 테스트 $\rightarrow$ 배포로 이어지는 전체 과정을 자동화하는 CI/CD (Continuous Integration/Continuous Delivery) 연계 전략이다.

프론트엔드부터 백엔드까지 각 자동화 도구는 다음과 같이 역할을 분담하여 파이프라인을 구성한다.

• Maven: 전체적인 의존성 관리, 빌드(Maven Build) 수행, 테스트 실행 과정을 통제한다.
• JUnit: 자바 기반 테스트 프레임워크로서, JUnit Test 단계에서 Assert문을 활용해 결과의 성공/실패를 검증한다.
• Selenium WebDriver: 웹 브라우저를 자동으로 제어하여 사용자의 동작을 모방하는 Selenium UI Test를 수행한다.

개발자가 코드를 커밋(Code Commit)하면 빌드와 단위 테스트, UI 테스트가 순차적으로 자동 실행되며, 이 결과를 바탕으로 최종 배포 여부를 결정하게 된다.

TDD 외에도 5가지의 소프트웨어 테스팅 기법에 대해서 존재한다. (이쪽이 시험에 잘 나온다고 말씀하심)

1) Random Testing(무작위 테스팅)

명세서(Specifications) 없이 무작위로 독립적인 입력값을 생성하여 수행하는 블랙박스 테스팅 기법으로, 주로 예외(Exceptions)가 발생하는지 확인하는 데 사용된다.

2) Mutation Testing(돌연변이 테스팅)

새로운 소프트웨어 테스트를 설계하거나 기존 테스트 스위트(Test Suites)의 품질을 평가하기 위해 사용된다. 의도적으로 결함을 삽입한 '돌연변이(Mutant)'를 기존 테스트가 얼마나 잘 탐지하는지(탐지율)를 측정하는 방식으로 테스팅을 진행하며, 이 때 '돌연변이(Mutant)'는 주로 구문 삭제/복제, 불리언 식 변경, 산술/관계 연산자 변경, 동일 범위 내 변수 교체 등의 '돌연변이 연산자'를 사용한다. .

3) Concolic Testing(콘콜릭 테스팅)

구체적 실행과 심볼릭(Symbolic) 실행을 결합한 의미로 기존 무작위 테스팅의 한계를 극복하기 위한 화이트박스 테스팅 기법이다. 코드 커버리지를 극대화할 목적으로 심볼릭 실행과 정리 증명기(Theorem prover)를 사용하여 Uncovered path를 찾고 테스트 입력값을 자동으로 생성한다.

4) Regression Testing(회귀 테스팅)

패치, 기능 향상, 환경 설정 변경 등이 발생한 후 새로운 버그가 나타나지 않았는지 확인하는 테스트이다. 이 테스팅 기법은 전제가 존재하는데, 변경 사항이 이전에 잘 동작하던 코드에 새로운 결함을 도입하지 않았음을 보장해야 한다.

5) Conformance Testing(적합성 테스팅)

제품이나 시스템이 규정된 요구사항 명세, 계약 또는 규제를 제대로 준수하고 있는지 판단하는 테스트이다.

2. Test-Driven Development(TDD)

1) Background

보통 프로그래머들은 테스트를 지루한 작업으로 여기거나 다른 부서의 역할로 미루는 경향이 있다. 개발하는 것에 의미를 크게 두고 Product를 만들고 나면 유지보수에 소홀하기 쉽다. 그러다보니 여러번 테스트를 반복할수록 꼼꼼함이 떨어지는 상황이 빈번히 발생한다.

이러한 상황을 해결하기 위해 등장한 방법론이 TDD 방법론이다.

2) TDD(Test-Driven Development)란?

코드를 작성하기 전에 테스트 코드를 먼저 작성하고, 이 테스트를 통과하는 것을 개발의 핵심 원동력으로 삼아 테스트와 코드 개발을 교차(Inter-leave)로 진행하는 개발 방식.

TDD는 도구의 지원을 받아 개발자가 코드 변경 시마다 반복 가능한 테스트를 유지하고 선택적으로 실행할 수 있도록 장려하기 위해 등장했다. 엄밀히는 애자일 방법론인 익스트림 프로그래밍(XP)의 일부로 도입되었지만, 계획 주도 개발 프로세스에서도 활용할 수 있다.

3) Process

TDD는 아래의 프로세스를 거친다. 일종의 사이클을 가지고 테스트를 수행하고 테스트가 실패하면 해당 기능을 지속적으로 빌드업하고 이후 테스트가 실행 완료될 경우 다음 기능 구현으로 넘어가는 방식으로 진행된다. 일련의 절차는 아래와 같다.

1. 몇 줄의 코드로 구현할 수 있는 작은 기능 단위(Increment)를 식별한다.
2. 해당 기능을 위한 자동화된 테스트를 작성한다.
3. 모든 테스트를 실행. 아직 실제 코드가 없으므로 새로운 테스트는 실패한다.
4. 테스트를 통과하기 위한 실제 기능 코드를 작성한다.
5. 다시 테스트를 실행하여 모든 테스트가 성공하면 다음 기능 구현으로 넘어간다.

4) Benefit

TDD는 좋은 테스팅 기법이다. 고로 여러 장점을 가지는데 아래의 4가지의 장점을 중심으로 생각해볼 수 있다.

1) 코드 커버리지 작성된 모든 코드는 최소 하나 이상의 연관된 테스트를 가지게 된다는 의미이다. 2) 회귀 테스트가 진행 프로그램이 개발됨에 따라 회귀 테스트 스위트가 점진적으로 구축되어 변경으로 인한 오류를 방지한다. 3) 디버깅 간소화 만약 테스트를 실패한다하더라도, 직전에 작성한 새로 추가된 코드에 문제가 있음이 명확하므로 디버깅이 간단하다. 4) 시스템 문서화의 역할을 수행 작성된 테스트 자체가 코드가 무엇을 해야하는지 설명하는 일종의 Document(문서)의 역할을 수행한다.

5) Apply

TDD는 테스트 케이스를 언제 만들 것인지에 따라 '기존 개발 방법(전체 개발 후 전체 테스트)', '모듈별 테스트', '모듈별 TDD', '전체 TDD' 등 다양한 전략으로 접근할 수 있다.

3. JUnit의 개념 및 활용

1) Introduction

켄트 벡(Kent Beck)이 90년대 중반 Smalltalk용으로 개발한 xUnit을 바탕으로, 켄트 벡과 에릭 감마가 비행기 안에서 공동 개발한 자바 TDD의 표준 도구이다. JUnit은 기존 프로그램을 건드리지 않고 테스트 수행이 가능하며 사용자가 결과값을 일일이 눈으로 확인하지 않아도 된다. xUnit 툴은 어떤 언어를 사용하느냐에 따라 다양한 방식으로 개발될 수 있다.

2) O-O Program

void main() 함수는 프로그램 수행의 시작 함수로 Java Application은 main() 내부에서 모든 제어를 담당한다. O-O program은 기존 프로그램을 건드리지 않고 테스트 수행이 가능하다. 또한 사용자가 결과값을 확인하지 않아도 된다.

아래와 같은 방식으로 Test Case를 수행한다.

테스트는 Precondition(사전 조건) 설정 ➔ 해당 코드 수행 ➔ 결과값 확인(Assert)의 흐름으로 진행된다. 결과를 검증하기 위해 assertEquals, assertFalse, assertTrue, Assert(Not)Null, Assert(Not)Same 등 다양한 Assert 메서드를 제공한다.

3) Eclipse 연동하기

그럼 Eclipse로 실습을 해보자.

Eclipse에서 프로젝트를 생성할 때 테스트 클래스는 반드시 일반 클래스가 아닌 "JUnit Test Case" 형태로 만들어야 한다. 또한 org.junit.Assert.* 및 org.junit.Test를 올바르게 import 하는 것을 반드시 기억해야한다.

실행 결과는 녹색 막대(성공) 또는 붉은 막대(실패)로 직관적으로 표시된다.

Fixture

@Before 어노테이션을 사용하여 각 테스트 전에 필요한 객체를 초기화(setUp) 하고, @After를 사용하여 테스트 종료 후 자원을 정리(tearDown)하는 일관된 테스트 환경을 구성할 수 있다.

Timeout & @Ignore

특정 시간 내에 로직이 수행되는지 검사하려면 @Test(timeout=130)과 같이 시간을 지정하고, 실행을 잠시 보류하려면 @Ignore를 사용한다. 만약 예상되는 예외를 검증하려면 @Test(expected=Exception)을 사용한다.

JUnit Annotation

JUnit과 관련된 Annotation을 정리해보면 아래와 같다.

JUnit 4 vs JUnit 5

JUnit 4에서 JUnit 5로 넘어가며 어노테이션 이름이 변경되었습니다. @Before는 @BeforeEach로, @After는 @AfterEach로, 전체 수행용인 @BeforeClass/@AfterClass는 @BeforeAll/@AfterAll로, 비활성화를 뜻하는 @Ignore는 @Disabled로 명칭이 바뀌었다.

JUnit vs TestNG

JUnit은 주로 단위 테스트에 초점이 맞춰져 있고 병렬 실행이나 그룹화에 제한적인 반면 TestNG는 단위, 통합, 대규모 테스트를 모두 아우르며 병렬 실행, 강력한 그룹화, XML 설정, 데이터 기반 테스트 등 훨씬 강력한 부가 기능을 제공한다.

4. 단위 테스팅(Unit Testing) 실습

EclEmma (자바 Coverage 도구): Eclipse Marketplace에서 설치 가능하며, Coverage As ➔ JUnit Test 모드로 테스트를 실행하면 내가 작성한 테스트 코드가 실제 프로덕션 코드의 몇 퍼센트를 실행(커버)했는지 시각적으로 확인할 수 있습니다 . GTest (Google Test): Visual Studio 환경에서 C++ 코드를 테스트할 때 사용하는 유닛 테스트 라이브러리입니다 . TEST(TestCaseName, TestName) 형식의 매크로로 테스트를 정의하고, 값을 비교할 때 EXPECT_EQ, EXPECT_TRUE 등의 매크로를 사용합니다 . Triangle Problem 실습: TDD의 구체적 사례로, 세 변의 길이를 입력받아 정삼각형(Equilateral), 이등변삼각형(Isosceles), 일반 삼각형(Scalene), 삼각형 아님(NotTriangle), 입력 오류(InputValidation)를 판별하는 프로그램을 작성합니다 . 점진적으로 실패하는 테스트 코드를 먼저 만들고 코드를 구현해나가는 과정이 GTest 코드로 상세히 예시되어 있습니다 .

Introduction

Structural Programming

Introduction

구조적 프로그래밍 기법은 단순성을 지향한다. 복잡한 코드도 Sequence(순차), Selection(선택), Repetition(반복)이라는 3가지 기본 구조만으로 표현할 수 있다.

구조적 프로그램 생성 규칙은 아래와 같다.

1. 가장 단순한 형태에서 시작하라.
2. 어떤 작업 상태든 연속된 두 개의 작업 상태로 대체할 수 있다.
3. 어떤 작업 상태든 임의의 제어 구문으로 대체할 수 있다.
4. 규칙2와 규칙3은 원하는 만큼, 어떤 순서로든 자유롭게 적용할 수 있다.

   프로그램 구조

   규칙 적용의 예시는 아래와 같다.

| --|--|

CFG(Control Flow Graph)

구조적 테스트를 수행하려면 먼저 코드의 실행 흐름을 시각적으로 모델링해야 하며, 이를 위해 CFG를 작성한다. CFG는 아래의 몇가지 구성요소를 가진다.

• 노드(Nodes): 분기(Branch) 없이 순차적으로 실행되는 구문 또는 구문들의 연속인 '기본 블록(Basic Block)'을 의미한다.
• 기본 블록(Basic Block): 첫번째 구문이 실행되면 블록 내의 모든 구문이 반드시 실행된다.
• 간선(Edges): 제어 흐름을 나타낸다.

CFG를 작성할 때는 몇 가지 주의사항이 있다. 우선 if-return 구문을 작성할 때, if문 안과 밖에 모두 return이 있는 경우 두 return 노드는 반드시 별개의 노드로 구분되어야한다. 또한 while & for 구문에서 loop가 시작되기 전에 loop 변수를 초기화하는 dummy node가 암묵적으로 생성됨을 고려해 그려야한다.

Test Coverage

CFG를 작성한 이후에는 어떤 경로로 테스트를할 것인가를 "기준(Criteria)"으로 정립해야한다. 이 기준의 엄격함에 따라 다양한 커버리지로 분류된다.

Statement Coverage

프로그램 내의 모든 구문이 최소 한 번 이상 실행되도록 보장하는 가장 기본적인 커버리지이다. 반복문을 통해 입력값을 더하고 -1이 입력되면 종료 후 평균을 계산하는 프로그램이 있다고 가정하였을 때, 정상적으로 값이 입력되는 경로와 조건문들이 실행되는 경로를 포함하는 테스트 패스가 2개면 모든 노드(구문)을 방문하는 것이다.

Decision(Branch) Coverage

프로그램의 모든 진입점과 진출점이 최소 한 번 이상 호출되며, 프로그램 내의 모든 결정이 True & False의 결과를 최소 한 번 이상 가져야 한다. CFG 상의 모든 간선(Edge)을 순회하는 것과 같다.

Condition/Decision Coverage(C/DC)

결정 커버리지를 만족하는 동시에, 결정 구문 내부를 구성하는 각각의 개별 '조건(Condition)'들도 모두 참과 거짓을 최소 한 번씩 가지는 것을 말한다.

예시로 A||B의 경우 결정 자체도 true/false가 나와야 하고, A와 B도 각각 true/false가 나와야하므로 최소 테스트 셋은 (True, True)와 (False, False)가 된다.

Modified Condition/Decision Coverage(MC/DC)

가장 엄격한 기준으로, 각각의 개별 조건이 전체 결정의 결과에 '독립적으로 영향을 미친다(independently affect)' 는 것을 증명해야 한다. 이를 증명하려면 특정 조건의 값만 변경하고 나머지 조건들은 고정(holding fixed)했을 때, 전체 결과가 달라지는 것을 보여줘야 한다.

Excemple - (MC/DC)

• AND 연산 (A && B) A의 독립성을 증명하기 위해선 B를 True로 고정하고 A를 T/F로 변경한다. 즉, (T,T)와 (F,T)가 필요하다. 반대로, B의 독립성을 증명할 때엔 A를 True로 고정하고 B를 T/F로 변경한다. 즉, (T,T)와 (T,F)가 필요하다. 결과적으로 최소 테스트 셋은 {(T,T), (T,F), (F,T)} 가 됩니다

• OR 연산 (A || B) AND와 동일한 원리로 전체가 거짓이 되는 (F,F)를 기준으로 각 변수를 하나씩 True로 바꾼 {(T,F), (F,T), (F,F)} 가 최소 테스트 셋이 된다.

• 윤년 계산기(isLeap(int year)) : 윤년 조건 ((year%4 == 0) && (year%100 != 0)) || (year%400 == 0)을 C1, C2, C3로 나눌 때, 각 조건(Variant)이 전체 결과에 영향을 미치는지 분석(예: B2는 B1의 C1 variant 등)하여 독립성을 증명하는 테스트 패스를 구성해야 한다.

Dataflow Testing

경로 기반 테스팅이 제어의 흐름에 집중했다면, 데이터 흐름 테스팅은 변수의 값이 어디서 정의되고 어디서 사용되는지 그 생명 주기를 추적하여 결함을 찾는다.

Dataflow Testing에는 두 가지 개념이 나오는데, 첫째로 Def는 Definition으로, 값이 메모리 위치에 저장되는 시점을 말한다. formal parameter로 사용되거나 input으로 값을 받을 때와 같은 상황에서 주로 발생한다. 두번째 개념은 Use로, 변수의 값이 접근(사용)되는 시점을 말한다. 대입 연산자의 우측에 올 때, 조건문의 평가에 사용될 때, 반환 및 출력되는 상황 등에서 발생한다.

Definition of Def-Use Pair

DU Pair는 특정 변수에 대해 (Def, Use)의 쌍을 묶은 것이다. 단, 이 쌍이 성립하려면 값이 정의된 후 사용되기 전까지 다른 값으로 재정의되지 않는 'Def-clear path' 여야만 한다. def와 use가 같은 노드에 나타날 경우, 루프 내에서 정의가 사용 후에 발생하면 DU 쌍이 생성된다. def 사용 전에 발생할 경우, DU pair가 생성되지 않는다. 마지막으로 DU pair는 새로운 중간 정의 없이 정의가 제거된 경로여야 한다.

Program Slicing

프로그램 슬라이싱은 오류 추적과 프로그램 분석을 극대화하기 위해 코드를 잘라내어 분석하는 기법입니다 . 정적 후방 슬라이스 (Static, Backward Slice) S(V, n): 특정 시점(Slice criterion)에 해당하는 노드 n에서의 변수 집합 V의 값에 영향을 미치는 프로그램 내의 '모든 구문 조각(statement fragments)들의 집합'을 역추적하여 계산하는 방법입니다 . 적용 분야: 오류의 근원을 더 쉽게 찾는 디버깅(Debugging), 소프트웨어 유지보수, 코드 최적화, 프로그램 분석, 정보 흐름 제어 등에 유용하게 사용됩니다 .

5. 테스트 기법 분석 (효과와 비용 비교) 강의 자료에서는 이러한 구조적 테스팅(Code-based testing) 기법들과 명세 기반 테스팅(Spec-based testing, 예: 경곗값 분석, 동치 분할)을 분석 비용(Effort), 테스트 케이스의 수, 의미적 내용(Semantic content) 측면에서 비교합니다 . 의미적 내용 (Semantic Content): 명세 기반의 Boundary Value(경곗값)나 Path Testing은 의미론적 파악 요구도가 낮은 편입니다 . 반면 구조적 기법인 Slice Testing이나 Data flow testing, 명세 기반의 Decision table 등은 구조 및 로직에 대한 높은 수준의 의미적 이해(High semantic content)를 요구합니다 . 테스트 케이스 식별 노력 (Test case identification effort): Data flow testing이나 Slice testing은 내부 로직을 일일이 추적해야 하므로 분석 노력이 매우 높게(High) 듭니다 . 반면 동치 분할(Equivalence class)이나 경곗값 테스트는 비교적 쉽게 식별(Low effort)할 수 있습니다 . 테스트 케이스의 수 (Number of test cases): 경곗값 테스트(Boundary value testing)와 프로그램 슬라이싱(Slice testing)은 생성되는 테스트 케이스의 수가 굉장히 많아집니다 . 반면 Decision table이나 Basic path testing은 상대적으로 적은 테스트 케이스를 생성합니다 .

Test Case(TC)는 Test Input과 정답을 포함해서 사용된다.

소프트웨어 테스트 케이스를 생성하는 전략은 크게 소프트웨어의 내부 구조 참조 여부에 따라 두 가지로 나뉜다. 1) 블랙박스 테스팅과 2) 화이트박스 테스팅이다.

1) Black-Box Testing

블랙박스 테스팅 (Black-Box Testing)은 프로그램의 내부 구조를 보지 않고 '블랙박스'로 간주하여 테스팅하는 기법이다. 내부를 살피지 않고 기능이 명세서(Specification)에 명시된 요구사항을 충족하는지를 중점적으로 보는 것이다. 이 방법을 사용하면 소스 코드가 완성되기 전, 소프트웨어 프로세스의 초기 단계부터 명세서를 바탕으로 테스트 계획을 시작할 수 있다는 장점이 있다.

Equivalence Partitioning

이 때 동치 분할 (Equivalence Partitioning)이라는 개념이 사용되는데, Equivalence Partitioning이란, 입력 데이터와 출력 결과가 동일하게 취급되는 클래스(집합)들로 나뉜다는 원리를 이용하는 것을 말한다.

하나의 파티션(클래스) 내의 모든 입력에 대해 프로그램이 동일하게(동등하게) 동작한다고 가정하므로,각 클래스에서 모든 값을 테스트할 필요 없이 대표 테스트 케이스만 선택하여 테스트한다.

10,000~99,999 사이의 5자리 정수가 입력 조건이라면, 범위를 <0-9999>, <10000-99999>, <100000 이상>으로 분할하고 각 경계값인 00000, 09999, 10000, 99999, 100000을 추출하여 테스트하는 것을 예로 들 수 있다.

2) 화이트박스 테스팅 (White-Box Testing):

블랙박스 테스팅과는 상반된 방식으로, 구조적 테스팅(Structural testing)이라고도 불리며 모듈 내부의 실제 소스 코드를 들여다보고 프로그램 구조에 따라 테스트 케이스를 도출한다. 이 방식은 프로그램에 대한 지식을 바탕으로 추가적인 테스트 케이스를 식별해 낸다.

화이트박스 테스팅의 목표는 프로그램의 모든 구문, 조건, 의사결정들을 한 번 이상 실행해보는 것이다. 단, 무한할 수 있는 모든 경로의 조합을 실행하는 것은 아니다.

화이트박스 테스팅의 예시로는 이진 탐색이 있다. Java 소스 코드를 분석하여 while 문과 if 조건문들을 거치는 4가지의 독립적인 경로(Independent paths: 1-2-8-9, 1-2-3-8-9 등)를 도출하고, 이를 Program Flow Graph로 모델링하여 검증한다.

2. Specification-based Testing

Introduction

명세 기반 테스팅은 블랙박스 테스팅 또는 기능 테스팅(Functional testing)이라고도 불린다.

명세 기반 테스팅의 가장 큰 장점은 프로그램 내부의 구현(Implementation) 방식이 변경되더라도 명세가 바뀌지 않는 한 테스트 케이스는 변경되지 않으며, 프로그램 구현과 동시에 테스트 케이스를 병행하여 개발할 수 있다는 것이다.

명세(Specification)와 프로그램, 테스트 케이스의 관계 (벤 다이어그램 시각화) 실제 개발 환경에서 명세(S)와 개발된 프로그램(P)은 완벽히 일치하지 않는다.

위의 그림에서 Scope 1이 명세서에서 기대되고(Expected), 프로그램에 올바르게 구현되었으며(Programmed), 성공적으로 테스트된(Tested) 이상적인 영역이고, Scope 2와 5는 명세서에서 요구하여 기대되지만(Expected), 아직 테스트되지 않은 영역이며 Scope 6은 명세서에 없는데 개발자가 임의로 구현했으며(Programmed, not expected), 테스트되지도 않은 잠재적 결함 영역이다.

IEEE 표준 소프트웨어 결함 분류

IEEE 표준 소프트웨어 결함 분류 (IEEE Std. Fault Types - 1993) 소프트웨어에서 발생하는 이상 징후는 다음과 같이 5가지로 분류된다.

• 입력/출력 결함 (Input/Output Faults): 올바른 입력 거부, 잘못된 입력 수용, 잘못된 포맷, 결과 오류, 타이밍 오류 등
• 논리 결함 (Logic Faults): 처리 케이스 누락 또는 중복, 극단적 조건 무시, 잘못된 변수 테스트, 조건 누락, 연산자 오류(예: < 대신 <= 사용) 등
• 계산 결함 (Computation Faults): 알고리즘 오류, 계산 누락, 피연산자/연산 오류, 괄호 에러, 반올림/잘림 등 정밀도 부족
• 인터페이스 결함 (Interface Faults): 잘못된 인터럽트 처리, I/O 타이밍, 존재하지 않거나 잘못된 프로시저 호출, 파라미터 불일치
• 데이터 결함 (Data Faults): 초기화 오류, 변수/인덱스/플래그 잘못 사용, 데이터 차원 및 타입 오류, 센서 데이터 한계 초과, Off-by-one(1 차이 연산) 오류 등

명세 기반 테스팅의 핵심 기법

경계값 테스팅 (Boundary Value Testing)

입력이나 출력 도메인의 변수 영역 끝부분(경계)에서 오류가 가장 많이 발생한다는 것을 바탕으로하는 테스팅 기법이다.

Normal Boundary Value Testing

예외를 제외하고 유효한 입력의 경계값만을 독립적으로 다룬다. <최솟값, 최솟값+1, 정상값, 최댓값-1, 최댓값> 5가지 포인트를 중심으로 테스트를 수행한다.

Robustness Testing

Normal 테스팅의 확장판으로 예외 처리 상황까지 중심으로 테스팅한다. Normal Boundary Value Testing의 포인트를 중심으로 범위를 벗어나는 <최솟값-1, 최댓값+1>을 추가하여 총 7가지 포인트를 확인합니다 (예: 엘리베이터의 하중 초과 시 동작 테스트)

Worst-Case Testing

변수들이 서로 독립적이지 않고 변수들 간의 의존성을 고려하여 모든 경계값들의 최악의 조합을 산출하는 방식이다. (Robust worst-case 방식도 존재)

동치 클래스 테스팅 (Equivalence Class Testing)

중복된 테스트를 피하면서도(avoid redundancy) 완벽하게 테스트했다는 확신을 얻기 위해 사용하는 테스팅 방법으로, 동치 클래스는 교집합이 없어야 하며, 합치면 전체 도메인이 되어야 한다. 또한 입력 값들은 동일 기능을 수행하기 때문에 대표값만 테스트해도 된다.

Testing 방법에 따라 아래 3가지 방법으로 나눌 수 있다.

1) Traditional Equivalence

유효한 값(Valid) 영역과 유효하지 않은 값(Invalid) 영역을 단순히 나누어 각각에서 값을 추출한다.

2) Weak/Strong Normal Equivalence

오직 유효한 정상 케이스(Normal cases) 에만 집중한다. 입력 변수들이 완전히 독립적이면 Weak, 서로 연관성/의존성이 있으면 조합을 고려하는 Strong 방식을 쓴다.

3) Weak/Strong Robust Equivalence

유효한 입력과 유효하지 않은 예외 입력을 모두 고려(Consider both) 하는 가장 강력한 방식이다. 독립 여부에 따라 Weak와 Strong으로 구분한다.

의사결정 테이블 기반 테스팅 (Decision Table-based Testing)

1960년대부터 복잡한 논리 관계를 표현하고 분석하는 데 쓰인 기법이다. 프로그램의 action을 수행하기 위한 다양한 조건(c1, c2, c3...)의 참/거짓 논리 조합을 표 형태로 그리고, 각 수행 조건(규칙)별로 빠짐없이 Test Case를 생성한다.

테스트 노력(Testing Effort)과 기법 선택 가이드라인

동일한 문제(Triangle, NextDate 등)를 각 기법으로 테스트할 때 도출되는 테스트 케이스의 개수를 비교해 보면, 모든 예외와 변수 의존성을 조합하는 Robust Worst-case (rob. wc) 방식이 압도적으로 가장 많은 테스트 케이스를 요구합니다

테스트 기법 선택 기준은 1) 변수가 물리적(아날로그)인지 논리적인지, 2) 변수 간 의존성이 있는지, 3) 단일 결함인지 다중 결함 가정이 필요한지, 4) 예외 처리를 고려해야 하는지 여부에 따라 적절한 기법(a1~a8)을 선택해야 한다.

3. Case Studies

수업 자료에서는 이론을 실제화하기 위해 4가지 구체적인 예제를 다룹니다.

1) 보험료율 계산 (Insurance Premium)

조건 보험료(Premium) = 기본료 * 나이 가중치(ageMultiplier) - 안전운전 할인(safeDrivingReduction). 나이별로 가중치가 다르고(16세~100세), 벌점(Point)이 커트오프 점수 아래일 때만 할인이 주어진다.

| --|--|

나이와 벌점이라는 두 변수의 경계값(Min, Max) 및 유효/비유효 구간을 나누어 도식화한 후, 벌점 커트오프 영역을 고려한 'Worst-Case Testing'과 유효/비유효 구간의 대표값을 뽑아내는 'Weak Robust Equivalence Class' 테스트 케이스 도출 과정을 보여준다.

2) 환자 관리 시스템 (MHC-PMS)

"Input을 구성해야한다. 환자 상태, 약품, 경고 무시 여부를 나누고 이를 warning 메세지 여부로 출력한다. 그리고 이 모든 조합을 분석해서 TC를 만든다" 요구사항 환자가 특정 약품에 알레르기가 있다면 처방 시 시스템이 경고 메시지를 띄워야 합니다. 의사가 경고를 무시하려면 반드시 무시하는 이유를 입력해야 한다.

이때 입력 조건과 출력 조건은 다음과 같다.

입력 조건: 알레르기 유무(None, One, Two), 처방 약품(Normal, 1개 알레르기, 다중 알레르기), 경고 무시 여부(No, Yes)

출력: Warning Message 여부.

이에 따라 나올 수 있는 모든 조합을 분석하여, 정상 처방 시 메시지가 안 뜨는 TC#1부터, 2가지 알레르기가 있는데 이를 모두 무시하고 처방하여 두 가지 사유를 입력받아야 하는 TC#13까지 총 13개의 구체적인 테스트 케이스를 도출해 낸다. .

3) 삼각형 문제 (Triangle Problem)

문제 정의 세 정수 a,b,c를 입력으로 받으며 아래의 조건을 만족해야한다. • a = b = c 이면, 정삼각형 출력 • a, b, c 중 한 쌍만 같을 때, 이등변삼각형 출력 • 한 쌍도 같지 않을 때, 삼각형 출력 • 두 변의 합이 한 변의 길이보다 작으면, “삼각형 아님”

입력 도메인과 출력 도메인은 위와같이 분류할 수 있다.

4) Triangle Problem - Expension

문제 정의 세 정수 a,b,c의 길이를 입력으로 받으며 아래의 조건을 만족해야한다. • C1: 1 <= a <= 200, C2: 1<= b <= 200, C3: 1<= c <= 200 • C4: a < b + c, C5: b < a + c, C6: c < a + b

또한 출력은 다음과 같이 정의한다. • a = b = c이면, 정삼각형 출력 • a, b, c 중 한 쌍만 같을 때, 이등변삼각형 출력 • 한 쌍도 같지 않을 때, 삼각형 출력 • C4, C5, C6가 만족되지 않으면, “삼각형 아님” 출력

출력값 기준의 Weak Normal Equivalence Class, Strong Robust Equivalence Class를 작성하고, 입력값 변수 기준의 Weak Robust Equivalence Class 테스트 케이스를 뽑아내는 훈련을 제시한다.

5) 다음 날짜 구하기 함수 (NextDate Function)

문제 정의 년(18122012), 월(112), 일(1~31)의 세 정수를 입력받아 바로 다음 날짜를 출력하는 함수입니다

테스트 케이스 설계 Weak Robust 기법을 위해 년/월/일의 단순 유효 범위를 M1, D1, Y1으로 나눕니다

Strong Normal 기법을 위해 월(30일인 달, 31일인 달, 2월), 일(128일, 29일, 30일, 31일), 년도(비윤년, 윤년, 세기말 평년 등)를 매우 세부적인 조건(M1M3, D1D4, Y1Y3)으로 치밀하게 클래스를 분할하여 테스트 케이스를 설계하는 전략을 보여줍니다

1) 임베디드 소프트웨어의 안전성 문제

임베디드 소프트웨어는 다양한 분야에서 폭넓게 활용되고, 이는 실생활과 매우 밀접한 관계를 가진다. IT와 관련된 제품들은 오류를 발생하면 심각한 결과로 이어질 가능성이 있다.

특히나 의료기기나 자동차와 같이 문제가 발생하면 생명에 직결되는 경우에는 심각한 상황을 연출하게 된다.

2) 대표적 실패 사례: 의료기기 Therac-25

Therac-25는 1976년 캐나다 AECL이 개발한 방사능 치료 기기로, 1982년에 하드웨어 제어 방식에서 소프트웨어 제어 방식으로 시스템을 변경했다.

1985년에 첫 의료 사고가 발생한 이후 19개월이라는 긴 시간 동안 6건의 사고가 추가로 발생했으며, 이로 인해 3명이 사망하고 3명이 심각한 장애를 입었다. 이후 2000년 파나마 시티에서는 유사한 원인으로 28명이 방사능에 노출되어 23명이 사망하는 참사가 발생했다.

사고 원인에 대해서 알아보기 위해서는 기기에 대한 속성을 파악할 필요가 있다. 해당 기기는 치료실과 제어실이 분리되어 운영중이었으며 기기는 두 가지 동작 모드를 가졌는데, X-ray 모드는 텅스텐 스크린 막을 통과시켜 얕은 종양을 치료하는 약한 방사능 모드이고, Electron 모드는 피부 깊숙한 종양 치료에 쓰이는 모드이다.

사고 시나리오를 살펴보면 오퍼레이터가 실수로 X-ray 모드를 설정했다가 이를 인지하고 급하게 Electron 모드로 변경하여 치료를 시작했을 때, 기기 내에 X-ray 모드 수준의 강력한 방사능이 세팅된 상태로 환자에게 그대로 노출되어 버리는 심각한 결함이 있었습니다

사고 이후에 조사에 따르면, 단 한 명의 프로그래머가 제어 소프트웨어를 작성했으며 개발 완료 후 어떠한 소프트웨어 검증 절차도 거치지 않았다고한다. 그리고 최초 사고 후 여러차례 검증하였으나 원인을 찾지 못했고 이를 통해 임베디드 소프트웨어의 오류는 재현이 어렵다는 것을 확인할 수 있다. 결론적으로 원인을 찾지 못하고 19개월간 시스템을 그대로 사용하게 됩니다.

이 사고를 통해 얻을 수 있는 주안점은, 임베디드 소프트웨어는 엄격한 기능 안전 표준(Functional Safety Standards)을 바탕으로 철저한 신뢰성 및 안전성 검증을 반드시 거쳐야 한다는 것**이다.

Software Testing

1) 왜 소프트웨어를 테스트해야 하는가?

소프트웨어 테스팅은 시스템에 대해 다음과 같은 가장 중요한 5가지 질문을 던지고 답을 구하는 과정이다.

• 제대로 작동할 것인가? (Will it work properly?)
• 신뢰할 수 있을 것인가? (Will it be reliable?)
• 구축하기 쉬울 것인가? (Will it to be easy to build?)
• 고품질의 설계인가? (Is it a quality design?)
• 유지보수하기 쉬울 것인가? (Will it be easy to maintain?)
• 구현과 테스팅의 비중: 프로젝트의 규모(Lines of Code)

위의 질문들이 커질수록 전체 시간에서 구현과 개발자 테스트가 차지하는 비중은 줄어들게 되지만, 역설적으로 전체 프로젝트 오류 중 소스 코드 구현 시 발생하는 오류의 비중이 가장 높기에 체계적인 테스트를 진행해야한다.

2) 소스 코드 검증 기법

소스 코드 검증 기법은 저번 포스트에서 언급한대로 총 두가지의 방향으로 나뉜다.

우선 1) 정적 분석(Static Analysis)는 코드를 실행하지 않고 인스펙션을 통해 오류를 사전에 예방하는 기법이다. 다음으로 2) 동적 분석(Dynamic Analysis)로 불리는 실제 소프트웨어 소스 코드를 실행하여 오류를 발견하는 기법이 존재한다.

2) Dynamic Testing

Dynamic Testing에는 아래의 4가지 개념이 존재한다.

• Test data: 시스템을 테스트하기 위해 의도적으로 고안된 인위적인 입력값.
• Test cases: 시스템에 주어지는 입력값과, 명세서에 따라 시스템이 올바르게 작동할 때 예측되는 '예상 결과값'의 쌍.
• Test suite : 프로그램 테스트에 사용하기 위해 모아둔 테스트 케이스들의 집합.
• Test oracle : 테스트가 통과했는지 실패했는지를 판별할 수 있게 해주는 기준점 메커니즘. (예: 명세서, 문서 등)

테스팅은 프로그램에 오류나 결함이 '존재함'을 밝혀낼 수는 있지만, 결함이 전혀 없음을 증명할 수는 없다.

수많은 테스팅 기법이 존재하지만, 단일 방법 하나만으로 평균 75% 이상의 오류 감지율을 보이는 것은 없고, 오류 감지율을 극대화하려면 V-모델과 같은 생명주기에 맞추어 반드시 다양한 검증 기법을 병행해야 한다.

Program Testing Technique

1) Program Testing

프로그램 테스트는 프로그램이 의도대로 작동하는지 확인하고 사용하기 전에 결함을 발견하기위해 진행된다. 데이터를 만들어서 프로그램을 실행하며, 실행 결과를 검토해 프로그램의 문제를 파악한다. 이 때, 테스트를 통해서는 존재의 여부를 알 수 있지만 오류가 없다는 것을 보장하지는 않는다는 것을 유의해야한다.

2) Verification(검증)과 Validation(확인)

Program을 테스팅을 할 때 우리는 두가지 용어를 주의깊게 살필 필요가 있다.

1) Verification(검증)은 "우리가 제품을 올바르게 만들고 있는가?" 에 대한 질문으로 소프트웨어가 설계 명세서를 정확히 준수하는지를 확인하는 것을 말하고 2) Validation(확인)은 "우리가 올바른 제품을 만들고 있는가?" 에 대한 질문으로 소프트웨어가 사용자가 실제로 요구하는 바를 잘 수행하는지를 확인하는 역할을 맡게된다.

그리고 Program testing에는 목적이 두가지 존재하는데,

첫째로 Validation testing(확인 테스팅)은 개발자와 고객에게 소프트웨어가 요구사항을 충족한다는 것을 증명하기 위해 사용하며 정상적인 시스템 사용 환경을 반영한 테스트 케이스를 사용한다. 둘째로 Defect testing(결함 테스팅)은 시스템이 부정확하거나 명세를 위반하는 상황을 의도적으로 찾아내기 위해 사용하며 사용자가 평소에 사용하지 않는 모호하거나 극단적인 테스트 케이스를 고의로 주입하여 결함을 노출시킵니다

그 중 하나인 Input-Output 모델은 다음과 같은 형태로 동작한다.

3) 인스펙션(정적 분석)과 테스팅(동적 분석)

Inspections(인스펙션)은 정적 분석이라고도 불리며, 시스템의 정적인 결과물(Code, Doc 등)을 분석해 문제를 발견하는 정적인 검증 기법이다. 근본적으로 코드 실행을 하지 않고 그 전 단계에서 오류를 사전에 예방하고자하는 목적으로 사용한다.

Testing(테스팅)은 동적 분석이라고도 하며, 테스트 데이터를 주입해 시스템을 작동시키고 동작을 관찰하는 동적 검증 기법이다. 인스펙션과 달리 코드를 실제로 실행시키고 이를 통해 오류를 발견하는 것에 초점을 두고 있다.

Advantage of Inspections

인스펙션은 3가지의 장점을 가진다.

첫째로 오류 간섭(Masking) 회피이다. '오류 간섭'이란 테스팅 과정에서 하나의 오류가 다른 오류를 숨기는 현상이 발생하는 것을 말한다. 테스팅이 가지는 치명적인 단점이 인스펙션에서는 독립적으로 결함을 찾을 수 있어 이를 회피할 수 있다.

둘째로 비용의 효율성이다. 시스템이 불완전할 때 테스팅을 하려면 특수한 Test Harnesses를 개발하여 사용 가능 부분을 실행해야하므로 추가 비용이 발생한다. 인스펙션은 문서 기반이므로 미완성인 코드에 대해 검사를 진행해도 비용을 추가로 지불할 필요가 없다.

마지막으로 광범위한 품질 속성 평가이다. 인스펙션은 버그를 찾는 것 뿐아니라 프로그램 전반의 품질에 대한 속성들을 종합적으로 평가하기에 용이하다.

Inspection과 Testing

시스템의 Performance나 사용성(Usability) 같은 시스템 작동 시 발생하는 비기능적 특징은 인스펙션으로 확인할 수 없고 오직 동적 시스템 실행(Testing)을 통해서만 점검할 수 있다. 고로 어느 한가지 기법만을 이용하는 것이 아닌 *두 기법을 병행하여 V&V(Verification & Validation) 프로세스 전반에 적용해야한다. *

소프트웨어 테스팅 단계별 프로세스 (Stages of Testing)

소프트웨어 테스팅은 시간 흐름 및 목적에 따라 크게 1) Development Testing, 2) Release Testing, 3) User Testing 의 3단계로 나뉜다.

1단계: 개발 테스트 (Development Testing)

시스템을 개발하는 내부 팀이 중심이 되어 버그와 결함을 발견하기 위해 직접 수행하는 과정으로, 범위에 따라 3단계로 세분화된다.

단위 테스트 (Unit testing):

개별 기능, 메서드, 객체 클래스 등을 완벽히 격리된 상태에서 테스트하는 '결함 테스트' 이다.

Unit Testing의 전략으로는 '방어벽(Barricade) 모듈' 을 두는 것이 있다. 신뢰할 수 없는 오염된 외부 입력 데이터를 정상 입력과 비정상 입력으로 걸러내고 정제하여 안전 구역(Clean Area) 내의 내부 클래스들은 검증된 정상 입력만을 처리하도록 설계하여 테스트한다.

또한 자동화라는 기술도 존재하는데, 이는 수동 개입으로 인한 비효율을 막기 위해 실행과 결과가 자동으로 확인되도록 가급적 자동화(Automated)가 되어야한다. 90년대 중반 Kent Beck이 Smalltalk용 xUnit을 개발한 이후, 현재는 Java를 위한 JUnit (Eclipse 등 IDE에 통합)이 테스트 주도 개발(TDD)의 표준 도구로 자리 잡았으며, 다양한 언어(C++, Python 등)로 확장되었다.

컴포넌트 테스트 (Component testing):

여러 개별 객체가 통합된 복합 컴포넌트를 테스트합니다. 하위 객체들의 단위 테스트가 끝났다고 가정하고, 구성 요소 간의 인터페이스가 명세대로 동작하는지 확인하는지를 점검한다.

이때 인터페이스 유형은 데이터나 변수를 넘겨주는 파라미터 전달(Parameter), 특정 메모리 블록을 공유하는 공유 메모리(Shared memory), 서브 시스템 간 서비스 요청인 메시지 전달(Message passing) 인터페이스 등이 있다.

Interface Errors

주로 발견되는 Interface Errors 를 살펴보자면 아래의 3가지 경우로 나눌 수 있다.

- Misuse - 파라미터 순서를 잘못 넣는 등 호출하는 컴포넌트가 인터페이스를 잘못 사용하는 경우 - Misunderstanding - 호출하는 측이 호출받는 쪽의 동작 방식에 대해 잘못된 가정을 하여 발생하는 오류, - Timing errors - 데이터를 요청하는 쪽과 제공하는 쪽의 작동 속도가 달라서 과거의 잘못된 정보에 접근하는 오류

시스템 테스트 (System testing):

개발 테스트의 가장 마지막 단계로, 모든 단위와 컴포넌트(외부의 기성 시스템이나 타 팀이 개발한 모듈 포함)를 하나로 통합하여 전체 시스템을 테스트한다. 완전히 통합된 환경에서 컴포넌트들이 정상적으로 호환되는지, 적절한 시점에 올바른 데이터를 전송하며 상호작용하는지를 점검한다.

개별 모듈 단위에서는 관찰할 수 없고 결합된 상태에서 비로소 나타나는 비기능적 요구사항인 창발적 특성(Emergent Behavior) 를 확인할 수 있는 필수적 단계라고 볼 수 있으며, 개발팀이 수행하는 시스템 테스트는 여전히 내부 시스템의 버그를 찾아내기 위한 결함 테스트에 목적을 둔다는 점에서 2단계인 Release Testing과는 명확하게 구별되고 1단계인 Development Testing에 포함된다.

2단계: 릴리스 테스트 (Release Testing)

릴리스 테스트는 개발팀 외부에서 사용할 목적으로 특정 소프트웨어의 릴리스 버전을 테스트하는 것을 말한다. 고장 여부, 명세된 기능과 성능, 신뢰성을 제대로 제공하는지를 확인하는 단계로 볼 수 있다.

주 목적은 결함 테스트(Defect Testing)인 개발 테스트와 다르게 시스템이 외부 사용자를 위해 제공되기에 충분히 훌륭한지에 대해 확신을 주기 위한 확인 테스트(Validation Testing) 의 성격을 가지고, 또한 명세서의 내용에만 의존하여 테스트를 설계하기에 블랙박스(Black-Box) 테스팅으로 진행된다.

이외에도 여러 테스트를 진행하게되는데, 사용자의 실제 사용 프로필을 반영해 시스템 성능이 허용 범위를 넘어서 수용할 수 없을 때까지 부하를 꾸준히 증가시키는 성능 테스트와 고장이 났을 때의 반응을 볼 수 있는 스트레스 테스트도 수행한다.

3단계: 사용자 테스트 (User Testing)

시스템 내부에서 아무리 포괄적인 테스트를 거치더라도 사용자의 실제 작업 환경에서 발생하는 예상치 못한 영향(신뢰성, 성능, 내구성 등)을 테스트 환경이 완벽히 복제할 수는 없으므로, 고객과 잠재 사용자가 직접 시스템 테스트에 참여하는 필수 단계다.

총 3가지의 테스트로 분류되며, 첫째로 1)알파 테스트 (Alpha testing) 는 실제 사용자가 시스템 '개발자 측의 사이트(환경)'에 와서 개발팀과 함께 소프트웨어를 테스트하는 것을 말하고 다음인 2)베타 테스트 (Beta testing) 는 다수의 일반 사용자에게 소프트웨어 릴리스를 배포하여, 사용자들 '자신의 환경'에서 자유롭게 실험해 보고 발견된 문제점들을 개발팀에 제기하도록 한다. 마지막으로 3)인수 테스트 (Acceptance testing) 는 최종 고객이 이 소프트웨어 시스템을 개발팀으로부터 인수하여 고객의 실제 운영 환경에 공식적으로 배포(deploy)할 것인지를 최종 결정하기 위해 직접 수행하는 과정을 말한다.

대규모 데이터의 분류와 저장, 검색에 초점을 맞추는 일반적인 정보 시스템과 달리, 임베디드 시스템은 더 큰 시스템 내부에 논리적으로 통합된 부품으로서 연산 자체가 주 목적이 아닌 시스템을 말한다.

대규모이며 수명이 길고, 실시간 응답과 고장시 안전을 보장하는 신뢰성이 필수적이다. 또한 비동기적이고 병렬적인 특성을 가지며 분산된 환경에서도 동작하는 경향이 있다.

응답 속도에 따른 분류

응답 속도에 따라 일괄 처리(batch), 대화형(interactive on-line), 실시간 시스템(real-time)으로 분류할 수 있다.

이 때 batch 시스템은 결과가 언제 오는지는 상관하지 않는다. 실시간 시스템(real time)은 time-deadline이 존재하는 시스템을 말한다.

실시간 시스템의 임계성

데드라인의 엄격성으로 Hard와 Soft로 구분이 가능하고 실행 속도에 따라 Fast와 Slow로 구분할 수 있다.

임베디드 시스템 특징

임베디드 시스템을 설계할 때, 3가지의 특성을 중심으로 고려해야하는데 환경, 성능, 고장 모드 이렇게 3가지로 이뤄진다. 이 3가지 모두를 고려할 수 있어야 한다.

1. Environmental Aspects

임베디드는 일반적으로 PC와 달리 물리,전기적으로 가혹한 환경에 노출되는 경우가 많아 이를 견딜 수 있어야한다. 그래서 온도, 전기적 간섭이 강한 공간, 장기 유지보수의 설계까지 반영되어야한다.

2. Performance Aspect

임베디드 시스템의 설계자는 시스템이 환경과 상호작용하며 내야하는 성능을 예측해야한다. 정해진 주기에 따라 지속적으로 백그라운드에서 수행되어야하고, 외부의 무작위 이벤트를 즉각 반응해서 처리해야한다.

3. Failure and their effects

시스템의 하드웨어나 소프트웨어는 수명 주기 내에 어떤 이유로든 반드시 고장이 발생할 수밖에 없다는 것을 전제로 한다. 따라서 예외 처리 매커니즘을 필수적으로 포함해야한다.

Dependable Software

3가지 품질 속성

신뢰성있는 소프트웨어(Dependable SW)는 단순히 결함이 없는 상태를 넘어 3가지 핵심 품질 속성을 충족해야한다.

• 정확성(Correctness) 프로그램이 요구사항 명세서와 일치하는지 나타내는 정적(static)인 속성이다. 오류가 발생하면 부정확한 결과를 보내는 것보다 아무 결과를 내보내지 않고 시스템을 멈추는 것이 낫다는 것을 의미한다.

• 신뢰성(Reliability) 프로그램이 요구되는 정밀도에 맞춰 의도된 기능을 실제로 얼마나 잘 수행하는지 나타내는 동적(dynamic)인 속성이다. 런타임 중에 고장이 발생하는 빈도를 최소화해서 서비스가 중단 없이 유지되도록 하는 것이 중요하다는 것이다.

• 안전성(Safety) 시스템이 정상적이거나 비정상적인 상황에서 작동하더라도 인명 피해나 재산상의 손상을 초래하는 위험없이 작동할 수 있는 능력이다. 고장이 나더라도 그것이 치명적인 사고로 이어지지 않도록 방어하는 것이다.

고장 발생 시 시스템 동작 전략

완벽한 소프트웨어는 없으므로 고장이 발생하면 시스템이 어떻게 반응하고 대처할 것인지를 4가지 전략에 따라 동작한다.

• Fail-operational (운영 유지): 고장이 발생한 상황에서도 전체 서비스를 온전히 유지하며 작동하는 방식이다.
• Fail-soft (성능 저하 운영): 고장이 존재할 때 시스템의 성능이나 서비스 수준은 어느 정도 저하되더라도, 동작 자체는 계속해서 유지하는 방식이다.
• Fail-hard (즉시 중단): 고장이 발생하면 전체 시스템을 즉시 완전히 멈추게(Halt) 하는 방식이다.
• Fail-safe (안전 중심 중단): 정상적인 시스템 운영을 복구하려고 노력하는 대신, 고장으로 인해 발생할 수 있는 위험이나 피해를 제한하고 최소화하는 데 목적을 두는 방식이다.

Software Error

소프트웨어 오류의 3가지 범주

소프트웨어 오류란 오작동을 일으키는 프로그램의 요소들을 총괄한 내용인데, 크게 3가지 범주로 나눌 수 있다.

시스템 설계 오류 설계자가 시스템이 작동할 물리적 환경이나 동작 시간에 대해 잘못된 가정을 내렸을 때 발생하는 치명적 오류이다.

설계 및 코딩 오류 개념을 실제 컴퓨터 코드로 번역하는 과정에서 발생한다. 우리가 흔히 생각하는 개발 중에 일어나는 오류들이 거의 대부분 여기에 포함된다. 소프트웨어가 고객의 의도나 의미를 잘못 이해한 의미론적 오류, 우발적 무한루프, 데드락 등의 논리적 오류, 0으로 나누기나 오버플로우 등의 알고리즘적 오류 등으로 구성된다.

환경적 요인 소프트웨어가 정상적인 환경에서 작동할 때 발생하는 하드웨어의 오작동, 사람의 실수, 예상치 못한 외부 간섭 등 예측 불가능한 오류이다. 이는 설계 단계에서 완벽하게 제거할 수 없기에 심층 분석으로 문제 발생 가능성을 최소화 해야한다.

좋은 소프트웨어 설계를 위한 원칙

나쁜 소프트웨어가 만들어지는 원인은 경영진 또는 상관에게 문제가 있거나 설계가 부족한 상황, 전문성 결여, 문서화 부족, 프로토타이핑 부재 등의 여러 문제들을 꼽을 수 있다.

그럼 반면 좋은 소프트웨어 개발의 기본은 무엇일까 1) 우선 명확한 요구사항이 정의되어야 한다. 사용자가 무엇을 원하는지 잘 파악하는것이 중요하다는 것이다. 그리고 2)설계를 할 때 목표 달성이 가능한 수준이어야하고, 3)관리에 있어서 유연한 프로젝트 조직으로 구성이 되어야한다. 마지막으로 4)테스트가 쉽게 이뤄지도록 설계와 검증된 방법을 사용하는 것이 필요하다.

이식성과 재사용성 또한 좋은 소프트웨어 하면 빠질 수 없는데, 검증된 컴포넌트를 사용해서 작업을 하면 설계, 코딩, 디버깅 시간 및 비용이 감소하고 신뢰성을 높일 수 있다. 이식성과 재사용성을 고려하면 소프트웨어가 더욱 효율적으로 구성될 수 있다.

Defensive Programming

오류 회피와 방어적 프로그래밍

우리는 기본적으로 오류에 대해 회피를 해야한다. 오류를 회피한다는게 무슨말이냐, _오류 회피는 기본적으로 잘못된 값이 들어오거나 잘못된 접속이 발생했을 때 큰 문제가 발생하지 않으면 가능한 회피_하는 방향으로 움직이는 것이다. 이러한 오류 회피를 실질적인 프로그래밍에 접목하면 "방어적 프로그래밍"이 된다.

방어적 프로그래밍은 예상치 못한 입력에도 소프트웨어가 계속 수행을 보장할 수 있도록 한 프로그래밍 기법이다. 방어적 프로그래밍은 목표가 존재하는데 오류가 발생했을 때, 도입 자체를 방지하고, 발생 시 감지는 필수적이며 마지막으로 시스템의 반응을 제어한다.

방어적 프로그래밍이 모토로 이끄는 문장이 있는데 "Garbage in, nothing out"이라고 하며, 좋은 프로그램은 잘못된 값이 들어오면 이를 아무것도 내보내지 않는 방식으로 방어해야한다.

단언문(Assertion)의 활용과 가이드 라인

단언문이란 개발 중에 프로그램이 예상대로 작동하는지 스스로 확인하도록 하는 코드이다. 복잡한 프로그램에서 잘못된 인터페이스나 코드 수정시에 발생한 오류를 빠르게 찾아내는 데에 유용하다. 주로 절대 발생하면 안되는 조건에만 사용한다.

그리고 Assertion 내에는 실행코드를 넣으면 안된다. 만약 넣게되면 그 코드가 배포 등을 했을 경우 무시될 가능성이 존재하기 때문이다. 그리고 마지막으로 사전 조건과 사후 조건을 문서화하고 검증할 때도 사용한다.

Exception Handling

오류처리 기법

오류를 처리하는 기법은 여러가지가 있는데 아래에 간결하게 정리해보면 다음과 같다.

• 중립적인 값 반환 : 안전한 값을 반환하는 방식이다.
• 다음의 유효한 데이터로 대체 : 손상된 기록을 건너뛰고 다음 값을 넣는다.
• 이전과 동일한 응답 반환 : 이전에 출력한 값을 이어서 출력하는 형태이다.
• 가장 가까운 합법적 값으로 대체 : 최대/최소 허용치로 값을 조정한다.
• 파일에 경고 메세지 기록 : 메세지만 남기고 계속 수행한다.
• 에러 코드 반환 : 예외 처리를 통해서 오류의 발생을 알린다.
• 에러 처리 루틴/객체 호출 : 중앙 집중식이며 코드를 재사용할 때 종속성을 계속 호출해야한다.
• 에러 발생 위치에 바로 메세지 표시 : 흔히 단순히 생각하는 출력구문을 이용하는 것이다.
• 가장 적합한 최소한의 방법으로 처리 : 유연성은 높지만 시스템 전체의 정확성/강건성은 못 맞출 수 있다.
• 시스템 종료 : 안전 필수 애플리케이션에서 유용하다.

딜레마 : 강건성(Robustness) vs 정확성

강건성과 정확성이 있다. 여기서 _강건성_이란, 소프트웨어가 중단되지 않고 어떻게든 작동하도록 하는 것을 말한다. 설령 기능적으로 성능이 저하되더라도 실행시키는 것에 의미를 둔다. 반대로 _정확성_이란 소프트웨어가 고장이나 에러가 발생하면 심각한 문제를 초래할 가능성이 높기에 부정확한 결과보다 아예 결과 자체를 반환하지 않는 것을 말한다.

소프트웨어는 그 종류에 따라서 강건성을 더 중요시할수도, 정확성을 중요시할수도 있다. 만약 에어백이나 방사선 치료기와 같이 조금의 문제도 발생해서는 안되는 기기에는 정확성을 요할 것이고, 그냥 우리가 자주 쓰는 유튜브나 서비스 프로그램들은 강건성에 힘을 더 주어서 중단되지 않고 이어가는 것을 중요시해야한다.

프로그래밍 언어 수준의 예외처리

Exception은 코드가 스스로 처리하지 못하는 예기치 않은 예외 이벤트를 마주쳤을 때, 이를 자신을 호출한 코드쪽으로 전달하는 특정 매커니즘이다. 언어에 따라서 예외처리를 하는 표현의 방식은 다르다는 점을 유의해서 접근해야한다.

이렇게 임베디드 시스템와 관련된 내용을 알아보았다.

디자인 패턴은 대규모 시스템 설계에서 특히 중요한 지점을 가진다.

공통의 설계 어휘를 통해서 1) 개발자들간의 의사소통을 명확하게 가져갈 수 있고, 2) 설계 복잡성이 감소하고 재사용성을 촉진한다. 또한 3) 시행착오를 방지하고 4) 유지보수성을 향상시키는 장점을 가진다.

패턴의 목적에 따라서 생성, 구조, 행위 패턴으로 구분해서 분류한다.

인터페이스 관점의 상속

상속을 통한 내부 은폐

인터페이스 관점에서 상속은 내부 은폐의 도구로 사용되기도 한다. 클라이언트에게 Parent 클래스만 보이게 하여 내부의 복잡한 상황들을 숨긴다.

Parent로 Child를 Abstract했다고도 볼 수 있다. 주로 서브 시스템 간의 커뮤니케이션에서 잘 사용된다.

재귀적 구조 정의

재귀적인 구조관계를 상속으로 정의할 수 있는데 디렉토리는 파일이기도 하지만 파일을 포함하고 또 다른 디렉토리도 포함한다.

이걸 단순하게 이야기해서 결론만 도출하면 클라이언트에게 모두 File 클래스로만 인지되며 내부의 복잡한 재귀적인 정의들은 숨겨버린다.

생성 패턴 (Creational Design Patterns)

Singleton

하나의 애플리케이션 내에서 특정 클래스의 인스턴스를 오직 하나만 생성해 보장하고, 어디서든 그인스턴스에 접근할 수 있도록 하는 생성 디자인이다.

시스템 전체를 포괄적으로 관리해야 하는 객체는 무분별하게 여러 개의 객체가 만들어지는 것을 통제해야할 때 사용된다. 구현 원리는 아래와 같다.

생성자 은닉

클라이언트가 new 키워드를 이용해 함부로 인스턴스를 만들지 못하도록 생성자를 protected나 private로 숨긴다.

Static 변수와 메서드 활용

클래스 내부에 유일한 인스턴스를 저장할 static 포인터를 둔다. 외부에서는 instance()라는 static 메서드만으로 객체에 접근한다

지연 생성

instance() 메서드가 호출되면, 인스턴스가 없는 경우(NULL), 최초로 하나 생성하고, 이미 생성된 경우 기존의 것을 그대로 반환한다.

Prototype

생성할 객체의 종류를 명시하는 Prototypee 객체를 만들어두고 새로운 객체가 필요할 때, 구체적인 생성자(new)를 부르는 대신 이 객체를 Clone하여 새로운 객체를 만든다.

Clone() 메서드 활용

미리 만들어둔 원형의 객체(Prototype)에 자신을 복제하는 Clone() 메서드를 정의해둔다.

클라이언트 추상화

상위 인터페이스(prototype)에 Clone()을 호출하기만 하면 실제 할당된 객체가 무엇이든 알아서 새 객체가 만들어진다.

구조 패턴 (Structural Design Patterns)

Facade

내부와 외부 시스템은 강한 연결을 하지 않는다. 내/외부의 시스템을 연결할 때, facade interface를 만들어 이를 통해서만 소통하게 한다.약한 연결로 소통하는 방식으로 이어간다.

클라이언트가 서브 시스템의 내부를 알 필요 없이 퍼사드(창구)하고만 통신하므로서 의존성을 최소화하고 로직이 변해도 클라이언트에게 영향이 덜해 유지보수도 쉽다.

Adapter

우리가 생각하는 그 어댑터가 맞다. 각기 따로 개발된 클래스나 외부 라이브러리를 수정없이 기존 시스템에 통합할 수 있다. 호환성을 보장해주기 위해 존재하며 클라이언트가 원하는 target 인터페이스로 변환해주는 패턴이다.

Composite

부분-전체 관계를 나타내기 위해 객체들을 트리로 구성하는 패턴으로, 클라이언트가 단일 객체와 이들이 묶인 복합 객체를 동일한 방식으로 취급한다.

행위 패턴 (Behavioral Design Patterns)

Template Method

여러 클래스에서 공통으로 사용되는 메서드를 템플릿화하여 상위 클래스에서 정의하고 하위 클래스마다 세부 동작 사항을 다르게 구현하는 것이다.

변하지 않는 기능들만 상위 클래스에 두고 자주 변하는 기능들을 하위 클래스에 둠으로서 하위 클래스를 수정해서 업로드하면 상위 클래스에 잘 적용되는 것을 목적으로 한다.

Observer Pattern

옵저버 패턴은 옵저버들이 관찰하고 있는 대상의 상태가 변하면 대상이 옵저버들에게 통지하고 옵저버들은 알림을 받고 조치하는 행동 패턴이다.

다른 디자인 패턴들과는 다르게 one-to-many의 의존성을 가진다. 일종의 interactive한 디자인 패턴이라고 볼 수 있다.

행위 모델 : Sequence Diagram

Syntax

철저히 클래스가 아닌 객체 단위로 그려야한다. 아래에 표기법과 관련된 내용을 그림으로 정의해둔다.

메세지의 주요 유형

메세지는 객체 간 서비스를 호출하는 리퀘스트를 의미하며, 화살표의 모양에 따라 실행 방식이 다르다.

Asynchronous message는 선으로만 된 화살표로, 상대의 처리 완료를 기다리지 않고 바로 다음 작업을 병렬로 진행한다.

Call message는 꽉찬 화살표로, 호출한 객체는 수신한 객체의 작업이 끝나고 리턴될 때까지 기다린다.

Reply message는 점선 화살표로 표기하며 처리가 끝나면 제어권과 결과값을 원래 객체에 돌려주는 메세지다.

Lost message는 외부 알 수 없는 곳으로 날아가는 예외적인 이벤트의 흐름을 나타낸다

Found message는 외부 알 수 없는 곳에서 날아오는 예외적인 이벤트의 흐름을 나타낸다

Combinded Fragments

기존의 시퀀스 다이어그램에서 if문이나 반복문을 표현하기 어려웠으나 UML 2.0부터 복합 프레그먼트를 도입하여 로직을 표현한다.

alt는 if-else 조건문을 나타내고, opt는 조건이 참일 때만 실행되는 단일 if문이다. loop는 특정 조건을 만족하는 동안 메세지 교환을 반복하며 par은 여러 흐름이 동시에 수행됨을 의미한다.

neg는 절대 발생해서는 안되는 시나리오를 나타내고, assert는 반드시 발생해야하는 올바른 흐름을 나타낸다. 마지막으로 critical은 임계 영역(병렬 상황에서 한번에 실행을 보장)을 나타낸다.

추가로 ref도 존재하는데, 외부의 시퀀스 다이어그램을 참조하기 위해 가져다 쓰는 것을 의미한다.

Pitfalls in Sequence Diagram

구조적 모델은 "무엇이 상호작용하는가"에 초점을 맞춰서 시스템의 정적인 구조와 뼈대를 모델링하는 것이 주의 핵심이다.

구조적 모델의 목적

객체는 Application Domain에서 핵심이 되는 사물, 아이디어, 개념 등을 나타내는 것이다. 클래스 다이어그램, 오브젝트 다이어그램을 작성하기 위한 규칙이나 스타일 지침 그리고 구조 모델간의 관계를 이해하는 것을 목적으로 한다. Structural 모델의 가장 주요한 목표는 문제 영역에 포함된 핵심 데이터를 발견하고 객체의 구조적 모델을 구축하는 것이다.

구조적 ViewPoint

ViewPoint를 표현하기 위해서 다양한 다이어그램을 제공하고, 컴포넌트 다이어그램부터 클래스 다이어그램, 객체 다이어그램 등이 대표적으로 활용된다.

Class Diagram

클래스 다이어그램에서는 시스템의 정적인 구조를 구성하는 핵심 단위인 클래스는 사각형 박스로 그려지고, 내부적으로 크게 3가지의 엘리먼트로 나누어 표현된다.

Class Name

말 그대로 클래스의 이름을 보이며, 가장 위칸에 위치하고 문제 도메인에서 식별된 해당 객체의 이름을 나타낸다.

Attributes

이름 다음에 오는 중간 칸을 이용하며, 클래스가 내부적으로 관리하고 유지하는 데이터를 의미한다.

표기법은 아래와 같다. [visible] name : type-expression [=initial-value]

가시성(Visibility)

이 때, Visibility는 총 3가지로 표기할 수 있는데, 우선 +는 public을 의미하며 외부의 누구나 접근 가능하고, -는 반대로 private를 의미해 해당 클래스 내부에서만 접근 가능하다. 마지막으로 #은 protected를 의미해 자식 클래스에게만 접근을 허용한다.

정적 인스턴스

속성 밑에 밑줄이 그어서 표기하며, 클래스 차원에서 메모리에 유일하게 하나만 존재하여 공유되는 정적(Static) 변수를 의미한다.

Operation

가장 아랫쪽 칸을 차지하며, 클래스가 외부 클라이언트에게 제공하는 서비스를 정의한다.

표기법은 아래와 같다. [visibility] name([parameter-list]) [: return-type]

속성과 마찬가지로 오퍼레이션에 밑줄이 그어져 있으면 Static Method를 뜻한다.

클래스 간의 주요 관계

Generalization(Inheritance)

is-a가 성립하는 부모-자식 간의 관계를 나타낸다. 여러 클래스를 분석하다 공통적인 부분(Attribute or Operation)이 발견되면, 이를 부모 클래스로 뽑아 올려 중복을 없애고 코드를 재사용하기 위해 사용되는 관계이다. 속이 빈 삼각형 화살표와 실선으로 표기한다.

Aggregation(Composition)

전체와 부분을 나타내는 part-of 관계를 가진다. 두 클래스의 결합 강도에 따라서 다음의 두 관계로 세분화할 수 있다.

Strong Aggregation(Composition)

전체와 부분의 생명주기가 동일한 매우 강한 결합의 형태이다. 전체 객체가 소멸하거나 생성될 때, 부품 component도 동시에 생성되고 소멸한다. 표기법으로는 속이 찬 다이아몬드로 표현된다.

Weak Aggregation

부품이 하나의 전체에만 전담되지 않고 여러 다른 객체에서 공유될 수 있는 결합으로 속이 빈 다이아몬드로 표기한다.

Association

상속이나 전체-부분 관계에 속하지 않는 클래스 간의 일반적인 연결 및 사용 관계를 의미한다. 선으로 연결해 표현하고, 관계를 명확히 하기 위해 방향성 화살표나 역할 이름을 덧붙일 수 있다.

가장 중요한 특징은 선 끝에 다중성을 명시해 하나의 객체가 상대방 객체와 몇 개의 관계를 맺는지를 나타낸다.

Dependency

Associate보다 훨씬 약한 연결로 한 클래스의 변경이 다른 클래스에 영향을 미치는 관계이다. 특정 메서드를 실행할 때, 파라미터로 전달받거나 리턴 타입으로 일시적으로만 사용할 때 주로 형성된다. 일반 실선이 아닌 점선 화살표로 표기하여 적용한다.

인터페이스와 스테레오 타입

인터페이스(interface)

실제 동작하는 구현 부분 없이 외부에 제공할 Operation의 시그니처만 모아둔 집합이다. <<interface>> 클래스들이 직접 통신하면 서로 떼어낼 수 없는 Strong Coupling이 발생한다. 인터페이스를 둠으로서 결합의 강도가 줄어들어 Weak Coupling을 유도할 수 있다.

스테레오 타입(Stereotype)

기존에 존재하는 UML의 기본 구성 요소를 확장해 새로운 의미나 종류의 모델 요소를 만들어내는 표기법이다.

아래와 같은 표기법으로 나타낸다. <<>> 다이어그램을 보는 사람이 해당 요소의 용도와 성격을 명확히 이해할 수 있도록 돕는 역할을 한다.

클래스 다이어그램 vs 객체 다이어그램

같은 내용을 정리해도 다이어그램의 종류에 따라서 서로 다른 형태를 띈다. 아래와 같이 클래스 다이어그램과 객체 다이어그램은 서로 다른 모습을 보인다.

객체 식별 및 모델링 프로세스

Object Identification

문제 도메인에 있는 어떤 아이디어나 개념을 소프트웨어 내의 클래스로 뽑아낼 것인가"를 결정하는 단계이다. 총 3가지의 기법으로 클래스 후보군을 추린다.

텍스트 분석

기계적으로 분석하는 방법으로, 문장에서 명사는 클래스나 속성의 후보로, 동사는 오퍼레이션 후보로 추출한다.

브레인 스토밍

팀원들이 한자리에 앉아 시스템에 필요할 듯한 클래스나 속성 등을 토론하며 식별하는 방식이다.

Common object list

비즈니스 도메인에서 보편적으로 클래스로 추출되는 대표적 유형리스트를 참고해 누락된 객체를 찾아내는 방법이다.

역할, 물리적 사물, 사건, 상호작용을 중심으로 알아보게 된다.

CRC 카드

CRC 카드는 다이어그램을 그리기 전, 설계의 결함을 조기에 찾아내고자 작성된다. 주로 Object Identification을 수행하고 작성된다.

Use Case 기반으로 분석을 통해서 초안을 작성하고 브레인 스토밍을 통해 토의한 이후 롤플레잉을 통해서 검증한다. 그리고 이에 대한 결함을 보완하면서 CRC 카드를 기반으로 클래스 다이어그램을 그린다.

CRC카드 앞	CRC 카드 뒤

클래스 유형

Unified Process는 3가지로 클래스를 유형을 나눠 분류한다.

이 전체는 stereotype이며, UML을 정의하면 시스템을 정확히 모델링하는 데 필요한 추가 구성요소를 정의할 수 있다.

Entity Class

영구적으로 DB에 저장되고 유지되어야 하는 데이터 정보들을 기록한다. 예를 들어 계좌나, 학생, 강좌 등 프로젝트에서 중심을 가지는 데이터들 다루는 Class를 말한다.

Boundary Class

시스템과 외부 Actor 간의 상호 작용 및 입출력을 담당한다. 위의 설명처럼 주로 input과 output과 연관된 작동을 주로 이 클래스에 분류한다.

Control Class

복잡한 비즈니스 로직을 연산하거나 알고리즘을 제어하는 것을 주로 담당하는 클래스로 무언가 계산을 해야하는 로직의 경우 이 클래스로 분류된다.

Case Study

Osbert Oglesby 미술품 시스템을 중심으로 앞서 정리한 내용들을 돌아보는 과정을 거친다.

1. System Request & Use Case

Osbert가 그림을 구매할 때 최대 지불 가능 가격을 산정하고, 미술 시장의 새로운 트렌드를 파악해 세금 계산 등을 위해 모든 판매/구매 기록을 유지하고 보고서를 출력하는 시스템을 개발하고자 한다.

이때, Use Case는 아래와같이 4개의 주요 Use Case로 구성된다. 정보 시스템을 한 단락으로 묘사해보면, "예술 작품 구매 의사 결정 과정의 효과를 향상시키기 위해 보고서를 생성할 것이다. 보고서에는 걸작, 명작 및 기타 그림으로 분류되는 그림에 대한 매매 정보가 포함되어있다."로 표현할 수 있다.

2. 엔티티 식별 및 구조 고도화

엔티티를 명사를 추출함으로서 식별하고, 구조를 개선하여 클래스 다이어그램을 명확하게 만들어낸다.

명사 추출

1) 위의 단락에서 명사만을 표기한다. "예술 작품 구매 의사 결정 과정의 효과를 향상시키기 위해 보고서를 생성할 것이다. 보고서에는 걸작, 명작 및 기타 그림으로 분류되는 그림에 대한 매매 정보가 포함되어있다."

2) 추출 결과물을 보면 아래와 같다. { 예술 작품, 구매, 과정, 효과, 보고서, 걸작, 명작, 기타 그림, 그림, 정보 }

3) Entity Class를 추출한다. 추상명사와 동명사 등을 제외하고, 오래 지속되지 않는 것들도 제외한 뒤, 동의어를 제거하면 아래만 남는다. { 걸작, 명작, 기타 그림, 그림 }

고로 이렇게 4개가 Entity Class로 선택된다.

1차 Diagram 구조 개선

우선 각 엔티티 클래스 후보군들을 두고, 클래스 간의 상호관계를 고려한다. 관계를 보면 그림을 기준으로 나머지 클래스들과 포함 관계를 가진다. 따라서 그림(painting) 클래스를 Base Class로, 나머지를 Sub Class로 한다.

2차 Diagram 구조 개선

지금까지의 클래스 다이어그램을 기준으로 Pricing Algorithm을 반영하지 않았기에 이제 이 부분을 고려해야한다.

걸작(masterwork)을 다룰 때, 정보 시스템은 우선 같은 화가의 명작(masterpiece)인 것처럼 최대 지불 금액을 계산한다. 고로 걸작(masterwork)은 명작(masterpiece)의 모든 attribute를 가져야한다. 또한 자신의 속성도 가져야한다.

3차 Diagram 구조 개선

위의 클래스에서 고려하지 못한 pricing algorithm은 경매 기록이 있는 그림과 구매를 고려중인 그림 사이의 유사도 계수를 계산한다는 것이다.

그렇게 되면 경매 기록이 있는 그림 클래스가 필요하다. 이는 Painting class의subclass여야 하며, 현재 전시된 그림과는 관련성이 없어서 표현하면 아래와 같이 표현한다.

4차 Diagram 구조 개선

3번째까지도 fashionability 모델링이 아직이며 F*A 공식으로 상품의 최대 지불가격을 정해야한다. (F = 작가 유명도 상수, A = 그림 크기) 또한 Fashionability Class가 필요하다. 이러한 고려사항을 적용하면 아래와 같아진다.

상세 클래스 다이어그램

클래스 다이어그램에 필요한 요소를 상세히 다 넣으면 아래와 같은 그림으로 그릴 수 있다.

3. 바운더리 클래스 식별

시스템과 유저간의 입력/출력을 담당하는 UI 요소를 도출한다. 4개의 Use Case 스크린을 포괄적으로 처리할 클래스를 둔다. 이후 보고서들의 내용은 각기 다르므로 3개의 독립적 보고서 클래스를 분리해 바운더리 클래스를 도출한다.

Purchase Report, Sales Report, Future Trends Report, User Interface Class

4. 컨트롤 클래스 식별 및 최종 완성

데이터를 가공하고 계산하는 복잡한 로직을 별도의 클래스로 도출한다. 가격을 계산하는 알고리즘을 처리하기 위해 클래스를 만들고 새로운 트렌드를 분석하는 Compute Future Trends 클래스를 추가해 4개의 컨트롤 클래스를 식별한다.

Class Concept

클래스는 캡슐화 되어 구성되며, Interface와 Body로 나눠져있다.

• Interface Interface는 보여지는 영역으로 서비스를 제공하는 다소 추상적인 영역이다.
• Body Body는 Interface와 달리 숨겨져있으며 object의 기능을 구현해둔 요소를 말한다.

이 때, 캡슐화(Encapsulation)는 interface와 body를 구분해서 불필요한 정보를 외부에 노출하지 않는 것을 말한다.

Default Constructor

arguments를 가지지 않는 Constructor를 말한다.

만약에 Class가 Constructor를 가지지 않는다면 시스템은 자동적으로 Default Constructor를 제공한다. C++에서 Class의 다른 Constructor가 존재한다면 자동적으로 만들어주지 않기 때문에, Array를 재정의할 때 에러가 발생한다.

명시적 선언이 필수적인 이유는 만약 개발자가 특정 값을 넣기 위해 파라미터가 있는 Constructor를 만들게 되면, 시스템은 더 이상 Default Constructor를 만들어주지 않는다.

Inheritance Concept

상속은 클래스 간의 관계를 정의할 때, 가장 핵심이 되는 개념이다. 상속은 기존 브모 클래스의 특성을 자식 클래스가 그대로 물려받아 새로운 클래스를 만드는 매커니즘이다.

상속의 가장 큰 목적은 코드의 중복을 피하고 재사용성을 극대화하여 효율적인 코드 관리를 하기 위함입니다.

클래스 중복 관리 및 재사용

부모 클래스는 Base Class, Parents, Super Class 등으로 불리고, 자식 클래스는 Derived Class, Child, Sub class로 불린다.

새로운 클래스는 이미 존재하는 클래스의 모든 정보를 재사용하면서 새로운 정보를 추가하거나 이미 존재하는 정보를 수정할 수 있다.

서브 클래스의 생성

서브 클래스의 객체가 생성될 때, 부모 클래스의 데이터도 함께 초기화 되어야하므로, 생성자에서 부모 클래스의 초기화(super)를 호출하는 과정을 말한다. 절차에 대해서 알아보면, 1) 부모와 자식 클래스 모두에 데이터를 입력한다. 그 다음 2) 생성자를 호출하여 객체를 생성해 부모/자식 클래스를 모두 초기화한다. 또한 자식 클래스의 생성자의 초기화 목록에서 부모 클래스의 생성자를 호출한다.

타입 변환

상속에서 파생되는 아주 중요한 요소인 Polymorphism을 곧 배우게 될텐데, 그 바탕이 되는 규칙으로 부모 클래스가 요구되는 변수 자리에 자식 클래스의 객체가 대신 들어갈 수 있다는 것이다.

말 그대로 자식은 부모 대신 자식 클래스가 적용되는 것은 가능하지만, 부모는 자식 대신 적용될 수 없다는 것이다.

Overriding & Polymorphism

Overriding

오버라이딩은 부모 클래스로부터 상속받은 메서드를 자식 클래스의 목적에 맞게 재정의하는 기법이다. 총 3가지 목적으로 오버라이딩을 진행할 수 있는데, 각각 확장, 적응, 최적화이다.

확장(Extension)

부모 클래스의 기존 행위를 그대로 유지하면서, 자식 클래스만의 추가적인 동작을 덧붙일 때 사용한다.

부모 클래스가 가지는 메서드를 이용하면서 그 메서드에 자식 클래스의 정보를 이용해 추가적인 기능을 확장할 수 있다.

적응(Adaptation)

Sub Class의 행동을 명시적으로 나타내기 위해 Super Class의 행동을 재정의한다. 다시 말하면 부모 클래스의 행위를 자식 클래스의 상황에 맞게 명시적으로 변경해 적용할 때 사용한다.

최적화(Optimization)

특정 자식 클래스에 맞춰 퍼포먼스(계산 속도 등)를 극대화하는 알고리즘으로 대체할 때 사용한다. 성능을 위해 오버라이딩하는 역할이다. 다소 추상적인 개념이라 이해가 안될 수 있지만, 예를 들어 다각형 면적을 구할 때, 삼각형은 공식이 존재할 때, 이를 overriding해서 성능을 향상시킬 수 있다.

동적 바인딩

동적 바인딩은 실행 시점에 변수에 할당된 객체를 파악해 객체에 맞는 함수를 동적으로 실행하는 매커니즘이다. 클래스에 대한 동적 바인딩이 일어나기에, 오버라이딩 된 메소드가 클래스에 맞게 자동으로 선정된다.

정적 바인딩과는 시점이 다른데, 동적 바인딩은 Run Time 시점이지만 정적 바인딩은 Compile Time에 할당된다.

다형성(Polymorphism)

Extend, Implement 관계인 다른 클래스의 객체를 부모 클래스나 인터페이스 형식을 변수에 담을 수 있고, Overriding 된 이름이 같은 메소드가 해당 클래스에 맞게 실행되는 것이다. 즉, 코드는 한 줄이지만 상황에 따라 다양한 형태로 해석되고 동작한다는 뜻이다.

여러 종류의 자식 객체들을 각각의 타입으로 관리하지 않고, 부모 타입의 배열로 하나로 묶어 관리한다.

Abstract Class & Interface

Abstract Class

하나 이상의 추상 메서드를 가진 클래스이다. 이때 추상 메서드란 선언만 하고 구현을 안한 메서드를 말한다.

추상클래스가 존재하는 이유는 다형성 코드를 만들기 위해서이다. 여러 자식 클래스를 하나로 묶어 효율적으로 관리하려면 부모클래스의 배열을 만들어야 한다.

Concrete Class

모든 동작을 구현한 클래스로 객체를 가진다. 실질적으로 Abstract와 완전히 반대되는 개념이다.

인터페이스의 개념

Interface는 포함된 모든 메서드가 구현부가 없는 추상 메서드로 이뤄진 극단적인 추상 클래스를 말한다. 일반적인 변수는 가지지 않는다. Interface는 항상 public, abstract이므로 별도로 public, abstract로 선언할 필요 없다.

Java에서 다중 상속(부모가 여러명인 경우)은 금지하지만, 클래스가 하나의 부모를 상속받으며 여러 인터페이스를 동시에 다중으로 구현하는 것은 허용된다.

둘 이상의 인터페이스를 구현하려면 클래스 선언에서 implements 키워드 뒤에 쉼표로 구분된 인터페이스 이름 목록을 사용한다.

인터페이스 사용

다른 클래스간 Communication 과정에서 사용되고, 오직 추상적 명령으로만 이루어지고 컴포넌트를 연결할 때 사용된다.

Strong Coupling은 Concrete Class를 가르키는 연결을 말하고, Weak Coupling은 Abstract Class나 Interface를 가르키는 연결을 말한다.

Introduction

요구사항 명세가 완벽하게 정의되었다면, 이후에는 무엇을 해야할까?

Use Case는 입력에 따른 반응을 기반으로 한 기술이다. 시스템의 내부는 요구사항 명세가 명확해져도 블랙박스의 형태를 가진다. 고로 개발자인 우리는 블랙박스를 화이트박스로 바꾸는 절차를 거쳐야 하고, 이를 위해 설계(architecture)를 해야한다.

Architectural Design이란?

아키텍쳐 디자인은 Software System이 어떻게 구성되는지 이해하고 그 System의 구조를 전체적으로 디자인하는 것을 말한다. 개발 요구사항과 디자인 사이에서 중요한 역할을 하며, 시스템의 주요 구조적 구성요소와 관계 사이에서 정의한다.

시스템의 세가지 핵심은 1) 기능 (요구 분석에서 결정), 2) 구조 (아키텍처 디자인, 클래스 다이어그램) , 3) 행위 (시퀀스 다이어그램, State 다이어그램) 으로 정의할 수 있다.

설계는 Top-Down 방식으로 진행되고, 점점 세분화되게 설계한다. 컴포넌트를 구성하면서 구조가 짜이면 각 컴포넌트 간의 행위를 정의한다. 아키텍처 디자인은 디자인과 요구 엔지니어링 사이를 연결하는 '링크'이고, 아키텍처 디자인의 장점은 이해 당사자 사이의 소통을 쉽게해주고 큰 규모의 재사용이 가능하며, 시스템 분석이 쉬워지는 장점을 가진다.

Architectural Patterns

시스템이 서로 통신하는 구성 요소들의 집합으로 어떻게 구성되는지 설명한다. 이러한 아키텍처를 명시적으로 설계함에 있어서 장점은 아래와 같다. 아키텍처 패턴은 지식을 표현하고 공유하고 재사용하는 일종의 수단이다. 다양한 환경에서 시도되며 디자인 관행을 양식화해서 설명한 것으로 볼 수 있다. 주로 이런 Pattern은 표나 그래프의 형식으로 표현한다.

MVC

MVC 패턴은 Software 디자인 패턴의 일종으로 Model, View, Controller로 분리하여 유지보수성과 확장성을 높이는 방식을 말한다.

간단한 구조 형태로 정의된 이 패턴의 로직은 User가 Controller를 통해서 조작을 하면 Model을 통해서 데이터를 가지요고 View가 그 정보를 바탕으로 시각적인 요소로 User에게 전달한다. 간결하게 보자면 아래와 같은 구조로 형성된다.

MVC 패턴은 시스템 데이터의 상호작용과 presentation을 분리한다. MVC의 장점은 데이터와 표현 방식 간의 독립적인 변화를 허용하고 그 반대의 경우도 가능하다는 것이다. 모델의 데이터가 변화하면 여러 뷰에 동시에 업데이트가 가능해 GUI 기반 시스템이나 웹 애플리케이션에서는 거의 표준처럼 사용된다.

Layered Architecture

시스템을 여러 계층으로 구성하고, 하위 계층이 바로 위 상위 계층에 코어 서비스를 제공하는 구조이다. 시스템은 최하위 계층부터 서비스를 제공하는 구조까지 계층이 구성되어있다. 계층적인 구조답게 interface가 변경되면 인접 계층에만 영향을 미친다. interface에서 여러 계층을 통해 최하위 계층에 존재하는 OS, DataBase까지 계층을 구성해서 운영한다

기존 시스템 위에 새로운 기능을 구축하거나 여러 팀에 개발이 분산되고 각 팀이 하나의 계층을 책임지는 경우에 주로 사용하며, 장점으로 인터페이스가 유지되면 전체 계층의 교체가 가능하고 각 계층에 중복 기능을 제공할 수 있다.

가장 단순한 방식인 만큼 단점도 명확히 존재하는데, 첫번째로 층간분리가 명확하게 발생하지 않는다는 점이다. 이에 대한 구현의 난이도 또한 높다. 둘째로 서비스의 요청에 따라 해석 단계가 여러 차례 존재하기에 성능 문제가 발생할 수 있다. 이로 인해 불필요한 계층간 이동이 발생하여 성능저하가 발생하게 된다.

Repository Architecture

모든 데이터가 중앙 저장소에 관리되며, 시스템의 서브 컴포넌트들은 서로 직접 통신하지 않고 오직 중앙 저장소를 거쳐 데이터를 주고 받는다.

데이터를 교환하는 일종의 보조 시스템의 역할을 담당한다. Repository는 2가지 일을 수행하는데 그 일들은 아래와 같다. 첫째로 공유 데이터는 중앙 DB 또는 repository에 저장되며, 모든 하위 시스템에서 접근할 수 있습니다. 둘째로 각 하위 시스템은 자체 데이터베이스를 유지하고 데이터를 다른 하위 시스템에 전달한다.

장기간 대량 정보가 생성되는 시스템에서 주로 사용하고, 컴포넌트가 모두 독립적이어서 개발하기 편하고 데이터를 일관성 있게 관리할 수 있다는 장점이 있지만, 저장소가 문제가 생기면 전체 시스템에 문제가 생긴다는 점과 모든 통신을 저장소를 통해 구성하는 것이 비효율적인 단점이 존재하기도 한다.

Client-Server Architecture

독립적인 특정 서비스를 제공하는 '서버'의 집합과 네트워크를 통해 서버들에 접속하는 서비스를 이용하는 '클라이언트' 집합으로 분산된 모델이다. 서버 1개와 다수 클라이언트가 소통하는 구조로, 여러 컴포넌트에 걸쳐 분산을 보이는 분산시스템의 모델이다.

주로 공유 DB의 데이터를 다양한 위치에서 접근할 때 사용하고, 시스템의 부하가 가변적일 때에도 적용할 수 있다. 서버를 네트워크 상에 분산시키거나 복제해 부하를 조절할 수 있다. 하지만 시스템의 성능이 네트워크 상태에 의존하기에 예측이 어렵고 특정 서버가 다운되거나 DoS공격을 받게되면, 서비스가 중단될 위험이 있다.

Pipe And Filter Architecture

우리가 흔히 아는 Unix Shell이 이 Pipe and filter 구조로 만들어졌다. 입력 데이터를 각 컴포넌트(필터)가 한가지 형태의 데이터 변환으로 처리한 이후 Pipe를 통해 다음 컴포넌트로 넘겨주는 구조이다. interactive한 시스템에는 적합하지 않지만 순차적으로 처리하는 경우에는 주로 사용할 수 있다.

하나의 컴포넌트에서 다른 컴포넌트로의 데이터 흐름을 말한다. 주로 흔히 데이터 처리 기반 애플리케이션에서 사용된다. 하지만 데이터 전송 형식은 통신하는 변환 간에 합의되야한다는 점이 필요하다.(우리는 이것을 프로토콜이라고 부른다)

워크플로우 비즈니스 프로세스에 적합하며, 변환 단계들이 병렬 처리(Parallelism)가 가능해 효율을 크게 높일 수 있다. 다만 컴포넌트 간에 호환되는 데이터 포맷을 맞춰야하는 오버헤드가 발생한다.

Application Architecture

도메인마다 사용하는 어플리케이션 구조가 비슷해 이를 정리한 구조이다. 주로 조직의 요구사항을 충족하도록 설계한다. 비슷한 구조를 중심으로 특정 요구사항을 충족하는 시스템을 구축하기 위해 구성 및 적용할 수 있는 SW System 유형의 아키텍처이다. 크게 두가지의 종류로 표현된다.

Transaction processing systems

우리가 흔히 아는 웹 정보 시스템(전자상거래, 예약 시스템, ATM 등)으로, 주로 데이터베이스와의 상호작용을 다룬다.

가장 밑에 DB가 깔리고, 그 위에 비즈니스 로직, UI가 올라가는 형태를 취한다. 데이터베이스에서 정보를 검색하거나 데이터베이스를 업데이트하려는 사용자의 비동기적 요청을 처리한다.

Information System Architecture 정보 시스템은 계층형 아키텍처로 구성될 수 있는 보편적인 아키텍처이다. 계층에는 사용자 인터페이스, 사용자 통신, 정보 검색, 시스템 데이터베이스를 포함한다.

Language processing system

기계어나 자연어를 입력받아 다른 표현으로 변환하는 시스템을 말한다. 우리가 흔히 생각하는 컴파일러, 인터프리터가 이 시스템에 포함된다.

컴파일러의 경우 아키텍처가 방식에 따라 여러개로 나뉘고, 이전에 Architecture Pattern에서 보였던 기법들을 주로 사용한다. (pipe-and-filter , repository 등)

오늘은 Architecture Pattern에 대해서 알아보았다.

주식 예측 프로그램을 동기들과 제작해보는 프로젝트를 진행 중에, 주식 그래프를 구현하면서 몇 가지 이슈에 부딪혔다. 초기엔 BackEnd에서 구현해본 것이 REST API가 대부분이라 당연히 방향성을 그렇게 잡고 움직였다.

하지만 프론트를 조금 구현하던 중 정보를 받아오는 것이 REST API로 진행하면 매끄럽지 않다는 것을 인지했다. 이러한 문제를 해결하고자 방법을 찾다가 WebSocket을 찾았고, 우리는 공부를 위해 REST와 Websocket을 모두 구현해보고자 한다.

그러기 위해서는 WebSocket에 대한 공부가 필요했고, 공부한 내용을 이렇게 블로그에 정리해보았다.

REST API 와 WebSocket

REST API와 WebSocket의 차이를 알아보려면 REST API가 가지는 한계를 알아봐야한다. REST API는 아래와 같은 한계를 가진다.

• 요청이 반드시 필요하다.
• 응답을 받으면 바로 연결을 끊어버려서 다시 요청을 보내야 통신이 가능하다.
• 정보를 전송할때마다 HandShake를 진행한다.

이러한 한계들은 결국 데이터를 빠르게 받아오고 빠르게 처리하는 과정이 필요한 서비스에는 너무도 비효율적인 방식이 되었고, 결국 WebSocket이 탄생하여 오늘날 사용되게 되었다.

Code로 보는 WebSocket

그렇다면 코드로는 어떻게 구현해볼 수 있을까. 내가 자주 사용하는 Spring Boot를 이용해서 이 WebSocket 기술을 구현해보자.

Controller

@Controller
public class StockController {

    private final StockService stockService;
    private final SimpMessagingTemplate messagingTemplate; 

    public StockController(StockService stockService, SimpMessagingTemplate messagingTemplate) {
        this.stockService = stockService;
        this.messagingTemplate = messagingTemplate;
    }

    // React에서 '/app/subscribe' 로 메시지를 보낼 때 실행됨
    @MessageMapping("/subscribe") 
    public void handleSubscribe(@Payload Map<String, String> payload) {
        String symbol = payload.get("symbol");
        Object currentStockData = stockService.getCurrentPrice(symbol); 
        messagingTemplate.convertAndSend("/topic/stock/" + symbol, currentStockData);
    }
}

위 코드는 개략적인 코드를 가져왔다.

WebSocket을 본격적으로 작업하려면 Topic(Room)이라는 개념을 이해해야한다. 웹소캣을 통해 주식 데이터를 받아오면 API를 통해 모든 주식 정보를 다 받아오게 된다. 만약 방이 없다면 이러한 정보들을 처리하지 못하고 받아내면서 브라우저에 강한 무리를 주게 된다.

이를 방지하기 위해 우리는 각 주식에 맞게 "Room"을 나누어서 처리한다. 그러면 사용자(User)는 방을 골라서 본인이 원하는 정보를 담은 Room에 대한 정보를 얻는 것이다. 이 과정을 우리는 Subscribe(구독)이라고 한다.

그리고 여기서 우리는 SimpMessagingTemplate을 주요하게 봐야한다. 이 항목은 이 WebSocket에서 정보를 알려주는 확성기의 역할을 한다. 이 확성기는 모두를 향해 제공되지만 이를 Room을 나누고 구독을 함으로서 각각의 방에, 각각의 User에게 원하는 데이터를 전송해주는 것이다.

이 코드는 아주 예시이기에 현재 가격을 가져오고, Room을 나눠서 특정 Room의 사용자들에게 값이 전달되는 기능만을 가지는 Controller이다.

Service

@Service
public class StockService {

    private final Random random = new Random();
    private double lastClose = 75000;

    public StockPrice getLatestPrice(String symbol) {
        double open  = lastClose + (random.nextDouble() * 400 - 200);
        double close = open      + (random.nextDouble() * 1000 - 500);
        double high  = Math.max(open, close) + random.nextDouble() * 300;
        double low   = Math.min(open, close) - random.nextDouble() * 300;
        lastClose = close;

        return new StockPrice(
                symbol,
                (long) open,
                (long) high,
                (long) low,
                (long) close,
                Instant.now().getEpochSecond()
        );
    }
}

Service는 받아내는 정보에 맞게 수정해야한다. 지금은 임시로 시가, 종가, 고가, 저가를 중심으로 나누어서 작업을 하도록 구성해두었다.

사실 WebSocket 구현 자체와는 크게 중요한 내용이라고 보이진 않는다. 차후 기능이 추가되면 더 자주 사용될 것이다.

Scheduler

@Component
public class StockScheduler {

    private final SimpMessagingTemplate messagingTemplate;
    private final StockService stockService;

    public StockScheduler(SimpMessagingTemplate messagingTemplate, StockService stockService) {
        this.messagingTemplate = messagingTemplate;
        this.stockService = stockService;
    }

    @Scheduled(fixedDelay = 1000)
    public void pushStockPrices() {
        StockPrice price = stockService.getLatestPrice("005930");
        messagingTemplate.convertAndSend("/topic/stock/005930", price);
    }
}

우리는 여기서 특정 종목에 대한 dto를 받아와서 messagingTemplate로 정의된 확성기를 통해 /topic/stock/{stockId} 라는 Room으로 내용을 쏴주는 절차를 밟는다. 1000ms로 작업을 해두었기에 1초마다 새로운 봉차트를 그리는 방향으로 디자인된다. Scheduler가 가지는 가장 중요한 요소는 1초마다 정보를 보내준다는 것이다.

사실상 front-End로 가기위해서는 Scheduler는 필수적인 요소이라고 볼 수 있다.

Summary

전체적인 플로우는 위의 사진과 같이 이해하면 될 것 같다. 전체적인 플로우를 이해하고 코드를 들여다 보면 더 쉽게 느껴지지 않을까 싶다.

물론 기능적으로 앞으로 더 맞춰나갈 것이 많으리라 보지만, 당장 처음 배운 개념과 기술에 대해서 너무 많은 것을 한번에 하기보다는, 하나씩 배워나가며 개념을 정립하고 이를 확장해서 더 좋은 기능들을 추가해 나가는 방향의 작업도 좋지 않을까.

내가 이끄는 것을 좋아해서인지 이끌다보니 좋아진 것인지는 모르지만, 어렸을 때부터 이러한 리더의 역할을 동경하고 지향해 왔다는 것에는 이유가 있지 않을까. 3학년이 된 지금, 나는 많은 프로젝트를 해보고 이끌어보고자 한다. 지금 진행 중인 프로젝트들도 많고 이 프로젝트에서 나의 역할을 다양하다. Front-end, Back-end 등 여러 파티션에서 경험을 쌓아가는 중이다. 그리고 이러한 경험이 충분한 밑거름이 된다고 생각하고 나는 천천히 이끌어 나갈 것이다.

IT 업계에서 PM으로의 길을 조금씩 나아가보고자 한다.

Product Manager

우선 Product Manager이란, Product(제품)을 Manage(관리)한다는 아주 간단한 뜻풀이로 접근할 수 있다. 그렇다면 그냥 아이디어 내는 기획자랑 비슷한가? 그렇게 묻는다면 크나큰 오산이다. 보편적으로 PM은 제품을 출시하고 유지보수하기까지의 전반을 운영 하는 것에 중심을 둔다. 아무래도 운영을 한다는 지점에서 이 직군은 경력이 있어야 주로 도달한다는 특징을 가지기도 한다. 왜 경력이 있어야 PM을 할 수 있는 것인가? 그래야만 이 시스템 전반에 대해서 알 수 있기 때문이다.

자연스레 대학생인 내가 왜 PM을 꿈꾸는지를 궁금해할 수 있다. 그건 다음에 또 다른 포스트로 적어보겠다.

PM의 가장 주요한 역할은 "기획문서 작성"이다. 그렇다면 기획 문서는 무엇일까.

기획문서

기획문서는 하나의 서비스를 만들 때, 필요한 내용을 정리하고 효율적인 소통을 위해 정의해두는 명세서와 같은 문서들의 집합이라고 볼 수 있다.

그렇다면 어떤 기획문서를 작성해야할까?

IA

IA, Information Architecture의 줄임말인 IA는 서비스의 정보와 계층적 구조에 대해서 보여준다. 서비스가 어떻게 구성되는지를 기준으로 하는 네비게이션 체계를 설계하는 것이 중심이다.

API 명세서

사실상 개발자와의 협업에 가장 깊게 중심을 둔 지점이다. 개발에 있어서 API 명세서는 필수적이다. 명세서를 디자인하지 않고 진행하게 되면 협업 자체가 굉장히 버거워진다. 그래서 최대한 명확하게 필요한 정보를 작성하는 것이 중요하다.

ERD

API 명세서와 더불어 백엔드 개발자의 중추와도 같은 요소로, 데이터베이스 구조를 작성하는 것이다. 데이터가 많이 필요한 서비스일수록 이 ERD의 구조에 따라 프로그램의 성능이 격하게 차이난다. 고로 ERD 작성을 하는 것에 힘을 많이 들여야한다.

PRD

사실상 이 모든 내용의 개요가 될 문서이다. 요구사항 정의서라고 불리는 이 문서의 작업을 통해 프로젝트의 방향성을 명확하게 드러낸다. 개요서나 계획서와도 같은 결을 가지고 있다고 볼 수 있는 문서로, PM으로서 작성해야하는 중요 문서 중 하나이다.

마치며..

프로젝트를 진행하면서 이외에도 다양한 기획 문서를 적용할 수 있고, 그런 다양한 기획문서를 이용해서 더 좋은 설계를 할 수 있다. 여러 프로젝트를 거치며 PM의 역할이 중요하고 선제적인 문서작업, 기획 단계가 탄탄할수록 프로젝트가 순항한다는 것을 알게 되었고 이를 위해서 꾸준히 공부하고 다져나가고자 한다.

첫 포스트는 이정도로 마무리 하고자한다. 앞으로는 더 좋은 글을 써나갈 수 있기를 바라며..

SW 개발 방법론 개요

SW 개발 방법론이란?

소프트웨어 시스템을 개발하는데 필요한 일련의 활동을 우리는 "소프트웨어 프로세스" 라고 부른다. 이는 아래와 같은 요소로 구성된다.

• 명세 : 시스템이 무엇을 해야하는지 정의한다.
• 설계 및 구현 : 시스템의 조직을 정의하고 시스템을 구현한다.
• 테스팅 : 고객이 원하는 것을 수행하는지 확인한다.
• 유지보수 : 변화하는 고객 요구에 대응해서 시스템을 변화시킨다.

소프트웨어 프로세스 모델. 즉, 개발방법론은 프로세스의 추상적인 표현이다. 특정 관점에서 프로세스에 대한 설명을 제공하는 것을 말한다.

SW 개발 방법론의 비교 포인트

현재 SW 산업에서는 여러 개발 방법론이 존재한다. 우리는 이 방법론들을 비교해보고 적절한 방법론을 사용해야하는데, 아래의 기준을 통해 비교를 할 수 있다.

• 주요 활동의 반복성 : 주요 활동을 반복하는지, 그리고 얼마나 자주 하는지를 고려해야한다.
• 수행가능 버전(MVP)의 출시 기간 : 수행가능한 버전인 MVP가 언제 나오는가에 대해 고려해야한다.
• 요구변경 수용 : 요구사항 변경이 들어오면 이를 얼마나 대응할 수 있는가를 고려해야한다.
• 개발 스케줄 관리 수월성 : 개발 일정을 얼마나 가시적으로 드러내는지 고려해야한다.

요즘과 같은 시대에는 AI의 역할이 크게 대두되는 추세인데, AI에게 일을 잘 시키기 위해서는 프롬프트를 잘 전달해줘야 한다. 이러한 AI 시대에 어떤 식으로 필요한 인력이 되어 스토리를 풀어나갈 것인지 생각해봐야 한다.

SW 개발 방법론의 종류

1.Waterfall 모델

Waterfall 모델은 위 그림처럼, 명확하고 순차적인 단계를 지닌다. 프로젝트가 시작해서 문제분석, 요구사항 명세 등을 거쳐 구현까지의 로직이 순차적으로 존재한다는 것이 특징이다.

waterfall 모델의 로직	waterfall의 비유연성

이러한 순차적 구조는 가장 치명적인 문제를 가지는데, 바로 비유연성 이다. 중간 절차에 대한 변경사항이 존재할 때, 이를 수행하는 것이 어렵다는 것이다. 이러한 점이 문제를 크게 발생시킨다.

이러한 Waterfall 모델은 요구사항이 명확한 경우에만 적용하기에 적합하다. 그래서 보통 Critical Project, 즉 국방과 같은 분야에서는 문서화와 인증이 필수적이므로 장기 프로젝트에서는 필연적으로 이 방법론을 선택하게 된다.

2.병렬적 개발 방법론

Waterfall 모델이 조금 변형된 스타일로, 같은 구조적 개발 방법론의 축에 들어간다. 계획, 문제 분석, 요구사항 명세는 순차적으로 진행하고, 이후의 개발은 subproject를 여러개를 동시에 실행시켜서 Prototype을 형성하는 방법론이다. 이 또한 요구사항이 명확한 경우에만 사용하는 것이 좋다.

3.Prototyping

진화적 프로토타이핑

빠르게 prototype을 만드는 것에 중심을 두고 개발하는 방식이다. 초기 개발 사양을 구성하고 이를 최종 시스템으로 수정 및 보완해서 확장하고 이를 통해 시스템을 개발하는 방식을 말한다. 요구사항이 명확하게 설정되지 않은 경우에 요구사항을 명확하게 하기 위해 사용하는 방법이다. 하지만 프로토타이핑 또한 단점이 분명하게 존재하는데, 초기 프로토타입에 래핑을 하는 것이기에 프로젝트가 다소 지저분해질 수 있고, 이 과정에서 복잡성이 증대한다는 것을 볼 수 있다.

Throwaway 프로토타이핑

위와 같은 문제를 해결하기 위해, Waterfall 모델을 적절히 섞은 프로토타이핑이라고 보면된다. 엄밀히 말하면 프로토타이핑의 목표는 시스템 요구사항을 이해하는 것이라고 볼 수 있다. 우리가 Waterfall 모델을 알아볼 때, 이 방법론은 요구사항이 명확해야한다고 했으니 둘을 잘 섞어본 것이다.

그래서 요구사항이 명확해질때까지 프로토타이핑을 사용하고 이후 Waterfall 모델을 이용해 개발하는 방식을 진행한다. 이를 통해 복잡성이 과도히 증대되는 것을 막을 수 있다.

이러한 prototyping 방식은 속도에 의미를 가진다. 대부분의 경우 갑과 을의 관계에서 개발을 진행하고 그러다보니 프로토타입이 빠르게 나올수록 갑의 이해도가 정립되면서 요구사항의 품질이 올라가는 효과를 볼 수 있다.

Incremental(점진적) 개발

기능에 대한 increment(증분)을 미리 나누어 두고 개발을 하는 방식을 말하고, 사용자 요구사항에 우선순위를 부여해서 그 순위에 맞춰서 작업하는 방식이다. 해당 요구사항은 고정하고 이후 증분에서 요구사항을 계속 발전시키는 방식이다. 한마디로 전체 시스템을 필요한 여러 개의 기능 단위인 '증분(Increment)'으로 나누어 순차적으로 개발하는 방식이다.

기능을 빠르게 제공하고, 실패 위험을 감소시키며 우선순위에 따라 테스트가 많이 발생할 수 있다는 점에서 장점을 가지지만 개발이 빠르게 진행되어 매 버전마다 문서를 수정하는 것이 비효율적일 수 있고, 증분이 추가될 때 구조가 점점 지저분해지는 프로토타이핑의 특성이 단점으로 작용한다.

prototype과 거의 유사하지만 조금 더 체계적인 방식으로 이뤄진다. 그러다보니 위에서 말한 것처럼 prototype의 문제점도 똑같이 가진다. incremental 개발 방법은 객체 지향 개발 방법이고, 그에 따라서 적용되는 분야도 상황에 따라 바뀐다.

Unified Process

Unified Process(UP)는 기존의 구조적 방법론들과 다르게 객체 지향 방법론의 일종이다.

Booch Method, Jacobson's Objectory, OMT라는 방법론을 하나로 합친 방법론이 발표된다. UP는 적응가능한(adaptable) 방법론이다. 즉, 특정 정보 시스템의 특성에 맞게 수정해서 적용하는 방식이라는 것이다.

애자일 방법론

애자일 방법론은 사실상 오늘날 가장 주로 쓰이는 방법론으로 불린다. 단순하고 반복적인 개발을 강조하며, 아래의 표를 통해 애자일 개발의 원리를 확인할 수 있다.

애자일 방법론의 가장 핵심은 "타임 투 마켓"이다. 어떤 프로그램이나 서비스를 출시하고자할 때, 그 서비스의 완성도보다는 출시 시기가 더욱 중요한 요소이다. 품질이나 완성도를 후순위로 차치한 이후 빠르게 시장에 서비스나 제품을 출시하는 것을 최우선으로 스프린트를 컴팩트하게 가져가는 방법이다.

XP(Extreme Programming)

XP 방법은 반복적 및 점진적 방법을 이용해 정보 시스템 개발에서 이슈가 되는 새로운 접근법이다.

프로그래머는 먼저 Task에 대한 Test case를 생성해서 자동 테스트 환경을 구성하고 하나의 컴퓨터에서 파트너와 함께 동시 작업한다. 이 모든 테스트 케이스를 올바르게 작동할 때까지 구현하고 이가 마무리되면 끝내는 방식을 택한다. 이때 한 컴퓨터로 동시에 작업한다는 의미는 한명이 코딩하고 한명은 뒤에서 같이 보면서 작업하는 것을 말한다.

XP의 방식을 택하려면 기본적으로 중급 이상의 시니어급 프로그래머가 되어야한다. 그리고 Customer를 한명 넣어서 운영된다. 로직을 보면 하루 단위로 개발 버전을 수정하고 업데이트를 해 나가고, Customer가 개발 버전을 검증하고 피드백을 주는 방식으로 운영된다.

MS의 사례

우리는 MS를 한번 주목할 필요가 있다. MS는 에러가 발생함에 크게 개이치 않는다. 애자일 방법론의 기조에 맞게 제품을 만들고 시장이 필요로 하는 시점에 완성도가 낮아도 일단 출시하여 이후 제품을 보강해 나가는 것이다. 이러다보니 MS가 독특한 점이 있는데, 보통은 갑과 을이 존재하는 프로젝트가 대부분이지만 MS의 경우에는 갑이 명확하게 존재하지 않는다. 어찌보면 대중이 그 갑의 위치로 들어갈 수도 있다고 본다. 결론적으로 MS가 가지는 포인트는 "time to market"이다.

애자일 방법론은 기존의 방법론들이 절차를 중시하며 흐름을 이어간 것과 다르게 사람을 중심으로 개인의 업무 프로세스를 보장해주는 방법론이다. 에러가 발생하면 수정하고 다시 테스팅하는 과정을 거치며 스프린트를 아주 잘게 쪼개서 업무를 이어간다. 이렇게 이어가다보면 코드가 스파게티 코드가 되고, 이를 정리해주는 것이 '리팩토링'이다. 리팩토링을 통해서 기존의 코드를 수정한다. 다만 리팩토링의 특징은 기능을 추가하거나 더 새로운 기술을 넣는 것이 아니라, 서비스 자체는 큰 변화가 없다는 것이다.

나아가 테스팅을 하는 관점에서는 이 방식을 TDD라는 이름으로 이해할 수 있는데 TDD란 Test-Driven Development로, 실제 코드를 작성하기 전에 실패하는 단위 테스트를 먼저 작성하고, 이를 통과한 최소한의 코드를 구현해 리팩토링을 반복하는 과정을 말한다.

Plan-driven vs agile specification

요구사항 분석

요구사항 분석의 목표

요구사항 분석은 제안된 시스템이 무엇을 수행하는지를 정의한 것이며, 어떻게를 정의하는 것은 아니다. 명확히 말하면 "What"을 정의하는 것이라 볼 수 있다. 어떻게는 설계 단계에서 정의 한다.

요구사항 명세의 구성요소

요구사항 명세의 구성요소로는 아래의 3가지로 나뉘는데, 앞의 2개는 우리가 흔히 생각하는 요구사항의 명세이다. 무엇을 수행하는지, 어떤 특성을 가지는지 이것은 프로젝트에서 반드시 다루어야하는 내용이라고 볼 수 있다.

하지만 그보다 선행되게 생각해야하는 부분이 있는데, 그것이 도메인의 기본적인 상식이다. 내가 하고자하는 프로젝트가 포함된 도메인에 대해서 기본적인 지식을 가지지 않으면 큰 어려움을 가질 수 있다.

기능적 & 비기능적 요구사항

요구사항은 크게 두가지로 나뉘는데, 기능적 요구사항, 비기능적 요구사항으로 나뉜다.

기능적 요구사항

기능적 요구사항은 시스템이 제공해야하는 서비스 명세서로 특정 입력이 발생하면 이에 대한 반응을 어떻게 할 것이고, 특정 상황에서 시스템이 어떻게 작동하는지 등의 서비스의 기능적인 요소를 포함하는 내용이다.

비기능적 요구사항

비기능적 요구사항은 서비스의 기능이 아닌 개발 프로세스의 제약, 표준 등의 시스템이 제공하는 서비스나 기능의 제약사항들을 말하고, 개별 기능이나 특정 컴포넌트가 아닌 전체 시스템에 적용되는 속성들을 기술한다.

요구사항 명세서 작성법

요구사항 명세서는 다음과 같은 방법으로 작성할 수 있다.

자연어 명세

자연어 문장으로 명세를 작성하는 방식을 이야기한다. 가장 직관적이고 표현하기가 용이하기 때문에 보편적으로 사용하고 고객 또한 요구사항을 쉽게 이해할 수 있다. 하지만 이 표기법은 몇가지 문제점이 존재한다.

• 명확성 부족 : 정확도를 높이면 문서를 읽거나 이해하기가 어려워진다.
• 요구사항 혼동 : 기능적, 비기능적 요구상항이 혼재되는 경향이 있다.
• 요구사항 합병 : 여러가지 요구사항을 함께 묶어 하나로 표현할 수 있다.

구조적 명세

작성자의 표현 자유가 제한되고 요구사항을 표준방식으로 작성하도록 하고 임베디드 제어 시스템에 대한 요구사항에는 적합하나 정보 시스템의 요구사항 작성에는 매우 엄격하다.

UML-based System Modeling

UML 방식의 장점은 Customer가 딱 보고 무슨 이야기인지 이해할 수 있다는 점이다.

Use Case 분석

고객 요구사항에 대한 분석, 개발 시스템의 범위를 정의한 것으로, 요구사항을 그래픽 다이어그램 및 시나리오 방식으로 기술하는 형태다. 시스템 관점에서 외부 상호작용의 적절정을 검증하고 수행 시나리오로서 acceptance test에 활용된다.

• Use Case use case는 actor 관점에서 관찰 가능한 연속적인 행위의 집합을 기술한 것이다.
• Actor
• 시스템과 상호작용하는 외부 에이전트가 수행하는 역할*을 말하고, 하나의 외부 에이전트가 여러 역할을 수행할 수 있다.

Use Case 예시	Use Case 설명 기술

Use Case 간의 관계

Use Case 간에는 관계가 존재한다.

• 포함 관계 << include >> 여러 Use Case들이 공통적인 행위를 하는 경우, 공통 행위를 따로 나타내고 이를 포함하도록 하는 것이다.
• 확장 관계 << extend >> 하나의 Use Case의 확장점에서 추가적인 행위를 추가해 다른 Use Case로 변형한 것이다.

요구사항 명세서와 테스팅

요구분석 단계에서 요구사항 명세서에 명시된 기능적 및 비기능적 요구사항에 대한 Test Plan을 수립한다. Test Case 작성 과정을 통해 요구사항의 일관성 및 완전성을 검사한다.

이번 포스트에서는 여러 방법론들과 요구사항 명세에 대한 부분을 알아보았다.

프로젝트는 비즈니스 요구사항을 중심으로 진행한다. 프로젝트를 제의한 사람(Sponsor)는 요구사항을 인지하고 구현을 요청해야한다. 결론적으로 프로젝트에서 비즈니스 요구사항이 가장 중요한 뼈대가 되는 것이다. 이러한 비즈니스 요구사항은 시스템의 기능을 결정하고 이때의 비즈니스 가치가 명확하게 드러나야 한다.

시스템 요구사항(System Request)

시스템 요구사항(System Request)은 _프로젝트를 공식적으로 제안하기 위해 작성하는 1~2장 분량의 요약 문서_이며, 프로젝트에서 가장 중요한 것 중 하나이다. 요구사항에는 아래 5가지 요소를 필수적으로 포함시켜야한다.

• Project Sponsor 프로젝트를 구상한 사람이자, 비즈니스적 측면에서 프로젝트의 주요 포인트를 짚어주는 사람이다.
• Business need 시스템을 구상할 때의 비즈니스와 관련된 이유를 나열한 것이다.
• Business requirements 시스템이 제공되었을 때, 비즈니스가 가지는 가능성을 말한다.
• Business value 시스템이 조직에 생성되어 도입되면, 이로 인해 발생하는 이점(이익)을 말한다.
• Special issues or constraints 시스템을 구현과 관련된 문제나 상위 관리자가 내린 결정들을 말한다.

예비 프로젝트 승인

시스템 요구는 상위 관리자의 승인에 따라 작성된다. 제공된 정보를 기반으로 이 프로젝트를 진행하는 것이 메리트가 있는지를 평가한다. *가치있는 프로젝트는 승인(1차)되고, 결과적으로 타당성 분석을 통한 추가적인 검증을 거친다. *이를 통해 정말 실현 가능한지에 대해 파악하게 된다.

타당성 분석 (Feasibility Analysis)

제안된 프로젝트에 대한 기회와 한계를 이해할 수 있는 요소이다. 프로젝트의 디테일한 비즈니스 케이스를 검증하며 프로젝트가 진행되는 내내 평가된다. 타당성 분석은 아래의 몇가지 방식으로 분류할 수 있는데, 기술적, 경제적, 조직적 관점에서 살펴볼 수 있다.

기술적 타당성

사용자와 분석가는 비즈니스 애플리케이션 영역에 대한 이해도를 말한다. 현재 보유한 기술력과 경험으로 이 프로젝트의 성공을 기대할 수 있는지를 평가하는 영역이다.

평가 요소 : 해당 기술에 대해 얼마나 경험이 있는지, 프로젝트 규모가 우리가 감당할 수 있는 수준인지, 그리고 기존의 시스템과 호환이 가능한지 등을 확인한다.

이를 평가할 때는 만약 이전에 사용한 프로젝트가 있으면 해당 프로젝트와 비교를 해보고, 처음이라면 IT 전문가의 조언을 받아 리스크를 분석한다.

경제적 타당성

경제적 타당성은 투입되는 전체 비용 대비 회사가 얼마나 이득을 취할 수 있는지를 확인하는 평가이다. 크게는 4가지의 과정으로 이루어진다.

우선 1) 비용과 이익을 계산하고, 2) 가치에 대한 비용과 이익을 부여한다. (이부분이 추상적이라 어려울 수 있으나 가장 중요하고, 무형 자산의 경우에도 수치화시켜 포함해야한다.) 그리고 이를 바탕으로 3) 현금 흐름을 결정하고 결론적으로 4) 재정적 타당성을 평가한다.

타당성 평가에는 몇가지 지표를 이용할 수 있는데, NPV, ROI, BEP가 있다.

NPV

가장 명확한 지표 중 하나이며, 단순히 유출 대비 유입의 양이 얼마나 많은지를 확인할 수 있는 지표이다. 이 때, PV(present Value)는 현금 흐름의 양을 말하고   $PV = (1+금리)^{n(년)}$ 으로 표현한다.

NPV 공식은 이러한 PV를 기반으로 $$PV 이익 - PV 비용$$ 으로 표현된다.

NPV가 0보다 크거나 같으면 프로젝트가 진행되어도 좋은 신호이며, 만약 0보다 작은 경우에는 적합하지 않다고 이해할 수 있다.

ROI

ROI(Return on Investment)는 NPV를 기반으로 계산되며, $\frac{NPV}{\sum PV(Cash ,,,outflows)}$ 으로 표현할 수 있다.

BEP

BEP(Break Even Point)는 손익분기점까지의 시간을 의미하고, 손익분기점을 맞기까지의 시간을 계산해 구한다. 당연하게도 이 값이 크면 프로젝트가 가지는 리스크는 정비례하게 커진다.

Tangible Cost vs Intangible Cost

각각 유형 비용, 무형 비용을 말하며, 유형 비용은 시스템을 통해 조직이 얻는 이익(수익)을 모두 포함하는 비용을 말하고, 무형 비용은 숫자에 기반하기보다는 직관과 믿음에 기반을 두는 비용을 말한다.

조직적 타당성

시스템이 사용자들에게 얼마나 잘 수용되고 조직의 지속적인 운영에 얼마나 잘 통합될 것인가를 나타내는 지표이다.

평가 요소 : 시스템의 도입이 현재 조직에 목표와 부합하는지, 그리고 Project Champion, 관리자, 최종 사용자 등의 이해관계자(Stakeholder)를 분석한다.

공장의 생산 라인에 로봇 시스템이 도입되는 것을 반발하는 것과 비슷한 의미를 가지며, 시스템의 도입으로 조직의 변화가 잘 이끌고 잘 수용되는지를 평가하는 것이 이 평가의 주 목적이다.

타당성 평가의 맹점은, 한번의 평가로 끝나는 것이 아니라 프로젝트가 이뤄지는 내내 진행되는 평가로, 지속적으로 재평가를 통해 프로젝트가 잘 순항하고 있는지를 확인해야한다.

Project Selection Issue

승인 위원회는 시스템 요구사항과 타당성 평가를 바탕으로 업무를 진행한다. 비즈니스 요구사항과 시스템 구축의 위험성을 검토하여 프로젝트를 신중하게 선택한다.

포트폴리오 관리

동시에 포트폴리오 관리도 이어지는데, 여기서 포트폴리오란 조직이 전체적으로 가져가고자하는 프로젝트가 있는 큰 물줄기를 말한다. 전체 프로젝트의 포트폴리오에서 해당 프로젝트가 어느정도 위치에 자리하고 있는지를 확인하고, 균형 잡힌 프로젝트 포트폴리오를 구성하기 위해서는 이에 대한 절충이 필요하다. 설령 실행이 가능한 프로젝트 일지라도 포트폴리오의 문제로 인해 거부되거나 연기되는 결정이 내려질 수 있다.

Project Management

프로젝트 관리의 4가지 주요 절차

프로젝트를 관리할 때 우리가 주요하게 거쳐야할 4가지의 절차가 있는데, 1) 프로젝트의 규모를 식별하고, 팀원과 조직의 상황에 맞게 2) 업무 일정을 구성하고 관리한다. 그리고 일정에 맞게 3) 인력을 배치하고 마지막으로 4) 프로젝트의 활동을 조정한다.

프로젝트 관리는 서로 연관관계를 가지기에 하나를 수정하면 다른 것도 같이 수정해야한다.

프로젝트 견적

시간과 노력의 가치에 값을 매겨 예상 값어치를 산정하는 과정이다. 프로젝트에서 사용한 방법론, 경험이 있는 개발자, 실제 이전 프로젝트를 측정하며, 이를 통해서 예상 값어치를 산정한다. 처음에는 단순 범위의 수준으로 러프하게 매겨지다 프로젝트가 진행되고 구체화함에 따라 견적 또한 더욱 상세하고 두터워진다.

기능 점수(Function Point)

프로젝트가 승인되고 본격적인 계획을 들어가면 PM은 프로젝트의 규모, 비용, 개발 소요기간을 최대한 정확하게 예측해야한다. 이전에는 개발자의 경험에 의존해 되는대로 예측하기도 하였으나, 1979년 IBM의 Allen Albrecht가 Function Point라는 기능을 고안한 이후에는 이 방법을 적극 사용하여 객체적이고 정량적인 방식으로 산정한다.

이 기법은 5가지의 핵심 기능을 분해해 개수와 복잡도를 측정한다.

• Input : 사용자가 시스템으로 데이터를 집어넣는 기능을 말한다.
• Output : 시스템이 데이터를 가공해 사용자에게 결과물로 보여주는 기능을 말한다.
• Query : DB의 정보를 검색과 조회를 통해 화면에 Display한다.
• File : 시스템 내부에서 자체적으로 유지, 관리하는 논리적 데이터 집합이다.
• Program Interface : 외부 다른 시스템과의 통신을 위해 필요한 게이트를 말한다.

Function Point를 계산하는 데 몇 가지 절차가 존재하는데, 아래의 그림들을 중심으로 그. 흐름을 파악해 볼 수 있다.

Function Point 측정

1. Function Point 계산	1-(1). Function Point 적용

2. 소요 인력 산정	3.Schedule Time 계산

Use Case

Use Case Diagram

Use Case는 여러 시나리오를 포함하는 기능을 말하고, Actor는 외부 에이전트가 수행하는 역할이다. 인간이나 하드웨어 등의 내용이 수행하며, 이러한 Actor와 Use Case 사이의 흐름을 작성한 문서로 보면 된다.

Use Case Estimation

Use Case를 측정하는 과정을 가진다.

• Unadjusted Use-Case Points(UUCP) Actor 가중치 (1~3) / Use Case 가중치 (5,10,15)

• Technical Complexity Factor(TCF) : 13 factors TCF = 0.6 + (0.01 * TFactor)

• Environmental Factors(EF) : 8 factors EF = 1.4 + (-0.03 * EFactor)

• Adjusted Use Case Point(UCP) UCP = UUCP * TCF * EF

• Effort in Person-hours = UCP * 계수(20 or 28)

Creating And Managing The Work Plan

업무 식별

프로젝트에 필요한 업무를 식별할 때는, 주로 방법론에서 제공하는 표준 업무 목록을 참고하거나 "하향식 접근법(Top-Down)"을 사용한다. 높은 레벨의 업무를 식별하고 그것을 더 작은 단위로 나눈 뒤에, 이렇게 쪼개진 업무들을 계층적으로 구조화한 것을 작업 분할 구조도(Work Breakdown Structure, WBS)라고 한다.

업무 식별 단계에서 업무를 누락하게 되면, 이후에 특정 팀원들에게 갑작스럽게 과중한 업무가 배정되어 불만이 쌓이고, 최악의 경우 인력 이탈이나 프로젝트의 실패로 이어질 수 있다. 고로 PM은 업무를 빠짐없이 도출하고, 공정하게 로드 밸런싱(Load Balancing) 해주는 것이 매우 중요하다.

Project Workplan

WBS를 바탕으로 도출된 모든 업무 목록을 모아 전체적인 작업 계획을 작성하는 것을 말하고, 아래의 내용들이 명시되어야 한다. – 작업명 – 작업 기간 – 현재 작업 상태 – 작업 간 종속 관계 – 마일스톤 (날짜)

Tracking Project Tasks

작업 계획이 수립되면, PM은 일정이 계획대로 진행되는지 시각적으로 모니터링하고 관리해야한다. 이때 주로 2가지의 차트를 사용하는데, 각각 Gantt Chart, PERT Chart이다.

• Gantt Chart : 막대 차트 형식으로, 프로젝트 진행상황을 언제든 파악하기에 용이하다.
• PERT Chart : 플로우 차트 형식으로, 주요 경로와 작업 의존도를 그리고 순서와 관계에 집중한 순서도이다,

Refining Estimates

Hurricane Model

불확실성의 원뿔을 허리케인 모델로 시각화한 그래프로, 가로축은 프로젝트의 진행 단계를 순차로 배치하고 세로축에는 소요 시간을 중심으로 구성한다. 이 때, 점선은 오차범위를 의미하고 원의 크기는 해당 시점에 예상되는 프로젝트 cost를 말한다.

프로젝트의 진행 순서는 아래와 같이 정의하고, 각각의 레벨은 특징과 상태를 지닌다.

Level 1 : 초기 초기에는 표준화된 프로세스가 거의 존재하지 않으며, 성공이 개발자 1~2명의 역량에 달린다. 그 사람이 나가면 프로젝트가 무너질 가능성이 급격히 높아진다.

Level 2 : 관리 프로젝트 단위로 일정한 규칙을 마련하는 시점이고, 계획을 세우고 일정과 비용을 관리하기 시작한다. 예전과 비슷한 프로젝트를 해낼 수 있는 지점이기도 하다.

Level 3 : 정의 회사(조직) 전체의 표준 프로세스가 확립된다. 이 시기를 기점으로 정확한 공통 가이드라인이 적용되고, 모든 팀이 메뉴얼에 따라 행동한다.

Level 4 : 정량적 관리 데이터와 숫자로 프로세스를 관리하며, 수치를 중심으로한 대화를 주고 받는다. 이로 인해 명확한 수치를 향상시키는 것을 목표로 하기에 결과 예측의 정확도가 향상한다.

Level 5 : 최적화 지속적인 개선과 혁신을 하는 시기로, 완성된 제품이 이미 완벽에 가까울 정도로 궤도에 올랐으나, 신기술을 도입하거나 데이터를 분석해 끊임없이 업그레이드를 하는 시기이다.

Managing Scope

Scope creep

Scope Creep은 프로젝트가 진행되는 도중에 새로운 요구사항이 계속해서 추가되면서, 결과적으로처음에 정했던 프로젝트의 범위(Scope)가 점점 늘어나는 현상이다. 이는 두 가지 관점을 가지는데, 일정 지연(Schedule overrun)과 예산 초과(Cose overrun)가 발생한다.

또한 주로 사용자가 요구사항을 늘리면 발생하게 되고, 초기예측의 불완전성을 인정하고 관리해야한다. 실제로 System Request에 비해 실제 비용은 4배(400%)까지도 차이가 발생할 수 있다.

SW Engineering을 알아보기 전에, Software에 대해서 알아보자.

우리가 건물을 바라볼 때, 여러 관점의 사람들과 이해관계자들이 접근하게 된다. 시공자, 거주자, 설계사, 인부 등에 따라 그 건물을 바라보는 시야가 달라진다. SW도 마찬가지다. 디자이너, 개발자, 사용자, 매니저 등 여러 이해관계자의 상황에 따라 다른 관점을 가지게 된다.

SW란 무엇일까. 소프트웨어란 사전적 의미로 접근하면 프로그램과 프로그램의 개발, 운용, 수정 및 기능 확정을 위해 필요한 모든 정보를 말한다. 소프트웨어는 어찌보면 프로그램의 동적인 의미로 볼 수 있다. 운영체제 관점에서는 Process와도 상통하는 개념이라고 볼 수 있다.

이러한 SW가 가지는 특성으로는 첫째로 비가시성_을 가진다. 비가시성이란 무형적인 특성을 가지고 구조가 코드 속에 내제된 상태로 구현된다. 둘째로 _복잡성_을 가진다. 복잡성이란 개념을 코드로 구현한 것 자체는 복잡하고 난해한 상태를 말한다. 추가로 요구나 환경 변화에 대한 **_변경 가능성, 복제 가능성, 테스팅의 어려움 등**의 특성을 가진다.

소프트웨어 유형

소프트웨어의 분류 체계

SW는 아래와 같은 분류 체계를 가진다.

• 기능
  • 시스템 소프트웨어 : 하드웨어를 직접 관리하고 원활하게 실행하는 기반을 제공한다.
  • 응용 소프트웨어 : 특정 목적을 위해 직접 사용하는 프로그램을 말한다.
    
• 개발 과정 : reusable, newly-built, modification, porting 등이 존재한다.
  
• 신뢰도
  • critical : 오류 발생 시, 심각한 문제를 초래할 수 있어 신뢰성을 요하는 시스템을 말한다.
  • non-critical : 오류 발생시 불편할 수 있으나 심각한 문제가 발생하지 않는 시스템이다.
    
• 소프트웨어 크기 : 규모에 따라 두 가지로 나뉜다.
  • programming-in-the-small : 규모가 작아 소수의 개발자가 단기간에 완성할 수 있는 것을 이야기하며, 개발자의 역량이 큰 영향을 준다.
  • programming-in-the-large : 장기간 개발하는 대규모 프로젝트이다. 이 때는 방법론을 적절하게 적용해야한다.
    
• *데이터 특성 *: 그래픽이나 이미지, 텍스트 등의 특성을 이야기한다.

정보 시스템 (Information System)

대량의 데이터의 분류, 저장, 검색에 관심을 두는 시스템으로 GUI 기반의 서비스 인터페이스를 제공한다.

정보 시스템의 특성을 몇 가지 알아보자면 이 시스템의 경우 문서가 중요한 요소로 작용하고, 개발이나 유지보수가 많은 노력과 비용이 발생한다. 데이터 설계는 비중이 큰 반면 제어구조는 비교적 간단하다는 특징도 가지고 있다.

우리가 흔히 볼 수 있는 쇼핑몰 사이트나 이런 대형 사이트들이 이런 정보 시스템의 예시가 될 수 있다.

내포 시스템 (Embedded System)

임베디드 시스템은 컴퓨터의 연산이 주 목적이 아니라 더 큰 기계나 시스템의 내부에 포함되어 제어 기능을 수행하는 소프트웨어를 말한다. 우리가 요즘에는 흔히 자동차나 냉장고 등의 전자 기기 내에 들어가는 형태로 주로 볼 수 있다.

특징으로는 시스템의 규모가 크고 수명이 긴 편이며, 실시간 응답성이 필수적으로 접목되어야한다. 또한 오류나 장애가 발생해도 치명적인 사고를 방지할 수 있어야 한다. 마지막으로 비동기성이 특징인데 여기서 비동기성이란 작업의 완료를 기다리지 않고 바로 다음 작업을 실행하는 것을 말한다.

소프트웨어와 관련된 사담

질문 1. 소프트웨어 시스템을 개발하는 데 드는 비용 중 프로그래밍에 드는 비용은 어느정도일까?

소프트웨어 시스템을 개발하는 데 드는 비용 중에 프로그래밍에 드는 비용은 20% 정도이다. 이외의 비용은 테스팅과 요구분석 및 설계가 각각 40%씩 나눠 가진다. 물론 모든 프로젝트가 이 추이를 따라가는 것은 아니고 전반적인 이야기이다.

질문 2. 사용자에게 배달되는 소프트웨어의 실행코드 1000줄 당 예상 오류의 개수는 몇 개일까?

보편적으로 4개 미만이라고 한다. 이는 개발 과정에서 50~60개의 오류가 발생하고 이를 보완해 사용자에게 제공되기에 현저히 떨어진 수치로 보여진다.

질문 3. 사용자가 발견하는 시스템의 오류 중 가장 발견하기 어려운 것은 어느것일까?

이 질문에 대한 답은 "제안서와 사용자 요구사항에 대한 잘못된 이해"이다. 오류가 빠르게 발견되어 요구사항 분석 시점에 가까이 발견될수록 비용이 저렴하고 유지보수 이후로 넘어갈수록 비용이 급격하게 올라간다.

질문 4. 소프트웨어 시스템을 유지 보수하는 데 드는 비용이 개발 비용의 몇배일까?

소프트웨어 시스템을 유지 보수하는데 드는 비용은 개발 비용의 2배 가량 드는 것을 알 수 있다. 이는 제품이 얼마나 체계적으로 만들어졌는지에 따라 반비례적인 추세를 가진다. 또한 처음에 다룬 질문 1번의 내용인 비용 문제에 대한 내용과도 일부 상통하는 내용이라고 볼 수 있다.

소프트웨어에 대한 오해

소프트웨어에 대한 오해는 관점에 따라서 관리자, 그리고 고객과 엔지니어의 오해로 나눌 수 있다. "이정도는 해줄 수 있는거 아닌가?"라는 이해관계의 문제가 중심이다. 그로 인해 이해관계자들의 상황에 맞게 서로 오해의 상황이 발생한다.

관리자의 오해

관리자들은 주로 _도구, 인력, 표준화된 프로세스만 갖춰지면 프로젝트가 기계적으로 통제될 수 있다는 착각을 하는 경향_이 있다. 쉽게 말해서 자원과 틀만 제공이 되면 프로젝트가 잘 이루어질 것이라는 일종의 믿음을 가진다는 의미이다.

"우리가 이정도 자원을 제공했으니 그들은 충분히 우리가 원하는 결과물을 만들 것이다"라거나 "엔지니어라면 엔지니어링에 중심을 둬야지 요구분석을 하는 것은 좋지 않다", "공정이 지연되면 인력을 투입하는 방식으로 해결할 수 있다" 등의 생각들이 그들이 쉽게 생각하는 오해이다.

자원을 제공했을 때 그에 상응하는 output이 나오기를 바라고 그러리라 믿는 경향이 있는 것이 관리자의 특징이다. 이에 따라 위와 같이 상호간의 오해가 생기기도 한다.

고객의 오해

고객은 _소프트웨어의 유연성을 과대평가하여 초기에 요구사항을 명확히 하지 않아도 나중에 고칠 수 있을 것_이라 생각한다. 하지만 이 생각은 착각이고, 이후에 수정을 하는 것이 더 힘든 상황이 발생하고 설령 가능하더라도 코드가 난잡해지는 등의 문제가 발생할 가능성이 높다.

흔히 고객이 생각하는 방향을 예로 들자면 "목표에 대한 기술만 대충 적어두면 SW를 만드는데 충분하고 세부적인건 나중에 채우면 된다" 나, "요구사항은 계속 변하고 이를 소프트웨어는 쉽게 수용할 수 있어야한다."는 생각을 하기 쉽다.

엔지니어의 오해

그럼 마지막으로 엔지니어의 오해를 알아보자. 개발자는 코딩과 실행결과에 치중되게 생각을 하는 경향이 있다. 그래서 기능을 만들고 생성하는 것을 중점을 두고 유지보수를 위한 문서화나 설계에서의 품질 검증이 쉽게 넘어가곤 한다.

예를 들자면 "프로그램이 만들어지고 작동하면 할 일을 다 한 것이다" 또는 "시스템을 작동시켜 보기 전까지는 품질을 평가할 방법이 없다", "프로젝트의 결과는 작동하는 프로그램일 뿐이다" 등의 오해를 할 수 있다.

소프트웨어 공학

소프트웨어의 위기

소프트웨어를 개발할 때는 많은 문제들이 발생할 수 있다.

• 예산 초과
• 개발 일정 지연
• 불충분한 성능
• 신뢰하기 어려운 품질
• 유지 보수의 어려움
• 막대한 유지보수 비용

등이 있다. 물론 이보다 훨씬 많은 문제들이 개발이나 설계, 유지보수 과정에서 발생한다. 이 때 우리가 주의깊게 볼 위기는 하드웨어의 급속한 발전과 컴퓨터의 대중화로 SW의 수요가 급증한다는 배경을 두고 심화된다.

현재 대부분의 빅테크가 SW 기업인 것을 감안하면 이 사실에 대해 짐작할 수 있다. 하지만 문제는 여기서 발생한다. 소프트웨어 생산성과 생산 기술은 그에 미치지 못하는 상황이 발생한다.

소프트웨어 공학이란 ?

소프트웨어 공학이란 품질 좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞추어 개발하기 위하여 여러가지 공학적 원리와 방법을 체계적으로 적용하는 것을 말한다. 한마디로 "일정에 맞게 개발하기 위해 방법론을 적용하여 좋은 퀄리티의 소프트웨어를 제작하는 공정"이다.

소프트웨어 공학의 역사

소프트웨어의 위기로부터 이어진 소프트웨어 공학의 역사에 대해서 알아보자. 우선 이 이야기를 하려면 1970년대부터 시작해야한다.

~1970

이 시기까지 소프트웨어의 위기가 인식되기 시작하고 이를 해결하기 위해 소프트웨어 공학이 탄생한다. 고급 언어가 발생하고, interactive한 프로그래밍이 생기기 시작한다. 이 때 goto 논쟁이라는 것도 발생하는데, 이는 스파게티 코드를 지양하고 논리적 흐름을 강조하는 "구조적 프로그래밍"이 중요하다는 것이 대두되는 기점이 된다.

~1980

이제 본격적으로 소프트웨어 위기로부터의 해결책을 모색하기 시작한다. 소프트웨어 공학이라는 분야가 학문적으로 정착하기 시작했고, 하드웨어로부터 독립된 개념의 소프트웨어가 점점 발생하기 시작한다. 이 때 아래와 같은 개념들이 생기기 시작했다.

• 소프트웨어 생명주기
• 대규모 프로그래밍
• 방법론 및 도구
• 정보 은닉
• 구조적 설계

~Present

80년대에 본격적으로 거론되기 시작한 해결책들은 오늘날까지 여러 방식으로 진화와 발전을 거듭해왔다. 기존의 구조적 프로그래밍의 중심을 벗어나 객체 지향 프로그래밍(방법론)이 흐름의 중심으로 다가서고, 그로인해서 재사용, 디자인 패턴, 소프트웨어 컴포넌트/설계 등의 개념들이 추가적으로 도입되기 시작한다.

소프트웨어 공학의 크기 체계

일전에 소프트웨어 공학의 분류 체계를 하면서 나온 개념이긴 하지만 더 세세하게 개념에 대해서 알아보도록 하자.

1. Programming-in-the-Small

규모가 작은 프로그램을 말하며 프로그램의 규모 자체가 작기 때문에 명확하게 정의가 가능하고 그 문제들을 집중적으로 해결하는 방식이다. 이러한 경우엔 정확하게 개발하는 것이 중요하고, 명세가 잘 변경되지 않는 특성을 가진다.

2. Programming-in-the-Large

우리가 주로 마주하는 프로그램의 크기는 이 형태를 가진다. 규모가 커지게 되면서 개인의 코딩 실력이 중요한 것이 아니라 시스템 전체의 구조와 관리가 중요한 방식이다. 규모가 큰 만큼 해결할 문제를 정확하게 정의해야하고, 아무래도 크기가 크다보니 요구사항을 초기에 정한대로 흘러가지 않는 경우가 많다. 이런 경우를 고려한 상태로 대응책을 마련해야한다.

또한 시스템을 구성하는 컴포넌트들 사이의 인터페이스를 명확하게 설계해야하고 시스템 통합과 테스팅 과정이 필요하다. 규모가 크다보니 협업이 여기서부터는 매우 중요하게 여겨지는데, 변경사항을 체계적으로 관리하는 git과 같은 툴이 적용되어야하고 지속적으로 문서, 유지보수 등을 수정하고 작업하며 탄탄히 나아가야한다.

3. Programming-in-the-Many

프로그램의 크기도 크기지만 인원에 중심을 둔 프로그래밍이다. 팀 단위로 무언가를 구축할 때, 주로 마주하는 문제들을 다루고 팀원 간의 정보 교환 등의 커뮤니케이션을 진행해야한다. 작업을 적당하게 할당해야하고, 표준화를 통해서 팀원들간의 문서 및 개발 성향을 조정할 필요가 있다. 결국 이 시점에 PM(Project Management)의 역량이 중요해진다.

사실상 Many의 경우는 Large인 프로그램에서는 필연적으로 필요한 상황이 발생하고, 규모가 크면 사람이 많아야하고 그에 따라서 2번과 3번은 유기적으로 이어질 가능성이 매우 높다.

소프트웨어 테스팅

구현과 테스팅

그림 1을 통해서 프로젝트의 규모가 클수록 구현과 테스트의 비중이 줄어든다는 사실을 알 수 있고, 프로젝트에서의 구현 오류의 비중이 높은 경우를 그림2를 통해 확인할 수 있다. SW 코드 검증 방법과 소스코드 검증 기법은 아래와 같다.

SW 코드 검증 방법	소스코드 검증 방법

다양한 테스트 기법들의 오류 감지율

오류 감지를 위한 여러 테스트 기법들이 존재하는데, 그 리스트를 보면 아래와 같다. 하나의 방법이 평균 75%를 넘는 경우가 없고, 그로 인해 다양한 방법을 병행으로 사용해야 효과를 볼 수 있다는 특징이 있다.

V-Model

테스팅을 할 때, 우리는 V 모델을 자주 사용한다. V 모델은 확인 절차가 왼쪽과 오른쪽 두 개로 나뉘고, V자 모양으로 움직일 때 아래의 순차적인 절차를 따라 움직인다.

왼쪽(Architecture Design)
1. 요구사항 분석 : 고객이 무엇을 원하는지 요구사항을 정리한다.
2. 시스템 셀계: 전체 시스템의 하드웨어, 소프트웨어 구조를 기획하는 과정이다.
3. 아키텍처 설계 : 시스템을 구성하는 여러 모듈(기능) 간의 관계와 구조를 설계한다.
4. 모듈 상세 설계 : 각 모듈 내부의 구체적인 로직이나 알고리즘, 데이터 구조 등을 상세히 설계한다.

중간(Coding) 5. 코딩 : 말 그대로 프로그램을 구현하는 절차를 말한다.

오른쪽(Testing) 6. 단위 테스트 : 개발자가 작성한 개별 함수나 클래스가 의도대로 작동하는지 테스트한다. 7. 통합 테스트 : 각각 만들어진 모듈을 연결하면 데이터가 잘 넘어가고 충돌 없이 작동하는지 테스트한다. 8. 시스템 테스트 : 완성된 전체 시스템이 정상적으로 작동하는지, 성능은 잘 나오는지 테스트한다. 9. 인수 테스트 : 최종 고객이 요구사항대로 완성되었는지 직접 사용해보며 승인하는 테스트이다. 10. 설치 테스트 : 최종 사용자의 실제 운영 환경에 소프트웨어가 문제없이 설치 및 구동되는지 테스트한다.

이번 포스트에서는 SW Engineering 과 Testing을 위한 개요를 알아보았다.