회의 음성에서 의사결정 배경을 남기는 개발 플로우를 AI로 해결하기
요약
본 글은 회의 음성 데이터를 활용하여 단순히 결정된 사양(What)뿐만 아니라, 그 의사결정 배경과 판단 이유(Why)를 기록하는 개발 워크플로우를 제안합니다. 이를 통해 요구사항 정의부터 설계, 개발 태스크까지 연결하여 지식 손실을 방지하고, 추후 사양 변경 시에도 근거 자료를 확보할 수 있습니다.
핵심 포인트
- 회의 음성 기반으로 의사결정 배경 기록 가능
- 단순 회의록 생성을 넘어 '왜' 결정했는지 기록하는 것이 핵심
- 요구사항 정의-설계-개발 태스크로 연결되는 워크플로우 제안
- 지식 손실 방지를 통해 사양 변경 시 근거 자료 확보
개발 업무를 하다 보면 이런 경험은 없으신가요?
- 상부로부터 사양이 내려왔지만, 왜 그 사양이 되었는지 알 수 없다
- 다른 엔지니어가 결정한 사양에 대해 기술적인 판단 이유를 모른다
- 과거에 결정했던 사양을 변경하려 했지만, 당시의 경위가 알 수 없다
- 사양의 배경을 알기 위해 당시 담당자에게 확인할 필요가 있다
- 회의에 참가하지 않은 멤버에게 결정 사항만 공유되어 있다
이것들에 공통되는 것은, '무엇을 결정했는지'는 남아 있지만, '왜 그렇게 결정했는지'가 남아있지 않다는 문제입니다.
이번에는 이 문제를 AI를 통해 개선할 수 있지 않을까 생각하여, 회의 음성 데이터를 기점으로 의사결정 배경을 기록하고, 요구사항 정의·설계·개발 태스크까지 연결하는 워크플로우를 소개합니다.
※본 기사는 워크플로우 제안입니다. 실제 도입에 따른 공수 절감이나 품질 개선 효과를 검증한 것은 아닙니다.
예를 들어, 비엔지니어 상부로부터 다음과 같은 요청이 있었다고 가정해 봅시다.
'로그인 중인 사용자만 일람 표시하는 기능을 추가해 주세요.'
요구 자체는 이해할 수 있습니다.
하지만, 다음과 같은 의문점이 남습니다.
- 왜 로그인 중인 사용자만인가?
- 어떤 과제를 해결하고 싶은가?
- 어떤 효과를 기대하는가?
- 다른 방법으로는 실현할 수 없는가?
이러한 배경이 공유되어 있지 않으면, 엔지니어는 제시된 사양을 구현할 수는 있어도, 보다 적절한 대안을 제안하기 어렵게 됩니다.
이 문제는 상부와 엔지니어 사이에서만 발생하는 것이 아닙니다. 엔지니어들 사이에서도 발생합니다.
예를 들어, 다음과 같은 사양이 결정되었다고 가정해 봅시다.
'사용자 목록의 갱신 주기는 30초로 한다.'
사양서에는 '30초 간격으로 갱신한다'라고 기재되어 있어도, 그 이유가 남아있지 않은 경우가 있습니다.
실제로는 다음과 같은 이유가 있었을 수 있습니다.
- DB 부하를 줄이기 위해
- 실시간성보다 안정성을 우선했기 때문에
- 기존 시스템의 제약이 있었기 때문에
- 개발 공수를 고려했기 때문에
이러한 판단 이유가 공유되어 있지 않으면, 나중에 사양을 변경할 때 당시의 제약을 놓칠 가능성이 있습니다.
사양을 결정했을 때는 담당자가 배경을 이해하고 있더라도, 시간이 지나면 상황이 변합니다.
- 담당자의 이동이나 퇴직
- 다른 멤버에게 인계
- 과거의 사양 변경
- 당시 논의 내용의 망각
그 결과, 기존 사양의 이유를 다시 조사할 필요가 생깁니다.
사양서는 남아있는데, 왜 그 사양이 되었는지 아무도 설명할 수 없는 상태.
이 상태를 개선할 필요가 있다고 생각합니다.
이번 목적은 단순히 회의록을 자동 생성하는 것이 아닙니다. 사양과 함께 의사결정 배경이나 판단 이유를 기록하여, 나중에 누구나 확인할 수 있는 상태로 만드는 것입니다.
예를 들어, 기존 사양서에서는 다음과 같이 기재되어 있었다고 가정해 봅시다.
| 항목 | 내용 |
|---|---|
| 기능 | 로그인 중 사용자 목록 |
| ... |
이것을 다음과 같은 형식으로 남길 수 있다면 이상적입니다.
| 항목 | 내용 |
|---|---|
| 요구사항 | 로그인 중인 사용자를 일람 표시한다 |
| ... |
위 내용은 설명용의 가상 예시입니다. (※)
이러한 기록이 남아있다면, 사양을 변경할 때도 당시의 판단 자료를 참고할 수 있습니다.
또한, 엔지니어가 사양을 이해할 때도 단순히 구현 내용뿐만 아니라, 요구사항의 목적부터 생각할 수 있게 됩니다.
그래서 생각해낸 것이 회의 음성과 AI를 결합한 워크플로우입니다.
사용할 도구 후보로는 다음과 같은 것을 상정하고 있습니다.
- Plaud 등의 녹음/텍스트 변환(文字起こし) 툴: 회의 음성을 기록 -
- AI 요약 툴: 회의 내용에서 결정 사항이나 판단 이유를 추출 -
- Claude Code: 추출된 정보를 바탕으로 요구사항 정의나 설계를 지원 -
- Redmine이나 Git 등: 결정 사항, 설계서, 개발 태스크를 관리
【회의/히어링】
|
v
...
이 메커니즘을 통해, 회의에서 결정한 내용을 그 배경과 함께 개발 공정으로 인계하는 것을 목표로 합니다.
우선, 요구사항 정의나 사양 검토 회의를 녹음합니다. 대상이 되는 것은 예를 들어 다음과 같은 회의입니다.
- 상부와의 사양 검토
- 엔지니어 간 기술 검토
- 시스템 설계 회의
- 사양 변경 관련 회의
- 장애 대응 후 되돌아보기(振り返り)
여기서는 가능한 한 대화 내용을 그대로 기록합니다.
참고로, 실제 업무에서 녹음할 때는 참가자의 동의나 사내 규정을 따라야 합니다. 녹음 데이터를 텍스트 변환하고 AI가 내용을 정리하게 합니다.
일반적인 회의록은 결정 사항이나 다음 액션 아이템에 초점을 맞추는 경향이 있습니다.
이번에는 여기에 더해, 왜 그러한 결론에 도달했는지를 중점적으로 추출합니다.
예를 들어, 다음과 같은 프롬프트를 사용할 수 있습니다.
다음은 사양 검토 회의의 녹취록입니다.
회의 내용으로부터 다음 정보를 정리해 주세요.
1. 요구사항/요구(Requirement/Wish)
...
이렇게 지시함으로써 단순한 요약이 아니라, 의사결정 기록으로 활용하기 쉬운 형태로 정리할 수 있습니다.
여기서가 중요한 과정입니다.
AI는 회의 내용을 정리할 수는 있지만, 반드시 정확하게 이해한다고 할 수는 없습니다.
예를 들어, 회의 중 "30초 업데이트로도 괜찮을지도 모른다"라는 발언을 AI가 결정 사항으로 처리해 버릴 가능성이 있습니다.
따라서 다음 내용들을 확인해야 합니다.
- 결정 사항이 올바른지
- 판단 근거에 오류는 없는지
- 검토 중인 안건이 결정 사항으로 오인되지 않았는지
- 중요한 제약 조건(Constraint)이 빠지지 않았는지
- AI가 사실을 추측하여 보완하지 않았는지
AI가 작성한 정보를 그대로 확정 사양으로 취급하는 것이 중요하지 않습니다.
확인된 정보를 Claude Code에 전달합니다.
기존 시스템의 구성이나 코드도 참조할 수 있는 환경이라면, 회의 내용과 실제 시스템을 대조하면서 설계 초안을 만들 수 있습니다.
예를 들어, 다음과 같이 지시할 수 있습니다.
다음 회의 기록을 바탕으로,
기존 시스템을 고려한 설계 안을 작성해 주세요.
【작성 대상】
...
이를 통해 회의 내용을 설계에 반영할 때 발생하는 전사(轉寫)나 정리 부담을 줄일 수 있을 가능성이 있습니다.
또한, AI가 기존 시스템과의 모순점이나 추가로 확인해야 할 사항을 도출하는 용도로도 활용할 수 있습니다.
기존 개발 플로우에서는 회의 종료 후 다음과 같은 작업이 발생합니다.
- 회의 내용을 기억해 내기
- 회의록 정리하기
- 결정 사항을 요구사항 정의서(Requirement Definition Document)에 반영하기
- 설계서 작성하기
- 개발 태스크로 분할하기
이러한 공정들을 AI가 지원함으로써, 사람이 하던 정보 정리나 문서 작성 작업을 줄일 수 있다고 생각합니다.
다만, AI를 통한 초안 생성 속도가 빠르더라도, 검토 및 수정에 시간이 걸릴 가능성은 있습니다.
따라서 실제로 도입할 때는 문서 생성 시간뿐만 아니라, 확인/수정까지 포함한 총 작업 시간으로 효과를 평가해야 합니다.
개인적으로는 이 부분이 가장 큰 장점이라고 생각합니다.
회의에서 결정된 사양뿐만 아니라, 그 배경(Background)까지 공유할 수 있게 된다면 다음과 같은 효과가 기대됩니다.
경영진과 엔지니어 사이
경영진이 무엇을 실현하고 싶은지, 어떤 과제를 해결하고 싶은지를 파악하기 쉬워집니다.
그 결과, 엔지니어는 요구된 사양을 구현할 뿐만 아니라, 목적에 맞는 대체안을 제안하기 쉬워집니다.
엔지니어 간
기술적인 판단 근거나 제약 조건을 공유할 수 있습니다.
예를 들어, DB 부하 때문에 업데이트 주기를 30초로 설정했다면, 나중에 다른 멤버가 사양을 변경할 때도 그 이유를 확인할 수 있습니다.
미래 유지보수 및 사양 변경
당시의 판단 근거가 남아 있다면, 현재에도 그 제약이 존재하는지 확인할 수 있습니다.
이를 통해 과거의 사양을 무조건 따르기보다는, 현재 상황에 맞춰 재검토하기 쉬워집니다.
유용한 시스템이지만, 몇 가지 주의할 점도 있습니다.
| 과제 | 대책 |
|---|---|
| AI가 발언 내용을 오인식하는 경우 | 원본 녹취록이나 녹음 파일과 대조한다 |
| ... |
또한, 모든 회의를 녹음/분석할 필요는 없다고 생각합니다.
우선은 사양 결정이나 기술적 판단이 발생하는 회의에 한정하여 시도하는 것이 도입하기 쉬울 것입니다.
AI는 회의 중에 언급된 내용을 정리할 수는 있습니다.
하지만, 회의에서 설명되지 않은 판단 근거를 정확하게 복원할 수는 없습니다.
따라서 회의 진행 방식 자체도 중요합니다.
예를 들어, 사양을 결정할 때 다음 3가지 포인트를 확인하는 것만으로도 기록의 질은 달라져야 합니다.
- 왜 그 사양이 필요한가?
- 왜 그 방법을 선택했는가?
- 다른 대안을 채택하지 않은 이유는 무엇인가?
AI 활용과 더불어, 이러한 확인 과정을 습관화하는 것이 필요하다고 생각합니다.
갑자기 회의부터 설계/구현까지를 자동화하기보다는, 단계적으로 검증하는 것이 현실적입니다.
| 단계 | 검증 내용 | 확인할 것 |
|---|---|---|
| Phase 1 | 회의 음성에서 의사결정 추출 | 결정 사항과 배경을 올바르게 추출할 수 있는지 |
| ... |
우선은 Phase 1과 Phase 2만으로도 충분히 가치가 있다고 생각합니다.
효과를 확인할 때는, 예를 들어 다음 지표들을 사용할 수 있습니다.
- 회의록 및 결정 기록 작성에 소요된 시간
- AI가 추출한 결정 사항의 정확성
- 판단 이유가 기록되어 있는 비율
- 사양 배경을 확인하기 위해 발생한 문의 건수
- 설계서 작성부터 리뷰 완료까지의 시간
이러한 지표로 비교하면, 도입에 따른 효과를 객관적으로 평가할 수 있습니다.
이번에 제안하는 것은 회의 음성을 시작점으로 삼아 AI를 사용하여 의사결정 배경을 기록하고, 이를 요구사항 정의 및 설계로 연결하는 워크플로우입니다.
기대되는 효과는 크게 두 가지가 있습니다.
① 문서 작성 및 개발 준비 효율화
회의 내용 정리, 요구사항 정의서/설계서 초안 작성, 태스크 분할 등을 AI의 지원을 받아 수행함으로써 수작업을 줄입니다.
② 의사결정 배경 및 의도 시각화와 공유
상위 부서의 요구 배경이나 엔지니어가 진행한 기술적 판단의 이유를 기록하여, 다른 멤버나 미래 담당자가 참조할 수 있도록 합니다.
AI를 활용하는 목적은 단순히 설계서를 빠르게 만드는 것이 아닙니다.
'무엇을 만들 것인가'뿐만 아니라 '왜 그것을 만드는가', '왜 그 설계를 선택했는가'를 팀원 모두가 이해할 수 있는 상태로 만드는 것입니다.
사양이라는 결론뿐만 아니라, 거기까지 이르는 의사결정 과정까지 남기는 것입니다.
그렇게 함으로써 엔지니어가 보다 적절한 설계나 제안을 할 수 있는 환경으로 이어질 것이라고 생각합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기