1차 프로젝트와 달리 2차 프로젝트는 생각보다 많은 블로커가 작용했고 원하는 만큼의 결과가 나오지 않아 솔직한 심정으로는 많은 것을 이루지 못해 여러모로 아쉽다. 아쉽기만 한가? 그렇지 않다. 1차 프로젝트 때 경험하지 못한 기술, 에러, 상황 등 오히려 또 다른 성장을 했다.

1. 프로젝트 개요

1. 모티브 : 클래스 101

사이트 설명 :

클래스 101은 취미 뿐 아니라 취업, 개인 사업 등 개인의 역량 발전을 위해 개설되는 다양한 강의들을 연계해줄 뿐 아니라 직접 유저가 크리에이터가 될 수 있게 중계해주는 교육 및 창업 플랫폼의 사이트다.

2. 주요 모티브 포인트 :

클래스 101의 모든 사이트 기능을 모티브로 프로젝트를 진행하는 것도 물론 중요하지만 우리 팀은 주요 기능 두 가지에 집중하기로 했다.

크리에이터가 오픈한 강좌를 보여주는 '오픈 예정' 페이지

크리에이터가 강좌를 오픈 할 수 있게 도와주는 '크리에이터 지원'

본래 오픈 예정인 강좌에 대해 status 값을 주어 '바로 수강'까지 진행해보려 했다. 하지만 멘토님과의 플래닝 미팅을 거쳐 논의한 점도 그렇고, 이번 프로젝트의 목표가 새로운 것을 배우고 익히는 것에 목적을 둔 것이지 홈페이지를 많이 구현하는 것이 아니었기 때문에 이 점은 팀원들과도 논의를 통해 다이어팅을 했다.

3. 팀 구성 및 방향성

1. 팀명 : 클래스200OK

• 200은 HTTP에서 성공적인 송수신을 의미한다. 무엇이든 이름 따라 간다고.. 성공적인 2차 프로젝트를 위해 200코드를 빌려왔다.

2. 팀 구성원

• 프론트엔드 4명 + 백엔드 3명
• 다른 팀에 비해서 팀원이 많은 팀이었다. 그 만큼 만만치 않은 홈페이지라는 점도 인지했다.

3. 방향성 : 기존의 것은 이미 알고 있는 것. 그러니 새로운 점에 도전

• 프론트엔드 : 함수형, 훅 등 자바스크립트의 업그레이드
• 백엔드 : 유닛테스트, 도커를 경유한 배포, S3를 이용한 이미지 업로드

4. 실제 계획

• 트렐로 사용
  

  주요 포인트 : 회의록 남기기 + 키 리스트, 목데이터 등 공유 사항 기록, 역할 중복일 때에도 명확히 티켓팅

4. 백엔드 내 역할 분담

1. 역할1 : 모델링 구축 및 초기 세팅
2. 역할2 : RDS DB 구축 및 S3 image 업로드
3. 역할3 : 소셜 로그인 및 로그인 데코레이터
4. 역할4 : 오픈 예정 메인 페이지 sorting & filtering
5. 역할5 : 크리에이터 지원센터 분담 제작
6. 역할6 : 오픈 예정 강좌 누를 시 나오는 모달 창 데이터 출력
7. 역할7 : ES2 배포

2. 나의 역할

이번 프로젝트에서 나의 역할은 역할1, 역할2, 역할 4의 일부였다. 아무래도 백엔드가 3명이다 보니 역할이 세분화 되기도 하였고 뒤에 이야기하겠지만 엄청난 블로킹으로 인해 나의 역할이 많이 단축되었다. 하지만 내실을 다지기 위해 많은 노력을 했다.

1. 모델링 및 초기 세팅(공동작업)

모델링 및 초기세팅의 경우는 1차와 마찬가지로 진행되었다. 크게 차이는 나지 않았으나 차이점을 뽑자면
1. 서버는 공동으로 쓰기 위해 RDS DB를 구축했다.
2. 모델링은 프론트엔드와 최대한 공유하려고 노력했다.
3. 키값을 목데이터로 초반에 맞췄다.

정도다.

2. 소셜 로그인 with 카카오톡

정리한 소셜 로그인 포스팅

소셜 로그인에 대해서 정리한 글은 위에 포스팅을 활용하면 된다. 여기 후기에서는 소셜로그인을 통해 어떤 것을 배웠는지만 정리하도록 하겠다.

1. 소셜 로그인 API 이용 플로우
   이번 기회를 통해 일반회원가입을 통한 방법 뿐 아니라 소셜 로그인을 이용하기 위해 API를 어떻게 사용하는지, 그 플로우는 어떻게 되는지 이해했다. 단순히 갖다가 복사 붙여넣기해서 쓰는 것이 아니라 충분한 로직을 구현하는 것이 필요하고, API와 프론트엔드, 그리고 백엔드가 어떻게 통신하는지 직접 구현해보면서 말이다. 물론 프론트엔드 입장에서 백엔드까지 토큰이 왔다 갔다 하는 모든 로직을 시간 내에 모두 구현해보는 것은 어려웠다. 하지만 플로우를 이해면서 느낀 희열이나, 이해한 로직을 직접 접목시켜보면서 느낀 재미는 이루 말 할 수 없이 즐거웠다.

2. 공식문서 통한 정보 얻기
   이번에 카카오 소셜 로그인을 하면서 사실 제일 어려웠던 부분은 다름 아닌 공식문서를 이용하여 정보를 얻는 것이었다. 카카오는 심지어 영어도 아니고 한국어로 친절하게 쓰여 있는데 막상 읽고 필요한 정보를 얻으려고 하니 여간 쉬운 일이 아니었기 때문이다. 약 2~3일 정도의 공식문서 정독과 관련 지식이 담긴 블로그를 참고했고 그 과정에서 동기들과의 소통을 통해 완전히까지는 아니지만 어느 정도 기술을 접목시킬 수 있는 정도까지 이르렀다. 앞으로도 공식문서를 접할 때 2차 프로젝트의 경험을 살린다면 공식문서로 봉착한 문제를 충분히 해결할 수 있을 것 같다.

• 참고로 이번 카카오 소셜 로그인에서 주요 포인트가 되었던 파트는 사용자 정보 받기와 개발자 도구 세션이었다. 가장 많이 보고 많이 사용하였다.

3. 새로 알게 된 기술
   2차 프로젝트를 하면서 파이썬, 장고에서 평소 쓰지 않던 새로운 기술, 메서드들을 배웠다. 다음은 그 예시다.

   requests

특히 카카오 소셜 로그인 같은 경우는 HTTP 송수신이 가장 중요한 포인트였는데 이 때 파이썬의 requests 개념을 이해하지 못 했어서 한참 방향을 잃었었다. 이 점 또한 다행히 동기와 이야기를 하면서 공부할 수 있었고 성공적으로 카카오 API를 사용할 수 있었다.

4. 카카오 소셜 로그인 유닛테스트 중 새로 알게 된 기술

   @patch
   mock / Magicmock

유닛테스트 전반에 대해서는 아래서 다룰 예정이지만 새로 알게 된 기술에 대해서는 로그인에 있어 여기서 다루면 위의 내용을 추가로 더 볼 수 있다. 여기서 새로 배운 내용인 패치와 목, 매직목 개념을 통해 실제 소셜 API와 가짜로 송수신을 해야할 때 어떤 플로우를 가졌으며 이를 어떻게 활용해야 하는지 알 수 있었다.(자세한 내용은 위 블로그에 참고했고 검색 시 많은 참고자료들이 있다.)

소셜로그인을 너무 오랜 기간 하는 바람에 글이 길어지기는 했으나 이번 기회를 통해 제대로 이해했고 온전히 내 것으로 만든 것 같아 뿌듯하다.

3. 크리에이터 지원 일부(기본 정보 제공)와 유닛테스트

정리한 Unittest 포스팅

• 유닛테스트 자체에 대한 이해와 과정
  (크리에이터 지원 뷰에 대해서는 큰 내용이 없이 자료만 출력하는 것이어서 유닛테스트에 대해서만 설명하면 다음과 같다.)

유닛테스트는 타 테스트보다 훨씬 경제적이고 효율적이며 자체적으로 할 수 있는 테스트임은 여러 정의를 통해서 알 수 있었다. 하지만 원론적인 이해만으로는 테스트 케이스를 만들거나 로직을 구현하는데 여간 쉬운 일이 아니었다. 또한 함수마다 테스트케이스를 만들어야하기 때문에 비슷한 예제를 찾는 것 또한 어려운 일이었다. 하지만 유닛 테스트의 본질을 이해하려고 하고 그 과정에서 예시를 끊임없이 서칭한 결과 위 정리한 블로그와 같은 결과를 낼 수 있었고 이러한 점을 배웠다.

유닛테스트는 결국 '어떤 에러'가 나는지를 먼저 생각하고 로직에 들어가야 한다.

유닛테스트는 해당 단위 함수가 어떤 경우에 SUCCESS고 어떤 경우가 FAIL 인지 경우의 수를 찾아가는 과정이다. 그러니 무작정 케이스를 만들어보려고 하는 것이 아니라 어떤 경우가 옳은지, 어떤 경우가 그른지부터 먼저 생각하고 들어가야 한다.

가령 이번에 내가 한 크리에이터 지원의 경우를 보더라도, 유저가 올바르게 적용이 되고 정보도 정확히 들어갔는지를 먼저 보고, 그 다음 유저 정보가 누락 되었거나, 정보가 누락되었거나, 똑같은 유저가 들어갔을 때 upload를 제대로 해주는가 등 다양한 로직을 먼저 생각해줘아 한다는 것이다.

4. 기술 외 담당

• 이번에도 마찬가지로 팀 내에서 서기? 역할을 맡으며 프로젝트의 전반을 정리하려고 노력했다. 프론트엔드에 대한 지식이 부족하지만 이해하려고 노력했고 진도를 맞추고, 서로 소통하기 위해서 백엔드의 입장 및 진도를 공유하려고 무지 애쎴다. 그 결과 마지막까지 최선을 다하기도 했지만 소통이 원활히 이뤄져 송수신이 잘 된 결과를 볼 수 있었다.

• 그 외에도 간식 담당을 맡았는데 팀원분들이 좋아해주셔서 다행이었다.

3. 블로킹과 해결 과정

사실 이번 프로젝트에서 백엔드의 핵심이라고 볼 수 있는 내용이 이번 내용이다. 너무 큰 블로킹이었고 해결하는데도 수 일에 걸쳐서 해결했다. 셋이서 머리를 맞대고 끝까지 집중한 결과라고 볼 수 있는데 이 점에서 같이 임했던 백엔드, 참아주고 기다려줬던 프론트엔드 분들 너무 감사했다.

1. 발단

1. 소셜 로그인을 마치고 유닛테스트에 들어가는 시기였다. 유닛테스트를 테스트해보려고 python manage.py test user를 누르는 순간이었다.
2. "1071, 'Specified key was too long; max key length is 3072 bytes'" 즉 서버에 특정 키값이 3072 바이트를 넘는다는 것이다. 이 에러는 그렇게 약 6일을 거치게 된다.

2. 해결 과정

1. 먼저 키값에 문제가 있었으므로 utf의 문제를 의심해봤다.

   ALTER DATABASE class200ok_third CHARACTER SET utf8; -> 실패

2. RDS DB의 문제가 있는 것 같아 로컬 DB로 실행해봤다. -> 덕분에 마이그레이션 파일이 모두 꼬였다.
3. 일단 마이그레이션 파일을 모두 초기화하고 다시 RDS DB에서 실행해봤다 -> 실패
4. RDS DB 설정값을 찾아봤으나 이상 없었다.
5. 그럼 모델에 문제가 있는 것. 모델을 모두 뒤져봤으나 USER 모델은 이상 없음
6. 길이가 긴 url 컬럼을 모두 500자, 200자로 줄였으나 실패
7. 이메일필드 등 필드값이 차필드가 아닌 모든 것을 수정해봤으나 실패

3. 해결

1. 힌트 : 장고 공식문서에 따르면 unique=True 등 유니크 값이 걸린 것은 글자수 제한이 걸린다고 한다.(max_length) 그래서 유니크 트루가 걸린 것에 있는 모든 컬럼을 확인해보니 석연찮은 것이 발견되었다.
   Introduction에 걸린 unique_together와 글자수

2. 과정 : 여기서 유니트 투게더를 주석을 달아보고 해봤더니 정상 작동하는 것을 볼 수 있었다. 따라서 이 부분을 수정하면 되었다. 일단 백엔드끼리 마이그레이션을 모두 맞추고 다시 모델을 최신화 하여 마이그레이트를 하고 깃풀을 받았다.

3. 결과 : 해결.

4. 결과에 따른 느낀 점 : 정말 모델링 하나가 얼마나 소중하다는 것을 느꼈고, 글자수 제한에 대해서도 있다는 것을 처음 알게된 사례였다. 이번을 계기로 공식문서를 꼼꼼하게 보면서 모델링에서 의심되는 부분을 잘 살펴봐야겠다고 생각했다.

4. 프로젝트를 마치며

1. 아쉬웠던 점, 잘한 점

참 많은 생각이 드는 프로젝트였다. 1차 프로젝트와는 완전히 다른 느낌이었고 2주가 이렇게 지나가나 싶은 정도로 사색에 잠길 때도 있었다. 먼저 아쉬운 점을 이야기해보면, 1차 프로젝트를 너무 무리하게 달렸는지 모르겠으나 체력적으로 달리는 느낌이 들었다. 그로 인해 생긴 약간의 지각과 (10~15분) 생활 패턴의 균열이 물론 프로젝트 자체에 큰 영향을 준 것은 아니지만 개인적인 아쉬움으로 남았다. 프로젝트 중 계획돼 있던 세션들과 3차 프로젝트(기업협업)에 대한 설렘과 우려, 새로 배우는 내용의 적용 등의 예상했지만 대처하기 힘들었던 브레이크도 프로젝트 완수에 영향을 줬다. 브레이크 뿐만 아니라 길어진 에러 상황 또한 정말 잘 해내고 싶고 좋은 퀄리티를 내고 싶었던 마음에 영향을 미쳐 정신적으로 쉽지 않았다. 이 일련의 모든 상황들이 1차, 2차 스프린트의 스크럼 완성에 영향을 끼쳤고 이로 인한 어수선함은 프로젝트 자체가 제대로 나올까 염려했었다.

하지만 위와 같은 역경을 겪는 와중에도 결론적으로는 계획한 플랜을 달성하였고 팀원들이 어느 정도 만족할 충분한 결과를 냈다. 이는 우리 팀원들이 발휘한 기지 덕분이었는데 '유연함'과 '이해'이 두 가지를 통해 가능했다. 실제로 며칠 남지 않은 상황에서 목표한 양에 대해 현실적으로 검토하고 2차 스프린트를 조정하기도 했고 그런 유연한 대처 덕분에 최종 발표 때 우리 팀이 주력으로 밀고 있던 '이미지 업로드'를 제대로 보여줄 수 있었다. 이 뿐만 아니라 유닛테스트로 고생하던, 함수형, 훅으로 고생하던 백엔드, 프론트엔드가 서로를 이해하고 기다려준 덕분에 원하던 성과를 낼 수 있었다.

2. 마치며

2차 프로젝트는 1차와는 달리 완전 다른 어려움을 겪으며 스스로를, 결과를 의심했지만 결국 해냈고 정말 많이 배운 프로젝트였다. 1차 때보다 훨씬 적극적으로 참여했고 문제해결 능력에 있어서도 다른 팀원의 과감한 결단과 의견 조율등을 보며 배운 점이 많았다. 또한 프로젝트를 마치고 '이제 모든게 끝났다!' 라는 느낌 보다는 이제 시작이며, 새로운 것에 도전해보고 싶고 개발과 공부를 하고 싶다 란 여운이 남아 의미있는 2주가 되지 않았나 한다.

앞으로 기업협업 4주가 진행되는데 새로운 기술 스택과 언어를 배우게 된다. NodeJS와 NESTJS인데 비록 쉽지 않겠지만 2차 프로젝트의 경험을 거울삼아 더욱 성장하는 개발과 공부를 즐기는 '진짜' 개발자가 되어야겠다.

끝으로, 내가 스스로 좋아하는 말을 가슴에 다시 새기며 글을 마친다.

'學而時習之 不亦說乎'
'배우고 때때로 익히면 즐겁지 아니한가.'