[SMILEGATE] 2022 winterDevCamp 후기 -3

1편 보러가기 - https://smaivnn.tistory.com/5

2편 보러가기 - https://smaivnn.tistory.com/6

팀 프로젝트의 시작 ..

개인 프로젝트를 마치고 드디어 팀 프로젝트가 시작되었다.

이번 글은 팀 선정의 과정부터 시작해 우리의 환경, 주제 선정, 설계, 기술적 우여곡절, 후기를 순서로 진행하고자 한다.

 

팀 선정

팀 선정은 스마일게이트 측에서 지역별 거점, 지원한 담당 분야, 개인 프로젝트를 모두 고려하여 임의로 팀을 배정하여주었다. 그렇게 모인 우리 팀은 총 4명이었으나, 추후 우리팀과 인연이 있던 다른 1명이 다른 조에서 우리 팀으로의 변경을 희망하여 결과적으로 총 5인으로 구성된 팀이 결성되었다.

 

프로젝트를 잘 마쳐서 우리 다 같이 판교로 가자는 의미로 toPangyo라는 팀 명을 설정하였다.(ㅋ-ㅋ)

시작도 전에.. 벌써?

이번 윈터 데브 캠프의 팀 프로젝트는

1월(PMP문서 작성 > 아키텍쳐 설계) > 2월(집중 구현)의 순서로 이루어져 있었다.

하지만 PMP문서 작성도 전에 하나의 문제가 있었으니..

 

우리 팀은 각자의 사유로 1월 한 달간 팀원 5명중 4명이 외국으로 떠나버렸다..

한 명은 한국, 나는 미국, 3명은 뉴질랜드에서 각자의 일정을 소화하여야 했다..

 

하지만 우리는 자랑스러운 컴공, 컴퓨터만 있다면 그 어디에서도 서로가 만나고 작업을 할 수 있는 '디지털노마드'이다.

 

시차를 계산한 후 각자의 일정을 확인하여 팀원 서로가 배려하면서 누구는 새벽까지, 누구는 아침 일찍 그렇게 배려하며 프로젝트의 시작을 알렸다..

 

당시 회의를 위해 계산한 시차..

주제 선정

PMP문서

캠프는 팀 프로젝트의 시작 전 PMP(project management plan)문서 작성의 필요성을 강의해주었다.

또 이 때 성장을 도모하기 위해 프로젝트를 진행하며 어떤 마음가짐으로 어떤 목표를 선정하는 것이 좋은가에 대해서도 설명해주었다.

 

들어가기에 앞서,

멘토의 강연과 프로젝트를 진행하며 '내가 느낀' 좋은 PMP문서를 작성하는 법과

설계 과정에서 느낀 점을 먼저 이야기 하고자 한다.

 

내가 느낀 좋은 PMP문서란?

1. 내가 이번 프로젝트에서 '무엇(을/에)' 목적으로 두고 진행하는지가 명확해야 한다.

이 목적이라는 것의 명확함은 구체적일수록 잘 나타나고 나 스스로도 집중하기 쉽다.

예를 들어, 이번 프로젝트에서 "나는 협업 경험을 향상시킬거야!" 라는 것보다 협업 경험이 올라갔다는 것을 어떻게 파악할 수 있는지, 그것을 위해서는 어떻게 구체적으로 역량을 파악하도록 가시화 할 것인지 등을 더욱 구체적으로 세세하게 나타내야 한다.

 

2. 문서와 발표는 보고 듣는 사람의 입장에서 작성해야한다. 저들은 아무것도 모른다.

우리 팀은 문서 작성을 위해 정말 많은 시간을 투자하였다. 하지만 우리끼리는 이 내용을 알고 있는데, 문서에는 우리가 이야기 하고 알고 있는 것을 적정히 담지 못했다. 즉, 문서를 읽는 사람 발표를 듣는 사람을 고려하지 못한 문서였던 것이다.

 

어려운 문서 작성

"이런 PMP문서를 작성한 팀은 여기 밖에 없어요."

우리 팀이 작성한 PMP문서에 대한 멘토님의 첫 평가이다.

 

멘토님이 말씀해주신 '좋은 목표를 선정하는 법'은 우리에게 낯설고 어려웠다.

캠프는 우리에게 MSA구조의 경험을 권장했다.

그래서 처음 우리 팀의 목표는 MSA구조의 경험, 협엽 경험의 향상 등으로 설정했으며 개인 목표 또한 서버 잘 구성하기, 모델 잘 구성하기 등 정말 추상적인 목표 범벅이었다.

 

하지만 리뷰 이후, 우리의 문제점을 어렴풋이 알았다. 구체성이 없는 목표였을 뿐이었다.

 

잘하고 싶던 우리는 즉각적으로 수정에 들어갔다.

우선 클라이언트와 서버의 니즈를 다시 파악해보았다. 우리의 클라이언트는 여러 API 특히 그 중에서 지도 API를 활용해보기를 원했고 서버 측은 채팅과 같은 실시간 통신 기술을 활용하기를 원했다.

 

자료조사 과정을 거치며 클라이언트의 니즈와 유사했던 사이트인 "진짜 서울"이라는 사이트를 발견하였고, 그렇다면 이 사이트에 매칭(채팅)기능을 함께 추가하여 조금 더 개선시켜보면 어떨까?라는 생각으로 기획을 시작하였다.

 

이 과정을 거치며 우리는 실시간성과 더 만족스러운 사용자 경험의 제공을 위해 LCP지수 2.5이하라는 팀 목표를 도출하였고, 이에 맞게 각 개개인의 목표도 수정하였다.

 

참고로 나의 개인 목표는 아래와 같았다.

1. 서버 호출을 최소화 하고 데이터를 효율적으로 읽는 스키마를 설계

2. RESTful한 API중심의 서버 구성

3. MSA아키텍쳐를 통한 서버 구성

 

더 어려운 아키텍처 설계

우리팀의 문제점은 하나 더 있었다.

바로 경험이 적은 것이다..

우리 팀은 모두 개인 프로젝트는 한 두번 진행 해보았으나 팀 프로젝트를 통해 협업을 한 경험도 적을 뿐더러

인프라 설계, 아키텍쳐를 고려한 개발을 진행해본 사람이 없었다. 나 또한 마찬가지였다.

 

아키텍처 설계 당시 "전체 아키텍처를 내가 한번 담당 해보겠습니다!" 라고 패기롭게 말한 후 고민이 많아졌다.

특히 채팅과 관련해서도 어떻게 현업에서 많이 채팅 서버를 구현 하는지, 알림 서버는 어떻게 구현하는지 등 모르것이 태반이었다. 

 

내가 선택한 방법은 물어보는 것이다. 검색만으로는 이해의 한계가 있었고 내가 궁금한 부분에 대해 사업을 하는, 현업에 있는 친구/사람들에게 적극적으로 물어보았다.

 

특히 정말 엄청난 인연이 있었는데, 이 당시 나는 미국 조슈아 트리 투어를 진행중이었다. 투어 마지막에 함께 캠프 파이어를 하는 시간을 가졌는데 이때, 투어 일행분들과 대화 중 알고보니 이 일행분들이 대기업 개발자 단체, 심지어 인프라팀이셨다. 정말 엄청난 기회이고 인연이라고 생각했다.

 

사실 투어 막바지에 이르러 거의 돌아갈 준비를 하던 중 이 사실을 알게돼서 조금 다급해진 면도 있었는데, 돌아가는 차 안에서 용기를 내어 이 분들께 아키텍처 설계에 있어 고민하던 부분, 어떻게 구성해야 합리적일까에 대해서 정리 안된 질문을 하였는데 참 감사하게도 친절히 답을 해주셨으며 혹시 더 궁금한게 있다면 연락을 주어도 괜찮다고 하시며 연락처도 주셨다. 정말 좋은 선배님을 만났고, 신기한 경험이었다.

 

이렇게 여러가지 방법을 거쳐 최종적으로 만들어본 설계는 아래와 같다.

팀 프로젝트 '동세권'의 전체 아키텍처

이는 추후 아키텍처 리뷰 시간에 멘토님들께 "그래도 나름 합리적인 설계다."라는 멘트를 들을 수 있었고 이 모든 것을 거져 정말 좋은 경험이 생겼다고 생각중이다.

 

시작된 프로젝트

문서와 설계 단계를 마친 우리는 드디어 구현에 착수하였다.

우선 우리가 구현한 프로젝트에 대한 소개와 사진을 보여주겠다.

동세권의 소개, 매인 접속 화면

모집글과 채팅&매칭 화면

파트 분배와 신경 쓸 부분

나는 이번 프로젝트의 구현에서 뜻하지 않게 많은 부분을 담당하게 되었다.

유저, 인증, 채팅, 매칭 서버를 담당하게 되었다.

"어 이거 파트 분배 잘못된거 아니야? 양이 왜이래?"라고 생각할 수 있지만

유저, 인증 서버는 개인 프로젝트에서 진행한 부분을 활용하기로 하였으니 채팅, 매칭 서버를 주로 담당했다고 보면 된다.

 

사실상 하나만 확실히 담당하기도 힘들겠지만  다른 팀원들 모두 적절한 서버를 담당하기도 하였고

어차피 후반부에는 각 부분의 연동을 확인하여야 하기에 다 같이 모여서 진행해야 했다.

 

나는 내가 맡은 부분에 대해서 특히 채팅방과 매칭방의 실시간 유저 변동, 그리고 이로 인한 데이터의 저장에 집중하였다.

 

실시간성, 특히 소켓 통신으로 진행되는 이 부분은 계속해서 변동되는 데이터의 저장에도 정말 많은 골머리를 썪였는데.. 

프로젝트를 진행하며 발생한 문제점 들에 대해 정리를 해보았다.

 

성공과 실패, 발생한 문제들

데이터 저장과 호출 시간 겹침 문제

1. 위 사진에도 나와 있듯이 데이터를 저장함과 동시에 호출하는 시간의 겹침 문제이다.

예를 들어 클라이언트가 글 생성 이후 해당 페이지로 즉각 리다이렉션 시키며 생성된 글에 대한 정보를 가져온다고 할 때

서버에서는 이 것을 생성>호출 이라는 단계를 거친다.

 

이 때 아직 생성되지 않은 데이터에 대한 호출이라는 과정이 생기게 되는데 매칭 기능 구현 중 발생한 대부분의 문제점이 이에 해당하는 문제였다.

 

특히, 이 부분은 프로젝트 막바지에 이르러 발견 되었는데 따라서 우섭은 급하게 setTimeout()함수를 통해 늦게 호출한다는 편법을 사용하였다.

이 회고록을 작성한 이후 트랜젝션, 호출문제 등의 키워드로 공부해본 후 다시 글을 업데이트 할 예정이다.

 

 

2. LCP 최적화 실패

구현 직후 LCP 테스트

LCP지수 레벨, 출처 : https://web.dev/i18n/ko/lcp/

우리 팀이 구현한 동세권 사이트의 개발 직후 LCP지수는 5.3으로 평균적으로 poor한 레벨이었다. 

2.5가 GOOD의 상한선인 것을 본다면 굉장히 안좋은 결과이다.

 

우리는 이러한 팀 목표인 LCP점수를 개선하기 위해서 여러가지 방법을 찾아 보았는데, 자료 검색 중 발견한 여러가지 방법은 아래와 같다.

- LCP 리소스를 최대한 빠르게 로딩 시작.

- LCP 요소가 로딩을 마친 후 최대한 빠르게 렌더링 되도록 한다.

- LCP 리소스 로드 타임을 줄인다.

- 초기 HTML을 최대한 빠르게 전달한다.

 

이 중 우리가 지금 당장 적용 가능 한 방법을 뽑아 보았는데, 우리가 적용한 방법은 아래와 같다.

- 요소 발견 때 최적화

필요에 따른 실행 구현, 용량이 큰 불필요한 요소가 항시 실행되며 이를 필요에 따른 가져오기로 변환하여 해당 페이지가 생성될 때 script를 생성한다.

개선 전

개선 후

- 렌더링 지연 제거하기

스타일 시트 줄이기

- 리소스 로드 타임 줄이기

웹 폰트 경량화

스타일 시트 정리 및 웹 폰트 경량화

개선에 따른 LCP지수 변화

위 과정을 거치며 플랫폼의 LCP지수는 5.3 > 3.7 > 3.3으로 "적절한 개선이 필요(권장되는)한 단계"까지 내려왔다. 사실 만족스러운 결과는 아니지만 앞 자리가 두 번 바뀌었다는 것에 긍정적으로 생각한다.

 

3. 그 외 성공과 실패들

이 부분은 정말 많기에 발표 ppt의 사진으로 대체하겠다.

성공 클라이언트&서버

실패/부분 성공 클라이언트&서버

정말 많은 부분에서 성공과 실패를 하였다.

특히 구현은 어느정도 완료 했지만 전체적으로 보면 프로젝트의 완성도는 굉장히 낮다고 할 수 있다.

팀 목표, 여러가지 개인 목표 등에서도 완전한 성공을 거둔 부분은 적었다.

나는 이 부분에서 왜 성공하지 못했을까, 뭐가 문제일까?라는 근본적인 질문을 던져 보았다.

 

그래서.. 뭐가 문제였을까?

이 질문에 대한 답은 너무 뻔한 답변이며 너무나도 당연한 답이었다. 뒤로 나올수록 바로 앞의 문제점에서 파생되는 문제점인데, 그것이 뭐냐면 ..

 

역량 파악 실패

우리 팀원은 하고싶은 것이 참 많았다. 그래서 세세한 기능 하나하나 다 넣고, 하고 싶은 것 다 넣고.. 정말 다 추가 하였다.

그러다보니 경험없는 우리 팀원이 시간이라는 주어진 리소스 안에서 우리의 능력대로 개발을 하는 것에는 무리가 있었다.

 

선택과 집중의 실패

뒤늦게 이를 파악한 우리 팀은 재 점검에 들어갔고, 우리가 목표로 했던 기능을 제외하고는 모두 구현에서 제외했다.

채팅과 매칭에 필요한 기능만 구현하고 그 외 예를들어 마이페이지 등은 후순위로 미루고

또 아키텍처 등에서도 내가 안써본거, 잘 모르는거에 대해서 급하게 제외하고 수정하며 진행하였다.

 

이는 철저한 선택과 집중의 실패라고 판단한다.

 

시간 관리 실패

결국 위 두가지 문제점은 시간 관리에 실패하게 만들었다.

갈 수록 촉박해지는 시간에 의해, 나중에는 철저한 설계를 하지 못한 주먹구구식 개발을 다시 진행하게 되었다.

 

API명세서에도 없는 것을 "이거 필요한데.."하면 그냥 대충 만들어버리고 그렇게 진행하였다..

최악의 결과였다.

 

문제의 결론

자기 객관화의 실패.

프로젝트를 진행한다는 것은 공부하고 발전하기 위해서 이기도 하지만, 내 능력을 파악하기 위해서라고도 생각한다.

무엇인가를 구현하면서 내가 뭐가 부족한지 이 부분은 어떻게 진행해야 하는지에 대해서 알 수 있고, 이러한 것들이 하나하나가 모여 경험이 되며 자기 객관화가 되는 것이다.

 

나는 이번 프로젝트에서 이 과정과 경험을 겪었다.

 

그래서 나는 무엇을 얻었고 어떻게 성장하였나?

사실 이번 회고록을 쓰기 전, 핫한 AI인 chatgpt에게 좋은 회고록이란 무엇인가? 물어보았다.

캠프를 진행하며 회고를 할 수 있는 정말 좋은 경험(데이터)을 얻었다. 그렇다면 이것을 소화시키고 회고하고 기록하는 것은 온전히 내 역량의 몫이다.

 

이 회고록이 좋은 회고록이 될지 그리고 나의 성장과 성찰을 잘 나타내어 줄지는 잘 모르겠다.

하지만 가능하다면 잘 녹여내어 후기를 남겨보고자 한다.

 

이번 프로젝트를 진행하며 많은 우여곡절을 겪었다.

목표의 성공과 실패, 데이터베이스 문제 등 참 많았다.

 

여담으로 컨텐츠를 저장하는 aws디비에서 하루만에 50만원이 청구(한달 예상200만원)되는 일 도 있었고

분명 잘 되던 파트가 하루 아침에 안되는 일도 있었고 정말정말 많았다.

 

이번 프로젝트를 진행하며 나는 너무 당연한 말이지만 경험을 얻었다.

이 경험은 팀원과의 협업과 소통, 서로가 의견을 표출하는 방법과 듣는 방법부터 시작해서

기술적인 탐색, 개발을 진행하며 여러가지 막힌 부분이 있을 때 다양하게 탐색하는 법, 자료를 찾아보고 문제를 해결해 나가는 것.

그리고 무엇보다도 나 스스로에 대한 파악 즉, 자기 객관화를 정립할 수 있었다.

 

사실 아직 이 캠프에서 지향하는 구체적인 개발자의 성장이라는 키워드에 대해서 잘 은 모르겠다. 내가 이해 해보고 1,2 그리고 이번 3편에서 정리해본 좋은 문서, 좋은 프로젝트, 좋은 성장이라는 것이 과연 이번 윈터 데브 캠프가 지향하는 부분과 부합할까?라는 의문이 존재한다.

 

하지만 이번 캠프는 분명히 나로 하여금 많은 부분을 느끼게 하였고, 실제로도 많은 부분을 얻어갈 수 있었다.

마지막 후기가 너무 추상적으로 끝나는 것 같긴 하지만 맞는 말인 것을 어떡하나, 내 실력이 게임도 아니고 개인의 성장에 대한 지표를 단계로 나타낼 수가 없는데..

 

한 문장으로 정리하고자 한다.

나는 이번 캠프를 통해 이전보다 더 나은 나로의 성장을 이루었다.

 

-완-