dev.ellug

디벨로켓 Unity 게임 클라이언트 개발자 8개월 과정 후기

ellug — Mon, 20 Apr 2026 20:48:46 +0900

배경을 이야기 하자면 나는 비전공자 웹/앱 프론트엔드 개발자 출신이고, 게임 개발자로 커리어 전환을 준비하던 중 디벨로켓의 온라인 부트캠프 과정을 발견해 지원하게 됐다.

실무에 필요한 커리큘럼들 위주로 갖추어져 있었고, 무엇보다 온라인이라는 부분이 매력적이었다.

나의 경우에는 이미 C#을 제법 학습해둔 상태였기에 기초부터 시작하는 건 원치 않았지만, 그렇다고 다른 과정이라고 해서 개강, 수료 더 빨리 끝나거나 메리트 있는게 아니었기 때문에 심사숙고 끝에 디벨로켓으로 빠르게 결정했다.

커리큘럼

기본적으로 모든 학습은 강의 → 과제 구조로 이루어진다.

처음 상담 때는 과제가 제법 많고 어렵다고 했지만 솔직히 그렇게 엄청나게 무거운 편은 아니다.

이 정도는 당연히 해야하고, 이 이상 추가로 학습을 해야 한다고 생각한다.

커리큘럼에 대해서는 크게 C#, Unity, 네트워크, 프로젝트 로 나눠서 보면 될 거 같다.

실제로는 더 세세하게 나눠져있지만 개요에서부터 그렇게 볼 필요 없고 어차피 다 한 몸이다.

다 알아야 하고 더 알아야 한다.

C#

C# 언어와 간단한 CS 지식, 알고리즘, 자료구조 등을 학습한다.

솔직히 이 부분은 거의 다 알고있는 내용 위주라서 복습하는 마음으로 임했었다.

내가 잘못 알고 있거나, 대충 넘겨짚어 알고 있는 부분들을 교정할 수 있는 기회가 되었기에 생각했던 것 보다 유효한 학습이었다.

많은 인원이 객체지향, 제네릭이 등장하면서부터 꺾이는 것 같다.

확실히 처음 보면 저게 뭔 소린가 싶긴 한데...

근데 여기서 꺾이면 개발자 못 한다. 아직 기초다...

C#이 기초라고 해도 알파이자 오메가이기도 하다.

자신이 노베이스라면 어느정도 선행학습을 한 뒤에 과정에 참여하는 것을 추천한다.

Unity

유니티 기초도 멘토와 다른 인터넷 강의를 통해 다소 학습을 한 상태였지만 여기서부터 제법 어려움을 겪게 된다.

유니티 파트는 5와 6를 모두 진행 된다.
(아마 다음 강의는 6만 진행할지도 모른다. 더 이상 6.4 이상부터는 빌트인을 지원하지 않는다는 오피셜로 인해...)

기본적인 사용법에서 시작해서 네비매시, 타일맵, 시네머신, 타임라인 등 실무에서 사용될 법한 기술 위주로 학습을 진행한다.

많은 인원이 고통을 호소하기 시작했지만, 반대로 제대로 게임을 만들기 시작하기 때문에 재밌어지는 시기다.

중간 중간 실무 팁도 많이 알려주시며, 최적화 관련된 내용은 필시 기억해두고 이 시기부터 준비해두는 게 좋다.

개발자 취업 포트폴리오에서 구현 보다는 설계, 최적화, 문제해결 이런 키워드 쪽이 가치가 훨씬 높다.

근데 새로운 툴을 배울 때의 어떤 답답한 시기만 잘 버텨내면 그 다음부터는 아주 재밌어지니까 너무 두려워하지 않아도 된다.

네트워크

학습 자체는 어렵지 않다.

특히 Firebase 같은 서버리스는 웹 개발자를 할 때도 많이 다뤄봤기 때문에 아주 자신있었다.

문제는 Photon 인데... 이것도 이론 자체는 어렵지 않다.

하지만 실제로 프로젝트에 적용하다 보면 예상치 못한 문제가 많이 발생한다.

네트워크의 불확실성이라고 하는데 처음 겪으면 제법 헤매게 될 수 있다.

기존에 하던 설계에서 한 차원 더 설계가 복잡해지는 것이기에 머리도 조금 아프다.

그래도 가장 재밌게 한 프로젝트가 네트워크 였다.

온라인 학습

온라인 과정이라는 부분은 나한테 아주 메리트가 있었다.

우선 나는 장거리 이동을 매우 싫어하고 그 시간과 에너지도 전부 비용이라고 생각한다.

그런데 온라인 과정으로 비대면 학습을 진행한다면 그 에너지를 전부 학습에 투자할 수 있다.

전력으로 공부에 임할 생각이 있다면 아주 유리한 조건이라 생각한다.

하지만 자신이 누군가가 잡아줘야하고, 쉽게 나태해지거나 의지가 약하거나 가벼운 마음으로 시작했다면 비추한다.

실제로 수업 중 다른 짓을 하거나 부정한 행위(?)를 하다가 제적되는 학생들을 몇 봤다.

제적되면 다행이지 어떻게든 살아남아서 몰래 숨어서 다른 짓 하는 학생도 간혹 있다.

이런 학생들 때문에 진짜 공부하고자 하는 사람들이 손해보지 않았으면 좋겠다.

기본적으로 스스로 통제해야하기에 자신 나름대로 규칙을 세우는게 중요하다.

다행히 나는 오랜 프리랜서 생활과 재택근무 경험이 있어 쉽게 적응할 수 있었다.

우선 절대로 침실과 작업실은 분리해야 하며,

일과를 전부 학습에 투자한다는 원칙 하에 세부적인 규칙을 자신에 맞게 구성하고 지키는게 좋다.

규칙 정해도 안 지킨다고?

해도 안 지키는데 정하지도 않으면 어떻게 될까?

프로젝트

콘솔 프로젝트
유니티5 프로젝트 (팀)
2D 개인 프로젝트
기획 사전합반 프로젝트 (팀)
네트워크 프로젝트 (팀)
기업협약 기획-개발 협업 프로젝트 (팀)

이렇게 6번의 프로젝트로 구성되어있다.

일단 난 모든 팀 프로젝트에서 팀장이자 리드 프로그래머로서 참여했다.

~~리드 프로그래머라는 말이 다소 허세스럽긴 하지만 간결하게 역할을 설명하기에 딱이었던 것 같다.~~

콘솔 프로젝트는 말 그대로 터미널상에서 C# 스크립트를 이용해 게임처럼 보이게 만드는 간단한 프로젝트다

약 1주일 이내로 진행되는데 나는 여기서부터 욕심을 부렸다.

의도적으로 많은 객체를 다루는 게임을 기획하여 부하상태를 유도하고 그 부하상태를 해결하는 방향으로 프로젝트 자체를 학습과 증명의 장으로 사용했다.

나머지 모든 프로젝트에서도 동일한 시각으로 접근했다.

그냥 저냥 돌아가는 대충 만든 프로젝트가 아니라 포트폴리오에 한 줄이라도 쓸 수 있는 내용을 만들고자 고민했다.

취업 준비

기업협약 프로젝트가 끝나면 취업 준비 시즌에 돌입한다.

하지만 난 이 기간을 기다리지 않고 기업협약 프로젝트 기간 비는 시간을 활용해 강사님들을 독점하면서 이력서, 자기소개서, 포트폴리오 준비를 선제적으로 해결했다.

원래 그러려던 계획은 아니고 그 시기에 지원하고 싶은 회사가 있어서 그렇게 했던 건데 결과적으로 잘한 것 같다.

왜냐하면 강사님들을 독점할 수 있는 유일한 시기이기 때문이다.

취업 시즌에 돌입하면 다들 이력서, 자기소개서 부터 시작하기 바쁘다.

강사님들이 그 사람들을 다 챙겨주면서 나한테 얼마나 집중할 수 있을까?

가능하다고 하더라도 퀄리티가 다르다.

프로젝트 하면서 그럴 시간이 어떻게 있냐고 한다면

그냥 아침부터 새벽2시까지 전부 사용하고 수면은 6시간 이내로, 나머지 아무것도 안 하고 개발 관련에만 투자하면 된다.

별로 이상할 거 없다.

수능준비 그렇게 해보지 않았나?

어떻게 보면 수능보다 중요한 시기다.

욕심 부리는게 맞다고 생각한다.

이후 취업지원팀에서도 봐주시지만, 이미 거의 문서를 완성해 놓은 상태라 문서적으로는 크게 피드백 받을 게 없었다.

마이너한 피드백 몇 가지만 선택적으로 반영하고, 지원할 기업에 맞춰 폴리싱하는 작업을 거치며 이제 이 불지옥 취업시장에서 싸우는 일만 남았다ㅎ

총평

난 개인적으로 강사, 교수 이런 사람들을 신뢰하지 못하는 편이라 디벨로켓에 올 때도 의심의 날을 세우고 강사가 부족하면 내가 알아서 내 몫을 챙기겠단 마인드로 시작했다.

하지만 솔직히 말해서 기대 이상이었다.

이번 기수를 담당해주신 두 강사님 모두 성격도 좋으시고, 교육에 열의도 있으시며 기술적인 지식의 깊이나 경험도 상당하셨다.

내심 "이런 건 바로 대답 못하고 같이 RnD 해봐야할지도 모르겠다"라고 생각하며 질문했던 내용에 대해서도 빠르고 정확하게 해결책이나 방향성을 제시해주시기도 했다.

그러면서도 하나의 답에 매몰되지 않도록 직접 고민할 기회를 주시는 것도 좋은 부분이었다.

기획 합반 프로젝트 과정에서 이런저런 문제가 발생하긴 하지만

기획반 또한 배우고 있는 학생이라는 점과 실제로 현업에 가서도 비슷한 문제, 혹은 더 심각한 문제도 발생한다는 걸 고려하면 이런 트러블 조차 전부 경험이며 그 해결 과정 또한 포트폴리오라고 생각한다.

솔직히 말해서 이 과정을 노베이스 비전공자가 가벼운 마음으로 하기엔 쉽지 않다.

대부분 C# 언어 학습 단계에서 꺾이고, 결국 과정 막바지가 되어서도 제대로 된 코드 하나 작성하지 못하는 경우도 봤다.

심지어 AI를 쓰는데도 말이다...

정말 열심히 해야한다.

게임 개발은 재미로 하는 블럭쌓기가 아니라 엔지니어링이라는 걸 명심해야 한다.

시장 상황도 좋지 않고 전망도 어떻게 될지 몰라 무조건적으로 추천할 수는 없다.

일단 취업률 몇% 이런 건 어느 학원이든 대학이든 절대 믿으면 안 된다.

개발업계는 지금 현업자 경력자들도 이직이 쉽지 않은 불지옥 상태다.

물론 다른 업계도 쉽지 않은 상태긴 하지만 내가 개발업계 종사자다 보니 더 피부로 느끼는 바는 이쪽이 심하다.

하지만 그럼에도 훈련지원금을 받으며 무료로 이정도 퀄리티의 강의와 프로젝트 경험을 쌓을 수 있는 기회라면 아주 혜자라고 생각한다.

정말 하고싶은 마음이 있다면 어느정도 사전 학습을 한 뒤에 지원하는 걸 추천한다.

유니티까지 사전학습 할 필요는 없고 최소한 C# 혹은 C계열 언어들을 중급 이상으로 학습한 뒤에 시작한다면 비교적 수월하게 진행할 수 있을 것 같다.

소정의 경품을 제공받아 작성된 후기입니다.

근데 빈말은 안 했읍니다.

Node.js : GameJob Notifier - Firebase Function & Discord WebHook

ellug — Fri, 17 Apr 2026 15:59:24 +0900

프로젝트 배경

처음에는 GameJob 공고를 놓치지 않기 위해 C# WPF 데스크톱 앱(트레이 상주 + 알림)으로 운영했다.
기능 자체는 잘 동작했지만, 실제 사용에서는 몇 가지 불편이 분명했다.

알림을 받으려면 앱이 켜진 PC가 항상 켜져 있어야 함
외부에서 모바일로 확인하기가 번거로움
OS/실행 환경에 의존적인 관리 포인트가 늘어남

그래서 “앱을 켜두지 않아도”, “데스크톱/모바일 어디서나” 알림을 받을 수 있는 방식으로 구조를 바꿨다.
핵심 아이디어는 서버리스 폴링 + Discord Webhook 조합이다.

Firebase Functions(2nd gen)가 5분마다 자동 실행
Firestore에 이전 상태를 저장해 변경 감지
신규 공고(Added)만 Discord로 전송

결과적으로 클라이언트 앱 없이도, Discord만 켜져 있으면 동일한 알림 경험을 유지할 수 있게 됐다.

사용 기술 스택

Runtime/Language: Node.js 20 + TypeScript
Serverless: Firebase Functions v2 (onSchedule)
Database: Firestore
Crawling/Parsing: HTTP Fetch + Cheerio
Notification: Discord Webhook
Secret: Firebase Secret Manager
Region/Cost Config: asia-northeast3, 256MiB, timeoutSeconds=60, maxInstances=1

핵심 기술 포인트

1. 상태 비교 기반 변경 감지

이번 프로젝트도 단순 목록 수집이 아니라, “이전 상태와 현재 상태의 비교”를 중심으로 설계했다.

Added: 이번 실행에서 처음 발견된 공고
Hidden: 이전에는 보였지만 이번엔 사라진 공고
Restored: 숨김 상태였다가 다시 노출된 공고

이 구조 덕분에 스크래핑 결과를 단순 데이터가 아닌 이벤트로 해석할 수 있었다.

2. 스코프 분리(필터/URL 기반 해시)

동일한 사이트라도 필터가 다르면 결과 집합이 완전히 달라진다.
그래서 URL + 필터 조합을 해시해 scopeKey를 만들고, 스코프 단위로 상태를 분리 저장했다.

jobScopes/{scopeKey}: 스코프 메타
jobScopes/{scopeKey}/jobs/{jobId}: 공고 상태

이렇게 하면 필터 변경 시 데이터가 섞이는 문제를 피할 수 있다.

3. 알림 노이즈 제어 + 중복 방지

알림 정책은 “Added만 전송”으로 단순화했다.

Hidden/Restored는 저장만 하고 알림은 보내지 않음
notificationLedger로 idempotency key를 관리해 중복 전송 차단
동일 공고에 대해 재실행/재시도 상황에서도 한 번만 전송되도록 보장

4. 운영성 중심 설계

서버리스는 실패를 전제로 운영해야 한다. 그래서 아래 항목을 기본으로 넣었다.

스케줄 중복 실행 방지 락(pollLocks)
HTTP/Discord 전송 재시도(간단 백오프)
구조화 로그(fetched, matched, added, hidden, restored, notified)
비정상 종료 시에도 다음 주기에 복구 가능한 TTL 기반 락/상태 처리

구현 방법 요약

Cloud Scheduler가 5분마다 pollGameJobs 실행
스코프 락 획득 후 목록 HTML 수집
Cheerio 파싱으로 공고 모델 정규화
필터(직종/경력/조건) 매칭
Firestore 기존 상태와 diff 계산(Added/Hidden/Restored)
상태 upsert 저장
Added만 idempotency 선점 후 Discord 전송
실행 메트릭/로그 기록 후 락 해제

알림 연결 방법

1. Discord Webhook

Discord 채널 Webhook URL 발급
Secret Manager에 DISCORD_WEBHOOK_URL 저장
Functions에서 defineSecret()으로 주입 받아 전송

하드코딩을 피해서 보안/운영성을 동시에 확보했다.

2. 메시지 포맷

신규 공고 알림은 아래 형식으로 고정했다.

[신규 공고] 제목
회사: ...
경력: ...
지역: ...
링크: ...

모바일에서도 빠르게 읽히는 형태를 우선했다.

3. 실패 처리

전송 실패 시 에러 로그 + ledger 상태 error로 기록
다음 실행에서 stale claim 기준으로 재시도 가능
함수가 실패해도 전체 상태 일관성은 유지되도록 분리 저장

배포/운영 포인트

1. 배포 구성

Firebase Functions 2nd gen, 리전 asia-northeast3
스케줄: every 5 minutes
리소스 제한: 256MiB, 60s, maxInstances=1

작게 시작하고 안정화하는 데 집중한 설정이다.

2. 비용 최적화

불필요한 고사양 인스턴스 사용 억제
Added 중심 알림 정책으로 외부 호출 최소화
Ledger TTL/인덱스 최적화로 Firestore 저장/인덱스 비용 관리

3. 관측성과 트러블슈팅

스코프 시작/완료 로그로 실행 흐름 추적
필터 실패 샘플 로그(duty_mismatch, career_mismatch) 제공
운영 중 파싱 구조 변경 시에도 로그 기반으로 빠르게 원인 파악 가능

학습 포인트

이번 전환에서 가장 크게 얻은 포인트는 아래 4가지다.

데스크톱 자동화 문제도 서버리스 이벤트 파이프라인으로 단순화할 수 있다.
스크래핑 품질은 “파싱 정확도”보다 “상태 모델 + diff 설계”가 더 중요하다.
알림 시스템은 전송 성공보다 중복 방지와 노이즈 제어가 핵심이다.
운영 환경에서는 기능 구현보다 로그/복구/비용 설계가 장기 품질을 좌우한다.

마무리

이 프로젝트는 기존 WPF 알림 앱의 한계를 실제 사용 관점에서 다시 정의하고,
클라이언트 의존형 구조를 서버리스 이벤트 구조로 치환한 작업이었다.

핵심은 “수집”이 아니라 “판단(변화 감지)”이고,
완성도는 “알림 전송”이 아니라 “운영 가능한 구조”에서 나온다는 점을 체감했다.

다음 단계에서는 다중 스코프 운영, 알림 채널 다변화(예: Slack/Email), 대시보드화까지 확장할 수 있다.

C# : GameJob 신규 공고 알람 앱 - WPF(MVVM), HttpClient, SQLite, Windows Toast

ellug — Tue, 14 Apr 2026 15:11:27 +0900

https://github.com/Ellug/GameJobNotifier

1. 프로젝트 배경

채용 사이트를 수시로 확인하는 반복 작업을 줄이기 위해, GameJob 공고를 주기적으로 수집하고 새로운 공고가 등록되면 즉시 알림을 주는 데스크톱 앱을 만들었다.
단순히 “목록 보여주기”가 아니라, 로컬에 상태를 저장하고 이전 상태와 비교해 변화(신규/비노출/복원) 를 감지하는 구조로 설계했다.

2. 사용 기술 스택

Language: C#
Runtime: .NET 10 (net10.0-windows)
UI: WPF + MVVM (CommunityToolkit.Mvvm)
Hosting/DI: Microsoft.Extensions.Hosting
Data: SQLite (Microsoft.Data.Sqlite)
Crawling: HttpClient + HtmlAgilityPack
Notification:
- Windows Toast 알림 (PowerShell + WinRT 호출)
- Tray Balloon 알림 (NotifyIcon)

3. 핵심 기술 포인트

3-1. 상태 비교 기반 변경 감지

핵심은 “현재 목록”만 보는 게 아니라, 이전 실행에서 저장한 데이터와 비교하는 것이다.

Added: 새로 발견된 공고
Hidden: 이전에 보였는데 이번엔 사라진 공고
Restored: 숨김 상태였다가 다시 노출된 공고

이 방식 덕분에 단순 스크래핑을 넘어 “변화 이벤트”를 만들 수 있다.

3-2. 스코프 분리(필터 조합 해시)

필터 조합(직종/지역/조건 등)이 바뀌면 결과 집합도 달라진다.
그래서 URL + 필터 조합을 해시해 source scope key를 만들고, 스코프 단위로 상태를 추적해 데이터 섞임을 방지했다.

3-3. 알림 노이즈 제어

첫 실행 때 기존 공고를 전부 알림으로 보내면 노이즈가 너무 크다.
마지막 성공 검사 시각과 현재 시각 사이에 등록된 항목만 신규 알림 대상으로 제한해 신뢰도를 높였다.

3-4. 데스크톱에서도 Host/DI 구조 적용

WPF에서도 Host + DI + HostedService를 적용해 UI와 도메인 로직을 분리했다.
테스트/유지보수 관점에서 구조가 훨씬 명확해진다.

4. 구현 방법 요약

대상 URL 수집
HTML 파싱 후 공고 모델 정규화
설정된 필터 적용
SQLite upsert
이전 상태와 diff 계산
변경 이벤트 생성
알림 전송
마지막 실행 상태 저장

5. 알림 연결 방법

5-1. Toast 알림

Toast XML 생성
PowerShell에서 WinRT Toast API 호출
알림 액션에 공고 열기(URL) 연결

5-2. Tray Balloon 알림

NotifyIcon.ShowBalloonTip() 사용
풍선 클릭 시 해당 공고 URL 오픈

5-3. 사용자 설정 연동

Toast On/Off
Tray Balloon On/Off
둘 다 꺼진 경우 테스트 알림 차단 및 안내 메시지 표시

6. 백그라운드/부팅 연동

6-1. 트레이 상주 동작

창 닫기/최소화를 “종료”가 아닌 “숨김”으로 처리해 백그라운드 상주를 유지했다.

6-2. 윈도우 시작 시 자동 실행

HKCU\Software\Microsoft\Windows\CurrentVersion\Run에 앱 경로를 등록/해제해 부팅 연동을 구현했다.

7. 학습 포인트

이번 프로젝트에서 특히 도움이 됐던 학습 포인트는 아래 4가지다.

데스크톱 앱에서도 서버형 아키텍처(Host/DI/BackgroundService)를 충분히 적용할 수 있다.
스크래핑은 “수집”보다 “변화 감지 모델” 설계가 더 중요하다.
알림 시스템은 기능 구현보다 노이즈 제어와 사용자 경험이 핵심이다.
로컬 앱이라도 상태 저장소(SQLite + runtime state) 설계가 품질을 좌우한다.

8. 마무리

이 프로젝트는 작은 토이 프로젝트처럼 시작했지만, 실제로는 수집 → 판단 → 이벤트 → 통지의 흐름을 끝까지 구현한 형태다.
데이터 신뢰성과 운영성(백그라운드, 부팅 연동, 알림 품질)에 집중하면서 구조를 정리한 경험이 가장 큰 수확이다.

C# : Chzzk(치지직) VOD / Clip 다운로더

ellug — Fri, 20 Mar 2026 15:46:18 +0900

CHZZK VOD/CLIP 다운로더 개발기 (C# WinForms)

치지직 VOD와 CLIP을 로컬로 저장하고, VOD 구간 채팅까지 함께 보관하는 도구를 개발했다.
목표는 단순 다운로드 기능이 아니라, 응답 구조 변경에 덜 깨지는 안정성과 유지보수 가능한 코드 구조를 확보하는 것이었다.

몇년전 트위치에서는 다시보기 영상을 구간 다운로드, 클립 다운, 영상 채팅 로그 수집 등이 가능한 앱들이 있었다.

하지만 어느순간 하나둘씩 사용할 수 없게되었고, 치지직에는 유사 앱이 거의 존재하지 않게 됐다.

그나마 풀려있는 치지직 다운로더는 광고 떡칠이라 불편해서 못 쓸 지경이었다.

그래서 다음 기능을 하나의 앱으로 통합했다.

VOD/CLIP 모드 전환
해상도 선택 + 구간 다운로드
VOD 채팅 저장(JSON/SRT/TXT)
ffmpeg 기반 미디어 처리

핵심 기술

1) API 복원력 설계

ChzzkApiClient를 단일 호출 구조로 두지 않았다.
CLIP 조회는 여러 경로를 순차 시도하는 fallback 체인으로 구성했다.

service clips 계열 호출
play-info/clip 호출
페이지/임베드 파싱
프로브 엔드포인트 탐색

핵심은 "하나가 실패해도 다음 경로로 복구"하는 구조다.

2) ffmpeg 인자 분기 전략

초기에는 입력 타입과 무관하게 동일 옵션을 넣어 오류가 발생했다.
HLS(.m3u8)와 direct mp4 입력을 분리해 인자를 다르게 적용했다.

HLS 입력: allowed_extensions, extension_picky, protocol_whitelist 적용
direct mp4 입력: HLS 전용 옵션 제거

결과적으로 CLIP/VOD 모두 안정적으로 처리되도록 정리했다.

3) UI-도메인-인프라 분리

WinForms 특성상 한 파일에 로직이 몰리기 쉽다.
유지보수를 위해 화면 코드를 역할별 partial로 분리했다.

MainForm.Layout.cs: 배치/레이아웃
MainForm.Actions.cs: 이벤트/동작
MainForm.cs: 상태/초기화

서비스 계층은 VideoDownloadService로 묶고, 외부 연동은 Infrastructure로 분리했다.

개발 결과

다운로드 모델 정리

초기에는 VOD 중심 모델을 CLIP에도 적용하려 했으나 실패했다.
리팩토링 후 DownloadRequest를 StreamUrl 중심으로 단순화해 VOD/CLIP 공통 경로를 만들었다.

VOD: 해상도 조회, 구간 다운로드, 오디오 추출 동작
CLIP: URL 기반 메타 조회 및 다운로드 동작
채팅: 구간 기준 JSON/SRT/TXT 저장 동작
UI: 모드 전환과 작업 로그 흐름 안정화

실사용 기준으로 주요 흐름은 정상 동작하는 상태를 확보했다.

한계와 다음 단계

ffmpeg는 외부 의존이라 배포 환경에서 PATH 이슈가 발생할 수 있다.
API 응답 포맷 변경은 계속 발생할 수 있어 fallback 경로를 주기적으로 보완해야 한다.
대용량 VOD 처리 시 재시도/네트워크 복구 정책을 더 강화할 여지가 있다.

GitHub 링크 : https://github.com/Ellug/ChzzkLiveDownloader

Unity : 마샬링(Marshalling) 과 메모리 풀링(Memory Pooling)

ellug — Mon, 2 Mar 2026 19:53:12 +0900

마샬링(Marshalling) 이란?

C#과 같은 Managed 환경은 가비지 컬렉터(GC)가 메모리를 관리하며, 데이터가 메모리에 배치되는 방식의 런타임에 의해 유동적으로 결정될 수 있다. 반면 C/C++ 같은 Unmanaged 환경은 개발자가 직접 메모리를 제어하며, 메모리 레이아웃이 고정되어 있다.

이런 서로 다른 두 환경에서 데이터를 교환하려면 번역 과정이 필요하게 된다.

예를 들어 C#의 string 타입은 내부적으로 UTF-16 인코딩을 사용하는 객체지만, C++ 에서는 const char* (UTF-8 또는 ASCII) 형태의 포인터 배열로 돼있다.

이때 C#의 문자열을 C++이 이해할 수 있는 메모리 구조로 복사하고 변환해 주는 작업이 마샬링이다.

Blittable 타입과 Non-Blittable 타입

마샬링 성능을 이해하려면 두 타입의 특성을 알아야 한다.

Blittable 타입

Managed 와 Unmanaged 양쪽에서 메모리 표현 방식이 완전히 동일한 타입. 변환 과정 없이 메모리 복사(Bit-block transfer)만으로 전달되므로 오버헤드가 거의 없다. (byte, sbyte, short, ushort, int, uint, long, ulong, float, double, IntPtr 등)

Non-Blittable 타입

양쪽의 메모리 표현 방식이 달라 마샬러(Marshaler)가 개입해 데이터를 변환해야 하는 타입으로 오버헤드가 발생한다. (bool, stirng, object, 클래스, 가변 배열 등)

참고로 C#의 bool은 4바이트를 차지하지만 C++의 bool은 일반적으로 1바이트다.

Photon Fusion 에서의 실전 활용

유니티 멀티플레이어 개발에서 널리 사용되는 Photon Fusion 같은 네트워크 엔진을 사용할 때, 이 Blittable/Non-Blittable 개념을 활용해 메모리 최적화가 가능하다.

Fusion은 완벽한 클라이언트 예측과 롤백을 위해 매 틱마다 게임의 전체 상태를 저장하고 복원한다.

만약 이 상태 데이터가 C#의 매니지드 힙(Managed Heap)에 파편화되어 있다면, 매 틱마다 데이터를 직렬화하고 마샬링하는 데 엄청난 CPU 연산과 GC가 발생할 것이다.

따라서 Fusion은 상태 데이터를 통째로 언매니지드 메모리*Unmanaged Memory) 버퍼에 연속적으로 배치하여, 마샬링 오버헤드 없이 Memcpy (메모리 블록 복사) 만으로 스냅샷을 찍고 롤백하는 방식을 취한다.

Case 1 : 지옥의 string 마샬링 피하기

채팅 메시지나 플레이어의 닉네임을 동기화해야 한다고 가정해 보자.

Non-Blittable 타입인 string을 아무 생각 없이 사용했다간 네트워크 버퍼에 C# string을 밀어 넣는 과정에서 인코딩 변환과 힙 메모리 할당(마샬링)이 발생한다.

이 때 고정 크기 버퍼(Fixed Buffer) 을 사용하는 것으로 최적화 전략을 취할 수 있다.

네트워크 틱마다 갱신될 수 있는 핫 패스(Hot path)에서 순수 string의 사용은 쥐약이다.

그래서 Fusion 에서는 이를 해결하기 위해 NetworkString<_16>, NetworkString<_32> 같은 전용 타입을 제공한다.

// 최악의 접근: 매 틱마다 GC 할당 및 마샬링 오버헤드 발생
[Networked] public string PlayerName { get => default; set; } 

// 최적화된 접근: 32바이트 언매니지드 메모리 공간을 직접 차지함 (Blittable)
[Networked] public NetworkString<_32> PlayerName { get => default; set; }

NetworkString은 내부적으로 C#의 fixed 키워드와 unsafe 구조체를 활용하여, 포인터 기반의 고정 크기 바이트 배열로 문자를 처리한다. 즉, Non-Blittable인 문자열을 강제로 Blittable한 구조체로 포장하여 마샬링 비용을 0으로 만든 것이다.

Case 2 : bool 대신 비트 마스킹(Bit-masking)

C#의 bool은 4바이트를 차지하는 Non-Blittable 타입이다.

때문에 캐릭터의 상태를 동기화하기 위해 bool 변수를 여러개 선언하면, 메모리 낭비는 물론 Unmanaged 버퍼로 넘어갈 때 오버헤드가 누적된다.

이 때 상태를 하나의 Blittable 타입(int, byte)으로 압축 할 수 있다.

bool 대신에 Blittable 타입인 byte나 int 하나를 선언하고, 비트 연산자를 이용해 여러 상태를 플래그(Flag)로 관리하면 마샬링 오버헤드 없이 깔끔하게 메모리가 복사된다.

// 비효율적인 상태 동기화 (마샬링 대상이며 메모리 낭비 심함)
[Networked] public NetworkBool IsJumping { get; set; }
[Networked] public NetworkBool IsAttacking { get; set; }
[Networked] public NetworkBool IsCrouching { get; set; }

// 최적화된 접근: 1개의 int(4바이트)에 32가지 상태를 Blittable하게 압축
[Networked] public int PlayerStateFlags { get; set; }

// 비트 연산을 통한 상태 제어 (마샬링 없음, Bit-block transfer 보장)
public void SetJumping(bool state) {
    if (state)
    	PlayerStateFlags |= (1 << 0);
    else
    	PlayerStateFlags &= ~(1 << 0);
}

Case 3 : 가변 데이터 통신을 위한 메모리 풀링 (Memory Pooling)

앞에서 언급한 NetworkString<_16> 이나 int 비트 마스킹은 데이터의 크기가 고정되어 있을 때 사용하는 고정 크기 버퍼(Fixed Buffer) 방식이다. 구조체 내부에 메모리를 인라인으로 박아 넣어 힙 할당 자체를 없애는 것이다.

하지만 네트워크 통신이나 C++ 플러그인과 데이터를 주고받다 보면, 크기가 매번 변하는 가변 배열을 마샬링 하는 경우가 생긴다.

크기가 유동적이니 구조체 안에 고정된 크기로 박아둘ㄷ 수도 없다.

이때 매 프레임 new byte[size]를 호출해 배열을 생성하면 GC 부하가 생긴다.

이를 해결하는 방법이 바로 메모리 풀링(Memory Pooling) 이다.

메모리 할당은 하드에 읽기 쓰기를 빼면 가장 느린 작업 중 하나이기에 메모리 할당 자체를 줄이는 게 좋다는 발상으로 근본적으로 오브젝트 풀링과 같은 발상이다.

객체의 논리적 껍데기를 재사용하는 오브젝트 풀링과 달리, 메모리 풀링은 거대한 순수 메모리 덩어리 (바이트 배열이나 언매니지드 포인터 공간)를 하나 통쨰로 빌려두고, 필요한 만큼 잘라서 쓰고 반납하는 기법이다.

C# 최신 버전과 유니티에서는 이를 위해 System.Buffers.ArrayPool<T> 를 기본적으로 제공한다.

이는 Managed 영역에서 발생하는 배열 할당을 극단적으로 줄여주며, 이를 바탕으로 Marshal.UnsafeAddrOfPinnedArrayElement나 Fixed 구문을 조합해 마샬링 오버헤드를 최소화할 수 있다.

using System.Buffers;
using System.Runtime.InteropServices;

// 최악의 접근: 매번 새로운 배열을 생성하여 GC 폭발 및 마샬링 오버헤드 발생
void SendVariableData_Bad(int requiredSize) 
{
    byte[] buffer = new byte[requiredSize]; // 매 프레임 GC 할당
    NativePlugin.Send(buffer, requiredSize); 
}

// 최적화된 접근: ArrayPool을 이용한 메모리 풀링
void SendVariableData_Good(int requiredSize) 
{
    // 1. ArrayPool에서 필요한 크기 '이상'의 메모리 덩어리를 빌려온다. (GC 할당 0)
    byte[] pooledBuffer = ArrayPool<byte>.Shared.Rent(requiredSize);

    try 
    {
        // 2. 관리형 배열을 고정(Pinning)하여 포인터만 C++(Unmanaged)로 넘긴다.
        // 메모리 복사(Bit-block transfer)조차 발생하지 않는 Zero-Copy 마샬링
        unsafe 
        {
            fixed (byte* pBuffer = pooledBuffer) 
            {
                NativePlugin.Send(pBuffer, requiredSize);
            }
        }
    }
    finally 
    {
        // 3. 사용이 끝난 메모리 덩어리를 풀에 반납한다.
        ArrayPool<byte>.Shared.Return(pooledBuffer);
    }
}

하지만 현시점에서 이렇게까지 최적화를 하며 작업하는 경우는 일반적인 게임 클라이언트 개발에서 많지 않다고 한다.

누군가가 비트단위 쪼개가며 메모리 풀링을 하고 있다면 높은 확률로 연배가 있으실 거라는 이야기를 들었다... (응애 개발자는 존경스러울 따름이다...)

Unity : C#과 Unity에서의 암묵적 Boolean 값 변환 => if (gameObject) 가능??

ellug — Mon, 2 Mar 2026 18:09:28 +0900

JS, Phyton 같은 타 언어에서는 암묵적 Bool 변환을 지원한다.

if 조건문에 넣은 값에 따라 true나 false로 평가되는 방식으로 말이다.

하지만 C#은 엄격한 타입 안정성을 지향하기에 반드시 명시적으로 bool 타입을 사용하지 않으면 컴파일 에러가 발생한다.

하지만 Unity 환경에서는 특이하게도 if (gameObject) 나 if (transform) 과 같이 객체 자체를 조건문에 넣어도 정상 작동이 되는 것을 볼 수 있다.

위에서 말한 C#의 기본적인 정책과 상충하는 것으로 보이는 이 현상에 대해 간략하게 정리해보자.

Unity 에서의 내부 구현

C# 언어 자체에서는 지원하지 않는 문법을 유니티가 쓸 수 있는 이유는, C#의 연산자 오버로딩(Operator Overloading)을 활용해 UnityEngine.Object 클래스 내부에 변환 로직을 직접 구현해 두었기 때문이다.

실제 유니티 엔진의 UnityEngine.Object C# 래퍼 코드를 살펴보면 다음과 같이 정의되어 있다.

namespace UnityEngine
{
    public partial class Object
    {
        // ... 생략 ...

        // 객체가 null이거나 파괴되었는지 확인하는 내부 로직
        private static bool CompareBaseObjects(Object lhs, Object rhs)
        {
            bool lhsNull = ((object)lhs == null) || !lhs.IsNativeObjectAlive();
            bool rhsNull = ((object)rhs == null) || !rhs.IsNativeObjectAlive();
            return lhsNull == rhsNull;
        }

        // 핵심: Object 형을 bool 형으로 암묵적 변환해주는 연산자 오버로딩
        public static implicit operator bool(Object exists)
        {
            return !CompareBaseObjects(exists, null);
        }
        
        // 추가로 ==, != 연산자도 동일한 방식으로 오버로딩되어 있다.
        public static bool operator ==(Object x, Object y)
        {
            return CompareBaseObjects(x, y);
        }
    }
}

위 코드에서 볼 수 있듯이 유니티 내부에서 implicit operator bool 을 정의하여 유니티 객체가 if 문 안에 들어갈 때 자동으로 내부의 CompareBaseObjects 함수를 호출하도록 설계했다.

그렇다면 굳이 왜 표준 C#의 규칙을 벗어나면서까지 이런 오버로딩을 구현했을까?

유니티 객체는 C# 영역의 관리형 객체(Managed Object)와 C++ 영역의 네이티브 객체(Native Object)로 분리되어 있다.

사용자가 Destroy(gameObject)를 호출하면 C++ 영역의 실제 메모리는 파괴되지만, 이를 가리키는 C# 객체 껍데기는 GC가 수거하기 전까지 메모리에 남아있게 된다.

만약 유니티가 순수 C#의 null 체크 방식을 그대로 쓴다면, 이미 파괴된 객체임에도 C# 껍데기가 남아있어 if (gameObject != null) 조건문을 통과해 버리는 치명적인 버그가 발생한다.

이를 막기 위해 유니티는 암묵적 Bool 변환 발생 시, C# 껍데기 뿐만 아니라 C++ 네이티브 객체가 실제로 살아있는지 (IsNativeObjectAlive)까지 검사하도록 내부 동작을 덮어씌운 것이다.

이러한 암묵적 변환은 UnityEngine.Object를 상속받는 모든 유니티 엔진 기반 객체들에게 적용된다.

GameObject, Component, MonoBehavior, ScriptableObject 등 그 외 유니티 에셋 타입들 모두 적용된다.

반대로 기본 자료형들과 순수 C# 클래스, 인터페이스 들은 지원하지 않는다.

기본 자료형의 경우 num != 0 같은 형태로 비교해야하고

string의 경우 반드시 string.IsNullOrEmpty 등으로 체크해야한다.

Unity : 같은 PC에서 클라이언트 여러개 실행시 멈추는 현상 (Firestore)

ellug — Sun, 8 Feb 2026 15:54:09 +0900

현상

Unity 프로젝트에서 Firebase Cloud Firestore를 사용할 때, 한 컴퓨터에서 클라이언트를 여러개 동시에 실행하면 완전히 멈춰버리거나 크래시가 발생하는 문제가 있었다.

원인 분석

사실 크게 기술적인 원인 분석을 한 부분은 없었다.

그런데도 왜 Firestore 라고 확신했냐면, Firebase Auth 도입 직후까지는 정상적으로 멀티 클라이언트 실행이 가능했던 프로젝트가 Firestore 도입 시점부터 바로 이런 현상이 발생했기 때문이다...

물리적으로 다른 원인이 있을 수 없었다.

하지만 Firestore가 원인이라고 해도 이해가 가질 않았다.

웹 에서 Firestore를 사용했던 경험으로는 하나의 컴퓨터에서 여러개의 브라우저, 여러개의 계정을 통해 Firestore에 아무리 접근해도 그 어떤 문제가 되지 않았기 때문이다.

해결 과정

1) 재현 조건

동일 PC에서 클라이언트를 2개 이상 동시에 실행

Firestore 사용 지점, 즉 로그인 지점 (해당 프로젝트에서는 로그인 직후 DB에서 회원 정보를 조회) 에서 문제가 발생하는 것으로 보임

2) 조사

Firestore는 성능 오프라인 동작을 위해 로컬에 캐시/DB를 유지(오프라인 지속성) 하는 구조를 가진다.

그리고 이 로컬 DB는 일반적으로 동일한 저장 경로에 대해 하나의 프로세스만 배타적으로 접근할 수 있다.

즉, 동일 PC에서 동일한 앱을 여러개 띄우게 되면

1번 인스턴스가 로컬 캐시 DB를 열고 "LOCK"을 잡는다.

2번 인스턴스도 동일한 경로의 DB를 열려고 시도한다.

LOCK을 얻지 못해 초기화에 실패하고 프리즈/크래시로 이어진다.

3) 그런데 왜 웹에서는 멀쩡했나?

이게 가장 의문점이었는데... 검색을 해보니 이미 안드로이드 앱에서도 비슷한 현상이 있었다는 리포트를 발견했다.

웹 SDK는 브라우저 저장소 기반이고, 탬 / 프로필 / 브라우저 단위로 저장소 분리 또는 조정이 되어있다.

반면 Unity나 일반적인 어플리케이션의 경우 동일한 실행 파일을 공유하는 형태로 동작한다.

이때 Firestore 로컬 캐시가 단일 경로를 점유해버리면 다중 프로세스에서 충돌이 발생한다.

즉, Firestore가 의도적으로 멀티 접근을 막은 게 아니라, 동일 PC 동일 앱의 로컬 캐시 저장소가 멀티 프로세스에 취약한 구조였다고 보는 편이 정답에 가깝다.

해결

해결법은 매우 간단했다.

Firestore 초기화 단계에서

FirestoreSettings.PersistenceEnabled = false;

한 줄만 초기화 해주면 된다.

이렇게 되면 로컬 DB를 사용하지 않게 되어, 동일 PC 다중 클라이언트 실행시 충돌이 발생하지 않게된다.

물론 일반적으로 다중 클라이언트 실행을 허가하는 게임은 많지 않기 때문에 개발 테스트 단계가 아니라면 굳이 필요 없어 보이긴 한다.

부작용

오프라인 캐시 기반 동작이 약해지기 때문에 네트워크 호출 효율성이 떨어질 수 있다.

즉, 네트워크 상황이 안 좋을 때 체감 성능이 떨어질 수 있기 때문에 사용 여부 및, 실제 배포 빌드에서 어떻게 할지에 대해 고민해볼 필요가 있다.

Unity : 관리자 콘솔 구현 및 프리징 현상 개선

ellug — Sun, 8 Feb 2026 15:22:27 +0900

Unity DevConsole 프리징 개선 기록 : 반복 에러 콜랩스 + Flush 예산화

1) DevConsole의 기존 작동방식과 핵심 기술

이 DevConsole은 유니티 로그를 받아서 콘솔 UI에 텍스트로 뿌리는 구조다.

핵심 흐름은 아래와 같았다.

Application.logMessageReceivedThreaded 콜백으로 로그를 수신한다.
유니티는 싱글쓰레드이기에 백그라운드 상의 멀티 쓰레드의 로그를 모두 수집하면 데드락 위험이 있어 lock 키워드를 통해 pending 버퍼에 로그를 쌓는 방식으로 데드락을 방지했다.
콘솔이 열리면 버퍼에 쌓인 로그를 실제 콘솔 UI에 출력하는 lines 리스트에 옮긴다.
lines 전체를 StringBuilder에 합쳐서 출력한다.

추가로, “연속 중복(바로 직전 로그와 동일)”은 체크해서 count++ 형태로만 병합했다.

그래서 연속해서 같은 에러가 나오는 상황에서는 어느 정도 줄어드는 효과가 있을 것이라 예상했다.

2) 문제 발생: 장문의 반복 에러 + 콘솔 오픈 순간 병목

문제는 “연속 중복”이 아닌 형태로 반복이 터질 때다.

예를 들어 같은 예외가 프레임마다 계속 찍히지만, 중간에 다른 로그가 섞이거나 스택/메시지가 조금씩 달라지면 pending이 계속 커진다.

특히 병목이 크게 터지는 지점은 콘솔을 키는 순간이다.

pending이 많아진 상태에서 버퍼에서 라인으로 옮겨 출력하는 메서드들이 한 번에 몰아서 실행된다
BuildText()가 lines 전체를 매번 문자열로 재구성한다
기존 코드에서 pending → lines 병합 시 count만큼 반복하는 루프가 있다
- 즉, “반복 수가 커질수록” 병합 비용이 기하급수적으로 늘어난다

결과적으로 “콘솔을 켰을 뿐인데 프레임이 몇 초 멈추는 현상"이 발생했다.

3) 해결 아이디어 정리

문제를 정확히 쪼개면 두 가지다.

1. 반복 로그를 출력 순간에 합치니 부하가 생긴다.

콘솔을 열 때 몰아서 처리하니까 스파이크가 생긴다.
해결 방향: 로그가 들어오는 시점에서 “동일 로그”를 바로 집계(콜랩스)한다.

2. Flush/병합을 한 프레임에 다 한다

버퍼 이동, 병합, 문자열 출력을 한 프레임에 다 처리하니 부하가 한 곳에 몰려 프리징 현상이 생긴다.
해결 방향: 프레임 예산(time/개수)을 두고 나눠 처리한다

부가로, 기존 count만큼 반복해서 증가시키는 로직도 꼭 필요해 보이진 않았다.

count를 통째로 더하는 AddCount()로 O(1) 병합하는 방향으로 수정해보자.

4) 해결법 실적용

(1) pending을 List → Dictionary 집계로 변경한다

동일 로그를 구분하는 키를 만든다.

Key 구조체: LogType + msg + stack
문자열 비교지만 해시를 미리 계산해둬서 딕셔너리 조회를 빠르게 한다

pending에 쌓는 방식이 이렇게 바뀐다.

기존: List<LogItem> _pending에 계속 append
변경: Dictionary<LogKey, LogItem> _pendingDict에서 동일 키면 count++, 없으면 새 항목 추가

여기서 표시 순서는 유지하고 싶으니 별도의 _pendingOrder로 키 삽입 순서를 기록한다.

(2) Flush를 프레임 예산으로 쪼갠다

콘솔이 열렸을 때 pending을 lines로 옮기는 작업을 한 번에 하지 않는다.

MaxFlushPerFrame: 프레임당 최대 처리 개수
MaxFlushTimeMs: 프레임당 최대 처리 시간(ms)

이렇게 하면 pending이 아무리 많아도 프리징 대신 천천히 반영된다.

모든 로그를 꼭 한 번에 출력할 필요가 없으며, 애초에 보여줘도 인간은 인식하지도 못한다.

UI는 즉시 열고 [Loading logs...] 같은 메시지를 먼저 보여주면 체감도 좋아진다.

웹 프론트엔드에서 사용하던 Lazy Loading 에서 출발한 아이디어다.

(3) count 병합을 O(1)로 바꾼다

기존에는 병합 시 for (k < it.count) Increment()로 반복했는데, 이게 반복 폭탄에서 최악이었다.

이를 아래처럼 바꾼다.

AddCount(now, add)로 count += add를 한 번에 처리
반복 수가 많아도 병합 비용은 동일하다

(4) 요약

수집한 쓰레드를 List에 append하지 않고 dict에 집계한다.
flush 연산을 분할시켜서 부하를 여러 프레임에 분산시킨다.
Increment 반복 제거 → AddCount로 한 번에 더한다.

5) 기대효과

이 방식으로 기대하는 효과는 다음과 같다.

콘솔을 켜도 순간적인 프리징 현상이 일어나지 않는다.
반복 에러는 “동일 키 1줄 + count 증가”로 수렴한다.
pending이 길게 쌓여도 오픈 순간에 폭발하지 않는다.
최악 상황에서 성능이 “스파이크”가 아니라 “점진 처리”로 바뀐다.

사실상 부하 문제를 완전히 없애는 것이 아니라 통제 가능한 비용으로 바꾼 것에 가깝다.

6) 결과

프리징 현상을 수치로 기록하지 않았던 것은 아쉽지만 명백히 프리징이 발생한다, 발생하지 않는다로 관측할 수 있었다.
에러 로그가 과도하게 쌓였을때 콘솔을 열어도 더이상 프리징 현상이 발생하지 않는 것을 확인했다.
가시적으로 프리징 현상이 사라졌기 때문에 별도의 성능 차 기록은 생략했다.

Unity : Firebase 등록 및 Auth로 (이메일/소셜) 로그인 구현

ellug — Sun, 11 Jan 2026 15:17:19 +0900

Firebase

애플리케이션 개발 시 백엔드 인프라 구축의 번거로움을 최소화하는 BaaS(Backend as a Service) 플랫폼이다.

서버 코드 작성 및 인프라 관리 부담을 줄여 개발 효율성을 극대화하는 것을 목적으로 한다.

즉, 우리는 Firebase를 이용해 간단한 인증부터 DB, API까지 여러 방면으로 서버 개발 없이 빠르게 활용할 수 있다.

Firebase 등록 방법

1. Firebase 검색 후 Firebase - Google 페이지로 들어간다

2. Get started in console

3. 새 Firebase 프로젝트 만들기 클릭해서 프로젝트 만들기

4. 프로젝트 생성

프로젝트 이름을 지정하고 그 뒤에 Gemini 애널리틱스 사용 여부를 묻는데 그냥 둘다 사용 안 해도 된다.

애널리틱스는 서비스 사용량, 트래픽 분석 도구 같은 거니 필요한 경우에만 체크하면 된다.

5. 프로젝트 생성 완료

생성 완료시 최초로 다음과 같은 화면이 보인다.

6. 프로젝트 세팅

좌상단의 프로젝트 개요 옆에 있는 톱니바퀴를 클릭하면 프로젝트 설정 메뉴가 나온다

프로젝트 설정을 클릭하고 들어가면 아래와 같은 창이 뜬다.

유니티 프로젝트에 사용할 것이니 하단의 내 앱 쪽에서 유니티 로고를 클릭해준다.

적당히 앱 이름 등록해주고

google-services.json 다운로드를 클릭해 json 파일을 받아 Assets 폴더에 넣어준다.

json 파일은 파이어베이스에 접근하기 위한 key 등 주요 데이터가 들어있기 때문에 git에 업로드 하거나 함부로 노출하면 안되니 주의하자.

SDK zip을 다운받아준다.

SDK zip 안에는 Firebase의 각종 서비스에 대한 패키지 파일들이 들어있다.

크기가 그리 가볍진 않으니 내가 필요한 서비스만 유니티 프로젝트에 임포트 해주자.

여기까지 했으면 기본적인 등록은 끝났다. 다음은 인증 서비스를 만들어 보자.

Authentication 설정

Firebase Authentication은 애플리케이션의 사용자 인증 시스템을 구축하기 위한 관리형 서비스이다.

복잡한 인증 로직(암호화, 세션 유지, 보안 토큰 관리 등)을 직접 구현하지 않고 SDK 호출만으로 처리할 수 있도록 설계되어있는 매우 편리한 기능이다.

설정을 순차적으로 알아보자.

1. Authentication 활성화

이번에 사용해볼 건 Auth, 즉 인증(회원가입/로그인) 기능이다.

좌측의 빌드 탭을 클릭하면 리스트가 나온다.

Authentication 을 클릭하면 다음과 같은 창이 뜬다.

시작하기 버튼을 눌러 Authentication을 활성화 한다.

2. 로그인 방법 설정

우선 이메일/비밀번호와 추가 제공업체 Google을 클릭해서 활성화 해주자

그럼 이런 창이 뜬다.

등록이 완료 된 거다.

3. 사용자 탭에서 유저 리스트를 확인할 수 있다.

여기서 사용자의 고유값은 최 우측의 사용자 UID 값이다.

식별자, 닉네임 등 다른 수치는 사용자의 고유함을 보장하기 어려울 수 있기에 유저 식별에는 이 UID값을 활용하도록 하자.

이러면 등록 끝

이메일 / 비밀번호 기반 로그인 구현하기

1. FirebaseApp 초기화 및 의존성 검사

Firebase 기능을 사용하기 전, 가장 먼저 실행해야하는 단계다.

기기에 구글 플레이 서비스가 최신 상태인지 확인하고 SDK를 초기화 한다.

FirebaseApp.CheckAndFixDependenciesAsync();

위 메서드는 유니티 실행시 비동기로 환경을 체크하며, DependencyStatus.Available 상태일 때

FirebaseAuth.DefaultInstance 를 통해 인증 인스턴스를 가져온다.

2. 회원 가입

신규 사용자를 등록하는 단계다. 이메일과 비밀번호를 파라미터로 전달한다.

CreateUserWithEmailAndPasswordAsync(email, password);

놀랍도록 직관적인 메서드명...

3. 사용자 프로필 업데이트 (Nickname 설정)

사용자의 닉네임도 설정해줄 수 있다.

UpdateUserProfileAsync(UserProfile);

UserProfile을 생성하고, DisplayName 속성에 원하는 닉네임을 할당한다.

user.UpdateUserProfileAsync(profile) 을 호출해 사용자 정보를 갱신할 수 있다.

4. 로그인

SignInWithEmailAndPasswordAsync(email, password);

입력한 정보 (email, password)가 일치하면 FirebaseUser 객체를 반환합니다.

실패시 FirebaseException을 통해 비밀번호 불일치, 존재하지 않는 사용자 등의 구체적인 에러 코드를 확인할 수 있습니다.

전체 코드

using System;
using System.Collections;
using System.Threading.Tasks;
using Firebase;
using Firebase.Auth;
using Firebase.Extensions;
using TMPro;
using UnityEngine;
using UnityEngine.UI;

public class FirebaseAuthManager : MonoBehaviour
{
    [Header("UI References")]
    [SerializeField] private TMP_InputField _emailField;
    [SerializeField] private TMP_InputField _pwField;
    [SerializeField] private TMP_InputField _nicknameField;
    [SerializeField] private Button _startButton;
    [SerializeField] private TMP_Text warningText;
    [SerializeField] private TMP_Text confirmText;

    // 인증 관련 핵심 객체
    public static FirebaseAuth auth; // Firebase 인증 서비스 인스턴스
    public static FirebaseUser user; // 현재 인증된 사용자 정보 (UID, DisplayName 등 포함)

    void Awake()
    {
        // [초기화] 구글 서비스 의존성 검사 및 Firebase 초기화
        FirebaseApp.CheckAndFixDependenciesAsync().ContinueWithOnMainThread(task =>
        {
            var dependencyStatus = task.Result;
            if (dependencyStatus == DependencyStatus.Available)
            {
                auth = FirebaseAuth.DefaultInstance;
                Debug.Log("Firebase Auth Init Complete");
            }
            else
            {
                Debug.LogError($"Firebase dependencies not resolved: {dependencyStatus}");
            }
        });
    }

    void Start()
    {
        _startButton.interactable = false;
        warningText.text = "";
        confirmText.text = "";
    }

    // --- Public Interface (버튼 연결용) ---

    public void OnClickLogin()
    {
        StartCoroutine(LoginCoroutine(_emailField.text, _pwField.text));
    }

    public void OnClickSignUp()
    {
        StartCoroutine(SignUpCoroutine(_emailField.text, _pwField.text, _nicknameField.text));
    }

    // --- Authentication Logic ---

    /*
     * [로그인] 이메일과 비밀번호를 이용한 인증 메서드
     * 성공 시 유저 정보를 획득하고 시작 버튼을 활성화함
     */
    private IEnumerator LoginCoroutine(string email, string pw)
    {
        Task<AuthResult> loginTask = auth.SignInWithEmailAndPasswordAsync(email, pw);
        yield return new WaitUntil(() => loginTask.IsCompleted);

        if (loginTask.Exception != null)
        {
            HandleAuthError(loginTask.Exception);
        }
        else
        {
            user = loginTask.Result.User;
            warningText.text = "";
            confirmText.text = "Login Success!";
            _nicknameField.text = user.DisplayName;
            _startButton.interactable = true;
        }
    }

    /*
     * [회원가입] 계정 생성 및 닉네임 설정 로직
     * CreateUser 후 UpdateUserProfileAsync를 통해 DisplayName(닉네임)을 서버에 등록
     */
    private IEnumerator SignUpCoroutine(string email, string pw, string nickName)
    {
        // 1. 계정 생성 시도
        Task<AuthResult> signUpTask = auth.CreateUserWithEmailAndPasswordAsync(email, pw);
        yield return new WaitUntil(() => signUpTask.IsCompleted);

        if (signUpTask.Exception != null)
        {
            HandleAuthError(signUpTask.Exception);
        }
        else
        {
            user = signUpTask.Result.User;

            if (user != null)
            {
                // 2. 닉네임(UserProfile) 설정
                UserProfile profile = new UserProfile { DisplayName = nickName };
                Task profileTask = user.UpdateUserProfileAsync(profile);
                yield return new WaitUntil(() => profileTask.IsCompleted);

                if (profileTask.Exception != null)
                {
                    HandleAuthError(profileTask.Exception);
                }
                else
                {
                    warningText.text = "";
                    confirmText.text = "Sign Up & Profile Set Complete!";
                    _startButton.interactable = true;
                }
            }
        }
    }

    /*
     * [에러 핸들링] Firebase 인증 과정에서 발생하는 에러 코드를 분석하여 UI에 출력
     */
    private void HandleAuthError(AggregateException exception)
    {
        FirebaseException firebaseEx = exception.GetBaseException() as FirebaseException;
        AuthError errorCode = (AuthError)firebaseEx.ErrorCode;

        string message = errorCode switch
        {
            AuthError.MissingEmail => "이메일을 입력해주세요.",
            AuthError.MissingPassword => "비밀번호를 입력해주세요.",
            AuthError.WrongPassword => "비밀번호가 틀렸습니다.",
            AuthError.InvalidEmail => "유효하지 않은 이메일 형식입니다.",
            AuthError.UserNotFound => "존재하지 않는 사용자입니다.",
            AuthError.WeakPassword => "비밀번호가 너무 취약합니다.",
            AuthError.EmailAlreadyInUse => "이미 가입된 이메일입니다.",
            _ => "알 수 없는 에러가 발생했습니다."
        };

        warningText.text = message;
        confirmText.text = "";
        Debug.LogWarning($"Auth Error: {errorCode}");
    }
}

대부분의 에러도 Firebase에서 정의해뒀으므로 관리가 편리한 편이다.

유니티에 간단하게 로그인창 만들어서 적용해보면

잘 작동 한다

Google 소셜 로그인

1. 로그인 방법에서 Google이 활성화 되어있어야 한다.

또한 안드로이드 빌드시 SHA-1 등록을 해야하니 주의하자.

2. 코드

using Google; // Google Sign-In SDK 필요

// ... 기존 변수 선언부 아래에 추가
[SerializeField] private string _webClientId = "YOUR_WEB_CLIENT_ID.apps.googleusercontent.com";

public void OnClickGoogleLogin()
{
    Configuration configuration = new Configuration
    {
        WebClientId = _webClientId,
        RequestIdToken = true
    };
    GoogleSignIn.Configuration = configuration;
    GoogleSignIn.Configuration.UseGameSignIn = false;
    GoogleSignIn.Configuration.RequestIdToken = true;

    GoogleSignIn.DefaultInstance.SignIn().ContinueWithOnMainThread(task =>
    {
        if (task.IsFaulted)
        {
            Debug.LogError("Google Sign-In Failed");
        }
        else if (task.IsCanceled)
        {
            Debug.Log("Google Sign-In Canceled");
        }
        else
        {
            // Google에서 획득한 ID 토큰으로 Firebase 인증 시도
            StartCoroutine(SignInWithGoogleCoroutine(task.Result.IdToken));
        }
    });
}

/*
 * [Google 인증] Google ID 토큰을 Firebase Credential로 변환하여 로그인
 */
private IEnumerator SignInWithGoogleCoroutine(string idToken)
{
    // 1. Google 인증 정보를 Firebase용 Credential로 변환
    AuthCredential credential = GoogleAuthProvider.GetCredential(idToken, null);

    // 2. 변환된 Credential로 Firebase 로그인
    Task<AuthResult> loginTask = auth.SignInWithCredentialAsync(credential);
    yield return new WaitUntil(() => loginTask.IsCompleted);

    if (loginTask.Exception != null)
    {
        HandleAuthError(loginTask.Exception);
    }
    else
    {
        user = loginTask.Result.User;
        confirmText.text = $"Google Login Success: {user.DisplayName}";
        _startButton.interactable = true;
        
        // 소셜 로그인은 이미 닉네임이 있으므로 필드에 자동 채우기
        _nicknameField.text = user.DisplayName;
    }
}

기존 코드에 이 코드를 추가하면 된다.

구글 로그인에 사용되는 각 주요 메서드들은 다음과 같다.

// 1. Google 로그인 설정 (Configuration) : Google SDK에 인증 요청 사양을 전달.
Configuration configuration = new Configuration
{
    WebClientId = "YOUR_WEB_CLIENT_ID", // Firebase와 연동하기 위한 필수 키
    RequestIdToken = true,               // Firebase 인증에 필요한 ID 토큰 요청 여부
    RequestEmail = true                  // 유저의 이메일 정보 접근 권한 요청
};

// 2. Google 계정 선택 및 인증 (SignIn) : 
// 비동기(Task)로 동작하며, 성공 시 유저의 신원 정보가 담긴 Task 결과를 반환.
GoogleSignIn.DefaultInstance.SignIn().ContinueWithOnMainThread(task => {
    // task.Result를 통해 GoogleSignInUser 객체에 접근 가능
});

// 3. Firebase용 자격 증명 생성 (GetCredential)
// Google로부터 받은 ID 토큰을 Firebase 시스템이 인식할 수 있는 'Credential'로 변환
// idToken: GoogleSignInUser로부터 획득한 고유 토큰
AuthCredential credential = GoogleAuthProvider.GetCredential(idToken, null);

// 4. 자격 증명을 이용한 최종 로그인 (SignInWithCredentialAsync)
// 변환된 Credential을 Firebase 서버에 제출하여 최종 세션을 획득
Task<AuthResult> loginTask = auth.SignInWithCredentialAsync(credential);

/* 5. 사용자 정보 참조 (FirebaseUser)
 * 주요 프로필 속성: 
 * - user.UserId: 서비스 내 고유 식별자 (UID)
 * - user.DisplayName: Google 계정에 설정된 이름
 * - user.PhotoUrl: Google 프로필 이미지 경로
 */
FirebaseUser user = loginTask.Result.User;

여기서 ContinueWithOnMainThread를 쓰는 이유에 대해 의문을 품을 수 있다.

ContinueWith : 작업 완료 후 백그라운드 스레드에서 후속 로직을 실행 → Unity에서 에러 발생

ContinueWithOnMainThread : 작업 완료 후 실행 흐름을 유니티 메인 스레드로 강제 전환하여 안전하게 실행

간단하게 Unity는 라이프사이클 정책상 싱글쓰레드로 동작하기 때문에 ContinueWithOnMainThread를 사용하는 것이다.

끝끝끝

Unity Network : Photon Pun2 - PhotonView, IPunObservable, RPC

ellug — Wed, 7 Jan 2026 17:04:32 +0900

PhotonView

Photon 네트워크에서 동기화 단위의 기준점
네트워크 상에서 하나의 오브젝트를 식별하는 ID
RPC, 변수 동기화, Ownership 판단의 기준
PhotonView가 없는 오브젝트는 네트워크에 존재하지 않는다

역할	설명
네트워크 ID	ViewID로 객체 식별
소유권 관리	Owner / IsMine
RPC 송신	View 기준 호출
변수 동기화	Observe 대상 지정

PhotonView pv;

pv.IsMine				// 내가 소유한 오브젝트인가
pv.Owner				// 소유 Player
pv.Owner.ActorNumber	// pv의 인덱스처럼 1000씩 증가하는 고유 값
pv.ViewID				// 네트워크 고유 ID

pv.RPC(함수명, RpcTarget.Others, 함수 파라미터);

IPunObservable : 변수 동기화

변수의 상태를 지속적으로 동기화하는 방식
위치, 회전, 체력, 속도 등
상태(State) 동기화 활용
매 프레임 or 고정 주기로 전송

public class PlayerSync : MonoBehaviour, IPunObservable
{
    public float hp;

    public void OnPhotonSerializeView(PhotonStream stream, PhotonMessageInfo info)
    {
        if (stream.IsWriting)
            stream.SendNext(hp);
        else
            hp = (float)stream.ReceiveNext();
    }
}

Writing : Owner가 데이터 전송
Readding : 다른 클라이언트가 수신
Owner → Others 단방향
PhotonView의 Observe 대상에 등록되어야 동작

적합한 경우	부적합한 경우
위치, 회전	단발성 이벤트
체력, 쿨타임	버튼 클릭
애니메이션 파라미터	공격 판정

RPC (Remote Procedure Call) : 함수 동기화

메서드 호출 사실을 네트워크로 전파하는 방식
이벤트 기반
한 번만 실행
명확한 타이밍 보장

[PunRPC]
void PlayHitEffect(int damage)
{
    Debug.Log($"Hit: {damage}");
}

pv.RPC("PlayHitEffect", RpcTarget.All, 10);

RPC에 사용할 메서드에는 [PunRPC] 해줘야 한다

RPC Target 종류

All	모든 플레이어
Others	나 제외
MasterClient	방장
AllBuffered	늦게 들어온 플레이어도 실행

IPunObservable vs RPC

	IPunObservable	RPC
성격	상태 동기화	이벤트 전달
호출 방식	자동	수동
빈도	지속적	단발
신뢰성	상태 기준	호출 기준
대표 용도	위치, 체력	공격, 이펙트

IPunObservable 과 RPC 중 무엇을 어디에 사용할지 적절히 설계하는 것이 중요

동작 예시 시나리오

입력은 IsMine 에서만 처리

if (!pv.IsMine) return;
HandleInput();

상태는 IPunObservable, 결과는 RPC

체력 감소 : IPunObservable
피격 이펙트 : RPC

RPC 남발은 네트워크 부하의 원인이 될 수 있으므로 상태 동기화는 Observable로 해결하는 게 좋다고 한다

또한 모든 클라이언트에서 로직을 실행하지 않도록 주의하자.

어떤 로직을 누가 실행할지를 잘 설계하고 방어코드를 작성해야 한다.