전략 작성 검증 agent는 따로따로 개발해서 붙일 수 있는것이 아니었다. 이 3 에이전트는 서로 밀접한 관련이 있으며 동시에, 함께 개발해야했다.
전략·작성·검증-1의 실행 순서, 함수별 입력·출력, 프롬프트 구성, 근거 보존, 검증·채점·재작성 흐름을 상세히 정리함. 갱신일: 2026-10-14.
처음으로 했던 작업을 기억한다. 로고를 만드는 일이었다. 우리의 마지막 추억이 되는 만큼 ai에게 맡기거나 대충 만들고 싶지않아 path로 직접 그렸었다 .
기존 로고가 brain이 2개로 시너지를 낸다면 팀은 좀더 본질적인 brain 1가 되지않을까
팀 로고도 따로 만들었다 .
사업계획서 파트를 맡았으니 사업계획서에 대한 자료 리서치를 도맡았다 . 이때 꽤 많은 시간을 투자했고 분석에 공을 들였다. 이해를 하지 못하면 개발을 결국 회귀하기 때문이다.
돌이켜보면 이때 시간을 많이쓰고 분석을 많이 한 덕분에 회귀는 단 한번도 하지않았다. 오히려 개발은 하루만에 끝이 났고, ai가 만들어내는 사업계획서를 검토하며 검증해 더 잘 만들라며 채찍질하는데 시간을 많이 들였다.
밑에서도 언급될테지만 아래는 전략/작성/검증1의 워크플로우이다 .
문서 유형 결정 (documentType / kind — 신청자 유형 기준)
→ 파이프라인 진입·Task 등록 (bootstrap.build_app / bind_partner_sw — 오케스트레이션 구현)
→ 오케스트레이터 구성 (sbrain_flow.py + catalog.py — 오케스트레이션 구현)
1. 실행 계약·입력 준비
→ 1.1 실행 계약 로드 (execution_contract.json)
├─ 함수별 입력·출력 계약과 기본 모델
├─ 실행 설정 사본·Task 모델·purposeModels
└─ FormSpec의 항목 번호·화면 제목·종류·태그
→ 1.2 입력 구성·정규화 (inputs.py)
├─ 아이디어·산출물·기술분야·사용자 목표 고객
├─ 대표·팀원 역량, 수익모델, 사업비·일정 행
└─ 일반현황 원본 사실: 창업아이템명·팀구성현황
→ 1.3 실행 제약 구성 (strategy_limits)
├─ deadline·supportLimit·featureList
└─ 협약기간 / 협약 이후 로드맵, 예비창업 1·2단계 사업비
2. 조사 자료 준비: 사이트별 수집·검색 경로
→ 2.1 기준 자료 구축·선택적 갱신
├─ KIET 시장 자료·개발지식·디자인 트렌드 자료
└─ 선택적 실행별 KIET 검색 (SBRAIN_KIET_SEARCH)
→ 2.2 파이프라인 실행 시 검색·전달
├─ F01 자료 조회·조건부 해석
└─ 시장·경쟁·개발 근거 조회와 sourceRef 연결
3. F01~F15 공통 전략 실행
→ 3.1 실행 흐름과 함수 목록
├─ T-S1: F01 → F02 → F05~F09 → F13~F15
├─ T-S2: F03 → F04 → F10~F12
└─ 3.1.1 기능정의서 v1.10 Task ID와 F 함수 대응
→ 3.2 F01~F15 프롬프트 구성
├─ 공통 JSON·사실성·문체 규칙
├─ 함수별 반환 필드·판단 규칙
└─ T-C3 작업 지시 + 사용자 payload + tools.llm
→ 3.3 F01~F15 결과 구조와 근거 보존
├─ 3.3.1 canonical 데이터 계보: 생성·참조·사용 경로
└─ 3.3.2 항목별 sourceKeys 선별·작성·검증 전달
→ 3.4 F16~F18 작성·결과·근거 보존 (작성 단계 상세 설명)
├─ 3.4.1 F16 프롬프트 지시 구성·F17 표·F18 이미지 작성
│ ├─ 3.4.1.1 F16 본문 생성 (T-W1, 항목 동시 최대 4)
│ ├─ 3.4.1.2 F17 표 생성 (T-W3, Python)
│ ├─ 3.4.1.3 F18 이미지 명세 생성 (T-W2, 동시 최대 2)
│ └─ 3.4.1.4 F16~F18 작성 단계 내부 실패·재시도
├─ 3.4.2 F16~F18 결과 구조와 생성 산출물 보존
└─ 3.4.3 작성 데이터 계보: sourceKeys 선별·작성·검증 전달
4. 작성 항목 연결 (FormSpec + execution_contract.json)
├─ 항목별 functionId·title·displayTitle·rules·sourceKeys
├─ 유형별 본문·표·이미지 항목 및 공유 근거
└─ 재작성 묶음 → 항목 → 작성 Task 연결 (rework_map.py)
5. 문서 유형별 작성 규칙 (writing_rules.json)
→ 5.1 항목별 F16/F17/F18 작성 및 작성 단계 재시도
├─ T-W1 본문 → T-W2 그림 → T-W3 표
├─ M-1: 본문·표 서술·표·그림 합치기
└─ T-V1에 생성 출력과 같은 항목의 원본 근거 전달
6. F19 검증·결과 저장·상태 분기 (T-V1, 항목 동시 최대 4)
→ 6.1 저비용 구조·계약 검사 (F19-1 · Python)
→ 6.2 원본 사실·근거·상태값 대조 (F19-2 · Python)
├─ issues 있음 → fail 기록, 의미 검증 호출 생략
└─ issues 없음 → 6.3 규정·공고 자료와 유형별 기준 (F19-3 · LLM)
→ 6.4 의미 검증 결과 재분류·조정 (F19-4 · Python)
├─ 표·그림 존재 및 기능명 정규화 대조
├─ 협약기간·로드맵·작성 표 일정 대조
└─ inputMissing / inputError 구분
→ 6.5 점수 계산과 공식 배점 구분 (F19-5 · Python)
├─ 6.5.1 rubric 평가 항목과 유형별 가중치
├─ 6.5.2 점수 계산 순서와 기본 감점
├─ 6.5.3 감점 간격을 둔 이유
├─ 6.5.4 공고 평가영역과 내부 점수의 관계
└─ 6.5.5 별도 제약 감점과 문서층 환산
→ 6.6 최종 상태와 회귀 재작성 연결 (F19-6 · Python)
→ 6.7 판정 저장과 후속 경로 분기 (Python)
├─ pass / warning → 항목 판정·점수 저장
├─ fail → 7.1 서버의 항목별 재수행·재검증
│ ├─ 본문·그림: 대상 작성 Task → M-1 → 대상 T-V1
│ ├─ 표: 대상 T-V1 재검증
│ └─ 한도 뒤 fail 표: T-W3 설명문 대체 → M-1, fail 유지
└─ G-02a 문서 평가 판정 → 사용자 평가 확인
├─ 묶음 재작성 → 7.2 사용자 선택 항목 재작성·재검증
└─ 다음 단계 → 후속 제작·산출물 검증·검수 → 8. 결과 통합
7. F19 fail 회귀 재작성·재검증
→ 7.1 검증 실패 항목 재수행 (항목마다·사이클마다 기본 1회)
→ 7.2 사용자 묶음 재작성 (묶음마다 기본 1회)
├─ 고른 묶음의 targetItems 계산
├─ F01~F15 전략 결과·사용자 원본 재사용
├─ 대상 F16/F17/F18 재작성, 나머지 base 결과 유지
└─ 대상 F19 재검증·점수 갱신·G-02a/G-02b 판정
→ 7.3 재작성 후 연결과 이력
├─ 문서 평가·종합 평가 구간별 후속 실행
└─ 새 산출물 버전·피드백·비교·되돌리기
→ 7.4 항목 병렬 처리·재개·실패 우선순위
├─ 동시 처리 상한·양식 순서·항목별 호출 기록
└─ 완료 partial 재사용·실패 종류별 전달
8. 계획서 합치기·결과 통합 및 저장 (M-1 / T-C4)
├─ PlanDoc 본문·표·그림 구성과 산출물 버전 보존
├─ 후속 산출물·점수 보고서·미달 항목 통합
└─ 웹 계획서 파일 내려받기·실행/호출/재작성 이력
문서 목차 전용
├─ 오케스트레이터 공통 운영
│ └─ 실행 상태·부분 결과 보존
├─ 실행 순서 요약 (목차 1~8단계)
├─ 참고 자료: F19 검증 기준 파일
├─ 부록 A. API 연동 명세 (백엔드·협업자 공유용)
│ ├─ A.1 UI ↔ 웹 백엔드
│ ├─ A.2 UI 동작과 실행 요청 대응
│ └─ A.3 외부 API
├─ 부록 B. 구현 실패 사례·개선 계획·성과 측정
├─ B.1 확인된 실패 사례와 적용한 개선
├─ B.2 개선 계획과 검증 방법
├─ B.3 task·항목별 성과 측정 기록
└─ B.4 발표용 단계별 이슈·트러블슈팅
├─ B.4.1 전략: 조사·사용자 입력·근거 전달
├─ B.4.2 작성: 본문·표·그림·재작성
└─ B.4.3 검증-1: 판정·오탐·채점·복구
└─ 부록 C. 함수별 구현·검토 대장
├─ C.1 구현 구조와 역할
├─ C.2 모듈별 함수 정의 (21개 모듈·217개 정의)
├─ C.3 개발 결과와 검증 근거
└─ C.4 발표·성과 보고용 지표 요약
여러 단계와 함수들이 얽히고, 사업계획서의 각 항목들이 얽혔다. 개발하면서 내가 헷갈려하거나 잘못 오해할 수 있을 거란 가능성을 염두에 뒀고 더불어 문제는 복잡한 만큼 남에게 설명할때 시간과 노력이 배가 드는게 문제였다. 간결하게 설명하기가 힘들어질 것이다. 위 flow를 개발하면서 하나하나 이해하고 연결해가며 실수를 하지않도록 노력함과 동시에 팀원들에게 어떻게 말해야 내가 수행한것을 쉽게 이해시킬 수 있을까를 고민하며 개발했다.
사업계획서는 총 예비, 재도전, 초기창업으로 크게 나뉘었고 예비창업패키지의 경우 기본형, 특화형으로 한번 더 나뉘었다.
각 예비(기본, 특화), 재도전, 초기창업, (정부지원이없는)기본 총 4개의 카테고리로 나뉘어 공식 공고자료와 사업계획서 양식, 또 각 검증1에 사용될만한 공식 자료를 찾아 헤맸고 1주일 지난뒤, 이에 적합한 자료를 모두 세팅할 수 있었다.
공고 및 사업계획서 양식을 보아 docs혹은 hwp혹은 둘다를 지원해야한다고 web팀에게 알렸다.
위 공고와 양식 외 세부관리기분 및 질의응답또 추출하여 전체공유했다. 각 사업계획서의 문항과 조건를 살핀뒤 web에 지속적으로 검토요청을 거듭했다. 현재도 이미 경우의 수가 많아 구현에 제한을 두는게 필요했기 때문이다. 특히 재도전의 경우 폐업한 이력 및 그 이유 및 재도전의 포부를 밝혀야하는등 개인정보와 밀접한 내용이 많아 더욱 고려대상이 되었다.
공식적으로 오픈된 '사업계획서 좋은 예시'를 서치중 찾게되어 마찬가지로 전체 공유했다. 이는 정부사업이 아닐경우 기본 사업계획서의 바탕이 되었다.
우선 작업전에 사업계획서 3개를 분석했다 . 각 항목은 어떻게 나뉘는지, 어디서 back 데이터가 들어오고 어디 항목과 서로 연관되어있는지 명확히 이해하고 기록해놔야 한다고 생각했다 .
또 각 agent가 어떻게 밀접하게 서로 통신할것인지 또 검증할때는 크래딧을 쓰지않아도 되는 경우 어떻게 저비용 검증 및 python 코드를 사용할것인지도 생각해봤다.
크롤링한 데이터와 각 항목이 어떻게 연결이 되고 근거로 사용되는지와 각 사업계획서가 무엇을 중점으로 보고있는지를 파악했고 이에 따라 함수를 나누어 관리하기로했다. 10개는 적고, 30개는 많이 세분화할 수 있었다. 2주 내에 구현할 수 있는 범위하면 20개 함수정도라면 완성도가 높지않을까? 각 항목별로 사용될 모델도 정의했다 . 덜 똑똑한 모델이 충분히 소화할 수 있는 항목에서는 크래딧을 절약하는 것이다 .
우선 주요 flow를 세팅한뒤 back에 예시 data를 요청했다. 형식은 json 형태로 sample을 만들어 형식을 맞춰달라고 요청했다.
3 에이전트 모두가 돈이 드는 agent인 만큼 한정된 자원 300$에서의 8할을 내가 소비할 것이란 생각이 들었다. 개발하는 중, 테스트하는중에도 불필요한 크래딧을 낭비하지않도록 처음부터 부분 테스트가 가능하도록, 부분검증이 가능하도록 부분 작성이 가능하도록 함수를 만들어 세팅해 주의했다.
위 방법으로 신중하게 개발하고, 정말 문제가 없을것같을때 전체 테스트를 수행했고 이때는 전략, 작성, 검증1이 모두 돌았다. 당연하게도 전체를 돌릴때 fail되는 경우가 있었고 다시 위방법으로 회귀하며 무한 테스트 및 개발을 수행했다. 175회가 넘어서자 안정적인 사업계획서를 만들 수 있었다.
수행하며 추가적으로 필요하기에 중단 버튼도 만들어 사용했다. 네트워크가 불안정하거나 몇번 안됬지만 잘못눌렀거나 등 차라리 내 돈이면 덜했을테지만 공용자원인만큼 테스트가 계속되는 만큼 사소한 실수에서의 소비되는 금적자원이 아쉬웠다.
특히 이미지의 경우 단순한 컬러 변경이나 구조변경은 새로 작성하기위해 별다른 agent가 돌 필요가 없을 수 있었다 . 이 경우를 대비해 이미지만 재작성 기능도 만들어 수행해갔다.
검증 또한 마찬가지다 .
작성보다 검증이 더욱 까다로웠다.
일반, 예비창업, 초기창업으로 나뉘어지고,
사업계획서 각 항목마다로 또 나뉘어져
경우의 수가 무한대로 늘어났기때문이다.
혼자 개발하는 것이아니고 주요기능인 만큼 back이나 front에도 간간히 개발이 채 완료되지않았을때 또한 결과물을 제공해야했다
성공적인 json 데이터가 나올때마다 빠르게 잘 공유할 수 있도록 다운로드 및 복사 기능도 추가해 수행했다.
사업계획서는 단순이 경우의 수를 따져 각 항목만을 잘 작성해서 끝나는 것이 아니었다.
재작성의 경우
각 부분들은 사업계획서에서의 다른 항목과 연관되며 한곳만 수정되서는 안되고 다른곳도 함께 수정되어야하는 경우가 빈번했다.
이를 미리 신경써 기록해놨고 이 기록을 기반으로 신경써 재작성되도록 했다 .
개인적인 회고는 여기까지하고, 상세히 개발한 내용을 보고하겠다 .
참고로 작성 agent의 페르소나에 '사업계획서문체'가 있다.
보고 또한 사업계획서 문체로 해보자. 해당 내용은 md파일로 작성해 팀원들에게 모두 공유되었따 .
전략·작성·검증-1의 함수, 프롬프트, 실행 계약과 자체 파이프라인을 개발함.
서비스에서는 제공한 기능을 오케스트레이션 담당자가 Task로 연동하여 사용함.
서비스 연결 구조와 운영 상세는 부록 D에 모아 둠.
전략 개발
F01~F15를 구성해 조사 자료, 아이템 분석, 시장·경쟁 분석, 개발 목표·방법·계획, 사업화·BM·성장전략, 자원·사업비·일정 분석을 연결함.
KIET 시장 자료와 개발지식·디자인 자료를 준비하고, 키워드 기반 조회·출처 참조·근거 선별을 통해 분석에 필요한 자료를 전달함.
원본 사실과 생성 계획값을 구분하고, canonical 결과·provenance·sourceRefs를 통해 작성과 검증에서 같은 근거를 사용하도록 구성함.
사용자 산업 키워드에 대한 추가 수집·자료 갱신과 실행별 KIET 검색 연결 기반을 개발함.
작성 개발
F16 본문, F17 표, F18 그림 명세를 분리하고 문서 유형·항목별 sourceKeys와 작성 규칙을 적용함.
일반·예비창업·초기창업 양식의 항목 계약을 구성하고, 항목별 분량·필수 내용·표 컬럼·이미지 명세를 정의함.
생성 응답을 정규화하고 표·그림 구조를 검사하며, 표 대체 사유·안내와 피드백 기반 재작성에 필요한 로직을 제공함.
흐름도·서비스 구조도 명세와 시험용 SVG 그리기를 구현함.
검증-1 개발
F19를 구조·계약 검사→원본 사실·근거 대조→규정·공고 기반 의미 검증→판정 보정→채점 순서로 구성함.
표·그림 누락 오탐과 기능명·날짜·금액 표현 차이를 보정하고, 확정 사실 위반과 제안·확인 필요 사항을 구분함.
협약기간·개발 종료월·지원금 상한 위반을 구조화된 입력 오류 코드로 반환하여 서비스가 후속 조치를 판단할 수 있도록 함.
유형별 평가 rubric과 감점 기준을 구성하고, 판정·근거·정책·감점 사유를 함께 보존하는 채점 로직을 개발함.
자체 파이프라인과 수정 대응
run_pipeline·normalize_back_input으로 입력과 실행을 구성하고, impact_plan·retry_sections로 영향 항목과 재작성 대상을 처리함. assemble_document·aggregate_scores로 작성 결과와 점수를 조립함. 서비스 연결 과정에서 입력 오류 코드·표 대체 안내·검색 연결 등 수정 요청에 필요한 원본 기능과 수정안을 제공함.
실행 방식은 python -B -m pytest -o "addopts=" -p no:cacheprovider -q에 위 10개 파일과 --junitxml을 지정함. 테스트는 본문·표·그림·입력 오류·문서층 채점·묶음 재작성·재개·호출 실패 시나리오를 포함함.
C.4 발표·성과 보고용 지표
구분
개발 규모
산출 근거
기능 단계
F01~F19
함수 실행 계약·원본 함수
양식 계약
일반 10·예비 25·초기 24, 총 59개 항목
execution_contract.json
작성 종류
본문 50·표 7·이미지 항목 2
F16/F17/F18 계약
개발지식 자료
지식 항목 40개·출처 URL 36개
development_knowledge.json·source_manifest.json
디자인 자료
편집 트렌드 30개와 근거 문구
web_design_trends_2026.json
발표는 전략→작성→검증-1의 개발 내용과 부록 B의 문제·해결을 설명하고, 위 계약·자료 규모 및 C.3의 결과를 근거로 제시함. 서비스 연동 검증 결과인 317건 통과는 “개발 기능과 서비스 연동 결과를 회귀 검증했다”로 설명함.
부록 D. 서비스 연동·운영 참고
오케스트레이션 담당자가 원본 기능을 서비스 Task로 연결한 구조와 운영 상세를 모음. 본인 제공 함수·계약·수정안을 활용한 부분은 해당 설명과 함께 기록함.
D.1 전체 서비스 실행 흐름
문서 유형 결정 (documentType / kind — 신청자 유형 기준)
→ 파이프라인 진입·Task 등록 (bootstrap.build_app / bind_partner_sw — 오케스트레이션 구현)
→ 오케스트레이터 구성 (sbrain_flow.py + catalog.py — 오케스트레이션 구현)
1. 실행 계약·입력 준비
→ 1.1 실행 계약 로드 (execution_contract.json)
├─ 함수별 입력·출력 계약과 기본 모델
├─ 실행 설정 사본·Task 모델·purposeModels
└─ FormSpec의 항목 번호·화면 제목·종류·태그
→ 1.2 입력 구성·정규화 (inputs.py)
├─ 아이디어·산출물·기술분야·사용자 목표 고객
├─ 대표·팀원 역량, 수익모델, 사업비·일정 행
└─ 일반현황 원본 사실: 창업아이템명·팀구성현황
→ 1.3 실행 제약 구성 (strategy_limits)
├─ deadline·supportLimit·featureList
└─ 협약기간 / 협약 이후 로드맵, 예비창업 1·2단계 사업비
2. 조사 자료 준비: 사이트별 수집·검색 경로
→ 2.1 기준 자료 구축·선택적 갱신
├─ KIET 시장 자료·개발지식·디자인 트렌드 자료
└─ 선택적 실행별 KIET 검색 (SBRAIN_KIET_SEARCH)
→ 2.2 파이프라인 실행 시 검색·전달
├─ F01 자료 조회·조건부 해석
└─ 시장·경쟁·개발 근거 조회와 sourceRef 연결
3. F01~F15 공통 전략 실행
→ 3.1 실행 흐름과 함수 목록
├─ T-S1: F01 → F02 → F05~F09 → F13~F15
├─ T-S2: F03 → F04 → F10~F12
└─ 3.1.1 기능정의서 v1.10 Task ID와 F 함수 대응
→ 3.2 F01~F15 프롬프트 구성
├─ 공통 JSON·사실성·문체 규칙
├─ 함수별 반환 필드·판단 규칙
└─ T-C3 작업 지시 + 사용자 payload + tools.llm
→ 3.3 F01~F15 결과 구조와 근거 보존
├─ 3.3.1 canonical 데이터 계보: 생성·참조·사용 경로
└─ 3.3.2 항목별 sourceKeys 선별·작성·검증 전달
→ 3.4 F16~F18 작성·결과·근거 보존 (작성 단계 상세 설명)
├─ 3.4.1 F16 프롬프트 지시 구성·F17 표·F18 이미지 작성
│ ├─ 3.4.1.1 F16 본문 생성 (T-W1, 항목 동시 최대 4)
│ ├─ 3.4.1.2 F17 표 생성 (T-W3, Python)
│ ├─ 3.4.1.3 F18 이미지 명세 생성 (T-W2, 동시 최대 2)
│ └─ 3.4.1.4 F16~F18 작성 단계 내부 실패·재시도
├─ 3.4.2 F16~F18 결과 구조와 생성 산출물 보존
└─ 3.4.3 작성 데이터 계보: sourceKeys 선별·작성·검증 전달
4. 작성 항목 연결 (FormSpec + execution_contract.json)
├─ 항목별 functionId·title·displayTitle·rules·sourceKeys
├─ 유형별 본문·표·이미지 항목 및 공유 근거
└─ 재작성 묶음 → 항목 → 작성 Task 연결 (rework_map.py)
5. 문서 유형별 작성 규칙 (writing_rules.json)
→ 5.1 항목별 F16/F17/F18 작성 및 작성 단계 재시도
├─ T-W1 본문 → T-W2 그림 → T-W3 표
├─ M-1: 본문·표 서술·표·그림 합치기
└─ T-V1에 생성 출력과 같은 항목의 원본 근거 전달
6. F19 검증·결과 저장·상태 분기 (T-V1, 항목 동시 최대 4)
→ 6.1 저비용 구조·계약 검사 (F19-1 · Python)
→ 6.2 원본 사실·근거·상태값 대조 (F19-2 · Python)
├─ issues 있음 → fail 기록, 의미 검증 호출 생략
└─ issues 없음 → 6.3 규정·공고 자료와 유형별 기준 (F19-3 · LLM)
→ 6.4 의미 검증 결과 재분류·조정 (F19-4 · Python)
├─ 표·그림 존재 및 기능명 정규화 대조
├─ 협약기간·로드맵·작성 표 일정 대조
└─ inputMissing / inputError 구분
→ 6.5 점수 계산과 공식 배점 구분 (F19-5 · Python)
├─ 6.5.1 rubric 평가 항목과 유형별 가중치
├─ 6.5.2 점수 계산 순서와 기본 감점
├─ 6.5.3 감점 간격을 둔 이유
├─ 6.5.4 공고 평가영역과 내부 점수의 관계
└─ 6.5.5 별도 제약 감점과 문서층 환산
→ 6.6 최종 상태와 회귀 재작성 연결 (F19-6 · Python)
→ 6.7 판정 저장과 후속 경로 분기 (Python)
├─ pass / warning → 항목 판정·점수 저장
├─ fail → 7.1 서버의 항목별 재수행·재검증
│ ├─ 본문·그림: 대상 작성 Task → M-1 → 대상 T-V1
│ ├─ 표: 대상 T-V1 재검증
│ └─ 한도 뒤 fail 표: T-W3 설명문 대체 → M-1, fail 유지
└─ G-02a 문서 평가 판정 → 사용자 평가 확인
├─ 묶음 재작성 → 7.2 사용자 선택 항목 재작성·재검증
└─ 다음 단계 → 후속 제작·산출물 검증·검수 → 8. 결과 통합
7. F19 fail 회귀 재작성·재검증
→ 7.1 검증 실패 항목 재수행 (항목마다·사이클마다 기본 1회)
→ 7.2 사용자 묶음 재작성 (묶음마다 기본 1회)
├─ 고른 묶음의 targetItems 계산
├─ F01~F15 전략 결과·사용자 원본 재사용
├─ 대상 F16/F17/F18 재작성, 나머지 base 결과 유지
└─ 대상 F19 재검증·점수 갱신·G-02a/G-02b 판정
→ 7.3 재작성 후 연결과 이력
├─ 문서 평가·종합 평가 구간별 후속 실행
└─ 새 산출물 버전·피드백·비교·되돌리기
→ 7.4 항목 병렬 처리·재개·실패 우선순위
├─ 동시 처리 상한·양식 순서·항목별 호출 기록
└─ 완료 partial 재사용·실패 종류별 전달
8. 계획서 합치기·결과 통합 및 저장 (M-1 / T-C4)
├─ PlanDoc 본문·표·그림 구성과 산출물 버전 보존
├─ 후속 산출물·점수 보고서·미달 항목 통합
└─ 웹 계획서 파일 내려받기·실행/호출/재작성 이력
문서 목차 전용
├─ 오케스트레이터 공통 운영
│ └─ 실행 상태·부분 결과 보존
├─ 실행 순서 요약 (목차 1~8단계)
├─ 참고 자료: F19 검증 기준 파일
├─ 부록 A. API 연동 명세 (백엔드·협업자 공유용)
│ ├─ A.1 UI ↔ 웹 백엔드
│ ├─ A.2 UI 동작과 실행 요청 대응
│ └─ A.3 외부 API
├─ 부록 B. 구현 실패 사례·개선 계획·성과 측정
├─ B.1 확인된 실패 사례와 적용한 개선
├─ B.2 개선 계획과 검증 방법
├─ B.3 task·항목별 성과 측정 기록
└─ B.4 발표용 단계별 이슈·트러블슈팅
├─ B.4.1 전략: 조사·사용자 입력·근거 전달
├─ B.4.2 작성: 본문·표·그림·재작성
└─ B.4.3 검증-1: 판정·오탐·채점·복구
└─ 부록 C. 함수별 구현·검토 대장
├─ C.1 구현 구조와 역할
├─ C.2 모듈별 함수 정의 (21개 모듈·217개 정의)
├─ C.3 개발 결과와 검증 근거
└─ C.4 발표·성과 보고용 지표 요약
파이프라인 진입·Task 등록 (bootstrap / tasks.py)
기여 구분: 오케스트레이션 독자 구현.
워커 구성과 Task 등록은 오케스트레이션 담당자가 구현함.
등록되는 전략·작성·검증-1의 기반 함수·계약은 본인이 개발함.
워커의 bootstrap.build_app이 실행 엔진과 Task 등록부를 구성하고, bind_partner_sw가 전략·작성·검증-1의 여섯 Task를 등록함. 서비스 명령이 작성 구간을 시작하면 흐름 엔진이 Task별 입력을 준비해 호출함.
웹 작성 시작 요청 → service.start_writing_for_project
→ 작성 구간 큐
→ T-C3 → T-S1 → T-S2 → T-W1 → T-W2 → T-W3 → M-1 → T-V1 → G-02a
전략·작성·검증-1의 함수는 strategy.py, writing.py, verify.py에서 Task 단위로 실행함.
pipeline.py의 근거 구성·정규화·표 입력·검증 보정 함수를 이 과정에서 재사용함.
각 Task는 입력 계약과 산출물 참조를 통해 앞 단계 결과를 전달받음.
오케스트레이터 구성 (sbrain_flow.py / catalog.py)
기여 구분: 오케스트레이션 독자 구현과 본인 개발 기반의 연동.
실행 순서·Task 입출력 연결은 오케스트레이션 담당 영역이며, 호출되는 F01~F19와 작성·검증 계약은 본인 개발 영역임. 아래 모듈 표는 전체 연동 구조를 설명함.
오케스트레이터는 실행 순서, Task별 입력·출력, 호출 설정, 산출물 버전과 재수행·재작성 흐름을 관리함. 전략·작성·검증-1 함수의 세부 처리는 전용 모듈에 위임함.
모듈
책임
sbrain/bootstrap.py
워커·호출처 구성, 실구현 Task 등록
flow/sbrain_flow.py
작성 구간·대기·재수행·재작성 순서
flow/catalog.py
Task 입력·출력과 산출물 참조 연결
flow/service.py
작성 시작·사용자 선택·재작성 명령
partner_sw/strategy.py
T-S1·T-S2 안에서 F01~F15 호출
partner_sw/writing.py
T-W1·T-W2·T-W3의 본문·그림·표 작성
partner_sw/verify.py
T-V1 검증·판정 보정·문서층 환산
partner_sw/common.py
canonical·목표 항목·동시 처리·부분 결과 재사용
partner_sw/inputs.py
원본 입력·표 행·기간·제약값 구성
partner_sw/calls.py
함수 요청을 tools.llm·tools.search에 연결
agent_strategy/runtime/llm_runtime.py
프롬프트 합성·JSON 응답 계약·결과 정리
agent_strategy/runtime/pipeline.py
항목 근거·표 인자·생성 출력 정규화·검증 보정
agent_strategy/functions/python_functions.py
F01·F14·F15·F17의 로컬 준비·처리
agent_strategy/functions/gpt_functions.py
F02~F13·F16·F18의 LLM 요청 구성
agent_validation_1/validation_1.py
F19 구조·원본·근거·의미 검증
agent_validation_1/scoring.py
항목 원점수·감점 계산
orchestrator/tools.py·trace.py
호출 재시도·시도 이력·토큰·오류 기록
모듈 경로는 agent-orchestration/sbrain/ 기준임. partner_sw 내부의 함수·자료 경로는 sbrain/agents/partner_sw/를 기준으로 읽음.
오케스트레이터 공통 운영
기여 구분: 서비스 운영 정책은 오케스트레이션 담당 구현.
함수별 근거 검색·제약·오류 판정은 본인 원본과 서비스 어댑터가 결합된 기능이며, 재시도·동시 처리·부분 결과 재개·운영 로그는 서비스 연결 구현으로 구분함.
흐름 엔진이 조정하는 공통 실행·복구 정책은 다음과 같음.
함수별 설명은 1~8단계에, 검증 실패 재수행과 사용자 재작성은 7단계에 정리함.
실행 제어와 재작성
작성 구간 제어: T-C3 작업 분해 이후 전략·본문·그림·표·합치기·검증·판정을 순서대로 실행함. 문서 평가 확인과 사용자 재작성 선택은 대기 지점으로 관리함.
부분 실행 데이터 재사용: 재작성은 기존 strategyData·marketStrategyData·원본 사실·조사 근거를 재사용함.
재작성 범위 결정: rework_map.py의 묶음→항목→Task 매핑과 ReworkInput.targetItems를 사용함.
동시 처리: T-W1 본문 항목은 최대 4개, T-W2 그림은 최대 2개, T-V1 항목 검증은 최대 4개를 동시에 처리하고 양식 순서로 결과를 모음.
호출 재시도: tools.llm·tools.search·tools.files에서 호출 실패 정책을 적용함. 형식 오류 재시도·검증 실패 재수행·사용자 재작성은 각각 별도로 관리함.
조사 자료와 작성 제약
선택적 KIET 검색: SBRAIN_KIET_SEARCH를 켜면 T-S1이 F01 전에 현재 산업 키워드로 KIET를 검색함. 검색 결과는 실행 메모리에서 시장 근거와 합침.
로컬 자료 검색: research_context.retrieve가 미리 준비한 시장·개발·디자인 JSON의 키워드·별칭을 검색해 함수별 근거를 구성함.
사실 상태 전달: _annotate_status가 적용되는 전략 결과는 provided, proposed, needs_confirmation을 구분함.
유형별 제약 적용: 개발 종료월·선택 공고 상한·기능 목록을 strategy_limits로 구성하고 예비창업 사업비는 _pre_startup_budget_phases로 단계별 보존함.
호출 설정 고정: 실행 시작 시 settingsSnapshot을 보존하고 그 실행의 Task 모델·목적별 모델·재시도·배점 설정을 적용함.
호출 실패 분류와 대기 설정
오류·호출 종류
처리
결제·사용량 한도 코드
상태 코드와 함께 제공되는 오류 코드를 확인하고 재시도 없이 소진 처리한 뒤 단계별 재개·종료 정책으로 전달
입력·운영 응답 오류
한 번 시도 후 입력/운영 오류로 종료
일시 응답 오류·시간 초과·연결 오류
늘리는 간격·무작위 지연·Retry-After를 적용해 재시도
형식 오류·파일 호출
고정 간격으로 재시도
공고 서버 검색·자격 판정 호출
backoff=False로 기본 2초 고정 간격 적용
한 호출의 대기 합 상한 도달
남은 재시도 횟수보다 상한을 우선 적용해 소진 처리
일시 오류의 n번째 재시도 전 대기는 retryIntervalSec × backoffMultiplier^(n−1) × (1 + 무작위[0, jitterRatio])로 계산함.
기본값은 간격 2초·배수 2·무작위 비율 0.25임.
Retry-After가 있으면 계산값과 전달값 중 큰 값을 사용하고 상한은 기본 60초임.
issues가 있으면 의미 검증을 생략하고 fail을 기록함. 통과하면 6.3 규정·공고 의미 검증을 수행함.
6.4 판정 보정에서 표·그림·일정 대조와 입력 없음/입력 오류 처리를 적용함.
6.5 채점에서 rubric 가중치·감점을 적용하고 문서층 배점으로 환산함.
6.6 상태, 6.7 저장·분기에서 항목 판정·점수를 보존하고 필요 시 7단계 재수행을 거쳐 G-02a로 연결함.
F19 fail 회귀 재작성·재검증
서버가 이번 생성 항목의 fail을 대상으로 본문·그림 재생성 또는 표 재검증을 수행함.
한도 뒤에도 fail인 표는 설명문으로 대체하고 판정은 유지함.
사용자가 고른 묶음은 목표 항목만 재작성하고 전략 결과와 나머지 항목을 이어받음.
재검증·점수 갱신 뒤 G-02a/G-02b가 다음 행동과 재작성 후보를 제시함.
계획서 합치기·결과 통합 및 저장
M-1이 본문·그림·표를 계획서에 합치고 산출물 버전을 저장함.
후속 제작·산출물 검증·검수 이후 T-C4가 계획서·프로토타입·인포그래픽·점수·미달 항목을 통합함.
웹이 planDoc에서 내려받기 문서를 생성하고 실행·호출·재작성 기록을 조회함.
7. F19 fail 회귀 재작성·재검증
기여 구분: 본인 판정·재작성 기능 기반의 서비스 연동.
F19 판정과 원본 impact_plan·retry_sections는 본인 개발임.
아래 서버 횟수 관리·묶음 선택·Task 큐·재개 경로는 오케스트레이션 담당 구현이며, 본인 제공 입력 오류 코드와 수정안을 반영함.
검증 실패 재수행과 사용자 선택 묶음 재작성은 각각의 범위·횟수·입력을 사용함. 두 경로 모두 F01~F15 전략 결과와 사용자 원본 근거를 재사용함.
7.1 서버의 항목별 검증 실패 재수행
T-V1 직후 흐름 엔진이 이번 생성 항목에서 fail을 고름. inputMissing·inputError·이미 표를 설명문으로 대체한 항목을 제외함. 횟수는 redo.verify1RedoCount로 관리하며 기본 항목마다·사이클마다 1회임.
항목 종류
재수행 실행
전달 내용
본문
T-W1 → M-1 → T-V1
targetItems·직전 issues·previousText
그림
T-W2 → M-1 → T-V1
targetItems·직전 issues·두 flowType
표
T-V1
기존 표와 원본 근거
한도 뒤 fail 표
T-W3 대체 → M-1
fallbackItems·문제 목록·fallbackReasonCodes
재수행은 본문·그림 대상만 작성 Task로 나누고 표는 재검증함. 마지막 표 대체는 generatedText 설명과 displayReason을 남기며 판정은 fail로 유지함. 이 재수행 횟수는 사용자 묶음 재작성 기회와 별도로 관리함.
7.2 사용자 선택 묶음 재작성
G-02a/G-02b는 항목 판정·점수·묶음 매핑을 읽어 재작성 후보를 구성함. 해당 묶음의 fail·warning 중 입력 없음/입력 오류 항목을 제외한 문제 목록을 후보 사유로 사용함. 점수가 기준 미만이고 항목별 후보가 없으면 설정된 전체 묶음 후보를 제시함.
사용자 묶음 선택
→ rework_map.bundle_items → 항목 번호·종류
→ T-W1 / T-W2 / T-W3별 targetItems
→ 직전 결과·원본 근거·보완 지시를 연결
→ 대상 재작성, 나머지 base 결과 유지
→ M-1 → 대상 T-V1 → 필요한 항목 재수행
→ 사이클 비교·점수 갱신 → G-02a / G-02b
기본 재작성 기회는 묶음마다 1회이며 settingsSnapshot.rework.perBundle을 따름. 일반현황·개요 및 그림의 새 묶음은 GENERAL_BUNDLES_ENABLED 스위치로 관리함. 목표 밖이지만 이전 결과가 없는 항목은 생성·검증함.
F16은 직전 본문·validationFeedback·retryInstruction, F18은 architecture의 validationFeedback·retryInstruction, F17은 사용자 원본 표 행을 사용함. 원본 사실과 수익모델·목표 고객은 동일 실행 산출물에서 이어받음.
7.3 재작성 후 연결과 이력
화면 6 문서층 재작성은 작성 Task→M-1→T-V1→사이클 비교→G-02a로 연결함. 화면 9에서 계획서를 재작성하면 웹개발/게임은 T-B1에, 원페이지는 T-B2에 반영하고 T-V2·G-02b로 연결함.
재작성은 새 ExecutionRecord와 산출물 버전을 만들고 피드백 출처를 FeedbackLink로 연결함. 이전·이후 점수와 비교 결과를 평가 보고서에 담고, 실패한 재작성의 되돌리기와 기회 사용은 실행 엔진이 관리함. 이후 사용자는 평가를 확인해 다음 행동을 선택함.
7.4 항목 병렬 처리·재개·실패 우선순위
gather는 최대 동시 처리 수로 스레드 풀을 구성하고 완료 순서와 관계없이 입력 키 순서로 결과를 모음. 각 항목은 자신의 tools.for_item과 partner_call 문맥을 사용해 모델·검색·파일 기록을 분리함.
동시에 여러 실패가 있으면 일반 예외→일시가 아닌 호출 소진→일시 호출 소진 순으로 원래 예외를 전달함. 일시 호출 소진은 이번 성공 결과와 앞 재개 결과를 함께 partial로 보존함. Steps.run은 순차 전략 함수의 완료 F번호를 같은 방식으로 관리함. 읽을 수 없는 priorResults 값은 다시 생성하고 목표 밖 base 결과는 재사용함.
이 처리로 한 항목 실패 시 이미 완료한 항목을 이어받고, 생성 순서·검증 판정·산출물 버전·로그의 항목 키를 일관되게 연결함.
8. 계획서 합치기·결과 통합 및 저장 (M-1 / T-C4)
기여 구분: 오케스트레이션 담당 구현. 서비스 M-1·T-C4와 후속 제작·검수·파일 통합은 오케스트레이션 영역임.
본인은 전달되는 작성 산출물·검증 판정과 원본 assemble_document를 개발했으며, 원본 조립 함수와 서비스 M-1 구현은 구분함.
계획서 합치기 (M-1)
T-W1의 본문 계획서에 T-W2의 diagrams, T-W3의 tables·tableSections를 합침. 양식 항목 번호를 기준으로 표 서술문과 표·그림을 연결하며, 합쳐진 planDoc 버전은 T-V1의 verifiedRef로 이어짐.
총점 통과 여부와 별도로 status=fail 항목을 inputError/verifyFail로 전달
산출물층 미달
gateFailure, codeCheck, featureMatchWithheld, missingFeature, partialFeature로 전달
파일 연결
프로토타입 진입 파일→안내 문서→자산 파일 순서, 인포그래픽 파일 별도 연결
사용자 안내
내려받기 안내, 총점 미달이면 표시 점수·기준점, 미달 항목별 이름·점수·사유
진입 파일·안내 문서 유무는 통합 누락 검사 대신 해당 산출물 판정·파일 연결로 처리함. T-C4는 LLM 없는 PLAIN_TASKS에 등록해 워커와 테스트 조립에서 같은 통합 함수를 사용함.
후속 제작·검증·검수의 호출 실패 연결
T-B2 이미지 호출과 T-V2 대조 호출은 결제·한도 소진을 대체 산출물/대조 판정으로 바꾸지 않고 재개 대기로 전달함. T-P2는 전체 문장 처리 뒤 호출 실패 비율을 확인하고 기준(기본 0.3)을 넘었을 때 운영 오류가 포함되면 실패로 처리함. 일시·한도 오류의 재개와 원문 유지 정책은 같은 실행 흐름에서 관리함.
실행별 KIET 검색·키워드 확장·적합성 선별, 검색 예산·재시도 제한, 소진 후 기존 근거 활용
최신 조회 근거를 실행에 연결하면서 실패 시 전략을 계속함. test_kiet_failure_is_retried_twice_then_ts1_continues·test_kiet_no_result_and_partial_failure_are_success기여: 본인 크롤러·SB-360 검색 연결 제공 / 서비스 스위치·실패·재시도 보완은 오케스트레이션
사용자 목표 고객과 모델이 분석한 목표 고객이 달라짐
생성된 아이템 사양이 사용자 입력보다 우선되면 후속 시장·사업화 분석의 고객이 달라짐
T-C1·F02 결과를 사용자 값으로 맞추고 원본 target_customer를 F10·F11에 전달
공고·전략·작성·후속 제작에서 같은 고객을 사용함. test_partner_inputs_fix.py기여: 본인 분석 함수 활용 / T-C1·입력·F02 결과 보정은 서비스 연결
제공한 서비스명·단가가 BM·성장전략에서 바뀌거나 누락됨
수익모델이 생성 과정에서 일반적인 가정으로 바뀔 수 있음
revenueItems를 F11·F12와 성장전략 원본 근거에 한정해 전달하고 보존 규칙 적용
사용자 수익모델을 관련 항목에 연결함. test_revenue_items_are_sent_only_to_business_model_and_growth_sections기여: 본인 F11·F12·근거 계약 기반 / 전달 보완은 서비스 연결
전략 근거가 중복되어 프롬프트가 커짐
성장전략에 상위 원본·조사 근거가 중첩 복사되고 동일 자료가 반복 검색됨
검색 해시 중복 제거·건수/문자 예산, compact_prompt_source로 중복 provenance 사본 축소
핵심 요약·facts·sourceRefs·최상위 원본을 유지하면서 중복 입력을 정리함. test_prompt_source_compacts_only_growth_strategy_provenance기여: 본인 검색·근거 구성 기반 / compact_prompt_source는 연결 구현
빈 기능 목록 또는 명시적 '없음' 입력을 처리해야 함
미입력·사용자 선택·모델 생성 결과가 서로 다른 의미를 가짐
빈 F02 기능은 itemSpec.coreFeatures 승계·자체 검사 기록, 자원 '없음'은 no_* 상태로 전달
후속 기능 목록과 자원 원본 상태를 유지함. test_ts1_empty_core_features_inherits_item_spec_in_same_attempt 및 입력 구성 함수 기여: 본인 분석·원본 상태 기반 / 기능 승계·no_* 입력 변환은 연결 구현
조사·전략 분석 함수와 근거 추적 구조, KIET 수집·검색 기반을 개발하고, 오케스트레이션 담당자가 사용자 입력 보존과 서비스 검색·복구 경로를 연동함.
B.4.2 작성 — 본문·표·그림·재작성
이슈·문제 상황
원인·설계 쟁점
해결 방식
결과·검증 근거
모델 응답이 비거나 JSON이 잘림
생성 완료 여부와 유효한 항목 본문 반환은 별도 확인이 필요함
F16 generatedText·필수 배열·JSON 계약 검사, 길이 한도 잘림을 형식 오류로 처리·재시도
유효한 작성 출력만 후속 단계에 전달하고 실패 시 완료 결과를 보존함. 응답 파서·호출 실패 회귀 기여: 본인 응답 파서·출력 계약 기반 / 서비스 재시도·partial 보존은 연결 구현
본문에 작성 지시·항목 제목이 반복됨
title의 작성 지시와 displayTitle의 화면 제목이 다른 역할을 가짐
화면 제목/작성 지시 분리, _strip_section_heading으로 번호·제목 반복 정리
양식 제목과 본문 내용을 분리해 PlanSection으로 구성함. 실행 계약·T-W1 출력 검사 기여: 본인 작성 계약·정규화 기반 / PlanSection 변환은 연결 구현
원본 표·표 서술·검증 실패 안내가 뒤섞임
구조화된 표와 본문 설명, 진단 사유와 사용자 안내가 서로 다른 용도임
F17 Python 표/서술 분리, fallbackReason·코드·displayReason 분리, 구조 실패 또는 재검증 한도 후 설명문 대체
원본 행을 보존하고 표 대체 이유를 코드 기반으로 안내함. test_f17_generated_text_is_narrative_only_and_preserves_unassigned_rows·test_table_fallback_reason.py기여: 본인 F17·대체 안내 기반 / T-W3 코드·표 대체 연결은 연동 보완
단계 미지정 사업비가 잘못 배분되거나 로드맵 일정이 빠짐
예비 1·2단계, 초기 통합 사업비, 협약/로드맵의 서로 다른 양식 구조
유형별 table_data·table_arguments 적용, unassignedOriginalRows 보존, 전체 일정에 두 범위 연결
입력의 단계·일정 의미를 유지하고 필요한 입력 확인을 안내함. 단계/원본 표 구성 회귀 기여: 본인 표 인자·단계 보존 규칙 기반 / 서비스 원본 행 구성은 연결 구현
밝은 카드의 글자가 잘 보이지 않거나 그림 비율이 깨짐
모델이 선택한 배경색과 고정 글자색의 대비, 문서 내 SVG 크기 해석
카드 상대 명도로 글자색 선택, SVG 캔버스 비율·텍스트 escape·파일 참조 구성, 스텁 SVG 크기 지정
밝은/어두운 카드와 문서용 SVG 구조를 확인함. test_f18_svg_uses_contrasting_text_for_bright_and_dark_cards·test_file_fields.py기여: 본인 F18·SVG 그리기 기반 / 대비·스텁 크기·FileRef 보완은 연결 구현
한 항목 수정으로 전체 문서를 다시 생성하게 됨
재작성 대상과 유지할 결과·근거가 명확히 분리되어야 함
targetItems·base 출력·직전 본문·피드백 연결, 성공한 partial 결과 재사용
선택한 항목만 갱신하고 나머지 결과를 이어받음. test_tw1_rebuilds_only_target_items_with_feedback·test_tw1_resume_calls_only_missing_items기여: 본인 항목별 작성·재작성 기반 / targetItems·base·partial 제어는 연결 구현
유형별 본문·표·그림 명세 생성 함수와 출력 계약·원본 보존·재작성 기반을 개발하고, 오케스트레이션 담당자가 파일 저장과 대상 항목·재개 제어를 서비스에 연결함.
B.4.3 검증-1 — 판정·오탐·채점·복구
이슈·문제 상황
원인·설계 쟁점
해결 방식
결과·검증 근거
존재하는 표·두 그림이 누락으로 판정됨
의미 검증의 진단 문구와 실제 저장 구조가 충돌함
Python 구조 검사 후 _reconcile_validation으로 표 컬럼·그림 flowType과 대조
구조상 존재하는 산출물에 대한 누락 진단을 보정함. 구조화 표 검증·판정 보정 회귀 기여: 본인 _reconcile_validation·출력 계약 개발 / 서비스 검증 연결
기능명·날짜·단위 표현 차이를 오류로 판정함
괄호·구분자·동의어·월 표기·행 순서 차이가 실제 누락과 다름
기능 핵심 토큰·동의어·월·금액 정규화, 기능 검사는 해당 개발 항목에 적용
표현 차이와 필수 기능 누락을 구분함. 기능/기간 검증 함수·원본 제약 회귀 기여: 본인 검증·정규화 함수 개발
생성 오류와 사용자 입력 오류가 같은 재작성 대상으로 처리됨
협약기간·개발 종료월·지원금 상한 위반은 입력 원인과 작성 원인을 구별해야 함
구조화된 inputErrorCodes→inputError, 빈 입력은 inputMissing warning, 입력 오류 항목을 재수행·표 대체 대상에서 제외
생성 재수행은 고칠 수 있는 항목에 적용하고 입력 문제는 안내함. test_input_error_items_are_not_redone_or_replaced·test_input_missing_items_are_not_input_errors기여: 본인 inputErrorCodes 제공 / inputError 변환·재수행 제외는 연결 구현
협약 이후 로드맵이 일정 초과로 감점됨
협약기간 제약을 전체 사업 로드맵 날짜에 적용하면 오탐 발생
agreement/roadmap 분리, 원본 협약기간 대조, 감점은 구조화된 위반 코드에 적용
협약 일정 위반과 유효한 로드맵을 구분함. 협약기간·종료월·감점 키 회귀 기여: 본인 기간·코드 기반 검증 및 채점 개발 / 서비스 일정 전달
제안 계획이 확정 사실 오류와 같은 fail로 판정됨
계획서 생성값은 제공 사실·완료 실적과 다른 상태로 검토해야 함
provided/confirmed 대조, proposed/needs_confirmation·계획 표현 검사, hard/advisory 분류
확정 사실 위반은 fail로 유지하고 제안·보완은 warning으로 정리함. validate_section·review_issues기여: 본인 사실 상태·hard/advisory 검증 개발
원점수와 문서층 점수가 혼동되거나 합계가 어긋남
항목 0~100 원점수와 전체 문서층 배점의 척도가 다름
D/N 환산·항목 반올림·Decimal 합산, verifiedRef·정책·감점 사유 연결
항목 점수 합과 총점·검증 버전을 일치시킴. test_score_items_sum_to_total·test_plan_doc_ref_is_verified_ref기여: 본인 원점수·감점·검증 근거 기반 / D/N·Decimal 서비스 환산은 연결 구현
fail 재수행에서 표 대체·후속 제작 순서가 꼬임
본문·그림 재생성, 표 재검증, 사용자 재작성이 다른 복구 경로임
항목별·사이클별 횟수 관리, 작성→M-1→대상 검증, 마지막 표 대체 후 fail 유지
재수행·재작성·후속 제작의 순서를 확인함. test_first_writing_redoes_only_failed_items_then_replaces_failed_table·test_screen9_document_rework_puts_verify1_redo_before_html기여: 본인 판정·입력 오류 수정안 기반 / 횟수·큐·M-1·후속 순서는 오케스트레이션
구조·사실·의미 검증, 오탐 보정, 입력 오류 코드와 설명 가능한 채점 체계를 개발하고, 오케스트레이션 담당자가 판정을 서비스 점수·재수행 흐름에 연결함.
관련 10개 테스트 파일의 회귀 실행은 317건 모두 통과함.
단계별 표의 근거는 이 실행과 구현 코드에 연결되며, 상세 파일별 건수와 결과 보고서는 C.3에 기록함.
D.6 전체 서비스 연동 성과표
C.3 개발 결과와 검증 근거
아래는 본인 개발과 서비스 연동이 결합된 결과임.
개발 결과
구현으로 확보한 동작
검증 근거
사용자 입력 보존
목표 고객·수익모델·일반현황·팀 원본의 단계별 전달
test_partner_inputs_fix·test_revenue_items_are_sent_only_to_business_model_and_growth_sections 기여: 본인 입력·근거 계약 기반 / 사용자 값 전달·보정은 서비스 연결
유형별 작성 계약
일반 10·예비 25·초기 24개 활성 항목과 F16/F17/F18 분리
test_chain_calls_partner_functions_and_fills_contracts 기여: 본인 직접 개발 / 서비스 Task·FormSpec 연결
사실·제안 구분
원본 확정값·계획값·확인값의 상태·출처 대조
validate_section·review_issues 및 원본 입력 오류 회귀 기여: 본인 직접 개발 / 판정 산출물 연결
표 구조·대체 안내
원본 표·서술·사유 코드·사용자 안내의 분리
test_f17_generated_text_is_narrative_only_and_preserves_unassigned_rows·test_table_fallback_reason 기여: 본인 F17·대체 안내 기반 / 서비스 코드·표 대체 보완
읽기 쉬운 그림
두 그림 명세·SVG·카드 대비·제목·FileRef
test_f18_svg_uses_contrasting_text_for_bright_and_dark_cards·test_diagrams_are_svg_files_in_tools_files 기여: 본인 F18·SVG 기반 / 제목·대비·FileRef 연결 보완
프롬프트 문맥 제어
근거 건수·문자 예산·성장전략 중복 provenance 축소
test_prompt_source_compacts_only_growth_strategy_provenance 기여: 본인 검색·근거 구성 기반 / compact 문맥은 연결 구현
필요한 항목만 재작성
targetItems·base 출력·검증 판정 이어받기
test_tw1_rebuilds_only_target_items_with_feedback·test_tv1_reverifies_only_targets_and_keeps_base_results 기여: 본인 항목별 재작성 기반 / targetItems·base 서비스 구현
완료 결과 재사용
함수/항목별 partial·priorResults 복원
test_ts1_resume_continues_after_received_functions·test_tw1_resume_calls_only_missing_items 기여: 서비스 연결 담당의 partial·priorResults 구현
병렬 처리 제어
본문/검증 4·그림 2의 상한·양식 순서·실패 우선순위
test_gather_runs_at_most_workers_at_once·test_concurrent_failure_order_prefers_non_exhausted_error 기여: 서비스 연결 담당 구현
점수 설명 가능성
구조화 감점·입력 오류·원점수/문서층 구분·항목 합계
test_score_items_sum_to_total·test_input_error_keeps_partner_status_issues_and_score 기여: 본인 검증·감점 개발 / 서비스 배점·합계 환산 구현
호출·내용 분리
산출물 내용과 모델/오류/토큰 운영 기록의 분리
test_llm_requests_carry_no_forbidden_values·test_call_logs_and_errors_carry_no_content 기여: 서비스 호출·로그 연결 담당 구현
조사 실패 복구
KIET 스위치·전체 검색 제한·재시도 소진 후 로컬 근거 활용
test_kiet_failure_is_retried_twice_then_ts1_continues·test_kiet_no_result_and_partial_failure_are_success 기여: 본인 크롤러·검색 연결 제공 / 서비스 스위치·소진 처리 보완
D.7 전체 연동·검토 규모
C.4 발표·성과 보고용 지표 요약
개인 개발 규모: F01~F19·양식/출력 계약·조사 자료·원본 작성/검증 함수.
서비스 연동 규모: 여섯 Task·두 그림의 서비스 파일 연결·동시 처리 상한.
전체 검토·검증 규모: 217개 정의와 317건 회귀 테스트. 전체 검토 함수 수와 연동 테스트 건수는 개인이 모두 작성한 함수·테스트 수로 제시하지 않고, 제공 기능과 연동 결과의 확인 범위로 제시함.
구분
확인된 구성·결과
산출 근거
실행 단위
전략 2·작성 3·검증-1 1, 총 6개 Task
tasks.py의 IMPLEMENTED
기능 단계
F01~F19의 조사·전략·작성·검증 역할
함수 실행 계약·Task별 호출
양식 계약
일반 10·예비 25·초기 24, 총 59개 활성 항목
execution_contract.json
작성 종류
본문 50·표 7·이미지 항목 2
유형별 활성 F16/F17/F18 계약
서비스 그림
이미지 항목별 흐름도·구조도 두 명세
T-W2의 FLOWS·DiagramSpec
개발지식 자료
지식 항목 40개·수집 출처 URL 36개
development_knowledge.json·source_manifest.json
디자인 자료
편집 트렌드 30개와 근거 문구
web_design_trends_2026.json
검토 코드
Python 파일 27개, 함수 정의 모듈 21개, 정의 217개
코드 AST·C.2 개별 위치
동시 처리
본문 4·그림 2·항목 검증 4의 상한
common.py 상수·동시 처리 회귀
회귀 검증
관련 10개 파일·317건 통과
C.3의 JUnit 실행 보고서
개인 개발 성과는 조사·전략·작성·검증 함수, 근거 추적, 유형별 출력 계약, 규칙·의미 검증 분리, 원본 재작성·채점 로직을 중심으로 설명함.
사용자 값의 서비스 전달·partial 재개·파일 저장·문서층 환산·실행 이력은 본인 기능을 활용한 연동 성과로 설명하고 연결 담당자의 구현을 함께 표시함.
위 항목 수는 문서 유형 전체의 계약 규모이며 한 실행에서는 해당 양식의 항목을 사용함. 함수 정의 수는 담당자 함수·연결 코드·자료 구축·단독 실행 부품을 포함한 검토 규모로 기록함.
전략→작성→검증-1 순서로 개발한 처리와 B.4의 대표 문제·해결을 설명한 뒤, 위 지표와 317건 회귀 결과를 근거로 제시함.
문서 앞부분·부록 B·C.3~C.4를 사용하고, 서비스 동작 상세와 연동 사례는 부록 D를 참고함.
D.8 함수·계약과 서비스 적용 상세
원본 함수의 상세 계약·프롬프트·크롤링 출처·검증 기준과 서비스 적용 경로를 함께 보존한 기술 참고 자료임. 직접 개발 함수는 부록 C, 발표용 설명은 문서 앞부분과 부록 B를 사용함.
문서 유형 선택 (documentType / kind)
신청자 유형을 기준으로 작성 계약의 documentType / kind를 결정함. inputs.document_type은 예비창업자를 pre_startup, 그 밖의 신청자 유형을 early_startup으로 매핑함. 작성·검증에서는 strategyData.document_type에 보존한 값을 사용함.
kind
문서 유형
적용
general
일반 사업계획서
공통 함수·양식 계약으로 관리
pre_startup
예비창업패키지
예비창업자 입력
early_startup
초기창업패키지
초기창업 계약에 해당하는 입력
문서 유형은 입력 구성, 항목 계약, 작성 규칙, 사업비·일정 및 검증 기준 전반에 적용됨. 웹개발·게임·원페이지의 서비스 카테고리는 후속 제작 방식을 정하는 값으로 별도 관리함.
사용자 값이 있으면 F02 직후 결과의 targetCustomer를 그 값으로 맞춰 F05·F06·F09·F13과 후속 작성에 전달함. 재개로 받은 F02 결과에도 동일하게 적용함. 사용자 값이 없으면 원본 사실 target_customer는 확인 필요, F02가 분석한 목표 고객은 생성 결과로 관리함. targetCustomerHint는 참고값으로 분리함.
일반현황 원본 사실
일반현황 항목 2.1.1·3.1.1은 F16과 F19의 같은 originalFacts에 두 칸을 추가함.
아이템명이 비면 해당 칸을 생략함. 팀원 행의 빈 역할은 직위 팀원, 담당업무 -로 표시하고 빈 경력은 보유역량 -로 표시함. 빈 팀 목록은 팀원 없음(대표자 단독), 기존 실행의 None 값은 칸 생략으로 처리함. 전략·작성 입력에는 분석에 필요한 값만 선별하고 개인 식별정보는 제외함.
정규화 단계는 제공된 금액·기간·역량을 보존하며 입력 간 정합성은 F19에서 검사함.
웹 입력 원천과 공통 전달
서비스 입력
웹 DB 원천·정리 규칙
전달
targetCustomer
project_plan_inputs.target_customer, 앞뒤 공백 제거·빈 값은 없음
PreInput → CompanyInfo·itemSpec.targetCustomer
startupItemName
projects.description 첫 줄의 앞뒤 공백을 정리해 최대 60자
CompanyInfo → 일반현황 originalFacts
teamMemberRows
team_members의 role·experience, 저장 순서 유지·이름 제외
TeamMemberEntry 목록 → 일반현황 표 행
target_customer는 선택 DB 컬럼으로 읽으며 컬럼이 없는 환경은 미입력으로 처리함.
입력 준비에서 이 세 값은 선택 칸으로 관리함.
T-C1은 사용자 목표 고객이 있으면 아이템 사양의 targetCustomer를 그 값으로 맞춘 뒤 공고 추천·작업 분해·전략·작성·검증·후속 제작에 전달함. 입력값의 정리는 코드에서 수행하고 T-C1의 아이디어 해석 요청은 기존 구성을 유지함.
1.3 실행 제약 구성 (strategy_limits)
inputs.strategy_limits가 개발기간 종료월, 선택 공고 지원 금액 상한과 기능 목록을 받아 실행 제약을 구성함.
T-S1의 원본 사실과 strategyData.strategy_limits에 보존하고, 작성·검증에서는 T-S1이 확정한 featureList를 적용함.
개발 개월 수는 시작·종료월을 포함해 계산하며, 기간을 읽을 수 없거나 종료가 시작보다 빠르면 0으로 처리함.
협약기간과 협약 이후 로드맵
agreement = [row for row in schedules if row['_schedule_scope'] == 'agreement']
roadmap = [row for row in schedules if row['_schedule_scope'] == 'roadmap']
예비창업 implementationSchedule은 협약기간 일정, fullScaleSchedule은 협약 이후 로드맵임.
개발 종료기한은 협약기간 일정에 적용하고 전체 사업단계 표에는 두 범위의 행을 함께 보존함.
초기창업도 원본 일정에 agreement/roadmap 범위를 붙여 후속 검증에서 식별함.
market_crawler.py가 중기부 공고·PDF에서 유형 및 키워드 기준을 확인하고, KIET의 연구·동향 검색 결과를 조회한 뒤 SummaryPop 본문을 추가 수집함. 검색어 적합성으로 결과를 걸러 저장함.
keyword_list.json, raw_kiet_results.json, results.json, keyword_history.json. 파이프라인에서는 선택적 갱신 후 research_context.retrieve로 필요한 시장 근거를 검색해 F01~F04 등에 전달함.
terms는 한국어·영문 키워드와 불용어를 정리하고 QUERY_ALIASES는 개발계획·핵심기술·시장동향·경쟁사의 관련 표현을 확장함. 제목에 맞는 검색어는 4점, 본문에 맞는 검색어는 1점으로 가중하고 같은 점수는 sourceRef 순서로 정렬함. 영어 단어는 경계를 확인하고 한국어 복합어는 부분 표현도 비교함.
검색 결과는 문서 텍스트 SHA-256으로 중복 제거하고 sourceRef에 원본 JSON pointer를 연결함. 발췌는 첫 일치 위치 앞 160자부터 최대 1,100자로 구성하고 excerptOffset·excerptTruncated·matchedTerms를 함께 전달함. 건수와 직렬화된 문맥 문자 수의 두 한도를 적용해 프롬프트 입력을 조절함.
전략 근거
최대 건수
로컬 문맥 문자 예산
시장 근거
4
5,500
경쟁 근거
4
4,500
개발 근거
3
3,000
실행별 KIET 근거는 URL 또는 키워드·제목·본문의 해시로 kiet:run:<해시> 참조를 구성함. merge_market_evidence가 새 자료부터 넣고 sourceRef 중복·문자 예산·4건 한도를 적용함. _DeadlineSession.request는 전체 검색의 남은 시간으로 개별 HTTP timeout을 제한함. 연구·동향 조회와 SummaryPop 수집에 같은 호출 예산을 적용함.
3. F01~F15 공통 전략 실행
F01
F15는 본문을 직접 작성하는 단계가 아니라 F16
F18이 사용할 전략·조사 결과를 준비하는 단계임.
결과는 공통 구조인 canonical에 모은 뒤, 항목별로 필요한 데이터만 작성 단계에 전달함.
F01·F14·F15는 python_functions.py가 검색·계산·일정 행 구성 등 입력을 먼저 준비한 뒤 필요 시 같은 request_json을 호출함.
F01 함수는 매번 로컬 검색을 실행하고, 검색 결과가 있을 때만 모델 해석 요청을 추가함.
Task 작업 지시와 호출 연결
request_json은 함수별 규칙과 payload를 구성하고 calls.send_json으로 전달함. T-C3의 Task 지시문은 system 메시지의 <작업지시> 블록에 추가하고, 함수 입력 JSON은 user 메시지에 둠.
system: 공통 규칙 + F번호별 규칙 + 작성/검증 기준 + 격리된 Task 작업 지시
user: 함수별 입력 payload JSON
→ tools.llm(messages, parse=..., purpose=F번호, json_mode=True)
→ JSON 파싱·필수 배열·본문/명세 계약 검사
지시문과 입력 데이터의 역할을 분리하며, 검증 Task T-V1은 별도 Task 작업 지시 없이 검증 기준을 적용함. F01의 해석은 제공된 sourceRef만 선택하고 F02의 목표 고객 참고값은 원본 사실과 분리함.
3.3 F01~F15 결과 구조와 근거 보존
F01~F15 결과는 공통 구조인 canonical에 모임.
가능한 경우 sourceRefs, evidence, originalFacts, status를 함께 보존함.
_annotate_status는 사실을 provided(확정 입력), proposed(제안값), needs_confirmation(확인 필요)으로 표시함.
조회되는 조사 자료는 사용자 산업 키워드에 따라 달라지며,
sourceRefs와 evidence로 원문 경로·JSON 위치·발췌를 추적함.
이 단계는 별도 조사 기능이 아니라 F01~F15 결과를 canonical에 정리하고, 항목별 작성·검증으로 넘기는 데이터 연결 단계임. 아래 세 부분으로 나누어 설명함.
생성·보존: F01~F15가 canonical 키별 결과를 만들고, 결과에 출처·근거·사실 상태를 붙임.
계보 추적: canonical 표에서 각 키의 생성 함수, 참조 경로, 포함 데이터, 후속 사용처를 확인함. 원문 근거는 연결된 sourceRefs·evidence에서 추적함.
항목별 전달·검증: 항목의 sourceKeys로 필요한 canonical 값만 골라 F16/F17/F18에 전달하고, F19가 같은 근거와 생성 결과를 함께 검증함.
예를 들어 web_data는 조사 자료와 출처를, item_spec은 아이템 요구사항을, development_plan은 개발 목표·내용·산출물·일정 연결을 보관함.
# F01~F15 결과를 모은 공통 데이터
canonical = {
"web_data": {
"sources": [...], "issues": [...]
},
"item_spec": {...},
"market_analysis": {...},
"competitor_analysis": {...},
"development_plan": {...}
}
select_sources(...), generate_section(...), validate_section(...)은 데이터 전달 관계를 설명하기 위한 예시 함수명임.
실제 sourceKeys는 항목 매핑에서 관리하며, canonical 전체가 아니라 지정된 결과만 작성·검증 입력으로 구성함.
실제 근거 구성 경로
section_source(spec, canonical, original, research)는 sourceKeys의 값을 고르고 관련 원본 사실을 originalFacts, 전략 결과의 근거를 strategyProvenance, 조사 자료를 evidence·sourceRefs에 연결함.
strategy_limits와 문서 유형도 함께 전달함.
본문 작성의 compact_prompt_source는 성장전략의 중복 원본·근거 복사본을 줄여 요청 크기를 조절함.
최상위 원본 사실·facts·sourceRefs는 유지하고, 검증에서는 전체 근거를 다시 구성함.
일반현황 2.1.1·3.1.1은 작성과 검증에서 창업아이템명·팀구성현황을 동일하게 추가함.
출력 계약 변환과 수치 토큰
변환 함수
서비스 출력 구성
requirement_analysis
problemStatement=아이템 요약, targetCustomer=F02/아이템 사양, featureList=확정 기능, differentiator=차별성, useCases=산출물 목록
전략 결과의 숫자+원·억·만·%·명·건·개를 수치금액 토큰으로 구성, 같은 값은 count로 집계
sentences
줄·문장 끝으로 본문을 나누고 항목 기반 sentenceId·paragraphNo 부여
marketSize는 현재 빈 목록으로 전달하고 시장 분석의 근거·서술과 구분함. 토큰 추출은 출처·근거 복사본·운영 메타를 제외한 의미 값에서 수행해 같은 자료 복사본의 수치를 반복 집계하지 않도록 구성함.
상태 부여의 대상
_annotate_status는 F02 기능에 coreFeatureStatus를, F06 KPI 목표·핵심기술에 상태를, F08 개발 단계·F09 제품화 단계의 기간에 상태를 부여함.
입력에서 확인한 값은 provided, 비어 있거나 확인 필요인 값은 needs_confirmation, 생성 계획값은 proposed로 구분해 후속 작성·검증에 전달함.
3.4 F16~F18 작성·결과·근거 보존
항목별 section_spec, 매핑된 source_data, 문서 유형별 작성 규칙을 바탕으로 작성함.
생성 출력과 입력 근거는 이 절의 하위 항목에서 보존하며, F19 이후 validation·evaluation·attempts 저장과 상태 분기는 6. F19 검증·결과 저장·상태 분기에서 설명함.
함수
역할
반환 및 후속 처리
F16 generate_section
본문 생성
generatedText, 상태값, 근거 연결을 F19로 전달
F17 generate_table
표 생성
tables·서술문을 반환하고 M-1에서 계획서에 합침
F18 generate_image_spec
USER_FLOW·SERVICE_ARCHITECTURE 이미지 명세 생성
명세를 로컬 SVG로 변환하고 tools.files로 저장. DiagramSpec.imageFile에 FileRef 연결
3.4.1 F16 프롬프트 지시 구성·F17 표·F18 이미지 작성
F16은 모든 항목에 같은 본문 지시만 보내지 않음.
런타임은 공통 JSON·사실성 지침과 문서 유형별 writing_rules.json 규칙을 적용한 뒤, 실행 계약의 해당 항목 section_spec을 입력으로 전달함.
section_spec.title이 항목별 작성 지시이고, section_spec.rules가 문장 수·줄 수·필수 개수 같은 추가 제약임. sourceKeys로 고른 source_data는 작성 근거로 함께 전달하며, 항목별 공고·양식 기준이 있으면 sectionCriteria도 추가함.
아래 표는 실행 계약에서 가져온 F16 전체 항목의 실제 지시임.
title은 항목별 프롬프트 문장, rules는 추가 제약, sourceKeys는 프롬프트에 함께 넣는 근거 데이터 범위임. 공통·유형별 작성 기준은 writing_rules.json에서 관리함.
일반 사업계획서: F16 10개 항목
항목
실제 항목별 지시 (title)
추가 제약 (rules)
근거 (sourceKeys)
1.1.1
3줄 내외의 간략한 서비스의 개요
maxLines: 3
item_spec
1.1.2
기존기술의 문제점 1 2 3 서술
exactItems: 3
market_analysis
1.1.3
관련 시장동향과 이 기술이 시장에 나왔을때 효과 서술
없음
market_analysis
1.2.1
개발 결과물에 최종목표를 적용할 분야, 사용할 기술언어, 주요성능을 넣어 1문장으로 작성.
maxSentences: 1
development_goal
1.2.2
핵심기술 위주 개발될 기능 서술, 이때 표 형태 제시가능.
minItems: 0
development_goal.core_technologies
1.2.3
검증에 필요한 성능지표 5개 이상. 정량적 지표로 작성하되 그렇지못할경우 측정환경을 함께 작성
minItems: 0
development_goal.kpi
1.3.1
1.2.2에서의 핵심기술에 따른 기술개발방법 2줄~4줄과 핵심기술 확보방안 1줄로 작성, 이때 표 형태 제시 가능.
없음
development_method
1.4.1
제품 개발계획을 수요조사, 기획, 개발, 테스트로 나눠 간략히 리스트화.
없음
development_plan
1.4.2
양산 1단계, 양산 2단계, 양산 3단계 각 기능 1줄, 상세계획을 3~5 문장으로 작성.
출력 정리: 제목·항목 번호 반복을 _strip_section_heading으로 정리하고 _normalize_section_output으로 본문·facts·확인 사항을 구성함. sectionOutputs[code]에는 generatedText·facts·sourceRefs·needsUserConfirmation·issues를 보존함.
계획서 문장 구성: 본문을 줄과 문장 끝으로 나눠 PlanSection.sentences에 저장함. 문장 ID는 s-<항목 번호>-<순번>, paragraphNo는 비어 있지 않은 줄 순서로 구성함.
재수행·재작성 입력: 목표 항목의 직전 본문을 previousText로, 직전 issues를 validationFeedback으로 전달함. 사용자 묶음 재작성은 보완 지시를 retryInstruction으로 추가함. 목표 밖 항목은 baseSectionOutputs·basePlanDoc에서 이어받음.
_parse_response는 JSON 객체 파싱을 먼저 시도하고 코드 울타리·주변 문구가 있으면 객체 부분을 정리해 다시 파싱함. issues·tables·sourceRefs·needsUserConfirmation·facts의 배열 형태를 확인하고, F16의 유효한 generatedText와 F18의 노드 계약을 검사함.
visualStyle의 palette·background·accent·cardStyle 등을 로컬 렌더러에서 적용함.
명세 계약 위반은 호출 형식 오류로 재시도함.
SVG 렌더링과 저장: diagram_svg.render가 가로 카드·화살표와 안내문을 포함하는 SVG 바이트를 생성함. tools.files.put으로 저장하고 DiagramSpec.imageFile에 FileRef를 연결함.
flowType
그림 표시 제목
파일명
USER_FLOW
서비스 흐름도
userflow.svg
SERVICE_ARCHITECTURE
서비스 구조도
architecture.svg
이미지 항목의 화면 제목은 이미지·서비스 구조도임.
작성 지시·규칙의 USERFLOW 용어와 내부 식별자 USER_FLOW는 유지함. 생성 명세는 diagramOutputs[code].imageSpecs, 파일 연결은 diagrams에 보존함.
문서 내 SVG 배치: 실구현 그림은 viewBox로 캔버스 비율을 정의함. 테스트 조립의 원페이지·계획서 그림 SVG는 width=1200·height=520·viewBox="0 0 1200 520"을 함께 지정해 웹 문서 내려받기의 그림 비율을 유지함.
다시 생성할 때: 목표 항목의 validationFeedback과 사용자 재작성 보완 지시를 architecture에 전달함. 목표 밖 항목은 직전 명세와 두 DiagramSpec을 이어받음. 재개에서는 성공한 그림 명세를 키별로 재사용함.
SVG 가독성·색상·텍스트 처리
_safe_color는 HEX·rgb/rgba·hsl/hsla 표현을 받아 유효한 색을 적용하고 기본 팔레트와 연결함. _card_text_color는 HEX 카드의 sRGB 상대 명도를 계산해 흰 글자와 짙은 글자(#172033) 중 대비가 큰 색을 선택함. 밝은 카드·어두운 카드의 두 경우를 회귀 테스트로 확인함.
render는 노드 개수로 카드 폭을 나누고 화살표·제목·고지를 배치함. 카드 radius는 0~28 범위로 제한하고 노드 텍스트는 HTML escape로 SVG에 삽입함. 명세의 visualStyle과 본문의 내용·파일 참조를 분리해 같은 렌더링 규칙으로 서비스 흐름도·구조도를 생성함.
3.4.1.4 F16~F18 작성 단계 내부 실패·재시도
작성 중 호출 복구와 검증 결과에 따른 재수행을 다음처럼 구분함. 사용자 선택 묶음 재작성은 7단계에서 설명함.
구분
F16 본문
F17 표
F18 그림
생성 처리
항목별 모델 요청
Python 원본 행 구성
flowType별 모델 명세·로컬 SVG
호출 형식/일시 오류
tools.llm 재시도
로컬 함수 처리
tools.llm 재시도, 파일 저장은 tools.files 정책
생성 자체 검사
응답 계약·본문 정리
필수 컬럼·행 길이 검사
nodes 계약
구조 자체 검사 불통과
응답 형식은 재시도, 내용은 T-V1 대조
즉시 설명문 대체
명세 계약은 재시도
T-V1 fail 재수행
목표 항목 재작성→재검증
같은 표를 재검증
목표 그림 재작성→재검증
검증 재수행 한도 이후
남은 fail을 판정에 보존
fail 표를 설명문으로 대체·fail 유지
남은 fail을 판정에 보존
호출 재시도 기본 횟수는 5회이며 오류 분류·대기 합 상한에 따라 종료함.
형식 오류는 고정 간격, 일시 오류는 늘리는 간격·무작위 지연·Retry-After를 적용함. 입력·운영 오류는 한 번만 시도함. 검증 실패 재수행 기본 한도는 항목마다·사이클마다 1회임.
T-W3의 같은 입력 자체 검사 실패는 그 시도에서 확정 대체 동작을 적용함.
본문·그림 생성과 검증을 재수행하는 경우에는 새 실행·산출물 버전을 기록함.
3.4.2 F16~F18 결과 구조와 생성 산출물 보존
본문·표·그림의 생성 출력은 Task별 산출물에 보존함.
M-1은 이를 planDoc에 합치고 T-V1은 같은 항목 계약·원본 사실·근거를 다시 구성해 검증함.
FormSpec 항목 번호 → execution_contract의 해당 spec
→ sourceKeys로 canonical 값 선택
→ section_source로 원본·출처·전략 provenance·제약 구성
→ T-W1 F16 / T-W2 F18 / T-W3 F17
→ 항목별 생성 출력·PlanSection·TableSpec·DiagramSpec
→ M-1 계획서 합치기
→ T-V1이 같은 항목의 출력·원본 근거를 대조
→ SectionResult.verifiedRef + DocScore
F17은 사용자 원본 표 행을 우선 사용하고, F18은 모델 명세와 렌더링 파일 참조를 함께 보존함.
본문 생성의 프롬프트 압축은 중복 근거만 조절하고 검증 근거는 전체 전략 산출물에서 다시 구성함.
재작성에서는 목표 항목만 새 버전으로 갱신하고 나머지 base 출력·판정은 이어받음.
이 계보를 통해 해당 본문·표·그림이 어느 원본과 어떤 계획서 버전으로 검증되었는지 추적함.
4. 작성 항목 연결 (FormSpec + execution_contract.json)
FormSpec은 항목 번호·화면 제목·태그·종류를 정의함. execution_contract.json은 같은 항목 번호의 functionId·title·displayTitle·sourceKeys·rules를 정의함. 연결 코드가 두 계약을 결합해 양식 순서로 작성·검증함.
writing_prompt는 공통 규칙→유형별 규칙→참고 기준 순으로 합성하고, 항목별 공고·양식 기준을 추가함.
5.1 항목별 F16/F17/F18 작성 및 작성 단계 재시도
작성 구간은 T-W1 본문→T-W2 그림→T-W3 표→M-1 합치기 순서임.
각 Task가 FormSpec의 해당 종류 항목을 선택하고 계약·sourceKeys·유형 규칙을 적용함.
작성 단계
실행 입력과 처리
호출 복구·검증 재수행
T-W1 / F16
section_spec·source_data·writing_rules, 항목별 공고·양식 기준
형식/일시 오류는 tools.llm 재시도, T-V1 fail은 목표 본문 재수행
T-W2 / F18
item_spec·architecture·flowType, 두 명세와 SVG FileRef
명세 계약 오류는 재시도, T-V1 fail은 목표 그림 재수행
T-W3 / F17
원본 tableData·columns·rows·rules, 표·서술문
자체 구조 실패 즉시 설명문 대체, T-V1 fail은 표 재검증 후 필요 시 대체
M-1
planDoc·tables·tableSections·diagrams
표 서술·구조화 표·그림을 양식 순서 계획서에 합침
T-W1은 동시 최대 4, T-W2는 동시 최대 2이며 결과 순서는 양식에 맞춤.
새로 만들 항목은 targetItems와 base 출력 유무로 결정함. 재개 입력의 성공한 항목은 이어받고 빠진 것만 실행함.
작성 단계에서는 생성 출력·원본 근거·파일 참조를 보존하고, 합치기 이후 T-V1에서 전체 또는 목표 항목을 검증함.
검증 실패 재수행과 사용자 선택 재작성의 흐름·횟수는 7단계에서 관리함.
6. F19 검증·결과 저장·상태 분기
T-V1은 작성 Task와 M-1 이후 항목별 F19를 실행함.
먼저 Python으로 본문 구조, 원본 사실·근거, 일정·예산 제약을 확인함.
항목 동시 처리 수는 최대 4이며 순서는 다음과 같음.
F19-1~F19-6은 이 문서에서 검증 처리를 나누어 설명하는 단계 번호임.
실제 진입 함수는 항목별 validate_section이며, Python 기본 검사 이후 필요한 항목에 F19 의미 검증 모델 요청을 연결하고 보정·채점은 로컬 코드에서 수행함.
Python 기본 검사
├─ 문제 발견 → issues 기록, fail 처리, 의미 검증은 생략
└─ 통과 → 규정·공고 기준을 포함한 의미 검증
→ 결과 조정 및 점수 계산
→ pass / warning / fail 저장
검증 대상은 항목 단위로 구성함.
첫 작성: FormSpec의 전체 항목 출력과 원본 근거를 검증함.
검증 실패 재수행: 이번 생성 항목 중 대상 fail 항목만 다시 검증함.
사용자 묶음 재작성: 재작성한 항목을 검증하고 나머지 baseSectionResults를 이어받음.
재개: 성공한 항목 판정은 priorResults에서 이어받고 빠진 항목만 호출함.
표의 사용자 원본 입력 유무와 F19 inputErrorCodes는 연결부에서 inputMissing·inputError로 변환함. 검증 결과는 sectionResults, 원점수는 항목별 score, 문서층 환산값은 docScore에 보존함.
6.1 저비용 구조·계약 검사 (F19-1 · Python)
agent_validation_1/validation_1.py는 LLM에 의미 검증을 요청하기 전에 작성 결과가 기본 형식과 원본 제약을 지키는지 Python으로 빠르게 확인함.
본문: generatedText가 있고, 항목별 exactItems·minItems·maxLines·maxSentences·requiredFields·stages 조건을 지키는지 확인함.
표·이미지: 필요한 표와 필수 컬럼, 이미지 노드 수(3~6개)와 이미지 유형 명세를 확인함.
원본 제약: 해당 항목의 기능 목록, 마감일, 정부지원사업비 상한을 확인함.
위반을 issues로 남기고 fail로 처리하는 흐름을 간단히 나타내면 다음과 같음.
if not text.strip() and not table_only:
issues.append("필수 generatedText 없음")
if missing_columns:
issues.append("필수 표 컬럼 누락")
if deadline_exceeded:
issues.append("마감일 초과")
if issues:
return {"status": "fail", "semanticCalled": False, ...}
표 검사와 원본 입력 확인: Python은 표 존재·필수 컬럼을 검사하고, minItems가 설정된 표 항목은 행 수를 대조함. 원본 rows 또는 미지정 원본 행이 있는 구조화 표는 table_only로 인정함. 빈 사용자 원본은 연결부의 inputMissing 처리로 안내하고 내용 적합성은 해당 항목 기준과 의미 검증에 연결함.
상위 항목 개수와 구조화 표의 검사
F19는 번호 불릿→최상위 기호 불릿→일반 불릿 순으로 상위 항목을 선택해 exactItems를 검사함. 최상위 항목 아래의 세부 '-' 설명을 별도 상위 항목으로 세지 않도록 구성함. minItems는 본문 불릿 수 또는 표 행 수에 적용하고 maxLines·maxSentences·requiredFields·stages를 함께 검사함.
표에 원본 rows 또는 unassignedOriginalRows가 있으면 구조화 표를 검토 내용으로 인정함. generatedText에 표를 문자열로 재복제하지 않아도 표의 columns·rows·rules에서 원본 사실·예산·일정을 대조함. 이미지 항목은 두 flowType과 노드 수·문자열 계약을 확인함.
6.2 원본 사실·근거·상태값 대조 (F19-2 · Python)
F19가 대조하는 입력
originalFacts: 사용자 입력에서 구성한 아이템·기간·팀·수익모델·사업비·일정 원본 사실
strategyProvenance: F01~F15 결과와 그 상위 근거
source_data: 항목의 sourceKeys로 골라 작성 단계에 전달한 자료. evidence와 규정 근거도 포함하며, 의미 검증에도 전달함.
F16 결과에 facts와 sourceRefs가 있으면 원본 사실·상위 근거와 대조함. F17 표와 F18 이미지 명세도 해당 항목 출력과 section_source로 다시 구성한 원본 사실·전략 근거를 연결해 검증함.
상태값별 처리
상태
검증에서의 의미
provided
back 입력 등 원본에서 받은 확정값. 원본과 다르면 fail
confirmed
확인된 확정값. 원본과 다르면 fail
proposed
사업계획을 위해 새로 제안한 값. 완료 사실로 쓰지 않고 계획·목표·제안임을 표시하면 warning
needs_confirmation
사용자 확인이 필요한 값. warning과 needsUserConfirmation 대상으로 기록
제안값에는 이를 뒷받침하는 사용자 원본 근거가 없을 수 있음. F19는 본문에서 계획·목표·제안·확인 필요로 표현했는지 확인함. 이런 표시 없이 확정 사실로 단정하면 오류로 처리함.
sourceRefs가 입력 근거나 적용 규정 출처에 연결되지 않으면 내용과 상태에 따라 출처 오류 또는 확인 경고를 기록함. 같은 원인의 메시지는 중복 제거함.
사실 경로·출처·금액의 세부 대조
_at는 점 경로와 배열 인덱스를 읽고 _fact_at는 partners/equipment/hiring처럼 평탄화된 자원 경로를 resources 아래 원본에 다시 연결함. proposed fact는 제안 경고로 구분하고 provided/confirmed의 원본 불일치는 fail로 처리함. 계획 표현과 생성 경로 중복 접두사는 provenance 확인 경고로 정리함.
허용 출처는 항목 sourceRefs·전략 provenance·적용 규정 sourceRefs의 합집합으로 구성함. 제공되지 않은 출처 참조는 본문의 계획/확정 상태에 따라 fail 또는 출처 확인 warning으로 기록함. 원 단위 금액은 본문에서 추출해 원본·전략 근거의 숫자와 비교하고 제안/예상/계획 금액은 별도 경고로 관리함.
_feature_key·_feature_tokens·_feature_present는 괄호·구분점·공백·등록 동의어·긴 기능명의 핵심 토큰을 정규화해 대조함. 기능 목록 검사는 핵심기술·개발 기능·개발방법·개발계획·양산 등 해당 제목의 항목에 적용하며 KPI/시험지표 항목은 목적에 맞게 별도 검사함. _month_key와 _agreement_duration_months는 월 표기를 통일하고 로드맵을 제외한 협약기간의 시작~종료월을 포함해 개월 수를 계산함.
검증 contentHash는 내용을 정렬한 JSON의 SHA-256으로 구성하고 policyVersion과 연결함. _unique_messages는 같은 문구를 제거하고 _confirmation_items는 사용자 확인이 필요한 경고를 별도 목록으로 구성함.
6.3 규정·공고 자료와 유형별 기준 (F19-3 · LLM 호출)
저비용 검사를 통과한 항목은 다음 기준으로 의미 검증함.
검증 프롬프트에 포함되는 내용
공통 검토 기준: persona, checklist, style guide, 유형별 템플릿, validation_rubric.json
자료 발췌: 문서 유형에 맞는 validation_sources.json과 규정 자료
현재 항목: section_spec, 생성 본문·근거·fact·이미지 정보, source_data, 항목별 기준
참고 자료를 사용하는 방식
자료
검증에서의 역할
공고·관리기준 원문
자격, 협약, 사업비 등 명시 조건 위반 확인
신청 양식
필수 항목과 표 구조 확인
FAQ·과거 자료
기준 해석을 돕는 참고. 현재 확정 사실의 직접 근거로 사용하지 않음
항목별 기준과 관련 발췌는 criteria_registry.json 설정에 따라 선택함.
문서 유형에 따른 검증 차이
예비·초기창업: 연결된 공고·관리기준에서 작성 항목에 적용할 협약기간, 정부지원사업비 상한·집행 비목·합계, 개발·PoC·매출·사업화 단계, 필수 표·항목 기준을 확인함. 실제 신청 자격 판정은 작성 전 G-01 게이트에서 처리함.
일반 사업계획서: rubric에 정부 규정 원문이 연결되어 있지 않으므로 back 입력과 실행 계약을 기준으로 구조·사실·근거 연결을 확인함. 예비·초기창업의 자격·사업비 규정은 적용하지 않음.
공통 제약 확인
_strategy_limits.deadline은 협약기간 일정에 적용하며, 협약 이후 로드맵과 구분함.
supportLimit은 정부지원사업비 상한임.
featureList는 해당 개발 항목에 기능이 보존됐는지 확인함. 기능명은 괄호·구분자·공백·등록된 동의어 차이를 정규화해 비교함.
기준 자료의 관련도와 권위 구분
_writing_criteria와 _regulation_evidence는 sourceMappings의 locatorKeywords 주변에서 최대 두 발췌를 고르고 일치 키워드 수로 high/medium/low 관련도를 구성함. sourceRole·authorityLevel·directFactAllowed·useFor·rationale를 함께 보존해 어떤 항목 목적에 어떤 근거를 적용했는지 추적함.
의미 검증에는 high/medium 관련도 근거를 우선 전달함.
공식 공고·관리기준은 명시 조건, 신청 양식은 구조, FAQ·과거 자료는 해석 보조 역할로 적용함. F19 프롬프트는 issues·warnings·needsUserConfirmation을 각각 최대 8개, 문제 문구는 200자 이내로 정리하도록 요청함. 월·금액·단위·기능 순서의 표현 차이는 정규화된 내용으로 대조함.
6.4 의미 검증 결과 재분류·조정 (F19-4 · Python, 추가 LLM 호출 없음)
저비용 검사를 통과해 의미 검증 결과가 나온 뒤에는 판정을 다음 순서로 정리함.
경고와 실패 구분: 계획·제안·확인 필요, 출처 보완, 시험조건 미확정, 표현 구체화는 상황에 따라 warning으로 분류함. 필수 구조나 확정 사실·마감일·예산 상한 위반은 fail로 남김.semantic_review.py가 문구를 규칙으로 분류하며, 추가 LLM은 호출하지 않음.
if any(marker in text for marker in HARD_MARKERS):
target = hard
elif any(marker in text for marker in ADVISORY_MARKERS):
target = warnings
else:
target = hard
HARD_MARKERS는 필수 누락·원본 불일치처럼 실패로 남길 문구를 찾는 키워드 목록이고, ADVISORY_MARKERS는 근거 보완·제안처럼 경고로 볼 문구를 찾는 목록임.
실제 결과 구조와 대조: _reconcile_validation()이 모델 판정과 저장된 표·이미지를 비교함. 표의 필수 열이나 두 이미지 명세가 이미 있는데 누락으로 지적한 경우, 그리고 F17 일정·예산 표에 모든 featureList를 반복하지 않았다는 지적은 오류 목록에서 제거함.
if spec.get('functionId') == 'F17':
issues = [i for i in issues if 'featureList 누락' not in i]
협약 일정 확인: 초기창업 3.5.2 표의 종료월이 원본 협약 일정의 마지막 달을 넘으면 fail로 추가함. 협약 이후 로드맵은 협약기간 일정과 따로 구분함.
if source_end and generated_end and generated_end > source_end:
validation.setdefault('issues', []).append(
f'개발계획 표 종료월 {generated_end}이 원본 협약 일정 종료월 {source_end} 이후임')
validation['status'] = 'fail'
위 코드는 각 처리의 핵심 부분만 발췌한 것임. 실제 코드는 표·이미지 누락 문구, 검증 상태와 원본 일정 행을 더 확인함.
이 조정이 끝난 결과를 최종 pass·warning·fail 판정과 다음 처리 단계에 사용함.
입력 없음·입력 오류 처리
판정 필드
구조화된 기준
저장·후속 처리
inputMissing
표 원본 행 없음, 예비창업 사업비 단계 미지정 행 존재
issues를 비우고 입력 확인 필요 — 사업비 집행계획/추진 일정 warning으로 기록
inputError
최종 fail이고 inputErrorCodes에 입력 위반 코드 존재
status·issues·점수를 유지하고 입력 오류로 표시
입력 오류 코드는 AGREEMENT_MONTHS_EXCEEDED, AGREEMENT_SCHEDULE_AFTER_DEADLINE, SUPPORT_LIMIT_EXCEEDED임. issue 문구 대신 코드·판정 필드를 읽어 흐름을 결정함. 입력 없음/입력 오류 항목은 검증 실패 재수행·표 대체·해당 항목에 따른 사용자 재작성 후보에서 제외하고 입력 안내에 연결함.
초기창업 3.5.3의 단계 미지정 원본 보존 판정도 담당자 보정 규칙을 적용함. 최종 fallbackReasonCodes에는 표 대체·입력 오류 코드를 합쳐 보존해 안내와 대체 사유를 연결함.
기준표에는 점수 범위(0~100), 평가 항목과 유형별 가중치, 기본 감점, 공식 배점 참고 정보가 들어 있음.
다만 fail 40점은 scoring.py에 고정값으로 적용되고, issue·warning·사용자 확인 필요 감점은 rubric의 penalties 값을 읽어 적용함.
rubric의 fail: 40은 코드의 고정값과 같은 숫자로 선언되어 있음.
6.5.1 rubric 평가 항목과 유형별 가중치
평가 항목
보는 내용
일반
예비·초기
구조 (structure)
필수 본문·항목 수·표 열·이미지 구조
25%
20%
작성 요건 (requirement)
항목 목적과 공고 기준 충족
25%
30%
근거 (provenance)
출처·원본 사실·상태값 추적 가능성
20%
20%
일관성 (coherence)
전략·원본·연관 항목 간 내용 일치
20%
15%
명확성 (clarity)
사실·제안 구분과 문장 가독성
10%
15%
가중치는 공식 배점이나 심사 통계에서 가져온 값이 아니라, 문서 유형별 평가 초점을 반영한 내부 배분임.
일반 유형은 특정 공고의 평가 기준이 고정되어 있지 않아 구조와 작성 요건을 각각 25%로 균형 있게 두고, 전략·원본 간 일관성은 20%로 반영함.
예비·초기 유형은 공고 평가영역과 필수 작성 기준을 맞추는 일을 우선해 작성 요건을 30%로 높임. 근거 추적은 사실 신뢰성에 중요하므로 모든 유형에서 20%로 유지함.
구조·일관성·명확성은 유형별 우선순위에 따라 나머지 비중을 배분함. 필수 구조 위반은 점수 비중과 별도로 F19에서 fail 처리될 수 있어 구조 점수만으로 심각도를 표현하지 않음.
이 비율은 문서 유형별 작성 목적과 검토 우선순위를 반영하는 내부 정책임.
6.5.2 점수 계산 순서와 기본 감점
점수 계산은 다음 순서로 진행함.
각 평가 구성요소를 100점에서 시작함.
F19 판정과 항목별 감점을 해당 구성요소에서 차감함. 기본 감점은 fail 40점, issue 12점, warning 3점, 사용자 확인 필요 2점임.
구성요소 점수에 문서 유형별 가중치를 적용해 합산함.
최종 score, 구성요소별 components, 감점 사유와 값인 deductions를 결과에 저장함.
기본 감점이 어느 항목에서 차감되고 전체 점수에 어느 정도 영향을 주는지는 다음과 같음.
판정
차감 대상
전체 점수에 미치는 대략적 영향
해석
fail 40점
structure; 최종 점수는 최대 59점
가중치 기준 약 8~10점 차감 후 59점 상한 적용
필수 위반이 높은 점수로 통과처럼 보이지 않게 함
issue 12점
requirement 또는 provenance
약 2.4~3.6점
필수요건·근거 결함을 보완 경고보다 크게 반영
warning 3점
provenance 또는 clarity
약 0.3~0.6점
개선 신호를 남기되 제안·표현 보완의 영향은 작게 제한
사용자 확인 필요 2점
clarity
약 0.2~0.3점
사실 오류와 구분해 가볍게 반영하고 사용자 결정 과제를 표시
감점은 구성요소 점수에 적용한 뒤 유형별 가중치로 합산함.
동일 문구는 중복 차감하지 않으며, 감점 후 구성요소 점수는 0점 아래로 내려가지 않음.
일관성(coherence)은 rubric의 평가 성분으로 가중 평균에 포함함. 현재 감점 분류는 structure·requirement·provenance·clarity에 적용하며, 전략·원본·항목 간 불일치 진단은 그 내용에 맞는 검증 문제와 감점 사유로 연결함.
6.5.3 감점 간격을 둔 이유
fail 40점: 필수 구조·확정 사실 위반의 심각도를 반영하고, 별도 59점 상한으로 다른 구성요소의 높은 점수가 항목 실패를 가리지 않게 함.
issue 12점: 필수요건·근거의 실질적 결함을 가벼운 보완 의견보다 뚜렷하게 반영하도록 warning 3점의 네 배로 설정함.
warning 3점: 결과 저장은 가능하지만 보완이 필요한 상태이므로 점수에 작은 개선 신호를 남김.
사용자 확인 필요 2점: 사용자 판단이 필요한 상황 자체를 확정 사실 오류처럼 취급하지 않도록 가장 낮은 감점으로 둠.
40·12·3·2는 필수 위반→실질적 결함→보완 경고→사용자 확인의 심각도 순서를 표현하는 내부 정책값임.
6.5.4 공고 평가영역과 내부 점수의 관계
먼저 볼 점수의 의미
F19의 evaluation.score와 estimatedPoints는 이 시스템의 내부 품질 점수임. 평가위원의 실제 점수나 선정 가능성을 예측하는 공식 점수가 아님. 2026년 공고가 평가영역을 공개하더라도 사업계획서 항목별 세부 배점은 제공하지 않아, 현재 가중치와 감점값을 공식 배점에서 산출할 수 없음.
공고에서 확인되는 공식 평가 기준
2026년 모집공고에서 확인되는 평가영역과 공개되지 않은 점수 정보는 다음과 같음.
유형
공고에서 명시한 기준
공고에 제시되지 않은 점수 정보
예비창업패키지
문제인식·실현가능성·성장전략·팀(기업) 구성. 중기부 제2026-207호(2026-03-24)
평가영역별·사업계획서 항목별 점수 배분
초기창업패키지 일반형
문제인식·실현가능성·성장전략·팀(기업) 구성. 중기부 제2026-38호(2026-01-23)
공고의 평가영역은 예비·초기 유형의 검토 초점을 정하는 참고 기준으로 사용함. 다만 평가영역별·사업계획서 항목별 점수가 공개되지 않아 내부 가중치와 감점값의 직접적인 수치 근거로 삼을 수 없음. 일반 사업계획서는 연결된 특정 정부 공고가 없어 내부 계약을 기준으로 평가함.
점수 보정과 성과 측정
가중치·감점의 개선은 동일 계획서 표본에 대한 전문가 항목 평가와 내부 채점 결과를 함께 비교해 검토함. 문서 유형·항목·문제 종류별로 평가 자료를 묶고, 원점수·문서층 환산점수·최종 수용 상태를 구분해 기록함. 재작성 전후 비교는 같은 입력과 기준에서 수행하고 측정 기간·표본 수를 함께 제시함.
6.5.5 별도 제약 감점과 문서층 환산
일정·지원금 제약 감점
F19의 AGREEMENT_SCHEDULE_AFTER_DEADLINE 코드가 있으면 requirement에서 40점을 차감함. 협약기간 일정에 적용함.
F19의 SUPPORT_LIMIT_EXCEEDED 코드가 있으면 requirement에서 50점을 차감함.
두 감점은 사업계획의 실행 가능성과 예산 준수에 직접 영향을 주므로 requirement에서 별도로 차감함.
일정 초과 40점: 협약기간 안에 계획을 이행하기 어려운 중대한 요건 위반으로 반영함.
지원금 상한 초과 50점: 신청 가능한 사업비 한도를 벗어나므로 일정 초과보다 더 큰 감점을 둠.
두 수치는 공식 배점이나 실제 심사자료에서 산출된 값이 아니라 내부 심각도 정책값임.
같은 위반이 검증 fail 또는 issue에도 기록되면 감점이 누적될 수 있음. 이 경우 deductions에서 사유별 차감 내역을 확인해야 하며, 중복 적용은 같은 결함의 점수 영향을 키울 수 있음.
공식 배점과 내부 점수
officialExpectedScoring은 공고 평가영역과 필수조건을 참고 기준으로 제공하지만, 공식 항목별 배점표는 아님.
따라서 officialPoints는 null로 저장함. 계산된 값은 estimatedPoints의 내부 예상 배점으로 표시하고, isOfficial은 false로 기록함.
신뢰도는 예비·초기 유형 medium, 일반 유형 low임. 이 구분도 공식 점수의 신뢰도가 아니라 참고할 공고 기준의 유무를 나타냄.
documentLayerScore는 F19 내부 품질 점수를 70점 만점으로 환산한 값임. fail의 59점 상한도 내부 상태 표현 규칙이며, 정부기관의 공식 심사 점수나 합격선을 재현하지 않음.
항목 원점수와 문서층 환산
T-V1이 score_section을 직접 호출해 원점수 0~100을 구함.
이 원점수를 실행 설정의 문서층 배점과 전체 항목 수로 환산함.
D = settingsSnapshot.scoring.docLayerMax (기본 70)
N = 전체 검증 항목 수
항목 환산점수 = round(항목 원점수 × D / 100 / N, 2)
문서층 총점 = 반올림된 항목 환산점수의 합
값
의미
저장 위치
score
담당자 rubric 항목 원점수 0~100
SectionResult.score
문서층 항목 점수
원점수를 D와 N으로 환산
DocScore.items[].score
문서층 총점
항목 환산점수 합
DocScore.total
표시 점수
문서층 총점 / D × 100, 소수 첫째 자리
G-02a ScoreReport.displayScore
담당자 반환의 documentLayerScore(원점수×0.7)는 원점수와 구별해 관리하고 서비스에서는 원점수에서 문서층 배점으로 한 번 환산함. varianceFlag의 반환값은 false임.
G-02a는 문서층 표시 점수를 기준점(기본 80)과 비교함. G-02b는 문서층과 코드 점검·계획서 대조의 환산점수를 합산함. 기본 배점은 문서층 70·코드 점검 15·계획서 대조 15이며 실행 설정을 따름.
환산 예시: 예비창업 25개 항목의 원점수가 각각 90점이고 D=70이면 항목 환산점수는 2.52점, 문서층 총점은 63/70점, G-02a 표시 점수는 90/100점임.
문서 평가 기준점 80은 이 표시 점수와 비교함. G-02b는 이후 산출물층 점수를 문서층 63점에 더해 종합 판정함.
채점 추적성과 사유 보존
score_section은 구성요소별 점수·가중치·감점 목록·기준 파일 가용 상태·공고 기준 발췌를 함께 구성함. issues·warnings·확인 목록의 동일 사유는 한 번 차감하고 본문 없음·평가 기준 파일 없음·제약 형식 해석 문제도 각각의 사유로 보존함. evaluationHash는 항목 계약·생성 결과·검증 결과를 정렬한 JSON 해시로 계산해 정책 버전과 연결함.
T-V1의 문서층 합계는 소수 둘째 자리로 반올림한 항목 점수를 Decimal로 합산함. 목표 항목 밖 판정은 verifiedRef를 포함해 그대로 이어받고 전체 DocScore는 다시 계산함. 검증 근거·감점·항목 판정·환산점수를 연결해 점수 변화의 원인을 확인할 수 있게 구성함.
사용자 묶음 재작성 후보는 묶음에 속한 fail·warning 항목을 기준으로 만들고 입력 없음/입력 오류 항목은 후보 사유에서 제외함.
status와 warnings 목록은 각각 보존함. 기본 검사·의미 검증을 통과한 pass 항목에도 확인·보완 경고가 함께 기록될 수 있음. 표 입력 없음은 연결부에서 warning 상태로 바꾸고, 판정 보정은 최종 issues·warnings에 맞춰 상태를 조정함. 재수행·묶음 후보 판단은 저장된 최종 status와 입력 상태 필드를 기준으로 처리함.
재수행이 끝나면 G-02a가 문서층 표시 점수·재작성 후보·남은 기회로 진행가능/재작성권유/상한도달을 결정함. 사용자는 평가와 보완 내용을 확인하고 묶음 재작성 또는 다음 단계 진행을 선택함.
확인·권유는 평가 기준점과 다음 행동을 기준으로 구성함. 남은 fail은 항목별 미달로 표시하고, 사용자가 진행을 선택하면 후속 검수·통합·내려받기에 같은 판정과 점수를 전달함. 설명문으로 대체한 표도 fail 상태를 유지함.
6.7 판정 저장과 후속 경로 분기 (Python)
T-V1은 각 항목의 검증·채점 결과를 SectionResult로 구성하고 전체 문서층 점수를 DocScore로 반환함.
