이어폰 ANC는 귀 근처에서 직접 소음을 상쇄하지만, 헤드보드 ANC는 공간에서 전달되는 소리를 제어해야 한다.
따라서 단순히 “코골이는 시끄럽다”는 수준이 아니라 다음 질문에 답할 필요가 있었다.

• 어떤 주파수 대역에 에너지가 집중되는가
• 실제 코골이 샘플들은 얼마나 다양한 구조를 가지는가
• ANC가 실제로 겨냥해야 할 주파수 대역은 어디인가

이 글은 snoring_analysis 노트북과 분석 결과 CSV를 기반으로 정리한 코골이 오디오 신호 분석 기록이다.

1. 프로젝트 배경과 목표

이번 분석의 목표는 다음과 같다.

코골이의 주파수 구조를 분석하고 이를 ANC 설계의 입력 정보로 연결하는 것

특히 다음 세 가지 질문에 집중했다.

1. 코골이는 실제로 저주파 중심 소리인가
2. 모든 코골이가 비슷한 주파수 구조를 가지는가
3. ANC 타깃 주파수 대역을 현실적으로 어디로 설정해야 하는가

이를 위해 다음과 같은 분석 파이프라인을 구성했다.

분석 파이프라인

• 파형 시각화
• FFT 분석
• 스펙트로그램 분석
• 80~300Hz 대역통과 필터 적용
• 파일 단위 정량 지표 계산
• Snore Index 기반 유형 분류
• 세그먼트 추출 후 분포 및 상관 분석

2. 데이터셋과 전처리

이번 분석에서는 29개의 코골이 오디오 파일을 사용했다.

비침묵 구간을 기준으로 코골이 세그먼트를 추출한 결과:

• 총 세그먼트 수: 1,444개
• 파일당 평균 세그먼트: 약 49.79개

세그먼트 수가 많은 파일

• freesound_community-snoring-50041.mp3 : 601개
• freesound_community-snoring-6773.mp3 : 282개
• freesound_community-soft-female-snoring-17325.mp3 : 101개

세그먼트 수가 적은 파일

• freesound_community-snoring-long-78149.mp3 : 1개
• freesound_community-snoring-42710.mp3 : 3개
• freesound_community-snoring-67961.mp3 : 3개

이 분포만 보더라도 코골이 데이터는 매우 비균일한 특성을 가진다.

같은 “snoring” 라벨이라도 다음과 같은 형태가 섞여 있다.

• 길게 이어지는 단일 이벤트형 코골이
• 짧은 burst 반복형 코골이
• 호흡음 또는 환경음이 섞인 샘플

이러한 다양성은 이후 분석에서 등장하는 Snore Index 편차와도 연결된다.

3. 파일 단위 분석

3-1. 파형 (Waveform)

시간 영역 파형을 보면 코골이는 보통 다음 패턴을 가진다.

1. 호흡과 함께 에너지가 증가
2. 짧은 burst 발생
3. 다시 에너지 감소

즉 코골이는 연속적인 noise라기보다 이벤트성 저주파 burst의 반복에 가깝다.

예시 파일 mollyroselee-a-person-snoring-468533.mp3

이 결과는 코골이가 단순한 작은 잡음이 아니라 상당한 에너지를 가진 신호임을 보여준다.

3-2. FFT 분석

시간 영역 분석만으로는 소리의 크기만 확인할 수 있다.
ANC 설계에서는 에너지가 집중된 주파수 대역이 더 중요하다.

그래서 FFT를 적용했다.

FFT 결과 (예시 파일)

이 샘플의 경우 전체 에너지의 약 70%가 80~300Hz 대역에 집중되어 있었으며
가장 강한 피크는 약 136Hz 부근에 존재했다.

즉 이 코골이는 전형적인 저주파 dominant 코골이라고 볼 수 있다.

3-3. 스펙트로그램

FFT는 전체 주파수 분포를 보여주지만,
스펙트로그램은 시간에 따른 주파수 변화를 보여준다.

스펙트로그램 요약

여기서 중요한 점은 다음이다.

FFT 기준으로 보면 코골이는 저주파 중심이지만,
시간 단위로 보면 더 높은 주파수 성분도 함께 나타난다.

즉 코골이는 단일 톤이 아니라 다음이 결합된 복합 음향 신호에 가깝다.

• 기도 저주파 진동
• 호흡 난류
• 비강/구강 공명
• 녹음 환경에서 발생한 broadband 성분

3-4. 80~300Hz 대역통과 필터

코골이 연구에서 자주 등장하는 가설은 다음과 같다.

코골이의 주요 에너지는 80~300Hz 저주파 대역에 집중된다.

이를 검증하기 위해 80~300Hz band-pass filter를 적용했다.

필터 적용 결과

RMS는 약간 감소했지만, 대부분의 에너지가 여전히 80~300Hz에 남아 있었다.

이는 이 샘플에서 저주파 대역이 코골이 핵심 성분임을 의미한다.

4. 정량 지표와 Snore Index

파일 단위 분석에서는 다음 지표들을 계산했다.

• spectral centroid
• spectral bandwidth
• spectral rolloff
• RMS energy
• dominant frequency
• snore_index

Snore Index 정의

Snore Index = (80~300Hz 에너지) / (20Hz 이상 전체 에너지)

즉 전체 코골이 에너지 중 저주파 대역이 차지하는 비율을 의미한다.

Snore Index 분포

해석

1. 모든 코골이가 저주파 dominant는 아니다

평균이 0.34라는 것은 저주파만으로 코골이를 설명할 수 없다는 의미다.

실제 코골이는

저주파 진동 + 광대역 성분

의 결합으로 보는 것이 더 적절하다.

2. 편차가 매우 크다

최소값 0.01, 최대값 0.89라는 결과는
코골이 스펙트럼 구조가 샘플마다 크게 다르다는 것을 의미한다.

3. ANC에 적합한 코골이도 존재한다

3사분위수 값이 약 0.59라는 것은
상위 25% 코골이는 저주파 중심 구조를 가진다는 의미다.

즉 일부 코골이는 ANC로 효과적으로 제어될 가능성이 높다.

5. 세그먼트 단위 분석

파일 평균만 보면 burst 특성이 희석된다.
그래서 비침묵 구간을 기준으로 세그먼트 단위 분석을 진행했다.

핵심 분석 대상은 다음 두 가지였다.

• dominant frequency 분포
• Snore Index 분포

5-1. dominant frequency 분포

세그먼트 단위 dominant frequency는 대부분

약 30~150Hz 구간

에 집중되어 있었다.

이는 기존 연구에서 말하는 80~300Hz보다 낮아 보일 수 있지만, 실제로는 모순이 아니다.

코골이는 보통 다음 구조를 가진다.

• fundamental: 50~100Hz
• 고조파: 2배, 3배 주파수

따라서

• dominant frequency: 30~150Hz
• 에너지 중심 대역: 80~300Hz

이라는 결과는 충분히 일관된 해석이다.

5-2. 세그먼트 분석의 의미

세그먼트 단위 Snore Index를 보면 다음 특징이 나타난다.

• 낮은 값의 세그먼트
• 매우 높은 값(0.6~0.9)의 세그먼트

즉 순수 코골이 burst와 혼합 신호가 명확히 구분된다.

이 결과는 ANC 설계에서 중요한 의미를 가진다.

ANC를 항상 작동시키기보다
저주파 dominant burst에만 강하게 반응하는 구조가 더 효율적일 수 있다.

6. ANC 설계로 이어지는 인사이트

이번 분석에서 얻은 주요 인사이트는 세 가지다.

6-1. 타깃 대역 설정

• 주 제어 대역: 80~300Hz
• 보조 관측 대역: 30~80Hz

세그먼트 분석 결과를 고려하면 더 낮은 주파수도 함께 관측하는 것이 현실적이다.

6-2. 코골이 유형별 ANC 전략 필요

Snore Index 편차가 매우 크기 때문에
모든 코골이에 동일한 ANC 전략을 적용하는 것은 비효율적이다.

• 저주파 dominant 코골이 → ANC에 매우 적합
• 광대역 코골이 → ANC만으로는 제한적

6-3. 공간 ANC 접근의 필요성

코골이는 머리 근처에서 발생해 방 전체로 퍼지는 저주파 소리다.

따라서 문제는 귀 근처 제어가 아니라 공간 음향 제어에 가깝다.

이 점에서 헤드보드 ANC 또는 multi-channel ANC가 자연스러운 접근이 된다.

7. 한계와 다음 단계

한계

공개 오디오 데이터셋 특성

녹음 환경이 서로 다르다.

• 마이크 거리
• 배경 소음
• mp3 압축
• 방 반사

세그먼트 추출 방식

librosa.effects.split은 비침묵 탐지일 뿐
코골이 자체를 분류한 것은 아니다.

ANC 성능 검증 미포함

이번 글은 분석 단계이며
실제 ANC 성능 검증은 별도 실험이 필요하다.

마무리

이번 분석에서 확인한 핵심은 다음과 같다.

코골이는 단순한 “시끄러운 소리”가 아니라
저주파 진동과 광대역 성분이 결합된 복합 음향 현상이다.

그리고 그 안에서 ANC에 매우 적합한 저주파 dominant 코골이도 분명 존재한다.

즉 헤드보드 ANC는 막연한 아이디어가 아니라
실제 스펙트럼 데이터를 기반으로 설계 가능한 문제라는 점이 이번 분석의 가장 큰 수확이었다.

코골이를 줄이기 위해 착용형 기기가 아니라 침대 머리맡에서 소음을 줄이는 시스템을 만들고 있다.

이어폰처럼 귀에 착용하는 방식이 아니라 침대 헤드보드에서 코골이 소음을 줄이는 ANC 시스템이다.

이 글에서는 개발하면서 정리한 Active Noise Control (ANC)의 개념을 설명한다.

설명 순서는 다음과 같다.

Active Noise Control이란 무엇인가 ANC의 물리적 원리 ANC 시스템 구조 ANC 알고리즘 (LMS, FxLMS) 실제 제품(이어폰)의 ANC 구조 최신 ANC 기술 헤드보드 ANC에서 중요한 포인트

Active Noise Control이란

Active Noise Control (ANC)은 소음을 막는 것이 아니라 상쇄시키는 기술이다.

일반적인 방음은

소음 → 차단

방식이지만 ANC는

소음 + 반대 위상의 소리 = 소리 감소

원리를 이용한다.

이를 Destructive Interference (상쇄 간섭)라고 한다.

간단히 표현하면

noise + anti_noise = 0

이 되는 방향으로 소리를 만든다.

ANC의 물리적 원리

소리는 공기 압력의 진동(파동)이다.

파동은 보통 다음과 같이 표현된다.

x(t) = A * sin(ωt)

각 기호의 의미

반대 위상의 소리는

-A * sin(ωt)

두 소리를 합치면

A*sin(ωt) + (-A*sin(ωt)) = 0

즉 소리가 상쇄된다.

하지만 현실에서는 다음 문제가 있다.

지연 (delay) 반사 (reflection) 공간 전달 (acoustic transfer)

그래서 단순히 반대 파형을 만드는 것만으로는 충분하지 않다.

ANC 시스템 구조

ANC 시스템은 보통 다음 4가지 구성으로 이루어진다.

구조는 다음과 같다.

Noise source
      ↓
Reference Mic
      ↓
Controller (DSP)
      ↓
Speaker
      ↓
Error Mic

시스템의 목표는 남은 소리를 최소화하는 것이다.

e(n) = d(n) + y(n)

각 변수의 의미

목표

e(n) → 0

ANC에서 중요한 두 경로

ANC에서는 두 가지 전달 경로가 존재한다.

Primary Path - 원래 소음이 전달되는 경로

Noise source → 공기 → 귀

수식

d(n) = P(z) * x(n)

이 Secondary Path 때문에 ANC가 어려워진다.

왜냐하면

거리 공기 반사

때문에 위상 변화와 지연이 생기기 때문이다.

ANC 알고리즘

ANC의 핵심은 Adaptive Filter (적응형 필터)이다.

LMS (Least Mean Square)

가장 기본적인 적응 알고리즘

w(n+1) = w(n) + μ * e(n) * x(n)

즉, error가 줄어드는 방향으로 필터 계수를 계속 업데이트한다.

FxLMS (Filtered-x LMS)

ANC에서 가장 많이 사용되는 알고리즘이다.

핵심 아이디어

Secondary Path를 고려해서 입력을 먼저 필터링한다.

x'(n) = S(z) * x(n)

업데이트

w(n+1) = w(n) + μ * e(n) * x'(n)

즉, FxLMS = LMS + 음향 경로 보정 대부분의 ANC 연구와 제품은 FxLMS 기반이다.

Feedforward vs Feedback ANC

ANC 구조는 크게 두 가지다.

Feedforward ANC : 소음을 미리 측정한다.

Noise → Reference mic → Controller → Speaker

장점 - 저주파 소음 제거에 강함 단점 - reference mic 필요

Feedback ANC

error mic만 사용한다.

Speaker → Error mic → Controller

장점 - 구조 단순 단점 - 안정성 문제 가능

Hybrid ANC 실제 제품은 대부분 Feedforward + Feedback 구조를 사용한다.

실제 이어폰 ANC 구조

예를 들어 AirPods 같은 제품은 다음 구조를 사용한다.

구성

• 외부 마이크
• 내부 마이크
• DSP
• 스피커

신호 흐름

외부 소음
   ↓
외부 마이크
   ↓
DSP
   ↓
스피커
   ↓
귀
   ↓
내부 마이크

DSP는

소음 분석 anti-noise 생성 error correction

을 초당 수만 번 반복한다.

최신 ANC 기술

최근 ANC 시스템은 단순 FxLMS만 사용하지 않는다.

Multi-band ANC

주파수 대역별로 ANC 수행

Low band ANC
Mid band ANC
High band ANC

Directional Filtering

여러 마이크로 소리 방향을 계산

Mic array → sound direction

이를 Beamforming이라고 한다.

ML Noise Classifier

AI가 소음 종류를 분류한다.

자동차 사람 목소리 엔진

그리고 ANC 강도를 조절한다.

ANC의 한계

ANC는 모든 소음을 제거하지 못한다.

특히 고주파 소음은 어렵다.

파장 공식

λ = c / f

고주파는

파장이 짧고

위상 오차에 민감하다.

그래서 ANC는 보통

20Hz ~ 500Hz

영역에서 가장 효과적이다.

헤드보드 ANC에서 중요한 포인트

헤드보드 ANC는 이어폰 ANC와 다른 문제가 있다.

공간이 크다

이어폰

speaker → ear

헤드보드

speaker → 공기 → 머리 위치

Multi-channel ANC 필요 여러 스피커

Spk1 Spk2 Spk3

여러 마이크

Mic1 Mic2 Mic3

즉

Multi-channel ANC

Secondary Path 변화

사람이 움직이면

S(z) 변화

그래서 adaptive control이 중요하다.

정리

ANC 시스템의 핵심은 다음 네 가지다.

파동 상쇄 (Destructive interference) 적응 필터 (LMS / FxLMS) 음향 전달 경로 모델링 실시간 DSP 제어

실제 제품에서는

Adaptive filter
+ Multi-band processing
+ Beamforming
+ ML noise detection

같은 기술이 함께 사용된다.

마무리

다음 글에서는 실제로 만들고 있는

헤드보드 ANC 시스템 아키텍처 코골이 주파수 분석 코골이 특화 ANC 알고리즘

을 정리해볼 예정이다.

"??? : ㅋㅋ SQL 왜 배우냐? ORM 쓰면 되는데" 이렇게 말하는 거 들어보시지 않으셨나요? 저희들이 농담삼아 많이 하는 말인데요. 이러면서 누구에게 가르쳐 줄 때는 SQL을 반드시 배우라고 조언을 해줍니다. 그럼 왜 그런지 알아보도록 하겠습니다.

SQL과 ORM

SQL이란?

Structured Query Language의 약자로, 관계형 데이터베이스 관리 시스템(RDBMS)의 데이터를 관리하기 위해 설계한 특수 목적의 프로그래밍 언어입니다.

ORM이란?

Object Relational Mapping의 약자로, 객체와 데이터베이스를 연결해 주는 도구입니다. 프로그래밍 언어의 객체와 관계형 데이터베이스 사이의 중계자 역할을 합니다.

ORM의 장점은?

1. 객체 지향적인 코드로 인해 더 직관적이고 비즈니스 로직에 더 집중할 수 있게 도와준다.
2. SQL Query가 아닌 메서드로 데이터를 조작할 수 있어 개발자가 객체 모델로 프로그래밍하는 데 집중할 수 있도록 도와준다.

ORM의 단점과 한계점은?

1. 성능 문제 - 비효율적인 쿼리를 날릴 수 있습니다. N + 1 문제와 같이 연관 데이터를 조회할 때, 불필요하게 많은 쿼리가 실행되어 성능 저하를 일으킬 수 있습니다.

2. 런타임 오류 가능성 - ORM은 내부적으로 SQL을 자동 생성하므로, 직접적인 SQL 작성이 줄어드는 대신 컴파일 시점에 쿼리 오류를 확인하기 어렵습니다.

3. ORM 프레임워크 자체의 복잡성 - ORM은 초보자에게는 SQL 쓰지 않아 쉽게 느껴질 수 있지만, 고급 기능을 제대로 이해하지 못하면 버그나 성능 저하를 발생시킵니다.

ORM만 사용하면 어떻게 될까?

편리해 보이지만, 복잡한 통계 쿼리, 성능이 중요한 대용량 조회 등에서는 오히려 비효율적인 방식이 될 수 있습니다.

SQL만 사용하면 어떻게 될까?

쿼리 작성시에 오류를 즉각 알 수 있고, 성능을 최적화 할 수 있습니다. 하지만 기본적인 CURD 작업에도 일일이 쿼리를 작성해야 한다는 단점이 생산성을 저하시키고 코드 중복을 초래할 수 있습니다.

SQL과 ORM을 균형있게 활용하자

ORM이 이러한 문제를 가졌기에 ORM과 SQL을 같이 사용하며 성능 문제, 런타임 오류 가능성과 같은 문제점을 해결할 수 있다.

균형있게 사용하기 위한 방법

1. 복잡한 쿼리나 성능이 중요한 부분은 SQL로 처리합니다.
2. 간단한 CURD, 혹은 성능이 중요하지 않은 부분은 ORM으로 처리해도 됩니다.
3. ORM과 SQL을 같이 사용합니다. 보통 ORM은 직접 쿼리를 날리는 기능도 메서드로 구현되어 있어 직접 SQL을 실행할 수 있습니다.

글을 쓴 나의 생각

저는 Spring의 ORM인 JPA를 사용해 본 경험이 있습니다. 초기에는 어떻게 메서드를 정의해야 할지 몰라 CustomRepository를 직접 만들어 쓰기도 했고, JPQL 메서드 이름을 잘못 작성해서 원하는 쿼리가 생성되지 않아 한참을 헤맨 적도 있습니다. 특히 update를 할 때, JPA가 해당 레코드를 삭제하고 새로 생성해버리는 바람에 오류가 났고, 그 원인을 찾느라 이틀 이상 고민했던 기억이 납니다. 이처럼 JPA는 분명 강력한 도구지만, 내부 동작을 정확히 이해하지 않으면 예상치 못한 버그로 이어질 수 있습니다. 결국 저는 SQL을 어느 정도 알고 있었기에 이 문제를 해결할 수 있었고, 그래서 지금도 복잡한 상황에서는 SQL을 더 선호합니다.

참고자료

https://ko.wikipedia.org/wiki/SQL https://gmlwjd9405.github.io/2019/02/01/orm.html

개발을 하다 보면 이런 말을 종종 듣을 수 있습니다. "유지보수가 어렵다", "코드가 너무 얽혀 있다", "기능 하나 수정했는데 다른 데서 에러가 난다"는 문제를 자주 마주하게 됩니다. 이럴 때 등장하는 것이 바로 SOLID 원칙입니다.

SOLID는 객체지향 설계의 5가지 원칙을 뜻하며, 코드를 유지보수하기 쉽고 확장 가능하며 유연하게 만드는 데 도움을 줍니다.

🏆SOLID

SOLID는 5가지 원칙의 앞 글자를 딴 것입니다.

S : 단일 책임 원칙 (Single Responsibility Principle) O : 개방/폐쇄 원칙 (Open/Closed Principle) L : 리스코프 치환 원칙 (Liskov Substitution Principle) I : 인터페이스 분리 원칙 (Interface Segregation Principle) D : 의존 역전 원칙 (Dependency Inversion Principle)

S: 단일 책임 원칙

"한 클래스는 하나의 책임만 가져야 한다."

• 즉, 클래스는 하나의 기능 또는 역할만 가져야 하며, 하나의 변경 이유만 있어야 합니다.

❌ 위반 예시

@Service
public class UserService {

    private static final Logger logger = LoggerFactory.getLogger(UserService.class);

    public static UserService createUserService() {
        logger.info("UserService 인스턴스 생성됨");
        return new UserService();
    }

    public void registerUser(String username) {
        logger.info("유저 등록 시도: {}", username);
        // 사용자 저장 로직 (예: DB 저장)
        System.out.println(username + " 등록 완료");
    }

    public void sendWelcomeEmail(String username) {
        logger.info("환영 이메일 전송: {}", username);
        // 이메일 전송 로직
        System.out.println("환영 이메일 전송 완료: " + username);
    }
}

문제점

UserService가 너무 많은 책임을 가지고 있습니다

1. 인스턴스 생성 로직 (팩토리 메서드)
2. 유저 등록 (비즈니스 로직)
3. 이메일 전송 (외부 시스템 연동)
4. 로깅 (로깅도 일종의 부가 책임)

✅개선한 예시

// 도메인 객체
class User {
    private String username;

    public User(String username) {
        this.username = username;
    }

    public String getUsername() {
        return username;
    }
}

// 이메일 전송 책임
@Service
class EmailService {
    private final Logger logger = LoggerFactory.getLogger(EmailService.class);

    public void sendWelcomeEmail(User user) {
        logger.info("환영 이메일 전송: {}", user.getUsername());
        // 실제 이메일 전송 코드
        System.out.println("환영 이메일 전송 완료: " + user.getUsername());
    }
}

// 유저 등록 로직
@Service
class UserService {
    private final EmailService emailService;
    private final Logger logger = LoggerFactory.getLogger(UserService.class);

    public UserService(EmailService emailService) {
        this.emailService = emailService;
    }

    public void registerUser(User user) {
        logger.info("유저 등록 시도: {}", user.getUsername());
        // DB 저장 로직
        System.out.println(user.getUsername() + " 등록 완료");

        emailService.sendWelcomeEmail(user);
    }
}

// 팩토리 메서드 책임 분리
@Component
class UserServiceFactory {
    private final EmailService emailService;

    public UserServiceFactory(EmailService emailService) {
        this.emailService = emailService;
    }

    public UserService create() {
        Logger logger = LoggerFactory.getLogger(UserServiceFactory.class);
        logger.info("UserService 인스턴스 생성됨");
        return new UserService(emailService);
    }
}

요약

User: 도메인 모델 EmailService: 알림 전송 책임 UserService: 유저 등록 비즈니스 로직 UserServiceFactory: 팩토리 역할만 담당 Logger는 각 클래스 안에서 자기 책임 범위 내에서만 사용

O: 개방/폐쇄 원칙

“소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.”

• 기존 코드를 수정하지 않고 기능을 확장할 수 있어야 합니다.

❌ 위반 예시

@Service
public class PaymentService {
    public void pay(String paymentType, int amount) {
        if (paymentType.equals("card")) {
            System.out.println("카드로 " + amount + "원 결제합니다.");
        } else if (paymentType.equals("kakao")) {
            System.out.println("카카오페이로 " + amount + "원 결제합니다.");
        } else if (paymentType.equals("naver")) {
            System.out.println("네이버페이로 " + amount + "원 결제합니다.");
        } else {
            System.out.println("지원하지 않는 결제 수단입니다.");
        }
    }
}

문제점

1. 결제 수단 결정 로직 (if-else 조건 분기)
2. 결제 실행 로직 (각 결제 방식의 세부 동작 수행)
3. 결제 수단 추가/확장 처리 (OCP 위반의 핵심)

✅개선한 예시

// 결제 전략 인터페이스
public interface PaymentStrategy {
    boolean supports(String paymentType);  // 어떤 타입인지 판별
    void pay(int amount);                  // 결제 실행
}

// 카드 결제 구현체
public class CardPayment implements PaymentStrategy {
    @Override
    public boolean supports(String paymentType) {
        return paymentType.equals("card");
    }

    @Override
    public void pay(int amount) {
        System.out.println("💳 카드로 " + amount + "원 결제합니다.");
    }
}

// 카카오페이 결제 구현체
public class KakaoPayment implements PaymentStrategy {
    @Override
    public boolean supports(String paymentType) {
        return paymentType.equals("kakao");
    }

    @Override
    public void pay(int amount) {
        System.out.println("📱 카카오페이로 " + amount + "원 결제합니다.");
    }
}

// 결제 서비스
public class PaymentService {
    private final Map<String, PaymentStrategy> strategyMap;

    public PaymentService(List<PaymentStrategy> strategies) {
        this.strategyMap = new HashMap<>();
        for (PaymentStrategy strategy : strategies) {
            strategyMap.put(strategy.getType(), strategy);
        }
    }

    public void pay(String paymentType, int amount) {
        PaymentStrategy strategy = strategyMap.get(paymentType);
        if (strategy != null) {
            strategy.pay(amount);
        } else {
            System.out.println("🚫 지원하지 않는 결제 수단입니다: " + paymentType);
        }
    }
}

요약

1. 개방/폐쇄 원칙에 따라 기존 코드를 변경하지 않고 확장할 수 있어야 합니다
2. 조건문 기반으로 결제 수단을 처리하는 대신 전략 패턴을 사용하여 결제 방식의 유연한 확장을 가능하게 했습니다

L: 리스코프 치환 원칙

“프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.”

• 상속받은 클래스(자식 클래스)는 부모 클래스의 행위를 일관성 있게 유지해야 합니다.

❌ 위반 예시

// 부모 클래스: 직사각형
public class Rectangle {
    protected int width;
    protected int height;

    public void setWidth(int width) {
        this.width = width;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    public int getArea() {
        return width * height;
    }
}

// 자식 클래스: 정사각형
public class Square extends Rectangle {
    @Override
    public void setWidth(int width) {
        this.width = width;
        this.height = width; // 정사각형은 너비와 높이가 항상 같아야 하니까
    }

    @Override
    public void setHeight(int height) {
        this.width = height; // 정사각형은 높이도 같게 맞춤
        this.height = height;
    }
}

문제점

1. Rectangle을 상속받은 Square는 setWidth()와 setHeight()가 서로 영향을 줘 Rectangle을 훼손시킵니다
2. getArea()에서 Rectangle은 width와 height가 서로 독립되어 있다고 생각했지만, Square에서는 그렇게 되지 않고 있습니다

✅개선한 예시

public interface Shape {
    int getArea();
}

// 직사각형
public class Rectangle implements Shape {
    private int width;
    private int height;

    public Rectangle(int width, int height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public int getArea() {
        return width * height;
    }
}

// 정사각형
public class Square implements Shape {
    private int side;

    public Square(int side) {
        this.side = side;
    }

    @Override
    public int getArea() {
        return side * side;
    }
}

요약

Rectangle과 Square의 상속관계에서 Shape과 Rectangle, Square과 Shape의 구현체로 변경해 서로의 특징을 보장할 수 있습니다.

I: 인터페이스 분리 원칙

“특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.”

❌ 위반 예시

public interface Machine {
    void print(Document doc);
    void scan(Document doc);
    void fax(Document doc);
}

// 단순 프린터
public class SimplePrinter implements Machine {
    public void print(Document doc) {
        System.out.println("프린트 완료");
    }

    public void scan(Document doc) {
        throw new UnsupportedOperationException("스캔 기능 없음");
    }

    public void fax(Document doc) {
        throw new UnsupportedOperationException("팩스 기능 없음");
    }
}

문제점

SimplePrinter는 프린트 기능만 필요한데도 스캔, 팩스 메서드를 구현해야 합니다 (불필요한 의존성 발생) 변경이 있을 경우, 쓰지 않는 메서드 때문에 부작용이 생길 수도 있습니다

✅개선한 예시

public interface Printer {
    void print(Document doc);
}

public interface Scanner {
    void scan(Document doc);
}

public interface Fax {
    void fax(Document doc);
}

public class SimplePrinter implements Printer {
    public void print(Document doc) {
        System.out.println("프린트 완료");
    }
}

public class MultiFunctionPrinter implements Printer, Scanner, Fax {
    public void print(Document doc) { /* 구현 */ }
    public void scan(Document doc) { /* 구현 */ }
    public void fax(Document doc) { /* 구현 */ }
}

요약

불필요한 메서드 강제 구현을 피하기 위해 인터페이스를 기능별로 분리

D: 의존 역전 원칙

프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.”

• 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 됩니다. 대신 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 합니다.

  ❌ 위반 예시

  public class Kid {
  private Robot toy;
  
  public Kid(Robot toy) {
      this.toy = toy;
  }
  
  public void play() {
      toy.activate();
  }
  }
  

public class Robot { public void activate() { System.out.println("🤖 로봇이 움직입니다!"); } }

#### 문제점
Kid가 Lego를 장난감으로 삼는다면 Kid코드를 직접 고쳐야하는 문제가 발생합니다. 구체화에 의존하고 있음 → DIP 위반

### ✅개선한 예시
```java
// 추상화
public interface Toy {
    void play();
}

// 구체화 1
public class Robot implements Toy {
    public void play() {
        System.out.println("🤖 로봇이 움직입니다!");
    }
}

// 구체화 2
public class Lego implements Toy {
    public void play() {
        System.out.println("🧱 레고로 탑을 쌓습니다!");
    }
}

// 고수준 모듈
public class Kid {
    private Toy toy;

    public Kid(Toy toy) {
        this.toy = toy;
    }

    public void play() {
        toy.play();
    }
}

요약

Kid는 Toy라는 추상화에만 의존하므로, 어떤 장난감을 쓰든 Kid 코드를 수정할 필요 없게 됩니다 즉, 새로운 장난감이 생겨도 쉽게 확장 가능하게 되었습니다

✨ SOLID 원칙을 적용하면 어떤 이점이 있을까?

1.유지보수가 쉬워집니다 하나 고치면 연쇄적으로 에러가 나는 현상 줄어듭니다.

2.새로운 기능 추가가 편해집니다 기존 코드 건드릴 필요 없이 확장할 수 있습니다.

3.협업이 쉬워집니다 각 클래스/모듈의 역할이 분명해서 다른 사람이 코드를 봐도 이해하기 쉬워집니다.

4.테스트 코드 작성이 쉬워집니다 의존성 분리 덕분에 단위 테스트나 Mocking이 쉬워집니다.

🏌️마무리하며

SOLID 원칙은 무조건 지켜야 하는 법칙은 아니지만, 객체지향 설계를 더 튼튼하고 유연하게 만들 수 있는 가이드라인입니다. 처음엔 어렵게 느껴질 수도 있지만, 점점 프로젝트를 진행하면서 "아, 그래서 이게 필요했구나!" 하고 체감하게 됩니다.

Implicit : 묵시적인

Implicit하게 코드를 짜는 것은 생략해서 간결하게 작성하는 것이다. 예시)

// Implicit
name = name;

// Implicit
int b = 1;
double a = b; // 자동 형변환 (double)이 생략됨

Explicit : 명시적인

Explicit하게 코드를 짜는 것은 모든 과정을 명확하게 드러내며 작성하는 것이다. 예시)

// Explicit
this.name = name;

// Explicit
int b = 1;
double a = (double) b;

Implicit한 코드의 장점

• 짧고 간단합니다.
• 개발하기 편합니다.

Implicit한 코드의 단점

• 협업 시 내 코드가 다른 사람이 봤을 때 이해하기 어려움

Explicit한 코드의 장점

• 코드가 수행하는 게 무엇인지 명확히 드러남.
• 코드를 봤을 때 이해하기 쉬움.

Explicit한 코드의 단점

• 다 명시적으로 써 놓아서 코드가 한도끝도 없이 길어질 수 있음.

요약

"Implicit은 나에게는 편하지만, 다른 사람에겐 불친절할 수 있음" "Explicit은 길더라도, 의도를 명확히 드러내므로 협업에 적합"

언제 Implicit 언제 Explicit을 써야할까?

개인 프로젝트나 빠른 개발: Implicit도 OK저축은행 협업, 오픈소스, 유지보수 고려 시: Explicit 추천

마무리

Implicit과 Explicit은 상황에 따라 적절히 선택해야 한다. 하지만 협업을 하거나, 명확한 코드가 필요한 경우에는 Explicit이 더 안전한 선택이다.

웹서버

웹서버는 정적 파일(HTML, CSS)을 제공하는 서버로 데이터를 처리하지 않는 서버입니다. 주로 사용되는 것은 Apache, Nginx 등이 있습니다.

WAS

WAS는 웹 페이지도 만들어주기는 하지만 API 서버 역할도 수행합니다.

• API 서버: 클라이언트에게 데이터(JSON) 를 반환
• 대표 예: Spring MVC에서 @RestController

Rest API

API 서버 내부에 존재하면서 REST 방식으로 자원을 주고받는데 이 때 REST 방식이란 자원과 동작을 분리하여 HTTP 메서드(GET, POST 등)로 동작을 표현하는 방식이다.

예시)
동작    메서드    예시 경로
조회    GET           /사실
생성    POST       /밥
수정    PUT           /유후/1
삭제    DELETE      /잠만/1
-> GET /사실 → 사용자 목록 조회
POST /밥 → 새로운 사용자 추가
PUT /유후/1 → 1번 사용자 정보 수정
DELETE /잠만/1 → 1번 사용자 삭제

Restful API

Restful API는 REST의 원칙을 더 철저히 지킨 API이다. URL, 자원 표현 방식, 응답까지 REST스럽게 구성해야 한다.

• URL에는 동사가 들어가지 않고, 명사만 들어간다. 보통 복수형으로 사용.
• 상황에 맞는 HTTP 상태 코드를 반환
• JSON 형식으로 반환
• 자원의 관계를 URL로 표현해 URL이 예측 가능하게 한다.

넌 전혀 Restful하지 않아의 예)

GET /getUser
POST /createUser 

Restful하게 고친 예)

Get /users
Post /users

REST API: REST 원칙을 조금 지키는 API Restful API: REST 원칙을 철저히 지킨 API → 즉, Restful API는 '넌 정말 Restful해. 넌 최고로 Restful해'이다.

공인망과 사설망

데이터를 주고 받으려면 서로의 위치를 알아야 통신이 가능하지 않을까요?

이때 서로의 위치를 알려주는 게 IP인데요. IP에는 공인 IP와 사설 IP가 있습니다. 공인 IP는 전세계에서 유일한 IP입니다. 공인 IP는 전세계를 기준으로 어디 있는지 찾을 수 있는 고유 번호인셈이죠. 하지만 우리는 인구 80억 시대를 살아가고 있기 때문에 현재 IPv4(최대 IP 갯수 42억개)로는 할당하기 부족해서 나온게 IPv6와 사설망입니다. IPv6는 32개의 비트를 사용하는 IPv4와 달리 128개의 비트를 사용해 사실상 무한개로 볼 수 있습니다. 하지만 IPv6는 전세계적으로 보급되지 않아 호환성이 부족하기에 사설망을 사용합니다. 앞서 공인 IP에 대해 이야기해 보았는데요 공인망에서는 공인 IP가 쓰이듯이 사설망에서 쓰이는 IP를 사설 IP라고 합니다. 사설 IP가 어디 쓰이는 건진 알겠는데 사설망이랑 공인망은 뭐야? 라고 생각하실 것 같아 설명드리자면 공인망은 인터넷 상에서 직접 접근 가능한 망, 사설망은 외부(인터넷)에서는 직접 접근할 수 없는 망이라고 생각하시면 됩니다. 사설망은 보통 회사, 학교, 가정용 공유기에서 사용됩니다. 외부에선 접근이 안되고 내부에서만 접근이 가능하기에 보안에도 용이합니다.

사설 IP주소 대역(CIDR)

아래 이미지는 사설망의 IP대역입니다.

CIDR 표기법은?

CIDR(Classless Inter-Domain Routing) 표기법의 /숫자는 IP 주소에서 네트워크를 식별하는 비트 수를 나타냅니다. 10.0.0.0/8은 앞의 8비트(10)가 네트워크 주소라는 의미로, 남은 24비트를 호스트 주소로 사용할 수 있습니다.

네트워크 인터페이스와 포트

네트워크 인터페이스는 네트워크 연결을 위한 컴퓨터나 장치의 출입구 역할을 하는 장치 입니다. IP는 여기에 할당되게 됩니다. 포트는 하나의 네트워크 인터페이스에 여러 애플리케이션이 돌아갈 때 어떤 애플리케이션에 접속할지를 구분하는 번호입니다. 컴퓨터에 랜선을 꼽으면 인터페이스에 IP가 할당되고 그 컴퓨터 속에 돌아가는 애플리케이션에 접근하려면 IP:포트번호로 접근할 수 있게 되는겁니다. 하지만 IP가 사설IP면 외부에서 접근할 수 없겠죠? ㅎ_ㅎ

NAT와 포트포워딩

OutBound, InBound?

OutBound는 내 서버에서 다른 서버에 요청을 보내는 것이고 InBound는 내 서버로 들어오는 요청을 받을 때이다.

OutBound 후에 오는 결과를 내 서버로 받아야 하기에 사설망을 사용중인 내 서버를 공인망과 연결해주는 역할을 하는 녀석이 필요한데 그 역할을 해주는게 바로 NAT 테이블이다. 하지만 이 NAT 테이블은 OutBound가 되야 기록되기에 그냥 InBound가 올때는 내 서버가 어디있는지 모른다. 그래서 나온게 포트포워딩이다. 포트포워딩은 테이블에 공인포트번호를 지정해서 한자리를 먹어놓는다.(공인포트번호는 중복x) 이렇게 포트포워딩을 해놓으면 외부에서 얼마든지 접근할 수 있게 된다. 만약 같은 사설망을 사용하는게 아니라면 다른 사설망에 있는 서버에 접근하려면 이렇게 포트포워딩을 해줘야겠죠?

DNS

DNS는 Domain name server의 약자로 Domain name과 Ip를 매핑해 가지고 있는 녀석이다. 예시를 들어보면 naver로 접속하고 싶으면 url에 naver.com을 치면 DNS서버로 가서 DNS서버가 naver.com과 매핑되어있는 Ip를 반환해주기에 그냥 naver.com만 쳐도 naver에 들어갈 수 있는 것이다.

도커 컨테이너 가상화

호스트 OS 위에서 격리된 컨테이너을 만들어 실행하는 기술이에요. VM은 OS까지 가상화시키지만 docker는 프로세스만 격리해서 빠릅니다.

가상 인터페이스

컨테이너가 인터넷 쓸 수 있도록 만들어주는 가짜 랜선 브릿지 네트워크를 docker0라하고 새로 생긴 컨테이너를 Veth1이라 하면 docker0와 연결되서 컨테이너끼리 통신, 외부와의 통신이 가능해지게 됩니다.

도커 네트워크 명령어

docker network ls    # 네트워크 목록 확인
docker network inspect #    네트워크 상세 정보
docker network create    # 사용자 정의 네트워크 생성
docker network connect    # 컨테이너 네트워크 연결
docker network disconnect #    컨테이너 네트워크 연결 해제
docker network rm    # 네트워크 삭제
docker run --network    # 컨테이너 생성 시 네트워크 지정

클럭

첫 번째 방법은 클럭 신호를 빠르게 해주는 방법이 있습니다. 클럭 속도는 헤르츠(Hz) 단위로 측정합니다. Hz는 1초에 클럭이 몇 번 반복되는지 나타냅니다. 1초에 100번 반복되면 100Hz로 표현합니다.

그럼 클럭 속도만 많이 올리면 될까요? *무작정 속도만 올리게 된다면 발열 문제가 생깁니다. * 클럭 속도를 올리는 건 빠른 CPU를 만들 순 있겠지만 이것만으로 CPU성능을 올리기엔 한계가 있습니다.

코어와 멀티코어

클럭 속도를 높이는 것 이외의 CPU성능을 올릴 수 있는 방법도 있습니다. 바로 CPU의 코어수와 스레드 수를 늘리는 방법이죠.

많은 전공 서적에서는 "명령어를 실행하는 부품"으로 하나만 존재했습니다. 하지만 오늘날의 CPU는 많은 발전을 거듭했고, 이젠 CPU내부에 "명령어를 실행하는 부품"을 얼마든지 만들 수 있게 되었습니다.

우리가 지금까지 CPU의 정의로 알고 있던 "명령어를 실행하는 부품"은 코어라고 불립니다. 오늘날의 CPU는 단순히 "명령어를 실행하는 부품"에서 "명령어를 실행하는 부품을 여러 개 포함하는 부품"으로 확대되었습니다. 이런 CPU를 멀티코어 CPU 또는 멀티코어 프로세서라고 합니다.

CPU의 종류는 CPU안에 코어가 몇 개가 들어 있는지에 따라 아래와 같이 나뉩니다. 그럼 코어 수를 100개로 늘리면 100배 빨라질까요? 안타깝게도 연산 속도와 코어 수는 비례하여 증가하지 않습니다. 학교에서 4인 1조를 한다고 생각해 볼까요? 모두 똑같이 참여해 한 사람이 생성해 낼 수 있는 생산성의 4배에 가까운 결과를 내는 경우도 있으나, 그렇지 않은 경우가 더 많습니다.

중요한 것은 코어마다 처리할 명령어를 얼마나 적절히 분배하느냐이고 그에 따라 연산 속도는 크게 달라집니다.

스레드

스레드의 사전적 의미는 '실행 흐름의 단위'입니다. 하지만 CPU의 스레드와 프로그래밍에서의 스레드는 용도가 다르기에 더욱 엄밀히 이해해야 합니다.

스레드는 CPU에서 쓰이는 하드웨어적 스레드, 프로그래밍에서 쓰이는 소프트웨어적 스레드가 있습니다.

하드웨어적 스레드

하나의 코어가 동시에 처리하는 명령어 단위를 의미합니다. 지금까지 배운 것은 1코어 1스레드였습니다. 즉 명령어를 실행하는 부품이 하나 있고, 한 번에 하나씩 명령어를 실행하는 CPU였죠. 반면 여러 스레드를 지원하는 CPU는 하나의 코어로도 여러 개의 명령어를 동시에 실행할 수 있습니다. 예를 들어 2코어 4스레드 CPU는 명령어를 실행하는 부품이 두 개고, 한번에 4개의 명령어를 처리할 수 있는 CPU를 의미합니다. 이처럼 코어 하나로 여러 명령어를 동시에 처리하는 CPU를 멀티스레드 프로세서 또는 멀티스레드 CPU라고 합니다.

소프트웨어적 스레드

하나의 프로그램에서 독립적으로 실행되는 단위를 의미합니다. 하나의 프로그램이 실행되는 과정에서 한 부분만 실행될 수 있지만, 프로그램의 여러 부분이 동시에 실행될 수도 있습니다.

만약 워드 프로세서 프로그램을 개발한다고 하고, 아래의 기능을 동시에 수행하고 싶어 한다고 생각해 봅시다.

• 사용자로부터 입력받은 내용을 화면에 띄워주는 기능
• 사용자가 입력한 내용의 맞춤법이 맞는지 검사하는 기능
• 사용자가 입력한 내용을 수시로 저장하는 기능

이 기능들을 작동시키는 코드를 각각의 스레드로 만들면 동시에 실행할 수 있습니다.

입력값에 수학적 알고리즘(해시 함수)을 적용하여 고정된 크기의 문자열을 출력하는 과정

키에 대한 연산에 의해 직접 접근이 가능한 구조를 해시 테이블이라 부르며, 해시 테이블을 이용한 탐색을 해싱이라 한다.

충돌 (Collision)

서로 다른 키를 갖는 항목들이 같은 해시주소를 가지는 현상이다.

오버플로우 (overflow)

해시 주소에 더이상 빈 버킷이 남아 있지 않으면 발생한다. 오버플로우는 충돌이 발생하고, 오버플로우가 발생하면 해시테이블에 항목을 더 이상 저장하는 것이 불가능해진다.

개방주소법(open addressing) : 현재 사용되고 있지 않은 공간을 찾아 저장하는 방법. 빈 공간을 효율적으로 찾는 것이 중요하다. 충돌이 일어났을 때 대처하는 방법에 따라 선형 조사법, 이차 조사법, 이중 해싱법, 체인법 등이 존재한다.

1. 선형 조사법(linear probing)

선형조사법 조사되는 위치: h(k), (h(k)+1) % 해시테이블 크기,(h(k)+2) % 해시테이블 크기. (h(k)+3) % 해시테이블 크기 (h(k)+4) % 해시테이블 크기 문제점 : clustering 문제(비선형법) -> 한 번 충돌이 시작 시, 그 위치에 집중되는 현상

2.** 이차 조사법 (quadratic probing)**

3. ** 이중 해싱법 (double hashing) **
   

** 이중해싱법에서 2를 삽입하고자 할 때 ** 4. 체인법 (chaining)

배열의 각 버킷(해시 테이블)에 저장하는 것은 인덱스를 해시값으로 하는 연결 리스트의 앞쪽 노드(head node)를 참조하는 것이다. 만약 해시 주소가 같은 키만을 하나의 리스트로 묶어둔다면 불필요한 비교는 하지 않아도 될 것이다. 충돌을 해결하는 두 번째 방법은 해시 테이블의 구조를 변경하여 각 버킷이 하나 이상의 값을 저장할 수 있도록 하는 것이다.

합병 정렬 - 주어진 배열의 원소가 하나가 될 때까지 배열을 2개로 분할 후 합치면서 정렬하는 알고리즘.

합병정렬의 단점

• 시간복잡도가 O(n logn)이라서 n이 커져도 성능이 보장된다.

합병정렬의 단점

• 임시 하위 배열에 저장하기에 추가공간이 필요해 메모리가 제한된 환경에서는 적합하지 않다.

예시

C언어 구현

#include <stdio.h>
int sorted[100],count;

void merge(int list[], int left,int mid, int right)
{
    int i,j,k,l;
    i=left;
    j=mid+1;
    k=left;
    while(i<=mid && j<=right)
    {
        if(list[i]<=list[j])
        {
            sorted[k++]=list[i++];
        }
        else
        {
            sorted[k++]=list[j++];
        }
    }
    if(i>mid)
    {
        for(l=j; l<=right; l++)
        {
            sorted[k++]=list[l];
        }
    }
    else
    {
        for(l=i; l<=mid; l++)
        {
            sorted[k++]=list[l];
        }
    }
    for(l=left; l<=right; l++)
    {
        list[l]=sorted[l];
    }
}

void mergesort(int list[], int left,int right)
{
    int mid;
    if(left<right)
    {
        mid=(left+right)/2;
        mergesort(list,left,mid);
        mergesort(list,mid+1,right);
        merge(list,left,mid,right);
    }
}

int main()
{
    int list[4]={27,12,20,25};
    mergesort(list,0,3);
    for(int i=0; i<4; i++)
    {
        printf("%d ",list[i]);
    }
    return 0;
}

평균적으로 가장 빠른 정렬 O(n logn)의 시간복잡도를 가진다

정렬 방법

1. 리스트 안에 한 요소를 피벗으로 설정한다.
2. 피벗보다 작은 요소를 피벗의 왼쪽, 피벗보다 큰 요소는 피벗의 오른쪽으로 옮긴다.
3. 정렬되어 있는 피벗이 아닌 리스트들을 다시 이러한 방법으로 정렬한다.

구현 코드

#include <stdio.h>
#define swap(x,y,t) ((t)=(x), (x)=(y), (y)=(t))
int partition(int list[], int left,int right)
{
    int pivot,temp,low,high;
    low = left;
    high= right+1;
    pivot=list[left];
    do
    {
        do
        {
            low++;
        }while(list[low]<pivot && low<=right);
        do
        {
            high--;
        }while(list[high]>pivot);

        if(low<high)
        {
            swap(list[low],list[high],temp);
        }
    }while(low<high);
    swap(list[left],list[high],temp);
    return high;
}

void quicksort(int list[], int left,int right)
{
    if(left<right)
    {
        int q=partition(list, left, right);
        quicksort(list,left,q-1);
        quicksort(list,q+1,right);
    }
}


int main()
{
    int list[6]={10,2,20,7,50,1};
    quicksort(list,0,5);
    for(int i=0; i<6; i++)
    {
        printf("%d ",list[i]);
    }
    return 0;
}

코드 설명

변수 설명 - pivot : 정렬 기준, low : 피벗 보다 큰 값을 가르킬 인덱스, high : 피벗보다 작은 값을 가르킬 인덱스

함수 partition [반복] 피벗을 맨앞 수로 잡고 list[low]의 값이 피벗보다 클 때까지 증가시키고 high값을 list[high]값이 피벗보다 작을 때까지 감소시킨다. swap을 써서 list[low]값과 list[high]값을 바꾼다. [반복] 마지막으로 피벗을 list[high]값과 바꿔주면 피벗을 기준으로 왼쪽에는 작은 값 오른쪽에는 큰 값이 들어가고 피벗의 인덱스를 반환한다.

함수 quicksort [반복] partition 함수에서 받아온 피벗의 인덱스를 받고 피벗의 인덱스를 기준으로 왼쪽 리스트와 오른쪽 리스트를 다시 정렬한다. [반복]

순차탐색 - 탐색해야할 자료들을 처음부터 마지막까지 순차적으로 비교하는 탐색 방식. 순차탐색의 장점 - 자료들이 정렬되어있지 않아도 탐색이 가능하다. 순차탐색의 단점 - 리스트가 길어지면 비효율적이다.

순차탐색 구현

#include <stdio.h>
int i, key, count, n, result;
int arr[5] = {9, 5, 8, 3, 7};

int search() 
{
    for (i = 0; i < n; i++) 
    {
        count++;
        if (arr[i] == key)
        {
            return count;
        }
    }
    return -1;
}

int main() 
{
    n = sizeof(arr) / sizeof(int);
    printf("탐색할 값은? ");
    scanf("%d", &key);
    result = search();
    if (result == -1) 
        printf("탐색 실패입니다.");
    else 
        printf("탐색 성공이며 탐색 횟수는 %d회입니다.", result);

    return 0;
}

이진탐색 - 자료들을 반씩 나누어서 탐색하는 방식. 이진탐색의 장점 - 탐색범위를 절반씩 줄여가기 때문에 시간복잡도가 O(logN)이다. 이진탐색의 단점 - 자료들이 반드시 정렬되어 있어야 탐색이 가능하다.

이진탐색 구현

#include <stdio.h>
int i, key, count, n, result;
int arr[6] = {1, 3, 5, 7, 9, 11};

int search(int start, int end)
{
    int middle;
    if (start <= end)
    {
        count++;
        middle = (start + end) / 2;
        if (key == arr[middle]) return count;
        else if (key < arr[middle]) return search(start, middle - 1);
        else if (key > arr[middle]) return search(middle + 1, end);
    }
    return -1;
}

int main()
{
    n = sizeof(arr) / sizeof(int);
    printf("탐색할 값은? ");
    scanf("%d", &key);
    result = search(0, n - 1);
    if (result == -1) 
        printf("탐색 실패입니다.");
    else 
        printf("탐색 성공이며 탐색 횟수는 %d회입니다.", result);

    return 0;
}

_ - 여러 개의 노드가 존재할 때 두 개의 노드를 선택해서 현재 이 노드가 서로 같은 그래프에 속하는지 판별하는 알고리즘_

Union-Find 동작 과정

처리할 연산 : Union(1,2), Union(2,3),Union(5,6)

1. n개의 부모노드를 초기화 해준다
   2. Union(1,2) : 노드1의 부모와 노드2의 부모를 찾고 둘의 부모가 다르면 부모를 같에 만들어준다
   • 노드2번의 부모에 노드1의 부모 1을 넣어준다
   3.Union(2,3)
   • 노드3번의 부모에 노드2의 부모 1을 넣어준다
   4.Union(5,6)
   • 노드6번의 부모에 노드5의 부모 5를 넣어준다 결과 : 노드1,2,3은 같은 집합, 노드5,6이 같은 집합, 노드4는 단독적인 집합에 존재하게된다.

     Union-Find 구현 방법

• Set (초기화) : n개의 부모노드가 각각의 집합에 포함되게 초기화
• Union (합치기) : 두 원소의 각각의 집합을 같은 집합으로 합친다
• Find (찾기) : 원소 a가 들어오면 그 원소가 어느 집합에 포함되어 있는지 찾아서 반환한다

[구현]

 #include <stdio.h>
int parent[1001];
int Find(int v)
{
    if(parent[v] == v) return v; // 노드의 부모가 v값과 같으면 부모가 같기에 부모를 리턴

    return parent[v] = Find(parent[v]); //노드의 부모가 같을 때까지 반복
}
void Union(int x, int y) // 연결시키기 or 연결됬는지 확인
{
    x = Find(x);
    y = Find(y);

    if(x != y) // x,y가 같다면 부모가 같기 때문에 다르면 저장해줌
        parent[x] = y; 
}
void Set(int n){ // parent 배열 초기화
    for(int i = 1; i <= n; i++){
        parent[i] = i;
    }
}
int main(void) {
    int n ,m, uf1,uf2;
    int f1,f2;
    scanf("%d %d",&n,&m);
        Set(n);
    for(int i = 1; i <= m; i++){
        scanf("%d %d",&uf1,&uf2);
                Union(uf1,uf2);
    }
    scanf("%d %d",&f1,&f2);
    printf("%s",(Find(f1) == Find(f2)) ? "YES":"NO" ); // 부모가 같다면 YES 다르면 NO를 출력
    return 0;
}