HeoBrain AI · DEV · GROWTH

HEO BRAIN · DEV LAB

배운 것을 구조화하고,
실제로 작동하게 만듭니다.

AI, 코딩, 영어, 포트폴리오를 직접 공부하고 만들며 얻은 지식을 누구나 다시 써먹을 수 있게 정리합니다.

heobrain.workflow LIVE
01 collect(experience) 02 structure(knowledge) 03 ship(something useful)

LATEST NOTES

최근에 정리한 글

모든 글 보기

Day14)정보처리기사_필기-애플리케이션 설계, 인터페이스 설계

이 글의 목차 펼치기

정처기 공부 기록 · Day 14

결합도부터 객체지향·디자인 패턴까지

오늘은 모듈을 잘 나누는 기준인 결합도·응집도를 출발점으로, 객체지향의 핵심 개념과 설계 원칙, 방법론, 디자인 패턴까지 한 흐름으로 정리했다. 용어가 많아도 “왜 나누는가”를 중심에 두면 연결된다.

오늘 공부한 내용

이번 글에서 정리한 세부 항목: 결합도 6가지와 권리 전도 현상, 응집도, 객체지향 구성요소·기법, SOLID 원칙, 객체지향 방법론, GoF 디자인 패턴 23가지.

1. 결합도(Coupling): 모듈 사이의 의존 정도

결합도는 모듈과 모듈이 서로 얼마나 강하게 연결되어 있는지를 뜻한다. 한 모듈의 변경이 다른 모듈까지 연쇄적으로 흔들리면 결합도가 높은 상태다. 유지보수와 테스트를 쉽게 하려면 필요한 정보만 주고받아 결합도는 낮을수록 좋다.

시험 순서 — 강함(나쁨) → 약함(좋음)
내용 → 공통 → 외부 → 제어 → 스탬프 → 자료
암기: “내 공은 외제 스자다”

① 내용 결합도(Content)
다른 모듈의 내부 변수·처리 로직을 직접 참조하거나 수정하는 경우다. 내부 구현이 바뀌면 밖의 모듈도 함께 고쳐야 하므로 가장 강하다.
② 공통 결합도(Common)
여러 모듈이 전역 변수나 공용 데이터를 함께 사용하는 경우다. 값이 어디에서 바뀌었는지 추적하기 어렵다.
③ 외부 결합도(External)
외부 장치, 통신 규약, 파일 형식처럼 외부에서 정해진 인터페이스에 함께 의존하는 경우다. 외부 규격이 바뀌면 관련 모듈도 영향을 받는다.
④ 제어 결합도(Control)
데이터와 함께 플래그·명령값을 넘겨 상대 모듈의 처리 흐름을 결정하게 하는 경우다. 예를 들어 mode=1이면 저장, mode=2이면 삭제하도록 지시하는 식이다.
⑤ 스탬프 결합도(Stamp)
배열·레코드·구조체처럼 자료구조 전체를 전달하는 경우다. 상대 모듈이 일부 필드만 써도 전체 묶음에 의존하게 된다.
⑥ 자료 결합도(Data)
필요한 값만 매개변수로 전달하는 경우다. 내부 구조를 몰라도 되므로 가장 바람직하고 결합도가 약하다.

권리 전도 현상은 제어 결합도와 함께 기억한다. 하위 모듈이 보내는 제어 신호 때문에 상위 모듈의 내부 처리 방식이 결정되는 상황이다. 원래 호출한 쪽이 흐름을 정해야 하는데, 호출받는 쪽의 신호에 끌려가므로 모듈 간 독립성이 떨어진다.

2. 응집도(Cohesion): 모듈 안의 집중도

응집도는 하나의 모듈 내부 요소들이 하나의 목적에 얼마나 잘 모여 있는지를 나타낸다. 결합도와 반대로 높을수록 좋다. 좋은 모듈은 한 가지 일을 분명하게 맡는다.

결약응강 — 결합도는 약하게, 응집도는 강하게. 시험에서 가장 먼저 떠올릴 문장이다.

응집도는 약한 쪽부터 우연적 → 논리적 → 시간적 → 절차적 → 통신적(교환적) → 순차적 → 기능적 순서다. 기능적 응집도는 모듈 안의 모든 요소가 하나의 단일 기능을 위해 움직이는 가장 좋은 상태다.

3. 객체지향의 기본: 객체로 역할을 나누기

객체지향은 데이터와 그 데이터를 다루는 기능을 객체 단위로 묶어, 현실의 역할처럼 프로그램을 구성하는 방식이다. 핵심 구성요소는 클래스, 객체, 메서드, 메시지, 속성이다.

클래스(Class) : 객체를 만들기 위한 설계도

객체(Object) : 클래스로부터 만들어진 실제 대상

메서드(Method) : 객체가 수행하는 동작

메시지(Message) : 객체에게 어떤 동작을 요청하는 전달

속성(Attribute) : 객체가 가진 상태나 데이터

객체지향 기법의 핵심은 캡슐화, 상속, 다형성, 추상화, 정보 은닉이다. 캡슐화는 데이터와 기능을 하나로 묶는 것이고, 정보 은닉은 내부 구현을 밖에 함부로 보여 주지 않는 것이다. 상속은 기존 클래스의 특성을 물려받는 것이며, 다형성은 같은 메시지라도 객체에 따라 다르게 동작하는 성질이다. 추상화는 공통 특징만 뽑아 핵심을 표현하는 과정이다.

4. 객체지향 설계 원칙: SOLID

S · 단일 책임 원칙(SRP) : 클래스는 변경 이유를 하나만 가져야 한다.
O · 개방-폐쇄 원칙(OCP) : 확장에는 열려 있고, 기존 코드 수정에는 닫혀 있어야 한다.
L · 리스코프 치환 원칙(LSP) : 하위 타입은 상위 타입을 대신해도 정상 동작해야 한다.
I · 인터페이스 분리 원칙(ISP) : 사용하지 않는 기능을 강요하는 큰 인터페이스보다, 목적별 작은 인터페이스가 낫다.
D · 의존 역전 원칙(DIP) : 구체적인 구현보다 추상화에 의존한다.

5. 객체지향 방법론과 디자인 패턴

객체지향 방법론은 분석·설계 과정에서 객체를 중심으로 시스템을 모델링하는 접근이다. 시험에서는 럼바우(Rumbaugh), 부치(Booch), Coad-Yourdon, Jacobson, Wirfs-Brock를 함께 정리한다. 특히 럼바우는 객체 모델링, 동적 모델링, 기능 모델링의 객체 모델링 기법(OMT)으로 기억한다.

디자인 패턴은 자주 반복되는 설계 문제의 검증된 해결 구조다. GoF 패턴은 생성 5개, 구조 7개, 행위 11개로 총 23개다. 이름을 외우는 데서 끝내지 말고 “무엇을 만들고, 어떻게 묶고, 어떻게 협력시키는가”로 구분하면 덜 헷갈린다.

생성 패턴(5) : Builder, Prototype, Factory Method, Abstract Factory, Singleton
객체를 어떤 방식으로 생성할지에 초점

구조 패턴(7) : Bridge, Decorator, Facade, Flyweight, Proxy, Composite, Adapter
클래스·객체를 어떻게 조합할지에 초점

행위 패턴(11) : Mediator, Interpreter, Iterator, Template Method, Observer, State, Visitor, Command, Strategy, Memento, Chain of Responsibility
객체 사이의 책임 분담과 통신 방식에 초점

빈출 역할만 먼저 잡아두면 좋다. Observer는 상태 변경을 구독자에게 알리고, Strategy는 알고리즘을 바꿔 끼우며, Memento는 이전 상태를 저장해 되돌린다. Adapter는 호환되지 않는 인터페이스를 연결하고, Facade는 복잡한 하위 시스템의 단순한 창구를 제공하며, Singleton은 객체를 하나만 생성하도록 제한한다.

공부하면서 개인적으로 중요하다고 생각하는 용어

결합도와 응집도
좋은 설계를 판단하는 가장 짧은 기준이다. “모듈 사이는 느슨하게, 모듈 안은 한 목적에 단단하게”라고 이해하면 된다.
제어 결합도와 권리 전도
플래그가 상대 모듈의 세부 동작을 지시하면 의존성이 커진다. 단순히 값을 전달하는 자료 결합도와 구별해야 한다.
캡슐화와 정보 은닉
내부를 직접 건드리지 않고 정해진 인터페이스로만 요청하게 만드는 원리다. 내용 결합도를 피하는 생각과도 이어진다.
SOLID
객체지향 코드를 ‘나중에 고치기 쉽게’ 만드는 다섯 가지 점검표다. 특히 SRP와 OCP는 문제 지문에서 자주 연결된다.

공부하면서 이해하지 못한 용어

외부 결합도와 공통 결합도의 차이
공통 결합도는 여러 모듈이 같은 전역 데이터를 공유하는 경우, 외부 결합도는 외부 규격·장치·프로토콜 같은 외부 인터페이스에 함께 의존하는 경우로 나누어 보자.
스탬프 결합도와 자료 결합도의 차이
구조체·레코드 같은 묶음 전체를 넘기면 스탬프, 꼭 필요한 값만 개별 매개변수로 넘기면 자료 결합도다.
패턴 이름과 실제 역할 연결
23개를 한 번에 외우기보다 생성·구조·행위로 나눈 뒤, Observer·Strategy·Adapter·Facade·Singleton처럼 역할이 선명한 패턴부터 예시와 함께 반복한다.

오늘 공부한것 소회

처음에는 결합도, 응집도, 객체지향, 디자인 패턴이 각각 따로 외워야 하는 목록처럼 보였다. 그런데 모두 ‘변경에 강한 프로그램을 어떻게 만들까’라는 질문으로 이어진다는 점이 보였다. 오늘은 결합도 순서와 결약응강을 확실히 잡고, 다음 복습에서는 각 디자인 패턴을 짧은 상황 예시와 연결해 보려고 한다.

※ 이 글은 제공된 Day14 학습 문서의 범위와 설명을 바탕으로 초보자 복습용으로 재구성했다.

EMAIL NEWSLETTER

새 글을 이메일로 받아보세요

하루 동안 올라온 HeoBrain의 새 글을 매일 오후 8시에 한 통으로 보내드립니다.

인증 이메일의 링크를 눌러야 구독이 완료되며, 언제든 해지할 수 있습니다.

블로그 검색