파이널 프로젝트 4일차
점심시간을 활용하여 cloudcraft를 이용하여 사용한 기술스택을 나타내는걸 좀 더 깔끔하게 배치해보았다. 하다보니까 막 마을컨셉으로 꾸미고 싶고...박스로 둘러싸고 마을을 만들고 빌딩 올리고 싶은 충동이 자꾸 들어서 꾹꾹 참았다. 오늘 우리팀이 작업하며 나눈 대화에서 따로 짚고 넘어가야할 부분을 위주로 적어보려한다.
오전에는 IA를 작성해보려고 했는데 IA가 순서도와 어떤 차이가 있는지 헷갈렸다. IA를 작성하려고 하면 왠지 순서도를 그리는것 같고 순서도에서의 조건을 빼고 구조만 적자니 뭔가 빠진것 같고 흐름을 어떻게 표현해야할지도 애매했다. 우리는 IA와 순서도의 차이를 검색해보았고 결론은 순서도만 작성하기로 결정하되 알아보기 쉽게 간단하게 작성하기로 했다. 우리는 어떤 흐름인지 알고 있고 남에게 보여주기 위한 용도라면 너무 디테일해서 복잡하게 나타내는것보다 간단하게 표현하여 눈에 잘 들어오게 하기 위함이다.
IA와 플로우차트, 순서도의 차이
IA랑 플로우차트랑 순서도의 차이는 뭘까?? 생각했는데 순서도가 영어로 flowchart였다. 민망하지만 개발자가 되려면 영어공부도 필요할것 같다는 생각이 들기때문에 적어본다.
순서도: 순서도는 화면, 기능 단위로 사용 동선을 설계하는 것이다. 도식화되어 작성자가 아니여도 읽어보면 쉽게 파악할 수 있을만큼 자세하다.
IA: 메뉴를 분류하여 Depth 구조로 설계한 것이다. 프로젝트 일정, 파트별 진행 여부를 동시에 관리할 수 있지만 설명이 제한적이다. (메인페이지에서 로그인으로 이동 / 소개페이지에서도 로그인으로 이동이 가능하다고 했을 때 표현할 수 없다.)
IA를 작성한 이후에 추가적으로 기획을 보충했다. 누락된 기획부분은 바로 채팅인데, 채팅은 기획을 미뤄두기로 했다. soket.io를 사용하여 채팅을 구현하기로는 했지만 어떻게 어디까지 구현이 가능한지 soket.io를 사용해본뒤 기획을 할 수 있을것이라는 결론이 나왔기 때문이다. soket.io는 무엇인지, 어떻게 쓰는지 일정을 마친뒤 좀 알아보기로 했다.
soket.io
웹소켓은 양방향 소통을 위한 프로토콜이다. 프로토콜은 쉽게 말하자면 서로 다른 컴퓨터끼리 소통하기 위한 약속 정도로 이해하면된다. socket.io는 양방향 통신을 하기위해 웹소켓 기술을 활용하는 라이브러리다. socket.io는 웹소켓을 이용해 클라이언트에 실시간으로 데이터를 전송한다. 채팅과 메세지, 실시간 분석, 문서 공동작업 등에 주로 활용된다.
점심을 먹고난뒤 우리는 gitbook을 활용하여 서버에서 클라이언트로 요청을 어떻게 보낼지에 대해 이야기하며 작성을 했다. 첫프로젝트때는 프론트적인것은 프론트를 맡은 팀원끼리, 백엔드부분은 백엔드를 맡은 팀원끼리 만나 작성을하고 알려주는 방식으로 소통했다면 이번에는 다함께 이야기하면서 작성을 했다. 어짜피 소통해야할 부분인데 처음부터 함께 작성하면 소통이 더 원할할 수 있을 것 같았다.
소통중 모르거나 헷갈리는 용어를 따로 메모에 두었다가 검색해보았다.
endpoint는 무엇인가?
API란 두 시스템, 어플리케이션이 소통 할 수 있게 하는 프로토콜의 총 집합이라면 endpoint란 API가 서버에서 리소스에 접근할 수 있도록 가능하게 하는 URL이다. 한마디로 Endpoint란 API가 서버에서 resource에 접근할 수 있도록 하는 URL이다.
500에러, 400에러는 어떤 에러지?
500에러 응답 코드는 요청을 처리하는 과정에서 서버가 예상하지 못한 상황에 놓였다는 것을 나타낸다. 이 에러 응답은 서버에러를 총칭하는 구체적이지 않은 응답이다. 서버의 동작에서 발생하는 에러 중 더 정확한 에러 코드가 아닌 경우를 나타낸다.
400에러 응답 코드는 클라이언트에서 서버로 보낸 요청이 잘못되었거나 손상되어 서버가 이를 이해하지 못했음을 의미한다.
시퀄라이즈란?
시퀄 라이즈 는 DB 작업을 쉽게 할 수 있도록 도와주는 ORM 라이브러리다. ORM이란 무엇일까? Object-Relational Mapping의 약자이다. 즉, ORM은 자바스크립트 객체와 관계형 데이터베이스를 서로 연결해주는 도구이다.
특별한 이슈사항이 있다면 기획이 거의 완성되어가고 있는 시점에 전 기수분들중 두팀이 우리와 같은 주제의 프로젝트로 했다는 것을 알게 되었다. 심지어 한팀은 프로젝트명까지 동일하다. 프로젝트 주제는 같았지만, 기획은 다르기 때문에 계속 진행하되 우리는 훨씬 완성도 있게 하기로 결심했다.
배달나눔방을 개설한 개설자가 음식을 직접 배달해주는것에 대해 선택 사항이 있었다. 개설자가 배달로 치킨을 받고 그 치킨을 신청자에게 다시 재 배달을 해주는것이다. 예를 들어 지코바치킨을 주문할것이고 배달료가 4000원일때 개설자를 통해 배달을 신청한 사람은 배달비의 반인 2000원만 지불한다는 점이 특징이다. 또 개설자는 인원이 3명이 모였을경우 각각 모두에게 2000원을 받으므로 자신은 배달료를 내지 않고도 2000원이라는 이득까지 보는셈이다. 만일 개설자가 포장을 해와서 배달료가 없을경우에도 신청자들에게 각각 배달료의 반을 받을 수 가 있다.
이 사항에대해 부분만 직접배달을 신청할 경우 어떻게 할 것인지와 직접 배달 신청자들이 3명일때 개설자는 3군데를 방문해야하는데 3번째로 방문하게 되는 곳은 불만이 있을 수 있다는 의견도 있는등 복잡한 부분이 많아서 없애기로 결정을 했다. 사실 이부분은 내가 낸 아이디어이기도 하고 같은 주제로 하는 팀의 프로젝트와 차별성이 있다고 생각해서 잘 살려내고 싶은 마음도 있었지만, 이 부분을 잘 살려내면 또 '직접배달'이라는 것이 이 프로젝트에서 포인트가 될것이고 기획에서 많은 부분이 수정되어야할 것같아서 놓아주었다. 다른 사항도 생각해야할 게 많았다.
우리는 마감시간도 삭제 했다. 모집인원마감을 모집인원이 다 차면 자동으로 마감이 될것인지, 생성자가 마감버튼을 눌렀을때 마감이 될것인지에대해서도 회의를 했다. 마감시간을 둘 경우 모집인원이 다 찼음에도 계속 신청하게 된다는 점을 고려하여 마감시간을 삭제 하고 생성자가 마감버튼을 눌렀을때 마감이 되는것으로 했다. 잠깐.. 그러고 보니 그러면 생성자가 마감버튼을 누르지 않으면 그것또한 계속 모집중이므로 문제가 있을것 같다. 내일 다시 팀원들과 의논해봐야겠다.
느낀점
서버에 요청이 많을 수록 서버에 무리가 많이 가며 서버에 돈도 많이 든다는것을 알게되었다. 우리팀은 회원가입에서 중복검사를 할때 실시간요청 아이디중복검사를 하기로 한것을 변경하여 아이디를 입력후 마우스커서가 벗어났을때 요청을 보내고 중복검사를 하기로 했다. 프로젝트를 하면서 새롭게 알게되는것이 많고 알게 될때마다 흥미롭다. 한편으로는 섹션1,2,3때 이 흥미를 느꼈다면 제대로 공부할 수 있었을텐데 하는 아쉬움도있다.
마감시간을 설정해주고 마감시간이 되면 자동 마감처리되는것으로 기획했다가, 마감시간을 둘 경우에는 모집인원이 다 찼음에도 계속 신청하게 된다는 점을 고려하여 마감시간을 삭제 했다. 생성자가 마감버튼을 눌렀을때 마감이 되는것으로 바꿨는데 생각해보니 그러면 생성자가 마감버튼을 누르지 않으면 그것또한 계속 모집중 상태로 있으므로 문제가 있을것 같다. 내일 다시 팀원들과 의논해봐야겠다.