[프로젝트 회고] 온라인 롤링 페이퍼 서비스, '서울 1반 추억쌓피'

뻔하지만 뻔하지 않게?

 

'뻔하지만 뻔하지 않은' 서비스를 만들고 싶었다. 첫 프로젝트였던 만큼 기본기에 충실하면서도 우리 팀만의 '와우 포인트'가 있는 서비스. 

1) 한 학기를 온라인으로만 보내느라 서로 대화를 많이 나누지 못한 점, 

2) 시간이 지나도 보관이 용이한 점,

3) 마지막으로 우리 팀만의 exclusive 한 느낌을 주기 위해 지정 날짜를 정해 해당 날짜 이후에만 편지함을 확인할 수 있는 점

 

이 3가지 포인트에 착안해 온라인 롤링 페이퍼 서비스를 기획했다. 

 

지정 날짜 이후에 편지함 확인하기

 

 

Django를 활용한 첫 웹 개발 프로젝트,
6주간의 여정

지난해 자바를 배웠지만, 자바 기반 프로젝트를 해보지 않았기에 (자바를 배웠다고 자신 있게 말할 수 없는 이유...) 이번이 나의 첫 웹 프로젝트였다. 자바보다 더 직관적이라고 느껴졌던 파이썬, Spring보다 훨씬 재미있게 다가왔던 Django로 첫 프로젝트를 진행한다 생각하니 설레는 마음이 컸다. 한 학기 동안 스터디를 하며 동고동락하던 팀원들과 프로젝트를 함께하는 것이라 더더욱 유의미했다. 이론으로는 알고 있어도 실제 DB를 설계하고 코드를 짜나가며 마주하게 될 오류가 반갑기도, 두렵기도 했다.

 

3명으로 이루어진 팀원 중 나는 기획, FE, BE에 모두 참여하기로 했다. 어떻게 보면 이도 저도 아닌 롤이라고 생각될 수도 있지만 우선 맛보기로 나에게 어떤 직무가 맞는지 탐색할 기회라고 생각하기로 했다.

 

프로젝트 진입 전 내가 세운 개인적인 목표는 2가지였다.

1. 직무 정하기

2. 욕심부리지 않고 기본에 충실한 기능을 구현하기

 

프로젝트 본격 돌입에 앞서 기술 스택, 아이템 및 MVP를 확정하고, 개발 상세 일정, 마일스톤 등 작업 효율을 위한 뼈대를 잡아나갔다. 초반에 git merging에서 충돌이 난 점을 제외하고는 개발 시작 전부터 프로젝트 완성까지, 우리 팀의 협업은 정말 칭찬해주고 싶다. 아마도 모두에게 첫 프로젝트였고, 그만큼 몰입했던 프로젝트여서 그랬던 게 아닐까.

 

어려웠던 점

DB 아키텍처를 견고하게 설계해야 한다는 사실을 절감했다. 기본기는 정말 정말 정말 중요하다. 롤링 페이퍼의 수신인, 발신인 관련해 모델링을 2번 이상 진행해야 했다. receiver와 sender의 역할을 하는 사용자 필드를 각각 표기해주었어야 했는데, 견고하게 설계하는 기간이 부족했다 보니 ORM 오류를 마주한 뒤에야 재설계에 성공할 수 있었다. 이미 이론으로 다 배운 내용임에도 불구하고 실전에 돌입하니 허둥지둥하느라 깔끔한 모델링 구현에 실패한 셈이다. FK의 참조 무결성이라는 개념을 다시 한번 복습하는 기회가 되기도 했는데, 장고 모델의 ForeignKeyField의 on_delete 옵션 종류에 대해 살펴보면서다. 회원 탈퇴 기능을 구현할 때는 on_delete=models.SET_NULL 로 설정해 편지가 바라보는 테이블인 User 테이블이 삭제될 때 해당 값이 null이 되게 하는 것이었다. 이 기능 역시 구현해놓고 나면 정말 별것 아닌 기능들이었으나 막상 기간에 쫓기며 나의 역할을 해내야 할 때는 그리 쉽게 느껴지지 않는다는 것... 

 

정해진 기간에 맞춰 나의 업무를 끝내는 것은 정말 중요하면서도 쉽지 않다. 앞으로 현업 개발자가 된다면 정해진 기간에 맞춰 일을 수행하는 루틴이 주가 될텐데 그런 의미에서 이번 프로젝트는 그 '초조함'을 미리 경험해볼 소중한 기회였다. 팀원에게 민폐를 끼치지 않는 수준을 넘어서 나의 코드가 도움이 되는 수준까지 꾸준히 노력하고 싶다. 

아이디 찾기 및 비밀번호 재설정 시 사용자 메일을 입력하면 해당 메일로 재설정 링크를 보내준다.

사용자 검증 구현에서 비밀번호 재설정 기능을 구현할 때 다소 챌린지하다고 느꼈다. 비밀번호 재설정 시 사용자의 이메일 유효성 검사가 진행되어야 하는데 진행되지 않았던 것이 문제였다. 사용자 검증 관련해서는 Django의 ModelForm을 사용하면 라이브러리가 알아서 해결해주었기 때문에 별도의 관심을 기울이지 않았던 게 문제라면 문제였기에 이를 해결하기 위해 이리저리 구글링, 팀원과 상의, 교수님에게 질문하여 passwordReset과 관련한 장고의 공식 문서를 탐독했다. 구글링으로 PasswordResetForm을 상속받은 커스텀 클래스는 작성한 뒤였고,  클래스 안의 함수 그리고 그 함수 안에서 email__iexact 필드, is_active 필드의 값을 판별해 조건문을 달아주는 식으로 오류를 해결했다. 이것 역시 해결하고 보면 정말 별것 아닌 오류라 여기에 적기 민망하다. 그럼에도 불구하고 공식 문서를 꼼꼼하게 탐독하는 것의 중요성, 자칫 간과했던 상속 함수 등을 자세히 살펴볼 필요성을 느꼈기 때문에 같은 실수를 반복하지 말자는 의미에서 남겨본다. 

 

잘한 점

 

스프린트를 지켜가며 활발히 협업했고 그 과정에서 역할 분담이 유연하게 이루어진 점은 잘한 점이라 꼽고 싶다. 아무래도 서로를 잘 아는 관계였고, 각자가 소통에 유연한 팀원이었던 덕분에 가능했던 거겠지만, 이런 경험을 바탕으로 '협업 근육'을 길러놓는다면 미래의 프로젝트에도 큰 도움이 될 것이라 믿는다. 

 

FE, BE를 둘 다 왔다 갔다 하며 개발을 진행했던 나에게는 이번 협업 경험이 더더욱 유의미했다. 프로젝트의 완성도를 위해서는 유연한 작업 스타일이 중요하다는 사실을 깨달았기 때문이다. 백과 프론트에서 기본적인 나의 역할을 수행한 뒤,  매 회의마다 진행 상황을 확인해가며, 혹은 마감 날짜에 가까워져서는 매일 매일 카톡으로 서로의 일정을 확인해가며 서로의 역할을 재분배했다. 누군가는 현재 작업 중인 영역에서 디테일을 신경 써야 하는 경우가 있었고, 또 누군가는 현재 작업 중인 에러에서 손을 뗄 수 없는 경우도 있었다. 그럴 때 내가 진행이 더딘 작업을 도맡아 처리했던 경우가 꽤 있었다. 내 개인의 작업에 집중하는 것 또한 무척 중요하나, 서비스의 완성도를 위해 숲을 볼 줄 아는 자세를 배울 수 있는 소중한 경험이었다. 

 

배포 후 사용자의 피드백을 실시간 반영하며 다양한 사용자의 반응을 살핀 것. 잘한 점으로 꼽고 싶기 보다는 프로젝트 통틀어서 가장 인상 깊은 경험이라 언급하고 싶었다. 미약하게나마 '이런 맛에 서비스 만드는구나!' 하며 개발자의 입장에 공감해볼 수 있었던 것?

 

아쉬웠던 점

나만의 역할을 정확히 정하고 기술적으로 깊게 고민해보는 기회는 아니었던 것 같아 아쉽다. 첫술에 배부를 순 없으니 다음 프로젝트에서는 백엔드 역할로 더 깊이 고민하는 시간을 갖고 싶다. 이번 프로젝트는 API를 사용하지도, 데이터를 활용하지도 않은 프로젝트였기 때문에 돌이켜보면 무난할 수밖에 없는 프로젝트였던 것 같다. DB 아키텍처가 훨씬 복잡해지고 다루는 데이터의 양이 늘어난다면 어떤 챌린지들이 있을까, 기대가 되기도 두렵기도 하다. 

 

AWS를 통해 배포할 때 예상치 못한 오류가 정말 많이 터졌다. 팀원의 도움을 받아 오류를 수정하고 결국 배포에 성공하긴 했지만, 누군가의 도움 없이 혼자서 배포해보지 못한 부분이 큰 아쉬움으로 남는다.

 

편지를 암호화하지 못한 점이 상당히 거슬린다. 아무래도 나의 기술적 빈곤이 문제이기 때문에 얹을 변명도 없다. 논리적이고 효율적인 방식으로 설계하는 것은 당연히 중요하다. 그러나 편지 암호화는 논리적이고 효율적인 설계와는 별개의 문제라고 느낀다. 애초에 기획 단계에서 이러한 부분을 고려하지 못한 것이 첫 번째, 고려했더라도 어떻게 구현할지 감이 오지 않았던 게 두 번째 반성 포인트다. 한 사용자는 '개발자들이 편지 내용을 볼 수 있다면 어떻게 믿고 허심탄회한 편지를 쓰냐?'는 의견을 줬는데 아무리 장난식으로 말한 피드백일지언정 앞으로 나아가야 할 방향을 확실히 알게 된 의미있는 피드백이었다. DB 암호화에 대해 공부해야겠다고 느꼈다. 꾸준하고 성실하게 공부해야겠다. 

 

보완할 점

1. 탄탄하게 기획하고 설계하기:

유저 스토리 및 유저 플로우를 더더욱 탄탄하게 기획해 개발 중간 단계에서 모델링을 다시 하거나 생각지 못했던 기능을 추가하는 식의 실수를 줄이고 싶다. SMTP의 활용 등 외부 라이브러리 등에 의존하는 경우가 더러 있었는데, google의 보안 정책에 영향을 받아 코드를 다시 짜야 하는 일이 발생했다. 이런 경우를 방지하기 위해선 기획 단계에서 더욱 탄탄하게 어떤 기능을 구현할 것인지, 예상되는 어려움은 무엇인지 미리 파악하려고 애쓰는 수밖에 없을 것이다.

 

2. 사용자 확장성:

27명의 사용자로 제한되어 있었기 때문에 더 많은 사용자가 사용하게 하려면 본인 인증 기능을 추가해야 한다.