Acadia는 SQL을 컴파일 대상으로 바꿀 수 있을까요

데이터베이스 코드는 애플리케이션의 타입 시스템과 자주 따로 움직여요. Elm 창시자 Evan Czaplicki가 공개한 Acadia는 테이블과 쿼리를 함수형 코드로 작성한 뒤 SQL로 컴파일해 이 간격을 줄이려는 개발 도구예요. 아직 Public Alpha라서 당장 운영 환경에 넣기보다 설계와 생성 SQL을 직접 확인해 볼 단계에 가까워요. 1
핵심 요약
| 구분 | 내용 |
| 무엇이 나왔나요 | Elm 창시자가 수년간 개발한 Acadia의 Public Alpha가 공개됐어요. |
| 어떻게 작동하나요 | 테이블과 Endpoint를 함수형 코드로 정의하면 컴파일러가 SQL을 만들어요. |
| 무엇을 줄이나요 | 클라이언트, 서버, 데이터베이스 사이의 타입 불일치를 컴파일할 때 찾는 것이 목표예요. |
| 지금 쓸 수 있나요 | Elm과 Haskell 연동을 지원하지만, 고급 쿼리 기능 일부는 아직 빠져 있어요. |
1. SQL 문자열 대신 함수형 코드로 쿼리를 작성해요
Acadia에서는 테이블을 일반 데이터 타입처럼 정의해요. 기본 키, 인덱스, 제약 조건, 행 단위 보안 정책도 같은 코드에 적을 수 있어요. 쿼리는 SQL 문자열을 조립하는 대신 `map`과 `filter` 같은 함수형 연산으로 표현해요. 컴파일러는 이 코드를 SQL로 변환하고 실제 실행할 SQL도 출력해요. 개발자는 추상화 뒤에 숨은 쿼리를 직접 확인할 수 있어요. 2
이 접근은 ORM이 객체와 테이블을 연결하는 방식과 출발점이 달라요. Acadia에는 객체 모델이 없어요. 함수형 언어의 타입과 데이터베이스 스키마를 연결하고 SQL을 컴파일 결과물로 다뤄요. 표현하지 못하는 작업이 있으면 내부의 일반 SQLite로 내려가 SQL을 직접 쓸 수 있어요.
애플리케이션 타입을 데이터베이스까지 이어가요
Rust의 Enum, Elm의 Custom Type, Haskell의 Algebraic Data Type처럼 값의 경우를 정확히 나누는 타입은 데이터베이스에 저장할 때 모양이 흐트러지기 쉬워요. JSON이나 여러 Nullable 열로 바꾸면 애플리케이션이 기대하는 타입과 실제 저장 구조가 어긋날 여지가 생겨요.
Acadia는 같은 타입 정보를 클라이언트, 서버, 데이터베이스에서 공유하는 방향을 택했어요. 테이블 열의 타입이 바뀌면 관련 Elm 코드에서 컴파일 오류를 보여 주는 것이 목표예요. 런타임에 데이터를 읽고 나서야 변환 오류를 발견하는 대신 코드 변경 시점에 불일치를 찾으려는 설계예요.
마이그레이션도 컴파일러가 미리 확인해요
스키마 마이그레이션은 현재 열 타입과 바꾸려는 타입을 모두 알고 있어도 사람이 실행 순서와 변환 가능성을 점검하는 경우가 많아요. Acadia는 이 정보를 컴파일러에 넘겨 마이그레이션을 사전에 확인하려고 해요. 여러 데이터베이스 작업은 하나의 `Transaction`으로 묶을 수 있어요. 앞 단계에서 만든 값도 다음 작업에서 일반 변수처럼 사용할 수 있고, 모든 단계가 성공해야 커밋돼요.
여기에는 확인할 부분도 남아 있어요. Public Alpha는 대부분의 일반 쿼리를 작성할 수 있지만 Window Function과 Custom Aggregate Function을 아직 지원하지 않아요. 현재 공식 연동 대상도 Elm과 Haskell이에요. PostgreSQL을 포함한 여러 데이터베이스에서 같은 설계가 어디까지 통할지, 1+N 쿼리와 오래된 클라이언트가 얽힌 마이그레이션을 어떻게 처리할지는 후속 설명이 더 필요해요. 2
왜 중요한가요
백엔드에서 타입 안전성을 높이려는 도구는 많지만, 데이터베이스 경계에서는 SQL 문자열과 별도 스키마 정의가 남는 경우가 많아요. Acadia는 언어의 타입 검사 범위를 쿼리와 마이그레이션까지 넓혀요. 이 설계가 잘 작동하면 열 이름이나 타입을 바꿨을 때 영향을 받는 코드를 배포하기 전에 찾을 수 있어요. 생성된 SQL을 공개해 성능과 동작을 개발자가 점검할 수 있다는 점도 실무 평가에 도움이 돼요. 2
다만 알파 버전의 아이디어와 운영 환경의 안정성은 구분해서 봐야 해요. 지원하는 언어와 SQL 기능이 제한돼 있고, 공식 글도 실험과 피드백을 받는 단계라고 밝혀요. 지금은 기존 ORM을 곧바로 바꾸기보다 예제 프로젝트에서 타입 연결 방식, 생성 SQL, 마이그레이션 동작을 확인하는 편이 맞아요.
참고 자료
- Acadia - 데이터베이스 프로그래밍을 다시 생각하기 — GeekNews
- Rethinking Database Programming — Acadia Engineering
'IT & AI' 카테고리의 다른 글
| Qwen3.8 검열 제거 모델, 맥에서 돌리기 전에 봐야 할 위험 (0) | 2026.08.19 |
|---|---|
| 2026년 개발자의 매일 쓰는 도구, 새것보다 조합이 중요해요 (0) | 2026.08.19 |
| DDR5 64GB가 1년 새 5배, 메모리 가격은 왜 이렇게 올랐을까요 (0) | 2026.08.19 |
| 원치 않는 AI 기능, 한 번 껐다고 끝나지 않아요 (0) | 2026.08.19 |
| 구글이 1,000만 달러에 산 것은 항공사가 아니라 데이터였어요 (0) | 2026.08.19 |