# 찰떡키보드: Jetson Nano로 만든 스마트 키보드 - 작성자: [은근한 고래](https://community.clauders.ai/member/imported-member-ESTbGMHvsa) - 공간: [에이전트 / 노코드 자동화](https://community.clauders.ai/automation) - 게시: 2026-07-26 - 연재: [AI 스마트홈 기기 만들기](https://community.clauders.ai/series/smart-home-ai-devices) 1/2편 - 태그: #스마트홈AI - 주소: https://community.clauders.ai/automation/post/%EC%B0%B0%EB%96%A1%ED%82%A4%EB%B3%B4%EB%93%9C-jetson-nano%EB%A1%9C-%EB%A7%8C%EB%93%A0-%EC%8A%A4%EB%A7%88%ED%8A%B8-%ED%82%A4%EB%B3%B4%EB%93%9C-0285e5f0-d895-89e5-b9c0-6e09e537be9e --- Jetson Nano로 만든 스마트 키보드 — 음성과 문서를 어디서든 텍스트로 입력하기 ### 전체 구조 설명 Open optionstext ``` ┌─────────────────────────────┐ 마이크 ─→ │ │ 녹음버튼 ─→ │ Jetson Orin Nano Super │ ──(WebSocket)──→ 작업 PC 웹캠(문서) ─→ │ (STT + OCR 연산 전담) │ → 현재 포커스 창 └─────────────────────────────┘ ``` 사용자는 다음 세 가지만 수행한다. 1. 버튼을 누르고 말한다. 2. 문서를 카메라로 촬영한다. 3. 평소처럼 키보드를 사용한다. 나머지는 모두 Nano가 처리한다. ### 입력 장치 설계 버튼 선택 처음에는 다양한 PTT(Push To Talk) 장치를 검토했다. 후보 결과 전용 무전기 버튼 기각 스마트폰 전용 PTT 버튼 기각 전문 헤드셋 PTT 장치 대안 2.4G/블루투스 매크로패드 채택 채택 이유는 단순했다. - 표준 키보드 프로토콜 사용 - 별도 드라이버 불필요 - 저렴한 비용 - 자유로운 키 매핑 최종적으로는 다음 구성을 고려했다. - 한국어 모드 - 영어 모드 - 녹음 시작/종료 - 노브(스크롤, OCR 촬영, 모드 전환) ### 텍스트 입력 방식 검토 이 프로젝트에서 가장 의외의 난관은 **한글 IME 문제**였다. 처음에는 "키보드를 흉내 내면 되겠지"라고 생각했지만 실제로는 그렇지 않았다. 검토한 방식 방식 결과 USB HID Gadget 기각 Bluetooth HID 기각 SSH + tmux 기각 클립보드 + Ctrl+V 기각 Windows SendInput (VK_PACKET) 채택 채택 이유 Windows가 기본 제공하는 유니코드 입력 경로를 활용하면 - 한/영 전환 상태와 무관 - 자모 조합 문제 없음 - 클립보드 오염 없음 - 거의 모든 프로그램에서 동일 동작 이라는 장점이 있었다. 결국 "물리 키보드를 흉내 내는 방식"보다 "운영체제의 문자 입력 경로를 사용하는 방식"이 훨씬 안정적이었다. ### Nano와 PC 간 통신 방식 통신 방식도 비교 검토했다. 방식 결과 Raw TCP 기각 HTTP 기각 MQTT 기각 WebSocket 채택 WebSocket을 선택한 이유 - 연결 유지 가능 - 재연결 오버헤드 없음 - 단어모드/문장모드 동시 지원 - 구현 복잡도 적절 ### 음성 인식(STT) 모델 선택 검토 대상 - 초경량 모델 - 중간 크기 모델 - Whisper 계열 Turbo 모델 - NVIDIA 다국어 STT 모델 현재는 특정 모델을 미리 결정하지 않고 실제 측정 결과로 판단하는 접근을 선택했다. 평가 기준은 단 두 가지다. - 속도 - 정확도 ### 음성 인식의 고려 사항 - 한국어 + 영어 혼합 발화 - 기술 용어 인식 - 필러(음, 어, 있잖아 등) ### 실행 환경 설정 Nano에는 이미 YOLO 기반 비전 모델이 설치되어 있었다. 처음에는 Docker 격리를 고려했지만 최종적으로는 다음 방식을 선택했다. 채택 방식 - Python 가상환경 분리 - 필요 시 모델 로드 - 사용 종료 후 메모리 해제 실제 사용 패턴상 - STT - OCR - YOLO 를 동시에 사용하는 경우가 거의 없기 때문이다. ### 단어모드와 문장모드의 차이 속도와 정확도는 동시에 최적화하기 어려웠다. 그래서 두 가지 모드를 설계했다. 구분 단어모드 문장모드 입력 방식 스트리밍 완료 후 처리 지연 매우 짧음 1~2초 후처리 없음 있음 용도 빠른 입력 정제된 입력 Open optionstext ``` [단어모드] 말하는 동안 → 계속 화면에 출력 [문장모드] 말 종료 → 후처리 → 정리된 문장 출력 ``` ### 필러 제거 방법 사람의 말에는 불필요한 표현이 많이 포함된다. 예시 - 음... - 어... - 있잖아... - 그러니까... 적용 방식 1차 버전은 단순 규칙 기반으로 구현했다. Open optionstext ``` 음 → 제거 어 → 제거 있잖아 → 제거 ``` 추후에는 문맥까지 고려하는 규칙을 추가할 예정이다. ### 개인화 후처리의 가능성 이 프로젝트에서 가장 흥미로운 확장 아이디어는 개인화 학습이다. 사용자는 결과를 보고 - 그대로 전송하거나 - 수정 후 전송한다. 이 행동 자체가 학습 데이터가 된다. Open optionstext ``` 원본 음성 ↓ STT 결과 ↓ 사용자 수정 ↓ 정답 데이터 자동 생성 ``` 장기적으로는 개인 말버릇을 이해하는 맞춤형 후처리 모델로 발전시키는 것이 목표다. ### OCR 기능의 필요성 음성만으로는 해결되지 않는 입력도 있다. 예를 들어 - 화이트보드 - 종이 문서 - 표 - 스크린샷 등이다. 처리 흐름 Open optionstext ``` 문서 촬영 ↓ 기울기 보정 ↓ OCR ↓ 텍스트 또는 표 인식 ↓ 미리보기 ↓ 전송 ``` 특히 표는 Markdown 형식으로 변환하는 것을 목표로 하고 있다. 예시 Open optionsmarkdown ``` | 이름 | 역할 | |------|------| | Nano | STT/OCR | | PC | 입력 수신 | ``` ## 결과와 배운 점 이번 설계를 진행하며 얻은 가장 큰 깨달음은 다음과 같다. ### AI 병목이 아닌 입력 속도 최신 AI 모델을 사용하는 환경에서도 실제 생산성을 제한하는 요소는 종종 사람의 입력 속도였다. ### 표준 프로토콜의 중요성 전용 장치보다 - USB 키보드 - Bluetooth 키보드 - WebSocket 같은 범용 기술이 훨씬 안정적이었다. ### 한글 입력의 복잡성 처음에는 단순한 문제라고 생각했지만 실제로는 IME 처리 방식이 전체 아키텍처를 결정할 정도로 큰 변수였다. ### 리소스 분리의 중요성 STT와 OCR을 별도 장치에서 처리하면 작업 PC는 오직 개발 작업에 집중할 수 있다. ## 향후 계획 - Whisper 계열 모델 벤치마크 - NVIDIA STT 모델 비교 실험 - 사용자 개인화 후처리 - OCR 표 인식 정확도 개선 - Linux 환경 입력 지원 - Bluetooth HID 대안 검토 ## 한 줄 요약 > "지금 사용하는 키보드에 음성과 카메라 입력을 추가한다"는 관점으로 접근하니, STT 도구가 아니라 새로운 입력 장치를 설계하는 프로젝트가 되었다. 이 초안은 사례 공유용으로 바로 게시 가능한 수준이며, 원하시면 제가 **"개발 과정 중심"**, **"삽질/시행착오 중심"**, **"Claude Code 활용 사례 중심"**으로 더 다듬어 드릴 수 있습니다. 🚀