• 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 수준에서 논의만 하고 실제 적용은 시작하지 않은 긴 꼬리 구간에 머물러 있음

댓글과 토론