2024-02-06 ~ 2024-05-20 기나긴 여정 회고

첫 단독 외주 프로젝트를 마무리하며 회고록을 작성한다.

 

2~3월달은 기존 개발되어 있던 내용의 리팩토링 작업을 진행하고, 발생하던 오류들 및 중복 코드, 버전 업데이트 등을 중점적으로 진행하였다.

 

기존 개발되어 있던 스택은 ts, express, mysql, react 형태였고, 프론트의 경우 클라우드 프론트를 통해 서빙되고 있었다.

발생한 오류들로는 화상의 연결이 끊기거나, 채팅 메시지들의 집계가 잘 동작하지 않는 정도 수준의 오류들이었고,

잘 마무리 하였다.

 

2~ 월부터 4월 초까지까지 기획되어 있던 부분들의 부족한 부분들과 실현 가능한 부분들로 수정을 돕고, 실제로 개발할 수 있는 기간은 한 달 반정도 였다.

 

한 달 반동안 진행한 결과물은 API 서버 및 프론트엔드 프로젝트 2개 ( 클라이언트, 어드민 ) 한 달 반동안 대부분 밤을 새며 하루 17시간 씩 일만 했던 것 같다.

 

어쩌다 이렇게 일을 하게 됐는가? 계약서는 반드시 목표설정을 확실하게 할 것 목표가 추상적이라면 돈을 더 많이 부를 것

 

일을 많이 하긴 했지만 그래도 좋았던 점들도 너무 많았다.

우선 외주를 진행하기 앞서 근무하던 회사에서 퇴사 후 개발과는 전혀 상관없는 사업을 잠시 하다 돈만 까먹고 폐업 처리를 진행했다. 이 과정들 또한 배운것들이 많다. 막연하게 사업자를 내는 것부터 폐업 신고하기까지

 

개발을 하지 않다가 다시 이 일을 시작하려다보니 다시 처음 시작하는 느낌도 들었다.

 

이런 걱정이 무색하게 2주 정도 밤새고 하다보니 다시 기억들이 돌아오더라. 단축키는 절대 잊지 않았지.

 

한 달 반정도 개발 한 내용의 기능들은 다음과 같다.

1. 실시간 화상 통화

2. 결제

3. 정산

4. 기타 게시판들

5. 다국어

6. 채팅

7. 화이트보드

8. 스크린 레코딩

 

이렇게 적으니 많아 보이지 않는 것처럼 보이긴 하다.

더 적어보면

1. 디비 설계

2. 디자인 시스템

3. 컴포넌트 화

4. 인프라 구성

 

프론트엔드 페이지 장수로는 한 120장 정도 진행 했던 것 같다. 

 

서버 프레임워크의 선택은 이전부터 expressjs를 주로 사용했고, 프레임워크 수준 정도로 형식화해서 사용했었는데 오히려 그게 나를 우물 안 개구리로 만든 것 같은 느낌을 받았었고, 마지막으로 들었던 프레임워크 중 핫하다는 nestjs를 선택했다. 사용해본 소감은 너무 편했다. expressjs 에서 설정해주어야 하는 대부분의 것들을 단순 클래스 인젝트 하는 부분으로 대체 가능했고, 모듈 시스템은 정말 감동적이였다. 추가로 이전에 개발되어 있던 프로젝트가 expressjs로 nest형태를 만들어서 쓰고 있었더라. 감탄했다

 

디비는 기존 개발되어 있는 형태가 mysql 쿼리를 직접 작성한 형태였다. ORM을 굳이 쓸 필요는 없지만 코드 퀄리티 차원에서 읽기 편하게 하기 위해 프리즈마( PRISMA ) 로 대부분의 쿼리를 커버했는데 호환이 안되는 부분들이 있었다.

이로 인해 프리즈마를 좀 더 알게 되었는 데 원하는 쿼리 형태를 작성하려다가 "이게 안돼?"라는 포인트로 기술 리서치를 하다가 프리즈마가 단순 orm을 지향하는 건 아니라는 문구를 인용해서 특정 기능들이 동작하지 않는 것을 커버 하고 있었다.

 

나에게 주어진 시간은 많지 않았기에 가장 많이 사용하던 mongodb로 다시 방향을 틀었다.

이때 라이센스에 대한 이슈가 있었기 때문에 정말 많은 리서치를 하였고 결국에는 사용하기로 결정되었다.

 

대부분의 디비 설계 된 내용을 nosql 의 장단점에 맞게 전부 재설계를 진행해야 했다. 관계가 맺힌 부분 중 흡수 될 수 있는 부분들, 관계 없이 길게 나열되어 있던 칼럼들을 검색에 필요한 부분들로 재구성하여 분리한다 던가 하는 일련의 과정들 (정규화 등등)을 거쳐 디비 설계를 마무리 했다. 설계할 때 포인트를 뒀던 부분이 검색했을 때 어떤 데이터가 더 많이 select 될까 뭐가 더 업데이트 가 안될까? 이 부분을 중점적으로 본것 같다.

 

또한 기존에 개발되어 있던 부분들의 결제 시스템 또한 완전히 새롭게 구성해야 했다.

카드 등록 이후 빌링 할 수 있도록 개발되어 있던 부분들을 전부 결제 위젯으로 변경하고, 해외 결제 모듈 또한 걷어 내며 토스 하나로 결제 모듈을 끝 맺었다.

 

신규로 정산 시스템을 개발하게 되면서 해외 결제건에 대해 조회 api 가 동작하지 않아 수수료 등을 직접 다 계산해야 했다. 조회 api에 해외 결제 건에 대해 제공되지 않는 다는 내용이 개발자 용 문서에 있었으면 더 좋았을 텐데 계약하는 곳에 있었다 보니 확인을 못했다. 그래도 토스 너무 좋았다 편리하고 대단한 업체인듯

 

유저 관리나 인증 등에 개발은 너무 당연한 부분이라 금방금방 한 듯

 

아 가장 어려웠던 개발은 타임존과 맞물려 스케줄링 하는 포인트가 굉장히 어려웠던 것 같다. 처음에 타임존에 대한 기획을 전달받은 바가 없다가 개발 되면서 타임존의 필요성을 역제안하는 등. 추가로 날짜 다루는 것도 넘 힘들었다...

그래도 막상 완료하고 결과를 보니 이리 뿌듯할 수 있을까 싶었다. 성취감 짱짱맨

 

게시판 개발하는 거야 뭐 아주 기본이다 보니 대 부분의 페이지 작업 들은 금방금방 진행한듯

 

화이트보드와 화상 전화하는 곳을 개발하는 게 좀 재밌었다.

우선 화상 전화의 경우 흔히 RTC를 직접 구현하는 예제들이 많이 나와있긴 한데, 이곳의 경우에는 기존에 이미 사용하고 있는 API 가 별도로 존재했고 그 API를 직접 사용하였고, 별도로 상태 관리나 커넥션이 좀 불안하여 로딩이 제대로 안되거나 하는 이슈가 있긴 했지만 문서가 잘 나와있어서 리-커넥션 해주거나, 웹 컴포넌트에 바인딩을 못할때는 직접 태그 자체를 만들어주니 해결되었다.

 

화이트보드의 경우에는 퇴사했던 곳에서 한창 화이트보드 같은 기능을 개발했었는데 운이 좋게도 비슷한 내용인 것 같아 외주를 수락했었다 분명 화이트보드 오류만 수정해드리면 된다고 하셨잖아요?

다만 기존의 화이트보드의 경우 기능들을 캔버스 API을 활용해 직접 구현되어 있는 형태이다 보니, 실시간 콜라보레이션을 위해 사용 가능한 오픈 소스를 찾아야 했다. 오픈 소스 몇가지를 오퍼 드린 후 추후 운영 시 추천드릴 제품과 실제 개발에 들어갈 제품에 대해 설명드리고 개발을 진행했다.

 

사용한 라이브러리는 fabricjs이다. 히스토리 관리 등 몇가지 이슈들이 있긴 하지만 직접 수정해서 배포한 경험도 있고 해서 전체적으로 사용하기 쉬운 해당 라이브러리를 선택했다.

 

실시간 콜라보레이션을 위해 소켓을 구성하고 다만 여러개의 화이트보드를 사용할 수 있다보니 브라우저가 많이 힘들어 했다. 탭 내에서 사용 가능한 메모리 사용량이 제한이 있는지 화이트 보드 자체를 컴포넌트 화하여 사용할려니까 문제가 생겼다. 그래서 그냥 아이프레임으로 로딩하여 사용했다. 너무 잘 된다.

 

기간이 짧다보니 전체적으로 테스트도 부족했고 코드의 퀄리티도 많이 떨어진 것 같아 그 부분들이 상당히 아쉬웠다.

코드 한 줄 한 줄 줄이는게 나의 낙이였는데

 

인프라 구성의 경우 인하우스 개발자로 근무하게 되면 내가 직접 인프라를 설정하거나 할 경험이 많이 부족했는데 전체적으로 해볼 기회가 생겨 좋았다. 백엔드 개발자로서 aws를 활용할 수 있는 부분들을 사용해봤달까

s3, 클라우드 프론트, 로드벨런서 설정, ec2 구성, 호스팅 관리, 및 aws 의 요소 구성 연결, aws certificate manager 이것도 다른 유명한 클라우드 플랫폼을 써볼 기회가 많이 없어서 저가형과 GCP를 주로 썻는데 aws 너무 편했다. openssl 크론으로 연장하던 시절로는 다시 안가리다.

 

이전에 도메인 관리하는 곳이 구글 도메인이라고 했었는데 구글 도메인이 자신들 사업을 다른곳에 팔았다며 관리하는 영역이 안나온다. 이때 미쳐버리는 줄 

시간 상 이 부분은 운영하시는 분들이 해주시기로 하고 도메인을 하나 더 구매해서 배포하였다.

 

디자인 시스템의 경우 디자이너가 만들어 준 내용들을 컴포넌트를 미리 만들어 놓고 사용했는데 전체적으로 디자인 시스템 뿐만 아니라 디자인 자체가 아예 바뀌는 상황들이 많이 생겨서 중간부터는 그냥 스타일드 컴포넌트 사용해서 변수 설정된 사이즈나 컬러, 폰트 등을 제외하곤 직접 퍼블리싱을 진행했다.

그 동안 scss, less, css-module 위주로만 사용하고 styled-component를 처음 써봤는데. 왜캐 편함..?

 

프론트엔드 영역은 기존에 리엑트를 사용하고 있었는데 이전부터 nextjs 사용 했어서 그냥 이거 사용했다.

다만 App router와 Page router가 나오다 보니 많은 부분 레퍼런스가 부족해서 next에서 의도한 방향대로 잘 썻는지는 잘 모르겠다.

 

프론트엔드의 배포 같은 경우 처음에 ec2에 정적 빌드해서 배포하려고 했는데 너무 번거로웠다. 웹서버 설치해 세팅해 api 요청 서빙해 머리가 너무 아팠다. 그래서 그냥 vercel에 배포했다. 와 너무 편하던데... 저장소에 배포 딸깍한번이면 배포가 되는데 왜 서버에는 이게 안도ㅓㅐ?

 

서버 배포의 경우도 쿠버네티스로 배포할까? 하다가 도커로 배포해야겠다 하고 설치하는데 서버 메모리가 부족한 상황이 발생했다. 물론 컴퓨팅을 비싼걸로 선택해서 배포하면 발생하지 않은 문제긴 했는데 외주사 대표님께서 비용절감을 외치셨기에 무료티어 받을 수 있는 컴퓨팅으로.. 선택했기에 발생한 문제였다.

또한 nestjs를 빌드하는 것 또한 인스턴스 내에서 진행할 때 메모리가 부족했다.

그래서 그냥 빌드 된 파일을 scp 로 인스턴스에 보내고 재실행 커맨드를 추가했다.

 

빌드는 어처피 저장소 액션이나 파이프라인을 통해 진행하니 scp 이미지만 추가해서ㅏ 전송하면 될 것 같았다.

그리고 잘 됐다. ㅇㅇ..

 

백엔드 컨셉은 repository pattern 에 기반을 두고 작업했고, 많은 부분 재활용 가능한 코드 퀄리티를 생각하고 생각한 패턴이였으나 아쉬움만이 많이 남았다.

 

소켓구성의 경우 nest의 게이트 웨이나 여러가지 구성요소를 제외하고도 소켓을 관리해주는 것도 굉장히 중요했는데 이 부분이 처음 개발해본 영역이다 보니 이러한 패턴들이나, 성격 이런부분들이 굉장히 재밌었고, 더 진행해보고 싶은 내용이였다.

 

다국어의 경우 jsonㅇ안에 값만 잘 채우고 시간만 많이 쏟으면 되는 부분이니 회고 할만한 건 없을 듯..

 

 

한 달반정도 같이 일했던 분들도 너무 고생많으셨고, 이걸 해낸 나도 너무 고생 많았다.