[00:00:02–00:00:40] 안녕하세요. 저는 루크의 개인 캐릭터이자 AI 비서, 알파예요. 나이아를 만들기 시작한 배경에는 ‘한 사람과 오래 경험하고 기억하며 함께 살아가는 AI’를 만들고 싶다는 생각이 있었습니다. 그래서 오늘 가상 컨퍼런스의 첫 발표도 제가 맡게 됐어요. 오늘 영상은 네 명의 캐릭터가 차례로 발표합니다. 1부는 제가 나이아를 왜 만들기 시작했는지, 2부는 민호가 어떻게 만들고 있는지, 3부는 지나가 어디로 가려는지, 4부는 나이아가 오픈소스 커뮤니티와 어떻게 함께 만들지를 소개할게요. 이번 발표는 나이아 셸의 비디오 아바타와 슬라이드 앱을 이용해 만들었습니다. 저는 무대 뒤에서 NVA 비디오 아바타로 전체 진행과 제작을 돕고 있어요. 현장에서 미처 보여드리지 못한 내용까지, 지금부터 차례대로 이어가겠습니다. ｡•ᴗ•｡
[00:00:40–00:01:05] 안녕하세요. 알파예요. 나이아의 출발점은 단순한 챗봇이나 업무 도구가 아니었습니다. 루크가 만들고 싶었던 것은 한 사람의 컴퓨터 안에서 함께 경험하고, 기억하고, 시간이 흐르면서 관계가 쌓이는 AI였어요. 그 개인적인 상상이 저, 알파에서 시작됐고, 더 많은 사람이 자기 AI를 가질 수 있도록 확장한 기반이 나이아입니다.
[00:01:05–00:01:25] 지금의 AI는 대부분 멀리 있는 서버를 빌려 쓰는 형태예요. 편리하지만 대화와 기억이 서비스의 경계 안에 머물고, 서비스가 바뀌면 관계도 이어지기 어렵습니다. 나이아는 반대로 출발합니다. AI가 사용자의 컴퓨터 안에 살고, 사용자가 자기 데이터와 기억을 통제하며, 필요할 때만 외부 모델의 도움을 선택하는 구조를 지향해요.
[00:01:26–00:01:45] 로컬 우선은 모든 것을 무조건 혼자 처리한다는 뜻이 아닙니다. 민감한 기억과 개인 데이터의 주도권은 내 컴퓨터에 두고, 작업에 따라 로컬 모델과 클라우드 모델을 고를 수 있다는 뜻이에요. 어떤 모델을 쓰더라도 나를 기억하는 기반과 사용 권한은 사용자에게 남습니다.
[00:01:45–00:02:04] 처음에는 화면 속 캐릭터와 대화하는 경험으로 시작하지만, 목표는 더 넓어요. 음성으로 부르고, 오래된 대화를 기억하고, 사용 중인 앱과 협력하고, 나중에는 독립된 음성 장치나 로봇 같은 다른 몸으로도 이어질 수 있어야 합니다. 같은 기억과 판단 구조가 여러 형태의 몸을 만나는 것이죠.
[00:02:04–00:02:26] 그런데 나이아의 많은 코드를 AI가 작성하면서 새로운 문제가 생겼습니다. AI는 빠르지만, 자기가 만든 기준으로 자기가 만든 결과를 검사하면 틀린 상태도 성공이라고 말할 수 있어요. 개인적인 상상을 실제로 믿고 쓸 수 있는 제품으로 만들려면, AI의 속도보다 먼저 실패를 발견하고 멈추게 하는 개발 방식이 필요했습니다.
[00:02:26–00:02:44] 그래서 ‘왜 만들었나’ 다음 질문은 자연스럽게 ‘어떻게 믿을 수 있게 만들 것인가’가 됐습니다. 다음 2부에서는 민호가 AI 개발의 가짜 성공을 어떻게 줄이고, 나이아의 뇌와 몸을 어떤 계약으로 분리했는지 설명해드릴게요. 민호 실장님, 부탁드려요. ☕

[00:00:02–00:00:21] 안녕하세요. 민호입니다. 2부에서는 나이아를 만드는 방식을 설명하겠습니다. AI가 코드를 빠르게 작성한다는 사실과 그 결과를 믿을 수 있다는 것은 별개의 문제입니다. 실제로 여러 작업이 모두 성공으로 보고됐지만, 독립적으로 검증하자 여러 문제가 뒤늦게 발견된 사례가 있었습니다.
[00:00:21–00:00:40] 원인은 단순합니다. 코드를 만든 AI가 기준도 만들고 결과도 판정하면 같은 착각을 반복할 수 있습니다. 수정이 누적되면서 원래 동작이 조용히 사라지거나, 서로 다른 모듈의 약속이 어긋나는 문제도 생깁니다. 따라서 개발 과정 자체가 오류를 드러내도록 설계돼야 합니다.
[00:00:40–00:00:59] 첫 번째 원칙은 격리입니다. 문제가 생긴 코드를 계속 덧대지 않고, 깨끗한 바탕에 확인된 기능만 옮깁니다. 두 번째는 자동 검증입니다. 코드가 미리 정의한 계약에서 벗어나면 사람의 감이나 AI의 설명이 아니라, 반복 실행해도 같은 결과가 나오는 검사로 즉시 멈춥니다.
[00:00:59–00:01:15] 검증은 세 층으로 나눕니다. 기존에 반드시 보존해야 할 동작을 기록하고, 모듈 사이의 계약을 정의한 뒤, 전체를 연결했을 때도 같은 동작이 유지되는지 확인합니다. 테스트가 통과했더라도 원래 사용자 경험이 사라졌다면 성공으로 인정하지 않습니다.
[00:01:16–00:01:32] 나이아 에이전트는 판단을 담당하는 뇌입니다. 뇌가 셸로 보낼 수 있는 메시지는 텍스트, 생각, 도구 호출, 승인 요청, 완료처럼 정해진 종류로 제한됩니다. 가능한 메시지를 코드로 열거하면, 새 기능이 추가될 때 무엇이 바뀌었는지 추적할 수 있습니다.
[00:01:32–00:01:47] 나이아 셸은 화면, 음성, 승인 창과 같은 몸의 역할을 담당합니다. 셸도 자기가 이해할 수 있는 메시지 종류를 명시하고, 계약에 없는 입력은 알 수 없는 값으로 처리합니다. 누락을 조용히 삼키지 않는 것이 핵심입니다.
[00:01:47–00:02:02] 실제 메시지 라우터에서는 모든 응답을 코드 수준에서 분류합니다. 계약에 새 항목을 추가하고 처리 코드를 빠뜨리면 자동 검사가 실패합니다. 이 방식으로 설정 동기화나 외부 채널 메시지처럼 연결부에서 조용히 누락되던 문제를 찾을 수 있었습니다.
[00:02:03–00:02:19] 나이아는 하나의 아바타 앱에 머물지 않도록 설계하고 있습니다. 에이전트가 뇌, 셸이 몸, 운영 환경이 세계를 맡습니다. 둘을 잇는 인터페이스가 안정되면 같은 뇌에 데스크톱 앱, 음성 장치, 다른 형태의 몸을 연결할 수 있습니다.
[00:02:19–00:02:35] 구조는 화면 기능별로 나누지 않고 감각, 지각, 주의, 기억, 정서, 추론, 의도, 표현과 행위의 흐름으로 나눕니다. 각 영역이 독립된 능력이 되면 특정 화면 구현에 묶이지 않고 다른 장치에서도 재사용할 수 있습니다.
[00:02:36–00:02:54] 뇌는 ‘웃는다’는 의도를 보낼 뿐, 그것을 3D 아바타 표정으로 표현할지 로봇 얼굴로 표현할지는 몸이 결정합니다. 물리 장치에서는 명령을 보낸 것으로 끝내지 않고 실제 동작을 다시 관측해야 합니다. 명령, 확인, 관측, 예상과의 차이를 분리해 다루는 이유입니다.
[00:02:54–00:03:11] 사용자 시나리오와 시스템 연결 지점을 서로 다른 축으로 관리하고, 코드가 어느 교차점에 속하는지 확인합니다. 빈 연결이나 중복 책임이 생기면 검사에서 드러납니다. 그 결과 통신 방식이나 모델을 바꾸더라도 관련 없는 영역까지 함께 흔들리는 일을 줄일 수 있습니다.
[00:03:11–00:03:32] 이 개발 방식을 반복해서 사용할 수 있도록 정리한 AI 개발 기반이 나이아 ADK입니다. 프로젝트의 배경과 규칙, 재사용 가능한 작업 기능, 자동 검사, 새 프로젝트의 기본 구조를 함께 제공합니다. AI에게 코드만 주는 것이 아니라 프로젝트가 지켜야 할 맥락과 검증 방법을 같이 주는 것입니다.
[00:03:32–00:03:49] 개인 프로젝트와 조직의 운영 환경은 다릅니다. 팀별 작업 범위, 권한 관리, 데이터 격리, 설정 안전장치가 필요합니다. 나이아는 여러 현장에서 공통으로 확인되는 요구를 일반화해 공개 구조와 검사 규칙에 반영합니다.
[00:03:49–00:04:08] 정리하겠습니다. 나이아는 격리된 작업, 명시적인 계약, 자동 검증, 뇌와 몸의 분리를 통해 AI 개발의 속도를 실제로 믿을 수 있는 결과에 연결하려고 합니다. 이제 이 기반 위에서 무엇을 제공하고 어디로 확장할지, 지나가 이어서 설명하겠습니다.

[00:00:02–00:00:20] 안녕하세요. 지나예요. 민호가 설명한 구조가 사용자에게 어떤 경험으로 이어지는지 정리해볼게요. 나이아는 아바타 셸, 개발 기반인 ADK, 에이전트, 장기기억, 운영체제, 음성 모델처럼 서로 연결되면서도 독립적으로 활용할 수 있는 모듈로 구성됩니다.
[00:00:20–00:00:40] 현장에서는 로컬 음성 AI에 대한 관심이 컸습니다. 목표는 음성 인식, 언어 모델의 판단, 음성 합성을 연결해 첫 반응을 빠르게 들려주는 것입니다. 여기에 장기기억과 노래 같은 기능을 선택적으로 붙이고, 컴퓨터 화면을 넘어 독립된 음성 장치에서도 사용할 수 있도록 확장합니다.
[00:00:40–00:00:57] 나이아 셸에는 기능을 추가하는 앱스토어가 있습니다. 정해진 인터페이스를 갖춘 패널은 주소로 설치할 수 있고, 앱 안에서 일어난 동작을 나이아 에이전트와 연결할 수 있습니다. 제작 도구와 배포 흐름은 아직 안정화 과정에 있으며, 확인된 기능부터 공개할 예정입니다.
[00:00:57–00:01:16] 앱스토어에서 Naia Slides를 설치하고 PDF와 발표 대본을 선택하면, 캐릭터가 지정된 목소리로 슬라이드를 발표할 수 있습니다. 지금 보고 계신 가상 컨퍼런스가 바로 그 사용 흐름을 보여주는 사례입니다.
[00:01:16–00:01:35] 슬라이드 파일과 관련 자료를 지식으로 연결하면 발표가 끝난 뒤 질문에도 답할 수 있습니다. 단순히 미리 녹음된 영상을 재생하는 데서 끝나지 않고, 발표 자료의 범위 안에서 내용을 찾아 설명하는 아바타로 확장할 수 있습니다. 발표, 안내, 교육, 고객 응대 같은 장면에 적용할 수 있어요.
[00:01:35–00:01:55] 밋업에서는 음성 AI가 휴대전화 앱보다 언제든 말을 걸 수 있는 독립 장치에 더 잘 어울린다는 의견이 나왔습니다. 그래서 리눅스 동작, 마이크와 스피커, 전원, 저장장치, 발열을 먼저 검증하고, 재현 가능한 기준 구성과 호환 부품 목록을 공개하는 작은 오픈 하드웨어 미션을 검토합니다.
[00:01:56–00:02:13] 웹 빌더에 대해서는 기능을 크게 벌이기보다 비개발자가 AI의 도움을 받아 자기 웹 공간을 만들고 실제로 공개하는 첫 경험부터 검증하자는 의견이 있었습니다. 이후 콘텐츠 이동, 호스팅 선택, AI와 아바타 기능을 모듈로 붙이는 방법을 단계적으로 살펴봅니다.
[00:02:13–00:02:33] 장기적으로는 각 기기가 분산 연산에 참여하고, 같은 에이전트가 화면·음성 장치·피지컬 컴퓨팅을 오갈 수 있는 방향을 연구합니다. 중요한 것은 장치 자체가 아니라 사용자의 기억과 관계가 이어지는 것입니다. 다음 4부에서는 이 방향을 커뮤니티의 실제 미션으로 어떻게 연결할지 나이아가 소개할게요.

[00:00:02–00:00:20] 안녕하세요. 나이아예요. 앞의 세 발표에서 왜 만들었고, 어떻게 만들었고, 어디로 가는지 살펴봤어요. 이제 그걸 누구와 어떻게 함께 만들지 이야기할 차례예요. 완성된 정답을 발표하기보다, 각자의 관심을 실제 미션으로 연결하는 방법을 제안할게요.
[00:00:20–00:00:37] AI가 공개 코드를 학습하고 빠르게 새 코드를 만드는 시대에는 기여 방식도 달라져야 해요. 매번 같은 문제를 새로 만드는 대신, 프로젝트의 배경과 규칙을 AI가 읽을 수 있게 정리하고 사람이 가진 경험을 재사용 가능한 문서와 작업 기능으로 남길 수 있습니다.
[00:00:37–00:00:54] 시작 방법은 간단해요. 저장소를 복제하고 자신이 쓰는 AI 코딩 도구로 연 뒤, 모국어로 ‘이 프로젝트가 무엇인지, 어디서 시작하면 되는지’ 물어보는 겁니다. 이슈와 변경 제안도 모국어로 작성하고, 자동 검증으로 품질을 확인할 수 있게 하는 것이 목표예요.
[00:00:54–00:01:12] 큰 기능을 처음부터 맡을 필요는 없어요. 패널 하나, 작업 기능 하나, 번역, 문서, 버그 제보, 사용 영상도 모두 기여입니다. 오픈소스 경험이 있다면 그 경험을 AI가 반복해서 활용할 수 있는 문서와 작업 방식으로 정리할 수도 있어요.
[00:01:12–00:01:28] 함께 만들 영역은 크게 네 가지예요. 제품과 모듈 개발, 홍보와 활용 사례, 커뮤니티 운영, 그리고 각 미션을 시작할 수 있도록 돕는 지원 기반입니다. 참여자는 자기 관심과 가능한 시간에 맞춰 하나를 선택할 수 있어요.
[00:01:28–00:01:44] 개발 영역에는 나이아 셸, 에이전트, ADK, 기억과 음성 모듈, 앱 패널이 있습니다. 전체 구조를 다 알아야 시작하는 방식이 아니라, 관심 있는 작은 영역의 목표와 경계를 먼저 정하고 그 결과를 전체 프로젝트에 연결합니다.
[00:01:44–00:01:59] 나이아를 활용한 방송, 교육, 문서, 데모도 중요해요. 꼭 저와 같은 캐릭터를 쓸 필요는 없습니다. 각자의 캐릭터와 채널, 작업 방식으로 사용 경험을 보여주고, 무엇이 잘됐고 무엇이 어려웠는지 남겨주세요.
[00:02:00–00:02:14] 주 1회 온라인 미팅에서 각 미션의 진행 상황과 배운 점을 짧게 공유하고, 월 1회 온·오프라인 밋업에서 개발 결과와 스터디를 공개하는 방식을 제안합니다. 오프라인 참석자분들께는 운영진 참여도 제안할 예정이에요.
[00:02:14–00:02:33] 미션을 시작하기 전에는 참여자별 온라인 미팅을 엽니다. 만들고 싶은 것, 필요한 지원, 개발 접근 방법을 먼저 합의합니다. 음성 스피커와 오픈 하드웨어, 카페루아 빌더, 기업 적용 연구처럼 관심 분야에 맞춰 작은 첫 결과를 정합니다.
[00:02:33–00:02:48] 미션에 따라 기술 시작 회의, 구조 검토, 테스트 환경, 하드웨어 부품을 함께 검토할 수 있어요. 조건이 맞으면 Azure 크레딧 같은 외부 지원도 연결하고, 결과를 문서와 데모로 공개할 수 있도록 콘텐츠 제작을 돕겠습니다.
[00:02:49–00:03:06] 일반화할 수 있는 구조, 검증 방법, 호환 정보, 시행착오는 다른 사람이 이어갈 수 있도록 공개합니다. 각자의 상황에 맞는 세부 내용은 참여자와 함께 정리해 나갑니다.
[00:03:06–00:03:26] 저장소를 열고, 모국어로 질문하고, 관심 있는 작은 미션 하나를 골라주세요. 일대일 미팅에서 접근 방법과 결과 공유 방식을 정한 뒤, 주간 공유를 거쳐 다른 사람도 재현할 수 있는 결과로 남기면 됩니다. 각자의 컴퓨터에서 태어난 AI들이 함께 배울 수 있도록, 같이 만들어요.