B(class) is a A(class)

클래스 A가 서로 관련있는 클래스 B의 서브 클래스임을 의미함. 상속 관계에서 주로 사용.

class A
{
public:
    void MoveA()
    {
        printf("Move A\n");
    }
};

class B : public A
{
public:
    void MoveB()
    {
        printf("Move B\n");
    }
};

int main()
{
    B b;
    b.MoveA();

    return 0;
}

console : Move A

🚨 문제점 : 클래스 A와 클래스 B는 서로 밀접하게 결합되기 때문에 부모 클래스인 A에서 변경이 일어날 경우, 자식 클래스 B도 영향을 받을 가능성이 높다.
'고양이는 포유류이다.'와 같은 1:1 관계에서는 안전한 클래스 계층구조를 이룰 수 있지만, 빈번한 상속은 피하는 것이 좋다. 혹은 추상 클래스로 다루는 것도 한 방법이다.

🖥️ 'has-a'란?

A(class) has a B(class)

클래스 A가 서로 관련 없는 클래스 B를 가지고(포함하고) 있음을 의미.

class A
{
public:
    void Attack()
    {
        printf("A - Attack! \n");
    }
};

class B : public A
{
public:
    void UseWeapon()
    {
        Attack();
    }
};

int main()
{
    B b;
    b.UseWeapon();

    return 0;
}

console : A - Attack!

🚨 문제점 :

• Player > Enemy 피격 시, 콤보 공격할 경우 생기는 이슈
  • 한 번 피격 당했을 때는 쿨타임 후, 공격하지만 콤보 공격으로 두 번 연속 피격 당할 경우 바로 공격하는 문제.

• 이슈 해결 방법

• Impact에서 Wait으로 Transition되는 구간에서 Interruption Source - Current State로 설정했을 경우, 해결.

출처 : https://jinhomang.tistory.com/116

메모리 인터리빙(memory interleaving)은 주기억장치를 접근하는 속도를 빠르게 하는데 사용된다. 메모리 인터리빙 기법은 인접한 메모리 위치를 서로 다른 메모리 뱅크(bank)에 둠으로써 동시에 여러 곳을 접근할 수 있게 하는 것이다. 메모리 인터리빙은 블록 단위 전송이 가능하게 하므로 캐시나 기억장치와 주변장치 사이의 빠른 데이터 전송을 위한 DMA(Direct Memory Access)에서 많이 사용한다.

🎭 객체지향 5원칙 (SOLID)

1. 단일 책임 원칙(Single Responsibility Principle)
2. 개방-폐쇄 원칙(Open-Closed Principle)
3. 리스코프 치환 원칙(Liskov Substitution Principle)
4. 인터페이스 분리 원칙(Interface Segregation Principle)
5. 의존성 역전 원칙(Dependency Inversion Principle)

🎭 개방 폐쇄 원칙(OCP)란?

클래스, 모듈, 함수 등 소프트웨어 엔티티는 기존의 코드를 변경하지 않고도 새로운 기능이나 동작을 추가할 수 있어야하며, 기존의 코드는 안전하게 동작하고 있는 상태를 유지하면서 새로운 기능이나 변경이 필요한 경우에는 해당 부분만을 수정하고 나머지 코드에는 영향을 주지 않아야 한다. 즉, 확장은 개방되고, 변경에는 폐쇄되어야 한다.

객체 지향의 특징인 추상화와 다형성을 사용하면 해당 원칙을 지킬 수 있으며, 이를 주로 인터페이스(Interface)로 다룬다.

🎭 C# 예시

class Character
{
    protected string name;
    public string Name { get => name; set => name = value; } 

    public Character(string name, float hp)
    {
        //this.name = name;
        //this.hp = hp;

        Name = name;
        Hp = hp;
    }


    public override string ToString() => $"{name}, {hp}";

    public virtual void Move() //[추상성 - 가상화] 부모가 가상화 되어야 오버라이딩 가능.  키워드 : virtual
    {
        Debug.Log("Charater : 우측 방향 > 10만큼 이동");
    }
}

class Player : Character
{
    public Player()
        : base("None", -1) //base() : 부모 클래스
    {
        Debug.Log(ToString()); //부모한테 상속받음

    }

    public Player(string name, float hp)
        : base(name, hp) //base() : 부모 클래스
    {
        Debug.Log(ToString());
    }

    public override void Move() //자식의 필요에 의해서 재정의. 키워드 : override
    {
        base.Move(); //부모의 Move() 사용

        Debug.Log("Player : 전진 > 30만큼 이동");
    }
}

class Monster : Character
{
    public Monster(string name, float hp)
        :base(name, hp)
    {
        Debug.Log($"Monster  {ToString()}");
    }

    public override void Move() //Move() 재정의
    {
        Debug.Log("Monster : 후진 > 50만큼 이동");

    }
}

출처 :

• https://velog.io/@zayson/%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D%EC%9D%98-5%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99-SOLID-%EC%9B%90%EC%B9%99
• https://aspdotnet.tistory.com/3156

🎭 객체지향 5원칙 (SOLID)

1. 단일 책임 원칙(Single Responsibility Principle)
2. 개방-폐쇄 원칙(Open-Closed Principle)
3. 리스코프 치환 원칙(Liskov Substitution Principle)
4. 인터페이스 분리 원칙(Interface Segregation Principle)
5. 의존성 역전 원칙(Dependency Inversion Principle)

🎭 단일 책임 원칙(SRP)란?

간결하게 말하자면, '하나의 객체는 반드시 하나의 동작만의 책임을 갖는다'는 원칙이다.

모듈화가 강할수록 다른 객체와의 의존 및 연관성이 줄어들며 모듈화가 약할수록 다른 객체와의 의존 및 연관성이 늘어난다. 약한 모듈화는 정보 은닉화가 되지 않기 때문에 모듈의 메소드에 무분별하게 접근할 수 있게 되므로 모듈의 의존성을 지양해야한다.

모듈화가 약할 때 코드가 무분별하게 길어지거나 복잡해지면, 코드 수정할 때마다 전체적으로 대공사를 해야하는 번거로움이 생긴다. 이를 방지하기 위해 '단일 책임 원칙', 즉 객체 하나 당 책임도 하나만 줌으로써 책임을 줄여줘서 최대한 간결하게 코드 작성을 할 수 있게 해준다.

🎭 C# 예시

class Character
{
    protected string name;
    public string Name { get => name; set => name = value; } 

    public Character(string name, float hp)
    {
        //this.name = name;
        //this.hp = hp;

        Name = name;
        Hp = hp;
    }


    public override string ToString() => $"{name}, {hp}";

    public virtual void Move() //[추상성 - 가상화] 부모가 가상화 되어야 오버라이딩 가능.  키워드 : virtual
    {
        Debug.Log("Charater : 우측 방향 > 10만큼 이동");
    }
}

class Player : Character
{
    public Player()
        : base("None", -1) //base() : 부모 클래스
    {
        Debug.Log(ToString()); //부모한테 상속받음

    }

    public Player(string name, float hp)
        : base(name, hp) //base() : 부모 클래스
    {
        Debug.Log(ToString());
    }

    public override void Move() //자식의 필요에 의해서 재정의. 키워드 : override
    {
        base.Move(); //부모의 Move() 사용

        Debug.Log("Player : 전진 > 30만큼 이동");
    }
}

class Monster : Character
{
    public Monster(string name, float hp)
        :base(name, hp)
    {
        Debug.Log($"Monster  {ToString()}");
    }

    public override void Move() //Move() 재정의
    {
        Debug.Log("Monster : 후진 > 50만큼 이동");

    }
}

→ Character 클래스를 상속 받은 Player, Monster 클래스는 각자의 Move() 함수에 알맞은 동작을 구현하여 한 객체가 하나의 책임을 갖게 된다.

예를 들어 Monster의 이동에 관련하여 코드를 수정해야한다면, 부모 클래스인 Character의 코드는 변경하지 않고 해당 객체의 메소드만 수정하면 되므로 의존성이 현저히 떨어지기 때문에 올바른 모듈화가 된다.

컴파일 시 가상함수가 정의된 클래스가 있다면 가상함수테이블(Virtual function table)이 만들어져서 바이너리 'rdata'영역에 기록되며 해당 클래스로 만들어진 객체에서 함수를 호출할 때 해당 클래스의 가상함수 테이블을 참조해서 함수를 호출된다. 편의를 위해 가상함수테이블은 "vtable" 이라고 명칭한다.

예제

///// vtable(Virtual Table)
//_vfptr : virtual function pointer (배열로 구성. Key / Value)
//정적할당일 때는 부모(Base)에 할당. 동적할당일 때는 통해서 와야하기 때문에 자기자신한테 가상함수가 있는지 먼저 확인하기 위해 가상테이블이 따로 할당됨.
//C에서는 대부분 동적할당일 때만 가상화를 한다.

class Character 
{
public:
    Character(int id, string name)
    {
        this->id = id;
        this->name = name;

        printf("캐릭터 생성 %p - %s\n", this, this->name.c_str());
    }

    virtual ~Character() //가상 소멸자
    {
        printf("캐릭터 소멸 %p - %s\n", this, this->name.c_str());
    }

    virtual void Move() //가상화
    {
        printf("캐릭터 이동 %p - %s\n", this, this->name.c_str());
    }

    //순수 가상 함수(C에서는 추상클래스, 즉 추상함수의 abstract 키워드가 존재하지 않음.)
    virtual void Attack() = 0;

protected:
    int id;
    string name;
};

class Player : public Character
{
public:
    Player(int id, string name)
        : Character(id, name)
    {
        printf("플레이어 생성 %p - %s\n", this, this->name.c_str());
    }

    //C에서는 가상화를 할 때, 소멸자도 가상화를 해줘야함.
    ~Player() //override -> 안 붙여도 됨.
    {
        printf("플레이어 소멸 %p - %s\n", this, this->name.c_str());
    }

    //재정의 X. 부모의 별도 영역에 들어간 것.
    void Move() override //C는 override 안 써도 됨. 그러나 써주는게 좋음.
    {
        Character::Move(); //재정의 X

        printf("플레이어 이동 %p - %s\n", this, this->name.c_str());
    }

    void Attack() override
    {
        printf("플레이어 공격 %p - %s\n", this, this->name.c_str());
    }
};


int main()
{
    //Character character(1, "Character");

    //생성과 소멸은 역순으로(스택 때문에)
    Player player(2, "Player");
    //player.Move();

    //Character player2 = player;
    //player2.Move(); //직접 접근 : 자기가 소유하고 있는 Move()를 콜 -> Character의 Move()

    Character* player3 = new Player(3, "Player3"); //주소로 접근
    player3->Move(); //간접 접근 : Player의 Move()
    player3->Attack();
    delete player3;

    return 0;
}

출처 :

• https://pabloariasal.github.io/2017/06/10/understanding-virtual-tables/
• https://cosyp.tistory.com/228

충돌시 입사벡터가 입사면을 따라 미끄러지게 하기위해 수평성분만을 남긴 벡터이다.

위 그림에서는 벡터P 가 법선벡터 n을 가진 입사면에 충돌했을 때, 미끄러짐 벡터 S를 확인할 수 있다. 미끄러짐 벡터S는 여러 방법으로 구할 수 있지만, 반사 벡터를 이용한 방법과 일반적인 방법 총 두 방법을 확인해보자.

반사 벡터를 이용한 방법

반사 벡터에서 입사벡터 P에 n(-P·n) 을 한 번 더해주면, 입사면에 투영된 접선벡터(Tangent Vector)를 구할 수 있다. 위 그림을 보면, 입사벡터의 역벡터 -P가 n에 투영된 n(-P·n)을 이용하여 슬라이딩벡터 S를 구할 수 있다.

그러므로 미끄러짐 벡터S는 S = P + n(-P·n) 으로 구할 수 있다.

일반적인 방법

일반적인 방법은 입사벡터P 를 n에 바로 투영시키는 것이다. 입사벡터P 와 법선벡터n 의 끼인각이 0≤ θ ≤ π/2 일 때, P·n 의 값은 음수가 되므로, n벡터의 역벡터 방향으로 투영벡터가 생성된다. 이렇게 얻어진 투영벡터 n(P·n)을 입사벡터 P에서 빼주면, 미끄러짐 벡터S 를 얻을 수 있다. 그러므로 슬라이딩벡터 S 는 S = P - n(P·n)으로 구할 수 있다.

출처 :

• https://toymaker.tistory.com/entry/미끄러짐-벡터-Sliding-Vector

굴절 벡터란?

주어진 입사 벡터 A, 표면 법선 B 및 굴절률 비율(IOR)에 따라, 굴절 벡터 R을 출력한다.

• 스넬의 법칙 : 굴절의 법칙이라고도 하며, 근처의 두 매체를 통해 빛의 통과를 기술하는 법칙이다.

입사벡터 P와 법선벡터 n이 주어졌을 때, 반사벡터 R은 벡터 P와 크기가 같고, 입사각과 반사각이 같음을 확인할 수 있다. 여기서 정반사는 입사벡터와 반사벡터의 크기가 같고, 입사각과 반사각의 크기가 같은것을 말한다.

Unity : 법선에 의해 정의된 평면에서 벡터를 반사한다. 벡터 'inNormal'는 평면을 정의하며(평면의 법선은 표면에 수직인 벡터이다.), 벡터 'inDirection'는 평면으로 들어오는 방향 화살표로 처리된다. 반환된 값의 크기는 동일한 inDirection이지만, 방향이 반영된 벡터이다.

입사벡터와 법선벡터로 반사벡터를 구하는 방법

우선, 입사 벡터 P의 역벡터 -P를 n의 연장선 상에 투영시켜, 투영벡터 n(-P·n)를 구한다. 입사 벡터 P의 시작 위치를 원점에 위치시키고, 여기에 n(-P·n)를 더하면, 입사면에 투영된 벡터의 위치를 구할 수 있다.

위 그림을 보면, 입사벡터 P에 n(-P·n)를 1번 더하면, 입사면에 투영된 위치를 구할 수 있고, 2번 더하면 반사벡터 R을 구할 수 있다. 결국, 반사벡터 R은 R = P +  2n(-P·n)로 구할 수 있다.

🖥️ 유니티 활용

using UnityEngine;
using System.Collections;

public class ExampleClass : MonoBehaviour {
    public Transform originalObject;
    public Transform reflectedObject;
    void Update() {
        reflectedObject.position = Vector3.Reflect(originalObject.position, Vector3.right);
    }
}

출처 :

• https://toymaker.tistory.com/entry/반사-벡터-Reflection-Vector
• https://docs.unity3d.com/kr/530/ScriptReference/Vector3.Reflect.html

🖥️ 해시 테이블(HashTable)이란?

해시테이블은 Key-Value 형태로 저장되는 자료구조로, 평균 O(1)의 시간복잡도를 가짐. 흔히, HashMap이라고 불리기도 함. key 값을 Hash Function을 이용해, Hash Table에 저장할 위치를 정함. 대표적인 Hash Function에는 Division Method(mod 연산)가 있음.

🖥️ DAT(Direct Access Table)

키 값을 인덱스로 직접 사용하여 배치하는 자료구조이며, 빠른검색과 삽입•삭제가 가능함. 최대값에 1을 더한 크기의 배열을 만든 다음(0 기반 인덱스로 가정) 값을 인덱스로 사용함.

🖥️ 충돌은 왜 발생하는가?

해시 충돌은 어떤 entry를 넣으려고 할때, Hash Function으로 찾은 위치에 이미 다른 entry가 존재하는 경우 발생함. 즉, 다른 키 값일때, Hash Function을 통해 같은 값을 가지게 되는 경우 해시 출돌이 발생함.

🖥️ 충돌 해결방법 - 체이닝(Chaining)

• 같은 주소로 해싱 될 때, 연결 리스트(Linked List)로 연결하는 방식.
• 각 인덱스는 자체 목록이 되므로 동일한 해시 인덱스를 가진 값이 동일한 목록에 배치됨.
• 추가 공간 활용

🖥️ 충돌 해결방법 - 개방주소법

출처 :

• https://velog.io/@nayu1105/%ED%95%B4%EC%8B%9C%ED%85%8C%EC%9D%B4%EB%B8%94Hash-Table%EC%99%80-%ED%95%B4%EC%8B%9C%EC%B6%A9%EB%8F%8CHash-Collision

🖥️GUID(Globally Unique IDentifier)란?

컴퓨터 시스템에서 식별자로 사용되는 고유 참조 번호. GUID의 값은 32자의 16진수 문자열로 표현되며 모든 시간과 공간에서 고유한 번호를 가진다. 이는 유니티에서 asset을 구분하기 위해 쓰이며, 'Global UID' 이므로 한 프로젝트 내에서만 아니라, 서로 다른 프로젝트 간에서도 유일한 번호를 가진다.

🖥️ GUID의 사용

Unity에서 새 에셋을 생성할 때마다 시스템이 자동으로 에셋에 GUID를 할당한다. 이 GUID는 자산과 연결된 메타 파일에 저장되며, Unity는 이 GUID를 사용하여 프로젝트 전체에서 자산을 추적한다.

🖥️ GUID의 중요성

GUID는 프로젝트 내에서 자산이 사용되거나 이동된 위치에 관계없이 자산을 식별하고 추적할 수 있도록 유지하는 Unity에서 중요한 역할을 한다. Unity에서 GUID가 작동하는 방식을 이해하면 깨진 참조 및 병합 충돌과 같은 일반적인 위험을 방지하여 게임 개발 프로세스를 보다 원활하고 효율적으로 만들 수 있다.

출처:

• https://coding-shop.tistory.com/145 [끄적끄적 코딩 공방:티스토리]

임계 구역(critical section)은 공유변수 영역이라고도 불리며, 병렬컴퓨팅에서 둘 이상의 스레드가 동시에 접근해서는 안되는 공유 자원(자료 구조 또는 장치)을 접근하는 코드의 일부를 말한다. 임계 구역은 지정된 시간이 지난 후 종료되기 때문에 어떤 스레드(태스크 또는 프로세스)가 임계 구역에 들어가고자 한다면 지정된 시간만큼 대기해야 한다. 스레드가 공유자원의 배타적인 사용을 보장받기 위해서 임계 구역에 들어가거나 나올때는 세마포어 같은 동기화 매커니즘이 사용된다.

출처 : https://ko.wikipedia.org/wiki/%EC%9E%84%EA%B3%84_%EA%B5%AC%EC%97%AD

문맥을 교환(Context Switch)하는 동안에는 유용한 작업을 수행할 수 없기 때문에, 문맥 교환 시간은 일종의 오버헤드라고 할 수 있다. CISC와 RISC는 각각 장단점이 있는데, 문맥교환 측면에 보면 RISC의 경우 레지스터의 용량이 CISC보다 상대적으로 크기 때문에 좀 더 큰 오버헤드가 발생한다.

CPU가 각 프로세스의 상태를 저장하고 복원해야 하기 때문에 오버헤드 비용도 발생하는데, 특히 프로세스 수가 많거나 컨텍스트 전환이 빈번한 환경에서 시스템 성능에 영향을 미칠 수 있다. 결과적으로 운영 체제 설계자는 최적의 시스템 성능을 달성하기 위해 멀티태스킹의 이점과 운영 체제의 컨텍스트 전환 오버헤드 간의 균형을 신중하게 조정해야 한다.

💻 운영체제의 문맥교환이 시스템 성능에 미치는 영향

시스템에서 실행 중인 프로세스 수가 많은 경우, 컨텍스트 전환을 자주 수행하면 CPU가 프로세스를 실행하는 것보다 프로세스 간 전환에 더 많은 시간을 소비하게 되어 전체 시스템 성능이 저하될 수 있다.

출처 :

• https://ko.wikipedia.org/wiki/%EB%AC%B8%EB%A7%A5_%EA%B5%90%ED%99%98
• https://datatrained.com/post/context-switching-in-os/

🖥️ 상호배제(Mutex)란?

상호 배제(相互排除, mutual exclusion, Mutex, 뮤텍스)는 동시 프로그래밍에서 공유 불가능한 자원의 동시 사용을 피하기 위해 사용되는 알고리즘으로, *임계 구역(critical section)으로 불리는 코드 영역에 의해 구현된다. 공유 불가능한 자원의 예로는 동시에 실행되고 있는 프로그램간의 통신에 사용되는 비트 단위의 깃발, 계수기, 큐 등이다. 문제는 스레드가 언제라도 정지되거나 시작될 수 있다는 것이다.

* 임계 구역 : 서로 다른 두 프로세스, 혹은 스레드 등의 처리 단위가 같이 접근해서는 안 되는 공유 영역. 프로그래밍시, 임계구역을 최소화하여야 성능 향상에 도움이 된다.

★ 상호배제는 교착상태(deadlock)의 4가지 필요조건 중 하나이다.

출처 : https://ko.wikipedia.org/wiki/%EC%83%81%ED%98%B8_%EB%B0%B0%EC%A0%9C

🖥️ 인터럽트(Interrupt)란?

CPU가 프로그램을 실행하고 있을 때 예외상황이 발생해 처리가 필요할 경우 현재 실행중인 작업을 중단하고 발생된 상황을 처리한 뒤 다시 실행중인 작업으로 복귀하는 것을 말한다.  입출력 연산이 CPU 연산 수행속도보다 현저히 느리기 때문에 사용한다. I/O 연산이 끝난 이후 I/O Device는 인터럽트를 통해 CPU에게 알리고 CPU는 I/O 연산 결과를 이용해 작업을 완료한다. 

🖥️ 인터럽트의 종류

• 외부 인터럽트: 입출력 장치, 타이밍 장치, 전원 등의 외부적인 요인에 의해서 발생하는 인터럽트.

  • 전원 이상 인터럽트: 정전이나 전원이 이상이 있는 경우
  • 기계 고장 인터럽트: CPU등의 기능적인 동작 오류가 발생한 경우
  • 입출력 인터럽트(I/O Interrupt): 입출력의 종료 등의 이유로 CPU의 수행을 요청하는 인터럽트.

• 내부 인터럽트: 잘못된 명령이나 데이터를 사용할 때 발생하는 인터럽트

  • 0으로 나누는 경우
  • 오버플로우 또는 언더플로우가 발생한 경우
  • 프로그램 상의 오류
  • 프로그램에서 함수 등 명령어를 잘못 사용한 경우
  • 예외를 처리하던 중 또 다른 예외가 발생할 경우, Double Fault이라고 부른다. Double Fault가 발생하여 이를 처리하는 중에 또 다른 예외가 발생할 경우, Triple Fault라고 부르며 이 경우 CPU Reset가 발생한다.
  • 소프트웨어 인터럽트: CPU가 인스트럭션을 수행하는 도중에 일어나는 인터럽트

출처 : https://nice-engineer.tistory.com/entry/%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C-%EC%9D%B8%ED%84%B0%EB%9F%BD%ED%8A%B8Interrupt#recentComments

🖥️ 데드락(deadlock)이란?

데드락(deadlock)은 교착 상태(膠着狀態)라고도 불리며, 두 개 이상의 작업이 서로 상대방의 작업이 끝나기 만을 기다리고 있기 때문에 결과적으로 아무것도 완료되지 못하는 상태이다. 전산학에서 교착 상태란 다중 프로그래밍 환경에서 흔히 발생할 수 있는 문제이다. 이 문제를 해결하는 일반적인 방법은 아직 없는 상태이다.

🖥️ 데드락(deadlock)의 발생조건

1. 상호배제(Mutual exclusion) : 프로세스들이 필요로 하는 자원에 대해 배타적인 통제권을 요구한다.
2. 점유대기(Hold and wait) : 프로세스가 할당된 자원을 가진 상태에서 다른 자원을 기다린다.
3. 비선점(No preemption) : 프로세스가 어떤 자원의 사용을 끝낼 때까지 그 자원을 뺏을 수 없다.
4. 순환대기(Circular wait) : 각 프로세스는 순환적으로 다음 프로세스가 요구하는 자원을 가지고 있다.

이 조건 중에서 한 가지라도 만족하지 않으면 교착 상태는 발생하지 않는다. 이중 순환대기 조건은 점유대기 조건과 비선점 조건을 만족해야 성립하는 조건이므로, 위 4가지 조건은 서로 완전히 독립적인 것은 아니다.

출처 : https://ko.wikipedia.org/wiki/%EA%B5%90%EC%B0%A9_%EC%83%81%ED%83%9C

📝 애자일 소프트웨어 개발(Agile Software Development; 애자일 방법론)이란?

애자일 소프트웨어 개발 방법론은 프로젝트를 작은 단위의 작업과 단계로 나누는 프로젝트 관리 공정이다. 업무를 세부적으로 나눠 진행하기 때문에 팀이 공정의 각 단계에서 관계자의 피드백을 적용하고, 작업을 재평가하고, 신속하게 반복 작업을 실행할 수 있다. 애자일 방법론에서 가장 일반적으로 사용되는 방식은 짧은 개발 주기인 '스프린트'를 통해 업무를 점진적으로 진행하는 것이다. 이를 통해 팀은 업무를 신속하게 진행하고, 스프린트 계획 단계와 매일 진행되는 스크럼을 통해 관리자, 관계자들과 정기적으로 업무를 재평가할 수 있다. 프로젝트팀과 관계자들은 검토를 거쳐 업무를 현재의 방식대로 계속 진행할 것인지, 아니면 앞으로의 스프린트에서는 계획을 변경해 적용할 것인지 결정할 수 있다. 전통적인 프로젝트 관리 방식과 비교하면 애자일 방법론은 속도, 유연성, 팀워크, 관계자의 요구 사항을 가장 우선순위로 둔다는 점에서 차이가 있다. 애자일 소프트웨어 개발은 2000년대 초반부터 현재까지 많은 기술 기업에서 프로젝트 관리 방식으로 중용되어 왔다. 오늘날 대부분의 소프트웨어 개발팀이 애자일 방법론을 어떠한 형태로든 사용하고 있고, 다른 많은 업무 환경에서도 애자일 방법론의 요소를 활용하고 있다.

📝애자일의 유래

애자일이라는 개념은 2000년대 초 소프트웨어 개발자들이 모여 4가지 원칙이 담긴 선언문을 발표한 데서 유래했으며, 그 원칙은 다음과 같다.

1. 공정과 도구보다 개인과 상호 작용 중시
2. 포괄적인 문서보다 작동하는 소프트웨어 중시
3. 계약 협상보다 고객과의 협력 중시
4. 계획을 고수하기보다는 변화에 대응

2001년에 발표된 애자일 선언문에 명시된 이 4가지 가치는 애자일 프로젝트 관리 방식의 바탕이 되었고, 소프트웨어 개발업계에 전면적인 변화를 가져왔다.

이전까지는 소프트웨어 개발 프로젝트에 폭포수 모델이 가장 선호되는 방식으로 여겨졌다. 폭포수 모델은 처음 등장한 1970년대에는 굉장히 획기적이었지만, 프로젝트를 시작하기도 전에 많은 양의 문서를 작성하고 확고한 계획을 세워야 한다는 점이 가장 큰 문제였다. 업무가 실제로 시작되면 각 팀이, 때로는 서로 고립된 상태에서, 계획을 철저하게 따라야 해 문제가 발생하거나 계획을 변경해야 할 때 이에 적절하게 대응하기가 힘들었다. 이에 비해 애자일 방법론을 사용하는 팀은 프로젝트를 더 신속하게 시작할 수 있고 문제가 발생하면 이에 적절하게 대응할 수 있으며 고객, 관계자와 함께 계획을 세울 수 있다.

출처 : https://experience.dropbox.com/ko-kr/resources/agile-methodology

가상 메서드*에는 구현이 있으며 자식 클래스에 이를 재정의하는 옵션을 제공한다. (반드시 재정의할 필요는 없음.) 이에 비해, 추상 메서드는 구현을 제공하지 않으며 파생 클래스가 메서드를 재정의하도록 강제한다.

따라서 추상 메서드에는 실제 코드가 없으며 추상이 아닌 자식 클래스는 부모의 추상 메서드를 재정의해야 한다. 가상 메서드에는 일반적으로 어떤 항목의 기본 구현인 코드가 있을 수 있으며, 모든 자식 클래스는 override 수정자를 사용하여 메서드를 재정의하고 사용자 지정 구현을 제공할 수 있다.

오토마타 이론(Automata Theory)은 계산 능력이 있는 추상 기계와 그 기계를 이용해서 풀 수 있는 문제들을 연구하는 컴퓨터 과학의 분야이다. 여기서 추상 기계를 오토마타(automata, 복수형) 또는 오토마톤(automaton, 단수형), 즉 자동 기계라고 부른다. 이 이름은 '자동'을 의미하는 그리스어 'αὐτόματα'에서 유래하였다. 오토마타는 "자동화"라는 단어와 밀접하게 관련된 자동 장치 라는 단어 자체는 특정 프로세스의 생산을 수행하는 자동 프로세스를 나타낸다.

🖥️ 오토마타의 종류

대표적으로 유한 상태 기계(Finite State Machine)가 있다. 이는 내부 상태 외의 저장 공간을 갖지 않는 오토마타이며, 저장 공간이 따로 없어서 가장 간단한 형태의 오토마타라 할 수 있다. 또한, 오토마타는 입력 문자열을 순서대로 하나씩 읽으면서 읽은 글자와 내부 상태에 따라 내부 상태를 바꾸면서 작동한다.

유한 상태 기계가 사용되는 대표적인 예시로 정규 표현식과 논리회로가 있다. 순차적 논리회로는 유한 개의 저장 공간을 가지므로 이를 내부 상태로 생각해 유한 상태 기계로 표현할 수 있다.

출처 :

• https://ko.wikipedia.org/wiki/%EC%98%A4%ED%86%A0%EB%A7%88%ED%83%80_%EC%9D%B4%EB%A1%A0
• https://cs.stanford.edu/people/eroberts/courses/soco/projects/2004-05/automata-theory/basics.html

벡터를 사용하는 이유

1. GameObject들의** 속도, 바람, 저항, 충돌, 위치 판단** 등 많은 요소들을 벡터로 표현할 수 있다.

2. 벡터의 내적을 이용해서 오브젝트 위치의 전·후방을 판별할 수 있다. 플레이어의 시선(forward) 중심으로 좌, 우 90도가 넘어가는 순간 코사인 값은 음수를 갖기 때문에, 플레이어 시선의 벡터와 target의 위치벡터를 내적해서 양수값이면 플레이어의 전방, 음수값이면 플레이어의 후방에 위치한다.

3. 벡터의 외적은 보통 오브젝트 위치의 좌우를 판별하는데 사용된다. 플레이어의 시선과 Up 벡터를 중심으로 외적을 구한다면 플레이어의 좌측에 있는 오브젝트는 양수, 플레이어의 오른쪽에 있는 오브젝트는 음수를 반환한다.

📈 벡터란?

                                    ↑ 벡터는 점 A와 점 B를 잇는 화살표이다.

벡터는 그리스 수학자인 '유클리디안 벡터(Euclidean vector)'의 이름을 따랐으며, 기하학적 벡터(geometric vector)라고도 불린다. 이는 크기와 방향을 모두 가지는 어떤 양으로 정의되며, 사물의 움직임을 프로그래밍하기 위한 가장 기본적인 구성요소이다. 일반적으로 벡터는 화살표로 표현한다. 화살표가 가리키는 쪽은 방향을 나타내며 화살표의 길이는 크기를 나타낸다.

📈 벡터의 내적(內積; inner product)

내적은 벡터를 곱하는 개념 중 하나인데, 이는 '쌓을 적(積)'이라는 한자로 표현된다. 이는 두 벡터의 방향이 일치하는 정도에 따라서 곱을 한다. 예를 들어, 두 벡터의 방향이 완전히 일치하면 각 벡터의 크기를 그냥 곱하고, 두 벡터가 이루는 각이 90도일 땐, 일치하는 정도가 전혀 없기 때문에 곱이 0이 된다. 즉 내적은 하나의 벡터를 다른 벡터로 * 정사영 시켜서 그 벡터의 크기를 곱하는 것으로 이해할 수 있다.

내적의 값을 구하는 수식은 두 벡터 사이에 기호로 가운데 점(dot)을 찍는 것( · )이며, 이는 벡터a와 b의 절대값을 곱하고 코사인 세타 값을 곱하면 된다.

* 정사영(Orthogonal Projection) : 한 벡터를 다른 벡터에 수직으로 내린 선상에 있는 점을 찾는 것을 말한다. 즉 정사영은 두 벡터 사이의 각도와 관련이 있으며, 이를 통해 한 벡터를 다른 벡터의 방향으로 투영시키는 것이라 볼 수 있다.

📈 벡터의 외적(外積; outer product)

두 벡터를 곱하는 내적 외에 외적도 존재한다. 외적의 결과값은 벡터이며, 이 벡터의 방향은 곱하는 두 벡터에 수직하고 크기는 두 벡터가 이루는 평행사변형의 넓이이다. 내적의 연산 기호는 닷(dot; ·)을 사용하며, 수식은 벡터a와 b의 절대값을 곱하고 코사인 세타 값을 곱하면 된다. 외적의 연산 기호는 크로스(cross; χ )이며, 수식은 각 벡터의 외적의 크기(절대값)를 곱하고 사인 세타 값을 곱하면 된다.

📈 내적과 외적의 차이

수학적으로 접근한다면 내적과 외적은 서로 상관이 없다. 즉 두 가지 형태의 다른 연산이 존재하는 것이라 볼 수 있다. 다만 내적의 결과값은 스칼라이고, 외적의 결과값은 벡터이다.

위에서 서술한 것과 같이 게임 프로그래밍에서 바라보는 벡터의 내적과 외적은 다소 차이가 있다. 내적은 0~180도 사이에서만 구할 수 있기 때문에 전·후방 값만 알 수 있으며, 반대로 외적은 중앙(0)을 기준으로 좌(-1)·우(1) 값을 알 수 있다. 즉 내적과 외적을 함께 쓰게 되면 360도 위치와 방향을 구현할 수 있다. (해당 부분은 다시 정리)

출처 :

• 칸 아카데미 - 벡터란?
• https://wikidocs.net/22384
• https://amirazmi.net/dot-products-in-games-and-their-use-cases/
• https://gnaseel.tistory.com/18#google_vignette