범데이의 개발노트 📄

Target API 34, IL2CPP, GPGS, Firebase 연동 과정에서 발생한 문제 해결 과정 Unity Android 프로젝트를 진행하던 중, Target API 레벨을 34로 올리면서 발생한 빌드 오류, 런타임 예외, 패키지 충돌 문제들을 해결한 과정을 정리한다. Google Play Games Plugin과 Firebase를 함께 사용하는 환경에서 발생하는 여러가지 문제점과 그 해결법을 공유한다. 프로젝트 환경Unity Editor 2021.3.16f1 → 빌드 오류 후 2021.3.45f1로 업그레이드Scripting Backend: IL2CPPTarget Architecture: ARM64Target API Level: 33 → 34Firebase Unity SDK (Authent..

정수형 데이터를 다루다 보면, 값이 특정 범위를 초과하거나 부족해 오버플로우(overflow) 또는 언더플로우(underflow)가 발생하는 경우가 있다. 이는 많은 프로그래밍 언어에서 발생할 수 있는 일반적인 형상이므로, 이 글에서는 그 개념을 설명하고 C# 예제를 통해 이해를 돕고자 한다. 1. 오버플로우란?오버플로우란 고정된 크기의 정수형 타입이 표현할 수 있는 최대값을 초과했을 때, 그 값이 다시 최소값으로 순환되어 저장되는 현상이다. 이와 반대로 최솟값 아래로 감소할 경우 언더플로우가 발생한다.대부분의 정수형 타입은 내부적으로 2의 보수 방식으로 표현되기 때문에, 이런 순환 현상이 자연스럽게 발생한다. 이러한 순환은 대부분의 언어에서 명시적 오류 없이 조용히 발생한다. 이를 흔히 "조용한 순환..

journalctl은 로그를 확인하는 도구지만, 실제 로그가 어떻게 저장되고 얼마나 오래 보관되는지는 systemd의 저널 데몬 설정(systemd-journald)에 의해 결정된다. 이번 글에서는 로그가 저장되는 경로, 설정 방법, 그리고 보관 기간을 조절하는 방법까지 함께 살펴본다. 1. 로그 저장 위치는 어디인가?journal 로그는 /etc/systemd/journald.conf 파일의 Storage 옵션에 따라 저장 위치가 달라진다.Storage 설정 값로그 저장 위치설명volatile/run/log/journal메모리 저장. 재부팅 시 로그 소멸persistent/var/log/journal디스크 저장. 재부팅 후에도 유지auto (기본값)자동 감지/var/log/journal 폴더가 있으면..

Linux 시스템에서는 다양한 로그가 발생한다. 과거에는 syslog, rsyslog 등의 시스템 로그 데몬을 통해 로그를 관리했지만,modern Linux 배포판에서는 systemd가 기본 init 시스템으로 자리 잡으면서 journalctl이라는 로그 관리 도구가 함께 제공된다. 1. journalctl의 개요journalctl은 systemd journal 로그를 조회하고 관리하는 명령어 도구이다.시스템 부팅 로그, 서비스 상태 로그, 커널 메시지 등을 통합적으로 관리하며, 로그 필터링 및 검색 기능도 제공한다. 2. 기존 syslog와의 차이점 항목syslogjournalctl (systemd)로그 포맷텍스트 중심바이너리 로그 (압축, 메타데이터 포함)저장 위치/var/log/messages 등..

웹 서버와 클라이언트 사이에 위치해 통신을 중계하는 기술로 프록시(proxy)와 리버스 프록시(reverse proxy)가 있다. 두 방식은 유사해 보이지만, 목적과 동작 방향에서 뚜렷한 차이가 있다. 각각의 개념과 차이를 정리한다. 1. 프록시(Proxy)란?프록시는 클라이언트가 요청을 보낼 때 중간에 위치해 대신 요청을 처리하는 서버이다. 사용자는 직접 서버에 접속하지 않고, 프록시를 거쳐 외부 자원에 접근하게 된다. 동작 흐름 주요 목적사용자의 IP 주소를 숨길 수 있다.특정 사이트 접근을 제한하거나 로그를 기록할 수 있다자주 요청되는 자원을 캐싱해 응답 속도를 높일 수 있다내부망에서 외부 인터넷으로의 접근을 제어할 수 있다 활용 예기업이나 학교에서 인터넷 트래픽을 관리하거나 감시할 때 사용된다...

데이터베이스 설계 시, 테이블의 기본 키(primary key)를 어떻게 구성할지는 시스템의 규모와 보안, 운영 효율성과 관련이깊은 중요한 선택이다. 가장 널리 사용되는 두 가지 방식은 UUID와 Auto-incrementing Key이다. 각각의 특성과 적절한 사용 사례를 비교해보고자 한다. 1. Auto-incrementing Key란?Auto-incrementing Key는 데이터베이스가 자동으로 증가시키는 정수형 ID이다.(예: 1, 2, 3...) 장점짧고 간결한 ID로 URL이나 로그에서 보기 편함연속된 값으로 인덱싱 효율이 높음개발 및 디버깅 시 식별이 쉬움 단점전역 고유성이 보장되지 않음URL 패턴을 통한 열거(enumeration) 공격에 취약함ID를 통해 전체 데이터 구조를 유추할 가능..

1. Metadata란?Metadata는 웹페이지의 콘텐츠에 대한 정보를 담는 데이터이다.HTML 문서의 태그 내부에 작성되며, 사용자가 직접 보지는 않지만브라우저, 검색엔진, 소셜미디어가 페이지를 해석하는 데 사용하는 정보다. 대표적인 메타태그 예시나의 블로그 주요 특성사람보다 시스템을 위한 데이터이다.페이지의 주제, 설명, 이미지 등을 알려준다.검색 결과, SNS 공유 카드, 브라우저 탭 제목 등에 사용된다. 2. SEO란?SEO(Search Engine Optimization) 는 검색 엔진 최적화라는 뜻이다.검색엔진이 내 웹사이트를 더 잘 이해하고, 더 높은 위치에 노출되도록 돕는 전략이다. 구성 요소title: 페이지 제목. 검색 결과의 제목으로 사용됨meta description: 검색 결과..

최근 Next.js 공식 가이드를 참고하다가 "정적과 동적 렌더링"에 대한 설명이 잘 정리되어 있어 포스팅으로 공유한다.웹 개발에서 자주 등장하는 개념이지만, 실제 사용 사례와 코드로 접하면 더 명확하게 이해할 수 있어 정리해본다. 정적 렌더링 (Static Rendering)정적 렌더링은 요청 전에 페이지의 HTML을 미리 생성해 두는 방식이다. 빌드 시점 혹은 최초 요청 시 데이터를 가져와 HTML로 만들어 두고, 이후에는 캐시된 결과를 재사용한다. 특징빠른 응답 속도CDN 캐싱* 가능자주 변경되지 않는 컨텐츠에 적합*CDN 캐싱: 전 세계에 분산된 서버들이 컨텐츠를 미리 저장해두고 사용자의 요청에 가장 가까운 서버에서 빠르게 응답하는 방식. 예시 코드 (Next.js 기준)export defaul..

Waterfall Request 방식은 여러 개의 비동기 데이터 요청을 순차적으로 처리하는 방식이다.하나의 요청이 완료된 후에야 다음 요청이 실행되며, 이전 요청의 결과가 다음 요청의 입력값으로 필요한 경우에 사용된다. 예를 들어, 다음과 같이 요청이 이어지는 구조를 의미한다.const session = await getSession();const user = await getUser(session);const teams = await getTeams(user); 특징1. 의존성 기반 처리 - 각 요청이 이전 요청의 결과에 의존할 때 적합하다. - 흐름이 명확하고 예측하기 쉬운 구조를 가진다.2. 순차적 실행 - 각 요청이 직렬적으로 처리된다. - 이전 요청이 끝나야 다음 요청이 시작된다.3...

React 기반의 다양한 프레임워크와 라이브러리 중에서 Next.js는 그 구조와 성능 최적화 측면에서 특별한 지점을 차지하고 있다. 특히 기존의 React SPC(Single Page Application)와 비교했을 때, 코드 분할, 프리페칭, 라우팅 안정성 등의 측면에서 뛰어난 사용자 경험을 제공한다. 아래는 그런 Next.js의 주요 차별점과 특징을 정리한 내용이다. 1. 자동 코드 스플리팅 (Automatic Code Splitting)Next.js는 페이지 단위로 코드를 자동 분할한다.전통적인 React SPA는 초기 로딩 시 전체 애플리케이션 코드를 한 번에 불러오게 되어 있다. 페이지가 많아질수록 처음 로딩 속도가 느려지고, 사용자 경험이 떨어질 수 있다. Next.js는 이를 해결하기 위..