[우테코/줍줍] 1차 스프린트 회고

+ 1차 데모데이 영상이 올라왔습니다🎉 (https://youtu.be/6rfkFdJCxDw)

 

팀 줍줍의 2주간의 일정

 

😵 얼렁뚱땅 정신 없이 지나가는 날

 우테코 레벨 3가 시작한지 약 2주가 되었다. 어느새 1차 데모데이가 끝났다. 여태까지 팀에 어떤 일이 있었는지, 팀 원들끼리 어떤 이야기를 나누고, 어떤 작업을 했는지 그런 과정을 담은 이야기를 하려고 한다. 원래는 일주일에 하나 정도씩 적고자했는데 저번주는 개강 직후라 너무 바빠서 담을 말이 많이 없었다😅 이번 주도 개발을 많이 했느냐? 라고 물어본다면 그렇지는 않은 것 같지만... 팀만의 컨벤션 팀만의 규칙 팀만의 어쩌구를 정하느라 내내 입운동을 한 것 같다. 중요한 시간이었다. 😊

 

 

✨ 특별한 경험

💛 우리들만의 팀 문화

 매일 데일리 스크럼 진행하기, 코어 시간 정하기, 주마다 회고하기 등등 여러가지 우리만의 팀 문화를 정했다. 나는 특히나 정해진 의견은 팀의 의견으로 정하자는 이야기가 마음에 들었다. 누군가 저거 왜저렇게 개발했어요? 라는 말이 나왔을때 아 전 저거 반대했었는데.. 이런 식으로 개인의 책임으로 떠밀거나 회피하는 케이스를 방지하고자 함이었는데 이런 저런 이야기를 통해 우리 팀원들의 배려심과 평소 사고를 알 수 있게 되어 좋았다. 😄

 

💛 몹 프로그래밍

 우테코에서 페어 프로그래밍도 처음 해봤는데 이번에 몹 프로그래밍을 진행하게 되었다. 몹 프로그래밍이란 3인 이상의 개발자들이 모여 함께 개발하는 방식이다. 우리 팀은 백엔드 크루가 4명이라 4명이서 동시에 진행하게 되었다. 각자의 코드 컨벤션이 모두 다를테니 몹 프로그래밍을 이용하면 맞춰나가기 더 쉬울 것 같다는 생각에 도전해보았다. 이 예상은 딱 적중했다. 테스트 코드에 한글을 넣을지 말지나 final을 선언하는 방식, 커밋 메시지 작명 방법 등등 사소한 것 하나하나 다양했고 이 의견을 취합하는 과정이 많았다. 매우 새롭고 즐거운 방식이었으나 마감 기한에 맞추기 위해서 100% 몹 프로그래밍 방식으로 가는건 힘들겠다는 생각도 들었다😅

 

💛 UI/UX 특강

 외부 강사님과 함께 한 시간이었다. 처음에는 확인/취소 버튼이 있을 때 취소 버튼 쪽에 하이라이트가 있으면 사용자들이 헷갈릴 수 있다~ 이런 내용을 가르쳐주나? 했는데 전혀 달랐다.💦 개발자가 아닌 기획자로서 프로젝트를 바라볼 수 있게 시야를 넓혀준다는 느낌이 들었다. 가장 즐거웠던 시간은 우리 팀의 주제로 수요조사와 인터뷰를 진행한 것이다. 실제로 이 서비스가 생기면 사용할 것 같은지, 이 서비스에 기대하는 점은 무엇인지. 프로젝트의 방향성도 조금 달라질 수 있었고 팀원들과도 더 친해질 수 있는 시간이었던 것 같다. 이 특강 때 끄적끄적거렸던 낙서가 우리 팀의 로고로 채택되기도 해서 뿌듯하다🤭

 

👉 줍줍 수요조사와 인터뷰 결과 보러가기

GitHub - woowacourse-teams/2022-pickpick

 

💛 공원과의 식사

 저희가 공원이랑 왕 맛있는 인도 커리 먹은 팀으로 보이시나요? 네 맞습니다😎 공원이 점심을 다같이 먹자고 제안해주셔서 아! 이번에는 회식비 이렇게 쓰이나보다! 하고 점심으로 아그라로 갔다ㅎㅎ 알고보니 공원은 점심 간단하게 먹고 다음에 저녁으로 간단하게 한잔 생각하셨던 것 같은데 이번에 다 써야하는줄 알고...😂💦 그래도 인도 커리는 너무 맛있었다. 안그래도 요근래 인도 커리 먹고싶다고 노래를 부르고 다녔는데 어떻게 알았지 내가 노래부르고 다녀서 알았나? 양이 적기로 유명한 내가 이날은 과식해서 저녁도 제대로 못먹고 하루종일 배부른 상태로 있었다.😅

 

 

🙆‍♀️ 나눴던 이야기

💜 레벨 3에서의 목표

 프로젝트의 목표는 크게 '진한 협업 경험'과 '포트폴리오에 쓸 수 있는 프로젝트의 완성'으로 뒀다.😎 우리 팀의 모든 인원이 우테코 수료 후 바로 취직을 해야하는 사람들이었다. 프로젝트에 모든걸 내던지기보다는 개인 공부할 시간도 필요하다는 의견이 만장일치였다. 우테코의 교육 시간인 월 1 to 6, 화~목 10 to 6을 코어 시간으로 두고 해당 시간에는 팀 프로젝트만 하되, 그 외 시간은 터치하지 않기로 했다. 이를 최대한 준수하려고 노력한 결과 스프린트 1 기간의 야근(?) 시간은 총 2시간이었다.👏👏👏 이 마저도 구현은 끝내고 리팩터링을 하고 싶어서 자발적으로 나섰다. (프론트 쪽은... 항상 바빴던 것 같지만.. 프로젝트 초기라 어쩔 수 없었고 이제부터 무리하지 않기로 했다!💪) 

 

💜 메시지를 실시간으로 보여줘야 할까?

 줍줍의 서비스는 무료 버전의 한계로 인해 자꾸 사라지는 슬랙 메시지를 백업해주는 일이 메인이었다. '이미 사라진 메시지'를 찾는다는 가정 하에 서비스를 이용한다 생각해 데이터를 실시간으로 보여줄 필요가 없다고 생각했다.🤔 그래서 초기에는 6시간 또는 12시간 단위로 메시지 목록을 저장하는 API를 만들자고 구상했다. UI/UX 특강 때 수요조사와 여러 인터뷰를 조사했는데 그 결과 '백업'도 당연히 중요한 일이지만 원하는 정보를 '검색'하는게 생각 이상으로 더 중요했다. 어떤 사람은 내가 검색한 메시지 목록에서 현재 메시지와 과거 메시지를 비교하고 싶은데 실시간성이 보장되지 않는다면 불편할 것 같다는 의견도 내주었다. 이를 포함한 몇 이유로 팀원들에게 슬랙 이벤트에 훅을 거는 방식에 대해 제안을 했다. 제안을 하면서도 이게 괜찮은 방식일까 의문이 아직 남아있었다. 팀원들이 모두 타당한 이유와 함께 긍정적인 반응을 보여주였고 실시간성 보장하는 쪽으로 채택되었다. 👍

 

💜 어떤 DB를 사용할까?

 PostgreSQL vs MySQL vs MariaDB. 어떤 DB를 사용할까에 대한 의견을 나눴다. 언뜻 들었을 때 PostgreSQL이 좋다던데~ 라는 이야기가 있어서 호기심이 동했다. 복잡한 쿼리에서 성능이 좋다는데 우리는 복잡한 쿼리를 사용할 일이 많이 없을 것 같았다. 또 update가 insert -> delete인 작업을 하나로 묶은 것과 동일하기 때문에 update가 자주 발생할 수 있는 우리 프로젝트에서는 더더욱 부적절하다고 느껴졌다. MariaDB는 MySQL과 거의 차이가 없었기 때문에 더욱 고민됐다. 약간의 차이점들이 있긴 한데 해당 설정들을 세세하게 이용할 일이 없을 것 같았다. 우리의 서버 배포는 AWS로 확정난 상태였고, 만약 AWS에서 DB를 변경하게 될 때 MariaDB보다는 MySQL이 이관하기 쉽다는 말을 들었다. 최종적으로 MySQL을 선택하게 되었다.

 

💜 DB를 설계하는 방법

 처음에는 변경 최소화가 되는 DB를 먼저 설계하자는 제안을 했다. 컬럼을 추가하거나 수정 삭제 시 데이터가 유실되거나 null 값이 들어가는 현상이 위험하다고 생각했기 때문이다.😣 하지만 프로젝트 초기 단계이기 때문에 DB 변경은 불가피하고 결정적으로 DB 변경을 최소화 하려다 보면 도메인이 아닌 DB 중심 개발이 진행되지 않을까라는 의견에 설득 당했다.😅 구현하면서 유연하게 DB를 변경하는 것으로 결정했다.👍

 

 

🐱‍👤 되돌아보기

🖤 철저한 시간 관리가 필요하겠구나...

 처음에는 팀 코어 시간 외의 시간은 CS 지식을 공부하려고 했다. 케이의 알고리즘 스터디를 하나 들었고 네트워크 책도 샀다. 하지만 되돌아보니 개인 공부를 한 시간이 정말 적었던 것 같다. 매일 갑자기 할 일이 생겼고 그걸 해결하느라 급급했다. 네트워크 책 한 챕터를 그것도 초반에나 겨우 읽은 것 같다. 다음 주부터는 다시 꾸준히 책을 읽으려고 노력해봐야겠다. 내가 왜 조급함을 느꼈는지 시간 관리의 실패 원인을 분석해봐야겠다.

 

🖤 개발 욕구 충족시키기

 몹 프로그래밍의 단점이라고 생각될 수도 있는데 실질적으로 내가 키보드를 붙잡고 타자치는 시간은 짧다. 초반이라 개발보다 팀 회의할 일이 많았고 그나마 진행되는 개발도 몹으로 하다보니 진행이 느렸다. 물론 좋은 방향으로 나아간다는 생각은 들었지만 '개발하고 싶다'는 욕구가 모두 충족된다는 생각이 들지는 않았다. 누군가 현직자에게 '회사 다니는 것도 바빠죽겠는데 어떻게 토이 프로젝트까지 하시나요?'라고 질문을 했는데 '회사는 회의 하느라 바빠서요. 내가 하고 싶은 개발과는 다르더라고요. 하고 싶은 일을 하고 싶었어요' 라고 답변한 사람이 있었다. 이번 스프린트의 내가 이런 상황이었던걸까? 이제 팀에 적응도 거의 다 했겠다 다음 스프린트부터는 페어로 진행할 것 같긴 하다. 이제는 개발 욕구가 어느 정도 충족되지 않을까 라는 기대감을 가져본다.

 

🖤 커뮤니티 풀도 힘이다

 이번에 백엔드 쪽에서 어떤 문제에 직면했는데 스스로 생각하는데 한계를 느껴 온갖 곳에 물어봤다. 예전에 했던 스터디 모임, 개발자들이 모인 오픈 카톡방, 우테코 코치, 트위터, ... 큰 의미를 갖고 한 행동은 아니었고 원래 나는 궁금한게 생기면 어디든 붙잡고 물어보는걸 좋아한다. 그리고 개발자들은 자기가 아는걸 공유하는걸 정말 좋아하는 사람들이 많으니까! 많은 사람들이 조언을 해주었고 나는 이 내용들을 팀원들에게도 공유했다. 한 팀원이 위 사진과 같은 말을 해주었는데 문뜩 엇, 이런것도 나의 장점이라고 생각해도 되지 않을까? 라는 생각이 들었다. 다른 사람의 도움으로 일을 해결할 수 있던거니까 나의 장점으로 연결시키진 못했는데 팀원의 말을 통해 조금은 자신감을 갖게 되던 에피소드였다.

 

👉 어떤 문제였는지 궁금하다면?

같은 HTTP 메서드, 같은 url인 API를 분리할 수 있을까?

 

🖤 다른 사람을 설득하는 방법

 나는 예제를 통해 설득하는 방법을 선호한다. 다른 사람을 이해시키기에 이보다 편하고 좋은 방법은 없다고 생각하기 때문에... 어떤 예제를 들고 상대가 납득하지 못한다면 다소 극단적인 예제를 드는 편이다. 그러면 상대가 엣지 케이스를 듣고 그렇구나~ 라고 생각할줄 알았는데 항상 그렇지는 않다는걸 이번에 깨닫게 되었다. 왜 그런 케이스까지 고려해야하는지 잘 모르겠다는 답변을 듣고 그렇게 생각할 수도 있구나😮❗ 라는 생각을 하게 되었다. 어떻게 해야 상대를 더 좋게 설득할 수 있을지 생각해봐야겠다.

 

 

 

팀 줍줍의 소식이 궁금하다면? 

https://github.com/woowacourse-teams/2022-pickpick Star 필수😆

GitHub - woowacourse-teams/2022-pickpick