오픈 프로젝트

제철42 🔗 https://jecheol42.herokuapp.com/

소개

42Seoul에서 진행한 오픈 프로젝트이다.
운영 목적은 올해가 지나기 전, 카뎃들에게 소프트웨어 프로젝트 산출물을 하나 이상 가지게 하기 위함이다.

8월 9일부터 23일까지 접수를 받았고, 26일에 계획발표를 했다.
10월 28일에 중간발표를, 12월 9일에 최종발표를 하기로 첫 공지가 났다.

참여 계기

프로그래밍 공부를 한 지는 꽤 됐는데, 참여한 프로젝트 하나 없는 게 마음에 걸리고 불안했다.
42서울의 과제를 열심히 해오긴 했지만, 그동안 여기 과제만 해선 안 되겠다고 생각하기도 했다.
그러던 차에 이번 프로젝트가 좋은 기회가 되겠다는 생각에 공지가 올라오자마자 꼭 해야겠다고 다짐했다.
또 친한 카뎃들, 42XX 동료들과 함께 팀 과제나 프로젝트를 해보고 싶다는 생각도 종종 했었다.

팀원 모집 및 주제 선정

42서울 본과정부터 친해진 42XX 동료들 중 현재 본과정을 진행하고 있는 7명이 모두 참여했다.

팀명은 과채파이다. GwaChaePah~ 🍋🍠🍊🍆🍑🥦🥒
팀원들 모두 42서울 슬랙 프로필 이미지가 과채류라서 지은 팀명이다.

선정된 주제는 다음과 같다.
1,2인 소가구를 대상으로 제철 식재료를 필요한 만큼 활용할 수 있는 방법을 제공하고, 양이 많은 식재료를 지역 주민들끼리 나눔 및 소분을 할 수 있는 게시판을 제공하는 서비스이다.
프로젝트명은 처음에는 철수야!(제철 수확물 이거야!)였는데, 숨은 의미가 정말 숨어있기만 하고 잘 드러나지 않는 것 같아서 후에 바꿨다.
최종 프로젝트명, 서비스명은 제철42(제철 수확물의 '제철'과 지역 주민들의 '사이'가 가까워지길 바라는 마음에 추가로 42서울에서 진행된 프로젝트임을 나타내기 위해 숫자 '42'를 사용함)이다.

기획(구현 기능)

1. 메인 페이지
   

• 이달의 제철 수확물 리스트 중 4개를 랜덤으로 보여준다.
• 새로고침을 할 때마다 바뀐다.

2. 검색 페이지
   

• 검색된 과채류의 가격정보를 제공한다.
• 게시판에서 검색된 게시글을 보여준다.
  

3. 게시글 상세 페이지
   
   
   

• 게시글 상세 정보들을 볼 수 있다.
• 게시글 작성자는 글을 수정 및 삭제할 수 있다.
• 로그인을 한 유저는 댓글을 작성할 수 있다.

4. 글 작성 및 수정 페이지
   
   

• 소분을 선택하면 가격을 입력할 수 있고, 나눔을 선택하면 0으로 설정된다.
• 이미지는 최대 3장까지 선택이 가능하다.
• 글 수정 페이지에서는 소분/나눔 태그를 완료로 바꿀 수 있다.

5. 회원가입 페이지
   

• 아이디 중복체크를 한다.
• 비밀번호를 두 번 입력해서 일치하는지 확인한다.
• 지역 정보를 입력한다.

6. 로그인 페이지
   

개발 과정

계획 대비 변경 사항

시작 전에 멘토링을 받았는데, 기간에 비해 규모가 크다는 피드백을 받았다.
규모를 줄이면서 앱을 포기하게 되었고, 그러다보니 7명은 또 너무 많지 않은가 싶었다.
하지만 이미 계획 발표가 끝나서 팀을 나누기는 힘들었고, 또 우리는 단순히 스펙을 하나 더 쌓자는 느낌보다는 새로운 언어와 프레임워크를 공부하기 위함도 컸기 때문에 그대로 진행했다.

인원이 많다 보니 프론트와 백에 각 파트를 이끌어줄 리더를 두면 좋겠다는 조언도 받았다.
그래서 inyang님이 프론트엔드를, yeslee님이 백엔드 리더를 맡았다.

최종적으로 팀원과 역할은 이렇게 결정되었다.

중간 발표까지 진행 과정

백엔드는 python에 django를 사용하기로 했다.
node.js와 django 중에 뭘 사용할지 고민했는데, 4명 중 3명이 python을 공부해보고 싶었다고 했다.
그리고 django에서 기본적으로 제공해주는 기능이 많고 자료도 많아서 빠르게 학습하고 코딩을 시작하기에 좋겠다고 판단했다.

9월에는 django 강의를 들으며 거의 실습만 했다.
사실 '이제는 코딩을 시작해야 하는데' 싶으면서도 뭐부터 어떻게 해야 할지를 몰라 방황하고 있었다.
그러다가 10월 둘째 주에 멘토링을 받고나서 해야 할 일을 찾고 순차적으로 진행할 수 있었다.

먼저 서버를 띄우고 메인 페이지에 들어갈 기능을 구현하는 것을 숙제로 받았다.
서버는 heroku를 이용하기로 했다.
42서울에서 aws에 서버를 띄울 수 있게 비용을 결제해주지만, 우리는 이 서비스를 지속적으로 운영하고 싶을 것 같다는 생각에 처음부터 무료로 사용할 수 있는 heroku를 선택했다.
메인 페이지에 띄울 제철 수확물 데이터는 mseo님께서 작업해주셨다.
이때 데이터베이스에 리스트로 데이터를 넣을 수 있다는 것도 알게 되었다.

다음으로는 서치 페이지를 작업했다.
검색된 과채류의 가격정보는 aT-Kamis에서 제공하는 open api를 받아와서 사용했다.
제공되는 데이터를 받아와 필요한 정보들만 db에 저장해서 사용했다.
여기서 문제가 있었다.
과채류의 가격정보는 하루에 한 번 업데이트 되는데, 업데이트가 된 시간 이후에 한 번만 불러와서 db에 저장하고 싶었다.
처음에는 같은 날짜의 같은 품종에 가격정보가 있으면 db에 저장하지 않는 방식으로 코드를 작성했다.
그런데 이렇게 하면 불필요하게 db에 데이터가 쌓이거나 수정되는 것을 막을 수는 있지만, api가 호출되는 것 자체는 막을 수 없었다.
적절한 방법을 찾지 못해서 멘토링을 신청해 질문했고, heroku scheduler가 있다는 것을 알게 되었다.

원하는 시간마다 원하는 명령어가 자동으로 실행되게끔 지정할 수 있다.

class Command(BaseCommand):
    def handle(self, *args, **options):
        i = 1
        date = datetime.now().date()
        while i < 5:
            put_data_to_api_table(date, i * 100)
            i += 1

Command 클래스를 작성하고 그 안에 handle 메서드에 필요한 코드를 작성한다.
그리고 그 클래스가 있는 파일을 실행시키면 된다.
put_data_to_api_table 메서드에서 open api를 호출하고 필요한 정보를 받아온다.

중간 발표 이후 진행 과정

이제 db에 있는 데이터를 api로 제공하는 작업을 해야 했다.
사실 이때부터가 진짜 백엔드의 작업이고, 그 전까지는 거의 프론트 작업만 한 것과 다름 없다고 생각한다.

아무튼 api로 프론트에 데이터를 제공하기 위해 중간 발표 전후로 django REST framework(drf)를 공부했다.
[Django]FBVs VS CBVs (함수형 뷰 vs 클래스형 뷰)를 참고하여 우리는 CBV로 작성하기로 했다.
처음에는 사용법을 잘 몰라서 mixin을 사용한 클래스, generics를 사용한 클래스, 둘 다 사용하지 않은 클래스가 다 있었다.
계속 구글링하고 사용법을 익혀가면서 최종적으로는 generics로 통일하여 작성했다.

Swagger로 문서화해서 제공하기 위해 drf-yasg를 공부했다.

그리고 게시판과 글 작성, 수정, 삭제 부분을 처리했다.
여기서 PUT과 PATCH의 차이를 제대로 모르고 작성해서 계속 문제가 발생했다.
그래서 처음에는 PUT을 PATCH처럼 사용할 수 있게 바꿨는데, 나중에 멘토링에서 용도에 맞게 쓰는 것이 좋다는 피드백을 받았다.
대신 serializer에서 read_only_fields를 지정해서 해결했다.

django의 기본 유저 모델을 사용해야 비밀번호 암호화도 별도의 처리 없이 가능하고 안전하다.
유저는 아이디와 비밀번호, 그리고 지역 정보를 저장해야 했다.
지역 정보를 추가해야 해서 따로 Profile 모델을 만들고, django에서 기본으로 제공하는 User 모델을 OneToOneField로 연결해서 사용했다.

class Profile(models.Model):
    user_key = models.OneToOneField(
        User,
        on_delete=models.CASCADE,
        primary_key=True
    )
    region = models.PositiveIntegerField(default=0)

지역 정보는 서울시 행정구역 코드가 들어있는 csv파일을 읽어서 db에 저장했다.
Region 모델에는 다음과 같이 데이터가 들어가있다.

Profile 모델의 region 필드에는 Region 모델의 code 필드와 같은 값이 들어가게 된다.

유저가 로그인을 하면 jwt(json web token)를 이용해 access token과 refresh token을 발급해서 로그인 확인을 한다.
access token이 만료되면 refresh token이 유효한지 확인하고, refresh token이 유효하면 access token을 다시 발급받는다.
refresh token도 만료되었다면, 로그인을 다시 해야 한다.

api로 데이터를 필요에 따라 제공하는 것은 마무리가 되었는데, 프론트나 관리자가 아니면 접근할 수 없게 설정해야 했다.
그래서 일단 프론트도 따로 서버를 띄우고 프론트에서만 접근할 수 있게, 접근을 해도 관리자 계정으로 로그인을 해야만 CRUD를 할 수 있게 설정했다.
view의 클래스들마다 get_permissions 메서드를 오버라이딩 해서 권한을 설정해줬다.

def set_permissions(self):
    try:
        origin = self.request.META['HTTP_REFERER']
    except:
        permission_classes = [permissions.IsAdminUser,]
    else:
        front = "https://jecheol42.herokuapp.com/"
        local = "http://127.0.0.1:8080/"
        if (origin == front) or (origin == local):
            permission_classes = [permissions.AllowAny]
        else:
            permission_classes = [permissions.IsAdminUser, ]
    return [permission() for permission in permission_classes]

최종 결과

11월 24일의 최종 발표 때까지 딱 기본 기능까지만 구현했다.
맨 처음 멘토링 이후에 규모를 줄이면서 구현할 기능도 많이 쳐냈었는데, 그때 플러스 알파로 빼 둔 기능들까지는 구현하지 못했다.

발표 결과는... 10팀 안에 들지 못했다.
이 서비스를 지속적으로 유지 및 보수를 하며 운영할 것인지 논의했는데, 여기서 멈추기로 했다.

이렇게 첫 프로젝트는 끝이 났다.

소감

팀장은 처음이라

처음 이런 프로젝트를 하게 됐는데, 팀장까지 맡게 되었다.
팀장이라는 역할이 무겁게 느껴져서 부담이 되기도 했지만, 프론트와 백 리더분들이 계셔서 점점 부담을 덜 수 있었다.
사실 그 두 분이 내 몫까지 해주신 것 같아서 부끄럽고 감사하다.
팀장의 역할이 뭔지 잘 몰랐다. 사실 지금도 딱 뭐라고 말은 못 할 것 같다.😅
또 팀원분들도 알아서 잘 해주셔서 내가 뭐.. 할 게 없었다.
사실 중간에 소통의 문제가 있긴 했다.
내가 제일 팀장으로써 부끄럽다고 생각되는 부분이기도 한데, 조금 더 일찍이 신경을 썼다면 상황을 더 부드럽게 해결할 수 있었을 것 같아서 아쉬움이 많이 남는다.
결과적으로는 잘 해결되었다. 하지만 그 과정 속에서 몇몇 팀원들에게는 그래도 조금은 상처가 남았을 것 같아서 마음이 안 좋았다.
사실 누군가 잘못한 사람이 있다기 보다는, 소통의 중요성을 잘 모르고 그저 일만 급하게 진행하려던 것이 문제였다고 생각한다.
아무튼 이번 프로젝트를 하면서 기술 외적으로도 팀원 간의 소통이 얼마나 중요한지 깨달았다.
또 팀장이라면 그런 부분을 더욱, 다른 사람들보다 먼저 신경써야 한다는 것도 알게 되었다.

멘토링을 잘 활용하자

프로젝트를 진행하며 42서울의 멘토님들께 멘토링을 받을 수 있었다.
처음에 우리한테 뭐가 필요한지도 몰랐을 때 멘토링 덕분에 팀에 맞는 계획을 세울 수 있었다.
또 뭘 해야 할지 몰라 방황할 때도 멘토링 덕분에 답답함과 불안감을 떨쳐내고 코드 작성을 시작할 수 있었다.
진행하면서도 계속 맞게 하고 있는 것인지 불안하고 자신 없을 때가 많았는데 멘토링 덕분에 길을 잃지 않고 자신감을 되찾고 쭉쭉 나아갈 수 있었다.
멘토님들의 애정어린 멘토링의 힘이 컸다.
멘토링을 여러 번 신청한 멘토님들께서는 먼저 연락을 주시면서 신경도 많이 써주셨다.
정말 무한한 감사함을 느낀다.🙏💛

깨달은 점

팀원들과 발생한 이슈나 처리해야 할 과제에 대해 이야기를 나누다 보면, 이건 이렇게 해야 할 것 같다, 아니다 저렇게 해야 할 것 같다 등의 말을 많이 했었다.
당연히 의견 차이가 나다 보니까 별 것도 아닌 상황이 심각해진 적도 있었다.
그런데 생각해보면, 어느 한 쪽도 맞다고 확신할 수 없는 것이었다.
모르니까. 모르는 부분을 가지고 이게 맞다, 저게 맞다 얘기하고 있는 것은 사실상 시간 낭비이다.
그래서 얘기를 하다보면 '왜 이걸로 이렇게 계속 얘기하고 있지?'하는 생각이 들곤 했다.
모르는 부분은 찾아보고 얘기를 나누는 게 낫다.
찾아보면 답이 금방 나오는 경우가 대부분이었다.😅

또 이번에 공부하면서 공식 문서를 열심히 읽어봤는데, 확실히 공식 문서로 공부하는 것이 좋다고 느꼈다.
제일 빠르고 정확하게 익힐 수 있는 방법이라는 생각이 들었다.
앞으로도 새로운 것들을 많이 공부하게 될텐데, 이전에는 그저 막막하다며 많이 불안해하고 스트레스 받았을 것 같다.
하지만 이제는 상황을 빠르게 받아들이고, 뭐가 필요한지, 어떤 것을 공부해야 하는지 빠르게 찾아서 공부를 시작할 수 있을 것 같다.
프로젝트를 잘 마무리하면서 얻은 성취감으로 그렇게 할 수 있는 자신감을 얻었고, 또 효율적인 학습을 하는 방법도 알게 되었다.

아쉬운 점

아무것도 모르는 상태로 시작했더니 욕심만 넘쳤던 것 같다.
기획 단계에서 구현하고자 한 기능이 너무 많아서 멘토링 이후에 앱도 포기하고, 기능도 많이 줄이게 되었다.😢
처음 방황한 기간이 길어서, 그 기간을 줄였다면 마이페이지까지도 구현할 수 있지 않았을까 싶은 아쉬움이 남는다.

그리고 10월에 사회적 거리두기 4단계라 18시 이후에는 접종완료자를 제외하면 2명까지만 모일 수 있었는데, 백엔드 4명 중 접종완료자가 한 명밖에 없었다.
18시 이후에는 모두 모일 수가 없어서, 결국 아침 일찍부터 모여서 18시까지 진행하게 되었다.
9시까지 모이다가 다들 너무 힘들어해서 10시로 늦추기도 했지만, 거의 3주 동안 쉬는 날 없이 생활패턴도 바꿔가며 그렇게 모였다는 점이 다들 대단하고 참 고생 많았다는 생각이 든다.👍

그리고 중간 발표 이후에 갑자기 최종 발표일이 12월 9일에서 11월 24일로 2주 넘게 앞당겨졌다.😱
그 날 발표한 팀들 중 10팀을 뽑아 12월 1일부터 3일까지 하는 이노콘에서 오프라인 부스를 설치해준다고 했다.
사실상 10팀 안에 들지 못하면 11월 24일이 끝이기 때문에 갑자기 프로젝트 마감일이 2주가 넘게 당겨진 것이다.😠
솔직히 많이 당황스러웠다. 계획에 차질이 생겨 더 바삐 움직여야 했다.🤯
중간 발표 때까지 버닝 주간으로 잡고, 발표 이후부터는 조금의 여유를 가지려고 했는데 그럴 수 없었다.😨
그래도 이때부터는 6시 이후에도 백엔드 4명뿐 아니라 프로젝트 팀원 전체가 모일 수 있다는 게 그나마 다행이었다.😮‍💨

마치며...

최종 10팀 안에 들지 못해서 아쉽지만 그리 속상하진 않다.
결과도 결과지만, 과정이 좋았다.😊
42서울의 과제들 대부분은 숙제를 하는 느낌이었던 것 같다.
부끄럽지만 단순히 통과만을 위해 진행했던 과제도 있었다.
그런데 이번 프로젝트에서는 주어진 것을 풀어가는 게 아니라 뭘 해야 하는지, 어떻게 해결해야 하는지 모두 스스로 찾고 학습해서 더 뿌듯하다.
팀원들 모두 너무나도 열심히 프로젝트를 진행했고, 다들 얼마나 고생했는지 잘 알고, 또 나 자신도 많이 성장했다고 느껴서 후회도 없고 만족스럽다.😉

체력적으로는 어마어마하게 힘들었지만, 성취감은 더 어마어마하다!
좋은 팀원들과 함께 해서 행복했고 모든 것에 감사하다.💛
다시는 이런 경험을 하지 못할 것이다.
jkeum 이렇게 또 성장했다~!🏋️‍♀️

과채파 짱 제철42 짱 🧡