Five Elements Framework를 사용하여 60개의 MCP 서버 구축하기: Build-in-Public 여정

대부분의 사람들은 AI 에이전트에 더 많은 기능을 추가하는 데 집중합니다. 하지만 저는 더 나은 평가 루프 (evaluation loops)가 더 중요하다는 것을 발견했습니다.

지난 몇 달 동안 저와 저희 팀은 60개 이상의 MCP (Model Context Protocol) 서버와 Skill을 호스팅하는 플랫폼인 tancoai.com을 구축해 왔습니다. "유용한 AI 도구를 몇 개 만들어보자"로 시작했던 일이, 무엇이 Skill을 실제 프로덕션 환경에서 정말로 신뢰할 수 있게 만드는지에 대한 깊은 탐구로 이어졌습니다.

그 과정에서 우리는 Five Elements Framework (连珠五环)라고 부르는 것을 개발했습니다. 이것은 라이브러리나 패키지가 아닙니다. 맹목적으로 기능을 추가하는 것을 멈추고, 우리가 만든 것이 실제로 작동하는지 측정하기 시작하게 만드는 Skill 설계에 대한 사고방식입니다.

이 글은 우리가 이 프레임워크를 60개 이상의 서버에 적용했을 때 일어난 일들에 대한 솔직한 기록입니다. 잘 풀리지 않았던 부분들도 포함되어 있습니다.

우리가 직면한 문제

시작할 때 우리의 접근 방식은 간단했습니다. 유용한 작업을 식별하고, 그에 맞는 Skill을 구축하고, 몇 번 테스트한 뒤, 출시하는 것이었습니다. 그리고 이를 반복했습니다.

처음 10개 정도의 Skill까지는 이 방식이 통했습니다. 기본적인 테스트를 통과했고, 그럴듯해 보이는 출력을 반환했습니다. 하지만 무언가 잘못되었다는 느낌이 들었습니다.

우리는 이를 "작동은 하지만 느낌이 이상한 (works but feels wrong)" 증후군이라고 부릅니다. Skill이 우리의 수동 테스트 케이스를 통과했습니다. 프롬프트를 입력하고 합리적인 응답을 받으면 완료로 표시했습니다. 하지만 실제 사용 로그를 살펴보면 상황은 달랐습니다.

• 트리거 실패 (Trigger failures): Skill이 작동하지 말아야 할 프롬프트에서 활성화되거나, 활성화되어야 할 때 활성화되지 않았습니다.
• 컨텍스트 격차 (Context gaps): Skill이 관련 없는 정보를 검색하거나 실제로 중요한 컨텍스트를 놓쳤습니다.
• 포맷 드리프트 (Format drift): 동일한 Skill이 80%의 경우에는 JSON을 반환하고 20%의 경우에는 산문(prose)을 반환하여, 다운스트림 소비자 (downstream consumers)를 망가뜨렸습니다.
• 피드백 루프 부재 (No feedback loop): Skill이 시간이 지남에 따라 나아지고 있는지 아니면 나빠지고 있는지 알 수 있는 방법이 없었습니다.

임계점은 우리가 100개 이상의 실패한 Skill 구현 사례를 분석했을 때 찾아왔습니다. 시스템 충돌(crash)이 아니라, 잘못되거나 도움이 되지 않는 결과를 생성한 "성공적인" 실행들이었습니다. 패턴은 매우 놀라웠습니다:

그 마지막 수치는 경종을 울렸습니다. 우리는 Skill이 나아지고 있는지 알 수 있는 방법도 없이 Skill을 구축하고 있었습니다.

Five Elements Framework 소개

우리는 처음부터 "프레임워크"를 만들기 위해 시작한 것이 아니었습니다. 우리는 그저 똑같은 실수를 반복하지 않기 위해 시작했습니다. 하지만 시간이 흐르면서 우리가 지속적으로 점검하던 패턴들이 다섯 가지 요소로 응축되었습니다.

1. Trigger (트리거) — 적절한 순간에 활성화되는가?

다른 무엇보다도, Skill은 언제 실행되어야 하는지 알아야 합니다. 이는 사소해 보이지만, 대부분의 조용한 실패(silent failures)가 시작되는 지점입니다. URL이 포함된 모든 질문에 활성화되는 팩트 체크(fact-checking) Skill은 너무 공격적입니다. 반면, 명시적인 "이것을 팩트 체크해줘"라는 명령에만 활성화되는 것은 너무 수동적입니다.

우리는 "실행되어야 함"과 "실행되지 않아야 함"이라는 입력 코퍼스(corpus)를 사용하여 트리거를 테스트하고, 정밀도(precision)와 재현율(recall)을 각각 측정합니다. 두 지표가 모두 90%를 초과하기 전까지는 Skill을 배포할 수 없습니다.

2. Retrieval (검색) — 컨텍스트를 정확하게 찾는가?

대부분의 Skill은 외부 컨텍스트(context) — API 데이터, 문서, 이전 대화 기록 — 가 필요합니다. 질문은 "검색할 수 있는가?"가 아니라 "올바른 것을 검색하는가?"가 되어야 합니다.

우리는 이를 히트 레이트(hit-rate) 지표로 측정합니다. 관련 컨텍스트가 알려진 테스트 케이스 세트에 대해, Skill이 해당 컨텍스트를 노출하는 비율이 얼마인지 측정하는 것입니다. 프레임워크를 도입하기 전에는 이를 전혀 추적하지 않았습니다. 알고 보니, 우리의 여러 Skill이 완전히 무관한 소스 자료를 사용하여 자신 있게 질문에 답변하고 있었습니다.

3. Reasoning (추론) — 의사결정 로직이 타당한가?

이 요소는 "추론 (reasoning)"이 모호하기 때문에 테스트하기 가장 어려운 요소입니다. 우리의 접근 방식은 다음과 같습니다. 각 기술 (Skill)에 대해 정답이 알려진 10~20개의 테스트 케이스를 정의하고 통과율을 측정합니다. 또한, 일반적인 추론 오류를 유발하도록 설계된 입력값인 적대적 사례 (adversarial cases) 도 포함합니다.

핵심 통찰: 추론의 품질은 모델이 더 똑똑한가에 달려 있는 것이 아닙니다. 그것은 프롬프트 (prompt), 컨텍스트 (context), 그리고 제약 조건 (constraints)이 함께 작동하는 방식에 달려 있습니다. 적절한 컨텍스트와 함께 잘 구조화된 프롬프트는, 구조가 좋지 않은 더 강력한 모델보다 성능이 낮은 모델을 더 뛰어나게 만들 수 있습니다.

4. Output (출력) — 응답 형식이 신뢰할 수 있는가?

이것은 우리가 발견한 가장 당혹스러운 결과였습니다. 우리는 우리의 기술 (Skills)이 일관된 형식을 반환할 것이라고 가정했습니다. 하지만 그렇지 않았습니다. JSON 필드가 누락되거나, 타입이 문자열 (string)과 숫자 (number) 사이에서 바뀌거나, 마크다운 (markdown)에 코드 펜스 (code fences)가 포함될 때도 있고 포함되지 않을 때도 있었습니다.

이제 모든 기술 (Skill)에는 출력 스키마 테스트 (output schema test) 가 있습니다. 우리는 다양한 입력값으로 기술 (Skill)을 100번 실행하고, 출력의 100%가 선언된 스키마를 준수하는지 확인합니다. 단 한 번이라도 실행에 실패하면, 해당 기술 (Skill)은 출시되지 않습니다.

5. Feedback (피드백) — 시간이 지남에 따른 개선을 측정할 수 있는가?

이 요소는 모든 것을 하나로 묶어주는 요소입니다. 피드백이 없다면 나머지 네 가지 요소는 그저 스냅샷에 불과합니다. 피드백이 있다면, 그것들은 하나의 추세 (trend)가 됩니다.

우리의 피드백 시스템은 다음을 추적합니다:

• 기술별 정확도 (Per-Skill accuracy) 의 시간 경과에 따른 변화 (버전별 테스트 케이스 통과율)
• 실제 사용 패턴 (Real-world usage patterns) (어떤 입력이 가장 흔한지, 사용자가 어디에서 재시도하는지)
• 실패 클러스터링 (Failure clustering) (근본 원인 요소별로 실패를 그룹화)

기술 (Skill)의 새 버전을 배포할 때, 우리는 트리거 (Trigger) 정확도가 올라갔는지 내려갔는지, 검색 (Retrieval)이 개선되었는지, 출력 (Output) 일관성이 유지되었는지를 확인할 수 있습니다. 이것이 _"더 나아진 것 같다"_와 _"X 차원에서 측정 가능할 정도로 더 나아졌다"_의 차이입니다.

이들이 함께 작동하는 방식

이 다섯 가지 요소는 체크리스트가 아니라 하나의 시스템입니다. Trigger (트리거) 실패는 Skill (스킬)이 Retrieve (검색)할 기회조차 얻지 못함을 의미합니다. Retrieval (검색) 실패는 Reasoning (추론)이 잘못된 데이터를 바탕으로 작동함을 의미합니다. Output (출력) 실패는 (다운스트림 시스템이 망가지기 때문에) Feedback (피드백)을 제대로 수집할 수 없음을 의미합니다. Feedback (피드백)은 나머지 네 가지 요소의 개선을 위한 정보를 제공합니다.

이 프레임워크의 가치는 단일 요소에 있는 것이 아닙니다. 그것은 **배포하기 전에 다섯 가지 요소를 모두 점검하는 규율 (discipline)**에 있습니다.

60개의 서버 구축: 실제로 일어난 일

솔직한 타임라인을 공개합니다:

1~4주 차: 시행착오를 통해 첫 10개의 Skill (스킬)을 구축했습니다. 프레임워크도, Eval (평가)도 없었습니다. 그저 느낌(vibes)에 의존했습니다. 그 10개의 Skill 중 약 6개는 몇 주가 지나서야 발견된 심각한 문제들을 안고 있었습니다.

5~8주 차: 분석 단계입니다. 구축을 멈추고 무엇이 고장 났는지 살펴보기 시작했습니다. 이때 100개 이상의 실패한 구현 사례들을 분석하며 프레임워크를 형성하기 시작했습니다. 생산적이었나요? 새로운 Skill (스킬)을 만드는 측면에서는 아니었습니다. 하지만 그 이후의 모든 것을 바꾸어 놓았습니다.

9~16주 차: 프레임워크를 적용하여 재구축했습니다. 처음 만든 10개의 Skill (스킬)로 돌아가 다섯 가지 요소를 모두 적용했습니다. 이는 고통스러운 과정이었습니다. 여러 Skill (스킬)은 단순한 수정이 아니라 근본적인 재설계(redesign)가 필요했습니다.

17~24주 차: 60개 이상의 Skill (스킬)로 확장했습니다. 프레임워크가 갖춰지자 새로운 Skill (스킬)을 구축하는 속도가 빨라졌습니다. 프레임워크가 코드를 대신 작성해주기 때문이 아니라, 언제 작업이 완료되었는지를 알려주기 때문입니다. 각 요소에는 합격/불합격(pass/fail) 임계값이 있습니다. 단순히 "보기 좋아 보일" 때 끝나는 것이 아닙니다. Trigger (트리거) >= 90%, Retrieval (검색) >= 85%, Reasoning (추론) >= 90%, Output (출력) = 100%, 그리고 Feedback (피드백) 연결이 완료되었을 때 비로소 끝나는 것입니다.

주요 실패 지점: 팩트 체크 스킬 (辩真)

우리의 팩트 체크 Skill (스킬)은 초기 테스트 스위트에서 70%의 정확도를 보였습니다. 문제는 추론(reasoning)이 아니라 Retrieval (검색)이었습니다. 해당 Skill (스킬)이 잘못된 소스에서 컨텍스트(context)를 가져오고 있었던 것입니다. Retrieval (검색) 파이프라인을 재구조화하고 (retrieval hit-rate 지표를 추가한) 후, 정확도는 **92%**로 올라갔습니다. 동일한 모델, 동일한 프롬프트 구조였지만, 단지 더 나은 컨텍스트를 제공했을 뿐입니다.

# 이전: 검색(retrieval)이 암시적이었음 — 무엇이든 돌아오면 사용함
def fact_check(claim):
    context = search_web(claim)
...

threshold=0.7과 len(relevant) < 2 체크는 Retrieval (검색) 요소 분석에서 직접 도출되었습니다. 이전에는 Skill (기술)이 관련성이 낮은 단일 소스만을 사용하여 자신 있게 주장을 검증했습니다. 하지만 적용 후에는 충분한 관련 컨텍스트를 찾을 수 없을 때 이를 정직하게 보고하게 되었습니다.

정직한 고충들

• 봇(Bots) vs 실제 트래픽. 초기에는 사용 데이터가 크롤러와 자동화 도구에 의해 지배되었습니다. 노이즈에서 실제 사용 신호를 분리해내는 데 몇 주가 걸렸습니다. 결국 이를 필터링하기 위해 클라이언트 측 행동 신호 (client-side behavioral signals)를 추가했습니다.
• 문서화 부채 (Documentation debt). 60개의 Skill을 구축한다는 것은 60세트의 문서를 만든다는 것을 의미합니다. 우리는 심각하게 뒤처졌습니다. 평가 (eval) 보고서가 이 문제를 부분적으로 해결해 줍니다. 이 보고서들은 각 Skill이 실제로 무엇을 하는지, 그리고 얼마나 잘 수행하는지에 대한 살아있는 문서 역할을 합니다.
• 유지보수 부담. 60개의 Skill은 스스로 유지되지 않습니다. 상위 API (upstream API)가 변경되면 3~4개의 Skill이 동시에 깨질 수 있습니다. Feedback (피드백) 요소가 이를 더 빠르게 포착하는 데 도움을 주지만, 여전히 지속적인 노력이 필요합니다.
• 건너뛰고 싶은 유혹. Skill #45쯤 되었을 때, 우리는 지쳤습니다. 프레임워크가 오버헤드(overhead)처럼 느껴졌습니다. 우리는 전체 평가 (eval) 없이 두 개의 Skill을 출시했습니다. 두 개 모두 일주일 이내에 문제가 발생하며 돌아왔습니다. 프레임워크가 존재하는 이유는 규율을 수동으로 유지하는 것이 어렵기 때문입니다.

배운 점들

가장 놀라웠던 점: 가장 큰 정확도 향상은 더 나은 모델이나 더 나은 프롬프트에서 오지 않았습니다. 그것은 추론 (reasoning) 단계 이전의 요소인 더 나은 Trigger (트리거)와 Retrieval (검색)에서 왔습니다. 우리는 프롬프트를 최적화하는 데 너무 많은 에너지를 쏟느라, 우리의 Skill이 잘못된 입력값 위에서 실행되고 잘못된 컨텍스트를 검색하고 있다는 사실을 놓치고 있었습니다.

빌더들을 위한 조언:

• 피드백부터 시작하세요 (Start with Feedback). 단 한 가지만 측정할 수 있더라도, 그것을 일관되게 측정하세요. 추적할 수 없는 것은 개선할 수 없습니다.
• 첫날부터 "프레임워크 (framework)"를 구축하지 마세요. 5~10개 정도를 먼저 만들어보며 패턴을 파악한 다음, 공식화하세요.
• 출력 품질보다 출력 일관성 (Output consistency)이 더 중요합니다. 95%의 확률로 훌륭한 산문을 반환하지만 5%의 확률로 파이프라인을 망가뜨리는 Skill보다, 85%의 정확도로 항상 유효한 JSON을 반환하는 Skill이 더 유용합니다.

이 프레임워크를 사용할 때 vs. 단순함을 유지할 때: 만약 1~3개의 Skill을 구축하고 있다면, 임시 테스트 (ad-hoc testing)로도 충분합니다. 만약 10개 이상을 구축하고 있다면, 구조의 부재가 발목을 잡을 것입니다. 만약 50개 이상을 구축하고 있다면, 이 프레임워크나 그와 유사한 무언가가 반드시 필요합니다. 50개 Skill의 품질을 머릿속에 다 담아두는 것은 불가능하기 때문입니다.

다음 단계 (What's Next)

우리는 계속해서 공개적으로 구축 (build in public)을 이어가고 있습니다. 모든 Skill에 대한 평가 보고서 (eval reports)를 tancoai.com에서 확인할 수 있으며, 과장 없이 강점과 약점을 모두 보여줍니다. 어떤 Skill이 특정 요소에서 낮은 점수를 받으면 그것이 그대로 드러납니다. 우리가 이를 개선하면 그 추세 또한 명확히 보입니다.

프레임워크 자체는 오픈 소스 (open source)입니다. 이것이 Skill 설계를 생각하는 유일한 방법이라고 주장하는 것은 아닙니다. 하지만 60개 이상의 서버를 구축하며 겪은 시행착오 끝에 우리에게 효과가 있었던 방식입니다.

GitHub: https://github.com/tancoai/lianzhu-skill

이슈 (issues), 토론 (discussions), 그리고 기여 (contributions)를 환영합니다. 만약 여러분도 Skill을 구축하다가 비슷한 벽에 부딪힌 적이 있다면, 여러분의 접근 방식에 대해 듣고 싶습니다. 특히 반대 의견 (Disagreement)을 환영합니다 — 이 프레임워크는 논쟁을 통해 진화해 왔으며, 앞으로도 계속 진화해야 합니다.

라이브 데모 및 평가 대시보드가 포함된 웹사이트: https://tancoai.com