위코드 2차 프로젝트 회고

이 글은 위코드에서의 2차 프로젝트에 대한 회고입니다.

 

목차

1. 1차 프로젝트와의 차별성

2. SQL 쿼리

3. CI / CD

4. 한 달간의 소감

 

Github 링크

github.com/wecode-bootcamp-korea/19-2nd-Younggulart-backend

wecode-bootcamp-korea/19-2nd-Younggulart-backend

 

---

 

1. 1차 프로젝트와의 차별성 (or 기존 사이트와의 차별성)

모티프가 될 사이트를 배정받고 어떤 방향성으로 나아가야 할지 고민을 많이 했습니다.

미술품 경매사이트였지만, 실상 경매 기능이 어떻게 작동하는지 알 길이 없었고

(프로젝트 끝난 지금 이 시점에 드디어 경매가 열립니다)

경매 기능을 구현한다 해도 웹소켓을 사용해야 했기 때문에 그 방향은 일단 보류하게 되었습니다.

 

결국 1차 프로젝트때 진행했던 커머스 사이트 프로젝트와 별반 다를 바가 없었습니다.

다른 팀은 외부 API도 있고 새로운 기능도 많았는데

그에 비해 우리팀 백엔드는 새로 다룰 기술이랄게 별로 없어 보였습니다.

반대로 프론트는 할 것도 많고 새로운 기능도 많아서

무작정 새로운 기술을 더 도입하자고 하기도 미안한 상황이었습니다.

 

그래서 프론트에게 최대한 짐이 덜 되는 방향으로 백엔드만의 task를 만들어갔습니다.

예를 들면 데이터를 24780개를 넣는다거나...

 

프론트측에서 최대한 신경을 덜 쓸 수 있는 카카오톡 메세지 API를 사용한다든가...

 

외부 API 써보는 거 꼭 하고 싶었는데 아주 적절한 API를 찾아냈었다.

 

이런 프로젝트 방향성은 매일 아침 회의를 통해 공유되었습니다.

 

 

웹소켓을 쓰지 못해 아쉬운 팀원들

사실 경매 사이트인 만큼 팀원들은 웹소켓을 사용해보고 싶었습니다.

하지만 안그래도 프론트의 업무량이 이미 많았기에 나중을 기약하게 되었습니다.

(하지만 그 대신 CI/CD를 만지게 되는데...)

 

 

---

 

2. SQL 쿼리.. 쿼리를 보자..!!

1번 id를 가진 객체를 뽑아오려 할 때, 가장 주로 쓰이는 방식은 아래 세 가지입니다.

 

1번 id의 user 객체를 가져온다는 예시

이 코드들의 결과는 같지만 수행되는 방식은 전혀 다릅니다.

무엇이 더 효율적이고 나은 방식인지는 상황에 따라 다르겠지만 

그 상황에 맞는 적절한 코드를 쓰기 위해서는 내부적으로 어떻게 돌아가는지를 이해해야 했습니다.

 

그래서 봤습니다. SQL문.

장고 settings.py 파일에다 아래 설정만 넣어주면 매 통신마다 SQL 로그가 찍힙니다.

LOGGING = {
    'version': 1,
    'filters': {
        'require_debug_true': {
            '()': 'django.utils.log.RequireDebugTrue',
        }
    },
    'handlers': {
        'console': {
            'level': 'DEBUG',
            'filters': ['require_debug_true'],
            'class': 'logging.StreamHandler',
        }
    },
    'loggers': {
        'django.db.backends': {
            'level': 'DEBUG',
            'handlers': ['console'],
        }
    }
}

왜 filter를 한 다음 0번 index를 가지고 오는 것보다 .filter().first()가 효율적인지,

왜 존재여부 판단에는 .exists()가 효율적인지 raw SQL문을 보니 적나라하게 드러나더군요.

1차 프로젝트는 이 메서드 저 메서드 골고루 써보는 시간이었다면

2차 프로젝트는 어느 메서드를 써야 데이터를 빨리 필터링할 수 있는지 고민했던 시간이었습니다.

 

---

 

3. 짧았던 CI / CD와의 만남

프로젝트 발표 전날밤 CI / CD 배포를 도전해볼까? 하는 요상한 객기가 생겨났습니다.

그 마음의 불씨가 된건 프론트 팀원분의 선 CI / CD 도전이었습니다.

옆에서 고통받고 있으면 나도 같은 고통받고 싶은 그런 마음이 참개발자의 마음 아닙니까.

 

그렇게 젠킨스를 만나게 되는데....

 

 

 

 

애초에 도커 배포도 처음인데 내가 젠킨스를 쓸 수 있을까...? 라고 시작했는데...

결국 봐버렸습니다. 파란불!!

드디어 파란불.....!!!!!!!!!!

 

Hub에 push까지 되었다!

캡쳐해놓지는 못했지만, 배포 서버에서 이미지 pull까지 자동으로 되도록 성공했습니다.

 

하지만

문제가 생겼습니다. 컨테이너 실행이 안됩니다.

알고보니 환경변수 문제 때문이었습니다.

 

위코드에서는 SECRET_KEY같은 정보를 my_settings.py에 저장하도록 안내합니다.

그리고 필요한 곳에서 import '변수명' 을 통해 모듈식으로 불러옵니다.

물론 환경설정 단계를 빠르게 넘기고 장고 본질에 집중하기 위함임을 알지만

(집에서 독학하던 시절 프로젝트 환경설정에만 2~3일 잡아먹었던 거 생각하면...)

 

이렇게는 도커와 장고 사이에서 변수 티키타카가 불가능합니다.

os.environ을 통해 변수를 저장하고 불러올 수 있어야 하기 때문입니다.

 

환경변수를 읽어오는 코드

 

docs.docker.com/compose/environment-variables/

Environment variables in Compose

위 docker 공식문서는 환경변수를 설정할 수 있는 다양한 방법에 대해 설명하고 있습니다.

저렇게 설정해놓은 환경변수를 장고 파일에서 읽어오지 못해 컨테이너 실행이 불가능했습니다.

그래도 원인을 알았으니 다음에 시간 나면 다시 시도해보려 합니다.

 

그래서 CI / CD가 뭔지 이해는 하고 한거냐

아니오. 완벽히 알지는 못합니다. (당당)

하지만 이번 기회를 통해 도커와 좀 더 친해진 것 같습니다.

불과 일주일 전만 해도 가상환경이 뭔지 감도 못잡았었으니까요.

도커라는 단어만 들으면 어마무시한 무언가인듯한 느낌이었지만

지금은 만약 도커를 주제로 한 대화에 참여한다면

끄덕끄덕 도리도리 정도는 할 수 있는 정도가 된 것 같습니다.

 

좀 더 밀도있는 CI / CD 환경이었다면 

파이썬 테스트코드도 배포환경에서 자동으로 실행하는 기능을 넣었을텐데

이것도 환경변수 설정할때 같이 시도해야겠습니다.

 

---

 

4. 마지막 프로젝트 소감

그저 다들 너무 고생했다는 말밖에 나오지 않습니다.

우리팀분들은 물론이고 동기들도 모두 고생 많으셨습니다.

밥도 거르며 코드짜는걸 보자니 너무 안쓰러웠는데..

🤘🏻앞으로 훌륭한 개발자가 되실겁니다 모두들 🤘🏻

 

조금 더 심적인 여유를 가졌으면 동기들을 더 도와줬을 수도 있을텐데.. 라는 아쉬움도 있습니다. 

지난 기간동안 다른분들의 기술적인 blocker를 종종 같이 고민해보곤 했습니다.

그런거 완전 좋아합니다. 그 과정에서 내가 모르는 것도 알아갈 수 있고 

서로 의지하는 느낌도 나기 때문입니다. 함께 서로 밀고 끄는 그 느낌이 좋았습니다.

 

하지만 나의 프로젝트에 치이다 보니 저도 모르게

가끔 몇번 무심하게 반응하지 않았나 싶은 아쉬움이 듭니다.

여러분 앞으로도 같이 고민합시다!!! 

 

멘토님들도 모두 고생 많으셨습니다.

제가 너무 pr 리뷰 닥달했던 건 아닌가 싶긴한데 다 도움이 많이 되었습니다.

이제부터가 시작이니 지금껏 쌓은 밑거름 잘 다져서 성장하도록 하겠습니다.

 

이제 전 다시 자바스크립트 공부하러 20000..