Beacon: 검사 보고서를 작업 지시서로 변환하기

_이 글은 Hacktoberfest Weekend Challenge: Build for a Friend 제출물입니다.

제가 만든 것 (What I Built)

저는 기계 공장 유지보수 분야에 막 취업한 친구가 겪을 수 있는 문제에 착안하여 'Beacon'을 만들었습니다. 검사 결과는 PDF 형태로 도착하지만, 누군가가 이를 유용한 후속 조치로 변환해야 하는 상황입니다.

Beacon은 검사 보고서를 읽고 그 내용을 추출하며, 브라우저 제어(browser control)를 사용하여 별도의 유지보수 앱에 작업 지시서(work order)를 작성합니다. 작동자는 제출 전에 확인 요청을 받고, 저장된 작업 지시서를 점검합니다. 이 유지보수 앱은 합성 데이터(synthetic data)를 사용하며 로컬에서 실행됩니다. 이는 실제 공장과 연결된 소프트웨어는 아니며, 작동 가능한 데모입니다.

아키텍처 (Architecture)

데모 스냅샷 (Demo Snapshot)

코드 (Code)

Beacon on Github

제작 과정 (How I Built It)

Beacon의 채팅 앱은 Next.js, React, TypeScript를 사용합니다. 에이전트(agent)는 Eve에서 실행되며, 각 채팅마다 별도의 Eve 세션과 작업 공간을 가집니다. 저는 Vercel AI SDK와 여기에 포함된 OpenAI 및 OpenAI 호환 제공업체 패키지를 사용하여 에이전트를 모델에 연결합니다.

오픈 웨이트(open-weight) 모델 경로의 경우, Beacon은 자체 호스팅된 Qwen 3.8 27B Max 엔드포인트에 연결됩니다. 모델 선택기에서는 OpenCode Go를 통해 호스팅되는 모델도 제공합니다. 검사 PDF의 경우, 에이전트는 문서를 사설 PaddleOCR-VL 서비스로 전송한 다음, 추출된 내용을 근거(evidence)로 사용하여 작업 지시서를 작성합니다.

앱과 에이전트 런타임은 Bun을 사용하여 로컬 장치에서 실행될 수 있습니다. 추론(inference)도 로컬로 실행하려면, OpenAI와 호환되는 API를 노출하고 Qwen 모델을 제공하는 로컬 서버를 가리키도록 QWEN_BASE_URL을 설정하십시오. 완전한 로컬 문서 워크플로우를 위해서는 OCR 서비스 또한 로컬에서 실행되어야 하며, 호스팅된 모델 대신 Qwen 엔드포인트를 선택해야 합니다.

Open Innovation이 중요한 이유?

오픈 웨이트(open-weight) 모델은 추론이 어디서 실행될지 저에게 선택권을 줍니다. 구축하는 동안 호스팅된 모델을 사용하거나, 제가 제어하는 엔드포인트 뒤에서 Qwen을 실행할 수 있습니다. OpenAI와 호환되는 인터페이스는 Beacon이 자신의 에이전트 코드를 특정 모델 제공업체에 종속시키지 않으면서 해당 엔드포인트에 연결할 수 있게 해줍니다.

이는 검사 문서의 경우 중요합니다. 만약 모델과 OCR 서비스가 로컬에서 실행된다면, 보고서는 운영자(operator)의 장치에 머무를 수 있습니다. 현재 설정은 호스팅된 모델도 지원하므로, 로컬 처리는 로컬 엔드포인트를 구성하고 선택하는 것에 달려 있습니다.

수상 부문

GitHub Copilot 활용 최고: GitHub Copilot이 가장 유용했던 점은 Beacon을 아이디어에서 작동하는 엔드투엔드(end-to-end) 프로젝트로 만드는 것을 도와주었다는 것입니다. 이는 채팅 앱, Eve 에이전트, 모델 제공업체, 검사 보고서 파싱, 브라우저 제어를 하나의 워크플로우로 연결하는 데 도움을 주었습니다. 제가 가장 가치 있다고 느낀 부분은 보고서의 발견 사항에서 작업 지시서(work order)로 넘어가는 과정을 구상하고 테스트한 것이었으며, 에이전트가 제출하기 전에 승인을 요청하고 나중에 주문이 저장되었는지 확인했습니다. Copilot이 구현 속도를 높여주었지만, 여전히 제품 결정을 내리고 조각들이 함께 작동하는지 검증해야 했습니다.

**@parthlightning의 단독 출품