아래는 프로그래머스에서 제공한 문제 설명입니다.

다음 규칙을 지키는 문자열을 올바른 괄호 문자열이라고 정의합니다.

(), [], {} 는 모두 올바른 괄호 문자열입니다. 만약 A가 올바른 괄호 문자열이라면, (A), [A], {A} 도 올바른 괄호 문자열입니다. 예를 들어, [] 가 올바른 괄호 문자열이므로, ([]) 도 올바른 괄호 문자열입니다. 만약 A, B가 올바른 괄호 문자열이라면, AB 도 올바른 괄호 문자열입니다. 예를 들어, {} 와 ([]) 가 올바른 괄호 문자열이므로, {}([]) 도 올바른 괄호 문자열입니다. 대괄호, 중괄호, 그리고 소괄호로 이루어진 문자열 s가 매개변수로 주어집니다. 이 s를 왼쪽으로 x (0 ≤ x < (s의 길이)) 칸만큼 회전시켰을 때 s가 올바른 괄호 문자열이 되게 하는 x의 개수를 return 하도록 solution 함수를 완성해주세요.

❌ 제한사항

• s의 길이는 1 이상 1,000 이하입니다.

💻 나의 풀이 (C#)

using System;
using System.Collections.Generic;

public class Solution {
    public int solution(string s) {
        int answer = 0;

        for(int i = 0; i < s.Length; i++)
        {
            List<char> temp = new List<char>();
            Stack<char> stack = new Stack<char>();
            int idx = i;

            for(int j = 0; j < s.Length; j++)
            {
                temp.Add(s[idx]);
                idx++;

                if(idx >= s.Length)
                    idx = 0;
            }

            foreach(char c in temp)
            {
                if(c == '(' || c == '{' || c == '[')
                    stack.Push(c);
                else
                {
                    if(stack.Count == 0)
                    {
                        stack.Push('X');
                        break;
                    }

                    char peek = stack.Peek();
                    char comparison = ' ';

                    switch(peek)
                    {
                        case '(':
                            comparison = ')';
                            break;

                        case '{':
                            comparison = '}';
                            break;

                        case '[':
                            comparison = ']';
                            break;
                    }

                    if(c == comparison)
                    {
                        stack.Pop();
                    }
                }   
            }

            if(stack.Count == 0)
            {
                answer++;
            }
        }

        return answer;
    }
}

Unity에서 여러 개의 탭 버튼을 생성하고, 각각 클릭했을 때 해당 인덱스의 탭으로 전환되도록 코드를 작성했다.

for (int i = 0; i < tabButtons.Length; i++)
{
    tabButtons[i].onClick.AddListener(() => SwitchTab(i)); // 문제 발생
}

문제는, 버튼을 클릭했을 때 항상 마지막 인덱스 (tabButtons.Length)가 전달되어 모든 버튼이 같은 탭을 여는 현상이 발생했다.

🔷 왜 이런 문제가 발생했을까?

C#의 람다 캡처 특성 때문이다.

• 위 코드에서 i는 람다 내부에서 참조(캡처)되고 있음
• 하지만 i는 for 루프의 하나의 변수로 존재하고, 반복문이 끝나면 i는 Length 값으로 고정됨
• 즉, 버튼 클릭 시점엔 이미 i == tabButtons.Length가 되어버림
• 결과적으로 모든 버튼이 같은 SwitchTab(i) 값을 호출하게 됨

🔷 해결 방법: 지역 변수로 캡처 분리하기

반복문 안에서 매 반복마다 새로운 지역 변수를 만들어서 캡처해야 한다.

for (int i = 0; i < tabButtons.Length; i++)
{
    int index = i; // i를 지역 변수로 복사
    tabButtons[i].onClick.AddListener(() => SwitchTab(index)); // 정확한 값 전달
}

이제 각각의 버튼은 자신에게 맞는 index를 기억하고, SwitchTab(index)가 의도한 대로 호출된다.

🔷 수정된 전체 코드 예시

private void Start()
{
    for (int i = 0; i < tabButtons.Length; i++)
    {
        int index = i;
        tabButtons[i].onClick.AddListener(() => SwitchTab(index));
    }

    SwitchTab(2); // 초기 탭 선택
}

🔷 정리

• 람다식 안에서 반복문 변수를 직접 참조하지 말자
• 대신, 지역 변수로 복사해서 캡처하도록 하자
• Unity 이벤트 할당 시에는 특히 자주 마주치는 이슈이므로 반드시 주의할 것!

아래는 프로그래머스에서 제공한 문제 설명입니다.

주차장의 요금표와 차량의 입/출차 기록이 주어졌을 때, 차량별로 주차 요금을 계산하세요.

요금표

입/출차 기록

자동차별 주차 요금

1. 입차 후 출차 내역이 없으면 23:59에 출차된 것으로 간주합니다.

2. 누적 주차 시간이 기본 시간 이하인 경우: 기본 요금만 청구합니다.

3. 초과 시간이 있는 경우:

   • 초과 시간은 (누적 시간 - 기본 시간)
   • 요금 = 기본 요금 + ⌈초과 시간 / 단위 시간⌉ × 단위 요금

4. ⌈a⌉는 올림 함수, 즉 a보다 크거나 같은 최소 정수

❌ 제한사항

• fees.Length == 4
• 1 ≤ fees[0] ≤ 1439 (기본 시간)
• 0 ≤ fees[1] ≤ 100000 (기본 요금)
• 1 ≤ fees[2] ≤ 1439 (단위 시간)
• 1 ≤ fees[3] ≤ 10000 (단위 요금)
• 1 ≤ records.Length ≤ 1000
• records[i]는 "HH:MM 차량번호 IN/OUT" 형식
• 차량 번호는 "0000" ~ "9999" 사이 문자열
• records는 시각 오름차순 정렬

💻 나의 풀이 (C#)

using System;
using System.Collections.Generic;
using System.Linq;

public class Solution {
    public int[] solution(int[] fees, string[] records) {
        List<int> answer = new List<int>();
        Dictionary<string, TimeSpan> timeDict = new Dictionary<string, TimeSpan>();
        Dictionary<string, int> feeDict = new Dictionary<string, int>();

        for(int i = 0; i < records.Length; i++)
        {
            string[] recordInfo = records[i].Split(' ');

            TimeSpan time = TimeSpan.Parse(recordInfo[0]);
            string carNum = recordInfo[1];

            if(timeDict.ContainsKey(carNum))
            {
                TimeSpan outTime = time;
                TimeSpan inTime = timeDict[carNum];
                TimeSpan totalTime = outTime - inTime;

                int totalM = (int)totalTime.TotalMinutes;

                if(feeDict.ContainsKey(carNum))
                    feeDict[carNum] += totalM;
                else
                    feeDict.Add(carNum, totalM);

                timeDict.Remove(carNum);
            }

            else
            {
                timeDict.Add(carNum, time);
            }
        }

        if(timeDict.Count > 0)
        {
            foreach(var carNum in timeDict.Keys)
            {
                TimeSpan outTime = TimeSpan.Parse("23:59");
                TimeSpan inTime = timeDict[carNum];
                TimeSpan totalTime = outTime - inTime;

                int totalM = (int)totalTime.TotalMinutes;

                if(feeDict.ContainsKey(carNum))
                    feeDict[carNum] += totalM;
                else
                    feeDict.Add(carNum, totalM);
            }
        }

        foreach(var carNum in new List<string>(feeDict.Keys).OrderBy(k => k))
        {
            feeDict[carNum] = CalculateFee(feeDict[carNum], fees);
            answer.Add(feeDict[carNum]);
        }

        return answer.ToArray();
    }

    public int CalculateFee(int minutes, int[] fees)
    {
        int basicTime = fees[0];
        int basicFee = fees[1];
        int unitTime = fees[2];
        int unitFee = fees[3];

        if(minutes <= basicTime)
            return basicFee;
        else
        {
            int extraTime = minutes - basicTime;
            int extraUnits = (int)Math.Ceiling((double)extraTime / unitTime);

            return basicFee + extraUnits * unitFee;
        }
    }
}

✅ 상태 패턴(State Pattern)이란?

• 객체의 상태에 따라 행위가 달라지는 상황에서, 각 상태를 클래스로 분리하고 상태 전이를 명확하게 만드는 패턴
• FSM은 게임 AI나 UI 상태 전이 등에 자주 사용되며, 상태 간의 전이를 명확하게 정의하고 관리하기 쉬워짐.

📝 구조 요약

1. 기반 클래스: UnitBase

• 모든 유닛(플레이어, 몬스터)의 공통 기능을 담당합니다. 주요 역할:
• NavMeshAgent, Animator 등 컴포넌트 관리
• 현재 유닛의 상태 전이 관리 stateMachine
• 공통 스탯 (UnitStatSO, unitStat) 및 체력 관리
• 상태 클래스들을 초기화 및 보유

public class UnitBase : MonoBehaviour 
{
    public StateMachine stateMachine { get; private set; }
    public IdleState IdleState { get; private set; }
    public ChasingState ChasingState { get; private set; }
    public AttackState AttackState { get; private set; }

    protected virtual void Awake() 
    {
        stateMachine = new StateMachine();
        IdleState = new IdleState(this);
        ChasingState = new ChasingState(this);
        AttackState = new AttackState(this);
    }
}

2. 상태 인터페이스: IState

• 모든 상태 클래스들이 구현하는 인터페이스입니다.

public interface IState 
{
    void Enter();
    void Update();
    void Exit();
}

3. 각 상태 클래스

타겟이 감지되면 ChasingState로 전이

IdleState

public void Update() 
{
    if (unit.Target != null && unit.IsTargetInRange(unit.unitStat.chaseRange)) 
    {
        unit.stateMachine.ChangeState(unit.ChasingState);
    }
}

ChasingState

• 타겟을 향해 이동

• 공격 사거리 내에 들어오면 AttackState로 전이

  public void Update() 
  {
    unit.Agent.SetDestination(unit.Target.position);
  
    if (unit.IsTargetInRange(unit.unitStat.attackRange)) 
    {
        unit.stateMachine.ChangeState(unit.AttackState);
    }
  }

AttackState

• 일정한 공격 쿨타임을 기반으로 애니메이션 호출 (Animation Event로 Attack 호출)
• 타겟이 사거리 밖이면 다시 IdleState로 전이

public void Update() 
{
    if (Time.time - lastAttackTime >= attackCooldown) 
    {
        unit.Attack();
        lastAttackTime = Time.time;
    }
}

📃 상태 전이 관리: StateMachine

상태 간 전이를 처리(Enter, Exit)하며 현재 상태의 Update()를 매 프레임 호출합니다.

public class StateMachine 
{
    private IState currentState;

    public void ChangeState(IState newState) 
    {
        currentState?.Exit();
        currentState = newState;
        currentState.Enter();
    }

    public void Update() 
    {
        currentState?.Update();
    }
}

정리

• 플레이어도 자동으로 적을 찾아 이동하므로 몬스터와 공통된 로직 UnitBase 클래스로 묶어서 처리
• 상태 패턴은 각 상태를 클래스로 분리함으로써 코드 가독성과 유지보수성을 높여줍니다.
• FSM 구조는 AI 행동 전이를 깔끔하게 구현할 수 있어, 몬스터나 NPC 행동 설계에 매우 유용
• UnitBase에 공통 로직을 묶고, FSM은 상태 전이만 관리하도록 책임 분리가 잘 되어 있어 확장에 용이
• AttackState에선 쿨타임 계산을 통해 프레임마다 공격하지 않도록 조절 가능

오늘은 주요 자료구조를 간단히 정리하고, 어떤 상황에서 유용하게 쓰일 수 있는지를 다시 복습해보는 시간을 가져보았다.

1. 배열 (Array)

• 고정된 크기의 연속적인 메모리 공간
• 빠른 인덱스 접근 (O(1)), 하지만 크기 변경 불가

🎮 활용 예:

• 맵 타일 데이터 (고정된 크기), 색상 팔레트 등
• 성능이 중요한 루프에서 단순 배열이 유리할 때 사용

2. 리스트 (List)

• C#의 동적 배열
• 내부적으로 크기 자동 조절 → 배열 복사 발생 가능

🎮 활용 예:

• 인벤토리 아이템 리스트
• 적군 목록, 퀘스트 목록 등 가변적인 데이터에 적합

3. 연결 리스트 (LinkedList)

• 노드 간 참조로 구성 (next, prev)
• 중간 삽입/삭제는 빠르지만 접근은 느림

🎮 활용 예:

• 순서 변경이 잦은 UI 요소나 이벤트 큐
• Undo/Redo 기록 관리 (양방향 리스트)

4. 스택 (Stack)

• 후입선출 (LIFO) 구조
• Push(), Pop() 으로 데이터를 다룸

🎮 활용 예:

• 상태머신 처리 (ex: 상태 push & pop)
• 씬 전환, UI 창 스택, 함수 호출 스택

5. 큐 (Queue), 우선순위 큐

• 선입선출 (FIFO) 구조
• Enqueue(), Dequeue() 사용

🎮 활용 예:

• 몬스터 스폰 큐
• 네트워크 패킷 처리
• 유닛 명령 대기열 등

6. 딕셔너리 (Dictionary)

• 해시 테이블 기반 자료구조
• 키 → 해시 → 인덱스 → 값 저장
• 평균 O(1) 접근 속도

🎮 활용 예:

• 오브젝트 이름 → Prefab 참조
• 유저 ID → 상태 정보
• NPC 대사, 스킬 ID → 효과 등

⚠️ 해시 충돌 시 성능 저하 가능성 있음 → 대량 데이터일수록 주의

7. SortedDictionary / SortedList

• 자동 정렬된 상태로 키 저장
• 내부적으로 이진 탐색 트리(레드블랙 트리) 사용

🎮 활용 예:

• 순차적으로 정렬된 데이터를 빠르게 조회하고 싶을 때
• 랭킹 시스템 (정렬된 유저 점수 목록 등)

8. 트리 (Tree)

• 계층 구조 표현에 적합
• 대표적: 이진 탐색 트리, AVL, 레드블랙 트리

🎮 활용 예:

• 스킬 트리, UI 메뉴 구조
• 상태 전이 트리 (FSM), 애니메이션 트리

9. 그래프 (Graph)

• 정점과 간선으로 이루어진 구조
• DFS / BFS / 다익스트라 / A*

🎮 활용 예:

• 길찾기 알고리즘 (네비게이션 메시, A*)
• 소셜 관계망 (플레이어 간 친구 시스템)
• 스테이지 간 연결 구조

10. 힙 (Heap) → 우선순위 큐

• 최소값 또는 최대값을 빠르게 찾는 구조
• 삽입, 삭제 후에도 자동으로 재정렬 유지

🎮 활용 예:

• AI 우선순위 작업 큐 (위험도 높은 유닛 우선 대응)
• 경로 탐색 알고리즘 (A*, 다익스트라)
• 리소스 관리 시스템

🧠 느낀점

• 자료구조는 단순히 외워서 쓰는 게 아니라, 언제 어떤 상황에서 적합한지를 판단
• 특히 게임 개발에서는 구조 하나 잘못 고르면 성능 문제나 유지보수 난이도가 크게 달라진다.
• 앞으로는 알고리즘 문제 풀이뿐만 아니라, 구현 설계 시에도 자료구조를 먼저 고민해야겠다.

아래는 프로그래머스에서 제공한 문제 설명입니다.

XYZ 마트는 일정한 금액을 지불하면 10일 동안 회원 자격을 부여합니다. XYZ 마트에서는 회원을 대상으로 매일 한 가지 제품을 할인하는 행사를 합니다. 할인하는 제품은 하루에 하나씩만 구매할 수 있습니다. 알뜰한 정현이는 자신이 원하는 제품과 수량이 할인하는 날짜와 10일 연속으로 일치할 경우에 맞춰서 회원가입을 하려 합니다.

예를 들어, 정현이가 원하는 제품이 바나나 3개, 사과 2개, 쌀 2개, 돼지고기 2개, 냄비 1개이며, XYZ 마트에서 14일간 회원을 대상으로 할인하는 제품이 날짜 순서대로 치킨, 사과, 사과, 바나나, 쌀, 사과, 돼지고기, 바나나, 돼지고기, 쌀, 냄비, 바나나, 사과, 바나나인 경우에 대해 알아봅시다. 첫째 날부터 열흘 간에는 냄비가 할인하지 않기 때문에 첫째 날에는 회원가입을 하지 않습니다. 둘째 날부터 열흘 간에는 바나나를 원하는 만큼 할인구매할 수 없기 때문에 둘째 날에도 회원가입을 하지 않습니다. 셋째 날, 넷째 날, 다섯째 날부터 각각 열흘은 원하는 제품과 수량이 일치하기 때문에 셋 중 하루에 회원가입을 하려 합니다.

정현이가 원하는 제품을 나타내는 문자열 배열 want와 정현이가 원하는 제품의 수량을 나타내는 정수 배열 number, XYZ 마트에서 할인하는 제품을 나타내는 문자열 배열 discount가 주어졌을 때, 회원등록시 정현이가 원하는 제품을 모두 할인 받을 수 있는 회원등록 날짜의 총 일수를 return 하는 solution 함수를 완성하시오. 가능한 날이 없으면 0을 return 합니다.

❌ 제한사항

• 1 ≤ want의 길이 = number의 길이 ≤ 10
  • 1 ≤ number의 원소 ≤ 10
  • number[i]는 want[i]의 수량을 의미하며, number의 원소의 합은 10입니다.
• 10 ≤ discount의 길이 ≤ 100,000
• want와 discount의 원소들은 알파벳 소문자로 이루어진 문자열입니다.
  • 1 ≤ want의 원소의 길이, discount의 원소의 길이 ≤ 12

💻 나의 풀이 (C#)

using System;
using System.Collections.Generic;

public class Solution {
    public int solution(string[] want, int[] number, string[] discount) {
        int answer = 0;
        Dictionary<string, int> wantDict = new Dictionary<string, int>();

        for(int i = 0; i < want.Length; i++)
        {
            if(!wantDict.ContainsKey(want[i]))
            {
                wantDict.Add(want[i], number[i]);
            }
            else    
                wantDict[want[i]] += number[i];
        }

        for(int day = 0; day <= discount.Length - 10; day++)
        {
            Dictionary<string, int> tempDict = new Dictionary<string, int>(wantDict);

            for (int i = day; i < day + 10; i++)
            {
                string item = discount[i];

                if(tempDict.ContainsKey(item) && tempDict[item] > 0)
                {
                    tempDict[item] -= 1;
                }
            }

            if(CheckRegister(tempDict))
                answer++;
        }

        return answer;
    }

    public bool CheckRegister(Dictionary<string, int> itemDict)
    {
        foreach(var wantItem in itemDict.Keys)
        {
            if(itemDict[wantItem] > 0)
            {
                return false;
            }
        }

        return true;
    }
}

아래는 프로그래머스에서 제공한 문제 설명입니다.

철호는 수열을 가지고 놀기 좋아합니다. 어느 날 철호는 어떤 자연수로 이루어진 원형 수열의 연속하는 부분 수열의 합으로 만들 수 있는 수가 모두 몇 가지인지 알아보고 싶어졌습니다. 원형 수열이란 일반적인 수열에서 처음과 끝이 연결된 형태의 수열을 말합니다. 예를 들어 수열 [7, 9, 1, 1, 4] 로 원형 수열을 만들면 다음과 같습니다.

원형 수열은 처음과 끝이 연결되어 끊기는 부분이 없기 때문에 연속하는 부분 수열도 일반적인 수열보다 많아집니다. 원형 수열의 모든 원소 elements가 순서대로 주어질 때, 원형 수열의 연속 부분 수열 합으로 만들 수 있는 수의 개수를 return 하도록 solution 함수를 완성해주세요.

❌ 제한사항

• 3 ≤ elements의 길이 ≤ 1,000
• 1 ≤ elements의 원소 ≤ 1,000

💻 나의 풀이 (C#)

using System;
using System.Collections.Generic;

public class Solution {
    public int solution(int[] elements) {
        int len = elements.Length;
        HashSet<int> temp = new HashSet<int>(elements);

        for(int length = 2; length <= len; length++)
        {
            for(int start = 0; start < len; start++)
            {
                int sum = 0;

                for(int i = 0; i < length; i++)
                {
                    sum += elements[(start + i) % len];

                }
                temp.Add(sum);
            }
        }
        return temp.Count;
    }
}

1. Enum & Struct 통합 관리

🔹 Enum의 장점

• 자동완성 지원으로 오타를 줄이고 가독성을 향상
• 상수 값보다 타입 안정성 확보
• 코드 작성 시 값의 명확한 의미 부여

🔹 Struct의 장점

• 값 타입으로 스택 메모리 활용, GC 부담 감소
• 참조 공유로 인한 데이터 오염 방지
• 직렬화가 가능하여 ScriptableObject나 JSON 등에 활용하기 유리

Enum과 Struct는 하나의 파일에서 모아서 관리하는 것이 유지보수에 효과적

2. 유틸리티 함수 & 글로벌 상수 관리

🔹 유틸리티 함수 (static class)

• 중복 제거와 재사용성 강화
• 어디서든 접근 가능하여 간단한 기능 처리에 유리
• 주의: 남용 시 의존성 증가 가능성

🔹 글로벌 상수

• public static readonly 또는 const를 활용하여 불변값만 전역 관리
• 예: Tag, Layer, 서버 주소, 씬 이름, UI 키 값 등

3. 싱글톤 + DontDestroyOnLoad 패턴

• 게임 전반에 걸쳐 유지되어야 하는 객체 (예: GameManager, AudioManager 등)에 사용
• DontDestroyOnLoad(this.gameObject)로 씬 전환에도 유지

남용 시 결합도 증가와 디버깅 난이도 상승

Generic 싱글톤

using UnityEngine;

public class Singleton<T> : MonoBehaviour where T : MonoBehaviour
{
    private static T instance;
    public static T Instance
    {
        get
        {
            if (instance == null)
            {
                // 해당 컴포넌트를 가지고 있는 게임 오브젝트 반환
                instance = (T)FindAnyObjectByType(typeof(T));

                if (instance == null)
                {
                    // 새로운 게임 오브젝트 생성 및 컴포넌트 추가
                    GameObject obj = new GameObject(typeof(T).Name, typeof(T));
                    // 새로운 오브젝트의 컴포넌트 인스턴스에 지정
                    instance = obj.GetComponent<T>();
                }
            }

            return instance;
        }
    }

    protected virtual void Awake()
    {
        // 인스턴스가 없을 때 해당 오브젝트로 설정
        if (instance == null)
        {
            instance = this as T;
            DontDestroyOnLoad(this.gameObject);
        }

        // 인스턴스가 존재한다면 현재 오브젝트 파괴
        else if (instance != null)
            Destroy(gameObject);
    }
}

4. ScriptableObject & 데이터 컨테이너

🔹 ScriptableObject

• 설정 값, 능력치, 아이템 데이터 등 불변 데이터 관리에 최적
• 인스펙터에서 관리 가능하며, 에디터 친화적

🔹 데이터 컨테이너

• 여러 ScriptableObject를 하나의 큰 묶음으로 관리
• 예: StageDataList, ItemDatabase 등

메모리 절약을 위해 불필요한 데이터까지 함께 로드하지 않도록 설계

5. 리소스 및 오브젝트 풀링

🔹 리소스 그룹화

• 사운드, 이펙트, 아이콘 등을 ScriptableObject나 Dictionary 등으로 묶어 중앙 집중식 관리

🔹 오브젝트 풀링

• 자주 생성/파괴되는 오브젝트는 Pool로 관리하여 GC 호출 방지 및 성능 최적화

6. 씬 & UI 관리

🔹 멀티 씬 구조

• UI, 월드, 매니저 등을 독립적인 씬으로 분리하면 모듈화와 로딩 최적화에 유리

🔹 UI 최적화

• 변경이 잦은 UI는 Canvas 분리

EventTrigger보다 UnityEvent, AddListener 사용 권장

😁 느낀점

이번 정리를 통해 프로젝트 구조의 중요성을 다시금 깨달았다. 더 체계적으로 설계하고, 유지보수성과 확장성을 고려한 개발 습관을 만들어나가는 방향으로 공부해야겠다.

아래는 프로그래머스에서 제공한 문제 설명입니다.

두 수의 최소공배수(Least Common Multiple)란 입력된 두 수의 배수 중 공통이 되는 가장 작은 숫자를 의미합니다. 예를 들어 2와 7의 최소공배수는 14가 됩니다. 정의를 확장해서, n개의 수의 최소공배수는 n 개의 수들의 배수 중 공통이 되는 가장 작은 숫자가 됩니다. n개의 숫자를 담은 배열 arr이 입력되었을 때 이 수들의 최소공배수를 반환하는 함수, solution을 완성해 주세요.

❌ 제한사항

• arr은 길이 1이상, 15이하인 배열입니다.
• arr의 원소는 100 이하인 자연수입니다.

💻 나의 풀이 (C#)

using System.Linq;

public class Solution {
    public int solution(int[] arr) {
        int answer = 0;
        int maxNum = arr.Max();

        while(true)
        {
            bool canDivide = true;
            answer += maxNum;

            for(int i = 0; i < arr.Length; i++)
            {
                if(answer % arr[i] != 0)
                {
                    canDivide = false;
                }
            }

            if(canDivide)
                break;
        }

        return answer;
    }
}

아래는 프로그래머스에서 제공한 문제 설명입니다.

효진이는 멀리 뛰기를 연습하고 있습니다. 효진이는 한번에 1칸, 또는 2칸을 뛸 수 있습니다. 칸이 총 4개 있을 때, 효진이는 (1칸, 1칸, 1칸, 1칸) (1칸, 2칸, 1칸) (1칸, 1칸, 2칸) (2칸, 1칸, 1칸) (2칸, 2칸) 의 5가지 방법으로 맨 끝 칸에 도달할 수 있습니다. 멀리뛰기에 사용될 칸의 수 n이 주어질 때, 효진이가 끝에 도달하는 방법이 몇 가지인지 알아내, 여기에 1234567를 나눈 나머지를 리턴하는 함수, solution을 완성하세요. 예를 들어 4가 입력된다면, 5를 return하면 됩니다.

❌ 제한사항

• n은 1 이상, 2000 이하인 정수입니다.

💻 나의 풀이 (C#)

public class Solution {
    public long solution(int n) {
        long divider = 1234567;
        long[] temp = new long[n + 1];
        temp[0] = 1;
        temp[1] = 1;

        for(int i = 2; i <= n; i++)
        {
            temp[i] = (temp[i - 1] + temp [i - 2]) % divider;
        }

        return temp[n];
    }
}

📝 SOLID?

• 객체지향 설계의 5가지 핵심원칙

🎮 게임 개발에서의 적용 예시

1️⃣ SRP - 단일 책임 원칙

하나의 스크립트/컴포넌트는 하나의 역할만 담당해야 한다.

// ❌ 이동, 공격, 저장 로직이 한 클래스에 몰려 있음
public class Player : MonoBehaviour {
    void Move() { }
    void Attack() { }
    void SaveData() { }
}

// ✅ 역할을 명확히 분리
public class PlayerMovement : MonoBehaviour { void Move() { } }
public class PlayerCombat : MonoBehaviour { void Attack() { } }
public class PlayerSave : MonoBehaviour { void SaveData() { } }

• 장점: 기능별 책임 분리로 유지보수가 쉬움, 재사용도 가능

2️⃣ OCP - 개방-폐쇄 원칙

코드를 수정하지 않고, 기능을 확장할 수 있어야 한다

// 공격방식을 인터페이스로 추상화
public interface IAttackStrategy 
{
    void Attack();
}

public class MeleeAttack : IAttackStrategy { public void Attack() { } }
public class RangedAttack : IAttackStrategy { public void Attack() { } }

public class Enemy {
    private IAttackStrategy attackStrategy;

    public Enemy(IAttackStrategy strategy) 
    {
        this.attackStrategy = strategy;
    }
    public void Attack() => attackStrategy.Attack();
}

• 장점: 새로운 공격 방식이 생겨도 기존 코드를 건드릴 필요 없음

3️⃣ LSP - 리스코프 치환 원칙

부모 클래스를 자식 클래스로 치환해도 동작이 깨지면 안 된다.

// X 자식 클래스가 부모의 계약을 깨뜨림
public class Enemy { public virtual void Die() { } }
public class ImmortalEnemy : Enemy 
{
    public override void Die() => throw new Exception("죽지 않음");
}

// O 공통 기능만 인터페이스로 분리
public interface IDamageable 
{
    void TakeDamage(int amount);
}

public class RegularEnemy : MonoBehaviour, IDamageable { }
public class ImmortalEnemy : MonoBehaviour { }

• 포인트: 상속보다는 인터페이스 분리와 조합을 더 많이 사용하자

4️⃣ ISP - 인터페이스 분리 원칙

필요한 기능만 명확하게 나눈 인터페이스를 사용하자.

// X 모든 엔티티에 다 필요한 메서드는 아님
public interface IGameEntity {
    void Move();
    void Attack();
    void CastSpell();
}

// O 기능별로 인터페이스를 분리
public interface IMovable { void Move(); }
public interface IAttackable { void Attack(); }
public interface ISpellCaster { void CastSpell(); }

• 장점: 필요 없는 기능 구현을 강제하지 않아 클래스가 깔끔해짐

5️⃣ DIP - 의존 역전 원칙

클래스는 구체적인 구현보다 인터페이스(추상화)에 의존해야 한다.

// X GameManager가 AudioManager에 직접 의존
public class GameManager 
{
    private AudioManager audioManager = new AudioManager();
}

// O 추상화에 의존하여 유연성 확보
public interface IAudioManager 
{
    void Play(string clip);
}

public class GameManager 
{
    private IAudioManager audio;

    public GameManager(IAudioManager audio) 
    {
        this.audio = audio;
    }
}

• 포인트: DI(의존성 주입)를 통해 테스트와 유연성 확보

📃 정리

게임도 결국 소프트웨어다. 설계가 깔끔해야 확장도 쉽다.

• SRP → 기능별 컴포넌트 분리로 유지보수 편리
• OCP → 새로운 무기/스킬/몬스터도 쉽게 추가 가능
• LSP → 상속보다 인터페이스 조합이 유리한 경우가 많음
• ISP → 엔티티마다 필요한 기능만 제공
• DIP → 테스트 가능한 구조, 교체 가능한 모듈 구성 가능

항상 지키며 작업할 수는 없겠지만 최대한 지켜려고 노력하고, 앞으로는 interface를 더 활용하여 설계를 해봐야겠다.

🧩 핵심 구조

모든 플레이어 관련 로직은 Player 스크립트가 중심이 되며, 아래의 구성요소들을 참조 및 초기화합니다:

[Player] : 중심 허브 역할
 ├── PlayerController         // 입력 처리
 ├── PlayerStatus            // 체력/스태미나 등 상태 관리
 ├── PlayerMovement          // 이동 처리
 ├── PlayerWeaponHandler     // 무기 해제/장착/투척
 ├── PlayerVehicleHandler    // 탈것 호출 및 탑승
 ├── PlayerAnimationHandler  // 애니메이션 상태 설정
 ├── PlayerAudioHandler      // 사운드 처리
 └── PlayerEventHandler      // 커스텀 이벤트 트리거

🧠 Player.cs - 메인 허브

모든 기능 스크립트들을 연결하고 초기화하는 중심 클래스 현재 상태를 나타내는 PlayerState를 관리하여 기능 분기 제어

주요 동작

• 이동 및 회전
• 대시, 투척, 자원 채집, 아이템 소비
• 피해 처리 및 사망 처리

🔄 주요 시스템 연결 예시

🎮 입력 → 동작 연결

• PlayerController → 사용자 입력 수신
• PlayerMovement → 이동 및 회전 처리
• PlayerWeaponHandler → 무기 투척 로직
• PlayerVehicleHandler → 탈것 호출 및 탑승 제어

🩺 상태 관리

• PlayerStatus → 체력, 스태미나, 수분 등 자원 관리
• UseStamina, TakeDamage, SetItemStat 등 주요 기능 제공

🧨 무기 시스템

• PlayerWeaponHandler → 무기 해금, 교체, 투척 제어
• WeaponController + Grenade로 투척체 기능 완성

🎥 애니메이션 처리

• PlayerAnimationHandler → Animator 연결
• 이동, 대시, 채집, 던지기, 사망 등 트리거 제어
• 피격 시 시각 효과도 포함 (Coroutine 기반)

🔉 사운드 처리

• PlayerAudioHandler → 각 행동에 맞는 사운드 처리 (추가 예정)

📌 상태 기반 제어 예시

PlayerState 열거형을 통해 상태에 따라 행동을 제한하고 분기 처리합니다.

public enum PlayerState
{
    Idle, Walk, Dash, Gathering, Throw, Vehicle, Death
}

public bool CanMove => CurState != PlayerState.Vehicle && CurState != PlayerState.Gathering && CurState != PlayerState.Death && CurState != PlayerState.Throw;

void FixedUpdate()
{
    if (CanMove)
        playerMovement.Move(playerController.MoveDirection, playerStatus.MoveSpeed);
}

void Update()
{
    if (CanMove)
        playerMovement.Rotate(playerController.LookDirection);
}

💻 플레이어 동작 화면

📌 설계에서 배운 점

• 컴포넌트 기반 설계는 각 기능을 분리하여 명확한 책임 분담 가능
• Player 클래스는 허브 역할만 담당하고 각 기능은 전담 컴포넌트가 수행
• 애니메이션과 상태, 입력과 로직의 결합을 느슨하게 유지하니 유지보수성이 높음

이렇게 구성해서 플레이어를 구축해나가니 확실히 새로운 기능들을 추가할 때 큰 어려움이 없이 잘 진행되었던거 같다.

• 플레이어가 조준 시 마우스 방향에 따라 투척 궤도(trajectory) 를 시각적으로 보여주는 시스템 구현
• 궤도 계산에 물리 엔진을 고려한 포물선 적용
• 마우스 위치를 기반으로 45도 위쪽으로 향하는 투척 방향 계산 로직 구현

⚙️ TrajectoryController 핵심 기능 요약

클래스: TrajectoryController

💡 투척 궤도 계산

void Update()
{
    if (!trajectoryLine.enabled) return;

    Vector3 direction = GetAimDirection(out float force);
    Vector3[] points = new Vector3[pointCount];

    Vector3 pos = throwPoint.position;
    Vector3 velocity = direction * force;
    for (int i = 0; i < pointCount; i++)
    {
        points[i] = pos;
        pos += velocity * timeStep;
        velocity += Physics.gravity * timeStep;
    }

    trajectoryLine.positionCount = pointCount;
    trajectoryLine.SetPositions(points);
}

• 매 프레임마다 pointCount 만큼의 궤도 점 계산
• 기본적인 투사체 운동 공식 적용 (v = v0 + at, x = x0 + vt)

📝 방향 및 힘 계산

🔄 방향 계산

public Vector3 GetAimDirectionForce(out float force)
{
    Ray ray = cam.ScreenPointToRay(Input.mousePosition);
    Plane groundPlane = new Plane(Vector3.up, throwPoint.position);
    if (groundPlane.Raycast(ray, out float enter))
    {
        // 평면에서 위쪽으로 45에 향하는 벡터 구하기
        Vector3 target = ray.GetPoint(enter);
        Vector3 dir = (target - throwPoint.position).normalized;

        Quaternion tilt = Quaternion.AngleAxis(-45f, Vector3.Cross(Vector3.up, dir));
        Vector3 finalDirection = tilt * dir;

        force = GetThrowForce(target);
        return finalDirection;
    }

    force = minThrowForce;
    return transform.forward;
}

• dir: 마우스 클릭 위치까지의 수평 방향 벡터
• Vector3.Cross(Vector3.up, dir): 수평 벡터를 기준으로 회전할 축(axis) 계산
  • 즉, dir 벡터를 위로(45도) 기울이기 위한 회전축
• Quaternion.AngleAxis(-45f, axis): 해당 축을 기준으로 -45도 회전하는 회전값(쿼터니언) 생성
• tilt * dir: 수평 벡터를 위쪽으로 45도 기울인 벡터 반환

목표점 방향을 그대로 향하게 하되, "위로 던지는 느낌"을 주기 위함

💪 힘 계산

public float GetThrowForce(Vector3 targetPos)
{
    float distance = Vector3.Distance(throwPoint.position, targetPos);
    float t = Mathf.Clamp01(distance / maxDistance);
    return Mathf.Lerp(minThrowForce, maxThrowForce, t);
}

• disctance: 던지는 위치와 목표간의 거리 계산
• t: 위 거리와 최대 거리간의 비율 계산
• Mathf.Lerp(minThrowForce, maxThrowForce, t): 최소 파워와 최대 힘 사이의 보간 값

거리에 따른 던지는 힘을 계산하기 위함

💻 투척 무기 결과물

🔧 매니저의 역할

매니저는 실제 기능을 수행하기보다는, 객체나 시스템 간의 연결을 관리하고 흐름을 조율하는 것이 핵심이다.

✅ 1. 의존성 관리

• 서로 관련 있는 객체들 간의 참조를 연결하거나 해제하는 역할
• 예: UIManager가 모든 UI 패널을 보유하고 필요할 때 Show/Hide 호출

✅ 2. 리소스 관리

• 로드/언로드, 캐싱 등 리소스 생명 주기를 조절
• 예: AudioManager가 배경음악 및 효과음을 미리 로드하여 필요한 순간에 재생

✅ 3. 이벤트 조율

• 게임 전체에서 발생하는 이벤트 흐름을 관리
• 예: GameManager가 게임 시작/종료 시 관련 매니저에 알림을 전달

🚫 매니저가 해서는 안 되는 일

매니저가 기능을 직접 구현하거나 세부 데이터를 처리하게 되면
책임이 무거워지고 유지보수가 어려워진다.

• 직접적인 게임 로직 구현
• UI 요소의 세부 애니메이션이나 상태 처리
• 객체 내부의 세부 데이터를 가공/처리

즉, 매니저는 말 그대로 관리자의 역할

📝 좋은 매니저 설계 원칙

1. 단일 책임 원칙 (SRP)

• 하나의 매니저는 오직 하나의 종류의 관리만 수행해야 한다.
• 예: AudioManager는 오직 오디오만, UIManager는 오직 UI만 관리

2. 중앙 집중화 (Centralization)

• 관련된 리소스/기능을 한 곳에 모아 효율적으로 조율
• 예: DataManager가 모든 기획 데이터를 로드/파싱하여 제공

3. 확장 가능성

• 매니저는 추후 시스템이 확장되더라도 쉽게 기능 추가/교체가 가능해야 한다.
• 예: 이벤트 기반 구조를 적용해 유연한 알림 시스템 구축

🧠 정리

• 매니저는 관리자이지, 기능 담당자가 아니다.
• 설계 시 책임 분리와 중앙화를 잘 지키면 시스템이 깔끔하고 확장 가능해진다.
• Unity 개발에서 "매니저 남용"은 코드 복잡도를 급격히 높이는 요인이므로
  항상 목적에 맞는 최소한의 매니저만 설계하자.

매니저는 관리와 조율에 집중하고, 세부 구현은 각 객체에게 맡기자!

3D 공간에서 마우스 위치를 기준으로 캐릭터 회전 방향을 결정하고 싶을 때, 마우스 포지션을 월드 좌표의 평면상 위치로 변환하는 것이 필요하다. 이때, Unity의 Plane과 Ray를 활용하여 구현 할 수 있다.

📌 Plane.Raycast

Plane groundPlane = new Plane(Vector3.up, Vector3.zero);

• 이 코드는 y = 0에 해당하는 가상의 바닥 평면을 생성한다.
• Vector3.up은 평면의 법선 벡터이며, Vector3.zero는 평면이 지나는 점.

  즉, 씬에 별도로 바닥 오브젝트가 없어도, 수학적으로 평면을 하나 만들어 사용할 수 있다.

Ray ray = cam.ScreenPointToRay(mouseScreenPos);

• 마우스 화면 좌표를 기준으로 카메라에서 쏘는 Ray를 만든다.

if (groundPlane.Raycast(ray, out float point))
{
    Vector3 hitPoint = ray.GetPoint(point);
}

• 이 Ray가 groundPlane과 충돌하는 지점까지의 거리(point)를 계산하고,
• 실제 월드상의 충돌 위치 (hitPoint)를 구할 수 있다.

왜 사용하는가 ?

• 마우스 포지션은 2D 화면 좌표
• 이를 3D 공간의 위치로 변환하려면,
  • 어떤 "기준 평면"에 마우스가 닿는 지점을 계산
• Plane.Raycast는 그 평면과 Ray가 만나는 지점을 찾음
• 씬에 별도의 Collider가 없어도 동작

📝 회전 처리 코드

// Input 관련 코드
public void OnLook(InputAction.CallbackContext context)
{
    Vector2 mouseScreenPos = context.ReadValue<Vector2>();

    Ray ray = cam.ScreenPointToRay(mouseScreenPos);
    Plane groundPlane = new Plane(Vector3.up, Vector3.zero); // y=0인 평면

    if (groundPlane.Raycast(ray, out float point))
    {
        Vector3 hitPoint = ray.GetPoint(point); // 바닥과의 교점
        Vector3 direction = hitPoint - transform.position;
        direction.y = 0; // y축 제거

        if (direction.magnitude < 0.9f)
        {
            lookDirection = Vector3.zero; // 너무 가까우면 무시
        }
        else
        {
            lookDirection = direction.normalized;
        }
    }
}

// 실제 회전
private void Rotate()
{
    float angle = Mathf.Atan2(lookDirection.x, lookDirection.z) * Mathf.Rad2Deg;
    transform.rotation = Quaternion.Euler(0f, angle, 0f);
}

💻 동작 화면

💡 느낀 점

Plane.Raycast를 활용해 가상의 평면을 만들고, 해당 평면에 닿는 지점을 기준으로 플레이어의 회전 방향을 계산하는 방식이 Collider 없이 동작한다는 점이 신기했다.

이 방식을 활용해서, 나중에 NavMesh와 결합하여 마우스 클릭으로 원하는 위치로 이동하는 시스템도 만들어보고 싶다.

게임 데이터를 설계할 때는 불변 데이터와 변동 데이터를 구분하는 것이 중요하다.

🗂️ 기획 테이블 활용 방식

기획자 중심의 콘텐츠 제작을 위해 데이터 수정이 쉽고 직관적이어야 하며, 보통 다음과 같은 형태로 데이터를 관리한다.

✅ CSV (엑셀 기반)

• 기획자가 엑셀로 작성한 데이터를 CSV로 저장 후 Unity에서 파싱
• 가장 쉬운 접근법이며 가볍고 빠름

✅ JSON 파일

• CSV보다 구조화된 데이터 표현이 가능
• 중첩된 배열, 복잡한 구성에 적합

// 저장
PlayerSaveData data = new PlayerSaveData();
string json = JsonUtility.ToJson(data);
File.WriteAllText(path, json);

// 불러오기
if (File.Exists(path)) {
    string json = File.ReadAllText(path);
    PlayerSaveData data = JsonUtility.FromJson<PlayerSaveData>(json);

✅ ScriptableObject

• Unity 에디터 상에서 직접 데이터를 관리할 수 있는 에셋
• 변하지 않는 데이터 관리에 적합
• Resources 또는 Addressables를 통해 로드
• 외부 JSON을 파싱한 데이터를 ScriptableObject에 적용하는 방식도 가능

✅ 서버 데이터

• 실시간 변경이 필요한 데이터는 서버에서 관리
• 원격 수정 및 유저 개인화 데이터에 적합 (예: 이벤트 정보, 랭킹 등)

직렬화용 클래스를 따로 만들어 데이터 포맷을 관리하고 검증 필요

📝 파싱과 참조 설계

게임 데이터를 저장하거나 불러올 때는 전체 데이터를 복사하거나 중복 저장하는 대신, 참조 기반 구조로 설계하는 것이 좋다.

예를 들어, 아이템의 이름, 설명, 기본 능력치 등은 변하지 않는 기준 데이터로 ScriptableObject나 JSON 파일을 통해 관리하고,

플레이어가 실제로 획득한 아이템은 해당 기준 데이터를 참조하는 인스턴스 클래스(ItemInstance 등)로 관리

이 인스턴스는 플레이 중 바뀌는 값만 따로 저장한다.

즉, "불변 데이터는 참조로, 변하는 값만 별도로 저장하는 구조"가 좋다.

📌 정리

• 게임 데이터는 불변 데이터(룰, 밸런스 등)와 가변 데이터(플레이어 상태 등)를 구분하여 설계해야 유지보수성과 확장성이 높아진다.

• CSV, JSON, ScriptableObject, 서버 데이터 등 다양한 방식으로 기획 데이터를 관리하며, 각 방식의 특성과 용도에 맞게 선택해야 한다.

• 직렬화 클래스를 따로 두어 데이터를 안정적으로 저장하고, 검증을 통해 데이터 무결성을 보장해야 한다.

• 게임의 다양한 설정 값이나 로직 데이터를 코드에 직접 하드코딩하지 않고,
• JSON*, CSV, ScriptableObject 등의 외부 데이터로 분리하여 처리하는 설계 방식이다.

✅ 데이터 드리븐 방식의 장점

• 빠른 수정과 반복 테스트 용이 → 코드 수정 없이 밸런스나 콘텐츠 수치를 변경할 수 있어 작업 속도가 빨라진다.

• 비개발자도 접근 가능 → 기획자나 밸런서 등 개발 지식이 없는 인원도 데이터를 손쉽게 수정해 테스트 가능.

• 하드코딩 방지 → 코드가 깔끔해짐 → 수치가 코드에 직접 박혀 있지 않기 때문에 유지보수성과 가독성이 향상된다.

• 빌드 없이 콘텐츠 수정 가능 → 실시간으로 데이터만 교체하여 빠르게 게임에 적용 가능. 빠른 A/B 테스트와 튜닝에 유리하다.

Parser & Parser Tool

🧾 파싱(Parsing)이란?

파싱은 데이터를 읽어서 이해할 수 있는 형태로 바꾸는 작업

보통 우리가 사용하는 JSON, CSV, 구글 시트 같은 데이터는 텍스트로 되어있음, 이걸 게임에서 쓰려면, 숫자나 문자열을 꺼내서 코드에서 쓸 수 있는 형태로 바꿔야함 이 과정을 바로 파싱(Parsing) 이라고 한다.

{ "name": "Slime", "hp": 50, "attack": 10 }

이런 JSON 데이터를 읽어서, MonsterData라는 클래스에 name: string, hp: float, attack: float 같은 변수로 채워 넣는 것

🔧 파서 툴(Parser Tool)이란?

파서 툴은 위처럼 데이터를 읽어서 클래스나 데이터 파일로 자동으로 변환해주는 프로그램

• 구글 시트 → CSV → 게임용 데이터 클래스 생성
• JSON 파일 → ScriptableObject 생성
• CSV → .cs 클래스 자동 생성 + 인스턴스화

즉, 기획자가 만든 수많은 데이터를 자동으로 가져와 코드에 쓸 수 있도록 만들어주는 도구

⚠️ Parser Tool(파서 툴) 설계 시 유의사항

• Unity 에디터 내부보다는 독립적인 외부 툴(C# WinForm, HTML, 독립 실행 파일 등)을 권장
  • 에디터 내부에 파서를 만들 경우, 시트 변경 → 즉시 클래스 반영 → 게임에 바로 영향이라는 구조가 너무 위험할 수 있다.
  • 파서 자체가 에러를 내면 Unity에서 스크립트 전체가 컴파일되지 않아 테스트 자체가 불가능해질 수 있다.
• 데이터는 자동 반영보다 수동 반영 구조가 안정적
  • 빌드 시점 또는 명확한 검증 절차를 거친 후 반영하는 것이 안전하다.

📌 정리

위 방식들은 실무에서 사용되는 방식들이므로, 우선 최대한 데이터를 직접 코드에 집어넣는 하드코딩의 방식대신 데이터를 한 곳에 모아 관리하며 사용하는 방식으로 먼저 코딩 습관을 들이고, 관련한 내용을 좀 더 학습하며 사용해보아야겠다.

아래는 프로그래머스에서 제공한 문제 설명입니다.

경화는 과수원에서 귤을 수확했습니다. 경화는 수확한 귤 중 'k'개를 골라 상자 하나에 담아 판매하려고 합니다. 그런데 수확한 귤의 크기가 일정하지 않아 보기에 좋지 않다고 생각한 경화는 귤을 크기별로 분류했을 때 서로 다른 종류의 수를 최소화하고 싶습니다.

예를 들어, 경화가 수확한 귤 8개의 크기가 [1, 3, 2, 5, 4, 5, 2, 3] 이라고 합시다. 경화가 귤 6개를 판매하고 싶다면, 크기가 1, 4인 귤을 제외한 여섯 개의 귤을 상자에 담으면, 귤의 크기의 종류가 2, 3, 5로 총 3가지가 되며 이때가 서로 다른 종류가 최소일 때입니다.

경화가 한 상자에 담으려는 귤의 개수 k와 귤의 크기를 담은 배열 tangerine이 매개변수로 주어집니다. 경화가 귤 k개를 고를 때 크기가 서로 다른 종류의 수의 최솟값을 return 하도록 solution 함수를 작성해주세요.

❌ 제한사항

• 1 ≤ k ≤ tangerine의 길이 ≤ 100,000
• 1 ≤ tangerine의 원소 ≤ 10,000,000

💻 나의 풀이 (C#)

using System;
using System.Linq;

public class Solution {
    public int solution(int k, int[] tangerine) {
        int answer = 0;
        int count = 0;
        int curTangerine = 0;

        int[] sortedTangerine = tangerine
            .GroupBy(x => x)
            .OrderByDescending(g => g.Count())
            .SelectMany(g => g)
            .ToArray();

        while(count < k)
        {
            if(sortedTangerine[count] != curTangerine)
            {
                curTangerine = sortedTangerine[count];
                answer++;
            }

            count++;   
        }


        return answer;
    }
}

GroupBy로 같은 원소끼리 묶고, OrderByDescending으로 묶은 원소의 개수가 많은 순으로 정렬, SelectMany로 다시 그룹 해제하여, 종류가 가장 많은 순으로 정렬하여 문제해결

• 게임 플레이 도중 숫자 키(1~0)를 이용해 슬롯을 선택하고, 선택된 아이템을 사용할 수 있는 툴바 시스템을 구현하는 것이 목표였다.
• 아이템은 포션과 같은 소비형 아이템과 장비형 아이템으로 나뉘며, 툴바 슬롯에 등록된 아이템을 사용하면 해당 효과가 적용되도록 만들었다.

🧱 주요 클래스 구성

📃 ToolBar 클래스

• InputAction: 숫자 키 입력 감지 및 슬롯 선택
• UseItem(): 아이템 사용 처리
• ApplyPotionEffect(): 아이템 효과 적용
• *AddItemToSlot(): *슬롯 관리 및 아이템 추가

InputAction을 통해 현재 선택된 슬롯 판별

public void OnSelectSlot(InputAction.CallbackContext context)
{
    if (context.phase == InputActionPhase.Started)
    {
        string keyString = context.control.name;

        if (int.TryParse(keyString, out int keyNum))
        {
            int slotIdx = keyNum - 1 != -1 ? keyNum - 1 : itemSlots.Length - 1;

            ItemSlot slot = itemSlots[slotIdx];

            if (selectedSlot != null && selectedSlot != slot)
            {
                selectedSlot.DeSelectSlot();
                ClearHand();
            }

            selectedSlot = slot;
            selectedSlot.SelectSlot();
        }
    }
}

• InputAction.CallbackContext는 Input System에서 이벤트가 발생했을 때 전달되는 입력 정보 컨테이너
• 어떤 키가 눌렸는지를 판별해서 해당 인덱스의 아이템 슬롯을 선택하는 역할을 수행한다.

📃 ItemSlot 클래스

• SetSlot(): 슬롯에 아이템 등록, 아이템 수량 표시 및 스택 처리
• SelectSlot() / DeSelectSlot(): 슬롯 선택/해제 시 외곽선 효과
• ClearSlot(): 아이템 사용 시 수량 감소 및 초기화

슬롯에 아이템이 추가 가능한지 판별하는 메서드

public bool CanAddItem(ItemData data)
{
    if (dataSO != null)
    {
        if (data == dataSO && quantity < dataSO.maxAmount)
            return true;
        else
            return false;
    }

    return true;
}

💻 실제 화면

아래는 프로그래머스에서 제공한 문제 설명입니다.

초 단위로 기록된 주식가격이 담긴 배열 prices가 매개변수로 주어질 때, 가격이 떨어지지 않은 기간은 몇 초인지를 return 하도록 solution 함수를 완성하세요.

❌ 제한사항

• prices의 각 가격은 1 이상 10,000 이하인 자연수입니다.
• prices의 길이는 2 이상 100,000 이하입니다.

💻 완전 탐색 (C#)

using System;

public class Solution {
    public int[] solution(int[] prices) {
        int[] answer = new int[prices.Length];

        for(int i = 0; i < prices.Length; i++)
        {
            bool isDrop = false;

            for(int j = i + 1; j < prices.Length; j++)
            {
                if(prices[i] > prices[j])
                {
                    answer[i] = j - i;
                    isDrop = true;
                    break;
                }
            }

            if(!isDrop)
                answer[i] = prices.Length - (i + 1);
        }
        return answer;
    }
}

💻 Stack 활용 (C#)

using System;
using System.Collections.Generic;

public class Solution {
    public int[] solution(int[] prices) {
        int length = prices.Length;
        int[] answer = new int[length];
        Stack<int> stack = new Stack<int>();

        for(int i = 0; i < length; i++)
        {
            while(stack.Count > 0 && prices[i] < prices[stack.Peek()])
            {
                int idx = stack.Pop();
                answer[idx] = i - idx;
            }

            stack.Push(i);
        }

        while(stack.Count > 0)
        {
            int idx = stack.Pop();
            answer[idx] = length - (idx + 1);
        }

        return answer;
    }
}

완전 탐색의 경우 시간 복잡도가 최악의 경우 O(n^2) 으로 prices[]의 크기가 너무 큰 입력값이 들어오면 시간 초과가 발생할 수 있다.

하지만 Stack을 활용한 경우 시간 복잡도는 O(N)으로 효율성이 훨씬 좋다.