Frame

한 줄 소개: 한국 회계기준(KSME · K-GAAP)을 따르는 복식부기 회계 백엔드. 법인마다 장부가 물리적으로 분리되고, 모든 쓰기는 되돌릴 수 없는 감사 로그로 남는다. 사람은 웹 화면으로, AI 에이전트는 MCP 93개 도구로 같은 장부를 다룬다.

주소

세 주소 모두 인증이 필요하다 — 로그인하지 않고 열면 401 이 돌아온다(브라우저는 로그인 화면으로 간다). 호스트 맨 주소 https://frame.axelabs.ai 는 /frame/ 으로 옮겨 준다.

고객 전용 인스턴스는 같은 호스트의 경로에 선다 — 웹 https://frame.axelabs.ai/t/<tenant>/frame/, MCP https://frame.axelabs.ai/t/<tenant>/frame/mcp. 입구는 모두에게 같다: 어느 경로로 들어와도 로그인한 계정의 테넌트가 화면을 정하고, 다른 테넌트의 입구로 들어온 사람은 로그인 직후 자기 자리로 옮겨진다(그 입구에서는 세션을 만들지 않는다). 인스턴스마다 쿠키 경로가 겹치지 않아 한 인스턴스의 세션이 다른 인스턴스로 실리지 않는다. 예전 주소 https://axe.axelabs.ai/frame/... 는 호환용으로 남아 MCP 커넥터는 그대로 쓰고, 브라우저 페이지는 frame.axelabs.ai 의 같은 경로로 옮겨 준다.

무엇을 하는가

• 복식부기 장부 — 차변·대변이 맞지 않는 분개는 애초에 기재되지 않는다. 분개 등록은 다층 검증을 통과해야 커밋된다.
• 개인정보 암호화 — 법인별 salt는 완성된 값만 원자적으로 확정하고 디스크 저장을 확인한 뒤 사용한다. 첫 접근이 동시에 일어나도 빈 salt를 읽는 경합을 막으며, 기존 salt를 덮어쓰지 않는다.
• 법인별 격리 — 법인·펀드마다 별도 스키마. 한 법인의 조회가 다른 법인의 데이터에 닿지 않는다. 법인(corporate)과 펀드(개인투자조합·벤처투자조합)를 같은 평면에서 다룬다.
• append-only 원장 — 원천 거래(입출금)와 분개 라인은 수정·삭제 권한 자체가 없다. 정정은 역분개로만 한다. 모든 쓰기는 감사 로그에 1행씩 남는다.
• 원천 데이터 자동 적재 — 은행·카드·홈택스 등에서 받은 파일을 올리면 포맷을 자동 인식해 원천 거래로 적재한다. 한 번 인식한 포맷은 캐시되어 다음부터 즉시 처리된다.
• 재무제표 4종 — 재무상태표 · 손익계산서 · 현금흐름표(간접법) · 자본변동표. 시산표는 임의 시점으로 조회할 수 있다.
• 증빙 보관 — 모든 증빙은 내용 해시로 주소화해 보관하고, 분개에서 증빙까지 링크가 끊기지 않는지 정기적으로 검사한다.
• 외부 재무 서비스 수집기 — AXE 법인과 고객 전용 인스턴스가 클로브의 공식 MCP에서 은행 거래·세금계산서를 받아 원천 행으로 적재한다. 조회 도구 이름 허용 목록과 법인별 고정 워크스페이스를 지킨다. 도구 목록 변경은 자동 비교하고, 쓰기 도구 변경과 호환되는 조회 도구 변경은 기록하며 계속한다. 조회 도구 삭제·쓰기 전환·비정상 도구 정의·인자 또는 응답 적재 계약 불일치면 멈추고 알린다. 응답의 필수값은 거래 ID·일자와 계좌 식별로 제한하며 선택 금액·통화·빈 목록은 기존 기본값으로 처리한다. AXE 세금계산서의 13자리 개인 식별번호는 저장 전에 마스킹하고, 승인번호 형식이 맞지 않으면 증빙 생성을 보류한다. 고객 증빙은 재현 계약에 따른 원문 보존 정책을 유지한다. 같은 기간의 재수신은 중복을 걸러 내고 회차별 건수·합계·잔액 흐름을 점검한다. AXE 법인의 카드 승인내역을 적재하며, 계좌별 전환 시점 이하 거래는 대조에 사용하고 해외 승인의 환산 차이도 제한된 범위에서 짝지어 처리한다. 전환 시점 이하에서는 이전 수집에 빠진 전액취소만 원승인과 연결해 추가하고, 원승인이 이미 분개됐으면 정정 필요를 표시한다. 모호한 카드 계좌와 검토가 필요한 취소는 보류하고 이슈로 남긴다. 현금영수증은 실제 응답으로 검토한 매핑에 따라 수집에 동의한 법인만 적재한다. 상호·메모 칸은 저장하지 않고, 식별번호가 개인 식별번호 형태이면 그 행을 보류하고 알린다.
• AXE 롯데카드 수집 일원화 — 롯데 자체 스크래퍼는 비활성으로 유지하고 클로브 카드 적재로 일원화한다. 전환 시점 이하 거래는 해외 승인 환산 차이를 포함해 대조하고, 이전 수집에 없는 취소만 원승인에 연결해 보충한다. 이미 분개된 원승인은 정정 대상으로 표시하며, 해소된 보류와 경보는 자동으로 닫는다.
• 고객 전용 인스턴스 옵션 — 외부 AI 호출 차단(양식 자동 판별·AI 분류를 쓰지 않는다), MCP 응답의 거래처·적요 가림, 그 고객 테넌트가 아닌 계정의 로그인·MCP 접근 차단. 기본은 모두 꺼져 있다. 고객 전용 외부 재무 서비스 수집기는 외부 AI 차단과 테넌트 차단이 켜진 인스턴스에서 돈다. AXE 법인 수집은 AXE 인스턴스에서 실행하며 이 두 스위치를 기동 조건으로 강제하지 않는다. 가림은 고객이 고르며 수집기의 조건이 아니다.
• 결산 — 회계기간을 열고(open) → 가마감(soft close) → 확정(hard close) 으로 전이시킨다. 확정된 기간에는 기재가 막힌다. 전기 마감 잔액을 당기 기초로 이월한다.

쓰는 방법

인증

Microsoft 계정으로 로그인한다. MCP 클라이언트는 커넥터 등록 시 표준 OAuth(PKCE) 흐름을 타고, 브라우저는 같은 계정으로 SSO 한다. 인증되지 않은 MCP 요청에는 401 과 함께 인가 서버 위치를 알려주는 표준 메타데이터가 돌아가므로, 클라이언트가 흐름을 자동으로 이어간다.

권한은 법인 × 스코프로 부여된다.

고객 전용 인스턴스는 그 고객 테넌트의 계정만 받는다 — 다른 테넌트 계정은 MCP 에서 TENANT_MISMATCH, 웹에서는 로그인 거부(AXE 운영자는 인스턴스의 허용 목록으로만). 같은 인스턴스는 외부 재무 서비스 수집기의 회차마다 받은 건수·적재 건수·점검 결과를 법인 장부 안의 회차 기록으로 남기고, 수집기는 운영자 CLI 명령 하나(1회 또는 상주 루프)로 돈다.

앞의 셋은 위가 아래를 겸한다(close 를 가지면 read·write 도 된다). reopen 과 admin 은 그 사다리 밖이라 토큰에 그 이름이 그대로 있어야 하고, close 나 admin 이 reopen 을 대신 서지 못한다. 그래서 write 만 든 호출자가 allow_soft_closed=True 를 넘기면 기재가 아니라 SCOPE_INSUFFICIENT 를 받는다 — 그 인자는 호출자가 채우는 불리언이라, 인가가 평범한 write 뿐이면 write 스코프 하나로 소프트클로즈된 기간이 열린다.

CLI

환경 변수

frame 스택의 망 구성과 원본 저장소 설정이다. 비밀값이 아니므로 컨테이너·호스트 환경에 평문으로 둔다.

두 값이 말하는 것은 같은 체인의 앞뒤 홉이다. 프록시가 믿는 대역이 상류 홉을 덮지 못하면 프록시가 상류의 X-Forwarded-Proto 를 스푸핑으로 보고 버린 뒤 자기 평문 리스너의 스킴으로 덮어쓰고, 앱이 믿는 집합이 프록시 홉을 덮지 못하면 앱이 프록시가 붙인 그 헤더를 아예 보지 않는다 — 어느 한쪽만 자기 앞 홉을 놓쳐도 리다이렉트가 평문으로 나가고 Secure 쿠키가 붙지 않아 로그인이 이뤄지지 않는다. 실제로 났던 회귀가 그 두 모양이다: 프록시 설정에 신뢰 선언이 아예 없었고, 앱은 웹 서버 기본값이 loopback 하나뿐이라 컨테이너 네트워크로 들어온 프록시를 신뢰하지 못했다. 지금은 양쪽 기본값이 그 홉을 덮으므로 두 변수를 비워 둔 배치에서도 서고, 변수는 기본값을 통째로 대체한다 — 배치마다 믿어야 할 프록시가 다르기 때문이며, 셀프호스트 compose 는 그것으로 신뢰를 홉 하나로 좁힌다. 닫히지 않는 것도 적어 둔다: 프록시가 게시한 포트로 들어오는 요청의 소스 주소는 언제나 그 홉의 게이트웨이라 프록시는 터널과 호스트-로컬 피어를 구별하지 못하고 그 헤더를 그대로 넘긴다 — LAN·tailnet 피어는 프록시와 앱의 호스트 포트를 loopback 에만 묶어 닫고, 이 두 값이 닫는 것은 앱 직행 위조이며, 호스트-로컬까지 닫으려면 터널이 frame_edge 에 직접 붙어 그 주소 하나만 신뢰해야 한다(전용 인입 홉 = B-frame-edge-dedicated-ingress-hop).

외부 요청은 터널 → 프록시 → frame 순으로 오고 마지막 홉이 컨테이너 네트워크라, frame 이 보는 피어는 loopback 이 아니라 프록시 컨테이너의 주소다. 그 주소가 이 집합에 없으면 forwarded 헤더가 버려져 리다이렉트의 Location 이 https 에서 http 로 강등되고(트레일링 슬래시 리다이렉트에서 실제로 났던 증상), 로그인 감사 줄에 실제 클라이언트 IP 대신 프록시 주소가 남는다.

반대로 아무 피어나 믿게 두면 두 값이 요청자 선택값이 된다 — 감사 로그의 IP 도, 모든 리다이렉트의 스킴도. 그래서 신뢰를 주소가 아니라 소속으로 정의한다. frame_edge 는 리버스 프록시와 MCP blue/green 만 올라가는 전용 네트워크이고 서브넷이 compose 에 못박혀 있어 셀프호스트 배치가 두 변수에 주는 값이 그 네트워크를 글자 그대로 가리킨다(셋이 어긋나면 테스트가 잡는다). 프록시는 이 네트워크에만 붙어 있으므로 신뢰 집합에 드는 홉은 그것 하나뿐이다. frame 워커와 blueprint 는 종전 기본 네트워크로 같은 이름의 MCP 에 계속 닿지만, 그 홉의 주소는 이 서브넷 밖이라 그들이 보낸 forwarded 헤더는 무시된다 — 브라우저가 아니라 Bearer 토큰 API 클라이언트라 잃는 것이 없고, 대신 감사 IP 와 리다이렉트 스킴을 그들이 정할 수 없게 된다.

/health 응답에는 forwarded_proto 필드가 있다 — 신뢰하는 프록시가 보낸 X-Forwarded-Proto 를 앱이 실제로 반영했는지 배포 검증에서 확인할 수 있도록, 그 요청에 대해 해석된 스킴(https 또는 http)을 그대로 보고한다. 운영자 CLI 의 frame 스왑은 컷오버 뒤 프록시를 거쳐 이 값이 https 인지 확인한다.

로그인 경로 점검 /frame/health/sso 은 인증 없이 실제 로그인과 같은 코드로 플랫폼 로그인의 토큰 교환과 서명키 조회를 시험해, 둘 다 되면 200·하나라도 막히면 503 을 돌려준다(결과는 60초 캐시, 비밀·주소·오류 문구는 싣지 않는다 — D-ops-120).

AXE 클라우드 배치는 compose 를 운영자 CLI 가 생성해 frame_edge 도 이 두 변수도 없다 — 거기서는 코드·파일 기본값(loopback + RFC1918)이 그대로 서서 프록시가 계속 신뢰받는다. 기본값을 홉 서브넷으로 좁히지 않는 이유가 그것이다: 기본값이 착지할 수 있는 위상보다 좁으면 그런 배치가 조용히 자기 프록시를 불신하게 되고, 좁히기는 좁은 위상을 실제로 가진 compose 가 준다.

상태 점검

두 응답 본문의 slot은 응답한 배포 색(blue 또는 green)이다. 엣지에서도 어느 색이 응답했는지 구별할 수 있으며, 색을 지정하지 않은 단일 컨테이너·로컬 실행에서는 null이다. /health/ready의 503 응답에도 slot이 포함된다.

MCP 도구 93개

조회 — 잔액·재무제표

조회 — 분개·거래·증빙

조회 — 결의서·고정자산·급여

기재 — 분개

기재 — 적재·증빙

기재 — 전자(세금)계산서 발행 (볼타)

매출 전자(세금)계산서를 발행대행사 볼타(Bolta)의 API 로 정발행하고, 국세청 승인번호가 나오면 증빙과 분개(미수금 / 매출 / 부가세)를 장부에 자동으로 남긴다. 순서는 항상 미리보기 → 발행 → (필요하면) 재확인이다. 라이브 발행은 되돌릴 수 없고 정정은 수정발행으로만 한다(frame 미지원 — 볼타 대시보드).

• 키는 법인마다 live(실발행)와 test(샌드박스)를 따로 둔다 — FRAME_BOLTA_API_KEY_<법인> / FRAME_BOLTA_TEST_API_KEY_<법인>, 값은 vault 에서 주입. 호출자가 mode 를 명시하면 그 슬롯의 키만 쓰고, 다른 법인·다른 mode 키로 넘어가지 않는다.
• 이중 발행을 막는다. 같은 요청은 같은 관리번호로 보내고, 보내기 직전 발행 의도를 장부에 기록하며, 이미 보낸 요청과 같은 내용이면 볼타 키나 서버 비밀이 바뀌었어도 다시 보내지 않는다. 결과가 확정되지 않은 건은 재발행이 아니라 재확인(sync_tax_invoice)만 안내한다.
• test 키 결과는 실제 법인 장부에 기록하지 않는다. 작성일자 기간이 닫혀 있으면 증빙만 남기고 분개는 보류한다(기간을 연 뒤 재확인하면 분개).

기재 — 정기 발행 스케줄 (볼타)

매월 같은 거래처에 같은 내용으로 발행하는 매출 전자(세금)계산서를 스케줄로 등록하면, 실행기가 회차마다 위 볼타 발행과 같은 경로(미리보기 → 발행 → 재확인)로 발행하고 장부에 기록한다. 순서는 초안 생성(미리보기) → 사람이 승인 → 회차 자동 발행이다. 라이브 스케줄은 승인 후 자동 발행되며 되돌릴 수 없다(정정은 수정발행 — frame 미지원).

• 작성일은 스케줄마다 규칙으로 정한다 — 예: 매월 25일(휴일이면 전 영업일), 매월 1일(휴일이면 다음 영업일). 달에 없는 날은 말일로, 휴일 이월은 작성월 안에서만 한다. 휴일은 토·일과 frame 에 내장된 관공서 공휴일 달력(설·추석·대체공휴일·선거일 포함, 매년 다음 해 월력요항이 나오면 갱신)이다. 달력이 아직 없는 해의 회차는 “토·일만 반영했다”고 경고하고, 그 해 달력이 등록되면 작성일이 공휴일에 걸린 회차를 알려 준다 — 작성일을 자동으로 옮기지는 않는다(승인 때 본 날짜가 모르게 바뀌지 않게). 새로 지정된 임시공휴일은 운영자가 설정으로 더한다.
• 계약 만료일(valid_until)은 필수이고(한 스케줄은 최대 36개월), 만료일 이후 작성일의 회차는 만들지도 발행하지도 않는다. 자동 연장은 없다 — 만료가 다가오면 갱신 확인 알림이 뜨고, 사람이 갱신을 승인해야 다음 기간이 이어진다. 갱신하지 않으면 만료일 다음 실행에서 스케줄이 종료된다.
• 첫 회차는 기본으로 작성일이 오늘 이후인 달부터다. 이미 지난 달은 홈택스에서 직접 발행했을 수 있으므로 시작 달(start_period)을 명시해야만 포함한다.
• 이중 발행을 막는다. 회차(스케줄 × 작성월)마다 한 번만 발행하고, 같은 거래처·같은 작성월의 매출 계산서가 이미 장부에 있으면(홈택스에서 직접 발행한 경우 등) 발행하지 않고 확인을 요청한다. 결과가 확정되지 않은 회차는 재발행하지 않고 재확인만 한다.
• 같은 거래처(같은 사업자번호)에 기간이 겹치는 스케줄은 만들 수 없다 — 정말 별개 용역이면 겹치는 스케줄을 별개로 선언해야 하고, 그 선언도 승인 대상이다. 다른 스케줄이 이미 발행한 같은 달 계산서도 중복 후보로 본다.
• 다른 스케줄(종료한 스케줄 포함)이 같은 거래처·같은 달을 이미 발행했거나 발행 중(국세청 승인 대기 등)이면, 그 달을 덮는 새 스케줄의 생성·갱신·승인을 거부하고 발행 직전에도 다시 확인해 발행하지 않는다. 종료한 스케줄이라도 이미 보낸 계산서는 결과가 확정되면 발행되기 때문이다 — 발행 중인 달은 별개 용역 선언으로도 풀리지 않는다.
• 스케줄 밖에서 직접 발행한 계산서와도 서로 막는다. 같은 거래처·같은 달을 직접 발행했는데 아직 국세청 승인 전이면 그 달을 덮는 스케줄을 만들거나 승인하지 않고 그 회차도 발행하지 않는다(재확인으로 확정한 뒤 판단). 반대로 스케줄 회차가 이미 발행됐거나 발행 중인 달을 직접 발행하려 하면 거부한다 — 별개 공급(추가 1회성 청구 등)임을 확인했을 때만 확인 표시와 함께 발행되고, 그 확인은 기록에 남는다.
• 이자처럼 세금계산서 대상이 아닌 거래는 스케줄로 만들 수 없다. 공급시기 전 발행(선발행)은 계속적 용역에만 옵션으로 허용하고, 선발행한 계산서의 작성일자는 발행일이다(미래 날짜로 발행하지 않는다).
• 일시정지했다가 재개하면, 정지 중 발행 시점이 지난 회차는 자동 발행하지 않고 승인을 기다린다(용역을 공급하지 않은 달은 발행하면 안 된다). 단 발행 시점이 재개 뒤인 회차는 정지가 그 달 일부에 걸쳤어도 보류하지 않는다 — 자동 승인 스케줄이면 원래 금액 그대로 발행되니, 일할 청구가 필요하면 발행 전에 그 회차 금액을 조정하거나 건너뛴다(재개 결과가 그 회차를 알려 준다).
• 스케줄을 종료한 뒤에 남은 미발행 회차(종료 순간 발행이 멈춰 있던 회차 등)도 실행기가 취소하고, 작성일이 지났으면 직접 발행 여부를 확인하라는 알림을 남긴다 — 공급한 달이 조용히 미발행으로 남지 않게.
• 알림(승인 대기·발급 기한 임박·실패·만료 임박·실행기 오류)은 미결(list_open_items)로 남는다. 한 스케줄이 연속으로 실패하거나, 실패를 기록하는 것조차 실패하면 실행기 상태도 비정상으로 보고된다.
• 무중단 배포(두 슬롯 동시 운영) 중에는 트래픽을 받는 슬롯의 실행기만 발행한다 — 이전 슬롯의 실행기는 대기한다(수정 배포 뒤 옛 코드가 발행을 계속하지 않게). 대기 중인 실행기는 발행할 일이 있는데 어느 슬롯도 제때(기본 90분 안에) 실행하지 않으면 비정상으로 보고하고 미결 알림을 남긴다 — 두 슬롯 모두 대기하는 설정 오류가 조용히 미발행으로 남지 않게.

기재 — 고정자산·급여·정기분개

기재 — 거래처·계좌

결산

폐지 계정 잔액은 결산 전에 재분류한다 — 마감·이월 분개에는 폐지 계정 전기 예외가 없다. 폐지(기재불가) 표시는 신규 전기를 막으려는 것이라, 잔액을 0 으로 만드는 마감 라인이나 새 기로 넘기는 이월 라인도 예외로 두지 않는다. 대신 막히는 이유를 미리보기에서 지목한다. closing_preview 는 잔액이 남은 폐지 손익계정이 있으면 ACCOUNT_NOT_POSTABLE 로 거부하고, 메시지(폐지 계정 <코드> <계정명> 잔액 <금액> — 재분류 후 마감)와 context.retired_balances 에 해당 계정을 모두 열거한다. closing_commit 은 전기 전에 같은 미리보기를 다시 돌리므로 같은 이유로 거부하고 아무것도 전기하지 않는다. 재무상태표 계정은 마감 분개가 닿지 않으므로 마감을 막지 않는다. opening_from_closing 은 이월 분개가 계정을 찾을 날짜(새 기간 시작일)를 지배하는 정책 era 로 폐지 여부를 판정해, 잔액이 남은 폐지 재무상태표 계정이 있으면 미리보기(dry-run)는 정상 미리보기에 blocked: true 와 blocked_reason(같은 메시지·잔액표·조치)을 얹어 보고하고, force_post 는 같은 메시지로 거부하며 아무것도 전기하지 않는다 — 전기 단계의 일반 거부나 분개 불평형으로 원인이 가려지지 않는다. 조치는 하나다: 각 폐지 계정의 잔액을 사용 중인 통합 계정으로 옮기는 재분류 분개를 먼저 게시하고 다시 마감·이월한다. 재분류 분개의 폐지 계정 쪽 라인은 update_account(is_postable=true) 로 잠깐 되살려 게시한 뒤 곧바로 다시 폐지한다(감사 로그에 남는다).

전기는 법인 단위로 직렬화된다 (아래 셋, frame 다음 ship · 2026-09). 원장에 전표를 세우는 트랜잭션은 — MCP 쓰기 경로만이 아니라 고정자산·세금계산서·펀드·스냅샷·적재 분류처럼 원장에 직접 쓰는 경로까지 — 전부 그 법인의 전기 잠금을 첫 문장으로 잡고 커밋까지 쥔다. 그래서 원장을 다시 읽어 내린 판정이 판정과 기재 사이에 무효가 되지 않는다. 마감 확정이 그 잠금 안으로 들어온 것이 이 축의 본론이다: closing_commit 은 잠금을 잡은 뒤 같은 트랜잭션 안에서 기간을 확인하고, 마감 라인을 다시 계산하고, 순이익을 대조하고, 전기하고, 기간을 소프트클로즈한다. 재계산이 트랜잭션 밖이던 동안에는 그 사이 커밋된 손익 전표 하나가 낡은 라인으로 마감되고 그 잔액이 마감되지 않은 채 닫힌 기간에 남았다 — 되돌리려면 전기된 마감을 역분개하고 기간을 다시 열어야 한다. 미리보기 뒤에 손익 전표가 커밋됐으면 마감은 조용히 새 잔액까지 닫지 않고 순이익 불일치로 거부한다. 전기되는 것은 호출자가 되돌려준 preview_spec 이 아니라 서버가 잠금 안에서 다시 계산한 그 분개이고, 넘어온 preview_spec 의 라인이 그것과 다르면 MATERIALITY_VIOLATION 으로 거부한다 — 미리보기는 제안이고 잠금 안 재계산이 정본이라, 한 분개를 승인했는데 성공 코드와 함께 다른 분개가 전기되는 쪽이 거부보다 나쁘다. 비교는 금액을 정규화하고 라인을 정렬해서 보므로, 미리보기를 JSON 으로 왕복시키거나 순서를 바꿔 넘겨도 걸리지 않는다.

마감된 기간의 판정은 잠금 안에서 한 번, 원장 옆에서 또 한 번. 사전 게이트는 잠금을 잡기 전에 나온 통과권이라, 그것을 쥐고 잠금 앞에 선 평범한 전표는 앞선 마감이 그 사이 기간을 닫고 커밋해도 자기 통과권만 보고 기재한다. 그래서 잠금 안 기간 재확인을 posted 로 서는 모든 전표로 넓혔다 — 예전에는 마감 전표에만, 그것도 호출자가 채워 넣는 문자열을 기준으로 걸려 있었다. 그리고 같은 판정을 DB 트리거가 원장 옆에서 한 번 더 한다: journal 에 posted 행이 들어오거나 다른 상태이던 행이 posted 로 바뀔 때 entry_date 를 덮는 기간이 hard_closed 면 언제나, soft_closed 면 트랜잭션 로컬 설정 frame.allow_soft_closed 가 켜져 있지 않으면 거부다 — 닫힌 기간에 draft 로 넣어 두고 나중에 posted 로 뒤집는 우회도 같은 판정을 받는다. 판정의 근거인 기간 행은 그 쓰기가 커밋할 때까지 붙들려 있어, 판정과 기간 마감이 엇갈리지 않는다. 게이트를 호출 지점마다 복제하면 새 경로가 하나 생길 때 조용히 빠지므로(실제로 그렇게 빠져 있었다) 판정을 원장 옆에 못박았다 — 파이썬 층을 지나지 않는 직접 기재도, 다른 언어로 쓰인 자동분개도 같은 답을 받는다. 그 설정은 post_journal·reverse_journal 이 받는 명시적 인자 allow_soft_closed 가 켠다 — 이미 소프트클로즈된 기간에 전표를 세워야 하는 두 쓰기 도구다. 마감 자체는 그 인자를 쓰지 않는다: closing_commit 은 아직 열린 기간에 전기하고, 소프트클로즈는 같은 트랜잭션에서 그 뒤에 한다. 설정은 트랜잭션 로컬이라 커밋·롤백에서 저절로 풀린다. entry_date 를 덮는 기간이 아예 없으면 통과시킨다 — 첫 회계기간 이전의 과거 이관이 그 자리다.

닫힌 기간에서는 역분개 계보도 같은 문을 지난다. 수동으로 만든 반대 분개를 원본과 사후 연결하는 relink_reversal 과 링크만 채우는 백필은 원본의 상태와 역분개 링크를 고치므로, 원본의 기간이 닫혀 있으면 거부된다 — 두 함수 다 allow_soft_closed 를 켜지 않으므로 소프트클로즈도 예외가 아니고, 소프트클로즈든 하드클로즈든 close_period 재개방 전이(close 스코프)로 기간을 먼저 열어야 한다. 숫자는 한 푼도 움직이지 않지만 list_journals(status='reversed') 와 총계정원장의 역분개 숨김, 역분개 쌍 무결성 검사가 정확히 그 두 열을 읽는다 — 닫힌 해의 그림이 재개방 흔적 없이 바뀌는 것을 막는 것이 이 판정이다. 링크만 채우는 백필은 예전에 이 판정에서 면제돼 닫힌 해에도 돌았고, 그 면제는 날 SQL 이 하드클로즈된 해의 계보를 아무 잠금 없이 옮기는 길이기도 해서 함께 없어졌다.

역분개 계보는 원장이 직접 지킨다. reversed 로 표시된 전표는 자기를 되감은 상대 전표를 반드시 가리켜야 하고, 링크 없는 reversed·자기 자신을 가리키는 링크·존재하지 않는 전표를 가리키는 링크는 어떤 쓰기 경로로도 원장에 들어가지 못한다. 링크된 상대 전표만 따로 지울 수도 없다. 예전에는 이 규칙을 쓰기 도구만 지켜서, 도구를 우회한 쓰기가 깨진 계보를 남겼고 정합성 검사가 사후에 찾아야 했다. 규칙 도입 이전에 남은 손상 행은 고치지 않고 그대로 둔다 — 새로 들어오거나 바뀌는 행에만 적용되고, 정합성 검사가 그 행들을 계속 보고한다.

이월의 폐지 판정은 도착 기간의 정책 era 에서 읽는다. 한 계정코드가 여러 회계정책 era 에 걸치면 era 마다 계정 행이 따로 있고 계정 수정은 한 era 만 바꾼다. 잔액을 era 행 단위로 묶던 동안에는 두 방향으로 어긋났다 — 옛 era 는 살아있고 도착 era 가 폐지면 게이트가 아무것도 못 본 채 이월이 전기에서 깨졌고, 반대면 이미 지나간 era 의 폐지 표시가 멀쩡한 이월을 막아 지나간 era 의 계정을 되살려야 풀렸다. 이제 잔액은 계정코드로 합치고 폐지 여부·계정명·유형은 새 기간 시작일을 지배하는 era — 이월 분개가 실제로 계정을 찾을 그 행 — 에서 읽는다(지배 era 판정은 전기와 같은 규칙이다). 도착 era 에 그 코드가 아예 없으면 전기 불가로 보고, 도중에 깨지느니 무엇을 재분류해야 하는지 알려 주며 막는다.

관리

공개 API — 스키마 목록

Frame 이 생산하는 사실(fact)의 타입 규격을 그대로 노출한다. 다른 서비스나 에이전트가 이 규격을 가져다 캐시·검증에 쓴다.

curl -H "Authorization: Bearer $TOKEN" \
  https://frame.axelabs.ai/frame/schemas

응답 봉투는 안정 형식이다.

{
  "version": "1.0",
  "service": "frame",
  "schemas": {
    "[email protected]": {
      "description": "단일 계정의 시점 잔액 (차변/대변 합계 + 순 잔액).",
      "produced_by": ["query_balance"],
      "key_fields": ["entity_id", "account_code", "as_of_date", "debit", "credit", "balance", "policy_id"]
    }
  }
}

현재 13종을 노출한다 — 잔액 · 시산표 · 분개 · 분개목록 · 원천거래 · 미결 · 결의서 · 고정자산 장부가액 · 손익계산서 · 재무상태표 · 현금흐름표 · 자본변동표 · 총계정원장.

• 인증 필요 — MCP 클라이언트와 동일한 토큰을 그대로 쓴다.
• 버전 — 스키마 ID 의 @1.0 접미사가 개별 스키마의 호환성을, 봉투의 version 이 응답 모양 자체의 변경을 나타낸다.

시작하기

1. 법인 등록 — 등록 시점에 KSME 표준 계정과목이 자동으로 복사된다. 별도 시딩 작업이 없다.
2. 원천 데이터 적재 — 은행·카드 거래내역 파일을 올린다. 포맷은 자동 인식된다. 처음 보는 포맷이면 몇 가지를 되묻고, 그 답을 캐시해 다음부터는 묻지 않는다.
3. 기초 잔액 등록 — 외부 회계법인 검수본 기준 시산표를 개시 분개로 기재한다.
4. 분개 — 자동 매칭이 붙는 건은 제안을 확인하고 커밋하고, 나머지는 직접 기재한다. 진척은 시산표로 매일 확인한다.
5. 마감 — 기간을 가마감 → 확정으로 전이시키고, 다음 기 기초로 이월한다.

관련 문서

• Blueprint — Frame 을 도구로 호출하는 워크스페이스
• UI (디자인 시스템)