정글일지 42

날짜

2023년 6월 1일 목요일

계획

결과

생각보다 아이디어 회의가 길어졌다. 대신 그만큼 모두가 집중하여 좋은 아이디어들이 많이 나왔다.
기획 관점보다 핵심 기능을 기준으로 생각했더니 결과가 훨씬 좋았다. 위치 기반, 대용량 데이터 처리, 메타버스, AR, 영상 관련, 동시 편집(동시성) 등등..
스프링, 알고리즘 문제 풀기 등 개인 공부는 하지 못했다.
Git repo 뿐만 아니라 Notion도 사용하여 훨씬 다양하고 편하게 기록을 남길 수 있게 되었다.

오늘 배운 내용

동시 편집 알고리즘

원격 문서 편집의 과정을 간략하게 살펴보자. JUNGLE 이라는 글자가 있을 때, BUNGLE로 바꾸고 싶다면? 우선 맨 앞에 ‘B’를 써서 BJUNGLE를 만들고 J라는 두번째 문자를 지워 BUNGLE을 완성하는 단계로 나누어 볼 수 있다. 이 과정이 순서에 맞게 차례대로 발생하면 문제가 될 것이 없다.

만약 여러 사람이 한 문서를 수정하는 상황에서는? 위의 두 과정이 두 사람에게 나누어져 진행됐다고 해보자. 김 과장이 B를 입력하고 박 대리가 지운다면? 그리고 이 과정이 두 유저사이에 있는 Relay Server를 통해 각자에게 전달된다.

김 과장 입장에선 B를 입력하고 서버를 통해 박 대리가 입력한 ‘지우는’ 지시가 들어왔다. 즉 B가 입력되자마자 지워졌다. 결과적으로 JUNGLE이 남아있는 상태가 된다. 박 대리는? 우선 지웠기에 UNGLE가 되버렸다. 이 후 김과장이 입력한 B가 서버를 통해 전달되어서 BUNGLE이 완성되었다. 위와 같은 과정을 두 사람이 나누어서 했더니 한 문서를 수정하는데 다른 결과물을 가지게 되버린다. 문제는 이렇게 발생한다!

이유가 뭘까? 쓰고 지우는 동작, 오퍼레이션은 ‘적용 이전의 문서’를 대상으로 한다. 여러 유저가 입력한 오퍼레이션을 변화 없이 그대로 전달하기 때문에 발생하는 문제이다. 모두가 공통된 문서에서 적용하는게 아니라, 각자가 가진 ‘직전의’ 상태를 기준으로 오퍼레이션을 수행하기 때문이라고 볼 수 있다.

OT방식

Operational Transformation 방식이다. 가운데 있는 릴레이 서버가 오퍼레이션을 그대로 전달하지 않고, 시간 상의 순서를 고려하고 스트림의 변화도 고려하여 전달하는 것이다. 선순위로 수행된 오퍼레이션에 따라 후순위 오퍼레이션은 영향을 받게 된다. 그리고 이 방식은 중앙집중적인 처리를 특징으로 한다. 우리가 자주 쓰는 Google Docs도 이 방식을 채택했다.

대신 알겠지만, 반응성이 안좋다.. 한박자 느린듯한 그 특유의 답답함.. 또한 중앙으로 모이기 때문에 증가하는 트래픽, 서버 부하도 문제가 된다.

CRDT방식

Conflict-Free_Replicated Data Types 방식이다. 위에서 기존에 있던 JUNGLE 문자열에서 각각 알파벳이 고유 ID를 부여한다. ‘두번째’ 문자를 지우라는 오퍼레이션 대신 ‘94라는 ID를 가진 문자’를 지우라고 한다면? 한 유저에 의해 지워졌을 때 다른 유저가 입력한 지우는 오퍼레이션은 취소된다. 그 ID의 문자열은 더 이상 찾을 수 없기 때문이다! 또한 중앙에서 처리해줄 필요도 없다. 두 유저 모두 ID를 갖고 있으니 그저 유저끼리 오퍼레이션을 할 타겟의 아이디만 주고받으면 된다.

이로 인해, 많은 메모리가 필요하게 된다.. 수 많은 문자열의 ID를 가지고 있으려면 당연히 필요하다. 또한 두 유저가 Peer-to-Peer로 통신한다면? 최근 보안의 중요성으로 Peer간 접속을 막는 추세이다. 그럼 이 방식은 쓸 수 없게 된다..

결론

두 방법 모두 장단점이 있지만, 최근 CRDT를 많이 쓰는 추세인 것 같다. 또한 다양한 알고리즘 기법들도 나오고 있다. Logoot, LSEQ, RGA, Treedoc, WOOT, Astrong 등이 있다. 정글 사관학교의 협력사인 채널톡의 블로그에서도 나온 주제인 만큼 공부하여 구현해 볼만한 기술이다!

메타버스의 최근 흐름

아이디어 구현 가능성에 대한 조사를 위해 2D 메타버스에 관한 오픈소스나 툴 등을 찾아보았다. 생각과 달리 3D 뿐이였고, 유니티를 사용하는 경우가 많았다. 메타버스의 체감을 게더타운으로 한 입장에서 “2D가 훨씬 기술적으로 쉽지 않나? 이렇게 하나도 없을 수 있나?”라는 생각이 절로 들었다. 읽은 기사에서 말한 논지는 다음과 같다. 메타버스가 현실의 연장으로 생각하는 만큼 그래픽 또한 현실적으로 구현되도록 발전해 왔다. VR기기를 통해 많이 접속하고, ‘현실성’을 추구하는 만큼 3D로 많이 만들었는데 기능에 충실하고 2D 도트 그래픽으로 만든 게더타운이 대박이 났다고 한다. 오히려 2D라서 가벼운 서비스인만큼 접근성이 좋아 오히려 많이 사용하게 되었다고 한다. 최신 기술, 고도의 기술만이 정도는 아닐 수 있다는 것을 배웠다.

회고

드디어 나만의 무기 만들기 프로젝트가 시작되었고, 팀끼리 만나 첫 회의를 가졌다. 최소한의 규칙을 정했다. 예전부터 같이 하고자 했던 친구들과 조금씩 생각해놨던 아이디어를 새롭게 들어온 팀원들과 공유했다. 이를 바탕으로, 혹은 영감으로 삼아 새로운 아이디어와 부족한 내용이 추가되었다. 결론적으로, 기존의 아이디어가 더 탄탄해졌고 그럴듯해졌다. ‘창의성’이나 ‘사업성’에 너무 몰두했던 우리에게 취업을 위한 포트폴리오인 만큼 기술적인 면에서 여러 생각들을 말해준 덕분이다. 다음 주 화요일 초안 발표로 정한 두 주제에 대해 모두 기대하는 중이고, 만족하는 중이다.

아이디어가 나만무에 적합한 것인지 조사하는 과정에서 어려웠다. 첫 프로젝트라 감이 안왔다. 오픈 소스는 쓰면 안되는 건가? 어느 정도가 어려운건가? 유행하는 기술을 따라가야 하는건가? 무엇을 찾아봐야 할지 감이 안왔다. ‘지금 당장 구현해야 한다면 볼만한 자료들을 찾아봐’라는 친구의 조언이 도움이 됐다. 개인프로젝트로 했던 사람들의 블로그도 찾아보고, 유튜브에서 구현하는 영상도 찾아보고 많은 링크를 모았다. 또한 그 기능에서 대표적으로 어떤 방법들이 있고, 장단점이 무엇인지, 실제 서비스하는 곳에서는 어떤 방법을 사용하는지 등을 찾아 팀원들끼리 회의를 하였다. 4가지 주제의 타당성에 대해 각각 주제마다 2~3사람이 조사하였고 여러 조사를 바탕으로 두 아이디어를 택했다. 첫 날이지만 바람직한 방향으로 출발한 것 같아 기분이 좋다. 오늘 초안 발표에 대해 개략적으로 작성하였고, 아키텍쳐 등은 내일부터 자세히 조사해서 준비할 예정이다.

리더긴 하지만 개발 능력도 없고, 경험도 없고, 지식도 없고 그냥 목소리만 커서 여러모로 걱정이 많았다. 하지만 각자가 맡은 역할이 너무 조화로워서 신기하다. 누구는 기술 스택에 대해 생각하고, 누구는 토의에 대해 기록하고, 누구는 프로젝트 진행의 관점에서 생각하고, 누구는 기술과 아이디어가 어울리는지, 말이 되는지 확인하였다. 서로 협의하지 않았지만 자연스럽게 흘러가는 이 협동이 참 좋았다.

가급적 매일 매일 TIL을 개인적으로 적으려고 한다. 첫 프로젝트인 만큼 최대한 기록을 많이 남기고 싶다. 그만큼 많이 배우고, 많이 생각하게 될 것이라고 생각한다.

프로젝트 시작하기

나만무 1일차 TIL