재무 판단에는 두 종류가 있다. "이 자산화가 정말 타당한가"처럼 맥락을 읽어야 하는 판단과, "이자보상배율이 1배를 넘는가"처럼 계산하면 답이 하나로 정해지는 판단이다. 후자를 LLM에 맡기면 같은 계획서를 다시 넣어도 답이 흔들릴 수 있다. OpenSeed(오픈시드)는 답이 하나로 확정되는 지점만 골라 코드로 계산하고, 나머지는 여신·회계·세무 심사역의 판단에 맡긴다.
사업계획서를 AI로 심사할 때 흔히 생기는 오해는, LLM이 문장을 잘 읽으니 숫자 판단도 잘하리라는 것이다. 하지만 "이자보상배율이 1배 미만인가"는 독해력의 문제가 아니라 나눗셈의 문제다. 이런 질문에 LLM을 쓰면 같은 입력에도 답이 달라질 수 있고, 그 불안정성이 재무 판단 전체의 신뢰도를 갉아먹는다.
OpenSeed의 원칙은 단순하다 — 코드로 확정할 수 있는 질문은 코드로 확정하고, 그럴 수 없는 질문(자산화 요건을 실제로 충족했는가, 이 매출 구조가 사업 특성상 타당한가)만 LLM과 사람의 판단에 남긴다. 이 원칙 아래 여신·회계·세무 세 영역에서 코드로 확정 가능한 규칙들을 운영한다.
여신(은행) 심사에서 반복되는 세 산식은 계산만으로 위험 신호를 만든다.
| 지표 | 산식 | 경고 기준 |
|---|---|---|
| DSCR(부채상환비율) | 영업활동현금흐름 ÷ 연간 원리금 상환액 | 1.0 미만 |
| 이자보상배율 | 영업이익 ÷ 이자비용 | 1배 미만 |
| 런웨이 | 보유 현금 ÷ 월 순현금유출 | 12개월 미만 |
DSCR이 1.0 미만이면 영업활동현금흐름만으로 원리금을 못 갚는다는 뜻이고, 이자보상배율이 1배 미만이면 영업이익으로 이자도 못 갚는 한계기업 징후다. 계획서에 두 수치가 라벨과 함께 명확히 적혀 있으면 계산만으로 경고를 띄울 수 있다 — 이건 해석이 아니라 산수다.
회계 쪽은 산식보다 "처리 방식이 기준을 벗어났는가"를 보는 표현 패턴 다섯 가지를 확인한다. 전부 이익을 실제보다 커 보이게 만드는 방향으로 작동하는 오류들이다.
이 다섯 가지는 계획서에 특정 표현 패턴이 실제로 등장할 때만 잡는다 — 있지도 않은 항목을 추정해서 지적하지 않는다. 다만 자산화 요건을 "실제로" 충족했는지 같은 질적 판단은 코드가 아니라 회계 전문가·LLM의 몫으로 남긴다.
세무에서 코드로 확정 가능한 지점은 좁다 — 세무는 요건 판단이 많아서 명확한 임계값이 있는 경우가 드물기 때문이다. 지금 운영 중인 규칙은 하나뿐이다: 조세특례제한법 제16조의4에 따라 적격 스톡옵션은 최근 2년 누적 행사가액이 5억원 이하일 때만 과세이연 혜택을 받는다. 계획서에 5억원을 넘는 행사가액이 적혀 있는데 과세(이연 불가·소득세·원천징수 등) 관련 인지 표현이 없으면, 세무 리스크를 놓쳤을 가능성이 있다고 본다.
R&D 세액공제율처럼 "법정 범위를 벗어났는가"를 코드로 판정하는 규칙은 의도적으로 넣지 않았다. R&D 세액공제는 사전심사 실시 여부가 필수 요건이 아닌데, 미실시 자체를 감점·가산세 사유로 단정하면 결정론 검증기가 오히려 틀린 법적 확신을 만들 위험이 있기 때문이다. 확정할 수 없는 질문은 코드로 확정하지 않는 것도 이 시스템의 원칙이다.
이 검증들은 지금 리포트에 별도 배지로 보이나요? — 아니다. 현재는 분석 과정에서 내부적으로 계산돼 여신·회계·세무 심사역의 판단을 뒷받침하는 데 쓰이고 있고, 사용자에게 개별 항목별 통과·실패로 직접 노출하는 화면은 아직 없다.
왜 세 영역 전부를 코드로 확정하지 않나요? — 코드로 확정하려면 "이 값이 저 값을 넘는가"처럼 이견이 없는 기준이 있어야 한다. 자산화 요건 충족 여부나 사업 구조의 타당성처럼 맥락 판단이 필요한 질문은 코드가 아니라 심사역의 몫으로 남긴다 — 억지로 코드화하면 오히려 틀린 확신을 만든다.
지금 내 사업계획서를 점검해 보세요
OpenSeed 심사 시작하기 — 단건 결제 30,000원.
🔒 베타 기간 무료 · 핵심 아이디어는 저장하지 않아요
OpenSeed AI 심사 시작 →