4주 프로젝트 회고
데모데이를 마지막으로 공식적인 4주 프로젝트 일정이 끝났다.
나는 우리 팀의 서비스 발표를 진행하였는데, 손에 땀이 나서 끈적거리는 느낌을 처음으로 경험해 볼 수 있을 정도로 발표 직전까지는 긴장이 되었다. 발표 후에는 긴장이 풀어진 탓인지 무슨 말을 했는지 기억이 안 나서 영상을 돌려보았는데 다행히 준비했던 말들은 대부분 했고, 생각보다 떨지 않았던 것 같다. 이런 발표 정말 재밌다 :)
+
킥오프와 더불어 많은 응원을 보내주신 준홍 엔지니어님이 앱에 대한 질문도 남겨주셔서 좋았다. 진짜 코드스테이츠 엔지니어분들 다 너무너무 좋다.
매주 일요일에 회고글을 썼는데 이번 주는 일요일과 프로젝트 종료일이 이틀 차이밖에 나지 않았기에 4주차의 회고 글은 작성하지 않았다. 그래서 이 글에는 4주차 때 느꼈던 점들을 바탕으로, 프로젝트를 하면서 기술적으로 배웠던 점들에 대해서 먼저 언급을 하고 그 외의 심리적인 부분로 나눌 예정이다.
우선 기술적으로 배웠던 것들이다.
- 하위테이블의 자료부터 삭제하고, 상위테이블로 넘어가자!
db의 자료를 삭제시, 외래키로 묶여있는 테이블이 있다면 하위 단계의 테이블의 자료부터 삭제한 후에 상위 테이블에서의 삭제를 해야한다.
카페 정보를 담는 cafes, 특정 cafe_id에 대한 사용자들의 리뷰가 있는 reviews 테이블이 우리 프로젝트에서의 한 예이다. 즉 이미 리뷰가 작성되어 있는 카페라면 리뷰 테이블에서의 해당 자료를 먼저 삭제하고, 카페 테이블에서의 삭제를 진행해야 삭제가 잘 진행된다.
반대로 상위개념에서부터 삭제를 시도하면 이와 같은 에러를 만날 수 있다.
그러므로 delete메소드를 적용하는 컨트롤러의 파일이 있다면 이 역시 하위 후 상위의 순서로 각각 destroy를 실행해야한다. 원두 기록을 남기는 notes도 먼저 notes_flavos의 자료를 삭제해야했고, mocha, chia로 truncate를 할 때도 마찬가지였다.
2. 에러 코드의 정리!
에러가 나는 상황은 다 각각 다르지만, 비슷한 상황임에도 상태 코드가 뒤죽박죽인 것을 발견했다. 그래서 승환님께 받은 답변을 토대로 코드를 정리해보니 find가 잘 안 되는 경우, bad req인 경우, syntax는 맞는데 넘겨진 데이터가 invalid인 경우 등으로 나눠볼 수 있었다. 이에 따라 404, 400, 422로 상태코드를 변경하고, 기존에 ‘err’라고만 나왔던 res도 더 상세하게 적어서 에러 발생시 직관적으로 상태를 알아챌 수 있도록 했다.
3. API 문서 작성 도구로 swagger를 사용했다!
지난 주 후반부에 시간적으로 조금 여유가 있어서 swagger에 대해 공부했다. 검색하면 node.js가 아닌 springboot와 적용해서 사용한 사례들이 대부분이고, swagger 에디터로 문서를 작성할 수는 있는데 그것에 나의 코드와 어떻게 연동이 되어서 작성이 되는건지 알아보는데에 시간을 많이 썼다.
어려웠지만 이번 기회에 배워두면 나중에도 계속 잘 쓸 수 있을 것 같아서 새롭게 배운 것에 만족한다. 결론적으로 문서가 작성될 뿐만 아니라 실제 코드로 테스트를 해볼 수도 있기에 프로젝트 초반부터 계속해서 사용한다면 코드가 잘 반영된 api 문서가 될 것이다. 내 경우에는 이미 만들어져있는 api 문서를 swagger로 리팩토링하는 것이었기에 포맷을 바꾸는 것에 이렇게 시간을 투자하는 것이 가치가 있을지에 대해 조금 회의감이 들기는 했다. 그리고 indentation에 민감해서 사실 조금 짜증나는 순간들이 있기도 했다.
하지만 무엇보다 이름에 끌려서 이 모듈을 꼭 쓰고 싶었다. 모듈의 이름이 swgger라니! 네이밍 최고!
4. null을 막는 방법?
이미 테이블 구조를 다 만들고 한참 후에 특정 컬럼에 대해 allowNull:false옵션을 추가했는데 테이블의 구조 자체에는 변경이 되지 않아서인지 migration이 되지 않았다. 테이블을 아예 삭제 후에 다시 migration을 하면 반영이 될 것 같은데 이미 들어가 있는 자료들이 있었기에 삭제될까봐 차마 시도하지 못했다. 혹은 컨트롤러에서 그 컬럼의 바디 파라미터의 길이가 0일 때는 에러 메세지를 띄우게 할 수도 있을 것 같다. 이젠 프로젝트가 끝나서 로컬호스트의 데이터는 날아가도 불편하지 않으니 우선 테스트를 해봐야겠다!
5. 중복되는 데이터를 함께 찾은 후 findOrCreate는 어떻게 할 수 있을까?
cafes는 해당 주소가 이미 db에 등록이 되어있지 않는 경우에만 등록을 하려고 했다. 그래서 findOrCreate 에서 where: { address: address}로 조건을 주고 defaults로는 다른 바디 파라미터들을 넣어주었는데 주소는 같아도 다른 값들이 달라서인지 아예 다른 데이터로 인식을 하고 create가 됐다. 사실 이 경우에는 3번의 상황이 이미 적용 되어야 할 것 같기도 하다. 우선 중복인지를 체크하는 옵션을 migration하고, 그 이후에 where조건절을 다시 써서 테스트를 해봐야겠다.
6. 핸드폰 기종마다 CSS는 다르게 적용될까? 혹은 ‘비율’을 설정하는 걸까?
팀원분들이 올려주신 코드를 실행하면 내 핸드폰에서만 유독 정렬이 깨지는 것을 발견했다. 현재 내가 사용하는 기종은 아이폰7이고, 그동안 다른 앱들을 받았을 때 뷰가 이상하게 나오는 일은 전혀 없었어서 예상하지 못했던 오류였다. 우선 CSS의 숫자들을 하나하나 조정하니 비율 문제는 해결이 되었지만, 그 경우 다른 분들의 핸드폰에서는 변경 전보다 조금 덜 예쁜 모습으로 보였다. 그래서 결국 발표 문서에 배포 링크를 걸고, 특정 기종으로 테스트를 했어서 다른 기종에서는 뷰가 조금 깨질 수 있다는 언급을 해야했다.
앱스토어에서 앱을 설치할 때에는 사용자의 기종이 어떤 것인지 정보를 받아서 그에 맞는 버전이 설치가 되는 것일까? 혹은 % 단위로 설정을 해 놓아서 모든 기종에 맞게 ‘자동' 적용이 되는 것일까? 하지만 그러기에 나의 기종은 최신 기종들에 비해 세로의 비율이 작은 편인데 이것이 %만으로 해결될 수 있는 문제인지 궁금하다. 또한 내가 클라이언트를 테스트할 수 있는 기종이 아이폰7 뿐이고 이것이 모든 기종을 커버하지 못한다면, 결국 현재로서는 안드로이드 스튜디오를 설치해서 모든 기종으로 테스트를 해보는 것이 최선인 것 같기도 하다.
다음으로는 심리적인 부분과 관련된 사항이다.
프로젝트 내내 팀원 한 분과의 소통 때문에 정말 힘들었다. 사실 4주동안 팀장으로서 프로젝트를 이끌어 나가면서 받은 스트레스의 99%는 이 분으로 인해 발생했다. 그래서 이 분과의 대화를 통해 배운 점과 앞으로 하지 말아야 할 것들에 대해 정리해보고자 한다.
1.지금까지의 진행 상황보다 변명과 핑계에 집중한다.
태스크마다 예상 시간을 정해놓고 작업을 시작하지만 그것이 일찍 끝날지, 몇 배로 길어질지는 아무도 모른다. 우리는 매일 5시에 그 날의 진행상황을 체크하고, 코드리뷰를 했는데 결국 각자 해야하는 말은 ‘어느 정도 구현이 되었고, 어느 정도의 시간이 더 걸릴 것 같다’이지 그러한 과정에서의 핑계는 본인만 알면 족하다. 물론 ‘이것을 시도했는데 안 돼서 저것을 해봤는데도 안 되고, 그래서 혹시 아이디어가 있으면 도움을 요청한다'는 당연히 환영하고, 모두 그렇게 했다. 하지만 애초에 논점이 ‘나는 해보려고 했는데 안 된다. 근데 나는 시간을 진짜 많이 썼다. 난 논 게 아니다'로 넘어가는 것과는 아주 다른 문제라고 생각한다. 그렇게 ‘꾸준한 핑계는 사람을 구차하게 만든다'는 점, ‘핑계를 대기 전에 매 순간 진심을 다해 무엇을 했는지 생각해보는 시간을 가져야한다'를 배웠다.
2. 배려와 결정을 미루는 것은 분명히 다르다.
의도는 분명 배려였을 것이라고 생각한다. 하지만 다 같이 기획한 태스크들에 관해 지속적으로 ‘나는 모르니 어떤 자료를 내가 서버에 보내면 되는지 너가 결정해서 알려달라'라고 하는 것은 결국 프론트엔드의 일을 백엔드 포지션에게 전가하는 셈이다. 특정 모듈과 라이브러리를 사용할 때마다 정해진 형식이 있고, 그에 대해 충분한 소통이 필요하지만 기본적으로 클라이언트에서 보내는 형식에 관해서는 클라이언트 담당자가 서버 담당자가 더 잘 알아야한다고 생각한다. 물론 서버 담당자가 클라이언트의 모든 것에 대해서도 다 잘 알면 좋겠지만, 그런 일은 쉽게 발생하지 않으니 말이다. 그래서 이 부분에 있어 효율적이고 유기적인 소통이 정말 어려웠다.
또한 코드의 구현이 아닌 기획 단계에서도 ‘나는 모르니 너희가 좋은 의견을 결정해서 알려주면 나는 지시에 따르겠다'라고 하는 것 역시 책임을 미루는 것이다. 우리는 사람인만큼 실수가 있을 수 있고, 추후에 그것을 바로잡는 작업이 필요하다. 하지만 이에 대해 본인은 처음의 지시대로 했다고 말씀하시는 것을 보며 ‘배려와 책임 회피는 한 끗 차이’라는 점, ‘다른 분들의 의견은 충분히 수용하되 나의 업무에 대해서는 어디까지나 내가 가장 잘 알아야하므로 주체적으로 처리를 해야한다’는 점을 배웠다.
3. 회의에 적극적으로 참여하지 않는다.
초기에 스키마를 작성할 때, 회의 내내 말씀이 없으셔서 의견을 부탁드렸었는데 본인은 데이터베이스를 모른다는 말씀을 하셨었다. 그 이후의 다른 기획에 대해서도 의견을 내놓으시는 일은 거의 없었다. 말을 안 하는 사람을 강제로 말하게 할 수 있는 방법이 사실상 없고, 의견 제안이 없더라도 프로젝트에 대해 이해만 한다면 그래도 괜찮지 않을까 생각했다. 하지만 프로젝트에 대한 전반적인 이해도가 다른 팀원분들과 너무 달랐고, 그렇기에 특정 태스크에 대해 이 분이 원하신 ‘지시'를 해도 그것을 다르게 받아들이셨다.
처음에는 나의 의사소통 방식에 문제가 있는 것인지에 대해 진지하게 고민을 했는데 다른 팀원분들과는 모든 분야에서 완전하게 소통이 되었으므로 이것이 비단 나만의 문제는 아니라는 생각이 들었다.
결국 회의를 통해 적극적으로 아이디어를 공유하지 않은 것이 프로젝트 전반에 대한 이해도 저하로 이어졌다는 결론을 내릴 수 있었다. 또한 ‘모른다는 태도로 지시만을 기다리는 것은 결국 계속 모르는 상태를 유지하겠다’와 같은 뜻임을 배울 수 있었다. 1, 2번 모두 깊은 깨달음을 주었지만 특히 3번의 결론이 앞으로 일을 하고, 무언가를 배울 때 나 자신을 쉽게 합리화시키지 않을 수 있도록 도와줄 것 같다.
이렇게 재밌으면서도, 3kg이 저절로 감량된 4주가 지났다. 무엇보다 2주 프로젝트에 비해서 두 배 이상으로 많은 것을 배울 수 있어서 뿌듯했다.
이제 ‘어떻게 기획했는지’부터 ‘결과물은 어떠한지' 대해 새로운 글을 남겨봄으로써 프로젝트를 완전히 마무리하고 리팩토링을 하는 시간을 가져야겠다 :)
