HOW IT WORKS / VERIFIED EDITION

ERP의 구조를 읽고,
업무 정의와 실행 가능한 조회로 연결합니다.

실제 코드를 따라 다시 그린 VESTA입니다. 분석 결과를 Forma로 정리하는 경로와, Cody가 분석 지도를 읽어 사용자 기능을 만드는 경로가 구현되어 있습니다. 두 경로 사이의 직접 연결은 별도로 확인해야 합니다.

검증 기준 2026-09-13 · 로컬 작업본코드 추적 + 로컬 자동검증내부 비교·검토용기존 설명본 열기 ↗

실제로 확인한 전체 흐름

실선 → 코드 연결 확인 · 점선 = 연결 미입증
실선은 운영 환경에서의 연속 시연 성공을 뜻하지 않습니다.

분석 대상

기존 ERP·업무 앱

소스코드 · DB 구조
화면·메뉴 · 설정 데이터
접근 가능한 자료만 분석

cody-platform / grounding

대상별 분석 도구

소스 분석과 DB 분석을 분리합니다. 객체·관계·출처·미확인 항목을 기록합니다.

scan_source.py / scan_db.py

공통 중간 산출물

분석 스냅샷

노드·관계와 분석 회차의 측정 기록. 여기서 두 출력 경로로 갈라집니다.

nodes.jsonl · edges.jsonl · receipt.json

분석 스냅샷 ↓ 업무 정의로 변환

Forma

개념·조회·능력·규칙·절차의 후보와 실제 시스템의 대응 정보를 만듭니다. 입력에 필요한 근거가 있어야 해당 후보가 나옵니다.

forma.py → bundle.json + bindings.json → 형식·참조 검증

분석 스냅샷 ↓ 검색용 그래프로 적재

Cody

Neo4j의 Grounding 지도에서 테이블·컬럼·관계를 찾고, 제한된 조회 선언문을 검사·시험하여 사용자 기능으로 저장합니다.

project_neo4j.py → 지도 탐색 → 조회 기능 → 리포트·대시보드

Forma ⇢ Cody 직접 소비 경로는 이번 검증에서 확인되지 않았습니다. 현재 확인한 Cody 지도 탐색은 Forma JSON이 아닌 Neo4j Grounding을 읽습니다. 제품의 지향 구조와 현재 구현 경로를 구분해 표시했습니다.

Refactoring Engine의 구현 위치: 별도 refact_root에는 소스 그래프·데이터 모델·요구사항 카드 분석 체계가 있습니다. 위 Forma 출력 도구는 cody-platform/build/grounding에 있으며, 두 분석 체계의 자동 인계는 입증하지 않았습니다.

INSIDE / ANALYSIS

Refactoring Engine

무엇을 읽고, 무엇을 근거로 남기는가

제품 이름 아래의 실제 구현은 두 저장소에 나뉘어 있습니다. 기존 엔진의 요구사항 추출과, 현재 Forma 출력을 담당하는 분석 도구를 함께 보되 하나의 자동 실행 경로로 합치지 않습니다.

입력소스 파일 · DDL 또는 접근 가능한 DB 메타데이터 · 분석 범위 설정

소스 관계 추출

Java·MyBatis·JSP·프론트엔드·DDL을 읽는 추출 함수를 통해 코드 객체와 관계를 모읍니다. 코드 전체의 업무 의미를 완전히 이해했다는 보장은 아닙니다.

refact_root/scripts/build_graph.py → cmd_extract()

데이터 모델 분석

테이블·컬럼·선언된 외래키를 수집하고 관계 추론 및 ERD 생성을 별도 단계로 수행합니다. 추론 관계는 선언된 관계와 구분해서 해석해야 합니다.

build_datamodel.py → declared_fks() / infer_fks()

요구사항 카드 구성

코드 근거와 모델 분석을 묶어 요구사항 카드를 만들고, 카드 형식·근거·추적 관계를 검사합니다. 구조 검증 통과와 업무 의미의 정확성 확인은 별개입니다.

deep_extract.py / req-cli.py

Forma를 위한 분석

cody-platform의 대상별 분석 도구가 공통 스냅샷을 생성합니다. Forma 변환은 이 스냅샷을 입력으로 받습니다.

connectors/*/grounding → build/grounding/forma.py

출력엔진: 그래프·목록·데이터 사전·요구사항 카드 / grounding: 공통 스냅샷

소스 경로 확인

파일이 실제로 존재하는 분석 체계

refact_root 산출물
graph/nodes.jsonl
graph/edges.jsonl
inventory.json
data-dictionary.json
요구사항 카드

grounding 산출물
nodes.jsonl
edges.jsonl
receipt.json

두 체계에서 파일 이름이 비슷하다고 자동 호환된다고 판단할 수는 없습니다. refact_root → Forma 변환 연결은 이번에 확인하지 못했습니다.

코드 근거 펼치기

refact_root/scripts/build_graph.py:496–574 — 추출과 파일 기록
refact_root/scripts/build_datamodel.py — DB 구조와 관계·ERD
refact_root/scripts/deep_extract.py — 근거 구성·모델 분석
cody-platform/connectors/glos/grounding/scan_source.py:316–585 — 스냅샷·회차 기록

INSIDE / BUSINESS DEFINITION

Forma

업무의 뜻과 실제 시스템의 위치를 나눠 담습니다.

Forma 0.17.0은 업무 정의 형식, 검증 코드, 표현식 평가기를 가진 패키지입니다. 분석 결과가 들어오면 근거가 있는 내용을 후보로 옮깁니다. 단독 ERP 접속 서버나 에이전트 실행기는 아닙니다.

입력테이블·조회·라우트·규칙·설정 행의 분석 사실 및 출처

업무 정의 묶음

Concept는 업무 개념, Query는 조회, Capability는 제공 기능, Rule은 규칙, Procedure는 절차를 표현합니다. 모든 종류가 항상 자동 추출되는 것은 아닙니다.

src/bundle.ts → FormaBundle

실제 시스템 대응

별도 문서에 시스템과 테이블·컬럼 등의 연결 정보를 담습니다. 업무 정의의 이름과 실제 저장 위치를 분리해 관리합니다.

src/binding.ts / src/system.ts → FormaBindings

후보 생성과 근거

변환기가 state=proposed로 후보를 냅니다. 규칙은 분석된 조건·권한·상태 자료에서, 절차는 단계 템플릿 표에서 만듭니다. 확인하지 못한 값과 건너뛴 항목을 남깁니다.

forma.py → envelope() / build() / project_rows()

검증과 표현식 평가

스키마·참조·누락을 검사하고, 표현식은 주어진 입력 값으로 평가합니다. 검사 통과만으로 고객 업무 정의의 정답이나 ERP 실행 성공이 입증되지는 않습니다.

lint/index.ts / src/eval.ts → evaluate() / holds()

출력bundle.json · bindings.json · 변환·검증 보고서

변환 자체검사·예제 실행 통과

자동 추출의 경계를 코드가 구분합니다.

공통 후보 표식 · 코드 발췌
state: "proposed"
provenance:
  source: "derived"
  origin: 원본 근거
  authority: 근거의 성격

업무 정의 → bundle.json
시스템 대응 → bindings.json

라우트 자료가 없으면 능력 후보를, 규칙 자료가 없으면 해당 규칙 후보를 만들지 않습니다. 절차의 순서를 화면·메뉴의 나열로 지어내지 않습니다.

위 표식은 코드 구조 설명입니다. 특정 고객 ERP에서 생성한 결과 화면은 아닙니다.

코드 근거 펼치기

cody-platform/build/grounding/forma.py:344–355 — proposed·출처 표식
같은 파일:2604–2771 — 입력별 후보 생성·두 문서 구성
같은 파일:3518–3522 — 조회·능력·규칙·설정 행 입력 옵션
forma/src/bundle.ts · binding.ts · envelope.ts · eval.ts
검증 로그: verification-v2/forma-*.log

INSIDE / USER-CREATED FUNCTION

Cody

분석 지도를 바탕으로, 검사 가능한 조회 기능을 만듭니다.

이번에 끝까지 추적한 범위는 사용자 조회 기능 → 리포트 → 대시보드입니다. 이 경로를 모든 종류의 에이전트 생성이나 모든 ERP의 쓰기 자동화로 확대해서 설명하지 않습니다.

입력사용자 요청 · 현재 화면·사용자 맥락 · Neo4j 분석 지도 · 연결 대상

지도에서 재료 찾기

테이블·컬럼·설명·관계를 검색합니다. 테이블 구조를 알려주는 지도이며 현재 업무 데이터 값은 실행 경로에서 조회합니다.

DataMapExplorer.search() / describe() → Neo4j Grounding

조회 선언문 검사

v1 선언문에 대상·테이블·열·조건·조인·집계를 표현합니다. 파서로 문법을 검사하고 지도와 대조해 없는 테이블·컬럼이나 맞지 않는 조인을 걸러냅니다.

DeclarationSchema → DeclarationTrialService.validate()

표본 시험과 저장

표본·소급 시험 도구가 있고 저장 시 확인·시험 여부를 검사합니다. 개인 기능으로 저장한 뒤 현재 화면에 활성화합니다. 기존 기능의 조건을 재조합하는 갈래도 있습니다.

SkillMakingToolPack → run_sample / save_skill_overlay

연결된 시스템 조회

검사된 선언문을 대상 실행기로 보냅니다. GLOS 구현은 SQL로 변환하고 값을 바인딩해 읽기 전용 DB 연결로 조회합니다. 시간 제한과 행 상한을 둡니다.

DeclarationTrialService.execute() → glos_run_declaration → GlosDeclarationRunner

출력저장·활성화된 개인 기능 · 실행 결과 행 · 리포트 게시에 사용할 기능 참조

파서·지도 대조·SQL 검사 55건 통과

실행 가능한 범위를 좁혀 검사합니다.

자연어 요청
  ↓ 지도에서 구조 탐색
조회 선언문 v1
  ↓ 문법·테이블·컬럼·관계 대조
표본 시험과 사용자 확인
  ↓ 개인 기능 저장·활성화
대상별 실행기
  ↓ GLOS: SQL 변환·값 바인딩
읽기 전용 DB 조회

현재 검색 범위에서 *_run_declaration 구현은 GLOS에서 확인됐습니다. 영림원에는 별도 커넥터가 있지만 같은 동적 조회 조립기를 제공한다는 근거는 확인하지 못했습니다.

코드 근거 펼치기

DataMapExplorer.java:65,168 — Grounding 조회
DeclarationTrialService.java:73–102 — 문법·지도 대조
SkillMakingToolPack.java:365–464 — 확인·시험 검사와 저장·활성화
GlosReadService.java:325–351 — 실행기 위임
GlosDeclarationRunner.java:60–87 — SQL 생성·바인딩·조회

INSIDE / SELF-SERVICE OUTPUT

Report & Dashboard

만든 조회 기능을 반복해서 보는 업무 화면으로

리포트는 저장된 조회 기능을 참조하고, 대시보드는 리포트를 배치·연결합니다. 데이터 조회와 AI 해설 생성의 실행 시점이 다릅니다.

입력게시할 조회 기능 · 고정·변경 가능한 조건 · 제목 · 화면 배치

리포트 게시

선언문 조회 기능을 찾아 조건과 게시 정보를 저장합니다. 실행할 때 저장된 기능을 해석하고 열람자 권한 및 접근 가능 여부를 확인합니다.

ReportService.publish() / resolve()

조회 결과와 캐시

열람 조건을 합쳐 같은 조회 실행기로 보냅니다. 동일 키의 결과는 최대 120초 동안 재사용할 수 있어 매 열람마다 DB를 다시 읽는 구조는 아닙니다.

ReportService.run() → CACHE_TTL_MS = 120_000

AI 해설

해설 생성 메서드가 모델 호출을 담당합니다. 게시 경로에서 해설을 요청하며, 일반 결과 조회 경로는 모델을 호출하지 않습니다.

ReportService.writeSummary() / publish()

대시보드 구성

리포트 참조·격자 배치·공통 조건·조건 연결을 저장하고 검사합니다. 각 카드의 해석과 접근 판정은 리포트 서비스를 재사용합니다.

DashboardService → draftLayout() / validate() / ReportService

출력조건을 바꿔 재사용하는 리포트 · 여러 리포트를 묶은 대시보드

BEFORE / AFTER

기존본과 무엇이 달라졌나

기존본의 표현과 흐름을 요약해 비교했습니다. 기존 파일은 수정하지 않았습니다.

비교 항목	기존 설명본	이번 검증본
전체 연결	ERP → Refactoring Engine → Forma → Cody → 결과의 일렬 구성	분석 스냅샷에서 Forma 후보 출력과 Neo4j 지도 활용으로 분기. Forma의 Cody 직접 소비는 미입증.
엔진 구현 위치	여러 저장소의 분석 기능을 제품 내부 구성으로 통합 설명	refact_root 분석 체계와 cody-platform의 Forma 변환 도구를 구분.
Forma 자동화	데이터·규칙·기능·절차를 업무 정의로 정리	입력 근거별로 생성되는 후보와 누락을 설명. proposed 상태, 별도 바인딩, 검사 범위를 명시.
Cody 생성 범위	에이전트 기획·생성·실행을 넓게 설명	확인한 조회 선언문·검사·시험·개인 기능 저장 경로를 구체화. 범용 에이전트 생성 검증과 구분.
ERP 적용 범위	영림원·UniERP 등을 적용 환경별로 확인한다는 주석	동적 조회 실행기는 GLOS에서 확인. 영림원 동일 경로와 UniERP 연속 실행은 미검증.
리포트 최신성	실행 시 데이터를 조회하고 해설 생성 시점을 구분	120초 캐시를 반영. “항상 즉시 최신”으로 읽힐 수 있는 표현을 제한.
근거의 깊이	설계 자료·타입·주요 파일 확인	함수 연결 추적 + 실제 자동검증 + 코드 해시 및 실행 로그 보관.

EVIDENCE / REPRODUCIBLE CHECKS

이번에 직접 실행한 검증

83 / 83

Cody 관련 테스트
파서·지도·SQL·리포트·대시보드

실행 로그

63 / 63

Forma 표현식 평가
Python 적합성 벡터

실행 로그

PASS

Forma 변환 자체검사
패키지 예제·검증 실행

변환 로그 · 예제 로그

Forma 0.17.0 스키마 차이
패키지와 Cody 고정 사본 비교

비교 로그

검증의 범위: 로컬 소스 분석과 단위·예제 검증입니다. 고객 ERP 접속, 실제 Neo4j 적재, LLM을 통한 기능 생성, 동일 ERP의 분석부터 대시보드까지의 연속 실행은 이번에 수행하지 않았습니다. HTML 도식은 구현 설명이며 실행 중인 제품 화면이 아닙니다.

기존 설명본과 비교 ↗상세 검증 근거분석한 코드 버전·파일 해시

ERP의 구조를 읽고,업무 정의와 실행 가능한 조회로 연결합니다.

실제로 확인한 전체 흐름

기존 ERP·업무 앱

대상별 분석 도구

분석 스냅샷

Forma

Cody

Refactoring Engine

무엇을 읽고, 무엇을 근거로 남기는가

소스 관계 추출

데이터 모델 분석

요구사항 카드 구성

Forma를 위한 분석

Forma

업무의 뜻과 실제 시스템의 위치를 나눠 담습니다.

업무 정의 묶음

실제 시스템 대응

후보 생성과 근거

검증과 표현식 평가

Cody

분석 지도를 바탕으로, 검사 가능한 조회 기능을 만듭니다.

지도에서 재료 찾기

조회 선언문 검사

표본 시험과 저장

연결된 시스템 조회

Report & Dashboard

만든 조회 기능을 반복해서 보는 업무 화면으로

리포트 게시

조회 결과와 캐시

AI 해설

대시보드 구성

기존본과 무엇이 달라졌나

이번에 직접 실행한 검증

ERP의 구조를 읽고,
업무 정의와 실행 가능한 조회로 연결합니다.