개요

빅프로젝트는 총 7주차에 걸쳐 진행되지만 1~2주차는 주제 선정 및 구체화, 6~7주차는 산출물 작성 및 발표회에 소요되다보니 실제 개발 기간은 3주 정도이다.

길다면 긴 시간이지만, 순조롭게 진행되다가도 오류 하나 고치는데 하루를 통째로 날리는 등 개발 진척이 더뎌지는 순간이 많고, 매주 2회 코치님에게 진행도를 발표하는 것을 준비하는 시간도 만만치 않기 때문에 정말 촉박한 일정이었다.

개발에 대한 내용을 쓰자면 한도 끝도 없으니 개발 중 어려웠던 점을 위주로 작성해보려고 한다.

어려웠던 점

코드 관리 (git)

브랜치 관리 미숙

우선 나를 포함한 팀원 모두가 git 사용에 그다지 익숙하지 않다보니 사용과정에서 많은 에러(?)가 있었다.

처음에는 기능 하나의 구현이 끝나고 정상 동작되는 것이 확인 되면 develop 브랜치에 merge하는 식으로 관리를 했는데 merge 후 checkout을 빼먹고 그대로 develop에서 작업을 해버리거나, 오류가 있는 코드를 테스트 없이 merge하는 등 브랜치 관리가 원활하게 이루어지지 못했다.

하지만 점점 모두 git 사용에 익숙해져서 개발 막바지 쯤에는 이런 문제가 거의 발생하지 않았다. 역시 써보면서 익숙해지는게 최고의 학습 방법인 것 같다.

.gitignore 설정 누락

프로젝트 시작하기전에 미리 .gitignore를 설정하여 모델 파일이나 이미지 파일 등이 업로드 되지 않도록 해야하는데, 처음 할 때 대충 작성했다보니 누락된 폴더나 파일이 git에 등록되는 문제가 있었다.

가장 문제가 됐던 것이 이미지 파일인데, DB에 이미지 파일의 로컬 경로를 저장하는 방식이었다. 때문에 pull 한 번하면 로컬 이미지 파일들이 모두 덮어씌워져 DB가 찾는 경로에 이미지가 존재하지 않게되고, 홈페이지가 엑박으로 도배되는 진풍경을 볼 수 있었다.

결국 문제가 된 폴더를 싹 지우고 커밋한 다음 다시 만들 때 .gitignore를 작성해 사용하는 식으로 해결했다.

conflict

처음에는 같은 기능에서 구현해야하는 페이지를 쪼개어 각자 기능을 개발하였는데, 해당 페이지에서만 작업을 하는게 아니라 상태를 넘겨주는 이전 페이지도 함께 변경해야하는 경우가 잦았다.

이로 인해 두 명 이상이 같은 코드부분을 수정하게되서 바로 충돌이 발생했고, 여기서 잘 소통이 되지 않으면 잘 못된 충돌 해결로 인해 또 오류가 발생하는 문제가 생겼다.

나중에는 서로 다른 기능을 개발하거나, 같은 기능이라도 최대한 서로에게 영향을 주지않는 기능을 맡아 진행하여 이러한 conflict 발생을 최소화 할 수 있었다.

백엔드와의 연동

잦은 DB 구조 변경

ERD를 작성하긴 했는데, 개발 도중 필요해지는 테이블 및 컬럼이 계속 추가/변경되면서 백엔드와 새로 연결할 때마다 어려움이 있었다.

그럴 때마다 DB 스키마 전체를 Drop한 뒤 아예 새로 만들어서 migrate부터 진행 하였는데, 이게 은근히 귀찮고 시간을 많이 잡아먹었다.

이러한 문제 없으려면, 결국 처음 프로젝트를 설계 할 때 구현해야할 모든 기능을 고려해서 확실하게 ERD를 작성해야 할 것 같다. 왜 애자일이 대세인 지금도 폭포수 모형을 들고와 애자일과 혼합해서 쓰는지 어느정도 알게된 계기 였다.

트러블 슈팅

공유 및 기록 미숙

에러가 발생하고, 이를 해결했다면 그 내용을 기록하고 공유했어야 했는데 그러지 못했다.

프로젝트를 진행하며 분명 어디선가 본 오류가 다시 발생하는 것을 수없이 겪었는데, 그 때마다 뭐 기록해놓은게 없다보니 처음부터 해결해야해서 많은 시간이 소요되었던 것 같다.

시간에 쫓기면서 개발하느라 그냥 급하게 에러 고치고 후다닥 넘어갔던 것 같은데, 앞으로는 아무리 바빠도 에러가 왜 발생했는지, 어떻게 고치는지 정도는 간단하게 정리해두고 팀원과 공유하는 시간을 가져야 할 것 같다.

좋았던 점

스크럼 회의

아무리 시간이 촉박해도 매일 아침, 저녁에 진행하는 15분 스크럼 미팅을 빼먹지 않았다.

마감 회의에서 각자의 진행상황을 공유받을 수 있어 내일 무엇을 해야할 지 파악하는것이 쉬웠고, 시작 회의에서는 내가 할 일과 팀원들에게 최우선적으로 해야 할 일들을 명확하게 말 할 수 있다는 점이 정말 좋았다.

바쁜 일정에도 일정 관리가 비교적 잘 이루어질 수 있었던게 스크럼 회의 덕분이 아닐까 싶다.

열정 넘치는 팀원들

사실 빅프로젝트 기간과 해커톤 기간이 겹치는 바람에 3주의 기간 중 2주차까지 수업 시간 외에 따로 시간을 투자하는 것이 어려웠다. 때문에 오늘 끝내야 하는 개발을 마치지 못하면 다음날로 미뤄지는 등 점점 해야할 일이 쌓이기 시작했다.

결국 해커톤이 끝난 3주차 째에는 거의 수업시간과 상관 없이 매일 밤 늦게 새벽까지 코딩을 하는 강행군이 지속되었다. (특히 프론트엔드)

거기다 의사소통의 효율을 위해 이 기간동안 매일같이 팀원 모두가 모여 대면으로 개발을 진행했는데 1시간 넘게 걸리는 거리를 매일 오면서도 불만을 가지지 않던 팀원들에게 너무 감사했다.

팀원들 모두가 고생한 결과, 결국 마감일에 맞춰 서비스와 산출물이 모두 완성될 수 있었다고 생각한다.

앞으로 해야할 일

클린 코드

다들 너무 시간에 쫓기느라 컨벤션 같은 것을 전혀 고려하지 못하고 기능을 개발하였다.

산출물 작성 시간에 나름 코드를 정리해보려고 했는데, 정작 나도 클린 코드에 대한 지식이 없어 주석을 추가/제거하거나 console.log를 지우는 정도 말고는 딱히 할 수 있는게 없었다.

코드가 동작하는 것만큼 코드의 유지보수성, 가독성도 정말 중요하므로 클린 코드를 공부해서 내가 과거에 짰던 스파게티 같은 코드들을 리팩토링하고 싶다.

백엔드 맡아보기

사실 나는 백엔드 웹 개발자를 지망하고 있었는데, 지금까지 진행한 프로젝트에서는 팀에 프론트를 잘 아는 사람이 없다보니 프론트엔드 개발을 담당하게 되었다.

프로젝트를 마무리하고 포트폴리오나 자기소개서를 작성하면서 백엔드 개발 경험이 정말 없구나 라는 것을 새삼 느꼈다.

때문에 가능하다면 작은 프로젝트라도 백엔드 부분을 맡아서 경험하는 기회를 가져봐야 겠다.