[Final Project]TeamB_화물 용달 예약/조회 서비스

Day1

오늘 한 것

• 요구 사항 명세 작성

소비자가 예약을 진행할 때, 예약 정보를 RDS에 저장한다.
드라이버가 예약을 인지할 수 있도록 해당 메시지를 알림 서버에 전달한다.
예약 정보를 다루는 서버는 추가 될 트래픽에 대한 확장성이 보장되어야한다.
알림 서버는 추가 될 트래픽에 대한 확장성이 보장되어야한다.
데이터 내구성을 보장하기 위해 RDS는 복제본이 만들어져야 한다.
빠른 예약 정보 검색을 위해 쿼리결과는 ElastiCache를 통해 캐싱이 되어야 한다.
예약 내역이 담긴 메시지 누적은 Elasticsearch를 통해 제공된다.
누적된 로그는 예약 정보를 담는 rds와는 별도의 db에 저장된다.
예약 서비스와 조회 서비스는 별도로 관리되는 서비스이다.

• 요구 사항 명세 바탕으로 엔지니어와 팀미팅
• ElasticCache 에 대한 사전조사
  • https://minholee93.tistory.com/entry/AWS-ElastiCache-Redis-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0
  • https://uchupura.tistory.com/112
• Elasticsearch 에 대한 사전조사
• 아키텍처 초안 작성

화이트보드 회의 결과

대략적인 초안

• DAY2 to do list 1차 작성
• 협업을 위한 기초 다지기
  • 칸반보드 제작 - git project
  • 협업툴 선정 - 노션,(자유 소통 및 회의록) 디스코드 팀 채널(공지사항), git issue(git project와 연동 및 엔지니어의 긴급 소통)
  • git commit 규칙 정하기
    • 파일 추가 ex ) "add: 파일명.확장자"
    • 파일 수정 ex ) "fix: 수정내용, 간단한 오탈자 및 문법수정"
    • 기능 추가 ex ) "feature: 추가한 기능 및 함수"
    • 파일 및 기능 삭제 ex ) "delete: 삭제한 내용"
    • commit, push 모두 자기 브랜치에만 자유롭게
    • commit message 반드시 작성
  • git branch 및 PR 규칙 정하기
    • main 브랜치에 PR 권한은 팀장만, 그 전에 다같이 코드리뷰하기
    • release 브랜치에 PR 요청 시, 디스코드에 공지 후 모두 코드리뷰.
    • release 브랜치 업데이트시 다같이 pull 받기

 

오늘의 삽질

 나는 코스가 끝나가는 마지막 프로젝트에서 도달해서 조차 데브옵스와 백엔드를 구별하지 못하고 있었다.

실제 현업과 비슷하게 프로젝트를 진행하는게 목표라고 듣긴했지만 이렇게까지 시나리오가 불친절 할 줄은 몰랐다. 단순하게 화물용달 예약/ 조회 서비스를 제공한다. 운송정보와 요금을 확인하면 플랫폼을 통해 요청이 드라이버에게 전달된다. 딱 두줄. 이걸로 아무것도 없는 무에서 유를 창조하려고 하다보니 나도 모르게 아직 개발 관점에서 구현 사항을 위주로 dfd와 요구사항 명세, 기술 명세를 작성하고 있었다. 요구사항에 RDS를 쓰라는 것만 보고 ERD까지 신나게 토론에 토론을 거쳐서 짜고 엔지니어님께 질문 할 것과 팀미팅을 준비해서 뿌듯하게 들어갔더니...정작 데브옵스 엔지니어가 해야 할 일들에 대해서(RDS의 레플리카, 안정성, 내구성, 속도를 위한 ElastiCache 같은 것들)는 아무것도 짜지 않은채로 들어가게 된 거다....진짜 직장 선배였으면 욕을 해도 나는 할 말이 없다...실컷 데브옵스 엔지니어로 뽑아놨더니 백엔드짓 하고 있는 어처구니 없는 상황이었을 거다...요구사항 명세부터 틀리게 작성한거다. 실제 데브옵스 엔지니어들이 마주하는 거래처에서의 요구사항들은 정말 구체적이지 않다. 아마 모든 개발직군들이 그렇겠지만 데브옵스 직군도 마찬가지였다. 요구사항에서 내가 해야하는 업무의 바운더리를 정확히 파악하는 것은 굉장히 어려운 일이었다.

 

내일 할 것

• [1]요구사항 작성 보완 후 최종본
• [1]아키텍처 초안 팀미팅
• [1]아키텍처 예제 조사 및 개념증명
• [1]아키텍처 보완본 엔지니어 미팅 - 오후
• [1]아키텍처 완성본 작성 - Day2 마일스톤
• [1]ElasticCache 적용 방법 조사
• [1]Opensearch 적용 방법 조사
• [1]팀 얼라인 및 개인회고

 

느낀점

 하루 종일 회의에 회의를 하는게 나중엔 목이 아프고 진이 다 빠지더라... 차라리 구현하느라 머리 아픈게 나을 것 같다는 생각을 정말 엄청나게 했다. 마지막 프로젝트는 실제 기업에서 주는 과제로 현업에서 처럼 업무 프로세스를 정하고 전달하고 지켜서 롤플레잉을 기반으로 진행할 것이라고 했다. 처음에는 무슨 키자니아인가..했는데 매운맛이다.

 오늘도 주어진 하루 업무시간의 반절 이상을 쏟아부었던 요구사항 명세와 erd가 쓸모없는 짓이었다고 정작 해야할 것들은 못했다는 사실을 마주하게 되니까, 심지어 난 자발적으로 팀장을 하겠다고 했고 팀원들이 믿어줬는데도 이모양이다보니 진짜 자괴감이 엄청나게 들었다. 무엇보다 팀원들한데 너무 미안해서 힘들었다. 팀장이라는 자리에 부담을 제법 느끼고는 있었지만 이렇게 되니까 너무 미안해서..조금이라도 더 움직이려고 하는 중 이다... 이런 무능한 사람을 팀장이라고 믿고 따라가야할 팀원들에게 너무 감사하고, 조금이라도 더 공부해서 나눠 줄 수 있는 사람이 되고싶다.

 업무 프로세스를 정하고 전달하고 이런 자잘한 잡무들도 생각보다 엄청 시간과 노력을 많이 요하더라. 하나하나 일의 진행을 문서화 한다는게 어째 개발보다 더 많은 리소스가 소요되는 느낌도 들고 그랬다. 하지만 제대로된 협업을 위해서라면 커밋 메시지 하나도 정해진 룰대로 태그를 달고 pr같이 많은 변경사항이 있는 부분들에 대해서는 권한과 책임 요소를 명확히 해야한다는 것도 느꼈다. 업무를 정하고 나눠주는 매니징의 역할에 대해서도 많은 고민을 하게되었다.