인터넷을 끊어도 내 앱의 AI가 일할까? 확인 계획과 측정이 멈춘 이유

문의 내용을 일정·장소·기타로 나누는 작은 앱을 생각해 보자. 인터넷 없이 화면이 열리면 AI 분류도 가능할까? 한 Mac의 브라우저에서 같은 뜻의 한국어·영어 합성 문의 10쌍(모두 20개)을 확인할 계획을 세웠지만, AI가 실제로 분류 계산을 하는 측정 실행은 한 번도 하지 않았다(NOT RUN). 출처를 확인하지 못한 연결 시도 때문에 통신 관찰·통제를 수용할 수 없어 준비 단계에서 멈췄다. 두 언어의 분류 결과와 속도는 알 수 없다. 이 글은 확인 계획과 준비에서 멈춘 이유를 설명하고, AI로 앱을 만드는 독자를 위한 미검증 설계 질문을 남긴다.

여기서 계획한 차단은 컴퓨터 전체의 인터넷 단절이 아니라 시험용 브라우저 실행 범위의 모의 차단이다. 그 차단을 검증할 검사도 수용된 실행 결과가 없다.

이 글의 목차

화면, 파일, 계산을 따로 확인한다

이 글의 다섯 문서 링크에 관한 설명은 2026년 10월 4일 연구 기록을 바탕으로 한다. 이번 원고 작성·수정에서는 해당 페이지를 다시 열어 확인하지 않았다.

당시 확인한 Transformers.js 문서는 호환 모델을 브라우저에서 실행하고 WebGPU를 사용하는 경로를 설명했다. WebGPU는 브라우저가 GPU 계산을 쓰는 방법이다. 그러나 실행 도구의 지원이 특정 모델과 내 기기의 작동을 보장하지는 않는다. Transformers.js 프로젝트

확인할 대상은 세 가지다. 화면이 열리는가, 계산에 필요한 파일이 있는가, 그 파일로 실제 새 답을 만드는가. 브라우저의 서비스 워커는 저장한 파일로 오프라인 화면을 제공할 수 있다. 화면을 다시 열었다는 관찰만으로 AI가 계산했다고 판단할 수 없는 이유다. MDN 서비스 워커 안내

모델 파일만 챙겨서도 부족하다. 실행 코드와 계산을 돕는 WASM 파일 등도 필요할 수 있다. ONNX Runtime Web의 배포 문서는 이런 자산을 구분한다. 준비 시간과 최초 전송량을 살피려면 필요한 파일 전체를 기록해야 한다. ONNX Runtime Web 배포 안내

여기서 ‘서버 없이’는 원격 서버에 AI 계산을 맡기지 않는다는 뜻으로 좁혀야 한다. 준비한 설계에서도 내 컴퓨터의 작은 서버는 화면과 파일을 전달한다. 계산을 어디서 하는지와 파일을 어디서 받는지는 다른 질문이다.

세 조건을 같은 문의로 살핀다

준비한 입력은 같은 뜻의 한국어·영어 10쌍이다. 실제 고객 문의는 사용하지 않는다. 아래 표와 검사·집계 규칙은 모두 실행 결과가 아닌 계획이다.

각 언어의 10문장은 일정 4개, 장소 3개, 기타 3개다. B와 C는 각각 같은 20문장을 번호 오름차순, 내림차순, 시드 27로 섞은 순서로 반복할 계획이었다. 최종 계획의 예열은 한국어와 영어로 짧게 인사하게 하는 비채점 호출 1회였으며, 이것도 실행하지 못했다.

지시문 번역 차이가 결과에 섞이지 않도록 두 언어에 같은 영어 지시문을 사용하고, 답은 schedule, place, other 중 하나로 정했다. 다음은 한국어 입력 두 개이며, 각각 같은 뜻의 영어 입력도 있다. “토요일 예약은 그대로예요. 방 번호만 알려 주세요.”는 날짜가 있어도 장소 문의다. “수업은 언제 시작하고 어디에서 하나요?”는 두 의도를 함께 물으므로 기타로 정했다. 이는 앱의 분류 규칙이며 보편적인 정답은 아니다.

앞뒤 공백만 제거한 뒤 정해진 소문자 라벨과 정확히 일치하는지 판정하기로 했다. 형식이 틀린 답·거부·잘린 출력·오류·시간 초과는 실패한 시도로 기록하고, 사람이 고친 선택은 별도로 남길 계획이었다. 아예 제출하지 않은 항목은 미시도로 두고 오답으로 만들지 않기로 했다. 계획·시도·완료·미시도 수를 함께 밝히고, 시도 기준 집계에는 실패한 시도도 포함하기로 했다. A는 화면 확인이므로 모델 정확도를 계산하지 않기로 했다. 같은 10쌍을 반복해도 다양한 문의를 새로 얻는 것은 아니며, 공통 영어 지시문이 두 언어에 똑같이 작용한다고 볼 수도 없다. 측정했더라도 일반적인 한영 성능 순위를 매길 설계는 아니다.

C에서는 온라인 상태인 B에서 분류 계산을 맡을 작업 단위인 ‘추론 워커’를 종료하고, 시험용 브라우저 실행 범위의 통신을 차단한 뒤 새 추론 워커를 만들 계획이었다. 이는 브라우저나 운영체제 재시작이 아니며, 이미 메모리에 올라온 엔진을 그대로 쓰는 진단으로 C를 대신할 수 없다. 새 참조값이나 새 워커, 라벨 화면, GPU 사용량만으로는 새 모델 계산을 입증할 수 없다. 정답표가 앱과 지시문에 들어가지 않는지, 저장 답이나 키워드 규칙으로 우회하지 않는지 코드와 실제 모델 호출·모델이 낸 답의 기록을 확인하도록 했다.

준비 직후·예열 후·온라인 분류 후의 파일 목록과 실제 읽기도 대조할 계획이었다. C가 예열 후 이미 있던 필수 파일만 사용하는지 확인하기 위한 미검증 수용 요건이다. 뒤늦게 받은 필수 파일이 준비의 빈틈을 가리지 못하도록 하려는 설계였다.

차단 자체도 검사가 필요하다. 화면·워커·서비스 워커 각각에서 캐시를 거치지 않는 시험 요청의 온라인 성공을 먼저 확인할 계획이었다. 이어 차단 후 같은 종류의 요청이 실패하는지 확인하도록 했다. 브라우저 자동화 도구인 Playwright의 오프라인 설정은 지정한 브라우저 실행 범위의 모의 차단이다. 컴퓨터 전체의 인터넷을 끊었다는 뜻은 아니다. Playwright 오프라인 설정

준비에서 확인한 범위

2026년 10월 6일 이 Mac의 사전 점검에서 Chrome 154가 WebGPU 어댑터를 얻고 shader-f16 기능을 보고했다. 이는 GPU 계산이나 모델 실행을 측정한 결과가 아니다.

초기 WebLLM/Qwen 후보는 변환된 모델 파일의 명시적 라이선스 근거가 부족해 진행하지 않았다. 2026년 10월 7일에는 LiquidAI의 LFM2.5-1.2B-Instruct-ONNX 개정 10f72e70abf67ac0fd7ebf15bc5854726891d864, Transformers.js 4.3.1, ONNX Runtime Web 개발 빌드 1.31.0-dev.20260914-8d85527a0를 쓰는 경로를 선정했다. 당시 내부 기록에는 변환물의 LFM Open License v1.0 명시, 파일 식별값과 로그인 없는 접근 확인(HEAD 요청) 결과가 있다. 라이선스 이름의 기록은 일반적인 사용 허락이나 법률·보안 검토 결론이 아니다. 공개 자료에 적힌 크기·해시와 접근 확인은 모든 파일을 내려받아 내용까지 대조했다는 뜻도 아니다. 이 선정도 한국어·영어 분류 성공을 뜻하지 않는다.

첫 실행 계획은 실행용 라이브러리를 내려받은 뒤 준비 단계에서 멈췄다. 당시 검토는 계측 도구의 초기화·연결 절차 결함을 유력한 원인으로 보았다. 예열이나 분류 호출은 없었다. 두 번째 계획의 사전 점검 시도 네 차례도 수용되지 않았다. 전송량 0과 이전 캐시 저장 기록만으로는 해당 워커 요청이 캐시에서 처리됐다고 인정하지 않았다.

후속 준비에서는 캐시 파일과 실행할 워커를 연결해 기록하는 계측 설계, 통신을 관찰하고 차단하는 중계 도구를 보강했다. 10월 26일 작성 작업과 분리된 검토에서 브라우저나 네트워크 연결 없이 도구 테스트 77개가 통과했다. 해시 대조는 검사 도구의 후보 파일·소스·입력에 대한 로컬 대조였다. 이 결과는 검사 도구의 로직을 확인했을 뿐, 내려받은 모델 파일이나 실제 브라우저의 캐시 실행 연결, 전체 통제, AI 실행을 입증하지는 않는다.

마지막 점검은 왜 멈췄을까?

10월 26일에는 모델을 불러오지 않는 브라우저 시작 점검을 한 번 수행했다. 파일·환경 사전 확인은 통과했지만, 시험 화면으로 이동하기 전에 Google 도메인인 www.gstatic.com:443으로 연결하려는 시도가 관찰됐다. 외부 목적지를 모두 거부하도록 만든 중계 장치가 이를 차단했다. 중계 장치가 해당 외부 목적지로 전달한 바이트는 기록상 0이며, 해당 시도를 어느 구성요소가 시작했는지는 확인하지 못했다. 이 수치는 그 목적지로 중계 장치가 전달한 바이트에 한정되며, 시도의 내용과 중계 장치 밖 경로의 통신은 미확인이다.

Google 호스트라는 사실과 발생 시점만으로 앱이나 모델이 보낸 요청이라고 단정할 수 없다. 반대로 출처가 불명확한 연결 시도를 무시하고 통신 관찰이 완전하다고 판단할 수도 없다. 마지막 준비 경로에서 브라우저 시작 중 외부 연결 거부가 네 번째로 관찰됐다. 이 실행에서는 배경 통신 억제 옵션을 추가한 뒤에도 같은 목적지 거부가 반복됐다. 이 기록만으로 어떤 구성요소에 옵션이 적용됐는지나 그 효과를 판정할 수는 없다. 출처를 모르는 목적지를 허용해도 관찰의 빈틈이 해결되지는 않는다. 미리 정한 중단 규칙에 따라 재시도하거나 허용할 연결 목록을 넓히지 않고 이 경로의 측정 준비를 종료하기로 했다.

따라서 A·B·C는 모두 미실행이다. 이는 측정 준비의 실패이며, 오프라인 분류가 실패했다거나 해당 모델을 이 기기에서 실행할 수 없다는 결과가 아니다. 분류 정확도·응답 시간·언어별 차이는 여전히 미확인이다.

내 앱에 남길 확인 질문

다음은 효과를 검증하지 못한 기능별 설계 질문이다. AI에게 앱을 만들게 할 때 “오프라인 지원” 한 줄 대신, 앞의 화면·파일·계산 구분과 A·B·C 조건에 맞춰 각 질문에 답할 근거를 요청한다.

• 계산은 어디서 하며, 시험용 브라우저 실행 범위의 통신을 차단하기 전에 어떤 파일이 필요한가?
• 변환물의 라이선스와 파일 식별값을 확인했으며, 목록에 적힌 해시와 실제 받은 바이트의 검증을 구분했는가?
• 준비 전·준비 실패·실행 실패를 화면의 안내에서 구별하는가?
• 차단은 어느 브라우저 실행 범위에 적용되며, 관찰하지 못한 전송량을 0이 아닌 미확인으로 남기는가?
• 통신 차단 뒤 새 계산을 시작했음을 무엇으로 확인하는가?
• 필요한 각 언어를 따로 시험하고, 입력을 보존한 채 직접 분류할 수 있는가?
• 분류 계산 외에 앱이 보내는 네트워크 요청은 무엇이며, 관찰하지 못한 범위는 어디인가?

저장 파일도 영구 보관을 전제해서는 안 된다. 브라우저 저장소에는 한도와 삭제 조건이 있으므로 파일이 없어졌을 때 안내하는 화면도 설계 제안에 포함했다. 이 안내의 작동은 검증하지 못했다. MDN 저장소 한도와 삭제 조건

이 확인 질문의 효과나 AI가 준비되지 않았을 때 보여 줄 안내 화면은 실측으로 검증하지 못했다. 로컬 계산이 확인되더라도 앱 전체의 개인정보 보호를 증명하지는 않는다. ‘화면이 열린다’와 ‘내 문의를 분류한다’에 필요한 근거를 나누어 보자는 미검증 설계 제안이다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조했으며, 작성자가 최종 원고를 검토하고 수정 방향을 결정했습니다.