PiLove

[영상처리] Compression

PiLove — Fri, 22 May 2026 21:46:18 +0900

이미지는 기본적으로 용량이 크다. 예를 들어, 흑백 이미지가 1024 x 1024이고, 픽셀당 8 bit이라면, 1024 x 1024 x 8bits 정도의 데이터가 필요하다. 컬러 이미지라면 RGB 3채널이므로 3배의 크기가 필요하다. 그래서 이미지를 저장하거나 전송할 때 압축이 필요하다. 압축에는 두 가지의 종류가 있다.

무손실 압축(Lossless compression) : Huffman, Run-length
손실 압축(Lossy compression) : JPEG

무손실 압축과 손실 압축의 차이는 말 그대로 압축하는 과정에서 정보의 손실이 있느냐 없느냐로 구분할 수 있다.

Lossless compression

Huffman coding

Huffman coding의 핵심은 간단하다. 자주 나오는 값에는 짧은 비트열을 주고, 드물게 나오는 값에는 긴 비트열을 준다. 예를 들어, 어떤 이미지에서 gray value가 다음 확률로 나온다고 가정하자.

Fixed code라면 값이 4개니까 각각 2bit가 필요하다. 반면, Variable code를 사용한다면, 자주 나올 확률이 높은 gray value에 대하여 짧은 비트열인 1을 할당함으로써 평균 bit 수를 줄일 수 있다.

이렇게 bit 수를 줄임으로써 얼마나 압축이 가능할까? 이를 확인하기 위해 Entropy 라는 개념이 나온다. Entropy는 쉽게 말해 무손실로 압축할 때 이론적으로 필요한 최소 평균 bit 수를 의미한다.

여기서 p_i는 값 gray value가 등장할 확률을 의미한다. 각 gray value의 확률이 0.2, 0.4, 0.3, 0.1이라고 가정했을 때, Entropy는 다음과 같이 계산된다.

즉, 아무리 압축을 잘해도 평균적으로 약 1.8464 bit/pixel 보다 더 낮추기는 어렵다는 의미이다.

그래서 huffman coding은 어떻게 진행되는가 알아보자. 우선 무작정 자주 나오는 값에 짧은 코드를 아무렇게나 주면 안된다. 왜냐하면 복원이 안될 수 있기 때문이다. A라는 값에 대해 코드 1을 주고 B라는 값에 대해 코드 10을 주고, C라는 값에 대해 코드 11을 주었다고 가정하자. 이 경우 압축된 비트열이 11이면 이 코드가 C인지 AA인지 알아보기 어렵다. 따라서 짧은 code를 주되, 복원할 때 헷갈리지 않은 code 체계를 만들어야 한다. 그래서 필요한 조건이 prefix-free code이다.

Prefix-free code란, 어떤 code도 다른 code의 앞부분이 되지 않는 코드 체계를 의미한다. 그럼 짧은 code와 긴 code를 적절히 배치하면서, 동시에 복원 가능한 prefix-free code를 어떻게 만들까? 이에 대한 답이 바로 Huffman tree이다.

Huffman tree는 다음 두 가지를 동시에 만족시키기 위해 등장한다.

자주 나오는 값은 짧은 code를 갖게 한다.
전체 code가 prefix-free가 되도록 만든다.

Huffman tree를 만드는 과정은 다음과 같다.

이미지의 각 gray value 확률을 구한다.
확률이 가장 작은 두 개를 묶는다.
묶은 값을 다시 하나의 노드로 보고 또 가장 작은 두 개를 묶는다.
전체 확률이 1이 될 때까지 위 과정(3)을 반복한다.
트리의 가지에 0과 1을 붙인다.
root에서 leaf까지 내려가며 codeword를 읽는다.

Run-length Encoding, RLE

Run-length Encoding은 같은 값이 연속되는 구간을 반복 횟수로 표현한다. 예를 들어, 0000011111000 이 있으면, 이는 "5,5,3" 처럼 표현할 수 있다. 이 방식은 특히 값이 0과 1뿐인 binary image에서 좋다. 그러나 일반적인 이미지에서는 사용하기 어렵다. 예시로, 128 129 130 128 131 128 130 ... 이런식으로 사람 눈으로 구분하기 어려운 픽셀값에 대해서 RLE로 표현하면 "(128, 1), (129, 1), (130, 1), (128, 1), (131, 1), (128, 1), (130, 1)" 이런 식으로 오히려 데이터가 더 커질 수 있기 때문이다.

Lossy compression

JPEG

무손실 압축으로는 충분히 줄이기 어렵다. 따라서 손실 압축을 사용하게 되는데, 손실 압축의 배경은 다음과 같다. 우선 사람의 눈은 모든 정보를 똑같이 민감하게 보지 않는다. 예를 들어 전체적인 밝기 변화나 큰 구조는 잘 느끼지만, 아주 미세한 고주파 질감 변화에는 상대적으로 둔감하다.

고주파 얘기가 나와서 주파수 영역에 대해 간단하게 소개하자면, 이미지를 바라보는 관점이 공간 영역에서 픽셀값의 변화량의 영역으로 바꾼 것이다. 즉, 이미지를 바라볼 때 픽셀값으로 이미지를 바라보는 것이 아닌 인접한 픽셀값들 사이의 차이, 즉 변화량으로 이미지를 바라보는 것이며, "미세한 고주파 질감 변화" 는 인접한 두 픽셀 사이의 변화량이 큰 픽셀의 관계를 말한다.

아무튼 다시 본론으로 돌아와서 사람이 잘 못 느끼는 세부 정보는 줄이고, 중요한 구조는 보존하면 용량을 훨씬 줄일 수 있지 않을까? 가 손실 압축인 JPEG의 출발점이다.

그런데 어떤 정보가 중요하고 덜 중요한지 어떻게 알 수 있을까?

이미지는 픽셀 값으로 저장되어 있다. 픽셀 값 그대로 보면 어떤 값이 중요한지 판단하기 어렵다. 따라서 이미지를 바라보는 관점을 주파수 영역으로 바꾼다. 이때 사용하는 변환이 바로 DCT이다.

DCT로 변환한 이후에는 Quantization을 해준다. 압축 과정을 대략적으로 표현하면 다음과 같다.

이미지를 작은 block으로 나눈다.
각 block에 DCT를 적용한다.
Quantization을 한다.
Zigzag scanning을 한다.
Entropy coding을 한다.

복원 과정은 다음과 같다.

Entropy decoding
Inverse quantization
Inverse DCT
Block들을 다시 합침

DCT

DCT는 이미지를 여러 주파수 서분으로 나누는 역할을 한다. 쉽게 말하면 8x8 block 하나를 다음과 같은 성분들의 조합으로 표현하는 것이다.

전체적으로 밝은 정도
천천히 변하는 성분
빠르게 변하는 성분
세밀한 경계나 질감

같은 성분들의 조합으로 표현된다. 수식은 다음과 같다. 참고로, DCT는 이미지 block을 여러 cosine basis 패턴의 조합으로 표현하는 변환이다. JPEG에서는 0~255 범위의 픽셀값을 그대로 DCT에 넣기보다, 각 값에서 128을 빼서 -128~127 정도의 0 중심 데이터로 이동시킨 뒤 DCT를 적용한다. 이렇게 하면 block의 평균 밝기 성분이 한쪽으로 크게 치우치는 것을 줄이고, 밝기 변화 성분을 더 다루기 좋은 형태로 변환할 수 있다.

4x4 block을 주파수 영역으로 변환했다고 하자. 각 자리는 다음과 같이 해석할 수 있다.

F(0, 0) : 전체 평균 밝기 성분
F(1, 0) : x방향으로 천천히 변하는 성분
F(0, 1) : y방향으로 천천히 변하는 성분
F(3, 3) : x, y 방향으로 빠르게 변하는 고주파 성분

일반적으로 DCT의 결과에서 왼쪽 위는 저주파 성분, 오른쪽 아래는 고주파 성분으로 해석한다. 즉, F(0, 0) 근처는 이미지의 큰 구조를 담고 F(3, 3) 근처는 세밀한 변화나 질감을 담는다.

DCT만 한다고 압축이 되는 것은 아니다. 실제로 용량을 줄이는 과정은 Quantization을 진행해야 한다.

8x8 block에 대해 각 pixel값 - 128

DCT 변환

Quantization

DCT의 결과를 해석하면 다음과 같다. 사람의 눈이 민감하게 반응하는 정보는 왼쪽 위에 저주파 성분으로 몰려 있고, 덜 민감하게 인식하는 정보는 오른쪽 아래인 고주파 성분으로 몰려있다.

따라서 오른쪽 아래인 고주파 성분을 대충 저장하거나 0으로 만들면 되지 않을까? 라는 생각에서 출발한 것이 바로 Quantization이다. 각 자리에 대응하는 matrix로 나누고 반올림을 해준다.

왼쪽 위 저주파 영역은 값을 비교적 많이 반영해야하므로 작은 값으로 나누고 반올림을 해주는 반면, 오른쪽 아래 고주파 영역은 0이 되도 상관없기 때문에 큰 값으로 나누고 반올림을 해준다. 결과는 다음과 같다.

이런식으로 Quantization을 진행하면 된다. 그렇다면 손실은 어디서 발생할까? 바로 올림을 하는 부분에서 발생한다. (0, 0) 위치의 -415에 대해서 16으로 나눈 후 반올림을 한 결과가 -26이다. 이 -26을 다시 16으로 곱하여 복원을 하면 -416이 된다. 처음 -415와 1이 차이가 나게 된다. 정리하자면 Quantization에서 나누고 반올림하면서 원래 DCT coefficient의 정확한 값이 사라지는 현상이 발생하여 손실이 생기는 것이다.

Zigzag scanning

Quantization 이후에는 값을 지그재그로 읽어준다. EOB는 End Of Block이라는 의미로, 이 뒤는 모두 0이 되기 때문에 더 이상 저장하지 않겠다는 의미이다.

[영상처리] Image Restoration

PiLove — Fri, 15 May 2026 08:42:41 +0900

고영준 교수님 영상처리 강의 내용 정리입니다.

Image Restoration

Image Restoration이란, 말 그대로 손상된 이미지를 더 원래 이미지에 가깝게 만드는 작업을 말한다.

: 우리가 얻고 싶은 원래 이미지
g(x,y): 실제로 관측된 손상된 이미지
h(x,y): blur를 만드는 필터 또는 커널
n(x,y): 이미지에 추가된 noise

우리가 실제로 보는 이미지는 원래 이미지에 어떤 blur filter를 거치고 거기에 noise가 더해진 결과라는 가정에서 출발한다.

Noise는 외부 방해나 센서 문제 등으로 인해 이미지에 생기는 원하지 않는 변화를 말한다. Salt and Pepper noise, Gaussian noise, Speckle noise, Periodic noise, ... 등 다양한 noise가 존재하는데, 이러한 noise의 종류에 따라 적절한 제거 방법이 다르다.

Salt and Pepper Noise

Salt and Pepper noise는 이미지에 흰 점 또는 검은 점이 무작위로 튀는 noise이다. 매우 갑작스러운 값의 변화가 생기고 일부 픽셀이 거의 0 또는 255같은 극단값으로 바뀌는 현상이 발생한다. 이에 대한 해결방안으로 3가지가 있다.

Low pass filtering
Median filtering
Outlier rejection method

이 중 Median filtering에 대해 알아보자. Median filtering의 과정은 간단하다. 예시로 어떤 픽셀 주변에 3 x 3 window를 잡는다고 하자. 이 window에 대해서, 다음과 같은 작업을 수행한다.

주변 픽셀 값들을 모은다.
값을 크기순으로 정렬한다.
가운데 값, 즉 median을 선택한다.
현재 픽셀 값을 그 median값으로 변경한다.

예를 들어 3 x 3 window의 픽셀값을 정렬한 결과가 다음과 같다고 가정하자.

50, 52, 57, 58, 60, 61, 63, 65, 255

여기서 255는 salt noise일 것이다. 그리고 값은 60으로 변경해주면 된다. 참 쉽다.

Gaussian Noise

Gaussian noise는 salt and pepper와 달리 이미지 전체에 비교적 자연스럽게 퍼지는 noise이다.

Gaussian noise는 additive noise를 가정한다. Additive noise란, 원래 픽셀 값을 완전히 바꾸는 것이 아니라, 원래 픽셀 값에 어떤 랜덤한 noise 값을 더하는 형태를 말한다. 또한 평균을 0으로 가정한다. 아래와 같이 표현할 수 있다.

: 원래 이미지
N(x,y): Gaussian noise
IG(x,y): noise가 추가된 이미지

이러한 Gaussain noise의 제거에는 average filter가 사용된다. Average filter가 왜 효과가 좋을까? 만약 같은 장면을 noise가 섞인 상태로 100장 찍었다고 가정하자

이 이미지들을 평균내면

원래 이미지 값인 I는 계속 같은 값이니까 평균을 내도 그 값이 그대로 유지가 되는 반면에 noise에 해당하는 N는 랜덤하고 평균이 0이므로, 큰 수의 법칙에 따라 많은 시행이 일어날 수록 N의 평균은 0에 수렴하게 된다.

따라서 noisy image 10장을 평균낸 것보다 100장을 평균낸 것이 더 깨끗하게 보인다.

그러나, 현실에서는 같은 장면을 100장 가지고 있는 경우가 많지 않다. 그래서 한 장의 이미지 내부에서 주변 픽셀들을 평균내는 방식인 simple average filtering을 주로 사용한다.

Adaptive filtering

Wiener Filter

Average filter의 문제는 모든 영역에 똑같이 평균을 적용한다는 점이다. 그런데 이미지에는 두 종류의 영역이 있다.

변화가 거의 없는 smooth region
변화가 큰 edge region

Smooth region에서는 평균을 많이 내도 괜찮다. 어차피 원래도 비슷한 값들이 모여있기 때문이다. 그러나, edge region에서는 평균을 많이 내면 경계가 모호해지는 문제가 발생한다. 그래서 Wiener filter는 지역적인 특성을 보고 필터링 강도를 조절한다.

그래서 그 지역적인 특성을 어떻게 보느냐? 바로, mask 내부의 평균과 분산을 사용한다. 분산이 크다는 건 주변 픽셀 값들이 많이 다르다는 의미이다. 즉, 경계나 디테일이 있을 가능성이 높으므로, 이런 곳에서는 평균을 강하게 적용하면 edge가 방가지므로, 원래 입력 값을 더 많이 유지해야한다.

반면, 분산이 작다는 건 주변 픽셀 값들이 비슷하다는 의미이다. 이런 곳에서는 평균을 많이 적용해도 구조가 크게 망가지지 않기 때문에 noise 제거를 더 강하게 해도 된다.

Bilateral Filter

Bilateral filter는 두 가지를 동시에 본다.

공간적으로 가까운가?
픽셀 값이 비슷한가?

아래 식이 위 2가지 가중치를 곱한 형태이다.

첫 번째 Gaussian은 위치 차이를 본다. 두 번째 Gaussian은 intensity 차이를 본다. 즉, Bilateral filter는 가까이 있으면서, 밝기 값도 비슷한 픽셀만 많이 평균을 내는 방식으로 동작한다.

Nonlocal Means Filtering, NLM

NLM은 앞의 필터들과 관점이 조금 다르다. 앞서 살펴보았던 filter들은 보통 현재 픽셀 주변의 local window를 중심으로 생각했다. 그러나 NLM은 이름 그대로 non-local, 즉 멀리 떨어진 영역까지 본다.

[데이터베이스] Week8. 확장 ER Modeling, ER Model to Relation schema

PiLove — Tue, 28 Apr 2026 14:46:25 +0900

충남대학교 이규철 교수님, 데이터베이스 수업 8주차 강의 정리입니다.

Enhanced(Extended) ER Modeling

ER Model로는 표현 못하는 것들이 많아, 더 확장한 모델을 EER(Enhanced ER) Model이라고 부른다. 기존 ER model에 대해 객체 지향 개념도 추가 되었다.

객체 지향 개념이 추가되면서 ER model에 새로운 타입이 추가되었는데, 먼저 상속 관계성 타입이다. 서브 클래스 - 수퍼 클래스 관계성 타입으로, is - a 타입이라고도 부른다. 두 개체 클래스(서브 클래스, 수퍼 클래스) 사이의 일대일 관계성 타입을 표현하는 타입으로, 서브 클래스는 수퍼 클래스의 모든 속성을 가지면서 추가적인 특성 또한 가질 수 있다.

다음과 같은 그림에 대하여, Hourly Employee와 Slaried Employee는 Employee라는 수퍼 클래스의 서브클래스이다. 위에서 서술 하였듯이, 서브 클래스는 수퍼 클래스의 속성을 모두 가지며, 추가적인 속성을 가지고 있는 것을 확인할 수 있다. is - a 타입이라고도 부른다고 했는데, Hourly Employee is an Employee 라는 관계로 나타낼 수 있기 때문이다.

여기서 Specialization, Genralization이라는 개념에 대해 간단하게 소개하자면, 모델링을 하는 과정에서 한 클래스 내의 객체들 간의 차이점을 발견하고 명세하는 과정을 Specialization(Top-Down)이라고 한다. 그리고, 두 개 또는 그 이상의 분리된 클래스들에서 하나의 공통된 속성들을 가지는 수퍼 클래스를 생성하는 과정을 Generalization(Bottom-Up)이라고 한다. 모델링은 어느 방향으로 하든 상관 없다.

Specialization은 다중 계층 구조를 가질 수 있는데, 예를 하나 살펴보자.

Specialization을 할 때 특정 측면에 따라 Specialization이 가능하다. 무슨 의미냐면, 위 그림의 왼쪽 브랜치를 보자. Employee가 돈을 어떤 형태로 받느냐에 따라 Hourly, Salaried로 구분이 가능하다. 반면, 오른쪽 브랜치를 보자. Employee의 업무에 따라 Cashier, Secretary, Shipping Clerk, Stock Clerck으로 구분 가능하다. 즉, 측면에 따라 다른 Specialization이 가능하고, 이를 Multiple Specialization(다중 특수화) 구조라고 부른다.

이와 헷갈리면 안되는 개념으로 Multiple Inheritance(다중 상속) 구조가 있다.

Multiple Inheritance 구조에서는 2개의 수퍼 클래스로부터 하나의 서브 클래스가 나오게 된다. 만약 서로 다른 두 수퍼 클래스에 같은 이름을 가진 속성이 있다면, 서브 클래스에는 속성이 구분되어 저장된다.

지금까지 구조, 즉 Structure에 대해 알아보았다. 이제 EER model의 constraint에 대해 알아보자.

Constraint는 3가지를 명시할 수 있다.

상호배제(Disjointness)
: 하나의 개체는 반드시 하나의 서브클래스에만 속해야 한다는 특성
완전성(Completeness)
: 하나의 개체는 적어도 하나의 서브 클래스에 속해야 한다는 특성
특수화에 대한 정의 애트리뷰트(Definiting Attribute)
: 애트리뷰트에 의해 정의된 특수화(speicalization)는 특정 애트리뷰트의 값을 통해 서브 클래스 멤버가 지정

위에서 부터 처음 왼쪽의 브랜치와 오른쪽의 브랜치를 보면, 그 줄기가 다른 것을 확인할 수 있다. 왼쪽은 2개의 줄로 표시된 total, 오른쪽은 1개의 줄로 표시된 partial이다. 지난번 시간에 배웠던 내용이기도 하다. 이를 통해 완전성 제약조건을 나타낼 수 있다. 왼쪽 브랜치를 먼저 보자. Employee는 Hourly나 Slaried 중 적어도 하나의 서브 클래스에 속해야 하므로 total participation constraint를 만족하고 이는 Completness constraint(완전성 제약조건)를 만족한다는 의미이다. 반대로 오른쪽 브랜치를 보자. 부분 특수화 라고 표현하였는데, 이는 partial participation을 의미하며, Employee가 업무에 따라 Cahiser, Secretary, Shipping clerk, Stock clerck으로 나눌 수 있는데, 이 외에도 Employee가 존재할 수 있다는 의미이다.

그리고 왼쪽 브랜치는 d라고 표시되어 있고 오른쪽 브랜치는 o라고 표시되어 있는데, d는 Disjoint라는 의미이며, Employee는 Hourly Emplyee와 Slaried Employee로 딱 나뉘어짐을 의미한다. 다시 말해, Hourly이면서 Slaried인 Employee가 없다는 의미이다. 오른쪽 브랜치의 o는 Overlap이라는 의미이며, Employee는 Cashier이면서 Secretary인 Employee가 있을 수도 있으며, 그 외에도 서로 업무가 겹칠 수 있다는 의미이다.

마지막으로 Defining attribute이다. Defining attribute는 각 개체의 특수화 방향을 정해주는 attribute이다. 위에서 살펴보았듯이, 특수화는 측면에 따라서 방향이 달라질 수 있는데, wageType이라는 Defining attribute를 두어 해당 속성의 값을 통해 Hourly이냐 Slaried이냐가 정해진다.

EER Model to Relation schema

EER Model을 relation schema로 표현하는 방법은 크게 3가지이다.

슈퍼 클래스와 서브 클래스 각각에 대해 하나씩의 테이블을 생성한다.
모든 서브 클래스의 애트리뷰트를 포함하여 슈퍼클래스에 대해서만 하나의 테이블을 생성한다.
각 서브 클래스가 슈퍼 클래스의 애트리뷰트를 상속받아, 각 서브클래스에 대해서만 하나씩의 테이블을 생성한다.

좀더 쉽게 말하면,

슈퍼, 서브 각각 생성
서브의 애트리뷰트를 포함하여 슈퍼 하나만 생성
슈퍼의 애트리뷰트를 포함하여 서브 각각에 대해서만 생성

으로 이해하면 된다.

[데이터통신] Week7. Digital Transmission

PiLove — Mon, 13 Apr 2026 19:27:20 +0900

충남대학교 김기일 교수님, 데이터통신 과목 7주차 강의 내용 정리입니다.

Digital to Digital Conversion

Digital data를 어떻게 Digital signal로 변경할 수 있을까? 변환은 Line coding과 Block coding을 통해 가능하며, Line coding은 항상 이루어지지만, Block coding은 항상 이루어지진 않는다.

Line coding

Line coding은 bit와 signal element를 맵핑하여 문제를 풀어가는 방식을 말한다. 무슨 말이냐? 아래 그림을 살펴보면서 알아가자.

Data element per Signal element (r)

Digital data를 Signal data로 변환하는 과정에서 중요하게 생각해볼만한 것이 Data rate와 Signal rate이다.

위 그림을 보면, "속도" 도 크게 두 가지로 나눌 수 있다. 하나는 Data rate, 또 하나는 Signal rate이다. Data rate는 우리가 지금까지 배웠던 것 처럼 초당 보내는 데이터 비트 수 즉, bps로 표현할 수 있고, Signal rate는 초당 보내는 signal element의 수, 단위는 baud로 표현할 수 있다.

지금까지 배웠던 내용에 의하면 bps가 높을수록 좋았다. 그렇다면, baud는 높을수록 좋을까? 낮을수록 좋을까? 정답은 낮을수록 좋다. Baud가 낮다는 의미는 무슨 의미일까? 1초 동안 signal이 바뀌는 횟수가 적다는 의미이다. 즉, 대역폭의 영역이 줄어든다는 의미이다. 지난 번에 배웠던 내용을 생각해보자. Signal이 빠르게 바뀐다는 건, 시간축에서 더 짧은 시간 안에 모양이 급격하게 변한다는 의미이고, 이러한 급한 변화는 빠르게 진동하는 주파수 성분이 필요하다. 결국, signal이 빠르게 변화하기 위해선 더 높은 주파수 성분이 필요하고 이는 곧 넓은 대역폭을 의미하게 된다.

따라서 데이터통신에서는 bps는 높게, baud는 낮게하는 것이 목표라고 할 수 있다.

해당 식에 대하여 N : data rate, S : signal rate, r : signal element 하나가 담는 data element 수를 의미한다.

해당 공식 바로 위의 그림에서 r의 값을 함께 표현하기도 했는데, 이 r이 signal을 평가하는 하나의 척도로 볼 수 있다. r이 크면 한 신호에 더 많은 데이터를 담을 수 있다. 따라서 signal rate가 작아진다. 반면 r이 작으면 비트 하나를 보내는 데 여러 신호를 써야한다. 결국 signal rate가 커진다. 즉, r은 클수록 좋다.

이 r값과 더불어 DC component, Self synchronization을 고려하여 적절한 신호 형태를 설계하는 것을 Line coding이라고 부른다.

DC Component problem

Line coding에서 생길 수 있는 문제 중 DC component라는 게 있다. 아래 2개 중 하나만 만족하더라도 Digital signal이 DC Component problem을 가지고 있는 것으로 본다.

Digital signal에서 전압이 오랫동안 한쪽으로 constant하게 치우쳐져 있다.
Digital signal의 평균 전압이 0이 아니다.

2개의 그래프 중 위 그래프는 평균 전압이 0이 아니므로, DC component를 가지고 있다고 볼 수 있다, 아래 그래프는 평균 전압이 0이지만, 전압이 한쪽으로 constant하게 치우쳐질 수 있는 위험이 있으므로 여전히 DC component를 가지고 있다고 볼 수 있다.

Self-synchronization problem

Line coding에서 생길 수 있는 또 다른 문제로 Self synchronization라는 게 있다. 송신측은 자신의 클럭에 맞추어 비트를 보내고, 수신측도 자신의 클럭에 맞추어 비트를 읽는다. 이때, 두 클럭이 완벽히 같을 수는 없다. 그래서 수신측은 signal을 통해 현재 비트의 위치를 알 수 있어야 한다.

즉, Digital signal은 signal 안에 타이밍 정보가 포함되어 수신측에서 그 신호의 transition(전이)을 보고 클럭을 다시 맞출 수 있는 성질인 self-synchronization을 가지고 있어야 한다.

해당 그림은 self synchronization이 없다고 볼 수 있다. 위에서 언급했듯이 송신기와 수신기는 각자의 클럭에 맞게 비트를 읽어내는데, 송신기에서 보낸 signal에 주기적인 전이(transition)이 없으므로 수신기에서 비트를 잘못 읽어낸 것이다.

Line coding의 종류

Unipolar

Unipolar는 말 그대로 전압이 한쪽 극성만 사용되는 방식이다. 안타깝게도 DC component가 존재하고, Self synchronization은 없다.

Polar : NRZ(Non Return to Zero)

NRZ-L의 경우, DC component가 없다고는 못한다. 평균은 0이지만, 전압이 한쪽으로 치우치면 DC component가 발생할 수 있다.

NRZ-I의 경우에도, DC component의 위험이 있다. 그래도 Inversion 덕분에 bit가 1이 발생할 때에 한하여 전이(Transition)가 발생하므로 한정적으로 Self synchronization이 있다곤 볼 수 있다. 물론 완벽하지 않다.

Polar : RZ(Return to Zero)

어떤 경우에도 중간에 전압이 0으로 돌아오면서 전압이 상수로 일정하게 이어질 걱정은 안해도 된다. 평균도 0이므로, DC component는 없다고 보면된다. 0으로 돌아오는 지점이 비트의 중간 부분이므로 타이밍도 전달이 된다. 따라서 Self synchronization이 있다고 볼 수 있다. 그러나 r 값이 안타깝게도 1/2이다. 따라서 필요한 Bandwidth도 2배이다.

Polar : Manchester and Differential Manchester

Manchester는 RZ와 다르게 0으로 보내지 않고, signal element 도중에 아예 다른 전압으로 signal을 변경한다. 덕분에 타이밍 정보가 수신기에 전달되므로 클럭을 비트에 맞출 수 있고, 따라서 synchronization을 만족한다. 또한 DC component도 없다고 볼 수 있다. 평균이 0이 될 것이고, 중간에 전압을 변경하기 때문에 상수로 일정하게 유지될 걱정도 없기 때문이다. 다만, RZ 처럼 signal element 당 bit의 수를 나타내는 r의 값이 1/2이기 때문에 Bandwidth를 2배로 사용해야 한다.

Bipolar : AMI and Pseudoternary

AMI는 0일 땐 0이고, 1일 땐 전압을 변경한다. 여기서 전압을 변경할 때, 이전 변경 방향과 반대로 방향을 함으로써 DC component 문제를 방지한다. 처음에 양의 방향으로 전압을 변경하다. 그 다음 1일 나올 때엔 음의 방향으로 전압을 변경한다. 그렇다면 synchronization은 어떠할까? synchronization은 제공하지 않는다. 대신 r 값이 1이 된다.

Bipolar : Multilevel Schemes

레벨을 여러개를 사용하게 되면 bps가 빨라진다. 즉, r값이 증가하는 이점을 얻는다. 대신 decoding과정이 복잡해지는 문제가 있다. 각각의 레벨을 나누어 송신하는 방법도 있다. 아래 그림을 참고하자.

Block coding

Line coding의 방법만으로는 준수한 r값(bandwidth), DC component, Self synchronization을 모두 만족시키긴 어려웠고, 이를 보완하기 위해 block coding이 등장했다.

일반적으로 블록 코딩은 위와 같은 과정을 통해 진행한다. 기존 m개의 비트열을 더 긴 비트열인 n개 비트열로 만들어준다.

이를 통해 얻을 수 있는 효과는 뭐가 있을까? 예를 하나 들어보자.

NRZ-I라는 Line coding의 문제가 무엇이었는지 기억하는지용? 0이 계속 반복되면 DC component가 발생할 수 있다는 점이다. Block coding을 이용하면 이 부분을 해결할 수 있다.

NRZ-I가 만약 0이 반복되는 4개의 비트열을 보냈다고 가정하면, 더 많은 비트열을 이어 붙여서 1이 나타나게끔 재포장하는 것이 즉, 0이 계속 나오는 게 문제면, 그 패턴이 그대로 나오지 않도록 먼저 block coding을 하고, 그 다음 NRZ-I로 보낸다

Scrambling

Line coding은 signal의 모양을 바꾸었다. Block coding은 데이터를 묶는 단위를 바꾸었다. Scrambling은 signal은 encoding할 때 signal을 바꾼다.

[데이터베이스] Week6. 데이터 모델 및 개념적 설계

PiLove — Thu, 9 Apr 2026 17:43:17 +0900

충남대학교 이규철 교수님, 데이터베이스 과목 6주차 강의 내용 정리입니다.

데이터베이스 설계 단계

데이터베이스 설계는 현실 세계의 요구사항을 분석하고 점차 구현 가능한 형태로 바꾸는 과정을 거친다. 설계 단계는 위 그림과 같다.

요구사항 수집 및 분석
개념적 설계 : 현실을 사람이 이해하기 쉬운 개념 수준으로 표현하는 단계
논리적 설계 : 관계형 테이블 같은 DBMS 구조로 바꾸는 단계
물리적 설계 : 실제 저장장치에 어떻게 저장하고 접근할지 정하는 단계(ORACLE, SQL, ...

Employee와 Project에 대한 실세계 데이터를 토대로 데이터베이스를 설계한다고 가정하자.

실세계의 데이터는 하나의 사실로, 데이터에 불과하지만, 개념적 설계를 통해 이들 사이의 관계를 정의하고 각 개체가 가지는 속성을 정의한다. Employee는 ssn이라는 key를 가지고, Project는 pnumer라는 key를 가진다. 그리고 Employee와 Project의 관계(Relationship)를 Works로 정의하고, hours라는 속성을 가진다. 또한 한 직원이 여러 프로젝트에 참여할 수 있고, 하나의 프로젝트에도 여러 직원이 참여할 수 있으므로, 다대다 즉, M:N 구조이다.

논리적 설계에서는 개념적 설계에서 만든 ER 모델을 실제 DB로 구현 가능한 형태로 바꾸는 작업을 수행한다. 개념적 설계의 결과인 ER Diagram을 Relational Schema로 변환해준다. 물리적 설계에서는 사용하는 DBMS의 종류에 따라 어떻게 저장하고 관리할지를 정하게 된다.

데이터 모델

데이터 모델은 개념적 설계 단계에서 현실세계의 데이터를 Abstratction하기 위해 사용하는 하나의 도구이다. 데이터 모델은 여러 종류가 있고, Structure, Operation, Constraints 3개의 구성요소를 지닌다. 이 중 Operation은 실제로 개념적 설계 단계에서는 잘 사용하지 않는다. 오늘 배워 볼 모델은 ER Data model이다. ER Data model 을 통해 개념적 설계를 하고, Relational Data model로 논리적인 설계를 하는 것이 목표이다.

위에서 언급했듯이, 개념적 데이터 모델에 해당하는 것이 ER Data model, 논리적 데이터 모델에 해당하는 것이 Relational Data model이다. 물리적 데이터 모델은 강의 내용에 따로 언급하지 않으셨다.

요구사항 수집과 분석

요구사항을 수집하고 분석하는 단계이다. 매우 중요한 단계이지만, 공부할 내용은 따로 없으니 넘어가도록 하자.

개체-관계 모델링(E-R Model)

E-R(-A) Model(Entity-Relationship(-Attribute) Model)이라고 부른다. 데이터를 개체, 애트리뷰트, 관계성으로 기술하는 고수준의 데이터 모델로 이해하면 된다.

E-R Diagram으로 데이터를 표현한 하나의 예제이다. 개념적 설계의 결과물인 ER Schema라고도 한다. 사각형은 각각의 개체를 의미하고, 사각형 사이의 마름모는 개체 사이의 관계성을 의미한다. 단어가 갑자기 기억이 안나는데... 납작한 원형 모양의 도형은 속성을 나타내고, 2줄로 그려진 납작한 원형 모양의 도형은 다중값을 가지는 속성을 의미한다. 실선으로 그려진 납작한 원형 도형은 유도 속성이라고, 다른 속성으로부터 파생된 속성임을 뜻한다.

Attribute의 유형은 크게 Simple과 Composite으로 나눌 수 있다. 더 이상 나눌 수 없는 atomic한 attribute를 simple attribute라고 하고, 하나의 의미있는 속성이지만, 더 잘게 쪼갤 수 있는 attribute를 composite attribute라고 한다.

다음과 같은 attribute가 있다고 할때, address, street은 composite attribute, 그 외의 attribute는 simple attribute라고 할 수 있다.

또한 Stored attribute와 Derived attribute로도 나눌 수 있다. Age라는 attribute가 있다고 할 때, stored attribute로 사용한다고 하면, 각 개체의 나이가 증가할 때마다 업데이트를 해줘야한다. 그러나 derived attribute로 사용한다고 하면, birthday라는 attribute를 통해 현재 년도를 빼서 나이를 구할 수 있으므로 업데이트를 하지 않아도 된다.

E-R Diagram

[운영체제및실습] Week6-7. Deadlock and Starvation

PiLove — Tue, 7 Apr 2026 19:00:16 +0900

충남대학교 류재철 교수님, 운영체제및실습 과목 6~7주차 강의 정리입니다.

Philosophers problem

Deadlock에 대해 알아보기 전에 Philosophers problem에 대해 알아보자.

Philosophers problem이란, 5명의 철학자가 원형 테이블에 앉아 있고, 포크도 5개가 있는 상황을 가정하고, Deadlock을 흉내(?)낸 문제이다. 철학자는 생각하다가, 배가 고프면 본인 왼쪽 오른쪽 즉, 양쪽 포크 2개를 모두 집어야만 식사를 할 수 있다. 그리고 다 먹으면 포크를 내려 놓는다. 여기서 중요한 조건은 포크는 한번에 한 철학자만 사용이 가능하다는 점이다.

각 철학자는 식사를 하려면 양쪽 포크를 다 집어야 한다. 그런데 만약 모든 철학자가 거의 동시에 행동해서, 왼쪽 포크만 먼저 집는 상황이 생길 수 있다. 이때 누군가 포크를 내려놓지 않으면 철학자 모두 영원히 오른쪽 포크를 기다려야하는 상황이 발생한다. 즉, Deadlock이 발생한다.

이에 대한 교재의 첫 번째 솔루션이다.

먼저, fork라는 배열을 생성한다. 각각의 fork는 한번에 한명의 철학자만 집을 수 있으므로, 값은 1로 선언하고, fork의 개수는 총 5개이므로 5칸짜리 배열로 생성한다.

다음으로 philosopher 함수를 보자. 철학자는 먼저 생각하고, 자신의 앞에 놓인 fork[i]를 집는다. 그리고 다음 fork[(i+1) mod 5]를 집어야 하는데, 이때 문제가 발생할 수 있다. 만약, fork[i]를 5명의 철학자가 거의 동시에 집는다고 가정하자. 그러면 그 어떤 철학자도 fork[(i+1) mod 5]를 집을 수 없게 된다. 즉, Deadlock에 걸릴 수 있다.

교재의 두 번째 솔루션을 확인해보자. 핵심 아이디어는 포크를 잡는 철학자의 수를 제한한다는 부분이다. 무슨 뜻이냐면, 문제의 Deadlock 상황은 5명의 철학자가 모두 왼쪽의 포크를 집었을 때 발생한다. 따라서, 애초에 동시에 포크를 잡을 수 있는 인원을 5명이 아니라 4명까지만 포크를 집도록 만든다는 의미이다.

코드를 보면, room이라는 semaphore 변수를 하나 더 선언한다. 해당 room에는 4명의 철학자만 입장이 가능하므로, 값은 4로 초기화한다. philosopher() 함수를 보면, 가장 먼저 wait(room)을 한다. 4명까지만 room에 입장이 가능하고, 마지막 한명은 입장이 불가능하다. 따라서 그 아래 코드가 실행될 때, 양쪽 fork를 모두 집은 철학자가 fork를 반납해야 입장이 가능하다.

이 외의 방법으로 2가지가 더 있다.

먼저 semaphore 변수 s를 선언하고 초기값을 1로 초기화한다. 그리고 가장 먼저 wait(s)를 하게 되면, 그 아래의 코드는 철학자 1명만 실행하게 된다. 이때 혼자이므로, fork를 양손 모두 집을 수 있으므로 식사를 마치고 자원을 반납하면 된다. 그러면 다음 철학자가 같은 과정을 거치게 된다.

마지막은 추가적인 semaphore를 사용하지 않는다. 철학자 중 홀수번째 철학자는 왼손을, 짝수번째 철학자는 오른손을 사용하게 하면 된다.

[운영체제및실습] Week5-6. Concurrency, Deadlock

PiLove — Tue, 31 Mar 2026 22:59:56 +0900

충남대학교 류재철 교수님, 운영체제 및 실습 과목 5주차 강의 내용 정리입니다.

Overview

Atomic operation : 중간이 보이지 않는, 쪼개지지 않는 동작
Critical section : 공유 자원 접근 구간
Mutual exclusion : Critical section엔 한 번에 하나의 thread만 접근 가능
Deadlock : 서로 기다리다가 영원히 멈춤
Livelock : 계속 반응은 하는데 진전은 없음
Starvation : 어떤 프로세스가 계속 선택되지 못함
Race condition : 실행 순서 때문에 결과가 달라짐

Critical-section problem

여러 process나 thread가 공유 자원을 함께 쓰면 race condition이 발생할 수 있다. 따라서 공유 자원에 접근하는 코드 구간을 critical section으로 두고, 이 구간에 여러 실행 흐름이 어떻게 들어가야 하는지 규칙을 세우기로 했다. 그 규칙이 제대로 된 해법인지 판단하는 기준이 바로 mutual exclusion, progress, bounded waiting이다.

Mutual Exclusion
한 순간에 오직 하나의 process/thread만 critical section에 들어갈 수 있어야 함
Progress
Critical section이 비어 있고, 들어가고 싶은 process/thread가 있다면 쓸데없이 무한정 기다리게 하면 안됨
Bounded Waiting
어떤 process가 critical section에 들어가고 싶다고 요청한 뒤, 언젠가는 들어갈 수 있어야 함

또한 critical section problem을 설명할 때, 한 process 코드를 보통 4개의 구간으로 나누어 생각한다.

Entry section
Critical section에 진입하기 전 준비하는 부분
Critical section
실제 공유 자원에 접근하는 부분
Exit section
Critical section을 다 쓰고 나온 뒤 다른 process/thread가 들어올 수 있게 정리하는 부분
Remainder section
그 외의 공유자원과 상관없는 일반적인 코드

이제 코드를 살펴보며 위 기준에 따라 해당 코드가 critical-section problem을 해결할 수 있는 해법이 될 수 있는지 판단해보자.

참고로, 단일 cpu일 경우, timeout을 염두해두고 코드를 보면 되고, 멀티 코어 cpu의 경우, 두 코드를 동시에 실행한다고 가정하면 된다. 일단 실습 환경이 core를 2개로 설정해두었기 때문에.. 멀티의 경우로 코드를 살펴보도록 하자.

PROCESS 0과 PROCESS 1이 동시에 실행된다고 가정하고, 초기의 turn값은 0이라고 가정하자. 이때, PROCESS 0 이 먼저 critical section에 진입하고, turn을 1로 만든 후 종료된다. 이후, PROCESS 1에서는 turn이 1이 되었으므로 무한 루프를 빠져나와 critical section에 접근하게 된다. 이는 mutual exclusion을 만족한다고 할 수 있다.

그러나, 이 방법에는 문제가 있다. 만약 PROCESS 0 이 실행된 후 turn 값이 1이 되고 난 후에 PROCESS 1이 실행된다고 하자. 이 때, PROCESS 1은 critical section에 진입하고 싶지 않다고 하면, PROCESS 1은 entry section 자체를 수행하지 않을 것이다. 그리고 timeout에 의해 PROCESS 0 이 실행될텐데, 이때 PROCESS 0은 critical section에 진입하고 싶다고 하더라도 turn 값을 바꿔줄 PROCESS가 없으므로 critical section에 진입하지 못하게 된다. 즉, 위 코드는 Progress를 위반하게 된다.

이 코드는 First attempt의 문제를 고치려는 코드이다. flag[0], flag[1]의 초기값은 false로 가정한다. 아이디어는 상대의 flag를 확인하여, 상대가 critical section에 안들어오려는 것 같으면 통과하고, 그 다음에 내 flag를 true로 변경한 뒤 critical section에 들어간다. 이후 내 flag를 false로 변경해준다. 이렇게 하면, 상대방이 critical section에 진입하고 싶지 않다고 하더라도, flag를 변경해줄 필요가 없어서 자신은 critical section에 진입할 수 있게 되어 progress를 지킬 수 있다.

그러나, 이 방법에도 문제가 있다. 두 process가 동시에 실행되고, flag[0]과 flag[1]의 초기값이 false로 가정하였기 때문에 동시에 critical section에 들어가버리는 일이 발생할 수도 있다. 즉, mutual exclusion을 위반하게 된다.

단일 CPU 일 때도 마찬가지이다. PROCESS 0이 while을 통과한 후 timeout으로 CPU를 빼앗긴다. 이후 PROCESS 1도 while를 통과하고 flag[1] = true를 수행한 뒤, critical section에 진입하기 전에 다시 timeout이 발생한다고 하자. 그 다음 PROCESS 0이 다시 CPU를 받아 flag[0] = true를 수행하고 critical section에 진입할 수 있다. 이후 PROCESS 1도 다시 CPU를 받으면 이미 while(flag[0]) 검사는 통과한 상태이므로 그대로 critical section에 진입할 수 있다. 따라서 단일 CPU 환경에서도 interleaving에 의해 두 프로세스 모두 critical section에 들어갈 수 있으므로, 이 알고리즘은 mutual exclusion을 만족하지 못한다.

이번 코드의 아이디어는 "상대를 먼저 확인하지 말고, 일단 내가 들어가고 싶다는 표시부터 하자"이다. 그래서 second attempt처럼 "둘 다 상대 flag를 false로 보고 동시에 들어가 버리는 문제"를 막으려는 것이다. 그래서 process가 critical section에 진입을 하고 싶다면, 자신의 flag를 true로 변경한뒤, critical section에 진입한다. 작업을 완료한 이후에는 자신의 flag를 false로 변경하여, 상대방의 진입 가능성도 열어둔다.

그런데, 이것도 문제가 있다. 두 process가 거의 동시에 실행된다고 하자. 서로의 flag가 true로 변경되며, while문에 갇히게 될 수도 있다. 이렇게 기다리는 동안 누가 flag를 false로 변경해줄까? 조건으로 보면 mutual exclusion은 만족한다. 둘 다 동시에 critical section에 들어가지는 못하니까.. progress의 경우는 만족하지 못한다. critical secion이 비어 있음에도 둘 다 들어가고 싶어하는 상황에서 누구도 못들어가기 때문이다. Bounded waiting의 경우 당연히 보장하지 못한다. 애초에 while문에 묶여서 진입 자체가 멈춰버릴 수도 있으니까.

단일 CPU에 대해서도 동일한 문제가 발생할 수 있다. PROCESS 0에서 flag[0]을 true로 초기화하고 time out이 걸리면 PROCESS 1에서는 while문 안에 갇히게 된다. 그러면 무한루프를 계속 돌다가 다시 timeout이 걸리고 PROCESS 0으로 넘어갈텐데, 이때 flag[1]의 값은 true로 변경되어 있기 때문에 똑같이 무한루프에 갇히게 된다.

Third attempt에서는 두 process가 while문에 갇혀서 둘 다 영원히 기다리는 상태가 됐었다. 이번에는 "상대가 원하면 내가 잠깐 양보해서 flag를 flase로 만들고, 나중에 다시 시도하자"가 아이디어이다. 다중 코어 CPU를 가정하면, 두 process가 동시에 실행되어, 서로의 flag를 동시에 false, true로 변경하게 되고... 똑같이 while문 안에 갇히게 된다. 단일 CPU를 가정해보자. PROCESS 0이 실행되고, flag[0]=true를 실행한 후, timeout에 걸린다고 하자. PROCESS 1에서 flag[1] = true로 변경하고 timeout이 걸린다고 하자. while문 안에서 또 flag[0] = true로 변경하고 다시 timeout에 걸리게 되면, PROCESS 1에서는 다시 while문을 돌아야하고... 이렇게 flag[0] = true, flag[1] = ture 를 수행한 후 timeout에 걸리게 되면 두 process 모두 critical section에 진입하지 못하게 된다.

Semaphore

Mutex, Progress, Bounded waiting과 같은 조건을 실제 코드에서는 어떻게 보장할까? 그 질문에 대한 답변이 바로 Semaphore이다.

Semaphore는 정수 값을 가지는 변수인데, 단 3가지의 연산만 허용된다. 초기화, semWait(감소), semSignal(증가)이다. semWait()은 보통 공유 자원에 들어가도 되나 확인하는 동작으로 보면 된다. 값을 1 감소시키고, 그 결과가 음수가 되면 지금 사용할 수 없는 자원이 없다는 뜻이라, 해당 프로세스를 ready queue에 넣고 block 시킨다. 반대로, semSignal()은 값을 1증가시키고, 기다리던 프로세스가 있다면 하나를 깨워 ready 상태로 보낸다. 코드로 이해해보자.

구조체로 선언된 semaphore에 대하여, count는 현재 사용 가능한 자원의 수를 의미하고, queue는 자원이 없어서 기다리는 프로세스들을 담는 queue이다. count는 개발자가 값을 지정할 수 있다.

semWait()을 보면, 먼저 s.count-- 를 통해 자원을 하나 쓰겠다는 표시를 하고, 그 결과가 0보다 작아지면 큐에 집어 넣는다. 무슨 의미냐면... count가 현재 사용 가능한 자원의 수를 의미한다고 했는데, 이 count가 0보다 작아진다는 것은 사용 가능한 자원이 없다는 의미이고 따라서 해당 프로세스를 큐에 대기시킨다는 의미이다.

semSignal()을 보면 s.count++ 를 통해 자원을 반납하겠다는 표시를 하고, 그 결과가 0보다 작거나 같으면, 큐에서 대기하고 있는 프로세스를 제거하고 ready 상태로 만든다. 무슨 의미냐면... count는 단순히 남아 있는 자원 수만을 의미하는 것이 아니다. semWait()의 코드를 보면, s.count-- 를 하고, 음수라면 큐에 프로세스를 담는다. 즉, count가 음수라면 큐에서 자원을 기다리고 있는 프로세스가 존재한다는 의미이다. 따라서 semSignal()을 실행하면 자원을 반납하고 큐에서 대기 중이던 프로세스가 자원을 점유할 수 있도록 ready 상태로 만드는 것까지 해야한다.

Deadlock

Deadlock이란 2개 이상의 thread가 공유하는 특정 자원에 대하여, 서로가 서로 점유한 자원을 요구하며 무한정으로 대기하는 상황을 말한다. Deadlock의 조건에는 4가지가 있는데, 다음과 같다.

Mutex(상호배제)
각각의 공유 자원은 한번에 하나의 thread만 점유 가능
Hold and Wait(점유대기)
특정 공유 자원을 점유한 상태에서 다른 공유 자원을 요구
Non-preemption(비선점)
이미 어떤 thread가 점유한 자원을 강제로 빼앗을 수 없어야 함
Circular Wait(순환대기)
Thread들이 원형으로 서로의 자원을 기다리는 상태

위 4가지 조건을 Coffman 조건이라고 하며, 4가지 조건을 모두 만족해야 deadlock이 성립한다.

Deadlock을 해결하기 위해서 OS(Kernel)는 예방, 회피, 탐지/회복, 무시 등의 방법을 수행한다.

[데이터베이스] Week5. SQL-2

PiLove — Tue, 31 Mar 2026 21:08:20 +0900

충남대학교 이규철 교수님, 데이터베이스 과목 5주차 강의 정리입니다.

SQL에서 복잡한 검색 질의

[TABLE] JOIN [TABLE] ON [CONDITION]

두 개의 테이블에 대하여 질의를 할 때 하나의 테이블처럼 보기 위해 JOIN을 사용할 수 있다. 예시는 아래와 같다.

SELECT *
FROM Employee, TimeCard
WHERE Employee.ssn = TimeCard.ssn;

SELECT *
FROM Employee JOIN TimeCard 
	ON Employee.ssn = TimeCard.ssn;

명령어 수행 결과, 두 개의 테이블을 동일한 ssn으로 묶어 하나의 테이블처럼 볼 수 있다.

집단화 함수

집단화 함수란, 여러 튜플의 정보를 하나의 튜플로 요약하는 데 사용하는 함수를 말한다.

count, avg, sum, min, max, ... 등이 있다
select 절이나 having 절에 사용된다.

SELECT COUNT(*)
FROM Rental
WHERE accountId = 101;

SELECT COUNT (DISTINCT lastName)
FROM Customer;

SELECT AVG((endTime-startTime)*24) as avghousWorked
FROM TimeCard;

GROUP BY, HAVING

GROUP BY 절은 grouping 하는 기준이 되는 attribute에 대하여 tuple들의 그룹을 구성하는 명령어이다. 아래 명령어를 살펴보자.

SELECT videoId, 
	AVG(cost) as averageCost,
	Count(*) as numRentals
FROM PreviousRental
GROUP BY videoId

과거 렌탈 정보를 가지고 있는 테이블에 대하여 videoId를 통해 grouping을 하되, 필요한 attribute로는 videoId, cost의 평균(averageCost), videoId 각각에 대한 튜플 개수(즉, 렌탈 횟수)이다.

HAVING 절은 grouping attribute에 대한 조건절이라고 생각하면 된다.

SELECT title,
	genre,
    COUNT(*) as numRentals,
    AVG(cost) as avgCost,
    SUM(cost) as totalCost
FROM Movie, Videotape, PreviousRental
WHERE Movie.movieId = Videotape.movieId
	and Videotap.videoId = PreviousRental.videoId
GROUP BY Movie.movieId, title, genre
HAVING COUNT(*) >= 2

위 명령어에 대한 적용 순서는 다음과 같다.

Nested query

Nested query에 사용되는 함수는 Exists, all, unique, contains, not 등이 있다. 대표적으로 exists에 대해 알아보자. Exists 다음에 오는 select 문장의 실행 결과가 존재하는지 검사하는 함수로, 튜플이 하나라도 존재하면 참, 아니면 거짓을 반환한다.

SELECT *
FROM Customer C
WHERE NOT EXISTS (SELECT *
	FROM PreviousRental P
    	WHERE C.accountId = P.accountId)

집합 연산자

집합 연산에는 합집합(Union), 차집합(Except), 교집합(Intersect)이 있다. 일반적인 집합 연산과 같은 작업을 수행한다.

SELECT *, 'Rental' as sourceTable
FROM Rental
UNION
SELECT *, 'PreviousRental' as sourceTable
from PreviousRental

이전 대여 정보와 현재 대여 정보를 모두 질의하는 명령문이다.

관계 대수를 이용한 정보조작

개발자가 작성하는 SQL은 매우 편하지만, 문법이 인간 중심적인 언어이기 때문에 이 질의가 본질적으로 어떤 연산을 하는지를 엄밀하게 설명하기는 애매했다. 다른 말로 표현하자면, 서로 다른 SQL 질의가 같은 동작을 수행하는 경우가 많았다. 따라서 데이터베이스 이론에서는 SQL을 대신하여 질의를 순수한 연산으로 표현하기 위한 방법으로 관계대수를 사용한다.

관계대수는 데이터베이스를 관계(Realation), A set of tuples로 보고, 거기에 대해 적용할 수 있는 기본적인 연산들을 정의했다.

Selection : 행 고르기
Projection : 열 고르기
Union : 합집합
Difference : 차집합
Intersect : 교집합
Join, Product : 연결하기

그래서 실제로 관계대수는 어디서 쓰이는가를 알아보기 전에 우리가 작성한 SQL문이 Output을 산출하기까지 어던 과정을 거치는지 알아봐야 한다.

프로그래밍언어개론, 컴파일러개론을 수강했다면, 그 과정이 비슷하다는 것을 느낄 것이다. 나는 일단 처음이라 낯설긴 하다... 아무튼 SQL문이 입력되면, 이 SQL문을 컴퓨터가 관계대수로 나타내고 명령어의 순서를 최적화한다. 이후 순서에 맞춰 실행을 하게 되고 Output이 나온다.

최적화 과정에 대해 알아보자. DBMS는 Selection, Projection과 같은 관계 대수 연산자들의 조합으로 구성된 관계 대수 연산을 구현한 여러개의 알고리즘 가지고 있다. 이러한 DBMS에 의해 구현되는 최적화 모듈은 특정 질의와 특정 데이터베이스 설계에 적용되는 실행 전략들을 고려하여 질의의 순서를 최적화한다. 말은 어렵지만... 간단하게 DBMS가 관계 대수 연산 알고리즘을 여러개 가지고 있고, 이 DBMS에 의해 구현된 최적화 모듈이 실제로 우리의 SQL 명령문을 최적화한다고 생각하면 된다.

간단한 최적화 예제를 하나 살펴보자.

위와 같은 명령어는 관계대수 형태로 변경되고, 이를 트리 형태로 나타낸다.

이후, 질의 순서를 최적화하고, 실행을 위한 계획을 세운다.

각 관계대수 연산자 별 생김새

먼저 Select는 다음과 같다.

Projection은 다음과 같다.

참고로 projection의 결과는 집합이므로, 모든 중복은 제거된다.

합집합, 교집합, 차집합은 우리가 흔히 잘 아는 기호를 그대로 사용한다. 여기서 집합 연산자는 연산을 수행하려는 두 릴레이션이 같은 형태(Union-Compatible)를 지니고 있을 때 적용이 가능하다. 즉, 두 릴레이션이 가지고 있는 attribute의 개수(degree)가 같고, 대응하는 attribute 별로 타입(domain)이 동일해야 한다.

다음은 Product이다. 카티션 프로덕트(Catesian Product)라고 부르며, 두 릴레이션을 가지고 새로운 릴레이션을 생성한다.

그러나, 이렇게 생성한 relation은 문제가 많다. Employee의 tuple이 3개, TimeCard의 tuple이 4개라고 가정하면, 3 x 4 = 12, 총 12개의 tuple이 만들어진다. 여기서 문제는, 공유하고 있는 PK - FK가 없기 때문에, 적절한 조건 없이 카티션 프로덕트를 진행하게 되면 이 12개의 tuple 중 전혀 관계없는 attribute들이 하나의 tuple로 구성되어 있는 케이스가 있다는 것이다.

따라서 조건을 걸어 Join연산을 진행해야 한다.

Join의 경우, Selection과 Cartesian Product 2개의 관계 대수 연산자로 표현된다. 이를 좀 더 간단하게 나타내기 위한 연산자가 자연조인(Natural Join)이다. 자연조인은 같은 이름의 attribute를 자동으로 기준 삼아 join하고, 중복 컬럼도 하나로 합쳐주는 join이다.

여기서 자연조인은 같은 이름의 attribute는 중복을 제거하여 하나로 합치게 되는데, 이와는 반대로 중복되는 attribute들을 모두 살려 join하는 방식이 동등조인(Equi-Join)이다.

이 외에 부가적인 관계 연산자로 집단화 연산의 Average, Count 등이 있다.

[영상처리] Week4. Image filtering

PiLove — Mon, 30 Mar 2026 23:43:19 +0900

충남대학교 고영준 교수님, 영상처리 4주차 강의 정리입니다.

Image filtering

지난 시간에 배웠던 point processing은 하나의 pixel이 output의 하나의 pixel에 1대1로 대응한 반면, image filtering에서는 특정 크기의 filter를 input image의 각 pixel에 대하여 filter의 크기만큼 주변 이웃 pixel들에 대한 연산을 통해 pixel값을 구하게 된다. 말로 표현하자니... 좀 헷갈리는데 그림으로 보면 이해하기 쉽다.

우선 다음과 같이 3 by 3 filter를 가정하자. 참고로 이 그림과 같이 filter의 각 자리에 대한 가중치, 즉 filter 내부의 모든 값들이 서로 같고, 그 전체의 합이 1이 되는 filter를 average filter라고 한다.

모든 pixel에 대하여 위 그림과 같이 연산을 진행하게 된다. 우선 해당 자리의 pixel은 주변 이웃 pixel들까지 모두 0이기 때문에 그 결과도 0이 되게 된다. filter를 오른쪽으로 한칸 움직여서 적용해보자.

연산은 Input image의 3 by 3 matrix와 3 by 3 filter의 동일한 자리끼리 곱셈을 진행하고 그 값을 모두 더하는 방식으로 진행된다. 따라서 (0 x 1/9) + (0 x 1/9) + (0 x 1/9) + (0 x 1/9) + (0 x 1/9) + (0 x 1/9) + (0 x 1/9) + (0 x 1/9) + (90 x 1/9) = 10이 된다. 이런 식으로 input image의 모든 pixel에 대해 연산을 진행하게 된다. 가장자리의 pixel에 대한 연산은 뒤에서 설명하도록 하겠다.

어쨋든 이러한 연산을 통해 얻을 수 있는 효과는 무엇일까?

각 pixel이 주변 pixel 값을 참고하여 평균을 낸 값으로 변경되기 때문에, pixel 사이의 contrast가 줄어들 것이다. 이러한 효과를 smoothing이라고 한다. 실제 이미지는 아래와 같이 변경된다.

음... 재밌당

이번엔 filter의 종류를 변경해보자. 다음과 같은 filter가 있다고 가정하자.

이 filter는 sharpening filter라고 부른다. 우선 해당 해당 filter에 대해 이해하기 위해 직관적으로 다음과 같이 표현할 수 있다.

출력 pixel 값 = (2 x 중심 pixel) - (주변 pixel 3x3 평균)

Input pixel에 대해여 Output pixel이 어떤 의미를 가질까? 중심 pixel의 밝기를 2배를 올리고, 주변의 평균으로 빼준다. 이는 곧, 중심 pixel과 주변 pixel 평균과 얼마나 다른지를 의미한다. 만약 주변 pixel의 크기가 거의 비슷한 곳은 중심 pixel의 연산 결과가 비슷하게 유지되겠지만, 주변 pixel의 크기가 서로 큰 차이가 난다면 연산 결과도 더 크게 차이가 날 것이다. 따라서 이미지에서 밝기가 급격히 변하는 부분, 즉 경계, 윤곽 등에서 선명함이 살아나는 효과를 준다.

음... 역시나 재밌당

또 다른 filter로 이런 것도 있다.

Filter의 모양을 보니, 각 pixel에 대하여 해당 pixel을 왼쪽으로는 양의 가중치를 곱해주고, 해당 pixel을 오른쪽으로는 음의 가중치를 곱해준다. 만약 input image의 3 by 3 matrix에 대하여 9개의 pixel이 큰 차이가 없다면 결과는 0에 가까워서 어두워질 것이다. 반면에 3 by 3 matrix에 대하여 왼쪽과 오른쪽 세로로 그 값의 차이가 크다면 결과는 높은 값을 가지게 될 것이다. 즉, 세로 윤곽선에 대하여 집중하여 표현할 수 있다.

가로 윤곽선에 대해서도 다음과 같은 filter를 통해 표현할 수 있다.

Gaussian filters

Gaussian filter는 average filter처럼 smoothing filter지만, 훨씬 더 자연스러운 smoothing을 가능하게 한다. 우선 식을 확인해보자.

... 식은 복잡하지만.. 그래프의 개형을 통해 우리가 어떤 filter를 사용할 것인지 확인할 수 있다. 그래프를 쉽게 그리기 위해서는 뮤를 없애고 (1/e)^(x^2) 에 대해서 그래프를 그리면 된다. x가 gaussian filter의 pixel값이라고 가정하고, x의 값이 0보다 커지면 점점 감소하게 되어 0에 수렴하게 된다. x의 값이 0보다 작아져도 점점 감소하게 되어 0에 수렴하게 된다. 그러면 우리가 흔히 잘 아는 0을 기준으로 대칭인 종모양 그래프가 그려지게 된다.

여기서 시그마까지 고려해보자. 시그마가 식에 포함되면 (1/e)^((x^2)/시그마) 가 되고, 시그마 값이 1보다 크면 기존 x^2보다 감소 폭이 더 완만해질 것이다. 시그마가 1일 때와 시그마가 2일 때를 가정하고 x값을 임의로 2나 4 등으로 넣어 생각해보면 된다. 반대로 시그마 값이 0보다 크고 1보다 작을 경우, 기존 x^2보다 감소 폭이 더 가파라질 것이다.

위에서 주저리 주저리 그래프를 상상하며 쓴 글은 1차원을 기준으로 쓴 것이다.

2차원 데이터에 대한 식은 다음과 같다.

2차원 식에 대한 그래프는 위와 같고, 시그마 값에 따라 그래프의 개형이 달라지는 것은 동일하다. 이걸 filter로 사용한다고 하면, 중심에 좀 더 높은 가중치를 두고, 중심에서 멀어질 수록 가중치가 줄어든다는 것을 확인할 수 있다.

Filter의 각 자리에 대한 계산은 식에 자리에 해당하는 x, y값을 대입해주면 된다. 그리고 그 값들을 모두 더하여 나눠주면 gaussian filter가 완성된다. 위 그림에는 나눠주지 않았는데, 나눠주어야 한다. 나눠주어야만 input image의 전체적인 밝기를 유지할 수 있다. 어쨋든 이걸 직접 적용하면 다음과 같아진다.

일반적인 box filter에 비해 더 자연스럽게 smoothing 처리 해주는 것을 확인할 수 있다.

Gaussian filter의 크기는 보통 다음과 같은 사항을 고려하여 정한다.

filter 원소의 합이 1
filter 가장자리의 값이 0에 가까워지게
Rule of thumb for Gaussian : filter의 너비의 절반을 대략 3x시그마 정도로 잡는다

3번의 이유도 그래프를 생각해보면 왜 그런지 알 수 있다. 일단 두번째 사항으로 filter의 가장자리의 값은 0에 가까워져야 한다. 만약 시그마의 값이 크다면, 그래프의 모양도 넓게 펴질 것이다. 여기서 filter의 크기를 작게 잡는다면, filter의 가장자리 0에 가까워지지 않을 수 있다.

위 그래프처럼 시그마 값이 크다고 가정하자. 그러면 입력 pixel x의 위치가 중심으로부터 멀리 떨어져야만 0에 가까운 값을 가지게 된다. 따라서 filter의 크기가 커야 중심으로부터 더 멀리 떨어진 x까지 연산이 가능하다. 따라서 시그마의 값이 크면 filter의 값도 커져야 하고, 그 비율이 대충 Rule of thumb for Gaussian에서 제시한 정도가 되는 것이다. 참고로 빨간색 파란색 세로 선은 filter 크기에 따른 입력 pixel x의 위치를 표현하기 위해 그린거다... 반듯하지 않네..

Separability of the Gaussian filter

Gaussian filter는 이미지 처리에 대해서 입력 값으로 2개를 받게 된다. 이를 분리하여 게산할 수도 있는데, 식으로 표현하면 다음과 같다.

식으로는 분리가 되는 것을 확인했다. 실제 matrix에서 어떻게 나뉘는지 확인해보자.

예로 가져온 filter가 gaussian filter는 아니지만, gaussian filter처럼 filter의 중심을 기준으로 대칭인 filter이므로, 그 성격은 동일하다고 볼 수 있다. Filter의 중심을 기준으로 대칭이기 때문에 2D를 1D 벡터의 곱으로 분리할 수 있다. 그리고 row를 먼저 연산해주고 나온 결과값에, 그림에는 없지만 column까지 곱해주면 그 결과가 동일한 것을 확인할 수 있다.

이에 대한 증명은 다음과 같다.

[데이터통신] Week5-6. Physical layer

PiLove — Mon, 30 Mar 2026 20:51:11 +0900

충남대학교 김기일 교수님, 데이터통신 과목 5~6주차 수업 정리입니다.

Data and Signals

Physical layer를 이해하기 위해선 가장 먼저 우리가 전달하고자 하는 data에 대해 이해해야 한다. Data는 우리가 보내고 싶은 정보 그 자체이다. 예를 들면, 텍스트, 오디오, 이미지 같은 것을 의미한다. 반면, signal은 그 data를 실제 매체를 통해 옮기기 위한 물리적 표현이다. 컴퓨터에서는 data가 bit로 표현되지만, 실제로 통신을 위해 선이나 공기 속에서는 전기 펄스나 빛의 형태로 전달된다. Physical layer는 바로 이 data에서 signal로의 변환과 전달을 담당한다.

Week3 수업 시간에 배웠던 통신을 구성하는 5개의 요소가 기억나는가? 송신자, 수신자, 전달하고자 하는 메세지, 프로토콜, 그리고 전송 매체(transmission medium)이다.

전송은 위 그림처럼 송신자 측에서 data를 signal로 변환한 후 전송매체를 통해 전송하게 돼고, 수신자 측에서 signal을 data로 다시 변환하여 수신하게 된다. Data를 signal로 변환하는 과정을 encoding, signal을 data로 변환하는 과정을 decoding으로 이해하면 쉽다.

여기서 등장하는 문제가 바로, 컴퓨터는 0과 1로 동작하는 반면, 현실 세계는 Amplitude(진폭)와 Frequency(주파수) 같은 연속적인 물리량으로 움직인다는 것이다. 즉, physical layer의 가장 큰 과제는 digital 세계의 bit들을 analog 세계의 signal로 변환하는 것이다.

위 그림은 signal로부터 packet이 생성되기 까지의 과정을 단순화한 그림이다. Continuous한 analog signal을 Discrete한 digital signal로 변환되고 bit stream으로 표현된다. 이러한 bit들이 모여 packet을 생성하게 되고, 이러한 packet은 결국 상위 layer의 다양한 의미를 담은 data가 된다.

Data는 analog 또는 digital로 표현될 수 있으며, analog data는 continuous한 케이스를 의미하며, digital data은 discrete한 케이스를 의미한다. Signal도 마찬가지이다. Analog signal은 시간에 따라 무한한 값을 가질 수 있고, digital signal은 제한된 몇 개의 값만 가진다.

그림에서 확인할 수 있듯이 analog signal은 x축 값에 대응하는 y축 값이 무한하다. 애초에 0~1 사이의 실수가 매우 많이 존재하므로 analog signal의 형태가 반복적이더라도 x값에 대응하는 y값이 무한하다는 의미이다. 반면에, digital signal의 경우 x값에 대응하는 y값이 상수로 정해져있다.

또한 Signal은 periodic과 nonperiodic으로 나눌 수 있다. Periodic signal은 일정한 패턴을 한 주기(period)마다 반복하고, nonperiodic signal은 반복되는 패턴이 없다. 참고로 데이터통신에서는 보통 periodic analog signal과 nonperiodic digital signal을 사용한다.

Periodic Analog Signals

바로 앞 목차에서 signal이 analog/digital, periodic/nonperiodic으로 나뉜다는 것을 확인했다. 이번 목차에서는 periodic analog signal에 대해서 다룰 예정이다.

Periodic analog signal은 simple과 composite으로 나눌 수 있다.

Simple periodic analog signal의 대표가 바로 sine wave이다. Sine wave는 signal을 더 이상 쪼갤 수 없는 가장 기본적인 파형이다. 여기서 "더 이상 쪼갤 수 없는" 이라는 표현은 이후에 이해할 수 있다.

Sine wave를 이해할 때 핵심적인 속성은 크게 3가지 이다.

Amplitude(진폭)
Amplitude는 wave의 높이, 즉 얼마나 강한 signal인지를 나타낸다. Amplitude가 크다는 뜻은 해당 wave의 Peak 즉, 최대값이 크다는 의미이며, Amplitude가 클수록 signal의 세기가 더 크다.
Frequency(주파수)
Frequency란, 1초 동안 몇 번의 period가 반복되는지를 뜻한다. 위 그림에서 왼쪽 상단의 wave는 1초 동안 12번의 period가 관측되었으며 이를 12Hz라고 표현한다. 오른쪽 하단의 wave에서는 1초 동안 6번의 period가 관측되었으며 6Hz로 표현한다.

집에서 사용하는 교류 전기는 60 Hz를 사용한다. 이에 대응하는 period는 약 16.6ms 이다. 이에 대한 계산 식은 다음과 같다.
즉, 당장 거실에 있는 등은 16.6ms의 속도로 꺼졌다 켜졌다를 반복하고 있는 것이다. 이거 배우고 좀 신기했다...
Phase(위상)
Phase는 wave가 시간축의 어느 지점에서 시작하는지를 의미한다. 위 그림에서 세 wave는 모두 서로 다른 phase를 가지고 있다. Time 0에 대한 phase는 위에서부터 차례대로 0도, 90도, 180도이다. 즉, 같은 Amplitude와 같은 Frequency를 가진 wave라고 해도 시작 위치가 다르면 서로 다른 phase를 가지게 된다.

지금까지 sine wave를 통해 simple periodic analog signal에 대해 알아보았다. 그러나, 데이터통신에서는 이러한 simple periodic analog signal로는 충분하지 않다. 실제 data는 훨씬 복잡한 정보를 담아야 하므로 여러 simple periodic analog singal이 합쳐진 composite signal이 필요하다.

Composite signal은 서로 다른 amplitude, frequency, phase를 가진 여러 sine wave의 조합이며, periodic일 수도 있으며 nonperiodic일 수도 있다. 그림처럼 파랑색, 검은색, 빨간색의 simple sine wave가 모여서 하나의 composite signal을 구성하는 걸 확인할 수 있다.

그리고 여기서 각각의 simple sine wave는 서로 다른 frequency를 가지는데, 이 중 최대값과 최소값의 차이가 Bandwidth(대역폭)가 된다.

그림을 예시로... 위쪽 그림은, composite periodic signal을 구성하는 각각의 simple signal들이 1000~5000의 Frequency를 가지고, 최대값과 최소값의 차인 4000이 Bandwidth가 되는 것을 확인할 수 있다.

그 아래 그림은, composite nonperiodic signal을 구성하는 simple sinal들이 peridoci signal과 다르게 딱딱 떨어지지 않고 연속적인 범위로 퍼질 수 있음을 보여준다. 그래도 Frequency의 최대 최소의 차인 4000이 Bandwidth가 되는 것은 여전하다.

Digital Signals

Data는 analog signal로도 표현할 수 있지만, digital signal로도 표현될 수 있다. 예를 들어, 1은 높은 전압, 0은 0 전압으로 인코딩 수 있다. 또한 이러한 2개의 level만 사용하는 게 아닌 여러개의 level로도 표현할 수 있다. 아래 예시를 보자.

먼저 왼쪽 그림부터 보면, signal이 2개의 level로 구성되어 있다. 또한 1초에 8개의 비트를 보내기 때문에 8bps로 표현할 수 있다.

반면 오른쪽 그림을 보면, signal이 4개의 level로 구성되어 있다. 각각의 4개의 level을 모두 표현하기 위해 사용하는 bit 수가 2로 늘어났다. 따라서 1초에 보내는 bit의 수도 16bps가 된다.

전송속도 측면에서 보면 오른쪽 그림이 더 빠르지만, 디코딩 측면에서의 난이도를 생각하면 왼쪽의 경우가 더 쉽다. 따라서 여러 고려사항을 생각하여 적절한 선택을 하는 것이 중요하다.

Fourier analysis에 의하면 digital sinal은 곧 composite analog signal이다. 정확하게 어떤 의미인지는 설명해주시지 않았지만, 수학적으로 보면 digital sinal도 여러개의 sine wave를 합쳐서 만들 수 있기에 digital signal = composite analog signal로 해석할 수 있다고 한다. 그림을 보자.

왼쪽 상단의 그래프는 digital signal이다. 그리고 오른쪽 상단을 보면 이 signal이 Frequency영역에서 여러 개의 Fequency 성분으로 나타나는 것을 확인할 수 있다. 즉, 왼쪽 상단의 digital signal은 여러 sine wave들이 합쳐져서 만들어졌다는 뜻이다.

또한, 오른쪽 그림을 보면 Frequency 영역에 대하여 "..."으로 표현한 걸 확인할 수 있다. 이는, digital signal의 모서리가 수직에 가깝게 갑자기 변하는 변화를 표현하기 위해 무한히 높은 Frequency 성분이 필요하기 때문이다. 그냥 단순하고 직관적으로 수직으로 변하는 변화량은 Frequency가 무한대에 가까워져야 표현이 가능하다고 생각하면 될 것 같다.

Digital data를 channel에 보낼 때, 그냥 보낼 수도 있고, analog로 변환하여 보낼 수도 있다. 그러나 실제 transmission medium은 아무 signal이나 다 받아주는 게 아니다. 어떤 channel은 digital signal 그대로 보낼 수도 있고, 어떤 채널은 특정 주파수 대역의 analog signal만 잘 통과시킨다. 따라서 channel 종류에 따라 전송 방식이 달라진다.

Digital signal을 보내는 방법은 크게 2가지이다.

Baseband transmission
Digital signal을 그대로 보내는 방식이다. Bandwidth가 0부터 시작하는 channel에서 가능하다. 즉, 아주 낮은 주파수 성분부터 통과시킬 수 있는 channel이어야 한다.
Broadband transmission
Digital signal을 analog signal로 변환하여 보내는 방식이다. Bandwidth가 0부터 시작하지 않는 channel 즉, Bandpass channel에서 필요하다.

Broadband transmission에서는 digital signal을 channel에서 허용하는 Bandwidth 안으로 옮겨서 보내야 한다. 이 과정을 Modulation(변조)라고 한다.

Transmission Impairment

Signal이 transmission medium을 통해 전달될 때, 이 signal의 모양이 변화하게 된다. 이러한 손상을 Transmission Impairment라고 한다.

Impairment의 종류에는 크게 3가지가 있다.

먼저 감쇄(Attenuation)에 대해 알아보자.

Signal이 medium을 통해 전달되는 과정에서 medium의 저항에 의해 에너지를 잃게 되곤 한다. 이러한 에너지를 잃는 현상을 두고 감쇄라고 하며, 이를 해결하기 위해선 Amplifier를 두어서 감쇄된 에너지를 증폭하여 원본 signal의 에너지를 복원해야 한다.

다음은 Dsitortion에 대해 알아보자.

Distortion은 composite signal에서 발생하는 현상이다. Composite signal은 전송될 때 각각의 bandwidth에 해당하는 simple signal로 분리되어 전송되는데, 각각 서로 다른 propagation speed를 가지고 있기 때문에, phase가 달라질 수 있다. 이로인해 출발과 도착 지점에서의 signal의 모양이 변화하는 현상이 발생한다.

다음은 Noise에 대해 알아보자.

Noise란, 신호에 방해가 되는 대부분의 요소를 말한다.

데이터통신에서는 이 3가지 Impairment 중 특히 Noise에 더 집중하여 본다. SNR이라는 Signal에 대하여 얼마만큼의 Noise가 존재하는 지를 나타내는 SNR이라는 용어도 존재한다.

SNR이 크려면, Signal의 power가 강하고, Noise의 power가 약해야하므로, 기존의 signal이 어느정도 잘 유지되는 모습이다. 반면에, SNR이 작다면 원본 signal의 모양이 잘 유지가 되지 않는다.

Data Rate Limites

통신에서 가장 중요한 것은 속도이다. Data rate을 계산하기 위한 2가지 방법을 소개하는데, 하나는 Noise가 존재하지 않는 channel을 가정한 Nyquist의 공식이고, 하나는 Noise를 가정한 Shannon의 공식이다.

먼저 Nyquist 공식이다.

L은 digital signal의 level을 의미한다.

다음은 Shannon 공식이다.

Noise가 있는 것과 없는 것의 차이를 보면, 2를 곱해주지 않게 되고, level 대신 SNR을 사용하게 된다.

예시를 하나 들어보자. 1 MHz 크기의 bandwidth를 지니고, SNR이 63인 channel이 있다고 가정하자. 그러면 Shannon formula를 통해 최대 전송 속도를 구할 수 있다. 식으로 보면 다음과 같다.

해당 값은 최대 속도이므로, 약간 값을 낮추어 4 Mbps로 하여 Nyquist formula를 사용하면 digital signal을 전송할 때 정해야하는 level을 구할 수 있다. 물론 noise를 가정하지 않았을 때이다. 이를 식으로 보면 다음과 같다.

Perofrmance

데이터 통신에서 통신의 성능을 측정하는 척도가 되는 것이 뭐가 있을까?

먼저, Bandwidth이다. 우리가 기존에 배웠던 Bandwidth in hertz를 포함하여, bps를 Bandwidth로 표현하기도 한다. 보통은 Bandwidth in hertz의 크기가 커지면 보낼 수 있는 signal의 범위가 커지기 때문에 Bandwidth in bps도 함께 커진다.

다음은 Throghput이다. Bandwidth in bps가 의미하는 것은 잠재적인 최대의 속도를 의미하는 것이며, 실제 전송 속도는 Bandwidth와는 다르다. Througput은 실제 전송 속도를 의미하는데, 이는 전송 알고리즘에 의해 달라질 수 있다.

마지막으로 Latency, 즉 delay이다. Delay란, source에서 첫 bit를 보내기 시작한 순간부터, 전체 메세지가 destination에 완전히 도착할 때까지 걸리는 시간을 의미한다. 그리고 delay는 다음 네 가지 요소의 합이다.

Propagation time
Signal이 transimission medium을 통해 이동하는데 걸리는 시간이다. 거리가 멀어지면 propagation time이 커진다
Transmission time
메세지의 비트들을 채널에 밀어넣는 데 걸리는 시간이다. 파일이 크면 transmission time이 커진다.
Device processing time
Source에서 destination까지 여러개의 switch, router를 거칠 수도 있는데, 이때, 다음 경로를 구하는 데 걸리는 시간이다. 장비가 바쁘거나 복잡하면 processing delay가 커진다.
Queuing delay
Router에는 input과 output이 있는데, input이 꽉차게 되면 packet이 손실되고 하는데, 이 input의 대기 공간을 queue라고 한다. 이 queue에 대기하는 시간을 의미한다. 네트워크가 막히면 queuing time이 커진다.

예시를 하나 들어보자, 메세지를 보내는데, 다음과 같은 상황을 가정해보자.

메시지 크기 = 2.5 KB
Bandwidth = 1 Gbps
거리 = 12,000 km
전파 속도 = 2.4 x 10^8 m/s

이러한 상황에서 메시지는 짧고, Bandwidth가 매우 높기 때문에, transmission time보다는 propagation time이 더 지배적이다. 반대로, 메시지 크기가 크고 Bandwidth가 작은 경우를 가정해보자.

메시지 크기 = 5 MB
Bandwidth = 1 Mbps
거리 = 12,000 km
전파 속도 = 2.4 x 10^8 m/s

이 상황에서는 propagation time보다 transmission time이 더 지배적인 것을 확인할 수 있다.

[운영체제및실습] Week4. Thread

PiLove — Tue, 24 Mar 2026 19:37:44 +0900

충남대학교 류재철 교수님, 운영체제 및 실습 과목 4주차 정리입니다.

Preview

프로그램을 실행하면 OS는 process를 생성한다. 이 과정에서 새로운 프로그램을 실행하려면 기존 process를 fork()를 하게된다. 일반적인 프로그램이라면 fork()를 하고 exec()을 하는 것만으로 충분하지만, 게임 같은 프로그램의 경우에는 동일한 데이터(맵 정보, 캐릭터 위치, 아이템 상태 등)를 서로 다른 process가 공유하며 실시간으로 처리해야 한다. 따라서 이러한 경우 process는 서로 독립된 메모리 공간을 가지므로 통신이 필요해진다. 이를 해결하기 위해 공유가 필요한 메모리 공간은 공유하고, 나누어야 할 부분은 나누어 작업하는 thread가 탄생하게 되었다.

Thread

Thread란 무엇일까? Thread란 일종의 실행흐름을 의미한다. 한 process 내에서 새로운 thread가 만들어지면, 새로운 작업이 시작되며 새로운 실행흐름이 만들어진다. 이게 어떤 도움이 될까?

우리가 1부터 1000조까지 더하는 작업을 수행한다고 가정하자. 연산량이 꽤 많이 들을 것이다. 이것을 single process에 single thread로 해결하려고 하면 이 모든 연산량을 하나의 실행흐름으로 감당해야 한다. 그러나, single process에 multi thread로 해결한다고 하면, 여러개의 실행흐름을 통해 연산량을 n개의 thread로 나누어 처리할 수 있게 된다. 이는 곧 실행 속도도 약 n배 빨라진다고 볼 수 있다.

Process가 생성되면 위와 같은 그림처럼 OS가 PCB, 그리고 메모리 맵을 할당해준다.

Process와 Thread의 생성에서 큰 차이점은 바로 thread는 stack만 독립된 메모리 공간으로 할당하고, PCB, HEAP, DATA, CODE를 공유한다는 점이다.

이로 인해 얻을 수 있는 효과는 무엇일까? Process의 종류에 따라 시간이 오래 걸리거나 여러 host가 필요한 작업의 경우, 공유가 필요한 작업은 공유하고 그 외에 작업은 병렬적으로 실행이 가능하다는 것이다. 위 사진에서 HEAP, DATA, CODE는 각 thread가 모두 공유하고 있다고 생각하면 된다.

위 그림은 RPC Request를 2번 수행하는 process를 2개의 thread로 병렬적으로 작업하였을 때 얻을 수 있는 효과를 나타낸 그림이다. Thread를 2개 실행하게 되면서 RPC Request를 병렬적으로 한번에 2개를 처리하게 되어, 약 2배 빠른 성능 향상을 체감할 수 있다. 다만 주의해야할 점은, processor가 코어가 하나뿐이 uniprocessor이므로, thread B가 RPC Request가 끝난 이후 종료를 위해 processor를 점유하게 되면 thread A는 잠시 wait해야 한다는 점이다.

여기서 의문이 들 수 있는 점이.. thread의 장점이 병렬성인데 processor를 사용하는 작업은 병렬적으로 처리하는 것이 불가능하다는 것이다. 사실 이는 ULT와 KLT에 대해 알면 이해하기 쉬우니 우선은 넘어가고 뒤에서 정리하도록 하겠다. 아무튼 코어가 하나뿐인 uniprocessor라서, processor를 사용하는 작업이 병렬적으로 처리하기 어렵다는 것만 알아두자.

Uniprocessor를 기준으로 multi thread의 동작을 설명한 그림이다. 역시나 processor를 사용한 작업에 대해 병렬적으로 처리하는 모습은 보이지 않는다.

Thread의 실행

Process가 생성될 때를 기억하는가?

fork()
PCB 생성, 메모리맵 생성
exec()
CPU 스케줄러가 인식=
Dispatcher가 CPU를 할당하여 process 실행

위 과정처럼 thread 또한 생성되는 데에 꽤 복잡한 과정을 거친다.

clone()
TCB 생성, 독립적인 Stack 할당
CPU 스케줄러가 인식
Dispatcher에 의해 CPU 할당

Multi thread의 문제

Multi thread의 장점은 지금까지 많이 알아보았다. 그러나 multi thread를 사용할 때 유의해야 하는 점이 있는데, 바로 race condition이다.

Race condition이란, 여러 thread가 같은 공유 데이터, 즉, PCB, CODE, HEAP, DATA 영역에 동시에 접근하게 되어, 실행 순서에 따라 결과가 달라지는 문제를 의미한다. 이름 그대로 thread끼리 race를 하게 되는 경우이다.

예시로 은행을 생각해보자. 계좌 잔액이 10,000원이라고 하자. 두 thread가 완전 동시에 1,000원을 인출하게 되면 계좌 잔액이 8,000원이 되어야 하는데 9,000원이 되어버린다.

이를 해결하기 위한 방법이 mutext이다. mutex는 mutual exclusion의 줄임말이다. 뜻은 그 이름 그대로 thread끼리 상호 간에 배제하는 것이다. 즉, 공유하는 데이터에 대하여 한 번에 하나의 thread만 들어오게 막는 장치이다.

다시 은행을 예시로 들어보자. Thread A가 잔액을 수정하기 전까지는 lock을 획득하고 작업을 수행한다. 그리고 끝나면 unlock하는 것이다. 이러면 thread B는 lock이 풀릴 때까지 기다렸다가 작업을 수행해야 한다.

그런데 또 mutex를 무조건 많이 쓰는 게 좋지만도 않다. 왜냐하면 lock을 걸면 다른 thread가 기다려야 해서 병렬성이 줄어들 수 있기 때문이다. 즉, 안정성은 올라가는 대신 성능이 떨어질 수도 있다.
또한 deadlock 문제가 발생할 수 있다. 만약 공유 자원에 정말정말 동시에 들어가게 되면 두 thread가 한번에 lock을 잡게 되는 경우도 있다. 이러한 경우 두 thread가 상대 thread의 unlock을 기다리면서 영원히 멈출 수 있다. 이러한 경우를 deadlock이라고 한다.

[데이터통신] Week4-5. Networks Model

PiLove — Mon, 23 Mar 2026 22:16:25 +0900

충남대학교 김기일 교수님, 데이터통신 4~5주차 정리입니다.

데이터통신에서 layer(계층)란 무엇일까?

통신은 그 과정이 매우 복잡하다. 여러 과정을 거쳐서 수신자와 송신자가 데이터를 교환하게 된다. 만약, 이 과정들을 한번에 처리하려고 하면 어떨까? 과정이 복잡하다보니 특정 기능을 개발하거나 수정하려다가 다른 기능에까지 영향을 줄 수 있다. 따라서 복잡한 과정을 여러 개의 작은 단계로 나누어 모듈화하여 관리하는 방식으로 통신을 진행하게 되었다. 이를 layer(계층)라고 한다.

Protocol Layering

Protocol이란, 송신자와 수신자 그리고 router, switch 등의 장치들이 따라야 하는 일종의 규칙을 의미한다. 통신이 단순하다면 하나의 protocol을 정의하는 것으로 충분하겠지만, 복잡한 통신은 각 layer마다 protocol이 필요하다. 이를 Protocol layering이라고 한다. 통신을 위한 네트워크에서는 "누가 먼저 말할지", "주소를 어떻게 적을지", "오류가 나면 어떻게 처리할지" 등과 같은 규칙이 필요하다.

간단한 예시를 들어, 마리아와 앤이 통신을 한다고 가정하자.

이 둘은 거리가 가까워서 공기를 매개로 말이 곧잘 전달된다. 즉, 이러한 단순한 통신에서는 추가적인 layer없이도 single layer로 충분하다는 의미이다.

Single layer에서도 protocol은 존재한다. 예를 들어, "만나면 인사를 한다", "관계 수준에 맞는 어휘를 사용한다", "말을 자르지 않는다" 등 마리아와 앤이 암묵적으로 스스로 생각하고 있는 일종의 마지노선, 즉 protocol이 존재한다. 통신에는 layer의 깊이에 상관없이 항상 protocol이 존재하는 것이다.

이번엔 "우편"을 이용한 통신을 예로 들어보자. 대면으로 통신을 하는 경우와 비교하여 통신이 복잡해졌다. 일종의 시나리오를 생각해보자. 마리아와 앤은 우편을 통한 통신을 하기 때문에, 첫번째로 우편을 작성하는 기능이 필요하다. 이를 가장 상위 layer가 될 것이다. 두번째로 마리아와 앤을 제외한 다른 사람이 이 우편을 읽지 못하게 하기 위한 Encrypt/Decrypt(암호화/복호화) 기능이 필요하다. 이는 그 다음 layer가 될 것이다. 마지막으로는 암호화를 완료한 우편을 상대방에게 전달하기 위한 전달 기능이 필요하다. 이게 마지막 layer가 될 것이다.

이를 단계별로 정리하면 다음과 같다. 마리아가 송신을 하고 앤이 수신을 한다고 가정하자.

먼저 마리아의 경우이다.

마리아가 layer 3에서 plain text(우편)을 작성한다.
layer 2에서 plain text를 Encrypt하여 ciphertext(암호문)을 생성한다.
layer 1에서 이 ciphertext를 봉투에 넣고 주소를 써서 앤측으로 발송한다.

이제 앤의 경우이다.

layer 1에서 수신받은 봉투에서 ciphertext를 꺼낸다.
layer 2에서 이 ciphertext를 Decrypt하여 plaintext를 생성한다.
layer 3에서 앤이 이 내용을 읽고 통신을 완료한다.

이렇게 알 수 있듯이, 각각의 layer는 서로다른 작업을 수행한다. 따라서 각 작업별로 유지보수 및 수정이 용이하다. 예를들어, 마리아와 앤이 Encrypt/Decrypt 하는 과정이 다른 사람에 공유되어서 다른 사람이 마리아의 우편을 볼 수 있게되었다고 가정하자. 이러한 경우에, 통신 전체를 손볼 것이 아니라 Encrypt/Decrypt 즉, layer 2만 변경해도 된다.

위 그림에서 아직 설명 안한 부분이 마리아와 앤이 가지는 각각의 layer는 서로 logical connection을 가진다. 실제 데이터(우편)는 가장 낮은 계층을 통해 이동하지만, 논리적, 개념적으로는 같은 layer끼리 통신하는 것처럼 본다.

Layer 3에서는 plaintext를 기준으로 logical connection, layer 2에서는 ciphertext를 기준으로, layer 1에서는 mail을 기준으로 connection이 있다고 보는 것이다.

이 그림은 인접한 layer 사이의 관계를 나타낸 그림이다. 송신을 기준으로 설명하면, N+1 layer에서는 데이터를 provide하고, N layer에서는 그 데이터를 use한다. 반대로 수신을 기준으로 설명하면, N layer에서 데이터를 provide하고, N+1 layer에서 그 데이터를 use한다.

TCP/IP Protocol Suite

흔히 잘 알고있는 Internet에서 사용하는 protocol이 바로 TCP/IP Protocol이다.

해당 protocol은 자료에 따라서 4개의 layer로 보기도 하고, 5개의 layer로 보기도 한다. 수업에서는 오른쪽 그림으로 설명해주셨다.

위와 같은 구조를 가지는데... 실제로 TCP/IP는 두 host 사이의 통신을 어떻게 제어하는지 확인해보자.

이 그림은 A와 B라는 host가 TCP/IP를 이용하여 통신하는 과정을 나타낸 그림이다. A와 B는 서로 다른 네트워크에 존재한다. 그렇다면 어떻게 통신이 가능할까? Switch와 router 덕분이다. Switch는 같은 네트워크 내의 서로 다른 LAN을 연결하는 역할을 한다. 그리고 router는 이러한 switch들은 연결하여 서로 다른 네트워크를 연결하는 역할을 한다.

이제 TCP/IP의 각 layer에서 정확히 어떤 일을 하는 지 알아보자. 이 과정에서 switch와 router의 layer가 A와 B의 layer 보다 적은 이유도 알아볼 것이다.

Physical layer :
말 그대로 물리적인 매체를 통한 송수신 기능을 수행한다. 케이블, 전압, 주파수, 광신호 같은 진짜 물리 매체를 통해 0과 1을 실제 신호로 바꿔 보내게 된다.
Data link layer :
Physical layer에서 송수신한 데이터에 오류는 없는지 검출 및 처리하는 기능을 수행한다.
Network layer :
Host와 host 사이를 연결하는 layer로 중간에 router가 있을 경우, router의 Network layer에서 최적의 루트를 찾아주는 기능을 수행한다.
Transport layer :
Network layer에서의 error를 control하는 역할을 수행한다.
Application layer :
Host가 실제로 사용하는 웹 브라우저, 이메일 등의 프로그램을 의미한다.

이렇게 각각의 layer는 서로 다른 기능을 수행하며, 다루는 데이터의 단위도 달라진다.

각 layer에서 데이터를 provide, use하는 과정을 이해하기 위해선 packet에 대해서도 알아야 한다.

Packet은 상위 layer(N+1)에서 하위 layer(N)에 보낸 data와 layer(N)에서 다음 layer (N-1)에 필요한 추가적인 정보인 header를 더하여 만들어진다. 이러한 과정은 physical layer에 도달하기 전까지 모든 인접한 layer에서 이루어진다.

그림은 data에 header가 계속해서 붙고, 제거되는 과정을 나타낸 그림이다.

송신자 측에서는 상위 계층에서 하위 계층으로 데이터를 전달하기 위해 필요한 정보를 header에 계속해서 추가하고 전달하게 되고, physical layer에서는 이러한 packet을 router에 전달하게 된다.

Router에서는 입력받은 packet에 대하여 각각의 layer에 해당하는 header를 읽고 제거한다. Data link lyaer에서는 2번 header를 읽고 data link layer 사이의 protocol에 맞게 header에서 읽은 정보를 토대로 특정 action을 수행한다. 이후 header를 벗겨서 상위 layer로 packet을 전달한다. Router의 network layer에서는 network header를 확인하여 다음 경로를 결정한다. 이후 packet은 하위의 data link layer로 전달되고, data link layer에서는 다음 link에 맞는 새로운 data link header를 추가한다. 그리고 이 packet은 physical layer로 전달되어 비트를 전송하게 되고 수신자 측으로 전달된다.

수신자측에서는 physcial layer를 통해 들어온 packet을 상위 layer로 전달하고 각 layer에 맞는 header를 읽고 해당 layer에 정해진 protocol에 맞게 header에서의 정보를 토대로 특정 action을 수행한다. 그리고 읽은 header는 제거하여 상위 layer로 전달한다. 가장 마지막 상위 layer에서는 전체 header가 제거된 message를 확인할 수 있다.

상위 layer에서 하위 layer로 데이터를 보낼 때 header로 감싸는 과정을 Encapsulation, 하위 layer에서 상위 layer로 데이터를 보낼 때 header를 제거하는 과정을 Decapsulation이라고 한다.

또한 각 layer에서 다음 layer로 packet을 전달하기 위해 사용하는 address가 존재한다. Physcial layer의 bit 자체는 주소를 가질 수 없기 때문에 보통 4종류의 address를 가정한다. 각각의 layer마다 address가 존재하는 이유는, layer마다 수행하는 작업이 다르기 때문이다.

예를 들어, Application layer에서는 "어떤 서비스/이름을 찾는가"가 중요해서 Names라는 address를 사용하고, Transport layer에서는 "그 컴퓨터 안의 어떤 process인가"가 중요해서 port number를 사용한다. Network layer에서는 "어느 호스트까지 갈 것인가"가 중요해서 logical address(IP 주소)를 사용하고, Data link layer에서는 "지금 이 링크에서 바로 누구에게 넘길 것인가"가 중요해서 link layer address(MAC 주소)를 사용한다. Physical layer에서는 변환한 bit 신호 자체를 보내는 layer이기 때문에 주소를 따로 두지 않는다.

TCP/IP protocol의 또 하나의 장점 중 하나가 바로 Multiplexing/Demultiplexing 기능이다. Application layer에는 다양한 protocol이 존재한다. FTP, HTTP, ... 또는 DNS, SNMP, ... 등, 이러한 다양한 protocol이 공통으로 사용가능한 protocol이 존재한다. 그게 바로 Transport layer의 protocol인 TCP/UDP이다.

Application layer의 다양한 protocol을 Transport layer의 TCP/UDP로 모으고, TCP/UDP는 IP라는 Network layer의 protocol로 모이게 되어 하위 layer로 전달된다. 이 과정을 Multiplexing이라고 한다.

Demultiplexing은 수신 측에서 하위 layer의 하나의 protocol이 받은 데이터를 해석하여, 그것을 알맞은 여러 상위 layer의 protocol 중 하나로 올려 보내는 과정이다.

한 컴퓨터는 동시에 여러 프로그램이 네트워크를 사용할 수 있으므로, Applcation layer에서 서로 다른 protocol을 사용할 수도 있다. 따라서 Multiplexing/Demultiplexing을 통해 충돌없이 통신할 수 있게 하는 것이 중요하다.

OSI Model

OSI 모델은 위와 같은 구조로 7개의 layer로 이루어져 있다. TCP/IP와의 차이점으로는 TCP/IP의 Application layer를 3개의 layer로 나누었다는 점이다. OSI의 Presentatino layer에서는 Encryption(암호화)/Decryption(복호화) 작업을 수행하게 되고, Session layer에서는 통신 대상과의 session(대화 흐름)을 관리한다.

두 모델이 등장한 순서를 생각해보면, OSI 모델이 나중에 나왔기 때문에 보통은 단점을 보완한 OSI 모델을 사용하지만, 다음과 같은 이유때문에 현재에도 TCP/IP 모델을 사용한다.

OSI가 나왔을 때 TCP/IP가 이미 자리 잡았고, 매몰된 시간과 비용이 많아서 바꾸기에는 큰 부담이 들었다.
OSI의 일부 계층, 특히 presentation과 session 계층의 서비스에 대해 그 정의가 충분히 구체적이지 못했다.
성능 상 큰 차이가 없었다.

즉, 이론적으로는 깔끔했지만, 실용성이 부족했다는 점이다. 따라서 OSI는 이론적으로 계층 구조를 더 세밀하게 바라보게 해주는 참조 모델 정도로 이해하고 넘어가면 된다.

[C언어] 포인터 (매우) 간단하게 정리, Makefile 기본

PiLove — Wed, 18 Mar 2026 19:42:11 +0900

휴학하고 파이썬만 다루었더니 C는 다 까먹었다. 간단하게만 정리해두고 간간히 보자.

포인터

선언에서 * : 주소를 저장하는 포인터 변수 (int *p = )
사용(우변)에서 * : 해당 변수의 주소에 존재하는 값 반환 (a = *p)
사용(우변)에서 & : 해당 변수의 주소 반환 (int *p = &b)
배열 : 배열의 이름 자체가 주소처럼 동작(첫 번째 인덱스 주소)

Makefile

CC = gcc
CFLAGS = -pthread
TARGET = DC_03_hw
SRC = DC_03_hw.c

all:
	$(CC) $(SRC) -o $(TARGET) $(CFLAGS)

clean:
	rm -f $(TARGET)

CC : 사용할 컴파일러
SRC : 컴파일할 소스코드 파일
TARGET : 컴파일 후 파일 이름
CFLAGS : 컴파일 할 때 추가할 옵션

"make" 로 바이너리 코드 파일(실행 파일) 생성, clean으로 삭제

[데이터통신] Week3. Introduction(2) & Networks Model overview

PiLove — Mon, 16 Mar 2026 23:13:01 +0900

충남대학교 김기일 교수님, 데이터통신 3주차 정리입니다.

지난 시간에 LAN은 각각의 호스트들이 모여 만들어지고, WAN은 switch, router 같은 connection device가 모여 만들어진다고 배웠다. 이번 시간에는 이러한 switch, router가 어떤 기능을 수행하는 지와 Internet에 대해 간단하게 알아보려고 한다.

Switching

internet이란 여러 네트워크가 연결된 switched network이다. Switch는 적어도 두 개 이상의 네트워크를 연결한다. 이렇게 한 네트워크에서 다른 네트워크로 데이터를 전달하는 기술이 switching이다.

Switching에는 Circuit Switching과 Packet Switching 2개 종류가 있다.

Circuit Switching의 구조는 host와 host 사이에 switch를 통해 하나의 고정된 회선으로 전용 경로를 설정하여 통신을 한다. 통신 전에 두 단말 사이에 전용 경로를 먼저 설정하고, 통신 중에는 해당 경로를 계~속 사용한다. 이 과정에서 해당 경로의 대역폭이 예약되기 때문에 다른 통신이 그 자원을 사용하지 못한다.

Packet Switching는 host와 host 사이에 router를 통한 링크를 통해 동적인 경로로 통신을 한다. 라우터를 사용하여 데이터를 packet 단위로 나누어 queue에 저장 후 전송한다. 동적으로 경로를 찾기 때문에, 전송 과정에서 데이터를 어떤 경로로 전송하는 게 빠른지 계산하는 알고리즘이 필요하다.

지난 시간에 배웠던 Jitter를 생각해보자... Circuit Switching 같은 경우는 Jitter가 even하게 들어올 것이다. 반면 Packet Switching은 데이터 전송 과정에서 router의 queue에서 packet이 대기하면서 delay가 달라지기 때문에 Jitter가 uneven하게 들어올 것이다. 그렇다면 Packet Switching은 왜 굳이 사용하는 걸까?

바로 자원의 효율성 때문이다. Circuit Switching은 회선을 독점 사용하는 반면, Packet Switching은 네트워크를 여러 사용자가 공유한다. 예를 들어, A, B, C, D가 있다고 하자. A와 B 사이에 Circuit Switching 방식을 통해 회선을 점유하고 있으면, C, D는 해당 회선을 사용할 수 없다. 반면에 Packet Switching을 사용하게 되면, A -> packet, B -> packet, C -> packet, D -> packet 이런 식으로 같은 링크를 여러 사람이 사용하여 데이터를 전송할 수 있다.

Internet

internet이란, 두 개 이상의 네트워크가 연결된 구조를 말한다. 이러한 internet 중 가장 주목할만한 internet이 바로 Internet이다. Internet은 수천개 이상의 네트워크로 구성된다.

오늘 날 Internet의 구조는 다음과 같다. 우리가 흔히 사용하는 wifi는 Customer network에 해당한다. 이러한 Customer network가 여러 개 묶여 Provider network라고 부르고, 이러한 Provider network가 모여 Backbone을 구성한다. Backbone은 모든 network의 상위 계층으로, 이러한 계층 구조에서 상위 계층에 있는 네트워크일수록 신뢰성과 속도가 중요하기 때문에 Mesh topology를 사용하는 것이 좋다고 한당.

[운영체제및실습] Week2. Operating System Overview

PiLove — Tue, 10 Mar 2026 20:41:00 +0900

충남대학교 류재철 교수님, 운영체제 및 실습 과목 2주차 정리입니다.

OS, Computer System의 발전과정

Serial Processing
과거엔 컴퓨터가 귀해서 10~11, 11~12, 12~13... 이런 식으로 여러 사용자가 시간을 나누어 컴퓨터를 사용했다. 이렇게 컴퓨터를 사용하다보니, 작업이 일찍 끝나거나 초과하게 되면 CPU가 놀게되고 다음 사용자가 대기해야하는 일이 빈번했다.
Batch Processing
따라서 여러 사용자들의 작업을 한번에 수행하기 위해 Batch Processing이 생겼다. 이제 개발자들은 컴퓨터에 작업을 모두 모아 순차적으로 실행함으로써 CPU가 노는 시간을 절약할 수 있게 되었다. 참고로 Main Memory 내에 Monitor 라는 OS의 시초격인 프로그램을 저장하여 하나의 프로그램의 시작과 끝을 확인하고 각각의 프로그램을 구분하여 실행할 수 있었다.
이후, Punch 카드 형태의 입력기에서 키보드와 하드디스크가 개발되며 프로그램을 실행하기 위한 여러 준비과정이 생략되었다.
Multi Programming
Main Memory에 2개 이상의 프로그램을 올리는 것을 말한다. 2개 이상의 프로그램을 Main Memory에 올렸을 뿐이지, 두 프로그램이 동시에 실행되지는 않는다.
Time Sharing
Main memory에 2개 이상의 프로그램이 올라갔는데, 만약 프로그램1이 계속 실행되고 있다면 프로그램2는 실행되지 않을 것이다. 이러한 문제를 방지하고자 일정 제한 시간을 둠으로써, OS가 일정 시간이 지나면 프로그램1의 실행을 멈추고 프로그램2를 실행한다. 이를 Context Switching이라고 한다.
Multi Processing
이제는 2개 이상의 Processor를 가지고 병렬적으로 프로그램을 실행할 수 있게 되었다.
Parallel Processing
프로그램 하나를 2개 이상의 Processor로 돌리는 것을 말한다. 그러나, 프로그램을 2개의 Processor로 돌리기 위해선 프로그램 코드를 작성하는 데에 있어서 어려움이 있다.
Distributed Computing
컴퓨터는 지금까지 빠른 속도를 추구하며 발전해왔다. 이 당시 네트워크가 보급되며, 한 컴퓨터의 자원을 다른 컴퓨터가 사용할 수 있도록하면 더 빠른 속도로 작업을 수행할 수 있지 않을까? 하는 아이디어로 나타났다. 그러나 서로 다른 H/W 환경으로 인해 큰 효과를 얻지는 못했다. 지금은 다른 방향으로 활용하고 있다고 한다.
Cloud Computing
오늘 날 사용하는 중앙 집중화된 컴퓨팅 작업 환경이다. 클라우드 서비스를 통해 큰 서버를 대여하여 활용할 수 있다.

OS Overview

사용자가 command를 입력하면, command interpreter가 명령어를 해석하고, 이에 해당하는 system call을 가져다가 instruction으로 H/W에 전달한다.

이를 자세히 정리하면 아래 사진과 같다. Application programs를 통해 명령어가 들어오고, Command Interpreter를 통해 OS가 System call을 불러서 Instruction으로 H/W에 전달한다.

%edit myfile.txt 라는 명령어에 대해 어떤 과정을 거치는지 알아보자.

keyboard device driver
command interpreter
명령어를 해석
loader editor
editor라는 프로그램을 하드디스크에서 찾아서 메인메모리로 로드
editor process creation
- fork() system call
CPU scheduling
file open() system call
editing
file close() system call
exit() system call

System call이 발생하면 CPU는 메인 메모리에 존재하는 IDT(Interrupt Descriptor Table)를 조회하여 해당 system call을 처리하는 handler로 제어를 넘긴다. 이후 system call handler가 system call 번호를 기반으로 system call table을 참조하여 실제 system call 함수를 실행한다.

시스템 프로그래밍, 컴퓨터 구조 시간에 배웠던 내용인 것 같은데... 휴학하고 오니까 다 까먹었다... 열심히 해야겠다.

[데이터통신] Week2. Introduction

PiLove — Tue, 10 Mar 2026 00:03:57 +0900

충남대학교 김기일 교수님, 데이터통신 2주차 정리입니다.

Data Communcations

데이터통신이란, local 또는 remote로 정보를 교환, 공유하는 행위를 말한다. 정보 교환의 주체는 2개 이상의 디바이스이며, 이들은 전송 매체를 통해 정보를 교환한다.
데이터통신 시스템의 유효성은 다음과 같다.

Delivery : 시스템은 반드시 데이터를 정확한 목적지에 전달해야 한다.
Accuracy : 시스템은 데이터를 손실없이 정확하게 전달해야 한다.
Timeliness : 시스템은 데이터를 정해진 시간 내에 전달해야 한다. 오디오나 비디오의 경우, 데이터가 생성되는 즉시 순서대로 지연없이 전달되는 것을 의미하는데, 이러한 종류의 전달을 실시간 전송(real-time transmission)
Jitter : Jitter란 오디오나 비디오 패킷을 전송하는 과정에서 지연 시간이 일정하지 않게(uneven) 변하는 현상을 의미한다. 예를 들어, 비디오 패킷이 30ms 간격으로 전달되어야 할 때 첫 번째 패킷은 30ms에 정상적으로 도착하지만, 두 번째 패킷은 40ms, 그 다음 패킷은 35ms에 도착하는 등 도착 시간이 일정하지 않게 변하는 경우를 Jitter라고 한다.

그림을 보면, Jitter를 포함한 데이터 통신과 포함하지 않은 데이터 통신의 차이를 확인할 수 있다. 개발자는 Jitter를 포함한 데이터통신을 사용자가 느끼지 못하도록 만들어야 한다.
Example of problem을 보자. Perfect Stream의 경우에, 데이터가 "ㅁ ㅁ ㅁ ㅁ ㅁ ㅁ" 이런식으로 균등하게 들어오는 반면, Stream with Jitter는 데이터가 "ㅁㅁ ㅁㅁ ㅁ" 이런 식으로 균등하지 않게 들어온다. 또한 예시에서처럼 버퍼가 충분히 할당되지 않은 상황에서 Jitter에 의해 데이터가 한번에 들어오게 되면 오버플로우가 발생할 수 있다.
따라서 개발자는 Stream with Jitter를 사용자가 Perfect Stream으로 체감할 수 있도록 버퍼를 잘 조작해야 한다. 그림의 Playout buffer를 보면 버퍼에 들어오는 데이터를 바로 처리하지 않고, 일정량의 데이터가 차는 경우 처리하는 방식으로 사용자가 Jitter의 발생을 경험하지 않도록 만든다.

데이터통신은 다음과 같은 구성요소를 가진다. 2개의 디바이스(Sender, Receiver)와 데이터(Message), 데이터를 전달하기 위한 전송 매체(Transmission medium), 그리고 통신에 사용되는 규칙인 프로토콜(Protocol)로 이루어져 있다.

데이터통신은 데이터가 흐르는 방향에 따라 단방향(Simplex), 반이중(Half-duplex), 전이중(Full-duplex) 통신으로 구분할 수 있다. 반이중 통신은 한쪽에서 데이터를 보내면 반대편에서는 데이터를 보내지 못하는 반면, 전이중 통신은 동시에 데이터를 보낼 수 있다.

Networks

네트워크란, 통신에 사용가능한 디바이스 집합의 연결을 의미한다. 이 집합에는 컴퓨터, 노트북, 핸드폰 등에서부터 데이터의 형태를 변경하는 라우터, 스위치, 모뎀까지 모두 포함된다.
이러한 네트워크를 평가하는 기준은 다음과 같다.

Performance : 전송속도, 반응시간, 처리량, 지연시간 등으로 평가
Reliability : 전송 실패의 빈도, 실패 후 데이터 처리 시간, 고장난 상태에서 네트워크의 견고성 등으로 평가
Security : 허용되지 않은 접근으로부터 데이터를 보호, 해킹으로부터의 보호, 보안 침해나 손실이 발생했을 때 복구를 위한 절차를 구성하는 것으로 평가

위 평가 기준으로 여러 형태의 네트워크를 살펴보자.

Performance를 기준으로 보면, a(Point-to-point) 방식은 2개의 디바이스가 직접적으로 데이터를 교환하기 때문에 여러 디바이스가 데이터를 공유하는 방식인 b(Multipoint)보다 빠르다.
Reliability를 기준으로 보면, a는 구조가 단순하기에 고장이 발생할 경우 그 원인을 파악하기 쉽다. 반면 b는 Mainframe에서 고장이 발생할 경우, 다른 여러 디바이스에도 영향을 줄 수 있다.
Security를 기준으로 보면, a는 구조가 단순하여 두 디바이스만 데이터를 공유하기에 데이터가 노출될 가능성이 낮다. 반면 b는 하나의 링크를 여러 디바이스가 공유하므로 다른 디바이스가 데이터에 접근할 가능성이 높다.
그렇다면, b는 대체 왜 쓸까? 그림에서 a 네트워크의 디바이스 개수를 늘려보자. Link의 개수가 매우 늘어날 것이다. 반면에 b는 여전히 하나의 Link만 사용한다. 즉, 비용적인 측면에서 b가 월등히 좋다.

a 네트워크의 디바이스 개수를 5로 늘리면 다음과 같아진다. 디바이스 개수를 n이라고 하면, Link의 개수는 n(n-1)/2가 된다. 이러한 네트워크 구조를 mesh topology라고 부른다.

하나의 Hub를 여러 대의 디바이스가 공유하는 형태이다. Performance 측면에서도, Security 측면에서도 Point-to-point 방식과 비슷한 점수를 줄 수 있다. 그러나, Reliability를 따져보자. Hub가 고장나게 되면, 다른 모든 디바이스에 영향을 주기 때문에 네트워크의 견고성이 부족하다고 할 수 있다. 이러한 형태의 네트워크를 Star topology라고 한다.

처음에 봤던 b 와 동일한 네트워크 형태이다. Performace, Reliabitlity, Security 모두 좋지 않지만, 비용적인 측면에서 만큼은 매우 좋다.

Bus topology에서 cable의 끝과 끝을 연결한 형태이다. 솔직히 이렇게 해서 뭐가 달라지는 지 잘 모르겠다.

Network Types

위에서 네트워크의 형태에 따라 물리적 구조(topology)를 결정했다면, 이번에는 네트워크의 크기, 지리적 범위 등을 고려하여 종류를 구분해보자.

LAN(Local Area Networks)

교실, 집, 캠퍼스 정도의 크기에서 주로 사용되는 네트워크이다.
LAN 내에 있는 PC, 프린터, 핸드폰 등의 호스트는 identifier(식별자) 즉, address(주소)를 가지며, 이 address는 LAN 내에서 해당 호스트를 고유하게 구별한다. 참고로, LAN에서는 이 identifier로 MAC Address를 사용하고, WAN에서는 IP를 사용한다고 한다. 아마 이건 다음 시간에 더 자세히 알아보지 않을까 싶당.
LAN 내에서 한 호스트에서 다른 호스트로 데이터를 보낼 때, Source address(출발지 주소)와 Destination address(도착지 주소)가 모두 포함된다. 추가로 Destination address가 잘못 도착했을 때, 이 정보를 이용하여 개발자가 지정한 프로토콜에 따라 데이터를 삭제하는 등의 방식으로 처리할 수 있다.

WAN(Wide Area Network)

도시, 주, 심지어 국가 단위까지 사용 가능한 네트워크이다.
LAN은 보통 호스트들을 서로 연결하는 반면에, WAN은 Switch, Router, Modem 등의 연결장치(Connecting device)를 연결한다. 또한 LAN은 일반적으로 이를 사용하는 조직이 개인적으로 소유하지만, WAN은 보통 통신 회사가 구축하고 운영하며, 이를 사용하는 조직이 임대하여 사용한다.

WAN 내부에 여러개의 switch가 있는 경우, 다음과 같은 형태로 네트워크를 디자인한다. 여러 LAN 네트워크를 서로 연결한다는 측면에서 성능, 신뢰성, 보안 모두 중요하기 때문에 Mesh topology 를 사용하여 디자인 하는 것이 효율적이다.

Internet History

Standards

[모각코] 회고

PiLove — Sun, 22 Feb 2026 22:03:20 +0900

시간이 흘러 어느덧 개강을 앞두고 있다. 25년 12월 말에 시작한 모각코도 저번주 금요일을 마지막으로 종료되었다.

처음 시작을 돌이켜보면 정말 이유없이 의기양양했던 것 같다. '개강 전에 공부 좀 하면 좋지 않을까?' 하는 단순한 마음가짐과 함께 친구들을 모았고 그렇게 시작했었다. 목표는 ADP 필기 시험 합격이였다. 이렇게 동기는 약한데 목표는 높게 잡으니 내 목표에 맞게 계획을 수립하는 것과 그 계획을 따라가는 게 매우 힘들었다. 자격증 자체도 정보가 많지 않아 하나하나 찾아가며 계획을 수정하고 정말 힘들었다... 알바를 병행하면서 공부를 하는 것도 처음이라 더더욱 그랬다. 그렇게 2주차까지는 열심히 공부했지만, 공부해야하는 양도 너무 방대했고, 알바하고 오면 몸이 너무 지쳐서 쉬는 일들이 발생하는 바람에 눈덩이처럼 해야하는 숙제가 늘어갔다. 결국 처음 계획으로 했던 ADP 필기를 포기하게 되었다.

3주차부터는 ADP 대신 토익 공부를 목표로 세웠다. 토익 공부는 계획을 너무 촘촘하게 짜지는 않았다. 2주차까지 세웠었던 미련하고 무식한 계획 덕분에 내가 알바와 공부를 병행하면서 버틸 수 있는 스트레스가 어느정도인지 대충 알았기 때문이다. 계획을 너무 구체적으로 세분화하기 보다는 일주일 단위로 총 해야하는 공부량을 정해서 진행했다. 덕분에 토익 준비는 나쁘지 않게 한 기분이다.

이번 모각코에 대해서는 좀 아쉬운 점이 많았다. 내가 모은 팀원들인데, 시작하고 2주만에 먼저 지쳐서 팀원들에게 큰 신경을 써주지 못한 느낌이다. 또한 팀원들이 서로 어색해보였는데, 이 부분도 노력했지만 잘 해소가 되지 않은 것 같다. 결국 팀원들도 하나 둘 지쳐서 어느순간부터는 결석을 많이 하게 되는 것 같았다... '모각코'라는 단어가 '모여서 각자 코딩'이란 뜻이고 서로 공부하는 내용도 다르지만, 결국 팀 단위로 진행하는 것이기 때문에 팀원들과의 소통 부분에서 너무나 아쉬운 것 같다.

[모각코 - 5, 6회차] 토익

PiLove — Fri, 13 Feb 2026 21:44:18 +0900

5회차까지 토익 기출 보카를 Day1~5까지 외웠다. 그리고 750+ 교재의 LC 파트를 한번 빠르게 훑었다.

6회차에는 토익 기출 보카를 Day6~10까지 외웠다. 그리고 750+ 교재의 RC 파트를 한번 빠르게 훑었다.

시험날은 2월 28일로 잡았으며, 남은 기간 동안 기출 보카는 끝까지 외우고 빠르게 2회독을 할 예정이다.

750+교재는 2월 20일까지 다시 한번 2회독을 하는 것을 목표로 하고, 일주일 동안은 실전 기출문제를 풀어볼 예정이다.

부끄럽지만, 과거에 1~2주 정도 준비하고 본 토익 점수가 595점이였는데, 이번에는 좀 더 열심히 준비해볼 예정이다.

[모각코-4회차] ADP 포기...

PiLove — Fri, 13 Feb 2026 21:39:37 +0900

모각코 4회차에는 방학 계획을 좀 수정하게 되었다.

기존 목표는 ADP 필기 합격이였지만, 주어진 시간을 생각했을 때 쉽지 않을 것이라고 판단되어 결국 포기하였다.

알바와 다른 공부와 병행하다보니, 선택과 집중이 필요했다.

따라서 모각코 시간에 ADP 공부가 아닌, 토익을 준비하기로 결정했다.

4회차에는 남은 방학 기간동안 토익을 준비하기 위해 간단한 계획을 정리하였다.

[모각코-2, 3회차] 2과목 2장 정리

PiLove — Fri, 23 Jan 2026 20:08:27 +0900

2과목 2장 정리.pptx

2.73MB

[모각코-1회차] 2과목 1장 정리

PiLove — Fri, 2 Jan 2026 22:30:03 +0900

1. ETL

데이터의 이동 및 변환 절차와 관련된 용어로, ODS > DWH > DM 에 데이터를 적재하는 과정에 사용됨

용어 그대로 데이터 원천(Source)로부터 데이터를 추출(Extraction)하고 변형(Transformation)하여 적재(Load)하는 기능을 수행

1-1. 데이터가 DW에 적재되기까지 과정

Interface
다양한 원천으로부터 데이터를 획득하기 위한 매커니즘 구현
Staging ETL
획득한 데이터를 스테이징 테이블에 임시로 저장
임시로 저장하는 이유는 ODS에 데이터를 적재하기 전 수집한 데이터에 대해 전처리를 해야하기 때문에 원본 그대로의 데이터를 백업으로 저장
Profiling ETL
스테이징 테이블의 데이터 품질 측정
Cleansing ETL
다양한 규칙을 적용하여 데이터의 보정 작업 수행
Integration ETL
다양한 원천으로부터의 데이터를 통합
Denormalizing ETL
DW 또는 DM에 데이터를 적재하기 위해 데이터에 대해 비정규화 수행

2. ODS, DW

2-0. ODS

데이터에 대한 추가 작업을 위해 다양한 원천(Source)로부터 수집한 데이터를 통합한 데이터베이스

ODS는 DW로 적재하기 이전 단계의 데이터베이스로, 실시간 또는 근접 실시간 간격으로 데이터를 업데이트하기에 실시간 조회가 가능함. 데이터를 업데이트하는 과정에서는 일반적인 데이터 클렌징, 중복제거, 무결성 점검 등의 작업을 수행함.

ODS는 DW로 데이터를 적재하기 이전 단계의 데이터베이스인데, DW에서는 데이터를 일괄적(Batch 단위)으로 업데이트하므로 실시간 조회가 쉽지 않음. 따라서 ODS는 원천 시스템과 DW 사이의 "대기 공간"과 같은 개념임.

2-1. ODS의 구성단계

Interface layer
다양한 데이터 원천으로부터 데이터를 획득하는 단계
데이터 획득을 위한 프로토콜로 OLEDB, ODBC, FTP 등이 사용됨
DW에 대한 실시간 또는 근접 실시간 OLAP 질의를 지원하기 위한 실시간 데이터 복제 인터페이스 기술에 함께 활용됨
Staging layer
원천으로부터 추출한 데이터를 하나 이상의 스테이징 테이블에 저장하는 단계
스테이징 테이블은 정규화가 배제되며, 스키마는 데이터 원천의 구조에 의존적임
데이터 원천과 스테이징 테이블 사이의 데이터 매핑은 일대일 또는 일대다로 구성됨
적재 타임스탬프, 값에 대한 체크 섬 등의 통제 정보들이 추가됨
Profiling layer
범위/도메인/유일성 확보 등의 규칙을 기준으로 데이터 품질을 점검하는 단계
Cleansing layer
프로파일링 단계에서 식별된 오류 데이터들을 수정하는 단계
Integration layer
수정 완료한 데이터를 ODS 내의 단일 통합 테이블에 적재하는 단계
이 단계 이전의 데이터들은 다양한 원천으로부터 가져온 데이터이므로 서로 다른 테이블에 저장되어 있을 수 있음
Export layer
앞 단계에서 통합된 데이터에 대해 보안 규칙을 반영한 ETL을 수행하여 익스포트 테이블을 생성하고 다양한 DBMS 클라이언트, DM, DW에 해당 테이블을 적재하는 단계

2-2. DW

ODS를 통해 정제 및 통합된 데이터가 데이터 분석과 보고서 생성을 위해 적재되는 데이터 저장소

DW가 필요한 이유는 원천으로부터 데이터를 분석하고 사용하려면, 기존의 서비스가 느려질 가능성이 있고, 다양한 원천으로부터 통합된 데이터베이스를 구축함으로써, 일괄적으로 데이터를 관리할 수 있기 때문임.

2-3. DW의 특징

주제 중심성(Subject Oriented)
다양한 원천으로부터 얻은 데이터들은 각각의 주제를 중심으로 테이블이 생성됨
영속성/비휘발성(Non Volatile)
DW의 데이터는 최초 저장 이후 Read Only 속성을 가짐
통합성(Integrated)
다양한 원천으로부터 생성된 데이터들의 통합본
시계열성(Time Variant)
시간 순에 의한 이력 데이터들의 기록들이 저장되어 있음

2-4. DW의 테이블 모델링 기법

스타 스키마(조인 스키마)
- 단일 사실 테이블(Fact Table)을 중심으로 다수의 차원 테이블(Dimenstion Table)로 구성됨
- 전통적 관계형 데이터베이스를 통해 다차원 데이터베이스 기능을 구현할 수 있음
- 사실 테이블은 보통 제 3정규형으로 모델링됨
- 차원 테이블은 보통 비정규화된 제 2정규형으로 모델링됨
- 복잡도가 낮아 쿼리 작성이 용이하지만 차원 테이블들의 비정규화에 따른 데이터 중복으로 인해 데이터 적재에 상대적으로 많은 시간이 소요됨

스노우 플레이크 스키마
- 스타 스키마의 차원 테이블을제 3정규형으로 모델링한 형태
- 데이터의 중복이 제거되어 데이터 적재 시 시간이 단축되지만, 복잡성의 증가로 조인 테이블 개수가 증가하고 쿼리 작성 난이도가 상승함

3. CDC

CDC(Change Data Capute)는 용어 그대로 데이터베이스 내 데이터에 대한 변경을 식별하여 필요한 후속처리를 자도오하하는 기술 또는 설계 기법이자 구조를 말함

3-1. CDC 구현 기법

Time Stamp on Rows
Version Numbers on Rows
Status on Rows
타임스탬프 및 버전넘버에 대한 보완 용도로, 변경 여부를 True/False 값으로 저장하는 상태 기반 변경 여부 판단 기법
Triggers on Tables
데이터베이스 내 트리거를 활용하여 데이터 변경 내역을 별도의 테이블에 기록하는 기법
Event Programming
데이터 변경 식별 기능을 application에 구현하여 다양한 조건에 의한 CDC 매커니즘을 구현하는 기법
Log Scanner on Database
모든 데이터베이스는 장애 복구를 위해 데이터에 발생하는 모든 변화를 로그 파일에 기록하는데, 이 로그에 대한 스캐닝 및 변경 내역을 확인하여 CDC 매커니즘을 구현하는 기법

3-2. CDC 구현 방식

Push 방식
원천에서 변경을 식별하고 대상 시스템에 변경 데이터를 적재
Pull 방식
대상 시스템에서 원천을 정기적으로 살펴보고 필요 시 데이터를 다운

4. EAI

기업 내 각종 애플리케이션 간의 상호 연동이 가능하도록 통합하는 솔루션으로, 상호 이질적인 정보 시스템들의 데이터를 연계함으로써 상호 융화 내지 동기화 되도록 만듦

비즈니스 프로세스를 자동화하고 실시간으로 통합 연계가 가능하게 할 수 있음. 즉, EAI는 실시간 혹은 근접 실시간의 처리가 가능함.

4-1. EAI의 구성요소

어댑터(Adapter)
각 정보 시스템과 EAI 허브 간의 연결성 확보
버스(Bus)
어댑터를 매개로 연결된 각 정보 시스템들 간의 데이터 연동 경로
브로커(Broker)
데이터 연동 규칙 통제
트랜스포머(Transformer)
데이터 형식 변환 담당

4-2. EAI 데이터 연계 방식

기존의 데이터 연계 방식 : Point to Point
- 정보 시스템 간의 데이터를 1대1로 연계함으로써 그림과 같은 복잡성이 발생
- N개의 연결 대상 노드들이 존재할 경우, 연결은 N(N-1)/2개가 됨
EAI의 데이터 연계 방식 : Hub and Spoke
- 가운데 지점에 허브 역할을 하는 브로커를 두고, 연결 대상 노드들의 데이터 연계 요구를 중계
- 다수 정보 시스템의 데이터를 중앙의 Hub가 연계하고 통합
- 각 연결의 대상이 되는 노드들이 Spoke에 해당

4-3. EAI 구현 유형

Mediation(Intra-Communication)
- EAI 엔진이 브로커로 동작하며, 특정 정보 시스템 내의 데이터 생성, 갱신, 커밋 등의 이벤트 발생을 식별하고 미리 약속된 정보 시스템에 해당 내용을 전달
- Publish/Subscribe model이라고 부름
Federation(Inter Communication)
- EAI 엔진이 외부 정보 시스템으로부터 데이터 요청들을 일괄적으로 수령하여 필요한 데이터를 각각의 정보 시스템에 전달
- Request/Reply model이라고 부름

4-4. EAI vs ESB

구분	EAI (Enterprise Application Integration)	ESB (Enterprise Service Bus)
기능	미들웨어(Hub)를 이용하여 비즈니스 로직을 중심으로 Application을 통합·연계	미들웨어(Bus)를 이용하여 서비스 중심으로 시스템을 유기적으로 연계
통합관점	Application	Process
로직연동	개별 Application에서 수행	ESB에서 수행
아키텍처	단일 접점인 허브시스템을 이용한 중앙집중식 연결구조	버스(Bus) 형태의 느슨하고 유연한 연결구조

5. 대용량 비정형 데이터 처리방법

대용량 로그 데이터 수집
- 로그(Log)
  - 기업에서 발생하는 대표적인 비정형 데이터
  - 로그 데이터 수집 시스템 예 : 아파리 Flume-NG, 페이스북 Scribe, 아파치 Chuckwa 등
- 대용량 비정형 데이터 수집 시스템의 특징
  - 초고석 수집 성능과 확장성
  - 데이터 전송 보장 매커니즘
    - 데이터가 전송 중간에 끊기지 않도록 보장할 수 있는 매커니즘이 필요
    - 여러 단계를 거쳐 저장소에 도착할 때 인접한 단계끼리 신호를 주고받아 이벤트 유실을 방지하는 방식으로 전송을 보장할 수 있음
  - 다양한 수집과 저장 플러그인
    - 수집하는 중에 오류가 발생하는 경우를 대비하여 저장 플러그인을 미리 구현
  - 인터페이스 상속을 통합 애플리케이션 기능 확장
    - 다양한 원천으로부터 데이터를 수집하기 때문에, 공통적인 내용은 인터페이스 상속을 통해 구현
- 수집한 대규모 데이터에 대한 대규모 분산 병렬 처리
  - 하둡(Hadoop)

5-1. 하둡(Hadoop)

대규모 분산 병렬 처리의 업계 표준인 맵리듀스(MapReduce)와 분산 파일시스템인(HDFS)를 핵심 구성요소로 가지는 플랫폼 기술로, 여러 대의 컴퓨터를 마치 하나의 시스템인 것처럼 묶어 분산 환경에서 빅데이터를 저장 및 처리할 수 있도록 하는 자바 기반의 오픈소스 프레임워크

하둡은 비공유 분산 아키텍처를 사용함
비공유 분산 아키텍처란, 분산 환경에서 각각의 컴퓨터(노드)들이 독립적인 CPU, 메모리, 로컬 디스크를 가지는 구조를 말함

5-2. 하둡의 특징

선형적인 성능과 용량 확장
- 비공유 분산 아키텍처 시스템이므로 서버를 추가하면 연산 기능과 저장 기능이 서버의 대수에 비례하여 선형적으로 증가함
고장 감내성
- 분산 파일시스템(HDFS)에 저장되는 데이터는 3중복제 되어 서로 다른 물리서버에 저장되므로 데이터 유실을 방지함
- 분산 병렬 처리(MapReduce) 작업 수행 중 특정 태스크에 장애가 발생하면, 해당 태스크만 다른 서버에서 재실행
핵심 비즈니스 로직에 집중
- 하둡의 맵리듀스는 맵과 리듀스라는 2개의 함수만 구현하면서 동작하는 시스템
- 알고리즘 및 로직 개발자는 맵리듀스라는 분산 병렬 처리 시스템의 데이터 처리/분석 방식만 이해하고 비즈니스 목적에 맞게 코드만 작성하면됨
- 시스템 수준에서 발생하는 장애에 대한 자동복구를 제공하고, 확정성 및 성능 등의 이슈도 하둡이 내부적으로 최적화하여 처리함
하둡 에코 시스템
- 하둡 프레임워크를 이루고 있는 다양한 서브 프로젝트들의 집합으로 수집, 저장, 처리기술과 분석, 실시간 SQL 질의 기술로 구분됨

5-3. 하둡 에코 시스템

비정형 데이터 수집 : Chuckwa, Flume, Scribe
- Chuckwa : 분산된 각 서버에서 에이전트를 실행하고, 컬렉터가 에이전트로부터 데이터를 받아와 HDFS에 저장하는 기술
- Flume : 많은 양의 로그 데이터를 효율적으로 수집하기 위해 이벤트와 에이전트를 활용하는 기술
- Scribe : 다수의 서버에서 실시간 스트리밍되는 로그 데이터를 수집하여 분산 시스템에 저장하는 대용량 실시간 수집 기술
정형 데이터 수집 : Sqoop, Hiho
- Sqoop : 대용량 데이터 전송 솔루션으로 RDBMS에서 HDFS로 데이터를 수집하거나(Import),
  HDFS에서 RDBMS로 데이터를 보내는(Export) 기술
- Hiho : Sqoop과 같은 대용량 데이터 전송 솔루션으로, HDFS에서 데이터를 가져오기 위한 SQL을 지정할 수 있고
  JDBC 인터페이스 지원
분산 데이터 저장 : HDFS
- 대용량 파일을 분산된 서버에 저장하고, 그 데이터를 빠르게 처리할 수 있게 하는 하둡 분산 파일시스템으로, 범용 하드웨어 기반 클러스터에서 실행되고 데이터 접근 패턴을 스트리밍 방식으로 지원하며, 다중복제, 대용량 파일 저장, 온라인 변경, 범용서버 기반, 자동복구 특징이 있음
- 네임노드, 보조 네임노드, 데이터 노드로 이루어짐

구 성	특 징
네임노드	마스터 역할 모든 메타데이터 관리 데이터 노드들로부터 하트비트를 받아 상태 체크
보조 네임노드	상태 모니터링을 보조
데이터노드	슬레이브 역할 데이터 입출력 요청 데이터 유실방지를 위해 블록을 3층 복

분산 데이터베이스 : HBase
- HDFS를 기반으로 구현된 컬럼 기반의 분산 데이터베이스로 실시간 조회 및 업데이트 할 수 있으며, 각각의 프로세스는 개인의 데이터를 비동기적으로 업데이트 할 수 있음
분산 데이터 처리 : MapReduce
- 대용량 데이터에 대한 분산 병렬 처리를 목적으로 만들어진 소프트웨어 프레임워크로 모든 데이터를 Key-Value로 구성
- 맵, 셔플, 리듀스로 구성됨
- 맵 : Key-Value 형태로 데이터를 취합
- 셔플 : 데이터를 통합하여 처리
- 리듀스 : 맵 처리된 데이터를 정리
- 데이터를 디스크에 두고 처리하기 때문에 속도가 느림
리소스 관리 : 얀(YARN)
- 하둡의 맵리듀스 처리 부분을 새롭게 만든 자원 관리 플랫폼으로, 리소스 매니저, 노드 매니저, 애플리케이션 마스터, 컨테이너로 구성됨

구 성	특 징
리소스 매니저	스케쥴러 역할을 수행하고 클러스터 이용률 최적화 수행
노드 매니저	각각의 노드 내 독립된 자원을 관리하고 리소스 매니저에게 전달 수행 및 컨테이너 관리
애플리케이션 매니저	리소스 매니저와 자원의 교섭을 책임지고 컨테이너 실행
컨테이너	프로그램 구동을 위한 격리 환경을 지원하는 가상화 자원

인메모리 처리 : 아파치 스파크(Apache Spark)
- 맵리듀스의 느린 속도를 개선하기 위한 하둡 기반 대용량 분산처리시스템으로, 스트리밍 데이터, 온라인 머신러닝 등 실시간으로 데이터 처리
- 데이터를 인메모리에 두고 처리하므로 속도가 빠름
데이터 가공 : Pig, Hive
- Pig : 대용량 데이터 집합을 분석하기 위한 플랫폼으로 맵리듀스를 사용하기 위한 스크립트 언어인 피크 라틴이라는 자체 언어 제공
- Hive : 하둡 기반 DW 솔루션으로 SQL과 매우 유사한 HiveQL이라는 쿼리 제공
데이터 마이닝 : Mahout
- 하둡 기반으로 데이터 마이닝 알고리즘을 구현한 오픈소스로 다양한 알고리즘 지원
실시간 SQL 질의 : Impala, Tajo
- Impala : 하둡 기반의 실시간 SQL 질의 시스템으로 조회을 위한 인터페이스로 HiveQL을 지원하고, HBase와 연동 가능
- Tajo : 다양한 데이터 소스를 위한 하둡 기반의 ETL 기술을 이용하여 DW에 적재하는 시스템
워크플로우 관리 : Oozie
- 하둡 작업을 관리하는 워크플로우 및 코디네이터 시스템
분산 코디네이션 : Zookeeper
- 분산 환경에서 서버들 간의 상호 조정이 피룡한 다양한 서비스를 제공하는 기술로 분산 처리를 알맞게 처리하도록 조정하는 역할 수행

[영상처리] Week2-3. Point processing & Histogram equalization

PiLove — Thu, 3 Apr 2025 00:18:16 +0900

어떤 이미지들은 너무 밝거나 어두워서 또는 주변 픽셀과의 대비가 낮아서 무슨 이미지인지 알아보기 힘든 경우가 있다. 이러한 이미지들은 특정한 처리를 통해 좀 더 선명하게 만들어줘야 한다. 오늘은 여러가지 처리기법 중 가장 기본적인 Point processing과 Histogram equalization에 대해 알아보려고 한다.

➤ Point processing

➤ Histogram equalization

Point processing

Point processing이란 이미지의 각 픽셀을 독립적으로 처리하는 방식을 말한다. 주변 픽셀은 고려하지 않고 오로지 입력 픽셀 값만에 의존하여 출력 픽셀들을 계산한다. 아래 그림을 확인해보자.

원본 이미지의 녹색 픽셀로부터 특정한 operation을 통해 출력 픽셀들의 값을 모두 결정했으므로 해당 과정은 Point processing에 해당한다.

만약, 입력 이미지의 어떤 한 픽셀이 아닌 주변 픽셀 값들을 고려하여 출력 픽셀 값들을 결정한다면, 그건 필터링에 해당한다. 아래 그림 같은 경우는 필터링에 해당한다.

Point processing의 예제를 몇가지 확인해보자. 원본 이미지의 모든 픽셀 값들의 집합을 f(x)라고 하자.

입력 픽셀 값 f(x)에 대해 특정한 operation을 적용한다. f(x)에 대해 상수를 단순히 더하거나 빼서 밝기를 조절할 수 있고, f(x)에 대해 곱하거나 나누어서 대비를 조절할 수도 있다.

이를 수식으로 나타내면 다음과 같다.

g(x, y) : 출력 이미지의 (x, y)위치의 픽셀 값

f(x, y) : 입력 이미지의 (x, y)위치의 픽셀 값

h : Intensity trnasformation function(변환 함수)

를 의미한다.

어떤 이미지에 대해 위와 같은 수식을 적용하게 되면, 해당 이미지의 모든 위치의 픽셀에 대해 연산을 진행한다. 따라서 연산 수행 횟수를 줄이기 위해 같은 픽셀 값을 지니는 픽셀에 대해서는 연산을 하지 않는 것이 좋다. 따라서 수식으로 나타낼 때도 s = h(r) 로 나타내며 의미는 다음과 같다.

r : 입력 이미지의 픽셀 값들의 집합

s : 출력 이미지의 픽셀 값들의 집합

그래프로도 확인해보자.

x축이 입력 이미지의 픽셀 값을 의미하며, y축이 Intensity transformation function을 적용한 출력 이미지의 픽셀 값을 의미한다.

(a)의 경우, 어두운 픽셀 값들은 더 어둡게, 밝은 픽셀 값들은 더 밝게 만들어주고 있다.

(b)의 경우, Threshold 값 k를 지정하여, k보다 작은 픽셀 값에 대해서는 출력 픽셀을 0으로 만들고, k보다 큰 픽셀 값에 대해서는 1로 만들고 있다.

Point processing에서 자주 사용되는 Intensity transformation function인 "Power-law(gamma) transformation"에 대해서도 알아보자. 수식으로 나타내면 다음과 같다.

r : 입력 이미지의 픽셀 값들의 집합

s : 출력 이미지의 픽셀 값들의 집합

c : 상수 (보통 1로 설정)

(gamma) : 밝기 조절을 결정하는 지수

위 수식에서 우리는 (gamma) 값을 조절하면서 이미지를 가공한다. 그래프를 통해 (gamma)의 변화에 따른 픽셀 값들의 변화를 확인해보자.

(gamma) < 1 : 어두운 픽셀 값들은 밝아지고, 밝은 픽셀 값들은 더 밝아지고 있다.

→ 어두운 부분이 강조되고 전체적인 밝기가 밝아졌다.

(gamma) = 1 : 변화 x

(gamma) > 1 : 어두운 픽셀 값들은 더 어두워지고, 밝은 픽셀 값들은 어두워졌다.

→ 밝은 부분이 강조되고 전체적인 밝기가 어두워졌다.

왼쪽 상단에 있는 이미지가 원본 이미지이다.

오른쪽 상단의 이미지 (gamma) = 0.6

왼쪽 하단의 이미지 (gamma) = 0.4

오른쪽 하단의 이미지 (gamma) = 0.3

(gamma)의 값이 작아질수록 이미지가 확실히 밝아지는 것을 확인할 수 있다.

왼쪽 상단에 있는 이미지가 원본 이미지이다.

오른쪽 상단의 이미지 (gamma) = 3.0

왼쪽 하단의 이미지 (gamma) = 4.0

오른쪽 하단의 이미지 (gamma) = 5.0

(gamma)의 값이 커질수록 이미지가 확실히 어두워지는 것을 확인할 수 있다.

Histogram equalization

Histogram은 특정 이미지에 대해 0~255 사이의 픽셀 값들의 분포를 나타낸다. 아래 예시를 확인해보자.

위 그림처럼 특정 구역에 픽셀이 집중적으로 모여있을 때는, Histogram stretching을 사용하여 픽셀 값의 영역을 재배치하여 대비(contrast)를 높일 수 있다.

0 ~ 255 사이의 픽셀 값을 0~15의 level로 구분하여 나타내고, 각 level별로 픽셀 값이 몇개씩 분포해있는지 나타낸 예제가 있다. 아래 그림을 보자.

이미지의 픽셀값이 대체적으로 5 ~ 9 사이에 몰려있는 것을 확인할 수 있다.

이에 대해서 stretching function을 적용해보자. 수식으로 나타내면 다음과 같다.

a i+1 : 이미지 내 픽셀 값이 몰려있는 영역의 최대 grey 레벨

a i : 이미지 내 픽셀 값이 몰려있는 영역의 최소 grey 레벨

b i + 1 : 퍼뜨리고자 하는 영역의 최대 grey 레벨

b i : 퍼뜨리고자 하는 영역의 최소 grey 레벨

그래프로 확인해보자.

확실히 5~9 사이에 분포하던 픽셀 값이 넓게 펼쳐진 것을 확인할 수 있다. 그러나 넓게 펼쳐지기만 하고 픽셀 값이 균등하게 분포되어 있지 않다. 이를 위한 기법이 Histogram equalization이다.

Histogram equalization의 가장 이상적인 케이스는 다음과 같이 모든 픽셀 값들을 grey level에 대해 균등하게 분포시키는 것이다.

위 그래프를 확률 밀도 함수(PDF, Probability Density Function)으로도 나타낼 수 있다. 원래 픽셀 값은 0~255의 정수로 나타내기 때문에 PDF로 나타낼 수 없지만, 그럼에도 불구하고 이론적인 모델링을 위해 "연속적인 경우"를 가정하고 PDF로 표현한다.

위 그래프를 PDF로 나타낸 그림은 다음과 같다.

여기서 입력 이미지와 출력 이미지의 픽셀 수 자체는 같기 때문에 다음 수식이 성립한다.

입력 이미지에 대한 PDF : $f_R(r)$

출력 이미지에 대한 PDF : $f_S(s)$

$f_R(r)$을 $f_S(s)$로 변환하려면, 다음과 같은 함수를 적용해야 한다.

여기서 각각의 픽셀 값들을 T(r)의 값으로 변환해준다.

여기서 T(r)은 monotonic increasing function이다.
Monotonic increasing function은 값은 같아도 되지만 감소하지 않는 함수를 말한다.

위 수식들을 토대로 $f_R(r)$ 은 다음과 같이 전개될 수 있다.

여기서 알 수 있는 건 T(r)의 도함수가 $f_R(r)$과 같아진다는 것이다.

이는 곧 T(r)이 monotonic increasing function이라는 것을 증명한다.

위 수식에서 $f_R(r) = T'(r)$ 이 성립하므로, 아래 수식도 성립한다.

해당 수식은 $T(r)$ 을 누적 분포 함수(CDF)로 정의한 수식이다.

그러나 위 수식은 continuous case를 가정한 이론적인 모델이다. 실제 이미지는 discrete하므로, 다음과 같은 근사가 필요하다.

해당 수식을 적용한 예제를 표로 나타내서 확인해보자.

[데이터베이스] Week3. Relational Database

PiLove — Tue, 1 Apr 2025 13:07:29 +0900

Relational database

Relational database(관계형 데이터베이스)는 데이터들 사이에 정의된 관계가 있는 데이터베이스를 의미한다. Relational database에 대해 이해하기 위해 relation에 대해 먼저 알아보자.

Relation(Table)

개체를 표현하기 위한 데이터 구조

2차원 테이블로 표현

▶행(row, tuple): 개체를 표현. 관련된 데이터 값들의 모임.

▶열(column, attribute): 각 행의 값들의 의미를 해석하는 데 사용.

Relation은 tuple들의 집합

간단한 예제를 하나 확인해보자.

Movie라는 relation(table)은 2차원 테이블 형태로 구성되어 있으며, 각 행은 객체로써 tuple이라고 부른다. 이 tuple들의 집합이 해당 relation에 대한 relation status(relation extension)이다. 각 열은 해당 열에 대한 값들의 의미를 뜻하며 attribute라고 부른다. 이 attribute들의 집합이 해당 relation에 대한 relation schema(relation intension)이다. 위 relation에서 relation schema는 "Movie(movieId, title, genre, length, rating)"으로 표기한다.

Relational database 스키마 기반 제약 조건

Schema는 stored database의 structure + constraints로 이루어져있다. 이전 목차에서 relational database의 structure에 대해 알아보았다면, 이번 목차에서는 constraint에 대해 알아볼 예정이다. Constraint는 relational database의 특정 attribute에 값이나 타입 등의 제한을 두거나 relation 사이에 지켜져야 하는 규칙 등을 의미한다. 하나하나 알아보도록 한자.

Relational database의 스키마 기반 제약 조건들

도메인 제약 조건(Domain constraints)

널 제약 조건(Null constraints)

키 제약 조건(Key constraints)

엔티티 무결성 제약 조건(Entity Integrity Constraints)

참조 무결성 제약 조건(Referential Integrity Constraints)

Domain constraints

Domain constraints는 각각의 tuple내에서 각각의 attribute A에 대하여 A의 값이 A의 도메인에 속하는 원자값이어야 함을 의미한다. 말이 어렵지만 예시를 들어 생각해보자.

Relation Avitivity에 'weather'이라는 attribute가 있다고 가정하자. 'weather' 는 'sunny, rainy, ...' 등의 날씨와 관련된 문자열만을 도메인으로 갖는다. 이러한 경우, 그 어떤 tuple이든 'weather'이라는 attribute에 대해서는 위에서 언급한 'sunny, rainy ...' 등의 날씨와 관련한 문자열 집합의 원소를 가져야 한다는 뜻이다. 'weather'이라는 attribute에 대해 뜬금없이 'football'이라는 값을 가지는 건 허용하지 않는다.

아래는 SQL로 domain constraints을 명시한 예제이다.

create table Movie( 
	movieId varchar(10) primary key,
	title varchar(100) unique,
	genre varchar(32),
	rating varchar(5), 
    	check (rating in(‘G’, ‘PG’, ‘PG-13’, ‘R’, ‘NC-17’)
    …
)

create table Rental( 
	accountId int,
	videoId varchar(10),
	dateRented datetime,
	dateDue datetime,
	…
	check (dateRented <= dateDue)
 )

Relation Movie의 'rating'은 시청 등급이라는 뜻이며, 이에 대한 명확한 표준 등급이 있으므로 해당 집합을 명시해주었다. Relation Rental의 'dateRented'는 대출 날짜를 의미하며 'dateDue'는 반납 날짜를 의미한다. 반납 날짜는 대출 날짜 뒤의 날이므로 이에 대한 domain constraints를 명시해주었다.

Null constraints

Attribute는 그 의미에 따라 Null값이 필요할 수도, 필요하지 않을 수도 있다. 아래 코드를 예제로 생각해보자.

create table VideoTape (
	videoId varchar(10) primary key,
	movieId varchar(10) not null default ‘000-00-000’
	references Movie,
	storeId int references Store 
)

Relation VideoTape의 'movieId'는 절대로 Null 값이 될 수 없다. VideoTape의 'movieId'가 relation Movie의 'movieId'를 참조하고 있기 때문이다. 또한 상식적으로 현실세계에서 비디오테이프에 저장된 영화에 대해 고유 식별 번호를 정의하지 않는 것도 말이 안된다.

Key constraints

Key constraints는 relation에서 특정 attribute에 대해 각 tuple을 고유하게 식별해야 함을 의미한다. 즉, key로 지정된 attribute에는 중복된 값도 존재할 수 없다. Super key는 1개 이상의 attribute를 집합으로 했을 때 유일성을 만족하는 attribute 집합이다. 예를 들어 생각해보자.

Relation R에 대해 'SSN'이라는 key가 있고, 'name', 'age'라는 attribute가 있다고 가정하자. 'SSN'은 그 자체로 각 tuple을 구별할 수 있는 유일성을 지니고 있다. 따라서 'SSN'은 key인 동시에 super key이다.

{'SSN', 'name'} 또한 각 tuple을 구별할 수 있는 유일성을 지니고 있다. 따라서 super key에 해당한다.

{'SSN', 'age'}와 {'SSN', 'age', 'name'} 또한 super key에 해당한다.

만일 relation schema가 하나 이상의 key를 가질 경우, 각 키를 'candidate key'라고 한다. 그리고 candidate key 중 하나를 'primary key'로 지정한다. Primary key를 지정하면, 이 primary key로 각 tuple들을 식별한다. Primary key이외의 다른 candidate key는 'unique key'라고 부른다. 이를 정리하면 아래와 같다.

Key

▶각 tuple을 고유하게 식별할 수 있는 attribute

Super key

▶각 tuple을 고유하게 식별할 수 있는 attribute 집합

Candidate key

▶해당 relation schema가 하나 이상의 key를 가질 때, 각 key = candidate key

Primary key

▶Candidate key 중 개발자가 지정한 하나의 key로, 해당 key로 각 tuple을 식별하게 됨

Unique key

▶Primary key를 제외한 다른 Candidate key

Entity Integrity Constraints

EIC(Entity Integrity Constraints)는 어떠한 primary key 값도 Null 값이 될 수 없음을 의미한다. Primary key로 각 tuple을 식별하므로 primary key 값이 Null이 되면 튜플을 식별할 수 없기 때문이다.

Reference Integrity Constraints

RIC(Reference Integrity Constraints)를 이해하기 위해선 foreign key에 대해 먼저 알아야 한다. Foreign key의 조건은 아래와 같다.

Foreign key

Rleation schema R1의 어떤 attribute 집합 FK가 아래 규칙을 만족하면, FK는 relation R2를 참조하는 R1의 foreign key이다.( R1 : 참조한 relation, R2 : 참조된 relation )

FK의 attribute는 R2의 primary key, PK의 attribute와 동일한 domain을 가진다.

현재 상태 R1의 한 tuple t1의 FK값은 현재 상태 R2의 어떤 tuple t2내의 PK값과 일치하거나 Null값을 가진다.

아래는 예제이다.

create table VideoTape (
	videoId varchar(10) primary key,
	movieId varchar(10) not null default ‘000-00-000’
	references Movie,
	storeId int references Store 
)

create table Store (
	storeId int(10) primary key,
    	street varchar(20) not null,
    	city varchar(20) not null,
    	manager varchar(12) not null,
)

코드를 보면, VideoTape의 'storeId'가 Store의 primary key인 'storeId'를 참조하는 것을 확인할 수 있다.

이를 Schema 다이어그램으로 표시하면 다음과 같다.

밑줄이 쳐진 attribute는 primary key를 의미한다.

만약 RIC가 위반된 경우에는 참조하는 혹은 참조되는 relation의 각 attribute의 값을 확인해보자.

[데이터베이스] Week2. 정보관리와 데이터베이스 시스템

PiLove — Tue, 1 Apr 2025 10:13:23 +0900

정보 시스템

정보 시스템을 이해하기 위해선 데이터와 정보의 정확한 정의에 대해 먼저 알아야 한다.

데이터와 정보

데이터

▶비트들의 모음

▶현실세계로부터 단순한 관찰이나 측정을 통해 수집된 사실이나 값

정보

▶데이터를 처리한 결과

▶의사결정의 근거

정보 시스템(Information System)이란, 한 기관을 위해 데이터를 수집, 조직, 저장하고 필요 시에 처리하여 의사 결정에 유용한 정보를 생성, 분배하는 수단이다.

앞으로 배우고자 하는 "데이터베이스 시스템"은 정보 시스템의 코어가 되는 시스템이다. 데이터베이스 시스템은 정보 처리 시스템이 그 기능을 효과적으로 수행할 수 있게 하는 기본이 되는 도구이다.

데이터베이스 시스템 구성 요소

데이터베이스 시스템을 단순화해서 나타내면 다음과 같다.

데이터베이스 시스템의 구성 요소

물리적 데이터베이스(Stored Database)

▶실제 데이터 내용을 포함하는 파일들의 집합

스키마(Schema, Meta-Data)

▶물리적 데이터베이스의 내용을 명세하는 데이터

데이터베이스 관리 시스템
(DBMS, DataBase Management System)

▶데이터베이스 안의 내용을 접근하고 변경할 수 있는
소프트웨어

▶Oracle, MS SQL Server, IBM DB2, ...

데이터 정의, 관리 언어(DDL, DCL)

▶스키마를 정의하고 데이터베이스에 접근하기 위해
사용하는 언어

Users/Programmers 가 DB에서 어떤 데이터를 질의(Query)하고자 명령어를 작성하면, 해당 DBMS에서 해당 명령어를 처리하고 Stored database에 접근하여 해당 데이터를 반환한다.

이제 실제로 값들이 저장되는 데이터베이스(Stored database)에 대해 알아보자. 데이터베이스의 정의는 "한 조직의 여러 응용 시스템들이 공용(Shared)하기 위해 통합(Integrated), 저장(Stored)한 운영(Operational)데이터의 집합"이다.

데이터베이스 정의

통합된 데이터(Integrated data)

▶최소의 중복 또는 통제된 중복

저장 데이터(Stored data)

▶컴퓨터가 접근 가능한 저장 매체에 저장

운영 데이터(Operational data)

▶한 조직의 고유 기능을 수행하기 위해 필요한 데이터

공용 데이터(Shared data)

▶한 조직에 있는 여러 응용 프로그램이 공동으로 소유, 유지, 이용하는 데이터

데이터베이스의 특징도 알아보자. 데이터베이스는 질의의 속도도 빨라야 하고, 현실세계의 값이 바뀌면 데이터베이스의 값도 바뀌어야 한다. 여러 사람이 질의를 할 수도 있어야 하며, 질의하고자 하는 데이터의 값에 따라 그 값을 반환해야 한다. 정리하면 아래와 같다.

데이터베이스 특징

온라인 접근성(Online accessibilities)

▶질의에 대한 실시간 처리 및 응답

계속적인 변화(Continuous Evolution)

▶새로운 데이터의 삽입, 기존 데이터의 삭제, 갱신으로 현실세계의 변화하는 값을 반영

동시 공용(Concurrent Sharing)

▶서로 다른 목적을 가진 응용들을 여러 사용자가 동시에 사용

값에 따른 참조(Content Reference)

▶위치나 메모리 주소가 아닌 값에 따른 참

이번에는 스키마(Schema, meta-data)에 대해 알아보자. 스키마는 위에서 설명한 데이터베이스(Stored database)에 대한 설명을 기술한 데이터이다.

스키마(Schema, Meta-data)

데이터베이스에 대한 설명을 기술

▶데이터베이스 구조, 타입, 제약 조건

DBMS 카탈로그(Catalog)에 저장

DBMS는 이 스키마가 저장된 카탈로그로부터 DB에 대한 정의를 가져와 DB에 접근한다.

이제 DBMS에 대해 알아보자. 위에서 설명했듯이 DBMS는 데이터베이스 안의 내용을 접근하고 변경할 수 있는 소프트웨어이다. 데이터베이스를 관리하기 위한 DBMS의 여러 기능에 대해 알아보자.

DBMS의 기능

정의(Definition)

▶데이터의 논리적 구조를 명세

▶물리적 저장 구조 명세

▶물리적 / 논리적 사상 명세

조작(Manipulation)

▶Read : 검색(SELECT)기능 지원

▶Write : 삽입(INSERT), 삭제(DELETE), 갱신(UPDATE) 기능 지원

제어(Control)

▶데이터의 삽입, 삭제, 갱신 기능에 대한 데이터의 무결성(Integrity) 유지

▶사용자의 데이터 접근 권한 관리

[프로그래밍언어개론] Syntax and Parsing

PiLove — Tue, 1 Apr 2025 08:50:53 +0900

[프로그래밍언어개론]의 목적은 프로그래밍 언어를 구성하는 구문(Syntax)과 의미(Sematics)를 이해하여 다양한 프로그래밍 언어를 빠르고 정확하게 습득할 수 있는 능력을 섭렵하는 것이다. 오늘은 프로그래밍 언어가 입력 문자열을 어떻게 인식하는 지에 대한 이야기이다.

프로그래밍 언어는 알파벳 문자열로 구성된 문자열 집합이다. 그러나 알파벳 문자열 중에는 "프로그래밍 언어"가 아닌 문자열도 분명히 존재한다. 즉, 프로그래밍 언어는 알파벳 문자열로 구성된 문자열 집합 중에 "특정 문법"에 부합하는 문자열을 의미한다. "입력으로 들어오는 문자열이 "특정 문법"에 부합하는 알파벳 문자열 집합인가?"를 판별하는 역할은 구문분석기(Syntax analyzer 또는 Parser)가 하게 된다.

오늘은 입력 문자열이 특정 language에 포함되는가를 어떻게 확인하는지와 그 language를 정의하는 여러가지 expression에 대해 알아볼 예정이다.

Syntax and Parsing

➤ Chomsky hierarchy

➤ Regular language & Regularexpression

➤ Finite (state) automata

➤ Overall structure of compilers and interpreters

➤ Overall sㅐ

➤ Overall of compilers and

➤ Overall of compiters

Chomsky hierarchy

Chomsky hierarchy는 언어의 표현력에 따라 계층으로 나타낸 것이다. 타원이 작을수록 해당 언어의 표현력이 작음을 나타낸다. 타원마다 automata가 존재하는데, 각각의 오토마타는 "이 문자열이 이 language에 포함되는가?"를 확인하는 역할을 한다. 오늘은 Regular language와 Context-Free language에 대해 간단하게 알아보자.

참고로 대부분의 프로그래밍 언어는 Context-Sensitive Language이거나 Context-Free Language에 속한다.

Regular language & Regular expression

Regular language는 기계가 인식할 수 있는 가장 간단한 형태의 language이다. 그리고 Regualr expression은 이러한 regular language를 정의하기 위한 문법을 의미한다. 주로 입력으로 주어진 문자열을 Tokenizing할 때 사용되며, token list로 만들어진 문자열은 automata에게 넘겨져서 language에 속하는 지 판별된다.

'Σ'는 소문자 알파벳으로 이루어진 문자의 집합이며, ' Σ+'는 소문자 알파벳으로 이루어진 문자열 무한집합을 의미한다.

위 그림에서 "::="는 R이 오른쪽의 값으로 치환될 수 있음을 의미한다.

아래는 regular expression을 간결하게 사용하기 위한 연산자이다.

Regular expression의 연산자들 사이에는 다음과 같은 우선순위가 존재한다.

Kleene closure > Concatenation > Union

| = ( ) | = { , }

∗ = ( ∗ ) = { , , , , …}

| ∗ = | ( ∗ ) = { , , , , , …}

Regular expression을 활용하여 간단한 email address language를 정의해보자. 보통 대부분의 email은 다음과 같은 형태를 갖는다.

[문자열]@[문자열].[문자열]

이를 regular expression으로 나타내면 아래와 같다.

그러나 해당 문법은 약한 표현력을 가진다. "pi@cnu.ac.kr" 이라는 문자열을 L(email)의 언어로 인식하지 않는다. 이를 보완하려면, 뒤에 ".[문자열]"이 더 나올 수 있음을 표현해야 한다. 아래 표현식을 보자.

아직도 문제가 있다. "pi@cnu.ac.kr" 이라는 문자열은 이제 L(email)의 언어로 인식하지만, "@" 뒤에 "."이 4개 이상 올 때는 인식할 수가 없다. 예를 들어 "pi@o.cnu.ac.kr" 은 인식할 수 없다. 이를 보완하려면 "@" 뒤 ".[문자열]"의 개수에 제한을 두면 안된다. 아래와 같이 마지막 expression인 (.[a-z][a-z]*)에 kleene closure를 사용하면 ".[문자열]"의 제한을 없앨 수 있다.

Finite (state) automata

regular expression이 regular language를 정의하기 위한 "문법"이였다면, Finite state automata는 주어진 문자열 s가 regular language에 속하는 지 판별하는 "추상 기계"이다.

Finite state automata는 입력으로 들어온 문자열에 대해서 "상태(state)"를 변경하게 되는데, 이 상태에 따라서 regular language에 속하는 지를 판별한다. Finite state automat를 기호로 표현하면 다음과 같다.

"Q"는 해당 automata가 가질 수 있는 모든 상태를 나타낸다. 그리고 "전이함수"는 입력 알파벳에 대하여 기계의 상태를 어떻게 변화할 지를 정의한 함수이다. 이전 목차에서 예시로 들었던 L(email) language에 대해 automata를 정의하면 다음과 같다.

"[문자열1]@[문자열2].[문자열3](.[문자열4]))"에 대한 동작

입력 문자열을 모두 순회했을 때 기계의 상태가 q5이거나 q7이면 정상적으로 종료한다.

------------------------------------------
처음 기계의 상태는 q0로 시작한다. 이때 "입력 문자열의 첫 번째 문자 = 소문자 알파벳"이면 q1으로 상태를 변경한다. 그리고 q1 상태에서 "다음 문자 = 소문자 알파벳"이면 "@"가 나올 때까지 q1 상태 그대로 유지한다. q1 상태에서 "@"가 나오면 q2 상태로 변경한다.

▶ "[문자열1]@" 까지에 대한 상태 변화이다.

------------------------------------------

q2 상태에서 "다음 문자열의 첫 번째 문자 = 소문자 알파벳"이면 q3 상태로 변경한다. q3 상태에서 "다음 문자 = 소문자 알파벳"이면 q3 상태를 유지한다. q3 상태에서 "."가 나오면 q4 상태로 변경한다.

▶ "@[문자열2]." 까지에 대한 상태 변화이다.

------------------------------------------

q4 상태에서 "다음 문자열의 첫 번째 문자 = 소문자 알파벳"이면 q5 상태로 변경한다. q5 상태에서 "다음 문자 = 소문자 알파벳"이면 q5 상태를 유지한다. q5 상태에서 "."가 나오면 q6 상태로 변경한다.

▶ ".[문자열3](." 까지에 대한 상태 변화이다.

------------------------------------------

q6 상태에서 "다음 문자열의 첫 번째 문자 = 소문자 알파벳" 이면 q7 상태로 변경한다. q7 상태에서 "다음 문자 = 소문자 알파벳"이면 q7 상태를 유지한다.

▶ "(.[문자열4])" 까지에 대한 상태 변화이다.

L(email)을 아래와 같은 모형으로 나타낼 수도 있다.

Overall structure of compilers and interpreters

우리가 지금까지 알아본 Regular expression은 Regualr language에 대한 문법이다. 이는 automata에 의해 활용되어 입력으로 들어온 문자열을 잘게 잘라서 token list 형태로 만들어준다. 이 과정을 Tokenizing 혹은 Lexing 이라고 한다. 여기서 token이란, 프로그래밍 언어에서의 어휘 항목에 대한 표현을 의미한다. 예를 들어 "let x = 3 in f x"라는 문자열에 대해 "let"이라는 키워드도 하나의 어휘 항목이고 "in"이라는 키워드도 하나의 어휘 항목이다. "x"라는 변수도 어휘 항목이고 "=", "3", "f", "x" 모두 어휘 항목이다.

이렇게 입력으로 들어온 문자열에 대해서 해당 언어의 어휘 항목 즉, token list 형태로 만들어주는 것을 Tokenizing 혹은 Lexing이라고 하며 이 과정은 그림의 "Lexical Analysis"에서 이루어진다. 이 과정에서 문제가 발생하면 어휘 분석 오류(lexing error)를 보고한다.

이후 token list는 "Syntax Analysis"를 거쳐 "AST(Abstract Syntax Tree)"로 변환된다. 이 과정에서는 CFG(Context-Free Grammer, Context-Free laguage를 정의하는 문법)를 사용한다.

Regular expression으로 어휘 항목을 분석했다면, Context-Free Grammer로 어휘 항목들의 구조적인 묶음, 즉 프로그래밍 언어의 구문(문장 구조, syntax)을 정의하는 것이다.

그런데 Chomsky hierarchy에 따르면 Context-Free Language는 Regular Language보다 좋은 표현력을 가지고 있다. 그렇다면 어휘 항목을 정의하는 것도 CFG를 활용하면 되는 것 아니냐는 의문이 들 수 있다. 물론 가능은 하다. 하지만 과한 접근이며 처리 비용도 더 크기 때문에 사용하지 않는다. CFG는 Regular expression보다 표현력이 큰 만큼 비용이 크다. 어휘 항목을 정의하는 것은 간단한 일이기 때문에 굳이 CFG를 사용하여 프로그램의 무게를 늘릴 필요가 없다는 의미이다.

CFG(Context-Free Grammer)

이전 항목에서 알아보았듯이 CFG는 Syntax Analysis에서 token list를 받아 프로그래밍 언어의 구문을 정의하는 역할을 한다. CFG는 아래 3가지로 구성되어 있다.

CFG 구성요소

Terminal

▶기초 기호(literal)로써 치환되지 않는 기호

Non-terminal

▶Production에 의해 치환되는 기호

Production

▶Non-terminal을 치환하는 규칙

간단한 예시를 하나 들어보자.

A = 빈 문자열

A = (A) = ()

A = (A) = ((A)) = (())
A는 위와 같이 계~속 치환될 수 있다.

CFG의 엄밀한 정의는 다음과 같다.

G = (Σ, N, P, S)

G는 S로부터 생성할 수 있는 모든 문자열을 나타내는 문법이다.

Σ: terminal의 유한집합

N: nonterminal의 유한집합

P: production의 유한집합

S: 시작 nonterminal (S ∈ N)

G를 아래와 같이 정의했다고 하자.

G의 원소는 시작 non-terminal인 E로부터 나타낼 수 있는 모든 문자열 집합이다.

G = {n, n+n, n-n, n+n+n, n+n-n, ...}

그런데 이렇게 CFG를 정의하니 너무나 길고 복잡하게 느껴진다. 이 때문에 CFG 기술을 위한 표기법이 따로 있는데 이를 BNF(Backus-Naur Form)이라고 부른다. 위 그림에서 정의했던 CFG를 아래와 같이 표기할 수 있다.

n을 0~9 사이의 숫자로 변경하여 다시 비교해보자.

Backus-Naur Form에서 CFG의 non-terminal이 2개 이상일 때, 가장 위에 있는 non-terminal이 시작 non-terminal이다.

BNF를 사용한 것이 사용하지 않았을 때보다 훨~씬 간결한 것을 볼 수 있다.

Derivation & Parse

Derivation

▶정의한 CFG를 활용하여 시작 non-terminal로 부터 문자열을 생성하는 과정 (Parse의 반대 과정)

▶위에서 제시한 CFG에 대한 Derivation 예시

Parse

▶정의한 CFG를 활용하여 입력 문자열이 문법에 부합하는 지 확인하는 과정 (Derivation의 반대 과정)

▶위에서 제시한 CFG에 대한 Parse 예시

Derivation이나 Parse는 보통 tree형태로 표현하게 된다. 다음과 같은 tree를 Parse tree(or derivation tree)라고 한다. 위에서 아래로 읽으면 Derivation tree이고, 아래에서 위로 읽으면 Parse tree이므로 둘을 구분해서 나타내지는 않는다.

입력 문자열에 대한 Parsing을 진행할 때, 여러 방식으로 파싱될 수 있는 문법이 존재한다. 이러한 경우를 ambiguos(모호)하다라고 표현하는데, 하나의 문자열에 대한 여러개의 서로 다른 parse tree가 존재하므로 적절한 parsing 방법이 필요하다. 아래는 ambiguous grammer 예시이다.

"1 + 3 - 2" 가 2개의 서로 다른 parse tree로 표현된다

이러한 경우, 두 가지 방향의 derivation 중 하나를 선택해야 한다. Left-most derivation(좌측 우선 유도)와 Right-most derivation(우측 우선 유도) 중 하나로 일관되게 표현해야 한다. Left-most derivation과 Right-most derivation은 이름 그대로 가장 왼쪽 혹은 가장 오른쪽에 있는 non-terminal부터 유도를 한다는 뜻이다. 아래는 예시이다.

derivation의 방향을 결정했다면, parsing은 다음 2가지 중 하나를 결정하게 된다. Left-most derivation을 사용할 경우 LL parsing(top-down)을 진행하게 된다. top-down 형식은 parse의 방향이 derivation과 동일하다. 위에서부터 아래로, non-terminal로부터 입력 문자열을 만들어낼 수 있는지를 확인한다. Right-most derivation을 사용할 경우 LR parsing(bottom-up)을 진행하게 된다. bottom-up형식은 아래서부터 위로, 입력 문자열로부터 non-terminal을 만들어가는 것을 의미한다.

그래서 이렇게 parsing될 수 있는 문법들을 LL grammer / language, LR grammer / language라고 부르고, 이들은 모두 Context-free grammer의 부분집합이다.

LL and LR

LL grammer / language

▶ LL 파싱으로 인식될 수 있는 모호하지 않은 문법 / 언어

LR grammer / language

▶ LR 파싱으로 인식될 수 있는 모호하지 않은 문법 / 언어

LL(k) 또는 LR(k)도 존재하는데, 이때 k는 ambiguity(모호성)를 제거하기 위해 미리보는 토큰의 개수(lookahead)를 의미한다. 여기서 lookahead란, parsing할 때 "현재까지의 token을 어떤 non-terminal로 치환할 지 결정하기 위해, 미리 확인하는 토큰의 개수"를 의미한다.

예시로 LR(k) parsing을 진행한다고 하자. 그리고 입력 문자열이 "1 + 3 * 2" 라고 하자. 이때 lookahead가 0일 때 발생할 수 있는 문제를 생각해보자. 우선 lexing을 진행하면 token list가 만들어지고 해당 list에는 ['1'; '+'; '3'; '*'; '2']과 같은 형식으로 원소들이 존재할 것이다. 그리고 parsing을 진행하기 위해 stack을 만드는데, 이 stack은 push된 token에 대하여 termianl로 만들 수 있으면 무조건 만든다고 가정하자. 아래는 예시로 사용할 CFG이다.

lookahead가 0인 경우를 생각해보자.

lookahead가 0인 경우

1) list에서 '1'이 stack에 push되면 stack의 상태는 ['1']이고 '1'이 '1' ➝ 'N' ➝ 'E' 로 치환될 것이다

▶ stack = ['E']

2) list에서 '+'가 stack에 push되면 stack의 상태는 ['E'; '+']이고 치환할 수 있는 기호가 없으므로 다음으로 넘어간다.

▶ stack = ['E'; '+']

3) list에서 '3'이 stack에 push되면 stack의 상태는 ['E'; '+'; '3']이고 '3'이 '3' ➝ 'N' ➝ 'E'로 치환될 것이다.

▶ stack = ['E'; '+'; 'E'], 이때 'E + E' ➝ 'E'로 치환될 것이다.
▶ stack = ['E']

4) list에서 '*'가 stack에 push되면 stack의 상태는 ['E'; '*']이고 치환할 수 있는 기호가 없으므로 다음으로 넘어간다.

▶ stack = ['E'; '*']

5) list에서 '5'가 stack에 push되면 stack의 상태는 ['E'; '*'; '5']이고 '5'가 '5' ➝ 'N' ➝ 'E'로 치환될 것이다.

▶ stack = ['E'; '*'; 'E'], 이때 'E * E' ➝ 'E'로 치환될 것이다.

▶ stack = ['E']

6) 모든 token에 대하여 parsing을 하였을 때, stack에 남아있는 기호가 시작 non-terminal하나만 남았으므로
parsing이 성공적으로 끝났다.

그러나 연산의 우선순위가 정해지지 않아서 문제가 발생한다. 위 과정을 parse tree로 확인해보면 다음과 같다.

3 * 2 보다 1 + 3을 먼저 시행하므로 기대값과 계산값이 다를 수 있다.

따라서 lookahead가 필요하다. lookahead를 1로 설정하고 다시 생각해보자.

아까 'lookahead가 0인 경우' 의 3) 단계에서 'E + E' ➝ 'E'를 그림으로 나타내보자.

'E + E' 를 'E' 로 치환하기 전에 '*'를 lookahead로 보고 있으므로, 치환하지 않고 '*'를 stack에 먼저 push한다. 이후 '2'까지 push하고 stack의 값들을 top에서부터 치환하면 다음과 같은 parse tree를 얻을 수 있다.

'+' 연산보다 '*' 연산을 먼저 수행하므로 이번 parsing은 문제가 없는 것을 확인할 수 있다.

Abstract syntax tree(AST)

입력 문자열이 들어오면 "Lexical analysis" 단계에서 regular expression을 사용하여 문자열을 token stream으로 변경한다. token stream은 "Syntax analysis"단계에서 CFG에 따라 parsing되고 Abstract Syntax tree(AST)를 만들어낸다. 여기서 AST는 Parse tree와는 다르다.

Parse tree

Abstract Syntax Tree

[프로그래밍언어개론] OCaml basic - 3

PiLove — Tue, 18 Mar 2025 21:45:05 +0900

Recursive function

OCaml에서 재귀함수(Recursive function)은 rec 키워드와 함께 named function으로 정의되어야 한다. 아래는 코드 예제이다.

(* 아래 코드는 rec 키워드 없이 함수가 자기자신을 호출하므로 에러 발생 *)
let mult_all x =
  if x = 1 then 1
  else x * (mult_all (x - 1))
in
Format.printf "Result: %d\n" (mult_all 10)

(* 재귀함수는 아래와 같이 rec 키워드와 함께 사용 *)
let rec mult_all x =
  if x = 1 then 1
  else x * (mult_all (x - 1))
in
Format.printf "Result: %d\n" (mult_all 10)

Modules

OCaml에서는 모듈 시스템을 지원한다. 모듈이란 변수, 함수, 타입, 값 등을 그룹화하여 관리하는 단위이다. 이러한 변수, 함수, 타입, 값 등이 모인 모듈이 모여 또다른 모듈을 구성하기도 한다. .ml 파일 또한 여러개의 모듈로 구성된 모듈이다.

Modules

각각의 모듈은 자료(변수)와 행동(함수)로 구성

모듈의 이름은 반드시 대문자로 시작

▶operation.ml -> Operation

모듈 내의 변수 또는 함수에 접근 : [module_name].[var_name]

(* operation.ml 파일의 내용 *)
let def_val = 99
let add x y = x + y

(* main.ml 파일의 내용 *)
let _ =
  let _ = Format.printf "Result: %d\n" Operation.def_val in
    Format.printf "Result: %d\n" (Operation.add 3 7)

위에서 언급했듯이, 모듈이 모여서 모듈을 구성하기도 한다. 이는 모듈 내부에 모듈이 정의되어 있을 수 있다는 의미이며 이러한 모듈 내부에 정의된 모듈을 Nested module이라고 한다.

Nested modules

module [module_name] = struct [defs] end definition

▶파일이 곧 모듈이므로, 위 definition으로 생성된 모듈은 nested module이다.

▶module_name : 모듈의 이름이며 만드시 대문자로 시작해야 한다.

▶defs : definition들의 나열이다.

Nested 모듈에 접근: [module_name].[nested_module_name].[var_name]

(* operation.ml *)
module IntOp = struct
  let add x y = x + y
end

module FloatOp = struct
  let add x y = x + y
end

(* main.ml *)
let _ =
  let _ = Format.printf "Result: %d\n" (Operation.IntOp.add 3 7) in
  Format.printf "Result: %f\n" (Operation.FloatOp.add 3.0 7.0)

모듈을 open하면 다른 모듈의 변수에 접근할 때 모듈 이름을 생략할 수 있다.

Module opening

open [module_name]: 현 scope에서 모듈 내 변수를 모듈 이름 없이 접근

▶모듈 내의 definition들을 해당 위치에 붙여넣기 한 효과

(* Operation 모듈 개방 -> Operation 내부의 변수, 함수 등 앞에 "Operation." 생략하고 접근가능 *)
open Operation

let _ =
  let _ = Format.printf "Result: %d\n" (IntOp.add 3 7) in
  Format.printf "Result: %d\n" (FloatOp.add 3.0 7.0)

그러나, 위와 같은 방식에는 문제가 있다. 여러 모듈을 open하여 사용할 때, 같은 이름의 변수나 함수가 존재하면 conflict가 발생하게 된다. 아래 예제를 보자.

open Operation
open IntOp
open FloatOp

let _ =
  let _ = Format.printf "Result: %d\n" (add 3 7) in
  Format.printf "Result: %d\n" (add 3.0 7.0)

위 예제의 경우, IntOp와 FloatOp 두 모듈 모두 add라는 함수가 존재함에도 불구하고, 마지막으로 open된 FloatOp의 add만 사용하게 된다. 결국 FloatOp.add의 인자로 int가 전달되어 컴파일 오류가 발생하게된다.

이러한 경우에는 let - in expression을 사용하여 특정 scope내에서만 모듈을 개방해주면 된다.

Local module opening

let open [module_name] in [expression]

▶module_name: 개방할 모듈 이름

▶expression: 계산할 expression으로 module_name이 개방된 상태에서 계산

let _ =
  let open Operation.IntOp in
  let _ = Format.printf "Result: %d\n" (add 3 7) in
  let _ = Format.printf "Result: %d\n" (add 1 2) in
  let _ = Format.printf "Result: %d\n" (add 4 12) in
  Format.printf "Result: %d\n" (add 2 5)

모듈의 이름이 긴 경우 약자를 이용하여 모듈을 지칭할 수도 있다.

Module renaming

module [abbreviation] = [module_name]

▶ abbreviation: 모듈의 이름을 지칭할 약자

▶ module_name: 모듈 이름

module OI = Operation.IntOp
module F = Format

let _ = F.printf "Result: %d\n" (OI.add 3 7) in
let _ = F.printf "Result: %d\n" (OI.add 1 4) in
let _ = F.printf "Result: %d\n" (OI.add 4 12) in
F.printf "Result: %d\n" (OI.add 2 5)

Pattern matching

Pattern matching은 값의 형태에 따라 다른 행동을 수행하게 만드는 expression이다. match - with expression을 사용하며, 그 자체로 하나의 expression이므로 값으로 계산된다.

Pattern matching

match expression with
| pattern1 -> expression1
| pattern2 -> expression2
...
| patternN -> expressionN

코드의 수행 순서

▶expression 계산

▶계산 결과를 pattern1과 매칭

- pattern1이 상수인 경우 : expression의 계산 결과와 상수 값이 매칭 확인

- pattern1이 변수인 경우 : 변수에 expression의 계산 결과를 바인딩하고 매칭에 항상 성공

▶매칭 성공 시 expression1 실행 or 매칭 실패 시 pattern2와 매칭

match - with expression은 하나의 expression이므로 expression1 ~ expressionN까지 동일한 타입을 가짐

위에서 설명했듯이, pattern에 변수가 들어갈 경우, 변수는 값과 바인딩되고 항상 매칭에 성공한다. 따라서 match with expression이 하나의 값을 보장하기 위해서 마지막 pattern에 변수를 넣어 매칭이 성공됨을 보장하도록 만드는 것이 일반적이다. 아래는 이에 대한 간단한 피보나치 코드 예제이다.

module F = Format
module Fib = struct
  let rec fib i =
    match i with
    | 0 -> 0 (* when i is 0 *)
    | 1 -> 1 (* when i is 1 *)
    | n -> fib (n - 2) + fib (n - 1) (* otherwise *)
end

let _ =
  let _ = F.printf "Res: %d\n" (Fib.fib 0) in (* 0 *)
  let _ = F.printf "Res: %d\n" (Fib.fib 1) in (* 1 *)
  let _ = F.printf "Res: %d\n" (Fib.fib 2) in (* 1 *)
  F.printf "Res: %d\n" (Fib.fib 3) (* 2 *)

만약, 매칭이 성공됨을 보장하되 값과 바인딩한 변수는 사용하고 싶지 않을 경우에는 wildcard(_)를 사용하면 된다.

let _ =
  let even_or_odd i =
    match i mod 2 with 
    | 0 -> F.printf "Even\n" 
    | 1 -> F.printf "Odd\n" 
    | _ -> F.printf "Unknwon\n"

여기서 만약에 pattern matching의 마지막 pattern에 있는 wildcard를 빼면 컴파일 warning이 발생한다. 따라서 가급적이면 위와 같이 작성하는 것이 좋다.

Pattern matching을 사용할 때 ".." 기호를 사용하여 연속된 문자 또는 숫자에 대한 패턴을 생성할 수도 있다.

let _ =
  let is_lowercase c =
    match c with
    | 'a' .. 'z' -> true (* when c is 'a' or 'b' or ... or 'z' *)
    | _ -> false
  in
  let _ = F.printf "A : %b\n" (is_lowercase 'A') in (* false *)
  let _ = F.printf "W : %b\n" (is_lowercase 'W') in (* false *)
  let _ = F.printf "b : %b\n" (is_lowercase 'b') in (* true *)
  F.printf "z : %b\n" (is_lowercase 'z') (* true *)

튜플이나 리스트에 대해서도 패턴 매칭이 가능하다. 아래 코드는 튜플의 첫 번째 값이나 두 번째 값을 반환하는 코드이다.

let _ =
  let get_fst p =
    match p with (* p is a tuple containig two elements *)
    | (fst, _) -> fst (* fst is a binding occurrence for the first element *)
  in
  let get_snd p =
    match p with (* p is a tuple containig two elements *)
    | (_, snd) -> snd (* snd is a binding occurrence for the second element *)
  in
  let _ = F.printf "fst : %d\n" (get_fst (1, 3)) in (* 1 *)
  let _ = F.printf "fst : %d\n" (get_fst (2, 4)) in (* 2 *)
  let _ = F.printf "snd : %d\n" (get_snd (1, 3)) in (* 3 *)
  F.printf "snd : %d\n" (get_snd (2, 4)) (* 4 *)

아래는 리스트에 대한 패턴 매칭 코드 예제이다.

Type definition

OCaml은 사용자가 새로운 타입을 정의하는 것을 허용한다.

Type definition

type [type_name] = [type]

▶ type_name: 새로운 타입 이름(소문자)

▶ type: 기존 타입

아래는 string list를 새로운 타입으로 정의하여 사용하는 간단한 코드 예제이다.

(* string list를 str_list라는 새로운 이름의 타입으로 정의 *)
type str_list = string list

let _ =
  let is_empty (x : str_list) =
    match x with
    | [] -> true
    | _ :: _ -> false
  in
  let _ = F.printf "Res: %b\n" (is_empty []) in
  F.printf "Res: %b\n" (is_empty ["welcome";"to";"this";"class"])

여러 타입을 묶어서 타입으로 정의할 수도 있다. 이렇게 정의한 타입을 disjoint union(variant records)라고 부른다.

Disjoint union(Variant records)

type [type_name] = [name] (of [type]) | [name] (of [type])

▶ type_name: 새로운 타입 이름(소문자)

▶ name: 식별자(대문자로 시작)

- Called "Constructor"

▶ type: 기존 타입

▶ of [type]은 생략가능

아래는 이에 대한 코드 예제이다.

type number =
  | Zero
  | Integer of int
  | Float of float

let _ =
  let x : number = Zero in
  let y : number = Integer 3 in 
  let z : number = Float 3.0 in
  let n_list : number list = [x; y; z] in
  ()

[프로그래밍언어개론] OCaml basic - 2

PiLove — Mon, 17 Mar 2025 10:44:02 +0900

오늘은 저번 게시글에 이어서 OCaml 언어에 대해 좀 더 알아보는 시간을 가지려고 한다. 목차는 아래와 같다.

➤ Comment

➤ Standard input/output

Comment

OCaml은 다음과 같은 multiline comment만 지원한다.

(* 주석주석주석주석주석 *)

Java의 multiline comment(/* 주석주석주석주석 */) 과 동일하게 동작한다.

Standard input/output

OCaml에는 다양한 입출력 방식이 존재하나, 간단한 형태의 입출력은 다음을 활용한다.

Standard input/output

Standard input : OCaml의 built-in 함수 readline

▶사용자 입력을 문자열로 반환

Standard output : OCaml의 build-in 모듈 Format

▶모듈 Format에는 출력에 대한 다양한 함수를 지원

▶ https://ocaml.org/manual/5.3/api/Format.html 참고

아래는 표준 입출력에 대한 간단한 예제코드이다.

let _ = Format.printf "Input: " in (* Write "Input" on the output buffer *)
let _ = Format.print_flush () in (* Flush the output buffer *)
let x = read_line() in (* Get an input from the user *)
Format.printf "The user input is \"%s\"\n" x (* Write the input on the output buffer *)

Variables

OCaml에서 변수(variables)는 특정 값에 묶인(혹은 연결된)(binding) 식별자(identifier)를 나타낸다. 다른 언어에서와 달리 변수가 메모리 공간을 가리키는 것이 아니라 변수 자체가 값과 묶이게되는 개념이기 때문에 한 번 묶인 변수의 값은 변경 불가능(immutable)하다. 또한 모든 변수는 선언과 동시에 값에 묶여야만 한다.

변수의 선언 및 묶기(binding)은 let (-in) expression을 사용한다. 아래 코드를 참고하자.

let x = 3 in (* 변수 선언 및 scope 설정*)
Format.printf "x : %d\n" x

let을 통해 x라는 변수에 3이라는 값을 묶었다. 그리고 in을 통하여 x라는 변수의 scope를 설정하였다. scope란 변수를 사용할 수 있는 영역을 의미한다. 해당 영역을 벗어나면 변수 x는 사용이 불가능하다.

let (-in) binding

Global let binding은 변수 자체와 값을 연결(binding)하는 definition이다. 값에 이름을 붙인다고 생각하면 이해하기 편하다. 이전 게시글에서 expression은 값을 반환하는 코드 형태라고 설명했었는데, 해당 내용을 기억한 상태로 아래 내용을 보면 이해하기 쉽다.

형태

기본형 : let [variable] = [expression]

▶expression을 계산하고 계산 값을 variable에 바인딩한다.

▶이후 variable이 사용되면 해당 variable을 바인딩된 값으로 치환하여 계산한다.

▶변수 뿐 아니라 이름있는 함수를 정의할 수도 있다.

▶variable 자리에 Wildcard(_)를 사용하여 단순히 expression을 실행하는 용도로도 활용한다.

(OCaml에서는 사용하지 않는 값을 변수에 바인딩 하는 것을 금지)

기본형 : let [variable] = [expression1] in [expression2]

▶expression1을 계산하고 계산 값을 variable에 바인딩한다.

▶expression2를 계산하고 계산한 결과값을 반환한다.

▶이 때, variable이 사용되면 해당 variable을 바인딩 된 값으로 치환하여 계산한다.

▶결국, 그 자체로 하나의 expression이므로 expression2의 값을 반환한다.

다음은 let binding과 let-in binding 코드 예제이다.

let x = 3 (* 3을 x에 바인딩 *)
Format.printf "x : %d", x (* x에 바인딩된 값 3으로 치환되어 계산 *)
(* 
   바로 위의 코드는 expression이므로 값을 반환한다. 
   하지만 그 값을 사용하지 않기에 아래와 같이 수정해야 한다. 
 *)
let _ = Format.printf "x : %d", x


let x = 3 in let y = 1 in x + y
(* 
   1) x에 3이 바인딩되어 (let y = 1 in x + y)에서 사용된다. 
   2) y에 1이 바인딩 되어 (x + y)에 사용된다.
   3) 전체 코드 자체가 expression이므로 x + y 결과 값(4)을 반환한다.
 *)

Sequencing

OCaml에서의 sequencing은 연속적인 unit expression의 계산을 수행한다. 여기서 unit expression이란 unit 타입을 반환하는 expression을 의미한다. 이전 게시글에서 살펴보았듯이, unit타입은 값이 없는 것을 의미한다. 따라서 unit expression은 연산을 수행하지만, 반환값이 필요없는 expression을 의미한다.

이러한 unit expression을 연속적으로 수행하게 될 경우, 반환된 값 unit에 대해 어떤 처리도 하지 않았기 때문에 OCaml에서는 오류나 경고를 준다. 따라서, 모든 unit expression에 대한 처리가 필요한데, 이는 wildcard를 이용하거나 sequencing을 이용하여 처리할 수 있다. 아래 예제를 보자.

(* Sequencing 사용 *)
Format.printf "1\n";
Format.printf "2\n";
Format.printf "3\n"

(* Wildcard 사용 *)
let _ = Format.printf "1\n"
let _ = Format.printf "2\n"
let _ = Format.printf "3\n"

또한 sequencing을 사용할 땐, 아래와 같이 begin-end expression을 함께 사용하여 명시적으로 sequencing을 표기하는 것이 일반적이다. begin-end expression은 괄호 (...)와 동일한 효과이다.

begin
  Format.printf "1\n";
  Format.printf "2\n";
  Format.printf "3\n"
end

Functions

이전 게시글에서 알아보았듯이 OCaml에서 함수는 first-class value이다. first-class value의 특징은 다음과 같다.

First-class function

함수 자체가 expression

▶함수를 변수에 할당할 수 있다.

▶함수를 다른 함수의 인자로 전달할 수 있다.

▶함수가 다른 함수의 반환값이 될 수 있다.

기본형 : fun [param_list] -> [expression]

▶param_list: 인자가 바인딩 될 변수들의 나열 (띄어쓰기로 구분)

▶expression: 함수의 몸체이며, 해당 expression의 계산 결과가 곧 return value

하지만 fun을 이용해서 이름있는 함수를 정의하는 것은 불가능하다. 오로지 익명(anonymous) 함수만을 정의할 수 있다. 아래 코드를 확인하자.

(* anonymous함수 정의 *)
fun x -> x + 1
(* anonymous함수를 변수에 바인딩 했을 뿐, 여전히 함수의 이름은 없음 *)
let x = (fun x -> x + 1) in
Format.printf "result : %d" (x 3)

(* 여러개의 파라미터는 아래와 같이 뛰어쓰기로 구분 *)
let f = (fun x y -> x + y) in
Format.printf "result : %d" (f 3 5)

그렇다면, 이름있는 함수를 정의하는 방법은 무엇일까?

바로, let definition 혹은 let -in expression을 활용하면 된다.

이름있는 함수의 정의

기본형 : let [id] [param_list] = [expression]

▶id: 함수 이름

▶param_list: 인자가 바인딩 될 변수들의 나열 (띄어쓰기로 구분)

▶expression: 함수 몸체

기본형 : let [id] [param_list] = [expression1] in [expression2]

▶id: 함수 이름

▶param_list: 인자가 바인딩 될 변수들의 나열 (띄어쓰기로 구분)

▶expression1: 함수 몸체

▶expression2: 함수 정의 후 실행할 expression

이름있는 함수를 정의하고 해당 함수를 사용하는 방식은 익명함수를 정의하고 변수에 할당하여 해당 변수를 사용하는 방식과 동일한 동작을 수행한다. 아래는 코드예제이다.

(* 익명함수를 정의하고 변수에 바인딩 *)
let sum = fun x y -> x + y
let _ = Format.printf "Result: %d\n" (sum 3 7)

let sum = fun x y -> x + y in
Format.printf "Result: %d\n" (sum 3 7)

(* ---------------------------------------- *)

(* 위 코드와 동일하게 동작함 *)
(* 이름있는 함수를 정의하고 사용 *)
let sum x y = x + y
let _ = Format.printf "Result: %d\n" (sum 3 7)

let sum x y = x + y in
Format.printf "Result: %d\n" (sum 3 7)

Function type

함수의 타입은 arrow 형태로 표기한다. (type1 → type2)

type1은 파라미터의 type을 의미하며, type2는 함수 몸체 expression의 type을 의미한다.

여러 파라미터를 받는 경우, curried form으로 표기한다. curried form이란 여러개의 인자를 파라미터로 받는 경우, 순차적으로 표기하는 형태이다. 예를 들어 int type의 파라미터를 2개 받으면 int → int → type2 로 표기한다.

아래 예제를 보자. 주석을 제대로 이해하는 것이 중요하다.

(* inc : int -> int *)
let inc x = x + 1

(* sum : int -> int -> int *)
let sum x y = x + y

let sum x y = x + y in (* sum : int -> int -> int *)
let sum' = sum 1 in 
(* 
  sum' : int -> int
  원래 sum이 int → int → int 이지만,
  sum'에서 인자로 1 하나만 넘기고 있다.
  따라서, sum 1의 연산 결과인 y → y + 1이 새로운 함수가 된다.
  이를 sum 1에 대입하면 let sum' = y → y + 1 in 이 되므로
  sum'의 type : int → int
*)

let res = sum' 3 in 
(*
  res : int
  sum'에서 설명한 주석을 이해했다면, res의 type이 왜 int 인지 쉽게 이해가 가능하다.
  sum'은 y → y + 1 인데, 여기에 3을 넘겼으므로 4라는 상수 함수가 된다.
  이 결과를 sum' 3에 대입하면, let rest = 4 in 이 되므로
  rest의 type : int
*)

Format.printf "Result: %d\n" res (* the result is 4 *)

Tuple & List

Tuple은 연속된 값을 저장하는 자료구조이다.

Tuple

기본형 : any1, any2, any3 or (any1, any2, any3)

▶쉼표를 사용하여 생성한다.

서로 다른 타입을 하나의 tuple에 저장할 수도 있다.

▶ex) 0, (1, 2, 3, 'c', "hi")

Tuple의 타입은 *를 사용하여 표기한다.

▶ex) 0, (1, "hi") : int * (int * string) / 튜플에 괄호를 사용했을 경우, 타입을 표기할 때도 괄호 사용

let 또는 let - in으로 tuple의 각 원소를 변수에 바인딩 할 수 있다.

▶ex) let x, y = (1, 3)

List는 tuple과 다르게 모든 원소의 타입이 동일하다.

List

기본형 : [1; 2; 3; 4]

▶대괄호([])로 리스트 생성

▶세미콜론으로 원소 구분

리스트의 타입 표기 : [type] list

▶type : 원소의 타입

▶ex) int list

연산자 '::'

▶리스트 앞에 원소를 삽입하여 새로운 리스트 반환

▶ex) 0 :: [1; 2; 3] --> [0; 1; 2; 3]

연산자 '@'

▶두 리스트를 연결하여 새로운 리스트 반환

▶ex) [1; 2; 3] @ [4; 5; 6] --> [1; 2; 3; 4; 5; 6]

OCaml은 List에 대한 내장 라이브러리를 지원하는데, 아래는 자주 사용하게 될 함수이니 참고하자.

Library for List

List.map [function] [list]

▶list에 존재하는 모든 원소에 대하여 function 수행 후 새로운 리스트 반환

▶type : ('a -> 'b) -> 'a list -> 'b list

('a -> 'b)는 파라미터로 받은 함수의 타입을 의미한다.

-> 'a list는 파라미터로 받은 리스트의 타입을 의미한다.

-> 'b list는 List.map의 수행 결과의 타입을 의미한다.

List.fold_left [function] [init] [list]

▶list에 존재하는 모든 원소에 대하여 왼쪽 원소부터 init과 function 수행한 후 누적 값 계산

▶type : ('b -> 'a -> 'b) -> 'b -> 'a list -> 'b

('b -> 'a -> 'b)는 파라미터로 받은 함수의 타입을 의미한다.

-> 'b는 init의 타입을 의미한다.

-> 'a list는 파라미터로 받은 리스트의 타입을 의미한다.

-> 'b는 List.fold_left의 수행 결과의 타입을 의미한다.

https://caml.inria.fr/pub/docs/manual-ocaml/libref/List.html

Conditional branch

if - then - else expression을 통해 분기문을 작성한다.

if - then - else

기본형 : if [expression1] then [expression2] else [expression3]

▶Expression1 을 계산

(Expression1은 반드시 bool 타입)

▶계산된 결과가 true인 경우, expression2를 계산하고 이 결과가 전체 expression의 값

▶계산된 결과가 false인 경우, expression3을 계산하고 이 결과가 전체 expression의 값

if - then - else도 그 자체로 expression이므로, 하나의 값으로 계산된다. 즉, 값을 반환하는 expression이다. 이러한 expression은 항상 하나의 타입을 가져야 하므로, expression2와 expression3에나 같은 타입의 expression이 위치해야만 한다. if - then - else 전체의 타입을 통일해야 하기 때문이다.

아래는 해당 내용을 포함한 코드 예제이다.

let is_odd x =
if x mod 2 = 0 then false (* bool *)
else 0 (* int *)
in
Format.printf "Res: %b\n" (is_odd 3)

(* 
  위 코드는 에러가 발생한다.
  expression2와 expression3의 타입이 동일하지 않기 때문이다.
  따라서 아래 코드와 같이 수정해줘야 한다.
*)

let is_odd x =
if x mod 2 = 0 then false (* bool *)
else true (* bool *)
in
Format.printf "Res: %b\n" (is_odd 3)

[프로그래밍언어개론] OCaml basic - 1

PiLove — Sat, 15 Mar 2025 10:18:14 +0900

➤ OCaml?

➤ Primitive types

➤ Basic compilation using Dune

➤ Statement? Expression?

Ocaml?

OCaml은 Caml에 객체지향(OOP)개념을 추가하여 확장한 프로그래밍 언어이다.

아래는 OCaml언어의 대표적인 특징이다.

특징

Functional programming language

▶ 함수는 first-class values (함수도 변수처럼 사용 가능하다)

Strongly typed language

▶ 모든 변수 및 표현식의 타입은 컴파일 시점에 결정

Type inference

▶ 타입 시스템이 변수 및 표현식의 타입을 추론

Polymorphism

▶ 데이터 구조 및 알고리즘을 일반적으로 구현

Pattern matching

▶ Case 분석 지원

Module system

▶ 프로그램을 여러 모듈로 나누어 구현

Primitive types

1. unit

unit 타입은 "()" 하나로 구성된 singleton 집합이다. "아무것도 없음"을 나타내는 값으로 C/C++, Java의 void타입과 유사하다. OCaml의 모든 표현식은 반드시 값으로 계산되고 존재한다. 따라서 C/C++, Java의 void와는 다르게 unit이 반환되면 "아무것도 없음"을 나타내는 값이 반환된 것이다. C/C++, Java의 void처럼 아무것도 반환하지 않는 것이 아니다.

() 값을 통해 "아무것도 없음" 을 표현한다는 것을 기억하면 좋을 것 같다.

2. Int

int 타입은 모든 정수의 집합이다.

3. float

float 타입은 모든 실수의 집합이다.

4. char

char 타입은 모든 문자의 집합이다.

5. bool

bool 타입은 true와 false로 이루어진 집합이다. 여기서 조심해야 할 부분이 있다. 아래 그림을 확인해보자.

위 그림을 보면, 같은 값을 가지는 List에 대해 '='와 '=='의 결과가 다른 것을 확인할 수 있다. 그 이유는 OCaml의 '='는 structural equality(구조적 동등성)을 확인하고 '=='는 physical equality(물리적 동등성)을 확인하기 때문이다. 따라서, '='의 경우 비교하는 두 리스트의 값이 같기 때문에 true를 반환하고, '=='의 경우 두 리스트의 물리적인 주소, 즉 두 리스트 자체가 서로 같은 지를 검사하기 때문에 false를 반환하는 것이다.

Basic compilation using Dune

1. Dune?

Dune이란, C/C++의 Makefile과 같이 OCaml 프로젝트를 쉽게 컴파일하고 실행할 수 있도록 도와주는 빌드 시스템이다.

2. How to use?

Dune을 사용하여 프로그램을 컴파일하는 기본적인 방법은 다음과 같다.

우선 실행하고자 하는 파일 디렉토리 내에 dune 파일을 생성한 후, 아래와 같이 작성한다.

(inclue_subdirs unqualified)
(excutable (name hello_world))

▶ (inclue_subdirs unqualified) :

현재 디렉토리를 포함하여 하위 디렉토리의 모든 소스파일을 하나의 프로젝트 코드처럼 간주한다는 의미이다.

좀 더 쉽게 말하자면, 현재 디렉토리 아래의 모든 .ml파일들을 하나의 폴더 안에 있는 것처럼 취급한다는 의미이다.

▶ (excutable (name hello_world)) :

hello_world.ml 파일을 프로그램의 entry point(다른 언어의 표현으로 main)로 간주하고,

실행가능한 바이너리 파일로 컴파일한다.

이렇게 작성한 dune 파일에 대하여 아래 명령어를 실행하면 hello_world.ml 파일을 .exe 파일로 컴파일 할 수 있다.

dune build hello_world.exe

명령어 실행 후, 디렉토리의 파일 구조를 살펴보면 다음과 같다.

이렇게 생성된 실행파일(hello_world.exe)을 실행하기 위해서는 아래 명령어를 한번 더 작성해야 한다.

_build/default/hello_world.exe

그러나 위와 같은 방식은 (compile -> execute) 과정을 두 번에 나누어서 진행하기 때문에 코드를 수정할 때마다 두 번의 명령어를 작성해야 한다.

따라서 코드를 수정해야 할 일이 많을 경우, exec이라는 명령어를 활용한다.

dune exec ./hello_world.exe

exec 명령어를 수행하면 (compile -> execute) 과정을 한 번에 진행하기 때문에 좀 더 편하게 사용 가능하다. 물론, 시간은 더 오래 걸릴 수 있다.

Statement? Expression?

Statement? Expression?

Statement(구문)와 Expression(표현식)은 프로그래밍 언어의 구성 요소이다. 언어에 따라 statement와 expression이 명확하게 분리되지 않는 경우도 존재하지만 우선 일반적인 경우를 확인해보자.

Feature of (Statement & Expression)

Statement

▶프로그램의 동작을 수행하는 코드이다. 값을 반환하지 않는 코드라고 이해하면 편하다.

Expression

▶값으로써 계산되는 코드이며, 값을 반환하는 코드이다.

▶실행 전과 실행 후의 메모리 상태가 동일하다.

Expression의 특징을 살펴 보면 "실행 전과 실행 후의 메모리 상태가 동일하다" 라는 특징이 있다. OCaml의 변수는 기본적으로 Immutable(불변성)한 특성을 가지고 있다. 따라서, OCaml의 대부분의 코드들은 expression으로 이루어져 있다. 그렇다고 해서 OCaml이 expression으로만 구성되는 pure functional language(순수 함수형 언어)인 것은 아니다.

다음 게시글에서는 OCaml의 comment, I/O, variable, function, let-in 등등 OCaml언어의 기본적인 내용들을 알아보자.