프로젝트를 시작하기 전에 - 무엇을 어떻게 만들 것인가

무엇을 만들 것인가

- 프로그래밍이란?

 

프로그래밍이란 말 그대로 프로그램을 만드는 것입니다. 그렇다면 프로그램은 왜 만드는 것일까요?

이에  답하기 위해선 사람들이 어디서 어떻게 프로그램을 사용하는지를 볼 필요가 있습니다.

 

병원에서는 모든 환자의 진료 기록을 보관하고 분석하기 위해 소프트웨어 프로그램을 쓰고

은행에서는 고객의 소중한 자산을 관리하고 보호하기 위해 소프트웨어 프로그램을 씁니다.

 

즉 프로그램은 특정한 분야의 어떠한 문제를 해결하기 위해 만들어집니다. 

그러니까 ' 프로그래밍이란 특정한 분야의 문제를 해결하기 위해 프로그램을 만드는 것'이라고 정리할 수 있습니다.

 

- 도메인 

 

여기서 '해결해야 하는 문제가 있는, 프로그램을 사용할 특정한 분야'를 도메인이라고 합니다.  도메인에 대해 정확히 이해하기 위해서는 전문 지식이 필요한 경우가 대부분입니다. 개발 커뮤니티에서 '혼자 프로젝트를 해야 겠는데 어떤 프로젝트를 해야할지 모르겠어요' 라는 질문을 자주 볼 수 있는데 도메인의 이러한 특성을 생각해보면 결국은 평소 본인이 관심 있어 하는 부분을 도메인으로 설정하는 것이 중요하다는 결론에 닿을 수 있습니다. 본인이 잘 모르는 분야의 문제를 해결하는 건 문장부터 이상한 말이니까요.

 

도메인을 설정했다면 그 다음은 올바른 문제를 찾기 위해 질문을 던질 차례입니다. 예를 들어 '오늘 뭐 먹지?'라는 문제를 해결하기 위한 프로그램을 만드려고 한다면 일단 왜 이런 고민을 하는 지에 대해  질문하는 것으로 시작하는 것이죠. 다양한 답이 나올 수 있겠지만 

 

• 주변에 어떤 가게가 있는지 잘 몰라서
• 매일 같은 곳에 가기는 싫어서
• 예전에 봐둔 좋은 가게가 있는데 기억이 잘 안나서
• 가고 싶은 가게가 있는데 자리가 있는지 모르겠고, 전화하기는 심리적으로 불편해서 다른 곳을 고려하느라

이 질문에 대한 답을 위와 같이 정리한다면, 이제 이를 토대로 해결방법을 생각해나갈 수 있습니다.

 

- 사용자 스토리

 

이 때 해결 방법, 즉 프로그램에 추가할 기능들은 사용자 입장에서 생각하는 게 중요합니다. 

그렇기 때문에 추가할 기능을 사용자 입장에서 서술하는 사용자 스토리를 작성하는 것이 좋습니다.

 

사용자 스토리는 아래와 같은 간단한 포맷을 가지고 있습니다.

 

사용자는 / 가치를 위해 / 기능을 할 수 있다.

 

즉 프로그램의 사용자를 고객, 가게, 관리자로 가정해 사용자 스토리를 작성하면

 

• 고객은 / 뭘 먹고 싶은지 발견할 수 있도록 / 가게 목록을 볼 수 있다.
• 고객은 / 정확히 먹고 싶은 게 뭔지 확인하기 위해 / 가게의 메뉴를 볼 수 있다.
• 고객은 / 찾은 가게가 좋은 가게인지 알 수 있도록 / 평점을 확인할 수 있다.
• 고객은 / 선택의 폭을 좁히기 위해 / 가게 목록을 분류에 따라 볼 수 있다.
• 고객은 / 나와 남을 위해 / 가게에 평점과 리뷰를 남길 수 있다.
• 고객은 / 나중에 찾아볼 수 있도록 / 가게를 즐겨 찾기에 추가할 수 있다.
• 고객은 / 가게에 연락을 하거나 기다리지 않도록 / 인원과 메뉴를 예약할 수 있다.
• 가게는 / 가게에  관심있는 고객을 받기 위해 / 예약 요청을 볼 수 있다.
• 가게는 / 더 나은 고객 서비스를 위해 / 예약 요청에 응답할 수 있다.
• 관리자는 / 고객이 서비스를 쓸 수 있도록 / 가게 정보를 등록할 수 있다.

간단히 위와 같이 정리할 수 있습니다. 단순히 그림 몇 장 그리거나 기능 목록만 나열하는 것이 아니고 이렇게 누구의 어떠한 가치를 충족시키려 기능을 만드는 지를 명확히 하면 우리가 집중해야 하는 부분이 명확해 질 뿐만 아니라 만약 협업을 한다면, 개발에 참여하는 구성원들이 공통의 목적을 갖게 하는 데도 효과적입니다.

어떻게 만들 것인가

- 계획을 세우자

 

어떻게 만들지를 생각하기 전에 해야하는 건 어떤 순서로 작업할 것인지 계획을 세우는 일입니다. 서비스가 순항한다면 요구사항은 계속 변경될 것인데 기존의 계획이 있어야 변경된 요구 사항에 따라 계획을 어떻게 변경할지, 일정은 얼마나 늘어날지, 무언가를 포기해야 한다면 어떤 것을 포기할지에 대해 판단할 수 있기 때문입니다. 

 

- 도메인 모델링

 

계획을 세웠다면 다음엔 도메인 모델을 만들어야 합니다.  도메인 모델링은 도메인에서 프로그래밍에 필요한 개념들만을 추려 추상화하는 것 입니다.  고객, 식당, 메뉴 등등이 가지고 있는 속성은 다양하지만

• Restaurant  (가게 이름, 주소, 가게가 취급하는 음식 종류)
• Menu Item ( 음식과 음료들 )
• User ( 사용자 정보 - 고객, 가게, 관리자 )
• Favorite ( 가게 즐겨 찾기 정보 )
• Review ( 가게에 대한 리뷰 정보 )
• Reservation ( 누가 어떤 메뉴를 예약 했고 예약자가 몇명인지 )

이렇게 서비스 개발에 필요한 것들을 추려 추상화 하는 것이 도메인 모델링입니다. 

 

- 시스템 아키텍쳐

 

다음으로는 시스템을 구성해야 합니다. 시스템은 소프트웨어와 하드웨어를 포함한 전체를 의미합니다. 이를 구성하는 방식으로는 Multi-tier Architecture 그 중에서도 

 

• Presentation ( Front - End )
• Business ( Back - End )
• Data Source ( DB )

로 구성된 3-tier Architecture를 주로 사용합니다. 각각의 세부적인 구성은 택하기 전에는 먼저 제약 조건을 알아보는 것이 좋습니다. 제약 조건에 위배되는 것은 선택지에서 제외하면 되니까요.

 

예를 들어 Web과 Mobile 양쪽으로 서비스를 하겠다고 하면 일단 Presentation (front-end) 부분은 html + css + javascript를 사용해 브라우저에 대응하는 부분을 개발하고, kotlin이나 swift를 활용해 모바일에 대응하는 부분을 따로 개발해야 할 것 입니다.

 

그러나 Business 부분과 Data Source 부분은 공통으로 가지고 가야겠죠. 그러니 REST-API나 GraphQL을 활용해 Business 부분을 구성하고 하나의 mySQL이나 Oracle로 Data Source 부분을 구성해야 할 것 입니다. 

 

이 중 Business 영역은 프로그램의 복잡도를 낮추기 위해 해당 부분을

 

• UI Layer
• Application Layer
• Domain Layer
• Infrastructure Layer

로 나누는 Layered Architecture 로 나누는 게 일반적입니다.

 

---

참조

 

객체지향의 사실과 오해

Fast Campus - Java 웹 개발 마스터 - 스프링 부트 프로젝트 - 02. 무엇을 만들 것인가

Fast Campus - Java 웹 개발 마스터 - 스프링 부트 프로젝트 - 03. 어떻게 만들 것인가