와 드디어 끝났다~! 소리질러~!

5월 31일부터 5주간 이어졌던 엘리스 마지막 프로젝트

어제 (적는데 3일 걸렸네...) 막 발표가 끝난 약간 식은 후기
드는 생각을 모두 메모하고 정리하면서 회고합니다!
방식은 가장 익숙한 KPT 방식으로.
KPT 회고 방식이란?

프로젝트

AI트랙의 꽃인 마지막 인공지능 프로젝트!
인공지능을 가진 웹 서비스를 만드는 것이 목표였다.

그리고 난 프론트를 1지망으로 지원했는데 2지망인 인공지능으로 배정이 돼서
갑자기 분위기 인공지능...

사실 인공지능도 배울 때 재밌긴 했는데, 프로젝트로는 아직 준비가 되지 않았다.
더군다나 이력서에 이제는 프론트 프로젝트를 채워야 하는데 그렇지 못한 게 가장 아쉬웠다.
(그래서 엘리스에서 프론트, 백, 인공지능 각각 하나씩 해봄)

아무튼 배정받은 포지션으로 해야지 뭘 어떡해!
하고 싶은 것만 하면서 살 순 없다.
한다면 한다.

우리팀의 주제는 다음과 같다.

다시금 기획을 보니 발표 이후 총평에서 받았던 피드백이 생각나는데,
기획 의도 및 예상 사용자에 맞게 UI, UX를 잘 구성했다는 의견을 받았다.
아 우리 팀 최고~!

---

혹시나 웹사이트가 궁금한 사람들은 아래로!👇
영어 수화 학습 사이트, 손생님

---

KEEP

• 현재 만족하고 있는 부분
• 계속 이어갔으면 하는 부분

<서비스 개발>

1. 사용자에 대한 고민

첫 프로젝트 때는 단순한 포트폴리오 웹사이트를 제작하는 것이었다.
그때는 단지 엘리스에서 제공한 템플릿을 가지고 디자인만 더하면 되겠지라는 생각이었다.
그런데 발표 때 다른 팀들이 여러 컨셉을 가지고 기능을 추가한 것을 보니 웹 서비스 사용자가 어떤 것을 바라는지 생각하는 게 중요하단 것을 깨달았다.

두번째 프로젝트 때는 그 생각을 미처 하지 못하고, '데이터 분석'에 너무 치중한 나머지 사용자에 맞는 기능을 깊게 생각하지 못했던 것 같다.

그래서 이전 두 프로젝트 때 아쉬웠던 점을 마지막 프로젝트 때에는 적용해보기로 했던 것 같다.

일주일동안 기획을 하면서 그리고 기능을 구현하면서 필요한 부분들을 그때그때 제안하고 팀원들과 조율했다.
전반적인 디자인은 초반에 강조를 했던 것이었지만,
이후 국립국어원의 수어사전 사이트를 보면서 버튼 hover 시 tooltip으로 수화영상이 나오는 것을 보고 우리 서비스에도 추가하기로 추후 정하게 되었다.

(그리고 이 부분은 내가 구현함! 아싸!)

2. 저작권이 없으면 몸으로 때워야지

학습 사이트, 특히나 수화 학습 사이트다 보니깐 소스가 정말 많이 필요헀다.
영어 알파벳을 발음하는 입모양 영상, 영어 수화 손모양 영상 그리고 단어 수화 손모양 영상 등...
그리고 이걸 다 다른 곳에서 각각 갖다 쓰는 것보다 통일성을 가지고 구성하는 게 서비스의 완성도를 높일 수 있음과 동시에 저작권 이슈를 피할 수 있다고 판단하여

직접 다 찍었다!

그리고 직접 다 그렸다!

(물론 비영리적인 목적으로 써도 되는 소스들은 갖다쓴 건 안 비밀)

사실 여기저기 찾으면 다 가져다 올 수 있었겠지만,
시간 쪼개가며 찍고, 그린 게 헛되지 않을만큼 디자인 및 구성 칭찬을 참 많이 받았다.

<협업>

1. 성실한 스크럼, 자발적 참여, 적극적 태도

우리 팀... 진짜 멋있는 사람들밖에 없다...

사실 처음에는 팀장을 하기가 정말 싫었지만,
(왜 싫었는지는 저번 프로젝트 회고 때랑 동일한 이유)
음... 내가 먼저 '언제 모일까요'라는 얘기를 꺼내서 팀장이 됐다!
그런데 또 마지막이다보니 괜히 또 욕심이 생겨서 내 의견을 많이 반영하고 싶었기에 굳이 하지 않겠다는 얘기는 안 한 것 같다.

그리고 항상 팀장이 되면 스트레스 받는 부분이,
왜 팀원들이 잘 따라와주지 않는 걸까, 무슨 문제가 있는 걸까, 내가 잘해주지 못해서 일까하는 생각을 하는 지점이었다.

그런데 이번 팀은 그런 생각을 한 번도 하지 않았다.
팀원 전부 스크럼에 늦은 적이 거의 없었고,
다른 포지션 오피스아워도 자주 와줬고,
소통도 부담가지지 않은 채 자주 하고,
자기가 맡은 바 열심히 임해줬으며,
...
전부 칭찬하려면 입이 열 개라도 모자라다.

아무튼 팀장이 이렇게 재밌는 위치인지 느낄 수 있었던 좋은 프로젝트였다.

2. 성향 밸런스

위의 포인트와 이어지는 이야기인데, 왜 협업이 수월하게 잘 되었는고 하니...
사람들 간의 밸런스가 잘 맞았던 것 같다.

게임을 할 때도 딜러, 탱커, 힐러 별 각 포지션이 골고루 있어야 정상적으로 팀이 굴러가듯이,
프로젝트 협업도 마찬가지인 것 같다.

무조건 파이팅 넘치는 사람 6명이 모였다고 해서 열정적인 팀이 되는 게 아니다.
불 그 자체인 사람도 있고, 불을 더 크게 피우기 위해 하는 부채질과 같은 사람도 있고, 불에 들어가는 장작과 같은 사람도 있어야 제대로 탄다.

그런 지점에서 우리 팀은 여러 성향인 사람들이 골고루 있어서 잘 굴러갔던 것 같다.

각자 성향대로 각자 위치에서 티키타카가 아주 잘됐다.

예를 하나 들자면,
나는 비록 팀장이 됐지만 다른 사람에게 일을 시키는 걸 정말 못한다.
내가 직접 하는 게 편하고 무엇보다 시키는 게 참 미안하다.
괜히 내 욕심뿐이고 팀에는 도움이 되지 않는 요청 사항일까봐...

그런데 어떤 팀원분께서 내가 뭔가 요청하고 싶어하는 것을 감지하고,
어떤 부분을 수정할지, 먼저 물어봐줬다.

어떤 팀원분은 말하지 않아도 팀에 필요한 것들을 찾아오고, 만들어오고
기능과 기술문서를 다채롭게 만들어줬다.

어떤 팀원분은 미처 부탁하지 못했지만 우리 팀이 해야할 것을 포착하고
본인이 하겠다고 자발적으로 나서줬다.

(이렇게 보니 팀장인 나 뭐했니...)

이건 누구 하나만이 잘했다라고 말하기보다는
전부가 잘 어우러져서 합이 맞았던 것 같다.

<개인>

1. 포기할 것을 구분

어떤 방식을 선택할 것인가를 "자주" 고민했던 것 같다.
특히나 웹캠에서 받은 관절 인덱스 데이터를 가지고 프론트와 트레이드오프 지점을 로드밸런싱하는 데에 있어서

트레이드오프(trade-off, tradeoff) 또는 상충 관계는 다른 측면에서 이득을 얻으면서 집합 또는 디자인의 품질, 양, 속성을 없애거나 잃어버리는 일이 수반되는 상황적 결정 (출처: 위키 백과)

로드밸런싱 부하분산 또는 로드 밸런싱(load balancing) 은 컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미한다. 이로써 가용성 및 응답시간을 최적화 시킬 수 있다. (출처: 위키 백과)

어느 한 기준을 가지고 선택을 하고 데이터를 조정한 것 같다.
최대한 사용자에게 딜레이가 적으면서, 예측값의 정확도를 높일 수 있는 방식을 찾기 위해 테스트를 진행했다.

그래서 결국에는 기준에 따라서 포기할 것을 찾는 것을 최대한 빨리 하기 위해 노력했다. 선택의 시점에서 고민할 때 오래 하지 않고, 즉시 선택하고 넘어가는 것을 반복했다. 오래 고민해봤자 결국 우리가 판단하는 것보다 직접 해보고 검증하는 것이 더 빠르기 때문이다.

그리고 무엇보다 고민이 길어질수록 미궁에 빠지기 마련.

이의 장점은 여러 시도를 해보고 경험적으로 어떤 것이 최선인지 알 수 있다는 것이고,
단점은 자칫하면 돌고 돌아서 헛수고를 할 수도 있다는 점이다.
그런데 주니어 개발자에게 이 단점은 오히려 좋아.
다양한 경험을 하면서 가보지 못한 지점을 활성화시키는 것이기 때문이다.

2. 문서화

이건 팀원과 인공지능 코치님께서 알려줘서 새삼 깨달은 부분이다.
그냥 좋아서 정리한 건데 이게 잘 정리하는 건 줄은 몰랐다.

정리광으로서 문서화에 힘을 준 것도 맞지만,
프로젝트에 있어서 문서화가 중요한 이유는 두 가지가 있다.

1. 스스로가 잘 이해했는지 파악, 그리고 공부
   어떤 문제를 맞닥뜨렸을 때, 또는 현재 적용하려는 라이브러리를 다룰 때 당장 해결했다고 해서, 당장 적용이 완료됐다고 해서 본인 것이 된 게 아니다.
   즉 남에게 설명할 수 있고, 한 달 뒤 내가 잊어먹지 않아야지 비로소 내 것이 된다.
   이럴 때 문서화는 자신이 얼마만큼 이해하고 있는지, 정말 이해하고 있는 것이 맞는지 확인할 수 있는 수단이 된다.
   형식에 맞게 정리하면서 어느 부분이 부족한지, 얼렁뚱땅 넘어간 부분은 없는지 확인할 수 있다.

2. 팀원들간의 상황 공유
   스크럼 때 물론 자신이 했던 것들을 공유하긴 하지만 효율을 위해 짧게 브리핑만 하고 넘어가기 마련이다.
   이때 이슈나 wiki로 정리한 것이 남아있다면, 각자 원하는 시간에 타 포지션 및 팀원의 상황을 알 수 있어 시간을 효율적으로 쓸 수 있다.
   이 방식은 짧은 스크럼 시간이라는 장점을 갖고 있지만, 다른 팀원이 무슨 일을 하는지 노력하지 않으면 소홀히 할 수 있다는 단점이 있긴 하다.
   그래도 한 가지 더 장점이 있다. 만약 어느 팀원이 N에 대해 궁금한 점(어떤 것으로 정해지고, 어떻게 할 것인지)이 생겨 그것을 담당하는 팀원인 'A'에게 물어보려는 상황일 때, 문서화를 해놓지 않았으면 각자 하는 일을 하던 와중 직접 물어보고 두 명의 시간을 뻇게 된다.
   
   만약 문서화를 해놓았다면, 각자 필요한 부분을 문서를 보고 확인하면 되니, 불필요한 시간 낭비를 피할 수 있다!

PROBLEM

• 불편하게 느끼는 부분
• 개선이 필요하다고 생각되는 부분

<서비스 개발>

1. 부족한 서브 기능

비록 인공지능 그 자체만으로도 프로젝트는 충분한 무게를 가지지만, 웹 서비스만 따로 보면 기능은 많다고 볼 수 없다.

현재는 학습, 퀴즈, 검색 뿐이기에 사용자 입장에서 학습을 더 하고 싶게 만드는 그런 장치는 아직 부족한 것 같다.

특히나 4주차 막바지에 우려했던 부분이기도 하면서, 실제 코치님들의 피드백도 받았던 부분인, '로그인 사용자 차별화'.
회원가입 및 로그인 기능은 있으나 지금은 없는 기능이나 마찬가지이다. 로그인을 해봤자 달라지는 것은, 정답 화면이 다른 것 뿐이기 때문이다.

그래서 이후 팀 회고에서 나온 방향은, 로그인 후 학습 및 퀴즈 이후 포인트를 획득하여 해당 포인트로 기부를 할 수 있는 방향으로 정하게 되었다.

(출처: 네이버 해피빈)

2. 학습 내용 증가 시 모델 학습

지금은 26개의 알파벳, 21개의 영어 단어로 이루어져 있는데, 확장성을 놓고 보자면, 이후 학습 내용을 늘리려면 인공지능 모델을 다시 학습시켜야 한다.

물론 단어 하나당 200개의 데이터셋을 손수 추가해야하는 것도 한 가지 단점.

3. 사용자 PC 스펙에 따른 이용 차이

프론트단에 mediapipe라는 오픈소스 프레임워크를 담았기에, 컴퓨터 웹캠의 프레임수가 낮거나, 처리하는 CPU 성능이 좋지 않다면,

학습 페이지에서 학습 시 웹캠을 켜는데부터 로딩이 길어길 것이고, 웹캠에서 영상을 받고 예측값을 받기까지 최대 5초~7초 정도 시간이 늘어날 것이다.

그런데 사실 이 부분은 mediapipe가 무거워서 발생한 문제가 우리 문제 아니기에 바로 개선하기 어렵다.

중요한 것은 추후 발표 때 받은 피드백인데, 웹캠이 없는 사용자는 학습 페이지에 들어가면 무한 loading이 걸린다는 것이다. 이는 당연한 게, 웹캠 사용을 허용할 때 로딩창이 꺼지는 것으로 구현했기 때문이다.

기획 의도에 맞게 당연히 모든 사용자가 웹캠이 있을 것이라 생각하고 이렇게 구성한 것인데, 미처 파악하지 못한 부분을 알게 되어 허를 찔린 기분이 들었다.

<협업>

1. 포지션 간 정보 공유

인공지능을 담당하면서 업무가 꽤나 많았고, 문제 상황도 많았기에 다른 포지션들을 신경쓸 겨를이 없었던 것 같다.
사실 이건 정말 핑계이고, 어떤 상황에서도 다른 포지션이 어떻게 돌아가는지 파악하고 인지하고 있었어야 했다.
다들 문서화를 정말 잘했지만 좀 더 신경쓰고 확인했었어야 했는데 그러지 못했다.
그래도 프론트는 1지망이기도 했고, 이후에 같이 작업을 하게 되어 전반적인 흐름은 알았지만 백엔드는 전혀 몰랐던 것 같다.
코치님들과 만나는 오피스아워 때 자주 참여하긴 했지만 어느 순간부터 integration test, jest, mocha 등 생소한 용어들이 나오니 이것을 전부 따라잡기에 무리가 생겼던 것 같다.

<개인>

1. 컨디션 관리

3주차까지 잘 견디다가 4주차에 크게 몸살이 나고 말았다. 계속 새벽 4시에 자고, 10시에 스크럼하느라 제대로 자지 못하고, 운동도 못 한 게 화근이었지 않나 싶다.
5주차 때는 병원에서 신경 안정제를 받아서 그걸로 버틴 것 같다.

그래도 나는 다른 팀원에 비해 열심히 한 것 같다고 느끼지 않았는데 혼자 지쳐버리니 정말 미안했고, 막막했다.
고작 5주짜리 프로젝트인데, 이렇게 쉽게 지치고 무너지니 앞으로는 어떻게 살아나갈지 생각하니 답답했다.

2. 부분적인 이해

지금 이걸 쓰고 있는 와중에도 걱정인 것이 'm1에서 tensorflow 설치' 정리하기이다.
이 문제는 3주차 초에 나타난 문제인데, m1에서 tensorflow 설치가 안된다는 것이다, 그런데 jupyter notebook으로는 설치가 잘 되는데, 로컬 IDE에서 돌리려면 발생한 문제...

아무튼 문제가 참 많았던 이슈이고, 5주차 오피스아워 때 겨우내 해결했지만 우당탕탕 해결로 미쳐 정리하지 못했다.
대표적인 예시가 이 tensorflow install인데 이 이외에도 이곳저곳에서 발생한 문제들을 전부 이해한 다음 넘어간 것이 아닌 게 참 아쉽다.

프로젝트는 단기간에 결과물을 하나 낼 수 있다는 것이 가장 큰 장점이지만, 도중에 발생한 문제 또는 새롭게 배우게 된 것에 대한 정리, 이해를 할 시간이 부족한 게 가장 큰 단점인 것 같다.

TRY

• Problem에 대한 해결책
• 당장 실행 가능한 것

<서비스 개발>

1. 디자인 통일

마스코트와 일부 단어 카드 디자인을 직접 하게 됐는데, 다른 페이지도 통일성 있게 만들고 싶다! 이게 한 사이트라는 정체성을 가지게 만들고 싶다.
그래서 쉽진 않겠지만 freepik에서 따온 소스들을 하나씩 직접 디자인한 것으로 대체할 예정.

<협업>_팀 프로젝트 회고

이건 우리 팀 프로젝트 회고에서 나온 최종 TRY!

1. 포지션 간 진행 상황 공유를 위해 타 포지션, 팀원이 오류 및 진행상황에 대해서 꼼꼼히 작성을 했다면, 해당 이슈를 읽었는지 확인하는 반응/댓글을 남기자.

2. 1주일에 한 번은 코드를 정리하는 시간이 있으면 좋을 것 같습니다.

3. 컨디션이 안 좋다면 이모지 Ex) 😨를 활용하여 스크럼 docs에 남기고 다음날 컨디션 관리를 할 수 있게 하는 것은 어떨까

<개인>

1. 완벽하지 않지만 꾸준한 기록

WIL도 그렇고, 개발일지도 그렇고, 기록에 있어서 정리하려는 강박을 가져서 그런지, 형식이 다 갖춰지지 않으면 함부로 포스트 하지 않으려 했던 것 같다.
지금도 회고 형식 맞춰서 쓰느라 일요일에 써서 올려야 할 것을 목요일에 마무리하고 올리려하고 있다.
완벽하지 않으면 남에게 보여주기가 꺼려지는 것 같다. 그래도 완벽한 것보다 꾸준한 게 더 중요하니깐 앞으로는 짧게 나마 하루메 키워드를 가지고 5문장 정도로 기록하는 습관을 들여야겠다.
총 5주간의 프로젝트를 뒤돌아 보면서 생각보다 생각나는 게 별로 없으니...
다시금 기록의 중요성을 깨닫는다.

느낀 점

배운 게 참 많다고 느끼고 있다.
5주 전 새롭게 마주하는 것들, 용어들이 한참 낯설고, 무섭게만 느껴지는 것들이
이제는 그냥 친구 이름같고, 두려움이 생기지 않는다.
당연히 앞으로는 더욱 더 어렵고 큰 것들이 나에게 다가오겠지만,
그래도 이번 프로젝트에서는 두려움에 맞서는 법을 배웠기에
마냥 이유없이 두렵지만은 않을 것이다.

어려운 데에는 이유가 있고, 그것을 이해하면 식견이 넓어지는 것을 의미하니깐
앞으로는 자꾸만 시도하고, 질문하고, 이해하는 것을 서슴치 않을 것이다.

특히나 공교롭게도 첫 프로젝트 때 내가 범했던 master merge 실수를 다른 팀원이 한 적이 있는데,
이번에는 내가 local에서 git revert로 해결했다. 뿌듯한 경험이었다.
물론 실수할까봐 떨리긴 했지만 무사히 해결하니 내가 지난 6개월 가량 마냥 가만히 있었던 건 아니었구나라는 것을 생각하게 됐다.

마치며

앞으로의 여정도 쉽지만은 않을텐데, 어떤 것이 기다리고 있을지 기대가 된다.