산업 UI빠른 반복리서치급Made in KoreaIndustrial UIFast iterationResearch-gradeMade in Korea

Heritage Labs도면 QA · 보안 운영 · LLM 네이티브 워크플로우를 위한 산업용 툴.Industrial-grade tools for geometry QA, secure operations, and LLM-native workflows.

우리는 “멋있게 자동수정”보다, 검증 가능한 워크플로우를 먼저 만듭니다. QA, 보안, LLM 네이티브 운영 — 전부 현업에서 안 터지게.We prefer verifiable workflows over flashy auto-fixes. Geometry QA, secure ops, and LLM-native operations — built to survive production.

혼돈은 줄이고, 신호는 늘리고. (재미는 유지)Less chaos. More signal. (Still fun.)
신호 로그Signal log
[SYS] Focus: 도면 QA • 보안 운영 • LLM 네이티브 워크플로우
[OK ] 슬라이드보다 툴. 분위기보다 근거.
[WARN] 데드라인은 현실. 현실을 위해 설계.
[NOTE] 우측 레일 UI = 생산성 모드.
[SYS] Focus: geometry QA • secure ops • LLM-native workflows
[OK ] Tooling over slides. Evidence over vibes.
[WARN] Deadlines are real. Build for reality.
[NOTE] Right-rail UI = productivity mode.

우리가 하는 일What we do

Heritage Labs는 검증 가능한 도구로 QA·보안·운영을 정리합니다. “자동으로 고쳐준다”보다, 먼저 틀린 지점을 정확히 보여주는 쪽.Heritage Labs ships verifiable tools for QA, security, and operations. Before "auto-fix", we first pinpoint what's wrong.

CAP-01
CAD QC
도면/지오메트리 QAGeometry QA

도면/모델에서 ‘오류 좌표’를 뽑아내고, 수정→재검증 루프를 자동화합니다.Extract error coordinates from drawings/models and automate the fix → re-check loop.

  • 이슈 탐지(면적/폐곡선/레이어/블록 등)
  • 카메라 점프 기반 수정 UX (자동수정은 옵션)
  • 리포트/로그 산출(CSV/JSON)로 검증 가능
  • Issue detection (area / closed loops / layers / blocks)
  • Camera-jump fix UX (auto-fix is optional)
  • Verifiable reports/logs (CSV/JSON)
CAP-02
Policy
보안 운영Secure Ops

저장 경로·권한·출력을 ‘정책’으로 묶어서, 유출/분실 리스크를 낮춥니다.Wrap save paths, permissions, and exports into policy to reduce leakage and loss.

  • SAVE/SAVEAS 경로 강제(allowlist)
  • Fail-closed 기본값 + 예외는 기록
  • 감사로그(JSONL)로 사후 추적 가능
  • Enforce SAVE/SAVEAS paths (allowlist)
  • Fail-closed by default + exceptions logged
  • Audit logs (JSONL) for traceability
CAP-03
Ops UX
LLM 네이티브LLM-native

LLM은 ‘대변인 UI’, 결정은 룰 엔진. 운영을 문장으로 다루되 흔들리지 않게.LLM as a spokesperson UI; outcomes decided by a rule engine — reproducible and stable.

  • 자연어 입력 + 톤 선택(설명/기술/강경 등)
  • 결과는 결정론적 룰로 재현 가능
  • 로그 기반으로 학습·개선 가능한 운영
  • Natural language input + tone selection
  • Deterministic rules for reproducible outcomes
  • Log-driven improvement loop
빠른 체크Quick filter
이럴 때 도움 됩니다You probably need us if
도면 검토/물량/면적 오류로 야근이 반복된다.You keep losing nights to drawing QA / quantity / area mistakes.
Or if
파일이 로컬에 흩어지고 NAS 권한이 꼬여 사고가 난다.Files scatter across local PCs and NAS permissions get messy.
Or if
운영이 문서/대화로 폭증해서, 룰과 로그가 필요하다.Ops explode into docs/chats — you need rules and logs.

일하는 방식How we work

슬라이드로 설득하기보다, 샘플 파일명확한 출력으로 PoC를 합니다. 도입은 조용하게, 결과는 로그로 남기게.Instead of slide decks, we run PoCs with real sample files and clear outputs. Quiet rollout. Loud logs.

01
정의Define

문제를 문장으로 정리하고, 성공 조건을 ‘출력 형태’로 고정합니다.Write the problem down and lock success criteria as concrete outputs.

  • 샘플 파일(가능하면 1~3개)
  • 기대 출력(리포트/좌표/룰)
  • 운영 환경(Office/Rhino/NAS)
  • Sample files (ideally 1–3)
  • Expected outputs (report/coords/rules)
  • Environment (Office/Rhino/NAS)
02
파일럿Pilot

작게 붙여서 검증합니다. 실패 케이스부터 잡고, 재현성을 확보합니다.Validate with a small pilot. Start with failure cases and make it reproducible.

  • 룰/정책 초안 구성
  • 로그/리포트 형식 확정
  • 수정→재검증 루프
  • Draft rules/policy
  • Freeze log/report formats
  • Fix → re-check loop
03
하드닝Harden

현업에서 안 터지게 만들고, 예외를 통제합니다.Make it production-safe and control exceptions.

  • Fail-closed 기본값
  • 권한/경로/무결성 체크
  • 배포/업데이트 전략
  • Fail-closed defaults
  • Permissions/path/integrity checks
  • Deploy/update strategy
04
배포Deploy

운영자가 ‘이해 가능한’ 형태로 넘깁니다. 문서보다 실행 가능한 패키지.Hand it off in an operator-friendly way — runnable packages over docs.

  • 설치/운영 가이드
  • 감사 로그 저장 경로
  • 롤백/복구 가이드
  • Install/ops guide
  • Audit-log storage path
  • Rollback/recovery playbook
산출물(일반)Deliverables (typical)
룰 / 정책Rule / Policy
  • • CSV/Config 기반 룰/정책
  • • 허용 경로/권한/예외 정의
  • • 재현 가능한 버전 관리
  • • CSV/config-driven rules & policy
  • • Allowlist paths/permissions/exceptions
  • • Reproducible versioning
리포트 / 로그Report / Log
  • • 이슈 좌표/근거 리포트
  • • 감사 로그(JSONL/CSV)
  • • 재검증 결과 요약
  • • Issue coordinates + evidence report
  • • Audit logs (JSONL/CSV)
  • • Re-check summary
패키지Package
  • • 설치 파일/zip + 체크리스트
  • • 운영 가이드(1~2p)
  • • 롤백/복구 시나리오
  • • Installable ZIP + checklist
  • • Ops guide (1–2 pages)
  • • Rollback/recovery scenarios

제품Products

작은 팀이지만, 현업에서 “그냥 돈 되는” 문제만 잡습니다.Small team, but we only chase problems that pay in production.

PRD-01
Geometry QC
Topo-Snap

Rhino 도면 QA 자동화: 이슈 탐지 + 카메라 점프로 빠른 수정 루프.Rhino drawing QA automation: detect issues and jump the camera for a fast fix loop.

  • Audit Panel
  • Go/Next 카메라 점프
  • 레이어 / 면적 / 블록 체크
  • Audit Panel
  • Go/Next camera jump
  • Layer / area / block checks
PRD-02
LLM Game
I Was a King

LLM 기반 CLI 서사 전략 — 결정은 룰 엔진, 연출은 LLM.LLM-oriented CLI narrative strategy — rules first, drama second.

  • 타이핑 기반 CLI
  • 룰 엔진 + LLM
  • Steam 출시 파이프라인
  • Typing-based CLI
  • Rule engine + LLM
  • Steam-ready pipeline
PRD-03
Security Ops
Office Gatekeeper

Office 파일 저장 경로 강제 + 무결성 검증으로 정보유출 리스크를 줄입니다.Enforce Office save paths and integrity checks to reduce leakage and loss risk.

  • Fail-closed
  • NAS allowlist
  • HMAC 무결성
  • Fail-closed
  • NAS allowlist
  • HMAC integrity
PRD-04
Infra Ops
Heritage NAS

Linux NAS 구축 + SMB/권한 정리 + 백업/동기화로 저장소를 표준화합니다.Linux NAS setup + SMB permissions baseline + backup/sync discipline for a standardized storage layer.

  • Linux-first NAS
  • SMB ACL 베이스라인
  • Syncthing / 오프사이트 DR
  • Linux-first NAS
  • SMB ACL baseline
  • Syncthing / offsite DR
Note

“밈”은 분위기용이고, 실제 설계는 fail-safe가 기본값입니다.Memes are for vibes. Engineering is fail-safe by default.

스택Stack

현업에서 깨지지 않는 쪽으로 쌓습니다. 멋보다 안정, 자동보다 검증.Built for production: stability over looks, verification over automation.

STK-01
지오메트리 / CADGeometry / CAD
  • Rhino 8 + .NET (C#)
  • Topology-aware 체크
  • 룰 매핑(CSV/Config)
  • Rhino 8 + .NET (C#)
  • Topology-aware checks
  • Rule mapping (CSV/Config)
STK-02
시스템Systems
  • Windows 툴링 + 정책 강제
  • Fail-closed 설계
  • 감사 로그 & 무결성
  • Windows tooling + policy enforcement
  • Fail-closed design
  • Audit logs & integrity
STK-03
AI / LLMAI / LLM
  • LLM은 UI, 권위 아님
  • 결정은 룰 엔진
  • 운영 프롬프팅
  • LLM as UI, not authority
  • Rule engine decides outcomes
  • Prompting for ops
STK-04
인프라Infra
  • Linux-first 운영
  • Syncthing / 백업 규율
  • 작고 단단한 배포
  • Linux-first ops
  • Syncthing / backup discipline
  • Small, reliable deployment
Principle

자동수정은 마지막 단계. 먼저 재현 가능한 규칙 감사 로그부터 확보합니다.Auto-fix comes last. First we secure reproducible rules and audit logs.

ABOUT

작은 팀. 날카로운 툴.Small team. Sharp tools.

Heritage Labs는 “현업에서 반복적으로 피곤한 문제”를 소프트웨어로 정리합니다. 제품은 과장하지 않고, 도입은 안전하게, 결과는 로그로 남깁니다.Heritage Labs turns recurring production pain into software. No hype, safe rollout, and outcomes proven with logs.

원칙Principle

분위기보다 근거. 기본값은 fail-safe.Evidence over vibes. Fail-safe by default.

속도Speed

1일 개념→초안 루프. 빨리 내고, 더 빨리 고칩니다.1-day concept-to-draft loop. Ship fast, fix faster.

디자인Design

Industrial UI: 장식은 줄이고, 신호는 늘립니다.Industrial UI: less decoration, more signal.

(밈) “우린 과장 안 합니다. 로그 합니다.”(meme) “We don’t do hype. We do logs.”

자주 묻는 질문FAQ

짧게만 답합니다. 나머지는 로그로.Short answers. The rest goes into logs.

컨설팅인가요, 제품인가요?Is this consulting or product?
제품 중심입니다. PoC도 실제 파일로 돌리고, 결과는 도구/룰/로그로 남깁니다. (슬라이드는 최소화)Product-first. PoCs run on real files, and results ship as tools/rules/logs. (Slides kept minimal.)
시작하려면 뭐가 필요하죠?What do you need to start?
샘플 파일(가능하면 1~3개), 기대 출력(리포트/좌표/정책), 운영 환경(Office/Rhino/NAS)만 있으면 됩니다.Sample files (ideally 1–3), expected outputs (report/coords/policy), and your environment (Office/Rhino/NAS).
사내망/오프라인도 되나요?Can it run on-prem / offline?
기본 방향은 작고 단단한 로컬/사내망 운영입니다. 데이터는 최소 수집, 예외는 기록.Yes — we prefer small, hardened on-prem setups. Minimal data collection; exceptions are logged.
보안은 어떻게 처리하나요?How do you handle security?
Fail-closed(막는 게 기본) + Allowlist(허용된 것만) + Audit log(남기는 것) 3세트로 갑니다.Three-pack: Fail-closed by default + Allowlist only + Audit logs for proof.
가격은 어떻게 책정되나요?How does pricing work?
보통은 작은 PoC로 시작하고, 이후 운영 범위(사용자 수/파일량/보안 요구)에 맞춰 단계화합니다.Usually a small PoC first, then tiered by scope (users, volume, security requirements).
첫 메일에 뭘 보내면 되죠?What should I send in the first email?
“무엇이 문제인지(1문장) / 어떤 파일인지 / 실패 사례 / 기대 결과(출력 형태)”만 적어주면, 바로 PoC 루프로 들어갑니다.Just send: the problem (1 sentence) / file type / a failure case / expected output format. We can start the PoC loop immediately.
TL;DR

우리가 하는 일은 간단합니다: 틀린 지점을 정확히 찾고, 안 터지게 운영하고, 로그로 증명합니다.We do three things: find what's wrong, run it safely, and prove it with logs.

문의Contact

PoC / 파일 샘플 / 협업 제안 — 간단히 보내주세요. (대신 로그로 답합니다.)PoC, sample files, partnerships — send a short note. (We reply with logs.)

(밈) 중요한 건 문서로 남깁니다 :)(meme) If it’s important, put it in writing. :)
메모Notes
  • • 샘플 파일이 있으면 PoC가 빨라집니다.
  • • 기대 결과(리포트/좌표/룰)를 명확히 적어주세요.
  • • SMTP 설정이 없으면 서버 로그로만 기록됩니다.
  • • Sample files speed up the PoC.
  • • Be explicit about expected outputs (report/coords/rules).
  • • Without SMTP, requests may be logged server-side only.
© 2026 Heritage Labs|개인정보 처리방침Privacy