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

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

MySQL은 POSIX 기반 정규표현식을 지원한다. 전방탐색 등의 고오급 기능을 지원하지 않는다는 얘기. 그래서 문제 발생. 다음은 SNORT DB에서 특정 탐지로그를 발생시킨 패킷 페이로드 조회 결과.

1

해당 로그를 텍스트로 옮기면 빈 줄 포함, 총 5개의 줄로 구성되어 있다.

2

줄바꿈 문자(0D0A)가 반영된 결과.

3

이게 왜 문제냐면 한 줄 단위가 아니기 때문에 테이블 구조로 바꾸기가 너무 빡셈. 대충 이런 식의 작업이 가능해야 하는데,

4

요 모양이 됨. 하나의 레코드에 들어가야 할 로그가 여러 레코드로 쪼개지면서 필드 고유성은 개나 줘버린, 망한 데이터베이스.

5

일일이 수작업으로 정리해야 하나? 그렇게 정성 들여봐야 IDS 로그 누가 본다고(..) 제일 쉬운 방법은 줄바꿈 문자를 없애는 것. 다음은 replace 함수를 이용해서 줄바꿈 문자(0D0A)를 공백 문자(20)로 바꾼 결과. 줄바꿈 문자가 없으니 당연히 한 줄로 표시된다.

6

이쯤에서 또 문제 발생

웹 트래픽에서 헤더 영역은 '0D0A'로 줄 구분을 하는데, 데이터 영역에서는 '0A'도 줄바꿈 문자로 동작한다. 다음은 웹 응답 트래픽의 줄바꿈 문자를 공백 문자로 바꾼 결과.

7

텍스트로 옮기면 여전히 줄 구분이 존재한다. 또 다른 줄바꿈 문자 '0A'가 남아있기 때문.

8

그래서 replace 함수를 한번 더 사용해서 줄바꿈 문자 '0A'도 공백 문자로 변경.

9

잘 된다 싶었는데 자세히 보니 데이터가 원본과 다르다.

10

원인은 줄바꿈 문자가 아닌 '0A'도 바뀌었기 때문. 16진수 문자는 2개의 문자가 하나의 의미를 이루기 때문에 2개 단위로 검사해야 한다. 그런데 '0A' 문자를 무조건 바꾸다 보니 마지막 16진수 문자 '40', 'A6'이 '42', '06'으로 바뀐 것.

11

연속되는 16진수 '0D0A'는 희소성이 커서 문자가 나열되는 과정에서 우연의 일치가 발생할 가능성이 낮지만, '0A'는 그렇지 않다는 얘기.

이런 상황을 막으려면?

전방탐색 정규표현식을 쓰면 된다. 다음 전방탐색 표현식 '(?=(..)*$)'는 짝수 단위의 문자열이 이어지거나, 아예 이어지는 문자열이 없는 '0D0A' 또는 '0A'만을 검사한다.

12

그런데 이미 얘기했지만 MySQL 정규표현식은 전방탐색을 지원하지 않는다(..) 다행히 정규표현식 지원을 확장시켜주는 lib_mysqludf_preg라는 라이브러리가 있어서, 추가로 설치하면 전방탐색 사용이 가능하긴 함.

13

그런데 이게 문자열이 좀 길어지면 잘 안 될 때가 있더라. 그래서 잘 안 썼는데 최근 MySQL 8.0에서 정규표현식 지원이 강화됐다는 소식이 들려음.

신난다

신나게 테스트.

15

오류는 없는지 좀 더 써봐야 알겠지만 일단 만족스럽다. MariaDB로 넘어오라는 스택오버플로 형님들 꼬임에도 꿋꿋이 버틴 보람이 있는 듯. 참고로 윈도우 버전만 테스트해본 결과 8.0.12 버전부터 해당 기능을 사용할 수 있는 듯하다.

Read more

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

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

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

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

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

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

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

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

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

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

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

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

By 김형준