SAT 시험 웹 서비스 구현 회고

Online SAT simulator 구현 페이지

프로젝트 개요 및 목표

• SAT 시험을 대비하기 위한 웹앱 구현
• 실제 온라인 SAT 앱과 최대한 비슷한 경험 제공이 목표
• 선생님이 시험을 칠 학생들을 관리할 페이지도 구현
• 기한은 2주차에 시험페이지 프로토타입 제공, 4주차에 완성 페이지 제공

실제 SAT 앱에서 사용되는 용어 및 주요 기능 | 펼쳐서 보기

문제 단위 | Exam, Section, Module, Question

• Exam: 시험 set 단위. 가장 넓은 단위
• Section:
  • Exam의 하위 단위. Reading and Writing(영어)과 Math(수학)로 구분(과목이라고 생각하면 됨)
  • Section이 바뀔 때 Break time이 존재(10분)
  • Section마다 제한 시간이 다름
• Module: Section의 하위 단위. 각 Section은 2개의 Module로 이루어짐.
• Question:
  • 가장 하위 단위. 문제의 단위.
  • Passage(지문), Question(문제), Choices(선택지), Correct Answer(정답)으로 구성
  • Passage와 Choices는 nullable
  • Passage가 없는 문제는 레이아웃이 좌우 분할에서 무분할로 변경됨
  • Choices가 없는 문제는 단답형(주관식)문제

시험 페이지

• annotate
  • 지문에 특정 영역을 선택해 표시하고 해당 영역에 메모 입력
• mark: 나중에 볼 Question을 표시, Module단위가 끝날 때, 혹은 navigator에서 한눈에 확인 가능
• navigator
  • Module 단위에서 다른 Question으로 바로 넘어갈 수 있는 장치
  • marked Question과 un Question을 한눈에 확인 가능
• timer: Module 단위에서 남은 시간을 보여줌, hide 버튼으로 숨기기 가능
• calculator: 계산기 및 수식을 입력하면 좌표평면에 그래프를 볼 수 있음

학생 관리 페이지 요청사항

• 시험 CRUD
  • 편집할 때 사진 첨부, 수식 입력, bold, underline 입력
  • 좌우/무 분할 배치 선택
  • 주/객관식 선택
• 학생 계정 생성/삭제
• 학생에게 시험 배정 (시험은 각 학생 당 하나만 배정)
• 시험친 학생의 성적 열람

 

  시험페이지 프로토타입 제공이 우선이었기 때문에 관리자 페이지를 배제하고 시험 페이지부터 만들기 시작했다. 목표가 실제 시험과 비슷한 경험을 제공하는 것이기 때문에 주관적인 UI/UX을 배제하고 최대한 비슷하게 만들었다.

스타일링 | 아이콘 그리기 / 스타일링 재사용(안함) / TailwindCSS

  스타일링은 크게 복잡한 부분이 없어 금방 만들 줄 알았지만 생각보다 오래걸렸다. 최대한 비슷한 느낌을 주기 위해 아이콘도 똑같은 파일을 쓰고 싶었지만 네이티브 앱에서 사용되는 아이콘 파일을 찾을 수 없어서 pigma로 직접 그렸다. pigma에서 픽셀 단위로 그리는 게 생각처럼 되지 않았다. 그림판처럼 픽셀을 똥똥똥 채울 수 없어서 애먹었는데 라인을 선택하고 라인 중간에 꺾이는 점?을 추가해 디테일한 픽셀수정을 할 수 있었다. 정물화 그리는 것처럼 나름 재미있는 작업이었다.

 

  스타일링 패턴을 잘 못 찾아서 재사용을 포기하고 인라인으로 한땀한땀 스타일링을 적용했다. 적용하다보니 재사용 패턴이 보였지만 나중에 한번에 리팩터링 해야지… 하는 생각에 미루고 미루다보니 대부분의 스타일링을 재사용없이 인라인으로 구현했다… 변경에 취약한 구조다. 미루지 않고 리팩터링을 바로하는 게 쉽지 않은 것 같다… 규칙적인 생활 습관 가지기, 간간이 스트래칭 하기와 마찬가지로 미친바른생활맨이 아니라면 쉽지 않은 일이다. 노력이 필요하다.

 

  거의 모든 프로젝트에서 styled-components를 쓰다가 tailwindCSS를 한 번 사용해보고 꽤 편해서 이번 프로젝트는 tailwindCSS를 사용했다. 개인적으로 스타일링은 분리되기보단 최대한 응집되어있는 게 더 편해서 하나의 컴포넌트에 스타일링을 함께 넣는 것을 선호한다. 그래서 styled-components를 사용했을 때도 스타일링 파일을 따로 분리하지 않고 컴포넌트 함수 아래에 스타일링을 선언해 사용헸다. 그래도 불편했던 점이 각 JSX 태그에 적용된 스타일링을 보려면 아래로 내려가서 확인해야 했다. 다른 파일이 아닌 것에 감사했지만 tailwindCSS는 인라인 스타일링처럼 각 태그에 스타일링을 할 수 있다는 점이 응집도 면에서 매우 유리했다. 스타일링이 분리가 안돼 복잡해보일 수 있지만 그만큼 복잡해진다면 컴포넌트를 분리할 때라는 신호다. 이 신호를 무시하고 그냥 구현할 때가 많지만 말이다…

갑자기 분위기 프로토타입

  1주차되는 주말에 클라이언트에게 갑자기 지금까지 완성된 프로토타입을 볼 수 없겠냐는 요구를 받았다. 아직 백엔드는 전혀 만들어지지 않아서 급한대로 msw로 모킹한 데이터를 보여주는 사이트를 파서 공유해드렸다. 컴포넌트 단위로 구현해 뭐라도 보여줄게 있어서 다행이었다. 짧은 단위로 결과물 피드백을 받을 수 있다는 게 좋은 경험이었다.

 

  클라이언트분이 사례로 커피값을 주셔서 뿌듯했다. 백엔드 분에게도 커피값을 반으로 나눠서 드렸다. 그런데 혼자 만든 결과물에 몫을 나눈다는 게 솔찬히 배가 아파왔다. 처음부터 커피 값은 없었던 거였고 백엔드는 몫을 나눠 달라고도 하지 않았지 않았다. 동료에게 감사하는 마음이 아가리에 있지 않고 가슴에 있었다면 어땠을까. 콩알만한 일에도 솔찬히 아픈 배는 이보다 더 큰 일이 있었다면 어떻게 될지.. 작은 일이었지만 내 정신을 되돌아보게 해주는 일이었다. 진정으로 감사하기 위해선 깊은 생각과 관심이 필요하다고 한다. 동료에게 감사하는 마음을 진정으로 가지기 위해선 감사한 일을 늘 생각해야겠다.

요구사항을 명확히 하지 않은 스노우볼

  외주 계약 당시 계약서에 요구사항을 기제했으나 구체적으로 적어놓지는 았았다. 그래서 의뢰를 직접 받은 백엔드 개발자로부터 구체적인 요구사항을 전달 받거나 백엔드 개발자가 만든 API에 의존해 작업을 진행했다. 그런데 이 API에 미심쩍은 부분이 있었다. 학생에게 배정된 시험을 확인하는 API에서 배정된 시험이 배열이 아닌 단일 값이었다. 학생에게 시험을 배정하면 이전에 배정된 시험은 사라지고 새로운 시험이 배정되는 형식이었다. 한 학생 당 하나만의 시험을 가지고 있을 이유가 있는지 궁금했다. 선생님이나 학생 입장에서 여러 시험을 배정 받는 편이 편리할 것 같고 우리가 모방하고 있는 실제 SAT 시험 프로그램에서는 한 학생이 다수의 시험을 배정 받을 수 있기 때문에 API에 대해 의문을 제기했다.

 

  백엔드 개발자는 본인이 기억하기로는 지금 만든 방식이 의뢰인의 요구사항에 맞지만 다시 한 번 물어보겠다고 했다. 그래서 일단 현재 만들어진 API를 기준으로 배정된 시험이 단일 값으로 온다고 가정하고 프론트엔드를 구성했다. (지금 생각해보면 추후에 배열이 올 때를 대비해 구조를 유연하게 구축하려고 노력했어야 했다) 이 부분에 대해선 따로 말이 없어서 이대로 배포까지 마쳤고 나도 이 부분에 대해 잊고 있었다. 개발 일정이 끝나고 약 일주일 쯤 뒤에 의뢰자로부터 이 부분에 대해 이야기가 나왔다. 시험을 여러 개 배정할 수 있게 바꿔 달라는 요청이었다. 

추가 기능인가 미구현된 요구사항인가

  계약서에는 배포 이후에 추가 기능 요구 시 추가 비용을 받는다고 명시가 되어있었다. 의뢰인의 요청은 문서화 된 요구 사항에 명시되어있지 않았고 개발 일정이 모두 끝난 상황이니 이 기능은 추가 기능 추가 비용을 받아야 한다.

 

  하지만 내가 느끼기에 이 일은 마치 일부러 프로그램을 덜 만들어두고 그걸 고쳐주고 비용을 받는 느낌이었다. 의뢰인의 해당 요청은 요구 사항에 구체적으로 명시가 되어있지 않아도 나는 우리가 만든 프로그램에 기대할 수 있는 상식적인 기능이라 생각했기 때문이었다. 이 작업은 추가 작업이 아닌 누락된 요구 사항을 작업하는 일이라 추가 비용을 받지 말자고 주장했다.

 

  개발 초기에 의문이 들었던 부분에 대해 의뢰인에게 다시 확인을 하지 않았기도 해서 추가 비용을 받지 않는 것으로 협의하고 해당 부분을 수정했다.