정보관리기술사의 노트

가상 메모리와 파이프라인 — 캐시 쓰기 정책·페이지 교체·Belady·해저드·RISC

정보관리기술사의 노트 — Tue, 21 Jul 2026 21:51:41 +0900

가상 메모리와 파이프라인 — 캐시 쓰기 정책·페이지 교체·Belady·해저드·RISC

캐시·가상 메모리의 교체 알고리즘과 파이프라인의 해저드 해결은 컴퓨터시스템응용기술사·정보관리기술사 시험의 단골 토픽이다. 전편이 메모리의 '공간'(주소 변환·사상·일관성)을 다뤘다면, 이번 글은 '정책과 시간'이다 — 언제 쓰고, 누구를 내보내고, 어떻게 겹쳐 돌릴 것인가.

관통하는 원리 하나 — 기다리지 않게 하라. 쓰기 정책은 메모리를 기다리지 않게, 교체 알고리즘은 디스크를 기다리지 않게, 파이프라인은 이전 명령을 기다리지 않게 만드는 기술이다.

1. 메모리 계층 동기화 — 캐시 쓰기 정책과 TLB

가. 캐시 쓰기 정책

Write Through vs Write Back

구분	Write Through	Write Back
메모리 반영	쓰기마다 즉시	캐시 축출 시에만 (Dirty 비트)
장점	일관성 단순 (캐시=메모리 일치)	쓰기 트래픽 최소 — 성능 우수
단점	버스 트래픽 증가	불일치 구간 존재 — 일관성 복잡
보완	Write Buffer	MESI 프로토콜

핵심 연결고리: Write Back의 성능을 얻는 대가가 MESI다. 캐시와 메모리가 다른 순간이 생기니, 다중 코어가 그 '다름'을 관리할 프로토콜이 필요해진 것이다. Dirty 비트("수정됐지만 아직 안 쓴 블록"의 표식)가 시험 함정 포인트다.

나. TLB (Translation Look-aside Buffer)

가상→물리 주소 변환 시 페이지 테이블(메모리 상주)을 매번 거치면 접근이 2배가 된다. MMU 내부의 고속 변환 캐시인 TLB가 이를 단축한다 — 참조 국소성 덕분에 작은 TLB로도 높은 적중률이 나온다. 상세 변환 흐름은 전편에서 다뤘다.

2. 가상 메모리 관리 — 정책과 교체 알고리즘

가. 관리 정책 4대 축 — 할·배·인·교

할당(얼마나 줄까) · 배치(어디에 둘까) · 인출(언제 가져올까) · 교체(누구를 내보낼까).

배치 전략은 최·최·다·최 — 최초(First Fit)·최적(Best Fit)·다음(Next Fit)·최악(Worst Fit) 적합. (단편화와 Buddy·Slab에 의한 해결은 전편 참조.)

나. 페이지 교체 알고리즘 — 무·피·후·루·루·옵·누

무작위(Random) · FIFO · LFU(최저 빈도) · LRU(최근 미사용) · MRU · OPT(최적, 이론상 기준) · NUR(최근 미사용 근사).

다. Belady's Anomaly — FIFO만의 병

Belady — FIFO만의 병, LRU는 면역

상식적으로 프레임(메모리)을 늘리면 페이지 부재는 줄어야 한다. 그런데 FIFO에서는 프레임을 늘렸는데 부재가 오히려 증가하는 역전이 발생할 수 있다 — 이것이 Belady's Anomaly다.

시험 포인트는 대비다: LRU·OPT는 스택 알고리즘이라 이 현상이 발생하지 않는다. "프레임 n개의 내용이 항상 n+1개의 부분집합"이라는 성질(포함 성질)이 보장되기 때문이다. "FIFO만의 병"으로 기억하면 된다.

3. 프로세서 병렬화 — 파이프라인과 RISC

파이프라인 중첩과 구·데·제 해저드

가. 파이프라인 중첩

명령어 처리를 단계로 나눠(표준 5단계: IF-ID-EX-MEM-WB, 교재에 따라 4단계 FiDEB) 여러 명령을 겹쳐 처리한다. 이상적으로는 매 클록마다 명령 하나가 완료되는 효과를 낸다.

나. 3대 해저드 — 구·데·제

해저드	원인	해법
구조적	하드웨어 자원 충돌	하버드 아키텍처(명령·데이터 메모리 분리), 자원 추가
데이터	앞 명령 결과 미완료	전·재·컴: 포워딩(전송) · 명령 재배치 · 컴파일러 nop
제어	분기로 인한 흐름 변화	분지·분예: 분기 지연 · 분기 예측

다. RISC — 단·파·고·효

단순 명령 · 파이프라인 최적화 · 고속 · 효율적 설계. RISC의 존재 이유는 파이프라인이다 — 명령어가 단순·균일해야 단계가 균등하게 쪼개져 파이프라인이 막힘 없이 돈다. 현대 고성능 프로세서(ARM 계열 등)의 근간이다.

4. 기술사적 제언 — 고성능 컴퓨팅의 최적화 방향

첫째, 메모리 벽과 데이터 중심 설계. CPU 대비 메모리 속도가 못 따라가는 병목을 캐시 적중률 최적화로 버텨왔지만, 근본 해법으로 데이터가 있는 곳에서 연산하는 PIM이 부상하고 있다 — 전편 제언의 연장선이다.

둘째, 분기 예측의 AI화. 제어 해저드를 줄이는 분기 예측은 이제 퍼셉트론·심층학습 기반 예측기가 도입되어 정확도 99% 이상을 노리는 추세다. 흥미로운 반전 — AI 연산을 빠르게 하려고 만든 CPU가, 그 CPU를 빠르게 하려고 AI를 쓴다.

셋째, 이종 아키텍처의 일관성. RISC 기반 CPU + 병렬 특화 GPU + AI 전용 NPU가 한 시스템에서 협업하는 시대다. 관건은 이들 사이의 캐시 일관성(Coherence) 유지이며, 전편에서 다룬 CXL이 바로 그 답으로 표준화되고 있다 — MESI(칩 안) → CXL(장치 간)로 일관성 문제의 스케일이 확장되는 흐름이다.

종합하면, 이 글의 세 주제는 모두 "기다림의 제거"라는 한 문제의 세 층위다. 쓰기는 버퍼와 지연으로, 교체는 예측(LRU)으로, 파이프라인은 중첩과 예측으로 — 그리고 그 모든 예측이 지금 AI로 정교해지고 있다.

마치며 — 핵심 요약

쓰기 정책은 성능(Back)과 일관성(Through)의 저울이고, 교체 알고리즘은 LRU가 실용 표준이며(Belady는 FIFO만의 병), 파이프라인은 구·데·제 해저드를 하버드·포워딩·예측으로 넘는다. RISC는 이 모든 것을 위한 명령어 설계다.

기술사 핵심 암기 포인트

쓰기 정책: Through(즉시·단순) vs Back(지연·Dirty 비트·MESI 필요)
관리 정책: 할·배·인·교 / 배치: 최·최·다·최 (First·Best·Next·Worst)
교체: 무·피·후·루·루·옵·누 / Belady = FIFO만, LRU·OPT는 스택 알고리즘이라 면역
파이프라인: IF-ID-EX-MEM-WB / 해저드 구·데·제 / 데이터 해법 전·재·컴 / 제어 해법 분지·분예
RISC: 단·파·고·효 — 파이프라인을 위한 명령어 단순화
답안 키워드: Dirty Bit, Write Buffer, 스택 알고리즘, 포워딩, 분기 예측, Memory Wall, PIM, CXL
실무 연결: 분기 예측의 AI화, CPU·GPU·NPU 이종 일관성 = CXL

예상 문제

(10점) 캐시 쓰기 정책 Write Through와 Write Back을 비교하고, Write Back에서 일관성 프로토콜이 필요한 이유를 설명하시오.
(25점) 파이프라인 해저드 3가지의 원인과 해결 기법을 설명하고, RISC 구조가 파이프라인 효율에 기여하는 원리를 논하시오.

주소 변환(MMU·TLB)·캐시 사상·MESI·Buddy/Slab 등 메모리의 '공간' 편은 메모리 관리와 캐시 아키텍처에서 다룬다 — 이 글은 그 후속편이다.

HW 성능 지표와 규모 산정은 오픈소스 라이선스와 SW·HW 규모 산정에서 이어서 볼 수 있다.

더 다뤘으면 하는 주제는 댓글로 남겨주세요.

차세대 소프트웨어 테스트 기법 — 메타모픽·변이 테스팅·퍼징·카오스 엔지니어링

정보관리기술사의 노트 — Fri, 17 Jul 2026 17:43:24 +0900

차세대 소프트웨어 테스트 기법 — 메타모픽·변이 테스팅·퍼징·카오스 엔지니어링

동등분할·커버리지 같은 전통 기법이 "요구한 대로 동작하는가"를 물었다면, 차세대 테스트는 "예상 못 한 상황에서도 버티는가"를 묻는다. 정답(오라클)이 없는 AI 시스템, 장애가 일상인 분산 환경에서는 테스트의 질문 자체가 바뀌어야 한다. 정보관리기술사·컴퓨터시스템응용기술사 시험에서 변별력을 만드는 차세대 기법 5가지를 정리한다.

전통 vs 차세대 — 기능에서 강건성으로

구분	전통적 테스트 (Legacy)	차세대 테스트 (Next-Gen)
중점	기능 구현 여부 (Success/Fail)	시스템의 강건성·비기능적 가치
오라클	명확한 기대 결과값 존재	결과 간 관계(MR)·생존율·복구력
수행 시점	개발 후반부 위주	전 주기 + 운영 환경(Chaos)
주요 기법	동등분할, 커버리지 측정	변이·퍼징·카오스·메타모픽·AI 윤리 검증

1. 메타모픽 테스팅 — 정답이 없을 때의 검증

AI 시스템은 입력에 대한 정답이 하나로 정해지지 않는다(Oracle Problem). 메타모픽 테스팅은 정답 비교 대신 입출력 간의 관계(Metamorphic Relation)를 검증한다.

예: 이미지를 회전시켜도 분류 결과는 같아야 한다, 검색어 조건을 좁히면 결과 수는 줄거나 같아야 한다. 개별 답이 맞는지는 몰라도, 관계가 깨지면 결함이다. AI 품질 보증의 사실상 표준 접근으로 자리 잡았다.

2. 변이 테스팅 — 테스트를 테스트한다

변이 테스팅 프로세스와 Mutation Score

발상을 뒤집은 기법이다 — 코드가 아니라 테스트 스위트의 품질을 검증한다.

절차: 원본 코드에 의도적으로 작은 결함(뮤턴트: > → >= 같은 변이)을 심고, 기존 테스트를 돌린다. 테스트가 실패하면 뮤턴트를 "죽인" 것(좋은 테스트), 전부 통과하면 뮤턴트가 "생존"한 것(테스트에 구멍이 있다는 증거)이다.

Mutation Score = 죽인 뮤턴트 ÷ (전체 뮤턴트 − 동등 뮤턴트)

시험 포인트 두 가지: ① 원본과 동작이 같아 어떤 테스트로도 못 죽이는 동등 뮤턴트는 분모에서 제외한다. ② 커버리지 100%여도 Mutation Score는 낮을 수 있다 — 실행만 하고 검증(assert)하지 않는 테스트를 걸러내는 것이 이 기법의 존재 이유다.

3. 퍼징 (Fuzzing) — 무작위로 두드려 깨뜨린다

대량의 무작위·변형 입력을 퍼부어 크래시·메모리 오류·보안 취약점을 찾는 기법이다. 단순 무작위(Dumb)에서 출발해, 커버리지 피드백으로 입력을 진화시키는 커버리지 기반 퍼징(AFL 계열)이 주류가 됐다. OSS 공급망 보안 심사와 시큐어 코딩 검증의 핵심 도구로, 사람이 생각 못 한 경계 밖 입력을 기계적으로 탐색한다는 점이 가치다.

4. 카오스 엔지니어링 — 실운영에서 무너뜨려 본다

카오스 실험 루프 — Blast Radius 최소화

Netflix의 Chaos Monkey에서 출발한, 가장 급진적인 기법이다. 테스트 환경이 아니라 실운영 환경에 일부러 장애를 주입해 복구력(Resilience)을 검증한다.

실험 루프 4단계: ① 정상 상태(Steady State) 정의 → ② 가설 수립("서버 하나가 죽어도 정상 유지될 것") → ③ 장애 주입(인스턴스 종료·네트워크 지연·자원 고갈) → ④ 검증·학습. 대전제는 폭발 반경(Blast Radius) 최소화 — 작은 범위에서 시작해 신뢰가 쌓이는 만큼 확대한다.

MSA처럼 장애가 '예외'가 아니라 '상수'인 환경에서, 복구력은 문서가 아니라 실험으로만 증명된다는 것이 이 기법의 철학이다.

5. AI 윤리·신뢰성 검증 — 기능 밖의 품질

AI 시스템은 정확도만으로 부족하다. 편향(Bias) 측정, 적대적 입력(Adversarial) 강건성, 설명가능성 확인이 테스트 항목으로 들어온다. 메타모픽 관계를 공정성 검증에 쓰는 식으로(성별만 바꾼 입력에 결과가 달라지면 결함) 앞의 기법들과 결합된다.

6. 기술사적 제언

첫째, 답안 서술의 정석 문장. "전통적인 V-모델 기반 테스트는 기능적 결함 탐지에는 효과적이나, 복잡한 분산 환경과 AI 시스템의 불확실성을 통제하기엔 한계가 있음. 따라서 Chaos Engineering을 통한 복구력 검증과 Metamorphic Testing을 통한 오라클 문제 해결이 병행되어야 함" — 이런 한계→보완 구조로 서술하면 전문성이 드러난다.

둘째, 다섯 기법의 공통 본질은 '오라클의 대체'다. 메타모픽은 관계로, 변이는 생존율로, 퍼징은 크래시로, 카오스는 정상 상태 유지로 — 모두 "기대 결과값"이라는 전통 오라클을 다른 판정 기준으로 바꾼 것이다. 이 관통 구조로 묶으면 나열형 답안과 차별화된다.

셋째, 금융권 적용의 순서. 규제 환경에서는 실운영 카오스가 부담스럽다. 현실적 도입 순서는 변이(CI 파이프라인 내) → 퍼징(대외 인터페이스) → 카오스(재해복구 훈련과 결합한 제한적 실험)이며, DR 훈련을 카오스 실험으로 진화시키는 접근이 규제와 혁신의 접점이 된다.

마치며 — 핵심 요약

차세대 테스트는 정답 비교에서 불확실성 통제로의 전환이다. 메타모픽은 관계를, 변이는 테스트 자신을, 퍼징은 경계 밖을, 카오스는 실운영을, AI 윤리 검증은 기능 밖의 가치를 본다.

기술사 핵심 암기 포인트

오라클 대체 구조: 메타모픽=MR / 변이=Mutation Score / 퍼징=크래시 / 카오스=정상 상태
Mutation Score = 죽인 뮤턴트 ÷ (전체 − 동등 뮤턴트), 커버리지 100% ≠ 좋은 테스트
카오스 4단계: 정상 상태 → 가설 → 장애 주입 → 검증 (Blast Radius 최소화)
답안 키워드: Oracle Problem, MR, Equivalent Mutant, AFL, Chaos Monkey, Steady State, Resilience
실무 연결: 변이는 CI 내재화, 퍼징은 보안 심사, 카오스는 DR 훈련과 결합

예상 문제

(10점) 메타모픽 테스팅이 해결하는 오라클 문제를 설명하고 메타모픽 관계(MR)의 예를 드시오.
(25점) 변이 테스팅과 카오스 엔지니어링의 절차를 설명하고, 전통적 테스트 대비 검증 관점의 차이를 논하시오.

7대 원리·V모델·커버리지 등 테스트의 기본기는 소프트웨어 테스트 핵심 정리에서 다룬다 — 이 글은 그 심화편이다.

메타모픽·AI 품질의 출제 맥락은 AI 소프트웨어 공학 예상문제 10선에서 이어서 볼 수 있다.

더 다뤘으면 하는 주제는 댓글로 남겨주세요.

메모리 관리와 캐시 아키텍처 — MMU·인터리빙·Buddy·Slab·MESI·캐시 사상

정보관리기술사의 노트 — Fri, 17 Jul 2026 17:34:28 +0900

메모리 관리와 캐시 아키텍처 — MMU·인터리빙·Buddy·Slab·MESI·캐시 사상

메모리 관리와 캐시 아키텍처는 컴퓨터 시스템의 '속도 차이 극복'과 '자원 효율화'를 관통하는 핵심 기술이다. 컴퓨터시스템응용기술사·정보관리기술사 시험에서 MMU 주소 변환, 캐시 사상 기법, MESI 프로토콜은 컴퓨터 구조 영역의 최다 빈출 주제다. 관리부터 일관성, 그리고 PIM·CXL이라는 미래까지 한 번에 정리한다.

관통하는 문제의식 하나 — CPU는 빠르고 메모리는 느리다. 이 속도 격차(Memory Wall)를 메우기 위한 장치가 캐시·MMU·인터리빙이고, 다중 코어 시대에는 여기에 '일관성'이라는 숙제가 더해졌다.

1. 메모리 관리와 성능 최적화 — MMU와 인터리빙

가. MMU (Memory Management Unit)

MMU 주소 변환 — TLB→테이블 워크→프레임

가상 주소(Logical)를 물리 주소(Physical)로 변환하는 핵심 장치다. 논리 공간의 페이지(Page)를 물리 공간의 페이지 프레임(Frame)에 대응시키며, 매핑 정보는 페이지 테이블이 갖는다. 테이블의 시작 주소는 페이지 테이블 베이스 레지스터(ARM은 TTB, x86은 CR3)가 가리킨다.

변환 순서가 시험 포인트다: TLB 조회(변환 캐시) → Miss 시 페이지 테이블 워크 → 페이지 부재 시 페이지 폴트 → 디스크 적재. TLB 적중률이 곧 성능이고, 그 적중률을 높여주는 것이 참조 국소성이다.

나. 메모리 인터리빙 (Interleaving)

메모리 모듈을 여러 개로 나눠 병렬 접근함으로써 대역폭을 확장한다.

방식	모듈 선택 비트	특징
상위 인터리빙	주소 상위 비트	모듈 중심 — 확장 용이, 병렬성 낮음
하위 인터리빙	주소 하위 비트	주소 중심 — 연속 데이터 접근 시 성능 극대화

연속된 주소가 서로 다른 모듈에 분산되는 하위 인터리빙이 순차 접근 병렬화의 핵심이다.

2. 메모리 자원 효율화 — 단편화, Buddy, Slab

가. 단편화 (Fragmentation)

외부 단편화: 가변 분할(세그먼테이션)에서 발생 — 빈 공간 총합은 충분한데 조각나서 못 씀
내부 단편화: 고정 분할(페이징)에서 발생 — 할당 단위 안의 남는 공간

나. Buddy와 Slab — 상호 보완의 한 쌍

버디 메모리(Buddy)는 블록을 2의 승수 단위로 분할·병합해 외부 단편화를 방지한다. 인접한 빈 '버디' 블록끼리 합쳐 큰 블록을 복원하는 게 핵심이다.

그런데 함정이 하나 있다 — 버디는 내부 단편화를 유발한다. 65KB를 요청하면 2의 승수 반올림으로 128KB를 할당하기 때문이다. 이 약점을 보완하는 것이 슬랩 할당자(Slab)다. 커널의 작은 객체들을 위해 미리 캐시(Cache → Slab → Object 구조)를 만들어 두고 재사용해, 소형 할당의 내부 단편화를 최소화한다.

리눅스가 실제로 이 구조다 — 페이지 단위 큰 할당은 Buddy, 커널 소형 객체는 그 위의 Slab. 두 기법은 경쟁이 아니라 계층 분담 관계라는 것이 답안의 차별화 포인트다.

3. 캐시 메모리와 일관성 — 국소성, Snoopy, MESI

가. 참조 국소성 (Locality)

시간적 국소성: 방금 쓴 것을 또 쓴다 (루프 변수)
공간적 국소성: 옆에 있는 것을 또 쓴다 (배열 순회)

캐시가 작아도 효과적인 이유이자, TLB·프리페치까지 관통하는 원리다.

나. 캐시 일관성 (Coherence)

다중 코어가 같은 데이터를 각자 캐시에 두면 정합성 문제가 생긴다. 유지 방식은 두 갈래다.

방식	원리	적합 환경
Snoopy	공유 버스를 감시해 갱신·무효화	소규모 (버스 기반)
Directory	중앙 디렉토리가 공유 상태 관리	대규모 (NUMA)

Snoopy 계열의 대표가 MESI 프로토콜이다. 캐시 블록을 4가지 상태로 관리한다.

상태	의미
Modified	나만 보유 + 메모리와 다름 (쓰기 반영 책임)
Exclusive	나만 보유 + 메모리와 일치
Shared	여러 캐시가 보유 + 일치
Invalid	유효하지 않음

전이의 핵심 두 가지: E→M은 버스 신호 없이 조용히(나만 갖고 있으니), S→I는 무효화 신호로 시끄럽게(남이 쓰면 내 것은 폐기). 이 차이가 Exclusive 상태의 존재 이유다.

4. 캐시 사상 기법 (Mapping)

캐시 사상 3기법

기법	주소 형식	특징
직접 사상 (Direct)	Tag + Line + Word	간단·빠름, 충돌 미스(Conflict Miss) 빈번
완전 연관 (Associative)	Tag + Word	어디든 적재, 적중률 높으나 검색 부담
집합 연관 (Set-Associative)	Tag + Set + Word	절충형 — 현대 CPU 표준

암기 팁은 주소 형식의 가운데 필드다 — Line(직접) / 없음(완전연관) / Set(집합연관). 그리고 시험 함정 하나: 교체 정책(LRU 등)은 연관 계열에서만 필요하다. 직접 사상은 자리가 고정이라 교체를 '선택'할 여지가 없다.

5. 기술사적 제언 — 메모리 계층의 미래

첫째, PIM(Processing In Memory)의 부상. AI 연산의 병목은 연산이 아니라 데이터 이동이다. 메모리 내부에서 직접 연산을 수행해 이동 자체를 없애는 PIM이 필수 논의가 됐다 — "메모리 벽을 넘는 게 아니라 벽 안으로 들어간다"는 발상 전환이다.

둘째, CXL(Compute Express Link). CPU·GPU·메모리 간 일관성을 하드웨어 레벨에서 보장하며 메모리 풀링을 가능케 하는 인터페이스다. 흥미로운 연결 — 3장의 MESI가 '한 칩 안의 코어들' 일관성이라면, CXL은 그 일관성 문제를 '장치와 서버 사이'로 확장한 것이다. 같은 문제의식이 스케일만 커졌다.

셋째, 보안 관점의 캐시. 캐시 타이밍을 이용한 부채널 공격(Spectre·Meltdown 계열)이 실증된 이후, 캐시 격리와 일관성 정책의 보안 강화가 새 축이 됐다. 답안 3단락에 "성능 장치였던 캐시가 공격 표면이 됐다"는 관점을 넣으면 차별화된다.

종합하면, 메모리 아키텍처의 역사는 속도 격차(캐시·인터리빙) → 공간 효율(Buddy·Slab) → 다중 코어 일관성(MESI) → 이동 최소화(PIM·CXL)로 문제를 옮겨온 여정이며, 각 단계의 해법이 다음 단계의 전제가 된다.

마치며 — 핵심 요약

MMU가 주소를 변환하고, 인터리빙이 대역폭을 넓히고, Buddy·Slab이 공간을 아끼고, MESI가 코어들의 진실을 하나로 맞춘다. 그리고 PIM·CXL이 이 계층 구조 자체를 다시 쓰고 있다.

기술사 핵심 암기 포인트

MMU 변환 순서: TLB → 페이지 테이블 워크 → 페이지 폴트 (베이스: TTB/CR3)
인터리빙: 상위=모듈 중심·확장, 하위=주소 중심·연속 접근 병렬화
단편화: 외부=가변분할, 내부=고정분할 / Buddy=외부 해결+내부 유발 → Slab이 보완
Slab 구조: Cache → Slab → Object
일관성: Snoopy(버스 감시·소규모) vs Directory(중앙·NUMA) / MESI 4상태
사상 기법: 가운데 필드 = Line / 없음 / Set — 교체 정책은 연관 계열만
답안 키워드: Memory Wall, TLB, Conflict Miss, LRU, 무효화 신호, PIM, CXL, 부채널 공격
실무 연결: AI 인프라의 병목은 데이터 이동 — PIM·CXL·메모리 풀링이 해법 축

예상 문제

(10점) 캐시 사상 3기법을 주소 형식 관점에서 비교 설명하시오.
(25점) 다중 코어 환경의 캐시 일관성 문제를 설명하고, MESI 프로토콜의 상태 전이와 Snoopy·Directory 방식을 비교 논하시오.

HW 규모 산정과 메모리·성능 지표(tpmC·IOPS)는 오픈소스 라이선스와 SW·HW 규모 산정에서 다룬다.

AI 인프라 관점의 데이터 계층 구조는 AI Agent가 읽는 데이터 레이크 5계층에서 이어서 볼 수 있다.

더 다뤘으면 하는 주제는 댓글로 남겨주세요.

2026 소프트웨어공학 출제 예상 Top 10 — SBOM·Saga·STPA·Error Budget·MC/DC

정보관리기술사의 노트 — Tue, 14 Jul 2026 10:35:36 +0900

2026 소프트웨어공학 출제 예상 Top 10 — SBOM·Saga·STPA·Error Budget·MC/DC

2026년 현재 정보관리기술사·컴퓨터시스템응용기술사 시험은 단순 이론 암기를 넘어 AI와의 협업, 공급망 보안, 클라우드 네이티브의 성숙도를 묻는 문제가 주를 이룬다. 소프트웨어공학 103개 토픽을 바탕으로 출제 가능성이 가장 높은 예상문제 10선을 엄선했다. 이 글은 정통 출제형이고, AI 재해석형 10선은 자매글로 따로 다룬다.

출제 예상 Top 10 + 시험 전날 체크리스트

1. AI 기반 개발 패러다임의 변화: 바이브 코딩

문제: LLM을 활용하여 자연어 지시만으로 코드를 생성하는 바이브 코딩의 개념과, 이로 인해 변화할 SDLC 각 단계별 테스터와 개발자의 역할 변화에 대해 논하시오.

키워드: 자연어 인터페이스, LLM, Prompt Engineering, 코드 검증 자동화, AI 에이전트
답안 포인트: AI가 코드를 짜는 시대에는 '구현'보다 '의도(Intent) 정의'와 '결과 검증'이 핵심이다. TDD와 코드 리뷰의 중요성이 역설적으로 더 높아진다.

2. 소프트웨어 공급망 보안: SBOM과 거버넌스

문제: 오픈소스 취약점·공급망 공격에 대응하기 위한 SBOM의 개념, 구성 요소, 기업 차원의 오픈소스 거버넌스 구축 방안을 서술하시오.

키워드: 공·컴·버·식·의·작·타, SPDX·CycloneDX·SWID, VEX(Vulnerability Exploitability eXchange)
답안 포인트: SBOM은 생성보다 '활용'이 중요하다. CI/CD 파이프라인에 SBOM 스캐닝을 통합해 취약점을 실시간 탐지하는 체계를 제안하라.

3. 분산 환경의 데이터 정합성: Saga 패턴과 CQRS

문제: MSA 환경에서 ACID 트랜잭션의 한계를 극복하기 위한 Saga 패턴(Choreography vs Orchestration)의 메커니즘을 비교하고, 읽기 성능 향상을 위한 CQRS 적용 방안을 설명하시오.

키워드: 최종 일관성, 보상 트랜잭션, CDC, Event Sourcing, API Composition
답안 포인트: 모든 곳에 Saga를 쓸 순 없다. 비즈니스 중요도에 따라 강한 정합성(2PC)과 최종 일관성(Saga)을 선택적으로 적용하는 아키텍처 결단력이 필요하다.

4. 고신뢰성 시스템 안전 분석: STPA

문제: 자율주행·국방 등 복잡한 시스템의 사고 예방을 위한 STPA의 4단계 절차를 설명하고, 전통적인 FTA/FMEA와의 차이점을 기술하시오.

키워드: 제어 루프(Control Loop), UCA(부·부·시·지), 안전 제약사항, 컴포넌트 간 상호작용 고장
답안 포인트: SW는 부품 고장이 아니라 '부적절한 제어'에서 사고가 난다. 하드웨어 중심 사고에서 시스템 전체의 상호작용 중심 사고로의 전환을 강조하라.

5. SRE의 관측성(Observability)과 Error Budget

문제: SRE에서 단순 모니터링을 넘어선 관측성 3요소의 개념과, 서비스 출시 속도 조절을 위한 Error Budget 산정·활용 방안을 논하시오.

키워드: Metrics·Logs·Traces, SLI/SLO, Toil 관리, Blameless Post-mortem
답안 포인트: 안정성 100%는 불가능하며 비용도 높다. 비즈니스 가치와 안정성 사이의 합의점으로서 Error Budget을 활용하는 문화를 제언하라.

6. 클라우드 네이티브를 위한 Clean Architecture

문제: 특정 프레임워크나 인프라에 종속되지 않는 소프트웨어 설계를 위한 클린 아키텍처의 4계층 구조와 의존성 역전 원칙(DIP)의 관계를 설명하시오.

키워드: 엔·유·인·프, 비즈니스 엔티티 보호, 인터페이스 어댑터, 제어의 역전(IoC)
답안 포인트: 클린 아키텍처는 가독성을 넘어 '테스트 용이성'을 제공한다. 외부 DB나 API 없이도 비즈니스 로직을 독립 검증할 수 있는 구조적 이점을 언급하라.

7. 기술부채의 정량적 관리와 상환 전략

문제: 애자일 환경에서 가속화되는 기술부채의 발생 원인과 유형을 설명하고, 이를 관리하기 위한 정량적 측정 지표(SQALE) 및 상환 프로세스를 서술하시오.

키워드: 설·코·테·문, 코드 스멜, 리팩토링, McCabe 순환 복잡도, 기술적 파산
답안 포인트: 부채는 갚지 않으면 이자(유지보수 비용)가 붙는다. 기술부채 대시보드를 도입해 경영진과 '상환 주기'를 협의하는 거버넌스가 필요하다.

8. Shift-Left 테스팅과 MC/DC 커버리지

문제: 고신뢰성 SW 품질 확보를 위한 Shift-Left 테스팅의 개념과, 제어 흐름 테스트의 최고 수준인 MC/DC의 케이스 도출 원리를 설명하시오.

키워드: 결함 예방, 정적 분석, 독립적 영향력 확인, N+1 테스트 케이스, ISO 26262/ASIL
답안 포인트: MC/DC는 고비용 기법이다. 모든 모듈이 아닌 Safety-Critical한 핵심 모듈에 자원을 집중하는 위험 기반 테스트(RBT) 전략을 병행하라.

9. 공공 SW 사업의 혁신: 민간투자형 SW 사업

문제: 소프트웨어 진흥법 제40조에 따른 민간투자형 SW 사업의 추진 요건, 사업 유형(개·임·수·구), 기존 SI 방식 대비 기대 효과를 서술하시오.

키워드: 제안형/구매형, BTL/BTO, SaaS 우선순위, 타당성 분석(정·기·혁)
답안 포인트: 단순 구축을 넘어 민간의 자본과 '창의적인 서비스 모델'이 공공에 이식될 수 있도록 규제 샌드박스 등과의 연계를 제안하라.

10. 마이크로서비스 가시성 확보: Service Mesh

문제: 마이크로서비스 간 통신의 복잡성을 해결하기 위한 Service Mesh의 개념, 주요 기능, 그리고 Sidecar 패턴의 동작 원리를 설명하시오.

키워드: 데이터 플레인(Envoy), 컨트롤 플레인(Istio), mTLS, 회로 차단기(Circuit Breaker), 트래픽 쉐이핑
답안 포인트: 애플리케이션 코드에 통신 로직을 넣지 마라. 인프라 계층으로 통신 기능을 분리해 개발자는 비즈니스 로직에만 집중하는 환경을 구축해야 한다.

시험 전날 마지막 체크리스트

두음 복기: 비·복·변·무·순, 엔·유·인·프, 롤·블·카·쉐 등 핵심 두음을 다시 한 번 읊어볼 것
그림 연습: 4+1 View, Saga 패턴 구조, V-Model을 1분 안에 그릴 수 있어야 한다
시사 연결: 디지털플랫폼정부(DPG), AI 윤리 가이드라인 등 공학 외적 최신 이슈와의 연결 고리를 생각해볼 것

아는 것을 시험장 언어(두음·그림·시사)로 꺼내는 연습 — 마지막 하루에 할 일은 그것뿐이다.

기술사 핵심 암기 포인트

Top10 한 줄 지도: 바이브코딩(역할 이동) · SBOM(활용·VEX) · Saga(선택적 일관성) · STPA(부적절한 제어) · SRE(Error Budget 합의) · 클린아키(테스트 용이성) · 기술부채(SQALE·대시보드) · MC/DC(핵심 모듈 집중) · 민투형(창의 모델 이식) · Service Mesh(통신의 인프라화)
신규 킬러 키워드: VEX, SQALE, ISO 26262/ASIL, Envoy/Istio, Blameless Post-mortem
공통 답안 전략: 개념 정의 → 구조 도식 → 트레이드오프 → 실무 제언의 4단 구성

10문제의 기초가 되는 103개 토픽 전체는 소프트웨어공학 103토픽 두음 총정리에서 복습할 수 있다.

경영·거버넌스 축의 예상문제는 AI 경영·거버넌스 예상 문제 10선에서 이어서 볼 수 있다. 같은 토픽들을 AI 관점에서 재해석한 'AI 소프트웨어 공학 예상문제 10선'도 자매글로 준비되어 있다.

더 다뤘으면 하는 주제는 댓글로 남겨주세요.

AI 소프트웨어 공학 예상문제 10선 — 바이브 코딩·RAG·메타모픽 테스팅·LLMOps·AI-BOM

정보관리기술사의 노트 — Tue, 14 Jul 2026 10:22:27 +0900

AI 소프트웨어 공학 예상문제 10선 — 바이브 코딩·RAG·메타모픽 테스팅·LLMOps·AI-BOM

최근 정보관리기술사·컴퓨터시스템응용기술사 시험의 핵심 흐름은 "전통적인 소프트웨어 공학이 AI라는 파괴적 기술을 어떻게 수용하고 통제할 것인가"에 집중되어 있다. 소프트웨어공학 핵심 토픽과 최신 AI 트렌드를 결합한 예상문제 10선을 우선순위별로 정리한다.

출제의 공식은 하나다 — 아는 개념(SOLID·V모델·SBOM·STPA...) + AI 맥락 = 답안. 새로 외울 것이 아니라, 이미 공부한 것을 재해석하는 시험이다.

전통 SW공학 → AI 재해석 매핑 — 출제의 공식

1순위: 바이브 코딩과 SDLC의 변화

문제: LLM을 활용해 자연어로 소프트웨어를 개발하는 바이브 코딩의 개념을 설명하고, 기존 SDLC(폭포수·애자일)가 AI 에이전트 기반의 명세 중심 개발로 어떻게 변화할 것인지 논하시오.

핵심 키워드: 자연어 인터페이스, AI 에이전트, Prompt-as-Code, 명세 기반 생성, 코드 리뷰 자동화
답안 포인트: "코딩의 종말"이 아니라 "설계와 검증의 시대"임을 강조. 기술사의 역할은 코드를 짜는 사람이 아니라 AI가 짠 코드의 아키텍처 적합성을 판단하는 사람으로 이동한다.
연계 글: AI 시대 개발 생산성과 품질 관리 (바이브 코딩·테스트 하네스)

2순위: LLM 애플리케이션 아키텍처 — RAG와 클린 아키텍처

문제: LLM의 환각(Hallucination)을 방지하기 위한 RAG(검색 증강 생성) 아키텍처를 클린 아키텍처 관점에서 도식화하고, 외부 지식 베이스와의 의존성 분리 방안을 서술하시오.

핵심 키워드: 엔·유·인·프, Vector DB, Semantic Search, Orchestration(LangChain 등), DIP
답안 포인트: AI 모델은 '프레임워크와 드라이버' 계층의 외부 요소로 취급한다. 핵심 비즈니스 로직(Entity)은 특정 모델에 종속되지 않아야 한다 — 모델 교체가 잦은 시대의 생존 설계다.
연계 글: 클린 아키텍처와 MSA 핵심 패턴

3순위: AI 품질 보증과 메타모픽 테스팅

문제: 입력에 대한 정답이 하나로 정해지지 않은 AI 시스템(Oracle Problem)을 검증하기 위한 메타모픽 테스팅의 개념과 테스트 오라클의 한계 극복 방안을 서술하시오.

핵심 키워드: 오라클 문제, 메타모픽 관계(MR), 입력 변환, 일관성 검증
답안 포인트: 전통적 참 오라클은 AI에서 동작하지 않는다. 정답 비교 대신 결과의 '일관성'과 '경향성'을 측정하는 새 품질 지표를 제안하라. 예: 입력을 회전시켜도 이미지 분류 결과는 같아야 한다(MR).
연계 글: 소프트웨어 테스트 핵심 정리 (테스트 오라클·7대 원리)

4순위: LLMOps

문제: DevOps·MLOps를 넘어선 LLMOps의 핵심 프로세스를 CI/CD/CT 관점에서 설명하고, 데이터 드리프트 및 모델 성능 모니터링 방안을 논하시오.

핵심 키워드: 지속적 학습(Continuous Training), 피드백 루프, 모델 서빙, 벤치마크 데이터셋
답안 포인트: AI 서비스의 안정성은 '모델'이 아니라 '데이터 파이프라인'에서 결정된다. SRE의 관측성(Observability)을 AI에 이식하라.
연계 글: DevOps·SRE·무중단 배포 (Error Budget·Observability)

5순위: AI 서비스 도입 비용 산정

문제: 가이드라인에 따른 AI 서비스 도입 비용 산정 방식(단순 도입·커스터마이징·시스템 통합)을 설명하고, 데이터 가공·모델 학습 비용 산정 시 고려사항을 서술하시오.

핵심 키워드: AI 이용료, 커스터마이징 작업비, GPU 인프라 비용, 데이터 구축·전처리 비용
답안 포인트: FP만으로는 AI 복잡도를 못 잡는다. '데이터 엔지니어링 난이도'가 새 비용 산정 기준이 되어야 한다.
연계 글: 소프트웨어 진흥법과 비용 산정 (AI 도입 절차·COCOMO)

6순위: AI 에이전트 워크플로우와 디자인 패턴

문제: 단일 프롬프트를 넘어 복잡한 태스크를 수행하는 Agentic Workflow의 개념을 설명하고, 계획·메모리·도구 사용 등의 설계 패턴을 서술하시오.

핵심 키워드: Multi-Agent, Chain-of-Thought, ReAct, Reflection — Andrew Ng의 Agentic 4대 패턴(Reflection·Tool Use·Planning·Multi-agent)
답안 포인트: SW는 정적 로직에서 자율 에이전트들의 협업체로 진화한다. Service Mesh 같은 통신 제어가 에이전트 간 통신에도 필요해진다.
연계 글: AI Agent가 읽는 데이터 레이크 5계층 (MCP·Agent 거버넌스)

7순위: AI 시스템의 숨은 기술부채

문제: 구글이 제시한 AI 시스템의 숨겨진 기술부채 유형(데이터 의존성·파이프라인 정글 등)을 설명하고, 엔지니어링적 대응 방안을 논하시오.

핵심 키워드: 얽힘(Entanglement)과 CACE 원칙(Changing Anything Changes Everything), 설정 부채, 피드백 루프, 모니터링 부채 — 출처: Sculley 외, "Hidden Technical Debt in ML Systems"(2015, 구글)
답안 포인트: AI 코드는 짧지만 주변 인프라·데이터 의존성은 거대하다. '코드보다 시스템 전체'를 관리해야 부채의 파산을 막는다.
연계 글: AI 시대 개발 생산성과 품질 관리 (기술부채 사분면)

8순위: 고신뢰성 AI를 위한 STPA 안전 분석

문제: AI가 포함된 자율 시스템의 사고 방지를 위해 STPA를 적용할 때, AI 모델의 불확실성이 제어 루프에 미치는 영향과 UCA 도출 방안을 서술하시오.

핵심 키워드: 제어 로직 오류, 안전 제약사항, UCA 4유형(부·부·시·지), 모델 환각
답안 포인트: AI 사고는 '고장'이 아니라 '의도하지 않은 동작'에서 발생한다. 제어권(Control Authority)의 명확한 설계가 필수다.
연계 글: 소프트웨어 품질·신뢰성 핵심 정리 (FMEA·FTA·STPA)

9순위: AI 공급망 보안과 AI-BOM

문제: AI 모델과 학습 데이터를 포함한 AI 공급망 보안 위협을 설명하고, 기존 SBOM을 확장한 AI-BOM(ML-BOM)의 필요 구성 요소를 논하시오.

핵심 키워드: 모델 가중치, 학습 데이터 출처, 편향성 리포트, Adversarial Attack, 데이터·모델 리니지
답안 포인트: SW 자재 명세서를 넘어 '데이터와 모델의 이력(Lineage)'까지 투명하게 공개하는 시대다. CycloneDX가 이미 ML-BOM을 지원한다.
연계 글: 오픈소스 라이선스와 SW·HW 규모 산정 (SBOM·공급망)

10순위: AI 기반 테스트 자동화

문제: 테스트 케이스 생성부터 실행·결과 분석까지 AI가 수행하는 AI-driven Testing의 아키텍처를 설계하고, 자가 치유(Self-healing) 테스트 스크립트 기술을 설명하시오.

핵심 키워드: 자가 치유 테스트, 케이스 자동 생성, 결함 예측 모델, 시각적 회귀 테스트
답안 포인트: 로우코드·노코드와 결합된 AI 테스트 자동화가 개발 속도의 트리거가 된다 — 1순위(바이브 코딩)가 만든 검증 병목을 이것이 푼다.
연계 글: 소프트웨어 테스트 핵심 정리 (회귀 테스트)

골든 토픽 2제 — 출제 사각지대

① 디지털플랫폼정부(DPG)와 AI 허브 아키텍처: 공공 AI 도입의 표준 프레임워크와 데이터 공유 체계 — 법제도(영향평가·민투형)와 공학이 결합되는 좋은 문제.

② AI 윤리와 정형 검증(Formal Verification): AI의 판단을 로직으로 검증할 수 있는가 — 자율주행·의료 SW에서 정형 명세·검증이 AI와 결합되는 지점.

마치며 — 재해석이 답이다

이 10+2 문제의 공통 구조는 명확하다. 기존에 공부한 SOLID·ATAM·V-Model·CMMI·SBOM·STPA를 AI 상황에 맞춰 재해석하는 것. 왼쪽(전통 개념)은 이미 알고 있다 — 시험장에서 할 일은 오른쪽(AI 맥락)으로 옮겨 적는 것뿐이다.

기술사 핵심 암기 포인트

출제 공식: 전통 토픽 + AI 맥락 = 재해석 답안
1~2순위: 바이브 코딩(설계·검증의 시대), RAG(모델=외부 드라이버, DIP)
3순위 킬러: 메타모픽 테스팅 — Oracle Problem을 MR(일관성)로 극복
7순위 킬러: CACE 원칙, Hidden Technical Debt(구글 2015)
답안 키워드: Prompt-as-Code, CT(지속학습), 데이터 드리프트, ReAct, UCA, AI-BOM, Self-healing Test
실무 연결: AI 안정성=데이터 파이프라인, 공급망은 모델·데이터 리니지까지

이 글의 각 문제에 대응하는 전통 토픽의 기초는 소프트웨어공학 103토픽 두음 총정리에서 확인할 수 있다.

AI 경영·거버넌스 관점의 예상문제는 AI 경영·거버넌스 예상 문제 10선에서 이어서 볼 수 있다 — 그 글이 '경영' 축, 이 글이 '공학' 축이다.

더 다뤘으면 하는 주제는 댓글로 남겨주세요.

소프트웨어공학 103토픽 두음 총정리 — 시험 직전 마지막 암기장

정보관리기술사의 노트 — Tue, 14 Jul 2026 08:49:24 +0900

소프트웨어공학 103토픽 두음 총정리 — 시험 직전 마지막 암기장

정보관리기술사·컴퓨터시스템응용기술사 시험의 소프트웨어공학 도메인 103개 핵심 토픽을, 소프트웨어 생명주기(SDLC)와 관리 체계에 맞춰 9개 영역으로 재분류했다. 시험 직전 인출 연습용 허브로, 각 영역의 상세 개념은 개별 발행 글로 이어진다.

9영역 체계도 — 만들고·지키고·값 매기는 구조

1. 공학 기초 및 프로세스 모델

토픽	두음	상세
SW 공학 특징	비·복·변·무·순	비가시성, 복잡성, 변경성, 무형성, 순응성
공학 발전원리	공·표·자·품	공학적 접근, 표준화, 자동화 도구, 품질보증체계
SW공학 구성요소	방·구·다·프	방법, 도구, 패러다임, 프로세스
폭포수 모델	순·하·산·단	순차적, 하향식, 산출물 중심, 단계적 테스팅
나선형 모델	계·위·개·고	계획, 위험분석(핵심), 개발, 고객평가
프로토타이핑	요·프·검·피·상·설	요구분석→Prototype→검토→Feedback→상세설계→설치
RAD 모델	지·라·크·씨	JRP(계획), JAD(설계), Construction, Cutover
반복적 모델	증·병 / 진·핵·피	증분: 병렬개발 / 진화: 핵심요구·지속발전·Feedback

2. 요구공학 및 방법론

토픽	두음	상세
요구사항 개발	추·분·명·검	추출·분석·명세·검증 (CMMI L3)
요구사항 관리	협·기·변·검	협상·기준선·변경관리·검토 (CMMI L2)
비기능 요구	성·장·인·테·보·품	성능·장비·인터페이스·테스트·보안·품질
SRS 8특성	정·명·완·일·중·검·수·추	정확·명확·완전·일관·중요도·검증·수정·추적
방법론 구성	절·방·산·관·기·도	절차·방법·산출물·관리·기법·도구
정보공학(IE)	ISP→BAA→BSD→SC	전략계획→업무영역분석→시스템설계→구축
CBD	정·분·컴·검·조·응	요구정의→영역분석→설계→검색→조립→응용
Product Line	프·리·인	Proactive·Reactive·Incremental
테일러링	특·표·상·문	특징정의·표준선정·커스터마이징·문서화

3. 객체지향 설계 및 패턴

토픽	두음	상세
객체지향 특징	캡·추·다·정·상	캡슐화·추상화·다형성·정보은닉·상속성
추상화 유형	기·데·제	기능·데이터·제어 추상화
다형성	로딩 vs 라이딩	오버로딩(동일명·다른인자) / 오버라이딩(상속·재정의)
설계 원칙	SOLID	단일책임·개방폐쇄·리스코프·인터페이스분리·의존역전
디자인 패턴	생(5)·구(7)·행(11)	GoF 23종
MVC	M·V·C	Model·View·Controller — 관심사 분리
UML	정적 클·객·패·컴 / 동적 유·액·상·시	구조 vs 행위 다이어그램

4. 소프트웨어 아키텍처

토픽	두음	상세
설계 프로세스	요·참·모·프·배	요구파악→참조모델→모델링→프로토타입→배포
ISO 42010	환·관·이·관·뷰·모	환경·관심사·이해관계자·관점·뷰·모델
4+1 View	시·논·구·프·배	Scenario(+1)·Logical·Implementation·Process·Deployment
ATAM	소·조·테·보	소개→조사(Utility Tree)→테스트→보고
CBAM	시·효·전·선	시나리오→효용곡선→전체이익(ROI)→선정
클린 아키텍처	엔·유·인·프	Entities→UseCases→Adapters→Frameworks
MSA 계층	유·아·서·퍼	User→API Gateway→API Server→Persistence
Service Mesh	사이드카	서비스 디스커버리·서킷브레이커·통신 분리
DDD	유·분·바·컨·마	유비쿼터스언어→분석→Bounded Context→Map→MS도출
Saga	코 vs 오	Choreography(이벤트) / Orchestration(중앙) + 보상 트랜잭션
CQRS·Discovery	명·조 분리 / 클·서	명령·조회 분리 / Client·Server-side 탐색

(*) MSA 두음 참고: "유·아·서·퍼"는 계층 구조 축, 별도로 "콘·데·폴·디"(콘웨이·DDD·Polyglot·DevOps)는 성공 기반 축 — 다른 관점의 두음이니 혼동 주의.

5. 현대적 개발 및 운영 (DevOps/AI)

토픽	두음	상세
AOP	조·포·어·애·위	JoinPoint·Pointcut·Advice·Aspect·Weaving
TDD	빨·초·리	Red→Green→Refactor
DevOps/SRE	모·카·변·장·문	모니터링·Capacity·변화·장애·문화 + Error Budget
무중단 배포	롤·블·카·쉐	Rolling·Blue/Green·Canary·Shadow
SBOM	공·컴·버·식·의·작·타	NTIA 최소 7요소
로우코드/바이브	LCNC / 자연어	시각 도구 / LLM 의도→코드 생성
기술부채	설·코·테·문	설계·코드·테스트·문서 부채

6. 소프트웨어 테스트

토픽	두음	상세
7대 원리	결·불·초·집·살·정·오	결함발견~오류부재의 궤변
테스트 단계	단·통·시·인·설	단위→통합→시스템→인수→설치
V-Model	검증 vs 확인	Verification(과정·정적) / Validation(결과·동적)
블랙박스	동·경·의·상·페	동등분할·경계값·의사결정·상태전이·페어와이즈
화이트박스	구·결·조·변·다	구문⊂결정⊂조건⊂MC/DC⊂다중조건
탐색적	차·박·노·디	Charter·Time-box·Note·Debriefing
성능	단·복·임 + L=λW	단위·복합·임계 성능 / 리틀의 법칙
회귀	리·파·사·부	Ripple·파급·Side Effect·부작용
테스트 케이스	식·항·입·출·환·특·의	IEEE 829 구성요소
ISO 29119	개·프·도·테·키	개념·프로세스·문서화·기법·키워드주도

(*) 성능 "단·복·임"은 측정 대상 축, 부하 패턴 축(부하·스트레스·스파이크·내구성)과는 별개 분류.

7. 유지보수 및 품질·안전성 관리

토픽	두음	상세
모듈화	응 높·결 낮	응집도(우·논·시·절·통·순·기↑) / 결합도(내·공·외·제·스·자↓)
3R 공학	역·재·재	Reverse·Re-engineering·Reuse
코드 스멜	중·긴·큰·긴·샷·다·주	리팩토링 대상 징후
유지보수 유형	수·완·예·적	수정적·완전적·예방적·적응적
CMMI	초·관·정·량·최	L1초기→L2관리→L3정의→L4정량→L5최적화
순환 복잡도	E−N+2	McCabe V(G) = 간선 − 노드 + 2
FMEA	심·발·검	심각도·발생도·검출도 → RPN
HAZOP	이·변·가	이탈·공정변수·가이드워드
FTA	정·통·기·게	정상·통상·기본사상 + AND/OR 게이트
STPA	사·컨·언·원	사고정의→제어구조→Unsafe Action→원인

8. 소프트웨어 경제성 및 거버넌스

토픽	두음	상세
비용산정	상·하·수	상향식(LOC)·하향식(델파이)·수학적(COCOMO·FP)
FP 절차	유·범·데·트·미·인·조	유형→범위→데이터→트랜잭션→미조정→인자→조정
FP 보정	규·연·성·운·보	규모·연계·성능·운영·보안
COCOMO I / II	오·세·엠 / 애·초·포	규모 3모드 / 단계 3모델
OSS 조건	자·소·파·차·일·라·동	7대 조건 (OSD 원전은 10개)
OSS 거버넌스	정·획·적·운·관	정책→획득→적용→운영→관리
HW 산정	기·분·모·가	기초조사→분석→참조모델→가중치

9. SW 법제도 및 공공 정책

토픽	두음	상세
영향평가 제외	상·안·민·단·단·D	상용·안보·민투·단일기관·단순유지·DB
영향평가 단계	기·운·민·사·종	기본정보→운영계획→민간유사성→필요성→종합
BMT 절차	대·사·설·조·의·실·결	대상검토→사전협의→설계→조달→의뢰→실시→결과
민투형	개·임·수·구	개발형·임대형(BTL)·수익형(BTO)·구매형(SaaS)
AI 도입	단·커·시	단순 도입→커스터마이징→시스템 통합

마치며 — 103토픽을 꿰는 세 흐름

이 토픽들은 개별 지식이 아니라 '품질과 신뢰성'이라는 흐름으로 연결된다.

첫째, 품질의 Shift-Left. 요구공학(추·분·명·검)에서 시작된 품질은 SOLID·클린 아키텍처를 거쳐 TDD와 MC/DC 테스트로 완성된다 — 뒤로 미룰수록 비싸진다.

둘째, 민첩성과 가시성. MSA·DevOps 환경에서는 Service Mesh와 SBOM으로 복잡성을 통제하고 투명성을 확보해야 한다 — 빨리 만드는 기술과 들여다보는 기술은 한 쌍이다.

셋째, 지속 가능한 공학. 리팩토링·기술부채 관리로 소프트웨어의 노화를 막고, CMMI·거버넌스로 조직의 성숙도를 높인다 — 코드의 수명은 조직의 습관이 정한다.

시험 직전에는 이 표로 인출 연습을 하되, 막히는 영역은 아래 상세 글로 돌아가 맥락을 복원할 것을 권한다.

상세 글로 이어보기

②요구공학·CBD와 ⑤의 TDD·AOP는 소프트웨어 재사용과 현대 개발 기법에서 다룬다.

④아키텍처는 평가(ISO 42010·ATAM·CBAM), 패턴·MSA·DDD, 클린 아키텍처·CQRS·Saga 세 편으로 이어진다.

⑤현대적 운영은 DevOps·SRE·무중단 배포와 AI 시대 개발 생산성(바이브코딩·SBOM·기술부채)에서 다룬다.

⑥테스트(7대 원리·V모델·커버리지·MC/DC)는 소프트웨어 테스트 핵심 정리에서 이어진다.

⑦품질·안전성(응집도·결합도·CMMI·FMEA·FTA·STPA)은 소프트웨어 품질·신뢰성 핵심 정리에서 이어진다.

⑧경제성과 ⑨법제도는 오픈소스 라이선스와 SW·HW 규모 산정과 소프트웨어 진흥법과 비용 산정에서 확인할 수 있다.

더 다뤘으면 하는 주제는 댓글로 남겨주세요.

지도의 빈자리에 용을 그리는 기계 — LLM은 왜 그럴싸한 거짓말을 하는가

정보관리기술사의 노트 — Wed, 8 Jul 2026 15:42:41 +0900

지도의 빈자리에 용을 그리는 기계

기계가 거짓말을 할 수 있을까요?

중세의 지도 제작자들에게는 오래된 관습이 하나 있었습니다. 아무도 가보지 못한 바다, 아직 측량되지 않은 땅. 그 빈자리를 그들은 비워두지 않았습니다. 대신 상상의 괴물을 그려 넣고 이렇게 적었죠. "여기에 용이 있다(Here be dragons)."

거짓말을 하려던 게 아니었습니다. 다만 지도란 빈칸을 견디지 못하는 물건이었을 뿐입니다.

저는 요즘의 인공지능을 볼 때마다 그 오래된 지도가 떠오릅니다. 챗봇이 존재하지 않는 보험 조항을 그럴듯하게 읊고, 사내 어시스턴트가 물을 때마다 다른 임직원 수를 답하는 장면들. 업계는 이것을 환각(Hallucination)이라 부르며 지난 몇 년간 가장 뜨거운 단어로 소비해 왔습니다.

그런데 15년 가까이 데이터 곁에서 일해 온 사람으로서, 저는 이 단어가 조금 억울하게 쓰이고 있다고 생각합니다.

기계는 정말 거짓말쟁이일까

환각에 대한 흔한 설명은 이렇습니다. "언어모델은 확률로 다음 단어를 예측할 뿐이라, 그럴싸하지만 틀린 말을 지어낸다." 기술적으로 틀린 말은 아닙니다. 모델의 크기, 학습 데이터의 편향, 생성 전략 — 모두 실재하는 요인입니다.

하지만 현장에서 이상한 광경을 목격하게 됩니다. 같은 모델, 같은 설정을 써도 어떤 회사에서는 AI가 제법 정직하고, 어떤 회사에서는 헛소리를 늘어놓습니다. 모델이 같은데 결과가 다르다면, 범인은 모델이 아니라는 뜻이겠지요.

차이를 만드는 것은 그 모델이 발을 딛고 선 데이터의 상태였습니다.

그래서 저는 환각을 이렇게 다시 정의하고 싶습니다. 환각이란, 데이터가 침묵하는 자리를 모델이 언어로 메우는 현상이라고. 지도 제작자가 미지의 바다에 용을 그려 넣듯이 말입니다.

데이터가 침묵하는 다섯 가지 방식

침묵은 한 가지 얼굴로 오지 않습니다. 현장에서 반복해 마주친 얼굴이 다섯입니다.

첫 번째는 부재의 침묵입니다. 답의 근거가 애초에 없는 경우죠. 최신 개정 문서가 아직 시스템에 등록되지 않았는데 챗봇에게 그 내용을 묻는다면, 모델은 "그 문서는 없습니다"라고 말하는 대신 세상의 일반적인 통념으로 빈자리를 채웁니다. 없는 조항이 그럴듯하게 태어나는 순간입니다.

두 번째는 정의의 침묵입니다. 데이터는 있는데 그 뜻이 어디에도 적혀 있지 않은 경우. 한 회사 안에 '매출'이라는 단어가 재무 기준, 영업 기준, 물류 기준으로 제각각 존재하는데 어느 기준인지 표시가 없다면, 모델은 눈에 띄는 첫 숫자를 집어 답합니다. 임원이 아는 숫자와 다른 답이 나오는 이유입니다.

세 번째는 맥락의 침묵입니다. 숫자는 있는데 그 숫자가 태어난 사정이 지워진 경우. 설비 재정비 기간의 시험 가동 데이터가 아무 표시 없이 정상 데이터와 같은 테이블에 섞여 있다면, 모델은 멀쩡한 상황을 이상 현상으로 읽습니다. 사람이라면 "아, 그 주는 공사 중이었지" 하고 걸러냈을 것을, 모델은 알 길이 없습니다.

네 번째는 관계의 침묵입니다. 조각들은 다 있는데 서로 이어져 있지 않은 경우. 고객을 부르는 이름이 시스템마다 달라 연결 고리가 끊겨 있으면, 모델은 분명히 존재하는 기록을 "없다"고 답합니다. 없는 것을 있다고 하는 것만 환각이 아닙니다. 있는 것을 없다고 하는 것도 환각의 얼굴입니다.

다섯 번째가 가장 미묘합니다. 권위의 침묵. 같은 질문에 여러 답이 존재하는데, 무엇이 공식인지 조직이 정하지 못한 경우입니다. "우리 회사 임직원은 몇 명입니까"라는 물음에 인사 시스템과 급여 시스템과 공시 자료가 서로 다른 숫자를 갖고 있다면, AI는 물을 때마다 다른 답을 냅니다. 이때 기계는 단 한 번도 거짓말을 하지 않았습니다. 매번 실제 데이터를 읽었을 뿐입니다. 답을 하나로 정하지 못한 것은 사람이었습니다.

용을 지우는 법

그렇다면 무엇을 해야 할까요. 거창한 로드맵보다, 내일부터 가능한 일들이 있습니다.

먼저, 기계에게 "모른다"고 말할 권리를 주는 것입니다. 지금의 AI 서비스 대부분은 무엇을 물어도 답하도록 만들어져 있습니다. 그것이 환각의 첫 번째 조건입니다. 근거가 부족하면 답을 거절하도록 설계된 시스템이, 그럴싸한 거짓말을 하는 시스템보다 훨씬 믿을 만합니다.

다음은 침묵의 지도를 그리는 일입니다. 우리 조직 어디에 데이터가 비어 있고, 어떤 용어가 정의되지 않았고, 어떤 연결이 끊겨 있고, 어떤 답이 합의되지 않았는지. 이 지도가 있으면 어떤 질문에서 용이 그려질지 미리 알 수 있습니다.

그리고 답변 옆에 근거를 함께 보여주는 것. 어디까지가 데이터에 발 딛은 말이고 어디부터가 채워 넣은 말인지 처음부터 보이게 하면, 사람은 그럴싸함에 속지 않게 됩니다.

마지막으로, 환각을 모델팀이 아니라 데이터팀의 문제로 다루는 것입니다. 뿌리가 데이터에 있다면, 책임도 그 곁에 있어야 하니까요.

에필로그 — 지도는 조직의 자화상이다

대항해시대가 무르익으면서 지도의 용들은 하나씩 사라졌습니다. 항해술이 좋아져서가 아닙니다. 누군가 그 바다에 실제로 가서, 보고, 기록했기 때문입니다. 빈칸이 측량으로 채워지자 상상의 괴물은 설 자리를 잃었습니다.

환각도 마찬가지라고 생각합니다. 더 큰 모델, 더 정교한 프롬프트가 용을 지워주지는 않습니다. 데이터가 부재하면 지어내고, 뜻이 없으면 멋대로 해석하고, 맥락이 없으면 오독하고, 관계가 끊기면 못 본 척하고, 권위가 없으면 매번 다른 답을 내는 것 — 이 침묵들을 하나씩 측량해 채우는 일만이 용을 지웁니다.

결국 AI의 환각은 기계의 결함이 아니라, 데이터가 침묵하는 조직의 자화상인지도 모릅니다.

당신 조직의 지도에는, 지금 어디에 용이 그려지고 있습니까?

소프트웨어 진흥법과 비용 산정 — SW 영향평가·BMT·민간투자형 사업·COCOMO

정보관리기술사의 노트 — Wed, 8 Jul 2026 10:31:12 +0900

소프트웨어 진흥법과 비용 산정 — SW 영향평가·BMT·민간투자형 사업·COCOMO

SW 진흥법 기반의 공공 사업 관리 체계(영향평가·BMT·민간투자형)와 SW 경제성 공학(COCOMO·AI 비용 산정)은 최근 정보관리기술사·컴퓨터시스템응용기술사 시험에서 비중 있게 다뤄지는 법제도·비용 도메인이다. 공공 SW 사업의 관문들부터 산정 모델의 진화까지 한 번에 정리한다.

관통하는 질문 하나 — "공공이 직접 만드는 것이 최선인가?" 영향평가는 시장 침해를, BMT는 제품 선택을, 민간투자형은 재원 조달을 각각 이 질문의 관점에서 검증한다.

1. SW 진흥법 기반 공공 사업 관리 체계

세 제도는 공공 SW 사업 생애주기의 서로 다른 지점에 서 있는 관문이다 — 기획 단계의 영향평가, 조달 단계의 BMT, 재원 조달의 민간투자형.

공공 SW 3대 관문 — 기획·조달·재원

가. SW 영향평가 (법 제43조)

공공기관의 SW 개발이 민간 시장을 침해하는지 사전 검토하여 산업 생태계를 보호하는 제도다.

평가 대상: 기·구·유 (기획 · 구축 · 유지관리 — 사업 전주기)
제외 대상: 상·안·민·단·단·D (상용 SW 구매 · 안보/치안 · 민투 SW · 단일기관 이용 · 단순 유지보수 · DB 구축)
평가 단계: 기·운·민·사·종 (기본정보 → 운영계획 → 민간침해 검토 → 사업성 → 종합의견)

나. 품질성능 평가시험 (BMT)

동종 SW 간 성능을 객관적으로 비교해 최적 제품을 선정하는 제도로, SW 직접구매(분리발주)와 연계되어 운영된다. 직접구매 대상 SW 중 일정 규모 이상 사업이 대상이다(금액 기준은 고시 개정에 따라 변동 — 최신 고시 확인 필요).

절차 두음은 "대·사·설·조·의·실·결"(대상검토 → 사전협의 → 설계 → 조달발주 → 의뢰 → 실시 → 결과)이다.

다. 민간투자형 SW 사업 (법 제40조)

공공 예산 부족을 해결하고 민간의 창의적 기술을 도입하는 제도다.

민투형 4유형 — 회수 방식과 위험 부담

유형	방식	투자비 회수
개발형	민간 개발 → 공공 소유	개발 대가
임대형(BTL)	구축·이전 후 공공이 임차	정부 임대료 (수요 위험 낮음)
수익형(BTO)	구축·이전 후 민간이 운영	이용자 수익 (수요 위험 민간 부담)
구매형	민간 보유 서비스(SaaS) 구매	사용료

구매형 요건 두음은 "민·서·사·디"(민간 존재 · 서비스 형태 · 사용료 · 디지털서비스 계약), 타당성 분석 3축은 "정·기·혁"(정책성 · 기술성 · 혁신성)이다.

2. AI 도입 및 비용 산정 모델

가. AI 서비스 도입 절차와 비용

AI는 일반 SW와 달리 데이터 학습·모델 튜닝 비용이 들어 별도 산정 체계가 필요하다.

도입 단계: 단순 이용 → 커스터마이징(데이터·모델) → 시스템 통합(SI 결합)
비용 구성: 이용료 + 작업 비용(데이터 가공·학습) + 구축 비용

단계가 깊어질수록 '이용료' 비중은 줄고 '작업·구축 비용' 비중이 커진다 — AI 사업 견적의 핵심 구조다.

나. COCOMO — 경험적 비용 산정의 고전

COCOMO I→II — 규모 기준에서 단계 기준으로

경험적 데이터 기반으로 공수(Man-Month)와 기간을 산정하는 수학적 모형이다.

COCOMO I — 오·세·엠 (규모 기준 3모드):

모드	규모	특성
Organic	5만 라인 이하	소규모·안정 환경
Semi-detached	30만 라인 이하	중간 규모·복잡도
Embedded	30만 라인 초과	HW·규제 등 강한 제약

COCOMO II — 애·초·포 (개발 단계 기준 3모델): 애플리케이션 합성(프로토타이핑, FP 중심) → 초기 설계(정성 인자) → 포스트 아키텍처(상세 설계 후 정밀 산정).

시험 포인트: I은 '규모(라인 수)'로 모드를, II는 '개발 단계'로 모델을 나눈다. 단계가 진행될수록 정밀도가 올라가는 차등 산정이 II의 본질이다.

3. 기술사적 제언

첫째, SaaS First와 영향평가의 진화. 클라우드 네이티브 전환이 가속되면서 공공은 직접 개발보다 민간 SaaS 우선 활용으로 가야 한다. 이에 따라 영향평가의 기준도 '민간 서비스 존재 여부'를 넘어 'SaaS 전환 적합성'으로 확장될 필요가 있다 — 민투형 4유형 중 구매형이 성장 축이 되는 배경이다.

둘째, BMT의 실효성 제고. 단순 기능 비교를 넘어, 실운영과 유사한 부하 상황에서의 회복 탄력성(Resilience)과 보안 성능이 핵심 평가지표가 되어야 한다. 정적 스펙 비교로는 클라우드 시대의 품질을 못 잡는다.

셋째, AI 비용 산정의 정교화. AI 사업은 학습 데이터 품질과 재학습 주기에 따라 비용 변동이 크다. 전통적인 COCOMO·FP에 '데이터 엔지니어링 복잡도'를 반영한 가중치 모델 도입이 시급하다 — 앞서 기능점수 글에서 지적한 "FP는 AI 사업의 원가를 못 잡는다"는 한계의 해법 방향이기도 하다.

종합하면, 세 관문(영향평가·BMT·민투형)과 산정 모델(COCOMO·FP)은 결국 하나의 흐름이다 — 공공 SW의 "만들 것인가, 살 것인가, 빌릴 것인가"를 검증하고, 그 값을 매기는 체계. 그리고 그 체계 전체가 지금 SaaS·AI라는 두 변수 앞에서 재설계를 요구받고 있다.

마치며 — 핵심 요약

영향평가는 시장을 보호하고, BMT는 제품을 검증하며, 민간투자형은 재원을 연다. COCOMO는 규모에서 단계로 산정의 축을 옮겨 왔고, AI 시대는 여기에 데이터 복잡도라는 새 축을 요구한다.

기술사 핵심 암기 포인트

영향평가: 대상 기·구·유 / 제외 상·안·민·단·단·D / 단계 기·운·민·사·종
BMT 절차: 대·사·설·조·의·실·결 (직접구매·분리발주 연계)
민투형: 개·임·수·구 / 구매형 요건 민·서·사·디 / 타당성 정·기·혁
COCOMO I: 오·세·엠 (5만/30만 라인 기준) / II: 애·초·포 (단계별 차등)
AI 비용 = 이용료 + 작업비(데이터·학습) + 구축비
답안 키워드: SW진흥법 제43조·제40조, 분리발주, BTL/BTO, SaaS, Man-Month, KLOC
실무 연결: SaaS First 시대의 영향평가 재설계, BMT는 Resilience·보안 중심으로, AI는 데이터 복잡도 가중치

예상 문제

(10점) 민간투자형 SW 사업의 4가지 유형을 투자비 회수 방식 관점에서 비교 설명하시오.
(25점) COCOMO I과 II의 차이를 설명하고, AI 사업 비용 산정에서 전통적 산정 모델의 한계와 개선 방향을 논하시오.

기능점수(FP)와 HW 규모 산정 등 비용 산정의 짝은 오픈소스 라이선스와 SW·HW 규모 산정에서 다룬다.

프로젝트 원가 관리(EVM)와 일정 산정은 프로젝트 일정·원가 관리 핵심 정리에서 이어서 볼 수 있다.

더 다뤘으면 하는 주제는 댓글로 남겨주세요.

클린 아키텍처와 MSA 핵심 패턴 — 의존성 규칙·Service Discovery·CQRS·Saga

정보관리기술사의 노트 — Wed, 8 Jul 2026 10:16:27 +0900

클린 아키텍처와 MSA 핵심 패턴 — 의존성 규칙·Service Discovery·CQRS·Saga

클린 아키텍처와 MSA의 핵심 패턴(Service Discovery·CQRS·Saga)은 대규모 분산 시스템을 지탱하는 설계의 정수다. 고수준 비즈니스 로직을 외부로부터 격리하고, 분산 환경의 데이터 정합성 문제를 푸는 이 주제들은 정보관리기술사·컴퓨터시스템응용기술사 시험의 아키텍처 심화 빈출 영역이다. 원리부터 트레이드오프까지 한 번에 정리한다.

관통하는 질문 하나 — "변하는 것과 변하지 않는 것을 어떻게 분리할 것인가." 클린 아키텍처는 코드 안에서, MSA 패턴들은 서비스 사이에서 같은 질문에 답한다.

1. 클린 아키텍처 (Clean Architecture)

로버트 C. 마틴이 제안한 설계 원칙으로, 핵심 로직이 프레임워크·UI·DB 같은 외부 요소에 의존하지 않도록 계층을 분리한다.

클린 아키텍처 동심원 — 의존성은 안쪽으로만

계층 두음은 "엔·유·인·프"(안쪽→바깥쪽)다.

계층	역할
Entities	핵심 업무 규칙 — 가장 높은 추상화
Use Cases	애플리케이션 특화 규칙, 데이터 흐름 제어
Interface Adapters	내·외부 간 데이터 변환 (Controller·Presenter·Gateway)
Frameworks & Drivers	웹 프레임워크·DB 드라이버 등 상세 구현체

의존성 규칙이 전부다: 소스코드 의존성은 반드시 안쪽으로만 향하고, 안쪽 원은 바깥쪽 원의 존재조차 몰라야 한다. 그래서 프레임워크나 DB를 교체해도 핵심 로직은 흔들리지 않는다. 이를 실현하는 수단이 DIP(의존성 역전 원칙) — 구체적인 것이 추상적인 것에 의존하게 만드는 것이다.

같은 계열로 헥사고날(포트&어댑터)·어니언 아키텍처가 있으며, 셋 다 "의존성은 안쪽으로"라는 동일 원리의 변주다.

2. MSA 통신·데이터 관리 패턴

가. Service Discovery — 동적 환경의 전화번호부

클라우드에서 서비스 인스턴스의 IP·포트는 수시로 바뀐다. 이를 관리·탐색하는 것이 Service Discovery이며, 중심에 Service Registry(전화번호부)가 있다.

축	방식	내용
탐색	Client-side	클라이언트가 레지스트리를 직접 조회 (예: Eureka)
탐색	Server-side	로드밸런서가 조회를 대행 (예: AWS ELB)
등록	Self-registration	서비스가 스스로 등록·헬스체크
등록	3rd-party	별도 레지스트라가 대신 등록

쿠버네티스 환경에서는 DNS 기반 디스커버리가 플랫폼에 내장돼 있어, 별도 레지스트리 구축 부담이 줄었다.

나. CQRS — 명령과 조회의 책임 분리

CQRS — 쓰기/읽기 분리와 이벤트 동기화

상태를 변경하는 명령(Command: 등록·수정·삭제)과 정보를 읽는 조회(Query)의 책임을 분리한다. 두음은 "명·조 분리"다.

효과는 읽기·쓰기 각각에 최적화된 DB를 따로 쓸 수 있다는 것(Polyglot Persistence) — 쓰기는 정합성 좋은 RDB, 읽기는 빠른 NoSQL·검색엔진 식이다. 대가는 두 저장소를 Kafka·CDC 등 이벤트로 동기화해야 하고, 그 사이에 지연(최종 일관성)이 생긴다는 것이다.

시험 함정 하나 — CQRS와 Event Sourcing은 별개 개념이다. 자주 결합되지만, CQRS는 책임 분리이고 Event Sourcing은 상태를 이벤트 로그로 저장하는 방식이다.

다. Saga 패턴 — 분산 트랜잭션의 현실해

먼저 왜 2단계 커밋(2PC)이 MSA에서 안 되는지부터. 2PC는 코디네이터가 단일 장애점(SPOF)이 되고, 합의가 끝날 때까지 모든 참여자가 락을 쥐고 기다려 가용성이 무너진다. 서비스가 수십 개인 분산 환경에서는 감당이 안 된다.

Saga는 접근을 뒤집는다 — 락으로 막는 대신, 일단 진행하고 실패하면 되돌린다. 그래서 보장하는 것은 강한 일관성이 아니라 최종 일관성(Eventual Consistency)이다.

Saga 두 방식 + 보상 트랜잭션

구분	Choreography(안무형)	Orchestration(지휘형)
방식	서비스 간 이벤트 교환으로 연쇄 수행	중앙 Orchestrator가 순서 지휘
장점	느슨한 결합	흐름의 중앙 가시화
단점	전체 흐름 파악 어려움	오케스트레이터 관리 부담
적합	단순 시나리오	복잡·긴 시나리오

두 방식 공통의 필수 요소가 보상 트랜잭션(Compensating Transaction)이다. 중간 단계가 실패하면 이미 완료된 앞 단계들을 역순으로 취소한다 — 배송 실패 시 결제 취소, 주문 취소로 거슬러 올라가는 식이다.

3. 기술사적 제언

첫째, '마이크로'와 '클린'은 상호 보완이다. MSA로 서비스를 나누는 것(서비스 사이의 분리)과 각 서비스 내부를 클린 아키텍처로 짓는 것(서비스 안의 분리)을 결합하면, 서비스 교체도 프레임워크 변경도 쉬워진다. 답안에서 "경계는 두 겹"이라는 구도로 서술하면 차별화된다.

둘째, Saga의 복잡도 비용을 먼저 계산하라. Saga는 일관성 문제를 풀어주지만 보상 트랜잭션의 설계·테스트 복잡도가 매우 높다. 도입 전에 물어야 할 질문은 기술이 아니라 비즈니스다 — "이 업무가 최종 일관성을 허용하는가?" 계좌이체처럼 즉시 일관성이 필수인 도메인이라면 서비스 경계 자체를 다시 그어 한 서비스 안의 로컬 트랜잭션으로 만드는 게 정답일 수 있다. 금융 코어 시스템에서 MSA 분해가 신중해야 하는 이유가 바로 이것이다.

셋째, CQRS는 병목이 확인된 뒤에. 조회 성능 병목이 실측된 시점에 도입해야 한다. 조기 도입은 동기화 지연 문제로 복잡도만 키운다 — "미래를 위해 미리"는 CQRS에서 통하지 않는 격언이다.

종합하면, 세 패턴은 공짜가 아니다. Discovery는 레지스트리 운영을, CQRS는 동기화 지연을, Saga는 보상 설계를 대가로 요구한다. 패턴 선택의 본질은 기능이 아니라 트레이드오프의 수락이다.

마치며 — 핵심 요약

클린 아키텍처는 코드 안에서, MSA 패턴은 서비스 사이에서 "변하는 것과 변하지 않는 것"을 분리한다. 의존성은 안쪽으로, 명령과 조회는 갈라서, 분산 트랜잭션은 보상으로 — 그리고 모든 패턴은 트레이드오프의 가격표가 붙어 있다.

기술사 핵심 암기 포인트

클린 아키 계층: 엔·유·인·프 / 의존성 규칙: 안쪽으로만, 수단은 DIP
같은 계열: 헥사고날(포트&어댑터)·어니언
Discovery: 탐색(Client/Server-side) × 등록(Self/3rd-party), K8s는 DNS 내장
CQRS: 명·조 분리, Polyglot Persistence, CQRS ≠ Event Sourcing
Saga: 코·오 (Choreography·Orchestration) + 보상 트랜잭션 필수
2PC 부적합 근거: 코디네이터 SPOF + 락 장기 유지
답안 키워드: DIP, Boundary, Service Registry, Eventual Consistency, Compensating Transaction, CDC
실무 연결: 즉시 일관성 필수 도메인(계좌이체)은 Saga보다 경계 재설계, CQRS는 병목 실측 후

예상 문제

(10점) 클린 아키텍처의 4계층과 의존성 규칙을 설명하시오.
(25점) MSA 분산 트랜잭션에서 2PC의 한계를 설명하고, Saga 패턴의 두 방식(Choreography·Orchestration)과 보상 트랜잭션을 비교 논하시오.

MSA·DDD·SAGA의 전체 지형은 소프트웨어 아키텍처 패턴과 MSA·DDD에서 다룬다 — 이 글은 그 심화편이다.

Clean Code 문화와 리팩토링·TDD는 소프트웨어 재사용과 현대 개발 기법에서 이어서 볼 수 있다.

더 다뤘으면 하는 주제는 댓글로 남겨주세요.

무너진 성을 다시 세운 것은 기록이었다 — 제조AI 2030, 명장의 암묵지를 기록하는 나라

정보관리기술사의 노트 — Wed, 8 Jul 2026 10:07:46 +0900

무너진 성을 다시 세운 것은 기록이었다

수원 화성에 가보신 적이 있으신가요?

지금 우리가 걷는 그 성곽은, 사실 한 번 무너졌던 성입니다. 일제강점기와 전쟁을 지나며 화성은 곳곳이 허물어졌습니다. 그런데 1970년대, 사람들은 이 성을 거의 원형 그대로 다시 세웠습니다. 기적 같은 복원이 가능했던 이유는 단 하나였습니다. 『화성성역의궤』. 성을 쌓을 때 쓴 돌의 크기부터 일꾼의 품삯까지, 축성의 모든 과정을 적어둔 기록이 남아 있었기 때문입니다.

조선은 나라의 큰일을 치를 때마다 의궤를 남겼습니다. 언젠가 같은 일을 다시 해야 할 후대를 위해서였지요. 기록이 있으면, 무너져도 다시 세울 수 있다. 그것이 의궤의 철학이었습니다.

지난 6월 말, 정부가 발표한 「제조AI 2030 전략」을 읽다가 저는 문득 이 오래된 기록물을 떠올렸습니다.

사라지는 손들

대한민국 제조업은 지금 조용한 위기를 지나고 있습니다. 인구는 줄고, 경쟁은 사나워지고, 그리고 무엇보다 — 공장을 지켜온 손들이 은퇴하고 있습니다.

반도체, 조선, 자동차. 이 나라가 세계와 겨뤄온 힘의 상당 부분은 도면에 적히지 않은 곳에 있었습니다. 쇳물 색만 보고 온도를 아는 눈, 기계 소리만 듣고 이상을 짚어내는 귀. 수십 년 현장에서 몸으로 익힌, 말로는 다 설명되지 않는 지식. 업계는 이것을 암묵지(暗默知)라 부릅니다.

문제는 암묵지가 사람과 함께 떠난다는 것입니다. 명장이 정년을 맞아 공장 문을 나서는 순간, 그의 머릿속 수십 년치 노하우도 함께 퇴근합니다. 그리고 다시 출근하지 않습니다. 도제가 어깨너머로 배우던 시대라면 그 지식은 다음 세대의 손으로 건너갔겠지만, 배울 사람 자체가 줄어드는 시대에는 건너갈 다리가 없습니다.

무너지고 있는 것은 성곽이 아니라, 기억입니다.

국가가 짓는 도서관

이번 전략에서 제 눈을 가장 오래 붙든 대목은 화려한 기술 이름들이 아니었습니다. 은퇴를 앞둔 제조명장의 노하우를 데이터로 변환해 수집하겠다는, 어찌 보면 소박한 한 줄이었습니다.

정부는 이렇게 모은 데이터를 담을 "국가 제조데이터 라이브러리"를 세우겠다고 합니다. 부처마다 흩어져 있던 제조데이터를 한곳에 모으고, 해외로 새어 나가지 않도록 지키고, 기업끼리 나눠 쓰더라도 누군가의 자산 가치가 훼손되지 않도록 국가가 직접 관리하는 도서관. 2030년까지 민관이 함께 20조 원을 투자해 100조 원 이상의 부가가치를 만들겠다는 계획의 한가운데에, 이 도서관이 있습니다.

저는 이 대목에서 의궤를 다시 생각했습니다. 조선이 의궤를 나라의 이름으로 편찬하고 보관했듯이, 이제 이 나라는 제조업의 의궤를 국가의 이름으로 쓰겠다고 나선 셈입니다. 개별 기업의 서고가 아니라 나라의 서고에, 사라지기 전의 기억을 옮겨 적는 일. 기초를 다지고, 고도화하고, 지역으로 퍼뜨리고, 생태계를 만든다는 네 단계의 긴 여정이 모두 이 첫 번째 기록 위에 서 있습니다.

이번 기록의 독자는 사람이 아니다

그런데 이 새로운 의궤에는 옛것과 결정적으로 다른 점이 하나 있습니다.

화성성역의궤의 독자는 200년 뒤의 사람이었습니다. 사람이 읽고, 사람이 해석해서, 사람의 손으로 성을 다시 쌓았지요. 하지만 제조데이터 라이브러리의 첫 번째 독자는 사람이 아닙니다. 인공지능입니다.

정부는 이 기록을 읽고 배운 AI로 제조업 전반을 이해하는 "제조AI 파운데이션 모델"을 만들고, 나아가 AI와 로봇이 스스로 판단하며 공장을 돌리는 "풀스택 AI팩토리"를 수출 상품으로 키우겠다고 합니다. 전국 산업단지를 AI 산업단지로 바꾸는 구상에는 M.AX라는 이름이 붙었습니다. 명장의 손끝에서 데이터로, 데이터에서 모델로, 모델에서 다시 현장의 기계 팔로. 기억이 이렇게 긴 여행을 하게 되는 것입니다.

물론 쉬운 길은 아닐 것입니다. 쇳물 색을 읽던 눈빛을 몇 테라바이트의 데이터로 옮기는 일이 계획서의 문장만큼 매끄러울 리 없습니다. 암묵지가 암묵지인 이유는, 애초에 적기 어렵기 때문이니까요. 그럼에도 이 시도가 의미 있는 것은, 적어도 이 나라가 무엇이 사라지고 있는지를 정확히 알고 있다는 증거이기 때문입니다.

에필로그 — 기록되지 않은 것은 복원되지 않는다

화성이 다시 서고 나서야 우리는 의궤의 가치를 알았습니다. 기록할 당시의 조선 사람들은 몰랐을 것입니다. 그 꼼꼼한 문서가 200년 뒤 무너진 성을 일으켜 세우리라는 것을.

지금 우리가 쓰기 시작한 제조업의 의궤도 마찬가지일지 모릅니다. 이 기록의 진짜 가치는 2030년이 아니라, 마지막 명장이 공장 문을 나선 한참 뒤에야 드러날 것입니다. 그때 이 나라의 공장들이 여전히 그 손끝의 기억으로 돌아가고 있다면, 우리는 늦지 않게 적어두었던 것입니다.

기록되지 않은 것은 복원되지 않습니다.

당신의 현장에서는 지금, 무엇이 기록되지 못한 채 퇴근하고 있습니까?