표 형식 데이터를 위한 범용 인메모리 계층, Apache Arrow의 탄생

엑셀 시트의 수천 개 셀을 일일이 수정하는 비효율을 없애기 위해 Wes McKinney는 22세에 퀀트 헤지펀드에 입사한 뒤 Pandas(표 형태의 데이터를 다루는 파이썬 라이브러리)의 초기 형태를 구축했다. 2010년 2월 PyCon에서 오픈소스로 공개된 이 도구는 엑셀과 수작업에 의존하던 분석 환경을 과학 계산 라이브러리 기반의 효율적인 체계로 바꿨다.

Apache Arrow(시스템 간 데이터 전송 표준 프레임워크)는 여기서 더 나아가 표 형식 데이터를 위한 범용 인메모리 기반 계층을 제공한다. NumPy(수치 계산 라이브러리)가 문자열 같은 비수치 데이터를 처리할 때 객체 오버헤드와 간접 참조로 인해 효율이 떨어졌던 한계를 해결하기 위해 탄생했다. Arrow는 데이터를 메모리 내에서 처리하고 전송하는 방식을 표준화하여, 서로 다른 시스템이 데이터를 주고받을 때 형식을 다시 맞추는 변환 과정 없이 곧바로 읽어 들일 수 있게 함으로써 데이터 전송과 처리 속도를 높였다.

이 표준을 채택하는 시스템이 늘어날수록 데이터 변환 비용이 줄어들어 전체 분석 파이프라인의 효율이 결정된다. 표준화된 인메모리 계층은 소프트웨어 사이의 데이터 호환성을 확보하는 핵심 장치가 된다.

평균적인 코드 생성으로 대체할 수 없는 정밀한 시스템 설계

AI가 순식간에 수천 줄의 코드를 짜준다면 정교한 소프트웨어 설계자는 필요 없을까? LLM(거대언어모델)은 기존에 공개된 수많은 코드와 접근 방식을 평균적으로 학습해 결과물을 내놓는 특성이 있다. DuckDB(분석용 내장 데이터베이스)나 DataFusion(러스트 언어 기반 쿼리 엔진)처럼 전문가가 세밀하게 최적화한 최첨단 시스템은 이런 평균적인 생성 방식으로는 구현하기 어렵다. 시스템 소프트웨어의 성능은 아주 작은 최적화의 차이에서 결정되기 때문에, 단기간에 AI가 정밀한 부품을 조립하듯 시스템을 구축하는 것은 한계가 있다.

따라서 엔지니어의 가치는 AI가 쏟아내는 코드의 양이 아니라, 생성된 코드가 정밀한 시스템의 성능 기준을 충족하는지 판단하고 수정하는 설계 역량에서 결정된다.

언어 문법보다 아키텍처와 판별 능력이 핵심인 시대

ChatGPT가 짜준 코드를 복사해 붙였으나 예상치 못한 에러로 해결 시간이 늘어나는 사례가 빈번하다. 이제 엔지니어에게 필요한 능력은 언어 문법이나 손코딩이 아니라, 전체 시스템의 구조를 잡는 아키텍처 설계, 정확한 문제 정의, 그리고 AI 결과물의 정답 여부를 가려내는 판별 능력이다. 기업 또한 사람이 직접 코드를 작성하는 시간보다, AI의 결과물을 검토하는 의사결정 과정과 토큰 비용(AI 모델 사용료)을 관리하는 운영 체계를 구축해야 하는 과제를 안게 됐다.

오픈소스 프로젝트의 가치는 단순히 공개된 코드 뭉치가 아니라, 유지관리자가 버그를 해결하고 공급망 공격(소프트웨어 배포 과정에 악성 코드를 삽입하는 해킹)을 방어하며 쌓아온 신뢰와 품질 기록에 있다. AI가 방대한 양의 코드를 생성하더라도, 엄격한 품질 기준을 유지하며 이를 검증하는 인간의 능력은 더욱 중요해진다.

결국 데이터 전송을 표준화해 프로그램 간 상호운용성을 높인 Apache Arrow의 사례처럼, 정밀하게 설계된 소프트웨어 구조는 AI의 평균적인 코드 생성만으로 대체될 수 없다.

오늘 AI가 짜준 코드를 그대로 붙여넣기 전에, 이것이 정밀한 시스템 기준을 충족하는 설계인지 먼저 검토하는 습관을 가져보자. AI가 쏟아내는 코드의 양보다 그것을 가려내는 안목이 곧 실무자의 경쟁력이 된다.