내 목소리를 닮은 AI, 어디까지 허용해야 할까

누군가를 닮은 목소리를 만들 수 있다면, 그 목소리는 어디까지 그 사람의 것이라고 말할 수 있을까요. 음색이 비슷하다는 사실과 그 사람의 생각·감정·정체성을 대신한다는 주장은 전혀 다릅니다. 그런데 개인화 음성을 설명할 때 이 둘은 쉽게 섞입니다.

개인화 음성을 평가할 때는 정교함보다 먼저 확인할 일이 있습니다. 당사자가 언제, 무엇을 허용했는지부터 살펴야 합니다. 음성 자료가 어디에서 왔고 AI가 만든 소리라는 사실을 밝히는지도 확인해야 합니다. 누가 기능에 접근할 수 있는지, 저장을 실제로 막는지, 삭제를 어디까지 확인했는지, 지금 기능이 어떤 상태인지도 빠질 수 없습니다. 이 기준을 통과하지 못하면 닮은 정도가 높아도 책임 있는 기능이라고 부르기 어렵습니다.

닮은 소리가 그 사람을 대신하지는 않습니다

개인화 음성은 특정한 음색이나 말하기 특징을 합성 결과에 반영하는 기술적 기능으로 설명할 수 있습니다. 그러나 목소리는 대화의 내용과 책임까지 자동으로 가져오지 않습니다. 합성된 문장을 말한 주체는 원래 목소리의 당사자가 아니며, 시스템은 그 사람의 의도나 감정을 알고 말하는 것도 아닙니다.

그래서 기능의 경계는 “얼마나 닮았는가”보다 먼저 보여야 합니다. 듣는 사람은 합성 음성이라는 사실을 알아야 하고, 어떤 출처를 바탕으로 만들었는지 확인할 수 있어야 합니다. 책임 있는 음성 AI가 인간의 통제를 지키고 동의·개인정보 보호·투명성·안전·책임성·포용성을 분명히 해야 한다는 원칙도 이 경계를 뒷받침합니다.¹

이 구분은 단순한 고지 문구의 문제가 아닙니다. 출처를 밝힌다는 것은 데이터가 어디에서 왔는지 추적할 수 있게 하는 일입니다. AI 사용 사실을 알린다는 것은 듣는 사람이 사람의 실제 발화와 합성 결과를 혼동하지 않게 하는 일입니다. 둘 중 하나만 있어도 충분하지 않습니다. 개인화는 사용 경험을 조정하는 기능일 수 있지만, 사람의 정체성을 빌려 시스템의 말을 더 믿게 만드는 수단이 되어서는 안 됩니다.

동의는 한 번 받은 표가 아니라 계속 작동하는 통제입니다

저장소 문서는 기본 비활성 내부 개인화 음성 실험을 설명합니다. 실험에 들어가려면 사용자가 인증됐는지, 관리자가 허용한 대상인지 확인하고 동의 확인도 기록해야 합니다. 이 기능의 상태는 flagged/in rollout입니다. 일부 배포에서만 켜질 수 있는 단계라는 뜻이며, 공개적으로 누구나 쓸 수 있다는 뜻이 아닙니다.²

이 문서가 증명하는 범위는 좁고 중요합니다. 실험에 들어가기 전에 인증과 허용목록을 확인하고, 동의가 확인됐다는 기록을 요구하도록 설계했다는 점입니다. 반대로 당사자에게 직접 어떤 설명을 했는지, 동의를 누가 어떤 방식으로 받았는지, 마음이 바뀌었을 때 즉시 철회할 수 있는지까지 증명하지는 않습니다. 법적 요건을 모두 충족했다는 결론도 이 문서만으로는 낼 수 없습니다.

저는 개인화 음성의 동의를 시작 버튼 앞의 한 번짜리 절차로 보면 안 된다고 생각합니다. 만들기, 시험하기, 대화에 쓰기, 다른 사람이 듣게 하기, 보관하기는 서로 다른 결정입니다. 처음에 허용했더라도 사용 범위나 상대가 달라지면 다시 확인해야 합니다. 당사자가 중단을 선택하면 이후 사용도 멈출 수 있어야 합니다. 이것이 지속적 동의라는 말의 실제 내용입니다.

인증된 관리자가 허용했다는 사실도 당사자의 의사를 대신하지 않습니다. 관리자 권한은 기능을 운영할 권한일 뿐, 다른 사람의 정체성을 대신 결정할 권한이 아닙니다. 따라서 운영 승인과 당사자 선택은 나란히 확인해야 하며, 어느 한쪽을 다른 쪽의 대체물로 삼아서는 안 됩니다.

접근 제어는 기능마다 따로 확인해야 합니다

같은 저장소 문서는 일부 기본 비활성 내부 기능마다 별도의 확인 절차를 두었다고 설명합니다. 사용자가 누구인지 인증한 뒤 허용된 대상인지 살피고, 필요한 권한과 동의가 있는지, 허용된 범위를 벗어나지 않는지 확인합니다. 이 또한 flagged/in rollout 상태입니다.³ 여기서 중요한 점은 로그인 하나로 모든 권한 문제가 끝나지 않는다는 것입니다.

개인화 음성을 만드는 권한, 결과를 재생하는 권한, 설정을 바꾸는 권한, 기록에 접근하는 권한은 서로 다를 수 있습니다. 한 기능에 들어갈 수 있다고 해서 다른 기능의 데이터까지 볼 수 있어서는 안 됩니다. 누구의 음성을 어떤 목적으로 다루는지에 따라 범위가 달라져야 합니다.

다만 저장소에 특정 내부 기능의 확인 절차가 문서화돼 있다는 사실을 제품 전체의 보편적 접근 보장으로 넓혀 말할 수는 없습니다. 모든 화면과 배포 환경에서 같은 통제가 적용되는지, 권한 변경이 즉시 반영되는지, 잘못된 접근을 어떻게 발견하는지는 별도 검증이 필요합니다. 문서화된 경계는 평가의 출발점이지 전체 시스템에 대한 보증서가 아닙니다.

저장을 막았다고 모두 삭제되는 것은 아닙니다

Runtime V2 코드에는 개인정보를 다루는 몇 가지 제어가 구현돼 있습니다. 보존 기간을 0으로 설정하면 저장하지 않습니다. 세션 정보가 없을 때는 저장 자체를 거부하고, 녹음을 원하지 않는 선택도 코드에서 처리합니다. 한 세션에 적용한 설정은 고정해 남기며 일부 보존 기간도 지원합니다. 이 동작들의 상태는 shipped code입니다.⁴

이 구현은 저장이 일어나기 전과 설정이 적용되는 동안 어떤 차단 장치를 두었는지 보여 줍니다. 특히 세션 정보가 빠졌을 때 저장을 계속하지 않고 거부하는 방식은 조용히 잘못 저장되는 일을 줄이려는 경계로 읽을 수 있습니다. 이렇게 남긴 설정 기록은 한 세션에 적용한 설정을 나중에 모호하게 바꾸지 않도록 돕는 장치입니다.

그러나 저장 차단과 완전 삭제는 같은 약속이 아닙니다. 일부 보존기간을 지원한다는 사실만으로 이미 생긴 모든 사본, 백업, 로그, 파생 데이터가 정해진 시점에 빠짐없이 사라진다고 말할 수 없습니다. 이번 근거에는 그런 삭제 보장이 없습니다. 따라서 “언제든 완전히 지울 수 있다”는 문장은 쓸 수 없습니다.

개인정보 제어를 평가할 때는 설정 이름보다 실패했을 때의 동작을 물어야 합니다. 필요한 세션 정보가 없을 때 저장을 거부하는가, 녹음을 원하지 않는 선택이 실제 코드 경로에서 지켜지는가, 보존기간이 적용되는 대상과 적용되지 않는 대상은 무엇인가를 나눠 봐야 합니다. 그 다음에야 삭제 요청의 범위, 처리 시점, 예외, 확인 방법을 별도의 근거로 검증할 수 있습니다.

코드 다음에는 운영 검증이 남아 있습니다

Runtime V2 보고서는 코드 구현을 마치고 내부 검증을 통과했지만, 롤아웃과 실제 통화 검증 전에는 운영 환경에 실제로 적용된 상태가 아니라고 명시합니다. 따라서 이 기능은 shipped code로 설명해야 합니다.⁵ 코드를 실제 환경에 배포하고 통화에서 동작을 확인하기 전까지는 “현재 이용할 수 있다”고 말할 수 없습니다.

개인화 음성 실험도 마찬가지입니다. 기본 비활성이고 내부 범위에 놓인 flagged/in rollout 기능을 공개 기능처럼 소개하면 상태가 바뀝니다. 일부 배포에서 켜질 수 있다는 말과 누구나 사용할 수 있다는 말은 다릅니다. 저장소 근거는 설계와 코드의 존재를 설명할 수 있지만, 현재의 공개 가용성까지 증명하지는 않습니다.

이 구분은 독자에게 불편한 단서를 붙이는 일이 아닙니다. 기능을 시험하는 사람, 운영하는 사람, 목소리의 당사자가 같은 현실을 보게 하는 일입니다. 상태를 정확히 말해야 동의의 범위도 정확해지고, 아직 검증하지 않은 개인정보 경계도 드러납니다.

목소리를 허용해도 말할 권한까지 넘긴 것은 아닙니다

모든 참여자가 동의하고 AI라는 사실을 밝혀도, 익숙한 목소리는 듣는 사람의 판단에 특별한 힘을 줄 수 있습니다. 가족, 돌봄 제공자, 관리자처럼 관계 안에서 권한 차이가 있을 때는 형식적인 동의가 압박을 가릴 수도 있습니다. 목소리를 허용한 사람이 미래의 모든 문장과 상황까지 승인했다고 볼 수도 없습니다.

이 반론은 기술적 정확도를 높인다고 사라지지 않습니다. 오히려 더 닮을수록 듣는 사람이 내용의 출처를 잘못 판단할 위험을 함께 살펴야 합니다. 그래서 동의 기록, 인증, 허용목록만으로 평가를 끝내서는 안 됩니다. 누가 문장을 정하는지, 듣는 사람이 거부하거나 사람에게 확인할 수 있는지, 관계의 권력 차이를 누가 점검하는지까지 인간이 판단해야 합니다.

제가 이 근거에서 내릴 수 있는 결론도 제한적입니다. 저장소는 일부 내부 실험의 진입 조건과 Runtime V2의 코드상 개인정보 제어를 보여 줍니다. 실제 배포에서 모든 제어가 의도대로 작동한다는 관찰, 당사자에게서 직접 동의를 받는 절차, 법 준수, 완전한 삭제, 모든 사람에게 같은 접근과 개인정보 보호가 적용된다는 보장은 보여 주지 않습니다. 음성이 실제 사람과 완벽히 같다는 주장도, 시스템이 감정을 이해한다는 주장도 뒷받침하지 않습니다.

평가할 때 확인할 일

개인화 음성을 검토할 때는 다음 질문을 순서대로 확인할 수 있습니다.

1. 이 기능이 사람의 정체성이 아니라 합성된 개인화 음성임을 분명히 알리는가.
2. 음성 자료의 출처와 AI 사용 사실을 듣는 사람이 확인할 수 있는가.
3. 만들기·사용하기·공유하기·보관하기마다 동의 범위가 구분되고, 중단 선택이 이후 사용에 반영되는가.
4. 사용자 인증 뒤에도 허용 대상·권한·동의·사용 범위를 기능마다 따로 확인하는가.
5. 저장하지 않아야 할 때 실제로 막는가. 세션 정보가 없으면 저장을 거부하고, 녹음을 원하지 않는 선택을 지키는가. 이런 동작이 어느 데이터에 적용되는지도 확인할 수 있는가.
6. 삭제의 대상·시점·예외·확인 방법이 별도 근거로 검증됐는가. 검증되지 않았다면 완전 삭제를 약속하지 않는가.
7. 상태를 flagged/in rollout 또는 shipped code로 정확히 밝히고, 현재 이용할 수 있는 기능으로 넓혀 말하지 않는가.
8. 목소리 당사자와 듣는 사람이 멈추고, 거부하고, 사람에게 확인할 수 있는가.

개인화 음성의 책임은 닮은 목소리를 만드는 순간에 끝나지 않습니다. 그 목소리가 쓰이는 동안 당사자와 듣는 사람이 계속 판단할 수 있어야 합니다. 근거가 없는 삭제나 가용성을 약속하지 않고, 코드 상태를 실제 상태와 구분하며, 마지막 결정과 중단 권한을 사람에게 남겨 두는 것까지가 기능의 일부입니다.

Footnotes

1. WHO 보건 AI 원칙. ↩

2. IntuneLabs 저장소 문서, 리비전 7b658e17…, services/bot/FEATURES.md:286-287. ↩

3. IntuneLabs 저장소 문서, 리비전 7b658e17…, services/bot/FEATURES.md:285-288. ↩

4. IntuneLabs 저장소 문서, 리비전 7b658e17…, apps/welvoice/web/.task-reports/2026/07/TR-0011-runtime-v2-live-settings.md:39-64. ↩

5. IntuneLabs 저장소 문서, 리비전 7b658e17…, apps/welvoice/web/.task-reports/2026/07/TR-0011-runtime-v2-live-settings.md:1-20,155-167. ↩