1강. 객체지향 설계는 왜 필요한가

?1. 이번 강의에서 해결할 문제

요구 하나를 바꿀 때 UI·저장·알림·규칙을 모두 수정한다면 기능 부족보다 경계가 문제입니다. 패턴을 넣기 전에 실제 변경이 어디까지 전파되는지 측정합니다.

✓2. 학습 목표

✓이 강의를 마치면

• 설계 품질을 변경 비용과 검증 범위로 설명합니다.
• 정책·입출력·저장 책임이 섞인 코드를 찾습니다.
• 패턴을 쓰지 않는 단순한 선택도 비교합니다.

◇3. 핵심 개념

객체지향 설계는 클래스를 많이 만드는 일이 아니라 상태와 규칙을 책임 있는 경계에 두는 일입니다. 변경 이유가 다른 코드가 함께 움직이면 결합이 생깁니다. 작은 프로그램은 함수와 값 타입 몇 개가 가장 좋은 설계일 수 있습니다.

먼저 용어를 구분합니다

용어	이 강의에서의 뜻	확인 질문
상태	작업 완료 여부처럼 프로그램이 기억해야 하는 값	이 값은 누가 바꿀 수 있어야 하나요?
책임	한 코드 단위가 맡아야 하는 판단이나 행동	이 규칙이 바뀌면 어느 파일을 고쳐야 하나요?
경계	서로 다른 책임이 만나는 함수·클래스·인터페이스	바깥 구현이 바뀌어도 안쪽 규칙은 그대로인가요?
결합	한 변경이 다른 코드의 수정을 끌고 오는 정도	메일 공급자만 바꿨는데 작업 규칙도 다시 시험해야 하나요?
변경 비용	수정 파일, 다시 돌릴 테스트, 확인할 외부 시스템의 범위	작은 요구 하나를 검증하는 데 무엇을 다시 확인하나요?

객체지향 설계가 필요한 시점은 단지 코드가 길어졌을 때가 아닙니다. 같은 함수가 서로 다른 이유로 반복해서 수정될 때 경계를 나눌 근거가 생깁니다. 반대로 한 번 쓰고 끝나는 짧은 변환 함수에 저장소·알림 인터페이스까지 만들면 구조를 이해하는 비용만 커집니다.

§4. 가장 작은 예제로 문제 찾기

다음 코드는 구조를 진단하기 위한 축약 예시입니다. completeTask를 호출하기 전에는 작업이 진행 중이고, 호출 뒤에는 완료 상태 저장·메일 전송·화면 갱신이 모두 한 번에 일어납니다.

나쁜 초기 구조

void Application::completeTask(int id) {
    tasks_[id].status = "done";
    std::ofstream{"tasks.txt"} << tasks_[id].title;
    EmailSdk::send(userEmail_, "completed");
    ui_.refresh();
}

상태 전이, 저장, 외부 알림, UI가 한 함수에 결합됐습니다. 먼저 Task::complete, Storage::save, Notifier::send라는 책임 후보와 변경 이유를 표로 나눕니다.

코드 한 줄씩 이해하기

1. tasks_[id].status = "done"은 작업의 핵심 상태를 바꿉니다.
2. 파일 출력은 변경 결과를 디스크에 보존합니다.
3. EmailSdk::send는 외부 메일 서비스라는 별도 실패 원인을 만듭니다.
4. ui_.refresh()는 사용자 화면을 다시 그립니다.

네 줄은 순서대로 실행되지만 같은 책임은 아닙니다. 예를 들어 파일 쓰기가 실패했는데 상태만 이미 바뀌었거나, 메일 서버가 느려 UI 갱신까지 늦어질 수 있습니다. 코드가 짧다는 사실만으로 변경 범위가 작은 것은 아닙니다.

새 요구	현재 수정·확인해야 할 곳	분리 뒤 주로 확인할 경계
파일 대신 DB에 저장	completeTask와 전체 완료 흐름	Storage 구현
메일 대신 게임 내 알림	completeTask와 SDK 호출부	Notifier 구현
완료 규칙 변경	UI·저장 코드가 섞인 함수	Task::complete
완료 뒤 화면 표현 변경	핵심 상태 변경 코드까지 재검토	UI 갱신 코드

→5. 코드가 동작하는 이유

현재 코드는 기능은 수행하지만 파일 형식·메일 공급자·UI 중 하나만 바뀌어도 재컴파일과 전체 테스트가 필요합니다. 변경 지도는 추상화할 실제 축을 보여 줍니다.

실행 흐름은 상태 변경 → 저장 → 알림 → UI 갱신입니다. 이 순서를 먼저 적어 두면 무엇을 도메인 규칙으로 유지하고 무엇을 외부 효과로 분리할지 판단할 수 있습니다. 다음 강의의 책임 분리는 이 흐름을 없애는 것이 아니라 각 단계가 누구의 책임인지 드러내는 작업입니다.

!6. 자주 하는 실수와 해결법

!자주 하는 실수

• 클래스 수를 품질로 판단: 변경 영향과 테스트 격리를 봅니다.
• 처음부터 모든 패턴 도입: 실제 두 번째 구현이나 반복 변경이 나타날 때 경계를 추가합니다.
• 작동하니 설계가 충분하다고 판단: 다음 요구를 넣어 수정 파일과 테스트 수를 기록합니다.

✎7. 직접 실습

✎직접 실습

실습 목표

작업 완료 기능의 변경 지도를 만들고, 실제 변경 이유가 다른 책임을 구분합니다.

시작 전 상태

위 completeTask 코드를 새 메모나 실습 파일에 복사합니다. 이 예시는 아직 완성 프로그램이 아니라 설계 진단용 코드이므로, 먼저 각 줄이 만드는 효과를 표로 분석합니다.

1단계: 따라 하기 — 책임 표시

각 줄 옆에 상태 규칙, 저장, 외부 알림, 화면 표현 중 하나를 적습니다. 완료 후 네 책임이 한 함수에 모였는지 확인합니다.

2단계: 바꿔 보기 — 요구 두 개 적용

“파일을 메모리 저장소로 변경”, “메일을 콘솔 알림으로 변경”을 각각 적용한다고 가정하고 수정할 줄과 다시 시험할 동작을 표시합니다. 두 요구가 서로 다른 이유로 같은 함수를 바꾸는지 비교합니다.

3단계: 직접 적용 — 최소 경계 만들기

아직 패턴을 도입하지 말고 completeTaskState, saveTask, sendCompletionNotice처럼 책임 함수만 나눠 보세요. 호출 순서는 Application에 남겨도 됩니다. 각 함수 이름만 읽고 변경 이유를 설명할 수 있어야 합니다.

4단계: 스스로 확인

• 메일 구현만 바꿀 때 상태 변경 코드를 건드리지 않아도 되나요?
• 저장 실패가 발생하면 어느 단계까지 실행됐는지 설명할 수 있나요?
• 한 번만 쓰는 단순 코드에 불필요한 인터페이스를 추가하지 않았나요?
• 수정 파일 수와 다시 확인할 테스트 수를 변경 전후로 기록했나요?

막혔을 때

증상	원인	확인·해결
책임을 클래스 이름으로만 나눔	변경 이유가 아니라 명사만 찾음	“무엇이 바뀔 때 이 코드가 바뀌는가?”를 각 줄에 묻습니다.
인터페이스부터 많이 만듦	실제 교체 축을 확인하지 않음	먼저 함수 분리만 하고 두 번째 구현이 필요한 경계만 추상화합니다.
호출 순서가 사라짐	책임 분리와 흐름 제어를 혼동함	유스케이스를 조정하는 한 함수에 순서를 명시합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 메일 공급자만 바꿨는데 작업 완료 규칙과 UI까지 다시 시험해야 한다면 어떤 설계 신호인가요?
2. 두 번째 저장 구현도 없고 변경 가능성도 낮은 20줄짜리 도구에서 Repository 인터페이스를 만들지 않는 편이 나을 수 있는 이유는 무엇인가요?
3. 나쁜 초기 함수의 네 효과 중 외부 시스템 실패와 무관하게 지켜야 할 핵심 상태 규칙은 무엇인가요?

■9. 핵심 요약

■핵심 요약

설계는 미래를 맞히는 일이 아니라 확인된 변경 축을 작은 경계로 격리하는 일입니다. 다음 강의에서는 책임·응집도·결합도로 경계를 평가합니다.

§10. 다음 강의 연결

이번 강의에서는 변경 이유가 다른 네 책임을 찾아냈습니다. 다음 강의에서는 그 후보를 무조건 클래스로 만드는 대신, 응집도와 변경 결합을 기준으로 어떤 코드를 함께 두고 어디서 나눌지 판단합니다.