[뉴스] 하퍼, 5.2 공개하며 '멀티 시스템 스택' 반대 - DB와 앱을 한 런타임에

데이터베이스 플랫폼 하퍼(Harper)가 5.2 버전을 공개하면서 "애플리케이션 서버 따로, DB 따로, 캐시 따로 두는 멀티 시스템 스택은 그만두자"는 주장을 함께 내놨습니다. InfoQ가 8월 20일 이 릴리스를 다뤘습니다. 지금까지 웹 서비스는 애플리케이션 서버와 데이터베이스, 캐시(레디스), 메시지 큐를 각각 별도 시스템으로 두고 네트워크로 연결하는 구성이 당연했는데, 하퍼는 이 계층들을 하나의 런타임 안으로 합치자고 말합니다. 코드와 데이터를 같은 프로세스에 두면 시스템 사이를 오가는 네트워크 홉과 직렬화 비용이 사라진다는 것입니다. 하퍼가 제시한 수치로는 별도 계층으로 나가는 네트워크 요청이 약 3ms인 반면, 같은 프로세스 안의 데이터 접근은 약 0.4ms였습니다.

5.2에서 실제로 손본 부분은 운영자 입장에서 눈에 들어옵니다.

• 레코드 캐시를 추가해 반복 읽기(warm read)를 5~8배 빠르게 처리합니다.
• 데이터베이스마다 커밋 경로를 분리해, 무거운 쓰기가 무관한 작업을 붙잡아 두지 않게 했습니다. 이 덕분에 서로 관련 없는 파일시스템 호출의 p99 지연이 223.7ms에서 2.6ms로 떨어졌다고 합니다.

하퍼는 같은 이모지 상품 카탈로그를 하퍼 한 벌과 버셀 스택(버셀 함수, 네온 포스트그레스, 업스태시 레디스, Ably) 한 벌로 각각 구현해 474회 부하 테스트를 돌린 결과도 공개했습니다. 결과는 워크로드에 따라 갈렸습니다. 개인화된 읽기가 많은 경우 하퍼가 최대 14배 빨랐지만, 캐시가 잘 먹는 공용 콘텐츠나 동시성이 높은 팬아웃 상황에서는 버셀 쪽이 더 나았습니다. 하퍼의 알렉스 하우곰(Aleks Haugom)은 "개인화된 읽기는 다른 서비스로 나가는 네트워크 요청이 아니라 인메모리 테이블에 대한 함수 호출"이라고 표현했습니다.

이 소식이 눈에 띄는 이유는 업계가 정반대 방향으로도 움직이고 있기 때문입니다. 데이터브릭스가 올해 2월 내놓은 레이크베이스(Lakebase)는 컴퓨트와 스토리지를 분리하는 쪽에 걸었는데, 하퍼는 계층을 합치는 쪽에 걸었습니다. 확장성을 위해 떼어내느냐, 운영 단순화와 비용을 위해 붙이느냐의 선택인 셈입니다. DBA나 서버 운영자 입장에서 보면 벤치마크 숫자 자체보다 우리 워크로드가 개인화 읽기 중심인지 아니면 캐시가 잘 먹는 공용 콘텐츠 중심인지를 먼저 따져 봐야 한다는 점이 실무적으로 남습니다. 벤더가 자기 제품으로 돌린 자체 벤치마크라는 점은 감안하고 보는 게 좋겠습니다.

🔗 https://www.infoq.com/news/2026/08/harper-vercel-benchmark/

🔗 https://www.harper.fast/resources/harper-5-2-more-throughput-per-node-fewer-systems-around-it