캡스톤 디자인 PART.1, 2주차(요구분석, 프로토타입 작성)

서론

요즘은 개발자가 기획도 하고 아이디어 회의에도 참여합니다. 즉 주어진 요구사항에 맞는 적절한 개발을 해야 사용자를 만족시킬 수 있습니다. 부트캠프를 하며 협업과 형상관리 기술을 배웠습니다. 캡스톤 디자인에서 아이디어 동기화의 끝인 요구사항을 분석해보는 경험을 쌓아 프로젝트 기획, 설계 단계를 마무리 해보겠습니다.

 

본론

요구사항 명세서를 작성하며 저희팀 주제로 들어온 학과측의 요구사항을 분석해 보겠습니다.(참고 1)

 

- 요구사항 명세서에 관하여(참고2)

=> 서론

서비스를 구현하기 위해 다양한 요구사항이 거론되는데 이를 명확하게 정리해야 할 필요가 있습니다. 요구사항 명세서는 요구사항을 분석하여 명확하고 완전하게 기록하는 것을 말합니다.(아이디어 동기화의 끝판왕) 소프트웨어 시스템이 수행해야 할 모든 기능과 구현상의 제약 조건에 대해 개발자와 관련자(클라이언트, 기획자, 경영진 등)가 합의한 스펙에 대한 사항을 명세합니다.

 

=> 왜 작성해야하나요?

작성된 요구사항 명세서를 토대로 회의가 진행되기 때문입니다. 실제 필요한 기능인지, 개발 이슈는 없는지, 이번 단계(버전)에서 개발하는 것이 좋은 것인지 검토합니다. 처음 작성한 명세서가 버전 1이고 피드백된 내용 또한 업데이트하여 관리합니다. 구체적으로 아래와 같은 것을 할 수 있습니다.

 

1) 프로젝트 전체 규모를 파악

2) 구현 가능 여부에 대한 논의

3) 커뮤니케이션 비용 절약

4) 프로젝트 일정 계획 수립 

 

=> 무엇을 기재해야 할까요?

요구사항 명세서는 공식적으로 사용하는 양식은 없지만, 필수로 기재해야 하는 항목은 대게 유사합니다.

 

1) ID : 내부 규칙에 따라 식별자를 부여한다. 하나의 요구사항에 하나의 식별자
2) 화면명 : 어느 화면에서 구현할 기능인지 기재한다. 화면에 속하지 않는 요구사항도 있을 수 있다.
3) 요구사항명 : 요구사항의 설명을 요약하여 기재한다.
4) 내용 : 요구사항의 상세한 내용을 기재한다.
5) 중요도 : 상중하, 1~5 
6) 부서/작성자 : 요구사항을 기재한 담장자를 기재, 부서가 없는 경우 생략해도 무방 
7) 날짜 : 요구사항을 기재한 날짜를 명시 
8) 진행사항 : 검토 예정, 진행 확정 등 내부에서 결정된 사항을 기재한다. 진행 불가이거나 추후 진행일 경우 이유를 같이 적는 것이 좋다. 
9) 버전명 : 요구사항이 변경될 수 있으므로 버전으로 표기하여 타인이 알 수 있게 한다.

 

※ 좋은 요구사항 명세서가 가지고 있는 특징

1) 요구사항 명세서를 읽는 작업자(개발자, 디자이너 등)가 이해하기 쉬워야한다.

2) 무엇을 어떻게 구현되어야 하는지 명확하게 작성한다.

3) 하나의 요구사항에 여러가지 요구사항을 작성하지 않는다.

4) 다른 요구사항 모순 또는 중복되지 않게 한다.

5) 애매한 단어를 사용하지 않고 명확하게 기재한다.(~있으면 좋겠다 -> ~ 기능 필요)

6) 꼭 필요하고 중요한 요구사항은 표시하는 것이 좋다.

7) 동일한 용어를 사용한다. 댓글, 코멘트와 같이 모두 같은 의미를 다르게 표현하지 말라

8) 난이도가 있는 기능이거나 프로젝트 기간이 짧아 모든 요구사항을 구현하기 어려울 상황일 경우, 대체 가능한 다른 방법도 함께 기술하여 전달하는 것이 좋다.

 

- 요구사항 명세서 작성

-> 작성하는 방법

화면명, 요구사항명, 요구사항 내용을 먼저 작성합니다. > 후에 다른 컬럼들을 고민해보고 적습니다.

 

(참고 1)의 제목이 요구사항명이 되겠고 세부 항목이 요구사항 내용이 되겠습니다.

 

※ 작성 중 이슈 발생

화면명, 요구사항명이 바로 작성하기 애매합니다. 따라서 일단 화면명은 관리자, 유저로만 나누고 나중에 세세하게 나눕니다.

 

=> 챗봇 요구사항 명세서 작성 강조

우리 서비스에서 제공하려고 하는 것은 지능형 봇이 아닌 규칙 기반 챗봇으로 SQL로 사용자가 원하는 정보를 찾아 응답해야합니다.

 

> 챗봇 외에 기능은 요구사항이 이미 정립이 된 상태였으므로 딱히 요구사항 분석을 할 필요가 없는 부분이었습니다. 하지만 챗봇은 처음부터 끝까지 저희팀이 구현해야하는 부분으로 요구사항을 분석하여 프로젝트에 녹여 내야하는 것이었습니다. > 제가 진행한 요구사항 분석에는 추가된 내용이 있었습니다. 바로 기존 챗봇의 밴치마크 리서치였습니다. 이 조사를 통해 요구사항 분석의 디테일을 잡고 구현의 방향을 잡을 수 있다고 생각합니다.

 

 

-> 기존 챗봇 밴치마크 리서치(참고 3)

1. 규칙기반 챗봇

if/else 논리를 사용하고 미리 정의된 시나리오에 따라 쿼리에 응답합니다. 고객과의 상호 작용은 키워드 기반으로 하고 모든 개선(유지 보수 등)은 수동으로 이뤄집니다.

 

> 장점

만들기가 쉽고, FAQ 답변과 같은 간단한 작업을 수행하기에 충분합니다. 또한 개발 비용이 적습니다.

 

> 단점

AI 자가 학습이 없고 미리 정의된 일련의 질문에만 답할 수 있는 능력을 가지며 수동 개선이 필요합니다.

 

> 챗봇을 구축하는 방법

1) 챗봇의 목적을 정의하고 배치할 위치 선택

① 목적 : 조교들이 주기적으로 받는 전화들을 대신 해결할 수 있는 졸업 도우미 챗봇 기능을 만듭니다. ex) 학생의 이름을 입력했을 때 들어야하는 msc는 무엇이고 몇 학점 남았나 등

 

② 위치 : 챗봇을 배치할 위치를 식별합니다. 기본 커뮤니케이션 채널을 식별하고 사용자와 가장 많이 상호 작용하는 위치를 정의합니다. 

 

2) 챗봇 대화를 디자인하고 환영 메시지에 대해 생각

챗봇의 첫 번째 메시지를 정의하고 이를 트리거로 사용하여 인사말로 시작하고 사용자에게 도움을 제공하는 것과 같이 커뮤티케이션을 시작합니다. ★ 그 후 봇에게 다음 대화 흐름을 만드는 것이 중요합니다! ① 객관식 질문을 사용할지, ② 사용자가 질문 버튼을 클릭하여 쿼리를 선택할지 질문 유형을 생각합니다.

 

3) 챗봇 테스트

다른 소프트웨어와 마찬가지로 챗봇을 테스트해야 합니다. 다양한 대화 시나리오를 시도하여 봇이 어떻게 작동하고 필요한 경우 개선되는지 확인해야합니다.

 

4) 로그를 저장하여 AI 모델로 발전

 

 

2. 시나리오 기반 챗봇

챗봇 UI 설계 및 인터페이스 설계에 관한 강연입니다.

 

1) 챗봇이란?

심심이를 보면 사용자가 입력한 키워드를 토대로 자동으로 답변하는 시스템으로 재미의 영역이었다면 지금은 전무적인 비서 역할을 하는 챗봇의 역할이 커지는 추세입니다. 

 

+ 강연에서 챗봇 조사 결과 : 

① 앱 내 챗봇 : cs 영역으로 앱과 연관된 기능 제공
② 플랫폼 이용 챗봇 : 사용자에게 컨텐츠를 제공(계좌 개설 등)
③ 직접 입력 방식 : 실제 채팅과 동일한 경험 유지
④ 선택지 제공 : 정보 범위를 한정 지어 빠른 탐색 가능

 

 

 

-> 조사에 따른 1차 기획 

① 앱 내 챗봇이고 버튼을 제공하면 좋겠고 기능 범위가 작으니깐 선택지로 정보 탐색하게끔 하자

② 사용자가 종료하고 싶거나 다른 정보를 찾고 싶을 때 자연스럽게 종료를 할 수 있게하자

 

> ★ 하지만 이것은 차별성이 없는 일반적인 챗봇의 앱 구조였고 보다 중요한 것은 대화를 어떻게 이끌어 가는 지를 봐야한다는 것입니다. 챗봇은 대화를 하는 것이 중점인 것을 알아야합니다.

 

 

2) 챗봇의 대화에 관하여(실제로 사람이 하는 방식으로 하자는 것)

① 사람을 만나면 인사를 하고 내가 누군지를 소개를 해주고 이 사람과 어떤 대화를 할지 머릿속으로 고민을 한다. 이런 주제를 해야겠다고 선정을 하면 이 대화를 이끌어 나가게 되고 만약 이 대화가 다른 주제로 가면 다른 주제로 변경해서 다시 대화를 하게 됩니다.
② 대화를 끝내고 이 사람과 이별할 시간이 되면 작별인사를 하게 됩니다.

 

3) ↑ 이것을 서비스하는 시선으로 보게 되면

 

① 서비스 진입 단계 : 인사 > 소개/안내

② 정보탐색 단계 : 대화를 하는 순간

③ 종료, 재 진입 유도 단계 : 작별, 재진입을 유도하는 단계

 

4) 차별화를 둔 이후 2차 기획

① 첫 진입시 챗봇 기능을 대화로 안내

hi there 인사를 하고 대화를 통해서 이 기능이 어떻게 사용하는 것인지 알려준다. 이것을 굉장히 친절하게 제공을 해주면서 아! 이 챗봇이 이런 선택지를 통해서 정보를 탐색하는 구나를 알 수 있습니다.

 

② 정보탐색

대화를 하면서 사용자가 이탈을 하지 않도록 하나하나씩 단계를 밟아갑니다. 대화를 하다보니 '어?? 자연스럽게 입력을 다 했네??' 이런 기분을 받도록 해야합니다.

 

또한 플러스 알파로 구글 같은 경우 우리 대화와 관련된 추가적인 정보를 알려줘서 이 대화가 끝나고 다른 정보를 더 탐색할 수 있게 유도를 해줍니다!

 

③ 종료

대화가 끝나더라도 다시 보고 싶으면 시작을 입력하면 된다! 이런식으로 재진입을 유도합니다.

 

 

=> 이를 토대로 요구사항 명세서 챗봇 파트 작성

위에서 고민했던 방식 그대로 요구사항 명세서 챗봇 파트를 작성하였습니다. 이는 실제로 요구되는 사항들을 요구받고 > (보다 완벽한 요구 달성을 위한)조사하고 > 명세서를 작성하기까지 처음부터 끝까지 완료해본 첫번째 경험입니다!

 

 

- 프로토타입 작성

UI 담당자가 제공한 홈페이지입니다. 오른쪽 부분이 챗봇이 들어갈 부분으로 저 안으로 들어가면 chatGPT같은 인터페이스가 나오고 챗봇을 넣을 것입니다.

 

 

 

 

 

- 2주차 회의

회의에 관하여 생각해보는 계기가 되었습니다. 요즘 부트캠프에서는 오전, 오후 PR 회의를 하며 회의에서 아주 체계적인 대화가 오고갑니다. 그에 비해 캡스톤은 공부와 배포에 주를 두고 있기에 회의 때 어떤 내용을 말하고 정리해야할까 고민이 됩니다.

 

> 결과적으로 : 캡스톤은 이대로 진행하겠지만 회의에 대해 정리해보자면 부캠에서 하듯이 오전, 오후, PR 회의를 하고 그때마다 진행상황, 향후일정을 공유하며 프로젝트 기획할 때 전체회의, 스프린트 끝나면 한 주 회의를 하면됩니다.

 

 

 

결론

- 느낀점

1. 요즘은 이런 요구사항 명세서를 작성해 보는 것이 다 스펙입니다. 정말 필요성을 느끼지 못하면 요구사항 명세서를 쓸 생각을 못합니다. 저는 개발은 아직 안했지만 프로젝트를 전반적으로 설계하는 방법과 기획하는 방법을 배웠고 협업하는 방법을 익혔습니다. 이제 개발을 위한 기반이 탄탄히 다져졌습니다!

 

 

2. 챗봇을 처음 만들어보고 사용도 잘 해보지 않은 상태에서 구현을 해야하니 눈 앞이 캄캄하였는데 조사를 진행하니 개발 방향이 잡히는 것 같습니다. 현업에 나가도 개발 경력이 쌓여도 새로운 분야의 문제를 해결하게 되면 제가 이번에 추가한 것을 토대로 요구사항 분석에 반영할 것이라고 생각합니다.

 

 

참고

요구사항

요구사항 명세서란?

규칙기반 챗봇