끝을 보는 용기

Spring 본캠프 Day 032 - 미니 프로젝트 90%

writingforever162 2024. 11. 7. 23:35

"어?"

 

"이게 되네?"

 

오늘 술술 풀리려고 어제 그렇게 매듭처럼 꼬였나 보다. 팀에서 'GitHub.io로 팀 소개 웹 사이트를 배포해 보자!'는 얘기가 나왔을 때, 담당자가 나라서 또 한방에 안 되겠거니 싶었다. 완전히 마음을 비웠는데, 웬걸. 모르는 사이에 URL이 생성되어 배포하기에 성공했다. TIL을 쓰는 이 순간까지도 어떻게 단번에 해냈는지 모른다. 고생 끝에 낙이 온다더니, 팀원분 말대로 이 행복이 도파민과 같아서 '이 맛에 개발 공부를 하는구나!' 싶었다. 

 

'TIL 특강'에서 '문제 해결 과정을 담아보라'고 권장하기도 했거니와, 때마침 오늘 그 과정을 두 번이나 겪었다. 

 

첫째, 어제 접착제보다도 강력하게 달라붙은 무기력감을 어떻게 떼어낼까?

 

아무것도 모른다고 넋 놓고 구경하고 싶지 않았다. 힘들다는 푸념이 하루의 끝을 봉합하면 앞으로 남은 일정에 발전도, 성장도 없었다. 내일배움캠프에서 쓰는 메신저 슬랙(Slack)을 켠 찰나, 한 가지 방법이 뇌리를 스치듯 지나갔다. 

 

'월요일부터 수요일까지 사흘 치 팀 대화를 처음부터 끝까지 읽으며 모르는 용어 뜻을 찾자!'

 

월요일 하루만 해도 분량이 어마어마했으나, 결심이 선 순간 망설임 없이 쭉 읽었다. 어마어마한 메시지 수보다는 어제와 똑같은 무기력감이 찾아올지 모른다는 사실이 훨씬 무서웠다. 공유한 정보를 당장 체득할 여력이 안 될 때면 캡처해서 다른 데 저장해두었으나 창고에 쑤셔 박아놓고 잊는 모양새나 다름없었다. 더 이상 그 무엇도 미루기 싫었다.

 

놀랍게도, 모르는 용어는 예상보다 훨씬 적었다.

 

나는 아예 대화에 끼지 못할 만큼 기초 지식이 부족한 사람이 아니라, 생소한 용어 한두 개가 시야에 걸린 탓에 지레 겁먹었을 뿐이었다. 몇몇 단어를 검색해서 뜻을 읽고 나니, 허무함과 안도감이 동시에 밀려들었다. 이게 바로 홀로 걸어간 문제 해결 과정이었다.

 
둘째, 실시간으로 진행되는 팀 프로젝트 발표를 누가 맡아야 하나?

 

처음 팀에서 나온 발표 방식은 총 3가지였다.

 

1안, 녹화 영상 없이 실시간으로 시연 및 발표하기. 필요 인원 1명 


2안, 시연 영상만 녹화 후 당일에 실시간 발표하기. 필요 인원 2명


3안, 시연하는 부분까지 포함하여 발표를 녹화하기. 필요 인원 1명

팀에서는 나와 '노력파'가 아예 프로젝트 경험이 없었고, '니즈 파악 요정'과 '즐길 줄 아는 사람'은 경험과 경력 모두 풍부했다. 나와 '노력파'는 팀 구성원이 아닌 짐이 된 듯한 기분을 느낀 데다, 네 명 모두 참여하는 프로젝트인 만큼 두 사람의 참여도를 높이고 싶었다. 부담감을 조금이나마 줄이고자 3안을 고른 다음 노력파에게 발표를 부탁했는데…….

 

"팀 소개 웹 사이트를 보여주는 시연 영상만 녹화하고 나머지 부분은 발표해 주세요!"

 

매니저님의 설명을 듣기가 무섭게 공부마저 제쳐두고 전원 다 마이크와 웹캠을 켰다. 긴급회의를 잡았다.

1안과 2안 모두 '실시간 발표'를 포함한 탓에 팀에서는 부담감 어린 분위기가 흘렀다. 이 외에도 영상이 중간에 들어가면 발표 흐름이 끊길 수 있으며 필요 인원이 2명이라 1안보다 2안에 자원이 더 든다는 점 등등 논의할 사항이 많았다. 모두가 머리를 맞대고 의견을 주고받은 끝에, 우리는 둘 중 하나를 선택했다.

 

팀원 '노력파'가 시연 영상을 녹화하고 내가 발표하기로 했다.

 

이렇게 결정을 내린 데에는, 공교롭게도 '필요 인원이 2명이라는 점'이 영향을 크게 끼쳤다. 유경험자가 제작한 웹 사이트를 왕초보가 자기만의 언어로 설명한다면 발표 자체가 배우는 기회가 되지 않을까? 미니 프로젝트는 발표까지 해야 완성되니, 이제 막 배우는 사람이 참여해야 '진정 모두의 노력이 깃든 프로젝트'가 되지 않을까?

 

이러한 이유로 처음 프로젝트에 참여하는 팀원 '노력파'에게 녹화를 부탁했고, 발표자를 자처했다. 이렇게 해서라도 프로젝트의 한 축을 맡고 싶었다. 

 

2안을 고르기까지 논의하는 과정에서, 혹여 본인의 말투 때문에 상처받지 않으면 좋겠다는 메시지가 떴길래 읽은 즉시 답해주었다. 프로젝트를 진행하며 다른 의견은 당연히 나올 수 있고, 그래야 한다고. 설령 직설적이라 하더라도 저 사람이 '날 싫어해서' 또는 '나랑 싸울 생각으로' 저렇게 말한다고 느낄 일이 전혀 없다고. 

 

어제에 이어 오늘도 마찬가지로 어휘력을 키워야겠다고 느꼈다. 부디 정말 괜찮다는 나의 진심이 말 속에 가득히 담기기를. 하루 동안 참으로 많은 것을 배웠다. 

 

[습관 관련]

오늘은 아예 알람을 7시 30분 이후로 맞추었다. 이 와중에 지각할까 봐 겁이 나서 8시 전에 일어났다. 운동은 아침에 스트레칭 20분, 점심에 20분, 저녁에 10분씩 했다. 집에서 '분식 먹는 날'을 맞이해 저녁때는 짧고 굵게 운동했다. 자바(Java) 문제는 딱 한 개 풀었고, 쉬는 시간에 틈틈이 『생강빵과 진저브레드』 책을 읽었다. '빵과 수프'를 모두 맛본 뒤 '주요리'로 넘어가 소설 ≪바람과 함께 사라지다≫의 '햄과 그레이비'까지 음미했다. 

 

"나 역시 뭔가 아주 중요한 걸 잊어버린 게 아닐까 하는 조바심이 든다." 

 

"냉엄한 현실이다."

 

책을 읽으며 '조바심'이나 '냉엄하다'와 같은, 깜빡 잊었거나 낯선 단어를 만나면 머릿속에 곧장 담는다. 변수라는 바구니에 값을 집어넣듯이.

 

어쩌면 나는 뭐라도 하나 건져내야 직성이 풀리는 욕심쟁이인가 보다.

 

[인용 및 참고 출처]

1. 강의: 스파르타코딩클럽, "[왕초보] 웹개발 종합반", 강의 소개, (2024.11.07)

2. 단행본: "생강빵, ≪우산 타고 날아온 메리 포핀스≫", 김지현, 『생강빵과 진저브레드』, 김영사, 2020, 61쪽, (2024.11.07)

3. 단행본: "햄과 그레이비, ≪바람과 함께 사라지다≫ ", 김지현, 『생강빵과 진저브레드』, 김영사, 2020, 111쪽, (2024.11.07) 

 

[학습 관련]

1. 파이어베이스(Firebase) getDoc 사용

팀원 '즐길 줄 아는 사람'의 도움을 받아 드디어 댓글을 다는 데 성공했다! 처음에는 <ul>는 있는데 </ul>는 없어서 태그가 닫히지 않은 줄 알았는데, 진짜 원인은 따로 있었다.

첫 번째로, 빨간색 네모로 표시한 <li>~</li> 부분을 지우지 않아 값이 충돌했다. 하필 이름도 'li'라서 원인을 찾은 순간 입에서 '에라이'가 튀어나왔다. 진짜로.

원인도 알았겠다, 모든 감자박스만 지우면 좋았으련만. #을 빠뜨렸다. '#comment_wr01'이라고 적지 않아서 웹 사이트가 요지부동이었다. 꼭 자바(Java) 공부 중 세미콜론(;)이 없단 사실을 뒤늦게 발견했을 때 심정처럼, '어떻게 저런 실수를 하냐!' 속으로 탄식하며 눈을 질끈 감았더랬다. 어쨌거나 해냈다. 산 넘어 산이었으나 끝이라는 꼭대기에 도달했다.

 

2. 변수 이름을 지을 때 유의 사항 

① 이름에 숫자를 넣어 구분하지 않는다. 숫자 대신 의미가 담기도록 명명한다.

▶ audio1, audio2 (X)

▶ audioWind, audioBackground (O

② 이름에 new 또는 old를 넣지 않는다. 마치 문서를 저장할 때 '최, 최, 최, 최종', '진짜 진짜 마지막 수정'과 같은 느낌과 동일하므로 두 단어를 쓰지 않는다.

 

3. API가 그래서 몇 개인가요?API를 은행 창구로만 본다면 1개였으나, 이는 틀린 계산법이었다. 예를 들어 고객이 은행 창구로 가서 예금한 다음에 통장 잔액을 확인한다면, 예금한 행위가 이루어진 다음에 확인 작업이 이루어졌기 때문에 2개로 계산해야 옳았다. 튜터님의 보충 설명에 따르면, 아마 댓글을 적고 댓글 등록 버튼을 누르면 바로 댓글이 달리니까 '두 행위가 동시에 이루어지는 모양'으로 보였을 거라고. 

튜터님의 설명을 듣고 나니 왜 우리 팀 API가 2개인지 이해가 갔다. 만약 팀 구성원마다 API가 있다면, 4X2로 8개 된다는 사실까지도.

 

[기타 사항]

12시간이 얼핏 길어 보여도 막상 공부하고 나면 늘 부족하게 느껴진다. 내일 팀원들의 노력이 헛되지 않도록 최선을 다해 발표해야겠다.