기록 블로그

요즘 글이 좀 뜸 했는데 ..

음 .. 베타 배포 전에 
알파 테스트 중 계속해서 기능 개선만 이뤄지고 있는 상황에 ...
생각보다 고치고 추가할게 계속 눈에 보여서 작업하다 보니 근 4일 만에 첫 글인거 같습니다 ... 
아무튼 .. 4일간 .. 이런 저런 일을 했습니다 ..

• Google·Kakao 소셜 로그인과 탈퇴 계정 복구 흐름 구현
• 문의 답변·첨부파일·메일 알림 및 사용자 문의 관리 추가
• 자동 로그인 기기 제한·이름 변경·등록 해제 기능 개선
• 거래·카테고리·반복 거래·정산 화면 반응형 UI 개선
• 정산 요약과 카테고리별 도넛 차트 추가
• 예산의 최근 설정 승계 방식 적용
• 통계 대시보드 총액 및 카테고리 표시 개선
• PWA 설치 버튼·manifest·아이콘·Service Worker 캐시 수정
• 캐릭터 기반 경고 대화창 적용
• 관리자 사용자 통계 및 API 오류 로그 관리 개선

- 조직별 통계 레이아웃 및 수정 권한 관리 추가
- 통계 컴포넌트별 조회 API와 카테고리별 수입·지출 통계 구현
- PC 드래그앤드롭 및 모바일 위·아래 버튼으로 컴포넌트 순서 편집
- 컴포넌트 활성화 여부와 절반·전체 너비 설정 지원
- 조회 기간 및 금융수단 그룹 검색 조건 추가
- 통계 레이아웃 목록과 추가 메뉴를 좌측 네비게이션으로 이동
- 모바일 하단 네비게이션 크기와 스크롤 UI 개선
- 알림 명칭 및 미확인 알림 개수 표시 적용
- 월간 예산 저장과 주간·연간 환산 표시 방식 정리
- 마이페이지 자동 로그인 등록 기기 관리 기능 추가
- 공통 입력 및 거래처 선택 컴포넌트 적용
- 빠른 거래의 신용카드·할부 입력과 영수증 등록 연동

실제 사용에서 발견한 불편함

직접 거래를 입력해보니 작은 불편이 계속 누적됐다.

입출금 구분을 등록한 후 수입·지출 선택값이 초기화되거나, 빠른 거래 등록에서 매번 같은 금융수단과 카테고리를 다시 선택해야 했다.

이를 개선하기 위해 사용자가 마지막으로 선택한 입력값을 서버의 usr_opt 테이블에 저장하도록 했다. 이 값은 단순한 디바이스 설정이 아니라 사용자의 소비 습관에 가까운 정보이므로 브라우저의 로컬 저장소보다 서버 저장 방식이 적합하다고 판단했다.

빠른 거래 등록에서는 이전 선택값으로 금융수단, 거래 유형, 카테고리까지 복원되면 카테고리에 포커스를 배치했다. 사용자는 값이 맞는지 확인한 후 Tab 또는 Enter만 눌러 금액 입력으로 이동할 수 있다.

드롭다운은 Tab뿐 아니라 위·아래 방향키와 Enter로도 조작할 수 있도록 통일했다.

계좌 단위 통계 정책

금액 가리기 기능은 단순히 화면에서 숫자를 숨기는 것만으로는 충분하지 않았다.

계좌 단위로 다음 세 가지 통계 정책을 두었다.

• 일반: 전체 통계와 그룹 통계에 포함
• 모든 통계 제외: 홈과 전체 통계에서 제외
• 그룹 전용: 전체 통계에서는 제외하고 지정된 금융 그룹 통계에서만 포함

거래 단위가 아니라 계좌 단위로 관리해 일관성을 유지했다.

예산 가능한 입출금 구분

모든 지출 카테고리가 반드시 예산 대상인 것은 아니다.

입출금 구분에 예산 책정 가능 속성을 추가하고, 예산 관리 화면에는 해당 옵션이 활성화된 지출 구분만 표시하도록 변경했다.

수입 구분은 예산 대상이 아니므로 수입 등록과 수정 시에는 예산 옵션 자체를 표시하지 않는다.

관련 DB 변경은 별도 마이그레이션으로 관리했다.

비정상적인 삭제 순서 테스트

정상적인 CRUD 테스트뿐 아니라 사용자가 잘못된 순서로 데이터를 삭제하는 상황도 점검했다.

테스트 과정에서 거래가 남은 계좌를 먼저 삭제하면 다음과 같은 문제가 발생했다.

1. 계좌 삭제 요청은 성공한다.
2. 계좌 목록에서는 계좌가 사라진다.
3. 거래 데이터는 API에 남아 있다.
4. 입출금 관리 UI에서는 남은 거래가 표시되지 않는다.

즉 데이터는 남아 있지만 사용자가 화면에서 접근할 수 없는 고아 거래 상태가 만들어졌다.

이를 방지하기 위해 실제 입출금 내역이 남은 계좌는 삭제할 수 없도록 변경했다.

계좌 생성 시 기록되는 초기잔고도 내부적으로는 거래이기 때문에 단순히 거래 행 존재 여부를 검사하면 모든 계좌 삭제가 차단된다. 따라서 초기잔고와 시스템 조정 내역은 제외하고, 사용자가 등록한 실제 입출금 카테고리의 활성 거래가 있을 때만 삭제를 차단했다.

0원·음수 거래, 빈 금액, 수입·지출 유형 불일치, 동일 계좌 이체, 중복 삭제 요청도 함께 검사했다. 해당 요청들은 모두 4xx 응답으로 안전하게 차단됐고 서버 500 오류는 발생하지 않았다.

remember-me와 서버 재시작

모바일에서 자동 로그인이 간헐적으로 풀리는 문제도 추적했다.

일반 세션인 JSESSIONID는 서버가 재시작되면 사라질 수 있다. 이 경우 브라우저의 remember-me 쿠키와 DB의 영속 토큰을 이용해 인증을 다시 복원해야 한다.

서비스에서는 Spring Security의 PersistentTokenBasedRememberMeServices와 DB 기반 토큰 저장소를 사용했다.

자동 로그인이 서버 재시작 후에도 유지되려면 다음 조건이 필요하다.

• REMEMBER_ME_KEY가 재시작과 배포 사이에 바뀌지 않아야 한다.
• remember-me 토큰 테이블이 유지돼야 한다.
• 브라우저가 remember-me 쿠키를 다시 전달해야 한다.
• 쿠키의 series와 DB 토큰이 일치해야 한다.
• 사용자 인증 버전이 변경되지 않아야 한다.

Cloudflare Tunnel을 사용해 외부에서는 HTTPS, 내부 서버에서는 HTTP로 통신하고 있지만 이것만으로 Secure 쿠키가 사라지지는 않는다. 브라우저와 Cloudflare 사이가 HTTPS이고 forwarded header가 정상 처리되면 Secure 쿠키를 사용할 수 있다.

서버 재시작마다 키가 달라지는 문제를 방지하기 위해 remember-me 키를 고정 환경변수로 분리했다.

모든 API 오류를 한곳에서 확인하기

인증 문제뿐 아니라 일반 API 오류도 사용자 제보만으로 추적하기 어려웠다.

모든 /api/** 요청 중 4xx와 5xx 응답을 수집하는 api_error_log 테이블과 전역 로깅 필터를 추가했다.

저장하는 정보는 다음과 같다.

• 요청 ID
• 발생 시각
• 사용자 ID와 로그인 ID
• HTTP 메서드와 경로
• 요청 파라미터 JSON
• 요청 본문
• 응답 상태
• 에러 코드와 메시지
• 응답 본문
• 예외 클래스
• 클라이언트 IP
• User-Agent
• 처리 시간

오류 응답에는 X-Request-ID를 함께 내려주므로 사용자에게 받은 요청 ID로 서버 로그를 바로 검색할 수 있다.

민감정보 마스킹

요청 본문 전체를 저장하면 디버깅에는 유리하지만 보안 위험이 생긴다.

다음 필드는 저장 전에 ***로 마스킹한다.

• 비밀번호
• 인증 및 갱신 토큰
• Authorization
• Cookie
• remember-me
• 이메일 인증 코드
• 클라이언트 시크릿

요청·응답 본문은 최대 10,000자로 제한했다. 이미지가 포함된 multipart 요청은 파일 원문을 저장하지 않는다.

오류 로그 때문에 원래 API 응답이 실패해서도 안 되므로, 로그 저장 실패는 기존 요청 처리에 영향을 주지 않도록 격리했다.

관리자 오류 로그 화면

관리자 화면에 API 오류 로그 메뉴도 추가했다.

기간, 상태 코드, 경로, 에러 코드, 메시지, 사용자로 검색할 수 있고 오류 행을 선택하면 요청 파라미터와 요청·응답 본문을 상세 팝업에서 확인할 수 있다.

일반 사용자가 관리자 여부를 확인하는 요청은 더 이상 정상적인 비관리자 상태를 403으로 표현하지 않는다.

인증된 일반 사용자에게는 다음과 같이 명시적인 결과를 반환한다.

```json
{
"access": false
}

설정값을 환경변수로 분리

등...

일단 .. 공개는 않했으나 퍼블릭하게 배포를 마친 후 사용하면서 불편한 점 등을 찾아 소소하게 개선했습니다.

- 이메일 인증시 중복 요청 처리 개선
- 계좌별 통계 집계 범위와 사용자 옵션 서버 저장 기능 추가

 > 이전 옵션 기억해서 조회 시 이전 옵션 적용 하게
- 예·적금 거래 제한 및 증권사 금융기관 코드 추가

- 빠른 거래 입력값 복원과 키보드 탐색 개선

- 홈 화면 구성과 모바일 로그아웃 UI 개선
- 예산 화폐단위를 등록 계좌 기준으로 제한

 > 등록 된 모든 화폐단위를 보여주기보단 유저 실사용 화폐단위만 보이게

1. VNC 원격 접속 시도

Ubuntu GUI 환경에 원격으로 접속하기 위해 처음에는 TigerVNC를 사용했습니다.

VNC 서버를 :2 디스플레이로 실행하면서 7897 포트를 사용했고, 방화벽에서는 내부망에서만 접근할 수 있도록 설정했습니다.

sudo ufw allow from 192.168.0.0/24 to any port 7897 proto tcp

초기에는 VNC 세션이 실행 직후 종료되는 문제가 발생했고, ~/.vnc/xstartup과 XFCE 세션 설정을 수정하면서 접속 자체는 성공했습니다.

다만 기존 Ubuntu GUI 화면을 공유하는 것이 아니라 새로운 가상 데스크톱 세션이 생성된다는 문제가 있었습니다.

2. Wayland 환경 확인 및 RDP 전환

기존 로컬 화면과 동일한 화면을 원격에서도 사용하고 싶어 x0vncserver를 시도했습니다.

확인 결과 현재 GUI 환경은 Xorg가 아니라:

GNOME Wayland
└─ Xwayland :0

구조였습니다.

x0vncserver는 X11 기반 화면 공유에 적합하기 때문에 현재 환경과 맞지 않았고, 결국 GNOME에서 기본적으로 제공하는 Remote Desktop(RDP) 방식으로 전환했습니다.

sudo apt install gnome-remote-desktop -y

• Remote Login: 별도 원격 로그인 세션 생성
• Desktop Sharing: 현재 로그인된 로컬 화면을 그대로 공유

Desktop Sharing 방식으로 설정했습니다.

최종적으로 RDP 포트 9879만 내부망에서 허용했습니다.

sudo ufw allow from 192.168.0.0/24 to any port 9879 proto tcp

기존 VNC는 더 이상 필요하지 않아 관련 패키지와 방화벽 규칙도 제거했습니다.

3. BUILD 환경 구성

첫 배포를 위해 서버에 Java 21 환경을 구성했습니다.

sudo apt update
sudo apt install openjdk-21-jdk -y

설치 확인:

java -version
javac -version

이후 프로젝트를 빌드하고 서버에서 실행할 수 있는 환경을 준비했습니다.

Spring Boot 프로젝트라면 일반적으로:

./gradlew clean build

로 빌드 후 생성된 JAR 파일을 서버에서 실행할 수 있습니다.

java -jar app.jar

SSH 접속을 종료해도 프로그램이 계속 실행되도록 하기 위해 nohup 또는 tmux 방식도 확인했습니다.

nohup java -jar app.jar > app.log 2>&1 &

4. Cloudflare Tunnel 및 도메인 연결

외부에서 서비스를 노출하기 위해 Cloudflare Tunnel을 사용했습니다.

여기서 중요한 점은 Tunnel보다 먼저 Cloudflare에 사용할 도메인이 연결되어 있어야 한다는 점이었습니다.

구조는 다음과 같습니다.

Domain
   ↓
Cloudflare DNS
   ↓
Cloudflare Tunnel
   ↓
cloudflared
   ↓
Local Application

즉 cloudflared만 실행한다고 외부에서 HTTPS 접속이 가능한 것이 아니라, Cloudflare에 등록된 도메인 또는 서브도메인이 Tunnel과 연결되어 있어야 합니다.

또한 Cloudflare SSL은 내부 서버 IP에 직접 적용되는 것이 아닙니다.

http://192.168.0.9:8080

로 직접 접속하면 Cloudflare를 거치지 않기 때문에 SSL이 적용되지 않습니다.

반대로:

https://api.example.com

처럼 Cloudflare에 연결된 도메인을 통해 접속해야 Edge SSL 인증서가 적용됩니다.

5. 첫 배포

서버 원격 접속 환경, Java 실행 환경, 방화벽, Cloudflare Tunnel까지 준비한 뒤 처음으로 애플리케이션을 홈서버에 배포했습니다.

전체 흐름을 정리하면:

개발 PC
   ↓
BUILD
   ↓
JAR 생성
   ↓
Ubuntu Server
   ↓
Java 21
   ↓
Application 실행
   ↓
Cloudflare Tunnel
   ↓
Domain
   ↓
HTTPS 외부 접속

이번 작업을 통해 단순히 개발한 프로그램을 실행하는 것을 넘어, 직접 구축한 Ubuntu 홈서버에 서비스를 처음 배포하는 과정까지 완료했습니다.

+ SFTP, 알드라이브 접속 에러

SFTP, 알드라이브 최신 리눅스 배포판 접속 에러

아 분명 SSH 로컬 접속도 되고,,, PUTTY 로 메인컴으로 서버컴 연결도 되는데 알드라이브에서 SFTP 연결이 안되서 삽질하다 보니

알드라이브에서 연결을 공개 키 암호화 알고리즘으로 요청하기 때문인데...

해당 연결 방식의 취약점 때문에 최신 버전 리눅스 커널은 연결 되지 않는다네요 ... 

이때 공개키 설정 과 다른 프로그램 사용이 있는데 ,,,

굳이 취약점이 있다는데 쓰기 싫어서 winSCP 프로그램을 활용했습니다. 그렇습니다 ...

자세한 연결 방법은 맨 아래 참조 사이트에 자세히 나와 있습니다. 많이 배웠습니다.

Cloudflare Tunnel 연결 시에는 도메인 연결이 선행되어야 하는 점

Cloudflare Tunnel을 사용해 외부에서 서비스에 접근하려면 먼저 Cloudflare에서 사용할 도메인을 등록하고 DNS 연결을 완료해야 합니다.

구조는 다음과 같습니다.

도메인 등록 및 DNS 설정
        ↓
Cloudflare Tunnel에 hostname 연결
        ↓
cloudflared
        ↓
내부 서버 서비스

즉, 단순히 cloudflared Tunnel만 생성한다고 바로 HTTPS 접속이 가능한 것이 아니라, 외부에서 사용할 도메인 또는 서브도메인이 Cloudflare에 연결되어 있어야 합니다.

예를 들어:

api.example.com
        ↓
Cloudflare DNS
        ↓
Cloudflare Tunnel
        ↓
localhost:8080

와 같은 구조로 연결됩니다.

또한 Cloudflare SSL 인증서는 192.168.0.X:8080과 같은 내부 IP에 직접 적용되는 것이 아니라,

https://api.example.com

처럼 Cloudflare에 연결된 도메인을 통해 접근할 때 적용됩니다.

따라서 Cloudflare Tunnel 구축 순서는 크게 다음과 같이 정리할 수 있습니다.

1. 도메인 준비
2. Cloudflare에 도메인 등록 및 DNS 연결
3. Cloudflare Tunnel 생성
4. Tunnel과 hostname 연결
5. hostname을 내부 서비스와 매핑
6. 도메인을 통해 HTTPS 접속 확인

Cloudflare Tunnel

Cloudflare Tunnel을 통해 서비스에 접속하면서 SSL 구조도 다시 확인했습니다.

Client
  ↓ HTTPS
Cloudflare
  ↓ Tunnel
cloudflared
  ↓ HTTP/HTTPS
Local Service

구조로 동작합니다.

따라서 192.168.0.X:포트로 직접 접속하면 Cloudflare SSL이 적용되지 않고, Cloudflare에 연결한 도메인을 통해 접속해야 HTTPS 인증서를 사용할 수 있습니다.

이때, HTTP 요청을 HTTPS 로 리다이렉션 해주는 기능도 Cloudflare 에서 제공해줍니다

자세한 연결 방법은 아래 사이트에 자세히 나와 있습니다.
참조 :

서론 

첫 시작은 ,,, 시간 관리를 위한 일일 일지 였으나 ,, 흠 
이거야 원 그냥 사이드 프로젝트 커밋 메세지가 되버렸다 ..........
그래서 생각 났던게 ,,, 과거 학부시절 만들었던 타임트래커 앱의 고도화...

빨리 장부 프로젝트 mvp 까지 개발해두고 ... 타임트래커 도 mvp 까진 재개발 해야겠다...

장부 개발 -> 타임트래커 재개발(리팩터링 ?) 흠 ... -> 그러고 타임트래커에서 하루 일과 출력 기능 넣어서 일일일지에 반영...
좀 더 풍성한 일지 작성을 위해서 ㅋㅋ (?)

본론

오늘은 ... 장부 거진 마무리 할려했는데 할 수 록 뭐가 계속 생각이 납니다 ...

조직 관리

조직 생성과 선택 메뉴를 추가하고, 현재는 최대 4명이 참여할 수 있는 패밀리 조직을 만들 수 있도록 구성했다. 조직 기본 정보 수정, 기본 역할 설정, 조직원 검색·초대·추방·탈퇴, 오너 양도와 조직 폐쇄까지 조직 생명주기 전반을 구현했다.

조직 초대는 사용자 이름이나 이메일로 검색한 뒤 마스킹된 이메일과 함께 결과를 보여주며, 기존 사용자 이벤트 테이블을 활용해 초대 수락과 거절을 처리한다. 이미 가입한 사용자는 검색 결과에서 가입 상태를 확인할 수 있도록 했다.

역할과 금융수단 권한

조직 역할별 권한 설정과 금융수단 접근 권한 관리를 추가했다. 역할별로 조직원을 묶어서 확인할 수 있으며, 각 금융수단에 대해 없음, 조회, 관리 권한을 지정할 수 있다.

계좌 소유자도 조직원 중에서 선택할 수 있도록 확장했다. 예산, 통계, 영수증, 반복 거래 등에서도 사용자가 접근 가능한 금융수단만 조회되도록 권한 필터를 적용했다.

외화와 계좌간 이체

서로 다른 화폐를 사용하는 계좌 사이에서도 이체할 수 있도록 환율, 입금액, 환전 수수료를 지원했다. 이체 시 출금·입금 거래와 수수료 거래를 함께 생성하며, 정산 잠금과 금융수단 권한도 양쪽 계좌에 모두 적용한다.

화폐별 소수 자릿수 메타데이터도 추가했다. 일반 화폐는 기본 2자리로 처리하고, 원화·엔화 같은 0자리 화폐와 디나르 계열의 3자리 화폐, 일부 4자리 화폐만 예외 데이터로 관리한다. 금액 컬럼은 최대 소수점 4자리까지 보존하며, 클라이언트 입력과 서버 검증에도 동일한 규칙을 적용했다.

반복 거래

전기세나 수도세처럼 금액이 사전에 확정되지 않는 반복 입출금은 예정 금액을 비워두고, 이벤트 처리 당일 실제 금액을 입력할 수 있도록 개선했다.

예적금 자동이체나 생활비 계좌 이동을 위한 반복 계좌간 이체도 추가했다. 고정 금액과 실행 시 직접 입력 방식을 지원하며, 외화 계좌 간 반복 이체에는 환율과 환전 수수료를 설정할 수 있다. 예정일이 되면 공통 이벤트가 생성되고, 사용자가 확인하면 기존 계좌간 이체 로직을 통해 실제 거래가 생성된다.

거래 확정과 계좌 정산

계좌와 기준 일시를 선택하고 실제 잔액을 입력하면 장부 잔액과의 차액을 계산하는 정산 기능을 추가했다. 차액이 존재하면 시스템 카테고리의 정산 보정 거래를 생성하고, 기준 시점 이전의 미확정 거래를 일괄 확정한다.

정산 이후에는 확정된 거래와 연결 영수증을 수정하거나 삭제할 수 없다. 마지막 정산 시점 이전의 거래 추가도 차단했으며, 정산 취소는 가장 최근 정산부터 역순으로만 가능하도록 제한했다. 미리보기에서는 정산 차액과 괴리율을 함께 보여주고, 괴리율이 ±5% 이내인지에 따라 상태 색상을 구분했다.

내일은 ...

정도 오늘 했고 ... 
내일은 ... 전체적으로 점검 하고 mvp 알파 테스트를 이래저래 배포 방법을 구상하고 실천해봐야겠습니다...
클라우드 플레어 터널링 서비스로 익명 배포를 생각하고 있긴한데 .. 내일이나 배포 할 때 한 번 자세히 기록 해보도록 하겠습니다...

오늘은 여기까지 ..

- 조직 생성, 선택, 수정, 폐쇄 및 탈퇴 기능 추가
- 조직원 초대, 취소, 추방 및 오너 양도 기능 구현
- 조직 역할, 기본 역할 및 역할명 중복 검증 추가
- 조직원 가입, 탈퇴, 추방, 역할 및 오너 변경 이력 기록
- 계좌, 카드, 부채별 접근 권한 추가
- 예산, 통계, 영수증, 반복 거래에 금융수단 권한 필터 적용
- 사용자 이벤트 테이블과 조직 초대 수락 흐름 구현
- 조직 대시보드와 내비게이션 UI 개선

오늘은 한게 많아서 .... 간략하게 ... 정리 

내일은.. 
조직 내 규칙 관리 ,, 정도 하고 mvp 1차 배포를 위한 랜딩 페이지 ...
흠 ,,, 피곤하네요...