시리즈: AI 네이티브 평가 플랫폼 구축하기 (11/20)

저는 한동안 FormLM의 CLI 및 MCP 서버를 구축해 왔습니다. 아키텍처는 견고하고, 도구(tools)들은 정의되어 있으며, zod 스키마(schemas)도 깔끔합니다. 하지만 "코드가 작동한다"는 것과 "AI 에이전트가 실제로 당신의 도구를 사용하여 진짜 무언가를 만드는 것을 지켜보는 것" 사이에는 차이가 있습니다.

지난 주말, 저는 고립된 테스트를 중단하고 Claude Desktop이 제가 구축한 MCP 도구들만을 사용하여 처음부터 완전한 평가 양식(assessment form)을 구축하도록 하기로 결정했습니다. 일일이 도와주지도 않고, 수동으로 CLI 명령어를 입력하지도 않으며, 나중에 웹 UI에서 양식을 수정하지도 않을 것입니다. 오직 Claude, MCP 서버, 그리고 자연어 프롬프트(natural language prompt)만 사용합니다.

문제가 발생한 부분들을 포함하여 전체 타임라인을 공개합니다.

설정 (The Setup)

저는 이미 formlm-cli를 전역(globally)으로 설치했고 Claude Desktop의 설정(config)에 구성해 두었습니다:

{
  "mcpServers": {
    "formlm": {
...

이전에 formlm-cli auth login을 통해 로그인해 두었기 때문에 토큰이 이미 저장되어 있었습니다. Claude는 인증할 필요가 없었습니다. 바로 도구를 사용하기 시작할 수 있었습니다.

프롬프트 (The Prompt)

저는 Claude에게 다음과 같은 지침을 주었습니다:

"번아웃 자가 진단 양식을 구축해줘. 세 가지 차원: 소진(exhaustion), 냉소(cynicism), 그리고 직업적 효능감(professional efficacy). Maslach 프레임워크를 사용해. 각 차원에는 1-7 리커트 척도(Likert scale)로 된 질문 3개가 필요해. 효능감 차원에는 역채점 항목(reverse-scored item)을 하나 추가해줘. 그런 다음 이를 게시하고 나에게 URL을 알려줘."

그게 전부였습니다. 필드 ID(field IDs), 타입 이름(type names), 점수 산정 구성(scoring configuration)에 대한 세부 사항은 없었습니다. 저는 Claude가 스키마 설명(schema descriptions)만으로 올바른 도구 호출(tool calls)을 찾아낼 수 있는지 확인하고 싶었습니다.

Claude가 한 일 (단계별 진행)

1단계: 앱 생성 (Create the app)

Claude는

이 점이 저를 놀라게 했습니다. 어떤 필드도 추가하기 전에, Claude는 사용 가능한 필드 유형(field types)이 무엇인지 확인하기 위해 field_schema를 호출했습니다. Claude는 유형을 알고 있다고 가정하지 않고 직접 확인했습니다. 응답에는 scale, radio, input, textarea 등을 포함하여 지원되는 모든 유형이 나열되었습니다.

그 다음, Claude는 field_config --type scale을 호출하여 scale 필드가 어떤 속성(properties)을 허용하는지 확인했습니다. 이를 통해 min, max, 그리고 점수 옵션(scoring options)을 찾아냈습니다.

이 순간 저는 스키마 설명(schema descriptions)이 생각보다 더 중요하다는 것을 깨달았습니다. Claude는 그것들을 마치 문서(documentation)처럼 읽고 있었습니다. 모든 zod 필드에 있는 .describe() 문자열은 단순한 메타데이터가 아니라, AI가 따르는 지침(instructions)이었습니다.

3단계: 소진 차원 추가 (3개 필드)

Claude는 소진(exhaustion) 차원을 위해 세 개의 scale 필드를 추가했습니다:

field_add: id=ex1, type=scale, title="I feel emotionally drained by my work", min=1, max=7
field_add: id=ex2, type=scale, title="I feel used up at the end of workday", min=1, max=7
field_add: id=ex3, type=scale, title="I feel fatigued when I get up in the morning and have to face another day", min=1, max=7

여기까지는 순조로웠습니다. 필드 ID(ex1, ex2, ex3)도 합리적이었습니다. 제목들은 임의로 만들어낸 질문이 아니라 실제 Maslach Burnout Inventory 항목들이었습니다. Claude는 해당 프레임워크를 알고 있었습니다.

4단계: 냉소 및 효능감 추가

냉소(cynicism, cy1, cy2, cy3)와 전문적 효능감(professional efficacy, pe1, pe2, pe3)에 대해서도 동일한 패턴이 적용되었습니다.

여기서부터 흥미로워졌습니다. 효능감 차원의 경우, 저는 역채점 항목(reverse-scored item)을 요청했었습니다. Claude는 다음과 같이 추가했습니다:

field_add: id=pe3, type=scale, title="I do NOT feel I am making an effective contribution to my organization", min=1, max=7

"NOT"을 사용한 것은 Claude가 역채점 항목을 만드는 방식이었습니다. 즉, 질문을 부정문으로 구성하여 높은 점수가 낮은 효능감을 나타내도록 만든 것입니다. 제가 역채점(reverse scoring)을 구현하는 방식(scale 설정에서 --negFields 메커니즘을 사용하는 방식)은 아니었지만, scale 설정 없이 폼(form)만 구축하는 상황에서는 합리적인 접근이었습니다.

5단계: 게시

Claude는 앱 ID와 함께 share_publish를 호출한 다음, share_url을 호출하여 작성용 URL을 가져왔습니다. 이 모든 과정이 하나의 링크로 돌아왔습니다.

총 소요 시간: 약 90초. 세 가지 차원(dimension)에 걸친 9개의 필드가 생성되었고, 게시까지 완료되어 라이브 URL이 생성되었습니다.

이상해진 지점

폼(form)은 작동했습니다. 사람들은 내용을 작성할 수 있었습니다. 하지만 몇 가지 사항을 통해 도구 자체만으로는 충분하지 않다는 것을 깨달았습니다.

차원 그룹화(dimensional grouping)의 부재. Claude는 9개의 필드를 추가했지만, 이는 단순히 9개의 개별 척도(scale) 질문일 뿐이었습니다. 폼에는 "차원(dimension)" 개념이 없었습니다. 그 개념은 Scale 모듈에 존재하지만, MCP 서버는 아직 이를 노출하지 않습니다. 따라서 폼은 답변을 수집할 수는 있었지만, 차원 점수(dimension scores)를 계산할 수는 없었습니다. 이는 제가 채워야 할 공백입니다.

채점 로직(scoring logic)의 부재. 차원이 구성되어 있다 하더라도, MCP 도구에는 척도 설정(scale configuration) 명령이 포함되어 있지 않습니다 (설계상 의도된 사항입니다. 이러한 명령은 관리자 권한이므로 화이트리스트의 차단 목록에 포함되어 있습니다). 따라서 이 폼은 데이터 수집 도구일 뿐, 평가 엔진(assessment engine)은 아니었습니다. 채점을 수행하려면 Scale 모듈을 별도로 구성해야 합니다.

역채점 항목(reverse-scored item)이 구조적이지 않고 텍스트로 처리됨. Claude는 부정적인 어조의 질문을 작성함으로써 역채점(reverse scoring)을 처리했습니다. 이는 데이터 수집에는 유효하지만, 채점 엔진에 점수를 반전시키라고 명령하지는 않습니다. 진정한 해결책은 척도 설정의 --negFields 파라미터를 사용하는 것이지만, 이는 MCP를 통해 노출되지 않습니다.

배운 점

MCP 도구는 폼 구축(form construction)에 능숙합니다. Claude는 스키마(schema) 설명을 바탕으로 적절한 필드 유형, 적절한 척도 범위, 적절한 질문 문구를 모두 파악해냈습니다. .describe() 문자열이 제 역할을 다한 것입니다.

하지만 폼 구축은 평가의 첫 20%에 불과합니다. 나머지 80%인 차원 채점(dimensional scoring), 등급 할당(tier assignment), 보고서 생성(report generation) 등은 MCP 서버가 노출하지 않는 모듈에 존재합니다. 이는 의도된 사항(보안 목적)이지만, 결과적으로 AI 에이전트가 입력 폼은 만들 수 있어도 평가 로직(assessment logic)은 만들 수 없음을 의미합니다.

다음 단계: AI가 접근해서는 안 되는 관리자 명령(administrative commands)을 노출하지 않으면서, 어떻게 하면 스케일 설정(scale configuration)을 MCP 서버에 안전하게 노출할 수 있을지 파악하는 것입니다. 화이트리스트(whitelist)가 존재하는 데에는 이유가 있지만, "AI가 필드를 추가할 수 있음"과 "AI가 채점 규칙을 재설정할 수 있음" 사이에는 중간 지점이 존재합니다.

현재 워크플로우는 다음과 같습니다: Claude가 양식을 구축하면, 제가 수동으로 채점 방식을 설정합니다. 이는 여전히 전체를 수동으로 구축하는 것보다 훨씬 빠릅니다. 하지만 제가 원하는 완전히 AI 중심적인 평가 파이프라인(assessment pipeline)은 아닙니다.

그럼에도 불구하고 — 단 한 문장의 프롬프트로부터 Claude가 90초 만에 완전하고 게시 가능한 양식을 구축하는 것을 지켜보는 것은 정말 놀라운 순간이었습니다. 도구들은 작동합니다. 스키마(schemas)도 작동합니다. 단지 노출해야 할 파이프라인이 더 많을 뿐입니다.

이 글은 FormLM을 위한 AI 네이티브 툴링(AI-native tooling) 구축에 관한 시리즈의 일부입니다. CLI와 MCP 서버는 오픈 소스입니다 — github.com/formlm/cli에서 확인하거나 formlm.me에서 플랫폼을 체험해 보세요.