앞에서 클래스를 공부하면서 속성(Attribute)을 배웠다.

속성은 객체가 기억해야 하는 정보였다.

예를 들어 학생 객체라면 다음과 같은 정보를 가질 수 있다.

Student
-----------------
id
name
department
year

그런데 객체가 정보만 가지고 있어서는 프로그램에서 아무 일도 일어나지 않는다.

학생은 수강 신청을 할 수도 있고, 자동차는 이동할 수도 있고, 도형은 이동하거나 크기를 변경할 수도 있다.

즉 객체에는

객체가 기억하는 것
+
객체가 할 수 있는 것

이 함께 존재한다.

UML에서는 이를 각각

속성(Attribute)
연산(Operation)

으로 표현한다.

이번에는 이 중 연산(Operation)이 무엇이고, 어떻게 찾아내며, 어떻게 UML 클래스 다이어그램으로 표현하는지를 정리해본다.

1. 연산(Operation)이란?

연산은 쉽게 말하면

객체가 외부에 제공하는 기능

이다.

예를 들어 사각형 객체가 있다고 해보자.

사각형은 자신의 위치와 색상 같은 정보를 가지고 있을 수 있다.

Rectangle
-----------------
leftTop
rightBottom
lineColor
surfaceColor

이것들은 속성이다.

그런데 사각형은 단순히 정보를 저장하기만 하는 것이 아니다.

확대한다.
축소한다.
이동한다.
색상을 변경한다.
넓이를 계산한다.

같은 일을 할 수 있다.

이것들이 바로 연산이다.

따라서 클래스는 크게 다음처럼 볼 수 있다.

┌──────────────────────┐
│      Rectangle       │
├──────────────────────┤
│ leftTop              │ ← 속성
│ rightBottom          │
│ lineColor            │
│ surfaceColor         │
├──────────────────────┤
│ zoomIn()             │ ← 연산
│ zoomOut()            │
│ move()               │
│ setLineColor()       │
│ getArea()            │
└──────────────────────┘

정리하면

Attribute
= 객체가 알고 있는 것

Operation
= 객체가 할 수 있는 것

이라고 생각하면 된다.

2. 같은 연산 이름이라도 클래스마다 동작은 다를 수 있다

예를 들어 확대()라는 기능을 생각해보자.

사각형에도 확대 기능이 있고 원에도 확대 기능이 있다.

Rectangle
+ zoomIn()

Circle
+ zoomIn()

둘 다 이름은 zoomIn()이다.

하지만 실제 구현은 다르다.

사각형이라면

leftTop
rightBottom

두 점 사이의 거리를 조정할 수 있다.

반면 원이라면

radius

를 증가시키면 된다.

즉

Rectangle.zoomIn()
≠
Circle.zoomIn()

구현 방법은 다를 수 있다.

하지만 사용자 입장에서는 둘 다

"도형을 확대한다."

라는 동일한 기능으로 이해할 수 있다.

이 개념은 이후 상속과 다형성을 이해할 때도 중요해진다.

3. UML에서 연산은 어떻게 표현할까?

클래스 다이어그램에서 클래스는 일반적으로 세 부분으로 나뉜다.

┌─────────────────────────┐
│       클래스 이름        │
├─────────────────────────┤
│          속성            │
├─────────────────────────┤
│          연산            │
└─────────────────────────┘

예를 들어

┌───────────────────────────────┐
│           Rectangle           │
├───────────────────────────────┤
│ - leftTop : Point             │
│ - rightBottom : Point         │
│ - lineColor : Color           │
├───────────────────────────────┤
│ + zoomIn(ratio : Real) : void │
│ + move(delta : Point) : void  │
│ + getArea() : Real            │
└───────────────────────────────┘

처럼 표현한다.

연산의 일반적인 UML 표현은 다음과 같다.

가시성 연산이름(매개변수 : 타입) : 반환타입

예를 들어

+ zoomIn(ratio : Real) : void

를 하나씩 뜯어보면

+           → public
zoomIn      → 연산 이름
ratio       → 매개변수 이름
Real        → 매개변수 타입
void        → 반환값 없음

이다.

4. 가시성은 속성에서 배운 것과 같다

앞의 속성에서도 등장했던

+
-
#
~

가 연산에도 그대로 사용된다.

예를 들어

+ getArea() : Real

이면 외부에서 접근할 수 있는 public 연산이다.

반면

- calculateArea() : Real

이라면 클래스 내부에서 사용하기 위한 private 연산이라고 볼 수 있다.

즉 가시성은 속성뿐 아니라 연산에도 적용된다.

5. 매개변수와 반환 타입도 중요하다

다음 두 연산을 비교해보자.

setColor(c : Color) : void
getColor() : Color

첫 번째는

Color를 입력받는다.
→ 반환값은 없다.

두 번째는

입력값은 없다.
→ Color를 반환한다.

따라서 UML만 보고도

어떤 정보를 입력받는가?
어떤 결과를 반환하는가?

를 알 수 있다.

다만 분석 단계에서는 모든 구현 세부사항을 처음부터 적을 필요는 없다.

초기 분석에서는

move()
resize()
calculateArea()

처럼 핵심 기능을 먼저 찾고,

설계가 구체화되면서

move(delta : Point) : void
resize(ratio : Real) : void
calculateArea() : Real

처럼 상세화할 수 있다.

6. Operation과 Method는 같은 말일까?

여기서 헷갈렸던 부분이 하나 있다.

Java에서는 보통

public void move(Point delta) {
    ...
}

를 메서드(Method)라고 한다.

그런데 UML에서는 왜 연산(Operation)이라고 할까?

둘은 비슷하지만 관점이 조금 다르다.

Operation
→ 객체가 제공해야 하는 기능

Method
→ 그 기능을 실제 프로그래밍 언어로 구현한 코드

예를 들어 UML에서

+ move(delta : Point) : void

라고 정의했다면,

Java에서는

public void move(Point delta) {
    ...
}

처럼 구현할 수 있다.

따라서 개념적으로

UML의 Operation
        ↓
구현
        ↓
Java/C++의 Method

라고 이해하면 편하다.

7. C++에서는 연산이 멤버 함수가 된다

UML에서 다음과 같은 클래스가 있다고 하자.

Rectangle
---------------------------
- leftTop : Point
- rightBottom : Point
---------------------------
+ zoomIn(ratio : Real) : void
+ move(delta : Point) : void
+ getArea() : Real

C++에서는 대략 다음과 같이 표현할 수 있다.

class Rectangle {

private:
    Point leftTop;
    Point rightBottom;

public:
    void zoomIn(float ratio);
    void move(Point delta);
    float getArea();
};

그리고 함수의 실제 구현은 클래스 외부에서 작성할 수도 있다.

void Rectangle::zoomIn(float ratio) {
    ...
}

여기서

Rectangle::

은

Rectangle 클래스의 함수라는 뜻

이다.

8. Java에서는 연산이 메서드가 된다

Java에서는 클래스 내부에서 바로 구현한다.

class Rectangle {

    private Point leftTop;
    private Point rightBottom;

    public void zoomIn(float ratio) {
        ...
    }

    public void move(Point delta) {
        ...
    }

    public float getArea() {
        ...
    }
}

따라서

UML

+ zoomIn(ratio : Real) : void

가 Java에서는

public void zoomIn(float ratio)

로 대응된다.

UML을 코드로 연결해서 보면 연산 표현이 훨씬 이해하기 쉽다.

9. 그런데 연산은 어떻게 찾아낼까?

속성에서도 가장 어려웠던 것은

"그래서 어떤 것을 속성으로 넣어야 하지?"

였다.

연산도 마찬가지다.

요구사항을 읽고

어떤 기능을
어느 클래스의 연산으로
넣어야 하는가?

를 판단해야 한다.

자료에서는 연산을 찾는 대표적인 방법으로 다음 관점을 제시한다.

상태에 바탕을 둔 방법

속성에 바탕을 둔 방법

책임에 바탕을 둔 방법

이 세 가지는 시험에서도 클래스 다이어그램을 직접 만들어보라고 하면 유용하게 사용할 수 있다.

10. 첫 번째 방법: 상태(State)를 보고 연산 찾기

어떤 객체의 상태가 변한다면

"무엇 때문에 이 상태가 변하는가?"

를 생각해볼 수 있다.

엘리베이터를 예로 들어보자.

엘리베이터는

정지
올라가는 중
내려가는 중

같은 상태를 가질 수 있다.

상태가 바뀌는 데에는 어떤 사건이 존재한다.

정지
 │
 │ goUp
 ▼
올라가는 중

이때

goUp()

이라는 연산을 찾아낼 수 있다.

또

정지
 │
 │ goDown
 ▼
내려가는 중

이라면

goDown()

을 생각할 수 있다.

즉

상태 변화
   ↓
그 변화를 발생시키는 Event
   ↓
필요한 Operation

이라는 흐름으로 연산을 찾을 수 있다.

11. 상태 다이어그램과 클래스 다이어그램을 연결할 수 있다

예를 들어 엘리베이터의 상태 다이어그램에서

activate
shutdown
goUp
goDown
timeout
arrived

같은 이벤트가 발견되었다고 하자.

그러면 클래스의 연산 후보로

Elevator
-------------------------
+ activate()
+ shutdown()
+ goUp(destination)
+ goDown(destination)
+ timeout()
+ arrived()

를 생각할 수 있다.

즉 상태 다이어그램은 단순히 상태만 그리는 그림이 아니다.

객체에 어떤 연산이 필요한지 찾는 단서

로 사용할 수도 있다.

⭐ 시험 대비

상태 다이어그램이 주어지고

"이 객체에 필요한 연산을 찾아라."

라는 문제가 나온다면,

상태 전이를 발생시키는 이벤트 이름을 먼저 확인해보는 것이 좋다.

12. 두 번째 방법: 속성을 보고 연산 찾기

이번에는 속성을 보자.

Person
-----------------
name
age
address

이런 속성이 있다면 처음에는 다음 연산이 떠오르기 쉽다.

getName()
setName()

getAge()
setAge()

getAddress()
setAddress()

하지만 이것만 넣는 것은 좋은 객체 설계라고 보기 어렵다.

왜일까?

객체지향에서는 객체에게

"너의 age를 줘."

라고 한 뒤 외부에서 계산하기보다는,

가능하면

"너의 나이를 증가시켜."

처럼 객체에게 행동 자체를 요청하는 것이 더 자연스럽기 때문이다.

예를 들어

setAge(age + 1)

보다

increaseAge()

가 객체의 의미를 더 잘 표현할 수 있다.

13. Getter/Setter를 무조건 만드는 것이 좋은 것은 아니다

Java를 처음 배우면 클래스를 만들자마자

getName()
setName()

getAge()
setAge()

getAddress()
setAddress()

를 만드는 습관이 생기기 쉽다.

하지만 도메인 모델링에서는

"이 객체가 실제로 해야 하는 행동은 무엇인가?"

를 먼저 생각해야 한다.

예를 들어

Person
-------------------
- name
- age
- address
-------------------
+ rename()
+ increaseAge()
+ moveTo()

처럼 표현할 수 있다.

rename()
→ 이름을 변경하는 행동

increaseAge()
→ 나이를 증가시키는 행동

moveTo()
→ 주소를 변경하는 행동

단순히 데이터를 읽고 쓰는 객체보다

자신의 상태를 스스로 관리하는 객체가 된다.

14. 계산할 수 있는 값은 객체에게 계산시키자

예를 들어 일용직 근로자가 있다고 해보자.

DailyWorker
-------------------
workDays
dailyWage

급여는

workDays × dailyWage

로 계산할 수 있다.

그렇다면 외부에서

worker.getWorkDays() * worker.getDailyWage()

를 하는 것보다

worker.getSalary()

처럼 객체에게 요청하는 것이 자연스럽다.

DailyWorker
-------------------
- workDays
- dailyWage
-------------------
+ getSalary()

객체가 자신의 데이터를 가장 잘 알고 있으므로,

그 데이터를 이용한 행동도 해당 객체가 책임지게 한다.

이것이 객체지향적인 설계와 연결된다.

15. 세 번째 방법: 책임(Responsibility)을 보고 연산 찾기

이 방법이 도메인 모델링에서 특히 중요하다.

클래스가 어떤 책임을 가지고 있다면,

그 책임을 수행하기 위한 연산이 필요하다.

예를 들어 사각형의 책임이

생성
삭제
이동
확대
축소
색상 변경
넓이 계산

이라면 연산 후보는 자연스럽게

create()
remove()
move()
zoomIn()
zoomOut()
setColor()
getArea()

가 된다.

즉

객체의 책임
   ↓
객체가 해야 하는 행동
   ↓
Operation

으로 연결할 수 있다.

16. 연산 이름도 아무렇게나 지으면 안 된다

연산 이름은 기능을 명확하게 표현해야 한다.

예를 들어 이자 계산 기능이 있다고 하자.

calculateInterest()

와

getInterest()

는 미묘하게 느낌이 다르다.

calculateInterest()
→ 이자를 계산하는 방법에 초점

getInterest()
→ 이자를 얻는 기능에 초점

도메인 모델에서는 내부 구현 방법보다

사용자가 이 객체에게 무엇을 요청할 수 있는가?

를 표현하는 것이 중요하다.

그래서 구현 방식이 그대로 드러나는 이름보다는 객체가 제공하는 기능을 나타내는 이름이 좋다.

17. 책임의 방향이 연산 이름에 드러나야 한다

논문 심사 시스템을 생각해보자.

처음에 다음처럼 만들었다고 하자.

Reviewer
-------------------
+ submitPaper()

그런데 Reviewer는 논문을 제출하는 사람인가?

보통 Reviewer의 책임은

논문을 심사한다.

이다.

그렇다면

+ reviewPaper()

가 더 자연스럽다.

즉 연산 이름을 보면

이 클래스가 무엇을 책임지고 있는지

알 수 있어야 한다.

좋은 연산 이름은 클래스의 책임과 일치한다.

18. 화이트보드 시스템으로 연산 찾기

자료에서는 화이트보드 시스템을 예제로 사용한다.

도형 관련 클래스에는

Text
Line
Oval
Rectangle
Image
FreeDrawing

등이 있다.

Text 객체를 생각해보면

생성한다.
삭제한다.
선택한다.
선택을 해제한다.
화면에 표시한다.
숨긴다.
앞으로 이동한다.
뒤로 이동한다.
색상을 변경한다.
폰트를 변경한다.

등의 행동이 필요하다.

따라서

Text
----------------------------
create()
remove()
select()
unselect()
show()
hide()

bringToFront()
sendToBack()

setTextColor()
setFontName()
setFontSize()
...

같은 연산이 만들어진다.

여기에서도 연산은 단순히 Getter/Setter를 기계적으로 만드는 것이 아니라

상태
속성
책임

을 보고 찾아낸다.

19. 상태 기반으로 Text 연산 찾기

Text 객체가 다음과 같은 상태를 가진다고 해보자.

생성되지 않음
     │
   create()
     ▼
선택되지 않은 상태
     │
   select()
     ▼
선택된 상태

다시

선택된 상태
    │
 unselect()
    ▼
선택되지 않은 상태

로 이동할 수 있다.

또

표시 상태
   │
 hide()
   ▼
숨김 상태

처럼 상태가 변한다.

그러면 상태 변화에서 자연스럽게

create()
remove()
select()
unselect()
show()
hide()

연산을 찾을 수 있다.

이게 바로

상태에 바탕을 둔 연산 찾기

다.

20. 책임 기반으로 Text 연산 찾기

이번에는 Text 객체가

앞으로 이동
뒤로 이동
맨 앞으로 이동
맨 뒤로 이동

할 책임이 있다고 생각해보자.

그러면

bringForward()
sendBackward()
bringToFront()
sendToBack()

같은 연산을 찾을 수 있다.

즉 상태가 직접 바뀌는 모습을 찾는 것뿐만 아니라,

이 객체가 시스템에서 담당해야 하는 책임을 생각하면서 연산을 찾아낼 수 있다.

21. Sequence Diagram에서도 연산을 찾을 수 있다

이 부분도 중요하다.

시퀀스 다이어그램에는 객체 사이의 메시지가 나타난다.

예를 들어

사용자
  │
  │ runCanvasEditingCommand()
  ▼
CanvasManager
  │
  │ selectShapeInRange()
  ▼
Canvas

처럼 메시지가 전달된다.

이때

CanvasManager
+ runCanvasEditingCommand()

Canvas
+ selectShapeInRange()

라는 연산이 필요하다는 것을 알 수 있다.

즉

객체가 받은 메시지는 그 객체가 제공해야 하는 연산의 후보가 된다.

⭐ 시험 대비

시퀀스 다이어그램을 보고 클래스의 연산을 채우는 문제가 나온다면

A → B : doSomething()

에서

B 클래스
+ doSomething()

을 먼저 생각하면 된다.

메시지를 받는 객체에 해당 연산이 필요하기 때문이다.

22. 여기까지 연산 찾기를 한 번에 정리하면

[상태를 본다]

상태 A
  │ event
  ▼
상태 B

→ event가 연산 후보

[속성을 본다]

workDays
dailyWage

→ getSalary()

[책임을 본다]

"논문을 심사한다"

→ reviewPaper()

[시퀀스 다이어그램을 본다]

A → B : execute()

→ B.execute()

결국 여러 모델을 서로 독립적으로 보는 것이 아니라

상태 다이어그램
시퀀스 다이어그램
클래스 다이어그램

이 서로 연결되어 있다는 것을 알 수 있다.

23. 고급 연산: 클래스 연산

여기서부터 조금 더 중요한 개념이 등장한다.

일반적인 연산은 특정 객체 하나를 대상으로 실행된다.

예를 들어

student1.getName();
student2.getName();

처럼 각각의 객체에 대해 호출한다.

그런데 어떤 기능은 특정 객체 하나에 속하지 않을 수도 있다.

예를 들어

현재 생성된 Course 객체의 총 개수

를 알고 싶다고 해보자.

이 값은 특정 Course 하나의 정보가 아니다.

course1
course2
course3

전체와 관련된 정보다.

이때 클래스 연산(Class Operation)을 사용할 수 있다.

24. 인스턴스 연산과 클래스 연산

일반적인 인스턴스 연산은

특정 객체가 있어야 호출 가능

하다.

Course course = new Course();

course.getName();

반면 클래스 연산은 특정 객체가 없어도 호출할 수 있다.

Java에서는 static으로 표현한다.

Course.getTotalCourse();

즉

Instance Operation
→ 특정 객체에 속함

Class Operation
→ 클래스 자체에 속함

이다.

25. ⭐ static에서 중요한 점

Java에서 정적 메서드는

public static int getTotalCourse() {
    return total;
}

처럼 작성한다.

그리고 객체 없이

Course.getTotalCourse();

로 호출할 수 있다.

그런데 중요한 제한이 있다.

static 메서드 안에서는 일반 인스턴스 필드를 직접 사용할 수 없다.

예를 들어

class Course {

    String name;
    static int total;

    static void test() {

        System.out.println(total); // 가능

        System.out.println(name);  // 불가능
    }
}

왜 그럴까?

name은 객체마다 다르다.

course1.name
course2.name
course3.name

그런데 static 메서드는 특정 객체 없이 호출된다.

Course.test();

그러면 Java 입장에서는

"어느 Course 객체의 name을 말하는 거지?"

를 결정할 수 없다.

따라서

static → static 직접 접근 가능
static → instance 직접 접근 불가능

이라는 규칙이 생긴다.

⭐ 시험 대비

이 부분은 코드 문제로 만들기 굉장히 쉽다.

class A {

    int x = 10;
    static int y = 20;

    static void test() {
        System.out.println(y); // O
        System.out.println(x); // X
    }
}

왜 x가 안 되는지를 단순 암기하지 말고

static 메서드는 특정 객체에 속하지 않기 때문

이라고 이해해두는 것이 좋다.

26. 그런데 객체를 가지고 있다면 접근할 수 있다

static 메서드에서 인스턴스 멤버를 절대로 사용할 수 없는 것은 아니다.

객체가 있다면 가능하다.

static void test() {

    Course course = new Course();

    System.out.println(course.name);
}

여기서는

course라는 특정 객체

가 존재한다.

따라서 어떤 객체의 name인지 명확하다.

문제는

System.out.println(name);

처럼 객체를 지정하지 않고 인스턴스 필드에 직접 접근하는 것이다.

27. 생성자는 왜 필요할까?

객체를 생성했다고 생각해보자.

Student kim = new Student();

객체가 만들어지긴 했다.

그런데 내부 값은 어떤 상태일까?

name = ?
age = ?
address = ?

객체가 생성되었는데 제대로 사용할 수 없는 상태라면 문제가 된다.

그래서 객체가 생성되는 순간 필요한 초기화 작업을 수행한다.

이 역할을 하는 것이 생성자(Constructor)다.

28. 생성자의 핵심 역할

생성자는

객체가 생성될 때 자동으로 호출되어 객체를 초기화하는 특별한 연산

이다.

예를 들어

class Student {

    String name;
    int age;

    Student() {
        name = "";
        age = 0;
    }
}

그리고

Student kim = new Student();

를 실행하면 생성자가 자동으로 호출된다.

new Student()
     ↓
객체 생성
     ↓
Student() 자동 호출
     ↓
필드 초기화

따라서 생성자의 핵심 목적은

객체를 사용 가능한 초기 상태로 만들어주는 것

이다.

29. 생성자는 여러 개 만들 수 있다

Java에서는 생성자를 오버로딩할 수 있다.

Student() {
}

Student(String name) {
    this.name = name;
}

Student(String name, int age) {
    this.name = name;
    this.age = age;
}

그러면 객체를 만드는 방법도 달라진다.

new Student();

new Student("Kim");

new Student("Kim", 27);

즉

하나의 클래스
→ 여러 초기화 방법

을 제공할 수 있다.

30. ⭐ 필드 초기값과 생성자 중 누가 더 강할까?

자료에서 강조된 부분이다.

예를 들어

class Student {

    int age = 10;

    Student(int age) {
        this.age = age;
    }
}

그리고

Student kim = new Student(20);

을 실행하면 최종 age는 얼마일까?

20

이다.

흐름을 보면

필드 기본값/명시적 초기값 설정
        ↓
생성자 실행
        ↓
생성자가 다시 값 변경

이기 때문이다.

따라서

생성자에서 설정한 값이 필드의 초기값보다 우선한다.

이 부분은 코드 실행 결과 문제로 나오기 좋다.

31. C++에는 소멸자도 있다

객체는 생성되기만 하는 것이 아니다.

언젠가는 사라진다.

C++에서는 객체가 소멸될 때 자동으로 호출되는 특별한 함수가 있다.

~FileHandler() {
    ...
}

이를 소멸자(Destructor)라고 한다.

생성자가

객체가 태어날 때

실행된다면,

소멸자는

객체가 사라질 때

실행된다.

32. 왜 소멸자가 필요할까?

예를 들어 객체가 파일을 열었다고 해보자.

객체 생성
   ↓
파일 Open
   ↓
작업
   ↓
객체 소멸

객체가 사라졌는데 파일이 계속 열려 있으면 문제가 될 수 있다.

그래서

~FileHandler() {
    close();
}

처럼 객체가 사라질 때

파일 닫기
메모리 해제
리소스 반환

등의 정리 작업을 수행할 수 있다.

이를 이해할 때

Constructor
→ Resource 획득 / 초기화

Destructor
→ Resource 해제 / 정리

로 연결하면 쉽다.

33. Java는 C++과 조금 다르다

Java는 C++처럼 개발자가 직접 사용하는 동일한 형태의 소멸자가 없다.

메모리는 Garbage Collector가 관리한다.

즉 개발자가

delete object;

같은 방식으로 직접 객체 메모리를 해제하지 않는다.

자료에서는 finalizer도 설명하지만,

핵심적으로 기억할 것은

C++
→ 명시적인 Destructor 존재

Java
→ Garbage Collector가 객체 메모리 관리

라는 차이다.

34. 연산을 검토할 때 무엇을 봐야 할까?

연산을 전부 찾았다고 끝나는 것이 아니다.

마지막에는 모델을 검토해야 한다.

첫 번째로 확인할 것은

각 연산은 실제로 하나의 기능을 나타내는가?

이다.

하나의 연산이

학생 등록
+
결제
+
이메일 발송
+
통계 업데이트

를 전부 처리한다면 너무 많은 책임을 가지고 있을 수 있다.

35. 연산 이름은 구체적이고 명확한가?

다음과 같은 이름은 좋지 않다.

process()
doIt()
handle()
work()

이름만 봐서는 무엇을 하는지 알기 어렵다.

반면

calculateSalary()
reviewPaper()
moveTo()
selectShape()

같은 이름은 기능을 비교적 명확하게 알 수 있다.

따라서

연산 이름만 보고도 기능을 어느 정도 추측할 수 있어야 한다.

36. 연산이 적절한 클래스에 들어갔는가?

이 부분이 도메인 모델링에서 정말 중요하다.

예를 들어

Reviewer.submitPaper()

가 있다면

"논문 심사자가 논문 제출을 책임지는 게 맞나?"

를 생각해야 한다.

책임이 잘못 배치되었다면

Author.submitPaper()
Reviewer.reviewPaper()

처럼 재배치해야 한다.

즉 연산 검토는 단순히 메서드 이름을 확인하는 작업이 아니라

책임이 올바른 객체에게 배정되었는지 확인하는 과정

이다.

37. 속성과 연산을 함께 보면 클래스가 보인다

앞 장에서 속성을 배웠고 이번 장에서 연산을 배웠다.

둘을 합치면 이제 클래스가 훨씬 명확하게 보인다.

┌──────────────────────────┐
│          Student         │
├──────────────────────────┤
│ id                       │
│ name                     │
│ department               │
│ year                     │
├──────────────────────────┤
│ enrollCourse()           │
│ cancelCourse()           │
│ changeDepartment()       │
└──────────────────────────┘

위쪽은

이 객체는 무엇을 알고 있는가?

이고,

아래쪽은

이 객체는 무엇을 할 수 있는가?

이다.

즉 객체는

State + Behavior

상태 + 행동

Attribute + Operation

으로 생각할 수 있다.

38. ⭐ 시험에서 클래스 다이어그램을 직접 만들라고 한다면

요구사항이 다음과 같다고 해보자.

학생은 이름과 학년을 가진다.
학생은 강좌를 신청할 수 있다.
학생은 강좌를 취소할 수 있다.

먼저 명사를 찾는다.

학생
이름
학년
강좌

여기서 클래스와 속성 후보를 찾는다.

Student
- name
- year

Course

이번에는 동사를 본다.

신청한다.
취소한다.

연산 후보가 된다.

Student
------------------
name
year
------------------
enrollCourse()
cancelCourse()

그리고 Course가 별도의 객체라면

Student ───── Course

라는 연관관계도 생각해야 한다.

즉 문제를 볼 때

명사
→ 클래스/속성 후보

동사
→ 연산 후보

상태 변화
→ 연산 후보

객체 간 메시지
→ 수신 객체의 연산 후보

다른 객체를 참조
→ 연관관계 후보

라는 흐름으로 접근하면 된다.

39. 이번 장에서 특히 구분해야 할 것

이번 장을 공부하면서 비슷해 보이는 개념들을 다음처럼 구분하면 된다.

Attribute
= 객체가 기억하는 정보

Operation
= 객체가 제공하는 기능

Method
= Operation을 실제 코드로 구현한 것

그리고

Instance Operation
= 특정 객체가 수행

Class Operation
= 클래스 자체가 수행
= Java/C++의 static

또

Constructor
= 객체 생성 시 초기화

Destructor
= 객체 소멸 시 정리

마지막으로 연산을 찾을 때는

State
Attribute
Responsibility
Sequence Diagram의 Message

를 단서로 사용할 수 있다.

시험 대비 핵심 정리

이번 장에서 시험을 준비한다면 단순히

"연산은 객체의 기능이다."

만 외우는 것보다 다음 흐름을 이해하는 것이 중요하다.

1. UML 연산 표기 읽기

+ move(delta : Point) : void
│   │       │            │
│   │       │            └ 반환 타입
│   │       └ 매개변수
│   └ 연산 이름
└ 가시성

2. 상태 다이어그램에서 연산 찾기

State A
  │ event
  ▼
State B

→ event가 Operation 후보

3. 시퀀스 다이어그램에서 연산 찾기

A → B : operation()

→ B가 operation()을 제공

4. 책임으로 연산 찾기

Reviewer
"논문을 심사한다"

→ reviewPaper()

5. static 이해하기

instance method
→ 객체 필요

static method
→ 객체 없이 클래스 이름으로 호출 가능

static method
→ instance field 직접 접근 불가능

6. 생성자

new Object()
     ↓
Constructor 자동 호출
     ↓
객체 초기화

7. 소멸자

객체 소멸
   ↓
Destructor
   ↓
Resource 정리

특히 코드를 보여주고

어떤 연산이 잘못되었는가?

static에서 접근 가능한 것은 무엇인가?

생성 후 필드 값은 무엇인가?

상태 다이어그램에서 어떤 연산을 찾아낼 수 있는가?

시퀀스 다이어그램의 메시지는 어느 클래스의 연산인가?

같이 묻는 형태는 꼭 대비해두는 것이 좋다.

마무리

속성을 공부했을 때는 클래스를

"데이터를 담는 상자"

처럼 생각하기 쉬웠다.

하지만 연산까지 배우고 나면 객체지향에서 클래스가 단순한 데이터 묶음이 아니라는 것이 보인다.

객체는 자신의 상태를 가지고 있고,

Attribute

그 상태를 바탕으로 자신이 맡은 책임을 수행한다.

Operation

그래서 좋은 클래스를 설계한다는 것은 단순히

필드를 잘 고르고
메서드를 많이 넣는 것

이 아니다.

오히려

"이 객체가 무엇을 알아야 하고, 무엇을 책임져야 하는가?"

를 결정하는 과정에 가깝다.

앞 장의 속성이

객체가 무엇을 기억해야 하는가?

에 대한 답이었다면,

이번 장의 연산은

그 정보를 가지고 객체가 무엇을 해야 하는가?

에 대한 답이라고 볼 수 있다.

결국 좋은 도메인 모델은

올바른 정보(Attribute)
        +
올바른 책임(Operation)
        +
올바른 객체에 책임 배치

가 함께 이루어져야 한다.

소프트웨어 아키텍처 스타일을 처음 보면 이름부터 많다.

Shared Repository
Blackboard
Event Broker
Event Mediator
Publish/Subscribe
...

처음에는 전부 다른 구조처럼 보였는데, 수업을 들으면서 한 가지 질문을 던지니 조금씩 구분되기 시작했다.

"이 시스템에서는 누가 다음 작업을 결정하는가?"

데이터 중심 스타일에서는 여러 컴포넌트가 하나의 데이터를 어떻게 공유하는가가 중요하다.

이벤트 드리븐 스타일에서는 컴포넌트들이 서로 직접 호출하지 않고 이벤트가 발생했을 때 누가 어떻게 반응하는가가 중요하다.

그리고 같은 데이터 중심 스타일 안에서도 Shared Repository와 Blackboard는 흐름을 주도하는 주체가 다르다.

이번 글에서는 이 차이를 중심으로 정리해본다.

1. 데이터 중심 스타일이란?

데이터 중심 스타일(Data-Centered Style)의 가장 큰 특징은 이름 그대로 데이터가 시스템의 중심에 있다는 것이다.

기본적인 구조를 단순하게 그리면 다음과 같다.

         Component A
              │
              ▼
Component B → Data Store ← Component C
              ▲
              │
         Component D

여러 소프트웨어 컴포넌트가 중앙의 데이터 저장소를 공유한다.

중요한 것은 컴포넌트 A와 B가 직접 데이터를 주고받는 것이 아니라는 것이다.

A ──직접 통신──> B

보다는

A ──> Data Store <── B

의 형태가 된다.

즉 데이터 저장소가 컴포넌트 사이의 공유 공간 역할을 한다.

구조적으로는 크게 두 부분으로 나눌 수 있다.

Data Store
    +
Data Accessor

Data Store는 데이터를 보관하는 중앙 저장소이고,

Data Accessor는 그 저장소에 접근하는 독립적인 소프트웨어 컴포넌트 또는 에이전트다.

따라서 데이터 중심 스타일에서는

데이터가 Data Accessor 사이의 의사소통 수단이 된다.

2. 데이터 중심 스타일에는 두 종류가 있다

대표적인 데이터 중심 스타일은 다음 두 가지다.

Data-Centered Style
        │
        ├── Shared Repository
        │
        └── Blackboard

둘 다 중앙에 데이터 저장소가 있다는 점은 같다.

그런데 결정적인 차이가 있다.

Shared Repository
→ 저장소 Passive
→ Client Active

Blackboard
→ 저장소 Active
→ Client(KS) Passive

여기서 처음 든 의문은 이것이었다.

"데이터 저장소가 능동적이라는 게 무슨 말이지?"

3. Active와 Passive는 무엇을 의미할까?

여기서 Active와 Passive는 단순히 데이터베이스가 CPU 연산을 하느냐 마느냐의 이야기가 아니다.

핵심은 누가 시스템의 처리 흐름을 주도하느냐에 가깝다.

Shared Repository를 생각해보자.

Client
  │
  │ "이 데이터 저장해줘"
  ▼
Repository

클라이언트가 먼저 요청한다.

예를 들어

INSERT ...
UPDATE ...
DELETE ...
SELECT ...

등을 요청하는 것이다.

Repository가 혼자 판단해서

"새 데이터가 들어왔네?
그럼 다음 프로그램을 실행해야겠다."

라고 결정하는 것이 아니다.

따라서

Client       → Active
Repository   → Passive

라고 한다.

즉 클라이언트가 로직의 흐름을 제어한다.

4. Shared Repository Style

Shared Repository의 구조를 조금 더 자세히 보면 다음과 같다.

 Client A ──────┐
 Client B ──────┤
 Client C ──────┼──> Repository
 Client D ──────┤
 Client E ──────┘

컴포넌트

하나의 Data Store
+
여러 Client

로 구성된다.

커넥터

클라이언트와 저장소가 상호작용하는 수단이다.

예를 들어

직접적인 데이터 접근
Database Query
Procedure Call
API

등이 될 수 있다.

쉽게 말하면

"클라이언트가 데이터베이스에 접근하기 위해 사용하는 수단"

이라고 생각하면 된다.

제약사항

가장 중요한 제약은

Data Store = Passive
Client     = Active

라는 것이다.

클라이언트가 요청을 보내고 로직의 흐름을 제어한다.

5. Shared Repository는 언제 사용할까?

대표적으로 대량의 정보를 오랫동안 저장해야 하는 시스템에 적합하다.

가장 이해하기 쉬운 예가 관계형 데이터베이스 관리 시스템이다.

        GUI Client
            │
            ▼
        Repository
        ▲    ▲    ▲
        │    │    │
     insert update delete

여러 클라이언트가 GUI나 Command Line 등을 통해

Insert
Update
Delete
Retrieve

작업을 수행한다.

데이터는 중앙 저장소에 모여 있고 클라이언트들이 필요할 때 접근한다.

6. Compiler와 IDE도 Repository를 사용할 수 있다

조금 의외였던 예제가 Compiler와 IDE다.

컴파일러를 생각하면 보통 다음 과정부터 떠올린다.

Source Code
    ↓
Lexical Analysis
    ↓
Syntax Analysis
    ↓
Semantic Analysis
    ↓
Code Generation

Syntax Analysis 과정에서는 대표적으로 AST(Abstract Syntax Tree) 같은 구조가 만들어질 수 있다.

Repository 기반으로 구성하면 이러한 중간 정보를 중앙 저장소에 두고 여러 처리기가 공유할 수 있다.

Lexical Analyzer ──────┐
Syntax Analyzer  ──────┤
Semantic Analyzer ─────┤
                       ▼
                   Repository
                   ┌───────────┐
                   │ AST       │
                   │ Symbol    │
                   │ Grammar   │
                   │ Output    │
                   └───────────┘
                       ▲
Optimizer ─────────────┤
Code Generator ────────┘

즉 각 처리기가 서로 직접 데이터를 넘기는 대신 Repository의 공통 데이터를 읽고 수정할 수 있다.

여기서 이전에 배운 Batch Sequential이나 Pipe-and-Filter와의 차이도 생각해볼 수 있다.

Pipe-and-Filter
A → B → C → D

Repository
      ┌→ A
      ├→ B
DB ───┼→ C
      └→ D

Pipe-and-Filter에서는 처리 결과가 다음 처리 단계로 흐르는 구조가 중요했다.

Repository에서는 여러 처리기가 동일한 중앙 데이터를 공유한다는 것이 핵심이다.

7. Shared Repository의 장점

첫 번째는 확장성(Scalability)이다.

특히 읽기 중심 구조에서는 수평 확장이 비교적 용이하다.

두 번째는 변경 용이성(Modifiability)이다.

새로운 클라이언트를 추가하거나 기존 클라이언트의 기능을 수정하기 쉽다.

기존

A ─┐
B ─┼── Repository
C ─┘


새 기능 추가

A ─┐
B ─┤
C ─┼── Repository
D ─┘

기존 A, B, C를 모두 수정하지 않고 D를 추가할 수 있다.

또한 모든 컴포넌트가 같은 공간의 데이터를 공유한다.

Component A가 데이터 변경
          ↓
      Repository
          ↓
다른 Component도 변경된 데이터 사용

컴포넌트끼리 계속 데이터를 복제하거나 전달할 필요가 줄어든다는 장점이 있다.

8. 하지만 중앙 저장소가 하나라는 것은 위험하기도 하다

Shared Repository의 가장 직관적인 문제는 Single Point of Failure(SPOF)다.

A ─┐
B ─┤
C ─┼── Repository 💥
D ─┤
E ─┘

모든 컴포넌트가 Repository에 의존하고 있는데 Repository가 죽으면 어떻게 될까?

전체 시스템이 영향을 받을 수 있다.

따라서 신뢰성(Reliability), 그리고 결과적으로 가용성 측면에서 문제가 될 수 있다.

또 다른 문제는 데이터 구조와 클라이언트 사이의 높은 의존성이다.

Repository Schema 변경
        ↓
Client A 수정
Client B 수정
Client C 수정
Client D 수정

중앙 데이터 구조를 변경했는데 모든 클라이언트가 그 구조를 알고 있다면 변경의 영향 범위가 매우 커질 수 있다.

9. 그런데 Blackboard는 뭐가 다른가?

Blackboard 역시 중앙에 데이터를 공유한다.

그래서 겉으로 보면 Repository와 매우 비슷하다.

 KS1 ─┐
 KS2 ─┤
 KS3 ─┼── Blackboard
 KS4 ─┤
 KS5 ─┘

하지만 가장 큰 차이는

Shared Repository
Client가 먼저 요청

Blackboard
Blackboard의 상태 변화가 다음 처리를 유발

한다는 점이다.

Blackboard에서는 클라이언트를 특별히

Knowledge Source
KS
지식 소스

라고 부른다.

KS를 처음 이해할 때는 특정 문제 하나를 해결할 줄 아는 독립적인 Agent처럼 생각하면 편하다.

10. Knowledge Source는 무엇인가?

예를 들어 하나의 복잡한 문제가 있다고 하자.

Raw Data
   ↓
정보 추출
   ↓
Tree 생성
   ↓
계층 구조 생성
   ↓
최종 결과

이 모든 것을 하나의 거대한 프로그램이 처리하도록 만들 수도 있다.

하지만 Blackboard에서는 문제를 독립적인 해결 단위로 분해한다.

KS1 = Raw Data에서 정보 추출

KS2 = 추출된 정보로 Tree 생성

KS3 = 여러 Tree를 계층 구조로 구성

각 KS는 자신이 해결할 수 있는 문제만 알고 있다.

그래서 중요한 것은

KS들을 얼마나 잘 정의하느냐

이다.

즉 복잡한 문제를 독립적인 해결 단위로 얼마나 잘 분해할 수 있는가가 Blackboard 설계의 핵심이 된다.

11. Blackboard는 어떻게 동작할까?

처음 Blackboard에 Raw Data가 들어왔다고 생각해보자.

Blackboard

[ Raw Data ]

Control이 Blackboard의 상태 변화를 관찰한다.

"Raw Data가 들어왔네?"

현재 상태를 처리할 수 있는 KS를 찾는다.

KS1 : Raw → 정보 추출

KS1이 실행된다.

Blackboard

[ Raw Data ]
     ↓
[ 추출된 정보 ]

Blackboard의 상태가 다시 바뀌었다.

그러면 또 조건을 확인한다.

"추출된 정보가 존재하네?"

→ KS2 실행

KS2가 Tree를 만든다.

Blackboard

Raw Data
   ↓
추출된 정보
   ↓
Tree

상태가 또 변경된다.

"Tree가 생겼네?"

→ KS3 실행

결국

Raw Data
   ↓
[KS1]
   ↓
Extracted Data
   ↓
[KS2]
   ↓
Tree
   ↓
[KS3]
   ↓
Hierarchy

처럼 문제가 단계적으로 해결된다.

12. 누가 KS를 호출하는가?

여기서 중요한 질문이 생긴다.

"Blackboard가 직접 KS를 호출하는 건가?"

조금 더 정확하게는 Control이 존재한다.

            ┌───────────┐
            │  Control  │
            └─────┬─────┘
                  │ 상태 관찰
                  ▼
            ┌───────────┐
            │ Blackboard│
            └───────────┘
              ▲   ▲   ▲
              │   │   │
             KS1 KS2 KS3

Control은 Blackboard의 변화를 관찰하고

다음에 어떤 Action을 실행할 것인가?

를 결정한다.

그리고 조건에 맞는 KS를 활성화한다.

따라서 Blackboard에서 중요한 것은 단순히 데이터를 저장하는 것이 아니다.

현재 Blackboard 상태
        ↓
실행 가능한 KS 판단
        ↓
KS 실행
        ↓
Blackboard 상태 변경
        ↓
다시 실행 가능한 KS 판단
        ↓
...

이 순환 구조가 핵심이다.

13. Repository와 Blackboard를 비교하면 확실해진다

[Shared Repository]

Client
  │
  │ 요청
  ▼
Repository

"Client가 뭘 할지 결정한다."


[Blackboard]

Blackboard 상태 변경
        ↓
      Control
        ↓
실행할 KS 결정
        ↓
       KS
        ↓
Blackboard 변경

"현재 문제 상태에 따라 다음 처리가 결정된다."

그래서 수업에서 말한

Repository
저장소 Passive
Client Active

Blackboard
저장소 Active
Client Passive

라는 차이를 이해할 수 있다.

14. Blackboard의 대표적인 활용: 음성 인식

Blackboard가 잘 어울리는 대표적인 문제가 음성 인식이다.

음성 인식은 한 번의 처리로 답이 나오는 단순한 문제가 아니다.

예를 들어 개념적으로

음성
 ↓
Segmentation
 ↓
Syllable Creation
 ↓
Word Creation
 ↓
결과

처럼 여러 전문적인 처리 과정이 필요할 수 있다.

각 처리기를 KS로 구성한다.

KS1 → Segmentation
KS2 → Syllable Creation
KS3 → Word Creation

그리고 Blackboard의 현재 상태를 보고 어떤 KS가 현재 문제 해결에 기여할 수 있는지 판단한다.

새로운 입력 발생
      ↓
Blackboard 상태 확인
      ↓
실행 가능한 KS 선택
      ↓
KS 동작
      ↓
Blackboard Update
      ↓
다시 상태 확인

이 과정이 반복되면서 답에 가까워진다.

15. Blackboard의 장점

가장 큰 장점은 기능 확장성(Extensibility)이다.

KS가 독립적으로 구성되어 있다면

KS1
KS2
KS3

에 새로운 기능이 필요할 때

KS1
KS2
KS3
KS4 ← 추가

처럼 새로운 Knowledge Source를 추가할 수 있다.

따라서 변경 용이성과 재사용성도 좋아질 수 있다.

또 KS들이 충분히 독립적이라면 여러 KS를 동시에 실행할 수 있다.

       ┌→ KS1
BB ────┼→ KS2
       └→ KS3

즉 Concurrency를 활용할 수 있고 이는 성능과 확장성으로 이어질 수 있다.

16. Blackboard의 단점

하지만 모든 KS가 Blackboard 구조를 알고 있다.

따라서 Blackboard의 데이터 구조 자체가 변경되면

Blackboard 구조 변경
       ↓
KS1 영향
KS2 영향
KS3 영향
KS4 영향

처럼 전체 KS가 영향을 받을 수 있다.

또 하나의 어려움은

"언제 문제 해결이 끝났다고 판단할 것인가?"

이다.

KS가 Blackboard를 변경하고,

그 변경이 다른 KS를 실행시키고,

다시 Blackboard가 변경되는 구조이기 때문이다.

여러 KS가 동시에 실행될 수도 있기 때문에 시스템 동작이 항상 똑같은 순서로 나타난다고 보장하기도 어렵다.

따라서 시스템 설계와 테스트가 어려워지고 시험 용이성(Testability)이 떨어질 수 있다.

17. 이제 완전히 다른 관점: Event-Driven Architecture

앞에서는 중앙 데이터가 중심이었다.

이번에는 Event가 중심이다.

기존 프로그램에서는 보통 특정 대상을 직접 호출한다.

A
│
├── call B()
│
└── call C()

이것을 명시적 호출(Explicit Invocation)이라고 볼 수 있다.

A가 B를 정확히 알고 있다.

반면 이벤트 기반에서는

A
│
└── "OrderCreated 발생!"
           ↓
       Event System
       ↙        ↘
      B          C

A가 B나 C를 직접 호출하지 않는다.

A는 단지

OrderCreated

라는 이벤트를 발행한다.

그리고 그 이벤트에 관심 있는 컴포넌트가 반응한다.

이것이 묵시적 호출(Implicit Invocation)이다.

18. Message와 Event는 같은 것일까?

둘은 완전히 같은 말은 아니다.

Message는 컴포넌트 사이에서 전달되는 데이터 단위다.

Message 안에는 여러 의미가 들어갈 수 있다.

Message
├── Event
├── Command
└── Information

예를 들어

CreateOrder

는 특정 작업을 수행하라는 Command가 될 수 있다.

반면

OrderCreated

는

"주문이 이미 생성되었다."

라는 상태 변화를 알리는 Event다.

따라서 Event는 보통 직접적인 응답을 요구하기보다

"이런 일이 발생했다."

라고 알리는 데 초점이 있다.

19. Event Broker Style

첫 번째 이벤트 기반 스타일은 Event Broker다.

구조는 다음처럼 생각할 수 있다.

Publisher
    │
    │ Event
    ▼
┌──────────┐
│  Broker  │
└──────────┘
  │   │   │
  ▼   ▼   ▼
 S1   S2   S3

Broker는 발행자가 보낸 이벤트를 받아 적절한 구독자에게 전달한다.

주요 컴포넌트는

Event Publisher
Event Subscriber
Event Broker
[Event Stream Processor]

다.

Publisher는 이벤트를 생성한다.

Subscriber는 자신이 관심 있는 이벤트를 비동기적으로 받아 처리한다.

Broker는 이벤트를 수집하고 라우팅한다.

20. Broker가 Workflow까지 결정하는 것은 아니다

여기서 굉장히 중요한 차이가 있다.

Broker의 핵심 역할은

"이 이벤트를 누구에게 전달할까?"

이다.

즉 메시지를 전달하고 라우팅하는 역할에 가깝다.

전체 업무 흐름을 중앙에서 완전히 제어하는 것은 아니다.

예를 들어 주문 시스템을 생각해보자.

OrderCreated
     ↓
Payment
     ↓
Inventory
     ↓
Shipping

Broker 스타일에서는 각각의 컴포넌트가 이벤트를 받아 처리하고 다시 다음 이벤트를 발생시킬 수 있다.

OrderCreated
     ↓
Payment Service
     ↓
PaymentCompleted
     ↓
Inventory Service
     ↓
InventoryUpdated
     ↓
Shipping Service

각 컴포넌트는 다른 컴포넌트를 직접 알 필요가 없다.

그래서 결합도가 낮아진다.

하지만 반대로 생각하면

"지금 주문이 전체 과정 중 어디까지 왔지?"

를 중앙에서 파악하기 어려울 수 있다.

21. 그래서 Event Mediator가 등장한다

복잡한 Workflow를 관리해야 한다면 중간에 Event Mediator를 둘 수 있다.

             Event
               │
               ▼
        ┌─────────────┐
        │  Mediator   │
        └─────────────┘
          │    │    │
          ▼    ▼    ▼
       Payment Stock Shipping

Mediator는 단순히 이벤트를 전달하는 것을 넘어

현재 주문이 어디까지 진행되었는가?

다음에는 어떤 작업을 해야 하는가?

실패했다면 재시도해야 하는가?

보상 처리가 필요한가?

등을 판단하면서 Workflow를 관리한다.

22. 배송 시스템으로 Broker와 Mediator 비교하기

Broker 방식이라면

OrderCreated
     ↓
 Payment
     ↓
PaymentCompleted
     ↓
 Inventory
     ↓
InventoryUpdated
     ↓
 Shipping

처럼 이벤트가 이어진다.

각 서비스는 자신에게 필요한 이벤트에만 반응한다.

반면 Mediator 방식은

             ┌───────────────┐
             │ Order Mediator│
             └───────────────┘
               │    │    │
         ┌─────┘    │    └─────┐
         ▼          ▼          ▼
      Payment    Inventory   Shipping

Mediator가 전체 진행 상황을 알고 있다.

예를 들어

1. 주문 생성
2. 결제 요청
3. 결제 완료 확인
4. 재고 확인
5. 배송 요청

순서를 직접 관리할 수 있다.

따라서 네 필기의

"배송 중 상태에서 다시 이전 단계로 못 넘어가게 한다?"

라는 생각은 워크플로우 제어라는 방향에서 이해하면 된다.

정확히는 단순히 이전 단계로 못 가게 하는 것만이 목적은 아니다.

Mediator가

현재 상태
다음 상태
실패 처리
재시도
보상 처리

등 전체 Workflow를 관리할 수 있다는 것이 핵심이다.

23. Broker vs Mediator

두 구조의 차이는 다음 질문으로 기억하면 편하다.

Broker

"누구에게 전달할까?"

Mediator

"다음에는 무엇을 해야 하지?"

Broker는 서비스들을 강하게 분리할 수 있다.

반면 Mediator는 전체 흐름을 더 쉽게 통제할 수 있다.

그 대신 중앙의 Mediator에 대한 의존성이 생긴다.

24. Event Broker의 장점과 단점

Broker 방식의 가장 큰 장점은 Decoupling이다.

이벤트 구독자들이 서로를 직접 알 필요가 없다.

A → Broker → B
           → C
           → D

따라서 각각 독립적으로 확장하기 쉽고 높은 확장성과 응답성, 성능을 기대할 수 있다.

또 하나 중요한 장점은 내고장성이다.

각 컴포넌트가 분리되어 있기 때문에 하나의 서비스 장애가 반드시 전체 시스템 장애로 이어지는 구조는 아니다.

하지만 전체 Workflow를 제어하기 어렵다.

이 이벤트가 마지막인가?

모든 처리가 끝났나?

중간에서 실패했나?

를 파악하기 어려울 수 있다.

또 비동기 처리 때문에 복구와 재시작이 복잡해질 수 있으며 데이터 비일관성 문제도 발생할 수 있다.

25. Event Mediator의 장점과 단점

Mediator의 장점은 Broker의 약점을 반대로 생각하면 된다.

Workflow Control
Error Handling
Recoverability
Restartability
Data Consistency

같은 부분을 관리하기 쉬워진다.

Mediator가 전체 Workflow를 알고 있기 때문이다.

하지만 그 대가가 있다.

Mediator에 대한 의존성이 커지고 Broker보다 확장성과 성능이 다소 떨어질 수 있다.

또 Mediator 자체가 중요한 역할을 담당하기 때문에 내고장성 측면에서도 불리해질 수 있다.

즉

Broker
→ 자유롭게 분산
→ 흐름 통제 어려움

Mediator
→ 흐름 통제 쉬움
→ 중앙 의존 증가

라는 Trade-off가 생긴다.

26. Queue와 Topic은 어떻게 다를까?

이벤트 시스템을 공부하면 Queue와 Topic도 등장한다.

가장 단순하게 구분하면 다음과 같다.

Queue

Producer
   │
   ▼
 Queue
   │
   ▼
Consumer

특정 메시지를 소비자가 가져가 처리하는 P2P 구조로 생각할 수 있다.

Topic

             ┌→ Subscriber A
Publisher → Topic
             └→ Subscriber B

Publisher가 Topic에 메시지를 발행하면 해당 Topic을 구독한 Subscriber들이 메시지를 받을 수 있다.

그래서

Queue
→ 특정 소비자를 향한 메시지 전달

Topic
→ 하나의 이벤트를 여러 구독자가 관심에 따라 수신

이라는 관점으로 시작하면 이해하기 쉽다.

27. 이벤트 기반 시스템의 공통적인 장점

첫 번째는 익명성(Anonymity)이다.

메시지 소비자는 반드시 다음을 알 필요가 없다.

누가 메시지를 만들었는가?
어디에 있는가?
언제 만들었는가?

이 때문에 컴포넌트 사이의 결합을 줄일 수 있다.

두 번째는 Concurrency다.

생산자와 소비자, 여러 소비자가 독립적으로 동작할 수 있다.

세 번째는 메시지 전달의 신뢰성을 조절할 수 있다는 점이다.

예를 들어

메시지 승인
메시지 우선순위
메시지 만료

등을 설정할 수 있다.

28. 이벤트 기반 시스템의 단점

하지만 비동기 시스템에서는 순서를 예측하기 어려워진다.

Event 발생
   ↓
Listener A
Listener B
Listener C

이때

A → B → C

순서로 반드시 끝난다고 보장하기 어려울 수 있다.

따라서

응답 순서 예측
종료 시점 판단
디버깅
검증

이 어려워진다.

메시지 큐 자체의 용량 문제나 메시지 처리에 따른 오버헤드도 고려해야 한다.

즉

"자동으로 반응해서 편하다"

는 장점의 반대편에는

"누가 언제 어떤 순서로 반응할지 추적하기 어렵다"

라는 문제가 존재한다.

29. Blackboard와 Event-Driven은 비슷해 보인다

여기까지 보면 한 가지 의문이 생긴다.

Blackboard도

상태 변경
→ KS 실행

이고 Event-Driven도

Event 발생
→ Subscriber 실행

이다.

둘이 굉장히 비슷해 보인다.

실제로 상태 변화가 다른 컴포넌트의 동작을 유발한다는 점에서는 비슷한 모습을 가질 수 있다.

하지만 아키텍처의 중심이 다르다.

Blackboard
→ 공유된 문제 상태(Data)를 중심으로 협력
→ 여러 KS가 부분적인 해법을 적용
→ 문제를 점진적으로 해결

Event-Driven
→ Event를 중심으로 통신
→ Publisher와 Subscriber의 결합을 줄임
→ 사건 발생에 따라 독립적인 Component가 반응

즉 Blackboard에서는

"현재 문제의 상태가 무엇인가?"

가 중요하고,

Event-Driven에서는

"무슨 사건이 발생했는가?"

가 중요하다.

30. 결국 아키텍처에는 무조건 좋은 구조가 없다

마지막으로 가장 중요한 내용이다.

데이터베이스 구조를 다음 세 가지로 생각해보자.

1. Monolithic DB

Service A ─┐
Service B ─┼── One DB
Service C ─┘

2. Domain별 DB

Domain A ── DB A
Domain B ── DB B

3. Service별 DB

Service A ── DB A
Service B ── DB B
Service C ── DB C

처음 보면

"서비스별 DB가 가장 분리되어 있으니까
3번이 제일 좋은 것 아닌가?"

라는 생각이 들 수 있다.

하지만 아키텍처에서는 그렇게 단순하게 판단할 수 없다.

31. 무엇을 중요하게 생각하느냐에 따라 답이 달라진다

평가해야 하는 품질 속성이 있기 때문이다.

성능
구축 용이성
변경 용이성
내고장성
확장성

예를 들어 하나의 DB를 공유하면

구조 단순
관리 편리
데이터 일관성 관리 상대적으로 쉬움

이라는 장점이 있을 수 있다.

하지만 DB가 하나이므로 장애가 전체 시스템에 영향을 줄 가능성이 커지고 서비스별 독립 확장에도 제약이 생길 수 있다.

반대로 서비스마다 DB를 분리하면

서비스 독립성 ↑
변경 독립성 ↑
확장성 ↑
장애 격리 ↑

같은 장점을 얻을 수 있다.

하지만

운영 복잡성 ↑
데이터 일관성 관리 난이도 ↑
분산 트랜잭션 문제 ↑

같은 비용을 지불해야 한다.

Domain별 DB는 그 사이에서 하나의 절충안이 될 수 있다.

32. 그래서 "몇 번이 제일 좋아요?"라는 질문에는 답이 없다

이게 이번 내용에서 가장 중요한 결론이라고 생각한다.

1번이 나쁘고
3번이 좋다

가 아니다.

만약

"나는 확장성과 서비스 독립성이 굉장히 중요해."

라면 서비스별 분리를 적극적으로 고려할 수 있다.

반대로

"시스템이 작고 구축과 운영의 단순성이 훨씬 중요해."

라면 굳이 모든 것을 서비스별로 쪼갤 필요가 없다.

또

"어느 정도 독립성은 필요하지만
서비스마다 DB를 운영하는 복잡성까지 감당하고 싶지는 않아."

라면 Domain 단위의 분리를 선택할 수도 있다.

결국 아키텍처 설계는

"어떤 구조가 가장 좋은가?"

를 찾는 문제가 아니라

"내 시스템에서 가장 중요한 품질 속성은 무엇이고, 그 속성을 얻기 위해 어떤 비용을 감수할 것인가?"

를 결정하는 문제에 가깝다.

마무리

처음에는 Shared Repository, Blackboard, Event Broker, Event Mediator가 전부 비슷하게 느껴졌다.

하지만 누가 흐름을 주도하는가?를 기준으로 보면 차이가 보인다.

Shared Repository
────────────────────
Client가 주도
Repository는 수동적

Client → Repository

Blackboard
────────────────────
문제 상태가 중심
Control이 상태를 보고 KS 선택

Blackboard 상태
      ↓
   Control
      ↓
     KS
      ↓
Blackboard 갱신

Event Broker
────────────────────
Event가 발생하면
관심 있는 Component가 반응

Publisher
    ↓
 Broker
 ↙  ↓  ↘
A   B   C

Event Mediator
────────────────────
Mediator가 전체 Workflow를 관리

       Mediator
      ↙   ↓   ↘
     A    B    C

그리고 이 모든 구조에는 장점과 단점이 존재한다.

따라서 소프트웨어 아키텍처를 공부할 때 단순히 구조를 암기하는 것보다

왜 이런 구조가 등장했는가?

누가 제어 흐름을 가지고 있는가?

컴포넌트는 어떻게 통신하는가?

무엇을 얻는 대신 무엇을 포기하는가?

어떤 시스템에 적합한가?

를 질문하는 것이 훨씬 중요하다.

결국 아키텍처 스타일은 정답을 고르는 문제가 아니다.

시스템이 중요하게 생각하는 품질 속성에 따라 적절한 Trade-off를 선택하는 문제다.

알고리즘을 작성하는 것만큼 중요한 것이 있다.

이 알고리즘은 입력 데이터가 많아졌을 때도 사용할 수 있을까?

데이터가 10개일 때 잘 동작하는 것과 데이터가 100만 개일 때 잘 동작하는 것은 전혀 다른 문제다.

그래서 알고리즘을 분석할 때는 단순히 "내 컴퓨터에서 몇 초 걸렸다"가 아니라 입력 크기 N이 증가함에 따라 필요한 연산의 수가 어떻게 증가하는가를 살펴본다.

이번 장에서는 이를 1-SUM과 2-SUM부터 시작해서 생각해본다.

1. 왜 알고리즘을 분석할까?

두 알고리즘이 있다고 생각해보자.

알고리즘 A → N²번 정도 연산
알고리즘 B → N log N번 정도 연산

N이 작을 때는 둘의 차이가 크게 느껴지지 않을 수 있다.

하지만 N이 커지면 상황이 달라진다.

예를 들어

N = 1,000,000

이라면

N²
= 1,000,000,000,000

N log₂N
≈ 1,000,000 × 20
≈ 20,000,000

정도가 된다.

같은 문제를 해결하더라도 알고리즘의 성장 속도에 따라 필요한 연산량이 엄청나게 달라질 수 있다.

그래서 알고리즘 분석에서는 입력 크기 N에 따른 실행 시간과 메모리의 증가량을 중요하게 본다.

2. 가장 간단한 예제: 1-SUM

다음 코드가 있다고 하자.

int count = 0;

for (int i = 0; i < N; i++) {

    if (a[i] == 0) {
        count++;
    }
}

이 알고리즘은 배열을 처음부터 끝까지 한 번 확인하면서 값이 0인 원소의 개수를 센다.

예를 들어

[-3, 0, 5, 0, 7]

이라면

-3 → 확인
 0 → 확인 → count++
 5 → 확인
 0 → 확인 → count++
 7 → 확인

총 N개의 원소를 확인한다.

따라서 직관적으로 생각하면 실행되는 연산의 수가 N에 비례한다.

하지만 강의에서는 여기서 바로 O(N)이라고 끝내지 않고 실제로 어떤 명령이 몇 번 실행되는지 먼저 계산한다.

3. 1-SUM의 명령 횟수를 직접 세어보자

코드를 다시 보자.

int count = 0;

for (int i = 0; i < N; i++) {

    if (a[i] == 0) {
        count++;
    }
}

여기에는 여러 연산이 존재한다.

변수 선언
대입
i < N 비교
a[i] 접근
a[i] == 0 비교
i++
count++

예를 들어 i < N은 반복문이 종료되는 마지막 검사까지 포함하기 때문에 대략

N + 1번

실행된다.

a[i] 접근과 a[i] == 0 비교는 각 원소마다 이루어지므로

N번

이다.

반면

count++;

는 배열에 실제로 0이 몇 개 있는지에 따라 달라진다.

최소 0번
최대 N번

실행될 수 있다.

중요한 것은 세부적인 횟수가 조금씩 달라도 전체적으로 보면 N에 비례해서 증가하는 연산들이 지배적이라는 것이다.

그래서 1-SUM은 linear한 성장 형태를 가진다.

4. 2-SUM은 무엇일까?

이번에는 배열에서 서로 다른 두 원소를 선택해서 합이 0이 되는 조합을 찾는다고 하자.

예를 들어

[-10, -5, 0, 5, 10]

이라면

(-10, 10)
(-5, 5)

가 존재한다.

Brute Force 방식으로 구현하면 다음과 같은 구조가 된다.

int count = 0;

for (int i = 0; i < N; i++) {

    for (int j = i + 1; j < N; j++) {

        if (a[i] + a[j] == 0) {
            count++;
        }
    }
}

여기서 중요한 것은

j = i + 1

이다.

왜 j = 0부터 시작하지 않을까?

같은 원소를 자기 자신과 비교할 필요가 없고,

a[0] + a[1]

을 확인했다면 나중에

a[1] + a[0]

을 다시 확인할 필요도 없기 때문이다.

즉 중복되지 않는 두 원소의 조합만 검사한다.

5. 두 원소를 고르는 경우의 수

N개의 데이터 중에서 서로 다른 2개를 선택하는 경우의 수는

N choose 2

이다.

수식으로 표현하면

N(N - 1)
────────
   2

이다.

왜 그런지 반복문으로 생각하면 더 쉽다.

첫 번째 i에서는

N - 1

개를 비교한다.

그다음에는

N - 2

개.

계속하면

(N - 1) + (N - 2) + ... + 2 + 1

이 된다.

결과는

N(N - 1) / 2

이다.

전개하면

1/2 N² - 1/2 N

이 된다.

여기서부터 알고리즘 분석에서 중요한 질문이 생긴다.

매번 1/2 N² - 1/2 N처럼 정확하게 써야 할까?

6. 정확한 명령 횟수를 계속 계산하는 것은 번거롭다

실제 프로그램에서는 비교뿐 아니라 대입, 배열 접근, 증가 연산 등 다양한 연산이 발생한다.

그래서 정확하게 계산하면 실행 횟수가 다음처럼 나올 수 있다.

1/2 N² + 3N + 7

혹은

2N² + 5N + 10

처럼 복잡해질 수 있다.

하지만 N이 매우 커졌을 때를 생각해보자.

N = 1,000,000

이라면

N² = 1,000,000,000,000
N  =         1,000,000

이다.

N²에 비하면 N이나 상수는 상대적으로 영향력이 매우 작아진다.

그래서 알고리즘의 성장률을 볼 때는 작은 차수를 제거하고 가장 빠르게 증가하는 항에 집중할 수 있다.

여기서 Tilde notation이 등장한다.

7. Tilde Notation ~

강의자료에서는 Tilde notation을 다음과 같이 설명한다.

lower-order terms를 무시하여 수학적 모델을 단순화한다.

예를 들어

f(N) = 1/2 N² + 3N + 7

이라면 N이 커질수록 가장 큰 영향을 주는 항은

1/2 N²

이다.

따라서

f(N) ~ 1/2 N²

처럼 표현할 수 있다.

여기서 중요한 점이 하나 있다.

Tilde notation에서는 최고차항의 계수까지 없애는 것이 아니다.

예를 들어

3N² + 10N + 5

라면

~ 3N²

이다.

~ N²이라고 하는 것과는 의미가 다르다.

왜냐하면 Tilde notation의 엄밀한 의미는

f(N) ~ g(N)

일 때

        f(N)
lim    ───── = 1
N→∞     g(N)

이기 때문이다.

예를 들어

f(N) = 3N² + 10N + 5
g(N) = 3N²

이면

3N² + 10N + 5
──────────────
     3N²

= 1 + 10/(3N) + 5/(3N²)

이고 N이 무한히 커지면

→ 1

이 된다.

따라서

3N² + 10N + 5 ~ 3N²

이다.

8. 그런데 Big-O에서는 계수도 무시한다

여기서 Tilde notation과 Big-O를 구분해야 한다.

예를 들어

f(N) = 3N² + 10N + 5

라고 하자.

Tilde notation에서는

f(N) ~ 3N²

이라고 한다.

반면 Big-O와 같은 점근적 표기에서는 보통

O(N²)

이라고 한다.

즉

Tilde
→ leading coefficient를 유지

Big-O 계열
→ 상수배까지 중요하지 않게 본다.

이 차이를 알아두면 둘을 혼동하지 않는다.

9. Big-O, Big-Ω, Big-Θ

알고리즘의 성장률을 표현할 때 자주 등장하는 세 가지 표기가 있다.

Big-O     O
Big-Omega Ω
Big-Theta Θ

가장 먼저 큰 그림을 잡으면

O(g(N))
→ 점근적 상한

Ω(g(N))
→ 점근적 하한

Θ(g(N))
→ 점근적으로 같은 차수

라고 이해할 수 있다.

그런데 여기서 상한과 하한이라는 표현을 정확히 이해해야 한다.

10. Big-O : 점근적 상한

어떤 알고리즘의 실행 횟수가

f(N) = 10N² + 3N + 20

이라고 하자.

Big-O는 충분히 큰 N에서

f(N) ≤ c · g(N)

을 만족하는 어떤 양의 상수 c와 기준점 N₀가 존재하는지를 본다.

예를 들어

g(N) = N²

라고 하자.

충분히 큰 N에서는

10N² + 3N + 20 ≤ 11N²

같은 관계를 만들 수 있다.

즉

f(N)
────────── 11N²

라는 위쪽 경계를 잡을 수 있다.

그래서

f(N) = O(N²)

라고 말할 수 있다.

핵심은 정확히 11이어야 한다는 것이 아니다.

20N²
100N²
1000N²

등 충분히 큰 상수배를 잡아도 된다.

Big-O는 어떤 상수배를 이용해서 위에서 덮을 수 있는가를 보는 것이다.

11. Big-Ω : 점근적 하한

같은 함수

f(N) = 10N² + 3N + 20

을 생각해보자.

이번에는 아래쪽 경계를 찾는다.

예를 들어

9N² ≤ 10N² + 3N + 20

은 충분히 큰 N에서 당연히 성립한다.

즉

9N²
────────── f(N)

처럼 아래에서 받칠 수 있다.

따라서

f(N) = Ω(N²)

라고 말할 수 있다.

Big-Ω의 핵심은

f(N) ≥ c · g(N)

이 되는 상수 c > 0과 충분히 큰 N이 존재한다는 것이다.

12. 내가 헷갈렸던 10N², 11N², 9N² 예제

처음에는 다음처럼 생각하기 쉽다.

10N² < 11N²
→ Big-O

10N² > 9N²
→ Big-Ω

직관 자체는 상한과 하한을 이해하는 데는 괜찮다.

       11N²       ← 위쪽 경계
        ↑
       10N²       ← 실제 함수
        ↑
        9N²       ← 아래쪽 경계

그래서

10N² = O(N²)

10N² = Ω(N²)

둘 다 맞다.

그리고 위와 아래에서 모두 같은 N² 차수로 잡을 수 있으므로

10N² = Θ(N²)

도 맞다.

다만 여기서 중요한 것은

11과 9라는 숫자 자체가 Big-O와 Big-Ω를 결정하는 것이 아니다.

Big-O와 Big-Ω에서는 상수배를 허용한다.

따라서 더 좋은 예제는 다음과 같다.

f(N) = 10N² + 3N + 20

충분히 큰 N에서

9N² ≤ f(N) ≤ 11N²

같은 형태의 경계를 잡을 수 있다면

f(N) = Ω(N²)
f(N) = O(N²)

이고 결과적으로

f(N) = Θ(N²)

이라고 볼 수 있다.

13. Big-O는 "정확한 실행시간"이 아니다

여기서 자주 하는 착각이 있다.

O(N²)

이라고 했다고 해서 실행 횟수가 정확히 N²번이라는 뜻은 아니다.

다음 함수들은 모두 O(N²)라고 할 수 있다.

N²
3N² + 10N
0.5N² + 100N + 300

상수배와 낮은 차수의 항을 무시하고 성장 속도의 상한을 보는 것이기 때문이다.

그리고 조금 더 엄밀하게 말하면

N

인 알고리즘도

O(N²)

라고 말할 수 있다.

왜냐하면 충분히 큰 N에서

N ≤ N²

이기 때문이다.

하지만 알고리즘의 성장률을 설명하면서 일부러 느슨하게

O(N²)

라고 표현하기보다는 더 정확한 경계인

O(N)

을 사용하는 것이 일반적으로 더 유용하다.

14. Big-Ω도 마찬가지다

Big-Ω는 하한이다.

예를 들어

f(N) = N²

이라면

f(N) = Ω(N²)

이다.

그런데

f(N) = Ω(N)

도 맞다.

왜냐하면 충분히 큰 N에서

N² ≥ N

이기 때문이다.

즉 Big-O와 Big-Ω는 각각 하나의 값만 가리키는 것이 아니라 가능한 상한과 하한의 집합을 표현한다고 생각하면 이해하기 쉽다.

15. Big-Θ는 위와 아래가 같은 경우

Big-Theta는 상한과 하한을 동시에 잡을 수 있을 때 사용한다.

c₁g(N) ≤ f(N) ≤ c₂g(N)

이 관계가 충분히 큰 N에서 성립한다면

f(N) = Θ(g(N))

이다.

예를 들어

f(N) = 10N² + 3N + 20

이라면 충분히 큰 N에서

c₁N² ≤ f(N) ≤ c₂N²

인 상수 c₁, c₂를 찾을 수 있다.

따라서

f(N) = Θ(N²)

이다.

그림으로 생각하면

c₂N²  ─────────────────  상한
              ↑
       f(N) = 10N² + 3N + 20
              ↓
c₁N²  ─────────────────  하한

처럼 f(N)을 같은 성장률을 가진 함수의 상수배 사이에 끼워 넣는 것이다.

16. O, Ω, Θ를 한 번에 이해하기

다음 함수가 있다고 하자.

f(N) = 5N² + 2N + 10

N이 충분히 커지면 N² 항이 지배한다.

그래서

f(N) = O(N²)

이라고 할 수 있다.

N²의 상수배가 위에서 f(N)을 덮을 수 있기 때문이다.

동시에

f(N) = Ω(N²)

이다.

N²의 상수배를 아래쪽 경계로 잡을 수 있기 때문이다.

두 조건이 모두 성립하므로

f(N) = Θ(N²)

이다.

정리하면

             위쪽 경계
                 ↓
Big-O      → 상한

Big-Theta  → 위와 아래가 같은 성장률

Big-Omega  → 하한
                 ↑
             아래쪽 경계

라고 기억할 수 있다.

17. Best Case와 Worst Case하고 같은 말일까?

여기서 또 하나 조심해야 한다.

흔히

Big-O = Worst Case
Big-Ω = Best Case

라고 외우기도 한다.

하지만 엄밀하게는 같은 개념이 아니다.

Big-O와 Big-Ω는 함수의 점근적 상한과 하한을 표현하는 수학적 표기법이다.

반면

Best Case
Worst Case
Average Case

는 어떤 입력 상황에서 비용을 분석하는지를 나타낸다.

예를 들어 Worst Case 실행시간 함수 자체에 대해서도

O(...)
Ω(...)
Θ(...)

를 이야기할 수 있다.

따라서 시험에서는 교수님 강의의 표현을 따라가되 개념적으로는

O  → asymptotic upper bound
Ω  → asymptotic lower bound
Θ  → asymptotically tight bound

로 이해해두는 것이 좋다.

18. Tilde와 Big-Theta는 비슷해 보이지만 다르다

다음 함수가 있다고 하자.

f(N) = 3N² + 10N + 5

Tilde notation에서는

f(N) ~ 3N²

이다.

왜냐하면

f(N) / 3N² → 1

이기 때문이다.

반면

f(N) = Θ(N²)

이다.

Theta에서는 상수배를 무시하기 때문이다.

그래서

Tilde
3N² + 10N + 5
        ↓
      ~ 3N²


Theta
3N² + 10N + 5
        ↓
      Θ(N²)

라고 구분하면 된다.

19. 1-SUM과 2-SUM으로 다시 돌아가보자

이제 처음의 알고리즘을 다시 보면 성장률이 보인다.

1-SUM

for (int i = 0; i < N; i++) {

    if (a[i] == 0) {
        count++;
    }
}

배열을 한 번 순회한다.

N에 비례

따라서 성장 차수는

Θ(N)

으로 이해할 수 있다.

2-SUM

for (int i = 0; i < N; i++) {

    for (int j = i + 1; j < N; j++) {

        if (a[i] + a[j] == 0) {
            count++;
        }
    }
}

두 원소의 모든 조합을 확인한다.

조합의 수는

N(N - 1) / 2

= 1/2 N² - 1/2 N

이다.

Tilde notation으로 보면

~ 1/2 N²

이고 성장 차수로 보면

Θ(N²)

이다.

즉 입력이 커질수록 1-SUM과 2-SUM의 차이는 급격히 커진다.

1-SUM → linear

2-SUM → quadratic

20. 자주 등장하는 성장률

알고리즘에서는 다음 성장률을 자주 보게 된다.

1
log N
N
N log N
N²
N³
2^N

입력 N이 커질수록 일반적으로

1
<
log N
<
N
<
N log N
<
N²
<
N³
<
2^N

순서로 빠르게 증가한다.

따라서 같은 문제를 해결한다면 보통 성장률이 낮은 알고리즘이 큰 입력에서 훨씬 유리하다.

핵심 정리

이번 내용을 공부하면서 가장 헷갈렸던 부분은 ~, O, Ω, Θ가 모두 비슷하게 보인다는 것이었다.

하지만 역할을 나누면 생각보다 간단하다.

Tilde ~

정확한 leading term에 관심
lower-order term 제거

3N² + 10N + 5
~ 3N²

Big-O

점근적 상한

f(N) ≤ c·g(N)

Big-Ω

점근적 하한

f(N) ≥ c·g(N)

Big-Θ

점근적으로 같은 성장 차수

c₁g(N) ≤ f(N) ≤ c₂g(N)

그리고

f(N) = 10N² + 3N + 20

같은 함수가 있다면 직관적으로

       c₂N²
         ↑
         │
       f(N)
         │
         ↓
       c₁N²

처럼 같은 N² 성장률의 함수 사이에 들어간다고 생각할 수 있다.

따라서

f(N) = O(N²)
f(N) = Ω(N²)
f(N) = Θ(N²)

이다.

결국 알고리즘 분석에서 궁금한 것은 작은 연산 몇 번의 차이가 아니다.

N이 매우 커졌을 때 무엇이 이 알고리즘의 실행 비용을 지배하는가?

이 질문을 답하기 위해 정확한 명령 횟수에서 출발해 Tilde notation으로 단순화하고, O·Ω·Θ 같은 점근적 표기법으로 성장률을 표현하는 것이다.

컴퓨팅 문제와 알고리즘 3장에서는 Queue에서 시작해서 Generics, Iterator, Bag을 거쳐 정렬 알고리즘까지 다룬다.

처음 보면 서로 크게 관련 없어 보이는 내용들이 한 장에 모여 있다.

그런데 공부하면서 생각해보면 공통된 질문이 있다.

데이터를 어떤 구조로 저장하고, 어떤 방식으로 접근하고, 얼마나 효율적으로 처리할 것인가?

Queue에서는 데이터를 넣고 빼는 위치를 고민하고, Generics에서는 하나의 자료구조를 여러 타입에 안전하게 사용하는 방법을 고민한다.

Iterator는 자료구조 내부 구현을 몰라도 데이터를 순회할 수 있게 하고, 정렬에서는 데이터의 순서를 효율적으로 바꾸는 방법을 고민한다.

이번 글에서는 이 흐름을 따라 3장의 내용을 정리해보려고 한다.

1. Queue란?

Queue는 먼저 들어온 데이터가 먼저 나오는 자료구조다.

이를 FIFO라고 한다.

FIFO
First In First Out

먼저 들어온 데이터
→ 먼저 나간다.

예를 들어 사람들이 줄을 서 있다고 생각하면 된다.

입구 → A → B → C → 출구

A가 가장 먼저 들어왔다면 A가 가장 먼저 나간다.

Queue에서는 데이터를 넣는 연산을

enqueue

라고 하고,

데이터를 제거하는 연산을

dequeue

라고 한다.

중요한 점은 삽입 위치와 삭제 위치가 서로 다르다는 것이다.

dequeue                         enqueue
   ↓                               ↓

[ A ] → [ B ] → [ C ] → [ D ]
  ↑                         ↑
front                      rear

새로운 데이터는 뒤쪽에 추가하고 가장 오래된 데이터는 앞쪽에서 제거한다.

따라서 Queue를 구현하려면 보통

front
rear

두 위치를 관리해야 한다.

2. 왜 front와 rear가 모두 필요할까?

Queue의 핵심 연산을 다시 생각해보자.

enqueue
→ 가장 뒤에 데이터 추가

dequeue
→ 가장 앞의 데이터 제거

따라서 빠르게 처리하려면

가장 앞이 어디인지
가장 뒤가 어디인지

를 모두 알고 있는 것이 유리하다.

Linked List로 Queue를 구현한다면 개념적으로 다음과 같다.

front                         rear
  ↓                             ↓

[A] → [B] → [C] → [D] → null

dequeue()를 하면

front
  ↓

[A] → [B] → [C]

에서 A를 제거하고

      front
        ↓

       [B] → [C]

처럼 front만 다음 노드로 이동시키면 된다.

반대로 enqueue(D)를 한다면 rear가 마지막 노드를 알고 있으므로 바로 뒤에 연결할 수 있다.

3. rear를 저장하지 않으면 어떻게 될까?

강의자료에는 다음과 같은 문제가 등장한다.

Null-terminated singly-linked list로 Queue를 구현하는데 front는 유지하고, 가장 최근에 추가된 item의 reference인 end는 유지하지 않는다면 enqueue와 dequeue의 최악 실행시간은 어떻게 될까?

여기서 핵심은 rear가 없다는 것이다.

현재 구조가 다음과 같다고 하자.

front
  ↓

[A] → [B] → [C] → [D] → null

dequeue()는 간단하다.

front가 이미 A를 가리키고 있으므로

front = front.next;

처럼 처리할 수 있다.

따라서 데이터 개수 N에 관계없이 일정한 작업만 수행한다.

dequeue → O(1)

그런데 enqueue는 다르다.

rear가 없으므로 마지막 노드를 모른다.

새로운 E를 추가하려면

A
↓
B
↓
C
↓
D
↓
null 발견
↓
E 연결

처럼 처음부터 끝까지 이동해야 한다.

N개의 데이터가 있다면 최악의 경우 N개 정도를 따라가야 한다.

따라서

enqueue → O(N)
dequeue → O(1)

이 된다.

이 문제를 통해 왜 Queue 구현에서 front와 rear를 함께 유지하는지가 이해된다.

포인터 하나를 더 저장하는 대신 연산 시간을 줄이는 것이다.

4. Linked List와 Array로 Queue를 구현하면?

Queue는 Linked List뿐 아니라 Array로도 구현할 수 있다.

Linked List 방식은 각 데이터가 다음 노드를 가리키는 링크를 가지고 있어야 한다.

[item | next] → [item | next] → [item | next]

따라서 링크를 저장하기 위한 추가 공간이 필요하다.

반면 Array는 연속된 공간에 데이터를 저장할 수 있다.

[ A ][ B ][ C ][ D ][   ][   ]

하지만 배열은 크기 문제를 고민해야 한다.

Queue에 앞으로 데이터가 몇 개 들어올지 클라이언트가 정확히 알 수 없다면 처음 배열의 크기를 어떻게 정할 것인지가 문제가 된다.

결국 자료구조 구현에서는 항상 이런 trade-off가 등장한다.

Linked List
→ 링크를 위한 추가 공간 필요

Array
→ 크기 관리 문제 발생

5. 그런데 Queue에 String만 넣어야 할까?

자료구조를 구현하다 보면 또 다른 문제가 생긴다.

예를 들어 다음과 같은 Stack이 있다고 하자.

class StringStack {
    String[] data;
}

String을 저장할 때는 문제가 없다.

그런데 Integer도 저장하고 싶다면?

class IntegerStack {
    Integer[] data;
}

Double도 저장하려면?

class DoubleStack {
    Double[] data;
}

자료형이 달라질 때마다 거의 똑같은 코드를 다시 작성해야 한다.

이것은 상당히 비효율적이다.

코드를 복사해서 계속 수정해야 하고, 한 구현에서 버그를 수정했다면 다른 구현도 모두 수정해야 할 수 있다.

그래서 Generics가 필요해진다.

6. Object로 받으면 되지 않을까?

Java의 모든 클래스는 Object를 기반으로 하므로 다음처럼 만들 수도 있다.

class Stack {
    Object[] data;
}

그러면 String도 넣을 수 있고 Integer도 넣을 수 있다.

stack.push("Hello");
stack.push(Integer.valueOf(10));

하지만 꺼낼 때 문제가 생긴다.

String value = (String) stack.pop();

Object로 저장했기 때문에 다시 원래 타입으로 casting해야 한다.

그리고 잘못된 타입으로 casting하면 문제가 실행 중에 발견된다.

강의자료에서 강조하는 원칙이 여기서 나온다.

Welcome compile-time errors.
Avoid run-time errors.

즉,

가능하다면 오류를 실행 중에 발견하지 말고 컴파일할 때 발견하자.

이것이 Generic을 사용하는 중요한 이유다.

7. Generic을 사용하면?

Generic을 사용하면 자료구조를 다음처럼 만들 수 있다.

public class Stack<Item> {

    private Item[] s;

    public void push(Item item) {
        ...
    }

    public Item pop() {
        ...
    }
}

여기서 Item은 특정 자료형 하나를 의미하는 것이 아니다.

사용할 때 실제 타입을 지정한다.

Stack<String> s1;
Stack<Integer> s2;

같은 Stack 구현을 사용하면서 저장할 데이터 타입만 바꿀 수 있다.

Stack<Item>
     ↓

Stack<String>
Stack<Integer>
Stack<Double>

이렇게 하면 클라이언트에서 불필요한 casting을 줄일 수 있고 타입이 맞지 않는 문제를 컴파일 단계에서 발견할 수 있다.

8. Generic 배열은 바로 만들 수 없다

강의자료의 구현에서 주의할 부분이 하나 있다.

다음 코드는 Java에서 허용되지 않는다.

s = new Item[capacity];

Generic type의 배열을 직접 생성할 수 없기 때문이다.

그래서 강의에서는 다음과 같은 형태를 사용한다.

s = (Item[]) new Object[capacity];

먼저 Object 배열을 만들고

new Object[capacity]

이를

(Item[])

로 casting하는 방식이다.

Generic 자료구조 구현 문제를 볼 때 자주 등장하는 형태이므로 기억해둘 필요가 있다.

9. primitive type은 Generic에 넣을 수 있을까?

다음과 같이 작성할 수 있을까?

Stack<int> stack;

Java Generic에는 primitive type을 직접 사용할 수 없다.

대신 Wrapper Class를 사용한다.

int     → Integer
long    → Long
float   → Float
double  → Double
byte    → Byte
short   → Short
char    → Character
boolean → Boolean

따라서

Stack<Integer> stack = new Stack<>();

처럼 사용한다.

그런데 실제 사용할 때는 다음처럼 작성할 수 있다.

stack.push(17);

17은 int인데 Integer를 요구하는 곳에 넣을 수 있다.

이것이 Autoboxing이다.

개념적으로 Java가

stack.push(Integer.valueOf(17));

처럼 처리해주는 것이다.

반대로 Integer를 int로 꺼내는 것도 자동으로 처리할 수 있다.

int a = stack.pop();

이를 Unboxing이라고 생각할 수 있다.

10. Iterator는 왜 필요할까?

자료구조 안에 데이터가 여러 개 있다고 하자.

클라이언트 입장에서는 자료구조가 내부적으로

Array인지
Linked List인지

알고 싶지 않을 수도 있다.

그냥

저장된 데이터를 처음부터 하나씩 보고 싶다.

는 요구가 있을 수 있다.

이때 Iterator를 사용할 수 있다.

Iterator는 데이터를 하나씩 순회하기 위한 인터페이스다.

핵심 메서드는

hasNext()
next()

이다.

hasNext()
→ 다음 데이터가 존재하는가?

next()
→ 다음 데이터를 가져온다.

11. Iterable과 Iterator는 다르다

이 둘은 이름이 비슷해서 구분할 필요가 있다.

Iterable은 Iterator를 제공하는 객체다.

개념적으로

interface Iterable<Item> {
    Iterator<Item> iterator();
}

형태다.

반면 Iterator는 실제 순회를 담당한다.

interface Iterator<Item> {

    boolean hasNext();

    Item next();
}

즉 관계를 생각하면

Iterable
   │
   │ iterator()
   ↓
Iterator
   │
   ├── hasNext()
   └── next()

이다.

자료구조가 Iterable을 구현하면 다음과 같은 enhanced for문을 사용할 수 있다.

for (String item : stack) {
    System.out.println(item);
}

12. enhanced for문 뒤에서는 무엇이 일어날까?

다음 코드는 매우 간단해 보인다.

for (String item : stack) {
    System.out.println(item);
}

하지만 Iterator를 명시적으로 사용하면 다음과 같은 흐름이다.

Iterator<String> it = stack.iterator();

while (it.hasNext()) {

    String item = it.next();

    System.out.println(item);
}

즉

for-each

를 이해하려면

Iterable
→ iterator()
→ Iterator
→ hasNext()
→ next()

의 연결을 알고 있으면 된다.

13. Bag은 무엇일까?

이번 장에서는 Bag이라는 자료구조도 등장한다.

Bag은 데이터를 추가하고 순회할 수 있는 자료구조다.

특징은 순서가 중요하지 않다는 것이다.

Bag

add(A)
add(B)
add(C)

→ 저장

순회 가능
→ 하지만 순서 자체가 핵심이 아님

강의자료에서는 Bag을

Stack without pop

또는

Queue without dequeue

처럼 생각할 수 있다고 설명한다.

즉 데이터를 넣은 뒤 제거 순서를 관리하는 것보다 데이터를 모아두고 순회하는 것에 초점이 있다.

14. Stack은 실제 어디에서 사용될까?

Stack은 LIFO 구조다.

Last In First Out

마지막에 들어온 데이터가 먼저 나온다.

Stack은 실제 여러 곳에서 사용된다.

Compiler Parsing
Java Virtual Machine
문서 편집기의 Undo
웹 브라우저의 Back 버튼
함수 호출 관리

예를 들어 브라우저에서

Google
↓
Naver
↓
GitHub

순서로 이동했다고 하자.

뒤로 가기를 누르면 가장 최근 페이지인 GitHub에서 이전 페이지로 돌아간다.

이런 구조가 Stack의 LIFO와 잘 맞는다.

15. 수식 계산에도 Stack을 사용할 수 있다

강의자료에서는 Stack의 응용으로 Two-Stack Algorithm을 소개한다.

하나는 연산자를 저장한다.

Operator Stack

다른 하나는 값을 저장한다.

Value Stack

규칙은 다음과 같다.

숫자
→ Value Stack에 push

연산자
→ Operator Stack에 push

왼쪽 괄호 (
→ 무시

오른쪽 괄호 )
→ 연산자 하나와 값 두 개를 pop
→ 계산
→ 결과를 Value Stack에 다시 push

예를 들어

(1 + ((2 + 3) * (4 * 5)))

같은 수식을 두 개의 Stack을 이용해 계산할 수 있다.

이 예제에서 중요한 것은 Stack이 단순히 데이터를 뒤집는 자료구조가 아니라 아직 처리하지 않은 연산을 임시로 보관하는 데 사용할 수 있다는 것이다.

16. Stack 두 개로 Queue를 만들 수 있을까?

강의자료에는 흥미로운 문제가 나온다.

Stack 두 개를 이용해서 Queue를 구현하라.

처음에는 이상하다.

Stack은

LIFO

이고 Queue는

FIFO

다.

서로 반대인데 어떻게 Stack으로 Queue를 만들 수 있을까?

핵심은 두 번 뒤집는 것이다.

예를 들어 Stack1에

A
B
C
D

순서로 넣었다고 하자.

Stack의 top에는 가장 최근 데이터가 있다.

Stack1

TOP
 ↓
[D]
[C]
[B]
[A]

이 데이터를 하나씩 pop해서 Stack2에 넣는다.

Stack2

TOP
 ↓
[A]
[B]
[C]
[D]

순서가 다시 뒤집혔다.

이제 Stack2에서 pop하면

A

가 먼저 나온다.

즉 가장 먼저 들어온 A가 가장 먼저 나온다.

FIFO

가 만들어졌다.

17. 그런데 매번 옮기면 느리지 않을까?

여기서 중요한 것이 Amortized Analysis다.

매 연산마다 모든 데이터를

Stack1 → Stack2

로 옮긴다면 비용이 상당히 커질 수 있다.

하지만 데이터를 한 번 이동시킨 뒤 Stack2에 남겨두고 필요한 동안 계속 사용하면 이야기가 달라진다.

각 원소의 이동을 보면 대략

Stack1에 push
↓
필요할 때 Stack2로 이동
↓
Stack2에서 pop

정도의 제한된 횟수만 처리된다.

어떤 한 번의 연산은 O(N)이 걸릴 수 있지만 여러 연산 전체의 비용을 나눠보면 연산 하나당 평균적인 비용을 상수 수준으로 볼 수 있다.

이것이 amortized constant time을 이해하는 핵심이다.

최악의 한 번만 보는 것이 아니라 여러 연산에 걸친 전체 비용을 나누어 생각한다.

18. 메모리 사용량도 알고리즘의 비용이다

알고리즘을 평가할 때 실행 시간만 중요한 것은 아니다.

메모리를 얼마나 사용하는지도 중요하다.

Java 객체에는 우리가 선언한 필드만 들어 있는 것이 아니다.

개념적으로

Object Overhead
Fields
Padding

등이 존재할 수 있다.

예를 들어 Integer 객체라면 단순히

int x;

4바이트만 사용하는 것으로 끝나지 않는다.

객체 자체를 관리하기 위한 추가 메모리가 필요하다.

Linked List의 Node도 마찬가지다.

class Node {

    Item item;
    Node next;
}

여기에는

item reference
next reference
object overhead

등이 필요하다.

그래서 Linked List가 Array보다 추가적인 메모리를 사용할 수 있다는 설명과 연결된다.

19. 배열도 데이터만큼의 메모리만 사용하는 것은 아니다

배열 역시 객체다.

예를 들어

int[] a = new int[N];

이라면 N개의 int 값뿐 아니라 배열 객체 자체를 관리하기 위한 메모리도 존재한다.

강의자료에서는 배열의 종류에 따라 필요한 메모리를 비교한다.

int[]
double[]
Date[]
double[][]

특히 객체 배열은 객체 자체를 배열 안에 직접 저장하는 것이 아니라 객체를 가리키는 reference들을 저장한다는 점을 구분해야 한다.

Date[]

[ref] → Date 객체
[ref] → Date 객체
[ref] → Date 객체

따라서 객체 배열의 메모리를 계산할 때는

배열 자체
+
reference
+
실제 객체

를 구분해서 생각해야 한다.

20. 이제 정렬로 넘어가자

3장의 후반부에서는 Elementary Sorts를 다룬다.

대표적으로

Selection Sort
Insertion Sort
Shellsort

가 등장한다.

먼저 Selection Sort와 Insertion Sort의 차이를 이해해야 한다.

21. Selection Sort는 어떻게 동작할까?

Selection Sort는 이름 그대로 가장 작은 값을 선택한다.

배열이 다음과 같다고 하자.

[5, 3, 4, 1, 2]

첫 번째 위치에 들어갈 가장 작은 값을 찾는다.

[5, 3, 4, 1, 2]
          ↑
         최소

1을 찾았다.

첫 번째 값 5와 교환한다.

[1, 3, 4, 5, 2]

이제 첫 번째 위치는 정렬이 끝났다.

다음 범위에서 다시 가장 작은 값을 찾는다.

[1 | 3, 4, 5, 2]
                ↑
               최소

2와 3을 교환한다.

[1, 2, 4, 5, 3]

이 과정을 반복한다.

즉 Selection Sort의 핵심은

현재 위치
↓
오른쪽에서 최소값 탐색
↓
현재 위치와 최소값 교환

이다.

22. Selection Sort 코드를 읽어보자

강의자료의 핵심 코드는 다음 구조다.

for (int i = 0; i < n; i++) {

    int min = i;

    for (int j = i + 1; j < n; j++) {

        if (less(a[j], a[min])) {
            min = j;
        }
    }

    exch(a, i, min);
}

한 줄씩 보면 어렵지 않다.

int min = i;

현재 위치를 일단 최소값이라고 가정한다.

그다음

for (int j = i + 1; j < n; j++)

로 오른쪽 데이터를 전부 확인한다.

더 작은 값이 발견되면

min = j;

로 최소값의 위치를 바꾼다.

탐색이 끝나면

exch(a, i, min);

으로 현재 위치와 최소값을 교환한다.

강의자료에서 Selection Sort 코드 부분에 '코드 시험' 표시가 있으므로 직접 손으로 추적할 수 있어야 한다.

23. Selection Sort는 이미 정렬되어 있으면 빨라질까?

다음 배열을 생각해보자.

1 2 3 4 5

이미 정렬되어 있다.

그렇다면 Selection Sort는 바로 끝날까?

아니다.

Selection Sort는 현재 값이 정말 최소인지 확인하기 위해 오른쪽 데이터를 계속 검사한다.

첫 번째 단계에서는

N - 1

번 비교한다.

그다음에는

N - 2

번 비교한다.

계속하면

(N-1) + (N-2) + ... + 1

이 된다.

이는 대략

N² / 2

에 비례한다.

따라서 Selection Sort는 입력 배열이 이미 정렬되어 있더라도 비교 횟수가 크게 줄지 않는다.

24. Insertion Sort는 어떻게 동작할까?

Insertion Sort는 앞부분이 이미 정렬되어 있다고 생각하고 새로운 값을 적절한 위치에 끼워 넣는다.

카드를 손으로 정렬하는 모습을 생각하면 이해하기 쉽다.

예를 들어

[2, 5, 7 | 4]

앞의

2, 5, 7

은 이미 정렬되어 있다.

새로운 값 4를 넣으려면 왼쪽으로 이동하면서 비교한다.

4 < 7
→ 이동

4 < 5
→ 이동

4 > 2
→ 멈춤

결과는

[2, 4, 5, 7]

이 된다.

즉 Insertion Sort는

현재 원소를 왼쪽의 정렬된 영역에서 알맞은 위치까지 이동시킨다.

25. Selection Sort와 Insertion Sort의 결정적인 차이

Selection Sort는 매번 남은 데이터 전체를 확인해서 최소값을 찾는다.

Selection Sort

최솟값 찾기
↓
교환
↓
최솟값 찾기
↓
교환

반면 Insertion Sort는 현재 데이터가 이미 올바른 위치에 가까우면 많은 이동을 할 필요가 없다.

그래서 입력 데이터가 이미 어느 정도 정렬되어 있는가가 성능에 영향을 준다.

강의자료에서 Insertion Sort의 Best Case는

이미 오름차순으로 정렬된 배열

이다.

이 경우 각 원소마다 바로 왼쪽 정도만 확인하면 된다.

따라서

N - 1 compares
0 exchanges

정도가 된다.

반면 Worst Case는 역순이다.

5 4 3 2 1

새로운 원소가 들어올 때마다 왼쪽 끝까지 이동해야 한다.

강의자료에서는 대략

1/2 N² compares
1/2 N² exchanges

로 설명한다.

강의자료에 '삽입정렬 시험'이라고 직접 표시되어 있으므로 Best Case와 Worst Case의 차이를 특히 확인할 필요가 있다.

26. 왜 Insertion Sort를 개선하려고 했을까?

Insertion Sort에는 약점이 있다.

원소가 한 번에 크게 이동하지 못한다.

예를 들어 작은 값이 배열의 아주 오른쪽에 있다고 하자.

[9, 8, 7, 6, 5, 4, 3, 2, 1]
                                ↑

1이 맨 앞으로 가려면

1칸
1칸
1칸
1칸
...

씩 계속 이동해야 한다.

즉 멀리 떨어진 위치로 이동해야 하는 원소가 많으면 비효율적이다.

여기서 등장하는 것이 Shellsort다.

27. Shellsort는 Insertion Sort를 어떻게 개선할까?

Shellsort는 Insertion Sort의 확장이라고 볼 수 있다.

핵심 아이디어는 간단하다.

처음부터 옆에 있는 데이터만 비교하지 말고 멀리 떨어진 데이터끼리 먼저 정렬하자.

이를 h-sort라고 한다.

예를 들어

h = 4

라면 바로 옆의 데이터가 아니라 4칸 떨어진 데이터들을 비교한다.

0 ↔ 4 ↔ 8
1 ↔ 5 ↔ 9
2 ↔ 6 ↔ 10
3 ↔ 7 ↔ 11

이렇게 하면 멀리 떨어져 있던 값이 한 번에 큰 거리를 이동할 수 있다.

강의자료에서 표현한 핵심은

Big increments
→ small subarray

Small increments
→ nearly in order

이다.

처음에는 큰 간격으로 거칠게 정렬한다.

그다음 간격을 줄인다.

큰 h
↓
부분적으로 정렬
↓
더 작은 h
↓
더 정렬됨
↓
h = 1
↓
Insertion Sort

마지막에 h가 1이 되면 일반적인 Insertion Sort와 같은 형태가 된다.

하지만 그 시점에는 배열이 이미 상당히 정렬되어 있으므로 Insertion Sort가 훨씬 빠르게 동작할 수 있다.

28. Shellsort의 h는 어떻게 정할까?

강의에서는 Knuth의 3x+1 증가 수열을 사용한다.

1, 4, 13, 40, 121, ...

다음 h를 만드는 식은

h = 3h + 1

이다.

코드에서는 다음과 같은 구조가 등장한다.

int h = 1;

while (h < N / 3) {
    h = 3 * h + 1;
}

예를 들어 데이터가 16개라면 사용할 수 있는 h는

1
4
13

이다.

실제 정렬은 큰 값부터 진행한다.

13-sort
↓
4-sort
↓
1-sort

즉

멀리 떨어진 데이터 먼저 정리
↓
간격을 줄이면서 다시 정리
↓
마지막에 일반 Insertion Sort

라고 이해하면 된다.

29. Shellsort 코드에서 Insertion Sort가 보이는 이유

Shellsort 코드를 보면 다음과 비슷한 부분이 등장한다.

for (int i = h; i < N; i++) {

    for (int j = i;
         j >= h && less(a[j], a[j-h]);
         j -= h) {

        exch(a, j, j-h);
    }
}

일반 Insertion Sort와 상당히 비슷하다.

차이는

1칸씩 이동

하는 것이 아니라

h칸씩 이동

한다는 것이다.

일반 Insertion Sort가

j--

처럼 이동한다면 Shellsort는

j -= h

처럼 이동한다.

그리고 h를 계속 줄이다가 마지막에는

h = 1

이 된다.

그러면

j -= 1;

이 되므로 사실상 Insertion Sort와 같은 형태가 된다.

그래서 Shellsort를 Insertion Sort의 확장 버전이라고 이해할 수 있다.

30. Shellsort는 왜 더 빠를 수 있을까?

Insertion Sort의 문제는 큰 값이나 작은 값이 멀리 이동해야 할 때 한 칸씩 이동한다는 것이다.

Shellsort는 큰 h부터 시작하므로 한 번의 교환으로 훨씬 멀리 이동할 수 있다.

Insertion Sort

A B C D E F G H
              ↑
한 칸씩 이동


Shellsort

A B C D E F G H
↑       ↑
h칸 단위 이동 가능

그 결과 마지막 h = 1 단계에서는 배열이 이미 거의 정렬된 상태가 된다.

Insertion Sort는 거의 정렬된 배열에서 효율적이므로 마지막 단계가 빠르게 끝날 수 있다.

강의자료에서는 Knuth의 3x+1 증가 수열을 사용하는 Shellsort가 최악의 경우에도 대략 N^(3/2)에 비례한다고 설명하고 있으며, 추가 메모리를 사용하지 않고 코드도 비교적 작다는 점을 언급한다.

31. 마지막은 Shuffling

정렬과 반대로 데이터를 무작위로 섞어야 하는 경우도 있다.

Shuffling의 목표는 단순히 아무렇게나 섞는 것이 아니다.

강의자료에서는 두 가지 목표를 제시한다.

1. Linear time에 배열을 무작위 permutation으로 만든다.

2. 가능한 모든 순열이 동일한 확률로 등장하도록 한다.

즉 공정하게 섞어야 한다.

여기서 Knuth Shuffle을 사용한다.

32. Knuth Shuffle

강의자료의 코드는 다음 구조다.

public static void shuffle(Object[] a) {

    int N = a.length;

    for (int i = 0; i < N; i++) {

        int r = StdRandom.uniform(i + 1);

        Object tmp = a[i];
        a[i] = a[r];
        a[r] = tmp;
    }
}

핵심은 현재 위치 i에 도달했을 때

0 ~ i

범위에서 임의의 위치 r을 선택한다는 것이다.

그리고

a[i]
a[r]

을 교환한다.

각 위치를 한 번씩 처리하므로 전체 반복은 N번이다.

따라서 실행 시간은

O(N)

으로 볼 수 있다.

33. 3장을 하나의 흐름으로 보면

처음에는 Queue, Generic, Iterator, 정렬이 왜 한 장에 같이 있는지 조금 뜬금없어 보였다.

하지만 전체를 다시 보면 계속 같은 질문을 하고 있었다.

Queue
→ 데이터를 어떤 순서로 넣고 뺄 것인가?

Generics
→ 같은 자료구조를 여러 타입에 어떻게 안전하게 사용할 것인가?

Iterator
→ 내부 구현을 몰라도 데이터를 어떻게 순회할 것인가?

Bag
→ 순서가 중요하지 않은 데이터는 어떻게 모아둘 것인가?

Stack
→ LIFO 구조를 어디에 활용할 수 있는가?

Two-Stack Queue
→ 기존 자료구조를 조합해서 다른 자료구조를 만들 수 있는가?

Memory
→ 자료구조가 실제로 얼마나 많은 공간을 사용하는가?

Selection Sort
→ 최솟값을 반복해서 선택하면 정렬할 수 있는가?

Insertion Sort
→ 정렬된 영역에 새로운 값을 삽입하면 어떻게 되는가?

Shellsort
→ Insertion Sort의 한 칸 이동 문제를 어떻게 개선할 수 있는가?

Shuffling
→ 데이터를 공정하게 무작위 순서로 만들려면 어떻게 해야 하는가?

결국 자료구조와 알고리즘은 단순히 코드를 외우는 문제가 아니었다.

어떤 연산을 빠르게 만들기 위해 무엇을 저장하고, 어떤 비용을 감수할 것인가를 계속 판단하는 과정이었다.

시험 전에 다시 볼 부분

이번 강의자료에서 특히 다시 볼 부분은 Queue의 front/rear, Generic, Iterator 그리고 정렬 코드다.

Queue에서는 다음 문제를 바로 판단할 수 있어야 한다.

Singly Linked List
front만 유지
rear는 유지하지 않음

enqueue → O(N)
dequeue → O(1)

Generic에서는

Object 사용
→ casting 필요
→ type mismatch가 runtime에 발견될 가능성

Generics 사용
→ casting 감소
→ type mismatch를 compile time에 발견

의 차이를 이해해야 한다.

Iterator에서는

Iterable
→ iterator() 제공

Iterator
→ hasNext()
→ next()

관계를 기억한다.

그리고 정렬에서는 특히 다음 차이가 중요하다.

Selection Sort
→ 남은 범위에서 최소값을 찾음
→ 이미 정렬되어 있어도 비교를 계속함

Insertion Sort
→ 왼쪽의 정렬된 영역에 현재 값을 삽입
→ 이미 정렬된 배열에서 매우 적은 작업
→ 역순에서는 많은 비교와 교환

Shellsort
→ h칸 떨어진 데이터부터 정렬
→ h를 줄여가며 배열을 거의 정렬된 상태로 만듦
→ 마지막 h=1에서는 Insertion Sort

코드 역시 단순히 외우기보다 각 반복문의 역할을 이해해야 한다.

Selection Sort

i
→ 이번에 확정할 위치

j
→ 오른쪽에서 최소값 탐색

min
→ 현재까지 발견한 최소값의 위치

Shellsort에서는

h
→ 비교할 데이터 사이의 간격

j -= h
→ 한 칸이 아니라 h칸씩 왼쪽으로 이동

라는 의미를 잡고 있으면 코드를 훨씬 쉽게 읽을 수 있다.

마무리

3장을 공부하면서 가장 중요하다고 느낀 것은 자료구조의 모양 자체보다 왜 그런 구현을 선택하는지 이해하는 것이었다.

Queue에서 front와 rear를 모두 저장하는 이유도 결국 시간 때문이다.

rear 없음
→ enqueue 때 마지막 노드를 찾아야 함
→ O(N)

rear 있음
→ 마지막 위치를 이미 알고 있음
→ 빠르게 삽입 가능

Generic도 마찬가지다.

Object
→ 무엇이든 받을 수 있음
→ 대신 casting과 runtime type error 문제

Generic
→ 사용할 타입을 지정
→ compile time에 type 검사

Insertion Sort와 Shellsort의 관계도 같은 관점에서 이해할 수 있다.

Insertion Sort의 문제
→ 멀리 있는 데이터도 한 칸씩 이동

Shellsort
→ 처음에는 큰 간격으로 이동
→ 배열을 부분적으로 정렬
→ 간격을 줄임
→ 마지막에는 거의 정렬된 배열에 Insertion Sort 적용

결국 이번 장을 관통하는 질문은 이것이라고 생각한다.

“이 연산을 더 효율적으로 만들기 위해 어떤 정보를 추가로 저장하거나, 어떤 처리 순서를 선택해야 할까?”

Queue의 rear 하나부터 Shellsort의 h까지, 서로 달라 보였던 개념들이 결국 이 질문으로 연결됐다.

Java 문제를 풀다가 갑자기 이런 코드가 등장했다.

run((int n) -> n + 9)

처음 봤을 때 가장 먼저 든 생각은

->는 도대체 뭐지?

였다.

Java에서 메서드라면 보통 이렇게 생겼다.

int add(int n) {
    return n + 9;
}

그런데 문제에서는 메서드 이름도 없이

(int n) -> n + 9

라고 적혀 있었다.

더 복잡한 문제에서는 다음과 같은 코드까지 등장했다.

F f = (x) -> {
    if (x > 2) {
        throw new Exception();
    }

    return x * 2;
};

처음에는 이것이 F와 무슨 관계가 있는지, apply()는 어디로 사라졌는지, run(f)를 호출하면 무엇이 실행되는지 이해하기 어려웠다.

그런데 이 문제를 이해하려면 먼저 Java에서 동작 자체를 객체로 전달하는 방식부터 생각해볼 필요가 있었다.

1. 먼저 Runnable을 보자

Java에서 다음과 같은 코드를 볼 수 있다.

class Car implements Runnable {

    @Override
    public void run() {
        System.out.println("run");
    }
}

Runnable은 인터페이스다.

핵심적으로 실행할 작업을 run()이라는 메서드로 표현한다.

public interface Runnable {
    void run();
}

따라서

class Car implements Runnable

이라고 하면 Car는 Runnable이 요구하는

run()

을 구현해야 한다.

class Car implements Runnable {

    public void run() {
        System.out.println("run");
    }
}

즉 Car 객체는 단순히 자동차라는 데이터만 표현하는 것이 아니라 실행할 작업을 가진 객체로 사용할 수 있다.

2. 왜 Runnable 객체를 Thread에 전달할 수 있을까?

다음 코드를 보자.

Thread t = new Thread(new Car());

처음에는 Thread 생성자 안에 왜 Car 객체를 넣을 수 있는지 이상했다.

하지만 Car는

implements Runnable

을 했다.

따라서 Car 객체는 Runnable 타입으로 사용할 수 있다.

개념적으로

Runnable task = new Car();

가 가능한 것이다.

그리고 Thread는 실행할 작업을 Runnable 형태로 전달받을 수 있다.

new Car()
    ↓
Runnable 구현 객체
    ↓
Thread에 전달
    ↓
Thread가 실행할 작업을 가짐

그래서

Thread t = new Thread(new Car());

가 가능하다.

3. start()와 run()은 다르다

여기서 시험에서 자주 헷갈리는 부분이 하나 있다.

t.start();

와

t.run();

은 같지 않다.

start()는 새로운 스레드의 실행을 시작한다.

t.start()
   ↓
새로운 스레드 시작
   ↓
run() 실행

반면

t.run();

을 직접 호출하면 일반적인 메서드 호출처럼 동작한다.

즉

start()
→ 새로운 스레드의 실행을 시작

run()
→ run() 메서드를 직접 호출

이라고 구분해야 한다.

이 부분을 이해하고 나니 Runnable이 단순히 run()이라는 이름을 외우는 인터페이스가 아니라 실행할 동작을 하나의 객체로 표현하는 방식이라는 것이 조금씩 보이기 시작했다.

그리고 이 생각이 람다식으로 연결된다.

4. 함수형 인터페이스란?

다음 인터페이스가 있다고 하자.

interface F {

    int apply(int x) throws Exception;
}

F에는 구현해야 할 추상 메서드가 하나 있다.

int apply(int x) throws Exception;

이처럼 람다의 대상으로 사용할 수 있는 추상 메서드가 하나인 인터페이스를 함수형 인터페이스라고 한다.

여기서 중요한 것은 F를 구현하는 객체가 사실상 하나의 동작을 가지고 있다는 것이다.

F
└── apply(int x)

그렇다면 이 인터페이스를 구현하려면 원래 어떻게 해야 할까?

5. 클래스를 직접 만들어 구현할 수 있다

가장 익숙한 방법은 클래스를 하나 만드는 것이다.

class MyFunction implements F {

    @Override
    public int apply(int x) throws Exception {

        if (x > 2) {
            throw new Exception();
        }

        return x * 2;
    }
}

그리고

F f = new MyFunction();

이라고 하면 된다.

이제

f.apply(3);

을 호출하면 MyFunction에서 구현한 apply()가 실행된다.

하지만 이 동작 하나를 사용하기 위해 클래스를 따로 만드는 것이 번거로울 수도 있다.

6. 익명 클래스로도 만들 수 있다

별도의 클래스 이름이 필요하지 않다면 익명 클래스를 사용할 수도 있다.

F f = new F() {

    @Override
    public int apply(int x) throws Exception {

        if (x > 2) {
            throw new Exception();
        }

        return x * 2;
    }
};

별도의 MyFunction 클래스를 만들지는 않았지만 F의 apply()를 구현한 객체를 바로 만들었다.

그런데 이것도 상당히 길다.

우리가 정말 표현하고 싶은 핵심은 사실 다음 부분이다.

int apply(int x) throws Exception {

    if (x > 2) {
        throw new Exception();
    }

    return x * 2;
}

그리고 F에는 구현할 추상 메서드가 하나뿐이다.

그렇다면 Java 입장에서는 어떤 메서드를 구현하려는 것인지 이미 알 수 있다.

그래서 이 부분을 더 간결하게 표현할 수 있다.

그것이 람다식(Lambda Expression)이다.

7. 람다식으로 바꾸면

익명 클래스 형태의 다음 코드를

F f = new F() {

    @Override
    public int apply(int x) throws Exception {

        if (x > 2) {
            throw new Exception();
        }

        return x * 2;
    }
};

람다로 표현하면 다음과 같이 간단해진다.

F f = (x) -> {

    if (x > 2) {
        throw new Exception();
    }

    return x * 2;
};

처음에는 apply라는 이름이 사라져서 이상했다.

하지만 F에는 람다의 대상이 되는 추상 메서드가 하나뿐이다.

int apply(int x) throws Exception;

따라서 Java는 이 람다가 apply()에 해당하는 동작이라는 것을 알 수 있다.

개념적으로는

F f = (x) -> x * 2;

를 볼 때

F의 추상 메서드
        ↓
apply(int x)
        ↓
구현 내용
        ↓
return x * 2;

라고 연결해서 생각하면 된다.

8. (int n) -> n + 9는 어떻게 읽을까?

이제 처음에 이해되지 않았던 코드를 다시 보자.

(int n) -> n + 9

처음에는 문법을 세세하게 분석하기보다 다음처럼 읽는 것이 가장 쉬웠다.

int n을 받아서 n + 9를 반환한다.

즉

입력
 ↓
 n
 ↓
n + 9
 ↓
결과

다.

예를 들어

(int n) -> n * 2

라면

int n을 받아서 n의 2배를 반환한다.

이고,

(int n) -> n + 9

라면

int n을 받아서 9를 더한 값을 반환한다.

라고 읽으면 된다.

9. 한 줄짜리 람다는 return도 생략할 수 있다

다음 람다를 보자.

(int n) -> n + 9

여기에는 return이 없다.

하지만 값을 반환하는 표현식 하나로 구성된 람다는 결과를 그대로 반환하는 형태로 사용할 수 있다.

따라서 개념적으로

(int n) -> n + 9

는

(int n) -> {
    return n + 9;
}

와 연결해서 이해할 수 있다.

그리고 F의 apply()와 연결하면

int apply(int n) {
    return n + 9;
}

와 같은 동작이라고 생각할 수 있다.

10. 매개변수 타입도 생략되는 이유

다음 두 표현을 볼 수 있다.

(int n) -> n + 9

(n) -> n + 9

상황에 따라 두 번째처럼 타입이 생략될 수도 있다.

왜냐하면 람다가 어떤 함수형 인터페이스를 대상으로 하는지 알면 매개변수 타입도 알 수 있기 때문이다.

예를 들어

interface F {
    int apply(int x) throws Exception;
}

이라면 apply()의 매개변수는 이미

int

라고 정의되어 있다.

그래서

F f = (x) -> x * 2;

에서 x가 int라는 것을 추론할 수 있다.

11. 이제 실제 문제를 풀어보자

문제는 다음과 같다.

public class Main {

    static interface F {
        int apply(int x) throws Exception;
    }

    public static int run(F f) {

        try {
            return f.apply(3);

        } catch (Exception e) {
            return 7;
        }
    }

    public static void main(String[] args) {

        F f = (x) -> {

            if (x > 2) {
                throw new Exception();
            }

            return x * 2;
        };

        System.out.print(
            run(f) + run((int n) -> n + 9)
        );
    }
}

처음에는 코드가 복잡해 보이지만 람다를 apply()의 구현이라고 생각하면 하나씩 따라갈 수 있다.

12. 먼저 run(f)를 계산해보자

run()은 다음과 같다.

public static int run(F f) {

    try {
        return f.apply(3);

    } catch (Exception e) {
        return 7;
    }
}

즉 F 객체를 하나 전달받아서

f.apply(3);

을 호출한다.

현재 전달한 f는 다음 람다다.

F f = (x) -> {

    if (x > 2) {
        throw new Exception();
    }

    return x * 2;
};

이를 apply()처럼 펼쳐 생각해보면

int apply(int x) throws Exception {

    if (x > 2) {
        throw new Exception();
    }

    return x * 2;
}

와 같은 동작이다.

13. apply(3)을 실행하면

run(f) 내부에서는

f.apply(3);

을 호출한다.

따라서

x = 3

이다.

조건을 확인한다.

if (x > 2)

즉

3 > 2

이므로 참이다.

따라서

throw new Exception();

이 실행된다.

흐름은 다음과 같다.

run(f)
   ↓
f.apply(3)
   ↓
x = 3
   ↓
3 > 2
   ↓
true
   ↓
Exception 발생

14. 예외가 발생하면 어디로 갈까?

f.apply(3)은 try 안에서 실행되고 있다.

try {
    return f.apply(3);
} catch (Exception e) {
    return 7;
}

따라서 Exception이 발생하면 catch로 이동한다.

Exception 발생
      ↓
catch (Exception e)
      ↓
return 7

결국

run(f)

의 결과는

7

이다.

15. 두 번째 람다를 보자

두 번째 호출은 다음과 같다.

run((int n) -> n + 9)

처음에는 run()의 매개변수가 F인데 어떻게 갑자기 람다를 바로 넣을 수 있는지 헷갈렸다.

run()을 다시 보면

public static int run(F f)

다.

즉 F 타입의 동작을 전달해야 한다.

그리고 F는

interface F {
    int apply(int x) throws Exception;
}

라는 하나의 추상 메서드를 가지고 있다.

따라서

(int n) -> n + 9

는 그 apply()를 구현하는 동작으로 사용할 수 있다.

개념적으로

run((int n) -> n + 9)

를 다음처럼 생각할 수 있다.

F temp = (int n) -> n + 9;
run(temp);

16. 두 번째 run()의 결과

run()에서는 항상

f.apply(3);

을 호출한다.

이번 f의 동작은

(int n) -> n + 9

다.

따라서

n = 3

이 들어간다.

3 + 9 = 12

예외도 발생하지 않는다.

따라서

run((int n) -> n + 9)

의 결과는

12

다.

17. 최종 결과

원래 코드는

System.out.print(
    run(f) + run((int n) -> n + 9)
);

였다.

앞에서 각각 계산했다.

run(f)
→ 7

그리고

run((int n) -> n + 9)
→ 12

따라서

7 + 12
= 19

최종 출력은

19

다.

18. 람다 문제는 이렇게 풀면 편하다

처음에는 람다 문법을 그대로 따라가려고 해서 더 어려웠다.

오히려 람다를 만나면 원래 메서드 형태로 다시 펼쳐서 생각하는 것이 편했다.

예를 들어

F f = (x) -> x * 2;

가 있고

interface F {
    int apply(int x);
}

라면 머릿속에서

int apply(int x) {
    return x * 2;
}

로 바꿔본다.

그러면

f.apply(3);

도 바로 이해된다.

x = 3
↓
3 * 2
↓
6

즉 시험에서는

람다 발견
   ↓
대상 인터페이스 확인
   ↓
추상 메서드 확인
   ↓
람다를 그 메서드의 구현으로 생각
   ↓
실제 전달되는 값 대입
   ↓
결과 계산

순서로 따라가면 된다.

19. 문자열 + 연산도 같이 헷갈렸다

Java 문제를 풀면서 람다 외에도 출력 결과에서 자주 헷갈렸던 것이 문자열의 + 연산이었다.

예를 들어

int r1 = 9;
int r2 = 2;
char r3 = '3';

System.out.println(r1 + r2 + "2" + r3);

가 있다고 하자.

처음부터 전부 문자열로 합치는 것이 아니다.

Java의 + 연산은 왼쪽부터 진행된다.

먼저

r1 + r2

를 계산한다.

9 + 2 = 11

아직 둘 다 숫자이므로 숫자 덧셈이다.

그다음

11 + "2"

를 계산한다.

여기서 String을 만났다.

따라서 문자열 연결이 된다.

"112"

그리고

"112" + '3'

도 문자열 연결이 된다.

결과는

"1123"

이다.

20. 1 + 2 + "3"과 "1" + 2 + 3

이 차이는 시험에서 특히 주의해야 한다.

먼저

System.out.println(1 + 2 + "3");

를 보자.

왼쪽부터 계산한다.

1 + 2
↓
3

3 + "3"
↓
"33"

따라서

33

이 출력된다.

반면

System.out.println("1" + 2 + 3);

에서는 처음부터 String이 등장한다.

"1" + 2
↓
"12"

"12" + 3
↓
"123"

따라서

123

이 출력된다.

둘의 차이는 결국 String을 어느 시점에 만나는가다.

21. 이번에 이해한 Runnable과 람다의 연결

처음에는 Runnable과 람다가 서로 다른 문법처럼 느껴졌다.

하지만 둘 다 어떤 동작을 전달한다는 관점으로 보면 연결된다.

Runnable에는 실행할 동작을 나타내는

void run()

이 있다.

그래서 다음처럼 익명 클래스를 만들 수 있다.

Runnable task = new Runnable() {

    @Override
    public void run() {
        System.out.println("Hello");
    }
};

그리고 Runnable은 람다의 대상으로 사용할 수 있는 형태이므로 이 동작을 더 간단하게 표현할 수도 있다.

Runnable task = () -> System.out.println("Hello");

Thread에 전달하면

Thread t = new Thread(task);
t.start();

처럼 사용할 수 있다.

더 줄이면

Thread t = new Thread(
    () -> System.out.println("Hello")
);

t.start();

와 같은 형태도 이해할 수 있게 된다.

처음에는

() -> ...

가 갑자기 등장한 이상한 문법처럼 보였지만 결국

Runnable의 run()에서 실행할 내용을 전달한 것

이라고 생각할 수 있었다.

익명 클래스와 람다를 연결해서 보기

람다가 아직 익숙하지 않다면 다음 세 단계를 비교해보는 것이 가장 이해하기 쉬웠다.

직접 클래스 구현

class MyFunction implements F {

    @Override
    public int apply(int x) {
        return x * 2;
    }
}

F f = new MyFunction();

익명 클래스

F f = new F() {

    @Override
    public int apply(int x) {
        return x * 2;
    }
};

람다식

F f = (x) -> x * 2;

표현은 점점 짧아지지만 핵심적으로 표현하려는 동작은

x를 받아서 x * 2를 반환한다.

로 같다.

문제를 풀 때 내가 확인할 것

람다 문제가 나오면 다음 순서로 보는 것이 가장 편했다.

1. 람다가 어떤 인터페이스 타입으로 사용되고 있는가?

2. 그 인터페이스의 추상 메서드는 무엇인가?

3. 매개변수 타입과 반환 타입은 무엇인가?

4. 람다를 그 메서드의 구현이라고 생각한다.

5. 실제로 어떤 값이 전달되는지 확인한다.

6. 예외가 발생하는지 확인한다.

7. try-catch가 있다면 어디에서 처리되는지 확인한다.

예를 들어

run((int n) -> n + 9)

를 보면

run()의 매개변수
↓
F

F의 추상 메서드
↓
int apply(int x)

람다
↓
(int n) -> n + 9

run() 내부
↓
f.apply(3)

따라서
↓
n = 3

결과
↓
3 + 9 = 12

로 따라가면 된다.

마무리

처음에는

(int n) -> n + 9

라는 표현 자체가 이해되지 않았다.

메서드 이름도 없고 return도 없는데 어떻게 실행되는지 감이 오지 않았다.

하지만 함수형 인터페이스와 연결해서 보니 훨씬 단순했다.

interface F {
    int apply(int x) throws Exception;
}

처럼 구현해야 할 추상 메서드가 하나라면

(x) -> x * 2

라는 람다를

int apply(int x) {
    return x * 2;
}

라는 동작의 구현으로 연결해서 생각할 수 있었다.

그리고

run(f)

처럼 람다를 전달받는 메서드에서는 결국 그 동작을

f.apply(3);

처럼 실행하고 있는 것이다.

이번 내용을 한 흐름으로 정리하면 다음과 같다.

함수형 인터페이스
       ↓
하나의 추상 메서드
       ↓
그 메서드의 동작을 구현
       ↓
익명 클래스로 표현 가능
       ↓
람다식으로 더 간결하게 표현 가능
       ↓
다른 메서드의 인자로 전달 가능
       ↓
필요한 시점에 실행

결국 람다를 처음 볼 때부터 어려운 문법으로 생각할 필요는 없었다.

(int n) -> n + 9는 int 값을 하나 받아서 9를 더한 값을 반환하는 동작이다.

그리고 그 동작이 어떤 메서드에 해당하는지는 람다가 사용되는 함수형 인터페이스를 확인하면 알 수 있다.

이렇게 생각하니 Runnable, 익명 클래스, 람다식이 따로 떨어진 문법이 아니라 “실행할 동작을 객체처럼 전달한다”는 하나의 흐름으로 연결되기 시작했다.

Java 문제를 풀다가 다음과 같은 코드를 만났다.

Parent obj = new Child();

처음에는 이 코드부터 이상하게 느껴졌다.

Child 객체를 만들 거면 그냥 이렇게 하면 되는 것 아닌가?

Child obj = new Child();

그런데 굳이

Parent obj = new Child();

라고 작성한다.

그리고 더 헷갈리는 것은 다음 코드였다.

class Parent {
    void show() {
        System.out.println("Parent");
    }
}

class Child extends Parent {
    void show() {
        System.out.println("Child");
    }
}

Parent obj = new Child();
obj.show();

obj의 타입은 분명 Parent인데 출력은

Child

가 나온다.

처음에는

왼쪽이 Parent인데 왜 Parent.show()가 실행되지?

라는 생각이 들었다.

이 문제를 이해하려면 Java에서 참조변수의 타입과 실제 생성된 객체의 타입을 구분해야 했다.

그리고 여기서부터 오버라이딩, 오버로딩, 다형성, 동적 바인딩까지 전부 연결되기 시작했다.

1. Parent obj = new Child()에서 왼쪽과 오른쪽은 다르다

다음 코드를 다시 보자.

Parent obj = new Child();

이 코드는 두 부분으로 나눠서 봐야 한다.

Parent obj = new Child();
^^^^^^         ^^^^^
참조변수 타입    실제 객체 타입

왼쪽의 Parent는 참조변수의 타입이다.

오른쪽의 new Child()는 실제로 생성되는 객체의 타입이다.

즉 obj라는 변수는 Parent 타입으로 객체를 바라보고 있지만 실제로 만들어진 객체는 Child다.

Parent obj = new Child();

obj
 │
 │ Parent 타입으로 참조
 ↓
┌─────────────┐
│ Child 객체   │
└─────────────┘

상속 관계이기 때문에 이런 대입이 가능하다.

Parent
   ↑
 Child

Child는 Parent의 자식이므로 Child 객체를 Parent 타입으로 참조할 수 있다.

2. 그러면 왼쪽과 오른쪽은 각각 무엇을 결정할까?

여기서 가장 중요했던 부분이다.

Parent obj = new Child();

를 볼 때 두 가지 질문을 따로 해야 한다.

1. 이 메서드를 호출할 수 있는가?
2. 호출할 수 있다면 실제 어떤 메서드가 실행되는가?

첫 번째 질문은 참조변수의 타입을 본다.

두 번째 질문은 오버라이딩된 인스턴스 메서드라면 실제 객체의 타입을 본다.

즉 시험 문제에서는 다음처럼 생각하면 편했다.

Parent obj = new Child();
       │             │
       │             └─ 실제 어떤 오버라이딩 구현이 실행되는가?
       │
       └─ 어떤 메서드를 호출할 수 있는가?

3. 왜 Child.show()가 실행될까?

다시 처음 문제를 보자.

class Parent {

    void show() {
        System.out.println("Parent");
    }
}

class Child extends Parent {

    @Override
    void show() {
        System.out.println("Child");
    }
}

그리고

Parent obj = new Child();
obj.show();

를 실행한다.

먼저 왼쪽 타입을 확인한다.

obj의 타입 = Parent

Parent에는

void show()

가 있다.

따라서

obj.show();

를 호출하는 것 자체는 가능하다.

그다음 실제 객체를 본다.

실제 객체 = Child

그리고 Child가 show()를 오버라이딩했다.

따라서 실제 실행되는 것은

Child.show()

다.

결과는

Child

가 된다.

흐름을 정리하면 다음과 같다.

obj.show()
   ↓
Parent 타입에 show()가 있는가?
   ↓
있음
   ↓
호출 가능
   ↓
실제 객체는?
   ↓
Child
   ↓
Child가 show()를 오버라이딩했는가?
   ↓
YES
   ↓
Child.show() 실행

4. 그렇다면 Child에만 있는 메서드도 호출할 수 있을까?

여기서 바로 다음 의문이 생겼다.

실제 객체가 Child라면 Child에만 있는 메서드도 호출할 수 있지 않을까?

예를 들어 다음과 같다.

class Parent {

    void show() {
        System.out.println("Parent");
    }
}

class Child extends Parent {

    @Override
    void show() {
        System.out.println("Child");
    }

    void childOnly() {
        System.out.println("Child Only");
    }
}

그리고

Parent obj = new Child();

라고 했다.

다음 코드는 가능하다.

obj.show();

하지만 다음은 불가능하다.

obj.childOnly(); // 컴파일 오류

처음에는 실제 객체가 Child인데 왜 안 되는지 이상했다.

하지만 앞에서 세운 규칙을 적용하면 된다.

호출할 수 있는지를 먼저 참조변수 타입으로 확인한다.

현재 obj의 타입은

Parent

다.

그런데 Parent에는

childOnly()

가 없다.

따라서 컴파일 단계에서 호출할 수 없는 메서드라고 판단한다.

실제 객체가 Child라는 사실을 확인하기도 전에 호출 자체가 불가능한 것이다.

5. 호출 가능 여부와 실제 실행 메서드를 분리해서 생각하자

이 부분을 다음처럼 정리하니 훨씬 덜 헷갈렸다.

호출할 수 있는가?
        ↓
참조변수 타입 확인

어떤 오버라이딩 구현이 실행되는가?
        ↓
실제 객체 타입 확인

예를 들어

Parent obj = new Child();

에서

obj.show();

는 Parent에 show()가 있으므로 호출 가능하다.

그 후 실제 객체가 Child이므로 오버라이딩된 Child.show()가 실행된다.

반면

obj.childOnly();

는 Parent에 childOnly()가 없으므로 호출 자체가 불가능하다.

6. 그래도 Child의 메서드를 사용하고 싶다면?

실제 객체가 정말 Child라면 다운캐스팅을 통해 Child 타입으로 바라볼 수 있다.

Parent obj = new Child();

((Child) obj).childOnly();

또는

Child child = (Child) obj;
child.childOnly();

처럼 사용할 수 있다.

다만 아무 Parent 객체나 Child로 바꿀 수 있는 것은 아니다.

예를 들어

Parent obj = new Parent();

인데

Child child = (Child) obj;

처럼 강제로 캐스팅하면 실제 객체가 Child가 아니므로 런타임 오류가 발생할 수 있다.

결국 캐스팅에서도 실제 객체가 무엇인지가 중요하다.

7. @Override가 있어야 오버라이딩일까?

다음으로 헷갈렸던 부분이다.

처음에는

@Override

가 붙어 있어야 오버라이딩이 발생한다고 생각했다.

하지만 아니다.

다음 코드를 보자.

class Parent {

    public void show() {
        System.out.println("Parent");
    }
}

class Child extends Parent {

    public void show() {
        System.out.println("Child");
    }
}

@Override가 없다.

그래도 Child.show()는 Parent.show()를 오버라이딩한 것이다.

즉 @Override가 오버라이딩을 만드는 것은 아니다.

8. 그렇다면 @Override는 왜 사용할까?

@Override는 Annotation이다.

쉽게 생각하면 컴파일러에게 다음과 같이 알려주는 것이다.

이 메서드는 부모의 메서드를 오버라이딩하려고 만든 거야. 제대로 작성했는지 검사해 줘.

예를 들어

class Parent {

    void show() {
    }
}

가 있는데 자식에서 실수로

class Child extends Parent {

    @Override
    void show(int n) {
    }
}

라고 작성했다고 하자.

나는 show()를 오버라이딩하려고 했지만 실제로는

show()
show(int)

로 매개변수가 다르다.

따라서 오버라이딩이 아니다.

@Override를 붙였다면 컴파일러가 이를 확인하고 오류를 알려준다.

그래서 @Override는 오버라이딩을 발생시키는 문법이라기보다 실수를 방지해 주는 검사 장치에 가깝다.

9. 오버라이딩과 오버로딩은 무엇이 다를까?

이제 가장 자주 헷갈리는 두 개념이 나온다.

Overriding
Overloading

이름도 비슷해서 처음에는 계속 섞였다.

하지만 기준은 명확하다.

오버라이딩(Overriding)

부모에게 있던 메서드를 자식이 재정의하는 것이다.

class Parent {

    void show() {
        System.out.println("Parent");
    }
}

class Child extends Parent {

    void show() {
        System.out.println("Child");
    }
}

상속 관계에서 같은 형태의 메서드를 자식이 다시 구현했다.

Parent.show()
      ↓
Child.show()

실제 객체가 Child라면 Child의 구현이 실행될 수 있다.

오버로딩(Overloading)

같은 이름의 메서드를 매개변수를 다르게 해서 여러 개 정의하는 것이다.

void show() {
}

void show(int n) {
}

void show(String s) {
}

이름은 모두 show지만 서로 다른 메서드다.

show()
show(int)
show(String)

호출할 때 전달되는 인자에 따라 어떤 메서드를 사용할지 결정된다.

10. getA()와 getA(int)는 오버라이딩이 아니다

다음 문제도 처음에는 헷갈렸다.

class Parent {

    int getA() {
        return 10;
    }
}

class Child extends Parent {

    int getA(int n) {
        return 20;
    }
}

Child에도 getA가 있으니 오버라이딩처럼 보인다.

하지만

Parent → getA()
Child  → getA(int)

로 매개변수가 다르다.

따라서 Child.getA(int)는 Parent.getA()를 오버라이딩한 것이 아니다.

Child는 부모로부터 getA()를 물려받고, 별도로 getA(int)라는 오버로드된 메서드를 가지는 것으로 이해할 수 있다.

그래서

Parent obj = new Child();

System.out.println(obj.getA());

를 실행하면 Parent.getA()가 실행되어

10

이 나온다.

Child가 getA() 자체를 오버라이딩하지 않았기 때문이다.

11. 오버로딩은 컴파일 시점, 오버라이딩은 실행 시점

여기까지는 이해했는데 다음 문제를 만나면서 다시 헷갈렸다.

class A {

    String f(Object x) {
        return "1";
    }

    String g() {
        return f("a");
    }
}

class B extends A {

    String f(Object x) {
        return "2";
    }

    String f(String x) {
        return "3";
    }
}

그리고

A a = new B();

System.out.println(a.g());

를 실행한다.

처음에는 "3"이라고 생각하기 쉽다.

왜냐하면

f("a")

에서 "a"는 String이고 B에는 정확히

f(String x)

가 있기 때문이다.

하지만 결과는

2

다.

왜일까?

12. 먼저 오버로딩을 결정한다

g()는 클래스 A에 작성되어 있다.

String g() {
    return f("a");
}

이 코드를 컴파일할 때 A에서 사용할 수 있는 f()는

f(Object x)

다.

따라서

f("a")

의 호출 형태는 컴파일 단계에서

f(Object)

로 결정된다.

String은 Object의 자식이므로 "a"를 Object 매개변수로 전달하는 것도 가능하다.

즉 먼저

f(Object)

를 호출한다는 사실이 정해진다.

13. 그다음 오버라이딩을 확인한다

이제 프로그램이 실행된다.

A a = new B();

실제 객체는 B다.

앞에서 호출하기로 결정한 메서드는

f(Object)

였다.

그런데 B에는

String f(Object x) {
    return "2";
}

가 있다.

이는 A.f(Object)를 오버라이딩한 메서드다.

따라서 실제 실행은

B.f(Object)

가 된다.

결과는

2

다.

B에

f(String)

이 있다고 해서 실행 도중 갑자기 이것으로 바뀌지는 않는다.

14. 이 문제는 두 단계로 풀면 된다

이 문제를 한 번에 생각하면 상당히 헷갈린다.

그래서 다음처럼 두 단계로 나누는 것이 중요했다.

1단계: 오버로딩 결정
       ↓
컴파일 시점
       ↓
어떤 시그니처의 메서드를 호출할 것인가?

2단계: 오버라이딩 결정
       ↓
실행 시점
       ↓
그 시그니처의 실제 구현은 어느 객체의 것인가?

앞의 문제에서는

f("a")
↓
A에서 f(Object) 선택
↓
실제 객체 B 확인
↓
B가 f(Object)를 오버라이딩함
↓
B.f(Object)
↓
"2"

가 된다.

이 문제를 통해 오버로딩과 오버라이딩의 차이가 훨씬 명확해졌다.

오버로딩은 어떤 메서드 시그니처를 호출할지 컴파일 시점에 결정하고, 오버라이딩은 그 메서드의 어떤 구현을 실행할지 런타임에 결정한다.

15. 그런데 Object는 무엇일까?

위 코드에서 또 처음 보는 것이 있었다.

String f(Object x)

처음에는 Object x가 특별한 문법인 줄 알았다.

하지만 Object는 그냥 클래스다.

Java에서 Object는 모든 클래스의 최상위 부모 클래스다.

개념적으로 생각하면 다음과 같다.

             Object
          /     |      \
      String  Integer   Child

따라서 다음과 같은 코드가 가능하다.

Object obj = "Hello";

String이 Object를 기반으로 하는 클래스이기 때문이다.

그래서

void test(Object obj) {
}

라고 하면 여러 종류의 객체를 전달할 수 있다.

test("hello");
test(Integer.valueOf(10));
test(new Child());

결국

f(Object x)

도 특별한 문법이 아니다.

Object 타입의 객체를 매개변수로 받는 메서드

라는 뜻이다.

16. 부모 메서드 안에서 draw()를 호출하면 누구의 메서드일까?

다형성을 이해하면서 특히 헷갈렸던 부분이 하나 더 있다.

다음 코드를 보자.

class Parent {

    void draw() {
        System.out.print("B");
        print();
    }

    void print() {
        System.out.print("P");
    }
}

class Child extends Parent {

    @Override
    void print() {
        System.out.print("D");
    }

    void test() {
        super.draw();
    }
}

그리고

Child obj = new Child();
obj.test();

를 실행한다.

test()에서는

super.draw();

를 호출했으므로 Parent.draw()가 실행된다.

Parent.draw()
    ↓
"B" 출력

그런데 Parent의 draw() 안에는

print();

가 있다.

이 코드가 Parent 클래스 안에 작성되어 있으니 Parent.print()가 실행될 것 같았다.

하지만 print()는 일반적인 인스턴스 메서드 호출이다.

현재 실제 객체는 Child이고 Child가 print()를 오버라이딩했다.

따라서

Parent.draw()
    ↓
"B" 출력
    ↓
print()
    ↓
실제 객체 확인
    ↓
Child
    ↓
Child.print()
    ↓
"D" 출력

이 된다.

최종 출력은

BD

다.

즉 부모 클래스에 작성된 코드라고 해서 무조건 부모의 메서드가 실행되는 것은 아니다.

일반적인 오버라이딩 가능한 인스턴스 메서드 호출이라면 실제 객체를 기준으로 동적 바인딩이 적용될 수 있다.

17. 그렇다면 super.draw()는 왜 부모 메서드를 실행할까?

여기서 draw()와 super.draw()를 구분해야 한다.

draw();

또는

this.draw();

는 일반적인 인스턴스 메서드 호출이다.

오버라이딩되어 있다면 실제 객체에 따라 실행되는 구현이 결정될 수 있다.

반면

super.draw();

는 부모 클래스의 구현을 직접 지정한다.

즉

draw()
→ 일반적인 동적 메서드 호출

super.draw()
→ 부모의 draw() 구현을 직접 호출

이다.

하지만 재미있는 점은 super.draw()를 통해 Parent의 메서드 안으로 들어갔다고 해서 이후의 모든 호출까지 Parent에 고정되는 것은 아니라는 것이다.

super.draw();

로 Parent.draw()에 들어간 뒤 그 안에서 다시

print();

를 호출하면 이것은 새로운 일반 인스턴스 메서드 호출이다.

따라서 다시 동적 바인딩이 적용될 수 있다.

18. 부모의 private 필드는 자식이 사용할 수 없는데 부모 메서드는 어떻게 사용할까?

다음 코드도 처음에는 조금 이상했다.

class A {

    private int a;

    A(int a) {
        this.a = a;
    }

    void display() {
        System.out.println(a);
    }
}

class B extends A {

    B(int a) {
        super(a);
        super.display();
    }
}

a는

private int a;

이므로 B에서 직접 접근할 수 없다.

즉 다음은 안 된다.

class B extends A {

    void test() {
        System.out.println(a); // 오류
    }
}

그런데

super.display();

는 가능하다.

왜일까?

display()는 A 클래스 내부에 작성된 메서드이기 때문이다.

class A {

    private int a;

    void display() {
        System.out.println(a);
    }
}

A 자신의 메서드는 A 자신의 private 필드에 접근할 수 있다.

따라서 B는 a에 직접 접근하는 것이 아니라 A가 제공하는 메서드를 호출하고 있는 것이다.

B
│
├─ A.private 필드 직접 접근 → X
│
└─ A의 접근 가능한 메서드 호출 → O
                    │
                    ↓
             A.display()
                    │
                    ↓
          A 자신의 private a 접근 → O

private이 의미하는 접근 제한을 정확히 구분해야 한다.

19. super()와 super.method()도 구분해야 한다

super가 등장한다고 전부 같은 의미도 아니다.

super(10);

은 부모 생성자를 호출한다.

super.display();

는 부모 클래스의 일반 메서드 구현을 호출한다.

즉

super(...)
→ 부모 생성자 호출

super.method()
→ 부모 메서드 호출

이다.

특히

super(...)

는 자식 생성자의 첫 번째 문장이어야 한다.

자식 객체를 초기화하기 전에 부모로부터 물려받은 부분을 먼저 초기화해야 하기 때문이다.

Child 객체 생성
      ↓
Parent 부분 초기화
      ↓
Child 부분 초기화

그리고 명시적인 다른 생성자 호출이 없다면 Java는 가능한 경우 부모의 매개변수 없는 생성자를 호출한다.

그래서

B() {
    System.out.println("B");
}

는 동작을 이해할 때

B() {
    super();
    System.out.println("B");
}

처럼 생각할 수 있다.

부모에게 매개변수 없는 생성자가 없다면

super(10);

처럼 알맞은 부모 생성자를 직접 호출해야 한다.

문제를 풀 때 내가 사용하는 순서

상속 문제가 나오면 처음에는 Parent, Child, Override, super가 한꺼번에 보여서 상당히 복잡했다.

지금은 다음 순서로 보는 것이 가장 편하다.

Parent obj = new Child();
obj.method();

먼저

1. obj의 참조변수 타입은 무엇인가?

를 확인한다.

그 타입을 기준으로 해당 메서드를 호출할 수 있는지 확인한다.

그다음 오버로딩된 메서드가 여러 개라면

2. 어떤 시그니처가 선택되는가?

를 컴파일 시점 기준으로 판단한다.

그리고 선택된 메서드가 오버라이딩 가능한 인스턴스 메서드라면

3. 실제 객체는 무엇인가?

를 확인한다.

마지막으로

4. 실제 객체가 해당 메서드를 오버라이딩했는가?

를 확인한다.

정리하면

참조변수 타입
     ↓
호출 가능한 메서드 확인
     ↓
오버로딩 해결
     ↓
호출할 메서드 시그니처 결정
     ↓
실제 객체 확인
     ↓
오버라이딩 확인
     ↓
실제 구현 실행

순서다.

마무리

처음에는

Parent obj = new Child();

라는 한 줄에서부터 혼란이 시작됐다.

왼쪽은 Parent인데 Child 메서드가 실행되고, 그렇다고 Child에만 있는 메서드를 호출할 수 있는 것은 아니었다.

여기에 오버로딩까지 같이 나오면 더 헷갈렸다.

하지만 각각이 담당하는 역할을 나누니 생각보다 규칙이 명확했다.

참조변수 타입
→ 어떤 멤버를 사용할 수 있는지 판단하는 데 중요

실제 객체 타입
→ 오버라이딩된 인스턴스 메서드의 실제 구현을 결정

오버로딩
→ 같은 이름 + 다른 매개변수
→ 호출할 시그니처를 컴파일 시점에 결정

오버라이딩
→ 부모의 메서드를 자식이 재정의
→ 실제 객체에 따라 런타임에 구현 결정

@Override
→ 오버라이딩을 만드는 문법이 아님
→ 오버라이딩을 제대로 했는지 검사하는 Annotation

super.method()
→ 부모의 메서드 구현을 직접 호출

super(...)
→ 부모 생성자를 호출

특히 가장 중요했던 것은 오버로딩과 오버라이딩을 한 번에 판단하지 않는 것이었다.

먼저 컴파일 시점에 어떤 메서드 시그니처를 호출할지 결정하고, 그다음 런타임에 실제 객체를 보고 오버라이딩된 구현을 선택한다.

이 순서가 잡히고 나니 Parent obj = new Child()에서 시작했던 여러 문제가 하나의 원리로 연결되기 시작했다.

Java의 상속을 공부하다가 다음 코드를 보게 됐다.

class A {
    private int a;

    public A(int a) {
        this.a = a;
    }

    public void display() {
        System.out.println("a=" + a);
    }
}

class B extends A {
    public B(int a) {
        super(a);
        super.display();
    }
}

여기서 super(a)는 부모 클래스 A의 생성자를 호출한다.

그런데 Java에서는 한 가지 규칙이 있다.

생성자에서 super(...)를 직접 호출한다면 반드시 첫 번째 문장이어야 한다.

처음에는 단순히 Java 문법이 그런가 보다 생각할 수 있다.

하지만 왜 반드시 첫 번째여야 하는 걸까?

이 규칙은 상속 관계에서 객체가 만들어지는 과정을 이해하면 자연스럽게 이해할 수 있다.

1. super는 무엇일까?

먼저 super는 부모 클래스를 가리키기 위해 사용하는 키워드다.

예를 들어 다음과 같이 A를 상속받는 B가 있다고 하자.

class A {
}

class B extends A {
}

B 입장에서

super

는 부모 클래스인 A와 관련된 멤버에 접근할 때 사용할 수 있다.

대표적으로 두 가지 형태를 자주 볼 수 있다.

super(...)

와

super.method()

이다.

겉으로 보기에는 비슷하지만 역할은 다르다.

super(...)

는 부모 클래스의 생성자를 호출한다.

반면

super.display();

와 같은 표현은 부모 클래스의 메서드를 호출한다.

이 차이가 중요하다.

2. super(a)는 무엇을 하는 걸까?

다음 코드를 보자.

class A {

    private int a;

    public A(int a) {
        this.a = a;
    }
}

A에는 다음 생성자가 존재한다.

A(int a)

그리고 B에서

class B extends A {

    public B(int a) {
        super(a);
    }
}

라고 작성했다.

여기서

super(a);

는 부모 클래스의

A(int a)

생성자를 호출한다.

따라서

new B(10);

을 실행하면 B의 생성자만 실행되는 것이 아니다.

먼저 부모인 A의 생성자가 호출된다.

new B(10)
    ↓
B(int a)
    ↓
super(a)
    ↓
A(int a)

그리고 A의 생성이 끝나면 다시 B 생성자의 나머지 부분을 실행한다.

3. 그런데 왜 부모 생성자가 먼저 실행될까?

여기서 가장 궁금했던 부분이다.

왜 Java는 부모 생성자를 먼저 실행하도록 만들어 놓았을까?

B extends A라는 것은 B 객체가 A로부터 물려받은 상태와 동작을 포함한다는 뜻이다.

개념적으로 생각하면 B 객체 안에는 다음과 같은 부분이 있다고 볼 수 있다.

B 객체

┌──────────────────┐
│ A로부터 물려받은 부분 │
├──────────────────┤
│ B에서 추가한 부분     │
└──────────────────┘

따라서 B 객체를 제대로 만들기 위해서는 먼저 부모 클래스에서 물려받은 부분이 올바르게 초기화되어야 한다.

그 다음에야 B가 자신의 초기화를 진행할 수 있다.

즉 객체 생성 과정은

부모 부분 초기화
       ↓
자식 부분 초기화

순서로 진행된다.

이것이 부모 생성자가 자식 생성자보다 먼저 실행되는 이유다.

4. 실제로 실행 순서를 확인해보자

간단한 코드를 작성해보자.

class A {

    A() {
        System.out.println("A 생성");
    }
}

class B extends A {

    B() {
        super();
        System.out.println("B 생성");
    }
}

그리고

public class Main {

    public static void main(String[] args) {
        B obj = new B();
    }
}

를 실행한다.

나는

new B();

를 호출했으니 B부터 만들어질 것 같다고 생각할 수도 있다.

하지만 실제 출력은 다음과 같다.

A 생성
B 생성

호출 과정을 따라가면 다음과 같다.

new B()
   ↓
B()
   ↓
super()
   ↓
A()
   ↓
"A 생성"
   ↓
A() 종료
   ↓
B()로 돌아옴
   ↓
"B 생성"

즉 자식 객체를 만들더라도 부모 생성자가 먼저 실행된다.

5. 그래서 super()는 반드시 첫 번째 문장이어야 한다

이제 다음 코드를 보면 왜 문제가 되는지 이해할 수 있다.

class B extends A {

    B(int a) {
        System.out.println("B 시작");
        super(a);
    }
}

이 코드는 컴파일되지 않는다.

super(a);

보다

System.out.println("B 시작");

이 먼저 실행되도록 작성했기 때문이다.

Java에서는 부모 생성자 호출이 자식 생성자의 다른 코드보다 먼저 이루어져야 한다.

따라서 다음과 같이 작성해야 한다.

class B extends A {

    B(int a) {
        super(a);
        System.out.println("B 시작");
    }
}

즉,

부모 생성자
    ↓
자식 생성자의 나머지 코드

순서를 보장하기 위해 super(...)를 생성자의 첫 번째 문장으로 제한한다.

6. 그런데 super()를 안 쓰는 코드도 많다

여기서 또 하나 헷갈리는 부분이 생긴다.

실제로 Java 코드를 보면 생성자에 super()가 없는 경우가 많다.

예를 들어 다음 코드를 보자.

class A {

    A() {
        System.out.println("A");
    }
}

class B extends A {

    B() {
        System.out.println("B");
    }
}

B()에는 super()가 없다.

그렇다면 부모 생성자를 호출하지 않는 걸까?

아니다.

이 경우 Java 컴파일러가 생성자의 첫 번째 문장에 부모의 기본 생성자를 호출하는 코드를 넣는 것으로 이해할 수 있다.

즉 다음 코드는

B() {
    System.out.println("B");
}

사실상 다음과 같이 동작한다.

B() {
    super();
    System.out.println("B");
}

따라서

new B();

를 실행하면 여전히

A
B

순서로 출력된다.

7. super()를 생략했다고 부모 생성자를 호출하지 않는 게 아니다

이 부분은 처음 공부할 때 헷갈리기 쉽다.

class B extends A {

    B() {
        System.out.println("B");
    }
}

코드에 super()가 보이지 않으니까 부모 생성자를 호출하지 않는 것처럼 보인다.

하지만 실제로는 그렇지 않다.

작성한 코드

B() {
    System.out.println("B");
}

를 다음과 같이 이해하면 된다.

실제 동작을 이해하기 위한 형태

B() {
    super();
    System.out.println("B");
}

따라서 상속 관계에서 자식 생성자를 호출하면 부모 생성자부터 실행되는 원칙은 그대로 유지된다.

8. 그런데 부모에게 기본 생성자가 없다면?

여기서 중요한 문제가 하나 생긴다.

다음 코드를 보자.

class A {

    A(int x) {
        System.out.println(x);
    }
}

class B extends A {

    B() {
    }
}

A에는

A(int x)

만 존재한다.

즉 매개변수가 없는

A()

는 존재하지 않는다.

그런데 B()에서는 부모 생성자를 직접 호출하지 않았다.

그러면 컴파일러는 사실상 다음과 같이 처리하려고 한다.

B() {
    super();
}

문제는 부모 A에 A()가 없다는 것이다.

A()       → 없음 ❌
A(int x)  → 있음 ✅

따라서 호출할 부모 생성자를 찾을 수 없어 컴파일 오류가 발생한다.

9. 이럴 때는 super(값)를 직접 작성해야 한다

부모에게 매개변수가 있는 생성자만 존재한다면 자식이 적절한 값을 전달해야 한다.

class A {

    A(int x) {
        System.out.println(x);
    }
}

class B extends A {

    B() {
        super(10);
    }
}

이제

super(10);

이 부모의

A(int x)

를 호출한다.

따라서 정상적으로 컴파일할 수 있다.

실행 흐름은 다음과 같다.

new B()
   ↓
B()
   ↓
super(10)
   ↓
A(10)
   ↓
부모 부분 초기화
   ↓
B() 나머지 실행

10. 여기서 기본 생성자도 구분해야 한다

이 내용을 이해하면서 한 가지 더 주의해야 했다.

Java에서는 생성자를 하나도 작성하지 않았을 때 컴파일러가 기본 생성자를 제공한다.

예를 들어

class A {
}

라고 하면 사용할 수 있는

A()

가 제공된다.

하지만 내가 직접 생성자를 하나라도 작성하면 이야기가 달라진다.

class A {

    A(int x) {
    }
}

이 경우 컴파일러가 자동으로

A() {
}

를 추가해주는 것이 아니다.

따라서

new A();

는 사용할 수 없다.

마찬가지로 자식에서 암묵적으로

super();

를 호출하려고 해도 부모에게 A()가 없으므로 문제가 된다.

그래서 다음처럼 직접 맞는 생성자를 호출해야 한다.

super(10);

11. super()와 super.display()는 다르다

처음 코드로 다시 돌아가보자.

class B extends A {

    public B(int a) {
        super(a);
        super.display();
    }
}

여기에는 super가 두 번 등장한다.

super(a);

와

super.display();

다.

둘의 역할은 완전히 다르다.

super(a)

super(a);

는 부모 생성자를 호출한다.

따라서 생성자 안에서 사용한다면 첫 번째 문장이어야 한다.

super.display()

super.display();

는 부모 클래스에 정의된 일반 메서드를 호출한다.

생성자 호출이 아니다.

따라서 반드시 첫 번째 문장일 필요가 없다.

예를 들어 다음과 같이 사용할 수 있다.

B(int a) {
    super(a);

    System.out.println("B 생성 중");
    super.display();
}

이 코드는 가능하다.

즉 “super는 무조건 첫 번째 문장이어야 한다”라고 외우면 안 된다.

정확하게는

부모 생성자를 호출하는 super(...)가 생성자의 첫 번째 문장이어야 한다.

라고 기억해야 한다.

12. this()도 생성자 호출이다

여기서 super()와 함께 알아두면 좋은 것이 this()다.

this(...)

는 같은 클래스의 다른 생성자를 호출한다.

예를 들어

class Student {

    Student() {
        this("이름 없음");
    }

    Student(String name) {
        System.out.println(name);
    }
}

여기서

this("이름 없음");

은 같은 Student 클래스의

Student(String name)

생성자를 호출한다.

this(...) 역시 생성자 호출이기 때문에 첫 번째 문장이어야 한다.

따라서 다음 코드는 안 된다.

Student() {
    System.out.println("생성");
    this("홍길동");   // 컴파일 오류
}

반드시 다음처럼 작성해야 한다.

Student() {
    this("홍길동");
    System.out.println("생성");
}

13. super()와 this()를 동시에 사용할 수 있을까?

생성자에서

super(...)

와

this(...)

는 모두 첫 번째 문장이어야 한다.

그렇다면 다음처럼 작성할 수 있을까?

Student() {
    super();
    this("홍길동");
}

불가능하다.

둘 다 첫 번째 문장이어야 하는데 첫 번째 문장은 하나밖에 없기 때문이다.

따라서 한 생성자에서는 생성자 호출문으로 this(...) 또는 super(...) 중 하나만 직접 사용할 수 있다.

다만 this(...)를 통해 호출된 다른 생성자가 최종적으로 super(...)를 호출할 수 있다.

개념적으로는

자식 생성자 A
     ↓
this(...)
     ↓
자식 생성자 B
     ↓
super(...)
     ↓
부모 생성자

와 같은 연결이 가능하다.

결국 생성자 호출을 따라가다 보면 부모 생성자의 초기화가 이루어진다.

14. 상속이 여러 단계라면 어떻게 될까?

부모가 하나가 아니라 상속 관계가 여러 단계라면 어떻게 될까?

class A {

    A() {
        System.out.println("A");
    }
}

class B extends A {

    B() {
        System.out.println("B");
    }
}

class C extends B {

    C() {
        System.out.println("C");
    }
}

그리고

new C();

를 실행한다고 해보자.

C()에는 super()가 생략되어 있다.

따라서 B()를 호출한다.

C()
↓
B()

그런데 B()에도 super()가 생략되어 있다.

따라서 다시 A()를 호출한다.

C()
↓
B()
↓
A()

실제 생성은 가장 위의 부모부터 완료된다.

A
B
C

가 출력된다.

즉 상속 계층이

A
↑
B
↑
C

라면 new C()를 했을 때 생성자 실행은

A → B → C

순서가 된다.

15. 처음 코드를 다시 보면

이제 처음 코드를 다시 살펴보자.

class A {

    private int a;

    public A(int a) {
        this.a = a;
    }

    public void display() {
        System.out.println("a=" + a);
    }
}

class B extends A {

    public B(int a) {
        super(a);
        super.display();
    }
}

그리고

B obj = new B(10);

을 실행한다.

호출 흐름을 따라가보면 다음과 같다.

new B(10)
     ↓
B(int a)
     ↓
super(10)
     ↓
A(int a)
     ↓
this.a = 10
     ↓
A 생성자 종료
     ↓
B 생성자로 돌아옴
     ↓
super.display()
     ↓
a=10 출력

따라서 결과는

a=10

이다.

display()를 호출하기 전에 이미

super(a);

를 통해 부모의 a가 초기화되었기 때문에 10이 출력되는 것이다.

내가 헷갈렸던 부분

처음에는

super(a);

가 단순히 부모 클래스에 접근하는 문법이라고 생각했다.

그래서

왜 굳이 첫 번째 줄이어야 하지?

라는 의문이 생겼다.

하지만 super(a)는 단순한 부모 멤버 접근이 아니라 부모 객체 부분을 초기화하기 위한 부모 생성자 호출이었다.

자식 객체는 부모에게서 물려받은 부분을 포함하고 있기 때문에 자식 자신의 생성 과정을 진행하기 전에 부모 부분부터 초기화해야 한다.

그래서

부모 생성자
↓
자식 생성자

라는 순서가 만들어진다.

또 하나 헷갈리기 쉬운 부분은 super()가 코드에 보이지 않는 경우였다.

B() {
    System.out.println("B");
}

라고 작성했다고 해서 부모 생성자가 실행되지 않는 것이 아니다.

명시적인 다른 생성자 호출이 없다면 부모의 매개변수 없는 생성자를 호출하는 super()가 암묵적으로 들어간다고 이해하면 된다.

그리고 부모에게 매개변수 없는 생성자가 없다면

super(10);

처럼 적절한 부모 생성자를 직접 호출해야 한다.

시험에서 기억할 내용

super(...)
→ 부모 생성자를 호출한다.

super(...)는
→ 자식 생성자의 첫 번째 문장이어야 한다.

명시적인 생성자 호출을 생략하면
→ 부모의 매개변수 없는 생성자를 호출하는 super()가 암묵적으로 사용된다.

하지만

부모에게 매개변수 없는 생성자가 없다면
→ 알맞은 super(값)를 직접 작성해야 한다.

그리고 반드시 구분해야 한다.

super(...)
→ 부모 생성자 호출
→ 첫 번째 문장이어야 함

super.method()
→ 부모 메서드 호출
→ 첫 번째 문장일 필요 없음

this(...)도 같은 클래스의 다른 생성자를 호출하는 문장이므로 첫 번째 문장이어야 한다.

따라서 하나의 생성자에서

super(...)
this(...)

를 둘 다 직접 호출할 수는 없다.

마무리

처음에는 super()가 첫 번째 문장이어야 한다는 것을 단순한 Java 문법 규칙으로 외우려고 했다.

하지만 객체가 생성되는 과정을 생각해보면 이유가 있었다.

자식 클래스 B가 부모 클래스 A를 상속받고 있다면 B 객체를 만드는 과정에는 A에서 물려받은 부분을 초기화하는 과정도 필요하다.

그래서 Java에서는

new B()
   ↓
부모 생성자 실행
   ↓
부모 부분 초기화
   ↓
자식 생성자의 나머지 부분 실행
   ↓
B 객체 생성 완료

순서로 객체를 초기화한다.

결국 super(...)가 첫 번째 문장이어야 한다는 규칙은 따로 떨어진 문법이 아니었다.

자식 객체를 완성하기 전에 부모로부터 물려받은 부분부터 올바르게 초기화하기 위한 규칙이다.

이렇게 이해하고 나니 super(), 부모 생성자, 기본 생성자가 왜 서로 연결되어 나오는지도 이해할 수 있었다.

객체지향 프로그래밍을 배우면서 class를 만들 때 자연스럽게 필드를 작성해왔다.

class Student {
    String id;
    String name;
    String address;
    int year;
}

코드를 작성할 때는 별생각 없이 학생에게 필요한 데이터니까 넣는다 정도로 생각했다.

그런데 도메인 모델링에서는 한 단계 더 생각해야 한다.

어떤 정보를 클래스의 속성으로 만들어야 할까?

학생의 이름은 속성이라는 게 자연스럽다.

그런데 학생의 학과도 그냥 department라는 속성으로 넣으면 될까?

Student
----------------
id
name
department

Department라는 클래스가 따로 존재한다면 이야기가 달라진다.

Student ───── Department

이 경우 department는 단순한 값이라기보다 Student와 Department라는 두 객체 사이의 관계를 나타내는 정보일 수도 있다.

이번 장에서는 이런 질문을 중심으로 클래스의 속성(Attribute)을 정리한다.

1. 속성이란?

속성(Attribute)은 객체가 가지고 있는 정보를 나타내는 데이터다.

예를 들어 학생이라는 객체가 있다고 생각해보자.

학생마다 다음과 같은 정보를 가지고 있을 수 있다.

학번
이름
주소
학과
학년

이를 Student 클래스의 속성으로 표현할 수 있다.

Student
----------------
id
name
address
department
year

여기서 중요한 것은 클래스와 객체를 구분하는 것이다.

Student는 학생이라는 개념을 정의한 클래스이고,

학생1
학생2
학생3

은 실제 객체다.

예를 들어 세 학생이 있다고 하자.

학생1
학번 = 20260001
이름 = 홍길동
학년 = 2

학생2
학번 = 20260002
이름 = 김철수
학년 = 3

학생3
학번 = 20260003
이름 = 이영희
학년 = 1

세 객체는 모두 같은 Student 클래스에서 만들어졌지만 각 객체가 가지고 있는 속성의 값(Value)은 다르다.

즉,

클래스
→ 어떤 속성을 가지는지 정의

객체
→ 그 속성의 실제 값을 가짐

이라고 생각할 수 있다.

2. UML 클래스 다이어그램에서 속성 표현하기

UML 클래스 다이어그램에서는 클래스를 일반적으로 사각형으로 표현한다.

┌─────────────────────┐
│       Student       │
├─────────────────────┤
│ - id : String       │
│ - name : String     │
│ - address : String  │
│ - year : Integer    │
└─────────────────────┘

위쪽에는 클래스 이름이 들어가고 그 아래에는 속성이 들어간다.

속성을 조금 더 자세하게 표현하면 다음과 같은 요소들을 사용할 수 있다.

가시성 이름 : 타입 [다중성] = 초기값

예를 들어

- name : String

이라면

-        → 가시성
name     → 속성 이름
String   → 타입

을 의미한다.

따라서 UML의 속성을 읽을 때는 단순히 이름만 보는 것이 아니라 다음 정보를 함께 볼 수 있다.

1. 가시성
2. 이름
3. 다중성
4. 타입
5. 초기값

3. 가시성(Visibility)

가시성은

해당 속성에 누가 접근할 수 있는가?

를 나타낸다.

Java에서 우리가 사용하는

public
private
protected

와 연결해서 생각하면 쉽다.

UML에서는 기호로 표현한다.

예를 들어

- name : String

이라면 name은 private 속성이다.

Java로 생각하면

private String name;

과 비슷하다.

반대로

+ name : String

이라면

public String name;

에 대응한다.

따라서 UML을 볼 때

+
-
#
~

는 연산자가 아니라 접근 범위를 표현하는 기호라고 보면 된다.

4. 속성의 이름

속성에는 당연히 이름이 필요하다.

예를 들어 학생 클래스에 다음 속성이 있다고 하자.

id
name
address
department
year

속성 이름은 그 정보가 무엇을 의미하는지 알 수 있도록 작성해야 한다.

예를 들어

n
a
d

같은 이름보다

name
address
department

가 의미를 훨씬 명확하게 전달한다.

도메인 모델링에서 이름은 단순한 변수명이 아니라 도메인의 의미를 표현하는 역할도 한다.

5. 다중성(Multiplicity)

속성이 항상 값 하나만 가지는 것은 아니다.

예를 들어 학생에게 주소가 하나만 있다고 가정하면

address : String

으로 표현할 수 있다.

하지만 여러 개의 주소를 저장할 수 있다면 이야기가 달라진다.

이때 다중성(Multiplicity)을 사용한다.

예를 들어

address : String[2]

와 같이 표현하면 여러 값을 가질 수 있다는 것을 나타낼 수 있다.

다중성은 앞으로 클래스 사이의 연관관계에서도 굉장히 중요하게 등장한다.

대표적으로

1
0..1
*
1..*

같은 표현을 볼 수 있다.

의미는 대략 다음과 같다.

1     → 정확히 하나
0..1  → 없거나 하나
*     → 여러 개
1..*  → 최소 하나 이상

특히 1..*는 이후 클래스 연관관계 문제에서 중요하다.

6. 타입(Type)

속성에는 어떤 종류의 값을 저장할 것인지 타입을 지정할 수 있다.

예를 들어

Student
-------------------------
id : String
name : String
address : String
year : Integer

라고 한다면

id      → 문자열
name    → 문자열
address → 문자열
year    → 정수

라는 뜻이다.

Java 코드로 생각하면

class Student {

    private String id;
    private String name;
    private String address;
    private int year;
}

와 비슷하다.

7. 기본 타입과 사용자 정의 타입

속성의 타입이 반드시 String, Integer 같은 기본적인 타입일 필요는 없다.

예를 들어 다음과 같은 속성이 있다고 하자.

department : Department

여기서 Department는 우리가 직접 만든 클래스일 수 있다.

Java에서도 똑같다.

class Student {

    private String id;
    private String name;
    private Department department;
}

즉 클래스도 다른 클래스의 타입으로 사용할 수 있다.

그런데 여기서 중요한 문제가 생긴다.

department : Department

를 정말 Student의 속성으로 표현해야 할까?

아니면

Student ───── Department

처럼 두 클래스의 관계로 표현해야 할까?

이 문제가 이번 장의 중요한 내용 중 하나다.

8. 초기값(Initial Value)

속성에는 초기값을 지정할 수도 있다.

예를 들어 학생의 기본 학년을 1학년으로 설정한다고 하자.

UML에서는 개념적으로 다음처럼 표현할 수 있다.

year : Integer = 1

Java에서는

private int year = 1;

처럼 표현할 수 있다.

즉 객체가 처음 만들어졌을 때 별도의 값이 주어지지 않는다면 기본적으로 1을 가지도록 하는 것이다.

9. UML과 Java를 연결해서 보기

UML에서 다음과 같은 클래스가 있다고 하자.

┌──────────────────────────┐
│         Student          │
├──────────────────────────┤
│ - id : String            │
│ - name : String          │
│ - address : String       │
│ - department : Department│
│ - year : Integer = 1     │
└──────────────────────────┘

Java에서는 대략 다음처럼 표현할 수 있다.

class Student {

    private String id;
    private String name;
    private String address;
    private Department department;
    private int year = 1;
}

결국 UML은 코드와 완전히 동떨어진 그림이 아니다.

코드를 작성하기 전에

시스템에 어떤 클래스가 있고 각 클래스가 어떤 정보를 가지고 있는가

를 추상적으로 표현하는 방법이라고 생각하면 이해하기 쉽다.

10. 속성은 어떻게 찾을까?

여기부터가 도메인 모델링에서 더 중요한 부분이다.

문제 기술서가 있다고 해서 등장하는 모든 명사를 무작정 속성으로 넣으면 안 된다.

먼저 객체가 어떤 정보를 알아야 하는지 생각해야 한다.

예를 들어 자동차 시스템을 만든다고 하자.

자동차에 대해 생각할 수 있는 정보는 굉장히 많다.

제조사
모델명
색상
가격
차량 번호
구매자
판매자
정비 기록
유통 정보
보험 정보
...

현실 세계의 자동차에는 사실상 수많은 정보가 연결되어 있다.

그런데 우리가 만드는 시스템에 이 모든 정보가 필요한 것은 아니다.

11. 객체의 유용한 정보

어떤 정보가 속성이 되어야 하는지는 시스템의 목적에 따라 달라진다.

예를 들어 자동차 판매 시스템이라면

모델
가격
색상
제조사

같은 정보가 중요할 수 있다.

하지만 자동차 정비 시스템이라면

차량 번호
주행 거리
정비 기록
마지막 정비 날짜

가 더 중요할 수 있다.

즉 같은 자동차 객체라도

판매 시스템의 Car

와

정비 시스템의 Car

가 가져야 하는 속성이 다를 수 있다.

이 부분에서 중요한 생각은 다음과 같다.

현실 세계 객체의 모든 정보를 모델에 넣는 것이 아니라, 현재 시스템에 필요한 정보만 선택한다.

도메인 모델은 현실 세계를 그대로 복사하는 것이 아니라 문제를 해결하는 데 필요한 부분을 추상화한 것이라고 볼 수 있다.

12. 속성과 객체를 구분하기

여기서 한 가지 헷갈리는 문제가 생긴다.

어떤 정보는 단순한 값(Value)이고, 어떤 정보는 독립적인 객체(Object)다.

예를 들어 Course 클래스가 있다고 하자.

Course
----------------
id
name
credit
department

처음에는 department도 그냥 Course의 속성처럼 보인다.

department : String

으로 만들 수도 있다.

하지만 시스템에 Department 클래스가 별도로 존재한다면?

Department
----------------
name
studentNumber
professorNumber
office

이 경우 department는 단순한 문자열보다 Department라는 독립적인 객체로 보는 것이 더 자연스러울 수 있다.

즉

Course
----------------
id
name
credit
department

에서 department를 단순 속성으로 유지하는 대신

Course ───────── Department

라는 관계로 표현할 수 있다.

13. 왜 속성을 연관관계로 바꿀까?

예를 들어 Course에

department : String

이 있다고 하자.

값은

"소프트웨어공학과"

정도일 것이다.

그런데 Department 자체가 다음 정보를 가지고 있다면?

Department
----------------
name
studentNumber
professorNumber
office

단순한 문자열 하나로 표현하기에는 Department가 가진 의미가 너무 많다.

따라서

Course.department

라는 속성 대신

Course ───── Department

라는 객체 간 관계로 표현하는 것이다.

14. 클래스 사이의 연관관계 ⭐ 시험 중요

이번 장에서 특히 중요하게 봐야 할 부분이다.

자료에서도 직접

시험!! 이 클래스들을 주고 연관관계를 맺어봐라

라고 표시되어 있다.

즉 여러 클래스와 속성을 주고

어떤 속성을 클래스 사이의 연관관계로 바꿀 것인가?

를 판단하는 문제가 나올 가능성이 높다.

15. 시험 예제의 클래스

자료에는 다음 네 클래스가 등장한다.

Course
Lecture
Professor
Department

처음에는 각 클래스 안에 다른 객체를 나타내는 정보가 속성으로 포함되어 있다.

예를 들어 개념적으로 보면

Course
----------------
id
name
credit
department

Lecture
----------------
course_id
professor_id
semester
classroom
min
max

Professor
----------------
id
name
department
major

Department
----------------
name
studentNumber
professorNumber
office

이다.

여기서 찾아야 하는 것이 있다.

Course.department
Lecture.course_id
Lecture.professor_id
Professor.department

이 정보들이다.

왜 이 속성들이 눈에 띌까?

이미 각각을 표현하는 클래스가 존재하기 때문이다.

department
→ Department 클래스가 존재

course_id
→ Course 클래스가 존재

professor_id
→ Professor 클래스가 존재

따라서 단순한 속성으로 표현하는 대신 클래스 사이의 연관관계(Association)로 나타낼 수 있다.

자료에서도 이 부분을 시험 문제로 직접 표시하고 있다. Chpater_03_속성.pdf

16. Course와 Department의 관계

먼저

Course.department

를 보자.

Department라는 클래스가 이미 존재한다.

따라서

Course
  │
  │
Department

라는 관계로 바꿀 수 있다.

Course 안에서는 기존의

department

속성을 제거할 수 있다.

왜냐하면 두 클래스 사이의 선 자체가

이 Course가 Department와 관계를 가지고 있다

는 정보를 표현하기 때문이다.

17. Course와 Lecture의 관계

Lecture에는

course_id

가 있다.

이것은 결국

이 강의가 어떤 Course에 해당하는가?

를 나타내는 정보다.

따라서

Course ───── Lecture

라는 관계로 표현할 수 있다.

그리고 한 Course에 여러 Lecture가 존재할 수 있다면 다중성을 이용해 표현한다.

예를 들어

Course 1 ───────── 1..* Lecture

처럼 생각할 수 있다.

1..*는

최소 1개 이상

이라는 뜻이다.

18. Lecture와 Professor의 관계

Lecture에는

professor_id

가 존재한다.

그런데 Professor 클래스가 이미 있다.

따라서 단순히 교수의 ID를 값으로 가지고 있는 대신

Lecture ───── Professor

라는 관계로 표현할 수 있다.

즉

professor_id

라는 속성이

Professor 객체와의 연관관계

로 바뀌는 것이다.

19. Professor와 Department의 관계

Professor에도

department

정보가 있다.

그리고 Department 클래스가 존재한다.

따라서

Professor ───── Department

라는 연관관계로 표현할 수 있다.

20. 시험 문제를 풀 때 보는 순서 ⭐⭐⭐

클래스 여러 개를 던져주고

연관관계를 맺어라.

라고 하면 처음부터 선을 그으려고 하지 않는 게 좋다.

다음 순서로 보면 된다.

STEP 1. 어떤 클래스들이 존재하는지 확인한다.

예를 들어

Course
Lecture
Professor
Department

가 있다.

STEP 2. 각 클래스의 속성을 확인한다.

Course.department

Lecture.course_id
Lecture.professor_id

Professor.department

처럼 다른 객체를 가리키는 것 같은 속성을 찾는다.

STEP 3. 그 속성에 대응하는 클래스가 존재하는지 확인한다.

department
→ Department 있음

course_id
→ Course 있음

professor_id
→ Professor 있음

그렇다면 단순한 값이 아니라 객체 사이의 관계일 가능성이 있다.

STEP 4. 해당 속성을 연관관계로 바꾼다.

Course ───── Department

Course ───── Lecture

Lecture ───── Professor

Professor ───── Department

STEP 5. 다중성을 판단한다.

이제

1
0..1
*
1..*

등을 붙인다.

여기서 중요한 것은 무조건 외우는 것이 아니라 도메인의 의미를 생각하는 것이다.

예를 들어

하나의 Course에는 몇 개의 Lecture가 존재할 수 있는가?

를 생각해서 다중성을 결정한다.

21. 속성과 연관관계를 구분하는 기준

처음에는 이 부분이 가장 헷갈렸다.

간단하게 생각하면 다음 질문을 던져볼 수 있다.

이 정보가 그냥 값인가, 아니면 시스템에서 별도의 객체로 다뤄야 하는 대상인가?

예를 들어

Student.name

에서 name은 일반적으로 그냥 값이다.

name : String

으로 충분하다.

하지만

Student.department

에서 Department를 시스템이 별도의 객체로 관리하고 있다면

Student ───── Department

라는 관계로 보는 것이 자연스럽다.

즉,

name
age
year
price

처럼 자체적으로 객체의 의미를 가질 필요가 없는 값은 속성으로,

Department
Professor
Course
Student

처럼 시스템에서 독립적인 개념과 정보를 가지는 대상은 클래스로 만들고 다른 클래스와 관계를 맺을 수 있다.

22. 속성 간의 관련성

하나의 클래스 안에서도 속성들이 서로 관련되어 있을 수 있다.

예를 들어 강의 클래스에 다음 속성이 있다고 하자.

강좌번호
강좌이름
학점
담당학과
개설학기
강의실
최소수강학생수
최대수강학생수

이 속성들은 모두 강의와 관련된 정보지만 조금 더 자세히 보면 성격이 다르다.

예를 들어

강좌번호
강좌이름
학점
담당학과

는 강좌 자체의 기본 정보와 관련되어 있고,

개설학기
강의실
최소수강학생수
최대수강학생수

는 실제 강의가 개설되는 상황과 더 관련되어 있을 수 있다.

이처럼 한 클래스가 너무 많은 종류의 정보를 가지고 있다면

정말 하나의 클래스가 모두 책임지는 것이 맞는가?

를 생각해볼 필요가 있다.

경우에 따라서는 하나의 클래스를 여러 클래스로 분리하는 것이 더 자연스러울 수 있다.

23. 클래스 범위 속성(Class Scope Attribute)

지금까지 본 속성은 대부분 객체마다 각각 존재하는 속성이었다.

예를 들어

Student
----------------
id
name
year

가 있다고 하자.

학생 객체를 세 개 만들면

학생1.year = 1
학생2.year = 3
학생3.year = 2

처럼 각각 자기 값을 가진다.

이를 인스턴스 범위 속성(Instance Scope Attribute)이라고 한다.

24. 인스턴스 범위 속성

예를 들어

Course
----------------
id
name
credit

이 있다고 하자.

Course 객체가 세 개 존재하면

Course1.credit
Course2.credit
Course3.credit

각 객체마다 별도의 credit 값이 존재한다.

즉 메모리에서도 각 객체가 자신의 속성을 따로 가진다.

Course 객체 1
[ id ][ name ][ credit ]

Course 객체 2
[ id ][ name ][ credit ]

Course 객체 3
[ id ][ name ][ credit ]

이것이 일반적인 객체 속성이다.

25. 클래스 범위 속성

그런데 모든 객체가 하나의 값을 공유해야 하는 정보도 있다.

예를 들어 전체 Course 객체의 개수를 저장한다고 하자.

total

Course 객체마다 total을 하나씩 가지고 있을 필요가 없다.

Course1.total
Course2.total
Course3.total

처럼 따로 가지고 있으면 오히려 관리하기 어렵다.

대신 클래스 자체가 하나만 가지고 모든 객체가 공유하면 된다.

           Course
              │
         total = 3
        ↙     ↓     ↘
 Course1   Course2   Course3

이것이 클래스 범위 속성(Class Scope Attribute)이다.

Java에서는 우리가 익숙하게 사용하는

static

과 연결된다.

26. Java의 static과 연결하기

예를 들어

class Course {

    private String id;
    private String name;
    private int credit;

    public static int total;
}

이라고 하자.

여기서

id
name
credit

은 객체마다 존재한다.

반면

static int total;

은 Course 클래스에 하나만 존재하고 모든 Course 객체가 공유한다.

즉

일반 필드
→ 객체마다 하나씩

static 필드
→ 클래스 전체에서 하나

라고 생각하면 된다.

27. UML에서 클래스 범위 속성

UML에서는 클래스 범위 속성을 일반 속성과 다르게 표시한다.

교재의 예처럼 클래스 전체에서 공유되는 속성은 밑줄을 그어서 표현한다.

즉 밑줄이 있는 속성을 발견하면

이 값은 객체마다 따로 존재하는 것이 아니라 클래스 전체에서 공유하는 값이다.

라고 읽으면 된다.

Java의

static

을 떠올리면 이해하기 쉽다.

28. 유도 속성(Derived Attribute)

유도 속성은 조금 독특하다.

다른 속성의 값을 이용해서 계산할 수 있는 속성이다.

예를 들어 사람이 다음 정보를 가지고 있다고 하자.

Person
----------------
name
birthYear
age

현재 연도와 birthYear를 알고 있다면 age는 계산할 수 있다.

개념적으로

age = 현재 연도 - birthYear

와 같은 관계가 있기 때문이다.

그렇다면 굳이 age를 별도로 저장해야 할까?

저장하지 않고 필요할 때 계산할 수도 있다.

이처럼 다른 속성으로부터 계산할 수 있는 속성을 유도 속성이라고 한다.

29. UML의 유도 속성 표현

UML에서는 유도 속성 앞에 /를 붙인다.

예를 들어

Person
----------------
name
birthYear
/age

라고 되어 있다면

/age

는 다른 정보를 통해 계산할 수 있는 속성이라는 뜻이다.

따라서 UML에서

/

가 속성 앞에 있다면 나눗셈 기호가 아니라

Derived Attribute

를 의미한다.

30. 왜 유도 속성을 사용할까?

예를 들어 다음 두 값을 모두 저장한다고 하자.

birthYear = 2000
age = 26

시간이 지나 2027년이 되었다.

그러면

birthYear = 2000
age = 26

에서 age가 잘못된 정보가 된다.

따라서 age를 직접 저장하는 대신

age = currentYear - birthYear

처럼 필요할 때 계산하면 데이터 불일치 문제를 줄일 수 있다.

31. 하지만 유도 속성을 항상 계산해야 하는 것은 아니다

유도할 수 있는 값이라고 해서 반드시 저장하면 안 된다는 뜻은 아니다.

계산 비용이 매우 크거나 값이 자주 필요하다면 미리 계산해서 저장하는 것이 더 효율적인 경우도 있다.

즉 유도 속성의 핵심은

다른 속성으로부터 계산할 수 있는 정보인가?

를 나타내는 데 있다.

32. 속성을 검토할 때 생각해야 할 것

클래스의 속성을 처음 찾았다고 해서 바로 확정하면 안 된다.

마지막으로 속성이 적절한지 검토해야 한다.

자료의 마지막에서는 특히 다음과 같은 관점으로 속성을 확인한다.

1. 필요한 정보가 빠지지 않았는가?

클래스가 역할을 수행하기 위해 필요한 정보가 모두 들어있는지 확인한다.

예를 들어 Student를 관리해야 하는데 학생을 구별할 방법이 없다면 문제가 된다.

Student
----------------
name
year

동명이인이 존재하면 객체를 정확히 구별하기 어렵다.

따라서 시스템 요구사항에 따라

studentId

같은 식별 정보가 필요할 수 있다.

2. 속성 이름이 명확한가?

data
value
info

같은 이름은 무엇을 의미하는지 불명확하다.

가능하면

studentId
courseName
credit

처럼 의미를 알 수 있는 이름을 사용하는 것이 좋다.

3. 한 클래스의 속성들이 서로 관련되어 있는가?

한 클래스 안에 서로 전혀 관계없는 정보가 지나치게 많이 들어있다면 클래스의 역할이 잘못 나누어진 것일 수 있다.

예를 들어

Course
----------------
courseName
credit
professorName
professorPhone
departmentOffice
studentAddress

처럼 여러 객체의 정보가 뒤섞여 있다면

Course
Professor
Department
Student

등으로 객체를 분리하고 관계를 맺는 것이 더 자연스러울 수 있다.

33. 이번 장을 공부하면서 이해한 핵심

처음에는 속성을 단순히 Java의 필드 정도로 생각했다.

class Student {
    String name;
    int year;
}

그래서 클래스에 필요한 정보를 그냥 변수로 넣으면 된다고 생각했다.

하지만 도메인 모델링에서 중요한 것은 변수를 어떻게 선언하는가보다 어떤 정보를 그 클래스의 책임으로 볼 것인가를 결정하는 것이었다.

특히

Course.department
Lecture.professor_id

처럼 다른 객체를 가리키는 정보는 무조건 일반적인 속성으로 둘 필요가 없다.

시스템에서 Department, Professor가 독립적인 객체라면

Course ───── Department
Lecture ──── Professor

처럼 객체 사이의 연관관계로 표현할 수 있다.

결국 속성을 찾는다는 것은 단순히 문제 설명에서 명사를 골라 클래스 안에 넣는 작업이 아니었다.

이 정보가 현재 시스템에 필요한가?

이것은 단순한 값인가?

독립적인 객체로 봐야 하는가?

다른 클래스와의 관계로 표현해야 하는가?

객체마다 따로 존재해야 하는가?

클래스 전체가 공유해야 하는가?

다른 속성으로 계산할 수 있는가?

를 계속 판단하는 과정에 가깝다.

시험 대비 정리

이번 장에서 특히 확인해야 할 부분을 정리하면 다음과 같다.

UML 속성 표기

- name : String

-       → private
name    → 속성 이름
String  → 타입

가시성은

+ → public
- → private
# → protected
~ → package

로 표현한다.

다중성

1     → 하나
0..1  → 없거나 하나
*     → 여러 개
1..*  → 하나 이상

클래스 사이의 연관관계를 그릴 때 중요하다.

인스턴스 속성과 클래스 속성

Instance Attribute
→ 객체마다 각각 존재

Class Scope Attribute
→ 모든 객체가 공유
→ Java의 static과 연결
→ UML에서는 밑줄

유도 속성

/age

처럼 /로 표시한다.

다른 속성으로부터 계산 가능한 속성

이라는 의미다.

⭐ 시험에서 연관관계 문제를 풀 때

자료에서 직접 시험 문제로 표시한 부분이다.

여러 클래스를 주고

연관관계를 맺어라.

라고 한다면 다음 순서로 풀어본다.

1. 주어진 클래스를 전부 확인한다.

2. 각 클래스의 속성을 확인한다.

3. 다른 클래스를 가리키는 속성을 찾는다.

   department
   course_id
   professor_id
   ...

4. 그 대상이 별도의 클래스로 존재하는지 확인한다.

5. 단순 속성이 아니라 연관관계로 표현할 수 있는지 판단한다.

6. 기존의 중복된 속성을 정리한다.

7. 클래스 사이에 Association을 연결한다.

8. 관계의 의미를 보고 다중성을 결정한다.

예를 들어

Course.department

가 있고 Department 클래스가 존재한다면

Course ───────── Department

를 생각한다.

Lecture.course_id가 있고 Course 클래스가 존재한다면

Course ───────── Lecture

를 생각한다.

Lecture.professor_id가 있고 Professor 클래스가 존재한다면

Lecture ──────── Professor

를 생각한다.

Professor.department가 있고 Department 클래스가 존재한다면

Professor ────── Department

를 생각한다.

그리고 마지막으로

1
0..1
*
1..*

등을 이용해 각 객체가 상대 객체와 몇 개까지 관계를 가질 수 있는지 표현한다.

마무리

이번 장에서 가장 중요하게 느껴진 부분은 속성과 객체의 경계를 구분하는 것이었다.

코드만 생각하면

String department;
String professorId;
String courseId;

처럼 전부 필드로 만들어도 프로그램은 작성할 수 있다.

하지만 도메인 모델에서는 한 단계 더 생각한다.

department는 정말 단순 문자열인가?

Professor는 ID 하나로만 표현할 대상인가?

Course와 Lecture는 어떤 관계인가?

이런 질문을 통해 현실 세계의 개념을 클래스로 나누고 관계를 표현한다.

그래서 이번 장의 내용을 한 문장으로 정리하면 다음과 같다.

속성을 찾는다는 것은 객체가 가진 정보를 나열하는 것이 아니라, 어떤 정보가 객체의 값이고 어떤 정보가 다른 객체와의 관계인지를 결정하는 과정이다.

이 장의 가장 큰 흐름은 다음과 같다.

수와 코드 → 논리 게이트 → Flip-Flop → Register → Bus → Register 간 데이터 전송

처음에는 각각 별개의 내용처럼 보이지만, 결국 컴퓨터가 0과 1을 어떻게 표현하고, 계산하고, 기억하고, 이동시키는가를 배우는 과정이다.

2.1 수와 코드

1. 2진수와 논리회로

컴퓨터 내부의 전기회로에서는 두 가지 상태를 구분하기 쉽다.

예를 들어 전압의 높고 낮음을 추상화해서 다음과 같이 표현할 수 있다.

낮은 전압 → 0
높은 전압 → 1

즉, 실제 컴퓨터 내부에서는 전기 신호가 흐르고 있지만 이를 논리적으로는 0과 1이라는 두 값으로 생각한다.

이것이 컴퓨터에서 2진수(Binary)가 자연스럽게 사용되는 이유다.

2. 수의 체계와 Weight

우리가 평소 사용하는 숫자는 10진수다.

예를 들어 다음 숫자를 보자.

3025.37

우리는 그냥 삼천이십오 점 삼칠이라고 읽지만, 실제로 각 자리에는 서로 다른 가중치(Weight)가 존재한다.

숫자     3     0     2     5   .   3      7
Weight  10³   10²   10¹   10⁰     10⁻¹  10⁻²

따라서 3025.37은 실제로 다음과 같다.

3025.37

= 3 × 10³
+ 0 × 10²
+ 2 × 10¹
+ 5 × 10⁰
+ 3 × 10⁻¹
+ 7 × 10⁻²

계산하면

= 3000 + 0 + 20 + 5 + 0.3 + 0.07
= 3025.37

즉,

숫자의 실제 값 = 각 자리의 숫자 × 그 자리의 Weight를 모두 더한 것

이라고 생각하면 된다.

3. R진법의 일반적인 표현

10진수에서는 Weight가 다음과 같다.

..., 10³, 10², 10¹, 10⁰, 10⁻¹, 10⁻², ...

2진수에서는 다음과 같다.

..., 2³, 2², 2¹, 2⁰, 2⁻¹, 2⁻², ...

5진수에서는 다음과 같다.

..., 5³, 5², 5¹, 5⁰, 5⁻¹, 5⁻², ...

따라서 이를 일반적인 R진법으로 표현하면

..., R³, R², R¹, R⁰, R⁻¹, R⁻², ...

이 된다.

수학적으로는 다음과 같이 표현한다.

$begin:math:display$ V(N) = \sum A_kR^k $end:math:display$

여기서

• R : 몇 진법인지 나타내는 밑(Base, Radix)
• A_k : 각 자리에 들어있는 숫자
• R^k : 해당 자리의 Weight

이다.

그리고 R진수에서 사용할 수 있는 숫자는

0 ~ R-1

이다.

예시

2진수에서는

0, 1

만 사용할 수 있다.

5진수에서는

0, 1, 2, 3, 4

만 사용할 수 있다.

16진수에서는 총 16개의 기호가 필요하므로

0 1 2 3 4 5 6 7 8 9 A B C D E F

를 사용한다.

예제 2-2. (1234.2)₅

(1234.2)₅는 5진수다.

5진수이므로 각 자리의 Weight는 5의 거듭제곱이다.

숫자      1     2     3     4   .   2
Weight   5³    5²    5¹    5⁰      5⁻¹

따라서

(1234.2)₅

= 1 × 5³
+ 2 × 5²
+ 3 × 5¹
+ 4 × 5⁰
+ 2 × 5⁻¹

계산하면

= 125 + 50 + 15 + 4 + 0.4
= 194.4

따라서

(1234.2)₅ = (194.4)₁₀

이다.

중요한 점

5진수에서는 한 자리에 5 이상이 올 수 없다.

(1234)₅ → 가능

(1254)₅ → 불가능

왜냐하면 사용할 수 있는 숫자가

0, 1, 2, 3, 4

뿐이기 때문이다.

예제 2-3. (1011.1)₂

이번에는 2진수다.

각 자리의 Weight를 적어보면

숫자      1     0     1     1   .    1
Weight   2³    2²    2¹    2⁰       2⁻¹

따라서

(1011.1)₂

= 1 × 2³
+ 0 × 2²
+ 1 × 2¹
+ 1 × 2⁰
+ 1 × 2⁻¹

계산하면

= 8 + 0 + 2 + 1 + 0.5
= 11.5

따라서

(1011.1)₂ = (11.5)₁₀

이다.

2진수이기 때문에 각 자리에는 반드시

0 또는 1

만 올 수 있다.

4. 진법 변환 ⭐ 중요

시험 중요

특히 10진수 ↔ 2진수 ↔ 8진수 ↔ 16진수 변환은 직접 할 수 있어야 한다.

10진수를 R진수로 변환할 때는 정수와 소수의 방법이 다르다.

정수 부분 → R로 계속 나눈다.
소수 부분 → R을 계속 곱한다.

예제 2-6. 27.625₁₀ → 2진수

먼저 정수와 소수 부분을 분리한다.

27.625

정수 부분 : 27
소수 부분 : 0.625

4-1. 정수 부분 변환

27을 2진수로 바꾸려면 계속 2로 나눈다.

27 ÷ 2 = 13 ... 1
13 ÷ 2 =  6 ... 1
 6 ÷ 2 =  3 ... 0
 3 ÷ 2 =  1 ... 1
 1 ÷ 2 =  0 ... 1

나머지를 아래에서 위로 읽는다.

11011

따라서

27₁₀ = 11011₂

이다.

왜 2로 나누는가?

우리가 실제로 찾고 싶은 것은 다음 네모 안의 숫자다.

27 =
□ × 2⁴
+ □ × 2³
+ □ × 2²
+ □ × 2¹
+ □ × 2⁰

이를 변수로 표현하면

27 =
a₄ × 2⁴
+ a₃ × 2³
+ a₂ × 2²
+ a₁ × 2¹
+ a₀ × 2⁰

이다.

2진수이므로 각 a에는

0 또는 1

만 들어간다.

27을 직접 2의 거듭제곱으로 표현하면

27 = 16 + 8 + 2 + 1

= 1 × 2⁴
+ 1 × 2³
+ 0 × 2²
+ 1 × 2¹
+ 1 × 2⁰

따라서

11011₂

이다.

즉, Weight를 직접 보고 구해도 된다.

하지만 숫자가 커지면 불편하기 때문에 2로 계속 나누는 방법을 사용한다.

왜 나머지를 보는가?

27을 2로 나누면

27 = 2 × 13 + 1

이다.

마지막 1은 바로 2⁰ 자리에 들어갈 값이다.

다시 13을 2로 나누면

13 = 2 × 6 + 1

이때 나온 나머지는 2¹ 자리의 값이 된다.

즉 나머지가

2⁰ → 2¹ → 2² → ...

순서로 나오기 때문에 마지막에는 거꾸로 읽는 것이다.

4-2. 소수 부분 변환

이번에는

0.625

를 2진수로 바꿔보자.

소수는 반대로 2를 계속 곱한다.

0.625 × 2 = 1.25
              ↑
              1

정수 부분 1을 가져온다.

소수 부분 0.25만 남겨 다시 2를 곱한다.

0.25 × 2 = 0.5
            ↑
            0

다시

0.5 × 2 = 1.0
           ↑
           1

이번에는 정수 부분을 위에서 아래로 읽는다.

101

따라서

0.625₁₀ = 0.101₂

이다.

정수와 합치면

27.625₁₀ = 11011.101₂

가 된다.

왜 소수는 2를 곱하는가?

우리가 찾고 싶은 것은

0.625 =
□ × 2⁻¹
+ □ × 2⁻²
+ □ × 2⁻³
+ ...

이다.

이를

0.625 =
a₋₁ × 2⁻¹
+ a₋₂ × 2⁻²
+ a₋₃ × 2⁻³
+ ...

라고 하자.

양쪽에 2를 곱하면

1.25 =
a₋₁ × 2⁰
+ a₋₂ × 2⁻¹
+ a₋₃ × 2⁻²
+ ...

가 된다.

여기서 a₋₁ × 2⁰가 정수 부분으로 튀어나온다.

실제로

0.625 × 2 = 1.25

에서 정수 부분이 1이다.

따라서 첫 번째 소수 자리인 2⁻¹ 자리에는 1이 들어간다는 것을 알 수 있다.

다시 소수 부분 0.25에 2를 곱하면 다음 자리인 2⁻²를 알아낼 수 있다.

그래서

정수 → 나누기
소수 → 곱하기

를 사용하는 것이다.

예시 문제 1. 12.25₁₀ → 2진수

정수 부분

12 ÷ 2 = 6 ... 0
 6 ÷ 2 = 3 ... 0
 3 ÷ 2 = 1 ... 1
 1 ÷ 2 = 0 ... 1

아래에서 위로 읽으면

1100

이다.

소수 부분

0.25 × 2 = 0.5 → 0
0.5  × 2 = 1.0 → 1

따라서

0.01

이다.

최종적으로

12.25₁₀ = 1100.01₂

이다.

검산하면

1100.01₂

= 1×2³ + 1×2² + 1×2⁻²
= 8 + 4 + 0.25
= 12.25

이다.

예시 문제 2. 3/16

3/16 = 0.1875

그런데 16 = 2⁴이므로 더 쉽게 생각할 수 있다.

3/16
= 2/16 + 1/16
= 1/8 + 1/16
= 2⁻³ + 2⁻⁴

따라서

0.0011₂

이다.

예시 문제 3. 1/3

소수 부분 변환법을 사용한다.

1/3 × 2 = 2/3
정수 부분 → 0

다시

2/3 × 2 = 4/3 = 1 + 1/3
정수 부분 → 1

다시 1/3이 등장한다.

따라서 같은 과정이 무한 반복된다.

0.010101010101...

즉

1/3 = 0.010101...₂

이다.

01이 계속 반복된다.

이런 경우 반복되는 부분 위에 선이나 점을 표시하여 순환한다는 것을 나타낼 수 있다.

5. 자릿수와 로그

숫자의 자릿수를 알아낼 때 로그를 사용할 수 있다.

예를 들어

3205

는 몇 자리인가?

다음 관계가 성립한다.

1000 ≤ 3205 < 10000

이를 10의 거듭제곱으로 쓰면

10³ ≤ 3205 < 10⁴

이다.

양쪽에 log₁₀을 취하면

3 ≤ log₁₀(3205) < 4

이다.

따라서 log₁₀(3205)의 정수 부분은 3이다.

여기에 1을 더하면

3 + 1 = 4자리

가 된다.

따라서 일반적으로

10진수 N의 자릿수
= floor(log₁₀N) + 1

이다.

2진수의 자릿수

2진수에서는 밑을 2로 바꾸면 된다.

2진수 N의 자릿수
= floor(log₂N) + 1

시험 예시

문제

1000₁₀은 2진수에서 몇 자리인가?

2의 거듭제곱을 비교한다.

2⁹  = 512
2¹⁰ = 1024

따라서

512 ≤ 1000 < 1024

즉

2⁹ ≤ 1000 < 2¹⁰

이므로 필요한 자릿수는

10자리

이다.

6. 2진수, 8진수, 16진수 ⭐ 중요

다음 관계를 반드시 기억한다.

8  = 2³
16 = 2⁴

따라서

2진수 3자리 ↔ 8진수 1자리
2진수 4자리 ↔ 16진수 1자리

로 정확하게 대응한다.

7. 8진수 ↔ 2진수

각 8진수 숫자를 2진수 3자리로 바꾸면 된다.

0 → 000
1 → 001
2 → 010
3 → 011
4 → 100
5 → 101
6 → 110
7 → 111

예제 (523.25)₈

각 숫자를 3bit로 바꾼다.

5 → 101
2 → 010
3 → 011

.

2 → 010
5 → 101

따라서

(523.25)₈
=
(101_010_011.010_101)₂

이다.

여기서 _는 숫자를 읽기 쉽게 구분하기 위한 것이다.

101010011

과

101_010_011

은 같은 값이다.

8. 16진수

16진수는 총 16개의 숫자가 필요하다.

하지만 숫자 기호는 0~9까지밖에 없기 때문에 이후에는 알파벳을 사용한다.

10진수   16진수

0        0
1        1
...
9        9
10       A
11       B
12       C
13       D
14       E
15       F

그 다음 숫자는

10₁₆

이다.

주의해야 한다.

10₁₆ = 16₁₀

이다.

9. 16진수 ↔ 2진수

16은

16 = 2⁴

이므로 16진수 한 자리는 정확히 4bit와 대응한다.

0 → 0000
1 → 0001
...
A → 1010
B → 1011
C → 1100
D → 1101
E → 1110
F → 1111

예제. (D1AF)₁₆ → 8진수

바로 16진수에서 8진수로 바꾸려고 하지 말고

16진수 → 2진수 → 8진수

순서로 바꾸면 쉽다.

먼저

D → 1101
1 → 0001
A → 1010
F → 1111

따라서

D1AF₁₆
=
1101 0001 1010 1111₂

이제 8진수는 3bit씩 묶으면 된다.

오른쪽부터 3개씩 묶는다.

1 | 101 | 000 | 110 | 101 | 111

맨 앞은 3bit가 되도록 0을 붙여도 된다.

001 | 101 | 000 | 110 | 101 | 111

각각 8진수로 변환하면

001 → 1
101 → 5
000 → 0
110 → 6
101 → 5
111 → 7

따라서

(D1AF)₁₆ = (150657)₈

이다.

10. 컴퓨터는 1111을 어떻게 보는가?

여기서 매우 중요한 개념이 있다.

1111

이라는 bit가 있다고 하자.

우리는 이것을 보고

2진수 1111 = 15

라고 생각할 수 있다.

하지만 컴퓨터 내부의 bit 자체에는 '15'라는 의미가 들어있는 것이 아니다.

1111이라는 bit pattern을 어떤 규칙으로 해석하느냐에 따라 의미가 달라질 수 있다.

예를 들어

1111

은 상황에 따라

• 숫자의 일부
• 주소의 일부
• 명령어의 일부
• 문자 코드의 일부
• 여러 개의 ON/OFF 상태

등으로 사용될 수 있다.

즉,

컴퓨터 내부에는 결국 0과 1만 존재하고, 그 0과 1을 어떤 의미로 해석할지는 규칙에 의해 결정된다.

이 개념은 앞으로 컴퓨터구조를 이해할 때 매우 중요하다.

11. 왜 주소와 데이터를 16진수로 많이 표현하는가?

컴퓨터 내부에서는 실제로 2진수로 데이터를 처리한다.

그런데 2진수는 사람이 읽기에 너무 길다.

예를 들어

11111110110111001011101010011000

보다

FEDCBA98

처럼 16진수로 표현하는 것이 훨씬 읽기 쉽다.

왜 16진수를 사용하냐면

16진수 1자리 = 2진수 4자리

로 정확히 대응하기 때문이다.

그래서 메모리 주소나 기계어 등을 사람이 볼 때 16진수를 많이 사용한다.

12. BCD

BCD는

Binary Coded Decimal

의 약자다.

말 그대로 10진수의 각 자릿수를 이진 코드로 표현하는 방법이다.

일반적인 2진수와 BCD의 차이

예를 들어

59

가 있다고 하자.

일반적인 2진수

59라는 값 전체를 2진수로 바꾼다.

59₁₀ = 111011₂

BCD

59를

5
9

라는 두 개의 10진수 숫자로 따로 본다.

그리고 각각을 4bit로 바꾼다.

5 → 0101
9 → 1001

따라서

59 → 0101 1001

이 된다.

즉 BCD에서는

10진수 숫자 하나하나를 숫자의 값 전체가 아니라 하나의 기호처럼 따로 코드화한다.

라고 이해하면 된다.

13. bit와 Byte

기본 단위는 반드시 기억한다.

1 bit = 0 또는 1 하나

그리고

1 Byte = 8 bit

이다.

일반적으로

b = bit
B = Byte

라고 쓴다.

따라서

1B = 8b

이다.

14. 문자 코드와 ASCII

컴퓨터는 문자도 결국 0과 1로 저장해야 한다.

예를 들어 사람이

A

라고 입력했다고 하자.

컴퓨터가 문자 A 자체를 저장하는 것이 아니라, A에 해당하는 숫자 코드를 저장한다.

ASCII에서는

A = 65

로 약속되어 있다.

65를 2진수로 표현하면

1000001

이다.

따라서

A → 1000001

로 표현할 수 있다.

b6 b5 b4 b3 b2 b1 b0는 무엇인가?

각 bit의 자리 이름이다.

b6 b5 b4 b3 b2 b1 b0

각 자리의 Weight는

2⁶ 2⁵ 2⁴ 2³ 2² 2¹ 2⁰

이다.

A의 코드인 1000001을 넣으면

b6 b5 b4 b3 b2 b1 b0
 1  0  0  0  0  0  1

이다.

따라서

1 × 2⁶ + 1 × 2⁰
= 64 + 1
= 65

가 된다.

그래서 ASCII 코드 65가 A다.

문자열도 결국 숫자다

예를 들어

good morning

이라는 문자열도 컴퓨터 내부에서는

g → 문자 코드
o → 문자 코드
o → 문자 코드
d → 문자 코드
공백 → 문자 코드
m → 문자 코드
...

처럼 문자 하나하나가 숫자로 저장된다.

즉 컴퓨터 입장에서는 문자열도 결국 bit들의 집합이다.

Unicode

ASCII만으로는 영어 중심의 제한된 문자만 표현할 수 있다.

한글, 일본어, 중국어 등 세계의 다양한 문자를 표현하기 위해 훨씬 큰 문자 체계가 필요하다.

그래서 Unicode가 사용된다.

현재 단계에서는

Unicode = 세계 여러 문자를 하나의 문자 코드 체계로 표현하기 위한 표준

정도로 이해하면 충분하다.

2.2 조합 논리회로

1. 조합 논리회로와 순차 논리회로

디지털 회로는 크게 두 종류로 생각할 수 있다.

조합 논리회로

현재 입력만 보고 현재 출력이 결정된다.

현재 입력
   ↓
조합 논리회로
   ↓
현재 출력

과거에 어떤 값이 들어왔는지는 중요하지 않다.

프로그래밍으로 비유하면 상태가 없는 함수와 비슷하다.

순차 논리회로

현재 입력뿐만 아니라 이전에 저장되어 있던 상태도 출력에 영향을 준다.

현재 입력 ─┐
           ↓
       순차 논리회로 → 출력
           ↑
        이전 상태

즉 기억 능력이 있다.

2. 논리 게이트

논리 게이트는 0과 1을 입력받아 특정 규칙에 따라 0 또는 1을 출력하는 가장 기본적인 회로다.

AND

두 입력이 모두 1일 때만 1이다.

A B | Y
---------
0 0 | 0
0 1 | 0
1 0 | 0
1 1 | 1

프로그래밍으로 생각하면

A && B

와 비슷하다.

OR

하나라도 1이면 1이다.

A B | Y
---------
0 0 | 0
0 1 | 1
1 0 | 1
1 1 | 1

XOR

두 값이 서로 다르면 1이다.

A B | Y
---------
0 0 | 0
0 1 | 1
1 0 | 1
1 1 | 0

즉

같으면 0
다르면 1

이다.

NOT

입력을 반대로 만든다.

A | Y
------
0 | 1
1 | 0

NAND

AND의 결과를 NOT한다.

NAND = NOT(AND)

따라서

A B | Y
---------
0 0 | 1
0 1 | 1
1 0 | 1
1 1 | 0

이다.

NOR

OR의 결과를 NOT한다.

NOR = NOT(OR)

XNOR

XOR의 결과를 NOT한다.

따라서 두 값이 같으면 1이다.

A B | Y
---------
0 0 | 1
0 1 | 0
1 0 | 0
1 1 | 1

Buffer

입력을 그대로 출력한다.

0 → 0
1 → 1

논리적으로 아무것도 하지 않는 것처럼 보이지만, 실제 회로에서는 신호 전달이나 회로 분리 등에 사용한다.

뒤에서 배우는 3-State Buffer가 Bus를 구성할 때 매우 중요하다.

3. 정논리와 부논리

정논리

일반적으로

높은 전압 → 논리 1
낮은 전압 → 논리 0

으로 해석한다.

부논리

반대로

높은 전압 → 논리 0
낮은 전압 → 논리 1

로 해석한다.

중요한 것은 실제 전기 신호가 바뀌는 것이 아니라 그 신호에 어떤 논리적 의미를 부여하느냐가 달라지는 것이다.

2.3 순차 논리회로

1. 동기식 순차 논리회로

순차 논리회로는 값을 기억할 수 있다.

그중 동기식 순차 논리회로는 Clock이라는 공통 신호에 맞춰 상태가 변한다.

Clock은 여러 회로에게

지금 값을 받아!
지금 상태를 바꿔!

라고 알려주는 공통 박자라고 생각하면 된다.

2. Flip-Flop ⭐ 시험 중요

Flip-Flop은 1bit의 데이터를 저장하는 기억 소자다.

이 문장은 반드시 기억한다.

Flip-Flop 1개 → 1bit 저장

예를 들어 Flip-Flop의 출력 Q가

Q = 1

이라면 현재 1이라는 1bit 정보를 기억하고 있는 것이다.

Q와 Q̅

Flip-Flop 그림에는 일반적으로 두 개의 출력이 있다.

Q
Q̅

Q는 정상 출력이다.

Q̅는 Q의 반대 값이다.

Q = 0 → Q̅ = 1
Q = 1 → Q̅ = 0

이다.

3. Clock Pulse(CP)

Clock은 다음과 같이 0과 1을 반복하는 신호다.

       ┌─────┐       ┌─────┐
───────┘     └───────┘     └──────
       ↑     ↓       ↑     ↓

Clock이

0 → 1

로 변하는 순간을 상승 에지(Rising Edge, Positive Edge)라고 한다.

      ↑
______|‾‾‾‾‾

반대로

1 → 0

로 변하는 순간은 하강 에지(Falling Edge, Negative Edge)다.

‾‾‾‾‾|______
      ↓

Edge Sensitive

Flip-Flop은 Clock의 특정 순간(edge)에 반응한다.

예를 들어 Positive Edge Triggered Flip-Flop이라면

Clock 0 → 1

이 되는 바로 그 순간에 입력을 확인한다.

따라서 앞으로 타이밍 다이어그램을 볼 때 가장 먼저 해야 하는 것은

1. Clock을 찾는다.
2. 상승 에지 ↑를 모두 표시한다.
3. 각 ↑ 순간의 입력을 확인한다.
4. Flip-Flop의 규칙에 따라 Q를 결정한다.

이다.

이것이 순차 논리회로의 그림을 읽는 가장 중요한 방법이다.

Latch와 Flip-Flop의 차이 ⭐ 시험 가능

둘 다 데이터를 기억할 수 있지만 언제 입력에 반응하는가가 다르다.

Latch

특정 레벨(Level)이 유지되는 동안 입력에 반응한다.

예를 들어 Enable이 1인 동안 입력이 바뀌면 출력도 영향을 받을 수 있다.

따라서

Latch → Level Sensitive

이다.

Flip-Flop

Clock의 특정 Edge 순간에만 입력을 받아들인다.

따라서

Flip-Flop → Edge Sensitive

이다.

시험용으로 기억

Latch      = Level Sensitive
Flip-Flop  = Edge Sensitive

4. Setup Time, Hold Time, Delay Time

Flip-Flop이 Clock의 상승 에지에서 D 값을 읽는다고 하자.

그런데 Clock이 올라가는 정확한 순간에 D가 계속 변하고 있다면 안정적으로 값을 읽기 어렵다.

그래서 입력이 일정 시간 동안 안정되어 있어야 한다.

Setup Time

Clock edge가 발생하기 이전에 입력값이 미리 안정되어 있어야 하는 최소 시간이다.

             Clock ↑
                 │
D ───────────────1────────────
        <-------->
        Setup Time

즉

"Clock이 올라오기 직전에는 D를 바꾸지 마라."

라고 생각하면 된다.

Hold Time

Clock edge가 발생한 이후에도 입력을 일정 시간 유지해야 한다.

             Clock ↑
                 │
D ───────────────1────────────
                 <------->
                 Hold Time

즉

"Clock이 올라간 직후에도 바로 D를 바꾸지 마라."

라는 의미다.

Delay Time

Clock edge가 발생했다고 해서 출력 Q가 물리적으로 0초 만에 변하는 것은 아니다.

실제 회로이기 때문에 약간의 시간이 필요하다.

Clock ↑
   │
   │   Delay
   └────────→ Q 변화

이를 Propagation Delay라고 한다.

일반적으로 Delay가 작으면 더 빠르게 동작할 수 있다.

실제 부품을 선택할 때 Datasheet를 보고

• Setup Time
• Hold Time
• Propagation Delay

등을 확인할 수 있다.

5. Flip-Flop의 종류

D Flip-Flop

가장 이해하기 쉬운 Flip-Flop이다.

규칙은 하나다.

Clock의 유효 Edge 순간의 D 값을 Q에 저장한다.

즉

Clock ↑일 때

Q ← D

이다.

예시

현재

Q = 0

이라고 하자.

Clock 상승 에지 순간에

D = 1

이라면

Q ← 1

이 된다.

그 이후 D가 다시 0으로 바뀌더라도 다음 Clock 상승 에지가 오기 전까지 Q는 계속 1을 유지한다.

D      0 ---- 1 ---- 0 --------
                ↑
Clock ----------|---------------
                ↑
             이 순간 D=1

Q      0 -------1---------------

즉 D의 값이 Q로 전달되지만 Clock에 맞춰 저장된다.

SR Flip-Flop

S는 Set, R은 Reset이다.

S = Set   → Q를 1로
R = Reset → Q를 0으로

따라서 기본적으로

S=1 → Q=1
R=1 → Q=0

라고 이해하면 된다.

JK Flip-Flop ⭐ 중요

JK Flip-Flop은 다음 표를 기억해야 한다.

J K | 다음 Q
----------------
0 0 | 현재 값 유지
0 1 | 0
1 0 | 1
1 1 | 현재 Q 반전

즉

J=0, K=0
→ 아무것도 하지 않는다.

J=0, K=1
→ Q를 0으로 만든다.

J=1, K=0
→ Q를 1로 만든다.

J=1, K=1
→ Q를 반대로 바꾼다.

마지막 11이 특히 중요하다.

현재

Q=0

이면

Q=1

로 바뀌고,

현재

Q=1

이면

Q=0

으로 바뀐다.

이를 Toggle이라고 한다.

T Flip-Flop

T Flip-Flop은 더 간단하다.

T | 다음 Q
-------------
0 | 현재 Q 유지
1 | 현재 Q 반전

즉

T=0 → Q
T=1 → Q̅

이다.

그래서 Counter 같은 회로를 만들 때 유용하다.

6. 상승 에지 JK Flip-Flop의 동작 ⭐⭐⭐

이 부분은 Q 출력 파형을 직접 그리는 문제가 나올 수 있다.

그림을 볼 때 절대 모든 선을 한 번에 보려고 하지 않는다.

다음 순서대로 본다.

STEP 1. Clock 상승 에지를 찾는다.

        ↑       ↑       ↑       ↑
Clock __|‾|_____|‾|_____|‾|_____|‾

Positive Edge Triggered JK FF라면 이 순간만 보면 된다.

STEP 2. 각 상승 에지 순간의 J와 K를 확인한다.

예를 들어 첫 번째 상승 에지에서

J=1
K=0

이라면 JK 표에서

10 → Q=1

이다.

STEP 3. 다음 상승 에지까지 Q를 유지한다.

Clock 중간에 J와 K가 변해도 Q가 바로 변하는 것이 아니다.

다음 상승 에지가 올 때까지 현재 값을 유지한다.

예시

초기 상태가

Q=0

이라고 하자.

각 상승 에지에서 J,K가 다음과 같다고 하자.

첫 번째 ↑ : J=1, K=0
두 번째 ↑ : J=0, K=0
세 번째 ↑ : J=1, K=1
네 번째 ↑ : J=0, K=1

하나씩 계산한다.

첫 번째 ↑

J=1, K=0
→ Set
→ Q=1

두 번째 ↑

J=0, K=0
→ 유지
→ Q=1

세 번째 ↑

J=1, K=1
→ 반전
→ Q=0

네 번째 ↑

J=0, K=1
→ Reset
→ Q=0

따라서 Q는

초기 0
→ 1
→ 1
→ 0
→ 0

으로 변한다.

⭐ 타이밍 다이어그램 풀이 공식

앞으로 Flip-Flop 파형 문제를 보면 무조건 다음 순서로 푼다.

① Clock을 찾는다.

② 유효 Edge를 표시한다.
   Positive → ↑
   Negative → ↓

③ 해당 순간의 입력을 읽는다.

④ Flip-Flop의 동작표를 적용한다.

⑤ 다음 Edge까지 Q를 유지한다.

이것만 기억하면 된다.

7. Register ⭐ 중요

Flip-Flop 하나는

1bit

를 저장한다.

그렇다면 4bit 데이터를 저장하려면 Flip-Flop이 몇 개 필요할까?

4개

이다.

예를 들어

[D FF] → 1bit
[D FF] → 1bit
[D FF] → 1bit
[D FF] → 1bit

이렇게 4개를 묶으면 4bit Register가 된다.

따라서

Register = 여러 개의 Flip-Flop을 묶어 여러 bit의 데이터를 저장하는 장치

라고 이해하면 된다.

Register의 Input과 Output

4bit Register를 예로 들면

Input
D3 D2 D1 D0
│  │  │  │
▼  ▼  ▼  ▼
[FF][FF][FF][FF]
│  │  │  │
▼  ▼  ▼  ▼
Q3 Q2 Q1 Q0
Output

이다.

D는 입력,

Q는 현재 Register에 저장되어 있는 출력이다.

예를 들어

D = 1011

이고 저장 조건이 만족되면

Q ← 1011

이 된다.

Control Signal

Register 그림에는 데이터 이외에도

Clear
Enable
Clock

같은 신호가 존재한다.

이들은 저장하려는 데이터 자체가 아니다.

Register에게

초기화해라.
저장을 허용해라.
지금 저장해라.

와 같은 명령을 내린다.

그래서 Control Signal(제어 신호)이라고 한다.

/Clear : Low Active

그림에서

/Clear

처럼 /가 붙어 있다면 일반적으로 Low Active라는 뜻이다.

즉 0일 때 기능이 작동한다.

/Clear = 0 → Clear 작동
/Clear = 1 → Clear 작동하지 않음

Clear가 작동하면

Q = 0000

으로 초기화한다.

Enable : High Active

Enable은 일반적으로

Enable = 1 → 동작 허용
Enable = 0 → 현재 상태 유지

이다.

즉 1일 때 기능이 활성화되므로 High Active다.

Register의 제어 신호 우선순위 ⭐ 시험 중요

교수님 설명에서 Clear가 가장 강한 신호라고 이해하면 된다.

예를 들어 다음 표를 생각해보자.

/Clear | Enable | Clock | 결과
--------------------------------
   0   |   X    |   X   | Q=0
   1   |   0    |   X   | Q 유지
   1   |   1    |   ↑   | Q ← D

여기서 X는

Don't Care

라는 뜻이다.

즉 0이든 1이든 상관없다.

첫 번째 경우

/Clear = 0

이면 다른 신호는 볼 필요가 없다.

Q = 0000

이 된다.

따라서 Clear가 가장 우선순위가 높다.

두 번째 경우

/Clear = 1
Enable = 0

이면 Clear는 작동하지 않지만 Enable이 꺼져 있다.

따라서

Q 유지

이다.

세 번째 경우

/Clear = 1
Enable = 1
Clock ↑

이면 입력 D를 저장한다.

Q ← D

이다.

비동기 Clear와 동기 적재

Clear가 비동기(Asynchronous)라면 Clock을 기다리지 않는다.

/Clear : 1 → 0

이 되는 순간

Q=0000

이 된다.

반면 일반적인 데이터 적재는

Clock ↑

를 기다린다.

따라서 동기식(Synchronous)이다.

8. 4bit Register 동작 파형 읽기 ⭐⭐⭐

이 그래프는 시험에서 매우 중요할 가능성이 있다.

그래프에

Clear
Enable
Clock
D
Q

가 있다고 하자.

한 번에 다 보지 않는다.

다음 순서대로 본다.

1단계. Clear부터 본다.

/Clear = 0

이면 즉시

Q=0000

이다.

다른 신호는 무시한다.

2단계. Clear=1이면 Enable을 본다.

Enable=0

이면

Q 유지

이다.

3단계. Enable=1이면 Clock 상승 에지를 찾는다.

Clock ↑

인 순간의 D를 읽는다.

예를 들어

D=0011

이라면

Q ← 0011

이다.

4단계. 다음 유효 Clock까지 Q를 유지한다.

D가 중간에

0011
→ 1010
→ 1111
→ 0101

처럼 계속 변해도 Clock 상승 에지가 없다면 Q는 바뀌지 않는다.

이것이 동기 적재(Synchronous Load)다.

9. Shift Register

Shift Register는 Register에 저장된 bit들을 Clock에 맞춰 한 칸씩 이동시키는 Register다.

예를 들어

SI → [FF0] → [FF1] → [FF2] → [FF3]
        │       │       │       │
       Q0      Q1      Q2      Q3

와 같은 구조가 있다고 하자.

SI는

Serial Input

즉 직렬 입력이다.

직렬 데이터란?

예를 들어 1100이라는 4bit 데이터를 보내고 싶다고 하자.

병렬 전송이라면

1 1 0 0
↓ ↓ ↓ ↓

4bit를 동시에 보낸다.

직렬 전송은

1 → 1 → 0 → 0

처럼 한 번에 1bit씩 보낸다.

Shift Register의 동작

초기값을

0000

이라고 하자.

SI로 데이터를 하나씩 입력한다.

예를 들어 회로의 이동 방향이 다음과 같다고 하자.

SI → Q0 → Q1 → Q2 → Q3

Clock이 한 번 상승할 때마다 한 칸씩 이동한다.

예를 들어 SI에 차례대로

1, 1, 0, 0

을 넣으면 각 Clock마다 저장된 값이 이동한다.

중요한 것은 정확한 숫자의 좌우 방향을 무작정 외우는 것이 아니다.

자료의 화살표를 보고 SI가 어느 Flip-Flop에 들어가고, 각 Q가 다음 어느 D로 연결되는지를 확인해야 한다.

핵심 원리는

Clock ↑
→ 모든 bit가 동시에 한 칸 이동

이다.

직렬 데이터를 병렬 데이터로 바꾼다는 의미

SI에서는 한 번에 1bit만 들어온다.

SI

1
↓
다음 Clock
1
↓
다음 Clock
0
↓
다음 Clock
0

그런데 충분한 Clock이 지난 후 Register의

Q3 Q2 Q1 Q0

를 동시에 읽으면 4bit를 한 번에 얻을 수 있다.

즉

Serial Input
     ↓
Shift Register
     ↓
Parallel Output

이 가능하다.

그래서 Shift Register를 직렬 데이터를 병렬 데이터로 변환하는 데 사용할 수 있다.

10. 4bit 양방향 Shift Register

일반 Shift Register가 한 방향으로만 이동한다면 양방향 Shift Register는

왼쪽 Shift ←
오른쪽 Shift →

둘 다 가능하다.

어느 방향으로 이동할지는 Control Signal이 결정한다.

자료에서는 S1, S0 같은 선택 신호의 조합에 따라 동작을 선택한다.

예를 들어 구조적으로는

S1 S0 | 동작
---------------------
0  0  | 현재 값 유지
0  1  | 오른쪽 Shift
1  0  | 왼쪽 Shift
1  1  | 병렬 Load

와 같이 여러 기능 중 하나를 선택하는 형태로 이해하면 된다.

정확한 S1, S0 조합은 수업 자료의 표를 기준으로 외우고, 핵심은 제어 신호 조합으로 Register가 수행할 동작을 선택한다는 것이다.

11. Counter

Counter는

정해진 순서대로 상태를 반복적으로 변화시키는 Register의 일종

이다.

예를 들어 4bit 이진 Counter는 다음처럼 상태가 변할 수 있다.

0000 → 0
0001 → 1
0010 → 2
0011 → 3
0100 → 4
...
1110 → 14
1111 → 15
0000 → 0
...

즉

0 → 1 → 2 → ... → 15 → 0 → ...

을 계속 반복한다.

Counter의 상태도

자료의 원형 그림에서

0000 → 0001 → 0010 → ... → 1111
 ↑                            ↓
 └────────────────────────────┘

처럼 연결되어 있는 이유가 이것이다.

마지막 상태가 끝나면 다시 처음 상태로 돌아간다.

Counter의 출력 파형

4bit Counter를

Q3 Q2 Q1 Q0

라고 하자.

숫자를 하나씩 증가시키면

0  = 0000
1  = 0001
2  = 0010
3  = 0011
4  = 0100
5  = 0101
6  = 0110
7  = 0111
8  = 1000
...

이 된다.

따라서 가장 낮은 자리 Q0는 매번 바뀐다.

Q0 : 0 1 0 1 0 1 0 1 ...

Q1은 두 번마다 바뀐다.

Q1 : 0 0 1 1 0 0 1 1 ...

Q2는 네 번마다 바뀐다.

Q2 : 0 0 0 0 1 1 1 1 ...

Q3는 여덟 번마다 바뀐다.

Q3 : 0 0 0 0 0 0 0 0 1 1 1 1 ...

따라서 각 출력의 주파수도 계속 절반으로 줄어든다.

12. 병렬 적재 가능한 4bit 이진 Counter

일반 Counter는

Q ← Q + 1

을 반복한다.

하지만 병렬 적재 기능이 있다면 원하는 초기값을 한 번에 넣을 수도 있다.

예를 들어

D = 1010

이고 Load가 활성화되어 있다면

Q ← 1010

으로 값을 넣을 수 있다.

그 후 Counter를 동작시키면

1010
1011
1100
1101
...

처럼 카운트할 수 있다.

즉 각 제어 신호의 역할을 다음처럼 생각하면 된다.

Clear  → 0으로 초기화
Load   → D값을 Q에 적재
Enable → Counting 허용
Clock  → 실제 상태가 변하는 시점

2.4 레지스터 전송

이제 지금까지 배운 Register들을 서로 연결한다.

CPU 내부에는 수많은 Register가 존재한다.

그리고 Register 사이에서 데이터를 이동시키고 연산해야 한다.

1. 마이크로오퍼레이션

마이크로오퍼레이션(Microoperation)은

컴퓨터 내부에서 Register에 저장된 데이터에 대해 수행되는 기본적인 작은 동작

이라고 이해하면 된다.

예를 들어

R2 ← R1

은 R1의 값을 R2로 전달하는 동작이다.

또

R3 ← R1 + R2

는 R1과 R2를 더해서 R3에 저장하는 동작이다.

2. Register 간 데이터 전달

다음 표현을 보자.

R2 ← R1

프로그래밍으로 비유하면

R2 = R1;

과 비슷하다.

화살표는 오른쪽에서 왼쪽으로 데이터가 이동한다고 읽는다.

R1 ───────→ R2

주의할 점은 R1의 데이터가 사라지는 것이 아니다.

복사된다.

예를 들어

R1 = 1010
R2 = 0000

에서

R2 ← R1

을 수행하면

R1 = 1010
R2 = 1010

이 된다.

4/ 표시는 무엇인가?

회로 그림의 선 옆에

4/

처럼 적혀 있다면 그 선이 하나의 bit가 아니라 4bit를 동시에 전달하는 선 묶음이라는 의미다.

즉

────── 4/ ──────

는 실제로는

bit 0 ─────────
bit 1 ─────────
bit 2 ─────────
bit 3 ─────────

네 개의 선을 간단하게 표현한 것이다.

R1과 R2가 Clock을 공유하는 이유

두 Register가 같은 Clock을 사용하면 같은 시간 기준으로 동작할 수 있다.

즉

Clock ↑

라는 공통 시점을 기준으로 데이터를 전달하고 저장한다.

이를 통해 여러 Register의 동작을 동기화할 수 있다.

T1 : R2 ← R1

이 표현을 해석해보자.

T1 : R2 ← R1

은

T1이라는 제어 시점에 R1의 데이터를 R2에 저장한다.

라는 뜻이다.

예를 들어 현재

R1의 Q = 1100

이라고 하자.

R1의 출력이 R2의 입력 D에 연결되어 있다.

R1 Q ─────────→ R2 D

T1이 활성화되면 R2의 Enable이 활성화된다.

하지만 바로 Q2가 바뀌는 것은 아니다.

R2가 상승 에지 Flip-Flop으로 구성되어 있다면

Clock ↑

를 기다린다.

Clock이 올라가는 순간

R2 ← R1

이 이루어진다.

따라서

R2 = 1100

이 된다.

Register 데이터 전송 타이밍 다이어그램 읽는 법 ⭐⭐⭐

이 부분에서 가장 중요한 개념은

Enable은 저장할 준비를 시키고, 실제 저장은 Clock Edge에서 일어난다.

는 것이다.

순서를 보면

① R1에 데이터가 존재한다.

② T1이 활성화된다.

③ T1에 의해 R2 Enable이 활성화된다.

④ R1의 Q가 R2의 D에 들어와 있다.

⑤ Clock ↑

⑥ R2가 D를 저장한다.

⑦ 약간의 Delay 후 Q2에서 새로운 값이 나타난다.

이다.

그래서 타이밍 그래프에서 계속 Clock이 올라가는 순간을 보는 것이다.

3. Register를 이용한 병렬 덧셈

이번에는 단순히 데이터를 복사하는 것이 아니라 계산한다.

예를 들어

R2 ← R1 + R0

을 수행한다고 하자.

이때 중간에 ALU가 사용된다.

ALU란?

ALU는

Arithmetic Logic Unit

의 약자다.

우리말로 산술 논리 연산 장치다.

다음과 같은 계산을 수행한다.

덧셈
뺄셈
AND
OR
XOR
...

중요한 점은

ALU는 기본적으로 조합 논리회로다.

즉 ALU 자체가 결과를 기억하는 것이 아니다.

입력이 들어오면 입력에 따라 결과가 만들어진다.

Register + ALU

구조를 단순하게 보면

R1 ─────┐
        ↓
       ALU ─────→ R2
        ↑
R0 ─────┘

이다.

예를 들어

R1 = 0101
R0 = 0011

이면 ALU에서

0101
+0011
-----
1000

을 계산한다.

ALU는 조합 논리회로이기 때문에 입력이 들어오면 약간의 전파 지연 후 결과가 출력된다.

그 결과가 R2의 D 입력에 도착한다.

그 후

R2 Enable = 1
Clock ↑

이면

R2 ← 1000

이 된다.

즉 CPU 내부에서 매우 자주 등장하는 구조가

Register
   ↓
  ALU
   ↓
Register

이다.

4. Bus 전송 ⭐ 중요

Register가 두 개뿐이라면 서로 직접 연결할 수 있다.

하지만 CPU 안에 Register가

R0
R1
R2
R3
R4
...

처럼 많이 존재한다고 하자.

모든 Register를 서로 직접 연결하면 선이 너무 많아진다.

그래서 여러 Register가 하나의 공통 데이터 통로를 공유한다.

이 공통 데이터 선을 Bus라고 한다.

Bus = 여러 Register 또는 장치가 공유하는 데이터 전송 통로

왜 Bus가 필요한가?

예를 들어

R0 → R1
R0 → R2
R0 → R3
R1 → R0
R1 → R2
R1 → R3
...

를 전부 별도 선으로 연결하면 회로가 매우 복잡해진다.

대신

R0 ─┐
R1 ─┤
R2 ─┼──── BUS ────→ Register들
R3 ─┘

처럼 공용 도로 하나를 만든다.

Bus의 가장 중요한 규칙 ⭐

한 순간에 하나의 Register만 Bus에 데이터를 출력해야 한다.

왜냐하면 R0가 Bus에

1010

을 출력하고 있는데 동시에 R1이

0101

을 출력하려고 하면 같은 선에서 충돌하기 때문이다.

따라서

한 순간 → 하나의 Source만 Bus 사용

이 원칙이 중요하다.

High Impedance 상태

여기서 3-State Buffer가 사용된다.

일반적인 논리 신호는

0
1

두 가지라고 배웠다.

그런데 3-State Buffer에는 세 번째 상태가 있다.

0
1
Z

여기서 Z가

High Impedance

상태다.

쉽게 말하면

"나는 지금 이 선에서 빠져 있을게."

라는 상태다.

왜 High-Z가 필요한가?

예를 들어 R0, R1, R2가 같은 Bus에 연결되어 있다고 하자.

현재 R1의 값을 Bus에 출력하고 싶다.

그러면

R0 → Z
R1 → 1010
R2 → Z

로 만든다.

그러면 Bus에는

1010

만 나타난다.

R0와 R2도 물리적으로 Bus에 연결되어 있지만 High-Z 상태이므로 Bus를 구동하지 않는다.

따라서 여러 장치가 하나의 Bus를 공유할 수 있다.

Bus를 통한 Register 전송

예를 들어

R2 ← R0

을 Bus를 통해 수행한다고 하자.

순서는 다음과 같다.

① R0의 3-State Buffer 활성화

② R0의 Q가 Bus에 나타남

③ 다른 Register의 출력은 High-Z

④ Bus의 값이 R2의 D에 도착

⑤ R2 Enable 활성화

⑥ Clock ↑

⑦ R2가 Bus의 값을 저장

⑧ R2의 Q에서 새로운 값 출력

그림으로 보면

R0
 │
 ▼
3-State Buffer
 │
 ▼
 BUS ─────────→ D of R2
                   │
              Clock ↑
                   │
                   ▼
                  Q2

이다.

5. Bus 연산

이제 Bus와 ALU를 결합한다.

자료에는

ABus
BBus

가 등장한다.

처음 보면 Bus가 왜 두 개나 있는지 헷갈린다.

이유는 간단하다.

ALU는 보통 두 개의 입력을 받아 연산해야 하기 때문이다.

예를 들어

R3 ← R1 + R2

를 계산하고 싶다.

R1과 R2 두 값이 동시에 ALU에 들어가야 한다.

따라서

R1 → ABus
R2 → BBus

로 보낸다.

그림으로 표현하면

R1 ─────→ ABus ─────┐
                     │
                     ▼
                   ┌─────┐
                   │ ALU │ ─────→ Result Bus
                   └─────┘
                     ▲
                     │
R2 ─────→ BBus ─────┘

이다.

예시

현재

R1 = 0011
R2 = 0101

이라고 하자.

다음 연산을 수행한다.

R3 ← R1 + R2

먼저

ABus = 0011
BBus = 0101

이 된다.

ALU가 덧셈을 수행한다.

0011
0101
----
1000

따라서 Result Bus에는

1000

이 나타난다.

R3 Enable이 활성화되어 있고 Clock이 상승하면

R3 ← 1000

이 된다.

Bus 연산 타이밍 다이어그램 읽는 방법 ⭐⭐⭐

복잡해 보여도 다음 순서만 보면 된다.

1. ABus의 Source를 찾는다.

어떤 Register가 ABus를 사용하고 있는가?

예를 들어

R1 → ABus

라면

ABus = Q1

이다.

2. BBus의 Source를 찾는다.

예를 들어

R2 → BBus

라면

BBus = Q2

이다.

3. ALU 연산을 확인한다.

예를 들어 Add라면

Result = ABus + BBus

이다.

4. Destination Register의 Enable을 확인한다.

예를 들어

R3 Enable = 1

인지 확인한다.

5. Clock 상승 에지를 확인한다.

Clock ↑

순간 Result Bus의 값을 R3가 저장한다.

따라서

R3 ← Result

가 된다.

결국 Bus 연산은 이것이다

Source Register A
       ↓
      ABus ─────┐
                │
                ▼
               ALU
                ▲
                │
      BBus ─────┘
       ↑
Source Register B

                ↓
           Result Bus
                ↓
      Destination Register
                ↓
             Clock ↑
                ↓
              저장

이 구조를 머릿속에 넣으면 된다.

6. 레지스터 전송 언어(Register Transfer Language)

복잡한 회로의 동작을 매번 그림으로 그리기 어렵다.

그래서 Register 사이의 데이터 이동과 연산을 간단한 기호로 표현한다.

Register 이름

예를 들어

R1
R2
PC
MAR
AC

등은 Register를 의미한다.

화살표 ←

R2 ← R1

은

R1의 내용을 R2로 전송한다.

라는 뜻이다.

프로그래밍의 대입과 비슷하다.

연산

R3 ← R1 + R2

은

R1과 R2를 더한 결과를 R3에 저장한다.

라는 뜻이다.

콜론 :

다음 표현을 보자.

T1 : R2 ← R1

이는

T1이라는 제어 조건/시점에 R1의 값을 R2에 전달한다.

라는 뜻이다.

즉

조건 : 수행할 Microoperation

형태다.

예시

T3 : AC ← AC + MAR

은

T3 시점에 AC와 MAR의 값을 더해서 그 결과를 AC에 저장한다.

라는 뜻이다.

Chapter 2 전체 흐름

이 장의 내용은 사실 전부 하나로 연결되어 있다.

컴퓨터
  │
  ▼
모든 정보는 0과 1
  │
  ├──────────────────┐
  ▼                  ▼
계산해야 함          기억해야 함
  │                  │
  ▼                  ▼
논리 게이트         Flip-Flop
  │                  │
  ▼                  ▼
조합 논리회로        Register
  │                  │
  │                  ├── Shift Register
  │                  └── Counter
  │
  └─────────┬────────┘
            ▼
           Bus
            │
       ┌────┴────┐
       ▼         ▼
      ABus      BBus
       │         │
       └────┬────┘
            ▼
           ALU
            │
            ▼
       Result Bus
            │
            ▼
         Register

CPU 내부 동작과 연결해서 이해하기

예를 들어 CPU가 다음 동작을 수행한다고 하자.

R3 ← R1 + R2

이 짧은 표현 안에 지금까지 배운 내용이 거의 전부 들어있다.

1단계

R1은 여러 개의 Flip-Flop으로 이루어진 Register다.

R1 = 0011

이라는 값을 기억하고 있다.

2단계

R2 역시 Register다.

R2 = 0101

을 기억하고 있다.

3단계

제어 회로가 R1을 ABus에 출력하도록 한다.

ABus = 0011

4단계

R2를 BBus에 출력한다.

BBus = 0101

5단계

ALU가 두 값을 더한다.

0011 + 0101 = 1000

6단계

ALU 결과가 Result Bus를 통해 R3의 D 입력으로 전달된다.

D3 = 1000

7단계

R3의 Enable을 활성화한다.

8단계

Clock 상승 에지가 발생한다.

Clock ↑

9단계

R3가 D 값을 저장한다.

R3 ← 1000

이제 R3의 Q 출력은

1000

이다.

왜 교수님이 계속 Clock의 상승 에지를 강조하는가?

조합 논리회로와 순차 논리회로의 차이를 생각하면 된다.

ALU 같은 조합 논리회로는 입력이 바뀌면 출력도 바뀐다.

입력 변화
   ↓
ALU 계산
   ↓
출력 변화

반면 Register는 아무 때나 값을 저장하면 안 된다.

D가 바뀜
→ 아직 저장 안 함

D가 또 바뀜
→ 아직 저장 안 함

Clock ↑
→ 바로 이 순간의 D를 저장

즉 Clock을 이용해서

"지금 계산 결과를 확정해서 저장해."

라는 시점을 정해주는 것이다.

그래서 타이밍 다이어그램 문제에서 Clock의 상승 에지가 가장 중요한 기준점이 된다.

⭐ 시험 대비 핵심 정리

1. 진법

반드시 할 수 있어야 한다.

10진수 → 2진수

정수 : 2로 나누고 나머지를 아래에서 위로
소수 : 2를 곱하고 정수 부분을 위에서 아래로

그리고

2진수 3bit ↔ 8진수 1자리
2진수 4bit ↔ 16진수 1자리

를 기억한다.

2. Flip-Flop

Flip-Flop = 1bit 저장

D FF

Clock ↑ → Q ← D

JK FF

J K | 다음 Q
---------------
0 0 | 유지
0 1 | 0
1 0 | 1
1 1 | 반전

T FF

T=0 → 유지
T=1 → 반전

3. Latch와 Flip-Flop

Latch      → Level Sensitive
Flip-Flop  → Edge Sensitive

4. 타이밍 다이어그램

무조건

① Clock 찾기
② 유효 Edge 찾기
③ 그 순간 입력 확인
④ 동작표 적용
⑤ Q 결정
⑥ 다음 Edge까지 Q 유지

순서로 푼다.

5. Register

Flip-Flop 여러 개
        ↓
     Register

4bit Register라면 기본적으로 4개의 1bit 저장 요소가 필요하다.

6. Register 제어 신호

/Clear=0
→ 즉시 초기화

/Clear=1, Enable=0
→ 유지

/Clear=1, Enable=1, Clock ↑
→ Q ← D

7. Shift Register

Clock ↑
→ bit가 한 칸 이동

직렬 입력을 받아 여러 Q를 통해 병렬 데이터로 사용할 수 있다.

8. Counter

0000
0001
0010
0011
...
1111
0000

처럼 정해진 상태를 반복한다.

9. Register Transfer

R2 ← R1

은

R1의 데이터를 R2에 복사

한다는 뜻이다.

10. Bus

Bus = 여러 Register가 공유하는 데이터 통로

가장 중요한 규칙:

한 순간에는 하나의 Source만 Bus를 구동해야 한다.

11. High Impedance

Z = High Impedance

는

Bus에 연결되어 있지만 현재는 Bus를 구동하지 않는 상태

라고 이해한다.

12. ABus와 BBus

ALU가 두 개의 입력을 필요로 하기 때문에 존재한다.

Register A → ABus ─┐
                   ▼
                  ALU → Result
                   ▲
Register B → BBus ─┘

⭐ 이 장에서 가장 중요한 사고방식

자료의 파형 그림이 나오면 전체를 한 번에 해석하려고 하지 않는다.

예를 들어 다음 신호들이 있다고 하자.

Clear
Enable
Clock
D
Q

반드시 다음 순서로 본다.

1. Clear가 작동하고 있는가?

   YES → Q 초기화
   NO  → 다음으로

2. Enable이 활성화되어 있는가?

   NO  → Q 유지
   YES → 다음으로

3. Clock의 유효 Edge인가?

   NO  → Q 유지
   YES → D 확인

4. 그 순간 D가 무엇인가?

   Q ← D

5. 다음 유효 Edge까지 Q 유지

JK Flip-Flop도 똑같다.

1. Clock ↑를 찾는다.
2. 그 순간 J와 K를 읽는다.
3. JK 표를 적용한다.
4. Q를 결정한다.
5. 다음 ↑까지 유지한다.

Register 전송도 똑같다.

1. Source Register는 누구인가?
2. Bus에 어떤 값이 올라왔는가?
3. Destination Register는 누구인가?
4. Destination Enable이 켜져 있는가?
5. Clock ↑인가?
6. 그렇다면 Destination에 저장

Bus 연산도 똑같다.

1. ABus에는 누가 올라왔는가?
2. BBus에는 누가 올라왔는가?
3. ALU가 무슨 연산을 하는가?
4. 결과는 무엇인가?
5. 어느 Register가 결과를 받을 것인가?
6. Clock ↑에서 저장

결국 Chapter 2 후반부의 그림은 전부

"어떤 데이터가 어디에 있고 → 어떤 제어 신호가 활성화되고 → Clock의 어느 순간에 → 어디로 저장되는가?"

를 읽는 문제라고 생각하면 된다.

컴퓨터 구조론 첫 수업을 들으면서 가장 먼저 든 생각은 단순했다.

그래서 컴퓨터 구조에서는 대체 뭘 배우는 걸까?

나는 지금까지 Java나 C++로 프로그램을 만들면서도 컴퓨터 내부에서 실제로 무슨 일이 일어나는지는 크게 신경 쓰지 않았다.

예를 들어 C++에서

int a = 10;
int b = 20;

cout << a + b;

라고 작성하면 당연히 30이 출력된다.

그런데 생각해보면 컴퓨터가 int라는 글자를 이해하는 것도 아니고, +를 보고 우리가 생각하는 덧셈의 의미를 이해하는 것도 아니다.

결국 우리가 작성한 프로그램은 컴퓨터가 실제로 실행할 수 있는 형태로 바뀌어야 한다.

그래서 이번에는 조금 더 아래로 내려가 보기로 했다.

내가 작성한 프로그램
        ↓
고급 프로그래밍 언어
        ↓
어셈블리어
        ↓
기계어
        ↓
CPU가 명령어 실행
        ↓
논리회로
        ↓
트랜지스터
        ↓
전기 신호

컴퓨터 구조론은 이 중 소프트웨어와 실제 하드웨어가 만나는 지점을 이해하는 과목이라고 볼 수 있었다.

컴퓨터는 무엇일까?

너무 당연한 질문 같지만 교재에서는 컴퓨터를 두 가지 관점으로 설명한다.

컴퓨터

= 계산을 수행하는 기계
+
프로그램을 실행하는 기계

계산기와 컴퓨터의 차이를 생각해보면 조금 이해하기 쉽다.

계산기도

10 + 20 = 30

과 같은 계산을 수행한다.

하지만 컴퓨터는 단순히 하나의 계산만 수행하는 것이 아니라 프로그램에 적혀 있는 명령들을 순서대로 실행한다.

그렇다면 프로그램은 무엇일까?

프로그램은 명령어의 모음이다

프로그램은

명령어들이 의미 있는 순서대로 나열된 것

이다.

영어로 표현하면

sequence of instructions

이다.

그리고 명령어(Instruction)는 프로그래머가 컴퓨터에게 실행하도록 지시할 수 있는 기본적인 작업 단위다.

예를 들어 굉장히 단순화하면

메모리에서 값을 가져와라.
두 값을 더해라.
결과를 저장해라.

같은 작업들이 명령어가 될 수 있다.

우리가 보는 프로그램은

int result = a + b;

한 줄이지만 컴퓨터 입장에서는 이를 더 작은 명령어들로 나누어 처리해야 한다.

a를 가져온다
      ↓
b를 가져온다
      ↓
두 값을 더한다
      ↓
result에 저장한다

즉 프로그램은 결국 CPU가 실행할 수 있는 명령어의 흐름이라고 볼 수 있다.

컴퓨터를 한 층씩 내려가 보면?

교재에서는 컴퓨터를 계층적으로 바라본다.

처음에는

컴퓨터 구조인데 그냥 CPU랑 RAM 배우는 거 아닌가?

라고 생각했는데 실제로는 여러 계층이 연결되어 있다.

대략 다음처럼 생각할 수 있다.

고급언어 프로그램
        ↓
어셈블리 프로그램
        ↓
프로그래머 모델
        ↓
컴퓨터 조직
        ↓
논리회로
        ↓
반도체 기술

위쪽으로 갈수록 프로그래머가 보는 세계에 가깝고, 아래쪽으로 내려갈수록 실제 하드웨어에 가까워진다.

예를 들어 나는 Java에서

int a = 10;

이라고 작성한다.

하지만 더 아래로 내려가면 CPU는 Java의 int를 직접 실행하지 않는다.

결국 CPU가 이해할 수 있는 명령어가 필요하고, 그 명령어를 실제로 수행하는 회로가 필요하며, 그 회로는 다시 트랜지스터로 만들어진다.

결국 컴퓨터의 가장 아래에는 스위치가 있다

반도체 기술에서는 트랜지스터(Transistor)라는 전기적으로 동작하는 스위칭 소자를 제공한다.

쉽게 생각하면 아주 작은 스위치다.

OFF
→ 전기 신호 없음

ON
→ 전기 신호 있음

이렇게 두 가지 상태를 표현할 수 있다.

그런데 컴퓨터에서는 이를

OFF → 0
ON  → 1

처럼 논리적인 값으로 바꿔 생각한다.

여기서 중요한 것은 실제 전압값 자체보다

이 전압을 0으로 볼 것인가?
1로 볼 것인가?

라는 논리적인 해석이다.

트랜지스터를 조합하면 논리 게이트를 만들 수 있고,

Transistor
    ↓
Logic Gate
    ↓
Logic Circuit
    ↓
Register / ALU ...
    ↓
CPU

처럼 점점 복잡한 컴퓨터를 만들 수 있다.

그래서 다음 Chapter에서 갑자기 0, 1, AND, OR 같은 논리회로를 배우는 것이 아니었다.

컴퓨터가 실제로 동작하는 가장 아래쪽 원리를 이해하기 위한 과정이었다.

전자회로와 논리회로는 무엇이 다를까?

처음에는 둘 다 전기 회로인데 굳이 왜 나누는지 헷갈렸다.

전자회로에서는 실제 전기적 특성을 생각해야 한다.

전압
전류
저항
트랜지스터의 특성

같은 것들이다.

하지만 컴퓨터 구조에서 매번

현재 전압이 몇 V이고,
전류가 몇 A이고...

를 계산한다면 너무 복잡해진다.

그래서 이를 논리적인 세계로 추상화한다.

실제 전압
   ↓
0 또는 1
   ↓
논리 연산

예를 들어 두 입력이 모두 1일 때만 출력이 1이 되는 회로가 있다면 전자회로의 세부 구조 대신

A B | Y
---------
0 0 | 0
0 1 | 0
1 0 | 0
1 1 | 1

이라고 표현할 수 있다.

이게 바로 AND 게이트다.

즉 컴퓨터 구조에서는 실제 전자회로의 복잡함을 어느 정도 숨기고 0과 1의 논리 세계로 추상화해서 바라보는 것이다.

컴퓨터 구조는 어디까지 다룰까?

교재에서는 컴퓨터 구조의 영역을 크게 다음과 같이 나눈다.

1. 이진수 체계 및 논리회로
2. 컴퓨터 조직
3. 프로그래머 모델

먼저 이진수 체계와 논리회로에서는

0과 1
부울 대수
논리 게이트
조합 논리회로
순차 논리회로

등을 배운다.

그다음 컴퓨터 조직(Computer Organization)에서는

CPU
Memory
I/O Device
System Bus

같은 실제 컴퓨터 구성 요소를 본다.

마지막으로 Programmer Model은 이 컴퓨터 구조 중에서도 프로그래머가 프로그램을 작성하기 위해 알아야 하는 부분이다.

예를 들면

Instruction Set
Register
Memory Organization

등이 있다.

Instruction Set은 무엇일까?

CPU가 프로그램을 실행하려면 명령어를 이해할 수 있어야 한다.

그런데 CPU가 아무 명령어나 이해하는 것은 아니다.

CPU마다 실행할 수 있도록 정의된 명령어들의 집합이 있다.

이것이 Instruction Set, 즉 명령어 집합이다.

예를 들어 개념적으로

LOAD
ADD
SUB
STORE

같은 명령어들이 있을 수 있다.

LOAD  → 값을 가져온다
ADD   → 더한다
SUB   → 뺀다
STORE → 저장한다

그리고 이러한 명령어는 결국 CPU가 실제로 해석할 수 있는 이진수 코드로 표현된다.

이것이 기계어(Machine Instruction / Machine Code)다.

여기서 중요한 점은 Instruction Set이

하드웨어와 소프트웨어 사이의 인터페이스

역할을 한다는 것이다.

Software
   ↓
Instruction Set
   ↓
Hardware

프로그래머나 컴파일러는 CPU가 어떤 명령을 지원하는지를 알아야 하고, CPU는 약속된 명령어를 실제 회로를 통해 수행한다.

기계어를 사람이 직접 작성하면 안 될까?

가능은 하다.

문제는 사람이 읽기 너무 어렵다는 것이다.

예를 들어

0010000110000000

같은 코드만 보고

아, 이건 어떤 값을 레지스터로 가져오는 명령이구나.

라고 바로 알아보기는 어렵다.

그래서 사람이 조금 더 이해하기 쉬운 기호를 붙였다.

LOAD
ADD
MOV
SUB

같은 것이다.

이것이 Assembly Language다.

예를 들어

ADD R1, R2

처럼 작성하면 이진수 기계어보다 훨씬 이해하기 쉽다.

하지만 어셈블리어도 여전히 CPU 구조에 크게 의존한다.

그래서 더 높은 수준의 언어가 등장한다.

C
C++
Java

같은 고급 프로그래밍 언어다.

우리가 작성한 코드는 어떻게 CPU까지 내려갈까?

대략적인 흐름을 생각하면 다음과 같다.

C / Java 등의 고급 언어
          ↓
       Compiler
          ↓
Assembly / Machine Code
          ↓
         CPU

교재에서는 고급 언어를 기계 독립적인 관점으로, 어셈블리 언어를 기계 의존적인 언어로 설명한다.

물론 실제 언어 구현과 실행 환경은 더 복잡하지만, 컴퓨터 구조의 관점에서는

사람이 이해하기 쉬운 표현
        ↓
컴퓨터가 이해할 수 있는 표현

으로 내려간다고 이해하면 된다.

컴파일러 수업에서 배웠던 내용이 여기서 다시 연결됐다.

컴파일러에서는

소스 코드가 어떻게 기계어로 번역되는가?

를 중심으로 봤다면,

컴퓨터 구조에서는 한 단계 더 내려가

그 기계어를 하드웨어는 어떻게 실행하는가?

를 보게 되는 셈이다.

프로그램은 어디에 저장될까?

여기서 폰 노이만 구조(Von Neumann Architecture)가 등장한다.

핵심 아이디어는 생각보다 간단하다.

프로그램과 데이터를 기억장치에 함께 저장한다.

그리고 CPU가 기억장치에서 명령어를 하나씩 가져와 실행한다.

Memory

[Instruction]
[Instruction]
[Data]
[Data]

      ↓

     CPU

이를 Stored Program Concept, 즉 프로그램 내장 구조라고 한다.

실행 과정도 단순하게 생각하면

Memory에서 명령어 가져오기
          ↓
명령어 해석하기
          ↓
명령어 실행하기
          ↓
다음 명령어 가져오기
          ↓
...

가 된다.

나중에 배우게 될

Fetch
Decode
Execute

가 여기에서 이어진다.

컴퓨터는 크게 세 부분으로 볼 수 있다

교재에서는 컴퓨터의 기본 구성 요소를 다음과 같이 나눈다.

          ┌───────────┐
          │    CPU    │
          └───────────┘
                ↕
          System Bus
        ↙             ↘
   ┌────────┐      ┌──────────┐
   │ Memory │      │ I/O      │
   └────────┘      │ Device   │
                   └──────────┘

즉

CPU
Memory
I/O Device

이다.

CPU

프로그램의 명령어를 실제로 실행한다.

Memory

프로그램과 데이터를 저장한다.

I/O Device

컴퓨터와 외부 세계를 연결한다.

Keyboard
Mouse
Monitor
Disk
Network

등이 여기에 해당한다.

그리고 이 구성 요소들이 데이터를 주고받는 통로가 System Bus다.

System Bus는 컴퓨터 안의 도로와 비슷하다

CPU, Memory, I/O Device가 각각 존재하기만 해서는 아무 일도 할 수 없다.

서로 정보를 주고받아야 한다.

그래서 Bus가 필요하다.

나는 버스를 컴퓨터 내부의 도로처럼 생각하니 이해하기 편했다.

CPU ───────── Memory
 │
 │ System Bus
 │
 └─────────── I/O

CPU가

메모리의 어떤 위치에 있는 데이터를 가져와라.

라고 요청하면 주소와 데이터, 제어 정보가 버스를 통해 이동한다.

뒤에서 구체적으로

Address Bus
Data Bus
Control Bus

로 나누어 배우게 된다.

컴퓨터는 어떻게 발전했을까?

컴퓨터의 발전 과정도 결국 어떤 소자를 사용했는가와 밀접하게 연결되어 있다.

초기에는 기계적인 장치를 사용했고 이후에는

진공관
  ↓
트랜지스터
  ↓
IC
  ↓
LSI
  ↓
더 높은 집적도의 반도체

로 발전했다.

하나의 칩에 더 많은 트랜지스터를 넣을 수 있게 되면서 컴퓨터의 성능도 빠르게 증가했다.

여기에서 무어의 법칙(Moore's Law)도 등장한다.

핵심은 반도체 칩에 집적되는 트랜지스터의 수가 시간이 흐르면서 빠르게 증가해왔다는 관찰이다.

결국 현대의 작은 CPU 하나에 엄청나게 많은 트랜지스터를 넣을 수 있게 되었고, 우리가 사용하는 복잡한 프로그램도 빠르게 처리할 수 있게 된 것이다.

그런데 왜 컴퓨터는 0과 1을 사용할까?

Chapter 1을 보고 나면 자연스럽게 다음 질문이 생긴다.

왜 하필 컴퓨터는 0과 1을 사용할까?

컴퓨터의 가장 아래에는 전기적으로 동작하는 스위칭 소자가 있다.

스위치는

ON
OFF

처럼 두 상태를 구분하기 쉽다.

이를 논리적인 값으로 바꾸면

ON  → 1
OFF → 0

처럼 표현할 수 있다.

그래서 컴퓨터에서는 이진수가 자연스럽게 등장한다.

하지만 여기서 또 문제가 생긴다.

우리는 평소

10
27
1000

처럼 10진수를 사용한다.

그런데 컴퓨터는 내부에서

1010
11011
1111101000

같은 2진수를 사용한다.

그렇다면

27은 왜 11011이 되는가?

2진수와 16진수는 어떤 관계가 있는가?

컴퓨터는 1111을 보면 정말 숫자 15라고 생각하는가?

문자 A는 컴퓨터 안에서 어떻게 저장되는가?

라는 질문이 생긴다.

그리고 이 질문들이 그대로 다음 Chapter의 내용으로 이어진다.

Chapter 2에서는 컴퓨터가 정보를 표현하는 가장 기본적인 방법인 수와 코드, 그리고 그 0과 1을 실제로 처리하고 기억하는 논리회로를 알아보려고 한다.

지난 Chapter에서는 컴파일러가 소스 프로그램을 한 번에 기계어로 바꾸는 것이 아니라 여러 단계를 거쳐 번역한다는 것을 알아봤다.

특히 앞부분에서는 다음과 같은 과정이 이루어진다.

Source Program
      ↓
Scanner
      ↓
Token
      ↓
Parser
      ↓
문법 구조 확인

Scanner는 소스 프로그램을 읽으면서 Token을 찾아내고, Parser는 그렇게 만들어진 Token들이 프로그래밍 언어의 문법에 맞게 작성되었는지를 확인한다.

그런데 여기서 생각해보니 조금 이상했다.

컴퓨터는 도대체 무엇을 보고 "이 프로그램은 문법에 맞다"고 판단할까?

나는 Java 코드를 보면 대충 알 수 있다.

int number = 10;

이건 맞는 것 같고,

int = number 10;

이건 뭔가 이상하다.

사람은 Java 문법을 배웠기 때문에 자연스럽게 판단할 수 있지만 컴퓨터에게

이건 딱 봐도 이상하잖아.

라고 할 수는 없다.

결국 컴파일러가 프로그래밍 언어를 처리하려면 언어 자체를 명확하게 정의할 방법이 필요하다.

이번 Chapter에서 배우는 형식 언어(Formal Language)가 바로 그 출발점이었다.

언어를 정의하려면 먼저 기호부터 정의해야 한다

형식 언어에서 가장 먼저 등장하는 것은 알파벳(Alphabet)이다.

처음에는 영어의 a, b, c ...를 말하는 줄 알았는데 여기서 알파벳의 의미는 조금 다르다.

알파벳은 기호(Symbol)들의 유한 집합이다.

보통 T와 같은 기호로 표현한다.

예를 들어 다음과 같은 것들이 알파벳이 될 수 있다.

T₁ = {a, b, c, ..., z}

T₂ = {0, 1}

T₃ = {auto, break, case, ..., while}

즉 꼭 문자 하나만 알파벳의 원소가 되는 것은 아니다.

프로그래밍 언어의 예약어처럼

auto
break
case
while

같은 것도 하나의 기호로 생각할 수 있다.

이 기호들을 이용해서 문자열(String)을 만들 수 있다.

문자열은 알파벳에 있는 기호를 나열한 것이다

문자열은 어떤 알파벳에 속하는 기호들을 유한하게 나열한 것이다.

예를 들어

T = {a, b}

라면

a
b
ab
ba
aab
abba

같은 문자열을 만들 수 있다.

문자열 w의 길이는 보통

|w|

로 나타낸다.

예를 들어

w = abba

|w| = 4

가 된다.

여기서 특별한 문자열이 하나 등장한다.

바로 공문자열(Empty String)이다.

ε

또는 교재에서는 λ(lambda)로도 표현한다.

공문자열은 아무 기호도 가지지 않기 때문에 길이가 0이다.

|ε| = 0

처음에는

아무것도 없는데 이것도 문자열이라고?

싶었는데 뒤에서 문자열과 언어의 연산을 정의할 때 계속 필요해진다.

숫자에서 0이 필요한 것처럼 문자열에서도 길이가 0인 문자열을 하나의 대상으로 정의해두는 것이다.

문자열을 서로 붙일 수도 있다

문자열에는 접합(Concatenation)이라는 연산이 있다.

두 문자열을 순서대로 이어 붙이는 것이다.

예를 들어

u = ab
v = ba

라면

uv = abba

가 된다.

반대로 순서를 바꾸면

vu = baab

가 된다.

따라서 일반적으로

uv ≠ vu

이다.

숫자의 덧셈처럼 순서를 바꿔도 같은 연산이 아니었다.

문자열에서는 어떤 순서로 연결했는지 자체가 의미를 가지기 때문이다.

Prefix와 Suffix는 무엇일까?

문자열의 일부를 이야기할 때 Prefix와 Suffix라는 개념도 사용한다.

예를 들어

w = abc

라고 해보자.

w = uv를 만족한다면 u는 w의 Prefix, v는 w의 Suffix가 된다.

예를 들어

w = abc

u = ab
v = c

라면

uv = abc

이므로

ab = prefix
c  = suffix

라고 할 수 있다.

문자열을 단순히 하나의 덩어리로 보는 것이 아니라 앞부분과 뒷부분을 나눠서 생각할 수 있는 것이다.

같은 문자열을 여러 번 반복하면 어떻게 표현할까?

문자열을 반복해서 연결하는 것도 표현할 수 있다.

예를 들어

w = ab

라면

w⁰ = ε
w¹ = ab
w² = abab
w³ = ababab

가 된다.

일반적으로

wⁿ

은 문자열 w를 n번 접합한 것을 의미한다.

이런 표기법을 이용하면 이후에 언어를 훨씬 간단하게 표현할 수 있다.

예를 들어

a
aa
aaa
aaaa
...

를 하나씩 모두 적지 않고

aⁿ

처럼 표현할 수 있다.

알파벳으로 만들 수 있는 모든 문자열을 모으면?

이제 알파벳 T를 가지고 만들 수 있는 문자열 전체를 생각해볼 수 있다.

먼저

T⁰ = {ε}

이다.

T¹은 알파벳의 기호 하나로 만들어지는 문자열이다.

T = {0, 1}

T¹ = {0, 1}

T²는 두 개의 기호로 만들 수 있는 모든 문자열이다.

T² = {
    00,
    01,
    10,
    11
}

T³라면

000
001
010
011
100
101
110
111

처럼 길이가 3인 모든 문자열이 된다.

그리고 이들을 전부 합친 것을

T*

로 나타낸다.

T* = T⁰ ∪ T¹ ∪ T² ∪ T³ ∪ ...

이것을 Kleene Closure라고 한다.

따라서

T = {0, 1}

이라면

T* = {
    ε,
    0, 1,
    00, 01, 10, 11,
    000, 001, 010, ...
}

가 된다.

즉 알파벳 T를 이용해 만들 수 있는 모든 유한 길이의 문자열 집합이다.

ε을 제외하고 싶다면 T+를 사용한다

T*에는 ε도 포함된다.

그런데 길이가 1 이상인 문자열만 필요할 수도 있다.

이때는

T+

를 사용한다.

T+ = T¹ ∪ T² ∪ T³ ∪ ...

따라서 관계를 보면

T+ = T* - {ε}

라고 할 수 있다.

정리하면

T*
→ 길이 0 이상
→ ε 포함

T+
→ 길이 1 이상
→ ε 제외

이다.

*와 +는 이후 정규 표현에서도 다시 만나게 되기 때문에 여기서 의미를 확실하게 알아두는 것이 중요해 보였다.

이제 언어를 정의할 수 있다

알파벳과 문자열을 정의했으니 이제 언어(Language)를 정의할 수 있다.

형식 언어에서 언어는

알파벳 T에 대한 T*의 부분집합이다.

즉

L ⊆ T*

이다.

처음에는 언어라고 하면 Java, C++, Python 같은 것부터 떠올랐다.

그런데 형식 언어에서는 훨씬 수학적으로 바라본다.

예를 들어

T = {a, b}

라고 해보자.

T*에는

ε
a
b
aa
ab
ba
bb
aaa
aab
...

처럼 만들 수 있는 모든 문자열이 들어 있다.

그중에서 특정한 조건을 만족하는 문자열만 골라

L = {a, aa, aaa, aaaa, ...}

라고 정의했다면 이것도 하나의 언어다.

즉

모든 가능한 문자열 T*
          ↓
특정 규칙을 만족하는 문자열 선택
          ↓
Language L

이라고 생각할 수 있다.

유한 언어와 무한 언어

언어에 포함되는 문자열의 개수에 따라 유한 언어(Finite Language)와 무한 언어(Infinite Language)로도 나눌 수 있다.

예를 들어

L = {a, ab, ba}

처럼 원소의 개수가 정해져 있다면 유한 언어다.

반면

L = {aⁿ | n ≥ 1}

이라면

a
aa
aaa
aaaa
...

가 끝없이 만들어지므로 무한 언어다.

프로그래밍 언어를 생각해보면 작성할 수 있는 프로그램의 길이를 하나로 제한하지 않기 때문에 사실상 무한한 문자열 집합을 다루게 된다.

언어끼리도 연산할 수 있다

문자열을 접합할 수 있었던 것처럼 언어끼리도 곱(Product)을 정의할 수 있다.

두 언어 L₁, L₂가 있다면

L₁L₂ = {uv | u ∈ L₁, v ∈ L₂}

로 정의한다.

즉 L₁의 문자열 하나와 L₂의 문자열 하나를 가져와 접합해서 새로운 언어를 만드는 것이다.

예를 들어

L₁ = {a, b}
L₂ = {c, d}

라면

L₁L₂ = {
    ac,
    ad,
    bc,
    bd
}

가 된다.

처음에는 문자열에만 접합이 있는 줄 알았는데 결국 언어도 문자열의 집합이기 때문에 집합 안의 문자열들을 이용해 새로운 언어를 만들 수 있었다.

언어도 거듭제곱할 수 있다

문자열에서 wⁿ을 정의했던 것처럼 언어에서도 거듭제곱을 정의할 수 있다.

L⁰ = {ε}

이고,

Lⁿ = LLⁿ⁻¹

로 정의할 수 있다.

예를 들어

L = {a, b}

라면

L² = {
    aa,
    ab,
    ba,
    bb
}

가 된다.

그리고 이를 이용하면 언어에 대해서도 *와 +를 정의할 수 있다.

언어의 Kleene Closure와 Positive Closure

언어 L에 대해

L* = L⁰ ∪ L¹ ∪ L² ∪ ...

를 Kleene Closure라고 한다.

반면

L+ = L¹ ∪ L² ∪ L³ ∪ ...

를 생각할 수 있다.

따라서 역시

L* = L+ ∪ {ε}

관계가 성립한다.

문자열에서 봤던 *, +가 언어에서도 거의 같은 의미로 확장된 것이다.

여기까지 오니 처음에는 따로따로 보였던

Alphabet
String
Language

가 사실 계속 같은 방식으로 확장되고 있다는 느낌이 들었다.

Alphabet
   ↓
Symbol로 String 생성
   ↓
String들의 집합 = Language
   ↓
Language에도 접합과 Closure 적용

그런데 언어의 문자열을 전부 적어둘 수는 없다

여기까지 언어를

L = { ... }

형태로 정의했다.

그런데 무한 언어라면 문제가 생긴다.

예를 들어

L = {
    a,
    aa,
    aaa,
    aaaa,
    ...
}

처럼 생략해서 표현할 수는 있지만 컴파일러가 처리할 프로그래밍 언어를 이런 식으로 전부 나열할 수는 없다.

Java 프로그램으로 만들 수 있는 모든 문자열을 하나씩 적는다는 것은 불가능하다.

그래서 필요한 것이 문법(Grammar)이다.

문법은 언어를 생성하는 규칙이다

교재에서는 언어를 크게 두 가지 방법으로 정의할 수 있다고 설명한다.

하나는 지금까지처럼

어떤 문자열이 언어에 포함되는지

를 직접 정의하는 방법이다.

다른 하나는

어떤 규칙을 적용하면 그 문자열을 만들 수 있는지

를 정의하는 것이다.

후자가 바로 문법(Grammar)이다.

즉

Grammar
   ↓
규칙 적용
   ↓
String 생성
   ↓
생성 가능한 String들의 집합
   ↓
Language

가 된다.

문법은 4개의 요소로 구성된다

문법 G는 다음과 같이 표현한다.

G = (Vₙ, Vₜ, P, S)

처음 보면 갑자기 기호가 많이 등장해서 어려워 보이는데 하나씩 보면 의미가 명확하다.

Vₙ : Nonterminal Symbol의 유한 집합

Vₜ : Terminal Symbol의 유한 집합

P  : Production Rule의 유한 집합

S  : Start Symbol

그리고

Vₙ ∩ Vₜ = ∅

이다.

즉 Nonterminal과 Terminal은 서로 겹치지 않는다.

또

V = Vₙ ∪ Vₜ

를 문법의 Vocabulary라고 한다.

Terminal과 Nonterminal은 무엇이 다를까?

Terminal Symbol은 최종적으로 만들어진 문자열에 남는 기호다.

반면 Nonterminal Symbol은 문자열을 만드는 과정에서 다른 기호로 바뀌는 기호다.

예를 들어 다음과 같은 생성 규칙이 있다고 해보자.

S → a
S → aS

여기서

S

는 Nonterminal이고

a

는 Terminal이다.

실제로 생성해보면

S
⇒ aS
⇒ aaS
⇒ aaaS
⇒ aaaa

처럼 마지막에는 S가 사라지고 Terminal인 a만 남는다.

그래서 나는 다음처럼 이해하는 것이 편했다.

Nonterminal
→ 아직 생성 과정에 있는 문법 기호

Terminal
→ 더 이상 변하지 않고 최종 문자열에 남는 기호

생성 규칙 Production Rule

P는 생성 규칙(Production Rule)들의 유한 집합이다.

보통

α → β

처럼 표현한다.

왼쪽에 있는 문자열을 오른쪽 문자열로 바꿀 수 있다는 의미다.

예를 들어

S → a
S → aS

가 있다면 S를 a로 바꿀 수도 있고 aS로 바꿀 수도 있다.

여러 규칙의 왼쪽이 같다면

S → a
S → aS

를

S → a | aS

처럼 줄여서 표현할 수도 있다.

여기서 |는

또는

의 의미다.

시작 기호가 필요한 이유

문법에는 여러 Nonterminal이 있을 수 있다.

그러면 문자열을 어디에서부터 만들어야 할지 정해야 한다.

그래서 시작 기호(Start Symbol)가 존재한다.

보통

S

를 사용한다.

예를 들어

G = ({S}, {a, b}, P, S)