221209 TIL

오늘 배운 것 & 한 일

항해 5주차 팀 과제 설계

협업에서 ERD를 본격적으로 설계하는 게 처음이라 정말 어려웠다. API 명세는 이전에 했던 경험을 토대로 진행해서 크게 문제는 없었다. 그런데 ERD는 정말 총체적 난국이었다..!

 

특히 게시글과 댓글의 좋아요 기능을 구현할 때 테이블을 어떤식으로 구현해야 할 지 정말 머리가 복잡했다. 그 외에도 PK, FK들의 컬럼명을 어떻게 해줘야 할 지도 결정을 제대로 못 내렸다. 아마 이건 MySQL 공식 문서를 토대로 진행하지 않을까 싶다.

 

그리고 오늘 팀 과제를 하면서 느낀 점이 크게 두 가지가 있다.

 

첫 번째는 다른 팀원을 설득하려면 내가 하려는 모든 것들에 제대로 된 근거를 갖추어야 한다는 거였다.

 

협업으로 프로젝트 설계를 해보니 사소한 부분에서도 서로의 의견이 다를 때가 정말 많았다. 그리고 그럴 때 상대를 설득하려면 제대로 된 근거가 필요하다. 상대를 제대로 납득시킬 만한 근거가 없다면, 그 의견은 묻힐 수 밖에 없다.

 

두 번째는 서로의 관심사가 정말 다르다는 점이었다.

 

나는 API 설계와 아키텍처 설계에 관심이 많아서 그 부분을 깊게 고민해 보았고 상대적으로 다른 팀원들보다 조금 더 알고 있었다. 다른 팀원은 DB에 관심이 많아서 ERD 설계를 깊게 고민해보고 해결해 본 경험이 있었다. 또 다른 누군가는 예외 처리와 보안 인증에 관심이 있었다.

 

이렇게 서로 다른 관심사를 가진 사람들과 협업을 하게 되니 혼자였으면 고민해보지 않았을 내용들을 알 수 있어서 정말 좋았다.

 

컨벤션

이번 주차에 컨벤션을 아예 제대로 다뤄보려고 한다. 깃 커밋 컨벤션, 코드 컨벤션, 그리고 기타 컨벤션 등 최대한 많은 컨벤션을 만들고 그거에 맞춰서 작업하는 걸 연습해보려고 한다. 

 

컨벤션들은 생으로 직접 짜기보단 구글 컨벤션이나 MySQL 공식 문서 같은 꽤 공신력 있는 자료들을 참고해서 작성할 예정이다.

 

그리고 컨벤션을 커스텀해서 컨벤션에 어긋나면 커밋하지 못하도록 하는 기능이 있다고 하니 그것도 찾아보도록 하자.  

 

실무에서의 의사 결정

오늘 매니저님의 피드백 중 재밌는 이야기를 들었다.

 

실제 서비스 운영 중에 서비스가 터지는 일이 발생했고, 그걸 해결하기 위해 데이터의 무결성을 깼었다고 하셨다.

 

실무에선 그런 일들이 상당히 비일비재하게 발생한다고 생각한다.

 

예전에 작은 스타트업에서 꽤 훌륭한 CEO분과 같이 일을 했었는데, 그때 그분의 의사결정들을 보면서 느낀게 있다.

 

리더는 항상 옳은 결정을 내려야 하는게 아니라 상황과 시간에 맞는 적절한 의사 결정을 내려야 한다. 항상 모든 것을 가져갈 순 없다. 늘 현실과 타협을 해야 하고, 무언가를 포기해야 한다. 그 의사 결정의 과정을 다른 팀원들이 이해할 수 있다면 그 팀은 정말로 잘 돌아갈 것이라 생각한다.

 

실무에선 늘 무언가를 포기하고, 타협해야 하는 상황이 올 것이다. 이런 것들을 잘 저울질하고 선택할 수 있는 게 좋은 리더와 좋은 팀원의 조건이라고 생각한다.  

 

잘한 점

개선할 점