[장고로 TMI 퀴즈 만들기] 벼락치기로 일단 되게 만들다1

🍊 계기

오늘은 드디어 교육 실습 2주차다. 학생들이랑 체육대회도 즐기고, 수업도 편하게 하기 위해서는 빠르게 친해져야할 것 같다는 압박감이 있었다. (물론 압박 외의 개인적 욕심도 있었다) 개발 공부 해야할 것은 많은데, 교생이라니.. 하며 툴툴대다가 두 마리의 토끼를 잡을 방법이 떠올랐다! 개발하면서 학생들과 친해지는 것 (ㅋㅋ)

 

그래서 smore나 구글폼같은 툴을 사용하지 않고, 나를 소개하는 내용이 담긴 퀴즈를 만들기로 결심했다.

 

# 비하인드

왜 장고로 했는가? 사실 바닐라 자바스크립트로 만들 생각에 설렜던 것인데 약 하루-이틀만에 만들어야하는 것과, 나의 자스 실력을 고려했을 때 어려워보였다. 리액트는 얼마나 GOD인가... 그러나 반드시 교생 이후에 리팩토링도 하고 바닐라JS로 마이그레이션 해야겠다.

 

🍊 퀴즈 기획내용

기획은 거의 2시간.. 아니 더 짧게 한 것 같다. 디자인 뽑는 시간은 스모어 참고해서 매우 최소화하였다.

 

문제유형은 아래와 같이 5개다. 부분점수 부여로 케이스를 다양하게 하기 위해 복수선택 유형을 포함시켰다. 서술형은 답이 너무 다양하게 나올 것 같아서 퀴즈 종료 후 하고 싶은 말을 남기는 용도로만 활용했다.

 

문제내용은 아래의 예시와 같이 정말 TMI(Too Much Information)로만 구성했다. 대신, 약간의 학생들의 눈높이와 유행에 맞는.

각 문제의 배점을 달리하고, (나만의?) 재미 요소로 특정 선택지에 대한 패널티(감점)도 적용시켰다. 

문항 예시1

문항 예시2

 

---

🍊 핵심 구현 사항

개발을 시작하기 전, 핵심 구현 사항들을 아래와 같이 나누어 생각하였다.

- 선택지를 고르면 바로 다음 질문으로 화면 전환

- 문제 유형에 따라 다르게 제출되는 답안

- 유저가 제출된 답안이 해당 유저의 점수로 쭉 누적되어 최종 점수 산출

 

 

1) 선택지를 고르면 바로 다음 질문으로 화면 전환

이 부분이 사실 바닐라 JS로 처음 구현하려 했을 때의 멘풍포인트였다. 라우팅을 어떻게 구현할지?가 막막했고, 문제 유형이 계속 반복될텐데 이 재사용되는 부분을 어떻게 효율적으로 짤지, 질문/선택지내용/배점 데이터를 어떻게 뿌려줘야할지가 그려지지 않았다. 시간이 더 있었다면 기존의 블로그 선배들의 좋은 글들을 참고할 수 있었겠지만 충분치 않았다 🥲

 

결국은 장고 template에서 1번~14번 문항별 모든 html파일을 다 작성했는데 큰 흑역사 플젝 🤢으로 남지 않을까 싶다...

(아니지 하면서 성장하는거니까!)

 

/tmi_quiz/urls.py 일부

path('question/<int:question_id>', views.question, name="question")

 

/quiz/views.py 일부

def question(request, question_id):
    ongoing = Person.objects.get(name = request.user)
    return render(request, 'q{0}.html'.format(question_id), {'ongoing': ongoing})

 

화면 전환은 2가지 경우로 나눠서 생각했다.

(1) 어차피 하나의 답을 고르는 선택지는 - 어떤 선택지 버튼을 누르는 것과는 상관없이 클릭만 하면 무조건 다음 질문으로 전환하면 되고

(2) 복수의 답을 고르는 선택지는 - 내가 선택할 답들을 다 고른 후에 넘기기 버튼을 직접 누르고 나서야 전환이 되어야 한다

 

여튼 이 두 가지 경우 모두 선택지 엘리먼트들에다가 click이벤트리스너를 등록하여 클릭 시 location.href를 직접 지정해주었다.

 

/quiz/templates/q4.html 일부

<script>

    // ... 생략 ... //
    const $choices = document.querySelectorAll(".basic-btn");
    for (let $choice of $choices) {
      $choice.addEventListener("click", (e)=> {
       
        console.log(e.target.innerText);
        if(e.target.innerText === "항정살") {
          // 정답 처리 (점수 추가)
          score += 5;
          console.log("정답!")
        }

        window.localStorage.setItem("{{ user.username }}", JSON.stringify([score]));
        location.href = "http://localhost:8000/question/2"
      })
    }
  
  </script>

 

2) 문제 유형에 따라 다르게 제출되는 답안

 

🤓 2지선다 1선택, 4지선다 1선택🤓

선택지 엘리먼트 모두에 클릭 이벤트리스너를 등록한다. 클릭한 엘리먼트의 내용이 정답과 일치하면 점수를 올리는 방식으로 처리하였다. 재미를 위해 어떤 선택지를 고를 시에는 감점되도록 하였다.

let score = 0;
    const $choices = document.querySelectorAll(".basic-btn");
    for (let $choice of $choices) {
      $choice.addEventListener("click", (e)=> {
       
        console.log(e.target.innerText);
        if(e.target.innerText === "정답멘트") {
          // 정답 처리 (점수 추가)
          score += 5;
          //console.log("정답!")
        }

 

🤓 이미지 2지선다 1선택🤓

이미지 선택지도 위의 유형과 거의 동일한 방식이다. 다만, 유저가 클릭하는 영역에 따라 이미지 div가 눌리기도 하고, 이미지 설명이 눌리기도 했다. 두 경우를 모두 아우르기 위해 정답 텍스트를 포함하거나, 이미지 순서가 정답에 해당하는 경우를 조건으로 정의했다.

  for (let $choice of $choices) {
      $choice.addEventListener("click", (e)=> {

        if(e.target.innerText.includes("스파이크") || e.target.id.includes(2)) {
          // 정답 처리 (점수 추가)
          score += 4;
          console.log("정답!");
        }

 

🤓 4지선다 다중 선택🤓

이 유형이 나름 까다로웠다. 다음과 같은 사항을 모두 고려해야 했기 때문이다.

(1) 유저가 고른 선택지가 "선택되었음" 또는 "취소되었음"이 표시되어야 한다.

(2) 다음 문항으로 넘어가기 전 "최종"적으로 선택된 옵션들을 반영해야 한다.

 

아래와 같이 4가지 선택지에 대한 선택 상태(isChecked)를 boolean 배열로 관리하였다.

➡️ 점수 업데이트는 다른 유형들과 달리 사용자가 직접 다음 문제로 넘어가는 버튼을 눌렀을 때 처리되도록 했다. '다중 선택'이란 유저 입장에서는 계속 선택한 케이스들을 변경할 수 있기 때문에 직접 최종 상태를 결정하는 권한을 넘겨주어야 한다고 생각했다.

 let score = 0;

    let isChecked = [false,false,false,false];

    for (let i=0; i<4; i++) {
        $choices[i].addEventListener("click", (e) => {

        // 체크박스 체크처리
        isChecked[i] = !isChecked[i];
       
        // 체크박스 색깔표시
        if (isChecked[i]) {
            $choices[i].children[0].style.backgroundColor = 'yellow';
        } else {
            $choices[i].children[0].style.backgroundColor = 'white';
        }
        })
    }

    $nextBtn.addEventListener("click", (e) => {
        isChecked.forEach((check, idx) => {
            if (check && (idx === 1  || idx === 2)) {
                score += 6;
            }
        })

 

아래와 같은 모습으로 동작하게 되었다.

3) 유저가 제출된 답안이 해당 유저의 점수로 쭉 누적되어 최종 점수 산출

처음에 이렇게 생각했다. 로그인하는 유저가 아닌데, 어떻게 관리하지?

- 닉네임 중복체크도 하고 싶고.

- 유저를 등록해서, 해당 유저의 점수로 모든 문항의 점수가 누적되도록 관리하고 싶고.

 

아주 옛날옛적(?) 호랑이 담배피우던 시절, 장고가 자체적으로 제공하는 User모델과 소셜 로그인을 구현했던 경험이 문득 스쳐갔다. 닉네임 중복체크하기에 매우 편리하겠다고 생각하여, 장고 auth의 User모델을 사용하기로 했다.

 

models.py

from django.db import models
from django.contrib.auth.models import User

class Person(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    name = models.CharField(max_length=30)
    comment = models.TextField('하고 싶은 말')
    score = models.IntegerField(default=0)
    # "1번점수-2번점수- ... -13번점수" 형식으로 저장

    def __str__(self):
        return self.name

 

어차피 내가 유저 데이터에 구성하고 싶은 것은 (이름 / 마지막 문항에서 작성하도록 하는 '하고싶은 말' / 제출 답안)뿐이었다. 

이때 User 모델을 커스텀하여 쓰는 것이기 때문에 가장 편리해보이는 OneToOneField 방식을 택했다. 어차피 닉네임 부분만 연결되어도 되는 구조이기 때문에. 

https://docs.djangoproject.com/en/5.0/topics/db/examples/one_to_one/

One-to-one relationships | Django documentation

 

편법(잔머리?)으로도 볼 수 있지만 ㅋㅋ 유저가 닉네임을 입력하면, 해당 닉네임에 대한 중복 체크를 실행하고 자동으로 회원가입 후 로그인되도록 처리하였다. 아래는 views에서의 처리 내용이다. 

 

(+) 중복되는 닉네임을 작성할 경우 노란색으로 경고 메시지가 입력창 아래에 작게 표시되도록 하였다.

 

views.py

def login(request):
    found_user = User.objects.filter(username = request.POST.get('username'))

    if len(found_user) > 0 :
            error = '이미 존재하는 닉네임입니다.'
            return render(request, 'nickname.html', {'error':error})

    ## 유저 회원가입 후 로그인 처리
    if request.method == 'POST':
        new_user = User.objects.create_user(
            username = request.POST['username'],
        )
        auth.login(
            request,
            new_user,
            backend='django.contrib.auth.backends.ModelBackend'
        )
        print(new_user)
    
        Person.objects.create(
            user = new_user,
            name = request.POST['username']
        )
        return redirect("tutorial")

    return render(request, 'nickname.html')

 

 

이렇게 돌아간다!

 

마지막에 "하고 싶은 말"을 입력받을 때도, 현재 문항을 풀고 있는 로그인된 유저와 대응하는 Person을 찾아 추가해주었다. 아래는 views에서 구현한 부분이다.

def comment(request):
    if request.method == 'POST':
        #print(request.user, '########')
        ongoing_user = Person.objects.filter(name = request.user).update(
            comment = request.POST['comment']
        )
        return redirect("scoring")

    return render(request, 'comment.html')

 

 

그런데 개발 중에 나를 괴롭힌 큰 1가지 미스테리가 있었는데 ,,,

이것때문에 소요 시간이 거의 2배는 되었던 것 같다. 바로 점수 누적 방식이었다.

 

👉 내가 처음 생각했던 방식은 아래와 같다.

 

TextField를 활용했다. "1번에서 얻은 점수-2번에서 얻은 점수-...-N번에서 얻은 점수" 이런 식으로 업데이트하는 방식이었다. 

ex) 3번 문항까지 답변했으면 "5-2-3" 이렇게 저장될 수 있고, 4번 문항에서 1점을 얻었다면 "5-2-3-1" 이런식으로 추가된다. 이렇게 해서 마지막 문항까지 답변 후 -기준으로 split하여 총점을 환산했다.

 

동작을  하긴 했다. 그런데 매우매우매우~ 느리게 선택지를 골라야만 제대로 획득한 점수가 담겼고, 심지어 느리게 담아도 제대로 담기지 않을 때도 있었다. 이유는 모르겠으나 ,,, 내 생각엔 불필요하게 조회하고 업데이트하는 과정 때문에 지연시간이 발생하지 않았나 싶다.

(이 부분은 꼭 찾아내야겠다. 장고의 object.filter 소요 시간 등. 키워드는 모르겠긴 한데,,, )

 

👉 결국 로컬스토리지 방식으로 바꾸었다. 

(1) 1번 문항에서 로그인한 유저의 닉네임을 기반으로 로컬 스토리지에 빈배열을 등록한다.

 window.localStorage.setItem("{{ user.username }}", []);

 

(2) 매 문항마다 이전까지의 획득 점수 기록이 담긴 배열을 getItem으로 읽어온다. 

(3) 현재 문항에서 얻은 획득 점수를 추가한 배열을 만들어 다시 로컬 스토리지에 등록한다. 

const $choices = document.querySelectorAll(".four-btn");
    let prevScore = JSON.parse(window.localStorage.getItem("{{ user.username }}"));
    let score = 0;

    for (let $choice of $choices) {
      $choice.addEventListener("click", (e)=> {
       
        console.log(e.target.innerText);
        if(e.target.innerText === "정답멘트") {
          // 정답 처리 (점수 추가)
          score += 4;
        }

        const newScore = [...prevScore, score];
        console.log(newScore);

        window.localStorage.setItem("{{ user.username }}", JSON.stringify(newScore));
   
      })
    }

 

(4) 점수 표시 이전 페이지에서 점수 기록들을 총합산하여 최종 점수를 산출한다. 

 const finalScore = [...JSON.parse(window.localStorage.getItem("{{ user.username }}"))];
    let newScore = 0;
    finalScore.forEach((score) => {
        newScore += score;
    })
    
 fetch('/answer', {
        method: 'POST', 
        body: JSON.stringify({score: newScore})
        })
        .then(response => response.json())

    setTimeout(()=>{
        location.href = "http://localhost:8000/result"
    }, 6000)

 

 

(5) views.py에서 현재 로그인하고 있는 유저와 대응하는 Person의 스코어로 최종 점수를 업데이트한다. 해당 점수는 result페이지에서 표시된다.

 

views.py

@csrf_exempt
def answer(request):
    request_body = json.loads(request.body)
    
    

    print(request_body['score'],'******')
    ongoing_user = Person.objects.filter(name = request.user).update(
            score = request_body['score']
        )
    return HttpResponse({'signal': 'great'})

 

🚨 귀요미 유저들의 트러블(에 대한 처리)

사실 처음에는 문항마다 얻은 점수를 기록하진 않았다. 바로바로 누적점수를 남기는 형태였다.

그런데 울학교 귀요미들(유저들)이 버그를 찾았다며 버튼을 마구 누르는 편법을 발견했다. 

 

다음 문항으로 넘어가기 전, 정답 선택지를 여러 번 연타하면, 페이지 전환 전까지 연타한 만큼 모두 점수에 반영된다. (2000점을 달성한 친구가 생겨났다 ㅋㅋㅋ)

 

1등 점수 획득자에게 상품을 걸었던 상황이었기에 재빠른 수정이 필요했다. 내가 좋아하는 개발 블로그에서 이를 위한 여러 가지 옵션을 찾을 수 있었다.

https://yceffort.kr/2020/10/prevent-double-click-on-button

(함수형으로) 자바스크립트로 HTML 버튼 중복 클릭 방지하기

- 글로벌 플래그 사용하기

- 핸들러 날려버리기

- 버튼 disable 처리하기

- 지역변수 처리하기

- 고차함수 사용하기 (=아마도 최선의 방법)

 

이중 필자가 적은 고차함수 외의 선택지들은 한계점이 있었다. 가령, disable처리하면 나의 로직에서는 잘못 눌렸을 경우 다음 문항으로 넘어가지 못하게 될 수도 있다 (유저가 어떤 문항에 탈출구도 없이 갇히는 격이다 ,,) 글로벌 플래그도 여전히 연타 문제에서 자유롭지는 않다. (아마도 최선의 방법이라고 한 고차함수도 마찬가지)

 

결론은, 완벽히 막을 수 있는 방법이란 없었는데... 사실 개발이라는 것은 이런 문제를 풀 때 더 재밌는 것이 아닌가?  (ㅎ . ㅎ) 💛

➡️ 내가 선택한 방식은 어차피 연타를 누르는 건 못 막으니, 문항별 획득 점수 로그를 남기는 것이었다. 고득점자들의 로그를 확인해서 일부 실격처리하면 되기 때문에!

 

➡️ 생각해보면 점수 반영을 페이지에서 하는 것이 아니라, 페이지별로 최종 제출한 "선택지"에 대한 로그를 남겨서 결과 표시 전에 최종 채점하는 로직으로 풀었다면 발생하지 않을 문제인 것 같다. (우리가 일반적으로 시험을 보고 채점하는 과정처럼.) 이렇게 바꿔봐야겠다. 

---

🍊 이후 처리 & 확인해야 할 것들

- 중복되는 닉네임이 조회되었을 경우, 에러 메시지 뜨고 새로운 닉네임으로는 제대로 작동하는가?

- 배포 후 화면 전환 시 server error 불규칙하게 뜨는 이슈 (이건 심각한 문제임. 자꾸 유저가 처음부터 해야 하는 경우가 있으니까)

- 부드러운 화면 전환

 

제한된 시간 안에 하느라 마구잡이 코드를 쓰긴 했지만, 배포해서 간단한 문제 해결에 대한 고민을 할 수 있어 행복했다. 여러 방법을 고려하는 과정 자체가 재밌던 것 같다. 물론 이후 리팩터링이 더 중요하겠지만 ㅎㅎ...

 

교생 끝나고는 꼭 . 하아 기말기간이긴 하겠지만, 기말고사 끝나서라도 꼭 wrap-up하자.