스킬의 끝은 스크립트인가 — 하네스 엔지니어링에서 스크립트는 '지능을 파낸 빈자리'다

AI에게 어떤 일을 자동으로 시키는 작업을 하다 보면, 거의 항상 전용 스크립트가 하나씩 떨어진다. 특정 파이프라인을 돌리는 스킬을 만들고 있으면, 그 안에서 결국 그 파이프라인만을 위한 스크립트를 짜게 된다. 그래서 최근에 누군가에게 하네스 엔지니어링이라는 개념을 설명하던 중에 이런 질문을 받았다.

"그러면 스킬의 끝은 결국 스크립트 아니에요? 스킬을 잘 만들면 만들수록 스크립트가 완성되는 거고, 그 스크립트가 나오면 스킬의 역할은 끝나는 거잖아요."

좋은 문제 제기이다. 그 자리에서 "그건 아니다, 스킬은 스크립트 앞뒤로 벌어지는 일까지 포괄한다"고 정리되었는데, 끝나고 나니 핵심을 제대로 못 박은 느낌이 들었다. 답은 맞았지만 왜 그런지를 한 문장으로 못 박지 못했다. 이 글은 그 못다 한 설명을 다이어그램으로 정리한 것이다.

결론부터 한 문장으로 박아 두면 이렇다.

스크립트는 "이미 풀린 문제를 고정한 것"이고, 스킬은 "문제를 푸는 행위 전체를 소유한 것"이다. 그래서 스크립트는 스킬이 만들어내는 부산물이지 목적지가 아니다.

먼저 용어 정리 — 하네스 엔지니어링과 스킬

본론 전에 두 단어를 풀어 둔다. 도메인 밖 독자가 이 둘을 모르면 나머지가 통째로 막히기 때문이다.

하네스(harness) 엔지니어링은, LLM(Large Language Model, 대규모 언어 모델)을 한가운데 두고 그 주위에 가드레일·재시도·검증 같은 통제 장치를 짜 넣어 "혼자 두면 들쭉날쭉한 모델"을 "믿고 맡길 수 있는 일꾼"으로 만드는 설계 작업이다. 말(馬)에 마구(harness)를 채워 마차를 끌게 하는 것에 비유하면 된다 — 말의 힘(LLM의 생성 능력)은 그대로 두되, 가고 싶은 방향으로만 가도록 묶는다. 여기서 주된 행위자(main actor)는 어디까지나 LLM이고, 코드는 그 LLM을 감싸 보조한다. (참고로 LLM을 보조하는 이 구조를 "하네스"라 부르고, 사람의 개입 없이 스스로 판단하고 행동하는 자율 행위자를 "에이전트"라 부른다 — 둘은 통제의 주체가 다르다.)

스킬(skill)은 그 하네스를 특정 작업에 맞춰 묶어 둔 "재사용 가능한 일 처리 묶음"이다. 절차서(이 일은 어떤 순서로, 무엇을 보고 하는지) + LLM의 판단 + 필요하면 호출하는 스크립트가 한 덩어리로 들어 있다. "캘린더를 정리해 줘" 한마디에 알아서 일을 끝내는 것이 스킬이다.

1. 질문자의 머릿속 그림 — 일직선 모델

질문자가 그린 그림은 이랬다. 스킬은 스크립트를 만들어내는 도구이고, 스크립트가 완성되면 임무가 끝난다는 일직선이다.

다이어그램 설명. 질문자의 모델을 그대로 그린 것이다. 핵심 메시지는 "스킬은 스크립트를 뽑아내기 위한 거푸집이고, 스크립트가 나오면 거푸집은 버려진다"는 일직선 인과다. 이 그림이 자연스러워 보이는 이유가 있다 — 실제로 스킬을 만들다 보면 손에 잡히는 산출물이 스크립트 한 개라서, 그게 결과물의 전부처럼 느껴진다. 함정은 이 그림에 "스크립트를 돌리기 전에 무엇을 판단했는가"와 "스크립트가 끝난 뒤 그 결과로 무엇을 하는가"가 통째로 빠져 있다는 점이다. 그 빠진 부분이 사실 스킬의 본체다.

2. 실제 그림 — 스크립트는 가운데 끼인 한 토막

실제 스킬은 일직선이 아니라, 스크립트를 가운데에 끼워 넣은 더 큰 루프다.

다이어그램 설명. 같은 작업을 실제 동작 순서대로 그린 것이다. 읽는 순서는 위에서 아래, 그리고 막히면 결과를 판단하는 마지막 단계에서 첫 판단 단계로 화살표가 되돌아간다. 스크립트를 실행하는 칸은 흐름의 한가운데 한 토막일 뿐이고, 그 앞에서 "무엇을·어떻게·지금 할까"를 정하는 판단과 그 뒤에서 "결과 해석·예외 처리·다음 행동"을 정하는 판단에 인간이 하던 일이 그대로 남아 있다. 일직선 모델과의 결정적 차이는 결과를 판단하는 단계에서 다시 처음 판단으로 돌아가는 화살표다 — 결과가 이상하면 다시 판단해서 다른 파라미터로 스크립트를 또 돌린다. 일직선에는 이 되먹임(feedback)이 없다. 질문자가 본 것은 이 그림에서 스크립트를 실행하는 한 칸뿐이었고, 그 칸을 둘러싼 판단 단계들을 못 본 것이다.

3. 스킬을 해부하면 세 개의 층이 나온다

왜 스크립트가 한 토막에 불과한지를 더 정확히 보려면, 스킬이 인간이 하던 일을 세 종류로 쪼개 각각 다른 것으로 대체한 묶음이라는 점을 봐야 한다.

다이어그램 설명. 스킬 내부를 세 층으로 분해한 그림이다. 핵심 메시지는 "스킬은 한 덩어리가 아니라, 인간 노동의 세 가지 다른 측면을 각각 대체한 합본"이라는 것이다. 반복 노동은 스크립트로, 판단력은 LLM으로, 전문성·순서 감각은 절차서로 대체된다. 화살표를 보면 절차서가 LLM을 지휘하고, LLM이 필요할 때만 스크립트를 호출하며, 스크립트 결과는 다시 LLM에게 돌아간다. 즉 스크립트는 LLM의 손발이지 머리가 아니다. 질문자는 이 셋 중 스크립트만 보고 "그게 끝 아니냐"고 한 것인데, 절차서와 LLM 판단이 빠지면 그건 스킬이 아니라 그냥 정해진 시각에 실행되는 스크립트일 뿐이다.

4. 지능은 어디로 갔나 — 스크립트의 "앞뒤"로 밀려난다

여기가 이 글에서 가장 중요한 대목이다. 스킬을 만든다고 지능이 사라지는 게 아니다. 지능은 결정적 코어(스크립트) 바깥, 즉 앞과 뒤로 밀려날 뿐이다.

다이어그램 설명. 한 작업을 "스크립트 전 / 스크립트 / 스크립트 후" 세 구간으로 가른 그림이다. 가운데 스크립트는 입력만 정해지면 항상 같은 출력을 내는 결정적(deterministic) 코어라서 지능이 필요 없다 — 오히려 여기에 LLM의 비결정성이 끼어들면 매번 결과가 달라져 해롭다. 반면 양쪽 구간은 본질적으로 애매하다. 스크립트 전 단계에서는 입력이 지저분하게 들어오고, 스크립트 후 단계에서는 세상이 예외를 던지고 결과를 누군가 해석해야 한다. 핵심 결론은 "지능은 없어진 게 아니라 결정적 코어의 가장자리로 밀려났다"는 것. 질문자가 본 스크립트는 정확히 이 그림 한가운데 박스 하나였고, 그 위아래의 판단 영역 두 개를 못 본 셈이다. 놓치기 쉬운 함정은 "스크립트가 잘 짜이면 양쪽 판단도 줄어들 것"이라는 기대인데, 실제로는 반대다 — 결정적인 부분을 스크립트로 떼어낼수록, 남는 것은 점점 더 "판단할 수밖에 없는 것"만 농축된다. 그 이유를 다음 그림에서 본다.

5. 스크립트는 어떻게 생겨나는가 — "동결"의 과정

스크립트는 처음부터 목표였던 적이 없다. 작업을 LLM에게 시키다 보면 "이 부분은 매번 똑같네"라는 조각이 눈에 띄고, 그 조각만 떼어 코드로 굳히는(freeze) 것이 스크립트다.

다이어그램 설명. 스크립트가 태어나는 과정을 시간순으로 그린 것이다. 출발점은 작업 전체를 LLM이 매번 판단으로 처리하는 상태 — 가장 유연하지만 느리고 비싸고 불안정하다. 진행하면서 "여기는 항상 같은 절차로 흘러간다"는 결정적 조각을 발견하면, 그 부분만 스크립트로 굳힌다. 그러면 남는 것은 정의상 "굳힐 수 없어서 남은 것", 즉 판단이 대체 불가능한 핵이다. 그리고 이 과정은 한 번으로 끝나지 않고, 남은 핵에서 다시 새로 굳힐 조각을 찾아 처음으로 돌아가는 루프를 돈다 — 작업을 더 하다 보면 또 굳힐 조각이 보인다. 여기서 짚을 점은, 스크립트로 떼어내는 기준 자체가 "여기엔 LLM 판단이 아무 가치를 더하지 않고 비용·위험·들쭉날쭉함만 더한다"는 것이라는 사실이다. 그러니 떼어내고 남는 부분은 논리적으로 반드시 "판단이 필요한 부분"일 수밖에 없다.

6. 그래서 스크립트는 "지능을 파낸 빈자리"다

앞 그림의 결론을 비유 하나로 못 박아 보자. 조각(彫刻)에는 두 방식이 있다. 돌을 깎아 형상을 튀어나오게 만드는 양각(陽刻)과, 반대로 형상 부분을 파내어 움푹 들어가게 만드는 음각(陰刻)이다. 스크립트는 작업에서 지능을 파내고 남은 음각이다 — 여기서는 이 표현을 비유로 쓴다.

다이어그램 설명. 음각 비유를 구조로 그린 것이다. 작업 전체에서 결정적인 부분을 파내면, 손에 잡히는 조각(스크립트)과 파낸 자리(판단의 핵)가 동시에 생긴다. 질문자는 손에 잡히는 조각을 가리키며 "이게 결과물 아니냐"고 했지만, 스킬이 진짜로 다루는 것은 그 옆의 빈자리, 즉 판단의 핵이다. 비유를 끝까지 밀면 이렇다 — "스킬의 끝은 스크립트냐"는 질문은, 조각가에게 "조각의 완성은 깎아내서 바닥에 떨어진 돌가루냐"고 묻는 것과 같다. 돌가루(스크립트)는 작업의 부산물이고, 작품은 그것을 파내고 드러난 형상(판단 구조) 쪽이다.

7. 판별 기준 — 끝이 스크립트인 작업 vs 끝이 스킬인 작업

그러면 "끝이 정말 스크립트인 작업"은 아예 없는가? 있다. 다만 그런 작업은 애초에 스킬로 만들 필요가 없는 작업이다. 이 구분이 질문자에게 줄 수 있는 가장 실용적인 판별 기준이다. 비교를 위해 두 경우를 따로 그린다.

▲ 닫힌 작업 — 끝이 스크립트인 경우

▲ 열린 작업 — 끝이 스킬인 경우

두 다이어그램 설명. 같은 질문(가장자리가 결정적인가?)에서 갈라지는 두 갈래를 위아래로 나눠 그렸다. 위쪽 닫힌 작업은 입력·예외·결과 해석이 전부 미리 정해져 있어 판단할 게 없다 — 로그 회전처럼. 이런 건 예약 실행 한 줄과 스크립트면 충분하고, 굳이 스킬로 감쌀 이유가 없다. 아래쪽 열린 작업은 가장자리가 애매해서, 입력을 해석하고 예외를 수습하고 결과를 판단하는 일이 남는다 — 여기서만 스킬이 의미를 갖고, 스크립트는 그 안의 부품이 된다. 여기서 한 번 더 꼬는 결론이 나온다. "우리가 어떤 작업을 굳이 스킬로 만들고 있다"는 사실 자체가, 그 작업의 가장자리에 판단이 남아 있다는 증거다. 닫힌 작업이었다면 애초에 스크립트만 짜고 끝냈을 테니까. 즉 "스킬로 만드는 중"이라면 답은 이미 "끝은 스크립트가 아니다"로 정해져 있다.

8. 비유로 마무리 — 조종사와 오토파일럿

마지막으로 이 관계를 가장 직관적으로 보여주는 비유 하나. 비행기의 조종사와 오토파일럿(autopilot, 자동 비행 장치) 관계가 스킬과 스크립트의 관계와 똑같다.

다이어그램 설명. 한 번의 비행을 스킬-스크립트 구조에 대입한 그림이다. 오토파일럿(스크립트)은 지루하고 결정적인 순항 구간을 대신 맡는다 — 항로가 정해지면 같은 입력에 같은 동작을 반복하는, 사람이 굳이 손댈 이유가 없는 부분이다. 하지만 이륙·착륙처럼 변수가 많은 국면과, 난기류 같은 예외 상황에서는 통제가 다시 조종사(판단)에게 돌아온다. 누구도 "오토파일럿이 있으니 조종사는 필요 없다"거나 "비행의 끝은 오토파일럿이다"라고 말하지 않는다. 오토파일럿은 조종사가 비행을 더 잘 수행하기 위한 도구일 뿐, 비행의 주체는 끝까지 조종사다. 스크립트와 스킬의 관계가 정확히 이것이다.

그래서, 질문에 다시 답하면

"스킬의 끝은 스크립트인가?" — 아니다. 그리고 그 이유는 "스킬이 스크립트보다 뭔가 더 많은 일을 하기 때문"이라는 양적인 설명보다, 구조적인 설명이 더 정확하다.

• 스크립트는 작업에서 "이미 풀려서 굳힐 수 있는 부분"만 떼어낸 음각이다. 떼어내는 기준이 "여기엔 판단이 불필요하다"이므로, 떼어내고 남는 것은 정의상 "판단이 대체 불가능한 핵"이다.
• 지능은 스킬을 만든다고 사라지지 않고, 결정적 코어의 앞뒤로 밀려난다. 요청 해석·실행 여부 판단(앞)과 결과 해석·예외 수습·다음 행동(뒤)이 스킬의 본체다.
• "스킬로 만들고 있다"는 사실 자체가 답을 정해 준다. 가장자리가 완전히 결정적인 닫힌 작업이었다면 스크립트만 짜고 끝냈을 것이다. 굳이 스킬로 감쌌다면, 그 작업엔 스크립트로 굳힐 수 없는 판단이 남아 있다는 뜻이다.

스크립트는 스킬의 목적지가 아니라, 스킬이 일하면서 떨어뜨리는 부산물이다. 조각가가 형상을 드러내며 떨어뜨린 돌가루처럼. 우리가 정말 만들고 있는 것은 그 돌가루가 아니라, 그것을 파내고 드러난 판단의 형상 — 즉 "이 일을 어떻게 판단하며 끝까지 끌고 갈 것인가"라는 구조 그 자체다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.