About Team management

1. 더 복잡해진 타임라인 관리

5월 14일경 MVP 구현이 마무리된 이후, 이번주 월요일인 5월 16일부터는 MVP 보수 작업에 들어갔다. 최종적으로 유저 테스트를 실행하기 이전에, 실제 유저가 사용하기에 최소한 불편하지 않을 수준으로 MVP 기능을 보수 및 개선해야할 필요가 있었기 때문이었다.
MVP 보수 작업은 모든 팀원이 함께 진행하는 것이 아니라, 각 팀원들이 자신이 맡은 기능/페이지에 한하여 진행되는 작업이었다. 그리고 목표 수준이 딱 정해져 있는 것이 아니라, 개발 과정에서 버그가 발견될 때마다 보수 작업해야하는 업무량은 늘어나는 것이기 때문에, 언제쯤 최종적으로 마무리될 지 가늠하기가 어려운 특징을 가진 작업이었다.

그래서 팀의 전체적인 업무 스케줄을 관리하는 데 매우 애를 먹었다. MVP 보수 작업을 진행하는 팀원과 그렇지 않은 팀원이 매일 조금씩 다르며, 각 팀원의 MVP 보수 작업이 언제 최종적으로 완료되는지도 정확하게 예측하기 어려운데다가, 우리 팀은 MVP 보수 작업 이외에도 1)마케팅 집행 준비, 2) MVP 외 추가 기능 구현이라는 업무도 진행해야 했기 때문이다.

그래서 나는 MVP 보수 작업에 한해서 팀원들의 업무 진행상황을 체크하는 방식을 변경했다. 프로젝트 초기에는 모든 업무별로 구체적인 업무 데드라인을 중심으로 팀원들의 업무 진행상황을 체크했었는데, MVP 보수 작업이라는 팀의 중요한 업무의 데드라인이 명확하게 예측이 되지 않는 상황이었기 때문에, MVP 보수 작업은 매일마다의 진행 경과만 체크했다.

즉, MVP 보수 작업이라는 건 어차피 버그가 발생할 때마다 유동적으로 진행해야하는 업무이니 체계적으로 관리해야 할 업무 내용에서 제외한 것이다.

덕분에, 마케팅 집행 준비나 MVP 외 추가 기능 구현의 타임라인에 조금 더 신경을 기울일 수 있게 되었고, 나도 MVP 보수 작업의 진행상황을 점검해야한다는 압박감에서 벗어나, 내가 구현해야할 추가 기능들을 개발하는 데 시간을 좀 더 편하게 할애할 수 있었다.

2. 해야 하는 일 VS 하고 싶은 일 VS 현실적으로 할 수 없는 일

기획 회의를 하다보면 필연적으로 맞닥드리게 되는 이슈인 것 같다. 사람은 저마다의 흥미와 관심을 가지고 있을 수밖에 없기 때문에, 같은 업무를 하더라도, 업무 안에서 '해야 한다고 생각하는 세부업무', '하고 싶다고 생각하는 세부업무', '현실적인 타임라인 안에서 할 수 없는 세부업무'에 대한 생각이 다를 수밖에 없다.

나는 지난 주에 마케팅 회의, 추가 기능 구현에 대한 회의를 팀원들과 진행하면서, 이를 한번 더 크게 느낄 수 있었다. 그런 와중에 내가 든 생각은 나의 생각과 다르게 팀의 업무 방향이 결정된 상황에서, 팀장으로서 나는 업무의 속도나 방향은 어떻게 관리해야할까? 였다.
아직까지 명확한 결론은 내지 못했지만, 지금까지 드는 생각은 팀원들에게 항상 현실적으로 남은 시간을 알려주고, 현실적으로 할 수 없는 일은 내치고 해야 하는 일에 집중하게 하고, 한편으로는 데드라인 안에 하고자 하는 목표를 달성할 수 있도록 팀원을 독려하는게 팀장의 역할이라는 생각이 들었다.

그렇게 팀원들을 독려하고, 피드백하여 팀의 속도와 방향을 잘 유지하고자 한다.

About tech

1. 알림/문자전송 스케줄러를 다른 서버로 이관

기존에 메인 서버에서 실행되는 스케줄러는 크게 세개였다. 그룹러닝 D-day/start/end 알림을 생성 및 관련된 유저에게 문자를 발송하는 스케줄러가 그것이다.
이번주에는 그 스케줄러를 메인 서버에서 분리하고, 별도로 해당 스케줄러 전용 ec2 instance를 구축해서 이관하는 작업을 진행했다. 이유는 크게 두가지였다.

• 그룹러닝 D-day, start, end 알림을 유저에게 문자로 발송하는 것은 서비스에서 매우 중요한 컨텐츠이기 때문에, 메인 서버가 꺼지더라도 계속 스케줄러는 작동되어야 하기 때문이다.
• 메인 서버에서 해당 스케줄러가 작동될 때마다 사용하는 CPU 사용량은 적게는 2.3%, 많게는 7~11% 이기 때문에, 메인 서버에서 이를 계속 작동시키는 것은 메인 서버에 큰 부담이 되기 때문이다.

이러한 근거에 따라서, 스케줄러를 메인서버에서 별도의 ec2 Instance로 이관했다. 물론 aws lambda나 다른 방법들을 이용해보고 싶었지만, 일단은 문제를 빠르게 해결하기 위해 빠르게 도입할 수 있는 ec2 instance를 선택했고, 현재 해당 스케줄러는 메인 서버와 분리된 상태에서 우리가 의도한 대로 잘 작동한다.

2.문자로 전송된 url로 로그인이 필요한 페이지에 접속하게 하기

출석체크/크루장평가 같은 서비스의 컨텐츠는 유저들이 오프라인에서 직접 만나 그룹러닝을 하는 상황에서도 이용할 수 있어야 하기 때문에, 유저들이 모바일 환경에서도 우리 서비스의 컨텐츠를 이용하게 하는 것은 우리 서비스에서 무척 중요한 일이다.
그래서 우리 팀은 다른 팀들과 달리 모바일 UI와 SMS 알림 기능에 좀 더 신경을 썼다. 그 중, SMS 알림 기능을 사용하는 이유는 우리 서비스는 현실적인 여건 상의 이슈로 일단은 웹 서비스이기 때문이었다.

나는 그 중 SMS 알림 기능을 담당했다. 이 기능 자체는 MVP 구현 기간 내에 개발을 완료했다. 그런데, MVP 테스트 과정에서 이 기능이 내 예상과는 다르게 작동되지 않는 지점을 발견했다. 바로 sms로 전송된 url로 사이트의 특정 페이지에 진입하는 지점이었다.
나는 유저에게 sms로 출석체크 url만 발송시키면, 알아서 다음과 같이 유저가 행동할 수 있을 것이라 생각했다.

1. 출석체크 페이지로 진입한다.
2. 로그인이 되어 있지 않으면, 로그인 페이지로 보낸다.(FE, BE에서 사용자 인증 예외처리를 구현했으므로)
3. 로그인을 하면 다시 출석체크 페이지로 진입한다.

그런데 생각과는 다르게, 2와 3이 제대로 되지 않았다. 2의 원인은 FE에서 예외처리가 되지 않았던 것이 원인이라 쉽게 해결했는데, 3은 좀처럼 쉽게 해결되지 않았다. 유저의 페이지를 이동시키는 것은 FE에서 처리하는 것이 적합하기 때문에, 나는 위 기능에 대해서 함께 협업하는 팀원과 3을 구현하는 방법을 함께 구글링하며 찾아보았다.

결론적으로, 우리는 아래 방식으로 3을 구현했다.

1. 출석체크 페이지로 진입한다.
2. 로그인이 안된 유저라면 로그인 페이지로 redirect를 시키면서,
해당 브라우저의 localStorage에는 'from'이라는 key에 출석체크 페이지의 url을 value로 저장시킨다.
3. 유저가 로긍니을 하면, localstorage의 from 값을 이용해서 원래 페이지(출석체크 페이지)로 다시 이동한다.

그런데 local 환경에서는 이것이 잘 구현되는데, 최종 서비스 환경에서는 계속 로그인 후에 원래 페이지로 이동하지 않고, 메인 페이지로 이동하는 오류가 발생했다. 분명히 코드는 문제가 없었다.

원인을 찾아본 결과, 원인은 sms로 전송한 url에 있었다.

localStorage는 originURL에 기반한 저장소라고 할 수 있는데, sms로 전송한 url은 abc.com 이었고, 소스코드에 작성된 url은 www.abc.com이어서, 비유하자면 from 값이 다른 originURL에 저장되어 있어, 소스코드에서 사용하지 못하는 일이 벌어진 것이다.

구글링을 통해, www.abc.com과 abc.com은 originURL이 다르다는 것을 파악하고, SMS에서 전송하는 URL에 www를 추가해서 문제는 잘 해결할 수 있었다.