Skills가 호출되는 원리(feat claude)

요즘 핫한 Skills. 도대체 어떤 로직으로 작동하는 것일까? 궁금해서 알아보고 정리한다.

 

우선 내가 아는 바로는 system promt에 agent가 가지고 있는 skill내용이 모두 들어간다.
물론, name과 description만. 근데 agent가 판단해서 어떤 스킬은 전문을 context안에 들어간다.

이 이야기는 LLM이 호출되고, 응답하는 것이 아니라 다시 context가 업데이트 된다는 이야기. 그 원리를 알아보자.

 

[워드 문서를 만드는 skill호출 시 프로세스]

별도의 분류기나 라우터가 없습니다. Skill을 로드할지 판단하는 것도, 실제로 view 도구를 호출하는 것도 전부 LLM 자신이에요.

사용자가 "Word 문서 만들어줘"를 보내면, LLM의 첫 번째 출력이 텍스트가 아니라 view SKILL.md tool_use입니다. Harness가 이걸 실행해서 결과를 돌려주면, 그제야 LLM이 SKILL.md 내용을 보고 실제 작업을 시작해요.

사용자가 한 번 메시지를 보내면 뒤에서 LLM API가 5~6번 연쇄 호출됩니다. LLM이 tool_use를 출력하면 → Harness가 실행 → 결과를 context에 추가 → LLM을 다시 호출. LLM이 텍스트만 출력하고 tool_use를 안 내보내면 루프가 끝납니다. 이게 Agentic loop의 종료 조건이에요.

그래서 역할 분담이 명확합니다: LLM = 의사결정자 (뭘 할지 판단), Harness = 실행자 (판단을 실행하고 결과를 돌려줌). Harness는 절대 "뭘 로드할지"를 스스로 결정하지 않아요.

 

위 말을 이해하기 쉽도록 langgraph의 그래프로 정리해보자.

왼쪽의 **보라색 세로선 "AGENTIC LOOP"**가 핵심 — inject_result가 다시 call_llm으로 돌아가는 순환 엣지입니다. LLM이 tool_use를 안 내보낼 때까지 이 루프가 계속 돕니다.

pre_tool_hook에서 deny되면 점선으로 call_llm에 바로 돌아가는 것도 보이시죠. Hook이 차단하면 도구 실행 없이 "거부됨" 결과만 context에 들어가서 LLM이 다시 판단합니다.

 

langgraph로 만들던 기초 Agent 크게 다르지 않은 구조이다.

핵심은 간단, LLM이 판단해서, context를 업데이트. 응답은 조건이 충족되었을때 실행.