26년 4월 10일 생각글

📓 일지

수업 및 정보 공유과정에서 이런저런 생각한 글

정리하려고 쓰는 게 아니라 흘려보내기 전에 적는 것

키오스크 대한 개념과 이해가 어렵게 느껴졌다. 화면에는 버튼 몇 개지만 그 안에서 처리되는 게 생각보다 복잡하다는 생각이 들어서.

---

티켓 시스템

키오스크에서 티켓 살 때 선택지가 많다. 일반, 청소년, 65세 이상 경로, 시즌 이벤트 상품, 마감 임박 여부까지. 겉으로는 단순해 보이지만 각 조건마다 다른 처리가 들어가야 한다.

65세 경로 할인 하나만 해도 — 어떻게 확인하지? 신분증 확인을 사람이 하더라도, 시스템 안에서는 그 조건이 구분되어 있어야 한다. 계절별 이벤트 상품도 마찬가지고. 개발자가 이걸 구현할 때 단순히 버튼 하나 추가하는 게 아니라, 조건마다 다른 로직을 설계하는 거다.

지금 배우는 수준에서 보면 if/elif 분기가 이런 데 쓰이는 거구나 싶다. 아직 감이 완전히 오진 않지만, 코드가 현실 어딘가의 판단 기준이 된다는 건 느껴진다.

---

메가커피 바코드

주문하면 바코드가 뜬다. 저 안에 뭐가 있을까 생각해봤다. 주문번호, 메뉴, 결제 완료 여부, 픽업 상태 정도가 담겨 있겠지. 직원이 스캔하는 순간 시스템이 읽어서 상태를 바꾼다.

마감 처리도 있다. 영업 종료 시간이 되면 주문 자체가 안 되도록 막히는 것. 이것도 어딘가에서 조건이 판단되고 있는 거다.

개념적으로만 보면 — 주문 상태를 딕셔너리로 담아두고, 스캔하면 픽업 상태 값이 바뀌고, 마감 시간이 되면 주문 가능 여부가 꺼지는 구조. 실제로는 서버랑 DB가 중간에 있어서 이것보다 훨씬 복잡하지만, 흐름 자체는 이렇다. 개념 이해용으로만.

---

레스토랑 호출벨 & 스타벅스

레스토랑 진동벨. 번호표 17번이 울리면 17번인 사람만 반응한다. 번호가 식별자 역할을 하는 거다. 아날로그처럼 보이지만 특정 대상에게만 신호를 보내는 구조는 디지털이든 아날로그든 같다.

스타벅스는 키오스크가 없다. 커스터마이징 조합이 워낙 많아서 키오스크 UI로 구현하면 오히려 복잡해지고, 앱으로 이미 디지털 전환이 되어 있다고 한다. 입력이 사람이냐 앱이냐 차이일 뿐, 데이터는 결국 같은 구조로 들어간다.

스타벅스 이유는 공식 입장을 확인한 게 아니라 일반적으로 알려진 내용 기준이다.

---

자격 증명과 검증

뉴스에서 학위 위조 관련 사건을 봤다. 자격증이나 학위 같은 것들도 따지고 보면 분류 체계다. 대학·학과·학번 조합으로 "이 사람은 이 자격을 가졌다"를 증명하는데, 이걸 제대로 검증하는 시스템이 없으면 서류 한 장으로 뚫린다.

바코드는 스캔 한 번으로 진위가 확인된다. 자격 증명은 아직 그런 구조가 없는 경우가 많다. 기술이 없어서가 아니라 시스템을 안 만들어서 생기는 문제다. 티켓처럼, 바코드처럼, 자격 증명에도 식별 코드와 검증 구조가 있으면 달라질 거라는 생각이 든다.

QR코드로 검증한다는 아이디어가 막연하게 떠올랐는데, 지금 내 수준에서 구현할 수 있을지는 모르겠다. 나중에 딕셔너리 구조나 API 호출 같은 걸 더 익히면 비슷한 걸 작게라도 만들어볼 수 있지 않을까 싶다. 아직은 방향만 보이는 단계.

---

오늘 이 생각들이 따로 흘러가다 어느 순간 연결됐다. 티켓이든 바코드든 자격 증명이든 — 결국 이 자격이 유효한가, 이 상태가 맞는가를 판단하는 구조라는 점이 같았다.

그 구조를 코드로 만드는 게 개발자 일이고, 나는 지금 그 기초를 배우는 중이다. 아직 멀었지만 이런 식으로 연결해서 보면 배우는 게 조금 더 와닿는다.

티켓 · 바코드 · 호출벨 · 스타벅스 · 자격 증명 · 식별과 검증