728x90
면접
인생 첫 면접을 봤다.
엄청 긴장했고, 같이 들어오신 인사담당자분께서도 여러번 너무 긴장하지 않아도 된다고 하신만큼 티가 났던 것같다.
준비를 한다고 했지만 그래도 부족한게 많았고, 부족한건 확실하게 면접에서 문제가 됐다.
그래도 그런 문제점을 그냥 있구나 하고 넘어가는게 아니라 적어 놓고 다시 보고 하면 도움이 될 것이라고 생각해서 이렇게 적어본다.
Set
정의
- set은 균형 이진 트리(일반적으로 레드-블랙 트리)로 구현된 정렬된 집합이다.
특징
- 정렬된 순서 : 원소들이 자동으로 정렬된 상태로 저장된다.
- 탐색 시간 : 삽입, 삭제 검색 연산의 평균 시간 복잡도는 O(log n)이다.
- 순회 : 원소들을 순회할 때 항상 정렬된 순서로 순회한다.
사용 예
- 데이터가 항상 정렬된 상태로 필요할 때
- 특정 범위의 원소들을 빠르게 찾을 때
- 게임 내 순위 리스트
- 게임 내에서 플레이어 점수 또는 순위 리스트를 관리할 때, 점수를 정렬된 상태로 유지해야 할 때 사용된다.
- 자동으로 정렬된 상태로 저장되기 때문에, 순위를 빠르게 검색하거나 특정 범위의 순위를 쉽게 추출할 수 있다.
- 퀘스트 트래킹
- 플레이어가 완료한 퀘스트를 추적하고, 완료한 순서대로 정렬하여 저장할 대 유용하다.
- 완료한 퀘스트를 정렬된 상태로 저장하여, 다음 퀘스트 진행을 쉽게 파악할 수 있다.
- 이벤트 스케줄링
- 게임 내 이벤트나 타이머를 관리할 때, 이벤트 발생 시간을 기준으로 정렬된 리스트를 유지해야 할 때 사용된다.
- 이벤트 발생 시간을 기준으로 자동 정렬되어, 다음 이벤트를 빠르게 확인하고 처리할 수 있다.
Unordered_Set
정의
- unordered_set은 해시 테이블로 구현된 집합이다.
특징
- 정렬되지 않은 순서 : 원소들이 특정 순서 없이 저장된다.
- 탐색 시간 : 삽입, 삭제, 검색 연산의 평균 시간 복잡도는 O(1)이다.
- 순회 : 원소들을 순회할 때 순서가 정렬되지 않는다.
사용 예
- 원소들의 순서가 중요하지 않고, 빠른 삽입, 삭제, 검색이 필요할 때
- 충돌 감지
- 게임 내에서 충돌 감지를 할 때, 충돌 대상 오브젝트의 ID를 빠르게 검색해야 할 경우 유용하다.
- 해시 테이블 기반이므로 충돌 대상 오브젝트를 빠르게 확인할 수 있다.
- 상태 추적
- 플레이어 상태나 오브젝트 상태를 추적할 때, 특정 상태가 존재하는지 여부를 빠르게 확인해야 할 때 사용된다.
- 상태 변경 시 빠르게 삽입 및 삭제할 수 있으며, 현재 상태를 O(1) 시간 복잡도로 확인할 수 있다.
- 아이템 인벤토리
- 플레이어의 인벤토리에서 아이템의 고유 ID를 관리할 때 유용하다.
- 특정 아이템의 존재 여부를 빠르게 확인하고, 인벤토리에 아이템을 추가하거나 제거할 때 효율적이다.
- 유니크 엔티티 관리
- 게임 내에서 유일해야 하는 엔티티를 관리할 때 사용된다.
- 유니크한 엔티티를 빠르게 추가, 삭제, 검색할 수 있어 게임 로직을 효율적으로 관리할 수 있다.
DevOps
- DevOps는 소프트웨어 개발(Development)과 IT 운영(Operations)의 합성어로, 이 두 영역을 결합하여 소프트웨어 개발과 운영 간의 협업을 촉진하고, 소프트웨어 배포 주기를 단축하며, 품질을 향상 시키는 방법론 및 문화이다.
DevOps의 주요 개념
- 협업과 소통
- 개발팀과 운영팀 간의 원활한 협업을 촉진하여, 각 팀이 서로의 목표와 도전에 대해 더 잘 이해하고 협력할 수 있도록 한다.
- 자동화
- 빌드, 테스트, 배포, 모니터링 등 소프트웨어 개발 및 운영의 많은 부분을 자동화하여 효율성을 높인다.
- 지속적 통합(Continuous Integration, CI)
- 개발자가 자주 소스 코드를 통합하여, 각 통합된 코드가 자동으로 빌드 및 테스트되도록 한다. 이는 버그를 초기에 발견하고 해결하는 데 도움을 준다.
- 지속적 배포(Continuous Deployment, CD)
- 변경된 코드가 자동으로 프로덕션 환경에 배포되도록 하여, 새로운 기능과 수정 사항이 빠르게 사용자에게 전달될 수 있게 한다.
- 모니터링과 로그 분석
- 애플리케이션과 인프라의 상태를 지속적으로 모니터링 하고, 로그를 분석하여 문제를 조기에 발견하고 해결한다.
DevOps의 원칙
- 문화(Culture)
- 협업과 소통을 중심으로 한 조직 문화를 구축하여, 개발팀과 운영팀 간의 장벽을 허물고, 공동의 목표를 추구한다.
- 자동화(Automation)
- 가능한 모든 반복적인 작업을 자동화하여, 인간의 실수를 줄이고, 효율성을 높인다.
- 측정(Measurement)
- 시스템 성능, 애플리케이션 상태, 개발 및 배포 주기 등을 측정하여, 데이터를 기반으로 의사 결정을 내린다.
- 공유(Sharing)
- 도구, 코드, 정보를 팀 간에 공유하여, 지식의 흐름을 원활하게 하고, 협업을 촉진한다.
DevOps 도구
- 버전 관리 도구
- Git, Subversion 등
- 지속적 통합/지속적 배포 도구
- Jenkins, CircleCI, Travis CI, GitLab CI/CD 등
- 컨테이너화 도구
- Docker, Kubernetes 등
- 구성 관리 도구
- Ansible, Chef, Puppet 등
- 모니터링 도구
- Prometheus, Grafana, Nagios, Splunk
- 클라우드 서비스
- AWS, Azure, Google Cloud Platform 등
DevOps의 장점
- 빠른 배포 주기
- 자동화와 지속적 통합/배포를 통해 소프트웨어를 더 빠르고 자주 배포할 수 있다.
- 높은 품질
- 자동화된 테스트와 모니터링을 통해 코드 품질을 높이고, 버그를 조기에 발견하여 해결할 수 있다.
- 높은 협업
- 개발팀과 운영팀 간의 협업을 촉진하여, 더 나은 커뮤니케이션과 문제 해결을 가능하게 한다.
- 효율성 향상
- 반복적인 작업을 자동화하여, 개발자와 운영자의 생산성을 높인다.
- 신뢰성 향상
- 자동화된 프로세스와 지속적인 모니터링을 통해 시스템의 신뢰성을 높이고, 문제 발생 시 빠르게 대응할 수 있다.
포트폴리오_슬레이어즈 관련
패킷이 뭉쳐서 들어오는 문제 쪽 관련
- 구분자 프레이밍에 문제가 있다.
- 구분자의 충돌 가능성
- 데이터 내용에 구분자와 동일한 패턴이 포함될 수 있다. 이 경우, 실제 데이터와 구분자를 혼동할 수 있어 데이터 패킷의 경계가 잘못 인식될 수 있다.
- 이 문제를 해결하기 위해 데이터를 전송하기 전에 구분자를 이스케이핑(escaping)하거나, 데이터 인코딩 방식을 변경해야 하는데, 이는 추가적인 처리 비용을 초래한다.
- 비효율성
- 구분자가 포함된 데이터를 처리할 때, 구분자를 찾아야 하므로 문자열 검색 연산이 필요하다. 이는 데이터 처리 속도를 저하시킬 수 있다.
- 특히 큰 데이터 스트림에서 구분자를 검색하는 것은 성능 저하를 일으킬 수 있다.
- 구분자 선택의 어려움
- 데이터 스트림에서 사용되지 않는 구분자를 선택하는 것이 어렵다. 특히 다양한 종류의 데이터를 처리해야 하는 경우, 모든 데이터에 대해 안전한 구분자를 선택하기는 어렵다.
- 구분자가 너무 자주 나타나지 않도록 해야 하며, 이는 데이터의 특성에 따라 복잡할 수 있다.
- 데이터 크기 제한
- 일부 구분자 기반 프로토콜은 구분자를 찾을 때 메모리나 버퍼 크기에 제한을 받을 수 있다.
- 에러 처리의 복잡성
- 구분자가 잘못 인식되거나 손실되면, 전체 데이터 패킷을 재구성하는 것이 어려울 수 있다.
- 구분자가 손실된 경우, 데이터의 나머지 부분을 재조립하는 것이 어려울 수 있다.
- 구분자의 충돌 가능성
- 헤더와 바디 프로트콜
- 명확한 프레이밍
- 헤더를 통해 메시지의 길이와 형식을 명확히 정의함으로써, 데이터의 시작과 끝을 쉽게 구분할 수 있다.
- 이는 패킷 경계 문제를 해결하고, 데이터가 혼합되지 않도록 한다.
- 유연한 데이터 처리
- 헤더에 다양한 메타데이터를 포함할 수 있어, 데이터의 처리 방법을 유연하게 제어할 수 있다.
- 예를 들어, 메시지 타입, 버전, 길이, 압축 여불 등을 헤더에 포함할 수 있다.
- 에러 검출과 복구
- 헤더에 체크섬이나 CRC 같은 오류 검출 코드를 포함하여 데이터 전송 중 발생할 수 있는 오류를 검출하고 복구할 수 있다.
- 데이터 무결성을 높일 수 있다.
- 확장성
- 프로토콜이 새로운 기능이나 요구 사항을 지원해야 할 때, 헤더를 확장하여 새로운 필드를 추가할 수 있다.
- 이는 기존 프로토콜의 호환성을 유지하면서도 기능을 확장할 수 있게 한다.
- 명확한 프레이밍
동기화 문제 관련
- 내가 했던 방식_초당 일정 개수의 패킷을 보내는 방식
- 장점
- 예측 가능성
- 패킷 전송 주기가 일정하여 네트워크 부하를 예측하고 관리하기 쉽다.
- 간단한 구현
- 주기적인 타이머를 사용하여 패킷을 전송하므로 구현이 상대적으로 간단하다.
- 예측 가능성
- 단점
- 비효율성
- 실제로 상태 변화가 없는 경우에도 불필요한 패킷이 전송될 수 있어 네트워크 부하가 증가할 수 있다.
- 반응성 저하
- 입력 이벤트가 발생한 순간과 패킷 전송 사이에 지연이 발생할 수 있어, 반응성이 떨어질 수 있다.
- 비효율성
- 장점
- 입력 이벤트에 따라 패킷을 보내고, 그 사이를 보간하는 방식
- 장점
- 높은 반응성
- 입력 이벤트 발생 시 즉시 패킷을 전송하므로, 반응성이 높아진다.
- 효율성
- 상태 변화가 있을 때만 패킷을 전송하므로, 네트워크 부하를 줄일 수 있다.
- 높은 반응성
- 단점
- 복잡한 구현
- 보간 로직을 추가해야 하며, 클라이언트 간의 시간 동기화가 필요할 수 있다.
- 변동하는 네트워크 부하
- 입력 이벤트가 집중될 경우, 일시적으로 네트워크 부하가 증가할 수 있다.
- 복잡한 구현
- 장점
- 하이브리드 접근
- 구현
- 주기적 상태 업데이트
- 일정한 간격으로 주기적인 상태 업데이트 패킷을 전송하여, 기본적인 동기화를 유지한다.
- 이벤트 기반 패킷 전송
- 주요 입력 이벤트(예 : 가속, 브레이크, 방향 전환)가 발생할 때마다 즉시 패킷을 전송한다.
- 보간 및 예측
- 클라이언트에서는 주기적인 패킷과 이벤트 기반 패킷을 사용하여 상태를 업데이트하고, 그 사이를 보간한다.
- 예측 기법을 사용하여 패킷 사이의 움직임을 예측하고, 패킷이 도착했을 때 이를 조정한다.
- 주기적 상태 업데이트
- 구현
나에게 하는 피드백
- 준비를 좀 더 잘해가자.
- 회사 정보
- 만든 게임의 정보
- 뉴스
- 투자
- 인재상 등등..
- CS, OS 지식 관련
- 내가 적은 이력서에 관한 내용들에 대해서.
- 회사 정보
728x90
'Study > TIL(Today I Learned)' 카테고리의 다른 글
24.06.20 알고리즘 (2) | 2024.06.20 |
---|---|
24.06.19 네트워크 (2) | 2024.06.19 |
24.06.17 서버 (5) | 2024.06.17 |
24.06.16 CS (1) | 2024.06.17 |
24.06.15 CS (0) | 2024.06.17 |