장고 50문 50답 -2

Django를 통해 CRUD를 구현하는 방법에 대해서 HTTP Method와 함께 설명하시오

• HTTP GET 메소드와 Read : request에 담겨오는 http메소드를 확인하여 Get이라면 모델에서 함수에서 제공해주어야 하는 데이터를 Read하여 요청을 보낸 프론트엔드로 보내준다.
• HTTP POST 메소드와 Create : 마찬가지로 메소드가 POST라면 request.POST에 담겨오는 데이터를 가져와 검증하고 모델에 맞는 데이터가 들어왔다면 orm을 통해 db에 저장해준다.
• HTTP PUT 메소드와 Update : 메소드가 PUT이라면 프론트에서 보내준 데이터를 받아와 filter를 통한 update나 필드에 새로 할당한 후 저장을 하는 방법으로 업데이트를 해준다.
• HTTP DELETE 메소드와 delete : 메소드가 delete라면 프론트에서 보내온 특정할 수 있는 id값을 받아와 orm을 통해 id값을 가진 데이터를 조회하고 데이터를 삭제해준다.

Django에서 테이블을 설계하고 데이터베이스에 반영하는 방법에 대해서 설명하시오

• 장고에서 이뤄지는 테이블 설계는 각 앱단위에 있는 models.py 파일에서 이루어진다.
• 이 파일 안에서 클래스를 선언하고 장고의 모델을 상속받아 필드 별로 models.에 있는 클래스를 불러와 어떠한 데이터가 들어가는지 명시해준다. (테이블간의 관계도 ForeignKey, OneToOne, ManyToMany 등 다양하게 설정할 수 있다.)
• 마지막으로 python manage.pymakemigrations 명령어를 통해 db의 생성, 수정등에 대한 기록을 남기고 python manage.py migrate 명령어를 통해 마이그레이트를 시행하여 데이터베이스에 생성 수정한 내용을 반영한다.

회원가입을 할 때 비밀번호를 암호화하여 저장하는 이유는 무엇입니까?

• 서비스의 데이터베이스가 무조건 안전하다고 볼 수 없기 때문에
• 개발자가 db에 접근해 비밀번호를 볼 수 있다는 것 자체가 개인의 데이터를 침해한 것이기 때문에

JWT에 대해서 설명하시오

• Json Web Token의 줄임말로 인증방식 중에서 가장 주목 받고 있는 토큰 인증 방식이다.
• db에 따로 토큰을 저장해주어야 하던 기존의 토큰 인증방식에서 조금 더 확장성이 좋고 안정성도 더 높아진 방식
• header, payload, signiture 이렇게 세 단위로 나뉘며
  • header에는 사용할 타입, 해시알고리즘의 종류가 담겨있고
  • payload에는 간단한 유저정보, expire_date 같은 서버에서 보내준 데이터가 담긴다.
  • signiture 부분에는 hash된 암호화된 토큰이 담겨있다.

JWT의 Access Token과 Refresh Token은 왜 필요한가요?

• access토큰은 서버에서 인증을 요구할 때 http request 헤더에 담아 인증된 사용자임을 증명하기 위해서 필요하다.
• 그러나 억세스토큰이 계속 사용된다면 기존의 db에 저장하는 방식만큼이나 token이 노출될 위협은 계속해서 존재한다. 이를 방지하는 것이 refresh토큰이다.
• refresh토큰을 통해서 새로운 access토큰과 refresh토큰을 발급 받을 수 있으며 이를 통해서 access토큰은 고정되지 않고 계속 변화하여 해킹의 위협을 줄일 수 있다.

Django의 기본 기능을 사용하는 것과 JWT를 사용하여 로그인 기능을 구현하는 것에는 어떤 차이점이 있습니까?

• Django의 기본기능
  • Django의 기본기능을 사용한 로그인은 세션을 이용한 방식이다. 기본 세팅을 통해서도 내장함수를 이용하여 간단하게 로그인을 구현할 수 있다.
  • 세션이 안전한가 토큰이 안전한가에 대한 논쟁은 의견이 분분하나 세션로그인은 어쨌든 쿠키라는 접근이 가능한 곳에 저장한다는 점에서 안정성이 떨어진다는 의견이 많다.
  • 그에 대한 대안으로 세션쿠키에 접근을 못하도록 막아놓는다던지 많은 대안을 내놓고 있다.

2. JWT를 사용한 로그인 기능
   • 우선 JWT를 사용하면서 Django에서 제공하는 기본적인 auth에 관련된 내장함수를 이용하기 위해서는 settings.py에 jwt토큰을 이용한 인증을 사용하겠다고 밝혀주어야 한다. (커스텀으로도 가능하나 jwt_simple 패키지를 활용하면 쉽게 구현할 수 있다.)
   • 특정 url으로 들어오는 아이디와 비밀번호를 가진 요청을 받아 데이터베이스에 일치하는 값이 있다면 jwt토큰을 생성해서 보내주기만 하면 된다.
   • 또한 jwt는 payload에 담을 값들이나 exp_date 같은 세세한 설정은 pyjwt를 통한 설정이나 jwt_simple을 사용한다면 settings.py 에 jwt에 대한 설정을 만들어두면 된다.

데이터 테이블 간의 관계를 나타내는 FK, OneToOne, ManyToMany 필드에 대해서 설명하시오

• FK
  • 테이블 간의 관계를 형성할 때 가장 보편적으로 쓰이는 형태
  • FK 필드에 관계될 테이블의 PK값을 저장해놓는 경우가 많으며 FK 필드로 묶어놓으면 한 데이터에 관계되어 있는 다른 데이터를 가져오는 것이 용이해진다.

2. OneToOne
   • 일종의 보조테이블이라고 볼 수도 있다.
   • 예를 들어 유저와 유저프로필은 다른 데이터이나 유저는 하나의 유저프로필만을 가지고 반대의 경우도 마찬가지이다.
   • 이럴 경우 FK로도 관계를 형성할 수 있겠지만 onetoone으로 관계를 형성하면 모종의 이유로 여러개의 테이블과 관계가 형성될 수도 있는 상황을 미연에 방지할 수 있다.
3. ManyToMany
   • 하나의 데이터에 여러 개의 데이터가 묶여있는 FK와는 다르게 여러개의 데이터가 여러개의 데이터를 가지는 조금 복잡한 형태의 관계
   • 2차원으로 구성된 db테이블을 매핑 테이블을 활용하여 3차원으로 만들어준다. (실제로 3차원이 되는 것은 아니지만)
   • ex) 인스타그램에서 포스트는 여러개의 태그를 가질 수 있고 태그 또한 여러개의 포스트를 가질 수 있다 (따라서 포스트를 통해 태그를 조회할 수도 있지만 태그 검색을 통해서 관계된 포스트를 조회할 수도 있다.)

Django에서 ManyToMany필드를 만드는 방법에 대해서 설명하시오

• Django에서는 model을 생성할 때 필드값에 특정 테이블과 manytomany관계임을 설정할 수 있다.
• 이렇게 설정해놓으면 Django는 알아서 mapping 테이블을 생성한다.
• 이 매핑테이블은 1번 테이블과 2번테이블의 관계를 형성한다고 했을 때 1번테이블의 pk와 2번테이블의 pk를 매핑하여 각각 어떤 데이터와 어떤 데이터가 묶여있는지 명시해준다.
• through명령어를 통해 직접 생성한 매핑테이블과 관계를 형성할 수도 있고
• 커스텀을 통해 매핑테이블을 직접 생성하고 테이블간의 관계를 생성하여 ManyToMany로 만들어줄 수도 있다.

FBV와 CBV는 각각 무엇이며, 어떤 차이가 있습니까?

• FBV
  • FBV는 function based view의 줄임말로 view에서 제어의 단위를 함수를 기본으로 한다는 의미이다.
  • 함수를 선언하고 그 안에서 method가 어떻게 들어오느냐를 if문으로 구분하여 제어한다.
  • 개인적으로 한 함수에서 하나의 역할만을 해야한다고 생각하는 사람으로서 지극히 불편함을 느낀다.
  • 그래서 또 다시 겟함수, 포스트함수로 세분화 해야하는 상황이 생기기도 한다.
• CBV
  • class based view의 줄임말로 view에서 제어의 단위를 클래스를 기본으로 한다는 의미이다
  • DRF에서는 APIView라는 클래스를 상속받아 설정할 수 있으며
  • get, post, put, delete함수들을 클래스 내부에서 생성하여 각각 함수 이름과 같은 Http메소드를 제어한다.
  • FBV 보다 속도면에서도 더 빠르며(실제로 지난 프로젝트를 통해 실험해봄) 직관성면에서도 더 뛰어나다고 생각한다.

테스트코드를 작성하는 이유는 무엇이며 어떤 장점이 있습니까?

• 작업을 하면서 실제로 있었던 일인데 작업의 막바지에 거의 다다랐을 때 쯤 유저모델(연관된 테이블이 어마어마하게 많았다.)의 필드를 변경해야할 일이 있었다.
• 이 필드는 나중에 생성한거지만 유저마다 다 필수로 가지고 있어야 하는 데이터였고 이 테이블을 생성하자마자 70개의 테스트 코드가 터졌다
• 이 터지는 테스트 코드를 보면서 든 생각이 지금 테스트 코드를 고치는게 괴롭기는 하나 이 테스트코드가 없었다면 일일이 찾아다니며 연관된 모든 테이블을 고쳐야 한다는 생각에 소름이 끼쳤었다.
• 코드를 작성하다보면 서비스가 커지면 커질수록 더욱 그렇겠지만 인간이 한 눈에 이해하기 어려울 정도록 복잡해지게 된다.
• 이 복잡한 미로에서 길잡이가 되어주는 것이 테스트 코드라고 생각한다. 어떤 문제가 발생했으며 어디를 고치면 되는지
• 또, 발생할 지도 모르는 문제를 미연에 방지할 수 있다는 면에서도 장점을 가진다고 생각한다.