JAD로 요구사항을 함께 합의하는 워크숍 운영
JAD의 참여자 역할, 세션 운영 방식, 요구사항 도출 기법과 다른 방법론의 차이를 실무 관점에서 정리한다.
2026-08-14 · 최초 발행 2025-05-23
요구사항을 한자리에 모아 결정하는 JAD
JAD(Joint Application Development)는 시스템 개발 초기에 사용자 참여를 높여 요구사항을 끌어내기 위한 구조화된 워크숍 방식이다. 1970년대 후반 IBM에서 Chuck Morris와 Tony Crawford가 개발했으며, 개발자와 사용자 사이의 상호작용을 강화하는 접근법으로 고안됐다.
전통적인 요구사항 수집은 사용자와 개발자 간 소통이 끊기거나, 요구사항을 잘못 이해하는 문제를 낳기 쉽다. 개발이 진행된 뒤 변경 요청이 늘어나면 일정 지연과 비용 초과로 이어질 수 있다. JAD는 최종 사용자, 시스템 개발자, 비즈니스 분석가, 프로젝트 관리자 등 관련자가 같은 세션에서 직접 논의하고 합의하도록 해 이 문제를 다룬다.
세션 안에서 역할을 나누는 방식
JAD는 단순한 회의가 아니다. 세션을 이끄는 사람, 내용을 남기는 사람, 업무와 기술의 관점을 제공하는 사람이 구분돼야 한다.
- 세션 리더(Facilitator)는 중립적인 위치에서 전체 논의를 진행하고, 갈등을 조정하며 각 이해관계자가 의견을 낼 수 있게 만든다.
- 스크라이브(Scribe)는 회의 내용과 다이어그램을 기록하고 결과물을 문서로 정리한다.
- 사용자 대표(End Users)는 실제 업무 프로세스와 요구사항을 설명하고, 제안된 해결책이 실용적인지 평가한다.
- IT 전문가(IT Specialists)는 개발, 시스템 설계, DB 등의 관점에서 기술적 실현 가능성, 제약사항, 대안을 검토한다.
- 관리자(Executives)는 프로젝트 방향과 우선순위를 정하고 자원 할당에 관한 결정을 내린다.
- 관찰자(Observers)는 토론에 직접 참여하지 않고 과정을 살피며, 필요할 때 전문적 조언을 제공한다.
준비부터 승인까지 이어지는 세션
JAD는 목표와 범위를 먼저 정한 뒤 참여자와 자료, 의제, 운영 방식을 준비하는 것으로 시작한다. 초기 세션에서는 프로젝트 목적과 역할, 진행 규칙을 공유하고 현행 업무 프로세스와 기초 요구사항을 파악한다.
주요 JAD 세션에서는 상세 요구사항을 분석하고 업무 프로세스를 다시 설계한다. 사용자 인터페이스와 데이터 요구사항을 정의하고, 주요 기능을 명세화하며, 프로토타입을 검토해 피드백을 받는다.
논의 결과는 요구사항 명세서로 문서화한다. 참여자 검토와 피드백이 필요하면 추가 세션을 열고, 최종 문서를 승인한 뒤 요구사항 우선순위와 개발 일정을 정한다. 승인된 결과는 공식 문서로 배포한다.
논의를 요구사항으로 바꾸는 기법
브레인스토밍은 비판 없이 아이디어를 넓게 모으는 데 사용한다. 모든 의견을 존중하고 “나쁜 아이디어는 없다”는 원칙 아래, 아이디어의 양을 중시하며 다양한 관점을 수집한다.
친화도 다이어그램은 모인 아이디어의 유사성을 분석해 그룹으로 묶고, 카테고리와 관계를 찾아 우선순위를 정하는 데 활용한다.
명목집단법(Nominal Group Technique)은 각자가 아이디어를 제시한 뒤 순서대로 공유하고, 토론과 명확화 과정을 거쳐 투표로 우선순위를 결정한다.
CRUD 매트릭스(Create, Read, Update, Delete)는 데이터 엔티티와 프로세스 사이의 관계를 정의한다. 기능별 데이터 접근 권한과 처리 방식을 분명히 해 시스템 기능을 정리할 수 있다.
프로토타이핑은 초기 UI/UX 설계를 참여자에게 보여 주는 시각적 의사소통 수단이다. 사용자 피드백을 바로 반영하면서 요구사항 이해도를 높이는 데 쓴다.
JAD가 요구사항 품질에 주는 영향
JAD는 집중된 세션에서 의사결정을 진행하므로 요구사항 도출 시간을 일반적으로 40-60% 줄일 수 있다. 후반부 변경 요청을 줄여 개발 비용을 낮추고, 불필요한 기능 개발을 피하는 효과도 기대할 수 있다.
사용자가 직접 참여하면 실제 요구사항을 더 정확히 파악할 수 있다. 여러 관점에서 검증하면서 누락을 줄이고, 실시간 피드백으로 요구사항을 정교화할 수 있다. 개발자와 사용자 사이에 직접 소통 채널이 생기고 상호 이해와 신뢰, 프로젝트에 대한 공동 주인의식도 형성된다.
세션에서 합의한 내용을 즉시 기록하면 모든 이해관계자가 검증한 요구사항 문서를 남길 수 있다. 이는 이후 참조할 수 있는 자료이자 명확한 요구사항 명세서의 기반이 된다.
운영에서 놓치기 쉬운 조건
JAD의 성패는 세션 이전에 상당 부분 결정된다. 목표와 의제를 명확히 하고, 필요한 참여자를 선정하며, 자료와 도구를 준비해야 한다.
진행자는 어느 한쪽의 입장에 치우치지 않아야 한다. 의견 충돌을 조정하고, 특정 참여자에게 논의가 쏠리지 않도록 하며, 회의가 정한 목표를 벗어나지 않게 관리한다.
세션은 방해받지 않는 독립된 공간에서 진행하고 필요한 도구와 장비를 갖춘다. 창의적 사고를 촉진하면서도 편안하고 생산적인 작업 환경을 마련할 필요가 있다. 세션당 시간은 일반적으로 4-6시간으로 유지하고, 주제별 시간을 배정하며 적절한 휴식 시간도 포함한다.
결정사항은 즉시 문서화하고 책임을 배정해야 한다. 후속 활동 계획을 세운 뒤 정기적인 검토와 피드백 수집으로 결과를 이어 간다.
인터뷰, RAD, 애자일과 구분되는 지점
전통적 인터뷰가 1:1 또는 소규모 대화에서 개별 의견을 수집한 뒤 종합하는 방식이라면, JAD는 집단 세션에서 의견을 모으고 충돌을 즉시 다룬다.
RAD(Rapid Application Development)는 빠른 개발과 반복적인 프로토타이핑에 무게를 둔다. JAD는 요구사항 도출에 초점을 맞추며, RAD의 초기 단계에서 결과물을 제공할 수 있다.
애자일은 요구사항을 지속적이고 점진적으로 관리하며 변화에 더 유연하게 대응한다. JAD는 초기 집중형 요구사항 수집 방식으로, 애자일 프로젝트의 초기 릴리스 계획에 적용할 수 있다.
적용 사례에서 확인되는 변화
A은행의 신규 인터넷뱅킹 시스템 개발 프로젝트에서는 3일간의 JAD 세션으로 150개 이상의 요구사항을 도출했다. 초기 설계 단계에서 문제점을 발견해 개발 지연을 막았고, 최종 사용자 만족도 92%를 달성했으며 기존 방식보다 개발 기간을 30% 단축했다.
정부 민원처리 시스템 개발에는 다양한 부서의 이해관계자 50명이 JAD 세션에 참여했다. 이 과정에서 부서 간 업무 프로세스를 통합하고 표준화했으며, 요구사항 변경으로 인한 비용을 이전 프로젝트 대비 45% 줄였다. 시스템 사용성 향상으로 민원처리 시간은 40% 단축됐다.
중견 제조기업의 ERP 시스템 맞춤형 개발에서는 생산, 물류, 재무, 인사 등 전 부서 담당자가 JAD에 참여했다. 현장 요구사항과 경영층 요구사항의 균형점을 찾고, 부서 간 데이터 흐름과 인터페이스를 최적화했다. 구축 후 추가 개발 요청은 60% 감소했다.
원격 협업과 애자일 환경에서의 활용
원격 근무 환경에서는 화상회의 도구, 디지털 화이트보드, 협업 도구를 이용해 가상 JAD 세션을 운영할 수 있다. 이를 통해 시간대와 지역의 제약을 넘어 워크숍을 진행한다.
애자일 환경에서는 초기 릴리스 계획에 JAD를 활용하거나, 스프린트 계획에 JAD 기법을 적용할 수 있다. 사용자 스토리 작성과 우선순위 결정에 쓰면서 지속적인 이해관계자 참여 모델을 만들 수 있다.
JAD 세션 결과를 자동으로 문서화하는 도구, AI 기반 요구사항 분석과 충돌 감지, 협업 플랫폼과 통합된 JAD 도구도 활용 대상이다. 자연어 처리를 이용해 요구사항을 정형화하는 방식 역시 이 흐름에 포함된다.