고객 회의에서 나온 요구사항은 개발 대기열에 닿기 전에 어디서 빠지나 — 회의 직후 할 일·자료 요청·결정 필요로 나누는 법

시스템 구축 프로젝트에서 요구사항은 회의 중보다 회의가 끝난 뒤에 빠집니다. 회의에서는 다들 같은 말을 들었는데, 일주일 뒤 개발 대기열을 열어 보면 그중 몇 가지가 보이지 않습니다. 누가 하기로 했는지 모르는 항목, 고객이 보내기로 한 자료, 아직 정하지 않은 문제가 회의록 한 문단 안에 섞여 있다가 그대로 묻히기 때문입니다.

제조 AI 운영체제 VEXPLOR를 만드는 웨이스는 고객 공장에 시스템을 구축하면서 고객과 요구사항 회의를 자주 합니다. 웨이스는 요구사항이 가장 많이 빠지는 단계가 회의가 끝나고 개발 대기열에 들어가기 전까지라고 봅니다. 이 글에서는 그 단계에서 요구사항이 빠지는 4곳과, 회의 직후 항목을 3가지로 나눠 두는 실무 방법을 정리합니다.

회의에서 나온 요구사항은 4곳에서 빠지거나 늦어집니다

• 회의록 정리가 늦어지는 곳 — 회의록은 대개 회의에 참석한 사람 가운데 가장 덜 바쁜 사람이 작성합니다. 정리가 하루 이틀 늦어지면 기억이 흐려지고, 정리하는 사람의 해석이 고객의 말을 덮습니다. 「품목 기준 정보를 이렇게 바꿔 달라」는 구체적인 요청이 「기준 정보 개선 검토」 한 줄로 줄어드는 것도 이때입니다.

• 「누가 하기로 했지」가 남는 곳 — 회의에서는 「그건 저희가 확인해 보겠습니다」로 넘어가는 항목이 많습니다. 「저희」가 누구인지 적지 않으면 그 항목은 모두의 일이 되고, 결국 아무의 일도 아니게 됩니다.

• 자료 요청이 메일 속에 묻히는 곳 — 개발을 시작하려면 고객 쪽 자료가 필요한 경우가 많습니다. 지금 쓰는 엑셀 양식, 계산 기준표, 현장 코드 목록 같은 것입니다. 이 요청이 회의록 본문에 한 줄로만 남으면, 고객은 무엇을 언제까지 보내야 하는지 모르고 업체는 자료가 안 와서 착수하지 못합니다. 양쪽이 서로를 기다리는 사이 시간만 갑니다.

• 결정할 일과 할 일이 섞이는 곳 — 「검사 기록을 로트별로 남길지 날짜별로 남길지」는 할 일이 아니라 결정할 일입니다. 이런 항목이 할 일 목록에 섞여 개발자에게 넘어가면, 개발자가 임의로 정하거나 그 앞에서 멈춥니다. 앞의 경우는 나중에 다시 고치는 일이 되고, 뒤의 경우는 대기열이 막힙니다.

넷 가운데 마지막이 가장 비쌉니다. 앞의 셋은 늦어지는 문제지만, 마지막은 잘못 만드는 문제입니다.

회의 직후 3가지로 나누면 항목마다 다음에 움직일 쪽이 정해집니다

회의가 끝나면 회의록을 작성하기 전에 나온 말을 항목 단위로 쪼개고, 항목마다 아래 3가지 가운데 하나를 붙입니다.

• 우리가 할 일 — 업체가 바로 착수할 수 있는 항목입니다. 무엇을 바꾸는지가 문장 하나로 적혀 있어야 하고, 고객이 실제 화면에서 확인할 수 있어야 끝난 것으로 봅니다.

• 자료 요청 — 상대가 무언가를 보내야 움직일 수 있는 항목입니다. 무엇을, 누가, 언제까지 보내는지를 적습니다. 자료 요청을 할 일과 따로 두면 「업체가 늦은 것」과 「자료가 안 온 것」이 기록에서 구분됩니다.

• 결정 필요 — 누군가 선택해야 다음으로 넘어가는 항목입니다. 이 항목은 할 일로 바꾸기 전에 선택지를 2~3개로 적어 둡니다. 「검사 기록 기준을 어떻게 할지」가 아니라 「로트별로 남긴다 / 날짜별로 남긴다 / 품목마다 정한다」처럼 적으면, 결정하는 사람이 고르기만 하면 됩니다.

이 구분은 회의록을 결정·할 일·미결로 나누는 흔한 방식과 비슷해 보이지만, 자료 요청을 따로 둔다는 점이 다릅니다. 시스템 구축 회의에서는 고객 쪽 자료가 오지 않아 멈추는 항목이 생각보다 많고, 이 항목이 할 일 목록에 섞여 있으면 업체의 지연으로 보입니다.

항목마다 붙일 것은 3가지입니다

• 누가 말했는지 — 항목을 처음 꺼낸 사람입니다. 나중에 해석이 다르면 그 사람에게 다시 물으면 됩니다. 회의록 작성자가 자기 말로 바꿔 적은 항목에서는 원래 누구의 요구였는지가 사라집니다.

• 기한 — 할 일이면 완료 목표일, 자료 요청이면 받을 날짜, 결정 필요면 정해야 하는 날짜입니다. 기한이 없는 항목은 다음 회의까지 그대로 남습니다.

• 원래 문장 — 요약 대신 회의에서 나온 말에 가까운 문장으로 적습니다. 요약하면 짧아지지만, 개발자가 다시 물을 일이 늘어납니다.

확인 메일은 회의 당일 3가지 목록 그대로 보냅니다

나눈 항목은 그날 안에 고객에게 보냅니다. 회의록 전문을 보내는 대신 3가지 목록을 그대로 보내고, 「틀린 항목이나 빠진 항목이 있으면 알려 달라」는 한 줄을 붙입니다. 고객은 긴 회의록을 읽지 않아도 되고, 자기가 보내야 할 자료와 정해야 할 일을 바로 확인합니다.

이 메일이 늦어지면 앞에서 본 4곳이 그대로 다시 생깁니다. 그래서 확인 메일은 회의록 작성이 끝난 뒤가 아니라, 항목을 나눈 직후에 보냅니다.

나누는 일을 AI가 먼저 하면 사람은 승인만 하면 됩니다

항목을 쪼개고 3가지로 나누고 말한 사람을 붙이는 일은 손이 많이 갑니다. 그래서 바쁜 프로젝트일수록 이 단계를 건너뛰고 회의록 한 장으로 끝냅니다.

이 일은 이제 사람이 처음부터 하지 않아도 됩니다. 회의를 녹음해 글로 옮기면, AI가 그 글에서 항목을 뽑아 3가지로 나누고 말한 사람을 붙여 둘 수 있습니다. 사람은 AI가 뽑은 항목을 보며 맞는 것은 승인하고 틀린 것은 버리면 됩니다. 처음부터 작성하던 일이 고르는 일로 바뀝니다.

웨이스는 고객과의 프로젝트 회의를 이렇게 운영하고 있고, 사람이 하는 승인 단계까지 자동화하는 작업을 진행하고 있습니다. 그 과정은 다른 글에 따로 정리했습니다.

회의가 끝난 뒤 지킬 원칙은 하나입니다. 회의록을 잘 작성하는 것보다, 회의에서 나온 말을 다음에 움직일 쪽이 정해진 항목으로 바꾸는 일이 먼저입니다.

WACE(웨이스)는 공장이 스스로 판단하고 멈추지 않게 하는 제조 AI 운영체제 VEXPLOR를 만드는 회사다.

함께 읽어보세요

• 웨이스는 사후관리에 이어 신규 프로젝트 개발도 무인화하는 중입니다: https://blog.vexplor.com/post/wace-extends-ai-from-maintenance-to-project-meetings

• 회의 메모 9줄, AI로 결정·할 일·미결 3표 만들기: https://blog.vexplor.com/post/meeting-memo-to-three-tables