메타는 끝이 없지 않다

이 글은 오늘 음성 메모에서 시작했다. 말하면서 정리해보니, 내가 요즘 Hermes와 콜바를 굴리면서 계속 만지는 것이 전부 같은 방향을 향하고 있었다. 스킬, 프롬프트, evaluation, 런타임 QA. 이름은 다르지만 결국 내가 일을 어떻게 시키고, 무엇을 좋은 결과라고 부르며, 그 기준을 어떻게 반복 가능하게 남기는지에 대한 문제였다.

요즘 내가 가장 많이 생각하는 단어는 메타다.

메타인지, 메타 프롬프팅, 메타 evaluation. 이름은 조금씩 다른데 결국 같은 방향을 가리킨다. 내가 지금 무엇을 하고 있는지, 그 일을 어떤 기준으로 시키고 있는지, 그 기준 자체가 맞는지 다시 보는 일이다.

1. 처음에는 결과물만 본다

AI를 쓰기 시작하면 처음에는 대부분 결과물에 집중한다. 글을 써달라고 한다. 코드를 짜달라고 한다. 고객에게 전화하는 스크립트를 만들어달라고 한다. 결과가 마음에 들면 잘 썼다고 생각하고, 마음에 들지 않으면 프롬프트를 고친다.

이 단계에서는 질문이 단순하다.

“어떻게 말하면 더 잘 나오지?”

나도 오래 그렇게 썼다. 그런데 실제 제품과 운영에 AI를 넣기 시작하면 이 질문만으로는 부족해진다. 콜바 데모랩을 만든다고 해보자. 여기서 내가 진짜로 원하는 것은 예쁜 페이지 하나가 아니다. 고객에게 보여주고 싶은 설득 구조가 살아 있어야 하고, 전화 AI라는 제품의 감각을 해치지 않아야 하며, 데모로 검증 가능한 형태가 되어야 한다. 페이지가 나왔는지보다 중요한 것은 그 페이지가 어떤 판단 기준을 따라 만들어졌는가다.

그때부터 중요한 것은 결과물이 아니라, 결과물이 만들어지는 방식이 된다.

2. 스킬은 메타 프롬프팅이다

나는 요즘 스킬을 많이 쓴다. Hermes에 스킬을 쌓아두고, MCP도 붙이고, 에이전트도 돌린다. 겉으로 보면 그냥 AI에게 일을 시키는 것처럼 보인다. 하지만 실제로 내가 하고 있는 건 그보다 한 층 위의 작업이다.

스킬은 사실상 메타 프롬프팅이다.

일반 프롬프트는 “이 일을 해줘”에 가깝다. 스킬은 “이런 종류의 일을 할 때는 이렇게 생각하고, 이런 순서로 확인하고, 이런 실수를 조심하고, 이 정도 품질이 아니면 끝났다고 말하지 말라”에 가깝다. 프롬프트가 한 번의 요청이라면, 스킬은 요청을 해석하는 방식 자체를 설계하는 일이다.

그래서 좋은 스킬은 범용적이되, 정답은 아니다. 같은 스킬이라도 누가 쓰는지, 어떤 제품을 만들고 있는지, 무엇을 성공이라고 부르는지에 따라 완전히 다르게 작동한다.

이 차이를 표로 쓰면 이렇게 된다.

이 표의 핵심은 도구 이름이 아니다. 내가 AI에게 “무엇을 하라”고 말하는 데서 끝나지 않고, “무엇을 좋은 일 처리라고 볼 것인가”를 같이 넘기고 있다는 점이다.

3. Evaluation은 항목보다 순서를 본다

여기서 한 번 더 올라간다. 만든 결과물을 평가하는 기준도 다시 프롬프트로 만든다.

예를 들어 어떤 에이전트가 고객 응대 스크립트를 만들었다고 하자. 평가 기준이 “A, B, C, D를 말했는가”라면 겉으로는 쉬워 보인다. 하지만 실제 고객 대화에서는 A, B, C, D를 다 말하는 것보다 순서가 더 중요할 때가 많다.

먼저 공감해야 하는지, 먼저 가격을 말해야 하는지, 먼저 고객의 상황을 좁혀야 하는지에 따라 같은 문장도 완전히 다른 결과를 만든다.

그러면 evaluation은 단순 체크리스트가 아니게 된다. 무엇을 말했는가가 아니라, 어떤 순서로, 어떤 맥락에서, 어떤 목적을 향해 말했는가를 봐야 한다.

이게 메타 evaluation이다.

런타임 QA도 비슷하다. 데모랩을 만들고 나면 끝이 아니다. 실제로 눌러보고, 대화해보고, 실패하는 경로를 따라가 보고, 사용자가 헷갈릴 지점을 찾는다. 그러면 QA는 단순히 버그를 잡는 일이 아니다. 내가 처음 세운 기준이 실제 사용 장면에서도 작동하는지 다시 보는 일이 된다.

4. 그래서 메타는 끝없어 보인다

그러다 보면 메타의 메타까지 간다. 프롬프트를 설계하고, 그 프롬프트의 결과를 평가하고, 그 평가 기준이 맞는지 다시 평가한다. 여기서 많은 사람이 멈춘다. 그럼 끝도 없는 거 아니냐고 생각한다.

나도 이 질문이 싫지 않다. 실제로 어느 정도까지는 끝이 없어 보인다. 프롬프트를 고치면 evaluation이 필요하고, evaluation을 고치면 그 evaluation이 현실을 잘 보고 있는지 다시 봐야 한다. 이 구조만 떼어놓고 보면 무한 계단처럼 보인다.

하지만 실제 운영에서는 조금 다르다.

메타에는 끝이 있다. 정확히 말하면, 추상적인 우주의 끝은 몰라도 내가 풀고 있는 문제 안에서는 끝이 보인다.

인간의 메타도 끝이 있다. 어떤 사람은 나무를 본다. 어떤 사람은 숲을 본다. 더 멀리 보는 사람은 숲이 놓인 지형을 본다. 그렇다고 모두가 우주 전체를 봐야 하는 것은 아니다. 일론 머스크가 세상을 보는 방식을 내가 다 이해할 수는 없을 것이다. 그 시야까지 가려면 훨씬 많은 층위의 메타가 필요하다.

하지만 내 사업을 굴리는 데 필요한 메타의 경계는 다르다.

5. 경계는 문제에서 나온다

콜바를 만들 때 내가 알아야 하는 것은 AI 전화가 멋있느냐가 아니다. 고객이 전화를 놓치는 순간 어떤 손실이 생기는지, 실제 사용자는 AI를 언제 어색하게 느끼는지, 병원과 음식점과 학원이 전화에서 원하는 것이 어떻게 다른지, 상담원이 자연스럽다고 느끼는 리듬은 무엇인지다.

이 정도까지 들어가면 비로소 기준이 생긴다. 어떤 프롬프트가 좋은지, 어떤 평가가 필요한지, 어떤 데모가 고객에게 의미 있는지가 보이기 시작한다.

문제에 충분히 집착하면 메타의 경계가 보인다.

이 말은 꽤 중요하다. 메타를 좋아해서 메타를 파는 게 아니다. 나는 메타라는 단어에 특별한 호감도 비호감도 없다. 단어는 단어다. 중요한 것은 내가 같은 실수를 반복하지 않기 위해 한 층 위의 기준을 만들고 있느냐다.

좋은 프롬프트는 명령이 아니라 관리 방식이다. 좋은 스킬은 반복되는 판단을 담은 운영체제다. 좋은 evaluation은 결과를 채점하는 표가 아니라, 내가 진짜로 원하는 행동을 계속 끌어내는 장치다.

6. AI에게 넘기는 것은 작업 방식이다

AI 에이전트는 결국 인간이 하던 일을 대체하거나 확장한다. 그렇다면 에이전트에게 일을 맡긴다는 것은 인간의 작업 방식까지 함께 넘기는 일이다.

사람이 일을 잘하려면 기준이 필요하다. 좋은 매니저는 일을 시킬 때 결과만 말하지 않는다. 맥락을 주고, 우선순위를 정하고, 하지 말아야 할 일을 일러주고, 끝났다고 말하기 전에 확인할 것을 정해준다.

AI에게도 똑같다.

앞으로 AI를 잘 쓰는 사람과 그렇지 않은 사람의 차이는 프롬프트를 예쁘게 쓰는 능력에서 나지 않을 것 같다. 차이는 더 위에서 난다. 자기 문제가 어떤 구조를 가지고 있는지, 그 문제를 푸는 데 어떤 판단 기준이 필요한지, 그 기준을 에이전트가 반복 가능하게 따르도록 만들 수 있는지에서 난다.

다른 조직에서도 그대로 가져갈 수 있게 압축하면 이렇다.

1. 프롬프트를 고치기 전에 “좋은 결과”의 기준을 먼저 쓴다.
2. 반복되는 판단은 스킬이나 runbook으로 남긴다.
3. Evaluation은 항목뿐 아니라 순서와 맥락을 본다.
4. QA는 산출물 확인이 아니라 기준이 현실에서 작동하는지 보는 일이다.
5. 메타의 끝은 추상에서 오지 않고, 실제 문제의 경계에서 온다.

7. 지금 내가 찾고 있는 것

메타 프롬프팅은 거창한 철학이 아니다.

내가 일을 어떻게 시키는지 다시 보는 것이다. 내가 무엇을 좋은 결과라고 부르는지 다시 정하는 것이다. 그리고 그 기준을 한 번의 말재주가 아니라 시스템으로 남기는 것이다.

처음에는 끝이 없어 보인다. 프롬프트 위에 프롬프트가 있고, 평가 위에 평가가 있고, 다시 그 평가를 평가해야 할 것 같다. 하지만 실제로는 어느 순간 경계가 생긴다. 내가 풀 문제, 내가 만나는 고객, 내가 만들 제품, 내가 반복해서 실패하는 지점이 그 경계를 만든다.

거기까지 가는 데 필요한 것은 천재적인 추상화 능력보다 끈질긴 집착에 가깝다.

문제에 오래 붙어 있으면 보인다. 이 일에는 어떤 메타가 필요한지. 어디까지 올라가야 하는지. 그리고 어디서부터는 그냥 다시 손을 움직여야 하는지.

나는 지금 그 경계를 찾고 있다. 콜바를 만들면서, 리콜바를 만들면서, 에이전트에게 일을 맡기고, 다시 그 에이전트를 평가하는 기준을 만들면서.

메타는 끝이 없지 않다.

다만 그 끝을 보려면, 문제를 충분히 오래 들여다봐야 한다.