우리는 여전히 얼마나 많은 것을 알고 있어야 할까요?

저는 현재 한 고객을 위해 가격 책정 시스템 (pricing system)을 구축하고 있는데, 솔직히 고백할 것이 하나 있습니다. 그것이 어떻게 가격을 책정하는지 그 대부분을 저는 설명할 수 없습니다.

코드가 불투명해서가 아닙니다. 제가 작성했으니까요, 정확히 말하면 Claude와 제가 함께 작성했습니다. 문제는 _비즈니스 로직 (business logic)_이 엄청나다는 점입니다. 가격은 고객, 재료, 원산지, 그리고 각각의 규칙을 가진 수많은 추가 사항과 예외 사항들에 따라 달라집니다. 제가 머릿속에 담아둘 수 있는 것보다 더 많은 규칙이 존재하며, 그것들은 계속 변합니다. 논리를 찾을 수 없는 가격이나 문서에 포함되지 않은 사례와 같은 공백을 발견할 때마다, 저와 Claude Code는 이를 "보류 데이터 (pending data)" 문서에 기록합니다. 그 문서는 검토를 거쳐 고객에게 전달됩니다.

여기서 제가 생각보다 더 신경 쓰여야 할 부분이 있습니다. 몇 번인가 고객이 특정 항목의 가격 책정 방식에 대해 설명을 요구해 왔는데, 답변을 하기 위해 저는 먼저 Claude에게 물어봐야만 했습니다. 저는 외부 컨설턴트입니다. 저는 비즈니스 지식을 보유하고 있지 않으며, 솔직히 말해서 보유하려고 노력해서도 안 된다고 생각합니다. Claude는 모든 문서에 접근할 수 있으며, 제가 전체 내용을 내재화하는 것보다 적절한 규칙을 찾아내는 데 훨씬 더 신뢰할 수 있습니다.

본능적으로 이에 대해 죄책감을 느끼게 됩니다. 하지만 저는 그 죄책감이 주로 잘못된 질문을 향하고 있다고 결론 내렸습니다.

지식을 외부화하는 것은 새로운 일이 아니며, 자동으로 부채가 되는 것도 아닙니다

우리는 오랫동안 기억을 외주화해 왔습니다. 우리 대부분은 20년 전에 전화번호를 외우는 것을 그만두었습니다. 우리는 찾아볼 수 있는 사실들을 암기하지 않습니다. 대신 어디서 찾아봐야 하는지를 기억합니다. 심리학자들은 이를 "구글 효과 (Google effect)"라고 부르며, 그렇다고 해서 세상이 무너지지는 않았습니다. 무언가를 찾는 방법을 아는 것 자체가 일종의 지식이며, 종종 그것이 더 유용한 종류의 지식입니다.

LLM (Large Language Model)은 그 사다리의 다음 단계입니다. LLM은 단순히 정답이 어디에 있는지를 알려주는 데 그치지 않습니다. 정답을 검색하고, 당신의 구체적인 사례에 적용하며, 이를 설명해 줍니다. 방대하고 고객사마다 특화된 가격 책정 규칙서(pricing rulebook)와 같은 대상에 대해, 이는 제 업무의 퇴보가 아닙니다. 그것이 유일하게 제정신인 방식입니다. 다른 사람의 비즈니스에 속한 수천 개의 변동적인 규칙들을 암기하는 것은, 제가 실제로 보수를 받는 유일한 가치를 낭비하는 일일 것입니다.

기술 부채 (technical debt)에서 빌려온 "인지 부채 (cognitive debt)"라는 용어가 떠돌고 있으며, LLM을 사용하여 에세이를 작성하는 사람들의 신경학적 참여(neural engagement) 감소를 측정한 널리 공유된 MIT 연구 ("Your Brain on ChatGPT")도 있습니다. 이는 유용한 표현입니다. 하지만 저는 이 용어가 너무 광범위하게 적용되고 있다고 생각합니다. 모든 오프로딩 (offloading, 외부 위탁)이 부채인 것은 아닙니다. 농사를 짓는 대신 식료품을 사는 것이 "농업 부채"가 아닌 것과 같습니다. 문제는 지식을 위임할 것인가의 여부가 아닙니다. 얼마나 많이, 언제, 그리고 — 모두가 건너뛰는 부분인 — 당신이 무엇에 대해 여전히 책임을 져야 하는가입니다.

실제로 변하는 것: 책임 (responsibility)

학습을 LLM에 위임하는 학생은 오직 자기 자신에게만 해를 끼칠 뿐입니다. 만약 그들이 에세이를 이해하지 못한다면, 그 비용은 나중에 개인적으로 그들에게 돌아갑니다. 그것은 그들이 자유롭게 선택할 수 있는 명확한 거래입니다.

저에게는 그런 탈출구가 없습니다. 저는 실제 고객에게 실제 숫자를 제시할 가격 책정 시스템 (pricing system)에 대해 책임을 집니다. 만약 시스템이 무언가를 잘못된 가격으로 책정한다면, "Claude가 그렇게 말했습니다"라는 말은 제가 고객에게 할 수 있는 답변이 아닙니다. 지식은 위임할 수 있습니다. 하지만 책임은 위임할 수 없습니다.

이것이 전체적인 관점을 재설정합니다. 제가 계속 스스로에게 던졌던 질문 — 이 중 얼마나 많은 것을 내가 알고 있어야 하는가? — 는 잘못된 질문이었습니다. 올바른 질문은 이것입니다: 나는 그것에 대해 책임을 질 수 있을 만큼 충분히 알고 있는가? 그리고 이 두 질문이 요구하는 기준은 매우 다릅니다.

세 가지 질문, 그리고 경계선이 실제로 그어지는 지점

그렇다면 그 순간에 질문할 수 있는 것만으로 충분한 때는 언제일까요? 질문하지 않고도 알고 있어야 하는 것은 무엇일까요? 그리고 그 이해는 얼마나 깊어야 할까요? 가격 책정 시스템을 예로 들어 답변해 보겠습니다. 왜냐하면 그 경계선은 특정한 지점에 그어져 있기 때문입니다.

개별 데이터 포인트 — 질문하십시오. 특정 원산지에서 오는 이 자재의 추가 요금(surcharge)은 얼마인가요? 저는 결코 그것을 머릿속에 담아두지 않을 것이며, 그래서도 안 됩니다. 그것은 변동성이 크고, 고객의 영역이며, 모델이 저보다 더 신뢰성 있게 이를 검색(retrieve)할 수 있기 때문입니다. 그 순간에 질문할 수 있다는 것만으로도 여기서는 진정으로 충분합니다. 이것은 위임(delegation)이 단순히 허용되는 수준을 넘어 올바른 선택이 되는 계층입니다.

시스템의 형태 — 묻지 않고도 알고 있어야 합니다. 어떤 범주의 규칙들이 존재하는지, 그것들이 어떻게 구성되는지, 어떤 입력값이 가격을 변동시킬 수 있고 어떤 것은 그렇지 않은지, 그리고 위험한 상호작용(interactions)이 어디에서 발생하는지 말입니다. 저는 모든 추가 요금을 암기할 수는 없지만, 원산지별 추가 요금이라는 것이 존재한다는 사실은 알고 있어야 합니다. 그렇지 않으면 질문해야 한다는 사실조차 모를 테니까요. 존재조차 인지하지 못하는 공간에 대해서는 쿼리(query)를 던질 수 없습니다. 이것이 지도이며, 지도는 제가 보유해야 할 영역입니다.

틀린 답을 잡아낼 수 있을 만큼 깊게 — 그리고 그것이 무엇을 의미하는지에 대해 정직하게. 이것이 진정한 임계점(threshold)이며, 이는 얼마나 많이 아느냐의 문제가 아니라 어떤 종류를 아느냐의 문제입니다. 하지만 여기서 저는 정직해져야 합니다. 저는 모든 출력값을 수동으로 검증할 수 없으며, 할 수 있는 척하는 것은 또 다른 형태의 부정직함일 뿐입니다. 저는 가격을 수동으로 계산하지 않을 것이며, 종종 정답이 무엇인지조차 모를 때가 있습니다. 그것은 고객의 비즈니스이지 저의 비즈니스가 아닙니다. 제가 직접 잡아낼 수 있는 것은 명백한 오류들입니다. 즉, 자릿수(order of magnitude)가 크게 틀린 숫자, 적용되어서는 안 될 사례에 적용된 규칙, 혹은 중복 적용되어서는 안 될 두 가지 추가 요금이 쌓이는 경우와 같은 기본적인 논리 위반(basic-logic violations)들입니다.

정확한 적용 방식 — 제가 눈으로 직접 확인할 수 없는 부분 — 은 제 판단에 의해 검증되지 않습니다. 그것은 _테스트 (tests)_와 클라이언트가 승인한 골든 셋 (golden set)에 의해 검증됩니다. 그것이 실제로 확장 가능한 (scales) 방식입니다. 저는 정답을 머릿속에 담고 있는 것이 아니라, 그것을 확인하는 _메커니즘 (mechanism)_을 보유하고 있는 것입니다. 검증 자체는 위임되지만, 이는 '느낌 (vibes)'이 아니라 결정론적이고(deterministic) 감사 가능한(auditable) 대상에게 위임됩니다. 이것이 프로그래밍이 결과 중심적 (results-oriented)인 방향으로 계속 흘러가는 이유 중 하나입니다. 모델이 결과를 만들어내기 위해 거친 경로가 아니라, 동작을 점점 더 명시하고 검증하게 되는 것입니다.

따라서 그 경계선은 단순히 "내가 개인적으로 그것이 틀렸음을 알 수 있는가"보다 조금 더 넓습니다. 그것은 다음과 같습니다: 틀린 답을 잡아낼 어떠한 방법이라도 가지고 있는가 — 투박한 오류를 잡아낼 나만의 안목인가, 아니면 정확한 오류를 잡아낼 테스트나 골든 셋인가? 만약 이 중 어느 것도 없다면, 그것은 위임(delegating)이 아니라 포기(abdicating)입니다. 위임은 인간, 혹은 인간이 소유한 확인 절차를 루프(loop) 안에 유지합니다. 포기는 그 둘 모두를 제거합니다. 이 둘은 답이 틀리기 직전까지는 동일해 보이지만, 그 이후에는 이보다 더 다를 수 없습니다.

조용한 증상: 에이전트만이 읽는 문서

제 작업에서도 이 경계가 흐릿해지는 것을 느끼는 지점이 바로 여기입니다. 제 시스템에 대한 지식 중 점점 더 많은 부분이 기계를 위해 작성된 파일들에 존재합니다. CLAUDE.md, AGENTS.md, Skills 등 말이죠. 그리고 이 프로젝트의 경우, 그 "보류 중인 데이터 (pending data)" 문서 — 절반은 사양(spec)이고 절반은 질문 목록인 이 문서 — 는 클라이언트도 저도 다른 어디에도 완전히 기록해 두지 않은 도메인을 저와 에이전트가 함께 탐색할 수 있도록 작성되었습니다.

저는 Software Is Dissolving Into the Model에서 이 변화를 다른 각도에서 다룬 적이 있습니다. 우리가 예전에 소프트웨어라고 불렀던 계층이 한쪽으로는 지시 사항(instructions)으로, 다른 한쪽으로는 생성된 출력(generated output)으로 붕괴하고 있다는 내용입니다. 이러한 편리함의 이면은 이것입니다. 만약 문서가 에이전트를 위해 작성된다면, 여전히 책임을 지고 있는 인간들을 위한 지도는 누가 유지하고 있는 것일까요? Claude에게는 아름답게 읽히지만, 그 시스템에 책임을 지는 모든 이들에게는 서서히 암흑 속으로 사라져 버리는 시스템을 만들기 쉽습니다.

흥미로운 점은 저의 "보류 중인 데이터 (pending data)" 문서가 의도치 않게 올바른 역할을 수행하고 있다는 것입니다. 그것은 단순히 에이전트 (agent)를 위한 컨텍스트 (context)가 아닙니다. 그것은 인간 참여형 (human-in-the-loop) 체크포인트입니다. 그것은 사람 — 처음에는 저, 그다음에는 클라이언트 — 이 무엇이 누락되었는지 살펴보고 결정해야 하는 순간을 강제합니다. 그것이 바로 유지할 가치가 있는 패턴입니다. "문서만 읽는 에이전트"에 대한 답은 아마도 문서를 더 적게 쓰는 것이 아닐 것입니다. 그것은 루프 (loop)가 인간 없이 닫히도록 내버려 두는 대신, 책임감 있는 인간이 멈춰서 검증해야 하는 지점을 의도적으로 설계하는 것입니다.

아무도 공개적으로 인정하고 싶지 않은 부분

기술적인 프레임 (framing)이 생략하는 이 모든 것의 사회적 층위가 있습니다. 제가 제 클라이언트에게 답변하기 전에 때때로 Claude에게 물어본다는 사실을 말하는 것은 대가가 따릅니다. 그것은 가면 증후군 (impostor syndrome) — 즉, 사람들이 소시지가 만들어지는 과정을 보는 순간, 내가 그들이 고용한 전문가가 아니라고 결정할 것 같다는 조용한 두려움 — 에 정면으로 맞닿아 있습니다.

이상한 점은 투명성 (transparency)이 그 감정의 촉매제가 아니라 치료제라는 것입니다. 가면 증후군은 당신이 투영하는 이미지와 실제로 일하는 방식 사이의 간극에서 자라납니다. "모델에게 물어본 다음 규칙이 적용되는지 확인했습니다"라고 공개적으로 말하는 것은 그 간극을 메워줍니다. 더 이상 밝혀질 것이 남지 않게 됩니다.

하지만 그 대가가 상상 속의 것이라고 거짓말하지는 않겠습니다. 어떤 클라이언트들에게는 솔직하게 말하는 것이 진심으로 불리하게 작용할 수 있습니다. 당신이 무언가 잘못했기 때문이 아니라, 그들이 아직 좋은 AI 활용이 어떤 모습인지 이해하지 못하기 때문입니다. 그들은 "Claude에게 물어봤다"라는 말을 들으면, 그것을 "몰랐다"로 패턴 매칭 (pattern-match)하지만, 사실 그것은 "권위 있는 규칙을 검색하여 확인했다"로 패턴 매칭되어야 합니다. 아이러니하게도 상황은 날카롭습니다. 그런 클라이언트들이야말로 제가 그들의 프로세스에 AI를 통합하도록 돕기 위해 고용되는 바로 그 대상들입니다. 투명성을 위험하게 만드는 바로 그 이해의 간극이, 역설적으로 이 업무가 존재하는 이유이기도 합니다.

그렇기 때문에 검증(validation)의 경계선은 단순히 기술적인 측면뿐만 아니라 여기서도 중요합니다. 투명성이란 "저는 아무것도 모르고, Claude가 다 합니다"라고 고백하는 것이 아닙니다. 그것은 무엇을 위임하는지 정확히 명시하고, 결정적으로 그것을 확인할 수 있는 능력을 유지하고 있음을 보여주는 것입니다. "Claude에게 물어보고 이 규칙이 이 사례에 적용되는지 확인했습니다"라는 문장은 "Claude에게 물어봤습니다"라는 문장과는 완전히 다릅니다. 전자는 도구를 잘 사용하는 전문가를 묘사하지만, 후자는 고객이 두려워하는 바로 그 모습을 묘사합니다. 검증할 수 있다는 능력이 바로 그 정직함을 방어 가능하게(defensible) 만듭니다. 그리고 시간이 흐르면서 이러한 차이를 모델링하는 것이 고객이 그 둘을 구분하는 법을 배우는 과정의 일부가 됩니다.

내가 도달한 결론

저는 여러분에게 위임을 덜 하라고 말하지 않을 것입니다. 가격 책정 프로젝트의 경우, 비즈니스 지식을 위임하는 것이 옳은 결정이며, 그렇지 않은 척하는 것은 저를 더 느리게 만들 뿐 신뢰도를 높여주지도 않습니다. 제가 긋고 있는 선은 "떠넘길 수 있는 구현(implementation)"과 "반드시 유지해야 하는 지식" 사이의 선이 아닙니다. 그것은 여전히 "검증(validate)"할 수 있는 지식과, 눈이 멀어버린(gone blind to) 지식 사이의 선입니다.

제가 실제로 실천하고 있는 세 가지는 다음과 같습니다:

영토가 아닌 지도를 보유하라. 데이터를 통째로 암기하지 마세요. 대신 어떤 범주의 것들이 존재하는지, 그리고 그것들이 어떻게 상호작용하는지는 파악하고 있어야 합니다. 존재조차 모르는 공간에 대해서는 질문을 던질 수 없습니다.
"이것을 확인할 수 있는가?"를 진정한 테스트로 삼으라. 모델이 의사결정을 주도하도록 허용하기 전에, 모델이 틀렸을 때 그것을 잡아낼 수 있는 "방법"이 있는지 스스로에게 묻습니다. 즉, 조잡한 오류를 잡아낼 나만의 안목이나, 정확한 오류를 잡아낼 테스트 또는 골든 세트(golden set)가 있는지 확인하는 것입니다. 여기서 "확인(check)"한다는 것이 반드시 "직접 계산한다"는 의미는 아님을 유의하세요. 대개 그것은 확인을 수행하는 메커니즘을 소유하고 있음을 의미합니다. 만약 메커니즘이 전혀 없다면 그것은 위임이 아니며, 저는 메커니즘을 직접 구축하거나, 그렇지 않다면 관리 없이 결과물을 내놓지 않을 것입니다.
프롬프트(prompt)뿐만 아니라 체크포인트(checkpoint)를 설계하라. 지식이 에이전트가 읽을 수 있는 문서(agent-readable docs)로 이동할 때, 의도적으로 인간의 개입 순간을 다시 추가하세요. 검토 단계, 질문 대기 문서, 승인(sign-off) 절차 등을 통해 책임 있는 사람이 없는 상태에서 루프가 조용히 닫혀버리는 일이 없도록 해야 합니다.

"얼마나 많은 것을 여전히 알고 있어야 하는가?"라는 질문에 대한 정직한 답변은 결코 양(quantity)의 문제가 아니라는 사실로 드러납니다. 그것은 하나의 능력입니다. 즉, 답변이 틀렸을 때를 알아챌 수 있을 만큼의 능력 말입니다. 그 기준선 위에 있는 모든 것은 자유롭게 물어보십시오. 그 기준선 아래에 있는 것은 노력을 아끼는 것이 아니라, 단지 당신이 사실을 알게 될 순간을 뒤로 미루는 것뿐입니다.

이 아이디어의 더 급진적인 버전이 있습니다. 모델의 판단을 신뢰하는 대신, 모델이 자신의 추론을 당신이 실제로 읽고 테스트할 수 있는 코드(code)로 외재화(externalize)하도록 강제하는 방식입니다. 그것이 다음 포스트에서 다룰 실험입니다. 즉, 한 줄씩 감사(audit)할 수 있는 위임(delegation)입니다.

_이 글은 위임(delegation)과 이해(understanding)에 관한 두 편의 글 중 첫 번째입니다. 다음 글에서는 구체적인 내용을 다룹니다. 모델이 자신의 지식을 머릿속에만 담아두는 대신, 검증 가능한 코드(verifiable code)로 작성하게 만드는 실험을 소개합니다. 관련 읽을거리: Software Is Dissolving Into the Model.

원문 게시지: javieraguilar.ai

더 많은 AI 에이전트(AI agent) 프로젝트를 보고 싶으신가요? 멀티 에이전트 시스템(multi-agent systems), MCP 개발, 그리고 컴플라이언스 자동화(compliance automation)를 소개하는 저의 포트폴리오를 확인해 보세요.