멋쟁이사자처럼 11주년 해커톤

우노·2023년 8월 25일

해커톤 끝난지 일주일이 지난 시점에 쓰는 회고라니 ,,
열심히 쉬다보니 벌써 일주일이 지났고 넘기기에는 생각해둔 주제가 많아서 아쉬운 마음에 또 머리도 복잡해서 쉬어갈 겸 적어봅니다 !

시도

협업

이전에 두어번의 프로젝트 경험은 있지만 백엔드의 작업물을 그대로 프론트한테 넘겨주거나 프론트, 백 1:1 작업을 했어서 기디프백이 전부 모인 협업다운 협업은 처음이었다고 볼 수 있을 것 같습니다.

다른 파트와 함께 회의하면서 협업을 어떻게 해야하는지 어느 정도 감을 잡을 수 있었고 특히 프론트-백의 소통에서 프론트가 무엇을 원하는지 이해할 수 있었던 것 같아요. API 시트에서 HTTP 상태 코드도 중요하지만 에러 메세지로 로직이 나누어진다는 걸 느낀 게 가장 큰 것 같습니다.

백엔드가 좀 더 빠르고 확실하게 마감을 해야 여러 파트가 편해지겠구나도 생각할 수 있었습니다. 멀티가 어려워서 피그마의 디자인을 소홀하게 여기고 코드를 짜거나 에러 처리가 덜 되었을 때 기디프가 고생하는 걸 보고,, 와이어프레임과 피그마를 한 번 더 보고 생각하자,,, 를 많이 느꼈습니다.

CI/CD

우연한 기회로 GitHub Actions를 접하게 되면서 해커톤 프로젝트에 충분히 CI/CD를 시도해볼 수 있겠다는 생각이 들어 약간의 삽질을 거쳐 무중단배포를 자동화할 수 있었습니다. 약 70번의 PR 머지와 동시에 서버 코드가 업데이트 되었으니 번거로운 일 하나를 줄인 것은 나름 성공적이라고 볼 수 있을 것 같아요. 조금 더 발전했다면 도커나 도커 컴포즈까지 활용하고 비밀키 파일 업데이트도 자동화할 수 있었을텐데 하는 아쉬움은 한켠에 남아있습니다🥲

GitHub 활용

GitHub의 여러 기능들을 활용하면서 GitHub이 버전 관리, 개발 협업 관리 툴이라는 걸 다시 깨달을 수 있었습니다. 어느 정도는 당장 코드가 보기 싫어서 협업 관리한다는 핑계로 도망친 것이긴 했지만.. 결과물 잘 쓰고 할 일 열심히 했으니 봐주는 걸로... 히히
한 번 Issue, PR 템플릿, 라벨을 만들어두니 어떤 기능이나 파일을 고쳤는지 적기도 편하고 이해도 빨라져서 서로 코드 봐주기가 편해졌던 것 같습니다. GitHub Actions를 포함하여 브랜치부터 이슈 등 여러 기능을 시도해볼 수 있는 좋은 기회였던 것 같아요. 레포 리드미 미뤄두고 있는데 언제 쓰지...

재미 챙기기

어렴풋이 남아있는 개발자 자기PR에서 제가 분명히 재미는 포기 못한다고 했던 것 같은데 그 부분은 확실히 챙긴 것 같아서 팀원들에게 고맙다고 생각하고 있습니다 !
책임감을 가질 일은 팀원과 마감 기한 밖에 없다고 느낀 만큼 동기부여를 위해서는 팀이나 프로젝트에 대한 애정이 중요하다고 생각했거든요. 이전 아이디어톤 때 캐릭터에 애정을 가져서 팀에 애정을 갖게 된 만큼 팀, 프로젝트 자체 둘 중 하나에는 애정이 있어야 제가 달릴 거라고 생각했는데 좋은 팀원들 만나서 귀여운 캐릭터가 있는 챌린징한 서비스 만들게 되면서 더 열심히 달릴 수 있었던 것 같아요. 제 지분이 40% 이상일 것 같지만 노션 우리의 추억 가득 채운 점 너무 뿌듯합니다. 절 대 쿵 야 해😆

아쉬움

API 문서화

API 시트 때문에 프론트한테 장난으로 혼나서 사알짝 억울했던 부분도 있고 시트 업데이트 하면서 백엔드 두명이 번거로웠던 기억이 있어서 swagger로 API 문서화를 못 했던 점이 아쉬운 것 같습니다. 약간의 변명을 해보자면 이미 여러 API가 완성된 상태에서 swagger를 위해 APIView ➡ GenericAPIView로 바꾸는 시도를 하기에는 당장 구현이 훨씬 급한 상태였고 swagger를 연결해도 주석 처리 등 해줘야할 일이 많아서 CI/CD처럼 초기에 연결하지 못한 점이 계속 아쉽게 남는 것 같아요. 예상치도 못했던 테스트케이스에 프론트도 미안해하고 백도 당황했던 경험을 생각하면.. API 문서화는 필수...

Response code 정리

프론트가 에러 메세지로 로직을 나눈다는 걸 미리 알았다면 API 시트에 하나하나 캡처로 업데이트 하기보다는 발생할 수 있는 에러마다 N자리 숫자로 정리해서 전달하는 게 서로 더 편했을 것 같다는 걸 너무 늦게 안 점을 아쉽게 생각하고 있습니다.

django 이해하기

django에 대한 이해가 부족한 상태로 프로젝트를 시작하다보니 views.py와 serializers.py 두 파일로 해결하려했던 점도 아쉽고 view에서 serilizer의 기능을 하고 있다거나 serializer에서 모든 기능을 수행하려 했던 점이 아쉽습니다. 특히 이미지 처리는 다른 파일로 옮겨서 serializer에서는 json만 반환해주면 훨씬 코드가 깔끔했을텐데.. 코드 작성보다 리팩토링이 더 어렵게 느껴지는 만큼 처음에 파일 용도를 나누고 시작하는 게 좋을 것 같아요.
django에서 제공하는 기능들을 활용하려고 가상환경 코드를 다 뜯어보는 것도 시간이 조금 걸렸습니다.. 추상화가 편하지만 아직 낯설어요😢

설계

어느 정도 ERD와 API 시트 초안을 잡고 시작했다고 생각했는데 처음 ERD를 구성하면서 자료형에 대한 생각을 미루고 시작하니 이것 때문에 수정이 배로 늘어나서.. 파일 나누기와 함께 초기에 시간을 쏟더라도 짜임새 있게 구성하고 가면 좋을 것 같아요.

FE 코드 이해하기

프론트엔드가 마지막까지 달리는 만큼 당일 제출 시점까지 고생해서 CSS는 도와주겠다는 얘기를 했는데 외부 스타일시트가 아니라 TS에서 CSS 작업하는 건 처음이어서.. 마감이 N시간 남은 시점에서 제가 건들면 오히려 짐이 되겠다는 생각에 못 도와준 점이 아쉬운 것 같아요. CSS 뿐만 아니라 위에 Response code처럼 프론트엔드의 코드를 좀 더 이해할 수 있었으면 어떨까.. 생각하는 리액트로 단일 페이지밖에 안 만들어본 백엔드의 생각입니다.