말은 더 자연스러워졌는데, 왜 불 하나 켜는 데는 실패할까

이 사례들이 업계 전체의 공통 실패율을 보여주는 것은 아니다. 다만 한 가지 반복되는 패턴은 확인할 수 있다. 대화 능력은 향상되고 있는데, 일상적인 실행은 여전히 일관되지 않다는 점이다.

자연어가 제어 문제로 바뀌는 과정

기존 음성 비서는 기능이 제한적이었던 대신, 제어 경로가 비교적 단순했다. 인식된 문장을 미리 정해둔 의도와 검증된 동작에 연결하는 방식이었다.

사용자는 정해진 표현에 가까운 명령을 익혀야 했다. 대신 시스템이 해석할 수 있는 경우의 수가 적었고, 음성 입력에서 실제 기기 동작으로 이어지는 경로도 반복 가능했다.

LLM 기반 비서는 훨씬 더 많은 일을 즉석에서 처리해야 한다. 예를 들어 다음 단계를 거칠 수 있다.

1. 사용자가 무엇을 뜻하는지 추론한다.
2. “여기”, “그것들”, “불” 같은 표현이 가리키는 대상을 해석한다.
3. 정확한 방과 기기, 해당 기기가 지원하는 기능을 찾는다.
4. 적절한 도구나 API를 선택한다.
5. 유효한 매개변수를 입력한다.
6. 기기의 현재 상태를 고려한다.
7. 명령이 실제로 성공했는지 확인한 뒤 정확하게 보고한다.

어느 한 단계에서든 오류가 나면 결과가 틀릴 수 있다. 다른 기기를 선택하거나 방을 잘못 이해할 수 있고, 지원하지 않는 기능을 호출하거나 잘못된 값을 보낼 수도 있다. 오래된 상태 정보를 참고하거나, 기기 상태가 바뀌지 않았는데도 성공했다고 말하는 경우도 가능하다.

LLM 기반 스마트홈 제어를 다룬 연구는 비결정성, 추론에 필요한 시간과 비용, 제한적인 개인화를 안정적인 기기 제어의 장애물로 지적한다. 또한 사용자의 요청이 명확하고 구조화돼 있을 때가 넓은 문맥을 스스로 해석해야 할 때보다 성능이 좋다고 설명한다.

대화 능력과 실행 능력은 다르다

Amazon과 Google이 내세우는 기능 자체가 무의미한 것은 아니다. Alexa+는 사용자가 말로 묘사한 요구를 적절한 기기와 기능에 연결하도록 설계됐고, Google은 여러 명령을 한 번에 처리하거나 문장 중간에 바뀐 지시를 반영하는 기능을 강조한다.

이런 능력은 다음과 같은 작업에 유용하다.

• 사용자가 원하는 분위기를 설명하면 적절한 장면이나 설정을 제안하는 일
• 복잡한 앱 화면을 거치지 않고 음성으로 루틴을 만드는 일
• 자동화가 어떤 방식으로 작동하는지 설명하는 일
• 모호한 요청을 구조화된 계획으로 바꾸는 일

그러나 요청을 이해하는 것과 실제로 실행하는 것은 별개의 문제다.

“저녁 식사에 어울리게 방 분위기를 만들어줘”라는 말에는 어느 정도 판단이 들어갈 수 있다. 반면 “주방 조명을 50%로 설정해줘”는 목표 상태가 명확하다. 전자에는 유연한 언어 모델이 잘 맞지만, 후자에는 범위가 좁고 결과를 확인할 수 있는 제어 경로가 더 적합하다.

이 차이 때문에 비서는 복잡한 문장을 인상적으로 처리하면서도 간단한 조명 명령에는 실패할 수 있다. 언어의 복잡성과 실행의 복잡성은 같은 것이 아니다. 여러 기기를 조작하는 요청도 도구와 매개변수를 우연히 정확하게 고르면 성공할 수 있지만, 짧은 명령은 기기 식별이나 기능 확인 단계에서 막힐 수 있다.

느린 응답은 실패를 더 크게 느끼게 한다

신뢰성은 정답 여부만으로 결정되지 않는다. 스마트홈 명령은 합리적으로 예측 가능한 시간 안에 반응해야 한다. 조명이 한참 뒤에 켜지거나 사용자가 같은 말을 반복한 뒤에야 작동한다면, 최종적으로 상태가 맞더라도 시스템은 불안정하게 느껴진다.

Alexa+ 리뷰에서는 일부 응답에 최대 15초가 걸렸다는 평가가 나왔다. 다만 조명이나 온도조절기 같은 기본 동작은 경우에 따라 더 빠르게 처리되기도 했다. Gemini for Home 관련 보도에서도 일상 명령의 응답 속도를 높이고 답변을 짧게 만드는 업데이트가 언급됐다. 이는 지연 시간이 여전히 해결 중인 기술 과제라는 점을 보여준다.

클라우드 처리, 모델 선택, 기기 검색, 도구 호출은 모두 지연을 추가할 수 있다. 이 과정에서 이론적으로는 더 많은 일을 할 수 있지만, 사용자가 실제로 명령하는 순간에는 예측 가능성이 낮아지는 시스템이 만들어질 수 있다.

소비자가 베타테스터가 되는 것처럼 느끼는 이유

소프트웨어를 지속적으로 배포하고 사용자의 데이터를 바탕으로 개선하는 방식은 일반적인 개발 전략이다. 위험이 낮은 대화 기능이라면 이런 반복 개선이 합리적일 수 있다.

하지만 스마트홈 제어는 다르다. 오류가 나면 추상적인 챗봇 화면이 아니라 실제 집 안의 조명, 알람, 자동화, 때로는 보안과 관련된 기기에 영향을 준다. 업데이트 이후 몇 달 동안 문제없이 작동하던 루틴이 달라지면 사용자는 기능 실험이 아니라 일상의 변화를 직접 겪게 된다.

출시 후 불만이 제기되고, 이어서 수정과 안정성 개선 업데이트가 나오는 흐름이 제조사가 의도적으로 미완성 제품을 출시했다는 뜻은 아니다. 다만 사용자들이 시스템이 조정되는 동안 문제를 겪고 있다는 점은 분명하다. 자동화 누락, 작동하지 않는 루틴, 일관되지 않은 응답에 대한 불만이 이어지면서 “출시하고, 데이터를 모으고, 개선한다”는 방식은 일상적인 기기 제어에 적용될 때 특히 큰 비용으로 느껴진다.

더 안전한 출시 방식은 기본 명령에 대해 신뢰할 수 있는 결정론적 경로를 유지하고, 그 주변에 생성형 기능을 더하는 것이다. 사용자는 자연스러운 대화를 얻으면서도 홈 오토메이션의 가장 기본적인 약속을 잃지 않아야 한다. 알려진 명령을 내리면 의도한 기기가 의도한 상태로 바뀌어야 한다.

해법은 하이브리드 구조에 가깝다

현실적인 해법은 스마트홈에서 LLM을 완전히 빼는 것이 아니다. 오류의 결과가 커지는 지점에서 LLM의 역할을 제한하는 것이다.

안정적인 시스템이라면 LLM이 먼저 사용자의 의도와 실행 계획을 해석한 뒤, 다음과 같은 제어 계층에 결과를 넘길 수 있다.

• 기기와 매개변수 선택을 스키마로 검증
• 민감한 동작에는 명시적인 권한 적용
• 실행 전후에 실제 기기 상태 확인
• 재시도와 명확한 오류 처리
• 실행 계획과 실제 완료를 구분해 확인

한 연구 분야에서는 LLM이 컴파일 단계에서 실행 가능한 결과물을 만들고, 실제 실행 단계에서는 워크플로 오케스트레이션이 분기, 도구 선택, 재시도, 오류 처리를 결정론적으로 수행하는 방식을 제안한다.

스마트홈에 이를 적용하면 모델은 사용자의 의도를 표현하는 데 도움을 줄 수 있지만, 매번 발생하는 물리적 동작의 최종 결정권자가 될 필요는 없다. 특정 기기의 상태를 정해진 값으로 바꾸는 거래에 가까울수록 실행 경로는 더 제한적이고, 검증 가능하며, 테스트하기 쉬워야 한다.

결론: 잘 말하는 비서와 잘 작동하는 비서는 다르다

Alexa+와 Gemini for Home은 생성형 AI의 더 넓은 교훈을 보여준다. 말을 더 잘하는 것이 곧 작동을 더 잘한다는 뜻은 아니다.

리뷰어와 사용자, 기술 매체의 보고를 종합하면 이들 비서는 더 풍부한 문맥을 이해하고 야심찬 복합 명령을 구성할 수 있다. 그러나 조명, 디머, 알람, 루틴처럼 평범하고 반복적인 작업에서는 여전히 흔들린다.

앞으로의 스마트홈 비서는 두 접근법을 결합할 가능성이 크다. 생성형 AI는 설정과 대화를 유연하게 만들고, 결정론적 소프트웨어는 최종 동작을 정확하고 빠르며 검증 가능하게 만들어야 한다.

이 경계가 제대로 설계되기 전까지는 대화가 더 자연스러워진 비서가 오히려 집 안의 가장 기본적인 일을 덜 안정적으로 처리하는 역설이 계속될 수 있다.