「받아쓰기(Transcription) → 요약」만이라면 어렵지 않습니다. 어려운 점은 그것을 일본의 회의에서 실무에 견딜 수 있는 회의록으로 만드는 것이었습니다. 개인 개발로 만들면서 특히 효과적이었던 설계 판단을 3가지로 압축하여 작성합니다.

자유 기술 방식의 요약이 아니라, 결정 사항 / 액션 아이템(Action Item, 누가·무엇을·언제까지) / 논점을 구조로 고정합니다. 포맷을 미리 정해둘수록 후속 공정(공유·태스크화·검색)이 편해집니다. 요약의 '능숙함'보다 구조의 '일관성'이 실무에서는 더 효과적이었습니다.

누구의 발언인지를 유지하면서, '데스·마스(です・ます)' 또는 '데아루(である)'의 톤을 무너뜨리지 않습니다. 이 부분이 무너지면 단번에 '회의록다움'이 사라져 수정 작업이 늘어납니다. 화자 분리(Speaker Diarization)와 문체의 일관성은 일본어 회의록에서 '정밀도'만큼이나 사용자 경험을 좌우했습니다.

어디서 처리하고, 어디에 보관하며, 언제 삭제할 것인가. 나중에 기능을 추가해도 파탄 나지 않도록, 보관은 국내 리전(Region), 음성은 받아쓰기 후 삭제를 처음에 결정해 둡니다. '나중에 생각하자'라고 하면 기능을 추가할 때마다 데이터 경로가 복잡해져서 막히게 됩니다.

근본적인 동기는 '회의 후의 "정리 작업"에 빼앗기는 시간을 줄이고 싶다'는 것이며, 위의 3가지는 이를 위한 수단입니다. 구현의 세부 사항(프롬프트 설계·화자 분리 처리 등)은 별도의 기사에서 깊이 있게 다루겠습니다.