이 글은 Sign Bridge라는 Android 앱을 만들며 생각을 정리한 글입니다. 코드나 설치 방법을 나열하기보다, 왜 이런 앱을 상상했는지, 사회적·기술적 배경, 앱이 실제로 하는 일, 모델을 고치는 폴더(ml-train)와 재학습 스크립트가 의미하는 것을 차근차근 풀어 쓰려고 합니다. IT 업계에 계시지 않은 분도, 문장만 따라가면 큰 그림이 보이도록 썼습니다.
1. 이 글에서 말하는 범위
Sign Bridge는 “수어 한 번에 통역”이 아니라, 짧은 단어 단위로 서로의 말을 옮겨 보는 보조 도구에 가깝습니다. 그 한계를 숨기지 않는 것이 이 글의 조건이기도 합니다.
또 이 글에서는 소스 코드 저장소 주소나 개발 일정은 다루지 않습니다. 대신 공개된 보도와 조사를 인용해 왜 이런 도구가 상상되는지 배경을 넓혀 두었습니다.
2. 배경: 수어 통역이 필요한 자리, 그리고 현실
2-1. 국가 통계가 보여 주는 ‘필요’의 크기
국립국어원이 발표한 「2023년 한국수어 활용 조사」 결과를 뉴시스가 정리한 바에 따르면, 조사 대상(만 20세 이상, 청각 관련 장애 정도가 심한 편으로 분류된 500명) 가운데 약 30%가 수어를 주된 의사소통 수단으로 사용하는 것으로 나타났습니다. 같은 기사에 따르면, 수어를 사용하는 응답자의 83.0%가 의료기관에서, 62.9%가 공공기관에서 수어 통역이 가장 필요하다고 답했습니다.
(출처: 뉴시스, 「청각장애인 30% 한국 수어 사용…의료기관 통역 서비스 필요 83%」, 2024년 6월 3일, 국립국어원 「2023년 한국수어 활용 조사」 인용)
이 숫자는 “모든 분이 같은 방식으로 소통한다”는 전제를 깨 줍니다. 말과 글이 중심인 서비스 창구와 수어가 익숙한 사람 사이에는, 구조적으로 시간이 더 걸리는 구간이 있다는 뜻이기도 합니다.
2-2. 지역에서 보도된 ‘통역 인력’의 밀도
인천 지역을 다룬 경기일보 집중취재에 따르면, 해당 지역 청각·언어 관련 등록 인구와 수어 통역사 수를 비교할 때 통역사 1명이 수백 명 단위를 담당하는 셈이 되고, 방문 통역 등을 쓰려면 1~2주 전 예약이 필요하다는 식의 불편이 제기되었습니다. 기사에는 급한 방문이 있을 때 배정이 맞지 않는 사례도 실려 있습니다.
(출처: 경기일보, 「인천 수어통역사 ‘태부족’…청각장애인 의사소통 사각지대」, 2025년 2월 2일)
이런 보도는 “한 도시의 이야기”에 그치지 않고, 통역이라는 공공 서비스가 물리적으로 촘촘하지 않을 때 개인이 겪는 마찰이 어떤 형태인지 보여 줍니다. 정책이 따라와야 할 부분과, 그 사이사이를 메우려는 기술·도구가 등장하는 이유가 여기에 있습니다. 도구가 정책을 대신할 수는 없지만, 선택지를 늘리는 실험은 병행될 수 있습니다.
2-3. 긴급 연락망 쪽의 제도적 보완
연합뉴스 보도에 따르면, 과학기술정보통신부와 소방청은 청각·언어 관련 장애가 있는 국민이 119에 영상 통화로 직접 신고할 수 있도록 손말이음센터와 119 종합상황실을 연계하는 시스템을 구축했다고 밝혔습니다. 과거에는 중계 기관을 거쳐 대신 신고하는 방식이어서 위치 정보 조회 등에 한계가 있었다는 설명도 덧붙었습니다.
(출처: 연합뉴스, 「청각·언어 장애인도 긴급상황서 119로 직접 전화하세요」, 2025년 4월 17일)
이 사례는 디지털 인프라가 ‘접근 방식’ 자체를 바꿀 수 있다는 점을 보여 줍니다. Sign Bridge와 직접 같은 레이어는 아니지만, “영상·실시간·직접 연결”이 왜 생명선과도 맞닿는 주제인지 이해하는 데 도움이 됩니다.
2-4. 제도와 방송: 한국수어를 둘러싼 큰 흐름(요지만)
한국수어는 「한국수화언어법」에 따라 공용어적 지위를 갖도록 제도화되어 있고, 방송·행사·재난 안내 등에서 수어 통역·노력 의무가 단계적으로 강화·확대되어 왔습니다. 미디어오늘 등은 재난 방송에서의 한국수어 의무화가 권고에서 법률로 상향되는 흐름을 다루기도 했습니다.
(출처 예: 미디어오늘, 「재난방송 한국수어 의무화…‘법률’로 지위 상향」 등)
이 글에서 제도 논의를 깊게 펼치지는 않겠습니다. 다만 “언어 권리”와 “정보 접근”이 법과 정책의 표면 위로 올라와 있다는 사실은, 개인이 만드는 앱도 그 방향성을 의식해야 한다는 뜻으로 짚어 둡니다.
2-5. 조사에서 함께 짚히는 ‘언어 선택’과 교육 지원
같은 뉴시스 기사에는 조사 응답의 다른 면도 실려 있습니다. 수어를 쓰는 응답자 가운데 한국수어를 가장 적절한 언어로 꼽은 비율이 **90.8%**에 달했다는 요약이 있습니다. 이어 한글(문자) 과 한국어(음성) 비중은 상대적으로 매우 작게 잡혀 있습니다. 또 수어 교원 양성·수어 교육 활성화가 한국수어를 보존·발전시키기 위해 필요한 일로 꼽힌 비율이 **56.0%**로 가장 높았고, 교육 시 지원으로는 수어로 수업이 가능한 교사 배치·수어 통역 서비스 등이 높은 응답을 받았다고 전합니다.
(출처: 뉴시스, 위와 동일 기사, 국립국어원 「2023년 한국수어 활용 조사」 인용)
이 부분은 기술 논의와 직접 겹치지 않아도, **“앱이 문자·음성·수어 영상을 오간다”**는 설계가 왜 단일한 답이 아닌 조합이어야 하는지 짚어 줍니다. 어떤 분은 수어가 가장 편하고, 어떤 분은 글자가 빠르며, 상황에 따라 섞어 쓰기도 합니다. 그래서 Sign Bridge는 한 방향만 고집하지 않고, 카메라 쪽과 말·글 쪽을 동시에 열어 두는 형태를 택했습니다.
2-6. 인용을 읽을 때의 주의
위에 인용한 보도와 조사는 특정 시점·특정 표본·특정 지역에 기반합니다. 전 국민의 보편 진리처럼 일반화할 수는 없습니다. 다만 **“통역 수요와 공급 사이에 긴장이 있다”**는 큰 그림을 잡는 데에는 도움이 됩니다. 이 글은 그 그림 위에 개인이 만든 보조 앱을 올려 놓고, 한계와 자리를 함께 이야기하고자 합니다.
3. 그럼에도 남는 ‘작은 틈’
병원 안내데스크, 은행 창구, 가족 식탁, 직장 팀 회의 자리까지 가지 않아도, 우리는 경험적으로 압니다. 통역사나 자막이 없는 짧은 순간에도 사람들은 서로 눈치를 보고, 말을 줄이고, 나중에 문자로 몰아서 설명합니다.
Sign Bridge가 겨냥하는 것은 그중에서도 특히 다음과 비슷한 순간입니다.
- 익숙하지 않은 상대에게, 수어로 된 짧은 말을 글·말로 빨리 옮기고 싶을 때
- 반대로, 말로 흘려보낸 문장을 짧은 수어 영상으로 보여 주어 분위기를 풀고 싶을 때
완전한 대화를 통째로 기계에 맡기는 상상은 이 글의 범위 밖입니다. 대신 단어 몇 개, 짧은 호출어 수준에서 시간을 벌고, 그다음에 통역·필담·다른 수단으로 넘어가는 다리를 떠올린 것입니다. 그래서 이름에 Bridge를 붙였습니다.
3-1. 상상해 볼 만한 장면들(소설이 아니라 ‘형태’만)
아래는 특정인을 가리키는 이야기가 아니라, 어떤 형태의 틈이 있는지 독자께서 떠올리시기 쉽게 적어 본 장면입니다.
가족 식탁
주말에 모였을 때, 한쪽은 수어로 짧게 감사 인사를 하고 다른 쪽은 말로 화제를 바꿉니다. 통역이 없으면 감사 인사가 공기 속에 남는 순간이 생깁니다. 이때 카메라로 한 번 비추어 글자와 소리로 옮겨 주면, 다음 말이 이어지기 쉬운 출발점이 될 수 있습니다.
병원·약국 안내
번호를 부르거나, 창구에서 한두 단어를 확인해야 할 때가 있습니다. 긴 설명은 통역이 맞지만, **“예약”“대기”“복용”**처럼 짧은 단서만 빨리 맞추면 줄 서는 동안 마음이 덜 조급해질 수 있습니다. 물론 진단·처방·동의는 앱에 맡기면 안 됩니다.
직장·모임
회의에서 짧은 동의나 거절을 표시할 때, 말과 수어가 동시에 오가지 않으면 리듬이 끊깁니다. 한쪽이 말로 요약한 뒤, 앱으로 짧은 수어 클립을 보여 주는 식의 보조는 분위기를 푸는 데 도움이 될 수도 있습니다. 반대로 기밀·논쟁·계약은 전혀 다른 통로를 써야 합니다.
일상 소매
카페에서 “포장”, “뜨겁게” 같은 짧은 옵션을 고를 때, 줄 뒤에 사람이 많으면 필담도 부담스럽습니다. 이때 단어 단위 도구가 시간을 벌어 줄 수는 있습니다. 다만 메뉴판 전체를 앱이 대신 설명한다는 기대는 버려야 합니다.
이 장면들의 공통점은 **“길고 섬세한 통역”이 아니라 “짧은 연결”**입니다. Sign Bridge가 겨냥하는 것도 그 층입니다.
3-2. 왜 ‘단어’에 집착하는가
한국수어는 말처럼 소리의 선으로 이어지지 않고, 공간·표정·손의 형태·움직임이 함께 어우러집니다. 문장 전체를 한 번에 기계가 읽어 내는 것은 아직도 연구 과제에 가깝고, 데이터와 윤리 논의도 크게 따라옵니다. 그래서 현실적인 타협점으로 단어 단위를 잡는 경우가 많습니다. 단어는 의미의 최소 덩어리에 가깝고, 영상 클립을 하나하나 준비하기에도 다루기 쉬운 크기입니다.
4. Sign Bridge가 하는 일: 방향이 두 갈래입니다
4-1. 수어 쪽에서 말·글 쪽으로
스마트폰 카메라로 손을 비춥니다. 앱 안에서는 먼저 손이 화면에서 어디에 있는지를 숫자로 잡아 냅니다. 눈으로 보기에는 연속된 동작이지만, 기계에게는 순간순간의 위치 묶음으로 기록됩니다. 그 묶음이 미리 만들어 둔 판별 모델에 들어가면, “지금 이 패턴은 어떤 단어에 가깝다”는 쪽으로 점수가 매겨집니다.
결과는 화면에 글로 나옵니다. 필요하면 음성 합성으로 읽어 주기도 합니다. 즉, 상대가 수어로 짧게 말했을 때 한 번 더 글자와 소리로 확인할 수 있는 통로를 열어 두는 셈입니다.
4-2. 말·글 쪽에서 수어 쪽으로
말로 입력하거나, 키보드로 문장을 적습니다. 앱은 문장을 단어 단위로 나눕니다. 미리 앱 안에 넣어 둔 단어별 수어 영상이 있으면, 그 순서대로 재생합니다. 상대가 수어를 읽을 수 있다면, 말로만 흘러가던 내용을 시각적으로 한 번 더 보여 줄 수 있습니다.
여기서 중요한 점은, 영상이 앱과 함께 배포되는 파일이라는 것입니다. 즉, 재생할 때마다 인터넷에서 큰 파일을 받아 오지 않아도 되도록 설계할 수 있습니다.
4-3. ‘통역 앱’이라고 부르기엔 이른 이유
위 두 갈래 모두 지원 단어가 정해져 있고, 문맥을 깊게 이해하지 못합니다. 농담, 관용 표현, 말 순서를 바꾼 표현까지 따라가지 못합니다. 그래서 이 글에서는 통역 앱이라는 말 대신 소통 보조, 짧은 다리라는 표현을 씁니다.
5. 왜 ‘구름’이 아니라 ‘폰 안’을 택했는지
5-1. 비용과 계정
영상을 서버로 보내 분석하면, 개발자 입장에서는 구현이 단순해질 수 있습니다. 하지만 사용자에게는 데이터 요금, 회원 가입, 서비스 종료까지 따라올 수 있습니다. Sign Bridge는 가능한 한 카메라 분석·단어 판별·영상 재생이 한 대의 기기 안에서 끝나도록 잡았습니다.
5-2. 촬영 영상이 밖으로 나가지 않게
의료·가정·직장 등 민감한 장면이 카메라에 잡힐 수 있습니다. 분석을 외부 서버에 맡기면, 약관과 보안 설계가 아무리 좋아도 심리적 부담은 남습니다. 온디바이스(기기 내 처리) 쪽은 “영상 파일 자체를 업로드하지 않는다”는 설명을 하기 쉬운 편입니다. 물론 완전한 프라이버시 보장은 마케팅 문구로 단정할 수 없고, OS·다른 앱·기기 설정의 영향도 있습니다. 다만 설계 방향으로 ‘외부 전송을 줄인다’는 선택은 분명합니다.
5-3. 음성 입력(STT)만은 예외에 가깝다
말을 글로 바꾸는 기능은 휴대폰 제조사와 설정에 따라 기기 안에서 끝나기도 하고, 네트워크를 쓰기도 합니다. 사용자 입장에서는 “앱은 온디바이스인데 왜 음성만 불안하지?”라는 느낌이 들 수 있어, 솔직히 예외 구간이라고 밝히는 것이 맞습니다. 완전한 오프라인까지 공약으로 걸기 어렵다면, 설명 문구와 설정 안내로 기대치를 맞추는 일이 남습니다.
5-4. ‘무료’와 ‘공짜 노동’을 구분하기
라이브러리와 도구가 라이선스상 무료라는 것과, 데이터를 모으고 검수하는 일이 공짜라는 뜻은 아닙니다. 특히 수어 영상은 촬영·동의·라벨링에 사람의 시간이 듭니다. 이 글은 비용 계산서를 펼치지는 않겠지만, 독자께서 **“왜 상용 앱이 많지 않을까”**를 떠올리실 때 데이터 비용이 한 축이라는 점만 기억해 주시면 충분합니다.
5-5. 배터리와 발열을 일상어로
카메라를 켜 두고 연속으로 분석하면 배터리와 발열이 늘어납니다. 온디바이스 처리는 프라이버시 면에서 장점이 있어도, 기기 자원을 쓰는 대가는 있습니다. 사용 설명에 **“필요할 때만 켠다”**는 습관이 적힌 이유도 여기에 있습니다.
5-6. 접근성 설정과의 관계
글자 크기, 진동·소리, 자막 표시 등 OS가 제공하는 접근성 설정은 앱과 겹쳐서 작동합니다. Sign Bridge가 무언가를 더해 준다고 해서, 시스템 전체의 접근성 옵션을 대신한다는 뜻은 아닙니다. 둘 다 켜 두었을 때 더 편해지는 경우가 많다는 정도로 이해하시면 됩니다.
6. 비전문가를 위한 비유: 요리와 레시피
손 위치를 숫자로 잡아 내는 단계를 “재료 손질”에 비유해 보겠습니다. 생선을 사 와서 비늘을 벗기고, 뼈를 발라 내는 과정이죠. 기계는 이미지 전체를 한꺼번에 ‘이해’하기보다, 손가락 끝이 어디쯤 있는지 같은 정보로 바꿔 두고 다음 단계에 넘깁니다.
판별 모델은 “손질된 재료를 넣고, 어떤 요리 이름에 가까운지 맞혀 보는 단계”에 가깝습니다. 요리사가 아니라 표준화된 판정표를 들고 있는 평가자라고 생각하면 됩니다. 재료가 조금만 달라져도 점수가 흔들릴 수 있어, 같은 요리라도 주방 환경을 바꾸면 맛 평가가 흔들리는 것과 비슷합니다.
수어 영상 재생은 “완성된 요리 사진·영상을 순서대로 보여 주는 것”에 가깝습니다. 직접 요리하지 않고, 미리 찍어 둔 클립을 꺼내는 방식입니다.
6-2. 다른 비유: 악보 한 마디만 맞춰 보기
음악에 익숙한 분께는 이렇게 비유해 볼 수 있습니다. 손 위치 추출은 연주를 녹음한 뒤 음높이만 뽑아 표로 적는 일에 가깝고, 판별 모델은 그 표를 보고 **“이건 어떤 곡의 한 마디와 비슷하다”**고 맞히는 일입니다. 실제 연주에는 템포·감정·호흡이 있지만, 기계가 보는 표에는 숫자 열만 있습니다. 그래서 한 마디짜리 퀴즈에는 통할 수 있어도, 콘서트 전곡을 대신 연주하지는 못합니다.
6-3. 비유의 한계
요리·악보 비유는 이해를 돕기 위한 것이지, 수어를 요리나 음악의 하위 개념으로 줄이자는 뜻이 아닙니다. 수어는 언어이고, 문화와 정체성과 맞닿아 있습니다. 기술 설명을 쉽게 하려다 언어를 도구로만 보는 인상을 주고 싶지 않아, 이 문단을 비유의 경계로 명시해 둡니다.
7. ml-train 폴더와 재학습: ‘앱을 고치는 사람’이 쓰는 공간
이제부터는 IT를 하지 않는 분도 흐름만 가져가실 수 있게, 프로젝트 안의 ml-train과 여러 스크립트가 하는 일을 길게 설명하겠습니다. 파일 이름은 실제 저장소에 있는 것과 같게 적되, 실행 방법을 복사해 쓰라는 뜻은 아닙니다. “이런 단계가 있다”는 지도를 보는 정도로 읽어 주시면 됩니다.
7-1. 왜 폴더가 따로 있을까
앱 스토어에 올라가는 파일은 이미 학습이 끝난 판별 모델과 라벨 목록, 영상 파일 위주입니다. 반면 개발자는 새 단어를 넣거나, 촬영 환경이 바뀌어 성능이 떨어졌을 때 모델을 다시 만들고 싶을 수 있습니다. 그때마다 앱 화면만 만져서는 해결되지 않습니다. 컴퓨터에서 데이터를 모으고, 모델을 다시 굽는 공간이 필요한데, 그 역할을 하는 것이 ml-train 쪽 작업들입니다.
7-2. 영상에서 ‘손질된 숫자 묶음’을 뽑는다
대표적으로 extract_mediapipe_from_videos.py 같은 스크립트는, 여러 영상 파일을 읽어 들여 프레임마다 손 위치 정보를 뽑아 하나의 학습용 묶음(예: NPZ 형태)으로 저장하는 식의 역할을 합니다. 비유하자면, 수십 개의 요리 영상을 전부 재료 목록 표로 바꿔 엑셀 한 장에 모아 두는 작업에 가깝습니다.
이때 중요한 것은 앱에서 쓰는 것과 같은 손 추적 방식을 쓰는 편이 낫다는 점입니다. 학습 때와 실행 때 규칙이 다르면, 시험에서는 잘 되다가 실제 앱에서는 잘 안 되는 간극이 생깁니다.
7-3. 묶음을 넣고 모델을 ‘다시 굽는다’
train_from_npz.py, train_subset_from_npz.py 같은 이름의 스크립트는, 앞에서 만든 학습용 묶음을 입력으로 받아 새 판별 모델을 만들어 냅니다.
- 단어 종류가 많을 때와, 소수의 단어만 따로 정확히 맞추고 싶을 때는 설정이 달라질 수 있습니다.
- train_subset_from_npz.py는 이름 그대로 부분 집합(Subset) 용 학습에 쓰일 수 있게 만들어 둔 스크립트라고 이해하시면 됩니다.
학습이 끝나면 TensorFlow Lite 형태의 가벼운 모델 파일과, 어떤 줄이 어떤 단어인지 적어 둔 라벨 파일 등이 나옵니다. 이것들이 앱의 assets 쪽으로 옮겨지면, 사용자가 받는 앱의 판별 성격이 바뀝니다.
7-4. 앱에 이미 들어 있는 영상만으로 빠르게 돌려 보기
retrain_subset_from_app_assets.sh 같은 셸 스크립트는, 개발용으로 앱에 이미 포함된 짧은 영상만으로 추출·학습·복사까지 한 번에 시도해 보라는 성격의 도우미입니다. 데이터가 매우 적을 때는 과적합(특정 영상에만 맞춰져서 다른 환경에서는 흔들리는 현상) 위험이 크다는 점이 문서에도 적혀 있습니다. 즉, **“돌아가는 파이프라인을 검증한다”**에는 유용하지만, **“품질이 좋은 제품 모델이 나왔다”**고 단정할 수는 없습니다.
7-5. 검증·데모용 스크립트
generate_demo_npz_for_subset_train.py는 이름에서 알 수 있듯 데모·스모크 테스트용으로 쓰라고 명시된 스크립트입니다. 실제 배포용 모델 학습에 쓰지 말라는 경고가 프로젝트 문서에도 있습니다. 비유하자면 무대 리허설용 소품이고, 본공연 의상과 혼동하면 안 됩니다.
validate_word_assets.py 등은 단어 ID, 파일 이름, 표시 이름이 서로 어긋나지 않았는지 확인하는 데 쓸 수 있습니다. 단어가 늘어날수록 사람이 실수하기 쉬운 지점이라, 자동으로 한 번 훑는 장치가 있는 셈입니다.
7-6. 데이터가 다양해질수록 좋아지는 이유를 일상어로
같은 단어라도 사람마다 손 크기, 속도, 각도, 배경 밝기가 다릅니다. 학습 묶음에 한 가지 화면만 반복으로 들어 있으면, 모델은 그 화면에만 맞춰져 버립니다. 그래서 장기적으로는 여러 사람, 여러 조명, 여러 거리의 클립을 쌓는 것이 중요합니다. 이 문장은 기술 자랑이 아니라 사진관에서 증명사진 찍을 때도 통하는 이야기입니다. 한 벽·한 조명에만 익숙해지면, 다른 곳에 서면 얼굴이 어둡게 나옵니다.
7-7. 앱 쪽에서 안정화를 돕는 상식
모델 바깥에서도, 손 떨림에 가까운 흔들림을 부드럽게 만드는 처리(지수이동평균 같은 개념), 너무 자주 바뀌는 판정을 잠그는 히스테리시스, 손이 잠깐 안 잡혔을 때 바로 ‘없음’으로 바꾸지 않는 디바운스 같은 장치가 들어갈 수 있습니다. 비전문가에게는 “깜빡이는 표시등을 조금 부드럽게 만드는 전기 기사의 손길” 정도로 이해하셔도 됩니다. 근본적인 인식 한계를 없애지는 못하지만, 쓸 때 신경이 덜 쓰이게 하는 쪽의 개선입니다.
7-8. 다른 원천 데이터와 비교 검증을 돕는 스크립트
프로젝트에는 train_from_nia_keypoints.py처럼, 특정 공개 데이터 형식(예: 키포인트가 이미 정리된 경우)을 출발점으로 삼아 학습을 시도해 볼 수 있는 스크립트도 함께 둘 수 있습니다. 또 verify_nia_vs_mediapipe_visual.py처럼, 서로 다른 방식으로 뽑은 손 위치 정보가 같은 영상에서 얼마나 비슷한지를 눈으로 확인하는 데 쓰는 도구가 있을 수 있습니다.
비전문가에게 필요한 메시지는 하나입니다. **“데이터를 만드는 규칙이 조금만 달라도, 모델이 배우는 세계가 달라진다”**는 점입니다. 그래서 앱에 넣는 최종 모델을 만들 때는 앱과 같은 규칙으로 뽑은 데이터를 우선하는 편이 안전합니다.
7-9. 화면에 보이는 이름과 내부 ID를 맞추는 일
수어 단어에는 시스템 안에서 쓰는 ID와 사람에게 보여 주는 이름이 따로 있을 수 있습니다. extract_word_display_from_morpheme.py 같은 스크립트는, 형태소·사전 정보에서 표시용 이름을 뽑아 표기를 통일하는 데 도움을 줄 수 있습니다. 사용자는 이 과정을 보지 못하지만, 단어 목록 화면이 흔들리지 않게 하려는 정리 작업에 해당합니다.
7-10. ‘클립이 train과 val에 섞이지 않게’ 같은 룰
학습용 데이터를 나눌 때, 같은 영상에서 뽑은 프레임이 연습용(train)과 시험용(validation)에 동시에 들어가면, 점수가 허상으로 좋아 보일 수 있습니다. 그래서 파이프라인 문서에는 클립 단위로 나눈다는 식의 규칙이 적혀 있습니다. 비유하자면 같은 문제지를 풀고 나서 그 문제지로 시험을 보는 것과 비슷한 착시를 막으려는 장치입니다.
7-11. 소수 단어만 쓸 때의 ‘subset’ 전략을 일상어로
단어 종류가 아주 많으면, 모델은 클래스가 많은 다지선다에 가까워져서 데이터가 부족할 때 더 흔들립니다. 반대로 당장 앱에서 쓰는 세 단어만 정확히 맞추고 싶다면, 그 세 단어만을 위한 작은 모델을 따로 굽는 전략이 있습니다. 프로젝트 문서에는 subset 전용 파일과 전체 모델에 마스킹을 걸어 후보를 줄이는 식의 우회도 함께 정리되어 있습니다.
비유하자면, 백과사전 한 권을 들고 시험을 보는 대신, 자주 쓰는 단어장 세 장만 들고 가는 선택입니다. 범위는 줄지만, 그 안에서는 집중해서 맞출 여지가 생깁니다.
7-12. 파이프라인을 한 줄로 요약하면
영상 → (손 위치 추출) → 숫자 묶음 → (학습) → 가벼운 모델 파일 → 앱에 넣기
여기에 이름 정리·검증·데모용 데이터는 데모용이라는 주의가 붙습니다. 이 한 줄만 기억하셔도, 나중에 뉴스에서 **“AI 수어 인식”**이 나올 때 어떤 단계가 숨어 있는지 짐작하시는 데 도움이 됩니다.
8. 지원 단어와 저작권, 그리고 ‘하지 말아야 할 기대’
8-1. 단어 목록이 곧 울타리
앱이 아는 것은 미리 등록된 단어뿐입니다. 새 신조어, 고유명사, 감정을 한꺼번에 담은 긴 문장은 기대하지 않는 것이 좋습니다. 가족끼리라도 자주 쓰는 호칭·짧은 요청부터 목록에 올리는 식의 현실적인 설계가 필요합니다.
8-2. 수어 영상·학습 데이터의 조건
수어 영상은 저작권·초상·이용 허락 문제와 맞닿습니다. 공개 데이터를 쓰더라도 라이선스를 읽고, 상업적 이용·재배포 조건을 지켜야 합니다. 이 글은 법률 자문이 아니므로 구체적 계약 내용까지 나가지는 않겠습니다. 다만 **“일단 인터넷에서 가져왔다”**로는 끝낼 수 없는 영역이라는 점만 분명히 해 두고 싶습니다.
8-3. 통역사·수어 사용자 커뮤니티를 대신할 수 없다
기계 보조는 빠른 단서를 줄 수 있어도, 문화적 뉘앙스·권리 관점·현장 윤리까지 대신하지 못합니다. 특히 공공 서비스·의료·법률 같은 자리에서는 제도적으로 마련된 통역이 우선입니다. Sign Bridge 같은 실험은 그 앞을 막는 장벽이 되어서는 안 된다고 생각합니다. 도구는 선택지이지, 의무의 대체재가 아닙니다.
8-4. ‘정확도’라는 말을 함부로 쓰지 않기
마케팅에서는 정확도 99% 같은 숫자가 쉽게 나옵니다. 하지만 어떤 데이터로, 누구의 손으로, 어떤 조명에서 잰 숫자인지에 따라 의미가 완전히 달라집니다. 이 글에서는 구체적인 백분율을 적지 않습니다. 대신 환경이 바뀌면 흔들릴 수 있다는 점과, 소수의 클립만으로는 일반화가 어렵다는 점을 반복해 말합니다.
8-5. 당사자 참여 없이 ‘편의’를 정의하지 않기
기능을 추가할수록 누구에게 편한지를 묻지 않으면, 오히려 불편을 고정할 수 있습니다. 버튼 배치, 글자 크기, 기본 모드가 말 중심인지 수어 중심인지 같은 문제는 실제 사용 흐름을 보며 조정하는 편이 안전합니다. 이 글은 제품 기획서가 아니므로 결론을 대신 내리지 않겠습니다. 다만 **“만들기 전에 묻는다”**는 태도를 권합니다.
9. 자주 묻게 될 질문(비개발자용 Q&A)
Q. 이 앱만 있으면 통역사가 필요 없나요?
아니요. 긴급·의료·법·교육 등에서는 제도적으로 준비된 통역과 상담이 우선입니다. 앱은 짧은 단서를 주는 보조에 가깝습니다.
Q. 왜 문장 전체를 한 번에 못 하나요?
수어는 공간과 동작의 연쇄로 의미가 쌓입니다. 문장 전체를 안정적으로 읽으려면 데이터·연산·윤리 모두에서 난제가 큽니다. 그래서 현실적인 출발점으로 단어를 잡는 경우가 많습니다.
Q. 카메라가 부끄러운데요?
그럴 수 있습니다. 도구는 원할 때만 쓰는 것이 맞고, 필담·통역·다른 방법이 더 편하면 그쪽을 택해야 합니다. 기술은 선택지를 늘리는 것이지, 하나의 방식을 강요하면 안 됩니다.
Q. 인터넷이 끊기면 다 되나요?
수어 인식·영상 재생·기기 안의 음성 합성 쪽은 오프라인으로 설계할 여지가 큽니다. 다만 말을 글로 바꾸는 기능은 기기에 따라 네트워크를 탈 수 있어, 항상 동일하다고 말하기 어렵습니다.
Q. 다른 가족도 같은 앱을 써야 하나요?
아닙니다. 한 사람이 중간에서 짧게 옮겨 주는 도구로 쓸 수도 있고, 서로 각자 편한 방식을 고를 수도 있습니다.
Q. ml-train 폴더는 뭔가요?
앱 안에 들어가기 전에, 컴퓨터에서 데이터를 정리하고 모델을 다시 만드는 작업을 모아 둔 공간입니다. 일반 사용자가 꼭 볼 필요는 없습니다.
Q. 스크립트 이름이 왜 이렇게 길고 많나요?
각각 한 가지 일만 하게 나누어 두면, 중간에 잘못되었을 때 어느 단계에서 꼬였는지 찾기 쉽습니다. 비유하자면 요리마다 도마를 바꾸는 것과 비슷합니다.
Q. 데이터를 많이 넣으면 무조건 좋아지나요?
같은 화면만 반복으로 많이 넣으면 오히려 그 화면에만 맞는 모델이 될 수 있습니다. 다양한 사람·환경이 섞인 데이터가 더 중요합니다.
Q. 수어 영상을 마음대로 올려도 되나요?
저작권·초상·동의를 확인해야 합니다. 공개 데이터라도 라이선스 조항을 읽어야 합니다.
Q. 앱이 틀리면 누가 책임지나요?
이 글은 법적 해석을 제공하지 않습니다. 다만 중요한 결정은 기계 출력을 그대로 믿지 말고 사람이 확인하는 것이 안전합니다.
10. 이런 앱을 쓸 때 마음가짐(비개발자용 체크리스트)
- 짧게 쓴다: 한 번에 옮기려는 말을 길게 늘리지 않는다.
- 환경을 맞춘다: 너무 어둡거나, 카메라가 너무 멀지 않게 한다. 손이 프레임 안에 들어오게 한다.
- 결과를 그대로 믿지 않는다: 특히 의료·안전·법적 표현은 전문 통로를 탄다.
- 상대의 선호를 묻는다: 수어·필담·통역 중 무엇이 편한지는 당사자에게 확인한다.
- 주변 소음을 고려한다: 음성 입력은 주변 소음에 민감할 수 있다.
- 배터리를 본다: 오래 켜 두면 소모가 크다.
- 업데이트 노트를 읽는다: 지원 단어·동작이 바뀔 수 있다.
- 사진·영상 공유 습관을 점검한다: 화면 녹화를 SNS에 올릴 때 다른 사람의 얼굴·손이 포함되지 않았는지 본다.
11. 글을 읽은 뒤에도 남는 숙제
첫째, 제도가 커지는 방향(119 연계, 방송·행사에서의 수어 노력 등)을 뉴스로만 소비하지 말고, 지역·분야에서 무엇이 막히는지를 한 번쯤 적어 보는 일입니다. 둘째, 가까운 관계 안에서 어떤 순간에 말이 앞서고 수어가 뒤로 밀리는지 관찰해 보는 일입니다. 셋째, 기술을 만든다면 데이터 동의·출처 표기·오류 시 안내를 기능과 같은 높이에 두는 일입니다.
이 세 가지는 Sign Bridge와 무관하게도 의미 있는 숙제입니다.
12. 마무리: 다리는 하나가 아니어도 된다
Sign Bridge는 말과 수어가 섞인 자리에서 시간을 조금 벌어 주는 실험에 가깝습니다. 국립국어원 「2023년 한국수어 활용 조사」를 뉴시스가 정리한 바에 따르면, 수어를 주된 소통 수단으로 쓰는 비율과 의료·공공에서 통역이 필요하다는 응답이 동시에 드러납니다. 경기일보가 인천을 사례로 집중 취재한 기사는 통역 인력 밀도와 예약이 현실에서 어떤 마찰을 만드는지 보여 줍니다. 연합뉴스가 전한 119·손말이음센터 연계 보도는 디지털 인프라가 접근 방식을 바꿀 수 있다는 희망을 함께 제시합니다.
이 흐름들은 서로 다른 층에 있습니다. 법·방송·응급은 국가와 기관이 책임지는 축이고, 가족·직장·일상 창구에서는 개인이 당장 쓸 수 있는 도구를 찾게 됩니다. Sign Bridge는 후자의 한 예시로, 온디바이스와 단어 단위라는 제약을 스스로 걸고 그 안에서 무엇을 할 수 있는지를 시험한 것입니다.
기술 쪽에서는 ml-train과 재학습 스크립트가 “앱을 한 번 출시하고 끝”이 아니라, 단어와 데이터가 바뀔 때 다시 연결할 수 있는 줄기라는 것을 이 글에 길게 써 두었습니다. extract_mediapipe_from_videos.py, train_from_npz.py, train_subset_from_npz.py, retrain_subset_from_app_assets.sh, generate_demo_npz_for_subset_train.py, validate_word_assets.py 같은 이름들은, 독자께서 외울 필요가 없습니다. **“단계가 나뉘어 있고, 데모용과 본용이 구분된다”**는 인상만 가져가셔도 충분합니다.
같은 문제의 다른 앱·서비스·정책이 함께 성장할수록, 사용자는 자기 상황에 맞는 조합을 고를 수 있습니다. Sign Bridge는 그중 하나의 작은 선택지가 되기를 바랍니다. 이 글은 저장소 주소나 일정을 밝히지 않되, 공개 보도와 조사를 인용해 배경을 넓혔고, 한계와 윤리를 숨기지 않으려 했습니다. 여기까지 읽어 주셔서 고맙습니다.