** 1.1. 의도 **

• 캡슐화(외부에서 맴버 변수의 값을 변경할 수 없도록 함)를 위배하지 않으면서 객체 내부의 상태를 캡슐화 해서 저장하고, 나중에 객체가 해당 상태로 복구 가능하도록 한다.

** 1.2. 예제 **

• Memento 구조체를 생성하여 필수 정보 저장
• 이후 Save()와 Restore()를 통해서 저장 복구 가능

  #pragma once
  #include <map>
  >
  enum color { red = 1, green = 2, blue = 3};
  >
  class Graphic
  {
    struct Memento
    {
        int penWidth;
        int penColor;
        Memento(int w, int c) : penWidth(w), penColor(c) {}
    };
    std::map<int, Memento*> memento_map; 
  >
    int penWidth = 1;
    int penColor = 0;
    int temporary_data;
  public:
  >
    int save()
    {
        static int key = 0;
        ++key;
  >
        Memento* p = new Memento(penWidth, penColor);
        memento_map[key] = p;
  >
        return key;
    }
    >
    void restore(int token)
    {
        penColor = memento_map[token]->penColor;
        penWidth = memento_map[token]->penWidth;
    }
  >
    void draw_line(int x1, int y1, int x2, int y2)
    {
    }
    void set_stroke_color(int c) { penColor = c; }
    void set_stroke_width(int w) { penWidth = w; }
  };

뭔가를 그리는 상황에서 모든 변경값을 함수 인자로 받아와서 진행도 가능하지만, 객체에 저장된 기본정보를 수정하게 하고, 함수에서는 객체의 기본정보를 활용할 수도 있음

2. State Pattern

사실상 Strategy Pattern과 동일하지만, 알고리즘을 교체할 때는 Strategy, 상태는 동작을 변경하는 경우 State로 명명 한다.

3. Builder Pattern

Strategy Pattern과 동일하지만, 객체를 생성하는 관점에서는 Builder는 객체를 변경하는 경우에 적용하는 개념이라고 생각하면 된다.

** 1.1 의도 **

• 클래스의 인스턴스는 오직 하나임을 보장하며 어디에서나 동일한 방법으로 접근 하는 방법을 제공.
• 단점과 비판
  • 전역변수와 유사하다.
  • 멀티스레드간의 접근 문제
  • 객체간의 결합도가 증가하고 재사용성이 감소한다.
• 그럼에도 많은 오픈소스에서 애용하는 패턴이다.

** 1.2. 규칙 **

• 외부에서는 객체를 생성할 수 없어야 한다. >> private 생성자를 활용
• 한 개의 객체는 만들수 있어야 한다. >> 오직 한개의 객체를 만들어서 반환하는 static 맴버 함수를 사용
• 복사 생성자도 사용할 수 없어야 한다 >> 복사/대입을 금지 (= delete)

1.3. Meyer's singleton

• 오직 한개의 객체를 static 지역변수로 생성
• 지연된 초기화 : get_instance()를 호출할 때 초기화 된다. 사용하지 않으면 생성자가 호출되지 않고, 메모리를 사용하지 않는다.
• thread-safe : static 지역 변수이기 때문에 가능

  class Cursor
  {
  private:
    Cursor() 
    {
        std::cout << "start  Cursor()" << std::endl;
        std::this_thread::sleep_for(3s); // 3초가 걸린다고 하더라도 늦게 도착한 애들은 앞의 생성자가 생성될 때까지 대기한다. 
        std::cout << "finish Cursor()" << std::endl;        
    }
    Cursor(const Cursor& ) = delete;
    Cursor& operator=(const Cursor&) = delete;
  >
  public:
    static Cursor& get_instance()
    {
        std::cout << "start  get_instance" << std::endl;
        static Cursor instance;
        std::cout << "finish get_instance" << std::endl;
        return instance;
    }
  };

** 1.4. Heap 영역에 singleton을 생성하는 방법 **

• 멀티스레드 접근에 안전하기 위해서 동기화가 필요 >> lock_guard를 통해서 동기화가 가능하다.
  • 직접적으로 lock을 걸어주는 코드는 좋은 코드가 아닌다 ( mutex를 통해서 lock을 해주는 경우 lock이 걸린 상태로 예외가 발생하면, lock 을 해제하지 못하는 경우 발생)
  • lock_guard를 사용하는 경우 생성자에서 자동으로 lock을 해줌
  • 만약 예외가 발생하더라도 cpp에서는 예외 발생시 지역변수는 안전하게 파괴되며, lock_guard 소멸자에서 lock을 안전하게 해제할 수 있음
  • {}을 통해서 lock을 빨리 해제하는 방법도 존재(지역을 벗어나면 소멸자가 불림)

    class Cursor
    {
    private:
    Cursor() {}
    Cursor(const Cursor& ) = delete;
    Cursor& operator=(const Cursor&) = delete;
    >
    static std::mutex m;
    static Cursor* instance;
    public:
    static Cursor& get_instance()
    {        
      std::lock_guard<std::mutex> g(m); // g의 생성자에서 m.lock()
    >
      // m.lock();
      if ( instance == nullptr )
          instance = new Cursor;
      // m.unlock();
      >
      return *instance;
    }
    };
    Cursor* Cursor::instance = nullptr;
    std::mutex Cursor::m;

** 1.5. Double Check Locking Pattern (DCLP)**

• 위의 코드와 같이 진행하는 경우 이미 Singleton객체가 생성된 후 불러오기만 할때도 불필요하게 lock을 걸고 해제하는 과정이 존재
• 이를 해결하기 위해 DCLP를 아래와 같이 사용 가능

  static Cursor& get_instance()
    {
        if ( instance == nullptr )
        {
            m.lock();
  >
            if ( instance == nullptr )
            {
                instance = new Cursor;
  >
            //    instance = Cursor 크기 메모리할당;
            //    Cursor::Cursor();
            }
  >
            m.unlock();
        }

• 위와 같이 진행하면 이미 singleton 객체가 존재하는 경우 lock 없이 진행가능하나, CPP에서는 해당 방식은 오류로 정의됨.
• 컴파일러가 최적화하면서 위의 주석과 같은 일이 발생하여 아직 초기화가 끝나지 않았는데도 instance는 메모리 주소가 할당되어 있음
• 따라서 Cursor::Cursor()가 오래걸리는 경우 아직 초기화가 끝나지 않았는데 다시 접근을 한다면 intance는 nullptr이 아니기에 초기화되지 않은 intance 주소를 전달함.
• Double-Checked Locking is Fixed in C++11에서 해결되었음

*1.6. Singleton 코드를 재사용하는 방법 *

• 매크로를 활용하는 방법

  #define MAKE_SINGLETON(classname)            \
  private:                                    \
    classname() {}                            \
    classname(classname&) = delete;            \
    void operator=(classname&) = delete;    \
  public:                                        \
    static classname& getInstance()            \
    {                                        \
        static classname instance;            \
        return instance;                    \
    }                                        \
  private:// 요게 있어주는게 좋음. 디폴트가 private으로 끝나게 지정해 주는 구조 
  #include "singleton.h"
  >
  class Cursor
  {
    MAKE_SINGLETON(Cursor)
  };

• 상속을 활용하는 방법
• CRTP(Curiously Recurring Template Pattern) : 기반 클래스에서 미래에 만들어질 파생 클래스의 이름을 사용할 수 있게 하는 기술
• 상속 받아서 사용할 수 있도록 생성자는 private이 아닌 protected에 위치
• intance와 mutex 객체를 만들때도 template|< typename T>로 선언해 주어야함

  template<typename T> //CRTP라는 방법 
  class Singleton
  {
  protected:
    Singleton() {} // 싱속 받아서 사용할 수 있도록 변경해 주었음 
  private:    
    Singleton(const Singleton& ) = delete;
    Singleton& operator=(const Singleton&) = delete;
    >
    static std::mutex m;
    static T* instance;
  public:
    static T& get_instance()
    {        
        std::lock_guard<std::mutex> g(m);
        if ( instance == nullptr )
            instance = new T; // 전달받은 Type의 객체가 생성됨
        return *instance;
    }
  };
  template<typename T> T* Singleton<T>::instance = nullptr; //T는 위의 클래스 내에서만 토용되므로 다음과같이 적어주어야 함 
  template<typename T> std::mutex Singleton<T>::m;
  >
  class Mouse : public Singleton< Mouse > // 상속을 통해서 싱글톤 코드를 재사용하는 방법도 가능
  {};

2. flyweight pattern

*2.1. 의도 *

• 속성이 동일한 객체를 공유하게 한다.
• Word에서 폰트 값은 동일하지만 값만 다른 수많은 객체들이 존재함
• 이때 일일이 동일한 속성의 font를 따로 저장하게 되면 메모리 소모가 크기 때문에, flyweight 패턴을 적용하여 동일한 속성 값은 한개만 생성하여 공유한다.

*2.2. 예제 *

• 생성자는 private에 두고, 자신을 생성하는 함수를 factory에서 생성 ( friend class 로 지정하여 private에 접근 가능함 / cpp에서만 friend지원)
• factory는 그동안 생성한 객체의 속성을 기억하는 map을 생성하고 중복하지 않는 경우에만 새로 생성.

  class Image
  {
    std::string image_url;
  >
    Image(const std::string& url) : image_url(url)
    {
        std::cout << url << " Downloading...\n";
    }
  public:
    void draw() 
    { 
        std::cout << "draw " << image_url << '\n';
    }
    friend class ImageFactory; // 친구는 private에 접근할 수 있음
    //cpp에는 가능하지만 다른곳에서는 안되는 코드임. 
  };
  >
  class ImageFactory
  {
    std::map<std::string, Image*> image_map;
  public:
    Image* create(const std::string& url)
    {
        Image* img;
        auto ret = image_map.find(url);
        >
        if (ret == image_map.end())
        {
            img = new Image(url);
            image_map[url] = img;
        }
        return image_map[url];
    }
  };

** 2.3 핵심정리 **

• Singleton pattern은 class에 대하여 단 한개의 객체를 생성하지만, flyweight은 class의 맴버 변수의 값이 다르다면 여러번 생성할 수 있다.
• 결국 하나의 객체 안에 동일한 값들을 중복적으로 저장하는 것을 막는 pattern 이다.

3. Factory Pattern

*3.1. 기원 *

• 정통적인 Design Pattern에 factory는 없다. Abstract Facotry만 존재하지만, Abstract Factory를 이해하기 위해서 factory를 먼저 이해하는 것이 유리.

** 3.2. 예제 **

• 새로운 도형이 추가되더라도, Client의 코드는 변경이 없는 구조로 구현함.
• Factory를 통해서 객체를 생성
  • 동일한 곳에서 객체를 생성 하기에 한곳에서만 관리하여 추가되더라도 factory의 수정만으로 변경 가능(큰 시스템에서는 main이 아닌 다른 곳에서 객체를 생성할 수도 있음)
  • static 맴버 함수를 통한 객체 생성 : cpp에서는 클래스의 이름을 자료형에 보관이 불가능하지만, 클래스를 생성하는 생성함수는 자료구조에 보관 할 수 있음.

    class Shape // 업케스팅으로 동일한 방식으로 create을 할수 있게 해줌
    {
    public:
    virtual void draw() = 0;
    virtual ~Shape() {}
    };
    >
    class ShapeFactory // 모양을 찍어내는 공장
    {
    MAKE_SINGLETON(ShapeFactory) // 싱글턴 구조를 활용하여 단 한개만 생성할수 있게 보장
    >
    using F = Shape*(*)(); // Shpae 내의 어떤 함수를 포인터로 받아오겠다. 
    >
    std::map<int, F> create_map; 
    >
    public:
    >
    void register_shape(int key, F create_function) // 
    {
        create_map[key] = create_function;
    }
    >
    Shape* create(int type)
    {
        Shape* p = nullptr;
    >
        if (create_map[type] != nullptr)
        {
            p = create_map[type](); // map에 등록해뒀던 입력받은 타입 객체를 생성하는 함수가 호출됨
        }
        return p;
    }
    };
    >
    class RegisterFactory // 등록해주는 factory
    {    
    public:
    RegisterFactory(int type, Shape* (*f)())
    {
    >        ShapeFactory::get_instance().register_shape(type, f);
    }
    };
    >
    >
    #define REGISTER(classname)                        \
    static Shape* create() { return new classname; }    \
    static RegisterFactory rf; // static으로 불러 동일한 RegisterFactory에 항상 접근 하겠다
    >
    #define REGISTER_IMPL(type, classname)            \
    RegisterFactory classname::rf(type, &classname::create);
    >
    class Rect : public Shape
    {
    public:
    void draw() override { std::cout << "draw Rect" << std::endl; }
    >
    REGISTER(Rect)
    };
    REGISTER_IMPL(1, Rect)
    >
    int main()
    {
    std::vector<Shape*> v;
    >
    ShapeFactory& factory = ShapeFactory::get_instance();
    >
    while (1)
    {
        int cmd;
        std::cin >> cmd;
    >
        if (cmd > 0 && cmd < 8)
        {
            Shape* s = factory.create(cmd);
    >
            if ( s )
                v.push_back(s);
        }
        else if (cmd == 9)
        {
            for (auto s : v)
                s->draw();
        }
    }
    }

• 각 도형은 동일한 Registor Factory에 자신을 생성하는 함수를 등록
• Registor Factory는 Shape Factory를 초기화하고, 해당 Factory의 Map(key = 입력받을 값 / value = 생성 함수)에 값을 저장 (이때 Factory는 처음 초기화되며 Singleton구조를 가지고 있음)
• factory의 create 함수에서 각각의 도형들이 Pointer로 생성되어 Return.

4. Prototype Pattern

** 3.1. 의도 **

• 견본적(porotypical) 인스턴스를 사용하여 생성할 객체의 종류를 명시하고, 견본을 복사하여 새로운 객체를 생성
• 같은 클래스더라도 Blue circle, Red Circle과 같이 특정 속성이 다르다면 미리 해당 객체를 생성해두고 복사하여 사용 가능

** 3.2. 예제 **

• Factory는 생성 함수를 등록했다면, Prototype은 객체를 등록
• Map 또한 실제 객체를 저장.

  class ShapeFactory
  {
    MAKE_SINGLETON(ShapeFactory)
  >
    std::map<int, Shape*> prototype_map; 
  public:
    void register_sample(int key, Shape* sample)
    {
        prototype_map[key] = sample;
    }
  >
    Shape* create(int type)
    {
        Shape* p = nullptr;
  >
        if (prototype_map[type] != nullptr)
        {
            p = prototype_map[type]->clone(); // 복사해서 사용
        }
        return p;
    }
  };
  int main()
  {
    std::vector<Shape*> v;
    ShapeFactory& factory = ShapeFactory::get_instance();
  >
    Rect* red_rect = new Rect; 
    Rect* blue_rect = new Rect; 
    Circle* blue_circle = new Circle;
  >
    // 자주 사용하는 객체를 등록
    factory.register_sample( 1, red_rect);
    factory.register_sample( 2, blue_rect);
    factory.register_sample( 3, blue_circle);
  >
    while (1)
    {
        int cmd;
        std::cin >> cmd;
  >
        if (cmd > 0 && cmd < 8)
        {
            Shape* s = factory.create(cmd);
            if ( s )
                v.push_back(s);
        }
        else if (cmd == 9)
        {
            for (auto s : v)
                s->draw();
        }
    }
  }
  

5. Abstract factory

** 5.1. 의도 **

• 상세화된 서브 클래스를 정의하지 않고 서로 관련성이 있거나 독립적인 여러 객체군을 생성하기 위한 인터페이스를 제공
• 결국 Factory의 Interface를 둬서 어떤 제품이 생성되든지 동일한 코드로 생성하게 하자!

** 5.2. 예제 **

• 게임 엔진은 다양한 플랫폼(PC, 모바일, 콘솔 등)을 지원해야 하며, 각 플랫폼에 맞는 그래픽 렌더러, 오디오 시스템, 입력 장치 터페이스를 제공해야함
• 추상 팩토리 패턴을 통해 플랫폼별로 서로 다른 시스템을 생성하지만, 클라이언트(게임 로직)에서는 이 모든 것을 동일한 인터페이스를 통해 접근할 수 있음 ex( GraphicsFactory는 플랫폼에 맞는 그래픽 시스템(DirectXRenderer, OpenGLRenderer, VulkanRenderer)을 생성)

  class RichControlFactory : public IControlFactory
  {
  public:
    IButton* create_button() { return new RichButton; }
    IEdit*   create_edit() { return new RichEdit; }    
  };
  >
  class SimpleControlFactory : public IControlFactory
  {
  public:
    IButton* create_button() { return new SimpleButton; }
    IEdit*   create_edit() { return new SimpleEdit; }
  };
  >
  int main(int argc, char** argv)
  {
    IControlFactory* factory;
  >
    if (strcmp(argv[1], "-style:rich") == 0)
        factory = new RichControlFactory;
    else
        factory = new SimpleControlFactory;
  >
    IButton* btn = factory->create_button();
    >
    btn->draw();
  }

** 동일한 기능을 가진 서로 다른 제품군이 있을때 유용. **

** 1.1. 의도 **

• 객체 사이의 1:N의 종속성을 정의 하고 한 객체의 상태가 변하면 종속된 다른 객체들의 통보가 가고 자동으로 수정이 일어나게 한다.
• 정보를 보관하는 클래스에서 정보를 필요로 하는 클래스들을 기억하고, 변화가 발생하면 모두에거 notify해준다.
• Subject에서 기본적인 attach, detach, notify를 구현하고, 이를 상속받는 클래스에서 필요한 데이터 타입만을 관리.

2. Iterator

** 2.1. 의도 **

• 컨테이너의 내부 구조를 노출하지 않고도, 동일한 방법으로 모든 요소에 순차적으로 접근할 수 있게 하자.

** 2.2. 인터페이스 기반의 설계 **

• 모든 Iterator의 사용법이 동일하기 위해서 Iterator의 인터페이스가 필요
• 반복 가능한 컨테이너 Enumerable은 Iterator를 꺼낼 수 있어야 한다.

  template<typename T> struct IEnumerator
  {
    virtual T& getObject() = 0;
    virtual bool moveNext() = 0;
    virtual ~IEnumerator() {}
  };
  >
  template<typename T> struct IEnumerable  
  {
    virtual IEnumerator<T>* getEnumerator() = 0;
    virtual ~IEnumerable() {}
  };

• 단점
  • getEnumerator()는 new로 할당하기 때문에 반드시 사용자가 delete 해주어야 하는데, 라이브러리가 할당하고 사람이 delete하는 구조는 좋은 디자인이 아님
  • moveNext(), getObject()등은 가상함수이기 때문에 자주 호출되면 성능 저하를 야기함
  • 모든 컨테이너가 동일한 방식으로 동작하지 않음.(연속된 배열을 가지는 container의 경우 ++을 이용해서 순차 접근)

** 2.3. STL Style의 Iterator **

• 인터페이스를 사용하지 않고, 인라인 치환 진행
• 연산자 재정의를 통해 ++, *을 통해서 moveNext(), getObject()등을 대체
• new 대신 임시객체를 전달하기 때문에 메모리 관리도 수월

  template<typename T> class slist 
  {
    Node<T>* head = nullptr;
  public:
    void push_front(const T& a) { head = new Node<T>(a, head); }
  >
    inline slist_iterator<T> begin()
    {
        return slist_iterator<T>(head); // 임시 객체
    }
    inline  slist_iterator<T> end()
    {
        return slist_iterator<T>(nullptr);
    }
  };

3. Visitor

** 3.1. 의도 **

• 객체 구조에 속한 요소에 수행될 오퍼레이션을 정의 하는 객체.
• Visitor pattern은 처리되어야 하는 요소에 대한 클래스를 변경하지 않고 새로운 오퍼레이션을 정의할 수 있게 한다.

** 3.2. 예제 **

• visitElement() 함수는 방문하고자하는 객체 별로 수행해야할 역할을 정의
• accept()는 Leaf 노드에서는 전달받은 visitor객체의 visitElement()만을 수행, internal 노드에서는 자신의 childern의 accept()를 호출하도록 구현해야한다.

  struct IMenuVisitor
  {
    virtual void visit(MenuItem* mi) = 0;
    virtual void visit(PopupMenu* pm) = 0;
    virtual ~IMenuVisitor() {}
  };
  >
  struct IAcceptor
  {
    virtual void accept(IMenuVisitor* visitor) = 0;
    virtual ~IAcceptor() {}
  };
  >
  class MenuItem : public BaseMenu // leaf node
  {
    int id;
  public:
    MenuItem(const std::string& title, int id) : BaseMenu(title), id(id) {}
  >
    void accept(IMenuVisitor* visitor)
    {
        visitor->visit(this);
    }
  >
    void command() override {};
  };
  >
  class PopupMenu : public BaseMenu // internal node
  {
    std::vector<BaseMenu*> v;
  public:
  >
    PopupMenu(const std::string& title) : BaseMenu(title) {}
    >
    void accept(IMenuVisitor* visitor)
    {
        visitor->visit(this);
  >
        for ( auto child : v)
            //visitor->visit(child);
            child->accept(visitor); // 
    }
  >
    void add_menu(BaseMenu* p) { v.push_back(p); }
  >
    void command() override{}
  };
  >
  //Visitor
  class PopupMenuTitleChangeVisitor : public IMenuVisitor
  {
  public:
    void visit(MenuItem* mi) {}  // 메뉴아이템 방문시 할일은 없다.
  >
    void visit(PopupMenu* pm) 
    {
        std::string s = "[ " + pm->get_title() + " ]";
        pm->set_title(s);
    }
  };

** 3.3. Visitor의 의미 **

• 객체지향의 디자이니 특징 : 새로운 객체 타입을 추가하는 것은 쉬우나 가상함수를 추가하는 것은 어렵다(모든 객체 타입의 수정이 필요).
• 반대로 Visitor를 사용하면 새로운 객체 타입을 추가하는 것은 어려워지지만, 새로운 오퍼레이션(visitor 작성)을 추가하는 것은 쉽다.
  • 새로운 객체 타입을 추가하면 visitor 인터페이스가 변경됨
  • 각 Visitor 마다 전달되는 객체 타입에 맞는 동작을 구현 필요
  • 결과적으로 기존의 모든 Visitor를 수정해야하는 문제점이 발생.
    
• 객체지향의 특징을 반대로 변경해주는 효과를 가진다.

** 1.1. 의도 **

• 인터페이스를 클라이언트가 기대하는 형태의 인터페이스로 변환

** 1.2. 구현 방법 **

• Class Adapter를 활용한 구현
  • 다중 상속을 활용하여 CoolText의 show()함수를 draw()함수로 탈바꿈
  • Object Adapter를 사용하는 경우에 비하여 가상함수를 통해 재정의 할 가능성이 남아 있음.

    class ClsAdapter : public CoolText, public Shape 
    {
    public:
    ClsAdapter(const std::string& text) 
          : CoolText(text) {}
    void draw() override { CoolText::show();}
    };    

• Object Adapter를 활용한 구현
  • 이미 생성되어 있는 객체를 포인터 혹은 Reference 타입으로 불러와서 해당 객체의 함수를 호출

    class ObjAdapter : public Shape  // 객체 어댑터
    {
    CoolText* ct; // 객체를 받아올 떄는 보통 이런 형식을 많이 사용한다.
    public:
    ObjAdapter(CoolText* ct) : ct(ct) {}
    void draw() override { ct->show();}
    };    

** 1.3. STL 에서의 활용 **

• stack을 구현하고자 할때 이미 다른 클래스에서 잘 만들어진 메모리 관리, 혹은 기본 기능들을 굳이 재정의하여 코드 메모리를 늘리고 싶지 않음

• object adapter를 활용하여 stack을 만들고, policy based design을 통해 사용자에게 선택권을 제공

  template<typename T, typename C = std::deque<T> > 
  class stack 
  {
    C c;
  //    C* c; // object adapter
  public:
    constexpr void push(const T& a) { c.push_back(a); }
    constexpr void pop()            { c.pop_back();     }
    constexpr T&   top()            { return c.back(); }
  };
  #include <stack>
  int main()
  {
    stack<int, std::vector<int>> s1; // cash 사용에 따라 유리할 수 있음
    stack<int, std::list<int>> s2;
    stack<int> s;
    s.push(10); // 인라인화가 이루어진다면 s.c.push_back(a) 가 되어 마치 stack은 없는 것처럼 작동하게 된다.
    s.push(20); // 기계어 코드에는 stack과 관련된 코드들은 없는 것 처럼 받아들여진다.
  }

*1.4. private을 이용한 상속 *

• 구현은 물려받았지만 인터페이스는 물려받지 않았다

• 상속을 모두 private 영역 안에 받게 하여, 외부에 노출하고 싶지 않은 부모 클래스의 기능을 숨길 수 있음. (java에서의 stack이 vector로부터 일반 상속을 받아 구현되어 push_front와 같은 함수가 ide에 잡히는 문제 발생)

2. Proxy

** 2.1. 의도 **

• 다른 객체에 접근하기 위한 중간 대리 역할을 하는 객체를 생성, 대리 역할하는 객체에서 다양한 문제를 해결(인증, 보안, 원격지 서버 대행)

** 2.2 예제 **

• Image 객체를 호출하면 Image가 로드됨.

• 하지만 주로 하고 싶은 작업은 이미지의 크기를 불러오는 것 >> 불필요하게 메모리가 소모됨.
• ImageProxy 클래스를 생성하여 문제 해결(헤더파일만을 읽는 방식으로 진행)
• 이미지를 그려야 할때 Image 객체를 생성해서 그림을 그림 ( 지연된 생성 )

  class Image : public IImage
  {
    std::string name;
  public:
    Image(const std::string& name) : name(name)
    {
        std::cout << "open " << name << '\n';
    }
    void draw() { std::cout << "draw " << name << '\n'; }
  >
    int width()  const { return 100;}
    int height() const { return 100;}
  };
  >
  class ImageProxy : public IImage
  {
    std::string name;
    Image* img = nullptr;
  public:
    ImageProxy(const std::string& name) : name(name) {}
  >
    int width()  const { return 100;} // 파일헤더에서 정보 획득
    int height() const { return 100;} // 파일헤더에서 정보 획득
    void draw() 
    {
        if ( img == nullptr )
            img = new Image(name); // 꼭 그림을 그려 주어야 할때는 img 객체를 생성해서 진행
            // 지연된 생성이라 부름 
        img->draw();
    }
  };

** 2.3. 차별점 **

• 브릿지와 유사하지만, 브릿지는 상호간의 업데이트를 위한 패턴
• 데코레이터와 유사하게 기능을 추가하는 것 같지만, 데코레이터는 중첩의 형태로 진행되며, 인터페이스가 동일함 / 반면에 프록시는 중첩이 안되며 지연된 생성을 활용한다는 점이 다름

3. Facade Pattern

** 3.1. 의도 **

• 서브 시스템을 합성하는 다수의 객체들의 인터페이스 집합에 대해 일관된 하나의 인터페이스를 제공할 수 있도록 한다.
• 서브 시스템을 사용하기 쉽게 하기 위한 포괄적인 개념의 인터페이스를 정의

** 3.2. 예제 **

• 내부적인 코드를 모두 감싸 TCP server에 대해서 몰라도 쉽고 간편하게 사용할 수 있도록 Facade를 생성

  class TCPServer // 반복되는것, 내부동작을 알 필요가 없는 동작은 다음과 같이 싸주는 것이 좋다.
  {
    NetworkInit init;
    Socket sock{SOCK_STREAM};
  public:
    void Start(const char* ip, short port)
    {
        IPAddress addr(ip, port);
        sock.Bind(&addr);
        sock.Listen();
        sock.Accept();
    }
  };
  >
  int main()
  {
    TCPServer server; // 파사드. 이련의 절차에 대한 포괄적인 개념의 인터페이스를 제공 >> 사용자가 사용이 쉬워짐 
    server.Start("127.0.0.1", 4000);
  }

4. Bridge

** 4.1 의도 **

• 구현과 추상화 개념을 분리하여 각각 독립적으로 변형할 수 있게 한다.
• 클라이언트에서 어떤 추가적인 기능을 원할때 인터페이스가 바뀌면 모든 구현 클래스들이 변경되어야 함.
• Abstraction 이라는 가상의 클래스를 통해 간단한 기능은 해당 클래스에서 구현할 수 있고, 구현계층이 변경되더라도 사용자와는 아무 상관이 없다.

** 4.2. 예제 **

• 업데이트를 편안하게 하고 싶다면 중간에 계층을 늘려 상호 독립적으로 업데이트! (단 성능 저하가 발생할 수 있음)

  class MP3
  {
    IMP3* impl; //P - IMPL point to implementation으로 불리기도 함 .
  public:
    MP3(IMP3* p = nullptr) : impl(p)
    {
        if (impl == nullptr)
            impl = new IPod;
    }
  >
    void play() { impl->play(); }
    void stop() { impl->stop(); }
    >
    void play_one_minute()
    {
        impl->play();
        // 1분 후에.. 
        impl->stop();
    }
  };

** 4.3. PIMPL**

• Pointer to Implementation 으로 cpp 에서는 유용하나 다른 언어에서는 적합하지 않을 수 있다.
• Point.h가 간접 계층이 되어준다면 PointImpl이 변경되어도 main은 Point.h만을 사용하기 때문에 변경될 것이 없다 (== maind을 전부 재 컴파일 할 필요가 없다.)
• Pointer를 선언할때 include 없이 전방선언으로도 가능하기 때문에 가능한 기법이다.
• 컴파일러 방화벽이자 완벽한 정보 은닉이 가능해진다.(실제 구현 파트는 DLL로 제공)

  //#include "PointImpl.h"
  class PointImpl; // 핵심.. 포인터를 쓸때는 전방선언으로도 충분하다.
  >
  class Point
  {
    PointImpl* impl;
  public:
    Point(int x, int y);
  >
    void print() const;
  };

** 1.1. 의도 **

• 부분과 전체의 계층을 표현하기 위해 복합 객체를 트리 구조로 만들어낸다.
• Composite 패턴을 클라이언트로 하려면 개별 객체와 복합 객체를 모두 동일하게 다룰 수 있도록 한다.
• 재귀적, 혹은 당양한 타입의 함수 인자를 받기 위해서 공통의 interface로 묶어 Upcasting을 활용.

*1.2. 예제 *

• Pop Up Menu를 구현하고 싶은데, Pop up menu(Composite)는 menu(Leaf)도 들어가고 Pop up menu도 들어갈 수 있어야 한다.
• 자기 자신을 받기 위해서는 단순히 Menu만 받아 저장하는 것이 아니라 Upcasting을 활용하여 BaseMenu(Component)를 받아서 저장하게 한다. -

** 1.3. 장점 **

• 객체간의 관계만 바꾸어주면 수정과 추가가 쉽다
• 위 그림의 색상 변경을 해상도 변경 아래 를 수정하기 위해서 아래와 같이 관계를 재설정 하여 구현 가능

  int main()
  {
    PopupMenu* root = new PopupMenu("ROOT");
    PopupMenu* pm1 = new PopupMenu("해상도 변경");
    PopupMenu* pm2 = new PopupMenu("색상 변경");
  >
    root->add_menu(pm1);
  //    root->add_menu(pm2); // 기존 관계 해지
    pm1->add_menu(pm2); // 새로운 관계 생성 
  >
    pm1->add_menu(new MenuItem("HD", 11));
    pm1->add_menu(new MenuItem("FHD", 12));
    pm1->add_menu(new MenuItem("UHD", 13));
  >
    pm2->add_menu(new MenuItem("RED",   21));
    pm2->add_menu(new MenuItem("GREEN", 22));
    pm2->add_menu(new MenuItem("BLUE",  23));
    pm2->add_menu(new MenuItem("BLACK", 24));
  >
    // 메뉴를 시작하려면 ??
    root->command();
  }

• 공통 기능을 구현하는데 있어 두가지 방법을 따를 수 있음. 아래의 방법의 경우 복합객체와 객체의 사용법이 동일해진다는 장점이 존재한다.(단 Leaf 노드에서는 사용할 필요가 없기 때문에 Composite에서 기본적으로 재구현 하지 않으면 오류를 발생시키도록 설정해두는 방법도 존재)

  객체 지향이란 결국 객체를 만들고, 관계를 설정하고, 서로간의 메시지를 주고 받는(맴버 함수 호출) 과정이다.

2. Decorator Pattern

** 2.1. 의도 **

• 객체에 동적으로 서비스를 추가할 수 있게 한다.
• 객체에 서비스를 중첩적으로 추가할 수 있다.
• 상속을 사용하여 서비스를 추가하는 것보다 포함을 사용하여 유연한 방법으로 서비스를 추가할 수 있다.
• Component에 포함되는 다른 추가적인 ConreteComponet가 Decorator를
  재사용할 수 있다.

** 2.2 예제 **

• Image 클래스는 draw() 함수를 보유하며, 이미지 파일을 출력하는 기능을 가지고 있다고 하자.
• 하지만 이때 Image 클래스에 액자, 혹은 말풍선등을 추가하고 싶다고 가정한다.
• 상속을 통해 기능을 구현하는 경우 엄밀히 말하면 객체에 기능을 추가하는 것이 아니라 Class에 기능을 추가한 것이기에 사실상 새로운 기능이 추가된 새로운 객체를 호출해야한다. 뿐만아니라 중복적인 기능의 추가시 코드가 복잡해진다.
• 상속이 아니라 포함(이미 생성된 객체를 호출해서 활용)을 통해 기능을 추가
• 또한 중복적으로 값을 추가하기 위해서 객체를 생성하는 클래스와, Decorator 모두 상속해야하는 공통의 부모 클래스를 추가하하여(IDraw 함수, Composite의 component와 유사한 역할) 해결.
• 추가적으로 Operation() 함수들은 전달받은 객체의 Operation() 함수를 호출하고, 부가 적인 기능을 만을 추가

  class Frame : public Image 
  {
  public:
    using Image::Image;
  >
    void draw() const 
    { 
        std::cout << "==========================" << std::endl; //부가기능
        Image::draw();
        std::cout << "==========================" << std::endl; 
    }
  };
  class Balloon : public Image 
  {
  public:
    using Image::Image;
  >
    void draw() const 
    { 
        std::cout << "== Balloon ==============" << std::endl; //부가기능
        Image::draw();
        std::cout << "== Balloon ==============" << std::endl; 
    }
  };

※ 다양한 종류의 객체를 전달받아 사용하고 싶은 경우, 공통의 인터페이스를 만들고 Upcasting을 활용하여 해결

** 1.1. 정의 **

• 오퍼레이션에는 알고리즘의 처리 과정만을 정의 하고 각 단계에서 수행할 구체적인 처리는 서브 클래스에서 정의
• 의도 : 알고리즘의 처리과정은 변경하지 않고 알고리즘 각 단계의 처리를 서브클래스에서 재정의 할 수 있게 한다.
• 탬플릿이란 전체적인 틀을 의미함.

*1.2. 적용법 *

• 변하지 않는 코드 내부의 변경될 수 있는 코드를 찾는다
• 변해야 하는 코드를 가상함수로 분리
• 변경이 필요한 부분을 재정의 해서 활용.

클래스 다이어그램

2. Strategy Pattern

*2.1. 정의 *

• 다양한 알고리즘들이 존재하면 이들 각각을 하나의 클래스로 캡슐화 하여 알고리즘 대체가 가능하도록 구현 (이를 통해 알고리즘을 변경하더라도 클라이언트는 아무런 변경을 할 필요가 없음)

** 2.2 적용 방법 **

• 인터페이스를 만들고, 약한 결합 을 통해 생성한 정책 클래스의 객체를 호출하여 활용

  int main()
  {
    Edit edit;
    DigitValidator v(5); // 정책 클래스 객체 생성
    edit.set_validator(&v); // 정책 클래스의 객체 호출
  >
  //    AddressValidator v2(15); // 또다른 정책을 미리 생성해서 사용하는 것도 가능
  //    edit.set_validator(&v2);
  >
    while (1)
    {
        std::string s = edit.get_text();
        std::cout << s << std::endl;
    }
  }

** 2.3. Strategy VS Template pattern **

• Strategy

  • 정책을 사용하는 클래스와 정책이 서로다른 클래스로 분리 (위임)
  • 정책을 필요로 하는 다른 클래스에서도 동일한 정책 사용 가능
  • 실행시간에 전략 변경 가능

• Template pattern

  • 탬플릿 패턴을 사용하는 경우 정책을 사용하는 클래스가 해당 정책을 소유
  • 다른 클래스에서 해당 정책을 사용할 수 없음
  • 실행시간에 정책 변경 불가능 (정책을 사용하는 새로운 클래스를 호출해야 함)
  • 다른 클래스에서 사용할 일이 없고, 실행시간중 교체할 이유도 없는 경우(Draw 함수와 같이) 가상함수로 구현하는 경우, 맴버 데이터 접근도 편리 하다는 이점 또한 존재.

• 변경되는 부분이 공용성이 있는지, 종속적인 것인지, 맴버변수에 접근이 필요한지 등을 종합적으로 고려하여 선택

  ---

  클래스 다이어그램

  3. Policy Base Design

  ** 3.1. 정의 **

  • 클래스의 동작을 다양한 정책 클래스로 분리하여 ** 템플릿 인자로 전달 ** 하고, 컴파일 타임에 조합함으로써 유연하고 효율적인 설계를 가능하게 하는 템플릿 메타프로그래밍 기법으로 런타임 오버헤드 없이 구현 가능.(CPP의 STL이 해당 방식을 차용)

    ** 템플릿 ** : 모든 데이터 유형과 작동할 수 있는 함수 또는 클래슬 생성하기 위한 틀

    // Function template to swap two values
    template <typename T>
    void swapValues(T& a, T& b) {
    T temp = a;
    a = b;
    b = temp;
    }

    ** 템플릿 메타 프로그래밍 ** : 런타임 대신 컴파일 타임에 코드를 생성, 런타임에 직접 적용

    ``` cpp template T multiply(T a, T b) { return a * b; }

    int result = multiply(3, 4); // Compiler generates a version where T=int

    //------------------------------------- // 컴파일 시간에 생성되는 int version multiply int multiply(int a, int b) { return a * b; } //---------------------------------------

    ---

    ** 3.2. Strategy VS Policy base design**

• Strategy pattern

  • 전략 패턴의 경우 인터페이스를 사용하여 전략 객체를 생성하고 객체를 전달 받음
  • 해당 과정에서 가상함수 테이블을 사용하기에 런타임에 오버헤드가 발생할 수 있음

• Policy base design

  • 전략 패턴과 개념은 유사하지만, 객체 대신 템플릿 인자를 활용하여 정책을 전달하기 때문에 런타임 오버헤드가 없음
  • 인라인 치환도 가능
  • 실행시간에 교체 불가능
  • 인터페이스가 없기 때문에 구현자가 반드시 규칙에 맞추어 모든 기능을 수행할 수 있도록 구현 해야 함

    ---

• • 3.3. 예시 코드 **

    template<typename T, typename Ax = std::allocator<T> > // 기본 Allocator 제공
    class vector
    {
     T* ptr;
     Ax ax;
    pubilc:
     void resize(std::size_t newsize)
     {
         ptr = ax.allocate(size);
    >
         ax.deallocate(ptr, size);
     }
    };
    >
    template<typename T>
    class malloc_allocator 
    {
    public:
    //반드시 구현자가 아래의 두 함수를 구현해 주어야 함. 인터페이스가 없으므로 에러가 발생하지 않음. 문서에 맞게 구현자가 구현.
     inline T*   allocate(std::size_t size)  { return static_cast<T*>(malloc(sizeof(T)*size));}
     inline void deallocate(T* ptr, std::size_t size) { free(ptr);}
    };
    >
    int main()
    {
     vector<int, malloc_allocator<int> > v;
    }

1.1. 생성자 : 객체가 생성될 때 호출되는 특별한 함수로 주로 객체를 초기화하는 데 사용.

*1.2. 부모클래스의 생성자 호출 *

• 자식 클래스의 생성자를 호출하는 경우 부모 클래스의 기본 생성자가 자동으로 호출 되며, 부모 클래스의 생성자가 존재하지 않는 경우 Error가 발생.
• 부모 클래스의 기본 생성자가 아닌 다른 생성자를 호출하고 싶은 경우 명시적 으로 선언해 주어야 함.

  class Derived : public Base
  {
  public:        
  //    Derived() { }     // Derived() : Base(){ }
  //    Derived(int a) { }// Derived(int a) : Base() { }
   Derived()      : Base(0) { }
   Derived(int a) : Base(a) { }
  };

*1.3. Protected 생성자 *

• 부모 클래스의 생성자중 Protected로 선언된 생성자는 직접적으로 호출이불가능하나, 상속하는 것은 가능.
• 이는 개념(Animal)에 해당하는 부모 클래스를 생성하는 것을 막아 현실 세계를 더욱 사실적으로 모델링 할 수 있음.

  class Animal
  {
  protected: // protected는 상속에 열려 있으나 호출에 막혀 있다.
    Animal() {}
  };
  class Dog : public Animal
  {
  public:
    Dog() {}    // Dog() : Animal() {}
  };
  int main()
  {
    Animal a;    // A error protected 생성자를 직접 호출 하는 case
    Dog    d;    // B ok
  }
  

2. Upcasting

** 2.1. upcating**

• 자식 클래스(파생 클래스, derived class)의 객체를 부모 클래스(기반 클래스, base class)의 포인터 또는 참조로 변환하는 과정
• 단 이때 부모 클래스의 포인터로는 부모 클래스의 맴버만 접근할 수 있음
• 만약 자식 클래스의 맴버에 접근하고 싶다면 명시적 변환을 활용해야 한다.

  static_cast<Rect*>(p)->x = 0; // ok

2.2. Upcasting 활용

• 동종을 보관하는 Container로 활용.
• 모든 자식 클래스에 공통으로 적용되는 함수를 한번에 적용 ~cpp class Shape { public: int color; };
  class Rect : public Shape { public: int x, y, w, h; };
  void changeBlack(Shape* p) // 공통함수 한번에 적용 { p->color = 0; }
  /* void changeBlack(Triangle* p) { p->color = 0; }
• / int main() { Rect r; changeBlack(&r);
  Rect* buffer[10]; Shape* buffer[10]; //동종을 보관하는 Container }

3. Dynamic Cast

** 3.1. Downcasting **

• 부모 클래스의 객체를 자식 클래스의 포인터 또는 참조로 변환하는 과정
• 명시적인 변환이 필요하다. (Static or Danamic Casting)

** 3.2. Static Casting 과 Dynamic Casting **

• Static Casting
  • 컴파일 시간 Casting
  • 런타임에 오버헤드가 발생하지 않는다.
  • 컴파일 시간에는 Casting하려는 Memory가 무엇인지 확인할 수 없기 떄문에 잘못된 DownCasting인지 확인 불가능
• Dyanmaic Casting
  • 런타임 Casting
  • 런타임 오버헤드 발생
  • Casting 하려는 메모리 확인후 진행하여 잘못된 DownCasting이 발생하지 않는다. 단 메모리 확인을 위해 가상함수 테이블을 활용하기 때문에 가상함수가 존재해야만한다.

** 3.3. Dynamic Casting의 설계적 관점 **

• Upcasting을 통해 부모 클래스(Animal)에서 정의된 함수가 있다면, 모든 자식 Classd에서 수행 가능해야 좋은 설계라고 할수 있음.
• 따라서 굳이 Dynamic Casting을 통해 특정 자식객체인지 확인할 이유가 없다.
• 만약 특정 자식객체만 독특하게 수행해야할 것이 있다면 오버로딩을 통해 새로운 함수를 만들어 내는 것이 설계적으로 바람직함

  //기존의 코드를 수정하지 않고, 추가적인 요구사항을 만족시키기 위해 다음과 같이 오버라이딩을 진행
  void foo(Animal* p)
  {
    // 모든 동물의 공통의 작업
  }
  >
  void foo(Dog* p)
  {
    foo(static_cast<Animal*>(p));
    p->run();
  }

  위의 코드와 같이 기존의 코드는 건드리지 않고 (Closed) 추가적인 기능을 수행(Open)할 수 있는 것이 바람직하다.

4. Abstract

** 4.1. 가상함수 & 순수 가상함수 **

• 가상함수 : virtual 키워드가 앖에 먼저 선언되며, 자식 클래스에서 Overriding이 가능한 함수
• 순수 가상함수 : virtual 키워드로 시작하며, 구현부 대신 =0 으로 구성되어진 함수
  • 자식 클래스에서 해당 함수를 반드시 override 하도록 강제 (구현하지 않는경우 컴파일 되지 않음)
  • 순수 가상함수가 하나라도 포함한 클래스는 추상 클래스가 됨. (추상 클래스는 객체를 생성할 수 없으나, 포인터 생성은 가능)

4.2. 설계 관점

• 가상함수의 경우 자식 클래스에서 해당 함수를 재정의 하지 않으면 부모 클래스의 함수를 호출 가능. 하지만 이때 부모 클래스의 함수를 호출하는 것이 개념적으로 맞지 않을 수 있음.

  class Shape
  {
  public:
    virtual ~Shape() {}
    virtual void draw() = 0; // 추상적인 개념을 직접 그려낸다는게 어려움.
  };
  >
  class Rect : public Shape 
  {
  public:
    void draw() override { std::println("draw Rect"); }
  };

• 위의 코드와 같이 Shpae 라는 개념이 그려질(draw)될 일이 없으므로 순수 가장함수로 만들고, 자식 클래스에서 override 하여 그리는 방식 활용

5. Interface

** 5.1. 인터페이스 & 추상 클래스 **

• 인터페이스 : 모두 순수 가상 함수들로 구현 되어 지켜야할 규칙 만을 가진 클래스 (구현 한다고 표현)
• 추상 클래스 : 순수 가상함수를 하나라도 포함하는 클래스

* Struct를 이용해서 인터페이스를 생성하기도 함. (public 키워드 뺄 수 있음)

** 5.2. virtual 키워드 **

• virtual 키워드는 런타임 시에 실제 객체 타입에 따라 함수를 선택적으로 호출 되도록 보장. (CPP 진영에서는 "가상함수가 아니면 재정의 하지도 말라"라는 격언이 존재)
• 이런 이유로 interface 혹은 기반 클래스들은 가상 소멸자를 사용해 주는 것이 좋다.(Upcasting을 사용하여 부모 클래스의 포인터로 파생클래스의 객체를 참조하는 경우 부모 클래스의 소멸자가 호출되는데, 이때 자식 클래스의 맴버변수들에 대한 정보 누락으로 ** 메모리 누수**가 발생할 수 있음)

  struct ICamera
  {    
  //public:
    virtual ~ICamera() {} // 가상 소멸자.
  >
    virtual void take() = 0;    
  };

• 동일한 코드가 상황에 따라 다르게 동작하는 것을 다형성(Polymorphism) 이라고 하며 이는 OCP를 지키는데 큰 도움이 된다.

** 5.3. 강한결합 & 약한결합 **

• 강한 결합 : 서로의 클래스 이름을 알고 있는 상태로 교체가 불가능하고 경직적인 디자인
• 약한 결합 : 서로의 클래스명을 알지 못하는 상태로 교체가 가능하고 확장성 있는 유연한 디자인.

• commit id : 커밋 내용, 저자 정보, 날짜 및 시간, 부모 및 커밋 정보로 생성됨

• Head는 현재 버전을, main은 마지막 버전을 나타내며, 각각의 version은 이전(부모) version을 기억하고 있다. 이때 추가적으로 Head는 branch를 가르킬 수도, commit id/version을 기억할 수도 있다.

• detached Head : Head가 직접적으로 version을 가리키고 있는 상태 만약 이 상태에서 지속적으로 commit을 하고, 추후에 main으로 check out하게 되면 이전의 version들은 그 누구도 기억하지 않는 상태가 된다. 따라서 반드시 main으로 돌아올 때는 check out을 통해서 돌아오지 말고, main을 더블 클릭해서 돌아와야 한다. UI가 조금 헷깔리게 되어있는데 아래의 상태는 detached Head 상태이다 아래와 같은 상태가 되어야 제대로 되고 있는 것이다. 잘 보면 테두리의 색이 다름 추가적으로 문제가 발생하더라도, commit id만 기억해두면 해당 id로 check out 하여 복구 가능하고, detached head 상태에서도 branch를 만들고 merge해주면 문제를 해결할 수 있다.

• reset : Head가 가르키는 branch를 변경해준다 위의 그림과 같이 exp branch에 d를 추가하고 싶었다면 exp로 Head를 옮기고, exp를 d version으로 reset한뒤, 다시 main breanch로 check out, c version으로 reset 해주면 됨.

• rebase : Head가 가리키고 있는 branch의 base를 선택한 branch로 재설정(rebase) 시켜준다. 기본적으로 rebase, 새로운 base가 되는 branch가 먼저 기록이 남게 되고, 만약 충돌이 있다면

-cherry pick : 변경사항만을 가져오고 싶은 경우에 사용. 특정 변화만을 가져와서 사용할 수 있음

• origine/main : remote tracking branch(rtb), 서버에 push되어 있는 버전을 확인할 수 있음 아래와 같은 경우는 main과 origine/main이 일치되어 있는 상황을 의미한다.
• push : 로컬 저장소의 내용을 원격 저장소에 전달하는 것
• pull : fetch(원격 저장소의 내용을 로컬로 가져오는 것) + merge
• reject : 충돌이 되지 않더라도, 로컬 저장소가 원격 저장소의 내용을 가지고 있지 않다면 발생한다.

• Commit Convention 개요

• Udacity에서 제안하는 Commit Convention은 코드의 이력을 명확하고 일관되게 관리하기 위한 규칙입니다.
• 이 규칙에 따르면, Commit 메시지는 Type, Subject (필수), Body (선택적), Footer (선택적)로 구성됩니다.

• Commit Type

• feat =: 새로운 기능 추가 feat: Add login functionality
• fix: 버그 수정 fix: Correct minor typos in code
  • docs: 문서 변경 사항 docs: Update README with project setup instructions
  • style: 코드 스타일 관련 변경 코드 변경 없이 포맷팅, 세미콜론 추가 등의 스타일 관련 수정을 포함. style: Format code according to PEP8 standards
  • refactor: 코드 리팩토링 refactor: Restructure existing class hierarchy
  • test: 테스트 추가 또는 리팩토링 test: Add unit tests for User class
  • chore: 빌드 태스크, 패키지 매니저 설정 등의 변경. 실제 제품 코드 변경 없이, 프로젝트의 유지관리 작업을 포함 chore: Update package.json dependencies

• Commit Message 예시
  • Header:
    • Commit Log의 제목으로, 50자 이내, 대문자로 시작하고 마침표 없이 명령문 형태로 작성.
    • 태그와 작업의 대략적 내용을 포함
  • Body
    • 작업에 대한 상세 기록으로, Header와는 한 칸 공백으로 구분하며, 72자를 넘기지 않도록 함.
    • 본문에는 변경의 의도와 이유를 상세히 설명. 여러 단락의 경우, 빈 줄로 구분. 필요에 따라 하이픈(-)을 사용해 불릿 포인트를 추가할 수 있음
  • Footer
    • 관련 Issue의 태그를 포함합니다. '#'과 Issue 번호로 작성합니다.(이슈 트래커 참조)
    • 해당 commit이 merge 되면 자동으로 issue가 종료됨

02. Pre-commit

• Pre-commit 툴

• 'git commit' 수행 시 정해진 스크립트들을 자동으로 실행하는 툴입니다.
• 예: 코드 포맷팅(black, flake8), 유닛 테스트(pytest) 등을 실행합니다.

• Pre-commit 설치

• 가장 쉬운 방법은 pip를 사용한 설치입니다.
• pip install pre-commit 명령어로 설치합니다.

• Pre-commit Hook 설정

• '.pre-commit-config.yaml’ 파일 생성이 필요합니다.
• 기본 hook에는 공백 제거, 파일 검사 등이 포함됩니다.
• 추가로 black 같은 툴을 통해 코드를 PEP8에 맞게 정리할 수 있습니다.
• pre-commit install로 hook을 설치합니다.
• pre-commit autoupdate로 hook을 업데이트합니다.

• Pre-commit 적용

• 파일을 commit하면 등록된 hook이 자동으로 실행되며, 필요에 따라 수정 후 다시 commit합니다.

• Git Flow와 Github Flow

• Git을 사용하며 branch를 활용하는 전략입니다.
• Local 중심의 Git flow와 Remote 중심의 Github flow가 대표적입니다.
• Local Remote 중심은 최신 commit이 위치하는 곳을 의미합니다.
• Git flow는 Local에 최근 작업한 commit들이, Github flow는 Local과 Remote에 위치합니다.

01 Git Flow

• Gitflow: Local 중심 Branch 전략

• 주요 branch로는 main(master), develop, release, feature, hotfix 등이 있습니다.

• main(master)

• 배포의 기준이 되며 Release Tag를 기록하는 브랜치입니다.
• 배포용이므로 main에 직접 commit하거나 비배포용 branch에서 merge 금지.
• hotfix 브랜치는 main에 직접 merge 가능.

• develop

• 주로 개발이 이루어지는 브랜치.
• 동시 작업 시 conflict 발생 가능, 따라서 feature 브랜치에서 작업 후 develop에 merge 권장.

• feature

• 개발 작업의 핵심, develop에서 분기.
• Issue에 등록된 기능, bugfix, refactoring 등을 수행.
• 작업 완료 시 develop에 merge.
• 예: feat, refactor, fix, docs 등의 prefix 사용.

• release

• 배포 준비를 위한 브랜치.
• develop에서 분기, bugfix 및 추가 refactoring 진행.
• 준비 완료 시 main에 merge.

• hotfix

• 배포된 버전(main)에서 문제 발생 시 사용.
• main에서 분기, 문제 해결 후 main 및 develop에 merge.

02 Github Flow

• Remote 중심 Branch 전략

• Git Flow와 달리, 주로 main 브랜치와 feature 브랜치로 구성.
• main은 배포의 중심, feature는 기능 개발의 중심.
• Remote에 작업 내용을 수시로 push, 항상 최신 상태 유지.
• 배포 준비용 브랜치 없이, main에 merge 시 엄격한 관리 필요.
• Github Flow는 빠른 반영과 심플한 구조가 특징.

참고 블로그 : https://herbwood.tistory.com/

01. Object Detection metrics & Library

1.1 Object Detection 평가 지표

• mAP (mean Average Precision)

• mAP는 클래스별 평균 정밀도(Average Precision)를 평균낸 것으로, 객체 탐지 알고리즘의 성능을 평가하는 데 중요한 지표
• mAP를 이해하려면 정밀도(Precision), 재현율(Recall), AP, IOU 등의 개념을 알아야 함.

• Precision & Recall

• 정밀도(Precision)는 Positive로 예측한 대상 중 실제로 Positive인 비율.
• 재현율(Recall)은 실제 Positive인 대상 중 올바르게 예측된 비율.
• TP(True Positive), FP(False Positive), TN(True Negative) 등의 개념을 통해 계산.

• IOU

• 교차집합 / 합집합
• 값이 1에 가까울수록 두 집합이 더 유사하다는 것을 의미하며, 0에 가까울수록 두 집합이 더 차이가 있다는 것을 의미

  • mAP 계산

• 정밀도와 재현율 곡선(Precision-Recall curve)을 사용해 계산되며, 여기서 얻어진 정밀도의 평균이 AP.
• mAP는 다양한 객체에 대한 AP의 평균값으로, 객체 탐지 성능의 전반적인 척도를 제공.

** 1.2 Object Detection 라이브러리**

• MMDetection

• PyTorch 기반의 객체 탐지 오픈소스 라이브러리

• Detectron2

• 페이스북 AI 리서치에서 개발한 PyTorch 기반의 객체 탐지 및 세그멘테이션 라이브러리.

• YOLOv5

• COCO 데이터셋으로 사전 학습된 모델로, 여러 연구와 개발을 거쳐 발전한 객체 탐지 모델.
• 다양한 플랫폼에서 오픈 소스로 제공.

• EfficientDet

• Google Research & Brain에서 연구한 모델로, EfficientNet을 응용해 만든 객체 탐지 모델.

• TensorFlow와 PyTorch 기반 라이브러리가 제공.

  02. 2 Stage Detectors

  2.1 R-CNN

  • 파이프라인

• 주요 과정은 입력 이미지 처리

• Region Proposal 추출

• CNN을 통한 feature 추출

• SVM 분류, Bounding Box Regression

• 학습 방법

• Pretrained AlexNet을 사용하여 4096차원의 feature vector를 추출.
• 각 Region에 대해 SVM을 사용하여 클래스를 분류하고, Bounding Box Regressor로 정확한 위치를 예측합니다.

• 단점

• 각각의 Region을 CNN에 통과시켜야 해서 계산 비용이 큼.
• Warping을 통해 이미지를 변형시키는 과정에서 성능 저하가 발생 가능.
• CNN, SVM, Bounding Box Regressor를 각각 별도로 학습해야함.
• End-to-End 학습이 아니기 때문에 최적화가 어려움.

2.2 SPPNet

• 파이프라인

• R-CNN과 달리 CNN을 먼저 통과
• Spatial Pyramid Pooling을 사용하여 다양한 크기의 feature map에서 고정된 크기의 feature를 추출.

  Spatial Pyramid Pooling : 이미지의 다양한 크기의 영역에 대해 고정된 크기의 특징 벡터를 생성(spatial bins의 개수를 정하고 pooling을 진행하기에 이미지의 크기에 상관없이 고정길이 feature 추출 가능)

• Fully connected layer를 통과
• SVM, Bounding Box Regressor 학습

2.3 Fast R-CNN

• 파이프라인

• 한 번의 CNN 처리를 통해 feature를 추출하고
• RoI Pooling을 사용하여 모든 Region에 대해 고정된 크기의 feature를 추출.

  ROI Pooling : Receptive field가 RoI에 맞게끔 계산하여 영역을 정하고 해당 부분에 대해서 pooling을 진행. 아래 그림에서 정중앙이 아닌 이유는 영역의 크기가 홀수 여서 버림을 진행하였기 때문!

• 이하 동일

• 학습 방법

• Multi-task loss(분류 및 Bounding Box Regression)를 사용.
• VGG16과 같은 강력한 CNN 구조를 사용하여 성능을 향tkd.

2.4 Faster R-CNN

• 파이프라인

• Feature extraction by pre-trained VGG16
• Generate Anchors by Anchor generation layer : 각각의 Grid Cell(원본이미지를 sub sampling ratio를 기준으로 기준으로 나눈 특정 영역)을 중심으로 기준(Anchor)를 생성하여 사전 정의된 9개의 anchor box 생성.
• Class scores and Bounding box regressor by RPN

  RPN : 미지 내에서 객체 후보 영역을 빠르게 제안하는 역할

• Region proposal by Proposal layer : anchor boxes와 RPN에서 반환된 class scores, bounding box regrerssor를 사용하여 anchor box가 객체의 위치를 더 잘 detect하도록 조정
• ROI pooling
• Classification

  NMS(Non-Maximum Suppression): confidence score가 낮은 박스 OR highest IoU score인 박스를 비교해가며 하나씩 삭제해 나감

• 학습 방법

• Imagenet pretrained backbone과 RPN을 번갈아 가며 학습하는 4단계 학습 방법을 사용.
• Fast R-CNN과 동일한 loss 함수를 사용하며, RPN 단계에서의 classification과 regressor 학습을 위해 anchor box를 사용.

03. Object Detection Library

3.1 MMDetection

• 기본 구조

• Pytorch 기반의 Object Detection 오픈소스 라이브러리입니다.
• MMDetection 라이브러리의 주요 특징은 전체 프레임워크를 모듈 단위로 분리해 관리할 수 있으며, 다양한 프레임워크를 지원하고 속도가 빠른 점입니다.

• Pipeline 구조

• Backbone, Neck, Dense Prediction Prediction 등 여러 단계를 거칩니다.
• 2 Stage 모델은 크게 Backbone, Neck, DenseHead, RoIHead 모듈로 나눌 수 있으며, 각 모듈 단위로 커스터마이징이 가능합니다.
• 이러한 시스템은 config 파일을 통해 제어됩니다.

• Config File

• Config 파일은 데이터셋부터 모델, scheduler, optimizer를 정의할 수 있으며, 다양한 object detection 모델들의 config 파일들이 정의되어 있습니다.

• 기본 구성요소
  • dataset : Train, Validation, Test
  • model : type, backbone, neck, rpn_head, roi_head, bbox_head, train_cfg
  • schedule
  • default_runtime

3.2 Detectron2

• 기본 구조

• Facebook AI Research의 Pytorch 기반 라이브러리입니다.
• Object Detection 외에도 Segmentation, Pose prediction 등의 알고리즘을 지원합니다.

• Pipeline 구조

• Setup Config, Setup Trainer, Start Training의 단계를 포함합니다.
• Config 파일 수정, 데이터셋 등록, Augmentation mapper 정의, Trainer 정의 등의 단계로 구성됩니다.

• Config File

• MMDetection과 유사하게 config 파일을 수정하여 파이프라인을 구축하고 학습을 진행합니다.

• 틀이 갖춰진 기본 config를 상속 받아 필요한 부분만 수정하여 사용합니다.

  04. Neck 구조

4.1 Neck

• 구조
• 필요성

• 입력, Backbone, Neck, RPN, Prediction의 유의미한 연결.
• 다양한 크기의 객체를 더 잘 탐지하기 위해 필요.
• 하위 레벨의 feature가 세맨틱적으로 약할 때, 상위 레벨의 강한 세맨틱 feature와의 교환을 수행.

4.2 Feature Pyramid Network (FPN)

• high level에서 low level로 세맨틱 정보를 전달하는 방식.
• Bottom-up, Top-down, Lateral connections 등을 통해 구성
• Upsampling시 Nearest Neighbor Upsampling 방식을 사용.
• Backbone으로 ResNet을 사용하며, Top N Boxes를 선택하는 과정을 포함.
• ROI Pooling을 진행하기 위해서, ROI의 크기에 따라 적절한 feature map(p5~p2)을 선정하여 진행하였음.

4.3 Path Aggregation Network (PANet)

• Bottom-up Path Augmentation

• Top-down을 진행할 때 과연 Row level feature가 high level featuer에 전달이 되지 않을 수 있다.
• Bottom-up Path Augmentation을 사용하여 하위 level feature가 보다 상위 level에 잘 전달 하게 구조 개선
  • ** Adaptive Feature Pooling **
  • ROI 풀링 시 경계 값에서 feture map을 선택하는데 있어 불연속적
  • Adaptive Feature Pooling을 통해서 모든 feature map을 고려

4.4 DetectoRS

• DetectoRS 동기

• (RPN), Cascade R-CNN 등을 고려하여 반복적인 계산을 통해 성능 개선을 이룰 수 있을 거라 판단.
  • Recursive Feature Pyramid (RFP)
• Neck의 정보를 활용하여 Backborn Network를 재학습
• Atrous Spatial Pyramid Pooling(ASPP) : 원본 feature를 여러 필터로 탐색하여, 보다 다양한 scale에서 유용한 정보를 뽑는 기법
• Atros Convolution

4.5 Bi-directional Feature Pyramid (BiFPN)

• 하나의 feature의 정보만 받게되는 노드 삭제
• 반복적으로 진행
• FPN과 달리, 각 feature에 가중치를 부여한 후 summation하는 방식

4.6 NASFPN

• FPN 아키텍처를 NAS(Neural architecture search)를 통해서 찾아보려는 시도
• Architecture, Search, Stacking 단계를 포함.
• COCO dataset ResNet 기준으로 찾은 architecture가 범용적이지 못하며, 많은 파라미터와 높은 search cost가 필요.

4.7 AugFPN

• FPN의 문제점, 특히 서로 다른 레벨의 feature 간의 semantic 차이, Highest feature map의 정보 손실, RoI 생성 방법 등을 개선

• Residual Feature Augmentation
  • 최고층의 feature map에서 정보의 손실이 발생하는 것을 막기 위해 Residual Feature를 증강해서 새로운 feature map 생성
  • 생성을 위해 Adaptive Spatial Fusion을 진행. 해당 과정에서 하위 feature map의 중요도를 학습하여 Weight Aggreation 진행
• Soft RoI Selection
  • PANet의 max pooling시의 정보 손실을 막기 위해 시도
  • 모든 scale의 feature에서 RoI projection 진행 후 RoI pooling
  • Channel-wise 가중치 계산 후 가중합을 사용

버전과 버저닝

• 버전(Version): 소프트웨어 제품의 특정 릴리스에 대한 고유한 식별자입니다.
• 버저닝(Versioning): 소프트웨어에 고유한 버전 이름과 번호를 할당하는 과정입니다.

파이썬 3.11 설치하기

• 다양한 방법으로 파이썬을 설치할 수 있습니다:
  • 공식 홈페이지에서 다운로드
  • Conda를 사용하여 설치
  • Docker 이미지를 사용하여 설치
  • 패키지 관리자(brew, apt, winget)를 사용하여 설치
  • Pyenv를 사용하여 설치

Pyenv

• Pyenv: 파이썬의 다양한 버전을 CLI로 쉽게 설치하고 관리할 수 있는 도구입니다.

3. 파이썬 프로젝트 버전 관리

3.1 가상 환경

• 가상 환경: 프로젝트 별로 독립적인 파이썬 환경을 생성하여 패키지 충돌 문제를 해결합니다.

3.2 패키지 매니저

• 파이썬의 주요 패키지 매니저:
  • pip: 가장 많이 사용되는 파이썬 내장 패키지 매니저입니다.
  • poetry
  • conda (주로 Anaconda의 패키지 매니저)

2. 리눅스(Linux)

2.1 리눅스

• Linux의 이해
  • 개발하기 전에는 주로 Mac OS나 Windows OS에 익숙하지만, 프로그래밍에 본격적으로 입문하면 Linux를 많이 다루게 됨.
  • 특히 서버와 관련된 직군에서 Linux 사용이 많음.

• Linux를 알아야 하는 이유

• 서버에서 자주 사용되는 OS로, Mac이나 Windows도 서버로 사용 가능하지만 유료임.
• Linux는 Free이며 오픈소스로, 다양한 버전이 존재하여 사용자가 직접 버전을 만들 수도 있음.
• Linux는 안정성과 신뢰성이 높으며, Unix 기반으로 Stability와 Reliability를 제공함.
• 쉘 커맨드와 쉘 스크립트 사용이 중요.

2.2 Shell Command

• 쉘의 종류

• sh: 최초의 쉘.
• bash: Linux 표준 쉘.
• zsh: Mac Catalina OS의 기본 쉘.

  • 쉘 사용 사례

• 서버 접속, crontab 같은 Linux 내장 기능 활용, 데이터 전처리, Docker 사용, 서버 관리 등에 쉘 커맨드 사용.

• 기본 쉘 커맨드

• man: 쉘 커맨드의 매뉴얼 문서를 보기 위함.
• mkdir: 폴더 생성.
• ls: 현재 폴더의 파일 목록을 확인.
• pwd: 현재 폴더의 절대 경로를 보여줌.
• cd: 폴더 이동.
• echo: 터미널에 텍스트 출력.
• cp: 파일 또는 폴더 복사.
• mv: 파일 또는 폴더 이동 또는 이름 변경.
• cat: 파일 내용 출력 및 파일 합치기.

• Redirection & Pipe

• Redirection을 통해 프로그램의 출력을 다른 파일이나 스트림으로 전달할 수 있음.
• Pipe를 사용하여 한 프로그램의 출력을 다른 프로그램의 입력으로 사용 가능.

• 서버에서 자주 사용하는 쉘 커맨드

• ps: 현재 실행 중인 프로세스를 보여줌.
• curl: 커맨드 라인 기반 데이터 전송, 웹 서버의 요청 테스트에 사용.
  • scp: SSH을 이용해 파일을 네트워크를 통해 전송.

2.3 쉘 스크립트

• 쉘 스크립트의 이해

• 쉘 커맨드의 조합으로 구성되며, Python과 유사한 if, while, case 문을 포함할 수 있음.
• 실제 작성 예시 및 학습 방법 제공.

3. Docker

3.1 Docker 소개

• 가상화란?

• 하나의 물리적 서버에 여러 개의 가상 서버를 생성하는 기술로 가상 서버는 물리적 서버의 하드웨어 자원을 공유하지만, 독립적인 운영 체제와 응용 프로그램을 실행할 수 있음
• 가상화를 통한 일관된 개발 환경 제공의 필요성.

• Container란?
  • 가상화의 한 형태로, 애플리케이션과 그 애플리케이션을 실행하는 데 필요한 모든 종속 항목을 하나의 패키지로 묶은 것
  • 컨테이너는 가상 머신과 달리 운영 체제의 커널을 공유하기 때문에 가볍고 효율적

• Docker 소개

• 컨테이너 기반의 개발과 운영을 빠르게 확장.
• 가상화 기술을 쉽게 사용할 수 있는 도구.
• Docker Image : 컨테이너를 실행할 때 사용할 수 있는 '템플릿'
• Docker Container : Docker Image를 활용해 실행된 인스턴스

3.2 Docker 사용법

• Docker 실행 명령어

• docker run --name [컨테이너 이름]: 컨테이너에 이름 지정. 이름을 지정하지 않으면 Docker가 랜덤으로 이름을 생성
• -e [환경변수=값]: 컨테이너에 환경변수 설정. MySQL 컨테이너의 경우, root 계정 비밀번호 설정을 위해 -e MYSQL_ROOT_PASSWORD=1234 사용
• -d: 컨테이너를 백그라운드 모드로 실행. 이 옵션을 사용하지 않으면 컨테이너가 현재 셸 위에서 실행되며, 셸을 종료하면 컨테이너도 종료됨 .
• -p [로컬 호스트 포트]:[컨테이너 포트]: 로컬 호스트의 포트와 컨테이너 포트를 연결. 예: -p 3306:3306을 사용하여 로컬 포트 3306을 컨테이너 포트 3306에 연결

• Docker 기본 명령어

• docker pull “이미지 이름:태그": 필요한 이미지 다운로드.
• docker images: 다운받은 이미지 목록 확인.
• docker run “이미지 이름:태그": 이미지를 기반으로 컨테이너 생성.
• docker ps: 실행 중인 컨테이너 목록 확인. -a 명령어를 활용하여 작동을 멈춘 컨테이너도 확인 가능
• docker exec -it “컨테이너 이름(ID)”/bin/bash: 컨테이너에 진입.
• docker stop “컨테이너 이름(ID)”: 실행 중인 컨테이너 중지.
• docker rm “컨테이너 이름(ID)”: 중지된 컨테이너 삭제. -f 옵션을 통해서 실행중인 것도 삭제 가능
  • -v [호스트 폴더]:[컨테이너 폴더]: 호스트와 컨테이너 간의 폴더 공유. ex) dockerrun-it-p8888:8888-v/some/host/folder/for/work:/home/jovyan/workspace jupyter/minimal-notebook

    • Docker Image 작성

• Dockerfile은 Docker Image를 빌드하기 위한 정보를 담고 있음.
• FROM: 이미지 빌드에 사용할 베이스 이미지를 지정.
• COPY: 로컬 디렉토리(파일)을 컨테이너 내 디렉토리(파일)로 복사.
• WORKDIR: Dockerfile의 명령어들을 실행할 컨테이너 경로 지정.
• ENV: 컨테이너 내 환경변수 설정.
• RUN: 컨테이너 내에서 리눅스 명령어 실행.
• CMD: 컨테이너 실행 시 바로 실행할 명령어.

• Docker Image 빌드

• docker build -t <이미지 이름:태그> <Dockerfile 위치>: Docker Image 빌드. ex): docker build -t 02-docker:latest .
• -t 옵션으로 이미지 이름과 태그 지정.
• 태그를 지정하지 않으면 기본적으로 latest가 사용됨.
• 빌드가 완료되면 docker images 명령어로 이미지 확인 가능.

• Docker Image Push

• 이미지를 온라인 저장소에 업로드.
• 로그인: docker login 명령어로 Docker 계정에 CLI에서 로그인.
• 태그 설정: docker tag <기존 이미지:태그> <새 이미지 이름:태그>.
  • Dockerhub에 올릴 경우, 이미지 이름은 계정 ID/이미지 이름 형태여야 함​【oaicite:1】​.
• Push: docker push <이미지 이름:태그> 명령어로 이미지 업로드.

• 원격 사용법 https://donghwa-kim.github.io/vscode_ssh.html

4. 디버깅

4.1 디버깅 Process

• 문제 인식

• 문제 상황 확인: 어떤 상황인지, 재현 가능성
• 오류 분류: 코드 오류, 인프라 오류, 알 수 없는 오류 등

• 해결책 찾기

• 과거 경험, 구글, Stackoverflow, 오픈카톡방, 공식 문서, Github Issue, ChatGPT 등을 통한 정보 수집
• 오답노트 및 오픈소스 코드 확인

4.2 서버 관리

• 서버의 역할과 관리

• 서버는 클라우드뿐만 아니라 집에 있는 컴퓨터로도 활용 가능
• 서버 관리의 목적: 안정적 운영 및 장애 방지

• 서버 관리를 위한 기초 지식

• Shell Command, 파일 시스템, 네트워크, 패키지 관리, 성능 모니터링, Docker 컨테이너 등
• Linux 파일 시스템 구성과 디스크 관리 방법

4.3 네트워크 관리

• 네트워크 관리와 진단

• IP, DNS, 포트 관리 및 방화벽 설정
• 네트워크 진단 명령어: ping, nslookup, netstat 사용법

5. MLOps

5.1 MLOps 개론

• 모델 개발 프로세스 (Research & Production)

• MLOps : ML(MachineLearning)+Ops(Operations)
• Research 프로세스: 문제 정의, EDA, Feature Engineering, Train, Predict.
• Production 프로세스: 위 단계에 Deploy 단계 추가.

5.2 MLOps Component

• Infra (Server GPU) : 서버 GPU 및 기타 인프라에 대한 중요성. (GCP, AWS)
• Serving : 모델의 배포 및 서빙 방식에 대한 설명.
• Experiment & Model Management : 실험 관리와 모델 관리의 중요성.

• MLflow : 모델의 개발, 배포 및 추적을 위한 오픈 소스 플랫폼. mlflow.sklearn.autolog() 와 같이 한줄로 logging을 시도할 수 있음

  • Feature Store : 데이터 특징 저장 및 관리 방법.
  • Data Validation : 데이터 유효성 검증의 중요성.

• 데이터 드리프트 : 입력 데이터의 통계적 특성이 예상치 못하게 변화하여 모델 성능이 저하되는 현상
• 모델 드리프트 : 시간에 따라 입력과 출력 변수 간의 기본 관계가 변경되어 모델 성능이 저하되는 현상
• 개념 드리프트 : 모델이 예측하려는 대상 변수의 통계적 특성이 변경되는 현상

  • Continuous Training : 모델의 지속적인 훈련 및 업데이트 필요성.
  • Monitoring : 모델 성능 및 상태 모니터링의 중요성.
  • AutoML : 자동화된 머신러닝 프로세스의 장점.

• NNI : 양한 머신 러닝 프레임워크와 호환되며, 다양한 하이퍼파라미터 탐색 방법을 제공

5.3 Futher reading

• awesome-production-machine-learning
• awesome-mlops
• Practitioners Guide to Machine Learning Operations (MLOps)

6.Model Serving

** 6.1 Model Serving 개요**

• Model Serving의 정의

• 실제 환경(앱, 웹 등)에서 머신러닝 모델을 사용할 수 있도록 배포하는 과정입니다.
• 서비스화된 모델을 회사 서비스의 일부로 활용할 수 있습니다.

• Model Serving의 주요 방식

• Model Serving은 크게 Online Serving 과 Batch Serving 두 가지 방식으로 나뉩니다.
• 각각의 방식은 모델을 배포하고 활용하는 방법에 따라 다릅니다.

** 6.2 Online Serving**

• Web Server 기초

• Web Server는 HTTP를 통해 요청받은 내용을 전달하는 역할을 합니다.

• Online Serving의 특징

• 실시간으로 요청에 대해 예측하고 결과를 반환합니다.
• 클라이언트(애플리케이션)에서 머신러닝 모델 서버에 HTTP 요청을 하고, 서버는 예측 후 결과를 반환합니다.

• Online Serving의 구현

• 직접 API 웹 서버 개발, 클라우드 서비스 활용, Serving 라이브러리 활용 등 여러 방법이 있습니다.

6.3 Batch Serving

• Batch Serving 기초

• Batch Serving은 데이터를 주기적으로 한꺼번에 처리합니다.
• 예: 매일 특정 시간에 데이터를 처리하거나, 일정 주기로 예측을 수행합니다.

• Batch Serving의 예시

• 추천 시스템, 수요 예측 등 실시간 처리가 필요하지 않은 대부분의 경우에 활용됩니다.

• Batch Serving의 장단점

• 구현이 간단하고 많은 데이터를 한번에 처리할 수 있는 장점이 있습니다.
• 실시간으로 활용할 수 없다는 단점이 있습니다.

6.4 Online Serving과 Batch Serving 비교

• 선택 기준

• 데이터 처리 방식과 결과 활용 방식에 따라 선택합니다.
• 예: 데이터를 하나씩 실시간 처리해야 하면 Online, 한꺼번에 처리해도 되면 Batch 방식을 선택합니다.

7. ML Project Flow

7.1 머신러닝 프로젝트 Flow

• 문제 정의의 중요성 : 문제 해결을 위해 명확한 문제 정의가 필수임을 강조.
• 현상 파악 : 현재 발생하고 있는 사건과 그로 인한 어려움을 파악하는 과정.

• 구체적인 문제 정의 : 문제를 보다 명확하고 구체적으로 정의하고, 이를 해결하기 위한 방법 모색.
• 프로젝트 설계 : 문제 정의에 기반한 프로젝트의 전체적인 설계.

  • 지표 결정 : 프로젝트의 성공을 측정하기 위한 지표를 결정.
  • Action(모델 개발 후 배포 & 모니터링) : 개발한 모델을 배포하고 그 성능을 모니터링하는 단계

7.2 비즈니스 모델

• 비즈니스 모델 파악하기

• 프로젝트의 비즈니스 측면을 이해하고, 비즈니스 모델을 분석하는 과정

7.3 예시

• 문제 정의에서 출발 : 문제 정의, 데이터 수집, 모델 개발, 배포 및 수익 획득의 순서로 진행.
• 실제 프로젝트 과정 : 문제 정의, Metric 선택, 데이터 수집, 모델 개발, 예측 결과 분석, 모델 재학습, 데이터 추가 수집, 모델 최적화 및 재학습 과정을 거침
• 목표 설정 : 프로젝트의 일반적인 목적과 그 달성을 위한 구체적인 단계 목표 설정.
• 목표 예시 : 랭킹 시스템에서 고객 참여 최대화 목표 설정 및 세부 목표 규정
• 비즈니스 목표 영향 파악 : 모델 성능 지표와 별개로 비즈니스 목표에 미치는 영향을 고려해야 함
• 제약 조건 : 프로젝트의 시간, 예산, 영향 받는 사람들 등을 고려.
• 기술적 제약 및 개인정보 보호 : 기존 인프라의 제약, 데이터 저장 및 보호 요구사항 등을 고려

8. 웹 서비스

8.1 웹 서비스 형태 - Streamlit

• 웹 서비스를 만드는 과정

• Voila에서의 학습 내용과 Streamlit의 장점 소개
• Voila의 장점: 노트북에서 쉽게 프로토타입을 만들 수 있음, 하지만 대시보드 레이아웃 설정이 어려움
• Streamlit의 등장 배경: 프로토타이핑을 위한 자바스크립트, React, Vue 사용의 비효율성과 HTML/자바스크립트 + Flask/Fast API 대신 기존 코드를 소량 수정하여 웹 서비스 제작 목표

• Streamlit의 대안

• R의 Shiny, Flask Fast API (백엔드 직접 구성 + 프론트엔드 작업), Dash (Python 대시보드 라이브러리), Voila (Jupyter Notebook 시각화)

• Streamlit 소개

• 장점: 파이썬 스크립트 코드를 소량 수정하여 웹 서비스 구현, 백엔드 개발 및 HTTP 요청 불필요
• 다양한 컴포넌트 제공, Streamlit Cloud를 통한 쉬운 배포, 화면 녹화 기능
• 예시 및 Streamlit Gallery 소개

• Streamlit 설치 및 실행

• 설치 방법: pip3 install streamlit
• 실행 방법: CLI를 통해 streamlit run streamlit-basic.py 실행, localhost:8501로 접근

• Streamlit 기능

• Text 작성, Button, Check Box, Pandas Dataframe, Markdown, Metric, JSON, Line Chart, Map Chart, Radio Button, Select Box, Multi Select Box, Slider, Input Box, Caption Code, Latex, Layout (Sidebar, Columns, Expander), Spinner, Balloons, Status Box, Form, File Uploader 등 다양한 기능

• Streamlit의 데이터 플로우

• 화면 업데이트 시 전체 코드 재실행
• 사용자 위젯 상호작용 시 코드 수정

• Streamlit Session State

• 데이터 플로우로 인한 코드 재실행 문제 해결을 위한 Global Variable 비슷한 기능
• Streamlit 0.84 버전에 session_state 개발
• Counter 예제로 session_state 사용 방법 설명

• Streamlit Cache - @st.cache

• 매번 코드 재실행으로 인한 데이터 재읽기 문제를 해결하기 위한 캐싱 기능
• 데이터 읽는 함수에 데코레이터 적용 방법

• 특별 임무

• Jupyter Notebook으로 만든 마스크 분류 모델을 Streamlit으로 구현
• 공식 문서 읽고 정리
• Callback 함수를 사용하여 session_state 값을 유지하는 코드 작성
• CV/NLP에서 진행한 프로젝트를 Streamlit으로 구현

추가 라이브러리

• poetry
• MLflow
• NNI
• wandb
• streamlit

1.1 Neural networks

• 정의 : 비선형 변환을 통해 우리가 원하는 함수로 근사시키는 모델

1.2 MLP

• 다층 신경망으로, Neural Networks가 적층되어 있는 구조
• 각각의 Layer를 다른 차원으로 변환시켜주는 행렬로 생각해주는 것이 좋음
• 이때 Activation Function을 활용하여 비선형성을 주지 못한다면 합성곱으로 인해 그저 하나의 층이 있는 것과 동일하다.

2. Optimization

2.1 Important Concepts in Optimization

• Generalization : 보지 않은 데이터에 대해서 모델이 어떻게 반응할 것인가
  • Underfitting : 과소적합
  • Overfitting : 과적합

• Cross-validation : Validation Set을 K개로 나누어 K-1 개로 학습을 진행하고, 나머지 하나에 대해서 검증을 진행하는 방식.
  

• Bias and Variance Tradeoff : 모델의 복잡도가 증가하면 Bias는 감소 할수 있을지 몰라라도 반대로 Variance가 커진다. 아래의 그림과 같이 Bias와 Variance는 Trade Off 관계로 두개를 모두 만족하는 모델을 찾기란 어렵다.

• Bootstrapping : 표본 데이터로부터 추가적인 표본을 생성하여 여러 모델을 학습하고, 모델들의 결과를 종합해 결론을 내는 방식
  • Bagging(Bootstrapping aggregating) : bootstrapping을 통해 생성된 여러 모델들의 voting 혹은 평균값을 활용하여 결과를 도출
  • Boosting : 순차적으로 강화되는 방식으로 모델을 훈련시킴. 이전 모델이 잘못 예측한 샘플에 가중치를 높여서 다음 모델을 훈련시키는 방식.

*2.2 Gradient Descent Method *

• Batch-size
  • Batch gradient descent : 전체 데이터를 사용하여 gradient를 계산, 시간이 오래걸린다는 단점이 있음
  • Mini-batch gradient descent : Mini-batch 단위에 들어있는 데이터를 활용하여 데이터를 계산
  • Stochastic gradient descent : 무작위로 선택된 하나의 데이터 포인트에 대한 그래디언트을 활용해 gradient 계산, 로컬 미니마로 부터 벗어날 가능성이 있음.

• Batch-size Matter Batch Size가 작을수록 Flat Minimum로 수렴하기 때문에 보다 일반화 성능이 올라감. Flat Minimum의 경우 함수의 굴곡이 작아, 비교적 적은 차이를 만들어낼 수 있기 때문.

• *Gradient Descent Methods *
  • Stochastic gradient descent 여기서 $J()$는 손실함수

    $\theta_{t+1} = \theta_t - \eta \nabla J(\theta_t; x^{(i)}, y^{(i)})$

  • Momentum :이전의 gradient 변화를 고려하여 관성을 부여하는 방식. 기울기가 0인 지점에서 momentum이 존재하여 local minima에서 벗어날 수 있음. $v_t$는 모멘텀

    $v_t = \beta v_{t-1} + (1 - \beta) \nabla J(\theta_t)$ $\theta_{t+1} = \theta_t - \eta v_t $

  • Nesterov Accelerated Gradient (NAG): 모멘텀을 사용하지만, 현재 위치가 아니라, 모멘텀 방향으로 더 진행한 상태의 gradient를 업데이트 하는 방식

    $v_t = \beta v_{t-1} + (1 - \beta) \nabla J(\theta_t - \eta \beta v_{t-1})$ $\theta_{t+1} = \theta_t - \eta v_t$

  • Adagrad : 매개변수 마다 학습률을 조절하여 업데이트 하는 방식. 변화값이 클 수록 학습속도가 감소함. 학습이 지속되면서 결국 학습이 잘 일어나지 않는 문제가 존재. $s_t$ : 각 매개 변수의 gradient의 누적 값

    $g_t = \nabla J(\theta_t)$ $s_t = s_{t-1} + g_t^2$ $\theta_{t+1} = \theta_t - \frac{\eta}{\sqrt{s_t + \epsilon}} g_t$

  • Adadelta : Accumulation window를 활용하여 학습률이 지속적으로 감소하는 것을 방지

    $g_t = \nabla J(\theta_t)$ $s_t = \rho s_{t-1} + (1 - \rho) g_t^2$ $\theta_{t+1} = \theta_t - \frac{\sqrt{\Delta \theta_{t-1} + \epsilon}}{\sqrt{s_t + \epsilon}} g_t $

  • RMSprop: 경험적으로 이렇게 하니깐 잘되더라~

    $g_t = \nabla J(\theta_t)$ $s_t = \rho s_{t-1} + (1 - \rho) g_t^2$ $\theta_{t+1} = \theta_t - \frac{\eta}{\sqrt{s_t + \epsilon}} g_t$

  • Adam : 모멘텀과 RMSprop을 결합하여 사용하는 최적화 알고리즘.(대체로 Adam이 성능이 잘나온다) $v_t$ : EMA of gradient squares

    $m_t = \beta_1 m_{t-1} + (1 - \beta_1) g_t$ $v_t = \beta_2 v_{t-1} + (1 - \beta_2) g_t^2$ $\hat{m}t = \frac{m_t}{1 - \beta_1^t}$ $\hat{v}_t = \frac{v_t}{1 - \beta_2^t}$ $\theta{t+1} = \theta_t - \frac{\eta}{\sqrt{\hat{v}_t} + \epsilon} \hat{m}_t$

  • AdamW : AdamW는 Adam 옵티마이저의 변형으로, 가중치 감쇠(weight decay)를 적용하여 모델의 복잡성을 제어하고, 오버피팅(overfitting)을 완화.

3. Regularization

Regularization

• Early Stopping : 학습중에 과적합이 되는 것을 방지하기 위해, Validation error가 더이상 증가하지 않는 시점에서 학습을 중지하는 기법.

• Parameter Norm Penalty : 모델의 파라미터가 너무 커지지 않도록 손실함수에 정규화 항을 추가하는 기법. 파라미터가 작은 값을 가지면 함수공간에서 더욱 부드러운 함수가 생성되어 보다 일반화 성능이 높을 것이라고 예상.

  $\text{total cost} = \text{loss(D;W)} + \lambda \sum_{i} |W_i|^2$

• Data Augmentation : 습 데이터를 다양한 방법으로 변형하여 모델의 일반화 성능을 향상시키는 기법.

• Noise Robustness : 모델이 입력 데이터에 포함된 노이즈에 강건하게 대응할 수 있도록 학습하는 기법. input 뿐만 아니라 학습 중간에 모델의 가중치에도 노이즈를 적용할 수 있음.

• Label Smoothing : 모델이 과적합되거나 너무 확신하지 않도록 하기 위해 정답 라벨에 소프트 업데이트를 적용하는 기법
  • Mix up : 서로다른 레이블의 input 데이터를 섞고, label 또한 값을 섞어주는 방식
  • Cut mix : 서로다른 레이블의 input 데이터를 자르고 붙이고, label 또한 적정 비율로 섞어주는 방식

• Dropout : 학습 중에 무작위로 선택된 뉴런을 비활성화하여 모델의 과적합을 방지하는 기법

• Batch Normalization : 학습 중에 각 미니배치의 입력을 정규화하여 학습을 안정화시키고 속도를 향상시키는 기법

4. Convolutional Neural Networks

4.1 Convolutional Neural Networks

• Conv : 데이터와 필터(또는 커널) 간의 연산으로, 입력 데이터에서 유용한 정보를 추출. 필터는 작은 가중치 행렬로, 입력 데이터를 도장처럼 스캔하면서 특징을 감지.

• 모델의 parameter 계산 : Kernel W x Kernel W x input channel x output channel (input channel의 개수 만큼 동일한 크기의 kernel이 확장된다고 생각해야함. 동일한 kernel을 재사용하는 것이 아니다.)

4.2 Modern CNN

• AlexNet
  • ReLU activation : ReLU(Rectified Linear Unit) 활성화 함수가 사용. 빠르게 수렴하며, 그레디언트 소실 문제를 줄여 학습이 효과적(양수 영역에서는 y = x 형태의 선형함수의 형질을 유지하고 있기에 미분도 용이)
  • Data Augmentation
  • Dropout

• VGGNet
  • 3x3 크기의 kernel 사용 : 동일한 Receptive field를 가지게 하는 kernel 간의 비교에서, 작은 크기의 kernel을 활용하는 것이 parameter 측면에서 이득이 존재.(parameter 수의 감소로 학습이 용이 )

• GoogLeNet
  • NiN 구조 : Network 안에 Network가 있는 구조를 활용하였음
  • Inception block : 1x1 Conv Layer를 활용하여 Parameter 수를 감소시키고, 다양한 크기의 Conv Layer를 거친 정보를 취합.

• *ResNet *
  • Residual Block : Skip Connection을 이용하여 Gradient vanishing을 완화하고, 이로인해 더 깊은 Layer에 대해서 학습이 가능하게 한다. (BN은 conv 뒤에 오기도 하고, ReLU 뒤에 오기도 한다)
  • Bottlenck architecture: 1x1 layer를 활용하여 차원 축소의 효과를 발생시키고, parameter수를 감소시킨다.

• DenseNet
  • DensBlock : Resnet과 다르게 모든 선행 layer의 output을 concatenate 하여 다음 layer로 전달.(이때 concatenate 하기 때문에 output의 channel이 기하적으로 증가한다. 또한 DensBlock 내의 layer에서는 output의 크기가 모두 동일하기 때문에 concatenate 가능하다.)
  • Transition Block : Dense Block 사이을 이어주는 block으로 1x1 Conv, 2x2 AvgPooling 진행

5. Computer Vision Applications

*5.1 Semantic Segmentation *

• Semantic Segmentation : 미지를 픽셀 단위로 분할하여 각 픽셀을 해당하는 객체 또는 클래스로 할당하는 작업

• Fully Convolutional Network (FCN)
  • 기존의 네트워크는 Dense Lyaer를 거치면서 대부분의 공간정보를 손실한다. 이를 해결하기 위해 모든 layer를 Conv layer로 사용한다.
  • 이와 같이 진행하는 경우 input 이미지의 size와 상관없이 동작하며 heatmap 형식으로 결과를 도출 할 수 있음
  • Upsampling : 앞에서 추출한 feature를 바탕으로 Upsampling을 하여 기존의 이미지 크기로 복원. 이때 Deconvolution을 활용

5.2 Detection

• R-CNN
  • image input
  • Region proposals : Selective search를 활용하여 2000개의 객체 위치 제안
  • feature 계산 : 각 Region Proposal에 대한 특징값을 계산(CNN 활용)
  • 객체 분류 : SVM(Support Vector Machine)을 활용하여 객체의 클래스 분류

    🔍 Selective search : 각각의 segment로 임의 분할하고, 각각의 segment간의 유사도를 측정하여 유사한 특징을 가지는 객체끼리 같은 객체로 분류

• SPP-Net
  • Convolutional Feature Extraction: R-CNN과 다르게 Conv layer를 우선적으로 수행
  • Spatial Pyramid Pooling : 이미지의 다양한 크기의 영역에 대해 고정된 크기의 특징 벡터를 생성(spatial bins의 개수를 정하고 pooling을 진행하기에 이미지의 크기에 상관없이 고정길이 feature 추출 가능)
  • Fully Connected Layers : 위에서 생성한 feature map을 FC layer에 입력.
  • 분류 및 예측 : SVM, BBox 등 진행

• Fast R-CNN
  • Selective Search : RoI(Resion Of Interset) 추출
  • ConvNet : Conv를 통해 feature map 추출
  • RoI pooling : RoI를 projection 시켜 해당 영역의 feature map에 대해서 RoI pooling 진행
  • FC layer : FC layer를 활용하여 고정길이 vector로 변환

    RoI Pooling : Receptive field가 RoI에 맞게끔 계산하여 영역을 정하고 해당 부분에 대해서 pooling을 진행. 아래 그림에서 정중앙이 아닌 이유는 영역의 크기가 홀수 여서 버림을 진행하였기 때문!

• Faster R-CNN
  • RPN(Region Proposal Network) : 기존의 Selective Search 대신 해당 기능을 수행하는 RPN을 학습시켜 보다 빠르게 진행.

• YOLO

1.1 Pytorch

• Define and Run : 그래프를 먼저 정의 하고 실행 시점에 데이터를 feed해주는 방식. >> Tensorflow
• Define by Run : 실행을 하면서 그래프를 생성하는 방식, 디버깅에 강점이 있다. >> Pytorch
• 중요 요소 : Numpy, AutoGrad, Function

*1.2 Tensor *

• 다차원 Array를 표현하는 Pytorch의 클래스로 사실상 Numpy의 ndarray와 동일하다.
• torch.tensor(list) 혹은 torch.from_numpy(ndarray)를 활용하여 생성할 수 있음
• torch.ones_like(), torch.flatten()등의 함수도 numpy와 동일하게 사용 가능하며, 슬라이싱도 가능하다.
• torch.to('cuda')를 활용하여 GPU에 올려서 사용가능. 단 이때 사용가능한 data type에 제한이 있다.

*1.3 Tensor()를 다루는 다양한 함수 *

• torch.view(), torch.squeeze(), torch.unsqueeze()

  import torch
  # 초기 텐서 생성
  x = torch.tensor([[1, 2, 3], [4, 5, 6]])
  # view를 사용하여 텐서의 모양 변경
  y = x.view(3, 2)  # 결과: tensor([[1, 2], [3, 4], [5, 6]])
  # 크기가 1인 차원을 가진 텐서 생성
  z = torch.randn(1, 3, 1, 4)
  # squeeze를 사용하여 크기가 1인 차원 제거
  w = z.squeeze()  # 결과: tensor([[-0.1901,  0.2942, -0.9842,  1.3037],
                 #         [ 0.4764,  0.1214,  0.8612,  0.5646],
                 #         [ 0.3986, -0.2139, -0.5733, -0.5669]])
  # 크기가 3인 차원을 가진 텐서 생성
  a = torch.tensor([1, 2, 3])
  # unsqueeze를 사용하여 인덱스 1에 차원 추가
  b = a.unsqueeze(1)  # 결과: tensor([[1], [2], [3]])

• torch.mm() : 행렬곱셈을 진행시켜준다. 단 torch.matmul 또한 행렬의 곱셈을 지원하지만, broadcasting 기능이 지원되기 때문에 명확하게 이해하고 사용하지 않으면 문제가 발생할 수 있음

1.4 torch.reshape vs torch.view()

• view 함수의 경우 텐서 내부 데이터를 공유하여 모양을 변경하기 때문에, 새로운 텐서는원래 텐서와 데이터를 공유하게 되며, 연속적인 메모리에 할당된다.
• reshape의 경우 내부 데이터를 복사하여 모양을 변경하며, 연속적인 메모리 공간을 보장하지 않는다.

1.5 Autograd Autograd는 PyTorch에서 제공하는 자동 미분 기능을 담당하는 패키지이다. PyTorch는 딥러닝 모델을 학습시키기 위해 역전파 알고리즘을 사용하는데, 이때 모델의 파라미터에 대한 손실 함수의 기울기(gradient)를 계산해야 한다. Autograd는 이러한 기울기를 자동으로 계산해주는 기능을 제공하여 딥러닝 모델의 학습을 간편하게 만들어줌.

• backward() 함수를 loss를 적용하면 하위 항목들에 모두 적용 된다.

  import torch
  from torch.autograd import Variable
  x = Variable(torch.Tensor([2]), requires_grad=True)
  y = x ** 2 + 3
  loss = 10 - y
  loss.backward()
  print(x.grad)
  # x.grad 값이 자동으로 계산되어 있다
  
  
  

2. Pytorch Templete

항상 하나의 주피터 노트북에서 학습하는 것은 한계가 있다.(배포의 어려움과, 실행 순서에 따른 결과가 상이해 질 수 있음) 언젠가는 OOP의 구조로 모델을 구성해야하는 시점이 온다. 이를 위해서 미리 지정된 Teamplete을 활용하여 보다 편리하게 개발을 진행할 수 있다. 프로젝트는 아래와 같은 구조를 가지게 된다.

pytorch-template/
│
├── train.py - main script to start training
├── test.py - evaluation of trained model
│
├── config.json - holds configuration for training
├── parse_config.py - class to handle config file and cli options
│
├── new_project.py - initialize new project with template files
│
├── base/ - abstract base classes
│   ├── base_data_loader.py
│   ├── base_model.py
│   └── base_trainer.py
│
├── data_loader/ - anything about data loading goes here
│   └── data_loaders.py
│
├── data/ - default directory for storing input data
│
├── model/ - models, losses, and metrics
│   ├── model.py
│   ├── metric.py
│   └── loss.py
│
├── saved/
│   ├── models/ - trained models are saved here
│   └── log/ - default logdir for tensorboard and logging output
│
├── trainer/ - trainers
│   └── trainer.py
│
├── logger/ - module for tensorboard visualization and logging
│   ├── visualization.py
│   ├── logger.py
│   └── logger_config.json
│  
└── utils/ - small utility functions
    ├── util.py
    └── ...

3. torch.nn.Module

3.1 torch.nn.Moudle 이란? 신경망 모델을 정의할 때 사용되는 기본 클래스. torch.nn.Module을 상속하는 클래스는 다양한 신경망 계층(layer) 및 다른 모듈들을 포함할 수 있다. 이를 통해 복잡한 모델을 구축할 수 있고, 각 계층의 파라미터들은 모델 내에서 자동으로 추적되어 역전파를 통한 학습이 가능해짐.

3.2 nn.Paramerter()

• 모듈의 attributre가 될 수 있고, required_grad = True로 지정되어 학습 대상이 되는 Tensor. Tensor를 상속해서 구현한다.

3.3 foward()

• 모델이 입력 데이터를 받아 순전파(forward pass) 연산을 수행하는 곳으로, 모델의 아키텍처를 정의하는 부분
• 해당 함수가 baward pass를 진행시킬 수 있게금 방향을 제시해준다.

3.4 backward()

• PyTorch에서 자동 미분을 수행하는 데 사용되는 메서드로, 주로 손실 함수를 통한 역전파(backward propagation) 단계에서 호출. 역전파는 모델의 파라미터에 대한 손실 함수의 기울기(gradient)를 계산하고, 이를 사용하여 모델의 파라미터를 업데이트하는 데 사용.
• 해당 함수를 호출하면 계산은 되지만, Update 되지는 않는다.

3.5 optimizer.step()

• 모델 파라미터 업데이트 할 때 사용

4. Dataset & Dataloaders

4.1 Dataset 데이터 입력 형태를 정의하는 클래스로, init(), len(), getitem() 등을 반드시 재정의 해주어야 한다.

4.2 DataLoader

• Data의 Batch를 생성해주는 클래스로, 학습 직전에 데이터 변환을 책임진다.
• 주요 역할 : Tensor로 변환, Batch 처리
• iterable 형태로 돌려주기 때문에, 데이터가 크더라도 필요할 때만 불러오기 때문에 batch 사이즈만큼의 메모리 공간만을 차지하게 한다.

5. Model 재활용하기

5.1 model.save()

• 학습 결과를 저장하기 위한 함수로, 형태와 파라미터(추천!)등을 저장할 수 있다.
• 요즘은 대부분 .pt 파일로 저장하는 추세

5.2 model.load_state_dict() 동일한 형태의 모델의 파라미터들을 불러와서 model에 저장 가능.

6. Monitoring

훅, 데코레이터 등

그동안 파이썬을 쓰면서도 자세하게 알지 못했던 부분을 정리하고자 한다.

1. Sequence Type

리스트, 튜플, 문자열등과 같이 값이 연속적으로 이어진 자료형을 Sequence Type이라고 하며 다음과 같은 공통 method를 사용할 수 있다.

• 인덱싱
• 복제 ([1,2,3] * 3)
• 덧셈 ([1,2,3] + [4,5,6])
• in (특정 원소가 해당 자료형 안에 존재하는지 확인)
• 이터레이션 (for loop)
• enumerate()
• zip()

Sequence vs Iterable

Iterable이 조금 더 큰 개념이다. indexing을 통해 개별 원소에 접근이 가능하다면 Sequence type이다!

2. Shallow copy 와 Deep copy

mutable 과 immutable

Mutable : 생성된 후에도 변경이 가능한 객체. 대표적으로 list, dict, set등이 있다. Immutable : 생성이후에 변경이 불가능한 객체로 수정하기 위해서는 새로운 객체를 생성(메모리 할당)해야 한다. 대표적으로 int, str, tuple 등이 있다.

# mutable
my_list = [1, 2, 3]
my_list[0] = 99  # 기존 객체를 직접 수정 가능
#immutable
a = 5
a = a + 1  # 이때 새로운 객체가 생성되어 할당됨

Shallow copy 와 Deep copy

Deep copy : 원본 객체와 복사된 객체가 서로 독립적인 객체를 참조 Shallow copy : 복사된 객체와 원본 객체가 동일한 객체를 참조 이때 immutable 객체에 대해서는 Deep copy가 발생하지만, mutable 객체에 대해서는 Shallow copy가 발생한다. 이때문에 아래와 같이 복사한 객체의 값을 바꾸면 원본 객체의 값도 변하는 문제가 발생한다.

import copy
original_list = [1, [2, 3], 4]
shallow_copied_list = copy.copy(original_list)
# 얕은 복사이므로 내부 리스트는 동일한 객체를 참조
print(original_list)            # [1, [2, 3], 4]
print(shallow_copied_list)      # [1, [2, 3], 4]
# 내부 리스트의 값을 변경하면 원본과 복사된 리스트에 모두 반영
shallow_copied_list[1][0] = 99
print(original_list)            # [1, [99, 3], 4]
print(shallow_copied_list)      # [1, [99, 3], 4]

이런 문제를 해결하기 위해 copy 모듈의 deepcopy() method를 활용하여 해결 가능하다.

import copy
original_list = [1, [2, 3], 4]
deep_copied_list = copy.deepcopy(original_list)
# 깊은 복사이므로 내부 리스트도 새로운 객체를 참조
print(original_list)          # [1, [2, 3], 4]
print(deep_copied_list)        # [1, [2, 3], 4]
# 내부 리스트의 값을 변경해도 원본에만 영향을 줌
deep_copied_list[1][0] = 99
print(original_list)          # [1, [2, 3], 4]
print(deep_copied_list)        # [1, [99, 3], 4]

3.interning

-5 ~ 256까지의 작은 정수를 메모리에 미리 할당하고, 동일한 값의 작은 정수가 생성될 때 마다 미리 할당된 메모리 주소를 참조하게끔 함.

a = 10
b = 10
print(a is b)  # True, 동일한 메모리 주소를 가리킴
c = 257
d = 257
print(c is d)  # False, 서로 다른 메모리 주소를 가리킴

4.String

1) f-string

파이썬 3.6 버전부터 도입된 문자열 포매팅 방법 중 하나로, 문자열 안에 변수나 표현식을 간편하게 삽입할 수 있도록 하는 기능

# 변수값 직접 사용 
name = "Alice"
age = 25
message = f"안녕하세요, {name}님! {age}살이시네요."
# 소수점 이하 자릿수 지정
height = 175.5
message = f"키: {height:.2f}cm"
# 정렬 및 폭 지정
name = "Bob"
age = 30
height = 175.5
message = f"Name: {name:<10}, Age: {age:03d}, Height: {height:.2f}"
# 왼쪽 정렬, 총 10자리, 정수는 3자리, 소수는 2자리까지
# 빈칸 *지정, 가운데 정렬
x = 42
formatted_x = f"The answer is: {x:*^20}"

2) raw string

특수 문자(이스케이프 문자)를 해석하지 않고 그대로 텍스트로 처리

normal_string = "This is a normal string.\nThis is a new line."
print(normal_string)
# 출력:
# This is a normal string.
# This is a new line.
raw_string = r"This is a raw string.\nThis is not a new line."
print(raw_string)
# 출력:
# This is a raw string.\nThis is not a new line.

3) function type hints

함수의 매개변수와 반환 값에 대한 타입 정보를 제공하는 기능이다. Docstring으로 함수에 대한 설명, 변수 설명등을 적어 다른 개발자가 함수를 이해할 수 있도록 하는 것이 좋다.

def add_numbers(x: int, y: int) -> int:
    """
    두 정수를 더하는 함수
    Parameters:
    - x (int): 첫 번째 정수
    - y (int): 두 번째 정수
    Returns:
    int: 두 정수의 합
    """
    return x + y
# 사용 예시
result = add_numbers(5, 10)
print(result)  # 출력: 15
# 타입 오류 발생 예시
# result = add_numbers("5", "10")  # 문자열을 전달하면 타입 오류 발생

5. Pythonic Code

1. join

문자열을 '+'를 통해서 결합하는 경우 새로운 객체가 매번 생성되기 때문에 메모리를 많이 차지하게 된다. 'join' method를 사용하는 경우 보다 효율적인 처리가 가능해짐

# Using join
result = ''.join(str(i) for i in range(10000))

2. list comprehension

보다 간결하게 list를 만들어내는 기법. 미세하게 속도가 빠름!

result = [x if x % 2 == 0 else x**2 for x in range(10)]

3. enumerate

iterable 객체를 입력받아 인덱스와 값을 포함하는 enumerate객체를 returen 해준다.

fruits = ['apple', 'banana', 'cherry']
for index, value in enumerate(fruits):
    print(f"Index: {index}, Value: {value}")
#Index: 0, Value: apple
#Index: 1, Value: banana
#Index: 2, Value: cherry

4. zip

두개 이상의 iterable을 묶어주는 역할

5. map

주어진 함수를 지정된 iterable의 모든 요소에 적용하여 새로운 map 객체를 생성한다. (iterator란 iterable에서 값을 하나씩 가져오는 객체로, map을 사용해서 객체를 생성하는경우 사용시점에 값을 생성하기 때문에 메모리 효율적이다)

6. generator

yield 키워드를 활용하여 메모리에 저장하지 않는 특별한 종류의 iterator를 생성. yield를 사용하여 값을 생성하고, 일시 중단.

def even_numbers_generator(limit):
    number = 0
    while number < limit:
        yield number
        number += 2
# 제너레이터 객체 생성
even_gen = even_numbers_generator(10)
# 제너레이터를 사용하여 값 순회
for num in even_gen:
    print(num)

데이터가 커져도 다룰수 있다는 장점을 가지고 있음

7. keyword arguments

함수 호출 시 인자를 전달할 때, 각 인자의 이름을 명시적으로 지정하여 값을 전달하는 방식

8. asterisk

단순 곱셈, 제곱 연산, 가변인자 활용, unpacking 까지 다양하게 사용

• unpacking : iterable(순회 가능한) 객체에서 요소를 개별 변수로 추출

  def add_numbers(a, b, c):
    return a + b + c
  numbers = [1, 2, 3]
  # Unpacking 함수 인자
  result = add_numbers(*numbers)
  print("Result:", result)

6.OOP

• OOP는 클래스와 실제 구현인 Instance로 구성된다.

• Inheritance : 클래스 간에 코드를 재사용하는 메커니즘을 제공
• Polymorphism : 동일한 인터페이스를 사용하여 여러 객체 타입을 처리할 수 있는 능력으로 주로 메서드 오버라이딩과 관련
• Visibility : 객체의 속성이나 메서드에 대한 접근 권한을 제어하는 것
  • public: 어떠한 제한도 없음.
  • _protected: 클래스 자체 및 해당 클래스를 상속받은 클래스에서 접근 가능.
  • __private: 해당 클래스에서만 접근 가능.
• Decorate : 함수를 받아 일부 작업을 수행한 후 해당 함수를 반환하는 함수

  def trace(func):                             # 호출할 함수를 매개변수로 받음
    def wrapper():
        print(func.__name__, '함수 시작')    # __name__으로 함수 이름 출력
        func()                               # 매개변수로 받은 함수를 호출
        print(func.__name__, '함수 끝')
    return wrapper                           # wrapper 함수 반환
  @trace    # @데코레이터
  def hello():
    print('hello')
  @trace    # @데코레이터
  def world():
    print('world')
  hello()    # 함수를 그대로 호출
  world()    # 함수를 그대로 호출

7.정규식

문자열의 검색, 매칭, 교체 등의 작업을 수행하는데 사용되는 강력한 도구

• 문자 클래스 ([ ]): 괄호 안에 들어가는 문자 중 하나와 매치.
• 마침표(.): 어떤 한 문자와 매치됩니다. 단, 새 줄 문자(\n)는 제외됩니다.
• 반복 (*, +, ?):
  • *: 0번 이상 반복
  • +: 1번 이상 반복
  • ?: 0번 또는 1번 반복
• 메타문자(^, $):
  • ^: 문자열의 시작과 매치
  • $: 문자열의 끝과 매치

8. JSON

9. Pandas

10. Numpy

$Ax = 0$ 의 형태를 가진 선형방정식

• Homogeneous System은 자유변수가 존재하면 Non Trivial Solution을 갖는다 == (자유변수가 존재한다 == Pivot 컬럼이 아닌 컬럼이 존재한다.)

Parametric Vector Form

아래와 같은 형태를 Parametric Vector Form이라고 한다.

Solution Set

$Ax = 0$를 만족하는 모든 x의 집합

• 결국 Solution Set은 특정 값 b를 찾기 위한 기저백터들의 계수 집합이라고 생각하면 편하다.
• Tall Matrix(M > N) 라고 하더라도 Pivot컬럼이 아닌 컬럼이 존재하면 무한해를 가지게 됨
• $R^n$

Column Span

$Ax = b$ 에서 가능한 모든 b의 집합

• $R^m$

Inhomogeneous System

$Ax = b$ 의 형태를 가진 선형방정식

• 기존의 Homogeneous System의 Solution Set에서 b 만큼 평행이동한 Span 영역이 해가 된다.

반드시 Matrix의 열의 수와 Vector의 행의 수가 일치해야 곱할 수 있음

Matrix Equation

$x_{1}v_{1} + x_{2}v_{2} + ... + x_{p}v_{p} = b$ 해당 식을 $Ax = b$와 같이 표현할 수 있고 이를 Matrix Equation이라고 한다.

지금까지 배운것을 정리해보면 우리는 아래와 같이 동일한 식을 표현할 수 있고, 이때의 해는 모두 동일하다.

1. System of Equation
2. Augmented Equation
3. Vector Equation
4. Matrix Equation

행백터로의 표현

동일한 식을 다음과 같이 두가지 관점에서 바라볼 수 있다.

Spans and Solution of Equations

$Ax = b$가 해를 가지고 있다 >> b는 A를 구성하는 columns에 의해 Span된다.

예시 링크

When Solutions Always Exist

Non-Augmented $m$ x $n$ Matrix $A$에 대하여 아래의 조건을 만족하면 항상 해가 존재한다.

1. $Ax = b$가 $R^m$에 존재하는 모든 b에 대해 해가 존재할 때
2. $A$의 Span이 $R^m$인 경우
3. 모든 행에 pivot이 존재하는 경우

3번식의 경우, A를 Augmented 시키더라도 마지막 행이 Pivot column이 될 수 없기 때문에 만족한다.

Properties of the Matrix - Vector Product

선형성에 의거하여, $Ax=0$를 만족하는 벡터 {$u$,$v$}를 구한경우 $Ax = 0$의 solution set은 반드시 Span이다.

우리는 위의 $x_{1}v_{1} + x_{2}v_{2} + ... + x_{p}v_{p}$ (Linear combinations of vectors == vector equations)를 아래의 Augmented matrices로 표현하는 것도 가능하다.

예시 : 2개의 3차원 백터의 올바른 계수를 찾는 과정

Span

Span은 $x_{1}v_{1} + x_{2}v_{2} + ... + x_{p}v_{p} = b$ 에서 임의의 $x_{1},x_{2},...x_{p}$ 로 생성할 수 있는 모든 $b$의 집합을 의미한다.

이를 수식으로 표현하면 다음과 같다

$Span{v_{1},v_{2},...v_{p}} = {x_{1}v_{1} + x_{2}v_{2} + ... + x_{p}v_{p};|;x_{1},x_{2},...x_{p} ; in ; R }$

이를 다르게 표현하면 $Span{v_{1},v_{2},...v_{p}}$ 이 $x_{1},x_{2},...x_{p}$ 에 의해서 Spanned by 혹은 generated by 라고 표현할수 있다.

따라서 vector $b$가 $x_{1}v_{1} + x_{2}v_{2} + ... + x_{p}v_{p}$ 의 Span에 포함된다면, 해당 벡터 방정식은 해가 존재한다.

위 그림의 1,2,3 번은 모두 동치이다.(하나 틀리면 다 틀리고 하나 맞으면 다 맞음)

※ 편하게 생각하면 Span이란 선형결합으로 표현 가능한 모든 백터의 값들이다.

Summary

Vector : Element of $R^N$, drawn as an arrow

우리는 백터끼리 더하고, scalr배 해줄수 있다.

Linear Combinations

$$ W = c_{1}v_{1} + c_{2}v_{2} + ... + c_{p}v_{p} $$

$W$ = Linear combintation of vectors $v_{1}$, $v_{2}$ ... $v_{p}$.

이때 $c_{1}$, $c_{2}$ ... $c_{p}$는 weight 혹은 coefficients(계수) 라고 한다.

RREF 형태의 Consistent한 Matrix A에 대해 pivot cloumn이 아닌 column에 대응하는 변수를 자유변수라고 한다.

1. You can choose any value for the free variables in a (consistent) linear system.
2. Free variable come from column without pivots in a matrix in row echelon form

아래와 같은 형태로 나타내는 것을 parametric form(일반해의 매개화된 형태)라고 한다.

RREF의 세가지 가능성

1. The last column is a pivot column

해가 없다

2. Every column except the last column is a pivot column

유일해를 가지게 됨

3. The last column is not a pivot column, and some other column isn't either

무수히 많은 해를 가지게 되며, 자유변수를 가진다.

Summary