PM Day와 개발자 피드백 시간에 받은 질문 중, SynQ의 구현 방향을 정리하는 데 중요한 질문을 중심으로 정리했습니다.
<aside>
</aside>
<aside>
현재 MVP에서는 SynQ 자체에서 화상회의 기능을 제공하기보다, 회의 이해를 돕는 보조 도구에 집중하려고 합니다.
2개월이라는 제한된 개발 기간 안에서는 회의 플랫폼을 직접 만드는 것보다, 대면회의 또는 외부 회의 도구에서 나온 발화/전사 내용을 바탕으로 AI 힌트와 AI Chat을 제공하는 경험을 검증하는 것이 더 중요하다고 판단했습니다.
장기적으로는 Zoom, Google Meet, Discord 등 외부 회의 도구 연동도 고려할 수 있습니다.
Notion은 문서와 회의록을 정리하고 관리하는 도구에 가깝고, Tiro는 실시간 전사와 회의록 생성에 강점이 있습니다.
반면 SynQ는 전사나 회의록 자체보다, 회의 중 특정 발화가 내 업무에 어떤 의미인지, 어떤 영향을 주는지, 지금 무엇을 확인해야 하는지를 알려주는 데 집중합니다.
즉, 기존 도구가 “무엇을 말했는지”를 기록한다면, SynQ는 **“그 말이 내 역할에서 어떤 의미인지”**를 이해하도록 돕는 서비스입니다.
</aside>
<aside>
STT는 장기적으로 중요한 기능이지만, 1차 MVP에서 반드시 완성도 높게 구현해야 하는 필수 기능은 아니라고 보고 있습니다.
초기에는 더미 전사, 수동 입력, 시나리오 기반 전사로도 핵심 경험을 검증할 수 있습니다. 핵심은 음성을 얼마나 완벽하게 인식하느냐보다, 전사된 발화를 바탕으로 의미 · 영향 · 질문을 제공하는 경험이 실제로 유용한지를 확인하는 것입니다.
이후 STT는 한국어 정확도, 비용, 실시간성, 연동 난이도를 기준으로 여러 후보를 비교할 예정입니다. 개발자 피드백에서 나온 것처럼 Tiro API를 활용해 전사 데이터나 회의 노트를 가져오는 방식도 후보 중 하나로 검토할 수 있습니다.
실제 실시간 전사와 AI 힌트 자동 노출까지 구현하려면 WebSocket이나 SSE 같은 실시간 이벤트 전달 방식이 필요할 수 있습니다.
다만 1차 MVP에서는 더미 전사 데이터, 시나리오 기반 전사, 또는 polling 방식으로도 핵심 UX를 먼저 검증할 수 있다고 보고 있습니다.
즉, 초기에는 실시간처럼 보이는 화면 경험을 먼저 만들고, 이후 실제 STT와 실시간 이벤트 구조를 붙이는 방식이 현실적이라고 판단했습니다.
</aside>
<aside>
초기에는 완전 자동 판단보다 중요 발화 기준을 먼저 정의하는 방식으로 접근하려고 합니다.
예를 들어 일정 변경, MVP 범위 변경, 기술 리스크, 담당자 영향, 완료 기준, 의사결정 가능성이 있는 발화를 중요 발화 후보로 볼 수 있습니다.
처음에는 룰 기반 또는 프롬프트 기반으로 시작하고, 이후 사용자 피드백과 회의 데이터를 통해 고도화할 수 있습니다.
초기에는 모든 문맥 분리를 AI에 의존하기보다, 문장 단위, 시간 단위, 의미 단위를 기준으로 발화 블록을 먼저 구성할 수 있다고 보고 있습니다.
고도화 단계에서는 LLM을 활용해 발화를 의미 단위로 나누거나, 일정 변경·리스크·결정사항 같은 유형별로 분류하는 구조를 고려할 수 있습니다.
</aside>
<aside>
완전한 RAG를 1차 MVP에서 필수로 보지는 않습니다.
다만 SynQ의 핵심이 프로젝트 맥락 기반 답변이기 때문에, 처음에는 참고자료 요약이나 일부 문서 내용을 AI 요청에 함께 넣는 방식으로 시작할 수 있습니다.
이후 파일 파싱, 임베딩, 벡터DB를 붙여 RAG로 고도화하는 방향을 생각하고 있습니다. 즉, 1차 MVP에서는 프로젝트 자료 기반 응답 경험을 먼저 검증하고, 이후 기술적으로 RAG 구조를 붙이는 방식입니다.
초기에는 상용 LLM API를 활용하는 것이 현실적이라고 보고 있습니다. UMC MVP 단계에서 자체 모델을 구축하거나 학습시키는 것은 리소스와 시간이 많이 필요하기 때문입니다.
따라서 현재 단계에서는 상용 API로 빠르게 핵심 경험을 검증하고, 이후 필요한 부분을 고도화하는 방향이 적절하다고 판단했습니다.
</aside>
<aside>
AI 힌트는 최종 판단이 아니라 회의 이해를 돕기 위한 보조 정보로 설계하려고 합니다.
이를 위해 AI 답변에 참고한 발화나 자료 출처를 함께 표시하고, 확정형 답변보다는 “확인해야 할 질문” 형태로 유도하는 방식을 고려하고 있습니다.
중요한 의사결정은 AI가 대신 판단하는 것이 아니라, 사용자가 팀과 다시 확인할 수 있도록 설계하는 것이 핵심입니다.
초기에는 AI가 모든 전문 용어를 완벽하게 이해하는 것을 목표로 하기보다, 프로젝트 자료와 지난 회의 맥락을 바탕으로 정확도를 높이는 방향을 목표로 합니다.
전문 용어는 일반 모델이 바로 이해하기 어려울 수 있기 때문에, 프로젝트 용어집, 기획안, 회의록, 정책 문서 등을 참고자료로 연결하는 구조가 중요합니다.
또한 AI의 답변은 확정 판단이 아니라 **“이 발화가 이런 의미일 수 있고, 이런 질문을 확인하면 좋다”**는 형태로 제공해 리스크를 줄이고자 합니다.
</aside>
<aside>
맞습니다. 회의 데이터는 민감한 정보를 포함할 수 있기 때문에, 보안은 SynQ가 B2B로 확장하기 위해 반드시 해결해야 할 과제입니다.
다만 초기 타깃은 보안 요구가 매우 높은 대기업보다는, 학생 프로젝트, 사이드 프로젝트, 프리랜서·소규모 에이전시, 스타트업처럼 협업 맥락 차이가 크고 도입 장벽이 낮은 팀으로 보고 있습니다.
초기 MVP에서는 사용자 동의, 녹음/전사 안내, 프로젝트별 접근 권한, 데이터 보관 범위 설정 같은 기본 정책부터 고려하고, 장기적으로는 데이터 암호화, 조직별 권한 관리, 보관 기간 설정, 외부 공유 제한 등을 확장할 수 있습니다.
장기적으로는 사용자가 데이터 보관 방식을 선택할 수 있어야 한다고 봅니다.
예를 들어 기본 설정은 녹음 원본을 저장하지 않거나, 요약 및 질문 생성 후 일정 시간 내 삭제하는 방식으로 설계할 수 있습니다.
대신 회의 요약, 발화 텍스트, 질문 로그 등 사용자가 필요로 하는 최소 데이터만 저장하는 방향을 고려할 수 있습니다. 기업용에서는 보관 기간, 삭제 정책, 접근 권한, 다운로드 제한 등을 관리자가 설정할 수 있어야 한다고 보고 있습니다.
STT와 AI API 비용은 실제 서비스화에서 중요한 이슈입니다.
따라서 초기 MVP에서는 STT 없이 시나리오 기반 전사로 핵심 UX를 먼저 검증하고, AI 요청도 필요한 순간에만 발생하도록 제한하려고 합니다.
서비스화 단계에서는 회의 시간, AI Chat 사용량, 저장 용량 등에 따라 사용량 제한이나 팀 플랜 과금 구조를 고려할 수 있습니다.
</aside>