42서울 오픈스튜디오 프로젝트 개발기 - 3

42서울에서 진행하는 42 서울을 위한 프로젝트 개발기

세 번째 이야기

📅 (2021 / 03 / 09 ~ 2021 / 03 / 15)

유저가 이용할 수 있는 기능은 어떤 관계를 갖고있는 지 살펴보자 ! 😃

유저가 어떤 기능을 사용할 수 있는 지 유저스토리를 통해 살펴보았었다. 만든 유저스토리를 보면 유저가 어떤 서비스를 이용할 수 있는 지는 알 수 있었지만, 이 기능들이 어떠한 관계로 엮여있고 선수행 대상으로 무엇이 필요한 지에 대해서 알 수 없었다. 그래서 우리 팀은 구체적으로 웹 애플리케이션 화면을 어떤 순서와 구성으로 할 지를 정하기 이전에 기능들이 어떤 관계로 이루어지고 기록하기 위해 유스케이스 다이어그램을 작성하기로 했다.

유즈케이스 다이어그램

유스케이스 다이어그램을 작성하면서 우리 서비스가 제공하려고 하는 기능들이 어떤 상관 관계를 갖고있는 지 다시 살펴볼 수 있었다. 예를 들면 로그인 기능과 다른 기능들과의 관계를 생각해 볼 수 있었는데, 로그인하지 않은 유저는 서비스 첫 페이지를 말하는 랜딩 페이지만 이용이 가능하다라는 것에 대해서 회의를 진행 할 수 있었고 다이어그램으로 기록함으로써 모두가 같은 내용으로 인지할 수 있었다.

오픈 스튜디오는 어떤 내용이 어떤 순서로 화면에 나올까 ? 👀

유스케이스 다이어그램 문서가 나오면서 기능들의 관계가 정리가 되었고 웹 페이지를 어떤식으로 구성해야될 지에 대한 생각이 가능해졌다. 회의를 진행했고 유스케이스를 기준으로 초기 페이지(랜딩 페이지)와 서브젝트를 보고 신청하는 페이지, 개인정보 페이지로 구성하기로 결정했다.

와이어 프레임 작성 과정

처음 시작을 할 때에는 유스케이스 다이어그램도 나왔고 어떤 페이지로 나오면 좋겠다. 라는 내용이 나와서 금방 완성될 것으로 예상을 했었다. 하지만 와이어프레임을 만들 때 2일이나 걸리게 되었었는데 이제와서 돌아보니 UI 라던지 "어떤 식으로 UX를 하면 좋겠다." 라는 대한 현재 단계에서 필요없는 웹 디자인의 내용을 굉장히 많이 얘기하고 회의를 했었던 것 같다.

와이어 프레임에서 보이는 데이터 📄

와이어 프레임을 그리면서 이 화면엔 어떤 내용이 나오도록 할 것인가에 대해 얘기해볼 수 있었다. 그러다보니 각각의 페이지에 들어가는 데이터를 생각해보게 되었고 자연스레 데이터와 모델을 뽑았다.

와이어 프레임 작성 과정

그 다음으로 데이터가 나왔으니 바로 api 명세를 작성해보는 것이 어떨까? 라는 얘기가 나오기 시작하여 바로 페이지 별로 뽑아낸 데이터를 토대로 api 명세를 작성을 하게되었다.

멘토님의 팩트 폭행 😂

한 주 내용 보고서

한 주가 지나고 오종인 멘토님에게 보고를 하는 시간이 다가왔다. 나름 결과가 나와서 열심히 준비했다. 라는 생각을 갖고 우리의 한 주 결과를 보고를 했는데 결과는,, 참담했다. 😭

멘토님에게 많은 피드백을 받은 내용으로는 여러가지가 있었는데, 첫 번째로 우리 팀의 문서화 작업물은 명시적이지 않다는 것이다. 즉, 유저스토리와 유스케이스 다이어그램을 보고 어떤 서비스인지 알 수 없다는 것이였다. 유저스토리에 팀 매칭이라는 것을 적어놨는데 멘토님이 느끼기에 팀 매칭이라는 것은 팀을 만들고자 하는 유저와 팀원이 되고자 하는 유저가 매칭되는 시스템으로 인지를 하셨는데, 우리 서비스의 팀 매칭은 유저가 특정 서브젝트의 매칭을 신청하면 해당 서브젝트의 풀을 만들어 정해진 날에 모든 유저를 랜덤하게 배정하여 팀을 만드는 서비스였다.

이것의 근본적인 문제는 무결성이 없어서라고 하셨는데, 유저스토리를 기반으로 유저 시나리오 혹은 유스케이스 다이어그램을 만들어야 하는데, 유저스토리는 유저스토리대로 유스케이스는 유스케이스대로 만들어서 문제가 생긴 것이라고 얘기를 해주셨다.

그 다음으로 와이어 프레임을 피드백 해주셨다. 와이어 프레임은 유스케이스 다이어그램을 묶어서 화면이 어떤 식으로 넘어가는 지를 보여줘야 하는데, 전혀 알 수 없다. 라는 말씀과 와이어 프레임과 더불어 유스케이스 다이어그램 등을 하는 이유는 문서화를 하기 위함인데 디자인과 같은 의미없는 것에 시간을 쏟고 있다는 팩트와 함께 충분한 고민이 느껴지지 않는다. 전혀 성의가 느껴지지 않는다.는 쓴 소리를 해주셨다.

와이어 프레임과 더불어 api 명세에 대해서도 피드백을 받을 수 있었는데, 후에 모바일 앱으로 서비스를 하게될 수도 있는데 페이지 별로 api를 작성했다는 내용을 지적해주셨고 api의 구체적인 작명에 대해서도 지적을 해주셨다. 또한, api 명세를 작성하기 위해서는 더 많은 내용이 있어야하는데 어떻게 벌써 api 명세가 나왔는 지 라는 의문을 얘기해주시면서 문제점을 제시해주셨다.

정말 많은 생각이 들게되는 시간이었고, 앞으로 어떤 방향으로 나아가야 되는 지 깨닫게 되는 시간이었다.

팩트로 맞은 것은 정말 아팠지만, 오히려 좋은 시간을 갖게되었다. 정말 많은 것을 생각해볼 수 있었다. 우리 팀이 문서화를 하면서 놓치고 있던 문서화의 진정한 의미(누군가 다른 사람으로 대체되더라도 서비스를 똑같은 내용으로 알 수 있도록 하는 것)와 각각의 문서의 의미를 되새길 수 있었다.

회의로 백날 얘기하는 것은 의미없다.라는 것을 깨달을 수 있었다. 많은 회의를 끝에 우리 팀은 서비스 내용을 같은 내용으로 인지하고 있었지만 기록물인 문서들은 그것을 나타내지 않았다. 그렇기에 멘토님에게 우리 팀의 서비스에 대한 열정을 보여드릴 수 없었다.

🚦 한 주의 내용 짧은 평가

평가 점수 🔴

이번 주는 무엇인가 회의가 어수선하게 돌아갔었다. 저번주와 그 전 주에서 느꼈던 문제점인 회의가 비효율적으로 길어지는 것을 해결하고자 했지만 오히려 회의를 어수선하게 만들었던 것 같다. 또한, 이번주의 목표인 유스케이스 다이어그램, 와이어 프레임과 api 명세 작성을 끝내긴 했지만 의미 없는 곳에 시간을 쓰는 결과를 만들어냈다.

현재 진행하고 있는 작업의 본질을 놓치고 있었고 그렇기에 더 많은 시간을 쓰게 된 것을 확인할 수 있는 한 주 였다. 하지만 그저 무의미한 한 주인것은 아니었다. 결과적으로 잘못된 방향으로 가고 있었지만 멘토님에게 많은 것을 배울 수 있는 시간을 갖을 수 있었다. 무엇을 놓쳤는 지, 다시 방향을 어디로 돌려야할 지 깨달을 수 있었다. 이 내용을 바탕으로 더 깊이있게 생각하고 앞으로 나아가야겠다.