AI가 작성한 코드를 사람이 안전하게 검토하기 위한 언어, Jacquard
코드 생성 도구의 활용이 일상화되면서, 개발자의 역할이 '코드를 직접 작성하는 사람'에서 '생성된 코드를 검토하고 신뢰 여부를 판단하는 사람'으로 빠르게 이동하고 있다. Jacquard는 바로 이 문제를 정면으로 겨냥한 실험적 프로그래밍 언어다. 핵심 철학은 단순하다. 모델이 코드를 작성하고, 사람이 검토한다. 그리고 그 검토를 언어 차원에서 지원한다.
이펙트 시스템: 함수가 세상과 어떻게 접촉하는지 명시한다
Jacquard의 가장 핵심적인 설계는 이펙트 시스템(effect system) 이다. 모든 함수 시그니처에는 해당 함수가 외부 세계와 어떻게 상호작용하는지가 명시된다. 네트워크 호출, 파일 I/O, 시스템 시각 참조, 난수 생성 등 사이드 이펙트의 종류가 타입 수준에서 선언된다.
런타임은 커맨드라인에서 명시적으로 허가하지 않은 이펙트를 실행 자체를 거부한다. 즉, 코드가 어떤 외부 효과를 낼 수 있는지를 검토자가 시그니처만 읽어도 파악할 수 있고, 체커가 그 시그니처의 완전성을 보장한다.
-- 네트워크와 파일 접근이 필요한 함수임을 시그니처에 명시
fn fetch_and_save [network, files] (url: String, path: String) -> Result
Java 백엔드 개발자 입장에서 보면, 이는 스프링의 @Transactional이나 체크드 예외처럼 "이 코드가 어떤 영향을 줄 수 있는가"를 컴파일 타임에 강제하는 접근과 맥이 닿는다. 다만 Jacquard는 그 범위를 파일, 네트워크, 시간, 난수 전체로 확장한다.
구현 구조와 실용적 특성
Jacquard의 구현체는 OCaml로 작성되었으며, 다음 구성 요소로 이루어진다.
- 체커 및 인터프리터:
.jac(공개용 소스) 또는.jqd(로우레벨) 파일을 처리 - 컴파일러: C 코드를 중간 표현으로 생성하여 네이티브 바이너리 산출
jacCLI 도구: 커맨드라인에서 이펙트 허가 범위를 직접 지정- 표준 라이브러리: Jacquard 자체로 작성
- Warp: 내장 테스트 프레임워크
현재 버전(0.1)은 엔드투엔드로 동작하지만 프로덕션 언어가 아닌 리서치 프로토타입임을 명확히 밝히고 있다. GitHub에서 Apache-2.0 라이선스로 공개되어 있다.
백엔드 개발자에게 주는 시사점
당장 프로덕션에서 Jacquard를 쓸 수는 없다. 그러나 이 프로젝트가 던지는 질문은 실무적으로 유효하다. 생성된 코드를 빠르고 안전하게 검토하려면 언어/런타임이 어떤 정보를 제공해야 하는가?
Java 생태계에서도 유사한 방향의 시도들이 있다. Project Loom의 구조적 동시성, @Effect 애너테이션 기반의 정적 분석 도구, 혹은 아키텍처 테스트 라이브러리(ArchUnit) 등이 "이 코드가 어디까지 영향을 미치는가"를 통제하려는 시도들이다. Jacquard는 그 방향을 언어 설계 수준까지 밀어붙인 사례로 읽힌다.
코드 리뷰의 부담이 늘어나는 시대에, 검토자가 시그니처 하나로 해당 코드의 외부 영향 범위를 파악할 수 있다면 리뷰 품질과 속도 모두 개선될 수 있다.
정리
- Jacquard는 모든 함수 시그니처에 이펙트(네트워크, 파일, 시간 등)를 명시하고, 런타임이 미허가 이펙트 실행을 거부하는 이펙트 시스템 기반 언어다.
- 생성된 코드를 사람이 안전하게 검토할 수 있도록 설계된 리서치 프로토타입으로, OCaml 기반 체커·컴파일러·CLI·테스트 프레임워크를 포함한다.
- Java 백엔드 실무 관점에서도 "코드의 외부 영향 범위를 타입/시그니처 수준에서 강제하는" 설계 방향은 리뷰 효율화와 안전성 확보를 위한 중요한 참고점이 된다.