Joyuno's Dev Blog

2026-04-23 (목) 개발일지

2026년 04월 23일 joyuno
dev-blog
#dev-blog #til

오늘의 개발 회고: GCP 복구, 카카오 OAuth 삽질, 그리고 SIEM 연동의 시작

오늘은 정말 다양한 프로젝트를 오가며 하루를 보냈네요. 아침부터 저녁까지 각기 다른 도메인의 문제를 해결하고, 새로운 기능을 구현하는 하루였습니다.

GCP 프로젝트 복구와 보안 강화

아침에 가장 먼저 맞닥뜨린 문제는 드롭쉽핑 자동화 프로젝트의 GCP 정지였습니다. “암호화폐 채굴에 도용되었다”는 경고 메시지를 받고 깜짝 놀랐어요. 처음에는 홍보 때문인가 싶었는데, 알고 보니 서버 보안 문제였습니다.

문제: GCP에서 프로젝트가 정지되고, Compute Engine 접근이 차단됨 시도:

  1. 이의신청 제출 (WACQUOAZDOJ3GDQDEI3VLYQGVM)
  2. 프로젝트 상태 확인 (gcloud projects describe)
  3. Compute Engine API 재활성화 시도

해결: 이의신청이 접수된 후 2일 이내에 복구될 예정. 기존 VM은 삭제되었을 가능성이 높아 새로 생성해야 함 배운 점: SSH 포트(22)를 전 세계에 열어두지 말고, Docker를 root로 실행하지 말아야 합니다. 보안 강화 스크립트를 미리 준비해두는 게 중요하네요.

카카오 OAuth 토큰 갱신의 함정

옵시디언 정리 프로젝트에서 카카오톡 알림 기능의 리프레시 토큰이 60일 만료되는 문제를 해결하려 했습니다. 생각보다 훨씬 복잡했어요.

문제: 카카오 OAuth 리프레시 토큰 만료, 재발급 필요 시도:

  1. kakao_token_refresh.py 스크립트 작성
  2. 로그인 URL 생성 시도 (https://kauth.kakao.com/oauth/authorize?client_id=...)
  3. redirect_uri를 http://example.com/oauth로 설정 → “This domain is for use in documentation examples” 에러
  4. 로컬 서버(localhost:4444)로 변경 → 404 에러

해결: 알고 보니 클라이언트 시크릿 키는 토큰 교환 단계에서만 필요하고, 로그인 단계에서는 불필요했습니다. 가장 큰 문제는 로컬 서버가 실행 중이지 않았다는 것이었어요. 간단히 python -m http.server 4444로 서버를 띄우니 해결됐습니다.

배운 점: OAuth flow를 단계별로 정리해보면:

  • 1단계(로그인): client_id + redirect_uri만 필요
  • 2단계(토큰 교환): client_id + client_secret + code 필요
  • 리프레시 토큰 갱신: client_id + client_secret + refresh_token 필요

SIEM 다중 연동 프로젝트 시작

소명처리시스템에서 가장 기술적으로 흥미로웠던 작업입니다. 현재 Logpresso만 연동되어 있는 tr-box에 다양한 SIEM을 추가로 연동하는 작업을 시작했어요.

문제: 한국 금융기관들은 Splunk, ArcSight, QRadar, FortiSIEM 등 다양한 보안장비를 사용하는데, 현재는 Logpresso만 지원 시도:

  1. Pulse 방법론 적용 (AI-Native Project Loop)
  2. feature/multiple-connection 브랜치 생성
  3. 7개 국내 SIEM 제품(시큐레이어, 시큐어시스템즈, SGA솔루션즈 등) 연동 가능성 조사
  4. BaseSIEMConnector 아키텍처 분석

해결: Pulse 0 단계 완료. 산출물 6개 파일 생성 및 연동 난이도 “보통”까지의 구현 범위 확정 (QRadar, Microsoft Sentinel, FortiSIEM, 커넥터 팩토리, Syslog/CEF 수신 서버) 배운 점: 현재 아키텍처는 Tenant 1개 → SIEM 1개 구조인데, 이를 Tenant 1개 → SIEM N개로 변경해야 합니다. Tenant 모델에 이미 siem_type/siem_config 필드가 있어서 마이그레이션이 필요할 것 같아요.

Flutter 앱 리브랜딩과 백엔드 문제

사주 프로젝트에서는 “연분”에서 “오연(五緣)”으로 앱 이름을 변경하는 작업을 했습니다. 생각보다 많은 곳에서 참조하고 있더라고요.

문제: 앱 이름이 여전히 “연분”으로 표시되는 곳이 많음 해결: splash_screen.dart, login_screen.dart 등에서 한자 장식(緣分)까지 五緣으로 변경 특이사항: Flutter에서 pubspec.yaml 파일을 찾지 못하는 에러는 단순히 frontend/ 폴더로 이동하지 않아서였습니다. cd frontend 한 줄이면 해결되는 문제였네요.

백엔드에서는 회원가입 시 “password cannot be longer than 72 bytes” 에러가 발생했는데, 사용자에게 비밀번호 길이 제한을 UI에서 알려주는 게 필요하다는 걸 깨달았습니다.

자동매매 시스템 디버깅

bit-scalp 프로젝트에서 재미있는 버그를 발견했습니다. 테스트넷에서 BNXUSDT 종목을 조회할 때 400 에러가 발생하는 문제였죠.

문제: [SCAN] BNXUSDT: Client error '400 Bad Request' 원인: 테스트넷에는 실제 거래소의 모든 종목이 존재하지 않음 해결: 에러 발생 시 블랙리스트에 추가하고 스킵하도록 처리

더 흥미로운 것은 쿨다운 버그였습니다:

# 문제의 코드
idx = len(df) - 1  # 항상 199
if idx - self._cooldown_idx < 24:  # 마지막 시그널 후 설정
    return None

진입 시 _cooldown_idx = 199로 설정된 후, 모든 후속 스캔에서 199 - 199 = 0 < 24가 되어 영구적으로 차단되는 버그였습니다. BCHUSDT 포지션이 18시간 동안 추가 시그널을 못 잡은 이유였죠.

오늘의 한줄

“보안은 사소한 설정에서, 버그는 논리적 함정에서, OAuth는 실행 중인 서버에서 문제가 발생한다”