야호!!!! PlayMCP 심사 통과!!
- 카카오 PlayMCP LexLink: https://playmcp.kakao.com/mcp/156
- smithery.ai LexLink: https://smithery.ai/server/@rabqatab/lexlink-ko-mcp
- github: https://github.com/rabqatab/LexLink-ko-mcp/tree/main
LexLink 이게 뭔데?
TL;DR: "국가법령정보 OpenAPI… 그거 그대로 쓰기 빡세잖아? 그걸 MCP로 말아서 설치 한 번으로 여기저기서 쓰게 만든 거임."
- 국가법령정보 공동활용 를 더 쉽게 사용할 수 있는 MCP 서버
- LLM에 물리면 사용할 수 있음! (ChatGPT, Claude 등 대부분의 상용 LLM 서비스에 접목 가능)
- 지금 구현된 기능은 30개 미만이지만, 계속된 업데이트(11/10 v1.0 공개 이후 1~2주일에 한 번씩은 업데이트 하는 중)를 통해 tool 개수를 늘려나갈 예정
- 구현된 기능은 github 링크 참조 (한국어도 있어요!)
- 누가 쓰면 좋을까? (1) 법령 리서치 자동화하고픈 법률 전문가 (2) 법령 데이터 기반 서비스 만드는 개발자 (3) AI 에이전트에 법령 검색 기능을 붙이고 싶은 AI 빌더
- 어떻게 설치? 위 3개 링크(PlayMCP, smithery, github)참조
- 단, 국가법령정보 공동활용에서 OC 키 발급 필수! (API key처럼 사용됨) 사용량 제한은 없지만 업무시간에 너무 많이 사용하면 키가 블락될 수 있다고~ (굉장히 두루뭉술한 가이드라인이지만 실제로 유선으로 안내받은 사항임.. 얼탱..)
왜 만들었나?
모티베이션
- 컴플라이언스 부서를 위한 멀티 에이전트 시스템을 만들고 있었음: 워크플로우 내부에는 국가법령정보 Open API를 이용한 최신 법령 정보 확인, 크롤링한 유권해석 데이터 등이 포함됨
- 국가법령정보 Open API를 LLM tool로 말아보니 이것만 따로 MCP로 말아서 공개해도 괜찮겠다 싶었음. 이 기능만 떼서 사용할 수 있으니까!
- 그리고 국가법령정보 스키마가 참.. 이해하기 어려워..
- 결정적으로, 컴플라이언스 부서의 피드백이 너어어어어어어무 없었음. user study를 중심으로 한 evaluation 진행해야 하는데, 어어어어어어엄청나게 비협조적이었음. 거의 "내가 왜? 느그 부서장이랑 우리 부서장이랑 협의해서 나한테 정식으로 업무요청하셈" 수준. 이거 나 좋자고 했냐..
API를 Direct tool로 싸는 건 운영지옥이다.
| Aspect | Direct Tools | MCP Server |
|---|---|---|
| 이식성(portability) | 단일 플랫폼 | 어떤 MCP 클라이언트에서도 사용 가능 |
| 배포 | 코드 복붙(혹은 github/gitlab 사용) | 한 줄로 끝(npx @anthropic/mcp install) |
| 업데이트 | 사용자가 직접 업데이트 해줘야 함 | 서버 단에서 업데이트 하면 끝 |
| 디스커버리 | 사용자가 직접 문서 작성 필요 | Auto-discoverable 스키마 |
| 생태계 | 사용자의 로컬/서버에서 고이 잠들어 있음 | Smithery, npm, Kakao PlayMCP etc. |
- AI와 관계없는 사용자가 AI를 사용할 수 있도록 배포하는 방법은 지옥의 양자택일
- 서버에 띄워서 엔드포인트만 제공
- 서버: 이렇게 작은 서버에서 돌린다고? 응 죽을게~
- LLM: 이렇게 request 많다고? 큐도 없이? 응 죽을게~
- github/gitlab이든 손배포든 엔드유저한테 코드 배포
- 보안: 응ㅋㅋ 너 뒤졌음ㅋㅋ
- 엔드유저: 한국어로 말해줄래요? 어쩌라는 거임?
- 업데이트: 엔드유저한테 업데이트할 때마다 코드 배포한다고? 응 죽을게~
- 서버에 띄워서 엔드포인트만 제공
- 국가법령정보 API를 비AI 유저가 쉽게 사용할 수 있는 방법? MCP로 말아서 어딘가에 띄우는 수밖에 없다.. 적용 방법은 그래도 간단한 편이잖아.. 사용자가 API 쓰려면 법령 식별자부터 머리아파..
법령 조회 식별자, 왜 이렇게 헷갈릴까?
- 국가법령정보 공동활용 OpenAPI는 "같은 법령을 가리키는 방법"이 API마다 달라서,
법령을 찾는 것보다 법령을 지칭하는 키부터 다시 학습하게 되는 경우가 많음
| 🔎 혼선 포인트 | 실제로 보이는 이름/형태 | 사용자/개발자가 겪는 혼란 | 결과(비용) | ✅ LexLink-ko가 줄이는 것 |
|---|---|---|---|---|
| 같은 대상, 다른 파라미터명 | ID / MST / LID | "법령을 가리키는 키가 하나가 아님" | 구현/문서화 반복 | 통합 인터페이스 지향 → 불가 확인 후 사용자가 신경 쓸 필요 없게끔 구성 |
| 응답 필드도 이중화 | 법령ID / 법령일련번호 | "둘 중 뭐가 본문 조회 키지?" | 매핑 실수/버그 | 검색 결과 → 조회 키 자동 연결 |
| MST와 lsiSeq는 사실 같은 녀석 | API: MST / 웹: lsiSeq | "같은 법령인데 ID가 왜 다르지?" | 변환 로직 필수 | MST ↔ lsiSeq 자동 변환 (참조 조문 검색 기능 사용시) |
| 웹/오픈API 용어가 섞임 | 웹: lsiSeq / API: MST | "문서마다 다른 용어" | 온보딩 지연 | 개념 숨기고 '법령'만 받기 |
| 조합에 따라 규칙이 달라짐 | ID 조회 vs MST+시행일 | "같은 조회인데 입력 규칙이 다름" | QA 케이스 증가 | 의도 기반 API 분리 (최신/특정시점) |
| 행정규칙은 또 다른 ID 체계 | id (일련번호) / LID (규칙ID) | "법령이랑 행정규칙 ID가 다름" | 별도 학습 필요 | 도구별 명확한 파라미터 가이드 |
Evaluation 결과 받기가 힘듦!
- 내가 나 좋자고, 내 연구 하자고 컴플라이언스 MAS 만들었냐.. 컴플 부서원분들 여러분 쓰라고 만든다잖아...
- 그러면 human evaluation 정도는 협조해줘야 하는 게 인지상정 아니냐...
- 답답해서 내가 익명의 유저들로부터 evaluation 결과 받아서 분석해야겠다!
- 그래서 카카오 PlayMCP에도 올리고, smithery.ai 에도 올리고, 깃헙에도 올리고 했다! 앞으로 어디에 더 올릴지는 미정임
- 원하신다면.. 댓글이나 github issue에도 올려준다면 압도적 감사..
배포와 승인과정에서 경험한 것들
smithery와 PlayMCP의 차이
| 항목 | Smithery.ai | Kakao PlayMCP |
|---|---|---|
| 호스팅 | Smithery가 서버 운영 (완전 관리형) | 사용자가 직접 호스팅 필요 |
| 배포 방식 | Git push → 자동 빌드/배포 | 원격 URL 등록 (서버 직접 운영) |
| 트랜스포트 | stdio / HTTP / SSE | Streamable HTTP만 지원 |
| 설정 파일 | smithery.yaml + Dockerfile | 없음 (URL만 등록) |
| 도메인 | 자동 제공 (*.smithery.ai) | 도메인 필수 (IP 불가) |
| 인증 | Session Configuration | Key/Token 헤더 또는 OAuth |
| 비용 | 무료 플랜 (사용자는 무료/유료 플랜 있음) | 무료 (단, 서버 비용 자부담) |
| 테스트 | Playground 제공 | 임시 등록 후 테스트 |
| MCP 심사방식 | 등록제 | 심사제 |
- PlayMCP에 많은 돈을 투자하고 싶지는 않았음. 그래서 aws t4 micro 서버 하나 파서 띄워놓고, 도메인은 ngrok 계정 가입하면 하나 무료로 부여해주는 것으로 사용. IP 등록도 안 돼서 고정IP 등록으로 해결할 수가 없었음.
- 물론 사용자가 폭주하면 위 수준으로는 안 될 거고, 큐, 게이트웨이, 어쩌면 pub/sub 등등이 필요할 것 같기는 한데, 그 문제는 추후에 생각하자.
- 사용자 입장에서는 smithery.ai나 PlayMcp나 큰 차이가 없겠지만, 개발자 입장에서는 압도적으로 smithery.ai가 편하다. smithery 배포를 위한 최소한의 작업만 해놓고, github에 올려놓으면 smithery 자체 서버에서 구동하기 때문. dockerfile 따로 있지만, 개발자가 손댈 것은 없다.
- PlayMCP는 글자 수 제한이 있음(20k). 그래서 무식하게 많은 텍스트를 때려박고, generator LLM이 좋은 답변을 생성하도록 기대할 수 없음
- smithery는 등록제라 등록만 하면 ok이지만, Play MCP는 심사제다.
- 이 점이 불편한 게, PlayMCP 등록 당시 설명과 달라지면 재심사를 받아야 한다는 것.. 등록 당시 tool이 23개, 현재는 거의 30개인데, 등록 당시 description에 tool 23개라고 적어버려서 이를 수정하기 위해 재심사를 받아야 함..
- 국가법령정보 공동활용 Open API를 사용하기 위해서는 API key 처럼 사용하는
OCtoken을 발급받아야 함. 이를 MCP 설명에 기재했는데, 이 정책에 관해 clarification을 요구하는 메일을 받아서 상당히 당황....
- 그럼에도 한국인 사용자(+비AI인력)한테 가장 소구력이 높은 플랫폼은 PlayMCP 라는 점은 어쩔 수 없긴 하다.
국가법령정보 공동활용의 문제
- 파라미터 불일치의 문제: 이건 위에서 언급했으니까 넘어가자.
- 파라미터에 대한 설명 불충분(input & output 모두)
- '사전식 검색'은 대체 뭐지?
- '자법', '타법'은 대체 뭔데...?
- query 문제
- query 예제를 달아놓기는 했는데.. 정확히 이게 whitespace 단위로 나눠서 검색이 되는 건지, 아니면 query 전체를 하나의 토큰으로 검색하는 건지 불명확함.
- 형태소 처리를 포함한 query의 preprocessing도 불명확함
- 지능형 검색 관련
- 아직 배포는 안 했지만 지능형 검색 API도 툴로 말아놓기는 했는데, 이 "지능형 검색"이라는 것의 모델/알고리즘이 불명확함
- 예제는 "뺑소니"로 검색을 해도 도로교통법 등등 해서 잘 찾아온다고 말해놨는데, 유의어 사전을 만든 건지, word vector로 처리를 한 건지 불명확해서 섣불리 손대기가 주저됨
- 랭킹 문제
- 랭킹 알고리즘 구현..은 바라지 않는 게 맞지만, 그래도 exact match 정도는 기대할 수 있는 거 아닌가?
- 적어도 '민법'을 검색했을 때 exact match 결과인 '민법'이 최상위로 나와야지, 가나다 오름차순으로 '난민법'이 나오는 건 아니잖아.. '상법'을 검색했을 때 '공무원보상법'이 아니라 '상법'이 최상단에 나와야 하고..
- 그래서 어쩔 수 없이 법령 검색 시 랭킹 알고리즘을 짤 수 밖에 없다.. 이것도 지금은 완전 간단하게 해놨는데, jaccard similarity든 뭐든 써서 고도화가 필요함
로그기록 및 대시보드
- PlayMCP나, smithery나 모두 로그 및 대시보드 기능이 부족함
- PlayMCP는 해당 기능이 아예 없지만, 서버단에서 리퀘스트 모두 기록하는 파트 넣으면 어느 정도 커버 가능할 것으로 생각
- smithery는 로그 트래킹이나 대시보드가 있는데.. smithery 자체 서버에서 MCP 서버가 구동되다 보니 내가 직접 확인할 수가 없어서 답답함. (아래는 각각 smithery observability, logs 페이지)
- 그래서 로그 싹 다 저장하고, 분석하는 페이지를 만들고 있음. 아마 그 데이터 기반으로 tool 개선이 있을 듯.
향후 개선 방향
- TOON을 적용해서 token 사용량을 줄이려고 함. 시험삼아 해봤을 때는 아래와 같은 문제점이 있었음
- TOON을 input으로 줬을 때 그럭저럭 이해는 잘 하는데, TOON으로 output은 못 뽑아냄. 가능하게 하려면 few shot 줘야 하는데, 그러면 token usage trade-off를 생각해봐야 함.
- csv같은 테이블 형태에서는 TOON의 효율이 올라가는데, 줄글이 길면 큰 개선 없다고 함.
prec_search같은 판례, 유권해석례 검색 도구의 output은 줄글이 많은데, 이 경우에는 json으로 가야 하나? 그러면 TOON과 json이 섞이는데, 너무 유지보수 비용이 커지지는 않을까?
- tool 개수가 많아진다면?
- 지금 계획하고 있는 tool 개수는 최종적으로 100개가 넘어갈 것 같은데, 그렇다면 tool이 너무 많아지지 않을까?
- 비슷한 tool 끼리 묶어서 별개의 MCP로 구성해야 하나? 아니면 비슷한 tool끼리 묶어서 하나의 tool로 구성해야 하나? claude에서 tool-search-tool 냈는데, 이런 걸 고민해봐야 하나? 그렇다면 leaf node의 tool은 어떻게 선택하지? embedding? keyword match? 속도가 너무 느려지지는 않을까?
- 너무나도 멍청한 판례/해석례 검색
- 현재는 키워드 기반으로 판례/해석례를 검색하는 것 같은데(자세한 알고리즘은 법제처만이 알겠지..), 동의어 검색으로 넓히거나, (raw data가 없어서 불가능할 것 같지만) embedding-based method까지 접목한 hybrid search까지 확장해야 함
- hybrid search를 쓰려면 DB를 붙여야 할 것 같은데.. opensearch를 써야 할까?
- 그 외에는 사용 기록 분석하면서 개선 예정
다 만들고 보니, PlayMCP에 비슷한 게 있네..? 그래도 내 MCP 서버가 먼저 나왔으니 괜찮을거야.. 아마도.. 국가법령정보 MCP
multidisciplinary