팀 안에서 회고에 대해 갈린 생각
나는 감정 회고를 통해 팀을 이해하는데 도움이 되었다고 생각했지만, 이게 불필요하다고 느끼는 사람들이 있을 것 같았고 실제로 그랬다는 걸 알게되었다. 사실 이 생각의 차이는 저번주 데모데이 후 돌아보기 회의에서부터 느꼈긴 했다. 결국, 월요일에 이에 대해서 제대로 논의했고 처음으로 의견 차이가 꽤나 크다는 걸 느꼈다.
감정 회고가 필요한 사람과 필요없는 사람의 차이는 성향의 차이라고 생각한다. 따라서 하는게 맞다, 아니다라고 정답이 있는 문제가 아니었다. 양쪽이 모두 왜 해야하는지, 왜 필요없는지를 충분히 얘기했고, 물론 시간을 아끼는 것도 중요하지만 팀 내에서 감정이 곪아 터지는 상황이 생긴다면 그게 더 팀에게 나쁜일이라는 데에 모두가 공감했다. 그래서 진행을 하되, 유강스 시간을 활용해 하고싶은 사람만 빠르게 진행해보기로 우선 결론을 내렸다.
이런 정답이 없는 의견 차이를 감정이 상하지 않으면서, 타협점을 찾아가는 게 협업이겠지? 어려운 일이구나를 다시 한 번 깨달았다.
도메인 구조 ver 3.
조영호님의 우아한 객체지향 강의을 보고, 저번주 데모데이 때 네오에게 조언까지 받고 나니 우리 도메인 구조를 수정해야한다는데 의견이 모아졌다. 마냥 객체지향적으로 짜느라 양방향 연관관계가 다수 존재하는 현재 구조를 개선하자는 것이 목표였다. 그래서 이번엔 무조건 객체지향!! 또는 반대로 무조건 참조 끊기!!이 아니라 생명주기와 정책의 변경 유연성을 고려해서 다시 도메인 구조를 짜기 시작했다. 이 과정에서 매우 고무적이라고 느낀 점이 있었는데 바로, 자연스레 아래와 같은 기준이 우리에게 생겼다는 것이다!
-
너무 생명주기가 같고 && 수정 필요성이 없고 && 부모가 삭제되는 경우 자식들도 동시 삭제되야하는 경우는 다대일 참조관계를 기꺼이 걸어준다.
-
1번 정도의 연관이 없는 것은 id만 갖고있게해서 직접적인 객체 참조를 끊는다.
-
검증도 해당 도메인이 어떤 정책 변경이 있든 상관없이 들고 있을 수 있는 보편적인 검증만 도메인에 넣고, 나머지는 서비스로 올린다.
- 따라서 검증이 객체 내에서가 아니고 서비스에서 이루어 지기에 절차지향적일 수 있다. 하지만
나중에 검증에 추가될 게 있을 때, 찾기 쉬운가를 우선으로 생각한다면, 즉 변경을 기준으로 생각한다면 절차지향적인 방식이 나쁘지 않다.(예: validator 클래스를 통한 검증 등)
물론 이 과정에서 이럴거면 이전 도메인과 로직을 짠 게 다 의미 없는 일 아닌가, 시간을 낭비한 것 아닌가하는 생각이 들 수도 있었겠지만, 그렇지 않았다. 어차피 결과는 계속해서 변하는 것이고, 그 과정에서 배운 프로세스가 더 오래 남기에 의미있다고 생각한다! 그런 관점에서는 이번 갈아엎는 경험을 통해 도메인 설계에 대한 정말 중요한 관점과 프로세스를 얻을 수 있게되어서 전혀 후회되지 않았다. 오히려 너무나 좋았다!
코드란 덧없는 것, 계속 변화하는 것이구나
도메인 엎기 ver3 과정에서 또 하나 느낀 것이 있었다.
산초와 함께 도메인 변경에 따른 수정사항 적용을 하면서 우리가 공들에 만들었던 Member 패키지를 삭제했는데, 코드란 참 덧없는 것이구나를 몸소 느꼈다. 코치들도 이걸 느끼는 게 중요하다고했었는데, 비로소 알게되었달까😂
이 Member 패키지 내의 코드를 짜고, 코드 리뷰를 하면서 네이밍이며 개행이며 얼마나 오래 고민했던가…
1, 역시 꼼꼼하게 짜서 검증이며 로직이며 탄탄한 코드를 짜는 것보다 변경에 유연한 코드를 짜는 게 중요하구나!
2. 너무 오래 고민하지 말고 빨리 빨리 짜고 변경에 대응하는 것이 더 중요하구나!
뼈저리게 느낌!!
ps. 패키지를 하나 하나 삭제하던 산초와 나...
2.5차 미니 데모데이
저번 2차 데모데이 때, 꽤나 아쉽다는 피드백을 받았다. 로그인이며, 리뷰 모아보기 기능이며 그런 부가적인 것들은 싹 빼고 일단 리뷰를 작성하고 확인하는 하나의 플로우를 완성해서 사용자가 경험해보게 하는 데 집중했어야 했다는 것이다.
이걸 놓친 것이 너무 아쉬웠다. 하지만 아쉬워만 하면 뭐할것인가!
그렇다면 1주일동안 바로 적용해보고 다시 피드백을 받으면 되지!라고 우리팀은 결론을 내려 1주일만에 부가 기능을 싹 빼고, 사용자 접속, 리뷰 작성, 확인이라는 하나의 사용자 플로우를 다시 구현했다.
동시에 질문지와 설문지 포맷 설계에 대한 중요성도 다시 한 번 깨달았기 때문에, 지난 1주일동안 투트랙으로 기능 구현은 구현대로 하면서 질문 회의도 진행하였다. 그 결과로 객관식+서술형이라는 설문 스타일도 만들어지게 되었다.
그렇게 포비와 준에게 바로 연락드렸고, 자체 2.5차 미니 데모데이를 진행했다😂 결론적으로는 너무 하길 잘했다는 생각이 들었다.
현재 플로우에서 보완할 점들(예: 첫 질문이 중요하다. 리뷰이와의 기억을 떠올리게 하는 장치가 필요하다. 열린 질문을 해야한다. 등)을 얘기해주셨고, 이런식으로 우리가 직접 써보고 거기서의 피드백을 반영하는 일명 ‘도그푸딩’이 중요함을 얘기해주셨다.
다시 한 번 중요한게 뭔지 방향을 잡은 느낌이다!
