Wecode 1차 프로젝트 후기(Brokurly Team)

seyong·2021년 12월 12일

Project

목록 보기

1/3

🚩 References

이 프로젝트는 마켓컬리 사이트를 참고하여 학습목적 으로 만들었습니다

이 프로젝트에서 사용한 이미지는 모두 unsplashed 에서 가져온 이미지입니다.

저는 백엔드 개발자로 이 프로젝트를 진행하였습니다.

1. 프로젝트 소개 및 목적

📣 소개

Brokurly는 마켓컬리 사이트를 모티브로 하여 진행한 클론프로젝트로
유기농 채소, 샐러드, 과일, 선식을 판매하는 사이트입니다.

Team Member

 brokurly_team = {
 "Front-end" : ["김성현", "구유진", "홍정빈"],
 "Back-end" : ["박세용", "성종호", "제갈창민"]
 }

Project Github
- 👩‍💻Front-end Github
- 👨‍💻Back-end Github

Development period
- 2021년 11월 29일 ~ 2021년 12월 10일 (약 11일)

Technologies stack(Back-end)
- Development tools
  - Python 3.8.1
  - Django Web Framework 3.2.9
  - bcrypt 3.2.0
  - PyJWT 2.3.0
  - MySQL
  - ERD : dbdiagram.io
  - httpie
  - AWS EC2, RDS

Collaboration tool
- git, github
- Trello
- Notion
- Slack

👨‍🏫 데모 영상

목적 (Back-end 기준)

신선 식품 전문 온라인 쇼핑몰인 마켓컬리 사이트로 클론프로젝트를 진행함으로써 기획단계에서의 데이터모델링설계 및 회원가입, 로그인, 장바구니, 메인페이지, 제품상세페이지, 주문내역 및 상태 페이지 등 커머스 사이트의 핵심적인 기능을 구현하고 개발역량을 기르는것을 목표로 하였습니다.

2. 구현사항

다음 구현사항중에서는 색깔표시가 된것이 제가 맡은 부분입니다!

회원가입 API

로그인 API

메인페이지 API

상품 상세 페이지 API

주문내역 API

장바구니 API

core app/ validator(회원가입시 유효성 검사), authorization(인가) 구현

훌룡한 팀원들과 함께 한 것들

dbdiagram.io 기반으로 팀원들과함께 데이터 모델링
모델링 한것을 기반으로 app 을 어떤것을 만들지 함께 고민하고 선정
각 app안의 models.py 작성 (모델링한것을 참고하여)
db_uploader.py 작성
CSV 파일 작성
프론트와 통신할 때 맞출 공동 key 값 정하기
API 기능 정의서 작성

진행과정

Django project 초기세팅 ➡ DB 모델링 ➡ models.py 작성 ➡ 공동 key 값 작성 ➡ 각자 맡은 views.py작성 ➡ API 기능 정의서 작성 ➡ postman 및 httpie로 자가통신 ➡ 프론트와 통신 후 에러 고치기 ➡ 공동 key값 안맞는 부문 및 models.py 수정 ➡ CSV파일로 실제사용할 data업로드 ➡ 최종 통신 ➡ AWS EC2 및 RDS 이용하여 배포

모델링

모델링은 백엔드 동료들과 함께 고민하여 작성하였고 기획단계에서부터 가장중요한것이 바로 이 모델링이라고 생각하였습니다.
모델링이 잘못되면 앞으로 진행하는 모든것에 영향을 끼치어 원할한 프로젝트 진행이 어렵게될수도있고, 불 필요한 수정작업을 여러번 거칠수있는 위험이 있었기에 모델링을 정말정말로 신중하게 생각하여 진행하였던것같습니다. 시간이 걸려도 좋으니 모델링 만큼은 확실하게 정리해보자라는 마음가짐으로 모델링을 하였으나... 결국 3~4번정도의 수정을 거쳐서야 최종 모델링이 완성되게 되었습니다. 언젠가는 한번에 깔끔하고 모범적인 모델링을 구성할수있는 실력이될때까지...❕❕❕

아래사진과 설명은 최초 작성하였던 모델링부터 여러번 수정을 거쳐 완성된 최종본의 모델링을 완성하게된 저희의 작업과정입니다.

최초 모델링 (2021.11.29)

장바구니(cart)와 주문서(order)의 사용 목적과 구분이 명확하지 않아 어려움에 부딪힘 계속 고민하다 도저히 감이 잡히지않아 멘토님께 도움을 구하였고 리뷰를 받음.
주문을 할 때, 주문목록은 1개의 row로 작성되므로 이에 착안하여 'order_list' 테이블을 추가 생성
대분류(menus)는 제외하고 우선적으로 하위 테이블들을 먼저 구성

2번째 모델링 수정 (2021.11.29)

field 값 설정 전 테이블별 위치 변경(좀더 직관적으로 이해하기위해서)
테이블 네이밍 수정
대분류(menus) 테이블 추가

3번째 모델링 수정 (2021.11.30)

field 값 수정 및 FE와의 key값을 고려하여 테이블별 key값 재조정

4번째 모델링 수정 (2021.11.30)

(멘토님께 전반적으로 잘 구성하였고 정규화도 잘했다고 칭찬을 받으면서 시작하였다 ㅎㅎ...)

여기서부터는 멘토님들께 피드백을 받아 다시 수정하였습니다.

price 와 weight 는 int 대신 decimal field 로 적용
'user_id' >>> 'user_name' 으로 수정
'product_quantuty' >>> 'quantity' 로 수정(product 도 제거)
테이블 관련 수정사항 ⏬
- order >>> order_items
- order_list >>> orders
- status >> order_status & order_items_status

🛑 수정 사항 종합

orders 와 order_items 로 table 을 대폭 개편하여 , orders 에서 user 의 id를, order_items에서 product의 id를 각각 갖도록 수정함

이에 따라, 단일 table 이었던 status 도 order_status, order_items_status 로 각각 분리함

각 column 별 수정 사항

order 에서 user의 id를 orders로 넘겨주고, order_list column을 삭제

orders 를 참조하도록 orders의 FK 부여

status 를 order_items_status 로 수정, tracking_number 를 추가

orders 에 orders_status(스샷 오타 수정) FK 부여

create_at 과 update_at 은 core app 에서 추상 부모 관계로 상속시킬지라도, 모델링에서는 각 테이블 마다 표시해 주어야 한다.

마지막 모델링(진짜 최최최종본)(2021.12.05)

멘토님들께 리뷰를 받고나서도 수정사항이 생기게되어 계속 수정하게 되었습니다... 여러번 시행착오를 겪고나서 마지막으로 완성된 모델링입니다. (정말 모델링은 어렵고도 중요하다는 걸 다시금 깨닫게되었죠)

내가 담당한 기능구현

회원가입 API (POST) / users.app 안에서 작성
- 회원가입시 입력한 아이디(username), 이메일(email) 중복체크 하는 별도의 함수를 만들어 작성
- 유효성검사(username,email,password)는 창민님이 별도의 core app안의 validator.py 를 만들어 그안에서 작성한것을 import 해와서 사용하는 방식으로 하기로 함
- 회원가입시 입력한 password는 bcrypt로 암호화 하여 DB에 저장
- 입력받은 data 값들이 중복체크 및 유효성검사 통과 그리고 암호화까지 성공하였다면 create 하여 DB에 새롭게 생성하고 저장.
- 통신 진행시 발생할 수 있는 다양한 에러메세지 핸들링

username, email 중복체크 검사 함수 / 유효성검사 import

회원가입 View

여기서 멘토님의 라이브 코드 리뷰를 받았을때, 멘토님께서는
core.app을 따로만들어 그안에 validater를 만들어 유효성검사를 하는것대신에 회원가입 view 클래스 안에 작성해주어도된다고 하셨다..
아직 클래스에 대한 이해도가 부족한 나로서 당시 코드작성시에는 미처 그 생각을 하지 못했던것 같다..
프로젝트 진행시 각자 어느 기능을 맡을 것인지 역할분담을 할때 효율적으로 역할을 나누기위해 회원가입시 유효성검사와 로그인 데코레이터 기능을 같은 팀원인 창민님이 맡아서 하기로하였는데, 이때 core.app 을 따로만들어 그안에 유효성 검사, 데코레이터 기능을 넣기로 하였다...
물론 우리가 기획한 의도는 잘못된것은 아니나, 다음에는 그렇게 해보는것이 어떻겠냐고 피드백을 받았다!!

2차 프로젝트 때는 피드백주신내용을 기억하여 SignUp 클래스 안에 유효성검사와 중복체크 함수를 한번에 작성해야겠다고 다짐했다 ❗

로그인 API (POST)
- 로그인시 DB에 저장된 data와 일치하는지 확인 후 틀릴시 에러메세지반환
- jwt를 활용하여 로그인성공시 token 발행

로그인 View

로그인 View에서 가장 기억나는 것은 바로
Authorization 이다.
처음에는 토큰을 발행하는 변수명은 "access_token" 이였다.
하지만 다른 팀원분이 데코레이터 코드를 작성하면서 변수명을
authorization 으로 바꾸었고 나역시 똑같이 변수명을 수정해주었다.
문제는 프론트 팀원분들과 통신을 진행하면서 생겼는데, 바뀐 변수명을 프론트분들께 알려주지 못하여 통신을 하는데 자꾸 key error 가 발생되는것이였다!! 코드만 작성하느라 바빠서 중간에 바뀐 변수명을 전달해야함을 까맣게 잊고 key error 의 원인을 찾는데 많은 시간을 소요했던것같다. 결국 프론트 쪽에서도 토큰을 페이지마다 넘겨줄때 authorization 으로 키값을 맞추게되었다.. 하지만 멘토님께서 코드리뷰를 해주실때 Authorization 은 맨 앞에 대문자 'A' 를 쓰는게 국룰이라고 바꾸라고 말씀해주셨다... 결국 다시 맞춘 키값을 수정하는 일이 발생되었다... 만약 백엔드 쪽에서 이런 국룰적인 부분을 미리 알고 프론트쪽에도 확실의 전달해주어서 처음부터 Authorization 으로 키값을 맞추었다면 시간을 훨씬 절약할수 있었을텐데... 라는 아쉬움이 남는다..

2차프로젝트때는 절대 이런 실수를 하지않으리라 이글을 쓰면서도 다시한번 다짐하는 바이다..._🙇‍♂️

한가지 더 !

Authorization = jwt.encode({'id' : user.id}, SECRET_KEY, algorithm = ALGORITHM).decode('utf-8')
            return JsonResponse({'ACCESS_TOKEN' : Authorization}, status = 200)

이 부분에서 맨뒤에작성한 decode('utf-8') 이 decode 코드는 원래 처음에는 작성하지 않은 코드인데, 프론트와 통신하면서 token 관련 에러가 계속 발생되기에 오류를 해결하고자 추가한 코드였다.

나의 최초작성시에 생각은 어차피 발행한 토큰은 데코레이터쪽에서 프론트쪽에 넘겨줄때 다시 decode 시켜서 넘겨주는 것이라 생각하여 굳이 encode 한것을 다시 decode 시켜줄 필요가 없다고 느껴 작성하였다.

jwt의 결과물은 pyjwt의 버전에 따라 bytes(ver. 1.7)타입 또는 str(ver. 2.0 이상)타입 으로 나오게 되는데, 파이썬에서 str을 encode 하면 bytes(이진화) 되고, Bytes decode를 하면 str 화 한다. 오류를 해결할 때
jwt 토큰을 만든것을 bytes화 시킨 후 다시 str화 하여 프론트 쪽에 넘겨주는것이라 생각하여 저 코드를 추가한것이였다.

추후 aws로 배포를 하면서 다시금 token 쪽에서 문자열 디코드할수없다는 에러가나오게 되면서 수정하기위해 코드를 살펴보고 깨닫게되었다.

데코레이터에서 이미 decode 하여 원래상태가 문자열인데 거기에서 다시 문자열 화 시켜주는 decode코드를 뒤에 작성하여서 에러가 발생한것이다.
Authorization = jwt.encode({'id' : user.id}, SECRET_KEY, algorithm = ALGORITHM).decode('utf-8') 뒤에 decode('utf-8') 를 제거해주니 오류가 해결되었다.

내가 처음에 생각한 부분이 맞았던 것이였다! ..라고 확신하고싶다..ㅠㅠ
~~이 부분은 멘토님께 다시한번 물어봐서 정확히 이해한다음 내것으로 만들 예정이다.~~
사실 이 부분은 아직도 내가 생각한 것이 맞는지 확신을 내릴수 없다..
그만큼 jwt토큰과 encode, decode 에 대한 이해도가 부족하여서 그렇다고 생각한다. 더 공부하고 추후 이런상황이 발생했을 때 스스로 확신을 내려서 코드를 작성할 수 있도록 노력해야겠다.

장바구니 API (POST, GET, PATCH, DELET)
- 메인페이지, 상세페이지에서 장바구니를 담는 POST 구현
- 장바구니 페이지로 이동시 담은 상품들을 보여주는 GET 구현
- 장바구니 페이지에서 저장되있는 수량을 수정하는 PATCH 구현
- 장바구니 페이지에서 전체삭제, 선택삭제 한개씩 삭제하는 DELETE 구현

장바구니 View - POST (장바구니 담기,생성)

POST 함수를 작성할 때 가장 기억나는것 은

바로 get_or_create 이다.
그 이유는 이 메서드를 사용하여 코드의 가독성을 높이고, 장고에서 제공해주는 메서드를 상황에 알맞게 사용해보았다는점과 이를 사용하면서 이해부족으로 에러가 발생하고 또 그것을 해결하기위해 깊은 고민을 하여 결국엔 에러를 해결했기 때문이다.

에러 내용은 이렇다.
장바구니 목록에 없는 상품을 담을 때는 문제가없이 잘 담기는데,
기존에 담겨있는 상품을 다시 담으면 장바구니 목록에 수량이 0인 상태로 담겨지는 오류가 발생하게된것이다.
아래코드는 오류가 발생된 최초 작성한코드이다.

 cart, created  = Cart.objects.get_or_create(
                user_id    = request.user.id,
                product_id = product_id,
            )

            if not created:
                cart.quantity += quantity
                cart.save()

            return JsonResponse({'messages' : 'SUCCESS'}, status = 201)

해당오류는 깊은 고민에 걸쳐 아래와 같이 수정하여 오류를 해결하였다.

cart, created  = Cart.objects.get_or_create(
                user_id    = request.user.id,
                product_id = product_id,
            )
                #Cart에 해당 값이 있고, 생성되지 않을경우 quantity값을 업데이트
            if not created:
                cart.quantity += quantity
                cart.save()
                return JsonResponse({'message' : 'SUCCESS'}, status = 200)
            #위의 if 조건을 거치지 않았으므로 생성 되었고 프론트에서 받아온 quantity값이 해당 객체의 quantity값
            cart.quantity = quantity
            cart.save()

            return JsonResponse({'message' : 'SUCCESS'}, status = 201)

만약 새롭게 생성되는것이 아니라면, 기존 수량을 누적하여 더한 후 저장하고, 그다음 return문을 작성하여 구분해주었다. 그리고나서
이 if 조건을 거치지않으면 (기존 장바구니목록에 있는 상품이 아니라 새롭게 추가하는 경우 일때)
새롭게 담은 장바구니 수량을 그대로 저장해주는 코드를 밑에 작성후 return 해주는 것으로 수정하였다. 해결하고나니 get_or_create 에 대해서 더 잘 이해가된거같아서 뿌듯하였다 😙

장바구니 View - GET (장바구니 목록조회)

GET 에서는 select_related 와 리스트 컴프리헨션을 사용하여 작성한것이 가장 기억에 남는다.
select_related 는 해당 객체가 참조하고있는 () 안에 들어가는 것들을 다 불러온다는 의미로 이해하고 사용하였다. 하지만 아직 부족한 상태이다. 반 정도만 이해한 상태로 사용한 듯한 느낌이 들어서 시간이 되는대로 좀 더 깊게 파서 공부해볼것이다.

리스트 컴프리헨션은 파이썬의 꽃이자 직관적으로 리스트를 생성하는 방법인데, 사용하기 전에 해당 코드부분이 2중 for문으로 작성되어, 작성하면서도 약간 기분이 나빴다. 그래서 작성 후 다시 살펴보며 리스트컴프리헨션으로 작성될수 있을 것 같아 사용하였다.
역시 리스트 컴프리헨션을 사용하고나니 코드가 좀 더 직관적이고 가독성이 높아진것 같아 기분이 좋았다 👦

         #해당 카트가 참조하고있는 product를 다 불러오고 필터링은 해당유저와 cart유저값이 맞을경우
        carts  = Cart.objects.select_related('product').filter(user = request.user)
        result = [{
            'cart_id'         : item.id,
            'quantity'        : item.quantity,
            'product_id'      : item.product.id,
            'product_price'   : item.product.price,
            'product_package' : item.product.package,
            'product_name'    : item.product.name,

            #해당 product를 참조하고있는 이미지의 0번째인덱스의 url을 product_image에 담아줌
            'product_image'   : item.product.image_set.all()[0].url

            #해당 카트의 프로덕트가 여러개일수 있으므로 반복문 돌려서 해당 아이템을 하나하나 꺼내서 딕셔너리형태로 값을 담아줌
            } for item in carts.select_related('product').all()]
        return JsonResponse({'result' : result}, status = 200)

장바구니 View - PATCH (장바구니 수량 수정)

특정 자원이 가지는 속성을 변경할 때 PUT, PATCH 두 메서드를 모두사용할수있지만, 이 경우에는 PATCH를 사용하였다.
왜냐하면, PUT은 Data에서 하나의 필드만 업데이트 하더라도 항상 모든 필드값을 가져와서 모든 필드를 항상 새로운 값으로 교체하는 반면에
PATCH는 Data에서 하나의 필드값을 업데이트 시킬때 해당 필드값만 가져와서 해당 부분만 업데이트 하기 때문이다.
여기에서는 cart의 quantity만 업데이트 해주면되기 때문에 PATCH를 쓰는것이 더 적절하다고 판단하였다.

#프론트에서 받은 카트id값과 맞는 Cart객체를 가져옴
cart = Cart.objects.get(id = data['cart_id'])
            
#가져온 Cart객체의 quantity를 프론트에서 받아온 quantity로 업데이트
 cart.quantity = data['quantity']
 cart.save()

 return JsonResponse({'message' : 'SUCCESS'}, status = 200)
        
 except KeyError:
 return JsonResponse({'message' :'KEY_ERROR'}, status = 400)

장바구니 View - DELET (장바구니 삭제)

DELETE 에서는 전체삭제, 선택삭제, 개별삭제 이 3가지가 다 이루어져야했다. 이것을 가능케하기위한 핵심코드는 id__in = data['cart_id'] 이다.프론트에서 받아온 cart_id 를 필터링하여 맞는 조건만 삭제해주도록 코드를 작성하였다.

🎉 잘한 점

데이터 모델링을 팀원들 함께 고민하여 멘토님께 칭찬을 받은 것 !

멘토님의 "모델링을 잘 구성하였다. 특히 정규화된 부분을 칭찬하고싶다👍" 라는 호평을 듣고 3일동안 모델링에 투자한 보람을 느끼게되었다 ㅎㅎ
목표한 필수기능을 기간내에 구현한 것 !

11일 정도의 짧은기간에 각자 맡은 필수구현기능을 성공적으로 구현해냈다는 점이 매우 뿌듯하였다!! 특히 처음 프로젝트 플래닝미팅에서 프론트엔트 백엔드 모두가 서로 지나친 욕심으로 다른 팀원을 배려하지않고 혼자만 질주하는 모습은 보이지않기로 얘기하였는데 이 부분이 프로젝트가 끝날때 까지 잘 지켜져서 좋았다. 처음에는 "과연 이걸 기간내에 할수 있을까?" 라는 의심으로 시작되었지만 프로젝트를 진행하면서 점점 "다 할수있겠는걸?" 라는 생각으로 점차 바뀌면서 끝에는 "충분히 할 수 있었다" 라고 느끼게 되었다.
git commit message를 구체적으로 잘 작성한점

커밋메세지를 작성할 때 보기 편하게, 구체적으로 잘 작성하였습니다.👨‍🎓
프론트엔드와 활발한 소통 및 협업도구 를 잘 이용한 것

맨 처음 미팅부터 프로젝트를 진행하면서 가장 지켜야 할것들을 얘기하는데 1순위를 소통으로 정하고 시작하였다. 통신을 할 때 필요한 key를 처음부터 프론트와 백엔드 서로 소통하면서 맞추었고 그것을 노션페이지에 잘 정리해두어 추후 문제가 일어나지않게 노력하였고, 각자 코드를 작성할 때에도 서로 궁금한 점이나 맞춰나가야할 부분이 생기면 그 즉시, 소통하여 노션에 계속 기록을 남겼다. 1차프로젝트 최종 발표에서 다른팀들은 아쉬운점으로 프론트-백 간의 키 값과 받는 데이터 형식이 맞지않아 문제가 생겼던점을 말하였는데, 그에 반하여 우리팀은 다른 팀의 아쉬운점이 잘한점이 되어서 기분이 매우 좋았다! 트렐로, 노션, 슬랙메세지를 항상 강조하며 원활히 이용한것도 한 몫을 한것 같다.

소통이 잘되서 엔드포인트도 단 한번도 수정하지않았다는사실😋
팀의 분위기

말이 필요없이 최고였다. 프론트/백엔드 서로 이등분하여 진행하였기 보다
그냥 한팀으로 움직인 느낌이였다. 서로 힘든부분이 있으면 속 시원하게 털어놓고 해소하였고, 그 상황에 맞게 도와줄 일이있으면 서로 나서서 도와주었다. 잠도 잘 못자서 다들 피곤한 상태였을텐데 최대한 티 내지않고 긍정적이고 밝은 분위기를 만들어가려는 모습들이 보였다.
나 또한 코드를 장바구니 API 코드를 작성하는데 막막하여 힘들었었는데 같은 백엔드 팀원인 종호님, 창민님이 거리낌없이 함께 고민해주고 이해가 안되는 부분은 이해가 될때까지 함께 공부하는 모습을 보고 감동을 많이 받았다. 우리팀 최고!!😊

😥 아쉬운 점

API 기능 정의서를 좀 더 잘 작성하지 못한것

우리팀의 경우 구글 스프레드시트에 API기능정의서를 작성하고 서로 공유하였는데 , 백엔드 3명이 최대한 고민 또 고민을 하여 작성하였지만 아무래도 처음 작성하는 부분도 있고, 백엔드끼리는 알고있지만, 프론트는 모르는 내용을 최대한 알기쉽게 전달해야하는데 그런부분을 잘 문서에 녹여내지 못한것이 아쉽다. 프론트 분들이 API기능정의서를 보고 우리에게 자주 찾아와 물어보는것을 보고 추후에는 좀 더 문서를 작성할 때는 알아보기 쉽게 잘 작성해야겠다는 생각을 절실히 느꼈다.

추가 구현사항을 못 한것

마지막 회고 미팅 때 필수구현기능은 성공적으로 잘 해내었지만,
추가구현기능을 제대로 못해본 것이 아쉽다고 하였다.
나 역시 마찬가지였으며 , 리뷰-대댓글 기능을 구현해보고 싶었지만 실력의부족함과 기간의 촉박함으로 인해 하지못한것이 아쉬웠다. ㅠㅠ
아마 처음 진행해보는 프로젝트라 정신이없어 기간을 구체적으로 예상하지못했기 때문이라 짐작한다.
2차프로젝트는 반드시 추가기능구현사항을 구현해보자고 으쌰으쌰 하였다!

코드를 작성할 때 침착하지 못한 것

당시 코드를 작성할 때는 뭔가 기간의 압박감에 못이겨 코드를 빠르게 작성하려고 하였다. 그래서 멘토님의 라이브리뷰 세션 때 수정한 코드들이 꽤 많았다. 작성하면서도 코드가 길어지고 뭔가 중복이 될 거 같다 싶으면 모듈화를 하거나 함수를 만들어서 응용해야 하는것을 머리속에서는 간간히 떠올리면서도 실천하지 못하였다.
코드를 리뷰할 때 이런 생각한 것들이 그대로 멘토님의 입을 통해서 나오게 되었고 가이드를 받아 다시 작성하긴 하였지만, 지금 완성된 코드와 처음 써놓은 코드를 비교해보면.... "어우..." 라는 소리가 절로나온다..
2차 프로젝트에서는 읽기쉬운 가독성좋은코드, 확장성을 고려한 코드, 재사용성을 고려한 코드를 작성하도록 노력할 것이다!!!!!!!!!!!!!!

프로젝트를 하면서 느낀 점

처음 진행해보는 프로젝트여서 각자 많이 서툴기도 하고, 체력의 한계를 느껴보기도 하였을텐데 그럼에도 불구하고 밝은 미소와 긍정적인 생각, 원활한 소통, 서로에게 웃는 모습을 보며 프로젝트는 개발실력을 늘리는것 뿐만 아니라 사람자체를 성장시킬수 있다고 느끼게되었습니다.

프로젝트 기간에 우리팀 뿐만 아니라 함께하는 41명의 동기 모두가 팀 상관없이 각자 어려운부분이 있으면 발 벗고 나서서 도와주는 모습을 보며 얼굴에는 티나지않았겠지만 내심 속으로 감동을 많이 받았습니다 😂

서로에게 좋은영향력을 끼치어 좋은 사람이되고 , 좋은 문화를 만들고, 더 잘하는 개발역량을 만들수있는 기간이었다고 생각합니다.

나 역시도 코드를 잘 작성하지못하여 이해력이 다른분들보다는 뒤쳐지다고 생각하여 잠시 우울한 생각이 들기도 하였지만, 항상 곁에 있는 동료개발자분들이 격려하며 도와주신 덕분에 한층 더 성장하였습니다.

2차프로젝트 더욱 기대되고 1차때는 다소 아쉬웠던 점들을 보완하여
각자 날개를 달아서 자유롭게 원하는 바를 이루고 흐뭇한 표정들을 짓고있었으면 좋겠습니다!!! :D

마지막으로 Brokurly 팀 모두 1차프로젝트 고생하였습니다 !!! 덕분에 잘 끝마칠수 있었던것 같습니다 .. 27기 동기분들도 모두 짱짱맨 🙆‍♂️

seyong

# 불편함을 편리함으로 바꾸고싶은 주니어 Back-end 개발자

다음 포스트