← Docs hub

Android 기반 Robotics AI 시스템 설계와 검증

LLM의 출력이 Android 기기의 실제 동작으로 이어지는 경계를 다뤘다. 자연어를 잘 해석하는 것만으로는 부족했다. 현재 상태가 맞는지, 요청한 기능이 실제로 지원되는지, 다른 동작과 충돌하지 않는지, 호출 접수 뒤 물리적으로 끝났는지를 서로 다른 책임으로 관리해야 했다.

작업의 중심은 모델 자체보다 의미 판단, 실행 계약, 상태의 권위, 실패 수렴과 검증 범위를 명확하게 만드는 일이었다. 아래 내용은 현재 코드와 시험으로 확인한 기반, 제한된 환경에서 연결한 시제품, 아직 검증이 필요한 목표 구조를 구분해 정리한 것이다.

담당한 시스템 경계

책임을 나눈 기준은 단순하다. Planner는 무엇을 왜 수행할지 정한다. 제품 실행 계층은 지금 허용되는지와 작업을 언제 끝낼지 관리한다. 도메인 서비스는 이동, 환경 관리, 화면, 음성 같은 기능의 실제 의미와 완료 조건을 안다. HAL, ROS 2 또는 로봇 SDK는 주행 안정화, 센서 주기, 긴급 정지 같은 저수준 제어를 소유한다.

이 경계를 지키면 LLM이 느리거나 응답하지 않아도 실행 중인 기기의 안전 상태는 유지된다. 반대로 기기 기능이 실패했을 때 모델이 성공으로 추정하는 것도 막을 수 있다.

기술 사례 1 · 의미 경계와 라우팅 품질

성숙도: 구현·검증

문제

실제 음성 입력은 완전한 문장보다 짧은 반응, 조사 누락, 발음 오류, 대화 잔여물이 많다. 이런 입력에서 특정 단어 하나만 보고 기기 실행이나 외부 검색으로 보내면 오동작이 발생한다. 반대로 짧다는 이유만으로 모두 인식 실패로 막으면 “안녕”, “지금 작업 중이야?”처럼 바로 답할 수 있는 요청까지 잃는다.

판단 구조

개별 문장을 예외 목록으로 추가하기보다 의미 증거를 분리했다.

최종 분류는 이 증거의 조합으로 결정한다. 예를 들어 실행 동사가 있어도 대상과 기능이 없으면 강한 기기 실행 근거로 보지 않는다. 반면 등록된 공간과 지원 기능이 함께 확인되면 짧은 표현도 실행 후보로 복구할 수 있다.

개선 방식

1. 실패를 정답 → 예측 방향으로 묶어 어느 경계가 움직였는지 확인했다.
2. 정답지 자체가 최신 정책과 맞지 않는 경우는 모델 실패와 분리했다.
3. 반복되는 실패가 같은 의미 축에서 설명될 때만 판단 기준을 조정했다.
4. 수정 뒤에는 해당 사례만 재시험하지 않고 전체 평가셋으로 반대편 회귀를 확인했다.
5. 정확도 외에 영역별 성공률과 과승격·과차단 방향을 함께 봤다.

이 방식은 규칙을 없애는 접근이 아니다. 안전상 반드시 고정해야 하는 금지 조건은 명시적으로 유지한다. 다만 자연어 의미를 문장 문자열 목록으로 관리하지 않고, 모델이 해석할 수 있는 일반적인 증거와 정책 경계로 제한했다.

남은 위험

평가셋에서 안정적이어도 실제 사용자 분포가 바뀌면 경계는 다시 흔들릴 수 있다. 정답 변경 이력, 데이터 출처, 모델·프롬프트 버전과 실패 방향을 함께 보존해야 재현 가능한 개선이 된다.

기술 사례 2 · Planner와 기기 실행 폐루프

성숙도: 시제품·통합 검증

문제

“두 공간을 순서대로 이동한 뒤 특정 기능을 수행하고 복귀”하는 요청은 문장 해석만 맞아도 끝나지 않는다. 첫 이동이 실제로 완료되어야 다음 단계가 실행되고, 사용자가 중간에 취소하거나 기기가 멈추면 남은 단계를 계속할지 결정해야 한다.

기존 방식에서 가장 위험한 혼동은 API가 요청을 받음과 기기가 동작을 끝냄을 같은 성공으로 보는 것이다. 이동 명령 반환, 화면 전환 요청 접수, 장시간 측정 시작은 모두 종료가 아니다.

계획 계약

Planner가 만드는 단계에는 최소한 다음 의미가 필요하다.

계획은 장치 API 이름을 임의로 생성하지 않는다. 현재 기능 목록과 입력 계약으로 표현할 수 없는 단계는 확인 질문 또는 실행 불가 결과로 남긴다.

실행 상태

제출 -> 허용 판정 -> 대기열 -> 실행 -> 완료 증거 대기
                                  -> 성공 | 실패 | 취소 | 시간 초과

허용 판정은 호출자의 권한, 현재 기기 상태, 제품 정책, 사용 중인 자원과 사용자 동의를 검사한다. 실행이 시작되면 Task runtime이 진행 상태를 소유하고, 도메인에서 올라오는 관찰 결과를 완료 증거와 대조한다. 물리적 완료가 확인된 뒤에만 후속 단계가 열린다.

재계획 경계

모든 단계 종료 때 LLM을 다시 호출하지 않는다. 정상적인 진행, 짧은 대기, 이미 정의된 재시도는 기기 실행 계층이 처리한다. 아래처럼 계획의 의미가 바뀌는 경우에만 Planner가 다시 개입한다.

• 목표 위치나 필요한 입력을 더 이상 사용할 수 없음
• 정책 또는 사용자 동의 때문에 원래 행동을 수행할 수 없음
• 실패 후 선택 가능한 대안이 여러 개이며 목표 영향이 서로 다름
• 사용자가 진행 중인 목표를 수정함

재계획 입력에는 자유 형식 로그가 아니라 실패한 단계, 현재 상태 snapshot, 실패 사유, 이미 완료된 단계와 허용 가능한 대안을 넣는다. 이 경계가 지연과 토큰 사용을 제한한다.

실패 처리

오래된 위치 값을 현재 위치로 사용하거나, 사용자가 화면에서 취소한 동작을 계속 대기하거나, 장시간 세션을 시작 직후 완료로 판단하는 문제가 대표적이었다. 해결의 핵심은 자연어 규칙이 아니라 상태의 출처·시각·세대와 terminal evidence를 계약에 포함하는 것이다. 증거가 없으면 성공으로 추정하지 않고 시간 초과 또는 확인 필요 상태로 수렴시킨다.

검증 범위

• 계획 구조와 단계 의존관계: 자동 시험
• 요청·상태·실패 계약: 단위 및 통합 시험
• Planner에서 기기 Task 제출까지: 로컬 통합 검증
• 이동·환경 관리·복귀의 일부 경로: 실기기 확인
• 장시간 측정, 사용자 UI 취소, 네트워크 단절 후 복구: 추가 검증 필요

기술 사례 3 · SoC Robotics-AI Framework

성숙도: 기반 구현·시험 / 전체 구조는 설계·연구

문제

제품 기능이 늘면 앱과 서비스가 기기 기능을 직접 호출하고, 각자 상태 cache와 오류 해석을 갖기 쉽다. 같은 기능도 호출 경로에 따라 허용 조건과 완료 의미가 달라지고, 한 서비스의 생명주기 문제가 다른 기능으로 전파된다. AI 호출자가 추가되면 이 문제가 더 커진다. 자유 형식 모델 출력을 기존 서비스에 바로 연결할 수 없기 때문이다.

목표 구조

Application / AI / IoT
  -> 타입이 명확한 Manager SDK
  -> Binder/AIDL 프로세스 경계
  -> 제품 실행 계층
       상태 · 정책 · 자원 · 기능 목록 · Task/Workflow · 완료 증거
  -> 도메인 서비스
  -> Android Framework/HAL 또는 ROS 2·로봇 SDK Adapter
  -> 실제 기기 동작

AOSP의 system_server에는 부팅과 서비스 등록에 필요한 얇은 연결부만 두고, 제품 정책과 장기 실행은 별도 제품 프로세스에 두는 구성을 검토했다. 장애 파급 범위를 줄이고 제품 기능을 시스템 핵심 서비스와 독립적으로 갱신하기 위한 선택이다.

계층별 책임

상태와 정책

상태는 여러 cache가 각각 맞다고 주장하지 않도록 도메인별 권위자를 둔다. 외부에 전달하는 snapshot에는 값뿐 아니라 출처, 관찰 시각, 세대와 유효 여부를 포함한다. 오래된 값은 false나 0으로 대체하지 않고 알 수 없음으로 표현한다.

실행 허용 범위는 순서대로 좁혀진다.

1. 저수준 안전 규칙이 금지하는 동작은 상위 요청과 무관하게 거부한다.
2. 제품 모드와 정책이 현재 장면에서 허용하는 기능을 확인한다.
3. 호출 앱 또는 AI에 부여된 기능 범위를 검사한다.
4. 현재 상태, 사용자 동의와 자원 충돌을 확인한다.

거부 결과에는 단순 실패가 아니라 어느 단계에서 왜 거부됐는지 설명 가능한 사유를 남긴다. Planner와 UI는 이 사유로 재시도, 대안 제안, 사용자 안내를 구분할 수 있다.

자원과 동시성

모터, 카메라, 마이크, 스피커, 화면, 환경 제어 장치는 동시에 사용할 수 없는 조합이 있다. 실행 주체는 자원을 직접 점유했다고 가정하지 않고 제한 시간이 있는 소유권을 받는다. 우선순위가 높은 안전 동작은 기존 소유권을 회수할 수 있으며, 회수된 Task는 명확한 중단 사유를 받는다.

이 구조는 “이동 중 카메라 자세 제한” 같은 제품 정책을 각 앱에 복사하지 않게 한다. 앱은 현재 상태를 조회해 UX를 조정할 수 있지만 최종 실행 허용 판정은 Framework가 수행한다.

Robotics 경계

상위 Task의 단위는 지정 위치로 이동, 환경 관리 시작, 관찰 수행처럼 제품 의미를 가진 동작이다. 관절 궤적, 균형 유지, 충돌 회피, 긴급 정지와 센서 주기는 ROS 2 또는 제조사 로봇 SDK에 남긴다. 제품 실행 계층은 목표와 정책을 전달하고 진행·완료·실패 상태를 정규화한다. 저수준 제어를 다시 구현하지 않는다.

이 분리는 특정 로봇 SDK에 종속되지 않는 Adapter 계약을 가능하게 한다. 공급자가 바뀌어도 상위 Application과 Task 계약은 유지하고, 지원 기능과 상태 변환만 Provider 별로 교체할 수 있다.

기존 기능과의 호환성

기존 단일 호출을 모두 Task로 강제하지 않는다. 한 번 실행하고 즉시 결과를 반환하는 설정 변경은 기존 경로를 유지할 수 있다. 단계 의존관계, 진행 조회, 취소, 제한 시간, 완료 증거가 필요한 요청만 관리형 Task 또는 Workflow로 올린다.

기존 IoT payload나 앱 계약도 일괄 교체하지 않는다. 기존 handler 앞에 호환 Adapter를 두고, 관리가 필요한 신규 요청에만 Task metadata를 추가하는 점진 이관이 현실적이다. 직접 호출과 관리형 Task가 같은 자원을 사용할 때는 두 경로 모두 공통 정책·자원 판정을 통과해야 동시성 규칙이 깨지지 않는다.

현재 확인된 범위

기반 코드가 존재한다는 사실은 전체 제품 통합이 끝났다는 뜻이 아니다. 전체 AOSP build, 모든 도메인 이관, OTA와 장시간 실기기 안정성은 별도 완료 조건으로 관리한다.

확장 설계 · Experience Goal과 지식 계층

성숙도: 시제품·통합 검증과 설계·연구가 혼재하며 항목별 구분 필요

Experience Goal

Experience Goal은 한 번의 명령보다 긴 범위에서 사용자가 기대하는 결과와 종료 조건을 유지한다. 대화만으로 충분하면 실행을 만들지 않는다. 기기 행동이 도움이 될 때만 현재 상태, 지원 기능, 부작용과 동의를 확인해 계획 후보를 만든다. 목표를 유지하는 것과 행동을 자동 승인하는 것은 별개다.

지식 그래프와 RAG

지식 그래프는 사용자, 공간, 기능, 정책, 과거 결과의 관계를 좁힌다. RAG는 관계에 연결된 설명서와 정책 원문이 필요할 때만 사용한다. 현재 상태만 묻는 요청과 이미 구조화된 단일 실행에는 검색을 붙이지 않아 지연을 늘리지 않는다.

월드모델

월드모델은 기기의 관찰을 시간축으로 정리한 상태 표현이다. 위치나 환경 값 자체보다 출처, 시각, 신뢰도, 충돌 여부와 행동 후 변화가 중요하다. Planner는 이 정보를 사용해 오래된 상태를 현재 사실로 오인하는 문제를 줄일 수 있다.

선제형 동작

선제형 Agent는 센서 임계치 규칙만으로 동작하지 않는다. 상태 변화의 지속성, 사용자 선호, 진행 중인 작업, 예상 효과와 오개입 비용을 보고 무시, 안내, 제안, 사전 승인된 실행 중 하나를 선택해야 한다. 실제 실행은 일반 요청과 같은 정책·Task·증거 경로를 사용한다.

검증 방식

문제를 분석할 때는 요청 식별자를 기준으로 음성 입력, 모델 판단, Task 제출, 도메인 실행과 terminal evidence를 연결한다. 한 계층의 성공 로그만으로 전체 성공을 판단하지 않는다.

현재 수준과 남은 과제

우선순위는 기능 수를 늘리는 일이 아니다. 기존 단일 요청의 지연과 정확도를 유지하면서 관리형 실행이 필요한 경계만 넓히고, 장기 작업의 완료 증거와 복구 가능성을 확보하는 것이 먼저다.

LinkedIn 소개문

Android 기반 지능형 기기에서 음성 입력, LLM 판단, 기기 실행과 완료 확인이 이어지는 시스템을 설계하고 검증해 왔다. 주로 다룬 문제는 자연어 의미 경계, Planner의 단계 계약, 장기·복합 Task의 생명주기, Android 서비스와 실제 기기 상태 사이의 불일치였다.

LLM은 목표와 실행 단계를 제안하되 기기 안전을 직접 결정하지 않도록 경계를 나눴다. 제품 실행 계층이 권한, 현재 상태, 자원 충돌, 제한 시간과 물리적 완료 증거를 관리하고, 도메인 서비스가 실제 기능의 완료·실패 의미를 제공하는 구조다.

품질은 모델 출력 정확도만으로 판단하지 않았다. 오분류 방향과 정답지 변경을 추적하고, 계약 시험, 로컬 통합, 로그 상관관계와 일부 실기기 동작을 서로 다른 검증 단계로 관리했다. 확인하지 않은 범위는 구현 완료로 표현하지 않는다.

현재는 Android/AOSP 위에서 여러 Application과 AI가 같은 상태·정책·Task 계약을 사용하도록 Robotics-AI Framework 구조를 구체화하고 있다. Manager SDK, Binder/AIDL, 제품 실행 서비스, 도메인 Adapter와 ROS 2·로봇 SDK 경계를 분리해 상위 Application이 바뀌어도 기기 실행 기반과 안전 정책을 안정적으로 유지하는 것이 목표다.

LinkedIn에 사용할 수 있도록 분리한 기술 프로필 패키지도 함께 제공한다.

Connections

• [[ContextAwarePlanning]]
• [[ExperienceGoal]]
• [[KnowledgeGraph]]
• [[WorldModel]]
• [[AndroidApplicationFramework]]