정보처리기사 태그의 최신글

CS

Database

데이터베이스(Database) 데이터베이스란 무엇인가? 데이터베이스(Database)는 여러 사용자가 공동으로 사용하는 데이터의 집합이다. 단순히 데이터를 저장하는 것이 목적이 아니라, 데이터의 중복을 줄이고 데이터 간 일관성을 유지하며 여러 사용자가 동시에 안전하게 접근할 수 있도록 관리하는 것이 핵심이다. 이러한 관리를 담당하는 소프트웨어를 DBMS(Database Management System) 라고 한다. 데이터베이스 설계가 필요한 이유 현실 세계의 데이터를 그대로 저장하면 다음과 같은 문제가 발생한다. 동일한 데이터가 여러 곳에 저장됨 → 중복 발생 한 곳만 수정되어 데이터 불일치 발생 일부 데이터를 삭제했는데, 다른 데이터까지 사라짐 이러한 문제를 방지하기 위해 체계적인 설계 과정을 통해 데이터 구조를 정의해야 한다. 데이터베이스 설계 단계 데이터베이스 설계는 다음과 같은 순서로 진행된다. 요구사항 분석 → 개념 설계 → 논리 설계 → 물리 설계 3.1 요구사항 분석 사용자가 어떤 데이터를 필요로 하고, 어떤 처리가 이루어져야 하는지를 분석하는 단계이다. 어떤 정보가 필요한가? 데이터 간 관계는 무엇인가? 3.2 개념 설계 (Conceptual Design) 현실 세계를 개념적으로 모델링하는 단계이다. 엔터티(Entity) 속성(Attribute) 관계(Relationship) 를 정의하며, 주로 ER 다이어그램(ERD) 을 사용한다. 이 단계에서는 DBMS 종류나 구현 방식은 고려하지 않는다. 3.3 논리 설계 (Logical Design) 개념 설계를 바탕으로 DBMS에서 사용할 논리적 구조를 설계하는 단계이다. 테이블 정의 속성 및 키 정의 정규화 수행 즉, 정규화는 논리 설계 단계에서 수행된다. 3.4 물리 설계 (Physical Design) 논리 설계 결과를 실제 저장 장치에 맞게 구현하는 단계이다. 저장 구조 인덱스 접근 경로 성능(처리량, 응답 시간) 을 고려한다. 👉 물리 설계의 핵심은 성능 최적화이다. 키(Key)의 개념 데이터베이스에서 키는 튜플을 유일하게 식별하기 위한 속성 또는 속성의 집합이다. 주요 키 종류 슈퍼키(Super Key): 유일성은 만족하지만 최소성은 만족하지 않음 후보키(Candidate Key): 유일성과 최소성을 모두 만족 기본키(Primary Key): 후보키 중 선택된 하나 대체키(Alternate Key): 기본키로 선택되지 않은 후보키 외래키(Foreign Key): 다른 테이블의 기본키를 참조 정규화(Normalization) 정규화는 데이터의 중복을 제거하고 이상 현상을 방지하기 위한 과정이다. 정규화를 통해 다음과 같은 이상 현상을 방지할 수 있다. 삽입 이상 삭제 이상 갱신 이상 5.1 제1정규형 (1NF) 모든 속성 값은 원자값(Atomic Value) 을 가져야 한다. 즉, 하나의 속성에 여러 값이 들어가면 안 된다. 5.2 제2정규형 (2NF) 제1정규형을 만족하면서 부분 함수 종속을 제거한 상태이다. 복합 기본키의 일부에만 의존하는 속성이 존재하면 이를 분리해야 한다. 5.3 제3정규형 (3NF) 제2정규형을 만족하면서 이행 함수 종속을 제거한 상태이다. 기본키가 아닌 속성이 다른 속성을 결정하면 안 된다. 5.4 BCNF 제3정규형보다 더 엄격한 정규형으로, 모든 결정자가 후보키여야 한다. 함수 종속(Function Dependency) 속성 X의 값이 결정되면 속성 Y의 값이 항상 하나로 결정될 때, 이를 Y는 X에 함수적으로 종속된다고 하며 다음과 같이 표기한다. X → Y 관계대수와 관계해석 관계대수(Relational Algebra) 절차적 질의 언어 연산의 순서를 명시 관계 연산의 집합 관계해석(Relational Calculus) 비절차적 질의 언어 원하는 결과만 기술

2026년 02월 02일 06:31

CS

결합도, 응집도

결합도, 응집도 결합도(Coupling)란? 모듈과 모듈 사이의 의존 정도 한 모듈의 변경이 다른 모듈에 얼마나 영향을 주는지를 나타냄 낮을수록 좋다 결합도 종류 (내·공·외·제·스·자) 내용 결합도 (Content) 다른 모듈의 내부 데이터나 로직을 직접 참조/수정 공통 결합도 (Common) 여러 모듈이 공통 데이터 영역(전역 변수) 사용 외부 결합도 (External) 외부 파일, 외부 인터페이스, 외부 포맷 공유 제어 결합도 (Control) 제어 신호(flag, mode)를 전달해 동작 제어 스탬프 결합도 (Stamp) 배열, 구조체, 객체 등 자료 구조 전체 전달 자료 결합도 (Data) 필요한 데이터 값만 전달 (가장 이상적) 응집도(Cohesion)란? 모듈 내부 요소들 간의 관련성 하나의 모듈이 얼마나 하나의 목적에 집중되어 있는지 높을수록 좋다 응집도 종류 (기·순·통·절·시·논·우) 기능적 응집도 (Functional) 하나의 명확한 기능만 수행 (최고) 순차적 응집도 (Sequential) 한 기능의 출력이 다음 기능의 입력 통신적 응집도 (Communicational) 동일한 데이터를 사용하는 기능들 묶음 절차적 응집도 (Procedural) 실행 순서 때문에 묶인 기능들 시간적 응집도 (Temporal) 같은 시간대에 실행되는 기능들 (초기화, 종료) 논리적 응집도 (Logical) 논리적으로 유사한 기능들 (입출력 처리 등) 우연적 응집도 (Coincidental) 관련 없는 기능들이 묶임 (최악)

2026년 02월 02일 05:23

CS

소프트웨어 테스트

Software Test 소프트웨어 테스트란? 소프트웨어가 요구사항에 맞게 동작하는지 확인하는 과정 오류(Error) 및 결함(Bug)을 발견하기 위한 활동이며 결함이 없음을 증명하는 활동이 아님 살충제 패러독스: 동일한 테스트 케이스를 반복해서 수행하면 새로운 결함을 더 이상 발견하지 못하는 현상 파레토의 법칙: 소프트웨어 테스트에서는 전체 결함의 대부분이 소수의 모듈에 집중되어 발생 테스트의 목적 오류 및 결함 발견 소프트웨어 품질 향상 신뢰성 확보 생명주기 단계별 테스트 (V-모델 기준) | 개발 단계 | 테스트 단계 | | ------------- | ------------- | | 요구사항 분석 | 인수 테스트 | | 시스템 설계 | 시스템 테스트 | | 아키텍처 설계 | 통합 테스트 | | 모듈 설계 | 단위 테스트 | 테스트 단계별 정리 단위 테스트 (Unit Test) 대상: 함수, 클래스, 단일 모듈 수행자: 개발자 목적: 모듈 내부 로직의 정확성 검증 특징 - 내부 구조를 고려한 테스트 - 구현 직후 수행 - 화이트박스 테스트 중심 통합 테스트 (Integration Test) 대상: 여러 모듈의 결합 수행자: 개발자 또는 테스트 담당자 목적: 모듈 간 인터페이스 오류 검출 특징 - 상위·하위 모듈 연동 테스트 - 스텁(Stub)과 드라이버(Driver) 사용 시스템 테스트 (System Test) 대상: 전체 시스템 수행자: 테스트 담당자 목적: 시스템 요구사항 충족 여부 검증 특징 - 실제 환경과 유사한 조건 - 기능 테스트 + 비기능 테스트 포함 - 블랙박스 테스트 중심 인수 테스트 (Acceptance Test) 대상: 완성된 시스템 수행자: 사용자 목적: 요구사항 만족 여부 최종 확인 특징 - 사용자 관점 테스트 - 계약 기준에 따라 수행 - 블랙박스 테스트 - 알파, 베타 테스트 테스트 관점에 따른 분류 블랙박스 테스트 (Black Box Test) 특징 - 내부 구조를 고려하지 않음 - 입력과 출력만을 기준으로 테스트 - 사용자 관점 테스트 적용 단계 - 시스템 테스트 - 인수 테스트 대표 기법 - 동치 분해: 입력 값을 유효한 그룹과 무효한 그룹으로 나누어 각 그룹에서 대표 값을 선택해 테스트 - 경계값 분석: 입력 값의 최소값·최대값 등 경계 부근에서 오류가 발생하기 쉬운 점을 집중 테스트 - 원인–결과 그래프: 입력 조건(원인)과 출력 결과(결과)의 논리적 관계를 그래프로 표현하여 테스트 케이스 도출 화이트박스 테스트 (White Box Test) 특징 - 내부 구조를 고려하여 테스트 - 코드 흐름과 분기 구조 확인 - 개발자 관점 테스트 적용 단계 - 단위 테스트 대표 기법 - 기초 경로 검사: 프로그램의 제어 흐름 그래프를 기반으로 독립적인 모든 실행 경로를 최소 한 번 이상 테스트 - 제어 구조 테스트: 프로그램의 순차, 선택, 반복 구조가 올바르게 동작하는지 검사 스텁과 드라이버 스텁 (Stub) 하위 모듈을 대신하는 가짜 모듈 호출 당하는 모듈 하향식 통합 테스트에서 사용 드라이버 (Driver) 상위 모듈을 대신하는 가짜 모듈 호출 하는 모듈 상향식 통합 테스트에서 사용 테스트 커버리지 (Test Coverage) 테스트가 프로그램을 얼마나 실행했는지를 측정하는 기준 테스트의 충분성을 판단하는 지표 주요 커버리지 종류 구문 커버리지: 모든 문장이 한 번 이상 실행되었는지 분기 커버리지: 모든 조건의 참/거짓이 실행되었는지 조건 커버리지: 조건식 내 각 조건이 실행되었는지 테스트 오라클 (Test Oracle) 테스트 결과가 올바른지 판단하기 위한 기준 테스트 실행 결과를 기대 결과(Expected Result) 와 비교하여 성공 또는 실패를 판정 목적: 테스트 결과의 옳고 그름 판단 특징 - 자동 또는 수동으로 판정 가능 - 모든 테스트에는 오라클이 존재해야 테스트 수행 가능 - 오라클이 없으면 테스트 결과의 정확성 판단 불가 회귀 테스트 (Regression Test) 프로그램 수정 또는 변경 이후 기존 기능이 정상적으로 동작하는지 확인하는 테스트 목적: 수정으로 인해 발생할 수 있는 부작용(Side Effect) 검출 특징 - 기존 테스트 케이스를 재사용 - 변경된 부분 및 영향 범위 중심으로 수행 - 유지보수 단계에서 주로 수행 정적 테스트 / 동적 테스트 정적 테스트 (Static Test) 프로그램을 실행하지 않고 검토 코드 또는 문서 기반 테스트 종류 - 워크스루(Walkthrough): 개발자가 주도하며 설명하면서 검토 - 인스펙션(Inspection): 전문가가 참여하는 공식적인 검토 동적 테스트 (Dynamic Test) 프로그램을 실제로 실행하여 테스트 실행 결과를 기반으로 오류 검출 알파 테스트 / 베타 테스트 알파 테스트 개발자 환경에서 수행 사용자 참여 가능 내부 검증 목적 베타 테스트 실제 사용자 환경에서 수행 배포 전 최종 검증

2026년 01월 30일 07:22

CS

소프트웨어 생명주기

소프트웨어 개발 전반 요약 (V-모델 기준) V-model 개발 단계(왼쪽)와 테스트 단계(오른쪽)를 1:1로 대응시킨 모델 각 단계의 산출물을 대응되는 테스트 단계에서 검증 요구사항 분석 ↔ 인수 테스트 요구사항 분석 시스템이 무엇을 해야 하는지 정의 기능 요구사항 정의 비기능 요구사항 정의 (성능, 보안, 신뢰성 등) 산출물 요구사항 명세서 유스케이스 다이어그램(선택) 인수 테스트 사용자 관점에서 수행 요구사항 충족 여부 확인 시스템 설계 ↔ 시스템 테스트 시스템 설계 전체 시스템 구조 설계 서브시스템 구성 외부 인터페이스 정의 산출물 시스템 설계서 유스케이스 다이어그램 컴포넌트 다이어그램 배치 다이어그램 시스템 테스트 전체 시스템 기능 테스트 성능, 보안 등 비기능 테스트 포함 아키텍처 설계 ↔ 통합 테스트 아키텍처 설계 주요 컴포넌트 구조 설계 컴포넌트 간 상호작용 정의 데이터 흐름 정의 산출물 아키텍처 설계서 컴포넌트 다이어그램 상위 수준 시퀀스 다이어그램 통합 테스트 모듈 및 컴포넌트 간 연동 테스트 인터페이스 오류 검출 스텁과 드라이버 사용 모듈 설계 ↔ 단위 테스트 모듈 설계 클래스 내부 구조 설계 메서드와 속성 정의 알고리즘 정의 산출물 상세 클래스 다이어그램 상세 시퀀스 다이어그램 모듈 설계서 단위 테스트 함수 또는 클래스 단위 테스트 내부 구조를 고려한 테스트 개발자가 직접 수행 구현 구현 설계 내용을 기반으로 소스 코드 작성 산출물 프로그램 코드 테스트 단계 요약 | 개발 단계 | 대응 테스트 | | ------------- | ------------- | | 요구사항 분석 | 인수 테스트 | | 시스템 설계 | 시스템 테스트 | | 아키텍처 설계 | 통합 테스트 | | 모듈 설계 | 단위 테스트 |

2026년 01월 29일 06:41

CS

Diagram & UML

Diagram & UML Diagram이란? 설계 시 모두가 같은 의미로 이해하기 위해 사용하는 그림 시스템을 시각적으로 표현하는 의사소통 도구 UML이란? Diagram을 그리기 위한 객체지향 모델링 언어 Unified Modeling Language 그림 기호와 의미를 표준화한 약속 UML의 구성요소 (사관다) UML은 다음 3가지로 구성된다. ① 사물 (Things) 관계의 대상이 되는 요소 구·행·그·주 - 구조: 시스템의 개념적, 물리적 요소 표현 - 행동: 시간과 공간에 따른 요소들의 행위 표현 - 그룹: 요소들을 그룹으로 묶어서 표현 - 주해: 부가적인 설명이나 제약조건 표현 ② 관계 (Relationships) 사물과 사물 사이의 연결 방식 연·집·포·일·의·실 - 연관(—): 2개 이상의 사물이 서로 관련되어 있음 - 집합(◇—): 하나의 사물이 다른 사물에 포함되어 있는 관계 - 포함(◆—): 포함하는 사물의 변화가 포함되는 사물에게 영향 미침 - 일반화(—▷): 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현 - 의존(--→): 사물 사이에 연관이 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관 유지 - 실체화(--▷) : 사물이 할 수 있거나 해야 하는 기능 (행위, 인터페이스) 로 서로를 그룹화 할 수 있는 관계 ③ 다이어그램 (Diagram) 사물 + 관계를 그림으로 표현한 결과물 정적 다이어그램, 동적 다이어그램으로 구성 정적 다이어그램: 구조 표현 클·객·컴·배·복·패 - 클래스 (Class): 클래스 사이 관계 표현 - 객체 (Object): 인스턴스를 특정 시점의 객체와 객체사이의 관계로 표현 - 컴포넌트 (Component): 컴포넌트 간 관계 표현 - 배치 (Deployment): 물리적 요소들의 위치 - 복합체 구조 (Composite Structure): 복합 구조 가지는 경우 그 내부 구조 표현 - 패키지 (Package): 모델 요소들을 그룹화한 패키지들의 관계 동적 다이어그램: 동작/순서 표현 유·시·커·상·활·호·타 - 유스케이스 (Use Case): 사용자의 요구 분석, 액터, 유스케이스로 구성 - 시퀀스 (Sequence): 시스템, 객체들이 주고받는 메시지 - 커뮤니케이션 (Communication): 메시지 뿐만이 아니라 객체들 관의 연관까지 표현 - 상태 (State): 객체의 상태가 어떻게 변하는지 표현 - 활동 (Activity): 시스템이 어떤 기능을 수행하는지 - 상호작용 개요 (Interaction Overview): 상호작용 다이어그램 간의 제어흐름 표현 - 타이밍 (Timing): 객체 상태 변화, 시간 제약을 명시적으로 표현 ※ Use Case 다이어그램 전용 관계 연관 (Association): 액터 ↔ 유스케이스 연결 포함 (Include): 항상 수행되는 공통 기능 확장 (Extend): 조건부로 수행되는 기능 일반화 (Generalization): 액터 또는 유스케이스 간 상속 관계

2026년 01월 29일 06:08