[기술조사] 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가 오픈소스를 사용한다고 해도, 사용능력도 향상시키거나, 해당인력이 배정하거나 해야할 것 같네요.