민사 고 간편 결제 제작 기 
 Featured DevLog Korean 
 by S Cho 6 months ago 23 min read 
 사용 자 400 명 
 거래 횟수 2 , 900 건 
 누적 지불액 460 만 4 , 210 원 
 누적 거래 액 1 , 731 만 9 , 300 원 
 민사 페이 는 민사 고 여름 축제 를 위해 제작 된 간편 결제 시스템 이 다 . 학생증 의 RFID 칩 을 사용 하 여 미리 학생증 과 연동 된 계정 에 현금 을 충전 해서 사용 한다 . 축제 가 끝난 뒤 미 사용 금액 은 환불 이 가능 하 다 . 축제 당일 실제 서버 에서 사용 된 모든 코드 는 GitHub 에서 확인 할 수 있 다 . 축제 당일 의 익명 결제 기록 또한 GitHub 에서 확인 할 수 있 다 . 
 고등학교 축제 에 간편 결제 가 왜 필요 한가 ? 
 많 은 학교 에 는 각자 의 여름 축제 가 있 다 . 민족 사관 고등학교 ( 민 사고 ) 는 여름 축제 를 민족 제 라고 한다 . 학생 들 이 부스 를 열 어서 먹거리 와 기념품 을 판매 하 고 , 영화관 이나 댄스 클럽 등 을 운영 한다 . 방송 부원 들 이 제작 한 1 시간 가량 의 영상 들 을 다 같이 감상 하 기 도 한다 . 이 외 에 도 많 은 행사 들 이 있 지만 그 중 단연 으뜸 은 물놀이 이 다 . 민족 제 는 여름 방학 하루 전 에 있 기 때문 에 오후 내내 물놀이 가 있 다 . 참고 로 민족 제 에 대해 2 년 전 에 제작 한 영상 이 있 으니 궁금 하 다면 여기 를 눌러 주 길 바란다 . 
 민족 제 에 는 판매 되 는 물품 이 꽤 많 다 . 때문 에 현금 거래 는 어려움 이 많 았 다 . 이 문제 를 해결 하 기 위해 민족 제 화폐 라는 제도 가 생겼 다 . 학생회 ( 금융 정보 부 ) 가 은행 의 역할 을 하 여 현금 을 관리 하 고 민족 제 화폐 를 교환 해 주 는 것 이 다 . 매년 새롭 고 참신 한 화폐 가 제작 되 었 기 때문 에 상징 성 과 소장 성 이 높 기 도 했 다 . 
 2018 년 민족 제 화폐 디자인 . 실제 디자인 에 는 민사 고 학생회 중 행정 , 입법 , 사법 위원장 의 사진 과 이름 이 포함 되 어 있 었 다 . 
 하지만 여러 문제 가 있 었 다 . 우선 친환경 이 지 못했 다 . 매년 몇 백 , 몇 천 장 의 지폐 가 새로 인쇄 되 고 이후 그대로 폐기 처분 되 었 다 . 장기간 사용 되 는 화폐 라면 모를까 , 단 하루 사용 하 기 위해 종이 수백 장 을 낭비 한다는 것 은 불 필요 하 게 자원 을 낭비 하 는 것 이 었 다 . 
 또한 언급 한 물놀이 도 문제 를 만들 었 다 . 민 사고 학생 들 은 ( 당연 하 게 도 ) 특수 화폐 를 제작 할 능력 이 없 다 . 기껏해야 조금 두꺼운 종이 에 인쇄 해서 사용 하 는 정도 였 다 . 그래서 오후 내내 물놀이 를 하 고 나 면 종이 화폐 가 모두 물 에 젖 어 찢어졌 다 . 수만 원 상당 의 수해 ( 水害 ) 를 입 은 수재민 ( 水災 民 ) 들 이 발생 할 정도 였 다 ! 이 때문 에 민 사고 의 학생 들 은 종이 화폐 를 사용 하 지 않 으면서 결제 를 할 수 있 는 방안 을 모색 하 게 되 었 다 . 
 학생회 에서 나 에게 처음 으로 간편 결제 시스템 ( 이하 민사 페이 ) 개발 을 제안 했 다 . 나 도 비슷 한 고민 을 한 적 이 있 었 기 때문 에 민사 페이 의 개발 가능 성 , 결제 시스템 의 필요 조건 등 이모저모 를 깊 게 따져 보 았 다 . 그리고 바로 제작 에 도입 할 수 있 을 정도 로 전체 적 이 고 구체 적 으로 구상 했 다 . 하지만 결국 고민 끝 에 제작 하 기 어렵 다는 판단 을 내렸 다 . 
 나 는 개발자 의 책임 을 깊 게 이해 하 고 있 다 . 개발자 들 은 요구 된 기술 사양 만 맞추 어 단순 납품 하 는 사람 들 이 아니 다 . 기술 을 매개 로 컴퓨터 와 소통 하 여 사람 들 의 삶 을 가장 파격 적 으로 변화 시킬 수 있 는 잠재 성 을 가진 사람 들 이 다 . 개발자 들 은 사람 들 의 삶 을 실질 적 으로 변화 시킬 강력 한 힘 을 가지 게 되 며 , 그 힘 을 사회 를 향상 시키 는 데 사용 하 는 것 이 책임 이 다 . 그렇 기에 개발자 들 은 자신 의 코드 한 줄 이 얼마나 큰 파장 을 불러올 수 있 는지 이해 해야 한다 . 
 욕심 이 나 기 는 했 다 . 하지만 나 는 일반 적 인 개발 은 해 본 적 이 있 으나 보안 이 강조 되 는 프로젝트 는 맡아본 적 이 없 다 . 물론 모든 일 에 처음 은 있 겠 으나 , 민사 페이 와 같 은 큰 프로젝트 로 시작 하 라는 것 은 위험 이 너무 컸 다 . 수많 은 질문 이 머리 를 오갔 다 . 만 일 코드 한 줄 이 잘못 돼서 통장 잔고 가 모두 사라진다면 ? 결제 기록 이 꼬인 다면 ? 해킹 을 당해서 금액 이 조작 당한다면 ? 이런 극단 적 인 상황 까지 가 지 않 는다고 해도 서버 가 마비 되 어 결제 를 전혀 할 수 없 게 된다면 ? 
 세상 은 대담 한 사람 을 칭송 하 지만 나 는 그 보다 신중 함 을 선호 한다 . 소신 과 만용 은 한 끗 차이 이 다 . 특히 돈 을 다루 는 시스템 은 버그 가 전혀 없 어야 한다 . 동작 하 기 만 하 면 되 는 것 이 아니 라 전천후 오류 없이 돌아가 는 견고 한 코드 여야 한다 . 시도 하 면 불 가능 할 것 같 지 는 않 았 지만 , 철저히 무경험자 인 내 가 단번에 " 아무 일 없 을 거 야 " 고 생각 하 는 것 은 내 능력 에 대한 과신 이 었 다 . 그래서 제작 이 어려울 것 같 다고 이야기 했 다 . 
 구글 설문지 를 이용 한 결제 ? 
 그럼에도 불구 하 고 학생회 는 민사 페이 를 여전히 진행 하 겠 다고 했 다 . 처음 에 그 소식 을 듣 고 학생회 가 전문 업체 에 외주 를 준다고 생각 했 다 . 차라리 그게 나을 것 같 았 다 . 최소한 시스템 보안 의 기본 은 다 할 것 이 기 말 이 다 . 하지만 학생회 의 생각 은 달랐 다 . 학생회 부원 들 이 직접 개발 을 한다고 했 다 . 무려 구글 설문지 기반 으로 . 
 앞서 민사 페이 를 구상 하 면서 집중 적 으로 풀려 했 던 문제 는 인증 에 관한 것 이 었 다 . 구매자 가 무언가 를 구매 할 때 판매자 와 개발자 에게 비밀 번호 가 공유 되 지 않 는 동시 에 그 구매자 를 식별 해서 정확 한 연산 을 할 수 있 어야 하 고 , 구매자 가 원 하 지 않 을 때 는 결제 가 되 지 않 도록 안전 장치 를 마련 해야 한다 . 그래야 구매자 가 잔고 보다 더 많 은 돈 을 결제 할 수 없 을 것 이 고 , 악의 적 으로 다른 계좌 로 결제 하 지 못할 것 이 다 . 이 인증 이 실시간 으로 이루어져야 한다 . 하지만 구글 설문지 으로 는 그 방법 이 전혀 생각나 지 않 았 다 . 어찌어찌 다른 것 들 을 해결 한다고 어떻게 실시간 인증 을 할 것 인지 에 대한 궁금증 은 풀리 지 않 았 다 . 그래서 학생회 에게 더 자세히 물 어 보 았 다 . 학생회 의 구상 은 다음 과 같 았 다 . 
 ⚡ ️ Google Form 을 이용 한 결제 시스템 동작 원리 
 학생 한 명 당 구글 설문지 를 하나 만든 다 . ( 총 400 명 가량 ) 
 그 구글 설문지 링크 를 각자 QR 코드 로 제작 한다 . 
 학생 들 에게 방수 놀이 공원 팔찌 의 형태 로 QR 코드 를 나눠 준다 . 
 결제 를 할 때 그 팔찌 를 보여준다 . 
 판매자 는 QR 코드 를 스캔 해서 개인 정보 보호 창 으로 구글 설문지 를 연다 . 
 구글 설문지 에 는 가격 , 부스 를 입력 한다 . 
 설문지 를 제출 한 뒤 창 을 닫 는다 . 
 즉 각자 생성 되 는 구글 설문지 의 주소 를 암호 처럼 사용 하 는 것 이 다 . 개인 정보 보호 창 으로 열 기 때문 에 나중 에 누가 악의 적 으로 다른 계좌 를 공격 하 려 해도 보호 를 할 수 있 을 것 이 다 . 만약 이런 제도 를 도입 한다면 후불제 를 도입 해야 했 을 것 이 다 . 하지만 개발자 의 관점 에서 이 방식 은 너무나 도 끔찍 했 다 . 짧 게 생각 해도 이런 문제 가 있 었 다 . 
 💣 찾 은 문제점 들 
 400 명 가량 의 설문지 는 어떻게 관리 하 는가 ? 
 ( 악의 적 이 든 아니 든 ) 팔찌 를 잃 어 버리 는 사람 이 나올 것 이 다 . 그런 사람 들 의 돈 을 정산 하 기 위해서 는 구글 설문지 마다 소유자 를 기록 해 두 어야 할 텐데 이 를 어떻게 관리 할 것 인가 ? 구글 설문지 에 이름 을 저장 해둔다면 팔찌 가 뒤섞이 지 않 고 정확 하 게 학생 들 에게 전달 할 수 있 는가 ? 
 판매자 가 개인 정보 보호 창 으로 열 지 않 아도 학생 들 은 알아차릴 수 없 을 것 이 다 . 그 경우 설문지 가 방문 기록 에 남 아 있 으므로 악의 적 인 공격 이 가능 해 지 는데 이 를 어떻게 방지 하 는가 ? 설문지 에 암호 를 추가 하 여 암호 가 일치 하 는 결제 기록 만 후불제 로 계산 하 는 방식 도 동작 은 하 겠 다 . 하 지만 … 
 판매자 가 부스 를 직접 선택 해서 금액 을 입력 한다면 , 부스 이름 이나 금액 을 잘못 입력 하 는 사람 이 생길 것 이 다 . 금액 을 잘못 입력 하 는 문제 는 당사자 들 에게 물어봐 해결 할 수 있 을지 몰라도 , 부스 를 잘못 입력 하 는 경우 누가 잘못 입력 한 것 인지 찾 는 것 이 매우 고통 스러울 것 이 다 . 가령 전체 기록 중 20 건 의 판매자 부스 가 뒤바뀌 었 다고 해 보 자 . 데이터 로써 가치 는 있 을 것 이 며 , 누가 잘못 기록 한 것 인지 어떻게 추적 할 것 인가 ? 
 나중 에 잔고 계산 및 통계 는 어떻게 처리 할까 ? 400 명 의 엑셀 파일 을 언제 추출 해서 통합 하 는가 ? 게다가 민족 제 다음 날 은 방학 식 이 다 . 학생 들 이 선불 로 결제 한 경우 돈 이 아까워서라도 돈 을 찾 으러 오 지만 후불제 인 경우 귀찮 아서 안 올 가능 성 도 염두 에 두 어야 한다 . 돈 을 지불 하 라고 수십 명 에게 재촉 문자 를 보내 는 것 은 여간 번거로운 일 이 아니 다 . 반면 선불 제 라면 불가피 할 경우 직접 계좌 나 전화 번호 로 일단 송금 해 주 면 된다 . 굳이 힘들 게 수십 명 에게 문자 를 돌릴 필요 가 없 다 . 
 설문지 를 제작 하 는 것 은 학생회 의 구글 계정 이 다 . 학생회 의 구글 계정 은 여러 명 이 사용 할 것 인데 ( 물론 제한 된 접근권 이 있 겠 지만 , 400 명 의 설문지 를 제작 할 때 한 사람 만 일 하 지 는 않 을 것 이 라 추측 ) 학생회 중 누군가 악의 를 가지 고 설문지 를 조작 한다고 할 때 편집 기록 만 으로 알아낼 수 있 는가 ? 
 이 모든 과정 에서 사람 의 실수 가 일어나 지 않 을 수 있 는가 ? 
 물론 이상 적 인 환경 에서 는 동작 할 것 이 다 . 하지만 그 과정 에서 수많 은 혼선 이 있 을 것 이 고 학생 들 의 불편 함 이 생길 것 이 다 . 차라리 그럴 바 에 는 내 가 제작 을 맡 은 뒤 내 방식 대로 제작 하 는 것 이 낫 다고 생각 했 다 . 학생회 와 여러 차례 의견 을 주고받 은 결과 민사 페이 를 시도 해 보 는 것 으로 결정 하 게 되 었 다 . 
 다행히 도 나와 뜻 을 함께 하 는 친구 를 만났 다 . 생각 하 는 제작 방향 도 상당히 동일 했 다 . 나 는 이전 에 구상 했 던 민사 페이 에 대해서 설명 을 해 주 었 고 , 서로 조율 을 하 며 실제 프로덕트 를 제작 하 였 다 . 카페 에서 몇 번 만나 기 도 했 다 . 나 는 DNS 설정 및 관리 , Front end 제작 을 맡 았 다 . 다음 은 민사 페이 가 완성 될 때 까지 우리 가 했 던 고민 들 이 다 . 
 🤔 고민 한 내용 들 
 현금 을 거래 에 사용 하 기 는 어려울 것 이 다 . 사업자 등록 도 되 지 않 았 고 단 하루 사용 하 는 것 이 기 때문 에 PG 등 의 결 제사 를 이용 하 기 는 어려울 것 이 다 . 그렇 다고 토스 나 카카오 페이 같 은 간편 송금 서비스 를 사용 하 기 에 는 스마트폰 이 없 는 학생 들 도 많 았 다 . 그렇 기 때문 에 유저 ( 구매자 ) 쪽 에 는 전자 장비 가 없 어야 한다 . 대신 각 판매자 의 부스 마다 컴퓨터 를 설치 해 두 어야 한다 . 
 사람 손 이 전혀 가 지 않 는 완전 자동 시스템 은 제작 이 불 가능 하 다 . 특히 현금 을 다루 는 부분 에서 는 어쩔 수 없이 학생회 ( 금융 정보 부 ) 의 도움 을 빌려야 한다 . 신뢰 할 수 있 는 금융 정보 부원 들 이 직접 돈 을 확인 하 고 데이터 를 입력 해 주 는 과정 을 거쳐야 한다 . 
 최소한 판매자 와 구매자 를 잘못 입력 할 일 이 없 도록 해야 한다 . 앞서 언급 했 듯이 다른 오류 는 바로잡 을 수 있 어도 이 부분 은 절대 잘못 되 면 안 된다 . 즉 구매자 와 판매자 들 이 자신 들 의 이름 을 잘못 기록 하 는 실수 를 하 지 않 을 것 이 라 신뢰 하 면 안 된다 . 대신 결제 중 절대 착오 가 날 수 없 는 환경 을 설계 해야 한다 . 
 부스 는 쉽 게 번잡 해진다 . 그런 과정 에서 아이디 와 비밀 번호 를 일일이 입력 하 고 있 게 된다면 불편 함 을 야기 할 것 이 다 . UX 적 인 면 에서 원터치 결제 를 할 수 있 으면 좋 겠 다 . 
 이 를 위해서 는 학생증 을 이용 하 면 좋 을 것 이 다 . 학생증 내부 에 는 이미 개인 식별 이 가능 한 값 이 들어가 있 다 . 즉 학생증 의 고유 번호 를 비밀 번호 로 사용 하 는 것 이 다 . 이렇게 되 면 학번 을 아이디 로 , 학생증 의 고윳값 을 비밀 번호 로 사용 이 가능 하 다 . 비밀 번호 가 서로 다르 다는 것 이 보장 이 되 기 때문 에 비밀 번호 ( 학생증 값 ) 만 으로 결제 가 가능 할 것 이 다 . 판매자 는 판매자 계정 으로 로그인 을 해야 하 고 , 구매자 는 학생증 을 소지 해야 결제 할 수 있 도록 하 자 . 
 결과 적 으로 선불 교통 카드 와 비슷 한 모습 을 하 게 된다 . 미리 학생증 과 연동 된 계정 에 현금 을 충전 해서 현금 대신 사용 한다 . 당연히 미 사용 금액 은 환불 이 가능 하 다 . 
 의견 이 갈리 는 부분 은 2 가지 였 다 . 
 첫째 는 웹 기반 으로 제작 할 것 인지 프로그램 기반 으로 제작 할 것 인지 에 대한 문제 였 다 . 그 친구 는 Windows exe 기반 의 프로그램 을 제작 하 자 했 다 . 나 는 멀티 플랫 폼 을 지향 했 고 exe 프로그램 들 에 큰 불신 이 있 었 기 에 웹 을 주장 했 다 . 예상 했 겠 지만 난 Mac 을 쓰 는 개발자 이 다 . 
 둘째 는 원터치 결제 를 할 때 RFID 를 사용 할 것 인지 바코드 를 사용 할 것 인지 에 관한 문제 였 다 . 학생증 에 는 RFID 칩 과 바코드 가 둘 다 있 다 . RFID 를 사용 하 게 된다면 약 10 대 가량 의 RFID 리더 를 구매 해야 하 는데 , 이 비용 이 10 만 원 정도 되 었 다 . 때문 에 나 는 노트북 내장 카메라 를 이용 하 여 바코드 를 스캔 하 는 방법 을 주장 했 다 . 올해 시범 운영 하 는 제도 라 자치 회비 를 사용 하 게 된다면 제도 의 실효 성 에 대한 의문 이 생길 것 같 았 기 때문 이 다 . 
 결국 웹 을 고르 는 동시 에 RFID 를 사용 하 기 로 했 다 . 하나 씩 양보 한 셈 이 다 . 나 는 카메라 를 이용 한 바코드 인식 이 브라우저 상 에서 성능 에 그리 좋 지 않 을 뿐 더러 인식 이 그리 빠르 지 않 다는 것 을 알 게 되 자 RFID 를 사용 하 자는 주장 을 받아들였 다 . 
 왼쪽 부터 메인 페이지 , 관리자 페이지 , 계좌 조회 페이지 . 
 앞서 했 던 고민 중 서버 가 터지 면 어쩌 지 라고 고민 했 던 것 을 기억 하 는가 ? 
 축제 당일 3 학년 학생 들 은 오전 내내 자습 을 하 기 때문 에 학교 자습실 에 있 었 다 . 그러다가 갑자기 전화 가 연달 아 울리 는 것 이 다 . 전화 를 받 아 보 니 우려 했 던 일 이 터진 것 이 었 다 . 결제 서버 가 마비 되 었 다 . 부리나케 내려가 서 상황 을 파악 해 보 았 다 . 구석 에 앉 아 같 은 개발자 친구 와 함께 이유 를 파악 하 려 해 보 았 다 . 
 데이터베이스 가 응답 을 하 지 않 고 있 었 다 . 생각 보다 어이없 는 문제 였 다 . 처음 데이터베이스 를 구축 할 당시 무료 플랜 만 으로 충분 할 것 이 라 판단 해서 무료 플랜 을 사용 했 는데 , 오전 10 시 전후 로 거래 가 일시 에 몰리 자 Free Tier 를 넘어간 것 이 다 . 9 달러 플랜 을 결제 했 고 그 이후 로 는 서버 가 다시 터지 지 않 았 다 . 
 민사 페이 공백기 에 는 각자 컴퓨터 에 엑 셀 로 학생 이름 과 금액 을 기록 해 두 었었 다 . 나중 에 그 를 모두 취합 해서 외상 부스 를 만들 어 돈 을 후불 하 는 것 으로 사태 를 수습 했 다 . 
 나중 에 기록 을 보 며 10 시 17 분 55 초 에 결제 가 멈춰서 10 시 31 분 10 초 에 결제 가 다시 되 기 시작 했 다는 것 을 알 게 되 었 다 . 이전 에 는 분당 결제 가 평균 10 회 , 많 게 는 30 회 도 일어난 반면 복구 직후 에 는 한동안 결제 빈도 가 낮 았 다는 점 이 당연 하 면서 도 흥미 롭 게 다가왔 다 . 이 기록 이 궁금 하 다면 여기 를 보 기 바란다 . 
 1546 번 결제 이후 13 분 15 초 동안 서버 가 다운 되 었 다 . 데이터베이스 저 장소 의 Free Tier 사용량 을 초과 한 것 이 이유 였 다 . 
 민사 페이 minsapay . com 
 민사 페이 코드 베이스 github . com / minsapay / server 
 민사 페이 익명 결제 기록 github . com / minsapay / transaction - data - 2019 
 티셔츠 를 구매 하 기 위해 민사 페이 로 ₩ 8 , 000 을 결제 했 던 영상 이 다 . 인터넷 익스플로러 와 도 완벽 하 게 호환 ( ...) 된다 . 
 # 1 . 민사 페이 
 리얼 서버 에서 사용 된 민사 페이 의 전체 코드 가 GitHub 에 업로드 되 어 있 다 . 민사 페이 또한 데이터베이스 를 초기 화 하 여 복구 해 두 었 다 . 
 난 여전히 이 코드 의 보안 이 극도 로 취약 할 것 이 라는 의심 이 든다 . 코드 를 오픈 소스 로 공개 했 기 때문 에 코드 상 의 취약점 하나 를 다른 분 께서 발견 해 주 셔서 사전 에 고칠 수 있 었 다 . 하지만 여전히 수많 은 보안 문제 가 있 을 것 이 다 . 또한 결제 를 하 기 위해 RFID 를 인식 하 는 순간 값 이 복사 되 어 저장 할 수 있 다는 취약점 은 해결 되 지 않 았 다 . 
 # 2 . 결제 데이터 
 빅 데이터 를 공부 하 는 민사 고 학생 들 에게 조금 더 밀접 하 게 연관 이 있 는 동시 에 흥미 로운 소재 를 주 고 싶 었 다 . 또한 민족 제 부스 운영 자 들 에게 도 성공 적 인 부스 운영 을 위한 참고 자료 를 주 고 싶 었 다 . 그래서 모든 결제 기록 을 공개 하 기 로 했 다 . 다만 한 가지 문제점 이 있 었 다 . 개인 정보 보호 문제 이 다 . 비록 사소 한 정보 일지라도 개인 의 금융 기록 인데 , 그 기록 이 공개 된다는 것 은 큰 개인 정보 보호 문제 가 있 었 다 . 
 때문 에 Jupyter Notebook 으로 짧 은 스크립트 를 작성 했 다 . csv 확장자 로 원본 데이터 를 입력 하 면 선택 한 열 을 익명 화 하 는 스크립트 이 다 . 당연히 동일 한 실명 은 같 은 익명 값 로 출력 된다 . 
 def anonymize ( df , targetColumn ) : 
 for x in range ( len ( df ) ) : 
 if user in anon : 
 if id < 10 : 
 elif id < 100 : 
 anonymize ( Dataframe , ' user ') 
 anonymize ( Dataframe , ' booth ') 
 데이터 는 여기 에서 확인 할 수 있 다 . 
 이 글 을 읽 고 자신 의 학교 에서 비슷 한 시스템 을 도입 하 고 싶 은 사람 들 이 분명히 있 을 것 같 다 . 만 일 이 코드 를 사용 하 게 된다면 검증 을 확실 하 게 하 길 바란다 . 아니 , 아예 재 설계 하 길 바란다 . 참고 로 민사 페이 시스템 은 MIT 라이선스 이 다 . 
 개선 점 이 분명히 많 다 . 
 우선 다시 봐도 아쉬운 코드 가 많 다 . 그 당시 에 도 시간 을 맞추 기 위해 타협 을 많이 했 던 기억 이 난다 . 결제 취소 등 의 기능 이나 여러 인터페이스 단계 의 안전장치 들 들 도 구상 했으나 축제 전 에 완성 하 기 위해 개발 시작 도 못 했었 다 . 시간 이 조금 만 주어진다면 더 나았 을 것 같 다는 생각 이 들 면서 도 , 그게 내 능력 부족 이 라는 생각 이 들 었 다 . 
 또한 보안 에 자신 이 없 었 기 때문 에 처음 에 는 저 장소 를 조용 하 게 유지 했 다 . 감춰서 유지 되 는 보안 은 절대 좋 은 보안 이 아니 라는 점 을 알 고 있 으면서 도 그런 악습 을 되풀이 하 는 내 모습 이 참 모순 적 이 었 다 . 
 마지막 으로 사람 의 실수 에서 자유 롭 지 못했 다 . 휴먼 에러 가 몇 건 생겼 다 . RFID 값 은 긴 숫자 열 인데 , 충전 금액 칸 에서 RFID 를 태그 하 는 바람 에 충전 금액 이 Integer . MAX _ VALUE 같 은 값 이 된 것 이 다 . 간단 하 게 50 , 000 원 이상 추가 하 는 경우 재확인 을 하 는 인터페이스 등 을 적용 했 으면 해결 될 문제 였 는데 이런 실수 가 발생 할 것 이 라 예상 하 지 못했 다 . 
 전반 적 으로 되돌아볼 때 , 실무 에 적용 하 는 첫 프로젝트 였 다는 점 에서 나 에게 큰 경험 이 었 다 . 나쁜 개발 패턴 을 알 고 있 으면서 도 현실 과 타협 하 는 내 모습 을 발견 하 게 되 었 고 , 아 는 것 과 실제로 할 수 있 는 것 은 분명 다르 다는 것 을 뼈저리 게 느꼈 다 . 아 는 것 에 는 문턱 이 없 지만 실제 행동 으로 옮길 때 는 극심 한 시간 적 , 환경 적 스트레스 가 동반 되 기 때문 이 다 . 지식 의 실무 대입 은 보이 는 것 보다 멀리 있 었 다 . 
 그래도 정말 즐거운 프로젝트 였 다 . 
 마지막 으로 민사 페이 가 있 도록 도와 준 모든 학생 들 에게 큰 감사 를 전하 고 싶 다 . 
 같이 민사 페이 를 개발 해 준 안주 언 동료 개발자 ( GitHub , Blog ) 
 민사 페이 정책 을 추진 해 준 행정 위원회 , 금융 정보 부 
 민사 페이 서버 의 보안 이슈 를 제보 해 주 신 개발 자분 들 
 민사 페이 의 서버 다운 으로 불편 함 을 겪 고 도 이해 해 줬 던 사람 들 
 그 외 에 민사 페이 를 사용 해 준 400 명 의 사람 들 
 모두 정말 감사 합니다 ! 
 Migrating a Node . js app from AWS Elastic Beanstalk to Heroku 
 동영상 압축 과 유체 이탈 
 Ghost 3 . 11 self - hosted on DigitalOcean distributed by Cloudflare . 
 Code Korean English Apple DevLog Tech