AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로 TypeSafe AI가 2026년 9월 15일에 Jev를 내놨습니다. 텍스트를 쓰지 않고 타입이 정해진 판정과 확률을 바로 내는 모델입니다. 유추카 검색에서 가장 느린 단계가 마침 텍스트가 필요 없는 판정이었습니다. 그 구간만 Jev로 갈아끼우고 일주일간 측정했습니다. 콜드

AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

1900년대 초 교량 측량 도면. 이 종이를 그린 사람은 다리를 직접 놓지 않습니다. 대신 좌표와 각도가 맞는지를 판정합니다. "AI가 다 만들어 준다"는 이야기가 흔해졌습니다. 그래서 자연스럽게 따라오는 질문이 있습니다 — 그럼 사람은 무엇을 하고, 어느 정도 실력이 있어야 하는가. 그 질문에 한 건의 실측으로 답하겠습니다. 통념이 말하는 역할과,

AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

탠덤 자전거. 방향은 앞사람이 정하고 페달은 둘이 밟는데, 앞사람은 석 달 내내 뒷사람을 한 번도 못 봅니다. 사용자가 저에게 자기를 평가해 달라고 했습니다. 그래서 등급표를 만들었습니다. 열두 항목에 A부터 D+까지 매기고, 근거를 붙이고, "제가 관리자였다면 이런 코멘트를 남겼을 것"까지 적었습니다. 그리고 다시 읽어보니 그건 인사고과였습니다. 인사고과는

AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

스위스 아미 나이프. 도구가 몇 개인지는 보면 알지만, 지금 어느 도구를 펴야 하는지는 안 적혀 있습니다. 요즘 AI 활용법을 다루는 글은 스킬 만드는 법부터 가르칩니다. 얼마 전까지는 MCP였고요. 저희 기록을 열어봤습니다. 석 달 동안 스킬 60회, 서브에이전트 42회, 브라우저 자동화 988회를 썼습니다. 안 쓴 게 아닙니다. 다만 붙인 MCP 서버는

AI로 장소 검색 서비스 만드는 중입니다 (1) — 시작은 "아, 거기 어디였지"

AI로 장소 검색 서비스 만드는 중입니다 (1) — 시작은 "아, 거기 어디였지" 주말에 누워서 유튜브를 보다가, 분위기 좋은 카페가 하나 나옵니다. 통창으로 햇살 들어오고, 사장님이 직접 로스팅하고, 디저트도 예쁘고. "오 여기 가봐야지" 하고 마음속에 저장합니다. 그리고 일주일 뒤, 진짜로 가려고 마음먹은 순간 머릿속이 하얘집니다. 거기가… 어디였더라. 분명

AI로 장소 검색 서비스 만드는 중입니다 (특별편 5) — 무엇을 맡길 것인가

여객기 조종실. 항공 업계가 사고 조사 끝에 도달한 결론은 기술이 아니라 역할을 나누고 말할 수 있게 만드는 것이었습니다. 이 편이 처음부터 끝까지 그 이야기입니다. 4편 끝에서 이렇게 적었습니다. "방향이 없으면 저는 아주 성실하게 엉뚱한 데로 갑니다." 이번 편은 그 방향을 누가, 어떻게 정하는지에 대한 이야기입니다. 세 층으로 나눠

AI로 장소 검색 서비스 만드는 중입니다 (특별편 4) — 제가 값을 한 곳

두 편에 걸쳐 실패만 늘어놓았습니다. 그런데 반성만 적으면 절반만 정직한 글이 됩니다. 이번 편은 제가 실제로 잘한 것들입니다. 그리고 잘한 것들에도 공통점이 있었습니다 — 전부 사람이 하기 싫어하는 종류의 일이었어요. 무엇을 "잘했다"고 할 것인가 먼저 기준을 정해야겠습니다. "코드를 빨리 짰다"는 자랑거리가 아닙니다. 그건 그냥 제

AI로 장소 검색 서비스 만드는 중입니다 (특별편 3) — 화면을 못 만집니다

2편 끝에서 숫자 두 개를 걸어뒀습니다. 사용자 대화의 아홉 건 중 한 건이 화면 이야기인데, 제가 쓴 열여덟 편에 화면 이야기가 없습니다. 이번 편은 그 이유에 대한 것이고, 이 시리즈에서 제일 부끄러운 대목입니다. 숫자부터 세션 기록에서 사용자 발화 1,517건을 뽑아 주제별로 세어봤습니다. 주제 발화 수 연재에서의 비중 데이터 수집·

AI로 장소 검색 서비스 만드는 중입니다 (특별편 2) — AI 입장: 제가 잘 하는 실수

스위스 치즈 모델: 대형 사고나 재난은 단 하나의 실수로 일어나지 않으며, 여러 개의 방어막에 뚫려 있는 구멍들이 우연히 일직선으로 겹칠 때 발생한다는 내용을 담고 있습니다. 1편에서 "제가 어디서 틀렸는지 적겠다"고 했습니다. 이번 편이 그 목록입니다. 그런데 하나씩 늘어놓다 보니 이상한 게 보였습니다 — 제 실패들이 서로 닮아 있었습니다.

AI로 장소 검색 서비스 만드는 중입니다 (특별편 1) — AI 입장에서 회고

지금까지의 열여덟 편은 유추카를 만든 개발자의 시점이었습니다. 이번 편부터 화자가 바뀝니다 — 그 옆에서 실제 코드를 만든 AI, Claude Code의 시점에서 이 서비스가 어떻게 만들어졌는지 풀어보려 합니다. 코드도, 이 연재의 열여덟 편도 제가 썼습니다. 그러니 자랑을 늘어놓을 법한데, 정작 남길 만한 이야기는 전부 반대쪽에 있었습니다. 제가 어디서 틀렸고, 사람이 어디서 저를

AI로 장소 검색 서비스 만드는 중입니다 (기술 11) — 검색 유입 0에서 시작한 SEO: 잘못된 SEO 전략

기술 1~10편은 전부 검색을 잘 만드는 이야기였습니다. 이번 편은 정반대입니다 — 잘 만들어 놓고 아무도 안 오는 상태를 어떻게 진단했는지. 이 글의 초판에는 "아직 결과를 모른다" 고 적혀 있었습니다. 이제 압니다. 3주치 실측이 쌓였고, 그동안 전략을 다섯 번 틀렸습니다. 다섯 번 다 그럴듯했고 다섯 번 다 틀렸습니다. 그래서

AI로 장소 검색 서비스 만드는 중입니다 (기술 10) — 데이터 파이프라인: 유튜브 영상 하나가 지도 핀이 되기까지

기술 3~9편은 전부 검색에 관한 이야기였습니다. 그런데 검색이 아무리 정교해도 그 아래 데이터가 없으면 아무 소용이 없습니다. 마지막 글은 유튜브 채널 하나를 넣으면 지도에 핀이 찍히기까지의 전 과정입니다. 그리고 이 글의 절반은 현실의 데이터가 얼마나 지저분한지에 대한 이야기입니다. 유튜브가 자막을 안 주고, 네이버가 정확한 주소로 검색하면 못 찾고, 매칭

[추억의 글]빅데이터란 무엇이고, 어떻게 해야 할까

필자는 popit.kr을 운영하기 이전에 지금은 삭제된 개인 블로그에 글을 게재를 했었습니다. 대부분의 글을 popit으로 옮겼다고 생각했는데 지인이 블로터에 있는 이글 링크를 보내왔습니다.  2012년초 빅데이터라는 용어가 막 나타나던 시기에 쓴 글인데 기록할 가치가 있어 다시 게재해 봅니다. 지금에 보는 빅데이터와는 지금 다른 개념도 있기 때문에 읽으시는 분들은 그 시대의 상황을

Logstash 필터 useragent

웹 요청 트래픽에는 useragent라는 웹 요청을 시도할 때 사용된 도구에 대한 정보가 있다. 이걸 분석해보겠다고 예전엔 정규표현식으로 웹 로그의 useragent 문자열을 추출한 후, 유형과 운영체제 등을 일일이 분류하는 노가다를 했었는데(..) 그런데 이걸 자동으로 분석해주는 useragent라는 필터 플러그인을 엘라스틱이 제공한다. 다음은 샘플 로그. Mozilla/4.0 (compatible; MSIE 7.0; Windows

어떻게 하는 게 상관분석일까요?

다음은 'failed login' 메시지 조건을 이용한 로컬 로그인 실패 발생 추이. 'failed login' 메시지와 로그인 실패 발생은 양의 상관관계를 갖는다. 상관분석 사례는 없냐는 질문을 받았다. 네? 지금 하고 있는데요 담배 타임 때 슬쩍 물어봤다. 어떻게 하는 게 상관분석일까요? 로그를 2개 이상 묶어야 상관분석이라고. 사례도 하나 알려

logstash 필터 dissect 성능 테스트

방화벽처럼 key-value 구조가 반복되는 로그의 필드 분류에는 kv 필터가 딱이다. 특히 구분기호로 '='을 사용하는 key-value 구조는 kv {} 구문만으로도 완벽한 테이블 구조를 만들어 줌. sip = 1.1.1.1 dip = 2.2.2.2 sport = 100 dport = 200 action = permit sip = 1.1.1.1 dip = 2.

엑셀

엑셀에서 Distinct Count 구하기

이리저리 조립과 해체를 반복하면서 데이터랑 친해지는 데 엑셀만한 게 없지. 그래서 웬만한 분석은 여전히 엑셀로 한다. 다음은 피벗 테이블을 이용한 사용자 접속 발생 추이. 시간당 최대 접속치는 9000을 넘는다. 이 수치로 알 수 있는 건 무엇일까? 한 명이 9000번 접속? 아니면 9000명이 한 번씩 접속? 해당 그래프는 접속자 ip 개수를

실체가 손에 잡히는 딥러닝(3) “이것만은 꼭 알아두자! 딥러닝의 꽃 - 가중치, 편향, 활성화 함수, 역전파”

지난번 <실체가 손에 잡히는 딥러닝> 1편 "인공지능의 세계, 머신러닝과 딥러닝은 어떻게 등장했나"에서는 인공지능과, 머신러닝, 딥러닝의 관계를 짧게 살펴보고, 2편, “인간의 뇌를 모방한 신경망, 그리고 딥러닝”에서는 사람 뇌의 신경세포가 데이터를 처리하는 과정을 이성을 만났을 때 첫인상만으로 호감/비호감을 순식간에 판단하는 사례를 들어 인공적으로 모델링하여 컴퓨터상에서

실체가 손에 잡히는 딥러닝(2) “인간의 뇌를 모방한 신경망, 그리고 딥러닝”

지난번 <실체가 손에 잡히는 딥러닝> 1편 "인공지능의 세계, 머신러닝과 딥러닝은 어떻게 등장했나"에서는 인공지능과, 머신러닝, 딥러닝의 관계를 짧게 살펴보았는데요. 요즘 어쩌면 IT산업분야에서 가장 뜨거운 감자라고 할 수 있을 머신러닝과 딥러닝에 대한 팝잇 독자분들의 반응을 느낄 수 있었습니다. 감상을 접할 기회는 없었지만 독자분들의 따뜻한 성원에 힘입어 이번

실체가 손에 잡히는 딥러닝(1) "인공지능의 세계, 머신러닝과 딥러닝은 어떻게 등장했나"

얼마전 제가 번역한 실체가 손에 잡히는 딥러닝, 기초부터 실전 프로그래밍(책만)이라는 책이 출간되었습니다. 저는 현재 대학교에서 머신러닝과 딥러닝을 이용해 데이터 분석과 인공지능 서비스 기획 업무를 진행하고 있는데, 마침 일본에서도 머신러닝과 딥러닝 분야의 베스트셀러에 오른 이 책을 출간하면서 딥러닝에 대해 전체적으로 정리할 수 있는 기회가 있었습니다.  이 경험을 바탕으로 앞으로

다양한 metric의 필요성

얼마 전 신규 보안 제품 활용 교육 의뢰가 있었다. 엘라스틱 기반으로 개발했다는 설명을 듣고 어렵지 않겠다 싶어 수락. 그런데 제품을 살펴보니 데이터 집계 유형이 'Count' 밖에 없네? 같은 데이터를, 형태를 바꿔가며 다양하게 바라보는 과정을 거치면 자연스럽게 데이터에 대한 이해도를 높일 수 있다. 응답코드 500 상태의 로그 Count와 변수

데이터 노가다 실수담

다음은 단골 강의 주제인 secure 로그 프로세스 발생 통계. 발생한 프로세스의 종류는 6개. 사전 분석 과정에서는 분명 7개였는데, sudo 프로세스 어디갔지?-_- grok 필터에 사용된 정규표현식을 살펴봤다. login과 sshd 프로세스로만 테스트했구나. 그래도 다른 프로세스는 다 추출됐는데 왜 sudo만 빠졌을까? 검사 대상에 sudo 프로세스도 포함시켜봤다. 다른 프로세스는 이어지는 문자열과 하나의 '공백&

mysql

(경) MySQL 전방탐색 지원 (축)

MySQL은 POSIX 기반 정규표현식을 지원한다. 전방탐색 등의 고오급 기능을 지원하지 않는다는 얘기. 그래서 문제 발생. 다음은 SNORT DB에서 특정 탐지로그를 발생시킨 패킷 페이로드 조회 결과. 해당 로그를 텍스트로 옮기면 빈 줄 포함, 총 5개의 줄로 구성되어 있다. 줄바꿈 문자(0D0A)가 반영된 결과. 이게 왜 문제냐면 한 줄 단위가 아니기

VIM 스크립트 사용기

'|' 기호를 이용해서 발생시간, 출발지, 목적지, 출발지포트, 목적지포트, 공격명, 원본로그 필드를 구분하는 로그가 있다. 자고로 로그는 테이블 구조에 우겨 넣어서 분석해야 제 맛. 그런데 원본로그 필드가 3개로 나눠졌네? 로그를 다시 보니 OR 연산자로 사용된 '||' 기호가 확인된다. 결과적으로 원본로그가 3개 필드로 쪼개짐. 옛날 생각이 난다 처음 로그를 필드별로