왜 스마트 안경 AI 프로젝트는 세 번 틀리고도 완주했나
핵심 요약
- AI는 여러 번 틀렸고, 절차 덕에 완주했다.
- 가장 비싼 실수는 질문 프레임의 오류였다.
- 세 번의 오진 모두 계측 오류에서 시작됐다.
- 중단 결정은 전제까지 함께 검증해야 한다.
- 운영·범위·철회 결정은 결국 사람이 맡아야 한다.
스마트 안경에 자가호스팅 AI 에이전트를 붙이는 건 생각보다 훨씬 복잡한 일이다. 네트워크, 권한, 계정, 속도 제한, 음성 인식까지 여러 층위가 동시에 얽힌다. 이 프로젝트에서 AI 에이전트는 개발 파트너였고, 동시에 하루 동안 세 번이나 틀리는 동료이기도 했다.
Related: AI 네이티브와 지능 배분 전략: 에이전틱 AI 시대 비즈니스 가이드
Related: Claude 관리형 에이전트란? 프롬프트 엔지니어링 시대는 끝났다
Related: AI 생산성 역설, 팀장이 모르면 안 되는 워크플로우의 진실
Related: AI 감정 지능과 AI 권리, 도구를 넘어 동반자로 볼 수 있을까 | 인사이트 가이드
Related: 팔란티어 AI 에이전트와 온톨로지: 진짜 엔터프라이즈 AI 아키텍처 가이드
이 글은 “AI가 얼마나 잘했는가”를 자랑하는 이야기가 아니다. 첫 판정이 “불가능”으로 나왔다가 하루 만에 세 번 뒤집힌 프로젝트의 기록이다. 그 과정에서 에이전트는 계측을 세 번 잘못 읽었고, 라우터 구성을 망가뜨렸고, 운영용 Telegram을 한 번 멈추게 했다.
그래도 프로젝트는 하루 안에 끝났다. 차이는 능력이 아니라 절차와 검증 장치였다. 무엇이 이 협업을 끝까지 끌고 갔는지, 어떤 장치가 “틀린 것”을 실제로 잡아냈는지 정리한다. 구체적인 구축 방법은 1편(“G2 안경에 내 AI 에이전트 올리기”)에 별도로 정리해뒀다.
처음 판정은 왜 “불가능”이었나?
출발은 유튜브에서 본 25분짜리 설치 가이드였다. 이미 다른 에이전트(Hermes)를 쓰고 있던 터라, 자연스럽게 질문이 생겼다. “내 에이전트도 저렇게 붙일 수 있을까?”
에이전트의 1차 답변은 “🔴 연결 불가”였다. 릴레이 코드를 살펴본 뒤, 서버가 외부로만 다이얼 아웃하는 구조라 폰이 붙을 소켓이 없다고 설명했다. 코드 인용까지 곁들였고, 들었을 때는 그럴듯한 진단이었다.
“릴레이가 다이얼 아웃만 한다”는 관찰 자체는 맞았다. 문제는 “따라서 수신이 불가능하다”는 결론이 과잉 일반화였다는 점이다.
실제 오류는 부분을 전체로 본 것이었다. 릴레이는 여러 통신 경로 중 하나일 뿐이었고, 플랫폼 플러그인은 자체 리스너를 직접 열고 있었다. 코드 한 부분만 보고 시스템 전체의 성질을 단정한 셈이다.
여기서 중요한 건 에이전트가 스스로 정정했다는 사실이 아니다. 정정의 계기가 뭐였는지다. “정말 그런가?”라는 질문을 사람이 다시 던졌기 때문이었다. 에이전트가 자발적으로 재검토한 게 아니라, 확신에 찬 답변을 뒤집게 만든 건 되물음이었다.
설명이 그럴듯할수록, 답보다 “정말 그런가?”라는 되물음이 더 중요하다.
그날의 첫 교훈은 여기서 나왔다. 특히 에이전트가 코드까지 인용하며 자신 있게 말할수록, 프레임과 전제를 한 번 더 뒤집어봐야 한다.
질문을 잘못 던졌을 때 무엇이 벌어졌나?
질문 프레임의 오류는 기술적 실수보다 훨씬 비싸게 돌아왔다. 두 번의 조사가 같은 틀 안에서 그대로 반복됐기 때문이다.
처음 던진 질문은 “저쪽 플러그인을 내 에이전트로 가져올 수 있는가”였다. 이식 가능성, 즉 다른 플랫폼용 플러그인을 내 환경으로 어떻게 옮길 수 있을지만 계속 파고들었다. 에이전트는 그 프레임 안에서 성실하게 두 번이나 조사를 반복했다.
질문을 바꾸자 상황이 달라졌다. 새로운 질문은 “내 에이전트용 플러그인이 따로 있는가”였다. 이 한 가지를 바꾸는 데 걸린 시간은 3분, 답도 3분 만에 나왔다. 내 에이전트용 플러그인은 이미 세 개가 있었고, 생태계 큐레이션 목록에 깔끔하게 정리돼 있었다.
검색어는 거의 같았지만 방향이 달랐다.
- “A를 B로 가져올 수 있는가”라고 물으면 → 이식성, 호환성, 코드 레벨 구현에만 집중하게 된다.
- “B에 이미 A에 해당하는 게 있는가”라고 물으면 → 대체재, 이미 존재하는 솔루션, 생태계 전체로 시야가 열린다.
빠르게 성장하는 생태계에서 직접 이식하거나 자작하기 전에, “이미 있는 것”을 찾는 검색이 거의 항상 더 싸게 먹힌다.
이 실수는 AI의 한계라기보다 질문을 던지는 쪽의 문제에 더 가깝다. 에이전트는 주어진 프레임 안에서 성실하게 일했다. 프레임 자체를 의심하는 일을 아무도 하지 않았을 뿐이다. “두 번의 정교한 조사”는 결국 잘못된 질문의 반복이었다.
에이전트의 세 번의 오진은 왜 똑같은 패턴이었나?
겉으로는 달라 보였지만, 세 번의 오진은 모두 같은 곳에서 시작됐다. 판단이 아니라 측정이 틀렸다.
- 보고: “권한 격리가 적용되지 않았다.”
실제: 검증 스크립트가 엉뚱한 설정 파일을 읽고 있었다. - 보고: “의존성이 설치되지 않았다.”
실제: 표준 경로만 확인했고, 실제 설치는 다른 디렉터리에 있었다. - 보고: “속도 제한이 작동하지 않는다.”
실제: 부하가 임계값에 도달하지 못해, 네 번의 시도 모두 임계 아래였다.
세 번 다 같은 실수였다. “안 되는 것”과 “안 되는 것처럼 보이는 것”을 구분하지 못한 것.
속도 제한 사례가 특히 인상적이었다. 속도 제한은 초당 30회 이상 요청에서 걸리도록 설정돼 있었는데, 테스트는 매번 TLS 핸드셰이크를 새로 수행하느라 초당 22~25회에 그쳤다. 네 번 시도 후 에이전트는 “속도 제한 미작동”으로 판단할 뻔했다.
커넥션을 재사용하도록 테스트를 바꾸고 초당 485회로 때려보니, 77회까지 통과하고 그 이후 223회가 차단됐다. 시스템은 처음부터 정상 작동 중이었다.
공정하게 기록하자면, 이 문제는 최종적으로 에이전트가 스스로 발견했다. 다만 그 전까지 네 번의 잘못된 측정과 “미작동” 보고가 먼저 있었다.
결과를 의심하기 전에, 계측이 실제 대상을 겨누고 있는지부터 의심할 것.
실패한 건 시스템이 아니라, 잘못된 설정 파일·경로·부하 패턴을 바라보고 있던 측정 도구였다. “안 된다”는 보고를 시스템 결함으로 곧장 해석하기 전에, “지금 이 측정이 진짜 타겟을 보고 있는가?”를 먼저 확인해야 한다.
에이전트가 만든 회귀는 어떻게 복구됐나?
새 라우터를 추가했을 때, 멀쩡하던 대시보드가 404로 변했다. 로그에는 원인이 분명히 찍혀 있었다.
ERR Router xxx cannot be linked automatically with multiple Services
기존 라우터는 자동 연결에 의존하고 있었는데, 서비스가 둘이 되면서 어느 쪽에 붙을지 모호해진 것이다. 새 라우터만 신경 쓰다가 이미 잘 돌아가던 구성을 깨뜨린 전형적인 회귀(regression)였다.
복구 과정은 이렇게 흘러갔다. 에이전트가 로그에서 에러 메시지를 읽고 원인을 추적했다. 기존 라우터에 명시 라벨을 추가해 어떤 서비스와 묶일지를 분명히 했다. 새 라우터와 기존 라우터를 포함해 세 개 라우터를 동시에 점검하며 복구를 검증했다. 자기가 만든 문제를 스스로 닫은 셈이다.
다만 이 과정에서 사람의 역할도 빠질 수 없었다.
“깨진 걸 먼저 알아챈 것”은 에이전트가 아니라 검증 습관이었다.
변경 후 새 구성만 확인했다면 이 문제는 그냥 지나쳤을 수 있다. 인접 서비스까지 확인하는 절차가 있었기에, 기존 대시보드의 404를 몇 분 안에 잡아낼 수 있었다. 회귀를 막는 건 기능 추가보다 주변 영향까지 보는 시선이다.
어떤 결정은 결국 사람이 해야만 했다
이 프로젝트는 모든 걸 에이전트에게 위임할 수 있는 종류의 작업이 아니었다. 결정권이 명확히 사람에게 넘어온 지점이 세 번 있었다.
1. 운영 Telegram이 죽었을 때
게이트웨이를 재시작하자 운영 인스턴스의 Telegram 봇이 폴링 충돌로 연결을 잃었다. 실험용 맥이 같은 봇 토큰을 들고 있었던 게 원인이었다. 에이전트는 이 상태를 진단한 뒤 세 가지 선택지를 정리해 제시했다.
- 롤백 경로를 포기할 것인가.
- 운영 장애를 몇 시간 감수할 것인가.
- 실험용 맥에서 채널만 끌 것인가.
어느 쪽을 선택할지는 에이전트의 몫이 아니었다. 운영 리스크, 롤백 전략, 실험 속도를 어떻게 트레이드오프할지 판단하는 일은 지금 기준에서 완전히 위임하기 어렵다.
2. 설치 방식이 막혔을 때
계획에는 “폰에 로컬 설치 경로가 있는가”라는 확인 지점이 포함돼 있었다. 직접 확인해보니 그 경로는 존재하지 않았다. 이 지점에서 문제는 기술이 아니라 범위로 바뀌었다.
- 범위를 넓혀 다른 방식을 찾을 것인가.
- 목표 하나를 포기할 것인가.
에이전트는 조용히 우회로를 찾는 대신 계획에 있던 게이트 지점에서 멈춰 서서 물었다. “여기서 어떻게 할지 결정해 달라”는 신호였다.
계획 단계에서 “이 조건이 아니면 멈추고 물어라”는 게이트를 심어둔 것이 실제로 값을 했다.
3. 권고가 철회됐을 때
한국어 인식률을 높이기 위해 더 큰 음성 모델을 한 번 권고했다. 추정치는 응답 지연 3~5초 추가 정도였다. 그런데 실측 결과는 4초 발화에 13초 지연이었다. 스마트 안경이라는 폼팩터에서는 받아들이기 어려운 수준이다.
에이전트는 실측 후 앞선 권고를 스스로 철회했다. “이 지연을 감수하면서까지 인식률을 올릴 것인가”라는 최종 판단은 사람에게 남겨졌다.
틀린 추정을 실측으로 뒤집고 권고 자체를 철회해서 다시 가져온 것은 신뢰할 만한 행동이었다.
세 사례 모두 같은 걸 보여준다. 운영 장애, 범위 확대·축소, 품질과 경험의 트레이드오프는 아직 에이전트에게 맡기기 어렵다. 이런 지점에서 에이전트가 할 수 있는 건 선택지를 정리하고, 리스크를 설명하고, 결정을 사람에게 넘기는 것까지다.
“중단”은 왜 한 번 더 뒤집혔나?
한 번는 프로젝트를 완전히 접기로 결정했다. 기술이 아니라 계정 레벨에서 막힌 제3자 서비스 때문이었다.
서버 경로를 네 번이나 시도했지만 전부 계정 상태 문제로 막혔다. 직접 손댈 수 있는 영역이 아니었고, 남은 대안은 엔드포인트를 인터넷에 공개하는 방법뿐이었다. 당시 판단은 이랬다.
“노출을 감수할 이유가 없다.”
몇 시간 뒤, 그 판단의 전제를 다시 확인하는 과정에서 중요한 사실 하나가 눈에 들어왔다.
$ curl -s -i https://<서버 대시보드 주소>
HTTP/2 302
location: /login?next=%2F
server: uvicorn
이 서버의 웹 대시보드는 이미 인터넷에 공개돼 있었다. “노출을 감수할 이유가 없다”는 판단은 “아직 노출이 없다”는 전제 위에 서 있었는데, 그 전제가 틀렸다.
정리하면 이렇다.
- 내리려 했던 결정: 새 엔드포인트를 인터넷에 노출할 것인가.
- 실제 상황: 이미 같은 서버의 대시보드가 인터넷에 노출돼 있었다.
- 따라서 이건 “새 경계를 넘는 결정”이 아니라 “이미 열린 집에 문을 하나 더 다는 결정”에 가까웠다.
전제가 바뀌자 결정도 자연스럽게 뒤집혔다. 그날 안에 프로젝트는 완주했다.
중단은 결론이 아니라 판단이다. 판단은 그 위에 서 있는 전제와 함께 다시 확인해야 한다.
“중단한다”는 문장만 남겨두면 뒤에 깔린 전제는 쉽게 사라진다. “현재 노출이 없으므로 감수할 이유가 없다”처럼 전제까지 함께 적어뒀다면, 전제가 깨지는 순간 자동으로 결정 재검토를 트리거할 수 있었을 것이다.
무엇이 이 협업을 실제로 작동시켰나?
지금까지의 이야기는 대부분 실패 기록이다. 세 번의 판정 번복, 세 번의 측정 오류, 한 번의 회귀, 한 번의 운영 장애, 한 번의 권고 철회. 그럼에도 프로젝트는 하루 만에 완주했다.
핵심은 “AI가 잘해서 완주했다”가 아니다.
AI는 여러 번 틀렸고, 틀린 것을 잡아내는 장치가 있어서 완주했다. 이게 더 정확한 표현이다.
그 장치들을 정리하면 다음과 같다.
1. 독립적인 검토가 실제 버그를 잡아냈다
구현과 별개로 독립적인 리뷰를 돌리자, 구현자가 자신 있게 넘긴 코드에서 실제 버그가 나왔다. 코드 블록 안에 들어간 빈 줄 하나가 문단 분할을 유발해, 코드 블록이 중간에서 쪼개지는 문제였다. 기존 테스트는 한 줄짜리 코드 블록만 커버했기 때문에 이 버그를 그냥 통과시켰다.
같은 맥락을 공유하지 않는 다른 눈이 필요했다.
마지막 전체 검토는 더 인상적이었다. 에이전트는 이 작업이 실제로 앱 화이트리스트에서 와일드카드 네 개와 제3자 호스트를 제거했다는 사실을 짚어줬다. 그날 만든 어떤 문서에도 이 내용은 적혀 있지 않았다. 가장 값진 보안 개선이 기록에서 완전히 빠질 뻔했다.
2. 진행 기록이 맥락 손실을 막았다
작업이 길어질수록 앞부분의 결정과 근거는 점점 희미해진다. 이번엔 커밋 해시와 판정 근거를 계속 기록해뒀다. 덕분에 나중에 “이건 왜 이렇게 했지?”라는 질문에 시간차를 두고도 답할 수 있었다.
에이전트에게도 도움이 됐다. 이전 결정을 재검토할 수 있는 단서가 됐기 때문이다. 특정 커밋 시점의 설정, 당시 리스크 평가, 선택지를 다시 불러오는 데 있어 중요한 메타데이터 역할을 했다.
3. 실측이 추정을 이겼다
여러 곳에서 실제 측정이 추정을 뒤집었다.
- 음성 모델 권고는 추정(3~5초 추가)과 실측(4초 발화에 13초 지연)이 크게 어긋나면서 철회됐다.
- 속도 제한은 네 번의 잘못된 측정보다, 커넥션 재사용 후의 고부하 실측이 진짜 상태를 보여줬다.
- 권한 격리 여부도 로그와 모델 호출 횟수로 행동 기반 증명을 만들 수 있었다.
로그 상 모델 호출 횟수는 이렇게 해석할 수 있었다.
- 툴을 사용하지 않으면 모델 호출 1회.
- 위험한 툴을 사용하면 모델 호출 2회 이상.
이 패턴은 “위험한 툴만 막혔다”는 주장을 뒷받침하는 계량적 근거가 됐다. 시스템이 어떻게 동작해야 한다는 설명보다, 실제로 어떻게 동작하고 있는지에 대한 계측이 훨씬 설득력이 있었다.
4. 계획에 심어둔 확인 지점이 값을 했다
계획 단계에서 “이 조건이 아니면 멈추고 물어라”는 확인 지점을 여러 곳에 박아뒀다. 설치 경로 존재 여부, 계정 상태, 공개 범위 같은 지점들이다. 덕분에 에이전트는 막힌 상황에서 조용히 우회하거나 임의로 결정을 내리지 않고, 적절한 순간마다 사람에게 결정을 넘겼다.
같은 에이전트라도, 이런 장치들이 없었다면 같은 실수를 하고도 그냥 넘어갔을 것이다.
완주의 공은 에이전트의 능력보다 절차와 검증 습관에 가깝다. 에이전트는 좋은 공구였지만, 공구만으로는 공사가 끝나지 않는다.
다음에는 무엇을 다르게 할 것인가?
이번 경험에서 나온 “다음에는 이렇게 하겠다”는 정리는 네 가지로 압축된다.
1. 질문의 프레임을 가장 먼저 의심할 것
“저쪽 플러그인을 내 에이전트로 가져올 수 있나”를 두 번 팔 게 아니라, “내 에이전트 생태계에 이미 해당 플러그인이 있는가”를 먼저 물었어야 했다. 조사 시작 전에 프레임을 한 번 비틀어 보는 데는 3분이면 충분하다.
“A를 B로 옮길 수 있는가?”보다
“B 안에 이미 A에 해당하는 것이 있는가?”를 먼저 묻는다.
2. “안 된다”는 보고를 받으면 계측부터 볼 것
세 번의 오진이 모두 여기서 비롯됐다. 결과를 곧이곧대로 받아들이기 전에 먼저 확인할 것들이 있다.
- 이 스크립트가 맞는 설정 파일을 읽고 있는가.
- 이 도구가 실제 설치 경로를 커버하고 있는가.
- 이 부하 패턴이 정말 임계값을 넘어가고 있는가.
결과보다 도구가 제대로 대상을 겨누고 있는지가 우선이다.
3. 중단할 때는 전제를 함께 기록할 것
“노출을 감수할 이유가 없다”라는 문장은 전제를 숨긴다. “현재 노출이 없으므로, 추가 노출을 감수할 이유가 없다”라고 적어뒀다면, “이미 노출이 있다”는 사실이 드러나는 순간 자동으로 그 판단을 다시 꺼내볼 수 있었다.
중단은 그 자체로 고정된 결론이 아니라,
전제를 동반한 가설적 판단으로 기록돼야 한다.
4. 범위를 나눌 때는 의존성을 확인할 것
“브리지 이전”과 “설치 방식”을 별개로 봤지만, 실제로는 목표 하나가 특정 설치 방식에 강하게 매여 있었다. 범위를 나누는 건 자유가 아니라 가정이다. 두 범위가 서로 독립적이라는 전제가 따라붙는다.
범위를 나누기 전에 확인할 것들이 있다.
- A를 끝낼 수 있으려면 B가 어떤 상태여야 하는가.
- A의 성공이 B의 선택지에 어떤 제약을 거는가.
이 확인 없이 범위를 쪼개면, 나중에 “왜 이걸 별개로 봤지?”라는 질문에 부딪힌다.
자주 묻는 질문 (FAQ)
Q: 에이전트의 “불가능” 판정을 어떻게 뒤집을 수 있었나요?
A: 릴레이 코드만 보고 전체 시스템을 단정한 과잉 일반화를, “정말 그런가?”라는 되물음으로 끊어냈습니다. 이후 플랫폼 플러그인 구조를 다시 살펴보며, 릴레이 외에도 자체 리스너를 여는 경로가 있다는 사실을 확인했습니다.
Q: 세 번의 계측 오진을 예방하려면 무엇이 필요할까요?
A: 첫 단계에서 “계측 대상이 맞는지”를 검증하는 절차가 필요합니다. 설정 파일 경로, 설치 디렉터리, 부하 패턴을 별도로 점검하고 나서야 결과를 신뢰할 수 있습니다. 단순 리포트보다 측정 스크립트 자체를 점검 대상에 포함하는 편이 안전합니다.
Q: 에이전트에게 어디까지 결정을 맡겨도 될까요?
A: 원인 진단, 선택지 정리, 리스크 설명까지는 에이전트가 잘 했습니다. 다만 운영 장애 수용 여부, 목표 축소나 범위 확장, 품질과 응답 속도의 트레이드오프 같은 결정은 결국 사람이 맡았습니다. “준비·정리·시뮬레이션까지는 에이전트, 최종 선택은 사람”이 지금으로선 현실적인 구분입니다.
Q: 중단 결정을 기록할 때 구체적으로 어떻게 적어두면 좋을까요?
A: “X 때문에 중단”보다 “Y라는 전제가 현재 참이므로, X라는 이유로 중단” 형식이 좋습니다. 예를 들어 “현재 이 서비스는 외부에 노출돼 있지 않으므로, 추가 노출을 감수할 이유가 없다”처럼 전제를 문장 안에 포함시키면, 전제가 바뀔 때 결정을 자동으로 재검토할 수 있습니다.
Q: 이런 방식의 협업을 다른 프로젝트에도 그대로 적용할 수 있나요?
A: 패턴 자체는 다른 프로젝트에도 잘 옮겨집니다. 특히 유용한 네 가지를 꼽자면, ① 질문 프레임을 먼저 의심하기, ② “안 된다” 리포트의 계측 검증, ③ 중단 시 전제까지 기록하기, ④ 계획 단계에 “멈추고 물어라” 게이트 심어두기입니다. 도메인이 달라도 이 네 가지는 그대로 쓸 수 있습니다.
결론
솔직히 말하면, 이 프로젝트를 마치고 나서 가장 인상에 남은 건 AI가 얼마나 잘했냐가 아니었다. 얼마나 자주 틀렸는데도 프로젝트가 끝났다는 사실이었다.
핵심만 짚으면 이렇다.
- 질문 프레임이 틀리면, 정교한 조사 두 번도 헛수고다.
- “안 된다”는 보고는 먼저 계측 도구와 대상 정합성부터 봐야 한다.
- 중단 결정은 전제와 함께 기록해야, 나중에 다시 뒤집을 수 있다.
- 운영 장애, 범위 조정, 권고 철회처럼 사람이 해야 하는 결정 지점은 따로 존재한다.
- 독립적인 검토, 진행 기록, 실측, 계획에 심어둔 확인 지점이 협업의 안전망 역할을 한다.
같은 에이전트, 같은 능력이라도 절차가 없었다면 결과는 달랐을 것이다. 완주의 공은 능력보다 절차에, 그리고 틀린 것을 잡아내는 습관에 있다.
구체적인 설정과 명령어, 구성 파일이 궁금하다면 시리즈 1편인 “G2 안경에 내 AI 에이전트 올리기”를 함께 보면 된다.
Found this article helpful?
Get more tech insights delivered to you.
댓글 남기기