TeachMon이 BugMon 으로 되었던건에 대하여

🥹 프로젝트 시작

프로젝트는 작년 디자인 프로젝트 수행평가에서 시작하였다.
자습감독이 구글시트로 시행되고 있고 힘들다는 것을 해결하기위해서 이 프로젝트는 기획되었다.
디자인을 직접해보고 디자인 선생님께 실력늘었다고 칭찬들은건 아직도 기억난다.
하지만
이건 또 어케 만들지 이건 어케하지 하면서 불안 반 기대 반 이었다.
일단 우리는 팀을 구했고 총 5명이 모이게 되었다. 하지만
자습감독이 어떻게 이루어지는지부터 설명하고 티치몬을 이해했어야해서 처음부터 순조롭지는 않았던 것 같다.

🐴 제작과정

일단 제작기한이 2월 10일까지 모든 기능구현을 원하셨다. 그때부터 테스트를 해보며 진행해야 실제로 3월달부터 쓰일 수 있다고 하셔서이다.
그렇다보니 아직 tsx는 미숙해서 공부를하며 사용하기에는 시간이 오래걸릴것같아서 그냥 jsx로 개발을 진행하였다.(솔직히 미숙하게나마라도 ts쓸걸 후회하고 있다.)
그래도 처음으로 zustand 와 React-Query 를 써보면서 뿌듯하기도하고 관리하기도 훨씬 쉬워서 너무 편리했다.

import { create } from 'zustand';

const useLocation = create((set) => ({
    place: '',
    setPlace: (newPlace) => set({ place: newPlace }),
}));

export default useLocation;

간단한 장소 상태저장

---

export const usePatchMovement = () =>{
    const queryClient = useQueryClient();
    return useMutation({
        mutationFn : (props)=> API.patchMovement(props),
        onSuccess:(_, variables)=>{
            queryClient.invalidateQueries(['getMovement', variables.day]);
        },
        onError:(err)=>{
            console.error("수정 실패 ", err);
        }
    })
}

훅을 활용한 이석 수정 쿼리

현재는 또 어떻게해야 더 효율적으로 관리할 수 있을까를 생각해보고있다.
하지만 제일 힘들게했던건 구글 로그인이었던것 같다...
백엔드 전체부담으로해서 내가 할 수 있는게 없어서 답답하기도하고 선배분까지 부르면서 도움을 요청해서 겨우 해냈다. 🙇‍♂️ (하지만 나중에 알게된건 구현한 구글로그인 방식이 잘못되어서 수정을해야 했었다...)
그렇게 어찌저찌 2월 10일까지 자습감독 자동배정빼고는 완료했던것 같다.
자동배정도 몇일정도만 있으면 만들 수 있어서 걱정은 없었다.

🎂 완성

일정이 늦어지긴했지만 결국엔 2월 26일까지는 테스트를 완료하고 개발을 완성했다. 이때까지만해도 모든기능들을 테스트해보며 이게 진짜 되네?? 하며 느낌이 굉장히 좋았다. 배포하는 과정도 docker-compose 를 이용하고 하면서 docker에대한 많은 공부가 되었던 것 같다.

🔗 운영

실제로 3월달부터 사용하기위해 우리는 필요한 데이터들을 사이트에 적용시켰다.(학생, 선생님, 방과후 데이터)
우리도 운영하면서 에러 몇개나올것이라고 생각을했다. 하지만 나의 예상은 훨신 초월했다...

🐞 BugMon출현

자습감독 교체 에러, 학생들 자습상태 중복생성 에러, 메인 달력 에러, 학생 제거, 방과후 동기화에러, 방과후 업로드에러, 방과후 저장에러, 이석작성 에러,
등등의 에러가 있었다.
거기에 선생님들께서 학교 구글계정이 아닌데 로그인 시도를 하셔서 오류가 났다고 하시거나 학교 방과후데이터가 학생이 겹치게 되면서 로직이 꼬이거나 하기도 하여서 우리의 신뢰는 바닥을치게 되었다.
우리딴에서도 이상함을 느꼇다 분명 테스트를 해보고 기능들을 통과시켰는데 왜 이렇게 되는건지.. 사실 티치몬이 운영되기 전에 우리의 로직이 바뀌었기 때문이었다.
우리는 우리가 알고있는 자습감독 로직대로 코드를 짰었지만 학교에서의 자습감독 방식이 바뀌어버렸다. 그래서 다 만들었던 기능들을 다시 만들고 수정하느라 좀 더 시간이 걸렸던 것 같다.
거기에 운영 2일전에는 학생들 자습에대해서 소통 오류까지 있었다.
하지만 그 부분은 우리에게 엄청난 타격이었다. 자습 로직을 수정해서 그 부분때문에 앞서말한 에러의 80%는 그 부분때문에 일어났다.
그렇게 티치몬은 에러덩어리의 버그몬소리를 듣게된것이다.

느낀점

이 프로젝트를 하기전에는 대회용이나 공부용으로 팀원들과 프로젝트를 해보았지만 실제로 운영할 목적으로 만든건 티치몬 프로젝트가 처음이었다. 기대에 부푼마음으로 개발하고 운영해보았지만
솔직히 운영 초기엔 너무 절망적이었다. 기대의 티치몬이 이렇게 되다니...왜 이렇게 된거지 도대체 왜 라고 생각하며 스트레스를 겁나 받았다. + (선생님들께 너무 죄송했음..)(진짜 죽고싶었음..ㅋㅋ)

하지만 다시 생각해보고나니 이것들은 다 우리의 미숙함때문이었다는것을 깨달았다. 시스템 수정이 있어도 오류가나면 코드잘못짠 놈들 잘못이지 지시의 문제는 아니기때문이다..소통의 오류는 걍 내잘못이다... 참... 그걸 확인했어야지 뭘 하는건지...
테스트의 중요함과 소통의 중요함은 무엇보다 뼈저리게 느끼게 된것 같다.