[SSAFY/2학기] 공통 프로젝트 1~3주차 회고록 1편

정신없이 하다 보니 1학기는. 어느새 끝나 있고 계절학기, Job Fair 기간을 지나 2학기 프로젝트가 시작되었다. 처음에는 자기소개를 하며 각자 원하는 팀을 만드는데 그게 벌써 5주 전?이다. 한 프로젝트 당 6주가 주어지는데 벌써 3주가 지났다니 참 빠르다 ㅠㅠ

3주간 많은 일이 있었고 느낀 점, 배운 점이 있어서 회고록을 작성한다!

---

어려움 1. 주제선정 (Week 1)

공통 프로젝트는 SNS, Web RTC, IOT라는 세 개의 주제 안에서 하나를 선택하여 진행된다. 우리 팀은 자유도가 높아 보이는 SNS를 선택했다. 초반에는 반려동물, 요리 전용 릴스 영상 등 여러 아이디어가 나왔다. 아이디어가 나올수록 SNS라는 주제에 사로잡혀 기존 서비스와 차별점이 없어졌다. 자유도가 높아서 선택했는데 타 서비스에 얽매여버리는 꼴이었다.

한 팀원 분께서 요즘 메타버스가 뜨는 데 사용해보는 것은 어떨까?라는 말이 나왔다. 그래서 명함을 메타버스로 표현해보면 재미있을 것 같아 '명함 메타버스 어떤까요?'라는 의견을 제시했다. 팀원들이 긍정적으로 봐줬고 '메타버스를 활용한 명함 서비스'를 선정하게 됐다.

 

주제를 명확히 하고자 메타버스가 무엇인지 또한 어떤 기술을 사용하는지 찾아보았다. 우리 팀은 메타버스를 가상현실 속에서 자신을 표현하는 기술이라고 정의를 내렸고 이러한 기존 서비스가 무엇이 있는지 찾아봤다. 제페토, 게더 타운 서비스가 있음을 알 수 있었는데 이 정도 수준까지 구현할 자신이 없었다. '짧은 기간 처음 사용하는 신기술을 저 정도 수준까지 구현할 수 있을까?', '3D와 디자인을 어떻게 해야 할 것인가?' 등 여러 어려움이 있음을 알게 되었다.

'명함을 카메라로 인식하면 그 위에 AR로 정보를 띄워보는 건 어떨까?' 라는 이야기가 나와 AR에 대한 사전조사를 시작했다. 구글링을 하다가 웹 브라우저에서 동작하는 AR SDK를 제공해주는 Letsee라는것을 알게 되었다. 렛시를 사용해 EXO, 라면과 같은 홍보자료 예시와 Github에 코드가 올라와져 있어서 사용해봤다. 뭔가 생각했던 것을 할 수 있을 것 같은 느낌?! 이걸 기반으로 팀원들과 이런저런 이야기를 했다.

AR 기능에 초점을 두고 아이디어를 생각하니 정말 많은 아이디어가 나왔다. 너무 SNS라는 틀에 갖혀 있었던 거 같다!

 

 아이디어 선정 시, 하나에 얽매이지 말고 자유롭게 이야기 하자!

그래서 여기서 내가 배운 점은 아이디어 선정 시에 주제에 너무 얽매이지 말고 자유롭게 아무 이야기나 하는 것이 좋다는 것이다. 주제에 맞춰서 생각하면 기존 유명한 서비스들을 벤치마킹할 수밖에 없어 창의력이 떨어지는 것 같다. 팀원들과 아무 이야기도 좋으니 취미, 관심 있는 것, 요즘 트렌드 기술 등 다양한 주제로 이야기 나누면서 툭툭 나오는 아이디어가 정말 좋은 것 같다! 그러니 아이디어 회의는 아무 이야기나 다 하는 걸로!!

 

---

어려움 2. 기획 (Week 2-3)

주제 선정 끝나고 기획회의를 들어갔다. 기획 때는 기능 명세서, 와이어프레임, DB ERD를 작성했다. 물론 이걸 진행하면서 AR 기능을 이용한 사물 인식 테스트, 카카오톡 API 테스트 및 컨벤션 정하기 그리고 발표 PPT 준비도 동시에 했다... ㅎ

아이디어 회의를 하면서 좋다 좋다 했지만 기능 명세를 진행하면서 큰 어려움을 겪었다. 말로만 이야기를 나누니 서로가 한 말이 이해가 잘 되지 않았다. 코로나가 아니었다면 오프라인으로 만나서 바로 그림을 그려주면 되는데 말로만 설명하려니 나도 어렵고 내 말을 듣는 팀원들도 어려움을 겪었다. 그래서 나는 팀원들에게 러프하게 프로토타입 작성을 해서 발표하자!라고 제안을 했다. 각자 그림을 그려와서 공유를 했는데 세상에나.... 이해한게 각자 다 달라서 신기하면서 놀랍고 그것 하나로 맞춰가는 과정이 정말 힘들었다.

 

모든 일을 함께 하려고 하지 말자!

러프하게 공통된 부분들을 맞추고 기능명세를 작성했다. 코치님께 어떻게 진행하면 좋을지 조언을 구했다. 코치님께서는 기능명세를 같이하면 생각한게 달라서 시간이 더 오래리기 때문에 절대 모든 것을 같이 하려하지 말라고 하셨다. 그래서 기능별로 분담하여 명세서를 작성했고 모두 취합한 다음 하나씩 기능을 살펴봤다. 팀원이 5명이었는데 각자 생각을 말하고 하나로 통합하는 과정이 진짜진짜 오래 걸렸다. 코치님께 여쭙지 않고 했다면.... 아득하다...^^

 

 

기능 명세가 어느 정도 끝나고 기술 스택을 정의했다. FE, BE, DB에서 어떤 프레임워크를 사용할지 결정하고자 프레임워크 별 특징을 찾아봤다. 나는 BE와 DB를 담당하였고 DB 선택을 위해 팀원들이 사용해본 DB가 무엇인지 조사했다. MongoDB, MariaDB, MySQL, SQLite 등 여러 DB가 있었고 추가로 많이 사용되는 DB가 무엇인지 찾아봤다. PostgreSQL 이라는 DB가 많이 사용되는 것을 알았고 각 DB가 어떤 장점과 단점이 있는지 찾아보며 우리 프로젝트와 맞지 않는 DB를 지워나갔다.

 

어떤 DB를 사용할까?

 

위의 과정을 통해 PostgreSQL이라는 DB를 선택하게 되었다. 그리고 팀원들에게 의견을 구했는데 PostgreSQL의 단점과 문제점을 찾아서 아래와 같이 상세히 알려주셨다.

PostgreSQL 문제점

 

덕분에 미쳐 알지 못했던 PostgreSQL의 단점을 알게 되었고 다시 한 번 찾아볼 수 있는 좋은 기회였다. PostgreSQL이 어떤 점에서 안좋은지 알고 싶다면 우버가 PostgreSQL을 사용하지 않는 이유를 읽어보는 것도 좋은 것 같다! 다만 영어 원문 이라는 점... ㅎ

아래는 추가로 알아본 단점을 기반으로 DB를 선택한 나의 최종 결론이었다!

나의 결론

 

기술 스택 선택에 있어 가장 중요한 점은 나의 프로젝트에 맞는 특징을 가진 기술 스택을 선택해야한다는 것이다. 이를 위해선 그 기술 스택의 장점뿐만 아니라 단점 모두 확인해야한다.

 

 

이 과정을 통해 내가 배운점은 무엇인가 선택할 때는 그 것의 양면을 다 봐야한다는 점이다. 나는 오 좋다 괜찮네?하고 선택했는데 장점도 있는 반면 어떤 상황에서는 단점이 될 수 도 있음을 간과했다. 이를 지적해 준 팀원 덕분에 우리 프로젝트 성격을 다시 돌아보고 이에 적합한 기술 스택을 선택할 수 있어 굉장히 기뻤다!

---

어려움 3. 인력 부족

 

팀원 한 분께서 취업을 하게 되어 팀을 떠나게 되었다. 사실 이 날 6시 프로젝트가 끝나자마자 잠들어서 9시에 일어나고 카카오톡을 확인했는데 알게되어 순간 멘붕이었다. 좋은 곳에 취업하게 되어 너무 축하했지만 한편으로는 큰 걱정이 되었다. 

팀원이 4명이면 팀을 해체하고 다른 팀으로 들어갈 수 있는데 어떻게 할지 만약 팀을 그대로 유지한다면 앞으로의 방향성을 어떻게 가져갈지 논의하고자 팀원들가 Zoom을 열어 회의를 했다. 다행히 팀원 모두 우리의 아이디어가 너무 좋고 포기하고 싶지 않아했다. 그래서 우리는 팀을 유지하기로 결정했다!

 

기간 내에 프로젝트 수행을 하기 위해서 어떻게 해야하지?

그럼 우리가 이 프로젝트를 수행하기 위해서 어떻게 해야할까?를 논의했다.

 

우선 순위가 낮은 기능은 과감히 제외하자!

 

첫 번째로, 가장 먼저 기능명세서를 작성하며 우선 순위가 낮았던 부분들을 과감하게 제외하였다. 추천 필터 기능, 검색 결과 간소화 등 없어져도 메인 기능에는 전혀 문제가 되지 않는 부분들을 없애버렸다. 

 

시간을 더 투자하자!

 

두 번째로, 야근을 선택했다. 그 이유는 이 고난을 이겨내고 프로젝트를 완성했을 미래의 나를 생각하면 분명 얻는 것이 더 많을 것이라고 생각했고 우리 팀의 아이디어가 너무 좋아 꼭 완성시켜보고 싶었기 때문이다. 덕분에 주말의 나를 프로젝트에 갈아넣어야 하지만... 너무 죠...타...ㅎㅎㅎㅎㅎㅎㅎㅎㅎ

 

Jira 티켓의 스토리 포인트를 넘기고도 해결하지 못한다면 무조건 팀원에게 도움을 요청하자!

 

마지막으로 모른 것이 생기면 무조건 팀원에게 알리기로 했다. Jira 티켓에 지정한 스토리 포인트를 넘기고도 해결하지 못한 내용을 혼자서 계속 끌고간다면 상황이 더욱 악화된다고 판단했기 때문이다. 팀원들에게 문제를 공유한다면 팀원들이 해결법을 알고 있을 수도 있고 모른다면 함께 해결법을 찾아 문제를 더 빨리 해결할 수 있다.

사실 이 것은 내가 제안한 것인데 그 이유는 내가 한 문제에 직면하면 계속 내 생각에만 사로잡혀 쉬운 문제임에도 바로 캐치하지 못한 경험이 있기 때문이다. 내가 겪은 문제를 타인에게 공유했을 때, '이렇게 하면 되는거 아냐?' 라는 말을 듣자마자 '아 맞네? 알고 있던건데 왜 그렇게 생각했지?'라는 생각이 들 때가 있었다. 뫼비우스의 띠처럼 틀린 해답만 머릿속에서 반복될 때, 다른 사람의 한 마디로 쉽게 해결되는 경우가 있었다.

---

배움. 발표를 잘하기 위해서는?

나는 발표를 하지 않고 듣는 입장이었는데 느끼는 점이 많았다. 총 8개의 팀이 발표를 하는데 발표자마다 자신만의 스타일대로 발표를 진행했다. 다들 잘하셨지만 우리 팀원 분 발표가 최고 👍🏻

 

아무튼 내가 느낀 발표 잘하는 법을 공유해보려한다.

 

1. 스몰톡으로 시작하자!

스몰톡으로 시작하니까 초반에 시선을 끌 수 있고 기존 발표로 루즈해진 공기를 리프레시 할 수 있었다.

 

2. 단조로운 목소리는 NO!

일관된 목소리로 발표하시는 분이 계셨는데 집중하지 않으면 한 귀로 흘러나갔다. 그러다보니 다른 발표를 들을수록 기억에서 잊혀져 갔다...

 

3. 스크립트를 읽는 듯한 말투 NO!

옆에 스크립트를 띄워놓고 따라 읽는 느낌을 받은 발표 역시 위의 내용처럼 귀에 쏙쏙 들어오지 않았다. 그리고 부자연스러운 느낌이 들어서 발표 듣는내내 약간 불편했다.

 

4. 청자가 공감할 수 있는 질문 던지기

질문을 받았을 때 누구에게나 겪어봤을 법한 일로 질문을 받으니 뭔가 각인이 된 느낌이었다. 그러니 자연스럽게 귀 기울여 듣게 되어 좋았따.

---

프로젝트 시작한지 고작 3주 됐지만 배운게 아주 많았다.

프로젝트 열심히 해서 꼭꼭꼭 완성할거다 ㅠㅠ! 그럼 더 멋찐 개발자가 되어 있겠지?