1. The story began with our cooperative store, not the club
DevCoop was a student-led development club I ran with students, but this story starts with a concrete school problem, not with club recruitment. Our store was not a typical vendor-run shop. It was Arisori, a social cooperative jointly run by students, parents, and teachers.
That structure mattered. The store had educational value because the school community operated it together, and students were not only customers but also part of the decision-making structure. Reality, however, was tough. Suppliers did not see a school cooperative as an easy account to serve, which kept our purchase costs high. On top of that, we were still paying the monthly cost of a POS terminal.
So the problem was never “let’s build a store app.” We had to trim costs, reduce daily workload, and build a system that actually ran inside that tight margin. Most DevCoop projects started this way: real inconvenience surfaced first, and technology entered as a tool to fix it, not an idea in search of a use case.
2. AriPay began with verifying paper vouchers
The store also issued its own paper vouchers. That sounds simple until you actually have to use them at the counter. Someone has to check whether a voucher is genuine, whether it was already used, and when it was redeemed.
That is when the seed of AriPay appeared. We added a QR code that staff could validate at checkout and connected each voucher to a database record so we could track its usage. It seems tiny in hindsight, but that is where the real pivot happened.
A paper voucher is just an object, yet once a QR code and a database attach to it, it becomes a data record with state. Suddenly we had to think about issuance, redemption, duplicate-use prevention, and audit logs. At that point the problem was no longer just about printing paper. It had become a service-design problem, and that is why I see this stage as AriPay's real beginning.
3. Use student IDs instead of printing 500 sheets
QR vouchers still left one issue unsolved: issuing them was exhausting. Every campaign required printing 500 vouchers, and roughly 10 store volunteers spent an hour on the task. Having an issuance system is different from achieving an efficient workflow.
That friction led to the next realization: why keep printing paper when every student already carried an ID card with a barcode? If we combined that with personal authentication, we could grant voucher rights without printing and distributing paper at all.
That produced a web service that scanned student IDs, authenticated the user, and treated that verified session like a voucher. I mark this as AriPay's real takeoff. It evolved from a QR checker into a service that tied permissions and payment flow to each student.
The early web app used React on the frontend and Node.js + Express on the backend. We chose that stack because it let us prototype screens quickly with students, test authentication ideas, and add usage logs without a long setup phase. It became DevCoop's first full-stack system.
The technical bar immediately rose. We now needed authentication, account-to-usage links, and a flow that actually worked during lunch. The question changed from “can we build it?” to “will it survive the lunch rush?” The answer was only partial: student-ID authentication reduced voucher work, but checkout itself was still too slow.
4. Lunch-hour bottlenecks led to Occount
Even with student ID payments, lunchtime chaos remained. When hundreds of students line up during a short break, checkout itself becomes the bottleneck. That naturally pointed us toward self-checkout kiosks.
At this point the service identity shifted. AriPay had started as the payment and voucher layer, but we were now thinking about the wider operating system around the store. That broader direction became Occount. In the longer term, we wanted it to cover inventory, ordering, and store operations as a whole. Reality forced us to prioritize. The immediate crisis was not grand automation; it was building a self-checkout counter students could use right away.
So we set priorities clearly. “Future features” had to wait until we solved “what keeps lunch moving today.” We built a kiosk that ran entirely on student points, and during that shift the service name moved from AriPay to Occount.
I highlight this transition because it marked an expansion from a payment add-on to a store operations system. The rebrand was not cosmetic—it signaled a wider problem scope.
5. One year of persuading payment processors for self-checkout
Finishing the kiosk was not the end. To run it for real we had to integrate with card terminals, which meant working with VAN and PG companies: the payment-network and gateway providers that connect retail systems to actual card processing in Korea. Student projects do not get special shortcuts; if anything we had to explain more and wait longer.
The journey was less about code and more about negotiation. From the first round of outreach to a usable integration path, we spent nearly a year contacting companies to secure a terminal that exposed a WebSocket-friendly interface. That work overlapped with development, but the approval and coordination cycle itself was slow. That year was not wasted time—it was the price of connecting a student project to real payment infrastructure.
Once the integration paths were approved, we implemented the payment module with FastAPI and built the kiosk client in Flutter. The result processed student points and cash payments reliably and eventually ran live inside the store.
The main web service matured as well. The initial React + Node/Express stack was enough for fast prototyping, but as operations and admin features grew, we needed a backend structure better suited to a larger service. That is why the main service later transitioned to Java + Spring Boot. DevCoop's tech choices followed operational demands, not trends.
You can still see traces of that evolution in the local source folders. The web service still references occount.bsm-aripay.kr, and separate kiosk projects exist. The real takeaway is that a student-built system addressed an actual lunchtime bottleneck instead of staying as a classroom demo.
6. Occount evolved again into O-ring
Because the store operated as a social cooperative, another layer of requirements appeared. A cooperative does not only sell products; it also manages membership onboarding and general assemblies where members participate in decisions. Once we digitized store operations, the next natural question was, “can we simplify membership and assembly voting too?”
That led to O-ring. The service handled student enrollment and collected votes or approvals during the cooperative assembly, and it worked in practice. DevCoop’s trajectory was not about polishing one app forever; it was shifting the same problem awareness into new layers of the school’s operation.
The current local folder does not yet contain O-ring source code, but understanding DevCoop requires following the chain: AriPay, Occount, and O-ring are separate names born from one expanding mission.
7. DevCoop left us with operational instincts, not just features
Students learned more than how to draw screens or wire APIs. They discovered why paper vouchers waste effort, why authentication becomes mandatory, how a lunch queue becomes a technical problem, and why attaching a card terminal takes months of vendor coordination.
As a teacher, I also changed. Guiding a student project was not about grading deliverables—it was walking with them as we navigated real-world constraints until the service was operational.
This series will not present DevCoop as “a cool student project.” Instead it will document how a social-cooperative store problem turned into AriPay, Occount, and O-ring, along with the technical decisions and operational missteps along the way.
The next article dives deeper into the paper voucher and QR verification stage, and how that naturally pushed us toward student ID authentication.
💬 댓글
이 글에 대한 의견을 남겨주세요