요구사항은 AI에게 맡기기 전에 사람이 같이 헷갈려야 한다

제일 먼저 든 생각

요구사항 도출(requirements elicitation)은 회의록을 예쁘게 정리하는 일이 아니다. 서로 다른 사람이 각자 애매하게 알고 있는 필요, 우선순위, 제약을 꺼내 놓고, 그 모호함을 견디면서 “무엇을 만들 것인가”로 바꾸는 일이다. 그래서 AI가 잘할 것 같은 부분과 하면 안 될 것 같은 부분이 동시에 보인다.

이 논문은 그 경계를 꽤 실용적으로 묻는다. 이해관계자가 같이 논의한 뒤 AI가 구조화해주는 방식, 사람이 협업만 하는 방식, LLM에게 바로 요구사항을 만들게 하는 방식, 협업 대화 기록을 LLM에게 넘기는 방식을 비교했다. 결과의 핵심은 단순하다. AI만으로 바로 쓰는 것도, 사람만으로 끝내는 것도 아니라, 사람이 먼저 같이 헷갈리고 AI가 나중에 합성할 때 요구사항 문서가 더 좋게 평가됐다.

이 논문의 요지는 “AI가 요구사항을 대신 만든다”가 아니라 “협업에서 나온 지식을 요구사항 문서로 바꾸는 합성 계층이 될 수 있다”에 가깝다.

AI가 먼저 말하면 빠르지만, 사람이 남긴 흔적이 사라진다

논문은 소프트웨어 요구사항 도출을 배경으로 하지만, 조직의 AI 업무설계에도 거의 그대로 들어맞는다. 새로운 CRM, 데이터 대시보드, 평가 자동화, 교육 추천 시스템을 만들 때도 문제는 비슷하다. 현업은 “이런 게 불편하다”고 말하고, 기획자는 “그러면 어떤 기능인가”로 바꾸고, 개발자는 “구현 가능한 규칙인가”를 본다. 이 과정에서 빠지는 말이 많다.

저자들은 혼합방법 통제 실험으로 네 가지 접근을 비교했다. 결과 산출물은 ISO/IEC/IEEE 29148에서 가져온 요구사항 품질 기준으로 평가했고, 참여자 인식도 함께 수집했다. 논문 초록은 이렇게 정리한다.

이해관계자 협업과 AI 지원 합성을 결합한 접근은 가장 높은 평가를 받은 요구사항 산출물을 만들었고, 전통적인 협업 도출보다 더 명확하고 실행하기 쉽다고 인식됐다.

Approaches combining stakeholder collaboration and AI-supported synthesis produced the highest-rated requirements artifacts and were perceived as clearer and easier to execute than traditional collaborative elicitation.

여기서 중요한 단어는 “combining”이다. AI가 회의 전에 요구사항을 선점해서 만들어주는 것이 아니라, 사람이 같이 만든 논의의 흔적을 AI가 구조화한다. 그래서 AI의 역할은 창작자라기보다 번역자에 가깝다. 말로 떠다니던 필요를 요구사항 문서의 형식으로 바꾸되, 그 원재료는 이해관계자의 상호작용에서 나온다.

협업을 건너뛴 AI 도입은 깔끔한 오답을 만든다

업무 자동화 프로젝트에서 흔한 유혹은 “일단 AI에게 초안을 만들게 하자”다. 빠르고 그럴듯하다. 하지만 요구사항 도출에서는 그럴듯함이 위험하다. 논의가 충분히 쌓이지 않은 상태에서 AI가 문서를 먼저 만들면, 사람들은 빈칸을 찾기보다 문장 품질을 보게 된다. 실제 갈등, 예외, 권한, 실패 조건이 문서 밖으로 밀릴 수 있다.

이 논문이 보여준 것은 제한된 실험 조건에서의 산출물 평가다. 그러므로 “AI 지원 협업이 항상 최고”라고 읽으면 안 된다. 다만 이 조건에서 분명히 보이는 신호가 있다. 요구사항 문서는 사람들의 대화에서 나온 지식을 잃지 않으면서도, 누군가가 실행 가능한 형식으로 정리해야 좋아진다. AI는 바로 그 두 번째 병목에 붙을 때 설득력이 생긴다.

요구사항 도출은 이해관계자들이 필요를 소통하고, 우선순위를 협상하며, 소프트웨어 요구사항 산출물로 바뀔 수 있는 지식을 함께 구성해야 한다.

Requirements elicitation requires stakeholders to communicate needs, negotiate priorities, and collaboratively construct knowledge that can be transformed into software requirements artifacts.

이 문장은 AI 도입 회의에도 그대로 붙는다. “요구사항을 써줘”보다 먼저 필요한 질문은 “누가 무엇을 다르게 알고 있는가”다.

논문 첫 페이지. 연구는 요구사항 도출에서 사람 협업, AI 지원 협업, LLM 직접 생성, 대화 기록 기반 생성의 차이를 비교한다.

조직 AI 도입에 가져올 원칙

Deciflow식 업무흐름으로 바꾸면 다음 순서가 더 안전해 보인다.

1. AI 초안보다 협업 기록을 먼저 만든다. 인터뷰, 워크숍, 코멘트, 반대 의견을 의도적으로 남긴다.
2. AI에게 요구사항을 ‘발명’하게 하지 말고 ‘합성’하게 한다. 입력 근거가 되는 발화와 결정 로그를 같이 준다.
3. 산출물 평가는 문장 품질이 아니라 요구사항 품질로 본다. 명확성, 완전성, 일관성, 검증 가능성, 실행 가능성 같은 기준을 따로 둔다.
4. 사람 검토는 마지막 승인만이 아니라 빠진 이해관계자를 찾는 과정이어야 한다. AI가 정리한 문서가 누구의 목소리를 지웠는지 본다.

특히 HRD나 사내 시스템 프로젝트에서는 이 순서가 중요하다. 교육 플랫폼을 바꾸거나 평가 자동화를 설계할 때 AI가 “좋은 기능 목록”을 빠르게 만들 수는 있다. 하지만 그 목록이 현장의 불편, 관리자 관점, 학습자 경험, 데이터 권한, 평가 책임을 함께 품고 있는지는 별개다.

다음 작은 실험

다음 요구사항 회의에서는 AI에게 바로 기능 목록을 만들게 하지 않고, 먼저 사람들의 발화를 모아 “서로 다른 필요 지도”를 만들고 싶다. 그다음 AI에게는 그 지도를 바탕으로 요구사항 문서 초안을 쓰게 한다. 오늘의 질문은 이렇다. 우리 조직의 AI는 사람들의 협업을 대체하고 있는가, 아니면 협업에서 생긴 지식을 더 실행 가능한 문서로 바꾸고 있는가.

원문 정보

• 제목: Collaborative and AI-Supported Requirements Elicitation: An Empirical Study
• 저자: Manoel Salgado Neto, Alan Araujo, Ronnie de Souza Santos
• 연도/게시일: 2026
• 게재/출처: arXiv
• DOI: 없음/확인 필요
• arXiv: 2606.24060v1
• PDF: https://arxiv.org/pdf/2606.24060

원문 논문: Collaborative and AI-Supported Requirements Elicitation: An Empirical Study