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

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

응답 속도에 따른 분류

응답 속도에 따라 일괄 처리(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을 위한 개요를 알아보았다.