비사이드 프로젝트 후기와 실패 회고

최근 비사이드 포텐데이 412에 참여하여 프로젝트를 진행했습니다.
결론부터 말씀드리면 저는 프로젝트에 실패했습니다.
이 포스팅에선 비사이드 포텐데이에 대해 소개하고, 제가 실패한 이유를 돌아볼 것입니다.

목차

---

1. 비사이드 포텐데이란?

• 참여자들이 팀을 구성해서  10일 동안 서비스를 만드는 온라인 해커톤입니다.
• 참여 분야는 기획, 디자인, 개발 세 종류이며, 자발적으로 팀을 구성합니다. 팀이 구성되지 않으면 비사이드에서 임의로 팀을 구성해 줍니다.
• 저는 DevOps 개발자로 참여했습니다.
• 참여비는 10만 원입니다. (얼리버드 신청 시 30% 할인)

---

2. 왜 비사이드에 참여했나?

저는 2024년 8월에 대학교를 졸업한 이후 Udemy의 강의와 여러 서적들을 통해 이론적 지식들을 공부했습니다.
그래서 저에겐 실무와 프로젝트 경험이 부족합니다. 
당연히 이론과 실무에는 차이가 존재할 것이라고 생각했고, 이 생각이 제가 프로젝트를 시작한 계기가 되었습니다.
 
팀 프로젝트를 찾기 위해 구글링 해보니 렛플, 홀라, 인프런 등 많은 프로젝트 구인 플랫폼들이 있었습니다.
저는 이 모든 플랫폼들의 게시글을 확인했고, 프로젝트의 대부분이 클라우드 엔지니어나 데브옵스 포지션을 원하지 않았습니다.

 

주업무가 개발보단 운영이 더 가까운 저의 포지션은 사이드 프로젝트에서 환영받지 못 했습니다.

아마 사이드 프로젝트의 목적은 서비스 운영이 아닌, 서비스 개발이기 때문인 듯싶습니다. 
 
그래서 저는 비사이드에 참여하게 됩니다. 그 이유는 두 가지입니다.

1. 다른 구인 플랫폼들에서는 원하지 않는 DevOps 포지션으로 프로젝트에 참여할 수 있기 때문입니다. 
2. 디자이너, 기획자, 개발자들의 협업 경험을 얻을 수 있기 때문입니다.

참가비가 10만 원이지만, 이 두 가지 이유로 10만 원을 사용할 가치가 있다고 생각했습니다.

---

3. 프로젝트 진행 과정

• 2024.12.02(월) 13시 ~ 2024.12.05(목) 09시 : 자체 팀 빌딩 (빌딩 실패 시 비사이드에서 팀 임의 배정)
• 2024.12.06(금) ~ 2024.12.15(일) 15시: 프로젝트 진행
• 2024.12.15(일) 15시: 프로젝트 마감

---

3-1 팀 빌딩하기

참여자들은 Slack 채널에 초대되고, 이곳에서 자기 소개를 합니다.
각자의 소개를 확인하고 마음에 드는 사람들과 팀을 구성합니다.

이런 식입니다. (저의 소개)

 
자기 소개 글을 게시했고 2시간 정도 기다려봤지만 아무런 연락도 오지 않았습니다.
아마 다들 저처럼 먼저 연락하지 않고 기다리기만 한 듯싶습니다.
그래서 저는 제가 직접 나서서 사람들에게 연락을 보내서 팀을 구성하기로 합니다. 그 이유는 두 가지입니다.

1. 프로젝트를 주도해보고 싶은 욕심: 이전 프로젝트에서 너무 팀장을 따라가기만 했기 때문에 이번엔 제가 주도해보고 싶었습니다. 상반된 두 경험을 겪으며 뭔가 얻을 게 있을 것이라고 생각했습니다.
2. 팀을 구성할 수 없을 것 같다는 불안감: DevOps는 개발 자체를 담당하진 않기 때문에 팀이 구성되지 않을 위험이 있다고 생각했습니다.

그렇게 첫 날의 밤 12시까지 총 열 한분께 메시지를 드렸고, 6인의 팀을 구성하는 데 성공합니다.
팀 구성은 이렇습니다: 기획자 1, 디자이너 2, 백엔드1, 프론트엔드 1, DevOps(본인) 1
 
제가 팀원을 모집한 유일한 기준은 다음과 같습니다.

'당장의 실력이 없더라도 프로젝트에 참여할 시간이 많을 것'

 
실력이 부족해도 열정과 시간만 있다면 충분히 서비스를 만들 수 있을 것이라고 생각했습니다.
그래서 저희 팀원은 모두 취준생으로 구성했으며, 모든 인원이 선약을 제외하고 10일 간 모든 시간을 프로젝트에 사용할 수 있었습니다.
하지만 돌이켜 보면 이것이 실패 원인 중 하나가 됐습니다. 이에 대한 내용은 '4. 실패 원인'에서 계속됩니다.
 
프로젝트 정식 시작 기간은 2024.12.06(금)부터지만 저희 팀은 팀을 빠르게 구성했기 때문에 2024.12.04(수)부터 회의를 시작할 수 있었습니다.

---

3-2. 아이디어 내기

어떤 서비스를 만들 지 회의하는 데 이틀이 걸렸습니다.
첫 날엔 여러 아이디어를 냈고, 기술적 실현 가능성과 경쟁력 등을 고려해서 아이디어를 간추렸습니다.
저희 서비스에선 Azure의 Computer vision(이미지 분석)을 이용하려고 했기 때문에 둘째 날엔 Azure를 공부했고 Computer vision의 성능을 테스트했습니다.
 

---

3-3 프로젝트 진행

저는 AWS, 쿠버네티스와 gitOps, 모니터링 환경 구축, CI/CD 파이프라인 구축을 목적으로 프로젝트에 참여했습니다.
하지만 AWS 작업 외 목적을 달성하지 못하고, 대부분의 시간을 백엔드 트러블 슈팅에 사용하게 됩니다. 이 이유는 '4. 실패 원인'에서 계속됩니다.
 
프로젝트 마감일 당일에는 밤을 새우며 23시간 동안 백엔드 api가 정상 동작하는 지 확인하고, 에러가 발생하면 그 에러를 해결했습니다.
하지만 마감 시간 이전에 모든 에러를 해결하진 못 했습니다.
백엔드 뿐만 아니라 프론트엔드도 완성되지 않았습니다.

---

4. 실패 원인

프로젝트 마감에 실패한 이유를 생각해봤습니다.

---

4-1. 일정 변동

저는 원래 계획에선 프로젝트 기간 동안 10일 모두 프로젝트에 사용하려고 했습니다.
하지만 예상에 없던 면접 일정으로 인해 이틀을 허비했습니다.
 
A 기업의 면접은 원래 프로젝트 기간 이전에 예정되어 있었습니다. 하지만 하필 면접일에 계엄령으로 인해 전사 재택 근무가 시행되어서 면접일이 프로젝트 기간 중으로 밀렸습니다.
B 기업에선 서류 합격 발표와 동시에 4일 뒤에 갑자기 면접을 보러 오라고 해서 갑작스럽게 또 하루를 면접 준비에 사용하게 됐습니다.
 
결국 저는 면접과 프로젝트 두 마리 토끼를 모두 잡으려다 모두 놓치게 됐습니다. (운이 좋게도 A 기업엔 최종 합격해서 1월에 입사가 예정되어 있습니다!)

---

4-2. 잘못된 팀원 선택 기준

제가 팀원을 고르는 기준으로 열정만을 확인했던 것이 패착입니다.
비사이드 포텐데이는 10일이라는 짧은 기간에 기획, 디자인, 개발을 모두 해야 합니다.
기획이 돼야 백엔드와 디자인을 할 수 있고, 디자인이 돼야 프론트를 개발할 수 있습니다. 따라서 실제 개발할 수 있는 기간은 10일 보다 훨씬 짧습니다.  따라서 기본적인 개발 실력이 뒷받침되어 있어야 합니다. 제가 이 사실을 간과했습니다.
 
저희 팀의 프론트엔드, 백엔드 개발자분들은 실력이 썩 좋아 보이진 않았습니다. (git과 대화 수준을 미루어 보아 짐작)
두 분은 공통적으로 디버깅을 할 줄 몰랐습니다. 그래서 저의 도움 없이는 해결 할 수 없던 에러들이 꽤 있었습니다.

 
남탓만 백날 해봐야.. 문제를 해결할 수 없죠

제가 직접 디버깅에 참여하기 위해서 저희 프로젝트의 백엔드 프레임워크인 Django의 기초를 공부했습니다.

파이썬을 쓸 줄 아니까 Django의 url, view, model, serializer 정도의 핵심 개념들만요.
 
이렇게 해서 드디어 디버깅할 수 있는 환경이 갖춰졌습니다. 하지만 저는 장고를 모르고, 백엔드 개발자님은 파이썬을 모르니 디버깅 과정이 다음과 같이 비효율적이여서 시간이 굉장히 오래 걸렸습니다.

1. 백엔드가 장고 코드를 실행
2. 에러 발생 시 결과를 저에게 전송
3. 제가 그 내용을 토대로 디버깅
4. 코드 수정 사항을 백엔드에게 전송
5. 백엔드가 코드를 수정, 이후 1번부터 반복

 

프론트 엔드 개발자분 또한 의사소통이 힘들었습니다. 프론트에서 에러가 발생하면 '어떤 에러가 발생했다'만 알려주고, 상세 에러 내용과 에러 발생 위치를 알려주지 않아서 디버깅을 하기 위해 세부 내용을 되묻는 과정이 필요했습니다. 카카오톡을 통해 소통했기 때문에 이 과정에는 많은 시간이 소요됐습니다.

AWS 오픈 채팅방의 비슷한 상황

 

예를 들어서 CORS 에러 발생 시 그 원인은 오리진이 될 수도 있고, 헤더나 메소드가 될 수도 있고, 프론트의 코드가 될 수도 있고, 이번 프로젝트의 경우엔 'redirect is not allowed'라는 에러 메시지도 있었습니다. CORS의 원인이 이렇게 다양할 수 있는데 CORS라고만 얘기하면 디버깅을 할 수가 없습니다.

---

 

하지만 개발자 두 분 모두 열정적으로 참여하고 협조해주신 점은 감사하게 생각하고 있습니다.

10만 원을 지불하고 프로젝트에 참여하는 사람들이라서 프로젝트 마감 기한은 12/15지만, 글을 작성하고 있는 12/31까지도 꾸준히 개발하고 있습니다.

---

5. 어떻게 해야 했을까?

저는 제가 프로젝트에서 사용하고 싶던 kubernetes, gitOps, fluentbit를 포기하고 운영보단 프로젝트 개발에 기여했습니다.

또한 면접으로 인해 프로젝트에 사용하지 못 한 시간은 잠을 줄여 프로젝트에 사용했습니다.

그래서 저는 제가 처한 상황에서 최선의 행동을 했다고 생각합니다.

 
그럼에도 후회스러운 일이 하나 있는데, 회의를 진행하지 않은 것입니다.
프로젝트 시작 당일에 저는 '하루나 이틀에 한 번씩은 디스코드에서 회의를 통해 서로의 진행 상황을 공유하자'고 했지만 팀원들은 번거로울 것 같다며 노션을 통해서만 공유하자고 했습니다.

 

다수결이니 어쩔 수 없이 그 의견에 따랐지만, 저는 회의를 하자고 설득했어야 했습니다.

텍스트를 통해 전달할 수 있는 메시지는 한정적입니다. 

예를 들어서 개발자들은 디자이너분들이 노션에 적은 작업들 중 하나인 '핸드오프'가 무엇인지, 또 기간이 얼마나 걸리는 작업인지 알 수 없습니다.

이것은 디자이너분들 입장에서도 개발 작업을 확인할 때 마찬가지일 것입니다.

 

만약 회의를 진행하며 서로의 진행 상황을 즉각적으로 공유했다면 서로가 얼마나 서둘러야 했을 지 알게 될 것이고, 다른 팀원의 부족한 점을 어떻게 도울 수 있을 지 생각할 수 있었을 것입니다. 

 

---

6. 이 경험에서 알게 된 점

6-1. 의사 소통은 정말 중요하다

현업자분들의 인터뷰를 보면 같이 일하고 싶은 동료로 항상 '의사소통이 잘 되는 동료'를 꼽았습니다.

그리고 전 이번 경험에서 그 이유를 깨달았습니다.

 

기획자님과는 의사소통이 정말 잘 됐습니다.

저와 기획자님 모두 조금이라도 이해가 안 된 내용이 있다면 서로 즉각 물어봄으로써 명확하게 서로의 이해도를 공유했습니다. 

이로 인해 할 일이 명확해졌으니 저도 빠르게 저의 일을 처리할 수 있었고, 기획자님도 의도한 대로 일을 맡길 수 있었습니다.

이해가 안 되는 점이 있다면 이해가 될 때까지 물어보는 행동이, 번거로워 보여도 오히려 가장 효율적으로 목표를 달성할 수 있는 방법임을 알았습니다.

 

반대로 상술했듯 개발자분들과는 의사소통이 힘들었습니다.

특히 한 분은 부모님 핑계를 대며 디스코드에 참여하지 않았습니다.

그래서 그분은 채팅을 통해 소통했고, 함께 디버깅을 할 땐 저의 시선을 채팅창에 고정해야 했기 때문에 터미널 보랴, 채팅창 보랴 고생이 많았습니다.

---

6-2. 절대 도구에 의존하지 말자

백엔드 개발자분을 보며 느꼈습니다.

그분은 ssh, scp 명령 대신 mobaxterm을 사용했고, curl 명령 대신 postman을 사용하는 등 GUI 도구에 의존했습니다.

따라서 그분은 mobaxterm을 통해 자신이 ssh 연결 동작을 수행하고 있음을 알지 못합니다.

 

GUI 도구는 분명히 편리한 점이 있습니다.

하지만 그것을 사용할 땐 적어도 자신이 어떤 동작을 하고 있는지는 알아야 한다고 생각합니다.

이 점은 비단 GUI 도구를 사용할 때 뿐만 아니라 모든 컴퓨터 동작에도 포함됩니다.

예를 들어 kill -9 {PID} 명령을 실행한다면 kill 명령이 무엇인지, -9 옵션이 뭘 의미하는지, PID가 무엇인지는 반드시 알아야 합니다.

---

이것으로 2024년의 마지막 포스팅을 마칩니다.

내년에는 더 발전한 제가 되길 기대합니다.

다들 새해 복 많이 받으세요!!