"가장 백엔드다운 프로젝트 아니었나."
"최종 프로젝트의 요약본과도 같았다."
"근거, 앞으로 무엇을 개선할 예정인지, 정량화된 수치, 트러블슈팅(Troubleshooting)까지 그동안 강조해 온 사항이 모두 담겼다."
기진맥진했다.
머리가 지끈거리고 허리는 욱신대고 눈꺼풀은 무거운 데다 목은 따끔거린다. 발표 때 모든 기운을 남김없이 쏟아부은 까닭이리라. 발표회에서 화면에 띄울 PPT 디자인을 수정하고, 팀원과 함께 한 고민과 노력이 모두 전달되도록 대본을 고친 다음, 오후 2시가 되기 직전까지도 마이크를 무음 상태로 해둔 뒤에 몇 번이나 읽었는지 모른다. 대본을 외우려다가 너무 떨린 나머지 '입이랑 혀가 뇌와 알아서 박자 잘 맞추겠지'란 심보로 암기는 깔끔하게 포기했다. 정말 놓쳐서는 안 되는 부분만 머릿속에 집어넣는 데도 시간은 쏜살같이 흘렀다.
누구나 '처음'에는 심장이 떨리기 마련이다. 미니 프로젝트이지만 내게는 더없이 소중하고 뜻깊은 '첫 팀 프로젝트'였다. 보통 무언가가 끝나면 후련하기 마련인데, 막상 끝나니 정말 아쉬웠다. 아무래도 열정으로 똘똘 뭉친 네 사람이 단 5일 만에 헤어져야 해서 그런가 보다. 그렇다고 슬퍼할 시간은 없다.
소리 내어 뱉은 말엔 늘 책임이 뒤따르니까.
잘해줘서 고맙고 정말 고생했다, 우리 11조!
[습관 관련]
긴장한 탓인지 7시부터 10분꼴로 뒤척이다가 일어났다. 운동은 아침에 거북목 스트레칭과 허리 근력 강화 운동만 10분씩 했다. 책 읽기 또한 주말로 넘겼다. 발표나 시험을 앞에 두면 늘 아무것도 눈에 들어오지 않고 손에 잡히지 않는다. Chapter 1 미니 프로젝트 발표회를 마치며 한 가지 깨달은 사실은, 긴장감은 온라인 공간으로도 잘만 찾아왔다.
그런 상황 속에서도 문제 하나는 어떻게든 풀었으니, 대단하다고 스스로에게 말해줘도 과장은 아니려나. 남은 10.0%가 아쉽긴 하지만, 개인 공부 때문에 팀원들의 노력을 100% 온전히 보여주지 못할까 봐 한 문제만 풀고 멈추었다. 옳은 선택이었다.
[학습 관련]
미니 프로젝트를 어떻게 진행했는지 궁금할 때마다 참고할 겸, 정리 차원에서 학습 관련 부분에 발표 내용을 적었다.
[첫 번째 슬라이드]
▶ "안녕하세요. '아, 저장안했다' 팀입니다. 드디어 마지막 발표인데요. 발표하기에 앞서 우리가 저장해야 하는 가장 중요한 사항이 한 가지 있죠? 네, 바로 시간입니다. 출결 관리에 들어가셔서 중간 인증 버튼 누른 다음 발표 들어주시면 감사하겠습니다."
▶ 이 말은 의도하고 준비했다. 11개 팀 중 순서가 마지막이라서 흐트러진 집중력을 다시 환기하는 동시에 우리 팀을 재치 있게 소개할 수 있겠다 싶었다. 효과는 꽤 컸다. '제2의 매니저'나 '출결 요정'이란 별명을 의도치 않게 얻었지만.
[두 번째 슬라이드]
▶ 목차는 원래 제작된 PPT에 직접 추가했다. 애초에 모든 팀에서 진행한 프로젝트의 주제가 '팀 소개 웹 사이트 제작하기'였기 때문에 겹치는 부분은 생략하고 싶었다. 그 대신, 목차를 보여주어 앞으로 어떤 순서로 무엇을 말할지 간단하게나마 알려주고 싶었다. 발표회 후 튜터님이 이 부분을 언급하며 칭찬해 주셨기 때문에, 다음 프로젝트 때도 잊지 않고 목차를 써야겠다는 다짐 차원에서 적어본다.
[시연]
▶ 웹 사이트에 어떤 기능이 있는지 발표회 당일 보여주거나 전날 녹화한 영상을 보여주는 방법이 있었는데, 팀에서는 두 번째 방법을 택했다. 이유는 뚜렷했다. 발표회 전 1시 30분에 미리 줌(Zoom)을 켜고 오디오와 비디오를 점검했는데도, 몇몇 팀에서 화면을 공유하니 마이크가 작동하지 않는 돌발 상황이 발생했다. 가뜩이나 첫 프로젝트에 첫 발표라 심장이 콩닥콩닥 뛰는데 예상 밖 문제까지 터지면 머릿속에 백지장보다 하얗게 변하기에 딱 좋았다. 예상 가능한 문제는 미리 막아야 옳다고 생각하는 만큼, 팀에서는 영상을 틀었다.
▶ 이때 화질 문제를 해결하지 못한 점이 내심 아쉽다. 화면을 공유할 때 '소리 공유'는 나름 바로 눌렀는데, 화질을 올리려고 톱니바퀴 버튼을 눌렀는데 이미 화면 공유 중인 영상과 줌에 가려져 화질을 높이지 못했다. 다음 프로젝트 때 발표자가 된다면, 그때는 '화질'까지 꼭 점검해야겠다고 다짐했다.
▶ 한 가지 더. 긴장한 나머지 '팀원'이라고 말해야 하는데 '팀장'이라고 얘기했다. 곧바로 정정하긴 했으나, 앞으로는 이런 실수하지 말자고 속으로 몇 번이나 곱씹었다.
[세 번째 슬라이드]
▶ 팀에서 가장 얘기하고 싶은 부분이자, 대본을 숙지할 때 최우선으로 챙긴 내용이었다. 변수를 사용하지 않고 각각의 방명록에 비슷한 API를 복제한다면 구현은 금방 끝날 수 있었으나, 유지 보수가 어려웠다. 사용자가 늘어나면, 그만큼 코드 또한 추가해야 한다는 부담감이 컸다.
▶ 반대로 변수를 사용한다면 구현하는 데에는 시간과 노력이 더 들겠지만, 팀에서 추구하는 '확장성'에 부합하는, 유지 보수가 쉬운 웹 사이트를 제작할 수 있었다.
▶ 발표회에서 바로 이 부분, 각 방안의 장단점을 두고 고민했다는 점을 꼭 얘기하고 싶어서 슬라이드 디자인을 바꾸는 내내 읊조렸다.
[네 번째 슬라이드]
▶ 팀에서 어떤 방안을 골랐는지 말할 때 '왜 쉬운 유지 보수를 택했는지' 근거를 덧붙였다. 처음부터 팀에서는 웹 사이트를 일회성으로 둘 생각이 없었고, 앞으로 꾸준히 성능을 개선해 보기로 약속했다. 즉, '당장의 마감'만 생각해 빠른 구현을 택했다가는 장기 계획이 완전히 어그러질 수 있었기에 후자를 골랐다고 발표했다.
▶ 여담으로 변수를 사용하여 댓글 기능을 구현하는 내내 팀에서는 프레임워크(Framework)의 소중함을 절실히 깨달았더랬다.
[다섯 번째 슬라이드]
▶팀에서 어떻게 변수를 사용했는지 설명할 때 팀원들의 도움을 크게 받았는데, 하마터면 id 값이 02가 아니라 comment02와 nickname02라고 얘기할 뻔했다. 앞에 있는 comment와 nickname을 자르고 02만 id 값으로 쓰는 게 맞았다.
▶ 이런 식으로 변수를 사용하면 API는 딱 2개였기 때문에, 회원가입 같은 기능을 새로 추가하거나 사용자가 늘어나도 코드를 늘려야 하는 부담이 줄었다.
[여섯 번째 슬라이드]
▶ API뿐만 아니라 팀에서는 여러 문제를 겪었는데, 이 부분은 나중에 급하게 추가되었다. 당시 이러한 삐그덕거림을 '문제'라고 인식하지 않은 탓이었다 '어려운가, 쉬운가?'로 문제인지 아닌지 판단했기 때문에 언급할 생각을 못 했는데, 다른 팀들이 적은 회고와 트러블슈팅을 보며 '아차!' 속으로 외쳤다.
▶ 여기서 스스로 잘했다고 느낀 점이 하나 있다면, 순서를 기다리는 사이 '슬라이드를 추가하고 그 내용을 숙지해서 말할 수 있어?'라는 마음속 질문에 바로 '그렇다'고 빠른 판단을 내렸다는 점이다. 물론 더듬거리기 싫어서 짧게나마 줄글도 적어뒀지만, 부담감보다 팀원들의 노력을 전부 뽐내고 싶은 마음이 컸다. 말 그대로 마음 가는 대로 행동했고, 칭찬을 받았으니 올바른 결정이었다.
[일곱 번째 슬라이드]
▶ wehp 같은 확장자 발음은 미리 익혀두자고 반성했다. 웹이라고 읽었는데 '웨피'란다. 순간 당황한 나머지 '더블유, 이, 비, 피, 일명 웹'이라고 말해버렸다. 생각할 때마다 부끄럽다.
[여덟 번째 슬라이드]
▶ 문제 & 해결 과정을 발표하며 팀원들의 도움을 크게 받았다. 혹 설명을 빠뜨리면 줌(Zoom) 채팅창에 추가로 설명해달라고 부탁했고, 팀원들은 제2의 발표자 못지않게 열심히 댓글로 보충 설명을 달아주었다.
▶ 나름 프로젝트의 전체 흐름을 안다고 생각했는데 섣부른 판단이었다. 이렇게 사소한 부분까지 팀장이라면 무조건 알아야 했다.
▶ [24.11.10 추가] CSS는 보통 대문자로 쓰는데, 발표가 끝나고 보니 소문자로 적혔다. 내용을 급히 넣느라 제대로 검토를 못 했다. 다음에는 이런 일이 없도록 더욱 신경 써야겠다.
[아홉 번째 슬라이드]
▶ 웹 퍼블리싱을 담당한 팀원이 구글의 PageSpeed Insights 사이트로 수치를 확인하여 내용을 추가해 주었다.
▶ 속도가 빨라졌다는 주장을 '정량화된 수치'로 객관화하여 보여주었다는 점에서 좋은 평가를 받았다. 이 웹 사이트는 반응형 웹이기 때문에 추후 모바일의 성능도 개선할 예정이다.
▶ [24.11.10 추가] 궁금해서 PageSpeed Insights에 들어가 직접 속도를 확인했다. 모바일까지 90% 이상이 되면, 웹 사이트뿐만 아니라 각 팀원이 얼마나 발전했는지 보여줄 수 있을 거다.
[열 번째 슬라이드]
▶ 팀에서 겪은 트러블슈팅만큼이나 모두가 참여했다는 점을 꼭 발표하고 싶은 부분이라 추가했다. 오전에 슬라이드를 쭉 읽으며 '4명 모두가 프로젝트의 일부라는 말을 어떻게 시각화하면 좋을까?' 고민하는 와중에 문득, 막대그래프가 번개처럼 번쩍했다. 특히나 모두 경험하고 학습하자는 취지대로 프로젝트를 진행했다고 얘기해 대미까지 완벽하게 장식할 수 있다고 생각했다.
▶ 슬라이드 한 장에 그동안 힘겹게 싸워온 자괴감과 무기력감을 모두 담아낼 순 없었지만, 결국 이겨냈다는 결론을 말할 수 있어 좋았다.
[열한 번째 슬라이드]
▶ TIL을 작성하는 이 순간에도 몽고DB(mongoDB)와 로컬호스트(localhost)가 뭔지 설명하지 못한다. 스프링(Spring)과 스프링 부트(Spring boot)가 다르다는 사실만 알 뿐, 둘의 차이점을 말하라고 하면 못한다. 그런 이유로, 주말에 자바(Java) 강의를 들으며 계속 앞으로만 나아가지 말고, 꼭 놓친 부분을 짚고 넘어가지고 발표 후 다짐했다.
▶ 발표회 자체가 애초에 기술보다는 팀 프로젝트를 처음 진행하면서 겪은 시행착오를 발표하는 자리였기에 '훗날 도메인을 직접 구매해서 웹 사이트를 제작하고 싶다'라는 각오로 발표를, 우리 팀 자랑을 갈무리했다.
[열두 번째, 마지막 슬라이드]
▶ 마지막까지 재치를 곁들이고 싶어서 위와 같이 적었다. 발표가 끝난 뒤 '아, 저장안했다' 팀의 마지막 퇴실 때도 나는 '12시간 확인 후 퇴실 버튼 꼭 누르세요'라고 그렇게 잔소리했다.
[기타 사항]
자바(Java) 문제보다 다면평가가 두 배 더 어려웠다. 9시 이전에 팀 KPT와 다면평가 작성 및 제출, 자정 전에 TIL 작성 및 제출. 오늘은 글쓰기 풍년이었다. 어느 때보 달콤한 꿀잠에 들겠다.
'끝을 보는 용기' 카테고리의 다른 글
Spring 본캠프 Day 035 - 정리 끝! (0) | 2024.11.10 |
---|---|
Spring 본캠프 Day 034 - 머릿속 기억 장치 최적화 (0) | 2024.11.09 |
Spring 본캠프 Day 032 - 미니 프로젝트 90% (0) | 2024.11.07 |
Spring 본캠프 Day 031 - 미니 프로젝트 70%, 첫 코드 리뷰 (0) | 2024.11.06 |
Spring 본캠프 Day 030 - 미니 프로젝트 40%, 책 『비전공자를 위한 이해할 수 있는 IT 지식』 읽기 20% (0) | 2024.11.05 |