활동

2학년 2학기가 끝나고 6주간 학교에서 지원해주는 실리콘벨리 부트캠프에 참여하게 되었다. 우리 팀 프로젝트 주제는 무인 상품계산대이다. 대형마트에 셀프 계산대가 많이 증가 하였는데 , 평소 무인 상품계산대를 사용하면 사용자들은 상품들을 계산대에 올려놓아 바코드를 하나하나 찍고 결제를 하는 방식이었다. 우리는 이 방식으로 인한 시간지연과 미숙한 바코드 인식으로 인한 지연을 개선하고자 했다. 해결방안으로 상품 사진 인식을 통한 시간단축이었다. 사용자들은 상품을 계산대에 올려놓고 단 한번의 사진 한 장으로 결제를 할 수 있는 것이다. 아마존에서는 바코드가 가진 문제점을 개선하기 위해 사진으로 구분하는 MMID 개발 중에 있다. 더 나아가 아마존 고에서는 진열대에 수많은 카메라를 설치해 단지 물건을 집어 넣은것 만으로도 매장에서 나가실 자동으로 계산이 된다.(정말 기술이 대단하다..)

배우고 느낀점

사실 나는 이번 부트캠프에 참여하기 전까지는 웹 프로그램에 대해 전혀 알지 못한 상태였다. 협업을 어떤 방식으로 하는지 제대로 알지도 못했고 주제 선정 이후 개발에 들어가니 마치 야생 초원에서 홀로 덩그러니 서 있는 침팬치와 같은 느낌이었다. 다 처음보는 기술 스택들이었고 내가 가진 건 열정과 의지, 인내였던것 같다. 나는 이 프로젝트에서 백엔드, 데브옵스를 맡게 되었다. 우리 팀은 기능이 많지 않아 내가 개발한 API는 많지 않았고 기술스택들을 많이 사용하는 측면이 컸다.(멘토님께서는 이 프로젝트는 기능을 적게하고 많은 기술 스택들을 써보는 것이 목적이라고 말씀하기도 하셨다.) 내가 배운 기술 스택들은 Flask, AWS EC2, RDS, S3, NGiNX, 모니터링툴(Grafana, Prometheus, ELK Stack), Redis, Rabbitmq, Celery가 있다. 나는 개인적으로 상품 검색 API를 Elasticsearch로 검색엔진으로 구현시킨 부분이 정말 뿌듯했다.

flask는 관련 자료, 레퍼런스, 예제 등이 확실히 장고보다 부족하다.

여러 기술 스택들을 접목시키기 위해서는 모두 구글링으로 찾아보았고 전 부트캠프에서 비슷한 기능을 사용한 프로젝트(깃허브)를 참고할 수 밖에 없었다. 그러나 flask는 관련 자료가 나에겐 너무 부족했고 내가 원하는 부분을 찾기는 힘들었다. 결국 수 많은 삽질이나 멘토분들이나 지인에게 물어보며 어떻게는 성공시킬 수 있었다. 개인적으로 다음에도 프로젝트를 하게 된다면 flask는 절대 쳐다도 보지 않을 것이다.

웬 만한 자료들은 구글링만 제대로 잘하면 다 나온다.

사실 위에서 flask는 관련 자료가 많이 없다라고 말했지만 이건 내가 구글링을 잘 못한것 일 수 도 있고 관련 자료를 보았어도 내가 이해를 못해 적용을 못시킨것 일 수 도 있다. 내 수준의 프로젝트에서는 사실 구글링만 제대로 하면 다 잘 나온다. 처음에는 구글링을 잘 못해서 많이 답답했는데 그래도 시간이 지나자 구글링하는 실력이 조금은 늘은 것 같다. 그래도 flask는 자료가... 많이 없는 것 같다... ㅎㅎ

백엔드만 알아서는 안된다!

부트캠프 참여하기 전에는 나는 앞으로 백엔드 공부만 할 생각이었다. 그러나 프로젝트에 참여해보니 프론트를 알지 못하면 "프론트엔드 개발자와 절대 대화를 할 수 없겠구나!, 서로 답답함만 쌓이겠구나!" 라고 생각을 하였다. 또한 우리 팀은 백엔드가 일을 다 끝내도 프론트 측이 일을 다 못 끝내면 같이 줌 회의에 남아 있어 해당 에러를 구글링 해주거나 UI/UX에서 더 나은 방향으로 의견을 내주곤 했다. 이때 나는 "아 내가 프론트 코드를 알고 짤 수 있는 수준이면 저 에러를 쉽게 해결할 수 있을 것 같은데.., 내가 코드를 짜서 도움을 줄 수 있을 것 같은데.."(실제로 백엔드가 프론트엔드보다 더 빨리 끝나서 남는 시간이 꽤 있었다.)라는 생각을 했다. 만약 내가 프론트를 잘 알고 있었다면 팀 전체로 보았을 때는 시간단축과 효율성이 극대화 되었을 것이다. 나는 데브옵스 역시 내가 몰라도 되는 부분인줄 알았다. 그러나 도커, 배포, 각종 기술스택 접목시키기 위해서는 데브옵스는 필수적이었고 데브옵스에서 가장 많이 삽질을 했다. 데브옵스가 너무 힘들었지만 다시 생각해보면 데브옵스를 내가 건들인 것에 정말 다행이라 생각한다. 실제로 스타트업에서는 백엔드가 데브옵스까지 맡는 경우도 많다고 들었다. 물론 어느 IT기업을 가도 데브옵스를 알고 있어야 하는 것 같다.

이게 팀워크구나!

앞서 말했듯이 또한 우리 팀은 백엔드가 일을 다 끝내도 프론트 측이 못 끝내면 같이 줌 회의에 남아 있었다. 프론트 측이 일을 다 끝내도 백엔드가 못 끝내는 경우 역시 같이 줌 회의에 있어 남아 있었다. 사실 어찌보면 조금 비효율적인 방법일수도 있다. 자신의 일을 다 끝마치면 쉬러가서 체력을 회복하거나 개인 공부를 하는게 더 효율적일 수 도 있다. 근데 웬지 백엔드가 다 못끝나도 프론트측이 끝날 때까지 줌회의에서 기다려주것 자체가 나는 너무 감동이었고 고마웠고 감사했다. 그저 같이 있어준 것만으로 든든했다랄까.. 막판엔 프론트 측에 너무 많은 일이 쌓이게 되었는데 이때 백엔드 측이 직접적인 도움을 주진 못했지만 해당 에러 구글링, UI/UX수정에 대한 의견 제출 등 팀 전체적으로 보았을 때 더 효율적인 부분이라 느꼈다. 내 개인의 시간을 뺏는 것이 아닌 팀 전체의 시간을 단축시키는 것이라 생각하자!

모르면 다 같이 붙어!

사실 이번 프로젝트에서 가장 많이 느꼈던 감정 중 하나가 외로움과 서러움이 아닐까 싶다. 솔직히 첫 프로젝트 참여한 사람으로써 혼자 맡은 부분에 에러를 해결 할 수 없으면 그만큼 외롭고 서럽고 답답할 수가 없었다. 딱히 해결을 해줄 사람도 생각이 안났다. 백엔드 팀원들 역시 자신의 맡은 부분을 처리하고 있었고 혼자 덩그러니 남아 있는 기분이었다. 결국 팀원들에게 요청을 하였고 바로 해결이 되는건 아니지만 같이 고민해주고 생각하고 시도하는 것 자체가 혼자서 에러를 처리하는 것 보다 심리적으로 너무 든든했다. 여러 에러처리를 다 같이 붙어서 구글링하고 시도하고 멘토들을 불러 해결방안을 찾고 수많은 삽질 끝의 마무리는 항상 성공이었다. 오합지졸들이라도 다같이 붙으면 어떻게든 해결이 된다!

모든 사람에게는 배울 점이 있다.

처음으로 팀 프로젝트를 하면서 협업이란 것에 대해 배웠다. 앞으로도 개발인생을 산다면 많은 사람들과 협업을 하고 다양한 사람들을 만나게 될 것이다. 나랑은 안 맞는 사람들은 분명히 있게 될 것이다. 그러나 그 사람들 역시 각자의 방식과 스타일이 있으신거고 그 방식을 존중할 줄 알아야 된다고 생각한다. 불평과 불만만 해서는 안된다. 그 사람들을 이해할려하고 노력해야한다. 물론 쉽지 않을 거라 생각한다. 그렇지만 이해를 하려고 노력하면 불평,불만이 아닌 배울 점이 분명히 있을거라고 생각한다. 한 친구는 오히려 자신과 안 맞는 사람한테 더 많은걸 배웠다고 말했다. 배울 수 있는 부분은 배우자!

내 의견을 확실히 말하자!

협업을 하게 되면서 나는 내 의견을 분명히 말해야 하는 사람인 것을 알게 되었다. 사실 경청을 많이 하는게 좋은 것임을 알고 있긴 하지만 내 의견을 말하지 않으면 후회되고 아쉬운 감정이 생긴다는 것을 느꼈다. 그래서 나는 최대한 사람들의 의견을 경청하고 내 의견을 말할려고 노력했다.(이 부분은 계속 더 노력해야겠다.) 어찌보면 대립대는 의견이나 요청을 그냥 말하기만 하면 상대방은 기분이 나쁠 수 있기에 내 생각이 더 나은 방안인지 상대가 납득할 만한 근거가 있는지 생각하려고 노력했다. 역시 타당한 근거와 함께 의견을 말하면 상대방 역시 이해를 하고 요청을 받아주었고 더 좋은 결과물을 이끌어 갈 수 있었던 것 같다. 충분한 생각과 타당한 근거를 두고 의견 요청!

발표력, UI/UX, 상품성

프로젝트가 마무리되고 마지막날 주최자, 멘토들, 각종 스타트업 대표들, 학교 교수님들이 최종 4팀을 선정해주셨다. 이때 선정된 팀은 각각 50만원의 상금을 받을 수 있었다. 사실 나는 우리팀이 절대로 상금을 받을 수 없을 것이라 생각했다. 다른 팀들 역시 다들 열심히하여 결과물이 좋았고 시간이 갈 수록 내 머릿속에는 기억에 남는 팀이 없었다.(이건 집중력 부족인가? ㅋㅋ) 사실 "우리팀 역시 기억에 안 남았겠구나, 모두 잘해서 어느 팀이 받아도 이상할게 없겠구나" 생각했다. 내 예상과 달리 우리팀은 상을 받을 수 있었다!! 4팀의 공통점을 생각해보았다. 어떻게 다른 팀보다 투표를 더 많이 받을 수 있었을 까...? 듣는이의 관심과 호기심을 당길 수 있게 발표력이 좋아야 기억에 남을 수 있고, 실제 배포한 사이트를 사용해 보았을 때 시각적으로 보이는 UI/UX가 좋아야 시스템이 기억에 남았을 것이다. 그러나 내 생각으로 가장 중요한건 주제다. 이 프로젝트가 돈이 되는가?, 상품성이 있는가?, 앞으로 보안과 피드백으로 현업에서 사용할 수 있는 작품인가? 의 부분에서 투표를 받아서 간신히 상을 받을 수 있었던 것 같다. 만약 다른 팀들이 발표를 상품성이 좋게 프로젝트를 홍보하듯이 판매하듯이 했다면 결과는 달랐을 것이다. 발표를 자신의 프로젝트(서비스)를 판매하듯이, 홍보하듯이 당당하게! 상품성있게!

앞으로..

우선 내가 한 프로젝트를 다시한번 돌려볼 것이다. 내가 프로젝트에서 사용한 기술스택들, 개념들을 다시 한번 정리 할 예정이다. 내가 한 프로젝트를 정확하고 완벽히 설명 할 수 있게!(이건 시간이 별로 안걸릴 것이다) 자바, 스프링은 플라스크,장고에 비해 어렵겠지만 난 할 수 있다. 한 멘토님은 김영한 무료강의 3번을 돌려보고 혼자 계시판을 구글링하며 직접 만들어 보았다고 했다. 내가 아는 실력있는 친구들도 직접 계시판을 만들어 보았다. 나 역시 그럴 예정이고 자바 스프링에 대해 더 깊이 공부할 예정이다. 이후 프론트 공부를 할 것이다. 어느 정도 내가 프론트 코드를 짤 수 있고 읽을 수 있을 정도로 공부할 것이다.(사실 어디까지 공부 해야할진 잘 몰라서 공부하면서 생각해봐야겠다.) 그런 다음 프론트부터 백까지 내가 다 만드는 나만의 토이프로젝트를 할 예정이다. 취업전까지 이 프로젝트를 유지보수를 할 예정이다. 아주 간단한, 정말 아주 간단한 기능부터 차근차근 살을 붙여 볼 생각이다. 그러면 어느 순간 꽤 쓸만한 서비스를 만들 것이라고 단연컨데 생각한다!

프로젝트 깃허브이다! : https://github.com/2023-Winter-Bootcamp-TeamH