신청해요 "사장님, 노래가 듣고 싶어요." - 손님이 QR코드로 신청합니다.

주점이나 카페를 운영하다 보면 꼭 듣는 말이 있습니다.

"사장님, 이 노래 좀 틀어주세요!"

기분 좋은 요청이지만, 막상 받아보면 은근히 번거롭습니다. 손님이 부르는 소리를 놓치기도 하고, 카운터가 바쁠 땐 대답도 제대로 못 하고, 곡명을 종이에 적어뒀다가 잃어버리기도 하죠. 손님이 여러 테이블에서 동시에 요청하면 그마저도 뒤죽박죽이 됩니다.

이런 불편을 줄여보고자 작은 웹앱을 하나 만들었습니다. 이름은 "신청해요(ReqNow)" 입니다.

손님은 QR코드 한 번, 앱 설치도 회원가입도 없이

사용 방법은 아주 단순합니다. 테이블이나 카운터에 놓인 QR코드를 손님이 스마트폰으로 스캔하면, 바로 신청곡을 입력하는 화면이 뜹니다.

• 앱 설치 필요 없음
• 손님(고객)은 회원가입·로그인 필요 없음
• 관리자(점주)는 회원가입·로그인 필요
• 닉네임만 한 번 정해두면 다음 신청 때도 그대로 사용

손님 입장에서는 "찍고 → 적고 → 보내고" 세 단계로 끝입니다. 술자리 분위기를 깨지 않고 가볍게 요청할 수 있다는 게 가장 큰 장점입니다.

사장님은 실시간 대시보드로 한눈에 확인

사장님 화면(대시보드)에는 손님들이 보낸 신청곡이 실시간으로 올라옵니다. 새 신청이 들어오면 알림음도 함께 울려서, 카운터를 보면서도 놓치지 않을 수 있습니다.

몇 가지 소소하지만 유용한 기능도 넣었습니다.

• 수신 On/Off: 너무 바쁘거나 마감 시간이 다가오면 신청 접수를 잠시 꺼둘 수 있습니다. 꺼진 동안은 손님이 신청해도 접수되지 않습니다.
• 자동 삭제: 접수된 신청 내역은 8~16시간 안에 자동으로 정리됩니다. 영업이 끝나면 따로 지울 필요 없이 다음 날 깨끗한 상태로 시작할 수 있습니다.
• QR코드 화면: 매장 모니터나 TV에 QR코드를 띄워두면 손님이 언제든 스캔해서 신청할 수 있습니다.

      [참고] QR코드는 주기적으로 변경됩니다. 매장에 없는 회원이 악의적인 신청을 차단합니다. QR코드는 다양한 형태로 표시될 수 있습니다. (전체화면, 작은 윈도우 등)

왜 만들었나?

거창한 사업 아이템이라기보다는, 작은 주점·카페를 운영하는 사장님들의 자잘한 불편을 줄여드리고 싶어서 시작했습니다. 복잡한 기능보다는 "손님도 사장님도 헷갈리지 않고 바로 쓸 수 있는 것"을 목표로 만들었습니다.

이렇게 시작하세요

1. Google 계정으로 로그인
2. 상호명 등 간단한 정보 입력
3. 발급된 QR코드를 매장에 게시 (디스플레이 필요 - 주기적으로 QR 변경)

이게 전부입니다. 별도 설치나 복잡한 설정 없이 바로 오늘부터 사용해보실 수 있습니다.

현재는 무료로 이용하실 수 있습니다.
(유료화는 좀 더 고민해보겠습니다. 지금 편하게 먼저 써보시는 걸 추천드립니다.)

신청곡 받느라 매번 신경 쓰이셨다면, "신청해요"로 한번 편하게 운영해보시는 건 어떨까요?

https://reqnow.microlabs.info/

참고: 음악 재생과 저작권

"신청해요"는 손님이 원하는 곡을 편하게 "요청"할 수 있도록 도와주는 웹앱-서비스이고, 요청받은 곡을 실제로 재생하는 것은 사장님이 매장에서 사용 중인 음악 서비스를 통해 직접 재생해야 합니다.

이때 한 가지 유의하실 점이 있습니다. 매장처럼 여러 사람이 함께 있는 영업 공간에서 음악을 트는 것은 개인이 혼자 듣는 것과 달리 "공연(공개 재생)"으로 분류되어, 한국음악저작권협회(KOMCA) 등 저작권 신탁관리단체에 별도의 공연 사용료를 내야 하는 경우가 많습니다. 또한 개인용으로 가입한 스트리밍 서비스는 약관상 상업적 공간에서의 재생을 금지하는 경우도 있어, 매장용 요금제나 별도 라이선스가 필요할 수 있습니다.

사업장 평수, 저작권 등을 확실히 알아보시고, 음악 재생을 해야 합니다. 
유튜브에서 뮤직비디오, 공연 등의 영상도 유튜브 약관을 확인하여야 합니다. 

"신청해요"는 신청곡 접수·확인 기능만 제공하며, 실제 재생에 따른 저작권 처리는 매장 운영자의 책임입니다. "신청해요"를 통해 음악을 재생할 계획이라면 이용 중인 음악 서비스의 상업적 이용 가능 여부와 저작권료 납부 여부를 미리 확인해 보시길 권장드립니다. (이 안내는 법률 자문이 아니며, 정확한 사항은 한국음악저작권협회 등 관련 기관이나 전문가를 통해 확인하시기 바랍니다.)

#신청해요 #RequestNow #ReqNow #요청사항 #신청곡 #매장신청곡 #신청곡서비스 

[Code] Web Audio API 소리 (Javascript) - 첫 소리가 잘리는 현상

JavaScript Web Audio API로 알람이나 알림음을 재생하는 기능을 만들다 보면, 이상한 버그를 하나 만나게 됩니다.

앱을 켜고 처음 알람이 울릴 때는 소리가 뭉개지거나, 앞부분이 잘려서 나오거나, 아예 안 들리는 경우가 있습니다. 그런데 같은 코드로 두 번째, 세 번째 알람을 재생하면 멀쩡하게 잘 들립니다.

일정시간 동안 아무런 동작을 안하고, 소리출력을 하면 앞부분이 누락되어 들립니다. 

같은 함수, 같은 파라미터인데 왜 첫 번째 소리만 짤리는 것입니다. 

원인: 오디오 하드웨어의 "절전모드"

브라우저(그리고 OS)의 오디오 출력 경로는 계속 켜져 있지 않습니다. 실제 스피커나 오디오 드라이버 쪽에서는 소리가 한동안 나오지 않으면 절전 상태로 들어가고, 다시 소리를 출력하라는 신호가 오면 하드웨어를 깨우는 과정을 거칩니다.

문제는 이 깨어나는 과정에 시간이 걸린다는 점입니다. AudioContext를 새로 만들거나, 한동안 소리를 내지 않다가 갑자기 osc.start()를 호출하면, 오디오 파이프라인이 완전히 준비되기 전 짧은 구간 동안 출력이 손실되거나 왜곡됩니다. 알람처럼 "짧고 정확한 타이밍의 소리"를 재생하는 경우, 하필 그 손실 구간이 소리의 시작 부분과 겹쳐서 정작 중요한 첫 비트가 날아가는 현상이 발생하는 것입니다.

해결 아이디어: 진짜 소리를 내기 전에 "예열"한다

사용자에게 들려줄 알람음을 재생하기 직전에, 사람은 거의 인지할 수 없는 아주 작은 소리를 짧게 먼저 흘려보내서 오디오 하드웨어를 미리 깨워두는 것입니다.

사운드 워밍업 함수

function warmSound() {

  try {

    const ctx = ensureAudioCtx();

    const osc = ctx.createOscillator();

    const gain = ctx.createGain();

    osc.type = 'sine';

    osc.frequency.value = 5;       // 5Hz, 사실상 들리지 않는 저역

    gain.gain.value = 0.0001;      // 최소 볼륨 (사람이 거의 못 듣는 수준)

    osc.connect(gain).connect(ctx.destination);

    osc.start(ctx.currentTime);        // 지연 없이 즉시 출력

    osc.stop(ctx.currentTime + 0.5);   // 0.5초간 유지 후 정지

  } catch (e) {

    /* 워밍업 실패는 무시 - 워밍업은 보조 수단일 뿐, 실패해도 본 알람 재생에 영향 없어야 함 */

  }

}

실제 알람 재생 흐름

async function playAlarmBeep() {
  if (!alarmEnabled) return;
  const soundChoice = localStorage.getItem(ALARM_SOUND_KEY) || 'beep';
  await ensureRunning();   // AudioContext resume 등 상태 확인
  warmSound();             // 본 소리 재생 전, 오디오 하드웨어 예열
  if (soundChoice === 'dingdong') {
    setTimeout(playDingdong, 500);
  } else {
    setTimeout(playBeepTone, 500);
  }
}

실제 비프음 재생 함수

function playBeepTone() {
  try {
    const ctx = ensureAudioCtx();
    const WARMUP_DELAY = 0;      // 이미 warmSound에서 예열했으므로 추가 지연 없음
    const BEEP_DURATION = 1;     // 1초간 재생
    const startAt = ctx.currentTime + WARMUP_DELAY;
    const osc = ctx.createOscillator();
    const gain = ctx.createGain();
    osc.type = 'sine';
    osc.frequency.value = 880; // A5음
    // 갑자기 소리가 튀지 않도록 짧게 페이드 인 / 페이드 아웃
    gain.gain.setValueAtTime(0.0001, startAt);
    gain.gain.exponentialRampToValueAtTime(0.2, startAt + 0.02);
    gain.gain.exponentialRampToValueAtTime(0.0001, startAt + BEEP_DURATION - 0.05);
    osc.connect(gain).connect(ctx.destination);
    osc.start(startAt);
    osc.stop(startAt + BEEP_DURATION);
  } catch (e) {
    /* 오디오 재생 실패는 무시 (자동재생 정책 등) */
  }
}

여기서 gain.gain.exponentialRampToValueAtTime을 이용해 볼륨을 서서히 올리고 내리는 것도 눈여겨볼 부분입니다. 워밍업으로 하드웨어 자체는 깨워뒀더라도, 볼륨이 순간적으로 0에서 최대치로 튀면 노이즈가 발생할 수 있기 때문에, 페이드 인/아웃을 함께 적용해 자연스러운 소리를 만들어줍니다.

흐름을 정리하면 다음과 같습니다.

 1. ensureRunning()으로 AudioContext가 정상 동작 중인지 확인 (suspended 상태면 resume) 

 2. warmSound()를 호출해 0.5초짜리 무음에 가까운 신호를 출력, 오디오 하드웨어를 미리 깨움

 3. 워밍업 신호가 끝나는 시점(setTimeout(..., 500))에 맞춰 실제 알람음(playBeepTone 또는 playDingdong)을 재생

즉, "진짜 소리"가 나가기 0.5초 전에 미리 저강도 신호로 파이프라인을 활성화시켜 놓고, 하드웨어가 완전히 깨어난 타이밍에 실제 알람음을 흘려보내는 구조입니다.

시행착오

osc.frequency.value = 0;   // 주파수 0

gain.gain.value = 0;       // 볼륨 0

주파수가 0이거나 gain이 완전히 0이면, 오디오 그래프상으로는 신호가 흐르지만 실제 하드웨어 출력 레벨에서는 "무음"과 다를 바 없이 처리되어 절전모드를 깨우지 못했습니다. 오디오 드라이버 입장에서는 "출력할 데이터가 없다"고 판단해버리는 것이죠. 즉, 워밍업이 성립하려면 하드웨어가 실제로 "출력 신호가 존재한다"고 인식할 수 있는 최소한의 값이 필요했습니다.

"0이 아닌 아주 작은 값"을 적용해야 합니다. 

[참고]

윈도우OS 크롬, 엣지에서 첫소리가 짤리는 현상이 발생하여, 워밍업 소리 출력을 해야 했습니다. 

그러나, 맥OS 크롬에서 첫소리가 짤리는 증상은 없습니다.

맥OS에서 웹앱을 개발하다가, 윈도우OS 웹브라우저에서 이런 증상이 나와서 시행착오를 많이 했습니다. 

 

[기술조사] Device Fingerprinting (디바이스 핑거프린팅)

Device Fingerprinting (or Browser Fingerprinting)

웹앱(Web Application)을 제작구상을 하다보니, 스마트폰을 식별하는 기술이 있을까 고민하게 되었습니다. LTE 또는 5G망에서 공인IP, Javascript에서 스마트폰 고유식별번호 확인, 동일한 스마트폰, 등등...

검색과 LLM(Gemini)를 통해서 알아보니, 생각한 방안들이 제한되어 있거나, 불가능한 것이 많았습니다.

웹브라우저 / JavaScript 환경에서 스마트폰를 식별하는 기술을 기기 핑거프린팅 또는 브라우저 핑거프린팅이라고 합니다. 해당 기술에 대해서 결론부터 말하면, 동일한 시점에 출고된 100% 같은 기종을 완벽하게 식별하는 것은 이론상 매우 어려운 것으로 판단하였습니다. 

실제, 동일 모델 간에 미세하게 달리지는 소프트웨어 설정, 사용환경, 하드웨어 미세 오차를 조합해서 높은 확률로 식별할 수 있을 것 같습니다. 스마트폰의 식별하기 위해서 몇 가지 스마트폰 정보를 모아서, 나만의 고유한 조합(해시값)을 만드는 방식입니다

스마트폰 정보 (Web Browser / JavaScript 환경에서 수집할 수 있는 정보)

 1. 운영체제(OS)정보, 웹브라우저(Web Browser) 정보

 2. 디스플레이의 가로/세로 픽셀 크기, DPR(Device Pixel Ratio)

 3. 설치된 폰트 리스트(기본적으로 탑재된 폰트 + 사용자가 추가로 설치한 서체 목록)

 4. 오디오 연산

 5. 그래픽카드 WebGL 또는 Canvas

 6. 사용자의 다크모드 설정

 7. 터치 스크린 최대 동시 터치 가능 수

 8. CPU 논리 코어 수

 9. 기타 등등...

현실에서 스마트폰은 겉보기엔 같아도 내부 상태가 다를 것입니다. 

위의 요소를 선별적으로 조합하고 추가 로직이 들어간다면 고유식별율이 높아질 것이라 예상됩니다. 그리고 아이폰/안드로이드 폰에 따라서 수집한 정보가 의미가 없을 수도 있습니다. 특히, 아이폰은 하드웨어 정보를 숨기기 때문에, GPU, 모델명, 메모리 정보를 얻을 수 없거나, 상세한 정보를 제공 안합니다. 

스마트폰의 모든 요소가 같다면, 식별할 방법이 없습니다. 

서버측에서도 수신 IP는 단순 참고할 수 있는 정보입니다. 스마트폰을 고유식별성에는 문제가 있습니다. 

같은 공간에서 통신사가 동일한 스마트폰 2개를 사용되는 경우, 똑같은 공인 IP가 될 수 있습니다. 

곧, 직접 코드로 확인해볼려고합니다. 

[기타] 구글 애드센스 승인 - 재신청

구글 애드센스 승인 거절 

https://www.microlabs.info/2026/07/blog-post_04.html

동일한 사유로 거절되었습니다. "주의필요", "가치가 별로 없는 콘텐츠" 

확인해보니, 몇 가지 설정이 안되어 있어 승인이 거절된 것으로 보입니다. 구글 검색 사이트에서 저의 글이 검색이 안되고, Google Search Console에서도 글이 색인이 안되어 있습니다. 

블로그 포스팅 20여개 이상 있는데, 구글에서 검색이 안되는 것입니다. LLM를 이용해서 "애드센스 승인과 구글 서치 콘솔(Google Search Console)"과 연관이 있는지 문의했습니다. 관련이 있다고 합니다. 구글에서 검색을 할 수 있어야, 애드센스 심사를 할 수 있나 봅니다. (추측)

- Google Search Console : Sitemap 추가 유무 확인

- Google Blog(Blogger.com) : 설정 - 맞춤 로봇 헤더 태그 사용설정 활성화

Google Search Console의 Sitemap 추가는 Atom, RSS 모두 등록했습니다. 검색이나 LLM(Gemini)에서는 sitemap.xml 등록하라고 하는데, sitemap.xml 추가가 안됩니다. "https://주소/sitemap.xml" 입력은 되지만, 블로그 정보를 가지고 올 수 없는 것으로 보입니다. 그리고 RSS피드 하나만 성공적으로 등록되어 있다면, 그것만으로도 충분하다고 합니다. 

Google Blog(Blogger) 설정에서 맞춤 로봇 헤더 태그 사용설정을 했습니다. 하부 세부 설정을 해야하는데, Gemini가 제시해준대로 하부설정을 하였습니다. 

Google Search Console, URL 검사를 통해서 '수동 색인 요청'을 해보려고 합니다. 

포스팅 주소를 입력 후, [색인 생성 요청] 클릭하면 됩니다. 3개 정도 신청하려고 합니다. 

Adsense 검토요청 다시 합니다. 

참고 : 초기 작은광고(배너) 단순 노출 1000회이면 약0.5달러 내외로 조사하였습니다. 방문자의 체류시간이 길어지면, 더 비싼 광고를 매칭해주어 수익이 상승할 수 있다고 합니다. 

[웹앱] SyncGo (Synchronize and Go)

SyncGo (Text 복사)

https://syncgo.microlabs.info/

컴퓨터로 작업하다가 스마트폰으로 긴 텍스트나 링크를 보내야 할 때, 보통 어떻게 하시나요?

보통 생각하는 것에 메일(자신에게 보내기), 카톡 등을 사용할 것입니다. 메일 로그인 하는 것, 카톡 사전 설치 등 좀 번거롭습니다. 

컴퓨터를 2~3대로 작업하는 경우, 간단한 설정내용, 코드, 라이선스 키 등을 빨리 복사해서 사용했으면 하는 경우가 간혹 있습니다. 컴퓨터와 스마트폰 간에도 텍스트를 쉽게 복사하고 싶을 때도 가끔 있습니다. 

SyncGo는 어떤 서비스?

 - 별도의 프로그램이 앱을 설치할 필요 없이, 웹브라우저만 있으면 컴퓨터-컴퓨터, 컴퓨터-스마트폰간에 텍스트를 간편절차로 복사/붙여넣기 할 수 있는 초간단 웹앱(Web Application) 입니다. 

주요 특징

 - 회원 가입 필요 없이 바로 사용가능 : 복잡한 가입절차 없이 웹사이트에서 접속해서 바로 사용

 - OS 제약 없음 : 인터넷만 연결되어면 사용가능

 - 프로그램 설치 필요없음 : 웹브라우저로 SyncGo주소로 접속, 즐겨찾기(북마크)로 등록

 

이럴 때 사용하면 정말 편해요!

 - 컴퓨터로 찾은 맛집 주소, 링크 

 - 인증번호, 계좌번호, 지갑주소 

 - 컴퓨터에서 작성한 긴 문장

 - 컴퓨터간에 코딩할 때, 일부코드 복사

 - LLM 답변 복사, 등

텍스트를 입력하고 [저장]버튼을 누르면 

접근코드, URL, QR Code(URL)

출력됩니다. 

접근코드(5자리)를 입력하면 

작성한 텍스트 내용을 보여줍니다.

텍스트를 입력할 때 설정한 유효시간이 지나면

자료는 삭제됩니다.

텍스트는 100KB 제한이 있습니다. 또한, 유효시간은 5~720분(5분~12시간)까지 설정할 수 있습니다. 기본값은 30분으로 설정하였습니다. 접근코드(AccessCode), URL, QR Code(URL)을 통해서 저장된 텍스트를 확인할 수 있도록 하였습니다. 

사용해 보시고 아쉬운 점이나 필요한 기능이 있다면 댓글로 남겨주세요. 

개발자노트 : 개발초기에 무의식적으로 SincGo문구로 적용해서, 막판에 SyncGo로 다 변경했습니다. 참고로, 파일복사기능도 고민하고 있습니다. 

#텍스트복사 #기기간텍스트전송 #생산성앱 #유용한사이트 #싱크고 #SyncGo