서론

ChatGPT나 Claude에게 "이 CSV를 집계해줘"라고 부탁하면, 그럴싸한 pandas 코드가 순식간에 돌아옵니다. 동작도 하고, 보기에도 깔끔하죠. 하지만 실무 데이터에 적용하는 순간, "유난히 느리다・메모리가 팽창한다・결과가 왠지 맞지 않는다" 라는 조용한 지뢰를 밟아본 경험이 있지 않으신가요?

본 기사는 AI에게 데이터 처리를 맡기는 기회가 늘어난 데이터 엔지니어(Data Engineer)・데이터 사이언티스트(Data Scientist)・분석 업무를 수행하는 개발자를 대상으로, **"AI 생성 pandas 코드를 그대로 받아들이지 않기 위한 검증 워크플로우"**를 소개하는 내용입니다.

결론부터 말씀드리면, AI 생성 pandas 코드는 (1) 행 루프(Row Loop) 계열의 느린 속도, (2) dtype의 암묵적 변환, (3) join 시의 중복 폭발 이 세 가지를 최우선으로 의심해야 하며, Assert + 프로파일러(Profiler) 를 템플릿화하여 방지하는 것이 현실적입니다.

이 기사에서 알 수 있는 것

• AI 생성 pandas 코드에 섞이기 쉬운 3대 지뢰와 그 발생 메커니즘
• apply 루프를 numpy.select로 벡터화(Vectorization)하는 재작성 패턴
• merge의 중복 폭발을 발생 지점에서 멈추는 safe_merge 헬퍼 구현
• AI 생성 코드를 안전하게 머지(Merge)하기 위한 운용 규칙

AI 생성 코드에 섞이기 쉬운 3대 지뢰

AI가 작성하는 pandas 코드에서 자주 보이는 함정은 크게 세 종류로 분류할 수 있습니다. 먼저 각각의 정체를 파악해 두겠습니다.

1. iterrows / apply에 의한 행 루프

가장 전형적인 지뢰입니다. AI는 "하고 싶은 일"을 솔직하게 번역하기 때문에, 벡터화된 API가 존재하는 경우에도 iterrows를 던질 때가 있습니다. 10만 행을 넘어가면 체감상 수십 배의 차이가 발생합니다.

2. dtype의 암묵적 변환

read_csv 직후에 NaN이 하나라도 섞이면, 정수 ID가 float64가 되어 버립니다. AI는 이러한 암묵적 변환을 고려하지 않고 후속 단계에서 == 비교나 JSON 쓰기를 수행하므로, "ID가 소수가 되어 있다", "JOIN 키가 일치하지 않는다"와 같은 사고를 일으킵니다.

3. merge의 중복 폭발

how="left"로 왼쪽 테이블에 일치하는 행이 여러 개 있는 오른쪽 테이블을 결합하면, 왼쪽의 행이 복제되어 행수가 예상보다 몇 배로 불어납니다. AI는 "일단 merge했다"는 코드를 반환하므로, 결합 전후의 행수 어서트(Assert) 를 넣지 않으면 감지할 수 없습니다.

구현 예시: 벡터화로의 교체

여기서부터 구체적인 대책으로 들어갑니다. 우선 AI가 쓰기 쉬운 apply 루프를 numpy.select로 재작성하는 예시입니다. 조건 분기가 늘어나도 선형 시간(Linear Time) 내에 끝나므로 성능 차이가 단번에 좁혀집니다.

import numpy as np
import pandas as pd
df = pd.DataFrame({"score": np.random.randint(0, 101, size=1_000_000)})
...

100만 행에서 측정하면 apply는 수 초, np.select는 수십 밀리초(ms) 단위로 끝납니다. AI가 apply를 반환했다면, 우선 조건 분기를 벡터 연산으로 전개할 수 없는지를 가장 먼저 생각하는 것이 기본입니다.

구현 예시: 검증용 어서트를 템플릿화하기

행수・dtype・키 중복의 세 지점을 "결합 전후에 반드시 확인"하는 헬퍼를 준비해 두면, AI 생성 코드의 조용한 사고를 발생 지점에서 멈출 수 있습니다. 다음의 safe_merge는 그대로 공통 유틸리티에 둘 수 있는 구현 예시입니다.

import pandas as pd
def safe_merge(left: pd.DataFrame, right: pd.DataFrame, on: str,
how: str = "left", expect_unique_right: bool = True) -> pd.DataFrame:
...

포인트는 validate="m:1"을 전달하고 있는 부분입니다. pandas 자체에 중복 검지 기능이 있음에도 불구하고, AI가 작성한 코드는 거의 확실하게 이 인자를 생략해 버립니다. 라이브러리의 안전장치를 꺼지지 않게 하는 것만으로도 후속 집계가 망가질 확률은 크게 낮아집니다.

함정과 운용상의 주의사항

구현 패턴이 갖춰지더라도, 운영 측면에서 빠지기 쉬운 함정들이 몇 가지 있습니다. 다음 표에 정리하였으니 리뷰 시 체크리스트로 활용해 보시기 바랍니다.

특히 첫 번째 항목이 중요합니다. AI가 반환한 코드는 "샘플에서 작동했다"는 단계에서 완성된 것처럼 보이기 때문에, 실제 운영 환경에 준하는 데이터를 통과시키기 전까지는 안심하지 마십시오.

요약

AI가 생성한 pandas 코드는 "작동하는 것"과 "정확한 것" 사이의 거리가 먼 영역이었습니다. 본 기사의 핵심 포인트를 되짚어 보겠습니다.

• 행 루프 (Row Loop), 데이터 타입 (dtype), merge 중복의 3가지를 최우선으로 의심할 것
• apply는 np.select 등의 벡터화 API (Vectorized API)로 교체할 것
• safe_merge와 같이 어서트 (Assert)를 라이브러리 계층에 포함할 것
• 리뷰 시 %timeit / memory_profiler 사용을 필수화할 것
• 대규모 집계는 Polars / DuckDB로의 이관도 비교 검토할 것

다음 단계로는, (1) 팀 공통 유틸리티에 dtype/행 수에 대한 어서트를 배치하고, (2) AI 생성 PR에는 %timeit 결과를 첨부하는 것을 필수화하는, 이 두 가지를 즉시 도입해 보시는 것은 어떨까요? AI에게 코드를 작성하게 하는 시대이기에 더욱, "검증의 자동화"를 엔지니어 측면의 핵심 능력으로 보유하는 것이 조용한 지뢰를 밟지 않는 최단 경로입니다.