2020. 9. 6. 18:47ㆍ웹서비스
김밥집을 차려보자. 일단 음식을 만들 재료가 있어야 한다. 쌀, 김, 계란, 단무지, 오이, 당근, 햄, 맛살, 우엉, 참치, 소고기, 식용유, 소금 등을 준비한다. 이런 재료들을 이용하여 여러 가지 김밥을 만들 수 있는 레시피도 있어야 한다.
재료와 레시피만 있다고 해서 김밥이 뚝딱 만들어지는 것은 아니다. 김밥을 만들 주방장이 있어야 한다. 주방장은 음식에 집중을 해야 맛을 유지하거나 더 맛을 낼 수 있다. 재료, 레시피, 주방장만 있다고 해서 식당을 차리기에는 힘들 듯 보인다. 홀이나 전화 주문을 받을 고객 서비스를 담당하는 사람도 필요하다.
가게 장소는 이미 있다고 생각하자. 장소와 재료와 주방장, 홀 서비스를 할 사람까지 준비가 됐으면, 오픈만 하면 된다. 오픈하기 전에 우선 고객과 홀 서비스, 주방의 역할이 명확해야 한다. 고객이 들어와서 주방까지 들어가 직접 김밥을 말아서 먹고, 계산도 없이 그냥 나가면 안 된다. 요즘은 고객이 알아서 해 먹고 계산만 하고 나가는 식당도 더러 있지만, 우리 가게는 이런 특색 있는 가게는 아니다.
오픈하기 전에 일단 시뮬레이션을 해보자. 고객이 들어오면 홀 직원은 환영인사를 건넨다. 고객이 자리에 앉고 주문을 한다. 홀 직원은 주문을 받고, 주방에 주문을 전달한다. 주방은 주문을 받고 주문에 나온 음식의 레시피를 찾거나, 생각한다. 레시피에 쓰여 있는 대로 재료들을 준비한다. 레시피에 맞게 음식을 만들고, 완성된 음식을 홀 직원에게 전달한다. 홀 직원은 음식을 받고, 고객에게 음식을 전달한다. 고객은 식사를 마치고 나서 계산대에서 계산을 하고 가게를 나간다.
여기까지가 정상적인 절차이다. 중간에 홀 직원이 주문을 잘 못 받거나, 주방에서 음식을 다르게 만들거나, 재료를 빼먹을 수도 있고, 잊어버리게 되면 고객은 클레임을 걸 수밖에 없다. 진상 고객의 경우에는 음식에 투정을 부리거나, 자신이 주문한 메뉴를 잊어버린 경우도 있을 것이다. 이런 고객 클레임에 대응하는 방안도 준비해야 한다.
오픈하고 나서 장사가 잘 된다면, 일할 사람이 더 필요하다. 홀을 담당하는 사람이 있어야 하고, 계산만 담당하는 사람도 있어야 할 것 같다. 그리고 전화 포장도 서비스한다면 전화 주문만 받는 사람도 필요하다. 홀 주문과 전화 주문을 헷갈리면 안 되기 때문이다.
주방도 마찬가지다. 김밥만 마는 사람과, 한식류를 만드는 사람, 분식류를 만드는 사람이 나누어져 있으면 재료 파악도 잘되고, 음식 제조 시 혼동을 피할 수 있다.
장사가 잘 돼서 매장을 넓힌 것은 물론이고, 직원도 많아졌다. 홀의 구역을 나누어 A영역만 담당하는 직원, B영역만 담당하는 직원이 있고, 계산만 하는 직원, 테이블 정리만 하는 직원, 전화 주문만 받는 직원이 있고, 주방에도 김밥 마는 직원, 한식류만 만드는 직원, 분식류만 만드는 직원, 특식류만 만드는 직원, 설거지만 담당하는 직원을 고용해 성장가도를 달리고 있다.
이런 시스템을 개발 분야와 접목시켜보자.
고객과 홀 서비스, 주방의 역할은 명확히 나뉘어 있다. 고객은 주문하고 식사 후에 계산하고 떠나면 된다. 홀 서비스는 주문을 받고, 주방에 주문을 전달하고 음식을 전달받으면 고객에게 전달해 주면 된다. 주방은 주문을 받으면 재료를 골라 레시피에 맞게 음식을 만들고, 홀 서비스에게 음식을 전달해 주면 된다. 이런 역할에 대해 정의한 것을 유스케이스(useCase)라고 부른다. 시스템을 사용하는 것에 있어서 각각의 역할을 명확하게 정의한 도표이다.
역할이 명확해야 업무분담이 확실하고,
뭘 개발해야 하는지도 명확하게 정의할 수 있다.
역할이 정해졌으면 앞서 해 본 시뮬레이션을 해보자. 고객이 들어온다. 환영인사를 한다. 고객이 자리에 앉는다. 주문을 받는다. 받은 주문을 주방에 알려 준다. 주방은 음식을 준비한다. 완성된 음식을 홀 직원이 고객에게 전달한다. 고객은 식사를 하고 계산한다. 이렇게 절차를 시간순으로 나열한 것을 시퀀스 다이어그램(Sequence Diagram) 시계열 도표라고 부른다.
개발에서도 고객이 들어오면 무엇인가가 처음을 맞이하고, 고객이 요청하는 것을 받아서 다른 시스템에 넘겨준 후 결과를 받아서 고객에게 전달해 주는 절차를 말한다.
시퀀스 다이어그램은 전체 프로세스를 한눈에 볼 수 있는 지도 같은 역할을 한다.
역할과 프로세스는 파악됐다. 좀 더 세부적으로 들어가 보자. 홀 직원은 주문을 받고 주방에 주문을 전달하는 역할을 한다. 홀 직원이 주문을 받고 음식까지 만들어버리면 주방의 역할이 없어진다. 또한 홀 직원이 음식을 만들고 있는데 고객이 들어오게 되면 대응도 안된다. 홀 직원은 홀을 책임지는 역할이 있다. 주방까지 넘보면 안 된다.
주방도 마찬가지다. 고객이 들어오면 환영인사 정도는 해도 상관은 없는데, 홀에 나가 주문까지 받아버리면 홀 직원은 필요가 없다. 주문 또한 꼬이게 된다. 나중에 계산할 때 홀 직원이 주문을 모르면 계산하기가 힘들기 때문이다. 주방 직원은 주방을 책임질 역할이 있다.
주방은 홀 직원에게 주문을 받아야 하고, 고객에게 받아서는 안된다. 홀 직원은 주문을 주방에게 전달해야 하고, 음식을 고객에게 전달해야 한다. 계산하는 직원이 따로 있다면 홀 직원은 주문을 받고 계산 직원에게 주문을 알려주고, 계산 직원은 주방에 주문표를 건네줘야 한다.
주방에는 주문이 하나만 와야 한다. 홀직원도 주문을 전달하고, 계산 직원도 주문을 전달하게 되면 같은걸 중복으로 만들 수 있다. 계산 직원이 최종 주문을 확인하는 직원이라면 홀 직원은 주문을 받아서 계산 직원에게 주문서를 전달하고, 계산 직원은 주방에 주문표를 전달한 후 홀 직원이 음식을 고객에게 전달해야 한다.
앞서 유스케이스가 각각의 역할에 대해 명확히 정의했다면 이런 명확한 정의를 혼동 없이 연결해야 한다. 각각이 해야 하는 일과 누구에게 전달해야 하는지 연결이 정의되어야 혼동이 없다. 직원 간에 업무 연결이 원활해야 한다.
직원은 개체이다. 개체라는 단어가 다소 생소할 수도 있지만, 눈에 보이는 모든 물질적인 것이 개체이다. 나무, 의자, 책상, 건물, 사람, 가방, 컴퓨터, 핸드폰 등등 눈에 보이는 모든 것이 개체이다. 영어로는 오프젝트(object)라고도 한다.
여기서 좀 더 생각을 확장해보자. 요즘 유행하는 현상으로 부캐가 있다. 누구나 부캐가 있지만, ‘놀면뭐하니’ TV 예능 프로그램을 통해 유행으로 가시화됐다. 더 이전에 게임에서는 부캐는 거의 당연시되고 있다. ‘나’이지만, 여러 가지의 다른 ‘나’로 존재하는 것이다. 마치 ‘나'를 다른 ‘나’라 복제하는 것과 같다. 모든 기본은 ‘나’이지만, 상황에 따라 기본인 ‘나’에서 상황이 더해져 새로운 ‘나’가 생겨난다. 복제된 ‘나’는 결국 ‘나’이다. 직장에서의 ‘나’, 동호회에서의 ‘나’, 학교에서의 ‘나’, 집에서의 ‘나’ 등 부캐인 ‘나’가 여러 명 있지만 결국 ‘나'라는 그룹으로 묶이고 파생된 ‘나’들이다.
이런 같은 종류와 성향으로 묶인 것을 영문으로는 클래스‘Class’라고 부른다. 클래스는 흔히 수업 또는 교실의 뜻을 가지고 있다. 수업이나 교실은 하나의 공통된 것을 배우는 곳이다. 특정 취미를 배우는 곳도 클래스라는 이름을 사용한다. 대표적으로 원데이 클래스가 있다.
개인적인 ‘나’와 여러 상황에 따라 만들어진 부캐인 ‘나’는 결국 ‘나’라는 클래스로 부를 수 있다. ‘나’라는 클래스는 기본인 ‘나’라는 속성이나 성향에서 상황에 따라 여러 부캐인 ‘나’로 일시적으로 만들어진다. 이런 일시적으로 만들어지는 부캐를 개발 용어로는 ‘개체화(instance)’라고 한다. 개체화라는 말이 ‘개채로 만들다'라는 의미이기 때문에 ‘나’라는 기본에서 부캐가 만들어지는 것이다.
앞서 예로 들었던 식당의 직원도 부캐이다. ‘나’라는 개인적인 사람이 있지만, 직장에 가면 공적인 ‘직원’으로 복제되어 개체로 만들어진다.
너무 멀리 온 것 같은 느낌이지만, 다시 돌아가서 직원과 직원과의 업무 연결은 개체와 개체의 연결을 의미한다. 개체는 클래스라는 기본에서 만들어지기 때문에 개체보다는 클래스 단위로 부른다. 따라서, 개체와 개체의 연결은 클래스와 클래스 간의 연결을 의미한다. 이런 클래스 간 연결을 도표와 시킨 것을 클래스 다이어그램(class diagram)이라고 한다.
클래스에는 클래스의 속성(‘직원’ 부캐 속성)이 있고, 다른 클래스(다른 ‘직원’ 부캐)와 어떻게 연결되고, 뭐가 전달되는지 도표로 명시화 되어 있다. 이 문서가 있으면 개발 시에 어떻게 값들이 전달되는지 한눈에 볼 수 있다.
지금까지 설명한 유스케이스, 시퀀스 다이어그램, 클래스 다이어그램 이런 도표들을 개발에서는 통합 모델링 언어(Unified Modeling Language) - UML이라고 부른다.
이제 주방을 보자. 주문이 들어오면 주방 직원은 주문 음식에 맞는 재료를 찾고, 레시피에 맞추어 요리한다. 재료들은 알기 쉬운 곳에 있어야 찾는데 어려움이 없다. 재료를 찾기 위해 온 주방을 다 뒤져야 한다면 음식도 늦어질뿐더러 주방 직원들의 동선에 혼란만 가중된다. 또한 상온에서 보관해야 하는 것도 있고, 냉장에서, 냉동에서 보관해야 하는 것도 있다. 이런 보관을 무시하면 재료가 금방 상하거나 맛이 날아간 재료로 요리를 할 수도 있다.
이런 재료를 보관하는 창고를 DB(DataBase)라고 생각하자. - 데이터 베이스는 단어 그대로 데이터를 보관하는 창고이다. - 소스는 재료들을 모아서 만든 또 다른 재료다. 우려서 만든 국물도 또 다른 재료에 해당한다. 재배해서 만든 재료를 원시 재료라고 부른다면 원시를 재료를 이용하여 만든 재료는 응용 재료라고 부를 수 있다. 원시 재료를 볶든지, 뭉개든지, 잘게 자르던지, 가루로 만든 재료도 있다. 원시 재료에서 여러 가지 재료가 나올 수 있다. 이런 재료들은 모두 원시 재료와 연관이 있고, 원시 재료가 없다면 만들 수도 없는 것들이다. 당연하지만 요리는 이렇게 만든 재료들로 만드는 것이다.
재료들 간에는 연결고리가 있고, 특유의 특성이 있다. 특히나 소스는 재료들이 연결된 집합체이다. 조금 비약적이지만, 이런 재료들의 연결고리를 개발에서는 ERD(Entity Relationship Diagram) 개체 관계 도표(모델)라고 부른다.
앞서 개체에 대해서 설명했을 때는 ‘Class’라는 개념을 사용하였다. 근데 여기에서는 ‘Entity’라는 개념으로 사용한다.
Class는 추상적인 개념이고, Entity는 실재적인 개념이다.
조금 어렵게 느껴질 수도 있지만, ‘Class’는 공통된 속성들의 그룹이라고 설명했다. 이것을 개체화시키기 전까지는 개념만 존재할 뿐 실제적인 것이 없다는 의미이다. 반면 ‘Entity’는 공통된 개념이 아닌 독립적인 개체이다. DB는 자체적으로 어디서 파생된 것이 아닌 독립적으로 실제로 존재하는 것이다. 더 설명하면 더 미궁에 빠지기 때문에 이 정도로 마무리하겠다.
ERD는 재료들이 서로 연결된 구조를 나타낸다. 클래스 다이어그램은 무엇인가를 하는 기능이 있는 반면 ERD는 기능보다는 재료 간의 연결 구조를 나타낸다. 연결구조 도표가 있으면 음식을 만들 때 재료들을 빠르게 찾을 수 있다. ERD 도표가 없으면 DB들을 일일이 찾아다녀야 한다.
마지막으로 식당을 운영하는 매뉴얼이 있어야 한다. 신입 직원이 들어오게 되면 바로 투입되는 경우도 있지만, 실수를 줄이기 위해 매뉴얼을 주고 숙지하고 나서 간단한 것부터 투입하는 게 좋다. 개발에서는 이런 매뉴얼과 비슷하게 순서도(Flow Chart)가 있다. 말 그대로 고객의 요청이 들어온 순간부터 어떤 시스템으로 흘러가는지를 도표로 만들어 놓은 것이다.
순서도가 있으면 전체적인 흐름이 파악되고,
중간중간에 오류가 나올 수 있는 부분을 미리 파악할 수가 있다.
이번 회는 다른 회보다는 조금 많은 부분을 다루었다. 통합 모델링 언어(UML)들인, 고객, 직원, 주방의 역할을 명세한 유스케이스(useCase), 시간대별로 흐름을 정의한 시퀀스 다이어그램(Sequence Diagram), 개체와 개체 간 관계를 도표로 만들어 놓은 클래스 다이어그램(Class Diagram), 재료들의 연결구조를 나타낸 개채 관계 모델(Entity-Relationship Diagram), 매뉴얼에 해당하는 순서도(Flow Chart)를 다루었다. 모두가 개발 시작 전 설계에 해당한다. 개발 설계는 어떻게 하는지 의문이 들었다면, 위의 모델링 방법을 설계하는 것이라고 생각하면 된다.
뭔가 많은 것을 해야 하는 것처럼 보이지만, 설계가 잘되면 개발은 한결 수월해진다.
Background Photo by chuttersnap on Unsplash
'웹서비스' 카테고리의 다른 글
| 소통은 무엇보다도 중요하다. (0) | 2020.10.10 |
|---|---|
| 엑셀이 데이터베이스다. (0) | 2020.09.24 |
| 로그와 버그 (0) | 2020.08.26 |
| 프로그램 건축 (0) | 2020.08.26 |
| 프로젝트 개발 관리 (0) | 2020.08.05 |