Pandas 데이터 분석 미드레벨 - 테스트 및 코드품질
새 면접Q. Pandas DataFrame을 반환하는 데이터 전처리 함수의 단위 테스트를 작성할 때, 두 DataFrame이 동일한지 검증하는 방법과 주의사항을 설명해주세요.
pandas.testing 모듈과 일반 assert의 차이를 생각해보세요.
pandas.testing.assert_frame_equal() 함수를 사용하여 두 DataFrame을 비교해야 합니다. 일반 == 연산자나 assert를 사용하면 element-wise 비교로 인해 제대로 작동하지 않습니다. check_dtype=True로 데이터 타입까지 검증하고, check_exact=False와 rtol 파라미터로 부동소수점 오차를 허용할 수 있습니다. NaN 값 처리를 위해 check_names, check_like 등의 옵션을 상황에 맞게 설정해야 합니다. 또한 테스트 데이터는 pd.DataFrame()으로 명시적으로 생성하여 예상 결과를 명확히 정의하는 것이 좋습니다.
- • pandas.testing.assert_frame_equal() 사용
- • check_dtype, check_exact 등 옵션 활용
- • 부동소수점 오차 처리(rtol)
- • 명시적인 예상 결과 DataFrame 생성
데이터 파이프라인의 각 변환 단계가 정확히 동작하는지 검증할 때 필수적입니다.
대용량 DataFrame의 경우 전체 비교가 부담스러울 수 있는데, 어떻게 테스트 전략을 수정하시겠습니까?
Q. 외부 데이터베이스에서 데이터를 읽어와 Pandas로 처리하는 분석 파이프라인을 테스트할 때, 실제 DB 연결 없이 테스트하는 방법과 각 접근법의 장단점을 설명해주세요.
Mock, Fixture, 테스트 DB 등 여러 접근법을 비교해보세요.
첫째, unittest.mock이나 pytest-mock으로 DB 연결 함수를 모킹하여 미리 정의된 DataFrame을 반환하게 할 수 있습니다. 빠르지만 실제 SQL 쿼리 로직은 검증하지 못합니다. 둘째, SQLite 인메모리 DB나 Docker 기반 테스트 DB를 사용하여 실제 DB 환경과 유사하게 테스트할 수 있으나 속도가 느립니다. 셋째, pytest fixture로 CSV/Parquet 형태의 테스트 데이터를 준비하고 pd.read_csv()로 읽는 방식은 중간 수준의 현실성을 제공합니다. 실무에서는 단위 테스트는 모킹으로 빠르게, 통합 테스트는 테스트 DB로 완전성을 확보하는 계층적 접근이 효과적입니다.
- • Mock을 통한 DB 연결 함수 모킹
- • 테스트 DB(SQLite, Docker) 활용
- • Fixture 기반 파일 데이터 사용
- • 단위/통합 테스트 계층 분리
CI/CD 파이프라인에서 DB 의존성 없이 빠르게 테스트를 실행해야 할 때 필수적입니다.
pandas.read_sql() 함수를 모킹할 때 실제 SQL 쿼리의 정확성은 어떻게 보장할 수 있을까요?
Q. 동료가 작성한 Pandas 코드에서 iterrows()를 사용하여 행별로 반복 처리하는 것을 발견했습니다. 코드 리뷰 시 어떤 점을 지적하고 어떤 대안을 제시하시겠습니까?
Pandas의 벡터화 연산과 성능 차이를 고려해보세요.
iterrows()는 각 행을 Series로 변환하며 반복하므로 매우 느리고, 데이터 타입이 보존되지 않을 수 있습니다. 먼저 벡터화 연산(apply, map, 브로드캐스팅)으로 대체 가능한지 검토해야 합니다. 복잡한 로직이라면 apply()나 NumPy 벡터화 함수를 사용하고, 조건부 처리는 np.where()나 mask/where 메서드를 활용할 수 있습니다. 정말 행별 처리가 필요하다면 itertuples()가 iterrows()보다 훨씬 빠릅니다. 코드 리뷰에서는 성능 테스트 결과와 함께 구체적인 리팩토링 예시를 제시하는 것이 좋습니다.
- • iterrows()의 성능 문제와 타입 보존 이슈
- • 벡터화 연산으로 대체 우선 고려
- • apply(), np.where(), itertuples() 등 대안 제시
- • 구체적인 리팩토링 예시 제공
수백만 행의 데이터를 처리할 때 iterrows() 사용은 수십 배의 성능 저하를 일으킵니다.
벡터화가 불가능한 복잡한 비즈니스 로직의 경우, 성능을 개선할 수 있는 다른 방법은 무엇이 있을까요?
Q. 체이닝된 Pandas 연산이 10개 이상 이어진 코드를 리팩토링할 때 고려해야 할 사항과 개선 방법을 설명해주세요.
가독성, 디버깅, 재사용성 측면에서 생각해보세요.
긴 메서드 체이닝은 가독성이 떨어지고 디버깅이 어려우므로 의미 있는 단위로 분리해야 합니다. 중간 결과를 변수에 할당하거나, 각 변환 단계를 함수로 추출하여 명확한 이름을 부여합니다. pipe() 메서드를 활용하면 체이닝 스타일을 유지하면서도 재사용 가능한 함수로 분리할 수 있습니다. 각 단계에 주석이나 docstring을 추가하고, 복잡한 로직은 별도 함수로 테스트 가능하게 만듭니다. 또한 assign()을 사용하여 여러 컬럼 생성을 그룹화하면 구조가 명확해집니다.
- • 의미 단위로 체이닝 분리
- • pipe() 메서드로 재사용 가능한 함수 추출
- • 중간 변수 할당으로 디버깅 용이성 확보
- • assign()으로 컬럼 생성 그룹화
복잡한 데이터 정제 파이프라인을 유지보수하고 팀원들이 이해할 수 있게 만들 때 필수적입니다.
pipe() 메서드를 사용할 때 각 변환 함수의 시그니처는 어떻게 설계해야 할까요?
Q. TDD 방식으로 시계열 데이터의 이동평균을 계산하는 Pandas 함수를 개발한다고 할 때, 테스트 케이스를 어떤 순서로 작성하고 어떤 엣지 케이스를 고려해야 하는지 설명해주세요.
가장 단순한 케이스부터 시작하여 점진적으로 복잡한 케이스로 확장하세요.
먼저 3개 행의 간단한 DataFrame으로 기본 동작을 테스트합니다(Red). 그 다음 window 크기가 데이터보다 큰 경우, 빈 DataFrame, NaN 값이 포함된 경우, 단일 행 DataFrame 등의 엣지 케이스를 각각 테스트로 작성합니다. 날짜 인덱스가 불연속적인 경우, 중복된 인덱스, 정렬되지 않은 데이터도 고려해야 합니다. 각 테스트마다 최소한의 코드로 통과시킨 후(Green) 리팩토링합니다. min_periods 파라미터 처리, 다양한 window 타입(rolling, expanding), 여러 컬럼 동시 처리 등을 점진적으로 추가합니다. 마지막으로 성능 테스트를 추가하여 대용량 데이터에서도 합리적인 시간 내에 동작하는지 검증합니다.
- • 단순 케이스부터 시작하여 점진적 확장
- • 빈 데이터, NaN, 불연속 인덱스 등 엣지 케이스 고려
- • Red-Green-Refactor 사이클 준수
- • 성능 테스트까지 포함
금융 데이터 분석에서 이동평균 계산은 핵심 기능이며, 버그 발생 시 큰 손실로 이어질 수 있습니다.
테스트 케이스가 너무 많아져서 실행 시간이 길어질 때 어떻게 관리하시겠습니까?
Q. Pandas 코드에서 SettingWithCopyWarning이 발생하는 상황과 이를 근본적으로 해결하는 방법, 그리고 코드 리뷰에서 이를 사전에 방지하는 가이드라인을 설명해주세요.
뷰(view)와 복사(copy)의 차이, 그리고 명시적인 의도 표현을 생각해보세요.
SettingWithCopyWarning은 DataFrame의 슬라이스가 뷰인지 복사본인지 불명확할 때 발생합니다. df[condition][column] = value 같은 체인 인덱싱은 중간 결과가 뷰일 수도 복사본일 수도 있어 위험합니다. 해결 방법은 loc/iloc을 사용한 단일 인덱싱(df.loc[condition, column] = value)이나, 명시적 복사(df.copy())입니다. 코드 리뷰 가이드라인으로는 체인 인덱싱 금지, 항상 loc/iloc 사용, 원본 수정 의도라면 inplace=True나 재할당 명시, 뷰가 필요하면 주석으로 의도 표시 등을 규칙화해야 합니다. 린터 설정에 pandas-vet 같은 도구를 추가하면 자동 검출이 가능합니다.
- • 체인 인덱싱의 뷰/복사 불명확성 문제
- • loc/iloc을 통한 단일 인덱싱 사용
- • 명시적 copy() 호출
- • 린터 도구로 자동 검출
데이터 전처리 파이프라인에서 예상치 못한 원본 데이터 변경은 심각한 버그를 일으킬 수 있습니다.
대용량 DataFrame에서 copy()를 자주 호출하면 메모리 문제가 발생할 수 있는데, 어떻게 균형을 맞추시겠습니까?
Q. 여러 데이터 소스(CSV, API, DB)에서 데이터를 읽어 병합하고 집계하는 Pandas 기반 ETL 파이프라인의 통합 테스트 전략을 설계할 때 고려사항과 구현 방법을 설명해주세요.
테스트 데이터 준비, 외부 의존성 관리, 검증 포인트를 생각해보세요.
먼저 pytest fixture로 각 데이터 소스의 테스트 데이터를 준비합니다. CSV는 tmpdir에 실제 파일을 생성하고, API는 responses나 vcrpy로 HTTP 응답을 모킹하며, DB는 Docker 컨테이너나 SQLite로 테스트 환경을 구성합니다. 전체 파이프라인을 실행한 후 최종 결과 DataFrame의 스키마(컬럼명, 타입), 행 개수, 주요 집계 값, 데이터 품질(null 비율, 중복 등)을 검증합니다. 중간 단계별 체크포인트를 두어 어느 단계에서 실패했는지 파악 가능하게 하고, 로깅을 추가하여 디버깅을 용이하게 합니다. 성능 기준(예: 10만 행 처리 시 5초 이내)도 설정하여 회귀를 방지합니다. CI/CD에서는 Docker Compose로 전체 환경을 재현 가능하게 만듭니다.
- • fixture로 다양한 데이터 소스 테스트 환경 구성
- • 최종 결과의 스키마, 집계 값, 데이터 품질 검증
- • 중간 체크포인트와 로깅으로 디버깅 용이성 확보
- • Docker Compose로 CI/CD 환경 재현
일일 배치로 실행되는 데이터 파이프라인의 안정성을 보장하고 배포 전 회귀를 방지할 때 필수적입니다.
통합 테스트가 실패했을 때 단위 테스트는 통과하는 상황이라면, 어떤 문제를 의심해야 할까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!