Sanghyun Park님의 포스트

LexQ의 MCP를 다시 붙였는데 도구가 전부 실패했습니다

LexQ는 전체 API를 MCP로 열어 뒀습니다.

에이전트가 규칙을 만들고, 변경 영향을 시뮬레이션하고, 배포까지 하는 구조입니다.

오늘 그 MCP를 다시 연결했는데 도구 호출이 하나도 되지 않았습니다. 돌아온 것은 이 한 줄입니다.

{"error":"Unexpected end of JSON input"}

JSON 파싱 오류처럼 보였습니다. 실제로는 아니었습니다.

원인은 오류를 뭉개는 코드였습니다

MCP 서버가 업스트림 응답을 이렇게 처리하고 있었습니다.

if (contentType.includes('application/json')) {
  const json = await response.json();
  ...
}

렌더링 분기를 위해서 상태 코드를 보지 않고 content-type만 봤습니다. 그런데 업스트림은 인증 실패에도 application/json을 선언하면서 body를 비웁니다.

HTTP/2 401
content-type: application/json;charset=UTF-8
content-length: 0

빈 body에 response.json()을 부르면 던집니다. catch가 그 메시지를 그대로 감쌌습니다. 인증 실패가 JSON 문법 오류로 위장된 겁니다.

그래서 결국 상태 코드를 먼저 보도록 고치고, 오류 형태를 CLI와 맞췄습니다.

영상

Agent가 결정 라이프사이클을 처음부터 끝까지 운전하는 데모입니다.

LexQ MCP demo (https://youtu.be/JwtGmBnDJus)

영상은 잘 돌아가는 모습이고, 위 기록은 그게 안 될 때 어디를 봐야 하는지에 대한 것입니다.

오류를 뭉개는 코드, 어디서 만나셨나요.

비즈니스 규칙을 코드 밖으로 꺼내는 도구, LexQ를 만들고 있습니다.

6년간 백엔드 개발자로 일하면서 매번 같은 일을 겪었습니다. 할인율 또는 한도 하나 바꾸는데 PR, 리뷰, 배포가 필요했습니다.

숫자를 정하는 곳은 사업팀인데, 그 숫자를 바꿀 수 있는 건 개발자뿐이었습니다.

그래서 혼자 만들기 시작한 것이 LexQ입니다.

규칙을 데이터로 꺼내
- 배포 없이 규칙을 바꾸고
- 바꾸기 전에 지난달 실제 트래픽으로 변경 영향 시뮬레이션해서 파장을 미리 보고
- 모든 결정에 어떤 규칙이 왜 그렇게 판정했는지 추적을 남깁니다.

최근에는 예약 배포를 붙였습니다. 분기마다 바뀌는 할인율처럼 "10월 1일부터 시행"이 정해진 규칙을, 미리 만들어 두면 시스템이 그 날짜에 알아서 배포합니다.

배포한 사람과 시간까지 전부 기록으로 남고요.

규칙 관리 때문에 배포를 기다려 본 적이 있는 분들의 이야기가 궁금합니다.

lexq.io