# Pandas 창시자가 말하는 AI·Apache Arrow·소프트웨어 엔지니어링의 미래 [유튜브] > Clean Markdown view of GeekNews topic #31516. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31516](https://news.hada.io/topic?id=31516) - GeekNews Markdown: [https://news.hada.io/topic/31516.md](https://news.hada.io/topic/31516.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-07-17T09:54:25+09:00 - Updated: 2026-07-17T09:54:25+09:00 - Original source: [youtube.com](https://www.youtube.com/watch?v=wdFt2F9uTZU) - Points: 3 - Comments: 0 ## Topic Body - 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 수준에서 논의만 하고 실제 적용은 시작하지 않은 긴 꼬리 구간에 머물러 있음 ## Comments _No public comments on this page._