어떤 프로젝트에요?
잘 모르는 사람들과 같은 팀을 이루어 본 적, 모두들 있으시죠?
대학교 조별과제, 스터디, 교육 내 프로젝트 등.. 특히나 개발을 꿈꾸시는 분들은 이런 상황을 자주 접하셨을 거라 생각합니다.
혹시, 해당 상황이 엄청나게 어색하진 않으셨나요?
'무슨 말을 해야 하지? 어떤 표정을 지어야 하지? 모르겠다..' 같은 생각을 하셨던 적이 있으실 겁니다.
네이버 부스트캠프에서도 이런 과정을 매번 거쳤습니다.
2주에 한번씩 모르는 사람들과 팀을 맺었습니다.
30분 정도 서로 자기소개를 하는 등, 아이스 브레이킹을 위해 힘을 쏟았습니다.
하지만 짧은 시간 안에 친해지는 건 생각보다 어려웠습니다.
대부분의 팀은 '친해지기 위해' 금요일에 시간을 추가적으로 투자했습니다.
프로젝트 아이디어를 떠올릴 때 '짧은 시간 안에 친해질 수 있는 방법을 프로젝트에 녹여낼 수 있다면 좋겠다'는 고민을 했습니다.
정말 떠오르지 않더군요..
그렇다면 반대로, '우리는 어떤 과정을 거쳐 친해질 수 있었을까?'를 되돌아봤습니다.
'공감대'라는 키워드를 도출할 수 있었습니다.
- 같은 야구팀을 응원한다는 것을 알게 되었을 때
- 어제 본 드라마에 대해 감상을 나눌 때
- 같은 빵집을 다녀왔다는 것을 알게 되었을 때
우리는 말이 많아졌고, 급속도로 친해질 수 있었습니다.
이처럼, 동시에 여러명이 '공감대'를 손쉽게 나눌 수 있는 프로젝트를 만들 수 있도록 노력했습니다.
어떠한 과정을 거쳐 개발하였나요?
중점적으로 파고든 부분
Nest.js, Socket.IO
다수의 접속자가 프로젝트를 사용하는 경우, 각각의 그룹을 나눌 수 있는 '방'이 필요했습니다.
또한 실시간성을 보장할 수 있어야 했습니다.
이를 위해 '게이트웨이'로 실시간 통신에 대해 쉽게 관리할 수 있는 Nest.js를 선택하였고, 해당 커넥션 및 '방' 개념의 도입을 위해 Socket.IO를 도입했습니다.
Nest.js도, Socket.IO도 처음이었기에 학습하기 힘들었습니다.
특히, Java 진영과 달리 공식문서나 레퍼런스가 잘 정리되어 있지 않다는 느낌을 받았습니다.
따라서 오픈소스를 직접 뜯어보며 예외 throw 시 클라이언트 콜백으로 응답을 전달하는 법과 '방' 개념을 위해 도입한 Socket.IO의 Adapter가 어떠한 의도를 지니고 있는지 알아보고 정리하게 되었습니다.
오버 엔지니어링을 하지 말자, 문제의 의도를 살피자
저는 이전에 오버 엔지니어링을 했다가 대차게 실패한 적이 있습니다.
정확히는, '문제의 근본적인 원인이 무엇인가?'를 살펴보지 않고 '기술적인 내용'에만 집중했었습니다.
이번 프로젝트는 계속 운영해 볼 마음이 있었으며, 이를 위해 '의도'에 집중해보는 시간을 가져 보았습니다.
따라서 '굳이 이렇게 해결해야 하나?'라는 물음표를 계속 가져갔습니다.
덕분에 자연스러운 해결책을 여럿 찾을 수 있었지만, 말 그대로 '자연'스럽기에 '저희 수준에서 당연해 보이는 것들'로 이루어지게 되었습니다.
어떤 고민을 했고, 어떻게 해결했는지는 저도 명확히 짚긴 힘듭니다. 그때의 기억을 되살릴 수 없으니 말이죠.
하지만 위에 첨부한 블로그 글들처럼, '자연스러움을 위해 내부가 어떻게 동작하는지 파악해보려고 노력했구나'를 추상적으로나마 전달해 드릴 수 있을 것 같습니다.
실패한 부분
무중단 배포
커넥션이 계속 물려있는 상태에서 무중단 배포를 하는 건 생각보다 쉽지 않았습니다.
특히, PM2를 이용해 블루-그린 배포를 수행해보려 노력했으나 생각대로 돌아가지 않았습니다.
PM2가 내부적으로 어떻게 돌아가는지 Nest.js나 Socket.IO처럼 직접 확인했다면 좋았겠지만.. 아쉽게도 그럴 수 없었습니다.
또한, 만약 PM2가 정상 작동했다 하더라도 근본적인 '커넥션의 자연스러운 인스턴스 교체'를 위해서는 고려할 점이 매우 많다고 생각합니다.
- 커넥션은 그대로 두고, 송수신되는 데이터만 다른 인스턴스로 보낼 수 있나?
- 그레이스풀하게 워커를 종료하고자 할 때, 커넥션이 비정상적으로 오래 연결된다면 무용지물이지 않은가?
- 물리적인 커넥션을 잠깐 끊었다가 새로 연결시킨다면, 이는 무중단 배포라고 할 수 있을까? 또한, 기존 커넥션 정보들을 그대로 유지하기 위해선 어떤 방법이 필요할까?
애석하게도 해당 방법들에 대해 명확한 해결책을 찾지 못했습니다. 다만 Socket.IO의 RedisAdapter, ClustedRedisAdapter, RedisStreamAdapter 및 네트워크 관련 글들을 살펴보며 계속 고민 중입니다.
빠른 시일 내에 해당 정보들을 담은 글로 찾아뵐 수 있다면 좋겠습니다.
어떻게 배포했어요?
Ncloud
저는 AWS에 대해 아주 조금이나마 알고 있습니다. 서비스를 직접 배포해 본 경험이 있기 때문입니다.
하지만 AWS를 접할 때마다 정말 많이 헤멨던 게 기억납니다. UI는 언제나 바뀌어있고, 번역은 들쑥날쑥이며, '왜 이게 필요한가'라는 근본적인 물음을 해소하기 힘들었습니다.
하지만 Ncloud를 통해 많은 부분을 해소할 수 있었습니다.
한국어를 통한 명확한 설명, 알기 쉬운 UI, 친절한 Q&A를 통해 많은 정보를 획득할 수 있었습니다.
어떤 서비스들을 사용했나요?
Server를 통해 서버 인스턴스를 만들고, Object Storage를 통해 이미지 공유 시스템을 손쉽게 구축했습니다.
Public IP를 통해 고정 IP 주소를 할당받았습니다.
또한 Snapshot 기능을 사용하여 새 인스턴스 환경을 쉽게 구축할 수 있도록 했습니다.
Auto Scaling은 PM2를 활용한 싱글 인스턴스 내 무중단 배포도 실패했기에.. 아쉽게도 사용하지 못 했습니다. 추후 도입해 볼 예정입니다.
AWS의 Lambda와 같은 Cloud Functions도 키워드 통계 도출 시 적절한 사용처가 되지 않을까 합니다.
아쉬움은 없었나요?
단 한가지, '레퍼런스가 적다' 뿐이었습니다.
아무래도 AWS에 대한 글들이 많다 보니, '이런 문제가 생겼을 때 Ncloud에서는 어떻게 해결하지?'와 같은 이슈들이 있었습니다.
다만 기존 작성된, 혹은 새로 작성하는 Q&A를 통해 문제를 해결할 수 있을 것입니다.
아직 배포 쪽으로는 많은 지식이 없기에, 큰 문제를 마주할 일이 적었다고도 볼 수 있습니다.
하지만, 역으로 생각하면 '배포 관련 지식이 많지 않은데도 Ncloud를 사용했을 때 큰 이슈가 없었다'고도 말씀드릴 수 있겠네요.
사용 소감
예상과는 반대로, 쓰기 정말 편했습니다.
'이런 기능이 있지 않을까?' 하는 건 대부분 존재했습니다.
금액 계산기도 있어서 '대략 얼마가 나올 것인가'를 계산하기도 쉬웠습니다.
앞으로도 지갑 혹은 크레딧에 여유가 있는 한은, Ncloud를 많이 애용하게 될 것 같다는 생각이 듭니다.
어떤 아키텍처로 구성하셨나요?
보시다시피, 엄청나게 간단한 형태로 배포하고 있습니다.
'오버 엔지니어링을 하지 말자'는 시선에서 보았을 때, DB같은 추가적인 환경이 필요하지 않았습니다.
인메모리 데이터로 해당 정보들을 구성하고 있습니다.
다만.. 이렇게 구현하니까 확장성이 떨어지더라구요.
따라서 다음 목표는 다음과 같습니다.
이미 내부적으로 아키텍처 구축에는 문제가 없음을 확인했으나, 무중단 배포가 실패하면서 옮겨가지는 못 했습니다.
PM2 대신 다른 기술을 사용해볼까 고민 중입니다. 팀원들과 이야기를 더 나눠봐야겠지만요.
프로젝트 피드백은 어땠어요?
우선 '누구나 제약 없이 쓸 수 있는 프로젝트'라는 점에서 좋은 평가를 받았습니다.
또한 '사용하는 과정이 재미있었다'는 평도 들을 수 있었습니다.
하지만, 동시에 '버그가 많다'는 피드백도 들을 수 있었습니다.
버그가 아님에도, UX적으로 버그로 느껴지는 부분이 있었습니다.
물론 실제 버그도 있었구요..
앞으로 버그를 많이 잡아보려 합니다.
앞으로 어떻게 할 것인가
앞서 이야기 드린 부분들을 총 정리해보자면
- 무중단 배포
- 아키텍처 변경
- 버그 픽스
등이 있겠네요.
누군가에게는 부족한 서비스겠지만, 계속해서 발전시켜 나아가보고자 합니다.
많은 응원과 관심 부탁드립니다.
