Python 주니어 성능 최적화 기술면접

파일 전체를 read()로 읽으면 모든 내용이 메모리에 적재되어 10GB의 메모리가 필요합니다. 제너레이터를 사용하면 한 줄씩 또는 청크 단위로 읽어 처리한 후 메모리에서 해제되므로 상수 수준의 메모리만 사용합니다. 예를 들어 파일 객체를 직접 순회하거나 yield를 사용한 함수를 작성하면 지연 평가(lazy evaluation)로 필요한 시점에만 데이터를 가져옵니다. 이를 통해 메모리 사용량을 수십~수백 배 줄일 수 있으며, 대용량 데이터 처리에 필수적인 패턴입니다.

리스트에서 값을 찾는 in 연산은 O(n) 시간 복잡도를 가지므로 전체 리스트를 순회해야 합니다. 반면 set이나 dict는 해시 테이블로 구현되어 있어 평균 O(1) 시간에 조회가 가능합니다. 수천 번 반복 시 리스트는 O(n*m), set은 O(m)의 차이가 발생합니다. 따라서 중복이 없고 순서가 중요하지 않은 경우 set으로 변환하여 사용하면 성능이 크게 향상됩니다. 실무에서는 화이트리스트 검증, 중복 제거 등에 활용됩니다.

N+1 문제는 주문 1000개를 가져오는 1번의 쿼리 후, 각 주문마다 사용자 정보를 가져오기 위해 추가로 1000번의 쿼리가 실행되는 현상입니다. Django ORM에서 외래키 접근 시 지연 로딩(lazy loading)이 기본이기 때문에 발생합니다. select_related()를 사용하면 SQL JOIN을 통해 연관된 객체를 한 번의 쿼리로 함께 가져옵니다. 예를 들어 Order.objects.select_related('user')를 사용하면 1001번의 쿼리가 1번으로 줄어들어 데이터베이스 부하와 응답 시간이 크게 개선됩니다.

순차 실행은 각 API 응답을 기다리는 동안 CPU가 유휴 상태가 되어 비효율적입니다. asyncio와 aiohttp를 사용하면 비동기 I/O로 여러 요청을 동시에 보내고 응답을 기다리는 동안 다른 작업을 처리할 수 있어 1초 내외로 단축됩니다. concurrent.futures의 ThreadPoolExecutor는 멀티스레딩으로 병렬 처리하며 기존 동기 라이브러리를 그대로 사용할 수 있습니다. I/O 바운드 작업에서는 두 방법 모두 효과적이지만, asyncio는 단일 스레드에서 이벤트 루프로 동작하여 메모리 효율이 더 좋고, ThreadPoolExecutor는 기존 코드 수정이 적다는 장점이 있습니다.

복잡한 계산 결과를 매번 수행하는 것은 비효율적이므로 뷰 레벨 또는 데이터 레벨 캐싱을 적용해야 합니다. Django의 cache.get()과 cache.set()을 사용하여 상품 ID를 키로 계산 결과를 Redis나 Memcached에 저장합니다. 첫 요청에서는 계산 후 캐시에 저장하고, 이후 요청에서는 캐시에서 바로 반환하여 응답 시간을 수십 배 단축할 수 있습니다. TTL(Time To Live)을 설정하여 일정 시간 후 자동 만료시키고, 상품 정보 수정 시 cache.delete()로 무효화하여 데이터 일관성을 유지합니다. @cache_page 데코레이터나 template fragment 캐싱도 상황에 따라 활용 가능합니다.

매 요청마다 데이터베이스 연결을 생성하고 해제하면 오버헤드가 크고 연결 수가 급증합니다. 커넥션 풀은 미리 일정 수의 연결을 생성하여 풀에 보관하고, 요청 시 풀에서 빌려주고 완료 후 반환하는 방식입니다. Django의 CONN_MAX_AGE 설정으로 연결을 재사용하거나, SQLAlchemy의 pool_size와 max_overflow로 풀 크기를 조정합니다. 이를 통해 연결 생성 비용을 줄이고, 동시 연결 수를 제한하여 데이터베이스 부하를 조절할 수 있습니다. 적절한 풀 크기는 애플리케이션 워커 수와 데이터베이스 최대 연결 수를 고려하여 설정합니다.

응답 크기를 줄이기 위해 첫째, 필요한 필드만 선택하여 반환합니다. Django ORM의 only()나 values()로 특정 컬럼만 조회하고, Serializer에서 fields 옵션으로 필드를 제한합니다. 둘째, 페이지네이션을 적용하여 한 번에 전송하는 데이터 양을 줄입니다. 셋째, HTTP 압축(gzip)을 활성화하여 JSON 응답을 압축 전송하면 70~80% 크기 감소 효과가 있습니다. 넷째, 불필요한 중첩 객체는 ID만 반환하거나 별도 엔드포인트로 분리합니다. 이러한 방법들을 조합하면 네트워크 전송 시간과 대역폭을 크게 절약할 수 있습니다.

Locust는 Python 기반 부하 테스트 도구로 코드로 시나리오를 작성하고 웹 UI로 실시간 모니터링이 가능합니다. 측정해야 할 주요 지표는 첫째, 응답 시간(평균, 중앙값, 95/99 백분위수)으로 사용자 체감 속도를 파악합니다. 둘째, 처리량(RPS, Requests Per Second)으로 초당 처리 가능한 요청 수를 확인합니다. 셋째, 에러율로 시스템 안정성을 점검합니다. 넷째, 동시 사용자 수를 점진적으로 증가시키며 성능 한계점을 찾습니다. 이를 통해 병목 지점을 파악하고 목표 성능(예: 95 백분위 응답 시간 200ms 이하)을 충족하는지 검증합니다.

LIKE '%keyword%'는 앞쪽 와일드카드 때문에 인덱스를 활용할 수 없어 전체 테이블 스캔이 발생합니다. 인덱스는 정렬된 구조이므로 앞부분이 확정되어야 활용 가능하지만, 앞쪽 %는 모든 값을 검사해야 합니다. 해결 방법으로는 PostgreSQL의 Full-Text Search나 Elasticsearch 같은 전문 검색 엔진을 사용합니다. Django에서는 SearchVector와 SearchQuery로 전문 검색을 구현하거나, 별도로 Elasticsearch를 연동합니다. 이를 통해 역인덱스(inverted index)를 활용하여 빠른 검색이 가능하고, 형태소 분석, 유사도 검색 등 고급 기능도 사용할 수 있습니다.

Python의 cProfile 모듈로 함수별 호출 횟수와 실행 시간을 측정할 수 있습니다. python -m cProfile -o output.prof script.py로 실행 후, snakeviz나 gprof2dot으로 시각화하여 병목 함수를 쉽게 파악합니다. Django Debug Toolbar는 개발 환경에서 SQL 쿼리 수와 실행 시간, 캐시 히트율 등을 실시간으로 보여줍니다. line_profiler는 함수 내부의 라인별 실행 시간을 측정하여 더 세밀한 분석이 가능합니다. 프로덕션에서는 APM 도구(New Relic, Datadog)를 사용하여 실시간 모니터링과 분석을 수행합니다. 이러한 도구들로 측정 후 가장 시간이 오래 걸리는 부분을 우선 최적화합니다.