서버 없는 AI 워크플로 도구 PatchCat, 브라우저에 남는 API 키 보안 두고 설계 논쟁

중국 개발자 커뮤니티 V2EX에 순수 프론트엔드로 동작하는 경량 시각적 AI 워크플로 오케스트레이터 PatchCat을 만들고 있다는 개발자가 글을 올렸다. 서버 의존성이 전혀 없고, 빌드 결과물이 몇 MB 수준의 정적 자원에 불과하다. NAS나 소프트 라우터, OpenWrt 라우터 같은 곳에 올려두면 브라우저로 열어 바로 쓸 수 있는 구조다.

데이터와 DAG 토폴로지는 브라우저의 LocalStorage와 IndexedDB에 저장되고, 모델 호출은 사용자가 직접 넣은 키로 모델에 직결하는 BYOK 방식이다. 문제는 키 보관이다. LocalStorage 자체는 브라우저 샌드박스로 격리되지만, 키를 평문으로 두면 공용 PC나 남에게 빌려준 기기에서 사실상 방어력이 없다. 커뮤니티에 공유된 워크플로 JSON을 자주 가져와 쓰는 도구 특성상 평문 저장은 환경 전체의 심층 방어를 약하게 만든다.

글쓴이는 두 가지 선택지를 놓고 의견을 구했다. 하나는 Web Crypto API와 마스터 패스워드를 조합해 로컬에서 복호화한 뒤 주입하는 방식이고, 다른 하나는 Cloudflare Workers 같은 초경량 엣지 프록시를 두고 키 보관과 헤더 주입을 맡기는 방식이다. 다만 후자는 '순수 정적, 서버 의존성 제로'라는 출발점에서 벗어난다는 점을 스스로 지적했다.

경량화를 택한 배경에는 진짜 로컬 우선과 가정용 수준의 가벼움이 있다. Docker나 데이터베이스를 돌릴 전용 NAS, 혹은 상시 켜두는 호스트를 요구하지 않고 운영 부담을 만들지 않겠다는 것이다. 상정한 시나리오는 NAS나 소프트 라우터 하나가 24시간 켜져 있는 환경에서, 사설 자료를 재료로 AI 상담 파이프라인을 직접 시각적으로 짜고 싶지만 블랙박스형 에이전트는 신뢰하지 않는 경우다.

댓글 반응은 갈렸다. 브라우저에서 실행되는 이상 요청에는 결국 키가 실려 나가므로 노출을 피할 수 없다는 지적이 나왔고, AI 시대에는 로컬 복호화 모듈을 그대로 떼어내 복호화하는 일이 쉬워진 만큼 경량 수준의 보안이면 충분하다는 의견도 있었다. 글쓴이는 HTTPS가 전송 구간을 지키고, 로컬 암호화는 기기를 빌려주거나 악성 확장 프로그램이 저장소를 훔쳐보는 상황을 막는 용도라고 선을 그었다. 기기에 트로이목마가 심긴 단계라면 어떤 아키텍처도 답이 되지 않는다는 입장이다.

로컬 우선 도구를 만드는 개발자에게 이 논의가 주는 실무적 시사점은 위협 모델을 먼저 좁히라는 것이다. 전송 구간 보호, 저장소 암호화, 악성 확장 대응은 서로 다른 문제이며 하나의 해법으로 모두 덮이지 않는다. 서버 없는 정적 배포를 유지하려면 보호 범위를 명시적으로 선언하고, 그 범위를 벗어나는 위협은 사용자 책임으로 남기는 편이 정직하다.

다만 원문은 개인 및 가정용 시나리오를 전제로 한 논의이며, 마스터 패스워드 방식이 실제로 구현됐는지나 구체적인 암호화 설계는 제시되지 않았다. 보안 감사 결과도 언급되지 않았고, 댓글은 커뮤니티 의견일 뿐 검증된 평가가 아니다.