1. 시작은 동아리가 아니라 우리매점이었다
DevCoop는 학생들과 함께 운영한 전공·자율동아리였지만, 이 이야기의 출발점은 동아리 소개가 아니라 학교 안의 아주 구체적인 문제였다. 우리 학교 매점은 단순한 사설 매점이 아니라 학생, 학부모, 교사가 함께 운영하는 사회적 협동조합 공간-아리소리 었다.
이 구조는 의미가 컸다. 학교 구성원이 함께 운영한다는 점에서 교육적으로도 가치가 있었고, 학생들이 소비자이면서 동시에 운영 구조의 일부라는 점도 흥미로웠다. 하지만 현실은 만만하지 않았다. 유통업체 입장에서는 학교 매점이 접근하기 쉬운 거래처가 아니었고, 그 결과 상품 원가 자체가 높았다. 여기에 포스기 유지비까지 계속 나가고 있었다.
즉, 문제는 단순히 "매점 앱을 하나 만들어 보자"가 아니었다. 이미 빠듯한 구조 안에서 운영비를 줄이고, 업무를 덜고, 실제로 돌아가는 시스템을 만들어야 했다. DevCoop의 프로젝트들은 대부분 이런 식으로 시작했다. 아이디어보다 먼저 현실의 불편이 있었고, 기술은 그 불편을 줄이기 위한 수단으로 들어왔다.
2. AriPay의 시작은 종이 상품권의 유효성 검증이었다
당시 우리매점에서는 상품권도 자체 제작하고 있었다. 그런데 종이 상품권을 쓰기 시작하면 생각보다 손이 많이 가는 일이 따라온다. 위조를 막아야 하고, 이미 사용한 상품권인지 확인해야 하며, 누가 언제 사용했는지도 관리해야 한다.
이때 처음 등장한 것이 AriPay의 씨앗이었다. 종이 상품권마다 유효성을 확인할 수 있는 QR을 만들고, 이를 데이터베이스와 연결해 사용 여부를 관리하는 시스템을 붙인 것이다. 지금 돌아보면 아주 작은 시작처럼 보이지만, 사실 이 단계에서 이미 중요한 전환이 일어났다.
종이 상품권은 원래 오프라인 물건이지만, QR과 DB가 붙는 순간부터 그것은 단순한 종이 조각이 아니라 상태를 가진 데이터가 된다. 발행 여부, 사용 여부, 중복 사용 방지, 검증 기록 같은 개념이 들어오고, 그때부터 문제는 인쇄물이 아니라 서비스의 문제가 된다. 내가 AriPay의 진짜 시작을 이 지점으로 보는 이유다.
3. 종이 500장을 찍는 대신 학생증을 쓰자
하지만 QR 상품권으로도 해결되지 않는 문제가 있었다. 상품권을 발부하는 일 자체가 너무 번거로웠다. 한 번 발행할 때마다 종이 상품권을 500장씩 준비해야 했고, 이 작업을 위해 매점부 인원 약 10명이 1시간 정도를 써야만 했다. 발행 시스템이 있다는 것과 발행 과정이 효율적이라는 것은 완전히 다른 문제였다.
그래서 다음으로 나온 아이디어는 종이를 줄이는 것이었다. 이미 학생들이 매일 들고 다니는 학생증의 바코드를 활용하고, 여기에 개인 인증을 붙이면 별도의 종이 상품권 없이도 사용 권한을 확인할 수 있지 않을까 생각했다.
이렇게 해서 만들어진 것이, 학생증 바코드를 읽고 개인 인증을 거쳐 상품권처럼 사용할 수 있는 웹 서비스였다. 내가 기억하는 AriPay의 본격적인 시작은 바로 이 단계다. 단순한 QR 검증 도구에서 한 걸음 더 나아가, 학생 개인을 기준으로 사용 권한과 결제 경험을 묶는 서비스가 된 것이다.
이 초기 웹 서비스는 프론트엔드를 React로, 백엔드를 Node.js + Express로 구성하며 출발했다. 학생들과 함께 빠르게 화면을 만들고 인증과 사용 기록을 붙여 보기에 적합한 조합이었고, 실제로 DevCoop의 첫 개발 경험도 이 구조 위에서 쌓였다.
여기서부터 기술적인 난이도도 달라졌다. 단순 조회가 아니라 인증이 필요했고, 학생 계정과 사용 내역이 연결되어야 했으며, 실제 점심시간 동선 안에서 빠르게 작동해야 했다. 즉 "만들 수 있는가"보다 "점심시간에 실제로 쓸 수 있는가"가 더 중요한 기준이 되었다.
4. 점심시간의 병목이 Occount를 만들었다
학생증 기반 웹 서비스가 생겨도 점심시간의 혼잡은 여전히 큰 문제였다. 짧은 시간에 많은 학생이 한꺼번에 몰리면, 결국 계산 과정 자체가 병목이 된다. 그래서 자연스럽게 키오스크의 필요성을 느끼게 되었다.
이 시점부터 서비스의 성격도 조금 달라졌다. 원래 Occount는 단순 결제 도구만을 뜻하는 이름이 아니었다. 재고 관리, 자동 주문 같은 기능까지 포함한 더 넓은 운영 시스템을 지향하고 있었다. 다만 당시 가장 급한 문제는 거창한 운영 자동화가 아니라, 매점에서 바로 써야 하는 셀프 계산대를 만드는 일이었다.
그래서 우선순위를 분명히 했다. "언젠가 필요한 기능"보다 "지금 당장 점심시간을 버텨 줄 기능"이 먼저였다. 그렇게 학생 포인트만으로 사용할 수 있는 키오스크를 만들기 시작했고, 이 흐름 속에서 서비스명도 AriPay에서 Occount로 옮겨 가게 되었다.
내가 이 전환을 중요하게 보는 이유는, 이때부터 프로젝트가 단순 결제 보조 도구가 아니라 매점 운영 시스템으로 확장되기 시작했기 때문이다. 이름이 바뀐 것은 브랜딩 변화라기보다 문제의 범위가 넓어졌다는 신호에 가까웠다.
5. 1년 동안 결제사를 설득하며 셀프 계산대를 만들었다
셀프 계산대를 만든다고 해서 바로 끝나는 일은 아니었다. 실제로 운영 가능한 키오스크를 만들려면 카드 단말기와의 연동이 필요했고, 그러려면 VAN사와 PG사와의 협력이 반드시 필요했다. 학생 프로젝트라고 해서 예외가 생기지는 않았다. 오히려 더 많이 설명해야 했고, 더 오래 기다려야 했다.
이 과정을 풀어 보면 기술보다 협업과 조율의 시간이 더 길었다. 카드 단말기와 웹소켓으로 연동할 수 있는 구조를 얻어내기 위해 연락을 이어 갔고, 협력 가능한 방식을 찾는 데만 1년 가까운 시간이 들었다. 이 시간은 개발 일정이 지연된 시간이 아니라, 실제 세상과 연결되기 위해 반드시 지나야 했던 시간이었다.
구조가 잡힌 뒤에는 결제 처리 모듈을 FastAPI로 만들고, 키오스크 클라이언트는 Flutter로 구현했다. 그렇게 해서 학생 포인트와 결제 흐름을 실제 현장에 맞게 처리할 수 있는 셀프 계산대를 완성했고, 결국 학교 매점에서 성공적으로 운영할 수 있었다.
이 과정에서 웹 서비스의 본체도 함께 성숙했다. 처음에는 React + Node/Express로 시작했던 구조가, 운영 기능과 관리 기능이 커지면서 점차 Java + Spring Boot 기반 백엔드로 넘어갔다. 즉 DevCoop의 기술 변화는 유행을 따라간 결과가 아니라, 실제 서비스 운영이 요구한 안정성과 구조를 따라간 결과였다.
지금 로컬에 남아 있는 소스에도 이 흔적이 일부 보인다. 웹 서비스 쪽에는 occount.bsm-aripay.kr를 사용하는 코드가 남아 있고, 키오스크 계열 프로젝트도 별도로 존재한다. 물론 코드 몇 줄보다 더 중요한 것은, 학생들과 함께 만든 시스템이 실제 점심시간의 흐름을 바꾸는 데까지 갔다는 사실이다.
6. Occount는 다시 O-ring으로 이어졌다
이후 우리매점이 사회적 협동조합이라는 점은 또 다른 문제로 이어졌다. 협동조합은 단순히 물건을 파는 조직이 아니라, 가입 절차와 총회 운영 같은 의사결정 구조까지 함께 가져가야 한다. 매점 운영을 디지털화하다 보니, 자연스럽게 "조합 구성원 관리와 총회 운영도 더 간소화할 수 없을까"라는 질문이 나왔다.
그 결과 서비스는 다시 O-ring으로 발전했다. 이 서비스는 학생들의 가입 절차를 다루고, 실제 총회에서 안건에 대한 동의 여부를 수렴하는 데 활용되었다. 그리고 그 과정 역시 성공적으로 운영되었다. 즉 DevCoop의 프로젝트들은 하나의 앱을 고도화하는 방식만이 아니라, 학교 운영의 다른 층위로 문제를 옮겨 가며 확장되었다.
현재 로컬 작업 폴더에는 O-ring 소스가 아직 없지만, DevCoop의 흐름을 이해하려면 이 단계까지 함께 봐야 한다. AriPay, Occount, O-ring은 서로 다른 이름의 서비스이면서도, 사실은 같은 문제의식이 조금씩 확장된 결과물이기 때문이다.
7. DevCoop가 남긴 것은 기능보다 운영의 감각이었다
이 과정을 지나며 학생들은 단순히 웹 화면을 만들거나 API를 붙이는 경험만 한 것이 아니었다. 실제로는 훨씬 더 복잡한 것을 배웠다. 종이 상품권이 왜 비효율적인지, 인증은 왜 귀찮아도 필요해지는지, 점심시간의 대기열이 왜 기술 문제로 바뀌는지, 카드 결제 하나를 붙이기 위해 왜 외부 업체와 긴 시간을 조율해야 하는지를 몸으로 익혔다.
교사인 내게도 이 경험은 분명했다. 학생 프로젝트를 지도한다는 것은 결과물을 평가하는 일이 아니라, 학생들과 함께 현실의 제약을 통과하며 서비스가 운영 가능한 형태로 성숙해 가는 과정을 끝까지 지켜보는 일이었다.
그래서 이 시리즈에서는 DevCoop를 단순히 "학생들과 만든 멋진 프로젝트"로 소개하지 않으려 한다. 대신 우리매점이라는 사회적 협동조합에서 출발한 문제들이 어떻게 AriPay, Occount, O-ring으로 이어졌는지, 그리고 그 과정에서 어떤 기술적 선택과 운영상의 시행착오가 있었는지를 한 편씩 정리해 보려고 한다.
다음 글에서는 종이 상품권과 QR 검증 단계에서 무엇이 문제였고, 학생증 기반 인증 방식으로 어떻게 전환하게 되었는지를 조금 더 구체적으로 적어 보겠다.
💬 댓글
이 글에 대한 의견을 남겨주세요