[PYTHON] 부작용(Side Effect)을 제어하는 3가지 핵심 테스트 전략과 해결 방법

Side Effect

 

소프트웨어 개발에서 부작용(Side Effect)이란 함수가 자신의 로컬 범위 밖의 상태를 수정하거나 외부 세계(파일 시스템, 데이터베이스, 네트워크 등)와 상호작용하는 것을 의미합니다. 파이썬과 같은 동적 언어에서 이러한 부작용은 테스트를 어렵게 만드는 주범입니다. 예측 불가능한 외부 요인에 의존하는 코드는 테스트 실행 시마다 결과가 달라질 수 있기 때문입니다. 본 가이드에서는 전문 소프트웨어 엔지니어의 관점에서 파이썬 환경의 부작용을 완벽하게 격리하고, 신뢰할 수 있는 단위 테스트를 구축하는 구체적인 전략 3가지를 심도 있게 다룹니다.

---

1. 부작용의 정의와 테스트가 어려운 이유

순수 함수(Pure Function)는 동일한 입력에 대해 항상 동일한 출력을 반환하며 부작용이 없습니다. 반면, 부작용이 있는 함수는 다음과 같은 특징을 가집니다.

• 전역 변수나 정적 변수의 수정
• 콘솔 출력 또는 로그 기록
• 파일 읽기/쓰기
• API 호출 및 네트워크 통신
• 현재 시간(datetime.now) 또는 난수 생성

이러한 요소들은 테스트 환경을 오염시키고, 네트워크 단절이나 파일 권한 문제로 인해 로직 자체는 완벽함에도 불구하고 테스트가 실패하는 '거짓 음성(False Negative)'을 발생시킵니다.

---

2. 부작용 제어를 위한 핵심 전략 비교

부작용을 처리하는 방법은 크게 의존성 주입, 모킹, 그리고 함수형 프로그래밍 접근법으로 나뉩니다. 각 전략의 차이점을 표로 정리하였습니다.

구분	의존성 주입 (DI)	모킹 (Mocking)	함수형 분리 (Functional)
핵심 개념	외부 객체를 인자로 전달	실제 객체를 가짜 객체로 대체	로직과 부작용 코드를 완전히 분리
구현 난이도	중간 (설계 변경 필요)	낮음 (기존 코드 유지)	높음 (패러다임 전환)
테스트 속도	매우 빠름	빠름	가장 빠름
추천 상황	객체 지향 설계 시	외부 라이브러리 사용 시	복잡한 알고리즘 테스트 시

---

3. 전략별 해결 방법 및 Sample Example

방법 01: `unittest.mock`을 활용한 객체 대체

파이썬 표준 라이브러리인 `unittest.mock`은 가장 대중적인 해결 방법입니다. `patch` 데코레이터를 사용하여 특정 모듈의 함수 호출을 가로채고 미리 정의된 값을 반환하도록 설정합니다.

Scenario: 외부 API에서 날씨 정보를 가져와 의사결정을 내리는 함수 테스트

import unittest
from unittest.mock import patch
import requests

# 부작용이 있는 실제 함수
def get_weather_decision(city):
    response = requests.get(f"https://api.weather.com/{city}")
    data = response.json()
    if data['status'] == 'Rain':
        return "우산을 챙기세요"
    return "맑음"

# 테스트 코드
class TestWeather(unittest.TestCase):
    @patch('requests.get')
    def test_rainy_day(self, mock_get):
        # API 응답을 모킹 (부작용 제거)
        mock_get.return_value.json.return_value = {'status': 'Rain'}
        
        result = get_weather_decision('Seoul')
        self.assertEqual(result, "우산을 챙기세요")
        mock_get.assert_called_once()

방법 02: 의존성 주입(Dependency Injection)을 통한 결합도 낮추기

함수 내부에서 객체를 직접 생성하지 않고, 인자로 전달받는 방식입니다. 이를 통해 테스트 시 실제 데이터베이스 연결 대신 메모리 내 객체를 주입할 수 있습니다.

# 개선된 설계: 데이터베이스 엔진을 주입받음
def save_user_data(user_info, db_engine):
    # db_engine은 .execute() 메서드를 가진 객체라고 가정
    db_engine.execute("INSERT INTO users VALUES (?)", user_info)
    return True

# 테스트 시 가짜 DB 사용
class FakeDB:
    def execute(self, query, params):
        print(f"Query executed: {query}")

def test_save_user():
    fake = FakeDB()
    assert save_user_data({"name": "Chaewon"}, fake) is True

방법 03: "비즈니스 로직"과 "부작용"의 물리적 분리

가장 고차원적인 해결 방법은 함수를 두 개로 쪼개는 것입니다. 데이터를 계산하는 '순수 함수'와 계산된 결과를 외부에 저장하는 '명령 함수'로 나눕니다. 이 경우 핵심 로직은 모킹 없이도 100% 신뢰도로 테스트할 수 있습니다.

---

4. 부작용 테스트 시 주의할 점 (Best Practices)

• 모킹 남용 금지: 너무 많은 것을 모킹하면 테스트가 실제 구현 코드의 세부 사항과 강하게 결합되어 리팩토링이 어려워집니다.
• 현실적인 데이터 사용: 모의 객체(Mock)가 반환하는 데이터는 실제 API나 DB의 스키마와 최대한 일치해야 합니다.
• Idempotency(멱등성) 확보: 테스트가 여러 번 실행되어도 로컬 파일 시스템이나 환경 변수에 흔적을 남기지 않아야 합니다.

---

5. 결론 및 요약

파이썬에서 부작용이 있는 함수를 테스트하는 것은 단순히 기술적인 문제를 넘어 코드의 설계 품질을 증명하는 과정입니다. `unittest.mock`을 통해 당장의 문제를 해결할 수 있지만, 장기적으로는 의존성 주입과 관심사 분리를 통해 부작용이 발생하는 지점을 최소화하는 설계가 권장됩니다. 위에서 제시한 3가지 전략을 적재적소에 활용한다면, 외부 환경에 구애받지 않는 견고한 CI/CD 파이프라인을 구축할 수 있을 것입니다.

---

참고 문헌 및 출처

• Python Software Foundation. "unittest.mock — mock object library". Official Documentation.
• Martin Fowler. "Mocks Aren't Stubs". martinfowler.com.
• Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin.