출처: Dev.to

모든 비트가 중요한 순간: 현대 개발에서 자원 효율성을 재발견하기

소개: 아폴로 정신

잠시 오늘날 우리가 손쉽게 배포하는 거대한 데이터 센터와 멀티 기가바이트 애플리케이션을 잊어보세요. 아폴로 유도 컴퓨터(AGC)를 떠올려 보세요. 인류를 달에 데려다 준 이 엔지니어링의 경이작은 RAM 2,048워드와 ROM 36,864워드만으로 동작했습니다. 비교하자면, 현대 운영 체제의 아이콘 캐시만으로도 그보다 더 많은 메모리를 차지할 수 있습니다. AGC의 모든 비트는 소중하고, 철저히 최적화된 자원이었습니다. 엔지니어들은 단순히 코드를 작성한 것이 아니라, 가혹하고 타협할 수 없는 제약 속에서 우아함을 조각해냈습니다.

오늘날 우리는 실리콘에 둘러싸여 무한에 가까운 연산 능력과 저장 공간을 누리고 있습니다. 이러한 풍요는 빠른 반복과 추상화의 시대를 만들었지만, 때때로 효율성을 희생시키기도 합니다. 우리는 편리함을 위해 설계를 비대하게 만들고, 과도한 메모리·CPU 사이클·네트워크 대역폭을 소비하는 디지털 거인을 만들어 냈습니다. 하지만 가끔 “바이트는 금이다”는 사고방식을 되돌아본다면 어떨까요? 모든 기능에 어셈블리 수준 최적화를 강요하려는 것이 아니라, 부풀어 오른 앱과 시스템에 규율 있는 엔지니어링을 주입하는 것입니다. 고대 기계들의 교훈은 단순히 역사가 아니라, 풍부한 시대에도 지속 가능하고 성능 좋으며 우아한 코드를 위한 청사진입니다.

우리가 어셈블리를 직접 작성하지는 않겠지만, “바이트는 금이다” 원칙을 데이터 구조와 객체 오버헤드에 대한 의식적인 선택으로 적용할 수 있습니다. 사용하기 쉬우면서도 낮은 수준 언어에 비해 메모리 사용량이 큰 파이썬을 예시로 살펴보겠습니다.

일반적인 상황: 간단한 데이터 레코드(예: 사용자 프로필) 표현

시나리오: 사용자 ID, 이름, 이메일, 상태를 저장해야 합니다.

일반 파이썬 클래스 – __dict__ 사용

파이썬 클래스는 인스턴스 속성을 동적으로 __dict__에 저장합니다. 유연성을 제공하지만 인스턴스당 메모리 오버헤드가 발생합니다.

import sys
from collections import namedtuple

# 접근법 1: 표준 파이썬 클래스 (암시적 __dict__ 사용)
class UserProfileVerbose:
    def __init__(self, user_id: int, name: str, email: str, status: str):
        self.user_id = user_id
        self.name = name
        self.email = email
        self.status = status

# 인스턴스 생성
user_verbose = UserProfileVerbose(101, "Alice Smith", "alice@example.com", "active")

# 메모리 사용량 측정
print(f"UserProfileVerbose size: {sys.getsizeof(user_verbose)} bytes")
# print(user_verbose.__dict__) # 내부 딕셔너리를 보려면 주석 해제

__slots__ 사용

__slots__를 정의하면 파이썬이 인스턴스 __dict__를 만들지 않으며, 속성을 위한 고정된 메모리 공간만 할당합니다. 특히 많은 인스턴스를 만들 때 메모리 사용량을 크게 줄일 수 있습니다. 단, __slots__가 적용된 클래스에서는 동적으로 새로운 속성을 추가할 수 없습니다.

# 접근법 2: __slots__ 사용 파이썬 클래스
class UserProfileLean:
    __slots__ = ['user_id', 'name', 'email', 'status']  # 슬롯 정의
    def __init__(self, user_id: int, name: str, email: str, status: str):
        self.user_id = user_id
        self.name = name
        self.email = email
        self.status = status

# 인스턴스 생성
user_lean = UserProfileLean(102, "Bob Johnson", "bob@example.com", "inactive")

# 메모리 사용량 측정
print(f"UserProfileLean size:    {sys.getsizeof(user_lean)} bytes")
# print(user_lean.__dict__) # AttributeError 발생

namedtuple (불변 및 매우 가벼움)

불변 데이터 레코드에는 namedtuple이 훌륭한 선택입니다. 필드 이름이 있는 튜플 서브클래스 팩터리를 생성하며, 튜플 자체가 메모리 효율적이고 불변성을 가집니다.

# 접근법 3: Named Tuple (불변 및 가벼움)
UserProfileNamedTuple = namedtuple('UserProfileNamedTuple', ['user_id', 'name', 'email', 'status'])

# 인스턴스 생성
user_nt = UserProfileNamedTuple(103, "Charlie Brown", "charlie@example.com", "pending")

# 메모리 사용량 측정
print(f"UserProfileNamedTuple size: {sys.getsizeof(user_nt)} bytes")

UserProfileVerbose size: 56 bytes
UserProfileLean size:    48 bytes
UserProfileNamedTuple size: 64 bytes

왜 UserProfileNamedTuple이 때때로 더 큰가?
sys.getsizeof()는 객체 자체의 크기만 측정하고, 문자열이나 리스트처럼 별도 파이썬 객체인 내용물의 메모리는 포함하지 않습니다. namedtuple은 필드 이름을 저장하기 위해 약간의 오버헤드가 추가됩니다. 그러나 많은 인스턴스와 그 속성을 전체적으로 고려하면 __slots__와 namedtuple이 __dict__ 오버헤드를 피하기 때문에 훨씬 메모리를 절약합니다. 특히 작은 객체를 대량으로 저장할 경우 namedtuple이 크게 유리합니다. 가변 객체가 필요하고 동적 속성이 필요하다면 __slots__가 더 적합합니다.

핵심은 이러한 방법들이 객체당 오버헤드를 줄이는 수단이라는 점입니다. 수천·수백만 개의 객체를 만들 때, 작은 차이가 크게 누적됩니다.

아폴로 엔지니어들의 교훈은 현대의 편리함을 모두 포기하고 어셈블리로 코딩하라는 것이 아니라, 자원에 대한 의도적이고 존중하는 사고방식을 기르는 것입니다. 구체적으로는:

• 올바른 데이터 구조 선택: 리스트나 namedtuple이 충분히 효율적이라면 딕셔너리를 남용하지 않기
• 객체 오버헤드 고려: 동적 속성이 꼭 필요하지 않다면 __slots__나 frozen dataclass로 메모리를 절감하기
• 추상화에 대한 인식: 사용 중인 프레임워크·라이브러리가 내부에서 어떤 작업을 수행하고, 그것이 성능·자원 사용에 어떤 영향을 미치는지 이해하기
• 프로파일링 및 측정: 추측하지 말고 측정하라. sys.getsizeof() 같은 간단한 도구부터 보다 포괄적인 프로파일러까지 활용해 병목을 정확히 파악하기

이는 모든 라인을 미세하게 최적화하라는 것이 아니라, 특히 핵심 경로, 대용량 데이터 처리, 자원 제한 환경(모바일, IoT, 서버리스) 등에서 정보에 기반한 설계 결정을 내리라는 의미입니다. 가끔 “바이트는 금이다”라는 마인드를 되새김으로써, 우리는 더 지속 가능하고, 성능 좋으며, 궁극적으로 더 우아한 소프트웨어를 만들 수 있습니다. 이는 규율 있는 엔지니어링의 영원한 원칙을 현대 개발에 적용한 결과라 할 수 있습니다.