본문으로 건너뛰기

BUMDAY · ENGINEERING NOTES

개발의 과정과
문제 해결의 기록.

직접 만들고, 부딪히고, 배운 것들을 기록합니다.

전체 글 306

운영 배포 후에만 외부 인증 콜백에서 세션 정보를 잃어버린 사례

외부 인증 서비스(제3자 도메인)와 연동하는 콜백 기능이 개발환경에서는 정상 동작했지만, 운영 배포 후에는 콜백에서 세션 정보를 찾지 못해 매번 실패했다. 최종 원인은 세션 쿠키에 걸려 있던 SameSite=Strict 옵션이었고, 이를 Lax로 완화해 해결했다.증상로그인/본인인증처럼 외부 도메인으로 이동했다가 인증 완료 후 자사 서버로 되돌아오는 콜백 기능에서, 콜백 시점에 "세션 정보가 없습니다" 류의 예외가 발생했다개발 환경(단일 WAS)에서는 같은 시나리오가 정상 동작했다운영 환경(다중 WAS 이중화 구성) 배포 후에는 매번 실패로 재현됐다처음에는 WAS 이중화(로드밸런서가 인증 시작 시점과 콜백 시점에 서로 다른 WAS 노드로 라우팅해서 세션 공유가 안 되는 것)를 의심했다어떻게 좁혔나1) 인증..

Git Squash Merge를 사용하는 이유와 브랜치별 적용 방법

Squash merge는 작업 브랜치의 여러 커밋을 하나의 의미 있는 변경 단위로 정리할 때 사용한다. 짧게 사용하는 기능 브랜치에는 유용하지만, main과 prod처럼 계속 유지되는 브랜치 사이에서 사용하면 커밋 계보가 끊어져 다음 MR에 과거 변경이 다시 표시될 수 있다.배경개발 중에는 기능 하나를 완성하기까지 여러 임시 커밋이 생긴다.feat/loginA: 로그인 화면 추가B: 오타 수정C: 리뷰 반영D: 테스트 코드 수정이 브랜치를 그대로 병합하면 A, B, C, D가 모두 대상 브랜치에 남는다. Squash merge를 사용하면 네 커밋의 최종 변경 내용을 하나의 새 커밋 S로 합쳐 대상 브랜치에 반영한다.feature: A -- B -- C -- D | ..

Git 2026.10.26

Git MR에서 커밋은 남는데 변경사항이 0건인 사례

Git 병합 요청에서 커밋 목록은 남아 있는데 파일 변경이 0건으로 보였다. 원인은 소스 트리와 커밋 그래프를 별개로 복구한 뒤 squash 병합이 원래 커밋 부모 관계를 보존하지 않았기 때문이다. 최종적으로 최신 main을 실제 부모로 갖는 no-squash 병합 커밋을 prod에 병합해 두 기준을 다시 일치시켰다.증상기준 커밋 이후 main에는 통계 기능 관련 소수의 파일 변경만 남아 있었다. 파일 비교 결과 main과 prod의 내용도 같았다.그런데 main에서 prod로 만드는 MR에는 과거 커밋이 18개, 이후에는 20개까지 표시됐다. 반면 Changes 탭은 0건이었다.prod는 보호 브랜치라 직접 푸시할 수 없었다. 기능 소스를 다시 적용하거나 강제 푸시하지 않고, MR로 이력만 정리해야 했..

Git 2026.10.26

가상 메모리 설정을 점검해 Windows 응답 지연을 개선한 사례

가상 메모리는 Windows가 프로그램의 메모리 주소와 실제 RAM을 연결해 관리하는 체계다. 페이지 파일은 그 과정에서 자주 쓰지 않는 RAM 데이터 일부를 디스크에 보관하는 보조 파일이다. Windows의 ‘가상 메모리 설정’에서는 이 파일의 저장장치와 크기를 조절한다.증상RAM 8GB PC에서 여러 작업의 응답 지연이 반복돼 업무 진행이 어려웠다. 저장장치는 C: SSD와 F: HDD를 함께 사용하고 있었다.원인 분석 과정CPU 평균 사용률은 9.1% 수준으로, 측정 구간에서 CPU 전체가 계속 포화된 상태는 아니었다.가용 RAM은 약 1GiB로 여유가 작았고, 페이지 파일은 F: HDD에서 사용 중이었다.원인페이지 파일에 보관한 데이터가 다시 필요하면 디스크에서 RAM으로 읽어와야 한다. 이때 느..

개발자의 AI 활용 7단계와 단계별 레벨업 가이드

AI 활용의 레벨업은 더 좋은 모델을 찾는 것보다, 사람이 하던 개발 작업을 점점 더 넓은 단위로 AI에게 맡기고 그 결과를 검증 가능한 구조로 만드는 과정에 가깝다.아래에서는 이미지의 7단계를 기준으로, 각 단계에서 무엇을 익혀야 다음 단계로 넘어갈 수 있는지만 정리한다. 1. Level 1 — Chat AssistantAI를 질문·검색·초안 작성 도구로 사용하는 단계다. 코드와 로그를 사람이 가져오고, 답변을 다시 사람이 프로젝트에 반영한다.레벨업 방법오류 해석뿐 아니라 코드·SQL 초안, 테스트 케이스, 리팩터링에 반복적으로 활용한다.질문할 때 목적, 제약조건, 기대 결과를 함께 전달하는 습관을 만든다.복사·붙여넣기 중심 사용에서 벗어나 AI가 실제 코드베이스를 보게 만든다.Level 2 기준: A..

ETC/AI 2026.09.14

[포트폴리오] Node.js·Socket.IO 기반 실시간 멀티플레이 RPG 백엔드 서버 구축

Unity 기반 멀티플레이 RPG 게임을 1인 개발·운영하며 Node.js와 Socket.IO를 이용한 실시간 통신 서버를 설계·구축했다. 처음에는 채팅과 플레이어 위치 공유로 시작했지만, 게임이 확장되면서 레이드와 파티 퀘스트의 전투 상태, 여러 오브젝트의 위치, 네트워크 단절 후 상태 복구까지 처리해야 했다. 이 글에서는 Socket.IO를 단순 메시지 전달 수단이 아닌, 여러 사용자가 동일한 게임 상태를 공유하는 핵심 통신 계층으로 활용한 과정을 정리한다. 1. 시스템 구성프로젝트는 REST API와 Socket.IO 서버의 역할을 구분했다.REST API사용자·아이템·퀘스트·랭킹 조회 및 저장PostgreSQL에 보존해야 하는 영속 데이터 처리Socket.IO플레이어 위치·HP·버프 상태 동기화스..

Bumday/About Me 2026.08.23

Base64 PNG 내부 문자열이 WAF의 SQL Injection으로 오탐된 사례

외부망에서 Base64 PNG를 포함한 POST 요청이 HTTP 응답 없이 종료됐다. WAF가 표준 Base64를 디코딩한 뒤 PNG 압축 데이터의 o'# 바이트를 SQL Injection으로 오탐한 것이 원인이었다. 전송 값을 Base64URL 형식으로 변환한 뒤 정상 동작을 확인했다.증상이미지가 포함된 보고서 조회 요청에서 브라우저 ERR_EMPTY_RESPONSE가 발생했다.HTTP 상태 코드와 응답 본문이 없었고, 연결이 수십 ms 안에 종료됐다.이미지 파라미터를 제외하면 같은 API가 HTTP 200을 반환했다.내부 애플리케이션 로그에는 요청 흔적이 없어 앞단 보안장비를 의심했다. 어떻게 좁혔나1) 파라미터를 하나씩 제거했다 테스트 결과 판단 원본 요청Empty Response재현Bas..

[포트폴리오] 반도체 소재 제조 현장의 공정·품질 데이터 시스템 구축기

반도체 소재 제조사에서 근무하며, 현장 장비 데이터를 수집·분석해 품질과 운영을 관리하는 시스템을 직접 설계·구축했다.이 글에서는 그중 대표적인 두 가지를 정리한다. 하나는 공정/품질을 통계적으로 관리하는 SPC(Statistical Process Control), 다른 하나는 분석·평가실의 장비 운영을 다루는 FIMS(Fab Information Management System)다. 두 시스템 모두 "현장에서 실제로 쓰이는 데이터를, 사람 손을 거치지 않고, 신뢰할 수 있게 다룬다"는 같은 문제의식에서 출발했다.1. SPC(통계적 공정관리) 시스템 구축배경제조 현장에는 공정별로 품질 편차가 존재했고, 설비에 이상이 생겼을 때 이를 실시간으로 감지해 대응하기가 어려웠다. 고객 불량이 발생하면 근거 자료가..

Bumday/About Me 2026.08.04

PC작업을 하지 않고 앱을 개발하고 운영하는 방법

운영 중인 앱 서비스를, PC 앞에 앉지 않고도 기획부터 배포 검증까지 유지보수한 방법을 정리한다. 핵심은 세 가지다. 원격으로 명령하는 AI 코딩 에이전트, 사람이 앉아서 하던 일까지 걷어낸 CI/CD, 그리고 이동 중에도 쓰는 음성 대화다.배경현재 육아와 병행하는 상황에서는 PC 앞에 앉아서 작업을 하기 어렵다. 하루 왕복 2시간의 운전 통근의 상황도 있다. 그럼에도 개인적으로 운영하는 앱 서비스(클라이언트 앱, API 서버, 내부 운영 콘솔로 구성)는 기능 추가와 버그 대응이 계속 필요하다. 예전에는 이 과정을 전부 PC 앞에서 직접 해야 했다. 지금은 대부분을 자리에 앉지 않고 처리한다. 1. 기획부터 개발까지, 채팅으로 원격 명령요즘 개발은 상당 부분 AI 에이전트가 한다. 최근에는 Claud..

Record/IT Diary 2026.07.23

운영 서버 CPU가 100%로 멈춘 뒤 악성 cron 제거 및 DB 계정 분리한 사례

운영 서버 CPU가 100%까지 치솟아 응답이 멈췄다. 처음에는 새로 추가한 시스템 메트릭 샘플러를 의심했으나, 최종 원인은 postgres OS 유저 crontab에 심어진 악성 wget | sh 스크립트였다. cron 제거 후 API DB 접속을 postgres 슈퍼유저에서 [앱DB계정] 전용 계정으로 분리해 재발 가능성을 줄였다. 증상평소 CPU 약 14% 유지특정 새벽 02:30 전후 CPU 100% → 서버 응답 불가[API프로세스] 재시작·재부팅 후에도 부하 지속 (cron 미삭제 시)동시에 시스템 메트릭 테이블 10초 INSERT 로그가 syslog에 대량 기록됨 → 처음엔 메트릭 기능이 원인으로 의심됨 어떻게 좁혔나1) 메트릭 샘플러 의심 (오탐)SystemMetricsManager가 10..

반응형