아무도 쓰지 않는 정직한 AI 도구 평가 프레임워크

지난 10월, 저는 세 개의 모니터에서 14개의 AI 도구를 동시에 실행하고 있었습니다. 코딩을 위한 Cursor, 추론을 위한 Claude.ai, 리서치를 위한 Perplexity, 문서 작성을 위한 Notion AI, 제가 직접 만든 커스텀 GPT-4 래퍼(wrapper), 그리고 "평가" 중이었던 나머지 9개의 도구들 말입니다. 저의 월간 AI 지출은 400달러를 넘어섰습니다. 하지만 실제 생산량은 도구를 두 개만 사용할 때보다 더 나빠졌습니다. 저는 커버리지(coverage)를 최적화하려다 마비 상태에 빠진 것입니다. 그 당혹스러웠던 한 달을 계기로, 저는 리스트 형식의 글이 아니라, 무언가를 거절할 수 있게 만들어주는 실제적인 AI 도구 평가 프레임워크를 구축해야만 했습니다.

진짜 비용은 구독료가 아니라 인지적 오버헤드(Cognitive Overhead)입니다

제가 읽어본 모든 AI 도구 평가들은 벤치마크(benchmarks), 가격 체계, 그리고 기능 체크리스트에만 집중합니다. 그것은 잘못된 분석 단위입니다. 올바른 단위는 다음과 같습니다: 이 도구가 사용 시간당 얼마나 많은 정신적 RAM을 소모하는가?

월 20달러의 비용이 들지만, 컨텍스트 스위칭(context-switch)을 요구하거나, 프로젝트를 다시 설명해야 하거나, 코드베이스를 다시 붙여넣어야 하거나, 도구의 출력을 실제 워크플로우로 정신적 번역을 해야 하는 도구는 20달러짜리 도구가 아닙니다. 그것은 숨겨진 오버헤드로 매 세션마다 조용히 세금을 징수하고 있는 도구입니다. 10월의 스택(stack)을 감사했을 때, 저는 도구 관리(탭 열기, 도구 간 출력 복사, 컨텍스트 유실로 인한 재프롬프팅 등)에 하루 약 40분을 쓰고 있다는 것을 발견했습니다. 이는 아무런 결과물도 만들어내지 못한 채 한 달에 14시간을 허비했다는 뜻입니다.

어떤 정직한 평가에서든 첫 번째 질문은 다음과 같아야 합니다: 재진입 비용(re-entry cost)은 얼마인가? 도구를 아무 준비 없이 열어보십시오. 실제 업무를 시작하기까지 얼마나 걸립니까? 만약 그 답이 90초 이상이라면, 매일 세금을 내고 있는 것입니다.

컨텍스트 지속성(Context Persistence)은 아무도 벤치마크하지 않는 기능입니다

벤치마크 사이트들은 어떤 모델이 MMLU, HumanEval, 또는 MATH에서 가장 높은 점수를 받았는지 알려줄 것입니다. 하지만 그 숫자들은 지속적이고 복잡한 업무에 해당 도구가 얼마나 유용한지에 대해서는 거의 아무것도 알려주지 않습니다. 그들이 결코 측정하지 않는 것은, 도구가 당신이 무엇을 하고 있었는지를 기억하느냐 하는 점입니다.

문맥 지속성 (Context persistence)에는 대부분의 평가 방식이 하나로 뭉뚱그려 버리는 세 가지 계층이 있습니다.

세션 문맥 (Session context) — 도구가 다섯 메시지 전의 대화를 기억하나요, 아니면 모순된 내용을 환각 (hallucinate) 하나요? 대부분의 도구는 이 단계를 통과합니다.

프로젝트 문맥 (Project context) — 도구가 당신의 API가 camelCase를 사용한다는 점, 특정 에러 처리 패턴을 가지고 있다는 점, 사용자 엔티티 (user entity)가 특정한 형태를 가진다는 점을 알고 있나요? 소비자용 AI 도구 중 이를 기본적으로 처리하는 도구는 거의 없습니다. 매 세션마다 이를 붙여넣거나, 메모리/RAG (Retrieval-Augmented Generation) 계층이 내장된 도구를 사용해야 합니다.

워크플로우 문맥 (Workflow context) — 도구가 실제 프로세스 내에서 자신이 어디에 위치해 있는지 이해하고 있나요? 자신의 출력이 코드 리뷰로 가는지, 문서로 가는지, 아니면 체인 (chain) 내의 다음 프롬프트로 이어지는지 알고 있나요? 이 기능을 기본적으로 제공하는 도구는 전무합니다. 직접 구축하거나, 아니면 포기해야 합니다.

새로운 도구를 평가할 때, 저는 이제 의도적으로 3회 세션 테스트를 수행합니다. 세션 1: 특정 제약 조건이 있는 프로젝트를 소개합니다. 세션 2 (다음 날): 도구를 아무런 사전 정보 없이 열고, 세션 1의 내용을 기억해야만 답변할 수 있는 후속 질문을 던집니다. 세션 3: 부분적으로 완료된 작업을 넘겨봅니다. 대부분의 도구는 세션 2에서 완전히 실패합니다. 세션 2를 통과하더라도 거의 대부분 세션 3에서 실패합니다. 이러한 실패 패턴은 당신의 수동 재입력 비용 (manual re-entry cost)이 정확히 어디에서 발생할지를 알려줍니다.

출력 충실도 (Output Fidelity)가 출력량보다 중요하다

AI 파워 유저들이 빠르게 빠지게 되는 병리적 현상 중 하나는 장황함 (verbosity)을 품질로 착각하는 것입니다. 당신에게 200단어가 필요한 상황에서 800단어를 쓰는 모델은 당신을 도와준 것이 아니라, 편집 업무를 떠안긴 것입니다. 작동하는 함수와 함께, 당신이 즉시 삭제할 12줄의 설명 주석을 생성하는 코딩 어시스턴트는 한계 효용 측면에서 당신의 시간을 절약해주지 못합니다.

출력 충실도 (Output fidelity)란 다음을 의미합니다: 도구가 매 세션마다 그렇게 하도록 별도로 학습시키지 않아도, 당신의 워크플로우가 실제로 요구하는 형식, 길이, 구체성을 갖춘 출력을 생성하는가?

제가 **사용 가능성까지의 차이 (delta-to-usable)**라고 부르는 지표를 측정하여 이를 테스트해 보세요. 가공되지 않은 출력물 (raw output)을 가져와서, 실제 문맥에서 사용 가능해지기 전까지 얼마나 많은 편집 작업이 필요한지 측정하는 것입니다. "정답이 되기 전"이 아니라, "사용 가능해지기 전"을 기준으로 삼으세요. 기술적으로는 정답일지라도 형식이 틀렸거나, 잘못된 가정을 포함하고 있거나, 부적절한 추상화 수준 (abstraction level)을 대상으로 한다면, 여전히 높은 '사용 가능성까지의 차이 (delta-to-usable)' 점수를 갖게 됩니다.

'사용 가능성까지의 차이 (delta-to-usable)' 점수가 낮은 도구들은 하나의 패턴을 공유합니다. 매우 특화되어 있거나 (한 가지 일을 반복적으로 수행하여 형식을 학습함), 명시적인 시스템 프롬프트 (system prompts) 하에서 강력한 지시 이행 (instruction-following) 능력을 갖추고 있습니다. 지속적인 지시 사항이 없는 범용 채팅 인터페이스 (General-purpose chat interfaces)는 기반 모델 (underlying model)의 품질과 관계없이 거의 항상 높은 '사용 가능성까지의 차이 (delta-to-usable)' 점수를 기록합니다.

통합 깊이 (Integration Depth)가 도구가 당신과 함께 확장될지를 결정한다

데모 단계에서는 사랑했지만 3주 이내에 버려버린 AI 도구들의 무덤이 있습니다. 그 패턴은 거의 항상 동일합니다. 도구가 단독 결과물 (standalone artifact)로서는 훌륭하게 작동하지만, 제가 실제로 사용하는 그 어떤 것과도 연결되지 않는다는 점입니다. 새로움의 단계 (novelty phase)가 지나면, 저는 그 결과물이 제 에디터, 작업 관리자, 코드베이스, 문서에 담기기를 원하게 됩니다. 매번 수동으로 그것들을 옮겨야 한다면, 그 도구는 레버리지 (leverage)처럼 느껴지지 않고 추가적인 업무처럼 느껴지기 시작합니다.

통합 깊이 (Integration depth)는 Zapier 커넥터를 갖추는 것에 관한 것이 아닙니다. Zapier 커넥터는 임시방편 (duct tape)일 뿐입니다. 진정한 통합 깊이란, 당신이 그들 사이에서 인간 API 역할을 수행하지 않고도, 도구가 당신의 환경으로부터 구조화된 문맥 (structured context)을 전달받고 다시 구조화된 출력 (structured output)을 돌려줄 수 있음을 의미합니다.

통합 (integration)을 평가할 때, 저는 세 가지를 확인합니다. 사용 가능한 API (단순한 REST 엔드포인트가 아니라, 연결하는 데 30분이 채 걸리지 않는 개발자 경험 (developer experience)), 이벤트 기반 훅 (event-driven hooks, 도구가 내 환경의 상태 변화를 트리거하거나 상태 변화에 의해 트리거될 수 있는가?), 그리고 출력 스키마 제어 (output schema control, 출력의 형태를 정확하게 정의할 수 있는가?). 이 세 가지를 모두 충족하는 도구는 이를 중심으로 구축해 나감에 따라 가치가 복리로 증가합니다. 반면, 세 가지 중 어느 것도 충족하지 못하는 도구는 기반 모델 (underlying model)이 아무리 훌륭하더라도 생산성 장난감에 불과합니다.

해자 (Moat) 문제: 모델이 더 저렴해지면 어떻게 되는가?

이것은 새로운 도구를 처음 접하는 달콤한 시기(honeymoon phase)에는 아무도 묻지 않지만, 장기적인 가치를 결정짓는 평가 질문입니다. 모든 AI 도구는 모델 위에 쌓인 하나의 레이어 (layer)입니다. 모델은 점점 더 짧아지는 타임라인 속에서 더 저렴해지고 더 강력해지고 있습니다. 도구가 가진 해자는 모델을 제외한 모든 것입니다. 즉, 도구가 보유한 당신에 대한 데이터, 구축된 통합 (integrations), 생성된 워크플로 기본 요소 (workflow primitives), 그리고 축적된 전환 비용 (switching cost)입니다.

도구에서 모델을 제거하고 "내가 비용을 지불할 만한 남은 것이 무엇인가?"라고 질문해 보면, 그 가치가 얼마나 지속 가능한지 명확한 그림을 얻을 수 있습니다. 대부분의 도구에 대한 정직한 답변은 다음과 같습니다: 별로 없습니다. 채팅 인터페이스 자체는 해자가 아닙니다. 예쁜 UI도 해자가 아닙니다. 해자가 되는 것은 축적된 문맥 (accumulated context), 당신의 환경과의 긴밀한 통합, 그리고 다시 구축하는 데 실제 시간이 걸리는 워크플로 자동화 (workflow automation)입니다.

이것은 단순히 벤더 (vendor) 분석 문제가 아닙니다. 당신의 워크플로 투자를 위한 '자체 구축 대 구매 (build-vs-buy)' 문제입니다. 데이터 해자가 없는 도구를 설정하는 데 쓰는 시간은 도구를 바꿀 때 다시 쓰게 될 시간입니다. 강력한 문맥 지속성 (context persistence)과 API 깊이를 가진 도구를 중심으로 구축하는 데 쓰는 시간은 복리로 쌓입니다.

평가 프레임워크 (The Evaluation Framework)

어떤 AI 도구를 도입하기 전에 다음을 사용하십시오:

재진입 비용 (Re-entry cost) — 도구를 콜드 스타트 (cold-start) 해보십시오. 도구를 연 시점부터 첫 번째 유용한 출력이 나오기까지의 시간입니다. 실패 임계값: >90초.

컨텍스트 지속성 테스트 (Context persistence test) — 3단계 세션 프로토콜(도입, 후속 콜드 스타트, 부분적 작업 인계)을 수행합니다. 세션 2를 통과해야 합격입니다.

사용 가능 수준까지의 차이 점수 (Delta-to-usable score) — 대표적인 출력물 3개를 선정합니다. 이를 실제 사용 가능한 수준(production-ready)으로 편집하는 데 소요되는 시간을 추정합니다. 실패 임계값: 평균 >15분.

통합 깊이 점수 (Integration depth score) — API 품질, 이벤트 훅 (event hooks), 출력 스키마 (output schema) 제어 능력을 평가합니다. 점수는 0~3점 사이로 매깁니다. 2점 미만일 경우, 단독 도구 (standalone tool)로만 취급합니다.

해자 감사 (Moat audit) — 모델을 제거해 보십시오. 무엇이 남습니까? 만약 답변이 "주말 동안 직접 다시 만들 수 있는 것 외에는 없다"라면, 그에 맞춰 도구의 가중치를 조정하십시오.

총 소유 비용 (Total cost of ownership) — 구독료 + 월간 인지적 오버헤드 시간 × 시간당 급여. 대부분의 도구는 이 계산법을 적용할 때 비싸집니다.

AI Handler가 이 문제에 접근하는 방식

제가 평가하는 모든 도구가 저의 프레임워크를 통과하지 못하는 것을 보며 AI Handler를 만들었습니다. 재진입 비용 (re-entry cost)이 너무 높았습니다. 세션 사이에 컨텍스트 (context)가 증발했습니다. 출력물을 다듬는 데 너무 많은 작업이 필요했습니다. 그 무엇도 서로 연결되어 있지 않았습니다.

AI Handler는 지속적인 프로젝트 컨텍스트(대화 메모리가 아닌, 세션을 통과하며 시간이 지남에 따라 더 똑똑해지는 프로젝트 메모리), Delta-to-usable 점수를 낮게 유지할 수 있도록 구성 가능한 스키마를 갖춘 구조화된 출력 (structured output), 그리고 개발자들이 실제로 사용하는 도구들과의 네이티브 통합 깊이를 중심으로 설계되었습니다. 이는 단순히 더 나은 모델을 탑재한 또 다른 채팅 인터페이스가 아니라, 통합된 AI 워크플로우 레이어 (unified AI workflow layer)입니다.

이 프레임워크에서 설명한 모든 것은 이 제품이 구축될 때 준수해야 하는 설계 제약 조건입니다. 저는 매일 제 자신의 업무에 이 프레임워크를 적용하고 있으며, 이는 제가 결정을 검증하거나 그 결과를 직접 체감하고 있음을 의미합니다. 실제로 사용하는 도구로부터는 결코 숨을 수 없습니다.

AI Handler는 제가 만들고 있는 통합 AI 워크플로우 도구입니다. 2026년 6월 출시 예정입니다. 베타 액세스 권한을 원하시면 **ceo@eternalsix.com**으로 이메일을 보내주세요.