티캣

1. 오류 분석

문제 현상

실제 사용자를 유입해야 하는 3주간의 운영에서, NFT 기능을 위해 사용자가 MetaMask 같은 외부 지갑을 미리 준비하고 연결해야 한다면 가입 장벽이 높아질 수 있었습니다.

원인

외부 지갑을 전제로 한 방식은 사용자가 지갑 설치, 니모닉 관리, 트랜잭션 서명에 익숙해야 합니다. 일반적인 회원가입 경험을 기대하는 사용자에게 이 절차는 추가 부담이었습니다.

추가 확인 사항

• •회원가입과 NFT 이용 과정에서 사용자에게 외부 지갑 연결을 요구하지 않는 흐름을 확인했습니다.
• •회원마다 고유한 파생 인덱스를 사용해 같은 인덱스에서 같은 지갑 주소가 생성되는지 확인했습니다.
• •회원 DB에는 지갑 주소와 파생 인덱스만 기록하고, 마스터 니모닉과 개인키는 저장하지 않는 구조를 확인했습니다.

측정 기준

105명은 3주 운영 기간의 실사용자 수입니다. 커스터디 도입 전후의 가입 전환율은 별도로 비교 측정하지 않았습니다.

2. 개선 과정

1. 1.3주 운영과 실사용자 유입이라는 목표에 맞춰 외부 지갑 준비 과정을 가입 흐름에서 제거
2. 2.블록체인 서비스가 보관하는 하나의 마스터 니모닉과 회원별 고유 인덱스로 HD 지갑 주소 파생
3. 3.회원가입이 완료되면 지갑 발급 요청을 남기고 백그라운드에서 지갑 생성
4. 4.발급을 재시도해도 같은 인덱스를 사용하도록 해 지갑 주소가 바뀌거나 중복 발급되지 않게 처리
5. 5.사용자가 개인키를 직접 다루지 않아도 서비스에서 필요한 블록체인 작업을 진행하도록 구성

커스터디 방식의 HD 지갑을 도입했습니다. 사용자는 일반 계정으로 가입하고, 서비스는 마스터 니모닉과 회원별 고유 파생 인덱스로 각자의 지갑을 생성합니다. 마스터 니모닉은 블록체인 서비스에서 관리하며 회원 DB에는 지갑 주소와 파생 인덱스만 저장합니다.

3. Before & After 비교

1. 오류 분석

문제 현상

2,400 VU 부하에서 DB 커넥션과 요청 처리 스레드가 포화되면서 좌석 조회 p95가 약 7.08초까지 늘고, 요청의 약 4.0%가 타임아웃으로 실패했습니다.

원인

같은 좌석맵을 요청마다 DB에서 다시 조립했고, 서버가 처리할 수 있는 양보다 많은 조회 요청이 몰렸습니다.

추가 확인 사항

• •Grafana에서 DB 커넥션 대기와 요청 처리 스레드 포화를 확인했습니다.
• •캐시 적용 후에도 남은 지연을 추적해 nginx의 연결 생성·임시 포트 고갈을 확인했습니다.

측정 기준

p95는 서버 기준입니다. 1,200 VU 캐시 적용 전후와 3,600 VU 재측정은 서로 다른 부하 조건이며, 대기실 정원 5,000명은 설정값입니다.

2. 개선 과정

1. 1.2,400 VU 실패 재현·병목 확인
2. 2.좌석맵 1초 캐시 적용
3. 3.nginx 연결 재사용
4. 4.재측정 후 가상 대기실로 입장 제어

좌석맵을 1초간 캐싱해 반복 DB 조회와 커넥션 점유를 줄이고, nginx keepalive로 연결을 재사용했습니다. 가상 대기실을 추가해 정원을 넘는 사용자는 대기시키고 순차 입장하도록 했습니다.

3. Before & After 비교

1. 오류 분석

문제 현상

Pinata 무료 플랜의 파일 수 한도 500개를 넘어 핀이 507개가 되자 운영 전용 게이트웨이가 403을 반환했습니다. 경매 상세, 마켓 목록, 포카덱스의 이미지가 실제 그림 대신 대체 이미지로 표시됐습니다.

원인

브라우저가 Pinata 게이트웨이에서 화면용 이미지를 직접 가져오는 구조였습니다. 또한 공연마다 이름이 다른 메타데이터 JSON을 새로 핀해, 이미지를 재사용해도 파일 수가 계속 증가했습니다.

추가 확인 사항

• •배포에 적용된 전용 게이트웨이는 403을 반환하지만 공용 게이트웨이는 같은 CID에 200을 반환하는 것을 확인했습니다.
• •Pinata API에서 핀 507개를 확인했고, 운영·개발 DB를 함께 대조해 안전하게 정리할 수 있는 미참조 핀 52개를 찾았습니다.
• •52개를 정리해 핀 수를 455개로 낮추자 전용 게이트웨이가 다시 200을 반환했습니다.

측정 기준

이미지 응답 200은 운영에서 확인한 표본 3건의 결과입니다. 22건 생성 시 핀 증가량 7개는 기존 템플릿의 메타데이터 CID 재사용이 포함된 실측값입니다. 기존 NFT의 온체인 URI와 지갑용 IPFS 경로는 변경하지 않았습니다.

2. 개선 과정

1. 1.IPFS 게이트웨이 한도·메타데이터 증가 원인 확인
2. 2.미참조 핀 52개 정리·게이트웨이 복구
3. 3.NFT 메타데이터와 화면용 이미지 경로 분리·이미지 주소 407건 이관
4. 4.공연별 메타데이터 정보 정리·템플릿 CID 재사용
5. 5.이미지 접근·온체인 등록 결과 검증

NFT 메타데이터와 화면용 이미지의 저장·조회 경로를 용도별로 분리했습니다. 메타데이터는 IPFS URI로 유지하고, 화면용 이미지는 객체 저장소의 공개 고정 URL에서 제공하도록 구성했습니다(구현: MinIO). 새 메타데이터에서는 공연별로 달라지는 정보를 제거해 같은 템플릿의 JSON·CID를 재사용했습니다. 기존 NFT의 온체인 URI와 지갑이 사용하는 IPFS 이미지 참조는 유지했습니다.

3. Before & After 비교

1. 오류 분석

문제 현상

8개 규칙 중 반복 거래쌍 규칙은 두 계정 사이만 확인해 A→B→C→A 형태의 3자 순환거래를 놓쳤습니다. 꾸민 카드에 적용한 가격 규칙 예외로 꾸밈 후 고가 거래도 탐지하지 못했습니다.

원인

개별 조건과 임계값으로 판단하는 규칙만으로는 카드 소유 이력, 거래 빈도, 가격과 계정 행동을 함께 평가하기 어려웠습니다.

추가 확인 사항

• •합성 검증 배치에서 기존 규칙은 3자 순환거래 48건 중 1건, 꾸밈 후 고가 거래 20건 중 0건을 탐지했습니다.
• •서로 다른 3개 시뮬레이션 배치 중 마지막 547건(이상거래 247건·정상 300건)을 통째로 분리해 기존 규칙과 모델을 같은 거래에서 비교했습니다.
• •모델이 오탐한 정상 거래 12건은 모두 고정가 판매였습니다. 거래 유형 피처를 제외한 가상 재학습에서는 오탐 6건·탐지 223건으로 바뀌어 해당 피처의 영향을 확인했습니다.
• •새 모델로 채점된 거래 548건에서 Java 점수와 Python 재계산값이 반올림 오차 범위에서 일치함을 확인했습니다.

측정 기준

탐지 성능은 시뮬레이터가 부여한 라벨 기준이며 실거래 성능이 아닙니다. 검증 배치의 이상거래 비율은 247/547건으로 높고 일부 피처가 시나리오를 거의 단독으로 구분해 성능이 낙관적일 수 있습니다. 피처 제외 실험은 오탐 원인 확인용 가상 비교로 실제 모델 변경이 아닙니다. 최종 저장 모델은 검증 뒤 전체 1,640건으로 다시 학습했으며, 548건 점수 대조는 채점 구현 검증이지 추가 탐지 성능 평가가 아닙니다.

2. 개선 과정

1. 1.규칙과 동일한 거래 맥락에서 44개 후보 피처를 생성하고 규칙 판정값은 모델 입력에서 제외
2. 2.앞선 두 배치 1,093건에서만 결측값 처리·극단값 범위·표준화 기준을 학습하고 마지막 배치 547건으로 검증
3. 3.상수 피처를 제외한 32개 피처로 로지스틱 회귀 모델을 학습하고 동일 검증 거래에서 규칙과 탐지·오탐 비교
4. 4.오탐 거래의 피처 기여도를 분석한 뒤 전체 1,640건으로 최종 모델을 다시 학습하고 Java 서버에 섀도 점수 기록 연결

학습된 계수와 전처리 기준을 JSON으로 저장하고, Java 서버가 거래 피처의 가중합에 시그모이드 함수를 적용해 0~1의 위험 점수를 계산하도록 했습니다. 모델 점수는 거래에 기록하되 관리자 심사 여부나 정산 보류 결정에는 사용하지 않았습니다.

3. Before & After 비교