Fact

이번 프로젝트에서 백엔드를 맡아 API 서버, 관리자 페이지를 개발하고 서버와 관리자 페이지를 배포했다.
그리고 앱 에러 핸들링에 참여하였다.

Feeling

이번 프로젝트는 정말 힘들었다. 3차 프로젝트가 힘들다는 말은 들었었지만 이렇게 힘들 줄 몰랐다. 프로젝트를 마치고 나서 생각해보니 개발보다 팀 운영이 더 어려운 게 아닌가 하는 생각이 들었다. 내 파트를 개발할 때 에러가 발생하거나 하면 내가 해결하면 되는데, 회의에 참석할 때마다 팀원 간의 갈등으로 인한 날 선 분위기가 불편했다.

가장 큰 원인은 팀원들의 역량을 벗어나는 규모의 프로젝트 기획이었다. 처음 프로젝트를 기획할 때는 모두 희망에 차 이런 저런 기능과 시나리오를 추가했다. 하지만 프론트엔드를 맡은 팀원들이 이번에 리액트 네이티브를 처음 접했고, 또 부트캠프 참여 이전에 개발 경험이 적거나 없었다는 점을 감안하지 않아 결국 기획한 내용의 30% 정도를 구현하는데 그쳤다.
자만일 수도 있지만 나는 이전에 다니던 회사에서 다수의 프로젝트에 참여했었다. 그렇기 때문에 초기 기획 단계에서 이 규모의 프로젝트를 한 달 안에, 초심자들로 구성된 팀이 구현하기엔 어렵다고 생각했다. 하지만 팀원들이 열정적으로 서비스를 구상하는 분위기에 초를 치고 싶지 않았고, 어쩌면 내 예상이 틀렸을지도 모른다는 생각에 프로젝트의 규모가 지나치게 크다고 지적하지 않았다.

프로젝트 하반기에 접어들자 이를 뼈저리게 후회했다. 각자 맡은 파트를 개발하기로 하고 내 파트를 마쳤는데, 다른 파트에선 일주일 정도의 시간을 남겨두고 팀원들 간의 이해도 차이로 각자 맡은 파트의 개발 진행률이 들쑥날쑥했다. 기본적인 로그인, 회원가입 기능도 완성되지 않은 상태였다. 게다가 다들 열심히 하려는 마음이 있는데 개발 진행이 뜻대로 되지 않자 잠을 줄여가며 개발에 집중했고, 컨디션이 나빠져 신경도 예민해졌다.
이대로 가다간 발표도 하지 못하겠다 싶어 각자 개발을 하는 대신 줌에서 모두 모여 동시에 개발을 하며 에러가 발생했을 때 함께 에러를 해결하는 페어 프로그래밍을 하자고 권고했다. 오전 10시에 시작해 오후 10시 반에 끝나는 페어 프로그래밍을 하다 보니 성과도 있었지만 다들 스트레스를 많이 받았다.
결국 앱의 목표였던 약 복용 알림 기능과 건강 정보 입력, NFT 발행 기능을 구현하고 발표를 했지만, 다른 팀에 비하면 현저하게 낮은 수준이었다.

면접 단골 질문 중에 상사가 부당하거나 잘못된 지시를 했을 때 어떻게 행동하겠냐는 것이 있다. 나는 위계 질서가 철저한 가정에서 성장했고, 자신감이 부족해 내 행동의 영향력이 작다고 생각하는 사람이었다. 그렇기 때문에 저 질문을 받는다면 상사가 나보다 업무에 대한 이해도가 높고 지식이 많을 것이라 예상되기 때문에 부당하거나 잘못된 지시를 하더라도 나의 판단 미스로 생각하고 상사의 뜻을 따르겠다고 대답하리라 생각했다.
하지만 이번 프로젝트에 참여하면서, 모두가 '예'라고 할 때 '아니오'라고 할 수 있는 사람의 중요성을 깨달았다. 만약에 내가 초기 기획 단계에서 팀원들이 추가하고 싶은 기능을 우리 역량으로 힘들다고 반대했다면 분위기를 깬다고 눈총을 받았을 수도 있고, 내가 능력을 자만하다는 평가를 받았을 수도 있다. 하지만 그랬다면 팀원들 간의 갈등도 훨씬 적었을 것이고, 프로젝트의 완성도도 더 높아졌을 것이다. 내가 불편해하는 것들을 감수하고서라도 규모가 커지는 것을 막았어야 했는데 그러지 못한 것을 진심으로 후회한다.

이제 프로젝트를 마치고 취업 준비 단계에 접어들었다. 만약 내가 면접에서 상사가 부당하거나 잘못된 지시를 했을 때 어떻게 행동하겠냐는 질문을 받는다면, 이젠 그저 상사의 지시를 따르겠다고 대답하지 않을 것이다. 내가 생각하는 그 지시가 부당하거나 잘못되었다는 이유를 논리적으로 정리하여 상사에게 보여주며 상사와 그 지시가 적절한지 함께 검토할 것을 요청할 것이다. 물론 건방지다던가 말을 잘 듣지 않는다는 평가를 받을 수도 있지만, 장기적으로 볼 때 팀을 위해서는 다시 검토하는 것이 더 옳은 결정이기 때문이다.

Future Plan & Finding

프로젝트를 진행하면서 아쉬운 부분을 정리하였다. 이후에 다른 프로젝트를 할 때 다시 참고하려고 한다.

1. 메세지 발송 조회 크론 불확실

현재 서버에서는 메세지를 발송하기 위해 매 분마다 현재 실행 시간이 사용자가 입력한 메세지 발송 시간과 일치할 때 메세지를 발송한다.

//server.ts
schedule.scheduleJob('* * * * *', ()=>{ 
  sendMedicationAlert();
});

//MedicationAlert.ts
export const sendMedicationAlert = async () => {

    const alivePrescription = await Prescription.find({
        lastMedicationCount: {$ne:0},
        alertTime:moment().format("HH:mm")
    }).populate("userId")

    for (let alertData of alivePrescription) {
        const message = {
            android: {
                priority:'high',
                notification: {
                    title: `Pill So Good!`,
                    body: `${alertData.medicine} 먹을 시간입니다.`
                }
            },
            token: alertData.userId.firebaseToken
        }
    
        await admin.messaging().send(message);
    }
}

현재 개발 단계의 데이터 규모에서는 조건에 맞는 전체 데이터를 조회해 정확한 시간에 메세지를 발송한다.
하지만 만약에 서비스의 규모가 엄청나게 커져 전세계인이 우리 서비스를 이용한다면, 1분 내에 알림 조건에 해당하는 전체 데이터를 조회해올 수 있을까? 하는 의문이 들었다.
MongoDB의 성능 분석 포스팅을 읽어보니, 데이터 25만 건이 들어있는 디비에서 랜덤 숫자 1000건을 검색할 때 인덱스가 없을 경우 3117초, 인덱스가 있을 경우 1.0126 초가 걸린다고 한다.
2022년 7월 기준 전 세계 스마트폰 사용자는 66억 4,800만 명이다. 그 중 몇 퍼센트가 우리 앱을 서비스를 이용할지 모르지만, 그래도 생각해볼만한 문제라고 생각된다.

참고한 포스팅에서는 나무위키 데이터를 덤프해 테스트를 실행했다. 조회 건수에 따른 성능을 테스트해보고 싶지만 우선 순위가 더 높은 태스크들이 있기 때문에 우선 미뤄두려고 한다. 주말쯤에나 테스트 할 수 있을 듯 하다.

2. EC2 인스턴스 재시작 시 서버 재시작 구현 미완성

현재 EC2 인스턴스에서 배포된 서버는 쉘로 접속하여 직접 실행한 것이기 때문에 만약 어떤 이유로 인스턴스가 재시작된다면 관리자가 직접 서버를 가동하기 전까지 서비스를 이용할 수 없다.
이를 방지하기 위해 인스턴스 재시작 시 자동으로 서버 재시작을 하도록 쉘 스크립트를 작성해 실행해야 한다. 시간 관계상 이를 미뤄두었는데, 이 또한 차후에 구현할 예정이다.

마무리

생각해보니 기왕에 백엔드를 한 번 더 할거라면 Express.js 대신 Nest.js 를 사용해 볼 걸 그랬다. Nest.js는 개인 프로젝트를 하며 시도해봐야겠다.
빨리 취업하고 싶다. 좋은 회사로...

참고 문헌

https://soojle.gitbook.io/project/requirements/undefined-2/undefined-2-1/mysql-vs-mongodb
https://www.bankmycell.com/blog/how-many-phones-are-in-the-world