FB208/OpenBidKit_Yibiao 딥다이브
— AI가 10만~100만 자 입찰서(標書)를 써 내려가는 오픈소스 데스크톱 에이전트

1프로젝트 한 줄 요약

FB208/OpenBidKit_Yibiao(중국어명 易标投标工具箱, "이뱌오 입찰 도구상자")는 기업이 입찰(招投標)에 낼 기술제안서·상용제안서 같은 "표준 입찰서(標書)"를 AI로 자동 작성해 주는 오픈소스 데스크톱 애플리케이션이다. 저장소가 내건 한 줄은 이것 — "开箱即用-开源免费AI标书编写工具"(개봉 즉시 쓰는, 오픈소스·무료 AI 입찰서 작성 도구).

동작의 큰 그림은 "공고문 한 부 → 완성된 입찰서 한 부"다. 사용자가 초대·공고 문서(招標文件)를 넣으면, 앱이 ① 프로젝트 개요와 기술 평가(배점) 요구를 뽑아내고 → ② 그 배점에 맞춘 입찰서 목차(3단 트리)를 만들고 → ③ 목차의 말단(잎) 노드마다 본문을 병렬로 채우고 → ④ 적절한 곳에 표·Mermaid 도표·AI 삽화를 배치하고 → ⑤ 전부 이어 붙여 Word(.docx)로 내보낸다. 이 과정에서 회사 자료를 담아 둔 지식베이스를 재료로 쓰고, 다 쓴 뒤엔 표절 검사(査重)와 폐찰(廢標) 위험 항목 검사까지 돌려 준다.

2왜 지금 주목받는가

OpenBidKit이 트렌딩에 오른 힘은 두 겹이다. 표층은 "유료 입찰서 AI가 비싸다"는 명확한 페인포인트를 오픈소스로 정면 공략했다는 점이고, 심층은 개발자가 제작 과정을 7편의 기술 연재로 공개해 "어떻게 만들었나"가 통째로 드러난다는 점이다. 후자가 이 저장소를 단순 앱이 아니라 LLM 엔지니어링 교재로 만든다.

주목 포인트 1 — "장문 생성"이라는, 챗봇과 다른 전장

일반 챗봇은 몇 백~몇 천 자 답을 낸다. 입찰서는 수십만 자다. 이 스케일에선 완전히 다른 문제가 튀어나온다 — 앞 장과 뒤 장이 서로 모순되고("우리 팀은 5명" vs 뒤에서 "8명"), 목차 JSON이 한 번만 깨져도 전체 파이프라인이 멈추며, 같은 공고문을 매 장마다 다시 넣느라 입력 토큰 비용이 폭발한다. OpenBidKit의 설계 대부분은 바로 이 "장문 3대 난제(일관성·안정성·비용)"를 푸는 데 바쳐져 있다.

주목 포인트 2 — 코드 + 연재 글이라는 "이중 교재"

저장소 안 文章/ 폴더에는 "标书智能体(입찰서 에이전트)" 연재 1~7편이 마크다운으로 들어 있다. 각 편이 실전 주제를 정면으로 다룬다 — 공고문 파싱, 목차 생성, 본문 생성, 프롬프트 순서·캐시(비용 10배↓), 약한 모델 복잡 JSON 안정화, 초장문+도표 제어, RAG 없는 지식베이스. 개발자 스스로 "vibe coding 시대엔 코드보다 문제를 푸는 사고(프롬프트·워크플로·에이전트 설계)가 중요하다"고 못박는다. 즉 이 저장소는 "무엇을 만들었나"보다 "어떻게 사고했나"를 배우기에 좋다.

3기술 스택 전체 지도

OpenBidKit은 전형적인 Electron 이중 구조다. 렌더러(renderer)는 사용자가 보는 화면으로 React 19 + TypeScript + Vite 7이 담당하고, 메인(main) 프로세스는 화면 뒤의 무거운 일 — 파일 파싱, AI 호출, SQLite 저장, 장시간 작업 관리 — 을 Node.js(.cjs 모듈)로 처리한다. 둘은 IPC 브리지(window.yibiao)로만 대화한다. 이 분리를 이해하면 코드 전체가 한눈에 잡힌다.

렌더러 — React 19 기능 슬라이스(feature-sliced)

UI는 client/src/ 아래 기능(feature) 단위로 잘려 있다. 입찰 워크플로의 각 단계가 곧 하나의 폴더다. 공통 부품(AI 클라이언트·프롬프트·마크다운·UI·타입)은 shared/에 모여 있다.

메인 — 파싱·AI·저장·작업의 엔진실

메인 프로세스(client/electron/)가 진짜 무게중심이다. 문서를 마크다운으로 바꾸고, AI를 부르고, SQLite에 쓰고, 오래 걸리는 작업을 관리한다.

패키징 · 벤더링된 OpenCode

배포는 electron-builder로 Windows(NSIS·zip)·macOS(dmg, x64+arm64) 설치본을 굽는다(appId: com.yibiao.openbidkit). 특이점은 extraResources로 OpenCode 런타임을 통째로 벤더링(vendor/opencode)한다는 것 — 즉 이 앱은 내부에 코딩 에이전트 엔진을 하나 품고 있다(§4에서 상술).

4아키텍처 심화 분석

OpenBidKit의 심장은 단계별 작업(Task) 파이프라인이다. 각 단계가 electron/services/의 독립 서비스이고, 결과는 로컬 SQLite와 파일에 낙점(落點)돼 페이지를 옮겨도 진행이 복구된다. 아래가 전체 흐름이다.

이 파이프라인을 떠받치는 세 가지 핵심 설계를 뜯어보자.

설계 ① 낙점 가능한 작업(Task) 엔진 — "끊겨도 이어서"

입찰서 생성은 수십 분씩 걸리는 장시간 작업이다. 그래서 각 단계(*Task.cjs)는 진행 상태를 SQLite에 계속 낙점한다. taskService가 이들을 관리하고, SQLite 스키마의 PRAGMA user_version = 17이 말해 주듯 17차례의 마이그레이션을 거치며 "다중 표단(標段)", "다중 공고문", "전문 삽화 편성" 같은 기능이 점진적으로 쌓여 왔다. 원문(공고문 마크다운)은 SQLite에 넣지 않고 userData/workspace/ 파일로 두고, DB엔 경로·해시·글자수만 저장하는 "큰 텍스트는 파일, 메타는 DB" 분리가 인상적이다.

설계 ② 장문 일관성 — 목차 잎 노드 병렬 + 전역 사실 앵커

본문은 목차 트리의 말단(잎) 노드 단위로 병렬 생성된다(contentGenerationTask). 병렬로 쓰면 빠르지만 장끼리 모순이 생기기 쉽다. 그래서 먼저 globalFactsTask가 전역 사실(회사 규모·프로젝트명·핵심 수치 등)을 뽑아 앵커로 삼고, 각 노드 생성 시 이 앵커를 함께 주입해 앞뒤 일관성을 붙든다. 삽화도 "본문 다 쓰고 나서"가 아니라 본문 생성 전에 미리 편성(预编排)한다 — 어느 노드에 표/Mermaid/AI그림을 넣을지 점수를 매겨 상위 몇 개만 고르는 식이라, 비용이 예측 가능하고 그림이 앞 장에만 몰리지 않는다.

설계 ③ 벤더링된 OpenCode 런타임 — 앱 속의 에이전트 엔진

electron/services/opencode/는 OpenCode(코딩 에이전트)를 로컬 런타임으로 감싼 층이다. opencodeServerRunner가 프로세스를 띄우고, aiServiceOpenAiProxy가 OpenAI 호환 프록시로 붙으며, opencodeIsolationService가 격리, opencodeSelfCheckService가 자기 점검(自检)을 담당한다. 즉 OpenBidKit은 "입찰서"라는 도메인 로직을, 검증된 에이전트 런타임 위에 얹은 셈이다. §6-②의 "약한 모델 JSON 안정화"가 OpenCode의 자기반성·교정(self-reflection) 기법을 차용한 것도 이 통합 덕이다.

5디렉토리 구조 해부

저장소는 앱 코드(client/)와 문서·자료가 명확히 갈린다. 특히 文章/(문장) 폴더는 이 저장소를 교재로 만드는 핵심이니 꼭 열어 보자.

이 저장소를 읽을 때 지적 핵심은 세 곳이다 — 文章/(왜·어떻게 사고했나), client/electron/services/(그 사고가 코드로 어떻게 구현됐나), client/src/shared/prompts/(실제 프롬프트 본문).

6학습 포인트 — LLM 엔지니어링 4대 노하우

OpenBidKit이 학습 표본으로 값진 이유는, "챗봇을 넘어 진짜 장문 LLM 애플리케이션을 만들 때 반드시 만나는 문제들"을 정면으로 풀고 그 과정을 글로 남겼기 때문이다. 아래 4개는 입찰서와 무관하게 모든 LLM 앱 개발자에게 전이되는 노하우다.

① 프롬프트 "순서"로 입력 비용을 10배 줄인다 (Prompt Cache)

가장 반직관적이면서 강력한 교훈이다. 대부분의 모델 서비스사는 Prompt Cache(프롬프트 캐시)를 지원하는데, "내용이 같으면" 캐시되는 게 아니라 "요청의 앞부분(prefix)이 같으면" 캐시된다. 그래서 매번 바뀌는 지시문을 앞에, 안 바뀌는 긴 원문(공고문)을 뒤에 두면, 같은 공고문이어도 캐시를 못 타 돈이 새어 나간다.

OpenBidKit은 같은 공고문을 두 번 분석한다(개요 추출 + 배점 추출). 그래서 긴 공고문을 프롬프트 앞에 고정하고, 분석 종류 같은 가변 지시는 뒤로 밀어 캐시 프리픽스를 안정화했다. 결과 — 입력 비용 최대 10배 절감.

# 나쁜 예 — 가변 지시가 앞, 긴 원문이 뒤 → 프리픽스가 매번 달라 캐시 미스
[system] "개요를 추출하는 지시..."          # 분석마다 다름
[user]   "다음 공고문을 분석: {아주 긴 원문}"   # 뒤에 있어 캐시 못 탐

# 좋은 예 — 안 바뀌는 긴 원문을 프리픽스로 고정, 가변 지시는 뒤로
[system] "당신은 공고문 분석가다. 원문은 아래와 같다:\n{긴 원문}"  ← 안정 프리픽스(캐시 명중)
[user]   "이번엔 '기술 배점 요구'만 추출하라"    # 짧은 가변 지시

② 약한 모델도 복잡한 JSON을 안정 출력하게 — "프롬프트가 아니라 워크플로"

입찰서 목차는 3단 중첩 JSON이고, 이 JSON이 한 번 깨지면 뒤의 모든 단계(본문·캐시·편집·Word)가 멈춘다. 값싼/약한 모델에 맡기면 쉼표 누락, markdown 코드블록으로 감싸기, 설명문 섞기, 필드명 오타(children→child), 2단만 생성 등 실패가 "운(運) 뽑기"처럼 터진다.

핵심 통찰 — "프롬프트는 첫 성공률만 올릴 뿐, 진짜 안정성은 워크플로가 만든다." OpenBidKit은 목차 생성을 단일 호출이 아니라 다단계 방어 루프로 짰다(OpenCode의 자기반성·교정 차용).

shared/prompts/jsonRepairPrompts.ts의 수리 프롬프트는 아주 구체적이다 — "너는 엄격한 JSON 수리 도우미다. 1\. 같은 불법 역슬래시 이스케이프를 1.로 고치고, 보존해야 할 역슬래시는 \\로 써라. 설명 없이 수리된 완전한 JSON만 반환하라." 이 "생성-검증-수리-재시도-분할-심사-재생성" 패턴은 어떤 구조화 출력 LLM 앱에도 그대로 쓸 수 있는 골든 템플릿이다.

③ 초장문(10만~100만 자)을 일관성 있게 — 잎 노드 병렬 + 전역 사실 + 삽화 선편성

수십만 자를 한 번에 생성할 순 없다. OpenBidKit은 목차 잎 노드마다 나눠 병렬 생성하되, 병렬이 부르는 모순을 두 장치로 막는다 — ① globalFactsTask가 뽑은 전역 사실을 모든 노드에 앵커로 주입해 앞뒤가 어긋나지 않게 하고, ② 지식베이스 소재도 어느 노드에 쓸지 미리 배정한다.

삽화는 더 영리하다. "본문 다 쓰고 어디에 그림 넣지?"라고 나중에 정하면 (a) 100만 자를 AI가 다시 읽어야 하고(토큰 낭비) (b) 그림 수가 통제 불능이 된다. 그래서 OpenBidKit은 본문 생성 전에 전체 목차를 훑어 "이 소절에 표/Mermaid/AI그림이 적합한가 + 우선순위 점수"를 미리 편성(预编排)하고, 점수 상위 노드만 골라 그림을 생성한다. 덕분에 비용이 예측 가능하고, 그림이 앞 장에만 몰리지 않으며, 본문이 "여기 뒤에 그림이 온다"를 미리 알아 표현이 자연스러워진다.

④ "당신에겐 RAG가 필요 없다" — 롱컨텍스트 + 캐시로 지식베이스

연재 7편의 도발적 제목이다. 전통적 지식베이스는 RAG(문서를 벡터로 쪼개 검색해 일부만 주입)를 쓴다. OpenBidKit의 접근은 다르다 — 모델의 거대한 컨텍스트 창(코드 기본값 DEFAULT_CONTEXT_LENGTH_LIMIT = 400000 자, 그 80%까지 사용)에 지식베이스를 통째로 넣고, ②에서 본 프롬프트 캐시로 그 비용을 죽인다.

벡터 검색의 "관련 조각을 잘 못 찾는" 문제도, 청킹 경계에서 문맥이 잘리는 문제도 없다. 대신 문서가 컨텍스트 한계를 넘으면 splitUserTextByContextLimit로 나누고, 과대 블록(8000자)·의미 병합 목표(500자) 같은 파라미터로 조율한다. "컨텍스트가 충분히 크고 캐시가 싸다면, 검색(RAG)보다 통째로 넣기가 낫다"는 이 관점은 롱컨텍스트 시대의 실전 설계 선택지로서 배울 가치가 크다.

7시스템 요구사항 · 설치

OpenBidKit 자체는 무겁지 않다 — 문서를 파싱하고 AI를 호출하는 앱이라 특별한 하드웨어가 필요 없다. 무거운 연산(모델 추론)은 외부 API나 로컬 Ollama가 담당한다. 두 가지 사용 경로가 있다.

# 경로 A) 그냥 쓰기 — Releases에서 설치본 다운로드
#   GitHub Releases의 Windows(.exe/NSIS) 또는 macOS(.dmg) 설치
#   앱 설정에서 모델 공급자(GPT/DeepSeek/火山方舟/OpenAI호환/Ollama) + API 키 입력

# 경로 B) 소스로 개발·빌드 (client/ 안에서)
git clone https://github.com/FB208/OpenBidKit_Yibiao && cd OpenBidKit_Yibiao/client
npm install
npm run dev          # Vite(5173) + Electron 동시 실행(핫리로드)
npm run dist:win     # Windows 설치본 빌드 (또는 dist:mac)

8직접 해볼 수 있는 실습 과제

9관련 기술 심화 학습 로드맵

10핵심 키워드 사전

11참고 링크

저장소 & 배포
· GitHub: github.com/FB208/OpenBidKit_Yibiao (AGPL-3.0, 클라이언트 v0.1.0)
· 미러(Gitee): gitee.com/yibiao-ai/OpenBidKit_Yibiao · 설치본은 GitHub Releases에서
· DeepWiki(자동 문서): deepwiki.com/FB208/OpenBidKit_Yibiao

공식 사이트
· 온라인 체험·제품 정보·기술 지원: yibiao.pro

저장소 내 핵심 코드/문서
· 文章/(연재 1~7편, LLM 노하우) · client/electron/services/(outlineGenerationTask·contentGenerationTask·globalFactsTask·knowledgeBaseService·opencode/) · client/src/shared/prompts/(outlinePrompts·jsonRepairPrompts·analysisPrompts) · sql/workspace_schema.sql

상위 개념 · 함께 볼 것
· Electron(electronjs.org) · Prompt Caching(각 모델사 문서) · MinerU(문서 파싱) · Mermaid(mermaid.js.org) · OpenCode(코딩 에이전트 런타임)