유저 피드백을 받아야 할 때 사용자들이 이용할 데이터를 어느 것을 넣을지 생각해야 할 것 같습니다.
실전 프로젝트 중간발표
8/14 (토) 13:00 ~ 19:30 : 실전 프로젝트 중간발표가 진행되었습니다.
총 15팀이 중간발표를 진행하였습니다.
React, Node.js, 풀 스택 총 3분의 튜터님이 참가하였습니다.
저희 팀은 15:40 ~ 16:00까지 발표를 진행하였습니다.
발표를 진행하기 10분 전까지 배포 오류로 인한 React 디버깅을 진행하였습니다.
MVP 소개 > 아키텍처 소개 > 트러블 슈팅 순으로 발표를 진행하였습니다.
프론트 엔드 2개, 백 엔드 6개의 피드백을 받았습니다.
실전 프로젝트 중간발표 이야기
다른 팀의 발표를 들으면서 아키텍처 부분을 가장 유심하게 보았습니다. 많은 팀이 안정적인 서버 관리를 위해 CI/CD를 구현하였고, 아키텍처를 탄탄하게 구현하였던 것을 느낄 수 있었습니다. 이번 주 백 엔드 목표에 CI/CD 구현이 있었지만, MVP 기능 추가를 위해 우선순위를 뒤로 미루었고, 중간발표에서는 해당 기능을 제외한 채 발표하였습니다. 개개인의 퍼포먼스를 뽐내는 개인 프로젝트가 아닌 팀 프로젝트이므로 어쩔 수 없었던 것 같습니다.
발표 진행 10분 전까지 React 디버깅을 진행하였습니다. 테스트하던 이전 버전에서는 발생하지 않았던 오류들이 Git Pull과 함께 반갑게 인사를 건넸습니다. 갑작스럽게 발생한 오류로 인해 발표를 진행하기 전까지 디버깅을 진행하였고, 모든 오류를 해결하지는 못하였습니다. 즉흥적으로 수정하기에는 많은 어려움이 있어 사이드 부분에서 발생하는 오류는 제외하고 프로젝트의 핵심적인 기능만 발표를 진행하였습니다. 다행히 발표할 때 버튼이 클릭 되지 않는 오류를 제외하면 다른 오류가 발생하지 않았고, 순조롭게? 들키지 않고 발표를 이어나갈 수 있었습니다.
프로젝트의 핵심기능, 아키텍처, 프로젝트를 진행하면서 어려웠던 점을 발표하였고, 백 엔드에게 6가지의 질문을 하였습니다.
테스트 코드에 대해서 자부하는데 왜 자부하는지?
테스트 코드가 4,000줄 이상인데 오버 엔지니어링이 아닌지?
GeoRedis는 어떻게 알고 사용하였나?
각 부하에 대한 평가 지표를 확실히 잡고 있는가?
클라이언트에서 부하가 발생할 경우, 원인을 어떻게 찾을 건지, 내구성의 문제는 어떻게 해결할 것인가?
실제 배포하면서 겪는 문제는 어떤 것들이 있는가?
프로젝트의 핵심 기능인 Kakao Map API를 이용한 GPS 실시간 Socket 통신, Socket 대화방 기능, 방대한 테스트 코드를 위주로 발표를 진행하였습니다. 테스트 코드는 백 엔드 팀원 2명이 3일가량 작성하였습니다. Router와 Joi Schema 별로 테스트 코드를 분리하여 모든 경우의 수를 커버하도록 구현하였기 때문에 자신감 넘치게 발표를 진행할 수 있었습니다. 하지만 튜터님들의 피드백은 오버 엔지니어링이 아니냐는 안타까운 지적만을 받았습니다. 프로젝트 발표 시간이 5분밖에 되어있지 않다 보니 세세한 부분에 관해 설명하지 못해 아쉬움이 남았습니다.
중간발표 피드백 중 전반적인 내용은 부하 테스트에 대한 이야기였습니다. 실시간 통신이라는 개념은 DB, Server, Client 어느 부분에서 부하가 발생하는지 확실하게 알지 못할 경우 수정 및 개선이 힘들고, 프로젝트가 목표로 하는 사용자의 지표를 확실하게 잡아놓아야 실제 서비스를 진행할 때 많은 어려움이 존재하지 않을 것이라 이야기하였습니다.
실전 프로젝트 4주 차 이야기
crontab을 이용해 EC2 Linux 서버에서 자동 백업 및 갱신 기능을 구현하였습니다. 갑작스럽게 MySQL 서버가 죽어버려 데이터가 사라지는 것을 대비하거나, HTTPS 인증서를 3개월 단위로 일일이 갱신하는 것이 불편하다고 느꼈습니다.
백업되고 있는 MySQL Dump 파일과 Crontab 설정
MySQL에서 Geometry POINT 형식을 사용하였습니다. int, string, date와 같이 일반적인 변수를 사용하는 것이 아닌 공간 데이터 전용으로 사용하기 위한 데이터 타입이었습니다. Geometry의 가장 우월하다고 느끼는 특성은 GPS의 좌표만으로 해당하는 거리를 출력하거나, 구분할 수 있는 것이었습니다. 실전 프로젝트에서 자신의 위치를 기반으로 모임 또는 사용자의 위치를 출력 시켜 줄 때 유용하게 사용할 수 있을 것 같습니다.
MySQL Geometry POINT 데이터 타입
Socket 전용 Middleware를 구현하였습니다. 기존의 Router에서는 jwt 토큰으로 사용자 인증을 하기 위해 동일한 코드를 작성할 필요 없이 middleware를 작성해 이벤트를 수행하였습니다. 하지만 Socket에서는 Express와는 다르게 request, response의 입력 형식으로 구성되어있지 않았고, 별도의 Socket 전용 middleware를 구현하여 사용자 인증을 진행할 수 있었습니다.
Socket에서 모임 핀 기능을 구현하였습니다. 모든 사용자의 위치를 출력하는 단순한 Socket.emit 이벤트와 다르게 모임 생성, 삭제 API가 실행하였을 때 각 모임의 Latitude, Longitude 정보를 Socket으로 접속한 모든 유저에게 전송하도록 구현하였습니다.
Kakao Map API의 사용자 및 모임의 위치 표시
React.js 에서 Socket 이벤트를 디버깅하였습니다. React.js를 사용해본 적 없지만, Socket API가 언제, 어느 데이터를 전송하는지 이해하고 있었고, 해당하는 데이터를 어떤 방식으로 가공해 Kakao Map API 출력해야 하는지 논리 구조를 이해하고 있었기 때문에 디버깅에 도움을 줄 수 있었습니다.
React.js에서 Marker 생성 논리 구조를 작성하였습니다. 기존에 구성되어 있던 Kakao Map API에서는 Marker를 Object 형식으로 관리하지 않고, Array로 관리하고 있었습니다. 모든 마커의 핵심은 userId와 postId를 한번 에 찾을 수 있어야 하지만 Array 형식으로 구성되었을 경우 모든 Array를 분해한 이후 userId와 postId를 검색해야 하는 불필요한 상황이 발생하였습니다. Marker를 생성하는 Socket 이벤트와 Axios가 수신하는 API 코드를 수정해 Marker를 생성하는 방법을 수정하였고, Socket 생성 및 삭제가 정상적으로 이루어지도록 구현하였습니다.
EC2에서 NIGNX를 이용해 React.js 서버를 구현하였습니다. AWS S3에서 Build 된 React.js 파일이 정상적으로 실행되지 않아 오류가 발생하였습니다. 해결방법으로 가장 먼저 떠오른 것이 EC2에서 NGINX를 이용해 배포하는 것이었고, 생각과 동시에 바로 구현을 시작하였습니다. apt-get을 이용해 NGINX를 다운받아 내부 설정 파일에서 Build 된 파일의 위치를 수정한 후 NGINX를 재실행하였고, 어려움 없이 성공적인 배포를 하였습니다. 하지만 AWS S3에서 발생한 오류가 동일하게 나타났고, 다른 해결방법을 찾아야 할 것 같습니다.
EC2에서 작성한 NGINX설정
Testcode, Swagger 작성이 종료되었습니다. 현재까지 작성된 모든 Express의 API를 Jest, Supertest 모듈을 이용해 테스트 코드 작성이 종료되었습니다. 단순히 Joi Schema를 테스트하기 위해 작성한 테스트 코드가 4,000줄 가까이 작성이 되었고, Router 별로 작성된 테스트 코드도 일반적인 개수를 뛰어넘는 것 같습니다. 하지만 안타까운 점은 Sequelize.Seed를 사용하지 않아, 서비스 중인 MySQL 서버를 기준으로 테스트한다는 것이 단점이었고, 테스트 전용 DB와 임시 데이터를 자동으로 생성해주도록 Testcode를 구현하도록 수정해야 할 것 같습니다.
Kakao Map API의 Marker 부하 테스트를 진행하였습니다. 기존에는 5개~10개 Marker의 통신 속도에 대해서 테스트를 하였지만, 클라이언트의 입장에서 어느 정도까지 버틸 수 있는지 확실한 데이터가 필요하였고, Server에서 임시 데이터를 자동으로 갱신하도록 설정하여 Marker를 표시해줄 때의 상황을 시뮬레이션하였습니다.
Kakao Map API 부하 테스트 및 테스트 결과표
MVP 구현 목록
HTTPS 구현 [21.8.4]
crontab 인증서 정기 갱신 [21.8.4]
패스워드 암호화 저장 [21.8.4]
aws 키 공유 [21.8.4]
morgan 서버 로깅작업 실행 [21.8.6]
상황에맞는 HTTP 코드 작성 [21.8.10]
jest supertest 테스트코드 작성 [21.8.11]
Swagger 모든 API 구현 [21.8.11]
Location Socket 초대하기 서비스 구현 [21.8.11]
SQL Injection 방지법 정의 ☆ [21.8.12]
Sequelize Raw Query 에서 ', ", ` 사용 불가능하게 설정
모든 Raw Query 에서 따옴표로 String 방지
배운 점
발표 준비 방법
Socket Middleware, 중복 로그인 차단 논리 구조
Linux crontab
MySQL, Redis Geometry 데이터 타입
모임 초대하기 논리 구조
React.js API 통신 및 Socket 통신
SQL Injection 방지 시큐어 코딩
NGINX
나의 생각과 이야기
React.js는 통신 순서를 작성하기 힘든 것 같습니다. Android는 Life Cycle을 기준으로 통신 순서를 작성할 수 있지만, Reac.js에서는 이러한 분기를 개인이 작성해야 한다는 것에서 불편함을 느낀 것 같습니다.
새로운 기술을 접목하고 싶다는 욕심이 더 강해진 것 같습니다. 중간발표를 보면서 저희 팀에도 접목하면 좋은 기술들이 많이 눈에 들어왔습니다. CI/CD는 기본이고, DB를 클라우드 환경에서 관리하는 것과 보안을 확실하게 하려는 아키텍처 작성이 마음에 들었습니다. 남은 API를 모두 해결하는 데 많은 시간이 걸리겠지만, 현재까지 주어진 업무가 마무리된다면, 프로젝트의 기술 스택을 성장시키기 위해 다양한 기술을 접목하면 좋을 것 같습니다.
드디어 중간발표가 종료되었습니다. 프로젝트를 시작한 지 3주라는 시간이 흘렀습니다. 도중에 프로젝트의 방향성을 잡지 못해 답답함을 느꼈었고, 성공적인 완성이 되지 않을 것이라는 불안감과 사용하는 기술 스택이 부족한 것이 아닌지에 대한 압박감 등 많은 걱정이 있었지만, MVP 작성과 중간발표를 성공적으로 진행했다는 깊은 만족감을 느꼈습니다. 아직 많은 오류가 남아있지만, 아무것도 모르던 첫 시작부터 현재까지 3주간 진행해왔던 이력들을 토대로 어떤 어려움도 헤쳐나갈 수 있다는 자신감을 가질 수 있었고, 남은 3주간의 프로젝트 진행 기간도 잘 헤쳐나갈 수 있을 것 같습니다.
다음 주는 본격적으로 Geometry에 대해 세부적인 기술을 배울 것 같습니다. 현재는 위치를 가공하지 않고 단순히 Pub/Sub만을 사용하지만, 접속한 사용자의 위치를 기준으로 지정된 거리 내부에 존재하는 사용자, 모임만을 출력시킬 수 있도록 코드를 작성해야 하므로 간단히 문제가 해결될 것 같지 않습니다. 그리고 위치를 연산하면서 발생하는 서버 부하를 어떤 방식으로 줄이거나, 해결할 수 있는지 구상해야 할 것 같습니다.
