Joon's Field Notes — AI, knowledge, and systems

왜 이 글을 쓰는가

스타트업에서 일하며 한 사람이 여러 역할을 동시에 떠안아야 했다. 그때 타협점은 늘 하나였다. 퀄리티를 낮추는 것. 시간과 손이 모자라니, 결국 어딘가를 덜 다듬은 채로 내보냈다.

그렇게 나온 결과물도, 그걸로 쌓인 내 포트폴리오도 미흡했다. 사정을 설명하면 외부인에겐 그저 변명으로 들렸다. 그러면서 한 가지를 분명히 배웠다. 이유가 무엇이든 결과에 아쉬운 점이 있으면, 이해는 받을 수 있을지언정 고객은 지갑을 열지 않는다. 사정은 공감의 대상이지 구매의 이유가 아니다.

내겐 Agentic Workflow가 그 막다른 곳에서의 유일한 희망이었다. 손이 모자라 퀄리티를 깎는 대신, 여러 일을 동시에 굴리면서도 각각의 퀄리티를 지킬 방법. 나는 더 이상 "졌지만 잘 싸웠다" 같은 말을 하고 싶지 않다.

그런데 막상 여러 일을 동시에 자동화로 굴려 보니, 진짜 문제는 일을 벌이는 쪽이 아니라 그 결과를 채점하는 쪽에 있었다. 그래서 이 글은 두 가지를 다룬다. 여러 루프를 어떻게 동시에 굴리는가(워크플로 토폴로지), 그리고 그 루프들을 채점하는 내 판단이 흔들릴 때 어떻게 보정하는가(루프 보정). 먼저 결론을 당겨 두면, 퀄리티를 지키는 싸움의 승부처는 일을 늘리는 데 있지 않았다. 흔들리는 채점자를 떠받치는 데 있었다.

그래서 미리 못을 박아 둔다. 이 글의 주인공은 에이전트가 아니다. 그 결과를 채점하는 Oracle, 더 정확히는 자기 자신을 채점하는 Oracle, 곧 흔들리는 나 자신이다. 우리는 보통 사람을 시스템을 관리하는 주체로만 두지만, 이 글의 주장은 사람도 Drift하므로 사람 자신이 관리 대상이라는 것이다. 좋은 Oracle은 처음부터 좋은 채로 태어나는 게 아니라 관리된다. 아래는 그 채점자가 왜 흔들리고, 무엇으로 그 흔들림을 추적하고 보정하는지를 지난 글의 비유 위에서 풀어 간다.

요약

지난 글에서 LLM을 통 속에 든 아인슈타인에 비유했다. 아는 건 방대하지만 몸이 없어, 컨텍스트 윈도우라는 가느다란 관으로 흘려보내 준 것만 본다. 그 글은 그 관 안에 무엇을 어떤 구조로 흘려보낼지, 곧 일을 시키는 쪽의 문제였다.

이번 글은 한 칸 더 밖이다. 통 밖에서 그 결과를 채점하는 자, Oracle. 우리는 시스템이 "잘했다"고 말할 때 늘 누군가를 믿고 있다. 정답 데이터셋이든, 채점하는 또 다른 모델이든, 화면을 보며 고개를 끄덕이는 사람이든. 문제는 그 채점자가 고정된 기준점이 아니라는 것이다.

핵심은 셋이다. 첫째, Oracle은 시스템 품질의 상한을 정한다. 그래서 Oracle이 흔들리면 시스템 전체가 흔들리되, 점수는 멀쩡해 보여서 조용히 흔들린다. 이게 Oracle Drift다. 둘째, Oracle이 Model이면 그 역시 통 속의 아인슈타인이라 같은 병을 앓는다(Model Drift, 관의 한계). Oracle이 사람이면 그의 Mental Model이 흔들린다(기준이 미끄러지고, 세상이 움직이는 동안 머릿속 모델은 멈춰 있다). 셋째, 그러니 답은 완벽한 Oracle을 찾는 게 아니라, Oracle의 흔들림을 이벤트로 잡아 의사결정 루프에 넣는 것이다. Drift를 Decision으로, Decision을 Update로 잇고, 그 판정 이력 자체를 기억으로 쌓는다.

여기에 현실의 조건 하나를 더한다. Agentic Workflow를 실제로 돌릴 때 우리는 여러 루프를 병렬로 굴리지만(모델·프롬프트 학습 루프, 리서치 루프, 서비스 QA 루프 같은 갈래) 판단할 사람은 하나라, 루프당 판단 시간은 1/N로 쪼개진다. 그래서 사람 Oracle의 흔들림은 예외가 아니라 기본값이 된다. 그 얇아진 자를 떠받치는 방법은 둘이다. 안으로는 판정을 기억으로 쌓아 흔들림을 추적하고, 밖으로는 루프 바깥의 외부인을 만나 굽은 자의 영점을 다시 맞춘다. 그리고 병렬 자동화로 비워 낸 시간은 공부와 콘텐츠로 돌려, 사람 Oracle 자신을 보정하는 데 쓴다.

1. 지난 글에서 한 칸 더 밖으로

지난 글의 끝에서 나는 겹겹의 포함 관계를 그렸다.

prompt engineering ⊂ context engineering ⊂ harness engineering ⊂ loop engineering

프롬프트는 이번 턴의 말, 컨텍스트는 관을 통과하는 맥락 전체의 조직, 하네스는 그 맥락을 모아 관에 넣고 도구를 호출하는 기계 장치, 루프는 올리고 반응 보고 다시 고치는 바깥 순환이다. 지난 글은 가운데 두 겹(컨텍스트와 하네스)을 다뤘다. 가장 바깥의 루프는 한 줄로만 받고 넘어갔다.

이번 글은 그 가장 바깥 고리를 연다. 루프란 결국 "올린 결과가 좋았는지 보고, 그에 따라 다시 고치는" 순환이다. 그런데 이 한 문장에는 묻혀 있는 주체가 하나 있다. 좋았는지를 누가 판정하는가. 통 안의 아인슈타인은 자기가 잘했는지 스스로 알지 못한다. 통 밖에서 누군가가 채점해야 루프가 돈다. 지난 글이 통 안에 무엇을 흘려보낼지를 다뤘다면, 이번 글은 통 밖에서 그 결과를 채점하는 자를 의심한다.

세 글을 한 줄로 꿰면 이렇다.

1편: 무엇을 기억할 것인가. 메모장(work-memory)을 관리하는 이야기.

2편: 무엇을 보여줄 것인가. 통 속의 아인슈타인에게 어떤 맥락을 흘려보낼지(context)를 관리하는 이야기.

3편(이 글): 무엇을 믿을 것인가. 그 결과를 채점하는 Oracle, 그리고 흔들리는 나 자신을 관리하는 이야기.

기억에서 맥락으로, 맥락에서 판단으로 한 칸씩 밖으로 나온 셈이다.

2. 시스템을 재는 자, Oracle

소프트웨어 공학에는 이 채점자를 부르는 이름이 있다. Oracle. 입력에 대해 올바른 출력이 무엇인지를 결정하는 기준 주체 혹은 메커니즘이다. Oracle은 사람일 수도, 정답 데이터셋일 수도, 또 다른 AI일 수도 있다. 형태가 무엇이든 한 가지는 분명하다. Oracle의 품질이 시스템 전체의 인식론적 상한을 정한다. 얼마나 좋은 시스템을 만들 수 있는가는, 결국 얼마나 좋은 Oracle을 가졌는가에 달려 있다.

여기까지는 Oracle을 고정된 자(尺)로 가정한다. 자가 정확하기만 하면, 시스템이 그 자에 가까워지도록 깎으면 된다. 루프의 채점 칸에 믿을 만한 Oracle을 한 번 꽂아 두면, 나머지는 그 기준을 향해 수렴한다고 믿는 것이다.

이 가정이 깨지는 지점이 이 글의 출발이다.

3. 그 자(尺)가 흔들린다: Oracle Drift

자가 고무라면, 아무리 정밀하게 재도 눈금은 매번 다르다. 더 나쁜 건, 재는 행위 자체는 멀쩡해 보인다는 것이다. 숫자는 나온다. 사람은 고개를 끄덕인다. 점수는 어제와 비슷하다. 그런데 그 점수가 가리키던 대상이 어느새 달라져 있다. 이것이 Oracle Drift다. 시스템을 평가하는 기준 자체가 시간에 따라 미끄러지는 현상.

이게 특히 위험한 이유는 2절의 명제 때문이다. Oracle이 상한을 정하므로, 상한 자체가 드리프트하면 시스템 전체가 따라 드리프트한다. 그런데 우리가 시스템을 감시하는 눈이 바로 그 Oracle이다. 감시자가 흔들리고 있을 때, 우리는 흔들림을 감지할 도구를 잃는다. 그래서 Oracle Drift는 요란하게 무너지지 않는다. 점수판이 정상인 채로, 시스템은 조용히 무너진다.

Drift에는 여러 종류가 있다. 데이터의 분포가 바뀌는 Data Drift, 개념의 정의가 바뀌는 Concept Drift, 실행 환경이 바뀌는 Environment Drift, 모델의 거동이 바뀌는 Model Drift. Oracle Drift가 이들과 다른 점은 층위다. 다른 Drift들이 "재어지는 대상"에서 일어난다면, Oracle Drift는 "재는 주체"에서 일어난다. 대상의 드리프트는 좋은 자만 있으면 잡힌다. 주체의 드리프트는 그 자로는 잡히지 않는다.

그렇다면 자는 왜 흔들리는가. 이건 Oracle이 무엇이냐에 따라 모양이 다르다. 그리고 어느 쪽이든, 결국 통 속의 아인슈타인으로 돌아온다.

4. Oracle이 Model이면: 채점자도 통 속에 있다

요즘 가장 흔한 Oracle은 또 다른 모델이다. LLM이 만든 출력을 다른 LLM이 채점하는 LLM-as-judge가 대표적이다. 사람 손이 닿지 않는 규모를 자동으로 재려면 거의 불가피한 선택이다.

그런데 여기서 1절의 비유가 그대로 한 번 더 적용된다. 채점하는 모델도 통 속의 아인슈타인이다. 채점자 역시 몸이 없고, 자기에게 흘려보내 준 관 안의 맥락만 본다. 채점 기준을 관에 충분히 넣어 주지 않으면, 채점자는 자기 학습에 흐릿하게 깔린 "그럴듯함"으로 점수를 매긴다. 채점받는 쪽과 같은 한계를 채점하는 쪽도 그대로 갖고 있는 것이다. 같은 병을 앓는 둘 중 하나에게 다른 하나의 채점을 맡긴 셈이다.

게다가 모델 Oracle은 고정점이 아니다. 모델은 버전이 바뀌고, 같은 모델도 시점에 따라 거동이 미세하게 달라진다. 어제의 채점자와 오늘의 채점자가 같은 답에 다른 점수를 준다. 이건 Drift 분류에서 Model Drift에 해당하는데, 보통은 "재어지는 모델"의 문제로 이야기된다. 그런데 그 모델이 동시에 Oracle이라면, Model Drift는 곧 Oracle Drift가 된다. 자가 모델이라서, 모델이 흔들리는 만큼 자도 흔들린다.

정리하면, Oracle을 모델로 두는 순간 우리는 통을 하나 더 늘린 것이다. 채점받는 통, 채점하는 통. 두 통 모두 가느다란 관으로만 세상을 본다. 자동화의 규모는 얻지만, 그 대가로 "흔들리지 않는 기준점"이라는 환상은 포기해야 한다.

5. Oracle이 사람이면: Mental Model이 흔들린다

그럼 사람을 Oracle로 두면 되지 않나. 사람은 통 안에 갇혀 있지 않으니, 능동적으로 맥락을 소환하고 세상을 직접 본다. 지난 글에서 사람과 LLM의 결정적 차이로 꼽았던 바로 그 능력이다.

맞다. 그래서 나는 여전히 사람이 최종 판정자여야 한다고 본다. 다만 사람 Oracle에는 다른 종류의 흔들림이 있다. 사람의 Mental Model이 흔들린다.

사람이 무언가를 채점할 때, 그는 머릿속 모델로 잰다. "좋은 글이란 이런 것", "이 의도는 이 범주", "이 정도면 통과". 이 머릿속 모델은 고정되어 있지 않다. 몇 가지 방식으로 미끄러진다.

기준 표류. 비슷한 걸 백 개째 채점하면 기준이 슬그머니 느슨해지거나 까다로워진다. 아침의 통과 기준과 저녁의 통과 기준이 다르다. 같은 답이 채점자의 피로에 따라 다른 점수를 받는다.
고정된 채로 세상이 움직임. 머릿속 모델은 한 시점의 세상으로 굳는다. 그런데 데이터도, 사용자도, 목적도 그 뒤로 계속 움직인다. 모델을 갱신하지 않으면, 사람은 지금이 아니라 과거의 세상을 기준으로 현재를 채점하게 된다.
암묵성. 사람의 기준은 대개 말로 적혀 있지 않다. 그래서 본인도 자기 기준이 언제 어떻게 바뀌었는지 알아채지 못한다. 흔들림이 기록되지 않으니 추적도 안 된다.

핵심은 이렇다. 사람을 Oracle로 두면 통 속의 한계는 벗어나지만, 자가 흔들린다는 사실 자체는 사라지지 않는다. 모델 Oracle은 버전과 거동으로 흔들리고, 사람 Oracle은 Mental Model로 흔들린다. 모양이 다를 뿐, 둘 다 고무 자다. 어느 쪽도 "꽂아 두면 끝나는 고정 기준점"이 되어 주지 못한다.

6. 병렬로 돌리면, 판단할 시간은 1/N이 된다

여기까지는 루프가 하나라고 가정했다. 현실은 그렇지 않다. 내가 Agentic Workflow를 실제로 돌릴 때는 여러 루프를 동시에 굴린다. 신뢰를 위해 실제 모양을 그대로 적는다. 대략 세 갈래다.

모델·프롬프트 갈래. 데이터 분석 → 전처리 → 모델 학습·프롬프팅 → 검증·평가가 한 루프다. 산출물은 개선된 모델이거나, 프롬프트이거나, 데이터셋이다.

리서치 갈래. 데이터 수집 → 검증 → 구조화 → 분석이 한 루프다. 산출물은 리포트다.

서비스 갈래. 서비스 정책 → 시스템 QA가 한 루프다. 산출물은 리포트다.

세 갈래가 각자의 루프를 가지고 나란히 진행된다. 여기서 두 가지를 몸으로 느꼈다. 하나, 어느 갈래도 입력에서 산출까지 직선으로 가지 않는다. 반드시 돌면서 틀리고 고친다. 그래서 루프는 선택이 아니라 필수다. 둘, 그 루프를 채점하는 내 판단도 한 번에 맞는 법이 없다. 매번 보정이 필요하다. 자동화된 루프가 잘 돌수록, 정작 손이 가는 건 그 결과를 보는 내 판단 쪽이었다.

문제는 비대칭이다. 실행은 병렬로 늘어나는데, 판단은 병렬로 늘어나지 않는다. 에이전트는 통을 세 개든 다섯 개든 늘릴 수 있다. 그런데 그 결과를 채점하는 사람 Oracle은 하나다. 루프가 셋이면 한 루프에 줄 수 있는 판단 시간은 1/3로 쪼개지고, 루프를 늘릴수록 루프당 판단은 1/N로 얇아진다.

이게 5절과 곧장 맞물린다. 사람 Oracle은 가만히 둬도 Mental Model이 흔들리는데, 거기에 더해 각 루프에 쏟을 주의가 1/N로 줄어든다. 주의가 얇아질수록 흔들림은 더 빨리, 더 안 보이게 일어난다. 슬쩍 보고 통과시킨 판정, 옆 루프에 정신이 팔린 채 끄덕인 승인. 그래서 병렬 운영에서 사람 Oracle의 드리프트는 예외적 사고가 아니라 기본 조건이다.

바꿔 말하면, 병렬화가 진짜로 옮겨 놓는 병목은 실행이 아니라 판단이다. 에이전트의 처리량은 늘었는데, 그 처리량을 받아 줄 사람의 판단 대역폭은 그대로다. 통을 늘릴수록 채점이 밀리고, 채점이 밀릴수록 자는 더 흔들린다. 이 절 이후의 이야기는 전부 이 병목, 곧 얇아진 사람 Oracle을 무엇으로 떠받칠 것인가에 관한 것이다.

이건 나 혼자만의 관찰이 아니다. 리누스 토르발스가 말한 메인테이너 번아웃이 같은 구조를 보여 준다. AI로 생성이 싸지자 무책임한 버그 리포트와 패치가 홍수처럼 밀려들었는데, 그걸 검토하고 판정할 메인테이너의 용량은 그대로였다. 생성은 병렬로 폭증했지만 판단은 병렬로 늘지 않았고, 1~3명이 떠받치던 프로젝트의 메인테이너들이 무너졌다.

다만 한 가지를 분명히 하고 싶다. 번아웃은 보통 "지쳐 가는 메인테이너"라는 피해자 서사로 이야기된다. 외부 부하의 희생자라는 그림이다. 이 글이 보려는 건 그보다 한 겹 안쪽이다. 부하에 쓰러지기 전에 이미, 판정자는 안 읽고 통과시키는 고무도장으로 조용히 퇴화한다. 점수판은 멀쩡한데 자가 굽는 것이다. 그러니 메인테이너는 단지 부하의 피해자가 아니라, 그 자신이 흔들리는 Oracle이다. 떠받쳐야 할 대상은 "불쌍한 판정자"가 아니라 "관리되어야 할 판정 기준"이다. 즉 사람은 시스템을 관리하는 주체이기만 한 게 아니라, 그 자신이 관리 대상이다. (이 생성·유지보수 비대칭은 전에 좋은 Agent보다 좋은 Repository가 중요하다에서 다뤘다. 그 글이 "생성을 감당할 구조(좋은 repository)"를 답으로 봤다면, 이 글은 그 구조로도 흔들리는 판정자 자신을 어떻게 관리할지를 본다.)

7. 그래서 Oracle은 얼리지 말고 루프에 넣는다

여기서 흔한 결론은 "더 좋은 Oracle을 찾자"다. 더 정밀한 채점 모델, 더 숙련된 리뷰어. 나쁘지 않지만, 그건 자를 더 단단한 고무로 바꾸는 일일 뿐이다. 흔들림의 종류를 줄일 수는 있어도 없앨 수는 없다. 그리고 Oracle을 아예 얼려 버리는 것은 더 나쁘다. 자를 멈추는 순간 세상만 움직이고, 시스템은 점점 과거를 향해 최적화된다.

내가 만드는 MSO에서 택한 방향은 다르다. Oracle을 고정하려 들지 않고, Oracle의 흔들림을 일급 이벤트로 잡아 의사결정 루프에 넣는다. 흔들림은 제거할 대상이 아니라 처리할 신호다. 루프는 대략 이렇게 돈다.

Drift Event → Decision Case → Agent Decision(대안 제시) → User Decision(선택) → Policy Update / Parameter Update → 다시 미래의 판정으로

읽으면 이렇다. 어딘가에서 Drift가 감지되면(Oracle Drift든 그것이 드러낸 Concept·Data Drift든) 그것을 Drift Event로 남긴다. 이 이벤트는 Decision Case, 곧 "이 문제를 두고 어떤 결정을 내렸는가"라는 의사결정의 묶음을 연다. 통 속의 아인슈타인(Agent)은 여기서 답을 확정하지 않는다. 대안을 제시한다. 택소노미를 고칠지, 데이터셋을 보강할지, 모델을 교체할지. 그 다음에 사람이 선택한다. 선택은 정책 수정이나 파라미터 수정으로 이어지고, 수정된 시스템이 다시 다음 판정의 조건이 된다.

이 구조의 요점은 두 가지다.

하나, 결정이 아니라 이벤트를 저장한다. Drift, 대안, 선택, 수정은 각각 하나의 이벤트로 남는다. "어떤 의사결정이었는가"는 이 이벤트들 사이의 관계로 나중에 재구성된다. 그래서 자가 언제 어떻게 흔들렸고, 그때 무엇을 보고 어디로 틀었는지가 추적 가능해진다. Oracle Drift는 더 이상 점수판 뒤에 숨지 못한다.

둘, 이 모든 게 가장 바깥 고리, 루프에서 일어난다. 1절의 prompt ⊂ context ⊂ harness ⊂ loop를 떠올리면, Oracle과 Drift와 의사결정은 컨텍스트나 하네스가 아니라 그 둘을 감싸는 루프의 일이다. 안쪽 고리들이 "통에 무엇을 어떻게 넣을까"라면, 루프는 "넣은 결과를 누가 어떻게 채점하고, 그 채점이 흔들릴 때 무엇을 고칠까"다. 지난 글이 안쪽 두 겹이었다면, 이 글은 가장 바깥 겹이다.

8. 사람이 최종 판정자로 남되, 그 판정도 기억이 된다

루프를 이렇게 짜도 한 가지 질문이 남는다. 5절에서 사람의 Mental Model도 흔들린다고 했고, 6절에서는 병렬 운영이 그 흔들림을 키운다고 했다. 그런데 7절의 루프는 결국 사람의 선택(User Decision)에 기댄다. 흔들리는 자에 다시 기대는 것 아닌가.

내 답은 이렇다. 사람은 그래도 최종 판정자로 남아야 한다. 모델 Oracle과 달리 사람은 통 밖에서 새 맥락을 능동적으로 들여올 수 있고, 책임을 질 수 있는 유일한 주체이기 때문이다. Agent는 대안을 제시하고, 사람은 선택한다. 이 권한 배분은 유지한다.

다만 그 판정마저 흔들린다는 사실을 부정하지 않고, 판정 자체를 이벤트로 남긴다. 사람이 무엇을 보고 어떤 대안을 왜 골랐는지를 기록으로 쌓으면, 사람이라는 Oracle의 드리프트도 비로소 추적 대상이 된다.

장면으로 그리면 이렇다. 한 사람이 모니터 앞에 앉아 있는데, 그가 보고 있는 건 돌아가는 루프가 아니라 자기 자신의 판단 기록이다.

2026-03 승인 2026-04 반려 2026-05 승인 2026-06 정책 변경

그는 그 목록을 짚으며 자신에게 묻는다. 나는 왜 이 결정을 했지. 석 달 전에도 같은 상황에서 같은 판단을 했나. 기준이 바뀐 건가, 세상이 바뀐 건가. 이건 거울을 보는 일에 가깝다. 거울 속에는 어제의 내가 내린 판정이 있고, 지금의 나는 체크리스트를 들고 그 판정과 오늘의 나를 대조한다. 8절에서 말한 Decision Log, User Decision, Policy Update는 사실 이 장면을 시스템 용어로 옮긴 것일 뿐이다. 여기서 사람은 에이전트를 관리하는 사람이 아니라, 자기 판단을 관리하는 사람이다.

이게 가능하면, 석 달 전의 나와 오늘의 나가 같은 상황에서 다른 선택을 했을 때 그 차이가 기록에 드러난다. 기준이 미끄러졌는지, 세상이 움직인 건지, 내가 과거에 갇힌 건지를 되물을 수 있다. 암묵적이라 추적되지 않던 흔들림(5절)이, 기록되는 순간 다룰 수 있는 것이 된다.

그래서 이 시스템이 쌓는 것은 대화 로그가 아니다. "왜 지금의 정책과 모델을 쓰게 되었는가"에 대한 답, 곧 의사결정의 기억이다. 한 사람의 머릿속 모델은 흔들리고 언젠가 사라지지만, 판정의 이력이 조직의 기억으로 남으면, 흔들리는 자들로도 흔들리지 않는 방향을 길게 유지할 수 있다. 고정된 Oracle을 갖는 대신, 흔들리는 Oracle들의 궤적을 기억하는 쪽을 택하는 것이다.

9. 루프 밖에서 자를 다시 맞춘다: 외부인

8절은 흔들림을 안에서 추적하는 일이었다. 판정을 기억으로 쌓으면 자가 언제 어떻게 굽었는지 되짚을 수 있다. 그런데 추적과 교정은 다르다. 굽은 걸 알아도, 무엇을 기준으로 다시 펴야 하는지는 루프 안의 기록만으로는 나오지 않는다. 영점(零點)이 루프 안에 없기 때문이다.

루프는 본질적으로 자기참조적이다. 결과를 만드는 것도, 그 결과를 채점하는 Oracle도 같은 루프의 맥락 안에 있다. 같은 가정, 같은 데이터, 같은 어제의 나. 루프를 오래 돌리면 그 안의 모든 것이 서로를 정당화하며 함께 미끄러진다. 자가 굽는데 재는 대상도 같이 굽으니, 안에서는 굽은 줄을 모른다. 전에 쓴 "에이전트는 실패하지 않는다, 다만 틀린 방향으로 성공한다"의 사람 버전이다. 루프는 자신만만하게 엉뚱한 곳으로 수렴할 수 있다.

그래서 나는 루프에 갇히지 않으려면 외부인을 만나야 한다고 본다. 외부인은 루프 밖의 Oracle이다. 그는 내 루프가 쌓아 온 맥락을 공유하지 않기 때문에, 바로 그 이유로 내 자가 굽었다는 걸 말해 줄 수 있다. 루프 안에서는 다들 당연하게 끄덕이던 것에 "그게 왜 당연하죠?"라고 묻는 사람. 그 질문이 굽은 자의 영점을 바깥에서 다시 찍어 준다.

지난 글의 표현을 빌리면, 외부인은 사람 세계의 표준어다. 자체 규범(사투리)으로만 돌아가는 루프는 자기들끼리만 말이 통하고, 그 안에서 기준이 미끄러져도 알아채지 못한다. 루프가 만들어 내지 않은 기준, 루프 밖에서 들여온 시선만이 그 폐쇄를 깬다. 그래서 외부인을 만나는 일은 한가한 네트워킹이 아니라 Oracle Drift에 대한 교정 장치다. 안으로는 판정을 기억으로 쌓아 흔들림을 추적하고(8절), 밖으로는 외부인을 만나 영점을 다시 맞춘다. 병렬 루프로 사람 Oracle이 1/N로 얇아질수록(6절), 이 바깥의 영점은 더 절실해진다.

10. 남는 시간은 자기 보정에 쓴다

여기서 실제로 일하는 모양을 한 겹 더 공유한다. 앞의 세 루프는 가능한 만큼 자동화해 병렬로 굴린다. 그러면 1/N로 쪼개졌던 내 시간에 틈이 생긴다. 그 틈을 나는 두 가지에 쓰는데, 둘 다 결국 흔들리는 사람 Oracle을 보정하는 일이다.

시간이 비면 먼저 공부한다. 논문을 리서치해 얻은 것을 KB(knowledge base)에 온톨로지로 넣어 둔다. 이건 9절의 외부 영점을 혼자서도 끌어오는 방법이다. 새 논문은 내 루프가 만들어 내지 않은 바깥의 기준이고, 그걸 온톨로지로 구조화해 두면 다음 판정 때 통 안의 아인슈타인에게도, 통 밖의 나에게도 다시 꺼내 쓸 수 있다. 지난 글에서 말한 "곱셈을 덧셈으로", "모델이 이미 아는 표준어로 적기"가 여기서 그대로 일한다. 한 번 구조화해 둔 지식은 매 루프마다 다시 공부하지 않아도 된다.

그러고도 시간이 남으면 콘텐츠를 만든다. 지금 읽고 있는 이 글이 그 산물이다. 생각을 글로 꺼내 두면 루프 밖의 사람들이 읽고 되물어 온다. 콘텐츠는 외부인을 한 명씩 찾아다니지 않고도 외부의 시선을 불러들이는 장치다. 9절의 외부인이 내가 찾아가는 영점이라면, 콘텐츠는 영점이 나를 찾아오게 만드는 쪽이다.

정리하면, 자동화의 목적은 시간을 아끼는 게 아니라 아낀 시간을 사람 Oracle을 보정하는 데 돌리는 것이다. 병렬로 굴려 비운 시간을 공부와 콘텐츠로 다시 채워, 굽은 자를 펴는 데 쓴다. 자동화가 사람을 한가하게 만드는 게 아니라, 사람이 자기 자를 손볼 여유를 만들어 준다.

처음으로 돌아가면, 스타트업에서 내가 가졌던 타협점은 퀄리티를 깎는 것 하나뿐이었다. 이제 겨우 다른 타협점을 찾았다. 일을 줄이지도, 퀄리티를 깎지도 않는 대신, 흔들리는 채점자를 계속 보정하는 것. 이게 내가 "졌지만 잘 싸웠다"에서 벗어나려고 붙잡은 방법이다. 사정은 여전히 변명이 되고 고객은 여전히 완성도에만 지갑을 열기 때문이다.

11. 자동 항해 중인 배, 그리고 나침반

마지막은 한 장면으로 닫고 싶다. 배가 자동 항해 중이다. 수십 개의 루프가 알아서 돌아간다. 데이터가 들어오고, 모델이 학습되고, 리포트가 나오고, QA가 돈다. 갑판 위는 분주하지만, 정작 선장은 바다를 보고 있지 않다. 그는 나침반의 오차를 점검하고 있다.

이상하게 들릴지 모른다. 배가 저렇게 잘 가는데 왜 바다가 아니라 계기를 보고 있나. 그러나 자동 항해일수록 진짜 위험은 속도가 아니라 방향이다. 나침반이 1도만 틀어져 있어도, 배는 그 1도만큼 자신만만하게, 빠르게, 엉뚱한 곳으로 간다. 게다가 갑판에서는 아무 문제도 보이지 않는다. 점수판이 멀쩡한 채로 시스템이 조용히 드리프트한다는 이 글의 그림이, 바로 이 배다.

그래서 자동화의 핵심은 배를 더 빨리 모는 게 아니다. 방향을 재는 나침반이 얼마나 틀어졌는지 아는 것이다. Oracle이 그 나침반이고, 이 글 전체는 틀어지는 나침반을 어떻게 점검하고 다시 맞출지에 관한 것이었다. 안으로 판정을 기억해 오차를 추적하고, 밖으로 외부인이라는 다른 별을 보고 영점을 다시 잡고, 비운 시간엔 계기 자체를 손본다.

시리즈의 메타포도 여기서 한 줄로 모인다.

통 속의 아인슈타인(무엇을 보여줄 것인가) → 메모장(무엇을 기억할 것인가) → 나침반(무엇을 믿을 것인가)

좋은 Oracle은 태어나는 게 아니라 관리된다. 흔들리지 않는 나침반은 없다. 있는 것은 자기 오차를 아는 나침반뿐이다.

12. 한 문장 요약

시스템을 채점하는 Oracle도 고정점이 아니다. Oracle이 Model이면 그 역시 통 속의 아인슈타인이라 Model Drift를 겪고, 사람이면 그의 Mental Model이 흔들린다. 게다가 여러 루프를 병렬로 굴릴수록 판단 시간이 1/N로 쪼개져 사람 Oracle의 흔들림은 기본값이 된다. 그러니 주인공은 에이전트가 아니라 자기 자신을 채점하는 Oracle, 곧 흔들리는 나 자신이고, 사람은 시스템을 관리하는 주체이자 동시에 관리 대상이다. 재는 자(尺)가 흔들리면 점수판은 멀쩡한 채로 시스템이 조용히 드리프트하므로, 답은 완벽한 Oracle을 찾는 게 아니라 흔들림을 Drift Event로 잡아 Decision과 Update로 잇고, 안으로는 판정을 이벤트로 기억해 드리프트를 추적하고, 밖으로는 외부인을 만나 영점을 다시 맞추며, 비운 시간을 공부와 콘텐츠로 돌려 판정 기준 자신을 보정하는 것이다. 자동 항해의 핵심은 배를 더 빨리 모는 게 아니라 방향을 재는 나침반이 얼마나 틀어졌는지 아는 것이다. 좋은 Oracle은 태어나는 게 아니라 관리된다.

메모 (발행 전 정리용)

포스트모템(게시 후). 1·2편 반응은 괜찮았으나 3편(이 글) LinkedIn 반응은 저조. 사용자 결정: 콘텐츠는 그대로 두고 학습만 남김(2026-06-20). 추정 원인: (1) 개념 밀도 과다(Oracle/Oracle Drift/Model Drift/Mental Model/1·N/Drift→Decision→Update/외부인·영점/나침반/시리즈 메타를 한 글에), (2) 진입 용어가 추상적(제목부터 'Oracle'; 1·2편은 일상어·즉물 비유로 진입), (3) 가져갈 한 문장(takeaway)이 분산, (4) 리프레이밍으로 밀도가 더 올라감(메인테이너+관제실+나침반+자기채점 메타), (5) 주제 자체가 한 층 메타(기억·맥락=실무 vs 판단·평가=그 위)라 공감 표면적이 좁음. 다음 편 원칙: 글당 중심 개념 1개 + 즉물적 훅, 추상 용어는 비유 뒤로, 곁가지는 과감히 컷. (wm_node.py 부재로 정식 IN/EP 미기록. CLI 복구 시 issue-note로 승격할 것.)
포스트모템 추가 가설(2026-06-20). (6) 즉시 적용 가능성 차이: 1·2편(기억·맥락)은 국내 현장에서 바로 손댈 실무인데, 3편(판단·Oracle 관리)은 당장 적용할 레버가 약해 "그래서 뭘 하라고?"가 흐림. (7) 개인 서사 과다 도입: 이번 세션에서 의도적으로 '왜 이 글을 쓰는가' 스타트업 서사를 맨 앞에 뒀는데, 독자 진입이 '내 얘기'가 아니라 '글쓴이 얘기'가 됨(1·2편은 독자가 겪는 현상으로 진입). (8) 매스미디어 순서 위반: '듣고 싶은 것 → 말하고 싶은 것'으로 흘러야 하는데, 말하고 싶은 것(Oracle도 흔들린다/나침반)에서 출발. 수정 원칙: 훅은 독자가 듣고 싶은 것(겪는 통증·얻을 것)으로 열고, 개인 서사는 본문 중반의 신뢰장치로 내린다. 그리고 즉시 적용 가능한 한 수를 반드시 포함한다.
프레이밍 전환(핵심). 무게중심을 "지쳐 가는 메인테이너"식 피해자 서사가 아니라 "인간도 Drift하므로 판정자 자신이 관리 대상"으로 잡음. 주인공 = 자기 자신을 채점하는 Oracle(= 흔들리는 나). 제목 좋은 Oracle은 태어나는 게 아니라 관리된다 / 부제 "판단자는 흔들린다. 중요한 건 흔들리지 않는 것이 아니라, 흔들림을 추적하는 것이다". 대안 제목 Oracle도 관리 대상이다도 후보(원하면 스왑).
시리즈 통일 + 메타포. 1편 메모장(무엇을 기억) → 2편 통 속 아인슈타인(무엇을 보여줄) → 3편 나침반/오라클 관리(무엇을 믿을). 1절에 3편 지도, 11절에 항해사·나침반 클로징(거울안은 8절 Decision History 장면으로 흡수). 6절 리누스 메인테이너 번아웃은 "피해자 서사 → 관리 대상" 전환의 실사례 앵커로 재배치하고 좋은 Agent보다 좋은 Repository를 related로 연결.
도입을 "왜 이 글을 쓰는가"(스타트업에서 퀄리티 외 타협점이 없던 절박함 → Agentic Workflow가 유일한 희망 → 워크플로 토폴로지·루프 보정을 다루는 이유)로 시작하도록 재구성함. 신뢰·공감 훅 + 글 전체 프레이밍. 10절 끝에서 "졌지만 잘 싸웠다"를 받아 수미상관으로 닫음. 본문 개념 순서(비유→Oracle→Drift→Model/사람→병렬→루프→외부인→자기보정)는 유지.
시리즈 후속편. 직전 글 맥락을 어떻게 전달해야 하는가: LLM은 통 속에 든 아인슈타인이다의 가장 바깥 고리(loop)를 여는 글. 도입에서 prompt ⊂ context ⊂ harness ⊂ loop 체인을 한 줄로 받되, 단독으로도 읽히게 구성함.
Oracle 개념(판정 주체 = 인식론적 상한)은 기존 발행 글 AI는 무엇으로 자신을 재는가: Oracle, 판정 기준의 구조와 한계에서 정의된 것을 계승. 채널별로 그 글을 한 줄 링크로 받을지 판단.
본문 구조는 MSO v0.3.5의 Governance Loop(Drift → Decision Case → Agent Decision/Alternatives → User Decision → Policy/Parameter Update)와 "Events First", "Human Remains Final Authority" 원칙을 비유로 풀어낸 것. 원자료의 mermaid 다이어그램은 채널 변환 시(특히 Substack/Notion) 선택적으로 추가 가능. LinkedIn은 텍스트 흐름으로.
Drift 분류(Oracle/Concept/Data/Workflow/Goal/Environment/Model/Context)는 본문에서 일부만 호출함. 전체 택소노미가 필요하면 별도 표로 보강 가능.
"조용히 무너진다"는 기존 발행 글 에이전트 파이프라인은 왜 조용히 무너지는가와 의도적으로 공명시킨 표현.
6절(병렬 루프 / 1·N)과 9절(외부인)은 저자의 실제 Agentic Workflow 운영 경험에서 나온 핵심 어필 포인트. 6절은 "실행은 병렬화되는데 판단은 안 된다 → 사람 Oracle 드리프트가 기본값"이라는 구조적 주장이고, 9절은 "루프는 자기참조적이라 외부인이 영점 교정"이라는 해법. 둘은 8절(내부 기억 추적)과 안/밖으로 짝을 이룸. 9절은 기존 발행 글 에이전트는 실패하지 않는다, 다만 틀린 방향으로 성공한다와 공명.
6절 병렬 갈래는 저자 실제 워크플로 그대로(신뢰 목적의 사례 공유): ① 데이터 분석→전처리→모델 학습·프롬프팅→검증·평가 → 모델/프롬프트/데이터셋, ② 데이터 수집→검증→구조화→분석 → 리포트, ③ 서비스 정책→시스템 QA → 리포트. "루프는 필수, 판단은 매번 보정 필요"라는 체득을 명시. 채널 변환 시 독자층에 맞게 예시 조정 가능.
10절(자기 보정)도 실제 업무방식 공유: 병렬 자동화로 비운 시간 → 논문 리서치를 KB에 온톨로지로 적재(공부) → 콘텐츠 제작. 지난 글의 "곱셈을 덧셈으로"·"표준어로 적기"와 연결되고, 콘텐츠는 외부 영점(9절)을 불러들이는 장치로 위치시킴. 이 글 자체가 그 산물이라는 자기참조 포함.
엠대시 미사용 확인(UD-0021). 尺(자)·콜론·괄호·가운뎃점으로 대체.
후속(v0.3.6+) 떡밥: Decision Criteria(Accuracy/Cost/Latency 등으로 대안을 평가), Preference Learning(판정 이력에서 조직 선호 추출), Decision Simulator. 이번 글에서는 의도적으로 배제하고 다음 편으로 미룸.