📘 형변환과 입력, 연산자 그리고 문자열 활용

🔄 형변환의 개념

C#은 형식이 엄격한 언어이기 때문에 서로 다른 자료형 간의 대입이나 연산을 수행할 때 형변환이 필요하다.
형변환에는 명시적 형변환과 암시적 형변환 두 가지 방식이 있다.

암시적 형변환 (Implicit Casting)

작은 범위의 자료형에서 큰 범위의 자료형으로 자동으로 변환된다.

int num = 10;
float result = num; // int → float 자동 변환

명시적 형변환 (Explicit Casting)

데이터 손실 우려가 있을 경우, 개발자가 직접 캐스팅을 명시해야 한다.

float pi = 3.14f;
int intPi = (int)pi; // 소수점 이하 버려짐

⌨️ Console 입력 받기

C#에서는 Console.ReadLine() 메서드를 통해 문자열 형태로 입력을 받을 수 있다.
입력된 문자열은 필요한 자료형으로 변환하여 사용해야 한다.

문자열 입력

Console.Write("Enter your name: ");
string name = Console.ReadLine();

숫자 입력 (문자열 → 정수형 변환)

Console.Write("Enter your age: ");
int age = int.Parse(Console.ReadLine());

공백으로 구분된 다중 입력

string input = Console.ReadLine();           // 예: "10 20"
string[] parts = input.Split(' ');
int a = int.Parse(parts[0]);
int b = int.Parse(parts[1]);

➕ 연산자 종류와 사용법

C#에서는 다양한 연산자를 제공한다. 자료형에 따라 연산자의 동작이 다르므로 정확한 사용이 필요하다.

산술 연산자

관계 연산자

논리 연산자

복합 대입 연산자

x += 3;  // x = x + 3;
x *= 2;  // x = x * 2;

증감 연산자

i++;   // 후위 증가
++i;   // 전위 증가

🧠 연산자 우선순위

연산자는 실행 순서가 정해져 있으며, 괄호로 우선순위를 조절할 수 있다.

1. 괄호 ()
2. 단항 연산자 (++, --, !)
3. 산술 연산자 (*, /, %, +, -)
4. 비교 연산자 (<, >, ==, !=)
5. 논리 연산자 (&&, ||)
6. 대입 연산자 (=, +=, -=, ...)

✍️ 문자열 처리 기초

C#의 문자열은 string 자료형이며 다양한 기능을 지원한다.

문자열 연결

string fullName = "Hello" + " " + "World";

문자열 분할

string sentence = "apple,banana,orange";
string[] fruits = sentence.Split(',');

문자열 검색

int index = "Hello World".IndexOf("World");  // 6

문자열 대체

string message = "I like Java";
string updated = message.Replace("Java", "C#");

문자열 변환

int num = int.Parse("123");
string text = num.ToString();

문자열 비교

string a = "Apple";
string b = "apple";
bool isEqual = a == b; // false (대소문자 구분)
int result = string.Compare(a, b); // 사전 순 비교

문자열 보간 (Interpolation)

string name = "Kero";
int age = 30;
string result = $"My name is {name} and I am {age} years old.";

📣 학습 태도와 조언

형변환과 입력은 사용자와 프로그램이 데이터를 주고받는 가장 기초적인 단계이다.
암시적 변환과 명시적 변환의 차이를 명확히 이해하고, 모든 입력은 문자열로 들어온다는 점을 항상 염두에 두어야 한다.
또한, 다양한 연산자와 문자열 처리 기능을 실제로 코딩해보며 손에 익히는 것이 중요하다.
문법은 암기보다 사용 경험이 우선이며, 직접 작성하고 테스트하면서 익숙해지는 것이 가장 좋은 학습 방법이다.

📘 자료형과 변수의 기초 — 선언, 리터럴, 코드 스타일

🧩 C# 기본 자료형 개념

C#은 자료형에 대해 엄격한 형식 시스템을 가진 언어로, 모든 변수는 선언 시 반드시 자료형을 명시해야 한다.
자료형은 메모리의 크기, 표현 범위, 부호 여부에 따라 구분되며, 변수의 용도와 저장할 값의 형태에 따라 적절한 자료형을 선택해야 한다.

주요 기본 자료형

자료형 선택 기준

• 메모리 절약이 필요하면 작은 자료형을 사용한다.
• 정밀한 소수 표현이 필요하면 double, 금융 계산에는 decimal을 사용한다.
• 논리 판단에는 반드시 bool을 사용한다.

🧮 리터럴의 개념과 종류

리터럴은 코드 안에 직접 작성된 고정값을 의미한다. 변수에 할당하거나 연산에 사용된다.

대표적인 리터럴 종류

• 정수형 리터럴: 10, 0x10 (16진수), 0b1010 (2진수)
• 부동소수점 리터럴: 3.14, 3.14f, 3.14m
• 문자형 리터럴: 'A', '\n', '\u0022'
• 문자열 리터럴: "Hello", "이름: \"홍길동\""
• 논리형 리터럴: true, false

예시:

int age = 25;
float pi = 3.14f;
char grade = 'A';
string name = "Kero";
bool isActive = true;

💡 변수 선언과 초기화

변수는 데이터를 저장할 공간으로, 사용할 자료형에 따라 선언하며 값을 할당할 수 있다.

선언 방법

자료형 변수이름;
int score;

초기화 방법

score = 100;
int health = 50;

여러 개 동시 선언

int x = 1, y = 2, z = 3;

잘못된 예시

int a, b, c = 10; // b는 초기화되지 않음

🧾 식별자와 변수명 규칙

식별자는 변수, 메서드, 클래스 등 모든 이름에 사용되며 아래와 같은 규칙을 따라야 한다.

작성 규칙

• 영문자 또는 _로 시작해야 한다.
• 숫자를 처음에 사용할 수 없다.
• 특수문자(예: -, $)는 사용할 수 없다.
• 대소문자를 구분한다.
• C#의 키워드(int, class, public 등)는 사용할 수 없다.

좋은 변수명 예시

int playerScore;
float itemPrice;
string userName;

나쁜 변수명 예시

int x1;     // 의미 없음
string a;   // 모호함
int 1stNum; // 숫자로 시작 → 오류

📐 C# 코드 컨벤션 (이름짓기 스타일)

C#은 표준적인 코드 스타일 가이드라인을 따르며, 대표적으로 PascalCase와 camelCase 표기법을 사용한다.

컨벤션 종류

• PascalCase: 클래스, 메서드, 프로퍼티 등 (PlayerScore, GetItemName)
• camelCase: 변수, 매개변수 등 (playerScore, itemCount)
• 대문자 약어: ID, URL 등은 그대로 대문자로 유지한다.

기타 규칙

• 들여쓰기는 공백 4칸 또는 탭 1칸을 사용한다.
• 중괄호는 항상 새로운 줄에서 시작한다.
• 관련 없는 코드 블록은 빈 줄로 구분한다.
• 메서드 사이에는 1~2줄 간격을 두어 시각적으로 분리한다.

📣 학습 태도와 조언

변수와 자료형은 C#의 기초이자 모든 코드의 출발점이다.
자료형의 크기, 표현 범위, 정수와 실수의 차이를 명확히 이해하고, 의미 있는 변수명을 짓는 연습을 반복하는 것이 중요하다.
또한 C#의 코드 스타일을 일찍부터 습관화하면 협업과 유지보수에 큰 도움이 된다.

📘 C# 기본 구조 완전 정복 — 출력, 주석, 자동완성

🧩 C# 코드 구조 이해하기

C# 프로그램은 반드시 클래스와 메서드로 구성되며, 진입점인 Main 메서드에서 실행이 시작된다.
기본 콘솔 애플리케이션 구조는 다음과 같다.

using System;

namespace HelloWorld
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

구성 요소 설명

• using System;: 콘솔 입출력을 포함한 .NET 기본 기능이 정의된 네임스페이스를 포함한다.
• namespace HelloWorld: 코드의 논리적 구역을 정의하고, 클래스 이름 충돌을 방지한다.
• class Program: 실행 코드가 포함되는 클래스이며, C#에서는 반드시 클래스 또는 구조체 내부에 코드가 존재해야 한다.
• static void Main(string[] args): 프로그램의 진입점이며, C# 콘솔 애플리케이션에서 반드시 필요한 메서드이다.
• Console.WriteLine(...): 문자열을 콘솔에 출력하고 줄바꿈을 포함한다.

🖨️ 출력 메서드: Write vs WriteLine

Console.WriteLine()은 문자열 출력 후 줄바꿈까지 처리한다.
Console.Write()는 줄바꿈 없이 출력하며, 다음 출력이 같은 줄에 이어진다.

예를 들어,

Console.Write("A");
Console.Write("B");

는 AB로 출력되며,

Console.WriteLine("A");
Console.WriteLine("B");

는 줄을 바꿔 A와 B가 각각 출력된다.

🔡 이스케이프 시퀀스

이스케이프 시퀀스는 문자열 내부에 특수한 동작을 삽입하기 위해 사용된다.

예시:

Console.WriteLine("이름\t나이");
Console.WriteLine("Kero\t30");

→ 탭 정렬된 표처럼 출력된다.

💬 주석(Comment)

주석은 코드의 설명, 메모, 기록을 위한 도구로, 컴파일러에 의해 무시된다.

• 한 줄 주석: //를 사용하며 해당 줄 끝까지 주석 처리된다.
• 여러 줄 주석: /* */를 사용하며 시작과 끝을 명시해 범위 주석을 작성한다.

좋은 주석은 다음을 만족해야 한다.

• 정확한 설명을 담고 있어야 한다.
• 오래된 정보가 포함되어 있지 않아야 한다.
• 코드의 흐름이나 의도를 명확히 드러내야 한다.

주석은 코드 자체를 대체하지 않고 보완하는 수단이어야 하며, 필요할 때만 작성하는 것이 바람직하다.

⚙️ 자동완성과 코드 템플릿 기능

Visual Studio는 개발자의 코딩 생산성을 높이기 위해 자동완성 기능을 지원한다.

• Tab 키를 이용해 변수명, 클래스명, 메서드명 등을 자동완성할 수 있다.
• Ctrl + Space를 누르면 사용 가능한 메서드 목록과 설명이 표시된다.
• 반복문, 조건문 등의 구조를 작성할 때 for, if 입력 후 Tab을 두 번 누르면 코드 템플릿이 자동으로 생성된다.

이 기능은 코드를 빠르게 작성할 수 있도록 도와주며, 오타로 인한 오류를 줄여준다.

📣 학습 태도와 조언

문법이나 키워드를 외우기보다 코드 구조의 원리를 이해하는 것이 우선되어야 한다.
특히 namespace, class, Main 메서드의 관계와 역할을 정확히 파악하는 것이 중요하다.
직접 입력하고 실행해보는 경험을 통해 출력 방식, 주석 처리, 자동완성 기능 등을 체득하는 것이 효과적인 학습 방법이다.

📘 챕터 1. C# 소개와 개발 환경 설정

🧩 C# 언어의 개요

C#은 마이크로소프트에서 개발한 객체지향 프로그래밍 언어이다.
형식에 엄격하며, 안전성과 효율성을 고려한 구조를 갖추고 있다.
C, C++, Java와 유사한 문법을 기반으로 하며, 다양한 플랫폼에서 실행 가능하다.

주요 특징

• 객체지향 설계: 모든 구성 요소가 클래스와 객체 기반으로 이루어진다.
• 강한 형식 시스템: 자료형을 명확히 선언해야 하며, 컴파일 타임에 오류를 방지할 수 있다.
• 가비지 컬렉션 지원: 메모리 해제를 자동으로 처리한다.
• 플랫폼 독립성: .NET 플랫폼을 기반으로 다양한 환경에서 실행 가능하다.

🛠️ .NET 프레임워크

.NET은 C# 프로그램이 실행되는 기반 플랫폼이다.
C#으로 작성된 코드는 중간 언어(IL)로 먼저 컴파일되며, 실행 시점에 CLR(Common Language Runtime)이 이를 기계어로 변환하여 실행한다.
이 과정에서 메모리 관리, 예외 처리, 보안 등의 기능을 자동으로 제공받을 수 있다.

💻 Visual Studio 설치 및 프로젝트 생성

Visual Studio는 C# 개발에 가장 널리 사용되는 통합 개발 환경(IDE)이다.

설치 절차

• Visual Studio 공식 홈페이지에서 설치 파일을 다운로드한다.
• 설치 시 .NET 데스크톱 개발 워크로드를 선택한다.
• 설치 완료 후 초기 설정을 진행한다.

콘솔 앱 생성 방법

• Visual Studio 실행 → 새 프로젝트 만들기
• C# 콘솔 앱 선택
• .NET 6.0 선택 + 최상위 문 사용 안함 설정
• 프로젝트 이름 및 경로 설정 후 생성

🖨️ Hello World 출력하기

아래는 C#으로 작성한 가장 기본적인 콘솔 출력 프로그램이다.

using System;

namespace HelloWorld
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

구성 요소 설명

• using System;: Console 클래스 등 기본 기능을 사용하기 위한 선언이다.
• namespace HelloWorld: 코드 영역을 구분하는 논리적 단위이다.
• class Program: 실행 로직을 담는 클래스이다.
• static void Main(string[] args): 프로그램의 진입점이다.
• Console.WriteLine(...): 콘솔에 문자열을 출력하고 줄바꿈을 포함한다.

⚙️ 자동완성과 보조 기능

Visual Studio는 IntelliSense라는 자동완성 기능과 코드 템플릿 기능을 지원한다.

자동완성

• Tab 키를 사용해 클래스명이나 메서드명을 자동으로 완성할 수 있다.
• Ctrl + Space를 누르면 사용 가능한 메서드 목록, 설명, 인자 정보를 확인할 수 있다.

코드 템플릿

• for, if, while 등 키워드 입력 후 Tab을 두 번 누르면 기본 구조가 자동 생성된다.

📣 강의에서의 학습 태도와 조언

무엇을 배우는가보다 왜 배우는가에 집중해야 한다.
문법을 단순히 외우기보다는 그 목적과 맥락을 이해하는 것이 장기적인 실력으로 이어진다.

또한, 완벽한 코드를 한 번에 작성하는 것보다 빠르게 시도하고 실패하면서 수정하는 경험이 중요하다.
많이 써보고, 직접 에러를 겪고 해결하면서 성장할 수 있다.

✅

사실 기초는 이미 알고있지만 다시 상기 시킨다는 목적으로 하나씩 다시 공부해봐야겠다. 개발자는 겸손할 수 밖에 없는 직업이기 때문에 항상 겸손하자..

❓

어댑터 패턴에대한 이해도가 부족한거 같아서 다시 GPT에게 물어봐서 다시 공부해봤다. namespace로 Adpater를 정의해야

하는 줄 알았는데 그렇지 않았다. 결론은 

🎯 결론

C#에서 어댑터 패턴은 "직접 클래스와 인터페이스로 구현"하는 것이지, 키워드나 특별한 기능이 있는 건 아니야.

✅

오..이건 굉장히 새로운 지식이였다 그냥 클래스와 인터페이스로 구현하는거지 딱히 키워드가 있는게 아니였다

새로운사실! 그래서 한 번 예제 코드로 보겠다!

INewAttack.cs

public interface INewAttack
{
    void DoAttack();
}

IOldAttack.cs

public interface IOldAttack
{
    void SlashAttack();
}

OldSwordAttack.cs

public class OldSwordAttack : IOldAttack
{
    public void SlashAttack()
    {
        Console.WriteLine("Old sword slashes the enemy!");
    }
}

OldSwordAdapter.cs

public class OldSwordAdapter : INewAttack
{
    private readonly IOldAttack _oldAttack;

    public OldSwordAdapter(IOldAttack oldAttack)
    {
        _oldAttack = oldAttack;
    }

    public void DoAttack()
    {
        // 새 인터페이스를 통해 기존 메서드를 호출
        _oldAttack.SlashAttack();
    }
}

Program.cs

using System;

class Program
{
    static void Main(string[] args)
    {
        // 레거시 시스템
        IOldAttack oldAttack = new OldSwordAttack();

        // 어댑터를 통해 새 시스템에 연결
        INewAttack adaptedAttack = new OldSwordAdapter(oldAttack);

        // 새 시스템의 인터페이스 사용
        adaptedAttack.DoAttack();
    }
}

💡 요약

• INewAttack: 새 클라이언트 인터페이스
• IOldAttack + OldSwordAttack: 레거시 시스템
• OldSwordAdapter: 어댑터 클래스
• Program.cs: 어댑터를 통해 새 방식으로 레거시 클래스를 사용하는 예

✅

처음에는 이해가 잘 안됐지만 그래도 이렇게 예제 코드로 보니 이해가 좀 됐다!

그냥 간단히 얘기하자면 예전 시스템을 새로운 시스템이랑 연결을 시켜야 하는데 어댑터 패턴을 쓰지 않는다면

굉장히 복잡해지고 어려워 질 것이다. 그래서 어댑터 패턴을 사용하는 것!

지난 일주일 동안 가장 인상 깊었던 배움에는 뭐가 있었지?

이번 주는 정말 많은 내용을 다뤘고, 그 중에서도 개념적으로는 C#의 메모리 구조, 클래스 설계, 디자인 패턴, 실무적으로는 Unity의 컴포넌트 이해 및 Git 협업 흐름이 깊이 있게 와닿은 한 주였다.

✅ C#/CS 기본기 정리

• object 타입이 힙에 저장된다는 구조부터 박싱/언박싱, Queue/Stack의 저장 방식까지 메모리 흐름을 코드와 그림으로 함께 정리함
• HashTable, Dictionary, HashSet, Generics의 차이와 사용처 학습
• delegate, Func, Action, 람다식의 기본 사용법을 정리하고 함수형 프로그래밍 기초에 접근
• base, virtual, override, abstract의 의미와 쓰임새를 학습하면서 템플릿 메서드 패턴을 적용해보는 실습 진행
• 일반 오버라이드와 템플릿 메서드 패턴의 차이, 다형성(polymorphism) 개념과 인스턴스 생성(Parent obj = new Child()) 구조를 확인

✅ Unity 실습 및 시스템 이해

• Unity의 SpriteRenderer 정렬, 스케일 조정, Update 주기, GC 동작 원리 학습
• Card 시스템 제작: 카드 클릭 제한, 애니메이션 타이밍 조절
• ScriptableObject의 개념과 실습을 통해 데이터 중심의 Unity 개발 방식에 입문

✅ Git & 협업

• Git / GitHub / GitHub Desktop을 통한 협업 방식 이해
• 커밋 → 푸시 → 풀 → 충돌 해결까지 실습
• Detached HEAD 오류 상황을 경험하고 해결 과정을 통해 감각 증가

✅ 디자인 패턴 적용

• 어댑터 패턴 개념 학습
• Unity 기반 예제로 캐릭터 공격 방식 리팩토링 → Adapter 구조로 설계 

배움까지 다가가는데 어떤 어려움이 있었지?

1. 내가 안다고 생각했던 개념이 실제론 정확하지 않았다는 충격
   • 문제정의: object는 값 타입이니까 스택에 저장된다고 착각함. 박싱/언박싱도 그냥 개념적으로만 알고 있었음
   • 시도: 메모리 구조를 직접 그림으로 그리고, object obj = 3;처럼 간단한 코드로 실제 메모리 흐름을 추적
   • 해결방법: object는 참조형이고, 값 타입을 넣는 순간 힙에 복사본이 생긴다는 점을 코드 + 그림 + 디버깅으로 확인
   • 새롭게 알게 된 점: "내가 안다고 생각하는 것"과 "내가 설명할 수 있는 것"은 완전히 다르다
   • 다시 만나게 된다면: 개념을 배울 땐 반드시 구조적 이해 + 코드 테스트 + 직접 설명까지 해보자
2. 클래스 구조, 오버라이드, 템플릿 메서드 개념 충돌
   • 문제정의: base, override, virtual, abstract를 각각 따로 알긴 했지만, 언제 어떻게 함께 써야 하는지 감이 안 왔음
   • 시도: 공통 동작이 있는 예제(예: 공격 방식, 카드 뒤집기 등)를 가정하고 부모/자식 클래스를 직접 코딩
   • 해결방법: 부모 클래스에서 뼈대를 잡고, 자식 클래스에서 세부 로직만 바꾸는 템플릿 메서드 구조로 정리
   • 새롭게 알게 된 점: 템플릿 메서드는 다형성과 결합돼서 확장 가능한 구조를 만드는 핵심 도구
   • 다시 만나게 된다면: 단순한 오버라이드에 그치지 않고, 유지보수가 쉬운 템플릿 구조로 먼저 생각해보기
3. Git 협업의 현실적인 문제 - Detached HEAD 겪음
   • 문제정의: GitHub Desktop에서 실수로 커밋하고 보니 HEAD가 브랜치에서 떨어져 있었음
   • 시도: 현재 브랜치 상태 확인 → git checkout -b로 새 브랜치 생성해서 커밋 이력 살리는 방식으로 복구
   • 해결방법: Detached HEAD 개념 파악하고, 협업 전엔 반드시 브랜치 체크하는 습관 만들기
   • 새롭게 알게 된 점: 협업 도구는 단순한 버튼 클릭으로 끝나지 않고, 기초 개념을 알고 써야 문제 발생 시 빠르게 대처할 수 있다
   • 다시 만나게 된다면: 커밋하기 전에 항상 현재 브랜치 상태 확인 / 중요한 작업은 커맨드라인에서 확인까지 병행
4. ScriptableObject 개념의 진입 장벽
   • 문제정의: MonoBehaviour랑 뭐가 다르고 왜 써야 하는지 감이 안 왔음. 실습이 없으니 더 막막했음
   • 시도: 카드 정보를 ScriptableObject로 분리해보고, 인스펙터에서 직접 값 할당해보며 구조 파악
   • 해결방법: 인스턴스화된 데이터가 아니라, 데이터 자산으로 재사용하는 구조라는 개념을 이해
   • 새롭게 알게 된 점: 반복되거나 확장될 수 있는 데이터는 ScriptableObject로 관리하면 설계가 훨씬 깔끔해짐
   • 다시 만나게 된다면: 데이터 구조를 설계할 때 먼저 "이건 ScriptableObject로 빼도 될까?"부터 고민해보기

과정에서 나는 무엇을 깨달았고, 어떤 감정/생각이 들었었지?

• 이번 주 가장 크게 느낀 건 “나는 생각보다 제대로 모르고 있었구나”였다.
  그동안 익숙하게 쓰던 object, override, abstract 같은 키워드가, 막상 그림으로 설명하거나 메모리 구조로 풀어내려 하니까 하나도 정리가 안 돼 있었다.
  처음엔 그 사실이 좀 충격이었고, 내가 잘 못하고 있다는 생각이 들었다.
• 그런데 공부를 다시 차근차근 해보면서, 그리고 직접 코드를 짜보고 그림도 그려보니까 하나씩 이해되는 순간이 생겼고, 그때부터는 오히려 재미있어졌다.
  “아 내가 이래서 이걸 잘못 쓰고 있었구나”, “이게 그래서 이렇게 동작했구나” 같은 실마리가 계속 풀리면서 '아는 척'이 아니라 진짜 이해하게 된다는 감각이 생겼다.
• 특히 Git에서 Detached HEAD 상황을 겪으면서 “아 도구도 개념 없이 쓰면 이렇게 꼬이는구나” 하는 깨달음이 컸고, 앞으로는 아무리 익숙한 거라도 구조부터 짚고 가야겠다는 생각이 들었다.
• 또 하나 느낀 건, "무조건 혼자 해결하려고 하지 말자"는 거였다.
  모르는 걸 질문하고, 회고로 정리하고, 팀원과 공유하면서 되려 더 빠르게 개념이 정리됐고, 나만의 언어로 정리하고 설명하는 연습이 진짜 중요하다는 걸 깨달았다.
• 솔직히 이번 주엔 조금 지치기도 했지만. 하루에 배우는 양도 많고, 헷갈리는 것도 많았는데, 그만큼 내가 단단해지고 있다는 느낌도 분명 있었다. 생각보다 너무 즐거웠고 좋은, 재밌는 시간이였다!
  “모르는 게 많다”는 걸 부끄러워하지 않고, “그걸 계속 알아가는 중이다”라고 생각하기로 했다!

💬 메모 [팀에 대한 감사와 나 자신에 대한 믿음]

이번 주는 스파르타 코딩클럽 1주차가 마무리된 시점이기도 하고, 함께했던 팀원들과 헤어지는 시간이기도 했다.
비록 한 주 동안의 짧은 만남이었지만, 팀원들과의 시간이 너무 소중했고, 각자의 자리에서 열심히 해준 모든 분들에게 진심으로 감사한 마음이 크다.

매니저님은 팀장이 그냥 말뿐인 역할이라고 했지만, 나는 한 명 한 명을 진심으로 챙기고 싶은 마음이 더 컸다.
불화 없이 함께 잘 지내고 싶었고, 누가 힘들어도 옆에 있어주고 싶었다. 나는 그런 팀장이 되고 싶었다.
그런 마음을 팀원들도 알아줬을진 모르겠지만 팀원들에게 고마운 한 주였다.
이별이 아쉽지만, 또 다른 팀에서 언젠가 다시 만날 수 있다는 생각에 기대도 된다.

또, 학습 측면에서도 스스로에 대해 다시 한번 확인할 수 있었던 시간이었다.
하루 12시간의 집중이 가능할까 걱정도 됐지만, 마음 한편엔 “나는 할 수 있어”라는 믿음이 있었다.
그 믿음은 어머니가 늘 해주시던 말, “너는 하면 제대로 하는 사람이야”라는 말에서 왔고, 지금의 나를 만든 힘이기도 하다.
늘 믿어주고 응원해주는 우리 가족에게도 이번 기회를 통해 다시 한번 감사함을 느꼈다.

앞으로 배워야 할 것도, 겪어야 할 것도 많지만
나는 잘 해낼 수 있다.
그리고, 점점 더 기대된다. 앞으로도 잘 해보자아!!!!
화이팅!! 오예!!!

📅 이번 주 TIL 목록

📅 이번 주 Study 목록

🌅 오전 (09:00 ~ 13:00)

• Unity & C# 학습
  • object 타입과 메모리 구조 (박싱/언박싱)
  • Queue, Stack의 차이 및 힙 저장 방식
  • delegate, Func, => 문법
  • 어댑터 패턴 이론 및 Unity 캐릭터 예제
  • namespace Adapter의 의미와 활용

🌇 오후 (13:00 ~ 18:00)

• 13:00 ~ 14:00 : 점심시간 🍽️
• 14:00 ~ 16:00 : 프로젝트 발표 🎤
• 16:00 ~ 16:30 : 쉬는 시간
• 16:30 ~ 17:30 : TIL 작성법 강의 📝
• 17:30 ~ 18:00 : 개인 시간

🌙 저녁 (18:00 ~ 21:00)

• 18:00 ~ 19:00 : 저녁시간
• 19:00 ~ 21:00 : 친구와 공부 👭
  • 오전공부 복습! & 친구가 공부한거 같이 복습!

1. 오늘 학습 키워드

• object 타입과 메모리 구조
• 박싱(Boxing) / 언박싱(Unboxing)
• Queue, Stack 저장 방식
• delegate, Func, Action, 람다식 (=>)
• 어댑터 패턴(Adapter Pattern)
• Unity 어댑터 예제 (캐릭터 공격 방식)
• namespace Adapter

2. 오늘 학습 한 내용을 나만의 언어로 정리하기

https://dev-jen.tistory.com/entry/C-Object-Type%EC%98%A4%EB%B8%8C%EC%A0%9D%ED%8A%B8-%ED%83%80%EC%9E%85-Object-Memori%EC%98%A4%EB%B8%8C%EC%A0%9D%ED%8A%B8-%EB%A9%94%EB%AA%A8%EB%A6%AC

https://dev-jen.tistory.com/entry/C-Collection%EC%BB%AC%EB%A0%89%EC%85%98

https://dev-jen.tistory.com/entry/C-List-vs-Array%EB%A6%AC%EC%8A%A4%ED%8A%B8-vs-%EB%B0%B0%EC%97%B4

https://dev-jen.tistory.com/entry/C-Queue%ED%81%90-vs-Stack%EC%8A%A4%ED%83%9D-%EB%A9%94%EB%AA%A8%EB%A6%AC%EA%B5%AC%EC%A1%B0

https://dev-jen.tistory.com/entry/C-Delegate%EB%8D%B8%EB%A6%AC%EA%B2%8C%EC%9D%B4%ED%8A%B8-Lambda-operator%EB%9E%8C%EB%8B%A4-%EC%97%B0%EC%82%B0%EC%9E%90-Lambda%EB%9E%8C%EB%8B%A4%EC%8B%9D

https://dev-jen.tistory.com/entry/C-goto

https://dev-jen.tistory.com/entry/Unity-Adapter-Pattern%EC%96%B4%EB%8C%91%ED%84%B0-%ED%8C%A8%ED%84%B4-%EC%98%88%EC%A0%9C

• object는 모든 타입의 부모이고, 값 타입을 참조 타입처럼 다룰 수 있게 해준다. 하지만 이 과정에서 박싱/언박싱이 일어나 성능상 주의가 필요하다. 박싱된 값은 힙에 저장되며, 언박싱은 스택에 다시 값을 복사하는 것이다.
• Queue와 Stack은 모두 힙에 저장되며, Queue는 먼저 들어온 데이터를 먼저 꺼내는 구조(FIFO), Stack은 나중에 들어온 걸 먼저 꺼내는 구조(LIFO)다. 사용 목적에 따라 구분해서 써야 하며, 둘 다 내부적으로 배열을 사용해 구현된다.
• delegate는 함수를 참조하는 타입으로, 코드의 흐름을 더 유연하게 만들 수 있다. 특히 Func, Action, Predicate 같은 제네릭 델리게이트는 선언을 줄이고 람다식과 조합해서 자주 쓰인다.
• =>는 람다식 문법으로, "입력값이 이렇게 동작한다"는 의미로 사용된다. 익명 함수를 간결하게 표현할 수 있어 LINQ나 이벤트 처리에 자주 활용된다.
• 어댑터 패턴은 서로 호환되지 않는 클래스 구조를 중간에서 연결해주는 구조로, 기존 코드를 건드리지 않고 외부 시스템을 도입할 수 있게 해준다. Unity에서도 IEnemy를 기준으로 LegacyOrcAdapter를 만들어 외부 클래스와 호환성을 유지하는 예제를 직접 구현해보았다.
• namespace Adapter처럼 네임스페이스를 적절히 나누면 구조가 명확해지고 클래스 충돌을 피할 수 있다. 특히 프로젝트 규모가 커질수록 네임스페이스 정리는 필수다.

3. 학습하며 겪었던 문제점 & 에러

1. object와 메모리 구조 헷갈림

• 문제정의: object는 값 타입일 때 스택에 저장된다고 오해함
• 시도: 그림을 통해 힙/스택 구조 확인
• 해결방법: object도 참조 타입이기 때문에 박싱 시 힙에 저장됨을 학습
• 새롭게 알게 된 점: object 타입의 변수는 실제 데이터를 힙에 저장하고, 변수에는 주소가 들어간다
• 다시 만나게 된다면: 메모리 구조를 항상 그림으로 함께 확인할 것

2. 어댑터 패턴 예시가 추상적으로 느껴졌음

• 문제정의: 입력 시스템 예제는 너무 복잡하게 느껴짐
• 시도: 캐릭터 공격 구조 예제로 변경해서 이해
• 해결방법: IEnemy → Goblin, LegacyOrcAdapter → LegacyOrc 예제로 쉽게 이해
• 새롭게 알게 된 점: 인터페이스 기반 설계의 유연성과 어댑터 패턴의 실용성
• 다시 만나게 된다면: 복잡한 구조는 단순한 예제로 바꿔서 학습할 것 & 유니티 예제로 학습

3. delegate와 Func의 시그니처 이해 부족

• 문제정의: Func<int, int, int>는 뭘 의미하는지 처음에 감이 안 옴
• 시도: 문법 구조 분석 → 매개변수와 반환값이 어떤 역할인지 학습
• 해결방법: Func<매개변수1, 매개변수2, 반환값> 구조임을 알게 됨
• 새롭게 알게 된 점: Func<int, int, int>는 int a, int b를 받아서 int를 반환하는 함수
• 다시 만나게 된다면: 직접 함수 시그니처를 풀어 쓰면서 이해할 것

4. 람다식의 => 문법 생소함

• 문제정의: => 기호가 무슨 의미인지, 어떤 구조인지 혼란스러웠음
• 시도: 일반 함수와 비교하면서 람다식을 해석
• 해결방법: =>는 "이렇게 동작한다"는 의미로, 익명 함수 정의임을 이해
• 새롭게 알게 된 점: 람다식은 익명 함수이며, delegate나 Func에 바로 넣어 쓸 수 있음
• 다시 만나게 된다면: 기존 함수 → 람다식 변환 예제를 더 연습할 것

5. Queue와 Stack의 저장 위치 오해

• 문제정의: 큐/스택이 스택 메모리에 저장된다고 착각
• 시도: 힙/스택 구조 그림을 통해 확인
• 해결방법: Queue<T>, Stack<T>는 참조 타입이라 힙에 저장됨을 명확히 이해
• 새롭게 알게 된 점: 내부에 배열을 가지며, 그 배열도 힙에 저장됨
• 다시 만나게 된다면: 스택/힙 구조를 항상 객체 기준으로 생각할 것

4. 메모

오늘 오전에도 원래 알던것들도 있었지만 처음 배웠던것도 있었다! 앞으로도 공부했던것들 잘 복습하면서 하나하나 잘 배워가자 이번 월~금을 지내며 솔직히 내가 이렇게까지 하게될줄 몰랐다 공부를 공부라고 생각하기보단 하나씩 의문점을 가지고 생각하고 하다보니 12시간이 너무 금방갔다 시작하기전에는 “말이 12시간이지 당연히 쉽지 않겠지” 라고 생각했지만 막상 공부시간등등을 생각하지않고 진행하다보니 너무 시간이 빨랐다. 앞으로의 시간도 너무 기대된다!

오늘 저녁에는 대학교를 같이 다녔던 5조의 혜현이라는 친구와 같이 오늘 오전에 공부했던걸 각자 얘기하며 공부했다 나는 확실히 혼자 하는 것 보단 소통하며 서로 뭘 알았고 이해했는지, 뭘 모르고 있었는지 서로 얘기하며 토론하는 식의 공부를 굉장히 좋아한다. 앞으로도 계속 잘 응용해보며 열심히 공부해보자아ㅏ!!!!

이번 1주차 팀 프로젝트를 진행하면서 팀원들도 너무 좋은 팀원들을 만나서 너무 즐겁게 같이 개발했는데 다음주면 다른 팀으로 바뀐다니 너무 아쉬웠다 저번 사전캠프 팀도 좋은 분들을 만나서 좋았었는데 항상 마지막이되면 너무 아쉽다..

뭐 아예 헤어지는건 아니니깐! 그래도 또 새로운 좋은 인연들이 많을거라고 생각한다! 앞으로의 인연들을 기대하면서 하루하루 열심히 해보자!!! 오예!!!

✅ 어댑터 패턴이란?

서로 다른 인터페이스를 가진 두 클래스가 함께 동작하도록 중간에 "변환기" 역할을 해주는 패턴

📌 한 줄 요약:
"호환되지 않는 인터페이스를 연결해주는 중간 어댑터 클래스"

✅ 언제 쓰일까?

• 기존 코드 or 라이브러리 인터페이스를 바꾸지 않고 사용하고 싶을 때
• 인터페이스 불일치 때문에 직접 호출이 안 될 때
• 예전 코드와 새로운 코드를 자연스럽게 연결하고 싶을 때

✅ 예제 시나리오: 충전기 어댑터

• 한국 콘센트는 220V
• 미국 전자제품은 110V

어댑터를 끼우면 한국 콘센트에 미국 기기를 연결할 수 있어!

✅ C# 코드 예제

1️⃣ 기존 시스템 (한국 방식)

interface ITarget
{
    void Request();  // 우리가 원하는 방식
}

class KoreanCharger : ITarget
{
    public void Request()
    {
        Console.WriteLine("220V로 충전합니다.");
    }
}

2️⃣ 호환되지 않는 외부 클래스 (미국 방식)

class AmericanDevice
{
    public void ConnectWith110V()
    {
        Console.WriteLine("110V에 연결되었습니다.");
    }
}

3️⃣ 어댑터 클래스

class Adapter : ITarget
{
    private AmericanDevice _device;

    public Adapter(AmericanDevice device)
    {
        _device = device;
    }

    public void Request()
    {
        // 220V 요청을 110V 방식으로 변환
        _device.ConnectWith110V();
    }
}

4️⃣ 사용 코드

ITarget charger1 = new KoreanCharger();
charger1.Request(); // ✅ 220V로 충전합니다.

ITarget charger2 = new Adapter(new AmericanDevice());
charger2.Request(); // ✅ 110V에 연결되었습니다.

✅ 구조 요약 (클래스 관계)

[ITarget] <─── [Adapter] ───> [AmericanDevice]
          ↑
[KoreanCharger] (직접 구현)

✅ 어댑터 패턴 종류

✅ 실제 사용 예 (Unity에서도 유용)

• Unity의 InputSystem이 바뀌었을 때, 기존 방식과 연결할 때
• 외부 API 라이브러리와 내부 구조 연결할 때
• 레거시 시스템 유지하면서 새 구조 연동할 때

✅ 요약

❓

흠..이렇게 봐서는 어댑터 패턴이 얼마나 중요한지 아직은 잘 모르겠다 좀 더 자세한 예시 코드를 보자.

일단 어댑터를 사용하는 방법을 제대로 알아보죠!

✅ 1. namespace Adapter가 왜 등장할까?

🔸 namespace는 이름 충돌을 방지하고 코드를 구조적으로 정리하기 위한 C#의 기능이야.

예를 들어, 이런 상황 생각해봐:

// Game 안에 있는 Enemy
namespace Game
{
    public class Enemy { }
}

// 외부에서 받아온 LegacyEnemy도 Enemy 클래스가 있음
namespace Legacy
{
    public class Enemy { }
}

이런 경우 Enemy가 둘이라 충돌해.
그래서 Game.Enemy, Legacy.Enemy처럼 네임스페이스를 명시해줘야 돼.

✅ 2. 어댑터 쓸 때도 마찬가지

보통 어댑터 코드는 별도의 Adapter 네임스페이스 안에 넣어 정리해.

namespace Adapter
{
    public class LegacyEnemyAdapter : MonoBehaviour, IEnemy
    {
        ...
    }
}

그리고 다른 코드에서 사용할 때는 이렇게 써:

using Adapter;

// 또는 명시적으로 접근
Adapter.LegacyEnemyAdapter adapter = new Adapter.LegacyEnemyAdapter();

✅ 3. 언제 Adapter.를 붙여야 할까?

✅ Unity에서 실제로는?

Unity에서는 대부분 클래스가 MonoBehaviour를 상속하고
스크립트를 오브젝트에 붙여서 인스펙터에서 연결하니까
Adapter.LegacyEnemyAdapter 라고 직접 쓰는 일은 드물어.

하지만 코드에서 직접 생성하거나, 네임스페이스 충돌이 있을 땐 명시적으로 써줘야 해:

IEnemy enemy = new Adapter.LegacyEnemyAdapter();

✅ 한 줄 요약

어댑터 클래스를 namespace Adapter 안에 넣으면
구조를 명확히 하고, 다른 클래스 이름과 충돌하지 않게 도와준다.
필요할 땐 Adapter.ClassName 으로 명시적으로 접근하면 된다.

✅

실제로 어댑터를 사용할때는 namespace를 사용하는듯합니다.

그리고 어댑터가 적용된거는 using으로만 작성해도 충분한듯해요!

다음 어댑터 제대로된 예제 코드를 보죠!

🎮 예제 시나리오:

우리 게임은 IInputHandler 라는 인터페이스로 입력을 처리하고 있음.
하지만 외부에서 제공된 LegacyInput 클래스는 우리가 쓰는 구조와 다름.
→ 어댑터를 만들어서 LegacyInput을 IInputHandler처럼 사용할 수 있도록 하자.

✅ 1. 인터페이스: 우리가 사용하는 입력 방식

// IInputHandler.cs
public interface IInputHandler
{
    void HandleInput();
}

✅ 2. 정상적인 Unity 입력 구현 (키보드로 움직임)

// KeyboardInputHandler.cs
using UnityEngine;

public class KeyboardInputHandler : MonoBehaviour, IInputHandler
{
    public void HandleInput()
    {
        if (Input.GetKeyDown(KeyCode.Space))
        {
            Debug.Log("스페이스바 눌림 (키보드)");
        }
    }
}

✅ 3. 외부에서 가져온 입력 시스템 (호환 안 됨)

// LegacyInput.cs
using UnityEngine;

public class LegacyInput
{
    public bool IsTouched()
    {
        // 가상의 외부 입력 방식 (예: 터치스크린)
        return Input.touchCount > 0;
    }
}

✅ 4. 어댑터 클래스 만들기

// Adapter/LegacyInputAdapter.cs
using UnityEngine;
using AdapterNamespace;

namespace AdapterNamespace
{
    public class LegacyInputAdapter : MonoBehaviour, IInputHandler
    {
        private LegacyInput _legacyInput;

        private void Awake()
        {
            _legacyInput = new LegacyInput();
        }

        public void HandleInput()
        {
            if (_legacyInput.IsTouched())
            {
                Debug.Log("터치 입력 감지됨 (어댑터)");
            }
        }
    }
}

✅ 5. 플레이어 컨트롤러 — 어댑터든 키보드든 상관 없이 처리 가능!

// Player.cs
using UnityEngine;

public class Player : MonoBehaviour
{
    public MonoBehaviour inputSource;

    private IInputHandler _inputHandler;

    private void Start()
    {
        _inputHandler = inputSource as IInputHandler;

        if (_inputHandler == null)
        {
            Debug.LogError("inputSource는 IInputHandler를 구현해야 합니다!");
        }
    }

    private void Update()
    {
        _inputHandler?.HandleInput();
    }
}

✅ Unity 인스펙터 설정

1. Player 오브젝트에 Player.cs 컴포넌트 추가
2. inputSource 슬롯에 아래 중 하나를 드래그:
   • KeyboardInputHandler 컴포넌트 붙인 오브젝트
   • LegacyInputAdapter 컴포넌트 붙인 오브젝트

➡️ 어떤 걸 연결해도 작동 ✅

✅ 결과

✅ 요약 구조

[Player] → IInputHandler ← [KeyboardInputHandler]
                          ← [LegacyInputAdapter → LegacyInput]

• LegacyInput 은 우리가 바꿀 수 없는 외부 시스템
• LegacyInputAdapter 가 어댑터 역할
• Player 입장에선 어떤 입력 시스템이든 같은 방식으로 처리함

✅

이렇게 예제 코드로 예시를 들어봤는데요 흠.. 사실 저도 아직까지 막 와닿진 않네요 ㅠㅜ

다음에 유니티로 직접 개발해봐야겠습니다! 사실 직접해보는게 제일 빠르고 이해가 좋은거같아요!