DB·테스트·시스템공학 답안

DB·테스트·시스템공학 답안 — 세트 C

DB 인덱스 · 인덱스 스캔 · 암스트롱 공리 · 옵티마이저(DB) · 옵티마이저(AI) · 백투백 테스트 · 성능 테스트 · SW 안전성 분석 · SIL · HIL · HW 규모산정 | 정보관리 대비

데이터베이스 인덱스 (DB Index)

검색 성능 향상 자료구조 · B+Tree·Hash·Bitmap · 클러스터드/논클러스터드

개념

정의: 테이블의 특정 컬럼 값을 기준으로 데이터 위치(ROWID/RID)를 미리 정렬·저장하여 조회 성능을 향상시키는 자료구조. 책의 색인(Index)과 동일한 원리

트레이드오프: 조회(SELECT) 속도↑ ↔ DML(INSERT·UPDATE·DELETE) 성능↓·저장 공간 추가 소요. 인덱스는 많을수록 좋지 않음

개념도 — 인덱스 종류 분류

구조별 인덱스

B+Tree
범위탐색·등치
대부분 RDBMS

Hash
등치탐색만
메모리 DB

Bitmap
저카디널리티
DW·분석용

클러스터링별 인덱스

Clustered: 인덱스 순서 = 실제 데이터 저장 순서. 테이블당 1개. InnoDB PK

Non-Clustered: 인덱스와 데이터 순서 별개. 리프에 PK 참조. 다수 가능

주요 구성 요소 — 인덱스 설계 원칙 "선카범조복"

두문자	원칙	핵심 내용	예시
선	선택도(Selectivity)	카디널리티가 높을수록(값이 다양할수록) 인덱스 효율↑. 성별(2종류)은 부적합	주민번호·이메일 → 적합, 성별→부적합
카	카디널리티	컬럼의 고유 값 수. 높을수록 인덱스 효과 좋음. 복합 인덱스 선두 컬럼에 배치	Bitmap Index: 저카디널리티(상태코드 등)
범	범위 조건 고려	= 조건에는 Hash Index, BETWEEN·LIKE·>= 범위 조건에는 B+Tree 인덱스 필수	Hash: 등치만. B+Tree: 범위 가능
조	조합(복합) 인덱스	자주 함께 쓰이는 컬럼을 묶어 복합 인덱스 생성. 선두 컬럼 기준 정렬	(dept_id, salary) → dept_id 단독 사용 가능
복	복합 인덱스 순서	선두 컬럼 생략 시 인덱스 미사용. 등치 조건 컬럼을 앞에, 범위 조건을 뒤에	WHERE dept=? AND sal>? → (dept, sal) 순

인덱스 사용 안 되는 경우 및 Index Only Scan

인덱스 사용 안 되는 경우

묵시적 형변환: WHERE TO_CHAR(dt)='2024' → 인덱스 무력화
LIKE 앞 와일드카드: WHERE name LIKE '%홍' → Full Scan
부정 조건: WHERE status != 'Y' → 인덱스 미사용
함수 사용: WHERE UPPER(name)='KIM'

Index Only Scan & 실행계획

Index Only Scan: 인덱스만으로 쿼리 완결 → 테이블 접근 불필요
Covering Index: SELECT 컬럼을 인덱스에 모두 포함
EXPLAIN: MySQL·PostgreSQL의 실행계획 확인
인덱스 재구성: 단편화 시 REBUILD·REORGANIZE

💡 킬러 문장: "인덱스는 공짜가 아니다. 조회 속도를 높이는 대신 쓰기 성능과 저장 공간을 지불한다. '얼마나 많이 쓰느냐'가 아닌 '어디에 쓰느냐'가 인덱스 설계의 핵심이다."

데이터베이스 인덱스 스캔 방식

Index Range·Unique·Full·Skip Scan · 옵티마이저가 선택하는 스캔 전략

개념

정의: 옵티마이저가 쿼리 조건에 따라 인덱스를 어떻게 탐색할지 결정하는 방식. 조건 유형·카디널리티·데이터 분포에 따라 Range Scan·Unique Scan·Full Scan·Skip Scan 등이 선택됨

개념도 — 스캔 방식 결정 흐름

쿼리 조건 분석
등치·범위·IS NULL

→

인덱스 존재 확인
선두 컬럼 일치 여부

→

스캔 방식 선택
Range·Unique·Full

→

비용 계산
최저 비용 실행

주요 스캔 방식 — "유범전스풀"

두문자	스캔 방식	사용 조건	특징
유	Unique Index Scan	UNIQUE 인덱스에 등치(=) 조건. 반드시 1건 이하 반환	가장 효율적. 단 1개 리프 접근 후 종료
범	Index Range Scan	BETWEEN·>=·<=·LIKE 'A%' 등 범위 조건. 가장 일반적	리프 시작점 탐색 → 범위 끝까지 순차 읽기
전	Index Full Scan	인덱스 전체 순차 탐색. ORDER BY 컬럼이 인덱스와 일치 시 정렬 생략 가능	Table Full Scan보다 인덱스가 작아 유리할 때
스	Index Skip Scan	복합 인덱스에서 선두 컬럼 조건 없을 때. 선두 컬럼 값을 건너뛰며 탐색	Oracle 특화. 선두 컬럼 카디널리티 낮을 때 효과적
풀	Table Full Scan	인덱스 미존재·선택도 낮음·대량 조회. 옵티마이저가 인덱스보다 유리하다 판단 시	전체 블록 순차 읽기. 대량 조회엔 유리할 수 있음

EXPLAIN 실행계획 및 인덱스 스캔 최적화

EXPLAIN 실행계획 주요 항목

type: 스캔 방식. const(PK등치) > ref > range > index > ALL(풀스캔)
key: 실제 사용된 인덱스 이름
rows: 예상 탐색 행 수 (낮을수록 좋음)
Extra: Using index(커버링), Using filesort(정렬필요), Using temporary

인덱스 스캔 최적화 포인트

인덱스 병합: 두 인덱스를 AND/OR 조건으로 결합 (Index Merge)
정렬 제거: ORDER BY 컬럼이 인덱스 순서와 일치 → filesort 제거
힌트: USE INDEX, FORCE INDEX, IGNORE INDEX
루스 인덱스 스캔: GROUP BY 최적화 시 인덱스 일부만 탐색

💡 킬러 문장: "옵티마이저는 인덱스를 항상 쓰는 것이 아니라 '비용이 낮을 때만' 쓴다. 인덱스가 있어도 Full Scan을 선택하는 이유를 이해하는 것이 DBA의 핵심 역량이다."

암스트롱 공리 (Armstrong's Axioms)

함수적 종속성 추론 규칙 · 정규화 이론적 기반 · 완전·건전성 증명

개념

정의: 관계 데이터베이스에서 함수적 종속성(FD)의 완전한 집합을 추론하기 위한 공리 체계. William W. Armstrong이 1974년 제안. 반사·증가·이행의 3개 기본 공리 + 3개 파생 규칙

함수적 종속성 X→Y: X 값이 같으면 Y 값도 반드시 같다. X가 Y를 함수적으로 결정

개념도 — 암스트롱 공리 3+3 체계

기본 공리 (3개)

반사성(Reflexivity): Y⊆X 이면 X→Y
증가성(Augmentation): X→Y 이면 XZ→YZ
이행성(Transitivity): X→Y, Y→Z 이면 X→Z

파생 규칙 (3개)

합집합(Union): X→Y, X→Z 이면 X→YZ
분해(Decomposition): X→YZ 이면 X→Y, X→Z
가이행(Pseudotransitivity): X→Y, WY→Z 이면 WX→Z

주요 구성 요소 — "반증이합분가"

두문자	공리/규칙	형식 표현	활용 예시
반	반사성	Y⊆X → X→Y (자명한 FD)	{학번,이름}→{학번} — 항상 성립
증	증가성	X→Y → XZ→YZ (양변에 Z 추가)	학번→이름 이면 {학번,과목}→{이름,과목}
이	이행성	X→Y, Y→Z → X→Z (전이)	학번→학과, 학과→학과장 → 학번→학과장
합	합집합	X→Y, X→Z → X→YZ	학번→이름, 학번→전화 → 학번→{이름,전화}
분	분해	X→YZ → X→Y, X→Z	학번→{이름,전화} → 학번→이름, 학번→전화
가	가이행성	X→Y, WY→Z → WX→Z	학번→학과, {부서장,학과}→급여 → {부서장,학번}→급여

정규화와의 연계 및 최소 함수 종속 집합

정규화와 연계

1NF: 원자값 보장
2NF: 부분 함수 종속 제거 (X→Y에서 X의 진부분집합→Y 없어야)
3NF: 이행 함수 종속 제거 (이행성 공리 역 방향 제거)
BCNF: 모든 결정자가 후보키
암스트롱 공리: 정규화 각 단계의 이론적 근거

최소 함수 종속 집합(Minimal Cover)

정의: 동등한 FD 집합 중 가장 작은 집합
구하는 방법:
① 우변 단일화 (분해 규칙 적용)
② 중복 FD 제거
③ 좌변 중복 속성 제거
활용: 3NF 분해 알고리즘의 입력

💡 킬러 문장: "암스트롱 공리는 데이터베이스 정규화의 수학적 언어다. 이 6가지 규칙으로 모든 함수적 종속성을 빠짐없이(완전성), 틀림없이(건전성) 추론할 수 있다."

DB 옵티마이저 (Query Optimizer)

최적 실행계획 수립 · RBO vs CBO · 조인 순서·접근 경로 결정

개념

정의: SQL 쿼리를 가장 효율적으로 실행하기 위해 여러 가능한 실행 계획(Execution Plan) 중 최소 비용의 계획을 선택하는 DBMS 핵심 컴포넌트

RBO(Rule-Based Optimizer): 미리 정의된 규칙·순위 기반. 예측 가능하나 데이터 분포 무시
CBO(Cost-Based Optimizer): 통계 정보(행 수·카디널리티·히스토그램)를 기반으로 비용 추정. 현재 표준

개념도 — 옵티마이저 처리 과정

SQL 파싱
구문 분석·AST

→

논리 최적화
SQL 변환·단순화

→

통계 참조
테이블·인덱스 통계

→

비용 추정
I/O·CPU 비용

→

최적 계획
최소 비용 선택

주요 구성 요소 — "통조접조조"

두문자	요소	핵심 내용	세부 내용
통	통계 정보	행 수(cardinality)·distinct 값 수·히스토그램·페이지 수. ANALYZE TABLE로 갱신	통계 오래됨 → 잘못된 실행계획 → 통계 갱신 필수
조	조인 방식 선택	Nested Loop(소량), Hash Join(대량 등치), Sort-Merge Join(정렬된 대량 범위)	드라이빙 테이블 선택이 NL Join 성능 결정
접	접근 경로 결정	Index Range Scan vs Full Table Scan vs Index Only Scan 비용 비교	선택도×행수×I/O비용으로 계산
조	조인 순서	N개 테이블 조인 시 N! 가지 순서. 동적 프로그래밍으로 최적 순서 탐색	Bushy Tree vs Left-Deep Tree 탐색
조	조건 푸시다운	WHERE 조건을 조인 이전에 적용하여 처리 행 수 감소. Predicate Pushdown	뷰·서브쿼리에 조건 밀어 넣기

RBO vs CBO 비교 및 실행계획 튜닝

RBO vs CBO

RBO: Oracle 구형 방식. 인덱스 존재하면 무조건 사용. 규칙 15단계
CBO: 통계 기반 비용 추정. MySQL·PostgreSQL·현대 Oracle
CBO 약점: 통계 부정확·복잡한 쿼리에서 잘못된 계획
해결: SQL 힌트로 강제 지정

실행계획 분석 및 튜닝

EXPLAIN ANALYZE: 예상 vs 실제 행 수 비교
문제 패턴: Using filesort, Using temporary, Full Table Scan
해결: 인덱스 추가, 쿼리 재작성, 통계 업데이트
힌트: /*+ INDEX(t idx_name) */ NO_MERGE, HASH_JOIN

💡 킬러 문장: "DB 옵티마이저는 SQL을 실행하는 최선의 방법을 스스로 찾는 AI다. 하지만 통계가 틀리면 옵티마이저도 틀린다 — 통계 관리가 DBA의 핵심 역할인 이유다."

AI 옵티마이저 (딥러닝 최적화 알고리즘)

SGD·Adam·AdaGrad·RMSProp · 손실함수 최소화 · 학습률 스케줄링

개념

정의: 딥러닝 모델의 손실함수(Loss Function)를 최소화하는 방향으로 가중치를 반복 업데이트하는 알고리즘. 경사하강법(Gradient Descent)을 기반으로 다양한 개선 기법이 파생

기본 업데이트 규칙: θ ← θ - η·∇L(θ) (η: 학습률, ∇L: 손실 기울기)

개념도 — 옵티마이저 발전 계보

SGD
기본 경사하강
모멘텀 없음

→

Momentum SGD
관성 추가
진동 감소

→

AdaGrad
파라미터별
학습률 조정

→

Adam
모멘텀+AdaGrad
현재 표준

주요 옵티마이저 비교 — "에모알아아"

두문자	옵티마이저	핵심 원리	장단점
에	SGD (확률적)	미니배치 기울기로 업데이트. η·∇L(θ;x,y). 단순	장: 빠른 계산 / 단: 진동 심함, 민감한 학습률
모	Momentum SGD	이전 기울기 방향(관성) 유지. v←βv-η∇L, θ←θ+v	장: 진동↓, 빠른 수렴 / 단: 하이퍼파라미터↑
알	AdaGrad	파라미터별 누적 기울기 제곱으로 학습률 나눔. 자주 업데이트된 파라미터는 학습률↓	장: 희소 데이터 강함 / 단: 학습률 계속 감소→소멸
아	RMSProp	AdaGrad 개선. 지수 이동 평균으로 학습률 감소 속도 제어	장: AdaGrad 소멸 문제 해결 / 단: 전역 최솟값 보장 없음
아	Adam	Momentum + RMSProp 결합. 1차·2차 모멘트 추정. 편향 보정	장: 범용적, 빠른 수렴 / 단: 일반화 성능 SGD보다 낮을 수 있음

학습률 스케줄링 및 LLM 훈련 최적화

학습률 스케줄링

Step Decay: 일정 에폭마다 학습률 감소
Cosine Annealing: 코사인 함수로 학습률 주기적 변화. LLM 훈련 표준
Warmup: 초기에 학습률을 서서히 높임 → 불안정 방지
ReduceLROnPlateau: 검증 손실 정체 시 학습률 자동 감소

LLM 훈련 최적화

AdamW: Adam + Weight Decay 분리. GPT·BERT 표준
Gradient Clipping: 기울기 폭발 방지. max_norm 설정
Mixed Precision: FP16·BF16 훈련 → 메모리·속도 개선
LION: Meta 제안. 메모리 효율적 Adam 대안

💡 킬러 문장: "AI 옵티마이저는 산에서 가장 낮은 골짜기를 찾는 등산가다. SGD는 직진, Momentum은 관성으로 이동, Adam은 지형(기울기 이력)을 기억하며 최단 경로를 찾는다."

백투백 테스트 (Back-to-Back Testing)

두 구현의 출력 비교 · 등가 테스트 · ISO 26262·DO-178C 요구

개념

정의: 동일한 입력에 대해 두 가지 버전의 구현(모델·코드·시스템)을 동시에 실행하고 출력을 비교하여 등가성을 검증하는 테스트 기법

주요 사용 맥락:
① 모델(MIL/SIL/HIL) 간 등가성 검증 — 모델→코드 변환 오류 탐지
② 구버전 vs 신버전 회귀 테스트 — 기능 동일성 확인
③ ISO 26262 Part 6에서 SW 단위 및 통합 테스트의 권고 기법

개념도 — 백투백 테스트 구조

동일 테스트 입력

구현 A
(레퍼런스 모델 / 구버전 / SIL)

구현 B
(생성 코드 / 신버전 / HIL)

↓ 출력 비교 (Diff)

동일: 등가성 확인 → Pass

차이: 구현 오류 탐지 → Fail·조사

주요 구성 요소 — 적용 맥락 "모회코안자"

두문자	적용 맥락	핵심 내용	표준 연계
모	모델 기반 개발 (MBD)	MIL(모델in루프) vs SIL(소프트웨어in루프): 코드 자동생성 오류 탐지	ISO 26262 Part 6 권고
회	회귀 테스트	소프트웨어 변경 후 기존 기능 동일성 확인. CI/CD 파이프라인 통합	IEEE 829 테스트 문서화
코	코드 생성 검증	Simulink/Matlab에서 자동 생성된 C코드와 원본 모델 출력 비교	DO-178C(항공 SW) 요구
안	안전 무결성 검증	독립적으로 개발된 두 구현의 다양성 검증 (Diverse Software)	IEC 61508 다양성 기법
자	자동화 테스트	대량 테스트 케이스를 자동으로 양쪽 실행·비교. 부동소수점 허용 오차 설정	MATLAB Test, PolySpace

MIL-SIL-HIL 연계 및 수치 비교 고려사항

MIL-SIL-HIL 백투백 테스트 연계

MIL vs SIL: 모델 vs 생성코드. 코드 생성 오류 탐지
SIL vs HIL: PC 실행 코드 vs 타겟 HW. 컴파일러·타겟 오류 탐지
HIL vs 실차: 시뮬레이터 vs 실제 차량. 하드웨어 인터페이스 검증
단계별 누적: 각 전환 단계에서 백투백 검증 수행

수치 비교 고려사항

부동소수점 허용 오차: 플랫폼별 FP 연산 차이 → 절대/상대 오차 허용치 설정
타이밍 차이: 실시간 시스템에서 실행 순서 차이 고려
상태 초기화: 두 구현의 초기 상태 동일성 보장
커버리지: MC/DC 커버리지로 테스트 완전성 검증

💡 킬러 문장: "백투백 테스트는 '두 가지 방법으로 같은 답을 내는가'를 검증한다. 모델→코드 변환에서 발생하는 미묘한 오류가 자동차·항공기의 생명을 위협할 수 있기 때문이다."

성능 테스트 (Performance Testing)

부하·스트레스·내구·스파이크 테스트 · NFR 검증 · JMeter·Gatling

개념

정의: 소프트웨어 시스템이 특정 조건(부하·스트레스·동시 사용자 수)에서 응답 시간·처리량·자원 사용률 등 비기능적 요구사항(NFR)을 충족하는지 검증하는 테스트

핵심 지표: 응답 시간(Response Time), 처리량(Throughput: TPS), 오류율(Error Rate), 자원 사용률(CPU·메모리·I/O)

개념도 — 부하 증가에 따른 성능 곡선

정상 구간
TPS↑, 응답시간 안정

저하 구간
TPS 한계, 응답시간↑

포화 구간
오류 급증, 시스템 불안

사용자 수 → 증가

성능 테스트 유형 — "부스내스용"

두문자	유형	목적	방법
부	부하 테스트 (Load)	예상 최대 부하 하에서 성능 요구사항 충족 여부 확인	목표 TPS/동시 사용자까지 점진적 증가
스	스트레스 테스트 (Stress)	시스템 한계·파괴점 탐색. 한계 초과 시 복구 동작 확인	한계 이상 부하 지속 → 장애점·오류 패턴 관찰
내	내구 테스트 (Endurance/Soak)	장시간 정상 부하에서 메모리 누수·성능 저하 탐지	정상 부하를 12~72시간 지속 (메모리 모니터링)
스	스파이크 테스트 (Spike)	갑작스러운 부하 급증에 대한 응답 확인	정상→급증→정상으로 급격한 부하 변화
용	용량 테스트 (Capacity)	현재 인프라로 최대 지원 가능한 사용자 수·TPS 측정	점진 증가로 포화점 결정 → 규모산정 기반

성능 테스트 도구 및 병목 분석

주요 테스트 도구

Apache JMeter: 자바 기반 오픈소스. GUI·CLI 지원. HTTP·DB·MQTT
Gatling: Scala 기반. 고성능 시나리오 코드. CI/CD 통합 용이
k6: Go 기반. 코드로 시나리오 작성. InfluxDB 연동
Locust: Python 기반. 분산 부하 생성

병목 분석 (APM 연계)

CPU 병목: 알고리즘 최적화·스케일 업
메모리 누수: 힙 덤프 분석·GC 튜닝
DB 병목: 슬로우 쿼리·인덱스 누락·커넥션 풀
네트워크: 응답 크기 압축·CDN 적용
APM: Datadog·New Relic으로 트레이스 분석

💡 킬러 문장: "성능 테스트는 '얼마나 빠른가'가 아니라 '얼마나 많이, 얼마나 오래, 얼마나 안정적으로'를 검증한다. 배포 전 병목을 찾지 못하면 사용자가 찾아준다."

소프트웨어 안전성 분석 기법

FMEA·FTA·HAZOP·STPA · 위험 식별 및 완화 · ISO 26262·IEC 61508 요구

개념

정의: SW 시스템에서 발생 가능한 위험(Hazard)·고장(Failure)·결함(Fault)을 체계적으로 식별·분석·완화하는 방법론의 총칭. 안전 임계(Safety-Critical) 시스템 개발의 필수 요소

귀납적 vs 연역적: FMEA(부품→시스템 영향 분석, 귀납) vs FTA(결과→원인 분석, 연역)

주요 분석 기법 비교 — "에에하에에스"

두문자	기법	방향	핵심 절차	적용
에	FMEA	귀납 (하→상)	부품 고장 모드 열거 → 영향 분석 → RPN(심각도×발생도×탐지도) 계산 → 고위험 조치	부품 설계 초기. ISO 26262 HARA
에	FTA	연역 (상→하)	최상위 위험 사건(Top Event) 정의 → AND/OR 게이트로 원인 트리 구성 → 최소 컷셋 분석	시스템 설계 단계. IEC 61508
하	HAZOP	귀납 (팀 기반)	프로세스를 노드로 분할 → 가이드워드(High/Low/None/Reverse) × 파라미터 조합으로 편차 탐색	공정 플랜트·화학 시설. IEC 61511
에	ETA	귀납 (시나리오)	초기 사건 정의 → 안전 기능 작동/실패 분기 → 결과 시나리오별 확률 계산	초기 사건 이후 결과 분석
에스	STPA	시스템 제어	위험 분석(Hazard) → 비안전 제어 행동(UCA) 식별 → 인과 시나리오 분석 → 제어 구조 개선	SW·AI·자율주행 복잡 시스템

FMEA vs FTA 선택 기준 및 AI 안전성 분석

FMEA vs FTA 선택 기준

FMEA: 설계 초기. 부품 단위 상향식. ASIL 할당 전
FTA: 시스템 수준. 하향식. 최소 컷셋으로 최소 안전 장벽 식별
병행 사용: ISO 26262에서 FMEA+FTA 병행 권고
FMEA 한계: 복합 고장·소프트웨어 오류 분석 어려움

AI 시스템 안전성 분석

전통 FMEA 한계: AI 모델의 불확실·확률적 출력 → 고장 모드 정의 어려움
STPA for AI: AI 결정에 대한 UCA 분석. 적대적 입력 포함
MITRE ATLAS 연계: AI 공격 시나리오 → HAZOP 스타일 분석
ISO 8800: AI 도로 안전 → FMEA+STPA 복합 적용

💡 킬러 문장: "FMEA는 '무엇이 잘못될 수 있는가', FTA는 '왜 잘못됐는가'를 묻는다. 안전 분석은 사고가 나기 전에 미래를 상상하는 작업이다."

SIL (Software in the Loop)

PC에서 생성 코드 검증 · MBD 검증 단계 · 백투백 테스트 핵심

개념

정의: 모델 기반 개발(MBD)에서 타겟 HW 없이 PC 환경에서 자동 생성된 소프트웨어 코드를 실행하고 검증하는 테스트 단계. MIL(모델) → SIL(생성코드) → HIL(하드웨어) 검증 파이프라인의 핵심 단계

목적: 코드 자동 생성 도구(Simulink Coder 등) 오류, 코드 최적화 오류, OS/컴파일러 의존성 문제를 HW 없이 조기 탐지

개념도 — MIL→SIL→PIL→HIL 검증 파이프라인

MIL
Model-in-Loop
원본 모델
Simulink 실행

→

SIL
Software-in-Loop
생성 C코드
PC 실행

→

PIL
Processor-in-Loop
타겟 MCU
크로스 컴파일

→

HIL
Hardware-in-Loop
실제 HW+
플랜트 시뮬레이터

SIL 구성 요소 및 ISO 26262 연계

구성 요소	역할	도구
SUT (테스트 대상)	자동 생성된 C/C++ 코드. 타겟과 동일한 기능	Simulink Coder, Embedded Coder 생성물
테스트 하네스	입력 벡터 주입, 출력 캡처, 비교 판정	MATLAB Test, Simulink Test
백투백 비교	MIL 출력 vs SIL 출력 비교. 허용 오차 내 일치 여부 판정	Diff Tool, 부동소수점 허용오차 설정
커버리지 측정	생성 코드의 MC/DC·구문·분기 커버리지 측정	BullseyeCoverage, VectorCAST
정적 분석	생성 코드의 코딩 규칙(MISRA C) 준수, 미정의 동작 탐지	PolySpace, LDRA, PC-lint

SIL 장점·한계 및 ISO 26262 연계

ISO 26262 Part 6 요구사항

SW 유닛 테스트: SIL로 단위 테스트 수행. MC/DC 커버리지 ASIL-C/D 요구
코드 생성 검증: 생성 도구의 자격부여(Qualification) 또는 백투백 테스트
ASIL-D: 독립된 MIL·SIL 비교로 등가성 증명 필요
MISRA C: 자동차 SW 코딩 표준. SIL에서 정적 분석으로 검증

SIL 장점 및 한계

장점: HW 없이 조기 검증 → 비용 절감. 디버깅 용이. 반복 실행 자동화
한계: 타겟 HW의 타이밍·인터럽트·메모리 제약 반영 불가
해결: PIL/HIL로 HW 특성 추가 검증
비교: SIL(PC 실행) vs HIL(실제 ECU + 시뮬레이터)

💡 킬러 문장: "SIL은 '하드웨어 없이 소프트웨어를 증명하는' 방법이다. 모델→코드 변환에서 발생하는 미묘한 오류를 값비싼 하드웨어 없이 PC 위에서 잡아낸다."

C10

HIL (Hardware in the Loop)

실제 ECU + 플랜트 시뮬레이터 · 실시간 폐루프 검증 · 자동차·항공 필수

개념

정의: 실제 제어 하드웨어(ECU·MCU)를 실제 플랜트(엔진·차량·항공기) 대신 실시간 시뮬레이터와 연결하여 폐루프(Closed-Loop) 제어 소프트웨어를 검증하는 테스트 환경

폐루프 원리: ECU가 제어 출력 → 시뮬레이터가 플랜트 반응 계산 → ECU에 센서 값 피드백 → 반복. 실제 차량 없이 ECU 소프트웨어의 실시간 동작 검증

개념도 — HIL 시스템 구성

실제 하드웨어 (Device Under Test)

ECU / 제어기 / 실제 전자 제어 장치

↕ I/O 신호 (CAN·LIN·PWM·아날로그)

실시간 시뮬레이터 (HIL 플랫폼)

플랜트 모델
엔진·차량 역학

I/O 인터페이스
신호 변환·주입

결함 주입
단선·단락·노이즈

HIL vs SIL 비교 및 자동차 ADAS 적용

비교 기준	SIL	HIL
실행 환경	PC (호스트 컴퓨터)	실제 ECU + 실시간 시뮬레이터
타이밍	비실시간 (빠름)	실시간 (하드 리얼타임 요구)
HW 의존성	없음	타겟 HW 필수
탐지 가능 오류	코드 생성 오류, 기능 오류	타이밍 오류, HW 인터페이스, 인터럽트, CAN 통신
비용	낮음	높음 (dSPACE, NI HIL 장비)

자동차·ADAS에서의 HIL

ADAS 센서 시뮬레이션: 카메라·레이더·LiDAR 모델 → ECU에 가상 센서 데이터 주입
결함 주입: 센서 실패·CAN 버스 오류·전원 이상 시 ECU 반응 검증
엣지 케이스: 실제 주행으로 재현 불가한 극단 시나리오 테스트
ODD 검증: ISO 21448 SOTIF의 미지 시나리오 탐색

HIL 플랫폼 및 국내 동향

dSPACE SCALEXIO: 가장 널리 사용. 모듈식 I/O
NI VeriStand: National Instruments. FPGA 기반
Speedgoat: MATLAB/Simulink 직접 연동
국내: 현대모비스·만도·HL만도 HIL 기반 ADAS ECU 검증 체계 구축

💡 킬러 문장: "HIL은 '실제 차를 부수지 않고 ECU를 테스트하는' 방법이다. 자동차가 절벽에 떨어지는 시나리오도 HIL에서는 반복 재생 가능하다."

C11

정보시스템 하드웨어 규모산정 지침

과기정통부 고시 · TPC·SPECint 기준 · 공공 정보시스템 HW 도입 기준

개념

정의: 공공기관이 정보시스템 구축 시 필요한 서버·스토리지·네트워크 장비의 적정 규모를 산정하는 과학기술정보통신부 고시 지침. 과도 또는 과소 도입을 방지하고 예산 낭비를 막기 위한 기준

근거: 정보시스템 마스터플랜 수립 지침 + 행정안전부 정보화사업 추진 지침

개념도 — 규모산정 절차

업무 분석
트랜잭션 수
동시 사용자

→

처리 능력
TPS 요구량
피크 배수 산정

→

벤치마크
TPC-C/E
SPECint/fp

→

장비 선정
성능 기준
여유율 적용

주요 구성 요소 — 서버 규모산정 "처피여벤고"

두문자	산정 요소	핵심 내용	적용 기준
처	처리 능력(CPU 성능)	TPS(Transaction Per Second) 또는 동시 접속 사용자 수 기반 CPU 성능 요구량 산출	TPC-C: OLTP 성능. SPECint: 정수 연산
피	피크 부하 배수	평균 부하 대비 최대(피크) 부하 발생 비율. 피크 시간대 처리 능력 보장	공공: 피크 배수 3~5배 적용
여	여유율(Headroom)	미래 증가·예측 오차를 위한 여유 성능. 통상 30~40% 여유율 적용	CPU 사용률 목표: 최대 70% 이하
벤	벤치마크 기준	도입 장비의 공인 벤치마크 점수로 요구 성능 충족 여부 판단	TPC-E(OLTP), TPC-H(DW), SPEC
고	고가용성(HA) 구성	Active-Active/Active-Standby 이중화. 단일 장애점(SPOF) 제거	장애 발생 시 자동 페일오버 요구

스토리지·클라우드 전환 및 AI 규모산정

스토리지 규모산정

용량: 원천 데이터량 × 증가율 × 보관 기간 × 복제 계수
IOPS: 초당 I/O 요청 수. 랜덤 I/O는 SSD 기반
대역폭: 순차 읽기·쓰기 처리량
백업: 용량의 2~3배 백업 스토리지 산정
NAS/SAN/오브젝트: 용도별 스토리지 유형 선택

클라우드 전환·AI 규모산정

클라우드 전환: 2023 공공 클라우드 우선 정책 → On-prem 규모산정을 클라우드 사양으로 변환
vCPU·메모리: 물리 CPU 성능 → 클라우드 인스턴스 사양 매핑
AI 워크로드: GPU 필요시 GPU 인스턴스 별도 산정. SW 대가 AI 부분의 GPU 실비 원칙과 연계
클라우드 비용: TCO 비교 (On-prem vs Cloud)

💡 킬러 문장: "HW 규모산정은 '공공 세금으로 얼마나 큰 컴퓨터를 사야 하는가'를 과학적으로 결정하는 작업이다. 과도 도입은 세금 낭비, 과소 도입은 서비스 장애 — 정확한 산정이 국민 신뢰다."