DB 프로젝트

DB 설계 팀 프로젝트

인생 첫 프로젝트가 시작되었습니다.

살면서 해본 팀플은 옛날 동화 ‘장님과 코끼리’의 내용처럼 팀원들끼리의 소통이 부족해서 코끼리가 아닌 어떤 것을 만들었는데.. 이번에는 다를 거라는 마음을 가지고 팀플을 시작하게 되었습니다.

 

각 조원들이 아이디어를 한 개 생각해 와서 서로 공유해 보기로 하였습니다.

아이디어 말 할 때 특 뭔가 민망함. 하지만 그것은 별로 안 좋은 습관이라고 생각합니다.

‘일단 말해라 그리고 실행해라’ 미국의 실리콘 밸리 회사 사장님이 말한 느낌으로 말해 봤습니다. 아무튼 각자 아이디어를 가지고 심도 있는(약 3분 21초) 회의를 통해 하나의 주제를 선정하였습니다. 주제 자체가 크게 프로젝트에 영향을 미치지 않기도 했고, 각 팀원들이 해당 주제(다양한 OTT들에 대한 하나의 검색 서비스)의 서비스에 대해 경험이 있어서 선택하게 된 것 같습니다.

역할 분배

제가 대학생때 경험한 팀.. 아니 ‘장님들과 코끼리’ 활동에서는 역할분배가 거의 뭐랄까 붕괴 직전 사회주의 같은 분배를 통해서 했던 것으로 기억합니다. 사실상 발표하는 사람이 자신에게 다가올 끔찍한 미래를 위해 모든 걸 준비하는 느낌이었지만… 이번에는 좀 달랐습니다.

 

우선 팀장님이 구체화된 업무를 할당해 줬습니다. 확실히 내가 맡은 업무가 구체화될수록 책임감이 생기는 것 같았습니다. 팀장님에게 이 자리를 빌려 감사의 말씀을 전하고 싶습니다. 물론 제 바로 앞자리에 계시긴 하지만 그냥 직접 전해드리는 게 좋겠죠?

협업 과정

살면서 아이스 브래킹을 증오하던 제가 아이스 브래이킹의 중요성을 느꼈습니다.

업무를 쪼개서 하다 보니 서로의 업무의 부분이 겹치는 부분이 많았고 이에 대해서 의견을 소통했으면 훨씬 더 좋았을 것 같다는 생각을 했습니다. 예를 들어 데이터를 삽입하는 과정에서 영화에 대한 다양한 값을 나눠서 넣어줬는데, 서로 어떤 데이터를 넣고 있는지에 대한 정보 공유가 부족해서 시간을 많이 소요하게 되었다고 생각합니다.

다행히도 프로젝트가 진행되면서 자연스럽게 편해져서 후반부에는 어떤 이슈나 의견을 편하게 말하고 생각을 공유할 수 있었습니다.

 

멋진 팀장님을 만나 준비기간을 다른 조와 다르게 좀 여유 있게 시작하게 되었는데, 여유가 있다 보니 MVP 느낌으로 나온 작업물에서 또 다른 서비스나 발전 방향을 생각할 수 있어서 좋았습니다. 뭔가를 항상 쫓기듯 해온 저로서는 참으로 흥미로운 경험이었습니다. 

 

협업 방식

• 있어 보이는 협업 방식들
  • jira를 통한 프로젝트 관리
    • 티켓을 끊고, 작업을 수행하고, 일 많이 한 척도 하고, 뭔가 대단한 일을 해내는 기분이 들어서 좋았습니다.(생색내기도 좋음 ㅎ) 
    •  

      

     
  • git을 통한 공통 레포 작업
    • 모르는 것 같았던 git을 실제로 사용해 보며 내가 진짜 모르는구나 를 생각했습니다. 
    • 한 번은 ‘회의록 작성’과 ‘DDL 쿼리 작성’ 작업을 동시에 하게 되어서 회의록에 대한 커밋을 DDL 쿼리 작성을 진행하던 브런치와 동일한 브런치에서 날렸습니다. 회의록의 특성상 하루를 보내고 저녁에 바로 공유하기 위해서 pr을 요청하려는데, 작성 중인 DDL 카레문 커밋과 섞여서 아직 pr요청을 하고 싶지 않은 부분까지 pr 범위에 들어가게 되었습니다. 물론 프로젝트 진행에 있어서 큰 영향을 주는 부분은 아니지만, 그때 한창 git을 배우고 있어서 이를 나눠서 보내보기로 마음먹었습니다. 그래서 고민하던 부분을 팀원들에게 공유를 하자마자 팀장님이 챗 지피티가 머쓱할 정도로 이슈를 해결해 주셨습니다.
  • slack을 통한 소통
    • 카톡과 뭐가 다르냐고 질문하면 당당하게 '다양한 이모지를 찍는 재미'라고 말하고 싶습니다. 일과 생활의 구분이 필요하죠. 그게 슬랙의 큰 역할이라고 생각합니다. 
  • 구글 드라이브를 통한 공통 문서 작업

결과물

https://github.com/Hi-Imjaeyoung/data_modeling_1team

GitHub - Hi-Imjaeyoung/data_modeling_1team: 한화 SW 캠프 3기 DATA Modeling 1조 repo 입니다.

 

느낀 점

DB archetacture에 대해서 좀 주도적으로 깊게 고민하지 못했던 않았던 부분이 좀 아쉽긴 합니다. 그래도 한 서비스에 정말 많은 정보가 필요하고 이를 효율적이게 관리하는 것은 참 쉽지 않겠구나라는 걸 몸으로 느껴볼 수 있었습니다.

 

팀장의 역할에 대해 생각을 해보게 되었습니다. 돌아가며 회의록을 작성하며 각 팀원들에게 팀프로젝트의 온보딩과 같은 경험을 하게 해 주신 부분과 모든 팀원의 의견을 십분 반영하여 모든 안건에 대해 고민하고 결정해 주시는 부분을 가장 좋았고 배우고 싶은 부분이었습니다.   

 

다른 팀들에 대해 배울 점

 

2조 : 학원 시스템 기반 DB 설계

영광님의 당당한 발표가 인상 깊었다. 멋진 사람

• 복합키를 PK로 설정해 보고, 추후 수정을 하였는데 그 고민의 과정을 보여줘서 좋았다. 'PK를 꼭 인공키로 가져가하나'에 대한 고민을 나도 한 적이 있는데, 이를 해결해 줘서 땡큐 쏘마치였다.
• view를 사용(권한을 분리) 이 부분도 너무 유익했다. 이런 식으로 '자주 조회 될 것 같은 정보의 권한에 따른 제한적인 접근'이라는 상황을 보여줬는데  흥미로웠다. 

3조 : 게임(크레이지 아케이드) 서비스에 대한 DB 설계

엄청난 고민의 시간이 느껴지는 DB 설계.

• ERD에 각 객체 간의 관계를 표현하는 거는 너무 좋아 보인다 내 스타일... 논리적 모델링하며 그리다 보면 뇌 정지가 자꾸 와서 생각하면 계속 달라지던데.
• 데이터의 분류를 사전 데이터와 이벤트 데이터 즉 서비스가 실행되기 전 데이터와 실행된 후 생기는 데이터를 분류 한 부분에서 '아 3조.. 좀 다르다' 생각했다 DB에 대해 정말 정말 깊게 생각을 해본 조같다. 
• 데이터 간의 위계 캬.. 정말 크레이지아케이드 물풍선을 놓아보고 DB 설계를 하셨구나.. 사실 그냥 그건 애플리케이션 단에서 해결하죠라고 넘어갈 수 있는 부분일 텐데 반성하게 되었습니다.
• CEO님이 발표를 매끄럽게 잘하신다. 

4조 : B마트 서비스 DB 구축

발표 자료 디자인이  README인데도 굉장히 깔쌈. 발표도 잘하드라구 정민쓰

• 아 공부하고 싶은데.. 모델링 사진이 화질구지라.. 이거 어쩌나.
• oder table을 crew를 통해 store와 연결시켜 준 이유가 궁금해졌다. 아 질문할걸..
• 서비스 시스템에 대한 분류에 따른 아이디어의 흐름을 보여줘서 좋았다.

 

5조: 아파트 커뮤니티 서비스 기획

DB 설계는.. 참 어렵다.

• 게시글의 타입마다 독립적인 테이블을 가져서 확장성을 가지게 설계. DB는 참.. 어렵다. 효율성만을 생각하는 것도 좋은 DB설계라고 할 수 있을까..
• 대댓글을 생각하여 DB생성. 대댓글을 이라는 데이터를 댓글이라는 테이블에 하나의 속성을 통해 넣어서 같이 관리하는 부분이 좋다.
• 같은 데이터 타입의 테이블인 경우 굳이 기능별로 분리를 해야 할까?
• 사실.. 내 생각을 쪼금 해보자면 메시지 테이블을 하나로 둬서 관리하는 건 어떨까.. 요

6조 : 음악 스트리밍 서비스

• 대댓글 역시 외래키를 자기 자신한테 걸어서 확
• null이 가능한 외래키를 다중으로 사용하여 DB를 관리하는 것에 대해, 저희 DB 프로젝트에서 구현한 부분과 살짝 달라서 고민해 보았다. 데이터가 단일 값이면 요렇게 하는 것이 더 깔끔할 것 같다. 우리 팀 같은 경우에는 장르나 배우가 다중의 데이터가 필요한 경우가 있어서 쪼개는 것이 더 괜찮아 보인다. 
• 그룹아이디를 넣어서 저장한다면.. PK를 서로 다른 상태로 구분 짓는다면..이라고 내가 적긴 했는데.. 뭔 소리니 재영아