엑셀 안에서 변환 규칙을 정의
__config__, source_table, XTL 표현식으로 원본 엑셀이 어떻게 결과 보고서가 되는지 적어둡니다.
워크플로 모델
엔진은 코드에, 업무 규칙은 엑셀 파일에.
개발자는 변환 엔진을 한 번만 만듭니다. 매번 바뀌는 업무 규칙, 원본 테이블 매핑, 레이아웃, 결과물의 모양은 팀이 보관하고 인수인계할 수 있는 엑셀 파일 안에 남습니다.
업로드 흐름은 단순하게
운영팀은 원본 엑셀을 올리고, 승인된 템플릿을 고르고, 변환을 실행합니다. 그것뿐입니다.
결과는 완성된 엑셀로
시트 구조, 숫자 형식, 스타일, 병합 셀까지 그대로 유지된 채 데이터만 채워진 엑셀이 나옵니다.
업무 규칙을 파일로 보관
템플릿이 곧 인수인계 자산이 됩니다. 매번 반복되는 엑셀 업무가 어떻게 동작하는지 한 파일에 정리되어 다음 담당자에게 그대로 넘어갑니다.
B2fxB2 source_table = 1
| A | B | C | |
|---|---|---|---|
| 1 | 키 | 값 | 메모 |
| 2 | source_sheet | 원본 | 읽어 들일 워크시트 |
| 3 | source_table | 1 | 컬럼명과 데이터 행 위치 |
__config__
source_table 이 원본 테이블의 시작 위치와 사용할 컬럼 범위를 엔진에 알려줍니다.
왜 개발자가 xl3 를 선택하나
반복되는 보고 업무를 일회성 스크립트에서 꺼내옵니다.
파이썬 스크립트, VBA 매크로, 서비스별 자동화 도구로도 엑셀 업무를 자동화할 수는 있습니다. 다만 그 과정에서 업무 규칙이 코드 안, SaaS 계정, 담당자 머릿속으로 흩어지는 경우가 많습니다.
xl3 는 재사용 가능한 엔진과 엑셀 파일별 업무 약속을 분리합니다. 개발자는 TypeScript 통합과 배포를 관리하고, 매번 바뀌는 엑셀 업무 규칙은 각 템플릿 엑셀 파일 안에 머무릅니다.
운영 환경 적합성
자동화보다 인수인계를 먼저 생각한 설계.
업무를 실제로 굴리는 사람은 코드를 읽지 않아도 됩니다. 안정적인 변환 엔진, 승인된 템플릿, 예측 가능한 결과 엑셀 파일이면 충분합니다.
인수인계 가능한 템플릿
업무 규칙이 엑셀 파일 안에 담겨 있어 검토, 버전 관리, 보관, 다음 담당자에게 넘기는 일까지 한 파일로 해결됩니다.
template.xlsx운영자가 다루기 편한 실행
런타임을 브라우저 페이지로 그대로 노출할 수 있습니다. 원본 데이터 업로드, 템플릿 선택, 결과 다운로드 — 코드를 읽지 않아도 됩니다.
raw.xlsx → result.xlsx엔진은 개발자가 책임
배포, 검증, 통합은 코드에서. 템플릿별 업무 규칙은 엑셀 파일에. 두 영역의 경계가 명확합니다.
convert(template, raw)XTL 0.1 은 ADR 37 개, conformance fixture 123 개를 포함하며 Stage 2 까지 모두 통과합니다. TypeScript 레퍼런스 구현은 @jinyoung4478/xl3로 공개되어 있습니다 — 다른 언어로의 포팅은 포팅 가이드 (영문)를 참고하세요.
비교
같은 문제, 다른 접근.
| 접근 | 잘하는 영역 | 대신 잃는 것 |
|---|---|---|
| xl3 | 파일 기반 엑셀 변환. 업무 규칙은 template.xlsx 안에 머뭅니다. | Alpha 단계입니다. XTL 언어 표면은 의도적으로 작게 유지하며 아직 다듬는 중입니다. |
| 파이썬 / VBA 스크립트 | 기존 스프레드시트와 가까운 빠른 일회성 자동화. | 규칙이 코드나 한 담당자의 기억에 남기 쉬워 검토와 인수인계가 어렵습니다. |
| Power Query / Office Scripts | Microsoft 365 워크플로, 엑셀 생태계 안에서의 데이터 가공. | 자동화가 테넌트와 계정에 묶여 어디서든 열 수 있는 엑셀 파일 형태로 남기 어렵습니다. |
| 스프레드시트 SDK (SheetJS, ExcelJS, Aspose) | 저수준 또는 풀-기능 코드 기반 엑셀 파일 생성. | 보고서별 규칙을 결국 애플리케이션 코드 안에 직접 넣게 됩니다. |
| 템플릿 엔진 (JXLS, xltpl) | 스프레드시트형 템플릿 기반의 서버 사이드 보고서 생성. | 특정 언어와 런타임에 묶이는 경우가 많고, 운영자 흐름이 메인 제품 형태는 아닙니다. |
| 문서 생성 SaaS (Plumsail, Conga) | 관리형 문서 워크플로, 외부 통합, 결재 프로세스. | 규칙이 vendor 서비스 안에 남고, 자체 호스팅 가능한 포터블 템플릿이 아닙니다. |
| LLM 기반 스프레드시트 생성 | 일회성 탐색과 초안 만들기. | 반복되는 운영 업무를 위한 결정적 변환 계약으로 쓰기에는 부적합합니다. |
개발자 API
같은 워크플로를 제품에 그대로 붙입니다.
데모의 흐름을 그대로 내부 포털, CLI, 서비스 엔드포인트로 옮길 때 패키지를 가져다 씁니다. 운영자 입장은 파일 기반으로 그대로 두고, 애플리케이션이 배포와 검증을 책임집니다.
$npm install @jinyoung4478/xl3import { convert } from '@jinyoung4478/xl3';
const outputs = await convert(templateBuffer, dataBuffer);
// OutputFile[] → 형식이 적용된 .xlsx 결과들