[UNITY]알쓸유잡 : 프로그래밍💻디자인패턴 1부

https://www.youtube.com/watch?v=iyeRmq24HVk

1. 📊 '알쓸유잡': 프로그래밍 디자인 패턴의 중요성과 활용

• 5월의 새로운 프로그램으로 그래픽에서 프로그래밍으로 주제가 전환되어 디자인 패턴을 다루게 되었다.

• 디자인 패턴은 스파게티 코드를 방지하고 모듈식으로 이해하기 쉬운 코드를 작성할 수 있게 하는 프로그래밍 방법론이다.

• 유니티 엔진은 디자인 패턴을 기반으로 설계되어 있으며, 프로그래밍 디자인 패턴을 이해하면 효율적인 코드 작성과 유지보수가 용이해질 수 있다.

• SOLID 원칙과 다양한 패턴(ex. 싱글턴, 팩토리 패턴)을 통해, 주로 사례로 많이 쓰이는 프로그래밍 디자인을 소개할 계획이다.

• 디자인 패턴은 기본적으로 소프트웨어 개발에서 발생하는 공통적인 문제를 해결하는 솔루션으로, 기타 패턴들과 함께 프로그래머 간의 원활한 커뮤니케이션 수단으로도 활용된다.

1.1. 프로그래밍 및 디자인 패턴 소개

• 5월부터 새로운 주제로 프로그래밍 분야의 디자인 패턴을 다룬다. 이는 기존의 그래픽 최적화 내용에서 변화된 것이다.

• 프로그래밍에서 스파게티 코드를 피하기 위해 최소한의 규칙을 유지하고 모듈화를 통해 이해하기 쉽고 기능 추가가 용이한 구조가 필요하다.

• 개발자는 다양한 패턴을 익혀야 하며, 유니티와 같은 게임 개발 환경에 적용 가능한 패턴에 대한 이해가 중요하다.

• 유니티에서는 다른 게임 엔진과의 연계가 가능한 유니티 클라우드 서비스를 통해 멀티플레이어 및 광고 등 다양한 기능을 지원하고 있다.

• 이번 방송은 프로그래밍과 디자인 패턴에 대한 내용을 기록하고 있으며, 향후 많은 도움이 될 수 있는 정보로 제공될 예정이다.

1.2. 디자인 패턴 소개 및 학습 계획

• 이번 프로그램에서는 디자인 패턴을 다룰 예정이며, 심도 깊은 설명은 없지만 기초적인 내용에 주력할 예정이다.

• 기존 그래픽 퍼포먼스 최적화에서 프로그래밍 계열로 방향을 전환하며 새로운 내용을 심도 있게 탐구할 계획이다.

• 이번 시간에는 싱글턴 패턴, 다음 달에는 커맨드, 스테이트, 옵저버 패턴 등 여러 디자인 패턴을 순차적으로 학습할 예정이다.

• 프로그램의 목표는 깔끔한 로직을 위한 유지보수 용이성을 높이기 위해 디자인 패턴을 조기에 학습하는 것이라고 강조한다.

• 디자인 패턴에 대한 이론 외에도 실제 데모와 함께 제공되어, 이론적으로만 배우는 것보다 이해가 더 잘 될 것이라고 언급한다.

1.3. ️ 프로그래밍 디자인 패턴 개요

• 프로그래밍에서의 디자인 패턴은 소프트웨어 개발 문제를 해결하는 재사용 가능한 방식이다.

• 디자인 패턴은 공통적으로 발생하는 문제에 대한 솔루션으로 이해하는 것이 더 적합하다.

• 디자인 패턴은 오랜 프로그래밍 역사을 반영하며, 특정 문제를 해결하기 위한 체계화된 이론이라고 볼 수 있다.

• 초심자나 신입 개발자에게 특히 도움이 되며, 디자인 패턴은 코딩 테스트와 이직 준비 시 중요한 질문 항목 중 하나이다.

• 디자인 패턴을 활용하면 깔끔한 코드 작성이 가능해져, 단순한 코더에서 한 단계 높은 프로그래머로 성장할 수 있는 발판이 된다.

1.4. 디자인 패턴의 중요성과 활용

• 객체지향 프로그래밍(OOP)은 디자인 패턴을 통해 깔끔한 구조를 만들고, 학습 자료로 활용될 수 있다.

• 디자인 패턴은 프로그래머들 간의 효율적인 커뮤니케이션 수단이 되며, 특정 패턴을 언급하면 대화가 간결해진다.

• 디자인 패턴을 반드시 이용해야 한다는 강박관념은 필요 없으며, 필요에 따라 적절히 활용하면 된다.

• 디자인 패턴은 마치 도구처럼 필요할 때만 사용하고, 간단한 솔루션에는 복잡한 패턴을 적용할 필요가 없다.

• 여러 엔진과 프레임워크에서 이미 다양한 디자인 패턴이 활용되고 있으며, 유니티에서도 그러한 관점이 적용된다.

1.5. 컴퍼넌트 패턴의 이해와 유니티의 적용

• 유니티에서 오브젝트를 만들 때 렌더링을 담당하는 매시 랜더, 사운드를 출력하는 오디오 소스, 그리고 바퀴 움직임 및 이펙트를 적용하기 위한 스크립트를 조합하여 사용한다.

• 이러한 조합 방식이 컴퍼넌트 패턴에 해당하며, 이는 유니티 엔진 자체에 적용된 기본 원칙이다.

• 유니티 이전에도 게임 개발에서 컴퍼넌트 패턴을 사용했지만, 그 당시에는 이를 코드로 직접 연결하는 방식이었고 이는 상대적으로 더 복잡하고 힘들었다.

• 유니티 엔진은 이러한 디자인 패턴을 기반으로 만들어진 엔진이며, 모든 게임 엔진도 유사한 방식으로 디자인 패턴이 적용된다.

• 따라서 디자인 패턴에 대한 이해는 프로그래밍 및 게임 개발에 있어 유용하다고 할 수 있다.

1.6. 디자인 패턴의 기초와 역사

• 디자인 패턴은 고프라라는 네 명의 구루에서 출발한 개념이다.

• 디자인 패턴에 관한 서적은 헤드 퍼스트 등 다양한 출처에서 출간되었으며, 여러 프로그래밍 언어를 다룬 책도 존재한다.

• 디자인 패턴의 역사는 오래되었으며, 시간에 따라 그 수가 증가하였지만 모든 패턴을 배울 필요는 없다.

• 기본적인 패턴을 위주로 학습하되, 추가적인 질문이 있을 경우 나중에 스스로 학습하는 방법이 권장된다.

 

2. 💡 SOLID 원칙과 디자인 패턴의 관계

• SOLID 원칙은 소프트웨어 개발에 있어 코드의 가독성, 유지보수성, 재사용성을 높이기 위한 다섯 가지 원칙으로 구성되어 있다.

• 단일 책임 원칙(Single Responsibility Principle)은 각 클래스가 하나의 책임만 가져야 하며, 이를 통해 코드의 가독성과 확장성이 향상된다.

• 개방 폐쇄 원칙(Open/Closed Principle)은 기존 동작은 변경하지 않으면서 새로운 기능을 추가할 수 있어야 하며, 이를 위해 상속을 활용한다.

• 리스코프 치환 원칙(Liskov Substitution Principle)은 하위 클래스가 부모 클래스의 방향성을 지켜야 하며, 그에 따라 기능 추가가 가능해야 한다.

• 인터페이스 분리 원칙(Interface Segregation Principle)은 클라이언트가 사용하지 않는 메서드에 의존하지 않아야 하며, 인터페이스를 작게 나누어 사용해야 한다.

• 의존 역전 원칙(Dependency Inversion Principle)은 상위 모듈이 하위 모듈을 직접 참조하지 않도록 하여, 추상화를 통해 상호작용하게 해야 한다.

• 이러한 SOLID 원칙들은 디자인 패턴과 밀접하게 연결되어 있으며, 디자인 패턴을 적용할 때 자연스럽게 SOLID 원칙들을 준수하는 방향으로 개발하게 된다.

2.1. SOLID 원칙 소개

• SOLID 원칙은 프로그래밍에서 코드의 유지보수성과 깔끔함을 높이기 위한 기본적인 원칙이다.

• 프로그래밍 뿐만 아니라 모든 소프트웨어에 적용되는 원칙으로, 원리와 원칙을 중요시하는 것이 기초가 된다.

• SOLID라는 용어는 다섯 가지 원칙의 약자로, 각각의 원칙은 단일 책임 원칙, 개방 폐쇄 원칙, 리스코프 치환 원칙, 인터페이스 분리 원칙, 의존성 역전 원칙이다.

• 이 원칙들은 프로그래밍을 하는 데 있어 강박관념 없이 유용하게 활용될 수 있으며, 코드의 질을 향상시키는 데 기여한다.

• 다섯 가지 원칙의 중요성을 강조하며, 특히 자세히 설명할 필요가 있다고 언급한다.

2.2. 단일 책임 원칙(SRP)의 중요성

• 단일 책임 원칙은 모든 클래스가 하나의 책임만 가지며, 각 책임을 캡슐화해야 한다는 원칙이다.

• 모든 클래스의 기능은 책임하에 부합해야 하며, 클래스가 행동하는 것이 제한적이기 때문에 가독성이 좋아진다.

• 짧은 클래스 구조는 확장성과 재사용성을 향상시켜준다.

• 예를 들어, 플레이어 클래스를 단일 책임 원칙에 따라 나누면, 팀장에게 코드 리뷰를 요청할 때 더 편리한 결과를 만들어낼 수 있다.

• 클래스를 의존하거나 사용하는 개념으로 나누게 되면, 다양한 상황에서 재활용할 수 있게 된다.

2.3. 개방 폐쇄 원칙 (Open-Closed Principle)

• 개방 폐쇄 원칙은 모듈이 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다는 개념이다.

• 모듈의 확장은 주로 상속을 통해 이루어지며, 필요한 기능을 추가할 수 있다.

• 기존 코드를 수정하지 않고도 새로운 기능이나 행동을 추가할 수 있어야 하며, 이는 라이브러리에서 잘 지켜진다.

• 예를 들어, 도형의 부피를 계산하는 프로그램에서, 새로운 도형이 추가될 때마다 수정할 필요 없이 상속을 통해 확장할 수 있다.

• 이 원칙은 복잡한 문제 상황에서도 유용하게 적용될 수 있으며, 객체지향 프로그래밍에서 자주 언급되는 주제이다.

2.4. 리스코프 치환 원칙 및 인터페이스의 중요성

• 리스코프 치환 원칙은 파생 클래스가 기본 클래스를 대체할 수 있어야 한다는 원칙으로, 상속받은 클래스는 부모 클래스의 방향성을 존중해야 한다.

• 하위 클래스에서 기능을 제거하거나 무효화할 경우, 이는 리스코프 치환 원칙에 위배되며 불필요한 복잡성을 초래할 수 있다.

• 상속보다는 구성에 초점을 맞추는 것이 중요하며, 클래스의 계층 구조가 현실과 항상 일치하지는 않는다.

• 자동차와 기차는 둘 다 비클의 하위 클래스이지만, 실제 구현에서 각 클래스의 기능은 다르며, 이로 인해 상속보다는 인터페이스를 통한 분리가 필요하다.

• 인터페이스는 역할에 따라 나눠져야 하며, 이를 통해 유연한 조합이 가능하고 다양한 기능적인 확장성을 제공할 수 있다.

2.5. 인터페이스 분할 원칙

• 인터페이스 분할 원칙은 클라이언트가 사용하지 않는 메서드에 의존하지 말라는 원칙이다.

• 이 원칙을 통해 큰 덩어리의 인터페이스를 작게 쪼개므로, 필요한 것만 활용할 수 있게 된다.

• 시스템의 내부 의존성이 약화되며, 이로 인해 유연성과 확장성이 강화된다.

• 예를 들어, 유닛을 만든다면 체력, 방어력, 데미지 같은 기능을 각각의 인터페이스로 나누는 것이 바람직하다.

• 인터페이스를 너무 잘게 자르지 말고, 적당한 선에서 작게 분리하여 사용해야 한다.

2.6. 의존 역전의 원칙과 소프트웨어 모듈화

• 의존 역전의 원칙은 상위 모듈이 하위 모듈에 직접 의존하지 않고, 추상화를 통해 의존해야 한다는 원칙이다.

• 클래스 간의 직접적인 의존성은 커플링을 증가시켜, 수정할 때 많은 부작용을 발생시킬 수 있다.

• 종속성이 증가할수록 클래스는 서로 강하게 결합되어 있어 유지보수가 어려워지는 위험이 있다.

• 예를 들어, 스위치와 도어의 관계를 통해 의존성이 발생하면, 도어가 아닌 다른 기믹을 추가할 때마다 스위치를 수정해야 하므로, 인터페이스를 통해 추상화하여 이런 문제를 해결해야 한다.

• 인터페이스를 사용하여 클래스들이 독립적으로 작업할 수 있도록 하면, 새로운 기믹이 추가되어도 스위치는 영향을 받지 않게 된다.

2.7. ️ 추상 클래스와 인터페이스의 차이점

• 추상 클래스는 메소드를 완전히 구현하거나 일부만 구현할 수 있으며, 필드와 스태틱 멤버를 가질 수 있다. 반면, 인터페이스는 선언만 가능하고 직접 구현은 불가능하다.

• 추상 클래스는 모든 엑세스 한정자를 사용할 수 있지만, 인터페이스는 모든 메소드가 공개되어야 한다. 따라서 인터페이스는 틀만 제공하는 구조로 볼 수 있다.

• C++ 언어는 다중 상속을 허용하기 때문에 여러 클래스를 한 번에 상속받을 수 있지만, C#은 다중 상속이 불가능해 인터페이스를 사용해야 한다.

• 다이아몬드 상속 문제는 C++에서 발생할 수 있으며, 이로 인해 솔리드 원칙을 위배하는 코드가 생성될 수 있다. 그래서 C#은 다중 상속을 아예 금지하였다.

• 유니티 엔진은 솔리드 원칙을 준수하며 여러 인터페이스를 사용해 각 기능을 세분화하여 구현하고 있다.

2.8. SOLID 원칙과 디자인 패턴

• SOLID 원칙은 소프트웨어 설계에서의 기본 원칙으로, 각 클래스는 단일 책임을 가져야 하고, 수정이 필요한 경우는 하나의 사유에서 이루어져야 한다.

• 개방-폐쇄 원칙은 이미 작동 중인 기능을 변경하지 않고도 새 기능을 추가할 수 있어야 한다.

• 리스코프 치환 원칙에 따르면 하위 클래스는 기본 클래스를 대체할 수 있어야 하며, 기본 클래스의 방향성을 유지해야 한다.

• 인터페이스 분리 원칙은 인터페이스를 작게 유지해야 하며, 클라이언트는 필요한 부분만 구현해야 한다.

• 의존 역전 원칙에서는 구체 클래스 간의 직접 참조를 피하고, 추상화된 구조를 통해 소통해야 한다.

• SOLID 원칙을 준수하면 디자인 패턴을 적용할 수 있으며, 이는 서로 밀접한 관계에 있다.

 

3. 🏭 팩토리 패턴의 이해

• 팩토리 패턴은 객체를 생성하기 위한 디자인 패턴으로, 구체적인 객체 생성 로직을 캡슐화하여 클라이언트 코드가 변경되지 않고 새로운 객체를 생산하도록 돕는다.

• 게임 아이템 관리를 위해선 아이템 매니저에서 팩토리 패턴을 사용하여 다양한 아이템을 효율적으로 관리할 수 있다.

• 이 패턴을 사용하면 확장성이 높아져서 새 아이템을 추가할 때 아이템 매니저를 변경할 필요 없이 팩토리만 수정하면 된다.

• 팩토리 패턴은 지키기 쉬운 오픈-클로즈 원칙을 따르며, 프로덕트 클래스와 팩토리 클래스를 통해 응집력 있는 코드를 작성할 수 있다.

• 구체적인 팩토리 클래스를 만들어 자식 클래스에서 필요에 따라 프로덕트를 간편하게 생성할 수 있게 해준다.

• 🗃️ 오브젝트 풀의 활용

  • 오브젝트 풀은 메모리 사용 최적화를 위해 사전에 생성된 객체를 재사용하는 패턴으로, 게임의 성능을 향상시킨다.

  • 이 패턴을 사용하면 게임 내에서 객체 생성을 반복하는 것보다 미리 만든 객체를 활성화하고 비활성화하는 과정이 많아져 성능 저하를 방지할 수 있다.

  • 유니티 2021버전부터는 오브젝트 풀을 관리하는 API가 추가되어 쉽게 객체를 관리하고 성능 개선을 도모할 수 있게 되었다.

  • 오브젝트 풀은 메모리 및 가비지 컬렉션 문제를 해결하기 위해 초기화된 객체를 활용하여 생성과 파괴를 최소화하도록 설계되었다.

  • 게임에서 일반적으로 사용되는 오브젝트 풀을 통해 총알, 몬스터 등 다양한 객체를 효율적으로 처리하는 것이 가능하다.

• 🧭 싱글턴 패턴의 역할

  • 싱글턴 패턴은 특정 클래스에 대해 오직 하나의 인스턴스만 생성되게 하고, 전역 접근을 제공하는 패턴이다.

  • 주로 게임 매니저나 UI 관리와 같이 전역적으로 접근해야 하는 객체를 생성하는 데 유용하다.

  • 그러나 싱글턴 패턴은 안티 패턴으로 평가되기도 하는데, 이는 전역 상태를 가지게 하여 코드 간의 의존성이 증가할 수 있기 때문이다.

  • 멀티스레드 환경에서는 싱글턴 접근 시 동시 생성의 위험이 있기 때문에 락을 이용하여 스레드 안전성을 확보해야 한다.

  • 최적화를 위해 싱글턴의 초기화를 지연하는 방식 대신, 스태틱 초기화를 사용하여 멀티스레드 상황에서의 안전성을 높일 수 있다.

3.1. 팩토리 패턴 개요

• 팩토리 패턴은 객체를 생성하기 위한 디자인 패턴으로, 객체의 생성 로직을 다른 클래스에 위임하는 구조이다.

• 이 패턴은 다양한 아이템을 생성하는 경우, 각 아이템의 자세한 생성 사항을 팩토리에 맡기도록 하여 아이템 매니저에서의 유지보수를 간편하게 해준다.

• 팩토리를 이용해 객체를 생성하면, 오픈 클로즈 원칙을 적용하여 기능 확장이 용이해진다.

• 객체 생성 시 객체의 세부사항을 캡슐화하고 추상화에 의존하게 되어, 세부정보의 변경 없이도 객체 생성을 관리할 수 있다.

• 이 방식은 수정과 확장을 쉽게 하여, 팀장이나 개발자에게 더 나은 유연성을 제공할 수 있도록 돕는다.

3.2. ️ 팩토리 패턴과 오브젝트 풀 패턴

• 팩토리 패턴은 객체 생성을 위한 디자인 패턴으로, 팩토리 메서드와 추상 팩토리로 분류된다. 그러나 경계가 모호해 구분의 필요성에 대해 의문이 제기된다.

• 예시로 든 것이 팩토리 메서드 패턴에 가까운 방식이며, 게임에서는 더 복잡한 구현이 필요할 수 있다.

• 키-값 쌍을 이용한 딕셔너리를 활용하면 다양한 아이템(예: 다양한 종류의 칼)의 생성이 용이해진다.

• 오브젝트 풀 패턴은 여러 개의 오브젝트를 미리 생성해 놓고 필요한 만큼 꺼내 사용하는 개념으로, 리소스를 효율적으로 관리하는 데 도움을 준다.

• 디자인 패턴은 시간이 지나면서 언어 발전과 함께 구현 방법이 다양해지고 있으며, 이러한 경향은 오브젝트 풀 패턴에서도 나타난다.

3.3. 오브젝트 풀의 개념과 활용

• 오브젝트 풀은 미리 초기화된 인스턴스를 보유하고, 필요할 때마다 이 인스턴스를 반환하여 사용하는 패턴이다.

• 오브젝트를 빈번히 생성하고 소멸시키면 가비지가 급증하여 렉 현상이 발생할 수 있는데, 이를 방지하기 위해 오브젝트 풀이 도입되었다.

• 이 개념은 주로 로딩 과정에서 활용되며, 런타임 중 활성화 및 비활성화를 반복함으로써 가비지 생성량을 줄이는 방식이다.

• 유니티 2021버전부터는 오브젝트 풀 관련 API가 추가되어, 효율적인 오브젝트 관리가 가능해졌다.

• 예제 코드에서는 개체를 오브젝트 풀에서 꺼내 사용하는 방식이 설명되며, 이는 유니티에서 제공하는 자료에 기반한다.

3.4. 오브젝트 풀의 개념과 구현

• 오브젝트 풀은 오브젝트를 미리 생성하고 관리할 수 있는 방식으로, 예를 들어 풀 사이즈를 설정 후 필요한 만큼 인스턴스를 만드는 방식이다.

• 풀에서 오브젝트를 꺼내거나 넣을 때는 활성화와 비활성화를 통해 상태를 관리하며, 사용하지 않을 경우에는 자동으로 비활성화된다.

• 게임에서는 메모리 할당과 해제를 줄이기 위해 오브젝트 풀을 많이 사용하며, 특히 액션, RPG, 퍼즐 게임에서 자주 활용된다.

• 유니티에서는 오브젝트 풀을 구현하기 위한 API를 제공하여, 오브젝트 풀링을 간편하게 사용할 수 있도록 지원하고 있다.

• API는 인터페이스를 제공하지만, 이를 통해 정확한 사용법을 이해하고 구현할 필요가 있어 코딩 방식이 조금 더 편해지는 장점이 있다.

3.5. ️ 오브젝트 풀 구현 및 최적화 기법

• 오브젝트 풀을 생성할 때 여러 인자를 넘겨주고, 이는 대체로 초기화 과정에 해당한다.

• 오브젝트 풀의 구현은 직접 코딩해야 하며, 이를 통해 구현이 편리해졌다는 점에서 도움을 준다.

• 최적화 기법의 일환으로 오브젝트를 준비된 상태에서 꺼내고, 다시 넣는 방식을 사용하여 성능을 향상시키는 방식이다.

• 오브젝트 풀은 전통적인 디자인 패턴과는 달리, 편의성보다는 최적화를 목적으로 한다.

• 연속 배치를 통해 메모리 효율을 증대시키는 프로세스가 필요하며, 세 부모가 빈번하게 호출될 경우 오버헤드가 발생할 수 있다.

3.6. 싱글톤 패턴의 이해와 주의점

• 싱글톤 클래스는 하나의 인스턴스만 존재하도록 설계되어, 여러 개의 인스턴스를 만들 수 없게 한다.

• 돈트 디스트로이 올 로드는 특정 객체가 신(scene) 변경 시에도 계속해서 남아 있도록 보장하는 메소드이다.

• 싱글톤은 주로 게임 매니저 클래스와 같은 관리 클래스에서 많이 활용되며, 여러 곳에서 쉽게 접근할 수 있는 전역 엑세스를 제공한다.

• 그러나 싱글톤 패턴은 안티 패턴으로 분류되는 경우가 있으며, 여러 곳에서의 접근으로 인해 의존성이 증가할 수 있다.

• 또한, 싱글톤은 생성 시점이 명확하지 않게 되어 테스트와 디버깅이 어려워질 수 있으므로, 사용 시 주의가 필요하다.

3.7. 싱글턴 패턴 구현의 핵심

• 싱글턴 구현은 간단하며, 인스턴스가 자기 자신을 정적으로 가지고 있어 여러 인스턴스가 발생해도 메모리 공간 하나만 사용된다.

• 인스턴스가 설정되지 않은 경우, 자기 자신을 설정하고 이미 존재하는 인스턴스가 있으면 나머지는 파괴하므로 유지관리가 용이하다.

• `모노비헤이비어` 기준으로 구현 시, 새로운 씬을 로드하면 게임 오브젝트가 삭제되는 문제가 있음에도 불구하고 싱글턴은 항상 유지되게 설계된다.

• 제네릭을 사용하여 다양한 종류의 싱글턴을 만들 수 있으며, 코드 중복을 줄이고 여러 매니저를 쉽게 관리할 수 있다.

• 멀티스레드 환경에서는 동시에 인스턴스를 생성할 수 있는 문제가 있어, 이를 해결하기 위해 락을 사용하여 쓰레드 세이프한 코드를 구현할 수 있다.

3.8. ️ 멀티스레드 환경에서의 싱글턴 패턴

• 인스턴스 체크를 두 번 하는 이유는 메모리 접근에서의 경쟁 조건이 발생할 수 있어 재수없는 상황을 피하기 위해서이다.

• 스레드 안전성을 보장하기 위해 '볼라틸리티' 키워드가 사용되며, 이는 멀티스레드 환경에서 메모리 접근을 안정적으로 관리하기 위한 방법이다.

• 스태틱 초기화 방식을 통해 싱글턴 인스턴스가 프로그램 시작 시 생성되므로, 잠금(lock) 처리 없이 안전한 접근이 가능하다.

• 싱글턴 패턴의 레이지 이니셜라이제이션은 필요할 때 인스턴스를 생성하는 방식을 따르지만, 이는 초기 로딩 시 복잡성을 증가시킬 수 있다.

• 멀티스레드 환경은 항상 고려해야 할 요소가 많으며, 각각의 방식에는 장단점이 존재하므로 신중한 선택이 필요하다.

 

4. 📝 싱글턴 패턴과 디자인 패턴 학습

• 싱글턴 패턴은 클래스가 자신의 인스턴스 하나만 존재할 수 있게 하는 유일무이한 존재를 만드는 개념이다.

• 다양한 부작용 때문에 싱글턴 패턴은 안티 패턴으로 간주되기도 하며, 그러므로 사용 시 주의가 필요하다.

• 디버깅과 메모리 관리에서의 문제로, 필수적인 경우에만 사용하는 것이 좋다.

• 디자인 패턴에 대한 사전 학습은 다음 기회에 다루어질 여러 개념을 위해서 중요하며, 관련 자료를 찾아보는 것이 권장된다.

• AI 도구를 활용하면 리팩토링이 용이해지고, 디자인 패턴 적용도 쉽다고 여겨진다.

4.1. 싱글턴 패턴과 디자인 패턴 관련 추천 도서

• 싱글턴 패턴은 클래스가 자신의 인스턴스 하나만 존재할 수 있도록 하는 유일한 존재를 만들어내는 개념이다.

• 하지만 부작용이 발생할 수 있어, 안티 패턴으로 취급되기도 하며, 꼭 필요한 경우에만 사용하는 것이 좋다.

• 이 패턴을 무조건 남용하면 커플링과 디버깅의 어려움이 발생하고, 메모리 문제를 일으킬 수 있다.

• 디자인 패턴에 대한 더 많은 내용은 다음 달에 다루며, 미리 예습하고 싶다면 다양한 디자인 패턴을 찾아보는 것이 좋다.

• 추천 도서로는 오래된 디자인 패턴 관련 책과 유니티 전용 디자인 패턴 책이 있으며, 가격적 부담은 적지만 내용의 분량은 고려해야 한다.

4.2. 유튜브 채널과 디자인 패턴 콘텐츠 소개

• 오늘 코딩 채널에서는 문서 기반으로 진행된 영상이 지속적으로 업로드되고 있으며, 한국어로 진행된 영상들을 찾기 어려운 현실을 반영하고 있다.

• 유니티 채널에서도 다양한 디자인 패턴과 관련된 내용을 다루는 영상이 제공되고 있으며, 커맨드 패턴과 팩토리 패턴 등이 포함되어 있다.

• 해당 영상들은 예습이나 복습을 원하는 사람들에게 유용하며, 고퀄리티의 그림을 통한 설명이 특징이다.

• 영상에는 자동 번역 기능이 있어, 한국어로도 쉽게 접근할 수 있는 점이 장점이다.

• 유니티 본사 채널 또한 디자인 패턴과 관련된 내용을 지속적으로 업데이트하고 있어, 방문 시 많은 지식을 얻을 수 있다.

4.3. ️ 디자인 패턴의 활용과 리팩토링

• 디자인 패턴을 사용할 때 샘플 코드 그대로 따를 필요는 없으며, 언어마다 세부 구현 방식이 다르기 때문이다.

• 프로그래머는 패턴 적용에 대해 강박감을 가질 필요 없이, 필요할 때 적절히 활용하면 되며, 리팩토링은 자주 이루어질 수밖에 없다.

• 실제로 코드 수정이 필요할 때에는 패치 후 안정화된 상태에서 리팩토링을 고려하는 것이 현실적이다.

• 기술 부채는 쌓일 수 있지만, 요즘 AI의 도움으로 리팩토링이 한층 쉬워졌으며, AI를 활용해 디자인 패턴을 적용할 수 있다.

• AI 도구를 사용하면서 디자인 패턴을 공부하고 적용하는 것도 효과적일 수 있으며, 리팩토링이 용이해진 점이 장점이다.

4.4. 디자인 패턴 세미나 마무리

• 이번 세미나에서는 디자인 패턴의 첫 번째 내용을 다루었으며, 다음 달에 나머지 부분을 계속 진행할 예정이다.

• SOLID 원칙의 다섯 가지는 중요하므로, 이를 잘 체득하여 개인 프로젝트에 적용할 것을 권장한다.

• 입사 시험에서 자주 출제되는 문제이므로 면접 준비 중인 사람은 반드시 숙지해야 한다.

• 포트폴리오 준비 중인 분들은 SOLID 원칙을 적용하여 점수를 높이는 데 도움이 될 것으로 보인다.

• 다음 세미나는 6월에 진행될 예정이며, 다른 디자인 패턴에 대해 공부할 계획이다.