회의록 기능 — 회의는 끝나도 기록은 업무 데이터가 되어야 한다
회의는 끝나지만, 결정과 맥락은 남아야 합니다. 모바일에서 녹음하고, 업무 포탈에서 검토하고, AI가 전사와 요약을 돕는 회의록 기능을 만들며 배운 것을 일반적인 설계 원칙으로 정리했습니다.
1. 왜 회의록부터 시작했나
섹션 제목: “1. 왜 회의록부터 시작했나”조직의 중요한 정보는 문서보다 대화에서 먼저 생깁니다. 문제는 대화가 끝나면 결정의 이유, 담당자, 기한이 사람의 기억 속에 흩어진다는 점입니다. 회의록은 단순한 받아쓰기가 아니라 결정·할 일·근거를 다시 찾을 수 있게 만드는 업무 데이터여야 합니다.
그래서 출발점을 “예쁜 녹음기”가 아니라 다음 질문으로 잡았습니다.
- 회의 직전에는 제목과 맥락을 빠르게 남길 수 있는가?
- 회의 중에는 녹음 상태와 마이크 입력을 신뢰할 수 있는가?
- 회의 후에는 파일·전사·요약·검토 상태가 끊기지 않는가?
- 모바일에서 시작한 기록을 포탈에서 이어서 검토할 수 있는가?
2. 최종적으로 만들고 싶은 경험
섹션 제목: “2. 최종적으로 만들고 싶은 경험”사용자는 기기를 선택할 뿐, 시스템을 선택할 필요가 없어야 합니다. 모바일에서는 한 번의 탭으로 녹음을 시작하고, 노트북에서는 업무 포탈 회의록 메뉴에서 같은 회의를 열어 이어서 작업합니다.
| 단계 | 사용자 경험 | 시스템이 보장할 것 |
|---|---|---|
| 시작 전 | 제목·프로젝트·메모를 입력하거나 나중에 보완 | 필수값을 과도하게 강제하지 않음 |
| 녹음 중 | 경과 시간, 입력 상태, 일시정지·종료를 명확히 확인 | 로컬 임시 저장과 중단 복구 |
| 전송 | 업로드 진행률과 재시도 상태 확인 | 중복 방지·재개 가능한 업로드 |
| 검토 | 전사·요약·결정·할 일·리스크를 한 화면에서 검토 | AI 결과를 초안으로 표시하고 사람의 승인을 남김 |
3. 화면을 만들며 바뀐 생각
섹션 제목: “3. 화면을 만들며 바뀐 생각”초기 시안은 풍부한 정보를 한 번에 보여 주는 방향이었습니다. 전문성은 느껴졌지만, 실제 녹음 시작까지의 인지 부담이 컸습니다. 특히 프로젝트를 반드시 고르게 하거나 참석자 이름을 미리 보여 주는 방식은 모든 회의에 맞지 않았습니다.
개선 원칙은 간단했습니다. 회의를 시작하는 데 필요한 것과, 나중에 풍부하게 만드는 것을 분리합니다. 제목은 바로 입력하되 프로젝트는 기존 항목을 선택하거나 새 이름을 직접 입력할 수 있게 하고, 참석자는 회의 중·후에 보완합니다. 마이크 확인은 파형 장식이 아니라 “입력이 감지되고 있다”는 상태와 장치를 함께 알려 주는 신호가 되어야 합니다.
4. 모바일과 포탈을 하나의 기록으로 연결하기
섹션 제목: “4. 모바일과 포탈을 하나의 기록으로 연결하기”모바일과 웹을 따로 만들면 “모바일에는 파일이 있는데 포탈에는 회의가 없다”는 단절이 생깁니다. 이를 피하려면 녹음 파일과 회의 레코드의 생명주기를 처음부터 함께 설계해야 합니다.
- 회의 레코드를 먼저 만든다. 제목, 작성자, 생성 시각, 선택적 프로젝트 연결을 서버에 기록합니다.
- 녹음 파일은 별도 저장소에 둔다. 데이터베이스에는 메타데이터와 상태만 저장하고, 원본 파일은 접근 제어가 가능한 파일 저장 영역에 보관합니다.
- 전송은 상태 머신으로 관리한다. 준비 → 업로드 중 → 전사 중 → 검토 필요 → 확정 같은 상태를 사용자에게 그대로 보여 줍니다.
- 웹은 같은 레코드를 읽는다. 포탈은 모바일 업로드를 별도 기능으로 흉내 내지 않고, 동일한 회의·파일·전사 결과를 조회합니다.
5. 전사와 요약은 어떤 AI를 써야 하나
섹션 제목: “5. 전사와 요약은 어떤 AI를 써야 하나”음성을 글로 바꾸는 STT와 글을 정리하는 LLM은 서로 다른 문제입니다. STT는 잡음·화자·언어·지연 시간이 중요하고, LLM 요약은 긴 문맥·구조화 출력·근거 보존이 중요합니다. 하나의 모델로 통일하기보다 작업별로 평가하는 편이 현실적입니다.
| 작업 | 선택 기준 | 운영 원칙 |
|---|---|---|
| STT | 한국어 정확도, 화자 구분, 처리 지연, 파일 크기 | 짧은 구간 처리와 재시도, 원문 보존 |
| 요약 LLM | 결정·할 일 추출, JSON 구조화, 긴 문맥, 비용 | 초안 생성 후 사람이 승인, 원문 근거 연결 |
| 임베딩·검색 | 회의 간 유사도와 검색 품질 | 모델을 바꾸면 재색인 비용을 고려 |
여기서 연결관리센터의 역할이 중요해집니다. 애플리케이션 코드에 특정 LLM과 API 키를 박아 넣는 대신, “회의 요약”, “결정사항 추출”, “질의 응답” 같은 **작업(capability)**을 등록하고 중앙에서 모델을 연결합니다(자세한 배경은 어떤 LLM을 도입할 것인가 참고). 운영자는 작업별 모델을 바꿀 수 있고, 호출 기록에는 실제 사용 모델과 비용·지연·결과 상태가 남습니다. 화면의 드롭다운만 바뀌는 것이 아니라, 변경 → 호출 → 기록 확인의 왕복으로 실제 라우팅을 검증해야 합니다.
6. 기밀을 지키면서도 배울 수 있게 쓰기
섹션 제목: “6. 기밀을 지키면서도 배울 수 있게 쓰기”회의록 시스템은 가장 민감한 업무 데이터에 접근합니다. 그래서 공개 글에서는 기능을 자랑하기보다 경계를 설명하는 것이 더 중요합니다.
- 녹음 원본과 전사 원문은 기본 비공개이며, 접근 권한을 회의 단위로 확인합니다.
- LLM에 보내는 데이터는 목적에 필요한 범위로 줄이고, 외부 전송 여부를 운영자가 알 수 있게 합니다.
- AI가 만든 요약은 사실의 최종본이 아니라 검토 가능한 초안으로 표시합니다. 되돌리기 어려운 액션(삭제·공유·확정)에 사람의 승인을 두는 원칙은 알림비서 NotiFilter에서도 같은 방식으로 다뤘습니다.
- 삭제·다운로드·공유·모델 호출은 감사 로그로 남깁니다(감사로그·백업의 자리 참고).
- 블로그·교육 자료에는 실제 회의 내용 대신 합성 데이터와 구조 설명만 사용합니다.
7. 이 여정에서 얻은 일반적인 교훈
섹션 제목: “7. 이 여정에서 얻은 일반적인 교훈”8. 다음 목표
섹션 제목: “8. 다음 목표”다음 단계의 목표는 기능을 더 많이 붙이는 것이 아닙니다. 다양한 네트워크와 긴 녹음에서도 파일이 유실되지 않는지, 전사 결과가 원문과 함께 검토되는지, AI 요약의 결정·할 일·리스크가 실제 업무로 이어지는지를 반복 검증하는 것입니다. 성공의 기준은 “AI가 멋진 문장을 썼다”가 아니라, 회의가 끝난 뒤 팀이 더 빨리 같은 사실을 보고 행동하는가에 있습니다.