코딩수첩

Mac OS LogStash 특정 버전 설치

길민호(ethan.mino) — Fri, 21 Apr 2023 17:01:14 +0900

다운로드

brew를 이용한 방법도 있지만, 제가 필요한 버전은 지원을 하지 않더라구요.

그래서 홈페이지를 통해 직접 설치해주었습니다.

먼저, 홈페이지에서 ~~Logstash~~를 설치해줍니다. Logstash 홈페이지

Download Logstash Free | Get Started Now

Download Logstash or the complete Elastic Stack (formerly ELK stack) for free and start collecting, searching, and analyzing your data with Elastic in minutes.

www.elastic.co

특정 버전을 설치하려면, Detailed release notes에서 원하는 버전을 설치해줍니다.

압축 해제

설치된 tar.gz 파일을 압축 해제 해줍니다.

더블 클릭 또는 아래 명령어를 실행해서 압축 해제할 수 있어요.

tar -xzf ${SOURCE_DIR}/${LOGSTASH_FILE_NAME} -C ${DESTINATION_DIR}

~~SOURCE_DIR~~ : 다운로드 받은 Logstash 파일의 path
~~LOGSTASH_FILE_NAME~~ : 다운로드 받은 Logstash 파일명
~~DESTINATION_DIR~~ : 압축 해제한 Logstash가 위치할 path

PATH 설정

logstash 명령어를 사용하기 위해 path를 설정해줍니다.

export PATH="$LOGSTASH_PATH/bin:$PATH"

그 다음, 터미널을 재실행 하거나, source ${SHELL_CONFIG_PATH}을 통해 shell 설정을 리로드할 수 있습니다.

실행

logstash --version

마지막으로, logstash의 version을 출력해보았을 때 아래와 같이 출력되면 성공입니다!

Using bundled JDK: /usr/local/logstash-x.x.x/jdk.app/Contents/Home
logstash x.x.x

싱글턴 패턴 (Singleton Pattern)이란?

길민호(ethan.mino) — Tue, 4 Apr 2023 23:10:00 +0900

싱글턴 패턴이란?

특정 클래스의 인스턴스가 하나만 만들어지도록 해 주는 패턴

이러한 ~~싱글턴~~ 패턴을 사용하면, 하나의 인스턴스만 생성되도록 할 수 있습니다. 설정 객체, Connection Pool, Thread Pool 등과 같이 하나의 인스턴스만 필요한 경우, 여러 개의 인스턴스가 생성되지 않도록 해서 자원이 불필요하게 사용되지 않도록 할 수 있는거죠.

고전적 싱글턴 패턴

고전적인 싱글턴 구현은 간단합니다. 생성자의 접근 제어자(Access Modifier)를 ~~private~~로 하여, 외부에서 접근하지 못하도록 하고, getInstance()와 같은 메서드를 통해 정해진 인스턴스를 반환하도록 하면 돼요.

public class Singleton {
	// 하나뿐인 인스턴스를 저장하는 static 변수
    private static Singleton uniqueInstance;
		
	// private 생성자, 클래스 내부에서만 접근 가능하다.
    private Singleton() {
    }

    public static Singleton getInstance(){
        if(Objects.isNull(uniqueInstance)){
            uniqueInstance = new Singleton();
        }
        return uniqueInstance;
    }
}

중요한 점은 아래와 같습니다.

생성자의 접근 제어자는 ~~private~~, 따라서 클래스 내부에서만 인스턴스를 생성할 수 있음
인스턴스를 저장하는 레퍼런스 변수와 하나뿐인 인스턴스를 반환하는 메서드는 ~~static~~
1. 이 메서드를 통해서만 인스턴스를 생성할 수 있으며, 여러 번 호출하더라도 같은 인스턴스를 반환
2. 이 메서드를 호출할 때 인스턴스가 생성되도록 하여, 불필요한 자원 낭비 방지

class Test{
    @Test
    @DisplayName("싱글스레드 환경에서 싱글턴 인스턴스는 하나만 생성되어야 한다.")
    void test1(){
        // Given
        Set<Singleton> singletonSet = new HashSet<>();

        // When
        IntStream.range(0, 1000)
                .forEach((index) -> singletonSet.add(Singleton.getInstance()));

        // Then
        Assertions.assertEquals(1, singletonSet.size());
    }
}

위 테스트 코드는, 싱글스레드 환경에서 싱글턴 인스턴스를 1000번 생성했을 때, 몇 개의 인스턴스가 생성되는지 확인하는 테스트입니다. 테스트 결과는 성공으로, 예상대로 1개의 인스턴스만 생성되어요.

고전적 싱글턴 패턴의 문제

고전적 싱글턴 패턴의 문제는 멀티스레드 환경에서 여러 개의 인스턴스가 생성될 수 있다는 것입니다.

class Test{
    @Test
    @DisplayName("멀티스레드 환경에서 싱글턴 인스턴스는 하나만 생성되어야 한다.")
    void test1() throws Exception{
        // Given
        Map<String, Singleton> singletonHashMap = new ConcurrentHashMap<>();
        var executorService = Executors.newFixedThreadPool(10);

        // When
        IntStream.range(0, 3).forEach((index) -> executorService.submit(() ->{
            Singleton instance = Singleton.getInstance();
            singletonHashMap.put(instance.toString(), instance);
        }));

        executorService.awaitTermination(500, TimeUnit.MICROSECONDS);

        // Then
        Assertions.assertEquals(1, singletonHashMap.size());
    }
}

위 코드는 크기가 멀티스레드 환경에서 Singleton 인스턴스를 3번 생성해서 ~~ConcurrentHashMap~~에 삽입하는 코드입니다.

실행 결과, 2개의 싱글턴 인스턴스가 생성됩니다.

~~getInstance()~~ 메서드에 진입하여 경합을 벌이는 과정에서 서로 다른 두 개의 인스턴스가 만들어질 수 있는거죠.

expected: <1> but was: <2>
Expected :1
Actual   :2

  스레드의 동작에 따라 결과가 달라집니다. 하나의 인스턴스만 생성되는 경우도 있습니다.

Thread-Safe Singleton

그럼 멀티스레드 환경에서 어떻게 하나의 인스턴스만 생성되도록 할 수 있을까요?

스레드가 경합을 벌였을 때, 문제가 발생하는 메서드를 동기화하면 멀티스레딩과 관련된 문제가 해결됩니다.

public class Singleton{
    ...
    public static synchronized Singleton getInstance(){
        if(Objects.isNull(uniqueInstance)){
            uniqueInstance = new Singleton();
        }
        return uniqueInstance;
    }
}

위 코드에서는 getInstance() 메서드에 ~~synchronized~~ 키워드를 붙여주었는데요,

이 키워드를 메서드에 붙여주면 이 메서드는 ~~임계 영역(Critical Section)~~이 되어서, 한 번에 하나의 스레드만 실행할 수 있습니다.

하지만, 동기화로 인해 성능이 저하되며, 심지어 인스턴스가 생성된 후부터는 동기화가 필요하지 않으므로, 불필요한 오버헤드가 증가합니다. 따라서 getInstance()가 병목으로 작용할 수도 있어요.

또한, DCL 방식에서 살펴보겠지만, 이 방식도 완전히 Thread-safe 하지는 않아요.

Eager Initialization (Early Loading)

public class Singleton{
    private static final Singleton uniqueInstance = new Singleton()
    public static Singleton getInstance(){
        return uniqueInstance;
    }
}

~~정적변수~~의 경우 클래스가 로딩될 때 초기화 되며, 정적변수가 초기화되기 전까지 어떤 스레드도 정적 변수에 접근할 수 없습니다.

따라서 멀티스레드 환경이라도 서로 다른 싱글턴 인스턴스가 생성되지 않습니다.

하지만, 클래스가 로딩될 때 초기화되므로, 인스턴스가 필요하지 않은 경우에도 미리 인스턴스를 생성하기 때문에 메모리를 낭비할 수 있습니다.

그렇다면, 정적변수는 Application이 실행될 때 초기화 된다는 걸까요?

public class Singleton {
    private static final Singleton uniqueInstance;
    static {
        uniqueInstance = new Singleton()
        System.out.println("정적 변수 초기화");
    }

    private Singleton() {
    }

    public static Singleton getInstance(){
        return uniqueInstance;
    }
}

public class Application {
    public static void main(String[] args) {
        IntStream.range(0, 5)
                .forEach(System.out::println);
    }
}

이 Application의 출력은 어떨까요? “정적 변수 초기화”라는 문자열이 출력될까요?

Singleton 클래스의 ~~static block~~에서 싱글턴 인스턴스를 초기화하고 있음에도, “정적 변수 초기화”라는 문자열이 출력되지 않았습니다. 즉, 클래스는 인스턴스 생성, static method 호출, 변수 접근, Class.forName() 등으로 인해 클래스가 로딩되는데, 현재는 ~~Singleton~~ 클래스에 대한 접근이 없기 때문에 클래스가 로딩되지 않는거고, 그에 따라 uniqueInstance가 초기화 되지 않는겁니다.

그럼, 인스턴스가 필요하지 않는 경우에도 인스턴스가 미리 생성된다는 게 무슨 말이야..?

public class Singleton {
    private final static Singleton uniqueInstance;

    static {
        System.out.println("정적 변수 초기화");
        uniqueInstance = new Singleton();
    }

    private Singleton() {
    }

    public static void noOperation(){
    }

    public static Singleton getInstance(){
        return uniqueInstance;
    }
}

public class Application {
    public static void main(String[] args) {
        Singleton.noOperation();
    }
}

정적 변수 초기화

이번에는 Singleton 클래스의 static block이 실행되었습니다. 이유가 뭘까요??

Application의 main()에서 Singleton의 정적 메서드 ~~noOperation()~~을 호출하고 있기 때문에, Singleton 클래스가 로드되면서 uniqueInstance까지 초기화가 되는거죠. 따라서 싱글턴 인스턴스가 사용되지 않음에도 자원을 낭비하게 됩니다.

Bill Pugh Solution (Initialization-on-demand holder idiom)

이 방식은 ~~holder~~를 이용하여 싱글턴 인스턴스를 초기화하는 방법이에요.

public class Singleton {
    private Singleton() {
    }

    private static Singleton getIntance(){
        return SingletonHolder.INSTANCE;
    }

    public static void noOperation(){
        System.out.println("noOperation call");
    }

    private static class SingletonHolder {
        private static final Singleton INSTANCE;
        static {
            INSTANCE = new Singleton();
            System.out.println("정적 객체 초기화");
        }
    }
}

public class Application {
    public static void main(String[] args) {
        Singleton.noOperation();
    }
}

noOperation call

중요한 점은 세 가지에요.

Singleton 클래스 내부의 ~~SingletonHolder~~ (private static class)
SingletonHolder의 INSTANCE 정적 변수
getInstance()의 return SingletonHolder.INSTANCE

이 방식의 특징은 아래와 같습니다.

~~Lazy Loading~~이 가능하다.
1. 위 출력을 보면, Singleton의 noOperation()을 호출했음에도 싱글턴 인스턴스가 생성되지 않았어요. 오직 getInstance()를 통해서만 ~~SingletonHolder~~ 클래스가 로드되고, 싱글턴 인스턴스가 생성됩니다.
2. 따라서, 인스턴스가 불필요하게 생성되는 것을 방지할 수 있어요.
클래스가 로드될 때 싱글턴 인스턴스가 생성되므로, ~~Thread-safe~~ 합니다.

DCL(Double-Checked Locking)을 이용한 싱글턴 패턴

⚠️ 자바5 이전 버전에서는 DCL이 제대로 동작하지 않습니다.

이 패턴은 instance가 null인지 두 번 check 하기 때문에 ~~Double Checked Locking~~이라고 해요.

public class Singleton {
    private volatile static Singleton instance;

    private Singleton() {
    }

    public static Singleton getInstance(){
        if(Objects.isNull(instance)){    // Single Checked
            synchronized (Singleton.class){
                if(Objects.isNull(instance)){    // Double Checked
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

중요하게 볼 부분은 세 가지 입니다.

getInstance()에서 두 번의 instance 정적 변수 null check
안쪽 null check 코드의 ~~synchronized 블록~~
instance 정적 변수의 ~~volatile~~ 키워드

왜 두 번의 null check이 필요할까요?

public static Singleton getInstance(){
	  if(Objects.isNull(instance)){    // Single Checked
        instance = new Singleton();
    }
    return instance;
}

예를 들어 위 코드에서 스레드1과 스레드2가 동시에 첫 번째 null check을 수행하는 경우, 두 스레드 모두 if문을 통과하고, 각각의 스레드가 Singleton 인스턴스를 생성하는 것이죠.

그럼 아래 코드는?

public static Singleton getInstance(){
    synchronized(Singleton.class){
        if(Objects.isNull(instance)){    // Single Checked
            instance = new Singleton();
        }
    }
	  
    return instance;
}

이 경우, getInstance()를 호출하는 모든 스레드가 synchronized 블록을 실행해야하기 때문에 성능이 저하됩니다.

싱글턴 인스턴스가 생성된 이후 또 다른 스레드가 getInstance()를 호출했을 때, synchronized 블록을 수행할 필요 없이 빠르게 instance를 반환 받도록 하기 위해 Double Check을 하는 것이죠.

그럼에도 getInstance() 메서드는 instance 정적 변수를 ~~volatile~~로 만들지 않으면 제대로 동작하지 않아요.

그렇다면, 왜 싱글턴 인스턴스를 volatile로 선언해야할까요?

Java memory

위처럼, 스레드는 ~~working 메모리~~를 가지고 있어요.

  여기서 working memory는 각 스레드마다 독립적으로 할당되는 메모리 영역으로, Cpu Cache 메모리와는 다름.

따라서, main 메모리와 working 메모리 간의 데이터 이동이 있기 때문에 메모리 간에 동기화가 진행되는 동안 빈틈이 생겨요. 그래서 volatile을 쓰지 않는 Double Checked Locking 방식은 아래와 같은 문제가 발생할 수 있습니다.

스레드 1이 instance를 생성하고 synchronized 블록을 벗어남.
스레드2가 synchronized 블록을 null check을 수행하는 시점에 스레드1이 생성한 instance가 working 메모리에만 존재
스레드2가 인스턴스를 생성

~~volatile~~ 키워드가 선언된 변수는 캐시 메모리를 사용하지 않고, 항상 main 메모리에서 직접 읽고 쓰기 때문에 싱글턴 인스턴스에 volatile 키워드를 선언해주어야 해요. 하지만, volatile 키워드로 선언하면 항상 메인 메모리에서 읽거나 쓰기 때문에 성능 저하가 발생할 수 있습니다.

Enum을 이용한 방식

~~Enum~~을 이용하면, 싱글턴 구현이 굉장히 간단합니다.

또한, Java에서 모든 enum은 프로그램에서 한 번만 인스턴스 화되도록 보장하기 때문에 ~~Thread-safe~~ 합니다.

class Status{
    private final int value;

    Status(int value) {
        this.value = value;
    }
}

public enum EnumSingleton {
    INSTANCE(1, 2);

    private final Status state1;
    private final Status state2;

    // enum 생성자의 기본 접근 제어자(Access Modifier)는 private
    EnumSingleton(int statusValue1, int statusValue2){
        state1 = new Status(statusValue1);
        state2 = new Status(statusValue2);
    }

    public void doSomething(){
        System.out.println("doSomething");
    }
}

class Application{
    public static void main(String[] args) {
        EnumSingleton instance = EnumSingleton.INSTANCE;
        instance.doSomething();
    }
}

doSomething

이 방식의 장/단점은 아래와 같습니다.

Pros

구현 쉬움
Thread-safe 하다.
~~직렬화/역직렬화~~에 대한 처리가 필요없다.

Cons

~~lazy Loading~~이 아니다.

직렬화/역직렬화를 왜 처리해주어야 하나에 대해 살펴보겠습니다.

먼저 ~~Early Loading~~ 방식의 Singleton 클래스가 ~~Serializable~~ 인터페이스를 구현하도록 하고, ~~serialVersionUID~~(직렬화 프로토콜의 고유 식별자)를 추가해주었습니다.

public class Singleton implements Serializable {
    private static final long serialVersionUID = 123456789L;

    private static Singleton INSTANCE = new Singleton();
    private Singleton() {
    }

    public static Singleton getInstance(){
        return INSTANCE;
    }
}

class Test{
	@Test
    @DisplayName("싱글턴 클래스에서 readResolve()를 정의하지 않으면, 싱글턴 인스턴스를 역직렬화할 때 새로운 인스턴스가 생성된다.")
    void test4() throws IOException, ClassNotFoundException {
        // Given
        Singleton serializedInstance = Singleton.getInstance();
        final String fileName = "output.txt";

        // When
        // 직렬화
        try(var out = new ObjectOutputStream(new FileOutputStream(fileName))){
            out.writeObject(serializedInstance);
        }

        // 역직렬화
        Singleton deSerializedInstance = null;
        try(var in = new ObjectInputStream(new FileInputStream(fileName))){
            deSerializedInstance = (Singleton) in.readObject();
        }

        // Then
        Assertions.assertNotEquals(serializedInstance.hashCode(), deSerializedInstance.hashCode());
    }
}

위 테스트 코드는 이 고전적인 싱글턴 패턴을 구현한 클래스의 인스턴스를 파일에 저장하고, 다시 읽어오는 코드에요.

테스트 결과, 성공했어요. 즉, 싱글턴 인스턴스와 역직렬화된 인스턴스가 다른 ~~hashCode~~ 값을 갖고있어요.

이것을 해결하려면, Singleton 클래스에 ~~readResolve()~~를 추가해주면 돼요. 그럼 인스턴스를 역직렬화해도 새로운 인스턴스가 생성되지 않아요.

public class Singleton implements Serializable {
    private static final long serialVersionUID = 123456789L;

    private static Singleton INSTANCE = new Singleton();
    private Singleton() {
    }

    public static Singleton getInstance(){
        return INSTANCE;
    }

    public Object readResolve(){
        return getInstance();
    }
}

그렇다면, enum은 어떨까요?

class Test{
    @Test
    @DisplayName("enum은 싱글턴 인스턴스를 역직렬화해도 새로운 인스턴스가 생성되지 않는다.")
    void test5() throws IOException, ClassNotFoundException {
        // Given
        EnumSingleton serializedInstance = EnumSingleton.INSTANCE;
        final String fileName = "output.txt";

        // When
        // 직렬화
        try(var out = new ObjectOutputStream(new FileOutputStream(fileName))){
            out.writeObject(serializedInstance);
        }

        // 역직렬화
        EnumSingleton deSerializedInstance = null;
        try(var in = new ObjectInputStream(new FileInputStream(fileName))){
            deSerializedInstance = (EnumSingleton) in.readObject();
        }

        // Then
        Assertions.assertEquals(serializedInstance.hashCode(), deSerializedInstance.hashCode());
    }
}

테스트 결과는 성공으로, 역직렬화 해도 새로운 인스턴스가 생성되지 않아요.

싱글턴 패턴의 장점

한 개의 인스턴스만 생성되도록 할 수 있다.
한 개의 인스턴스만 생성되기 때문에, 메모리 공간을 절약할 수 있다.
전역적으로 접근할 수 있다.

싱글턴 패턴의 문제점

Reflection을 통해 인스턴스 생성이 가능하다.

class Test{
	@Test
    @DisplayName("Reflection을 이용하여 싱글턴 클래스의 인스턴스를 직접 생성할 수 있다.")
    void test3() throws Exception {
        Singleton instance = Singleton.getInstance();

        Constructor[] constructors = Singleton.class.getDeclaredConstructors();

        for (Constructor constructor : constructors) {
            constructor.setAccessible(true); // singleton breaker
            Assertions.assertNotEquals(instance, constructor.newInstance());
        }
    }
}

위 코드는 Reflection을 이용하여 싱글턴 클래스의 인스턴스를 직접 생성하는 코드입니다.

이렇게 싱글턴 클래스의 접근 제어자(Access Modifier)가 private라도, Reflection을 이용해서 Singleton 패턴을 무력화시킬 수 있습니다.

인스턴스 생성

Thread-Safe와는 별개로, 클래스 로더를 어떻게 구성하고 있느냐에 따라서 싱글턴 클래스임에도 하나 이상의 오브젝트가 만들어질 수 있습니다. 따라서 자바 언어를 이용한 싱글턴 패턴 기법은 서버 환경에서는 싱글톤이 꼭 보장된다고 볼 수 없습니다. 또한 여러 개의 JVM에 분산되어 설치되는 경우에도 각각 독집적으로 오브젝트가 생기기 때문에 싱글턴으로서의 가치가 떨어집니다.

동기화

싱글턴 인스턴스의 상태가 변할 수 있는 경우, 동시에 접근하는 스레드 간 상호작용에 의해 예기치 않은 결과가 발생할 수 있습니다.

class Test{
	@Test
    @DisplayName("가변 Singleton 인스턴스를 여러 스레드가 이용하는 경우, 동기화 이슈가 발생할 수 있다.")
    void test6() throws Exception{
        // Given
        var executorService = Executors.newFixedThreadPool(10);

        // When
        IntStream.range(0, 1000).forEach((index) -> executorService.submit(() ->{
            Count.getInstance().increase();
        }));
        executorService.awaitTermination(500, TimeUnit.MICROSECONDS);

        // Then
        int resultCount = Count.getInstance().getCount();
        System.out.println(resultCount);
        Assertions.assertNotEquals(1000, resultCount);
    }
}

resultCount : 522

위 코드는 멀티스레드 환경에서 Count 싱글턴 인스턴스의 값을 1000번 증가시키는 코드입니다.

하지만, 결과 값은 522로 훨씬 낮은 값이 출력되는 것을 볼 수 있어요.

따라서 싱글턴이 멀티스레드 환경에서 사용되는 경우, 불변 객체로 만들어져야합니다.

테스트가 어렵다.

싱글톤 객체는 프로그램 전역에서 유일하게 하나의 객체만 존재하기 때문에 ~~Mock Object~~로 대체하기 어렵습니다. Mock Object는 보통 실제 객체와 같은 인터페이스를 구현하며, 테스트 시에는 Mock Object를 실제 객체 대신 사용하여 테스트를 수행합니다.

하지만 싱글톤 객체는 유일하게 하나만 존재해야 하기 때문에 Mock Object로 대체할 수 없습니다. Mock Object로 대체하면 다른 객체에서 해당 싱글톤 객체를 참조하면서 예상치 못한 동작을 할 수 있기 때문입니다. 따라서, 싱글톤 객체를 사용하는 코드를 테스트하기 위해서는 다른 방법을 사용해야 합니다. 예를 들어, ~~의존성 주입(Dependency Injection)~~ 등을 활용하여 싱글톤 객체에 대한 의존성을 주입하는 방법이 있습니다.

유연성이 떨어진다.

싱글턴 인스턴스는 정적 필드로 선언되어 있기 때문에 런타임 시에 동적으로 변경되지 않습니다. 이로 인해 싱글턴 클래스를 다른 클래스로 교체하거나, 여러 개의 인스턴스를 생성하는 것과 같은 일이 어렵습니다.

객체지향적이지 않다.

아무 객체나 자유롭게 접근하고 수정하고 공유할 수 있는 전역 상태를 갖는 것은 객체지향 프로그래밍에서는 지양되어야 할 모델이며, Java에서 Singleton은 private 생성자를 가지므로 상속할 수 없습니다. 따라서 다형성과 같은 객체지향의 특징을 적용하기 어렵습니다. 또한, 상속과 다형성 같은 객체지향의 특징이 적용되지 않는 스태틱 필드와 메소드를 사용해야 합니다.

전역적 사용으로 인해, 프로그램 전체에 영향을 미친다.

싱글턴 클래스의 인스턴스는 전역 상태를 유지하기 때문에 다른 객체와의 의존성이 높아집니다. 이는 코드의 유지보수를 어렵게 만들 수 있으며, 특히 테스트 코드 작성을 어렵게 만들 수 있습니다.

안티패턴으로 여겨지는가?

싱글턴 패턴은 반드시 안티패턴이라고 할 수는 없지만, 앞서 살펴본 문제점 등으로 인해 잘못 사용할 경우 문제가 발생할 수 있는 패턴 중 하나입니다.

~~Spring~~에서는 이러한 싱글턴의 단점을 보완해서 사용하고 있습니다.

Spring의 ~~어플리케이션 컨텍스트~~는 싱글톤을 저장하고 관리하는 ~~싱글톤 레지스트리~~이기도 한데요, 스프링은 기본적으로 별다른 설정을 하지 않으면 내부에서 생성하는 빈(Bean) 오브젝트를 모두 싱글톤으로 만듭니다. 하지만, 우리가 Spring에서 Service 빈을 싱글톤으로 작성했던 적이 있었나요? 없죠. 여기서 싱글턴이라는 것은 디자인 패턴의 싱글턴과 비슷한 개념이지만, 그 구현 방법이 다르기 때문이에요.

~~싱글턴 레지스트리~~의 장점은 스태틱 메서드와 private 생성자를 사용해야 하는 비정상적인 클래스가 아니라 평범한 자바 클래스를 싱글턴으로 활용하게 해줍니다. 평범한 자바 클래스라도 IoC 방식의 컨테이너를 사용해서 생성과 관계 설정, 사용 등에 대한 제어권을 컨테이너에게 넘기면 손십게 싱글턴 방식으로 만들어져 관리되게 할 수 있습니다. 오브젝트 생성에 관한 모든 권한은 IoC 기능을 제공하는 애플리케이션 컨텍스트에게 있기 때문입니다. 이 경우, 테스트 환경에서 자유롭게 오브젝트를 만들 수 있고, 테스트를 위한 Mock 오브젝트로 대체하는 것도 간단합니다. 또한, 생성자 파라미터를 이용해서 사용할 오브젝트를 넣어주게 할 수도 있습니다.

출처

Head First Design Pattern Chapter 5. 싱글턴 패턴
토비의 3.1 VOL.1, 스프링 1.6 싱글턴 레지스트리와 오브젝트 스코프
디자인패턴 - 싱글톤 패턴
Double Checked Locking on Singleton Class in Java - Example
Thread and Locks
Double-checked Locking Pattern (DCLP) 을 쓰지 말아야 하는 이유
Initialization-on-demand holder idiom
All About the Singleton
[Structure] 싱글톤 패턴과 문제점

데코레이터 패턴(Decorator Pattern)이란?

길민호(ethan.mino) — Tue, 4 Apr 2023 22:58:17 +0900

~~데코레이터 패턴(Decorator Pattern)~~으로 객체에 추가 요소를 동적으로 더할 수 있습니다. 데코레이터를 사용하면 서브 클래스를 만들 때보다 훨씬 유연하게 기능을 확장할 수 있습니다.

~~커피 전문점~~의 ~~주문 시스템~~을 예로, 데코레이터 패턴을 단계 별로 설명드리겠습니다.

1단계. 간단한 주문 시스템

먼저, 가장 간단한 구현입니다.

커피 전문점의 주문 시스템

~~Beverage~~ 추상 클래스가 있고, 매장에서 판매되는 모든 음료는 이 클래스의 서브 클래스가 됩니다.

그리고, ~~Beverage~~ 추상 클래스에는 getDescription(), getCost(), getName()이라는 ~~추상 메서드~~가 있습니다.

그래서, 모든 음료는 세 개의 메서드를 모두 구현해야합니다.

~~getDescription()~~은 “가장 훌륭한 다크 로스트 커피”와 같은 음료 설명을 반환하는 메서드이고,

~~getCost()~~는 음료의 가격을 반환하는 메서드,

~~getName()~~은 음료의 이름을 반환하는 메서드입니다.

하지만, 이 시스템에서는 각 음료에 휘핑 크림, 모카, 두유 등의 ~~첨가물~~을 추가할 수 없습니다.

2단계. 첨가물 추가가 가능한 주문 시스템

그래서 첨가물을 추가할 수 있도록 모든 경우의 수에 대해 클래스를 만들면 아래와 같은 구조가 됩니다.

첨가물을 고려한 주문 시스템

이렇게 구현할 경우, 매우 복잡한 구조가 만들어집니다.

만약, 새로운 첨가물이 추가되는 경우, 더 많은 클래스가 만들어져야 해요.

일단은 클래스가 너무 많기 때문에 ~~인스턴스 변수~~와 ~~슈퍼 클래스 상속~~을 써서 첨가물을 관리하도록 해보겠습니다.

(단, 아직 첨가물은 우유, 두유, 휘핑크림, 모카만 가능하다고 가정합니다.)

Beverage 클래스의 다이어그램

그럼, ~~Beverage~~ 클래스가 이러한 구조로 변합니다.

멤버변수로 첨가물의 첨가 여부를 나타내는 milk, soy, whip, mocha가 추가되고, has첨가물(), set첨가물() 메서드가 추가되었습니다.

또한, ~~Beverage~~ 클래스의 getCost() 메서드는 추상 메서드로 정의하지 않고, 구현합니다.

즉, ~~Beverage~~ 클래스의 getCost()는 첨가물의 가격을 계산하고, ~~서브클래스~~의 getCost()에서는 ~~Beverage~~ 클래스가 반환한 첨가물의 가격에 더하여 커피 값을 더한 값을 반환하면 됩니다.

Beverage 추상 클래스의 코드는 이렇습니다.

public abstract class Beverage {
    boolean milk;
    boolean soy;
    boolean mocha;
    boolean whip;

    public Beverage(){
        this.milk = false;
        this.soy = false;
        this.mocha = false;
        this.whip = false;
    }

    public abstract String getDescription();
    public abstract String getName();

    public Double getCost(){
        double condimentCost = 0;
        if(hasMilk()){
            condimentCost += 0.25;
        }
        if(hasSoy()){
            condimentCost += 0.1;
        }
        if(hasWhip()){
            condimentCost += 0.15;
        }
        if(hasMocha()){
            condimentCost += 0.05;
        }
        return condimentCost;
    }

    public boolean hasMocha(){return milk;}

    public boolean hasWhip(){return whip;}

    public boolean hasSoy(){return soy;}

    public boolean hasMilk(){return milk;}

    public void setMilk(boolean milk) {this.milk = milk;}

    public void setSoy(boolean soy) {this.soy = soy;}

    public void setMocha(boolean mocha) {this.mocha = mocha;}

    public void setWhip(boolean whip) {this.whip = whip;}

    public void 기타_메서드들(){}
}

이렇게 구현하는 경우, 앞서 모든 경우의 클래스를 만들었을 때 보다 클래스의 수가 현저히 적습니다.

class DarkRoast{
	public int getCost(){
		return super.getCost() + 0.33;
	}
}

그렇다면, 위 구현은 어떤 문제점이 있을까요??

첨가물 가격이 바뀔 때마다 기존 코드를 수정해야합니다.
첨가물의 종류가 많아지면 새로운 메소드를 추가해야 하고, 슈퍼 클래스의 getCost() 메서드도 고쳐야 합니다.
새로운 음료가 출시될 수도 있습니다. 그 중에는 특정 첨가물이 들어가면 안 되는 음료도 있을 것입니다.
1. 예를 들어, ~~아이스 티~~는 여전히 hasWhip()을 상속 받게 됩니다.
2. 즉, 일부 서브 클래스에 적합하지 않은 행동이 추가되었습니다.
3. ~~Duck~~ 추상 클래스에 fly()를 추가하면서 서브 클래스인 RubberDuck이 fly() 상속받은 것과 같은 문제입니다.
~~더블 모카~~를 주문할 수 없습니다.

상속이 강력하기는 하나,

상속을 사용한다고 해서 무조건 유연하거나 관리하기 쉬운 디자인이 만들어지지는 않습니다.

서브클래스를 만드는 방식으로 행동을 상속 받으면, 그 행동은 ~~컴파일 시점~~에 완전히 결정됩니다.

게다가 모든 서브 클래스에서 똑같은 행동을 상속 받아야 합니다.

3단계. 데코레이터 패턴을 이용한 주문 시스템

하지만, 구성, 위임으로 객체의 행동을 확장하면 실행 중에 동적으로 행동을 설정할 수 있습니다.

따라서, 객체를 동적으로 구성하면, 기존 코드를 고치는 대신 새로운 코드를 만들어서 기능을 추가할 수 있습니다.

기존 코드는 건드리지 않기 때문에 코드 수정에 따른 버그나 의도하지 않은 부작용을 원천봉쇄 할 수 있습니다.

~~OCP(Open-Closed Principle)~~는 정말 중요한 디자인 원칙 중 하나입니다.

디자인 원칙
클래스는 확장에는 열려 있어야 하지만, 변경에는 닫혀 있어야 한다.

우리의 목표는 기존 코드를 건드리지 않고 확장으로 새로운 행동을 추가하는 것입니다.

이후 배울 ~~데코레이터~~ 패턴도 OCP 원칙을 준수합니다.

하지만, 무조건 OCP를 적용한다면, 필요 이상으로 복잡하고 이해하기 힘든 코드를 만들게 되는 부작용이 발생할 수 있으니 주의해야합니다.

❓ 확장에는 열려 있고, 변경에는 닫혀 있다고요? 어떻게 2가지 조건을 동시에 만족할 수 있죠?

✋ 코드를 변경하지 않아도 시스템을 확장하게 해주는 기발한 객체지향 기법은 많습니다. 
옵저버 패턴에서도, 옵저버를 새로 추가하면 subject에 코드를 추가하지 않으면서도 얼마든지 확장할 수 있습니다.

❓ 모든 부분에서 OCP를 준수하려면 어떻게 해야 하나요?

✋ 보통 그렇게 하는 것은 불가능합니다. OCP를 준수하는 객체지향 디자인을 만드려면 적지 않은 시간과 노력이 필요합니다. 
디자인의 모든 부분을 깔끔하게 정돈할 만큼 여유가 있는 상황도 흔치 않습니다. (게다가 그렇게 할 필요가 없습니다.) 
OCP를 지키다 보면 새로운 단계의 추상화가 필요한 경우가 종종 있는데, 추상화를 하다보면 코드가 복잡해집니다. 
그래서 가장 바뀔 가능성이 높은 부분을 중점적으로 살펴보고 OCP를 적용하는 방법이 가장 좋습니다.

❓ 바뀌는 부분 중에서 OCP를 적용할만큼 중요한 부분을 어떻게 골라낼 수 있죠?

✋ 객체지향 시스템 디자인 경험과 지금 건드리고 있는 분야의 지식이 많다면 쉽게 구분할 수 있습니다. 
여러 디자인을 살펴보면 바뀌는 부분 가운데 중요한 부분을 골라내는 안목이 높아집니다.

2단계에서는 문제점이 발견되었습니다.

이번 단계에서는 음료를 첨가물로 ~~장식(decorate)~~ 해보겠습니다.

먼저, 데코레이터의 구조를 먼저 살펴보면 아래와 같습니다.

데코레이터 패턴의 일반화된 구조

주문 시스템에서 ~~Component~~는 ~~Beverage~~를 의미하고, ~~Decorator~~는 첨가물을 의미합니다.

~~ConcreteComponentA/B~~는 DarkRoast와 같은 음료를 의미하고,

~~ConcreateDecoratorA/B~~는 두유, 휘핑크림과 같은 첨가물을 의미합니다.

중요한 점

Component는 직접 쓰일 수도 있고, Decorator에 감싸여 쓰일 수도 있다.
Decorator는 자신이 장식할 구성 요소(ex. DarkRoast)와 같은 ~~인터페이스~~ 또는 ~~추상 클래스~~를 구현한다.
Decorator는 자신이 장식할 Component 객체를 갖는다.
각 ConcreteComponent는 Component를, 각 ConcreteDecorator는 Decorator를 확장한다.
데코레이터가 새로운 메서드를 추가할 수도 있습니다. 하지만, 일반적으로 새로운 메소드를 추가하는 대신 Component에 있던 메서드를 별도의 작업으로 처리해서 새로운 기능을 추가합니다.

일단은 이러한 구조라는 것만 봐주시면 됩니다.

다음으로, 주문 시스템에 Decorator 패턴을 적용한 모습을 보겠습니다.

주문 시스템에 데코레이터 패턴을 적용한 구조

~~Beverage~~는 Component에 대응되고, ~~BeverageCondiment~~는 Decorator에 대응됩니다.

~~BeverageCondiment~~는 자신이 장식할 ~~Beverage~~를 필드로 갖고 있어요.

아 그래서 도대체 어떻게 동작하는건데~?

어떤 고객이 모카와 휘핑크림을 추가한 다크 로스트 커피를 주문한다면, 다음과 같이 장식할 수 있습니다.

~~DarkRoast~~ 객체를 가져온다.
~~Mocha~~ 객체로 장식한다.
~~Whip~~ 객체로 장식한다.
~~getCost()~~ 메서드로 첨가물의 가격을 계산한다.

그림으로 다시 살펴보겠습니다.

~~DarkRoast~~ 객체에서 시작합니다.

DarkRoast는 Beverage로부터 상속받으므로, 음료의 가격을 계산하는 메서드를 갖고 있습니다.

2. 고객이 모카를 추가했으니까 Mocha 객체를 만들고, 그 객체로 ~~DarkRoast~~를 감쌉니다.
여기서 Mocha 객체는 BeverageCondiment의 서브클래스이면서, Beverage의 서브클래스입니다.
따라서, Mocha에도 getCost() 메서드가 있습니다.

3. 고객이 휘핑크림도 추가했으니까 ~~Whip 데코레이터~~로 ~~Mocha~~를 감쌉니다.

Whip도 마찬가지로, cost() 메서드를 갖고 있습니다.

4. 가격을 계산합니다.

가격을 구할 때는 가장 바깥쪽에 있는 데코레이터인 ~~Whip~~의 getCost()를 호출하면 됩니다.

그러면 Whip은 그 객체가 장식하고 있는 객체에게 가격 계산을 위임합니다.

가격이 구해지고 나면, 계산된 가격에 휘핑크림의 가격을 더한 다음 그 결과값을 리턴합니다.

코드로 보면 아래와 같습니다.

class Whip implements BeverageCondiment{
	private final Beverage beverage;

	public int getCost(){
		return beverage.getCost() + .33;
	}
}

Beverage beverage = new Whip(new Mocha(new DarkRoast()));
System.out.println(beverage.getCost()) // 1.29

지금까지 배운 내용을 한 번 정리해보겠습니다.

데코레이터의 슈퍼 클래스는 자신이 장식하고 있는 객체의 슈퍼 클래스와 같다.
한 객체를 여러 개의 데코레이터로 감쌀 수 있다.
데코레이터는 자신이 감싸고 있는 객체와 같은 슈퍼클래스를 갖고 있기에 원래 객체(싸여있는 객체)가 들어갈 자리에 데코레이터 객체를 넣어도 상관없다.
데코레이터는 자신이 장식하고 있는 객체에게 어떤 행동을 위임하는 일 말고도 추가 작업을 수행할 수 있다.
객체는 언제든지 감쌀 수 있으므로 실행 중에 필요한 데코레이터를 마음대로 적용할 수 있다.

❓ CondimentDecorator에서 Beverage 클래스를 확장하고 있는데, 그럼 상속 아니야..?

✋ 상속을 사용하고 있는 것은 맞습니다. 
하지만, 형식을 맞추기 위해 사용한 것이지, 행동을 물려받기 위해 상속을 사용한 것은 아니에요. 
어떤 구성 요소를 가지고 데코레이터를 만들 때, 새로운 행동을 추가합니다. 
슈퍼 클래스로부터 행동을 상속 받아서 얻는 것이 아니라 객체를 구성해서 새로운 행동을 얻는 거죠. 
만약 상속만 써야 했다면, 행동이 컴파일시에 정적으로 결정되어 버리지만, 
객체 구성을 이용하고 있기 때문에 실행 중에 데코레이터를 조합해서 사용할 수 있기 때문에, 
새로운 첨가물이 추가되어도 유연성을 잃지 않을 수 있어요.

❓ 구성 요소의 형식만 상속하면 되는 거라면 Beverage 클래스를 왜 인터페이스로 만들지 않고 추상 클래스로 만든 건가요?

✋ Beverage 클래스를 받았을 때부터 추상 클래스였기 때문이에요. 
사실 인터페이스를 쓰면 되지만, 기존 코드를 고치는 일은 될 수 있으면 피하는 게 좋으니까 추상 클래스를 써도 되는 상황이라면, 
그냥 추상 클래스만 가지고 작업을 하는 게 나을 수도 있어요.

데코레이터 패턴을 적용한 코드는 아래 깃헙 주소에서 확인하실 수 있습니다!

GitHub - rlfalsgh95/design-pattern

Contribute to rlfalsgh95/design-pattern development by creating an account on GitHub.

github.com

데코레이터의 적용된 예 : 자바 I/O

~~java.io~~는 데코레이터 패턴을 바탕으로 만들어졌어요.

파일에서 데이터를 읽어오는 스트림에 기능을 더하는 데코레이터를 사용하는 객체는 보통 다음과 같은 형식으로 구성됩니다.

java.io의 사용 예

~~FileInputStream~~을 데코레이터로 장식할 예정입니다.

자바 I/O 라이브러리는 FileInputStream, StringBufferInputStream 등 다양한 구성 요소를 제공합니다.

이는 모두 바이트를 읽어들이는 구성 요소 역할을 합니다.

~~BufferedInputStream~~은 구상 데코레이터입니다.

FileInputStream에 입력을 미리 읽어서 더 빠르게 처리할 수 있게 해주는 버퍼링 기능을 더해 주는 역할을 합니다.

~~ZipInputStream~~도 구상 데코레이터입니다.

zip 파일에서 데이터를 읽어올 때, 그 속에 들어있는 항목을 읽는 기능을 더해주죠.

~~java.io~~ 패키지의 구조는 아래와 같아요.

java.io  패키지 구조

굉장히 복잡하죠.

InputStream만 떼어서 한 번 보겠습니다.

java.io  InputStream의 구조

어디서 많이 본 구조 아닌가요?

여기서 ~~InputStream~~은 ~~Component~~ 역할을, ~~FileInputStream~~은 ~~Decorator~~의 역할을 수행합니다.

구조가 단순히 이러한 모양을 갖고 있다고 데코레이터 패턴은 아니에요.

구상 데코레이터인 ~~FileInputStream~~과 ~~BufferedInputStream~~의 코드를 보겠습니다.

FileInputStream의 생성자

BufferedInputStream의 생성자

~~FileInputStream~~은 ~~InputStream~~이면서, InputStream을 필드로 갖고 있습니다.

~~BufferedInputStream~~은 생성자 파라미터로 InputStream을 받아서 FileInputStream을 초기화 하고 있습니다.

~~BufferedInputStream~~는 필드로 갖고 있는 in의 기능에 더해서 ~~버퍼링~~ 기능을 확장한 클래스라 보시면 되겠습니다.

그럼 이 ~~InputStream~~은 어떻게 사용할까요?

알고리즘 문제를 풀 때, 버퍼링 기능을 이용하여 ~~Scanner~~보다 더 빠르게 입력 받기 위해 아래와 같은 방식을 사용해보신 분들도 많을 거에요.

저도 문제를 풀 때는 몰랐지만, ~~데코레이터 패턴~~이라고 하더라구요.

InputStreamReader input = new InputStreamReader(new BufferedInputStream(System.in));

~~Reader/Writer 스트림~~도 InputStream과 거의 똑같이 디자인 되어 있습니다.

자바 I/O를 보면 잡다한 클래스가 많고, 복잡하다는 것을 발견할 수 있는데요, 이것이 데코레이터 패턴의 단점 중 하나입니다.

자 그럼 직접 입력 데코레이터를 만들어볼게요!

입력 스트림에 있는 대문자를 전부 소문자로 바꿔주는 데코레이터를 만들어 볼게요.

public class LowerCaseInputStream extends FilterInputStream {
    public LowerCaseInputStream(InputStream in){
        super(in);
    }

    // ! 입력 스트림으로부터 다음 byte를 읽는 메서드, 더이상 읽을 byte가 없으면 -1을 반환한다.
    @Override
    public int read() throws IOException {
        int c = in.read();
        return (c == -1 ? c : Character.toLowerCase((char)c));
    }

    // ! 이 입력 스트림에서 최대 len byte의 데이터를 byte 배열로 읽습니다.
    // ! 버퍼로 읽은 총 바이트 수 또는 스트림 끝에 도달하여 더 이상 데이터가 없는 경우 -1을 반환한다.
    @Override
    public int read(byte[] b, int off, int len) throws IOException {
        int result = in.read(b, off, len);
        for(int i = off; i < off + result; i++){
            b[i] = (byte) Character.toLowerCase((char)b[i]);
        }
        return result;
    }
}

~~read() 메서드~~는 입력 스트림으로부터 다음 byte를 읽는 메서드에요.

이 메서드 안에서 필드로 갖고 있는 In의 read() 메서드를 호출한 다음,

그 결과를 소문자로 바꿔줌으로써, 소문자 변환 기능을 확장하였습니다.

아래 test.txt 파일을 읽어서 소문자로 바꾸는 코드를 작성해볼게요.

hello. This is ethan, who announced the Decorate Pattern.

class InputTest {
    @Test
    void test(){
        int c;
        StringBuilder stringBuilder = new StringBuilder();
        try(InputStream in = new LowerCaseInputStream(new BufferedInputStream(new FileInputStream("./src/test/resources/test.txt")))){

            while((c = in.read()) > 0){
                stringBuilder.append((char) c);
            }
        }catch (Exception e) {
            e.printStackTrace();
        }

        Assertions.assertEquals(stringBuilder.toString(), "hello. this is minho gil, who announced the decorate pattern.");
    }
}

~~FileInputStream~~는 파일에서 byte를 읽고, ~~BufferdInputStream~~은 버퍼링 기능을 확장하였고,

마지막으로 ~~LowerCaseInputStream~~은 소문자로 변환하는 기능을 확장하였어요.

결국, 파일에서 읽은 byte를 소문자로 변환하여 가져올 수 있었어요!

이외에도 다른 요구사항이 추가되어도, 데코레이터를 추가함으로써, 기존 코드를 수정하지 않고도 기능을 확장할 수 있습니다.

더블 모카는 어떻게 만들 수 있을까?

class BeverageTest {
    @Test
    @DisplayName("더블 모카 다크 로스트의 가격은 1.05이다.")
    void test1(){
        Beverage beverage = new Mocha(new Mocha(new DarkRoast()));
        assertEquals(beverage.getCost(), 1.05);
    }
}

장/단점?

Pros

런타임에 동작을 수정할 수 있다.
데코레이터는 상속보다 유연한 방식으로 기능을 추가할 수 있습니다. 즉, 데코레이터는 객체 간의 결합도를 낮추며, 객체 지향 설계의 원칙 중 하나인 개방-폐쇄 원칙(OCP)을 따릅니다.
높은 유연성을 갖고 있어, 유지보수가 용이하다. (서브 클래스를 이용하여 기능을 확장할 수 있다.)
기존 클래스를 수정하지 않고도 새로운 기능을 추가할 수 있습니다. 이는 코드의 유지보수와 확장성을 높여줍니다.

cons

데코레이터 패턴을 사용하면, 클래스 계층 구조가 매우 복잡해질 수 있습니다. 이는 설계 과정에서 클래스 계층 구조를 잘 고려해야 함을 의미합니다.
데코레이터 패턴을 구현하는 과정에서, 많은 중복 코드가 발생할 수 있습니다. 이는 코드 가독성을 떨어뜨릴 수 있습니다.
데코레이터 패턴이 중첩되어 사용될 경우, 코드가 복잡해질 수 있습니다. 이는 디버깅과 유지보수에 어려움을 더할 수 있습니다.

출처

Head First Design Pattern Chapter. 3
https://neillmorgan.wordpress.com/2010/02/07/decorator-pattern-pros-and-cons/

신입 서버 개발자의 합격 후기 (Feat. Kakao 최종합격, SSAFY 8기)

길민호(ethan.mino) — Thu, 1 Dec 2022 18:57:55 +0900

그동안의 개발자 생활을 정리하고, 하소연하는 게시글입니다.

⚠️ 개인적인 경험, 의견이므로 참고만 하세요!

학교 생활

군 입대 전, 나는 프로그래밍에 큰 흥미를 느끼지 못했고, 학점은 1.7점대에, 학사 경고까지 받았다.

그저 동아리 활동과 학생회, 그리고 노는 것이 즐거웠다.

군 전역 후에는, 지도 교수님의 따끔한 조언이 동기가 되었고, 일단 학교 성적이라도 잘 받아보자는 생각으로 열심히 노력했다.

얼마나 공부해야 좋은 성적을 받을 수 있는 지도 몰랐고, CS 지식도 전무 했던 상태라 정말 정말 정말 정말 열심히 했다.

밥은 샌드위치로 때우고, 1시간 반 거리의 통학 길에서도 책을 읽었다.

그리고, 매 수업마다 강의가 끝나면 녹음을 들으며 수업을 정리했고, 시험 기간에는 잠을 쫓기 위해 야외에서 허벅지 내려치며 공부했다.

결국, 5학기 연속 차석/수석을 기록할 수 있었다.

2학년 때는 어느 한 동아리원이 대학원생에게 필요한 정보를 제공해주는 챗봇을 만들어줄 수 있냐는 요청을 받았다.

(지금은 그때 이용했던 ~~오픈 빌더~~와 관련된 부서에서 일하고 있다)

이때 처음으로 서비스를 만들어보았고, "개발자란 누군가에게 편의를 제공해줄 수 있구나"라는 생각이 들었고, 눈에 보이는 결과물을 보고 개발에 큰 매력을 느꼈다.

그리고 무엇보다 기획부터, 개발 그리고 서비스하는 과정 자체가 즐거웠고 설렜다. 그 때부터 여러 프로젝트를 진행했다.

4학년 때는 AI에 관심이 생겼고, ~~멀티미디어 보안 랩실~~에 들어가서 ~~CNN 네트워크~~와 ~~PRNU 알고리즘~~을 이용하여

~~SMDB~~라는 이미지 데이터 셋에 대한 검증을 수행하고, 논문을 작성하는 역할을 맡았고, ~~KCI~~에 논문이 등재되었다.

또한, 군 입대 전의 학점을 복구 하기 위해 22 ~ 23학점을 신청했고, 논문/졸업 프로젝트/토이 프로젝트로 인해 취업을 준비하지 못했던 것이 아쉽다.

스펙

교육

XX대학교 멀티미디어 보안랩 (학부연구생) (2020.12 ~ 2022.01)
XX대학교 컴퓨터과학과 졸업, 학점 3.94 (2014.03 ~ 2022.02)
삼성 청년 SW 아카데미 8기 (2022.07.06 ~ 2022.11.25)

자격증

정보처리기사 (2020.11.12 취득)
SQL 개발자 (2021.10.01 취득)
PCCP cpp level 3, 700점 (2022.10.23 취득)

프로젝트

Good-I-Deer
- 2019.09 ~ 2019.12 (약 3개월)
- XX대학교 문화기술대학원생들이 빈번하게 찾는 정보를 카카오톡 챗봇을 통하여 제공하는 서비스
코로나 웹
- 2020.08 ~ 2020.09 (약 1개월)
- 안심 식당/병원의 정보와 코로나 확진자 정보를 제공하는 웹 사이트
전자상거래 주문 수집 자동화 및 재고 관리 사이트
- 2020.04 ~ 2020.12 (약 8개월)
- 전자상거래 주문 수집 자동화 및 재고 관리 사이트
️ Rest Camping
- 2021.09 ~ 2021.12 (약 3개월)
- 캠핑장 예약 플랫폼
❤️ 들어줄게
- 2021.03 ~ 2021.10 (약 8개월)
- 사용자가 챗봇에게 지인, 연예인, 캐릭터등의 음성을 학습시킬 수 있으며, 음성을 학습한 챗봇과 속마음을 털어놓을 수 있는 AI 음성 챗봇

논문

크라우드소싱을 통해 수집된 카메라 소스 식별 데이터셋(이미지)의 검증 및 공유
- 2021.03 ~ 2022.01 (약 11개월)
- 크라우드소싱 방식을 통해 수집된 Sangmyung Image Database (SMDB)의 유효성 검증 및 데이터 공유

기술 스택

Backend	~~Spring Boot~~, ~~Spring MVC~~, ~~Express~~, ~~Spring Security~~, ~~JSP~~, ~~Node.js~~, ~~Mybatis~~, ~~Swagger~~, ~~Selenium~~, ~~Puppeteer~~, ~~Mysql~~ ~~JAVA~~, ~~Javascript~~ ~~Maven~~, ~~Gradle~~
Frontend	~~HTML5~~, ~~CSS~~, ~~Javascript~~ ~~jQuery~~, ~~ES6~~
DevOps	~~Linux~~, ~~Docker~~ ~~NGINX~~, ~~Tomcat~~, ~~Apache~~ ~~EC2~~, S3
Collaboration	~~Notion~~, ~~Trello~~
Configuration Management	~~git~~
Tools	~~XMind~~, ~~StarUML~~ ~~Postman~~, ~~Talend API Tester~~ ~~Putty~~, ~~Wireshark~~, ~~FileZila~~ ~~Visual Studio Code~~, ~~PyCharm~~, ~~intellij~~

상반기 지원 현황

~~당근마켓 백엔드 개발 인턴~~ - 서류 탈락
~~티맥스 Fintech, AI, Office~~ - 서류 탈락
라인 - 코딩 테스트 탈락
~~카카오 채용 연계 인턴~~ - 코딩 테스트 탈락
~~엔씨소프트 인턴~~ - 코딩 테스트 탈락
~~카카오 페이 신입 개발자~~ - 코딩 테스트 탈락
~~라인 플러스 Ads Server Engineer~~ - 코딩 테스트 탈락
~~오늘의 집~~ - 서류 합격, 코딩 테스트 탈락

~~네이버 Code Your Careers 인턴십~~ - 서류/코딩 테스트 합, 1차 면접 탈락
~~SSAFY 8기~~ - 최종합격
~~다나와~~ - 최종합격
~~엔젤스윙 인턴~~ - 최종합격
렛시 - 최종 합격
로민 - 최종 과제 테스트 불참

학부생 때는 취업 준비를 못했던 탓에 알고리즘, 자료구조 역량이 부족했다.

코딩 테스트가 취업의 많은 비중을 차지한다는 것 자체에 무지했다.

그래서 상반기에는 빠킹독님의 실전 알고리즘 강의와 문제집으로 알고리즘과 자료구조 공부를 시작했다.

그리고 자기소개서와 포트폴리오를 작성하고 다듬었다.

당시에는, 포트폴리오도 없었고, 코딩 테스트 역량도 부족했기 때문에 지원을 많이 하지 않았는데, 이 부분이 조금 아쉽다.

그나마 곁에 있던 친구가 지원하라고 옆에서 쪼아서 많이 넣었다.

여러 스타트업에 지원하면서 부족한 점을 파악해서 채우고, 면접 역량을 키웠다. 그리고 코딩 테스트 출제 유형을 파악했다.

대규모의 사용자들 대상으로 서비스하고 있는 대기업을 목표로 하고 있었기 때문에 최종 합격한 스타트업 및 중견기업은 가지 않았다.

상반기가 끝났고, 혼자 준비하기엔 학습해야할 양도 많고 지치기 쉽기 때문에, 여러 개발자들과 함께 학습하는 것이 좋겠다고 생각했다.

그래서, ~~SSAFY~~에 지원하였고, 운이 좋게 합격하였다.

주변인들은 이미 프로젝트와 역량이 충분하니 가지 않아도 된다는 의견이었지만,

나는 함께할 개발자들이 절실했고, 여러 개발자들을 만나고 싶었다.

‍♀️ SSAFY

대전 지역 Java 전공 반으로 배정되었다.

SSAFY에서는 ~~Java~~부터 시작하여, ~~알고리즘~~, ~~HTML/CSS/Javascript~~, ~~Web~~, DB, ~~Spring MVC~~, ~~Spring Boot~~, ~~Vue.js~~을 약 5개월 동안 속성으로 교육한다.

또한, 매주, 매월 시험을 치르며 일정 횟수 이상 통과해야 1학기를 수료할 수 있고, 매 주제가 끝나면 해당 기술을 이용하여 간단한 프로젝트를 진행한다.

나는 사전 지식이 있음에도 불구하고, 취업 준비랑 병행하려니 버거웠다.

그래서 SSAFY 수업보다 스터디에 집중하였다.

~~SSAFY~~의 장단점은 아래와 같다.

SSAFY의 장점

여러 프레임워크, 언어, 기술 등에 대한 복기
취업지원센터의 면접, 자소서 등 취업에 대한 체계적인 도움
여러 기업의 채용 우대
여러 개발자들과 함께 스터디, 취업 준비
100만원의 지원금, 점심 지원
삼성 임직원 멘토링, 삼성 B형 응시 기회, 기업 탐방 등의 다양한 지원

SSAFY의 단점

프로그래밍이 처음이라면 커리큘럼을 따라가기 매우 어렵고, 깊숙한 이해는 본인이 별도로 학습해야함
취업을 준비하는데 오히려 시간을 뺏길 수 있음 (과목평가, 월말평가, 프로젝트 등 ...)
짧은 개발 기간으로 인해 탄탄한 프로젝트를 진행하기 어렵고, 교육생들이 많기 때문에 프로젝트에 대한 피드백을 받기 어려움
오프라인 수업으로 인한 통학 시간
본가와 캠퍼스가 먼 경우, 방을 구해야 함

결과적으로는, SSAFY에 입과한 것에 매우 만족하고 있다.

SSAFY는 충분한 지원을 제공하고 있으며, 본인이 필요한 부분만 얻어간다면, 많은 도움을 받을 수 있다.

알고리즘 & 자료구조

SSAFY 입과 전에는 빠킹독님의 실전 알고리즘 강의와 문제집으로 알고리즘과 자료구조 역량을 쌓았고,

SSAFY 입과 후에는 5명 ~ 7명의 교육생들과 알고리즘/CS 스터디를 진행하였다.

스터디는 일주일에 두 번 진행하였고, 매 스터디마다 백준 문제와(빠킹독님 문제집, 삼성 A형 기출) 프로그래머스의 카카오 기출을 2 ~ 3 문제씩 풀어와서 코드 리뷰하는 방식으로 진행하였다.

또한, 주기적으로 ~~기업 코딩 테스트~~, ~~삼성 역량 테스트~~, ~~PCCP~~에 응시하여, 자주 출제되는 유형과 현재 역량을 파악하였다.

⚠️ 알고리즘 공부 방식은 아래 포스팅을 참고해주세요!

2022 코딩 테스트 후기 (라인 플러스, 오늘의 집, 카카오 인턴십 ...)

본 게시글은 아래의 코딩 테스트를 경험하고 느낀점에 대한 게시글입니다. 주관적인 느낀점이니 참고만 해주시면 감사하겠습니다! 라인 플러스 (2022.03.26) 원티드 (2022.04.02) 오늘의 집 (2022.04.

codingnotes.tistory.com

Computer Science

~~CS 스터디~~는, CS 지식을 쌓고, ~~기술 면접~~에 대비하기 위한 스터디로,

매주 2명의 인원이 발표 주제를 정하고, 학습한 내용을 발표하는 방식으로 진행하였다. (짧게는 10분, 길게는 한 시간)

CS 주제는 아래와 같다.

Java
컴퓨터 구조
디자인 패턴 <- 여기까지만 진행하고 취뽀
네트워크
Web
운영체제
데이터베이스
프레임워크
아키텍처

정보의 신뢰성이 없다면, 팀원들 모두가 잘못된 정보를 얻어갈 수 있기 때문에

CS 스터디의 가장 중요한 점은 ~~정보의 신뢰성~~이라고 생각한다.

이를 방지하기 위해서 팀원들이 최대한 질문을 많이 하도록 분위기를 이끌었다.

질문을 반복하면서 정보의 오류를 찾아낼 수 있고, 질문에 충분히 답변하려면,

발표자는 해당 주제에 대해 정확하게 학습해야 하기 때문에, ~~정보의 신뢰성~~을 높일 수 있다.

발표 자료를 준비하고, 다른 팀원의 학습 자료를 습득하면서 보다 더 깊숙한 CS 지식을 얻었고 기술 면접에서 좋은 성적을 낼 수 있었다.

하반기 지원 현황

~~신한은행 (디지털/ICT 수시채용 삼성청년 SW 아카데미 특별 전형)~~ - 서류 탈락
~~쿠팡 신입 공채~~ - 추천서, 서류 탈락
~~카카오 뱅크 채용연계형 인턴~~ - 서류 탈락
~~현대 오토에버~~ - 서류/코테 탈락
~~요기요 Rookies 5기~~ - 서류/코딩 테스트 탈락

~~CJ E&M~~ - 서류 합, 코딩 테스트 불참
~~KT DS 2022년 하반기 신입사원 공개 채용~~ - 서류 합, 코딩 테스트 불참
~~2022 넷마블 컴퍼니 신입사원 공개 채용~~ - 서류/코딩 테스트 합, 필기 불참

~~KT SW 개발 역량 우수자 블라인드 채용 신입~~ - 코딩 테스트 합, 1차 면접 탈락
~~넥토리얼 2기 채용형 인턴십~~ - 서류/코딩 테스트 합, 최종 면접 탈락
~~2023 카카오 Blind 신입 공채~~ - 최종합격

상반기에는 지원하는 것을 회피했는데, 코딩 테스트가 어느 정도 준비가 되어,

하반기에는 이름 있는 스타트업과 대기업에 많이 지원하였다. 포트폴리오는 상반기와 동일한 상태였다.

여러 번 지원하다보니 자료가 많이 쌓여 자소서를 작성하는 시간이 많이 줄어들어, 닥치는 대로 지원하였다.

원래는 2023년도 상/하반기에 취업하는 것을 목표로 하고 있었다.

하지만, 막상 몇 기업에서 합격하니 욕심이 났고, 조바심이 생겼다.

~~KT DIGICO~~는 프레임워크와 프로젝트 DB 설계에 대한 질문에 잘 대답하지 못했고, 1차 면접에서 탈락하였다.

넥슨은 인턴십이기도 하고, 면접 제의온 곳들은 스킬셋이 맞지 않았고, 면접도 잘 보지 못했다.

그래서 기대를 많이 하고 있진 않았고, 최종 면접에서 떨어졌다.

~~카카오~~는 면접을 그럭저럭 보았고, 내심 기대하였는데 결국, 최종 합격할 수 있었다.

⚠️ 카카오 채용 자세한 후기는 아래 포스팅을 참조해주세요.

2023 Kakao Blind 신입 공채 최종 합격 후기 (프로그래밍 직무)

길고 긴 두달 간의 채용 전형이 마무리 되었고, 드디어 학부생 때 부터 꿈에 그리던 카카오에 합격하였다. 11월 24일로 결과 발표가 예정되어 있었지만, 오전에 결과가 발표되지 않았고, 일부 지

codingnotes.tistory.com

❗️취준Tip

본인이 가려는 회사가 어떤 유형의 회사인지 고민 (서비스 기업/제조사/SI/은행, 대기업/스타트업 …)

고민하는 과정에서 본인의 개발 가치관에 대해서도 고민할 수 있고, 회사 유형에 따라 인재상이 다르기 때문에 앞으로 준비해야할 스펙들이 조금 더 명확해집니다.

프로젝트 수 보다는 퀄리티

여러 개의 프로젝트를 했냐를 중요시하는 기업도 있지만, 서비스 기업의 경우 하나의 프로젝트라도 얼마나 고민을 했냐를 더 중요시합니다. 또한, 프로젝트 수가 적어도 붙은 분들이 꽤 있으니까 너무 부담갖지 마시고, 천천히 깊숙히 고민하며 프로젝트를 진행하시면 좋을 것 같습니다.

또한, 프로젝트 수가 많으면 오히려 답변하기 어렵기 때문에, 저는 확실하게 답변할 수 있는 2 ~ 3개 정도만 어필했습니다.

⚠️ 프로젝트 기획의도도 중요합니다!

포트폴리오, Git, 블로그 다듬기

포트폴리오, Git, 블로그를 꾸준히 작성하고 다듬어 가세요.

어떻게 공부해왔는지 기록할 수 있고, 면접관님들이 들어와서 꼼꼼히 보십니다. 보기 쉽게, 꾸준히 본인의 기록을 남겨놓으면 좋게 보실 거 같습니다.

⚠️ 레포마다 Readme.md도 잘 정리

지원은 다다익선

지금 당장 부족하더라도 기업에 꾸준히 지원하면서 코딩 테스트에 참여하고 자기소개서를 많이 쓰는 것도 중요합니다.

자기소개서를 쓰고, 다듬으면서 자료가 점점 쌓이면서, 자소서 작성하는 시간이 줄어들고, 퀄리티가 높아집니다.

또한 코딩 테스트를 여러 번 참가해야, 기업이 어떤 유형을 출제하는 지 알 수 있고, 테스트 환경에 적응할 수 있습니다.

CS 학습

CS 스터디를 꼭 꼭 꼭 꼭 꼭 하세요. 코딩 테스트는 한 관문일 뿐입니다.

코딩 테스트를 지나고 나면 ~~CS 테스트~~나 ~~기술 인터뷰~~가 있습니다.

이를 통과하려면 꾸준한 CS 스터디가 중요합니다. 하지만, 단 기간의 학습은 꼬리 질문에 답변하기 어렵습니다.

여러 명이 면접 질문 리스트를 만들어서 다 같이 질문을 채워나가고, 스터디를 통해서는 좀 더 깊숙한 지식을 채워나가는 것을 추천합니다.

개발자에 대한 깊은 고민

인성 인터뷰를 통과하려면 협업 경험, 소통 역량도 중요하지만, 개발에 얼마나 진심이고, 얼마나 고민했냐를 보는 질문들을 하십니다.

평소에 내가 왜 개발을 하고 싶은지, 좋은 개발자란 무엇이고, 이를 위해 나는 어떤 노력을 하고 있는지 등 개발 철학과 가치관에 대해 깊은 고민이 필요합니다.

그간의 경험 정리

면접 전형에서는 본인이 어떻게 학습해왔고, 어떤 경험을 했는지, 어떤 가치관을 가지고 있는 지, 내가 어떤 경쟁력을 갖고 있는지 짧은 시간 동안 보여주어야 합니다. 그 간 잘 해왔어도 이 부분에 대한 정리가 부족하면, 면접관에게 어필하기 어렵습니다.

평소에 꾸준히 정리하기! 나에게 장점이 없어 보여도, 프로젝트가 너무 부실해보여도 고민하다보면, 분명 분명 어필할 점이 있습니다!

⚠️ 어찌보면 프로젝트보다도 더 중요! 이미 당신은 준비되어 있을 지 모릅니다.

"코딩 테스트라도 봐야지"하고 붙은 분들이 꽤 있었습니다.

멀리 가고 싶다면 함께 가라

혼자 취업을 준비하기에는 너무 많은 양입니다.

최대한 여러 명이 정보를 공유하고, 자료를 쌓아나가 효율적으로 준비하기!

22.11.15 SSAFY 스터디 CS 발표 - 디자인 패턴 (전략 패턴)

길민호(ethan.mino) — Thu, 1 Dec 2022 14:07:25 +0900

❓ 전략 패턴 (Strategy)

객체들이 할 수 있는 행위 각각에 대해 전략 클래스를 생성하고, 유사한 행위들을 캡슐화 하는 인터페이스를 정의하여, 객체의 행위를 동적으로 바꾸고 싶은 경우 직접 행위를 수정하지 않고 전략을 바꿔주기만 함으로써 행위를 유연하게 확장하는 방법을 말합니다.

전략 패턴도 마찬가지로 단계별로 설명하겠습니다.

1단계 (상속을 이용한 Simple Duck)

오리 시뮬레이션 게임을 예로 들겠습니다.

오리시뮬레이션 게임의 클래스 다이어그램

~~quck()~~ : 꽥꽥거리는 소리를 내는 메서드
~~swim()~~ : 헤엄치는 메서드
~~display()~~ : 오리의 고유한 모양을 화면에 보여주는 메서드

~~Duck~~이라는 추상 클래스가 있고, 여러 유형의 오리가 Duck 클래스로부터 상속을 받습니다.

모든 오리가 꽥꽥 소리를 낼 수 있고, 헤엄을 칠 수 있으므로, ~~quack()~~과 ~~swim()~~은 슈퍼 클래스에 작성합니다.

또한, 오리별로 모양이 다르므로, 오리를 화면에 보여주는 ~~display() 메서드~~는 추상 메서드로 선언하여, 서브 클래스에서 반드시 구현하도록 하였습니다.

fly() 기능을 추가한 클래스 다이어그램

이제 오리들이 날 수 있도록 하기 위해서 Duck 클래스에 ~~fly() 메서드~~를 추가하였습니다.

따라서, 모든 서브 클래스에서 fly()를 상속 받습니다.

고무오리(Rubber Duck)을 추가한 클래스 다이어그램

하지만, Duck이라는 슈퍼 클래스에 fly() 메서드를 추가하면서, 날아다니면 안 되는 오리(고무오리, RubberDuck)에게도 날아다니는 기능이 추가되었습니다.

즉, 일부 서브 클래스에 적합하지 않은 행동이 추가 되었습니다.

RubberDuck 클래스 내부

그래서, ~~RubberDuck~~의 fly() 메서드가 호출되었을 때, 아무것도 하지 않도록 오버라이드 해주었습니다.

하지만, 임원진이 앞으로 6개월마다 제품을 업데이트하기로 결정했습니다.

즉, 앞으로 규격이 계속 바뀔 것입니다.

따라서, 상속을 계속 활용한다면, 규격이 바뀔 때마다 프로그램에 추가했던 Duck 클래스의 메서드들을 일일이 살펴보고 상황에 따라 오버라이드 해야 합니다.

(예를 들면, 나무로 된 가짜 오리는 날 수도, 소리를 낼 수도 없기 때문에 quack()과 fly() 메서드가 아무것도 하지 않도록 오버라이딩 해주어야 합니다.)

2단계 (행동 인터페이스)

상속이 옳은 방법이 아니라는 사실을 깨달았습니다.

그래서 fly()를 Duck 슈퍼 클래스에서 빼고, ~~Flyable 인터페이스~~를 만들었습니다.

이렇게 하면 날 수 있는 오리만 Flyable 인터페이스를 구현해서 날아다니는 행동, 즉, fly() 메서드를 넣을 수 있습니다.

(~~quack()~~도 마찬가지)

행동 인터페이스를 추가한 클래스 다이어그램

하지만, 이러한 설계의 경우, 각 날아다니는 방식의 코드를 재사용할 수 없다는 문제가 있습니다.

	ADuck 클래스	BDuck 클래스	CDuck 클래스
날아다니는 방식	(가)	(나)	(나)

위와 같은 경우, Flyable 인터페이스의 fly() 메서드가 ~~디폴트 메서드~~이고, ~~(나)~~ 방식으로 작성되어 있다고 하더라도,

~~(가)~~ 방식으로 날아다니는 오리 클래스 ~~DDuck 클래스~~가 새로 추가 된다면,

~~(가)~~ 방식으로 날아다니는 fly() 메서드는 ~~ADuck 클래스~~와 ~~DDuck 클래스~~에서 중복됩니다.

하지만, ADuck 클래스와 DDuck 클래스의 fly() 메서드는 재사용할 수 없습니다.

따라서 코드 관리에 커다란 문제가 발생합니다.

따라서, ~~(가)~~ 방식이 수정되는 경우, ~~(가)~~ 방식으로 날아다니는 오리 클래스들의 fly() 메서드를 일일이 모두 수정해주어야 하고, 그 과정에서 새로운 버그가 생길 가능성도 있습니다.

3단계 (행동 클래스 집합)

3단계는 아래와 같은 디자인 원칙을 적용한 방식입니다.

애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분과 분리한다.

여러 디자인 원칙 가운데 첫 번째 원칙으로, 모든 디자인 패턴의 기반을 이루는 원칙입니다.

달라지는 부분을 찾아서 나머지 코드에 영향을 주지 않도록 캡슐화한다면, 코드를 변경하는 과정에서 달라지지 않는 부분에는 영향을 미치지 않으면서, 의도치 않게 발생하는 일을 줄이고, 시스템의 유연성을 향상시킬 수 있습니다.

~~fly()~~와 ~~quack()~~는 오리의 종류에 따라 달라지지만, 나머지 부분(display(), swim()) 은 자주 달라지지 않거나 바뀌지 않습니다.

따라서, Duck 클래스는 그대로 두는 것이 좋습니다.

~~fly()~~와 ~~quack()~~을 Duck 클래스로부터 분리하려면 2개의 메서드를 Duck 클래스에서 모두 끄집어내고, 각 행동을 나타낼 클래스 집합을 새로 만들어야 합니다.

나는 행동과 꽥꽥거리는 행동을 구현하는 클래스 집합은 어떻게 디자인해야 할까요?

Duck의 인스턴스에 행동을 할당할 수 있도록 해서, 최대한 유연하게 만드는 것이 좋습니다.

예를 들어, ~~MallardDuck~~ 인스턴스를 특정 형식의 나는 행동으로 초기화 하거나, 오리의 행동을 동적으로 바꿀 수 있도록 디자인 하는 것입니다.

일단 이렇게 목표를 정해놓고, 두 번째 디자인 원칙을 살펴보겠습니다.

구현보다는 인터페이스에 맞춰서 프로그래밍한다.

이 디자인 원칙은 상현님이 발표하신 ~~SOLID 원칙~~ 중 ~~의존관계 역전 원칙~~을 의미합니다.

즉, “구현클래스가 아닌, 인터페이스에 의존하도록 해야 한다.”라는 걸 의미합니다.

(여기서 인터페이스는 자바의 인터페이스만을 의미하는 것이 아니라, 인터페이스라는 개념을 지칭하는 용도로도 쓰입니다)

즉, 핵심은 실제 실행 시에 쓰이는 객체가 코드에 고정되지 않도록 상위 형식에 맞춰 프로그래밍하여 다형성을 활용해야 한다는 점에 있습니다.

인터페이스 즉, 역할에 의존하게 되면 유연하게 구현체를 바꿀수 있게 됩니다.

⚠️ 구현 의존 VS 인터페이스 의존으로 이동!

이러한 디자인 원칙을 고려하여서 설계를 수정해보겠습니다.

먼저, 각 행동은 ~~인터페이스~~(ex. FlyBehavior, QuackBehavior)로 표현하도록 수정합니다.

그리고, 이제 나는 행동과 꽥꽤거리는 행동은 Duck 클래스에서 구현하는 것이 아니라, 특정 행동만을 목적으로 하는 클래스 집합에서 구현합니다.

두 번째 디자인 원칙을 고려한 fly 행동 설계

이전 방법은 항상 특정 구현에 의존했기 때문에 행동을 변경할 여지가 없었습니다.

새로운 디자인을 사용하면, 나는 행동과 꽥꽥거리는 행동은 특정 행동 인터페이스를 구현한 별도의 클래스 안에 있습니다.

따라서, Duck 클래스에서는 그 행동을 구체적으로 구현할 필요가 없습니다.

두 번째 디자인 원칙을 고려한 fly, quack 행동 설계

이 설계에서는 ~~FlyBehavior~~와 ~~QuackBehavior~~라는 2개의 인터페이스를 사용합니다.

그리고 구체적으로 핼동을 구현하는 클래스들이 있습니다.

또한, FlyBehavior과 QuackBehavior 인터페이스에는 구현 클래스에서 반드시 구현하도록 특정 행동을 나타내는 메서드가 선언되어 있습니다.

각 구현 클래스는 특정 행동에 맞춰서 이 메서드를 구현하면 됩니다.

이런 식으로 디자인하면, 다른 형식의 객체에서도 나는 행동과 꽥꽥거리는 행동을 재사용할 수 있습니다.

또한, 기존의 행동 클래스를 수정하거나 날아다니는 행동을 사용하는 Duck 클래스를 전혀 건드리지 않고도 새로운 행동을 추가할 수 있습니다.

즉, 상속의 부담을 떨쳐 버리고도, 재사용의 장점을 누릴 수 있습니다.

❓ 매번 바뀔 수 있는 부분을 찾아낸 후, 바뀌는 것과 바뀌지 않는 것을 분리해서 캡슐화하는 식으로 작업해야 하나요?

✋ 언제나 그렇게 해야 하는 것은 아닙니다. 
애플리케이션을 디자인 하는 과정에서 바뀔 수 있는 부분을 예측하고 대처해서 유연한 코드를 만들 수도 있습니다. 
여기에서 설명하는 원칙과 패턴은 개발 라이프사이클 어느 단계에서든지 적용할 수 있습니다.

❓ 행동만 나타내는 클래스를 만든다는 게 이상하게 느껴지네요, 클래스는 원래 어떤 대상을 나타내는 것 아닌가요? 클래스에는 상태와 행동이 모두 들어있어야 하지 않나요?

✋ 객체지향 시스템에서는 질문한 내용이 맞습니다. 
클래스는 일반적으로 상태(인스턴스 변수)와 메서드를 모두 가지고 있습니다. 
그런데, 이 경우에는 클래스가 '행동'을 가지고 있습니다. 
하지만, 행동에도 여전히 상태와 메서드가 들어 있을 수 있습니다. 
fly 행동에 속성(ex. 1분당 날개를 펄럭이는 횟수, 최고 높이, 속도)을 나타내는 인스턴스 변수를 넣을 수도 있으니까요.

4단계 (동적으로 행동 지정하기)

가장 중요한 점은 나는 행동과 꽥꽥거리는 행동을 Duck 클래스 또는 서브 클래스에서 정의한 메서드를 써서 구현하지 않고, 다른 클래스에 위임한다는 것입니다.

동적으로 오리의 행동을 지정해주기 위해, Duck 클래스에 ~~flyBehavior~~과 ~~quackBehavior~~라는 인터페이스 타입의 멤버 변수를 추가합니다. (특정 서브 클래스의 타입으로 선언하지 않습니다.)

각 오리 객체는 실행 시 이 행동 인터페이스 타입의 레퍼런스 변수에 특정 행동 객체(FlyWithWings 등)를 설정합니다.

또한, 나는 행동과 꽥꽥거리는 행동은 FlyBehavior와 QuackBehavior 인터페이스로 옮겨놨으므로, Duck 클래스와 모든 서브 클래스에서 fly()와 quack() 메서드를 제거하고, Duck 클래스에 performFly()와 performQuack()을 추가합니다.

Duck 클래스

그럼, 이러한 형태의 Duck 클래스가 만들어집니다.

그럼, flyBehavior 레퍼런스 변수에는 언제 어떤 객체가 들어갈까요?

먼저, Duck 클래스에 행동 객체를 파라미터로 전달하는 ~~setter() 메서드~~를 정의한 후,

실행 시 동적으로 오리의 행동을 지정하는 방식을 생각해볼 수 있습니다.

interface QuackBehavior {
	public void quack();
}

interface FlyBehavior {
	public void fly();
}

class Quack implements QuackBehavior {
	public void quack() {
		System.out.println("Quack");
	}
}

class MuteQuack implements QuackBehavior {
	public void quack() {
		System.out.println("<< Silence >>");
	}
}

class FlyRocketPowered implements FlyBehavior {
	public void fly() {
		System.out.println("I'm flying with a rocket");
	}
}

class FlyNoWay implements FlyBehavior {
	public void fly() {
		System.out.println("I can't fly");
	}
}

abstract class Duck {
	FlyBehavior flyBehavior;
	QuackBehavior quackBehavior;

	public Duck() {}

	abstract void display();

	public void setFlyBehavior(FlyBehavior fb) {
		flyBehavior = fb;
	}

	public void setQuackBehavior(QuackBehavior qb) {
		quackBehavior = qb;
	}
	
	public void performFly() {
		flyBehavior.fly();
	}

	public void performQuack() {
		quackBehavior.quack();
	}

	public void swim() {
		System.out.println("All ducks float, even decoys!");
	}
}

class MallardDuck extends Duck {

	public MallardDuck() {}

	public void display() {
		System.out.println("I'm a real Mallard duck");
	}
}

class MiniDuckSimulator1 {
 
    public static void main(String[] args) {
            Duck mallard = new MallardDuck();
            mallard.setFlyBehavior(new FlyRocketPowered());
            mallard.setQuackBehavior(new MuteQuack());
            mallard.performQuack();
            mallard.performFly();

            System.out.println();

            // setter() 메서드를 이용하여 날아다니는 행동, 소리를 내는 행동을 교체
            mallard.setFlyBehavior(new FlyNoWay());
            mallard.setQuackBehavior(new Quack());
            mallard.performQuack();
            mallard.performFly();
    }
}

<< Silence >>
I'm flying with a rocket

Quack
I can't fly

~~performFly()~~와 ~~performQuack()~~ 메서드에서는 Duck 클래스, 즉 슈퍼 클래스로부터 상속받은 flyBehavior와 quackBehavior에 의해 참조되는 객체의 ~~fly()~~와 ~~quack()~~ 메서드를 호출하여 행동을 위임해주면 됩니다.

다음으로, 생성자에서 초기화하는 방식을 생각해볼 수 있습니다.

abstract class Duck {
    private FlyBehavior flyBehavior;
	private QuackBehavior quackBehavior;

    public Duck() {}
    public Duck(QuackBehavior quackBehavior, FlyBehavior flyBehavior){
        this.quackBehavior = quackBehavior;
        this.flyBehavior = flyBehavior;
    }
    
    abstract void display();

    public void performFly() {
        flyBehavior.fly();
    }

    public void performQuack() {
        quackBehavior.quack();
    }

    public void swim() {
        System.out.println("All ducks float, even decoys!");
    }
}

class MallardDuck extends Duck{
    public MallardDuck(QuackBehavior quackBehavior, FlyBehavior flyBehavior){
        super(quackBehavior, flyBehavior);
    }

    @Override
    void display() {

    }
}

class MiniDuckSimulator1 {
    public static void main(String[] args) {
        QuackBehavior muteQuack = new MuteQuack();
        FlyBehavior flyRocketPowerd = new FlyRocketPowered();

        Duck mallard = new MallardDuck(muteQuack, flyRocketPowerd);
        mallard.performQuack();
        mallard.performFly();
    }
}

~~setter()~~ 메서드 방식의 경우, 실행 시에 언제나 오리의 행동을 바꿀 수 있지만, setter() 메서드가 아니라 생성자에서 오리의 행동을 지정 해준다면, 오리 객체의 행동을 실행 시에 결정하고 난 이후 임의로 오리의 행동을 수정할 수 없도록 할 수 있습니다.

(단, 슈퍼 클래스의 오리 행동 객체를 ~~private~~로 설정)

마지막 단계까지 마쳤을 때, 프로젝트는 이러한 모습의 구조가 됩니다.

구현 의존 VS 인터페이스 의존

Animal, Dog, Cat 클래스 다이어그램

~~Animal~~이라는 ~~추상 클래스~~가 있고, ~~Dog~~와 ~~Cat~~이라는 서브 클래스가 있다고 가정해보겠습니다.

구현에 의존하여 프로그래밍한다면 다음과 같이 할 수 있습니다.

Dog dog = new Dog();
d.bark();

하지만, 이러한 방식의 경우, Animal의 구현체를 유연하게 바꿀 수 없다는 단점이 있습니다.

Animal animal = new Dog();
animal.makeSound();

위 코드는 Dog라는 구현체가 아닌 Animal 인터페이스에 의존한 예시입니다.

이 경우, Animal 추상 클래스의 구현체를 갈아낄 수 있다는 장점이 있습니다.

하지만, 이 경우에도 구현체를 갈아끼려면 코드의 수정이 필요합니다.

따라서, 아래와 같은 코드가 더 바람직한 방법입니다.

Animal animal = getAnimal();
animal.makeSound();

구현체를 넣어주는 코드를 직접 작성해주는 대신, 실행 시에 대입하는 방식을 통해서, 기존 코드를 수정하지 않아도 구현체를 바꿔줄 수 있습니다.

전략 패턴의 장단점

장점

1. 전략 사용자(context)의 코드 변경 없이 새로운 전략을 추가 할 수 있다.

따라서 "확장에는 열려있으나 변경에는 닫혀있어야 한다"를 의미하는 Open/Close Prinipal을 준수할 수 있습니다. 
또한, if - else 분기를 제거할 수 있습니다.

2. 런타임에 전략을 변경시킬 수 있다.

단점

1. Strategy 객체와 Composition클래스 객체 사이에 의사소통 오버헤드가 발생할 수 있다.

서브클래스에서 구현할 알고리즘의 복잡함과는 상관없이 모든 ConcreteStrategy 클래스는 Strategy 인터페이스를 공유한다. 
따라서 어떤 ConcreteStrategy 클래스는 이 인터페이스를 통해 들어온 모든 매개변수를 다 사용하지 않는데도 전달받아야 할 때가 생긴다. 
즉, 사용되지도 않을 매개변수를 Composition 객체가 생성하고 초기화하는 경우가 발생할 수 있다.

2. 객체 수가 증가한다.

Strategy들로 생성하는 객체 수가 증가한다.

참조

Head First Design Pattern Chapter.01 디자인 패턴 소개와 전략 패턴
객체지향 설계 5원칙 SOLID (이상현)
디자인패턴 - 전략 패턴(Strategy Pattern) in Javascript
디자인 패턴 : 전략패턴이란?

2023 카카오 블라인드 신입 공채 프로그래밍 직무 최종 합격 후기 (1, 2차 코딩 테스트, 1, 2차 면접)

길민호(ethan.mino) — Thu, 1 Dec 2022 00:59:00 +0900

⚠️ 자세한 취업 과정은 아래 포스트를 참고해주세요!

서버 개발자 신입의 취뽀 후기 (Feat. Kakao 최종합격, SSAFY 8기 후기)

그동안의 개발자 생활을 정리하고, 하소연하는 게시글입니다. ⚠️ 개인적인 경험, 의견이므로 참고만 하세요! 학교 생활 군 입대 전, 나는 프로그래밍에 큰 흥미를 느끼지 못했고, 학점은 1.

codingnotes.tistory.com

길고 긴 두달 간의 채용 전형이 마무리 되었고, 드디어 학부생 때 부터 꿈에 그리던 ~~카카오~~에 합격하였다.

11월 24일로 결과 발표가 예정되어 있었지만, 오전에 결과가 발표되지 않았고,

일부 지원자들에게는 지연 메일까지 왔었기 때문에 마음 졸이고 있었다.

15시에 합격 결과가 발표되었고, 보자마자 SSAFY 강의실을 뛰쳐나와 가족들과 지인들에게 합격 소식을 알렸다.

부모님이 그렇게 좋아하시는 모습은 정말 대학교 합격 이후 처음 본 것 같다.

직무는 현재 ~~Server~~ 직무로 결정되었고, 부서는 아직 미정이다.

지금까지는 학부생, 취준생으로써 학습해왔지만,

이제는 엄연한 직장인으로써 업무를 시작하게 될 것이다.

앞으로, 최고의 개발자들 옆에서 도태되지 않고, 성장하기 위해 그리고 더 많은 사용자들에게 편의를 제공하는 서비스를 개발하기 위해 끊임없이 노력할 것이다.

1차 코딩 테스트

1차 코딩 테스트는 블라인드 채용 기출 문제보다 약간 쉬운 수준으로 출제되었다.

문제는 4문제를 풀었고, 합격 컷이 5문제가 되지 않을까 싶었는데 다행히 합격할 수 있었다.

(직무 : ~~프로그래밍~~, 풀이 언어 : ~~C++~~)

(~~1차 코딩 테스트~~ : 9월 24일, ~~결과 발표~~ : 10월 04일 19:30)

2차 코딩 테스트

~~API~~를 사용하여 문제를 풀이해야하는데,

API를 호출하고, 데이터를 가져오는 과정을 ~~Java~~로 하면, 시간이 더 걸릴 것 같아서 ~~Python~~을 사용했다.

이 전에 Python을 다뤄본 적이 있어서, 1차 코딩 테스트 발표 후,

간단히 Python 문법을 복기하고, 프로그래머스의 2차 코딩테스트 기출 문제를 풀어보았던게 많이 도움되었다.

(2차 코딩 테스트 전, 미리 API를 호출하는 모듈을 만들어놓았다)

첫 솔루션을 테스트 했을 때는 전체 24등을 기록했고,

이후, 최종 제출 한 시간 전까지 약 98등을 기록했지만, 이후 100등 이하로 떨어졌다.

오히려 1차 코딩 테스트보다 난이도가 낮았고, 구현만 제대로 한다면, 점수를 얻어낼 수 있었다.

600점대인데, 2차 코딩 테스트를 통과하신 분이 있는 걸 보면, 합격 컷이 너무 높지는 않은 것 같다.

(최종 점수 : ~~895점~~, 풀이 언어 : ~~Python~~)

(~~2차 코딩 테스트~~ : 10월 8일, ~~결과 발표~~ : 10월 17일 19:45)

아래는 2차 코딩 테스트 깃헙 레포 주소입니다.

GitHub - rlfalsgh95/2023_KAKAO_ASSIGNMENT_TEST: 2023 카카오 과제 테스트

2023 카카오 과제 테스트. Contribute to rlfalsgh95/2023_KAKAO_ASSIGNMENT_TEST development by creating an account on GitHub.

github.com

1차 인터뷰

나는 1차 인터뷰 첫 날에 일정이 잡혔다. (10월 31일)

신입 공채 단톡방에 면접 스터디를 모집하는 분들이 있으셨고, 그 중 SSAFY 교육생이 모집하는 스터디가 있어서 참여하였다.

자소서와 2차 코딩 테스트에 대한 간단한 솔류션을 공유하고, 그에 대한 예상 질문을 서로 작성해주었다.

1차 인터뷰는 화상으로 진행되었고, 생각보다 기본적인 CS 질문을 하셨다.

그 간 해왔던 CS 스터디와 면접 스터디의 내용이 많이 나와서 나름 잘 답변하였다.

하지만, 끝나고 나니 부족했던 점들이 생각나서, 크게 기대하고 있지 않았는데, 다행히 합격하였다.

(~~지원서 제출~~ : 10월 21일 ~ 10월 26일)

(~~1차 인터뷰~~ : 10월 31일 ~ 11월 03일, ~~결과 발표~~ : 11월 9일 11:00)

2차 인터뷰

2차 인터뷰도 인터뷰 첫 날에 일정이 잡혔다. (11월 14일)

1차 인터뷰를 붙을 지 모르고 준비가 전혀 안된 상태에 첫 날에 일정이 잡혀서 멘붕이 왔었다.

부랴 부랴 SSAFY 취업지원센터에 도움을 요청하여 방향을 잡았다.

기술적 인성 면접이었기 때문에 기술 면접을 준비하지는 않았고, 인성 면접만 준비하였다.

개발 가치관, 협업 경험, 갈등 해결 경험 등을 정리하였다.

인터뷰 전 날에는 압박감이 너무 심해서, 바람을 쐬면서 생각을 정리했다.

2차 인터뷰는 편안한 분위기로 진행되었고, 긴장을 풀고 잘 답변하였다.

(생각보다 정리했던 내용은 나오지 않았고, 예상하기 어려운 질문을 해주셨다)

마찬가지로, 몇가지 걸리는 점이 있었지만, 합격할 수 있었다.

인성 면접에서는 대부분의 인원이 합격할 거라 생각했지만, 오픈채팅방을 보니 생각보다 많은 인원들이 탈락하였다.

다 같이 붙어서 아지트에서 보자 으쌰 으쌰 했지만, 참 아쉬웠다.

분위기가 좋았지만 떨어지신 분도 있었고, 애매한 분위기였지만 합격하신 분도 있었다.

그리고 화려한 경력의 중고 신입도, 고학력자도, 좋은 학벌을 가진 분도 있었지만 안타깝게 떨어지셨다.

결국, 면바면이니 걱정 내려놓고 전형을 이어나가면 좋을 것 같다.

(~~2차 인터뷰~~ : 11월 14일 ~ 11월 17일, ~~결과 발표~~ : 11월 24일 15:00)

2022.11.09일 서버 개발자 취준생의 성장 일지 ✍

길민호(ethan.mino) — Wed, 9 Nov 2022 13:13:14 +0900

~~카카오~~ 1차 인터뷰에 합격하였다..

인터뷰가 끝나고 난 후, 생각해보니 아쉬운 답변들이 있었는데 다행이다.

붙을 줄은 정말 상상도 못했는데, 합격이라는 단어를 보고 굉장히 놀랐다.

SSAFY에서 했던 알고리즘/CS 스터디가 많이 도움된 것 같다.

하지만, 기대했다가 최종면접에서 떨어지면 너무 힘들 것 같기 때문에

아직은 카카오에 입사할 것이라 기대하지 않으려고 한다.

당장 다음주부터 인성 면접을 보아야하기 때문에,

그동안 개발자로써의 생각들을 잘 정리해야겠다.

+ ~~KT SW 역량 우수자 전형~~은 탈락했다.

Spring Framework와 내 프로젝트에 대한 분석이 부족했다.

+ ~~넥토리얼 2기~~ 면접 결과는 21일 공개된다..!

마케팅 개발팀은 면접 시간이 짧았지만, 실무적인 부분까지 질문 하셨고, 잘 답변하지 못했기 때문에 탈락을 예상하고 있고,

라이브 웹실 면접에서는 나름 기본적인 CS와 인성 질문에 대해 답변했기 때문에 결과를 기다리는 중이다.

22.11.8 SSAFY 스터디 CS 발표 - 디자인 패턴 (템플릿 메서드 패턴)

길민호(ethan.mino) — Mon, 7 Nov 2022 16:48:15 +0900

❓ 템플릿 메서드 패턴이란?

템플릿 메서드 패턴은 알고리즘의 골격을 정의합니다. 템플릿 메서드를 사용하면, 알고리즘의 일부 단계를 서브 클래스에서 구현할 수 있으며, 알고리즘의 구조는 그대로 유지하면서 알고리즘의 특정 단계를 서브 클래스에서 재정의할 수도 있습니다.

~~템플릿 메소드~~는 알고리즘의 템플릿(틀)로, 일련의 단계로 알고리즘을 정의한 메서드입니다.

템플릿 메서드는 여러 단계 가운데 하나 이상의 단계가 ~~추상 메서드~~로 정의되며, 추상 메서드는 서브 클래스에서 구현됩니다.

이러면, 서브 클래스가 일부분의 구현을 처리하게 하면서도 알고리즘의 구조는 바꾸지 않아도 됩니다.

❗️예 1 (커피와 홍차)

커피와 홍차는 매우 비슷한 방법으로 만들어집니다.

~~prepareRecipe() 메서드~~는 알고리즘의 절차를 정의한 메서드입니다.

그리고, 각 메소드는 알고리즘의 각 단계를 구현합니다.

먼저, 커피를 우려내는 ~~Coffee 클래스~~입니다.

public class Coffee{
	void prepareRecipe(){
		boilWater();// 물을 끓인다.
		brewCoffeeGrinds(); // 끓는 물에 커피를 우려낸다.
		pourInCup(); // 커피를 컵에 따른다.
		addSugarAndMilk(); // 설탕과 우유를 추가한다.
	}
	
	public void boilWater() {
		System.out.println("물 끓이는 중");
	}
	
	public void brewCoffeeGrinds() {
		System.out.println("필터로 커피를 우려내는 중");
	}
	
	public void pourInCup() {
		System.out.println("컵에 따르는 중");
	}
	
	public void addSugarAndMilk() {
		System.out.println("설탕과 우유를 추가하는 중");
	}
}

다음은 홍차를 우려내는 ~~Tea 클래스~~입니다.

Tea 클래스는 두 번째 단계와 네 번째 단계가 조금 다르지만, 기본적으로 Coffee 클래스와 유사합니다.

~~steepTeaBag()~~, ~~addLemon()~~은 홍차 전용 메서드이지만, ~~boilWater()~~와 ~~pourInCup()~~은 Coffee 클래스와 동일합니다.

즉, 중복된 코드가 발생하였습니다.

public class Tea{
	void prepareRecipe(){
		boilWater(); // 물을 끓인다.
		steepTeaBag(); // 끓는 물에 찻잎을 우려낸다.
		pourInCup(); // 홍차를 컵에 따른다.
		addLemon(); // 레몬을 추가한다.
	}
	
	public void boilWater() {
		System.out.println("물 끓이는 중");
	}
	
	public void steepTeaBag() { // 홍차 전용 메서드
		System.out.println("찻잎을 우려내는 중");
	}
	
	public void pourInCup() { 
		System.out.println("컵에 따르는 중");
	}
	
	public void addLemon() { // 홍차 전용 메서드
		System.out.println("레몬을 추가하는 중");
	}
}

그럼 어떻게 하면 중복되는 코드를 줄일 수 있을까요? 단계 별로 설계를 수정해보겠습니다.

Coffee와 Tea의 수정된 구조

먼저, 두 클래스의 공통된 부분을 추상화해서 ~~베이스 클래스~~로 만드는 방법을 생각해볼 수 있습니다.

먼저, 커피와 홍차 모두 카페인 음료이기 때문에 ~~CaffeineBeverage~~를 베이스 클래스로 두었고, 서브 클래스에서 메서드를 구현할 수 있도록 ~~추상 클래스~~로 두었습니다.

~~prepareRecipe()~~는 서브 클래스마다 다르기 때문에 ~~추상 메서드~~로 선언하였고,

~~boilWater()~~과 ~~pourInCup()~~은 두 클래스에서 공통으로 사용되므로, CaffeineBeverage 클래스에 정의하였습니다.

서브 클래스는 prepareRecipe()를 오버라이드해서 구현하고, brewCoffeeGrinds()와 같이 해당 클래스에만 존재하는 메서드는 서브 클래스에 그대로 두었습니다.

하지만, 현재 구조에서는 커피와 홍차의 제조 과정이 비슷함에도 서브 클래스에서 구현해야 된다는 단점이 있습니다.

아래는 커피와 홍차에 모두 적용시킬 수 있는 알고리즘입니다.

물을 끓인다.
뜨거운 물을 사용해서 커피 또는 찻잎을 우려낸다.
만들어진 음료를 컵에 따른다.
각 음료에 맞는 첨가물을 추가한다.

위 알고리즘은 커피와 홍차에 모두 적용시킬 수 있기 때문에, prepareRecipe(), 즉 카페인 음료의 제조 절차를 베이스 클래스에 추상화할 수 있습니다.

이전 설계에서, ~~Coffee 클래스~~는 brewCoffeeGrinds()와 addSugarAndMilk() 메서드를 쓰고,

~~Tea 클래스~~는 steepTeaBag()과 addLemon()을 사용합니다.

따라서, brewCoffeeGrinds()와 steepTeaBag()을 ~~brew() 메서드~~로 일반화하고, addSugarAndMilk()와 addLemon()은 ~~addCondiments()~~ 즉, 첨가물을 넣는 함수로 일반화 해주겠습니다.

public abstract class CaffeineBeverage{
	final void prepareRecipe() {
		boilWater();
		brew();
		pourInCup();
		addCondiments();
	}
	
	abstract void brew();
	abstract void addCondiments();

	void boilWater() {
		System.out.println("물 끓이는 중");
	}
	
	void pourInCup() {
		System.out.println("컵에 따르는 중");
	}
}

public class Tea extends CaffeineBeverage{
	@Override
	void brew() {
		System.out.println("찻잎을 우려내는 중");
	}

	@Override
	void addCondiments() {
		System.out.println("레몬을 추가하는 중");
	}
}

public class Coffee extends CaffeineBeverage{
	@Override
	void brew() {
		System.out.println("필터로 커피를 우려내는 중");
	}

	@Override
	void addCondiments() {
		System.out.println("설탕과 우유를 추가하는 중");
	}
}

서브 클래스에 공통되는 메서드를 베이스 클래스에 정의해주었고, 서브 클래스마다 다르게 구현하는 brew()와 addCondiments() 메서드는 ~~추상 메서드~~로 선언하였습니다.

서브 클래스는 CoffeinBeverage를 상속 받아서 추상 메서드를 구현해주면 됩니다.

(CoffeinBeverage 클래스의 prepareRecipe() 메서드와 같은 ~~Concrete 메서드~~는 ~~final~~로 선언하여, 서브 클래스에서 재정의하지 못하도록 할 수도 있습니다)

prepareRecipe()는 서브 클래스가 임의로 오버라이딩 할 수 없도록, final로 선언하였습니다.

~~prepareRecipe()~~가 ~~템플릿 메서드~~입니다. 즉, 어떤 알고리즘의 템플릿 역할을 합니다.

여기서는 카페인 음료를 만드는 알고리즘의 템플릿인 것입니다.

⚠️ Concrete 메서드란 ~~Default Method~~, ~~Abstract Method~~, ~~interface private Method~~ 외의 메서드를 의미

❗️예 2 (Hook 메서드)

후크는 추상 클래스에서 선언되지만, 기본적인 내용만 구현되어 있거나, 아무 코드도 들어있지 않은 메서드입니다.

추상 클래스에 후크 메서드가 있으면, 서브 클래스는 그 메서드를 선택적으로 오버라이딩 할 수 있습니다.

오버라이드하지 않으면, 추상 클래스에서 기본으로 제공한 코드가 실행됩니다.

public abstract class CaffeineBeverageWithHook {
 
	void prepareRecipe() {
		boilWater();
		brew();
		pourInCup();
		if (customerWantsCondiments()) {
			addCondiments();
		}
	}
 
	abstract void brew();
 
	abstract void addCondiments();
 
	void boilWater() {
		System.out.println("Boiling water");
	}
 
	void pourInCup() {
		System.out.println("Pouring into cup");
	}
 
	boolean customerWantsCondiments() {
		return true;
	}
}

public class CoffeeWithHook extends CaffeineBeverageWithHook {
	@Override
	public void brew() {
		System.out.println("Dripping Coffee through filter");
	}
 
	@Override
	public void addCondiments() {
		System.out.println("Adding Sugar and Milk");
	}
 
	// 첨가물의 추가 여부를 반환하는 함수
	@Override
	public boolean customerWantsCondiments() {

		String answer = getUserInput();

		if (answer.toLowerCase().startsWith("y")) {
			return true;
		} else {
			return false;
		}
	}
 
	private String getUserInput() {// 유저의 키보드로부터 입력받는 함수
		String answer = null;
		
		System.out.print("Would you like milk and sugar with your coffee (y/n)? ");
		
		BufferedReader in = new BufferedReader(new InputStreamReader(System.in));'

		try {
			answer = in.readLine();
		} catch (IOException ioe) {
			System.err.println("IO error trying to read your answer");
		}

		if (answer == null) {
			return "no";
		}
		return answer;
	}
}

CaffeineBeverageWithHook 클래스, 즉, 추상클래스의 ~~customerWantsCondiments()~~의 구현부를 보면 단순히 true를 반환하고 있습니다.

서브 클래스는 이 메서드를 선택적으로 오버라이딩 하면 됩니다.

위의 CoffeeWithHook 클래스는 추상 클래스의 ~~Hook 메서드~~를 오버라이딩 하였습니다.

따라서, 커피를 제조할 때 사용자에게 입력을 받아서 첨가물의 추가 여부를 결정하게 됩니다.

반면, 서브 클래스가 이 메서드를 구현하지 않는다면, 카페인 음료를 제조할 때, 반드시 첨가물을 추가합니다.

❓ 템플릿을 만들 때 추상 메서드를 써야될 때와 후크를 써야할 때를 어떻게 구분할 수 있나요?

✋ 서브 클래스가 알고리즘의 특정 단계를 필수로 제공해야 한다면 추상 메서드를 써야 합니다. 
알고리즘의 특정 단계가 선택적으로 적용된다면, 후크를 쓰면 됩니다.

❓ 추상 메서드가 너무 많아지면 서브 클래스에서 일일이 추상 메서드를 구현해야 하니까 별로 좋지 않을 것 같아요.

✋ 알고리즘 단계를 너무 잘게 쪼개지 않는 것도 한 가지 방법입니다. 
하지만, 알고리즘을 큼직한 몇 가지 단계로만 나눠 놓으면 유연성이 떨어진다는 단점도 있습니다. 
또한, 모든 단계가 필수가 아니기 때문에, 필수가 아닌 부분을 후크로 구현하면, 
그 추상 클래스의 서브 클래스를 만들 때 부담이 줄어듭니다.

실 사용 예시 (Arrays.sort())

private static void mergeSort(Object[] src, Object[] dest,
	                            int low, int high, int off) {
		// 많은 코드
		
		for (int i=low; i<high; i++){
				for (int j=i; j>low && 
						((Comparable) dest[j-1]).compareTo(dest[j])>0; j--)
		        swap(dest, j, j-1);
		}
		
		// 많은 코드
}

~~Arrays~~의 ~~mergeSort()~~ 함수를 보면 이런식으로 작성되어 있습니다.

mergeSort() 안에서는 compareTo()와 swap()이라는 method를 사용합니다.

compareTo() - Comparable 인터페이스의 메서드
swap() - Arrays 클래스에 의미 정의되어 있는 Concreate 메서드

이러한 mergeSort()도 ~~템플릿 메서드~~라고 할 수 있습니다.

❓ Arrays는 추상 클래스도 아닐 뿐더러, Arrays의 서브 클래스를 만들지 않았는데 템플릿 메서드 패턴인가?

Array를 상속받을 수 있을 때

✋ 실전에서 패턴을 적용는 방법이 책에 나와있는 방법과 완전히 같을 수는 없습니다. 
주어진 상황과 구현상 제약조건에 맞게 고쳐서 적용해야합니다.
Arrays의 mergeSort() 메서드를 디자인한 사람도 몇 가지 제약조건이 있었습니다. 
자바에서는 배열의 서브 클래스를 만들 수 없지만, 
모든 타입의 배열에 대해 정렬 기능을 사용할 수 있도록 만들어야 했습니다. 
그래서 정적 메소드를 정의한 다음, 대소를 비교하는 부분은 정렬될 객체에서 구현하도록 만든겁니다. 
만약 Array가 상속 가능했다면 위와 같은 방식으로 구현됐을 것입니다.

❓ 추상 클래스 말고, 인터페이스의 디폴트 메소드로 템플릿 메소드 패턴을 구현할 수 있지 않나요?

✋ 인터페이스의 경우, 디폴트 메서드는 final로 정의할 수 없어 재정의가 가능하기 때문에, 
추상 클래스에서 알고리즘을 독점할 수 없습니다. 
또한, 인터페이스의 모든 추상 메소드는 public이므로 
템플릿 메서드 내부에서만 호출되어야 할 메서드들이 의도치 않은 사용처에서 호출될 위험이 있습니다.

템플릿 메서드 패턴의 장점

시시한 Tea와 Coffee 클래스	템플릿 메서드로 새로 만든 CoffeinBeverage 클래스
Coffee와 Tea 클래스가 각각 작업을 처리하고, 두 클래스에서 각자 알고리즘을 수행	CaffeineBeverage 클래스에서 작업을 처리하고, 알고리즘을 독점
Coffee와 Tea 클래스에 중복된 코드가 존재	CaffeineBeverage 클래스 덕분에 공통 메서드를 서브 클래스에서 재사용할 수 있음
알고리즘이 바뀌면, 서브 클래스를 일일이 고쳐주어야 함	알고리즘이 한 군데 모여 있으므로, 한 부분만 고치면 됨
클래스 구조상 새로운 음료를 추가하려면, 꽤 많은 일을 수행해야 하며, 중복 코드가 또 발생함	다른 음료도 쉽게 추가할 수 있는 프레임워크를 제공, 음료를 추가할 때 몇 가지 메서드만 더 만들면 됨
알고리즘 지식과 구현 방법이 여러 클래스에 분산되어 있음	CaffeineBeverage 클래스에 알고리즘 지식이 집중되어 있으며, 일부 구현만 서브 클래스에 의존. 즉, 알고리즘과 구체적인 구현을 분리할 수 있음.

참조

Head First Design Pattern Chapter 8, 템플릿 메소드 패턴
[Design Pattern] 템플릿메소드(Template Method)란?
[Design Pattern] 템플릿 메서드 패턴이란
How does the JLS specify the terms "abstract method", "concrete method" and "default method"?
JLS 8.4.3.1, JLS 9.4

백트래킹(Backtracking)이란?

길민호(ethan.mino) — Wed, 2 Nov 2022 00:54:02 +0900

백트래킹이란?

1. 현재 상태에서 가능한 모든 후보군을 따라 들어가며 탐색하다가, 가능성이 없다고 판단되면, 되돌아가서 다시 해를 찾아가는 기법
2. 조합, 순열, 부분집합도 가지치기가 없는 백트래킹이라고 할 수 있습니다.
3. 백트래킹을 이용하여, 완전탐색을 수행할 수 있고, 가지치기를 통해 최적화가 가능합니다.

백트래킹은 크게 두 부분으로 구분할 수 있습니다.

void back(int depth, int m){
    if(depth == m){
        // 1. 선택한 원소로 기반으로 결과를 계산하는 부분
    }else{
        // 2. 원소를 선택하는 부분
    }
}

꿀팁

재귀 함수는 함수를 명확히 정의하는 것이 좋습니다.
함수를 명확하게 정의하면, 나를 이용하여 나를 정의하는 것이 명확해집니다.

예를 들어 아래와 같은 함수는 m - cnt개를 선택하는 모든 경우의 수를 탐색하는 함수로 정의할 수 있습니다.
back 함수의 전체적인 틀은 아래와 같습니다.

1. m개를 모두 선택한 경우
    1-1. 선택한 원소들을 기반으로 결과를 계산
2. m개를 선택하지 않은 경우
    2-1. 원소를 하나 선택
    2-2. 남은 원소를 선택하는 역할을 back(cnt + 1, m) 호출에 위임 
    2-3. 즉, m - (cnt + 1)개를 선택하는 모든 경우의 수를 탐색하는 함수에게 남은 원소의 선택을 위임

함수 구현은 아래와 같습니다.

/*
    * @param m 선택해야 할 원소의 총 개수
    * m은 반드시 backtracking 함수의 인자로 전달될 필요는 없습니다, static 변수로 두어도 됩니다
    * @param cnt 현재까지 선택한 원소의 개수
    * cnt는 main 함수 호출 시 0또는 1로 시작할 수 있습니다. 
    * 다만, 주로 원소가 배열로 주어지기 때문에, 저는 배열의 인덱스와 맞추기 위해 0을 사용합니다.
*/

void back(int cnt, int m){
    if(cnt == m){
        // 1. 선택한 원소로 기반으로 결과를 계산하는 부분
    }else{
        // 2. 원소를 선택하는 부분
        for(int cur = XXX; cur < XXX ; cur++){
            // 원소를 선택
            back(cnt + 1, m); // cnt + 1부터 총 m개를 선택하는 함수를 호출
            // 원소의 선택을 해제
        }
    }
}

public static void main(String[] args) {
    back(0, 10); // (10 - 0)개를 선택하는 모든 경우의 수를 탐색
}

원소 선택

원소를 선택하는 부분은 두 가지 유형으로 구분될 수 있습니다.

depth가 기준이 되는 유형
원소가 기준이 되는 유형

depth가 기준이 되는 유형

depth란 단계라고 생각하시면 됩니다.
depth가 기준이 되는 유형은 현재 단계에서 원소를 선택하고, 다음 단계에게 나머지 역할을 위임시켜 주면 됩니다.
순열/중복 순열/조합이 이 유형에 해당됩니다.

순열

순열은 순서에 따라 결과가 달라질 수 있는 문제에 적용시킬 수 있습니다.

static boolean [] isSelected = new boolean[10];
static int [] selected = new int[10];

static void back(int depth, int m){
    if(depth == m){
        // 1. 선택한 원소로 기반으로 결과를 계산하는 부분
    }else{
        // 2. 원소를 선택하는 부분
        for(int curIdx = 0; curIdx < n; curIdx++){  // curIdx는 n개의 원소 중에서 선택할 원소의 idx
            if(!isSelected[curIdx]){ // curIdx번째 원소가 선택되지 않았다면
                isSelected[curIdx] = true; // curIdx번째 원소를 선택 처리
                selected[depth] = cur;  // depth 단계에서 선택한 값 저장
                back(idx + 1, maxNum); 
                isSelected[curIdx] = false;  // curIdx번째 원소를 선택 해제 처리
            }
        }
    }
}

중복 순열

중복 순열은 순열과 같지만, 같은 원소를 중복 선택 가능한 경우 문제에 적용시킬 수 있습니다.

static void back(int depth){
    if(depth == n){
        // 1. 선택한 원소로 기반으로 결과를 계산하는 부분
    }else{
        for(int cur = 0; cur < n; cur++){
            // 2. 원소를 선택하는 부분
            selected[depth] = cur;  // depth 단계에서 선택한 값 저장
            back(depth + 1, maxNum); 
        }
    }
}

조합

조합은 순서는 결과에 영향을 주지 않고, 어떤 원소를 선택했냐가 중요한 경우 문제에 적용시킬 수 있습니다.

static int [] selected = new int[10];
static void back(int depth, int pre){
    if(depth == m){
        // 1. 선택한 원소로 기반으로 결과를 계산하는 부분
    }else{
        for(int cur = pre + 1; cur < n; cur++){ // * cur의 시작점이 pre + 1
            // 2. 원소를 선택하는 부분
            selected[depth] = cur;  // depth 단계에서 선택한 값 저장
            back(depth + 1, cur); 
        }
    }
}

원소가 기준이 되는 유형

즉, 현재 원소를 몇개 선택할 것이냐입니다.
부분 집합, 중복 조합이 이 유형에 해당됩니다.

static int [] selectCnt = new int[10];
/*
    * @param maxNum idx 원소의 최대 선택 가능 개수
    * 부분집합의 경우 maxNum은 1이 됩니다.
*/
static void back(int idx, int maxNum, int n){
    if(idx == n){
        // 1. 선택한 원소로 기반으로 결과를 계산하는 부분
    }else{
        // 2. 원소를 선택하는 부분
        for(int num = 0; num < maxNum; num++){  // 해당 원소를 선택하지 않을 수 있기 때문에 0부터 시작
            selectCnt[idx] = num;   // idx 번째 원소를 num개 선택
            back(idx + 1, maxNum); 
        }
    }
}

public static void main(String[] args) {
    back(0, 10, 20); // 20개의 원소 중에서 0번째 원소부터 각각의 원소를 최대 10개 선택
}

결과 계산

결과 계산은 크게 두 가지 유형으로 구분할 수 있습니다.

1. 첫 번째 유형
    - 반드시 현재 경우의 수를 완성한 다음, 해당 경우의 수에 대한 결과를 계산해야하는 경우
    - ex. 캐슬 디펜스 

2. 두 번째 유형
    - 경우의 수를 완성해가면서, 결과를 계산하며 depth를 진행시킬 수 있는 경우
    - ex. 해밀턴 순환 회로, 배열 돌리기

먼저, 첫 번째 유형에 대해 설명하겠습니다.

캐슬 디펜스의 경우, 3명의 궁수를 모두 격자판에 배치시킨 후,
해당 배치에 대해 제거 가능한 적의 수를 계산해야합니다.

즉, 결과를 누적시키며 백트래킹을 진행할 수 없습니다.
이 경우 주어진 n개 중에서 m개를 모두 선택했을 때, 결과를 계산하면 됩니다.
이 유형의 경우 아래와 같은 코드 작성이 가능합니다.

static void backtracking(int depth, int m){
    if(depth == m){    
        // depth가 0부터 시작했다면, depth == m일 때 0 ~ m - 1까지 m개의 원소를 선택한 것이므로, 
        // 이 때 결과를 계산하면 됩니다.

        game(); // 선택한 원소를 기반으로, 결과를 계산
    }else{  // 아직 m개를 선택하지 않은 경우
        // 선택 가능한 원소들 중에서 하나를 선택
        backtracking(depth + 1, m);
    }
}

public static void main(String[] args) {
    back(0, 3);
}

두 번째 유형은 원소를 선택하면서 결과를 계산할 수 있기 때문에, 원소를 모두 선택한 다음 결과를 계산하지 않고, 원소를 하나씩 선택할 때마다, 현재까지의 결과를 계산하는 것입니다.
이 경우 계산 중복을 피할 수 있기 때문에 시간을 줄일 수 있습니다.

두번째 유형은 다시 두 가지 유형으로 구분할 수 있습니다.

m개를 반드시 선택해야 하는 경우
최대 m개를 선택할 수 있는 경우

m개를 반드시 선택해야 하는 경우

static int minDist = Integer.MAX_VALUE;

/*
    * @param preDist 시작 노드부터 이전 노드까지의 거리 
*/

static void backtracking(int depth, int m, int preDist){
    if(depth == m){    
        // depth가 0부터 시작했다면, depth == m일 때 0 ~ m - 1까지 m개의 원소를 선택한 것이므로, 
        // 이 때 결과를 계산하면 됩니다.

        minDist = Math.min(minDist, preDist); // * 핵심
    }else{  // 아직 m개를 선택하지 않은 경우
        // 선택 가능한 원소들 중에서 하나를 선택

        for(int cur = XXX; cur < XXX ; cur++){
            int curDist = 이전 노드와 현재 노드간의 거리
            backtracking(depth + 1, m, preDist + curDist);
        }
    }
}

public static void main(String[] args) {
    back(0, 3);
    System.out.println(minDist);    // 최종 출력 변수를 출력
}

최대 m개를 선택할 수 있는 경우

이 경우, 최대 m개를 선택할 수 있을 뿐, 반드시 m개를 선택해야 하는 것은 아닙니다.
따라서, 아래와 같이 함수 작성이 가능합니다.

static void backtracking(int depth, int m, int preDist){
    // 반드시 m개를 선택해야 하는 것은 아니므로, 원소를 선택할 때마다 최종 출력 변수의 값을 업데이트함
    minDist = Math.min(minDist, preDist); // ** 핵심

    if(depth < m){  // 아직 m개를 선택하지 않은 경우
        // 선택 가능한 원소들 중에서 하나를 선택

        for(int cur = XXX; cur < XXX ; cur++){
            int curDist = 이전 노드와 현재 노드간의 거리
            backtracking(depth + 1, m, preDist + curDist);
        }
    }
}

백트래킹 최적화

백트래킹에서 최적화는 일명 가지치기라고 할 수 있습니다.
대표적으로 최소 값을 구할 때, 이미 앞서 계산된 최소 값보다 현재 계산된 값이 더 클 때 더이상 진행하지 않는 방법이 있습니다.

static int minDist = Integer.MAX_VALUE;

static void backtracking(int depth, int m, int preDist){
    if(depth == m){    
        // depth가 0부터 시작했다면, depth == m일 때 0 ~ m - 1까지 m개의 원소를 선택한 것이므로, 
        // 이 때 결과를 계산하면 됩니다.

        minDist = Math.min(minDist, curDist);
    }else if(preDist < minDist){ // ** 핵심 
        // 아직 m개를 선택하지 않은 경우
        // 선택 가능한 원소들 중에서 하나를 선택

        for(int cur = XXX; cur < XXX ; cur++){
            int curDist = 이전 노드와 현재 노드간의 거리

            // ** 아래와 같은 방식도 가능
            if(preDist + curDist < minDist)
                backtracking(depth + 1, m, preDist + curDist);
        }
    }
}

풀이 과정

1. 모든 경우의 수에 대해 시도해보아야 결과를 알 수 있겠다라는 생각이 들면 일단 백트래킹을 후보로 둠
2. n의 크기를 살펴봄
    2-1. 백트래킹의 경우 보통 순서를 고려해야 한다면 11이하, 고려하지 않아도 된다면 25이하의 n이 주어짐
2-2. n이 그 이상이지만, 완탐이 아닌 이상 절대 알 수 없을 것 같다면, 가지치기를 고려
    2-3. n이 50 이상인 경우, 백트래킹일 가능성이 낮음 
2-4. 특히, n이 100,000이상인 경우, DP/그리디/이분탐색/그래프를 고려
3. 백트래킹을 할 수 있다면, 위의 백트래킹 유형 중 어떤 유형인지 파악
4. 유형 파악이 된 이후에는, 가지치기를 통해 최적화가 가능한지 파악
5. 솔루션 작성 이후에는, 어떠한 케이스가 있을 수 있는지, 정답이 잘 나오는지 파악하기 위해 간단한 테스트케이스부터 복잡한 테스트 케이스까지 직접 만들어보고 입력해서 솔루션을 검증

⚠ 주의할 점

최종 출력 변수의 값을 업데이트 할 수 있는 경우의 수가 존재하지 않는 경우,
Integer.MAX_VALUE 또는 Integer.MIN_VALUE와 같은 쓰레기 값이 출력될 수 있습니다.
따라서, 최종 출력 변수의 값을 업데이트 할 수 있는 경우의 수가 존재하는지, 이러한 경우, 출력해야 될 값을 문제에서 제시하였는지 등을 확인해야합니다.

22.10.11 SSAFY 스터디 CS 발표 - 컴퓨터 구조, 기억장치

길민호(ethan.mino) — Tue, 11 Oct 2022 14:44:08 +0900

기억장치

컴퓨터의 기억장치는 중앙처리장치 내부의 ~~레지스터~~, 중앙처리장치와 직접 버스로 연결되는 ~~주기억장치~~, 그리고 입출력 장치로 연결되는 ~~보조기억장치~~로 구성되어 있습니다.

컴퓨터의 ~~주기억장치(Main memory)~~은 주로 전원이 켜져 있을 때 실행하는 프로그램과 데이터를 저장하고, 보조기억장치(Auxiliary storage)는 영구적으로 프로그램과 데이터를 저장합니다.

~~주기억장치~~는 중앙처리장치와 ~~온라인~~으로 연결되고, ~~보조기억장치~~는 ~~오프라인~~으로 연결됩니다.

~~온라인 연결~~은 중앙처리장치가 필요할 때 항상 사용할 수 있다는 의미이고, ~~오프라인~~은 별도의 연결 과정을 거친 후 사용할 수 있다는 의미입니다.

~~레지스터~~는 주기억장치의 내용을 필요에 따라 임시로 중앙처리장치 안에 저장하는 용도로 사용됩니다.

주기억장치(Main memory)

주기억장치는 ~~ROM(Read Only Memory)~~과 ~~RAM(Random Access Memory)~~으로 구성됩니다.

~~ROM~~은 그 안에 저장된 데이터를 읽기만 가능하고, 지우거나 다른 값으로 갱신할 수 없는 ~~기억 소자~~입니다.

전원이 제거되더라도, ROM에 저장된 데이터를 그대로 유지됩니다.

전원이 인가될 때, 처음으로 실행하는 프로그램인 ~~부트로더~~를 저장하는 용도로 ROM을 사용합니다.

(~~부트로더~~는 시스템 스택을 설정, 서비스 루틴을 기억 장치에 적재, 인터럽트 벡터 설정 등의 역할을 수행합니다.)

반면, ~~RAM~~에 저장된 데이터를 읽고 쓰기가 가능하며, 전원이 제거되면 RAM의 내용이 모두 지워집니다.

컴퓨터는 보조 기억장치에 있는 프로그램을 RAM으로 복사한 후, RAM에서 실행합니다.

휘발성	비휘발성	삭제 가능	삭제 불가능
RAM	ROM, 보조기억장치	RAM, 보조기억장치	ROM

보조기억장치

~~보조기억장치~~는 프로그램과 데이터를 영구적으로 보관할 목적으로 사용되는 입출력 장치입니다.

중앙처리장치는 보조기억장치에 저장되어있는 데이터를 주기억장치로 옮겨놓고 사용합니다.

종류로는 ~~플로피 디스크~~, ~~하드 디스크~~, ~~SSD~~, ~~마그네틱 테이프~~, ~~CD-ROM~~ 등이 있습니다.

보조기억장치는 컴퓨터와 오프라인으로 연결되어 있으므로,

중앙처리장치가 필요할 때 즉시 보조기억장치의 데이터를 엑세스 할 수 없습니다.

컴퓨터는 입출력 장치를 연결하는 방식으로 보조기억장치를 엑세스하며, 한 번 연결하여 적은 양의 데이터를 송수신하는 것은 전체적인 성능이 낮아지는 요인이 됩니다.

따라서, 컴퓨터는 주기억장치에 많은 양의 데이터를 모아 두었다가 한 번에 보조기억장치로 전송하고, 보조기억장치에서 많은 양의 데이터를 읽어 주기억장치로 저장해두고 필요한 데이터를 가져옵니다.

(⚠️ 컴퓨터와 보조기억장치 간에 데이터를 전송하는 단위를 ~~블록(block)~~이라고 합니다.)

블록의 크기는 보조기억장치의 용량 증가와 함께 1K 바이트, 2K 바이트, 4K 바이트로 점점 증가하는 추세입니다.

엑세스 방법

엑세스 방법에는 ~~순차 엑세스~~, ~~직접 엑세스~~, ~~임의 엑세스~~, ~~연관 엑세스~~ 방법 등이 있습니다.

여기서는 순차/직접/임의 엑세스만 간단히 설명하고 넘어가겠습니다.

순차 엑세스(Sequential access) :
- 일렬로 저장된 데이터를 처음부터 차례대로 엑세스하는 방식
- 필요한 데이터가 저장된 위치에 따라 엑세스 시간이 달라짐. (ex. 자기 테이프)
직접 엑세스(Direct access) :
- 기억장치의 임의 위치로 디스크 헤드를 이동시켜 엑세스하는 방식
- 디스크 헤드가 이동하는 시간에따라 엑세스 시간이 달라짐
임의 엑세스(Random access)
- 주소에 의하여 데이터를 엑세스하는 방식
- 기억장치의 임의 위치를 엑세스하는 시간이 같음
- 각 기억장치의 위치마다 고유의 주소가 할당되어 있으며, ~~RAM~~도 임의 엑세스 방식을 사용

기억장치 계층

컴퓨터의 기억장치는 용량이 크고, 속도가 빠르고, 가격이 저렴할수록 좋습니다.

하지만, 이 세 가지 특징은 상반되는 특징을 갖고 있습니다.

(속도가 빨라지면, 가격이 ⬆️, 용량이 커지면, 가격이 ⬆️)

컴퓨터는 기억장치를 빠르게 엑세스 하면서도, 많은 용량을 사용하기 위해서 기억장치를 계층적으로 구성하여 운영하고 있습니다.

윗 계층일수록 중앙처리장치의 사용 빈도가 증가하고, 엑세스 시간이 짧고, 용량이 적고, 비트당 가격이 비쌉니다.

컴퓨터는 속도가 느리고, 용량이 큰 기억장치의 내용 중에서 중앙처리장치가 자주 사용하는 데이터를 속도가 빠른 기억장치로 옮겨 놓고 사용함으로써, 전체적인 기억장치 엑세스 속도를 개선하는 전략을 사용합니다.

기억장치 계층 구조 (출처 : 코딩 팩토리, https://coding-factory.tistory.com/354)

디스크 캐시

보조기억장치와 데이터를 주고 받기 위해서 ~~디스크 캐시~~를 사용하기도 합니다.

디스크 캐시는 주기억장치 혹은 보조기억장치에 존재할 수 있으며, 일반적으로 두 개의 장치 모두 디스크 캐시를 포함하고 있습니다.

아래는 응용 프로그램이 데이터를 디스크의 파일로 전송하는 과정입니다.

응용 프로그램은 디스크에 대한 파일 출력을 운영체제에게 요청
운영체제는 파일에 기록할 데이터를 주기억장치에 마련되어 있는 디스크 캐시로 저장하고, 응용 프로그램에게 데이터 전송이 완료되었음을 알림
운영체제는 한 개의 블록에 대한 데이터가 디스크 캐시에 모일 때까지 기다렸다가, 블록이 채워지면, 적절한 시간에 보조기억장치로 한 개의 블록을 전송, 이때 보조기억장치는 자신의 디스크 캐시에 데이터를 저장하고, 운영체제에게 디스크 기록이 완료되었다고 보고
디스크는 컴퓨터 시스템과 독립적으로 동작하는 입출력 장치이므로, 디스크 캐시의 데이터를 안전한 시간에 디스크로 기록

디스크 캐시의 운영은 전적으로 ~~운영체제~~가 관리합니다.

캐시기억장치

~~프로그램 내장형 컴퓨터~~는 프로그램과 데이터를 주기억장치에 저장해두고, 명령어를 하나씩 중앙처리장치로 인출하여 실행합니다.

이러한 구조는 ~~폰 노이만~~이 처음으로 제안하였으며,

주기억장치를 프로그램 기억장치와 데이터 기억장치로 분리하여, 명령어와 데이터를 동시에 엑세스하여, 기억장치 엑세스 속도를 개선한 ~~하버드 구조~~도 있습니다.

문제는 주기억장치의 엑세스 속도가 중앙처리장치보다 4 ~ 10배 느리다는 것입니다.

중앙처리장치는 주기억장치에서 명령어나 데이터를 인출하기 위해서 긴 시간 동안 대기해야합니다.

이러한 문제점을 해결하기 위해 ~~캐시 기억장치~~를 사용합니다.

중앙처리장치와 주기억장치 사이에 존재하는 ~~캐시 기억장치~~는 용량은 적지만, 엑세스 속도는 레지스터의 속도와 같거나 조금 느립니다.

중앙처리장치가 주기억장치를 엑세스하려고 기억장치 주소를 생성하면, ~~캐시 제어기~~는 해당 주소를 포함하는 여러 개 또는 수십 개의 데이터를 한 번에 캐시 기억장치로 옮겨 놓고, 그곳에서 데이터를 엑세스하도록 만듭니다.

참조의 지역성

프로세스는 프로그램을 수행할 때 기억장치의 특정 부분을 집중적으로 참조하는 경향이 있습니다.

이러한 특성을 ~~참조의 지역성~~이라고 하며, 이것이 캐시 도입으로 기억장치의 엑세스 속도를 개선할 수 있는 이유입니다.

참조의 지역성은 ~~공간적 참조의 지역성~~과 ~~시간적 참조의 지역성~~으로 구분됩니다.

공간적 참조의 지역성
- 인접한 영역의 명령어 또는 데이터가 다음 번에도 계속 참조될 가능성이 큰 것을 의미
- 아래의 경우 hit할 가능성이 높음
  - 현재 실행 중인 명령어의 다음 명령어를 수행
  - 루프를 실행
  - 함수 호출 (함수 안에서는 지역 변수를 많이 사용하는데, 지역 변수는 스택과 같은 일정한 영역에 집중적으로 배치됨)
시간적 참조의 지역성
- 한번 사용된 프로그램이 일정한 시간 내에 다시 참조될 가능성이 크다는 의미
- 프로그램 코드는 한 번 사용한 데이터를 여러 번 사용하는 경향이 있고, 함수에서 복귀하면, 원래 수행하던 코드 영역을 다시 수행할 가능성이 높음

따라서, 참조의 지역성을 고려할 때, 주기억장치에서 캐시 기억장치로 옮겨온 데이터를 중앙처리장치가 여러번 사용할 가능성이 큽니다.

~~퀵소트~~는 시간 복잡도 면에서 빠른 것도 있지만, 배열 안에서 자리 바꿈으로 처리가 되기 때문에 적중률이 높아서 속도가 빠른 이유도 있습니다.

또한, 해시 충돌 회피 방법으로, ~~Open Addressing~~ 방식에서 n칸 옆의 슬롯을 검사하는 ~~LInear probing~~의 경우 인접한 영역을 확인하기 때문에 적중률이 높습니다. 다만, 데이터가 밀집 저장되는 ~~클러스터링~~ 문제가 발생할 수 있습니다.

충돌 발생 시, 이동할 칸의 수를 새로운 해시 함수로 계산하는 ~~Double Hashing~~ 방식은 클러스터링을 효과적으로 회피할 수 있지만, 적중률이 매우 낮습니다.

캐시의 동작

컴퓨터 시스템은 아래와 같은 방식으로 캐시를 활용합니다.

중앙처리장치가 기억장치를 엑세스하려고 주소를 생성한다.
중앙처리 장치가 요청한 데이터가 캐시 안에 존재한다면, 중앙처리장치는 캐시 안에서 데이터를 가져온다.
만일 데이터가 캐시 안에 존재하지 않는다면, 주기억장치에서 중앙처리장치가 원하는 데이터를 포함한 데이터 블록을 캐시로 복사한 후, 캐시에서 해당 단어를 중앙처리장치로 전송한다.

중앙처리장치가 요청한 데이터가 캐시에 들어 있는 것을 ~~"적중하였다(hit)"~~라고 말하고, 존재하지 않는 것을 ~~"실패하였다(miss)"~~라고 말합니다.

또한, ~~적중률~~은 중앙처리장치의 기억장치에 대한 전체 요청 수에 대하여 적중한 수를 퍼센트로 표현한 척도로, 실제로 95 ~ 99%로 측정됩니다.

적중률에 의하여 캐시를 도입함으로써 기억장치 엑세스 속도가 얼마나 개선되었는지 계산할 수 있으며, 적중률은 응용 프로그램의 지역성에 의하여 결정됩니다. ~~데이터베이스~~ 같은 경우 캐시 적중률이 낮으며, ~~신호처리 프로그램~~의 경우 캐시 적중률이 높은 것으로 알려져 있습니다.

주기억장치와 캐시 간에는 여러 개의 단어로 구성된 블록 단위로 데이터를 전송하며, 일반적으로 주기억장치의 데이터 전송 단위를 ~~블록block)~~이라고 부르고, 캐시의 전송 단위를 ~~라인(line)~~ 또는 ~~슬롯(slot)~~이라고 부릅니다.

주기억장치의 블록 크기와 캐시의 라인 크기를 서로 다르게 설정할 수 있으나, 일반적으로 같게 설정합니다.

계층적 캐시

최근에는 마이크로프로세서 칩 내부에 캐시를 포함함으로써, 두 레벨의 캐시를 사용하기도 합니다.

(⚠️ 마이크로프로세서는 중앙처리장치의 기능을 하나의 칩 안에 내장한 소자, 작은 칩안에 중앙처리장치를 구현했다는 의미로 Micro 사용)

계층적 캐시 구성

칩 내부에 포함된 캐시를 ~~온 칩(on-chip) 캐시~~ 또는 ~~레벨1 캐시~~라고 부르고, 칩 외부의 캐시를 ~~오프 칩(off-chip) 캐시~~ 또는 ~~레벨 2 캐시~~라고 부릅니다.

레벨 2 캐시는 엑세스 속도 면에서 레벨 1 캐시보다 느리고, 주기억장치보다 빠르며, 용량 면에서는 레벨1 캐시보다 많습니다.

교체 정책

캐시 실패(miss)가 발생할 때, 주기억장치에서 새로 가져온 블록은 기존 캐시에 저장된 라인 중 하나와 교체되어야 합니다.

여러 개의 캐시 라인 중에서 어느 것을 선택하는 지 결정하는 방법을 ~~교체 정책~~이라고 합니다.

교체 정책을 선택할 때의 기준은 적중률을 높게 유지하는 것입니다.

또한, 캐시의 목적이 기억장치의 엑세스 속도를 빠르게 하기 위함이므로, 캐시 교체 정책은 하드웨어로 구현되어야 합니다.

가장 이상적인 교체 정책은 교체 대상인 캐시 라인 중에서 향후 가장 오랫동안 사용하지 않은 라인을 선택하는 것이지만,

가장 오랫동안 사용하지 않을지는 미래의 일이기 때문에 현실적으로 구현이 불가능합니다.

LRU(Least Recently Used)
- 현재부터 과거로 볼때, 가장 오래 전에 사용하였던 라인을 선택하여 교체
- 한동안 사용하지 않았기 때문에 앞으로도 사용할 가능성이 적다는 추정에 근거한 방법
- 우수한 적중률을 유지
- 캐시 라인마다 사용한 시기를 기록하는 ~~USE 카운터~~를 둔다.
- 캐시 라인을 엑세스할 때마다, 해당 라인의 USE 카운터를 0으로 만들고, 다른 라인의 USE 카운터를 증가
- 대상 라인 중에서 USE 카운터의 값이 가장 큰 라인을 선택
FIFO(First-In-First-Out)
- 캐시 안에 가장 오랫동안 존재했던 라인을 교체
- 가장 오래된 라인이더라도 자주 사용될 가능성이 있으므로, 적중률 면에서 높은 효율을 보이지 않는 것으로 알려짐
- 캐시 라인에 새 블록이 들어올 때, USE 카운터를 0으로 만들고, 다른 라인의 USE 카운터를 증가
- 교체할 때, 대상 라인 중에서 USE 카운터 값이 가장 큰 라인을 선택
LFU (Least Frequency Used)
- 사용 횟수가 가장 적은 라인을 교체
- 최근 캐시에 들어온 라인이 교체 대상으로 선택될 가능성이 있다는 단점이 있음
- 새로운 블록이 캐시에 들어올 때마다 USE 카운터를 0으로 만들고, 사용될 때마다 USE 카운터를 증가시킴으로써 구현
Random
- 임의로 교체할 라인을 선택
- 제법 효율이 좋음

쓰기 정책

기억장치에 대한 쓰기는 궁극적으로 주기억장치에 데이터가 기록되어야 합니다.

쓰기 정책은 캐시와 주기억장치에 대한 쓰기 동작을 처리하는 방법을 규정하며, ~~write-through~~, ~~write-back~~ 정책이 있습니다.

Write-through
- 쓰기 정책이 수행될 때마다 캐시 라인의 해당 단어와 주기억장치의 단어를 모두 수정하는 방법
- 주기억장치는 항상 유효한 데이터를 보관하게 됨
- 항상 캐시와 주기억장치의 내용을 같게 유지할 수 있으며, 캐시 라인을 교체할 때 주기억장치의 블록을 선택된 캐시 라인으로 복사하면 된다는 장점이 있다.
- 하지만, 주기억장치를 엑세스하는 횟수가 증가하여 전체적인 개선 속도가 느려지는 단점이 있다.
Write-back
- 쓰기 동작이 수행될 때, 일단 캐시 라인의 단어만을 수정하고, 주기억장치의 단어를 수정하지 않음
- 대신 캐시 라인이 변경될 때마다, 해당 라인이 수정되었다고 표시
- 이 정보를 ~~dirty 비트~~라고 한다.
- 나중에 dirty 비트가 세트되어 있는 캐시 라인을 교체할 때, 해당 라인 전체를 주기억장치 블록으로 복사한 다음, 새로운 블록을 가져온다.
- Write-through 정책보다는 기억장치 엑세스 속도가 빠르다는 것이 장점이지만, 주기억장치와 캐시의 내용이 일치하지 않는 순간이 존재한다는 것이 주요 단점이다.

프로세스, 프로세서, 코어

~~프로세스(Process)~~는 실행중인 프로그램을 의미하며, ~~프로세서(Processor)~~는 현재는 CPU와 혼용되어 사용되고 있습니다.

코어(Core)는 프로세서의 주요 구성 요소입니다.

프로그램의 명령을 읽고 수행하는 독립적인 처리 장치로, 프로세서가 하는 일을 분담하여 처리합니다.

코어는 메모리에서 명령을 가져오거나 실행하며, 하나의 프로세서는 여러 개의 코어를 가질 수 있습니다.

프로세서	Core
컴퓨터 내의 전자 회로	프로세서 내의 전자 회로
컴퓨터에 여러 개의 프로세서가 있을 수 있다.	프로세서에 여러 개의 코어(Core)가 있을 수 있다

일관성 유지

중앙처리장치 이외에 입출력장치도 ~~DMA 방식~~으로 기억장치에 엑세스할 수 있으며,

한 개의 컴퓨터에 여러 개의 프로세스를 탑재한 ~~멀티 프로세서~~ 시스템인 경우, 프로세서마다 독립적으로 기억장치에 엑세스 합니다.

이런 환경에서 캐시 장치를 운영할 때, 다음과 같은 문제점이 발생할 수 있습니다.

멀티프로세스 시스템 환경

주기억장치의 한 개의 블록이 여러 개의 캐시에 복사될 수 있다. 만일 프로세서 중 하나가 데이터를 자신의 캐시에 기록하면 같은 블록을 복사해 갖고 있는 프로세서의 캐시 라인은 틀린 값을 갖게 된다.
만일 입출력 장치가 주기억장치에 데이터를 직접 기록하는 경우, 해당 데이터가 포함된 블록을 복사하고 있는 캐시 라인은 틀린 값을 갖게 된다.

캐시와 주기억장치의 내용이 일치하지 않는 상태를 ~~무효 상태(Invalid state)~~라고 하고, 캐시와 주기억장치의 내용이 같도록 유지하는 문제를 ~~일관성 유지(coherence)~~라고 합니다.

캐시 불가능 영역 지정
- 여러 개의 프로세서들이 동시에 사용하는 주기억장치의 데이터 영역을 캐시로 들어가지 않도록 지정
버스 감시 :
- 각 프로세서의 캐시 제어기는 시스템 버스에서 데이터 쓰기가 발생하는 것을 감시.
- 만일 자신의 캐시가 새로 갱신되는 기억장치 블록을 저장하고 있다면, 해당 라인을 무효화
- ~~Write-through~~ 정책을 채택하는 경우, 이 방법을 주로 사용
동시 갱신
- 주기억장치의 데이터를 수정할 때 , 모든 캐시의 내용을 모두 수정

질문

데이터 베이스의 캐시 적중률이 낮은 이유는?

출처

한 눈에 보이는 컴퓨터 구조, 9장 기억장치(생능출판사, 전중남)
프로세서(Processor), 코어(Core), 쓰레드(Thread)
CPU, 프로세서, 코어는 어떤 연관성과 차이점이 있을까?