모듈 구현 & 테스트
목차 16
12강이 DB 서버 안에 저장해 자동·반복 실행하는 SQL 프로그램이었다면, 13강은 따로 만든 여러 모듈을 인터페이스로 합쳐 한 시스템으로 굴리고(통합 구현), 제대로 도는지 검증하는(테스트) 단원이다. 분량은 길어 보여도 확실한 점수밭은 셋 — EAI 4유형 매칭(포허메하), 단위 vs 통합(단=내·통=외), 화이트 vs 블랙박스(화블=내외). 모듈 설계(결합도·응집도)와 EAI는 5강·8강에서 본격 다뤘고, 13강은 한 줄 즉답으로 회수한다.
핵심 암기: 통합 구현 5단계 모단통통가 · 모듈 황금률 결↓응↑(5강) · 결합도/응집도 내공외제스자·우논시절통순기(5강) · EAI 4유형 포허메하(8강) · 테스트 4레벨 단통시인 · 단위 vs 통합 단=내·통=외 · xUnit 5종 JJPNR · 화이트 vs 블랙 화블=내외
통합 구현과 모듈
통합 구현과 5단계 흐름 — 모단통통가 ·통합 구현·1순위·
[정의] 통합 구현(Integration Implementation) = 따로 개발된 여러 모듈·시스템을 인터페이스로 연결해 하나의 통합 시스템으로 동작시키는 작업. '부품(모듈) 만들기 + 부품 결합 = 자동차 완성'의 과정. 두 축은 ① 모듈 구현 + ② 인터페이스 통합.
[흐름] 13강 본문 전체가 이 5단계를 따라 흐른다.
① 모듈 구현 → ② 단위 테스트 → ③ 모듈 통합 → ④ 통합 테스트 → ⑤ 시스템 가동
| 단계 | 키워드 | 한 줄 핵심 |
|---|---|---|
| ① 모듈 구현 | 결↓응↑·Fan-In/Out | 모듈 한 개를 잘 만들기 |
| ② 단위 테스트 | 격리·Mock/Stub | 모듈 한 개를 단품으로 검증 (내부) |
| ③ 모듈 통합 | EAI·ESB | 여러 모듈을 인터페이스로 결합 |
| ④ 통합 테스트 | 인터페이스 시나리오 | 합쳐진 모듈이 함께 도는지 검증 (외부) |
| ⑤ 시스템 가동 | 운영 배포 | 사용자에게 서비스 시작 |
🔑 암기 모단통통가 — 모듈 구현·단위 테스트·모듈 통합·통합 테스트·시스템 가동. ⚠️ 함정 단위 테스트가 모듈 통합보다 먼저, 통합 테스트가 시스템 가동보다 먼저. 이 두 순서 뒤집기가 단골. 🎯 빈출 5단계 순서 매칭은 간헐 출제. 모단통통가 다섯 글자가 13강 전체 지도.
모듈과 설계 황금률 — 결↓응↑ ·모듈·1순위·
[정의] 모듈(Module) = 명확한 입력·출력을 갖고 재사용·교체·조합이 가능한 독립 기능 단위. 좋은 모듈인지 가르는 한 줄 정답 = 결합도는 낮게(↓), 응집도는 높게(↑).
| 척도 | 정의 | 황금률 |
|---|---|---|
| 결합도(Coupling) | 모듈 간의 연관 정도 (외부) | 낮을수록 좋음 (느슨한 결합) |
| 응집도(Cohesion) | 모듈 내부 요소들의 연관 정도 | 높을수록 좋음 (한 일에 집중) |
[표] 7단계 전체는 5강에서 본격. 13강은 양 끝점 즉답 매칭만.
| 구분 | 두문자 (방향) | 가장 나쁨 ↔ 가장 좋음 |
|---|---|---|
| 결합도 6단계 | 내공외제스자 (강→약) | 내용(최악) ↔ 자료(최선) |
| 응집도 7단계 | 우논시절통순기 (약→강) | 우연(최악) ↔ 기능(최선) |
🔑 암기 결↓응↑ · (5강 회수) 내공외제스자 "내가 공부 외워서 제일 스마트한 자" · 우논시절통순기 "우리는 논리적인 시대의 절친, 통하는 순간 기적이". ⚠️ 함정 결합도와 응집도는 방향이 정반대 — 둘이 같은 방향이라는 보기는 함정. '결합도가 높을수록 좋다'도 함정(높을수록 좋은 건 응집도). 🎯 빈출 '결합도는 ?·응집도는 ?' 빈칸 + 양 끝점 매칭. 거의 매회. 7단계 전체 나열·보기 단서 매칭은 5강에서. 💡 보충 MSA(Microservice Architecture)가 결↓응↑의 실무 구현 — 도메인별 모듈 분리(응집도↑) + 이벤트 기반 통신(결합도↓). 📝 기출 '결합도·응집도 옳은 것?' → 결합도 낮게·응집도 높게.
Fan-In / Fan-Out ·모듈·
[정의] 모듈 간 호출 관계로 시스템 복잡도를 측정하는 척도. 화살표 방향이 정반대다.
| 척도 | 정의 | 의미 |
|---|---|---|
| Fan-In(팬인) | 그 모듈을 호출하는 상위 모듈 수 | 들어오는 화살표 — 재사용성↑ |
| Fan-Out(팬아웃) | 그 모듈이 호출하는 하위 모듈 수 | 나가는 화살표 — 제어 복잡도↑ (7 이하 권장) |
🔑 즉답 In = 불려옴(재사용) · Out = 불러냄(복잡도). Fan-In 높은 모듈 = 재사용성 좋은 모듈. ⚠️ 함정 '바람직한 설계 = Fan-Out을 높인다'는 오답 — Fan-Out은 낮춰야 한다. 🎯 빈출 구조도를 주고 화살표 세는 계산형. 거의 매회. 본격 풀이는 5강.
EAI 4유형 — 포허메하 ·모듈 통합·1순위·
[정의] EAI(Enterprise Application Integration) = 기업 내 흩어진 여러 애플리케이션을 미들웨어(중간자)로 통합. N개를 1대1로 직접 연결하면 N(N-1)/2로 폭발하는 연결을 중간자 하나로 N개로 정리한다.
| 시스템 수 | 1대1 직접 연결 수 |
|---|---|
| 5개 | 10개 |
| 10개 | 45개 |
| 100개 | 4,950개 (카오스) |
[분류] EAI 4유형 — 8강에서 본 포허메하의 1슬라이드 회수.
| 유형 | 토폴로지 | 장점 | 단점 |
|---|---|---|---|
| ① 포인트투포인트 | 1:1 직통 | 단순·빠름 (소규모) | N(N-1)/2 폭발 (대규모 부적합) |
| ② 허브앤스포크 | 중앙 허브 | 표준화·중앙 통제 | 허브 장애 = 전체 마비 (SPOF) |
| ③ 메시지버스 | 공용 버스 | 확장성·SPOF 분산 | 메시지 순서·중복 처리 복잡 (비동기) |
| ④ 하이브리드 | 허브 + 버스 혼합 | 유연성·확장성 | 설계 복잡도↑ |
🔑 암기 포허메하 — 포인트투포인트·허브앤스포크·메시지버스·하이브리드. ⚠️ 함정 Hub & Spoke의 약점 = SPOF(단일 장애점). '허브 장애에도 정상 동작'은 100% 함정. '포인트투포인트가 대규모에 적합'도 함정(정반대 — 소규모만). 🎯 빈출 4유형 토폴로지 매칭이 모듈 통합 1순위. 본격 비교·등장 배경은 8강. 📝 기출 'EAI 4유형이 아닌 것?'·'Hub & Spoke 특징?'.
EAI vs ESB — 앱 통합 vs 표준 기반 ·모듈 통합·
[정의] ESB(Enterprise Service Bus) = 표준(SOAP·REST·XML·JSON) 기반으로 서비스 단위 통합을 제공하는 미들웨어. 메시지 라우팅·변환·보장을 자동 처리. SOA(Service Oriented Architecture)의 핵심 인프라이자 EAI의 진화형.
| 비교 축 | EAI | ESB |
|---|---|---|
| 통합 단위 | 애플리케이션 단위 | 서비스 단위 (SOA 친화) |
| 표준 의존도 | 솔루션 종속 (벤더별 상이) | 표준 기반 (SOAP·REST·XML/JSON) |
| 메시지 변환 | 어댑터로 처리 | 자동 (라우팅·변환·보장 내장) |
| 결합 | Hub & Spoke 위주 | 느슨한 결합·유연한 확장 |
🔑 암기 EAI = 애플리케이션 통합 / ESB = 표준 기반 서비스 통합(SOA). ESB = '통역사 갖춘 우체국'(변환·라우팅·보장까지). ⚠️ 함정 'EAI가 표준 기반·SOA·서비스 단위'는 함정 — 그건 ESB 성질. 'EAI ≠ ESB 완전히 다른 기술'도 함정 — 둘은 진화 관계. 🎯 빈출 '표준·SOA·느슨한 결합·서비스 단위' 키워드 → ESB 즉답. 📝 기출 'EAI와 ESB의 차이로 옳은 것?'.
애플리케이션 테스트
테스트 4레벨 — 단통시인 ·테스트·
[흐름] 통합 구현의 검증 단계는 작은 단위에서 큰 단위로 올라가는 4레벨 구조(V모델 좌→우).
| 레벨 | 검증 대상 | 한 줄 핵심 |
|---|---|---|
| ① 단위 테스트 | 모듈 한 개 (단품) | 격리해 단품 검증 |
| ② 통합 테스트 | 모듈 간 인터페이스 | 합친 모듈의 결합 검증 |
| ③ 시스템 테스트 | 시스템 전체 | 성능·보안·부하 종합 검증 |
| ④ 인수 테스트 | 고객 관점 (알파·베타) | 고객이 써보고 인수 결정 |
🔑 암기 단통시인 — 단위·통합·시스템·인수. 🎯 빈출 4레벨 순서 매칭이 단골. '단위 다음은 통합'·'시스템 다음은 인수'. 13강은 앞 두 레벨(단위·통합)을 본격 다루고, 시스템·인수 테스트는 17강에서 자세히.
단위 테스트 — 단품·격리 ·단위·1순위·
[정의] 단위 테스트(Unit Test) = 모듈 한 개를 단품으로, 다른 모듈·외부 의존(DB·네트워크·파일)과 격리해 그 모듈만 잘 도는지 검증. 핵심 한 단어는 격리(isolation).
| 본질 | 한 줄 설명 |
|---|---|
| ① 단품 | 모듈 한 개만 검증 (여러 모듈 결합 X) |
| ② 격리 | 외부 의존 차단·가짜 대역(Mock/Stub) 사용 |
| ③ 빠름 | 외부 의존이 없어 매우 빠름 (수 ms) |
| ④ 자동화 친화 | CI 파이프라인 자동 실행·머지 차단 조건 |
🔑 즉답 '모듈 한 개 + 단품 + 격리 + 외부 의존 차단' → 단위 테스트. ⚠️ 함정 '단위 테스트는 여러 모듈을 결합해 인터페이스를 검증한다'는 함정 — 그건 통합 테스트의 일. 🎯 빈출 단위 테스트 정의 식별. 단 = 단품 / 통 = 결합. 📝 기출 '단위 테스트의 정의로 옳은 것?'.
xUnit 5종 — JJPNR ·단위·
[정의] 단위 테스트를 도와주는 언어별 프레임워크. 모두 켄트 벡(SUnit) 계보의 xUnit 패턴 계열.
| 약자 | 도구 | 언어 |
|---|---|---|
| J | JUnit | Java (xUnit 대표) |
| J | Jest | JavaScript (React 친화) |
| P | PyTest | Python |
| N | NUnit | .NET (C#) |
| R | RSpec | Ruby (BDD 스타일) |
[흐름] xUnit 공통 구조 4단계:
Setup → 테스트 환경 준비
Exercise → 대상 코드 실행
Verify → 결과 검증 (assert)
Teardown → 환경 정리
🔑 암기 JJPNR — JUnit·Jest·PyTest·NUnit·RSpec. (즉답) JUnit = Java. ⚠️ 함정 'JUnit은 Python 단위 테스트 프레임워크'는 100% 함정 — JUnit은 Java, Python은 PyTest. 🎯 빈출 도구·언어 매칭은 간헐 출제. JUnit = Java 단골 정답.
Mock vs Stub ·단위·
[정의] 단위 테스트의 '격리'를 가능하게 해주는 가짜 대역 배우(Test Double). 외부 의존(DB·API·외부 모듈)을 대신한다.
| 구분 | Stub | Mock |
|---|---|---|
| 주 역할 | 고정된 응답을 돌려줌 | 호출 검증 (어떻게 불렸는지) |
| 검증 대상 | 상태 검증 (결과) | 행위 검증 (호출 횟수·인자) |
| 한 줄 | "응답만 돌려주는 가짜 부품" | "호출 기록까지 남기는 가짜 부품" |
🔑 암기 행위 검증·호출 기록 = Mock / 고정 응답·상태 검증 = Stub. ⚠️ 함정 Driver는 상향식 통합 테스트의 가짜 호출자(단위 도구 아님), Fixture는 테스트 데이터·환경 세팅(가짜 부품 분류 아님). 보기에 섞이면 Mock vs Stub 분별만 보면 된다. 🎯 빈출 '행위·호출 횟수 기록' → Mock / '정해진 응답' → Stub. 📝 기출 '호출 횟수·인자 행위를 검증하는 Test Double?' → Mock.
통합 테스트 — 결합·인터페이스 ·통합·
[정의] 통합 테스트(Integration Test) = 단위 테스트를 통과한 여러 모듈을 결합해, 모듈 간 인터페이스가 약속대로 도는지 검증. 단위가 격리였다면, 통합은 결합 검증.
| 본질 | 한 줄 설명 |
|---|---|
| ① 결합 | 여러 모듈을 결합해 검증 |
| ② 인터페이스 중심 | 모듈 간 약속·메시지 형식·호출 순서 검증 |
| ③ 실제 의존 | 가능한 한 실제 DB·실제 API 사용 (Mock 최소화) |
| ④ 단위 다음 단계 | 단위 테스트 모두 통과 후 진행 |
🔑 즉답 '여러 모듈 결합 + 인터페이스 검증' → 통합 테스트. ⚠️ 함정 단위와 결정적 차이는 격리(단위) vs 결합(통합) 한 줄. 🎯 빈출 통합 테스트 정의 식별. 💡 보충 통합 시 아직 안 만든 모듈을 대신하는 가짜 — 스텁(하향식·하위 모듈 대역)·드라이버(상향식·상위 호출자 대역). 합쳐가는 순서(하향식·상향식)는 18강에서 본격.
단위 vs 통합 — 단=내·통=외 ·단위 vs 통합·1순위·
[정의] 13강 시험장 최고의 무기. 단위 테스트 = 모듈 내부 격리 / 통합 테스트 = 모듈 외부 결합(인터페이스).
| 비교 축 | 단위 테스트(Unit) | 통합 테스트(Integration) |
|---|---|---|
| 검증 대상 | 모듈 한 개 | 여러 모듈 결합 |
| 초점 | 모듈 내부 로직 | 모듈 외부 인터페이스 |
| 외부 의존 | 차단 (Mock/Stub) | 실제 사용 (가능한 한) |
| 속도 | 매우 빠름 (수 ms) | 상대적으로 느림 (수백 ms~수 s) |
| 순서 | 먼저 (개발자 PR 단위) | 통합 단계에서 (CI 게이트) |
🔑 암기 단=내·통=외 · (회수) 단위=Mock·통합=실제. ⚠️ 함정 '단위 테스트 = 외부 의존 실제 사용'은 100% 함정(단위는 격리·차단). '통합 테스트 = 단품 검증'도 100% 함정(통합은 결합). 둘 다 정반대. 🎯 빈출 두 축을 뒤바꾼 보기가 단골. 단=내·통=외 두 단어 매칭으로 즉답. 📝 기출 단위·통합 정의를 뒤바꾼 함정 보기로 출제.
화이트박스 vs 블랙박스 — 화블=내외 ·테스트 기법·
[정의] 화이트박스 = 안을 봄(내부 구조·코드) / 블랙박스 = 결과만 봄(입력→출력, 내부 모름). 앞의 단=내·통=외와 한 쌍 — 둘 다 '내부'가 화이트·단위 쪽.
| 비교 축 | 화이트박스(White Box) | 블랙박스(Black Box) |
|---|---|---|
| 시야 | 내부 구조·코드 본다 | 외부 결과만 본다 |
| 별칭 | 구조 기반 테스트 | 명세 기반 테스트 |
| 대표 기법 | 문장·분기·조건·경로 커버리지 | 동등 분할·경계값·결정 테이블·원인-결과 |
| 적용 단계 | 주로 단위 테스트 | 주로 통합·시스템·인수 |
🔑 암기 화블=내외 — 화이트=내부·블랙=외부. '엔진 분해 검사(화이트) vs 시동·주행 검사(블랙)'. ⚠️ 함정 '화이트박스는 결과만, 블랙박스는 내부 구조를 본다'는 거꾸로 함정. 별칭도 뒤바꾸기 단골(화이트=구조 기반). 🎯 빈출 '내부 vs 결과' 한 줄 분별. 화이트박스 커버리지 4종·블랙박스 6기법은 18강에서 본격. 📝 기출 '화이트박스와 블랙박스의 차이로 옳은 것?'.
기출 다지기
[기출 1 출제] 다음 중 EAI의 4가지 구축 유형에 해당하지 않는 것은? (개념 분류·아닌 것 고르기)
- ① Point-to-Point
- ② Hub & Spoke
- ③ Message Bus
- ④ Pipe & Filter
정답 및 해설 보기
정답 ④
EAI 4유형은 포허메하 넷뿐 — 포인트투포인트·허브앤스포크·메시지버스·하이브리드. Pipe & Filter는 소프트웨어 아키텍처 패턴이지 EAI 구축 유형이 아니다. 빠진 건 하이브리드.
| 선지 | 판정 | 근거 |
|---|---|---|
| ① Point-to-Point | 오답 | EAI 4유형 — 1:1 직접 연결 |
| ② Hub & Spoke | 오답 | EAI 4유형 — 중앙 허브 (SPOF 약점) |
| ③ Message Bus | 오답 | EAI 4유형 — 공용 버스 비동기 |
| ④ Pipe & Filter | 정답 | 소프트웨어 아키텍처 패턴 — EAI 아님 |
🔑 포허메하 네 글자에 없으면(Pipe & Filter·MVC·Layered 등) 그게 정답.
[기출 2 출제] EAI의 Hub & Spoke 방식의 특징으로 옳은 것은? (옳고 그름·옳은 설명 고르기)
- ① 시스템 간 1:1 직접 연결을 사용한다
- ② 중앙 허브를 통해 모든 메시지가 라우팅되며, 허브 장애 시 전체 통신이 마비될 수 있다
- ③ 메시지 버스에 메시지를 비동기로 올린다
- ④ 허브와 버스를 혼합 운영해 그룹 간 통신을 효율화한다
정답 및 해설 보기
정답 ②
Hub & Spoke의 정체성은 '중앙 허브 라우팅' + '허브 장애 시 전체 마비(SPOF)' 두 키워드의 교집합. 나머지 보기는 다른 세 유형의 성질이다.
| 선지 | 판정 | 근거 |
|---|---|---|
| ① | 오답 | 1:1 직접 연결은 포인트투포인트 |
| ② | 정답 | 중앙 허브 + SPOF — Hub & Spoke 본질 |
| ③ | 오답 | 비동기 공용 버스는 메시지버스 |
| ④ | 오답 | 허브 + 버스 혼합은 하이브리드 |
🔑 'Hub & Spoke는 허브 장애에 영향받지 않는다'는 100% 함정. 약점은 SPOF — 실무는 허브 다중화로 방어.
[기출 3 출제] EAI와 ESB의 차이에 대한 설명으로 옳은 것은? (옳고 그름·옳은 설명 고르기)
- ① EAI는 표준 기반·서비스 단위 통합이고, ESB는 애플리케이션 단위 통합이다
- ② ESB는 표준 기반(SOAP·REST 등)과 SOA 친화·서비스 단위 통합을 지원한다
- ③ ESB는 EAI보다 단순한 1:1 연결만 제공한다
- ④ EAI는 메시지 라우팅·변환·보장을 표준으로 자동 제공한다
정답 및 해설 보기
정답 ②
ESB의 결정적 특징은 '표준 기반 + SOA 친화 + 서비스 단위 + 라우팅·변환·보장 자동'. ①③④는 EAI와 ESB의 성질을 거꾸로 적은 함정.
| 선지 | 판정 | 근거 |
|---|---|---|
| ① | 오답 | 표준·서비스 단위는 ESB 성질 (거꾸로) |
| ② | 정답 | ESB = 표준 기반 + SOA + 서비스 단위 |
| ③ | 오답 | ESB는 EAI의 진화형 — 단순 1:1만 제공 아님 |
| ④ | 오답 | 라우팅·변환·보장 자동은 ESB 성질 (EAI 아님) |
🔑 '표준·SOA·서비스 단위·자동 변환' 키워드 → ESB. EAI는 애플리케이션 단위 통합.
[기출 4 출제] 단위 테스트(Unit Test)의 정의로 옳은 것은? (개념 식별·옳은 설명 고르기)
- ① 여러 모듈을 결합해 모듈 간 인터페이스가 약속대로 동작하는지 검증한다
- ② 모듈 한 개를 단품으로, 외부 의존을 격리한 채 그 모듈만 잘 도는지 검증한다
- ③ 시스템 전체를 부하·보안·성능 측면에서 종합 검증한다
- ④ 고객이 실제 환경에서 사용해보며 인수 여부를 결정한다
정답 및 해설 보기
정답 ②
네 보기가 정확히 테스트 4레벨(단통시인)을 한 줄씩 정의한 것. 단위 테스트는 '단품 + 격리 + 내부'다.
| 선지 | 판정 | 근거 |
|---|---|---|
| ① | 오답 | 통합 테스트 — 여러 모듈 결합·인터페이스 |
| ② | 정답 | 단위 테스트 — 단품·격리·내부 |
| ③ | 오답 | 시스템 테스트 — 부하·보안·성능 |
| ④ | 오답 | 인수 테스트 — 고객 환경·인수 결정 |
🔑 단=내·통=외. '단위 = 여러 모듈 결합 검증'은 통합 테스트의 정의를 가져다 붙인 함정.
[기출 5 출제] 화이트박스 테스트와 블랙박스 테스트의 차이로 옳은 것은? (옳고 그름·옳은 설명 고르기)
- ① 화이트박스는 결과만 검증하고, 블랙박스는 내부 구조를 검증한다
- ② 화이트박스는 명세 기반이고, 블랙박스는 구조 기반이다
- ③ 화이트박스는 내부 구조·코드를 보고 검증하고, 블랙박스는 입력→출력 결과만 검증한다
- ④ 화이트박스는 인수 테스트에 주로 쓰이고, 블랙박스는 단위 테스트에 주로 쓰인다
정답 및 해설 보기
정답 ③
화이트 vs 블랙은 '내부 vs 외부' 한 줄 분별. 화이트 = 내부 구조(구조 기반·주로 단위) / 블랙 = 결과만(명세 기반·주로 통합 이상).
| 선지 | 판정 | 근거 |
|---|---|---|
| ① | 오답 | 키워드 거꾸로 — 화이트가 결과만 / 블랙이 내부 |
| ② | 오답 | 별칭 거꾸로 — 화이트=구조 기반 / 블랙=명세 기반 |
| ③ | 정답 | 화이트=내부 구조·코드 / 블랙=입력→출력 결과 |
| ④ | 오답 | 적용 단계 거꾸로 — 화이트=주로 단위 / 블랙=주로 통합·인수 |
🔑 화블=내외. 단=내·통=외와 한 쌍 — 화이트·단위가 둘 다 '내부'.
[기출 6 출제] 단위 테스트에서 외부 의존(DB·API·외부 모듈)을 대신하는 가짜 부품(Test Double) 중, 호출 횟수·인자 등 행위를 검증하는 데 쓰이는 것은? (개념 식별·매칭)
- ① Stub
- ② Mock
- ③ Driver
- ④ Fixture
정답 및 해설 보기
정답 ②
'가짜 부품' + '호출 횟수·인자 행위 검증' 두 키워드의 교집합은 Mock 하나. Stub은 고정 응답·상태 검증이라 호출 기록을 남기지 않는다.
| 선지 | 판정 | 근거 |
|---|---|---|
| ① Stub | 오답 | 고정 응답·상태 검증 — 호출 기록 X |
| ② Mock | 정답 | 행위 검증·호출 횟수·인자 기록 |
| ③ Driver | 오답 | 상향식 통합 테스트의 가짜 호출자 |
| ④ Fixture | 오답 | 테스트 데이터·환경 세팅 — 가짜 부품 분류 아님 |
🔑 행위 검증·호출 기록 = Mock / 고정 응답·상태 검증 = Stub.
[기출 7 출제] 모듈의 결합도와 응집도에 대한 설명으로 옳은 것은? (옳고 그름·옳은 설명 고르기)
- ① 결합도는 높을수록, 응집도는 낮을수록 좋은 모듈이다
- ② 결합도는 낮을수록, 응집도는 높을수록 좋은 모듈이다
- ③ 가장 강한 결합도는 자료 결합도이고, 가장 약한 응집도는 기능적 응집도이다
- ④ 결합도와 응집도는 같은 척도로 양쪽 모두 높을수록 좋다
정답 및 해설 보기
정답 ②
모듈 설계 황금률 결↓응↑ 그대로. 결합도는 낮게, 응집도는 높게가 좋은 모듈이다.
| 선지 | 판정 | 근거 |
|---|---|---|
| ① | 오답 | 거꾸로 — 결합도 높음·응집도 낮음은 최악 |
| ② | 정답 | 결↓응↑ — 결합도 낮게·응집도 높게 |
| ③ | 오답 | 양 끝점 거꾸로 — 가장 강한 결합도는 내용, 가장 약한 응집도는 우연적 |
| ④ | 오답 | 둘은 방향성이 정반대인 다른 척도 |
🔑 결↓응↑. 양 끝점 — 결합도는 내용(최악)↔자료(최선), 응집도는 우연(최악)↔기능(최선).
한 장 요약
| 영역 | 핵심 | 암기팁 |
|---|---|---|
| 통합 구현 5단계 | 모듈 구현→단위→모듈 통합→통합→시스템 가동 | 모단통통가 |
| 모듈 황금률 | 결합도 낮게·응집도 높게 | 결↓응↑ |
| 결합도/응집도 양 끝 | 내용(최악)↔자료(최선) / 우연(최악)↔기능(최선) | 내공외제스자·우논시절통순기 (5강) |
| Fan-In/Out | In=호출되는 수(재사용)·Out=호출하는 수(복잡도) | In=재사용·Out=복잡도 |
| 영역 | 핵심 | 암기팁 |
|---|---|---|
| EAI 4유형 | 포인트투포인트·허브앤스포크(SPOF)·메시지버스·하이브리드 | 포허메하 (8강) |
| EAI vs ESB | EAI=애플리케이션 통합 / ESB=표준 기반 서비스 통합(SOA) | EAI앱·ESB표준 |
| 테스트 4레벨 | 단위→통합→시스템→인수 | 단통시인 |
| 단위 vs 통합 | 단위=내부 격리(Mock) / 통합=외부 결합(실제) | 단=내·통=외 |
| xUnit 5종 | JUnit(Java)·Jest·PyTest·NUnit·RSpec | JJPNR |
| Mock vs Stub | Mock=행위 검증 / Stub=고정 응답 | 행위=Mock·응답=Stub |
| 화이트 vs 블랙 | 화이트=내부 구조(구조 기반) / 블랙=결과(명세 기반) | 화블=내외 |
🎯 합격 한 끗: 매 회차 점수밭 셋 = EAI 4유형 매칭(포허메하) + 단위 vs 통합(단=내·통=외) + 화이트 vs 블랙박스(화블=내외). 단골 함정 5종 = 'EAI 4유형에 Pipe & Filter 포함'(→포허메하만), 'Hub & Spoke는 SPOF 없음'(→약점이 SPOF), 'EAI가 표준·SOA·서비스 단위'(→그건 ESB), '단위 테스트가 모듈 결합 검증'(→통합), '화이트박스가 결과만 본다'(→거꾸로, 화블=내외). 여덟 두문자(모단통통가·결↓응↑·내공외제스자·우논시절통순기·포허메하·단통시인·JJPNR·단=내·통=외) + 화블=내외가 손에 박히면 13강은 거뜬.
