정신없이 살던 중에 이메일이 왔다.

잉?

16KB 페이지 크기 요구사항을 해결하려고 React Native 버전을 0.79.2로 올려놨기 때문에 해당 이슈는 해결되었다.. 생각하고 있었는데 뜬금없이 이런 이메일이 왔다.

이상하다... 내 기억상으로 0.77 버전에 이미 해당 이슈를 해결한 걸로 기억하고 있었다. 공식 블로그 글

원인 분석 하기

바로 원인 분석을 위해 구글 플레이 콘솔을 켜고 확인해 봤다.

webp... 이미지 컴포넌트에 무슨 문제가 있나..?

고민을 해보니 과거에 Image 컴포넌트에서 webp 혹은 gif 같은 형식을 쓰려면 build.gradle에 어떤 라이브러리를 추가해야 한다고 해서 추가했던 기억이 생각났다.

그래서 "아 버전이 뭔가 오래됐나 보다 생각하고 공식 Docs로 들어가서 버전 체크해 봐야지~" 하고 들어가서 이미지 컴포넌트를 확인했다.

공식 문서를 보니 Fresco 3.2.0 라이브러리를 추가해야 한다.

그래서 내 버전을 확인해 봤는데...

야무지게 구버전을 사용하고 있었다.

세상에 3.1.3 난 대체 얼마나 오래된 버전을 사용하고 있었는가... 하면서 부랴부랴 3.2.0으로 변경했다.

Fresco... 정체가 뭐냐...

근데 문득 이 Fresco라는 라이브러리가 어떤 걸 위해 만들어진 라이브러리인가 궁금해서 공식 Github에 들어가 보았다.

Fresco는 안드로이드 앱에 이미지를 띄우기 위한 강력한 시스템이라고 한다. 요약하자면 Fresco를 쓰면 개발자가 OutOfMemoryError 겪는 일을 줄여줄 수 있다고 한다. (작동 원리 적으면 길어질 것 같아서 생략..)

사실 나는 첫 페이지 상단을 보자마자 당황했었다. 왜 당황했는지 이 글을 읽는 여러분도 찾았을 거라 믿는다.

왜냐하면...

Release 버전이 3.6.0이었기 때문이다.

오...? 뭐지...?

당장 릴리즈 내용을 읽어보았다

AVIF 포맷을 지원한다... 디스크 캐시 읽기 시간 초과 지원... . . . 쭉 읽어보다가 3.4.0 버전에서 난 스크롤을 멈춰버렸다.

3.4.0 버전부터 Android 15를 위한 16KB 페이지 크기가 지원된다는 것이다.

그렇다는 건 3.2.0 버전은 여전히 16KB 페이지 크기를 지원하지 않는다는 의미다.

이게 왜 문제일까?

일단 공식 문서는 React Native로 개발하는 개발자도 보지만 React Native를 처음 시작하는 사람들이 가장 먼저 보는 홈페이지다

공식 문서에 있는 컴포넌트들을 보면서 어떻게 사용할 수 있는지 공부하는데 저런 식으로 오래된 버전의 라이브러리 버전을 유지하면 RN으로 프로젝트를 만드는 사람들은 전부 잠재적으로 16KB 페이지 크기 이슈를 겪을 수 있다는 것이다.

그리고 꽤 충격적인 사실이 있는데... 25년 11월 1일부터 16KB 메모리 페이지 크기를 지원하지 않으면 업데이트를 출시할 수 없게 된다. 이건 치명적이라고 생각한다.

아 Expo 유저는 괜찮다.

아마 이건 RN-CLI를 쓰는 유저만 해당될 것 같다.

??? : 나는 webp나 gif 안 쓸 거라서 Fresco 필요 없는데요?

Fresco를 안 쓴다면 당연히 해당 이슈에서 벗어날 수 있다. 하지만 요즘 WebP는 이미지 압축률도 좋고 애니메이션도 지원하기 때문에 여러 플랫폼에서 사용하고 있는 이미지 포맷이다.

결국 나는 해당 문제를 직접 PR로 올려보기로 했다.

문제 해결하기

어떤 걸 할 땐 항상 이유가 있어야 한다. 왜 이렇게 했는지에 대해 설명 하기 위해 위에서 찾은 내용과 React Native의 깃허브를 좀 찾아보았다.

Release 내역을 찾아보니 0.78부터 이미 Fresco의 버전을 3.6.0으로 대응하고 있었다.

엇 그러면 Fresco는 3.4.0, RN은 0.77 버전부터 16KB 페이지 사이즈를 대응했으니 0.77 버전은 3.4.0으로 해둬야겠다는 생각이 들었다.

왜냐하면 0.77에서 Fresco 3.5.0 혹은 3.6.0 버전으로 하면 혹시 모를 이유로 인해 프로젝트에서 각종 오류가 나오지 않을까 걱정했다..

좀 더 정보를 찾아봤는데 0.77의 Release 내역에서 커밋한 내용을 보니 0.77에서 3.4.0을 대응하는 내용을 찾을 수 있었다.

오케이! 테스트를 해보자

테스트하기

이제 내 논리가 제대로 적용되는지 확인해 볼 시간이었다. 그렇게 대단한 건 아니고 내 프로젝트에 Fresco 버전을 바꾸는 것이었다. 현재 나는 0.79.2를 사용하고 있었기 때문에 가장 최신 버전인 3.6.0을 사용해 보았다.

빌드는 잘되었고 난 이대로 PR을 작성하기로 했다.

PR 작성하기

사실 오픈소스에 PR을 작성하는 건 처음이 아니다. 예전에 Deprecated 된 Repo에 PR을 올렸지만, 당연히 관리를 안 하고 있어 요청이 받아들여지진 못했었다.

하지만 당시에 반응이 좋았다.. 그래서 그런가 더 아쉬웠다...

망한 PR 구경하러 가기

이번에도 GPT의 도움을 받아 PR을 작성하였다.

해당 PR 구경하러 가기

아까 찾았던 Release 내용을 링크를 달아가며 왜 0.77에는 3.4.0을 해야 하는지 간략하게 적어두었다.

중간에 CLA sign을 해야 한다는 메타의 피드백을 받아 다시 PR을 작성했었다.

결과는?

고맙다는 인사와 함께

다행스럽게도 Merge가 되었다!! React Native Image Component 3.6.0으로 버전이 바뀐 모습을 볼 수 있다..! 이런 간단한 거라도 오픈소스에 기여해서 기분이 참 뿌듯했다..😁

느낀 점

처음으로 컨트리뷰터가 됐는데 나름 치명적인 부분을 기여한 것 같아서 기분이 좋았고 내가 겪는 문제에서 시작되어서 이렇게 오픈소스 기여까지 할 줄은 몰랐다.

사실...

예제 코드 아래쪽에 보면 제때 업데이트되지 않을 수 있다고 명시되어있다.. 하핫 (머쓱) 그래도 처음 하는 사람들한테는 도움이 되지않았을까..?

다음에는 꼭 React Native CLI나 FastAPI 같은 내가 자주 쓰는 곳에 PR을 올려보고 싶다...

시작하기 전에

겜린더에는 사용자가 출시 예정인 게임을 달력에 등록하여 출시 당일 알림을 주는 기능이 있습니다. 저는 이 기능을 구현하기 위해 Firebase에서 Topic 이란 기능을 활용했는데요

Firebase Cloud Messaging - Topic

Topic은 주제 별로 알림을 전송할 클라이언트를 분류하여 효율적으로 여러 기기에 알림을 전송할 수 있는 기능입니다. 마치 pub / sub 구조와 비슷하다고 생각이 드네요

문제

초기 구조

어떤 것을 Topic으로 잡아야 할지 고민을 한 결과 게임 정보마다 있는 ID로 주제를 잡으면 될 것이라고 판단하였습니다.

그래서 알림 구조를 만들어보았는데요 과정은 파란색 → 회색 → 빨간색 순서로 봐주시면 됩니다.

예상 결과물에 보면 알 수 있듯이 2024년 12월 8일에 출시하는 게임 4가지가 각각 알림이 나오는 걸 확인할 수 있습니다.

이 방식의 장단점이 있었는데요

장점

• 개발하기 편하다...
• DB를 사용할 필요가 없다.

단점

• 각각 알림이 오기 때문에 중복되는 알림으로 인한 알림 폭탄이 예상된다.

알림 폭탄?

예상 결과물을 보게 되면 겉보기엔 문제가 없어 보입니다.

하지만 만약 게임을 10개 이상 달력에 등록하게 되면

3~4개는 괜찮아도 10개가 한 번에 온다....? 이거 거의 알림 폭탄인데..?

라는 생각과 함께 개선해야한다는 결론에 도달하게 되었습니다.

해결 방안

문제를 해결하기 위해 저는 사용자가 달력에 등록한 정보를 DB에서 불러와 하나의 알림으로 묶어서 보내야겠다는 판단을 하였습니다.

일단 Topic의 기준을 유저 ID로 변경하였고 이를 기반으로 알림 구조를 다시 만들어보았습니다.

플로우를 번호 순서대로 정리를 해봤는데요

순서 정리

1. 로그인

달력에 등록하기 위해선 사용자는 로그인을 해야 합니다.

2. 로그인 성공 시 Access Token 발급

로그인 성공을 하면 Access Token을 발급받는데요 그곳에 유저 id가 존재합니다. 예시로 "id":"00000000"로 하겠습니다.

3. 유저 ID로 FCM Topic 구독

로그인 성공과 동시에 id를 이용해 FCM Topic을 구독하게 됩니다.

4. 게임을 자유롭게 탐색

말 그대로 게임을 자유롭게 탐색을 합니다.

5. 탐색 중 맘에 드는 게임을 달력에 등록 시 MongoDB와 Redis에 저장

게임이 맘에 들었다면 Redis는 HASH 타입으로 저장, MongoDB에는 게임 id가 저장이 됩니다.

Redis에 저장되는 데이터를 활용하기 때문에 Redis를 중점적으로 보자면 날짜 - 유저 ID - 게임1, 게임2 이런식으로 저장이 되는데요

이를 기반으로 실제 결과물을 보게 되면 아래와 같은 이미지가 나오게 됩니다.

날짜와 유저 ID를 기반으로 HASH 타입으로 저장이 되어있고 유저 ID 속에는 유저가 저장한 게임들이 저장됩니다.

6. BOT이 실행되는 날짜 기준으로 게임을 예약한 유저 ID 불러오기

오늘 날짜에 맞춰 달력에 게임을 등록한 유저 ID를 불러옵니다.

7. 유저 ID 별 게임 목록을 하나의 알림으로 그룹화

게임 목록을 불러오고 message_template에 맞게 메시지를 그룹화 시킵니다.

8. 유저 ID Topic 별로 각각 전부 전송

여러 개의 출시 알림을 하나의 알림으로 모아서 전송할 수 있게 됩니다.

개선점

• 알림 폭탄을 줄일 수 있다.

• 유저 ID 기반으로 Topic을 구독하였기 때문에 다중 로그인에도 동일한 알림을 전송할 수 있게 되었습니다.

  이전처럼 게임 id를 기반으로 구독하게 되면 여러 기기에 같은 계정으로 로그인 하더라도 A 기기는 전부 알림이 오지만 추후 B 기기에 같은 계정으로 로그인을 하게 되었을 경우 알림이 오지 않아 동일한 사용자 경험을 제공할 수 없게 됩니다.

• MongoDB와 Redis의 역할을 나눠 I/O를 분산하여 MongoDB의 부담을 줄일 수 있었습니다.

  사실 이런 작업은 Redis 없이도 가능합니다. MongoDB Query를 작성해 분류해서 불러온 후 똑같이 그룹화 시켜 알림을 전송하면 되는데요

  하지만 그렇게 하면 쿼리 작업으로 인한 연산이 발생해 안 그래도 느린 자체 서버에 부담을 주기 싫었습니다.

  구조적으로 복잡한 데이터가 아니라고 생각했기 때문에 key-value 스토리지인 Redis를 사용하는 것이 좋다고 판단하였습니다.

요즘 알림 그룹화 시켜주는데 사용하지 않은 이유

요즘 iOS나 Android는 알림을 그룹화 시켜주는 기능이 존재합니다. 근데 이걸 사용하지 않은 이유는 관리하기가 더 힘들 것 같다는 생각이 들었습니다.

안드로이드의 경우 Channel_id로 여러 유형의 알림을 분류하고 그룹화 시켜주는데요. 저는 이미 Topic으로 그 역할을 하고 있다고 생각해 굳이 사용할 필요성을 느끼지 못했습니다.

그래서 channel_id를 하나만 사용하고 있습니다.

그리고 그룹화 시켜줘도 알림은 계속 울린 후에 그룹화가 되기 때문에 저는 알림 1번으로 오늘 어떤 게임이 출시하는지 유저에게 알려주고 싶었습니다.

나는 Github Actions를 쓸 줄 몰라요! 라고 한다면...

라즈베리파이 같은 간단한 보드사셔서 우분투 설치하고 환경 구성하신 후 Crontab 같은 걸로 스케줄링하면 좋습니다.

사실 Github Actions로 하는 것보다 더 나을 수도... 저도 사실 지금 운영하고 있는 서버 PC에서 crontab을 설정해 운영할 고민도 했지만 학습 목적으로 Github Actions를 이용했습니다.

마치며

겜린더 프로젝트를 하면서 제한된 하드웨어 성능에 최대한 뽕을 뽑아보려고 노력하고 있는데요... 제 스스로 판단하기엔 나름 타당한 근거로 이번 알림 시스템을 잘 개선했다고 생각합니다.

알림 시스템은 여전히 잘 동작하고 있고 앞으로도 안정적으로 운영하려고 최대한 노력해 보려 합니다.

혹시 궁금하신 점이 있다면 언제든 댓글 남겨주세요 열심히 답글 올리겠습니다.

긴 글 읽어주셔서 감사합니다. 🙇‍

게임이 언제 출시하는지 사이트 들어가고 유튜브로 일일이 찾으셨나요? 겜린더로 한 번에 찾고 달력에 저장하세요!

📋 스팀, 플레이스테이션, 엑스박스, 닌텐도 스위치의 출시 예정 게임을 한눈에 보세요!

📆 출시 예정 게임을 캘린더에 등록할 수 있어요!

🔔 매일 아침마다 오늘 어떤 게임이 출시되었는지 알려줘요!

👾 만약 내가 인디게임 개발자라면 겜린더에 무료로 게임을 등록할 수 있어요! (모바일 게임도 가능해요)

구글 플레이

앱 스토어

Github Repo 모음 겜린더 백엔드 : 링크 겜린더 게임 수집 봇 : 링크 겜린더 게임 출시 알림 자동화 : 링크

관련 글 (수시로 업데이트됩니다) 여러 개의 알림을 하나로 묶어서 보내기 - 2024-12-27

개발하면서 어려웠던 부분이나 기술적인 부분은 분량이 많을 것 같아 이번 글에선 간략하게 요약했습니다.

리뉴얼

겜린더가 드디어 다시 출시되었습니다. 겜린더 2.0.0 개발 후기를 작성한 지 벌써 3년이 지났네요

3년 전의 나와 지금 나의 차이점을 한줄로 설명하자면:

이제야 조금은 개발자다워진 것 같습니다.

하지만 여전히 제 자신의 부족함을 다시 알 수 있었던 프로젝트였습니다.

포기하기엔 너무 멀리 와버린 프로젝트

"3년이나 걸릴 이유가 있나?"라고 생각하셨다면, 맞는 말입니다. 이 프로젝트가 3년이나 걸릴 일은 죽어도 아니었죠.

작년에는 아예 집중을 하지 못했었습니다. 번아웃이 왔었거든요... 3년이지만 실질적인 개발 기간은 1년 되는 것 같네요...

사실, 겜린더는 출시 후에 그만두려던 프로젝트였습니다. 다른 사이드 프로젝트도 시도해보고 싶었지만, 겜린더는 계속 제 머릿속에서 떠나질 않았습니다.

그리고 솔직히, 저렇게 어정쩡한 앱을 출시하고 나니 스스로도 부끄러웠습니다. 어디 가서 내가 개발했다고 말하기조차 어려울 것 같았죠.

마지막으로, 누군가에게 정말 도움이 되는 제대로 된 서비스를 만들어보고 싶었습니다.

슬로건 변경

겜린더의 초기 슬로건은 "달력으로 알아보는 게임 정보"였습니다.

즉, "어떤 게임이 출시하는지 달력을 통해 알아보고, 출시 당일 알림을 받아보자!"를 목표로 했습니다.

하지만 제가 구현하고 싶었던 본질적인 가치를 더 잘 담아내고 싶었고, 친구의 피드백도 큰 도움이 되었습니다. 그 결과, 슬로건을 "나만의 게임 캘린더"로 바꾸게 되었습니다.

슬로건 변경했던 상세한 이야기

디자인은 정말 어렵다

겜린더는 정말 많은 디자인 변천사를 겪었습니다.

자세한 내용은 겜린더 프론트엔드 제작기 1에서 확인하실 수 있습니다.

하지만 기존 디자인은 슬로건 변경과 함께 대폭 수정되었습니다.

항상 겜린더의 UI/UX에 피드백을 주던 친구가 이번에는 직접 UI를 리디자인해 주었죠.

덕분에 UX가 크게 개선되었고, 더 간결하고 깔끔한 UI를 완성할 수 있었습니다.

사실 개발이 지연된 가장 큰 이유 중 하나가 UI/UX 디자인이었습니다.

하지만 친구가 도와준 이후로는 디자인 걱정을 덜고 개발에만 집중할 수 있었습니다. 그 결과, 개발이 훨씬 순탄하게 진행되었죠.

친구가 디자인을 완성해 준 덕분에, 저는 이를 기반으로 API 명세서를 작성하고 본격적으로 개발에만 몰두할 수 있었습니다.

이 글을 빌려 친구에게 다시 감사하다는 말 전합니다.

느낀점

이번에는 정말 제대로 된 앱을 만들고 싶다는 마음으로, 설계부터 더 열심히 고민하고 작업했습니다.

아직 부족한 점이 많지만, 본질적인 부분을 안정적으로 구현해낼 수 있어서 정말 기뻤습니다.

삽질했던 부분들은 하나씩 정리하며, 따로 글로 남길 예정입니다.

겜린더는 여기서 끝이 아니라 이제 시작입니다. 본질적인 기능을 구현한 지금부터가 진짜라고 생각하며, 게이머가 애용하는 앱으로 거듭나기 위해 최선을 다해볼 생각입니다.

지금까지 받은 수많은 피드백을 바탕으로 새로운 기능을 정리했고, 그 기능들을 단순히 추가하는 것에 그치지 않고, UI/UX에 어떻게 자연스럽게 녹여낼지 고민해야 할 것 같습니다.

서비스 리뷰

개요

개발 과정에서 중점적으로 고려한 주요 포인트는 다음과 같습니다:

1. 출시 예정 게임의 수 부족 문제 해결 → 이용자가 더 다양한 게임 정보를 확인할 수 있도록 개선

2. 회원가입 및 로그인 기능 구현 → 사용자 편의성과 보안을 모두 고려

3. 푸시 알림(FCM)의 재설계 → 알림 폭탄을 방지하기 위한 체계적인 설계

4. 페이징(Pagination) 구현 → 자유로운 게임 탐색 경험 제공과 함께 서버 부하 최소화

5. VPN을 활용한 보안 강화 → 자체 서버 운영 환경에서 데이터를 안전하게 보호

사용한 스택

기술 스택

Front-End

• React Native
• Axios
• React Query

Back-End

• Docker
• Nginx
• FastAPI
• MongoDB
• Redis
• Firebase Cloud Message(FCM)

게임 수집 봇

• Selenium
• MariaDB
• Pandas

자동화

• Github Action

프로젝트 관리

• Notion
• Figma

실제 서비스 화면

Front-End 주요 기능

1. 자유로운 게임 탐색 및 제스쳐를 이용한 빠른 달력 등록

페이징을 통해 데이터 로딩을 최적화했습니다. React Native에서는 FlatList보다 성능이 뛰어난 FlashList 라이브러리를 사용했습니다. 스크롤 시 성능 차이가 명확히 드러나 만족스러웠습니다.

2. 로그인/회원가입

회원 가입 절차를 직관적으로 만들기 위해 UX에 집중했습니다. 상단의 진행 바를 통해 단계별로 진행 상황을 쉽게 확인할 수 있도록 설계했습니다.

또한, 가입 단계별로 필요한 UI를 컴포넌트화하여 효율적으로 재사용할 수 있게 구성했습니다.

3. 설정페이지

4. 푸시 알림 받기

Back-End

백엔드 개발 과정에서 여러 문제를 만나며 많은 것을 배울 수 있었습니다. 각 기능별로 어떤 문제를 겪었고, 어떻게 해결했는지를 정리한 글을 차근차근 작성해 나갈 예정입니다.

이 글에선 간략하게 설명만 하고 마치겠습니다.

아래 이미지는 전체적인 구상도입니다.

JWT를 이용한 로그인

Redis를 활용한 효율적인 JWT 로그인 구현

1. 로그인 프로세스

• 사용자가 로그인 시 Access Token과 Refresh Token이 발급됩니다. Refresh Token을 이용해 Access Token을 재발급받을 경우, Refresh Token도 새로 생성하여 보안을 강화합니다.

2. 멀티 로그인 관리

• 한 계정으로 여러 기기에서 로그인할 수 있도록, 각 기기에 UUID를 생성하여 구분. Redis에 계정ID:UUID 형태로 Refresh Token을 저장하여 기기별로 독립적으로 관리합니다.

3. Redis 사용 이유

• Expire 기능: Refresh Token의 만료 시간을 Redis에서 자동으로 관리하여 유지보수 편리. 기존 겜린더에서 Redis를 사용하고 있었기에 자연스럽게 통합. 빠른 읽기/쓰기 성능으로 다중 기기 로그인 시 효율적인 관리 가능.

4. 구현 결과

• 보안성을 강화하면서도 다중 기기 지원이 가능해졌으며, Redis를 통해 Token 관리의 복잡성을 줄이고 성능을 최적화할 수 있었습니다.

푸시 알림 (FCM)

Firebase Cloud Messaging(FCM)을 이용해 게임 출시 알림을 제공합니다. 게임 출시 알림은 Github Actions로 매일 오전 9시에 자동으로 실행되는데요 Github-Hosted runners를 이용하기 때문에 좀 느리긴 하지만 오류 없이 정상적으로 작동 중이라 만족하고 있습니다.

특히 알림 폭탄 문제를 해결하기 위해 설계를 최적화하고 사용자 경험을 개선했습니다.

아래 이미지는 당시 어떻게 구현할지 구상했던 이미지입니다.

2024-12-27 업데이트 푸시 알림 관련해서 개선한 글을 작성하였습니다. 자세한 내용은 하단 글을 통해 확인해주시면 감사하겠습니다. 여러 개의 알림을 하나로 묶어서 보내기

배포 자동화

배포 자동화는 그냥 큰 리소스를 쓰고 싶지 않아 간단하게 CI/CD 파이프라인을 만들어 보았습니다. Github Actions를 사용하여 코드가 푸시될 때마다 자동으로 빌드하고 배포하는 방식입니다.

VPN을 이용한 보안 강화

개인 서버, 어떻게 안전하게 운영할까?

겜린더는 현재 개인 서버에서 운영되고 있습니다. 개인 서버는 외부 공격에 취약하기 때문에, 이를 보완하기 위해 VPN을 적극적으로 활용했습니다.

데이터베이스, 외부에서 막아야 안전하다

MongoDB와 Redis 같은 중요한 데이터베이스는 외부에서의 직접 연결을 완전히 차단했습니다. 만약 데이터베이스에 직접 접근해야 할 일이 있다면, VPN을 통해서만 접속할 수 있도록 설정했습니다.

Swagger 문서도 아무나 못 보게

FastAPI의 Swagger 문서 페이지는 기본적으로 개발 편의를 위해 제공되지만, 이 역시 VPN에 연결된 사용자만 접근 가능하도록 제한했습니다. 추가로, IP Whitelist를 만들어 특정 IP만 접속할 수 있도록 보안을 한층 더 강화했습니다.

보안은 선택이 아닌 필수... 안 그럼 큰일 난다...

VPN과 IP Whitelist 덕분에 서버 접근 경로를 최소화할 수 있었고, 외부 위협으로부터 서버를 한층 더 안전하게 보호할 수 있었습니다. 작은 서버라도 보안에 신경 쓴다면, 예상치 못한 문제를 미리 방지할 수 있습니다!

게임 수집 봇

게임 데이터 수집과 관련해 이전에 작성한 두 가지 글이 있습니다:

• 약 2300개의 게임을 수집해 DB에 저장하기
• 게임 데이터 수집 봇 파이프라인 개선하기

마치며

아쉬웠던 점

• 아직 코드를 완벽하게 작성하지 못한 점이 아쉬웠습니다.
• 백엔드에서 응답을 통일한 뒤, 프론트엔드에서 코드 재사용성을 높이려 했으나, 급하게 개발하다 보니 이를 구현하지 못한 점이 아쉬웠습니다.
• 올해 안에 출시하고자 급하게 진행하다 보니, 출시 초기에는 버그가 많았고, 넣지 못한 기능도 있었습니다.
• 생각보다 구현한 기능에 비해 보이는 부분이 적어 아쉬움이 남습니다. 😂
• 기초 지식은 여전히 부족하고 더 공부해야겠다는 마음가짐을 가질 수 있게 되었습니다.

만족했던 점

혼자서 서비스를 만들어본 경험이 정말 값졌습니다. 스스로 실력에 대한 의심이 많았지만, 이번 경험을 통해 많은 의문이 해결되었고, 단순히 코드를 작성하는 사람이 아니라 문제를 파악하고 해결할 수 있는 능력을 갖춘 개발자로 성장했다는 점에서 뿌듯함을 느낍니다.

앞으로 계획

이제 취업 준비를 본격적으로 시작할 생각입니다. CS, 자료구조, 코딩 테스트, SQL 등 기초부터 다시 복습하며 실력을 쌓고자 합니다. 이 기회가 마지막으로 기초를 제대로 다질 수 있는 시간이 아닐까 싶습니다. 겜린더는 주말마다 업데이트를 위해 꾸준히 개발할 예정입니다.

Github Repo 모음 겜린더 백엔드 : 링크 겜린더 게임 수집 봇 : 링크 겜린더 게임 출시 알림 자동화 : 링크

읽어주셔서 감사합니다.

문제

기존 파이프라인을 먼저 보자

이런 과정인데 여러 번 테스트를 거치면서 여러 문제점이 있었다.

1. 데이터 파편화 발생

1. 플랫폼마다 수집
2. CSV로 백업 파일 생성
3. RDB(MariaDB)로 insert하고 다음 플랫폼 수집을 진행하였다.

위와 같은 프로세스가 진행되어 다음 플랫폼으로 넘어갔다고 가정해보자

Playstation에서 데이터를 수집하는데 오류가 발생되어 만약 프로그램이 종료된다면..? 이전에 수집했던 데이터는 더미데이터로 남게되어버린다.

덕분에 데이터를 관리하는데 어려운 측면이 있었다. 실패하면 그 더미데이터를 수동으로 지워야했기 때문이다.

생각보다 별 거 아니겠거니 했는데 데이터가 쌓이다보니 관리가 너무 힘들었다.

2.백업 데이터 저장 방식의 문제

기존 백업 데이터를 저장할 때

생성 날짜와 시간을 함께 사용해서 저장했는데 이게... 음... 나쁜건 아닌거같은데 좀 가독성이나 보기 불편한 기분이었다. 그래서 타임스탬프를 써서 저장하는게 낫다고 판단하였다.

생성 날짜와 시간을 전역 변수로 생성을 했었는데 이번엔 Database 클래스에 인스턴스 생성 시 같이 생성할 예정이다.

개선

위의 문제점을 인지 후 개선한 버전이다.

개선된 V2 버전

비교해보자

1. 영역을 명확하게 분류

Init, Collection, Upload 영역으로 명확하게 프로세스를 분류하였다.

2. 수집 후 일괄적 업로드

기존에는 한 플랫폼 수집하자마자 DB로 Insert 과정을 거쳤지만 이번엔 Steam, Playstation, Xbox, Switch 이 4개의 데이터를 전부 수집하지 못하면 Upload 프로세스로 넘어가지 못하게 하였다.

덕분에 일관성 있는 데이터와 더미데이터를 줄일 수 있을 것으로 기대한다.

3. 병렬 프로그래밍을 고려한 설계

사실 Collection 영역을 만든 건 추후 병렬 프로그래밍을 통한 수집 속도 개선을 하기 위한 설계다.

기존 V1에서 만약 병렬 프로그래밍을 한다고 해보자 Steam, Playstation, Xbox, Switch 데이터를 동시에 수집하고 MariaDB에 insert를 하는 과정이 발생한다고 하면

만약 Switch 데이터가 먼저 수집이 되어 insert를 하고있는 중간에 Xbox가 데이터를 수집해서 insert를 동시에 한다고 가정해보자 그렇게 되면 성능 저하도 우려되고 동시성 문제나 데드락이 걸릴 수도 있다.

이를 방지하기 위해서 Collection을 영역을 나눠 Collection은 병렬로 데이터 수집을 진행한 다음 순차적으로 DB에 insert를 하는 것이 구조적으로 보나 확장성면에서 더 유리할 것으로 판단하였다.

Xbox 번들 탐지 개선

이번에 Xbox 번들 탐지 알고리즘도 개선하였다. 사실 상 새로 만들었다고 하는게 맞다.

패턴 분석

개선하기 위해서 일단 상품이 어떤식으로 나오는지 패턴을 분석했다.

Xbox는 이렇게 Edition 같은 패키지 상품도 출시 예정 리스트에 올리는데

상세 페이지는 "포함됨" 혹은 "이 번들" 영역이 존재한다. 하지만 인식해야할 건 "이 번들" 영역이다.

공통점 -> 모든 오리지널 게임들은 다 첫번째에 배치되어있다.(라고 생각했으나 아니였다.) “이 번들” -> 인식 대상 “포함됨" -> 인식 대상 X (대부분 DLC)

"이 번들"에 있는 오리지널 게임으로 Redirect 하는 것이 목표이다.

이 번들 영역은 일단 분석해 본 결과 4가지 패턴이 존재하였다. 이렇게 4가지 패턴으로 존재하는데 오리지널 게임은 보통 게임보기, 가격 형태로 표시가 된다는 것이었다.

그리고 만약 가격+게임보기처럼 동시에 존재하는 형태인 경우 가격이 붙은 상품이 오리지널 게임이었다.

이런 패턴을 분석하여 솔루션을 정리하였다.

솔루션

1. 게임보기 혹은 가격이 있으면 그건 원본 게임일 확률이 높다.

2. N번째 게임을 순차적으로 수집해 패턴과 일치하는지 확인 후 그 곳으로 페이지를 넘긴다.

3. 만약 첫번째에서 패턴이 일치하지 않으면 두번째 세번째 넘어가면서 순차적으로 패턴 분석

알고리즘

코드

패턴 탐지 if문

이전 번들 탐지 알고리즘

이전 코드와 비교해보자

이전에 비하면 엄청 단순화 되었고 정확도가 올라갔다!

이전 알고리즘은 제대로 탐지를 못해 이상한 DLC페이지로 넘어갔었다. 이 부분 때문에 이상한 데이터를 수집하거나 프로그램이 터졌었다.

마무리

다음 V3는 아무래도 병렬 프로그래밍을 통한 수집 속도를 개선할 예정이다. 아마 이 파트는 겜린더가 정식 출시했을 때 할 수 있지 않을까 싶다.

지금은 앱 개발이 더 급하기 때문이다. 개발 중인 부분을 잠깐 보여주자면 빠르게 탐색하고 나만의 겜린더에 빠르게 추가하는 인터랙션을 넣어보고 있다. 얼른 정식 출시해서 사용자 피드백을 많이 들어보고 싶다. 😁

세션과 쿠키 그리고 JWT에 대해 공부하고 겜린더에는 왜 JWT를 적용했는지 정리하기 위한 글이다.

HTTP

세션을 알아보기 전에 HTTP에 대한 정리를 해보면 좋을 것 같다.

HTTP는 HyperText Transfer Protocol의 약자로 www(World Wide Web) 상에서 정보를 주고 받을 수 있는 프로토콜이라고 한다. 주로 HTML 문서를 주고받는 데 쓰이지만 일반적인 텍스트, 이미지, 영상, 음성, 파일 등도 전송할 수 있다.

특징

클라이언트 서버 구조

클라이언트와 서버 사이에 이루어지는 요청/응답(Request/Response) 프로토콜인데 예를 들어 클라이언트가 HTML을 요청하면 해당 필요한 정보를 해당 클라이언트에게 전달한다.

비연결성(Connectionless)

이건 사실 1.0의 대표적인 특징이고 1.1부턴 지속 연결을 사용한다... 특징이라고 하긴 좀 애매하지만 그래도 가져와 봤다.

Stateless 하다

HTTP에서는 서버가 클라이언트의 상태를 보존하지 않는다.

응답과 요청이 독립적인데 이를 통한 장단점이 존재한다.

• 장점 : 서버 확장성이 높다 응답 서버를 쉽게 바꿀 수 있어 서버 증설하기 좋은 편이다.

• 단점 : 클라이언트가 추가 데이터를 전송해야 한다.

그럼, 로그인 같은 유저의 상태(정보)를 유지하는 서비스는 어떻게 하는 거지?

이럴 때 브라우저 쿠키, 세션, 토큰 등을 이용해 상태를 유지해 주는 것이다.

Cookie

HTTP Cookie란 웹 서버에 의해 사용자의 컴퓨터에 저장되는 "이름을 가진 작은 크기의 데이터"(4KB) 이다. 사용자가 어떠한 웹사이트를 방문할 때 사용자의 웹 브라우저를 통해 인터넷 사용자의 컴퓨터나 다른 기기에 설치되는 작은 기록 정보 파일을 일컫는다.

쿠키는 스파이웨어를 통해 유저의 브라우징 행동을 추적하는 데 사용될 수 있고 누군가의 쿠키를 훔쳐 해당 사용자의 웹 계정 접근권한을 획득할 수도 있다.

쿠키는 보통 세 가지 목적을 위해 사용된다.

1. 세션 관리

• 서버에 저장해야 할 로그인, 장바구니, 게임 스코어, 접속 시간 등의 개인 정보 관리

2. 개인화

• 각 사용자에게 적절한 페이지를 보여줌 (사용자 선호, 테마 등의 세팅)

3. 트래킹

• 사용자의 행동과 패턴을 분석하고 기록하는 용도

요즘은 Web Storage를 사용해 정보를 저장하는 것을 권장한다고 한다.

요청마다 쿠키가 함께 저장되기 때문에 특히 Mobile Data Connections인 경우 성능이 급격히 떨어질 수 있다. 정보를 클라이언트 측에 요청하려면 Web Storage의 종류인 Local storage, Session storage 아니면 Indexed DB를 사용하면 된다.

Velog도 야무지게 사용한다. 근데 Local storage에 저장하면 XSS공격에 취약하지 않을까...? 차라리 HttpOnly, Secure, SameSite 플래그가 설정된 쿠키에 저장하는 게 나을지도..

Please Stop Using Local Storage 좋은 글이 있어 공유해본다.

HTTP Session

HTTP는 상태가 유지되지 않는 Stateless 한 프로토콜이라고 했다. 그럼, 서버는 클라이언트의 상태를 어떻게 기억할까?

클라이언트의 상태를 기억하기 위해 대표적으로 Session 개념을 사용하였다.

작동 방식

1. 서버는 고유한 세션 ID(JSESSIONID)를 웹 브라우저 쿠키로 전달한다.

2. 이를 받은 클라이언트는 서버에 어떠한 요청을 할 때 쿠키(JSESSIONID)를 함께 전달한다.

3. 서버는 전달받은 세션 ID를 서버에 이미 저장되어 있는 정보와 비교해 클라이언트의 상태를 지속적으로 유지하게 된다.

Session ID가 저장된 쿠키를 이용한 HTTP Request 과정

구조

• 서버에 세션 저장소가 필요하다 (메모리, 데이터베이스 등)

• 클라이언트에는 세션 ID만 저장하는데 보통 쿠키에 저장한다.

세션의 특징

• Session ID는 브라우저 단위로 저장되어 브라우저 종료 시 소멸한다.

• 사용자의 로그인 상태, 닉네임 등 사용자가 요청할 때마다 필요한 정보들을 세션에 담아두면 사용자 DB에 접근할 필요가 없어 효율적이다.

• Stateful 하고 서버 측에서 세션 관리 및 제어가 용이하다.

JWT

JWT(JSON Web Token)은 JSON 객체로 당사자 간에 정보를 안전하게 전송하기 위한 컴팩트하고 독립적인 방식을 정의하는 개방형 표준이다. (RFC 7519)

라고 하면 너무 복잡해 간단하게 정리해 보자

작동 방식

서버가 사용자 인증 후 JWT를 생성하여 클라이언트에 전송 클라이언트는 이후 요청마다 JWT를 함께 전송 서버는 JWT의 서명을 확인하여 유효성 검증

서버는 JWT를 디코딩해 유효성 검증을 진행한다.

구조

• Header: 토큰 타입과 해시 알고리즘 정보
• Payload: 클레임(사용자 ID, 만료 시간 등)
• Signature: 토큰의 유효성을 검증하는 서명

JWT 특징

• Stateless: 서버에 별도의 저장소가 필요 없음
• 확장성이 좋음: 서버 간 공유가 쉬움
• 클라이언트 측에서 저장 및 관리

난 왜 JWT를 사용했을까?

1. 확장성과 Open API

• 추후 겜린더 서비스가 만약 커진다면 개발자들에게 겜린더의 데이터를 Open API로 배포하고 싶은 목표가 있었다. (누가 쓸지는 모르겠다만...)

• 이럴 땐 서비스 확장에 유리한 JWT가 더 적합하다고 판단하였다.

2. 리소스의 효율성

• 라즈베리파이로 서버를 일단 구성해야하기 때문에 제한된 리소스 환경에선 세션보단 JWT가 서버 메모리 사용을 줄일 수 있다고 생각한다.

• 세션 저장 및 조회할 때 서버에 대한 부하가 증가할 것 같아 JWT가 더 좋다고 생각했다.

3. 개발 난이도

• 세션도 분명 확장성을 보완하기 위해 세션 클러스터링 같은 방법이 있다고 배웠다. 하지만 JWT보단 난이도가 높을 것으로 판단하였다.

물론 JWT의 한계도 매우 잘 알고 있다.

보안 이슈가 생기면 정말 골때리기 때문에 신중하게 구현해야 한다. 그래서 내가 할 수 있는 방법들을 생각해 보았다.

1. Access Token & Refresh Token 탈취

• 이를 위해 Access Token의 만료시간을 짧게 할 예정이다.

• Refresh Token은 Token Rotation 기능을 구현해 Refresh할 때마다 새로운 Token을 발급받을 수 있도록 하였다. (Redis를 적극 활용하였다)

• 애초에 토큰에 민감한 정보를 많이 넣지 않을 예정이다. 자칫하면 DB 조회가 좀 더 늘어날 수 있지만 그래도 Token 자체에 예민한 개인정보를 넣는 것보단 나을 것 같다.

2. HTTPS 구현

3. 앱 보안

• 로그아웃 시 안전하게 토큰 삭제

• 토큰 저장할 때 Local Storage 쓰는 게 아닌 좀 더 안전한 저장소 사용 (iOS의 Keychain, Android의 EncryptedSharedPreferences 같은 것들...)

마무리

겜린더는 확장성이 중요하다고 생각해 JWT를 구현하였지만,

언제나 기술의 장단점을 알고 명확하게 왜 써야 하는지 그리고 단점을 최대한 보완하는 것이 중요하다고 생각했다.

사실 예전에 Spring Boot로 Session 로그인을 구현한 적이 있었다. 근데 사실 구현하기가 너무 힘들었다.

레퍼런스가 많이 없었기 때문이었다.(스프링인데..?) 다들 JWT로 구현하는것이 유행인 것 처럼 로그인 기능을 구현하는 강의나 그런걸 찾아볼 때 전부 JWT로 구현하는 것을 보았었다.

기술에도 트랜드가 있다고 하지만 왜 써야 하는지 명확하게 모르면 안된다고 생각해 이번 글을 정리해보았다.

다음 글은 JWT를 어떻게 구현하였는가에 대해 적어볼 예정이다.

최근 겜린더를 개발하면서 생겼던 일들을 서사별로 정리하고 싶어 일기 느낌으로 정리해 보았습니다.

슬로건 변경

겜린더의 슬로건을 바꾸었다.

기존 슬로건 달력으로 알아보는 게임 정보

새로운 슬로건 나만의 게임 캘린더

최근 겜린더의 UI를 개선한 부분을 UI/UX 공부하는 친구에게 자랑 아닌 자랑을 했었다. 겜린더 프론트엔드 제작기 1 근데 친구가 UI 관련 피드백을 해주다가 팩폭을 했는데

한마디로 요약하자면 친구가 현재의 겜린더는 딱히 써야 할 이유를 모르겠다고 했었다.

*친구 : * 겜린더라길래 자신이 원하는 게임을 달력에 추가하는 건 줄 알았는데 아니네? 그럴 거면 왜 써 오히려 불편해

친구가 말하는 게 사실 맞다. 지금의 겜린더는 특출난 무언가가 없다. 그냥 달력 형태로 게임 정보 보여주는 건데 말 그대로 CRUD인데 무슨 매력이 있겠는가 심지어 보기에도 더 불편한 달력 형태로 데이터를 제공한다. (최악 그 잡채)

굳이 핑계를 대보자면 내가 개발 능력이 없다고 생각했고, 빨리 만들어야겠단 생각을 했기 때문에 그냥 최대한 단순화하고 싶었다. 사실 이렇게 생각하면 안 되는 건데 어느 순간 현재 상황에 안주하고 있었다

이렇게 만들면 내가 만족할까?

또 새로 만든다고 코드를 다시 작성하고 있을 나 자신이 보였고 후회할 짓 하지 말고 내가 하고 싶은 것 다 구현해 보자 싶었다.

그래서 "나만의 게임 캘린더"로 슬로건을 바꾸었다.

그럼, 회원 관리를 해야 하나?

슬로건이 나만의 게임 캘린더로 바뀌면서 단순히 달력 형태로 사용자에게 게임 정보를 제공하는 걸 벗어나야겠다고 판단했다.

친구의 말을 토대로

자신이 원하는 게임을 저장해 달력에 볼 수 있게 하고, 덩달아 출시 알림까지 받아낼 수 있게 하는 과정이 사용자가 쓰기에도 더 유용할 것 같았다.

단순한 개념도

회원 관리는 혼자 서비스를 운영하는 데 있어 상당히 리스크가 있다.

당장 생각나는 것만 해도 보안 문제, 인프라 문제, 비용적인 문제, 구글플레이나 앱스토어의 정책문제 등등... 여러 문제가 생길 것이 분명하다는 느낌이 팍팍 들었고 간단한 Key Value 스토리지나 SQLite 같은 거 사용해 로컬에 데이터를 저장하는 게 어떠려나? 싶었다.

나 : 폰을 바꾸거나 앱을 재설치하면 데이터가 전부 날아가! 대신 관리는 내가 할 필요가 없고! 운영하는 데 큰 비용이 들지 않아서 이득!

라고 친구한테 설명했으나... 이걸 같이 듣고 있던 친구의 반응은

친구 : 쓰읍 그건 좀.... 살짝 아쉬운데? (에반데?)

당연한 반응이다. 요즘 누가 저렇게 사용자의 데이터를 저장도 안 하고 날려 먹게 하는가... 다 계정 연동되서 저장되는 세상이다.

알고 보니 매너리즘에 빠진 건 나 자신이었다.

난 아직도 운영에 대한 리스크를 줄이려고 최대한 발악했던 것이다.

과거에는 항상 사용자의 입장에서 생각해보려고 노력했던 내 생각은 어느 순간 스스로의 현실에 타협하고, 편안함을 찾으려는 나 자신을 보고 충격받았다.

도전해도 모자를 판에 이런 생각을 하는 나 자신이 너무 싫었고, 일단 기능을 다 만들고 운영은 나중에 생각하자는 마음으로 결국 회원 기능을 만들기로 하였다.

새벽 4시에 머릿속에 생각나는 것들만 열심히 휘갈겨 쓴 흔적들

JWT 기능 구현

회원 기능을 만들자! 라고 생각하고 공부하면서 개발을 하니 어느 순간 완성 되어있었다.

2주 정도 예상했었는데 생각보다 빨리 만들어냈다.

다만 아직 비밀번호 재설정 관련 기능을 만들지 못했고 보안을 위해 Refresh Token Rotation 기능을 구현하였다.

Refresh Token Rotation을 만들면서 약간 문제 아닌 문제가 있었는데 이 내용은 추후 JWT 구현 과정 글을 작성할 때 적을 예정이다.

친구의 디자인 피드백과 도움

그리고 이전에 피드백 받은 친구한테 UI 관련해 좀 더 자세한 내용을 들어보고 싶어 질문을 했는데 친구가 직접 Figma로 본인이 생각했던 UI 디자인을 만들어주었다.

생각 이상으로 너무 잘 나와서 이대로 친구가 만들어준 UI 디자인을 토대로 다시 프론트 작업을 할 생각이다.

내가 여태껏 구현하지 못했던 것들을 구현해야 해서 나름의 도전이라고 생각하고 또 해보려고 한다.

1시간 30분 정도 걸렸다는데 내가 한 것보다 훨씬 낫다 역시 배운 사람은 다르다...

마무리

나는 항상 어떤 일을 하든 최악의 상황을 가정하고 여러 가지 경우의 수를 생각한다. 그러다 보니 생각이 점점 많아지게 되는데

덕분에 항상 어떤 아이디어를 내놔도 생각 많은 성격 탓에 스스로를 검열해 아이디어로만 남겨놓는 경우가 대부분이다.

사실 욕심이 많아서 아이디어를 많이 내보았지만 실제로 실행하기가 무섭기도 하다.

이러다가 취업은 할 수 있을까... 사회에서 인정도 못 받을 것 같다는 생각 때문에 그런 것 같다.

이런 복잡한 생각들을 요즘은 최대한 단순하게 생각하려고 한다. 그냥 해야지!, 하지 말아야지! 생각하는 게 아니다.

지금은 퇴사했지만, 과거 Apple 최고 디자이너 Jony Ive가 iOS 7 소개했던 영상이 있는데 영상 초반 그가 했던 말은 정말 인상 깊었다.

"단순함은 복잡함에 질서를 부여하는 것이다."

어렸을 적 봤을 땐 디자인에만 적용되는 문장 같았지만, 인생을 살아가는 데도 매우 중요한 문장이라고 생각한다.

어렸을 때부터 감명받아 항상 인생에 적용하려 노력했었는데 어느 순간 잊고 살아온 것 같아 이렇게 다시 한번 복기해본다.

열심히 허슬하자

Github Gamlendar_Selenium

겜린더 게임 수집 파이프라인을 안정화 작업을 하고 있을 때 발생했던 일이었다. 약 2300개의 게임을 수집해 DB에 저장하기

문제

안정화 하고 테스트를 해보는데 분명 수집할 때는 1400개 이상의 게임이 수집되었지만 DB에는 24개의 게임 밖에 저장이 되지 않았다.

왜 그럴까..?

원인

일단 기존 데이터 수집 방식 구조를 알아야 할 필요가 있다.

수집 프로그램은 최초 실행 때 db 인스턴스를 생성한다.

main.py 최초 실행 때 db 인스턴스를 생성하는 걸 볼 수 있다.

이번에 작업하면서 안정화하면서 기능을 하나 추가했었는데

지난번 글에서 언급한 닌텐도 스위치 페이지 난제를 해결하기 위해 스위치에서 수집한 게임이 기존 DB에 수집되어 있는가를 확인하는 검색 작업을 추가하였다.

저번에 언급한 난제

switch/detailScrap.py db = Database()로 인스턴스를 생성하고 findGame 함수로 검색할 수 있게 만들어뒀었다.

여기서 이제 눈치 빠르신 분들은 어디가 문제인지 눈치채셨을 것 같다.

그렇다 똑같은 Database 인스턴스가 여러 개 생성되었다.

이를 해결하기 위해선 예전에 공부했던 싱글톤 패턴을 이용하면 될 것 같단 생각이 들었다.

해결

싱글톤 패턴??

출처: 위키피디아

짧게 요약하면 싱글톤 패턴은 특정 클래스의 인스턴스를 1개만 생성되는 것을 보장하는 디자인 패턴이다.

장점으로

1. 메모리 낭비를 줄일 수 있다. 한 개의 인스턴스만을 고정 메모리 영역에 생성하기 때문에 메모리 낭비를 방지할 수 있다.

2. 속도 측면의 이점 생성된 인스턴스를 사용할 때는 이미 생성된 인스턴스를 활용하여 오버헤드를 줄일 수 있다.

3. 데이터 공유가 가능하다. 여러 클래스에서 데이터를 공유하며 사용할 수 있다. 하지만 동시성 문제가 발생할 수 있어 설계할 때 유의해야 한다.

왜 나는 싱글톤 패턴을 사용했는가?

1. 데이터 공유

일단 싱글톤 패턴을 사용해야겠다고 생각한 이유는 데이터의 공유가 제일 큰 목적이었다.

물론 그렇게 되면 의존성이 높아질 수 있다는 단점도 있지만

애초에 데이터 공유가 안되면 아예 내가 원하는 대로 작동이 불가능했기 때문에 싱글톤 패턴을 사용하기로 했다.

2. 싱글 스레드로 동작

내가 만든 수집 봇은 싱글 스레드로 동작한다. 싱글톤의 대표적인 문제점 중 하나가 멀티 스레드 환경에서의 동시성 문제인데

내 수집 봇은 애초에 싱글 스레드로 동작했기 때문에 크게 문제가 없을 것 같단 판단이 들었다.

해결한 코드

이런 식으로 중복된 인스턴스를 만들지 못하게 하였다.

하지만 이렇게 했는데도 여전히 1400개에서 24개밖에 올리지 못하는 모습을 보여주었다.

코드와 메모리 주소를 보니깐 인스턴스는 분명 하나인데 인스턴스를 할당할 때마다 init을 하는 것 같았다.

그래서 최초로 초기화하면 그 이후에는 초기화하지 못하게 만들었다.

마무리

싱글톤 패턴은 자바를 공부하면서 대표적인 디자인 패턴으로 공부를 하게 되었는데 이걸 파이썬에 적용해 볼 줄은 몰랐다.

그래도 덕분에 개념을 더 확실하게 잡아갈 수 있었고

이런 상황에서 싱글톤 패턴을 이용해 문제를 해결해야 한다는 생각까지 도달한 모습을 보고 그냥 막 배운 건 아니구나 싶었다.

싱글톤 패턴을 찾아보면서 안티패턴이라고 하던데, 객체지향적인 측면에서 보면 맞는 말이다.

하지만 무작정 안티패턴이라 해서 배척하기보다는, 내 상황과 조건을 확인해보고 필요하면 사용하는 것이 맞다고 보았다.

애초에 멀티 스레드 환경이 아니라 싱글톤 패턴을 사용하기 좋은 조건이 아니었을까 생각한다.

잠깐 언급한 닌텐도 스위치 게임과의 데이터 통합도 잘 해결된 것 같고, 이렇게 수집 봇도 나름의 안정화를 잘 거쳐가고 있는 중이다.

피드백은 언제나 환영합니다. 궁금하신 점이 있다면 댓글 달아주세요!

최근 게임 수집 데이터 파이프라인을 안정화 작업을 해 많은 부분을 개선했습니다. 약 2300개의 게임을 수집해 DB에 저장하기

백엔드를 튼튼하게 만들었으니 멋지게 화면을 뽑아내 줄 프론트엔드도 필요하겠죠?

드디어 백엔드 부분은 좀 빛이 보이는 기분이라 이제 막막한 프론트엔드 작업을 이어서 해보려고 합니다.

만들 때 어떤 고민을 했었는지 생각을 정리해 구현 과정을 적어두었고 물론 지금 만들고 있는 건 아직 작업 중이기 때문에 달라질 수 있습니다.

겜린더(메인 화면)

사실 여러 번 디자인을 갈아엎기도 하고 겜린더의 본질은 무엇인지 다시 한번 고민하게 되었던 시간이었습니다.

앱의 메인 화면은 정말 중요하죠

"어떻게 하면 달력을 좀 더 친숙하게 표현할 수 있을까?" 이 부분을 많이 고민했습니다.

아예 달력 형태를 쓰지말까?라는 의견도 나왔지만 이름이 겜린더(게임 캘린더)인 만큼 달력의 형태를 더욱 유지하고 싶었습니다.

그래서 기존 판매하는 달력들의 이미지를 많이 검색하기도 하고 집안에 있는 탁상 달력이나 벽걸이 달력 등을 많이 봤는데요

Reference Image 출처 : 달카닷컴

이런 식으로 대부분 달력들은 상단에 여러 이미지나 정보들이 담겨있고 하단에 달력이 있는 형태가 많았습니다.

이 아이디어를 착안하여 겜린더의 페이지를 개선해 보았습니다.

개선된 화면

저 게임 등록 배너 이미지는 최종 버전에서 당연히 없어질 예정입니다. (마리오를 실제 앱에 사용했다간... 큰일 날지도..)

어떠신가요? 기존 앱과는 많이 달라 보인다면 다행이네요

개선된 화면의 장점이라면 달력이 하단으로 자연스럽게 내려오면서 한 손으로 달력 조작을 쉽게 할 수 있게 되었다는 점이었습니다.

Thumb Zone

사용자는 한 손으로 달력을 조작할 수 있고 자연스럽게 상단 배너로 새로운 정보를 습득할 수 있게 되었습니다.

상단에 있는 배너는 광고 배너로 활용할 예정인데 겜린더에 직접 게임 등록을 신청해 주신 게임을 홍보할 수 있는 배너로 활용할 예정입니다.

게임 목록

게임 목록은 별도의 페이지를 만들어 분류하였습니다.

기존 카드 디자인

예전에는 게임 썸네일의 이미지가 풀 사이즈로 노출되는게 이쁘고 멋지다고 생각했었는데요

이런 식으로 디자인을 하면 공간 효율이 많이 좋지 못하다 생각하였고, 유저에게 더 많은 정보를 전달하는 게 중요하다 생각하였습니다.

개선 버전 디자인

썸네일 이미지를 일부 포기하더라도 위의 이미지와 같이 정리해두는 게 훨씬 좋아 보여 이 디자인을 채택하게 되었습니다.

덕분에 한 화면에 더 많은 게임들의 정보가 보이게 되어 화면 공간 효율이 좋아졌다고 생각합니다.

D-Day 기능을 넣어 언제 출시하는지 직관적으로 볼 수 있어 개인적으로 더 좋네요! 고민을 많이 했었는데 좋은 결과물이 나온 것 같아 다행입니다.

게임 상세

게임의 상세 정보를 보여주기 위한 페이지를 정말 많이 개선했습니다. 메인화면 다음으로 공을 들여봤는데요

기존 버전

일단 기존 버전의 디자인부터 보시죠

진짜 정보 전달에만 집중되어 있는 느낌... 사실 이때는 실력이 없어 이거에 만족하자~ 이런 느낌이었습니다.

디자인 의도

개선 버전의 디자인 의도부터 말씀드리자면 유저가 게임 설명 페이지를 볼 때 몰입이 되었으면 좋겠다고 생각했습니다.

어떻게 하면 지루한 상세 정보 페이지를 몰입감 있게 보여줄 수 있을까? 라는 고민을 열심히 해 나온 결과물입니다.

개선 버전

애니메이션 미리보기

너무 빨랐나요? 다시 천천히 봅시다.

첫 화면

디자인 의도에서 말했던 것처럼 첫 화면에서 유저가 게임에 몰입되는 것을 원했기 때문에 과감하게 화면 전체를 채워보았습니다.

하단에는 정보들이 간략하게 나오게 됩니다.

좌측 제스처로 화면을 넘겼을 때 상세 설명이 나오게 됩니다.

설명은 역시 검은 화면에 흰 글자가 더 보기 좋을 것 같아서 그렇게 작업해 보았고

기존 버전은 게임 설명에서 문단도 제대로 구분이 되어있지 않는 경우도 있었는데요 그 이유는 제가 일일이 하나씩 게임을 수집하느라 문단 구분하기가 힘들어서 제대로 수집이 되지 않은 경우가 많았습니다.

UX 경험 개선을 위한 애니메이션 추가

몰입감 있게 디자인 한 건 좋은데 좌측 제스처로 화면을 넘기는 사실을 유저가 모른다면...? 라는 생각이 들어

게임 정보와 그에 맞게 제스처로 넘기라는 화살표를 만들어뒀었는데요 이걸로 과연 충분할까? 라는 생각이 들었습니다.

과한 생각이긴 하지만 게임 정보의 위치는 글 상단에 언급했던 Thumb Zone에 포함되어 있어 자칫하면 엄지에 가려져 보이지 않을 수도 있겠다는 생각도 했습니다.

결국 애니메이션을 넣어 눈에 사용자 눈에 바로 즉각적으로 보이게 해주는 것이 좋다고 판단하여 애니메이션을 추가하게 되었습니다.

적절하게 Fade In과 Out을 활용해 반짝거리면서 눈에 띄게 해보았습니다.

간략한 구현 코드입니다.

글 마무리

아직 구현할 화면과 기능들은 많습니다.

1. 검색 페이지
2. 게임 페이지
3. FCM

그 외..

• 게임 페이지 컨텐츠 구상 등...

예전에는 급급하게 화면에 글 띄우는 것만 해도 정말 재밌었는데 이제는 이런 UI와 UX 같은 사용성까지 고려해가며 제가 생각했던 디자인을 구현할 수 있게 되어 매우 기쁘네요

빠른 시일내로 제작해 얼른 재출시를 해보고 싶어집니다.

그리고 프론트 결과물을 보고나니 더욱 더 백엔드를 다시 처음부터 설계하길 잘했단 생각이 다시한 번 들었습니다.

마지막으로 전체적인 플로우를 보며 글을 마무리 하겠습니다. UI나 UX 관련 피드백은 언제나 환영합니다.

읽어주셔서 감사합니다.

전체적인 플로우

목차 1. 궁극적인 목표 2. 내가 겪은 문제점 3. 솔루션 (데이터 파이프라인을 만들자!) 4. 의문점 5. 후기

피드백은 언제나 환영합니다. 언제든 훈수해 주셔도 괜찮습니다.

지난 글에 이어서 작성합니다. 겜린더 스크래핑 봇 제작기 Steam편

Github Gamlendar_Selenium

3줄 요약

1. 게임 정보를 자동으로 수집하고 저장하는 데이터 파이프라인 구축
2. 데이터 전처리(Data Cleansing)을 통해 일관성 있는 데이터 정제 및 RDB에 저장
3. Steam, Xbox, Playstation, Nintendo Switch 합쳐 약 2300개의 데이터를 수집할 수 있었음

궁극적인 목표

리마인드 하기 위해 다시 목표부터 작성해 보자면..

1. 게임 정보를 하나하나 손으로 수집하기 힘들기 때문에 자동화하기

2. 중복 게임은 하나로 합쳐주기

   게임 출시하는 플랫폼은 여러 곳이 존재하는데 만약 A라는 게임이 Playstation, Xbox에 출시한다면 각 플랫폼 페이지에 있는 A 게임의 정보를 하나로 합쳐 정리해 주는 것이 목표였습니다.

예시를 들어보자

이런 식으로 정리가 되면 중복되는 데이터가 너무 많아지는데.. 예제라서 별것 아니네~ 할 수 있겠지만 세상에는 게임이 정말 많았습니다..

이런 게임이 수백 개가 쌓이면 저걸 어떻게 관리할 방법이 있을지... 저는 생각나지 않았습니다.

이렇게 합쳐 추후에 JSON 형식으로 정리할 때도

{
    "게임이름":"엘든링",
    "게임설명":"그냥 겁나어려운 게임",
    "제작사":"FromSoftware",
    "플랫폼":[Playstation, Xbox, Steam"]
}

이런 식으로 손쉽게 정리했으면 좋을 것 같은데 이렇게 정리하면 결과물은 어떻게 나올까요??

예상 결과물

현재 리뉴얼을 진행 중인 겜린더 상세정보 페이지 이미지 우측 하단에 지원 플랫폼 아이콘을 볼 수 있다.

요런 결과물이 나오게 됩니다

내가 겪은 문제점

1. 데이터 수집 전략

• 각 플랫폼마다 형태가 전부 다른데 일일이 하나하나 웹페이지를 분석하여 페이지에 맞게 수집을 해야 하는 것 (이건 당연한 소리지만... 생각보다 애를 많이 먹었네요...😂)

2. 수집한 데이터의 게임 이름을 일치시키기

같은 게임이더라도 각 플랫폼에 등록되어 있는 게임의 이름이 다른 경우가 있었습니다.

이런 식으로 어떤 곳에선 한국어로 되어있고 어떤 곳은 영어로 되어있었던 건 기본이고...

이런 식으로 DLC 번들팩을 같이 포함해서 노출시키는 경우도 많았습니다. (사실 이 부분은 완벽하게 해결하진 못했습니다.)

3. 게임 이외의 DLC도 함께 노출

위 사진은 Xbox의 출시 예정 리스트 중 일부

MLB The Show 24만 현재 5개나 겹쳐있는 이런 경우도 많았습니다. 저런 데이터까지 전부 수집하면 중복되는 데이터가 많아져

겜린더를 이용하는 유저 입장에선 필요 없는 데이터까지 노출되어 정작 해당 게임에 대한 핵심 정보는 보지 못할 수 있겠다 생각하였습니다.

4. 닌텐도는 왜... 한국 페이지랑 북미 페이지랑 완전히 다를까요...?

북미 페이지와 한국 페이지의 레이아웃 디자인은 완전히 달랐습니다. 심지어 SKU(Stock Keeping Unit)도 형태 자체가 달라 이건 뭐.. 어떻게 수집해야 할지 고민을 많이 했습니다.

5. 성인 게임 필터링

겜린더 스크래핑 봇 제작기 Steam편 여기서 보면 Steam에 있는 성인 게임을 어떻게 필터링했는지 나와있기 때문에 솔루션 부분에서 간단하게 언급만 하겠습니다.

이렇게 5가지를 어떻게 해결했고 어떤 구조로 만들었는지 구체적으로 적어보겠습니다.

솔루션 (데이터 파이프라인을 만들자!)

겜린더 백엔드 구조도

흐름도..

유저에게 최종적으로 어떻게 전달되는지 보여주는 간략한 구조도입니다. 오늘은 MongoDB - MariaDB - Selenium 이렇게 3가지 영역을 좀 더 설명해 볼까 합니다.

데이터 파이프라인 구조

게임 수집과 DB에 저장하기 위한 데이터 파이프라인을 구축해 보았는데요 여기서 영역 별로 쭉 훑어보도록 하겠습니다.

Data 수집

데이터 수집을 시작할 때 처음부터 Selenium 브라우저를 2개를 실행하기로 했습니다. 겜린더 스크래핑 봇 제작기 Steam편 이유는 여기에 나오지만 간략한 설명을 하자면

게임 검색에 필요한 게임 이름이 한국어뿐만 아니라 영어도 필요했기에 2개를 실행해 각각 수집하기 위해서였죠

여기선 겪은 문제점 중 3번(게임 이외의 DLC 노출) 을 어떻게 해결했는지 적어보려고 합니다.

번들 탐지 기능

여기 중 가장 좌측 상단의 첫 번째 MVP 에디션을 눌러보면

게임의 정보와 함께 하단을 내렸을 때 "이 번들"이라는 정보가 나오게 됩니다. 제가 원하는 정보는 DLC가 아닌 순수한 게임의 정보였기 때문에

"이 번들" 정보를 수집해 "MLB The Show 24 Xbox One" 혹은 "MLB The Show 24 Xbox X|S" 둘 중 하나의 페이지로 다시 리다이렉트 시키는 것이 목표였습니다.

반대로 저런 번들이 없다는 건 순수한 게임 페이지로 판단할 수 있어 바로 게임 정보를 수집할 수 있게 만들었습니다.

코드

주의⚠️ 스파게티 코드라 눈뽕이 있을 수 있으니 참고 바랍니다. 죄송합니다...🙇 (물론 Refactoring 할 예정입니다...)

물론 다른 것들도 여러 가지 번들이 많기 때문에 처음 게임 리스트에서부터 사전에 정해둔 단어가 포함되어 있으면 수집 대상에서 제외하는 1차 필터링 기능을 넣었습니다.

하지만 1차 필터링으론 한계가 꽤 많았습니다.

필터링 단어에 "Edition"이란 단어를 넣으면 게임 이름에 Edition이 들어간 게임이 의도치 않게 제외될 수도 있어 번들 탐지 기능을 추가하였습니다.

Xbox 페이지를 수집하면서 꽤나 중복된 게임 정보가 많았기 때문에 여러 수집 전략을 생각해 볼 수 있었습니다.

성인 게임 필터링

겪었던 문제점 중 5번 성인 게임 필터링이 있었죠? 이 부분은 그냥 필터링 걸어서 해결했습니다.

저 태그가 들어간 친구들은 도저히 겜린더에 들어가기 힘들겠단... 게임들도 많았습니다. 그래서 그냥 자체적으로 걸러냈습니다.

아직 성인 인증 기능이 겜린더에는 안 들어갔거든요...🥲

Data Cleansing

사실상 여기가 제일 중요한 지점인데요 이 부분을 잘해야 나중에 DB에 저장할 때 데이터 무결성과 중복 데이터를 잘 처리할 수 있었기 때문이었습니다.

그래서 수집한 사이트마다 미묘하게 다른 게임 데이터들을 일관성 있게 정제해야 했습니다.

정제 기법은 3가지가 존재하는데요 3가지의 소개와 겜린더에는 어떻게 적용했는지 같이 설명하겠습니다.

1. 변환

다양한 형태로 표현된 값을 일관된 형태로 변환하는 작업

• 수집된 게임 이름 중 불필요한 데이터를 없앴습니다. 게임 이름 뒤에 있는 PS4 & PS5는 필요 없기 때문에 replace로 간단하게 지워주었습니다. 이렇게 괄호가 정말 많이 들어간 게임도 존재했는데요 코드로 보여드리는 게 빠를 것 같네요 정규식을 이용했습니다.

굳이 두 번 넣은 이유는 괄호 안에 괄호가 있는 경우가 많아 2번 넣어 해결했습니다.

2. 파싱

데이터를 정제 규칙을 적용하기 위한 유의미한 최소 단위로 분할하는 과정

• 수집한 데이터 중에서 날짜를 예시로 들면 좋겠네요 Steam은 연, 월, 일로 날짜를 표시하고 (2024년 3월 12일) Xbox는 '-'로 표시 (2024-03-12) Playstation은 '/' (2024/3/12) Nintendo Switch는 '.' (2024.03.12)

각각 달랐기 때문에 연, 월, 일의 최소 단위로 분할부터 하였습니다. 2024, 3, 12 이런 식으로 추출하였습니다.

3. 보강

변환, 파싱, 수정, 표준화 등을 통한 추가 정보 반영

• 겜린더에 적용하기 위해선 YYYY-DD-MM 형식으로 만들어야 했습니다. 그래서 보강이 좀 필요했는데요 Playstation을 예시로 들면 '/'을 기준으로 split 후 월, 일에 zfill(2)를 통해 3을 03으로 변환하는 작업을 거쳐 겜린더 형식에 맞게 '-'.join을 넣어 2024-03-12 가 최종적으로 출력되도록 하였습니다.

닌텐도 페이지 수집

사실 이게 제일 난제였습니다. 다른 페이지들은 페이지 주소만 바꿔서 영문 페이지나 한국 페이지로 변경할 수 있었는데 얘네는 각각 독립적으로 사이트를 운영하고 있었습니다...

어.. 그러면 영문 게임 이름 수집을 어떻게 해야하지...?라고 고민을 많이 했습니다.

고민한 흔적들..

하지만 고민하면서 사이트를 둘러보고 있을 때 게임 이름 중에 이렇게 괄호로 영문 이름을 사용한 게임이 있더군요! 그 반대의 경우도 있었습니다. 영어(한국어) 형태로 이거라도 추출해야겠다 싶었습니다. 이게 제 최선이 아닐까 싶었습니다.

이런식으로 추출하는 코드를 만들었는데

1. raw_title에 괄호가 존재하는지 re.search로 확인
2. match가 True인 경우 추출한 문자열이 영어인지 ASCII 코드로 확인
3. True면 괄호 안의 문자열은 영어이므로 eng_title에 저장 kor_title은 raw_title에서 괄호를 제거해 저장하였습니다.
4. match가 False인 경우는 그 반대로 했습니다.
5. 아예 위 조건에 맞지 않는 경우는 그냥 raw_title를 eng, kor 둘 다 저장했습니다.

데이터 무결성

데이터 무결성을 위해 여러 작업도 거쳤는데요 한국어로 된 게임 이름은 추후 DB에 넣을 때 무결성이 좋지 못하다고 판단했고 그래서 영문 이름을 기준으로 넣어야겠다는 생각이 들었습니다.

영문 이름을 수집한 이유도 그중 하나였는데요 데이터를 CSV로 전환하는 작업 중 title column 데이터를 autokwd에 있는 영문 이름으로 덮어씌우는 작업까지 해 데이터 무결성을 지킬 수 있었습니다.

for 문만 보시면 됩니다.

왜 concat을 하는지는 겜린더 스크래핑 봇 제작기 Steam편 참고해주시면 감사하겠습니다... 🙇

최종적으로 CSV 파일로(백업용) 저장되는데 이 파일은 DB로 저장됩니다..

Save to MariaDB

여러 가지 과정을 거쳐 결국 MariaDB에 저장하게 되는데 전체적인 ERD입니다. ( Platform, autokwd, screenshot이 중복되는 데이터가 많기 때문에 2정규화를 거쳤습니다.

Dragon's Dogma 2를 기준으로 찾아보면

platform 테이블

screenshot 테이블

autokwd 테이블 Dragon's Dogma 2는 한국어 이름이 없어서 다른 게임으로 대체하였습니다.

Transform Data (RDB -> JSON)

자.. 이제 모은 정보들을 다시 하나로 합쳐 JSON 형태로 변환해 API로 전송해야 합니다.

MongoDB로 보내는 작업을 해야 하는데...

View를 따로 만들어서 조회하고

일부 필요한 데이터를 또 추가로 넣어둔 다음...

Request로 간단하게 넣어주면 MongoDB로 옮기는 작업이 끝나게 됩니다.

MongoDB에 이쁘게 옮겨진 모습입니다. 위에 보니 2399개가 저장되었네요 😊

의문점

실제로 지인들에게 들었던 말인데

"이럴 거면 그냥 CSV에서 데이터 통합해서 JSON으로 보내는 게 더 낫지 않냐! 굳이 왜 RDB같은 거 왜 씀?" (Pandas 뒀다 뭐 함?)

어.. 물론 맞는 말 같아서 할 말 없었는데 굳이 이유를 설명하자면 RDB에 저장해 두는 게 추후 데이터 관리에 매우 용이할 것 같아서 저렇게 번거로워도 작업했던 것이 가장 큰 이유였고 언제든 데이터 복구를 위해 사용한 것도 있습니다. (그냥 RDB를 제대로 써보고 싶었던 욕심도 있었습니다.)

겜린더는 라즈베리파이 환경에서 돌릴 예정이기 때문에 여러가지 요인으로 서버가 다운될 수도 있습니다. (정전, SD카드 수명, 라즈베리파이 수명 등..)

그래서 데이터를 지켜야 하는데 관리를 하려면 아무래도 2중으로 DB를 나누는 것이 좋다고 생각했고

MongoDB는 유저가 볼 수 있는 "Contents DB"라고 생각하고 MariaDB는 서버 단에서 데이터를 관리할 수 있는 DB로 생각하고 있었습니다.

물론 이렇게 되면 데이터 불일치(Data Inconsistency) 현상이 발생할 수 있지만

MariaDB는 데이터를 용이하게 관리하고 백업의 목적성이 크기 때문에 일단 이렇게 유지해 볼까 합니다.

후기

되찾은 본질

처음 겜린더를 만들 때도 겜린더의 본질은 무엇일까 생각했었는데 "출시 예정의 게임을 누구나 빠르고 쉽게 볼 수 있었으면 좋겠다"였습니다. 왜냐하면 친구가 게임 스트리머를 준비하는 데 게임을 일일이 스팀에서 찾기 귀찮아했었기 때문이었죠

하지만 그때는 너무 방대한 스팀 게임들에 압도당해 다른 기능을 만든다던가 본질을 좀 회피했었는데 이제서야 본질에 제대로 맞게 플랫폼이 만들어질 것 같습니다.

생각보다 어렵고 복잡했던 데이터 파이프라인 작업

데이터 전처리 작업이 엄청 힘든 작업일 거라곤 생각하지 못했습니다. 여태 간단하게 수집만하고 이쁘게 표시해주는 크롤링 작업만 해봤었는데요 이렇게 데이터를 하나하나 정제하고 일관성 있게 맞추는 작업까지 하려니 정말 힘든 작업이었지 않나 싶습니다. 예상하지 못하는 변수들이 정말 많은 것 같아요...😂

아직 부족한 점은 많습니다. 사실 DB도 제가 제대로 구성해서 효율적인 구조인지 정확히 잘 몰라서 피드백은 언제나 환영입니다. 댓글로 훈수 좀 해주세요...

작업하다 보니 더러워진 스파게티 코드들은 당연히 정리해야 하고, 제대로 정제되지 않는 데이터도 있어서 그런 부분들을 좀 더 고민해 보고 보강도 해야 합니다.

하지만 여태 테스트를 해봤을 땐 100개 중에 3개(3%) 정도의 데이터가 제대로 정제되지 못해 DB에 중복되어 저장되는 경우도 있었습니다. (이건 좀 더 수집해보고 확인해야할 것 같습니다.)

이런 부분들은 제가 수 작업을 좀 거쳐 MongoDB로 보내는 작업을 거칠 예정입니다.

그래도 일일이 60개 이상의 게임을 수집하는데 8시간 쓰는것보다 정말 많이 좋다고 생각합니다.

일이 줄었네요 😁

핵심만 추려서 정리했으니 자세한 부분은 Github 참고해 주세요!

폴더 구성

upcoming

플랫폼 별로 폴더를 만들고 플랫폼 별로 Log와 Backup 폴더를 만들어 문제가 발생할 때 언제든 플랫폼 별로 빠르게 확인할 수 있게 만들었습니다.

Core

자주 사용하는 기능은 core에 따로 분류하였습니다.

어떤 데이터가 필요할까?

겜린더에서 필요한 데이터를 알아보기 위해선 현재 개발 중인 겜린더 앱 상태를 보면...

연보라색의 둥근 사각형이 필요한 데이터입니다.

최대한 단순하게 보자면 총 8가지가 나오게 되는데..

1. 게임 이름 + 영문 이름
2. 제작사
3. 썸네일
4. 플랫폼 지원
5. 스크린샷
6. 게임의 자세한 정보
7. 유튜브 트레일러 링크 (이건 나중에 🥲)
8. 출시 날짜

게임의 영문 이름까지 수집하는 이유 사용자가 한국어로만 검색하지 않기 때문에 영문 이름도 수집합니다. 겜린더 검색 자동완성 성능을 개선해보기

전략

1. 목록 데이터 수집

   • 게임 이름, 출시 날짜, 상세 페이지 링크

2. 각 게임의 상세 페이지 데이터 수집

   • 제작사, 썸네일, 스크린샷, 게임의 상세한 정보
   • 성인 게임은 수집 금지

3. 데이터 통합

1. 목록 데이터 수집

분석

일단 가볍게 페이지를 들어가면 목록들이 나옵니다.

검색에 일치하는 결과가 2,160개가 있다고 나오는데 "오! 그럼 바로 태그 지정해서 수집하면 그만 아닌가!?" 라고 생각하면 큰일 납니다.

2,160개의 정보를 한 번에 띄우는 것이 아닌 스크롤을 내리면 데이터를 받아오는 구조이기 때문에

위의 사항을 고려해 전략을 세우면

1. 스크롤 전의 페이지 전체 높이 값을 알아낸다. (currnetPageHeight)
2. 페이지 스크롤을 한다.
3. 스크롤 후의 페이지 전체 높이 값을 알아낸다. (newPageHeight)
4. 스크롤 전과 스크롤 후의 페이지 높이가 같은지 비교한다.
5. 같지 않다면 아직 불러올 컨텐츠가 있다는 의미이기 때문에 스크롤을 계속한다.
6. 만약 값이 같다면 스크롤을 다 했다는 의미로 해석해 스크롤을 중지한다.

이런 부분을 인지하고 설계한 플로우차트를 보면

currentPageHeight : 현재 페이지 높이 newPageHeight : 스크롤 후 페이지 높이

두 변수의 높이 값이 다르다면 게임 이름, 출시 날짜 수집 두 변수의 높이 값이 같다면 스크롤 중지

위의 설계를 코드로 구현해 봅시다!

코드 구현

• 페이지 언어 한국어로 바꿔주기 가장 먼저 수집하기 전에 driver가 실행되고 페이지를 불러오면 영문으로 표시되는데 페이지를 한국어로 바꿔줘야 합니다.

my_game에 게임 이름, 출시 날짜, 상세 페이지 링크까지 수집

실제 결과 값

목록 데이터 수집은 이렇게 마무리하고 이제 상세 페이지 링크를 활용해 상세 페이지를 수집해 봅시다!

2. 각 게임의 상세 페이지 데이터 수집

이제 상세 페이지 수집을 위해 어떻게 해야할지 고민해 봅시다.

일단 저는 대전제 1가지는 무조건 걸었습니다.

"노출이 정말로 심한 성인 게임은 최대한 수집을 하지 않는다."

이 부분을 어떻게 해결했는지 천천히 과정을 설명드리면서 진행하겠습니다.

상세 페이지 분석

잠깐 숨은 그림 찾기를 해볼까 합니다. 여기서 찾을 수 있는 요소는 총 4가지가 존재합니다.

게임 이름(영문 이름), 개발자, 태그, 스크린샷

또 하단으로 내리면 게임의 상세 정보가 나옵니다.

그럼 총 5가지를 수집할 수 있네요!

수집한 상세 페이지 데이터와 목록 페이지 데이터를 하나로 통합해 CSV 파일로 통합하는 과정까지 해봅시다!

코드 구현

성인 게임 인증

스팀 성인 게임 인증은 특징이 있습니다. 한 번만 인증하면 모든 성인 게임 열람이 가능합니다.

그래서 저는 GTA 5의 페이지로 먼저 성인 게임 인증을 하고 상세 페이지를 수집하기 시작했습니다.

성인 게임 인증

영문 이름 수집 방법

영문 이름을 수집하기 위해서 webdriver를 2개를 실행해 진행하기로 했습니다.

driver 1개로 하면 계속 언어를 바꿔가면서 수집해야 하는데 언어 전환할 때 소요시간이 약 3초 정도가 소요됩니다.

단순하게 3초 * 2000개의 게임 = 6000초의 시간이 그냥 소비가 되기 때문에 2개로 실행하는 것이 더 합리적이라 판단했습니다.

driver : 한국어 driver_eng : 영어

driver은 이미 목록 데이터 수집할 때 한국어로 변경하였고 driver_eng는 새로운 프로세스로 실행이 되기 때문에 페이지를 불러올 때 영문 페이지가 나옵니다.

성인 게임 수집 시 문제점과 해결 방안

"노출이 정말로 심한 성인 게임은 최대한 수집을 하지 않는다."

성인 게임은 최대한 보수적으로 수집한다고 했지만 우리가 하는 게임 중에 성인 인증이 필요한 게임은 생각보다 많았습니다. (GTA, 용과 같이 시리즈 등..)

그리고 분명 노출이 엄청 심한 성인 게임인데도 오히려 성인 인증을 거치지 않는 게임들이 많았기 때문에 이걸 필터링을 어찌해야 할까... 고민을 정말 많이 했습니다.

그래서 생각한 방안 중 하나가 태그를 이용한 필터링을 생각해냈습니다.

정말 노출이 심한 성인 게임을 찾아보면서 공통적으로 들어가는 태그가 있었는데 대표적으로 '헨타이','후방주의','선정적인 내용' 이런 태그가 무조건 상위 태그에 존재하는 사실을 알았습니다.

실제로 필터링 되었던 게임의 태그...

그래서 저런 게임들을 필터링하기 위해 태그를 수집했고 위의 3개 중 1개라도 존재하면 수집하지 않는 방향으로 구성하였습니다.

수집 완료된 데이터 이제 하나로 통합해 봅시다

목록 + 상세 페이지 데이터 하나로 통합시키기

데이터를 통합시키는 건 Pandas의 concat 함수를 이용해 하나로 통합시켰습니다.

백업을 위한 csv까지 생성할 수 있게 하였고 이 함수는 자주 사용하기 때문에 Core에 따로 분리해 언제든 불러와 사용할 수 있게 만들었습니다.

3. 결과

csv 파일은 깃허브에서 확인해 주시면 감사하겠습니다 :)

깔끔하게 csv로 통합해서 결과물이 나오는데 이 데이터를 추후에는 MariaDB에 정리할 예정입니다.

아무래도 이런 데이터는 MongoDB보단 RDB인 MariaDB로 해야 가독성이나 추후 join을 이용한 데이터 조회에도 도움이 될 것 같다고 판단했습니다.

4. 후기

이제 겨우 스팀의 데이터를 수집했지만 할 일이 정말 많습니다.

겜린더라는 프로젝트를 하면서 많이 느낀 부분은 원하는 기능을 구현하기 위해 여러 가지 조사를 하면서

내가 이 기술을 왜 써야 하는가에 대해 항상 스스로 질문하고 합리적인 판단을 하는 과정이

정말 저에겐 공부할 목적을 만들 수 있어 정말 좋은 것 같습니다.

단, 조심해야 할 건 단순히 구현하는 것에 목적을 두는 게 아닌 제대로 원리를 배워가면서 추후 협업을 위한 가독성이 좋은 코드를 작성하는 것을 목표로 프로젝트를 진행해야겠네요.

드디어 겜린더의 핵심이라고 할 수 있는 게임 데이터를 수집하려고 한다.

게임 데이터를 하나하나 수기로 작성했던 입장에서 너무 힘들었던 기억이 있기 때문에 꼭 데이터 수집을 자동화시키고 출시하고 싶었던 목표가 있었다.

하지만 부랴부랴 출시만 했던 서비스라 백엔드에 아주 많은 문제점이 있었고, 결국 처음부터 다시 제작했었기 때문에 시간이 많이 걸렸다. (생각보다 많은 시행착오를 겪은 것 같다.)

시행착오 흔적들

Redis 스터디 및 겜린더 서버 설계 Redis와 FastAPI를 활용해 CRUD 만들기 겜린더의 DB의 문제점과 고쳐야할 것들 MongoDB는 겜린더에 적합한 DB일까?

그리고 우연히 용산에서 알바를 하다가 사장님도 데이터 수집에 관심이 있으셔서 Selenium을 활용해 여러 데이터 스크래핑 프로그램을 만들 기회가 있었는데, 만드는 과정 중 겪었던 경험을 기반으로 이번 스크래핑 봇을 잘 만들어볼까 한다.

과거에 스크래핑 봇을 제작할 때 내 코드를 보면서 아쉬웠던 점을 몇 개 뽑자면...

1. 기능 별로 나누지 못해 코드 가독성 최악
2. 무식한(?) 예외 처리
3. 어차피 내가 개발하고 유지 보수하는 거라 협업 따위 생각하지도 않은 변수명과 구조...

하지만 겜린더는 추후에 같이 해볼 사람이 있을 것을 고려하여 내가 할 수 있는 최선을 다해 코드를 잘 작성해 보려 한다.

그래서 어떤 사이트를 수집할 것인가?

Steam Upcoming

Playstation Upcoming

Xbox Upcoming

Nintendo Release Schedule

개인적인 목표

항상 글을 작성할 때마다 아쉬웠던 점은 글도 글대로 못 쓰지만 시각화를 잘 못해서 아쉬움이 많았다. 나중에 내가 봐도 "아니 이걸 보고 누가 이해를 할 수 있으려나?" 라는 스스로의 의문도 많이 생겼었다.

그래서 이번엔 문서화도 잘해야겠지만 정확히 로직이 어떻게 돌아가는지 쉽게 알아볼 수 있는 시각화 자료를 만들어보고 싶다는 목표가 생겼다.

여담

테스트 코드의 중요성

사실 좀 더 빠르게 프로젝트를 진행할 수 있었는데 하도 설계를 잘해보겠다고 노션에 정리도 해보고 고심도 많이 했지만 결국 테스트 코드 몇 줄 작성해 그에 맞게 설계도 바꿔보고 하면서 진행하는 것이 뭔가 노션에 뜬구름 잡는 것보다 나았다.

Github

Gamlendar_Selenium

상세한 전략과 정리는 깃허브에...

겜린더 백엔드 문제 인식과 문제 해결을 위한 조사에서 이어지는 글 입니다.

요약

1. Redis JSON에서 해야 했던 Indexing(색인) 작업이 사라져 성능을 개선

2. JSON 데이터가 아닌 Sorted Set 형태로 저장해 용량 문제 개선

3. 캐싱 작업을 통해 MongoDB의 부하를 대폭 감소

4. Redis-Stack에 대한 의존성 낮추기...

피드백은 언제나 환영입니다. :)

개요

겜린더의 메인 DB를 Redis에서 MongoDB로 전환하면서 한 가지 문제점이 생겼습니다. 검색 기능을 어떻게 구현해야 할까?

Redis에선 편하게 ReJSON을 통해 index와 search 기능을 제공합니다. 덕분에 과거 작성한 글 중에 실제로 적용해 구현까지 완료했었죠

Redis와 FastAPI를 활용해 DB 만들기

새로 제작 중인 겜린더 앱 일부

문제점 & 개발 방향 정하기

하지만 이번 MongoDB로 전환하는 과정에서 단순하게 쿼리 검색으로 자동완성 기능을 구현하면 큰일 날 것 같은 기분이 들었습니다.

자동완성 기능은 텍스트를 입력할 때마다 사용자에게 완성된 키워드를 줘야 했는데 In-Memory 특징 덕분에 읽기 속도가 빨랐던 Redis의 성능만 믿고 ReJSON의 기능을 이용했지만,

MongoDB는 Disk에 저장하는 방식이기 때문에 분명 성능 상 큰 문제가 발생할 것이라고 판단했습니다.

그래서 방안을 고민하던 과정을 짧게 적어볼까 합니다.

Cache Warming

Cache Warming을 통해 예상 검색어를 미리 Redis에 저장해두는 방식을 고민했는데

과거에 ReJSON을 사용하는 Redis-stack이 Ubuntu 버전(jammy)를 지원하지 않는다는 대참사를 겪어본 적이 있어서 차마 적용하기가 좀 두려웠습니다.

하지만 검색해 보니 이젠 지원하는 것 같네요.. 😂

예전엔 지원하지 않았는데... 🥺

굳이 Redis-Stack을 써야 할까..?

Cache Warming은 결국 여러 문제점으로 인해 아이디어를 폐기하고..

Redis-Stack을 사용하지 않고 Redis-Cli로 충분히 기능을 구현할 수 있지 않을까? 라는 생각을 했으나 String 형식으로는 검색 기능을 사용할 수 없었습니다.

그러다가 문득 전에 Redis를 공부하면서 Redis의 Sorted Set이라는 데이터 타입이 생각났습니다.

Redis 공부 - 2

자동완성 시스템 구축? 어떻게 가능하지? 하면서 다시 복습을 해봤는데

ZRANGE로 구현할 수 있다는 사실을 알게 되었습니다.

ZRANGE를 사용하면 부하도 줄이고 매우 적절하게 기능을 구현할 수 있지만 기존 로직과는 약간 다르게 설계를 해야 하는 리스크가 있었지만 이건 꼭 개선해 보고 싶은 생각에 다시 설계해 보았습니다.

기존 로직과 새로운 로직의 차이점

기존 설계

FT.SEARCH를 이용해 DB에 autokwd에 있는 값과 유사한 JSON 데이터 전부를 가져오는 방식

문제점

유사한 데이터를 가져오는데 데이터 일부만 가져오는 것이 아닌 모든 데이터를 가져옵니다.

덕분에 기존 검색 기능에서 이미지와 각종 데이터를 바로 불러올 수 있어 UI&UX 면에서 직관성은 매우 좋다고 생각했으나...

이렇게 하면 비용적인 측면에서 매우 좋지 못하는 것을 알게 되었죠...

가져오는 JSON 데이터가 커지면 그만큼 대역폭과 데이터 송수신 시간이 늘어나기 때문에 추후 서버 부하 문제로 고생할 것 같은 미래가 떠올랐습니다. (라즈베리파이로 돌릴 예정이라 더욱... 성능 이슈가...)

새로운 설계

더 복잡해 보이는 건 기분 탓...이 아니다.

부분적으로 코드와 함께 설명을 해보자면...

MongoDB와 Redis에 데이터 저장

"example"이란 이름의 게임이 있다고 가정해 보겠습니다.

Redis에는 autocomplete라는 Sorted Set에 "example"를 추가합니다.

(예시로 example_1, example_2를 추가했습니다.)

MongoDB에는 수집한 게임 데이터를 저장합니다.

코드 구현

자동완성 키워드 불러오기

사용자는 겜린더에 "exam"이라는 텍스트만 입력했을 때를 가정하고 ZRANGE를 통해 "exam"이 포함된 텍스트를 찾게 됩니다.

이미지 하단에 Response body을 보면 전에 추가한 example, example_1, example_2까지 전부 나오게 됩니다.

코드 구현

유의할 점 Redis는 항상 결과물이 utf-8형식으로 콘솔에 출력이 됩니다. 영어로 검색할 때는 크게 문제가 되지 않지만 한국어는 제대로 검색되지 않는 문제가 발생하기 때문에 text를 utf-8로 인코딩을 먼저 거쳐야 합니다.

불러온 키워드로 검색하고 캐싱 하기

example를 사용자가 선택해 검색을 시도하면 바로 MongoDB를 통해 "example"을 검색합니다.

검색 결과를 Redis에 5분 동안 캐싱 하는 작업을 거쳐 최종적으로 사용자에게 결과를 보여주게 됩니다.

이렇게 캐싱을 하게 되면 순간적으로 검색어가 몰려 검색 시도가 발생할 때 MongoDB에 부하를 줄일 수 있다고 생각했습니다.

코드 구현

성능 개선 정리

1. 기존 Redis JSON은 DB와 자동완성 기능 둘 다 수행했기 때문에 큰 트래픽이 발생하면 두 기능 전부 작동이 안됄 수 있었던 부분 개선

2. JSON 데이터가 아닌 Sorted Set 형태로 저장해 용량 문제도 개선

3. 만약 위에서 제시한 Cache Warming 작업으로 시도했다면 똑같이 JSON을 Indexing 해서 결과물을 찾아야 했기 때문에 성능이나 비용적으로 비효율적

4. 캐싱 작업을 통해 MongoDB의 부하를 대폭 감소

5. Redis-Stack을 사용하지 않아도 된다! Redis-Stack에 대한 의존성 낮추기...

후기

뭔가 별거 없어 보이지만, Redis를 개인적으로 공부하고 공부한 내용을 잘 활용해서 문제를 해결했다는 점이 정말 뿌듯했습니다.

물론 로직이 바뀌면서 프론트도 다시 작업을 해야 하지만 무조건 개선해야 할 부분이었고 적절하게 트레이드오프 했다고 생각합니다.

다음 글은 최종적으로 백엔드를 어떻게 설계했고, 기존 백엔드와 성능 비교 테스트도 해보면서 정리하는 글을 작성할 예정입니다.

이 글에는 코드가 없습니다. 현재 문제점과 어떻게 해결해야 할지 고민한 글입니다.

다음 글에 전체적인 백엔드 구조와 함께 정리해서 올릴 예정입니다. 아마 다음 글이 최종 백엔드 설계가 아닐까 싶네요 :)

문제인식

현재 겜린더의 DB는 Redis로 개발하고 있다.

Redis는 In-Memory 방식이기 때문에 I/O 성능이 정말 빠르지만 반면에 외부요인으로 인해 데이터 손실이 발생할 수 있는 리스크가 존재한다.

그리고 개발과 함께 Redis를 공부하면서 문득 들었던 생각은

"많은 게임 관련 정보를 담아야 하는데 Redis의 메모리 용량으로 감당이 가능할 수 있을까?" 와

"라즈베리파이의 RAM 용량은 8GB인데 이 8GB를 전부다 사용하면 Swap이 발생할 테고 이러면 어차피 느려지지 않을까?" 라는 의문이 생겼다.

물론 위의 문제를 해결할 수 있는데, 데이터 손실 문제는 RDB, AOF 방식의 백업을 이용해 추후 외부적인 요인으로 데이터 손실이 발생했을 때 복구할 수 있다.

아니면 Redis Cloud를 사용하면 위의 의문들과 데이터 손실 걱정이 모두 해결된다. 하지만 매달 낼 돈이 없기도 하고...🥲 데이터와 트래픽이 늘어날수록 비용이 엄청나다는 글을 읽어버렸다.

LINE 알림 센터의 메인 스토리지를 Redis에서 MongoDB로 전환하기

기존에 LIN은 Redis를 메인 스토리지로 사용하면서 알림 관련 주요 데이터를 Redis에 저장해 서빙하고 있었습니다. 하지만 늘어가는 알림 종류와 스펙, 새 계정 유입 등의 영향으로 Redis 사용률이 지속적으로 증가하면서 결국 가용량의 80% 이상을 사용하는 상황까지 도달했습니다. 이에 따라 스왑 인/아웃(swap in/out)이 발생하면서 Redis 페일오버(failover) 또한 발생하는 상황이었고요.

내가 우려했던 상황이 그대로 LINE에서도 겪었던 문제였다.

그래서 Redis는 캐시 서버, MySQL 같은 디스크에 저장하는 DB를 사용하는 것이 적절하다고 판단했다.

*그럼 다시 만들어야겠네...? 거의 다 개발했는데... * 😂

문제 해결을 위한 조사

SQL를 제대로 다루지 못하는 나..

사실 난 SQL을 제대로 다루지 못한다. 그래서 갑작스럽게 RDB를 만들면 너무 조잡하고 효율적이지 못한 DB를 구축할 것 같았다.

실제로 MariaDB를 설치해 보고 대충 테이블을 만들었으나… 내가 제대로 만들고 있는지도 감이 잡히지 않았다.

그래서 정석으로 배우자!라는 기분으로 책을 하나 구매해서 개념 정리를 하고 있었다.

RDB vs Document?

겜린더는 JSON 형태로 불러오는데 지인이 차라리 RDB 말고 Document 형식의 MongoDB를 사용하는 것이 어떻겠냐고 조언을 해주었다.

사실 아주 예전에 겜린더를 처음 개발할 때 MongoDB를 사용해보고 싶었지만, 그 당시의 나에겐 너무 복잡하고 당장 앱 만들기도 힘들어서 보류했었는데

MongoDB의 자세한 스펙과 겜린더에 적절한지 판단하기 위해 이 기회에 제대로 조사해 보았다.

겜린더의 데이터 저장 방식

겜린더는 기본적으로 JSON 형식으로 저장을 한다.

일단 JSON으로 저장하는 가장 큰 이유가 서비스 확장 혹은 원하는 기능을 넣을 때 데이터 구조를 자유롭게 변경했어야 했기 때문에 JSON으로 저장했었다.

MongoDB의 BSON (Binary JSON)

MongoDB의 장점 중 BSON(Binary JSON)이 있었는데 JSON Document를 Binary로 인코딩한 포맷이다.

왜 Binary로 인코딩을 했는지 알아보았는데 기존 JSON으로 저장하면 텍스트 기반이라 구문 분석이 느리고 공간 효율성이 떨어졌기 때문에 컴퓨터가 읽기 좋게 Binary 포맷으로 저장해 구문 분석과 공간 효율 단점을 해결하였다.

공식 스펙 사이트가 있다. BSON Spec

이 3가지가 대표적인 특징이라는데

1. 경량화

   • 경량화는 모든 데이터 표현 형식에서 매우 중요한 요소

   • 특히 네트워크를 통해 사용되는 경우는 더욱 중요하다.

   • 그만큼 트래픽을 줄이고 공간을 최대한 활용할 수 있다는 의미이기 때문이다.

2. 횡단 가능

   • BSON은 쉽게 탐색할 수 있도록 설계되어 있다.

   • 기본 데이터 표현이 필요한 MongoDB에 있어서 필수적인 속성이다.

3. 효율적

   • BSON으로 인코딩하고 BSON에서 디코딩 하는 것이 C 데이터 유형을 사용하기 때문에 대부분의 언어에서 매우 빠르게 수행된다.

4. 이 밖에도

   • JSON 보다 더 많은 데이터 타입을 사용할 수 있다.

이런 특징을 보고 RDB보단 Document 방식에 자유롭게 데이터 구조를 변경할 수 있는 MongoDB를 사용하는 것이 더 좋다고 판단하였다.

데이터 모델링

Ref. (NHN Cloud) mongoDB Story 3: mongoDB 데이터 모델링

LINE+가 사내에 MongoDB를 도입한 이유

일단 데이터 모델링의 정확한 정의를 짚고 넘어가자

데이터 모델링이란 데이터를 정확하고 효율적으로 데이터베이스에 저장하기 위해 데이터 구조를 설계하는 과정을 의미한다.

RDB의 데이터 모델링은 Table 설계 후 Column을 설계하는 순서이지만, MongoDB는 Document를 설계 후 Collection을 설계하는 순서로 진행된다.

물론 그 이전에 요구사항과 필요한 데이터가 무엇인지 분석해야 하지만 이미 Redis로 설계하면서 필요한 데이터와 요구사항을 정립해뒀기 때문에 넘어간다.

Document 구조

MongoDB에는 Document 구조가 2가지 존재한다.

1. Embedding

관계를 갖는 데이터 집합을 단일 Document에 포함하여 저장하는 방식

장점

• 데이터 관리가 직관적이고 쿼리가 단순
• 조회 성능이 좋고 도큐먼트에 포함된 관련 데이터를 모두 업데이트할 수 있다.
• 구조가 단순해 반정규화 모델이다.

단점

• 구조가 단순하고 조회 성능이 좋아지지만 데이터 불일치가 발생할 수 있다.

• Document에 포함하는 데이터가 증가할수록 크기도 증가하여 디스크 I/O 시 성능 저하 및 최대 크기를 초과하면 저장이 불가능하다.

2. Referencing

Document에 관계를 갖는 다른 Document의 식별자를 참조키로 저장하여 필요시 애플리케이션에서 조인하는 방식

장점

• 데이터가 중복되지 않도록 업무 성격별로 컬렉션을 분리 후 참조하므로 데이터 불일치가 발생하지 않는 정규화 모델

• 적절한 업무 단위의 Collection으로 데이터가 분리되어 Embedded 방식 대비 Document의 크기 증가가 작다.

• 업무 요건 추가 및 변경으로 인한 도큐먼트 구조에 미치는 영향이 적다.

단점

• 참조가 많거나 대규모 Document를 조회하는 경우 애플리케이션에서 2차 쿼리로 인한 처리량 증가로 조회 성능이 저하될 수 있다.

• 데이터 중복으로 인한 일관성 문제는 해소되나 참조 정보를 정확하게 관리하지 않는 경우 참조 정보 소실에 의한 데이터 정합성 문제가 발생할 수 있다.

Collection

관계형 데이터베이스의 Table과 같은 개념으로 용도가 같거나 유사한 도큐먼트들의 그룹을 묶는 단위를 의미한다. 간단하게 특징만 정리해 보자

1. Normal Collection

• 가장 일반적으로 사용되는 컬렉션이다.

2. Capped Collection

• 고정된 크기를 갖는 Collection으로 높은 성능의 Logging 기능을 위해 설계되었다.

3. TTL Collection

• TTL Collection은 특정 시간이 경과한 도큐먼트를 자동으로 삭제하는 컬렉션으로 TTL 인덱스에 의해 지원되는 기능이다.

4. System Collection

• mongoDB 내부에서 사용되는 컬렉션으로 사용자가 지정하여 사용할 수 없다.

겜린더에는 어떤 Document 방식이 적합할까?

겜린더는 DB에 있는 게임 정보를 간단하고 빠르게 조회할 수 있는 기능이 핵심이다.

그렇다는 의미는 조회 성능이 중요하고 업데이트가 자주 발생하지 않는다. 어차피 데이터는 크롤러가 수집 후 DB에 계속 집어넣기 때문이다.

그래서 도달한 결론은 겜린더에는 사실 Embedded 방식이 매우 적합하다고 생각한다.

조사하면서 느낀 점

최근 Redis, SQL을 공부한 덕분에 MongoDB의 용어가 이해하기 쉽고 빠르게 넘어갈 수 있었다고 생각한다.

사실 MongoDB를 사용해야 할지 1달 가까이 Docs를 읽어가면서 고민을 했는데, 이유는 간단했다. 기존 개발한 것들을 싹 다 갈아엎어야 하기 때문이었다.

하지만 장기적으로 봤을 땐 무조건 적용해야 한다는 생각과 함께 MongoDB와 RDB을 같이 공부할 수 있었다.

조사와 설계는 다했으니 이제 직접 만들어보면서 겪은 문제점과 어떻게 해결했는지 메모하면서 개발을 이어가야겠다.

프론트도 UI를 엄청 고민하면서 제작 중이다. 변천사들이 좀 많아서 개발하는 과정에서 UI&UX가 어떻게 변화했는지 적어볼 예정이다.

Advanced Data Types

Index

1. Sets
2. Sorted Set
3. Bitmap
4. HyperLogLog

Sets

집합, 비정렬, 중복된 Member가 있을 수 없는 Data Type

모든 Member가 Integer인 경우 Set 메모리 공간을 줄일 수 있다.

Element의 총 개수는 set-max-intset-entries의 값 만큼 높을 수 있다.

Data filtering, Data grouping, Membership checking 등으로 활용할 수 있다.

Commands

SADD : 세트에 Member 추가, 이미 존재하는 Member는 추가할 수 없다.

SINTER : Set끼리 비교해서 겹치는 Member를 반환한다. (교집합)

SDIFF : A Set와 B Set끼리 비교해 중복되는 Member를 제외한 A Set의 Member를 반환한다. (차집합)

user:max:favorite_artists - user:hugo:favorite_artists

SUNION : 여러 개의 세트를 다같이 합쳐 출력한다. 단 Set의 특징처럼 중복된 Member는 하나의 Member로 출력한다. (합집합)

Arctic Monkeys는 user:max:favorite_artists, user:hugo:favorite_artists 둘 다 중복되는 Member이므로 하나로 합쳐 출력한다.

SRANDMEMBER : Set중 Random으로 Member를 반환한다.

SISMEMBER : Member가 Set에 존재 유무를 알 수 있다. 이 친구 우리 멤버 맞나요? Yes = 1, No = 2

SREM : 특정 Member 삭제

SREM으로 “Arctic Monkeys” 삭제 후 SISMEMBER로 존재하는지 확인

SCARD : Member 수 반환

SMEMBERS : Set에 있는 Member 모두 출력

Sorted Sets

단어 그대로 Sets에서 정렬된 Data Type

Sorted Set의 각 Element에는 연관된 점수가 존재한다.

Sorted Set은 Set보다 성능이 느리다.

실시간 대기 리스트 시스템, 게임 순위표 표시, 자동완성 시스템 구축등이 가능하다.

Commands

ZADD : 하나 이상의 Member를 추가하고 만약 이미 있는 Member의 경우 무시한다.

ZRANGE : 낮은 Score 순서대로 (오름차순) Member를 반환한다. -1은 마지막 Member

ZREVRANGE : ZRANGE의 Reverse 역순으로 Member를 반환

WITHSCORES : ZRANGE, ZREVRANGE 맨 마지막에 넣으면 스코어와 함께 반환된다.

ZREM : 특정 Member 삭제

ZSCORE : 특정 Member의 Score 반환

ZRANK : 특정 Member의 Rank 확인

ZREVRANK : ZRANK의 역순

Bitmaps

Bitmap은 실제 데이터 타입이 아닌 String 타입이다.

하지만 Bitmap이 String에 대한 비트 연산이라고 말할 수 있으며, String을 Bitmap으로 간주하는 명령어가 존재하기 때문에 Bitmap으로 간주한다고한다.

Bitmap index를 Offset으로 참조한다.

비트맵은 메모리 친화적이고 빠른 데이터 조회를 지원한다.

Commands

SETBIT : Bitmap offset에 값을 부여하는데 사용 1 또는 0만 허용된다.

GETBIT : Bitmap offset 입력하면 Bit리턴

BITCOUNT : offset이 1인 개수 출력

BITOP : 대상 키, 비트 연산 및 해당 연산에 적용하고 결과를 따로 새로운 키에 저장한다.

HyperLogLogs

실제 Data Type이 아니다.

Element수에 대한 근사치를 제공하기 위해 무작위화(Randomization)을 사용하는 알고리즘

실행속도 O(1)로만 동작하고 하나의 키당 아주 작은 메모리(최대 12KB)를 사용한다.

HyperLogLog 알고리즘은 확률적이기 때문에 100%의 정확도를 보장하지 않는다. (약 0.81%의 표준 오차를 가진다.)

이론상 셀 수 있는 셋의 개수 제한은 사실 없다.

고유 개수 카운팅을 수행하려면 카운팅하려는 세트의 항목 수에 비례하는 메모리량이 필요

HyperLogLog가 100%정확하진 않지만, 일부 상황에서 99.19%의 정확도가 나온다.

Commands

PFADD : 카디널리티가 변경된 경우 1을 반환하고 동일하게 유지되면 0을 반환

PFCOUNT : 하나 이상의 키를 매개 변수로 받고, 근사치 개수를 반환

PFMERGE : 대상키와 하나 이상의 HyperLogLog키를 매개변수로 받아야하고 병합 후 대상키에 저장

Redis Essential의 내용을 정리하였습니다. 번역해서 정리했기 때문에 오역이 있을 수 있습니다. 부족하거나 모르는 내용은 구글링을 통해 정리하였습니다.

Index

1. Redis 기본 개념
2. Redis Data Types
   1. Strings
   2. Lists
   3. Hashes

Redis 기본 개념

Redis? (REmote DIctionary Server)

고성능 Key-Value를 지원하는 NoSQL Data Structure 서버

유추해보자 Dictionary? 내가 아는 Dictionary는 파이썬의 Dictionary인데 Hash Table이라는 자료구조 기반으로 작동한다. Redis도 Hash Table를 활용해서 데이터를 저장하는 건가?

왜 고성능 Key-Value일까?

수 많은 데이터 타입을 지원한다. (기본 데이터 타입 : Chapter1, 더 많은 데이터 타입 : Chapter 2)

Redis의 모든 데이터는 메모리에 저장된다. (InMemory 저장 방식)

Memory는 Disk보다 속도가 빠르다. 기존 Disk 기반의 DB보다 훨씬 빠르지만 전원 공급이 끊어지면 Memory의 휘발성 특징 때문에 데이터가 전부 사라진다.

간단하게 짚어보는 CS 지식

• (CPU > Memory > Disk) 순으로 CPU가 가장 처리속도가 빠르고 Disk가 가장 느리다
• Memory 종류
• DRAM (Dynamic Random Access Memory)* : 우리가 흔히 쓰는 램이 DRAM이다. SRAM (Static RAM) : 용량이 작은 대신 속도가 DRAM보다 빠르다. CPU의 캐시메모리에 활용

Redis의 데이터는 우리가 쓰는 DRAM에 저장된다.

그럼 데이터 저장을 아예 못하는가?

아니다. Redis는 SnapShot(RDB), 혹은 모든 명령의 시퀀스가 포함된 파일(AOF)로 Disk에 저장할 수 있다. 추후 자세하게 알아보자 😃

그 외에도

Redis는 Key Expiration, Transactions, Publish, Subscribe 기능들을 가지고 있다.

Redis Data Types

Redis의 기본적인 데이터 타입들을 알아보자

Strings

우리가 아는 문자열이다. String은 값과 사용 된 명령에 따라 integer, float, text string, bitmap으로 작동할 수 있다.

String 값은 Text 혹은 Binary 데이터의 크기가 512MB를 초과할 수 없다.

Cache mechanisms(캐시 매커니즘)

Redis는 Text 혹은 Binary 데이터를 캐시로 이용할 수 있다.

Command

SET, GET, MSET, MGET으로 간단한 캐시 시스템 구현이 가능하다.

SET : Key - Value 추가

GET : Key를 대입하면 Value를 출력

MSET : 하나의 명령어로 여러개의 Key - Value 추가

MGET : 하나의 명령어로 여려개 Key를 입력해 각각의 Value를 출력

Example

Cache with Automatic expiration (캐시와 자동 만료)

특정 시간이 지나면 자동으로 만료되고 이는 데이터베이스 쿼리를 실행하는데 오랜 시간이 걸리고, 지정된 기간동안 캐시될 수 있는 경우 매우 유용하다.

Command

SETEX, EXPIRE, EXPIREAT으로 구현이 가능하다. TTL (Time To Live)

EXPIRE : Key에 만료시간 추가 (단위 : 초, TTL)

**EXPIREAT** : Key에 만료시간 추가 (단위 : Unix Timestamp)

~~SETEX : Deprecated 사용하지 않음~~

TTL (Time To Live) 표시 상태 양수 : 만료 시간이 주어진 상태 초 단위로 점점 감소한다.

-2 : 키가 만료되었거나, 존재하지 않는 경우

-1 : 키가 존재하지만 Expire을 설정하지 않은 경우

Example

Counting

간단하게 카운트를 구현할 수 있는 기능 좋은 예시로 조회수나 좋아요 같은 카운팅을 활용한 기능을 만들 수 있다.

Command (Atomic)

INCR : +1

DECR : -1

INCRBY : 원하는 값 증가

DECRBY : 원하는 값 감소

INCRBYFLOAT : 원하는 소수점 값 증가

DECRBYFLOAT : 원하는 소수점 값 감소

Atomic? 해당 명령을 수행하는 도중에 다른 명령이 끼어들 수 없는 명령

Example

SET counter 100

→ OK

INCR counter

→ (integer) 101

INCRBY counter 5

→ (integer) 106

DECR counter

→ (integer) 105

DECRBY counter 100

→ (integer) 5

GET counter

→ “5”

INCRBYFLOAT counter 2.4

→ “7.4”

Counting 명령어는 단일 명령으로만 처리할 수 있다.

MSET 같은 멀티작업으로 여러개의 Key를 동시에 카운팅을 할 수 없게 설계되어있단 의미

Example

만약 두 개 혹은 여러 개의 클라이언트가 동시에 INCR key 명령어를 실행할 경우 중복처리가 되지 않고 모두 처리할 수 있다.

Why?

“Redis is Single threaded” 레디스는 싱글 스레드로 동작하고 이 의미는 항상 하나의 명령을 수행하기 때문이다.

Lists

List는 Redis에서 매우 유연한 데이터 타입이다.

단순 수집, Stack, Queue 처럼 동작하게 만들 수 있다.

Blocking Command

Redis의 List에는 Blocking Command가 있다. 클라이언트가 비어있는 리스트에 Blocking Command를 실행할 때, 클라이언트는 List에 새로운 Element가 추가될 때까지 기다린다.

List 성능

Redis의 List는 Linked List 라서 리스트의 처음 또는 끝에서 Element의 추가 및 삭제는 항상 O(1) 즉 일정 시간의 성능을 가진다. Element 접근시간 : O(N) 첫번째 또는 마지막 Element 접근 시간 : O(1)

List Encoding

List 크기의 엘리먼트가 list-max-ziplist-entires 설정보다 작고, List 의 개별 바이트가 list-max-ziplist-value 설정보다 작으면 → ziplist로 최적화

List 크기의 엘리먼트가 list-max-ziplist-entires 설정보다 크거나, List 의 개별 엘리먼트의 바이트가 list-max-ziplist-value 설정보다 크면 → Linked List로 최적화

하지만

현재는 QuickList만 사용한다.

QuickList

• ziplist가 여러개 리스트로 되어 있는 형태
• ziplist의 마지막보다 찾는 인덱스가 다음에 있으면 다음 ziplist로 이동하는 형식으로 다수를 skip하여 리스트 탐색 시간을 줄였다고 한다…

Redis의 List는 최대 2^32 - 1의 Element를 가질 수 있다.

Command

LPUSH : List 처음에 Element 추가

RPUSH : List 마지막에 Element 추가

LLEN : List 길이 출력 (Length)

LINDEX : List의 Index 값을 볼 수 있음 (0부터 시작)

LRANGE : For문처럼 Index 범위를 지정해 지정된 모든 값을 출력한다. -1은 List의 마지막 Element

LPOP : 가장 처음 Element 삭제 후 출력

RPOP : 가장 마지막 Element 삭제 후 출력

BLPOP, BRPOP : LPOP과 RPOP을 Blocking하면서 기다린다. 구글링을 해보니 Message Queue처럼 활용이 가능하다고 한다. 나중에 예제를 만들어보자

Example

LPUSH, RPUSH

LLEN, LINDEX

LRANGE

LPOP, RPOP

BLPOP, BRPOP

strings Key에 Element가 있을 경우 → strings에 있는 “안녕하세요”를 POP 하였다.

strings Key가 없을 경우 → Executing command 라고 뜨고 만료시간 30000초가 넘기 전까지 대기한다.

만료시간 이내에 strings key에 “hello” Element를 추가 → 대기하던 blpop명령어가 동작해 출력

만료시간이 지나면 → (nil)을 출력

Hashes

메모리를 효율적으로 사용하고 데이터를 빠르게 찾도록 최적화 되어있다.

Field name 그리고 Value 둘 다 String으로 구성되어있다. 따라서 Hash는 문자열을 문자열로 매핑한다.

Hash는 내부적으로 ziplist와 Hash Table이 될 수 있다.

Ziplist & Hash Table

Ziplist? → 메모리 효율화에 목적을 둔 양쪽으로 연결된 리스트 (연결 리스트)

ziplist는 정수를 일련의 문자로 저장하지 않고 실제 정수의 값으로 저장한다.

ziplist는 메모리 최적화가 되어있어도 일정한 시간 내로 검색이 수행 되지는 않는다.

Hash Table에서는 일정한 시간 내로 검색은 되지만 메모리 최적화가 이루어지지 않는다.

Command

HSET, HMSET : Key “Field name” Value 형식으로 등록

HGET, HMGET : Key “Field name” 으로 조회

HINCR : +1

HINCRBY : 주어진 정수 값 증가

HDECR : -1

HDECRBY : 주어진 정수 값 감소

HINCRBYFLOAT, HDECRBYFLOAT : 주어진 정수 혹은 부동소수점 만큼 필드를 증가 감소 시킴.

Example

HSET, HMSET

HGET, HMGET

HINCRBY, HINCRBYFLOAT

프로젝트 기간 2022-10 ~ 2023-02

코드가 길어 Github에 업로드 합니다. Github Front-End Back-End Scraping Server

기술 스택 Front-End : React, Websocket Back-End : FastAPI, Redis, Docker WebScrapingServer : Websocket, Selenium, BeautifulSoup4, Python Request Language : Python, JavaScript

제작 의도

용산에서 한창 일할 때 Selenium으로 네이버 쇼핑 데이터 수집 봇을 만들어달라고 하셨던 사장님께서 새로운 무언가를 만들어 보고 싶으셨다 하셨고 해외직구 물품을 자동으로 검색해 주고 최저가를 한눈에 보이면 좋겠다는 아이디어를 주셨다.

처음 들었을 땐 네이버 쇼핑이 너무 압도적으로 최저가를 잘 찾아주어서 이게 가능할까 싶었는데 네이버 쇼핑뿐만 아니라 다양한 오픈마켓에서 일일이 발품 뛰는 내 모습을 보면서 이 과정을 자동으로 해줬으면 좋겠다는 생각으로 제작하게 되었다.

스카이스캐너 같은 최저가 항공권을 찾게 해주는 서비스처럼 만들어 보면 재밌을 것 같았다.

마침 겜린더로 FastAPI와 Redis를 공부도 했겠다, 내가 공부했던 기술들을 모두 이용하면 만들 수 있을 것 같아

새로운 사이드 프로젝트를 시작하게 되었다.

견적

어떤 기술을 사용해야 할지 스스로 견적을 맞춰보았다.

조건

1. 데이터 수집 시 무조건 백엔드 단에서 모든 것을 수행해야 한다.

2. 한 사람만 사이트를 사용하는 것이 아니기 때문에 데이터 수집 할 때 싱글 쓰레드나 프로세스가 아닌 멀티 쓰레드 혹은 프로세스를 이용해야 한다.

3. 검색어 자동 완성 기능이 무조건 있어야 한다.

4. 같은 시간대에 중복 검색어 방지를 위한 최소한의 방어 수단이 있어야 한다.

Front-End

1. React : 이번엔 최초로 웹 페이지를 만들어 보기로 했다. 겜린더를 통해 React Native를 해서 그나마 익숙한 React로 제작하는 것이 개발에 유리하다고 생각하였다.

2. WebSocket : DB에 만약 데이터가 없을 때 스크래핑 서버와 통신하기 위해서 WebSocket을 사용하였다. 당장 생각나는 게 웹 소켓밖에 없었다...

Back-End

1. Redis (Redis-Stack) : 겜린더에서도 사용했던 Redis를 활용할 예정이다. Memory 기반 DBMS라서 읽기, 쓰기 속도가 빠른 것도 있고 상대적으로 성능이 좋지 못한 하드웨어에서도 준수한 성능을 내줄 수 있을 것으로 생각했다.

2. Docker : 겜린더를 만들었을 때 Docker를 이용해서 Local로 돌리고 있는데 Container로 분리가 되어 사용이 편리할 것 같아 개발환경에선 Docker를 사용하게 되었다.

3. FastAPI : 이것도 겜린더에서 사용했었지만, 성능도 좋고 내가 현재 구현하려는 선에서 FastAPI가 역할을 훌륭하게 수행해 줄 것 같아 적용하였다.

Web Scraping Server

1. Selenium : 대부분의 웹 페이지가 동적 웹페이지여서 원활하게 데이터를 받아오려면 직접 브라우저를 조작해 가며 데이터를 수집해야 한다고 생각하였다.

2. BeautifulSoup4 : Selenium으로도 HTML 태그를 불러올 수 있지만 BS4가 좀 더 속도가 빠른 것 같아 같이 사용할 것이다.

3. WebSocket : Front-End에서 전송한 텍스트 데이터를 받아와서 스크래핑을 실행하게 해주는 역할을 할 것이다.

설계

기존에 노트에 단순하게 적었던 설계를 구체화시켰다. 만들다보니 MiddleWare에 각각의 기능들이 의존하는 형태가 마치... SOA(Service Oriented Architecture) 형식처럼 나오게 되었다.

설계한 부분을 하나씩 설명해 볼까 한다. (분명 복잡하지 않은데 플로우차트가 복잡하게 나왔다...)

Front-End

React 개발한 Front-End는 엄청 단순하게 검색, 결과 이렇게 2가지의 페이지로 구성하였다.

Main Page

단순하게 만들었고 아까 조건 중 3번 조건인 검색어 자동 완성 기능을 만들었다.

아마존의 자동 완성 기능을 이용하였는데 상품 검색 위주의 내 프로젝트에선 아마존의 자동 완성 기능은 매우 적합했다.

Result Page

결과 페이지는 국내, 해외 오픈마켓으로 구역을 나눠서 나오게 하였고, 배송비로 가격을 올리는 업체도 있어 배송비도 데이터 수집을 해 합산 가격이 나오도록 만들어 보았다.

Back-End

유효한 데이터가 있는지 판단

FastAPI를 통해 검색어를 받은 Redis에선 FT.Search를 통해 데이터가 있는지를 확인한다. 데이터가 있으면 JSON 형식의 Data를 출력하고 없으면 Null을 출력한다.

전체적인 설계 Flow 설명

1. Main Page에서 입력한 검색어를 FastAPI를 통해 GET 요청을 한다.
2. FastAPI에선 Redis DB에 접속 후 FT.SEARCH 명령어를 통해 검색어에 맞는 유효한 데이터가 있는지 확인한다.
3. 데이터가 있으면 JSON 형식의 Data 보내고 없으면 Null을 보내준다.
4. 데이터를 받은 FastAPI는 유효한 데이터면 Status Code 200, Null이면 404를 Return 할 수 있게 하였다.
5. Status Code 200인 경우 Result 페이지를 보여준다.

그럼 404면 어떻게 될까?

Web Scraping Server

WebSocket Listener(Recevier)

FrontEnd에서 보내준 검색어를 받아 Scraper Process Container에 새로운 Process를 추가한다.

Scraper Process

글 위에 작성했던 조건 중 2번 조건인

"한 사람만 사이트를 사용하는 것이 아니기 때문에 데이터 수집 할 때 싱글 스레드나 프로세스가 아닌 멀티 스레드 혹은 멀티 프로세스를 이용해야 한다."

부분을 해결하였다. Python의 Multiprocessing 라이브러리를 사용해 어떤 검색어가 들어와도 바로 스크래핑 봇을 실행해 다수의 일을 해결할 수 있게 만들었다.

테스트 영상.gif

멀티 스레드 vs 멀티 프로세스

어떤 걸 사용해야 할까?

스크래핑 서버는 성능보다 안정성이 중요하다는 점을 고려하였을 때 멀티 스레드보다는 메모리 공간과 CPU 시간을 더 많이 사용하지만 독립된 구조로 작동하여 안정성이 높은 멀티 프로세스를 선택하였고, 무엇보다 문제가 발생해도 다른 프로세스에 영향을 주지 않는다는 점이 안정성에 도움이 될 것 같아 선택하게되었다.

Scrape Data & Convert JSON

스크래핑한 데이터를 JSON 형식으로 변환하는 과정이다.

DB 저장

JSON Data를 POST 요청을 통해 FastAPI에선 Redis에 JSON.SET 명령어를 통해 DB에 저장하게 된다.

전제적인 Flow 설명

1. Front-End에서 WebSocket을 연결 후 검색어를 WebSocket Listener(Recevier)에 전송한다.

2. Scraper Process Container에 Process가 추가된다. (스크래핑 시작)

3. 스크랩한 데이터를 JSON 형식으로 변환한다.

4. JSON 형식의 데이터를 FastAPI를 통해 데이터를 전송한다 (POST)

5. FastAPI에선 JSON.SET 명령어를 통해 Redis DB에 데이터를 저장한다.

6. 저장한 데이터를 FrontEnd에서 다시 요청해 최종적으로 Status Code 200이 나오고 Reuslt 페이지가 나오게 된다.

결과

모든 조건을 해결했는가?

1. 데이터 수집 시 무조건 백엔드 단에서 모든 것을 수행해야 한다.

A. 데이터 수집과 저장 모두 백엔드 단에서 모든 걸 수행하게 되었다.

2. 한 사람만 사이트를 사용하는 것이 아니기 때문에 데이터 수집 할 때 싱글 쓰레드나 프로세스가 아닌 멀티 쓰레드 혹은 프로세스를 이용해야 한다.

Python의 MultiProcessing을 이용해 해결하였다.

3. 검색어 자동 완성 기능이 무조건 있어야 한다.

아마존의 자동 완성 기능을 이용해 해결하였다.

4. 같은 시간대에 중복 검색어 방지를 위한 최소한의 방어 수단이 있어야 한다.

여러 사용자가 같은 검색어를 입력하게 되면 중복된 데이터를 수집할 수 있는 시나리오를 예상했고 상품 가격이 실시간으로 급변하지 않기 때문에 수집한 데이터는 6시간 동안 유지되게 제작하였다.

즉, DB에 데이터가 있어도 6시간이 지나면 다시 데이터 수집을 해서 새로운 데이터로 유지할 수 있게 만들었다.

Redis의 Expire 기능을 사용하려 했으나 Expire을 사용하면 데이터가 아예 사라지기 때문에 refreshtime이란 키를 만들어 현재 시각과 비교해 데이터 수집의 판단 여부를 결정하게 했다.

아쉬운 점

1. 세상엔 다양한 상품명과 모델명 상품 코드들이 있어서 검색 정확도가 높지 못해 아쉬웠다.

이 부분은 ChatGPT를 활용해서 사전 필터링을 가져봤으면 좋았을 것 같은데 비용을 쓸 여력이 없어 패스 했다. 물론 정확도를 높이기 위해 슬라이딩 윈도우, 코사인 유사도 같은 문자열 유사도 AI나 알고리즘을 찾아봤지만 적용하지 못했었다.

2. 마감 기간이 정해져 있어 제대로 FrontEnd에 신경 쓰지 못한 점이 아쉬웠다.

2022년 10월에 시작한 프로젝트였는데 2023년 2월 초까지 프로토타입이 나와야 한다고 하셔서 Front-End에 신경 쓰지 못해 아쉬웠다.

3. 앱으로 제작하면 더 실용적이었을 것 같아 아쉬웠다.

이걸 앱으로 만들면 조금 더 실용적으로 만들 수 있었을 것 같다...

4. 여전히 부족한 기초 실력...

이런 사이드 프로젝트를 하면 할수록 기초가 정말 매우 부족하다는 것을 다시 한번 체감하게 된다. 특히 Redis 기초부터 제대로 공부해 보고 싶단 생각이 많이 들었다.

마무리

이번 사이드 프로젝트는 내가 원하는 기술로 전체적인 서비스를 만들어 볼 수 있어서 많이 배울 점이 많았던 프로젝트이다.

여기서 배운 것들을 실제로 겜린더에 적용한 것도 있고 여러모로 백엔드에 대한 이해도를 많이 높일 수 있었다.

조금 더 나은 개발자가 되기 위해 단순히 사이드 프로젝트만 진행하는 것이 아닌 꾸준하게 컴퓨터 사이언스를 공부해야겠다는 생각을 가지면서 글을 마친다.

사용한 라이브러리

(가격 수집 스크래핑 봇) Selenium, BeautifulSoup4, Pandas, df2gspread (가격 수정 프로그램) Tkinter, request

글을 시작하기 전 소스 코드는 공개를 못한다는 점 양해 부탁드립니다. 😂

제작의도

한창 용산에 있는 노트북 판매 업체에서 알바했을 때 느꼈던 점은 세상에는 내가 생각한 것보다 정말 많은 노트북들이 판매되고 있다.

그리고 그 노트북들의 가격은 하루가 다르게 가격이 조정되는데 그 가격을 일일이 사람이 수기로 수집해서 관리할 수 있을까라는 생각과 함께 실제로 사장님이 가격을 정리하는 모습을 보았을 때, 수많은 제품 중에서 추려내어 가격 시세를 파악하고 최저가를 찾아내고 구글 시트에 정리하고 실제로 판매하는 스토어에 가격 반영까지 45시간 이상이 걸렸었다. _(이것도 주력 제품 기준으로 걸렸던 시간이었다.)~~_

이런 과정을 줄이기 위해 사장님께서 데이터 수집 프로그램 제작을 부탁하셨다.

견적을 짜보자

1. 기존 사장님께서 관리하셨던 구글 시트의 불편한 점을 정리 후 기존 형식에서 크게 벗어나지 않고 개선해야 한다.

2. 데이터 수집과 수집한 데이터를 정리해야 하기 때문에 Selenium, BeautifulSoup4, Pandas 공부를 해야 한다.

3. 수집한 데이터를 제조사별로 시트를 분리해 추후 데이터에 문제가 생겼을 때 별도로 쉽게 대응할 수 있도록 설계해야 한다.

4. 24시간 프로그램을 돌릴 수 있게 하여 별도의 조작 없이도 연속적으로 수집해야 한다.

이렇게 총 4가지의 중요 포인트를 가지고 개발을 하게 되었고 결과를 말하자면

결과

1. 다나와의 모든 노트북 제품 가격을 관리할 수 있게 되었다. (이론상으로 모든 제품을 수집할 수 있지만 수집 속도를 위해 주요 회사의 제품만 수집하게 되었다.)

2. 판매 스토어에 가격 수정을 반자동화 시켜 일일이 가격을 직접 수집하고 판매 스토어 반영까지 45시간 걸렸던 시간을 11.5시간으로 단축하였다.

3. 판매 스토어에 빠른 가격 수정을 위해 기존 사용했던 쇼핑몰 통합 관리 솔루션에서 제공한 API를 활용해 가격 수정 프로그램을 별도로 제작하여 가격 수정의 편의성을 높였다.

시스템 구조

Selenium으로 만든 수집 프로그램

Python의 Selenium을 활용해 데이터 수집 봇을 만들었다. 이유는 당연하게도 요즘은 한 번에 모든 데이터를 받아와서 보여주는 정적 웹(Static Web Page) 형식이 아닌 동적 웹 (Dynamic Web Page) 형식이 많기 때문이다.

특히나 다나와에서 각 제조사 별로 데이터를 수집하기 위해서 체크 박스에 표시를 해야 하는 과정이 필요해 Selenium을 활용해 만들어야 했다.

그리고 추가로 11번가 사이트도 스크래핑을 하였는데

다나와, 11번가 이렇게 스크래핑 프로그램을 나눠서 분류하여 버그가 발생할 때 수정하기 편하게 만들었다.

해당 프로그램은 24시간 프로그램을 실행해 데이터를 수집했으며

백업 데이터 저장 기능까지 있었다.

사실 백업 기능은 df2gspread의 버그인데 가끔씩 정해진 시트가 아닌 자체적으로 새로운 시트를 만들어 데이터를 저장하는 현상이 있었다. 하지만 이런 버그 덕분에 백업데이터를 모아둘 수 있어서 가끔씩 데이터가 제대로 구글 시트에 반영이 되지 않을 때 데이터를 가져와 복구할 수 있었다.

수집한 데이터 저장하기

다나와 수집 결과물 하단에 보면 각 제조사 별로 정리되어 있는 모습을 볼 수 있다.

11번가 수집 결과물 검색어가 좀 부정확해서 상품번호로도 추후 통합 관리 시트에 불러올 수 있게 만들었다.

통합 관리 시트...

통합 관리 시트는 아쉽게도 공개가 조금 힘들다... 엄청 간단하게 MATCH 함수로 다나와 그리고 11번가의 시트를 참조할 수 있게 만들었다. 이렇게 한 이유는 통합 관리 시트에 정보들이 너무 많아 분산이 필요했고 관리하기에 훨씬 용이할 것 같아 이렇게 구조를 만들었다.

가격 수정 프로그램

사용자는 자동으로 가격이 수정된 통합 관리 시트를 엑셀로 저장 후 가격 수정 프로그램만 실행하면 끝난다.

프로그램은 Python의 Tkinter로 만들었다.

사용 방법은 간단하다. 통합 관리 시트를 엑셀로 저장해 가격 수정을 하고 싶은 시트를 선택하고, 값을 전송할 열을 작성 후 API 전송 버튼을 누르면 가격이 일괄적으로 수정하기 시작한다.

API 서버에 문제가 없다면 제품 하나 당 1~3초의 시간이 소요된다.

검증

아무래도 "수집한 데이터가 정확한 가?!"에 대해 의문을 품는 건 당연하고 약 1개월 동안 사장님께서 직접 사용하고 피드백을 주면서 데이터 검증도 끝마쳤다.

아쉬운 점

개인적으로 아쉬웠던 점은 데이터 수집 방지를 위한 게 아닌 쇼핑몰 상위권에 노출을 많이 하기 위해 보통 상품명에 여러 키워드를 많이 넣어두는데 이것 때문에 제품명 추출이 많이 어려웠다. 차선책으로 상품코드를 참조할 수 있게 수정을 하긴 했지만... 아쉬운 건 아쉽다... 요즘은 Chat-GPT 같은 친구를 활용해서 제품명만 따로 뽑아내주거나 별도로 추출하는 알고리즘이나 AI를 만들어보고 싶었으나... 다른 것들을 만드느라 정신없었다.

마무리

이렇게 사용자가 직접 제품 가격을 하나하나 수집하는 것을 봇을 제작해 업무시간을 확 줄였다는 것에 매우 뿌듯했다. 이래서 다들 자동화를 하는구나 싶고 개인적으로 Selenium 과 Python 내장 함수에 대해 많이 알 게 되었다.

간만에 겜린더 개발 일지를 작성해 보는데 이번에는 백엔드를 중심으로 작업이 되었고 필수 기능들이 대부분 구현이 되었기 때문에 이렇게 정리한다.

사실 노션에 정리해둔거 여기다가 백업한다

겜린더의 이번 목표는 단순 사이드 프로젝트에서 멈추는 게 아닌 진짜 서비스를 목표로 제작하는 것이 목표다.

사실 이전에도 서비스를 목표로 만들었고 열심히 업데이트를 했지만 항상 맨날 언급한 컨텐츠 문제, 그리고 스케일업이 불가능한 서버 구조로 인해 결국 지금은 서버를 그냥 내려놓은 상태다.

오늘의 글은 차례대로 문제점을 적고 어떻게 해결했는지 공유하기 위한 글이라고 생각하면 된다.

그리고 혹시나 구조와 코드를 보면서 더 좋은 방법이 있다면 언제든 댓글을 달아주면 감사하겠습니다. ☺️

무조건 개선 및 추가해야 할 목록

1. 달력페이지

문제점 세일 기간 및 게임 정보 빈약

겜린더는 기본적으로 게임이 언제 출시하는지 달력으로 정리해 보여주는 게 핵심이다.

그런데 세일 기간 정보는 가지고 있어도 달력에 제대로 표현하지 못했고, 직관적이지 못해 따로 영역을 만들어서 표시할 예정이고

게임 정보가 빈약한 이유는 여태까지 내 손으로 직접 손수 직접 검색해 일일이 추가했던 구조라 정보가 매우 부족했다.

이러한 문제점들이 결국 백엔드를 새롭게 만들게 된 계기가 되었다.

2. 백엔드 재설계 및 최적화

문제점 기존 백엔드는 모든 날짜 정보를 불러와서 달력이 갑자기 초기화되는 현상 발생

이전에 겜린더를 만들고 서비스하면서 위 현상 때문에

"아... 이거 잘 못 만들었다..."

라는 생각을 들게 만들었다.

- 기존 구조를 보자

ㅋㅋㅋㅋㅋㅋㅋㅋㅋ.... 진짜 충격적인 구조

이때는 json-server를 이용해 만들었는데

전혀 DB와 백엔드 자체에 이해도가 없었던 때라 야매로 만들자~ 느낌으로 했다가 이렇게 다시 제작하게 되었다.

예전에는 그냥 통신만 되어도 오오오오! 하면서 신났을 때라 나중에 스케일업까지는 전혀 고려해 보지 못했던 상황이었다...

*구조를 하나씩 쪼개서 설명하자면 *

이미지에 보면 datelist라는 Array가 보일 텐데 이걸 펼치면...

지옥이 펼쳐진다... 저 데이터가 달력에는 12월 7일을 보면 .으로 표시가 된다.

이 리스트 들을 앱을 실행할 때마다 항상 GET 요청을 통해 달력에 표시가 되는 구조인데

이러면 처음 정보가 없을 땐 괜찮지만 나중에 데이터가 쌓이면 대참사가 발생한다.

왜냐면 원하지도 않는 날짜까지 전부다 불러오는 구조라 추후에 서비스를 운영할 때 서버가 불필요한 자원을 소비하기 때문이다.

실제로 저렇게 불러와서 달력을 옆으로 넘기면 오버플로우인지 뭔지는 모르겠지만 다시 초기화가 되어버리는 치명적인 버그가 있었다.. (디버깅 로그에도 안 뜬다...)

게임 정보가 들어있는 Array...

해당 날짜를 이제 누르면 localhost:1234/2021-03-02 이런 식으로 요청을 해 게임 데이터를 가져오는 구조이다

겉보기엔 괜찮아보이지만... 이건 엄청난 노가다를 요구하는 구조가 되어버린다. 한마디로 비효율적인 구조...

- 해결하기 위한 방안

이를 위해 Redis와 FastAPI를 사용하였다. Redis는 DB의 역할을 하고 FastAPI는 RESTAPI 형식으로 GET과 POST 요청 등을 처리하기 위한 미들웨어이다.

게임을 실제로 등록을 하게되면 Redis에선 JSON형식으로 DB에 저장되면서

이런 식으로 DB에 정리가 된다. 저장 형식을 보면 game:test indie 3 로 저장이 되는데 게임 이름으로 저장해서 게임 정보 관리에 더 용이하도록 했다.

그럼 달력에서 게임 정보는 어떻게 불러옴?

이라고 물어본다면 Redis에는 Search 기능이 있어서 Query 검색으로 불러올 수 있게 만들었다.

예를 들어 2022-08-05일에 출시하는 게임을 찾고 싶으면 Redis가 JSON 데이터에서 "date" key를 참조하여 2022-08-05와 일치하는 것을 찾아내 표시하는 방식이다.

또 예를 들어 2022년 8월 게임 정보만 달력에 표시가 되었으면 좋겠다고 가정하면 JSON 데이터에서 "yearmonth" key를 참조하여

이런 식으로 표시가 된다.

이렇게 만들어서 데이터관리와 접근에 훨씬 더 용이해진 것 같다. 애초에 처음부터 이렇게 만드는 게 맞다고 생각한다...

이번 백엔드 작업을 통해서 스케일업이 상당히 편해졌다. 진짜로

자세하게 코드로 보여주고 싶지만... 노출되면 좀 곤란할 것 같아 코드는 생략하겠다...

3. 상세 페이지 개선

가독성이 높게 리뉴얼 및 “Push Notification(FCM)”기능 추가

사실 FCM은 이전에 2.0에서 추가했던 내용이라 겜린더 2.0.0 개발 후기를 참고하면 좋을 것 같다.

핵심은 상세페이지를 개선하는 것이 목표인데 이건 아직 구체적인 계획이 없다... UI를 개선해야 할지... 어떤 것을 도입해야 할지 좀 더 고민해 보고 있다.

4. S3(Object Storage)사용

겜린더 등록 페이지에서 추후 활용 사실 예전 서비스 출시 때부터 겜린더에 자체적으로 등록신청을 해주시는 분들을 위한 이미지 서버가 존재했는데

이걸 제대로 활용하지 못했고 이번에 아예 등록 페이지를 자체적으로 만들어 이미지를 업로드 시 서버에 스토리지에 저장하도록 계획 중에 있다.

5. 신청페이지 및 심사 대시보드 제작

React로 제작하고 있고 나름 Figma를 활용해 디자인해봤지만 디자인 하나도 모르는 사람이라 정말 빈약하다. 그래서 요즘 비핸스와 핀터레스트를 미친 듯이 보고있다...(뭐라도 봐야할 것 같아서..)

그 외 개발 도중 이슈와 솔루션들

1. 쿼리 검색 기능 넣을 시 “-”, “.” 같은 특수 문자 String으로 변환 문제

Q. Redis에선 symbol로 인식한다 어떻게 해결해야 할까..?

A. 파이썬(FastAPI)에서 replace()를 이용해 “-” → “\-” 식으로 백슬래시를 넣으면 string으로 인식한다. 참고내용 Redis query_syntax

2. 날짜 조회 시 TEXT or TAG로 할지 선택

TEXT, TAG가 뭔지는 Redis ft.create를 참고해 주세요

TAG로 하면 월/날짜 나눠야 한다 그래서 date와 yearmonth를 만들어 월별 날짜 조회는 yearmonth로 참조하고

yearmonth를 참조해서 나온 결과 값

특정 날짜 조회는 date를 참조하게 만들었다.

TEXT로 index를 만들었는데 연관된 것 까지 검색되고 원하는 결과값이 나오질 않았다.

하지만 TEXT를 잘 이용하여 자동완성 기능도 만들었다 게임 검색 기능에 유용하게 사용될 예정이다.

3. LIMIT 문제

이거 때문에 반 년 이상을 지체한 것 같은데 너무 간단해서 허무하다...

Docs를 제대로 안 읽어본 잘 못이긴 하다... (근데 Docs 내용 너무 방대하고 많다..) Redis search 부분 참고

LIMIT가 뭐냐면 Redis는 FT.SEARCH로 검색 시 표시할 수 있는 데이터의 량을 정할 수가 있다.

Redis CLI에선 LIMIT로 그것을 조절할 수 있다.

하지만 redis-py를 사용할 땐 Query('검색 키워드').paging(0, 10) 이런 형식으로 사용하는데

paging이 LIMIT와 같은 역할을 한다.

저거 해결하려고 참 많이 찾아봤었는데 그냥 Docs 스크롤 하다가 발견해 너무 허무했었다...

4. Docker → Redis-Stack VS Ubuntu Server → Redis-Stack

일단 지금 로컬 테스트로는 docker를 통해서 사용하고 있지만 추후 서비스할 때는 우분투 서버에 직접 Redis-Stack를 설치할 까 한다..

하드웨어는 역시 언제나 라즈베리파이로 할 예정이다

마무리

오래 걸리긴 했지만 백엔드의 기반을 다져놓은 것 같아 뿌듯하다.

드디어 프론트엔드에 집중할 수 있게 되었고, 본격적으로 스케일업을 해도 충분히 대응할 수 있는 구조를 가지게 되어서 앞으로 개발이 많이 수월할 것 같다는 생각과 함께 글을 마치겠다.

2022년 나는 무엇을 했고 어떤 것을 배웠는가

한 번 정리를 해볼 겸 이렇게 글을 작성해 본다.

두서없이 작성해서 분량이 길어요...

1. Project MOD (현 메이플스토리 월드) 공모전

친구의 권유로 2021년 11월부터 같이 시작했던 공모전이다. 한창 메타버스라는 분야가 엄청 핫한 트렌드로 올라올 때라 친구가 권유해 줬을 때 재밌을 것 같아서 하게 되었다.

프로젝트 런웨이의 컨셉은 사용자가 직접 코디를 만들면서 전시도 하고 추후엔 전시된 코디 중 맘에 드는 것을 살 수 있는 시스템을 구축하려고 했으나, 아쉽게도 개발할 당시엔 코디를 만들 수 있는 스프라이트 에디터 같은 것도 없었던 시기여서 단순하게 이미지만 불러와 맵을 장식했던 것이 너무 아쉬웠던 프로젝트였다.

그래서 이미지를 자세히 보면 코디 신청 주소도 적어두었고, 심지어 두 번째 이미지에는 접근성 좋게 QR코드도 만들었다.

신청받은 코디 이미지를 직접 받아서 에디터에 업로드해서 올리려고 했지만 아무래도 접근성도 그렇고 기능이 부족해서 그런가... 반응은 별로 없었다.. 😂

그래도 친구가 맵 디자인과 코디를 진짜 이쁘게 꾸며서 그런지 댓글 반응은 상당히 좋았다 사실상 친구가 캐리 했다고 봐도 무방...

물론 내 개인적으론 LUA 스크립트를 사용하는 게 처음이라 그런지 열심히 레퍼런스나 독스를 읽어가면서 하드코딩을 했던 기억이 생생하다...

정 모르겠으면 커뮤니티에 직접 물어보거나 몇 없는 유튜브 강좌를 보면서 했는데도 제대로 못했던 모습 그리고 레퍼런스에 의존할 수밖에 없는 모습을 보면서

실력이 정말 부족한 나 자신을 되돌아볼 수 있었다.

2. 용산 알바

나는 컴퓨터 조립이나 기계에 관심이 많아서 예전부터 용산에서 한 번 알바를 해보고 싶다는 생각이 있었다.

그러다가 우연히 용산에서 알바를 할 수 있는 기회가 주어졌고, 그냥 단순한 조립 알바이니깐 몇 개월만 하고 그만 둘 생각이었다.

하지만 알바 사장님하고 대화를 하면서 사실 나를 고용한 이유가 자신이 프로그래머도 찾고 있었는데 마침 내가 프로그래밍을 할 줄 아는 것 같아 고용했다고 한다.

그러고는 "XX씨 혹시 크롤링(스크랩핑) 프로그램 만들어볼래요?"라고 물어보셨고 거기서 나는 이건 기회다 싶어 무조건 "네, 만들어볼게요" 라고 말했다.

사실 이걸 주변 사람들한테 말했을 당시엔 "아니 무슨 알바생한테 코딩까지 시키려고 하냐... 돈은 더 줘?"라는 말을 들었다.

겜린더의 게임 수집을 일일이 수작업으로 찾아서 타이핑을 하는 게 너무 힘들었던 나에게 이 제안은 매우 나쁘지 않았던 제안이었다.

마침 알바 사장님도 스크랩핑 프로그램이 필요하다고 하고, 나도 겜린더에 사용해야 할 스크랩핑 프로그램을 만들어야 하는데, 돈도 벌면서 관련 스터디도 할 수 있다는 생각도 들면서

우연이라기엔 타이밍과 시기가 딱 맞물려서 그런가.. 그냥 덥석 물어버렸다

덕분에 셀레니움, BS4, Pandas 등 많은 라이브러리와 데이터 수집하고 엑셀로 이쁘게 정리하는 방법들을 공부했다. 그리고 사장님이 이런 정리된 데이터를 어떻게 활용해야 하는지, 사업적으로 활용할 수 있는 방법들을 알려주셔서 개인적으론 지금도 하고 있는 이 알바가 상당히 재밌다. (배울게 많다 진짜)

알바를 다닌 지 거의 9개월이 되어가는 지금 요즘은 알바생이 아니라 거의 스타트업처럼 신규 플랫폼 프로젝트도 같이 준비하면서 겜린더에 적용하려고 했던 Redis나 FastAPI 같은 것들을 이용해 서버도 만들고

React를 활용해 홈페이지도 만들면서 느리지만 꾸준하게 성장하고 있는 것 같아 뿌듯하다. 겜린더를 React Native로 개발해 React도 좀 할 수 있지 않을까? 했는데... 뭔가 같으면서도 다른... 느낌을 많이 받았다.

그리고 겜린더 개발할 때는 Hook이 아니라 Class Component로 개발했었는데 React Hook이 더 쉽다고 얼핏 들었던 것 같은데... 내가 멍청해서 그런가 아직 공부가 더 필요해 보인다...

얼른 만들어서 공개하고 싶지만 혼자 개발해서 그런지 느릿느릿하다.. 심지어 아직 할 게 너무 많다.. DDNS, https(SSL)인증서 발급, 도메인 구매 등...

이렇게 공부한 것들을 기반으로 겜린더도 슬금슬금 다시 리뉴얼 하려고 개발 중이다.

3. 네이버 제페토 월드 공모전

이건 이전에 작성한 글이 있다. 뒤늦게 작성하는 제페토 월드 공모전 후기

후기 글은 약간 우수상을 받은 게 신기해서 우리가 어떻게 우수상을 받을 수 있었는가에 대한 분석이었다면 여기엔 내 개인적인 생각을 적어보려고 한다.

사실 메이플 공모전의 후유증이 있어서 그런가.. 이 공모전을 참가하는 게 좀 두려웠었다. 또 제대로 1인분도 못하고 광탈할 것 같은 느낌과 함께 같이하는 친구들에게 너무 미안하기만 할 것 같아서 같이 해야 하나...? 하는 생각을 많이 했었다.

그래서 내가 할 수 있는 역량이 되는가...하면서 제페토 깃허브에도 들어가보고 타입스크립트도 보면서 어느 정도 내 스스로 자기 객관화를 했던 것 같다.

그래도 최소한 1인분은 할 수 있겠다!라는 판단과 함께 참여하게 되었고 내가 이 공모전 기간에 할 수 있는 것과 없는 것을 잘 판단해 코딩을 한 것 같다.

물론 중간에 여러 개인적인 사건들이 참 많이 발생해서 심리적으로 힘들었지만...

제출 2주일 전에는 매일 카페에 모여서 10시간 이상 앉아서 작업했던 게 지금 생각해 보면 대단하면서도 재밌었다 ㅋㅋㅋ

한 가지 아쉬운 게 있었는데 제페토 월드 인 게임 안에서 일반 아이템(포션이나 버프 등..)을 팔 수 있는 IWP 기능이 있었지만 코디(옷, 신발 등) 아이템은 아직 팔 수가 없다고 해서 너무 아쉬웠다..

4. 겜린더 이야기

4-1 겜린더 상표권 등록 완료

21년 3월에 신청했던 겜린더의 상표권 심사가 22년 6월에 드디어 끝이 났다.

꼭 돈을 많이 벌어서 우선 심사권으로 꼭 신청해야겠다는 생각밖에 들지 않았다... :)

4-2 겜린더 리뉴얼

이 정도면 겜린더 서비스 안 하고 접은 거 아니냐?!

라는 말이 나올 수 있지만... 사실 꾸준하게 겜린더를 리뉴얼 하고 있었다. 어떤식으로 리뉴얼을 하고 있는지 정리하자면..

Front 리액트 네이티브로 여전히 개발 중이지만 최근에 코드가 너무 더럽게 짜여 있고 코드를 어떻게 해야 할지 애매해서 그냥 새롭게 다시 짜기로 했다. 기존 프로젝트에는 state가 너무 많아서 관리가 점점 힘들어졌었는데 이를 위해 Redux를 사용할 명분이 생겨버려 요즘 Redux를 공부 중에 있다.

Middleware FastAPI를 활용해 API 형식으로 정보를 받을 수 있게 만들고 추후에는 다른 곳에서도 활용할 수 있게 이 정보를 오픈할 예정이다.

Back Redis를 이용해서 DB를 새롭게 다시 구축 중인데 용산에서 알바하면서 Redis를 계속 공부하다 보니 DB를 다시 만들어야 할 것 같은 기분이 든다... 하지만 금방 만들 수 있을 것 같다.

게임 등록 페이지 현재 React로 게임 등록 페이지를 만들고 있다. 기존 구글 시트로 서비스를 했으나, 일일이 수동으로 입력해서 또 업로드를 해야 했던 게 현실이라 이번 기회에 등록 페이지와 그에 맞는 대시보드까지 만들려고 계획 중에 있다.

2022년 마무리

곧 2022년이 끝나간다. 2023년에는 어떤 일들이 생길지 정말 기대되고, 내년이야말로 내가 2022년에 해왔던 작업들이 전부 완성되어 제대로 된 서비스를 할 수 있는 한 해가 될 수 있도록 노력해야겠다.

할 거면 끝장을 봐야 하는 내 성격이 성장을 더디게 할 수도 있지만 개인적으론 끝까지 해보고 실패해 봐야 원인 분석을 정확하게 하고 다음에는 똑같은 실수를 반복하지 않았다...

대신 조급하게만 하지 않았으면 좋겠다... 제발...

내년에도 열심히 삽질해 보고 치이면서 살아봐야겠다.

2022년 회고록 끝

3월에 친구의 권유로 시작하고 7월에 마무리된 제페토 월드 공모전 후기를 뒤늦게 작성해 봅니다.

수상작 발표 링크

아트 2, 클라이언트 1 이런 조합으로 진행했고

처음 제출할 때 저희 팀 모두 다 같이 "이걸 제출했네...?" 하면서 신기했었고 우수상을 받을 때도 너무 기쁘기도 했지만 우수상까지 받을 줄은 사실 생각도 못 했었습니다.

왜냐하면 팀원 모두가 여러 가지로 많이 미숙하다고 판단했고 그냥 참가에 의미를 두자라고 생각했습니다.

하지만 우수상을 받았기 때문에 "우리가 어떻게 해서 우수상을 받을 수 있었을까?" 에 대해 여러 번 고민을 했었는데

딱 3가지 이유가 있었다고 생각합니다. 이번 글은 그 이유를 작성해 보려고 합니다.

1. 주어진 일에 끝까지 책임진다.

일단 같이 참여했던 친구들이 책임감이 매우 좋은 친구들이었습니다.

사실 이건 너무 당연한 게 아닌가?라고 생각할 수 있지만 생각보다 제 주변엔 많이 없더라고요..

물론 제 자신도 엄청 책임감이 강하다고 생각하진 않지만 주어진 일에 항상 최선을 다하려고 노력합니다.

2. 타인의 의견 수렴을 잘하고 자기 객관화를 잘한다.

기획을 했을 당시 프로그래밍을 맡은 저를 제외한 나머지 아트 2명은 게임을 하지 않았던 친구들이었고

심지어 저는 자바스크립트는 겜린더 개발 때문에 조금 했었지만 타입스크립트는 정말 처음이었기 때문에 사실 기술적인 이슈도 상당히 많았던 팀이었습니다.

그래서 처음 기획을 할 때 많은 의견 충돌이 있을까 봐 걱정을 많이 했습니다.

하지만

서로 못하는 부분은 확실하게 말하면서 타협점을 찾아나갔던 모습이 이번 공모전에 입상을 할 수 있던 큰 이유라고 생각합니다.

3. 꾸준하게 스터디를 했다.

이번에 같이 아트를 한 친구들도 모델링을 배우긴 했지만 아직 미숙하기도 했고 유니티를 아예 몰랐다고 해도 무방했고

제 자신도 유니티를 제대로 사용해 보지도 않았던 상태였습니다.

아트 친구들은 학교에서 동아리나 스터디 모임으로 배우고

저는 제페토 깃허브 커뮤니티를 찾아보면서 수많은 레퍼런스들을 공부하고 바로바로 적용해 보는 방식으로 스터디를 꾸준하게 병행한 덕분에 좋은 결과물을 얻을 수 있었다고 생각합니다.

공모전을 마무리하고 들었던 생각...

다른 이유도 있겠지만 이 3가지 이유가 제일 우수상까지 받을 수 있었던 큰 원동력이라고 생각하고

제페토 공모전을 하면서 이번에 같이 한 친구들하고 만약 다른 프로젝트를 해도 정말 재밌게 할 수 있겠다는 생각이 많이 들었습니다.