code-gen이 deprecated Pandas API를 제안할 때 — 파이프라인을 깨뜨린 미묘한 변동
Source: Dev.to
How the failure surfaced
보이는 오류는 하위 스키마 불일치와 검증 체크 실패였으며, 생성된 코드에서 직접적인 예외가 발생한 것은 아니었습니다. 폐기(deprecation)는 dtype 강제 변환과 NaN 처리에서 미묘한 변화로 나타났으며, 이는 큰 데이터셋이 엣지 케이스를 실행할 때만 드러났습니다. 단위 테스트가 작은 고정 데이터를 사용했기 때문에 해당 동작을 트리거하지 못했고, CI 파이프라인은 안전해 보이는 착각을 만들었습니다.
프로덕션 컨테이너 이미지를 사용해 스테이징 환경에서 문제를 재현했을 때, 폐기 경고가 호환성 문제로 바뀌었습니다. 계측을 통해 파일 쓰기 전후에 스키마 어설트를 추가하고 경고가 발생하면 예외를 발생시키도록 하면 드리프트를 더 일찍 잡을 수 있었습니다. 우리는 프로덕션에서 고정된 Pandas 버전으로 롤백하고, 변환 로직을 현재의 명시적인 API를 사용하도록 다시 작성했습니다.
Why it was easy to miss
이 문제가 놓친 데에는 몇 가지 상호 작용하는 이유가 있습니다.
- Legacy code in training data – 코드 생성 모델은 널리 사용되는 코퍼스 예시를 그대로 반영하는 경우가 많으며, 여기에는 레거시 코드도 포함됩니다. 이러한 예시는 간결하고 자신감 있게 보이기 때문에, 생성된 스니펫이 최신이 아니더라도 권위 있게 보입니다.
- Incomplete safety nets – 작은 단위 테스트, 로컬 개발 환경, 그리고 CI 매트릭스가 충분히 커버되지 않았습니다. 우리는 하나의 테스트 매트릭스 타깃만 가지고 있었고, 이는 개발 머신과 일치했습니다.
- Semantic regression – 실패 모드가 구문(syntax)보다 의미(semantic)와 관련되었습니다. 코드는 정상적으로 실행되어 값을 반환했지만, 코너 케이스에서 미묘하게 다른 값을 반환했습니다. 이러한 회귀는 단순한 어설션 기반 테스트로는 잡히기 어렵고, 프로퍼티 기반 체크, 스키마 검증, 혹은 버전 인식 린터가 필요합니다.
우리 경우, 어시스턴트가 버전 인식을 하지 못한 것이 위험을 가중시켰습니다: Pandas 호환성을 확인하는 import‑time 체크나 주석이 포함되지 않았기 때문입니다.
Practical mitigations we adopted
사고 이후 우리는 개발자 워크플로우를 생성된 코드를 초안으로 다루도록 조정했습니다.
- Pre‑commit hooks –
python -m pip check와 폐기된 API에 대한 정적 검사를 실행합니다. - Expanded CI matrix – 프로덕션 Pandas 버전을 포함하도록 매트릭스를 확장했습니다.
- Multi‑turn chat interface – chat interface를 사용해 어시스턴트에게 특정 API가 최신 릴리스에서 왜 안전하지 않을 수 있는지 물어봅니다; 이를 통해 제안의 역사적 배경을 파악하고 더 안전한 재작성 방법을 안내받을 수 있습니다.
- Schema validators – 직렬화 경계에 검증기를 추가합니다.
또한 풀 리퀘스트에 작은 체크리스트를 도입했습니다:
- 런타임 pandas 버전을 확인합니다.
- 폐기된 헬퍼보다 명시적인 변환을 선호합니다.
- dtype에 민감한 경로를 실행하는 어설션을 추가합니다.
보다 깊은 검증을 위해 우리는 간단한 툴체인을 사용해 라이브러리 변경 로그와 교차 참조하고, 어시스턴트의 출처 힌트가 모호할 때는 deep research 쿼리를 통해 수동 검토를 진행합니다.
이러한 변화가 생성된 코드를 완벽하게 만들지는 못했지만, 폐기된 API로 인한 은밀한 실패 모드를 크게 감소시켰으며, 맹목적인 신뢰를 반복 가능한 리뷰 프로세스로 전환했습니다. 데이터 파이프라인에 코드 생성을 활용한다면, 버전 체크와 스키마 검증을 초기 워크플로우에 포함시키세요 — 그 비용은 프로덕션에서 조용히 발생하는 드리프트를 추적하는 것보다 훨씬 작습니다.