[알림 기능 찾아 삼만리 링크 1주 차: (1) (2)]
[알림 기능 찾아 삼만리 링크 2주 차: (3) (4) (5) (6) (7) (8) (9) (10)]
[알림 기능 찾아 삼만리 링크 3주 차: (11) (12) (13) (14) (15) (16)]
개발 공부를 하면서 늘 발표하진 않았어도 항상 발표 자료를 제작하고 검토하고 수정했다. 이번 발표 순서는 특히나 맨 끝이라, 최대한 모두의 집중력을 끌어올릴 수 있는 방향으로 PPT를 제작했다. '인상 깊은 발표' 또한 개발에서 중요한 부분이라고 생각하는 만큼, 이번에 공들인 PPT를 정리했다.
▶ 유리잔은 Canva의 왼쪽에 있는 'Elements'에 'celebration'을 검색하여 사용했다. 사진처럼 보이지만 사실 움직인다. 목차는 마찬가지로 왼쪽에 있는 'Design'에 'flow process'를 검색하여 마음에 드는 서식을 골라 사용했다. 목차는 듣는 사람에게 안내 표지판 같은 존재라고 생각하기 때문에 PPT를 만들 때 꼭 추가했다.
▶ Cloud Architecture와 CI/CD Pipeline은 모두 팀장님 작품이다. 기술적 의사결정이든 트러블슈팅(troubleshooting)이든 '취하여'가 무슨 프로젝트인지 배경지식이 없다면 듣는 사람 귀에 나머지 내용이 들어오지 않을 듯했다. 이런 이유로 맨 처음에 프로젝트 기획 배경과, 발표에서 자주 언급할 용어를 프로젝트 핵심 요소로 소개했다. 그다음에는 사용자가 이 서비스에서 무엇을 할 수 있고, 이 서비스는 어떤 흐름으로 이메일 알림을 전송해 주는지 최대한 한눈에 보이도록 신경 썼다. API 명세서나 와이어프레임(Wireframe)처럼 한눈에 잘 들어오지 않는 자료는 전부 리드미(README)로 대체했다.
▶ [시연 영상 링크] 시연 영상에는 팀장님이 자막을 추가했고, 조회와 이메일 알림이라는 두 가지 큰 틀만 핵심으로 소개했다. 시연 영상은 2분 5초 분량이라서 발표할 시간을 보장하면서도 발표자가 직접 설명할 부담을 줄여주었다. 발표 시간이 10분으로 제한되었기 때문에 팀에서도 영상 길이가 3분을 넘지 않도록 했다.
▶ 팀 전체가 항상 기술적 의사결정을 할 때마다 잘 기록해 두어 금방 표로 시각화할 수 있었다. 테스트한 결과를 보여줄 뿐만 아니라 배율로 얼마나 기능이 좋아졌는지 보여주려고 했다.
▶ 이메일 알림 전송 속도를 개선할 때, 왜 발송 전 작업 속도를 높이고 비동기로 처리했는지 꼭 언급하기로 했다. 구글의 SMTP 서버를 직접 해결할 수 없었기에 서버 앞뒤로 개선하려고 했다는 점을 강조하고 싶었다. Elasticsearch를 적용했을 때도 '속도가 늘었다고 무조건 좋아하지 말자'라는 교훈을 얻은 만큼, 이 부분을 발표 자료에 녹여냈다.
▶ 마지막 슬라이드를 고치면서 앞으로 남은 팀 일정이 괜찮은지 함께 점검할 수 있어서 좋았다. 시연 영상을 포함해서 분량이 아무리 길어도 15분을 넘기지 않을 듯했다.
과연 중간 발표회 결과는?
Day 18에서 계속…….