목차

1. 개발 동기

2. 개발 1) 순서도 2) 개발환경 3) Frontend 4) Backend 5) Traffic Spike 대응 6) 보안

3. 문제대응
4. 결론 (소감)

---

1. 개발 동기

학교 학생회에서 맡은 역할인 학예미디부 차장으로써 무엇을 할 수 있을까 생각하던 중 평소 관심있던 분야인 코딩에 접하여 생각해본 결과 교내 축제에 도입할 수 있다는것을 깨달았다. 따라서 티켓 예매 시스템 도입을 제안함에 따라 웹 애플리케이션 개발을 함으로써 공간문제로 인해 전교생들이 축제를 한꺼번에 관람할 수 없는 문제를 해결하게 되었다.

2. 개발

1) 순서도

2) 개발환경

Frontend는 HTML, CSS, JavaScript, Tailwind CSS 웹프레임워크를 사용하였다. Backend는 PHP, MariaDB, 트래픽 분석을 위한 umami를 사용하였다. 그리고 티켓 예매 관련 문의를 받기 위해 채널톡을 사용하였다.

3) Frontend

먼저, Frontend 개발은 축제 홍보에 있어서 매우 중요한 부분을 차지하기 때문에, 이 부분에는 신중하게 접근하였다. Frontend는 사용자와 직접적으로 상호작용하는 부분이므로 사용자 친화적인 디자인이 중요하다는 것을 알게되었다. 또한, 축제 시작이 얼마 남지 않았기 떄문에 빠른 개발 속도 또한 요구되었다. 이러한 문제를 해결하기 위해, 나는 Github Universe 웹사이트의 디자인을 참고하였다. 이를 통해, 티켓 예매 웹사이트 사용자 친화적인 디자인을 가질 수 있게 되었다. 더불어, 이러한 디자인은 학생들이 웹사이트를 쉽게 탐색하고, 원하는 정보를 빠르게 찾을 수 있도록 도와주게되었다. 즉, 요약하자면 Github Universe 웹사이트의 디자인을 참고하여, 티켓 예매 웹사이트는 사용자 친화적이면서도 빠른 개발이 할 수 있었다. 이를 통해 사용자는 웹사이트를 쉽게 이용하면서도 원하는 정보를 빠르게 찾을 수 있게 되었다.

4) Backend

웹사이트 개발을 위해, 나는 사용자의 데이터 안정성과 특정 웹사이트의 특성인 Traffic Spike 현상을 고려하였다. 이 두 가지 요인을 고려하면서, 기술 스택 선택에 있어서는 MariaDB와 PHP를 선택하였다. MariaDB는 높은 단일 쿼리 실행 성능을 보여주기 때문에 선택하였다. 이는 사용자의 데이터를 빠르고 안정적으로 처리할 수 있게 해주며, 특히 트래픽이 급증하는 티켓팅 웹사이트에서는 이러한 성능이 매우 중요하다. 또한, PHP는 서버 리소스를 많이 요구하지 않는 프로그래밍 언어로써, 이를 통해 서버의 부하를 줄이고 효율적이고 안정적인 웹사이트 운영을 할 수 있어 선택하였다. 마지막으로, 나는 축제 시작 전까지 웹사이트의 개발을 완료해야 해야했다. 이러한 시간적 제약을 고려하여, 코드가 단순하고 개발이 빠르게 할 수 있는 PHP를 선택하다. 이를 통해, 나는 짧은 시간 안에 안정적이고 효율적인 웹사이트를 개발할 수 있게 되었다.

5) Traffic Spike 대응

특정 시간대에 방문자가 갑자기 몰리는 티켓 예매 웹사이트의 특성을 고려하여, WAS 서버와 프록시 서버를 분리하여 서버 구조를 설계하였다. (아래 Server Topology 참고)

또한, Traffic Spike에 대응하는 방법을 인터넷에서 찾아보았다. 검색 결과를 통해 알게 된 사실 중 하나는 웹 페이지의 HTML, CSS, JS 파일을 압축하면 원본 파일 크기보다 작아져서 서버가 클라이언트에게 전송하는 데이터의 양이 줄어든다는 것이다. 이로 인해 서버의 부하가 줄어들게 된다. 더불어 파일의 크기가 줄면서 네트워크 대역폭도 감소하게 되어, 네트워크 자원을 효율적으로 사용할 수 있게 됩니다. 이 방법은 홈 서버로 운영 중인 네트워크에 매우 적합한 해결책 이었다. Proxy Server의 Nginx Proxy Manager에 있는 Cache Assets 기능을 enable하면 정적 콘텐츠인 CSS, Javascript, 이미지 파일은 Proxy Server에 캐싱을 하게 된다. 이로 인해 정적콘텐츠에대한 요청을 WAS Server에 요청을 보내지 않아도 되므로 WAS Server 부하를 줄이게되어 성능을 향상시킬 수 있게 되었다. 위 방법을 적용해봤더니, 동접자 450명을 버텨냈다.

동접자 450명일때 서버 상태

6) 보안

순서도를 보면 QR코드를 생성하기 전, QR코드에 담길 정보를 AES-128-CTR 암호화 알고리즘을 사용해 암호화하는 것을 알 수가 있는데 암호화하는 이유는 QR코드의 위변조를 막기 위해 암호화하였다 만약 암호화가 되질 않은 상태에서 QR코드를 생성하게되면 누구나 QR코드의 정보를 볼 수 있게 되어 그러므로 QR코드의 위변조가 쉬워진다. 하지만 AES-128-CTR 암호화 알고리즘을 사용해 암호화 해당 암호화 키를 알고 있는 사용자만이 QR코드의 담긴 정보를 해독할 수 있게 되어 정보의 안전성과 기밀성이 확보되게 되었다.

3. 문제 대응

교내 축제 티켓 예매 웹사이트에서는 사용자가 좌석을 선택한 후, 해당 정보를 GET 파라미터로 서버에 전달하는 방식을 사용하였다. 그러나, 이 과정에서 입력 데이터의 유효성 검증 절차가 누락되어, 일부 학생들이 이를 악용해 좌석 정보를 불공정하게 조작하는 문제가 발생하였다. 문제를 인지하자마자, 저는 즉시 학생들에게 이 사실을 알리는 사과문을 작성하였고, 티켓 예매를 일시 중지하였다. 또한, 데이터 유효성 검증 절차를 추가하는 작업에 착수하였다. 이어서 학생회 임원들과 긴급 회의를 개최하여 문제 해결 방안을 논의하였다. 회의에서는 티켓 예매 절차를 언제부터 다시 시작할지, 그리고 어떻게 진행할지에 대해 깊게 고민하였다. 이 과정에서 저는 보완된 데이터 유효성 검증 절차를 갖춘 예매 시스템을 책임지고 개발하겠다는 결심을 하였다. 이 경험을 통해 데이터 유효성 검증의 중요성을 깊이 이해하게 되었고, 이를 바탕으로 보다 공정하고 안전한 티켓 예매 시스템을 만들기 위해 노력하였다. 그 결과, 안전한 예매 시스템을 통해 교내 축제 티켓 예매는 성공적으로 재개되었고, 모든 과정이 원활하게 이루어졌다.

4. 결론

작성한 개발동기와 같이 코딩을 이용한 부문으로 교내 축제 티켓 예매 시스템의 개발과정을 진행하며, 수많은 실험과 검증을 끝으로 완벽한 데이터의 보안, 트래픽 대응능력, 데이터 유효성 검증을 갖추게 되었다. Frontend와 Backend의 개발과정을 통해 사용자인 학생들을 위한 디자인과 모든 시스템의 완벽한 작동을 위한 데이터 유효성 검증을 완료하였다. 이를 통해 교내 축제 티켓 예매 시스템의 빈 틈인 불공정한 예매 즉, 부정예매를 방지할 수 있었다. 또한 이와 비슷한 문제가 발생하였을때 어떻게 대응해야하는지, 어떠한 결과값을 도출해내야 하는지 배우게 되었다. 이러한 수 많은 검증 과정과 데이터 실험결과를 통해 관심 분야인 코딩 부문의 웹 개발과 대규모 트래픽 대응에 대해 한 발자국 더 나아갈 수 있는 시간이었다.