이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
메르카리 NFT 팀은 기존 사내 AI 인프라를 즉시 사용하지 않고 1월 말부터 약 4개월간 AI-Native 개발 방식을 PoC 형태로 재설계했다는 배경을 두고, 하네스 구성요소는 플랫폼에서 점차 표준 부품으로 제공될 가능성이 크므로 hooks·권한·샌드박스 같은 기구는 외부에서 확보하되 어떤 결과를 '정답'으로 볼지, 어떤 출력을 '위험'으로 판단할지는 해당案件에 특화된 판단기준을 팀 내부에서 먼저 수집·정의해야 한다는 핵심 논리를 제시했다. 이 논리는 Mitchell Hashimoto의 'engineer the harness' 명명과 Thoughtworks의 관점을 인용하여 Guide/Guardrail와 Sensor의 역할 분담을 근거로 삼았고, 실행은 CLAUDE.md·rules·skill·hooks 같은 경량 구성으로 빠르게 플랫폼 변화에 대응하면서 판단 기준을 축적하는 방식으로 설계되었다. 결과적으로 팀은 기구는 외부에서 조달하고 판단 기준은 내부에서 유지·확장하는 순서를 택했으며, 이후 축적이 충분해지면 사내 인프라와 양방향으로 통합할 계획이다.
섹션별 상세
프로젝트는 기존의 메르카리 NFT 코드베이스를 기반으로 새로운 서비스를 기획하면서 동시에 AI-Native 개발 방식 자체를 검증하는 PoC 역할을 수행했다. 이 팀은 1월 말부터 약 4개월간 개발 방식을 재구성했고 Merpay & Mercoin Tech Openness Month 2026의 일환으로 결과와 학습을 공유했다. 조직 차원의 AI 인프라가 존재함에도 불구하고 이 실험에서는 의도적으로 그 기반에서 벗어나 전제로부터 재설계하는 접근을 택했다. 이 선택은 플랫폼 의존으로 인해 발생하는 '기성 정답 내 최적화' 한계를 회피하려는 목적이 있었다.
팀은 기능적 기구(mechanism)보다 판단 기준(judgment criteria)에 리소스를 집중하기로 결정했다. 그 근거로 플랫폼이 제공하는 평가 루프·hooks·권한·샌드박스 같은 구성요소는 외부에서 점점 표준 부품으로 제공될 것이며, 실제로 Claude Code 본체에 hooks·권한 제어 기능이 통합되어 가고 있음을 들었다. 반면 어떤 출력이 '정답'인지, 어느 수준을 '합격'으로 볼지, 무엇을 '위험'으로 간주할지는 해당案件(케이스)의 고유한 가치 판단이므로 외주화할 수 없다고 판단했다. 따라서 먼저 판단 기준을 모으고 정리하는 전처리 단계를 거친 뒤, 성숙 시점에 플랫폼과 결합하는 순서를 선택했다.
하네스(harness)는 내부 하네스(Agent SDK 등 모델 공급자 제공)와 외부 하네스로 구분되며 외부 하네스는 Guide/Guardrail(feed-forward)와 Sensor(feedback)로 분해할 수 있다는 관점이 제시되었다. Mitchell Hashimoto의 2026년 2월 블로그에서 'engineer the harness'라는 명명이 확산된 이후로 prompt→context→harness의 계보가 형성되었고, Thoughtworks의 Birgitta Böckeler 관점에서는 가드레일 쪽 논의가 상대적으로 많고 관측(센서) 쪽이 약하다는 지적이 소개되었다. 저자는 이 세 역할(정답 제시·결과 관측·위험 차단)을 동등하게 지지하는 체계를 고민했고, 그 결과 '기구는 사서 쓰고 판단은 자가 보유'라는 구조적 결론을 도출했다.
근거
- 세 가지 하네스 역할(정답 제시·결과 관측·위험 차단)에 대해 기구는 플랫폼에서 제공 가능하지만 판단기준은 각案件 고유이므로 자가 보유해야 한다는 결론이 도출되었다. — 본문 중 '整理すると、三本柱のすべてについて「機構は買える／判断は自前」という構図になります。' 라는 단락
실행 방식은 Claude Code의 경량 구성(CLAUDE.md, rules, skill, hooks)으로 빠르게 변하는 플랫폼 기능을 수용하면서도 판단 기준을 체계적으로 축적하는 형태로 설계되었다. 이 접근법은 플랫폼의 새로운 기능(예: plugin, Agent Teams)을 신속하게 도입할 수 있게 하며 동시에 어떤 요소가 실제로 효과를 내는지 분리하여 평가할 수 있게 한다. 팀은 우선 소규모의 단순한 하네스로 실험을 반복하고, 축적된 판단 기준과 관측 결과를 통해 내부 평가 루프를 강화한 뒤 필요한 시점에 사내 인프라와 통합할 계획을 세웠다.
용어 해설
- 하네스 엔지니어링(Harness Engineering)
- — 하네스 엔지니어링은 모델 주위에 환경·제약·관찰 루프를 설계하여 자동화된 에이전트 동작을 안전하고 예측 가능하게 만드는 접근법으로, prompt engineering과 context engineering에서 발전한 개념이며 플랫폼 수준의 hooks, 권한·샌드박스, 평가루프 같은 구성요소를 포함한다.
- 가이드·가드레일(Guide / Guardrail)
- — Guide/Guardrail는 에이전트가 따를 사전 지침과 금지 규칙을 의미하며 feed-forward 방식으로 모델에 전달되어 의사결정 기준을 보조하고 위험한 동작을 사전 차단하는 역할을 한다.
- 센서(피드백)(Sensor (Feedback))
- — Sensor는 에이전트의 출력을 관측하여 평가·로깅·후속 조치를 유발하는 피드백 계층으로, 결과를 계량화·판정해 평가 루프와 결합하면 모델의 행동을 보정하고 지속적 개선을 가능하게 한다.
- CLAUDE.md
- — CLAUDE.md는 Claude Code 기반 워크플로에서 규칙·스킬·hooks 같은 경량 구성으로 에이전트를 제어하는 문서형·설정형 인터페이스로 본문에서는 외형적 하네스를 최소화한 실험 구성으로 언급되었다.
- Agent SDK
- — Agent SDK는 모델 공급자가 제공하는 내부 하네스 구성요소로서 함수 호출·권한·플러그인 연동과 같은 런타임 기능을 제공하며 외측 하네스와 결합되어 에이전트 동작을 실행하는 기초 계층이다.
기술
- Claude Code
- CLAUDE.md
- Agent SDK
- hooks
활용 사례
- AI-Native 개발 PoC
- 서비스 개발의 자동화 지향 워크플로
- 판단기준 수집 및 평가 루프 구축
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 06. 30.수집 2026. 06. 30.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
