축구팀 관리 프로젝트 21일차 - 추천 알고리즘? 백엔드로 가기 위해선

축구팀 관리 프로젝트 21일차 - 추천 알고리즘? 백엔드로 가기 위해선

 

 

중간발표 하루 앞둔 날, 튜터님과의 면담을 가졌습니다. 이번 면담 전에는 각자 기본 기능 외에 더욱 심화적인 기술을 구상해오라는 숙제가 있었습니다. 필자가 가지고간 기술 소개와 그에 따른 사전조사 및 고민에 대해 아래 기록해두려 합니다.

 

 

축구 포메이션 화면을 보다가

 

며칠 전부터 심화적인 기술에 대해 고민을 했었습니다. 주제가 축구팀 관리이다 보니 대용량 데이터 처리는 프로젝트 흐름상 어려웠습니다. 게다가 필자가 맡은 부분은 경기 예약, 경기 일정, 경기 포메이션 설정 이었습니다. 이에 관하여 심화적인 기술을 고민해보았습니다.

 

축구에 관한 대용량 데이터를 만들기 위해 해외 api를 가져와서 데이터 처리를 해볼까. 

 

해외 축구 정보 API 사용 방법 및 실행 예제

[Python] 파이썬으로 축구 스탯 가져오기 part.

 

이렇게 구상해도 주제가 '조기축구회'라는 한정적인 타겟팅으로 기획되어 있기 때문에 연관성이 없어보였습니다. 그래서 전술 관련해서 페이지를 보다가 추천 포메이션을 만들면 좋겠다고 생각했습니다.

 

그렇게 바로 자료를 조사해보았습니다. 추천을 위한 알고리즘은 다양한 기업에서 관심 가지고 있는 기능이었습니다. 각종 쇼핑몰이나 OTT 등 사용자의 수요가 대거 필요한 거의 모든 기업에서는 사용자 맞춤 알고리즘을 위한 추천 알고리즘 활용은 필수적이었습니다.

 

초개인화 시대, 추천 알고리즘 경쟁력이 기업의 미래를 좌우한다 | KT Enterprise

 

게다가 작년에는 트위터를 인수한 일론머스크가 트위터 추천 알고리즘을 깃허브에 올리는 사건도 있었습니다. 매우 복잡한 구성의 코드로 스칼라로 쓰여진 코드들이었습니다.

 

GitHub - twitter/the-algorithm: Source code for Twitter's Recommendation Algorithm

 

한 눈에 이 알고리즘을 이해하는게 어려워 아래 영상들을 보며 트위터가 사용하는 추천 알고리즘에 대해 분석하였습니다.

 

 

 

 

필자가 파악한 트위터의 추천 알고리즘 흐름은 다음과 같았습니다.

 

팔로우 추천 서비스에 대한 이해 (추천 알고리즘)

트위터 팔로우 추천 서비스
트위터의 팔로우 추천 서비스(FRS, Follow Recommendations Service)는 사용자에게 맞춤형 계정 추천을 제공하는 강력한 추천 엔진입니다. 이 서비스는 다양한 트위터 제품 인터페이스에 걸쳐 누구를 팔로우할지(WTF, Who-To-Follow)에 대한 모듈 추천을 지원하며, 사용자가 향후 관심을 가질 수 있는 계정의 트윗(퓨처그래프 트윗)을 추천함으로써 사용자 경험을 향상시킵니다.

디자인
FRS는 신규 사용자 경험(NUX), 광고, 퓨처그래프 트윗 등 다양한 사용 사례를 지원하기 위해 맞춤 설계되었습니다. 각 사용 사례는 고유한 디스플레이 위치 식별자를 특징으로 합니다. 추천 절차는 디스플레이 위치에 따라 맞춤화되며, 후보 생성, 순위 결정, 필터링, 변환 등의 공통 및 고급 단계를 포함합니다.

후보 생성
FRS는 다양한 사용자 신호와 알고리즘을 사용하여 모든 트위터 계정에서 후보를 식별합니다.

필터링
계정 후보 생성 후, FRS는 품질과 건전성을 향상시키기 위해 다양한 필터링 로직을 적용합니다. 필터링은 순위 결정 단계 전후에 적용될 수 있으며, 일반적으로 순위 결정 후에 더 무거운 필터링 로직이 적용됩니다.

순위 결정
FRS는 기계 학습(ML) 및 경험적 규칙 기반의 후보 순위 결정을 사용합니다. ML 순위 결정자의 경우, ML 특성은 미리 가져온 후(<사용자, 후보> 쌍마다 DataRecord를 구성하여 별도의 ML 예측 서비스로 전송됩니다. ML 예측 서비스는 사용자가 추천을 받아 팔로우하고 긍정적인 참여를 할 확률을 나타내는 예측 점수를 반환합니다.

변환
후보 시퀀스는 중복 제거, 소셜 증명(예: "XX 사용자가 팔로우함") 첨부, 추적 토큰 추가 등 필요한 변환을 거칩니다. 축소 FRS는 후보군을 특정 크기로 줄여 최종적으로 사용자에게 가장 관련성 높고 매력적인 후보만을 제시합니다.

이러한 종합적인 절차를 구현하고 다양한 사용 사례에 맞게 조정함으로써, FRS는 트위터 사용자에게 맞춤형 추천을 제공하며 그들의 전반적인 경험을 향상시키고 플랫폼 내에서 의미 있는 연결을 촉진합니다.

 

말은 쉬웠지만 이를 구체화 하기 위한 기획 모델과 기술스택들을 정리하며 실현 가능성에 대해 고민이 더욱 생기기 시작했습니다.

 

축구 전술 추천 알고리즘 기획 모델
축구 전술 추천 알고리즘은 사용자의 선호도, 팀의 특성, 경기 데이터 등 다양한 데이터를 분석하여 사용자에게 최적의 축구 전술을 추천하는 시스템입니다. 다음은 그 구상 모델입니다:

1. 데이터 수집 및 처리
사용자 프로필: 사용자의 선호 팀, 선호하는 축구 스타일(공격적, 수비적), 이전에 선택한 전술 등을 포함합니다.
팀 데이터: 팀의 현재 폼, 선수 명단, 선수들의 능력치, 부상 및 징계 상황 등을 포함합니다.
경기 데이터: 최근 경기의 통계, 승리 패턴, 상대 팀과의 역대 전적 등을 포함합니다.

2. 후보 전술 생성
다양한 축구 전술 데이터베이스에서 후보 전술을 선정합니다. 예를 들어, 4-4-2, 4-3-3, 3-5-2 등 다양한 포메이션과 전략을 고려합니다.

3. 필터링 및 순위 결정
필터링: 사용자의 프로필과 팀의 현재 상황에 부합하지 않는 전술을 필터링합니다. 예를 들어, 수비적인 전술을 선호하는 사용자에게 공격적인 전술을 제외시킵니다.순위 결정: 머신러닝 알고리즘을 사용하여 각 후보 전술의 성공 확률을 예측하고, 이를 기반으로 순위를 매깁니다. 선수들의 능력치, 경기 데이터, 상대 팀과의 매치업 등을 특성으로 활용합니다.

4. 개인화된 추천 제공
사용자에게 맞춤형 전술 추천을 제공합니다. 추천 시, 각 전술의 장단점, 사용자의 선호도, 팀의 현재 상태를 고려한 설명을 함께 제공하여 사용자가 정보에 기반한 결정을 내릴 수 있도록 합니다.

5. 피드백 및 지속적 학습
사용자로부터의 피드백을 수집하여 추천 알고리즘의 정확도를 지속적으로 개선합니다. 예를 들어, 추천받은 전술을 사용한 후의 경기 결과, 사용자의 만족도 등을 분석합니다.

기술 스택
데이터 처리: Apache Spark, Hadoop 등대용량 데이터 처리를 위한 기술
머신러닝: TensorFlow, PyTorch 등 머신러닝 프레임워크
백엔드: Node.js, Flask 등 API 개발을 위한 프레임워크
데이터베이스: PostgreSQL, MongoDB 등

 

알고리즘 이해하는 데에도 어려움이 있지만 기술 스택을 정리하며, 추천 알고리즘을 위해 백엔드 뿐만 아니라 머신러닝까지 활용해야 하는 점이 골치 아팠습니다. 약 2주 정도 남은 기간 동안 할 수 있을지에 대해 확신이 서지 않았습니다. 한참을 고민하다가 문득 문제의 본질에 대해 다시 생각해봤습니다. 

 

 

백엔드 개발자의 핵심 요구 기술

 

"백엔드 개발자로서 가장 우선적으로 경험해봐야할 기술이 무엇이지"

 

이 생각이 들고나서야 튜터님이 조언해주셨던 두가지 키워드가 떠올랐습니다. '서버 안정성'과 '고가용성'

 

가비아 라이브러리

 

대표적인 클라우딩 서비스인 aws가 떠올랐습니다. AWS의 다양한 서비스들을 찾아보며 이 서비스의 장점에 대해 정리해 볼 수 있었습니다. 

 

AWS(Amazon Web Services)는 서버 안정성과 고가용성을 달성하기 위해 다양한 서비스를 제공합니다. 이러한 서비스들을 활용함으로써 얻을 수 있는 장점들은 다음과 같습니다:

1. 탄력성과 확장성
Auto Scaling: 자동으로 서버 인스턴스의 수를 조절하여 변동하는 트래픽에 대응할 수 있습니다. 이를 통해 사용자 요구에 따라 자원을 즉시 확장하거나 축소할 수 있어 비용 효율성과 성능을 동시에 관리할 수 있습니다.
Elastic Load Balancing (ELB): 여러 서버 인스턴스에 걸쳐 트래픽을 자동으로 분산시키며, 서버 부하를 효율적으로 관리합니다. 이는 어플리케이션의 가용성과 내결함성을 높이는 데 기여합니다.

2. 데이터 내구성과 복구
Amazon S3: 높은 내구성을 자랑하는 스토리지 서비스로, 데이터를 안전하게 저장하고 언제든지 접근할 수 있습니다. 여러 가용 영역에 데이터를 복제하여 재해 복구 대비에 유리합니다.
Amazon RDS: 백업, 패치 관리, 복제를 자동으로 처리하는 관리형 데이터베이스 서비스입니다. 높은 가용성과 데이터 복구를 위한 다중 AZ(Availability Zone) 배포 옵션을 제공합니다.

3. 보안 및 컴플라이언스
Amazon VPC: 사용자 정의 가상 네트워크를 생성하여 AWS 리소스를 격리하고, 보안 그룹과 네트워크 ACL을 통해 접근을 제어할 수 있습니다.
AWS Identity and Access Management (IAM): 사용자, 그룹, 역할에 대한 세밀한 접근 권한을 관리할 수 있어, 최소 권한 원칙을 적용하여 보안을 강화할 수 있습니다.

4. 비용 최적화
Amazon EC2 Reserved Instances: 사전에 예약함으로써 비용을 크게 절감할 수 있으며, 장기적인 리소스 사용 계획에 따라 비용을 예측 가능하게 관리할 수 있습니다.AWS Cost Explorer: 사용 패턴을 분석하고 비용 절감 기회를 식별할 수 있는 도구를 제공합니다.

5. 글로벌 배포
Amazon CloudFront: 전 세계에 분산된 엣지 로케이션을 통해 콘텐츠를 빠르게 제공하는 CDN 서비스입니다. 사용자에게 낮은 지연시간으로 콘텐츠를 전달하여 사용자 경험을 향상시킵니다.

AWS 글로벌 인프라: 전 세계 다양한 지역과 가용 영역에 걸쳐 서비스를 배포할 수 있어, 글로벌 사용자 기반에 서비스를 제공하는 데 유리합니다.

AWS의 이러한 서비스들을 활용함으로써 개발자는 서버의 안정성과 고가용성을 달성하는 동시에, 보안, 비용 효율성, 그리고 글로벌 사용자에 대한 빠른 콘텐츠 제공과 같은 다양한 이점을 누릴 수 있습니다.

 

자료를 찾아보며 백엔드 개발자의 가장 중요한 스킬은 서버를 안정적으로 운용할 수 있는 것이라 정리할 수 있었습니다. 서버 비용을 최소한으로 하면서 최대의 트래픽에도 서버 운용에 차질없게 하는 것. 이 점이 가장 필수적으로 해야할 경험이라 생각하였습니다. 그래서 대용량 트래픽 경험을 어떻게 이루어낼지 대략적인 시나리오를 구상해봤습니다.

 

 

대용량 트래픽 처리 시나리오

1단계: 인프라 분석 및 계획
현재 상황 파악: 현재 인프라의 용량, 트래픽 패턴 분석, 피크 타임 동안의 서버 부하 확인목표 설정: 트래픽 증가 예측, 목표 트래픽 용량 설정, SLA(Service Level Agreement) 기준 명시

2단계: 인프라 최적화 및 확장
자동 확장 설정: 클라우드 서비스의 자동 확장 기능을 활용해 트래픽 변동에 따라 자동으로 리소스를 조절
로드 밸런싱: 여러 서버에 걸쳐 트래픽을 분산시키기 위한 로드 밸런서 구성
캐싱 전략 수립: 자주 접근하는 데이터나 정적 콘텐츠를 캐시하여 응답 시간 단축 및 서버 부하 감소

3단계: 데이터베이스 관리
데이터베이스 분산: 샤딩, 리플리케이션 등을 통해 데이터베이스 부하 분산
읽기/쓰기 분리: 읽기 전용 복제본을 사용하여 읽기 요청 처리 효율성 증가

4단계: 코드 및 리소스 최적화
애플리케이션 최적화: 비효율적인 코드 리팩토링, 비동기 처리 적용
리소스 압축 및 최적화: 이미지, CSS, JavaScript 파일 압축 및 최적화

5단계: 보안 강화 및 비상 대비
DDoS 대비책 마련: DDoS 공격 방어 솔루션 구축
백업 및 재해 복구 계획 수립: 정기적인 백업 및 재해 복구 시나리오 테스트

6단계: 모니터링 및 알림 시스템 구축
성능 모니터링 도구 활용: CPU, 메모리 사용량, 응답 시간 등 모니터링
알림 시스템 설정: 문제 발생 시 신속한 대응을 위한 알림 시스템 구축

7단계: 지속적인 성능 평가 및 개선
트래픽 분석 및 평가: 정기적인 트래픽 및 성능 분석을 통해 인프라 상태 평가
기술 동향 및 솔루션 업데이트: 최신 기술 동향을 모니터링하고 필요시 새로운 솔루션 도입

 

대략적인 시나리오는 이렇게 구상해봤고 좀 더 가시적인 계획은 더 조사를 하며 만들어야할 것 같습니다. 최종 프로젝트에서 서비스 구현에만 몰두하고 있다보니 더 중요한 '경험'을 간과하고 있었던 것 같습니다. 최대한 이번 프로젝트에서 경험해야겠다는게 목표고 설령 팀 프로젝트 진행상 구현이 어렵다면 개인으로라도 경험해야할 것 같습니다.

 

개인적으로 캠프 교육과정 중 강의로 제공해준건 있지만 이런 경험을 캠프에서 교육과정으로 공식적으로 알려주었으면 더 유익하지 않았을까 하는 생각이 듭니다.

 

▼ 이전 진행한 프로젝트들 ▼

 

NestJS mailer 활용하여 이메일 보내는 방법

 

내일배움캠프 NestJS 프로젝트 코드리뷰 - 온라인 공연 예매 서비스