구현할 기능에 대한 전체적인 밑그림 그리기(20221115-TIL)

어제는 비록 기능은 한 가지지만 이것을 오롯이 정리하고 어떻게 구현해나갈지 다시 처음부터 생각해보았다.

https://onulmansanda.tistory.com/218

서비스의 사용성 생각하며 다시 설계하기[20221114-TIL]

 

설계는 왜 어려웠을까?

 포트폴리오 초반에 설계의 어려움에 관하여 엄청 많이 썼었는데 오늘은 조금이나마 그 가닥을 잡은 것 같아서 다시 써보려고 한다.

 

일단 어려웠던 이유를 분석해보자

1. 참조할 모델이 있어서 그것에만 의존을 했다.

참조하는 서비스 모델이 있었는데 오로지 보이는 그것에만 집중하다 보니 자꾸 '뭘 생각하라는 거야... 뭘 더 키워... 그냥 해보는 거지 뭐'라는 생각이 들었다. 근데 무작정 해보는 것도 사실 나쁘진 않았다.

 

2. 처음이라 어찌 설계를 잡아가는 지 몰랐다.

사실 트레이너분들이 여러 방식을 알려주셨지만 나는 새로 하는 것에 조금 낯섦을 느끼는 편이라 익숙지 않아 더 어려웠다. 그런데 한번 기존에 했던 설계를 다 뒤엎고 다시 해보고 또 동료들의 좋은 설계 방식도 참조하니 아직 어설프지만 그래도 조금 편해졌다.

 

무엇이 달라졌나?

작게 하나부터 잘 만들기

일단 기존에 내가 하려던 서비스의 크기가 너무 컸다. 사실 양이 적어보이고 별게 없다고 생각하던 터라 막 때려 넣었었는데 결국 작은 실패를 여러 번 겪고 나니 크기가 큰 것을 느꼈다. 작더라도 제대로 만들자라는 목표를 세우고 다시 하나의 도메인 모델을 완벽히 구현해내려고 애썼다.

 

하나의 모델에 대해서 아래와 같은 다이어 그램을 그려보았는데 사실 그릴게 뭐가 있겠어라고 했는데 

백엔드 모델을 만들거나 fake model을 만들어줄때마다 속성을 무엇이 들어가지 하고 정리가 되지 않아서 난잡했던 경험이 있다.

아래처럼 정리해두니 백엔드를 만들때 매우 편리했다.

다음에도 하나의 도메인에 대해서 저렇게 정리를 해두고 가는 것이 초기에 수정을 하더라도 편하다는 것을 배웠다.

비슷하거나 유사한 서비스 시장조사하기

시장조사라고 하면 이상하지 모르지만 내가 하려는 서비스가 유일한 서비스는 아니기 때문에 참조모델이 반드시 있다. 근데 그 조사가 미흡했다. 내가 밑바탕으로 하는 참조 서비스 말고도 더 좋은 서비스들이 있었는데 이것들의 인터페이스와 구성을 참조하면서 내가 직접 사용할 때 무엇이 더 좋을까라고 고민하며 후보군에 정리해 두었다.

 

간단하게라도 예시 UI 그려보기

이전에 유료 기획서 프로그램을 이용해서 기획서를 썼었는데 기획 자체보다 디자인에 시간이 많이 들어 애를 먹었었다. 일단 여러 후보군을 틀이 보이도록 노션에 정리한 후 mvp를 만들고 사용성에 대한 피드백을 받아보기로 결정했다.

 

URL 상세히 작성하기

추가로 유저 스토리를 조금 더 상세히 작성하고

 

동료분이 각각의 페이지에 대해 url을 상세히 써놓았길래 나도 따라 해 보았는데 이게 뭐 아는데 왜 그래라고 하는 것 같지만 적어두는 게 정말로 url에 대한 인지 자원을 줄여주고 통일성을 높여준다.

 

API 스펙 상세

 

이것 또한 동료분이 작성한 기획서에서 따온 것인데

API 스펙을 상세히 서술하여 백엔드에서 개발을 할 때 어떤 이름을 지을지 어떤 DTO로 받아올지 등의 고민을 줄여주어서 너무 편리한 것 같다.

 

 

이제 일단 하나의 도메인 모델에 관해서는 그래도 개략적으로 마친 것 같은데 추가로 빠진 부분이 없는지를 점검하고 프런트의 인수 테스트 코드를 작성하러 가보려 한다!