📚 Part 2. 동시성 프로그래밍과 엔지니어링 원칙

1. Asynchronous Programming (비동기 프로그래밍)

🔄 개념 (Sync vs Async)

• Synchronous (동기): 요청(Request)을 보내고 응답(Response)이 올 때까지 기다림 (Blocking).
• Asynchronous (비동기): 요청을 보내고 응답을 기다리지 않고 다른 작업을 수행함 (Non-blocking).

🧵 Threading vs Python Asyncio (Context Switching)

• Threading (멀티스레드):
  • OS가 관리: Context Switching(문맥 교환)이 OS에 의해 일어납니다.
  • 비용: Context Switching은 꽤 비싼(무거운) 작업입니다.
  • 제어 불가능: 언제 다른 스레드로 넘어갈지 개발자가 예측할 수 없습니다. 코드 한 줄 실행 도중에도 OS가 강제로 스위칭할 수 있습니다.
  • 예) I/O 작업 시 OS가 강제로 다른 스레드로 전환.
• Asyncio (비동기 프로그래밍):
  • App(Event Loop)이 관리: Context Switching이 Application 레벨에서 일어납니다. (단일 스레드 내)
  • 비용: OS의 개입이 없어 리소스 소모가 적고 저렴합니다.
  • 제어 가능: 단일 스레드(Single Thread)라고 가정했을 때, 개발자가 await를 걸지 않는 한 다른 작업이 끼어들지 못합니다. 이 점을 활용해 락(Lock) 없이도 효율적인 코딩이 가능합니다.
  • I/O Bound 작업(네트워크, 디스크) 효율 극대화

⚠️ 저지르기 쉬운 실수 (Common Pitfalls)

1. Blocking Event Loop:
   • async 함수 내에서 time.sleep()이나 일반 requests.get() 같은 Blocking 함수를 사용하면, 전체 Event Loop가 멈춰버려 비동기의 이점이 사라짐.
   • CPU Bound 작업(무거운 연산)도 Event Loop를 독점하므로 주의 필요.
2. Fire and Forget (종료 대기 미흡):
   • main 함수가 Task의 완료를 기다리지(await) 않고 종료되면, 실행 중이던 Task(예: cook)도 강제 종료됨.
3. Exception Handling:
   • Task 내부에서 발생한 예외를 처리하지 않으면, Task가 조용히 죽거나 메모리 누수가 발생할 수 있음 (최신 파이썬에서는 경고 발생).

---

2. GIL (Global Interpreter Lock)

🔒 GIL이란?

• 정의: Python 인터프리터(CPython)가 한 번에 하나의 스레드만 Python 바이트코드를 실행하도록 제한하는 Mutex(잠금)입니다.
• 발음: '길' 혹은 '질'이라고 읽습니다.
• 존재 이유:
  1. Reference Counting 보호: Python은 객체의 참조 횟수(Reference Count)를 통해 메모리를 관리하는데, 여러 스레드가 동시에 이 숫자를 건드리면 메모리 누수나 잘못된 해제(Race Condition)가 발생할 수 있습니다. 이를 막기 위해 GIL을 사용합니다.
  2. Thread-safe 하지 않은 C Extensions: 초창기 C 라이브러리들이 멀티스레드를 고려하지 않았기 때문에 안전장치가 필요했습니다.
  3. 역사적 배경: Python이 개발된 1990년대에는 멀티코어 프로세서가 드물었으므로, 당시에는 합당하고 효율적인 선택이었습니다.

📉 GIL의 영향과 미래

• CPU-bound 작업의 한계:
  • 계산 위주의 작업(CPU-bound)을 멀티스레드로 돌리면, GIL 때문에 병렬 처리가 안 될 뿐더러 잦은 Context Switching으로 오히려 싱글 스레드보다 성능이 떨어질 수 있습니다.
• I/O-bound 작업: 네트워크나 파일 처리 등 대기 시간이 긴 작업에서는 GIL이 해제되므로 멀티스레드도 유용합니다.
• Python 3.13+: 실험적으로 GIL을 비활성화하는 기능이 추가되었으며, 향후 버전(3.14 등)에서는 GIL이 제거된 'Free-threaded Python'이 표준이 될 예정입니다.

💡 퀴즈: Process vs Thread

• Process (프로세스):
  • 리소스의 오너(Owner). 독립된 메모리 공간을 가진 실행 중인 프로그램 단위.
  • 멀티코어를 활용하려면 프로세스를 여러 개 띄워야(Multiprocessing) 하며, 서로 데이터를 주고받을 때(IPC) 리소스를 통째로 공유/복사해야 하는 비용이 듭니다.
• Thread (스레드):
  • CPU의 스케줄링(Switching) 단위.
  • 하나의 프로세스 내에서 자원(코드, 데이터, 힙)을 공유하므로 통신 비용이 적습니다.

---

3. GC (Garbage Collection)

Python은 기본적으로 Reference Counting을 사용하며, 이를 보완하기 위해 Generational Garbage Collection(세대별 가비지 컬렉션)을 함께 사용합니다.

🔄 Reference Counting (참조 횟수 계산)

• 객체가 참조될 때마다 카운트를 증가시키고, 참조가 해제되면 감소시킵니다.
• Count == 0이 되는 순간 메모리에서 즉시 해제될 수 있습니다.
• 한계: Cyclic Reference(순환 참조) 문제(서로가 서로를 참조해 카운트가 0이 안 되는 상황)를 해결하지 못합니다.

♻️ Generational GC (세대별 GC)

순환 참조 문제를 해결하고 효율을 높이기 위해 객체를 3개의 세대(Generation 0, 1, 2)로 나누어 관리합니다.

1. 가설 (Generational Hypothesis): "대부분의 객체는 금방 죽는다(Life-cycle이 짧다). 반면, 오래 살아남은 객체는 계속 오래 살 것이다."
2. 동작 방식:
   • 모든 새 객체는 Gen 0에서 시작합니다.
   • GC에서 살아남으면 Gen 1, 또 살아남으면 Gen 2로 승격됩니다.
   • Gen 0을 가장 자주 검사하고, Gen 2는 아주 가끔 검사합니다.
3. GC Threshold (임계값): (700, 10, 10) (기본값 예시)
   • 700: (객체 생성 수 - 해제 수)가 700을 넘으면 Gen 0 GC 실행.
   • 10: Gen 0 GC가 10번 실행될 때 Gen 1 GC 1번 실행.
   • 10: Gen 1 GC가 10번 실행될 때 Gen 2 GC 1번 실행 (전체 메모리 검사).
   • Tip: Gen 2 검사는 시간이 오래 걸리므로, 성능을 위해 Threshold를 조절하거나 아예 막는 경우도 있습니다.

---

4. 코드 원칙 (Code Principles)

이 원칙들은 파이썬뿐만 아니라 모든 프로그래밍 언어와 현업 개발 환경에서 통용되는 핵심 가치입니다. AI 코딩 시대에도 여전히 유효하며, 결국 핵심은 '커뮤니케이션 능력'으로 귀결됩니다.

1️⃣ DRY (Don't Repeat Yourself)

"똑같은 코드를 반복하지 마라"

• 현업의 현실: 처음부터 개발하는 경우보다 기존 코드를 유지보수하거나 기능을 추가하는 경우가 훨씬 많음.
• 문제점:
  • 기존 코드 이해 부족: 기존에 이미 구현된 기능이 있는지 모르고 새로 만드는 경우가 발생.
  • AI의 한계: AI는 새로운 코드를 잘 짜주지만, 기존 프로젝트의 문맥을 완벽히 파악하여 "기존 함수를 재사용하라"고 가이드해주지는 못함 (사람의 검토 필수).
• 주의사항 (과유불급): 추상화는 재사용성을 높이지만, 과도한 추상화는 오히려 가독성(Readability)을 해칠 수 있음. 합리적인 수준에서 타협이 필요.

2️⃣ KISS (Keep It Simple, Stupid)

"단순하게 유지하라"

• 문제점:
  • 과시욕과 욕심: 아는 것이 많은 개발자가 디자인 패턴이나 고급 문법(Meta-class 등)을 남용하여 코드를 복잡하게 만듦.
  • 조기 최적화: 미래의 유연성이나 성능 최적화를 미리 걱정하여 구조를 복잡하게 짬.
• 결과: 코드의 흐름을 파악하기 어려워지고, 유지보수성이 급격히 떨어짐.
• 참고 용어: RTFM (Read The Fxxx Manual) - 질문하기 전에 매뉴얼을 먼저 읽어라.

3️⃣ YAGNI (You Aren't Gonna Need It)

"그건 나중에 필요하지 않을 거야 (지금 필요한 것만 구현해라)"

• 문제점:
  • 상상에 의한 개발: 아무도 요구하지 않았는데 "나중에 필요할 것 같아서" 혼자 구현함.
• 핵심: 커뮤니케이션 부재. 필요해 보인다면 동료와 상의하고 공식 요구사항으로 만든 뒤 구현해야 함.

---

5. 디자인 패턴 (Design Patterns)

주니어 단계를 넘어 중급 개발자로 성장하기 위해 반드시 학습해야 하는 영역입니다.

📚 왜 디자인 패턴을 배워야 하는가?

1. Best Practice 학습: 수많은 시행착오 끝에 정립된 '가장 효율적인 해결책'임.
2. 공통 개발 언어: 동료와의 의사소통 효율성 증대.
   • 예: "여기는 Factory Method 패턴으로 풀죠"라고 했을 때 즉시 이해해야 함.
3. 내 가치 증명: 디자인 패턴을 모르면 수준 높은 기술 대화가 불가능하며, 좋은 회사에 들어가기 어려움.

🏗️ 주요 디자인 패턴 (GoF - Gang of Four)

GoF(Gang of Four)라 불리는 4명의 저자가 정리한 23가지 패턴이 대표적입니다.

분류	설명	패턴 종류
생성 패턴 (Creational)	객체 생성 메커니즘을 결정	Abstract Factory, Builder, Factory Method, Prototype, Singleton
구조 패턴 (Structural)	클래스와 객체를 조합해 더 큰 구조를 만듦	Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy
행위 패턴 (Behavioral)	객체 간의 알고리즘과 책임 분배	Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method

💡 학습 조언

• 끊임없는 공부: CS(Computer Science) 분야는 매일 공부하지 않으면 뒤처짐.
• 이론과 실무의 병행: 책으로만 읽으면 금방 잊혀짐. 실무 코드에 적용해보고 검토하는 과정을 거쳐야 내 것이 됨.