Django 셀프 50문 50답 21~50번 + @2문항 추가

21. 테스트코드에서 setup 함수와 setupclass의 차이는 무엇입니까?

• setUp = 테스트를 하기위한 조건을 만들어 주는 것

• setUpClass = 테스트를 하기 위한 조건이 테스트를 진행하는 과정중에 기억되게 하는 것

• setUp 함수는 unit-test으로 모든 테스트를 독립적으로 시행하기 위해서 필요한 함수
  그러나 매번 단위별로 테스트를 진행할 수 없고, 통합테스트를 진행할 수 있도록 setUpClass를 통해 공통된 조건들을 기억 할 수 있도록 세팅할 수 있음

• 테스트코드를 작성함에 있어서 중요한 핵심은 모든 테스트는 독립적으로 시행되어야 합니다. 또한 테스트케이스에서 사용되는 데이터베이스 레코드는 실제 레코드가 아닌 테스트케이스에서 생성해서 테스트를 실행한 후 삭제하게 됩니다. 이러한 레코드를 테스트코드 밖에서 만들어주는 작업이 필요한데 이것을 SetUp 함수에서 담당하게 됩니다.

• 독립적으로 회원가입, 로그인과 같은 기능을 테스트케이스마다 매번 실행해준다면, API와는 관계없이 같은 SetUp함수를 반복적으로 실행하는 것으로 테스트케이스의 속도저하를 유도하게 됩니다. 따라서 stateless한 테스트케이스이지만 공통적으로 반복되는 데이터의 경우 SetUp 클래스를 생성하여 한 번의 실행으로 모든 테스트케이스가 공통조건을 가지고 SetUP 함수의 반복 실행없이 테스트할 수 있습니다.

22. Template Engine을 사용할 때, 발생하는 CSRF Error가 무엇이고 어떻게 해결합니까?

• CSRF = Cross Site Request Forgery (사이트간 요청 위조)사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 특정 웹사이트에 요청하게 하는 공격을 말하며, Django Template Engine에서는 CSRF 공격을 막기 위한 코드인 {% csrf_token %} 이 내장되어 있으며, POST 요청 시 해당 코드가 반드시 필요로 합니다.
  이 코드를 작성하지 않아 Request 에러가 발생하는 것이고 해당 코드를 기입하는 것으로 에러를 해결할 수 있습니다.

23. Django ORM에서 queryset과 object의 차이점에 대해서 설명하시오

• queryset은 object의 집합체이며 리스트로 구성되어 있음

• object = 데이터베이스를 하나의 단일 객체 덩어리로 봄

• Django ORM 을 통해서 데이터베이스의 레코드를 접근하여 추출한 결과물에는 object와 queryset이 있습니다.
  object는 레코드 하나를, queryset은 여러 개의 object가 있는 리스트를 의미합니다.
  object는 하나의 데이터베이스 레코드이므로 해당 필드 이름을 메서드로 사용하여 값을 추출할 수 있습니다.
  그러나 queryset은 리스트 형태로 되어 있어 object형식으로 특정할 수 있는 인덱스를 사용하거나 반복문을 사용하는 등 추가 처리를 통해서 필드 값을 추출할 수 있습니다.

24. Django ORM에서 정참조와 역참조에 대해서 설명하시오

• 장고의 모델에서 내가 참조하고있는 모델의 필드 조회하는것은 정참조
• 참조되고 있는 모델에서 나를 참조하고있는 모델을 조회하는 것이 역참조

25. Response 결과와 함께 status code를 반환하는 이유는 무엇입니까?

• 개발자들간의 약속된 규약으로 status code를 통해 프론트엔드에서 서버에 request시 어떤 상태값을 반환 받는지에 따라 코딩을 해야함으로 함께 반환합니다.
• 이는 코드를 통해서 개발하는 환경에 있어 명확하게 요청의 성공과 실패를 결과물에서 확인할 수 있으며, 또한 이를 사용자에게 UI및 UX의 형태로 보여주기 위함입니다.

26. 회원탈퇴, 게시글 삭제와 같은 기능을 구현할 때 실제 레코드를 삭제합니까? 그렇지 않다면 그 이유는 무엇입니까?

• 삭제 할수도 있고 하지 않을 수도 있습니다
• 실제 레코드를 삭제한다면 더이상 데이터베이스에 접근할 수 없기때문에, setnull등을 통해 회원탈퇴나 게시글 삭제를 진행하여도, 기록은 남아 있을 수 있도록 할 수 있습니다.
• 탈퇴한 사용자나, 삭제한 게시글과 같은 형태의 레코드를 단순히 삭제 기능을 구현하는 것이 아닌 is_active와 같은 메서드를 사용해 노출을 숨기는 것으로 백업할 수 있는 데이터를 남겨두는 것이 차후 서비스의 안정성을 높일 수도 있습니다.

27. RESTful API는 무엇을 의미합니까?

• REST의 특징을 기반으로 API를 구현한것을 RESTful API라고 합니다

• HTTP 요청을 보낼때 어떤 URI에 어떤Method를 사용할 지 개발자들 사이에 널리 지켜지는 약속이며 프레임워크등이 아닌 형식이기때문에 기술에 구애받지는 않음

• REST 란?
  어떤 자원에 의해 CRUD(Create, Read, Update, Delete)연산을 수행하기 위해 URI(Resource)로 GET, POST등의 방식(Method)를 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태(Representation of Resource)로 표현됨.

28. DRF를 사용해 API를 개발할 경우 어떤 장점이 있습니까?

• valid 분기문을 통한 검증을 하지 않아도 되기에 좋다
  DRF 시리얼라이저의 Validation을 통해서, 모델 필드의 형식과 맞는지 자동으로 검사해주므로, 일일히 입력값을 조회하여 확인해주지 않아도 되는 편리함이 있다.

• Django 프로젝트에서, Serializer(직렬화)를 통해 JSON과 같은 양식으로 다양한 플랫폼의 클라이언트에게 데이터를 제공해 줄 수 있는 장점이 있다

29. Django 와 DRF를 통한 개발의 차이점은 어떤 것이 있습니까?

• Django와 DRF 둘 다 파이썬기반의 웹 프레임 워크이다.
  그러나 Django는 서버와 클라이언트 사이에 html,css,JS주고 받는다 (request&response).
• 반면 DRF는 시리얼라이저를 사용하여 서버와 클라이언트 사이에 JSON형식의 데이터만 상태를 표시하며 주고 받는다.

30. Django User 모델과 DRF Custom User 모델의 차이는 무엇입니까?

• Django의 경우 기본 유저모델은 아이디,비밀번호,이메일과 같은 기본 필드만 제공되며, 추가로 다른 필드를 필요하게 될 경우 직접 클래스를 만들어 사용해야합니다.
• DRF의 경우 AbstractBaseUser 클래스를 상속받아서 커스텀 유저모델을 작성할 수 있습니다.
  지원되는 기본 필드에는 is_active, is_admin, is_staff가 있고, 사용자아이디를 다른 필드로 지정할 수 있거나 필수로 입력받을 필드를 지정할 수 있고 관리자계정 여부를 정할 수 있습니다

31. DRF Serializer는 무엇이며, 어떤 기능을 수행합니까?

• Serializer는 직렬화로, 입력받은 데이터를 JSON화 하여 출력합니다.
• 뷰에서 입력받은 값에 해당하는 데이터를 일일히 묶어줘서 반환해줘야 하는 불편함이 있지만, 시리얼라이저를 사용해서 원하는 데이터 테이블과 필드를 손쉽게 묶어서 반환해주는 장점이 있습니다.

32. JSON 형식으로 데이터를 받고, Serializer를 통해서 JSON형식으로 데이터를 반환하는 이유는 무엇인가요?

• 다른 환경과 데이터를 주고 받으려면 동일한 데이터 구조 표준을 가지는 것이 javascript를 사용하는 프론트엔드의 작업효율을 높인다.
• 파싱 및 시리얼라이저를 따로 또 사용하지 않아도 읽기 쉽고, 사용하기 쉬운 JSON 형태로 받았기 때문이다.

33. Serializer를 통해서 모델에 존재하지 않지만, 관계 있는 테이블의 필드 레코드를 반환하는 방법에 대해서 설명하시오

• 원하는 데이터의 필드이름을 변수로 지정하여 해당하는 모델에 시리얼라이저에
  SerializerMethodField()를 추가하여 데이터의 값을 반환하며, fields에 지정한 변수를 입력하여야 한다
• MethodField는 벨리데이터를 타지 않는다

34. Serializer를 통해서 역참조 하는 방법에 대해서 설명하시오

• 외래키로 참조되어 있는 데이터 테이블의 필드를 조회하고싶을때 시리얼라이저를 통해 진행할 수 있으며, 모델에 저장된 필드의 이름 변수에 set 메서드를 통해 역참조 구문을 사용할 수 있습니다.
• 변수를 내가 원하는 이름으로 변경하고 싶다면 (source=필드이름_set)을 통해 커스터마이징 해줄 수 도 있습니다.

35. Django Q기능을 통해서 쿼리하는 것은 어떤 장점이 있습니까?

• Django DB 작업에서 사용할 수 있는 SQL조건문으로, filter메서드에서 주로 사용합니다
• ORM은 조건이 많아지면 코드가 길어지는 단점이 존재하는데, Q를 통해 SQL쿼리문을 쓰지 않고도 간단하게 쿼리할 수 있는 장점이 있습니다

36. Serializer에서 어떻게 객체를 validate하게 됩니까?

• DRF의 내장되어있는 validate 함수를 활용하여, 데이터 테이블 모델의 필드의 형식이 올바른지, 데이터는 모두 입력되어 있는지 등의 내용을 기본 내장 validate()메서드를 통해 입력받은 데이터의 값을 True, False로 구분하여 is_valid() 메서드에 반환하여 검증하게 된다.
• 개발할 경우 이를 사용하여 검증이 되었는지 여부를 확인할 수 있다.

37. Serializer에서 Custom Validation을 하는 이유는 무엇입니까?

• 데이터 테이블의 모델의 필드의 형식 외에 추가적으로 검증하고싶은 조건이 있을때 커스텀 벨리데이션을 통해 추가 검증을 진행합니다.

38. Serializer에서 create, update 함수는 어떤 기능을 수행합니까?

• create = 유효성 검사를 통과한 데이터들을 바탕으로 새로운 DB인스턴스를 생성하고 반환합니다
• update = 유효성 검사를 통과한 데이터들을 바탕으로 기존의 DB 인스턴스를 수정하고 반환합니다

39. Serailizer Custom validate함수를 통해 오류 케이스를 어떻게 처리합니까?

• 기본 및 커스텀 밸리데이션을 통해서 검증할 데이터마다 확인되는 조건을 통과하지 못할 때, raise 구문으로 예외처리하여 검증 오류문을 반환하게 됩니다.

40. DRF permission_classes를 사용하는 이유는 무엇입니까?

• 사용자별 각각의 개별적인 권한을 부여하기 위해 사용
• 구현되어 있는 API별로 각각 다른 조건의 접근 권한을 부여하기 위해서는 Django 기본기능의 authenticate 의 구문으로는 부족하다.
• 따라서 permission_classes를 활용하여 다양한 조건을 생성하고 해당 조건을 만족하는 사용자에게 접근 권한을 부여할 수 있게되므로 복잡한 기능을 구현할 수 있게된다.

41. Django는 어떤 종류의 데이터베이스를 사용합니까? Flask와의 차이는 무엇입니까?

• Django는 공식적으로 SQLite, MySQL, PostgreSQL, MariaDB, Oracle을 지원합니다.
• 기본적으로 아무런 설치없이 사용 가능한 것으로는 SQLite가 있습니다.
• 그러나, 실제로 프로젝트를 시작할 때에는 나중에 데이터베이스를 교체하느라 골치아파질 일을 피하기 위해서라도 PostgreSQL과 같이 좀 더 확장성이 있는 데이터베이스를 사용하는 것이 좋습니다.
• Django에는 RDBMS와의 상호 작용을 지원하는 기본 내장 ORM을 함께 제공하고, 이 ORM은 마이그레이션 생성 및 관리도 지원합니다.
• 내장된 유효성 검사를 사용하여 데이터베이스 모델을 만드는 것이 상대적으로 더욱 편안합니다.
• Flask에는 DB ORM 구조가 따로 존재 하지 않습니다.
• 개발자가 원한다면 따로 ORM을 지원하기도 하며, 패키지를 선택해서 사용하면 됩니다.

42. Django에서 제공하는 sqlite는 어떤 장단점이 있습니까?

• 장점

  SQLite는 낮은 메모리 환경에서도 이식성, 안정성이 좋고 매우 가볍습니다.
  무료 오픈소스 소프트웨어이고, 이를 사용하는 데 특별한 라이센스가 필요하지 않습니다.
  또한 별도로 돈을 낸다면 압축 및 암호화에 도움이 되는 확장 기능을 제공하기도 합니다.

• 이식성 = 데이터를 분리된 파일의 커다란 배치로 저장하는 다른 일반적인 데이터베이스와 달리 단일 파일에 전체 데이터가 저장되고, 이 파일은 디렉터리 계층의 어디에나 위치할 수 있으며 이동식 디스크 또는 파일 전송 프로토콜을 통해 공유할 수 있습니다.

• 특별한 라이센스가 필요하지 않음 = 완전한 독립형, 외부 종속성이 없음 즉시 사용될 수 있는 “Zero-configuration”데이터베이스

• Sqlite는 Django에서 기본으로 제공하는 데이터베이스로, 다른 데이터베이스에 대한 사전지식이 많지 않아도 개발환경에서 프로젝트의 데이테베이스를 쉽고 빠르게 구현할 수 있습니다. 다른 SQL에 비해서 가벼우며, 개발환경에서 직접 데이터베이스를 GUI로 확인할 수 있습니다.

• 단점

  동시성의 제한이 있습니다.
  동시에 여러 프로세스가 SQLite 데이터베이스에 액세스하고 쿼리가 가능하지만 주어진 시간에 하나의 프로세스만 데이터베이스를 변경할 수 있습니다.
  사용자 관리가 존재하지 않습니다.

• 데이터베이스 시스템은 데이터베이스 및 테이블에 대해 사전에 정의된 액세스 권한을 사용자에게 제공하지만, SQLite는 일반 디스크 파일을 직접 읽고 쓰기 때문에 적용 가능한 유일한 액세스 권한은 기본 운영 체제의 일반적 액세스 권한뿐입니다.
  이로 인해 특별한 액세스 권한이 필요한 응용 프로그램에는 적합하지 않습니다.
  다른 RDBMS에 비해 보안이 약합니다.

• Django에서 기본으로 제공하는 Sqlite는 가벼우나 다른 관계형데이터베이스에 비해, 방대한 양의 데이터처리나 빠른 속도를 제공하는 것은 아닙니다.

43. AWS를 통해 배포할 경우, sqlite를 사용하지 않는 이유는 무엇입니까?

• 서비스를 AWS를 사용하여 배포할 경우, 더 이상 개발환경에서 두드러지는 장점을 가진 Sqlite는 다른 데이터베이스보다 사용성이 좋지 않기 때문입니다.
• 상대적으로 낮은 보안, 데이터 처리 양의 한계, 병렬처리 불가 등의 단점을 이유로 서비스를 배포할 때는 이런 단점을 보완할 MySQL 혹은 PostgreSQL을 선호하게 됩니다.

44. Django settings에서 DB 스택을 변경하는 방법은 무엇입니까?

• Sqlite를 데이터베이스로 사용하지 않고, 원하는 데이터베이스를 사용할 경우 settings.py 에서 DATABASES 의 default값을 USER, PASSWORD, HOST, PORT번호를 기재함으로써 원하는 DB로 변경할 수 있습니다.
• 위의 default 값은 .env 파일에서 따로 저장하게 됩니다.

45. Django 프로젝트를 배포할 때, 노출되어서는 안되는 값은 어떤 것이 있습니까?

• DEBUG = False 로 변경해야 합니다
  디버깅 정보를 오픈하면 소스를 그대로 보여주는것과 다름이 없습니다

• Secret Key
  암호화 서명, 해싱등에 사용하는 값이기때문에 노출하면 안됩니다

• ALLOWED_HOSTS
  HTTP Host Header Attack 위협에 대응하기 위해서 비공개 처리해야합니다

• RDS, S3
  AWS 계정 정보가 있기 때문에 비공개 처리해야 합니다

46. Django 프로젝트를 배포할 때, 시크릿키를 노출하지 않는 방법에 대해서 설명하시오

• pip install django-dotenv를 통해 설치 해줍니다
• git을 사용한다면 .ignore 파일에 반드시 .env을 추가하여 github에 올라가는 것을 방지해야 합니다
• import dotenv를 통해 env를 활성화 해주고, import os를 통해 필요한 환경변수를 불러올 수 있도록 준비합니다
• 기존 settings.py 에 SECREY_KEY의 벨류값을 복사하여 .env 파일을 생성한 후 SECRET_KEY = ‘복사해온 벨류값 작성’ 형태로 가져와줌으로 보이지 않지만 역할을 할 수 있도록 해줍니다
• settings.py 에 SECREY_KEY = os.environ.get(”SECRET_KEY”)를 통해 .env에 있는 시크릿파일을 읽습니다

47. Django 프로젝트 진행 시 발생하는 CORS 오류를 처리하는 방법에 대해서 설명하시오

• Django Settings.py 에
  CORS_ORIGIN_WHITELIST
  CORS_ALLOW_METHODS
  CORS_ALLOW_HEADERS 를 추가,
  추가로 MIDDLEWARE corsheaders.middleware.CorsMiddleware 순서가 중요하기에 맨위에 에 추가한 후
  CORS_ORIGIN_WHITELISTE 에 교차출처를 허용할 사이트 주소를 명시해줌으로써 CORS 오류를 해결할 수 있습니다

• 요청을 받는 백엔드쪽에서 CORS를 허용할 출처들을 미리 명시해줌으로 해결해줄 수 있다

48. Django 프로젝트를 배포할 때 Allow Host에 * 가 들어가면 안되는 이유는?

• 해킹에 위험이 있기때문에 와일드카드는 개발할때 혹은 특별한 경우를 제외하고는 사용하지 않는것이 좋습니다

• Allow Host는 Django settings.py파일에서 서버에 접근할 수 있는 호스트의 IP를 명시하는 부분입니다.
  와일카드인 애스터리스크(*)는 모든 경로의 접근을 허용한다는 것을 의미합니다.
  이는 어떤 IP더라도 해당 프로젝트에 접근할 수 있게 되는 것을 의미하며, 이는 서버에 직접적으로 관여할 수 있게되는 접근 권한을 모두 열어둔 것이기 때문에, 프로젝트 개발자 이외의 불특정 공격자에게 서버를 무방비 노출하게 되는 결과를 초래합니다.

• 따라서, 서버를 관리할 IP주소를 Github에 노출하지 않게 해서 보안 취약을 막아야 합니다.

49. Django 프로젝트를 배포할 때 사용되는 Gunicorn이 무엇이며, WSGI를 왜 사용해야 하는지 설명하시오

• Gunicorn은 Python WSGI로 WEB Server(Nginx)로부터 서버사이드 요청을 받으면, WSGI를 통해 서버 애플리케이션(Django)에 전달해주는 역할을 수행합니다.

• WSGI는 파이썬 애플리케이션이 웹 서버와 통신하기위한 인터페이스로, 웹서버서의 요청을 해석하여 분배해야함으로 필요하고 멀티 쓰레드를 만들 수 있기 때문에 Request 요청이 많아지더라도 효율적으로 처리할 수 있으며, 이는 production 환경에 적합합니다

• Django를 통해서 웹 서버를 구축한 뒤 배포하려면, 프론트엔드를 담고 있는 정적인 웹 서버를 필요로 합니다. 그러나, Django와 웹 서버는 바로 연결될 수 없습니다. 웹 서버에 해당하는 Nginx는 Django의 코드를 이해하지 못하기 때문에 연결해줄 중간 역할이 필요하며 이를 WSGI가 사이에 연결되어 해소할 수 있습니다.

50. Django 프로젝트를 배포할 때 사용되는 NGINX가 무엇이며, 웹서버를 왜 사용해야 하는지 설명하시오

• Nginx는 동시접속 처리에 특화된 웹 서버로 http 요청을 받아 요청에 해당하는 파일을 http통신을 통해 응답해주는 프로그램입니다

• Apache보다 동작이 단순하고, 전달자 역할만 하기때문에 효율적입니다
  Nginx를 사용함으로써 여러 Request를 처리할 수 있음으로 정적 콘텐츠를 고속으로 처리하기에 사용합니다

• Django는 웹 백엔드를 담당하는 스택입니다.
  따라서 일반적으로 서비스에서 사용되는 프론트엔드는 Django가 아닌 다른 스택을 사용하기 때문에 프론트엔드와 백엔드는 분리되어 있습니다.

• 이를 하나로 배포하기 위해서는 백엔드에서는 프론트엔드의 요청을 받고 읽어낼 수 있는 웹서버를 필요로합니다. Nginx는 이 웹서버 중 하나로 백엔드에서 정적 파일의 요청을 읽어 웹 프레임워크인 Django로 전달하는 행위를 수행합니다.

51. Django에서 PostgreSQL을 선호하는 이유는 무엇입니까?

• Django는 PostgreSQL에서만 작동하는 여러 데이터 유형을 제공하며 공식문서에서 권장하는 데이터베이스입니다.
• 지도를 사용하여 애플리케이션을 구축하거나 지리적 데이터를 저장하는 경우 GeoDjango는 PostgreSQL과 완벽하게 호환할 수 있기에 타 DB보다 장점이 있습니다

52. HTTP가 아닌 HTTPS로 배포했을 때의 장점에 대해 설명하시오

• HTTPS는 Hyper Text Transfer Protocol Secure로 보안이 추가된 HTTP입니다
  클라이언트와 서버가 서로 비밀리에 약속된 방식을 통해 주고받는 내용을 암호화 하여 전달받기때문에
  하이재킹 공격을 통한 위험을 줄여줍니다
  또한 구글 검색결과로 HTTPS를 우선하여 보여주기때문에 SEO관점에서도 좋습니다

• 서버에 요청하는 HTTP Request를 HTTPS를 사용하지 않는다면, 전부 보여지게 되므로 불특정 공격자에게 노출이 되게 됩니다. HTTPS를 사용하면 Request와 관련된 모든 내용을 암호화하는 것으로 보안성을 높일 수 있습니다.