분석 기간: 2026년 2월 1일 — 2026년 3월 31일 (56일)
서버: @rabqatab/lexlink-ko-mcp on kakao PlayMCP, smithery.ai, run.tools
작성일: 2026년 4월 19일 (2, 3월 분석 치고는 조금 늦은..)
요약
이전 리포트(2025.11-2026.1)에서 20,555건의 로그 중 대부분이 initialize 에러였고, 식별된 사용자가 2명뿐이었다. "운영은.. 지옥이다.."로 끝났던 그 리포트의 후속편이다.
2월은 AWS에서 GCP로의 인프라 이전이 진행된 과도기였고, 3월은 PlayMCP 기반 프로덕션 런칭 이후 첫 번째 온전한 운영 월이었다. 두 달간의 핵심 수치:
| 지표 | 1월 | 2월 | 3월 | 2→3월 변화 |
|---|---|---|---|---|
| 도구 호출 수 | 471 | 762 | 3,070 | +303% |
| 도구 호출 세션 | 436 | 132 | 1,132 | +758% |
| 고유 클라이언트 | 5 | ~6 | 12 | +100% |
| 도구 성공률 | ~99% | ~98% | 99.6% | 개선 |
| 주요 클라이언트 | cursor | node | Mozilla (42%) | PlayMCP 시대 개막(짝짝짝) |
주요 발견사항
- 3월 16일, 최고 기록 달성 — 일일 565건의 순수 유기적(organic) 도구 호출. 봇 없이.
- 사용자 생태계 폭발 — cursor 독점 → Mozilla(PlayMCP), Go-http-client, openai-mcp, goose 등 12종 클라이언트
- 개인정보보호법이 왕좌 탈환 — 2월의 부동산/도시계획 주제를 밀어내고, 프라이버시/핀테크/AI 규제가 3월 지배
- 첫 봇 사건 — 3월 5일, 단일 IP에서 "민법" 605회 폭격 (너 대체 누구냐..)
- GCP 이전 성공 — 2월 27일 시작, 3월 2일 완료. 4일간 데이터 갭 발생
서버 개요 (변경사항)
이전 리포트 이후 달라진 점:
| 항목 | 이전 (v1.2.x) | 현재 (v1.5.x+) |
|---|---|---|
| 인프라 | AWS EC2 | GCP VM |
| 배포 플랫폼 | Smithery.ai 단독 (+간헐적인 PlayMCP 배포) | PlayMCP (Kakao) + Smithery.ai + run.tools(이건 smithery와 연결되어 있음) |
| 로그 포맷 | raw HTTP | JSON (구조화) |
| 도구 수 | 26개 | 26개 (동일, 4월에 50+개로 대대적인 업데이트 이썽ㅆ음..) |
| OC key | optional | 여전히 optional (얘기는 하고 있음..) |
1. 2월: 과도기의 달
1.1 트래픽 개요
기간: 2026-02-01 ~ 2026-02-26 (26일)
로그 수: 3,708건
도구 호출: 762건 (1월 대비 +61.8%)
데이터 갭: 2월 27-28일 — GCP 이전 진행 중, 데이터 없음2월은 AWS 시대의 마지막 달이자, 첫 유기적 사용이 관측된 달이다. Smithery.ai(5,133건)가 메인 채널이었고, run.tools가 2월 13일에 등장(1,078건)하며 두 번째 마켓플레이스(실상은 smithery와 연결된 것임)가 되었다.
1.2 클라이언트 분포
| 클라이언트 | 요청 수 | 비율 | 비고 |
|---|---|---|---|
| node | 405 | 53.1% | Node.js MCP 클라이언트 |
| python-httpx/0.28.1 | 298 | 39.1% | Python SDK |
| Claude-User | 30 | 3.9% | Anthropic Claude |
| openai-mcp | 14 | 1.8% | ChatGPT 첫 등장 |
| okhttp | 11 | 1.4% | Android/JVM |
| Mozilla | 4 | 0.5% | 웹 브라우저 첫 등장 |
이전 리포트에서 cursor가 90%였던 것에서, node + python-httpx 중심으로 전환. openai-mcp가 처음 나타났다는 건, ChatGPT 사용자가 MCP를 통해 LexLink에 접근하기 시작했다는 뜻이다. 그리고 Mozilla가 4건. 이 4건이 3월에 42%가 될 줄은 이때 몰랐다.
1.3 검색어 주제: 부동산의 달
| 검색어 | 건수 | 분야 |
|---|---|---|
| 주택법 | 18 | 부동산 |
| 국토의 계획 및 이용에 관한 법률 | 18 | 도시계획 |
| 주택법 시행령 | 15 | 부동산 |
| 건축법 | 12 | 건축 |
| 도시개발법 | 11 | 도시개발 |
| 도로교통법 | 8 | 교통 |
| 도시 및 주거환경정비법 | 8 | 도시정비 |
| 민법 | 7 | 민사 |
| 국민연금법 | 7 | 연금 |
상위 10개 중 6개가 부동산/도시계획 관련이다. 누군가(혹은 어떤 팀)가 부동산 규제를 체계적으로 조사한 흔적. 단일 세션에서 335건의 도구를 호출한 부동산 규제 조사 세션이 발견되었는데, 이는 역대 최다 단일 세션 기록이었다.
1.4 세션 분석
전체 세션 ─────────────────────► 743 (100%)
│
▼
도구 호출 세션 ────────────────► 132 (17.8%)
│
▼
다중 도구 사용 (2+) ──────────► 13 (9.8%) ← 1월 1.1%에서 급증
│
▼
심층 연구 (5+) ────────────────► 10 (7.6%)1월의 다중 도구 사용률이 1.1%였던 것에서 9.8%로 도약. 도구를 쓰는 세션이 더 깊어지고 있다.
1.5 2월의 이야기: 335건의 부동산 세션
세션 df01c5b1 — 335건의 도구 호출. law_search, admrul_service, aiSearch, eflaw_service, eflaw_josub를 모두 사용.
- 한국표준산업분류 부동산
- 주택도시기금법
- 건축법 시행령
법률 전문가 혹은 컴플라이언스 팀이 주택, 건축, 도시기금 규제를 체계적으로 조사한 것으로 보인다. 335건이면... 개인정보보호법을 303번 검색했던 이전 기간의 검색 봇과는 다르다. 이건 진짜 연구이지 않을까?
1.6 귀신 도구 (Ghost Tools)
LLM이 존재하지 않는 도구 이름으로 호출을 시도한 건이 발견됨:
| 귀신 도구 | 건수 | 추정 원인 |
|---|---|---|
| google_search | 4 | LLM hallucination |
| googleSearch | 2 | LLM hallucination |
| search_law | 1 | LLM hallucination |
LLM이 tool registry를 참조하지 않고 자기가 아는 이름으로 호출한 것. 이건 LexLink의 문제가 아니라 MCP 클라이언트 쪽의 문제인데.. 사용자 입장에서는 조용히 실패하니까 답답할 수 있겠다.
2. 3월: 런칭의 달
2.1 트래픽 개요
기간: 2026-03-02 ~ 2026-03-31 (30일)
로그 수: 25,840건
도구 호출: 3,070건
세션: 5,351개
일 평균: 도구 호출 102건, 세션 178개3월은 숫자로 말한다. 2월 대비 도구 호출 +303%, 세션 +758%. GCP 이전이 3월 2일 완료되면서, 처음으로 안정적인 인프라 위에서 운영.
2.2 트래픽의 5단계
3월 트래픽은 5개 국면으로 나뉜다:
기간 도구 호출/일 상태
───────────────────────────────────────────────────────────
Mar 2-4 9→42 런칭 램프업 (GCP 첫 날)
Mar 5 615 ★ 봇 스파이크: 민법 x605
Mar 6-9 23-47 안정화 (봇 이후 실제 베이스라인)
Mar 11-18 151-565 ★★ 유기적 성장 물결 (프라이버시, 핀테크)
Mar 19-31 0-85 포스트-피크 정상 상태3월 16일(일요일)에 565건을 기록하며 LexLink 역사상 최고 유기적 일일 트래픽 달성. 일요일이라는 게 재밌는데, KST 기준 일요일은 미국 토요일이라 해외 사용자의 영향으로 추정된다.
2.3 봇 사건: 민법 605회
3월 5일. IP 222.99.61.80에서 python-httpx를 통해 eflaw_search("민법") 605회 연타.
- 같은 IP, 같은 쿼리, 같은 user-agent
- 우회 시도 전혀 없음 (솔직한 봇?)
- IP+쿼리 기반 rate limiting이면 사실 쉽게 잡힘
- 3월 전체 "민법" 쿼리 627건 중 605건이 이 봇
봇이 악의적이었는지는 모르겠지만, 뭘 하려 했는지도 모르겠다. 민법 전문이 필요했으면 1번만 호출하면 되는데 605번이라니... 아마도 스크래퍼 테스트 하다가 for loop을 제대로 안 짠 것 같다ㅋㅋ
2.4 Cursor 에러 폭풍
3월 12-13일. Cursor 클라이언트가 resources/subscribe를 420번 호출.
LexLink는 이 엔드포인트를 지원하지 않는다. Cursor가 MCP resource subscription을 시도한 건데, 이건 Cursor 쪽 프로토콜 불일치 문제다. 도구 호출에는 영향 없었지만, 로그가 오염됨. smithery 이어서 cursor도 똑바로 일 안 하니?
3. 도구 사용 분석 (3월 기준)
3.1 도구별 사용빈도
| 순위 | 도구 | 호출 수 | 비율 | 카테고리 |
|---|---|---|---|---|
| 1 | eflaw_search | 1,104 | 36.0% | Phase 1: 현행법령 검색 |
| 2 | aiSearch | 622 | 20.3% | Phase 5: AI 검색 |
| 3 | eflaw_josub | 397 | 12.9% | Phase 1: 조문 조회 |
| 4 | prec_search | 178 | 5.8% | Phase 3: 판례 검색 |
| 5 | eflaw_service | 169 | 5.5% | Phase 1: 법령 전문 |
| 6 | article_citation | 96 | 3.1% | Phase 4: 인용조문 |
| 7 | admrul_search | 91 | 3.0% | Phase 2: 행정규칙 |
| 8 | prec_service | 74 | 2.4% | Phase 3: 판례 상세 |
| 9 | elaw_search | 61 | 2.0% | Phase 2: 영문법령 |
| 10 | expc_search | 46 | 1.5% | Phase 3: 법령해석례 |
| 기타 (16개 도구) | 232 | 7.5% | 2-43건씩 | |
| 전체 | 3,070 | 100% |
이전 리포트에서 모든 도구가 균등하게 10-31건씩 호출됐던 것(= 테스트)과 비교하면, 극명한 파워-로 분포가 나타남. eflaw_search가 36%로 압도적이고, 그 뒤를 aiSearch(20%)가 따른다. 이건 유기적 사용의 전형적 지표다.
3.2 검색 진입 전략
세션의 첫 번째 도구 호출이 뭐냐가 중요하다:
| 진입 도구 | 세션 수 | 비율 |
|---|---|---|
| eflaw_search | 807 | 77% |
| aiSearch | 161 | 15% |
| elaw_search | 23 | 2% |
| prec_search | 22 | 2% |
| law_search | 18 | 2% |
| admrul_search | 9 | 1% |
77%가 eflaw_search로 시작한다. 대부분의 사용자(혹은 그들의 LLM 에이전트)는 이미 찾으려는 법의 이름을 알고 있다는 뜻이다. aiSearch는 15%로, 탐색적 질문에 사용되는 보조 수단.
이전 리포트에서 1월 기준 aiSearch가 28%로 제일 높았는데(= 테스트), 실제 유기적 사용에서는 법령명 직접 검색이 압도적이다. LLM이 "개인정보보호법 찾아줘"라고 하면 eflaw_search("개인정보보호법")을 바로 때리지, aiSearch("개인정보 관련 법률 찾아줘")로 돌아가지 않는다는 것.
3.3 도구 체인 전환
사용자들이 도구를 어떤 순서로 사용하는지:
전환 패턴 건수 의미
─────────────────────────────────────────────────────
aiSearch → aiSearch 238 반복 정제 (검색어 다듬기)
eflaw_josub → eflaw_josub 178 연속 조문 읽기
eflaw_search → eflaw_search 152 검색 확장
eflaw_search → aiSearch 115 구조화 검색 → AI 검색 전환
prec_search → prec_search 85 판례 탐색
aiSearch → eflaw_josub 76 ★ AI 검색 → 조문 drill-down
aiSearch → eflaw_search 75 AI 검색 → 법령명 검색
article_citation → article_citation 32 인용 체인 추적
prec_search → prec_service 32 판례 찾기 → 판례 읽기핵심 패턴:
- 자기-루프가 지배적 — 대부분의 도구에서 가장 흔한 전환은 같은 도구 재호출 (검색어를 바꿔가며 반복)
- AI→조문 파이프라인 검증됨 —
aiSearch → eflaw_josub(76건): AI로 개념 찾고, 구체적 조문으로 drill-down - 양방향 검색 전환 — 사용자들이
eflaw_search와aiSearch사이를 자유롭게 오감 - 판례 워크플로우 확립 —
prec_search → prec_service(32건): 판례 찾고 → 읽기
3.4 aiSearch vs eflaw_search 중복
두 도구에 동일 쿼리가 사용된 건 20건뿐:
- aiSearch 고유 쿼리: 558개
- eflaw_search 고유 쿼리: 216개
- 중복: 20개
두 검색 모드가 실제로 다른 용도로 쓰이고 있다는 증거다. aiSearch는 "개인정보 유출 신고 절차" 같은 자연어, eflaw_search는 "개인정보보호법" 같은 법령명 직접 검색. 중복이 발생할 때는 대개 AI 검색을 먼저 시도하고, 정확도가 불만족스러워서 직접 검색으로 전환한 경우.
4. 클라이언트 생태계
4.1 3월 클라이언트 분포
| 클라이언트 | 도구 호출 | 비율 | 특징 |
|---|---|---|---|
| Mozilla | 1,298 | 42.3% | PlayMCP 웹 인터페이스 |
| python-httpx | 767 | 25.0% | 봇 605건 포함 |
| Go-http-client | 595 | 19.4% | 프로그래밍 자동화 |
| Claude-User | 233 | 7.6% | Claude.ai MCP |
| okhttp | 77 | 2.5% | 모바일/Android |
| goose | 34 | 1.1% | AI 에이전트 프레임워크 |
| claude-code | 29 | 0.9% | Claude Code CLI |
| openai-mcp | 20 | 0.7% | ChatGPT MCP |
| curl | 9 | 0.3% | 수동 테스트 |
| Cursor | 2 | 0.1% | IDE |
이전 리포트에서 클라이언트 분포는 이랬다:
이전 리포트: (빈 값) 65.5% → mcp 33.9% → smithery-host 0.2%
2월: node 53.1% → python-httpx 39.1% → Claude-User 3.9%
3월: Mozilla 42.3% → python-httpx 25.0% → Go-http-client 19.4%3개월 만에 완전히 다른 사용자 기반이 됐다. 가장 의미 있는 변화는 Mozilla가 42%를 차지한다는 것. LexLink가 더 이상 API-only 서비스가 아니다. 일반 사용자가 웹 인터페이스를 통해 들어오고 있다.
4.2 신규 클라이언트
| 클라이언트 | 첫 등장 | 의미 |
|---|---|---|
| Mozilla | 3월 2일 | PlayMCP 웹 → 지배적 클라이언트 |
| Go-http-client | 3월 2일 | 프로그래밍 자동화 통합 |
| goose | 3월 중순 | AI 에이전트 프레임워크 채택 |
| openai-mcp | 3월 4일 | ChatGPT MCP 브릿지 |
Go-http-client(595건, 19%)가 특히 의미 있다. 이건 사람이 직접 쓰는 게 아니라 자동화 시스템에서 LexLink를 호출한다는 뜻이다. 3월 18일의 핀테크 deep dive 세션에서 집중적으로 관측됨. LexLink가 프로덕션 워크플로우에 임베딩되기 시작했다.
5. 검색어 분석
5.1 3월 상위 검색어 (봇 제외)
| 순위 | 검색어 | 건수 | 분야 |
|---|---|---|---|
| 1 | 개인정보 보호법 | 44 | 개인정보 |
| 2 | 근로기준법 | 29 | 노동 |
| 3 | 자본시장과 금융투자업에 관한 법률 | 26 | 금융 |
| 4 | 자동차관리법 | 24 | 교통 |
| 5 | 개인정보보호법 | 20 | 개인정보 |
| 6 | 뺑소니 처벌 | 17 | 형사 |
| 7 | 환경정책기본법 | 15 | 환경 |
| 8 | 전자금융거래법 | 14 | 핀테크 |
| 9 | 건축법 | 14 | 건축 |
| 10 | 정보통신망 이용촉진 및 정보보호 등에 관한 법률 | 13 | ICT |
| 11 | 뺑소니 | 11 | 형사 |
| 12 | 인공지능 | 8 | AI |
| 13 | 내부자거래 | 8 | 증권 |
| 14 | 개인정보 유출 신고 | 8 | 개인정보 |
| 15 | 의료법 | 7 | 의료 |
고유 쿼리 수: 1,098개
5.2 주제 클러스터링
이전 리포트에서 개인정보보호법(1,100건 이상)과 환경법(700건 이상)이 양대 주제였다.
2월-3월은 다른 양상이다:
2월: 부동산/도시계획의 달
주택법 (18) + 주택법 시행령 (15) ─── 주거
국토의 계획 및 이용에 관한 법률 (18) ── 국토
건축법 (12) ─────────────────────── 건축
도시개발법 (11) ─────────────────── 도시
도시 및 주거환경정비법 (8+5) ────── 정비3월: 프라이버시/핀테크/AI의 달
개인정보 보호법 계열 (44+20+8+7) ── 79건 프라이버시 ★
자본시장법 계열 (26+6) ────────── 32건 금융
전자금융거래법 (14) ───────────── 14건 핀테크
정보통신망법 (13) + 인공지능 (8) ─ 21건 ICT/AI
근로기준법 (29) + 퇴직금 관련 ──── 29건+ 노동한 달 사이에 부동산 → 프라이버시/핀테크로 완전히 전환됐다. 개인정보보호법이 이전 리포트에서의 왕좌를 탈환한 셈인데, 이번에는 단독이 아니라 핀테크·AI·ICT와 클러스터를 이루고 있다. 이건 4개의 별개 트렌드가 아니라 하나의 연결된 규제 파도다: AI 제품 만들려면 개인정보보호법, 핀테크 회사는 데이터 보호, 헬스케어 플랫폼은 의료법+개인정보 프레임워크가 필요하다.
5.3 도메인 교차 네트워크 (3월)
한 세션 내에서 여러 법 분야를 넘나든 경우:
| 도메인 조합 | 세션 수 | 해석 |
|---|---|---|
| 데이터 + 개인정보(PIPA) | 19 | 데이터 거버넌스 |
| ICT + 개인정보(PIPA) | 16 | 플랫폼 컴플라이언스 |
| 핀테크 + 개인정보(PIPA) | 10 | 금융 데이터 보호 |
| 데이터 + 핀테크 | 10 | 오픈뱅킹 / 데이터 이동성 |
| 의료 + 개인정보 | 9 | 의료 데이터 규제 |
| 의료 + 원격의료 | 6 | 디지털 헬스 |
| 가중처벌 + 뺑소니 | 6 | 형사 양형 |
| 디지털 치료제 + 의료 | 6 | DTx 규제 |
프라이버시의 넥서스: 개인정보보호법(PIPA)이 거의 모든 도메인과 교차한다. 사용자들이 개인정보를 단독으로 연구하는 게 아니라, 각 산업 규제와 조합해서 연구하고 있다. 이건 한국 규제 환경의 현실을 반영한다 — 개인정보보호법은 모든 곳에 닿아 있다.
5.4 이전 리포트와의 비교
| 분류 | 이전(11-1월) | 2월 | 3월 |
|---|---|---|---|
| 개인정보 | 1,159건 (20.4%) | 5건 | 79건 ★ |
| 환경법 | 977건 (17.2%) | 4건 | 15건 |
| 부동산/건축 | 316건 (5.6%) | Top | 14건 |
| 민법 | 246건 (4.3%) | 7건 | 봇 605건 😂 |
| 핀테크/자본시장 | 거의 없음 | 없음 | 54건 ★ |
| AI/ICT | 거의 없음 | 없음 | 21건 ★ |
이전 리포트에서 환경법이 17%로 2위였는데, 2-3월에는 거의 사라졌다. 부동산도 2월에 반짝 1위 했다가 3월에는 후퇴. 개인정보는 꾸준한 관심사인데, 3월에는 핀테크/AI와 결합하면서 더 복합적인 형태로 나타남.
6. 세션 분석
6.1 세션 퍼널 (3월)
전체 세션 ─────────────────────► 5,351 (100%)
│
▼
도구 호출 도달 ────────────────► 1,132 (21.2%)
│
▼
다중 도구 사용 (2+) ──────────► 336 (29.7%)
│
▼
심층 연구 (5+) ────────────────► 195 (17.2%)이전 리포트에서 세션 86개에 고밀도 세션 12개였다. 3월은 5,351 세션에 심층 연구 195개. 스케일이 완전히 다른 레벨.
세션 → 도구 호출 전환율 21%는, 나머지 ~80%가 tools/list만 받고 끊는다는 뜻이다. MCP 마켓플레이스에서 "뭐 있나" 구경만 하고 나가는 사용자가 대부분인 셈. 근데 도구를 실제로 쓰는 사용자 중에서는 30%가 다중 도구, 17%가 심층 연구까지 간다 — 이건 꽤 건강한 수치다.
6.2 세션 유형
| 유형 | 건수 | 설명 |
|---|---|---|
| browse_only | 4,219 | 접속만 하고 도구 호출 없음 |
| quick_lookup | 854 | 1-2건, 단일 질문 |
| focused_research | 219 | 3-5건, 주제 탐색 |
| deep_dive | 55 | 6-15건, 깊은 조사 |
| exhaustive_survey | 4 | 16건 이상, 포괄적 연구 |
6.3 세션 지속시간
| 구간 | 세션 수 | 비율 |
|---|---|---|
| < 1분 | 3,311 | 87.1% |
| 1-5분 | 458 | 12.1% |
| 5-15분 | 8 | 0.2% |
| 15-60분 | 4 | 0.1% |
| > 60분 | 17 | 0.4% |
87%가 1분 미만. 대부분은 quick lookup이지만, 1-5분 구간(458 세션)과 60분 이상(17 세션)에서 진짜 가치가 만들어진다. 이전 리포트에서 최대 세션이 25.8시간이었는데, 3월은 727분(약 12시간). 물론 이건 MCP 연결이 유지된 채 여러 연구를 수행한 것이지, 12시간 연속 법 검색은 아닐 거다... 아마.
7. 주목할 만한 세션
이전 리포트에서는 층간소음 스토킹(세션 1), 긴급조치 9호 국가배상(세션 2), 디지털 증거(세션 3) 같은 판례 중심 세션이 많았다. 2-3월은 컴플라이언스 중심으로 전환됐다.
7.1 Story of the Month: 약관 변경 고지 의무 (3월 10일, 세션 87f133e9)
이용약관을 변경할 때, 법적으로 사용자에게 정확히 뭘, 얼마나 미리 알려야 하는가?
누군가 이 질문에 답이 필요했다. 35건의 도구 호출, 5개 도구, 3 depth.
1. aiSearch("부가통신사업자 이용약관 변경 고지 통지 의무")
2. eflaw_search("정보통신망 이용촉진 및 정보보호 등에 관한 법률")
3-30. eflaw_josub — 조문별 drill-down (고지 요건, 변경 통지 기한...)
31. law_josub — 약관규제법 교차참조
35. eflaw_service — 전문 확인부가통신사업자 → 정보통신망법 → 조문별 고지 요건 분석 → "불리하지 않은 변경"과 일반 변경의 구분 (7일 사전고지 규정) → 약관규제법 추가 의무 확인.
통신사나 플랫폼 회사의 컴플라이언스 담당자로 추정. 이전 리포트의 "층간소음 스토킹" 세션이 판례 연구의 전형이었다면, 이 세션은 규제 컴플라이언스 연구의 전형이다. LexLink가 만들어진 이유 그 자체 — 법률 전문가가 규제 요건을 조문 단위로 추적하는 것.
7.2 전자상거래 소비자보호 (세션 9acd2ba7)
- 48건 도구 호출 (3월 최다)
- 전자상거래 등에서의 소비자보호에 관한 법률 조문 읽기 + 자동결제 해지 관련
카드 소유자 자동결제 해지 권리를 집중 연구. 아마 법률 메모나 프로덕트 컴플라이언스 체크리스트 작성 중이었을 것.
7.3 ISMS 인증 의무 (세션 8fc41894)
- 34건 도구 호출
- 정보통신망법 + ISMS 인증 의무대상 행정규칙
admrul_search와 admrul_service를 적극 활용한 점이 인상적 — 행정규칙(훈령, 예규, 고시)까지 파고드는 사용자가 있다는 건, LexLink의 Phase 2 도구들이 실제로 쓰이고 있다는 증거.
7.4 퇴직금 평균임금 (세션 8d80bd51)
- 23건 도구 호출
- 법령 + 판례 동시 연구
근로자퇴직급여보장법의 퇴직금 계산 규정을 확인한 뒤, prec_search → prec_service로 법원이 "평균임금"을 어떻게 해석하는지 판례를 찾았다. 법령 + 판례 결합 워크플로우의 전형적 예시.
7.5 건축법 벌칙 (세션 6eeb44a4)
- 17건, depth 4 (3월 최고 깊이)
- 건축법 → 시행령 → 법령해석례 → 판례
aiSearch → eflaw_search → eflaw_josub → expc_search → prec_search — 5개 도구를 단계적으로 사용하며 무허가 건축물 벌칙을 조사. 이전 리포트의 "디지털 증거" 세션(103건 prec_search)처럼 하나의 도구를 반복하는 것이 아니라, 여러 도구를 계단식으로 사용하는 성숙한 패턴.
8. 시간대별 분석
8.1 시간대별 (3월)
| 시간대 (KST) | 도구 호출 | 비고 |
|---|---|---|
| 05:00 | 626 | ★ 피크 (봇 포함) |
| 04:00 | 184 | |
| 08:00 | 187 | |
| 09:00 | 147 | |
| 00:00 | 131 | |
| 03:00 | 132 | |
| 18:00 | 127 |
이전 리포트에서 피크가 06-07시(14.2%), 16-18시(18.9%)였다. 3월도 비슷하게 이른 아침(3-5시 KST)이 피크인데, KST 3-5시 = 미국 동부 1-3시 오후 / 서부 10시-12시.
해외(특히 미국) 사용자가 상당하다는 증거. 한국 법률 MCP 서버를 미국 시간대에 쓴다? 아마:
- 다국적 기업의 한국 규제 컴플라이언스 팀
- 한국 법을 연구하는 미국 소재 로펌
- 해외 거주 한국인 법률가
8.2 요일별 (3월)
| 요일 | 도구 호출 | 비고 |
|---|---|---|
| 목요일 | 794 | 최다 근무일 |
| 월요일 | 650 | 봇 날짜(3/5) 포함 |
| 수요일 | 548 | |
| 일요일 | 468 | 의외로 많음 |
| 화요일 | 400 | |
| 금요일 | 117 | |
| 토요일 | 93 |
일요일(468건)이 화요일(400건)보다 많다는 게 재밌다. 미국 시간대 효과(KST 일요일 = 미국 토요일)로 설명 가능하지만, 한국 법률가들이 일요일에도 일한다는 뜻일 수도... 아 슬프다.
9. 오류 분석
이전 리포트에서 전체 오류율 42.5%, initialize 실패가 80.9%였다. 2-3월은 극적으로 개선됐다.
9.1 오류 개요 (3월)
| 오류 유형 | 건수 | 기간 | 영향 |
|---|---|---|---|
| Cursor resources/subscribe | ~420 | 3/12-13 | 클라이언트 쪽 문제; 도구 호출 영향 없음 |
| 기타 | ~275 | 산발 | |
| 전체 | 695 |
9.2 도구 호출 성공률
| 지표 | 이전 리포트 | 3월 |
|---|---|---|
| 전체 성공률 | 57.5% | 99.6% |
| 도구 호출 오류율 | 11.2% | 0.1% |
| 도구 성공률 (초기화 후) | 84-90% | 99.6% |
57.5% → 99.6%. 이전 리포트의 초기화 에러 지옥에서 벗어났다. 물론 그건 LexLink 버그가 아니라 MCP 생태계/Smithery 문제였지만, GCP + PlayMCP로 이전한 이후 이 문제가 사실상 해결됨.
9.3 커버리지 갭
| 쿼리 | 시도한 도구 | 결과 | 문제 |
|---|---|---|---|
| 뺑소니 / 뺑소니 처벌 | aiSearch, lnkLs_search, aiRltLs_search | 0건 | 구어체 형사법 용어 처리 불가 |
| 울산 태양광 / 태양광 발전 조례 | lnkLs_search | 0건 | 자치법규 커버리지 부족 |
| 개인정보 보호법 시행령 제14조의2 | lnkLsOrdJo_search | 0건 | 조문 수준 자치법규 연계 한계 |
| hello world | 다수 | N/A | 프로브/테스트 |
뺑소니(뺑소니 처벌) 갭이 가장 큰 이슈다. 28건의 쿼리가 0건 결과를 반환했다. eflaw_search나 prec_search에서는 정상 작동하는데, aiSearch 등 보조 도구에서 구어체 형사 용어를 못 찾는다. 이건 이전 리포트의 lnkLs_search 빈 결과(형법, 형사소송법)와 같은 맥락 — 도구 선택의 문제이기도 하고, 자연어 → 법률 용어 매핑의 문제이기도 하다.
새로운 갭으로 자치법규(태양광 발전 조례) 수요가 관측됨. 현재 LexLink는 국가법 중심이라 지자체 규제는 커버하지 못한다.
10. 성능 분석
10.1 응답 크기 (3월)
| 도구 | 평균 크기 | 최대 크기 | 비고 |
|---|---|---|---|
| elaw_service | 282.1 KB | 1.28 MB | 영문법령 — 거대 |
| lsDelegated_service | 141.8 KB | 1.39 MB | 위임법령 |
| admrul_service | 59.8 KB | - | 행정규칙 |
| eflaw_service | 47.8 KB | - | 법령 전문 |
| aiSearch | 20.9 KB | 177.8 KB | AI 검색 결과 |
이전 리포트에서 PlayMCP 24KB 응답 제한이 이슈였는데, elaw_service(282KB)와 lsDelegated_service(142KB)가 여전히 무겁다. 영문법령이나 위임법령 사용량이 늘면 pagination이나 truncation이 필요할 것.
10.2 응답 시간 (3월, 프록시 레벨)
| 지표 | 값 |
|---|---|
| 평균 | 5.30 ms |
| 중앙값 | 1.58 ms |
| p95 | 6.66 ms |
| p99 | 15.52 ms |
이전 리포트에서 중앙값 539ms, 평균 705ms이던 것이 5ms 수준으로 급감한 것은 GCP 인프라 효과. 단, 이건 프록시 레벨 측정이라 실제 사용자 체감 시간은 법제처 API 호출 시간이 추가됨.
11. Regulatory Weather Report
2월
| 상태 | 주제 | 신호 |
|---|---|---|
| 🔥 Hot | 부동산/도시계획 | 상위 10개 쿼리 중 6개 |
| 📈 Rising | 건축 안전 | 화재 안전 연구 세션 3건 |
| 🆕 New | 국민연금법 | 첫 등장 |
| 📉 Cooling | 개인정보보호법 | 이전 1위 → 5건으로 급감 |
3월
| 상태 | 주제 | 볼륨 | 신호 |
|---|---|---|---|
| 🔥 Hot | 개인정보보호법 (PIPA) | 79건 | 유출 신고, 동의, 국외이전 |
| 🔥 Hot | 핀테크 규제 | 54건 | 자본시장법, 전자금융거래법, 내부자거래 |
| 📈 Rising | AI 규제 | 8건 | "인공지능" 쿼리 — AI 거버넌스 초기 신호 |
| 📈 Rising | 디지털 헬스 | 13건+ | 의료법, 디지털 치료제, 원격의료 |
| 🆕 New | 전자상거래 소비자보호 | 세션 단위 | 자동결제 해지 권리 |
| 📉 Cooling | 부동산 | 최소 | 2월 1위 → 3월 거의 없음 |
| ➡️ Steady | 노동법 | 27건+ | 근로기준법, 퇴직금 (상시 주제) |
| ➡️ Steady | 건축법 | 14건 | 무허가 건축물 벌칙 |
규제 시대정신: 3월 2026은 데이터 거버넌스의 달이다. 프라이버시/핀테크/AI/의료가 4개의 별개 트렌드가 아니라 하나의 연결된 규제 파도라는 건 앞에서 이야기했다. LexLink의 쿼리 데이터는 한국 규제 환경의 실시간 거울이며, 3월의 지형은 "새로운 기술 영역에서 개인정보를 어떻게 다룰 것인가?"라는 질문이 지배하고 있다.
12. 추후 개선사항 업데이트
12.1 이전 리포트에서의 개선사항 현황
| 항목 | 이전 상태 | 현재 상태 |
|---|---|---|
| TOON(token 절약) | 보류 | 삭제 고려중 — TOON이 좋기는 한데, legacy 모델들에서 제대로 처리를 못하는 현상이 발견됨 |
| tool 100개 넘으면 분리 | 보류 | 여전히 보류 — 현재 26개 |
| 판례/해석례 검색 개선 | 진행중 | 부분 해결 — aiSearch, aiRltLs_search 추가됨 |
| OC key 필수화 | 제안 | 미해결 — 여전히 optional |
| 검색어 정규화 | 제안 | 미해결 — 개인정보보호법 vs 개인정보 보호법 여전히 혼재 |
| 판례 연구 워크플로우 | 제안 | 자연스럽게 해결 — 사용자들이 알아서 prec_search→prec_service 패턴 사용 |
| article_citation 오류 | 30.1% 오류율 | 해결 — 3월 성공률 99.6% |
| MCP 초기화 오류 | 80.9% | 해결 — GCP + PlayMCP 이전으로 해결 |
12.2 새로운 개선사항
2-3월 로그에서 도출된 추가 개선사항:
- 뺑소니 갭 해결 — 구어체/일상어 → 법률 용어 매핑 레이어 추가. "뺑소니" → "도로교통법 제54조" 같은 resolving
- 자치법규 커버리지 — 태양광 조례 등 지방자치단체 규제 수요 감지. API 커버리지 0%인 자치법규 카테고리(3개 API)에 대한 구현 검토
- elaw_service 응답 최적화 — 282KB 평균, 1.28MB 최대. 영문법령 사용 증가 시 pagination 필요
- aiSearch 진입 가이던스 — 77%가 eflaw_search로 시작하는데, 탐색적 질문에는 aiSearch가 더 적합. LLM 대상 tool description 개선 고려
- 봇 대응 — IP+쿼리 기반 rate limiting 도입 검토. 605건 같은 건 사실 쉽게 잡힘
13. 종합 비교: 이전 리포트 vs 현재
| 차원 | 이전 (11월-1월) | 현재 (2-3월) |
|---|---|---|
| 로그 건수 | 20,555건 | ~29,500건 |
| 도구 호출 | 6,753건* | 3,832건 |
| 전체 성공률 | 57.5% | ~99% |
| 도구 성공률 | 84-90% | 99.6% |
| 식별된 사용자 | 2명ㅋㅋ | 12종 클라이언트 |
| 주요 클라이언트 | (빈 값) 65.5% | Mozilla 42.3% |
| 주요 주제 | 개인정보보호법 1위 | 프라이버시/핀테크/AI 클러스터 |
| 최고 세션 | 453건 (개보법+소음 연구) | 48건 (전자상거래 소비자보호) |
| 최고 일일 트래픽 | 8,479건 (대부분 에러) | 565건 (순수 유기적) |
| 인프라 | Smithery.ai + ngrok | GCP + PlayMCP + Smithery + run.tools |
| 오류 주범 | initialize 80.9% | Cursor resources/subscribe (일시적) |
*이전 도구 호출 수에는 Smithery 초기화 재시도 등이 포함되어 있어 직접 비교는 부적절
가장 큰 변화는 질적 전환이다. 이전 리포트에서 20,555건의 로그 중 실제 유의미한 사용은 극소수였고, 오류가 42.5%를 차지했다. 3월에는 3,070건의 도구 호출 중 99.6%가 성공했고, 세션 분석에서 컴플라이언스 담당자, 법률 전문가, 자동화 시스템의 실제 사용이 다수 관측됐다.
"식별된 사용자 2명(ㅋㅋ)"에서 12종 클라이언트, 5,351 세션까지. 더 이상 웃을 일은 아니다.
Misc
- 이전에 "그간 MCP 배포자(혹은 호스트)는 무료로 배포할 수 있었는데, 그게 2026.3.1.부로 막힘."이라고 했는데 — 실제로 3월 중순부터 Smithery 유료화가 적용됨. 그에 대응하기 위해 AWS로 갔다가, GCP에 정착.
- OC key 강제 문제는 여전히 미해결. 내 OC key를 뿌릴까 고민했던 것... 결국 아직도 뿌리고 있다. 일단 사용량이 더 늘 때까지는 이대로 가기로.
- Go-http-client의 등장(19%)은 LexLink가 자동화 파이프라인에 임베딩되기 시작했다는 뜻인데, 이건 기쁘면서도 무섭다. 봇 605건이 사람이 for loop 잘못 짠 거면 괜찮지만, 자동화 클라이언트가 늘면 rate limiting은 진지하게 고민해야 한다.
- 운영은.. 여전히 지옥이다. 하지만 사용자가 있는 지옥은 없는 것보다 낫다. 후후후! 실사용자들이 무엇을 검색하는지 살펴보고 이를 어떻게 개선할지가 진짜 재밌다
