1. 어떤 프로젝트인가?

KB IT’s Your LIfe의 최종 프로젝트는 5가지 금융 관련 주제에서 하나를 고르는 것부터 시작된다.

4. 편리한 금융 생활을 위한 전자 지갑 서비스

나는 해당 주제로 프로젝트를 진행하게 되었다.
https://www.hankyung.com/article/2024040525977

올해 아이유 콘서트에서 한 팬이 암표 거래상으로 오해받아 공연을 못보는 해프닝이 벌어졌다.

암표 근절 노력이 아티스트와 기획사에게 부담이 되고 이런 부작용이 발생하는 것이 옳지 않다는 생각이 들었다.

조사 결과, 암표 문제의 핵심은 티켓 구매자의 본인 인증에 있다는 결론에 도달했다. 즉, 표를 산 사람이 실제 구매자임을 확실히 증명할 수 있다면 암표 거래를 막을 수 있지 않을까?

→ 전자지갑의 디지털 신분증에 주목하고 이를 티켓 거래 신분증명에 이용해보자.

그래서 나온 주제가 아래 암표 거래 방지를 위한 전자지갑 기반 티켓팅 플랫폼 이다.

2. 프로젝트때 해본 것?

암표 방지 시스템 구현과 Global Exception 구현, CI/CD, Nginx를 통한 대기열 시스템 구축등을 진행했다.

암표 방지 시스템 구현

어떻게 구현하지?

사실 거창하게 말했지만 결국 정부 인증을 받은 모바일 신분증이 있어야 가능한 프로젝트다.

이를 받기 위해서는 모바일 신분증 지원센터에서

1. 연계서비스 신청 접수
2. 이용 승인
3. 개발용 DID 등록
4. 테스트 운전면허증 발급
5. 테스트 국가보훈등록증 발급
6. 테스트 APP 설치 안내
7. SP 서버 개발 및 테스트
8. 시나리오 영상 제출 및 운영 승인
9. 운영용 DID 등록
10. 운영 개시

의 절차를 통과해야 가능하다
물론 1달짜리 개발자 프로젝트에서 사용하겠다고 승인해줄리가 만무하다..

우리는 기기 귀속된 모바일 주민등록증을 발급받았고 주민등록증에 대한 CI 값이 있다고 가정하고 아키텍쳐를 설계했다.

좋아. 이제 사용자임을 특정할 수 있는 CI 값을 확보했으니 이를 암표 방지 시스템을 구축하는데 사용하면 된다.

우리가 설계한 최종 아키텍쳐는 다음과 같다.

모바일신분증 개발지원센터

물론 1달짜리 개발자 프로젝트에서 사용하겠다고 승인해줄리가 만무하다.

티켓 예매
1.	사용자가 티켓을 예매할 때 좌석 정보와 CI(개인 정보) 값을 서버로 전송합니다.
2.	서버는 전송받은 정보를 RSA 암호화하여 예매 티켓 테이블에 함께 저장합니다.

티켓 사용
1.  사용자가 CI 값과 티켓 정보를 public key로 암호화하여 QR 코드로 만듭니다.
2.	사용자가 공연장 입장 시 관리자는 QR 코드를 스캔하여 서버로 전송합니다.
3.	서버는 QR 코드에 담긴 CI 값을 해독하여 미리 저장된 CI 값과 비교합니다.
4-1.	CI 값이 일치하면 티켓이 유효하다고 판단하여 입장이 허용됩니다.
4-2.	CI 값이 일치하지 않으면 부정 티켓으로 간주하여 입장이 거부됩니다.

이 로직을 통해 티켓 정보가 중간에 탈취되어도 RSA 암호화로 안전하며, 해당 티켓의 사용자만이 티켓을 간편하게 이용할 수 있게 했다.

FE와 BE에 암호화 로직을 나누고 기능을 설정했다. 해당 과정에서 FE, BE의 RSA 암호화 로직을 맞추고 QR 파싱을 동일하게 설정하는 트러블 슈팅을 하기도 했다.

CI/CD 파이프라인 구축

프로젝트의 효율적인 개발과 배포를 위해 CI/CD 파이프라인을 구축했다. 이를 통해 코드 변경사항을 자동으로 빌드하고 배포할 수 있었다.

• GitHub Actions를 사용하여 자동화된 빌드 및 배포 프로세스를 구현했다
• AWS EC2 인스턴스에 자동 배포 설정으로 신속한 업데이트가 가능했다

Nginx를 통한 대기열 시스템 구축

우리 서비스는 전자지갑과 티켓 서비스가 동일한 서버에서 운영된다.
예매가 몰리는 특정 시간대에 트래픽이 집중되면서 서버에 과부하가 걸리면, 전자지갑 서비스와 결제 서비스 모두 영향을 받을 수 있기에 트래픽 처리 방안을 고려해야 했다.

이를 해결하기 위해 몇가지 솔루션을 검토했다.

1. Nginx Reverse Proxy를 통해 Rate Bucket을 설정하여 트래픽을 서버 외부에서 관리하는 방법.
   이를 통해 Spring 서버 앞단에서 트래픽을 효율적으로 분산하여 티켓 서비스의 부하를 줄일 수 있다.
2. Spring 서버를 하나 구현하여 가상 대기열을 만들어 관리하는 방법.
   필터와 인터셉터를 활용해 대기열을 구성할 수 있다.
   사용자의 새로고침에도 대기열 순서가 유지되게 커스텀할 수 있다는 장점이 있다.

시간적인 요인과 향후 서버 이중화 시 로드밸런서 등으로 확장이 가능한 Nginx를 선택했다.

Nginx로 요청이 들어오면 Lua 스크립트를 통해 실시간으로 접수자 수를 counting하여 해당 요청이 동시에 얼마나 들어오는지를 체크하게 했다.

물론 해당 로직만으로는 부족한 점이 많다. Bucket Head를 구성하고 이에 Lua 스크립트를 통해 대기자 수를 Counting 하는 로직뿐이다. 향후 어떻게 고도화 하면 될지는 따로 구성할 예정.

그렇게 만들어진 최종 프로젝트

그리고 결과는 아쉽게 2등 했다. 그래도 첫 스프링 프로젝트에서 기술적으로 알아간 부분들이 많아 아쉽지만 CRUD 뿐 아니라 기술적인 도전을 할 수 있어서 만족스러운 프로젝트였다.