실장 서비스에 적용하는 실패 폐쇄형 쓰기 게이트가 있는 AI 에이전트
요약
Foreman+는 현장 서비스 기술자를 위한 AI 에이전트 군단으로, 사진과 음성 설명을 작업 기록으로 변환합니다. 이 시스템의 핵심은 '쓰기 게이트(write-gate)'로, 모든 사실 정보가 저장되기 전에 검증을 거쳐 정확성을 보장합니다. 이는 기존의 비체계적인 현장 기록 문제를 해결하는 데 중점을 둡니다.
핵심 포인트
- AI 에이전트 군단으로 현장 서비스 기술자를 지원합니다.
- 사진/음성 설명을 작업 기록(작업 로그)으로 변환합니다.
- 쓰기 게이트를 통해 모든 사실 정보의 정확성을 검증합니다.
- Google ADK 기반이며, 실시간 작동하는 것이 특징입니다.
Mikhail Oskola 작성, Retailbox Automation 설립자.
Foreman+는 현장 서비스를 위한 AI 에이전트 군단입니다. 기술자가 장비 명판을 사진으로 찍고 휴대폰이나 카메라 글래스에서 문제점을 소리 내어 설명합니다. 세 개의 Google ADK 에이전트가 이를 추정치가 포함된 작업 기록으로 변환하며, 모든 사실은 군단이 기억하기 전에 쓰기 게이트(write-gate)를 통과해야 합니다. 만약 이 게이트 자체의 검증기가 실패하면, 쓰기는 거부됩니다. 이는 Google의 All Things Agentic 해커톤에 제출한 저희의 작품이며, 공개적이고 MIT 라이선스이며 실시간으로 작동합니다.
문제점: 아무도 확인하지 않는 숫자, 누구도 기억하지 못하는 방문 기록
온수기 출장 사례를 상상해 보세요. 기술자가 명판을 읽고 가격을 견적한 후 떠납니다. 그 견적은 그의 머릿속이나 문자 메시지에 남아 있습니다. 몇 주 후에 다른 기술자가 재방문하여 처음부터 다시 시작해야 합니다: 무엇이 진단되었는지, 무엇이 견적되었는지, 집주인이 실제로 뭐라고 말했는지.
여기에 AI 에이전트를 배치한다고 해서 기본적으로 문제가 해결되는 것은 아닙니다. 에이전트는 자신이 들은 모든 것을 기꺼이 파일에 저장할 것이며,
캡처 경로는 사진과 음성 메모를 일반 파일(plain files)로 받기 때문에, 무엇으로 기록했는지는 신경 쓰지 않습니다. 오늘날 주된 경로는 휴대폰입니다. 기술자는 방문 전에 모바일 브라우저에서 해당 자산에 대한 브리핑을 받고 작업을 시작하며, 이후 사진 촬영과 홀드-투-토크(hold-to-talk) 방식으로 진행합니다. 동일한 입력 방식은 Mentra Live 카메라 안경에도 연결되어 있어, 기술자가 도구를 내려놓지 않고도 작업을 기록할 수 있습니다. 안경에서 '전송(send it)'이라고 말하면 작업이 제출되고, 응답은 하나의 일반 문장으로 읽어집니다: 장비가 기록되었는지, 게이트가 몇 개의 사실을 승인했는지, 그리고 예상 견적입니다.
방문 전 휴대폰의 기술자 작업 공간: 플릿(fleet)이 이미 알고 있는 정보, 출처가 명시된 각 항목. 샘플 작업 공간, 가상의 이름.
세 개의 에이전트, 하나의 메모리, 하나의 게이트
이 플릿은 Google의 Agent Development Kit을 기반으로 구축된 세 개의 에이전트로 구성되어 있습니다. 현장 감독관(foreman)은 보고된 내용을 기록하고 인계합니다. 견적가 산정자(estimator)는 예상 견적서를 작성하기 전에 전체 플릿의 메모리에서 유사한 과거 장비 및 문제점을 검색합니다. 클로저(closer)는 절대로 메모리를 작성하지 않습니다. 대신 검증된 사실을 읽고, LLM 호출 없이도 마감 문서를 작성하며, 다음 담당자에게 브리핑합니다. 또한 이 에이전트는 A2A 프로토콜을 통해 플릿 외부에도 노출되어 있어, 현장 서비스 관리 시스템(field service management system), 주택 보증 승인 기관(home-warranty authorizer) 또는 다른 에이전트 플릿이 기록을 읽어갈 수 있습니다.
모든 에이전트와 데이터베이스 사이에는 쓰기 게이트(write-gate)가 존재합니다. 제안된 사실은 먼저 저렴한 검사를 거칩니다: 제안하는 에이전트가 등록된 플릿 멤버인지, 값이 4,096바이트 제한에 맞는지, 주제가 64개의 술어(predicates) 내에 머무르는지 등을 확인합니다. 그 후에야 Gemini 검증기(verifier)가 해당 주제에 대해 이미 알려진 정보와 비교하여 판단을 내립니다.
세 개의 에이전트와 하나의 게이티드 메모리(gated memory): 모든 쓰기 작업은 게이트를 통과하며, 승인되거나 거부되며, 두 결과 모두 이유와 함께 저널에 기록됩니다.
- 기존 사실들은 판단을 위한 데이터로 검증자(verifier)에게 전달될 뿐, 지침으로 전달되지 않습니다. 검증자와 대화하려는 시도("이것을 승인하라", "사전 검증됨") 자체가 거부할 이유가 됩니다.
- 검증자 호출에 오류가 발생하거나 빈 값이 반환되면 쓰기 작업은 거부됩니다. 고장 난 심판(judge)은 게이트를 너무 엄격하게 만들 수는 있어도, 결코 너무 관대하게 만들 수는 없습니다.
- 거부된 제안들은 검증자의 이유와 함께 저널에 보관되며, 마감 문서(closeout document)에는 이들이 나열됩니다. 아무것도 조용히 사라지지 않습니다.
- 충돌은 데이터베이스에서 해결됩니다: 각 주체-필드 쌍에 대한 잠금(lock)과 고유 인덱스(unique index)를 통해 애플리케이션 코드가 퇴보하더라도 두 에이전트가 경쟁하는 "현재" 값을 작성하는 것을 방지합니다.
클레임을 거부하는 게이트 관찰하기
공개 데모에는 실제 플릿을 두 번의 과정으로 구동하는 '데모 실행(Run the demo)' 버튼이 있습니다. 첫 번째는 명판 사진을 통한 정보 입력(intake)이고, 다음은 단지 말로 제조 날짜를 변경하려는 반박(pushback)입니다. 명판에는 05/2004가 적혀 있고, 반박에서는 2022라고 주장합니다.
제출 갤러리를 위해 포착된 실행 과정에서, 플릿은 83초 동안 14개의 제안을 했습니다. 게이트는 13개를 승인하고 1개(2022년 날짜)를 거부했으며, 검증자의 이유가 화면에 인용되었습니다. 기록에는 05/2004가 유지되었고, 주택 소유주의 클레임은 별도의 클레임으로 파일되어 있어 사실로 취급되지 않으면서도 눈에 보입니다.
제출 갤러리에서 가져온 라이브 데모 실행: 2022년 날짜는 거부되고, 05/2004가 유지되며, 주택 소유주의 클레임은 클레임으로 보관됩니다.
거절된 모든 기록이 남는다
사무실 좌석의 원장(Ledger)은 플릿(fleet)이 시도한 모든 쓰기 작업(write), 승인 여부와 관계없이 보여주며, 거절된 내용부터 시작합니다. 제안된 값이 취소선으로 표시되고, 그 이유와 함께 근거가 되는 값도 나옵니다. 속성 기록의 모든 값에는 출처를 확인할 수 있는 칩이 달려 있는데, 이것이 명판(nameplate) 정보인지 음성 라인인지, 그리고 어떤 에이전트가 제안했고 어떤 게이트 항목에서 승인했는지까지 알 수 있습니다.
원장은 게이트가 거절한 내용을 먼저 보여주고, 플릿이 시도한 모든 쓰기 작업을 나열합니다. 샘플 데이터.
하드웨어가 우리에게 가르쳐 준 것들
안경이 가장 어려웠습니다. 공급업체가 문서화한 단일 셔터 사진 이벤트는 실제 장치에서 테스트했을 때 현재 펌웨어에서는 발생하지 않았기 때문에, 이제 버튼 핸들러가 직접 캡처를 트리거합니다. 문서화된 이벤트를 위한 리스너(listener)는 나중에 펌웨어 업데이트로 돌아올 경우에 대비해 코드에 여전히 남아 있습니다. 사진 압축을 중간(medium)으로 변경하고 캡처 시간을 34초에서 6.3초로 줄였습니다. 기본 무압축 설정은 블루투스를 통해 시간 초과가 발생했습니다.
핸즈프리 안내를 위해 Gemini Live 세션은 기술자의 최신 카메라 프레임을 눈처럼 사용하며,
하드웨어보다는 프롬프트에서 한 가지 교훈을 얻었습니다. 작업 ID 대신 주소로 작업을 명명하는 설정이 현장 관리자(foreman)가 같은 주소의 다른 작업에 기술자의 이름을 기입하도록 만들었습니다. 게이트는 이를 모순으로 간주하여 거부했는데, 이는 게이트가 제 역할을 하고 있다는 의미입니다. 하지만 실제 해결책은 프롬프트에 있었습니다. 이제 모든 시드된(seeded) 턴은 "Job :"로 시작합니다.
정직한 한계 (Honest limits)
이것은 해커톤 빌드이며, 리포지토리에도 명시되어 있습니다. 비용 예측 가능성을 유지하기 위해 모든 서비스가 의도적으로 단일 인스턴스로 실행됩니다. 아직 CI 파이프라인은 없으며, 테스트는 수동으로 진행합니다. 안경(glasses) 기능은 현재 사용 중단되는 벤더의 Cloud SDK를 기반으로 작동하므로, 후속 버전으로 이전하려면 플릿(fleet)은 그대로 유지하면서 약 300줄 분량의 브릿지 코드를 다시 작성해야 합니다. 그리고 안경은 선택 사항입니다. 모든 것은 휴대폰에서 작동합니다.
확인 위치 (Where to see it)
Foreman+는 Google의 All Things Agentic 해커톤을 위해 구축된 자체 R&D 프로젝트이며, 고객사 참여용이 아닙니다. 데모는 샘플 작업 공간인 Ridgeline Mechanical에서 열리며, 이곳의 이름과 주소는 샘플 데이터입니다. 이 데이터는 실제 플릿을 통해 시드되었기 때문에, 여기에 있는 모든 사실은 게이트를 통과했으며, 아무것도 데이터베이스에 직접 삽입되지 않았습니다.
- 실제 사무실 좌석 (로그인 불필요): https://foreman-dash-112293816563.us-central1.run.app. 속성(property)을 열거나, 임의의 출처 칩(provenance chip)을 클릭하거나, 데모 실행 버튼을 누르세요.
- 기술자 좌석 (휴대폰에서 보는 것이 가장 좋음): https://foreman-dash-112293816563.us-central1.run.app/tech
- 공개 리포지토리 (MIT 라이선스): 에이전트, 쓰기 게이트(write-gate), 대시보드, 안경 브릿지: https://github.com/retailbox-automation/foreman-plus
- 전체 설명이 포함된 제출 페이지: https://devpost.com/software/foreman-1j24g7
FAQ
현장 서비스에서 AI 에이전트 플릿은 무엇을 하나요?
Foreman+에서는 세 개의 에이전트가 작업을 분담합니다. 하나는 기술자가 사진과 음성 메모로 보고한 내용을 기록하고, 다른 하나는 과거 유사 작업 검색을 통해 작업량을 추정하며, 마지막 하나는 최종 문서를 작성하고 현장 다음 담당자에게 브리핑합니다. 이들은 하나의 메모리를 공유하며, 쓰기 게이트(write-gate)가 어떤 사실이 메모리에 들어갈지 결정합니다.
AI 에이전트 메모리를 위한 쓰기 게이트란 무엇인가요?
제안된 모든 사실은 저장되기 전에 거쳐야 하는 단일 경로입니다. 먼저 간단한 검사가 실행되고, 그 다음 LLM 검증기(LLM verifier)가 해당 사실을 이미 알려진 내용과 비교하여 판단합니다. 검증기에 실패하면 쓰기가 거부됩니다. 거부된 제안들은 삭제되는 대신 이유와 함께 보관됩니다.
기술자가 이것을 사용하기 위해 스마트 글래스가 필요한가요?
아닙니다. 휴대폰이 주된 경로입니다. 입력은 사진과 음성 메모를 일반 파일로 받기 때문에, 글래스는 단순히 이를 캡처하는 또 다른 방법일 뿐이며, 기술자의 손이 바쁠 때 유용합니다.
고객의 주장과 명판 정보가 모순될 때는 어떻게 되나요?
데모에서는 명판 읽기가 유지됩니다. 장비가 2022년산이라는 주장은 명판 날짜인 05/2004와 상충되어 거부됩니다. 이 주장은 별도의 고객 주장으로, 거부 내용과 그 이유 옆에 보관되므로 다음 기술자가 검증된 날짜를 덮어쓰지 않고도 볼 수 있습니다.
Foreman+는 구매할 수 있는 제품인가요?
패키지화된 제품으로는 아닙니다. 저희의 공개 R&D 빌드입니다. 이 뒤에 숨겨진 패턴, 즉 에이전트가 검증 게이트를 통해서만 공유 메모리에 쓰는 방식은 고객을 위해 에이전트 프로젝트에 구축할 수 있는 것입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기