소웨카이나

[스위프 후기] - 스위프 웹 12기 밍글링 프로젝트

shineast_ — Fri, 6 Mar 2026 07:33:15 +0900

스위프 웹 12기 FE 후기

이번 스위프 활동은 처음 참여해보는 대외활동이었고 동시에 처음 진행해보는 팀 프로젝트였습니다. 저는 프론트엔드 파트를 담당했었는데요~ 진행 기간 6주 그리고 2주 간의 고도화 기간까지 대략 2달의 시간을 투자하면서 참 많은 것들을 배워간 시간이었습니다. 개발환경 세팅부터 디자이너 분들의 figma 시안을 코드로 구현하고 백엔드 api와 연동하는 작업들은 너무나 즐거운 시간이었습니다. 단순히 기능을 구현하는 것을 넘어서 사용자 경험을 어떻게 더 좋게 만들 수 있을지 고민해보는 과정도 개인적으로 굉장히 의미 있는 시간이었습니다.

그러다가도 막히면 며칠을 끙끙대고 gemini, claude, gpt의 도움을 받아 해결하고도 또 에러 터지면 코드를 낱낱이 분석하고 이러면서 밤을 훌쩍 새기도 했습니다 ㅎㅎ... 그럼에도 힘든 줄 모르고 열심히 프로젝트에 참여했네요. 그렇게 팀원들과 함께 두 달 간의 기간을 열심히 달려온 결과!! 프로젝트가 완성되었습니다. 각자의 자리에서 맡은 역할을 책임감 있게 해주신 팀원 분들 덕분에 끝까지 완주할 수 있었던 것 같습니다. 이 기간 동안 열심히 작업한 모든 팀원 분들께 감사드립니다!!

데모데이에 참석하며 각 팀의 작업 과정과 결과물을 보고 체험하는 시간을 가졌는데 다들 너무나 완성도 있게 결과물을 내셨더라구요. 다양한 아이디어와 구현 방식들을 직접 보면서 또 한 번 자극을 받아 가게 되었습니다. 그리고 각 직군과 랜덤 네트워킹 시간은 여러 인사이트를 가져갈 수 있는 좋은 시간이었습니다~ 다양한 분들과 이야기를 나누면서 많은 것을 배우고 돌아올 수 있었습니다. 귀한 자리 마련해주신 스위프 팀에 감사드립니다!!

기회가 된다면 또 참여하고 싶을 정도로 만족스러웠던 시간이었고 좋은 포트폴리오 작품, 귀한 협업 경험, 좋은 사람들을 만날 수 있어서 너무나 좋았습니다 (다들 스위프해보세요 두 번 하세여)

Mingling(밍글링) - 중간 위치로 만날 곳 정하기

P.S 밍글링이라고 하는 저희 프로젝트는 중간 지점을 연결해주고 그 지점에서의 여러 장소를 추천해주는 프로젝트입니다 ㅎㅎ 밍글링 프로젝트는 아래의 링크에서 체험해보실 수 있습니다!! 부족하지만 열심히 만들었습니다 ㅎㅎ 피드백은 저의 성장에 큰 힘이 됩니다 https://www.mingling.kr

밍글링 - 중간 위치로 만날 곳 정하기

퇴근 후 모임, 주말 약속까지! 서울 어디서든 모두가 비슷하게 도착하는 마법의 장소를 찾아드려요.

www.mingling.kr

[데이터베이스] - 데이터베이스 응용 기술 (Database Application Technologies)

shineast_ — Sat, 24 Jan 2026 20:03:59 +0900

객체지향 데이터베이스

관계 데이터베이스는 관계 데이터 모델의 기능적 제약조건과 SQL의 표현력 한계로 인해 다양한 응용 분야에 부적합하다. 객체지향 데이터 모델은 객체지향 개념에 기반을 둔 데이터 모델로, 의미상 관계가 있는 데이터베이스 구조를 표현할 때 적합하다. 객체지향 데이터 모델이 지원하는 객체지향 개념은 다음과 같다.

객체: 현실 세계에 존재하는 개체를 추상적으로 표현한 것
객체 식별자: 각 객체를 유일하게 식별하는 수단
속성: 객체의 상태나 특성
메서드: 객체에 수행할 수 있는 연산, 객체의 속성 값을 조작한다.
클래스: 속성과 메서드를 공유하는 유사한 성질의 객체들을 그룹화한 것
복합 객체: 사용자 정의 클래스를 도메인으로 하는 속성을 가지고 있는 객체

객체지향 데이터베이스에서는 질의 대상이 클래스이고 질의 결과는 클래스에 속하는 객체 집합이다. 객체지향 데이터베이스의 데이터 모델과 질의어는 표준화되지 못했는데 이로 인해 보편적으로 사용되지 못하고 특수 분야에서만 사용된다.

이 문제를 해결하기 위하여, 객체지향 데이터 모델의 장점과 관계 데이터 모델의 장점을 모두 가진 객체관계 데이터베이스가 등장했다. 객체지향 개념을 지원하는 표준 SQL을 사용할 수 있다

분산 데이터베이스 시스템

데이터베이스 시스템을 물리적으로 한 장소에 설치하여 운영하는 것을 “중앙 집중식 데이터베이스”라고 한다. 그러나 데이터베이스 시스템을 한 곳에 설치하지 못하고 여러 곳에 분산하여 운영하는 것이 있는데 이를 “분산 데이터베이스 시스템”이라고 한다.

분산 데이터베이스 시스템은 “분산 처리기”, “분산 데이터베이스”, “통신 네트워크”로 구성된다.

분산 처리기: 물리적으로 분산되어 지역별로 필요한 데이터를 처리할 수 있는 지역 컴퓨터
분산 데이터베이스: 물리적으로 분산되어 해당 지역에서 가장 많이 사용되는 데이터를 저장하는 지역 데이터베이스
통신 네트워크: 지역의 분산 처리기가 하나의 시스템으로 자원을 공유할 수 있도록 연결해주는 네트워크

분산 데이터베이스 시스템의 목표

분산 데이터베이스 시스템에서는 사용자가 “데이터베이스가 분산되어 있음을 느끼지 못하도록” 하는 것이 중요하다. 이를 “분산 데이터 독립성”이라고 하며, 분산 데이터 독립성을 지원하기 위해서는 분산 투명성을 보장해야 한다. 분산 투명성의 종류는 다음과 같다.

위치 투명성 (Location Transparency)

위치 투명성은 데이터베이스가 지역적으로 분산되어 있지만, 사용자가 접근하려는 데이터의 실제 저장 위치를 알 필요 없이 데이터베이스의 논리적인 이름만으로 데이터에 접근할 수 있다는 것을 말한다.

위치 투명성이 보장되면, DBMS가 시스템 카탈로그에서 관리하는 위치 정보를 통해 데이터를 제공하여, 응용 프로그램의 처리를 쉽게 진행할 수 있다.

중복 투명성 (Replication Transparency)

중복 투명성은 동일한 데이터가 여러 지역에 저장되더라도 사용자가 중복을 인식하지 못하고, 하나의 데이터베이스 시스템에 데이터가 저장된 것처럼 사용하는 것을 말한다.

데이터베이스를 중복 저장하면 한 지역의 데이터베이스에 문제가 생겨도 다른 지역 데이터베이스를 이용할 수 있기에 신뢰성과 가용성을 높일 수 있다. 그러나 저장 공간을 많이 차지하고, 데이터 관리가 어려워진다는 단점이 있다.

그럼에도, 분산 데이터베이스에서는 데이터를 중복 저장해서 얻을 수 있는 장점이 크기에 데이터를 중복해서 저장한다. 분산 데이터베이스 시스템에서 데이터를 중복하여 저장하는 방법으로는 완전 중복과 부분 중복이 있다.

완전 중복: 동일한 데이터를 둘 이상의 지역에 있는 분산 데이터베이스 저장하는 것
부분 중복: 일부 데이터만 중복하여 저장하는 것

단편화 투명성 (Fragmentation Transparency)

단편화는 하나의 릴레이션을 더 작은 단편으로 나누고 각 조각을 별개의 릴레이션으로 처리하는 것을 말한다. 단편화를 하면 저장 공간을 적게 사용하고 관리할 데이터 수도 줄어든다.

단편화 투명성은 사용자가 데이터를 사용할 때, 데이터가 단편화된 것을 인식할 수 없도록 하는 것을 말한다.

단편화를 할 때는 다음 세 조건을 만족시켜야 한다.

완전성(Completeness): 전체 릴레이션의 모든 데이터는 어느 한 조각에는 반드시 속해야 한다.
회복성(Reconstructability): 단편화된 조각들로부터 원래의 전체 릴레이션을 회복시킬 수 있어야 한다.
분리성(Disjointness): 전체 릴레이션의 모든 조각을 서로 중복되지 않게 분리해야 한다.

릴레이션을 단편화하는 방법으로는 “수평적 단편화”, “수직적 단편화”, “혼합 단편화”가 있다. 이 세 가지 방법을 통하여 단편화된 데이터를 여러 지역에 나누어 저장한다.

수평적 단편화: 릴레이션을 수평적으로 단편화하는 것으로, 릴레이션을 “튜플(행)” 단위로 나눈다.
수직적 단편화: 릴레이션을 수직적으로 단편화하는 것으로, 릴레이션을 “속성(열)” 단위로 나눈다.
혼합 단편화: 수평적 단편화와 수직적 단편화를 모두 사용하여 릴레이션을 분리한다.

병행 투명성 (Concurrency Transparency)

병행 투명성은 분산 데이터베이스와 관련된 트랜잭션들이 동시에 수행되더라도 결과는 항상 일관성을 유지하는 것을 말한다.

장애 투명성 (Failure Transparency)

장애 투명성은 특정 지역 시스템에 문제가 발생해도 전체 시스템이 작업을 계속 수행할 수 있는 것을 말한다.

분산 데이터베이스의 구조

분산 데이터베이스의 일반적인 구조는 다음과 같다. 다만, 모든 분산 데이터베이스가 이러한 구조로 개발되지는 않는다.

전역 개념 스키마: 분산 데이터베이스에 저장할 모든 데이터 구조와 제약조건을 정의한다.
단편화 스키마: 전역 개념 스키마를 분할하는 방법인 단편화를 정의한다.
할당 스키마: 각 조각 스키마의 인스턴스를 물리적으로 저장해야 하는 지역을 정의한다.
지역 스키마: 지역별로 저장하고 있는 데이터 구조와 제약조건을 정의한다.

분산 데이터베이스 시스템에서는 최선의 질의 전략을 선택할 때, 데이터베이스에 위치한 디스크에 접근하는 횟수와 네트워크에서 데이터를 전송하는 비용, 하나의 질의문을 분해하여 여러 지역에서 병렬 처리함으로 얻는 성능상의 이점을 고려한다.

분산 데이터베이스의 장단점

분산 데이터베이스 시스템의 장단점은 다음과 같다.

(장점): 신뢰성과 가용성 증대
(장점): 지역 자치성과 효율성 증대
(장점): 확장성 증대
(단점): 설계 및 구축 비용 증가
(단점): 관리의 복잡성

기타 데이터베이스 응용 기술

멀티미디어 데이터베이스 시스템

멀티미디어 데이터베이스 시스템은 다양한 미디어가 조합된 멀티미디어를 저장하고 관리하는 시스템이다. 미디어 종류에 따라 다양한 질의 유형과 처리 기법이 존재한다.

데이터 유형: 텍스트, 그래픽, 이미지, 비디오, 오디오
데이터 특성: 대용량 데이터, 검색 방법과 구조가 복잡한 데이터

웹 데이터베이스 시스템

웹 서비스와 데이터베이스 시스템이 제공하는 데이터 관리 기능을 통합한 데이터베이스이다.

데이터 웨어하우스 시스템

데이터베이스 시스템에서 의사 결정에 필요한 데이터를 미리 추출하여 원하는 형태로 변환하고 통합한 읽기 전용의 데이터 저장소이다. 주체 지향적이며 통합적이고 비소멸성을 가지며 시간에 따라 변화하는 데이터베이스이다.

래퍼런스(Reference)

데이터베이스 개론 3판 - 김연희

[데이터베이스] - 보안과 권한 관리 (Security and Access Control)

shineast_ — Fri, 23 Jan 2026 12:24:42 +0900

데이터베이스 보안

데이터베이스 내의 데이터는 조직 내 사용자들이 공유하여 사용한다. 이때 허가되지 않은 외부인이 데이터베이스에 침입하여 데이터에 접근한다면 문제가 생길 것이다. 따라서 조직에서 허가된 사용자만 데이터베이스에 접근하도록 하여 보안을 유지하는 것은 매우 중요하다.

데이터베이스의 보안을 유지하여 데이터를 보호하는 방법은 다음 세 가지 유형으로 분류된다.

물리적 환경에 대한 보안: 데이터베이스에 물리적으로 손실을 발생시키는 위험으로부터 데이터베이스를 보호해야 한다.
권한 관리를 통한 보안: 접근이 허락된 사용자만 부여된 권한 내에서 데이터베이스를 사용할 수 있도록 보호해야 한다.
운영 관리를 통한 보안: 데이터 무결성을 유지하기 위하여 올바른 제약조건을 정의하고, 사용자들이 정의된 제약조건을 위반하지 않도록 통제해야 한다.

권한 관리

데이터베이스 관리 시스템은 데이터베이스의 보안을 유지하기 위하여 접근 제어 기능을 제공한다. 모든 사용자는 자신에게 발급된 계정으로 로그인하여 데이터베이스에 접근 가능하다. 이때 사용자 계정 관리는 데이터베이스 관리자가 담당한다. 로그인을 통하여 데이터베이스에 접근이 가능하다 하더라도 데이터베이스의 모든 데이터를 사용할 수 있는 것은 아니다. 각 사용자는 자신에게 허용된 권한 내에서만 데이터베이스 사용이 가능하다.

데이터베이스에 존재하는 모든 객체는 기본적으로 해당 객체를 생성한 사용자만 사용 권한을 가지게 된다. 그러나, 다른 사용자도 필요에 따라 객체에 접근할 수 있어야 한다. 이를 위해 객체의 소유자는 다른 사용자에게 자신이 소유한 객체에 대한 사용 권한을 부여하거나 취소할 수 있다.

권한 부여

객체의 소유자는 다른 사용자에게 객체에 대한 사용 권한을 부여하기 위하여 SQL문의 `GRANT` 명령어를 사용할 수 있다.

GRANT 권한 ON 객체 TO 사용자 [WITH GRANT OPTION];

-- Example
GRANT SELECT ON 고객 TO Kang;
GRANT INSERT, DELETE ON 고객 TO Kang PUBLIC;
GRANT SELECT ON 고객 TO Kang WITH GRANT OPTION;
GRANT CREATE TABLE TO Kang

데이터베이스에 존재하는 모든 유형의 객체에 다른 사용자 권한을 부여할 수 있다. 테이블과 관련하여 다른 사용자에게 부여할 수 있는 주요 권한으로는 `INSERT`, `DELETE`, `UPDATE`, `SELECT`, `REFERENCES` 등이 있다. `GRANT` 명령어는 기본적으로 테이블을 구성하는 모든 속성에 권한을 부여하지만 일부 속성만 권한을 부여하는 것도 가능하다.

`REFERENCES`는 외래키 제약조건을 정의할 수 있는 권한이다. 이 권한을 부여받으면 권한 부여 대상인 테이블의 기본키를 참조하는 외래키를 자신이 생성하는 테이블에 포함할 수 있다.
`PUBLIC` 키워드는 모든 사용자에게 권한을 똑같이 부여하고 싶을 때 사용할 수 있다.
`WITH GRANT OPTION` 키워드를 사용하여, 권한을 부여받은 사용자가 자신이 부여받은 권한을 다른 사용자에게 부여할 수 있도록 한다.

객체에 대한 권한은 객체의 소유자가 부여하지만, 테이블 생성, 뷰 생성과 같은 데이터 정의(DDL)와 관련된 시스템 권한은 데이터베이스 관리자가 직접 부여할 수 있다.

권한 취소

`GRANT` 명령어를 통해 다른 사용자에게 권한을 부여한 사용자가 자신이 부여한 권한을 취소하는 것도 가능하다. `REVOKE` 명령어는 다른 사용자에게 부여된 객체의 사용 권한을 취소하기 위하여 사용된다.

REVOKE 권한 ON 객체 TO 사용자 CASCADE | RESTRICT;

-- Example
REVOKE SELECT ON 고객 TO Kang CASCADE;
REVOKE SELECT ON 고객 TO Kang RESTRICT;
REVOKE CREATE TABLE FROM Kang;

`CASCADE` 키워드는 권한 취소 대상자인 사용자 B가 사용자 C에게 권한을 부여한 경우, 권한을 취소할 사용자 A가 사용자 B와 C의 권한을 연쇄적으로 취소할 경우 사용한다.
`RESTRICT` 키워드는 위의 경우에서 사용자 C의 권한은 취소하지 않을 경우 사용한다.

역할의 정의

데이터베이스 객체 소유자는 자신이 소유한 객체에 대한 권한들을 여러 사용자들에게 부여하는 경우가 많은데, 각 권한마다 `GRANT` 문을 따로 작성하여 부여하는 것은 번거로운 일이다. 권한을 취소할 때도 마찬가지이다. 여러 사용자에게 동일한 권한들을 부여하고 취소하는 번거로운 작업을 편리하게 수행하도록 하는 것이 “역할”이다.

역할은 여러 권한을 그룹으로 묶어놓은 것으로, 부여하고 싶은 여러 권한을 역할에 미리 넣고 필요할 때 역할을 부여하면 여러 권한을 한 번에 부여하거나 취소할 수 있다.

역할 부여

새로운 역할을 생성하는 기능은 데이터베이스 관리자만 가능하며, 역할을 생성할 때는 `CREATE ROLE` 명령어를 사용한다. 그리고 역할을 사용자에게 부여하는 것도 데이터베이스 관리자가 `GRANT` 문을 통해 진행한다.

CREATE ROLE 역할이름;
GRANT 권한 ON 객체 TO 롤이름;

-- Example
CREATE ROLE role_1;
GRANT SELECT, INSERT, DELETE ON 고객 TO role_1;

역할을 이용하면 `GRANT` 문만으로 여러 권한을 한 번에 부여할 수 있고 다른 사용자에게 동일한 권한을 부여해야 할 때도 역할 하나만 부여하면 된다. 만약 역할에 변화가 생기면, 해당 역할을 부여받은 모든 사용자에게 변화가 전달된다.

역할 취소

부여한 역할을 취소하는 작업 또한 데이터베이스 관리자가 담당하며, 부여된 역할을 취소할 때는 `REVOKE` 문을 이용한다.

REVOKE 역할이름 FROM 사용자;

-- Example
REVOKE role_1 FROM Kang;

역할을 아예 제거하는 작업은 `DROP ROLE` 문을 이용한다. 당연히 데이터베이스 관리자가 담당한다. 역할이 제거되면 제거된 역할을 부여받은 모든 사용자도 역할에 속한 권한을 가질 수 없게 된다.

DROP ROLE 역할이름;

-- Example
DROP ROLE role_1;

래퍼런스(Reference)

데이터베이스 개론 3판 - 김연희

[데이터베이스] - 회복과 병행 제어 (Recovery & Concurrency Control)

shineast_ — Sat, 17 Jan 2026 15:40:09 +0900

장애의 유형

장애란 시스템이 제대로 작동하지 않는 상태를 말한다. 데이터베이스 시스템에서 발생할 수 있는 장애는 다음과 같이 분류된다.

트랜잭션 장애: 트랜잭션 수행 중 오류가 발생하여 정상적으로 수행을 할 수 없는 상태이다.
시스템 장애: 하드웨어의 결함으로 정상적으로 수행을 할 수 없는 상태이다.
미디어 장애: 디스크 장치의 결함으로 디스크에 저장된 데이터베이스의 일부 혹은 전체가 손상된 상태를 말한다.

회복 기법

회복은 데이터베이스에 장애가 발생했을 때, 장애가 발생하기 전의 모순이 없고 일관된 상태로 복구시키는 것을 말한다. 장애가 발생하면 복구하는 기간 동안에는 데이터베이스에 접근하여 업무를 진행할 수 없기에 회복 과정은 빠른 시간 내에 이루어져야 한다.

회복 과정을 수행할 때, 덤프 또는 로그 방법을 사용하여 데이터를 복사해놓았다가 회복시킬 때 복사본을 사용한다. 덤프 방법과 로그 방법은 다음과 같다.

덤프(Dump): 데이터베이스 전체를 다른 저장 장치에 주기적으로 복사하는 방법
로그(Log): 데이터베이스에서 변경 연산이 실행될 때마다 데이터를 변경하기 이전 값과 변경한 이후의 값을 별도의 파일에 기록하는 방법

덤프 방법 또는 로그 방법으로 중복 저장한 데이터를 이용하여 데이터를 복구할 때는 Redo 연산이나 Undo 연산을 사용한다.

Redo(재실행): 로그에 기록된 “변경 연산 후의 값”을 이용하여 변경 연산을 재실행하는 방법으로, 데이터베이스가 전반적으로 손상된 경우에 주로 사용한다.
Undo(취소): 로그에 기록된 “변경 연산 이전의 값”을 이용하여 변경 연산을 취소하는 방법으로, 데이터베이스가 변경 중이었거나 이미 변경된 내용만 신뢰성을 잃은 경우에 주로 사용한다.

장애가 발생하는 시점과 유형이 다양한데, 이러한 장애들을 빠르게 해결하기 위하여 효율적인 회복 기법들을 사용한다. 데이터베이스 회복 기법으로는 “로그 회복 기법”, “검사 시점 회복 기법”, “미디어 회복 기법”이 있다.

로그 회복 기법

로그를 이용한 회복 기법은 데이터를 변경한 연산 결과를 데이터베이스에 반영하는 시점에 따라 “즉시 갱신 회복 기법”과 “지연 갱신 회복 기법”으로 분류된다.

즉시 갱신 회복 기법

즉시 갱신 회복 기법은 트랜잭션 수행 중에 데이터를 변경한 연산의 결과를 데이터베이스에 “즉시” 반영한다. 장애 발생을 대비하기 위해 데이터 변경에 대한 내용을 로그 파일에 기록한다. 데이터베이스 회복 시 로그를 제대로 사용하려면, 트랜잭션에서 데이터 변경 연산이 실행되었을 때 로그 파일에 로그 레코드를 먼저 기록한 후 데이터베이스에 변경 연산을 반영해야 한다.

즉시 갱신 회복 기법은 장애가 발생하면 로그 파일에 기록된 내용을 참조하여 장애 발생 시점에 따라 Redo 또는 Undo 연산을 실행하여 데이터베이스를 복구한다. 이때 Redo 또는 Undo 연산을 실행하는 기준은 다음과 같다.

Redo 연산 실행: 트랜잭션이 완료된 후에 장애가 발생하면 Redo 연산을 수행한다.
Undo 연산 실행: 트랜잭션이 완료되기 전에 장애가 발생하면 Undo 연산을 수행한다.

지연 갱신 회복 기법

지연 갱신 회복 기법은 트랜잭션이 수행되는 동안에는 데이터 변경 연산의 결과를 데이터베이스에 즉시 반영하지 않고 로그 파일에만 기록했다가, 트랜잭션이 부분 완료된 후에 로그에 기록된 내용을 이용하여 데이터베이스에 한 번에 반영한다. 트랜잭션이 수행되는 동안 장애가 발생하면 로그 기록을 제거하면 되기에 Undo 연산이 필요없고 Redo 연산만 필요하다. 따라서 로그 레코드에 변경 이전 값을 기록할 필요가 없다.

검사 시점 회복 기법

로그를 이용한 회복 기법은 로그 전체를 분석하여 Redo 연산 또는 Undo 연산을 결정해야 하기에 비효율적인 부분이 발생한다. 검사 회복 기법은 로그 기록을 이용하되, 일정 시간 간격으로 검사 시점(Checkpoint)을 만든다.

장애가 발생한 경우, 가장 최근 검사 시점 이후의 트랜잭션에만 회복 작업을 수행한다. 검사 시점 회복 기법을 이용하면 회복 작업의 범위가 검사 시점 이후로 정해지기에 불필요한 회복 작업을 수행하지 않기에 데이터베이스 회복 시간이 단축된다. 회복 작업의 범위가 정해지면 즉시 갱신 회복 기법 또는 지연 갱신 회복 기법을 이용하여 회복 작업을 수행한다.

미디어 회복 기법

미디어 회복 기법은 디스크에 발생할 수 있는 장애에 대해서 적용할 수 있는 회복 기법이다. 미디어 회복 기법은 전체 데이터베이스의 내용을 일정 주기마다 다른 안전한 저장 장치에 복사해두는 덤프를 사용한다. 이를 통해 디스크 장애가 발생하면 덤프를 이용하여 장애 발생 이전의 일관된 데이터베이스 상태로 복구한다. 필요에 따라 로그의 내용을 토대로 Redo 연산을 수행한다. 다만, 전체 데이터베이스를 다른 저장 장치에 복사하는 것은 비용도 많이 들고 복사하는 동안 트랜잭션 수행도 중단되어야 하기에 CPU가 낭비된다.

병행 제어의 정의

데이터베이스 관리 시스템은 여러 사용자가 데이터베이스를 동시에 공유할 수 있도록 여러 개의 트랜잭션이 동시에 수행되는 병행 수행을 지원한다. 이때, 병행 수행은 여러 트랜잭션이 차례로 번걸아 수행되는 인터리빙(Interleaving) 방식으로 진행된다. 그런데 병행 수행을 할 때 각 트랜잭션이 다른 트랜잭션의 방해를 받지 않고 제대로 수행되도록 제어가 필요하다. 이를 병행 제어 또는 동시성 제어라고 한다.

병행 수행의 문제점

병행 수행을 제어 없이 진행하면 여러 문제가 발생할 수 있다. 대표적인 문제로는 갱신 분실, 모순성, 연쇄 복귀가 있다.

갱신 분실 (Lost Update)

갱신 분실이란 하나의 트랜잭션이 수행한 데이터 변경 연산의 결과를 다른 트랜잭션이 덮어서 변경 연산이 무효화되는 것이다.

두 개 이상의 트랜잭션을 동시에 수행하더라도 갱신 분실 문제가 발생하지 않고 순차적으로 수행한 것과 같은 결과 값을 얻을 수 있어야 정확한 병행 수행이라 할 수 있다.

모순성 (Inconsistency)

모순성이란 하나의 트랜잭션이 여러 개의 데이터 변경 연산을 실행할 때, 일관성 없는 상태의 데이터베이스에서 데이터를 가져와서 연산을 실행하여 모순된 결과가 발생하는 것이다.

두 개 이상의 트랜잭션을 동시에 수행하더라도 모순성의 문제가 발생하지 않고 순차적으로 수행한 것과 같은 결과 값을 얻을 수 있어야 정확한 병행 수행이라 할 수 있다.

연쇄 복귀 (Cascading Rollback)

연쇄 복귀란 트랜잭션이 완료되기 전에 장애가 발생하여 rollback 연산을 수행하면, 이 트랜잭션이 장애 발생 전에 변경한 데이터를 가져가 변경 연산을 실행한 또 다른 트랜잭션에도 rollback 연산을 연쇄적으로 실행해야 한다는 것이다.

만약 장애가 발생한 트랜잭션이 rollback 연산을 실행하기 전에 변경한 데이터를 가져가 사용하는 다른 트랜잭션이 수행을 완료해버리면 rollback 연산을 실행할 수 없어 큰 문제가 발생하게 된다. 두 개 이상의 트랜잭션을 동시에 수행하더라도 연쇄 복귀의 문제가 발생하지 않고 순차적으로 수행한 것과 같은 결과 값을 얻을 수 있어야 정확한 병행 수행이라 할 수 있다.

트랜잭션 스케줄

병행 수행에서는 인터리빙 방식으로 진행되기에 트랜잭션의 연산을 실행하는 순서에 따라 트랜젹션들의 수행 결과가 달라지기도 하고, 문제가 생기기도 한다. 따라서 여러 트랜잭션을 병행 수행할 때는 트랜잭션들의 연산을 실행하는 순서가 중요하다.

트랜잭션 스케줄은 트랜잭션에 포함되어 있는 연산들을 수행하는 순서이다. 트랜잭션에는 많은 연산들이 포함되어 있기에 트랜잭션 스케줄도 여러 가지가 있을 수 있다. 트랜잭션 스케줄은 “직렬 스케줄”, “비직렬 스케줄”, “직렬 가능 스케줄” 이렇게 세 가지 유형으로 구분할 수 있다

직렬 스케줄 (Serial Schedule)

직렬 스케줄은 인터리빙 방식을 이용하지 않고 트랜잭션 별로 연산들을 순차적으로 실행시키는 것이다. 직렬 스케줄에 따라 트랜잭션이 수행되면, 다른 트랜잭션의 방해를 받지 않고 독립적으로 수행되기에 항상 모순이 없는 정확한 결과를 얻을 수 있다.

같은 트랜잭션들을 대상으로 해도 트랜잭션의 수행 순서에 따라 다양한 직렬 스케줄이 만들 수 있고, 직렬 스케줄마다 최종 결과가 달라질 수 있다. 그러나, 직렬 스케줄의 결과는 정확하기에 어떤 직렬 스케줄을 사용하는가는 중요하지 않다.

직렬 스케줄에 따라 트랜잭션을 수행하면 정확한 결과를 얻을 수 있으나, 인터리빙 방식이 아니며 각 트랜잭션을 독립적으로 수행하기에 병행 수행이라고 할 수 없다. 따라서 직렬 스케줄은 일반적으로 잘 사용하지 않는다.

비직렬 스케줄 (Nonserial Schedule)

비직렬 스케줄은 인터리빙 방식을 사용하여 트랜잭션을 병행하여 수행시키는 것이다. 비직렬 스케줄에 따라 여러 트랜잭션을 병행 수행하면 갱신 분실, 모순성, 연쇄 복귀 등의 문제가 발생할 수 있어 최종 결과의 정확성을 보장할 수 없다.

트랜잭션의 연산들을 실행하는 순서에 따라 다양한 비직렬 스케줄이 만들어질 수 있다. 이 중에는 모순이 없는 정확한 결과를 생성하는 비직렬 스케줄도 있으나, 잘못된 결과를 수행하는 비직렬 스케줄도 있다. 따라서 어떤 비직렬 스케줄을 선택하여 트랜잭션들을 수행하느냐가 중요하다.

직렬 가능 스케줄 (Serializable Schedule)

직렬 가능 스케줄은 직렬 스케줄에 따라 수행한 것과 같이 정확한 결과를 생성하는 비직렬 스케줄이다. 모든 비직렬 스케줄이 직렬 가능한 것은 아니다. 비직렬 스케줄 중에서 정확한 결과가 생성되는 것은 직렬 가능 스케줄이고 정확하지 않은 결과가 생성되는 것은 직렬 가능 스케줄이 아니다.

직렬 가능 스케줄을 이용하여 트랜잭션을 병행 수행해야 하지만, 직렬 가능 스케줄인지 여부를 판단하는 것은 쉽지 않다. 다수의 트랜잭션을 대상으로 비직렬 스케줄을 찾아내는 것도 쉽지 않으며 게다가 트랜잭션 스케줄을 하나씩 수행해보며 직렬 스케줄과 같은 결과가 나오는지 비교하는 것도 어렵기 때문이다. 따라서 대부분 데이터베이스 관리 시스템에서는 직렬 가능 스케줄인지를 검사하는 것보다는 직렬 가능성을 보장하는 병행 제어 기법을 사용한다.

병행 제어 기법

병행 제어 기법은 여러 트랜잭션을 병행 수행하면서도 정확한 결과를 얻을 수 있는 직렬 자능성을 보장받기 위해 사용한다. 병행 제어 기법은 모든 트랜잭션이 지키는 경우 직렬 가능성이 보장되는 규약을 정의하고, 트랜잭션들이 이 규약을 따르도록 하는 것이다.

따라서 트랜잭션 스케줄이 직렬 가능 스케줄인지 미리 검사할 필요가 없다. 모든 트랜잭션이 병행 제어 기법에서 정의한 규약을 따르면 해당 스케줄은 직렬 가능성을 보장할 수 있다.

로킹 기법

로킹 기법은 병행 수행되는 트랜잭션들이 동일한 데이터에 동시에 접근하지 못하도록 lock 과 unlock 이라는 2개의 연산을 이용해 제어한다. 두 가지 연산을 통해 다른 트랜잭션의 방해를 받지 않고 데이터에 독점적으로 접근할 수 있다. 로킹 기법의 원리는 한 트랜잭션이 먼저 접근한 데이터에 대한 연산을 모두 마칠 때까지 해당 데이터에 다른 트랜잭션이 접근하지 못하도록 “상호 배제”하여 직렬 가능성을 보장하는 것이다.

lock 연산: 트랜잭션이 사용할 데이터에 대한 독점권을 가지기 위해 사용한다.
unlock 연산: 트랜잭션이 데이터에 대한 독점권을 반납하기 위해 사용한다.

lock 연산은 전체 데이터베이스에서 데이터베이스를 구성하는 속성에 이르기까지 다양한 크기의 데이터를 대상으로 실행 가능하다. 가장 큰 단위인 전체 데이터베이스에 lock 연산을 실행하면 제어가 간단해지지만 데이터베이스에 하나의 트랜잭션만 수행되는 것과 같기에 병행 수행이라 하기 어렵다. 반면, 가장 작은 단위인 속성에 lock 연산을 하면 독점하는 범위가 좁아 많은 수의 트랜잭션을 병행 수행할 수 있지만 제어가 복잡해진다.

즉, 로킹 단위가 커질수록 병행성은 낮아지지만 제어가 쉽고, 로킹 단위가 작아질수록 제어가 어렵지만 병행성은 높아진다. 따라서 시스템에 따라 적절한 로킹 단위를 선택하는 것이 중요하다.

그러나 기본 로킹 기법은 병행 수행을 제어할 수 있지만 너무 엄격한 제약으로 인해 어떤 순간이든 데이터에 대한 독점권은 하나의 트랜잭션만 가진다. 트랜잭션이 데이터를 변경시키는 write 연산의 경우는 독점권을 가져야 하지만, 단순히 데이터를 읽는 read 연산의 경우 트랜잭션이 같은 데이터에 대해 동시에 수행해도 문제가 생기지 않는다. 이와 같은 트랜잭션의 처리 효율성을 높이기 위하여 lock 연산을 두 종류로 구분할 수 있다.

공용 lock(Shared Lock): 트랜잭션이 데이터에 대해 공용 lock 연산을 실행하면 해당 데이터에 read 연산을 사용할 수 있지만, write 연산은 사용할 수 없다. 해당 데이터에 다른 트랜잭션도 공용 lock 연산을 동시에 실행할 수 있다.
전용 lock(Exclusive Look): 트랜잭션이 데이터에 전용 lock 연산을 실행하면 해당 데이터에 read 연산과 write 연산을 모두 실행할 수 있다. 해당 데이터에 다른 트랜잭션은 공용이든 전용이든 어떤 lock 연산도 수행할 수 없다.

이렇게 로킹 기법 규약을 지켜도 잘못된 결과를 얻을 수 있다. 그 이유는 lock과 unlock 연산이 실행되는 시점으로 인함이다. 이 문제를 해결하기 위해서는 lock과 unlock 연산을 실행하는 시점에 대한 새로운 규약이 추가로 필요하다.

2단계 로킹 규약

2단계 로킹 규약이란 기본 로킹 규약의 문제를 해결하고 트랜잭션의 직렬 가능성을 보장하기 위해 lock 과 unlock 연산의 수행 시점에 대한 새로운 규약을 추가한 것이다.

트랜잭션 스케줄의 모든 트랜잭션이 2단계 로킹 규약을 준수하면 해당 스케줄은 직렬 가능성이 보장된다. 2단계 로킹 규약을 따르려면 모든 트랜잭션이 lock 연산과 unlock 연산을 다음과 같이 2단계로 나누어 실행해야 한다.

확장 단계: 트랜잭션이 lock 연산만 실행할 수 있고, unlock 연산은 실행할 수 없는 단계
축소 단계: 트랜잭션이 unlock 연산만 실행할 수 있고, lock 연산은 실행할 수 없는 단계

트랜잭션이 처음에 수행되면 확장 단계로 들어가 lock 연산만 실행할 수 있다. 그리고 unlock 연산을 실행하면 축소 단계로 들어가 그때부터는 unlock 연산만 실행할 수 있다. 2단계 로킹 규약을 준수하는 트랜잭션은첫 번째 unlock 연산을 실행하기 전에 필요한 모든 lock 연산을 실행해야 한다.

2단계 로킹 규약을 적용하면 트랜잭션 스케줄의 직렬 가능성을 보장할 수 있지만, 교착 상태(Dead Lock)가 발생할 수 있어 이에 대한 해결책이 필요하다. 교착 상태란 트랜잭션들이 상대가 독점하고 있는 데이터에 unlock 연산이 실행되기를 서로 기다리며 수행을 중단하는 상태이다. 교착 상태는 처음부터 발생하지 않도록 예방하거나, 발생한 경우 최대한 빠르게 탐지하여 필요한 조치를 취해야 한다.

래퍼런스(Reference)

데이터베이스 개론 3판 - 김연희

[데이터베이스] - 트랜잭션 (Transaction)

shineast_ — Tue, 13 Jan 2026 16:05:19 +0900

트랜잭션 정의

데이터베이스는 다수의 사용자가 동시에 사용해도 항상 정확한 데이터를 유지해야 하며, 장애가 발생하더라도 빠른 시간 내에 원래의 상태로 복구되어야 한다. 즉, 데이터베이스 관리 시스템은 항상 정확하고 일관된 상태를 유지해야 한다. 이때, 트랜잭션이 사용된다.

트랜잭션은 작업 하나를 수행하는데 필요한 데이터베이스의 연산들을 모아놓은 것으로, 데이터베이스의 논리적인 작업의 단위이다. 트랜잭션을 관리함으로 데이터베이스의 회복과 병행 제어가 가능해진다.

트랜잭션의 모든 명령문이 완벽히 처리되거나, 하나도 처리되지 않아야 데이터베이스가 모순 없는 일관된 상태를 유지할 수 있다. 일반적으로 데이터베이스를 변경하는 `INSERT`문, `UPDATE`문, `DELETE`문의 실행을 트랜잭션으로 관리한다.

트랜잭션 특성 (ACID)

트랜잭션이 성공적으로 처리되어 데이터베이스의 무결성과 일관성을 유지하기 위해서는 다음 네 가지 특성을 필수적으로 만족시켜야 한다. 트랜잭션의 네 가지 특성을 각 특성의 이니셜을 따서 ACID 특성이라고 한다.

원자성 (Atomicity)

트랜잭션의 원자성(Atomicity)은 트랜잭션을 구성하는 연산들이 모두 정상적으로 실행되거나 하나도 실행되지 않아야 함을 의미한다. 즉, All or Nothing 방식을 취한다.

트랜잭션을 수행하다가 장애가 발생하여 작업을 완료하지 못하면, 현재까지 실행된 연산 처리는 모두 취소되고 데이터베이스는 트랜잭션 작업 전의 상태로 되돌아가야 한다. 트랜잭션을 구성하는 연산 중 일부만 처리한 결과가 데이터베이스에 반영하는 일이 없어야 한다.

일관성 (Consistency)

트랜잭션의 일관성(Consistency)은 트랜잭션이 성공적으로 수행된 후, 데이터가 일관된 상태를 유지해야 함을 의미한다.

트랜잭션 수행 과정 중에서 데이터베이스가 일시적으로 일관된 상태를 유지 못할 수 있지만, 트랜잭션의 수행이 성공적으로 완료되면 데이터베이스는 일관된 상태를 유지해야 한다.

격리성 (Isolation)

트랜잭션의 격리성(Isolation)은 현재 수행 중인 트랜잭션이 완료될 때까지 생성된 중간 연산 결과에 다른 트랜잭션들이 접근할 수 없음을 의미한다.

격리성에 의해 여러 트랜잭션들이 동시에 수행되더라도 각 트랜잭션이 독립적으로 수행될 수 있도록 다른 트랜잭션의 중간 연산 결과에 서로 접근하지 못한다. 이를 통해 트랜잭션들이 동시에 수행되는 것처럼 느끼면서도 순서대로 하나씩 수행되는 것처럼 정확하고 일관된 결과를 얻을 수 있다.

지속성 (Durability)

트랜잭션의 지속성(Durability)은 트랜잭션이 성공적으로 완료된 후 데이터베이스에 반영한 수행 결과는 어떤 경우에도 손실되지 않고 영구적이어야 함을 의미한다.

시스템에 장애가 발생하더라도 트랜잭션 작업 결과는 없어지지 않고 데이터베이스에 남아있어야 한다는 것이다.

트랜잭션 연산

트랜잭션의 수행과 관련하여 주로 사용되는 연산으로는 `COMMIT` 연산과 `ROLLBACK` 연산이 있다.

COMMIT

`COMMIT` 연산은 트랜잭션의 수행이 성공적으로 완료되었음을 선언하는 연산으로, `COMMIT` 연산이 실행된 후에야 트랜잭션의 수행 결과가 데이터베이스에 반영되며 일관된 상태를 지속적으로 유지할 수 있다.

ROLLBACK

`ROLLBACK` 연산은 트랜잭선의 수행이 실패했음을 선언하는 연산으로, `ROLLBACK` 연산이 실행되면 트랜잭션이 지금까지 실행한 연산의 결과는 취소되고 트랜잭션이 수행되기 전 상태로 되돌아간다.

트랜잭션 상태

트랜잭션은 다섯 가지 상태 중 하나에 속하게 된다. 트랜잭션이 수행되기 시작하면 활동 상태가 되고, 활동 상태의 트랜잭션이 마지막 연산을 처리하고 나면 부분 완료 상태가 되며, 부분 완료 상태의 트랜잭션이 COMMIT 연산을 실행하면 완료 상태가 된다. 활동 상태나 부분 완료 상태에서 여러 원인으로 인해 정상적인 수행이 불가능해지면 트랜잭션을 실패상태가 된다. 실패 상태의 트랜잭션은 ROLLBACK 연산이 실행되어 철회 상태가 된다. 완료 또는 철회 상태에 도달하면 트랜잭션은 종료된다.

활동 상태(Active)

활동 상태는 트랜잭션이 수행되기 시작하여 현재 수행 중인 상태를 말한다. 활동 상태인 트랜잭션은 상황에 따라 부분 완료 상태나 실패 상태가 된다.

부분 완료 상태 (Partially Committed)

부분 완료 상태는 트랜잭션의 마지막 연산이 실행된 직후의 상태를 말한다. 트랜잭션의 모든 연산을 처리한 상태이지만 최종 결과가 데이터베이스에 반영되지 않은 상태이다. 트랜잭션의 연산은 모두 처리했지만 트랜잭션의 수행이 완료된 것은 아니다. 부분 완료 상태인 트랜잭션은 상황에 따라 완료 상태나 실패 상태가 된다.

완료 상태 (Committed)

완료 상태는 트랜잭션이 성공적으로 완료되어 COMMIT 연산을 실행한 상태를 말한다. 트랜잭션이 완료 상태가 되면 최종 결과가 데이터베이스에 반영되고 데이터베이스는 새로운 일관된 상태가 되며 트랜잭션은 종료된다.

실패 상태 (Failed)

실패 상태는 여러 원인으로 인하여 장애가 발생하고 트랜잭션의 수행이 중단된 상태를 말한다. 트랜잭션을 더 이상 수행할 수 없을 때 실패 상태가 된다.

철회 상태 (Aborted)

철회 상태는 트랜잭션을 수행하는데 실패하여 ROLLBACK 연산을 실행한 상태를 말한다. 트랜잭션이 철회 상태가 되면 지금까지 실행한 모든 트랜잭션의 연산은 취소되고 트랜잭션이 수행되기 전의 데이터베이스 상태로 되돌아가며 트랜잭션이 종료된다. 철회 상태로 종료된 트랜잭션은 상황에 따라 다시 수행되거나 폐기된다.

래퍼런스(Reference)

데이터베이스 개론 3판 - 김연희

[데이터베이스] - 정규화 (Normalization)

shineast_ — Fri, 9 Jan 2026 23:47:57 +0900

이상 현상 (Database Anomalies)

데이터베이스를 잘못 설계하면 불필요한 데이터 중복이 발생하며, 릴레이션의 데이터에 대한 연산 작업을 수행할 때 문제가 생길 수 있다. 이를 “이상 현상(Anomaly)”이라고 한다. 이러한 이상 현상을 제거하면서 데이터베이스를 올바르게 설계하는 과정이 “정규화(Normalization)”이다. 이상 현상은 “삽입 이상”, “갱신 이상”, “삭제 이상”으로 분류된다.

`삽입 이상(Insertion Anomaly)`: 릴레이션에 새 데이터를 삽입해야 할 때, 불필요한 데이터도 함께 삽입되는 문제를 말한다.
`갱신 이상(Update Anomaly)`: 릴레이션의 중복된 튜플들 중, 일부만 수정되어 데이터가 불일치하게 되는 문제를 말한다.
`삭제 이상(Deletion Anomaly)`: 릴레이션에서 튜플을 삭제할 때, 필수적인 데이터까지 함께 삭제되어 데이터가 손실되는 문제를 말한다.

함수 종속성 (Functional Dependency)

하나의 릴레이션을 구성하는 속성들의 부분 집합을 $X$와 $Y$라 할 때, 어느 시점이든 릴레이션 내의 모든 튜플에서 $X$값에 대한 $Y$이 항상 하나이면 “$X$가 $Y$를 함수적으로 결정한다.” 또는 “$Y$가 $X$에 함수적으로 종속되어 있다.” 라고 표현한다. 함수 종속 관계는 “$X \rightarrow Y$로 표현하며 이때, $X$를 결정자, $Y$를 종속자라고 한다.하나의 릴레이션을 구성하는 속성들 간의 함수 종속 관계를 도식화하여 표현할 수 있는데, 이를 함수 종속 다이어그램이라고 한다.

함수 종속 관계를 판단할 때, 현재 시점에 릴레이션에 포함된 속성 값만으로 판단하면 안 된다. 그 이유는 릴레이션에서 속성 값은 가변적이기 때문이다. 따라서, 속성 값이 아닌 속성 자체의 특성을 고려하여 함수 종속 관계를 판단해야 한다.

일반적으로, 기본키와 후보키는 릴레이션을 구성하는 다른 모든 속성들을 함수적으로 결정한다. 그러나, 기본키나 후보키만 결정자가 될 수 있는 것은 아니며, 기본키나 후보키가 아니라도 함수 종속 관계에서 결정자가 될 수 있다. 이때, 속성이 기본키의 일부만으로도 결정되는가, 아니면 반드시 기본키 전체가 필요한가에 따라 완전 함수 종속과 부분 함수 종속으로 나눌 수 있다.

`완전 함수 종속(Full Functional Dependency)`: 기본키 전체가 있어야만 속성이 결정되는 경우
`부분 함수 종속(Partial Functional Dependency)`: 기본키의 일부만 있어도 속성이 결정되는 경우

정규화의 기본 개념 (Normalization)

정규화의 필요성

관련이 없는 속성들을 하나의 릴레이션에 모아두는 경우, 여러 이상 현상이 발생할 수 있다. 이러한 문제를 해결하기 위하여 릴레이션을 구성할 때, 관련 있는 속성들로만 구성해야 한다. 이때, 필요한 과정이 “정규화(Normalization)”이다.

정규화는 이상 현상이 발생하지 않도록 릴레이션을 분해하는 과정이다. 이때, 함수 종속성을 이용하여 릴레이션을 연관성이 있는 속성들로만 구성되도록 분해해야 한다. 이러한 과정을 통해 이상 현상이 발생하지 않는 올바른 릴레이션을 만들 수 있다.

정규형 종류

릴레이션이 정규화된 정도는 정규형(Normal Form)으로 표현하는데, 정규형은 제1정규형, 제2정규형, 제3정규형, 보이스/코드 정규형 제4정규형, 제5정규형으로 나뉜다. 각 정규형마다 만족시켜야 하는 제약조건이 존재하며, 릴레이션이 특정 정규형의 제약조건을 만족하면 해당 정규형에 속하게 된다. 정규형의 차수가 높아질수록 요구되는 제약조건도 많아지고 엄격해진다.

정규형의 차수가 높을수록 이상 현상이 발생할 가능성이 적은 설계가 잘된 릴레이션이지만, 모든 릴레이션이 제5정규형에 속할 필요는 없기에 릴레이션의 특성을 잘 고려하여 적합한 정규형을 선택해야 한다.

제1정규형 (1NF)

제1정규형은 릴레이션에 속한 모든 속성의 도메인이 원자 값으로만 구성되어 있어야 한다.

원자 값이란 속성이 더 이상 분해되지 않는 상태를 말하며, 다중 값을 가지는 속성을 포함하는 릴레이션은 제약조건을 만족하지 못하기에 제1정규형에 속하지 못한다.

제1정규형을 만족해야 관계형 데이터베이스의 릴레이션이 될 자격이 생긴다. 그러나 제1정규형에는 속하더라도 불필요한 데이터 중복으로 인해 이상 현상이 발생할 수 있다.

제2정규형 (2NF)

제2정규형은 릴레이션이 제1정규형에 속하고, 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속되어야 한다.

즉, 부분 함수 종속이 모두 제거되고 모든 속성이 기본키에 완전 함수 종속되도록 하는 정규화 과정을 거치면 제2정규형이 될 수 있다.

정규화 과정에서 릴레이션을 분해할 때, 분해된 릴레이션들은 자연 조인하여 분해 전의 릴레이션으로 다시 복원될 수 있어야 한다. 이를 무손실 분해라고 하며, 정규화 과정에서 수행되는 릴레이션의 분해는 무손실 분해여야 한다. 부분 함수 종속은 없더라도 함수 종속성을 여러 개 포함한다면 제2정규형에 속하더라도 릴레이션에 이상 현상이 발생할 수 있다.

제3정규형 (3NF)

제3정규형은 릴레이션이 제2정규형에 속하고, 기본키가 아닌 모든 속성이 이행적 함수 종속이 되지 않아야 한다.

릴레이션을 구성하는 3개의 속성 집합 $X, \ Y, \ Z$에 함수 종속 관계 $X \rightarrow Y$와 $Y \rightarrow Z$가 존재하면 논리적으로 $X \rightarrow Z$가 성립하는데 이를 이행적 함수 종속이라고 한다.

제2정규형을 만족하더라도 하나의 릴레이션에 여러 개의 함수 종속 관계가 존재하고 이행적 함수 종속 관계가 유도되면 이상 현상이 발생할 수 있다. 따라서 이행적 함수 종속을 제거하는 정규화 과정을 거쳐야 제3정규형이 될 수 있다.

제3정규형에 속하더라도 후보키가 여러 개의 후보키가 존재하는 경우, 이상 현상은 발생할 수 있다.

보이스/코드 정규형(BCNF)

보이스/코드 정규형은 릴레이션의 함수 종속 관계에서 모든 결정자가 후보키여야 한다.

이때 보이스/코드 정규형에 속하는 모든 릴레이션은 제3정규형에 속하지만, 제3정규형에 속하는 릴레이션이라고 해서 모두 보이스/코드 정규형에 속하는 것은 아니다. 모든 결정자가 후보키가 되도록 테이블을 무손실 분해하면 BCNF 정규형이 될 수 있다.

제4정규형과 제5정규형

제4정규형은 릴레이션이 보이스/코드 정규형(BCNF)에 속하고, 함수 종속이 아닌 다치 종속을 제거해야 한다.

제5정규형은 릴레이션이 제4정규형에 속하고, 후보키를 통하지 않는 조인 종속을 제거해야 한다.

데이터베이스를 설계할 때, 릴레이션이 반드시 제5정규형에 속하도록 분해하는 것은 비효율적인 경우가 많다. 일반적으로 제3정규형 또는 BCNF 정규형에 속하도록 릴레이션을 분해하여 데이터 중복을 줄이고 이상 현상 문제를 해결한다.

래퍼런스(Reference)

데이터베이스 개론 3판 - 김연희

[데이터베이스] - 데이터베이스 설계 (Database Design)

shineast_ — Mon, 5 Jan 2026 16:14:41 +0900

데이터베이스 설계 단계

데이터베이스 설계는 사용자의 요구사항을 고려하여 데이터베이스를 생성하는 과정으로, 데이터베이스 설계 과정의 각 단계에서 수행하는 주요 작업은 다음과 같다.

요구사항 분석: 실제 업무를 처리하는 사용자에게서 필요한 데이터의 종류와 처리 방법과 같은 다양한 요구 사항을 수집한다. 그 후, 수집한 요구사항을 분석하여 그 결과를 요구사항 명세서로 작성한다.
개념적 설계: 요구사항 명세서를 바탕으로, 요구사항을 개념적 데이터 모델을 이용하여 표현한다. E-R 모델과 같은 개념적 데이터 모델은 DBMS의 종류에 독립적이면서 중요한 데이터 요소 간의 관계를 표현할 때 사용한다.
논리적 설계: 개발에 사용할 DBMS에 적합한 논리적 데이터 모델을 이용하여 개념적 설계 단계에서 생성한 개념적 구조를 기반으로 논리적 구조를 설계한다. DBMS의 종류에 따라 다양한 논리적 데이터 모델로 사용할 수 있다.
물리적 설계: 논리적 설계 단계에서 생성된 논리적 구조를 기반으로 물리적 구조를 설계한다. 이때, 물리적 구조란 데이터베이스를 저장 정치에 실제로 저장하기 위한 내부 저장 구조와 접근 경로 등을 말한다.
구현: 설계 단계의 결과물을 기반으로 DBMS에서 SQL로 작성한 명령문을 실행하여 데이터베이스를 실제로 생성한다.

요구사항 분석

요구사항 분석 단계에서는 사용자들이 데이터베이스에 원하는 것이 무엇인지 분석한다. 개발한 데이터베이스의 목적을 파악하고, 분석한 사용자 요구사항의 내용을 명세서로 작성한다. 이때 작성한 요구사항 명세서는 설계 단계의 기반이 된다.

요구사항 분석 단계에서는 데이터베이스를 사용할 주요 사용자의 범위부터 결정하고, 범위를 결정하여 불필요한 요구사항을 수집하지 않도록 한다. 사용자의 범위가 결정되면 해당 사용자가 조직에서 수행하는 업무를 분석한다. 이 분석 과정을 통해 필요한 데이터가 무엇인지 파악하고 데이터 처리 방식을 고려하여 요구사항들을 수집하고 분석한다.

요구사항 분석 단계는 사용자가 요구하는 데이터베이스 용도를 결정하는 단계이기에 데이터베이스를 잘못 설계하여 재개발하는 일이 없도록 신중하고 꼼꼼하게 작업이 수행되어야 한다.

개념적 설계 (Conceptual Design)

개념적 설계에서는 요구사항 분석 단계의 결과물을 개념적 데이터 모델을 이용하여 표현한다. 개념적 데이터 모델은 주로 E-R 모델을 사용한다. 즉, 요구사항 분석 결과를 기반으로 현실 세계의 중요한 데이터 요소인 개체를 추출하고 개체 간의 관계를 결정하여 E-R 다이어그램으로 표현한다.

요구사항을 개념적 데이터 모델로 변환하는 작업을 개념적 모델링이라 하며, E-R 다이어그램과 같이 개념적 데이터 모델로 표현된 개념적 설계물을 개념적 스키마라고 한다. E-R 모델의 핵심 요소인 개체를 추출하고, 주요 속성과 키 속성을 선별하고, 개체 간의 관계를 결정해야 한다.

개체와 속성 추출

개념적 설계 단계에서 기본 작업은 요구 사항 분석 단계의 결과물에서 개체를 추출하는 일이다. 이때, 개체란 저장할 만한 가치가 있는 중요 데이터를 지닌 구별되는 모든 것을 의미하며, 개념적 모델링을 함에 있어 가장 중요한 요소이다. 개체부터 결정해야 속성과 관계도 결정할 수 있다. 개체를 추출하는 방법은 다음과 같다.

제시된 요구사항의 문장들에서 명사를 찾는다.
업무 처리와 관련이 깊고 의미 있는 명사를 찾는다.
찾아낸 명사를 “개체”와 개체가 가진 고유한 특성인 “속성”으로 정확히 분류한다.

관계 추출

개체와 속성을 추출한 이후에는 개체 간 관계를 결정할 수 있다. 관계란 개체 간의 의미 있는 연관성으로 주로 동사로 표현된다.

제시된 요구사항의 문장들에서 동사를 찾는다.
개체 간의 연관성을 의미 있게 표현한 동사를 찾는다.

관계를 추출한 후에는, 추출한 관계에 대한 매핑 카디널리티와 참여 특성을 결정한다. 이때, 매핑 카디널리티란 각 개체 인스턴스가 관계를 맺는 상대 개체의 개체 인스턴스 개수를 말한다. 매핑 카디널리티를 기준으로 추출한 관계가 일대일(1:1), 일대다(1:N), 다대다(N:M) 중 하나로 분류한다. 그리고 개체가 관계에 필수적으로 참여하는지, 선택적으로 참여하는지를 의미하는 참여 특성을 결정한다.

E-R 다이어그램 작성

데이터베이스에 대한 요구사항 명세서에서 개체, 속성, 관계를 모두 추출하고 나면, 이를 하나의 E-R 다이어그램으로 표현한다. E-R 다이어그램은 데이터베이스에 대한 요구사항 명세서를 개념적으로 모델링하여 표현한 것이다.

논리적 설계 (Logical Design)

논리적 설계에서는 DBMS에 적합한 논리적 데이터 모델을 이용하여, 개념적 스키마를 기반으로 논리적 스키마를 설계한다. DBMS에 독립적인 개념적 스키마를 기반으로 DBMS가 처리 가능한 데이터베이스의 논리적 구조를 설계하는 단계이다. 논리적 설계 단계에서는 주로 관계 데이터 모델을 사용하며, E-R 다이어그램을 관계 데이터 모델의 릴레이션 스키마로 변환한다. 이러한 작업을 논리적 모델링이라고 하며, 생성되는 릴레이션 스키마를 논리적 스키마라고 한다.

E-R 모델에서는 개체와 관계를 구분하지만, 관계 데이터 모델에서는 개체와 관계를 구분하지 않고 릴레이션으로 표현한다. 또한 E-R 모델에서는 다중 값 속성이나 복합 속성의 표현을 허용하나, 관계 데이터 모델에서는 허용하지 않는다. 이로 인하여 E-R 다이어그램을 관계 데이터 모델의 릴레이션 스키마로 변환하는 과정에서 고려해야 할 사안이 많다.

또한 변환된 릴레이션 스키마에 대해 속성의 데이터 타입, 길이, Null 값 허용 어부, 기본값, 제약조건 등도 논리적 설계 단계에서 결정된다. 릴레이션 스키마에 대한 세부 사항들이 결정되면 결정된 내용을 문서화하는 것이 권장된다.

릴레이션 스키마 변환 규칙

E-R 다이어그램을 관계 데이터 모델의 릴레이션 스키마로 변환할 때, 다섯 가지 규칙을 순서대로 적용하면 쉽게 변환할 수 있다. 변환 규칙을 순서대로 적용하면서 해당되지 않는 규칙은 제외하고 넘어가면서 변환 작업을 수행한다. E-R 다이어그램을 릴레이션 스키마로 변환할 때 적용되는 다섯 가지 규칙은 다음과 같다.

규칙 1: 모든 개체는 릴레이션으로 변환한다.

E-R 다이어그램의 각 개체를 하나의 릴레이션으로 변환한다. 이때, 개체의 이름은 릴레이션의 이름으로 변환하고 개체가 가진 속성도 릴레이션의 속성으로 그대로 변환하면 된다. 만약 개체가 가진 속성이 복합 속성이면 복합 속성을 구성하는 단순 속성만 릴레이션의 속성으로 변환한다. 개체의 키 속성은 릴레이션의 기본키로 변환한다.

규칙 2: 다대다(N:M) 관계는 릴레이션으로 변환한다.

E-R 다이어그램에 있는 다대다(N:M) 관계를 하나의 릴레이션으로 변환한다. 관계의 이름은 릴레이션의 이름으로, 관계의 속성도 릴레이션의 속성으로 그대로 변환한다.

다만, 관계를 맺고 있는 개체들을 먼저 규칙 1에 따라 변환하고 릴레이션들의 기본키를 관계 릴레이션에 포함시키고 외래키로 저장한다. 개체를 변환한 릴레이션의 기본키를 외래키로 지정할 때, 가져온 기본키들의 이름이 같은 경우에는 하나의 이름을 변경해야 한다.

규칙 3: 일대다(1:N) 관계는 외래키로 표현한다.

E-R 다이어그램에 있는 일대다(1:N) 관계는 릴레이션으로 변환하지 않고 외래키로만 표현한다. 약한 개체가 참여하는 일대다(1:N) 관계도 릴레이션으로 변환하지 않고 외래키로만 표현한다. 약한 개체가 참여하는 일대다(1:N) 관계에서는 외래키가 포함된 릴레이션에서 외래키를 포함하여 기본키를 지정해야 한다. 약한 개체는 강한 개체에 따라 존재 여부가 결정되기에 강한 개체의 기본키를 이용하여 식별한다.

규칙 4: 일대일(1:1) 관계도 외래키로 표현한다.

E-R 다이어그램에 있는 일대일(1:1) 관계도 릴레이션으로 변환하지 않고 외래키로만 표현한다. 데이터의 중복을 피하기 위해서 다음 세부 규칙이 정의된다.

일반적인 일대일 관계는 외래키를 주고 받는다.
일대일 관계에 필수적으로 참여하는 개체의 릴레이션만 외래키를 받는다.
모든 개체가 일대일 관계에 필수적으로 참여하면 하나의 릴레이션으로 합친다.

규칙 5: 다중 값 속성은 릴레이션으로 변환한다.

관계 데이터 모델의 릴레이션에서는 다중 값을 가지는 속성을 허용하지 않기에, 다중 값 속성은 그 속성을 가지는 개체에 해당하는 릴레이션이 아닌 별도의 릴레이션을 만들어 포함시킨다. 이때, 새롭게 만들어진 릴레이션의 이름은 자유롭게 정하고 기본키는 다중 값 속성과 외래키를 조합하여 지정한다.

물리적 설계와 구현 (Physical Design & Implement)

논리적 설계 단계에서 릴레이션 스키마의 설계를 완료하면, 물리적 설계 단계에서는 인덱스 구조, 내부 저장 구조, 접근 경로 등 하드웨어나 운영체제의 특성을 구려한 물리적 구조를 설계한다. 그 후, DBMS를 이용하여 SQL 쿼리를 작성하고 실행시키고 데이터베이스를 실제로 생성하면 데이터베이스 개발 작업이 끝난다.

데이터베이스에서 가장 흔하게 쓰이는 예시 중 하나인 '직원(Employees)' 정보를 저장하는 테이블(릴레이션)을 생성하는 SQL문은 다음과 같다.

CREATE TABLE Employees (
    employee_id INT PRIMARY KEY,       -- 직원 고유 번호 (기본키)
    first_name VARCHAR(50) NOT NULL,    -- 이름
    last_name VARCHAR(50) NOT NULL,     -- 성
    email VARCHAR(100) UNIQUE,          -- 이메일 (중복 불가)
    hire_date DATE DEFAULT CURRENT_DATE, -- 입사일 (기본값은 오늘 날짜)
    salary DECIMAL(10, 2)               -- 급여 (총 10자리, 소수점 2자리)
);

래퍼런스(Reference)

데이터베이스 개론 3판 - 김연희

[데이터베이스] - 관계 데이터 연산 (Relational Data Operation)

shineast_ — Fri, 2 Jan 2026 17:14:00 +0900

이번 포스팅은 데이터 모델링에 관한 기본적인 이해를 전제로 합니다. 데이터 모델링에 대해 알지 못하는 경우, 따로 공부를 하거나 "이 포스팅"을 참고한 후 이번 포스팅을 읽기 바랍니다.

관계 데이터 연산의 개념

관계 데이터 연산이란 원하는 데이터를 얻기 위해 릴레이션에 필요한 처리 요구를 수행하는 것이다. 대표적인 관계 데이터 연산으로는 "관계 대수"와 "관계 해석"이 있다. 그러나 관계 대수와 관계 해석은 상용화된 관계형 데이터베이스에서는 잘 사용되지 않는 개념적 언어이다. 그럼에도 이를 이해하고 공부하는 것이 상용화된 데이터 언어를 이해하는데 도움이 된다.

관계 대수(Relational Algebra): 원하는 결과를 얻기 위해 데이터의 처리 과정을 순서대로 기술한다. (절차 언어)
관계 해석(Relational Calculus): 원하는 결과를 얻기 위해 처리를 원하는 데이터가 무엇인지만 기술한다. (비절차 언어)

관계 대수

원하는 결과를 얻기 위해 데이터의 처리 과정을 순서대로 기술하는 "관계 대수"에서는 피연산자가 릴레이션이다. 릴레이션들에 연산자를 적용하여 연산하고 그를 통해 도출한 결과 또한 릴레이션이다.

관계 대수에는 대표적인 연산자가 8개 있는데 특성에 따라 "일반 집합 연산자"와 "순수 관계 연산자"로 분류된다.

일반 집합 연산자

일반 집합 연산자들은 수학의 집합 관련 연산자들을 차용한 것으로, 릴레이션이 "튜플의 집합"임을 이용하여 연산한다. 연산자의 종류는 다음과 같다.

연산자	기호	표현	의미
합집합	$\cup$	$R \cup S$	릴레이션 R과 S의 합집합을 반환한다.
교집합	$\cap$	$R \cap S$	릴레이션 R과 S의 교집합을 반환한다.
차집합	$-$	$R - S$	릴레이션 R과 S의 차집합을 반환한다.
카티션 프로덕트	$\times$	$R \times S$	릴레이션 R의 각 튜플과 릴레이션 S의 각 튜플을 모두 연결하여 만든 새로운 튜플을 반환한다. (곱집합 반환)

이때 합집합, 교집합, 차집합은 피연산자인 2개의 릴레이션이 합병이 가능해야 한다.

두 릴레이션의 차수가 같아야 한다. (속성이 같아야 한다)
2개의 릴레이션에서 서로 대응되는 속성의 도메인이 같아야 한다.

순수 관계 연산자

순수 관계 연산자는 릴레이션의 구조와 특성을 이용하는 연산자로, 릴레이션에 저장된 데이터를 다양하게 처리하는데 자주 사용한다. 연산자의 종류는 다음과 같다.

연산자	기호	표현	의미
셀렉트	$\sigma$	$\sigma_{조건}(R)$	릴레이션 R에서 조건을 만족하는 튜플들을 반환한다.
프로젝트	$\pi$	$\pi_{속성리스트}(R)$	릴레이션 R에서 주어진 속성들의 값으로만 구성된 튜플들을 반환한다.
조인	$\bowtie$	$R \bowtie S$	공통 속성을 이용해 릴레이션 R과 S의 튜플들을 연결하여 만든 새로운 튜플들을 반환한다.
디비전	$\div$	$R \div S$	릴레이션 S의 모든 튜플과 관련이 있는 릴레이션 R의 튜플들을 반환한다.

관계 해석

관계 해석은 원하는 결과를 얻기 위해 처리를 원하는 데이터가 무엇인지만 기술하는 비절차 언어이다. 데이터를 처리하는 기능과 처리를 요구하는 표현력에서 관계 대수와 관계 해석은 동일하다. 관계 해석의 특징은 다음과 같다.

수학의 프레디킷 해석에 기반을 둔다.
튜플 관계 해석과 도메인 관계 해석으로 분류한다.

래퍼런스 (Reference)

데이터베이스 개론 (3판) - 김연희

[회고] - 2025년 돌아보기 (Retrospective of 2025)

shineast_ — Tue, 30 Dec 2025 19:33:02 +0900

개발자라면 매년 이맘때 쯤, 회고록을 작성하는데 2023년, 2024년 모두 회고록을 작성하며 내 삶을 돌아보는 시간이 너무나도 유익했다. 2025년도 지난 번과 마찬가지로 동일하게 이번에도 "신앙", "개발", "블로그", "일상", "목표" 5가지 카테고리로 나누어 회고록을 작성해보도록 하겠다.

1. 신앙 (Faith)

올해는 청년부 회장

작년 이맘때, “이제는 청년부 임원을 그만하고 싶다” 라는 생각이 많이 들었다. 그런데 올해 청년부로 회장으로 뽑혀버렸다… 권위는 하나님께서 세우신다는 걸 믿기에 순종했고, 이왕 회장으로 세워진 거 하나님 앞에서 최선을 다해보자고 마음을 먹었다. 그렇게 청년부의 많은 일정들을 직접 맡아서 기획하고 진행하게 되었는데, 정말 쉽지 않았던 것 같다. 부회장일 때랑은 비교도 안 될 정도로 스트레스를 많이 받았다. 그럼에도 불구하고 매주 임원기도회를 통해 기도를 놓치지 않으려고 애썼고, 어느덧 시간이 흘러 12월이 되었고 결국 임기를 잘 마칠 수 있었다.

여러 에피소드들이 있지만, 단언컨대 청년부 여름수련회를 준비하면서가 제일 힘들었던 시간이었던 것 같다. 청년부 내의 무질서함을 많이 보았고 그로 인해 상처받는 일들도 꽤 있었다. 그 과정 속에서 하나님께서 내게 주신 말씀이 하나 있다.

너는 힘써 대장부가 되고 네 하나님 여호와의 명령을 지켜 그 길로 행하여 그 법률과 계명과 율례와 증거를 모세의 율법에 기록된 대로 지키라 그리하면 네가 무엇을 하든지 어디로 가든지 형통할지라 (왕하 2:2B~3)

개인적으로 나는 우리 청년부원들이 꽤 성숙한 편이고, 영성도 전반적으로 높다고 생각한다. 하지만 동시에 각자마다 분명한 연약함이 있다는 것도 많이 느끼게 되었다. 결국에는 주님의 사랑으로 품어주고, 기다려주는 게 필요하구나라는 걸 배웠던 것 같다.

그리고 리더인 나는 더 강단을 가져야 한다는 것을 많이 느꼈다. 스스로도 우유부단한 모습을 많이 보았고 쉽게 휘둘리는 내 모습이 나 자신에게도 참 싫게 느껴졌다. 다윗이 솔로몬에게 유언하면서 “너는 힘써 대장부가 되라” 라고 말하는데 이 말에는 왕으로서 통치를 잘하고 하나님의 율법을 지키기 위해서는 그만큼의 강단과 중심이 필요하다는 의미가 담겨 있다고 생각한다. 나 역시 더 힘써 대장부가 되고, 굳건하고 단단한 성품을 가진 사람이 되고 싶다.

이렇게 돌아보면, 한 해 동안 정말 많은 일들이 있었다. 마음이 상하는 일도 있었고, 기쁘고 즐거운 순간들도 있었다. 그런데 결국 지나고 보니 모든 게 다 하나님의 은혜였다는 것이 참 많이 와닿는다. 한 시즌을 잘 마무리하게 하신 하나님께 감사하고, 주님께서 맡겨주신 자리를 충성되게 감당하고 내려올 수 있어서 진심으로 기쁘다…!!

말씀으로 행하는 사람

올해는 정말 성경을 많이 읽으려고 애썼던 한 해였던 것 같다. 시편과 잠언은 매달 1독을 목표로 했고, 아침, 점심, 저녁으로 나눠서 말씀을 읽었다. 아침에는 성경 1독 흐름으로, 점심에는 시편과 잠언을, 저녁에는 사복음서를 읽는 식이었다. 특별히 말씀은 항상 소리 내서 읽으려고 했고, 마음에 와닿는 구절들은 메모 앱에 적어두고 자주 보고 묵상하고 암송했다. 그렇게 말씀을 읽으면서 나아갈 때, 지식적으로 성장할 뿐 아니라, 영적으로도 많이 성장하는 것을 느꼈다. 이 시간을 통해 말씀이 점점 내 안에 쌓이면서 감정적으로 요동치는 것도 많이 줄어든 것 같다.

주의 말씀은 내 발에 등이요 내 길에 빛이니이다 (시편 119:105)

그리고 올해 가을에는 성경 한 달 1독 챌린지에 도전해봤다. 정말 시간 날 때마다 말씀을 읽었던 것 같다. 아쉽게도 한 달 안에 1독을 끝내지는 못했지만, 약 45일 정도 걸려서 1독을 완료했다. 이렇게 성경을 양적으로 많이 읽었던 것이 참 많은 유익을 주었던 것 같다. 말씀이 곧 하나님이시기에, 말씀 되신 주님과 더 깊이 동행했던 것 같다

말씀이 육신이 되어 우리 가운데 거하시매 우리가 그의 영광을 보니 아버지의 독생자의 영광이요 은혜와 진리가 충만하더라 (요한복음 1:14)

특별히 이렇게 말씀 읽기에 힘쓸 수 있었던 이유는, 하나님께서 내게 약속하신 말씀을 붙잡고 싶었기 때문이다. 말씀을 통해 생명을 주시고, 육신의 강건함도 허락하시는 하나님을 신뢰하며 소리 내어 말씀을 읽었다.

내 아들아 내 말에 주의하며 내가 말하는 것에 네 귀를 기울이라 그것을 네 눈에서 떠나게 하지 말며 네 마음 속에 지키라 그것은 얻는 자에게 생명이 되며 그의 온 육체의 건강이 됨이니라 (잠언 4:20~22)

말씀을 이렇게 가까이하다 보니, 내 삶 자체가 조금씩 정리되기 시작했다. 불필요한 미디어를 보는 대신 하나님의 말씀을 보려고 애썼고, 말씀을 직접 보지 못할 때에는 신앙적으로 유익한 것들을 보거나 들으려고 노력했다. 그런 선택들이 내 삶을 더 거룩하고 정결한 방향으로 이끌어 주었던 것 같다.

또 하나님의 말씀을 보면서 깨닫게 된 것은 “하나님께서는 반드시 인생을 치유하신다.”는 사실이다. 예수님께서는 단 한 사람도 거절하시지 않으시고, 구하며 나아오는 모든 자에게 치유를 허락하셨다. 1년 동안 말씀을 꾸준히 읽으면서, 내 믿음 또한 함께 자라났다는 걸 느낀다. 믿음을 자라게 하는 하나님의 말씀과 앞으로도 매 순간 동행하고 싶다.

그러므로 믿음은 들음에서 나며 들음은 그리스도의 말씀으로 말미암았느니라 (로마서 10:17)

내적치유와 인카운터

올해 금요기도회에서 “내적치유와 인카운터”라는 주제로 특강이 진행되었다. 여러 소주제로 나뉘어 이어졌던 내적치유와 인카운터 특강은 나에게 매우 중요한 시간이 되었다. 어렸을 때부터 지금까지의 삶을 돌아보며, 그동안 내 안에 쌓여 있던 상처를 들춰내고 하나님 앞에서 해결받는 시간을 가졌다. 용서하지 못하던 사람들을 용서하고, 깊숙이 자리 잡고 있던 쓴뿌리를 뽑아내는 과정은 내 신앙 여정 가운데 매우 중요한 터닝포인트가 되었다.

“나는 딱히 큰 상처가 없고, 이미 자유한 상태다”라고 생각했지만, 그것은 착각이었다는 것을 많이 느꼈다. 나도 모르는 사이에 내 안에 자리 잡고 있던 쓴뿌리와 상처들이 생각보다 많았고, 그 상처들을 직면하는 과정에서 참 많이 울며 하나님 앞에 모든 것을 쏟아냈던 것 같다. 특별히 이 내적치유와 인카운터 과정을 거치며 하나님께서 내게 주셨던 말씀이 있다.

오직 너희의 심령이 새롭게 되어 하나님을 따라 의와 진리의 거룩함으로 지으심을 받은 새 사람을 입으라 (에베소서 4:23~24)

이 말씀을 주님께로부터 받았을 때, 참 많이 위로가 되었다. 내게는 육신의 연약함이 있지만, 하나님께서 심령을 새롭게 하실 때 새 사람을 입혀주신다는 약속처럼 느껴졌기 때문이다. 그리고 그 새 사람은 지식에까지 새롭게 함을 입은, 하나님의 DNA로 이루어진 새 사람이라는 확신이 들었다. 하나님께서 올해 내게 내적치유를 이루어주셨고 또한 주님께서는 내적치유에서 끝마치지 않고 외적치유로까지 이루실 것을 신뢰한다…!!

2. 개발 (Dev)

2025년 학습 목록

To be Full Stack

2025년은 프론트엔드 개발자로서 필수적으로 익혀야 할 기술 스택들을 집중적으로 학습하며, 부족했던 부분들을 많이 채웠다. Next.js, TypeScript와 TanStack Query, shadcn/ui 등 여러 라이브러리와 프레임워크를 학습했고, 실제 프로젝트에 적용하며 사용 경험을 쌓을 수 있었다.

일단은 웹 프론트엔드 개발자로서 갖춰야 할 필수적인 스택들은 모두 학습한 것 같다. 이제는 동작 원리와 함께 렌더링 방식, 상태 관리, 성능 최적화 등의 더 깊은 학습(Deep Dive)을 진행하고자 한다. 점점 실력이 성장하는게 보이는 것 같아서 기쁘다

또한 SQL, Docker, Supabase, Express.js 등 프론트엔드 뿐만 아니라 풀스택 개발자로 성장하기 위한 백엔드 기술 스택들도 함께 학습하고 있다. 개인적으로는 특정 영역에만 국한되기보다는, 전체 흐름을 이해하고 문제를 해결할 수 있는 풀스택 개발자를 지향하고 있기에, 앞으로도 더 넓은 도메인과 다양한 기술을 꾸준히 경험해 보고 싶다.

프로젝트 (Project)

2025년 1월, ChelseaFC 프로젝트의 AWS 배포를 완전히 마무리했다. AWS EC2를 활용한 백엔드 배포, AWS S3를 통한 프론트엔드 배포, Route 53을 이용한 도메인 구매, 그리고 Nginx를 통한 HTTPS 적용까지 풀스택 배포 전 과정을 직접 경험하며 실제 웹 서비스가 운영되는 전반적인 흐름을 배운 것 같다.

그리고 2025년 상반기에 Into the Math 프로젝트를 진행했다. Next.js와 MDX 기반 수학 문서 프로젝트로, Next.js의 렌더링 방식과 라우팅 방식, MDX 파싱과 i18n 국제화, 다크모드, 컴포넌트 설계 등 웹 개발에 필수적인 여러 요소들을 많이 배웠다. 그리고 Vercel을 통해 비교적 간단하게 배포를 진행하며 배포 경험도 함께 쌓을 수 있었다.

https://github.com/kangdy25/Into-the-Math

GitHub - kangdy25/Into-the-Math: 누구나 수학을 공부할 수 있는 문서(docs) 형식 웹사이트

누구나 수학을 공부할 수 있는 문서(docs) 형식 웹사이트. Contribute to kangdy25/Into-the-Math development by creating an account on GitHub.

github.com

마지막으로 2025년 하반기에는 BibleSlide 프로젝트를 진행했다. Electron과 React를 활용한 데스크톱 애플리케이션 개발로, 웹 개발과는 다소 다른 영역처럼 느껴질 수 있지만 TypeScript와 React를 중심으로 UI를 구성하며 웹 개발에서 쌓아온 경험을 충분히 활용할 수 있었다. Electron-builder를 통해 exe 파일 배포를 완료했고 자동 업데이트 기능까지 구현했다. BibleSlide는 실제 교회에서도 사용하는 프로그램으로 개인적으로도 가장 뿌듯하게 느끼는 프로젝트다.

https://github.com/kangdy25/BibleSlide

GitHub - kangdy25/BibleSlide: 성경 구절 PPT 생성기 ("Bible" Verse to PPT "Slide")

성경 구절 PPT 생성기 ("Bible" Verse to PPT "Slide") . Contribute to kangdy25/BibleSlide development by creating an account on GitHub.

github.com

어쨌거나 이 세 가지 프로젝트를 마무리하면서 포트폴리오로서 필요한 개인 프로젝트 작업은 어느 정도 끝냈다고 느낀다. 무엇보다도 책이나 문서로 학습하는 것보다, 실제 프로젝트를 직접 진행하며 부딪히는 과정에서 가장 빠른 성장이 이루어진다는 것을 많이 느꼈던 것 같다.

링크드인과 오픈소스

많은 주니어·시니어 개발자들이 공통적으로 강조하는 것은 오픈소스 기여였다. 개발자 컨퍼런스에 참석할 때마다 연사자분들은 빠짐없이 오픈소스의 가치를 이야기했다. 나 또한 오픈소스의 중요성을 알고는 있었지만 진입장벽에 대한 두려움 때문에 쉽게 시작하지 못하고 계속 미루고 있었다.

그러던 중 추석 연휴에 Toss 팀의 `frontend-fundamental` 프로젝트에서 사소한 오류를 발견했고, 이를 수정해 PR을 보냈다. PR이 바로 확인되지는 않았지만, 시간이 지난 뒤 리뷰를 거쳐 머지되었다. 작은 기여였지만 이 경험은 나에게 생각보다 큰 자신감을 주었다. 예전에 AUSGCON에서 시온님의 발표를 들었을 때 “토스 같은 대기업의 개발자들과 나 사이의 거리가 우주만큼 먼 것이 아니다.”라고 하셨는데 그 말이 이제서야 이해가 되는 것 같다.

또한 AUSGCON에서 영하님의 발표를 계기로 링크드인을 본격적으로 사용하기 시작했다. 이전까지는 사실상 방치된 계정이었지만, 글을 작성하고 여러 개발자들과 연결되면서 자연스럽게 다양한 인사이트를 접할 수 있게 되었다. 비록 자주 글을 올리지는 못하지만, 네임드 개발자님들과 1촌을 맺고 여러 인사이트를 접하다 보니 개발자로서의 시야가 넓어지고 있다는 것을 많이 느낀다.

돌이켜보면 2025년 동안 가장 잘한 선택 중 하나는 링크드인을 시작한 것과 오픈소스에 첫 기여를 한 것이다. 이 경험들은 단순한 활동을 넘어, 개발자로서 한 단계 더 성장할 수 있도록 해준 것 같다.

이력서와 포트폴리오

올해 가을, 재성님의 이력서 강의를 듣고 처음으로 제대로 된 이력서를 작성했다. 토스뱅크 서류전형 패스 채용에 지원하기 위해 준비한 것이었는데, 이력서를 작성하는 과정에서 내가 어떤 부분이 부족한지, 앞으로 무엇을 더 채워야 하는지 명확하게 알 수 있었다. 완벽하지 않아도 이력서를 써보고 지원을 막 해보라는 말이 이해가 되었다.

https://tropical-pasta-efb.notion.site/DongYoon-Kang-s-PORTFOLIO-28800d342f9680739dd8c915f07d5a76

DongYoon Kang’s PORTFOLIO | Notion

️ Introduce

tropical-pasta-efb.notion.site

비록 아직은 부족한 점이 많지만, 이력서를 작성하며 앞으로의 성장 방향을 구체적으로 그려볼 수 있었다는 점에서 의미 있는 시간이었다. 이렇게 작성한 이력서는 연합동아리 지원이나 나를 소개해야 하는 자리에서도 생각보다 유용하게 활용되고 있다. 최근 지원한 연합동아리 ‘스위프’에서도 프로필 카드를 작성할 때 큰 도움이 되었다. 앞으로 더 많은 경험과 프로젝트로 이력서의 내용을 채워가며, 자연스럽게 더 좋은 개발자로 성장해가고 싶다.

2026년 학습 예정 목록

프로젝트 고도화

2026년에는 새로운 프로젝트를 진행하기보다는, 올해 진행했던 개인 프로젝트들을 조금 더 다듬고 고도화하는 데 집중하려고 한다. BibleSlide랑 Into the Math 프로젝트를 중심으로 구조를 정리하고, 기능도 조금씩 개선하며 포트폴리오로서의 가치를 높이고 싶다.

BibleSlide의 경우, 기능 구현은 이미 마친 상태라 새로운 기능을 추가할 생각은 없다. 대신 테스트 코드를 추가하고 지금까지 작성한 코드를 100% 이해하고 설명할 수 있는 수준까지 끌어올리는 것이 목표다.

Into the Math도 마찬가지로 테스트 코드를 작성하고 Supabase를 활용하여 로그인/회원가입, 댓글 기능, 좋아요 기능 등을 추가하여 풀스택 프로젝트로 고도화하고자 한다. 현재는 Tailwind CSS로만 스타일링되어 있는데, 이를 Shadcn/ui와 함께 구성해 유지보수성과 재사용성을 높이고 싶다. 아직 확정은 아니지만, React Native를 활용해 Into the Math의 모바일 앱을 제작해보는 것도 고민 중이다.

알고리즘과 코딩테스트

올해는 알고리즘 공부를 거의 하지 못했는데, 2026년부터는 코딩테스트 대비를 포함해서 본격적으로 알고리즘 공부를 해보려고 한다. 우선은 C++로 공부할 생각이고, 인프런 강의를 활용할 예정이다.

목표는 [solved.ac] 기준 다이아몬드 달성이고, 프로그래머스 SQL 문제도 함께 꾸준히 풀어보려고 한다. 큰 욕심보다는 1일 1알고를 목표로, 매일 조금씩이라도 손을 대는 게 우선이다. 취업 과정에서 코딩테스트가 발목을 잡지 않도록, 꾸준히 실력을 쌓아가고 싶다.

정보처리기사 & SQLD

올해 정보처리기사 시험에서 필기는 비교적 수월하게 붙었는데, 실기에서 58점으로 떨어졌다. 난이도가 어려웠다기보다는, Implements를 implement라고 쓰는 것처럼 사소한 실수들이 겹친 게 컸다. 시험 결과를 확인했을 때는 좀 열받았지만, 한편으로는 CS 내용을 제대로 정리할 좋은 계기라고 생각하고 다시 제대로 준비하고자 한다.

2026년에는 정보처리기사 실기를 다시 준비하면서 운영체제, 데이터베이스, 네트워크 같은 CS 과목들을 한 번 더 제대로 복습해보려고 한다. 또한 데이터베이스 공부하는 김에 SQLD 자격증도 같이 준비할 생각이다. 이 두 개 정도만 있어도 이력서에 적을 자격증은 충분하지 않을까 싶다.

TOEIC, OPIC

다가올 2026년에는 어학도 준비하려고 한다. TOEIC은 최소 800점 이상, OPIC은 IH 등급 이상을 목표로 잡았다. 지금 영어 과외를 하고 있어서 영어를 계속 가르치는 게 꽤 도움이 되는 것 같다. 이 장점을 잘 살려서 너무 부담 갖지 말고 차근차근 준비해보려고 한다.

3. 블로그 (Blog)

어느덧 블로그의 총 방문자 수 150,000명을 달성했다. 처음 블로그를 개설했던 2022년을 떠올려 보면, 내 블로그 역시 꽤 많은 성장을 이뤄온 것 같다. 특별히 올해의 블로그 작성은 상반기와 하반기로 나누어 돌아볼 수 있을 것 같다.

상반기에는 React, 컴퓨터 네트워크, 소프트웨어 공학 등 새로운 주제의 포스팅을 많이 작성했고, 기존에 작성해 두었던 컴퓨터 구조 포스팅 업데이트도 모두 마무리했다. 반면 하반기에는 블로그 공백이 꽤 길어졌던 것 같다. 12월 즈음 BibleSlide 프로젝트 트러블슈팅 관련 포스팅 하나와 AUSGCON 컨퍼런스 후기글 하나를 작성한 것이 전부였다. 열정적으로 작성했던 상반기에 비해 하반기에는 BibleSlide 프로젝트를 비롯한 여러 개인 프로젝트와 학습에 집중하다 보니, 상대적으로 블로그 작성의 우선순위가 많이 뒤로 밀려 있었던 것 같다.

요즘은 대부분의 기록을 Notion에 남기고 있다 보니 블로그의 가치가 점점 줄어드는 것 같다… 그래도 열심히 커스텀하고 공들였던 블로그이기에 다시 마음을 다잡고 포스팅을 올려야겠다. 작년과 제작년의 회고글에도 있었던 것 같은데 쓰고 싶은 포스팅 주제는 너무나 많다.

일단 최우선적으로 목표로 하는 포스팅들은 “데이터베이스”, “운영체제”, “클라우드 컴퓨팅”, “컴퓨터 보안” 관련 주제들이다. 정보처리기사 자격증을 준비하며 다시 정리할 필요성을 느꼈고, 특히 데이터베이스는 SQLD 자격증과도 직접적으로 관련이 있기에 열심히 다시 CS 과목 관련한 포스팅을 작성해보도록 하겠다…!!

4. 일상 (Daily)

아이자야 컨퍼런스 (SOLA FIDE, BORN ZEAL)

올해 1월, 처음으로 아이자야 컨퍼런스에 참여해보았다. SOLA FIDE 컨퍼런스는 너무나 기억에 남는 컨퍼런스였다. 말씀을 전해주셨던 조성민 간사님, 최욥 선교사님의 말씀도 너무 좋았고, 아이자야 팀과 제이어스 팀의 찬양들도 너무나 기억에 남았다. 여름에 SOLA FIDE 앨범이 발매되고 유튜브에 실황 영상들이 올라왔을 때는 너무나 반가웠고 계속 반복해서 듣게 되었던 것 같다.

이후, 여름에 진행되었던 본질 컨퍼런스도 역시 기억에 많이 남는다. SOLA FIDE 때 불렀던 ‘의인의 길은’, ‘화평을 누리자’ 찬양들도 반가웠고 아이자야 팀이 번안해서 부른 ‘Jehovah’, ‘In Jesus name’ 찬양들도 너무 좋았다. 그리고 천관웅 목사님께서 전해주신 말씀도 너무나 은혜로웠다. 두 컨퍼런스 모두 내 신앙 상태를 한 단계 더 성장시켜준 터닝포인트였던 것 같다.

2025 어노인팅 예배캠프

우리 교회의 전교인 수련회가 10월로 미뤄져서, 8월에 2025 어노인팅 예배캠프에 참석할 수 있었다. 소병찬 간사님께서 인도하신 마지막 날에 참석했는데 “영광의 소망”이라는 주제로 진행된 예배캠프는 너무나 기억에 남았고 은혜 충만했던 시간이었다. 찬양을 부르며 많이 울었는데, 그때 불렀던 찬양들이 아직까지도 생생하게 기억에 남아 있다. (Born Again, 예수의 길, 승리하리라, 선을 행하면서 등)

2026년 1월에는 2025 어노인팅 예배캠프 실황 영상과 앨범이 공개된다고 하는데, 벌써부터 많이 기대된다. 정말 은혜를 가득히 받았던 집회였던 것 같다.

Dev Conference

올해는 FeConf와 AUSGCON, 이렇게 두 가지 개발자 컨퍼런스에 참석했다. 원래는 DevFest까지 참석할 계획이었는데, 개인 일정이 겹치는 바람에 표는 구매했지만 아쉽게도 참여하지는 못했다.

솔직히 말하면 FeConf는 기대에 비해 아쉬움이 조금 남았다. 티켓 가격에 비해 가져갈 수 있었던 굿즈, 참여할 수 있는 부스 이벤트가 많이 적었던 것 같다. 물론 컨퍼런스에 굿즈 얻으러 다니는 것은 아니지만 그런 이벤트들이 너무 적지 않나 싶었다. 컨퍼런스를 준비해주신 분들의 노고는 충분히 느껴졌지만, 개인적으로는 기대가 컸던 만큼 아쉬움도 컸다.

반면 AUSGCON은 정말 만족스러웠다. 참가비도 부담이 크지 않았는데, 간식이나 굿즈, 부스 이벤트까지 전반적으로 준비가 잘 되어 있었고, 무엇보다 연사자분들의 발표 내용이 굉장히 인상 깊었다. 개발자로서 많은 자극을 받았고, “나도 더 열심히 해야겠다”는 생각이 들었던 컨퍼런스였다.

어쨌든 올해 여러 컨퍼런스에 참석하면서 생각보다 많은 것들을 배우고 얻어갈 수 있었다. 내년에도 기회가 된다면 다양한 컨퍼런스에 참여하면서, 새로운 인사이트를 얻고 개발자로서 한 단계 더 성장하고 싶다.

5. 목표 (Goal)

2025년 목표 달성 여부

2025년에 설정했던 개인적인 목표는 다음과 같다. 생각보다 성공한 목표가 많아서 기쁘다. 동시에 아쉽게 달성하지 못했던 목표들도 꽤나 있어 아쉬운 점도 참 많았던 것 같다. 특히 정보처리기사 자격증 불합격이 너무나 속이 쓰렸다…

(신앙) 매 달, 시편-잠언 1독하기 (성공) ⇒ 10월까지는 6개월간 개역개정, 4개월간 NIV로 읽었고, 이후에는 1달 1독 목표로 성경을 읽었다. 100% 완벽하게 달성했다고 보기는 애매하지만, 목표의 방향이 바뀌었기에 성공으로 간주하려 한다. (아마 목표가 바뀌지 않았다면 충분히 성공했을 것 같다.)
(신앙) 공부하기 전, 반드시 말씀 최소 1장 이상 읽고 시작하기 (성공) ⇒ 말씀을 ‘읽는 것’에서 그치지 않고, 말씀대로 행하려는 습관을 만들고자 했다.
(개발) Solved.ac 플래티넘 달성 (실패)
(개발) 포트폴리오용 개인 프로젝트 1개 이상 진행하기 (성공) ⇒ 포트폴리오용 프로젝트를 2개 진행했다.
(개발) 사이드프로젝트 여러 개 진행하기 (클론코딩도 가능) (성공)
(개발) 1년 평균 학점 4.0 넘기기 (실패) ⇒ 1학기 3.6, 2학기 4.1로, 사실상 1년 평균 기준으로는 실패다
(개발) 정보처리기사 자격증 취득하기 (실패) ⇒ 필기는 합격했지만, 실기는 58점으로 아쉽게 불합격. 진짜 많이 아쉬웠다.
(운동) 손 재활 완벽하게 하기 (애매) ⇒ 일상 생활에 지장은 없으나 완벽은 아닌 것 같다…
(운동) 머슬업 연속 2개 이상하기 (실패) ⇒ 머슬업 1개까지는 다시 성공했지만, 연속 2개에는 아직 도달하지 못했다
(블로그) 블로그 포스팅 300개 달성하기 (실패)

2026년 목표 설정

2026년 목표는 2025년 목표들의 연장이 될 것 같다.다만, 커리어 측면에서 조금 더 명확한 방향성과 도전적인 목표들을 세워보고자 한다. 그럼에도 불구하고 가장 중요한 우선순위는 늘 “하나님과의 동행”이다. 말씀대로 행하며, 삶 속에서 하나님의 역사하심을 더욱 느끼고 싶다.

2026년의 개인적인 목표는 다음과 같다.

(신앙) 성경 8독 도전
(개발) 팀 프로젝트 2개 이상 진행하기
(개발) 진행했던 개인 프로젝트 고도화하기 (BibleSlide, Into the Math)
(개발) 총 300개 블로그 포스팅 작성하기
(개발) [Solved.ac] 다이아몬드 달성
(개발) 정보처리기사 실기 취득
(개발) SQLD 자격증 취득
(어학) TOEIC 800점 이상 취득
(어학) OPIC IH 등급 이상 취득

2025년은 신앙적으로도, 실력적으로도 많은 배움과 성장이 있었던 한 해였다. 그러나 동시에 부족함도 많이 느꼈고, 그만큼 나에게는 아직 더 성장할 수 있는 가능성이 남아 있다는 것을 깨닫게 된 시간이었다. 여기서 멈추지 않고, 하나님 앞에서 신앙과 인품, 그리고 실력까지 균형 있게 성장하는 육각형 크리스천으로 살아가고 싶다.

[BibleSlide] - 성경 구절을 PPT로 빠르게 생성하기

shineast_ — Mon, 29 Dec 2025 16:37:41 +0900

이전부터 너무나 감사하게도 잘 쓰고 있던 성경 PPT 생성 프로그램인 Bible2PPT 프로그램이 어느 순간 작동하지 않기 시작했습니다 ㅠㅠ 그래서 이참에 제가 직접 성경 PPT 생성 프로그램을 제작해야겠다고 생각했고, 올해 프로그램을 완성하여 배포하게 되었습니다!!

https://github.com/kangdy25/BibleSlide

GitHub - kangdy25/BibleSlide: 성경 구절 PPT 생성기 ("Bible" Verse to PPT "Slide")

성경 구절 PPT 생성기 ("Bible" Verse to PPT "Slide") . Contribute to kangdy25/BibleSlide development by creating an account on GitHub.

github.com

BibleSlide 소개

BibleSlide는 귀찮은 복사-붙여넣기 과정 없이, 원하는 성경 구절을 입력하기만 하면 즉시 파워포인트 슬라이드로 변환해 주는 도구입니다.

올해 개발을 완료하여 현재 GitHub를 통해 무료로 배포하고 있습니다.

프로그램 설치 및 사용 방법

[프로그램 설치하기]

BibleSlide는 별도의 복잡한 설치 과정 없이, 파일 하나만 내려받으면 바로 실행됩니다.

[BibleSlide GitHub 다운로드 페이지]에 접속합니다. (포스팅 상단의 링크와 동일합니다.)
화면 우측의 'Releases' 메뉴에서 가장 최신 버전을 클릭합니다.
파일 목록 중 bibleslide-setup-1.2.4.exe (또는 압축 파일)를 클릭하여 내 컴퓨터에 저장합니다. (버전은 점차 업그레이드 될 수 있습니다. 따라서 setup 뒤에 붙은 숫자는 달라질 수 있습니다.)
내려받은 파일을 실행합니다. (처음 실행 시 보안 경고 창이 뜨면 '추가 정보'를 누른 뒤 '실행'을 눌러주세요.)

프로그램을 설치한 이후, 폰트 다운로드 과정이 필요합니다. BibleSlide는 폰트 커스터마이징 기능을 제공하기 위해 다음 폰트(나눔바른고딕, 나눔명조, 나눔손글씨 펜, KoPub 돋움체, KoPub 바탕체, Pretendard)들을 사용합니다. 아래의 문서에서 폰트를 다운로드할 수 있는 링크를 제공하니 필요한 폰트들을 먼저 다운로드 받아주세요~

https://github.com/kangdy25/BibleSlide

GitHub - kangdy25/BibleSlide: 성경 구절 PPT 생성기 ("Bible" Verse to PPT "Slide")

성경 구절 PPT 생성기 ("Bible" Verse to PPT "Slide") . Contribute to kangdy25/BibleSlide development by creating an account on GitHub.

github.com

[성경 구절 입력하고 생성하기]

프로그램 상단의 입력창에 원하는 성경 구절을 입력합니다. (예: 창1:1, 요3:16-17)
글꼴, 자간, 행간, 정렬 방식들을 자신이 원하는 방식으로 설정합니다. (설정하지 않으면 기본 값으로 적용됩니다.)
PPT 제작하기 버튼을 눌러 PPT를 생성합니다.
파일 탐색기의 다운로드 폴더에서 생성한 PPT 구절을 확인할 수 있습니다.
완성된 파일을 열어 최종 확인만 하면 예배 준비 끝입니다~!!

프로그램 기능

BibleSlide의 특징들은 다음과 같습니다.

첫째로, 성경 구절을 찾는 방법이 매우 간편합니다. 복잡한 메뉴를 일일이 누를 필요 없이, 우리가 평소에 쓰는 방식 그대로 "창1:1"이나 "요3:16-17"처럼 성경 이름과 장·절 번호를 입력하기만 하면 됩니다. 익숙한 방식으로 검색할 수 있어 컴퓨터가 서툰 분들도 헤매지 않고 원하는 구절을 바로 찾아낼 수 있습니다.

둘째로, 제작 속도가 무척 빠릅니다. 본문이 길거나 찾아야 할 구절이 많으면 예전에는 한참 동안 컴퓨터 앞에 앉아 있어야 했지요. 하지만 이 프로그램을 사용하면 구절이 몇 개이든지 상관 없이 단 몇 초 만에 파워포인트 슬라이드로 뚝딱 만들어냅니다. 예배 준비 시간을 획기적으로 줄여주는 고마운 기능입니다. 뿐만 아니라, 인터넷이 연결되지 않은 오프라인 환경에서도 프로그램이 설치만 되어있다면 문제 없이 성경 PPT를 생성할 수 있습니다.

셋째로, 커스텀 기능을 제공합니다. 자동으로 만들어질 뿐만 아니라, 글꼴(폰트), 자간, 행간, 그리고 정렬 방식을 내 마음대로 조절할 수 있습니다. 직관적인 설정창을 통해 내가 원하는 텍스트 형태를 그대로 구현할 수 있어, 우리 교회만의 보기 편한 화면을 만들기에 안성맞춤입니다.

넷째로, 누구나 바로 사용할 수 있을 만큼 화면이 간결합니다. 사용법을 따로 공부하지 않아도 될 정도로 인터페이스를 깔끔하게 설계했습니다. 꼭 필요한 버튼들만 눈에 띄게 배치했기 때문에, 프로그램을 처음 실행해 보시는 분들도 별다른 어려움 없이 금방 익숙해지실 수 있습니다.

마지막으로, 이 프로그램은 모두에게 열려 있는 '오픈 소스' 프로젝트입니다. 제 개인의 소유로 두지 않고 소스 코드를 인터넷(GitHub)에 투명하게 공개해 두었습니다. 덕분에 전 세계 누구나 자유롭게 프로그램을 사용할 수 있으며, 실력 있는 다른 개발자들이 힘을 보태어 함께 프로그램을 개선해 나갈 수도 있습니다. 모두가 함께 가꾸어가는 도구라는 점에서 더욱 의미가 깊습니다.

직접 만든 이 프로그램이 매주 예배를 준비하며 헌신하시는 많은 분께 작게나마 도움이 되었으면 좋겠습니다. 프로그램을 사용하시다가 궁금한 점이 생기거나, 혹은 "이런 기능이 더 있으면 좋겠다" 하는 의견이 있으시면 언제든 댓글이나 GitHub issue를 통해 남겨주세요. 여러분의 소중한 의견을 바탕으로 조금씩 더 발전시켜 나가겠습니다. 모두 주님 안에서 평안한 하루 보내시고, 성경 PPT 만드시는 시간이 조금 더 즐겁고 가벼워지시길 소망합니다~

[AUSGCON] - 2025 AUSGCON 참여 후기

shineast_ — Sat, 13 Dec 2025 21:11:16 +0900

매우매우 뒤늦은 AUSGCON 참여 후기이다... 9월 13일날 갔는데 후기 작성은 12월... ㅋㅋ 자 어쨌거나 시작!!

개발자를 준비하는 학생으로서 "성장"에 대해 많이 고민해보고 답을 찾아가는 시간이었던 것 같다. 짧은 시간이었지만, 정말 많은 영감을 얻을 수 있었어서 너무 감사한 시간이었다 ㅎㅎ

최근 AI가 등장하고 매우 빠른 속도로 발전하면서 꽤나 조급한 마음이 많이 들었던 것 같다. 얼어붙은 채용시장, 점점 AI에 의해 대체되어 가는 신입 개발자, 여전히 갈 길이 먼 내 실력...^^ 이러한 상황 속에서 성장에 대해서 갈급함을 느꼈고, 다른 사람들은 어떻게 성장하는지가 많이 궁금했었다. 총 다섯 가지의 세션을 들었는데, 정말 모든 세션이 저에게 피가 되고 살이 되는 조언과 격려들로 가득했던 것 같다!!

내가 할 수 있었던 "시온식 사고"

시온식 사고는 오픈소스 문화와 개발자 커뮤니티 활동을 통해 형성된 성장형 마인드셋이다.

'오픈소스 경험': "나도 할 수 있겠는데?"라는 자신감과 깨달음이다.
'커뮤니티 활동': 발표 등을 통해 능동적으로 기여하고 성장하는 활동이다.

오픈소스, 개발 업계 최전선으로 가는 문

오픈소스 문화는 개발 업계 최전선에 대한 높은 접근성을 제공한다. 빅테크 개발자와 나의 거리가 멀지 않다는 것을 깨닫는다.

글로벌 협업 및 기술 습득: 전 세계 개발자와 협업하며 최신 기술을 빠르게 배운다.
기술 접근: 누구나 최신 기술과 도구에 무료로 접근 가능하다.
선도 기업 기술 체험: 선도 기업 기술을 직접 체험하고 기여할 수 있는 기회다.

오픈소스 문화의 특징

오픈소스 생태계는 특별한 문화적 특성을 지닌다.

특징	설명
진입 장벽이 낮다	누구나 쉽게 시작할 수 있다.
협업 및 공유	지식과 코드를 공유하며 함께 성장하는 것이 핵심이다.
열정과 의지 중시	형식적인 스펙보다 열정과 의지가 중요하게 평가된다.
글로벌 소통	전 세계 개발자와 소통하며 시야를 넓힌다.
실전 경험	실제 프로젝트 기여로 값진 실전 경험을 쌓는다.
빠른 피드백	기여에 대한 빠른 피드백으로 학습 속도가 높다.

오픈소스 생태계 규모 (참고)

GitHub 회원 수: 1억 명 이상
GitHub 조직 수: 4백만 개 이상

시온식 사고 실천 방법

성장 마인드셋을 실제로 구현하는 구체적인 방법들이다.

작은 기여로 시작: 오타 수정, 작은 버그 수정 등 부담 없이 시작한다.
개발자 커뮤니티 참여: 온라인/오프라인 커뮤니티에 적극 참여한다.
커뮤니티와 소통: 질문하고 답변하는 과정을 통해 지식을 확장한다.
컨퍼런스 발표 도전: 경험과 지식을 공유하며 리더십을 키운다.

첫 번째, 시온님의 "시온식 사고" 세션에서는 오픈소스와 개발자 커뮤니티의 중요성에 대해 많이 말씀해 주셨다. 특히, "오픈소스 문화는 개발업계 최전선에 대한 높은 접근성을 가진다"는 말씀과 "빅테크 개발자와 나와의 거리가 우주만큼 멀지 않다"는 말씀이 참 와닿았다. 오픈소스 활동이 나와는 우주만큼 동떨어진 분야가 아니라 얼마든지 저도 시작할 수 있다는, "나도 할 수 있겠는데?"라는 깨달음을 주는 세션이었던 것 같다.

Serverless와 Vibe Coding: 스타트업의 최전선에서 기술로 성장하기

왜 스타트업을 선택하는가?

연봉도 낮고 불안정하며 복지도 별로인 스타트업을 왜 다닐까?

이에 대한 대답은 바로 "성장 가능성"이다. (물론 스톡옵션, 분명한 동기, 낭만 등도 부가적인 이유가 된다.) 하지만 스타트업 개발자는 다음과 같은 근본적인 고민에 직면한다.

스타트업은 불안정하고 열악하다. 회사가 내일 터지면 나는 무엇을 가져갈 수 있는가?

따라서 스타트업이 개발자에게 제공해야 할 가장 확실한 보상은 "성장" 그 자체여야 합니다.

`기술적 성장`: "내가 주도하는" 다양한 문제 해결 경험, 혁신 기술 도입 기회, 오픈소스 기여, 그리고 워라밸을 통한 충분한 기술 공부 시간 확보 등이 포함된다.
`기타 스킬`: 소프트 스킬, 브랜딩, 마케팅, 디자인 등 프로덕트 전반에 필요한 역량을 함께 키울 수 있다.

성장의 딜레마, 붉은 여왕 효과 (Red Queen Effect)

"이상한 나라의 앨리스"의 붉은 여왕 효과는 성장에 대한 경각심을 일깨운다.

정의: 내가 열심히 성장해도, 다른 사람도 똑같이 열심히 성장한다.
결과: 즉, 결과적 비교우위는 크게 차이가 없다.

단순히 남들만큼 열심히 하는 것으로는 부족하다. 성장할 수 있는 시간적 여유는 다른 사람과 비슷하다는 현실에서, 플러스 알파가 필요하다.

남들과 다른 방향으로, 또는 더 효율적으로 성장한다.
남들과 다른 분야로 진출한다.

결론은 명확하다. 단순한 경험 이상의 나만의 "플러스 알파"를 확보해야 한다.

나만의 알파: 프로덕트 엔지니어로 성장하기

이 '플러스 알파'를 만들기 위한 핵심 역할 중 하나가 바로 "프로덕트 엔지니어(Product Engineer)"이다.

프로덕트 엔지니어: 제품 관리자와 엔지니어의 역할을 결합한 직무로, 제품 기획부터 설계, 개발, 출시, 운영까지 전 과정을 주도하고 책임지는 역할을 한다.

효율적으로 프로덕트 엔지니어로 성장하는 가장 좋은 방법은 "직접 내 서비스 만들어보기"이다.

Serverless와 Vibe Coding의 시너지

내 서비스를 구축하고 프로덕트 엔지니어로 성장하는 데 `Serverless`는 강력한 도구이다. Serverless는 인프라 관리 없이 애플리케이션을 구축하고 실행하는 방식이다. Zero Scale이 가능하다. 이는 온프레미스, EC2와 달리 잘게 쪼개진 서비스들의 집합으로 구성된다. Serverless의 장점은 다음과 같다.

가볍고 빠르고 효율적이기에 최소한의 비용으로 다양한 프로덕트 실험이 가능하다.
고가용성, 장애 내구성을 아키텍처 차원에서 확보하기 용이하다.
AI + Vibe Coding 환경에 매우 유리하다.

AI 기술 발전은 Serverless 환경을 더욱 활성화시킬 것이므로, 이에 대한 이해도를 높여야 한다.

Serverless는 언어 의존성이 없다.
MSA (Microservices Architecture)를 작은 단위로 구성하는 데 유리하다.

Vibe Coding 팁: AI와의 협업이 활발해지는 만큼, 재사용 가능한 코드와 주석을 잘 작성한 코드를 쓰는 것이 중요해진다.

연차가 쌓일수록, 내가 저 사람들과 다른 점은 무엇일까? 끊임없이 자문하며 나만의 경쟁력을 구축해야 하며, 성장형 스타트업에서 Serverless와 프로덕트 엔지니어링 역량을 결합하여 나만의 '플러스 알파'를 만들어야 한다.

상운님의 세션에서는 서버리스와 바이브코딩, 스타트업에 대해 이야기를 해 주셨는데, 공교롭게도 제가 가장 관심 있어 하는 주제들이었습니다. 말씀해 주신 붉은 여왕 효과도 참 많이 와닿았습니다. 결과적 비교우위는 크게 차이가 없다는 것, 결국 남들과의 차별점을 가지고 플러스 알파를 가져야 한다는 말씀들이 좋았습니다. 리얼타임 바이브코딩 채팅 구현을 체험해 보는 것은 다른 컨퍼런스 세션에서 보지 못했던 색다르고 재미있는 시간이었습니다.

자기 이해가 선행되는 진정한 성장 가속화 방법론

진정한 목표 세우기: Start with WHY

Start with WHY: 5WHY 기법을 활용하여 구체적이고 설득력 있는 목표를 설정해야 한다.

단순히 '무엇(What)'을 할지가 아니라, '왜(Why)' 그 목표를 이루어야 하는지 명확히 해야 끝까지 달릴 수 있다.

목표 설정 프로세스

준비 단계: (자신을 돌아보고 현재 상태를 점검한다.
스토리 공유: Peaks and Valleys (인생이나 경험에서 겪는 성공과 실패, 기쁨과 슬픔, 좋은 시절과 힘든 시절 등 고점과 저점을 번갈아 겪는 상태)를 공유하며 자신의 경험을 되돌아본다.
테마 찾기: 공유한 이야기들 속에서 공통점과 핵심 가치를 찾는다.
Why 문장 작성: "~하기 위해서 ~하도록"이라는 형태의 문장으로 자신의 진정한 목표를 작성한다.

이 "Why" → "HOW" → "What"의 흐름을 통해 남들과의 비교를 멈추고 자신에게 집중할 수 있다. 계속 질문하는 방법을 통해 목표를 더욱 견고히 한다.

성장 가속화: 습관화와 쉬운 시작

성장을 가속화하려면 목표 달성 과정을 습관화하고, 시작을 쉽게 만들어야 한다.

레고 방법론: 큰 목표를 작은 블록으로 쪼개서 시작한다. 작은 블록이 모여 람보르기니를 완성하듯이, 목표를 컴포넌트화하여 부담 없이 시작하고 성취감을 쌓는다.

구체적인 성장 습관화 방법은 다음과 같다.

관심 분야 공부하기: 흥미를 잃지 않고 꾸준히 지식을 쌓는다.
오픈소스 생태계 탐색하기: 적극적으로 오픈소스 환경을 살펴본다.
초보자 친화적 환경 찾기: 처음 시작하는 사람도 쉽게 기여할 수 있는 프로젝트를 찾는다.
오픈소스 문화 학습하기: 단순히 코딩을 넘어, 커뮤니티의 문화를 이해하고 참여한다.

나에 대해 이해하기: 메타인지가 잘 되어 있더라도, 루틴(습관화)을 지속하는 것이 성장의 핵심이다.

인정하고 실행하기: 용기 방법론

삶 속에서 루틴을 실패했을 때, 자신을 자책하거나 그 루틴으로 되돌아가려고 과도한 노력을 쏟기보다는, 실패를 인정하고 다시 실행하는 유연함이 필요하다.

용기 방법론: 쫄지 말고 나 자신을 드러내야 한다. 온라인을 적극 활용하여 활동을 시작한다. 틀린 정보라도 괜찮다. 그렇게 활동하다 보면 분야의 선배들과 자연스럽게 연결될 수 있다.

커닝햄 법칙 (Cunningham's Law): "인터넷에서 올바른 답변을 얻는 가장 좋은 방법은 질문을 하는 것이 아니라 잘못된 답변을 게시하는 것"이다.

이 법칙처럼, 두려워하지 않고 자신의 의견이나 지식을 드러내는 용기가 성장의 문을 열어준다.

영하님의 성장 가속화 세션에서 시작하자마자 하셨던 "링크드인 하시나요?"라는 질문은 오늘 링크드인에 첫 글을 쓰게 되는 가장 큰 계기가 되었습니다. 5WHY에 대한 내용은 예전에 교회에서 배웠던 디자인씽킹 방식인데 이 세션에서 다시 보게 되어 반가웠습니다. 그리고 오픈소스에 대한 말씀들을 해 주셨는데, 앞서 들었던 시온님의 세션과 연결되어 더 구체적으로 제가 어떻게 오픈소스 생태계를 탐방하고 접근할 수 있는지 알게 되어 너무나 좋았습니다.

테스트로 나 혼자만 레벨업?

테스트가 가지는 의미와 도구의 탄생

도구는 문제가 발생하고 해결책을 내는 과정에서 탄생했다. 테스트 역시 마찬가지다.

테스트는 데이터를 모으고 미래를 미리 예측하여 불안함을 완화한다.
이를 통해 확률이 100%가 되는 것은 아니다. 그럼에도 100%에 수렴하게 만드는 과정에 의미가 있다.

테스트와 피드백을 반복하는 "피드백 순환 고리(Feedback Loop)"를 통해 "버그 방지"와 "비즈니스 요구사항 만족"에 대한 확률을 높인다. 그리고 테스트 코드를 작성하여 테스트를 자동화한다. 이는 개발에 다음과 같은 긍정적인 영향을 준다.

회귀 버그 방지: 코드 수정 시 기존 기능이 망가지는 버그를 방지한다. 기능 추가나 리팩토링 시에도 안정감을 준다.
코드 품질 향상: 단일 책임 원칙(SPR), 낮은 결합도, 예측 가능한 구조를 고민하게 한다.

핵심 테스트 방법론의 이해

TDD, BDD, ATDD는 서로 상호 보완적이며, 각각을 살펴보고 그 본질을 이해하는 것이 중요하다.

1. TDD (Test-Driven Development)

TDD: 테스트를 먼저 작성하고 테스트를 통과하는 최소한의 코드를 작성한 후 리팩토링하는 개발 방식이다.

TDD는 짧고 반복적인 Feedback Loop를 따른다. 이는 점진적으로 안전한 설계를 만드는 데 도움을 준다. 다만, 테스트 작성을 강제화하는 것이 포인트가 아니다. 테스트라는 검증된 방식을 통해 설계와 코드 품질을 의식적이고 점진적으로 개선하는 것에 의미가 있다.

2. BDD (Behavior-Driven Development)

BDD: 모든 프로젝트 구성원이 소프트웨어의 행동에 대한 공통된 이해를 바탕으로 협업하는 방식이다.

기술적인 테스트뿐만 아니라 사용자의 시나리오와 행동에 집중한다. 이는 코드 검증뿐 아니라 비즈니스 가치 검증에 시선을 돌린다. 이는 사용자 관점으로 소프트웨어를 바라보기 때문이다. 시나리오 작성에는 팀에서 익숙한 용어를 사용한다. (Given, When, Then 구조를 사용한다.)

AS-IS: 이 코드는 기술적으로 잘 동작하는가?
TO-BE: 이 기능은 사용자가 원하는 대로 동작하는가?

모두가 이해하는 공통의 언어를 사용하기에 구조적으로 커뮤니케이션 비용이 절약된다. 성공적인 커뮤니케이션은 서로의 이해 수준이 일치하는 것이다.

3. ATDD (Acceptance Test-Driven Development)

ATDD: 소프트웨어가 “완성되었음”을 판단하는 인수 기준을 미리 합의하고, 이를 기준으로 먼저 인수 테스트 코드를 작성하고 개발한다.

인수 기준은 사용자/비즈니스 요구를 기반으로 정의된다. 일반적으로 API 레벨에서 애플리케이션을 블랙박스로 보고 테스트한다. 통합 테스트와 비슷한 구조를 가진다. 개발자와 비즈니스 담당자의 간격을 최소화하고 사용자/비즈니스 관점의 테스트를 진행한다.

테스트 방법론 Summary

TDD: 테스트를 먼저 작성하고 피드백 루프를 빠르게 만들자.
BDD: 행동 중심으로 테스트를 작성해서 표현력을 높이고 공통의 언어를 활용해 의사소통을 개선하자.
ATDD: 유저 중심에서 인수 기준을 테스트로 먼저 작성하고 피드백 루프를 빠르고 정확하게 만들자.

테스트가 주는 인사이트

코드를 테스트하는 이유는 비즈니스를 위해서이다. 이 기준을 인지하는지 여부가 코더와 엔지니어를 나눈다. 회사도 나를 테스트하고, 나도 회사를 테스트한다. 내가 제어할 수 있는 Feedback Loop를 만들고, 현재 나의 기준에 맞는 목표와 작더라도 꾸준한 실행을 통해 커리어 레벨업을 한다.

'본질을 이해하고 Feedback Loop를 만들자'

제가 최근에 프로젝트를 진행하며 테스트는 어떤 방식으로 이루어지고 어떻게 공부를 해야 할까 등을 많이 고민하고 있었습니다. AUSGCON에서 들은 한수님의 "테스트" 관련 세션은 저에게 숲을 보게 해주는 것 같은 느낌이었습니다. 실제 Kotlin과 Java 코드를 통해 어떻게 테스트 코드를 작성하는지와 각 테스트 방법론(TDD, BDD, ATDD)의 본질에 대해서 알려주신 것들이 너무나 좋았습니다. 앞으로 jest와 vitest를 배우며 테스트 기법 등을 학습하려 하는데, 들었던 세션이 정말 도움이 될 것 같습니다.

더 나은 개발자/엔지니어가 되기 위한 소프트 스킬

Long Run을 위한 빙산 아래의 역량

취업이나 이직은 겉으로 보이는 성과일 뿐이다. 수면 위로 드러나지 않은 많은 역량들(하드 스킬, 소프트 스킬)이 필요하다. Long Run 하기 위해서는 겉으로 보이지 않는 빙산의 아래쪽에 신경을 써야 한다.

구분	내용
하드 스킬 (Hard Skill)	프로그래밍 언어, 자격증, 외국어 능력, 프로젝트 관리, 데이터 분석 등 직접적인 기술 능력이다.
소프트 스킬 (Soft Skill)	대인 관계, 협업, 커뮤니케이션, 리더십, 시간 관리, 건강 등 비기술적인 역량이다.

성장의 시작은 '나를 아는 것'

성장의 가장 첫 단계는 나를 먼저 아는 것이다. 즉, 나에 대해 잘 아는 능력인 "메타 인지"가 중요하다. 많은 개발자들이 테크트리를 고민한다. 스페셜리스트(한 분야의 깊은 전문가)가 될지, 제너럴리스트(여러 분야를 두루 아는 사람)가 될지 말이다.

결국 나에 대한 충분한 이해를 바탕으로 많은 시도가 필요하다. 지금 내가 잘 맞다고 생각하는 것이 아닐 수 있다. 그러한 많은 시도를 하는 것은 부담이 되고 두려울 수 있었다.

Two-Way Door Decision: 두려움 없는 시도

우리가 겪는 대부분의 선택은 위험하지 않다.

Two-Way Door Decision: 우리가 겪는 대부분의 선택에는 약간의 손해를 감수해야 할 수는 있지만, 크리티컬한 손해는 아니다.

따라서 지속적인 작은 성공과 두려움 없는 작은 실패를 경험해 보는 것이 중요하다.

기회는 준비된 사람에게 온다

기회는 준비된 사람한테 온다. 이 준비는 "내가 주도적으로 했던 것들에 대한 이력 (리더십 + 오너십)"을 통해 만들어진다. 잘 만들어진 포트폴리오를 준비하는 것도 중요한데 왜 만들었는지, 어떤 이유로 만들었는지 명확히 설명할 수 있어야 한다.

나의 이력을 표현하는 STAR 기법

나의 경험을 효과적으로 전달하기 위해 STAR 기법을 활용한다.

S (Situation): 상황을 설명한다.
T (Task): 맡았던 임무(목표)를 설명한다.
A (Action): 내가 취한 행동을 구체적으로 설명한다.
R (Result): 행동의 결과와 성과를 설명한다.

좋은 성과를 거두었다면, 기록하는 습관을 들여야 한다. 이는 나를 알리려는 노력이며, (블로그, LinkedIn 등을 통해) 기록하는 습관이 된다.

나에게 맞는 성장 방법과 선순환

지속 가능한 성장을 위해 커뮤니티 활동을 추천한다.

성장의 선순환: 학습 → 실천/적용 → 경험/기록 → 공유의 단계를 반복한다.

마지막 세션이었던 용호님의 세션은 하드 스킬뿐만 아니라 소프트 스킬에 대한 중요성을 많이 말씀해 주시는 시간이었습니다. 가천대 취업 교양 수업 때 들었던 STAR 기법 내용이 나와 많이 반가웠습니다. 그리고 나는 확실한 "제너럴리스트"이구나를 느꼈던 시간이었습니다. Long Run 하기 위해 갖춰야 할 소프트 스킬들을 메타인지를 통하여 잘 가꿔나가고 싶다는 생각이 참 많이 들었습니다.

너무나 유익한 세션들이었고, 그리고 동시에 아쉽게도 겹쳐서 듣지 못한 세션들도 참 많았습니다 AUSGCON을 통해서 또 새로운 인사이트를 받아가고 한 걸음 더 성장을 이루는 귀한 시간이 되어 너무나 감사했습니다!!

[Trouble Shooting] - BibleSlide 자동 업데이트 구현

shineast_ — Thu, 11 Dec 2025 22:55:56 +0900

BibleSlide 트러블슈팅

프로젝트 개요

사용 기술: `electron-updater`, `electron-builder`, `GitHub Releases`

BibleSlide 데스크톱 애플리케이션을 배포하면서, 사용자가 매번 웹사이트를 방문하여 수동으로 다운로드하는 번거로움을 없애고자 했습니다. 앱 실행 시 자동으로 최신 버전을 감지하고 설치를 유도하는 자동 업데이트 기능을 `electron-updater`를 이용해 구현하는 것이 이번 목표였습니다.

자동 업데이트 기본 구현 과정

1. 환경 설정 및 패키지 설치

먼저, 자동 업데이트의 핵심 패키지인 `electron-updater`를 설치했습니다. 주의할 점은 이 패키지는 런타임에 실행되어야 하므로 `package.json`의 dependencies에 포함되어야 하며 devDependencies에 있으면 안 됩니다.

2. Main Process 설정 및 업데이트 로직

`electron-updater`를 초기화하고 업데이트 확인 및 설치 이벤트를 처리하는 로직을 구성했습니다. 이때, 개인 프로젝트에서는 유료 인증서(코드서명 X)를 사용하지 않기 때문에, Windows 환경에서 자동 업데이트가 정상 작동하도록 설정했습니다.

// main/index.ts (일부)
if (process.platform === 'win32') {
  (autoUpdater as WindowsUpdater).verifyUpdateCodeSignature = false;
}

그 이후, 앱이 준비되면 업데이트 확인을 시작하되, 개발 환경에서 불필요한 네트워크 요청을 피하도록 조건을 추가했습니다.

// main/index.ts (일부)
app.whenReady().then(() => {
  createWindow();
  if (app.isPackaged) { // 빌드된 프로덕션 환경에서만 실행
    autoUpdater.checkForUpdatesAndNotify();
  }
  // ...
});

업데이트 파일 다운로드가 완료되면, 사용자에게 다이얼로그를 띄워 재시작 및 설치를 요청합니다.

autoUpdater.on('update-downloaded', (info) => {
  const dialogOpts = {
    type: 'info' as const,
    buttons: ['재시작 및 설치', '나중에'],
    title: '업데이트 알림',
    message: `새로운 버전(${info.version})이 준비되었습니다.`,
    detail: '앱을 재시작하여 업데이트를 적용하시겠습니까?',
  };

  dialog.showMessageBox(dialogOpts).then((returnValue) => {
    if (returnValue.response === 0) {
      // '재시작 및 설치' 클릭 시
      autoUpdater.quitAndInstall(false, true);
    }
  });
});

3. 수동 배포 방식 채택

저작권 및 보안상 `.gitignore`에 등록된 필수 파일(`data/bible.json`) 문제 때문에 CI/CD 통한 배포 자동화는 포기하고 로컬 빌드 후 `.exe` 및 `latest.yml` 파일만 GitHub Releases에 수동으로 배포를 진행하는 방식을 유지했습니다.

트러블슈팅: 404 Not Found (파일명 불일치)

문제 발생

새 버전(v1.2.3) 배포 후 구버전(v1.2.2) 앱 실행 시, 업데이트 확인 로그는 찍혔으나 다운로드 단계에서 멈추고 팝업이 뜨지 않았습니다.

PowerShell을 실행하고 `& "$env:LOCALAPPDATA\Programs\bibleslide\BibleSlide.exe"` 명령어를 강제 실행하여 확인한 에러 로그를 확인했습니다.

Error: Cannot download "https://.../bibleslide-Setup-1.2.3.exe", status 404

원인 분석

`electron-updater`는 서버(GitHub Releases)에 직접 접근하는 것이 아니라, `electron-builder`가 생성한 `latest.yml` 파일을 먼저 읽고 그 안에 명시된 경로를 따라 파일을 요청합니다. 현재 발생한 문제 원인은 다음과 같습니다.

latest.yml에 명시된 파일명: bibleslide-Setup-1.2.3.exe (하이픈 -)
GitHub Releases에 수동 업로드한 파일명: bibleslide.Setup.1.2.3.exe (점 .)

결국, latest.yml에 명시된 파일명과 Github Release에 수동으로 업로드한 파일명이 달라 발생한 문제였습니다.

문제 해결

먼저 GitHub Releases에서 잘못된 이름의 파일 삭제하고 로컬 빌드 결과물의 파일명을 `latest.yml`에 맞춰 정확히 bibleslide-Setup-1.2.3.exe로 수정하여 재업로드했습니다.

Found version 1.2.3
Downloading update...
Update installer has already been triggered. Quitting application.

그 이후, 정상적인 업데이트 다운로드 및 설치 유도를 확인하고, 앱 재시작 후 v1.2.3 버전으로 성공적으로 업데이트되었습니다.

[Error] - the terminal process failed to launch: starting directory (cwd)

shineast_ — Thu, 19 Jun 2025 09:37:46 +0900

해당 에러는 VSCode Terminal을 분할(Split)할 때, 생겼던 오류이다. 해결하는 방법은 다음과 같다.

모자이크 친 부분은 터미널을 분할하고자 하는 디렉터리 위치의 경로를 의미한다.

VSCode의 설정(Preferences -> Settings)에 들어가기 (단축키 Ctrl + ,)
`terminal.integrated.defaultProfile.windows`를 검색하면 기본(Default)으로 null이 들어가있을텐데, 이를 Git Bash로 변경한다. (자신이 사용하는 터미널로 변경하면 된다)

위와 같이 해도 안 되는 경우, `settings.json` 파일에 들어가서 다음의 내용을 추가하고 vscode를 재실행하면 문제가 해결된다.

{
    "terminal.integrated.defaultProfile.windows": "GitBash",
    "terminal.integrated.splitCwd": "initial"
}

[소프트웨어 공학] - 품질 (Quality)

shineast_ — Mon, 2 Jun 2025 23:14:26 +0900

고수준 소프트웨어 품질 (High-level Software Quality)

소프트웨어 개발 작업은 실행될 수 있는 소프트웨어 시스템을 최종적으로 생산한다. 소프트웨어 개발에 어떤 프로세스를 어떻게 사용하는가는 소프트웨어 시스템의 품질에 영향을 준다. 이때, 품질에 대한 일반적인 정의는 다음과 같다.

`고객 만족`: 품질에 대한 사용자 기반의 관점으로, 사용자가 원하는 만족도를 의미한다.
`요구 적합성`: 요구 사항에 대한 적합성으로, 지정된 요구사항과 디자인을 준수하는 제품이 높은 품질의 제품이다.
`제품 품질`: 제품의 일부 성분 또는 속성의 차이로 측정된다.

개발 작업과 병행하여 품질에 관한 작업이 이루어져야 한다. 품질에 관한 작업은 표준을 정하고, 품질을 보증하는 작업, 품질 표준에 맞는지 체크하는 작업들을 말한다. 이러한 작업들을 “소프트웨어 품질 보증”이라고 한다. 높은 수준의 소프트웨어 품질을 달성하기 위한 활동은 다음과 같다.

`테스트`: 품질을 보장하는 가장 일반적인 방법으로, 결함을 찾기 위해 소프트웨어를 작동하는 것이다.
`리뷰`: 제품이 변경되거나 예상치 못한 조건에서 작동하는데 필요한 품질을 갖추는지 확인한다. 비기능적 품질 요구사항을 검증하는데 적합하다.
`품질 보증`: 소프트웨어 제품이 계획된 품질 수준을 가지고 있음을 경영진 및 이해 관계자에게 보장하는 활동을 말한다.
`품질 관리`: 여러 가지 품질 관련 프로세스를 포함하는 용어로, 프로젝트 품질 목표 달성을 위해 엔지니어링 및 관리 기술을 적용하는 것이다.

품질 모델 (Quality Model)

소프트웨어 품질의 여러 측면을 나타내는 속성에는 세 가지 차원이 있다.

품질 요소(Factor): 사용자에 대한 외부 관점을 나타낸다. (Ex: 사용성, 신뢰성, 효율성 … )
품질 기준(Criteria): 개발자 측면의 내부 관점을 나타낸다. (Ex: 정확성, 일관성, 장치 효율성 … )
메트릭 차원(Metric): 품질 기준별로 측정 방법과 스케일 등을 정의하여 정확히 품질 기준을 측정 가능하게 한다.

소프트웨어의 변경 및 유지 보수 차원의 품질 속성, 환경의 변화라는 측면의 품질 속성, 소프트웨어를 사용하고 운영하면서 중요하게 생각되는 품질 속성들이 다르다. 결국, 소프트웨어 품질 모델은 소프트웨어 개발에 있어 매우 중요한 요소이다. 이때 각 품질 속성은 비기능 요구를 추출하기 위한 체크리스트로 사용될 수 있다.

품질 관리 (Quality Management)

품질 관리의 전반적인 목적은 소프트웨어 개발 프로세스를 요구대로 수행하는지 소프트웨어 시스템이 요구와 품질 표준을 만족시키는지 확인하는 것이다. 품질 관리는 소프트웨어 개발 주기의 프로세스와 병행하여 수행되는 생명주기 활동이다. 일반적인 소프트웨어 품질 관리 기능은 다음의 세 가지로 나누어진다.

`프로세스와 표준의 정의`: 소프트웨어 개발 조직을 위하여 품질 관리 프레임워크를 개발하고 정의하는데 목적을 둔다.
`품질 보증`: 특정한 소프트웨어 프로젝트를 위하여 수행되며 품질 계획과 품질 제어 활동을 포함한다.
`프로세스 개선`: 개발 뿐만 아니라 조직의 품질 보증 프로세스를 개선하는 활동을 수행한다.

품질 보증 활동은 소프트웨어 개발 조직과 별도로 이루어진다. 프로젝트의 품질 관리자는 소프트웨어 품질 보증 활동을 계획하고 관리 감독하는 책임을 진다. 또한 유지보수 작업의 일종인 형상 관리가 잘 되는지 확인한다.

프로세스와 표준 정의

소프트웨어 품질 보증을 위해서 프레임워크가 개발되는데, 프레임워크는 다음과 같은 요소들로 구성된다.

소프트웨어 개발, 품질 관리 프로세스 및 방법론의 정의
`개발 주기 동안 품질 보증 작업을 수행할 표준, 절차, 가이드라인 정의
품질 측정과 평가를 위한 품질 메트릭, 지표 정의

표준 프레임워크는 프로세스 각 단계에서 사용된 품질 보증 프로세스를 정의해야 한다. 전통적인 프로세스에서 필요한 품질 보증 활동은 다음과 같다.

`요구 분석과 설계 단계`: 요구와 설계 명세를 검토하고 통합 테스트를 위한 계획을 수립한다.
`구현 단계`: 코딩 표준을 사용하고 리뷰나 인스펙션 뿐만 아니라 정적 분석 도구를 통해 소프트웨어 품질을 보증한다.
`통합 및 시스템 테스팅 단계`: 품질 보증 조직에서 실제 통합하고 인수 테스트를 담당한다.
`운용 및 유지보수 단계`: 변경 효과 분석, 형상관리, 리엔지니어링, 리그레션 테스팅을 적용한다.

소프트웨어 품질을 측정하고 평가할 때 메트릭도 필요한데, 프로젝트의 프로세스와 프로덕트 측면을 측정하는데 사용될 메트릭을 정의한다.

품질 보증 활동

품질 보증 기능은 각 프로젝트에 대해 프레임워크를 적용하고 실현하는 작업이다. 품질 보증은 다음 두 가지 활동으로 구성된다.

`품질 계획`: 계획은 각 프로젝트 초반에 이루어지는 활동으로, 특정 프로젝트에 대한 품질 계획을 작성한다.
`품질 제어`: 품질 제어는 프로젝트 전반에 걸쳐 이루어지는 활동으로, 품질 계획의 실행을 모니터링하고 현실적으로 수정이 필요하다면 품질 계획을 수정한다.

품질 측정 (Quality Measurement)

소프트웨어 품질 속성은 객관적이고 정량적인 평가가 필요하다. 모듈의 크기를 객관적이고 정량적으로 측정하는 방법은 다음과 같다.

메모리 적재에 소모되는 바이트 크기
원시코드의 라인 수
원시코드의 문장 수
알고리즘의 시간 복잡도

같은 품질 속성에 대한 측정 방법은 여러 가지이고 결과도 다르기에 표준화할 필요가 있다. 공식적으로 표준화가 된 것은 아니지만 많은 사람들이 표준 측정 방법으로 받아들이는 것으로 “메트릭”이 있다.

품질 메트릭 (Quality Metrics)

메트릭은 요구 메트릭(R), 설계 메트릭(D), 코드 메트릭(C), 시스템 메트릭(S)으로 분류한다. 이를 통해 요구 명세, 설계, 코드, 시스템의 품질 측면을 측정한다.

요구 메트릭

소프트웨어 개발 프로젝트에서 요구사항의 품질, 완전성, 추적 가능성, 변경 가능성 등을 정량적으로 평가하기 위해 사용하는 지표이다. 즉, 요구사항이 얼마나 잘 정의되고 관리되고 있는지를 수치로 측정하는 도구이다.

설계 메트릭

소프트웨어의 설계 단계에서 산출된 아키텍처, 모듈, 클래스, 인터페이스 등의 품질을 정량적으로 평가하기 위한 지표이다. 설계 메트릭은 향후 유지보수성, 확장성, 재사용성, 복잡성 등에 직접적인 영향을 주기 때문에 매우 중요하다.

구현 및 시스템 메트릭

소프트웨어가 개발되고 운영되는 과정에서의 품질, 성능, 복잡성, 유지보수성 등을 정량적으로 측정한다.

프로세스 개선 (Process Improvement)

소프트웨어 품질 저하는 소프트웨어 개발 경험 부족으로부터 비롯되는 경우가 많다. 엔지니어링 프로세스가 경험에 따라 어떤 차이가 있는지 연구하고 모델을 제시하는 많은 노력이 있어왔는데, 그 중 CMMI와 ISO SPICE가 많이 알려져있다.

CMMI (Capability Maturity Model Integration)

CMMI는 현재의 프로세스 상태를 벤치마킹하고 어떤 부분을 향상시킬 것인지에 대한 전략을 선택하여 프로세스를 개선하려는 소프트웨어 개발 조직에 도움이 되기 위하여 제정되었다. CMMI는 미래의 고객이 소프트웨어 공급업자가 어떤 점이 강하고 부족한지를 발견하기 위한 평가하는 기준으로도 사용되고, 소프트웨어 개발자 스스로 프로세스 능력을 평가하고 개선의 방향을 설정하기 위해서도 사용된다.

CMMI는 단계적인 모델을 기초로 하는데, 레벨에 따른 특징은 다음과 같다.

`Level 1 - 초보 단계(Initial)`: 소프트웨어 개발 과정이 임시방편이며 무질서한 상태이다. 프로젝트의 성공은 개인 역량과 영웅적 노력에 의존하며 일정 지연, 품질 문제, 예측 불가능성이 많다.
`Level 2 - 관리 단계(Managed)`: 기본적인 프로젝트 관리 프로세스가 확립되어 비용, 일정, 기능에 대한 예측과 추적이 가능한 수준이다.
`Level 3 - 정의 단계(Defined)`: 관리와 엔지니어링을 위한 소프트웨어 프로세스가 잘 문서화되어 규격으로 만들어져있다. 조직 내 모든 프로젝트가 표준 프로세스를 참고하여 일관되게 수행된다.
`Level 4 - 계량적 관리 단계(Quantified Managed)`: 소프트웨어 프로세스와 프로덕트의 품질에 대한 자세한 측정이 이루어진다. 소프트웨어 프로세스와 프로덕트가 정량적으로 이해되고 통제된다.
`Level 5 - 최적화 단계(Optimizing)`: 프로세스에 대한 정량적인 피드백과 획기적인 아이디어와 기술로 지속적으로 프로세스를 향상시킨다. 프로젝트 프로세스의 생산성 향상을 위해 래거시 기술과 방법론은 적절하게 퇴출시킨다.

ISO SPICE

ISO SPICE는 국제표준협회(ISO)에서 SPICE(Software Process Improvement and Capability dEtermination)라는 이름으로 제정한 소프트웨어 프로세스 평가를 위한 국제 표준이다. SPICE는 각 프로세스 영역마다 능력에 대한 평가를 별도로 하는 이차원적 구조를 가진다.

ISO SPICE 또한 소프트웨어 개발이나 시스템 개발 조직의 프로세스 역량을 평가하고 개선하는 것을 목표로 제정되었다. SPICE는 특별히 다음 세 가지 목적을 위해 제정되었다.

개발 기관이 프로세스 개선을 위하여 스스로 평가한다.
기관에서 정한 요구조건을 만족하는지 개발 조직이 스스로 평가한다.
계약을 맺기 위해 수탁 기관의 프로세스를 평가한다.

SPICE에서 다루는 프로세스 영역은 다음과 같다.

`고객 공급자 프로세스`: 소프트웨어를 개발하여 고객에게 제공하고 소프트웨어를 정확하게 운용하고 사용하도록 지원하기 위한 프로세스
`엔지니어링 프로세스`: 시스템과 소프트웨어 제품을 개발하는 모든 프로세스
`지원 프로세스`: 문서화, 형상 관리, 품질 보증, 검증, 확인, 검토 등 개발 활동을 지원하는 프로세스
`관리 프로세스`: 일반적인 소프트웨어 프로젝트에서 일어나는 관리 활동
`조직 프로세스`: 조직 업무의 목적을 수립하고 조직이 업무 목적을 달성하기 위해 도움을 주는 프로세스

SPICE의 6단계 능력 수준은 다음과 같다.

`Level 0 - 불완전 단계 (Incomplete)`: 프로세스가 정의되지 않았거나 거의 수행되지 않는 상태
`Level 1 - 실행 단계 (Performed)`: 프로세스가 수행되긴 하지만 관리나 문서화는 부족한 상태
`Level 2 - 관리 단계(Managed)`: 프로세스가 계획되고 관리되는 상태
`Level 3 - 확립 단계(Established)`: 조직의 표준 프로세스에 따라 수행되는 상태
`Level 4 - 예측 단계(Predictable)`: 프로세스 성과가 정량적으로 관리되는 상태
`Level 5 - 최적화 단계(Optimizing)`: 프로세스의 지속적 개선이 이루어지는 상태

[소프트웨어 공학] - 유지보수 (Maintenance)

shineast_ — Sun, 1 Jun 2025 22:21:59 +0900

유지보수 (Maintenance)

소프트웨어 시스템을 개발하고 릴리즈하여 운영하기를 시작하면 본격적으로 사용 단계에 접어들게 된다. 사용자가 시스템의 기능을 사용하면서 시스템 또한 안정된다. 그러나 빈도는 점차 줄어들겠지만 시스템의 버그와 결함에 대한 수정 작업은 계속 진행되어야 한다. 이와 같이 소프트웨어 개발 이후에 진행되는 변경 작업을 “유지보수”라고 한다.

유지보수가 지속되면서 소프트웨어는 계속 진화하며, 이 기간은 소프트웨어 생명 주기의 많은 부분을 차지한다. 따라서 유지보수는 소프트웨어 엔지니어링에서 매우 중요하다.

유지보수의 목적

과거에 구축된 많은 소프트웨어 시스템이 오늘날까지 사용되는데, 이러한 오래된 시스템들이 현재까지 여전히 사용되는 것을 “래거시 시스템(Legacy System)”이라고 한다. 래거시 시스템은 쉽게 소멸되지 않는데, 이는 시스템을 대체하기 위해서 많은 비용이 들고 또한 대체되는 새로운 시스템이 래거시 시스템에 비해 좋다는 보장이 없기 때문이다.

결국, 이러한 래거시 시스템의 구조를 개선하고 지속적으로 변경해나가는 작업을 진행하게 된다. 릴리스된 시스템의 변경이 필요하게 되는 목적은 다음과 같다.

버그 제거
운영 환경의 변화
정부 정책, 규례의 변화
비즈니스의 절차의 변화
미래 문제를 배제하기 위한 변경

유지보수의 유형

유지보수 작업은 변경의 이유에 따라서 작업의 형태가 달라진다. IEEE에 의하여 소프트웨어 유지보수의 종류를 분류하면 다음과 같다.

`수정형 유지보수`: 소프트웨어 설치 후에 발견된 결함을 고치기 위하여 소프트웨어 제품을 수정하는 작업 유형
`적응형 유지보수`: 소프트웨어 설치 후에 변경된 환경에서도 계속 사용할 수 있도록 소프트웨어를 이식하거나 변경하는 작업 유형
`완전형 유지보수`: 소프트웨어 설치 후에 성능이나 유지보수성을 개선하기 위하여 실시하는 작업 유형
`예방형 유지보수`: 오류 발생을 방지하기 위하여 소프트웨어 복잡성을 줄이는 유지보수 작업 유형

Lehman의 법칙

Lehman이 발견한 유지보수에서의 변경에 대한 추세와 패턴에 대한 사실은 다음과 같다. 이를 소프트웨어 진화의 법칙이라고 부른다.

지속적인 변경의 원칙

시스템이 릴리즈 된 후 변경은 기 시스템이 대체될 때까지 변경된다. 시스템의 요구는 항상 변화하기에 소프트웨어가 계속 사용되기 위해서는 끊임없이 좋은 방향으로 진화되어야 한다.

엔트로피, 복잡도 증가의 법칙

시스템이 변경될수록 구조는 더욱 복잡해지고 컴포넌트 사이의 결합은 증가한다. 시스템 구조를 단순화시키기 위한 많은 노력이 필요하며 재구조화나 리엔지니어링을 통해서 시스템 구조를 개선해야 한다.

자기 통제의 법칙

시스템 진화 과정은 자기 통제의 과정이다. 일정한 규모의 조직과 프로젝트에서는 시간이 지나면서 개발 속도, 변경 빈도, 결함율 등이 예측 가능하고 안정된 분포를 보인다

안정성 유지의 법칙

진화하는 시스템의 유지보수 프로세스는 시스템이 소멸될 때까지 일정한 평균 작업량을 보인다.

친근성 유지의 법칙

시스템의 평균 성장률은 소멸될 때까지 일정하다. 시스템 개발 전 단계에 걸쳐 각 버전의 변화는 거의 일정하다.

지속적 성장의 법칙

계속 진화하는 E 타입의 시스템은 사용자를 만족시키기 위해 기능적 성장을 계속해야 한다.

품질 저하의 법칙

E 타입 시스템의 품질은 운영 환경의 변화에 완전히 적응하지 못하는 한 저하된다.

피드백 시스템의 법칙

진화 프로세스는 여러 단계의 어려 번 반복, 중요한 역할을 담당하는 여러 관련자들의 피드백으로 구성된다.

유지보수 작업 과정 (Maintenance Work Process)

유지보수 작업은 개발 작업과는 다르게 수정하기 위해 프로그램 로직을 이해하고 문서를 리뷰하는 일이 많다. 실제 변경을 계획하고 구현하고 수정된 것을 문서에 반영하는 일은 상대적으로 적다. 유지보수에는 다음의 작업들이 기본적으로 포함된다.

`현재 프로그램의 이해`: 유지보수를 위해서 엔지니어는 프로그램 로직을 추적하고 요구, 설계에 대한 이해가 필요하다.
`변경 파악과 분석`: 필요한 변경을 파악하고 영향도와 소요 비용, 변경에 대한 리스크를 분석해야 한다.
`변경 영향 파악`: 시스템의 컴포넌트가 변경되면 다른 컴포넌트에 영향을 줄 수 있기에 이러한 부분을 인지해야 한다.
`변경 구현, 테스트, 설치`: 변경이 승인되면 현재 시스템을 수정하고, 구현으로부터 설계를 복구하거나 변경된 요구를 만족시키기 위해 설계를 변경하기도 한다. 변경을 반영하여 시스템을 수정하고 테스트를 실시하고 시스템을 운영 환경에 설치한다.

유지보수 프로세스 모델

소프트웨어 개발 작업처럼 유지보수 작업도 프로세스가 필요하다. 소프트웨어에 유지보수성을 형성하기 위한 요구가 어떤 것인지 인식하기 위해 모델이 필요하다.

`즉시 수정 모델`: 임시방편적인 유지보수 작업 모델로, 문제가 발견되어 확인되면 가능한 빨리 문제를 해결하는 방식이다.
`반복적 개선 모델`: 소프트웨어에 대한 변경이 전체 생명주기 단계에 반복적으로 일어나 시스템을 계속 개선시키는 방식으로, 변경의 필요성이 생길 때마다 분석, 재설계, 구현 작업을 반복하고 계속 파급되어 시스템을 개선시킨다.
`재사용 중심 모델`: 프로그램 컴포넌트의 재사용을 중심적으로 여기는 방식이다.

변경 파악과 분석

소프트웨어 유지보수는 변경 요구를 기초로 어떤 부분을 변경해야 하는지 찾는 것이다. 지정된 컴포넌트가 변경되어 영향을 받는 다른 컴포넌트는 어떤 것인지를 파악하고, 변경을 구현하고 결과를 테스트하는데 드는 비용과 시간을 예측해야 하며, 리스크를 파악하고 해결책에 대한 측정 방법을 정의해야 한다.

형상 관리 (Configuration Management)

소프트웨어 개발 주기 동안 생성된 문서를 관리하고 소프트웨어 시스템과 컴포넌트의 상태를 추적하는 작업을 “소프트웨어 형상 관리”라고 한다.

베이스라인 (Baseline)

소프트웨어 개발 주기 각 단계에 결과물이 성공적으로 만들어졌는지 체크하는 것은 프로젝트의 진도를 측정하고자 하는 것이다. 베이스라인은 소프트웨어 프로젝트의 진척 상태를 나타내고, 소프트웨어 결과물의 집합으로 구성된다. 베이스라인은 다음의 목적을 지닌다.

프로젝트 진행의 중요한 상태를 정의한다.
프로젝트나 프로덕트가 특정 상태에 이르렀는지를 나타낸다.
계속되는 개발 또는 유지보수 작업의 기준이 된다.
형상 항목에 대한 변경을 제어하는 메커니즘이다.

프로젝트의 베이스라인을 정의하고 베이스라인을 공식적으로 확립하기 위한 메커니즘을 제공함으로 형상 관리를 진행할 수 있다. 결국, 형상 항목 관리는 베이스라인에 대한 업데이트이다.

형상 관리 절차

형상 관리는 다음 네 가지 기능으로 구성된다.

`소프트웨어 형상 파악`: 베이스라인과 형상 항목, 아이템을 구별하기 위한 명명 체계를 정의한다.
`형상 변경 제어`: 시스템 형상의 일관성과 개발자 사이의 협력을 확인하기 위해 형상 항목에 대한 변경을 관리한다.
`소프트웨어 형상 감사`: 소프트웨어 형상에 대하여 요청된 변경이 적절히 이루어졌는지 확인하고 베이스라인과 형상 항목들을 검증한다.
`소프트웨어 형상 상태 보관`: 소프트웨어 형상에 대한 정보를 추적하고 유지하기 위해 형상의 상태를 보관하고 관리한다.

역공학 (Reverse Engineering)

역공학은 완제품으로부터 설계를 해독해내는 과정을 말한다. 소프트웨어 작업 과정에서 역공학은 설계, 요구 명세, 문제 정의를 회복하기 위하여 코드를 변환하는 개발 프로세스의 역방향 프로세스를 말한다.

대상 시스템을 분석하여 시스템의 컴포넌트와 관계를 찾고 같은 수준의 다른 표현이나 더 높은 추상 수준의 표현으로 만드는 것이다. 반면, 논리적/구현 독립적 설계에서 시스템의 물리적 구현으로 진행하는 프로세스를 순공학이라고 한다.

역공학 작업 순서

역공학 프로세스의 단계는 다음과 같다.

원시코드에서 소프트웨어 결과물들을 추출한다.
파악된 각 요소는 다이어그램으로 그리기 위해 레이아웃을 계산한다.
디스플레이 컴포넌트가 레이아웃에 따라 다이어그램으로 그려진다.

역공학 용도

역공학에 의하여 복원된 다이어그램은 여러 방면에 사용된다.

`프로그램 이해`: 역공학 도구에 의해 생성된 다이어그램은 유지보수하고 있는 소프트웨어의 구조, 기능, 동작의 이해를 용이하게 한다.
`정형적 분석`: 정형적 분석 기술은 역공학 도구에 의하여 생성된 다이어그램을 소프트웨어에 존재할 수 있는 문제를 감지하기 위해 사용될 수 있다.
`테스트 케이스 생성`: 역공학 도구에 의하여 생성된 다이어그램은 테스트 케이스 생성을 용이하게 한다.
`리엔지니어링`: 역공학에 의하여 생성된 다이어그램은 리엔지니어링을 위하여 사용

설계 복구

설계 복구는 원시코드를 자세히 검토하여 의미있는 추상성이 높은 표현을 찾아내고 추출하는 작업이다. 이때, 복구된 설계는 원래 설계가 아닐 수도 있다. 복구된 설계는 원시코드 이해에 도움이 되고 유지보수나 리엔지니어링을 위한 베이스라인으로도 사용될 수 있다.

리엔지니어링 (Re-Engineering)

리엔지니어링이란 소프트웨어의 어떤 측면을 개선하기 위해서 시스템 또는 컴포넌트를 재구조하는 과정이다. 리엔지니어링은 소프트웨어 시스템의 구조를 개선하여 향후 유지보수 작업이 효율적으로 이루어지게 하기 위해서 필요하다.

리엔지니어링 목적

소프트웨어 리엔지니어링은 여러 가지 목적으로 수행된다.

소프트웨어 아키텍처 개선
소프트웨어의 복잡도 경감
변경에 대한 적응성 개선
성능, 효율성, 자원 유용성 개선
소프트웨어 시스템의 유지보수 개선

리엔지니어링 과정

소프트웨어 리엔지니어링 과정은 다음과 같다.

개선이 필요한 위치 파악: 소프트웨어를 분석하여 개선이 필요한 위치를 파악한다.
개선 전략 선택: 개선할 것으로 파악된 항목에 대한 개선 전략을 개발한다.
제안된 개선 구현: 제안된 개선을 구현하고 리엔지니어링한 소프트웨어가 요구를 만족하는지 테스팅을 실시한다.
목표를 기준으로 시스템 평가: 변경된 시스템을 목표 대비하여 평가하고 추가 개선이 필요하면 프로세스를 반복한다.

[소프트웨어 공학] - 테스트 (Testing)

shineast_ — Sat, 24 May 2025 13:01:56 +0900

테스트 (Testing)

소프트웨어 개발 과정 중 실수와 결함이 발생하는 것을 필연적인데, 이 실수와 결함을 낮추는 방법은 두 가지이다. 첫 번째는 처음부터 결함이 발생하지 않도록 방지하는 것, 두 번째는 유입된 결함을 식별하고 제거하는 것이다.

테스트는 소프트웨어에 결함이나 원치 않는 동작을 찾아내고 소프트웨어가 요구와 제약에 맞는지 검증하는 작업이다. 즉, 테스트 작업은 유입된 결합을 식별하고 제거하는데 초점을 둔다.

버그, 오류, 결함, 고장

버그, 오류, 결함, 고장이라는 용어를 잘 구별하면 테스트 작업에 도움이 된다. 버그는 문제, 결함 등을 나타내는데 일반적으로 사용되는 용어이다.

`오류(Error)`: 개발자가 잘못하여 설계나 코딩에서 실수한 것이다. 즉, 사람의 실수이다.
`결함(Defect)`: 오류가 있는 경우 결함이 발생한다. 결함은 시스템이 고장을 일으키게 되는 오류의 결과이다. 결함은 코드 또는 문서에 오류가 있다고 선언된 것이다.
`고장(Failure)`: 고장은 시스템이 원하는 작업을 수행할 수 없는 상황을 말한다. 프로그램의 실제 동작이 예상된 동작과 같지 않을 때 발생하는 현상이다.

테스트 원리

테스트 작업의 원리와 특징은 다음과 같다.

테스트는 오류를 발견하기 위하여 프로그램을 실행시키는 것이다.
완벽한 테스트는 불가능하다.
테스트는 창조적인 일이며 어려운 일이다.
테스트는 오류의 유입을 방지할 수 있다.
테스트는 구현과 관계없는 독립된 팀에 의해 수행되어야 한다.

테스트 작업 과정

테스트하고자 하는 소프트웨어를 실행시킨 후의 결과가 예상한 결과와 차이가 있다면 오류가 있는 것이다. 테스트 작업은 다음의 단계를 통해 이루어진다.

테스트에 의하여 무엇을 점검할 것인지 정한다.
테스트 방법을 결정한다.
테스트 케이스를 개발한다.
테스트의 예상되는 올바른 결과를 작성한다.
테스트 케이스로 실행시킨다.

테스트 케이스 (Test Case)

성공적인 테스트를 위해서는 결함의 존재를 잘 드러내는 좋은 테스트 케이스를 찾아낸 것이다. 이러한 테스트 케이스는 시험 대상 단위별로 묶어서 준비한다. 테스트 케이스에는 일반적으로 시험조건, 테스트 데이터, 예상 결과를 포함시켜야 한다. 또한 테스트 방법이 제안하는 조건을 만족하는 테스트 케이스를 신중히 선택하는 것이 중요한데, 테스트 케이스를 어떤 근거로 선택하는가? 이것이 테스트 작업의 중요한 관심사이다.

블랙박스 테스트 (Black Box Testing)

블랙박스 테스트란 내부 코드 구조, 구현 세부 사항 및 소프트웨어의 내부 경로에 대한 지식을 보지 않고 테스트 대상의 기능이나 성능을 테스트하는 기술이다. 즉, 블랙박스 테스트에서는 소프트웨어 프로그램의 내부 지식에 신경 쓰지 않고 소프트웨어 시스템의 입출력에 중점을 둔다.

블랙박스 테스트 방법을 사용하는 테스트 엔지니어는 시스템에 줄 수 있는 입력과 시스템이 배출해야 하는 출력이 무엇인지 결정해야 한다. 블랙박스 테스트의 장단점은 다음과 같다.

(장점) 테스트하기 위해 기술적 배경이 필요하지 않다.
(장점) 코딩이 완료되어야 테스트가 가능해서 테스터와 개발자가 서로 독립적으로 작업 가능하다.
(장점) 테스트 초기 단계에서 결함과 불일치를 식별할 수 있다.
(단점) 크고 복잡한 경우 완전한 테스트 범위가 불가능하다.
(단점) 개발 지식이 없다면 테스트할 시나리오의 가능한 조건을 무시할 수도 있다.

동등 분할 기법 (Equivalence Partitioning)

동등 클래스는 시스템의 동작이 같을 것으로 예상되는 입력들로 구성된다. 이때, 동작이 다를 것으로 예상되는 입력은 각각 다른 동등 클래스로 분리되어야 한다.

동등 분할 기법은 입력 데이터를 몇 개의 동등한 클래스(Equivalence Class)로 나누어 각 클래스에서 대표값 하나만 테스트하는 기법이다. 테스트 케이스를 줄이면서도 효율적인 테스트를 수행할 수 있다. 동등 클래스에서 테스트 케이스를 선택할 때는 정상적인 입력 뿐만 아니라 비정상적인 입력도 고려한다.

경곗값 분석 (BVA: Boundary Value Analysis)

경곗값 분석은 입력값의 경계선에 중점을 두는 테스트 방법으로, 이때 경계란 시스템의 동작이 변경되는 한계 근처의 값을 말한다. 입력값의 경계에서 결함이 발생할 가능성이 높다는 가정 하에, 경곗값 전후의 값을 집중적으로 테스트한다.

동등 분할 기법과 마찬가지로 유효한 입력과 유효하지 않는 입력 모두 테스트하여 문제를 확인한다.

원인 결과 그래프 (Cause-Effect Graphing)

동등 분할 기법과 경곗값 분석 방법 모두 각각의 입력을 별도로 생각하여, 입력 조건이나 클래스의 조합을 고려하지 않는다. 여러 입력 조건의 조합을 검사하는 방법은 테스트 케이스가 너무 많이 나오기에 쉽지 않다.

원인 결과 그래프는 입력 조건의 조합을 체계적으로 선택하여 테스트 케이스가 너무 많게 되지 않도록 하는 기법이다. 테스트하려는 시스템의 원인과 결과를 파악하고 이를 논리적으로 분석한다. 그 이후 원인 결과 그래프로 시각화하고 그래프를 의사 결정 테이블로 변환한다. 그리고 테이블을 바탕으로 테스트 케이스를 도출한다.

이때, 원인(Cause)은 입력 조건 또는 트리거이고 결과(Effect)는 시스템의 반응 또는 출력이다. 원인과 결과를 도식화하여 논리 연산으로 표현한다. 그리고 이를 의사 결정 테이블로 변환하여 테스트 케이스를 도출하는 것이다.

화이트박스 테스트 (White Box Testing)

화이트박스 테스트는 모듈 안의 작동을 자세히 관찰하는 테스트 방법이다. 모듈의 논리적인 구조를 체계적으로 점검하기에 검증 기준이 더 정확하고 세밀하다. 화이트박스 테스트의 과정은 다음과 같다.

원시 코드를 통해 애플리케이션의 구조를 이해한다.
테스트에 의해 검증하는 범위를 정하고 이에 맞는 테스트 경로와 선택조건을 찾는다.
각 경로를 구동시키는 테스트 데이터를 준비하여 시험 대상 프로그램을 수행시키고 결과를 비교한다.

화이트박스 테스트의 장단점은 다음과 같다.

(장점) 모든 라인과 경로를 직접 추적하므로 테스트 정밀도가 높다.
(장점) 논리적 실수를 조기에 발견할 수 있다.
(장점) 사용되지 않는 코드나 처리되지 않은 예외를 발견하기 쉽다.
(단점) 코드의 내부 구현을 알지 못하면 수행할 수 없다.
(단점) 테스트 케이스 설계가 복잡하고, 코드 변경 시 테스트도 자주 수정해야 한다.

검증 기준 (Test Coverage)

화이트박스 테스트에서 테스트 데이터를 선택하기 위해 테스트 실행이 프로그램의 어떤 기준을 커버하는지 먼저 결정해야 한다. 이러한 검증 기준은 다음과 같다.

문장 커버리지 (Statement Coverage)

문장 커버리지는 코드의 각 라인이 적어도 한 번씩 실행되는지를 검증하는 방법이다.

분기 커버리지 (Branch Coverage)

분기 커버리지는 IF문과 같은 각 분기가 한 번씩 실행되는지를 검증하는 방법이다.

경로 커버리지 (Path Coverage)

경로 커버리지는 프로그램의 모든 실행 경로를 테스트하는 기준으로, 프로그램의 모든 경로가 적어도 한 번씩 통과하도록 분기가 나올 때마다 누적하여 추가한다.

대부분의 프로그램에서는 여러 차례 반복되는 중복된 반복문을 가지기에 셀 수 없이 많은 경로가 발생한다. 이러한 반복문으로 인해 모든 경로 커버리지는 현실적으로 사용하기 어렵다. 이를 해결하기 위해 모든 반복 구조를 “단순 반복문 테스트”, “중첩된 반복문 테스트”, “연속된 반복”, “비구조화 반복”으로 분류하여 각각의 케이스마다 테스트 방법을 달리하여 적용한다.

상태기반 테스트 (State-Based Testing)

같은 입력에 대해 항상 같은 동작, 동일한 결과를 생성하는 프로그램을 “상태가 없는 프로그램(State-Less Program)” 이라고 한다. 반면, 동일한 입력에 대해 시간에 따라 다르게 동작하고 다른 결과를 출력하는 프로그램도 존재한다.

프로그램의 상태는 프로그램이 받은 과거의 입력에 따라 좌우된다. 이러한 시스템을 위한 테스트 케이스를 선택하는 방법이 상태 기반 테스트이다. 상태 모델을 통해 무엇이 상태 변화를 일으키는지 이벤트에 대한 반응으로 시스템이 어떤 액션을 취하는지 나타낼 수 있다. 이때, 상태 모델은 네 가지 요소로 구성된다.

`상태(State)`: 시스템의 과거 입력에 대한 영향을 표시한다.
`트랜지션(Transition)`: 이벤트에 대한 반응으로 시스템이 하나의 상태에서 다른 상태로 어떻게 변하는지를 나타낸다.
`이벤트(Event)`: 시스템에 대한 입력을 나타낸다.
`액션(Action)`: 이벤트에 대한 출력을 나타낸다.

시스템의 상태 모델이 구축된 후, 테스트 케이스를 선택할 수 있다. 상태기반 테스트는 상태와 트랜지션에 집중하여 테스트 케이스를 고려한다.

통합 테스트 (Integration Testing)

통합 테스트는 시스템을 구성하는 모듈들의 결합을 테스트하는 것이다. 단위 모듈을 개발하고, 그 사이의 인터페이스가 잘 작동하는지 테스트하는 것이다.

빅뱅 통합 (BigBang Integration)

빅뱅 통합은 한 번에 모든 모듈을 모아 통합하는 방법이다. 개발하는 모듈에 대해 일정한 마감일을 정하고 완성된 모듈을 한 번에 모아 통합한다.

하향식 통합 (Top-Down Integration)

하향식 통합은 시스템 구조도의 위층에 있는 모듈부터 아래층의 모듈로 내려오며 통합되는 방법이다. 명령어 처리 모듈을 먼저 구현하고 시험하며, 이때 명령어 처리 모듈은 시스템 구조도의 최상위 모듈을 의미한다. 이렇게 하위 층의 모듈로 계속 내려가면서 테스트하고 추가하여 전체 시스템이 모두 결합될 때까지 반복한다.

최상위 층의 모듈에 대한 드라이버와 더미 모듈인 “스텁”을 작성하고 통과되면 스텁을 대상 모듈로 교체한다.

상향식 통합 (Bottom-Up Integration)

상향식 통합은 시스템 구조도의 최하위층에 있는 모듈을 먼저 통합하여 시험한다. 그 이후, 위층의 모듈이 추가되어 서브시스템을 이루고 서브시스템은 계속 커져나가는 방법이다.

최하위 층을 구동하는 드라이버를 준비하여 통합하고, 통과하면 드라이버 대신 개발된 모듈로 대체하고 이를 구동하는 드라이버로 통합시킨다. 위층으로 올라가면서 메인 모듈이 통합될 때까지 반복한다.

연쇄식 통합 (Chain Integration)

가장 최선의 통합 방법인 연쇄식 통합은 특수하고 중요한 기능을 수행하는 최소 모듈 집합을 먼저 구현하고, 보조적인 기능의 모듈은 나중에 구현하여 테스트하고 추가한다.즉, 모듈의 최소 단위(Thread)로부터 시작되는 통합 방법이다.

연쇄식 통합에서는 자료의 흐름이 한 방향으로만 흘러가는 시스템에서 모듈을 데이터 흐름 순서대로 하나씩 연결하며 통합 테스트한다.

시스템 테스트 (System Testing)

단위 테스트와 통합 테스트는 주로 개별 컴포넌트 사이으이 인터페이스 오류에 중점을 둔다. 컴포넌트가 통합되면 시스템 테스트 기법을 사용하여 전체 시스템이 기능적/비기능적 요구를 만족하는지 확인한다.

기능 테스트 (요구 테스트)

기능 테스트는 말그대로 기능적 요구와 시스템의 차이를 발견하고자 하는 테스트이다. 테스트 사례를 유스케이스 모델에서 추출할 수 있는데, 모든 유스케이스를 테스트하는 것은 불가능하기에 적절한 테스트 케이스를 추출하는 것은 중요하다.

기능 테스트를 파악하기 위해 먼저 유스케이스 모델을 검토하고 오류를 일으킬만한 유스케이스 인스턴스를 찾아낸다. 이때 주로 블랙박스 테스트 기법을 사용한다.

성능 테스트

성능 테스트는 시스템의 작업 부하, 처리량, 반응 시간, 효율성 등 시스템의 여러 측면을 평가하기 위한 목적을 가진다. 성능 테스트를 위해서 시뮬레이션을 사용하기도 한다.

보안 테스트

보안 테스트는 시스템과 사용자에게 해를 입히려는 해커에게 이용될 수 있는 의도하지 않은 기능 및 동작 시스템을 찾아내기 위한 것이다. 즉, 시스템의 취약점을 찾기 위한 것이다.

보안 취약점을 찾아내기 위해 테스트 케이스를 생성할 때, 화이트박스 테스트를 적용할 수 있다. 보안 테스트 케이스를 생성하여 취약점을 검증하기도 한다. 그 뿐만 아니라 무작위로 입력값을 주는 랜덤 테스트 방식도 사용하여 취약점을 찾아내고 검증한다.

UI 테스트

UI 테스트는 기능, 성능, 보안 테스트와는 달리 인간공학적인 결함들을 발견하기 위한 목적을 가진다. UI 테스트를 통해 찾고자 하는 결함들은 다음과 같다.

보고 느끼는 UI에 대한 결함
데이터 입력과 출력 디스플레이에 대한 결함
액터-시스템 사이의 동작 결함
오류 처리에 대한 결함
문서와 도움말에 대한 결함

UI 테스트에서도 UI 테스트 도구를 사용할 수 있지만, UI 테스트에서는 작업의 상당 부분이 사람의 판단을 요구하기에 완전한 자동화는 불가능하다.

인수 테스트 (Acceptance Testing)

인수 테스트는 시스템을 당장 사용할 수 있도록 모든 준비가 되었는지를 테스트한다. 인수 테스트는 개발자가 아닌 클라이언트가 수행한다. 인수 테스트 방법의 대부분은 시스템 테스트와 같다. 실제 사용할 하드웨어와 소프트웨어를 기반으로 사용할 사람들이 실제 업무 절차를 따라 수행한다. 결국 인수 테스트의 목적은 다음과 같다.

요구사항 충족 확인: 기능이 계약서나 명세서 대로 구현되었는지 확인한다.
실사용 시나리오 검증: 실제 업무 흐름이 잘 동작하는지 확인한다.
사용자 만족도 확인: UI/UX, 응답 속도, 실용성 등 비기능 요소 등을 확인한다.
릴리즈 승인 여부 결정: 인수 테스트 통과 시 실제 배포 또는 상용화가 가능하다.

불특정 다수의 사용자를 위하여 작성한 소프트웨어의 인수 시험으로는 알파 테스트와 베타 테스트가 있다.

`알파 테스트(Alpha Testing)`: 소프트웨어 출시 전, 개발자와 내부 테스트 인원이 사내에서 실시하는 사용자 관점 테스트
`베타 테스트(Beta Testing)`: 일정 수준의 완성도를 갖춘 소프트웨어를 외부 사용자에게 공개하여 피드백을 수집하는 테스트

소프트웨어 제품 정식 출시 전에 알파 테스트 이후 베타 테스트 순으로 진행하는 것이 일반적이다.

[컴퓨터 네트워크] - 네트워크 보안 (Network Security)

shineast_ — Sat, 10 May 2025 14:10:07 +0900

네트워크 보안 (Network Security)

정보 기술의 발전으로 수많은 데이터를 공유하면서 보안을 위협하는 사이버 범죄도 증가하고 있다. 네트워크가 개방되고 성능 및 시스템 간 연결성이 강화되면 이에 비례하여 취약성도 증대된다. 보안을 명확하게 경계를 구분하는 것은 어렵지만 크게 컴퓨터 보안과 네트워크 보안으로 구분된다.

`컴퓨터 보안`: 컴퓨터 자체의 데이터를 보호한다.
`네트워크 보안`: 컴퓨터 간 데이터를 안전하게 전송한다.

네트워크 보안의 요구 사항

네트워크 보안의 요구 사항은 크게 “비밀성”, “무결성”, “가용성”이다.

`비밀성(Privacy)`: 데이터의 소유자가 원하는 대로 비밀을 유지하는 것으로, 비밀성을 보장하는 방법으로는 “암호화”와 “접근 통제”가 있다.
`무결성(Integrity)`: 인증되지 않은 사용자가 데이터를 임의로 변경/수정/삭제하지 못하게 하여 데이터의 정확성과 완전성을 보장하는 것이다.
`가용성(Availability)`: 정당한 방법으로 권한을 받은 사용자가 데이터 또는 자원이 필요할 때 아무런 방해를 받지 않고 데이터에 접근하여 사용할 수 있음을 보장하는 것이다.

네트워크 위협 (Network Threats)

스미싱 (Smishing)

스미싱은 문자 메시지(SMS)와 피싱(Phising)의 합성어이다. 스미싱 공격에서 공격자는 신뢰할 수 있는 기관을 사칭해 문자 메시지를 보내고, 사용자가 악성 링크를 클릭하거나 앱을 설치하도록 유도한다. 이로 인해 금융 정보, 개인 정보가 유출되거나 악성코드에 감염될 수 있다.

스미싱의 특징은 다음과 같다.

스마트폰에 많이 설치되는 정상 어플을 사칭하여 악성 앱 설치를 유도한다.
사용자가 악성 앱을 설치하도록 유도하기 위해 관심을 끄는 SMS를 전송한다.
정상적인 사이트와 매우 유사하게 제작된 피싱 사이트로 연결한다.

스미싱의 예방 방법은 다음과 같다.

의심스러운 문자에 포함된 링크 클릭 금지
출처가 불분명한 앱 설치 금지
문자 수신 시 발신번호 확인 및 공식 웹사이트 접속 확인
모바일 백신 설치 및 최신 업데이트 유지

랜섬웨어 (Ransomware)

랜섬웨어는 몸값(Ransom)과 소프트웨어(Software)의 합성어로, 시스템을 잠그거나 데이터를 암호화하여 사용 불가능하게 하며 이를 인질로 금전을 요구한다.

랜섬웨어의 감염 경로는 다음과 같다.

신뢰할 수 없는 사이트: 단순한 사이트 방문으로도 감염될 수 있고, 드라이브 바이 다운로드 기법을 통해 유포된다.
파일 공유 사이트: 토렌트, 웹하드 등의 P2P 사이트에서 동영상 등의 파일을 다운로드하여 실행하면 악성코드에 감염될 수 있다.
SNS: 페이스북, 인스타그램 등의 SNS에 업로드 된 단축 URL과 이미지를 통해 유포된다.
네트워크망: 네트워크를 통해 최신 보안 패치가 적용되지 않은 컴퓨터를 스캔하여 악성 코드를 감염시킨다.

랜섬웨어의 예방 방법은 다음과 같다.

중요 데이터는 주기적으로 백업하기
신뢰할 수 없는 이메일 첨부파일 및 링크 클릭 금지
운영체제 및 보안 소프트웨어 최신 상태 유지
이메일 발신자와 내용 확인 후 의심되면 열람하지 않기

공유기 보안 위협

보안 설정이 되지 않은 무선 LAN은 외부에서 무선 공유기를 무단으로 사용할 수 있다. 해커가 접속하여 해킹 및 개인 정보 유출 등의 다양한 보안 위협을 유발할 수 있으며, 인터넷에서 접속 가능한 공유기의 DNS 주소를 변조하는 방법들을 활용하여 사용자에게 피해를 입힐 수 있다.

공유기 보안 위협 예방 방법은 다음과 같다.

공유기 관리자 비밀번호를 복잡하게 설정하기
주기적으로 펌웨어 업데이트하기
원격 관리 기능 비활성화하기
WPA3 또는 WPA2 보안 프로토콜 사용하기

네트워크 공격 기술 (Network Attack Techniques)

네트워크 공격 기술은 점점 더 정교해지고 범위가 넓어지고 있다. 이러한 공격 기술들은 컴퓨팅 환경에 심각한 위협을 가한다.

IP 스푸핑 (IP Spoofing)

IP 스푸핑은 IP 주소를 속이는 행위로, 공격자가 임의로 웹사이트를 구성하여 일반 사용자의 방문을 유도하고 TCP/IP의 구조적 결함을 이용해 사용자 시스템 권한을 획득하여 정보를 빼가는 해킹 수법이다. 즉, 공격 대상 컴퓨터를 무력화하여 자신이 해당 컴퓨터인 것처럼 위장하는 것이다. IP 스푸핑의 공격 방법으로는 다음이 있다.

`IP 주소 스푸핑 공격`: 거짓 송신 주소를 이용한다.
`사용자 인증 스푸핑 공격`: 인증되지 않은 패스워드로 접근하여 공격하는 방법이다.

이러한 IP 스푸핑을 차단하는 방법은 다음과 같다.

`액세스 제어`: 내부 네트워크에 있는 송신지 주소를 가진 외부 네트워크의 패킷을 모두 거부한다.
`필터링`: 내부 네트워크의 IP 주소 범위에서 송신지 주소를 보유하지 않은 패킷이 외부로 나가는 것을 차단한다.
`암호화`: 패킷을 암호화하여 전송하기에 노출되더라도 이해할 수 없는 암호화된 문자로 나타난다. (SSH)

IP 스니핑 (IP Sniffing)

IP 스니핑은 네트워크를 이용하여 전송하는 데이터를 엿듣는 일종의 도청 행위이다. TCP/IP 프로토콜은 인터넷이 시작되기 전부터 설계된 프로토콜이기에 데이터 통신 보안의 기본 요소인 비밀성과 무결성을 보장하지 못한다.

스니핑은 비밀성을 해치는 대표적인 공격 방법이기에, 네트워크를 공유하는 환경에서 매우 치명적일 수 있다. 스니핑은 LAN 카드의 모든 트래픽을 보도록 설정할 수 있는 “프로미큐어서 모드(Promiscuous Mode)”를 성정하여 모든 트래픽을 도청할 수 있다.

스니핑 피해를 감소시키는 방법은 다음과 같다.

`가상 LAN을 작게 나누기`: 스니핑은 동일한 가상 LAN에서 가능하기에 가상 LAN을 작게 나누면 피해를 감소시킬 수 있다.
`암호화 전송 프로토콜 사용`: 스니핑은 텔넷, FTP, POP3 등이 평문으로 전송되는 트래픽을 모니터링하여 ID나 패스워드를 빼내는 것이다. 이때, 암호화 전송 프로토콜을 사용하면 중간에 패킷을 가로채도 분석하기 어렵다. 따라서 최근에는 텔넷 대신 SSH, HTTP 대신 HTTPS, POP3 대신 POP3S 등의 프로토콜을 사용한다. 이외에도 VPN을 사용하는 방법도 권장된다.

시스템 보안 기술 (System Security Technologies)

대표적인 네트워크 시스템 보안 장비로는 방화벽이 있다. 또한 방화벽 기능을 보완하기 위해 등장한 침입 탐지 시스템, 침입 방지 시스템 등이 있다.

방화벽 (Firewall)

방화벽은 외부 네트워크에서 내부 네트워크로 접근하기 위해 반드시 통과해야 하는 요소로, 내부 네트워크의 자원과 정보를 보호하는 시스템이다. 외부 네트워크와 내부 네트워크의 유일한 경로에 방화벽을 둬서 불법적인 트래픽을 거부하거나 방지할 수 있다.

방화벽의 여러 기능과 보안 대처 수준에 따라 다양한 유형의 방화벽을 사용할 수 있는데, 방화벽을 구성하는 요소는 다음과 같다.

`네트워크 정책`: 방화벽의 설계/설치/사용에 직접적으로 영향을 줄 수 있는 두 가지 수준의 네트워크가 있다. 이는 조직 차원의 보안 목표를 명시한 개념적 정책인 “상위 수준 정책”과 상위 정책을 구현한 구체적인 방화벽 규칙인 “하위 수준 정책”으로 구분된다.
`방화벽 사용자 인증 시스템`: 방화벽에서는 단순한 패스워드로 사용자를 인증하는 방식을 사용하지 않고, 스마트카드, 인증 토큰, 소프트웨어 메커니즘 등을 인증 수단으로 사용한다.
`패킷 필터링`: 패킷 필터링 라우터는 라우터 인터페이스를 지나는 패킷을 필터링한다.
`응용 계층 게이트웨이`: 애플리케이션 데이터를 직접 분석해 고급 보안을 제공하는 프록시 형태의 방화벽이다. 프록시 서버(Proxy Server) 기능을 제공하여 사용자의 요청을 외부 서버로 대신 전달하고, 그 결과를 다시 사용자에게 전달한다.

방화벽 사용 시 이점은 다음과 같다.

`외부 공격 차단`: 해킹, 악성 코드, 무단 접근 등 외부 위협으로부터 네트워크를 보호할 수 있다.
`접근 제어`: 승인된 사용자나 IP, 포트만 접근이 가능하도록 설정할 수 있다.
`트래픽 모니터링 및 로깅`: 들어오고 나가는 트래픽을 기록하여 보안 분석에 활용한다.
`내부 정보 유출 방지`: 내부에서 외부로 나가는 민감한 데이터 흐름을 제어한다.
`보안 정책의 일관된 적용`: 네트워크 전반에 걸쳐 통일된 보안 규칙을 적용할 수 있다.

방화벽 사용 시 고려해야 할 점은 다음과 같다.

`정책 설정의 복잡성`: 잘못된 룰 설정 시 정상 트래픽도 차단할 수 있고 보안적으로 취약점이 생길 수 있다.
`성능 저하 가능성`: 트래픽 검사로 인해 지연이나 속도 저하가 발생할 수 있다.
`암호화된 트래픽 처리 한계`: HTTPS와 같은 암호화된 트래픽 내부까지 분석하기 어렵다.
`단일 장비 의존 위험`: 방화벽 하나만으로 모든 보안을 담당하게 될 경우, 공격에 대한 방어 실패 시 전체 네트워크가 위험해질 수 있다.
`정기적인 업데이트 필요`: 새로운 공격 방식이나 취약점에 대비해 방화벽 소프트웨어 및 룰 업데이트는 필수이다.

침입 탐지 시스템 (IDS: Intrusion Detection System)

침입 탐지 시스템은 네트워크나 시스템에서 발생하는 이벤트를 실시간으로 모니터링하여, 의심스러운 행위나 보안 위협을 탐지하고 관리자에게 경고하는 역할을 수행한다. IDS는 주로 트래픽을 분석하여 정상적인 패턴과 비교하거나 알려진 공격 서명과 대조함으로써 공격을 식별한다. 그러나 실제로 공격을 차단하지는 않으며, 단순히 탐지와 알림 기능에 중점을 둔다.

침입 방지 시스템 (IPS: Intrusion Prevention System)

침입 방지 시스템은 IDS와 유사하게 네트워크 트래픽을 모니터링하지만, 탐지에 그치지 않고 실제로 위험한 트래픽을 차단하거나 중단하는 능동적인 보안 장비이다. IPS는 실시간으로 의심스러운 행위를 식별한 후, 즉시 해당 연결을 차단하거나 패킷을 삭제하여 네트워크에 미치는 피해를 사전에 방지할 수 있다.

침입 방지 시스템은 방화벽과 유사한 기능을 하면서도 더 세부적인 공격 패턴을 분석하고 차단한다. 특히 제로데이 공격이나 비정상적 행위 기반 탐지 기능이 향상되면서, 현대 보안 시스템에서 중요한 역할을 담당하고 있다.

[컴퓨터 네트워크] - 네트워크 관리 (Network Management)

shineast_ — Fri, 9 May 2025 11:23:21 +0900

네트워크 관리 (Network Management)

네트워크 관리란 제한된 인력과 비용을 활용하여 네트워크의 효율성과 생산성을 높일 수 있도록 복잡한 네트워크를 제어하는 일련의 과정으로, 네트워크에 분산된 각종 자원을 분배하고 관리하고 분석하며 평가하는 기능들이 포함된다.

네트워크 관리의 목적은 효율적으로 자원 사용을 극대화하고 서비스 품질의 가용성과 신뢰성을 최상의 상태로 유지하여 응답 시간을 단축하는 것이다. 또한 네트워크 관리를 통해 네트워크 모니터링, 트러블 슈팅, 유지보수 등을 능률적으로 수행할 수 있다.

네트워크 관리 기능

OSI 표준에서는 효율적인 네트워크 관리를 위해 “장애 관리”, “구성 관리”, “성능 관리”, “계정 관리”, “보안 관리” 기능을 제공한다.

장애 관리 (Fault Management)

장애 관리는 네트워크 구성 요소에 문제가 발생하거나 비정상적으로 작동할 때 이를 검출하여 격리/조사/분석/정정을 통해 복잡한 네트워크가 원할하게 작동하도록 하는 것이다. 장애가 발생한 시점을 기준으로 “사전 장애 관리”와 “사후 장애 관리”로 구성된다.

`사전 장애 관리`: 장애 발생을 억제하는 것으로, 장애 발생 원인을 사전에 파악하고 처리하는 과정
`사후 장애 관리` : 장애가 발생한 시점부터 장애를 처리하여 정상적인 상태로 전환할 때까지의 과정

성능 관리 (Performance Management)

정상적으로 작동하던 시스템에 트래픽이 발생하면 성능이 현저히 떨어지거나 다운되기도 한다. 이때, 성능 저하가 장애로 이어지지 않도록 방지하는 것이 성능 관리이다.

성능 관리는 통계 정보를 수집하고, 시스템 상태 이력 기록을 유지/검사하며, 시스템 성능을 측정하고, 지연 시간과 대역폭 사용률과 패킷 처리율 등을 단계별 또는 시간별로 관리한다.

구성 관리 (Configuration Management)

구성 관리란 장애 관리나 성능 관리에서 문제가 되었던 원인을 제거하여 네트워크 장치가 정상적으로 동작하도록 시스템에 적절한 설정을 하는 것이다. 네트워크 구성에 관한 정보를 수집하고 장치의 구성을 업데이트하여 최신 정보를 유지하며 보고서를 작성한다.

즉, 구성 관리는 시스템 구성을 최적의 상태로 유지하는데 목적을 둔다.

계정 관리 (Account Management)

계정 관리는 개방 시스템에서 일어나는 활동에 따라 소비하는 자원에 관한 모든 정보를 관리하고 자원 사용량과 관련이 있는 네트워크 데이터를 수집하는 것을 말한다.

네트워크 자원에 접근하려는 사용자가 정당한 사용자인지 인증하고, 인증되지 않은 사용자라면 네트워크 접근을 차단한다. 또한 사용자가 네트워크 자원을 어떤 방식으로 사용하는지 정보를 수집하고 네트워크 구성을 설계하는데 사용하여 사용자가 많이 사용하는 자원을 좀 더 효율적으로 사용할 수 있도록 한다.

보안 관리 (Security Management)

보안 관리란 컴퓨터 범죄, 해킹, 지적재산권 침해 등의 문제를 방지하여 네트워크 관리가 올바로 이루어지게 한다. 네트워크 자원과 정보를 보호하며, 패스워드와 인증, 접근 제어 정보를 관리하고 분배하는 역할을 한다.

네트워크 관리 프로토콜

네트워크 시스템을 효과적으로 관리하고 모니터링하기 위해 다양한 프로토콜이 사용되며, 그중 대표적인 것이 SNMP(Simple Network Management Protocol) 와 CMIP(Common Management Information Protocol) 이다.

SNMP (Simple Network Management Protocol)

SNMP는 IETF에서 개발한 프로토콜로, 오늘날 가장 널리 사용되는 네트워크 관리 프로토콜이다. SNMP는 단순하고 가벼운 구조를 가지고 있어, 다양한 네트워크 장비에 쉽게 적용할 수 있다는 큰 장점을 갖는다.

SNMP는 기본적으로 관리자가 정보를 요청하고, 네트워크 장비는 그에 응답하는 방식으로 동작한다. 예를 들어, 네트워크 관리 시스템(NMS)은 라우터나 스위치 등 장비에 연결된 에이전트에게 CPU 사용률이나 트래픽 양 등을 요청할 수 있고, 에이전트는 이를 MIB(Management Information Base)라는 표준화된 데이터 구조를 통해 전달한다. 또한, 장비에 이상이 발생한 경우에는 에이전트가 스스로 "Trap"이라는 경고 메시지를 보내 관리자에게 문제를 알릴 수 있다.

CMIP (Common Management Information Protocol)

CMIP는 ISO에서 개발한 프로토콜로, SNMP보다 훨씬 정교하고 복잡한 네트워크 관리를 가능하게 한다. CMIP는 객체 지향적인 구조를 채택하고 있으며, 네트워크 장비를 다양한 속성과 동작을 가진 객체로 모델링하여, 훨씬 유연하고 강력한 관리 기능을 제공한다.

CMIP는 정보를 조회하는 수준을 넘어서 객체를 생성하거나 삭제할 수 있으며, 특정 조건에 따라 이벤트를 필터링하는 등 고급 기능도 지원된다. 보안 측면에서도 우수하여 인증이나 접근 제어 기능이 내장되어 있다.

그러나 이러한 고급 기능으로 인해 구현의 복잡도가 높아졌고, 처리 비용도 상대적으로 크기 때문에 실제 산업 현장에서는 사용되지 않는다. 현재 대부분의 네트워크 장비는 CMIP보다 단순하고 효율적인 SNMP를 기본으로 지원한다.

[소프트웨어 공학] - 코딩 (Coding)

shineast_ — Thu, 8 May 2025 10:12:18 +0900

코딩 작업 (Coding Work)

설계가 완성되면 코딩 작업이 시작된다. 모듈에 대한 원시 코드를 작성하고 문서화하는 단계이다. 코딩 작업은 프로그래밍을 의미하며, 단순히 설계한 기능을 구현하는 일을 넘어 가독성을 높이고 유지보수를 편하게 하는 관점으로도 작업해야 한다. 즉, 코딩 단계에서는 품질 향상을 위한 다각도의 노력이 필요하다.

작업 과정

분석 단계, 설계 단계에서 완성된 작업물들을 가지고 코딩 단계에서는 다음의 순서를 통해 프로그래밍을 진행한다.

원시코드를 같은 스타일로 만들기 위해 코딩 표준을 만든다.
아키텍처 설계 결과 프레임워크 패키지와 응용 패키지를 결정한다. (프레임워크 패키지는 응용 패키지가 완성되기 전에 구현되어야 함)
패키지 내의 각 클래스에 대해 요구 사항과 상세 결과를 반영하여 메서드를 코딩한다.
클래스 구현이 끝나면 곧바로 설계나 코드의 결함을 찾는 인스펙션 과정을 진행한다.
클래스 단위로 테스트하고, 클래스나 패키지를 릴리스하여 응용 시스템으로 통합한다.

자주 발생하는 오류

코딩 과정에서는 버그를 찾고 해결하는데 많은 시간을 할애하게 된다. 소프트웨어 개발 시, 잘못된 데이터는 예상치 못한 문제를 일으킬 수 있다. 이러한 에러 처리를 위한 작업들은 매우 중요하다.

`메모리 누수(Memory Leak)`: 동적으로 할당된 메모리를 해제하지 않아 사용되지 않는 메모리가 계속 남아 있는 현상으로 장기 실행 프로그램에서 심각한 성능 저하를 일으킨다.
`중복된 프리 선언(Double Free Error)`: 이미 해제된 메모리를 다시 해제하려고 할 때 발생하는 오류로 프로그램 충돌이나 예측 불가능한 동작을 유발할 수 있다.
`NULL의 사용(Null Pointer Dereference)`: NULL 포인터를 참조하거나 접근하려고 할 때 발생하는 오류이다.
`별칭 남용 (Alias Misuse)`: 포인터나 참조가 동일한 메모리를 가리킬 때, 한 곳에서 변경한 값이 다른 곳에 예상치 못하게 영향을 줄 수 있다.
`배열 인덱스 및 수식 예외 오류`: 배열 범위를 초과하거나 수식 계산 중 예외(예: 0으로 나누기)가 발생하는 오류. 메모리 접근 위반이나 논리 오류의 원인이 된다..
`사용자 정의 자료형 오류(Custom Type Error)`: 구조체(struct), 클래스(class) 등을 잘못 설계하거나 사용할 때 생기는 오류이다. 초기화 누락, 잘못된 접근 등 다양한 원인이 있다.
`스트링 처리 오류(String Handling Error)`: 문자열을 복사, 결합, 파싱할 때 경계값을 넘거나 종료 문자를 누락하는 등의 실수로 발생한다. 보안 취약점과도 연결된다.
`버퍼 오버플로우 오류(Buffer Overflow)`: 제한된 버퍼 공간보다 많은 데이터를 입력하거나 저장하려 할 때 발생하며 프로그램 충돌이나 악성 코드 실행의 원인이 될 수 있다.
`동기화 오류(Synchronization Error)`: 멀티스레드 환경에서 공유 자원 접근이 적절히 조율되지 않아 발생하는 오류이다. 경쟁 조건(Race Condition), 데드락(Deadlock) 등이 포함된다.

코딩 표준 (Coding Standard)

프로그래머들에게는 각자 코딩에 있어서 일관된 유형을 가지는데, 이를 코딩 스타일이라고 한다. 좋은 코딩 스타일은 딱 잡아서 정의하기는 어렵지만 좋은 스타일인지 아닌지 판별하는 기준은 “코드가 간결하고 읽기 쉬운가?”이다. 즉, 코드가 명확하고 복잡하지 않아 이해하기 쉽다는 것이다. 다음의 원칙들을 지킴으로 좋은 가독성을 지닌 코드를 작성할 수 있다.

명명 규칙 (Naming Convention)

프로그램 안에 여러 요소들에 이름을 붙이는 것은 매우 중요한데, 일정한 규칙에 따라 명확한 의미를 가지는 이름을 작성하면 협업이 쉬워지고 가독성이 높은 코드를 작성할 수 있다. 주요 명명 규칙 스타일은 다음과 같다.

카멜 표기법(camelCase): 첫 단어는 소문자, 이후 단어는 대문자로 시작한다. Ex: `userName`, `getUserInfo()` JavaScript, Java, TypeScript에서 변수나 함수 이름에 주로 사용한다
파스칼 표기법(PascalCase): 모든 단어의 첫 글자를 대문자로 설정한다. Ex: `UserInfo`, `MainComponent` 클래스 이름, 생성자 함수 등에서 자주 사용한다
스네이크 표기법(snake_case): 모든 글자를 소문자로 쓰고, 단어는 밑줄(_)로 구분한다. Ex: `user_name`, `total_count` Python, 일부 C 프로젝트에서 변수나 함수에 주로 사용한다.
케밥 표기법(kebab-case): 단어를 하이폰(-)으로 연결한다. Ex: `main-header`, `user-profile` 주로 HTML 클래스나 CSS 선택자 이름에 사용한다.

프로그래밍 내의 여러 요소에 대해 이름을 붙이는 방법은 다음과 같다. 다만, 이는 정답이 아니며 단지 예시일 뿐이다.

클래스와 인터페이스 이름: 일반적으로 명사 또는 명사구이며, 파스칼 표기법을 따른다.
메서드 이름: 일반적으로 카멜 표기법을 따르고, 프로시저는 실행하라는 명령문이기에 동사구로 표현하고 (Ex: `public void setTitle(String t) {...}`), 함수는 값을 생성하기에 명사구로 표현한다(Ex: `public double areaOfRectangle(int x, int y) {...}`),
변수 이름: 일반적으로 소문자로 표시한다. 변수 이름은 변수의 용도에 대한 힌트를 잘 제공해야 한다. 구체적인 이름을 사용하는 것이 좋다.
상수 이름: 상수는 모두 대문자로 표시하고, 단어는 밑줄로 구분한다. (Ex: `public static final double SPEED_OF_LIGHT = 299792458`)
패키지 이름: 일반적으로 모두 소문자이며, 명사로 정한다.

일관된 형식

프로그램 내에서 일관된 형식에 대한 규칙을 정의하고, 그 규칙대로 코드를 작성해야 한다. 대표적인 일관된 형식으로는 “들여쓰기”와 “괄호 사용”이 있다. 들여쓰기와 괄호 사용은 프로그램 구조를 명확하게 하기 위하여 사용한다. VSCode나 IntelliJ 등 많은 IDE에서는 들여쓰기와 괄호 사용을 지원하여 일관되게 형식을 둘 수 있다.

프로그램에서 되풀이되느 문장이나 수식은 메서드나 클래스로 패키지화하는 것이 좋다. 제어흐름을 나타내는 구조에서는 수식을 사용하는 것보다 블록 문장을 사용하는 것이 좋다. 이 또한 괄호 사용에 해당하는 것인데, 제어구조가 중첩되는 경우 블록 문장을 사용하면 혼란을 줄일 수 있다. 수식 내에서도 괄호(소괄호)를 사용하면 오퍼레이션의 순서를 명확히 할 수 있다.

주석 (Comment)

프로그램을 작성하고 디버깅하는 중간마다 주석을 다는 것은 중요하다. 다른 사람들이 프로그램을 이해하기 쉽도록 프로그램을 잘 문서화해야 한다. 프로그램이 잘 문서화가 되면 유지보수가 쉽다. 주석의 종류는 다음과 같다.

한 줄 주석 (Single-Line Comment)

특정 코드 라인에 대한 간단한 설명에 사용한다.

// 사용자의 입력값을 검증함
const isValid = validateInput(input);

블록 주석 (Block Comment)

여러 줄에 걸쳐 설명할 때 사용한다.

/*
  이 함수는 사용자 데이터를 가져와서
  프로필 화면에 표시하는 역할을 합니다.
  서버 응답이 실패할 경우 예외를 발생시킵니다.
*/
function fetchUserData() {
  ...
}

문서 주석 (Documentation Comment)

함수, 클래스, 메서드 등의 사용법을 문서화하는 데 사용한다. JavaScript/TypeScript에서는 JSDoc, Java에서는 JavaDoc, Python에서는 docstring을 사용한다.

/**
 * 두 수를 더하는 함수
 * @param a 첫 번째 숫자
 * @param b 두 번째 숫자
 * @returns 두 수의 합
 */
function add(a: number, b: number): number {
  return a + b;
}

좋은 주석의 기준은 다음과 같다.

기준	설명
What 보다는 Why	코드는 무엇을 하는지보다 왜 그렇게 했는지 설명하는 게 더 중요하다
구체적이고 간결해야 함	너무 장황하거나 추상적인 설명은 오히려 해롭다
코드 변경 시 주석도 반드시 수정	주석이 실제 코드와 달라지면 혼란을 초래한다
중복 설명 금지	코드로 명확한 내용은 주석으로 반복하지 않는다

리팩토링 (Refactoring)

리팩토링은 이미 존재하는 코드의 디자인을 안전하게 향상시키는 기술로, 문제가 될 수 있는 코드를 여러 측면에서 향상시킨다. 이때, 코딩 스타일 뿐만 아니라 성능과 구조를 개선한다. 좋은 설계가 되도록 코드를 개선시키는 것이 리팩토링이다.

결국 리팩토링의 목적은 다음과 같다.

구조가 망가지지 않도록 디자인을 유지하면서 동시에 소프트웨어의 디자인을 개선시킨다.
소프트웨어를 이해하기 쉽도록 만든다.
버그를 더 잘 찾을 수 있도록 한다.
프로그램 작성을 더 빠르게 할 수 있도록 한다. 즉, 개발 속도가 빨라진다.

리팩토링 과정

리팩토링 과정은 다음의 순서대로 이루어진다.

소규모의 변경 - 단일 리팩토링
코드가 모두 잘 작동되는지 테스트
전체가 잘 작동하면 다음 리팩토링 단계로 넘어간다.
코드가 잘 작동하지 않으면 문제를 먼저 해결하고 리팩토링한 것을 undo하여 시스템이 작동되도록 유지한다.

이 과정을 반복하여 코드를 개선하며 문제를 해결한다.

코드 스멜 (Code Smell)

리팩토링은 프로그램에 대한 작업을 어렵게 만드는 것을 찾아 고치고 다듬어 나가는 것이다. 이때, 리팩토링 대상을 “코드 스멜”이라고 한다. 말 그대로 나쁜 코드의 냄새라는 것이다. 코드 스멜이 될 수 있는 요소들과 그에 대한 리팩토링 방법은 다음과 같다.

코드 스멜	설명	리팩토링 기법 및 설명
Long Method (긴 메서드)	하나의 메서드가 너무 많은 일을 하며 코드 길이가 지나치게 길다	Extract Method 메서드를 여러 개의 작은 메서드로 나눠서 가독성과 재사용성을 높인다
Large Class (거대한 클래스)	클래스에 너무 많은 책임이 집중되어 복잡도가 높아진다	Extract Class 클래스의 책임을 나누어 새로운 클래스로 분리한다
Feature Envy (기능 질투)	어떤 메서드가 자기 클래스보다 다른 클래스의 데이터를 더 많이 사용한다	Move Method 해당 메서드를 관심 있는 데이터를 가진 클래스로 옮긴다
Data Clumps (데이터 덩어리)	항상 같이 다니는 변수 묶음이 반복적으로 나타난다	Introduce Parameter Object 관련 변수들을 하나의 객체로 묶는다
Primitive Obsession (기본형 집착)	문자열, 숫자 등 원시 타입을 과도하게 사용한다	Replace Primitive with Object 의미 있는 객체로 대체해 표현력과 안정성을 높인다
Switch Statements (조건문 남용)	여러 곳에 중복된 if-else나 switch 문이 존재한다	Replace Conditional with Polymorphism 조건문 대신 다형성(상속, 전략 패턴 등)을 활용한다
Speculative Generality (쓸데없는 일반화)	현재는 사용하지 않지만 미래를 대비해 만든 코드 구조가 존재한다	Collapse Hierarchy 불필요한 추상 클래스나 인터페이스를 제거한다
Temporary Field (임시 필드)	특정 조건에서만 사용되는 필드가 클래스에 존재한다	Extract Class 조건부 데이터를 별도의 클래스로 분리한다
Message Chains (메시지 체인)	a.b.c.d처럼 체인 형식으로 객체에 계속 접근한다	Hide Delegate 중간 객체를 숨기기 위해 위임 메서드를 만들어 캡슐화한다
Middle Man (중개자 남용)	클래스가 대부분 다른 객체에 대한 호출만 전달한다	Remove Middle Man 직접 접근하도록 하여 중복 위임을 제거한다
Inappropriate Intimacy (부적절한 친밀감)	클래스 간 내부 구현에 과도하게 의존한다	Move Method/Field 책임을 적절한 위치로 옮겨 결합도를 낮춘다
Duplicate Code (중복 코드)	비슷하거나 동일한 코드가 여러 곳에 반복된다	Extract Method 중복된 코드를 하나의 메서드로 통합한다
Shotgun Surgery (산탄총 수술)	하나의 변경이 여러 클래스나 파일을 동시에 수정하게 만든다	Move Method/Field 관련 기능을 한 클래스에 모아서 변경 범위를 줄인다
Divergent Change (산발적 변경)	하나의 클래스가 여러 이유로 자주 변경된다	Extract Class 변경 이유에 따라 클래스를 분리하여 단일 책임을 유지한다
Lazy Class (게으른 클래스)	너무 적은 기능만 가진 클래스가 존재한다	Inline Class 해당 클래스를 다른 클래스에 통합한다
Comments (불필요한 주석)	코드 자체로 설명될 수 있는 내용을 주석으로 설명하고 있다	Rename/Extract 주석이 필요 없도록 변수명이나 메서드를 명확하게 바꾼다

코드 품질 향상 기법

코드를 작성한 이후, 다른 곳에서 사용되기 전에 오류가 없는지 검사하고 테스트해야 한다. 즉, 코드의 품질을 향상시키는 좋은 방법은 바로 “테스트”이다. 그러나 이외에도 여러 가지 코드 품질 향상 기법들이 있는데 다음과 같다.

인스펙션 (Inspection)

인스펙션은 설계든 코드든 결함을 찾아내고 이를 확인하는 작업이다. 즉, 사전에 정해진 절차에 따라 팀원들이 함께 소프트웨어 산출물을 검토하는 품질 관리 기법이다. 이를 통해 버그나 설계상의 오류, 코딩 스타일 위반, 요구사항 미반영 등의 문제를 개발 초기에 발견할 수 있다.

인스펙션의 특징은 다음과 같다.

`목적`: 오류 발견, 품질 향상, 문서 일관성 확보
`검토 대상`: 소스코드, 설계서, 요구사항 명세서, 테스트 케이스 등
`검토 방식`: 개발자가 아닌 검토자들이 직접 읽고 분석한다.
`도구 사용 여부`: 보통 사람 중심이지만, 정적 분석 도구와 병행할 수도 있다.
`공식성`: 비공식 코드 리뷰와 달리, 정해진 절차와 역할이 있음

정적 분석 (Static Analysis)

정적 분석은 프로그램 텍스트를 조직적으로 분석하여 결함을 찾아내는 과정이다. 프로그램을 실제로 실행하지 않고, 소스 코드나 중간 코드 등을 분석하며, 컴파일 전에 코드의 구조, 문법, 스타일, 보안 취약점 등을 자동으로 점검할 수 있다.

정적 분석은 소프트웨어 도구를 사용하여 자동으로 할 수 있다. 대표적인 정적 분석 도구는 다음과 같다.

정적 분석 도구	언어	특징
SonarQube	Java, JS, Python 등 다수	코드 품질과 보안 점검에 특화된 통합 분석 플랫폼
ESLint	JavaScript	문법 오류, 스타일 위반 탐지
Pylint / Flake8	Python	PEP8 스타일, 코드 오류 점검
Cppcheck	C/C++	런타임 오류 없이 정적 분석 가능
FindBugs / SpotBugs	Java	바이트코드 수준에서 버그 탐지
Infer (by Meta)	Java, C, C++ 등	Null pointer, memory leak 자동 분석

테스트 중심 개발 (TDD: Test-Driven Development)

일반적으로는 프로그램을 작성하고 테스팅을 하지만 테스트 중심 개발은 테스트를 위한 코드를 먼저 작성하고 기능을 구현하도록 요구한다. 테스트는 주로 클래스 내의 메서드를 시험하는 “단위 테스팅”을 위한 것이다. TDD 진행 과정은 다음과 같다.

TDD를 준비한다: 개발하려는 프로그램의 뼈대를 만들고 테스트 커버리지 수준을 결정한다.
테스트 코드를 작성한다: 구현할 기능을 정하고 동시에 기능을 테스트할 방법을 설계하고 코딩한다.
반복하여 기능을 구현하고 테스트한다: 미리 작성한 테스트 코드에 의해 통과될 수 있도록 기능을 조금씩 정확하게 구현한다. 테스트를 통과할 때까지 코드를 발전시키고 테스트를 수행한다.
테스트 커버리지 측정: 테스트가 수행되어 프로그램의 실행이 확인된 비율을 측정하여 원하는 수준에 미치지 못하면 테스트 케이스를 추가한다. 추가한 테스트 코드를 사용하여 프로그램을 테스팅하여 원하는 수준의 커버리지에 도달하면 종료된다.

TDD의 구성 요소는 다음과 같다.

`단위 테스트(Unit Test)`: 가장 작은 단위(함수, 메서드 등)의 동작 검증
`테스트 프레임워크`: Jest, JUnit, PyTest 등 언어에 맞는 테스트 도구 사용
`Mocking / Stubbing`: 외부 API나 DB와 같은 의존 요소를 대체하여 테스트 수행

TDD의 장단점은 다음과 같다.

(장점) 요구사항 기반 개발 가능 (정확한 기능 정의)
(장점) 코드의 결함 감소 및 품질 향상
(장점) 문서 역할을 하는 테스트 코드 자동 생성 및 자동화된 테스트 커버리지 확보
(단점) 초기 학습 곡선이 높고 개발 속도가 느리다
(단점) 잘못된 테스트 작성 시 잘못된 설계 유도 가능

[소프트웨어 공학] - UI 설계 (User Interface Design)

shineast_ — Wed, 7 May 2025 15:02:26 +0900

UI 기본 개념 (Concept of User Interface)

UI 설계(User Interface Design, 사용자 인터페이스 설계)는 사용자가 제품을 쉽게 이해하고, 효과적으로 사용할 수 있도록 시각적이고 인터랙티브한 요소를 구성하는 작업이다. UI 구성 요소들은 사용자와 시스템 간의 정보를 교환하고 조정하는 수단이 되기에, 소프트웨어를 이해하기 쉽고 효율적으로 사용할 수 있도록 구성해야 한다.

사용성 (Usability)

UI 설계 결과는 소프트웨어의 비기능적 품질 중 “사용성”을 좌우한다. 이때, 사용성이란 일반적으로 시스템이 얼마나 사용하기 편한지를 나타내는 척도이다. 인간과 컴퓨터 상호 작용을 개선하기 위한 방법, 기술을 포함하는 사용의 용이성에 대한 연구를 설묭하는 용어로도 쓰인다.

사용성에 영향을 주는 요소는 다음과 같다.

`학습용이성(Learnability)`: 처음 사용하는 것이 얼마나 쉬운가에 대한 척도
`효율성(Efficiency)`: 작업 수행 방법을 배운 사용자가 작업을 쉽게 수행할 수 있어야 함
`기억용이성(Memorability)`: 애플리케이션을 오랫동안 사용하지 않고 다시 사용하더라도 동작 방식이 쉽게 기억 나야 함.
`낮은 오류율`: 오류가 거의 없어야 하며, 오류가 발생하더라도 쉽게 복구되어야 함

멘탈 모델 (Mental Model)

멘탈 모델을 현실 세계의 사물이나 과정이 어떻게 작동하는지에 대한 개인의 이해이다. 이는 사용자의 행동 결과와 특정 작업을 수행하는데 필요한 행동을 예측할 수 있도록 한다. 멘탈 모델은 소프트웨어 사용에서도 중요한데, 잘못된 멘탈 모델로 접근하게 되면 프로그램 작동이 어려워지게 된다.

개발자는 사용자의 멘탈 모델을 중심으로 디자인해야 한다. 이는 사용자의 UI 학습 곡선을 완만하게 하며 이를 통해 빠른 적응을 이끌 수 있다.

피드백 (Feedback)

사용자는 명령에 대한 진행 상황과 입력 내용을 해석하는 방법을 알고 싶어한다. 피드백은 시스템 상태와 사용자의 지시에 대한 효과를 보여준다. 대표적으로 Spinner와 같은 Loading UI는 웹페이지가 로딩되고 있음을 나타낸다.

피드백은 반응한 시간에 따라 다르게 줄 수 있다. 0.1초 내에 수행되는 작업을 사용자에게 즉각적인 것처럼 보이기에 피드백을 줄 필요가 없으며, 0.1~1.0초 정도 걸리는 작업은 지연이 느껴지지만 특별한 피드백이 필요하지 않다.

그러나 1초 이상 지속되는 작업에 대한 응답은 피드백을 제공하는 것이 유익하다. 회전구, 바퀴 등의 애니메이션 아이콘은 1초 이상 걸리는 작업에 대한 피드백으로 적합하다. 만약 10초 이상 지속되는 작업은 작업 소요 시간을 나타내는 진행 표시기(프로그레스 바)나 완료율 표시기가 적합하다.

제약 (Constraint)

일반적인 사용자들은 소프트웨어 사용 시 메뉴얼을 읽기 싫어하기에 직관적으로 파악 가능한 UI를 설계하는 것이 중요하다. 사용자들은 선택에 익숙하지 않기에 많은 옵션을 제공하는 것은 좋은 UI 설계 사례는 아니다. 또한 사용자를 두렵게 하는 경고 메세지나, 혼동을 유발하는 UI도 바람직하지 않다.

UI 설계 원리 (UI Design Principles)

UI는 단순히 관심을 끄는 것이 아니라 시스템 설계 목적을 달성하고 시스템 사용에 도움을 주는 것에 초점을 맞춘다. 따라서 UI 설계의 기본 원리를 잘 따라서 개발하는 것이 중요하다.

단순하고 자연스럽게 만들기

UI가 잘못 해석되지 않도록 추가로 설명하는 정보를 주지 않고 단순하게 하는 것이 좋다. 사용자에게 친숙한 단어와 개념들을 사용하고 미니멀리즘 디자인을 선호해야 한다.

안전한 사용과 오류 회복이 쉽게 하기

시스템을 사용하면서 탐색하는 과정 가운데 잘못된 결과를 피하도록 하고, 혹여나 사용자가 실수하더라도 큰 피해를 입지 않게 하고, 실수했을 때 쉽게 복구할 수 있도록 설계해야 한다. 실수 가능성이 있는 행동은 미리 경고하거나 방지 장치를 마련하고, 되돌리기(Undo)가 가능하도록 하는 것이 좋다. 또한 오류 메시지는 친절하게 작성하는 것이 좋다.

직접 조작하고 바로 피드백 받기

사용자가 어떤 대상에 대해 작업을 수행하는 경우, 해당 작업이 개체에 미치는 영향을 즉각적으로 나타나게 하는 것이 좋다. 파일 탐색기에서 파일을 선택하여 드래그할 때, 파일이 이동하는 것을 직접 느끼도록 UI를 구성하는 것이 “직접 조작하고 바로 피드백 받기”의 대표적인 예시이다.

일관성을 유지하기

UI가 일관성을 가져야 사용자는 이전에 사용해 본 지식과 경험을 토대로 다른 소프트웨어에서도 쉽게 사용할 수 있다. 사용자의 기대와 일치하는 일관성에 충돌이 생기면 좁은 범위 일관성은 넓은 범위 일관성보다 우선된다. 결국, 이를 위해서는 플랫폼 규약 및 표준을 따르고 표준 요소들을 사용하는 것이 중요하다.

즉각적으로 만족시키기

사용자는 소프트웨어 사용 후 몇 초 내에 어느 정도의 성공을 거두어야 만족한다. 따라서 즉각적인 만족으로 사용자에게 신뢰감을 주는 것이 좋다. 사용자가 원할 만한 작업을 먼저하고 프로그램 설정하는 쉬운 일은 나중에 하는 것이 좋다.

단축 명령 제공하기

다양한 사용자를 수용하기 위해서는 단축 명령을 제공하는 것이 좋다. 전문 사용자들을 효율적으로 작업하는데 관심이 많기 때문이다. “바로 가기” 등을 활용하며 효율적으로 사용하게 하는 것이 좋다. 그러나 전문 사용자를 지원하기 위해 UI를 구성하더라도 초보 사용자에게 부정적인 영향을 미치지 않도록 해야 한다.

인식하기 쉽게 만들기

대부분의 사용자들은 복잡한 인터페이스를 분석할 시간, 에너지, 인내심이 없다. 따라서 사용자는 잘 읽지 않고 긴 시간을 투자하지 않음을 기억하고 UI를 설계해야 한다. 설명서가 필요 없는 UI를 위해서 노력하고, 설명서나 도움말을 최후의 수단이 되어야 한다.

공간 기억을 활용하기

사람들은 의식적/무의식적으로 공간 기억을 사용하여 UI의 개체나 명령을 찾아가는 경향이 있다. UI의 요소나 메뉴 옵션을 다시 정렬하면 위치를 기억하는 공간 메모리가 손상될 수 있다. 따라서 일관성을 갖추고 공간 기억을 활용하는 UI를 설계하는 것이 좋다.

접근성을 고려하기

UI 접근성이 좋은 시스템은 사용자를 넓히고 사용자 경험(UX)을 풍요롭게 한다. 장애인 등의 접근성을 높이는 것은 소프트웨어의 경쟁력을 높인다.

UI 설계 과정 (UI Design Process)

UI를 설계하기 위해야 할 작업들은 다음과 같다.

사용자 분석

UI 설계자는 소프트웨어를 사용할 사용자를 분석한다. 사용자의 지식 및 역량 수준에 따라 디자인 세부 사항이 변경되기에 사용자 분석은 중요하다. 사용자의 목표는 무엇인지, 사용 스킬과 경험은 무엇인지에 대한 질문을 고려하는 것은 UI 설계 전략을 세우는데 도움이 된다.

태스크 분석

UI를 설계하려면 소프트웨어가 수행해야 할 작업을 분석해야 한다. 유스케이스 별로 UI 흐름을 파악하는 것이 중요하며, UI 흐름은 하나의 주요 작업을 더 작은 하위 작업으로 나누는 계층적 방식으로 표현된다.

UI 설계 구현

UI 작업에 대한 정보를 얻고 GUI를 디자인하고 코드로 구현한다. UI 설계 과정에서 자주 사용되는 개념은 다음과 같다.

`마법사(Wizard)`: 미리 저장된 순서로 사용자가 절차를 쉽게 따라오도록 안내한다.
`사이트 이동경로(Breadcrumbs)`: 웹사이트나 애플리케이션에서 사용자의 위치를 표시하는 내비게이션
`메타포(Metaphor)`: 사용자의 개념적 인식 모델을 말한다. 이를 통해 사용자가 개념적 인식 방식으로 프로그램의 작동을 예측하고 조작한다.

사용성 테스트

UI 설계 과정에서 사용자가 실제로 인터페이스를 어떻게 사용하는지 관찰하고, 문제점을 찾아 개선하기 위해 수행하는 테스트이다. 사용자 테스트는 다음의 절차에 따라 진행된다.

`테스트 목적 설정`: UI 테스트의 목적을 명확히 한다. 학습성, 오류율, 예측성 등의 사용자의 여러 측면에서 상대적 우선 순위가 무엇인지 결정한다.
`대표 사용자 선정`: 대표적인 사용자 샘플을 찾는다.
`설문 준비 및 테스트`: 테스트 대상을 준비하고 사전/사후 테스트 설문지 및 작업 시나리오를 정의하여 참가자에게 수행하도록 요청한다. 사용성 테스트를 수행하고 데이터를 기록하며, 수행한 테스트의 데이터와 관찰 결과를 분석한다.

UI 요소 (UI Components)

UI는 시스템과 상호 작용하기 위한 그래픽 요소들을 제공한다. 그래픽 UI 요소를 사용하여 소프트웨어를 해석하고 사용한다. GUI(Graphic User Interface)는 소프트웨어와 상호작용하기 위해서 구성 요소를 제공한다. 이는 단순히 예쁜 그림이 아니라, 기능성과 미적 균형을 함께 갖춘 중요한 UI 구성 요소이다. GUI에는 다음과 같은 요소들이 사용된다.

`윈도우(Window)`: 프로그램이나 애플리케이션의 독립된 작업 영역. 일반적으로 사용자가 정보를 입력하거나 기능을 수행할 수 있는 창을 의미함. 예: 설정 창, 팝업 창 등.
`탭(Tab)`: 하나의 화면 안에서 여러 내용을 구분해 보여줄 수 있는 요소. 사용자가 클릭하면 콘텐츠 영역이 전환됨. 예: 브라우저의 탭, 설정 페이지의 탭 메뉴.
`메뉴(Menu)`: 사용자가 선택할 수 있는 기능이나 옵션 목록. 드롭다운, 햄버거 메뉴, 사이드 메뉴 등이 포함됨.
`아이콘(Icon)`: 기능이나 의미를 직관적으로 표현한 작은 그래픽. 예: 휴지통, 설정, 홈 아이콘 등.
`커서(Cursor)`: 사용자가 현재 어디에 있는지 보여주는 지시자. 마우스 커서, 텍스트 입력 커서 등이 있음.
`명령 버튼(Command Button)`: 특정 동작을 실행하는 버튼. 예: 저장, 제출, 확인, 취소 등.
`다이얼로그(Dialog)`: 사용자에게 정보를 전달하거나 확인/입력을 요구하는 팝업 창. 예: 경고창, 파일 열기 창.
`텍스트 박스(Text Box)`: 사용자가 텍스트를 입력할 수 있는 필드. 예: 검색창, 로그인창의 아이디/비밀번호 입력란.
`토글 버튼(Toggle Button)`: 두 가지 상태(예: 켜기/끄기)를 전환할 수 있는 버튼. 상태 유지형 버튼이라고도 함.
`리스트 박스(List Box)`: 여러 항목 중에서 하나 또는 여러 개를 선택할 수 있는 박스 형태의 목록.
`드롭다운 리스트(Dropdown List)`: 사용자가 선택할 수 있는 항목이 숨겨져 있다가 클릭 시 펼쳐지는 형태의 목록.
`라디오 버튼(Radio Button)`: 여러 항목 중 하나만 선택 가능할 때 사용하는 원형 버튼.
`체크 박스(Checkbox)`: 여러 항목 중 복수 선택 가능할 때 사용하는 네모난 체크용 UI 요소.

화면 및 출력 설계

화면 설계

화면 설계는 사용자가 시스템과 직접 상호작용하는 화면(UI)을 어떻게 구성할지 설계하는 과정이다. 사용자가 시스템을 쉽고 편리하게 사용할 수 있게 하며, 입력, 탐색, 클릭, 이동 등 사용자 행동 흐름을 고려한 화면 구성해야 한다.

출력 설계

출력 설계는 시스템이 사용자에게 보여주는 최종 결과물(출력 정보)을 어떻게 제시할지 설계하는 과정이다. 정보를 명확하고 이해하기 쉽게 전달하는 것이 목표이며, 사용자나 관리자 등이 보고 판단할 수 있도록 구성해야 한다.

[소프트웨어 공학] - 디자인 패턴 (Design Pattern)

shineast_ — Tue, 6 May 2025 11:59:36 +0900

디자인 패턴 (Design Pattern)

디자인 패턴이란 아키텍처 설계 수준보다 낮은 수준의 설계 문제를 효과적으로 해결하기 위한 “재사용 가능한 솔루션”이다. 디자인 패턴이 적용되는 절차는 다음과 같다.

요구 사항을 고려하여 아키텍처를 확정한다.
아키텍처의 컴포넌트들을 구현하는 클래스의 역할과 동작을 결정한다.
발생하는 설계 이슈에 대해 솔루션으로 적합한 디자인 패턴을 적용하고 개선시킨다.

디자인 패턴의 혜택

디자인 패턴을 사용하면 누리게 되는 혜택은 다음과 같다.

쉽게 재사용이 가능하다.
설계 작업이 쉬워진다.
설계 관련 지식이 정리된다.
설계를 논의하기 위한 의사소통이 쉬워진다.
객체지향 설계 원리를 잘 따르게 된다.

디자인 패턴의 형식

소프트웨어 디자인 패턴을 설명하는 일관되는 형식이 존재한다. 디자인 패턴을 서명할 때 사용되는 형식은 다음과 같다.

`패턴 이름`: 짧은 설명과 이름은 의사소통을 촉진하고 디자인 아이디어를 논의하기 위한 어휘를 제공한다.
`소개`: 각 디자인 패턴에 대한 설명은 배경을 정의하고 패턴을 학습하는 동기를 제공하는 소개로 시작한다.
`해결하는 문제`: 해당 디자인 패턴으로 해결되는 설계 이슈에 대해 설명한다.
`솔루션`: 솔루션은 디자인 패턴의 본질로, 디자인 문제를 해결하기 위한 해법이기에 디자인 패턴은 실행 코드보다 추상적인 설계 조각이다.
`예제`: 디자인 패턴은 추상적 해법이기에, 특정 예제에 적용된 것을 보며 이해를 높인다.
`관련 패턴`: 한 패턴이 다른 패턴을 완전히 포함하거나, 비슷한 문제를 해결할 수 있다. 따라서 유사한 패턴이 있는 경우 구분하기 위한 설명이 추가된다.

싱글톤 패턴 (Singleton Pattern)

해결하려는 문제

싱글톤 패턴은 다음과 같은 상황에서 발생하는 문제를 해결하고자 한다:

클래스의 인스턴스가 단 하나만 존재해야 하는 경우
여러 곳에서 해당 인스턴스에 대한 일관된 접근이 필요한 경우
전역 상태를 관리해야 하지만, 전역 변수를 사용하면 안 되는 경우

솔루션

싱글톤 패턴은 다음과 같은 방식으로 문제를 해결한다:

클래스의 생성자를 private으로 선언하여 외부에서 인스턴스 생성을 막는다
클래스 내부에 자신의 인스턴스를 private static으로 보관한다
public static 메서드를 통해 단일 인스턴스에 대한 접근점을 제공한다
처음 호출될 때만 인스턴스를 생성하고, 이후에는 이미 생성된 인스턴스를 반환한다

구현 사례

public class Singleton {
    // private static 인스턴스 변수
    private static Singleton instance;
    
    // private 생성자
    private Singleton() {}
    
    // public static 접근 메서드
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

실제 활용 사례

데이터베이스 연결 관리자: 애플리케이션에서 단일 데이터베이스 연결을 유지하고 관리
설정 관리자: 애플리케이션의 환경 설정을 중앙에서 관리
로깅 시스템: 로그 기록을 중앙에서 일관되게 관리
프린터 스풀러: 프린터 작업을 중앙에서 관리하고 조정

반복자 패턴 (Iterator Pattern)

해결하려는 문제

반복자 패턴은 다음과 같은 상황에서 발생하는 문제를 해결하고자 한다:

컬렉션의 내부 구조를 노출하지 않고 모든 요소에 순차적으로 접근해야 하는 경우
서로 다른 자료구조(배열, 리스트, 트리 등)에 대해 동일한 방식으로 순회해야 하는 경우
컬렉션의 순회 방식을 변경하거나 확장할 필요가 있는 경우

솔루션

반복자 패턴은 다음과 같은 방식으로 문제를 해결한다:

순회 동작을 별도의 반복자 객체로 캡슐화한다
컬렉션의 내부 구현과 상관없이 동일한 인터페이스로 접근할 수 있게 한다
hasNext()와 next() 같은 표준화된 메서드를 제공한다
여러 개의 반복자가 동시에 컬렉션을 순회할 수 있게 한다

구현 사례

public interface Iterator<T> {
    boolean hasNext();
    T next();
}

public class ArrayIterator<T> implements Iterator<T> {
    private T[] array;
    private int position = 0;
    
    public ArrayIterator(T[] array) {
        this.array = array;
    }
    
    public boolean hasNext() {
        return position < array.length;
    }
    
    public T next() {
        return array[position++];
    }
}

실제 활용 사례

Java의 Collection Framework: List, Set 등의 컬렉션에서 표준화된 반복자 제공
데이터베이스 결과셋 순회: JDBC ResultSet을 통한 쿼리 결과 순회
파일 시스템 탐색: 디렉토리와 파일을 순회하는 파일 탐색기
복합 객체 구조 순회: 트리나 그래프 같은 복잡한 자료구조의 순회

어댑터 패턴 (Adapter Pattern)

해결하려는 문제

어댑터 패턴은 다음과 같은 상황에서 발생하는 문제를 해결하고자 한다:

서로 다른 인터페이스를 가진 클래스들이 함께 동작해야 하는 경우
기존 코드를 수정하지 않고 호환되지 않는 인터페이스를 사용해야 하는 경우
레거시 시스템과 새로운 시스템을 통합해야 하는 경우

솔루션

어댑터 패턴은 다음과 같은 방식으로 문제를 해결한다:

기존 클래스를 감싸는 어댑터 클래스를 생성한다
클라이언트가 기대하는 인터페이스를 어댑터가 구현한다
어댑터 내부에서 기존 클래스의 메서드를 호출하여 변환 작업을 수행한다
클라이언트는 어댑터를 통해 기존 클래스의 기능을 이용한다

구현 사례

// 기존 인터페이스
interface MediaPlayer {
    void play(String filename);
}

// 변환이 필요한 클래스
class AdvancedMediaPlayer {
    void playMp4(String filename) {
        System.out.println("Playing mp4 file: " + filename);
    }
}

// 어댑터 클래스
class MediaAdapter implements MediaPlayer {
    private AdvancedMediaPlayer advancedPlayer;
    
    public MediaAdapter() {
        this.advancedPlayer = new AdvancedMediaPlayer();
    }
    
    public void play(String filename) {
        advancedPlayer.playMp4(filename);
    }
}

실제 활용 사례

외부 라이브러리 통합: 서로 다른 API를 연결하여 사용
레거시 시스템 통합: 오래된 시스템과 새로운 시스템 간의 인터페이스 변환
다양한 데이터 형식 처리: JSON, XML 등 다른 형식의 데이터를 변환하여 처리
하드웨어 인터페이스: 다양한 하드웨어 장치와의 통신을 위한 인터페이스 제공

데코레이터 패턴 (Decorator Pattern)

해결하려는 문제

데코레이터 패턴은 다음과 같은 상황에서 발생하는 문제를 해결하고자 한다:

객체의 기능을 동적으로 확장하고 싶은 경우
상속을 사용하지 않고 유연하게 기능을 추가하고 싶은 경우
클래스 수의 증가 없이 다양한 조합의 기능을 제공하고 싶은 경우

솔루션

데코레이터 패턴은 다음과 같은 방식으로 문제를 해결한다:

기본 기능을 정의한 인터페이스나 추상 클래스를 만든다
데코레이터는 해당 인터페이스를 구현하거나 상속한다
데코레이터는 원래 객체를 감싸고 있으며, 추가 기능을 제공한다
클라이언트는 데코레이터를 통해 객체에 확장된 기능을 적용한다

구현 사례

interface Printer {
    void print();
}

class Text implements Printer {
    public void print() {
        System.out.print("Hello");
    }
}

class Exclamation implements Printer {
    private Printer p;
    Exclamation(Printer p) { this.p = p; }
    public void print() {
        p.print();
        System.out.print("!");
    }
}

// 사용
public class Main {
    public static void main(String[] args) {
        Printer p = new Exclamation(new Text());
        p.print(); // 출력: Hello!
    }
}

실제 활용 사례

GUI 컴포넌트 꾸미기: 버튼, 스크롤바 등의 기능을 동적으로 추가
입출력 스트림: Java의 BufferedInputStream, DataInputStream 등
로깅 기능 추가: 객체 동작 전후에 로그 출력
기능 모듈화: 인증, 캐싱, 암호화 등을 유연하게 조합

팩토리 메서드 패턴 (Factory Method Pattern)

해결하려는 문제

팩토리 메서드 패턴은 다음과 같은 상황에서 발생하는 문제를 해결하고자 한다:

객체 생성 코드를 클라이언트 코드에서 분리하고 싶을 때
객체 생성 과정이 복잡하거나, 하위 클래스에 따라 다른 객체를 생성해야 할 때
코드 변경 없이 새로운 타입의 객체를 유연하게 추가하고 싶을 때

솔루션

팩토리 메서드 패턴은 다음과 같은 방식으로 문제를 해결한다:

객체 생성을 캡슐화한 팩토리 메서드를 정의한다
서브클래스에서 이 메서드를 오버라이드하여 원하는 객체를 생성하도록 한다
클라이언트는 구체적인 클래스 대신 팩토리 메서드를 통해 객체를 얻는다
이를 통해 객체 생성 로직을 변경하거나 확장하기 쉬워진다

구현 사례

// 제품 인터페이스
interface Product {
    void use();
}

// 구체적인 제품
class ConcreteProduct implements Product {
    public void use() {
        System.out.println("Using product");
    }
}

// 팩토리 클래스
abstract class Creator {
    abstract Product createProduct();
    
    public void operation() {
        Product p = createProduct();
        p.use();
    }
}

// 구체적인 팩토리
class ConcreteCreator extends Creator {
    public Product createProduct() {
        return new ConcreteProduct();
    }
}

public class Main {
    public static void main(String[] args) {
        Creator creator = new ConcreteCreator();
        creator.operation(); // 출력: Using product
    }
}

실제 활용 사례

Java의 Calendar.getInstance(), Connection.getConnection() 등
UI 컴포넌트 생성 시 테마나 플랫폼에 따라 다른 객체 반환
로그 시스템, 알림 시스템 등에서 다양한 구현체를 유연하게 교체

추상 팩토리 패턴 (Abstract Factory Pattern)

해결하려는 문제

추상 팩토리 패턴은 다음과 같은 문제를 해결하고자 한다:

관련된 객체들을 일관되게 생성해야 하는 경우 (ex. 버튼 + 입력창 세트 등)
구상 클래스에 의존하지 않고, 제품군을 생성하고 싶을 때
제품들의 호환성을 보장하면서 다양한 제품군을 지원하고 싶을 때

솔루션

추상 팩토리 패턴은 다음과 같은 방식으로 문제를 해결한다:

관련 객체들을 생성하는 팩토리 인터페이스를 정의한다
각 제품군에 대해 구체 팩토리 클래스를 만든다
클라이언트는 구체 클래스가 아닌 팩토리 인터페이스를 통해 제품을 생성한다
이를 통해 제품군 간의 호환성과 일관성을 유지할 수 있다

구현 사례

// 제품 인터페이스
interface Button { void click(); }

// 구체 제품
class MacButton implements Button {
    public void click() { System.out.println("Mac Button"); }
}

class WinButton implements Button {
    public void click() { System.out.println("Windows Button"); }
}

// 추상 팩토리
interface GUIFactory {
    Button createButton();
}

// 구체 팩토리
class MacFactory implements GUIFactory {
    public Button createButton() { return new MacButton(); }
}

class WinFactory implements GUIFactory {
    public Button createButton() { return new WinButton(); }
}

// 사용
public class Main {
    public static void main(String[] args) {
        GUIFactory factory = new MacFactory(); // 또는 new WinFactory()
        Button btn = factory.createButton();
        btn.click(); // 출력: Mac Button
    }
}

실제 활용 사례

UI 테마 변경: 다크 모드 / 라이트 모드 컴포넌트 일괄 생성
운영체제별 컴포넌트: Windows / macOS / Linux 용 UI 위젯
게임 아이템 생성: 종족 또는 클래스에 따라 무기, 방어구 등을 일괄 제공
테스트 환경 분리: 실제 서비스 객체 vs Mock 객체 팩토리로 전환

상태 패턴 (State Pattern)

해결하려는 문제

상태 패턴은 다음과 같은 문제를 해결하고자 한다:

객체의 내부 상태에 따라 행동이 달라지는 경우
조건문(if, switch)으로 상태별 동작을 처리하는 코드가 복잡하고 유지보수가 어려운 경우
상태 전환 로직과 동작을 분리하고 싶을 때

솔루션

상태 패턴은 다음과 같이 문제를 해결한다:

상태를 클래스로 캡슐화하여, 각 상태에 따른 동작을 클래스로 나눈다
컨텍스트 객체는 상태 객체에 위임하여 동작을 수행한다
상태 전환은 상태 객체 내부나 컨텍스트에서 명확하게 처리한다
조건문 없이도 상태에 따라 동작이 유연하게 바뀐다

구현 사례

// 상태 인터페이스
interface State {
    void handle(Context ctx);
}

// 상태 A
class OnState implements State {
    public void handle(Context ctx) {
        System.out.println("전원 ON");
        ctx.setState(new OffState());
    }
}

// 상태 B
class OffState implements State {
    public void handle(Context ctx) {
        System.out.println("전원 OFF");
        ctx.setState(new OnState());
    }
}

// 컨텍스트
class Context {
    private State state;
    public Context(State state) { this.state = state; }
    public void setState(State state) { this.state = state; }
    public void pressButton() { state.handle(this); }
}

// 사용 예
public class Main {
    public static void main(String[] args) {
        Context c = new Context(new OffState());
        c.pressButton(); // 전원 ON
        c.pressButton(); // 전원 OFF
    }
}

실제 활용 사례

UI 버튼 상태 관리: 활성/비활성/누름 상태에 따라 동작 변경
문서 편집기: 편집 모드 / 읽기 전용 모드 / 선택 모드 전환
게임 캐릭터: 걷기 / 점프 / 공격 / 죽음 상태에 따라 다른 행동
네트워크 연결: 연결됨 / 연결 중 / 끊김 상태에서 전송 방식 달라짐

옵서버 패턴 (Observer Pattern)

해결하려는 문제

옵서버 패턴은 다음과 같은 문제를 해결하고자 한다:

어떤 객체의 상태 변화에 따라 다른 객체들을 자동으로 갱신해야 하는 경우
객체 간의 느슨한 결합이 필요할 때
이벤트 기반 시스템에서 변경을 알리고 반응하는 구조가 필요할 때

솔루션

옵서버 패턴은 다음과 같이 문제를 해결한다:

주체(Subject)가 옵서버(Observer)들을 관리한다
상태가 변경되면 주체는 등록된 옵서버들에게 자동으로 알림을 보낸다
옵서버들은 주체와 직접 연결되지 않고, 인터페이스를 통해 느슨하게 연결된다

구현 사례

// 옵서버 인터페이스
interface Observer {
    void update(String msg);
}

// 주체 인터페이스
interface Subject {
    void addObserver(Observer o);
    void notifyObservers(String msg);
}

// 구체 주체
class NewsAgency implements Subject {
    private List<Observer> observers = new ArrayList<>();
    public void addObserver(Observer o) { observers.add(o); }
    public void notifyObservers(String msg) {
        for (Observer o : observers) o.update(msg); 
    }
 }
    
// 구체 옵서버
class NewsReader implements Observer {
    private String name;
    public NewsReader(String name) { this.name = name; }
    public void update(String msg) {
        System.out.println(name + " received: " + msg);
    }
}

// 사용 예
public class Main {
    public static void main(String[] args) {
        NewsAgency agency = new NewsAgency();
        agency.addObserver(new NewsReader("Alice"));
        agency.addObserver(new NewsReader("Bob"));
        agency.notifyObservers("Breaking News!");
    }
}

실제 활용 사례

GUI 이벤트 시스템: 버튼 클릭 시 여러 리스너에게 알림 전달
채팅 앱: 새로운 메시지가 오면 구독한 사용자에게 알림
모델-뷰(Model-View) 구조: 모델이 변경되면 뷰가 자동으로 갱신
파일 감시 시스템: 파일 변경 시 등록된 작업 수행

[소프트웨어 공학] - 아키텍처 설계 (Architecture Design)

shineast_ — Mon, 5 May 2025 11:59:04 +0900

아키텍처 개념 (Concept of Architecture)

아키텍처는 구성 요소와 구성 요소 간의 통신에 관한 것으로, 클래스 수준 이상의 그루핑, 역할, 인터페이스를 정의하는 작업이다. 아키텍처는 다양한 수준에서 구성 요소의 역할과 구성 요소 간의 관계에 집중한다. 소프트웨어 적용 분야에 따라 아키텍처 유형이 결정되고 스타일을 기초로 아키텍처의 뼈대를 구성하고 필요한 구성 요소들을 추가하며 배치한다.

소프트웨어 아키텍처는 소프트웨어 시스템에서의 높은 추상 수준의 구성 요소를 의미한다. 소프트웨어 시스템과 비기능적 품질 요구 사항을 충족시키기 위해 좋은 아키텍처를 구성하는 것이 중요하다.

아키텍처 역할

아키텍처는 시스템의 구조를 확립하는 소프트웨어 개발에서 중심축으로, 소프트웨어 개발의 모든 단계에 영향을 주는 초기 의사 결정의 핵심이다. 아키텍처의 역할은 다음과 같다.

`요구사항 분석`: 아키텍처에 제약사항을 반영한다.
`아키텍처 설계`: 컴포넌트와 인터페이스를 정의하고 시각화한다.
`상세 설계`: 아키텍처를 구성하는 컴포넌트의 내부를 설계한다.
`구현`: 컴포넌트를 구현한다.
`통합 및 시험`: 인터페이스를 시험한다.

아키텍처 표현

아키텍처 내의 불필요한 것들을 생략하고 중요한 문제에 관심을 집중시키려면, 아키텍처에서 컴포넌트를 블랙박스로 명시하고 외부에 보일 수 있는 구조적인 속성만 나타내야 한다.

이때, 아키텍처를 표현하는 가장 강력한 방법은 “계층적 분할”이다. 이는 표현된 컴포넌트를 상세 수준에 따라 더 자세히 나타내기 위해 분할하는 방법이다. 계층적으로 분할된 아키텍처는 수준에 따라 서로 다른 개발자들이 관심을 가지게 되고, 분석하고 설계하여 더 좋은 품질 목표를 설정할 수 있게 한다.

아키텍처 스타일 (Style of Architecture)

아키텍처 스타일이란 구성 요소 유형에 대한 설명, 런타임 제어, 데이터 전송에 대한 패턴을 나타낸 것으로, 아키텍처 유형을 정의하는 것이다.

클라이언트 서버형 아키텍처

클라이언트 서버 아키텍처는 컴퓨터 네트워크에서 역할을 “클라이언트”와 “서버”로 분리하여 구성하는 시스템 구조이다. 서버는 자원을 관리하며 클라이언트가 요청하는 기능이나 자원을 제공하고, 클라이언트는 사용자 시스템으로 자원의 사용을 위하여 서버를 접속하는 애플리케이션이다. 클라이언트와 서버는 물리적으로 다른 장소에 존재하여 원격 접근하여 통신한다.

클라이언트 서버형 아키텍처의 장단점은 다음과 같다.

(장점) `데이터 집중화`: 모든 데이터는 서버에 모아 데이터의 구성과 관리를 단순화할 수 있다.
(장점) `보안`: 클라이언트의 요청을 모니터링하고 기록할 수 있어서, 인증된 클라이언트만이 특정 서비스에 접근할 수 있도록 할 수 있다.
(단점) `병목`: 서버와 통신하려는 클라이언트가 증가하면 서버의 부하도 증가하여 네트워크 속도가 저하된다.
(단점) `비용`: 설치 및 관리 비용이 높다.
(단점) `비강인성`: 서버가 고장 나면 복구될 때까지 클라이언트는 작동할 수 없다.

계층형 아키텍처

계층형 아키텍처는 소프트웨어의 기능을 역할 별로 분리된 여러 층으로 분할하고, 기능이 명확하게 정해진 각 층 사이에서 메시지를 교환한다. 이때, 각 층은 인접한 층과만 메시지를 송수신한다. 대부분의 통신 시스템은 계층형 시스템을 따르며, 대표적으로 OSI 7 계층 모델이나, TCP/IP 모델이 계층형 시스템이다.

계층형 아키텍처의 장단점은 다음과 같다.

(장점) `추상화`: 시스템에 대해 좋은 추상적인 뷰를 제공하여, 각 층의 역할과 책임, 관계를 잘 이해할 수 있다.
(장점) `캡슐화`: 자세한 데이터들이 각 층 안에 캡슐화되어 층 사이에 가정하거나 이해해야 할 사항이 적다. 즉, 각 층의 응집이 높고 층 사이의 결합은 적다.
(장점) `재사용성`: 각 층의 의존도가 적어 쉽게 다른 모듈로 교환이 가능하며 다른 시스템에서 사용 가능하다.
(단점) `구성의 어려움`: 이웃 층과의 커뮤니케이션이 제한적이며 결합력이 낮기에 시스템을 계층으로 구성하는 것이 쉽지 않다.

이벤트 기반 아키텍처

이벤트 기반 아키텍처는 비동기 메시지인 이벤트 스트림을 생성하는 “이벤트 생산자”와 이벤트를 수신 대기하는 “이벤트 소비자”로 구성된다. 이벤트는 실시간으로 전달되고 발생 즉시 소비자는 이벤트에 응답할 수 있어야 한다. 이벤트 기반 아키텍처는 발생된 이벤트의 종류와 현재 시스템의 상태에 따라 다른 처리를 하는 상태 기반 처리로 주로 이루어진다.

이벤트 기반 아키텍처의 장단점은 다음과 같다.

(장점) 이벤트가 도착하는 즉시 소비자가 이벤트에 응답 가능하다.
(장점) `캡슐화`: 이벤트의 생산자와 소비자가 분리되어 캡슐화된다.
(장점) `확장성`: 시스템에 새로운 소비자를 쉽게 추가할 수 있다.
(단점) `복잡성`: 상태에 따라 복잡하고 정교한 제어가 필요하다.
(단점) `테스팅`: 각 상태에 허용된 이벤트가 제한적인 것을 정확히 테스트해야 한다. 허용되지 않은 이벤트에 대해서도 적절한 제어가 필요하다.

MVC (Model-View-Controller)

MVC는 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 스타일의 아키텍처이다. MVC는 응용 프로그램을 세 가지 구성요소로 나누며, 각각의 구성요소 사이에는 다음의 관계가 있다.

`컨트롤러(Controller)`: 모델에 명령을 내림으로 모델의 상태를 변경할 수 있다. 사용자의 요청을 받아 처리의 흐름을 제어한다.
`모델(Model)`:애플리케이션의 데이터와 비즈니스 로직을 담당한다. 데이터의 상태에 변화가 있을 때, 컨트롤러와 뷰에 통보한다.
`뷰(View)`: 사용자에게 보여지는 UI를 담당하며, 모델로부터 정보를 얻어온다.

MVC 아키텍처의 장단점은 다음과 같다.

(장점) `확장성`: 각 컴포넌트의 결합이 약하기에 다른 부분에 영향을 주지 않고 수정 가능하다.
(장점) `다수의 뷰`: 하나의 모델을 위해 다수의 다른 뷰를 제공할 수 있고, 데이터와 비즈니스 로직이 분리되기에 코드 중복이 적다.
(장점) `비동기`: 비동기 기술을 이용하여 애플리케이션을 빠르게 로딩 가능하다.
(단점) `복잡도`: 컴포넌트의 분리로 인해 메커니즘 이해를 위한 복잡도가 올라간다.
(단점) `비효율성`: 뷰에서 데이터를 접근해야 한다는 비효율적인 요소가 있다.
(단점) 각 컴포넌트 구현을 위한 여러 가지 기술에 대한 이해도가 필요하다.

파이프 필터

파이프 필터 아키텍처는 필터 사이에 데이터를 이동시키며 단계적으로 처리하는 구조이다. 데이터는 파이프를 통해 단방향으로 흐른다. 파이프 필터 아키텍처의 장단점은 다음과 같다.

(장점) `단순성`: 시스템을 일련의 입력, 출력, 변환으로 쉽게 볼 수 있다.
(장점) `재사용`: 다른 응용 프로그램에서 필터를 쉽게 재사용하고 교체할 수 있다.
(장점) `병렬성`: 병렬 처리로 구현하기 쉬운 아키텍처를 제공한다.
(단점) `복잡도`: 컴포넌트의 분리로 인해 메커니즘 이해를 위한 복잡도가 올라간다.

데이터 중심 아키텍처

데이터 중심 아키텍처는 시스템이 데이터를 중심으로 구성되며, 모든 컴포넌트가 데이터를 공유하거나 처리하기 위해 상호작용하는 아키텍처이다. 데이터 중심 아키텍처에서는 공유 데이터 저장소와 공유 데이터 접근자, 두 가지 유형의 구성 요소로 분류된다.

`공유 데이터 저장소`: 모든 데이터의 중심, 컴포넌트들이 여기로 접근한다.
`공유 데이터 접근자`: 공유 데이터를 추가/삭제/수정한다.

데이터 중심 아키텍처의 대표적인 유형은 다음과 같다.

`블랙보드 아키텍처`: 여러 컴포넌트가 공유 공간(블랙보드)에 데이터를 놓고, 서로의 결과를 기반으로 추론하거나 문제 해결한다. (Ex: 음성 인식)
`레파지토리 아키텍처`: 중앙에 데이터 저장소가 있고, 여러 컴포넌트들이 여기에 읽고/쓰기를 통해 협력한다. (Ex: Github)

데이터 중심 아키텍처의 장단점은 다음과 같다.

(장점) `낮은 결합`: 접근자 간 통신은 공유 데이터 저장소를 통해 이루어지기에 느슨한 결합을 유지한다.
(장점) `확장성`: 각 접근자를 수정하고 확장하기 쉽다.
(단점) `단일 장애지점`: 공유 데이터의 장애 시, 전체 장애 가능성이 존재한다.

Peer-to-Peer 스타일

P2P 아키텍처는 모든 참여자가 동등한 지위(Peer)를 가지며, 서버와 클라이언트의 구분 없이 서로 직접 데이터를 주고받는 분산형 구조이다. 각 컴포넌트는 하드웨어 리소스의 일부를 공유하고 서비스나 컨텐츨르 제공한다. 즉, 각 컴포넌트 자원 제공자이자 자원이다.

대표적으로 블록체인 기술은 Peer-to-Peer 아키텍처를 기반으로 한다. 보안을 해결하기 위해 각 노드가 상대방의 노드를 비교하고 감시하여 일관성을 유지한다.

Peer-to-Peer 아키텍처의 장단점은 다음과 같다.

(장점) 전담하는 애플리케이션이나 서버가 없다.
(장점) 컴포넌트에 고장이 있어도 전체 시스템은 가동된다.
(단점) 중앙에서 제어할 수 없고 보안이 취약할 수 있다.
(단점) 공유된 자원으로 성능이 떨어질 수 있다.

아키텍처 평가 (Architecture Evaluation)

아키텍처 평가는 소프트웨어 아키텍처나 디자인 패턴의 속성, 강점 및 약점을 결정하는 방법으로, 기능적 및 비기능적 품질 요구 사항을 모두 충족시키는지 보증하는 과정이다. 이를 통해 시스템에 대한 이해도가 증가하고 문서화하여 기존의 문제를 감지할 수 있다.

소프트웨어 아키텍처 평가를 위해 제안된 방법과 기술들은 다음과 같다.

SAAM (시나리오 기반 평가 방법)

관심 있는 일련의 시나리오에 대해 아키텍처를 조사할 수 있는 체계적인 수단을 제공한다. 시나리오를 기반으로 소프트웨어 아키텍처를 탐색하고 매핑하여 원하는 아키텍처 구성 요소와 해당 상호 작용을 찾아 시나리오를 통해 표현된 작업을 수행한다.

시나리오 기반 방법은 시나리오를 도출할 때, 여러 이해 당사자들을 통합하여 최종 사용자가 성능 문제를 나타낼 수 있도록 한다. 이때, 시나리오는 다음의 두 가지로 구분된다.

`직접 시나리오`: 시스템 변경이 요구되지 않는 시나리오, 일반적인 유스케이스에 대한 아키텍처 지원의 평가 인터페이스에 의해 지원되는 보통 기능들에 대해 아키텍처를 평가한다.
`간접 시나리오`: 시스템의 변경이 요구되는 시나리오, 새로운 장치 환경에 적응하는지, 아키텍처를 재구조화하거나 새로운 기능을 추가하거나 기능을 삭제할 때 아키텍처를 지원하는지 평가한다.

ATAM (속성 모델 기반 방법)

ATAM도 시나리오를 기반으로 아키텍처를 분석하지만 여러 가지 품질 속성에 더 초점을 맞추어 평가한다. 이를 통해 아키텍처의 설계 타협점(Trade-Off)을 찾아내고, 아키텍처 내부의 리스크를 발견한다.

ATAM의 진행 순서는 다음과 같다.

시스템 개발팀이 업무 배경과 요구 사항들을 설명하고 아키텍처에 대해 소개한다.
품질 특성 목표를 파악하고 이에 대한 우선순위와 시나리오를 작성한다. (유틸리티 트리)
아키텍처에서 품질 목표와 민감한 부분을 찾아낸다.

[소프트웨어 공학] - 객체지향 설계 기법 (Object-Oriented Design Principles)

shineast_ — Sun, 4 May 2025 22:14:07 +0900

객체지향 개념 (Concept of Object-Oriented)

객체지향 프로그래밍(OOP)은 현실 세계를 프로그래밍에 반영하기 위한 패러다임이다. 객체지향의 핵심 개념들은 다음과 같다.

객체와 클래스 (Object and Class)

객체와 클래스는 객체지향 시스템의 가장 기초가 되는 개념이다. 객체는 상태, 동작, 고유 식별자를 가지며 상태는 속성 값에 의해서 결정된다. 클래스는 공통 속성을 공유하는 객체 집합에 대한 정의이다. 주로 클래스는 붕어빵 틀에, 객체는 붕어빵에 비유한다.

캡슐화 (Encapsulation)

캡슐화란 데이터와 기능을 하나로 모아 캡슐로 싼다는 것이다. 즉, 연관된 여러 항목을 모아 하나로 취급하는 것이다. 캡슐화는 속에 있는 항목에 대한 정보를 외부에 감추는 “정보 은닉”을 가능하게 한다. 이때 정보가 은닉되었다는 것은 정보를 외부에서 직접 접근하여 사용하거나 변경할 수 없도록 한다는 것이다. 캡슐화된 정보는 외부에 보이지 않게 감출수도, 필요에 따라 보이게 할 수 있다.

객체지향 언어의 `public`, `private`, `protected` 명령어를 통하여 캡슐 안 접근을 제어할 수 있다.

상속 (Inheritance)

상속은 상위 개념의 일반화된 클래스가 갖는 속성과 연산을 하위 개념의 구체화된 클래스가 물려받는 것을 말한다. 상위 개념의 일반화된 클래스를 “슈퍼 클래스”, 세분화되면서 여러 종류나 유형을 이루는 클래스를 “서브 클래스”라고 한다.

추상화 (Abstraction)

추상화는 대상에 대하여 특정한 목적에 관련된 정보에 집중하고 나머지 정보는 무시하는 관점이다. 즉, 불필요한 정보는 숨기고 핵심적인 기능만 제공하는 것이다.

추상화의 원리는 복잡성을 줄이고 복잡한 소프트웨어 시스템을 효율적으로 다루고 구현이 가능하게 한다. 추상화는 설계 작업 과정에 필수적이며 문제를 분할하는 작업에 있어 필수적이다. 또한 설계 과정 뿐만 아니라 존재하는 컴포넌트에 추상화를 적용하여 유지보수에서도 유용하게 사용된다.

다형성 (Polymorphism)

다형성은 동일한 인터페이스가 다른 방식으로 동작할 수 있다는 것을 의미한다. 즉, 여러 형태를 받아들일 수 있는 특징을 의미한다. 다형성은 현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가할 수 있도록 한다.

객체지향 설계 원리 (SOLID Design Principle)

객체지향 패러다임이 등장하면서 전통적인 설계 원리와 함께 새로운 원리들도 적용되고 있다. 특별히 Martin이 제시한 5가지 객체지향 소프트웨어 설계 원리는 유지보수가 쉽고 확장성이 좋은 시스템을 설계하는데 유용하다.

단일 책임의 원리 (Single Responsibility Principle: SRP)

클래스는 객체지향 설계에서 매우 중요한 모듈 단위인데, 이때 클래스의 역할과 책임을 단일화해야 한다. 즉, 클래스를 변경해야 할 이유를 하나로 제한시키는 것이다.

NOTE!
단일 책임의 원리: 하나의 클래스는 하나의 책임만 가져야 한다.

개방 폐쇄의 원리 (Open/Closed Principle: OCP)

소프트웨어 개체(클래스, 모듈, 기능 등)가 확장을 위해서는 열려있어야 하지만 변경을 위해서는 닫혀있어야 한다. 상속을 통해 클래스가 정의되면 다형성이 적용되어 서로 대체 가능한 인터페이스를 구현할 수 있다.

NOTE!
개방 폐쇄의 원리: 새로운 기능은 기존 코드를 변경하지 않고 추가할 수 있어야 한다.

리스코프 교체의 원리 (Liskov Substitution Principle: LSP)

클래스 B가 클래스 A로부터 상속 받은 서브 클래스라면 프로그램의 동작을 방해하지 않고 A를 B로 대체할 수 있어야 한다. 부모 타입의 객체를 사용하는 곳에 자식 객체를 넣어도 정상적으로 작용해야 하며, 이 원칙을 지키지 않고 설계한 클래스 상속 계층은 문제를 일으키게 된다.

NOTE!
리스코프 교체의 원리: 자식 클래스는 부모 클래스의 자리를 대체해도 문제가 없어야 한다.

인터페이스 분리의 원리 (Interface Segregation Principle: ISP)

클라이언트가 사용하지 않는 인터페이스를 강제로 구현하게 만들면 안 된다. 이는 전체 인터페이스에 의존하게 하며 사용하지 않는 일부 메서드에 대해 더미 메서드를 구현하게 된다. 이를 비만 인터페이스(Fat Interface) 또는 오염된 인터페이스(Polluted Interface)라고 한다.

NOTE!
인터페이스 분리의 원리: 하나의 범용 인터페이스보다는 여러 개의 구체적인 인터페이스를 사용해야 한다.

의존관계 역전의 원리 (Dependency Inversion Principle: DIP)

복잡한 논리를 제공하는 높은 수준의 모듈은 재사용이 가능하고 유틸리티 기능을 제공하는 낮은 수준의 모듈 변경에 의해서 쉽게 영향을 받으면 안 된다. 이를 해결하기 위해 높은 수준의 모듈과 낮은 수준의 모듈을 서로 분리하는 추상화를 도입해야 한다.

NOTE!
의존관계 역전의 원리: 고수준 모듈은 저수준 모듈에 의존하면 안 된다는 것이며 추상화에 의존되어야 한다.

객체지향 메트릭 (Object-Oriented Metric)

객체지향 패러다임은 메트릭에도 반영되어야 하며, 널리 알려진 Chidamber와 Kemerer 메트릭은 다음과 같다.

타입	영문 명칭	설명	권장 방향
클래스 메서드 복잡도	Weighted Methods per Class (WMC)	클래스에 정의된 모든 메서드 수 또는 복잡도의 총합	너무 높지 않게
상속 깊이	Depth of Inheritance Tree (DIT)	상속 계층의 깊이 (루트 클래스부터 현재 클래스까지의 거리)	너무 깊지 않게
자식 클래스 수	Number of Children (NOC)	해당 클래스를 직접 상속한 클래스 수	적절한 수준 유지
클래스 간 결합도	Coupling Between Object Classes (CBO)	다른 클래스에 의존하고 있는 클래스 수	낮을수록 좋음
클래스 응답 집합	Response For a Class (RFC)	클래스에서 호출 가능한 메서드의 총합 (자기 자신 + 관련된 객체)	적절한 수준 유지
메서드 응집도 부족	Lack of Cohesion in Methods (LCOM)	클래스 내 메서드들이 얼마나 다른 필드들을 사용하는지 (응집도가 낮을수록 LCOM 높음)	낮을수록

[소프트웨어 공학] - 설계 원리 (Design Principles)

shineast_ — Sat, 3 May 2025 13:20:06 +0900

설계 기본 원리 (Design Principles)

설계는 “어떻게 실현할 것인가”를 구체적으로 결정하는 활동으로, 시스템의 논리 구성을 결정한다. 설계 작업은 기본 구조에 대한 설계와 모듈 내부의 설계(상세 설계)로 분류된다.

`기본 구조 설계`: 아키텍쳐 설계로, 각 모듈의 역할과 인터페이스를 정의한다.
`상세 설계`: 모듈 내부의 알고리즘, 데이터를 명세화한다.

설계 작업을 위해서는 반드시 기초가 되는 개념을 정확히 이해하고 적용할 수 있어야 한다. 또한 설계 작업은 문제를 해결하며 솔루션을 구축해 나가는 높은 수준의 의사 결정 과정의 연속이다. 이를 위해서는 설계 원리를 숙지해야 하며 커뮤니케이션도 중요하다.

품질 목표 (Quality Attributes)

사용자가 요구하는 기능을 만족하는 요구 분석 모델은 하나이지만, 품질을 만족시키는 설계안은 여러 가지일 수 있다. 비기능 요구 사항이 품질 특성이고 시스템 설계안을 결정한다.

설계 작업 전에 시스템이 요구하는 품질 특성을 충분히 검토해야 하고, 설계 단계에서 품질 특성에 대한 요구를 잘 반영하는 설계안을 만들어야 한다. 여러 품질 요구 사항을 충족시키도록 설계할 때, 다른 속성에 미치는 영향을 잘 고려하여 설계해야 하며, 상반되는 품질 요구 간의 절충안을 찾는 것도 중요하다.

아키텍쳐 설계 원리 (Architecture Design Principles)

아키텍쳐를 고려한 설계는 복잡한 문제를 다룰 수 있고, 특별히 변경에 잘 대처할 수 있기에 아키텍쳐에 관한 개념을 이해하는 것이 중요하다,

컴포넌트, 서브시스템, 모듈

소프트웨어의 아키텍쳐를 구성하는 요소가 많아질수록 당연히 시스템의 구조는 복잡하지고 유지보수하기 어려워진다. 시스템의 복잡도를 줄이기 위해 분할하는 것이 서브시스템이며, 복잡한 시스템을 서브시스템으로 분할하여 계층화하면 전체적인 개발 과정의 효율이 증가한다.

이때, 컴포넌트, 서브시스템, 모듈은 비슷한 의미로 사용되지만 차이가 존재한다.

`서브시스템(Sub-System)`: 복잡한 시스템을 쪼개기 위한 아키텍처 수준의 단위이다. (가장 추상화 단계가 높다.)
`컴포넌트(Component)`: 명확한 인터페이스를 가진 배포 가능/재사용 가능한 기능 단위, 독립 실행 단위이다.
`모듈(Module)`: 코드를 조직화하기 위한 개발자 중심의 구조 단위로, 세부적인 코드 조각 단위이다.

모듈화 (Modularization)

모듈화는 소프트웨어를 작은 구성 요소(패키지 또는 클래스)로 나누는 것을 말한다. 큰 시스템을 만드는 것보다 모듈 단위로 개발하고 테스트하는 것이 훨씬 쉽고, 또한 변경 사항이 있을 때 수용하는 것도 모듈 단위가 더 쉽기에 자주 사용된다.

모듈로 분할하면 각각의 모듈을 별개로 만들고 수정 가능하기에 좋은 구조가 될 수 있다. 그러나, 모듈성이 너무 크게 증가하면 모듈 간 서로 어떻게 상호작용하는지 이해하는 것이 어려워진다. 따라서 소프트웨어 모듈화 수준을 적절하게 선택하는 것이 중요하다.

결합 (Coupling)

결합은 모듈 간에 서로 의존하는 정도를 의미한다. 좋은 소프트웨어는 낮은 결합력을 가지게 되는데, 이는 모듈 사이에 의존도가 강하면 시스템을 이해하기 어려우며 변경될 때의 파급효과가 커지기 때문이다. 모듈 간의 결합 정도는 다음 두 가지 요소에 의해 결정된다.

모듈 간 인터페이스 수
각 인터페이스의 복잡성

모듈 사이의 결합은 정도에 따라 다섯 가지로 나누어진다. 위에서 아래로 내려갈수록 결합도가 낮아지고, 더 좋은 설계가 된다.

`내용 결합(Content Coupling)`: 한 모듈이 다른 모듈의 내부 작업을 직접 참조하거나 수정하는 경우
`공통 결합(Common Coupling)`: 한 모듈이 다른 모듈이 읽은 전역 변수 값을 쓰거나 변경하는 경우
`제어 결합(Control Coupling)`: 한 모듈이 다른 모듈의 제어(분기, 조건 등) 흐름 경로를 결정하는 경우
`스탬프 결합(Stamp Coupling)`: 모듈 간에 필요한 데이터만 전달하지 않고, 구조체나 객체처럼 필요한 것보다 복잡한 데이터 구조를 전달하는 경우
`데이터 결합(Data Coupling)`: 한 모듈이 다른 모듈에 정확히 필요한 값만 인자로 넘겨주고, 반대로 불필요한 정보는 주지 않는 경우

응집 (Cohesion)

응집은 하나의 모듈 안에서 수행되는 작업들이 서로 관련된 정도를 말한다. 모듈 안의 여러 요소들은 하나의 목적을 위해 유기적으로 관련되어 있는 것이 좋다. 높은 응집성을 가지는 모듈은 재사용하기 좋고, 이해하기도 쉬우며, 수정할 때 받는 영향도 적다.

모듈 사이의 응집은 정도에 따라 다음과 같이 분류된다. 위에서 아래로 내려갈수록 응집도가 강해지고, 더 좋은 설계가 된다.

`우연적 응집(Coincidental Cohesion)`: 가장 응집이 약한 상태로, 서로 관련 없는 기능들이 그냥 한 곳에 묶여 있는 상태.
`논리적 응집(Logical Cohesion): 비슷한 종류의 기능들이 하나의 모듈에 논리적으로 묶여 있지만, 호출할 때 구분해서 사용해야 하는 상태.
`시간적 응집(Temporal Cohesion)`: 특정 시간에 함께 수행되는 작업들이 하나의 모듈에 묶여 있는 상태. (예: 프로그램 초기화 작업)
`절차적 응집(Procedural Cohesion)`: 수행 순서에 따라 묶여 있지만, 서로 기능적으로는 크게 관련 없는 상태.
`교환적 응집(Communicational Cohesion)`: 같은 데이터를 사용하거나 같은 데이터를 생성하는 작업들이 묶여 있는 상태.
`기능적 응집(Functional Cohesion)`: 모듈 안의 모든 기능이 하나의 명확한 기능을 수행하기 위해 밀접하게 연결된 상태. (가장 좋은 응집 형태)
`정보적 응집(Informational Cohesion)`: 하나의 모듈이 다양한 기능을 제공하지만, 공통된 데이터를 기반으로 서로 다른 작업을 수행하는 상태.

설계 관점

아키텍쳐 기반 설계는 전통적인 설계와 큰 차이가 있다. 전통적 설계 원리는 “Top-Down”, “Bottom-Up , “분할 정복” 등 기능을 실현하는데 초점이 맞추어져 있고, 아키텍쳐 기반 설계는 관점에 근거하는 품질 중심의 설계 작업이다. 이때, 관점이란 소프트웨어 구조(요소와 관계)를 바라보는 일관된 방법이다.

아키텍쳐의 설계 관점은 다음과 같다.

`모듈 관점`: 일정한 책임을 구현하는 코드 단위인 모듈과 그 관계로 소프트웨어 구조를 설명한다.
`컴포넌트 관점`: 실행될 때 동작하는 요소와 상호작용으로 구조를 설명한다.
`할당 관점`: 소프트웨어의 하드웨어 설치, 작업 할당, 구현, 데이터 저장 등으로 설명한다.

설계 작업 과정

설계 과정은 의사 결정 과정이며 동시에 시스템을 알아가는 과정이다. 일반적인 설계 작업 과정은 다음의 순서로 이루어진다.

`설계 목표 설정`: 전체 시스템에 대한 설계 목표를 파악하고 결정한다.
`스타일 결정`: 시스템이나 서브시스템의 타입을 결정하기 위해 설계 목표와 유형에 맞는 아키텍쳐 스타일을 결정한다.
`서브시스템 기능, 인터페이스 명세`: 서브시스템 사이의 인터페이스를 정의하고 서브시스템 사이의 상호작용을 위한 동작을 작성한다.
`아키텍쳐 설계 검토`: 설계한 아키텍쳐가 요구, 설계 목표, 설계 원리를 잘 만족하는지 검토한다.

설계 메트릭 (Design Metrics)

설계 메트릭은 소프트웨어의 설계 품질을 수치적으로 평가할 수 있게 도와주는 정량적 기준이다. 설계를 마친 후, 그 결과가 원리들을 잘 적용하여 좋은 설계가 되었는지 따진다. 설계 모델에 대한 전통적 측정 방법은 다음과 같다.

`크기(Size)`: 시스템의 물리적인 규모를 하나의 메트릭으로 측정하는 방법 → 모듈 수, 인터페이스 수, 코드 라인 수(LOC) 등을 센다
`복잡도(Complexity)`: 시스템이 얼마나 복잡하게 얽혀 있는지를 나타내는 방법 → 구조적 복잡도, 데이터 흐름 복잡도, 제어 흐름 복잡도 등을 수식으로 측정한다
`결합도(Coupling)`: 모듈 간의 실제 연결 정도를 나타내는 방법 → 외부 모듈 호출 수, 입출력 매개변수의 수, 전역 변수 사용 여부 등을 고려한다.
`응집도(Cohesion)`: 모듈 내부의 구성 요소들이 하나의 목적을 위해 얼마나 잘 협력하는지를 나타내는 방법 → 내부 함수 간의 관계, 사용하는 데이터 객체 등을 분석한다
`정보 흐름 (Information Flow)`: 시스템 내에서 얼마나 많은 정보가 처리되고 이동하는지를 나타내는 방법 → 함수 간 전달되는 매개변수 수, 전역 변수 사용, 입출력의 수 등을 통해 측정한다

[컴퓨터 네트워크] - TCP/IP: 응용 계층 (Application Layer)

shineast_ — Fri, 2 May 2025 00:51:39 +0900

TCP/IP: 응용 계층

응용 계층은 TCP/IP 모델의 최상위 계층으로 OSI 참조 모델의 세션 계층과 표현 계층, 응용 계층이 포함된다. 우리가 주로 사용하는 애플리케이션들은 응용 계층에서 동작한다.

세션 계층 (Session Layer)

세션 계층은 응용 프로그램 계층 간의 통신을 제어하는 구조를 제공하며, 이를 위해 계층 사이의 접속을 설정/유지/종료하는 역할을 담당한다.

데이터 단위를 전송 계층으로 전송할 순서를 결정하고, 데이터를 점검하고 복구하는 동기 위치를 제공한다. 그리고 세션을 종료해야 하는 상황이 생기면, 종료할 적절한 시간을 수신자에게 알린다.

세션 계층의 기능은 다음과 같다.

`동기화`: 전송 계층으로 전송할 순서와 전송할 때 수신자 확인 필요한 곳을 결정한다.
`세션 연결의 설정과 종료`: 세션 연결의 설정과 종료 및 관리 절차를 정의한다.
`대화 제어`: 누가 언제 보내는지 결정한다.

표현 계층 (Presentation Layer)

표현 계층은 데이터 표현의 차이를 해결하기 위해 서로 다른 형식으로 변환하거나 공통 형식을 제공하는 계층이다. 송신 측에서는 수신 측에 맞는 형태로, 수신 측에서는 응용 계층에 맞는 형태로 변환한다.

표현 계층에서는 송신 측과 수신 측 사이에서 표준화된 데이터 형식을 규정하고, 두 시스템 간 다르게 사용하는 문자와 그래픽 문자들을 번역하여 일관된 데이터 전송을 가능하게 한다.네트워크로 전송되는 데이터의 보안을 위해 송신 측에서는 암호화하고 수신 측에는 복호화하며, 전송률을 높이기 위해 데이터를 압축하기도 한다.

표현 계층의 기능은 다음과 같다.

`암호화`: 데이터의 보안을 위해 암호화와 복호화를 수행한다.
`압축`: 데이터의 효율적인 전송을 위해 데이터 압축 및 압축 해제를 수행한다.
`코드 변환`: 전송에 사용할 수 있도록 메시지를 상호 간에 수용할 수 있는 형식으로 변환하고 수신지에서 수신자가 이해할 수 있는 형식으로 변환한다.

응용 계층 (Application Layer)

응용 계층은 파일 전송, DB, 원격 접속, 메일 전송 등 응용 서비스를 네트워크에 접속하는 역할을 하고 여러 서비스를 제공한다. 사용자가 정보를 입력하면 하위 계층으로 전달하고, 하위 계층에서 전송한 데이터를 사용자에게 전달한다.

응용 계층은 OSI 모델의 최상위 계층으로, 통신의 최종 목적에 해당하는 계층이다. 응용 프로세스가 네트워크에 접근하는 수단을 제공하여 데이터를 서로 교환하는 창구 역할을 하고 사용자 인터페이스를 제공한다.

응용 계층의 기능은 다음과 같다.

`파일 접근 및 전송`: 원격으로 다른 호스트 파일에 접근이 가능하게 하며, 원격 컴퓨터에서 파일을 가져오고 관리하고 제어한다.
`메일 서비스`: 메일을 발송하고 저장할 수 있는 토대를 제공한다.

응용 계층 프로토콜

응용 계층은 클라이언트의 요청을 전송하기 위해 서버가 이해 가능한 메시지로 변환하고 전송 계층으로 전송하게 된다. 이때, 애플리케이션과 네트워크 간 통신을 위해서는 응용 계층의 프로토콜을 사용해야 한다.

프로토콜

응용 계층에서 제공하는 프로토콜은 TCP 응용 프로토콜과 UDP 응용 프로토콜로 분류된다.

`TCP 응용 프로토콜`: FTP, HTTP, TELNET, SMTP, POP3, IMAP
`UDP 응용 프로토콜`: DHCP, SNMP

FTP (File Transfer Protocol)

인터넷에서 파일을 전송하는 기본 프로토콜로, 사용자 식별 패스워드가 필요한 “일반 FTP”와 ID와 PW 없이 누구나 접속 가능한 “익명 FTP”로 분류된다. FTP는 제어 프로세스 간의 통신을 위해 제어 연결을 사용한다.

서버는 포트번호를 21로 수동 설정하고 응답을 기다린다.
클라이언트는 임시 포트를 사용하여 능동적 설정을 시도한다.

제어 연결에서 전송하는 명령을 제어하여 데이터 연결을 수행한다.

데이터 연결에는 포트번호 20을 사용하고, 임시 포트를 사용하여 수동적 설정을 시도한다.
클라이언트는 PORT 명령어를 사용하여 포트 번호를 전송한다.
서버는 포트 번호를 수신한 후 능동적 연결을 설정한다.

HTTP (Hyper Text Transfer Protocol)

클라이언트의 웹 브라우저가 서버에 웹 서비스를 요청하면 서버가 응답하여 클라이언트에게 웹 페이지를 제공하는 서비스이다. 즉, 서버와 클라이언트 사이에 하이퍼텍스트 문서를 송수신하는 프로토콜이다.

HTTP의 동작 과정은 다음과 같다.

클라이언트는 접속하려는 웹사이트의 URL 또는 IP 주소를 알아야 한다.
클라이언트가 웹 브라우저에 URL 주소를 입력하고 TCP 포트 번호 80을 이용하여 접속하려는 서버와의 연결을 시도한다.
클라이언트는 TCP 요청 소켓을 이용하여 URL 주소를 포함한 요청 메시지를 서버에 전송한다.
서버는 클라이언트 요청 메시지에 응답하여 소켓을 통해 메시지를 전송하고 TCP 연결 설정을 해제한다.

이와 같이 HTTP 프로토콜을 데이터를 요청하고 데이터를 전송받으면 바로 소켓 연결을 해제한다. 즉, 필요할 때마다 소켓을 연결하고 데이터를 전송받으면 바로 연결을 끊는 것이다.

HTTP 프로토콜의 특징은 다음과 같다.

HTTP를 통해 데이터를 전송할 때, 데이터 외에도 메타 정보를 HTTP 헤더에 포함하여 전송한다.
MIME를 이용한 하이퍼미디어 이메일, 뉴스 등의 정보와 통합하기 위해 HTTP는 MIME 헤더를 확장한 헤더를 사용한다.
하이퍼텍스트 문서보다 확장된 형태의 문서도 전송 가능하다.
클라이언트는 서버와의 사이에 TCP를 기반으로 한 HTTP 연결을 만들고 규정된 요구 형식에 따라 서버에 요청 메시지를 전송한다.
서버는 프로토콜 버전, 성공 또는 오류 코드, 서버 정보, 데이터 정보, 사용자 데이터 등을 포함한 메시지를 클라이언트로 전송한다.

SMTP, POP3, IMAP

TCP/IP 프로토콜에서 이메일을 교환하기 위해 SMTP, POP3, IMAP를 사용한다.

`SMTP`: 네트워크의 두 메일 서버 간 이메일을 송수신하는데 사용하는 프로토콜, 25번 포트에서 동작하도록 만들어진다.
`POP3`: 이메일을 수신하는 표준 프로토콜인 POP의 최신 버전, 이메일을 수신하고 보관하기 위해 인터넷 서버에서 사용한다. 110번 포트에서 동작한다.
`IMAP`: 이메일을 저장 및 복사하는 프로토콜로, 143번 포트에서 동작한다.

SNMP, DHCP

전송 계층의 UDP에 기반을 둔 프로토콜들이다.

`SNMP`: 다른 네트워크 장치를 원격에서 관리할 수 있는 가장 간단한 방법을 제공하는 인터넷 표준 프로토콜, 161번 포트에서 동작한다.
`DHCP`: 네트워크의 각 노드에 유일한 IP 주소를 자동으로 할당하고 관리하는 서비스로 67번, 68번 포트를 사용한다.

Ping (Packet InterNet Groper)

Ping은 TCP/IP에서 널리 사용하는 서비스로, 모든 TCP/IP 설치에 포함되어있다. Ping은 네트워크에 다른 시스템에서 TCP/IP가 정상적으로 동작하는지 알려주는 프로그램이다.

Ping의 주요 기능은 다음과 같다.

대상 서버가 연결 가능한지 확인한다. (Ex: `ping google.com` Google 서버가 정상 작동 중이면 응답이 온다.)
왕복 시간(RTT, Round Trip Time)을 측정한다. 데이터를 보낸 후 응답이 오기까지 걸리는 시간(ms)을 확인 가능하다.
패킷 손실 여부를 확인한다. 즉, 전송한 데이터가 도중에 유실되었는지 확인할 수 있다.

[컴퓨터 네트워크] - TCP/IP: 전송 계층 (Transport Layer)

shineast_ — Thu, 1 May 2025 22:23:21 +0900

TCP/IP: 전송 계층

네트워크 접속 계층이나 네트워크 계층에서는 수신지로 데이터를 전송할 수는 있지만 전송 중인 데이터가 손실되거나 분실되면 할 수 있는 것이 없다.

전송 계층은 수신지에 신뢰할 수 있는 데이터를 전송하는 계층으로, 데이터에 오류가 발생하면 재전송을 요청할 수 있다. 즉, 전송 계층은 오류 복구와 흐름 제어를 담당하고 두 시스템 간 신뢰성 있는 데이터를 전송하는 것이다.

결국, 전송 계층은 네트워크 계층에서 전송한 데이터와 실제 운영체제의 프로그램이 연결되는 통신 경로이다. 송신 측에서는 데이터를 패킷으로 분할하고 네트워크 계층으로 전송하고 수신 측에서는 패킷을 결합하여 순서대로 재조립한다.

전송 계층의 데이터 단위

전송 계층은 세션 계층에서 온 데이터를 수신할 때 데이터를 전송할 수 있는 세그먼트로 분할하고, 수신 측에서 재조립 가능하도록 헤더에 순서를 표현한다.

네트워크 계층은 전송해야 하는 시스템에 각 패킷을 전송하고, 전송 계층은 해당 시스템의 응용 프로그램에 모든 데이터를 전송한다. 전송 계층에서 담당하는 역할은 다음과 같다.

`연결 제어`: 패킷을 하나의 경로로 보낼 것인지 결정한다.
`데이터 전송`: 수신지에서 데이터의 모든 패킷 전송과 도착을 검사한다.
`단편화`: 데이터를 전송 가능한 세그먼트로 분할하고 순서 번호를 기록한다.
`재조립`: 수신지의 전송 계층에서 순서 번호에 따라 데이터를 올바르게 재조립한다.

전송 계층의 통신 방식

결국, 전송 계층에서는 데이터를 수신지까지 문제 없이 빠르고 효율적으로 전송해야 한다. 이때, 신뢰 가능한 데이터를 정확하게 전송하는 방식을 “연결형 통신”이라고 하며, 정확도보다 효율성에 집중하여 데이터를 전송하는 방식은 “비연결형 통신”이라고 한다.

`연결형 통신`: 신뢰성을 우선으로, 데이터를 전송할 때 여러 번 확인하고 동작한다. 전송 계층의 연결형 통신 프로토콜에는 TCP가 사용된다.
`비연결형 통신`: 효율성을 우선으로, 확인 절차 없이 일방적으로 데이터를 전송한다. 전송 계층의 비연결형 통신 프로토콜에는 UDP가 사용된다.

TCP (Transmission Control Protocol)

연결형 프로토콜은 송수신측 컴퓨터가 데이터를 전송하기 전, 먼저 데이터를 송수신할 수 있는 연결 통로를 생성한 후 데이터를 전송하는 방식의 프로토콜이다. TCP는 “신뢰성 있는 데이터 전송을 보장하는” 연결형 프로토콜로, 송신 측 TCP 포트에서 수신 측 TCP 포트로 바이트 스트림을 전송하는 연결형 데이터 전달 서비스를 제공한다.

포트 번호

포트는 TCP가 상위 계층으로 데이터를 전송하거나, 상위 계층에서 TCP로 데이터를 전송할 때 상호 간에 사용하는 데이터의 이동 통로를 말한다. 상위 계층 프로토콜과 하위 계층 프로토콜이 서로 같은 포트를 사용해야 통신이 가능하다.

웹 브라우저로 서버에 접속하여 해당 페이지의 내용을 볼 때는 다음의 과정을 거친다.

웹 브라우저에서 접속하려는 서버의 IP 주소를 입력하고 해당 서버에 접속한다.
서버가 열어놓은 포트를 이용하여 웹 서비스를 담당하는 상위 계층의 서버 프로그램에 웹 페이지의 내용을 요청한다.
웹 서비스를 하는 서버의 IP 주소가 있고 80번 포트를 웹 서비스로 사용하는 경우. 서버에 접속하려는 클라이언트도 80번 포트로 접속해야한다.

웹 서비스는 HTTP 프로토콜을 사용하기에 포트 번호가 80번이다. 웹 브라우저를 사용하여 웹 서버에 접속할 때 자동으로 80번이 할당된다.

포트 번호를 사용하지 않고 네트워크 통신을 하면 데이터가 수신되어도 어플리케이션까지 도달하지 못한다. 데이터를 전송할 때는 수신 측의 IP 주소가 필요하지만, 어떤 어플리케이션이 사용되고 있는지 구분하기 위해서는 TCP는 포트 번호를 필요로 한다.

TCP 세그먼트

TCP 프로토콜은 전송을 위해 바이트 스트림을 세그먼트 단위로 분할한다. 이때 세그먼트란 TCP를 이용하여 두 장치 간 전달하는 데이터의 단위를 말한다. TCP 세그먼트는 TCP 헤더와 TCP 데이터로 나뉜다. TCP 헤더는 수신지까지 데이터를 제대로 전송하는데 필요한 정보를 가진다.

`송신지 포트 번호(16비트)`: 세그먼트를 전송하는 송신지 호스트에 있는 응용 프로그램의 포트 번호
`수신지 포트 번호(16비트)`: 수신지 호스트에서 수행하는 프로세스가 사용하는 포트 번호
`순서 번호(32비트)`: 데이터의 신뢰성 있는 연결을 보장하기 위해 세그먼트에 포함된 데이터의 첫 번째 바이트에 부여된 부호 없는 번호
`확인 응답 번호(32비트)`: 세그먼트를 수신하는 노드가 상대편 노드에서 수신하려는 바이트 번호
`헤더 길이(4비트)`: TCP 헤더 길이를 4비트 워드 값으로 나타내며, 헤더 길이는 20~60바이트가 될 수 있다.
`예약(6비트)`: 나중에 사용하기 위해 예약된 필드
`코드 비트(6비트)`: 연결의 제어 정보가 기록되며, 비트 별로 역할(URG, ACK, PSH, RST, SYN, RIN)이 정해져 있다.
`윈도우 크기(1비트)`: 상대방이 유지해야 하는 바이트 단위의 윈도우 크기를 정의한다.
`검사합(16비트)`: 의사 헤드를 포함한 헤드 부분의 오류를 검출하는 검사합 계산이 포함된다.
`긴급 포인터(16비트)`: 코드 비트의 URG 플래그가 설정되면 긴급한 데이터의 마지막 바이트 순서 번호는 긴급 포인터 값과 순서 번호 값의 합으로 계산된다.
`옵션`: 송신지에서 수신하고자 하는 세그먼트의 최대 크기를 나타낸다.

TCP 연결 관리

3-Way Handshake (연결 설정)

TCP는 항상 데이터를 전송하기 전, 연결부터 설정해야 한다. 3-Way Handshake는 송신자(클라이언트)와 수신자(서버)가 서로의 존재를 확인하고, 시작할 준비가 되었는지 확인한 뒤, 연결을 정식으로 확립하는 과정이다. 3-Way Handshake 방식은 다음과 같다.

`연결 시작 요청(SYN: Synchronize)`: 클라이언트가 서버에게 연결을 요청하고, “초기 시퀀스 번호(ISN)”가 포함된 SYN 플래그가 설정된 패킷을 보낸다.
`SYN + ACK`: 서버는 클라이언트의 요청을 수락하고, 응답으로 SYN+ACK 패킷을 보낸다. 이때 동시에 서버 자신의 “초기 시퀀스 번호(ISN)”도 포함시킨다. 클라이언트와 서버는 각자 독립적인 ISN을 가진다.
`수신 확인 응답(ACK: Acknowledgment)`: 클라이언트는 서버의 응답을 받고, 다시 확인 응답을 보내 연결을 확정한다.

데이터 전송 (Data Transmission)

TCP는 3-Way Handshake 연결이 성립되면, 아래와 같이 데이터를 전송한다.

`데이터 분할 및 시퀀스 번호 부여`: 데이터가 크면 세그먼트 최대 크기만큼 나누고, 각 조각에는 고유한 시퀀스 번호가 부여된다.
`데이터 전송과 확인 응답 (ACK)`: 데이터를 전송하면 수신자는 정상적으로 수신한 경우 ACK를 보낸다. 반면, 보낸 패킷에 대한 ACK가 일정 시간 내에 오지 않으면 TCP는 해당 세그먼트를 자동으로 재전송한다.
`흐름 제어 (Flow Control)`: 수신자의 버퍼가 꽉 찼을 경우, 윈도우 크기(Window size)를 조절하여 송신자가 전송 속도를 줄이게 한다.
`혼잡 제어 (Congestion Control)`: 네트워크에 패킷이 너무 많으면 혼잡이 생기고, 손실 가능성이 커지기에, TCP는 스스로 혼잡을 감지하고 전송 속도를 동적으로 조절한다.

4-Way Handshake (연결 종료)

데이터 전송 과정이 끝나면 TCP는 연결을 안전하고 종료한다.

`연결 종료 요청(FIN: Finish)`: 클라이언트는 자신의 마지막 시퀀스 번호가 포함된 FIN 플래그가 설정된 패킷을 보내면서 연결 종료 요청을 보낸다.
`수신 확인 응답(ACK: Acknowledgment)`: 서버는 클라이언트의 종료 요청을 받으면 확인 응답을 보내고, 클라이언트가 보낸 시퀀스 번호 + 1을 ACK 번호로 설정한다.
`서버의 종료 요청(FIN: Finish)`: 서버도 데이터 송신이 끝났음을 알리기 위해 연결 종료 요청을 보낸다. 클라이언트와 마찬가지로 자신의 시퀀스 번호가 포함된 FIN 플래그가 설정된 패킷을 보낸다.
`최종 확인 응답(ACK: Acknowledgment)`: 클라이언트는 서버의 종료 요청을 수락하고 ACK 응답을 보낸다. 서버가 보낸 시퀀스 번호 + 1을 ACK 번호로 설정한다. 이때, 서버측 연결이 종료되고 클라이언트는 타이머가 만료되면 연결이 종료된다.

UDP (User Datagram Protocol)

UDP는 “흐름 제어, 단편화, 전송 보장” 등의 기능을 제공하지 않는 비연결형 프로토콜이며, TCP 헤더에 비해 UDP 헤더는 간단하여 통신 과부하가 적다. 독립적인 제어 메시지를 사용하지 않고 UDP 통신은 요청 메시지와 응답 메시지만으로 구성되어 적은 양의 데이터 전송에 사용되며 전송 속도가 중요할 때 사용된다.

UDP 헤더의 구조는 다음과 같다.

`송신지 포트 번호(16비트)`: 데이터 영역의 데이터 정보를 만든 전송 시스템의 프로세스 또는 응용 프로그램
`수신지 포트 번호(16비트)`: 데이터 영역의 데이터 정보를 처리할 수신 시스템의 프로세스 또는 응용 프로그램
`전체 길이(16비트)`: UDP 헤더와 데이터의 길이를 바이트 단위로 표현한 것
`검사합(16비트)`: 수신 측에서는 검사합을 사용하여 UDP 헤더와 데이터 및 IP 헤더의 오류를 검출한다.

전송 계층 프로토콜

TCP/IP 모델의 전송 계층에는 TCP와 UDP 프로토콜이 있는데, 이외에도 SPX, NCP 프로토콜이 있다.

SPX (Sequenced Packet eXchange)

SPX는 NetWare의 연결형 프로토콜로, NetWare 서버는 프린트 큐 사이에서 프린트 서버와 프린트 간의 통신에서 주로 사용하고 인터넷 통신에는 주로 사용하지 않는다.

NCP (NetWare Core Protocol)

NCP는 NetWare 클라이언트와 서버 간의 파일 공유 등 다양한 네트워크 기능을 담당한다. 다양한 기능을 수행하기에 OSI 계층을 하나로 규정하기는 어렵다.

[컴퓨터 네트워크] - IPv4와 IPv6 (Internet Protocol)

shineast_ — Wed, 30 Apr 2025 10:42:46 +0900

IPv4 (Internet Protocol v4)

인터넷에 연결된 모든 컴퓨터는 고유 주소를 가지는데, 이를 IP 주소라 한다. IP 버전은 IPv4와 IPv6이 있다. IPv4는 32비트의 IP 주소로 $2^{34}$(약 43억)개의 컴퓨터에 할당 가능하다.

IP 주소는 2진수 32비트를 구분하기 쉽게 10진수로 표시하여 사용한다. 컴퓨터가 이해하기 쉽도록 8비트 단위로 나누어 표시하고 읽기 쉽게 하기 위해 8비트를 10진수로 변환한 것이 IPv4이다. 예를 들어 163.142.35.114와 같이 마침표로 구분한 10진수 4개로 구성된다. IP 주소의 값은 0.0.0.0부터 255.255.255.255이다. 그러나 실제로 사용 가능한 주소는 이보다 한정적이다.

숫자로 표현된 IP 주소는 기억하기 어려운데, 도메인 네임이라는 별칭을 통해 해결할 수 있다. 도메인 네임은 그저 숫자로 된 IP 주소를 쉽게 기억하기 위한 것일 뿐이지 인터넷에서 컴퓨터를 찾기 위해서는 IP 주소가 있어야 한다. IP 주소는 네트워크 ID와 호스트로 구분된다.

`네트워크 ID`: 네트워크 자체를 나타내는 주솔, 다른 네트워크와 구분하는 역할을 한다.
`호스트 ID`: 해당 네트워크에 속한 호스트의 주소를 나타낸다.

IP 주소는 공인 IP 주소와 사설 IP 주소로 구분되며 공인 IP 주소는 ISP가 제공한다. 인터넷에 직접 연결되는 컴퓨터나 라우터에는 공인 IP 주소를 할당하고 집 또는 회사의 LAN에 연결되는 컴퓨터에는 사설 IP 주소를 할당한다.

IPv4의 클래스 구조

IP 주소는 비트로 구분하지만, 네트워크 ID를 크게 하거나 호스트 ID를 작게 만들어서 네트워크의 크기를 조정할 수 있다. 이때, 네트워크의 크기는 클래스 개념으로 구분하고 IP 주소는 네트워크의 규모에 따라 A, B, C, D, E 클래스로 나뉜다.

D 클래스는 IP 멀티 캐스팅용으로, E 클래스는 연구 및 특수 용도로 사용하는 주소이기에 일반 네트워크에서는 A 클래스, B 클래스, C 클래스를 사용할 수 있다.

인터넷과 연결하지 않고 개별적으로 구성한 네트워크는 A, B, C 클래스의 어떤 IP 주소를 사용해도 되지만 인터넷에 연결하기 위해서는 할당 받은 공인 IP 주소를 사용해야 한다. 반면, IP 주소 중 인터넷에서 사용하지 않는 주소가 있는데 이것이 사설 IP 주소이다. 사설 IP 주소는 공인 IP 주소로 사용할 수 없다.

A 클래스

A 클래스는 네트워크 ID로 8비트, 호스트 ID로 24비트를 사용한다. 네트워크 주소의 가장 왼쪽 비트가 0으로 고정된다는 특징을 가진다. 첫 번째 바이트의 첫 비트가 0이기에 가장 처음 숫자는 0~127로 시작하고 범위는 $0.0.0.0~127.255.255.255$이다. 그러나, 0.0.0.0은 사용하지 않는 주소이고, 127.X.X.X는 시스템 루프백 주소(가상으로 할당한 인터넷 주소)이기에 사용하지 않는다.

A 클래스의 기본 네트워크 마스크는 255.0.0.0이고 4바이트로 구성되며, 네트워크 주소를 구분하는 역할을 한다. A 클래스의 네트워크는 네트워크 126개(1~126)로 구성하고 총 24비트를 호스트 주소로 배정할 수 있다. 다만 호스트 주소 비트가 모두 0이거나 모두 1인 주소는 제외된다.

A 클래스의 특징을 정리하면 다음과 같다.

맨 왼쪽 비트가 0이고 첫 번째 옥텟이 네트워크 ID(7비트)이다.
$2^7 = 128$개 네트워크 중 126개를 사용할 수 있다. (2개는 특수 목적에 사용된다)
호스트를 $2^{24} = 16,777,216$개 중 $16,777,214$개 사용할 수 있다. (호스트 ID가 모두 0이거나 1인 것은 특별한 의미가 있다.)
대형 기관 및 기업에서 사용한다.

B 클래스

B 클래스는 네트워크 ID에 16비트, 호스트 ID에 16비트를 사용한다. B 클래스를 구분하는 식별자는 10으로 시작한다. 따라서 B 클래스의 IP 주소는 128~191로 시작하고 B 클래스의 기본 네트워크 마스크는 255.255.0.0이다. 범위는 $128.0.0.0~191.255.255.255$이고 호스트 주소는 2바이트로 호스트 65,534개를 구성할 수 있다. A 클래스와 동일하게 네트워크 주소(0.0)과 브로드캐스트 주소(255.255)를 제외한 호스트의 수이다.

B 클래스의 특징을 정리하면 다음과 같다.

맨 왼쪽 2비트가 10이고 옥텟이 두 개인 네트워크 ID(14비트)이다.
네트워크를 $2^{14} = 16,384$개 사용할 수 있다.
호스트 ID로 16비트를 사용할 수 있다.
호스트(라우터)를 $2^{16} = 65,536$개 중 65,534개 사용할 수 있다. (2개는 특수 목적에 사용된다)
중형 기관 및 기업에서 사용한다.

C 클래스

C 클래스를 구분하는 식별자는 110으로 시작한다. C 클래스는 호스트 배정에 총 8비트를 사용할 수 있기에 호스트를 최대 254개 사용할 수 있다. C 클래스의 IP 주소는 192~223로 시작하고 기본 네트워크 마스크는 255.255.255.0이다. 범위는 $192.0.0.0~223.255.255.0$이고 호스트 주소는 1바이트로 호스트 254개를 구성할 수 있다. A 클래스, B 클래스와 동일하게 네트워크 주소(0)과 브로드캐스트 주소(255)를 제외한 호스트의 수이다.

C 클래스의 특징을 정리하면 다음과 같다.

맨 왼쪽 3비트가 110이고 옥텟이 세 개인 네트워크 ID(21비트)이다.
네트워크를 $2^{21} = 2,097,152$개 사용할 수 있다.
호스트 ID로 8비트를 사용할 수 있다.
호스트(라우터)를 $254$개 사용할 수 있다. (2개는 특수 목적에 사용된다)
소규모 기관에서 사용한다.

D 클래스

멀티캐스트 용도로 사용하는 D 클래스의 IP 주소는 224~239로 시작한다.

E 클래스

연구 및 특수 용도로 사용되는 E 클래스의 IP 주소는 240~255로 시작한다. 255.255.255.255는 전체 컴퓨터에 대한 브로드캐스트 주소로 사용한다.

네트워크 주소와 브로드캐스트 주소

네트워크 주소와 브로드캐스트 주소는 컴퓨터에 할당할 수 없는 특별한 IP 주소이며, 컴퓨터나 라우터가 자신의 IP로 사용할 수 없는 주소이다. 호스트 ID가 2진수로 00000000, 10진수로 0인 주소는 네트워크 주소이고, 호스트 ID가 2진수로 11111111, 10진수로 1인 주소는 브로드캐스트 주소이다.

`네트워크 주소`: 전체 네트워크에서 작은 네트워크를 식별할 때 사용되고, 호스트 ID가 0인 경우, 그 네트워크 전체를 대표하는 주소가 된다.
`브로드캐스트 주소`: 네트워크에 있는 모든 컴퓨터에 동시에 데이터를 전송할 때 사용되는 전용 IP 주소이다. 전체 네트워크에 데이터를 전송할 때 호스트 ID에 255를 설정하면 된다.

서브넷의 구조와 서브넷 마스크

많은 컴퓨터가 브로드캐스트 패킷을 전송하면 모든 컴퓨터에 패킷이 전송되어 네트워크가 매우 혼잡해질텐데, 이때 대규모 네트워크를 작은 네트워크로 분할하여 브로드캐스트로 전송되는 패킷의 범위를 줄일 수 있다. 이를 “서브넷팅”이라고 하며, 분할된 네트워크를 서브셋이라고 한다. 이를 통해 네트워크를 더 많이 생성하여 IP 주소를 더 효율적으로 활용할 수 있다.

서브넷팅을 하면 “네트워크 ID + 호스트 ID”로 구성된 특정 클래스가 “네트워크 ID + 서브넷 ID + 호스트 ID”로 변경된다. 호스트 ID에서 비트를 빌려 서브넷으로 만드는 것이다. 그런데 IP 주소를 서브넷팅할 때, 어디까지가 네트워크 ID고 어디부터 호스트 ID인지 판단하기 어려울 때 “서브넷 마스크”를 사용한다. 서브넷 마스크란 네트워크 ID와 호스트 ID를 식별하기 위한 32비트 값으로 다음과 같다.

A 클래스: 255.0.0.0
B 클래스: 255.255.0.0
C 클래스: 255.255.255.0

서브넷 마스크를 슬래시로 나타내는 프리픽스 표기법으로 나타내기도 한다.

A 클래스: 255.0.0.0 (/8)
B 클래스: 255.255.0.0 (/16)
C 클래스: 255.255.255.0 (/24)

데이터그램 (Datagram)

IP 계층의 패킷을 데이터그램이라고 하는데, 데이터그램은 가변 길이이며 헤더와 데이터 부분으로 구성된다. IP 방식에서 동작하는 패킷이기에 비연결형 전송 시스템이다. 데이터그램의 헤더는 다음으로 구성된다.

`버전 (Version)`: 버전 필드는 4비트로, IP 버전(IPv4 또는 IPv6)을 규정한다.
`헤더 길이(Header Length)`: 데이터그램 헤더의 길이를 4비트 단위로 나타낸다.
`서비스 유형(Type of Service)`: 서비스 유형은 8비트로, 1비트는 우선순위 및 서비스 품질(QoS)를 제어하는 필드이다.
`전체 길이(Total Length)`: IP 데이터그램의 전체 길이(헤더와 데이터)를 16비트로 나타낸다.
`식별(Identification)`: 단편화된 데이터그램을 재조합하는 데 사용되는 16비트 값으로, 각 데이터그램에 고유한 식별자를 할당한다.
`플래그(Flags)`: 데이터그램을 단편화할 때 사용되는 3비트로, 첫 번째 비트는 사용하지 않고 두 번째와 세 번째 비트만 사용한다.
`단편 오프셋(Fragment Offset)`: 단편 오프셋은 13비트로, 단편화된 데이터를 재조합할 때 위치를 지정한다.
`라이프 타임(Time to Live)`: 데이터그램이 네트워크에서 얼마나 오래 살아남을 수 있는지를 8비트로 나타내며, 라우터를 통과할 때마다 1씩 감소한다.
`프로토콜(Protocol)`: 데이터그램에서 전달하려는 상위 프로토콜을 식별하는 8비트 필드이다.
`검사합(Header Checksum)`: 헤더의 오류를 검출하는데 사용되는 16비트 값으로, 헤더의 잘못된 부분을 검출한다.
`송신지 주소(Source Address)`: 송신자의 IP 주소를 32비트로 나타냅니다.
`수신지 주소(Destination Address)`: 수신자의 IP 주소를 32비트로 나타냅니다.

데이터그램의 데이터는 말그대로 실제 데이터로, 전송되는 정보나 메시지 본체이다.

라우터 (Router)

스위치만 있는 네트워크에서는 모든 컴퓨터와 스위치가 동일한 네트워크에 속한다. 허브 또한 스위치처럼 네트워크를 분할할 수는 없다. 그러나, 라우터는 네트워크를 분할할 수 있다.

네트워크를 분할하고 다른 네트워크에 있는 컴퓨터로 데이터를 전송하기 위해서는 라우터의 IP 주소를 설정해야 한다. 이는 네트워크의 출입구를 설정하는 것으로 “기본 게이트웨이”라고 한다.

현재 네트워크에서 다른 네트워크로 데이터를 전송할 때, 라우팅의 경로 정보를 바탕으로 최적의 경로로 데이터를 전송하게 된다. 이는 각 라우터의 라우팅 테이블에 경로 정보가 등록이 되어있기에 가능한 것이다.

IPv6 (Internet Protocol v6)

인터넷의 폭발적인 성장으로 인해, 32비트로 구성된 IPv4 주소 공간은 이미 고갈된 상태이다. 이를 해결하기 위해 등장한 IPv6는 전 세계 60억 인구가 1인당 $53,731,028$개의 주소를 할당 받을 수 있기에 주소 부족 현상이 일어나지 않는다.

IPv6 특징

IPv6는 128비트로 구성되고, 16비트씩 콜론(:)으로 나누어 각 필드를 16진수로 표현하는 방식을 사용한다. IPv4에 비해 주소 공간 길이가 4배 가량 증가했다. IPv6는 옵션을 기본 헤더에서 분리하여 필요할 때마다 기본 헤더와 상위 계층 데이터 간에 새로운 확장 헤더를 삽입해서 사용 가능하다. 이로 인해 라우팅 및 네트워크 속도가 더 빠르다. 그리고 IPv4에 비해 더 향상된 보안 환경(IPSec)을 제공한다.

즉, IPv6의 장점은 다음과 같다.

확대된 주소 공간
단순해진 헤더 포맷
간편해진 주소 설정 기능
강화된 보안 기능
개선된 모바일 IP

IPv6 주소 체계

IPv6 주소의 128비트는 2바이트 영역 8개로 나뉘어서 이와 같이 표시된다. 2001:0db8:85a3:0000:0000:8a2e:0370:7334

이때, 앞의 64비트(2001:0db8:85a3:0000)는 네트워크 주소를 의미하고, 뒤의 64비트는 네트워크에 연결된 통신 장비 등에 할당되는 인터페이스 주소를 의미한다.

IPv6 헤더

IPv6의 각 패킷은 기본 헤더와 페이로드로 구성된다. IPv6의 헤더는 고정 길이 40바이트로 이루어진다. IPv6의 기본 헤더의 종류는 다음과 같다.

`버전(4비트)`: IP 버전을 나타내며, 값은 6에 해당한다.
`트래픽 클래스(8비트)`: IPv4의 TOS(Type of Service) 필드 명칭이 바뀐 것이다.
`플로 테이블(20비트)`: 미사용 필드로 일반적으로 0이 들어간다.
`페이로드 길이(16비트)`: IPv4의 전체 길이 필드 명칭이 바뀐 것이다.
`다음 헤더(8비트)`: IPv4의 프로토콜 필드 명칭이 바뀐 것이다.
`홉 제한(8비트)`: IPv4의 라이프타임 필드 명칭이 바뀐 것이다.
`송신지 IP 주소(128비트)`: 송신지의 IPv6 주소를 지정한다.
`수신지 IP 주소(128비트)`: 수신지의 IPv6 주소를 지정한다.

IPv6는 패킷 전송 시 평소에는 기본 IPv6 기본 헤더만으로 구성된 패킷을 사용하지만 필요시 용도에 맞게 확장 헤더를 기본 헤더 뒤에 추가하여 라우팅 효율을 증가시킬 수 있다.

`홉 바이 홉 옵션 헤더(Hop-by-Hop Options Header)`: 경로 상의 각 홉에서 처리할 옵션 지정
`라우팅 헤더(Routing Header)`: 패킷이 목적지에 가는 동안 경유해야 할 라우터 지정
`단편화 헤더(Fragment Header)`: 패킷 단편화 처리
`목적지 옵션 헤더(Destination Options Header)`: 목적지에서 처리할 옵션 지정
`AH(Authentication Header)`: IPSec의 인증 헤더
`ESP(Encapsulating Security Payload)`: IPSec의 암호화 헤더

IPv4에서 IPv6로의 전환 기술

인터넷에는 수많은 시스템으로 인해 IPv4에서 IPv6로의 전환은 오랜 시간이 필요하다. 모든 변환은 점진적으로 이루어져야 하는데, 전환 기술은 다음과 같다.

`응용 계층 게이트웨이 방식`: IPv6 클라이언트와 IPv4 서버 간 통신을 프록시 서버 등 응용 계층에서 중계하는 방식
`전송 계층 릴레이 방식`: TCP/UDP 통신을 릴레이 서버를 통해 중계하여 서로 다른 IP 체계 간 통신을 가능하게 하는 방식
`헤더 변환 방식`: IPv6 패킷 헤더를 IPv4로 변환하거나 반대로 변환하여 IP 계층에서 직접 통신을 가능하게 하는 방식

[컴퓨터 네트워크] - TCP/IP: 네트워크 계층 (Network Layer)

shineast_ — Wed, 30 Apr 2025 10:26:51 +0900

TCP/IP: 네트워크 계층

네트워크 계층의 필요성

데이터 링크 계층은 이더넷 규칙을 기반으로 데이터 전송을 담당하는데, 같은 네트워크에 있는 컴퓨터에는 데이터 전송이 가능하지만 다른 네트워크나 인터넷으로는 데이터를 전송할 수 없다. 서로 다른 네트워크 간의 통신을 가능하게 하는 것이 네트워크 계층이다. 네트워크 계층을 통해 다른 네트워크로 데이터를 전송하기 위해서는 라우터 네트워크 장치가 필요하다.

네트워크를 통해 데이터를 전송하기 위해서는 반드시 수신지 주소를 알아야 하는데, MAC 주소가 아닌 네트워크를 식별할 수 있는 주소가 필요하다. 이때 사용되는 것이 바로 IP 주소이다. IP 주소가 있으면 다른 네트워크에 있는 수신지 컴퓨터를 지정할 수 있다. 그리고 수신지 컴퓨터 IP 주소까지 어떤 경로로 데이터를 전송할지 결정하는 라우팅 과정도 필요한데, 라우팅 과정은 라우터가 담당한다.

네트워크 계층의 역할

네트워크 계층은 데이터를 전송할 수신 측의 주소를 찾고 수신된 데이터의 주소를 확인하여 자신의 것이면 전송 계층으로 전송한다. 데이터 링크 계층은 인접한 두 노드 사이의 전송을 담당하고, 네트워크 계층은 각 패킷이 송신지에서 최종 수신지까지 정확하게 전송되도록 경로를 책임진다. 이때, 네트워크 계층에서는 논리 주소인 IP 주소가 헤더에 포함되어 전송되기에 송신지에서 수신지까지 주소가 바뀌지 않고 유지된다.

네트워크 계층에서는 데이터를 전송하기 위해서 물리 링크를 임시로 연결하여 더 긴 링크를 만드는 “스위칭 작업”과 송신지에서 수신지로 패킷을 보낼 때 복수의 경로가 생기는 경우 최적의 경로를 찾는 “라우팅 서비스”도 제공한다. 결국 네트워크 계층의 기능은 다음과 같다.

`논리 주소 지정`: 송신지와 수신지 주소를 헤더에 포함한다.
`라우팅`: 다양한 경로 중 패킷의 경로를 설정한다.
`주소 변환`: 대응하는 물리 주소를 찾기 위해 논리 주소를 해석한다.
`다중화`: 하나의 물리적 회선만 사용하여 많은 장치에 데이터를 동시에 전송한다.
`패킷 순서 제어`: 도착하는 패킷의 순서를 바로잡아 상위 계층의 메시지를 재구성할 때 사용된다

네트워크 계층 프로토콜

TCP/IP에서 네트워크 계층 프로토콜은 IP, ARP, ICMP, IGMP로 구성된다. 전송 계층의 패킷은 세그먼트 형태로 네트워크 계층에 전송되고, 네트워크 계층의 데이터는 IP 헤더가 추가된 데이터그램으로 동작하는데 이와 같이 상위 계층의 패킷에 IP 주소 정보를 포함한 헤더를 추가하여 하위 계층으로 전송한다. 그리고 반대로 수신할 때는 하위 계층으로부터 받은 패킷의 헤더 정보를 확인하고 헤더를 제거하고 상위 계층으로 전송한다.

IPv4와 IPv6

IPv4와 IPv6에 대한 내용을 다룰 경우 분량이 과다해져서 다음의 포스팅에서 다룬다.

https://kangdy25.tistory.com/247

[컴퓨터 네트워크] - IPv4와 IPv6 (Internet Protocol)

IPv4 (Internet Protocol v4) 인터넷에 연결된 모든 컴퓨터는 고유 주소를 가지는데, 이를 IP 주소라 한다. IP 버전은 IPv4와 IPv6이 있다. IPv4는 32비트의 IP 주소로 $2^{34}$(약 43억)개의 컴퓨터에 할당 가능하

kangdy25.tistory.com

주소 변환 프로토콜 (ARP)

패킷이 수신 측 시스템에 도착하기 위해서는 물리적 네트워크를 통과하게 되기에, 수신 측의 논리 주소 뿐만 아니라 물리 주소도 알아야 한다. 이때, ARP는 IP 주소를 받아서 네트워크 카드의 물리 주소인 MAC 주소로 변환하는 프로토콜이다. 즉, 논리 주소인 IP 주소를 물리 주소인 MAC 주소로 매핑하는 것이 주소 변환 프로토콜(ARP)이다. IP 주소로 MAC 주소를 매핑하는 절차는 다음과 같다.

호스트 A가 동일 네트워크 내 호스트 B와 통신하려고 할 때, 목적지 IP 주소는 알고 있지만 해당 IP에 대응하는 MAC 주소를 모르는 경우, ARP 프로토콜을 통해 주소 해석을 시도한다.
호스트 A는 ARP Request 메시지를 생성하여 브로드캐스트(FF:FF:FF:FF:FF:FF) 방식으로 네트워크에 전송한다. 이때, 메시지에는 요청자의 IP 및 MAC 주소, 대상 IP 주소가 포함된다.
네트워크 상의 모든 호스트는 이 ARP Request를 수신하고, 요청된 IP 주소와 자신의 IP 주소를 비교한다.
해당 IP 주소를 보유한 호스트 B만이 ARP Reply 메시지를 생성하여, 요청자에게 유니캐스트 방식으로 응답한다. 이때, 응답에는 자신의 MAC 주소가 포함된다.
호스트 A는 응답으로 받은 MAC 주소를 자신의 ARP 캐시에 일정 시간 동안 저장하여, 이후 동일 대상과의 통신 시 재요청 없이 직접 MAC 주소를 사용할 수 있도록 한다.

역주소 변환 프로토콜 (RARP)

역주소 변환 프로토콜은 물리 주소인 MAC 주소를 IP 주소로 변환하는 것이다. 즉, 호스트의 물리 주소를 알고 있을 때, IP 주소를 알아내기 위해서 사용된다.

인터넷 제어 메시지 프로토콜 (ICMP)

인터넷 제어 메시지 프로토콜은 라우터에서 발생한 오류를 송신 측으로 전송하는데 사용하는 프로토콜이다. ICMP의 메시지는 질의 메시지와 오류 메시지로 분류된다. 일반적인 ICMP 질의 메시지의 유형은 다음과 같다.

에코 요청 및 응답 (Ping 테스트)
타임 스탬프 요청 및 응답
주소 마스크 요청 및 응답
라우터 요청 및 응답
리디렉션 메시지

일반적인 ICMP 오류 메시지의 유형은 다음과 같다.

목적지 도달 불가
시간 초과
매개변수 문제
송신지 억제
재지정

인터넷 그룹 메시지 프로토콜 (IGMP)

인터넷 그룹 메시지 프로토콜은 인터넷에 연결한 컴퓨터가 멀티캐스트 그룹을 주위의 라우터에 알릴 수 있는 수단을 제공하는 프로토콜이다. 멀티캐스팅은 네트워크의 한 호스트 컴퓨터가 미리 지정된 다수의 컴퓨터에 메시지를 보낼 수 있도록 허용한다.

인터넷 그룹 메시지 프로토콜의 동작 방식은 다음과 같다.

호스트가 멀티캐스트 그룹에 가입할 때, IGMP Membership Report 메시지를 전송한다.
라우터는 수신된 IGMP 정보를 바탕으로 멀티캐스트 트래픽을 전달할지 결정한다.
라우터는 주기적으로 IGMP Query 메시지를 전송하여, 여전히 그룹에 참여 중인 호스트가 있는지 확인한다.
만약 참여 중인 호스트가 응답하지 않으면, 해당 그룹에서 탈퇴된 것으로 간주한다.

[컴퓨터 네트워크] - TCP/IP: 네트워크 접속 계층 (Network Access Layer)

shineast_ — Mon, 28 Apr 2025 14:40:20 +0900

TCP/IP: 네트워크 접속 계층

TCP/IP 모델의 네트워크 접속 계층은 OSI 참조 모델의 물리 계층(1계층)과 데이터 링크 계층(2계층)에 해당한다.

물리 계층 (Physical Layer)

물리 계층은 두 시스템 간 데이터를 전송하기 위해 링크를 활성화하고 관리하는 물리적 특성들을 정의한다. 물리 계층은 허브, 라우터, LAN 카드, 케이블 등의 전송 매체를 통해 비트를 전송하고, 물리적 네트워크 장치의 사양은 물리 계층에 의해 결정된다.

물리 계층(1계층)은 상위 계층이 전송한 데이터를 물리적 매체를 통해 다른 시스템에 전기 신호로 전송한다. 물리 계층의 특성은 다음과 같다.

`기계적 특성`: 시스템과 주변장치를 연결하기 위해 정의한다.
`전기적 특성`: 두 시스템 간 상호 접속 회로의 전기적 특성 등을 정의한다.
`기능적 특성`: 상호 접속 회로의 기능을 정의한다.
`절차적 특성`: 데이터 전송에 필요한 순서를 정의한다.

물리 계층의 데이터 단위

물리 계층에서 데이터 단위는 “비트열의 데이터(비트)”이며, 데이터 단위를 전송하는 과정은 다음과 같다.

송신 측 물리 계층이 데이터 링크 계층에서 0과 1로 구성된 비트열의 데이터를 받아 전기 신호로 변환한다.
변환한 데이터를 전송 매체를 통해 수신 측으로 전송한다.
수신 측의 물리 계층이 전기 신호를 0과 1로 구성된 비트열로 복원하고 데이터 링크 계층으로 전송한다.

이때 물리 계층에서 수행하는 기능들은 여러 가지가 있는데, 다음과 같다.

`회선 구성 결정`: 2개 이상 장치의 회선 구성을 결정한다. (ex: 점대점, 다중점)
`데이터 전송 모드 결정`: 연결된 시스템 간의 데이터 전송 모드를 결정한다. (ex: 단방향, 양방향)
`접속 형태 결정`: 네트워크 접속 형태를 결정한다. (ex: 성형, 버스형, 트리형)
`전송 매체 유형 결정`: 데이터를 전송하는 물리적 장치를 결정한다.(ex: 허브, 케이블)

데이터 링크 계층 (Data Link Layer)

데이터 링크 계층은 물리적 링크를 이용하여 신뢰성 있는 데이터를 전송하는 계층이며, 네트워크를 통해 데이터를 전송할 때 전송로 역할을 한다. 데이터 링크 계층에서는 물리 계층에서 발생하는 오류를 검출하고 복구하며, 동기화 및 흐름 제어 기능, 데이터 양 조절 기능을 제공한다.

데이터 링크 계층은 물리 계층의 바로 위에 위치한다. 데이터 링크 계층에서는 3계층인 네트워크 계층으로부터 받은 데이터 단위에 의미 있는 비트를 시작 부분(헤더)과 끝 부분(트레일러)에 추가한다.

데이터 링크 계층의 데이터 단위

데이터 링크 계층에서는 비트를 “프레임”이라는 논리적 단위로 구성한다. 즉, 데이터 링크 계층에서 데이터 단위는 “프레임”이다. 데이터 링크 계층에서 수행되는 기능들은 다음과 같다.

`주소 지정`: 데이터 링크 계층에서 추가되는 헤더와 트레일러 부분에는 최근 데이터가 지나온 노드와 다음에 접근할 노드의 물리 주소가 포함된다.
`순서 제어`: 데이터를 순차적으로 전송하기 위해 프레임 번호 부여 기능을 수행한다.
`흐름 제어`: 한 번에 전송 가능한 데이터 양을 조절하고, 프레임을 전송할 때 수신 여부를 확인하는 기능을 수행한다.
`오류 처리`: 오류 검출 및 정정 기능을 수행하고, 프레임의 재전송을 요구할 . 수있다.
`프레임`: 데이터를 전송할 때 프레임 단위로 전송한다.
`동기화`: 데이터의 헤더에는 수신 측에 프레임이 도착했다는 비트가 있고, 트레일러에는 프레임의 끝을 나타내는 비트와 오류를 제어하는 비트가 있다.
`데이터 링크 설정`: 헤더와 트레일러에는 송수신측 주소 정보가 포함되는데, 수신 측의 데이터 링크 계층에서 헤더와 트레일러를 삭제하고 수신 측의 네트워크 계층으로 전송한다.

스위치 (Switch)

데이터 링크 계층에서는 네트워크 접속 장치 간 신호를 주고받는 규칙을 정한다. 이때, 일반적으로 사용되는 규칙은 이더넷이다. 이더넷은 여러 컴퓨터가 동시에 데이터를 전송해도 충돌이 발생하지 않도록 하는 구조로, CSMA/CD 방식을 사용한다. 그러나 최근에는 효율이 좋지 않아 CSMA/CD를 거의 사용하지 않으며 네트워크 충돌이 일어나지 않는 “스위치”를 사용한다.

스위치는 데이터를 동시에 송수신할 수 있는 전이중 통신 방식으로 충돌이 발생하지 않으며, 충돌이 발생할 때 영향이 미치는 범위(충돌 도메인)도 좁다.

[소프트웨어 공학] - UML: 동적 모델링 다이어그램 (Dynamic Diagram)

shineast_ — Tue, 22 Apr 2025 03:27:38 +0900

동적 모델링 다이어그램 (Dynamic Modeling Diagram)

동적 모델링은 소프트웨어가 실행될 때마다 변경될 수 있는 “동적 측면”을 모델링하는 것이다. 소프트웨어의 동적 측면은 시간의 함수로 이해할 수 있다. 동적 모델링 다이어그램은 정적인 클래스 다이어그램을 보완한다.

즉, 클래스 다이어그램은 소프트웨어의 정적 구조를 모델링하고, 여러 동적 다이어그램은 말그대로 동적 동작들을 모델링한다. 주로 시스템 전체 동작과 오퍼레이션을 모델링할 때 주로 동적 모델링 다이어그램을 사용한다. 대표적인 동적 모델링 다이어그램의 종류는 다음과 같다.

다이어그램	설명	사용 시점
시퀀스 다이어그램 (Sequence Diagram)	시스템 내 객체 간의 메시지 교환 순서를 시간 흐름에 따라 표현한다.	기능 구현, 시스템 동작 분석, 시나리오 설명
커뮤니케이션 다이어그램 (Communication Diagram)	객체 간의 메시지 교환과 관계를 강조하며, 객체들 간의 상호작용을 나타낸다.	시스템 상호작용 분석, 객체 간 관계 파악
상태 다이어그램 (State Diagram)	객체가 가질 수 있는 상태와 상태 간의 전환을 표현한다.	객체의 상태 변화 분석, 이벤트 기반 시스템 설계
액티비티 다이어그램 (Activity Diagram)	시스템의 활동 흐름을 나타내며, 병렬 처리나 조건 분기를 다룰 때 사용한다.	비즈니스 프로세스 흐름, 시스템 활동 흐름 분석

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

시퀀스 다이어그램은 메시지 교환을 시간적 관계로 나타낸 것으로, 시스템이 어떤 방식으로 동작하는지 시각화한다. 즉, 메세지의 상대적 순서를 더 쉽게 볼 수 있도록 한다.

시퀀스 다이어그램의 기본 요소

시퀀스 다이어그램의 기본 요소들은 다음과 같다.

`객체(Object)`: 상호작용에 참여하는 주체로, 보통 클래스의 인스턴스를 의미한다.
`생명선(Lifeline)`: 객체가 존재하는 기간을 의미하며 수직선으로 나타낸다. 시간은 위에서 아래로 흐름
`활성 막대(Activation Bar)`: 객체가 메시지를 처리하는 동안 활성화 되어 있는 시간을 말한다.
`메시지(Message)`: 객체 간에 주고받는 동기/비동기 메시지나 메서드를 호출한다.
`반환 메시지(Return Message)`: 호출에 대한 응답 또는 반환값이다.
`프레임(Frame)`: 조건 분기, 반복 등 제어 흐름을 표현한다. (alt, loop)
`객체 소멸(Destroy)`: 객체의 생명 주기가 종료되는 시점으로, 생명선 끝에 'X'로 표시된다.

시퀀스 다이어그램의 작성 과정

참여하는 객체를 파악한다
파악한 객체를 X축에 나열하고 라이프라인을 긋는다.
유스케이스에 기술된 이벤트 순서에 따라 객체의 메시지 호출을 화살표로 나타낸다.

커뮤니케이션 다이어그램 (Communication Diagram)

커뮤니케이션 다이어그램은 상호작용에 참여하는 객체의 정적인 구조를 더욱 잘 보여준다. 커뮤니케이션 다이어그램은 협동 다이어그램이라고도 불린다. 커뮤니케이션 다이어그램은 시퀀스 다이어그램과 본질적으로는 같은 의미를 가지나, 표현 방식이 살짝 다르다. 커뮤니케이션 다이어그램은 “상호작용에 필요한 객체들 간의 링크를 포함한 객체 다이어그램”과 “상호작용을 정의하는 객체 간의 메시지”를 조합한 것이다.

커뮤니케이션 다이어그램의 기본 요소

커뮤니케이션 다이어그램의 기본 요소들은 다음과 같다.

`객체(Object)`: 메시지를 주고받는 주체로 사각형으로 표현한다. (객체명 : 클래스명)
`링크(Link)`: 객체들 간의 연결로, 객체 간의 관계(연관)를 표현한다.
`메시지(Message)`: 객체 간 전달되는 메시지이다. 이때, 메시지는 “화살표 + 메시지 내용”으로 표기한다.
`메시지 순서 번호(Message Sequence Number)`: 실행 순서를 명확하게 하기 위해 숫자를 붙인다. 만약 중첩 호출이 있다면 소수점을 사용한다. (Ex: 1 → 1.1 → 1.1.1)

상태 다이어그램 (State Diagram)

상태 다이어그램은 시스템의 동작을 “수신 이벤트”와 이에 대한 “응답”을 기반으로 상태 사이의 전환으로 모델링을 진행한다. 즉, 상태 다이어그램은 어떤 “사건(event)”에 의해 어떻게 “변환(transition)”되는지를 표현한 다이어그램이다.

상태 다이어그램의 기본 요소

상태 다이어그램의 기본 요소들은 다음과 같다.

`상태(State)`: 객체가 특정 시점에 가지고 있는 조건이나 상황을 말한다. 끝이 둥근 사각형으로 표현하며, 내부에 상태 이름이나 상태 안에서 수행하는 행동을 적을 수 있다.
`시작 상태(Initial State)`: 상태 다이어그램의 시작 지점으로, 시스템이 시작되었을 때 머무르는 가상의 상태이다. 검은 동그라미(●)로 표시한다.
`종료 상태(Final State)`: 상태 다이어그램의 끝 지점으로, 시스템이 종료되었음을 나타내는 상태이다. 원 안에 원이 들어간 형태(◎)로 표시한다.
`이벤트(Event)`: 상태를 변화시키는 외부 또는 내부의 트리거이다. (Ex. 버튼 클릭, 요청 발생)
`변환(Transition)`: 이벤트에 의하여 한 상태에서 다른 상태로의 변화를 말하며, 화살표로 표현한다.

상태 다이어그램 작성을 위한 준비

서브 시스템이나 객체가 어떤 상태를 가질 수 있는지 파악한다.
외부 이벤트나 오퍼레이션이 무엇인지 파악한다.
어떤 상태에서 어떤 이벤트에 의하여 어떤 상태로 변화하는지 파악한다.

액티비티 다이어그램 (Activity Diagram)

액티비티 다이어그램은 알고리즘 또는 프로세스에서 작업 절차를 모델링한다. 업무 프로세스, 로직 흐름, 사용자의 행동 흐름 등을 시각화할 때 사용하며 흐름도(flowchart)와 유사하다.

액티비티 다이어그램의 기본 요소

액티비티 다이어그램의 기본 요소들은 다음과 같다.

`액티비티(Activity / Action)`: 수행되는 작업 또는 행동을 의미하며, 둥근 모서리 사각형으로 표시됨
`초기 노드(Initial Node)`: 흐름의 시작 지점으로, 원(●)으로 표현한다.
`종료 노드(Final Node)`: 흐름의 종료 지점으로, 원 안에 원이 있는 형태(◎)로 표현한다.
`제어 흐름(Control Flow)`: 액티비티 간의 순서를 나타내며, 화살표로 표현한다.
`분기 노드(Decision Node)`: 조건에 따라 흐름이 갈라지는 지점으로, 마름모(◆) 모양으로 표현한다.
`병합 노드(Merge Node)`: 분기된 흐름을 다시 합치는 노드로, 분기 노드와 동일하게 마름모로 표현한다.
`포크(Fork) & 조인(Join) 노드`: 병렬 수행을 표현하는 기능으로 포크 & 조인 표기법으로 나타낸다.
- `포크(Fork)`: 한 흐름 → 여러 흐름으로 나눔 (병렬 처리 시작)
- `조인(Join)`: 여러 흐름 → 하나로 합침 (병렬 처리 종료)

[소프트웨어 공학] - UML: 정적 모델링 다이어그램 (Static Diagram)

shineast_ — Mon, 21 Apr 2025 17:00:45 +0900

정적 모델링 다이어그램 (Static Modeling Diagram)

UML에서 정적 모델링이란 객체들의 공통 구조와 동작들을 추상화(모델링)시킨 것으로, 객체지향 개념으로부터 시작한다. 즉, 객체지향의 핵심 개념(클래스, 객체, 캡슐화, 상속 등)을 시각적으로 표현한 것이 정적 모델링이다. 대표적인 정적 모델링 다이어그램의 종류는 다음과 같다.

다이어그램	설명	사용 시점
클래스 다이어그램 (Class Diagram)	시스템의 클래스와 클래스 간의 관계를 표현한다.	설계 단계 (특히 상세 설계)
객체 다이어그램 (Object Diagram)	클래스 다이어그램을 바탕으로 특정 시점의 객체 상태를 보여준다.	설계 or 테스트 시나리오 설명
컴포넌트 다이어그램 (Component Diagram)	시스템을 구성하는 컴포넌트(모듈) 간의 의존 관계를 표현한다.	아키텍처 설계 단계
배치 다이어그램 (Deployment Diagram)	하드웨어와 소프트웨어의 배치 구조를 표현한다. (서버, DB 등)	배포/운영 설계 단계
패키지 다이어그램 (Package Diagram)	클래스나 컴포넌트를 패키지 단위로 묶어서 구조를 표현한다.	대규모 시스템의 구조 설명

클래스 다이어그램 (Class Diagram)

UML에서 정적 모델링을 표현할 때, 주로 “클래스 다이어그램”을 사용한다. 시스템의 도메인 개념을 나타낼 때 사용하고, 클래스 사이의 관계를 나타낸다. 클래스 다이어그램을 그린다는 것은 응용 문제를 개념화하는 것이고, 이때 “분류(Classification)” 과정이 중요하다. 클래스 다이어그램은 시스템 내에서 시간 요소가 없는 모델인 “정적 측면”을 모델링한다.

클래스 (Class)

UML에서 클래스는 박스로 나타내고, 박스 안에는 클래스 이름을 표시한다. 박스 안에서 3개의 구역으로 나누어, 클래스 이름, 속성, 오퍼레이션을 나타낼 수 있도록 한다.

속성 (Attribute)

클래스가 갖고 있는 자료에 이름을 붙인 것이 속성이다. 이때, 속성의 형식은 주로 다음과 같이 나타낸다.

NOTE!
속성 형식: 가시성 / 변수 이름 : 타입 다중성 = 디폴트값 {속성}

`가시성(Visibility)`: 속성에 대한 접근성을 나타낸다.(Ex: public, private, protected … )
`속성 이름(Attribute Name)`: 속성을 나타내는 명사로 구성된 이름 (EX: name, age, … )
`타입(Type)`: 속성의 타입 (Ex: String, int, … )
`다중성(Multiplicity)`: 자료가 참조하는 객체의 수 (Ex: 1, 0..1, 1..*, … )
`디폴트(Default Value)`: 클래스 인스턴스가 생성될 때 속성에 할당되는 기본 값
`속성(Attirbute)`: 속성에 대한 추가 속성 (Ex: ordered, unordered, unique)

오퍼레이션 (Operation)

오퍼레이션은 클래스의 동작을 의미하며, 클래스에 속하는 객체에 대해 적용될 메서드를 정의한 것이다. 오퍼레이션은 동작에 대한 인터페이스를 지칭한다. 이때, 오퍼레이션의 형식은 주로 다음과 같이 나타낸다.

NOTE!
오퍼레이션 형식: 가시성 오퍼레이션 이름(매개변수, ) : 반환 타입 { 속성 }

`가시성(Visibility)`: 오퍼레이션에 대한 접근 수준을 나타낸다. (Ex: public, private, protected, package)
`오퍼레이션 이름(Operation Name)`: 동작을 의미하는 동사 형태의 이름을 말한다. (Ex: calculateSalary, getName, printReport)
`매개변수(Parameter)`: 오퍼레이션 수행에 필요한 입력 값들로, 이름과 타입을 함께 명시한다. (Ex: base: int, bonus: int)
`반환 타입(Return Type)`: 오퍼레이션 실행 결과의 데이터 타입 (Ex: int, String, void)

정적 속성과 오퍼레이션 (Static Attribute/Operation)

속성과 오퍼레이션은 클래스 또는 클래스의 객체와 연관될 수 있다. 이때, 클래스와 연관되는 속성을 클래스 속성이라 하고 값은 해당 클래스의 모든 객체 사이에 공유된다. 그리고 클래스의 오브젝트와 연관된 속성을 인스턴스 속성이라 하며 값은 객체마다 다르다.

오퍼레이션 또한 정적으로 선언 가능하고, 정적 오퍼레이션은 클래스와 연관되어 정적 속성만 접근 가능하다. 정적이 아닌 오퍼레이션은 각 객체와 관련되어 호출된 객체에 대해 작동한다.

정적 속성과 오퍼레이션은 밑줄을 그어 구별한다.

관계 (Relationship)

클래스 다이어그램은 클래스 요소와 관계를 보여준다. 이때 관계란 클래스 단위 또는 객체 사이의 관계로 네 가지가 있다. 각 네 가지 유형의 관계는 선 및 화살표 스타일로 구분된다.

`연관(Association)`: 객체 사이에 관련되어 연결되어 있음을 의미한다. 연관은 시간이 지나도 유지되는 관게이다. 구조적으로 연관을 맺어 정보를 참조하는 관계이다. 연관은 두 클래스 사이에 실선으로 표시한다. 이때, 화살표가 있는 경우는 단방향으로 탐색이 가능하다는 것이고, 화살표가 없으면 양방향 탐색이 가능하다는 것이다. (Student — Lecture)
`상속(Generalization)`: 일반화 관계로, 자식 클래스가 부모 클래스의 속성과 오퍼레이션을 상속받는 관계이다. 실선 삼각형 화살표로 표시하며, 화살표 방향은 구체적인 클래스로부터 일반적인 클래스로 간다. (Rectangle → Shape)
`의존(Dependency)`: 한 클래스가 다른 클래스의 기능을 일시적으로 사용하는 관계로, 클래스 간의 약한 결합을 나타낸다. 한 클래스의 변경으로 인해 다른 클래스의 변경이 필요할 수 있는 의존성을 나타낸다. 의존은 점선 화살표로 표시한다. (Order - → Payment)
`구현(Implement)`: 인터페이스와 이를 구현하는 클래스 간의 관계를 나타낸다. 즉, 정의된 인터페이스를 구현 관계의 클래스에서 구현하고 인터페이스가 사용된 곳에서는 인터페이스를 구현하는 모든 클래스의 인스턴스가 사용될 수 있다. 구현 관계는 점선 삼각형 화살표로 표시한다. (Circle - → Drawable)

[소프트웨어 공학] - 유스케이스와 UML (Use Case & UML)

shineast_ — Sat, 19 Apr 2025 21:13:29 +0900

유스케이스 (Use Case)

유스케이스란 시스템이 제공해야 할 기능을 사용자 중심으로 설명하는 방법으로, 시스템의 동작을 모형화하는 것이다. 유스케이스는 액터, 시스템 범위, 유스케이스, 관계 이렇게 네 가지 요소로 결합된 것으로 각각의 요소의 의미와 관계를 잘 이해하는 것이 중요하다. 유스케이스 분석 작업은 다음의 과정으로 이루어진다.

액터 찾기
유스케이스 찾기
유스케이스 사이의 관계 찾기

이 과정을 통해서 유스케이스 다이어그램과 유스케이스 명세가 완성된다.

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

유스케이스 다이어그램은 시스템의 기능을 나타내기 위해 사용자의 요구를 추출하고 분석하기 위해 사용하는 그림으로, 외부에서 보는 시스템의 동작에 초점을 맞춘다. 유스케이스 다이어그램은 “액터(Actor)”와 “유스케이스(Use Case)”로 구성된다. 액터는 시스템과 상호 작용하는 시스템 환경, 유스케이스는 액터에게 보이는 시스템의 기능을 나타낸다. 유스케이스와 액터를 정하는 것이 곧 시스템의 범위를 정하는 것이다.

액터 (Actor)

액터는 시스템과 상호작용하는 외부 엔티티로, 역할을 추상화한 것이다. 액터는 대상 시스템으로부터 서비스를 제공받거나 제공한다. 예를 들어 대학 수강 신청 시스템에서는 “학생”, “교수”, “교직원” 이렇게 세 가지 액터가 존재할 수 있다. 유스케이스 모델링의 첫 단계는 액터를 찾는 것이다. 이때 액터를 찾기 위하여 다음의 질문을 던지는 것이 좋다.

어떤 사용자들이 작업을 수행하기 위해 시스템의 지원을 받는가?
어떤 사용자들이 시스템의 주요 기능을 사용하는가?
어떤 사용자 그룹이 유지 보수와 관리 등의 부수적 기능을 사용하는가?
시스템이 어떤 외부 하드웨어나 소프트웨어 시스템과 동작하는가?

유스케이스 (Use Case)

유스케이스는 시스템이 실행하는 일련의 동작을 말하며, 특정 액터에게 관찰 가능한 실행 결과를 제공한다. 즉, 유스케이스는 시스템의 단위 기능이며, 시스템의 기능은 서로 다른 유스케이스에 의해서 정의되고 각 유스케이스는 특정 이벤트 흐름을 나타낸다.

예를 들어 대학 수강 신청 시스템에서 “학생” 액터와 관련된 작업은 과목 추가, 수강 취소, 개설 강의 보기 등이고, “교수” 액터와 관련된 작업은 개설 강의 보기, 수강생 보기, 강의할 과목 선택 등이다. 유스케이스를 찾기 위해서 던져보면 좋을 질문들은 다음과 같다.

찾아낸 각 액터에 대해 시스템과 관련된 작업은 무엇인가?
시스템에서 발생되는 특정 사건에 대해 액터에게 알려야 하는가?
시스템이 비지니스에 정확한 동작을 제공하는가?
찾아낸 유스케이스로 모든 기능을 수행할 수 있는가?
어떤 유스케이스가 시스템을 지원하고 유지보수하는가?

유스케이스 명세 (Use Case Specification)

유스케이스는 대상 시스템이 제공하여야 할 서비스가 시간이 경과되는 순서로 정렬하여 사용자와 시스템의 상호작용을 파악하여 기능을 설명하는 방법인데, 이때 유스케이스는 여러 개발 시나리오를 묶어서 일반화한 것이다. 유스케이스 다이어그램은 시각적으로 전체 흐름과 관계를 보여준다면, 유스케이스 명세는 각각의 유스케이스를 텍스트 기반으로 자세히 설명한다.

유스케이스의 이벤트 흐름에는 유스케이스 명세 작업에서 가장 중요한 정보들이 포함이 된다. 이벤트 흐름의 일부를 분리 추출하여 따로 설명하면 이벤트 흐름의 가독성을 높일 수 있고 유스케이스 모델 구조를 개선할 수 있다. 이벤트 흐름을 분리하는 방법은 다음이 있다.

`대안 흐름`: 기본 유스케이스에서 이벤트의 흐름이 약간 변형되거나 선택 또는 예외인 경우 대안 흐름으로 분리한다.
`포함 관계`: 다른 유스케이스에서 재사용 가능하도록 캡슐화 하려는 경우, 포함 관계로 분리하여 명시한다.
`확장 관계`: 기본 유스케이스에 묵시적으로 포함된 이벤트로, 기본 유스케이스의 기본 이벤트 흐름이 특정 조건에 만족되었을 때 분리 확장된다. 기본 유스케이스의 설명에서 플로우를 숨겨 덜 복잡하게 한다.
`Etc`: 위의 방법에 포함되지 않는 경우로, 이벤트의 기본 흐름에서 하위 흐름이 있을 수 있다.

요구 모델링 (Requirements Modeling)

모델링은 대상을 파악해 나가면서 특정 관점에 해당하는 요소를 찾아내어 시각적으로 표현한 것이다. 반면, 요구 분석은 “고객의 요구를 만족시키기 위한 사양”, “시스템을 구축하기에 충분한 정보를 제공하는 사양”을 만족시키는 시스템 사용을 작성하는 프로세스이다.

이 두 가지의 의미가 합쳐진 요구 모델링은 이 속성을 만족하는 시스템 명세를 시각적으로 작성하는 작업이다. 결국, 요구 모델링은 요구를 만족시키기 위해 대상 시스템이 가져야 할 동작이나 구조를 나타내는 것이다.

UML (Unified Modeling Language)

UML의 정의 (Concept of UML)

소프트웨어 모델을 표현하기 위해 보편적으로 사용되는 것이 UML이다. UML은 소프트웨어 모델링에 사용되는 실질적 표준이며 소프트웨어 모델링의 공통 언어이다. UML이 도입될 때, UML의 초안은 다음 세 가지 주요 객체지향 방법론의 표기법이 결합된 것이었다.

`Grady Booch의 방법론`
`James Rumbaugh의 Object-Modeling Technique(OMT)`
`Ivar Jacobson의 Object-Oriented Software Engineering(OOSE)`

UML은 객체지향 방식에서 진화했기에 객체지향 스타일의 모델링, 설계, 프로그래밍을 지원한다.

UML 다이어그램 (UML Diagram)

UML은 소프트웨어 모델링의 표기법이지 소프트웨어 구성 방법론은 아니다. UML에서는 유스케이스가 주도하고 아키텍쳐 중심적이며 반복, 점진적 개발 프로세스를 권장한다.

UML 2.x는 13개의 다이어그램 유형을 정의한다. 6개는 구조 유형(클래스, 객체, 컴포넌트, 배치, 패키지, 컴포지트 구조), 7개는 동작 유형(유스, 액티비티, 상태, 시퀀스, 커뮤니케이션, 인터랙션 오버뷰, 타이밍)이다. UML을 이용하면 정적, 동적 두 가지 관점의 모델링을 할 수 있다. UML 모델링 과정은 다음의 프로세스로 이루어진다.

요구를 유스케이스로 정리하고 유스케이스 다이어그램을 작성한다.
클래스 후보를 찾아내고 개념적인 도메인 모델을 작성한다.
유스케이스를 기초하여 시퀀스 다이어그램을 작성한다.
클래스의 속성, 오퍼레이션 및 클래스 사이의 관계를 찾아 도메인 모델을 완성한다.
상태 다이어그램이나 액티비티 다이어그램 등 다른 다이어그램을 추가하여 UML 모델을 완성한다.
서브시스템을 파악하고 전체 시스템 구조를 설계한다.
적당한 객체를 찾아내거나 커스텀화 또는 객체를 다시 새로 설계한다.

모델 검증 (Model Validation)

요구를 모델로 표현하는 작업에는 반드시 모델링이 올바르게 되었는지 확인하는 과정이 필요하다. 모델을 검증하는 방법으로는 여러 가지가 있다.

`리뷰 (Review)`: 워크스루, 인스펙션 등 사람이 눈으로 확인하는 방법으로, 체크리스트를 이용한다.
`정형적 방법 (Formal Methods)`: 요구가 정확하고 모델이 일관성이 있음을 수학적으로 증명하는 방법이다.
`프로토타이핑 (Prototyping)`: 예상대로 동작함을 보이기 위해 모델을 기반으로 프로토타입을 제작한다.
`요구 추적 (Requirements Traceability)`: 모델로부터 요구를 거꾸로 추적하는 방법이다.

또한 UML 다이어그램 한쪽에 표현된 사실이 다른 UML 다이어그램의 정보와 모순되지 않아야 하며, 모델 사이에 불일치가 없는지 교차하여 검토한다.

[소프트웨어 공학] - 요구 분석(Requirements Analysis)

shineast_ — Mon, 14 Apr 2025 13:43:31 +0900

요구의 정의 (Concept of Requirements)

요구란 시스템이 무엇을 해야 하며 어떤 특징을 가져야 하는지 명확히 정의한 것이다. 문제 해결을 위해서는 반드시 먼저 사용자의 요구를 이해하는 단계를 가져야 한다. 이것이 바로 요구 분석이다. 사용자가 진정으로 원하는 요구를 찾는 것은 쉽지 않은데, 프로젝트의 이해 당사자들이 생각하는 비지니스 우선순위가 다르고 시스템에 요구하는 역량이 다르기 때문이다.

요구 분석 단계에서는 “제약(Constraint)”도 고려해야 하는데, 이는 정치적이거나 사업적인 고려에 의한다. 제약 사항은 소프트웨어 시스템의 해결책을 제한한다. 요구와 제약은 요구 분석 명세서에 잘 정리되어야 한다. 소프트웨어에 대한 요구는 크게 기능 요구와 비기능 요구로 분류된다.

기능 요구 (Functional Requirements)

기능 요구는 개발할 시스템이 무엇인지 표현하며, 시스템이 외형적으로 나타내는 기능과 동작을 말한다. 기능 요구는 시스템과 외부 요소들 사이의 상호작용으로, 기능적 요구를 결정할 때는 시스템이 특정 상황에서 어떤 반응을 하는지 기술해야 한다.

요구 분석의 표준인 IEEE 표준 830에는 기능 요구에 포함되어야 할 사항을 제시한다.

입력의 검증(Input Validation)
정확한 작업 순서(Accurate Operation Order)
비정상적인 상태에 대한 응답 및 복구(Handling and Recovery)
매개변수의 유효성(Validity of Parameters)
입출력 관계(I/O Relationship)

기능 요구는 외부 사용자에게 직접적인 혜택을 줄 수 있는 시스템의 기능들이다. 이때, 기능 요구의 항목들은 사용자의 문제를 해결하기 위한 구현 기술과는 독립적이다. 시스템이 무엇인지, 어떤 기능을 가지는지 기술하면 된다.

비기능 요구 (Non-Functional Requirements)

비기능 요구는 시스템이 제공하는 기능에 직접 관련되지 않은 요구를 말하며, 시스템 구축에 대한 성능, 보안, 품질, 안전 등이 그 예시이다. 비기능 요구는 소프트웨어에 대한 다양한 제약 조건이며 대표적인 조건들로는 다음이 있다.

`성능 요구`: 시스템의 효율성에 대한 요구이다.
`품질 요구`: 시스템의 품질 특성에 관한 요구이다.
`안전 요구`: 의도하지 않은 동작을 방지하는 요구이다.
`보안 요구`: 시스템 자원을 악의적인 공격으로부터 보호하도록 하는 요구이다.
`사용성 요구`: 시스템의 외부 요소와 상호작용할 때 제공되어야 할 보고 느끼는 것에 대한 요구이다.

요구 추출 (Requirement Elicitation)

요구 추출은 사용자가 무엇을 원하는지 결정을 내리는 작업이다. 요구를 추출하기 위해서는 다음 세 가지 단계의 작업을 진행한다.

요구에 대한 정보 출처 파악: 사용자가 진정 무엇을 원하는지 알기 위해 질문들을 여러 형태로 묻는다.
요구에 대한 정보 취합: 소프트웨어 응용 분야에 대한 정보를 모은다. 이러한 정보 조각들은 응용 문제를 이해하고 요구와 제한을 추출할 때 도움이 된다.
요구와 제한 사항 정리: 취합된 정보는 분석 과정을 통해 우선순위가 정해지고 요구와 제한으로 정리된다.

요구 추출의 방법

요구는 누구나 알고 있는 사실이 아니기에 여러 방법을 동원하여 정보들을 추출해야 한다. 요구를 추출하는 방법들은 다음이 있다.

`고객의 발표`: 고객의 발표는 개발 팀에게 고객의 업무를 소개하고 의심되는 것을 명확히 한다. 발표를 통해 시스템에 대해 초기에 개념을 잡기 쉽다.
`문헌 양식 조사`: 유사한 프로젝트를 조사하거나 업무 문서나 양식을 조사하여 현재 업무, 시스템에 대해 깊이 이해할 수 있다. 즉, 새로운 시스템의 설계와 구현은 유사 시스템의 설계와 구현을 할 때 혜택을 받을 수 있다.
`인터뷰 및 설문`: 인터뷰와 설문은 질문지를 만들어 직접 사용자나 고객을 만나 요구 사항을 듣는 것이다. 시스템에 대한 기대와 요구 사항을 질문하여 조사를 할 수 있다.
`브레인스토밍`: 이슈에 대한 아이디어를 쏟아놓는 회의로, 여러 명으로부터 정보를 얻는 효과적인 방법이다.
`프로토타이핑`: 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램으로, 소프트웨어 엔지니어의 아이디어에 대한 피드백을 조기에 받아 요구 사항을 취합한다.

요구 분석 (Requirements Analysis)

요구 품질

도출한 요구 후보들을 분석하고 결정하여 요구로 확정한다. 이때, 확정된 요구 사항이 다음의 성질이 있는지 분석해야 한다.

`원자적(Atomic)`: 요구 사항이 복합된 목적이 아니라 단일 목적을 가지는 성질
`완전성(Complete)`: 요구 사항 안에 정의된 것이 정보의 모든 것을 포함하는 성질
`통일성(Consistent)`: 명확하지 않는 것을 기술하지 않고, 같은 내용을 다르게 언급하지 않는 성질
`추적성(Traceble)`: 요구 사항을 쉽게 추적할 수 있도록 하는 성질
`우선순위화(Prioritize)`: 요구 사항의 중요도를 파악할 수 있는 성질
`테스트 가능성(Testable)`: 요구 사항이 검증 가능하도록 기술되어 있는 성질

도메인 분석

도메인은 요구의 배경을 말한다. 문제가 발생했을 때 이를 해결하기 위해서는 “문자 자체를 이해해야 하며” 또한 “배경(도메인)을 이해해야 한다.” 도메인을 분석하는 것은 설계 모델링에 필요한 여러 개념과 비즈니스 규칙을 파악하기 위함이다. 도메인 분석은 요구의 배경을 알아보는 것이다. 이때, 도메인의 배경을 알아내기 위해서는 다음의 세 가지 단계의 작업이 필요하다.

`도메인 개념 찾기`: 도메인 개념은 도메인을 구성하는 객체, 프로세스, 사람, 규칙들을 말한다. 프로젝트 초기에 정확한 개념을 세우기 위하여 용어를 바르게 정의하는 것이 중요하다.
`도메인 사전 작성`: 사전은 시스템과 관련된 도메인 개념을 조직화한 것이다. 도메인 사전을 작성하기 위해 많은 정보들을 모아야 한다.
`비즈니스 규칙 정리`: 비즈니스 규칙은 업무에서 지키기로 정한 규칙이다.

시나리오 기반 분석

시나리오 기반 분석은 개발자와 사용자 사이의 “서로 다른 전문 영역의 용어에 대한 이해와 해석”을 넘어 원할한 커뮤니케이션이 이루어지게 한다. 시나리오를 작성할 때, 5W1H 방식으로 표현하는 것이 효과적이다. 소프트웨어에 대한 시나리오를 언제(When), 어디서(Where), 누가(Who), 무슨 서비스를(What), 왜(Why) 제공하는지 어떻게(How) 동작하는지 기술한다.

요구 명세 및 검증

요구 명세 (Requirements Specification)

분석한 요구 사항을 모두 빠짐없이 명확하게 작성하는 것을 명세하고 한다. 명세한 문서를 요구분석 명세서(SRS)라고 하는데, SRS에는 대상 시스템이 무엇을 수행하는지에 대해서 기술한다. 시스템이 이룰 목표를 기술하지 목표를 달성하기 위한 해결 방법을 기술하는 것은 아니다.

요구 명세는 “시스템이 수행할 모든 기능”과 “시스템에 영향을 미치는 제약 조건”을 명확하게 기술한다. 이때 요구분석 명세서에는 설계를 나타내면 안 된다. 요구사항을 쉽게 참조 가능하도록 고유의 식별자를 가지도록 번호화하고, 요구사항의 우선순위를 정해야 한다.

요구 검증 (Requirements Validation)

요구 검증이란 사용자 요구가 요구분석 명세서에 올바르게 기술되었는지 검토하는 활동을 말한다. 초기 단계에서 검토를 잘해야 나중에 수정할 때 드는 비용들을 절감할 수 있다. SRS에 기술한 요구를 검증할 때 체크해야 하는 내용들은 다음과 같다.

`이해용이성(Comprehensibility)`: 요구 명세서를 읽을 때 요구의 의미를 잘 이해할 수 있는가?
`중복(Redundancy)`: 필요없이 중복된 부분이 없는가?
`완전성(Completeness)`: 빠진 요구가 없는지, 요구를 기술하는데 빠진 정보가 없는가?
`일관성(Consistency)`: 요구사항이 서로 모순되지 않는가?
`모호성(Ambiguity)`: 요구분석의 내용이 모호함 없이 모든 참여자들에 의해 명확하게 이해될 수 있는가?
`검증 가능성(Verifiable)`: 요구분석 명세서에 기술된 내용이 사용자의 요구를 만족하는가? 개발된 시스템이 요구사항 분석 내용과 일치하는지를 검증할 수 있는가?
`추적 가능성(Traceable)`: 시스템 요구사항과 시스템 설계문서 및 구현과 매핑되어 추적할 수 있는가?

[컴퓨터 네트워크] - TCP/IP 개론 (Introduction of TCP/IP)

shineast_ — Wed, 9 Apr 2025 00:36:57 +0900

프로토콜 (Protocol)

프로토콜이란 서로 다른 시스템에 있는 개체 간 성공적으로 데이터를 전송하는 통신 규약을 의미한다. 이때, 시스템은 하나 이상의 개체를 보유한 컴퓨터를 의미한다. 프로토콜은 계층적 구조로 정의되고 각 계층의 역할을 구분한다.

프로토콜은 네트워크 기능을 단계별로 세분하고 모듈화하여 사용자에게 제공하기에 이해하기 쉬우며, 각 계층 간 표준 인터페이스가 정의되어 다른 업체의 시스템과도 호환이 쉽다.

TCP/IP 개론 (Introduction of TCP/IP)

인터넷에 연결된 네트워크의 종류와 사용하는 프로토콜 또한 매우 다양하다. 인터넷에서 컴퓨터 간의 통신이 가능하도록 표준화하여 채택한 통신 규약이 TCP/IP이다. TCP/IP는 “전송 제어 프로토콜(Transmission Control Protocol: TCP)”과 “인터넷 프로토콜(Internet Protocol)”을 말하며, 인터넷에서 사용하는 응용 프로그램은 TCP/IP를 통해 데이터를 교환한다. TCP/IP는 TCP와 IP 뿐만 아니라 상위 응용 계층의 프로토콜도 포함하는 개념이다. 즉, TCP/IP는 인터넷에 접속하는 프로토콜 중에서 가장 중요한 기능을 TCP와 IP 또는 여러 프로토콜의 집합을 말한다.

인터넷에서 연결된 컴퓨터인 호스트는 데이터를 패킷 단위로 분할하여 전송하는데, 만약 긴 데이터를 전송하는 경우에는 TCP/IP는 데이터를 여러 개의 패킷으로 분할하고 다양한 정보를 추가하여 전송한다.

IP는 패킷으로 변환된 데이터를 네트워크를 통해 멀리 떨어진 호스트에 보낸다. (전송 기능) TCP는 전송된 패킷에 오류가 발생할 경우 재전송을 요청하고 재전송된 패킷에 오류가 없으면 원래의 데이터로 재결합한다.(검사 기능) 이와 같이 TCP/IP는 인터넷의 두 호스트 간 데이터 흐름의 정확성을 보장한다.

TCP/IP 프로토콜의 구조

OSI 참조 모델의 7계층은 서로 독립적이기에 어느 한 계층이 변경되어도 다른 계층에 영향을 끼치지 않는다. OSI 참조 모델의 7계층을 4계층으로 단순화하면 TCP/IP 프로토콜이 된다.

TCP/IP 프로토콜은 OSI 참조 모델의 물리 계층과 데이터 링크 계층을 합쳐 “네트워크 접속 계층”으로, 세션 계층과 표현 계층과 응용 계층을 합쳐 “응용 계층”이 된다. 그리고 네트워크 계층과 전송 계층은 각각 그대로 이어진다.

네트워크 접속 계층 (Network Access Layer)

하드웨어적인 요소와 관련된 모든 것을 지원하는 계층으로, 데이터 링크 계층의 역할을 하는 TCP/IP 프로토콜에는 "이더넷", "802.11x", "MAC/LLC", "SLIP", "SLIP", "PPP" 등이 있다.

네트워크 접속 계층의 송신 측 컴퓨터에서는 상위 계층으로부터 전달받은 패킷에 "물리 주소"인 MAC 주소 정보가 있는 헤더를 추가하고 프레임을 만들어 하위 계층인 물리 계층에 전달한다. 수신 측 컴퓨터에서는 데이터 링크 계층에서 추가한 헤더를 제거하고 상위 계층인 네트워크 계층에 전달한다.

네트워크 계층 (Internet Layer)

네트워크 계층은 TCP/IP 프로토콜에서는 주로 인터넷 계층이라고 불린다.(OSI 모델에서는 네트워크 계층이라고 한다.) 네트워크의 패킷 전송을 제어하는 계층으로, 네트워크 계층 프로토콜은 "IP", "ARP", "ICMP", "IGMP"가 있다. IP(Internet Protocol)은 네트워크의 주소 체계를 관리하고 데이터그램을 정의하고 전송에 필요한 경로를 결정한다.

네트워크 계층의 송신 측 컴퓨터에서는 상위 계층으로부터 전달받은 패킷에 "논리 주소"인 IP 주소를 포함한 헤더를 추가하여 하위 계층인 네트워크 접속 계층에 전달한다. 수신 측 컴퓨터에서는 하위 계층으로부터 전달받은 프레임의 헤더 정보를 확인하고 송신 측 컴퓨터의 네트워크 계층에서 추가한 헤더를 제거하고 상위 계층인 전송 계층에 전달한다.

전송 계층 (Transport Layer)

호스트 간의 데이터 전송을 담당하는 계층으로, 전송 계층 프로토콜은 "TCP", "UDP"가 있다. 전송 계층은 네트워크 양단의 송수신 호스트 간 신뢰성 있는 전송 기능을 제공한다. TCP(Transmission Control Protocol)는 전송되는 패킷에 오류와 중복이 없도록 하며, 보낸 순서대로 상대편이 받도록 신뢰성 있는 데이터 전송을 보장한다.

전송 계층의 송신 측 컴퓨터에서는 상위 계층을부터 받은 데이터를 효율적으로 전송하기 위해 패킷 단위로 분할한다. 이때 패킷을 생성할 때, TCP를 이용하면 해당 패킷에 TCP 헤더 정보가, UDP를 이용하면 해당 패킷에 UDP 헤더 정보가 포함된다. 수신 측 컴퓨터에서는 전송 받은 패킷의 해더 정보를 통해 패킷이 TCP로 만들어졌는지, UDP로 만들어졌는지 알아내고 그에 맞는 프로토콜을 사용하여 재결합한다.

TCP는 정확한 패킷 전송을 보장하기에 패킷 헤더에 추가 정보가 포함되지만, UDP는 정확한 패킷 전송을 보장하지 않아 패킷 헤더 부분에 추가 정보가 없다. TCP는 UDP에 비해 정확한 패킷 전송을 보장하지만, 속도는 UDP보다 느리다.

응용 계층 (Application Layer)

TCP/IP의 프로토콜 범위에는 응용 계층의 프로토콜까지 포함되고, 응용 계층 프로토콜은 "FTP(파일 전송)", "SMTP(이메일)", "SNMP(네트워크 관리)" 등이 있다. 주로 사용하는 메일, 웹 브라우저 등은 응용 계층으로 분류된다.

TCP/IP 프로토콜을 지원하기 위해서는 서버 컴퓨터에 프로토콜을 서버 형태로 제공하는 "데몬(Damon)"이 있어야 한다. 서버 프로그램과 연동하여 작업을 수행하는 원격지의 프로그램을 클라이언트라 하며, 클라이언트의 요청을 처리하는 것이 데몬이다. 이러한 관계를 "클라이언트-서버 시스템"이라고 한다.

TCP/IP 주소 구조 (TCP/IP Address Structure)

TCP/IP에서 사용되는 주소는 "물리 주소", "인터넷 주소", "포트 주소"가 있다.

`물리 주소(Physical Address)`: MAC 주소(Media Access Control Address)로, 링크 주소 또는 통신망에서 정의된 노드의 주소, 이더넷 네트워크, 인터페이스 카드 6바이트 주소를 말한다. MAC 주소는 이더넷에서 각 호스트를 구별하기 위해 모든 이더넷 카드에 개별적으로 부여하는 고유한 식별 번호이다.
`인터넷 주소(Internet Address)`: 인터넷에서는 물리 주소와는 별도로 호스트를 식별할 수 있는 유일한 주소를 지정해야 하는데, 현재 32비트 주소 체계를 인터넷 주소로 사용하며 이는 중복해서 사용될 수 없다.
`포트 주소(Port Address)`: 인터넷 통신의 목적은 한 프로세스가 다른 프로세스가 통신할 수 있도록 하는 것이다. 동시에 발생하는 프로세스를 처리하기 위해서는 각 프로세스를 식별하는 방법이 필요하다. TCP/IP 구조에서는 포트 번호를 사용하여 식별하며, 포트 주소의 길이는 16비트이다. 인터넷에 흩어져 있는 호스트와 통신하기 위해서는 IP 주소와 함께 포트 번호도 알아야 한다.

[컴퓨터 네트워크] - OSI 참조 모델 (OSI 7 Layer Model)

shineast_ — Tue, 8 Apr 2025 17:34:15 +0900

OSI 참조 모델 (OSI Model)

과거 통신 업체에서 사용한 네트워크 구조(ex: SNA, DNA)는 호환성을 고려하지 않고 자신의 시스템에만 적용되는 폐쇄형 네트워크 구조였다. 이로 인해 네트워크 구조와 프로토콜 등에 차이가 있어 문제가 생겼다.

이를 해결하기 위해 국제표준화기구(ISO)에서는 서로 다른 컴퓨터 간 통신 기능을 일곱 계층으로 구분하고, 구분된 계층마다 표준화된 서비스와 프로토콜을 규정한 OSI 참조 모델을 제시했다.

OSI 참조 모델은 기본적으로 하드웨어나 소프트웨어의 논리적 변경 없이 시스템 간 통신을 개방한다. 따라서 유연하고 안전하고 상호 연동이 가능한 네트워크 구조를 설계할 수 있게 되었다.

OSI 7계층 (OSI 7 Layer)

OSI 참조 모델은 각각 특정 기능을 수행하는 7개의 계층으로 이루어져 있다.

물리 계층 (1계층)
데이터 링크 계층 (2계층)
네트워크 계층 (3계층)
전송 계층 (4계층)
세션 계층 (5계층)
표현 계층 (6계층)
응용 계층 (7계층)

각 계층은 헤더와 데이터 단위로 정의된다. 헤더에는 각 계층의 기능과 관련된 정보가 포함된다. 데이터 단위는 헤더를 추가한 데이터를 전송하는 기본 단위이다. 일반적으로 패킷이라고 한다. 이때, 상위 계층이나 하위 계층 사이에서 주고 받는 것을 “서비스 데이터 단위(SDU)”, 동일한 계층 사이에서 주고 받는 것을 “프로토콜 데이터 단위(PDU)”라고 한다.

OSI 참조 모델 데이터 전송

OSI 참조 모델에서는 데이터가 응용 계층에서 하위 계층으로 순차적으로 전송된다. 물리 계층과 응용 계층(최상단과 최하단)을 제외한 나머지 계층에서는 데이터의 시작과 끝부분에 헤더나 트레일러 형태로 정보를 추가한다. 응용 계층에서부터 물리 계층까지의 데이터 전송 과정은 다음과 같다.

응용 계층의 데이터는 하위 계층인 표현 계층으로 전송된다.
표현 계층에서는 표현 계층과 관련된 헤더를 추가하고 세션 계층으로 전송된다.
세션 계층에서는 세션 계층과 관련된 헤더를 추가하여 전송 계층으로 전송된다.
이렇게 물리 계층과 응용 계층을 제외한 나머지 계층에서는 각 계층마다 데이터에 헤더를 추가하여 하위 계층으로 전송한다.
물리 계층에서는 수신 측 시스템에 전송할 수 있는 전자적 신호로 변환하고 전송 매체를 통해 수신 측으로 전송한다.

그리고 수신 측에 데이터가 도착하면 전기적 신호로 변환되었던 데이터는 물리 계층으로 전송되어 디지털 형태로 복원된다. 그 이후 수신된 데이터는 상위 계층에 전송되면서 송신 측 계층에서 추가한 헤더와 트레일러를 제거하고 각 계층에서 해야할 일을 수행하고 최종적으로 응용 계층까지 데이터를 전송한다. 그리고 데이터를 적절한 형태로 변환하여 수신자에게 전송한다.

송신 측 시스템에서 수신 측 시스템으로 데이터를 전송하는 과정에서 많은 노드를 거치게 되는데, 실제 네트워크 프로토콜은 OSI 참조 모델의 7계층 중 물리 계층, 데이터 링크 계층, 네트워크 계층만 사용한다.

[컴퓨터 네트워크] - 네트워크 종류 (Network Type)

shineast_ — Mon, 7 Apr 2025 23:13:09 +0900

근거리 네트워크 (LAN)

근거리 네트워크는 비교적 가까운 지역에 한정된 통신망을 말하며, 컴퓨터 뿐만 아니라 다른 네트워크 장비를 연결/접속하여 통신할 수 있도록 구성한 네트워크 시스템을 말한다. LAN은 다양한 장치와 연결하기 편하고 재배치와 확장이 자유로우며 다양한 종류의 데이터를 처리할 수 있다. LAN의 특징은 다음과 같다.

단일 기관의 소유로 수 km 범위 내의 지역으로 한정된다.
네트워크 기기에 상관없이 서로 통신이 가능하다.
광역 전송 매체를 사용하여 고속 통신이 가능하다.
많은 사용자가 단일 매체로 지연 없이 데이터를 주고 받을 수 있다.
좁은 구간에서 통신하기에 전송 지연 시간이 짧고 확장하기 쉽다.

LAN 전송 방식

LAN에서 케이블을 이용하여 데이터를 전송하는 방식은 “베이스밴드” 방식과 “브로드밴드” 방식으로 분류된다.

베이스밴드 방식 (Baseband)

데이터를 전송할 때 디지털 신호를 변조하지 않고 직접 전송하는 방식으로, 하나의 케이블에 단일 통신 채널을 형성하여 데이터를 전송한다. 채널 하나에 신호 하나만 전송하기에 경제적이다. 채널이 하나이기에 생길 수 있는 충돌을 방지하기 위하여 시간을 분할해서 채널 전송 권한을 부여하는 다중화 방식을 사용한다.

브로드밴드 방식(Broadband)

부호화된 데이터를 아날로그 신호로 변조하고 제한된 주파수만 전송 매체에 전송하는 방식으로, 하나에 케이블에 다수의 통신 채널을 형성하여 데이터를 동시에 전송한다. 아날로그 신호로 변환을 위하여 모뎀이 필요하고 비용이 꽤나 들지만, 전송 거리를 크게 늘릴 수 있다.

전송 매체의 주파수를 여러 대역으로 나눠 각각 다른 데이터를 전송하는 토큰버스 방식을 사용한다.

매체 접근 제어 방식

LAN에서는 하나의 통신 회선을 공유하기에 데이터를 전송할 때 전송 매체의 접속을 제어하지 않으면 데이터 충돌이 발생할 수 있다. 데이터 충돌을 방지하기 위해서 LAN에 연결된 모든 장치는 정의된 규칙에 따라 전송 매체에 접근한다.

이와 같은 매체 접근 제어 방식은 경쟁 방식과 토큰제어 방식으로 구분된다.

`경쟁 방식`: 언제나 매체에 접근 가능한 방식
`토큰 제어방식`: 토큰을 사용하여 정해진 순서나 시간에 따라 매체에 접근 가능한 방식

이더넷 (Ethernet)

LAN을 구축하기 위해 사용되는 많은 네트워크 통신 기술 중, 가장 많이 사용되는 방식은 “이더넷”이다. 이더넷은 각 물리적 링크를 유일한 MAC 주소를 사용하는 포트와 연결하는 버스형 접속 형태의 구조이다. 이더넷은 매체의 종류와 배선 방식, 전송 지원 속도에 따라 이더넷, 고속 이더넷, 기가비트 이더넷, FDDI 등으로 구분된다.

`이더넷`: 초기 버전으로, 10Mbps 속도를 제공한다. 공유기나 스위치 없이 “버스형 구조”로 여러 장비를 공유 케이블로 연결한다. 동축 케이블에 연결된 컴퓨터를 서로 접속시키는 CSMA/CD 방식으로 충돌을 감지하고 대기하며 재전송한다.
`고속 이더넷`: 100Mbps 속도를 제공한다. 물리적 구조는 스타형이며, 대부분 UTP 케이블(Cat5 이상) 을 사용한다.
`기가비트 이더넷`: 1Gbps 이상의 전송 속도를 제공한다. 서버, 고속 백본, 데이터센터 등에서 널리 사용한다.
`FDDI`: 기가비트 이더넷에 밀려 많이 쓰이지 않지만, LAN의 고속 컴퓨터 연결이나 백본 네트워크로 사용된다. 통신망은 링형 접속 형태를 띈다. 이중 링 구조를 사용하여 한쪽 링이 고장나도 다른 링으로 통신이 가능하다.

무선 LAN (Wireless LAN)

이더넷 케이블과 같은 유선으로 연결된 근거리 네트워크가 아닌 Wi-Fi와 같은 무선 기술로 연결된 근거리 네트워크를 무선 LAN이라고 한다. 무선 주파수나 적외선 기술을 사용하여 네트워크 환경을 조성한다.

무선 LAN은 유선 LAN에 비해 데이터 전송 속도는 느리지만 단말기를 자유롭게 옮길 수 있고 복잡한 선이 없어 작업 환경이 쾌적하다.

IEEE에서는 무선 LAN 규격을 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac 등으로 규정했는데, 현재는 802.11n이나 802.11ac를 주로 사용한다.

무선 LAN의 기본 단위는 BSS이다. 즉, BSS(Basic Service Set)란 무선 LAN에서 통신이 이루어지는 가장 기본적인 단위의 네트워크 집합이다. 무선 LAN은 애드훅 모드와 하부 구조 모드로 분류된다.

`애드훅 모드(Ad-Hoc Mode)`: 단일 BSS만으로 된 네트워크로, 컴퓨터에 무선 LAN 카드를 장착하여 연결하는 방법이며 일대일 통신 방식이다.
`하부 구조 모드(Infrastructure Mode)`: BSS 사이를 연결하기 위해 무선 공유기와 같은 중심 장치인 AP(Access Point)를 사용하는 방식이다.

무선 LAN의 매체 접근 제어 방식은 이더넷에서의 방식과 다른데, 이더넷에서 사용하는 CSMA/CD는 무선 LAN 환경에서 발생하는 문제를 해결할 수 없기에 새로운 액세스 프로토콜인 CSMA/CA가 만들어졌다.

광역 네트워크 (WAN)

광역 네트워크는 2개 이상의 LAN이 넓은 지역에 걸쳐 연결되어있는 것을 말한다. WAN을 통해 국가와 국가를 연결할 수 있고, 수천 km 이상의 거리도 통신이 가능하다. WAN은 당연히 LAN에 비해 더 먼 거리를 연결할 수 있지만 네트워크 구축 비용이 많이 들고 LAN보다 연결 속도가 느리다.

통신망 노드의 전송 기능을 이용하여 데이터를 수신 측으로 전송하는 통신망을 “교환 통신망”이라고 한다. 교환 통신망은 상호 연결된 노드의 모임으로, 노드들을 경유하여 목적지까지 데이터가 전송된다. 교환 통신망은 데이터를 송신 측에서 수신 측으로 전송할 때, 한 링크에서 다른 링크로 데이터를 교환하는 방법에 따라 “회선 교환”, “메시지 교환”, “패킷 교환” 등으로 분류된다.

회선 교환 (Circuit Switching)

회선 교환은 두 스테이션 사이에 전용 통신 경로가 있다는 것이다. 데이터를 전송하기 전, 하나의 물리적 경로를 설정하고 통신을 종료할 때까지 해당 경로를 독점한다. 회선 교환 방식은 다음의 과정을 거쳐서 이루어진다.

노드 간 통신 시작 전, 신호 방식을 이용하여 회선을 설정한다.
노드는 비어있는 회선을 고정적으로 할당한다.
설정된 회선은 데이터를 전송한다. 이때, 회선은 사용 여부에 관계없이 점유되었기에 다른 데이터를 전송하는데 사용될 수 없다.
데이터 전송이 종료되면 할당 받은 회선의 연결을 해제한다.

회선 교환 방식의 장단점은 다음과 같다.

(장점) 회선을 전용선처럼 사용해서 많은 데이터를 전송할 수 있다.
(장점) 경로 설정 시, 사용자에게 고정적인 전송률로 정보를 전송할 수 있다.
(장점) 경로 설정 시, 교환 노드에서 처리 지연이 거의 없다.
(장점) 실시간 미디어 전송에 적합하다.
(단점) 오류 없이 데이터를 전송해야 하는데 서비스에는 부적합하다.
(단점) 설정된 데이터를 그대로 투과시키기에 오류 제어 기능이 없다.
(단점) 데이터를 전송하지 않아도 회선을 독점하기에 비효율적이다.

메시지 교환 (Message Switching)

메시지 교환은 가변 길이의 메시지 단위로 저장/전송 방식에 따라 데이터를 교환하는 방식이다. 저장/전송 방식은 도착한 메세지를 먼저 저장하고 다음 노드로 가는 링크가 비면 전송하는 “축적 전송” 방식이다.

메시지 교환 방식은 송수신측 간에 데이터를 전송하는 전용 통신로가 필요 없고, 저장/전송 방식을 통해 링크를 동적으로 공유하여 메시지를 전송한다. 메시지 교환 방식은 다음의 과정을 거쳐 이루어진다.

메시지 교환기는 하드디스크가 있는 컴퓨터로 구현된다.
수신되는 메시지는 교환기의 하드디스크에 저장된다.
교환기는 메시지를 완전히 수신하면 오류를 검사한다.
오류가 없으면 경로를 결정하여 다음 교환기로 메시지를 전송한다.
먼저 도착해서 전송을 기다리는 메시지가 있으면 메시지가 모두 전송될 때까지 지연시키고 그 후 전송한다.

메시지 교환 방식의 장단점은 다음과 같다.

(장점) 회선을 독점하여 비효율적인 회선 교환 방식을 개선했다.
(장점) 전송 지연이 문제되지 않는 이메일이나 파일 전송에 적합하다.
(단점) 메시지의 지연이 길고 가변적이다.

패킷 교환 (Packet Switching)

패킷 교환은 네트워크를 통해 데이터가 전송되기 전, 데이터는 각 고유 번호를 가진 작은 조각인 패킷으로 나누어지고 수신지에 전송되면 다시 원래 데이터로 재결합된다.

패킷 교환 방식은 네트워크로 전송되는 모든 데이터는 패킷으로 구성되는 방식이다. 패킷은 송수신지 정보를 포함하고, 표준과 프로토콜을 사용하여 생성된다. 이때, 패킷의 크기는 “옥탯(1바이트)”으로 나타내고, 주로 128 옥탯의 패킷을 사용한다. 패킷은 기본적으로 “헤더”, “데이터”, “순환 중복 검사”로 구성된다.

`헤더`: 패킷의 정보(송수신지, 패킷 번호, 플래그 정보, 패킷 길이)가 들어 있다.
`데이터`: 각 시스템에서 패킷의 최대 길이는 정해지는데, 데이터의 크기가 패킷의 최대 길이보다 크면 작은 조각으로 쪼개져 여러 패킷으로 나뉘어 전송된다.
`순환 중복 검사`: 수신된 정보에 오류가 있는지 검사할 수 있도록 송신 측에서 원래 데이터에 추가 데이터를 보낸다. 이를 순환 중복 검사라 하며, 강력한 오류 검출이 가능하게 한다.

패킷 교환 방식은 회선 교환과 메시지 교환의 장점을 받아들이고 단점을 최소화한 방식으로, 저장/전송 방식을 사용하지만, 적당한 크기로 메시지를 분할해서 전송한다. 패킷 교환 방식은 다음의 과정을 통해 이루어진다.

전송 경로를 따라 패킷이 수신되면 버퍼에 저장한다.
먼저 도착한 패킷의 전송이 완료되면 다음 노드로 전송된다.
패킷이 수신지에 도착할 때까지 저장 및 전송 과정을 반복한다. (이때, 물리적 회선 연결 없이, 회선의 상황에 따라 패킷 내 주소를 이용하여 경로를 라우팅한다.)
수신지에 전송된 패킷은 원래 패킷의 순서대로 재결합되어 최종 스테이션으로 전송된다.

패킷 교환 방식의 특징은 다음과 같다.

(장점) 네트워크가 버퍼 기능을 수행하기에 처리 속도가 달라도 데이터를 전송할 수 있다.
(장점) 노드 간의 회선을 다수의 패킷이 공유하기에 효율이 높다.
(장점) 패킷 별로 우선순위 설정이 가능하여 패킷 전송 순서를 결정할 수 있다.
(장점) 데이터 전송 시, 과부하가 발생하면 전송 지연은 발생해도 패킷 송신은 가능하다.

패킷 교환은 접속 방식에 따라 데이터그램 패킷 교환과 가상 회선 패킷 교환으로 구분된다.

`데이터그램 패킷 교환`: 데이터를 전송하기 전 논리적 연결을 설정하지 않고 패킷마다 송신 측과 수신 측의 주소를 추가하여 독립적으로 전송하는 방식
`가상 회선 패킷 교환`: 데이터를 전송하기 전 논리적 연결을 설정하여 모든 패킷을 전송하는 방식

데이터그램 패킷 교환 방식은 순서가 보장이 되지 않고 경로가 매 패킷마다 다르지만, 가상 회선 패킷 교환 방식은 순서가 보장되고 경로가 미리 설정된다. 따라서 데이터그램 방식이 더 유연하고 탄력적이지만, 가상 회선 방식이 더 안정적이고 예측 가능성이 높다

[컴퓨터 네트워크] - 네트워크 통신 (Network Communication)

shineast_ — Fri, 4 Apr 2025 14:43:08 +0900

통신 방식 (Communication Method)

LAN에서 통신하는 방식

LAN에서 통신하는 방식으로는 유니캐스트, 브로드캐스트, 멀티캐스트가 있다.

유니캐스트(Unicast)

유니캐스트 방식은 서버와 클라이언트의 일대일 통신 기법으로, 통신할 때 송신지와 수신지의 주소(MAC 주소)를 사용한다. 통신 시 프레임을 전송하면 네트워크의 모든 컴퓨터는 프레임을 전송받아 LAN 카드에서 자신의 MAC 주소와 비교한다. 이때, 자신의 MAC 주소와 수신지의 MAC 주소가 동일하면 전송된 데이터를 수신하고 그렇지 않으면 해당 프레임을 버린다. 유니캐스트 방식은 컴퓨터의 CPU에 영향을 주지 않으며 따라서 컴퓨터의 성능을 저하시키지 않는다.

브로드캐스트(Broadcast)

브로드캐스트 방식은 로컬 LAN에 있는 모든 네트워크 단말기에 데이터를 보내는 방식으로, 서버와 클라이언트가 “일 대 다(1:N)”로 통신하는 기법이다. 브로드캐스트 주소가 오게 되면 LAN 카드는 자신의 MAC 주소와 같든 다르든 패킷을 CPU에 보낸다. 네트워크의 모든 장치는 패킷을 수신하게 되고 필요한 장치만 데이터를 처리하고 나머지는 무시한다.

처음 컴퓨터 사용 시, 상대방의 컴퓨터의 MAC 주소를 알 수 없기에 상대방 컴퓨터의 MAC 주소를 알아내기 위해 ARP로 동작한다. ARP는 Address Resolution Protocol 의 약어로 IP 주소를 MAC 주소로 변환하기 위한 요청 메세지다. ARP 요청을 통해서 MAC 주소를 알아낼 수 있는데, 브로드캐스트 방식은 ARP 요청을 모든 네트워크의 장치에 보낸다는 것이다. 결국, 이로 인해서 불필요한 트래픽이 증가하고 네트워크 성능 저하가 발생할 수 있으며 보안 측면에서의 위험이 증가한다.

멀티캐스트(Multicast)

멀티캐스트 방식은 특정 그룹의 여러 장치에 한 번에 데이터를 전송하는 통신 방식으로, 필요한 장치들에만 데이터를 전송할 수 있다. 일 대 다 방식이지만 특정 그룹에만 전송하기에 네트워크 트래픽이 줄어든다. 다만 멀티캐스트 방식은 스위치나 라우터가 지원될 때만 사용할 수 있기에 제한적이다.

전송 방향에 따른 통신 방식

두 장치 간 데이터를 전송할 때, 데이터 전송 방향에 따라 단방향 통신과 양방향 통신으로 분류된다.

`단방향 통신(Simplex)`: 송신 측과 수신 측이 고정되고, 통신 채널을 통해 접속된 두 단말기 사이에서 데이터가 한 방향으로만 전송되는 통신 방식
`양방향 통신(Duplex)`: 통신 채널을 통해 접속된 두 단말기 사이에서 데이터의 송수신이 모두 가능한 통신 방식

또 양방향 통신은 반이중 통신과 전이중 통신 방식으로 분류된다.

`반이중 통신`: 통신 채널에 접속된 단말기 두 대 중 어느 한 쪽이 데이터를 송신하면 상대방은 수신만 할 수 있는 방식, 대표적인 예시로 무전기가 있다.
`전이중 통신`: 통신 채널에 접속된 단말기 두 대가 동신에 데이터를 송수신할 수 있는 방식

직렬 전송과 병렬 전송

데이터 전송은 이진 데이터를 전압이나 전류의 변화로 표현한 신호에 실어 보내는 것을 만한다. 데이터 비트를 전송하는 방법에 따라 직렬 전송과 병렬 전송으로 나뉜다.

직렬 전송 (Serial Transmission)

하나의 정보를 나타내는 각 데이터 비트를 직렬로 나열한 후, 하나의 통신 회선을 사용하여 순차적으로 1비트씩 송신하는 방식이다. 하나의 통신 회선을 사용하기에 송신 측에서는 데이터를 1비트씩 송신하고 수신 측에서는 수신되는 비트를 일정 단위로 모아 수신한다.

동기화 (Synchronization)

컴퓨터 등 장치 내부에서는 병렬 입출력을 사용하기에 송신 측에서 외부로 데이터를 보내려면 병렬 데이터를 직렬 데이터로 변환해야 하고 수신 측에서는 변환될 직렬 데이터를 다시 병렬 데이터로 변환한다.

직렬 전송 방식에서는 신호를 연속으로 전송하기에 정확히 송수신하려면 데이터의 시작과 끝을 수신 측이 알아야 한다. 두 시스템 간 컴퓨터의 속도 차이(클록 오차)로 인해서 송신 비트 시간 간격(TS)와 수신 비트 시간 간격(TR)은 일치하지 않는데 송식 측이 전송한 데이터의 각 비트를 수신 측이 정확히 수신할 수 있도록 “동기화”시켜야 한다.

따라서 송수신 측이 약속한 패턴을 이용하여 데이터의 송수신 타이밍을 일치시키는 것을 “동기식 전송”이라고 한다. 반면 송수신 간 동기를 맞추지 않고 문자 단위로 구분하여 전송하는 방식을 “비동기식 전송”이라고 한다.

`동기식 전송`: 송신기와 수신기가 동일한 클록을 사용하여 데이터를 송수신하는 방식이다. 동기식 전송의 대표적인 예로 “파일 업로드”와 “다운로드”가 있다.
`비동기식 전송`: 긴 데이터 비트열을 연속으로 전송하지 않고 한 번에 한 문자씩 전송하여 수신기가 새로운 문자의 시작점에서 재동기하도록 하는 방식이다. 대표적인 예시로는 “메세지 전송”이 있다.

병렬 전송 (Parallel Transmission)

부호를 구성하는 비트 수와 같은 양의 통신 회선을 사용하여 여러 데이터 비트를 동시에 전송하는 방식이다. 비트 $n$개를 전송하기 위해 회선 $n$개를 사용한다. 일반적인 컴퓨터와 같은 단말기가 사용하는 병렬 데이터를 그대로 송수신하기에 직렬 전송보다 입출력 구조가 단순하고 동일 조건의 직렬 전송에 비해 $n$배 빠르다.

다만, 병렬 전송은 거리에 비례해서 선로 비용이 많이 들게 된다. 따라서 전송 속도가 빨라야 하는 짧은 거리의 데이터 전송에 주로 이용된다.

통신 오류 검출 (Error Detection in Communication)

통신 오류 (Communication Error)

수신 측으로 전송한 데이터는 송신 측의 데이터와 동일해야 한다. 그러나 다양한 원인들로 인해 데이터 오류가 발생할 수 있다. 오류의 종류로는 다음이 있다.

`단일 비트 오류(Single-Bit Error)`: 데이터 단위 중 하나의 비트만 변경하는 오류
`다중 비트 오류(Multiple-Bit Error)`: 데이터 단위 중 2개 이상의 비연속적인 비트를 변경하는 오류
`집단 오류(Burst Error)`: 데이터 단위 중 2개 이상의 연속적인 비트를 변경하는 변경하는 오류

송신 측이 보내는 데이터 외에 잉여 데이터를 추가하면 수신 측에서 잉여 데이터를 검사하여 오류를 검출할 수 있다.

패리티 비트 검사

패리티 비트 검사 방식은 전송하는 데이터마다 패리티 비트를 하나씩 추가하여 홀수 또는 짝수 검사 방법으로 오류를 검사한다. 이때 추가로 전송되는 1비트를 패리티 비트라고 한다.

홀수 패리티 방식

전체 비트에서 1의 개수가 홀수가 되도록 패리티 비트를 정하는 방식이다. 데이터 비트에서 1의 개수가 짝수이면 패리티 비트를 1로 정하여 전체 데이터에 있는 1의 개수를 홀수로 만들고, 데이터 비트에서의 1의 개수가 홀수이면 패리티 비트를 0으로 정하여 전체 데이터에 있는 1의 개수를 홀수로 유지한다.

짝수 패리티 방식

전체 비트에서 1의 개수가 짝수가 되도록 패리티 비트를 정하는 방식이다. 데이터 비트에서 1의 개수가 홀수이면 패리티 비트를 1로 정하여 전체 데이터에 있는 1의 개수를 짝수로 만들고, 데이터 비트에서의 1의 개수가 짝수이면 패리티 비트를 0으로 정하여 전체 데이터에 있는 1의 개수를 짝수로 유지한다.

패리티 방식의 오류 검출 과정

송신 측에서 데이터에 패리티 비트를 추가하여 전송한다.
수신 측에서 받은 데이터의 1의 개수를 확인한다.
전송 중 데이터 비트의 수가 변한 경우, 오류를 검출한다.

패리티 방식은 간단한 오류를 검출하기 쉽지만, 한 개의 비트 오류만 검출 가능하고 수정은 불가능하다. 그리고 두 개 이상 비트의 오류가 발생 시 검출이 불가능하다.

블록 합 검사

블록 합 검사는 오류 검출 능력을 향상시키기 위해 수평 패리티와 수직 패리티를 적용하여 문자 블록을 이차원적으로 검사하는 방식이다. 즉, 여러 개의 데이터 블록을 행렬 형태로 배열한 후, 행과 열의 합을 구해 오류를 감지한다.

블록 합 검사 방식의 오류 검출 과정

데이터를 일정 크기의 블록으로 나눈다.
각 행의 합과 각 열의 합을 계산하여 검사합(checksum) 블록을 추가한다.
데이터 전송 후, 수신 측에서 동일한 방식으로 합을 계산하여 비교한다. (계산된 합과 전송된 검사합이 다르면 오류 발생을 감지할 수 있음.)

블록 합 검사 방식은 데이터에 짝수 개의 오류가 발생해도 오류를 검출할 수 있다. 그러나, 사용자 데이터를 전송한 후 검사 데이터를 추가로 전송하기에 많은 오버헤드가 발생한다. 그리고 연석된 문자에서 같은 위치의 2비트가 오류일 때는 오류 검출이 불가능하다.

순환 중복 검사 (Cyclic Redundancy Check)

순환 중복 검사는 정확히 오류를 검출하기 위해서 다항식 코드를 사용하는 방식이다.

순환 중복 검사의 오류 검출 과정

송신 측이 데이터를 전송하기 전, 송수신 측은 동일한 생성 다항식을 결정한다.
송신 측은 $K$ 비트의 전송 데이터를 생성 다항식으로 나눈 $n$ 비트의 나머지 값을 구한다.
$K$ 비트의 전송 데이터에 $n$ 비트의 나머지 값을 추가하여 $K+n$ 비트의 데이터를 수신 측에 전송한다.
수신 측은 수신된 $K+n$ 비트의 데이터를 생성 다항식으로 나눈다. 나머지가 0이면 오류가 없고, 0이 아니면 오류가 발생한다.

[소프트웨어 공학] - 프로젝트 관리 (Project Management)

shineast_ — Thu, 3 Apr 2025 17:35:50 +0900

프로젝트 팀 조직

소프트웨어는 프로젝트 팀 구성이 프로젝트 운영과 소프트웨어 결과물에 중요한 영향을 미친다. 개발 팀을 직능별로 나누어 부서를 나누거나 또는 다른 방식으로 부서를 형성할 수 있다. 프로젝트 팀 조직은 다음 세 가지를 정하는 것이다.

역할과 책임이 어디 있는가?
어떤 통로로 정보가 전달되고 결정되는가?
어떻게 갈등을 해소할 것인가?

소프트웨어 개발을 위한 인력 자원과 작업 목표가 주어졌을 때 각자의 임무와 역할이 무엇인지 결정해야 한다.

직능별 조직 구성

개발자들의 역할에 따라 같은 부서에 속하게 하는 것이 직능별 팀 조직이다. 직능별 팀 조직은 서로 다른 부서가 한 프로젝트의 다른 단계에 들어와 작업을 수행하고 나가는 것이다. 부분적으로 완성된 결과물이 한 부서에서 다른 부서로 전달되면서 소프트웨어가 진화해간다.

소프트웨어 개발 조직에서 일반적으로 분류하는 직능은 다음과 같다.

프로젝트 관리자 (Project Manager)
시스템 운영자 (System Administrator)
시스템 분석가 (Ststem Analyst)
시스템 개발자 (Software Engineer)
데이터베이스 엔지니어 (Database Engineer)
QA 관리자 (QA Manager)
기술 지원 (Technical Support)
하드웨어 엔지니어 (Hardware Engineer)
웹 개발자 및 디자이너

프로젝트별 조직 구성

서로 다른 역할을 담당하는 직능별 개발자들이 프로젝트에 배정되어 프로젝트 별로 부서를 조직하는 방법이 프로젝트별 조직이다. 프로젝트별 조직은 다양한 인력 자원이 프로젝트 안에 배치되어 프로젝트 관리자가 독립성을 가지고 관리하며 조정할 수 있다.

매트릭스 조직

매트릭스 조직은 프로젝트별 조직과 직능별 조직을 혼합한 것으로, 관리자와 개발자는 직능별 조직에 속하지만 전문지식이 필요한 지정된 프로젝트를 위해 간헐적으로 일하는 것이다. 직능별 조직의 관리자가 프로젝트 책임을 가지고, 직능별 조직 부서에 소속된 개발자가 프로젝트에 참여한다.

매트릭스 조직에서는 모든 팀원이 보고하는 두 명 이상의 관리자가 존재한다. 따라서 커뮤니케이션 스킬이 더 많이 요구된다.

애자일 조직

애자일을 따르는 개발은 5~9명의 적은 인원의 팀을 구성하여 서로 밀접하게 협력한다. 개인보다는 팀이 중요시 되기에 책임과 역할이 교환될 수 있다.

애자일 조직에서는 “결과와 이슈에 대한 오너쉽을 공유한다”는 것이 중요하다. 팀원이 여러 직능을 담당하거나 팀을 재구성하는 것도 가능하다. 결국 고객의 요구와 가치를 만족시키기 위하여 역동적이며 융통성 있고 최적화된 조직을 구성한다.

애자일 팀의 단점은 적은 인원으로 구성되어 규모가 큰 프로젝트에 맞지 않는다는 것이다.

실행과 모니터링

계획을 짠 이후, 계획이 실행되지 않거나 실행에 도움이 되지 않으면 의미가 없기에 프로젝트를 실행하는 동안 모니터링하고 현재 상황을 반영하여 계획과 비교하고 수정해야 한다.

프로젝트 실행

프로젝트를 실행하면 두 가지의 관리 작업이 시작된다.

`작업 시작 미팅`: 팀원들에게 작업이 시작됨을 알리고 회의를 열어 팀이 작업의 목표와 형식에 맞춰졌는지를 확인한다.
`작업 결과 수집`: 프로젝트의 결과물을 체계적으로 수집하는 과정으로, 여러 가지 요소를 평가하기 위한 기회이다.

프로젝트 모니터링

모니터링은 프로젝트의 현황을 파악하고 차이를 분석하여 조치를 취하기 위하여 진행하는 과정이다. 모니터링을 중점적으로 해야 할 부분은 “일정”, “비용”, “진척도”로 각각을 모니터링하는 방법은 다음과 같다.

`일정 모니터링`: 주어진 시간 계획의 스냅샷을 기초로 실행 값을 비교한다. 실제로 들어간 노력과 진행 상황을 비교한다.
`어닝 밸류 분석(Earning Value Analysis)`: 비용과 일정을 통합하여 모니터링하는 방식으로, 계획된 노력(비용), 실제 진적도(어닝 밸류), 노력(실제 비용)을 금전적 가치로 측정하여 통합된 모니터링을 제공한다. 이때 맨파워(Manpower)를 비용으로 간주하여 미래의 비용과 일정을 예측한다.

번다운 차트 (Burndown Chart)

번다운 차트에서는 구현될 각 기능에 이상적인 투입 시간을 할당하고 각 기능은 스프린트에 배정되어 기능이 완성되며 소멸되는 스프린트 점수로 기록한다.

결국, 번다운 차트는 기능이 출시되는 속도를 측정하고 잔여 작업량과 잔여 시간을 계산하고 시각화하기 위해 사용된다.

리스크 관리

리스크 관리란 위험 요인을 파악하고 평가 관리하는 기술과 프로세스를 의미한다.

리스크 파악

리스크를 관리하기 위해서는 우선 프로젝트에 영향을 줄 수 있는 리스크가 무엇인지 이해하고 특징을 파악해야 한다. 리스크를 찾는 방법은 다음과 같다.

`회의`: 리스크 파악을 위한 회의를 통해 아이디어를 도출한다.
`문서 분석`: 프로젝트와 관련된 문서를 읽고 리스크를 찾는다.
`리스크 분할 구조`: 리스크 아이템을 분할하여 계층 구조로 그리거나 체크리스트를 만들어 파악한다.
`유추`: 비슷한 프로젝트 유형과 비교하여 유추한다.

리스크 평가

리스크를 프로젝트에 대한 영향도에 따라 평가하고 우선순위를 매긴다. 평가하는 방법은 정성적인 방법과 정량적인 방법으로 분류된다.

`정성적인 방법`: 리스크 발생 확률에 대한 정확한 정보가 없을 경우 사용하는 방법으로, 주관적인 판단으로 평가하는 방법이다.
`정량적인 방법`: 리스크 확률을 고려한 영향을 돈으로 환산하는 방법으로, 확률과 영향도에 대하여 채택된 스케일로부터 출발하여 리스크 메트릭스에 리스크 요소를 표시한다.

리스크 관리

결국 리스크 관리의 목표는 프로젝트에 대한 부정적 사건이 발생할 가능성을 줄이고 긍정적인 사건이 일어날 가능성을 높이는 것이다. 리스크 요소는 계속 관찰하여 계획과 차이가 나면 원인을 찾아내어 해결 방안을 제시하거나 계획을 수정한다. 미리 인지된 리스크는 대처하기가 쉽지만 예상치 못한 리스크는 인식하고 분석하는 모든 과정의 작업이 필요하다.

리스크 관리 시 완전히 큰 위험 요소의 경우는 애초에 프로젝트 시작을 포기하면 된다. 그리고 프로젝트가 지연된다거나 지체보상금이 부과되는 것과 같은 “영향”을 원인과 혼돈하지 말아야 한다.

[소프트웨어 공학] - 비용 예측 기법 (Cost Estimation Techniques)

shineast_ — Wed, 2 Apr 2025 12:23:01 +0900

비용 예측 기법 (Cost Estimation Techniques)

프로젝트 계획 작업에는 소프트웨어 개발을 위한 비용이 얼마인지 예측할 필요가 있다. 비용을 계산하기 위해 “노력(Effort)”, “자원(Source)”, “기간(Duration)”의 관계를 이해해야 한다.

노력(Effort): 프로젝트를 완성시키기 위해 필요한 작업의 양, 단위는 일(Work-Day), 주(Work-Week), 달(Work-Month)로 표현한다.
자원(Resource): 작업에 동원될 수 있는 인력의 양
기간(Duration): 작업이 수행될 기간

노력과 자원, 기간의 관계는 다음의 식으로 나타낼 수 있다. 이때, M(Manpower)은 투입되는 인력의 투입 비율의 총합이다.

$$ D = E/M $$

비용 예측 기법에는 크게 세 가지가 있다.

`전문가 판단`: WBS를 기초로 경험 많은 전문가가 각 작업에 소요되는 비용을 추정한다.
`PERT`: Program Evaluation and Review Technique의 이니셜을 딴 글자로, 기간을 결정하기 위해 기대치(가중 평균)를 계산하는 방법이다.
`알고리즘식 방법`: 프로젝트에 소요되는 노력을 체계적으로 결정하는 방법으로, 프로젝트의 측정 가능한 특징을 찾아 함수를 정의한다. 대표적인 알고리즘식 방법으로는 COCOMO, 기능 점수가 있다.

COCOMO-81

COCOMO 초기 모델은 B.Boehm 원시 프로그램의 규모에 의한 방법으로, 완성될 시스템의 규모를 추정하고 준비된 식에 대입하여 소요 MM(Man-Month)를 파악한다. 규모 기반 모델은 규모를 기반으로 하는 다음과 같은 기본 수학적 공식 형식을 따른다.

$$노력 = A \times (Size)^B \times M$$

A는 개발 기관의 특징이나 개발 소프트웨어의 유형에 따라 좌우되는 상수, Size는 개발될 소프트웨어의 원시코드 라인 수나 기능 점수, B는 1에서 1.5 사이의 가변적인 값이다. M은 프로젝트에 영향을 주는 여러 가지 다른 요소들로 인해 달라지는 계수들로, 기본적으로 예측한 노력을 보정하는 값이다.

COCOMO-81 모델에서는 규모를 KDSI(Kilo Delivery Source Instruction)로 정하고 세 가지 프로젝트 유형에 따른 산출 공식을 다음과 같이 명시한다.

`유기형(Organic)`: $PM = 2.4 \times (KDSI)^{1.05}$ 공식을 따르며, 소규모 팀이 개발하는 잘 알려진 응용 시스템에 해당한다.
`반결합형(Semi-Detached)`: $PM = 3.0 \times (KDSI)^{1.12}$ 공식을 따르며, 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템에 해당한다.
`내장형(Embeded)`: $PM = 3.6 \times (KDSI)^{1.20}$ 공식을 따르며, 하드웨어가 포함된 실시간 시스템, 신호기 제어 시스템에 해당한다.

COCOMO-81의 문제점은 다음과 같다.

프로젝트 초기 단계에서 Size 값 예측의 어려움
기본 예측 모델에서 B와 M의 값에 영향을 주는 요소들의 주관성
모델과 속성값 보정의 어려움

COCOMO II

COCOMO II는 소프트웨어 개발 프로젝트의 진척도에 따라 세 가지 다른 모델로 분류한 것으로 COCOMO 초기 모델을 개선한 것이다. 단계 별 모델은 다음과 같다.

1단계: 응용 합성 단계로, 프로토타이핑을 진행한다. GUI, 3세대 언어 컴포넌트 개수를 세어 응용 점수를 계산하고 이를 바탕으로 노력을 추정한다.
2단계: 초기 설계 단계로, 기능 점수 방법을 채택하여 자세한 구조와 기능을 탐구하며 정확한 예측을 노린다.
3단계: 구조 설계 이후의 단계로, 시스템에 대한 자세한 이해를 바탕으로 COCOMO-81에서 제시된 LOC(Lines Of Code)에 의하여 소요되는 노력을 추정한다.

COCOMO II에 적용되는 기본 모델은 다음과 같다.

$$E = b\ S^c \ m(X)$$

이때 $b \ S^C$는 기초 소요 노력 예측값이고, $m(X)$는 비용승수의 벡터이다.

기능 점수(Function Points)

기능 점수는 소프트웨어 시스템이 가지는 기능을 정량화한 것으로, 일반적인 소프트웨어가 가지는 기능의 개수로 소프트웨어의 규모와 복잡도를 나타내고 소요 인력과 개발 기간을 계산하는 방법이다.

기능 점수는 총 기능 점수(GFP)와 처리 복잡도 보정계수(PCA)를 곱한 것으로, 기능 점수를 구하는 방법은 다음으로 구성된다.

다섯 가지 기능 분야(입력, 출력, 질의, 파일, 인터페이스)에 해당하는 개수를 파악하여 작업표에 채운다
각 다섯 기능에 대한 복잡도(단순, 중간, 복잡)를 결정하여 표시한다.
총 기능 점수(GFP)를 구한다. 구하는 식은 다음과 같다.
$$ GFP = \sum\limits_{i = 1}\limits^{5}{Count_i \times Complexity_i} $$
처리 복잡도 계산표의 14개의 질문을 활용하여 각 처리 복잡도의 정도에 따라 0~5의 점수를 할당한다.
처리 복잡도 보정계수(PCA)를 다음 식을 이용하여 구한다.
$$ PCA = 0.65 + 0.01 \sum\limits_{i = 1}\limits^{14}{PC_i} $$
최종 식에 넣어 기능 점수를 구한다.

$$ FP = GFP \times PCA $$

기능 점수는 구현되는 언어와 관련이 없다. 그러나 기능 점수 방법은 모든 항목에 일률적인 가중치가 적용되기에 문제가 있을 수 있다. 이러한 문제점은 각 항목의 가중치를 하나의 값이 아닌 범위를 정하여 가변적으로 만들어 적용하여 해결 가능하다.

[소프트웨어 공학] - 프로젝트 계획 (Project Planning)

shineast_ — Tue, 1 Apr 2025 12:34:19 +0900

프로젝트를 관리하는 목적은 작업 수행에 필요한 여러 가지 자원, 인력, 비용, 기술 등을 효과적으로 사용하여 프로젝트의 목표를 달성하기 위함이다. 프로젝트 관리는 “계획”, “조직”, “모니터링”, “조정”의 네 가지 활동으로 이루어진다. 각 활동은 프로젝트의 진행에 따라 순차적으로 이뤄진다.

프로젝트 시작 (Project Start)

프로젝트의 첫 작업은 목표를 세우고 가치와 치스크를 이해하는 일이다. 프로젝트를 시작할지 말지를 결정하는 요인은 다음과 같다.

`프로젝트가 제공할 가치`: 프로젝트에 의해 창출되는 가치와 프로젝트의 결과물이 얼마나 지속 가능한지를 말한다.
`프로젝트와 연관된 리스크`: 자원의 가용성, 타이밍, 기술적 어려움 등을 말한다.

가치와 리스크는 정확하게 평가하기는 쉽지 않지만 정량적으로 측정할 수 있기에 프로젝트 시작 전 가치 분석과 리스크 파악이 제대로 되어야 한다.

프로젝트 가치

프로젝트에 의하여 창출되는 직접/간접 가치는 프로젝트의 긍정적/부정적 결과를 측정하여 나타낼 수 있다. 그리고 프로젝트가 지속 가능하고 결과물이 오랫동안 사용될 능력을 말하는 “지속 가능성”도 중요한 프로젝트 가치이다.

프로젝트의 가치를 평가하는 방법은 다음과 같다.

`투자 회수 기간`: 투자금과 같은 금액을 벌어들이는데 걸리는 시간
`ROI(Return of Investment)`: 총 비용에 대한 연간 평균 이익률
`순수 현재 가치`: 현재 투자금과 미래 수익금을 현재 가치로 비교하는 방법
`평가표`: 금액적인 요소 이외에 기술, 품질, 시간 여유, 인력 등을 고려하여 점수화하는 방법
`SWOT`: 프로젝트의 강점(Strength), 약점(Week), 기회 요인(Opportunity), 위험(Threat)을 파악하여 타당성을 이해하는 방법

프로젝트 리스크

프로젝트는 일정 기간 동안 인력, 재정, 기술적 자원이 필요한데 이에 따르는 리스크를 대비하기 위해 프로젝트의 자원 요구를 미리 확인해야 한다. 고려해야 할 위험 요인은 다음과 같다.

현재 자원 사용량과 가용성
예상 자원 사용량과 가용성
프로젝트의 우선순위 및 중요도
기술적 어려움 및 불확정성

타당성 분석

타당성 분석은 프로젝트를 공식적으로 인정하고 기관의 목표와 연결시키는 문서로, 프로젝트의 선택에 기초가 되는 문서이다. 타당성 분석에 포함되어야 할 내용은 다음과 같다.

SOW(Statement of Work): 프로젝트가 성취되어야 할 일
비지니스 목표(가치): 프로젝트의 결과물
예산: 비용과 수익의 요약
프로젝트 일정: 대략적인 일정
프로젝트 리스크: 위험 요소
대안: 구축, 구매 등의 방법
평가: 프로젝트 가치에 대한 평가 결과

프로젝트 계획 (Project Planning)

프로젝트 시작되고 가장 먼저 하는 작업은 “프로젝트 계획”이다. 초기 프로젝트 계획 단계에서는 다음의 세 가지 사항에 대하여 계획한다.

`목표 설정`: 프로젝트의 특성은 무엇이며, 누가 자원을 제공하며, 누가 사용할 것인지 정한다.
`일정 정의`: 프로젝트 작업의 진행 스케줄과 할당할 자원을 정한다.
`비용 추정`: 프로젝트를 완성시키기 위해 필요한 비용을 추정한다.

일정을 계획할 때는 다음과 같은 순서를 따른다.

프로젝트의 목표와 요구를 정하고 문제의 범위를 정한다.
문제를 작업 스케줄 관점으로 이해하기 위해 WBS 분석을 진행한다
작업의 의존관계를 파악하고 자원 할당을 고려하여 일정을 정한다.

목표 설정

프로젝트 목표에는 프로젝트에서 다루어야 할 모든 작업이 포함되어야 하고 범위 밖의 작업이 포함되면 안 된다. 프로젝트 범위를 문서로 정리할 때는 다음 세 가지 내용이 포함되어야 한다.

`프로젝트 목표 및 요구`: 프로젝트에서 달성하여야 할 목표, 수행되어야 할 기본 작업(WBS), 산출해야 할 결과물, 승인 조건
`가정과 제약조건`: 프로젝트가 성공하기 위해 만족해야 할 조건
`산출물과 점검 일정`: 프로젝트에서 정해진 일정에 산출해야 할 결과물

프로젝트 범위

소프트웨어 프로젝트 계획은 대상 업무나 문제의 범위(Scope)를 정하는 것으로부터 시작된다. 현재 상황을 잘 파악하고 구현될 시스템의 목표 및 제약 조건 등을 정의해야 한다. 이때, 문제의 범위는 사용자의 입장에서 작성하는 것이 중요하다. 문제의 범위를 정의하기 위해서 문제의 배경과 응용 분야를 잘 이해하는 것이 좋다.

WBS (Work Breakdown Structure)

프로젝트의 목표를 스케줄 관점으로 이해하기 위해서는 WBS 분석이 필요하다. WBS는 개발 팀이 프로젝트 목표를 달성하고 결과물을 산출하기 위해 수행하여야 할 작업을 계층적으로 분할한 것이다.

소작업에 대한 소요 일정이 예측되어야 전체 프로젝트의 일정을 계획할 수 있기에 WBS를 작성한다. WBS 작성을 통해 프로젝트 진행에서 일어나는 모든 작업을 찾아내고 각 작업을 필요에 따라 더 자세한 소작업으로 분류할 수 있다. 이때, 가장 하위의 단위 작업은 프로젝트 단위 조직이 책임져야 할 규모의 목표가 되어야 한다.

WBS는 프로젝트에서 수행할 작업을 정의하는데 효과적이고 모니터링할 때 유용하다. WBS는 프로젝트 스케줄링 작업의 입력이 된다.

스케줄링

스케줄링이란 빠른 기간 내에 프로젝트를 완성할 수 있도록 작업의 순서를 최적화하는 일이다. 프로젝트 목표가 설정되면 WBS를 기초로 하여 일정을 정의하는 것이다. 스케줄링 결과는 간트 차트로 표현되는데, 다음의 작업들이 필요하다.

작업 사이의 의존 관계 파악
CPM 방법을 이용한 여유 시간 계산
소요 자원의 할당

작업 의존 관계

작업을 수행하는 순서는 논리적으로 정해져 있다. 작업 사이의 의존 관계에는 강한 관계와 약한 관계가 있다.

`강한 의존 관계`: 코딩을 다 한 이후에 테스팅할 수 있거나, 계약이 끝나야 코딩을 시작할 수 있는 관계이다. 강한 의존 관계를 제거하려면 재작업 비용이 든다.
`약한 의존 관계`: 순서에 따라 다른 계획이 가능한 관계이다. 사용할 수 있는 자원과 수준에 다라 다른 순서로 진행 가능하다.

CPM 네트워크

CPM(Critical Path Method) 네트워크는 노드와 간선으로 구성된 네트워크로, 노드는 작업, 간선은 작업 사이의 의존 관계를 나타낸다. CPM 네트워크의 박스에는 작업의 시작일과 완성일을 표시한다.

CPM 네트워크는 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용한다. 이를 위해 작업의 선후 관계를 결정해야 한다. CPM 네트워크를 통해 전체 프로젝트의 최소 소요 기간을 구한다.

임계 경로와 여유 시간 계산

임계 경로(Critical Path)란 소요 기간이 가장 긴 경로로, 경로 상에 있는 어떤 작업이라도 늦추어지면 전체 프로젝트가 지연된다는 것을 말한다. CPM 네트워크를 이용하여 각 작업의 여유 기간(Slack Time)을 구할 수 있는데, 다음의 식을 이용하여 구할 수 있다.

$$TS = TL (Latest \ Start \ Time) - TE(Earliest \ Start \ Time)$$

자원 할당과 간트 차트

간트 차트(Gantt Chart)란 각 작업에 대한 여유 시간을 구하고 작업 별로 시작과 종료 기간을 수평 막대로 표현한 것이다.

프로젝트 진행을 위해서 일정 계획에는 필요한 자원을 할당하게 되는데, 소프트웨어 개발 시 필요한 자원은 크게 세 가지로 나누어진다.

`인력`: 주어진 작업을 수행할 인원과 투입률
`장비`: 주어진 작업을 수행할 때 필요한 도구나 하드웨어 및 소프트웨어
`재료`: 주어진 작업을 수행할 때 필요한 소모품이나 자료

[소프트웨어 공학] - 프로세스와 방법론 (Process & Methodology)

shineast_ — Mon, 24 Mar 2025 21:41:31 +0900

소프트웨어 생명주기 (Life Cycle)

소프트웨어는 사람과 같이 생명주기를 가진다. 개발된 소프트웨어는 계속해서 변경되고, 새로운 기능이 추가되어 쓰이며 마침내 소멸에 이른다. 소프트웨어 프로젝트의 생명주기는 “요구분석 → 설계 → 구현 → 테스팅 → 유지보수”의 단계들을 거친다.

TIP!
소프트웨어 프로젝트의 생명주기는 “요구분석 → 설계 → 구현 → 테스팅 → 유지보수”의 단계를 거친다.

프로세스 (Process)

프로세스는 소프트웨어 시스템을 구축하기 위해 수행되는 작업의 단계로, 소프트웨어 개발에 관한 기술적, 관리적 이슈를 다루는 작업을 소프트웨어 프로세스라고 부른다. 프로세스는 여러 컴포넌트 프로세스로 구성된다. 각 컴포넌트 프로세스는 서로 다른 목적을 가지지만 서로 협력하여 전체 소프트웨어 공학의 목적을 만족시킨다.

프로세스 종류

개발 프로세스는 프로젝트에서 가장 중심으로 수행되는 프로세스로, “개발 프로세스”와 “괸리 프로세스”로 분류된다.

`개발 프로세스`: 수행해야 할 개발 작업과 품질 보증 작업들이 해당된다.
`관리 프로세스`: 비용, 품질, 기타 목표를 맞추기 위한 계획, 제어 작업을 말한다.

이 프로세스들을 통해 프로젝트 엔지니어링 프로세스를 이룬다. 소프트웨어 프로세스는 동적인 요소이며, 새로운 기술과 도구를 도입하고 소프트웨어 개발에 대한 이해가 커지면서 수정되어야 한다.

프로세스 정의

프로젝트는 단계 별로 이루어지고, 이때 각 단계는 프로젝트의 목표를 만족시킬 수 있는 작업들로 정의되어야 한다. 프로세스는 비용을 줄이기 위해 그 단게에 유입되는 결함을 찾아내는데 초점을 두어야 한다.

각 단계의 결과를 검증해야 하기에 적당한 양의 단계로 분류해야 한다. 그리고 각 단계가 언제 시작되고 끝나는지, 각 단계의 진입 조건과 출구 조건을 다루어야 한다. 각 작업의 진입 조건은 그 전 단계의 종료 조건과 일관되어야 한다.

프로세스 특성

프로세스를 정의할 때, 그 프로세스가 사용하기 적합한지를 판단하는 기준은 다음과 같다.

`예측 가능성`: 어떤 프로젝트 안의 프로세스의 결과가 프로젝트를 완성하기 전에 얼마나 정확하게 예측될 수 있다.
`테스팅 & 유지보수 용이성`: 소프트웨어 개발에서는 테스팅과 유지보수에 가장 많은 노력과 비용이 들어가기에 테스팅과 유지보수에 드는 노력과 비용을 낮추도록 힘써야 한다.
`변경 용이성`: 소프트웨어 개발에는 변경되는 것들이 많기에 수정하기 용이한 프로세스들로 구축하는 것이 소프트웨어 개발에 유리하다.
`결함 제거 용이성`: 개발 각 단계에서 발생한 오류는 그 단계에서 수정되어야 하며, 오류 탐색과 수정은 소프트웨어 개발 전체 단계에 지속적인 프로세스가 되어야 한다.

프로세스 모델 (Process Model)

소프트웨어의 개발 프로세스 모델은 개발 단계를 단순화하여 표현한다. 각 모델은 특정 관점에서 나타낸 일반적인 프로세스의 유형이다. 프로세스 모델은 더 구체적인 프로세스를 생성하도록 변경하고 확정할 수 있다.

폭포수 모델 (Waterfall Model)

폭포수 모델은 가장 오래되고 널리 사용된 프로세스 모델로, 계획 단계에서 운영 및 유지보수 단계까지 각 프로세스를 위에서부터 순차적으로 수행하는 방식이다. 각 프로세스 사이에 결과물이 분명히 구분되며, 이전 작업으로 돌아가지 않고 폭포수가 위에서 흘러내리듯 선형적으로 작업이 수행된다.

따라서 폭포수 모델을 사용할 때는, “각 단계가 끝나고 나와야 할 결과물을 명확히 정의해야 한다.” 폭포수 모델의 장단점은 다음과 같다.

(장점) 단순하고 이해하기 좋으며 각 단계가 명확하여 프로세스의 진행 상황을 관리하기 쉽다.
(장점) 개발자가 비슷한 소프트웨어를 설계하고 개발하여 응용문제를 알거나 요구 사항이 명확한 대규모 시스템을 장기간 개발할 때 적합하다.
(단점) 작업이 순차적으로 이루어지기에 이전 단계의 문제가 발견되지 않고 넘어가면 문제가 생긴다.

V 모델 (Verification Model)

V 모델은 폭포수 모델을 확장하여 만든 모델로, 분리된 프로그램들이 완성되면 단위 테스트를 통해 확인하고, 인터페이스에 대한 설계대로 구현되었는지 통합 테스트를 하여 올바로 작동하는지 확인하고, 시스템 테스트를 통해 전체 시스템이 제대로 동작하는지 확인하며, 마지막으로 사용자의 요구를 모두 반영하는지 인수 테스팅을 실시한다.

프로토타이핑 모델 (Prototyping Model)

프로토타이핑 모델은 요구 사항에 대한 피드백을 받기 위해 시스템을 실험적으로 만들고(프로토타입) 사용자에게 보여주고 평가를 받는 방법이다. 프로토타이핑은 소프트웨어의 일부를 구현하여 보여주며, 구현 단계에서 사용될 골격 코드가 될 수 있다. 이때, 프로토타입은 쓰고 버리는 일회용과 계속 발전시켜 나가는 진화형으로 나누어진다.

프로토타이핑 모델의 장단점은 다음과 같다.

(장점) 문제점을 빨리 파악하여 요구 사항에 반영할 수 있고 정확한 기능 요구를 확정 지을 수 있다.
(장점) 설계 시 기술적인 문제가 있으면 프로토타입을 만들어 타당성을 확인할 수 있다.
(단점) 프로토타입 개발에 많은 비용이 들 수 있고, 프로토타입을 중심으로 요구가 정리되는 경우 문제가 생길 수 있다.

나선형 모델 (Spiral Model)

나선형 모델은 “목표, 방법, 제약 조건 결정”, “위험 요소 분석 및 해결”, “개발과 평가”, “다음 단계 계획”의 4가지 단계를 반복 순환하며 시스템을 확대시켜 나가는 방법이다. 재정적, 기술적 위험 부담이 큰 경우, 요구사항 및 아키텍쳐를 이해하기 어려운 경우 적합하다.

반복 주기가 시작될 때 소프트웨어의 목표와 제약 조건을 결정한다.
프로토타입을 만들며 위험을 분석하고 하나의 표준 개발 주기를 진행하여 소프트웨어를 구축한다.
소프트웨어를 구축하면 다음 주기를 준비하고 계획한다.

소프트웨어 개발 프로세스를 위험 관리 측면에서 보며, 프로젝트 초기에 실패 요인과 위험 요소를 찾아내어 대비하고자 한다. 나선형 모델의 장단점은 다음과 같다.

(장점) 비선형적이며 반복적으로 개발이 진행되어 소프트웨어 품질을 높일 수 있다.
(장점) 오류 수정과 앞 주기에서 이루어지는 변경에 유연하게 대처 가능하다.
(단점) 싸이클을 잘 관리하는 것이 어렵다.

진화적 모델 (Evolutionary Model)

진화적 모델은 프로토타입을 개발하고 좋은 쪽으로 개선을 시키며 발전시키는 방법을 따른다. 진화적 모델에서는 초기 단계에 모든 요구 사항을 파악하여 확정할 필요가 없고, 시스템 개발 도중에 요구를 변경하기 쉽다. 진화적 모델에서 시스템을 발전시키는 두 가지 방법이 있다.

`점증적 방법`: 시스템을 기능 별로 여러 개의 서브시스템으로 나누고 일부 기능만을 포함한 서브시스템을 배포하고 다음에 새로운 기능을 추가한다.
`반복적 방법`: 시스템 전체 기능을 대상으로 하되 릴리스할 때마다 기능을 더 완벽히 개발하는 형태이다.

진화적 모델의 장단점은 다음과 같다.

(장점) 몇 가지 기능이 부족해도 초기에 사용 교육을 할 수 있다.
(장점) 이전에 없던 기능을 가진 스프트웨어에 대한 시장을 빨리 점유할 수 있다.
(장점) 자주 릴리스하여 가동 중인 시스템에서 발생하는 예상 못한 문제를 신속하고 꾸준하게 고칠 수 있다.
(단점) 프로젝트 관리가 상당히 복잡해지기에 소규모 프로젝트에 적합하지 않다.
(단점) 반복적인 프로세스로 프로젝트의 끝이 보지 않을 수 있다. 이로 인해 프로젝트 실패 위험도 커진다.
(단점) 프로젝트의 진행이 위험 분석에 크게 의존될 수 있다.

통합 프로세스 (Unified Process)

통합 프로세스는 여러 싸이클로 구성되고, 싸이클은 시스템을 출시하여 종결된다. 하나의 반복 과정은 “도입”, “정련”, “구축”, “전환” 4단계로 구성된다. 각 단계는 점검 일정으로 종류되고 관리자가 프로젝트에 대한 중요한 결정을 내린다. 각 4단계는 다음과 같다.

`도입(Inception)`: 간단한 유스케이스 모델, 소프트웨어 구조, 프로젝트 계획을 작성한다. 도입 단계는 1~2회 정도 반복으로 도입 단계를 진행한다.
`정련(Elaboration)`: 대부분의 유스케이스를 작성하고 아키텍쳐 설계를 나타내는 UML 다이어그램을 그린다.
`구축(Construction)`: 남아 있는 유스케이스에 대해 구현하고 시스템에 통합한다.
`전환(Transition)`: 시스템을 배치하고 베타 테스팅을 진행하며 결함 수정 및 기능 개선의 작업을 수행한다.

NOTE!
유스케이스 모델: 어떤 시스템이 개발될 것인지 나타내기 위해 비지니스 프로세스를 모델링한 것

통합 프로세스의 장단점은 다음과 같다.

(장점) 방법론과 프로세스가 잘 문서화되고 쉽게 접할 수 있어 교육 받기 좋다.
(장점) 요구 변경에 대한 리스크를 적극적으로 해결 가능하다.
(장점) 반복적 개발 싸이클을 통해 통합을 위한 노력과 시간을 줄일 수 있다.
(단점) 프로세스가 너무 복잡하여 전문가가 아니면 이해하기 어렵다
(단점) 의사소통에 대한 자세한 가이드가 없고, 조직화되지 않은 개발로 완전하지 않은 소프트웨어 개발로 이어질 수 있다.

애자일 프로세스 (Agile Model)

애자일 프로세스는 프로젝트에 대한 피드백을 빨리 받고 방향을 평가하여 짧은 싸이클을 반복한다. 2~6주 사이의 짧은 주기로 개발을 반복해서 부분적인 기능을 완성시키고 시스템 전체를 완성시킨다. 애자일 프로세스의 중요한 특징은 다음과 같다.

형식적 문서보다 커뮤니케이션을 통해 프로젝트가 목표를 향하여 나아가게 한다.
사용자는 문서가 아니라 실행되는 소프트웨어를 통해 요구를 확인한다.
사용자의 요구는 비지니스 환경에 따라 프로젝트 중간에 바뀔 수 있다는 것을 고려한다.
짧은 주기 동안 요구정의에서 구현, 테스트를 이루며 각 반복 주기의 성찰 의견을 다음 계획에 포함한다.

애자일 프로세스의 장단점은 다음과 같다.

(장점) 다른 프로세스 모델보다 소프트웨어 배포가 빨라 즉각적 피드백을 받을 수 있으며, 변화에 더 잘 적응하고 대응할 수 있다.
(장점) 항상 최신 작업을 수행하기에 자원의 낭비가 적다.
(장점) 문제와 결함을 더 빨리 감지하고 수정할 수 있다.
(장점) 불필요한 문서화에 시간을 덜 쓰고, 비용이 저렴하기에 아이디어를 실험하고 테스트한다.
(단점) 문서화가 등한시되기에 개발자의 성장 속도를 높이기 어렵다.
(단점) 애자일 모델은 개발자와 고객이 지속적으로 상호 작용해야 하기에 많은 에너지와 시간을 소모한다.
(단점) 명확한 끝이 정의되지 않으면 프로젝트가 종료되지 않고 계속 될 수 있다.

지원 프로세스 (Support Process)

소프트웨어 개발에 있어서는 개발 프로세스 뿐만 아니라 프로젝트 관리 프로세스, 형상 관리 프로세스, 품질 관리 프로세스 등 개발 전 과정에 필요한 다른 성격의 프로세스도 필요하다. 이를 “지원 프로세스”라고 한다.

관리 프로세스

관리 프로세스는 비용과 품질 목표를 달성하기 위해 관리하는 모든 작업을 말한다. 당연히 대규모 프로젝트를 성공시키기 위해서는 관리 프로세스가 필요하다. 관리 프로세스의 작업은 크게 다음의 세 가지로 분류된다.

계획: 프로젝트의 목적에 맞는 소프트웨어 개발 계획을 개발하는 것으로, 개발 작업이 시작되기 전에 작성되고 개발하면서도 변경된다.
모니터링: 개발하는 동안 수행하는 모든 작업이 프로젝트의 목적에 부합하는지, 개발이 계획대로 진척되는지 확인하기 위하여 데이터를 수집한다.
제어, 분석: 모니터링에 의하여 확인된 사실을 분석하고, 계획과 차이나는 부분을 조정한다.

품질 보증 프로세스

품질 보증 프로세스는 소프트웨어 프로젝트의 프로세스와 프로덕트에 대한 품질을 관리하고 향상시킨다. 크게 다음의 두 가지로 분류된다.

인스펙션 프로세스(Inspection Process): 정의된 프로세스에 따라 동료 그룹이 작업 결과를 검사하는 것으로, 적은 비용으로 조기에 결함을 찾아 생산성을 높인다.
프로세스 관리 프로세스: 프로세스 관리는 프로젝트 관리와 다르다. 프로세스 관리는 프로세스를 개선하여 생성된 결과의 품질과 생산성을 향상시키는 것으로, 프로젝트가 진행되는 기간을 초과하는 긴 시간 동안 이루어진다.

형상 관리 프로세스

형상 관리는 “소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것”으로, 소프트웨어 프로젝트에서는 변경이 빈번히 일어나기에 개발 중에 발생하는 변경을 체계적으로 컨트롤하는 것이 중요하다.

형상 관리는 높은 품질의 소프트웨어 프로덕트를 고객에게 납품하기 위해 필수적이다. 결국 프로젝트를 수행하는 동안 요구의 변경은 필연적인데, 프로젝트의 후반에 요구가 변경되면 프로젝트에 치명적이다.

개발 방법론 (Develope Methodology)

소프트웨어 개발 방법론이란 소프트웨어 프로세스의 각 작업을 어떻게 수행하는가를 정의한 것이다. 즉, 프로세스의 구현이 바로 방법론이다.

NOTE!
소프트웨어 개발 방법론: 소프트웨어 프로세스의 각 작업을 어떻게 수행하는가를 정의한 것

방법론은 프로세스가 구체적으로 구현된 것이고 소프트웨어 프로세스는 하나 이상의 방법론으로 구현될 수 있다.

구조적 방법론 (Structured Development Methodology)

구조적 분석 설계 방법론은 실세계의 문제를 “처리”라는 관점으로 모델링한다. 자료 흐름도를 사용하여 모델링을 하며, 각 노드는 외부 엔티티, 프로세스, 자료 저장소를 표현하고 자료 흐름 관계를 간선으로 나타낸다.

구조적 분석에서는 복잡한 문제를 쉽게 다루기 위해 분할 정복 원리를 적용한다. 시스템 전체를 프로세스로 보고 복잡한 프로세스를 단순한 프로세스로 분할하며 나간다. 계층의 말단 프로세스를 쉽게 구현할 수 있을 때까지 분할하는 것이다.

이때, 소프트웨어 모듈 사이의 구동 관계를 나타낼 때는 자료 흐름도가 적절하지 않다. 소프트웨어와 모듈 사이의 구동관계는 자료 흐름이 아니라 제어 흐름이기 때문이다. 따라서 구조적 설계는 자료 흐름도를 구조도로 변경한다. 구조도는 모듈 사이의 관계를 나타내는 그래프이다.

정보공학 방법론 (Information Engineering Methodology)

구조적 방법론에서 발생하는 기업 전체의 조망과 데이터 통합의 어려움을 극복하기 위해 정보공학 방법론이 고안되었다. 정보공학 방법론은 기업 전체나 기업의 주요부분을 계획, 분석, 설계 및 구축에 정형화된 기법들과 상호 연관성 있게 통합 및 적용하는 데이터 중심 방법론이다.

객체지향 방법론 (Object-Oriented Methodology)

객체지향 방법론은 실세계를 “객체”로 판단하고, 객체 사이의 상호작용은 모델링하는 방법이다. 객체지향 방법론은 대규모 시스템을 클래스로 “모듈화”하고 “캡슐화”하는 방법이다. 결국 객체지향 방법론에서는 주어진 작업을 수행하기 위해 협력하는 객체들의 모임이 바로 시스템이다.

객체지향 프로그래밍이 널리 퍼지며 다양한 방법론들이 나오게 되었는데, 서로 다른 방법론을 이용하여 개발된 시스템을 통합하고 유지보수하는 것은 비용도 많이 들고 효율적이지 않다. 이러한 문제들을 해결하기 위해 통합된 방법이 요구되었고 이를 통해 UML(Unified Modeling Language)와 UP(Unified Process)가 등장하게 되었다.

[소프트웨어 공학] - 소프트웨어 공학 개론 (Introduction of Software Engineering)

shineast_ — Sat, 22 Mar 2025 00:31:10 +0900

소프트웨어 (Software)

소프트웨어는 컴퓨터를 작동시키는 프로그램으로 하드웨어의 동작을 제어하는 명령어들로 구성되어 있다.

소프트웨어 특징

소프트웨어가 가지는 특징은 다음과 같다.

`복잡성(Complexity)`: 소프트웨어가 자동화하려는 대상은 수많은 내부 요소들로 이루어져 있어 복잡하다.
`순응성(Conformity)`: 환경이나 데이터의 변화에 따라 적절하게 변형된다.
`변경성(Changeability)`: 소프트웨어는 문자로 구성된 프로그램으로 쉽게 변경 가능하며 개발 과정 중 자주 변화된다.
`비가시성(Invisibility)`: 소프트웨어는 가시적인 매체에 저장되지만 그 자체는 무형이며 구조가 코드 안에 있기에 쉽게 드러나지 않는다.

소프트웨어 종류

소프트웨어는 크게 세 가지 유형으로 분류된다.

`주문형 소프트웨어`: 특정 고객이나 기업의 요구를 만족시키기 위하여 제작된 소프트웨어
`패키지형 소프트웨어`: 패키지화하여 상업적으로 판매하는 소프트웨어
`임베디드 소프트웨어`: 다른 시스템에 내장된 소프트웨어

소프트웨어 개발 작업 (Software Development)

소프트웨어 개발 시스템

소프트웨어는 독립적으로 존재하지 않고 컴퓨터를 기반으로 하는 여러 시스템과 관계를 맺는다. 따라서 소프트웨어 개발은 시스템 안에 속하는 여러 요소를 파악하고 관계를 설정하는 작업이 포함된다. 시스템은 다음의 성질을 가진다.

서브 시스템: 시스템은 밀접히 관련된 서브 시스템들로 구성된다.
기능적 분할: 시스템은 규모가 작은 부속 서브 시스템들로 분할 가능하다.
시스템 경계: 시스템과 주변 환경을 구분할 수 있는 경계가 있다. 이 경계가 입력과 출력이 맞닿는 곳이다.
자동화 경계: 시스템은 자동화된 부분과 수동 작업 부분을 나누는 경계이다.

소프트웨어 개발의 기본 활동

소프트웨어를 만들고 실사용 단계까지 가기 위해서는 여러 사람들의 지적 활동이 필요하다. 이를 통해 다양한 결과물이 만들어지는데 이때, 네 가지의 기본 활동이 필요하다.

`명세화(Specification)`: 소프트웨어 제품을 생산하기 전, 요구 사항을 엄격하게 정리하여 부정확하게 개발하여 제품 개발이 실패하는 것을 방지한다.
`구현(Coding)`: 시스템의 명세를 주어진 여건에 맞게 설계하여 프로그래밍 언어로 변환하는 것이다. 주어진 설계에 대해 최선의 방법으로 구현하는 것이다.
`검증(Verification)`: 구현된 소프트웨어가 고객의 의도와 일치하는지 확인하는 작업이다.
`유지보수(Maintenance)`: 개발된 이후로도 사용 단계에 결함이 있다면 수정하고, 고객의 요구 변화에 맞게 소프트웨어를 수정한다.

소프트웨어 개발 작업의 특징

소프트웨어 개발은 공장에서 대량 생산하는 방식으로 이루어지지 않기에 하드웨어 제조와 관련하여 오랜 기간 축척된 생산 기술이 소프트웨어 개발에 그대로 적용되지 않는다.

예를 들어, 2배의 인원을 투입한다고 소프트웨어 개발 생산성이 2배로 늘지 않고, 2배의 시간을 준다고 해서 결과가 배로 향상되지도 않는다. 소프트웨어의 질과 양은 개발에 참여한 개인의 능력에도 크게 좌우된다.

WARNING!
즉, 인적 요인과 비가시성은 소프트웨어 개발에 대한 공학적 접근을 어렵게 만든다.

소프트웨어 개발에 있어 간단한 문제에 대해서는 충분한 해결책이 제시되었으나, 여전히 소프트웨어 개발에는 다음과 같은 어려움들이 존재한다.

명세화의 어려움: 소프트웨어 개발은 보고 사용하기 전까지 필요한 것을 명확히 정의하기 어렵다.
재사용의 어려움: 소프트웨어는 다루는 문제가 똑같지 않기에 미리 재사용할 부품을 만들기 어렵다.
예측의 어려움: 소프트웨어는 여러 외부 요소(법규, 하드웨어, 성능, 업무 절차)의 영향을 받기에 사전 견적이나 프로젝트의 규모를 예측하기 어렵다.
유지보수의 어려움: 다른 사람이 개발한 소프트웨어는 쉽게 이해하는 것이 어렵고, 이해해서 고쳐도 다른 부분에 오작동을 일으키기 쉽다.
고품질의 어려움: 한 줄의 코드를 수정하더라도 테스트할 내용이 많아지고, 모든 실행 조합을 다 테스트하는 것은 불가능하다.

비효율적인 소프트웨어 개발

소프트웨어를 개발할 때 설계, 테스팅, 문서화 등을 생략하고 코딩에만 집중하는 것은 비효율적인 소프트웨어 개발이다. 계획이나 절차 없는 소프트웨어를 개발 방식은 코딩과 수정 작업의 연속이다. 그때그때마다 즉흥적으로 프로그래밍하고 사용자가 원하는 것과 다르면 수정하는 방식을 반복하여 소프트웨어를 완성시키는 것이다.

이러한 소프트웨어 개발 방식은 다음의 문제를 일으킨다.

개발 지연과 예산 초과: 요구가 명확하게 파악되지 않고 프로그램의 골격이 확정되지 않아 계속 수정을 반복하게 된다.
낮은 품질: 소프트웨어의 결함은 개발 과정에 포함되는 인간의 실수 때문인데, 사람의 실수를 관리하는 것은 매우 어려운 일이다.
유지보수의 곤란함: 소프트웨어는 배포 이후에도 많은 수정이 필요한데, 시스템을 구성하는 각 요소를 잘 구조화하지 않고 관리하지 않으면 간단한 수정도 어려워진다.
재작업: 구조화되지 않고 마구잡이로 개발하고 수정한 프로그램은 재작업 가능성이 높아진다.

소프트웨어 공학 (Software Engineering)

결국, 비효율적인 소프트웨어 개발을 지양하고 “체계적으로 접근하고 원리를 적용하여 소프트웨어를 개발하기 위하여” 소프트웨어 개발을 공학적으로 접근하려는 개념이 도입되었다.

소프트웨어 공학의 목표

소프트웨어 개발에 공학적 접근 방법을 적용하는 궁극적인 목표는 다음과 같다.

복잡도 저하: 대규모 소프트웨어는 복잡하고 개발하기 어렵기에 큰 문제를 소규모의 작은 문제로 나누어 해결한다.
비용 최소화: 소프트웨어 개발은 많은 인력이 필요하고 비용이 많이 드는 작업이다. 이때, 필요하지 않는 일과 중복되는 일을 최소화한다.
개발 기간 단축: 계획 없이 하는 일은 시간을 낭비하는데, 개발 작업을 잘 계획하고 설계하여 개발 기간을 단축시킨다.
대규모 프로젝트 관리: 큰 프로젝트는 단기간에 구축하기 어렵기에 공학적 접근을 통하여 관리를 진행한다.
고품질 소프트웨어: 결함을 모두 해결하기 위해 테스트와 유지보수 작업 방법을 동원하여 프로젝트를 진행한다.
효율성: 소프트웨어 내에서 표준화 작업을 수행하여 작업의 효율을 높인다.

결국, 소프트웨어 공학의 목표를 한 줄로 정의하면 다음과 같다.

NOTE!
소프트웨어 공학: 여러 원리와 방법을 적용하여 품질 좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞춰 개발하는 것이다.

소프트웨어 공학의 주제

궁극적인 목표인 “품질”, “생산성”, “비용”을 고려하여 개발하기 위해 소프트웨어 공학은 다음의 세 가지 작업으로 나눌 수 있다.

`단계적 프로세스`: 소프트웨어에 대한 개념을 파악하고 소프트웨어를 구현할 때까지 정해진 순서의 작업을 수행한다. 비지니스 요구를 파악하고 타당성을 검토하며 시스템이 제공해야 할 요구와 성능을 명세화한다. 설계하고 구현하고 테스트하여 목표 환경에 설치하는 단계적 절차를 밟는다.
`품질 보증`: 개발 작업이 적절히 수행되었는지 확인한다. 개발 작업 결과물이 요구에 일치하는지, 품질 수준에 맞는지 검사한다.
`프로젝트 관리`: 개발과 품질 보증 작업을 관리하고 감독한다. 소프트웨어 시스템이 정해진 일정과 예산 내에 진행되도록 확인하고 관리한다.

이 세 가지의 작업을 통해 품질과 생산성, 비용을 고려한 소프트웨어 개발을 이루어낼 수 있다.

[컴퓨터 네트워크] - 네트워크 구성 (Network Architecture)

shineast_ — Wed, 19 Mar 2025 14:14:20 +0900

네트워크의 구성 (Network Architecture)

네트워크를 구성하는 요소로는 “컴퓨터”, “네트워크 접속 장치”, “네트워크 전송 매체”로 분류된다.

`PC(컴퓨터, 서버)`: 우리가 일상에서 주로 사용하는 웹 브라우저, 카카오톡, 인스타그램 등은 애플리케이션의 종류이다. 애플리케이션은 네트워크를 사이에 두고 다양한 데이터를 송수신한다.
`네트워크 접속 장치`: 애플리케이션의 데이터를 정상적으로 전송하기 위한 장치로, 기본적으로 한 네트워크 내부에서 데이터 전송을 수행하는 “스위치”와 서로 다른 네트워크를 구분 짓고 연결하는 “라우터”가 있다.
`네트워크 전송 매체`: 컴퓨터와 네트워크 접속 장치는 전송 매체에 의해 서로 연결되며, “유선 전송 매체(케이블)”와 “무선 전송 매체(전파)”로 분류된다. 케이블은 다양한 종류가 있기에 네트워크 규격에 맞는 케이블을 사용해야 하며, 네트워크 통신에 사용되는 전파는 규격에 따라 전파의 파장이나 주파수가 지정되어 있다.

네트워크 형태 (Network Type)

근거리 네트워크 (Local Area Network: LAN)

근거리 네트워크는 범위가 건물 안이나 특정 지역인 네트워크이다. 유선 케이블, 적외선 링크, 무선 송수신기 등을 이용하여 통신한다.

광역 네트워크 (Wide Area Network: WAN)

광역 네트워크는 2개 이상의 LAN을 넓은 지역에 걸쳐 연결한 네트워크로 WAN은 ISP(통신 사업자)가 제공하는 서비스를 사용하여 구축되는 네트워크이다.

LAN은 연결한 거리가 짧아서 신호가 약해지거나 오류가 발생할 확률이 높으나, WAN은 멀리 떨어진 LAN과 연결되어있기에 신호가 약해지거나 오류가 발생할 확률이 더 높고 속도도 LAN에 비해 느리다.

인트라넷 (Intranet)

인트라넷은 인터넷에서 사용하는 회선과 여러 기반 기술을 이용해 구축하는 사설 네트워크이다. 인트라넷은 외부 공격으로부터 보호되도록 설계되며 기업의 중요한 데이터와 시스템을 외부의 위험으로부터 보호할 수 있다.

네트워크 접속 장치 (Network Connecting Device)

네트워크 접속 장치는 통신망 구성에 가장 기본이 되는 하드웨어로, 다양한 형태의 근거리 통신망을 연결하여 좀 더 복잡하고 큰 광역 통신망을 형성할 수 있다.

LAN 카드 (Network Interface Card, NIC 카드)

LAN 카드는 두 대 이상의 컴퓨터로 네트워크를 구성하기 위해 외부 네트워크와 빠른 속도로 데이터를 송수신할 수 있도록 컴퓨터 내에 설치하는 확장 카드이다.

네트워크에 연결하는 물리적 장치에는 반드시 하나 이상의 LAN 카드가 있어야 하고, LAN 카드는 전송 매체 접속, 데이터 입출력, 데이터 송수신, 프로토콜 처리 등을 담당한다.

허브 (HUB)

허브는 여러 개의 입력 및 출력 포트가 있는 특수한 형태의 네트워크 장치로, 허브를 사용하면 네트워크에 연결된 컴퓨터끼리 통신이 가능하다. 한 포트에서 수신된 신호는 허브의 다른 모든 포트로 즉시 재전송되고 모든 입력과 출력이 연결되어 여러 개의 노드가 같은 중계기를 공유할 수 있다. 허브는 더미 허브, 스위칭 허브, 스태커블 허브, 인텔리전트 허브 등으로 분류된다.

`더미 허브`: 단순히 컴퓨터 간의 네트워크를 중계하는 역할을 하는 허브로, 네트워크의 전체 대역폭을 노드 수만큼 분할하여 사용한다. 이에 따라 허브에 연결된 노드 수가 증가하면 네트워크의 속도가 떨어진다.
`스위칭 허브`: 전체 대역폭을 컴퓨터 노드 수만큼 나누어 사용하는 문제점을 해결한 접속 장치이다. 수신지 주소를 읽어 그 주소의 단말기로만 데이터를 보내는 스위칭 기능이 있으며 노드들을 각각 점대점으로 접속시킨다. 따라서 더미 허브보다 전송 속도가 빠르다
`스태커블 허브`: 스택 접속 포트를 갖춘 허브로, 허브 사이를 연결하여 용량을 확장할 수 있다. 여러 허브가 하나의 허브처럼 동작하여 전송 속도의 차이가 적다.
`인텔리전트 허브`: 신호의 조절과 변경 등 다양한 지능형 기능을 포함한 허브로, 네트워크 관리 시스템을 이용하여 데이터 제어와 분석이 가능하다. 또한 충돌 발생 시 충돌을 일으키는 포트를 강제로 차단하는 기능을 가지고 있다.

스위치 (Switch)

스위치는 컴퓨터에 할당되는 대역폭을 극대화하는 장치로 근거리 통신망이 제공하는 대역폭을 모두 컴퓨터로 전송한다.

데이터를 하드웨어로 처리하며, 연결되는 포트에 서로 다른 속도를 연결하는 기능을 제공한다. 스위치는 수신하는 데이터의 수신 컴퓨터를 식별 가능하기에 데이터를 수신하기로 한 컴퓨터에만 데이터를 보낸다.

브리지 (Bridge)

브리지는 2개 이상의 근거리 통신망을 연결하여 하나의 네트워크로 만드는 장치로, 수신지 주소에 따라 특정 네트워크 트래픽만 통과시킬 수 있도록 설계된 특수한 네트워크 스위치이다.

브리지는 받은 신호를 증폭하고 입력과 출력을 연결하고 전체 네트워크의 트래픽을 줄이기 위해 네트워크를 세그먼트 단위로 분할한다. 이때, 세그먼트란 하나의 허브나 스위치로 구성된 가장 작은 규모의 네트워크를 말한다.

게이트웨이 (Gateway)

게이트웨이는 종류가 다른 2개 이상의 네트워크를 서로 접속하여 정보를 주고 받을 수 있는 장치이다. 하나의 네트워크를 다른 네트워크와 연결할 떄 사용되며, 서로 다른 프로토콜 통신망 간에 프로토콜을 변환하여 정보를 주고 받을 수 있다.

중계기 (Repeater)

중계기는 접속 시스템의 수를 증가시키거나 네트워크 전송 거리를 연장시키기 위해 사용한다. 네트워크에서 신호를 수신하여 증폭한 후 다음 구간으로 재전송하는 역할을 한다. 중계기는 신호를 증폭하기만 하고 데이터의 내용을 변경하지 않는다. 따라서 중계기는 통신망을 구성하는 세그먼트를 확장하거나 서로 연결하는데 주로 사용한다.

라우터 (Router)

라우터는 서로 다른 네트워크 간에 통신하는데 사용하는 장치로, 구조가 다른 망을 연결할 수 있기에, 근거리 통신망(LAN)과 대도시 통신망(MAN), 광역 통신망(WAN)을 연결하는데 이용된다.

라우터는 효율적인 경로를 선택하는 라우팅 기능도 수행한다. 그 외에도 “오류 패킷 폐기 기능”, “혼잡 제어 기능”, “네트워크 트래픽 방향 지정”, “방화벽 등의 보안 기능 제공” , “둘 이상의 네트워크 연결”, “웹 페이지 요청을 수신지로 전송” 등의 역할들을 수행한다.

네트워크 접속 형태 (Network Topology)

전송 매체와 프로토콜이 결정되면 다양한 형태로 컴퓨터를 구성할 수 있다. 네트워크에 연결된 노드와 링크가 물리적으로 배치된 방식을 “네트워크 토폴로지(Network Topology)”라고 한다.

네트워크 접속 형태는 네트워크에 연결된 여러 노드의 상호 연결 방법을 보여주는데, 그 종류로는 “성형”, “버스형”, “트리형”, “링형”, “그물형”, “혼합형” 등이 있다.

성형 (Star Topology)

성형은 가장 일반적인 네트워크 구성 형태로, 네트워크 중앙에 위치한 허브가 회선 교환 방식을 사용하여 통신하려는 노드 2개에 전용 회선을 만든다. 모든 노드가 중앙의 허브에 연결되어 통신된다. 성형의 장단점은 다음과 같다.

(장점) 각 장치와 다른 장치를 연결하는 링크 하나와 I/O 포트 하나만 필요하기에 설치 비렴이 저렴하다
(장점) 중앙 집중적 구조로 인해 유지 보수나 확장이 용이하다
(장점) 링크 하나가 끊어져 작동하지 않을 때, 해당 링크만 영향을 받고 다른 링크는 영향을 받지 않아 안전하다.
(단점) 중앙에 있는 전송 제어 장치에 장애가 발생하면 전체 네트웤크가 작동할 수 없고 통신량이 많으면 전송이 지연된다.
(단점) 각 노드가 중앙 허브와 연결되어야 하기에 다른 접속 형태보다 많은 케이블이 필요하다.

버스형 (Bus Topology)

버스형은 모든 네트워크 노드와 주변장치가 일자형 케이블(버스)에 연결된 형태로, 하나의 긴 케이블은 네트워크의 모든 장치를 연결하는 중추 네트워크 연결을 한다. 버스형에서는 케이블에 연결된 하나의 노드가 데이터를 전송하면 나머지 노드가 수신할 수 있다. (브로드캐스팅)

NOTE!
브로드캐스팅(Broadcasting): 하나의 송신 측이 다수의 수신 측 단말을 지정하여 동일한 정보나 메세지를 동시에 전송하는 것

버스형은 네트워크 케이블의 양 끝에 종단 저항(Terminator)을 설치해야 신호 반사를 방지할 수 있다.

버스형의 장단점은 다음과 같다.

(장점) 간단히 설치할 수 있고 케이블 비용이 적게 든다.
(장점) 각 장치가 고장이 나도 전체 네트워크에 영향을 미치지 않는다.
(단점) 장비 수가 많아지면 네트워크 성능이 저하된다.
(단점) 중앙 케이블이 고장 나면 전체 네트워크가 작동하지 않으며, 버스 케이블에 결함이나 파손 발생 시 모든 전송은 중단되고 한쪽 지역에 있는 장치 간에도 전송할 수 없다
(단점) 재구성이나 결합, 분리가 어렵다.
(단점) 여러 장치가 동시에 데이터를 전송하면 충돌이 발생할 수 있다.

트리형 (Tree Topology)

트리형은 중앙에 있는 전송 제어 장치에 모든 장비를 연결하지 않고 트리 모양의 노드에 전송 제어 장치를 두고 노드를 연결한다. 트리의 최상위 노드에 위치한 허브는 하위 노드를 제어한다. 트리형의 장단점은 다음과 같다.

(장점) 제어가 간단하여 관리나 네트워크 확장이 쉽다.
(장점) 중앙에 있는 하나의 전송 제어 장치에 많은 장비를 연결할 수 있어 각 장비 간의 데이터 전송 거리를 늘릴 수 있다.
(장점) 여러 컴퓨터를 분리하거나 우선순위를 부여할 수 있다.
(단점) 중앙에 트래픽이 집중되어 병목 현상이 발생할 수 있다. 중앙의 전송 제어 장치가 다운되면 전체 네트워크에 장애가 발생한다.

링형 (Ring Topology)

링형은 노드가 링에 순차적으로 연결된 형태로 모든 컴퓨터를 하나의 링으로 연결한다. 각 노드는 인접한 두 노드와 연결되며 전체 네트워크는 하나의 링을 형성한다. 링형에는 링의 한 방형으로면 데이터를 전송하는 단순 링형(Simple Ring)과 양방향으로 전송하는 이중 링형(Double Ring)이 있다. 링형의 장단점은 다음과 같다.

(장점) 구조가 단순하여 설치와 재구성이 쉽고, 장애가 발생해도 복구 시간이 빠르다.
(장점) 각 장치는 바로 이웃하는 장치에만 연결되어 장치를 추가/삭제할 때는 연결선 2개만 움직이면 된다.
(장점) 케이블 비용을 많이 줄일 수 있다.
(장점) 신호가 항상 순환하기에 장치가 특정 시간 내에 신호를 받지 못하면 경보를 할 수 있다.
(단점) 링을 제어하는 절차가 복잡하고 새로운 장비를 연결하려면 링을 절단하고 장비를 추가해야 한다.
(단점) 단순 링형의 경우 링에 결함이 생기면 전체 네트워크를 사용할 수 없다. (이중 링형 또는 스위치를 사용하여 해결 가능)

그물형 (Mesh Topology)

그물형은 중앙에 제어하는 노드가 없고 모든 노드가 서로 전용의 점대점으로 연결되는 형태이다. 연결된 두 장치 간의 통신만 담당하는 링크를 통해서 연결된다.

(장점) 전용 링크를 통해 데이터를 전송하기에 많은 장치를 공유하는 링크에서 발생하는 통신량 문제를 해결 가능하다.
(장점) 한 링크가 고장나도 전체 시스템에 큰 영향을 끼치지 않는다.
(장점) 메세지를 전용선으로 보내기에 수신자만 받을 수 있다. 보안에 유리하다.
(단점) 노드를 다른 모든 노드와 연결해야 하기에 설치와 재구성이 어렵다.
(단점) 네트워크가 복잡하고 많은 통신 회선이 필요하기에 많은 하드웨어 비용이 든다.

혼합형 (Hybrid Topology)

소규모 네트워크가 아니며 노드 수가 많은 실제 네트워크에서는 효율을 높이고 결함 허용 능력을 극대화하기 위해서 혼합형 접속 형태를 사용한다. 네트워크 서브넷을 서로 연결하여 규모가 큰 접속 형태를 만들기 위해 여러 접속 형태를 결합할 수 있다.

네트워크 전송 매체 (Network Transmission Media)

네트워크 접속 장치는 데이터를 표현하기 위해 신호를 사용한다. 이때 신호는 전자기 에너지 형태로 한 노드에서 다른 노드로 전송된다.

전송 매체란 송신 측과 수신 측을 연결하는 물리적 선로를 의미한다. 각 매체는 전송 지연, 대역폭 등 고유한 특성을 가지고 있다. 전송 매체는 크게 유선 전송 매체와 무선 전송 매체로 분류된다. 유무선 전송 매체의 특성은 매체 자체의 특성과 신호의 특성에 따라 달라진다.

유선 전송 매체 (유도 매체)

`동축 케이블`: 주파수가 높고 데이터 전송이 빠르며 외부 신호와 전자파 차단 능력이 뛰어나다. 주로 유선 방송, 근거리 통신망 등에 사용한다.
`꼬임선`: 네트워크 접속 형태 중 성형에 많이 사용되고 설치하기 쉽다는 장점이 있다.
`광섬유 케이블`: 머리카락보다 가늘어 휘어지는 전송 매체로, 빛을 이용하여 데이터를 전송하기에 외부 간섭에 강하다. 광역 통신망과 근거리 통신망에서 주목 받는 전송 매체이다.

무선 전송 매체 (비유도 매체)

무선 전송 매체에서는 전자파를 매개체로 데이터를 전송한다.

`라디오파`: 빛의 속도로 데이터를 전송하면서 진공 상태나 대기를 통과하여 데이터 전송에 유용하게 이용되는 전파로, 방향성이 없는 무선파를 사용한다.
`마이크로파`: 주파수가 매우 높은 전파로 파라볼라 안테나를 설치하여 전파를 전송한다. 통신 및 레이더 등 광범위한 용도로 사용된다.

[컴퓨터 네트워크] - 네트워크 이해 (Understanding Network)

shineast_ — Mon, 17 Mar 2025 11:21:26 +0900

네트워크 개념 (Concept of Network)

네트워크란 모뎀이나 LAN, 케이블, 무선 매체 등 통신 설비를 갖춘 컴퓨터로, 서로 연결하는 조직이나 체계 통신망을 말한다.

NOTE!
네트워크: 모뎀이나 LAN, 케이블, 무선 매체 등 통신 설비를 갖춘 컴퓨터로, 서로 연결하는 조직이나 체계 통신망

즉, 통신 설비로 두 대 이상의 컴퓨터를 서로 연결하는 것이다. 네트워크로 연결된 컴퓨터는 시공간에 제약을 받지 않고 원하는 정보를 공유하며 활용할 수 있다. 다수의 컴퓨터를 네트워크를 통해 연결했을 때의 장점은 다음과 같다.

데이터 공유 (Data Sharing)

데이터를 서버인 중앙 컴퓨터에 저장하면 하나의 데이터 파일에 해당하는 마스터 사본을 서버에 저장하고 필요할 때마다 사용자가 마스터 사본에 접근할 수 있게 된다. 이때, 여러 사용자가 함께 이용하기 위해 네트워크로 공유된 파일은 특정 권한이 있는 사용자만 데이터를 읽고 수정 가능해야 한다.

주변장치 공유 (Peripheral Device Sharing)

하나의 장치를 네트워크로 연결해서 공유하면 비용을 절약하면서 장치를 중앙 집중화할 수 있기에 관리하기가 편해진다. 예를 들어 프린터의 경우, *스풀링 프로세스를 활용하면 다수의 사용자가 하나의 프린터에 여러 작업을 동시에 보낼 수 있고 특정 작업에 우선순위를 부여해 다른 작업보다 먼저 출력하도록 하는 것이 가능하다.

NOTE!
스풀링 프로세스: 컴퓨터 시스템에서 중앙처리장치와 입출력장치의 처리 속도 차이로 인한 대기 시간을 줄이기 위해 사용하는 기법

능률적인 통신 (Efficient Sommunication)

네트워크를 통해 송신자와 수신자 사이에서 문자나 음성 등의 메세지를 교환하는 “이메일 송수신” 등의 데이터 통신이 가능하다.

손쉬운 백업 (Convenient Back-Up)

네트워크를 이용하면 각 사용자가 접근 가능한 공유 저장장치 중 하나에 모든 데이터를 손쉽게 백업할 수 있고, 자동 백업을 진행하는 네트워크 백업 소프트웨어를 이용하면 파일을 매번 백업 서버에 직접 복사할 필요가 없다.

데이터 전송 규칙 (Rules for Data Transmission)

네트워크가 연결되면 컴퓨터 간의 파일 전송, 웹 사이트 접속, 메일 송수신 등의 작업이 가능하다. 그러나 네트워크나 인터넷에서 데이터를 주고받을 때에는 규칙이 필요하다.

패킷 (Packet)

웹 브라우저를 통해 웹 사이트의 내용을 볼 때, 패킷을 사용한다. 패킷이란 컴퓨터 간에 데이터를 주고 받을 때 네트워크를 통해 전송되는 데이터의 전송 단위이다. 패킷은 헤더, 페이로드, 제어 요소 등을 포함하는 데이터 세그먼트이다.

NOTE!
패킷: 컴퓨터 간에 데이터를 주고 받을 때 네트워크를 통해 전송되는 데이터의 전송 단위

`헤더(Header)`: 데이터의 형태와 데이터의 송수진지, 일련번호 등으로 구성된다.
`페이로드(Payload)`: 실제 전송 데이터를 포함한다.

용량이 큰 데이터를 전송할 때는 데이터가 네트워크의 *대역폭을 많이 점유하여 다른 패킷의 흐름을 방해할 위험을 없애기 위해서 용량이 큰 데이터를 그대로 보내지 않고 데이터를 작게 나누어 보내야 한다.

NOTE!
대역폭: 네트워크에서 이용 가능한 신호의 최고 주파수와 최저 주파수 차이를 말하며, 데이터를 전송할 수 있는 최대 전송 속도

이때, 분할된 패킷은 수신지로 전송 시 네트워크 상황에 따라 전송한 순서대로 도착하지 않을 수 있다. 따라서 수신지에서 분할된 패킷을 원래대로 재결합하는 작업을 수행한다. (네트워크가 지연되면 패킷이 늦게 도착하거나 손실 가능성도 존재한다.) 일련 번호 순서대로 패킷이 도착하지 않아도 원래도 재조립이 가능한 것은 패킷이 디지털 데이터이기 때문이다.

[컴퓨터 구조] - 병렬 컴퓨터 (Parallel Computer)

shineast_ — Thu, 27 Feb 2025 16:45:02 +0900

병렬 처리 (Parallel Processing)

병렬 처리(Parallel Processing)란 하나 이상의 연산을 동시에 수행하여 컴퓨터 연산 속도를 증가시키는 방법이다. 병렬처리기는 이러한 병렬 처리 기법을 구현한 컴퓨터 구조를 말한다. 병렬처리기는 순차처리기에 비해 꽤나 높은 성능 향상을 이끌어내었다.

컴퓨터 성능 평가

컴퓨터 성능을 평가하는 척도는 "시간"이다. 같은 작업량을 최단시간에 수행하는 컴퓨터가 가장 성능이 좋은 것이다. 그리고 이때 말하는 시간은 프로세서가 순수하게 프로그램을 실행하기 위해 소비한 시간인 "CPU 시간"을 말한다. CPU 시간은 다음과 같이 정의된다.

NOTE!
프로그램 CPU 시간 = 프로그램의 CPU 클록 사이클 수 X 클록 사이클 시간

병렬 처리 시스템 분류

병렬처리기 구조는 동시에 처리 가능한 명령어, 데이터 수, 처리기의 내부조직, 처리 기간의 연결구조 등에 따라 분류된다. 대표적인 분류 방법으로 "플린(Flynn)의 분류", "펭(Feng)의 분류", "구조에 의한 분류"가 있다.

플린의 분류 (Flynn)

플린은 컴퓨터 구조를 명령어 스트림과 데이터 스트림이 컴퓨터 내에 몇 개인지를 기준으로 분류했다. 명령어 스트림과 데이터 스트림의 정의는 다음과 같다.

`명령어 스트림(Instruction Stream)`: 프로세서에 의해 실행되기 위하여 순서대로 나열된 명령어 코드들의 집합
`데이터 스트림(Data Stream)`: 명령어들을 실행하는데 필요한 순서대로 나열된 데이터들의 집합

플린의 분류 방식에 따른 컴퓨터 구조는 명령어 스트림과 데이터 스트림을 처리하는 방식에 따라 아래와 같이 나눌 수 있다.

`SISD(Single Instruction Single Data)`: "단일 명령어 스트림-단일 데이터 스트림" 방식으로, 한 번에 한 개씩의 명령어와 데이터를 순서대로 처리하는 단일 프로세서 시스템이다.
`SIMD(Single Instruction Multiple Data)`: "단일 명령어 스트림-복수 데이터 스트림" 방식으로, 모든 프로세서가 같은 프로그램을 수행하며, 각 프로세서가 병렬적으로 다른 데이터를 처리하는 구조이다. 여러 개의 데이터 스트림을 동시에 처리 가능하다.
`MISD(Multiple Instruction Single Data)`: "복수 명령어 스트림-단일 데이터 스트림" 방식으로, 다수의 프로세서들이 서로 다른 명령어들을 실행하지만, 처리하는 데이터 스트림은 한 개인 구조이다. 비현실적이기에 실제로 구현하지 않는다.
`MIMD(Multiple Instruction Multiple Data)`: "복수 명령어 스트림-복수 데이터 스트림" 방식으로, 각 프로세서가 서로 다른 프로그램을 수행하며 또 다른 데이터를 처리하는 구조이다. 모든 프로그램들이 협력하여 통합적인 목적을 이루도록 하는 가장 복잡한 구조이다. 현재까지 개발된 대부분의 다중처리기 컴퓨터 시스템은 MIMD 컴퓨터 구조에 속한다.

펭의 분류 (Feng)

펭은 컴퓨터 구조를 병렬수행 정도에 따라 분류했다. 한 컴퓨터에서 단위 시간 내에 처리 가능한 최대 비트 수를 $P$라고 한다면, 이는 "최대 병렬수행도"가 된다. 그리고 $P_i$를 $i$번째 클록 펄스에서 수행될 수 있는 비트 수라고 하고, $T$ 사이클 동안 처리되는 평균 비트 수 $P_a$는 다음과 같이 구할 수 있다.

$$ P_a = \frac{P_1 + P_2 + \cdots + P_T}{T} $$

이때, $P_a$를 "평균 병렬수행도"라고 한다. 그리고 주어진 컴퓨터 시스템 $C$의 최대 병렬수행도 $P$는 비트 슬라이스의 길이 $n$과 단어의 길이 $m$의 곱셈으로 나타낼 수 있다.

$$P(C) = n \times m$$

펭의 분류 방식에 따른 컴퓨터 구조는 비트 처리 방식에 따라 아래와 같이 나눌 수 있다.

`WSBS(Word-Serial, Bit-Serial)`: 단어별 순차, 비트별 순차 방식으로, 한 워드에 대해 한 번에 한 비트씩 처리하는 방식
`WPBS(Word-Parallel, Bit-Serial)`: 단어별 병렬, 비트별 순차 방식으로, 여러 워드에 한 번에 한 비트씩 병렬적으로 처리되는 방식이다. $m$개의 워드를 묶어 그 중 1개의 비트 슬라이스 단위를 순차적으로 처리하는 방식
`WSBP(Word-Serial, Bit-Parallel)`: 단어별 순차, 비트별 병렬 방식으로, 한 번에 한 워드의 모든 비트를 병렬적으로 처리하는 방식이다. 가장 널리 사용되는 방식
`WPBP(Word-Parallel, Bit Parallel)`: 단어별 병렬, 비트별 병렬 방식으로, 병렬처리의 가능성을 최대로 높인 방식이다,

구조에 의한 분류

다중처리기 시스템은 문제를 해결하기 위해 협력하여 동작하는 독립적인 많은 처리기가 하나의 컴퓨터 시스템을 이루는 것이다. 여러 처리기가 결합하여 하나의 시스템을 이루는 방법은 "분산 처리"와 "병렬 처리"가 있다.

`분산 처리`: 하드웨어 자원이 프로세스 작업에 대하여 상대적으로 약하게 결합되어 동작하는 것
`병렬 처리`: 하드웨어 자원이 프로세스 작업에 대하여 강하게 결합되어 동작하는 것

병렬 처리 시스템은 다중처리기와 다중 컴퓨터로 구분된다.

`다중처리기`: 독자적인 처리기, 기억장치, 입출력, 운영체제를 가진 여러 컴퓨터로 구성된다.
`다중 컴퓨터`: 하나의 운영체제만 가지고 기억장치공간의 입출력 자원을 공유한다.

병렬적이며 비동기적인 컴퓨터 시스템에서 동시에 여러 태스크를 수행하는 "다중 프로세싱"에는 공유기억장치 시스템과 메세지 전달 시스템, 두 가지 기본 모델로 나누어진다.

공유기억장치 시스템 (Shared Memory)

공유기억장치 시스템을 가지는 다중처리기 구조는 처리기와 기억장치모듈 사이에 완전한 연결성이 있는 강결합 시스템이다. 즉, 모든 프로세서들이 상호 연결망에 의해 접속된 주기억장치를 공유한다.

프로세서들이 공통으로 사용하는 데이터들이 공유기억장치에 저장되므로, 별도의 통신 매커니즘이 필요하지 않다. 또한 시스템 효율도 높아지게 된다. 그러나, 공유기억장치를 사용하기에 많은 프로세서가 동시에 통신하는 것은 불가능하다.

메세지 전달 시스템 (Message Passing)

메세지 전달 시스템은 여러 개의 컴퓨터 모듈과 상호 연결망으로 구성되고, 데이터 통신은 메세지를 통해 이루어진다. 즉, 프로세서가 기억장치에 직접 접근할 수 없고 메세지를 통해 통신이 이루어진다는 것이다.

메세지 송수신 방식을 사용하기에 송수신 시간은 길어지지만, 각각의 프로세서가 개별 메세지를 사용하기에 많은 프로세서가 동시에 통신하는 것이 가능하다.

다중처리기 고려사항

병렬성을 활용하고 연산 속도를 증가시키기 위하여 다중처리기를 사용하는데, 이때 몇 가지 고려해야 할 사항들이 있다.

`병렬성 고려사항`: 병렬성을 어떻게 표현해야 하는 가에 대한 고려와 병렬로 처리할 작업을 어떻게 분할할지에 대한 고려가 필요하다.
`기억장치 고려사항`: 기억장치 충돌 문제에 대한 고려, 기억장치 접근의 효율성에 대한 고려와 캐시 일관성에 대한 고려가 필요하다.
`그 밖의 고려사항`: 스케줄링에 대한 고려와 프로세스 동기화에 대한 고려, 시스템의 균형에 대한 고려가 필요하다.

병렬처리기 종류

파이프라인 처리기 (Pipeline Processor)

파이프라인 처리기는 프로그램에 내재하는 시간적 병렬성(Temporal Parallelism)을 활용하기 위하여 프로그램 수행에 필요한 작업을 시간적으로 중첩하여 수행시키는 처리기이다. 이러한 기법을 명령어에 사용하는 것이 "명령어 수행 파이프라인"이다.

한 명령어의 $S_i$ 단계의 수행이 끝나면, 그 다음 단계인 $S_{i+1}$ 단계로 넘어간다. 그리고 다음에 수행시킬 명령어는 $S_{i-1}$에서 $S_i$ 단계로 넘어가게 된다. 따라서 한 파이프라인의 각 단계마다 서로 다른 명령어의 각 단계가 수행된다.

명령어 파이프라인이 정상적인 동작에서 벗어나게 되기도 하는데, 그 원인은 다음과 같다.

`자원 충돌`: 두 세그먼트가 동시에 기억장치에 접근하고자 할 때 발생한다. 명령어 기억장치와 데이터 기억장치를 분리하면 해결된다.
`데이터 의존성`: 어떤 명령어가 이전 명령어의 결과에 따라 수행될 때, 그 값이 준비되지 않았을 경우 발생한다.
`분기 곤란`: 분기 명령어와 같이 프로그램 카운터의 값을 변경시키는 명령에 의해 발생한다.

배열처리기 (Array Processor)

한 컴퓨터 내에서 여러 개의 처리장치를 배열 형태로 가질 때, 이를 배열처리기라고 한다. 배열 내의 처리기들은 동기화되어 병렬 처리를 하여 동시에 같은 작업을 수행한다. 프로그램의 수행을 위해서는 배열 내의 처리기 사이에 데이터 교환이 가능해야 하기 때문에 배열처리기 사이에는 적절한 정보 교환 수단이 세팅되어야 한다.

배열처리기를 구성하는 처리기들은 레지스터, 연산기, 지역기억장치를 가지며 "상호연결망"에 의해 데이터 교환이 가능하다.

다중처리기 (Multiple Processor)

다중처리기란 시스템 상의 여러 처리기에 여러 개의 독립적인 작업을 각각 배정하여 2개 이상의 처리기를 동시에 수행할 수 있는 기능을 갖춘 시스템을 말한다. 다중처리기의 목적은 다음과 같다.

한 작업을 여러 처리기로 나누어 서로 다른 처리기에 할당하고 동시에 실행하여 수행시간을 줄인다.
여러 작업을 동시에 처리하여 시스템의 전반적인 효율성을 향상시킨다.
같은 기능의 처리기를 중복시켜 에러 허용과 동시 처리로 인한 수행 속도를 향상시킨다.

다중처리기의 모든 처리기는 공통의 기억장치모듈, 입출력 채널, 입출력 장치에 접근 가능하며 각 처리기는 자체의 지역기억장치를 가진다. 다중처리기를 구성하는 각 요소들의 연결은 "상호연결 구조"에 의해 결정된다.

데이터 흐름 컴퓨터 (Data Flow Computer)

보편적으로 사용되는 폰 노이만형 컴퓨터를 "제어 흐름 컴퓨터(Control Flow Computer)"라고 한다. 제어 흐름 컴퓨터는 하나의 프로그램 카운터로 명령어가 순차적으로 수행된다. 수행 속도가 느리다는 단점을 극복하고자 내재된 병렬성을 극대화 시키려 하는 시도가 계속 발생되었고, 데이터 흐름 컴퓨터는 그 중의 한 예이다.

데이터 흐름 컴퓨터는 프로그램 내의 모든 명령어를 수행에 필요한 피연산자들이 모두 준비되었을 때, 프로그램에 나타나는 명령어의 순서와 무관하게 수행시킨다.(데이터 추진 방식) 이렇게 명령어들이 수행되면 그 결과는 결과를 필요로 하는 명령어들에 보내진다.

데이터 추진 방식에서는 프로그램 카운터가 필요하지 않고, 명령어 수행 시작은 명령어 출현 시기와 무관하며, 단지 "피연산자들이 준비되었는가"에 의 달려있는 것이다. 이는 이론적으로 최대의 병렬성을 얻을 수 있으며, 이용 가능한 하드웨어 자원의 양에만 제한을 받을 뿐이다.

VLSI 처리기 (Very Large Scale Integration)

VLSI 기술, 초규모 직접 회로 설계 기술이 발전함에 따라 병렬 알고리즘을 직접 하드웨어로 구현하는 VLSI 처리기가 등장하게 되었다. VLSI 처리기는 파이프라인 기법을 이용한 다중처리 기법을 사용하며, 규칙적인 단위인 "셀(Cell)" 등의 연결망으로 이루어져 있다.

상호연결망 구조

병렬처리 시스템은 하나의 문제를 해결하기 위해 여러 개의 처리요소가 동작하기에, 각각의 처리요소 사이 통신 가능한 경로가 필요하다. 이때, 처리요소와 기억장치를 연결하는 네트워크를 "상호연결망(Interconnection Network)"이라고 한다. 현재 개발된 상호연결망은 여러 종류가 있는데, 크게 "정적 상호연결망"과 "동적 상호연결망"으로 구분된다.

정적 상호연결망

정적 상호연결망은 직접 연결된 경로를 사용하고, 한 번 마련된 경로는 변경 불가능하다. 따라서 정적 상호연결망은 통신 유형이 예측 가능한 상황에 적합하다. 정적 상호연결망의 종류는 다음과 같다.

`성형 구조`: 허브(hub)라는 특별한 노드와 연결되는 연결도 1의 노드로 구성된다. 허브 충돌에 대한 위험 때문에 10여 개의 노드로 제한한다.
`완전상호연결 구조`: 각 처리기와 각 기억장치모듈 사이에 가능한 연결이 모두 존재한다. 노드를 추가하는 비용이 비싸다.
`선형 구조`: 이용 가능한 가장 단순한 구조로, 모든 노드가 연결도를 가지기에 노드를 추가하는 비용은 고정되지만 통신 시간은 노드 사이 거리에 비례하며 결함 노드 발생 시, 결함 노드로 인해 분리되는 모든 노드 사이 통신이 마비된다.
`링 구조`: 양 끝이 연결된 선형 노드로, 선형 구조와 같이 노드 추가 비용은 고정된다. 결함 노드 발생 시, 메세지는 반대 방향으로 가서 결함 노드를 피할 수 있다.
`트리 구조`: 완전 트리 형태를 가지며, 각 지역 그룹에서 프로세서들이 하나의 기억장치로 강결합되는 형태를 가진다. 노드의 연결도는 일정하게 유지하며 확장 가능하지만, 통신 거리는 상대적으로 길다.
`메시 구조`: 노드들이 2차원 망의 교차점에 배치된 형태로, 2개의 노드가 상하좌우로 근접하며 서로 연결된다.
`토러스 구조`: 메시 구조에서 상하 끝과 좌우 끝을 서로 연결해 대칭성을 부여하여 평균 통신 거리를 줄인다.
`하이퍼큐브 구조`: 기하학적으로 $n$차원 공간에서 정의되는 큐브의 $2^n$개의 꼭짓점에 노드를 가진 구조이다. 아주 좋은 효율을 가지고, 높은 확장성을 가진 구조이다. 또한 모든 노드가 동등하기에 같은 경로 배정 방식을 사용할 수 있다.

동적 상호연결망

동적 상호연결망은 가능한 모든 유형의 통신이 가능하기에 범용적인 시스템 구축에 적합하다. 다만, 동적인 연결을 위해 경로 뿐만 아니라 스위칭 모듈이나 중계기가 필요하다.

`버스 구조`: 사용되는 처리기 수가 적을 때, 좋은 성능을 발휘한다. 비용이 저렴하기에 작은 규모의 다중처리기 시스템에 적합하며 트리 구조의 시스템에 지역적인 기반으로 이용 가능하다. 다만, 버스 사이클 당 하나의 연결만을 제공한다.
`다중 버스 구조`: 여러 개의 버스를 가지는 구조로, 여러 개의 장치가 다른 여러 개의 장치와 동시에 통신 가능하기에 고성능 시스템에 이용된다.
`크로스바 구조`: $P \times M$ 크로스바는 $P$개의 처리기와 $M$개의 기억장치 모듈과 동시에 연결 가능하다. 이때, 기억장치 모듈의 개수가 정확히 $M$개라면, 완전 크로스바가 된다. 완전 크로스바는 스위치의 수가 "처리기의 수와 기억장치의 수의 곱"으로 증가하기에 규모가 커지면 매우 비싸지지만, 지역적 기반구조로는 매우 유용하다.
`다단계 네트워크 구조`: 근원지와 목적지 사이에 여러 개의 스위치 요소가 있는 상호연결망으로, 많은 연결이 필요하고 처리기의 수가 많을 때 이용된다. 연결망은 여러 단계로 구성되며 인접한 두 단계는 "순열(Permutation)" 연결을 이루게 된다.