개발하는 서버

스트리밍 서비스 최적화를 위한 Chrome Extension 개발기 (StreamLite) - 2

싹다배워 — Thu, 2 Apr 2026 19:02:19 +0900

이전에 제작했던 크롬 확장 프로그램이 이번 업데이트(2.1v 릴리즈)를 통해 한 단계 더 개선했다.

기존에는 YouTube 시청 환경 최적화에 집중했다면, 이제는 Netflix까지 지원 범위를 확장하여 보다 몰입감 있는 콘텐츠 시청 환경을 제공한다.

주요 업데이트 내용

1. Netflix 최적화 기능 추가

이번 업데이트의 핵심은 바로 넷플릭스 지원이다.

넷플릭스 접속 시 아래 기능이 자동으로 적용된다.

메인 화면 광고 요소 제거
자동 재생되는 미리보기 영상 차단

넷플릭스를 이용하다 보면 의도하지 않은 미리보기 영상이 자동으로 재생되거나 불필요한 UI 요소로 인해 집중이 깨지는 경우가 있는데, 이번 기능을 통해 훨씬 깔끔하고 집중도 높은 시청 환경을 경험할 수 있다.

2. 성능 개선 및 안정화 작업

기존에 적용되어 있던 YouTube 관련 기능들도 그대로 유지되며, 내부적으로 성능 개선(리팩토링)이 함께 진행됐다.

지속적인 테스트를 통해 코드 전반을 점검하고 개선했다.

소스 코드 리팩토링 진행
일부 버그 수정
확장 프로그램 동작 안정성 향상
전반적인 퍼포먼스 최적화

사용 중 발생하던 자잘한 이슈들을 개선하여 보다 안정적으로 사용할 수 있도록 보완했다.

마무리

이번 업데이트를 통해 단순한 유튜브 최적화 도구를 넘어
멀티 플랫폼(YouTube + Netflix) 시청 최적화 확장 프로그램으로 발전한 느낌이다.

앞으로도 추가적인 기능 개선과 다양한 플랫폼 지원을 계속 확장해 나갈 예정이다.

chrome 웹 스토어에 올려둔 확장 프로그램은 아래 링크를 통해 다운로드 가능합니다!

https://chromewebstore.google.com/detail/kckfmemgmphngdofnnkaiikhbmgjdmci?utm_source=item-share-cb

StreamLite - Chrome 웹 스토어

유튜브와 넷플릭스 성능 최적화 확장 프로그램

chromewebstore.google.com

Gmail POP3 종료 (IMAP 전환 배경 정리)

싹다배워 — Thu, 19 Mar 2026 22:00:10 +0900

Gmail 외부 메일 통합 기능 종료

최근 Gmail에서 중요한 정책 변경이 발표되었다.

기존에 제공하던 다음 기능들이 단계적으로 종료된다.

POP3 기반 ‘다른 계정에서 메일 확인’
Gmailify (외부 메일을 Gmail처럼 관리)

일정

신규 사용자: 2026년 1분기부터 사용불가
기존 사용자: 2026년 말에 기능이 중단될 때까지 계속 사용 가능

기존에 연결된 계정은 일시적으로 유지될 수 있지만, 신규 연동은 제한되며 결국 완전히 사라지게 된다.

기존 POP3 역할

많은 사용자들이 Gmail 하나로 다음과 같은 메일을 통합 관리해왔다.

네이버 메일
회사 메일
기타 외부 이메일 계정

이 기능은 내부적으로 POP3 방식을 사용했다.

- Gmail이 외부 메일 서버에 접속해서 메일을 “가져오는(pull)” 구조였다.

왜 POP3만 사라지는가?

이건 단순 기능 제거가 아니라 메일 사용 패러다임 변화라고 보여진다.

1. 멀티 디바이스 시대와 맞지 않는 구조

POP3는 기본적으로:

메일을 내 기기로 다운로드하는 방식

그래서 이런 문제가 발생한다.

PC에서 읽은 메일 → 모바일에서 안 보임
읽음/안읽음 동기화 불가
폴더 및 정리 상태 공유 안됨

반면 IMAP은:

서버에 메일을 두고 모든 기기가 동기화

스마트폰 + PC + 태블릿 환경에서는 IMAP이 사실상 표준인 것이다.

2. 클라우드 기반 메일 서비스와 충돌

요즘 메일 서비스는 단순 수신함이 아니다.

검색 기능
스팸 필터링
자동 분류
AI 기반 메일 정리

이 모든 기능은 서버 중심 구조에서 동작한다.

하지만 POP3는 메일을 가져가버리기 때문에 서버 기능 활용이 제한된다..

3. 보안 및 인증 문제

POP3는 오래된 프로토콜이라:

최신 인증(OAuth 등)과 호환성 낮음
계정 탈취 시 전체 메일 다운로드 가능
접근 제어 및 로그 관리 어려움

반면 IMAP은 보안 정책 적용이 훨씬 유리하다.

(안전하다는 것은 아니다.. POP3에 비해서 그렇다는거지~)

4. 운영 비용과 비효율

Gmail의 외부 메일 가져오기 기능은 주기적으로 외부 서버에 접속해서 메일을 가져오는 Polling 구조인데

위 방식은:

트래픽 낭비
지연 발생
실패/중복 이슈
운영 비용 증가

구글 같은 세계적인 대규모 서비스에서는 이 비용이 매우 크게 작용할 것이다.

그래서 IMAP + 전달 방식으로 바뀐다

Gmail이 제시하는 대안은 크게 두 가지다.

1. 메일 전달(Forwarding)

외부 메일 → Gmail로 자동 전달
Push 방식이라 효율적

2. IMAP 기반 메일 클라이언트 사용

Outlook, Thunderbird 등
여러 계정을 한 번에 관리 가능

핵심 변화 정리

구분	POP3	IMAP
방식	다운로드	서버 동기화
기기 연동	X	O
보안	낮음	높음
클라우드 기능	제한	완전 활용
운영 효율	낮음	높음

메일을 가져오는 시대 → 메일을 공유하는 시대로 변화

실무 관점에서 느낀 점

이번 정책 변경은 단순 기능 종료가 아니라 업무 방식 자체를 바꾸는 변화다.

특히 기업 환경에서는 하나의 Gmail로 여러 메일을 관리하던 사용자, 외부 메일을 Gmail에 의존하던 조직과 같은 경우 반드시 대응이 필요하다.

예상되는 사용자 반응

왜 갑자기 안 되나요. 이거 원래 잘 쓰던 기능인데. 왜 기술이 발전하는데 더 불편해지지?

실제로는 불편해졌다기보다 방식이 바뀐 것인데.. 변화를 어떻게 받아드리느냐에 따라서 반응이 나누어지는 것 같다.

스트리밍 서비스 최적화를 위한 Chrome Extension 개발기 (StreamLite) - 1

싹다배워 — Thu, 12 Mar 2026 21:39:14 +0900

https://chromewebstore.google.com/detail/kckfmemgmphngdofnnkaiikhbmgjdmci?utm_source=item-share-cb

StreamLite - Chrome 웹 스토어

유튜브와 넷플릭스 성능 최적화 확장 프로그램

chromewebstore.google.com

YouTube는 다양한 추천 영상, 댓글, Shorts, 라이브 채팅 등 많은 UI 요소를 제공하지만 사용 목적에 따라서는 이러한 요소들이 오히려 집중도를 떨어뜨리고 페이지 성능에도 영향을 줄 수 있다.

그래서 이번 프로젝트에서는 YouTube 페이지를 단순화하고 성능을 개선하는 Chrome 확장 프로그램 StreamLite를 개발하였다.

메인화면

프로젝트 목표

이 확장 프로그램의 최초 목표는 크게 두 가지였다.

YouTube 페이지에서 불필요한 요소 제거
페이지 성능 변화를 사용자에게 시각적으로 제공

즉, 단순한 UI 제거 확장이 아니라 성능 개선 효과까지 확인할 수 있는 확장 프로그램을 목표로 했다.

그런데 왜 YoutubeLite가 아니라 StreamLite냐?

최초 목표는 Youtube에 대한 개선이고 추후 릴리즈를 통해 Netflix, Disneyplus, Twitch 등 스트리밍 플랫폼에 대한 성능 개선까지 확장할 예정으로 명칭을 지었다.

주요 기능

1️⃣ YouTube UI 최적화

사용자가 선택적으로 다음 요소들을 제거할 수 있도록 구현하였다.

추천 영상
댓글
Shorts
라이브 채팅

사용자가 설정을 변경하면 해당 설정이 즉시 적용되며, 비활성화 시에는 페이지 새로고침을 통해 정상적으로 복구된다.

2️⃣ Performance Monitor

페이지 성능 변화를 확인할 수 있도록 성능 모니터링 기능을 추가하였다.

수집 데이터

Memory Usage
CPU Usage
DOM Nodes

이 데이터를 기반으로 실시간 그래프를 표시한다.

3️⃣ Performance Score

단순한 수치 대신 직관적인 성능 점수를 제공한다.

Score 계산 기준

Memory 40%
CPU 40%
DOM Nodes 20%

점수 상태

80 ~ 100  Good
40 ~ 79   Normal
0 ~ 39    Heavy

이를 통해 사용자는 현재 페이지 상태를 쉽게 이해할 수 있다.

4️⃣ Optimization Impact 분석

최적화 기능 적용 전후의 성능 변화를 분석하여 성능 개선 효과를 사용자에게 보여준다.

예시

Performance Improvement

Page Elements Reduced   ↓ 32%
Memory Usage Reduced    ↓ 18%

5️⃣ YouTube 페이지 자동 감지

확장 프로그램은 현재 페이지가 YouTube인지 자동으로 감지한다.

UI 표시

  YouTube ✅
⚪ YouTube ❌

또한 최적화 기능이 활성화되었는지도 함께 표시한다.

  Optimization ✅
⚪ Optimization ❌

다국어 지원

사용 편의성을 위해 다국어 지원 시스템도 구현하였다.

지원 언어

한국어
English

Chrome Extension의 _locales 구조를 사용하여 구현하였다.

_locales
 ├ ko
 │   └ messages.json
 └ en
     └ messages.json

UI/UX 개선

초기 버전에서는 단순한 설정 UI였지만 Chrome Web Store 수준의 UX를 목표로 다음 요소들을 추가하였다.

카드 기반 UI
토글 스위치
실시간 성능 그래프
성능 점수 표시
상태 표시 패널

기술 스택

이번 프로젝트에서 사용한 기술

Chrome Extension (Manifest V3)
JavaScript
Chart.js
HTML / CSS
Chrome Storage API
Chrome Tabs API

마무리

이번 프로젝트를 통해

Chrome Extension 구조 이해
브라우저 API 활용
사용자 경험(UI/UX) 개선

등 다양한 경험을 할 수 있었다.

StreamLite는 단순한 기능 구현을 넘어 사용자가 성능 변화를 직접 확인할 수 있는 확장 프로그램이라는 점에서 의미 있는 프로젝트였다.

앞으로도 지속적으로 개선해 나갈 예정이다.

SVN 저장소를 Git으로 백업 및 이관하기 (SVN → Git Migration)

싹다배워 — Fri, 6 Mar 2026 22:03:21 +0900

사내 프로젝트는 오래전부터 SVN(Subversion) 으로 소스코드를 관리하고 있었다.
하지만 대부분의 개발 조직이 Git 기반 협업 환경(GitHub / GitLab 등) 을 사용하고 있기 때문에, 기존 SVN 저장소를 사내 Git 서버로 백업 및 이관하는 작업을 진행하게 되었다.

이번 글에서는 실제 프로젝트를 이관하면서 진행했던 과정과 그 과정에서 겪었던 트러블슈팅까지 함께 정리해보려고 한다.

1. 목표

이번 작업의 목적은 단순히 소스를 옮기는 것이 아니라 아래와 같은 조건을 만족해야 했다.

기존 SVN 저장소는 그대로 유지
Git으로 전체 소스 백업
SVN Commit History 유지
사내 GitHub 서버(Gitea)로 Push

즉 구조는 다음과 같다.

SVN (기존 운영)
        ↓
Git 로컬 변환
        ↓
사내 GitHub 백업

2. 준비 환경

OS	Windows
Tool	Git
작업 경로	D:\svn_migration
SVN 저장소	https://test.com/project
Git 서버	사내 GitHub

먼저 Git에 SVN 명령어가 포함되어 있는지 확인한다.

git svn --version

3. SVN 구조 확인

SVN → Git에서 가장 중요한 단계는 바로 SVN 저장소 구조 확인이다.

svn list https://test.com/project

실행 결과(EX)

WebContent/
classes/
doc/

즉 SVN 구조가 다음과 같이 되어 있었다.

SVN
 └ project
     ├ WebContent
     ├ classes
     └ doc

여기서 중요한 점은 SVN 표준 구조(trunk / branches / tags)가 아니라는 것이다.

이 구조가 없기 때문에 git svn clone 명령어를 사용할 때 옵션을 다르게 줘야 한다.

4. SVN → Git 변환

작업 폴더 생성

D:\svn_migration

다음 명령어 실행(생성한 경로에서 실행이 필요)

git svn clone https://test.com/project --trunk=. project

옵션 설명

git svn clone	SVN 저장소를 Git으로 변환
--trunk=.	현재 루트를 trunk로 인식
homepage	로컬 폴더

실행하면 다음과 같이 SVN revision이 Git commit으로 변환된다.

r1 = a3f4e13213
r2 = b4c5d61241
r3 = 7a812442c0
...

5. 변환 완료 확인

변환이 완료되면 Git 로그를 확인한다.

cd project
git log

정상이라면 다음과 같이 SVN commit history가 Git commit으로 변환된 것을 확인할 수 있다.

commit a12345
Author: kim
게시판 수정

commit b23456
Author: lee
로그인 기능 추가

6. Git 서버 연결

GitHub에 Repository를 생성한 뒤 remote를 연결한다.

git remote add origin http://ip:port/github/project.git

연결 확인

git remote -v

7. GitHub Push

메인 브랜치 설정 후 push

git branch -M main
git push -u origin main

8. 트러블슈팅

1. trunk 관련 오류

처음에는 다음 명령어를 사용했다.

git svn clone https://test.com/project --stdlayout project

하지만 다음과 같은 오류가 발생했다.

fatal: refs/remotes/origin/trunk: not a valid SHA1

원인은 SVN 저장소에 trunk 구조가 없기 때문이었다.

아래와 같은 명령어로 해결

git svn clone https://test/homepage --trunk=. homepage

2. Git commit이 없는 문제

clone 이후 다음 오류 발생

fatal: your current branch 'master' does not have any commits yet

이 역시 SVN 구조를 잘못 인식해서 clone이 정상적으로 완료되지 않은 것이었다.

SVN 구조 확인 후 --trunk=. 옵션으로 해결..

3. Git Push 인증 오류

Git push 시 다음 오류 발생

fatal: Authentication failed

원인

Git 서버 인증 문제

해결

Git 계정 인증 (아이디 방식 사용)

git remote set-url origin http://아이디@ip:port/github/project.git

ex) git remote set-url origin http://test@127.0.0.1:1000/github/project.git

9. 최종 결과

최종적으로 다음 구조로 이관이 완료되었다.

SVN (기존 유지)
     │
     └── Git Migration
            │
            └── GitHub 백업

[형상관리] GitHub에 잘못 PUSH한 폴더 및 파일 완전 삭제하기 (BFG 사용)

싹다배워 — Wed, 4 Mar 2026 22:49:34 +0900

프로젝트를 진행하다가 Docker 설정 폴더를 GitHub에 실수로 Push하는 일이 발생했다.
단순히 git rm으로 삭제하면 최신 버전에서는 사라지지만, 히스토리에는 그대로 남아있다.

특히 설정 파일 안에 민감 정보(DB 계정, 내부 IP, Key 등)가 포함되어 있다면 반드시 히스토리까지 완전 삭제해야 한다.

이번 글에서는 BFG Repo Cleaner를 이용해 특정 폴더를 Git 히스토리에서 완전히 제거하는 방법을 정리한다.

1. 왜 git rm으로는 부족한가

git rm -r Docker
git commit -m "remove docker folder"
git push

위 방법은 현재 브랜치에서만 삭제된다.

하지만 Git의 과거 커밋 기록에는 Docker/ 폴더가 그대로 남아있다.

즉, 누군가 이전 커밋을 조회하면 파일을 다시 확인할 수 있다.

2. 해결 방법: BFG Repo Cleaner 사용

BFG는 Git 히스토리를 빠르게 정리해주는 도구다.
특정 파일이나 폴더를 과거 커밋에서 완전히 제거할 수 있다.

2-1. BFG 다운로드

https://rtyley.github.io/bfg-repo-cleaner/

BFG Repo-Cleaner by rtyley

$ bfg --strip-blobs-bigger-than 100M --replace-text banned.txt repo.git an alternative to git-filter-branch The BFG is a simpler, faster alternative to git-filter-branch for cleansing bad data out of your Git repository history: Removing Crazy Big Files Re

rtyley.github.io

bfg-x.x.x.jar 파일을 다운로드 한다.

2-2. GitHub 레포를 Mirror 모드로 Clone

git clone --mirror https://github.com/계정/레포명.git

ex) git clone --mirror https://github.com/user/github_project.git

위 명령어를 실행하면 bare repository를 생성한다.

2-3. BFG 실행 (폴더 전체 삭제)

다운로드한 bfg.jar 파일을 방금 생성된 .git 폴더 안에 넣는다.

그 후 아래 명령 실행

java -jar bfg.jar --delete-folders 폴더명 --no-blob-protection

ex) java -jar bfg.jar --delete-folders docker --no-blob-protection

옵션

--delete-folders docker : docker 폴더 전체 삭제

--no-blob-protection : 보호 옵션 무시 (완전 삭제)

- 폴더명은 대소문자를 정확하게 입력해야 한다.

2-4. Git 내부 정리 작업

BFG 실행 후에는 Git Garbage Collection을 진행해야 한다.

git reflog expire --expire=now --all
git gc --prune=now --aggressive

설명

- reflog 정리

- 삭제된 객체 완전 제거

- Git 내부 최적화

2-5. GitHub에 강제 Push

히스토리가 변경되었기 때문에 반드시 --force 옵션이 필요하다.

git push --force

협업자에게 반드시 알려줘야한다.. 히스토리가 재작성되기 때문이다.

2-6. BFG 실행 후 생성되는 폴더

작업 후 다음 폴더가 생성된다.

레포명.git.bfg-report

이 폴더는 단순 리포트 로그다. 삭제해도 무관.

3. 최종 정리

삭제해도 되는 것

레포명.git
레포명.git.bfg-report

유지해야 하는 것

실제 프로젝트 폴더

Git은 강력한 버전 관리 도구지만, 한 번 올라간 파일은 단순 삭제로 완전히 제거되지 않는다.

특히 설정 파일이나 Docker 환경 파일은 .gitignore로 사전에 관리하는 습관이 중요하다.

Docker 기반 웹 푸시 알림 시스템 - 5

싹다배워 — Wed, 4 Mar 2026 00:19:33 +0900

실제 로직 gif

PWA 웹 푸시 시스템 구축 최종 정리

1. 프로젝트 개요

이번 프로젝트의 목표는 PWA 웹 푸시 기능을 Docker 기반 구축하는 것이 목표였다.

단순히 기능 구현이 아니라,

실제 운영 서버 적용
Docker 기반 배포 환경 반영
Oracle 10g 사용 환경 고려
기존 통합 로그인 시스템과의 분리

를 기준으로 설계를 진행했다.

2. 기술 스택

최종 운영 환경은 다음과 같다.

[Backend]
- Spring Boot 3.5.9
- Java 17
- Spring Data JDBC
- Oracle 10g

[Infra]
- Docker (Rocky Linux)

[Frontend]
- PWA
- Service Worker
- Web Push API

[Push 인증]
- VAPID Key 기반 인증

특이사항:

로컬 / 운영 동일 버전 DB 사용
Oracle 10g 사용으로 최신 기능 제약 존재
ojdbc6 → ojdbc11 버전으로 수정

3. 초기 설계 vs 현실 설계

[초기 목적 및 설계]

사용자 테이블과 푸시 구독 정보 연계
통합로그인 시스템과 직접 연결
redis를 사용한 대량 발송 로직 처리

[현실적 제약]

통합로그인 시스템 연동 시 라이선스 및 구조 변경 이슈
브라우저 Service Worker를 활용해야하므로, endpoint 기준 관리 필요
memory Queue만으로도 충분하여 추후 확장 예정

4. 최종 적용 구조

푸시 구독 정보를 독립적으로 관리하여 아래와 같은 특징을 갖는다.

endpoint 기준 관리
중복 구독 방지 로직 적용
만료 구독 자동 삭제 처리

5. PWA 구성 요소

5-1. Service Worker 등록

navigator.serviceWorker.register('/sw.js')

5-2. VAPID 키 기반 구독 생성

const subscription = await registration.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: vapidPublicKey
});

5-3. 서버 저장 처리

endpoint
p256_key
auth_key
bros_type
os_type

DB 저장

6. 모바일 이슈 및 정책 정리

PC Chrome
- 정상 동작
Android Chrome, iOS Safari
- 홈 화면에 추가 후 실행 시 정상 동작
네이버 / 카카오 인앱 브라우저
- Push API 미지원

▶ 모바일은 브라우저 실행 상태가 아니라, 반드시 "설치형 PWA 상태"여야 동작한다는 점이 핵심이었다.

7. 운영 환경 구성

Docker 기반 컨테이너 운영(프록시 네트워크 구성)
Nginx Reverse Proxy 구성
HTTPS 필수 적용
VAPID Key 운영 서버 기준 발급 및 관리

8. 현재 완료 단계 정리

PWA 적용 완료
웹 푸시 구독 및 발송 기능 구현
모바일 정책 대응 가이드 적용
별도 구족 테이블 관리 구조 완성
확장 가능한 구조 유지 및 모듈화

9. 향후 개선 방향

사내 통합 로그인 시스템 연동 (endpoint + ID 기반 푸시 관리)
사용자 기반 푸시 타겟팅
구독 상태 모니터링 대시보드
장애 대응 자동화

10. 마무리

이번 프로젝트는 처음부터 "완성형 아키텍처"를 목표로 하지 않았다.

대신 Agile(애자일) 방식의 점진적 확정 전략을 선택했다.

애자일의 핵심은 다음과 같다.

처음부터 모든 것을 설계하지 않는다.
작게 만들고 빠르게 검증한다.
현실 제약 안에서 동작 가능한 결과물을 우선 제공한다.
이후 점진적으로 개선한다.

이번 PWA 기반 웹 푸시 시스템 역시 동일한 접근이었다.

초기 설계 단계에서는 사용자 테이블과 직접 연동되는 구조, 권한 기반 발송 제어, 통합 로그인 기반 사용자 식별 구조까지 고려했다.

그러나 실제 환경에서는 다음과 같은 현실적 제약이 존재했다.

사내 통합 로그인 시스템 연동 필요
라이선스 및 정책 이슈
조직 간 협의 절차
기존 시스템 영향도 검토

이러한 상황에서 이상적인 구조를 고집했다면 프로젝트는 시작조차 어려웠을 가능성이 높다.

그래서 선택한 방향은 명확했다.

“현실적으로 구현 가능한 최소 기능부터 완성한다.”

그 결과 현재 단계에서는:

PWA 기반 웹 푸시 구조 확립
모바일 정책 대응 구조 정리
별도 구독 테이블 기반 독립 구조 완성
운영 환경(Docker + HTTPS) 안정화

즉, 기능적으로는 독립 운영 가능한 1차 버전이 완성된 상태다.

향후 통합로그인 시스템이 도입되어 사용자 식별 기반 푸시 관리 구조로 확장될 경우, 이 프로젝트는 단순 기능 개선이 아닌 사내 인증 체계와 연결되는 대외비 성격의 프로젝트로 전환될 가능성이 높다.

이는 블로그에는 공개하기 어려운 영역으로 판단되어 기록은 여기까지 작성할 예정이다.

Docker 기반 웹 푸시 알림 시스템 - 4.5

싹다배워 — Thu, 12 Feb 2026 23:14:48 +0900

소스 형상관리 및 사내 Git 서버(Gitea) 연동

이번 단계에서는 프로젝트 소스 형상관리를 위해 Git을 도입하고,
초기 GitHub 연동 이후 사내 Git 서버(Gitea) 로 이전한 과정을 정리한다.

1. Git 도입 배경

Spring Boot 기반 웹 푸시 알림 서버를 개발하면서 다음과 같은 필요성이 있었다.

코드 변경 이력 관리
기능 단위 버전 관리
협업 및 추후 확장 대비
회사 내부 정책에 맞는 형상관리 체계 구축

초기에는 사이드 프로젝트 개념으로 GitHub Private Repository로 관리했으나,
추후 내부적으로 활용이 가능할 것으로 판단되어 사내 보안 정책에 따라 내부 Git 서버(Gitea)로 이전하게 되었다.

2. gitignore 구성

기존 연동했던 Github에선 IDE 설정 파일, 빌드 산출물, 민감 정보가 Git에 포함되지 않도록 구성했다.

내부 Git 서버로 이관 했을 때도 동일하게 유지했다. (민감 정보는 형상관리를 통해서가 아닌 내부적으로 관리 및 공유)

# IDE
.idea/
*.iml

# Build
.gradle/
build/

# Logs
logs/

# Spring Profile
application-local.properties        #개발 환경 설정
application-prod.properties         #운영 서버 설정

# Env
.env
*.key

3. Git 이관 과정

생각보다 매우 간단해서 어이가 없었다..

#기존 Remote 확인
git remote -v

#Gitea 저장소로 Remote 변경
git remote set-url origin http://사내Gitea주소/team/knunotify.git

#Push
git push -u origin main

기존 커밋 히스토리를 유지한 상태로 원격 저장소만 사내 Gitea 서버로 변경했다.

4. Gitea 사용 이유

Gitea는 경량 Git 서버로 다음과 같은 장점이 있다.

자체 서버 운영 가능
낮은 리소스 사용량
간단한 설치 (Docker 지원)
GitHub와 유사한 UI
내부망 운영 가능

특히 사내 보안 요구사항을 충족하면서도 GitHub와 유사한 사용 경험을 제공한다는 점이 장점이었다.

5. 마무리

이번 단계에서 프로젝트는 단순한 코드 저장 수준을 넘어 사내 정책에 맞는 형상관리 체계를 갖추게 되었다.

작게 시작했던 프로젝트가 어딘가에 쓰여진다는 기대감과 무게감으로 더욱 동기부여가 되었다.

연말정산 구조 쉽고 간단하게 알아보자

싹다배워 — Mon, 9 Feb 2026 21:53:00 +0900

1️⃣ 연말정산을 한 문장으로 요약하면

1년 동안 미리 낸 세금이 적절했는지 다시 계산해서 더 냈으면 돌려주고 덜 냈으면 추가로 받는 과정”

즉, 새로운 세금을 매기는 게 아니라 이미 낸 세금을 정산하는 것이다.

2️⃣ 연말정산 전체 프로세스 (큰 그림)

연말정산은 항상 아래 순서로 흘러간다.

연봉 (총급여)
 → 1. 자동으로 빼주는 금액 (근로소득공제)
 → 2. 세금 계산 기준 금액 (과세표준)
 → 3. 세율 적용 (누진세)
 → 4. 깎아줄 수 있는 세금 차감 (세액공제)
 → 5. 최종 세금
 → 6. 이미 낸 세금과 비교 후 환급 or 추가 납부

위 순서는 연봉이 얼마든 동일하다.

3️⃣ 단계별 구조를 쉽게 풀어보면

연봉 (총급여)

세전 연봉
상여금 포함

1. 근로소득공제 (자동계산)

“회사 다니는 사람이라서 깎아줌”

자동 적용
연봉이 높을수록 비율은 줄어듦

2. 과세표준

“세금 매길 진짜 기준 금액”

연봉 - 근로소득공제 - 기본공제(본인 1명) = 과세표준

여기서 산출된 과제표준 금액으로부터 세율이 붙는데, 인적공제(기본공제)는 본인 1명 기준으로 150만 원이다.

3. 세율 적용 (누진세)

낮은 구간은 낮은 세율
높은 구간은 높은 세율

연봉이 오를수록 세금이 급격히 늘어나는 느낌이 든다.

4. 세액공제

“여기서부터 전략의 영역”

카드
보험
의료비
교육비

연봉이 높을수록 전략을 통한 효과가 커진다.

5. 이미 낸 세금과 비교

많이 냈으면 → 환급
적게 냈으면 → 추가 납부

4️⃣ 이 구조 안에서 연봉에 따라서 비교하면?

이제 같은 구조에 연봉만 바꿔서 넣어보자.

비교 기준 (조건 통일)

근로소득자 (회사원)
부양가족 없음 (본인 1명)
비과세 수당 없음
주택자금·특별공제 없음
카드 사용은 평균 수준

연봉 차이만 놓고 구조 비교를 해보자.

연봉	연간 세금	체감
3,000만	약 120만	거의 안 냄
5,000만	약 390만	딱 중간
8,000만	약 1,000만	확 체감됨

연봉별 계산 구조 비교

연봉 3,000만원 계산 구조

총급여          30,000,000
근로소득공제   -10,000,000
기본공제        -1,500,000
과세표준 ≈      18,500,000

연봉 5,000만원 계산 구조

총급여          50,000,000
근로소득공제   -13,250,000
기본공제        -1,500,000
과세표준 ≈      35,250,000

연봉 8,000만원 계산 구조

총급여          80,000,000
근로소득공제   -16,500,000
기본공제        -1,500,000
과세표준 ≈      62,000,000

같은 금액의 공제라도 구조는 같지만

연봉에 따라서 세율이 다르기 때문에 절감 효과 차이가 크다.

[CS] 메일 헤더를 분석해보자

싹다배워 — Mon, 9 Feb 2026 18:10:44 +0900

메일 헤더(Header)란 무엇인가?

메일 헤더는 "이 메일이 어디서, 누구에 의해, 어떤 방식으로 전달되었는지"를 기록한 메일의 이력서 같은 존재다.

본문은 사용자에게 보이는 영역이라면 헤더는 메일 서버와 보안 시스템을 위한 영역이다.

스팸 분석, 위·변조 판단, 발송 경로 추적 시 가장 먼저 확인하는 게 바로 이 메일 헤더다.

메일 헤더 분석 가이드 (예시 헤더 기반 정리)

/* ChatGPT를 통해 만든 샘플 메일 헤더입니다. */

Received: from mail.example-sender.com (203.0.113.10)
        by mail.example-receiver.com with ESMTP;
        Tue, 04 Feb 2026 15:20:11 +0900

Authentication-Results: mail.example-receiver.com;
        spf=pass smtp.mailfrom=mailer@example.com;
        dkim=pass header.d=example.com

Received-SPF: pass (mail.example-receiver.com: domain of mailer@example.com
        designates 203.0.113.10 as permitted sender)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=default;
        h=From:To:Subject:Date;
        bh=abcdefg123456=;
        b=ZYX987654321=

From: "Example Service" <no-reply@example.com>
To: user@example-receiver.com
Reply-To: support@example.com
Subject: [Example] Sample Mail Header Guide
Date: Tue, 04 Feb 2026 15:20:11 +0900

Precedence: bulk
List-Unsubscribe: <mailto:unsubscribe@example.com>,
        <https://example.com/unsubscribe>

Message-ID: <20260204152011.12345@mail.example-sender.com>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

1. Received - 메일 전달 경로

Received: from mail.example-sender.com (203.0.113.10)
by mail.example-receiver.com with ESMTP;

역할: 메일이 어떤 서버에서 어떤 서버로 전달되었는지 기록 (여러 줄일 경우 아래에서 위 순서로 해석)
체크 포인트: 발송 서버 IP, 중간 경유 서버 존재 여부

2. SPF (Sender Policy Framework)

Received-SPF: pass
spf=pass smtp.mailfrom=mailer@example.com

역할: 발송 서버 IP가 해당 도메인에서 허용된 서버인지 검증 (DNS SPF 레코드 기반 검사)
체크 포인트: pass(정상), fail(스푸핑 의심), softfail(정책 미흡)

3. DKIM (DomainKeys Identified Mail)

dkim=pass header.d=example.com

역할: 메일 전송 중 본문/헤더 위변조 여부 검증
체크 포인트: dkim=pass header.d → 서명 도메인

4. Authentication-Results

Authentication-Results:
spf=pass
dkim=pass

역할: SPF, DKIM, DMARC 최종 인증 결과 요약
체크 포인트: pass가 아닐 경우 의심 필요

5. From / Reply-To

From: no-reply@example.com
Reply-To: support@example.com

역할
- From=사용자에게 표시되는 발신자
- Reply-To: 회신 시 실제 수신 주소
체크 포인트
- 외부 발송 서버 + 내부 도메인 From 구조 가능
- SPF/DKIM 통과 여부가 핵심

6. Precedence - 메일 성격 구분

Precedence: bulk

bulk: 대량 발송 메일
list: 메일링 리스트
normal: 일반 메일

7. List-Unsubscribe

List-Unsubscribe:
<mailto:unsubscribe@example.com>,
<https://example.com/unsubscribe>

역할: 수신 거부 경로 제공

8. Message-ID

Message-ID: <20260204152011.12345@mail.example-sender.com>

역할: 메일 고유 식별자, 로그 추적, 발송 이력 확인 시 활용

9. MIME / Content-Type

Content-Type: text/html; charset=UTF-8

메일 본문 형식, 문자셋(인코딩) 정보
한글 깨짐 현상 발생 시 해당 헤더값과 연관됨

메일 헤더 분석 체크리스트

항목	확인 내용
Received	발송 경로 정상 여부
SPF	pass 여부
DKIM	pass 여부
From	도메인 정합성
Precedence	대량 메일 여부
List-Unsubscribe	수신 거부 제공
Message-ID	로그 추적 가능

메일 담당자이다보니, 잘 까먹는 나를 위해 정리해보았다.

메이플키우기 환불 방법 총정리 (환불 링크 포함)

싹다배워 — Mon, 9 Feb 2026 13:59:05 +0900

메이플키우기 환불

최근 메이플키우기 관련하여 넥슨에서 결제 금액 환불 안내를 공지했다.

그래서 환불 링크 + 환불 절차를 간단하게 정리했다.

메이플키우기 환불 대상 안내

이번 환불은 메이플키우기에서 유료 결제를 진행한 사용자를 대상으로 진행된다.

메이플키우기 유료 상품 결제 이력 보유
넥슨 계정 로그인 필요
PC / 모바일 브라우저 모두 가능

정확한 환불 대상 여부는 환불 페이지 접속 후 자동으로 확인된다.

메이플키우기 환불 신청 링크

아래 링크를 통해 바로 환불 신청 페이지로 이동할 수 있습니다.

https://maplestoryidle.nexon.com/ko/refund

메이플 키우기

출구 없는 무한 성장의 재미, 방치형 RPG로 돌아온 메이플스토리!

maplestoryidle.nexon.com

메이플키우기 환불 방법 (순서대로 따라 하기)

1️⃣ 환불 페이지 접속
- 위 환불 링크 접속

2️⃣ 넥슨 계정 로그인
- 메이플키우기를 플레이했던 넥슨 ID로 로그인

3️⃣ 환불 대상 여부 확인
- 결제 이력이 있는 경우 자동으로 표시됨

4️⃣ 환불 신청 진행
- 안내에 따라 환불 동의 및 신청 버튼 클릭

5️⃣ 환불 완료
- 결제 수단에 따라 환불까지 일정 기간 소요될 수 있음