신청해요 "사장님, 노래가 듣고 싶어요." - 손님이 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

[웹앱] 희석용량, 희석배율 계산기

희석용량 계산기, 희석배율 계산기

https://lapp.microlabs.info/dilute

일상 속에서 또는 업무 중에 락스 소독액, 농약, 식물 액체비료(액비), 차량 디테일링 용품 등을 희석할 때마다 계산을 해야 했습니다. 

"물을 1L에 500배로 희석하려면 원액을 몇 mL 필요하지?"

"원액 3mL가 물에 섞었는데 혼합비율이 어떻게 되지?"

설치할 필요없이 희석용량 & 희석배율 계산기 웹앱을 사용하세요.  

 - 물의 양과 희석배수를 입력하면 사용량이 계산됩니다.

 - 물의 양과 물질 용량을 입력하면 혼합비율(희석배수)가 계산됩니다. 

희석의 목적
- 농도조절 : 용액의 농도를 조절하고 특정 농도의 용액을 얻기 위해 희석이 사용됩니다. 특정 실험이나 분석에서는 정확한 농도의 용액이 필요할 수 있습니다.
- 반응속도조절 : 어떤 화학 반응은 고농도에서 빠르게 일어나지만, 너무 높은 농도에서는 원하는 결과를 얻기 어려울 수 있습니다. 따라서 희석을 통해 반응 속도를 적절히 조절할 수 있습니다.
- 분석의 정확성 : 어떤 분석 기술에서는 정확한 결과를 얻기 위해 희석이 필요할 수 있습니다. 특히, 농도가 너무 높으면 측정이나 분석이 어려울 수 있습니다.
- 화학반응특성 : 몇 가지 화합물은 농도가 높을수록 더 복잡한 화학 반응을 일으킬 수 있습니다. 희석은 이러한 반응의 특성을 조절하고 예측할 수 있도록 도와줍니다.

개발자 노트 : 식물을 키우신다면, 눈대중으로 또는 대충 희석하지 말고, 정확하게 희석해서 식물에 적용하세요. 식물 비료/농약, 락스 희석(청소), 세차제품 등을 사용하다 보면 희석하는 경우가 많습니다. 

디자인도 아주 간단하게 만들었고, 애플리케이션 설치 없이 바로 웹브라우저에서 해당링크로 접속하면 희석계산기를 사용할 수 있습니다. 

Tag : #희석계산기 #희석배율 #희석용량 #웹앱

[기술조사] 아키텍쳐 & 다수의 프로세스간에 통신 방식

분산 프로세스 아키텍처에서 가장 철학적이고 실무적인 논쟁이 바로 통신방식입니다. 통신방식은 중앙 관리형 통신방식(Orchestration & Gateway), 분사형 통신 방식(Cherography & Message Broker) 정도로 확인하였습니다. 

프로세스를 여러 개로 분리를 시작하면, 가장 먼저 마주하는 거대한 벽이 "통신 복잡성"입니다. 다수의 프로세스가 직접 통신한다면 관리해야 항목(커넥션, URL)이 늘어납니다. 그래서 프로세스간 직접 통신방식은 많이 언급하지 않을려고 합니다. 

1. 중앙 관리형 통신방식(GateWay & Orchestration)

 - 중앙집권과 명령입니다. 각 프로세스는 스스로 판단하지 안혹, 오직 중앙의 지휘자가 내리는 명령에 따라서면 움직입니다.  요청->대기->응답 과정을 거치는 것입니다. 

 - 비지니스 로직과 흐름이 한눈에 보임, 중앙 관리 프로세스가 병목이 될 수 있음 

2. 분산형 통신방식(Choreography & Message Broker)

 - 지방자치와 이벤트입니다. 중앙의 통제관이 없으며, 각 프로세스는 시스템이 발생한 "사건"을 듣고 로직을 수행합니다. 

 - 시스템 확장(프로세스 추가)이 자유로움, 흐름이 사방으로 진행되어 모니터링이 어려움 

 - RabbitMQ, Kafka, Redis Pub/Sub 

중앙 관리형 통신방식이든 분산형 통신방식이든 해당 프로세스가 문제가 발생하면, 전체 시스템이 마비되는 것은 동일합니다. 이런 것을 피하려면 프로세스간에 직접 통신방식으로 해야 해야 하는데, 프로세스가 늘어날 수록 관리가 상당히 어렵습니다. 

중앙 관리형 통신방식(GateWay & Orchestration), 분산형 통신방식(Choreography & Message Broker) 모두 해당 프로세스가 죽으면 마비되는 것은 동일합니다. 장애 발생했을 때 '데이터 유실'과 '인프라 수준에서 이 문제를 어떻게 극복(복구)' 관점에서 분류된 것으로 보입니다. 

1. 데이터 영속성 관점 (메시지 보관 창고 유무)

 - 수동 중앙 관리 프로세스 : 중앙 관리 프로세스가 장애 시, A프로세스가 B 프로세스로 요청을 보내면, 프로세스 연결자체가 실패하면서 에러 발생하고, A 프로세스가 메시지를 저장하지 않았다면 유실됩니다.

 - 메시지 브로커 : 메시지 브로커는 단순한 통로가 아니고, '디스크 보관 기능이 있는 메모리 창고' 개념입니다. 프로세스 2,3 모두 죽어있더라도 메시지 브로커만 살아있다면 메시지를 큐(Queue)에 안전하게 쌓아두고, 프로세스 2,3 실행되면 밀려있던 메시지를 순서대로 처리할 수 있습니다. 

2. 고가용성과 클러스터링의 난이도

 - (직접 구현한) 중앙 관리 프로세스 : 비즈니스 로직, 세션 상태, 흐름 제어 코드등이 포함되어 있고, 변화가 있을 때 개발자가 직접 코드로 다 구현해야 합니다. 

 - 전문 메시지 브로커(RabbitMQ, Kafka 등) : 전세계 천재 개발자들이 만든 전문 인프로 소프트웨어이고, "우리는 절대로 죽으면 안 된다" 목표로 제작된 것입니다. 

3. 시스템의 결함도와 부하 분산

 - 중앙 관리 프로세스 : 프로세스들이 중앙 관리자에 철저히 종속됩니다. 

 - 메시지 브로커 : 예를 들어서, A프로세스는 브로커에 메시지르 초당 10,000개씩 던지고 자기 할 일을 하러 갑니다. 브러커 뒤에는 B 프로세스의 성능이 부족해 초당 1000 만 처리하더라도, 시스테밍 터지지 않고 브로커 큐에 안전하게 저장됩니다.(Buffer, Load Balacing) 

처음부터 메시지 브로커를 도입하면 인프라 관리 비용이 들기 때문에, 시스템 초기에는 단순한 중앙 관리자로 시작하고, "절대 데이터 유실되면 안 된다"거나 "특정 구간에 트래픽이 몰려 서버가 버티지 못한다"는 신호가 올 때 RabbitMQ나 Kafka 같은 브로커 도입을 검토하는 것이 가장 현실적인 개발 방향입니다. 

개발 초기에는 데이터 유실까지 고려하지 않고 메시지 전달만 잘 되도록 중앙 관리자를 만들면서 전문SW(메시지 브로커) 적용을 고민해보는 것도 좋을 것 같습니다. 전문 SW가 오픈소스를 사용한다고 해도, 사용능력도 향상시키거나, 해당인력이 배정하거나 해야할 것 같네요. 

[Code] 모듈러 모놀리딕(Modular Monolithic) + 프로세스 분리 & Python 예제 #2

모듈러 모놀리딕(Modular Monolithic) + 프로세스 분리 & Python 예제 #2

모듈러 모놀리딕으로 개발하다가, 특정모듈을 분리하려고 합니다. 여기서 분리는 프로세스(실행파일)을 독립적으로 분리하려고 합니다. 분리하려는 이유는 여러가지를 가정할 수 있을 것 같습니다. 

초기 개발할 때는 모듈러 모놀리딕으로 진행하다가 MacroService 또는 Citadel 아키텍처로 변환이 되는 시작점이 되는 것으로 보입니다. 개발 초기부터 MSA로 시작할 필요가 없다고 생각하고, 또한 MSA가 최종 목표도 아닙니다. 

아키텍처 전환 시, 발생하는 변화가 있습니다. (쉽게 표현하면, 프로세스가 나누어지면)

통신방식의 변환이 필요한 것입니다. In-Memory -> IPC/Network로 변경해야 하고, 코드가 더 들어갑니다. 

다시 말해서, 노출된 함수를 직접 호출하는 방식이 아닌, IPC 또는 Network로 통신을 해야 합니다. 

main_app            # [프로세스 1]

 - main.py

 - cli.py

 - feature_a.py

 - feature_b.py   # 로직수행하지 않음. 프로세스2로 요청을 보내는 대리인 역할

service_b            # [프로세스 2]

 - service_b.py    # 자체 웹 서버를 탑재한 B 기능 실행 파일

1. [프로세스 1] main.py | cli.py | feature_a.py (변경없음)

  - https://www.microlabs.info/2026/07/code-modular-monolithic-python-1.html 

2. [프로세스 1] feature_b.py 

기존 비즈니스 로직 코드는 삭제되고, 독립된 B 프로세스 웹 서버로  HTTP POST 요청을 보내는 코드로 대체합니다. 

# main_app/feature_b.py

import requests

# 독립 실행된 B 프로세스의 REST API 주소

B_SERVICE_URL = "http://127.0.0.1:8000/execute"

def run(input_value: str) -> str:

    print(" [네트워크] 독립된 B 프로세스로 REST API 요청 전송 중...")

    

    # REST API에 보낼 JSON 데이터 구성

    payload = {"text": input_value}

    

    try:

        # B 프로세스 서버로 POST 요청 발송 (타임아웃 3초 설정)

        response = requests.post(B_SERVICE_URL, json=payload, timeout=3)

        

        if response.status_code == 200:

            data = response.json()

            return data.get("result", "응답 데이터 누락")

        else:

            return f" B 서비스 오류 (HTTP {response.status_code})"

            

    except requests.exceptions.ConnectionError:

        # B 프로세스가 죽어있어도 메인 시스템은 크래시 나지 않고 결함이 격리됨

        return "B 서비스 프로세스에 연결할 수 없습니다. (서버가 꺼져있음)"

3. [프로세스 2] service_b.py (분리된 독립 B 서비스 코드)

프로세스1과 완전히 별개로 실행되는 가벼운 웹 서버입니다. 기존 B기능의 비지니스 로직이 이관된 것입니다. (사전에 pip install fastapi uvicorn 설치 필요) FastAPI 사용

# service_b/service_b.py

from fastapi import FastAPI

from pydantic import BaseModel

import uvicorn

app = FastAPI(title="독립된 B 기능 매크로서비스")

# 요청 데이터 구조 정의 (DTO)

class RequestData(BaseModel):

    text: str

def _pure_business_logic(data: str) -> str:

    """기존 b.py에 있던 핵심 비즈니스 로직"""

    return data[::-1]

@app.post("/execute")

def handle_b_feature(data: RequestData):

    """메인 프로세스로부터 REST API 요청을 받는 엔드포인트"""

    print(f"[B 프로세스 수신] 요청 데이터: '{data.text}'")

    

    # 비즈니스 로직 수행

    processed_text = _pure_business_logic(data.text)

    

    # JSON 형태로 응답 반환

    return {

        "status": "success",

        "result": f"[B 원격 프로세스 완료] 뒤집힌 결과 -> {processed_text}"

    }

if __name__ == "__main__":

    print("B 기능 독립 프로세스 서버를 시작합니다 (Port: 8000)...")

    # 8000번 포트에서 독립된 웹 서버 프로세스로 가동

    uvicorn.run(app, host="127.0.0.1", port=8000)

2개 실행파일을 모두 실행해야 합니다. 2개의 프로세스이므로 터미널에 두개 열어서 각각 실행합니다. 

 - python service_b.py

 - python main.py

추가 고려사항

 - 프로세스간에 통신하는 방식은 여러가지가 있지만, 여기서는 REST를 사용한 것입니다. 다른 방식으로 선정했다면, 그에 맞는 코드로 적용하면 됩니다. 

 - B기능이 자원(CPU, Memory)를 많이 소모하는 경우, B 실행파일만 별도의 고성능 서버에 실행할 수 있습니다. 코드에서 IP, Port만 변경해주면 됩니다. 

 - B기능이 자주 변경되어 배포해야하는 것은 메인 프로세스를 중단하지 않고 B 모듈/서비스만 배포하여 실행할 수 있습니다. (반대의 경우도 동일함)

 - B기능에 문제가 발생하면(메모리 누수로 인한 비정상 종료), 메인 프로세스에 영향이 거의 없습니다. 

Step #1 : 모든 코드가 하나의 큰 프로세스 내부에 있으며, In-Memory 함수 호출로 통신함

Step #2 : 메인 프로세스는 핵심기능(A)를 유지하고, 분리된 독립 B 서비스가 독립적으로 존재. 메인 프로세스 내부의 Feature_b.py는 로직수행이 아닌 REST 클라이언트가 되어 원격으로 독립 B 서비스를 REST API요청을 보냅니다.