문제 상황

FastAPI 서버가 메모리 부족으로 반복적으로 종료되는 현상 발생

현상: Pod가 주기적으로 재시작
원인 추정: OOM (Out of Memory) Kill

원인 분석

Kubernetes deployment 설정을 확인한 결과, 메모리 리소스 할당이 부족함을 발견. 초기에는 경량 데이터와 서비스를 제공하던 역할만 하고 있어서 메모리 할당량을 적게 부여한 상태였음.

기존 설정:

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"    # 너무 낮음
  limits:
    cpu: "500m"
    memory: "512Mi"    # ML 작업에 부족

문제점:

• FastAPI 애플리케이션이 ML 관련 작업 수행 (pandas, numpy, quantstats 등)
• 차트 생성, 보고서 생성 등 메모리 intensive한 작업이 늘어남
• 512Mi limit를 초과하면 OOM Kill 발생 → Pod 종료 → 재시작 반복

해결 방법

메모리 리소스 할당량 증가:

resources:
  requests:
    cpu: "100m"
    memory: "512Mi"    # 128Mi → 512Mi (4배)
  limits:
    cpu: "500m"
    memory: "2Gi"      # 512Mi → 2Gi (4배)

적용:

kubectl apply -f kubernetes/deployment.yaml

변경 사항 적용 후 rolling update를 통해 새로운 메모리 설정으로 pod 재시작.

학습 포인트

1. Kubernetes Memory Requests vs Limits

Memory Requests (요청량):

• Pod 스케줄링 시 사용 (어느 노드에 배치할지 결정)
• 실제 메모리 사용량을 제한하지 않음
• requests가 낮아도 pod가 바로 종료되지는 않음

Memory Limits (제한량):

• 실제 메모리 사용량의 상한선
• 이 값을 초과하면 OOM Kill 발생 → Pod 강제 종료
• 이게 메모리 부족으로 pod가 죽는 진짜 원인

2. Requests가 낮을 때의 영향

1. 스케줄링: requests가 낮으면 어떤 노드에도 쉽게 배치 가능
2. Eviction 우선순위: 노드 전체 메모리 부족 시 requests가 낮은 pod부터 축출될 수 있음
3. 리소스 경쟁: 실제로 많은 메모리를 사용하는데 requests가 낮으면 다른 pod들과 메모리 경쟁

3. 리소스 할당 전략

권장 설정:

• requests = 실제 평균 사용량
• limits = 피크 사용량 + 여유분

모니터링:

# Pod 메모리 사용량 확인
kubectl top pods -n fastapi-app

# Pod 상세 정보
kubectl describe pod <pod-name> -n fastapi-app

추가 고려사항

고가용성 (High Availability)

현재 deployment 설정:

replicas: 2
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

질문: 노드 1개 vs 노드 2개?

답변: 프로덕션 환경에서는 노드 2개 권장

이유:

1. 고가용성: 노드 1개 장애 시에도 서비스 계속 운영
2. 무중단 배포: maxUnavailable: 0 설정과 조합하여 진정한 무중단 배포
3. 장애 격리: 한 노드의 하드웨어/커널 문제가 전체 서비스에 영향 없음
4. Pod 분산: 2개 replica가 서로 다른 노드에 배치되어 리스크 분산

추가 최적화 - Pod Anti-affinity:

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - fastapi
          topologyKey: kubernetes.io/hostname

이 설정은 2개 pod를 서로 다른 노드에 배치하도록 유도함.

Replica 제대로 작동하는지 확인

# Pod 개수 확인
kubectl get pods -n fastapi-app -l app=fastapi

# Pod가 어느 노드에 있는지 확인 (분산되어 있는지)
kubectl get pods -n fastapi-app -l app=fastapi -o wide

# Deployment 상태 확인
kubectl get deployment -n fastapi-app fastapi-deployment

주의: 노드가 1개밖에 없으면 pod 2개가 같은 노드에 배치됨 → 고가용성 없음

다음 액션

• 메모리 사용량 모니터링 (kubectl top pods)
• 여전히 OOM 발생 시 limits를 4Gi까지 증가 고려
• 노드 개수 및 분산 상태 확인
• 필요시 Pod Anti-affinity 설정 추가

1. 소는 가축이 아니다.

나는 소가 가축이 아니라고 생각한다. 이 판단은 내가 소고기를 먹는 것을 좋아하는 것과는 무관하게 성립하는 명제다. 내게 '소'는 어떠한 집단적 범주이기 이전에 하나의 개별자로서 생명을 의미한다. 소가 가축이 된 이야기는 인류의 문명적 서사와 함께할 뿐, 소를 인식하는 나의 인식 체계의 근본 명제가 되지는 못하는 셈이다. 가축 이외의 가능성을 타진하는 것이 소에 대한 최소한의 배려라고 생각한다.

2. 개발자는 개발하는 사람이 아니다.

이 명제는 소에 대한 나의 사유와 동일한 궤적을 그린다. 개발자라는 단어는 이미 기술 문명 사회의 거대한 서사 속에서 굳어진 기표가 되었다. 이 기표는 문제를 효율적으로 해결하는 사람, 코드를 짜는 기계, 특정 기술 스택의 전문가, 높은 연봉을 받는 직업인 같은 일련의 기의를 불러일으킨다. 사회는 이 기표가 함축하는 기의를 확대 재생산하며 소비한다. 이 집단적 기의의 압박 속에서 개별자는 가축화의 위험에 놓인다.

3. 커리어는 여정이 아니다.

커리어가 하나의 여정이라는 관념은 새로운 신화다. 이 관념에는 개인의 파편화된 밥벌이 경험을 유기적이고 통합적인 계획의 대상으로 만드는 힘이 있다. 현대 사회의 불안한 노동 환경 위에 휩쓸려가지 않도록 부표를 세우는 정박성이 있는 셈이다. 하지만 여기에는 한 가지 부작용이 있다. 바로 오늘의 체험을 약화시킨다는 점이다. 체험을 약화시키는 질문은 바로 이런 것이다. '다음 직급으로 승진하기 위해 오늘 하루 나는 충분히 발전했던가?' 이같은 질문이 독극물처럼 느껴지는 이유는 발견의 즐거움, 배움에 감탄하는 존재로서의 자신을 질식시키기 때문이다. 잘못된 질문은 매일의 하루를 이력서의 재료로 축소시키고 만다.

4. 개발자는 개발을 체험하는 존재다.

개발자는 매번 새로운 코드를 작성할 때마다 단순한 기능 구현 이상의 무언가를 투영한다. 그가 투영하는 것은 자신의 존재와 생명이다. 밤샘 작업 끝에 찾아온 깨달음, 디버깅 속에서 얻은 고독한 기쁨, 또는 자신의 서비스가 누군가의 삶을 개선할 때 느끼는 미묘한 성취감 등이야말로 '개발자'라는 기표가 포착하지 못하는 살아있는 기의이다. 소를 가축이라는 범주로 가두지 않고 생명으로 인식하듯, 개발자 역시 직업이라는 프레임 너머의 주체로 호명되어야 까닭은 이러한 창조성을 부흥시키기 위함이다.

5. 개발자는 가축이 아니다.

소가 가축이 아니듯, 개발자도 개발하는 사람이 아니다. 이 선언은 개발자의 직무를 부정하는 것이 아니라 직무가 존재의 전부가 아님을 강조한다. '개발자'라는 기표를 잠시 내려놓을 때, 우리는 그 자리에 서 있는 한 명의 복잡하고 입체적인 인간을 발견하게 된다. 이 인간은 가축이 아니다. 그는 개발자라는 기표의 울타리를 넘어설 수 있는 생명력을 지닌 존재다. 나는 이같은 새로운 언어적 코드의 발명과 매핑이야말로 개발자가 추구할 수 있는 궁극의 개발 활동이라 생각한다. 개발자는 결국, 자신을 설명하는 언어를 발명하는 존재다.

우선순위 큐(Priority Queue)

데이터를 다루다 보면 여러 작업 중 ‘가장 중요한 것’을 빠르게 처리해야 하는 상황이 자주 발생한다.우선순위 큐는 이러한 데이터를 효율적으로 관리하기 위한 자료구조이며 핵심 연산은 다음과 같다.

• 원소 삽입
• 최대(또는 최소) 원소 반환
• 최대(또는 최소) 원소 삭제

힙(Heap)

힙은 우선순위 큐를 효율적으로 구현하기 위해 사용되는 전형적인 자료구조다. 힙은 우선순위 큐를 구현하기 위해 완전 이진트리(complete binary tree)라는 구조를 사용한다.

• 이진트리: 모든 노드가 2개 이하의 자식을 가진 트리
• 포화 이진트리: 모든 내부 노드가 정확히 2개의 자식을 가진 트리
• 완전 이진트리: 마지막 레벨을 제외한 모든 레벨이 꽉 차 있고, 마지막 레벨의 노드는 왼쪽부터 채워진 트리

Part 2. Heap 구현

힙에 값 추가하기(percolate up)

힙에 값을 추가할 때는 추가하는 값을 리스트의 가장 마지막에 추가한 다음 부모와의 값 비교를 통해 값을 올리는 percolate up 작업을 수행한다.

def percolate_up(A, i):
    parent = (i-1)//2
    if i > 0 and A[parent] < A[i]:
        A[parent], A[i] = A[i], A[parent]
        percolate_up(A, parent)

힙에 값 삭제하기(percolate down)

힙에서 값을 삭제할 때는 0번째 인덱스에 위치한 값을 반환하고, 리스트의 마지막에 위치한 값을 0번째 인덱스로 옮겨와서 percolate down 작업을 수행한다.

def percolate_down(A, i):
    left = 2*i+1
    right = 2*i+2
    n = len(A)

    largest = i

    if left < n and A[largest] < A[left]:
        largest = left

    if right < n and A[largest] < A[right]:
        largest = right

    if largest != i:
        A[i], A[largest] = A[largest], A[i]
        percolate_down(A, largest)

힙 생성

임의의 리스트를 힙으로 만들기 위해서는 트리의 모든 서브트리가 힙 특성을 만족해야 한다. 이를 위해 리프 노드의 부모인 (n-1)//2 인덱스부터 시작해, 각 노드에 대해 percolate_down을 수행한다.

for i in range((n-1)//2, -1, -1):
    percolate_down(A, i)

이 방식은 bottom-up 접근으로서, 전체 리스트를 한 번에 힙으로 만든다.

Part 3. 심화

Q) heapify()는 왜 bottom-up(percolate-down) 방식을 사용하는가?

힙을 만드는 방법은 두 가지가 있다.

방법 A. top-down 방식(percolate-up)

초기 상태: 빈 힙 리스트의 모든 원소를 하나씩 push

for x in array:
    heappush(heap, x)

방법 B. bottom-up 방식(percolate-down)

초기 상태: 리스트 전체가 배열로 전체 아래처럼 한 번에 heapify

i = (n-1)//2 down to 0:
    percolate_down(array, i)

heapify는 결국 percolate-down 기반이 훨씬 효율적이기 때문에 bottom-up을 사용한다.

Q) 왜 percolate-up은 비효율적(O(N log N))인가?

• percolate-up은 노드가 들어올 때 부모 방향으로 이동한다.
• 문제는 leaf 노드는 움직일 때마다 log N만큼 올라와야 가능하다.
• 전체 노드의 약 절반이 leaf이기 때문에 이동 비용이 커질 확률이 매우 높다.

Q) 왜 bottom-up + percolate-down은 효율적(O(N))인가?

• 트리의 아래쪽에는 노드가 엄청 많다.
• 하지만 leaf는 percolate-down 비용이 거의 0이다.
• 많은 노드는 거의 이동이 없고, 적은 노드는 이동이 많아 선형 시간으로 수렴한다.

Amortized Analysis (percolate-down)

힙은 완전 이진트리이므로, 루트에서부터의 레벨을 다음과 같이 정의한다.

• 레벨 0: 루트 노드
• 레벨 1: 루트의 자식들
• 레벨 2: 그 아래 레벨
• 레벨 H: 가장 아래 리프 (H = 트리 높이 ≈ ⌊log₂n⌋)

1. 레벨 k에 있는 노드 수: $\frac{n}{2^{k+1}}$ k가 커질수록 노드 수가 기하급수적으로 증가한다.

2. 레벨 k가 내려갈 수 있는 최대 percolate-down 깊이 레벨 k의 노드가 내려갈 수 있는 최대 깊이는 H-k이다. 위 레벨일수록 percolate 비용은 크지만 노드 수가 거의 없다.

3. 전체 heapify 비용 공식 레벨 k의 총 비용 $$ T(n) = (n / 2^{k+1})(H-k) $$

전체 heapify 비용: $$ T(n) = \sum (n / 2^{k+1})(H-k) $$

시각 신호는 단일 경로로 의사결정을 결정하지 않는다. 감각 정보는 전정기관(Vestibular System), 고유수용감각(Proprioception), 과거 환경 경험 등의 다양한 신호원으로 보완되며, 하나의 모듈이 오류를 내더라도 즉시 균형 보정이 이루어진다. 즉, 인간은 한 번의 잘못된 판단이 치명적 실패로 전파되지 않도록 계층적으로 분리된 다중 의사결정 경로와 상호 보정 루프를 통해 생존성을 유지한다.

이와 같은 관점에서 보면, 고신뢰도를 요구하는 시스템일수록 정확성(Accuracy)보다 견고성(Robustness)을 우선하는 것이 논리적으로 정합적이다. 특히 금융 시장과 같이 고잡음·비정상(non-stationary) 환경에서 작동하는 정량적 트레이딩 시스템은, “항상 맞는 모델”을 설계하기보다, “틀려도 무너지지 않는 구조”를 설계해야 한다.

파이썬 프로젝트 관리의 핵심은 파이썬 버전과 의존성을 관리하는 것이다. 이를 위해 가장 기본적으로 알아야 하는 명령어는 파이썬 설치 경로 확인 방법과 파이썬 설치 방법이다. 또한 패키지들의 의존성을 잘 관리하기 위해서는 poetry와 같은 프로젝트 관리 도구를 잘 숙지하고 있는 것도 중요하다.

1. 파이썬 설치 경로 확인

설치 경로 확인 명령어

파이썬 설치 위치를 확인하면 현재 사용 중인 파이썬 인터프리터가 어디에 있고, 어떤 도구에 의해 설치되었는지도 알 수 있다. 또한 poetry와 같은 패키지 관리 도구를 사용할 때 파이썬 버전을 지정할 수 있다.

# python 명령어가 가리키는 실행 파일의 위치
$ which python  

# python3 명령어가 가리키는 실행 파일의 위치
$ which python3  

# python3.11 명령어가 가리키는 실행 파일의 위치
$ which python3.11  

# Poetry를 사용하여 프로젝트에서 python3.11 버전 사용
$ poetry env use /path/to/python3.11  

2) 파이썬 설치 도구별 설치 경로 (Intel)

1️⃣ Homebrew: /usr/local/bin/python3.x 2️⃣ pyenv: ~/.pyenv/versions/3.x.x/bin/python 3️⃣ Anaconda: 기본 환경: /Users/username/anaconda3/bin/python 가상 환경: /Users/username/anaconda3/envs/env_name/bin/python

3) 파이썬 설치 도구별 설치 경로 (Apple Silicon)

1️⃣ Homebrew: /opt/homebrew/bin/python3.x 2️⃣ pyenv: ~/.pyenv/versions/3.x.x/bin/python 3️⃣ Anaconda: 기본 환경: /Users/username/anaconda3/bin/python 가상 환경: /Users/username/anaconda3/envs/env_name/bin/python

2. 파이썬 설치 방법들

1) Homebrew를 사용하여 설치 (macOS)

Homebrew는 macOS에서 패키지를 쉽게 설치하고 관리할 수 있는 패키지 관리 시스템이다. 터미널에서 아래의 명령어를 실행하여 파이썬을 설치 할 수 있다.

brew install python@3.11
python3.11 --version

# python3 명령어가 Python 3.11을 가리키도록 강제로 설정
brew link --overwrite python@3.11

2) pyenv를 사용하여 설치

pyenv는 여러 버전의 Python을 동시에 설치하고, 각 프로젝트마다 다른 버전을 사용할 수 있게 해주는 도구이다.macOS에서 Homebrew를 사용해 pyenv를 설치한다. 설치 후 셸 초기화 파일 설정이 필요하다는 것이 특징이다.

brew install pyenv

# 셸 초기화 파일(~/.zshrc, ~/.bashrc, 등)에 다음을 추가합니다:
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.zshrc
echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.zshrc
echo 'eval "$(pyenv init --path)"' >> ~/.zshrc
source ~/.zshrc

# Python 3.11 설치
pyenv install 3.11.0

# 특정 프로젝트에서 Python 3.11 사용 설정
pyenv local 3.11.0

3) Anaconda를 사용하여 설치

Anaconda는 데이터 과학과 머신러닝에 자주 사용되는 Python 배포판으로, 가상 환경 관리와 함께 다양한 패키지를 쉽게 설치할 수 있다.

# Python 3.11을 사용하는 가상 환경(py311) 생성
conda create -n py311 python=3.11

# 설치된 Conda 가상환경 목록 출력
conda env list

# 생성한 가상 환경 활성화
conda activate py311

Anaconda로 설치된 파이썬 및 가상 환경은 Anaconda가 설치된 디렉토리 안에 위치한다. macOS 기준 /Users/username/anaconda3/ 에 설치된다.

3. 마무리

어떤 설치 방법을 이용하든 결국 파이썬 인터프리터 자체는 동일하다. 다만 설치 방법별로 가상 환경 관리 및 패키지 간의 의존성 충돌 해소를 수동으로 해야하는지, 자동으로 관리되는지가 달라진다.

• 시스템 기본 파이썬 또는 Homebrew를 사용해 설치한 파이썬을 사용할 경우 venv나 virtualenv를 사용해 가상 환경을 수동으로 생성하고 관리해야 한다. 또한 패키지 간의 의존성 문제를 수동으로 해결해야 한다.

• pyenv를 사용해 파이썬을 설치한 경우 pyenv-virtualenv 플러그인을 통해 가상 환경을 생성하고 관리할 수 있다. 마찬가지로 패키지 간의 의존성 문제를 수동으로 해결해야 한다.

• Anaconda의 경우 conda 명령어를 통해 가상 환경을 생성하고 의존성도 자동으로 관리해 의존성 충돌 문제를 최소화해준다. 단 conda와 pip 혼용시 의존성 문제 발생 가능성이 높아 주의해야 한다.

각 방법의 장단점을 이해하고, 프로젝트에 맞는 적절한 방법을 선택하여 파이썬 개발 환경을 효율적으로 관리해보자. 파이썬 버전 및 패키지 관리만 잘해도 불필요한 오류로 낭비되는 시간을 크게 줄일 수 있다.

슬라이싱

• 슬라이싱은 파이썬의 1.0 버전부터 존재한 기능으로, 기존의 다른 언어보다 직관적이고 일관적인 방식으로 구현되었다.

  numbers = [1, 2, 3, 4, 5]
  print(numbers[1:4])   # 2번째부터 4번째까지 출력: [2, 3, 4]
  print(numbers[::-1])  # 역순으로 출력: [5, 4, 3, 2, 1]

• 슬라이싱을 하면 새로운 리스트 객체가 생성되지만 얕은 복사를 한다는 것을 유의해야 한다. 리스트의 내부 객체가 만약 변경 가능한 객체(Mutable Object)라면 해당 객체를 수정했을 때 원본 리스트에도 영향을 준다.

  >>> original_list = [[1, 2], [3, 4]]
  >>> sliced_list = original_list[1]
  >>> sliced_list[0] = 'NEW VALUE'
  >>> print("Original list:", original_list)
  Original list: [[1, 2], ['NEW VALUE', 4]]

리스트 컴프리헨션

• 리스트 컴프리헨션은 파이썬 2.0 버전부터 도입된 기능으로 PEP 202 문서를 통해 관련 내용을 확인할 수 있다.

  numbers = [1, 2, 3, 4, 5, 6]
  even_numbers = [num for num in numbers if num % 2 == 0]
  print(even_numbers)  # 출력: [2, 4, 6]

제너레이터

• 제너레이터는 파이썬 2.2 버전에서 도입된 기능으로, PEP 255에 정의되어 있다. 제너레이터는 메모리 효율성을 극대화하면서 반복 작업을 수행할 수 있도록 도와준다.

  def infinite_sequence():
    num = 0
    while True:
        yield num
        num += 1
  

제너레이터는 필요할 때만 값을 생성하므로 메모리 효율적이다

gen = infinite_sequence() print(next(gen)) # 출력: 0

### zip() 함수
- zip() 함수는 파이썬의 내장 함수로, 여러 시퀀스를 병렬로 묶어주는 기능을 제공한다. 동일한 길이의 시퀀스를 함께 묶어, 각 시퀀스에서 같은 인덱스에 위치한 요소들을 튜플로 반환한다.

names = ["Alice", "Bob", "Charlie"] scores = [85, 92, 78] grades = ["A", "B", "C"] for name, score, grade in zip(names, scores, grades): print(f"{name}: {score}, Grade: {grade}")

""" 출력: Alice: 85, Grade: A Bob: 92, Grade: B Charlie: 78, Grade: C """ ```

PEP 8 스타일 가이드를 따르자

파이썬을 파이썬스럽게 사용하려면 PEP 8을 알아야 한다. 파이썬 개선 제안서 (Python Enhancement Proposal) #8, 다른 말로 PEP 8은 파이썬 코드를 어떻게 구성할지 알려주는 스타일 가이드다. 화이트스페이스, 네이밍, 표현식과 문장에 관한 규칙의 주요 내용은 다음과 같다.

화이트스페이스(whitespace)

1️⃣ 탭이 아닌 스페이스로 들여쓴다. 2️⃣ 문법적으로 의미 있는 들여쓰기는 각 수준마다 스페이스 네 개를 사용한다. 3️⃣ 표현식이 길어서 다음 줄로 이어지면 일반적인 들여쓰기 수준에 추가로 스페이스 네 개를 사용한다. 4️⃣ 파일에서 함수와 클래스는 빈 줄 두 개로 구분해야 한다. 5️⃣ 클래스에서 메서드는 빈 줄 하나로 구분해야 한다. 6️⃣ 리스트 인덱스, 함수 호출, 키워드 인수 할당에는 스페이스를 사용하지 않는다. 7️⃣ 변수 할당 앞뒤에 스페이스를 하나만 사용한다.

위 규칙을 적용한 샘플 코드는 다음과 같다.

class Calculator:
    def __init__(self, value=0):  # 1️⃣ 들여쓰기는 스페이스 4개, 6️⃣ 키워드 인수 할당에는 스페이스X
        self.value = value  # 7️⃣ 변수 할당 앞뒤에 스페이스 하나 사용

    def add(self, x):  # 5️⃣ 클래스에서 메서드는 빈 줄 하나로 구분
        self.value += x
        return self.value


def calculate_expression(a, b, operation):  # 4️⃣ 파일에서 함수와 클래스는 빈 줄 두 개로 구분
    if operation == 'add': 
        return a + b
    elif operation == 'complex_operation':
        return (a + b +  # 3️⃣ 표현식이 길어지면 다음 줄로 넘어가고 추가 들여쓰기
                a * b -
                b / a)
    else:
        return 'Error: Unsupported operation'  # 7️⃣ 연산자 앞뒤에 스페이스 하나 사용


if __name__ == '__main__':  # 2️⃣ 조건문, 반복문, 함수 호출 등에서 스페이스를 적절히 사용
    calc = Calculator()  # 6️⃣ 함수 호출 시 인수와 함수명 사이에 스페이스 사용하지 않음
    result = calc.add(10)  # 6️⃣ 함수 호출 시 인수와 함수명 사이에 스페이스 사용하지 않음
    expression_result = calculate_expression(10, 5, 'complex_operation')  # 6️⃣ 함수 호출 시 인수와 함수명 사이에 스페이스 사용하지 않음

    print(f"Calculator 결과: {result}")
    print(f"수식 계산 결과: {expression_result}")

네이밍(naming)

1️⃣ 모듈은 짧고 모두 소문자 이름을 가져야 한다. 가독성을 개선하는 경우 모듈 이름에 밑줄을 사용할 수 있다. 2️⃣ 모듈 수준 상수는 ALL_CAPS 형식을 따른다. 3️⃣ 클래스와 예외는 CapitalizedWord 형식을 따른다. 예외는 접미사 Error로 끝나야 한다. 4️⃣ 클래스의 Public 메서드, 함수, 변수, 속성은 lowercase_underscore 형식을 따른다. 5️⃣ 클래스의 Non-public 메서드와 인스턴스 변수에는 _leading_underscore 형식을 따른다. 6️⃣ 클래스의 인스턴스 메서드에서 첫 번째 파라미터의 이름은 self로 지정한다. 7️⃣ 클래스 메서드에서는 첫 번째 파라미터의 이름을 cls로 지정한다. 8️⃣ 서브 클래스에서의 변수명 충돌을 막으려면 __double_leading_score 형식을 따르는 인스턴스 변수명을 사용한다.

# 1️⃣ 파일명은 simple_module.py이라 가정한다.
ALL_CAPS_CONSTANT = 100  # 2️⃣ 모듈 수준 상수


class SampleClass:  # 3️⃣ 클래스 이름은 CamelCase
    def __init__(self, value):  # 6️⃣ 인스턴스 메서드, 첫 번째 파라미터는 self
        self.public_var = value  # 4️⃣ Public 변수
        self._private_var = value  # 5️⃣ Non-public 변수
        self.__mangled_var = value  # 8️⃣ 이름 충돌 방지 변수

    def _private_method(self):  # 5️⃣ Non-public 메서드
        if self._private_var < 0:  # 음수 값에 대한 예외 처리
            raise CustomError("Value cannot be negative!")
        return self._private_var * ALL_CAPS_CONSTANT

    def public_method(self):  # 4️⃣ Public 메서드
        return self._private_method()

    @classmethod
    def class_method(cls, value):  # 7️⃣ 클래스 메서드, 첫 번째 파라미터는 cls
        return cls(value * ALL_CAPS_CONSTANT)


class CustomError(Exception):  # 3️⃣ 예외 클래스
    pass


if __name__ == '__main__':
    instance = SampleClass(10)
    try:
        print(instance.public_method())
        print(SampleClass.class_method(5))  # 클래스 메서드 호출
    except CustomError as e:
        print(e)

표현식과 문장

자동 포맷팅 도구 black과 VSCode 설정 방법

파이썬 코드를 작성할 때 자동으로 PEP 8 스타일을 준수하도록 코드 포맷터를 설정할 수 있다. 대표적인 코드 포맷터는 black이다.

1️⃣ 개요

파이썬다운 스타일은 단순함과 가독성을 극대화하기 위해 권장 패턴을 따르고, 안티 패턴을 피하며, 파이썬 고유 특성에 맞게 코딩하는 것을 의미한다.

1장은 총 13개의 절로 구성되어 있다.

• ✅는 권장 패턴 (7개)
• ❌는 안티 패턴 (3개)
• 🩶는 파이썬 고유 특성 (3개)

각 절의 내용을 3가지 범주로 나눈다면 위와 같이 구분할 수 있다. 그리고 각 절의 주관적인 중요도는 ⭐️로 표기하였다. PEP 8 스타일 가이드는 코드 품질 관리의 핵심이며, 사용 중인 파이썬 버전을 아는 것은 의존성 관리에 필수적이기에 ⭐️⭐️로 중요도를 매겼다. 스타일 가이드 준수를 위해서는 black과 flake8과 같은 정적 검사 도구를 이용하는 것이 좋으며, 의존성 관리는 poetry 같은 도구를 잘 사용하는 것이 필요하다.

개발에 도움되지만 사용 빈도가 낮거나, 필수적이지 않은 챕터는 ⭐️표기를 생략했다. 특히 안티 패턴과 관련된 내용은 중요하지만 습관을 잘 들이면 의식할 필요가 없어 중요도를 표기하지 않았다. 안티 패턴을 피하기 위해서는 파이썬스러운 생각을 체화하는 게 중요하기 때문이다.

2️⃣ 목차

✅ [chapter 2] PEP 8 스타일 가이드를 따르자 ⭐️⭐️ ✅ [chapter 4] 복잡한 표현식을 사용하는 대신 헬퍼 함수를 사용하자 ⭐️ ✅ [chapter 7] map과 filter 대신 리스트 컴프리헨션을 사용하자 ⭐️ ✅ [chapter 9] 컴프리헨션이 클 때는 제너레이터 표현식을 고려하자 ⭐️ ✅ [chapter 10] range보다는 enumerate를 사용하자 ⭐️ ✅ [chapter 11] 이터레이터를 병렬로 처리하려면 zip을 사용하자 ✅ [chapter 13] try/except/else/finally에서 각 블록의 장점을 이용하자

❌ [chapter 6] 한 슬라이스에 start, end, stride를 함께 쓰지 말자 ❌ [chapter 8] 리스트 컴프리헨션에서 표현식을 두 개 넘게 쓰지 말자 ❌ [chapter 12] for와 while 루프 뒤에는 else 블록을 쓰지 말자

🩶 [chapter 1] 사용 중인 파이썬의 버전을 알자 ⭐️⭐️ 🩶 [chapter 3] bytes, str, unicode 차이점을 알자 ⭐️ 🩶 [chapter 5] 시퀀스를 슬라이스하는 방법을 알자 ⭐️

3️⃣ 리뷰

파이썬의 시퀀스 데이터 타입 및 반복문과 관련된 내용이 가장 많은 분량을 차지하고 있다(13장 중 9장). 파이썬이 다른 언어에 비해 데이터 핸들링에 유용한 이유는 시퀀스 데이터 타입을 효율적으로 지원하는 데이터 모델과 문법 덕분이다. 파이썬의 슬라이싱, 리스트 컴프리헨션, 제너레이터, zip() 함수가 대표적인 예이다.

복잡한 작업을 단순하고 효율적으로 표현해주는 기능들 덕분에 파이썬 개발자들은 읽기 쉽고 유지보수하기 쉬운 코드를 작성할 수 있게 되었다. 슬라이싱을 통해서 특정 요소를 보다 쉽게 추출할 수 있고, 리스트 컴프리헨션을 사용해 필터링과 변환 작업을 한 줄로 처리할 수 있으며, 제너레이터로 대용량 데이터를 메모리 효율적으로 다룰 수 있으며, zip() 함수로 여러 시퀀스를 동시에 순회할 수 있게 되었다.

이러한 기능들은 The Zen Of Python에 명시된 설계 원칙을 반영한다. 시퀀스 데이터 타입 뿐만 아니라 파이썬의 다양한 문법적인 요소들이 해당 설계 원칙을 반영해 작성되었다. 파이썬 문법에 어느 정도 익숙해진 개발자라면, 언어 설계자들이 추구한 가치가 무엇인지에 대해서 한 번쯤 고민해보는 시간을 가져도 좋을 것이다. 언어는 가치의 구현체이기 때문이다.

>>> import this  # The Zen of Python, by Tim Peters

4️⃣ 추가 조사

파이썬 프로젝트들에서 특정 Python idiom(언어적 관용 패턴)이 얼마나 자주 사용되는지를 비교한 표를 보면 List comprehension, Decorator, with 등이 널리 쓰이는 걸 확인할 수 있다.

There Is More Than One Way to Zen Your Python

<파이썬 코딩의 기술>은 파이썬 기본 문법을 배우고 다음 수준의 자료를 찾는 사람에게 추천하는 책이다. 이 책을 읽으면 파이썬 중급 개발자로 성장하는 데 필요한 노하우를 익힐 수 있다. 파이썬을 파이썬스럽게(pythonic) 작성하기 위한 가이드, 객체 지향 프로그래밍, 병행성과 병렬성, 디버깅 및 테스트 방법 등 중요한 주제를 균형 있게 다루고 있기 때문이다. 이 책을 통해 파이썬의 관용 표현, 디자인 패턴, 성능 개선, 트러블 슈팅 방법들을 알아보자.

책의 목차

책의 목차는 다음과 같다. 모든 챕터가 유용하지만 상대적으로 중요도가 높다고 생각한 챕터는 ⭐️ 표기를 하였다.

• ⭐️⭐️ 표기가 된 챕터를 이해하지 못하면 파이썬스러운 코딩에 어려움을 겪을 수 있다.
• ⭐️ 표기가 된 챕터를 이해하지 못하면 프로젝트 진행이 어렵다.
• 특별한 표기가 없는 챕터도 훌륭하지만 필요할 때 찾아봐도 늦지 않다.

책의 목차 (1장) 파이썬다운 생각 ⭐️⭐️ (2장) 함수 ⭐️ (3장) 클래스와 상속 ⭐️⭐️ (4장) 메타클래스와 속성 (5장) 병행성과 병렬성 (6장) 내장 모듈 (7장) 협력 ⭐️ (8장) 제품화 ⭐️

연재 계획

앞으로는 이 책의 각 장을 살펴보며 왜 이 장이 중요한지, 그리고 어떤 내용을 다루는지에 대해 정리할 예정이다. 1장 파이썬다운 생각에서는 파이썬 철학과 이를 활용한 효과적인 코딩 방법을 소개한다. 이 장을 이해하는 것은 파이썬스러운 코드를 작성하는 데 필수적이다.

velog에서의 목표는 하나다. 읽은 책 잘 정리해놓고 복습할 수 있게 만들기. 노션에 정리해둔 책들과 읽고 정리를 해놓지 않은 양서들을 시리즈화하여 체계적으로 정리하는 것이 목표다. 파이썬, 디자인 패턴, 데이터베이스, 시스템 설계 등 굵직한 주제들의 책을 아카이빙 하는 용도로 사용하려고 한다.

올해 연말까지의 목표는 매주 1권, 10권 가량의 책을 정리하는 것이다.