Pandas 창시자 Wes McKinney가 말하는 AI·Apache Arrow·소프트웨어 엔지니어링의 미래

Pandas와 Apache Arrow를 만든 경험을 바탕으로, AI 시대에도 고성능 데이터 시스템과 소프트웨어를 설계하는
전문성·판단력·취향이 핵심이라고 봄
Apache Arrow는 표 형식 데이터를 위한 범용
인메모리 기반 계층으로 시스템 간 전송과 처리를 표준화하며, 채택하는 시스템이 늘수록 상호운용성의 가치도 커짐
DuckDB·DataFusion 같은 정교한 시스템은 LLM의 평균적인 코드 생성만으로 대체하기 어려우며, 오픈소스의 경쟁력에는 코드뿐 아니라 장기간 축적한
신뢰와 품질 기록도 포함됨
AI 도구는 주도성 높은 개발자의 생산성을 크게 높이지만, 무엇을 만들지 명확하지 않으면 평균적인 해법과 코드가 쌓여 에이전트도 빠져나오기 어려운
에이전트 수렁(agentic tarpit) 이 생길 수 있음
앞으로는 언어 문법과 손코딩보다 아키텍처, 문제 정의, 의사소통, 결과 판별 능력이 중요해지며, 조직은 늘어난
의사결정 부담과 토큰 비용까지 관리해야 함

Pandas에서 AI 개발 도구로 이어진 경력

Wes McKinney는 약 18년 전
Python Pandas를 만들었고, 2010년 오픈소스 프로젝트로 공개함
저서
Python for Data Analysis

는 Python 데이터 과학 생태계에서 널리 사용됐으며, 이후 오픈소스 개발을 지속할 수 있는 회사와 사업 모델을 만드는 일에 참여함

Cloudera에서 여러 오픈소스 개발자와
Apache Arrow를 시작했고, Arrow 생태계와 Parquet 개발에도 관여함
Ursa Computing은 이후 Voltron Data가 됐으며, Voltron Data가 정리된 뒤에도 Posit과의 관계를 이어감
현재는 데이터 과학 라이브러리보다
AI 개발자 도구와 인프라에 집중하는 새 회사를 설립해, AI로 소프트웨어 엔지니어링 생산성을 높이는 방법을 탐색하고 있음

Apache Arrow가 확산되기까지

Arrow는 표 형식 데이터를 위한 범용
인메모리 데이터 기반 계층으로, 메모리 내 처리와 시스템 간 데이터 전송을 빠르게 하며 상호운용성을 높임
초기에는 사용자와 소비 시스템이 적어 채택 유인이 낮았고, 여러 오픈소스 커뮤니티가 하나의 형식에 합의하기 어려울 것이라는 회의론도 있었음
새 통합 표준을 만들면 기존 13개 표준이 14개로 늘어나는 XKCD식 문제가 발생하기 쉬움
Arrow는 같은 문제를 푸는 신뢰할 만한 대안이 거의 없는 상황에서 안정적인 구현을 제공하고 채택을 기다리는 방식으로 성장함
기술 자체는 최근 5~6년 동안 크게 달라지지 않았지만, 더 많은 시스템이 채택하면서
네트워크 효과에 가까운 가치 증가가 나타남
DataFusion은 쿼리 엔진을 처음부터 만들지 않고 제품에 맞게 확장할 수 있어 약 30~40개 회사가 내부 구성 요소로 활용하는 것으로 추정됨
스트리밍 데이터 엔진을 만들던 Arroyo는 Cloudflare에 인수됐고, 이후 Arrow와 DataFusion이 Cloudflare의 스트리밍 데이터 인프라 일부에 사용됨
DataFusion Comet은 Spark 가속에 활용됨

AI가 쉽게 대체하기 어려운 시스템 소프트웨어

DataFusion과 DuckDB는
바이브 코딩으로 대체품을 빠르게 만들기 어려운 종류의 프로젝트임
LLM은 기존 코드와 접근법을 평균화하는 성격이 강해, 최첨단 쿼리 엔진처럼 전문가가 세밀하게 구성한 시스템을 가까운 시일 안에 만들어내기 어려움
이런 프로젝트는 사출 성형 플라스틱 장난감보다 장인이 조립한
정밀한 스위스 시계에 가까움
AI가 영원히 만들 수 없다는 뜻은 아니지만, 현재로서는 대체 가능성이 낮음
오픈소스 프로젝트의 가치는 구현물뿐 아니라 커뮤니티가 오랫동안 축적한 신뢰에서도 나옴
유지관리자가 공동체의 이익을 고려한다는 믿음
공급망 공격을 방어하고 심각한 버그를 고칠 것이라는 기대
일관되게 잘 설계되고 신뢰할 수 있는 소프트웨어를 제공한 기록
McKinney는 2013년 이후 Pandas 개발에 깊이 관여하지 않았고, 현재는 대규모 개발자 그룹이 프로젝트를 유지하고 있음
따라서 실제 유지관리자에게 감사와 후원이 돌아가야 한다고 봄
AI로 하루에 1만 줄의 코드를 생성할 수 있어도 과거에 쌓은 품질 기준에 미치지 못하는 결과물을 공개할 수는 없으므로, 생성량보다
검토와 품질 유지가 더 중요한 과제가 됨

게임과 수학에서 프로그래밍으로

1990년대 후반 Nintendo 64의
GoldenEye 007

에 빠졌고, 1997년 말이나 1998년 초 GeoCities에 팬 사이트를 만들며 속도 경쟁 커뮤니티에 참여함

당시 웹사이트를 수작업으로 관리했지만, 경쟁 프로그래밍에 능숙했던 Kisman이 C++ 프로그램으로 사이트 갱신을 자동화하는 모습을 보며 뛰어난 프로그래머가 만드는
자동화의 효과를 접함
고등학교에서는 수학 경시대회와 컴퓨터 활용에 관심을 뒀고, MIT에서는 어린 시절부터 프로그래밍한 동료들 사이에서 큰 실력 차이를 느낌
순수수학 학위를 받으며 복잡도와 알고리듬 같은 이론적 컴퓨터 과학을 일부 공부했지만, Java에 대한 부정적인 경험 때문에 프로그래밍 자체에는 큰 흥미를 느끼지 못함
프로그래밍을 문제 해결과 개인 생산성을 증폭하는 도구로 인식한 뒤에야 본격적으로 몰입하기 시작함

금융 연구에서 시작된 Pandas

2007년 22세에 퀀트 헤지펀드에 입사했으며, 예상했던 수식 중심 연구와 달리 많은 분석이
Excel 스프레드시트와 수작업에 의존한다는 사실을 발견함
MATLAB과 R도 사용됐지만 보조 수단에 가까웠고, MATLAB 코드를 서버에 배포하려면 서버별로 비싼 라이선스가 필요했음
연구부터 프로덕션까지 이어지는 작업에는 시스템 구축에 적합한 오픈소스 언어가 필요하다고 판단함
동료의 권유로 2008년 초 Python과 과학 계산 라이브러리를 사용하기 시작했고, 기존 연구 도구를 Python으로 다시 만들면서
초기 Pandas 형태가 나타남
생산성을 높이는 도구를 만들고 다른 사람이 그 도구로 더 효율적으로 일하는 모습을 보는 과정에서 게임 속도 경쟁과 비슷한 몰입감을 느낌

단순한 사용자 경험과 내부 기술 부채

McKinney는 개인에게만 맞는 복잡한 AI 도구보다 다른 사람도 이해하고 사용할 수 있는
단순하고 일관된 도구를 중시함
지나치게 개인화된 도구 모음은 구조가 복잡해져 만든 사람 외에는 탐색할 수 없는 Winchester Mystery House 같은 상태가 될 수 있음
Pandas 초기 구현은 내부 아키텍처보다 사람이 이해하고 작성하기 쉬운 API와 사용성에 집중함
내부 구조의 혼란은 오랫동안 유지보수 부담을 남겼지만, Pandas의 성공은 소프트웨어가 완벽한 아키텍처를 갖추지 않아도 크게 성공할 수 있음을 보여줌

NumPy의 역할과 한계

NumPy는 Jim Hugunin이 1990년대 중반 시작한 다차원 배열 라이브러리 Numeric과, 메모리 매핑 등 대규모 배열 기능을 추가한 Numarray 계열을 Travis Oliphant가 2005~2006년 무렵 통합하며 만들어짐
당시 Matplotlib·SciPy·통계 및 선형회귀 도구가 NumPy 배열을 중심으로 작동했기 때문에, 새 데이터 도구가 생태계에 참여하려면
NumPy 호환성이 필수였음
NumPy는 숫자와 정수의 대규모 다차원 배열에 초점을 맞췄고, 데이터베이스나 비수치 데이터를 위한 기반으로 설계되지는 않음
초기 Pandas는 NumPy를 기반으로 삼고 비수치 데이터의 제약을 우회함
숫자나 불리언이 아닌 값은 NumPy 배열 안의 Python 객체로 저장됨
문자열 데이터에는 객체 오버헤드와 간접 참조가 발생해 효율이 낮았음
이러한 한계는 이후 Pandas 같은 시스템을 위한 대안적 인메모리 기반인
Arrow를 만드는 동기가 됨

Python 데이터 과학 생태계의 성장

벤처 투자를 받은 여러 회사가 기업마다 Google과 같은 데이터 인프라를 구축해야 한다고 홍보하면서 빅데이터 오픈소스 프로젝트에 막대한 투자가 유입됨
모든 기업에 같은 규모의 인프라가 필요했던 것은 아니지만, 이 자금이 없었다면 Arrow에 필요한 개발자를 모으는 일이 훨씬 어려웠을 가능성이 있음
당시 업계는 데이터 과학과 데이터 과학자의 의미, 비즈니스·통계·소프트웨어 능력을 함께 갖춘 인력을 어디서 구할지를 두고 경쟁함
Python은 프로그래밍 경험이 많지 않지만 통계를 아는 사람도 데이터 과학에 접근할 수 있게 함
Python for Data Analysis

와 scikit-learn 같은 도구를 익히면 2~3주 안에 업무에 유용한 분석을 시작할 수 있었음

Scala 같은 언어를 먼저 배워야 했다면 진입 장벽이 높고 학습 기간도 더 길었을 것으로 봄

Pandas 공개와 Arrow 조직의 형성

Pandas는 2009년 새해 전야에 공개하기로 결정됐고, 2010년 2월 첫 PyCon 발표를 계기로 Python 커뮤니티와 본격적으로 연결됨
McKinney는 2010년 Duke에서 통계학 박사 과정을 시작했지만, Python 데이터 도구에 대한 금융회사의 관심과 Pandas의 성장 가능성을 보고 휴학함
당시 Pandas 0.1은 조인 종류도 모두 지원하지 못할 만큼 기능이 제한적이었으며, 프로젝트 성장에 집중하기 위해 대학원을 떠남
금융 기술 사업을 검토한 뒤
Python for Data Analysis

집필과 BI 스타트업 창업으로 이어졌고, 2013년 BI 시장에서 Looker와 경쟁하기 어렵다고 판단해 Cloudera에 합류함

Cloudera에서는 Impala 개발자들과 연결됐고, 이후 Iceberg·Databricks 등에서 활동한 여러 엔지니어를 만났으며 이 경험이 이후 경력의 발판이 됨
Arrow 프로젝트는 2016년 초 Cloudera에서 시작됐지만, 당시 엔터프라이즈 소프트웨어 시장에서는 실험적 기술을 위한 전담 팀 예산을 확보하기 어려웠음
2016~2018년에는 금융회사에서 Arrow를 실제 시스템에 적용해 데이터 처리 워크로드를 가속하고 Parquet를 개선함
2018년에는 여러 기업이 Arrow 개발에 자금을 제공하려 했지만, 금융회사 규정상 외부 자금을 관리하기 어려워 기업 후원을 받을 수 있는 독립 조직을 4월에 설립함
Nvidia를 포함한 하드웨어 회사와 금융회사 등 약 6개 후원사가 참여함
약 8명 규모의 개발팀을 구성함
상업적 기회를 확인한 뒤 2020년 코로나19 시기에
Ursa Computing으로 전환함

여전히 남아 있는 데이터 엔지니어링 문제

오늘날에도 데이터 분야는 데이터를 A에서 B로 옮기고, 형식을 변환하고, 메모리에 적재하며, 쿼리와 변환을 효율적으로 실행하는 문제를 반복해서 해결하고 있음
Pandas는 예상보다 훨씬 많은 기업 데이터 흐름을 지탱하는 기반이 됐으며, 현재는 사람이 과거에 작성한 양보다 더 많은 Pandas 코드를
LLM이 생성하고 있을 가능성이 있음
DuckDB는 20년 전 개발자라면 상상하기 어려웠을 정도로 강력한 도구임
무료로 설치해 다양한 환경에서 실행할 수 있음
전화와 웹 브라우저에서도 작동할 수 있음
단일 머신에서 복잡한 설치 없이 고성능 분석을 제공함
오랜 불편과 시행착오를 통해 DuckDB·Arrow 같은 기술의 필요성이 분명해졌으며, Parquet를 비롯한 여러 해법은 Google 같은 대규모 인터넷 기업이 비용과 시간을 줄이려고 만든 기술에서 영향을 받음
Parquet는 최상의 형식은 아니지만 과거보다 크게 개선됐고 거의 모든 시스템이 지원함
Vortex와 Lance 같은 특화 대안이 있어도
충분히 좋은 호환성 덕분에 계속 사용됨
AI가 업계의 관심을 차지하면서 데이터 엔지니어링의 화제성은 낮아졌고, Databricks가 새 데이터 엔진을 발표해도 과거보다 관심을 덜 받는 상황임
반대로 데이터 도구 개발자에게는 유행을 좇지 않고 기술 완성도에 집중할 여지가 생겼으며, 테스트 작성처럼 반복적이고 불편한 작업에는 AI를 활용할 수 있음

데이터베이스 기술로의 수렴

빅데이터 시대의 주요 교훈은 데이터베이스 연구자들의 논문과 학회 결과를 더 일찍 활용했어야 한다는 것임
TU Munich·CWI·MIT·CMU·Berkeley 같은 기관의 데이터베이스 연구를 읽고 구현하며 협업하는 접근이 중요함
NoSQL과 비관계형 저장소 중심 시대에는 확장 가능한 시스템이 큰 오버헤드를 추가해, 잘 만든 단일 머신·단일 스레드 구현보다 느려지는 경우가 있었음
Frank McSherry와 Michael Isard 등이 참여한
Scalability! But at what COST?

연구는 확장성을 얻기 위해 치르는 비용 문제를 다룸

현대 데이터 스택은 다시
데이터베이스 기술과 컬럼형 처리를 중심으로 수렴함
Polars·Daft·DataFusion은 Arrow를 사용함
dbt의 새 엔진은 ADBC를 활용함
Databricks Photon은 Arrow 사용 여부와 별개로 컬럼형 구조를 채택함
주요 시스템이 비슷한 아키텍처와 접근법으로 수렴하면서, 이제는 핵심 처리 방식보다 소프트웨어를 실제로 얼마나 쉽게 사용할 수 있는지가 더 중요한 과제가 됨

Hadoop에서 DuckDB로 이어진 사용성 개선

Hadoop 시대에는 Java와 XML 설정 파일, 수많은 조정 항목 때문에 실제 작업을 시작하기 전 이틀가량을 설정에 써야 하는 경우도 있었음
Spark는 단어 수 세기를 한 줄로 작성할 수 있다는 점에서 큰 개선이었지만, 여전히 인프라와 설정 파일을 준비해야 했음
DuckDB의 설치와 실행 형태는 데이터 시스템이 얼마나 단순해질 수 있는지 보여주는
사용성 모델임
분산 시스템도 합리적인 기본값과 즉시 작동하는 설정을 제공해 운영 복잡도를 줄일 수 있어야 함
DuckDB는 클라이언트·서버 영역으로도 확장하고 있으며 MotherDuck과 긴밀히 협력함

생성형 AI를 위한 멀티모달 데이터 계층

기존 레이크하우스는 표 형식과 Parquet 중심이지만, 생성형 AI와 대규모 모델 학습·미세조정에는 이미지·영상·텍스트·문서·로그가 함께 필요함
LanceDB가 다루는
멀티모달 데이터 레이크하우스는 실제 엔터프라이즈 문제에 해당함
대규모 비정형 데이터에서 임베딩을 생성하면 전력과 GPU 시간이 소비되므로, 결과 임베딩 자체에도 계산 비용에 따른 경제적 가치가 생김
프로덕션 환경에서는 원본 데이터와 생성 결과를 안정적으로 저장·관리·처리할 데이터 저장소가 필요함
모든 기업이 독자적인 멀티모달 저장소를 만들면 버그, 데이터 손실, 성능 문제를 반복해서 겪을 수 있으므로 전문 소프트웨어 공급자가 공통 해법을 제공하는 편이 효율적임
Iceberg 테이블을 직접 운영할 수 있어도 Databricks·Snowflake·AWS 같은 사업자에게 관리를 맡기면 운영 복잡성을 줄일 수 있으며, 생성형 AI용 멀티모달 데이터에도 같은 논리가 적용됨
생성형 AI 데이터 시장에는 문서 벡터 검색과 고QPS 처리부터 데이터 수명주기 관리까지 서로 다른 계층을 해결할 여지가 남아 있음

AI 시대 개발자의 경쟁력

McKinney는 한때 자신도 소프트웨어 엔지니어로서 미래가 있는지 고민했지만, AI가 사람을
주도성 수준에 따라 더 뚜렷하게 구분한다고 판단함
주도성 높은 사람은 무엇을 만들지 숙고하고 좋은 결과를 판별하는 취향과 판단력을 바탕으로 AI에서 큰 생산성 증폭을 얻을 수 있음
LLM은 대부분의 문제에 평균적이고 무난한
B+ 수준의 접근법을 제공하지만, 사용자를 대신해 경험·취향·판단력을 만들어주지는 않음
좋은 판단 없이 생성 코드를 계속 추가하면 복잡한 수렁이 형성되고, 에이전트도 맥락과 구조에 눌려 작업을 이어가기 어려워짐
과거에는 직접 구현하며 기술과 판단력을 함께 길렀지만, 앞으로는 손코딩 시간이 줄어드는 만큼 시스템 이해와 설계 능력을 별도로 길러야 함

AI 시대에 공부해야 할 것

새 개발자는 Python·Java 문법만 익히기보다
소프트웨어 설계와 아키텍처, 데이터 시스템 구조를 공부할 필요가 있음
데이터 엔지니어링에서는 Lambda 아키텍처와 Kappa 아키텍처처럼 서로 다른 시스템이 어떻게 작동하고 어떤 문제에 적합한지 이해해야 함
에이전트에게 원하는 결과를 정확히 전달하고, 잘못된 방향으로 진행할 때 이를 알아차릴 수 있어야 함
사용자가 A와 B 중 무엇이 더 나은지 판단하지 못하면 에이전트도 올바른 선택을 대신 보장할 수 없음
소프트웨어 엔지니어·데이터 엔지니어·데이터 과학자 모두 코드 작성보다
문제 정의와 의사소통에 더 많은 시간을 쓰게 될 가능성이 있음
원하는 것을 설명할 수 없다면 AI에서도 원하는 결과를 얻을 수 없으며, 단순히 조직에 AI를 추가한다고 생산성과 경제적 성과가 자동으로 높아지지 않음
경험과 판단력이 부족한 사람에게 AI를 제공하면 유용한 산출물보다 다른 사람이 처리해야 할 부채를 대량 생성하는
슬롭 대포(slop cannon) 가 될 수 있음

늘어난 의사결정과 조직의 AI 투자

향후 2~5년 동안 개발자 채용과 기술 면접, 역할 구분은 혼란스럽고 빠르게 변할 수 있음
과거에는 회의·스프린트 계획·계획 포커를 통해 팀이 작업에 대한 공통 확신을 만든 뒤 구현을 나눠 맡았음
이제는 기존 애자일 계획 과정이 Claude의
계획 모드 안으로 압축되고, 개발자 한 명이 혼자 수많은 선택을 내려야 하는 상황이 생김
하루에 이전보다 10배 많은 결정을 내려야 하는 개발자는 결정 피로와 모호성 때문에 멈춰 설 수 있음
빠르게 판단해 효율적인 경로를 정하는 사람은 AI의 생산성을 활용할 수 있지만, 무엇을 해야 할지 확신하지 못하는 사람에게 AI는 그 문제를 해결해주지 못함
기업은 Anthropic과 OpenAI에 많은 비용을 지불하면서도 AI 투자 수익을 확인하기 어려울 수 있음
일부 긍정적인 결과와 함께 낭비, 낮은 품질의 산출물, 그 산출물을 정리하는 비용도 발생함
AI 모델 제공자는 토큰 판매가 지속되는 동안 수익을 얻지만, 고객사는 더 엄격한
토큰 예산을 적용할 가능성이 있음

오픈 웨이트 모델과 토큰 경제성

McKinney는 오픈 웨이트 중국 모델
GLM 5.2를 물리 인프라에서 실행했으며 결과가 좋았다고 평가함
GLM 5.2는 소형 모델이 아니며 제대로 실행하려면 B200 GPU 약 8개가 필요함
B200 한 개의 가격은 약
3만~5만 달러로 추정됨
전체 하드웨어 비용은 약 25만~40만 달러에 이를 수 있음
장기적으로 오픈 웨이트 모델의 품질이 높아지고 하드웨어가 저렴해지면, 외부 AI 기업에 지속적으로 비용을 내지 않고 개인 서버의 전력비만 부담하는 방식이 가능해지기를 기대함
최근 30일 동안 사용한 토큰을 API 정가로 계산하면 약
3만7천 달러였지만, 실제 모델 제공자에게 지불한 금액은 이보다 훨씬 적었음
현재 토큰 가격에는 대규모 보조가 포함됐을 가능성이 있으며, 장기적으로 어떤 비용 구조가 지속 가능한지는 불확실함
AI 도입률도 업계의 관심만큼 균일하지 않아, 일부 기업은 이사회와 CTO 수준에서 논의만 하고 실제 적용은 시작하지 않은 긴 꼬리 구간에 머물러 있음

Pandas 창시자 Wes McKinney가 말하는 AI·Apache Arrow·소프트웨어 엔지니어링의 미래

요약

핵심 포인트

Pandas에서 AI 개발 도구로 이어진 경력

Apache Arrow가 확산되기까지

AI가 쉽게 대체하기 어려운 시스템 소프트웨어

게임과 수학에서 프로그래밍으로

금융 연구에서 시작된 Pandas

단순한 사용자 경험과 내부 기술 부채

NumPy의 역할과 한계

Python 데이터 과학 생태계의 성장

Pandas 공개와 Arrow 조직의 형성

여전히 남아 있는 데이터 엔지니어링 문제

데이터베이스 기술로의 수렴

Hadoop에서 DuckDB로 이어진 사용성 개선

생성형 AI를 위한 멀티모달 데이터 계층

AI 시대 개발자의 경쟁력

AI 시대에 공부해야 할 것

늘어난 의사결정과 조직의 AI 투자

오픈 웨이트 모델과 토큰 경제성

댓글과 토론

댓글

Pandas에서 AI 개발 도구로 이어진 경력

Apache Arrow가 확산되기까지

AI가 쉽게 대체하기 어려운 시스템 소프트웨어

게임과 수학에서 프로그래밍으로

금융 연구에서 시작된 Pandas

단순한 사용자 경험과 내부 기술 부채

NumPy의 역할과 한계

Python 데이터 과학 생태계의 성장

Pandas 공개와 Arrow 조직의 형성

여전히 남아 있는 데이터 엔지니어링 문제

데이터베이스 기술로의 수렴

Hadoop에서 DuckDB로 이어진 사용성 개선

생성형 AI를 위한 멀티모달 데이터 계층

AI 시대 개발자의 경쟁력

AI 시대에 공부해야 할 것

늘어난 의사결정과 조직의 AI 투자

오픈 웨이트 모델과 토큰 경제성

댓글과 토론